Replikate verwalten

Auf dieser Seite werden Lesereplikate beschrieben. Zu diesen Vorgängen gehört die Deaktivierung und Aktivierung der Replikation. Außerdem wird auf dieser Seite Folgendes erläutert:

  • So stufen Sie ein Replikat zu einer eigenständigen Instanz hoch:
  • Parallele Replikation konfigurieren

Weitere Informationen zum Arbeiten mit Lesereplikaten finden Sie unter Replikation in Cloud SQL.

Replikation deaktivieren

Standardmäßig beginnt ein Replikat mit aktivierter Replikation. Sie können die Replikation jedoch deaktivieren, zum Beispiel zur Fehlerbehebung oder um den Instanzstatus zu analysieren. Wenn Sie bereit sind, können Sie die Replikation ausdrücklich wieder aktivieren. Durch das Deaktivieren oder Wiederaktivieren der Replikation wird das Replikat neu gestartet.

Durch das Deaktivieren der Replikation wird die Replikatinstanz nicht gestoppt. Sie wird zu einer schreibgeschützten Instanz, die sich nicht mehr von ihrer primären Instanz repliziert. Für die Instanz fallen weiterhin Kosten an. Sie können die Replikation auf dem deaktivierten Replikat wieder aktivieren, das Replikat löschen oder es zu einer eigenständigen Instanz hochstufen. Sie können das Replikat nicht stoppen.

So deaktivieren Sie die Replikation:

Console

  1. Öffnen Sie in der Google Cloud Console die Seite "Cloud SQL-Instanzen".

    Zur Seite „Cloud SQL-Instanzen“

  2. Öffnen Sie eine Replikatinstanz, indem Sie auf den Namen klicken.
  3. Klicken Sie in der Schaltflächenleiste auf Replikation deaktivieren.
  4. Klicken Sie auf OK.

gcloud

gcloud sql instances patch [REPLICA_NAME] --no-enable-database-replication

REST v1beta4

Um diesen cURL-Befehl über die Befehlszeile auszuführen, rufen Sie mit dem Befehl gcloud auth print-access-token ein Zugriffstoken ab. Sie können auch den APIs Explorer auf der Seite "Instanzen:patch" verwenden, um die REST API-Anfrage zu senden.

Ersetzen Sie diese Werte in den folgenden Anweisungen:

  • project-id: die Projekt-ID
  • replica-name: der Name der Replikatinstanz

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

JSON-Text anfordern:

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

Replikation aktivieren

Wenn ein Replikat lange nicht mehr repliziert wurde, braucht es einige Zeit, um auf den aktuellen Stand der primären Instanz zu gelangen. Löschen Sie in diesem Fall das Replikat und erstellen Sie ein neues.

So aktivieren Sie die Replikation:

Console

  1. Öffnen Sie in der Google Cloud Console die Seite "Cloud SQL-Instanzen".

    Zur Seite „Cloud SQL-Instanzen“

  2. Wählen Sie eine Replikatinstanz, indem Sie auf den Namen klicken.
  3. Klicken Sie in der Schaltflächenleiste auf Replikation aktivieren.
  4. Klicken Sie auf OK.

gcloud

gcloud sql instances patch [REPLICA_NAME] --enable-database-replication

REST v1beta4

Um diesen cURL-Befehl über die Befehlszeile auszuführen, rufen Sie mit dem Befehl gcloud auth print-access-token ein Zugriffstoken ab. Sie können auch den APIs Explorer auf der Seite "Instanzen:patch" verwenden, um die REST API-Anfrage zu senden.

Ersetzen Sie diese Werte in den folgenden Anweisungen:

  • project-id: die Projekt-ID
  • replica-name: der Name der Replikatinstanz

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

JSON-Text anfordern:

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

Replikat hochstufen

Wenn Sie ein Lesereplikat hochstufen, wird die Replikation beendet und die Instanz in eine eigenständige primäre Cloud SQL-Instanz mit Lese- und Schreibfunktionen umgewandelt. Dieser Vorgang kann nicht rückgängig gemacht werden.

