Von AWS zu Google Cloud migrieren: Von Amazon RDS und Amazon Aurora for MySQL zu Cloud SQL for MySQL migrieren

Last reviewed 2024-08-16 UTC

Google Cloud bietet Tools, Produkte, Anleitungen und professionelle Dienstleistungen, um von Amazon Relational Database Service (RDS) oder Amazon Aurora zu Cloud SQL for MySQL zu migrieren.

Dieses Dokument richtet sich an Cloud- und Datenbankadministratoren, die Planung, Implementierung und Validierung eines Datenbankmigrationsprojekts durchführen möchten. Es ist auch für Entscheidungsträger gedacht, die die Möglichkeit einer Migration in Betracht ziehen und ein Beispiel wollen, wie eine Migration aussehen könnte.

In diesem Dokument geht es um eine homogene Datenbankmigration, also eine Migration, in denen Quell- und Zieldatenbank dieselbe Datenbanktechnologie haben. In diesem Migrationsleitfaden ist die Quelle Amazon RDS oder Amazon Aurora for MySQL und das Ziel Cloud SQL for MySQL.

Dieses Dokument ist Teil einer mehrteiligen Reihe zur Migration von AWS zu Google Cloud, die folgende Dokumente enthält:

• Jetzt starten
• Von Amazon EC2 zu Compute Engine migrieren
• Von Amazon S3 zu Cloud Storage migrieren
• Von Amazon EKS zu GKE migrieren
• Von Amazon RDS und Amazon Aurora for MySQL zu Cloud SQL for MySQL migrieren (dieses Dokument)
• Von Amazon RDS und Amazon Aurora for PostgreSQL zu Cloud SQL for PostgreSQL und AlloyDB for PostgreSQL migrieren
• Von Amazon RDS for SQL Server zu Cloud SQL for SQL Server migrieren
• Von AWS Lambda zu Cloud Run migrieren

Für diese Migration zu Google Cloud empfehlen wir die Ausführung des unter Migrate to Google Cloud: Erste Schritte beschriebenen Migrations-Frameworks.

Diese Grafik veranschaulicht den Migrationsprozess:

Die Migration von Ihrer Quellumgebung zu Google Cloud kann in einer Reihe von Iterationen erfolgen. Beispielsweise können Sie einige Arbeitslasten zuerst und andere später migrieren. Für jede separate Migrationsiteration folgen Sie den Phasen des allgemeinen Migrations-Frameworks:

1. Arbeitslasten und Daten bewerten und erkennen.
2. Grundlage in Google Cloud planen und erstellen.
3. Arbeitslasten und Daten zu Google Cloud migrieren.
4. Google Cloud-Umgebung optimieren.

Weitere Informationen zu den Phasen dieses Frameworks finden Sie unter Zu Google Cloud migrieren: Erste Schritte.

Um einen effektiven Migrationsplan zu entwerfen, empfehlen wir, jeden Schritt des Plans zu validieren und sicherzustellen, dass Sie eine Rollback-Strategie haben. Informationen zur Validierung Ihres Migrationsplans finden Sie unter Migrate to Google Cloud: Best Practices zur Validierung eines Migrationsplans.

Quellumgebung bewerten

In der Bewertungsphase bestimmen Sie die Anforderungen und Abhängigkeiten für die Migration Ihrer Quellumgebung zu Google Cloud.

Die Bewertungsphase ist für den Erfolg der Migration entscheidend. Sie benötigen umfassende Kenntnisse über die zu migrierenden Arbeitslasten, deren Anforderungen, Abhängigkeiten und über Ihre aktuelle Umgebung. Sie müssen Ihre Ausgangssituation verstehen, um eine Google Cloud-Migration erfolgreich planen und ausführen zu können.

Die Bewertungsphase umfasst die folgenden Aufgaben:

1. Ein umfassendes Inventar Ihrer Arbeitslasten erstellen.
2. Arbeitslasten nach ihren Attributen und Abhängigkeiten katalogisieren.
3. Die Teams auf Google Cloud vorbereiten.
4. Tests und Proofs of Concept in Google Cloud erstellen.
5. Die Gesamtbetriebskosten (TCO) der Zielumgebung berechnen.
6. Migrationsstrategie für Ihre Arbeitslasten auswählen.
7. Tools für die Migration auswählen.
8. Migrationsplan und Zeitplan definieren.
9. Migrationsplan validieren.

In der Phase der Datenbankbewertung können Sie die Größe und die Spezifikationen Ihrer Ziel-Cloud SQL-Datenbankinstanz auswählen, die der Quelle für ähnliche Leistungsanforderungen entspricht. Achten Sie dabei besonders auf Laufwerkgröße und Durchsatz, IOPS und Anzahl der vCPUs. Migrationen können aufgrund einer falschen Größe der Zieldatenbankinstanz schwierig sein oder fehlschlagen. Falsche Größen können zu langen Migrationszeiten, Problemen mit der Datenbankleistung, Datenbankfehlern und Problemen mit der Anwendungsleistung führen. Beachten Sie bei der Auswahl der Cloud SQL-Instanz, dass die Laufwerkleistung von der Laufwerkgröße und der Anzahl der vCPUs abhängt.

Die folgenden Abschnitte basieren auf dem Dokument Zu Google Cloud migrieren: Arbeitslasten bewerten und erkennen und integrieren die Informationen aus diesem Dokument.

Inventar Ihrer Amazon RDS- oder Amazon Aurora-Instanzen erstellen

Um den Umfang der Migration zu definieren, erstellen Sie ein Inventar und erfassen Informationen zu Ihren Amazon RDS- oder Amazon Aurora-Instanzen. Wir empfehlen, diesen Prozess mithilfe spezieller Tools zu automatisieren, da manuelle Ansätze fehleranfällig sind und zu falschen Annahmen führen können.

Amazon RDS oder Amazon Aurora und Cloud SQL haben möglicherweise keine ähnlichen Funktionen, Spezifikationen oder Abläufe. Einige Funktionen sind möglicherweise anders implementiert oder nicht verfügbar. Unterschiede können sich beispielsweise auf Infrastruktur, Speicher, Authentifizierung und Sicherheit, Replikation, Sicherung, Hochverfügbarkeit, Ressourcenkapazitätsmodell sowie Integrationen und Erweiterungen bestimmter Datenbankmodulfunktionen beziehen. Je nach Datenbank-Engine-Typ, Instanzgröße und Architektur können sich auch die Standardwerte der Datenbankparametereinstellungen unterscheiden.

Benchmarking kann Ihnen helfen, die zu migrierenden Arbeitslasten besser zu verstehen und trägt dazu bei, die richtige Architektur der Zielumgebung der Migration zu definieren. Es ist wichtig, Informationen zur Leistung zu erfassen, um die Leistungsanforderungen der Google Cloud-Zielumgebung zu schätzen. Benchmarking-Konzepte und -Tools werden in der Test- und Validierungsphase des Migrationsprozesses durchgeführt, aber sie gelten auch für die Inventarerstellungsphase.

Tools für Bewertungen

Für eine erste Übersicht über Ihre aktuelle Infrastruktur empfehlen wir die Verwendung des Google Cloud-Migrationscenters zusammen mit anderen spezialisierten Tools zur Datenbankbewertung wie migVisor und das Datenbanktool zur Migrationsberwertung (DMA)

Mit dem Migrationscenter können Sie eine umfassende Bewertung Ihrer Anwendungs- und Datenbanklandschaft, einschließlich der technischen Eignung für eine Datenbankmigration zu Google Cloud ausführen. Sie erhalten Größe und Konfigurationsempfehlungen für jede Quelldatenbank und erstellen einen Bericht zu den Gesamtbetriebskosten (TCO) für Server und Datenbanken.

Weitere Informationen zur Bewertung Ihrer AWS-Umgebung mithilfe des Migrationscenters, siehe Daten von anderen Cloud-Anbietern importieren

Neben dem Migrationscenter können Sie das spezielle Tool migVisor verwenden. migVisor unterstützt eine Vielzahl von Datenbankmodulen und ist besonders geeignet für heterogene Migrationen. Eine Einführung in migVisor finden Sie in der migVisor-Übersicht.

migVisor kann Artefakte und inkompatible proprietäre Datenbank-Features identifizieren, die zu Migrationsfehlern führen können, und kann auf Umgehungsmöglichkeiten hinweisen. migVisor kann auch eine Ziellösung für Google Cloud empfehlen, einschließlich der anfänglichen Größe und Architektur.

Die migVisor-Datenbankbewertung enthält Folgendes:

• Umfassende Suche und Analyse aktueller Datenbankimplementierungen.
• Detaillierter Bericht zur Komplexität der Migration, basierend auf den proprietären Features, die von Ihrer Datenbank verwendet werden.
• Finanzbericht mit Details zu den Kosteneinsparungen nach der Migration, Migrationskosten und einem neuen Betriebsbudget.
• Plan für eine schrittweise Migration, um Datenbanken und zugehörige Anwendungen mit minimaler Unterbrechung des Geschäftsbetriebs zu verschieben.

Beispiele für Bewertungsergebnisse finden Sie unter migVisor – Tool zur Bewertung der Cloud-Migration.

Hinweis: migVisor erhöht vorübergehend die Auslastung des Datenbankservers. In der Regel liegt diese zusätzliche Last unter 3 % und kann außerhalb der Spitzenzeiten ausgeführt werden.

Mithilfe der Bewertungsausgabe von migVisor können Sie eine vollständige Bestandsaufnahme Ihrer RDS-Instanzen erstellen. Der Bericht enthält allgemeine Eigenschaften (Version und Edition des Datenbankmoduls, CPUs und Arbeitsspeichergröße) sowie Details zur Datenbanktopologie, zu Sicherungsrichtlinien, Parametereinstellungen und verwendeten speziellen Anpassungen.

Wenn Sie lieber Open-Source-Tools verwenden, können Sie Data-Collector-Scripts mit (oder anstelle) den genannten Tools verwenden. Mit diesen Skripts können Sie detaillierte Informationen (über Arbeitslasten, Funktionen, Datenbankobjekte und Datenbankcode) und Ihr Datenbankinventar erstellen. Außerdem bieten Skripts in der Regel eine detaillierte Datenbank, Migrationsbewertung, einschließlich einer Schätzung des Migrationsaufwands.

Wir empfehlen das Open-Source-Tool DMA, das von Google-Entwicklern entwickelt wurde. Es bietet eine vollständige und genaue Datenbankbewertung, einschließlich der verwendeten Funktionen, der Datenbanklogik und der Datenbankobjekte (einschließlich Schemas, Tabellen, Ansichten, Funktionen, Trigger und gespeicherte Prozeduren).

Laden Sie zur Verwendung von DMA die Skripts zur Erfassung für Ihr Datenbankmodul aus dem Git-Repository und folgen Sie der Anleitung. Senden Sie die Ausgabedateien zur Analyse an Google Cloud. Google Cloud erstellt und liefert eine Bewertungsübersicht für die Datenbank und gibt Empfehlungen für die nächsten Schritte bei der Migration.

Migrationsumfang und vertretbare Ausfallzeiten ermitteln und dokumentieren

In dieser Phase dokumentieren Sie wichtige Informationen, die Ihre Migrationsstrategie und -tools beeinflussen. Mittlerweile können Sie die folgenden Fragen beantworten:

• Sind Ihre Datenbanken größer als 5 TB?
• Gibt es große Tabellen in Ihrer Datenbank? Sind sie größer als 16 TB?
• Wo befinden sich die Datenbanken (Regionen und Zonen) und wie nah sind sie an den Anwendungen?
• Wie oft ändern sich die Daten?
• Welches Datenkonsistenzmodell verwenden Sie?
• Welche Optionen gibt es für Zieldatenbanken?
• Wie kompatibel sind die Quell- und Zieldatenbanken?
• Müssen sich die Daten an bestimmten physischen Standorten befinden?
• Gibt es Daten, die komprimiert und archiviert werden können, oder gibt es Daten, die überhaupt keine Migration erforderlich?

Legen Sie fest, welche Daten beibehalten und welche migriert werden sollen, um den Migrationsbereich zu definieren. Die Migration aller Ihrer Datenbanken kann viel Zeit und Mühe erfordern. Einige Daten können in den Sicherungen Ihrer Quelldatenbank verbleiben. Zum Beispiel alte Logging-Tabellen oder Archivdaten, die möglicherweise nicht benötigt werden. Je nach Strategie und Tools können Sie die Daten auch nach der Migration verschieben.

Legen Sie Referenzwerte für die Datenmigration fest, mit denen Sie die Ergebnisse und Auswirkungen vergleichen und bewerten können. Diese Baselines sind Referenzpunkte, die den Zustand Ihrer Daten vor und nach der Migration darstellen und Ihnen bei der Entscheidungsfindung helfen. Es ist wichtig, Messungen in der Quellumgebung vorzunehmen, um den Erfolg Ihrer Datenmigration zu bewerten. Zu diesen Messungen gehören:

• Größe und Struktur Ihrer Daten
• Vollständigkeit und Konsistenz Ihrer Daten
• Dauer und Leistung der wichtigsten Geschäftstransaktionen und Prozesse.

Legen Sie fest, wie lange die Ausfallzeit maximal sein darf. Welche geschäftlichen Auswirkungen haben Ausfallzeiten? Gibt es Zeiträume mit geringer Datenbankaktivität, in denen weniger Nutzer von Ausfallzeiten betroffen sind? Wenn ja, wie lang sind diese Zeiträume und wann treten sie auf? Ziehen Sie in Erwägung, eine teilweise Ausfallzeit für Schreibzugriffe einzuplanen, während Lesezugriffe weiterhin bedient werden.

