Übersicht über Lesereplikatsindexe

In diesem Dokument werden Konzepte und Mechanismen zum Verwalten von sekundären Indexen auf Cloud SQL-Lesereplikaten in der Cloud SQL Enterprise-Version und der Cloud SQL Enterprise Plus-Version beschrieben. In MySQL können Sie zwei Haupttypen von Indizes für eine Tabelle erstellen:

  • Geclusterter Index: Der Hauptindex in einer MySQL-Tabelle, der die Zeilen auf dem Laufwerk physisch sortiert. Wenn Sie einen Primärschlüssel für eine Tabelle definieren, verwendet MySQL diesen als geclusterten Index. Eine Tabelle kann nur einen geclusterten Index haben.

  • Sekundärer Index: Ein zusätzlicher Index für eine MySQL-Tabelle, der die Abfrageleistung optimiert.

    Ein Replikat ist normalerweise schreibgeschützt. Sie können jedoch zu Berichtszwecken sekundäre Indexe für Tabellen erstellen. Cloud SQL unterstützt zwei Methoden zum Erstellen von sekundären Replikatindexen:

    • Verwaltete Replikatindexe (empfohlen): Cloud SQL speichert Indexdefinitionen auf der primären Instanz und erstellt sekundäre Indexe nach einem Absturz oder einer Neuerstellung des Replikats automatisch neu. Google empfiehlt verwaltete Indexe gegenüber selbstverwalteten Indexen, um Indexverluste zu vermeiden und eine manuelle Indexwiederherstellung zu umgehen.
    • Selbstverwaltete Replikatindexe: Sie können sekundäre Indexe direkt auf einem Replikat hinzufügen und löschen. Diese Indexe bleiben jedoch nach einem Absturz des Replikats oder einer Neuerstellung des Replikats nicht erhalten. Wenn Sie selbstverwaltete Indexe verwenden, können Sie zu verwalteten Replikatindexen migrieren.

Replikatindexmethoden vergleichen

In der folgenden Tabelle werden verwaltete Replikatindexe und selbstverwaltete Replikatindexe in Cloud SQL verglichen:

Funktion Verwaltete Replikatindexe Selbstverwaltete Replikatindexe
Persistenz bei der Neuerstellung von Replikaten Automatisch neu erstellt Verworfen (manuelle Neuerstellung erforderlich)
Konfigurationsmodell Zentralisierte Metadaten auf der primären Instanz Direkte DDL auf dem Ziel-Lesereplikat
Ausführungsmechanismus Regelmäßiger Hintergrundprozess
(etwa alle fünf Minuten)		 Sofortige Ausführung
Schutzmaßnahme für Replikationsverzögerung Pausiert die Indexerstellung automatisch, wenn die Replikationsverzögerung 20 Minuten überschreitet. Keine (nutzerverwaltet)
Unterstützte Versionen Cloud SQL Enterprise-Version und Cloud SQL Enterprise Plus-Version Cloud SQL Enterprise und Cloud SQL Enterprise Plus
Unterstützte Datenbankversionen Cloud SQL for MySQL
(Wartungsversion R20260726.00_05 oder höher)		 Cloud SQL for MySQL
(alle unterstützten Versionen)
Unterstützung für Replikat des externen Servers Nicht unterstützt Unterstützt

Verwaltete Replikatindexe

Damit nach der Neuerstellung des Replikats keine Indexe verloren gehen, unterstützt Cloud SQL verwaltete Replikatindexe. Google empfiehlt diese Methode zur Indexerstellung und -aufbewahrung. Cloud SQL aktiviert diese Methode standardmäßig.

Für verwaltete Replikatindexe ist die Cloud SQL-Wartungsversion R20260726.00_05 oder höher erforderlich.

In den folgenden Abschnitten wird beschrieben, wie Cloud SQL Replikatindexe verwaltet, welche Vorteile sie bieten und wie sie sich bei Lifecycle-Events verhalten.

So verwaltet Cloud SQL verwaltete Replikatindexe

