Umstellung von MySQL durchführen

In dieser Anleitung wird beschrieben, wie Sie die Umstellung einer Live-Datenbankmigration von einer MySQL-Quellinstanz zu einer Spanner-Datenbank mit Datastream und Dataflow durchführen.

Hinweis

Bevor Sie die Umstellung durchführen, prüfen Sie, ob Sie die folgenden Aufgaben im Rahmen Ihrer Live-Datenmigration abgeschlossen haben:

  1. Schema-Migration: Stellen Sie Ihr Schema in Spanner bereit. Weitere Informationen finden Sie unter Schema aus MySQL migrieren.
  2. Backfill-Migration: Schließen Sie die erste Datenmigration mit dem Dataflow-Job für die Backfill-Migration ab. Weitere Informationen finden Sie unter Backfill-Migration durchführen.
  3. Aktive CDC-Replikation: Prüfen Sie, ob die kontinuierliche CDC-Replikation (Change Data Capture) aktiv und fehlerfrei ist:
    • Der Datastream-Stream liest aktiv Änderungsereignisse aus Ihrer MySQL-Quelldatenbank und schreibt sie in den Cloud Storage-Bucket.
    • Cloud Storage-Bucket-Benachrichtigungen veröffentlichen Ereignisse zur Objekterstellung im Pub/Sub-Thema.
    • Der Streaming-Dataflow-Job (Cloud_Datastream_to_Spanner) verwendet das Pub/Sub-Abo und schreibt Änderungen mit einer Replikationsverzögerung von weniger als einer Sekunde oder einer vernachlässigbaren Verzögerung in Spanner. Weitere Informationen finden Sie unter MySQL-Daten migrieren.
  4. Erste Datenvalidierung: Führen Sie Datenvalidierungsprüfungen durch, um die Daten konsistenz zwischen der MySQL-Quellinstanz und dem Spanner-Ziel zu prüfen. Weitere Informationen finden Sie unter Datenmigration validieren.
  5. Status der Dead-Letter-Warteschlange (DLQ) bereinigen: Prüfen Sie, ob das Verzeichnis für schwerwiegende Fehler der Vorwärts replikation in Cloud Storage (z. B. gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) vollständig leer ist. Wenn schwerwiegende Fehler vorhanden sind, beheben Sie die zugrunde liegenden Probleme und spielen Sie alle fehlgeschlagenen Änderungsereignisse mit einem retryDLQ-Batchjob noch einmal ab, bevor Sie mit der Umstellung beginnen. Weitere Informationen finden Sie unter CDC-DLQ-Fehler beobachten und beheben.
  6. Einrichtung der umgekehrten Replikation (Fallback-Bereitschaft): Wenn Sie einen Notfall-Fallback-Pfad benötigen, richten Sie eine aktive Pipeline für die umgekehrte Replikation von Spanner zurück zu Ihrer MySQL-Quelldatenbank ein. Weitere Informationen finden Sie unter Fallback zu MySQL konfigurieren.

Erforderliche Rollen

Umstellung durchführen

In den folgenden Abschnitten wird beschrieben, wie Sie die Schreibpipeline per Drain beenden und prüfen, ob alle Quelländerungen in Spanner repliziert werden, bevor Sie die Anwendungsschreibvorgänge umstellen.

Pipeline-Status und DLQ-Status prüfen

Bevor Sie den Schreibtraffic der Anwendung pausieren oder eine Ausfallzeit einleiten, prüfen Sie, ob sich in der DLQ Ihrer Vorwärtsreplikationspipeline keine nicht verarbeiteten Änderungsereignisse befinden:

  1. Rufen Sie in der Google Cloud Console die Seite Jobdetails für Ihre Streaming Dataflow-Pipeline auf.
  2. Prüfen Sie auf dem Tab Benutzerdefinierte Messwerte den benutzerdefinierten Zähler Total permanent errors.

  3. Wenn dieser Zähler größer als 0 ist, prüfen Sie das Verzeichnis für schwerwiegende Fehler in Cloud Storage (z. B. gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) und prüfen Sie, ob das Verzeichnis leer ist.

