Übersicht über die Migration

In diesem Dokument wird die Migration Ihrer Datenbank zu Spanner beschrieben. Wir beschreiben die Migrationsphasen und die Tools, die wir für jede Phase abhängig von Ihrer Quelldatenbank und anderen Faktoren empfehlen. Zu den empfohlenen Tools gehören Google Cloud-Produkte sowie kommerzielle und Open-Source-Tools von Drittanbietern. Gemeinsam helfen diese Tools Ihnen, Migrationen zu beschleunigen und Risiken zu reduzieren.

Jede Spanner-Migration umfasst die folgenden Kernphasen:

  1. Bewerten Sie die Komplexität der Migration.
  2. Migrieren Sie das Schema.
  3. Migrieren Sie Ihre Anwendung.
  4. Leistung testen und optimieren
  5. Migrieren Sie die Daten.
  6. Prüfen Sie die Migration.
  7. Umstellungs- und Failover-Mechanismen konfigurieren

Das folgende Diagramm zeigt diesen Vorgang.

Diagramm des Migrationsprozesses, das Bewertung, Schema- und Anwendungsmigration, Tests und Feinabstimmung, Datenmigration, Validierung und Umstellung zeigt.

In diesen Phasen kann Ihr Migrationsplan abhängig von Faktoren wie Quelle und Größe Ihrer Datenbank, Anforderungen an Ausfallzeiten, Komplexität des Anwendungscodes, Fragmentierungsschema, benutzerdefinierten Funktionen oder Transformationen sowie der Failover- und Replikationsstrategie stark variieren.

Wir stellen Migrationshandbücher für Amazon DynamoDB, MySQL, Oracle Database und PostgreSQL zur Verfügung. Wenn Sie von einer dieser Datenbanken migrieren, folgen Sie auch der entsprechenden Anleitung:

Wenn Sie von einer anderen Datenbank migrieren, benötigen Sie möglicherweise weitere Anpassungen und Tools, die in dieser Anleitung nicht behandelt werden.

Migrationstools

Wir empfehlen die Verwendung der folgenden Tools, die Sie in verschiedenen Phasen der Migration abhängig von Ihrer Quelldatenbank und anderen Faktoren unterstützen. Einige Tools unterstützen nur bestimmte Quelldatenbanken. Für einige Schritte des Prozesses ist kein Tool verfügbar. Sie führen diese Schritte also manuell aus.

  • Das Spanner-Migrationstool ist ein Open-Source-Tool, das grundlegende Bewertungen sowie Schema- und Datenmigrationen ausführt.
  • Das Datenvalidierungstool (DVT) ist eine standardisierte Datenvalidierungsmethode, die von Google entwickelt und von der Open-Source-Community unterstützt wird. Sie können DVT in vorhandene Google Cloud-Produkte einbinden.
  • Datastream ist ein Google Cloud-Dienst, mit dem Sie Change Data Capture-Ereignisse (CDC) und Bulk-Daten aus einer Quelldatenbank lesen können.
  • Dataflow ist ein Google Cloud-Dienst, mit dem Sie mithilfe von Vorlagen große Datenmengen effizienter in Spanner schreiben können. Diese Vorlagen generieren keine Dumpdatei. Sie muss von den Quelldatenbanktools oder Drittanbietertools generiert werden.

In der folgenden Tabelle sind die wichtigsten Tools zusammengefasst, die wir für jede Phase der Migration für einige gängige Quelldatenbanken empfehlen. Sie können mit Anpassungen von anderen Datenbanken migrieren.

Quelldatenbank Umfang bewerten Schema migrieren App migrieren Daten migrieren Datenmigration validieren Umstellung und Failover konfigurieren
MySQL Manuell Spanner-Migrationstool Manuell Spanner-Migrationstool DVT Manuell
PostgreSQL Manuell Spanner-Migrationstool Manuell Spanner-Migrationstool DVT Manuell
Andere Datenbanken Manuell Spanner-Migrationstool Manuell Manuell DVT Manuell

Bewerten Sie die Komplexität der Migration

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

  • Abfragemuster
  • Menge der Anwendungslogik, die von Datenbankfeatures wie gespeicherten Prozeduren und Triggern abhängt
  • Hardwareanforderungen
  • Gesamtbetriebskosten (TCO)

Schema migrieren

Bevor Sie ein Schema zu einem Spanner-Schema migrieren, sollten Sie die Kompatibilität zwischen den Schemas bewerten und das Schema für Spanner optimieren. Beispielsweise können Sie Schlüssel ändern, Indexe löschen oder hinzufügen oder Spalten vorhandener Tabellen hinzufügen oder entfernen. Informationen zum Optimieren des Schemas für Spanner finden Sie unter Best Practices für das Schemadesign und Empfohlene Migrationsstrategien für Primärschlüssel.

