Übersicht über die Migration

In diesem Dokument wird beschrieben, wie Sie Ihre Datenbank zu Spanner migrieren. Wir beschreiben die Migrationsphasen und die Tools, die wir für jede Phase empfehlen, je nach Quelldatenbank und anderen Faktoren. Zu den empfohlenen Tools gehören Google Cloud Produkte sowie kommerzielle und Open-Source-Tools von Drittanbietern. Mit diesen Tools können Sie Migrationen beschleunigen und Risiken reduzieren.

Jede Spanner-Migration umfasst die folgenden Hauptphasen:

  1. Bewerten Sie die Komplexität Ihrer Migration.
  2. Migrieren Sie Ihr Schema.
  3. Laden Sie Beispieldaten.
  4. Migrieren Sie Ihre Anwendung.
  5. Leistung testen und optimieren
  6. Migrieren Sie die Daten.
  7. Prüfen Sie die Migration.
  8. Konfigurieren Sie Umstellungs- und Failover-Mechanismen.

Innerhalb dieser Phasen kann Ihr Migrationsplan je nach Faktoren wie Datenbankquelle und ‑größe, Ausfallzeitenanforderungen, Komplexität des Anwendungscodes, Sharding-Schema, benutzerdefinierten Funktionen oder Transformationen sowie Failover- und Replikationsstrategie stark variieren.

Migrationstools

Wir empfehlen die Verwendung der folgenden Tools, um Sie in verschiedenen Phasen der Migration zu unterstützen, je nach Ihrer Quelldatenbank und anderen Faktoren. Einige Tools unterstützen nur bestimmte Quelldatenbanken. Für einige Schritte des Prozesses ist kein Tool verfügbar. Diese Schritte müssen Sie daher manuell ausführen.

  • Das Spanner Migration Tool (SMT) ist ein Open-Source-Tool, mit dem grundlegende Bewertungen, Schemakonvertierungen und Datenmigrationen durchgeführt werden können.

  • Die Datenbankmigrationsbewertung (Database Migration Assessment, DMA) bietet eine grundlegende Bewertung für die Migration von PostgreSQL zu Spanner.

  • Datastream ist ein Google Cloud Dienst, mit dem Sie CDC-Ereignisse (Change Data Capture) und Bulk-Daten aus einer Quelldatenbank lesen und in ein bestimmtes Ziel schreiben können.

  • Dataflow ist ein Google Cloud Dienst, mit dem Sie große Datenmengen mithilfe von Vorlagen effizienter in Spanner schreiben können.

  • Bulk-Datenmigration ist eine Dataflow-Vorlage, mit der Sie große MySQL-Datenmengen direkt in Spanner migrieren können.

  • Bei der Migration mit minimaler Ausfallzeit werden Datastream und Dataflow verwendet, um Folgendes zu migrieren:

    • Vorhandene Daten in Ihrer Quelldatenbank
    • Stream mit Änderungen, die während der Migration an der Quelldatenbank vorgenommen werden.
  • Das Data Validation Tool (DVT) ist eine standardisierte Methode zur Datenvalidierung, die von Google entwickelt und von der Open-Source-Community unterstützt wird. Sie können DVT in bestehendeGoogle Cloud Produkte integrieren.

Migrationstools für MySQL-Quelldatenbanken

Wenn Ihre Quelldatenbank MySQL ist, können Sie einige der ersten Migrationsphasen mithilfe von MySQL-Dumpdateien ausführen. Sie müssen eine direkte Verbindung zu Ihrer laufenden MySQL-Quelldatenbank herstellen, um eine Produktionsmigration abzuschließen.

In der folgenden Tabelle werden Migrationstools empfohlen, die auf der Migrationsphase und darauf basieren, ob Sie mit einer Dumpdatei arbeiten oder eine direkte Verbindung zu Ihrer Quelldatenbank herstellen:

Migrationsphase Dumpdatei Direkte Verbindung zur Quelldatenbank
Bewertung Verwenden Sie SMT mit mysqldump. Verwenden Sie SMT mit mysqldump.
Schemakonvertierung Verwenden Sie SMT mit mysqldump. Verwenden Sie SMT, um das Schema zu konfigurieren und zu konvertieren.
Beispieldaten laden Führen Sie eine Bulk-Migration aus.
Datenmigration Nicht zutreffend Führen Sie eine Bulk-Migration und dann eine Migration mit minimaler Ausfallzeit aus.
Datenvalidierung Nicht zutreffend Verwende DVT.
Failover-Konfiguration Nicht zutreffend Verwenden Sie SMT für die umgekehrte Replikation.