Anwendungsschreibvorgänge pausieren

  1. Pausieren Sie den gesamten Schreibtraffic der Datenbank für Ihre Anwendung.
  2. Warten Sie, bis aktive Transaktionen in den primären MySQL-Quellinstanzen vollständig abgeschlossen und per Drain beendet wurden.

Datastream verfolgen und pausieren

  1. Rufen Sie in der Google Cloud Console die Streamdetails Seite für Ihren Stream auf.
  2. Prüfen Sie auf dem Tab Monitoring das Diagramm Datenaktualität (Cloud Monitoring-Messwerttyp: datastream.googleapis.com/stream/freshness). Warten Sie, bis der Messwert auf 0 sinkt. Das bedeutet, dass Datastream alle Änderungen der Quelldatenbank bis zu dem Zeitpunkt erfasst und verarbeitet hat, an dem die Schreibvorgänge pausiert wurden. Weitere Informationen finden Sie unter Stream beobachten.

  3. Prüfen Sie, ob keine Replikationsereignisse durch den Stream laufen. Prüfen Sie auf dem Tab Monitoring das Diagramm Durchsatz (Monitoring-Messwerttyp: datastream.googleapis.com/stream/event_count) und prüfen Sie, ob die Ereignisrate 0 ist.

    Alternativ können Sie die Anzahl der Ereignisse programmatisch mit dem Metrics Explorer abfragen. Verwenden Sie dazu die Monitoring Query Language (MQL): 

    fetch datastream.googleapis.com/Stream
| metric 'datastream.googleapis.com/stream/event_count'
| filter (resource.stream_id == 'STREAM_ID')
| align rate(1m)
| group_by [], [value_event_count_sum: sum(value.event_count)]
| every 1m
     Ersetzen Sie STREAM_ID durch die ID Ihres Streams.

    Prüfen Sie, ob für diesen Messwert für mindestens zwei aufeinanderfolgende Aggregationszeiträume 0 gemeldet wird.

  4. Pausieren Sie Ihren Datastream-Stream mit der Google Cloud Console oder der API und warten Sie, bis sich der Streamstatus in PAUSEDändert.

Warten, bis die Änderungsdaten, die gerade verarbeitet werden, per Drain beendet wurden

  1. Rufen Sie in der Google Cloud Console die Streamdetails Seite für Ihren Stream auf.
  2. Prüfen Sie auf dem Tab Monitoring das Diagramm Systemlatenz (Monitoring-Messwerttyp: datastream.googleapis.com/stream/system_latencies).
  3. Notieren Sie sich den Latenzwert des 99. Perzentils (P99) und warten Sie mindestens zweimal die P99-Systemlatenz plus 30 Sekunden, nachdem Sie Ihren Stream pausiert haben. Diese Wartezeit trägt dazu bei, dass alle Änderungsdatendateien, die vor dem Pausieren generiert wurden, sicher in Cloud Storage geschrieben werden und dass die Ereignisse zur Objekterstellung in Pub/Sub veröffentlicht werden.
  4. Prüfen Sie, ob Ihr Streaming-Dataflow-Job alle ausstehenden Änderungsereignisse verarbeitet hat. Rufen Sie in der Google Cloud Console die Seite Abos von Pub/Sub auf und wählen Sie dann das Abo aus, das bei der Einrichtung der CDC-Migration erstellt wurde.
  5. Prüfen Sie auf dem Tab Monitoring das Diagramm Anzahl der nicht bestätigten Nachrichten (Monitoring-Messwerttyp: pubsub.googleapis.com/subscription/num_undelivered_messages) und prüfen Sie, ob die Anzahl 0 ist.

