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

Last reviewed 2024-09-12 UTC

Google Cloud bietet Tools, Produkte, Anleitungen und professionelle Dienstleistungen, um von Amazon Relational Database Service (RDS) oder Amazon Aurora zu Cloud SQL for PostgreSQL oder AlloyDB for PostgreSQL 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 PostgreSQL und das Ziel Cloud SQL for PostgreSQL oder AlloyDB for PostgreSQL.

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

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:

Migrationspfad mit vier Phasen

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 enthalten 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- und Amazon Aurora-Instanzen. Idealerweise sollte dies ein automatisierter Prozess sein, da manuelle Ansätze fehleranfällig sind und zu falschen Annahmen führen können.

Amazon RDS oder Amazon Aurora und Cloud SQL for PostgreSQL oder AlloyDB for PostgreSQL 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 auf Integrationen und Erweiterungen bestimmter Datenbankmodulfunktionen beziehen. Je nach Datenbank-Engine-Typ, Instanzgröße und Architektur gibt es auch Unterschiede bei den Standardwerten der Datenbankparametereinstellungen.

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 der 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 for PostgreSQL-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 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 Listen mit Betriebssystemprozessen.

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 Cloud SQL for PostgreSQL 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 PostgreSQL-Instanzen zu Cloud SQL for PostgreSQL und AlloyDB for PostgreSQL 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:

Flussdiagramm zur Auswahl der Migrationsstrategie

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.

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

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

Für einmalige Migrationen zu Cloud SQL for PostgreSQL oder AlloyDB for PostgreSQL empfehlen wir, Datenbank-Engine-Sicherungen zu verwenden, um die Daten sowohl aus der Quellinstanz zu exportieren als auch in die Zielinstanz zu importieren. Einmalige Migrationsjobs werden vom Database Migration Service nicht unterstützt.

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. Dieser Ansatz eignet sich für jede Datenbankgröße und ist in der Regel bei großen Instanzen effektiver als andere Tools.

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 können nicht gesichert sein, wenn die Snapshots nicht ordnungsgemäß verwaltet werden.
  • Für Back-ups gibt es keine geeigneten Überwachungsmöglichkeiten.
  • Bei der Migration vieler Datenbanken ist es schwierig, Sicherungen zu skalieren.

Sie können die integrierten PostgreSQL-Sicherungstools pg_dump und pg_dumpall verwenden, um sowohl Cloud SQL for PostgreSQL als auch AlloyDB for PostgreSQL zu migrieren. Die Dienstprogramme pg_dump und pg_dumapall haben jedoch die folgenden allgemeinen Einschränkungen:

  • Die integrierten Sicherungstools sollten für die Migration von Datenbanken mit einer Größe von maximal 500 GB verwendet werden. Das Dumpen und Wiederherstellen großer Datenbanken kann sehr lange dauern und viel Speicherplatz und Arbeitsspeicher erfordern.
  • Das pg_dump-Dienstprogramm enthält keine Nutzer und Rollen. Sie können das Dienstprogramm pg_dumpall verwenden, um diese Nutzerkonten und Rollen zu migrieren.
  • Cloud Storage unterstützt einzelne Objekte mit einer Größe von bis zu 5 Terabyte (TB). Wenn Sie Datenbanken haben, die größer als 5 TB sind, schlägt der Exportvorgang nach Cloud Storage fehl. In diesem Fall müssen Sie die Exportdateien in kleinere Segmente unterteilen.

