Verzögerung der Replikation

Auf dieser Seite wird beschrieben, wie Sie die Replikationsverzögerung bei Cloud SQL-Lesereplikaten beheben können.

Übersicht

Die Replikationsverzögerung kann in verschiedenen Szenarien auftreten:

• Die primäre Instanz kann die Änderungen nicht schnell genug an das Replikat senden.
• Das Replikat kann die Änderungen nicht schnell genug empfangen.
• Das Replikat kann die Änderungen nicht schnell genug anwenden.

Die Gesamtverzögerung wird durch den Messwert replica_lag angegeben. Der Unterschied zwischen replica_lag und network_lag kann der dritte Grund dafür sein, dass das Replikat Replikationsänderungen nicht schnell genug anwendet. Diese Messwerte werden unten im Abschnitt Replikationsverzögerung überwachen beschrieben.

Schnellere Replikatkonfiguration

Es gibt zwei Möglichkeiten, damit ein MySQL-Replikat Änderungen schneller anwendet. Nutzer können ihre Replikate mit den folgenden Optionen konfigurieren:

• Parallele Replikation
• Leistungsstarke Leerung

Parallele Replikation

Bei einer Replikationsverzögerung kann auch eine parallele Replikation helfen. Dazu wird das Replikat so konfiguriert, dass mehrere Threads parallel verwendet werden, um Änderungen auf das Replikat anzuwenden. Informationen zur Verwendung der parallelen Replikation finden Sie unter Parallele Replikation konfigurieren.

Wenn Sie die parallele Replikation durch Festlegen des Flags replica_parallel_workers (oder slave_parallel_workers) aktivieren, sollten Sie Folgendes beachten:

• Wir empfehlen, den Wert des replica_parallel_workers-Flags auf eine Zahl zu setzen, die der Anzahl der vCPUs der Replikatinstanz entspricht. Ein sehr hoher Wert kann zu Wartezeiten für Sperren, Zeitüberschreitungen bei Sperren und Deadlocks führen. Wenn Sie Spitzen bei der Wartezeit für Sperren beobachten, die mit der Replikationsverzögerung übereinstimmen, sollten Sie die Parallelität reduzieren.
• Wenn Ihre MySQL-Version das Flag binlog_transaction_dependency_tracking unterstützt, sollten Sie es für die primäre Instanz auf WRITESET festlegen. Dies ist das Standardverhalten für Version 8.4 und höher.

Leistungsstarke Leerung

Standardmäßig leert Cloud SQL for MySQL die Redo-Logs nach jeder Transaktion auf das Laufwerk, um die Daten zu schützen. Ein leistungsstarkes Leeren von Elementen reduziert die Häufigkeit, mit der die Redo-Logs auf einmal pro Sekunde auf das Laufwerk geleert werden. Dadurch kann die Schreibleistung auf dem Replikat verbessert werden, da die Festplatten-E/A reduziert wird.

Legen Sie für das Flag innodb_flush_log_at_trx_commit des Lesereplikats den Wert 2 fest. Wenn die binäre Protokollierung für das Replikat aktiviert ist, empfehlen wir, das Flag sync_binlog auf einen hohen Wert, z. B. 10.000, zu setzen,damit das Flag innodb_flush_log_at_trx_commit wirksam wird.

Unter Tipps zum Arbeiten mit Flags finden Sie weitere Informationen zu diesem Flag.

Wenn das Flag innodb_flush_log_at_trx_commit für das Lesereplikat festgelegt ist und Cloud SQL erkennt, dass ein Absturz aufgetreten ist, erstellt Cloud SQL das Replikat automatisch neu.

Sicherstellen, dass das Replikat ausreichend bereitgestellt wird

Bei einer Replikatinstanz, die kleiner als die primäre Instanz ist (z. B. mit weniger vCPUs und Arbeitsspeicher), kann es zu einer Replikationsverzögerung kommen. Ein kleineres Replikat hat möglicherweise auch andere Standardkonfigurationsflags als eine größere primäre Instanz. Wir empfehlen, dass die Replikatinstanz mindestens so groß ist wie die primäre Instanz, damit genügend Ressourcen für die Replikationslast vorhanden sind.