Bevor Sie ein Lesereplikat hochstufen, sollten Sie alle Schreibvorgänge an die primäre Instanz beenden, sofern diese noch verfügbar ist und für Clients ausgeführt wird. Prüfen Sie dann den Replikationsstatus des Replikats. Folgen Sie dazu der Anleitung auf dem Tab MySQL-Client. Sie sollten kontrollieren, dass das Replikat die Replikation ausführt, und dann warten, bis die vom Messwert Seconds_Behind_Master gemeldete Replikationsverzögerung 0 ist. Andernfalls fehlen in der neu hochgestuften Instanz möglicherweise einige Transaktionen, für die in der Primärinstanz ein Commit durchgeführt wurde.

So stufen Sie ein Replikat zu einer eigenständigen Instanz hoch:

Console

  1. Öffnen Sie in der Google Cloud Console die Seite "Cloud SQL-Instanzen".

    Zur Seite „Cloud SQL-Instanzen“

  2. Wählen Sie eine Replikatinstanz, indem Sie auf den Namen klicken.
  3. Klicken Sie in der Schaltflächenleiste auf Replikat hochstufen.
  4. Klicken Sie auf OK.

gcloud

gcloud sql instances promote-replica [REPLICA_NAME]
  

REST v1beta4

Um diesen cURL-Befehl über die Befehlszeile auszuführen, rufen Sie mit dem Befehl gcloud auth print-access-token ein Zugriffstoken ab. Sie können auch den APIs Explorer auf der Seite "Instanzen:promoteReplica" verwenden, um die REST API-Anfrage zu senden.

Ersetzen Sie diese Werte in den folgenden Anweisungen:

  • project-id: die Projekt-ID
  • replica-name: der Name der Replikatinstanz

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

Prüfen Sie, ob die hochgestufte Instanz korrekt konfiguriert ist. Insbesondere sollten Sie bei Bedarf die Instanz für Hochverfügbarkeit konfigurieren.

Parallele Replikation konfigurieren

Die Replikationsverzögerung ist wichtig für die Verwaltung der Replikationsleistung. Eine Replikationsverzögerung tritt auf, wenn die Aktualisierungen eines Lesereplikats hinter den Aktualisierungen der primären Instanz liegen. In diesem Abschnitt wird beschrieben, wie Nutzer die parallele Replikation aktivieren können, wodurch die Replikationsverzögerung reduziert werden kann.

In der MySQL-Replikation wird ein SQL-Replikations-Thread verwendet, um die Transaktionen auszuführen, die im Relay-Log auf dem Lesereplikat erfasst werden. Parallele Replikation reduziert die Replikationsverzögerung, indem die Anzahl der SQL-Threads erhöht wird, die diese Transaktionen ausführen. Lesereplikate mit aktivierter paralleler Replikation werden manchmal als Multi-Thread-Replikate bezeichnet.

Die parallele Replikation ist in den folgenden drei Szenarien in Cloud SQL for MySQL verfügbar:

Der Einfachheit halber werden auf dieser Seite die Begriffe „primäre Instanz” und „Lesereplikat” verwendet.

Grundlegende Schritte zum Ändern der Flags für die parallele Replikation

Gehen Sie so vor, um die parallele Replikation zu aktivieren:

  1. Deaktivieren Sie die Replikation in einem Lesereplikat.
  2. Legen Sie im Lesereplikat die Flags für die parallele Replikation fest. Geben Sie das Flag mit dem Befehl gcloud an. Die Option "Google Cloud Console" ist deaktiviert, wenn die Replikation deaktiviert ist.
  3. Aktivieren Sie die Replikation im Lesereplikat.
  4. Legen Sie optional auf der primäre Instanz die Flags fest, um die Leistung für die parallele Replikation zu optimieren.

Lesereplikate: Flags für parallele Replikation

Cloud SQL for MySQL unterstützt mehrere Flags für die parallele Replikation auf Lesereplikaten. Informationen zu den Flags erhalten Sie, wenn Sie auf die folgenden Links zur MySQL 8.0-Dokumentation klicken:

Durch das Ändern dieser Flags wird das Lesereplikat nicht neu gestartet.

Die folgende Tabelle enthält die zulässigen Bereiche und Standardwerte für diese Flags:

Replikat-Flag lesen Zulässige Werte MySQL 5.7 (Standardwert) MySQL 8.0 (Standardwert)
slave_parallel_workers 0-1024 0 0
slave_parallel_type DATABASE, LOGICAL_CLOCK DATABASE DATABASE
slave_preserve_commit_order 0, 1 0 1
slave_pending_jobs_size_max 1024-1GB 16MB 128 MB

Das Flag slave_preserve_commit_order verhindert Lücken in der Reihenfolge der Transaktionen, die über das Relay-Log des Replikats ausgeführt werden.

Für die Einstellung slave_preserve_commit_order=1 ist Folgendes erforderlich:

Das Flag slave_pending_jobs_size_max legt den maximalen Arbeitsspeicher in Byte fest, der für Anwenderwarteschlangen verfügbar ist, die Ereignisse halten, die noch nicht angewendet wurden.

Primäre Instanz: Flags für parallele Replikation

Cloud SQL for MySQL unterstützt mehrere Flags zur Verwendung auf einer primären Instanz. Sie können diese Flags verwenden, um die Replikationsleistung für zugehörige Lesereplikate mit aktivierter parallelen Replikation zu optimieren. Informationen zu den Flags erhalten Sie, wenn Sie auf die folgenden Links zur MySQL 8.0-Dokumentation klicken:

Durch das Ändern dieser Flags wird die primäre Instanz nicht neu gestartet.

Die folgende Tabelle enthält die zulässigen Bereiche und Standardwerte für diese Flags:

Flag der primären Instanz Zulässige Werte MySQL 5.7 (Standardwert) MySQL 8.0 (Standardwert)
binlog_transaction_dependency_history_size 1-1000000 25.000 25.000
binlog_transaction_dependency_tracking COMMIT_ORDER, WRITESET, WRITESET_SESSION COMMIT_ORDER COMMIT_ORDER
transaction_write_set_extraction OFF, MURMUR32, XXHASH64 OFF XXHASH64

Wenn in MySQL 5.7 binlog_transaction_dependency_tracking auf WRITESET oder WRITESET_SESSION festgelegt ist, muss transaction_write_set_extraction auf einen Nicht-OFF-Wert festgelegt sein (XXHASH64 oder MURMUR32).

Replikationsstatus überprüfen

Wenn Sie eine Replikatinstanz mit der Google Cloud Console aufrufen oder sich bei einem Verwaltungsclient bei der Instanz anmelden, erhalten Sie Details zur Replikation, einschließlich Status und Messwerten. Wenn Sie das gcloud-Befehlszeilentool verwenden, erhalten Sie eine kurze Zusammenfassung der Replikationskonfiguration.

Die folgenden Messwerte stehen für Replikatinstanzen zur Verfügung. (Weitere Informationen zu zusätzlichen Messwerten, die für alle Instanzen verfügbar sind, einschließlich Nicht-Replikatinstanzen.)

MesswertBeschreibung
Replikationsstatus
(cloudsql.googleapis.com/database/replication/state)

Gibt an, ob die Replikation aktiv Logs von der primären zur Replikatdatenbank streamt. Folgende Werte sind möglich:

  • Running
  • Stopped
  • Error

Dieser Messwert gibt Running an, wenn die E/A- und SQL-Threads des Replikats ausgeführt werden. Im Ausführungsstatus des Slave-E/A-Threads undAusführungsstatus des Slave-SQL-Threads erhalten Sie weitere Informationen. Alternativ können Sie im MySQL-Referenzhandbuch den Replikationsstatus prüfen.

Verzögerung der Replikation
(cloudsql.googleapis.com/database/replication/replica_lag)