Wenn Sie diese Dienstprogramme verwenden, beachten Sie die folgenden Einschränkungen und Best Practices:

  • Komprimieren Sie Daten, um Kosten und Übertragungsdauer zu reduzieren. Verwenden Sie die Option --jobs mit dem Befehl pg_dump, um eine bestimmte Anzahl von Dumpjobs gleichzeitig auszuführen.
  • Verwenden Sie die Option -z mit dem Befehl pg_dump, um die zu verwendende Komprimierungsstufe anzugeben. Zulässige Werte für diese Option liegen zwischen 0 und 9. Der Standardwert ist eine Komprimierung auf Stufe 6. Höhere Werte verringern die Größe der Dumpdatei, können aber zu einem hohen Ressourcenverbrauch auf dem Clienthost führen. Wenn der Clienthost genügend Ressourcen hat, kann die Größe der Dumpdatei durch höhere Komprimierungsstufen weiter reduziert werden.
  • Verwenden Sie beim Erstellen einer SQL-Dumpdatei die richtigen Flags.
  • Prüfen Sie die importierte Datenbank. Beobachten Sie die Ausgabe des pg_restore-Dienstprogramms während des Wiederherstellungsvorgangs auf Fehlermeldungen. Prüfen Sie die PostgreSQL-Logs auf Warnungen oder Fehler während der Wiederherstellung. Führen Sie grundlegende Abfragen und Tabellenzählungen aus, um die Datenbankintegrität zu prüfen.

Weitere Informationen zu Einschränkungen und Best Practices finden Sie in den folgenden Ressourcen:

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

Die Verwendung anderer Ansätze als die integrierten Sicherungstools bietet möglicherweise mehr Kontrolle und Flexibilität bei der geplanten Wartungsmigration. Mit diesen anderen Ansätzen können Sie während der Migration Transformationen, Prüfungen oder andere Vorgänge auf Ihren Daten ausführen. Sie können mehrere Instanzen oder Datenbanken in einer einzigen Instanz oder Datenbank konsolidieren. Durch die Konsolidierung von Instanzen können Sie die Betriebskosten senken und Skalierbarkeitsprobleme verringern.

Eine solche Alternative zu Sicherungstools besteht darin, Flatfiles zum Exportieren und Importieren Ihrer Daten zu verwenden. Weitere Informationen zum Importieren von Flatfiles finden Sie unter Mithilfe von CSV-Dateien für Cloud SQL for PostgreSQL exportieren und importieren.

Eine weitere Alternative besteht darin, mit einem verwalteten Import eine Replikation aus einer externen PostgreSQL-Datenbank einzurichten. Bei einem verwalteten Import erfolgt eine anfängliche Datenübertragung von der externen Datenbank in die Cloud SQL for PostgreSQL-Instanz. Für diese anfängliche Datenübertragung wird ein Dienst verwendet, der Daten vom externen Server (RDS- oder Aurora-Instanz) extrahiert und direkt in die Cloud SQL for PostgreSQL-Instanz importiert. Weitere Informationen finden Sie unter Replikation aus externen Datenbanken mithilfe eines verwalteten Imports einrichten.

Eine alternative Möglichkeit für eine einmalige Datenmigration besteht darin, die Tabellen aus Ihrer PostgreSQL-Quelldatenbank in CSV- oder SQL-Dateien zu exportieren. Anschließend können Sie die CSV- oder SQL-Datei in Cloud SQL for PostgreSQL oder AlloyDB for PostgreSQL importieren. Sie können die aws_s3-Erweiterung für PostgreSQL verwenden, um das Datum Ihrer Quellinstanz zu exportieren. Alternativ können Sie den Amazon Database Migration Service und einen S3-Bucket als Ziel verwenden. Weitere Informationen zu diesem Ansatz finden Sie in den folgenden Ressourcen:

Sie können Daten auch manuell in eine AlloyDB for PostgreSQL-Instanz importieren. Folgende Formate werden unterstützt:

  • CSV: Bei diesem Dateiformat enthält jede Datei den Inhalt einer Tabelle in der Datenbank. Sie können die Daten mit dem Befehlszeilenprogramm psql in die CSV-Datei laden. Weitere Informationen finden Sie unter CSV-Datei importieren.
  • DMP: Dieses Dateiformat enthält das Archiv einer vollständigen PostgreSQL-Datenbank. Sie importieren Daten aus dieser Datei mit dem Dienstprogramm pg_restore. Weitere Informationen finden Sie unter DMP-Datei importieren.
  • SQL: Dieses Dateiformat enthält die Textrekonstruktion einer PostgreSQL-Datenbank. Die Daten in dieser Datei werden über die psql-Befehlszeile verarbeitet. Weitere Informationen finden Sie unter SQL-Datei importieren.

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:

Flussdiagramm zur Auswahl eines Tools für Migrationen mit kontinuierlicher Replikation

Das obige Flussdiagramm zeigt die folgenden Entscheidungspunkte:

  • Verwenden Sie lieber verwaltete Migrationsdienste?

    • Falls ja, können Sie sich ein paar Sekunden Schreibausfall leisten, während der Replikationsschritt ausgeführt wird?

      • 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 einen speziellen Jobtyp für kontinuierliche Migrationen. Diese fortlaufenden Migrationsjobs unterstützen High-Fidelity-Migrationen zu Cloud SQL for PostgreSQL und AlloyDB for PostgreSQL.

Wenn Sie den Database Migration Service für die Migration zu Cloud SQL for PostgreSQL oder AlloyDB for PostgreSQL verwenden, gelten für jede Zielinstanz bestimmte Voraussetzungen und 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. Die Datenbankreplizierung kann als einmaliger Vorgang oder als Abfolge von Batchvorgängen ausgeführt werden.

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. Diese Replikationstypen werden als logische Replikation bezeichnet. Für PostgreSQL gibt es auch Erweiterungen von Drittanbietern wie pglogical, die die logische Replikation mithilfe von Write-Ahead-Logging (WAL) implementieren.

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

Im Folgenden finden Sie Einschränkungen und Voraussetzungen für Cloud SQL for PostgreSQL:

  • Die folgenden Amazon-Versionen werden unterstützt:

    • Amazon RDS 9.6.10 und höher, 10.5 und höher, 11.1 und höher, 12, 13 und 14
    • Amazon Aurora 10.11 und höher, 11.6 und höher, 12.4 und höher sowie 13.3 und höher

  • Die Firewall des externen Servers muss so konfiguriert sein, dass der interne IP-Adressbereich zugelassen wird, der dem Zugriff auf private Dienste des VPC-Netzwerk zugewiesen ist. Die Cloud SQL for PostgreSQL-Replikatdatenbank verwendet das VPC-Netzwerk als privates Netzwerk.

  • Die Firewall der Quelldatenbank muss so konfiguriert sein, dass der gesamte interne IP-Adressbereich zugelassen wird, der für die private Dienstverbindung des VPC-Netzwerk zugewiesen ist. Die Cloud SQL for PostgreSQL-Ziellininstanz verwendet dieses VPC-Netzwerk im Feld privateNetwork der Einstellung IpConfiguration.

  • Wenn Sie die pglogical-Erweiterung auf einer Cloud SQL for PostgreSQL-Instanz installieren, müssen Sie das enable_pglogical-Flag auf on (z. B. cloudsql.enable_pglogical=on) setzen.

  • Der Parameter shared_preload_libraries muss die pglogical-Erweiterung in Ihrer Quellinstanz enthalten (z. B. shared_preload_libraries=pg_stat_statements,pglogical). Legen Sie den Parameter rds.logical_replication auf „1“ fest. Mit dieser Einstellung werden Vorabschreibprotokolle auf logischer Ebene aktiviert.

    Diese Änderungen erfordern einen Neustart der primären Instanz.

Weitere Informationen zur Verwendung von Cloud SQL for PostgreSQL für die Replikation finden Sie in der Checkliste für externe Server im Abschnitt zur Replikation für PostgreSQL sowie unter Logische Replikation und Decodierung für PostgreSQL einrichten in der offiziellen Cloud SQL-Dokumentation.