Eine hohe CPU-Auslastung auf dem Replikat kann ebenfalls zu Replikationsverzögerungen führen. Wenn die CPU-Auslastung des Replikats hoch ist (z. B. über 90%), sollten Sie die CPU-Kapazität des Replikats erhöhen.

Abfragen und Schema optimieren

In diesem Abschnitt werden einige gängige Abfrage- und Schemaoptimierungen vorgeschlagen, mit denen Sie die Replikationsleistung verbessern können.

Abfrageisolationsebene im Lesereplikat

Die Transaktionsisolationsebenen REPEATABLE READ und SERIALIZABLE erhalten Sperren, die die Replikationsänderungen blockieren können. Prüfen Sie, die Isolationsebene für Ihre Abfragen im Replikat zu reduzieren. Die Transaktionsisolationsebene READ COMMITTED bietet eventuell eine bessere Leistung.

Lang andauernde Transaktionen in der primären Datenbank

Langlaufende Transaktionen auf der primären Instanz können zu Replikationsverzögerungen führen. Das Binärlog wird erst an das Replikat gesendet, wenn die Transaktion übernommen wurde.

Wenn eine große Anzahl an Zeilen in einer einzelnen Transaktion aktualisiert wird, kann dies zu einem plötzlichen Anstieg der Anzahl an Änderungen führen, die auf die primäre Instanz angewendet und dann an das Replikat gesendet werden müssen. Dies gilt für einzelne Anweisungen für Aktualisierungs- oder Löschvorgänge, die mehrere Zeilen gleichzeitig betreffen. Änderungen werden nach dem Commit an das Replikat gesendet. Ein plötzlicher Anstieg von Änderungen auf dem Replikat kann die Wahrscheinlichkeit von Sperrenkonflikten im Replikat erhöhen, wenn die Abfragelast auf dem Replikat ebenfalls hoch ist. Dies führt zu Replikationsverzögerungen.

Unterteilen Sie dann große Transaktionen in mehrere kleinere Transaktionen. Sie können lang andauernde Transaktionen überwachen, indem Sie den Messwert cloudsql.googleapis.com/database/mysql/innodb/active_trx_longest_time auf dem primären Knoten prüfen.

Fehlende Primärschlüssel

Cloud SQL-Lesereplikate verwenden eine zeilenbasierte Replikation. Diese wird langsam ausgeführt, wenn die replizierten MySQL-Tabellen keine Primärschlüssel haben. Wir empfehlen in diesem Fall, dass alle replizierten Tabellen Primärschlüssel erhalten.

Für MySQL 8 oder höher empfehlen wir, das Flag sql_require_primary_key auf ON zu setzen, damit Tabellen in Ihrer Datenbank Primärschlüssel haben müssen.

Lang andauernde Transaktionen im Lesereplikat

Lang andauernde Transaktionen für das Replikat, z. B. SELECT-Anweisungen, können die Replikation blockieren oder verlangsamen. Tabellenscans sind ein häufiges Problem. Untersuchen Sie alle Abfragen, die lange dauern, und optimieren Sie sie gegebenenfalls. Diese Anfragen können dazu führen, dass die Größe der InnoDB-Verlaufsliste zunimmt.

Übermäßig lange InnoDB-Verlaufsdaten

Eine sehr lange InnoDB-Verlaufsliste kann zu Leistungsproblemen führen und die Replikation verlangsamen. Sie können die Länge der Verlaufsliste mit dem Messwert cloudsql.googleapis.com/database/mysql/innodb/history_list_length überwachen. Dieser Messwert kann auch im primären Cluster hoch sein und bereits Leistungsprobleme verursachen. Wenn Ihr Replikat nach dem ersten Start Anzeichen für eine hohe Replikationsverzögerung aufweist, kann dies die Ursache sein.

Eine lange Verlaufsliste kann folgende Ursachen haben:

• Lang andauernde Transaktionen: Lang andauernde oder inaktive Transaktionen verhindern das Löschen alter Undo-Logeinträge.
• Langsame Festplattenleistung: Das dauerhafte Löschen ist ein E/A-intensiver Vorgang.
• Isolationsebene REPEATABLE READ: Das kann dazu beitragen, dass die Verlaufsliste immer länger wird.
• Unzureichende Bereinigungskonfiguration: Der Parameter innodb_purge_threads, der die Anzahl der Threads steuert, die für die Bereinigung verwendet werden, ist möglicherweise zu niedrig für die Arbeitslast.