Bei dieser Methode definieren Sie sekundäre Replikatindexe, gruppieren sie und legen fest, welche Replikate diese Indexgruppen verwalten können. Cloud SQL führt einen Hintergrundprozess auf dem Replikat aus, um die erforderlichen Indexe automatisch zu erstellen und zu löschen und die Indexe im Laufe der Zeit zu verwalten. Wenn Cloud SQL einen verwalteten Replikatindex erstellt, wird dem Indexkommentar ein [SIC_X_Y]-Tag vorangestellt, wobei X und Y Ganzzahlen sind. Dieses Tag wird nur für die interne Verwaltung verwendet und hat keine Funktion.

Cloud SQL führt die Wartung von verwalteten Replikatindexen, z. B. das Erstellen und Löschen von Indexen, in Batches aus. Nachdem der Cloud SQL-Indexwartungsprozess eine Gruppe von CREATE- oder DROP-Aktionen erfasst hat, wird für jeden sekundären Index ein PENDING-Statuseintrag erstellt. Anschließend wird jede DDL-Anweisung (Data Definition Language, Datendefinitionssprache) nacheinander ausgeführt. Ein Fehler bei einem Index blockiert nicht die Ausführung nachfolgender Indexe in der Warteschlange. Cloud SQL ruft dann nach etwa fünf Minuten den nächsten Batch ab.

Vorteile und Anwendungsfälle

Verwaltete Replikatindexe bieten folgende Vorteile:

  • Automatisierte Indexaufbewahrung: Wenn Cloud SQL ein Lesereplikat neu erstellt (z. B. nach einem Instanzabsturz), werden die diesem Replikat zugeordneten sekundären Indexe automatisch neu erstellt. Sie müssen keine manuellen gespeicherten Prozeduren ausführen oder externe Scripts zur Schemabeobachtung verwalten, um fehlende Indexe wiederherzustellen.
  • Konsistente Abfrageleistung: Durch den automatischen Neuerstellung von sekundären Indexen nach der Replikatwiederherstellung sorgt Cloud SQL für einen gleichbleibenden Abfragedurchsatz und verhindert Spitzen bei der Abfragelatenz sowie eine hohe CPU-Auslastung, die durch nicht indexierte Abfragen verursacht werden.
  • Gruppenbasierte Konfiguration: Sie definieren sekundäre Indexe einmal auf der primären Instanz und organisieren sie in benannten Replikatgruppen. Anschließend können Sie einer Lesereplikat eine Indexgruppe mit Hunderten von Indexen zuweisen, indem Sie ein einzelnes Datenbank-Flag (cloudsql_index_recreate_replica_group) festlegen. Dadurch müssen Sie keine einzelnen gespeicherten Prozeduren für mehrere Replikate ausführen.
  • Selektive Indexzuweisung nach Replikatrolle: Sie können Indexgruppen speziell Lesereplikaten für Berichte und Analysen zuweisen, um Leseabfragen zu beschleunigen. Lesereplikate für die Notfallwiederherstellung bleiben dabei nicht indexiert und identisch mit dem Schema der primären Instanz. Dadurch werden der Overhead für Schreibtransaktionen und die Replikationsverzögerung auf DR-Instanzen vermieden.
  • Leistungsisolation der primären Instanz: Sekundäre Indexe auf Lesereplikaten optimieren Lese- und Berichtsabfragen, ohne Speicherplatz zu verbrauchen oder die Schreibtransaktionslatenz der primären Instanz zu erhöhen.
  • Integrierte Beobachtbarkeit: Mit dedizierten gespeicherten Prozeduren können Sie den Fortschritt der Indexerstellung, die Ausführungsdauer und die Fehlerlogs auf dem Lesereplikat überwachen.
  • Unterbrechungsfreie Migration und Koexistenz: Verwaltete Replikatindexe können sicher mit vorhandenen selbstverwalteten Replikatindexen auf derselben Instanz und Tabelle koexistieren. Sie können verwaltete Replikatindexe schrittweise ohne Ausfallzeiten oder Unterbrechung aktiver Lesearbeitslasten übernehmen.

Replikat hochstufen

Cloud SQL verwaltet verwaltete Replikatindexe nur auf Lesereplikatinstanzen. Wenn Sie ein Lesereplikat zu einer primären Instanz hochstufen, löscht Cloud SQL automatisch alle sekundären Indexe, die als verwaltete Replikatindexe erstellt wurden. Es kann etwa fünf Minuten dauern, bis Cloud SQL den Löschvorgang ausführt.

