Von MySQL zu Spanner migrieren

In diesem Artikel wird erläutert, wie Sie Ihre OLTP-Datenbank (Online Transactional Processing) von MySQL zu Spanner migrieren.

Migrationseinschränkungen

Bei Spanner werden bestimmte Konzepte anders als bei anderen Verwaltungstools für Unternehmensdatenbanken verwendet. Daher müssen Sie möglicherweise die Architektur Ihrer Anwendung anpassen, um alle Funktionen nutzen zu können. Eventuell müssen Sie Spanner durch andere Dienste von Google Cloud ergänzen, um Ihre Anforderungen zu erfüllen.

Gespeicherte Prozeduren und Trigger

Spanner unterstützt nicht die Ausführung von Nutzercode auf Datenbankebene. Daher muss im Rahmen der Migration die Geschäftslogik, die durch auf Datenbankebene gespeicherte Prozeduren und Trigger implementiert wird, in die Anwendung verschoben werden.

Sequenzen

Spanner empfiehlt, als Standardmethode die UUID Version 4 zum Generieren von Primärschlüsselwerten zu verwenden. Die Funktion GENERATE_UUID() (GoogleSQL, PostgreSQL) gibt Werte der UUID Version 4 zurück, die als STRING-Typ dargestellt werden.

Wenn Sie ganzzahlige Werte generieren müssen, unterstützt Spanner Bit-umgekehrte positive Sequenzen (GoogleSQL, PostgreSQL). Diese erzeugen Werte, die gleichmäßig über den positiven 64-Bit-Zahlenbereich verteilt sind. Sie können diese Nummern verwenden, um Heißlaufen zu vermeiden.

Weitere Informationen finden Sie unter Standardwertstrategien für Primärschlüssel.

Zugriffssteuerung

Spanner unterstützt eine fein abgestimmte Zugriffssteuerung auf Tabellen- und Spaltenebene. Eine differenzierte Zugriffssteuerung für Ansichten wird nicht unterstützt. Weitere Informationen finden Sie unter Detaillierte Zugriffssteuerung.

Einschränkungen bei der Datenvalidierung

Spanner unterstützt auf Datenbankebene eine begrenzte Anzahl von Einschränkungen bei der Datenvalidierung. Wenn Sie komplexere Dateneinschränkungen benötigen, implementieren Sie diese auf der Anwendungsebene.

In der folgenden Tabelle werden die in MySQL-Datenbanken häufig vorkommenden Arten von Einschränkungen und ihre Implementierung mit Spanner erläutert.

Einschränkung	Implementierung mit Spanner
Nicht null	Spalteneinschränkung `NOT NULL`
Eindeutig	Sekundärer Index mit `UNIQUE`-Einschränkung
`Foreign key` (für normale Tabellen)	Weitere Informationen finden Sie unter Fremdschlüsselbeziehungen erstellen und verwalten.
Fremdschlüsselaktionen `ON DELETE/ON UPDATE`	Nur für verschränkte Tabellen möglich, ansonsten auf der Anwendungsebene implementiert
Wertprüfungen und Validierung durch `CHECK`-Einschränkungen	Weitere Informationen finden Sie unter Diagnoseeinschränkungen erstellen und verwalten.
Wertprüfung und Validierung durch Trigger	Auf Anwendungsebene implementiert

Generierte Spalten

Spanner unterstützt generierte Spalten, wobei der Spaltenwert immer von einer Funktion generiert wird, die als Teil der Tabellendefinition angegeben wird. Wie in MySQL können generierte Spalten nicht explizit auf einen bereitgestellten Wert in einer DML-Anweisung festgelegt werden.

Generierte Spalten sind als Teil der Spaltendefinition in einer DDL-Anweisung (Data Definition Language) CREATE TABLE oder ALTER TABLE definiert. Auf das Keyword AS folgt eine gültige SQL-Funktion und das erforderliche Suffix-Keyword STORED. Das Keyword STORED ist Teil der ANSI-SQL-Spezifikation und gibt an, dass die Funktionsergebnisse zusammen mit anderen Spalten der Tabelle gespeichert werden.

