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.

Leistungsstarke Leerung

Standardmäßig leert Cloud SQL for MySQL die Redo-Logs auf das Laufwerk. Ein leistungsstarkes Leeren von Elementen reduziert die Häufigkeit, mit der die Redo-Logs auf einmal pro Sekunde auf das Laufwerk geleert werden. Dies verbessert die Schreibleistung.

Legen Sie für das Flag innodb_flush_log_at_trx_commit des Lesereplikats den Wert 2 fest. Sie müssen auch das Flag sync_binlog auf einen höheren Wert setzen, damit das Flag innodb_flush_log_at_trx_commit wirksam ist.

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.

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

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.

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.

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 mit Verzögerung neu, wenn die Replikation hinter einem akzeptablen Zeitraum zurückbleibt.

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 folgende 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 keine maximale akzeptable Replikationsverzögerung 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 Replikatgruppen mit Verzögerung 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 zur Instanz aufrufen beschrieben werden.

Anhand dieser Informationen können Sie entscheiden, ob Sie den von Ihnen angegebenen akzeptablen 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 Blattreplikate neu, um die Replikationskonsistenz aufrechtzuerhalten.
• Für das Neuerstellen eines regionenübergreifenden Replikats fallen zusätzliche Kosten an.
• In der Google Cloud -Konsole können Sie die Neuerstellung von verzögerten Replikaten nicht aktivieren.

Wie geht es weiter?

• Replikate für die regionale Migration oder Notfallwiederherstellung hochstufen