AlloyDB for PostgreSQL unterstützt die Replikation über die pglogical-Erweiterung. Mit dem Befehl CREATE EXTENSION können Sie die pglogical-Erweiterung für die Replikation aktivieren. Bevor Sie diesen Befehl verwenden, müssen Sie die Datenbankflaggen alloydb.enable_pglogical und alloydb.logical_decoding in der AlloyDB for PostgreSQL-Instanz, in der Sie die Erweiterung verwenden möchten, auf on setzen. Wenn Sie diese Flags festlegen möchten, muss die Instanz neu gestartet werden.

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

Mit Datastream können Sie Änderungen an Ihrer PostgreSQL-Quell-Instanz nahezu in Echtzeit replizieren. Datastream verwendet Change Data Capture (CDC) und Replikation, um Daten zu replizieren und zu synchronisieren. Anschließend können Sie Datastream für die kontinuierliche Replikation von Amazon RDS und Amazon Aurora verwenden. Mit Datastream können Sie Änderungen von Ihrer PostgreSQL-Instanz entweder in BigQuery oder Cloud Storage replizieren. Diese replizierten Daten können dann mit Dataflow, einer Dataflow-Flex-Vorlage oder mit Dataproc in Ihre Cloud SQL for PostgreSQL- und AlloyDB for PostgreSQL-Instanz importiert werden.

Weitere Informationen zur Verwendung von Datastream und Dataflow finden Sie in den folgenden Ressourcen:

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 ist beispielsweise der Fall, 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:

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 Cloud-Datenplattformen und zwischen ihnen 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 Migrationsüberprüfung: 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.

Parallele Datenbankmigrationsaufgaben

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:

  • Vorbereitungen und Voraussetzungen für eine Amazon RDS- oder Amazon Aurora-Instanz
  • Vorbereitung der Quelldatenbank und Voraussetzungen
  • Cloud SQL for PostgreSQL- und AlloyDB for PostgreSQL-Instanzeinrichtung
  • 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 zuzulassen, und die Sicherheitsgruppe auf Ihre Amazon RDS- oder Amazon Aurora-Instanz anwenden:

    • 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.

  • Wenn Sie von Amazon RDS migrieren, muss genügend freier Speicherplatz vorhanden sein, um Vorabschreibprotokolle für die Dauer des vollständigen Ladevorgangs in Ihrer Amazon RDS-Instanz zu puffern.

  • Für die fortlaufende Replikation (Streamingänderungen über CDC) müssen Sie eine vollständige RDS-Instanz und kein Lesereplikat verwenden.

  • Wenn Sie die integrierte Replikation verwenden, müssen Sie Ihre Amazon RDS- oder Amazon Aurora-Instanz für die Replikation für PostgreSQL einrichten. Für die integrierte Replikation oder Tools, die die integrierte Replikation verwenden, ist die logische Replikation für PostgreSQL erforderlich.

  • 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 PostgreSQL einrichten.

Vorbereitung der Quelldatenbank und Voraussetzungen

  • Wenn Sie Database Migration Service verwenden, müssen Sie Ihre Quelldatenbank konfigurieren, bevor Sie eine Verbindung herstellen. Weitere Informationen finden Sie unter Quelle für PostgreSQL konfigurieren und Quelle für PostgreSQL für AlloyDB for PostgreSQL konfigurieren.

  • Bei Tabellen ohne Primärschlüssel werden nach der Migration der ursprünglichen Sicherung durch den Database Migration Service während der CDC-Phase (Change Data Capture) nur INSERT-Anweisungen in die Zieldatenbank migriert. DELETE- und UPDATE-Anweisungen werden für diese Tabellen nicht migriert.

  • Große Objekte können nicht vom Database Migration Service repliziert werden, da die logische Decodierungsfunktion in PostgreSQL keine Decodierungsänderungen an großen Objekten unterstützt.

  • Wenn Sie die integrierte Replikation verwenden, beachten Sie, dass die logische Replikation bestimmte Einschränkungen in Bezug auf DDL-Befehle (Data Definition Language), Sequenzen und große Objekte hat. Für Tabellen, die für CDC aktiviert werden sollen und häufig aktualisiert werden, müssen Primärschlüssel vorhanden sein oder hinzugefügt werden.

  • Bei einigen Migrationstools von Drittanbietern müssen alle Spalten mit großen Objekten nullable sein. Bei allen Spalten mit großen Objekten vom Typ NOT NULL muss diese Einschränkung während der Migration entfernt werden.

  • Erstellen Sie Baseline-Messungen in Ihrer Produktionsumgebung. Berücksichtige 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 die Quellumgebung außer Betrieb nehmen können oder ob Sie sie noch als Fallback benötigen.