Die SQL-Funktion, der Generierungsausdruck, kann beliebige deterministische Ausdrücke, Funktionen und Operatoren enthalten und in sekundären Indexen oder als Fremdschlüssel verwendet werden.

Weitere Informationen zum Verwalten dieses Spaltentyps finden Sie unter Generierte Spalten erstellen und verwalten.

Unterstützte Datentypen

MySQL und Spanner unterstützen unterschiedliche Datentypen. In der folgenden Tabelle sind die MySQL-Datentypen und ihre Entsprechungen in Spanner aufgeführt. Ausführliche Definitionen für jeden Spanner-Datentyp finden Sie unter Datentypen.

Möglicherweise müssen Sie Ihre Daten weiter transformieren, wie in der Spalte "Hinweise" beschrieben, damit MySQL-Daten in Ihre Spanner-Datenbank passen. Sie können beispielsweise ein großes BLOB als Objekt eher in einem Cloud Storage-Bucket als in der Datenbank speichern. Anschließend können Sie den URI-Verweis auf das Cloud Storage-Objekt in der Datenbank als STRING speichern.

MySQL-Datentyp	Entsprechung für Spanner	Notes
`INTEGER`, `INT`, `BIGINT` `MEDIUMINT`, `SMALLINT`	`INT64`
`TINYINT`, `BOOL`, `BOOLEAN`	`BOOL`, `INT64`	`TINYINT(1)`-Werte werden zur Darstellung der booleschen Werte "true" (ungleich null) oder "false" (0) verwendet.
`FLOAT`, `DOUBLE`	`FLOAT64`
`DECIMAL`, `NUMERIC`	`NUMERIC`, `STRING`	In MySQL unterstützen die Datentypen `NUMERIC` und `DECIMAL` insgesamt bis zu einer Gesamtgenauigkeit und Skalierung von 65 Ziffern, wie in der Spaltendeklaration definiert. Der Datentyp Spanner `NUMERIC` unterstützt eine Genauigkeit von bis zu 38 Stellen und eine Skalierung mit 9 Dezimalstellen. Wenn Sie eine höhere Genauigkeit benötigen, beachten Sie die alternativen Mechanismen unter Numerische Daten mit beliebiger Genauigkeit speichern.
`BIT`	`BYTES`
`DATE`	`DATE`	Sowohl Spanner als auch MySQL verwenden das Datumsformat `yyyy-mm-dd`, sodass keine Transformation erforderlich ist. SQL-Funktionen werden bereitgestellt, um Datumsangaben in einen formatierten String zu konvertieren.
`DATETIME`, `TIMESTAMP`	`TIMESTAMP`	Spanner speichert die Uhrzeit unabhängig von der Zeitzone. Zur Speicherung einer Zeitzone müssen Sie eine separate `STRING`-Spalte verwenden. SQL-Funktionen werden bereitgestellt, um Zeitstempel in einen formatierten String zu konvertieren.
`CHAR`, `VARCHAR`	`STRING`	Hinweis: Spanner verwendet durchgehend Unicode-Strings. VARCHAR unterstützt eine maximale Länge von 65.535 Byte, Spanner hingegen bis zu 2.621.440 Zeichen.
`BINARY`, `VARBINARY`, `BLOB`, `TINYBLOB`	`BYTES`	Kleine Objekte (kleiner als 10 MiB) können als `BYTES` gespeichert werden. Ziehen Sie die Verwendung alternativer Google Cloud-Angebote wie Cloud Storage in Betracht, um größere Objekte zu speichern.
`TEXT`, `TINYTEXT`, `ENUM`	`STRING`	Kleine `TEXT`-Werte (kleiner als 10 MiB) können als `STRING` gespeichert werden. Erwägen Sie die Verwendung alternativer Google Cloud-Angebote wie Cloud Storage, um größere `TEXT`-Werte zu unterstützen.
`ENUM`	`STRING`	Die Validierung der `ENUM`-Werte muss in der Anwendung durchgeführt werden.
`SET`	`ARRAY<STRING>`	Die Validierung der `SET`-Elementwerte muss in der Anwendung durchgeführt werden.
`LONGBLOB`, `MEDIUMBLOB`	`BYTES` oder `STRING` mit URI zum Objekt.	Kleine Objekte (kleiner als 10 MiB) können als `BYTES` gespeichert werden. Erwägen Sie die Verwendung alternativer Google Cloud-Angebote wie Cloud Storage, um größere Objekte zu speichern.
`LONGTEXT`, `MEDIUMTEXT`	`STRING` (entweder mit Daten oder URI zum externen Objekt)	Kleine Objekte (weniger als 2.621.440 Zeichen) können als `STRING` gespeichert werden. Ziehen Sie die Verwendung alternativer Google Cloud-Angebote wie Cloud Storage in Betracht, um größere Objekte zu speichern.
`JSON`	`JSON`	Kleine JSON-Strings (weniger als 2.621.440 Zeichen) können als `JSON` gespeichert werden. Ziehen Sie die Verwendung alternativer Google Cloud-Angebote wie Cloud Storage in Betracht, um größere Objekte zu speichern.
`GEOMETRY`, `POINT`, `LINESTRING`, `POLYGON`, `MULTIPOINT`, `MULTIPOLYGON`, `GEOMETRYCOLLECTION`		Geospatiale Datentypen werden von Spanner nicht unterstützt. Sie müssen diese Daten mit Standarddatentypen speichern und Such-/Filterlogik in der Anwendungsebene implementieren.

