Von MySQL zu Spanner migrieren

In diesem Artikel wird erläutert, wie Sie Ihre Online-Transaktionsverarbeitung (OLTP) migrieren können. von MySQL bis hin zu Spanner.

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 die Verwendung von UUID Version 4 als Standardmethode zum Generieren Primärschlüsselwerte. Mit der Funktion GENERATE_UUID() (GoogleSQL, PostgreSQL) gibt UUID-Version 4-Werte zurück, die als STRING-Typ dargestellt werden.

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

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

Zugriffssteuerung

Spanner unterstützt eine differenzierte Zugriffssteuerung an Tabellen und Spalten. Die detaillierte 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.

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.

Migrationsprozess

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

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

Schritt 1: Datenbank und Schema konvertieren

Konvertieren Sie das vorhandene Schema in einen Spanner-Typ Schema zum Speichern Ihrer Daten. 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. Die Primärschlüssel identifiziert jede Zeile in einer Tabelle eindeutig und Spanner verwendet den Primärschlüssel zum Sortieren von Tabellenzeilen. Da Spanner stark verteilt ist, ist es wichtig, dass Sie eine Primärschlüsselgenerierung die mit dem Datenwachstum gut skaliert wird. Weitere Informationen finden Sie unter die Primärschlüssel-Migrationsstrategien die wir empfehlen.

Nachdem Sie Ihren Primärschlüssel festgelegt haben, können Sie keine Primärschlüsselspalte oder später einen Primärschlüsselwert ändern, ohne und wenn Sie die Tabelle neu erstellen. Weitere Informationen zur Festlegung des Primärschlüssels Siehe Schema und Datenmodell – primär Schlüssel.

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 „Löschen“-Aktionen definieren für untergeordnete Tabellen, um zu bestimmen, was passiert, wenn die übergeordnete Zeile gelöscht wird: werden entweder alle untergeordneten Zeilen gelöscht oder das Löschen der übergeordneten Zeile wird blockiert, während 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 um Daten in der Tabelle außerhalb des Primärschlüssels zu indexieren. Spanner implementiert sekundäre Indexe auf dieselbe Weise wie Tabellen, Daher haben die Spaltenwerte, die als Indexschlüssel verwendet werden, denselben Einschränkungen als 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, indem Sie Kopien der Spaltenwerte aus der Originaltabelle im sekundären Index unter Verwendung des STORING-Klausel, was sie zu einer Abdeckungsindex.

Die Abfrageoptimierung von Spanner verwendet nur dann automatisch einen sekundären Index, wenn der Index selbst alle abgefragten Spalten speichert (abgedeckte Abfrage). Um die Verwendung eines Index beim Abfragen von Spalten im Original zu erzwingen müssen Sie eine FORCE-INDEX-Anweisung in der SQL-Anweisung ein. Beispiel:

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

Mit Indexen können eindeutige Werte innerhalb einer Tabellenspalte erzwungen werden, indem a UNIQUE-Index für diese Spalte. 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 die ANSI 2011-Dialekt von SQL mit Erweiterungen, und hat viele Funktionen und Operatoren um Ihre Daten zu übersetzen und zu aggregieren. 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 in der Unterabfragen der Dokumentation.

SQL-Abfragen können auf der Seite von Spanner Studio in die Google Cloud Console, 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 migrieren, um Spanner zu verwenden

Spanner bietet eine Reihe von Clientbibliotheken für verschiedene Sprachen und die Möglichkeit, Daten mit Spanner-spezifische API-Aufrufe sowie die Verwendung von SQL-Abfragen und Datenänderungssprache (DML) Aussagen. 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 eine JDBC-Treiber für Java-Anwendungen.

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 Sie Transaktionen können Zeitstempelgrenzen angewendet, bei dem Sie eine konsistente Version der Daten lesen, 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.

Bulk-Export aus MySQL

Das in MySQL enthaltene mysqldump-Tool kann die gesamte Datenbank in korrekt formatierte XML-Dateien exportieren. Alternativ können Sie den SELECT ... INTO OUTFILE SQL-Anweisung zum Erstellen von CSV-Dateien für jede Tabelle. 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.

Wir empfehlen Ihnen, diese Datendateien nach dem Export in einen Cloud Storage damit sie für den Import zugänglich 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. Es bietet eine Plattform zum Ausführen von Datenpipelines, die mit die Apache Beam SDK um große Datenmengen parallel über mehrere .

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 aufrechterhalten

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 keine native Change Data Capture (CDC) unterstützt. Es gibt jedoch verschiedene Open-Source-Projekte, die MySQL-Binlogs empfangen und in einen CDC-Stream konvertieren können. Beispiel: Maxwells Daemon 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 Export und Import finden Sie unter Datenbanken exportieren und Datenbanken importieren.

Nächste Schritte

• Spanner-Schema optimieren
• So funktionierts Dataflow für komplexere Situationen.