Das Spanner-Migrationstool, ein von der Community gepflegtes Open-Source-Tool, das von Google-Entwicklern erstellt wurde, erstellt automatisch ein Spanner-Schema aus Ihrem Quelldatenbankschema. Sie können das Schema mit dem Schemaassistenten für das Spanner-Migrationstool anpassen.

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

  • Eine Dumpdatei von einem lokalen Speicherort oder 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 der Datentypkompatibilität und Empfehlungen
  • Primärschlüssel bearbeiten und Empfehlungen
  • Sekundärindexbearbeitung und Empfehlungen
  • Tabellenbearbeitung und Empfehlungen verschachteln
  • Allgemeine Empfehlungen für das Spanner-Schemadesign
  • Schemaversionsverwaltung
  • Kollaborative Schemaänderung

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

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

Anwendung migrieren

Für eine Datenbankmigration sind verschiedene Treiber und Bibliotheken sowie eine Vergütung für Funktionen erforderlich, die Spanner nicht unterstützt. Damit Sie ähnliche Funktionen erreichen und die Stärken von Spanner optimieren können, müssen Sie möglicherweise den Code, die Anwendungsabläufe und die Architektur ändern.

Im Folgenden finden Sie einige der Änderungen, die erforderlich sind, um Ihre Anwendung zu Spanner zu migrieren:

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

Möglicherweise müssen Sie auch Änderungen an der Transaktionsabwicklung vornehmen. Dafür stehen keine Tools zur Verfügung, sodass Sie diesen Schritt manuell ausführen müssen. Beachten Sie dabei Folgendes:

  • Die maximale Anzahl von Mutationen pro Commit beträgt 40.000. Jeder sekundäre Index einer Tabelle ist eine zusätzliche Mutation pro Zeile. Informationen zum Ändern von Daten mit Mutationen finden Sie unter Daten mit Mutationen einfügen, aktualisieren und löschen. Verwenden Sie partitionierte DML, um große Datenmengen zu ändern.
  • Auf der Transaktionsisolationsebene ist keine Verarbeitung erforderlich, da Spanner-Transaktionen isoliert sind.
  • Da Spanner linearisierbar ist, verarbeitet es standardmäßig Konsistenz und Sperre.

Schema- und Anwendungsleistung testen und optimieren

Die Leistungsoptimierung ist ein iterativer Prozess, bei dem Sie Messwerte wie CPU-Auslastung und Latenz basierend auf einer Teilmenge Ihrer Daten bewerten, Ihr Schema und Ihre Anwendung anpassen, um die Leistung zu verbessern, und Tests wiederholen.

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

Insbesondere für den Produktionstraffic ist die Leistungsoptimierung wichtig, um Überraschungen zu vermeiden. Die Leistungsoptimierung ist effektiver, je näher die Einrichtung dem Durchsatz und den Datengrößen des Live-Produktionstraffics entspricht.

So testen und optimieren Sie das Schema und die Anwendungsleistung:

  1. Eine Teilmenge Ihrer Daten in eine Spanner-Datenbank hochladen. Weitere Informationen finden Sie unter Daten migrieren.
  2. Verweisen Sie die Anwendung auf Spanner.
  3. Prüfen Sie anhand grundlegender Abläufe die Richtigkeit.
  4. Prüfen Sie, ob die Leistung Ihren Erwartungen entspricht, indem Sie Lasttests für Ihre Anwendung durchführen. Informationen zum Identifizieren und Optimieren der teuersten Abfragen finden Sie unter Probleme mit der Abfrageleistung mithilfe von Abfragestatistiken erkennen. Insbesondere die folgenden Faktoren können zu einer suboptimalen Abfrageleistung beitragen:
    1. Ineffiziente Abfragen: Informationen zum Schreiben 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, die durch Transaktionssperren verursacht werden, finden Sie unter Transaktionen ermitteln, die hohe Latenzen verursachen können.
    4. Ineffizientes Schemadesign: Wenn das Schema nicht gut konzipiert ist, ist die Abfrageoptimierung nicht sehr nützlich.
    5. Hotspoting: Hotspots in Spanner begrenzen den Schreibdurchsatz, insbesondere bei Anwendungen mit einer hohen Anzahl von Abfragen pro Sekunde. Prüfen Sie in der Google Cloud Console die Key Visualizer-Statistiken, um Hotspots oder Anti-Muster zu identifizieren. Weitere Informationen zum Vermeiden von Hotspots finden Sie unter Primärschlüssel zur Vermeidung von Hotspots auswählen.
  5. Wenn Sie Schemas oder Indexe ändern, wiederholen Sie die Korrektheit und Leistungstests, bis Sie zufriedenstellende Ergebnisse erhalten.

Weitere Informationen zum Optimieren der Datenbankleistung erhalten Sie vom Spanner-Support.

Daten migrieren

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