Migrationsprozess

Ein allgemeiner Zeitplan für Ihren Migrationsprozess würde folgendermaßen aussehen:

Schema und Datenmodell migrieren
Alle SQL-Abfragen übersetzen
Anwendung migrieren, um Spanner zusätzlich zu MySQL zu verwenden
Bulk-Export der Daten aus MySQL und Import in Spanner mithilfe von Dataflow durchführen
Während der Migration beide Datenbanken konsistent halten
Migrieren Sie Ihre Anwendung weg von MySQL.

Schritt 1: Datenbank und Schema konvertieren

Konvertieren Sie Ihr vorhandenes Schema in ein Spanner-Schema, um Ihre Daten zu speichern. Prüfen Sie, ob das konvertierte Schema dem vorhandenen MySQL-Schema so genau wie möglich entspricht, um Änderungen an der Anwendung zu vereinfachen. Aufgrund der unterschiedlichen Funktionen können jedoch einige Änderungen erforderlich sein.

Der Leitfaden Best Practices für Schemadesign kann dabei helfen, den Durchsatz zu erhöhen und Hotspots in Ihrer Cloud Spanner-Datenbank zu reduzieren.

Primärschlüssel

In Spanner muss jede Tabelle, die mehr als eine Zeile speichern muss, einen Primärschlüssel haben, der aus einer oder mehreren Spalten der Tabelle besteht. Der Primärschlüssel der Tabelle identifiziert jede Zeile in einer Tabelle eindeutig und Spanner verwendet den Primärschlüssel, um Tabellenzeilen zu sortieren. Da Spanner stark verteilt ist, ist es wichtig, dass Sie ein Verfahren zur Primärschlüsselgenerierung wählen, das mit dem Datenwachstum gut skaliert wird. Weitere Informationen finden Sie in den von uns empfohlenen Migrationsstrategien für Primärschlüssel.

Nachdem Sie Ihren Primärschlüssel festgelegt haben, können Sie keine Primärschlüsselspalte hinzufügen oder entfernen und auch keinen Primärschlüsselwert später ändern, ohne die Tabelle zu löschen und neu zu erstellen. Weitere Informationen zum Festlegen des Primärschlüssels finden Sie unter Schema und Datenmodell – Primärschlüssel.

Tabellen verschachteln