Cloud SQL for PostgreSQL- und AlloyDB for PostgreSQL-Instanzeinrichtung

Damit die Zielinstanz eine ähnliche Leistung wie die Quellinstanz erzielt, müssen Größe und Spezifikationen der Ziel-PostgreSQL-Datenbankinstanz mit denen der Quellinstanz übereinstimmen. Achten Sie dabei besonders auf Laufwerkgröße und Durchsatz, Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) und Anzahl der virtuellen CPUs (vCPUs). Falsche Größen können zu langen Migrationszeiten, Problemen mit der Datenbankleistung, Datenbankfehlern und Problemen mit der Anwendungsleistung führen. Berücksichtigen Sie bei der Entscheidung für eine Cloud SQL for PostgreSQL- oder AlloyDB for PostgreSQL-Instanz, dass die Laufwerkleistung von der Laufwerkgröße und der Anzahl der vCPUs abhängt.

Sie müssen die folgenden Eigenschaften und Anforderungen bestätigen, bevor Sie Ihre Cloud SQL for PostgreSQL- und AlloyDB for PostgreSQL-Instanzen erstellen. Wenn Sie diese Eigenschaften und Anforderungen später ändern möchten, müssen Sie die Instanzen neu erstellen.

  • Wählen Sie das Projekt und die Region Ihrer Ziel-Cloud SQL for PostgreSQL- und AlloyDB for PostgreSQL-Instanzen sorgfältig aus. Instanzen können nicht ohne Datenübertragung zwischen Google Cloud-Projekten und ‑Regionen migriert werden.

  • Migrieren Sie zu einer übereinstimmenden Hauptversion in Cloud SQL for PostgreSQL und AlloyDB for PostgreSQL. Wenn Sie beispielsweise PostgreSQL 14.x auf Amazon RDS oder Amazon Aurora verwenden, sollten Sie zu Cloud SQL oder AlloyDB for PostgreSQL für PostgreSQL 14.x migrieren.

  • Replizieren Sie die Nutzerinformationen separat, wenn Sie integrierte Datenbank-Engine-Sicherungen oder Database Migration Service verwenden. Einzelheiten hierzu finden Sie im Abschnitt Datenbankmodulspezifische Sicherungen.

  • Prüfen Sie die Datenbank-Engine-spezifischen Konfigurationsflags 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. Wenn Sie beispielsweise mit PostgreSQL arbeiten, empfehlen wir, die Werte aus der Tabelle pg_settings in der Quelldatenbank mit den Werten in der Cloud SQL- und AlloyDB for PostgreSQL-Instanz zu vergleichen. Aktualisieren Sie die Flag-Einstellungen nach Bedarf auf der Zieldatenbankinstanz, um die Quelleinstellungen zu replizieren.

  • Je nach Art Ihrer Arbeitslast müssen Sie möglicherweise bestimmte Erweiterungen aktivieren, um Ihre Datenbank zu unterstützen. Wenn für Ihre Arbeitslast diese Erweiterungen erforderlich sind, sehen Sie sich die unterstützten PostgreSQL-Erweiterungen und die Möglichkeit zum Aktivieren in Cloud SQL und AlloyDB for PostgreSQL an.

