Fallback für MySQL konfigurieren

Auf dieser Seite wird beschrieben, wie Sie mit der umgekehrten Replikation ein Failover für MySQL einrichten. Mit Fallback ist ein Notfallplan gemeint, mit dem Sie zu Ihrer MySQL-Quelldatenbank zurückkehren können, falls Probleme mit Spanner auftreten.

Die umgekehrte Replikation ist nützlich, wenn unerwartete Probleme auftreten und Sie mit minimalen Unterbrechungen des Dienstes zur ursprünglichen MySQL-Datenbank zurückkehren müssen. Mit der umgekehrten Replikation können Sie ein Fallback durchführen, indem Sie Daten, die in Spanner geschrieben wurden, in Ihre MySQL-Quelldatenbank replizieren. So wird sichergestellt, dass beide Datenbanken letztendlich konsistent sind.

Der Ablauf der umgekehrten Replikation umfasst die folgenden Schritte, die von der Spanner_to_SourceDb-Dataflow-Vorlage ausgeführt werden:

  1. Änderungen aus Spanner mit Spanner-Änderungsstreams lesen.

  2. Prüfen Sie, ob der Filtermodus forward_migration ist.

  3. Mit dem Spanner-Migrationstool können Sie Spanner-Daten so transformieren, dass sie mit dem Schema Ihrer Quelldatenbank kompatibel sind. Weitere Informationen finden Sie unter Benutzerdefinierte Transformation.

  4. Prüfen Sie, ob die Quelldatenbank bereits neuere Daten für den angegebenen Primärschlüssel enthält.

  5. Schreiben Sie die Daten in Ihre Quelldatenbank.

Spanner_to_SourceDb-Dataflow-Vorlage verwenden

Das Dataflow-Template sorgt für Konsistenz auf Primärschlüsselebene. Mit der Vorlage werden Metadatentabellen, sogenannte Schatten-Tabellen, in Spanner erstellt, die den Commit-Zeitstempel der letzten Schreibtransaktion für den Shard für diese bestimmte Tabelle enthalten.

Der Schreibvorgang ist bis zum Commit-Zeitstempel des Primärschlüssels konsistent.

Sie können den Dataflow-Job, der die Reverse-Replikation ausführt, so konfigurieren, dass er in einem der folgenden Modi ausgeführt wird:

  • Regulär: Dies ist der Standardmodus. Der Dataflow-Job liest Ereignisse aus Spanner-Änderungsstreams, konvertiert sie in Datentypen, die mit dem Quelldatenbankschema kompatibel sind, und wendet sie auf die Quelldatenbank an. Der Job wiederholt Fehler automatisch. Nachdem alle Wiederholungsversuche fehlgeschlagen sind, werden die Fehler in den Ordner severe des DLQ-Verzeichnisses (Dead-Letter-Warteschlange) im Cloud Storage-Bucket verschoben. Außerdem werden alle dauerhaften Fehler in den Ordner severe verschoben.

  • RetryDLQ: In diesem Modus liest der Dataflow-Job Ereignisse aus dem Ordner severe der Dead-Letter-Warteschlange und versucht, sie noch einmal zu verarbeiten. Führen Sie diesen Modus aus, nachdem Sie alle dauerhaften Fehler behoben haben. In diesem Modus werden nur Daten aus der DLQ gelesen, nicht aus den Spanner-Änderungsstreams. Wenn Datensätze, die aus dem Ordner severe verarbeitet wurden, in den Ordner retry verschoben werden, werden sie im Job noch einmal verarbeitet.

Hinweise

  • Sorgen Sie für eine Netzwerkverbindung zwischen Ihrer MySQL-Quelldatenbank und IhremGoogle Cloud -Projekt, in dem Ihre Dataflow-Jobs ausgeführt werden.

  • Setzen Sie die IP-Adressen der Dataflow-Worker auf die Zulassungsliste Ihrer MySQL-Zielinstanz.

  • Prüfen Sie, ob die MySQL-Anmeldedaten in source shards file richtig angegeben sind.

  • Prüfen Sie, ob Ihre MySQL-Instanz online ist und ausgeführt wird.

  • Prüfen Sie, ob der MySQL-Nutzer die Berechtigungen INSERT, UPDATE und DELETE für die MySQL-Datenbank hat.

  • Prüfen Sie, ob Sie die erforderlichen IAM-Berechtigungen zum Ausführen einer Dataflow-Flex-Vorlage haben. Weitere Informationen finden Sie unter Flex-Vorlage erstellen und ausführen.

  • Prüfen Sie, ob der Port 12345 für die Kommunikation zwischen den Dataflow-Worker-VMs geöffnet ist.