Migrationstools für PostgreSQL-Quelldatenbanken

Wenn Ihre Quelldatenbank PostgreSQL verwendet, können Sie einige der Migrationsphasen mit einer PostgreSQL-Dumpdatei ausführen. Sie müssen eine direkte Verbindung zu Ihrer laufenden PostgreSQL-Quelldatenbank herstellen, um die Migration abzuschließen.

In der folgenden Tabelle werden Migrationstools basierend auf der Migrationsphase und darauf empfohlen, ob Sie mit einer Dumpdatei arbeiten oder eine direkte Verbindung von Ihrer Quelldatenbank herstellen:

Migrationsphase Dumpdatei Direkte Verbindung zur Quelldatenbank
Bewertung Verwenden Sie SMT mit pg_dump. Verwenden Sie DMA.
Schemakonvertierung Verwenden Sie SMT mit pg_dump. Verwenden Sie SMT, um das Schema zu konfigurieren und zu konvertieren.
Beispieldaten laden Führen Sie eine Migration mit minimaler Ausfallzeit aus.
Datenmigration Nicht zutreffend Führen Sie eine Migration mit minimaler Ausfallzeit aus.
Datenvalidierung Nicht zutreffend Verwende DVT.
Failover Nicht zutreffend Nicht zutreffend

Komplexität der Migration bewerten

Um den Umfang und die Komplexität Ihrer Migration zu beurteilen und Ihren Ansatz zu planen, müssen Sie Daten zu Ihrer Quelldatenbank erfassen, darunter:

  • Abfragemuster
  • Umfang der Anwendungslogik, die von Datenbankfunktionen wie gespeicherten Prozeduren und Triggern abhängt
  • Hardwareanforderungen
  • Gesamtbetriebskosten

Schema migrieren

Bevor Sie ein Schema zu einem Spanner-Schema migrieren, sollten Sie die Kompatibilität zwischen den Schemas prüfen und Ihr Schema für Spanner optimieren. Sie können beispielsweise Schlüssel ändern, Indizes löschen oder hinzufügen oder Spalten vorhandener Tabellen hinzufügen oder entfernen. Informationen zum Optimieren Ihres Schemas für Spanner finden Sie unter Best Practices für das Schemadesign und Empfohlene Strategien für die Migration von Primärschlüsseln.

Das Spanner-Migrationstool ist ein Open-Source-Tool, das von Google-Entwicklern erstellt und von der Community gepflegt wird. Es erstellt automatisch ein Spanner-Schema aus dem Schema Ihrer Quelldatenbank. Sie können das Schema mit dem Schemaassistenten des Spanner-Migrationstools anpassen.

Das Spanner-Migrationstool nimmt Schema und Daten an einem der folgenden Speicherorte auf:

  • Dumpdatei von einem lokalen Speicherort oder aus Cloud Storage (MySQL, PostgreSQL, CSV)
  • Direkt aus der Quelldatenbank (MySQL, PostgreSQL)

Das Spanner-Migrationstool führt die folgenden Funktionen für Schemabewertungen, Empfehlungen und Migrationen aus:

  • Bewertung und Empfehlungen zur Datentypkompatibilität
  • Primärschlüssel bearbeiten und Empfehlungen
  • Bearbeiten und Empfehlungen für sekundäre Indexe
  • Tabellenbearbeitung und Empfehlungen überlappen
  • Allgemeine Empfehlungen für das Spanner-Schemadesign
  • Schemaversionierung
  • Schemaänderungen in Gruppen

Weitere Informationen zu Schemamigrationen mit dem Spanner-Migrationstool finden Sie in der README.md-Datei des Spanner-Migrationstools.

Sie können das Spanner-Migrationstool auch für die Datenmigration verwenden.

Beispieldaten laden

Nachdem Sie ein Spanner-kompatibles Schema erstellt haben, können Sie Ihre Datenbank für den Test mit Beispieldaten vorbereiten. Sie können die Beispieldaten mit dem BigQuery-Reverse-ETL-Workflow laden. Weitere Informationen finden Sie unter Beispieldaten laden.

Anwendung migrieren

Für eine Datenbankmigration sind andere Treiber und Bibliotheken sowie eine Kompensation für Funktionen erforderlich, die von Spanner nicht unterstützt werden. Um die Stärken von Spanner zu nutzen, müssen Sie möglicherweise Ihren Code, Ihre Anwendungsabläufe und Ihre Architektur ändern.