Bereitstellungs- und Verwaltungsprozess bewerten

Nachdem Sie die Inventare erstellt haben, bewerten Sie die Betriebs- und Bereitstellungsprozesse für Ihre Datenbank, um zu bestimmen, wie diese angepasst werden müssen, um die Migration zu erleichtern. Diese Prozesse sind grundlegend dafür, wie Sie Ihre Produktionsumgebung vorbereiten und pflegen.

Überlegen Sie, wie Sie die folgenden Aufgaben ausführen:

• Definieren und erzwingen Sie Sicherheitsrichtlinien für Ihre Instanzen: Sie müssen zum Beispiel Amazon Security Groups ersetzen. Sie können Google IAM-Rollen, VPC-Firewallregeln und VPC Service Controls verwenden, um den Zugriff auf Ihre Cloud SQL-Instanzen zu steuern und die Daten innerhalb einer VPC einzuschränken.

• Instanzen patchen und konfigurieren: Ihre vorhandenen Bereitstellungstools müssen möglicherweise aktualisiert werden. Vielleicht verwenden Sie benutzerdefinierte Konfigurationseinstellungen in Amazon-Parametergruppen oder Amazon-Optionsgruppen. Ihre Bereitstellungstools müssen möglicherweise angepasst werden, damit Sie Google Cloud Storage oder Secret Manager zum Lesen solcher benutzerdefinierten Konfigurationslisten verwenden können.

• Monitoring- und Benachrichtigungsinfrastruktur verwalten: Messwertkategorien für Ihre Amazon-Quelldatenbankinstanzen sorgen für Beobachtbarkeit während des Migrationsprozess. Zu den Messwertkategorien gehören unter anderem Amazon CloudWatch, Leistungsstatistiken, erweiterte Überwachung und Betriebssystemprozesslisten.

Bewertung abschließen

Nachdem Sie das Inventar aus Ihrer Amazon RDS- oder Amazon Aurora-Umgebung erstellt haben, schließen Sie die restlichen Aktivitäten der Bewertungsphase ab, wie unter Zu Google Cloud migrieren: Arbeitslasten bewerten und erkennen beschrieben.

Grundlage planen und aufbauen

In der Planungs- und Erstellungsphase stellen Sie die Infrastruktur bereit und konfigurieren sie für Folgendes:

• Unterstützung Ihrer Arbeitslasten in Ihrer Google Cloud-Umgebung.
• Verbinden Ihrer Quellumgebung und Ihrer Google Cloud-Umgebung, um die Migration abzuschließen.

Die Planungs- und Erstellungsphase besteht aus den folgenden Aufgaben:

1. Erstellen Sie eine Ressourcenhierarchie.
2. Konfigurieren Sie Identity and Access Management (IAM) von Google Cloud.
3. Richten Sie die Abrechnung ein.
4. Richten Sie die Netzwerkverbindung ein.
5. Erhöhen Sie die Sicherheit.
6. Logging, Monitoring und Benachrichtigungen einrichten

Weitere Informationen zu den einzelnen Aufgaben finden Sie unter Migrate to Google Cloud: Planen und erstellen Sie Ihre Grundlage.

Wenn Sie den Database Migration Service für die Migration verwenden möchten, finden Sie unter Netzwerkmethoden für MySQL Informationen zu den Netzwerkkonfigurationen, die für Migrationsszenarien verfügbar sind.

Monitoring und Benachrichtigungen

Verwenden Sie Google Cloud Monitoring, welches vordefinierte Dashboards für verschiedene Google Cloud-Produkte, einschließlich eines Monitoring-Dashboards von Cloud SQL enthält. Alternativ können Sie auch Überwachungslösungen von Drittanbietern verwenden, die in die Google Cloud integriert sind, wie Datadog und Splunk. Weitere Informationen finden Sie unter Beobachtbarkeit von Datenbanken.

Amazon RDS- und Amazon Aurora for MySQL-Instanzen zu Cloud SQL for MySQL migrieren

So migrieren Sie Ihre Instanzen:

1. Wählen Sie die Migrationsstrategie aus: kontinuierliche Replikation oder geplante Wartung.

2. Wählen Sie die Migrationstools je nach gewählter Strategie und Anforderungen.

3. Definieren Sie den Migrationsplan und den Zeitplan für jede Datenbankmigration, einschließlich Vorbereitungs- und Ausführungsaufgaben.

4. Definieren Sie die Vorbereitungsaufgaben, die ausgeführt werden müssen, um sicherzustellen, dass das Migrationstool richtig funktionieren kann.

5. Definieren Sie die Ausführungsaufgaben, einschließlich der Arbeitsaktivitäten, die die Migration implementieren.

6. Definieren Sie Fallback-Szenarien für jede Ausführungsaufgabe.

7. Führen Sie Tests und Validierungen durch, die in einer separaten Staging-Umgebung durchgeführt werden können.

8. Führen Sie die Migration aus.

9. Führen Sie die Produktionsumstellung durch.

10. Bereinigen Sie die Quellumgebung und konfigurieren Sie die Zielinstanz.

11. Optimieren Sie die Kampagne.

Die einzelnen Phasen werden in folgenden Abschnitten beschrieben.

Migrationsstrategie auswählen

In diesem Schritt haben Sie genügend Informationen, um eine der folgenden Migrationsstrategien zu bewerten und für jede Datenbank auszuwählen, die am besten zu Ihrem Anwendungsfall passt:

• Geplante Wartung (auch als einmalige Migration bezeichnet): Dieser Ansatz ist ideal, wenn Sie sich Ausfallzeiten leisten können. Diese Option ist in Bezug auf Kosten und Komplexität relativ günstig, da Ihre Arbeitslasten und Dienste nicht viel Refaktorierung erfordern. Schlägt die Migration jedoch fehl, müssen Sie den Prozess neu starten, was die Ausfallzeit verlängert.

• Kontinuierliche Replikation (auch als „Trickle-Migration“ bezeichnet): Für geschäftskritischen Datenbanken bietet diese Option ein geringeres Risiko von Datenverlusten und nahezu keine Ausfallzeiten. Der Aufwand ist in mehrere Schritte unterteilt. Tritt ein Fehler auf, nehmen Rollback und Wiederholung weniger Zeit in Anspruch. Die Einrichtung ist jedoch komplexer und erfordert mehr Planung und Zeit. Zusätzlicher Aufwand ist auch für die Refaktorierung der Anwendungen erforderlich, die eine Verbindung zu Ihren Datenbankinstanzen herstellen. Sie haben folgende Möglichkeiten:

  • Mit dem Ansatz Y (Schreiben und Lesen), der eine Form der parallelen Migration ist, bei der Daten aus beiden Quellen dupliziert und Zielinstanzen während der Migration erstellt werden.
  • Die Verwendung eines Mikrodiensts für den Datenzugriff, der den Refaktorierungsaufwand für den Ansatz Y (Schreiben und Lesen) reduziert.

Weitere Informationen zu Datenmigrationsstrategien finden Sie unter Ansätze zur Datenmigration bewerten.

Das folgende Diagramm zeigt ein Flussdiagramm, das auf Beispielfragen basiert, die Sie sich bei der Entscheidung für die Migrationsstrategie für eine einzelne Datenbank stellen könnten:

Das obige Flussdiagramm zeigt die folgenden Entscheidungspunkte:

• Können Sie sich Ausfallzeiten leisten?

  • Falls nicht, übernehmen Sie die Migrationsstrategie für kontinuierliche Replikation.
  • Falls ja, fahren Sie mit dem nächsten Entscheidungspunkt fort.

• Ist die Ausfallzeit in Form eines Umstellungsfensters für Sie beim Migrieren der Daten tragbar? Das Umstellungsfenster gibt an, wie lange es dauert, die Datenbank zu sichern, sie zu Cloud SQL zu übertragen, sie wiederherzustellen, und dann zu Ihren Anwendungen zu wechseln.

  • Falls nicht, übernehmen Sie die Migrationsstrategie für kontinuierliche Replikation.
  • Falls ja, wenden Sie die Migrationsstrategie für die geplante Wartung an.

Die Strategien können für verschiedene Datenbanken variieren, auch wenn sie sich in derselben Instanz befinden. Eine Kombination aus Strategien kann optimale Ergebnisse liefern. Beispiel: Migration kleiner und selten genutzter Datenbanken mit dem Ansatz der geplanten Wartung, aber kontinuierliche Replikation für geschäftskritische Datenbanken, bei denen Ausfallzeiten teuer sind.

Normalerweise gilt eine Migration als abgeschlossen, wenn der Wechsel zwischen der anfänglichen Quellinstanz und der Zielinstanz stattfindet. Alle Replizierungen (falls verwendet) werden beendet und alle Lese- und Schreibvorgänge werden auf der Zielinstanz ausgeführt. Wenn Sie wechseln, während beide Instanzen synchronisiert sind, gehen keine Daten verloren und die Ausfallzeit ist minimal.

Weitere Informationen zu Datenmigrationsstrategien und -bereitstellungen finden Sie unter Klassifizierung von Datenbankmigrationen.

Ausfallzeiten und Auswirkungen auf die Migration minimieren

Migrationskonfigurationen, die keine Ausfallzeiten für die Anwendung verursachen, erfordern eine kompliziertere Einrichtung. Achten Sie darauf, dass die Einrichtung nicht zu kompliziert ist und dass die Wartungszeit auf Zeiten mit wenig Traffic gelegt wird.

Jede Migrationsstrategie hat einen Kompromiss und einige Auswirkungen auf den Migrationsprozess. Replikationsprozesse erfordern z. B. eine zusätzliche Belastung Ihrer Quellinstanzen, und Ihre Anwendungen könnten durch die Replikationsverzögerung beeinträchtigt werden. Anwendungen (und Kunden) müssen möglicherweise während Ausfallzeiten der Anwendung warten, zumindest so lange, wie die Replikationsverzögerung vor der Verwendung andauert, bevor sie die neue Datenbank nutzen können. In der Praxis können die folgenden Faktoren die Ausfallzeit verlängern:

• Datenbankabfragen können einige Sekunden dauern. Während der Migration werden laufende Abfragen möglicherweise abgebrochen.
• Es kann einige Zeit dauern, bis sich der Cache füllt, wenn die Datenbank groß ist oder über einen großen Pufferspeicher verfügt.
• Anwendungen, die in der Quelle beendet und in Google Cloud neu gestartet wurden, haben möglicherweise eine kleine Verzögerung bis zur Verbindung mit der Google Cloud Datenbankinstanz.
• Die Netzwerkrouten zu den Anwendungen müssen neu festgelegt werden. Je nachdem, wie DNS-Einträge eingerichtet sind, kann dies einige Zeit dauern. Wenn Sie das DNS aktualisieren, reduzieren Sie TTL vor der Migration.

Mit den folgenden gängigen Praktiken können Sie Ausfallzeiten und Auswirkungen minimieren:

• Ermitteln Sie einen Zeitraum, in dem die Ausfallzeit eine minimale Auswirkung auf Ihre Arbeitslasten hat. Zum Beispiel außerhalb der normalen Geschäftszeiten, an Wochenenden oder während anderer geplanter Wartungsfenster.
• Identifizieren Sie Teile Ihrer Arbeitslasten, die in verschiedenen Phasen migriert und in die Produktion übernommen werden können. Ihre Anwendungen haben möglicherweise verschiedene Komponenten, die isoliert, angepasst und migriert werden können, ohne das dies Auswirkungen hat. Beispiele: Frontends, CRM-Module, Backend-Dienste und Plattformen für das Berichtswesen. Solche Module könnten eigene Datenbanken haben, die zu einem früheren oder späteren Zeitpunkt für die Migration vorgesehen werden können.
• Wenn Sie sich eine gewisse Latenz für die Zieldatenbank leisten können, sollten Sie eine schrittweise Migration implementieren. Verwenden Sie inkrementelle, batchbasierte Datenübertragungen und passen Sie einen Teil Ihrer Arbeitslasten an die veralteten Daten in der Zielinstanz an.
• Prüfen Sie, ob Sie Ihre Anwendungen so refaktorieren können, dass die Auswirkungen der Migration minimal sind. Passen Sie beispielsweise Ihre Anwendungen so an, dass sie sowohl in Quell- als auch in Zieldatenbanken schreiben können und implementieren Sie daher eine Replikation auf Anwendungsebene.

Auswahl der Tools für die Migration

Der wichtigste Faktor für eine erfolgreiche Migration ist die Auswahl des richtigen Migrationstools. Nachdem Sie eine Migrationsstrategie festgelegt haben, prüfen und entscheiden Sie sich für ein Migrationstool.

Es gibt viele Tools, die jeweils für bestimmte Migrationsanwendungsfälle optimiert sind. Anwendungsfälle können Folgendes umfassen:

• Migrationsstrategie (geplante Wartung oder kontinuierliche Replikation)
• Quell- und Zieldatenbank-Engines und -Engineversionen.
• Umgebungen, in denen sich Quell- und Zielinstanzen befinden.
• Datenbankgröße Je größer die Datenbank, desto länger dauert es, die erste Sicherung zu migrieren.
• Häufigkeit der Datenbankänderungen.
• Verfügbarkeit von verwalteten Diensten für die Migration