Prüfen, ob die Replikation abgeschlossen ist

  1. Prüfen Sie, ob Ihre Streaming-Dataflow-Pipeline alle replizierten Änderungen geschrieben hat. Wählen Sie auf der Seite Jobdetails für Ihren Streamingjob den Tab Benutzerdefinierte Messwerte aus und prüfen Sie dann den benutzerdefinierten Zähler Replication lag total latency_MAX. Warten Sie, bis der Zählerwert 0 erreicht.

    Alternativ können Sie den benutzerdefinierten Zähler im Metrics Explorer mit MQL abfragen: 

    fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'Replication lag total latency_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
     Ersetzen Sie JOB_ID durch die ID Ihres Dataflow-Jobs.

  2. Prüfen Sie, ob die Schreibaktivität in der Spanner-Zieldatenbank beendet wurde. Wählen Sie auf der Seite Datenbankdetails für Ihre Zieldatenbank den Tab Monitoring aus und prüfen Sie das Diagramm Schreibdurchsatz (Monitoring-Messwerttyp: spanner.googleapis.com/transaction_stat/total/bytes_written_count). Prüfen Sie, ob der Schreibdurchsatz für mindestens zwei aufeinanderfolgende 1-Minuten-Aggregationszeiträume 0 ist.

  3. Führen Sie eine letzte Prüfung der DLQ für die Vorwärtsreplikation durch. Prüfen Sie die DLQ-Verzeichnisse für schwerwiegende Fehler und für Wiederholungen in Cloud Storage (z. B. gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/ und gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/retry/) und prüfen Sie, ob sie leer sind.

  4. Beenden Sie Ihren Streaming-Dataflow-Job per Drain:

    1. Rufen Sie in der Google Cloud Console die Seite Jobdetails für Ihren Streamingjob auf.
    2. Klicken Sie auf Job anhalten, wählen Sie Drain aus und klicken Sie dann auf Job anhalten.
    3. Warten Sie, bis sich der Jobstatus in Drained ändert. Weitere Informationen finden Sie unter Aktive Pipeline beenden.

  5. Führen Sie eine DLQ-Prüfung nach dem Drain durch: Nachdem sich der Jobstatus in Drained geändert hat, prüfen Sie die DLQ-Verzeichnisse für schwerwiegende Fehler und für Wiederholungen in Cloud Storage ein letztes Mal. Prüfen Sie, ob während des Drain-Vorgangs von Daten, die gerade verarbeitet wurden, neue Fehlerdateien aufgetreten sind. Wenn Dateien vorhanden sind, beheben Sie die Fehler und spielen Sie die Dateien noch einmal ab. Weitere Informationen finden Sie unter CDC-DLQ-Fehler beobachten und beheben.

Anwendungsumstellung durchführen

Stellen Sie die Datenbankverbindungen der Anwendung auf Spanner um und setzen Sie den Live-Lese- und -Schreibtraffic fort:

  1. Aktualisieren Sie die Anwendungskonfiguration oder die Datenbankverbindungsstrings, um auf Ihre Spanner-Datenbank zu verweisen.
  2. Starten Sie die Anwendungsdienste und prüfen Sie, ob der Live-Lese- und -Schreibtraffic erfolgreich in Spanner ausgeführt wird.
  3. Beobachten Sie Ihre Pipeline für die umgekehrte Replikation auf Fehler. Wenn ein Spanner-Schreibvorgang nicht zurück zu MySQL repliziert werden kann, speichert Dataflow den fehlgeschlagenen Datensatz in einem DLQ-Verzeichnis in Cloud Storage (z. B. gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/). Prüfen Sie diesen Pfad regelmäßig, um sicherzustellen, dass er leer bleibt. Wenn fehlgeschlagene Datensätze angezeigt werden, lesen Sie den Hilfeartikel Fehler bei der umgekehrten Replikation beobachten und beheben.

Nächste Schritte