Obwohl Cloud SQL die sekundären Indexe löscht und Datenbank-Flags aus der hochgestuften Instanz entfernt, behält die primäre Instanz die sekundären Indexdefinitionen und Gruppenzuordnungen bei.

Notfallwiederherstellung (Disaster Recovery, DR) – Wechsel

Wenn Sie während eines DR-Wechsels das DR-Replikat zur neuen primären Instanz hochstufen, löscht Cloud SQL automatisch alle sekundären Indexe, die auf dem DR-Replikat erstellt wurden. Cloud SQL erstellt diese sekundären Indexe nicht automatisch auf der alten primären Instanz, wenn sie zu einem Replikat wird.

Wenn Sie nach dem Wechsel sekundäre Indexe auf der alten primären Instanz erstellen möchten, legen Sie das Datenbank-Flag cloudsql_index_recreate_replica_group für diese Instanz fest.

Replikationsverzögerung

Cloud SQL pausiert die Erstellung sekundärer Indexe, wenn die Replikationsverzögerung 20 Minuten überschreitet. Wenn die Erstellung des Index für das verwaltete Replikat bereits im Gange ist, wenn die Verzögerung 20 Minuten überschreitet, lässt Cloud SQL den Vorgang abschließen. Die Replikationsverzögerung pausiert keine Vorgänge zum Löschen von verwalteten Replikatindexen.

Beschränkungen

Wenn Sie verwaltete Replikatindexe verwenden, gelten die folgenden Einschränkungen:

  • Sie können keine verwalteten Replikatindexe auf externen Serverreplikaten erstellen: Cloud SQL unterstützt das Erstellen von verwalteten Replikatindexen für externe Serverreplikate nicht.
  • Maximal 1.000 Indexe pro Replikatgruppe: Sie können einer Replikatgruppe maximal 1.000 sekundäre Indexe zuweisen.
  • Das Aktualisieren oder Ändern von Indexmetadaten wird nicht unterstützt: Sie können vorhandene Indexmetadaten nicht aktualisieren oder ändern. Wenn Sie einen Index ändern möchten, müssen Sie die vorhandene Indexdefinition löschen und eine neue erstellen.

Selbstverwaltete Replikatindexe

Selbstverwaltete Replikatindexe sind sekundäre Indexe, die Sie direkt auf einzelnen Cloud SQL-Lesereplikaten erstellen und löschen. Wie verwaltete Replikatindexe optimieren sie die Leistung von Leseabfragen, z. B. für Berichts- und Analysearbeitslasten, ohne Speicherplatz zu verbrauchen oder die Schreiblatenz auf der primären Instanz zu beeinträchtigen.

Selbstverwaltete Indexverwaltung

Sie verwalten selbstverwaltete Replikatindexe direkt auf dem Lesereplikat. Verwenden Sie dazu die folgenden gespeicherten Prozeduren im Schema mysql:

  • mysql.addSecondaryIdxOnReplica: Fügt einen sekundären Index für eine angegebene Tabelle im Lesereplikat hinzu. Diese gespeicherte Prozedur ist ein Wrapper für die DDL-Anweisung CREATE INDEX.
  • mysql.dropSecondaryIdxOnReplica: Löscht einen zuvor erstellten sekundären Index aus dem Lesereplikat. Diese gespeicherte Prozedur ist ein Wrapper für die DDL-Anweisung DROP INDEX.

Zum Ausführen dieser gespeicherten Prozeduren ist die Rolle cloudsqlsuperuser erforderlich.

Wenn Sie einen selbstverwalteten Index erstellen, zeichnet Cloud SQL grundlegende Metadaten in der Tabelle mysql.cloudsql_replica_index auf dem Replikat auf, einschließlich Datenbankname, Tabellenname und Indexname. Im Gegensatz zu verwalteten Replikatindexen werden selbstverwaltete Indexe nicht auf der primären Instanz registriert und nicht vom Cloud SQL-Hintergrundreplikationsprozess verwaltet.

Syntaxdetails und Anwendungsbeispiele finden Sie unter Selbstverwaltete Replikatindexe.

Vorteile und Anwendungsfälle

