Auf dieser Seite finden Sie eine Übersicht zur Migration Ihrer OLTP-Datenbank (Online Transactional Processing) 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:
- Migration bewerten
- Migrieren Sie Ihr Schema und übersetzen Sie alle SQL-Abfragen.
- Anwendung migrieren, um Spanner zusätzlich zu MySQL zu verwenden
- Beispieldaten laden und Leistung optimieren
- Daten migrieren
- Migration validieren
- Cutover- und Fallback-Mechanismen konfigurieren.
Migration bewerten
Für die 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 aus MySQL migrieren – Übersicht.
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 nicht wie oben erwähnt in Spanner verfügbar sind, in der Anwendung implementiert werden. Ein Trigger, um Datenwerte zu überprüfen und eine verbundene Tabelle zu aktualisieren, müsste beispielsweise in der Anwendung mithilfe einer Lese- oder Schreibtransaktion implementiert werden, die die vorhandene Zeile liest, die Einschränkungen überprüft und die aktualisierten Zeilen in beide Tabellen schreibt.
Spanner bietet Lese-/Schreibtransaktionen und schreibgeschützte Transaktionen, die für eine externe Konsistenz der Daten sorgen. Außerdem können für Lesetransaktionen Zeitstempelgrenzen angewendet werden, bei denen eine konsistente Version der angegebenen Daten gelesen wird. Entweder
- 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.
Sie können den BigQuery-Reverse-ETL-Workflow und die Google Cloud CLI verwenden, um eine kleine Menge von Daten im CSV-Dateiformat in Spanner zu laden.
Weitere Informationen finden Sie unter Beispieldaten laden.
Wenn Sie Ihre Daten von MySQL in Spanner übertragen möchten, können Sie Ihre MySQL-Datenbank auch in ein portables Dateiformat (z. B. XML) exportieren und die Daten anschließend 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-Datenbank in Produktionsgröße verschieben.
Weitere Informationen finden Sie unter Live-Datenmigration von MySQL.
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.
Sie können Dataflow verwenden, um mithilfe der Join-Transformation einen detaillierten Vergleich großer Datasets vorzunehmen. 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.
Cutover- und Fallback-Mechanismen konfigurieren
Sie können die Umstellung und das Fallback für MySQL mithilfe der Reverse-Replikation einrichten. Mit Cutover und Fallback haben Sie einen Notfallplan, um zu Ihrer MySQL-Quelldatenbank zurückzukehren, falls Probleme mit Spanner auftreten.
Die umgekehrte Replikation ist nützlich, wenn unerwartete Probleme mit Spanner auftreten und Sie mit minimalen Unterbrechungen des Dienstes auf die ursprüngliche MySQL-Datenbank zurückgreifen müssen. Die umgekehrte Replikation ermöglicht das Fallback, indem Daten, die in Spanner geschrieben wurden, zurück in Ihre MySQL-Quelldatenbank repliziert werden.
Der Ablauf der umgekehrten Replikation umfasst die folgenden Schritte, die von der Spanner to SourceDB
-Dataflow-Vorlage ausgeführt werden:
Änderungen aus Spanner mit Spanner-Änderungsstreams lesen.
Filtern Sie die vorwärts migrierten Änderungen.
Spanner-Daten so transformieren, dass sie mit dem Schema Ihrer Quelldatenbank kompatibel sind.
Prüfen Sie, ob die Quelldatenbank bereits neuere Daten für den angegebenen Primärschlüssel enthält.
Schreiben Sie die Daten in Ihre Quelldatenbank.
Nächste Schritte
- Best Practices für Schemadesign
- Spanner-Schema optimieren
- Dataflow für komplexere Situationen verwenden