Spanner hat ein Feature, mit dem Sie zwei Tabellen mit einer 1:n-Beziehung mit hierarchischer Struktur definieren können. Mit dieser Funktion werden die untergeordneten Datenzeilen mit der jeweils übergeordneten Zeile im Speicher verschränkt. Die Tabelle wird hierdurch vorab verknüpft und der Datenabruf erfolgt effizienter, wenn beide Tabellen (untergeordnet und übergeordnet) gemeinsam abgefragt werden.

Der Primärschlüssel der untergeordneten Tabelle muss mit der bzw. den Primärschlüsselspalten der übergeordneten Tabelle beginnen. Aus der Perspektive der untergeordneten Zeile wird der Primärschlüssel der übergeordneten Zeile als Fremdschlüssel bezeichnet. Sie können bis zu 6 Ebenen an hierarchischen Beziehungen definieren.

Sie können "On Delete"-Aktionen für untergeordnete Tabellen definieren, um zu bestimmen, was passiert, wenn die übergeordnete Zeile gelöscht wird: Entweder werden alle untergeordneten Zeilen gelöscht oder die übergeordnete Zeile kann nicht gelöscht werden, solange untergeordnete Zeilen vorhanden sind.

Hier sehen Sie anhand eines Beispiels, wie eine Album-Tabelle erstellt wird, die in der zuvor definierten übergeordneten Tabelle mit den Interpreten verschränkt ist:

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId)
INTERLEAVE IN PARENT (Singers)
ON DELETE CASCADE;

Sekundäre Indexe erstellen

Sie können auch sekundäre Indexe erstellen, um Daten in der Tabelle außerhalb des Primärschlüssels zu indexieren. Spanner implementiert sekundäre Indexe auf dieselbe Weise wie Tabellen. Daher gelten für die als Indexschlüssel zu verwendenden Spaltenwerte dieselben Einschränkungen wie für die Primärschlüssel von Tabellen. Dies bedeutet auch, dass Indexe die gleichen Konsistenzgarantien wie Spanner-Tabellen haben.

Werte-Zuordnungen mit sekundären Indexen entsprechen praktisch einer Abfrage mit Tabellenverknüpfung. Sie können die Leistung von Abfragen mithilfe von Indexen verbessern. Speichern Sie dazu Kopien der Spaltenwerte der ursprünglichen Tabelle mithilfe der Klausel STORING im sekundären Index und speichern Sie so einen abdeckenden Index (Covering Index).

Die Abfrageoptimierung von Spanner verwendet nur dann automatisch einen sekundären Index, wenn der Index selbst alle abgefragten Spalten speichert (abgedeckte Abfrage). Wenn Sie erzwingen möchten, dass beim Abfragen von Spalten in der ursprünglichen Tabelle ein Index verwendet wird, müssen Sie in der SQL-Anweisung eine FORCE INDEX-Anweisung verwenden. Beispiel:

SELECT *
FROM MyTable@{FORCE_INDEX=MyTableIndex}
WHERE IndexedColumn=@value

Mit Indexen können eindeutige Werte in einer Tabellenspalte erzwungen werden. Dazu wird ein UNIQUE-Index für diese Spalte definiert. Der Index verhindert das Hinzufügen doppelter Werte.

Hier ist ein Beispiel für eine DDL-Anweisung, die einen sekundären Index für die Album-Tabelle erstellt:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Wenn Sie nach dem Laden Ihrer Daten zusätzliche Indexe erstellen, kann das Auffüllen des Index einige Zeit in Anspruch nehmen. Daher wird empfohlen, maximal drei Indexe pro Tag hinzuzufügen. Eine ausführliche Anleitung zum Erstellen von sekundären Indexen finden Sie unter Sekundäre Indexe. Weitere Informationen zu den Einschränkungen bei der Indexerstellung finden Sie unter Schemaaktualisierungen.

Schritt 2: SQL-Abfragen übersetzen

Spanner verwendet den ANSI 2011-Dialekt von SQL mit Erweiterungen und bietet viele Funktionen und Operatoren zum Übersetzen und Zusammenfassen von Daten. Alle SQL-Abfragen, die MySQL-spezifische Dialekte, Funktionen und Typen verwenden, müssen konvertiert werden, damit sie mit Spanner kompatibel sind.