Für eine nahtlose Migration und Umstellung können Sie Anwendungsbereitstellungsmuster, Infrastrukturorchestrierung und benutzerdefinierte Migrationsanwendungen verwenden. Mit speziellen Tools, sogenannten verwalteten Migrationsdiensten, lässt sich der Vorgang jedoch vereinfachen. So können Sie Daten, Anwendungen oder sogar ganze Infrastrukturen von einer Umgebung in eine andere verschieben. Sie führen die Datenextraktion aus den Quelldatenbanken aus, übertragen die Daten sicher in die Zieldatenbanken und können die Daten optional während der Übertragung ändern. Mit diesen Funktionen kapseln sie die komplexe Logik der Migration ein und bieten Funktionen zur Überwachung der Migration.

Verwaltete Migrationsdienste bieten folgende Vorteile:

• Ausfallzeiten minimieren: Dienste verwenden die integrierten Replikationsfunktionen der Datenbankmodule, sofern verfügbar, und stufen Replikate hoch.

• Datenintegrität und -sicherheit gewährleisten: Die Daten werden sicher und zuverlässig von der Quell- zur Zieldatenbank übertragen.

• Konsistente Migration: Andere Migrationsverfahren und -muster können durch die Verwendung von ausführbaren Datenbankmigrationsdateien, die Sie verwalten und überwachen können, in einer konsistenten, gemeinsamen Schnittstelle konsolidiert werden.

• Stabile und bewährte Migrationsmodelle anbieten: Datenbankmigrationen sind seltene, aber wichtige Ereignisse. Um Anfängerfehler und Probleme mit bestehenden Lösungen zu vermeiden, können Sie Tools von erfahrenen Experten verwenden, anstatt eine benutzerdefinierte Lösung zu erstellen.

• Kosten optimieren: Verwaltete Migrationsdienste können höhere Kosten verursachen als zusätzliche Server und Ressourcen für benutzerdefinierte Migrationslösungen bereitzustellen.

In den folgenden Abschnitten werden die Empfehlungen für Migrationstools beschrieben, die von der gewählten Migrationsstrategie abhängen.

Tools für geplante Wartungsmigrationen

Das folgende Diagramm zeigt ein Flussdiagramm mit Fragen, die Ihnen bei der Auswahl des Migrationstools für eine einzelne Datenbank helfen können, wenn Sie eine Migrationsstrategie für die geplante Wartung verwenden:

Das obige Flussdiagramm zeigt die folgenden Entscheidungspunkte:

• Bevorzugen Sie verwaltete Migrationsdienste?
  • Falls ja, empfehlen wir den Database Migration Service.
  • Falls nicht, empfehlen wir, die Migration mithilfe der integrierten Sicherungen der Datenbank-Engine durchzuführen.

Die Verwendung eines verwalteten Migrationsdienstes bietet einige Vorteile, die im Abschnitt Auswahl der Tools für die Migration dieses Dokuments beschrieben werden.

In den folgenden Unterabschnitten werden die Tools, die für einmalige Migrationen verwendet werden können, sowie deren Einschränkungen und Best Practices, beschrieben.

Database Migration Service für die Migration bei geplanter Wartung

Database Migration Service verwaltet sowohl die anfängliche Synchronisierung als auch die fortlaufende CDC-Replikation (Change Data Capture) und gibt den Status des Migrationsvorgangs an.

Mit dem Database Migration Service können Sie Migrationsjobs erstellen, die Sie verwalten und überprüfen können. Wir empfehlen die Verwendung des Database Migration Service, da er Migrationen zu Cloud SQL for MySQL über einmalige Migrationsjobs unterstützt. Bei großen Datenbanken können Sie den Parallelismus von Datendumps im Database Migration Service verwenden.

Weitere Informationen zur Architektur der Datenbankmigration und zum Database Migration Service finden Sie unter Datenbank mit dem Database Migration Service zu Cloud SQL for MySQL migrieren und Migrationsintegrität für MySQL.

Weitere Informationen zu den Einschränkungen und Voraussetzungen des Database Migration Service finden Sie hier:

• Bekannte Einschränkungen des Database Migration Service
• Kontingente und Limits im Database Migration Service
• Quelle im Dienst zur Datenmigration konfigurieren

Integrierte Sicherungen des Datenbankmoduls

Wenn eine erhebliche Ausfallzeit akzeptabel ist und Ihre Quelldatenbanken relativ statisch sind, können Sie die integrierten Dump- und Ladefunktionen (manchmal auch Sicherung und Wiederherstellung genannt) der Datenbank-Engine verwenden.

Die Einrichtung und Synchronisierung ist etwas aufwendig, insbesondere bei einer großen Anzahl von Datenbanken. Datenbank-Engine-Sicherungen sind jedoch in der Regel leicht verfügbar und einfach zu verwenden.

Für Sicherungen des Datenbankmoduls gelten die folgenden allgemeinen Einschränkungen:

• Sicherungen können fehleranfällig sein, insbesondere wenn sie manuell ausgeführt werden.
• Daten sind nicht gesichert, wenn die Sicherungen nicht ordnungsgemäß verwaltet werden.
• Für Back-ups gibt es keine geeigneten Überwachungsmöglichkeiten.
• Wenn viele Datenbanken mit diesem Tool migriert werden, ist ein gewisser Aufwand für die Skalierung erforderlich.

Wenn Sie sich für diesen Ansatz entscheiden, beachten Sie die folgenden Einschränkungen und Best Practices:

• Wenn Ihre Datenbank relativ klein ist (unter 10 GB), empfehlen wir die Verwendung von mysqldump. Es gibt kein festes Limit, aber die ideale Datenbankgröße für mysqldump liegt in der Regel unter 10 GB.

• Wenn Sie Datenbanken importieren, die größer als 10 GB sind, benötigen Sie möglicherweise andere Strategien, um die Ausfallzeit der Datenbank zu minimieren. Beispiele für diese Strategien:

  • Exportieren Sie das Schema und die Daten in Unterabschnitten ohne Sekundärschlüssel.
  • Zeitstempel nutzen Wenn eine Ihrer Tabellen Zeitstempelspalten verwendet, können Sie eine Funktion des Befehls mysqldump verwenden, mit dem Sie eine WHERE-Klausel angeben können, um nach einer Zeitstempelspalte zu filtern.
  • Sie können auch andere Ansätze wie die Tools mydumper und myloader verwenden.

Datenbankdumps und ‑sicherungen enthalten in der Regel keine MySQL-Nutzerkonten. Prüfen Sie bei der Vorbereitung der Migration alle Nutzerkonten auf der Quellinstanz. Sie können beispielsweise den Befehl SHOW GRANTS für jeden Nutzer ausführen, um die aktuellen Berechtigungen zu prüfen und zu sehen, ob Berechtigungen in Cloud SQL eingeschränkt sind. Ebenso können Sie mit dem pt-show-grants-Tool von Percona die Zuteilungen auflisten.

Einschränkungen für Nutzerberechtigungen in Cloud SQL können Migrationen betreffen, wenn Datenbankobjekte mit dem Attribut DEFINER migriert werden. Beispielsweise kann eine gespeicherte Prozedur über eine Super-Privileg-Definition für SQL-Befehle wie das Ändern einer globalen Variablen verfügen, die in Cloud SQL nicht zulässig ist. In solchen Fällen kann es erforderlich sein, den Code der gespeicherten Prozedur neu zu schreiben oder nicht tabellenbasierte Objekte wie gespeicherte Prozeduren als separaten Migrationsschritt zu migrieren. Weitere Informationen finden Sie unter Best Practices zum Importieren und Exportieren von Daten.

Weitere Informationen zu Einschränkungen und Best Practices finden Sie hier:

• Informationen zu Nutzern in Cloud SQL for MySQL
• Best Practices zum Importieren und Exportieren von Daten mit Cloud SQL for MySQL
• Bekannte Probleme mit Cloud SQL for MySQL

Andere Ansätze für die Migration bei geplanter Wartung

Wenn Sie einen verwalteten Import verwenden, um die Replikation aus einer externen MySQL-Datenbank einzurichten, werden die Daten zuerst aus der externen Datenbank in die Cloud SQL-Instanz geladen. Bei diesem Ansatz wird ein Dienst verwendet, der Daten vom externen Server – in diesem Fall der RDS-Instanz – extrahiert und direkt in die Cloud SQL-Instanz importiert.

Bei großen Datenbanken (mehrere TB) ist es schneller, einen benutzerdefinierten Import für die Erstbelastung zu verwenden, bei dem die Tools mydumper und myloader verwendet werden.

Sie können die Tabellen aus Ihrer MySQL-Datenbank in CSV-Dateien exportieren, die dann in Cloud SQL for MySQL importiert werden können. Wenn Sie Daten aus Ihrer RDS-Instanz exportieren möchten, können Sie den AWS Database Migration Service (AWS DMS) und einen S3-Bucket als Ziel verwenden.

Ausführliche Informationen und Schritte finden Sie unter Replikation aus externen Datenbanken mithilfe eines verwalteten Imports einrichten.

Tools für Migrationen mit kontinuierlichen Replikationen

Das folgende Diagramm zeigt ein Flussdiagramm mit Fragen, die Ihnen bei der Auswahl des Migrationstools für eine einzelne Datenbank helfen können, wenn Sie eine Migrationsstrategie mit kontinuierlicher Replikation verwenden:

Das obige Flussdiagramm zeigt die folgenden Entscheidungspunkte:

• Verwenden Sie lieber verwaltete Migrationsdienste?

  • Falls ja, können Sie sich eine Schreibausfallzeit von einigen Sekunden leisten, je nach Anzahl der Tabellen in Ihrer Datenbank?

    • Falls ja, verwenden Sie den Database Migration Service.
    • Falls nein, prüfen Sie andere Migrationsoptionen.

  • Andernfalls müssen Sie prüfen, ob die integrierte Replikation des Datenbankmoduls unterstützt wird:

    • Falls ja, empfehlen wir die Verwendung der integrierten Replikation.
    • Falls nicht, empfehlen wir Ihnen, andere Migrationsoptionen zu prüfen.

In den folgenden Abschnitten werden die Tools beschrieben, die für kontinuierliche Migrationen verwendet werden können, zusammen mit ihren Einschränkungen und Best Practices.

Database Migration Service für die Migration mit kontinuierlicher Replikation

Der Database Migration Service bietet durch die Verwendung von Jobs für kontinuierliche Migrationen eine nahtlose Unterstützung für kontinuierliche Migrationen. Nur Jobs für die kontinuierliche Migration können befördert werden, was das Ende der Replikation signalisiert.

Wenn Sie sich für dieses Tool entscheiden, beachten Sie die folgenden Einschränkungen und Best Practices:

• Vermeiden Sie während der Migration lang laufende Transaktionen. In solchen Fällen empfehlen wir die Migration von einem Lesereplikat, sofern Sie nicht von AWS Aurora migrieren.
• Eine vollständige Liste der Einschränkungen finden Sie unter Bekannte Einschränkungen.

Integrierte Replikation des Datenbankmoduls

Die integrierte Replikation des Datenbankmoduls ist eine alternative Option zum Database Migration Service für eine kontinuierliche Migration.

Bei der Datenbankreplikation werden Daten aus einer Datenbank, der primären Datenbank, in andere Datenbanksysteme kopiert und verteilt, die als Replikate bezeichnet werden. Sie soll die Datenzugänglichkeit sowie die Fehlertoleranz und Zuverlässigkeit eines Datenbanksystems verbessern. Die Datenbankmigration ist zwar nicht der primäre Zweck der Datenbankreplikation, kann aber als Tool zur Erreichung dieses Ziels verwendet werden. Die Datenbankreplikation ist in der Regel ein fortlaufender Prozess, der in Echtzeit ausgeführt wird, wenn Daten in die primäre Datenbank eingefügt, aktualisiert oder gelöscht werden. Dies kann als einmaliger Vorgang oder als Abfolge von Batch-Vorgängen erfolgen.

Die meisten modernen Datenbank-Engines implementieren verschiedene Möglichkeiten zur Datenbankreplikation. Eine Art der Replikation kann durch Kopieren und Senden des Write-Ahead-Logs oder Transaktionslogs des primären Replicas an die Replikate erreicht werden. Dieser Ansatz wird als physische oder binäre Replikation bezeichnet. Bei anderen Replikationstypen werden die Roh-SQL-Anweisungen, die eine primäre Datenbank empfängt, verteilt, anstatt Änderungen auf Dateisystemebene zu replizieren.

Cloud SQL unterstützt die Replikation für MySQL. Es gibt jedoch einige Voraussetzungen und Einschränkungen.

Voraussetzungen:

• Sie müssen MySQL 5.5, 5.6, 5.7 oder 8.0 auf Ihrer Amazon RDS- oder Amazon Aurora-Instanz verwenden.
• Achten Sie darauf, dass binäre Logs aktiviert sind.
• Wählen Sie eine ausreichend große Maschinenebene aus, um die anfängliche Phase des vollständigen Dumps zu beschleunigen. Berücksichtigen Sie dabei die CPU- und Arbeitsspeichergröße.
• Wenn Sie die CDC-Phase beschleunigen möchten, können Sie versuchen, die parallele Replikation zu konfigurieren und die Hochleistungs-Auslagerung zu aktivieren.
• Wenn das Cloud SQL-Replikat mit internen IP-Adressen aktiviert ist, weil die ausgehende IP-Adresse nicht statisch ist, konfigurieren Sie die Firewall des Amazon RDS- oder Amazon Aurora-Servers so, dass der interne IP-Adressbereich zugelassen wird, der dem Zugriff auf private Dienste des VPC-Netzwerk zugewiesen ist, das das Cloud SQL-Replikat als sein privates Netzwerk verwendet. Weitere Informationen finden Sie unter Informationen zum Replizieren von einem externen Server und Zugriff auf private Dienste konfigurieren.