Erforderliche Rollen

  • Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für die Instanz zuzuweisen, damit Sie die nötigen Berechtigungen zum Starten der umgekehrten Replikation haben:

  • Damit das Compute Engine-Dienstkonto die erforderlichen Berechtigungen zum Starten der umgekehrten Replikation hat, bitten Sie Ihren Administrator, dem Compute Engine-Dienstkonto die folgenden IAM-Rollen für die Instanz zuzuweisen:

Rückwärtsreplikation ausführen

So führen Sie die umgekehrte Replikation aus:

  1. Laden Sie die Sitzungsdatei in den Cloud Storage-Bucket hoch.

  2. Erstellen Sie eine Pub/Sub-Benachrichtigung für den Ordner retry des DLQ-Verzeichnisses. Dazu erstellen Sie ein Pub/Sub-Thema und ein Pub/Sub-Abo für dieses Thema.

  3. Erstellen Sie die Dataflow-Vorlage und stellen Sie sie bereit. Weitere Informationen finden Sie unter Vorlage erstellen.

  4. Führen Sie das Dataflow-Template für die umgekehrte Replikation mit dem folgenden Google Cloud CLI-Befehl aus:

      gcloud dataflow flex-template run "spanner-to-sourcedb-job" \
  --project "PROJECT" \
  --region "REGION" \
  --template-file-gcs-location "TEMPLATE_SPEC_GCSPATH" \
  --parameters "changeStreamName=CHANGE_STREAM_NAME" \
  --parameters "instanceId=INSTANCE_ID" \
  --parameters "databaseId=DATABASE_ID" \
  --parameters "spannerProjectId=SPANNER_PROJECT_ID" \
  --parameters "metadataInstance=METADATA_INSTANCE" \
  --parameters "metadataDatabase=METADATA_DATABASE" \
  --parameters "sourceShardsFilePath=SOURCE_SHARDS_FILE_PATH" \
  --parameters "startTimestamp=START_TIMESTAMP" \
  --parameters "endTimestamp=END_TIMESTAMP" \
  --parameters "shadowTablePrefix=SHADOW_TABLE_PREFIX" \
  [--parameters "sessionFilePath=SESSION_FILE_PATH"] \
  [--parameters "filtrationMode=FILTRATION_MODE"] \
  [--parameters "shardingCustomJarPath=SHARDING_CUSTOM_JAR_PATH"] \
  [--parameters "shardingCustomClassName=SHARDING_CUSTOM_CLASS_NAME"] \
  [--parameters "shardingCustomParameters=SHARDING_CUSTOM_PARAMETERS"] \
  [--parameters "sourceDbTimezoneOffset=SOURCE_DB_TIMEZONE_OFFSET"] \
  [--parameters "dlqGcsPubSubSubscription=DLQ_GCS_PUB_SUB_SUBSCRIPTION"] \
  [--parameters "skipDirectoryName=SKIP_DIRECTORY_NAME"] \
  [--parameters "maxShardConnections=MAX_SHARD_CONNECTIONS"] \
  [--parameters "deadLetterQueueDirectory=DEAD_LETTER_QUEUE_DIRECTORY"] \
  [--parameters "dlqMaxRetryCount=DLQ_MAX_RETRY_COUNT"] \
  [--parameters "runMode=RUN_MODE"] \
  [--parameters "dlqRetryMinutes=DLQ_RETRY_MINUTES"] \
  [--parameters "sourceType=SOURCE_TYPE"] \
  [--parameters "transformationJarPath=TRANSFORMATION_JAR_PATH"] \
  [--parameters "transformationClassName=TRANSFORMATION_CLASS_NAME"] \
  [--parameters "transformationCustomParameters=TRANSFORMATION_CUSTOM_PARAMETERS"] \
  [--parameters "filterEventsDirectoryName=FILTER_EVENTS_DIRECTORY_NAME"]

    Die erforderlichen Variablen werden in der folgenden Liste beschrieben:

    • project: die Google Cloud Projekt-ID.
    • region: die Google Cloud Region.
    • template-file-gcs-location: Der Pfad zur Cloud Storage-Datei, in der Sie die Dataflow-Vorlage bereitgestellt haben.
    • changeStreamName: Der Name des Spanner-Änderungsstreams, aus dem der Job liest.
    • instanceId: Die Spanner-Instanz-ID.
    • databaseId: die Spanner-Datenbank-ID.
    • spannerProjectId: die Projekt-ID, in der sich Ihre Cloud Spanner-Instanzen befinden.
    • metadataInstance: Die Instanz, in der die Metadaten gespeichert werden, die der Connector verwendet, um die Nutzung von Änderungsstream-API-Daten zu steuern.
    • metadataDatabase: Die Datenbank, in der die Metadaten gespeichert werden, mit denen der Connector die Nutzung von Änderungsstream-API-Daten steuert.
    • sourceShardsFilePath: der Pfad zur Cloud Storage-Datei, die die Verbindungsprofilinformationen für die Quell-Shards enthält.

    Die optionalen Variablen werden in der folgenden Liste beschrieben:

    • startTimestamp: Der Zeitstempel, ab dem Änderungen gelesen werden sollen. Die Standardeinstellung ist leer.
    • endTimestamp: Der Zeitstempel, bis zu dem Änderungen gelesen werden sollen. Wenn Sie keinen Zeitstempel angeben, werden Änderungen unbegrenzt gelesen. Die Standardeinstellung ist leer.
    • shadowTablePrefix: Das Präfix zum Benennen von Schattentabellen. Die Standardeinstellung ist shadow_.
    • sessionFilePath: Der Pfad zur Sitzungsdatei in Cloud Storage, die Zuordnungsinformationen aus dem Spanner-Migrations-Tool enthält.
    • filtrationMode: Der Modus, der bestimmt, wie Datensätze anhand von Kriterien gefiltert werden. Unterstützte Modi sind none oder forward_migration.
    • shardingCustomJarPath: Der Speicherort (Pfad) in Cloud Storage der benutzerdefinierten JAR-Datei, die die Logik zum Abrufen der Shard-ID enthält. Die Standardeinstellung ist leer.
    • shardingCustomClassName: Der voll qualifizierte Klassenname mit der benutzerdefinierten Shard-ID-Implementierung. Dieses Feld ist erforderlich, wenn shardingCustomJarPath angegeben ist. Die Standardeinstellung ist leer.
    • shardingCustomParameters: Ein String mit allen benutzerdefinierten Parametern, die an die benutzerdefinierte Sharding-Klasse übergeben werden sollen. Die Standardeinstellung ist leer.
    • sourceDbTimezoneOffset: der Zeitzonenversatz von UTC für die Quelldatenbank. Beispiel: +10:00. Standard: +00:00.
    • dlqGcsPubSubSubscription: Das Pub/Sub-Abo, das in einer Cloud Storage-Benachrichtigungsrichtlinie für das DLQ-Wiederholverzeichnis verwendet wird, wenn der regular-Modus genutzt wird. Geben Sie den Namen im Format projects/<PROJECT_ID>/subscriptions/<SUBSCRIPTION_ID> an. Wenn Sie diesen Parameter festlegen, werden deadLetterQueueDirectory und dlqRetryMinutes ignoriert.
    • skipDirectoryName: Das Verzeichnis, in das das System Datensätze schreibt, die bei der umgekehrten Replikation übersprungen werden. Standardeinstellung: skip
    • maxShardConnections: Die maximale Anzahl von Verbindungen, die pro Shard zulässig sind. Standard: 10.000.
    • deadLetterQueueDirectory: Der Pfad zum Speichern der DLQ-Ausgabe. Der Standardwert ist ein Verzeichnis unter dem temporären Speicherort des Dataflow-Jobs.
    • dlqMaxRetryCount: Die maximale Anzahl der Wiederholungsversuche über die DLQ bei vorübergehenden Fehlern. Standardwert: 500
    • runMode: Der Ausführungsmodustyp. Optionen sind regular oder retryDLQ. Verwenden Sie retryDLQ, um nur die schwerwiegenden DLQ-Einträge noch einmal zu versuchen. Standard: regular.
    • dlqRetryMinutes: Die Anzahl der Minuten zwischen DLQ-Wiederholungsversuchen. Der Standardwert ist 10.
    • sourceType: Der Typ der Quelldatenbank, in die die Replikation rückgängig gemacht werden soll. Standard: mysql.
    • transformationJarPath: Der Speicherort (Pfad) in Cloud Storage der benutzerdefinierten JAR-Datei, die die benutzerdefinierte Transformationslogik für die Verarbeitung von Datensätzen bei der Rückwärtsreplikation enthält. Die Standardeinstellung ist leer.
    • transformationClassName: Der vollständig qualifizierte Klassenname mit der benutzerdefinierten Transformationslogik. Dieses Feld ist erforderlich, wenn transformationJarPath angegeben ist. Die Standardeinstellung ist leer.
    • transformationCustomParameters: Ein String mit allen benutzerdefinierten Parametern, die an die benutzerdefinierte Transformationsklasse übergeben werden sollen. Die Standardeinstellung ist leer.
    • filterEventsDirectoryName: Das Verzeichnis, in das das System Datensätze schreibt, die bei der umgekehrten Replikation übersprungen werden. Standardeinstellung: skip

Nächste Schritte