Versuchen Sie Folgendes, um das Problem zu beheben:

• Teilen Sie große Transaktionen in kleinere auf. Schnelleres Löschen alter Logs ermöglichen
• Größere Instanz verwenden: Größere Instanzen haben mehr CPU und Arbeitsspeicher.
• Einstellungen für das Löschen von Daten anpassen: Erhöhen Sie innodb_purge_threads, innodb_io_capacity und innodb_io_capacity_max.
• Isolationsebene READ COMMITTED verwenden:
• Tabellen müssen Primärschlüssel haben. Tabellen ohne Primärschlüssel können Tabellenscans verursachen, die die Replikation verlangsamen und zum Wachstum der Verlaufsliste beitragen können.

Hohe Anzahl von Wartezeiten bei Sperren

Eine hohe Anzahl von Sperrwarten auf dem Replikat kann die Replikation verlangsamen, insbesondere wenn die parallele Replikation aktiviert ist. Sie können mit den folgenden Messwerten Sperren und Deadlocks überwachen:

• cloudsql.googleapis.com/database/mysql/innodb/row_lock_waits_count
• cloudsql.googleapis.com/database/mysql/innodb/row_lock_time
• cloudsql.googleapis.com/database/mysql/innodb/lock_timeout_count
• cloudsql.googleapis.com/database/mysql/innodb/deadlocks_count

Wenn diese Messwerte für Sperren zu hoch sind und mit der Replikationsverzögerung zu korrelieren scheinen, sollten Sie den Wert des Flags replica_parallel_workers verringern. Auch die Isolationsebene kann sich auf Sperren auswirken.

Exklusive Sperren aufgrund von DDL

DDL-Befehle (Data Definition Language) wie ALTER TABLE und CREATE INDEX können aufgrund von exklusiven Sperren zu Replikationsverzögerungen im Replikat führen. Um Sperrenkonflikte zu vermeiden, sollten Sie die DDL-Ausführung zu Zeiten planen, in denen die Abfragelast auf den Replikaten geringer ist.

Überlastetes Replikat

Wenn ein Lesereplikat zu viele Abfragen erhält, kann die Replikation blockiert werden. Ziehen Sie in Betracht, die Lesevorgänge auf mehrere Replikate aufzuteilen, um die Last auf den einzelnen Replikaten zu reduzieren.

Sie können Abfragespitzen vermeiden, indem Sie Replikatleseabfragen in Ihrer Anwendungslogik oder in einer Proxy-Ebene, falls Sie eine verwenden, drosseln.

Wenn es auf der primären Instanz zu Spitzen bei der Aktivität kommt, können Sie Updates verteilen.

Monolithische primäre Datenbank

Ziehen Sie eine vertikale Fragmentierung der primären Datenbank in Betracht, um zu verhindern, dass eine oder mehrere verzögerte Tabellen alle anderen Tabellen zurückhalten.

Replikationsverzögerung überwachen

Mit den Messwerten replica_lag und network_lag können Sie die Replikationsverzögerung überwachen und ermitteln, ob die Ursache der Verzögerung in der primären Datenbank, im Netzwerk oder im Replikat liegt.

Replikation prüfen

Führen Sie die folgende Anweisung für das Replikat aus, um zu prüfen, ob die Replikation funktioniert:

mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
               Slave_IO_State: Queueing master event to the relay log
                  Master_Host: xx.xxx.xxx.xxx
                  Master_User: cloudsqlreplica
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.199927
          Read_Master_Log_Pos: 83711956
               Relay_Log_File: relay-log.000025
                Relay_Log_Pos: 24214376
        Relay_Master_Log_File: mysql-bin.199898
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 24214163
              Relay_Log_Space: 3128686571
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: Yes
           Master_SSL_CA_File: master_server_ca.pem
           Master_SSL_CA_Path: /mysql/datadir
              Master_SSL_Cert: replica_cert.pem
            Master_SSL_Cipher:
               Master_SSL_Key: replica_pkey.pem
        Seconds_Behind_Master: 2627
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 321071839
                  Master_UUID: 437d04e9-8456-11e8-b13d-42010a80027b
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: System lock
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:52111095710-52120776390
            Executed_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:1-52113039508
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