Einschränkungen:

• Wenn Sie einzelne große Tabellen und viele sekundäre Indexe in Ihrer Datenbank haben, kann der erste vollständige Dump länger dauern.
• Wenn der externe Server DEFINER-Klauseln (Ansichten, Ereignisse, Trigger oder gespeicherte Prozeduren) enthält, kann die Replikation fehlschlagen, abhängig von der Reihenfolge, in der diese Anweisungen ausgeführt werden. Weitere Informationen zur Verwendung von DEFINER in Cloud SQL und zu möglichen Problemumgehungen finden Sie in diesem Artikel.
• InnoDB ist die einzige unterstützte Datenbank-Engine in Cloud SQL. Eine MyISAM-Migration kann zu Dateninkonsistenzen führen und erfordert eine Datenvalidierung. Weitere Informationen finden Sie unter Tabellen von MyISAM zu InnoDB konvertieren.

Andere Ansätze für die Migration einer kontinuierlichen Replikation

Weitere Ansätze für die Migration einer kontinuierlichen Replikation:

• Anwendungen refaktorieren, um J (Schreiben und Lesen) auszuführen oder einen Mikrodienst für den Datenzugriff verwenden.

  • Die kontinuierliche Replikation wird von Ihren Anwendungen ausgeführt.
  • Die Migration konzentriert sich auf die Refaktorierung oder Entwicklung von Tools, die Verbindungen zu Ihren Datenbankinstanzen herstellen.
  • Leseranwendungen werden nach und nach refaktoriert und bereitgestellt, um die Zielinstanz zu verwenden.

• Mit Datastream können Sie Änderungen an Ihrer MySQL-Instanz nahezu in Echtzeit replizieren.

  • Datastream ist ein serverloser CDC- und Replikationsdienst, der mit Amazon RDS oder Amazon Aurora verwendet werden kann, um Daten zu replizieren und zu synchronisieren.
  • Replizieren Sie Änderungen mit Datastream von Ihrer MySQL-Instanz entweder in BigQuery oder Cloud Storage und laden Sie die Daten dann mit Dataflow oder Dataproc in Ihre Cloud SQL-Instanz hoch.

Weitere Informationen zur Replikation mit Datastream finden Sie unter den folgenden Links:

• Amazon RDS for MySQL-Datenbank in Datastream konfigurieren
• Amazon Aurora MySQL-Datenbank in Datastream konfigurieren
• Änderungen an Daten mit Datastream in Echtzeit streamen

Drittanbietertools für Migrationen mit kontinuierlicher Replikation

In einigen Fällen ist es besser, ein Drittanbieter-Tool für die meisten Datenbankmodule zu verwenden. Das kann beispielsweise der Fall sein, wenn Sie einen verwalteten Migrationsdienst verwenden möchten und dafür sorgen müssen, dass die Zieldatenbank immer nahezu in Echtzeit mit der Quelle synchronisiert ist, oder wenn Sie während der Migration komplexere Transformationen wie Datenbereinigung, -restrukturierung und -anpassung benötigen.

Wenn Sie ein Drittanbieter-Tool verwenden möchten, können Sie eine der folgenden Empfehlungen wählen, die Sie für die meisten Datenbankmodule verwenden können.

Striim ist eine End-to-End-In-Memory-Plattform zum Erfassen, Filtern, Transformieren, Anreichern, Aggregieren, Analysieren und Bereitstellen von Daten in Echtzeit:

• Vorteile:

  • Ermöglicht die Verarbeitung großer Datenmengen und komplexer Migrationen.
  • Integrierte Change Data Capture für SQL Server.
  • Vorkonfigurierte Verbindungsvorlagen und No-Code-Pipelines
  • Er kann geschäftskritische, große Datenbanken mit hoher Transaktionslast verarbeiten.
  • Genau einmalige Zustellung.

• Nachteile:

  • Nicht Open Source.
  • Kann teuer werden, insbesondere bei langen Migrationen.
  • Einige Einschränkungen bei der Weitergabe von DDL-Vorgängen (Data Definition Language). Weitere Informationen finden Sie unter Unterstützte DDL-Vorgänge und Hinweise und Einschränkungen zur Schemaentwicklung.

Weitere Informationen zu Striim finden Sie unter Striim in Google Cloud ausführen.

Debezium ist eine verteilte Open-Source-Plattform für CDC, die Datenänderungen an externe Abonnenten streamt:

• Vorteile:

  • Open Source
  • Starke Community-Unterstützung.
  • Kostengünstig
  • Detaillierte Kontrolle über Zeilen, Tabellen oder Datenbanken
  • Speziell für die Erfassung von Änderungen in Echtzeit aus Datenbanktransaktionsprotokollen.

• Nachteile:

  • Erforderliche Kenntnisse mit Kafka und ZooKeeper.
  • Datenänderungen werden mindestens einmal übermittelt, was bedeutet, dass Sie Duplikate verarbeiten müssen.
  • Manuelle Einrichtung des Monitorings mit Grafana und Prometheus
  • Keine Unterstützung für die inkrementelle Batch-Replikation.

Weitere Informationen zu Debezium-Migrationen finden Sie unter Nahezu-in-Echtzeit-Datenreplikation mit Debezium.

Fivetran ist eine Plattform für die automatisierte Datenübertragung, mit der Daten aus und zwischen Cloud-Datenplattformen verschoben werden können.

• Vorteile:

  • Vorkonfigurierte Verbindungsvorlagen und No-Code-Pipelines
  • Alle Schemaänderungen werden von der Quelle an die Zieldatenbank weitergegeben.
  • Datenänderungen werden genau einmal übermittelt, was bedeutet, dass Sie Duplikate nicht verarbeiten müssen.

• Nachteile:

  • Nicht Open Source.
  • Die Unterstützung für komplexe Datentransformationen ist begrenzt.

Migrationsplan und Zeitplan definieren

Für eine erfolgreiche Datenbankmigration und Produktionsumstellung empfehlen wir die Vorbereitung eines klar definierten, umfassenden Migrationsplans. Um die Auswirkungen auf Ihr Unternehmen zu minimieren, empfehlen wir Ihnen, eine Liste aller erforderlichen Arbeitselemente zu erstellen.

Durch das Definieren des Migrationsbereichs werden die Arbeitsaufgaben angezeigt, die Sie vorab, während und nach der Datenbankmigration erledigen müssen. Wenn Sie beispielsweise bestimmte Tabellen aus einer Datenbank nicht migrieren möchten, sind möglicherweise Aufgaben vor oder nach der Migration erforderlich, um diese Filterung zu implementieren. Außerdem achten Sie darauf, dass die Datenbankmigration nicht Ihre bestehende Service Level Agreement (SLA) und Ihren Notfallwiederherstellungsplan beeinträchtigt.

Ihre Dokumentation zur Migrationsplanung sollte folgende Dokumente enthalten:

• Technisches Designdokument (TDD)
• RACI-Matrix
• Zeitplan (z. B. ein T-Minus-Plan)

Datenbankmigrationen sind ein iterativer Prozess und die ersten Migrationen sind oft langsamer als die späteren. Normalerweise verlaufen gut geplante Migrationen ohne Probleme, doch ungeplante Probleme können trotzdem auftreten. Wir empfehlen Ihnen, immer einen Rollback-Plan zu haben. Befolgen Sie als Best Practice die Anweisungen aus: Migration zu Google Cloud: Best Practices zum Validieren eines Migrationsplans

TDD

In der TDD werden alle technischen Entscheidungen dokumentiert, die für das Projekt getroffen werden müssen. Schließen Sie Folgendes im TDD ein:

• Geschäftsanforderungen und -kritalität
• Recovery Time Objective (RTO)
• Recovery Point Objective (RPO)
• Details zur Datenbankmigration
• Schätzungen des Migrationsaufwands
• Empfehlungen für die Migrationsvalidierung

RACI-Matrix

Für einige Migrationsprojekte ist eine RACI-Matrix erforderlich. Dies ist ein gängiges Projektmanagementdokument, in dem festgelegt wird, welche Personen oder Gruppen für Aufgaben und Arbeitsergebnisse im Migrationsprojekt verantwortlich sind.

Zeitplan

Erstellen Sie einen Zeitplan für jede Datenbank, die migriert werden muss. Schließen Sie alle auszuführenden Aufgaben und ein und legen Sie Start- und Endtermine fest.

Wir empfehlen, für jede Migrationsumgebung einen Zeitplan zu erstellen. Ein T-minus-Plan ist als Countdown-Zeitplan strukturiert und enthält alle Aufgaben, die für die Durchführung des Migrationsprojekts erforderlich sind, zusammen mit den zuständigen Gruppen und der geschätzten Dauer.

Der Zeitplan sollte nicht nur die Ausführung der Vorbereitungsaufgaben vor der Migration, sondern auch die Validierung, Prüfung oder Tests berücksichtigen, die nach der Datenübertragung stattfinden.

Die Dauer der Migrationsaufgaben hängt in der Regel von der Datenbankgröße ab, aber auch andere Aspekte sind zu berücksichtigen, wie die Komplexität der Geschäftslogik, Anwendungsnutzung und Teamverfügbarkeit.

Ein T-Minus-Plan könnte so aussehen:

Datum	Phase	Kategorie	Aufgaben	Rolle	T-Minus	Status
1.11.2023	Vor der Migration	Aufgabe	Bewertungsbericht erstellen	Discovery-Team	-21	Fertig
7.11.2023	Vor der Migration	Zielvorbereitung	Entwurf der Zielumgebung, wie im Designdokument beschrieben	Migrationsteam	-14	Fertig
15.11.2023	Vor der Migration	Unternehmensführung	Migrationsdatum und T-Minus-Genehmigung	Leitende Positionen	-6	Fertig
18.11.2023	Migration	DMS einrichten	Verbindungsprofile erstellen	Cloud-Migrationstechniker	-3	Fertig
19.11.2023	Migration	DMS einrichten	Migrationsjobs erstellen und starten	Cloud-Migrationstechniker	-2	Nicht gestartet
19.11.2023	Migration	DMS überwachen	DMS-Jobs und DDL-Änderungen in der Quellinstanz überwachen	Cloud-Migrationstechniker	-2	Nicht gestartet
21.11.2023	Migration	DMS-Umstellung	DMS-Replikat hochstufen	Cloud-Migrationstechniker	0	Nicht gestartet
21.11.2023	Migration	Migrationsüberprüfung	Validierung der Datenbankmigration	Migrationsteam	0	Nicht gestartet
21.11.2023	Migration	Anwendungstest	Funktions- und Leistungstests ausführen	Migrationsteam	0	Nicht gestartet
22.11.2023	Migration	Unternehmensführung	Migrationsvalidierung: GO oder NO GO	Migrationsteam	1	Nicht gestartet
23.11.2023	Nach der Migration	Monitoring prüfen	Monitoring konfigurieren	Infrastrukturteam	2	Nicht gestartet
25.11.2023	Nach der Migration	Sicherheit	DMS-Nutzerkonto entfernen	Sicherheitsteam	4	Nicht gestartet

Mehrere Datenbankmigrationen

Wenn Sie mehrere Datenbanken migrieren möchten, sollte Ihr Migrationsplan Aufgaben für alle Migrationen enthalten.

Wir empfehlen, mit der Migration einer kleineren, idealerweise nicht kritischen Datenbank zu beginnen. Dieser Ansatz kann Ihnen helfen, Ihr Wissen und Ihr Vertrauen in den Migrationsprozess und die Tools zu erweitern. Außerdem können Sie in den frühen Phasen des Migrationszeitplans eventuelle Mängel im Prozess erkennen.

Wenn Sie mehrere Datenbanken migrieren möchten, können die Zeitpläne parallelisiert werden. Um den Migrationsprozess zu beschleunigen, können Sie beispielsweise eine Gruppe kleiner, statischer oder weniger geschäftskritischer Datenbanken gleichzeitig migrieren, wie im folgenden Diagramm dargestellt.

Im im Diagramm dargestellten Beispiel sind die Datenbanken 1-4 eine Gruppe kleiner Datenbanken, die gleichzeitig migriert werden.

Vorbereitungsaufgaben definieren

Die Vorbereitungsaufgaben sind alle Aktivitäten, die Sie durchführen müssen, um die Voraussetzungen für die Migration zu erfüllen. Ohne die Vorbereitungsaufgaben kann die Migration nicht stattfinden oder die migrierte Datenbank ist nicht verwendbar.

Vorbereitungsaufgaben können in folgende Kategorien unterteilt werden:

• Amazon RDS- oder Amazon Aurora-Instanzen – Vorbereitungen und Voraussetzungen
• Vorbereitung der Quelldatenbank und Voraussetzungen
• Cloud SQL-Einrichtung
• Migrationsspezifische Einrichtung

Amazon RDS- oder Amazon Aurora-Instanz – Vorbereitung und Voraussetzungen

Beachten Sie die folgenden häufigen Einrichtungs- und Voraussetzungen:

• Je nach Migrationspfad müssen Sie möglicherweise Remote-Verbindungen auf Ihren RDS-Instanzen zulassen. Wenn Ihre RDS-Instanz in Ihrer VPC als privat konfiguriert ist, muss eine private RFC 1918-Verbindung zwischen Amazon und Google Cloud bestehen.

• Möglicherweise müssen Sie eine neue Sicherheitsgruppe konfigurieren, um Remote-Verbindungen zu erforderlichen Ports zu zulassen.

  • In AWS ist der Netzwerkzugriff für Datenbankinstanzen standardmäßig deaktiviert.
  • Sie können Regeln in einer Sicherheitsgruppe festlegen, die den Zugriff von z.  . einem IP-Adressbereich, ein Port oder eine Sicherheitsgruppe zu zulassen. Dieselben Regeln gelten für alle Datenbankinstanzen, die dieser Sicherheitsgruppe zugeordnet sind.

• Achten Sie darauf, dass genügend freier Speicherplatz vorhanden ist, um WAL-Protokolle während des vollständigen Ladevorgangs in Ihrer Amazon RDS-Instanz zu puffern.

• Für optimale Migrationsergebnisse sollten Sie von einem Lesereplikat migrieren, es sei denn, Sie migrieren von Amazon Aurora. Außerdem empfehlen wir, die Migration während eines Zeitraums mit geringerer Datenbankaktivität zu starten.

• MySQL begrenzt den Hostnamen auf 60 Zeichen. Amazon RDS-Datenbank-Hostnamen sind in der Regel länger als 60 Zeichen. Wenn dies für die migrierte Datenbank der Fall ist, konfigurieren Sie eine DNS-Weiterleitung, um einen CNAME-Eintrag zu erstellen, der Ihren Domainnamen mit dem Domainnamen Ihrer RDS-Datenbankinstanz verknüpft.

• Wenn Sie die integrierte Replikation verwenden, müssen Sie Ihre Amazon RDS- oder Amazon Aurora-Instanz für die Replikation einrichten. Für die integrierte Replikation oder Tools, die sie verwenden, muss das binäre Logging für MySQL auf ROW festgelegt sein.

• Wenn Sie Tools von Drittanbietern verwenden, sind in der Regel Vorabeinstellungen und -konfigurationen erforderlich, bevor Sie das Tool verwenden können. Lesen Sie die Dokumentation des Drittanbietertools.

Weitere Informationen zur Instanzvorbereitung und zu den Voraussetzungen finden Sie unter Externen Server für die Replikation für MySQL einrichten.

Vorbereitung der Quelldatenbank und Voraussetzungen

• Wenn Sie Database Migration Service verwenden möchten, müssen Sie Ihre Quelldatenbank konfigurieren, bevor Sie eine Verbindung herstellen. Prüfen Sie die Migrationsjobs, bevor Sie sie implementieren. Weitere Informationen finden Sie unter Quelle für MySQL konfigurieren.
• Je nach Datenbankmodul müssen Sie möglicherweise bestimmte Funktionen ändern. Cloud SQL for MySQL unterstützt beispielsweise nur das InnoDB-Datenbankmodul. Sie müssen MyISAM-Tabellen in InnoDB-Tabellen ändern.
• Bei einigen Migrationstools von Drittanbietern müssen alle LOB-Spalten optional sein. Bei allen LOB-Spalten, die NOT NULL sind, muss diese Einschränkung während der Migration entfernt werden.

• Erstellen Sie Baseline-Messungen in Ihrer Produktionsumgebung. Beachten Sie dabei Folgendes:

  • Messen Sie die Größe Ihrer Daten sowie die Leistung Ihrer Arbeitslast. Wie lange dauern wichtige Abfragen oder Transaktionen im Durchschnitt? Wie lange dauert es in Spitzenzeiten?
  • Dokumentieren Sie die Basismessungen für einen späteren Vergleich, damit Sie entscheiden können, ob die Genauigkeit Ihrer Datenbankmigration zufriedenstellend ist. Entscheiden Sie, ob Sie Ihre Produktionsarbeitslasten umstellen und Ihre Quellumgebung außer Betrieb setzen können oder ob Sie sie noch als Fallback benötigen.

Cloud SQL-Einrichtung

Wählen Sie die Größe und die Spezifikationen Ihrer Ziel-Cloud SQL for MySQL-Datenbankinstanz sorgfältig aus, damit sie der Quelle für ähnliche Leistungsanforderungen entspricht. Achten Sie dabei besonders auf Laufwerkgröße und Durchsatz, IOPS und Anzahl der vCPUs. Falsche Größen können zu langen Migrationszeiten, Problemen mit der Datenbankleistung, Datenbankfehlern und Probleme mit der Anwendungsleistung führen.

Sie müssen die folgenden Eigenschaften und Anforderungen bestätigen, bevor Sie Ihre Cloud SQL-Instanzen erstellen, da sie später nicht geändert werden könne, ohne sie neu zu erstellen.

• Wählen Sie das Projekt und die Region Ihrer Ziel-Cloud SQL-Instanzen sorgfältig aus. Cloud SQL-Instanzen können nicht ohne Datenübertragung zwischen Google Cloud-Projekten und -Regionen migriert werden.
• Migrieren Sie zu einer übereinstimmenden Hauptversion in Cloud SQL. Wenn in Ihrer Quelle beispielsweise MySQL 8.0.34 auf Amazon RDS oder Amazon Aurora verwendet wird, sollten Sie zu Cloud SQL for MySQL 8.0.34 migrieren.
• Replizieren Sie die Benutzerinformationen separat, wenn Sie integrierte Datenbank-Engine-Backups oder Database Migration Service verwenden. In Cloud SQL werden Nutzer mit Google IAM verwaltet. Einzelheiten hierzu finden Sie im Abschnitt Integrierte Datenbankmodulsicherungen.
• Prüfen Sie die Konfigurationsflags der Datenbank-Engine und vergleichen Sie die Werte der Quell- und Zielinstanz. Stellen Sie sicher, dass Sie deren Auswirkungen verstehen und ob sie gleich sein müssen oder nicht. Wir empfehlen beispielsweise, den Befehl SHOW VARIABLES vor der Migration in der Quelldatenbank und dann noch einmal in der Cloud SQL-Datenbank auszuführen. Aktualisieren Sie die Flag-Einstellungen nach Bedarf in der Cloud SQL-Datenbank, um die Quelleinstellungen zu replizieren. Beachten Sie, dass nicht alle MySQL-Flags auf einer Cloud SQL-Instanz zulässig sind.

Weitere Informationen zur Cloud SQL-Einrichtung finden Sie unter den folgenden Links:

• Allgemeine Best Practices für MySQL
• Instanzkonfigurationsoptionen für MySQL
• Wichtige Überlegungen vor der Migration von Aurora zu Cloud SQL for MySQL

Migrationsspezifische Einrichtung

Wenn Sie SQL-Dumpdateien in Cloud SQL importieren, müssen Sie möglicherweise einen Cloud Storage-Bucket erstellen. Im Bucket wird der Datenbankdump gespeichert.

Wenn Sie die Replikation verwenden, muss das Cloud SQL-Replikat Zugriff auf Ihre primäre Datenbank haben. Dieser Zugriff kann über die dokumentierten Verbindungsoptionen erreicht werden.

Je nach Szenario und Kritik müssen Sie möglicherweise ein Fallback-Szenario implementieren, das in der Regel die Umkehrung der Replikationsrichtung beinhaltet. In diesem Fall benötigen Sie möglicherweise einen zusätzlichen Replikationsmechanismus von Cloud SQL zurück zur Amazon-Quellinstanz.

Für die meisten Drittanbietertools müssen Sie migrationsspezifische Ressourcen bereitstellen. Für Striim müssen Sie beispielsweise den Google Cloud Marketplace verwenden. Um dann Ihre Migrationsumgebung in Striim einzurichten, können Sie mit dem Flow Designer Anwendungen erstellen und ändern oder eine vorhandene Vorlage auswählen. Anwendungen können auch mit der Programmiersprache Tungsten Query Language (TQL) codiert werden. Mit einem Datenvalidierungs-Dashboard erhalten Sie eine visuelle Darstellung der von Ihrer Striim-Anwendung verarbeiteten Daten

Sie können die Ressourcen, die Ihre Amazon- und Google Cloud-Umgebung verbinden, außer Betrieb nehmen, nachdem die Migration abgeschlossen und validiert wurde.

Hier finden Sie weitere Informationen:

• Migrationsjobs im Datenbank-Migrationsdienst verwalten
• Best Practices zum Importieren und Exportieren von Daten
• Verbindung für MySQL

Ausführungsaufgaben definieren

Ausführungsaufgaben implementieren die Migration selbst. Die Aufgaben hängen vom ausgewählten Migrationstool ab, wie in den folgenden Abschnitten beschrieben.

Integrierte Sicherungen des Datenbankmoduls

Wenn Sie eine einmalige Migration ausführen möchten, erstellen Sie mit dem Dienstprogramm „mysqldump“ eine Sicherung, mit der die Daten aus Amazon RDS auf Ihren lokalen Clientcomputer kopiert werden. Eine Anleitung finden Sie unter SQL-Dumpdatei in Cloud SQL for MySQL importieren.

Sie können den Status von Import- und Exportvorgängen für Ihre Cloud SQL-Instanz prüfen.

Database Migration Service-Migrationsjobs

Migrationsjobs im Database Migration Service definieren und konfigurieren, um Daten aus einer Quellinstanz in die Zieldatenbank zu migrieren. Migrationsjobs stellen über benutzerdefinierte Verbindungsprofile eine Verbindung zur Quelldatenbankinstanz her.

Testen Sie alle Voraussetzungen, um sicherzustellen, dass der Job erfolgreich ausgeführt werden kann. Wählen Sie einen Zeitpunkt aus, zu dem Ihre Arbeitslasten eine kurze Ausfallzeit für die Migration und die Produktionsübernahme verkraften können.

Im Database Migration Service beginnt die Migration mit der anfänglichen vollständigen Sicherung und dem Laden, gefolgt von einem kontinuierlichen Fluss von Änderungen von der Quell- zur Zieldatenbankinstanz.

Der Database Migration Service benötigt einige Sekunden, um die Lesesperre für alle Tabellen in Ihrer Quell-Amazon-RDS- oder Amazon-Aurora-Instanz zu erhalten, die für die konsistente Ausführung des ersten vollständigen Dumps erforderlich sind. Um die Lesesperre zu erreichen, kann eine Schreibausfallzeit von 1 bis 49 Sekunden erforderlich sein. Die Ausfallzeiten hängen von der Anzahl der Tabellen in Ihrer Datenbank ab. 1 Sekunde entspricht 100 Tabellen und 9 Sekunden 10.000 Tabellen.

Der Migrationsprozess mit Database Migration Service endet mit dem Vorgang zum Hochstufen. Wenn Sie eine Datenbankinstanz hochstufen, wird die Zieldatenbank vom Änderungsfluss der Quelldatenbank getrennt. Die nun eigenständige Zielinstanz wird dann zu einer primären Instanz hochgestuft. Dieser Ansatz wird manchmal auch als Produktionsschalter bezeichnet.

Weitere Informationen zu Migrationsjobs im Database Migration Service finden Sie unter:

• Migrationsjob prüfen
• Migrationsjobs verwalten
• Migrationen hochstufen

Eine detaillierte Anleitung zur Migrationseinrichtung finden Sie unter Datenbank mit Database Migration Service zu Cloud SQL for MySQL migrieren. Im Database Migration Service wird die Migration durch Starten und Ausführen eines Migrationsjobs durchgeführt.

Integrierte Replikation des Datenbankmoduls

Sie können die integrierte Replikation von Amazon RDS zu einer externen Cloud SQL for MySQL-Instanz verwenden.

Bei MySQL müssen Sie zuerst einen ersten Dump erstellen, der in einem Cloud Storage-Bucket gespeichert werden kann, und dann die Daten in Cloud SQL for MySQL importieren. Starten Sie dann den Replikationsprozess.

Überwachen Sie die Replikation und beenden Sie die Schreibvorgänge in der Quellinstanz zum passenden Zeitpunkt. Prüfen Sie noch einmal den Replikationsstatus, um sicherzustellen, dass alle Änderungen repliziert wurden. Anschließend können Sie das Cloud SQL for MySQL-Replikat zu einer eigenständigen Instanz hochstufen, um die Migration abzuschließen.

Eine ausführliche Anleitung zum Einrichten der integrierten Replikation von einem externen Server wie Amazon RDS oder Amazon Aurora for MySQL finden Sie unter Informationen zur Replikation von einem externen Server und Cloud SQL und externen Server für die Replikation konfigurieren.

Weitere Informationen und Anleitungen finden Sie unter:

• Datenbank in einen Cloud Storage-Bucket exportieren
• Replikation aus externen Datenbanken mithilfe eines verwalteten Imports einrichten
• Replikation auf dem externen Server starten

Drittanbieter-Tools

Definieren Sie alle Ausführungsaufgaben für das ausgewählte Drittanbietertool.

In diesem Abschnitt wird Striim als Beispiel verwendet. Striim verwendet Anwendungen, die Daten aus verschiedenen Quellen abrufen, verarbeiten und dann an andere Anwendungen oder Ziele weitergeben.

Anwendungen können mit dem Webclient grafisch erstellt werden. Sie enthalten Quellen, Ziele und andere logische Komponenten, die in einem oder mehreren Abläufen organisiert sind.