Weitere Informationen zur Einrichtung von Cloud SQL for PostgreSQL finden Sie unter Instanzkonfigurationsoptionen, Datenbankmodulspezifische Flags und unterstützte Erweiterungen.

Weitere Informationen zur Einrichtung von AlloyDB for PostgreSQL finden Sie unter Unterstützte Datenbank-Flags und Unterstützte Erweiterungen.

Migrationsspezifische Einrichtung

Wenn Sie eine Ausfallzeit in Kauf nehmen können, können Sie SQL-Dumpdateien in Cloud SQL und AlloyDB for PostgreSQL importieren. In solchen Fällen müssen Sie möglicherweise einen Cloud Storage-Bucket erstellen, um den Datenbankdump zu speichern.

Wenn Sie die Replikation verwenden, müssen Sie dafür sorgen, dass das Cloud SQL- und AlloyDB for PostgreSQL-Replikat Zugriff auf Ihre primäre (Quell-)Datenbank hat. Dieser Zugriff kann mithilfe der dokumentierten Verbindungsoptionen gewährt werden.

Je nach Anwendungsfall 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 Ihrem Cloud SQL- und AlloyDB for PostgreSQL-Ziel zurück zur Amazon-Quellinstanz.

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

Wenn Sie zu AlloyDB for PostgreSQL migrieren, können Sie eine Cloud SQL for PostgreSQL-Instanz als potenzielles Ziel für Ihre Fallback-Szenarien verwenden. Verwenden Sie die pglogical-Erweiterung, um die logische Replikation zu dieser Cloud SQL-Instanz einzurichten.

Weitere Informationen finden Sie in den folgenden Ressourcen:

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

Verwenden Sie das Dienstprogramm pg_dump, um eine Sicherung zu erstellen. Weitere Informationen zum Importieren und Exportieren von Daten mit diesem Dienstprogramm finden Sie in den folgenden Ressourcen:

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 dem ersten Schemadump und der Wiederherstellung ohne Indizes und Einschränkungen, gefolgt vom Datenkopievorgang. Nach Abschluss der Datenkopie werden Indexe und Einschränkungen wiederhergestellt. Schließlich wird die kontinuierliche Replikation von Änderungen von der Quelle zur Zieldatenbankinstanz gestartet.

Der Database Migration Service verwendet die Erweiterung pglogical für die Replikation von der Quelle zur Zieldatenbankinstanz. Zu Beginn der Migration richtet diese Erweiterung die Replikation ein, indem sie exklusive kurzfristige Sperren für alle Tabellen in Ihrer Quell-Amazon-RDS- oder Amazon-Aurora-Instanz erfordert. Aus diesem Grund empfehlen wir, die Migration zu starten, wenn die Datenbank am wenigsten ausgelastet ist, und während der Dump- und Replikationsphase keine Anweisungen in der Quelle auszuführen, da DDL-Anweisungen nicht repliziert werden. Wenn Sie DDL-Vorgänge ausführen müssen, verwenden Sie die Funktionen „pglogical“, um DDL-Anweisungen auf Ihrer Quellinstanz auszuführen, oder führen Sie dieselben DDL-Anweisungen manuell auf der Migrationszielinstanz aus, aber erst nach Abschluss der ersten Dumpphase.

Der Migrationsprozess mit Database Migration Service endet mit der Umstellung. 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 auch als Produktionsschalter bezeichnet.

Eine ausführliche Anleitung zur Migrationseinrichtung finden Sie in den Kurzanleitungen für PostgreSQL und PostgreSQL zu AlloyDB for PostgreSQL.

Integrierte Replikation des Datenbankmoduls

Cloud SQL unterstützt zwei Arten der logischen Replikation: die integrierte logische Replikation von PostgreSQL und die logische Replikation über die pglogical-Erweiterung. Für AlloyDB for PostgreSQL empfehlen wir die Verwendung der pglogical-Erweiterung für die Replikation. Jede Art der logischen Replikation hat ihre eigenen Funktionen und Einschränkungen.