Obwohl Spanner keine strukturierten Daten als Spaltendefinitionen unterstützt, können Sie mit den Typen ARRAY<> und STRUCT<> strukturierte Daten in SQL-Abfragen verwenden. Sie können beispielsweise eine Abfrage schreiben, die ein ARRAY von STRUCTs verwendet und alle Alben eines Interpreten ausgibt. Hierbei werden die vorab verknüpften Daten genutzt. Weitere Informationen finden Sie im Abschnitt Unterabfragen der Dokumentation.

SQL-Abfragen können auf der Spanner Studio-Seite in der Google Cloud Console profiliert werden, um die Abfrage auszuführen. Im Allgemeinen sollten Abfragen, die vollständige Tabellenscans für große Tabellen ausführen, sparsam verwendet werden, da sie sehr teuer sind. Weitere Informationen zur Optimierung von SQL-Abfragen finden Sie in der Dokumentation zu Best Practices für SQL.

Schritt 3: Anwendung zur Verwendung von Spanner migrieren

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.

Sie können auch den JDBC-Treiber (Java Database Connectivity) verwenden, um eine Verbindung zu Spanner herzustellen und dabei vorhandene Tools und Infrastrukturen einzubinden, die keine native Integration haben.

Im Rahmen des Migrationsprozesses müssen Features, 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-Schreib-Transaktion 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.

Schritt 4: Daten von MySQL zu Spanner übertragen

Wenn Sie Ihre Daten von MySQL in Spanner übertragen möchten, müssen Sie Ihre MySQL-Datenbank in ein portables Dateiformat (z. B. XML) exportieren und die Daten anschließend mit Dataflow in Spanner importieren.

Daten von MySQL in Spanner übertragen

Bulk-Export aus MySQL

Das in MySQL enthaltene mysqldump-Tool kann die gesamte Datenbank in korrekt formatierte XML-Dateien exportieren. Alternativ können Sie mit der SQL-Anweisung SELECT ... INTO OUTFILE für jede Tabelle CSV-Dateien erstellen. Dieser Ansatz hat jedoch den Nachteil, dass jeweils nur eine Tabelle exportiert werden kann. Sie müssen also entweder die Anwendung anhalten oder die Datenbank stilllegen, damit die Datenbank für den Export in einem konsistenten Zustand bleibt.

Nach dem Export dieser Datendateien empfehlen wir, dass Sie sie in einen Cloud Storage- Bucket hochladen, damit sie für den Import verfügbar sind.

Bulk-Import in Spanner

Da sich die Datenbankschemas von MySQL und Spanner wahrscheinlich unterscheiden, müssen Sie im Rahmen des Importvorgangs möglicherweise einige Datenkonvertierungen vornehmen. Dataflow ist die einfachste Methode, um diese Datenkonvertierungen durchzuführen und die Daten in Spanner zu importieren. Dataflow ist der ETL-Dienst (Extrahieren, Transformieren, Laden) von Google Cloud. Dieser Dienst bietet eine Plattform zum Ausführen von Datenpipelines, die mit dem Apache Beam SDK geschrieben wurden. So können große Datenmengen parallel auf mehreren Maschinen gelesen und verarbeitet werden.

Für das Apache Beam SDK benötigen Sie ein einfaches Java-Programm, um die Daten lesen, transformieren und schreiben zu können. Für Cloud Storage und Spanner gibt es Beam-Connectors. Der einzige Code, den Sie schreiben müssen, ist jener für die Datentransformation selbst.

Ein Beispiel für eine einfache Pipeline, die CSV-Dateien liest und in Spanner schreibt, finden Sie im Beispielcode-Repository.

Wenn Sie in Ihrem Spanner-Schema verschachtelte über- und untergeordnete Tabellen verwenden, achten Sie beim Import darauf, dass die übergeordnete Zeile vor der untergeordneten Zeile erstellt wird. Zu diesem Zweck importiert der Code der Spanner-Importpipeline zuerst alle Daten für Tabellen auf Stammebene, dann alle untergeordneten Tabellen der Ebene 1, dann alle untergeordneten Tabellen der Ebene 2 usw.