Abhängig von Ihrer Quelldatenbank können Sie die Datenbank möglicherweise mit minimalen Ausfallzeiten migrieren oder Sie benötigen längere Ausfallzeiten.

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

Die folgende Tabelle zeigt die Unterschiede zwischen Migrationen mit minimaler Ausfallzeit und Migrationen mit mehr Ausfallzeiten, einschließlich unterstützter Quellen, Formate, Größe und Durchsatz.

Migration mit minimaler Ausfallzeit Migration mit Ausfallzeiten
Unterstützte Quellen MySQL, PostgreSQL Jede Datenbank, die in CSV oder Avro exportieren kann.
Unterstützte Datenformate Direkt kommunizieren. Siehe Direkte Verbindung zu einer MySQL-Datenbank. 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 aus MySQL, PostgreSQL und Oracle Database. 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, der als Change Data Capture (CDC) bezeichnet wird.

Migrationen mit minimaler Ausfallzeit tragen zwar zum Schutz Ihrer Daten bei, der Prozess beinhaltet jedoch unter anderem folgende Herausforderungen:

  • CDC-Daten während der Migration des Snapshots speichern.
  • CDC-Daten in Spanner schreiben, während der eingehende CDC-Stream erfasst wird
  • Dafür sorgen, dass die CDC-Daten zu Spanner schneller migriert werden als der eingehende CDC-Stream.

Das Spanner-Migrationstool orchestriert die folgenden Prozesse für Sie, um eine Migration mit minimaler Ausfallzeit zu verwalten:

  1. Richtet einen Cloud Storage-Bucket zum Speichern von CDC-Ereignissen in der Quelldatenbank ein, während die Snapshot-Migration ausgeführt wird.
  2. Richtet einen Datastream-Job ein, der die Massenlast 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 zum Migrieren der CDC-Ereignisse zu Spanner ein.

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 aufholt. 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 Ausfallzeiten

Wenn die Datenbank bei anderen Datenbanken als MySQL, PostgreSQL oder Oracle Database Daten in CSV oder Avro exportieren kann, können Sie mit Ausfallzeit zu Spanner migrieren. Wir empfehlen die Verwendung von Dataflow oder dem Spanner-Migrationstool.

Migrationen mit Ausfallzeiten werden nur für Testumgebungen oder Anwendungen empfohlen, die eine Ausfallzeit von einigen Stunden verarbeiten können. In einer Live-Datenbank kann eine Migration mit Ausfallzeiten zu Datenverlusten führen.

Führen Sie die folgenden allgemeinen Schritte aus, um eine Migration nach einer Ausfallzeit durchzuführen:

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

Wenn Sie mehrere kleine Dumpdateien generieren, geht das Schreiben in Spanner schneller, da Spanner mehrere Dumpdateien gleichzeitig lesen kann.

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

  • Wenn Sie verhindern möchten, dass sich die Daten während der Generierung der Dumpdatei ändern, wenden Sie vor dem Ausführen des Dumps eine Lesesperre auf die Quelldatenbank an.
  • Generieren Sie die Dumpdatei mit einem Lesereplikat aus der Quelldatenbank mit deaktivierter Replikation.

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

Wenn Sie CSV verwenden, sollten Sie Folgendes berücksichtigen:

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

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

Informationen zur Verwendung von benutzerdefinierten Skripts zum Laden von Daten in Spanner finden Sie unter Leistungsrichtlinien für das Laden im Bulk.

Datenmigration validieren

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

Das Datenvalidierungstool (DVT) ist ein Open-Source-Tool, das eine Verbindung zu Datenspeichern herstellen und Prüfungen zwischen der Quelle und Spanner durchführen kann. Wir empfehlen, es für grundlegende Validierungen im Rahmen Ihrer Migration zu verwenden, z. B.:

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

Wenn Sie spezifischere Validierungen durchführen möchten, erstellen Sie während der Migration benutzerdefinierte Prüfungen.

Umstellungs- und Failover-Mechanismen konfigurieren

Migrationen sind oft zeitaufwendig und komplex. Erstellen Sie Fallbacks, um erhebliche Auswirkungen im Falle eines Fehlers während der Migration zu vermeiden. So können Sie mit minimaler Ausfallzeit zurück zur Quelldatenbank zurückwechseln.

Derzeit wird empfohlen, Änderungsstreams für die umgekehrte Replikation zu verwenden und über einen Stream wie Pub/Sub oder Cloud Storage zurück in die Quelldatenbank zu schreiben.

Das Diagramm zeigt den Umstellungsprozess.

Die Reverse-Replikation muss Folgendes tun:

  • Änderungen an Datentypen oder Inhalten verarbeiten
  • Machen Sie alle Transformationen rückgängig, die während der Migration ausgeführt wurden.
  • Übertragen Sie die Daten per Push an das entsprechende Ziel und berücksichtigen Sie dabei die Fragmentierungsschemas für die Quelle.