Lesereplikate verwalten

Auf dieser Seite wird beschrieben, wie Lesereplikate verwaltet werden. Diese Vorgänge umfassen das Deaktivieren und Aktivieren der Replikation, das Hochstufen eines Replikats, das Konfigurieren der parallelen Replikation und das Prüfen des Replikationsstatus.

Weitere Informationen zur Funktionsweise von Replikaten 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 erneute Aktivieren der Replikation wird die Replikatinstanz nicht 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. Auf dem deaktivierten Replikat können Sie die Replikation wieder aktivieren, das Replikat löschen oder es zu einer eigenständigen Instanz hochstufen.

So deaktivieren Sie die Replikation:

Console

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Wählen 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 Version 1

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 Anfragedaten:

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

HTTP-Methode und URL: 

PATCH https://sqladmin.googleapis.com/v1/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:

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 Anfragedaten:

  • 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. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

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

gcloud

gcloud sql instances patch REPLICA_NAME \
--enable-database-replication

REST Version 1

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 Anfragedaten:

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

HTTP-Methode und URL: 

PATCH https://sqladmin.googleapis.com/v1/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:

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 Anfragedaten:

  • 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.

Beim Hochstufen werden Lesereplikate automatisch mit Sicherungen konfiguriert. Sie werden jedoch nicht automatisch als Hochverfügbarkeitsinstanzen konfiguriert. Allerdings können Sie Hochverfügbarkeit nach dem Hochstufen des Replikats wie bei jeder Nicht-Replikatinstanz aktivieren. Die Konfiguration eines Lesereplikats für Hochverfügbarkeit erfolgt auf die gleiche Weise wie für eine primäre Instanz. Mehr über das Konfigurieren von Instanzen für Hochverfügbarkeit erfahren

Bevor Sie ein Lesereplikat hochstufen, sofern die primäre Instanz noch verfügbar ist und für Clients ausgeführt wird, sollten Sie Folgendes tun:

  1. Beenden Sie alle Schreibvorgänge an die primäre Instanz.
  2. Prüfen Sie den Replikationsstatus des Replikats. Folgen Sie dazu der Anleitung auf dem Tab MySQL-Client.
  3. 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 einer 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. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Wählen Sie eine Replikatinstanz, indem Sie auf den Namen klicken.
  3. Klicken Sie auf Replikat heraufstufen.
  4. Klicken Sie auf OK.

gcloud

gcloud sql instances promote-replica REPLICA_NAME

REST Version 1

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 Anfragedaten:

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

HTTP-Methode und URL:

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

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

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

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 Anfragedaten:

  • 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 eine JSON-Antwort ähnlich wie diese 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) Standardwert für MySQL 8.0 und höher
replica_parallel_workers 0-1024 0 0 (MySQL 8.0.26 und früher)
4 (MySQL 8.0.27 und höher)
replica_parallel_type DATABASE, LOGICAL_CLOCK DATABASE DATABASE (MySQL 8.0.26 und früher)
LOGICAL_CLOCK (MySQL 8.0.27 und höher)
replica_preserve_commit_order ON, OFF OFF OFF (MySQL 8.0.26 und früher)
ON (MySQL 8.0.27 und höher)
replica_pending_jobs_size_max 1024-1GB 16MB 128 MB

Das Flag replica_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 replica_preserve_commit_order=1 ist Folgendes erforderlich:

Das Flag replica_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) MySQL 8.4 (Standardwert)
binlog_transaction_dependency_history_size 1-1000000 25.000 25.000 25.000
binlog_transaction_dependency_tracking COMMIT_ORDER, WRITESET, WRITESET_SESSION COMMIT_ORDER WRITESET – (in MySQL 8.4 eingestellt)
transaction_write_set_extraction OFF, MURMUR32, XXHASH64 OFF XXHASH64 – (in MySQL 8.4 eingestellt)

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 prü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 die gcloud CLI verwenden, erhalten Sie eine kurze Zusammenfassung der Replikationskonfiguration.

Bevor Sie den Replikationsstatus einer Cloud SQL-Replikatinstanz prüfen, rufen Sie mit dem Befehl
gcloud sql instances describe den Status der Instanz auf. Sie können so feststellen, ob die Replikation für die Replikatinstanz aktiviert ist.

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.

Bei kaskadierenden Replikaten wird jedes primäre Replikatpaar separat überwacht und es gibt keinen einzelnen Messwert, der die End-to-End-Verzögerung (Primär-zu-Replikat) verursacht.

