Migration von MySQL zu Cloud Spanner

In diesem Artikel wird erläutert, wie Sie Ihre OLTP-Datenbank (Online Transactional Processing) von MySQL zu Cloud 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 implementiert keinen Sequenzgenerator. Wie nachstehend erläutert, ist die Verwendung kontinuierlich steigender Zahlen als Primärschlüssel in Spanner ein Anti-Muster. Eine alternative Methode zum Generieren eines eindeutigen Primärschlüssels ist die Verwendung einer zufälligen UUID.

Wenn Sequenzen aus externen Gründen erforderlich sind, müssen diese auf der Anwendungsebene implementiert werden.

Zugriffssteuerung

Spanner unterstützt nur Zugriffssteuerungen auf Datenbankebene mit den Zugriffsberechtigungen und Rollen der Identitäts- und Zugriffsverwaltung (IAM). Vordefinierte Rollen können Lese-/Schreibzugriff oder nur Lesezugriff auf die Datenbank erteilen. Wenn Sie präzisere Berechtigungen benötigen, müssen Sie diese auf der Anwendungsebene implementieren. In einem normalen Szenario hat nur die Anwendung Lese-/Schreibzugriff auf die Datenbank.

Wenn Sie Ihre Datenbank für die Berichterstellung an Nutzer freigeben und präzise Sicherheitsberechtigungen verwenden möchten (z. B. Berechtigungen auf Tabellen-/Ansichtsebene), empfehlen wir das Exportieren der Datenbank nach BigQuery.

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üfungen und Validierung durch Trigger Auf Anwendungsebene implementiert

Generierte Spalten

Spanner unterstützt generierte Spalten, bei denen der Spaltenwert immer durch eine Funktion generiert wird, die als Teil der Tabellendefinition bereitgestellt wird. Wie in MySQL können generierte Spalten nicht ausdrücklich 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 Hinweise
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 eine Genauigkeit und Skalierung von insgesamt 65 Stellen, wie in der Spaltendeklaration definiert. Der Spanner-Datentyp NUMERIC unterstützt eine Genauigkeit von 38 Stellen und eine Skalierung von neun Dezimalstellen.
Weitere Informationen finden Sie 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. Erwägen Sie die Verwendung alternativer Google Cloud-Angebote wie Cloud Storage, 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. Erwägen Sie die Verwendung alternativer Google Cloud-Angebote wie Cloud Storage, um größere Objekte zu speichern.
JSON STRING (entweder mit Daten oder URI zum externen Objekt) Kleine JSON-Strings (weniger als 2.621.440 Zeichen) können als STRING gespeichert werden. Erwägen Sie die Verwendung alternativer Google Cloud-Angebote wie Cloud Storage, 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.

Schema und Datenmodell 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

Jede Tabelle, die mehr als eine Zeile umfassen muss, muss einen Primärschlüssel haben, der aus einer oder mehreren Spalten der Tabelle besteht. Der Primärschlüssel Ihrer Tabelle identifiziert jede Zeile in einer Tabelle eindeutig. Da die Tabellenzeilen nach dem Primärschlüssel sortiert sind, fungiert die Tabelle selbst als primärer Index.

Spalten, die kontinuierlich größer oder kleiner werden, sollten nicht als erster Teil des Primärschlüssels festlegt werden (z. B. Sequenzen oder Zeitstempel). Der Grund hierfür ist, dass durch Einfügungen am Ende des Schlüsselraums Hotspots verursacht werden. Ein Hotspot ist eine Kumulierung von Vorgängen auf einem einzelnen Knoten, die zu einer Reduzierung des Schreibdurchsatzes bei der Kapazität des Knotens führt. Hierbei gehen die Vorteile des Load-Balancing aller Schreibvorgänge auf mehrere Spanner-Knoten verloren.

Verwenden Sie die folgenden Techniken, um eindeutige Primärschlüsselwerte zu generieren und das Risiko für Hotspots zu reduzieren:

Nachdem Sie den Primärschlüssel der Tabelle zugewiesen haben, können Sie ihn nicht mehr ändern. Dazu müssten Sie die Tabelle löschen und neu erstellen. Weitere Informationen zum Zuweisen des Primärschlüssels finden Sie unter Schema und Datenmodell – Primärschlüssel.

Hier sehen Sie ein Beispiel für eine DDL-Anweisung, die eine Tabelle für eine Datenbank mit Musiktiteln erstellt:

CREATE TABLE Singers (
  SingerId   INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  SingerInfo BYTES(MAX),
  BirthDate  DATE,
) PRIMARY KEY(SingerId);

Tabellen verschränken

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 aus der Originaltabelle mithilfe der STORING-Klausel im sekundären Index, was einem abdeckenden Index (Covering Index) entspricht.

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.

Alle 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 mithilfe der Spanner-Abfrageschnittstelle in der 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.

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.

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.

Daten von MySQL in 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 von 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.

Beide Datenbanken konsistent halten

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.

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.

Nächste Schritte