Wenn die Replikation erfolgt, wird in der ersten Spalte Slave_IO_State der Eintrag Waiting for master to send event oder eine ähnliche Nachricht angezeigt. Außerdem ist das Feld Last_IO_Error leer.

Wenn die Replikation nicht erfolgt, wird in der Spalte Slave_IO_State der Status Connecting to master und in der Spalte Last_IO_Error der Status error connecting to master cloudsqlreplica@x.x.x.x:3306 angezeigt.

Gemäß der MySQL-Dokumentation gibt es weitere im Zusammenhang mit Replikationsverzögerungen relevante Felder:

Im vorherigen Beispiel hat Relay_Master_Log_File den Wert mysql-bin.199898. Master_Log_File beispielsweise den Wert mysql-bin.199927. Das numerische Suffix 199898 ist kleiner als 199927. Das bedeutet, dass das Replikat weiterhin die ältere Datei mysql-bin.199898 verwendet, obwohl es die neuere mysql-bin.199927-Logdatei erhalten hat.

In diesem Fall verzögert sich der SQL-Thread im Replikat.

Sie können auch eine Verbindung zur primären Datenbank herstellen und Folgendes ausführen:

  SHOW MASTER STATUS;

Dieser Befehl zeigt an, welche binlog-Datei in die primäre Datenbank geschrieben wird.

Wenn die binäre Logdatei der primären Datenbank aktueller ist als die Master_Log_File-Datei im Replikat, bedeutet dies, dass der E/A-Thread sich verzögert. Das Replikat liest dann noch eine ältere binäre Logdatei aus der primären Datenbank.

Wenn sich der E/A-Thread verzögert, ist auch der Messwert network_lag hoch. Wenn der SQL-Thread sich verzögert, der E/A-Thread aber nicht, ist der Messwert network_lag nicht so hoch, der Wert replica_lag aber hoch.

Mit den vorherigen Befehlen können Sie Verzögerungsdetails während der Verzögerung ermitteln. Die Messwerte network_lag und replica_lag bieten Ihnen einen Einblick in frühere Verzögerungen.

Verzögertes Replikat neu erstellen

Erstellen Sie ein Replikat, das hinter der primären Instanz zurückliegt, neu, wenn die Replikation einen akzeptablen Zeitraum überschreitet.

Mit Cloud SQL können Sie Ihr Lesereplikat so konfigurieren, dass es sich selbst neu erstellt, wenn die Replikation über einen akzeptablen Zeitraum hinaus verzögert wird und diese Verzögerung mindestens fünf Minuten lang anhält.

Wenn Sie eine akzeptable Replikationsverzögerung von weniger als 360 Sekunden (6 Minuten) definieren und eine Replikationsverzögerung von mindestens 361 Sekunden länger als 5 Minuten anhält, erstellt die primäre Instanz nach 5 Minuten einen neuen Snapshot von sich selbst und das Lesereplikat wird mit diesem Snapshot neu erstellt.

Das Neuerstellen eines verzögerten Lesereplikats bietet die folgenden Vorteile:

• Sie legen fest, was als akzeptabler Bereich für die Replikationsverzögerung gilt.
• So können Sie den Zeitaufwand für die Fehlerbehebung bei Replikationsverzögerungen um Stunden oder sogar Tage reduzieren.

Es gelten zusätzliche Details zu den Funktionen:

• Kompatibel mit den folgenden Versionen:
  • MySQL 5.7
  • MySQL 8.0
  • MySQL 8.4
• Ein akzeptabler Bereich für die Replikationsverzögerung muss in Sekunden definiert werden.
• Der kleinste akzeptable Wert liegt bei 300 Sekunden oder 5 Minuten.
• Der maximal zulässige Wert beträgt 31.536.000 Sekunden oder ein Jahr.
  • Wenn Sie die Option zum Neuerstellen von Replikatinstanzen mit Verzögerung für eine Instanz aktivieren, aber die maximal zulässige Replikationsverzögerung nicht festlegen, verwendet Cloud SQL den Standardwert von einem Jahr.