Die integrierte logische Replikation hat folgende Funktionen und Einschränkungen:

  • Sie ist in PostgreSQL 10 und höher verfügbar.
  • Alle Änderungen und Spalten werden repliziert. Veröffentlichungen werden auf Tabellenebene definiert.
  • Daten werden nur von Basistabellen zu Basistabellen repliziert.
  • Es wird keine Sequenzreplikation durchgeführt.
  • Dieser Replikationstyp wird empfohlen, wenn es viele Tabellen ohne Primärschlüssel gibt. Richten Sie die integrierte logische PostgreSQL-Replikation ein. Wenden Sie für Tabellen ohne Primärschlüssel das Formular REPLICA IDENTITY FULL an, damit bei der integrierten Replikation die gesamte Zeile anstelle eines Primärschlüssels als eindeutige Kennung verwendet wird.

Die pglogical-logische Replikation hat folgende Funktionen und Einschränkungen:

  • Sie ist in allen PostgreSQL-Versionen verfügbar und bietet versionsunabhängige Unterstützung.
  • Die Zeilenfilterung ist in der Quelle verfügbar.
  • Die Tabellen UNLOGGED und TEMPORARY werden nicht repliziert.
  • Tabellen benötigen einen Primärschlüssel oder eindeutigen Schlüssel, um UPDATE- und DELETE-Änderungen zu erfassen.
  • Die Sequenzreplikation ist verfügbar.
  • Eine verzögerte Replikation ist möglich.
  • Es bietet Konflikterkennung und konfigurierbare Konfliktlösung, wenn es mehrere Publisher oder Konflikte zwischen replizierten Daten und lokalen Änderungen gibt.

Eine Anleitung zum Einrichten der integrierten logischen PostgreSQL-Replikation von einem externen Server wie Amazon RDS oder Amazon Aurora for PostgreSQL finden Sie in den folgenden Ressourcen:

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.

Sie verwenden einen oder mehrere Abläufe, um diese Migrationsprozesse in Ihren benutzerdefinierten Anwendungen zu organisieren. Zum Codieren Ihrer benutzerdefinierten Anwendungen können Sie ein grafisches Programmiertool oder die Programmiersprache Tungsten Query Language (TQL) verwenden.

Weitere Informationen zur Verwendung von Striim finden Sie in den folgenden Ressourcen:

Wenn Sie sich dafür entscheiden, Ihre Daten mit Striim zu migrieren, lesen Sie die folgenden Anleitungen zur Migration von Daten mit Striim in Google Cloud:

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 in 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 entweder den Abschnitt „Migration prüfen“ für PostgreSQL oder PostgreSQL zu AlloyDB for PostgreSQL.

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.

Alternativ können Sie eine andere Instanz verwenden und Ihre Änderungen auf diese Instanz replizieren. Wenn AlloyDB for PostgreSQL beispielsweise ein Migrationsziel ist, sollten Sie für Notfallszenarien die Replikation zu einer Cloud SQL for PostgreSQL-Instanz einrichten.

Neben der Bereinigung der Quellumgebung müssen die folgenden wichtigen Konfigurationen für Ihre Cloud SQL for PostgreSQL-Instanzen vorgenommen werden:

  • 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 für Cloud SQL for PostgreSQL- und AlloyDB for PostgreSQL-Instanzen finden Sie in den folgenden Ressourcen:

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:

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:

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.