Die Zeit, in der der Status des Replikats vom Status der primären Instanz verzögert wird. Dies ist die Differenz zwischen (1) der aktuellen Zeit und (2) dem ursprünglichen Zeitstempel, zu dem der Primärserver die Transaktion festgeschrieben hat, die derzeit auf das Replikat angewendet wird. Insbesondere können Schreibvorgänge als verzögert gezählt werden, selbst wenn sie vom Replikat empfangen wurden, wenn das Replikat den Schreibvorgang noch nicht auf die Datenbank angewendet hat.

Dieser Messwert gibt den Wert von Seconds_Behind_Master an, wenn SHOW SLAVE STATUS auf dem Replikat ausgeführt wird. Weitere Informationen finden Sie im MySQL-Referenzhandbuch unter Replikationsstatus prüfen.

Ausführungsstatus des Slave-E/A-Threads
(cloudsql.googleapis.com/database/mysql/replication/slave_io_running_state)

Gibt an, ob der E/A-Thread zum Lesen des binären Logs der primären Instanz auf dem Replikat ausgeführt wird. Folgende Werte sind möglich:

  • Yes
  • No
  • Connecting

Dieser Messwert gibt den Wert von Slave_IO_Running an, wenn SHOW SLAVE STATUS auf dem Replikat ausgeführt wird. Weitere Informationen finden Sie im MySQL-Referenzhandbuch unter Replikationsstatus prüfen.

Ausführungsstatus des Slave-SQL-Threads
(cloudsql.googleapis.com/database/mysql/replication/slave_sql_running_state)

Gibt an, ob der SQL-Thread zum Ausführen von Ereignissen im Relay-Log auf dem Replikat ausgeführt wird. Folgende Werte sind möglich:

  • Yes
  • No
  • Connecting

Dieser Messwert gibt den Wert von Slave_SQL_Running an, wenn SHOW SLAVE STATUS auf dem Replikat ausgeführt wird. Weitere Informationen finden Sie im MySQL-Referenzhandbuch unter Replikationsstatus prüfen.

So prüfen Sie den Replikationsstatus:

Console

Cloud SQL meldet die Messwerte Replication State und Replication Lag im standardmäßigen Cloud SQL-Monitoring-Dashboard.

Wenn Sie andere Messwerte für regionale und regionenübergreifende Replikate und Replikate externer Server sehen möchten, erstellen Sie ein benutzerdefiniertes Dashboard und fügen Sie die Messwerte hinzu, die Sie überwachen möchten:

  1. Rufen Sie die Seite Monitoring auf.
  2. Wählen Sie den Tab Dashboards aus.
  3. Klicken Sie oben auf der Seite in der Schaltflächenleiste auf + DASHBOARD ERSTELLEN.
  4. Geben Sie einen Namen für das Dashboard ein und klicken Sie auf „OK“.
  5. Klicken Sie rechts oben auf der Seite auf DIAGRAMM HINZUFÜGEN.
  6. Wählen Sie als Ressourcentyp die Option Cloud SQL-Datenbank aus.
  7. Sie haben folgende Möglichkeiten:
    1. Um den Replikationsstatuswert zu beobachten, geben Sie im Feld Messwert auswählen Replication state ein. Fügen Sie dann einen Filter für state = "Running" hinzu. Das Diagramm zeigt 1, wenn die Replikation ausgeführt wird, andernfalls 0.
    2. Um den Replikationsmesswert zu überwachen, geben Sie im Feld Messwert auswählen replica_lag ein. Das Diagramm zeigt die Zeitspanne an, die der Zustand des Replikats hinter der primären Instanz zurückliegt.
    3. So überwachen Sie den Status des E/A-Threads des Replikats: Geben Sie im Feld Messwert auswählen Slave I/O thread running state ein. Fügen Sie dann einen Filter mit state = "Yes" hinzu. Im Diagramm wird 1 angezeigt, wenn der Thread ausgeführt wird, andernfalls 0.
    4. So beobachten Sie den Status des SQL-Threads des Replikats: Geben Sie im Feld Messwert auswählen Slave SQL thread running state ein. Fügen Sie dann einen Filter mit state = "Yes" hinzu. Im Diagramm wird 1 angezeigt, wenn der Thread ausgeführt wird, andernfalls 0.