• Unterstützte Instanztypen:
  • Lesereplikat
  • Regionenübergreifendes Lesereplikat
  • Kaskadierendes Replikat
• Der für das Feld replicationLagMaxSeconds festgelegte Wert ist für jede Replikatinstanz spezifisch. Wenn eine primäre Instanz mehrere Replikatinstanzen hat, können Sie für jedes Replikat einen anderen Wert festlegen.
• Wenn eine Replik neu erstellt wird, kann es zu Ausfallzeiten kommen, während die folgenden Vorgänge abgeschlossen werden:
  • Die Replikation wurde gestoppt.
  • Das Replikat wird gelöscht.
  • Es wird ein Snapshot der primären Instanz erstellt.
  • Die Replika wird aus diesem neuesten Snapshot neu erstellt. Das neue Replikat verwendet denselben Namen und dieselbe IP-Adresse wie das vorherige Replikat. Daher muss MySQL beendet und neu gestartet werden.
  • Das neue Replikat beginnt mit der Replikation von Daten.
• replicationLagMaxSeconds ist ein Feld auf Instanzebene. Jede Instanz hat einen eigenen Wert.

• Wenn Sie mehrere Lesereplikate für dieselbe primäre Instanz haben, können Sie für jedes Replikat einen eindeutigen Wert für das Feld replicationLagMaxSeconds festlegen.

  Wenn Sie unterschiedliche Zeitlimits für verschiedene Replikate definieren, können Sie vermeiden, dass alle Replikate gleichzeitig ausfallen.

„Zurückgebliebenes Replikat neu erstellen“ aktivieren

Das Feature zum Neuerstellen von verzögerten Replikaten ist standardmäßig deaktiviert. Verwenden Sie eine der folgenden Methoden, um die Funktion beim Erstellen einer Instanz zu aktivieren:

gcloud beta sql instances create REPLICA_INSTANCE_NAME \
  --master-instance-name=PRIMARY_INSTANCE_NAME \
  --database-version=DATABASE_VERSION \
  --tier=TIER \
  --edition=EDITION \
  --region=REGION \
  --root-password=PASSWORD \
  --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS

{
  "settings": {
  "replicationLagMaxSeconds" :REPLICATION_LAG_MAX_SECONDS,
  }
  ...
}

Zeitrahmen für die Neuerstellung bei Replikationsverzögerung aktualisieren

Wenn Sie die Einstellungen einer Instanz aufrufen möchten, verwenden Sie eine der Methoden, die unter Zusammenfassende Informationen zu Instanzen aufrufen beschrieben werden.

Anhand dieser Informationen können Sie entscheiden, ob Sie den von Ihnen als akzeptabel angegebenen Zeitraum für die Replikationsverzögerung aktualisieren möchten, bevor das Replikat neu erstellt wird.

gcloud beta sql instances patch INSTANCE_NAME \
  --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS

Beschränkungen

Für das Neuerstellen von verzögerten Replikaten gelten die folgenden Einschränkungen:

• Werte für replicationLagMaxSeconds können nur in Sekunden festgelegt werden.
• Indexe, die vor einem Neuerstellungsvorgang auf dem Lesereplikat erstellt wurden, werden nicht beibehalten. Wenn ein Index vorhanden ist, erstellen Sie nach der Neuerstellung des Replikats einen sekundären Index.
• Um häufige Ausfallzeiten bei Lesereplikaten zu vermeiden, ist die Neuerstellung auf einmal pro Tag und Instanz beschränkt.
• Replikate externer Server werden von dieser Funktion nicht unterstützt.
• Wenn Sie die Neuerstellung von verzögerten Replikaten auf einem kaskadierenden Replikat aktivieren, erstellt Cloud SQL zuerst die untergeordneten Replikate neu, um die Replikationskonsistenz aufrechtzuerhalten.
• Für das Neuerstellen eines regionenübergreifenden Replikats fallen zusätzliche Kosten an.
• In der Cloud de Confiance Console können Sie die Neuerstellung von verzögerten Replikaten nicht aktivieren.

Wie geht es weiter?

• Replikate für die regionale Migration oder Notfallwiederherstellung hochstufen