Sie können die Spanner-Importpipeline direkt für den Bulk-Import Ihrer Daten verwenden. Bei diesem Ansatz müssen Ihre Daten jedoch in Avro-Dateien mit dem richtigen Schema vorliegen.

Schritt 5: Konsistenz zwischen beiden Datenbanken wahren

Da viele Anwendungen Anforderungen bezüglich der Verfügbarkeit haben, ist es oftmals nicht möglich, die Anwendung für den Zeitraum des Exports und Imports der Daten im Offline-Modus zu halten. Während die Daten an Spanner übertragen werden, nimmt die Anwendung daher weitere Änderungen an der vorhandenen Datenbank vor. Aus diesem Grund müssen Aktualisierungen auch in die Spanner-Datenbank kopiert werden, während die Anwendung ausgeführt wird.

Es gibt verschiedene Methoden, um eine kontinuierliche Synchronisierung beider Datenbanken zu ermöglichen, darunter Change Data Capture und die gleichzeitige Implementierung von Aktualisierungen in der Anwendung.

Change Data Capture

MySQL hat kein natives Change Data Capture-(CDC-)Dienstprogramm. Es gibt jedoch verschiedene Open-Source-Projekte, die MySQL-Binlogs empfangen und in einen CDC-Stream konvertieren können. Maxwell's daemon kann beispielsweise einen CDC-Stream für die Datenbank bereitstellen.

Sie können eine Anwendung schreiben, die diesen Stream abonniert und die gleichen Änderungen (nach der Datenkonvertierung) in die Spanner-Datenbank übernimmt.

Gleichzeitige Aktualisierungen beider Datenbanken über die Anwendung

Eine weitere Methode besteht darin, die Anwendung so anzupassen, dass Schreibvorgänge in beiden Datenbanken ausgeführt werden. Eine der Datenbanken (anfangs MySQL) wird als Quelle angesehen. Nach jedem Schreibvorgang in der Datenbank wird die gesamte Zeile gelesen, konvertiert und in die Spanner-Datenbank geschrieben. Auf diese Weise überschreibt die Anwendung die Spanner-Zeilen kontinuierlich mit den aktuellen Daten.

Wenn Sie sich sicher sind, dass alle Daten korrekt übertragen wurden, können Sie die Spanner-Datenbank als "Source of Truth" festlegen. Dieser Mechanismus bietet einen Rollback-Pfad für den Fall, dass beim Wechsel zu Spanner Probleme auftreten.

Datenkonsistenz prüfen

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.

Schritt 6: Spanner als „Source of Truth“ für die Anwendung festlegen

Wenn Sie sich sicher sind, dass die Datenmigration ordnungsgemäß funktioniert hat, können Sie Spanner als "Source of Truth" für Ihre Anwendung festlegen. Fahren Sie damit fort, Änderungen in die MySQL-Datenbank zurückzuschreiben, um die MySQL-Datenbank auf dem neuesten Stand zu halten und bei Problemen einen Rollback-Pfad anzugeben.

Abschließend können Sie den Code zur Aktualisierung der MySQL-Datenbank deaktivieren und entfernen sowie die inzwischen veraltete MySQL-Datenbank herunterfahren.

Spanner-Datenbanken exportieren und importieren

Optional können Sie Ihre Tabellen mithilfe einer Dataflow-Vorlage aus Spanner in einen Cloud Storage-Bucket exportieren. Der dabei erstellte Ordner enthält eine Reihe von Avro-Dateien und JSON-Manifestdateien mit den exportierten Tabellen. Diese Dateien dienen verschiedenen Zwecken:

Sichern der Datenbank, um die Datenaufbewahrungsrichtlinie einzuhalten oder die Notfallwiederherstellung zu gewährleisten
Avro-Datei in andere Google Cloud-Angebote wie BigQuery importieren

Weitere Informationen zum Exportieren und Importieren finden Sie unter Datenbanken exportieren und Datenbanken importieren.