Um Ihre Migrationsumgebung in Striim einzurichten, können Sie die Funktion Flow Designer verwenden, um Anwendungen zu erstellen und zu ändern. Sie können auch eine der vordefinierten Vorlagen auswählen. Anwendungen können auch mit der Programmiersprache TQL codiert werden.

Mit einem Datenvalidierungs-Dashboard erhalten Sie eine visuelle Darstellung der von Ihrer Striim-Anwendung verarbeiteten Daten.

Eine Kurzanleitung für den Einstieg mit Striim in Google Cloud finden Sie unter Striim in der Google Cloud ausführen. Weitere Informationen zu den grundlegenden Konzepten von Striim finden Sie unter Striim-Konzepte. Lesen Sie auch den Leitfaden mit Best Practices zum Übergang von einem ersten Ladevorgang zur kontinuierlichen Replikation.

Beachten Sie bei der Datenmigration die folgenden Best Practices:

• Informieren Sie die beteiligten Teams, wann die einzelnen Schritte des Plans beginnen und enden.
• Wenn einer der Schritte länger als erwartet dauert, vergleichen Sie die verstrichene Zeit mit der maximalen Zeit, die für jeden Schritt vorgesehen ist. Informieren Sie die beteiligten Teams in diesem Fall regelmäßig über den Stand der Dinge.
• Wenn der Zeitraum länger ist als die maximale Zeit, die für jeden Schritt im Plan reserviert ist, sollten Sie einen Rollback ausführen.
• Treffen Sie für jeden Schritt des Migrations- und Umstellungsplans die Entscheidung „Go oder No-Go“.
• Berücksichtigen Sie für jeden Schritt Rollback-Aktionen oder alternative Szenarien.

Fallback-Szenarien definieren

Definieren Sie Fallback-Aktionselemente für jede Migrationsausführungsaufgabe zum Schutz vor unvorhergesehenen Problemen während des Migrationsprozesses. Die Fallback-Aufgaben hängen in der Regel von der verwendeten Migrationsstrategie und den verwendeten Tools ab.

Ein Fallback kann erheblichen Aufwand erfordern. Führen Sie die Umstellung der Produktion am besten erst durch, wenn die Testergebnisse zufriedenstellend sind. Die Datenbankmigration und das Fallback-Szenario sollten ordnungsgemäß getestet werden, um schwerwiegende Ausfälle zu vermeiden.

Definieren Sie Erfolgskriterien und legen Sie Zeitlimits für alle Migrationsaufgaben fest. Mit einem Migrations-Testlauf können Sie Informationen zu den erwarteten Zeiten für die einzelnen Aufgaben erfassen. Bei einer geplanten Wartungsmigration können Sie sich zum Beispiel die Ausfallzeit leisten, die durch das Umstellungsfenster dargestellt wird. Es ist jedoch wichtig, Ihre nächsten Schritte zu planen, falls der einmalige Migrationsjob oder die Wiederherstellung der Sicherung auf halbem Weg fehlschlägt. Je nachdem, wie viel Zeit Ihrer geplanten Ausfallzeit bereits verstrichen ist, müssen Sie die Migration möglicherweise verschieben, wenn die Migrationsaufgabe nicht innerhalb der erwarteten Zeit abgeschlossen wird.

Ein Fallback-Plan bezieht sich in der Regel auf das Zurückrollen der Migration nach der Produktionsübernahme, wenn Probleme mit der Zielinstanz auftreten. Wenn Sie einen Fallback-Plan implementieren, denken Sie daran, dass er als vollständige Datenbankmigration behandelt werden muss, einschließlich Planung und Tests.

Wenn Sie sich gegen einen Fallback-Plan entscheiden, müssen Sie die möglichen Folgen verstehen. Wenn Sie keinen Notfallplan haben, kann dies unvorhergesehene Mehrarbeit verursachen und zu vermeidbaren Unterbrechungen bei der Migration führen.

Auch wenn ein Fallback das letzte Mittel ist und bei den meisten Datenbankmigrationen nicht verwendet wird, empfehlen wir Ihnen, immer eine Fallback-Strategie zu haben.

Einfaches Fallback

Bei dieser Fallback-Strategie stellen Sie Ihre Anwendungen wieder auf die ursprüngliche Quelldatenbankinstanz um. Verwenden Sie diese Strategie, wenn Sie sich eine Ausfallzeit leisten können, wenn Sie auf das Notfallsystem umstellen, oder wenn Sie die Transaktionen, die im neuen Zielsystem ausgeführt wurden, nicht benötigen.

Wenn Sie alle in der Zieldatenbank geschriebenen Daten benötigen und sich eine gewisse Ausfallzeit leisten können, können Sie die Schreibvorgänge für die Zieldatenbankinstanz beenden, integrierte Sicherungen erstellen und in der Quellinstanz wiederherstellen. Anschließend können Sie Ihre Anwendungen wieder mit der ursprünglichen Quelldatenbankinstanz verbinden. Je nach Art der Arbeitslast und der in der Zieldatenbankinstanz geschriebenen Datenmenge können Sie diese zu einem späteren Zeitpunkt in Ihr ursprüngliches Quelldatenbanksystem einbringen, insbesondere wenn Ihre Arbeitslast nicht von einem bestimmten Erstellungszeitpunkt der Datensätze oder von zeitlichen Beschränkungen abhängig ist.

Rückwärtsreplikation

Bei dieser Strategie werden die Schreibvorgänge, die nach der Produktionsumstellung in Ihrer neuen Zieldatenbank stattfinden, in Ihre ursprüngliche Quelldatenbank repliziert. Auf diese Weise halten Sie die ursprüngliche Quelle mit der neuen Zieldatenbank synchron und lassen die Schreibvorgänge in der neuen Zieldatenbankinstanz stattfinden. Der größte Nachteil ist, dass Sie den Replikationsstream erst testen können, nachdem Sie die Zieldatenbankinstanz erstellt haben. Daher sind keine End-to-End-Tests möglich und es gibt eine kurze Zeitspanne ohne Fallback.

Wählen Sie diesen Ansatz aus, wenn Sie Ihre Quellinstanz noch einige Zeit beibehalten können und die Migration mit der Migration mit kontinuierlicher Replikation ausführen.

Vorwärtsreplikation

Diese Strategie ist eine Variante der Rückwärtsreplikation. Sie replizieren die Schreibvorgänge in Ihrer neuen Zieldatenbank auf eine dritte Datenbankinstanz Ihrer Wahl. Sie können Ihre Anwendungen auf diese dritte Datenbank verweisen, die eine Verbindung zum Server herstellt und Lesezugriffsanfragen ausführt, während der Server nicht verfügbar ist. Sie können jeden Replikationsmechanismus je nach Bedarf verwenden. Der Vorteil dieses Ansatzes ist, dass er vollständig getestet werden kann.

Verwenden Sie diesen Ansatz, wenn immer ein Fallback verwendet werden soll oder wenn Sie Ihre anfängliche Quelldatenbank kurz nach der Produktionsumstellung verwerfen müssen.

Doppelte Schreibvorgänge

Wenn Sie eine Migrationsstrategie für den Mikrodienst „Y (Schreiben und Lesen)“ oder „Datenzugriff“ auswählen, ist dieser Fallback-Plan bereits festgelegt. Diese Strategie ist etwas komplizierter, da Sie Anwendungen umschreiben oder Tools entwickeln müssen, die eine Verbindung zu Ihren Datenbankinstanzen herstellen.

Ihre Anwendungen schreiben sowohl in die anfänglichen Quell- als auch in die Zieldatenbankinstanzen, sodass Sie eine schrittweise Umstellung der Produktion vornehmen können, bis Sie nur noch Ihre Zieldatenbankinstanzen verwenden. Falls Probleme auftreten, verbinden Sie Ihre Anwendungen ohne Ausfallzeiten wieder mit der ursprünglichen Quelle. Sie können die ursprüngliche Quelle und den doppelten Schreibmechanismus verwerfen, wenn Sie die Migration als problemlos durchgeführt betrachten.

Wir empfehlen diesen Ansatz, wenn es wichtig ist, keine Ausfallzeiten bei der Migration zu haben, ein zuverlässiges Fallback zu haben und wenn Sie Zeit und Ressourcen für die Refaktorierung der Anwendung haben.

Testen und Validieren

In diesem Schritt werden folgende Punkte getestet und validiert:

• Die Daten in der Datenbank wurden erfolgreich migriert.
• Einbindung in vorhandene Anwendungen nach der Umstellung auf die neue Zielinstanz.

Definieren Sie die wichtigsten Erfolgsfaktoren, die für Ihre Migration subjektiv sind. Dies sind Beispiele für subjektive Faktoren:

• Welche Daten migriert werden sollen. Bei einigen Arbeitslasten ist es möglicherweise nicht erforderlich, alle Daten zu migrieren. Möglicherweise möchten Sie keine Daten migrieren, die bereits aggregiert, redundant, archiviert oder alt sind. Sie können diese Daten in einem Cloud Storage-Bucket als Sicherung archivieren.
• Ein akzeptabler Prozentsatz an Datenverlust. Das gilt insbesondere für Daten, die für Analysearbeitslasten verwendet werden, bei denen der Verlust eines Teils der Daten sich nicht auf allgemeine Trends oder die Leistung Ihrer Arbeitslasten auswirkt.
• Kriterien für Datenqualität und -quantität, die Sie auf Ihre Quellumgebung anwenden und nach der Migration mit der Zielumgebung vergleichen können.
• Leistungskriterien Einige Geschäftstransaktionen sind in der Zielumgebung möglicherweise langsamer, die Verarbeitungszeit liegt aber immer noch innerhalb der definierten Erwartungen.

Die Speicherkonfigurationen in Ihrer Quellumgebung lassen sich möglicherweise nicht direkt zu Google Cloud-Umgebungszielen zuordnen. Dazu gehören beispielsweise Konfigurationen aus den Volumes vom Typ „SSD für allgemeine Zwecke“ (gp2 und gp3) mit IOPS-Burst-Leistung oder SSD mit bereitgestellten IOPS. Führen Sie ein Benchmarking Ihrer Quelle durch, um die Zielinstanzen zu vergleichen und die richtige Größe zu bestimmen, sowohl in der Bewertungs- als auch in der Validierungsphase.

Beim Benchmarking wenden Sie produktionsähnliche Abfolgen von Vorgängen auf die Datenbankinstanzen an. Während dieser Zeit erfassen und verarbeiten Sie Messwerte, um die relative Leistung sowohl des Quell- als auch des Zielsystems zu messen und zu vergleichen.

Verwenden Sie für herkömmliche, serverbasierte Konfigurationen relevante Messwerte, die bei Spitzenlasten erfasst wurden. Bei flexiblen Ressourcenkapazitätsmodellen wie Aurora Serverless sollten Sie sich Verlaufsmessdaten ansehen, um Ihre Skalierungsanforderungen zu beobachten.

Die folgenden Tools können für Tests, Validierung und Datenbank-Benchmarking verwendet werden:

• HammerDB: Ein Open-Source-Tool für Datenbank-Benchmarking und Lasttests. Es unterstützt komplexe Transaktions- und Analysearbeitslasten auf der Grundlage von Industriestandards auf mehreren Datenbank-Engines (sowohl TPROC-C als auch TPROC-H). HammerDB hat eine detaillierte Dokumentation und eine große Nutzergemeinschaft. Sie können Ergebnisse für mehrere Datenbank-Engines und Speicherkonfigurationen freigeben und vergleichen. Weitere Informationen finden Sie unter SQL Server-Lasttests mit HammerDB und Amazon RDS SQL Server-Leistung mit HammerDB benchmarken.
• DBT2-Benchmark-Tool: Benchmarking speziell für MySQL. Eine Reihe von Datenbank-Workload-Kits imitieren eine Anwendung für ein Unternehmen, das Lager besitzt und eine Mischung aus Lese- und Schreibtransaktionen umfasst. Verwenden Sie dieses Tool, wenn Sie einen vorgefertigten Lasttest für die Online-Transaktionsverarbeitung (OLTP) verwenden möchten.
• DbUnit: Ein Open-Source-Tool zum Testen von Einheiten, mit dem relationale Datenbankinteraktionen in Java getestet werden können. Die Einrichtung und Verwendung ist unkompliziert und unterstützt mehrere Datenbankmodule (z. B. MySQL, PostgreSQL und SQL Server) verwenden. Je nach Größe und Komplexität der Datenbank kann die Testausführung jedoch auch länger dauern. Wir empfehlen dieses Tool, wenn es möglichst einfach sein soll.
• DbFit: Ein Open-Source-Framework für Datenbanktests, das die testgesteuerte Codeentwicklung und automatisierte Tests unterstützt. Es verwendet eine einfache Syntax für die Erstellung von Testfällen und bietet datengesteuerte Tests, Versionskontrolle und Testergebnisberichte. Support für komplexe Abfragen und Transaktionen ist jedoch begrenzt und es gibt im Vergleich zu anderen Tools keine große Community-Support oder umfangreiche Dokumentation. Wir empfehlen dieses Tool, wenn Ihre Abfragen nicht komplex sind und Sie automatisierte Tests durchführen möchten und diese in die Continuous Integration- und Continuous Delivery-Prozesse integrieren wollen.

Führen Sie immer einen Migrations-Probelauf durch, um einen End-to-End-Test durchzuführen, einschließlich des Migrationsplans. Durch einen Probelauf wird die Datenbankmigration in vollem Umfang durchgeführt, ohne dass die Produktionsarbeitslasten gewechselt werden:

• Hier können Sie prüfen, ob alle Objekte und Konfigurationen ordnungsgemäß migriert wurden.
• Hilft Ihnen, Migrationstestfälle zu definieren und auszuführen.
• Sie erhalten einen Einblick in die Zeit, die für die eigentliche Migration benötigt wird. Damit können Sie Ihre Zeitachse kalibrieren.
• Bietet die Möglichkeit, den Migrationsplan zu testen, zu validieren und anzupassen. Manchmal kann man nicht alles im Voraus planen. Das hilft Ihnen, eventuelle Lücken zu erkennen.

Datentests können mit einem kleinen Teil der zu migrierenden Datenbanken oder mit dem gesamten Satz durchgeführt werden. Je nach Gesamtzahl der Datenbanken und den Tools, die für die Migration verwendet werden, können Sie einen risikobasierten Ansatz wählen. Mit diesem Ansatz führen Sie die Datenvalidierung für eine Teilmenge von Datenbanken durch, die mit demselben Tool migriert wurden, insbesondere wenn es sich um einen verwalteten Migrationsdienst handelt.

Für Tests sollten Sie Zugriff auf Quell- und Zieldatenbanken haben und die folgenden Aufgaben durchführen:

• Vergleichen Sie Quell- und Zielschemas. Prüfen Sie, ob alle Tabellen und ausführbaren Dateien vorhanden sind. Zeilenanzahl prüfen und Daten auf Datenbankebene vergleichen
• Führen Sie Benutzerdefinierte Datenvalidierungsskripts aus.
• Prüfen Sie, ob die migrierten Daten auch in den Anwendungen sichtbar sind, die auf die Verwendung der Zieldatenbank umgestellt wurden. Migrierte Daten werden über die Anwendung gelesen.
• Führen Sie Integrationstests zwischen den umgestellten Anwendungen und der Zieldatenbank durch, indem Sie verschiedene Anwendungsfälle testen. Diese Tests umfassen sowohl das Lesen als auch das Schreiben von Daten in die Zieldatenbanken über die Anwendungen, damit die Arbeitslasten migrierte Daten zusammen mit neu erstellten Daten vollständig unterstützen.
• Testen Sie die Leistung der am häufigsten verwendeten Datenbankabfragen, um festzustellen, ob es aufgrund von Fehlkonfigurationen oder falscher Dimensionierung zu Beeinträchtigungen kommt.

Im Idealfall sind alle diese Migrationstestszenarien in jedem Quellsystem automatisiert und wiederholbar. Die Suite der automatisierten Testfälle wird so angepasst, dass sie für die umgestellten Anwendungen ausgeführt werden kann.

Wenn Sie den Database Migration Service als Migrationstool verwenden, lesen Sie den Hilfeartikel Migration prüfen.

Datenvalidierungstool

Für die Datenvalidierung empfehlen wir die Verwendung des Datenvalidierungstools (DVT). DVT ist ein Open-Source-Python-Befehlszeilentool, das von Google unterstützt wird und eine automatisierte und wiederholbare Lösung für die Validierung in verschiedenen Umgebungen bietet.

Das DVT kann den Datenvalidierungsprozess optimieren, indem es benutzerdefinierte, mehrstufige Validierungsfunktionen bietet, um Quell- und Zieltabellen auf der Tabellen-, Spalten- und Zeilenebene zu vergleichen. Sie können auch Validierungsregeln hinzufügen.

Das DVT deckt viele Google Cloud-Datenquellen ab, darunter AlloyDB für PostgreSQL, BigQuery, Cloud SQL, Spanner, JSON und CSV-Dateien auf Cloud Storage. Es kann auch in Cloud Run-Funktionen und Cloud Run für eine ereignisbasierte Auslösung und Orchestrierung eingebunden werden.

Die DVT unterstützt die folgenden Validierungstypen:

• Vergleiche auf Schemaebene
• Spalte (einschließlich „AVG“, „COUNT“, „SUMME“, „MIN“, „MAX“, „GROUP BY“ und „STRING_AGG“)
• Zeile (einschließlich Hash- und exakter Übereinstimmung bei Feldvergleichen)
• Vergleich der Ergebnisse benutzerdefinierter Suchanfragen

Weitere Informationen zum DVT finden Sie im Git-Repository und im Artikel Datenvalidierung mit dem Google Cloud-Datenvalidierungstool.

Migration ausführen

Die Migrationsaufgaben umfassen die Aktivitäten, die die Übertragung von einem zu einem anderen System.

Beachten Sie bei der Datenmigration die folgenden Best Practices:

• Informieren Sie die beteiligten Teams, wenn ein Planungsschritt beginnt und endet.
• Wenn einer der Schritte länger als erwartet dauert, vergleichen Sie die verstrichene Zeit mit der maximalen Zeit, die für diesen Schritt vorgesehen ist. Informieren Sie die beteiligten Teams in diesem Fall regelmäßig über den Stand der Dinge.
• Wenn der Zeitraum länger ist als die maximale Zeit, die für jeden Schritt im Plan reserviert ist, sollten Sie einen Rollback ausführen.
• Treffen Sie für jeden Schritt des Migrations- und Umstellungsplans die Entscheidung „Go oder No-Go“.
• Berücksichtigen Sie für jeden Schritt Rollback-Aktionen oder alternative Szenarien.

Führen Sie die Migration gemäß Ihren definierten Ausführungsaufgaben aus und lesen Sie die Dokumentation des ausgewählten Migrationstools.

Produktionsumstellung ausführen

Der allgemeine Produktionsübergang kann je nach gewählter Migrationsstrategie variieren. Wenn Sie Ausfallzeiten für Ihre Arbeitslasten in Kauf nehmen können, beginnen Sie die Migrationsübernahme damit, dass Sie das Schreiben in die Quelldatenbank beenden.

Bei Migrationen mit kontinuierlicher Replikation führen Sie in der Regel die folgenden allgemeinen Schritte aus:

• Beenden Sie das Schreiben in die Quelldatenbank.
• Leeren Sie die Quelle.
• Beenden Sie den Replikationsprozess.
• Stellen Sie die Anwendungen bereit, die auf die neue Zieldatenbank verweisen.

Nachdem die Daten mit dem ausgewählten Migrationstool migriert wurden, validieren Sie sie in der Zieldatenbank. Sie bestätigen, dass die Quelldatenbank und die Zieldatenbank synchronisiert sind und die Daten in der Zielinstanz den von Ihnen gewählten Erfolgsstandards für die Migration entsprechen.

Sobald die Datenvalidierung Ihre Kriterien erfüllt, können Sie die Umstellung auf Anwendungsebene durchführen. Stellen Sie die Arbeitslasten bereit, die für die Verwendung der neuen Zielinstanz refaktorisiert wurden. Sie stellen die Versionen Ihrer Anwendungen bereit, die auf die neue Zieldatenbankinstanz verweisen. Die Bereitstellungen können entweder über Rolling Updates, gestaffelte Releases oder durch ein Blau/Grün-Bereitstellungsmuster erfolgen. Es kann zu einer kurzen Anwendungsausfallzeit kommen.

Beachten Sie die Best Practices für die Produktionsumstellung:

• Überwachen Sie Ihre Anwendungen, die mit der Zieldatenbank arbeiten, nach der Umstellung.
• Legen Sie einen Überwachungszeitraum fest, um zu entscheiden, ob Sie den Fallback-Plan implementieren müssen.
• Beachten Sie, dass Ihre Cloud SQL- oder AlloyDB for PostgreSQL-Instanz möglicherweise neu gestartet werden muss, wenn Sie einige Datenbank-Flags ändern.
• Beachten Sie, dass der Aufwand für das Rollback der Migration größer sein kann, als Probleme in der Zielumgebung zu beheben.

Quellumgebung bereinigen und Cloud SQL- oder AlloyDB for PostgreSQL-Instanz konfigurieren

Nach Abschluss der Umstellung können Sie die Quelldatenbanken löschen. Wir empfehlen Ihnen, die folgenden wichtigen Aktionen vor der Bereinigung Ihrer Quellinstanz durchzuführen:

• Erstellen Sie eine endgültige Sicherung jeder Quelldatenbank. Diese Sicherungen bieten Ihnen einen Endzustand der Quelldatenbanken. Die Sicherungen können auch in einigen Fällen erforderlich sein, um bestimmte Datenvorschriften einzuhalten.

• Erfassen Sie die Datenbankparametereinstellungen Ihrer Quellinstanz. Oder überprüfen Sie, ob sie mit denen übereinstimmen, die Sie in der Phase der Inventarerstellung gesammelt haben. Passen Sie die Parameter der Zielinstanz an die Parameter der Quellinstanz an.

• Sammeln Sie die Datenbankstatistiken der Quellinstanz und vergleichen Sie sie mit denen der Zielinstanz. Wenn die Statistiken nicht übereinstimmen, ist es schwierig, die Leistung von Quell- und Zielinstanz zu vergleichen.

Für ein Fallback-Szenario können Sie die Replikation Ihrer Schreibvorgänge in der Cloud SQL-Instanz zurück in die ursprüngliche Quelldatenbank implementieren. Die Einrichtung ähnelt dem Migrationsprozess, wird aber in umgekehrter Reihenfolge ausgeführt: Die ursprüngliche Quelldatenbank wird zum neuen Ziel.

Um die Quellinstanzen nach der Umstellung auf dem neuesten Stand zu halten, sollten Sie die Schreibvorgänge auf den Cloud SQL-Zielinstanzen zurück in die Quelldatenbank replizieren. Wenn Sie ein Rollback durchführen müssen, können Sie mit minimalen Datenverlusten auf Ihre alten Quellinstanzen zurückgreifen.

Neben der Bereinigung der Quellumgebung müssen Sie die folgenden wichtigen Konfigurationen für Ihre Cloud SQL-Instanzen vornehmen:

• Konfigurieren Sie für die primäre Instanz ein Wartungsfenster, in dem betriebsunterbrechende Updates erfolgen können.
• Konfigurieren Sie den Speicher auf der Instanz so, dass mindestens 20 % Speicherplatz zur Verfügung stehen, um kritische Datenbankwartungsvorgänge, die Cloud SQL durchführen könnte, unterzubringen. Wenn Sie eine Warnung erhalten möchten, wenn der verfügbare Speicherplatz unter 20 % liegt, erstellen Sie eine messwertbasierte Benachrichtigungsrichtlinie für den Messwert zur Laufwerksauslastung.

Starten Sie keinen neuen Verwaltungsvorgang, bevor der letzte Vorgang abgeschlossen ist.

Weitere Informationen zur Wartung und zu Best Practices finden Sie unter Wartung für Cloud SQL-Instanzen.

Umgebung nach der Migration optimieren

Die Optimierung ist die letzte Phase Ihrer Migration. In dieser Phase iterieren Sie Optimierungsaufgaben, bis Ihre Zielumgebung Ihre Optimierungsanforderungen erfüllt. Die Iteration umfasst folgende Schritte:

1. Bewerten Sie die aktuelle Umgebung, Teams und Optimierungsschleife.
2. Optimierungsanforderungen und -ziele festlegen.
3. Umgebung und Teams optimieren.
4. Verbessern Sie die Optimierungsschleife.

Wiederholen Sie diese Sequenz, bis Sie Ihre Optimierungsziele erreicht haben.

Weitere Informationen zum Optimieren Ihrer Google Cloud-Umgebung finden Sie unter Migrate to Google Cloud: Optimieren Sie Ihre Umgebung und den Leistungsoptimierungsprozess.

Optimierungsanforderungen festlegen

Prüfen Sie die folgenden Optimierungsanforderungen für Ihre Google Cloud-Umgebung und wählen Sie die Anforderungen aus, die sich am besten für Ihre Arbeitslasten eignet:

Zuverlässigkeit und Verfügbarkeit Ihrer Datenbank erhöhen

Mit Cloud SQL können Sie eine Strategie für Hochverfügbarkeit und Notfallwiederherstellung implementieren, die Ihrem Recovery Time Objective (RTO) und dem Recovery Point Objective (RPO) entspricht. Um die Zuverlässigkeit und Verfügbarkeit zu erhöhen, überlegen Sie Folgendes:

• Fügen Sie bei leselastigen Arbeitslasten Lesereplikate hinzu, um die primäre Instanz zu entlasten.
• Verwenden Sie für geschäftskritische Arbeitslasten die Hochverfügbarkeitskonfiguration, Replikate für den regionalen Failover und eine robuste Notfallwiederherstellungskonfiguration.
• Bei weniger kritischen Arbeitslasten reichen automatische und On-Demand-Sicherungen aus.
• Um ein versehentliches Löschen von Instanzen zu verhindern, verwenden Sie den Instanzlöschschutz.
• Sie können die Cloud SQL Enterprise Plus-Version verwenden, um von einer höheren Verfügbarkeit, einer längeren Protokollaufbewahrung und einer geplanten Wartung ohne Ausfallzeiten zu profitieren. Weitere Informationen zu Cloud SQL Enterprise Plus finden Sie unter Einführung in die Cloud SQL-Versionen und Geplante Wartung ohne Ausfallzeiten.

Weitere Informationen zur Erhöhung der Zuverlässigkeit und Verfügbarkeit Ihrer Datenbank finden Sie unter den folgenden Links:

• Replikate für die regionale Migration oder Notfallwiederherstellung hochstufen
• Notfallwiederherstellung von Cloud SQL-Datenbanken
• Cloud SQL-Sicherungen
• Löschen einer Instanz verhindern

Kosteneffizienz Ihrer Datenbankinfrastruktur erhöhen

Für positive wirtschaftliche Auswirkungen müssen Ihre Arbeitslasten die verfügbaren Ressourcen und Dienstleistungen effizient nutzen. Sie haben jetzt folgende Möglichkeiten:

• Stellen Sie der Datenbank die erforderliche Mindestspeicherkapazität bereit, indem Sie Folgendes tun:

  • Um die Speicherkapazität automatisch zu skalieren, wenn Ihre Daten wachsen, aktivieren Sie die automatische Speichererweiterungen. Sie sollten jedoch sicherstellen, dass Sie Ihre Instanzen so konfigurieren, dass sie bei Spitzenauslastungen über einen gewissen Puffer verfügen. Denken Sie daran, dass sich die Datenbankarbeitslasten im Laufe der Zeit tendenziell erhöhen.

• Identifizieren Sie möglicherweise überschätzte Ressourcen:

  • Durch die Größenanpassung Ihrer Cloud-SQL-Instanzen können Sie die Infrastrukturkosten senken, ohne zusätzliche Risiken für die Kapazitätsmanagementstrategie einzugehen.
  • Cloud Monitoring bietet vordefinierte Dashboards, mit denen Sie den Zustand und die Kapazitätsauslastung vieler Google Cloud-Komponenten, einschließlich Cloud SQL, ermitteln können. Weitere Informationen finden Sie unter Benutzerdefinierte Dashboards erstellen und verwalten.

• Identifizieren Sie Instanzen, für die keine Hochverfügbarkeits- oder Notfallwiederherstellungskonfigurationen erforderlich sind, und entfernen Sie sie aus Ihrer Infrastruktur.

• Entfernen Sie Tabellen und Objekte, die nicht mehr benötigt werden. Sie können sie in einem vollständigen Sicherungs- oder Archivierungs-Cloud Storage-Bucket speichern.

• Bestimmen Sie den kostengünstigsten Speichertyp (SSD oder HDD) für Ihren Anwendungsfall.

  • In den meisten Anwendungsfällen ist SSD die effizienteste und kostengünstigste Wahl.
  • Wenn Ihre Datasets groß (mindestens 10 TB), latenzunempfindlich sind oder nur selten darauf zugegriffen wird, ist eine HDD möglicherweise besser geeignet.
  • Weitere Informationen finden Sie unter Zwischen SSD- und HDD-Speicher wählen.

• Kaufen Sie für Arbeitslasten mit vorhersehbarem Ressourcenbedarf Rabatte für zugesicherte Nutzung.

• Verwenden Sie Active Assist, um Kosteninformationen und Empfehlungen zu erhalten.

  Weitere Informationen und Optionen finden Sie unter Mit Active Assist mehr erreichen: Empfehlungen zur Kostenoptimierung in Cloud SQL mit Active Assist.

Leistung der Datenbankinfrastruktur erhöhen

Kleinere datenbankbezogene Leistungsprobleme können sich häufig auf den gesamten Betrieb auswirken. Beachten Sie die folgenden Richtlinien, um die Leistung Ihrer Cloud SQL-Instanz beizubehalten und zu steigern:

• Eine große Anzahl von Datenbanktabellen kann sich auf die Leistung und Verfügbarkeit einer Instanz auswirken und dazu führen, dass die Instanz nicht mehr vom zugehörigen SLA abgedeckt ist.

• Achten Sie darauf, dass der Speicher bzw. die CPU-Leistung für die Instanz nicht zu knapp ist.

  • Für leistungsintensive Arbeitslasten sollten Sie sicherstellen, dass Ihre Instanz über mindestens 60 GB Speicher verfügt.
  • Wenn das Einfügen, Aktualisieren und Löschen von Datenbankeinträgen langsam ist, prüfen Sie den Ausgangsort des Schreibbefehls in Bezug auf den Standort der Datenbank. Werden Daten über weite Strecken übertragen, führt dies zu längeren Latenzzeiten.

• Verbessern Sie die Abfrageleistung mit dem vordefinierten Dashboard „Abfragestatistiken“ in Cloud Monitoring oder mit ähnlichen integrierten Funktionen der Datenbank-Engine. Identifizieren Sie die teuersten Befehle und versuchen Sie, sie zu optimieren.

• Verhindern, dass Datenbankdateien unnötig groß werden. Legen Sie autogrow in MB und nicht als Prozentsatz fest, indem Sie die Schritte verwenden, die für die Anforderung geeignet sind.

• Prüfen Sie den Standort des Lesers und der Datenbank. Latenz wirkt sich auf die Leseleistung mehr aus als auf die Schreibleistung.

• Sie können die Cloud SQL Enterprise Plus-Version verwenden, um von erweiterten Limits für die Maschinenkonfiguration und dem Datencache zu profitieren. Weitere Informationen finden Sie unter Einführung in Cloud SQL-Versionen.

Weitere Informationen zur Leistungssteigerung finden Sie unter Leistung im Abschnitt „Probleme diagnostizieren“.

Beobachtbarkeit von Datenbanken erhöhen

Die Diagnose und Behebung von Problemen in Anwendungen, die sich mit Datenbankinstanzen verbinden, kann schwierig und zeitaufwendig sein. Daher ist ein zentraler Ort erforderlich, an dem alle Teammitglieder sehen können, was auf Datenbank- und Instanzebene passiert. Sie können Cloud SQL-Instanzen auf folgende Arten überwachen:

• Cloud SQL verwendet integrierte, benutzerdefinierte Arbeitsspeicheragenten, um Abfragetelemetriedaten zu sammeln.

  • Verwenden Sie Cloud Monitoring, um Messungen Ihres Dienstes und der Google Cloud-Ressourcen, die Sie nutzen, zu sammeln. Cloud Monitoring umfasst vordefinierte Dashboards für mehrere Google Cloud-Produkte, einschließlich eines Cloud SQL-Monitoring-Dashboards.
  • Sie können benutzerdefinierte Dashboards erstellen, um Messwerte zu überwachen und Benachrichtigungsrichtlinien einrichten, damit Sie rechtzeitig Benachrichtigungen erhalten.
  • Alternativ können Sie auch Überwachungslösungen von Drittanbietern verwenden, die in die Google Cloud integriert sind, wie Datadog und Splunk.

• Cloud Logging erfasst Logging-Daten von gängigen Anwendungskomponenten.

• Cloud Trace erfasst Latenzdaten und ausgeführte Abfragepläne aus Anwendungen, damit Sie verfolgen können, wie Anfragen Ihre Anwendung durchlaufen.

• Datenbankcenter bietet eine KI-gestützte, zentralisierte Datenbankflotte. Sie können den Zustand Ihrer Datenbanken, die Verfügbarkeitskonfiguration, den Datenschutz, die Sicherheit und die Branchencompliance überwachen.

Allgemeine Best Practices und Betriebsrichtlinien für Cloud SQL

Wenden Sie die Best Practices für Cloud SQL an, um die Datenbank zu konfigurieren und zu optimieren.

Hier sind einige wichtige allgemeine Empfehlungen für Cloud SQL:

• Wenn Sie große Instanzen haben, empfehlen wir, sie nach Möglichkeit in kleinere Instanzen aufzuteilen.
• Konfigurieren Sie den Speicher für eine kritische Datenbankwartung. Achten Sie darauf, dass mindestens 20 % Speicherplatz für alle kritischen Datenbankwartungsvorgänge zur Verfügung stehen, die von Cloud SQL ausgeführt werden.
• Zu viele Datenbanktabellen können sich auf die Dauer des Datenbankupgrades auswirken. Idealerweise sollten weniger als 10.000 Tabellen pro Instanz vorhanden sein.
• Wählen Sie die richtige Größe für Ihre Instanzen aus, um die Aufbewahrung von (binären) Transaktionslogs zu berücksichtigen, insbesondere bei Instanzen mit hoher Schreibaktivität.

Um eventuelle Datenbankleistungsprobleme effizient beheben zu können, folgen Sie der folgenden Anleitung, bis das Problem behoben ist:

Infrastruktur hochskalieren: Erhöhen Sie die Ressourcen (z. B. Laufwerkdurchsatz, vCPU, und RAM). Je nach Dringlichkeit und Verfügbarkeit und Erfahrung Ihres Teams können Sie die meisten Leistungsprobleme beheben, indem Sie die Instanz vertikal skalieren. Später können Sie die Ursache des Problems in einer Testumgebung weiter untersuchen und Optionen zur Beseitigung des Problems prüfen.

Datenbankwartungsvorgänge ausführen und planen: Indexdefragmentierung, Aktualisierungen von Statistiken, Vakuumanalyse und Neuindexierung stark aktualisierter Tabellen. Prüfen Sie, ob und wann diese Wartungsvorgänge zuletzt ausgeführt wurden, insbesondere bei den betroffenen Objekten (Tabellen, Indexe). Prüfen Sie, ob es eine Abweichung von den normalen Datenbankaktivitäten gab. Das kann beispielsweise der Fall sein, wenn Sie vor Kurzem eine neue Spalte hinzugefügt oder viele Änderungen an einer Tabelle vorgenommen haben.

Datenbank optimieren: Sind die Tabellen in Ihrer Datenbank richtig strukturiert? Haben die Spalten die richtigen Datentypen? Ist Ihr Datenmodell für die Art der Arbeitslast geeignet? Prüfen Sie Ihre langsamen Abfragen und ihre Ausführungspläne. Werden die verfügbaren Indexe verwendet? Prüfen Sie, ob Indexscans, Sperren und Wartezeiten auf andere Ressourcen vorliegen. Sie können Indexe hinzufügen, um wichtige Abfragen zu unterstützen. Entfernen Sie nicht kritische Indexe und Fremdschlüssel. Erwägen Sie, komplexe Abfragen und Joins neu zu schreiben. Wie lange es dauert, bis Ihr Problem behoben ist, hängt von der Erfahrung und Verfügbarkeit Ihres Teams ab und kann von Stunden bis zu Tagen dauern.

Lesevorgänge skalieren: Sie können Lesereplikate verwenden. Wenn die vertikale Skalierung nicht ausreicht und Maßnahmen zur Datenbankoptimierung nicht helfen, sollten Sie eine horizontale Skalierung in Betracht ziehen. Die Weiterleitung von Leseabfragen aus Ihren Anwendungen an ein Lesereplikat verbessert die Gesamtleistung Ihrer Datenbanklast. Es ist jedoch möglicherweise mit zusätzlichem Aufwand verbunden, Ihre Anwendungen zu ändern, damit sie eine Verbindung zum Lesereplikat herstellen.

Datenbankarchitektur neu gestalten: Sie können die Datenbank partitionieren und indexieren. Dieser Vorgang erfordert wesentlich mehr Aufwand als die Datenbankabstimmung und -optimierung und kann eine Datenmigration erfordern, aber er kann eine langfristige Lösung sein. Manchmal kann ein schlechtes Datenmodelldesign zu Leistungsproblemen führen, die durch vertikales Skalieren teilweise kompensiert werden können. Ein richtiges Datenmodell ist jedoch eine langfristige Lösung. Sie können Ihre Tabellen partitionieren. Archivieren Sie nicht benötigte Daten, wenn möglich. Normalisieren Sie Ihre Datenbankstruktur. Denken Sie aber daran, dass auch eine Denormalisierung die Leistung verbessern kann.

Datenbank-Sharding: Sie können Ihre Schreibvorgänge skalieren, indem Sie Ihre Datenbank in Shards aufteilen. Das Sharding ist ein komplexer Vorgang, der die Neustrukturierung Ihrer Datenbank und Anwendungen auf eine bestimmte Weise und die Durchführung einer Datenmigration umfasst. Sie teilen Ihre Datenbankinstanz mithilfe bestimmter Partitionierungskriterien in mehrere kleinere Instanzen auf. Die Kriterien können sich auf den Kunden oder das Thema beziehen. Mit dieser Option können Sie Schreib- und Lesevorgänge horizontal skalieren. Dadurch wird jedoch die Komplexität Ihrer Datenbank- und Anwendungsarbeitslasten erhöht. Außerdem kann es zu ungleich verteilten Shards führen, die sogenannten Hotspots, die den Vorteil des Sharding überwiegen würden. – Achten Sie bei Cloud SQL for MySQL darauf, dass Ihre Tabellen einen Primär- oder eindeutigen Schlüssel haben. Cloud SQL verwendet die zeilenbasierte Replikation, die sich am besten für Tabellen mit Primärschlüsseln bzw. eindeutigen Schlüsseln eignet.

Weitere Informationen finden Sie in den allgemeinen Best Practices und den Betriebsrichtlinien für Cloud SQL for MySQL.

Nächste Schritte

• Informationen zu anderen Migrationspfaden von AWS zu Google Cloud
• AWS- und Azure-Dienste mit Google Cloud vergleichen.
• Hilfe für Migrationen erhalten
• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.

Beitragende

Autoren:

• Alex Cârciu | Solutions Architect
• Marco Ferrari | Cloud Solutions Architect

Weitere Beitragende:

• Derek Downey | Developer Relations Engineer
• Paweł Krentowski | Technical Writer
• Matthew Smith | Strategic Cloud Engineer
• Somdyuti Paul | Data Management Specialist
• Zach Seils | Networking Specialist