Hier sind einige der Änderungen, die für die Migration Ihrer Anwendung zu Spanner erforderlich sind:

  • Spanner unterstützt nicht die Ausführung von Nutzercode auf Datenbankebene. Daher müssen alle auf Datenbankebene gespeicherten Prozeduren und Trigger in die Anwendung verschoben werden.
  • Verwenden Sie Spanner-Clientbibliotheken und objektrelationale Mapper (ORMs). Weitere Informationen finden Sie unter Übersicht über APIs, Clientbibliotheken und ORM-Treiber.
  • Wenn Sie Suchanfragen übersetzen müssen, können Sie dies manuell tun oder andere Tools von Drittanbietern verwenden.
  • Informieren Sie sich über partitionierte DML, schreibgeschützte Transaktionen, Commit-Zeitstempel und Lesezeitstempel und wie sie die Anwendungsleistung optimieren können.

Möglicherweise müssen Sie auch Änderungen an der Transaktionsverwaltung vornehmen. Es gibt keine Tools, die Sie dabei unterstützen können. Sie müssen diesen Schritt also manuell ausführen. Beachten Sie Folgendes:

  • Das Limit für Mutationen pro Commit beträgt 40.000. Jeder sekundäre Index in einer Tabelle ist eine zusätzliche Mutation pro Zeile. Informationen zum Ändern von Daten mithilfe von Mutationen finden Sie unter Daten mithilfe von Mutationen einfügen, aktualisieren und löschen. Verwenden Sie partitionierte DML, um eine große Datenmenge zu ändern.
  • Für die Transaktionsisolationsebene ist keine Verarbeitung erforderlich, da Spanner-Transaktionen stärker isoliert sind.
  • Da Spanner linearisierbar ist, werden Konsistenz und Sperrung standardmäßig verwaltet.

Schema und Anwendungsleistung testen und optimieren

Die Leistungsoptimierung ist ein iterativer Prozess, bei dem Sie Messwerte wie die CPU-Auslastung und die Latenz anhand einer Teilmenge Ihrer Daten bewerten, Ihr Schema und Ihre Anwendung zur Leistungssteigerung anpassen und noch einmal testen.

Sie können beispielsweise in Ihrem Schema einen Index hinzufügen oder ändern oder einen Primärschlüssel ändern. In Ihrer Anwendung können Sie Batch-Schreibvorgänge ausführen oder Abfragen zusammenführen oder ändern.

Insbesondere bei Produktionstraffic ist die Leistungsoptimierung wichtig, um unerwartete Probleme zu vermeiden. Die Leistungsoptimierung ist umso effektiver, je näher die Konfiguration am Durchsatz und den Datenmengen des Live-Produktivtraffics liegt.

So testen und optimieren Sie das Schema und die Anwendungsleistung:

  1. Laden Sie einen Teil Ihrer Daten in eine Spanner-Datenbank hoch. Weitere Informationen finden Sie unter Daten migrieren.
  2. Weisen Sie die Anwendung Spanner zu.
  3. Prüfen Sie die Richtigkeit, indem Sie nach grundlegenden Aufrufabfolgen suchen.
  4. Führen Sie Lasttests für Ihre Anwendung durch, um zu prüfen, ob die Leistung Ihren Erwartungen entspricht. Informationen zum Identifizieren und Optimieren der kostenintensivsten Abfragen finden Sie unter Probleme mit der Abfrageleistung mithilfe von Query Insights erkennen. Insbesondere die folgenden Faktoren können zu einer suboptimalen Abfrageleistung beitragen:
    1. Ineffiziente Abfragen: Informationen zum Erstellen effizienter Abfragen finden Sie unter Best Practices für SQL.
    2. Hohe CPU-Auslastung: Weitere Informationen finden Sie unter Hohe CPU-Auslastung untersuchen.
    3. Sperren: Informationen zum Reduzieren von Engpässen durch Transaktionssperren finden Sie unter Transaktionen identifizieren, die zu hohen Latenzen führen können.
    4. Ineffizientes Schemadesign: Wenn das Schema nicht gut konzipiert ist, ist die Abfrageoptimierung nicht sehr nützlich.
    5. Hotspots: Hotspots in Spanner begrenzen den Schreibdurchsatz, insbesondere bei Anwendungen mit hoher QPS. Um Hotspots oder Antimuster zu identifizieren, sehen Sie sich die Statistiken im Schlüsselvisualisierer in der Google Cloud Console an. Weitere Informationen zum Vermeiden von Hotspots finden Sie unter Primärschlüssel zur Vermeidung von Hotspots auswählen.
  5. Wenn Sie das Schema oder die Indexe ändern, wiederholen Sie die Korrektheits- und Leistungstests, bis Sie zufriedenstellende Ergebnisse erzielen.

