Von MySQL zu Spanner migrieren

Auf dieser Seite finden Sie eine Übersicht zur Migration Ihrer Online Transactional Processing-Datenbank (OLTP) von MySQL zu Spanner. Der Migrationsprozess zu Spanner kann je nach Faktoren wie Datengröße, Ausfallzeitenanforderungen, Komplexität des Anwendungscodes, Fragmentierungsschema, benutzerdefinierten Funktionen sowie Failover- und Replikationsstrategien variieren.

Die Spanner-Migration ist in die folgenden Schritte unterteilt:

  1. Migration bewerten.
  2. Schema migrieren und alle SQL-Abfragen übersetzen.
  3. Anwendung migrieren, um Spanner zusätzlich zu MySQL zu verwenden.
  4. Beispieldaten laden und Leistung optimieren.
  5. Daten migrieren.
  6. Migration validieren.

Migration bewerten

Bei der Bewertung einer Migration von Ihrer MySQL-Quelldatenbank zu Spanner müssen Sie Ihre geschäftlichen, technischen, betrieblichen und finanziellen Anforderungen berücksichtigen. Weitere Informationen finden Sie unter Migration bewerten.

Schema migrieren

Sie konvertieren Ihr vorhandenes Schema mit dem Spanner Migrationstool in ein Spanner Schema.

Weitere Informationen finden Sie unter Schema von MySQL migrieren.

Anwendung migrieren, um Spanner zu verwenden

Spanner bietet eine Reihe von Clientbibliotheken für verschiedene Sprachen und die Möglichkeit, Daten mit Spanner-spezifischen API-Aufrufen sowie mit SQL-Abfragen und DML-Anweisungen (Data Modification Language) zu lesen und zu schreiben. Die Verwendung von API-Aufrufen kann für einige Abfragen schneller sein, z. B. für das direkte Lesen der Zeilen nach Schlüssel, da die SQL-Anweisung nicht übersetzt werden muss.

Spanner bietet einen JDBC-Treiber für Java-Anwendungen.

Im Rahmen des Migrationsprozesses müssen Funktionen, die in Spanner nicht verfügbar sind, wie bereits erwähnt in der Anwendung implementiert werden. Beispielsweise muss ein Trigger zum Überprüfen von Datenwerten und Aktualisieren einer zugehörigen Tabelle in der Anwendung mit einer Lese- oder Schreibtransaktion implementiert werden, um die vorhandene Zeile zu lesen, die Einschränkung zu überprüfen und dann die aktualisierten Zeilen in beide Tabellen zu schreiben.

Die Standardisolationsstufe von Transaktionen in Spanner ist die serialisierbare Isolation, die die externe Konsistenz Ihrer Daten gewährleistet. Spanner bietet auch die Isolation wiederholbarer Lesevorgänge. Wir empfehlen, die Isolationsstufe auf „Wiederholbarer Lesevorgang“ und die Nebenläufigkeitserkennung im Rahmen des Migrationsprozesses der Anwendung auf „Pessimistische Parallelität“ festzulegen, damit die Transaktionssemantik von Spanner weitgehend mit der Standardtransaktionssemantik von MySQL übereinstimmt. Eine Anleitung zum Festlegen der Isolationsstufe und der Parallelitäts steuerung in Ihrer Anwendung finden Sie unter Isolationsstufe „Wiederholbarer Lesevorgang“ verwenden und Parallelitätssteuerung konfigurieren.

Spanner bietet Lese- und Schreibtransaktionen sowie Transaktionen mit Lesezugriff. Außerdem können auf Lesetransaktionen Zeitstempelgrenzen angewendet werden, wobei Sie eine konsistente Version der Daten lesen:

  • zu einer genauen Zeit in der Vergangenheit (bis zu 1 Stunde zuvor),
  • in der Zukunft (der Lesevorgang wird bis zu dieser Zeit blockiert) oder
  • mit einer akzeptablen begrenzten Veralterung, die eine konsistente Darstellung bis zu einem früheren Zeitpunkt ausgibt. Hierbei muss nicht geprüft werden, ob spätere Daten auf einem anderen Replikat verfügbar sind. Dies kann Leistungsvorteile mit sich bringen, aber die Daten sind unter Umständen veraltet.

Beispieldaten in Spanner laden

Sie können Beispieldaten in Spanner laden, bevor Sie eine vollständige Datenmigration durchführen, um Schemas, Abfragen und Ihre Anwendung zu testen.

Mit dem BigQuery-Workflow für Reverse-ETL und der Google Cloud CLI können Sie eine kleine Menge an Daten im CSV-Dateiformat in Spanner laden.

Weitere Informationen finden Sie unter Beispieldaten laden.

Wenn Sie Ihre Daten von MySQL zu Spanner übertragen möchten, können Sie Ihre MySQL-Datenbank auch in ein portables Dateiformat wie XML exportieren und diese Daten dann mit Dataflow in Spanner importieren.

Daten zu Spanner migrieren

Nachdem Sie Ihr Spanner-Schema optimiert und Beispieldaten geladen haben, können Sie Ihre Daten in eine leere Spanner-Produktionsdatenbank verschieben.

Weitere Informationen finden Sie unter MySQL-Daten migrieren.

Datenmigration validieren

Während Daten in ihre Spanner-Datenbank gestreamt werden, können Sie regelmäßig einen Vergleich zwischen den Spanner- und den MySQL-Daten vornehmen, um sicherzustellen, dass die Daten konsistent sind. Sie können die Konsistenz prüfen. Dazu fragen Sie beide Datenquellen ab und vergleichen die Ergebnisse.

Mit Dataflow können Sie einen detaillierten Vergleich großer Datensätze durchführen, indem Sie die Transformation „Join“ verwenden. Diese Transformation prüft anhand der Schlüssel von zwei Datasets, ob die Werte übereinstimmen. Die übereinstimmenden Werte können dann verglichen werden. Sie können diese Überprüfung regelmäßig vornehmen, bis die Konsistenz Ihren Geschäftsanforderungen entspricht.

Weitere Informationen finden Sie unter Datenmigration validieren.

Fallback und Umstellung konfigurieren

Sie können Fallback und Umstellung für MySQL mit Reverse-Replikation einrichten. Durch die Konfiguration des Fallbacks haben Sie einen Notfallplan, um zu Ihrer MySQL-Quelldatenbank zurückzukehren, falls nach der Umstellung auf Spanner Probleme auftreten.

Die Reverse-Replikation ist nützlich, wenn unerwartete Probleme mit Spanner auftreten und Sie mit minimalen Dienstunterbrechungen zur ursprünglichen MySQL-Datenbank zurückkehren müssen. Die Reverse-Replikation ermöglicht den Fallback, indem Daten, die in Spanner geschrieben wurden, zurück zu Ihrer MySQL-Quelldatenbank repliziert werden.

Der Reverse-Replikationsfluss umfasst die folgenden Schritte, die von der spanner-to-sourcedb Dataflow-Vorlage ausgeführt werden:

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

  2. Vorwärts migrierte Änderungen filtern.

  3. Spanner-Daten so transformieren, dass sie mit dem Schema Ihrer Quelldatenbank kompatibel sind.

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

  5. Daten in die Quelldatenbank schreiben.

Nächste Schritte