gcloud

Prüfen Sie den Replikationsstatus einer Replikatinstanz mit:

gcloud sql instances describe [REPLICA_NAME]

Suchen Sie in der Ausgabe nach den Attributen databaseReplicationEnabled und masterInstanceName.

Prüfen Sie auf vorhandene Replikate einer primären Instanz mit:

gcloud sql instances describe [PRIMARY_INSTANCE_NAME]

Suchen Sie in der Ausgabe nach dem Attribut replicaNames.

MySQL-Client

  1. Stellen Sie eine Verbindung zum Replikat mit einem MySQL-Client her.

    Weitere Information finden Sie unter Verbindungsoptionen für externe Anwendungen.

  2. Prüfen Sie den Replikatstatus:
    SHOW SLAVE STATUS \G

    Suchen Sie die folgenden Messwerte in den Ausgabedaten des Befehls:

    • Master_Host: Der Name der primären Instanz.
    • Slave_IO_Running, Slave_SQL_Running: Gibt an, ob die E/A- und SQL-Threads ausgeführt werden. Diese Threads sind dafür verantwortlich, Ereignisse vom primären in das Relay-Log des Replikats zu übertragen und diese Ereignisse aus dem Relay-Log auszuführen. Der Wert des Messwerts ist Yes, wenn der Thread ausgeführt wird. Beide Threads müssen ausgeführt werden, damit die Replikation aktiv ist.
    • Seconds_Behind_Master: Die Zeitspanne in Sekunden, um die das Replikat bei der Verarbeitung der Transaktionen der primären Instanz sich verzögert, d. h. die Differenz zwischen (1) der aktuellen Zeit und (2) dem ursprünglichen Zeitstempel, zu dem die primäre Instanz die Transaktion festgeschrieben hat, die derzeit auf das Replikat angewendet wird. Der Wert ist NULL, wenn die Replikation fehlerhaft ist.
    • Master_Log_file, Read_Master_Log_Pos, Relay_Master_Log_File, Exec_Master_Log_Pos: Diese Messwerte zeigen die Koordinaten (Dateiname und Offset) an, bis zu denen der E/A-Thread Ereignisse gelesen (Master_Log_file und Read_Master_Log_Pos) und bis zu denen der SQL-Thread Ereignisse ausgeführt (Relay_Master_Log_File und Exec_Master_Log_Pos) hat. Wenn sie gleich sind (d. h. Master_Log_file gleich Relay_Master_Log_File und Read_Master_Log_Pos gleich Exec_Master_Log_Pos ist), hat das Replikat alle Ereignisse verarbeitet, die es von der Primärinstanz empfangen hat.

Weitere Informationen zur Ausgabe dieses Befehls finden Sie in der MySQL-Dokumentation unter Replikationsstatus prüfen.

Fehlerbehebung

Klicken Sie auf die Links in der Tabelle, um weitere Informationen zu erhalten:

Problem Mögliche Ursache Lösungsvorschlag
Beim Erstellen hat das Lesereplikat nicht repliziert. Dies kann viele Ursachen haben. Weitere Informationen finden Sie in den Logs.
Lesereplikat kann nicht erstellt werden – invalidFlagValue-Fehler Eines der explizit oder standardmäßig angegebenen Flags ist ungültig. Prüfen Sie Flag-Werte und Logs auf weitere Informationen.
Lesereplikat kann nicht erstellt werden – unbekannter Fehler. Dies kann viele Ursachen haben. Weitere Informationen finden Sie in den Logs.
Laufwerk ist voll. Das Laufwerk der primären Instanz kann während der Replikaterstellung zu voll werden. Aktualisieren Sie die primäre Instanz mit einem größeren Laufwerk.
Replikatinstanz verwendet zu viel Arbeitsspeicher. Replikate können häufig angeforderte Lesevorgänge im Cache speichern. Starten Sie die Replikatinstanz neu, um den temporären Speicherplatz freizugeben.
Replikation gestoppt. Der maximale Speicherplatz wurde erreicht und die automatische Speichererweiterung ist nicht aktiviert. Aktivieren Sie die automatische Speichererweiterung.
Replikationsverzögerung ist durchgehend hoch. Die kann viele verschiedene Ursachen haben. Hier finden Sie einige Lösungsvorschläge.