Weitere Informationen zur Optimierung der Datenbankleistung erhalten Sie vom Spanner-Support.

Daten migrieren

Nachdem Sie Ihr Spanner-Schema optimiert und Ihre Anwendung migriert haben, verschieben Sie Ihre Daten in eine leere Spanner-Datenbank in Produktionsgröße und wechseln dann zu dieser Datenbank.

Je nach Quelldatenbank können Sie Ihre Datenbank mit minimaler Ausfallzeit migrieren oder eine längere Ausfallzeit benötigen.

Sowohl für Migrationen mit minimaler Ausfallzeit als auch für Migrationen mit längerer Ausfallzeit empfehlen wir die Verwendung von Dataflow und dem Spanner-Migrationstool.

In der folgenden Tabelle sind die Unterschiede zwischen Migrationen mit minimaler und Migrationen mit längerer Ausfallzeit aufgeführt, einschließlich unterstützter Quellen, Formate, Größe und Durchsatz.

Migration mit minimaler Ausfallzeit Migration mit Ausfallzeiten
Unterstützte Quellen MySQL, PostgreSQL Alle Datenbanken, die in CSV oder Avro exportiert werden können
Unterstützte Datenformate Stellen Sie eine direkte Verbindung her. Weitere Informationen finden Sie unter Direkte Verbindung zu einer MySQL-Datenbank herstellen. MySQL, PostgreSQL, CSV, Avro
Unterstützte Datenbankgrößen Kein Limit Kein Limit
Maximaler Durchsatz 45 GB pro Stunde 200 GB pro Stunde

Migration mit minimaler Ausfallzeit

Spanner unterstützt Migrationen mit minimaler Ausfallzeit von MySQL-, PostgreSQL- und Oracle-Datenbanken. Eine Migration mit minimaler Ausfallzeit besteht aus zwei Komponenten:

  • Ein konsistenter Snapshot aller Daten in der Datenbank
  • Der Stream der Änderungen (Einfügungen und Aktualisierungen) seit diesem Snapshot, auch als Change Data Capture (CDC) bezeichnet

Migrationen mit minimaler Ausfallzeit tragen zwar zum Schutz Ihrer Daten bei, stellen Sie aber vor Herausforderungen, darunter:

  • CDC-Daten während der Migration des Snapshots speichern
  • CDC-Daten in Spanner schreiben und gleichzeitig den eingehenden CDC-Stream erfassen.
  • Die Migration von CDC-Daten zu Spanner muss schneller sein als der eingehende CDC-Stream.

Um eine Migration mit minimaler Ausfallzeit zu ermöglichen, orchestriert das Spanner-Migrationstool die folgenden Prozesse für Sie:

  1. Hiermit wird ein Cloud Storage-Bucket eingerichtet, um CDC-Ereignisse in der Quelldatenbank zu speichern, während die Snapshot-Migration fortschreitet.
  2. Hiermit wird ein Datastream-Job eingerichtet, der die Bulk-Ladung von CDC-Daten verschiebt und kontinuierlich inkrementelle CDC-Daten in den Cloud Storage-Bucket streamt. Sie richten das Quellverbindungsprofil im Spanner-Migrationstool ein.
  3. Richtet den Dataflow-Job ein, um die CDC-Ereignisse in Spanner zu migrieren.

Wenn Dataflow die meisten Daten kopiert hat, wird das Schreiben in die Quelldatenbank beendet und es wird gewartet, bis die Migration der Daten abgeschlossen ist. Dies führt zu einer kurzen Ausfallzeit, während Spanner die Quelldatenbank auf den neuesten Stand bringt. Danach kann die Anwendung auf Spanner umgestellt werden.

Das folgende Diagramm zeigt diesen Vorgang.

Das Diagramm zeigt den Prozess einer Migration mit minimaler Ausfallzeit.

Migration mit Ausfallzeit

Bei anderen Datenbanken als MySQL, PostgreSQL oder Oracle Database können Sie mit einer Ausfallzeit zu Spanner migrieren, wenn die Datenbank in CSV oder Avro exportiert werden kann. Wir empfehlen die Verwendung von Dataflow oder dem Spanner-Migrationstool.