Dieser Messwert gibt den Wert von Seconds_Behind_Master an, wenn SHOW REPLICA STATUS auf dem Replikat ausgeführt wird. Weitere Informationen finden Sie im MySQL-Referenzhandbuch unter Replikationsstatus prüfen.
Netzwerkverzögerung
(cloudsql.googleapis.com/database/replication/network_lag)

Die Zeit in Sekunden, die vom Schreiben des binlogs in der primären Datenbank bis zum Erreichen des E/A-Threads in der Replik vergeht.

Wenn "network_lag" null oder vernachlässigbar ist, aber "replica_lag" hoch ist, weist dies darauf hin, dass der SQL-Thread Replikationsänderungen nicht schnell genug anwenden kann.
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 REPLICA 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 REPLICA 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 in der Google Cloud Console die Seite Monitoring auf.

    Zu Monitoring

  2. Wählen Sie den Tab Dashboards aus.
  3. Klicken Sie auf Dashboard erstellen.
  4. Geben Sie einen Namen für das Dashboard ein und klicken Sie auf „OK“.
  5. Klicken Sie 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 REPLICA 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

Problem Fehlerbehebung
Beim Erstellen hat das Lesereplikat nicht repliziert. Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler. Prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.
Lesereplikat kann nicht erstellt werden – invalidFlagValue-Fehler 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.

Prüfen Sie als Erstes, ob der Wert des Flags max_connections größer oder gleich dem Wert auf der primären Instanz 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. Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler. 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 ist voll. Das Laufwerk der primären Instanz kann während der Replikaterstellung zu voll werden. Bearbeiten Sie die primäre Instanz, um sie auf ein größeres Laufwerk zu aktualisieren.
Die Replikatinstanz verwendet zu viel Arbeitsspeicher. 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.

Starten Sie die Replikatinstanz neu, um den temporären Speicherplatz freizugeben.
Replikation gestoppt. Das maximale Speicherlimit wurde erreicht und die automatische Speichererweiterung ist nicht aktiviert.

Bearbeiten Sie die Instanz, um automatic storage increase zu aktivieren.
Replikationsverzögerung ist durchgehend hoch. 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.

Hier einige mögliche Lösungen:
Die Replikationsverzögerung steigt plötzlich stark an. Dies wird durch lang andauernde Transaktionen verursacht. Wenn ein Commit einer Transaktion (einzelne oder mehrere Anweisungen) auf der Quellinstanz durchgeführt wird, wird die Startzeit der Transaktion im binären Log aufgezeichnet. Wenn das Replikat dieses binlog-Ereignis empfängt, vergleicht es den Zeitstempel mit dem aktuellen Zeitstempel, um die Replikationsverzögerung zu berechnen. Eine lang andauernde Transaktion in der Quelle würde daher zu einer sofortigen großen Replikationsverzögerung auf dem Replikat führen. Wenn die Menge der Zeilenänderungen in der Transaktion groß ist, würde das Replikat auch viel Zeit für die Ausführung benötigen. Während der Zeit erhöht sich die Replikationsverzögerung. Sobald das Replikat diese Transaktion abgeschlossen hat, hängt die Aufholphase von der Schreibarbeitslast auf der Quelle und der Verarbeitungsgeschwindigkeit des Replikats ab.

So vermeiden Sie lange Transaktionen z. B.:

  • Teilen Sie die Transaktion in mehrere kleine Transaktionen auf
  • Teilen Sie eine einzelne große Schreibabfrage in kleinere Batches auf
  • Versuchen Sie, lange SELECT-Abfragen von einer mit DML-Daten gemischten Transaktion zu trennen
Das Ändern der Flags für die parallele Replikation führt zu einem Fehler. Für mindestens eines dieser Flags wurde ein falscher Wert festgelegt.

Legen Sie in der primären Instanz, die die Fehlermeldung anzeigt, die Flags für die parallele Replikation fest:

  1. Ändern Sie die Flags binlog_transaction_dependency_tracking und transaction_write_set_extraction:
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. Fügen Sie das Flag slave_pending_jobs_size_max hinzu:

    slave_pending_jobs_size_max=33554432

  3. Ändern Sie das Flag transaction_write_set_extraction:

    transaction_write_set_extraction=XXHASH64

  4. Ändern Sie das Flag binlog_transaction_dependency_tracking:

    binlog_transaction_dependency_tracking=WRITESET
Die Replikaterstellung schlägt bei Zeitüberschreitung fehl. Langlaufende Transaktionen ohne Commit auf der primären Instanz können dazu führen, dass die Lesereplikaterstellung fehlschlägt.

Erstellen Sie das Replikat neu, nachdem alle laufenden Abfragen beendet sind.

Nächste Schritte