Beim Erstellen hat das Lesereplikat nicht repliziert

Beim Erstellen hat das Lesereplikat nicht repliziert.

Mögliche Ursache

Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler.

Lösungsvorschlag

Prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.


Lesereplikat kann nicht erstellt werden – invalidFlagValue-Fehler

Das Lesereplikat kann nicht erstellt werden – invalidFlagValue.

Mögliche Ursache

Eines der Flags in der Anfrage ist ungültig. Dies kann ein Flag sein, das Sie explizit angegeben haben, oder ein Flag, für das ein Standardwert festgelegt wurde.

Lösungsvorschlag

Prüfen Sie als Erstes, ob der Wert des Flags max_connections größer oder gleich dem Wert auf der Primärseite ist.

Wenn das Flag max_connections korrekt festgelegt ist, prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.


Lesereplikat kann nicht erstellt werden – unbekannter Fehler

Das Lesereplikat kann nicht erstellt werden – unknown error.

Mögliche Ursache

Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler.

Lösungsvorschlag

Prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.

Lautet der Fehler set Service Networking service account as servicenetworking.serviceAgent role on consumer project, deaktivieren Sie die Service Networking API und aktivieren Sie sie dann wieder. Dadurch wird das Dienstkonto erstellt, das erforderlich ist, um den Prozess fortzusetzen.


Laufwerk voll

UPDATE_DISK_SIZE- oder mysqld: disk is full-Fehler.

Mögliche Ursache

Das Laufwerk der primären Instanz kann während der Replikaterstellung zu voll werden.

Lösungsvorschlag

Bearbeiten Sie die primäre Instanz, um sie auf ein größeres Laufwerk zu aktualisieren.


Replikatinstanz verwendet zu viel Arbeitsspeicher

Die Replikatinstanz verwendet zu viel Arbeitsspeicher.

Mögliche Ursache

Das Replikat verwendet temporären Speicher zum Speichern häufig angeforderter Lesevorgänge im Cache, was dazu führen kann, dass es mehr Speicher als die primäre Instanz verwendet.

Lösungsvorschlag

Starten Sie die Replikatinstanz neu, um den temporären Speicherplatz freizugeben.


Replikation gestoppt

Die Replikation wurde gestoppt.

Mögliche Ursache

Das maximale Speicherlimit wurde erreicht und >automatic storage increase is disabled.

Lösungsvorschlag

Bearbeiten Sie die Instanz, um automatic storage increase zu aktivieren.


Replikationsverzögerung ist durchgehend hoch

Die Replikationsverzögerung ist durchgehend hoch.

Mögliche Ursache

Die Schreiblast ist für das Replikat zu hoch. Die Replikationsverzögerung tritt auf, wenn der SQL-Thread auf einem Replikat nicht mit dem E/A-Thread Schritt halten kann. Einige Arten von Abfragen oder Arbeitslasten können vorübergehend oder dauerhaft zu einer hohen Replikationsverzögerung für ein bestimmtes Schema führen. Typische Ursachen für Replikationsverzögerungen sind:

  • Langsame Abfragen des Replikats. Suchen Sie diese und korrigieren Sie sie.
  • Alle Tabellen müssen einen eindeutigen Schlüssel/Primärschlüssel haben. Jede Aktualisierung einer solchen Tabelle ohne eindeutigen bzw. Primärschlüssel führt zu vollständigen Tabellenscans auf dem Replikat.
  • Abfragen wie DELETE ... WHERE field < 50000000 führen bei der zeilenbasierten Replikation zu einer Replikationsverzögerung, da sich eine große Anzahl von Aktualisierungen auf dem Replikat ansammelt.

Lösungsvorschlag

Mögliche Lösungen:

Nächste Schritte