Fallback auf MySQL ausführen

In dieser Anleitung wird beschrieben, wie Sie ein Fallback und ein Rollback der Notfallwiederherstellung von Cloud Spanner zurück zu Ihren MySQL-Quellinstanzen durchführen.

Wenn nach der Umstellung auf Cloud Spanner unerwartete Leistungseinbußen, nicht wiederherstellbare Anwendungsfehler oder kritische funktionale Blockaden auftreten, verwenden Sie die Verfahren in den folgenden Abschnitten, um ein Rollback zu Ihren primären MySQL-Instanzen durchzuführen:

Hinweis

Prüfen Sie vor dem Starten der Fallback-Verfahren die folgenden Voraussetzungen:

  1. Aktive umgekehrte Replikation: Prüfen Sie, ob die Dataflow-Pipeline für die umgekehrte Replikation (Spanner_to_SourceDb) ausgeführt wird und aktiv Spanner-Änderungsstreams im Filtermodus forward_migration verarbeitet. Weitere Informationen finden Sie unter Fallback zu MySQL konfigurieren.
  2. Verfügbarkeit der MySQL-Quelle: Prüfen Sie, ob Ihre MySQL-Quelldatenbank online und von Dataflow aus erreichbar ist und Schreibverbindungen akzeptieren kann.
  3. Wartungsfenster: Informieren Sie die Stakeholder darüber, dass ein geplantes Ausfallfenster erforderlich ist, während Schreibvorgänge in Cloud Spanner pausiert und die umgekehrte Replikation geleert wird.

Erforderliche Rollen

Schreibvorgänge in Cloud Spanner pausieren

  1. Pausieren Sie alle Datenbankschreibvorgänge in Cloud Spanner in Ihrer Anwendung.
  2. Warten Sie, bis aktive Transaktionen in Cloud Spanner vollständig abgeschlossen und geleert wurden.

Umgekehrte Replikation leeren

In den folgenden Abschnitten wird beschrieben, wie Sie prüfen, ob alle Änderungen, die nach der Umstellung in Cloud Spanner vorgenommen wurden, in MySQL repliziert werden, bevor Sie die Schreibvorgänge der Anwendung umstellen.

Replikationsverzögerung überwachen

Verfolgen Sie die Replikationsverzögerung, um zu prüfen, ob alle laufenden Änderungen in MySQL geschrieben werden:

  1. Rufen Sie in der Google Cloud Console die Seite Jobdetails für Ihren Dataflow-Job für die umgekehrte Replikation auf.
  2. Prüfen Sie auf dem Tab Benutzerdefinierte Messwerte den Nutzerzähler replication_lag_in_seconds_LOGICAL_SHARD_NAME_MAX. Weitere Informationen finden Sie unter Fallback zu MySQL konfigurieren.
  3. Warten Sie, bis der Zählerwert 0 erreicht.

Alternativ können Sie den Nutzerzähler in Metrics Explorer mit der Monitoring Query Language (MQL) abfragen: 

fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'replication_lag_insecondsLOGICAL_SHARD_NAME_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
Ersetzen Sie Folgendes: * JOB_ID: die ID Ihres Dataflow-Jobs für die umgekehrte Replikation. * LOGICAL_SHARD_NAME: der logische Shard-Name der für Ihre Quelldatenbank konfiguriert wurde.

MySQL-Schreibaktivität prüfen

Prüfen Sie, ob die Schreibvorgänge der umgekehrten Replikation in Ihrer Quelldatenbank abgeschlossen sind:

  1. Prüfen Sie in Ihrer primären MySQL-Quelldatenbank die aktiven Abfragen und die Messwerte für die Datenbankverbindung.
  2. Prüfen Sie, ob der Schreibtraffic aus der Pipeline für die umgekehrte Replikation beendet wurde.

Sauberen DLQ-Status prüfen

Prüfen Sie die Warteschlangen für unzustellbare Nachrichten (Dead-Letter Queues, DLQs), um zu prüfen, ob bei der umgekehrten Replikation nicht behandelte Fehler aufgetreten sind:

  1. Rufen Sie in der Google Cloud Console die Seite Jobdetails für Ihren Dataflow-Job für die umgekehrte Replikation auf. Prüfen Sie auf dem Tab Benutzerdefinierte Messwerte den Nutzerzähler severe_error_count.

  2. Prüfen Sie sowohl die DLQ-Verzeichnisse für schwerwiegende Fehler als auch für Wiederholungen der umgekehrten Replikation in Cloud Storage (z. B. gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/ und gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/retry/).

    Sie können den Inhalt des DLQ-Verzeichnisses für schwerwiegende Fehler mit der gcloud CLI auflisten:

    gcloud storage ls gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/

    Ersetzen Sie Folgendes:

    • MIGRATION_BUCKET: der Name Ihres Cloud Storage-Bucket.
    • ENV: der Name Ihrer Bereitstellungsumgebung (z. B. prod).
    • SERVICE: der Name Ihrer Anwendung oder Ihres Dienstes.
    • DB_SCHEMA: der Name Ihres Datenbankschemas.

  3. Prüfen Sie, ob die DLQ-Verzeichnisse vollständig leer sind.

  4. Wenn Fehlerdateien vorhanden sind, beheben Sie die zugrunde liegenden Probleme und spielen Sie die fehlgeschlagenen Datensätze noch einmal ab, bevor Sie fortfahren. Weitere Informationen finden Sie unter Fehler bei der umgekehrten Replikation überwachen und beheben.

Vorwärts-CDC-Streaming fortsetzen

Wenn Sie die Vorwärtsmigration zu Cloud Spanner in Zukunft fortsetzen möchten, setzen Sie den Vorwärts-Datastream-Stream fort:

  1. Rufen Sie in der Google Cloud Console die Seite Streamdetails für Ihren Stream auf.
  2. Klicken Sie auf Fortsetzen und warten Sie, bis sich der Streamstatus in RUNNING ändert. Weitere Informationen finden Sie unter MySQL-Daten migrieren.

Alternativ können Sie den Stream mit der gcloud CLI fortsetzen. Führen Sie dazu den Befehl gcloud datastream streams resume aus:

gcloud datastream streams resume STREAM_ID \
    --location=LOCATION

Ersetzen Sie Folgendes:

  • STREAM_ID: die ID Ihres Datastream-Streams.
  • LOCATION: die Google Cloud Region, in der sich Ihr Stream befindet.

Schreibvorgänge zu MySQL umleiten

  1. Aktualisieren Sie die Anwendungskonfiguration und die Datenbankverbindungsstrings, um auf Ihre primären MySQL-Quelldatenbankinstanzen zu verweisen.
  2. Starten Sie die Anwendungsdienste und setzen Sie den Live-Lese- und -Schreibtraffic für MySQL fort.
  3. Prüfen Sie, ob die Lese- und Schreibvorgänge der Anwendung in der MySQL-Datenbank erfolgreich ausgeführt werden.

Nächste Schritte