Migrationen mit Ausfallzeiten werden nur für Testumgebungen oder Anwendungen empfohlen, die einige Stunden Ausfallzeit verkraften können. Bei einer Live-Datenbank kann eine Migration mit einer Auszeit zu Datenverlusten führen.

So führen Sie eine Migration mit geplanter Ausfallzeit durch:

  1. Erstellen Sie eine Dumpdatei der Daten aus der Quelldatenbank.
  2. Laden Sie die Dumpdatei im MySQL-, PostgreSQL-, Avro- oder CSV-Dumpformat in Cloud Storage hoch.
  3. Laden Sie die Dumpdatei mit Dataflow oder dem Spanner-Migrationstool in Spanner.

Wenn Sie mehrere kleine Dumpdateien generieren, können Sie schneller in Spanner schreiben, da Spanner mehrere Dumpdateien parallel lesen kann.

Beachten Sie beim Erstellen einer Dumpdatei aus der Quelldatenbank Folgendes, um einen konsistenten Daten-Snapshot zu generieren:

  • Damit sich die Daten während der Generierung der Dumpdatei nicht ändern, sollten Sie vor dem Ausführen des Dumps eine Lesesperre auf die Quelldatenbank anwenden.
  • Erstellen Sie die Dumpdatei mit einem Lesereplikat aus der Quelldatenbank, bei dem die Replikation deaktiviert ist.

Avro ist das bevorzugte Format für eine Bulk-Migration zu Spanner. Wenn Sie Avro verwenden, beachten Sie Folgendes:

Wenn Sie CSV verwenden, beachten Sie Folgendes:

  • Verwenden Sie die von der Quelle unterstützte CSV-Generierung, um einen CSV-Dump der Daten zu erstellen. Wenn die Daten neue Zeilen enthalten, verwenden Sie ein benutzerdefiniertes Zeilentrennzeichen.
  • Verwenden Sie einen Dataflow-Importjob, um CSV-Daten zu importieren. Sie können eine eigene Dataflow-Importvorlage erstellen oder eine Google Cloud-Importvorlage verwenden. Weitere Informationen finden Sie unter Dataflow-Datenpipeline-Vorlagen.

Wenn Sie MySQL oder PostgreSQL verwenden, können Sie das Spanner-Migrationstool verwenden.

Informationen zum Laden von Daten in Spanner mit benutzerdefinierten Scripts finden Sie unter Leistungsrichtlinien für das Bulk-Laden.

Datenmigration validieren

Bei der Datenvalidierung werden Daten aus der Quell- und der Zieltabelle verglichen, um sicherzustellen, dass sie übereinstimmen.

Das Datenvalidierungstool (DVT) ist ein Open-Source-Tool, mit dem eine Verbindung zu Datenspeichern hergestellt und Prüfungen zwischen der Quelle und Spanner durchgeführt werden können. Wir empfehlen, damit im Rahmen der Migration grundlegende Validierungen durchzuführen, z. B.:

  • Prüfen Sie, ob alle Tabellen erstellt wurden und ob alle Schemazuordnungen korrekt sind .
  • Die Anzahl der Zeilen für jede Tabelle muss übereinstimmen.
  • Extrahieren Sie zufällige Zeilen, um die Richtigkeit zu überprüfen.
  • Prüfen Sie die Spalten (count, sum, avg, min, max, group by).
  • Vergleichen Sie alle zyklischen Redundanzprüfungen oder Hash-Funktionen auf Zeilenebene.

Wenn Sie genauere Prüfungen durchführen möchten, können Sie während der Migration benutzerdefinierte Prüfungen erstellen.

Umstellungs- und Failover-Mechanismen konfigurieren

Migrationen sind oft zeitaufwendig und komplex. Integrieren Sie Fallbacks, um bei einem Fehler während der Migration erhebliche Auswirkungen zu vermeiden. So können Sie mit minimaler Ausfallzeit zur Quelldatenbank zurückkehren.

Derzeit wird empfohlen, Änderungsstreams zu verwenden, um die umgekehrte Replikation durchzuführen und die Daten über einen Stream wie Pub/Sub oder Cloud Storage in die Quelldatenbank zurückzuschreiben.

Diagramm, das den Umstellungsprozess zeigt

Die umgekehrte Replikation muss Folgendes tun:

  • Änderungen an Datentypen oder Inhalten verarbeiten
  • Rückgängig machen Sie alle während der Migration durchgeführten Transformationen.
  • Die Daten werden unter Berücksichtigung der Sharding-Schemata an die entsprechende Zielanwendung gesendet.

Nächste Schritte