Selbstverwaltete Replikatindexe bieten die folgenden Vorteile für bestimmte Workflows:

  • Leistungsisolation der primären Instanz: Sekundäre Indexe auf Lesereplikaten optimieren Lese- und Berichtsabfragen, ohne Speicherplatz zu verbrauchen oder die Schreibtransaktionslatenz der primären Instanz zu erhöhen.
  • Sofortige Ausführung: Aufrufe gespeicherter Prozeduren werden sofort als DDL-Anweisungen auf dem Replikat ausgeführt, ohne auf den regelmäßigen Hintergrundwartungszyklus (etwa alle fünf Minuten) zu warten, der für verwaltete Replikatindexe erforderlich ist.
  • Isolierte Tests und Experimente: Sie können die Abfrageleistung testen und Indexoptimierungen auf einem einzelnen Lesereplikat validieren, bevor Sie verwaltete Replikatindexe für eine Replikatgruppe erstellen.

Beschränkungen

Selbstverwaltete Replikatindexe haben erhebliche betriebliche Einschränkungen:

  • Keine Persistenz bei der Neuerstellung von Replikaten: Wenn Cloud SQL ein Lesereplikat neu erstellt (z. B. während der Instanzwiederherstellung, Wartung oder bei Hardwarefehlern), werden alle selbstverwalteten sekundären Indexe auf diesem Replikat gelöscht und nicht automatisch wiederhergestellt.
  • Aufwand für manuelle Wiederherstellung: Cloud SQL kann die Indexe nicht rekonstruieren und neu erstellen. Sie müssen die Indexe manuell neu erstellen, indem Sie mysql.addSecondaryIdxOnReplica noch einmal ausführen.
  • Leistungseinbußen bei Abfragen: Bei Leseabfragen kann es nach der Neuerstellung des Replikats zu Leistungseinbußen kommen, bis Sie die fehlenden Indexe manuell neu erstellen.

Da verwaltete Replikatindexe automatisch persistent gespeichert und bei der Neuerstellung von Replikaten neu erstellt werden, empfiehlt Google die Verwendung von verwalteten Replikatindexen für Produktionsarbeitslasten. Wenn Sie bereits selbstverwaltete Indexe haben, migrieren Sie sie zu verwalteten Replikatindexen.

Koexistenz von Replikatindextypen

Selbstverwaltete Replikatindexe (mit mysql.addSecondaryIdxOnReplica erstellt) und verwaltete Replikatindexe können auf derselben Cloud SQL-Lesereplikatinstanz und in derselben Tabelle koexistieren. So können Sie verwaltete Replikatindexe schrittweise übernehmen, ohne vorhandene Datenbankarbeitslasten zu unterbrechen.

Wenn Sie beide Methoden zur Indexverwaltung verwenden, beachten Sie die folgenden Verhaltensweisen:

  • Unabhängiger Betrieb: Selbstverwaltete Indexe, die Sie direkt auf dem Lesereplikat erstellen, funktionieren weiterhin parallel zu verwalteten Replikatsindexen.
  • Regelmäßige Bewertung: Der Cloud SQL-Hintergrundwartungsprozess bewertet regelmäßig (etwa alle fünf Minuten) Indexdefinitionen, die der Replikatgruppe zugeordnet sind, die Sie dem Replikat zuweisen.
  • Umgang mit Namenskonflikten: Wenn Sie eine Definition für einen verwalteten Replikatindex mit demselben Namen wie ein vorhandener selbstverwalteter Index im Lesereplikat registrieren, erkennt der Hintergrundprozess, dass bereits ein Index mit diesem Namen vorhanden ist. Der Prozess zeichnet den Status FAILED in der Tabelle mysql.cloudsql_replica_idx_status auf. Dieser Fehler hat keine Auswirkungen auf den Datenbanktraffic, erstellt keine Tabellensperren und wirkt sich nicht auf den vorhandenen selbstverwalteten Index aus.
  • Automatische Lösung bei der Neuerstellung: Wenn das Lesereplikat neu erstellt wird, löscht Cloud SQL den vorhandenen selbstverwalteten Index im Rahmen der Instanzneuerstellung und erstellt automatisch den verwalteten Replikatindex aus der registrierten Definition.

Nächste Schritte