Beachten Sie bei der Migration von Amazon RDS und Aurora for PostgreSQL zu Cloud SQL for PostgreSQL die folgenden Richtlinien:

  • Verwenden Sie Caching, um die Leseleistung zu verbessern. Sehen Sie sich die verschiedenen Statistiken in der Ansicht pg_stat_database an. Das blks_hit / (blks_hit + blks_read)-Verhältnis sollte beispielsweise über 99 % liegen. Wenn dieses Verhältnis nicht über 99 % liegt, sollten Sie den Arbeitsspeicher Ihrer Instanz unter Umständen vergrößern. Weitere Informationen finden Sie unter PostgreSQL-Statistik-Collector.
  • So können Sie Speicherplatz freigeben und eine schlechte Indexleistung verhindern. Je nachdem, wie oft sich Ihre Daten ändern, können Sie entweder einen Zeitplan für die Ausführung des Befehls VACUUM in Ihrer Cloud SQL for PostgreSQL-Datenbank festlegen oder
  • Verwenden Sie die Cloud SQL Enterprise Plus-Version, um die Limits für die Maschinenkonfiguration und den Datencache zu erhöhen. Weitere Informationen zu Cloud SQL Enterprise Plus finden Sie unter Einführung in die Cloud SQL -Versionen.
  • Wechseln Sie zu AlloyDB for PostgreSQL. Wenn Sie wechseln, profitieren Sie von vollständiger PostgreSQL-Kompatibilität, besserer transaktionaler Verarbeitung und schnelleren transaktionalen Analysearbeitslasten, die in Ihrer Verarbeitungsdatenbank unterstützt werden. Außerdem erhalten Sie über die Funktion „Indexberater“ eine Empfehlung für neue Indexe.

Weitere Informationen zum Optimieren der Leistung Ihrer Cloud SQL for PostgreSQL-Datenbankinfrastruktur finden Sie in der Dokumentation zur Leistungssteigerung von Cloud SQL für PostgreSQL.

Wenn Sie von Amazon RDS und Aurora for PostgreSQL zu AlloyDB for PostgreSQL migrieren, beachten Sie die folgenden Richtlinien, um die Leistung Ihrer AlloyDB for PostgreSQL-Datenbankinstanz zu steigern:

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.

Weitere Informationen zur Verbesserung der Beobachtbarkeit Ihrer Datenbankinfrastruktur finden Sie in den folgenden Abschnitten der Dokumentation:

Allgemeine Best Practices und Betriebsrichtlinien für Cloud SQL und AlloyDB for PostgreSQL

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, was den Vorteil des Sharding überwiegen würde.

Beachten Sie für Cloud SQL for PostgreSQL und AlloyDB for PostgreSQL die folgenden Best Practices:

  • Fügen Sie Lesereplikate hinzu, um die primäre Instanz zu entlasten. Sie können auch einen Load Balancer wie HAProxy verwenden, um den Traffic zu den Replikaten zu verwalten. Vermeiden Sie jedoch zu viele Repliken, da dies den VACUUM-Vorgang beeinträchtigt. Weitere Informationen zur Verwendung von HAProxy finden Sie auf der offiziellen HAProxy.
  • Optimieren Sie die VACUUM-Ausführung, indem Sie den Systemspeicher und den Parameter maintenance_work_mem erhöhen. Wenn Sie den Systemspeicher erhöhen, können in jeder Iteration mehr Tupel in Batches verarbeitet werden.
  • Größere Indexe verbrauchen viel Zeit für den Indexscan. Daher wird INDEX_CLEANUP bevorzugt, um die Tabellendaten schnell zu bereinigen und zu fixieren.OFF
  • Wenn Sie AlloyDB for PostgreSQL verwenden, verwenden Sie das AlloyDB for PostgreSQL-Systemstatistik-Dashboard und die Audit-Logs. Im AlloyDB for PostgreSQL-Systemstatistik-Dashboard werden Messwerte für die von Ihnen verwendeten Ressourcen angezeigt und Sie können sie überwachen. Weitere Informationen finden Sie in der AlloyDB for PostgreSQL-Dokumentation unter Instanzen überwachen.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Nächste Schritte

Beitragende

Autoren:

Weiterer Mitwirkender: Somdyuti Paul | Data Management Specialist