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 für die Migration von Amazon Relational Database Service (RDS) oder Amazon Aurora zu Cloud SQL for PostgreSQL oder AlloyDB for PostgreSQL.

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 zuGoogle Cloud , die folgende Dokumente enthält:

Für diese Migration zu Google Cloudempfehlen wir die Ausführung des unter Zu Google Cloudmigrieren: Erste Schritte beschriebenen Migrations-Frameworks.

Diese Grafik veranschaulicht den Migrationsprozess:

Migrationspfad mit vier Phasen

Die Migration von Ihrer Quellumgebung zu Google Cloud erfolgt in einer Reihe von Iterationen, z. B. einige Arbeitslasten werden zuerst migriert und andere später. Für jede separate Migrationsiteration folgen Sie den Phasen des allgemeinen Migrations-Frameworks:

  1. Arbeitslasten und Daten bewerten und erkennen.
  2. Grundlage in Google Cloudplanen und erstellen.
  3. Arbeitslasten und Daten zu Google Cloudmigrieren.
  4. Google Cloud Umgebung optimieren

Weitere Informationen zu den Phasen dieses Frameworks finden Sie unter Zu Google Cloudmigrieren: 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 Zu Google Cloudmigrieren: 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 Cloudvorbereiten.
  4. Tests und Proofs of Concept für Google Clouderstellen.
  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 Datenbankbewertungsphase können Sie die Größe und die Spezifikationen Ihrer Cloud SQL-Zieldatenbankinstanz 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 Dimensionierung der Zieldatenbankinstanz fehlschlagen. Falsche Größen können zu langen Migrationszeiten, Problemen mit der Datenbankleistung, Datenbankfehlern und Probleme mit der Anwendungsleistung führen. Bei der Auswahl der Cloud SQL-Instanz sollten Sie berücksichtigen, dass die Laufwerksleistung von der Laufwerksgröße und der Anzahl der vCPUs abhängt.

Die folgenden Abschnitte basieren auf dem Dokument Zu Google Cloudmigrieren: Arbeitslasten bewerten und erkennen und enthalten die Informationen aus diesem Dokument.

Inventar Ihrer Amazon RDS- oder Amazon Aurora-Instanzen erstellen

Um den Umfang Ihrer Migration zu definieren, erstellen Sie ein Inventar und sammeln Informationen zu Ihren Amazon RDS- und Amazon Aurora-Instanzen. Im Idealfall 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, Instanzspezifikationen oder Abläufe. Einige Funktionen sind möglicherweise anders implementiert oder nicht verfügbar. Zu den Bereichen, in denen es Unterschiede geben kann, gehören Infrastruktur, Speicher, Authentifizierung und Sicherheit, Replikation, Sicherung, Hochverfügbarkeit, Ressourcenkapazitätsmodell und spezifische Integrationen von Datenbankmodulfunktionen sowie Erweiterungen. 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 die richtige Architektur der Zielumgebung zu definieren. Das Erfassen von Informationen zur Leistung ist wichtig, um den Leistungsbedarf der Google Cloud Zielumgebung Google Cloud 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, durchfü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 Google Cloud empfehlen, einschließlich der anfänglichen Größe und Architektur.

Die migVisor-Datenbankbewertungsausgabe enthält Folgendes:

  • Umfassende Ermittlung und Analyse aktueller Datenbankbereitstellungen.
  • 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.
  • Ein schrittweiser Migrationsplan zum Migrieren von Datenbanken und zugehörigen Anwendungen mit minimalen Auswirkungen auf das Unternehmen.

Einige Beispiele für die Bewertungsausgabe finden Sie unter migVisor – Cloud-Migrationsbewertungstool.

Beachten Sie, dass migVisor die Auslastung des Datenbankservers vorübergehend erhöht. 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 der Datenbank-Engine, CPUs und Speichergröße) sowie Details zur Datenbanktopologie, zu Sicherungsrichtlinien, zu Parametereinstellungen und zu 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, Triggern und gespeicherten 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 einen Datenbankbewertungsbericht und gibt die nächsten Schritte für die Migration an.

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 in Anspruch nehmen. 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 Daten auch nach der Migration verschieben.

Legen Sie Basislinien für die Datenmigration fest, mit denen Sie Ihre 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 Entscheidungen helfen. Es ist wichtig, Messungen in der Quellumgebung vorzunehmen, um den Erfolg Ihrer Datenmigration zu bewerten. Dazu 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 viel Ausfallzeit Sie sich leisten können. 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 möglicherweise Amazon CloudWatch, Performance Insights, Enhanced Monitoring und Betriebssystemprozesslisten.

Bewertung abschließen

Nachdem Sie das Inventar aus Ihrer Amazon RDS- oder Amazon Aurora-Umgebung erstellt haben, schließen Sie die restlichen Aktivitäten der Bewertungsphase ab, wie unter Zu Google Cloudmigrieren: 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 Sie Ihre Quellumgebung und Ihre 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 die Identitäts- und Zugriffsverwaltung (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 Zu Google Cloudmigrieren: Grundlage planen und aufbauen.

Wenn Sie Database Migration Service für die Migration verwenden möchten, lesen Sie den Abschnitt Netzwerkmethoden für Cloud SQL for PostgreSQL, um die für Migrationsszenarien verfügbaren Netzwerkkonfigurationen kennenzulernen.

Monitoring und Benachrichtigungen

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

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. Migrationsplan und Zeitplan für jede Datenbankmigration definieren, 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. Quellumgebung bereinigen und Zielinstanz konfigurieren

  11. Abstimmung und Optimierung durchführen

Die einzelnen Phasen werden in folgenden Abschnitten beschrieben.

Migrationsstrategie auswählen

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

  • Geplante Wartung (auch als einmalige Migration oder Big-Bang-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 Online-Migration oder Trickle-Migration bezeichnet): Für geschäftskritische 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 können eine der folgenden Varianten verwenden:

    • 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 stellen könnten, wenn Sie die Migrationsstrategie für eine einzelne Datenbank festlegen:

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, übernehmen Sie die Migrationsstrategie für geplante Wartung.

Strategien können für verschiedene Datenbanken variieren, auch wenn sie sich auf derselben Instanz befinden. Mit einer Kombination von Strategien lassen sich optimale Ergebnisse erzielen. 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. Die Replikation (falls verwendet) wird beendet und alle Lese- und Schreibvorgänge werden auf der Zielinstanz ausgeführt. Wenn Sie wechseln, während beide Instanzen synchronisiert sind, kommt es zu keinem Datenverlust und die Ausfallzeit ist minimal.

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

Migrationskonfigurationen, die keine Ausfallzeiten der Anwendung verursachen, erfordern eine kompliziertere Einrichtung. Finden Sie das richtige Gleichgewicht zwischen Komplexität der Einrichtung und Ausfallzeiten, die während der verkehrsarmen Geschäftszeiten geplant werden.

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:

  • Die Ausführung von Datenbankabfragen kann 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 Cloudneu gestartet wurden, haben möglicherweise eine kleine Verzögerung bis zur Verbindung mit der Google Cloud-Datenbankinstanz.
  • Netzwerkrouten zu den Anwendungen müssen neu geroutet 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.

Die folgenden gängigen Praktiken können dazu beitragen, Ausfallzeiten und Auswirkungen zu 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 der Produktion umgestellt 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 Batch-Datenübertragungen und passen Sie einen Teil Ihrer Arbeitslasten an, damit sie mit den veralteten Daten in der Zielinstanz funktionieren.
  • 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 ‑Engine-Versionen.
  • 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 verwalteter Dienste für die Migration.

Für eine nahtlose Migration und Umstellung können Sie Anwendungsbereitstellungsmuster, Infrastrukturorchestrierung und benutzerdefinierte Migrationsanwendungen verwenden. Spezialisierte Tools, sogenannte Managed Migration Services, können jedoch den Prozess der Migration von Daten, Anwendungen oder sogar ganzen Infrastrukturen von einer Umgebung in eine andere erleichtern. Sie führen die Datenextraktion aus den Quelldatenbanken aus, übertragen Daten sicher in die Zieldatenbanken und können die Daten während der Übertragung optional ä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 entwickeln.

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

In den nächsten 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-Back-ups zu verwenden, um die Daten aus der Quellinstanz zu exportieren und in die Zielinstanz zu importieren. Einmalige Migrationsjobs werden in 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 Funktionen zum Sichern und Wiederherstellen der Datenbank-Engine verwenden.

Die Einrichtung und Synchronisierung erfordert etwas Aufwand, insbesondere bei einer großen Anzahl von Datenbanken. Sicherungen der Datenbank-Engine sind jedoch in der Regel sofort verfügbar und einfach zu verwenden. Dieser Ansatz eignet sich für Datenbanken jeder Größe und ist für große Instanzen in der Regel effektiver als andere Tools.

Für Sicherungen von Datenbankmodulen gelten die folgenden allgemeinen Einschränkungen:

  • Sicherungen können fehleranfällig sein, insbesondere wenn sie manuell durchgeführt werden.
  • Daten können ungeschützt sein, wenn die Snapshots nicht richtig verwaltet werden.
  • Für Sicherungen sind keine geeigneten Monitoringfunktionen verfügbar.
  • Sicherungen erfordern einen hohen Aufwand, um skaliert zu werden, wenn viele Datenbanken migriert werden.

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. Für die Dienstprogramme pg_dump und pg_dumapall gelten jedoch die folgenden allgemeinen Einschränkungen:

  • Für die Migration von Datenbanken mit einer Größe von bis zu 500 GB sollten die integrierten Sicherungstools verwendet werden. Das Exportieren und Importieren großer Datenbanken kann lange dauern und erfordert möglicherweise viel Speicherplatz und Arbeitsspeicher.
  • Das pg_dump-Tool enthält keine Nutzer und Rollen. Wenn Sie diese Nutzerkonten und Rollen migrieren möchten, können Sie das pg_dumpall-Tool verwenden.
  • 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 Dump-Jobs gleichzeitig auszuführen.
  • Verwenden Sie die Option -z mit dem Befehl pg_dump, um die zu verwendende Komprimierungsstufe anzugeben. Die zulässigen Werte für diese Option reichen von 0 bis 9. Standardmäßig wird auf Stufe 6 komprimiert. Höhere Werte verringern die Größe der Dumpdatei, können aber zu einem hohen Ressourcenverbrauch auf dem Clienthost führen. Wenn der Client-Host über genügend Ressourcen verfügt, kann die Größe der Dumpdatei durch höhere Komprimierungsstufen weiter verringert werden.
  • Beim Erstellen einer SQL-Dumpdatei die korrekten Flags verwenden
  • Importierte Datenbank prüfen Achten Sie bei der Ausgabe des pg_restore-Dienstprogramms auf Fehlermeldungen während des Wiederherstellungsvorgangs. Sehen Sie sich die PostgreSQL-Logs an, um nach Warnungen oder Fehlern während des Wiederherstellungsvorgangs zu suchen. Führen Sie einfache Abfragen und Tabellenzählungen aus, um die Integrität Ihrer Datenbank zu prüfen.

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

Andere Ansätze für die Migration geplanter Wartungsarbeiten

Die Verwendung anderer Ansätze als der integrierten Sicherungstools ermöglicht mehr Kontrolle und Flexibilität für Ihre geplante Wartungsmigration. Mit diesen anderen Ansätzen können Sie während der Migration Daten transformieren, prüfen oder andere Vorgänge 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 ist die Verwendung von Flatfiles zum Exportieren und Importieren Ihrer Daten. Weitere Informationen zum Importieren von Flatfiles finden Sie unter Mithilfe von CSV-Dateien exportieren und importieren.

Eine weitere Alternative ist die Verwendung eines verwalteten Imports zum Einrichten der Replikation aus einer externen PostgreSQL-Datenbank. Wenn Sie einen verwalteten Import verwenden, werden die Daten zuerst aus der externen Datenbank in die Cloud SQL for PostgreSQL-Instanz geladen. Für diesen anfänglichen Ladevorgang wird ein Dienst verwendet, der Daten vom externen Server (der 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 die einmalige Datenmigration Ihrer Daten 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. Wenn Sie das Datum Ihrer Quellinstanz exportieren möchten, können Sie die aws_s3-Erweiterung für PostgreSQL verwenden. Alternativ können Sie Amazon Database Migration Service und einen S3-Bucket als Ziel verwenden. Ausführliche 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 in diesem Format 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 gesamten 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 Befehlszeile mit dem Befehl psql 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:

  • Möchten Sie lieber verwaltete Migrationsdienste verwenden?

    • Wenn ja, können Sie sich einige Sekunden Ausfallzeit für Schreibvorgänge leisten, während der Replikationsschritt ausgeführt wird?

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

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

      • Falls ja, empfehlen wir die Verwendung der integrierten Replikation.
      • Falls nein, empfehlen wir Ihnen, andere Migrationsoptionen in Betracht zu ziehen.

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

Database Migration Service bietet einen speziellen Jobtyp für kontinuierliche Migrationen. Diese kontinuierlichen Migrationsjobs unterstützen Migrationen mit hoher Genauigkeit zu Cloud SQL for PostgreSQL und zu AlloyDB for PostgreSQL.

Wenn Sie Database Migration Service verwenden, um zu Cloud SQL for PostgreSQL oder AlloyDB for PostgreSQL zu migrieren, gelten für jede Zielinstanz bestimmte Voraussetzungen und Einschränkungen:

Integrierte Replikation des Datenbankmoduls

Die integrierte Replikation des Datenbankmoduls ist eine Alternative zu Database Migration Service für eine kontinuierliche Migration.

Bei der Datenbankreplikation werden Daten aus einer Datenbank, der primären Datenbank, in andere Datenbanken, die Replikate, kopiert und verteilt. Sie soll die Datenzugänglichkeit erhöhen und die Fehlertoleranz und Zuverlässigkeit eines Datenbanksystems verbessern. Obwohl die Datenbankmigration nicht der primäre Zweck der Datenbankreplikation ist, kann sie erfolgreich als Tool verwendet werden, um dieses Ziel zu erreichen. Die Datenbankreplikation ist in der Regel ein fortlaufender Prozess, der in Echtzeit erfolgt, wenn Daten in die primäre Datenbank eingefügt, aktualisiert oder gelöscht werden. Die Datenbankreplikation kann als einmaliger Vorgang oder als Abfolge von Batchvorgängen erfolgen.

Die meisten modernen Datenbank-Engines implementieren verschiedene Methoden zur Datenbankreplikation. Eine Art der Replikation kann erreicht werden, indem das Write-Ahead-Log oder das Transaktionslog des Primärservers in seine Replikate kopiert und gesendet wird. Dieser Ansatz wird als physische oder binäre Replikation bezeichnet. Bei anderen Replikationstypen werden die Roh-SQL-Anweisungen verteilt, die eine primäre Datenbank empfängt, anstatt Änderungen auf Dateisystemebene zu replizieren. Diese Replikationstypen werden als logische Replikation bezeichnet. Für PostgreSQL gibt es auch Drittanbietererweiterungen wie pglogical, die die logische Replikation auf Grundlage von Write-Ahead-Logging (WAL) implementieren.

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

Die folgenden Einschränkungen und Voraussetzungen gelten 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, 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-Bereich zugelassen wird, der dem Zugriff auf private Dienste des VPC-Netzwerk zugeordnet ist. Die Cloud SQL for PostgreSQL-Replikatdatenbank verwendet das VPC-Netzwerk als privates Netzwerk.

  • Die Firewall der Quelldatenbank muss so konfiguriert sein, dass sie den gesamten internen IP-Adressbereich zulässt, der für die private Dienstverbindung des VPC-Netzwerk zugewiesen wurde. Die Cloud SQL for PostgreSQL-Zielinstanz verwendet dieses VPC-Netzwerk im Feld privateNetwork ihrer Einstellung IpConfiguration.

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

  • Achten Sie darauf, dass der Parameter shared_preload_libraries die Erweiterung pglogical in Ihrer Quellinstanz enthält (z. B. shared_preload_libraries=pg_stat_statements,pglogical). Setzen Sie den Parameter rds.logical_replication auf 1. Mit dieser Einstellung werden Write-Ahead-Logs auf der logischen 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 und in der offiziellen Cloud SQL-Dokumentation unter Logische Replikation und Decodierung für PostgreSQL einrichten.

AlloyDB for PostgreSQL unterstützt die Replikation über die pglogical-Erweiterung. Wenn Sie die pglogical-Erweiterung für die Replikation aktivieren möchten, können Sie den Befehl CREATE EXTENSION verwenden. Bevor Sie diesen Befehl verwenden können, müssen Sie zuerst die Datenbank-Flags alloydb.enable_pglogical und alloydb.logical_decoding in der AlloyDB for PostgreSQL-Instanz, in der Sie die Erweiterung verwenden möchten, auf on setzen. Für das Festlegen dieser Flags 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-Quellinstanz 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 replizieren Sie Änderungen aus Ihrer PostgreSQL-Instanz entweder in BigQuery oder in Cloud Storage. Diese replizierten Daten können dann mit Dataflow über eine Dataflow Flex-Vorlage oder mit Dataproc in Ihre Cloud SQL for PostgreSQL- und AlloyDB for PostgreSQL-Instanz übertragen werden.

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

Drittanbietertools für die Migration mit kontinuierlicher Replikation

In einigen Fällen ist es besser, ein Drittanbieter-Tool für die meisten Datenbankmodule zu verwenden. Das kann beispielsweise der Fall sein, wenn Sie einen verwalteten Migrationsdienst bevorzugen und dafür sorgen müssen, dass die Zieldatenbank immer nahezu in Echtzeit mit der Quelle synchronisiert wird, oder wenn Sie komplexere Transformationen wie das Bereinigen, Umstrukturieren und Anpassen von Daten während der Migration 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:

    • Verarbeitet große Datenmengen und komplexe Migrationen.
    • Integrierte Change Data Capture-Funktion für SQL Server.
    • Vorkonfigurierte Verbindungsvorlagen und Pipelines ohne Code.
    • Kann geschäftskritische, große Datenbanken verarbeiten, die unter hoher Transaktionslast betrieben werden.
    • Genau einmalige Zustellung.

  • Nachteile:

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

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

  • Vorteile:

    • Open Source
    • Starker Community-Support
    • Kostengünstig
    • Detaillierte Steuerung von Zeilen, Tabellen oder Datenbanken.
    • Spezialisiert auf das Erfassen von Änderungen in Echtzeit aus Datenbanktransaktionslogs.

  • Nachteile:

    • Erfordert spezifische Kenntnisse von 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.
    • Die inkrementelle Batchreplikation wird nicht unterstützt.

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

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

  • Vorteile:

    • Vorkonfigurierte Verbindungsvorlagen und Pipelines ohne Code.
    • Überträgt alle Schemaänderungen von der Quelle in die Zieldatenbank.
    • 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 Arbeitsvorgänge 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 sorgen Sie dafür, dass sich die Datenbankmigration nicht auf Ihr bestehendes Service Level Agreement (SLA) und Ihren Plan zur Aufrechterhaltung des Geschäftsbetriebs auswirkt.

Ihre Dokumentation zur Migrationsplanung sollte folgende Dokumente enthalten:

  • Dokumentation zur technischen Ausführung (Technical Design Document, 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, immer einen Rollback-Plan zu haben. Befolgen Sie als Best Practice die Anleitung unter Zu Google Cloudmigrieren: Best Practices zur Validierung eines Migrationsplans.

TDD

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

  • Geschäftliche Anforderungen und Kritikalitä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 definiert wird, welche Personen oder Gruppen für Aufgaben und Ergebnisse 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.

Für jede Migrationsumgebung empfehlen wir, einen T-minus-Plan 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, sowie die verantwortlichen Gruppen und die geschätzte Dauer.

Der Zeitplan sollte nicht nur die Ausführung von Vorbereitungsaufgaben vor der Migration berücksichtigen, sondern auch Validierungs-, Prüfungs- oder Testaufgaben, 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 Vorbereitung des Zielsystems Entwurf der Zielumgebung, wie im Designdokument beschrieben Migrationsteam -14 Fertig
15.11.2023 Vor der Migration Unternehmensführung Migrationsdatum und Genehmigung für T-Minus Leitende Positionen -6 Fertig
18.11.2023 Migration DMS einrichten Verbindungsprofile erstellen Cloud-Migration Engineer -3 Fertig
19.11.2023 Migration DMS einrichten Migrationsjobs erstellen und starten Cloud-Migration Engineer -2 Nicht gestartet
19.11.2023 Migration DMS überwachen DMS-Jobs und DDL-Änderungen in der Quellinstanz überwachen Cloud-Migration Engineer -2 Nicht gestartet
21.11.2023 Migration Umstellung von DMS DMS-Replikat hochstufen Cloud-Migration Engineer 0 Nicht gestartet
21.11.2023 Migration Migrationsvalidierung 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 GO oder NO GO für die Migrationsvalidierung Migrationsteam 1 Nicht gestartet
23.11.2023 Nach der Migration Monitoring überprü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, den Prozess mit der Migration einer kleineren, idealerweise nicht geschäftskritischen Datenbank zu beginnen. So können Sie Ihr Wissen und Ihr Vertrauen in den Migrationsprozess und die Tools stärken. Außerdem können Sie in den frühen Phasen des gesamten Migrationszeitplans Fehler 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 erfolgen oder die migrierte Datenbank ist danach nicht nutzbar.

Vorbereitungsaufgaben können so kategorisiert 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-Instanz einrichten
  • Migrationsspezifische Einrichtung

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

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

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

  • 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, achten Sie darauf, dass auf Ihrer Amazon RDS-Instanz genügend freier Speicherplatz vorhanden ist, um die Write-Ahead-Logs für die Dauer des vollständigen Ladevorgangs 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 Drittanbietertools verwenden, sind in der Regel vorab Einstellungen und Konfigurationen erforderlich, bevor Sie das Tool verwenden können. Sehen Sie in der Dokumentation des Drittanbietertools nach.

Weitere Informationen zur Vorbereitung der Instanz 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öchten, konfigurieren Sie Ihre Quelldatenbank, bevor Sie eine Verbindung herstellen. Weitere Informationen finden Sie unter Quelle für PostgreSQL konfigurieren und Quelle für PostgreSQL zu AlloyDB for PostgreSQL konfigurieren.

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

  • Beachten Sie, dass große Objekte nicht vom Database Migration Service repliziert werden können, da die logische Decodierung in PostgreSQL keine Änderungen an großen Objekten unterstützt.

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

  • Bei einigen Migrationstools von Drittanbietern müssen alle Spalten für große Objekte NULL-fähig sein. Für alle Spalten mit großen Objekten, die NOT NULL sind, muss diese Einschränkung während der Migration entfernt werden.

  • Nehmen Sie Baseline-Messungen in Ihrer Quellumgebung im Produktionsbetrieb vor. Berücksichtige Folgendes:

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

Cloud SQL for PostgreSQL- und AlloyDB for PostgreSQL-Instanz einrichten

Damit die Zielinstanz eine ähnliche Leistung wie die Quellinstanz erzielt, müssen Sie die Größe und die Spezifikationen der Ziel-PostgreSQL-Datenbankinstanz an die der Quellinstanz anpassen. Achten Sie dabei besonders auf Laufwerkgröße und Durchsatz, Ein-/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 Probleme mit der Anwendungsleistung führen. Bei der Entscheidung für eine Cloud SQL for PostgreSQL- oder AlloyDB for PostgreSQL-Instanz sollten Sie berücksichtigen, dass die Festplattenleistung von der Festplattengröß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 Cloud SQL for PostgreSQL- und AlloyDB for PostgreSQL-Zielinstanzen sorgfältig aus. Instanzen können nicht ohne Datenübertragung zwischen Google Cloud Projekten und ‑Regionen migriert werden.

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

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

  • Prüfen Sie die datenbankmodulspezifischen 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 denen in der Cloud SQL- und AlloyDB for PostgreSQL-Instanz zu vergleichen. Aktualisieren Sie die Flageinstellungen nach Bedarf in 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 an und erfahren Sie, wie Sie sie in Cloud SQL und AlloyDB for PostgreSQL aktivieren.

Weitere Informationen zur Einrichtung von Cloud SQL for PostgreSQL finden Sie unter Optionen für die Instanzkonfiguration, 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 Ausfallzeiten 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 über die dokumentierten Verbindungsoptionen erfolgen.

Je nach Anwendungsfall und Kritikalität 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 zu Ihrer Amazon-Quellinstanz.

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

Wenn Sie zu AlloyDB for PostgreSQL migrieren, sollten Sie eine Cloud SQL for PostgreSQL-Instanz als potenzielles Ziel für Ihre Fallback-Szenarien in Betracht ziehen. Verwenden Sie die pglogical-Erweiterung, um die logische Replikation für diese Cloud SQL-Instanz einzurichten.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Ausführungsaufgaben definieren

Mit Ausführungsaufgaben wird die eigentliche Migrationsarbeit erledigt. Die Aufgaben hängen vom ausgewählten Migrationstool ab, wie in den folgenden Unterabschnitten 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 Tool finden Sie in den folgenden Ressourcen:

Database Migration Service-Migrationsjobs

Sie definieren und konfigurieren Migrationsjobs in Database Migration Service, um Daten aus einer Quellinstanz in die Zieldatenbank zu migrieren. Migrationsjobs stellen über nutzerdefinierte 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 Umstellung auf die Produktion tolerieren können.

In Database Migration Service beginnt die Migration mit dem ersten Schema-Dump und der Wiederherstellung ohne Indexe und Einschränkungen, gefolgt vom Datenkopiervorgang. Nachdem das Kopieren der Daten abgeschlossen ist, werden Indexe und Einschränkungen wiederhergestellt. Schließlich wird die kontinuierliche Replikation von Änderungen von der Quell- zur Zieldatenbankinstanz gestartet.

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

Der Migrationsprozess mit Database Migration Service endet mit dem Vorgang zum Hochstufen. Beim Hochstufen einer Datenbankinstanz wird die Zieldatenbank vom Fluss der Änderungen getrennt, die aus der Quelldatenbank stammen. Die nun eigenständige Zielinstanz wird dann zur primären Instanz hochgestuft. Dieser Ansatz wird auch als Produktionsumstellung bezeichnet.

Eine detaillierte Anleitung zur Einrichtung der Migration 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 Erweiterung pglogical für die Replikation. Jeder Typ der logischen Replikation hat seine eigenen Funktionen und Einschränkungen.

Die integrierte logische Replikation hat die folgenden Funktionen und Einschränkungen:

  • Sie ist in PostgreSQL 10 und höher verfügbar.
  • Alle Änderungen und Spalten werden repliziert. Publikationen werden auf Tabellenebene definiert.
  • Daten werden nur von Basistabellen in Basistabellen repliziert.
  • Es wird keine Sequenzreplikation durchgeführt.
  • Dies ist der empfohlene Replikationstyp, wenn es viele Tabellen ohne Primärschlüssel gibt. Integrierte logische PostgreSQL-Replikation einrichten 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 logische Replikation von pglogical hat die folgenden Funktionen und Einschränkungen:

  • Sie ist in allen PostgreSQL-Versionen verfügbar und bietet versionsübergreifende Unterstützung.
  • Das Filtern von Zeilen ist in der Quelle verfügbar.
  • Die Tabellen UNLOGGED und TEMPORARY werden nicht repliziert.
  • Für Tabellen ist ein Primärschlüssel oder eindeutiger Schlüssel erforderlich, um UPDATE- und DELETE-Änderungen zu erfassen.
  • Die Sequenzreplikation ist verfügbar.
  • Die Replikation kann verzögert erfolgen.
  • 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, die Daten verarbeiten und dann an andere Anwendungen oder Ziele weiterleiten.

Sie verwenden einen oder mehrere Flows, um diese Migrationsprozesse in Ihren benutzerdefinierten Anwendungen zu organisieren. Für die Programmierung 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 Striim zum Migrieren Ihrer Daten verwenden möchten, finden Sie in den folgenden Anleitungen Informationen dazu, wie Sie Daten mit Striim in Google Cloudmigrieren:

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.

Die Fallback-Lösung kann einen 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 für alle Migrationsausführungsaufgaben einen Zeitrahmen fest. Bei einem Migrationsprobelauf werden Informationen zu den erwarteten Zeiten für die einzelnen Aufgaben erfasst. Bei einer geplanten Wartungsmigration können Sie sich zum Beispiel die Ausfallzeit leisten, die durch das Umstellungsfenster dargestellt wird. Es ist jedoch wichtig, dass Sie Ihren nächsten Schritt planen, falls der einmalige Migrationsjob oder die Wiederherstellung der Sicherung mittendrin fehlschlägt. Je nachdem, wie viel Zeit Ihrer geplanten Ausfallzeit bereits verstrichen ist, müssen Sie die Migration möglicherweise verschieben, wenn die Migrationsaufgabe nicht innerhalb der erwarteten Zeit abgeschlossen wird.

Ein Fallback-Plan bezieht sich in der Regel auf das Zurücksetzen der Migration nach der Produktionsumstellung, wenn Probleme auf der Zielinstanz auftreten. Wenn Sie einen Fallbackplan 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. Ohne Fallback-Plan kann es zu unvorhergesehenem Aufwand und vermeidbaren Unterbrechungen bei der Migration kommen.

Auch wenn ein Fallback das letzte Mittel ist und bei den meisten Datenbankmigrationen nicht zum Einsatz kommt, 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. Wählen Sie diese Strategie, wenn Sie sich Ausfallzeiten leisten können, wenn Sie ein Rollback durchführen, oder wenn die Transaktionen nicht im neuen Zielsystem festgeschrieben werden müssen.

Wenn Sie alle geschriebenen Daten in Ihrer Zieldatenbank benötigen und sich eine Ausfallzeit leisten können, können Sie in Erwägung ziehen, Schreibvorgänge für Ihre Zieldatenbankinstanz zu beenden, integrierte Sicherungen zu erstellen und sie in Ihrer Quellinstanz wiederherzustellen und dann Ihre Anwendungen wieder mit der ursprünglichen Quelldatenbankinstanz zu 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 replizieren Sie die Schreibvorgänge, die nach der Produktionsumstellung in Ihrer neuen Zieldatenbank erfolgen, zurück in Ihre ursprüngliche Quelldatenbank. 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, wenn Sie Ihre Quellinstanz noch einige Zeit behalten können und die Migration über die kontinuierliche Replikation erfolgt.

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 schreibgeschützte Abfragen 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 komplizierter, da Sie Anwendungen refaktorieren 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 soll Folgendes getestet und validiert werden:

  • 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. Dies gilt insbesondere für Daten, die für Analysearbeitslasten verwendet werden, bei denen der Verlust eines Teils der Daten keine Auswirkungen auf allgemeine Trends oder die Leistung Ihrer Arbeitslasten hat.
  • 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äftsvorgänge können in der Zielumgebung langsamer sein, die Verarbeitungszeit liegt aber weiterhin innerhalb der definierten Erwartungen.

Die Speicherkonfigurationen in Ihrer Quellumgebung lassen sich möglicherweise nicht direkt zuGoogle Cloud -Umgebungszielen zuordnen. Dazu gehören beispielsweise Konfigurationen von SSD-Volumes für allgemeine Zwecke (gp2 und gp3) mit IOPS-Burstleistung 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. In dieser Zeit erfassen und verarbeiten Sie Messwerte, um die relative Leistung von Quell- und Zielsystem zu messen und zu vergleichen.

Verwenden Sie für herkömmliche, serverbasierte Konfigurationen die entsprechenden Messungen, die während Spitzenlasten beobachtet wurden. Bei flexiblen Ressourcenkapazitätsmodellen wie Aurora Serverless sollten Sie sich historische Messwertdaten ansehen, um Ihren Skalierungsbedarf zu ermitteln.

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

  • HammerDB: Ein Open-Source-Tool für Datenbank-Benchmarks 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 bietet eine detaillierte Dokumentation und eine große Community von Nutzern. Sie können Ergebnisse für verschiedene 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.

Wenn Sie einen End-to-End-Test durchführen möchten, einschließlich des Migrationsplans, sollten Sie immer einen Migrationsprobelauf durchführen. Durch einen Probelauf wird die Datenbankmigration in vollem Umfang durchgeführt, ohne dass die Produktionsarbeitslasten gewechselt werden:

  • So können Sie sicherstellen, dass alle Objekte und Konfigurationen richtig migriert werden.
  • Unterstützt Sie beim Definieren und Ausführen Ihrer Migrations-Testläufe.
  • Sie erhalten einen Einblick in die Zeit, die für die eigentliche Migration benötigt wird. Damit können Sie Ihre Zeitachse kalibrieren.
  • Dies ist eine gute Gelegenheit, 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 für die Migration verwendeten Tools 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. Prüfen Sie die Anzahl der Zeilen und vergleichen Sie Daten auf Datenbankebene.
  • Führen Sie Benutzerdefinierte Datenvalidierungsskripts aus.
  • Prüfen Sie, ob die migrierten Daten auch in den Anwendungen sichtbar sind, die auf die 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. Bei diesen Tests werden sowohl Daten in die Zieldatenbanken gelesen als auch geschrieben, damit die Arbeitslasten migrierte und neu erstellte 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 automatisierter Testläufe wird angepasst, um für die umgestellten Anwendungen ausgeführt zu werden.

Wenn Sie den Database Migration Service als Migrationstool verwenden, lesen Sie die Version des Themas „Migration überprüfen“ für PostgreSQL oder PostgreSQL zu AlloyDB for PostgreSQL.

Datenvalidierungstool

Für die Datenvalidierung empfehlen wir die Verwendung des Datenvalidierungstools (DVT). Das DVT ist ein von Google unterstütztes Python-Befehlszeilentool im Open-Source-Format, das 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 Functions und Cloud Run für eine ereignisbasierte Auslösung und Orchestrierung eingebunden werden.

Das DVT unterstützt die folgenden Arten von Validierungen:

  • Vergleiche auf Schemaebene
  • Spalte (einschließlich „AVG“, „COUNT“, „SUM“, „MIN“, „MAX“, „GROUP BY“ und „STRING_AGG“)
  • Zeile (einschließlich Hash und genauer Übereinstimmung bei Feldvergleichen)
  • Vergleich benutzerdefinierter Abfrageergebnisse

Weitere Informationen zum DVT finden Sie im Git-Repository und unter Data Validation Tool von Google Cloud.

Migration ausführen

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

Beachten Sie die folgenden Best Practices für die Datenmigration:

  • Informieren Sie die beteiligten Teams, wenn ein Planschritt beginnt und endet.
  • Wenn einer der Schritte länger als erwartet dauert, vergleichen Sie die verstrichene Zeit mit der maximal für diesen Schritt vorgesehenen Zeit. Stellen Sie den beteiligten Teams regelmäßig Zwischenupdates zur Verfügung, wenn dies geschieht.
  • Wenn der Zeitraum länger ist als die maximale Zeit, die für jeden Schritt im Plan reserviert ist, sollten Sie ein Rollback in Betracht ziehen.
  • 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äß Ihrer definierten Ausführungsaufgaben aus und erfahren Sie mehr in der Dokumentation des ausgewählten Migrationstools.

Produktionsumstellung ausführen

Der allgemeine Prozess für die Umstellung auf die Produktion kann je nach gewählter Migrationsstrategie variieren. Wenn für Ihre Arbeitslasten Ausfallzeiten möglich sind, beginnt die Umstellung der Migration damit, dass Schreibvorgänge in Ihre Quelldatenbank beendet werden.

Bei Migrationen mit fortlaufender Replikation führen Sie im Allgemeinen die folgenden Schritte auf hoher Ebene im Umstellungsprozess aus:

  • Schreiben Sie nicht mehr in die Quelldatenbank.
  • Entleeren 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 die Daten 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 Ausfallzeiten bei einigen Anwendungen kommen.

Beachten Sie die Best Practices für die Umstellung auf die Produktion:

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

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

In einem Fallbackszenario möchten Sie möglicherweise die Replikation Ihrer Schreibvorgänge in der Cloud SQL-Instanz zurück in Ihre ursprüngliche Quelldatenbank implementieren. Die Einrichtung ähnelt dem Migrationsprozess, wird aber umgekehrt 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 minimalem Datenverlust 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 das Migrationsziel ist, sollten Sie die Replikation zu einer Cloud SQL for PostgreSQL-Instanz für Fallbackszenarien einrichten.

Zusätzlich zur 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 Zu Google Cloudmigrieren: Umgebung optimieren und Google Cloud Well-Architected Framework: Leistungsoptimierung.

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 eignen:

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

Geringfügige datenbankbezogene Leistungsprobleme können sich häufig auf den gesamten Betrieb auswirken. Beachten Sie die folgenden Richtlinien, um die Leistung Ihrer Cloud SQL-Instanz aufrechtzuerhalten 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 Query Insights-Dashboard in Cloud Monitoring oder ä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 Lesebefehls 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:

  • Caching verwenden, um die Leseleistung zu verbessern. Sehen Sie sich die verschiedenen Statistiken in der Ansicht pg_stat_database an. Das Verhältnis blks_hit / (blks_hit + blks_read) sollte beispielsweise über 99 % liegen. Wenn dieses Verhältnis nicht größer als 99 % ist, sollten Sie den Arbeitsspeicher Ihrer Instanz unter Umständen vergrößern. Weitere Informationen finden Sie unter PostgreSQL-Statistikerfassung.
  • Speicherplatz freigeben und eine schlechte Indexleistung verhindern Je nachdem, wie oft sich Ihre Daten ändern, können Sie einen Zeitplan für die Ausführung des VACUUM-Befehls in Cloud SQL for PostgreSQL festlegen.
  • Verwenden Sie Cloud SQL Enterprise Plus, um die Grenzwerte für die Maschinenkonfiguration zu erhöhen und den Datencache zu nutzen. 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, können Sie die volle PostgreSQL-Kompatibilität, eine bessere Transaktionsverarbeitung und schnelle transaktionale Analysearbeitslasten in Ihrer Verarbeitungsdatenbank nutzen. Außerdem erhalten Sie über den Indexberater Empfehlungen für neue Indexe.

Weitere Informationen zur Leistungssteigerung 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, sollten Sie die folgenden Richtlinien beachten, 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. Aus diesem Grund ist ein zentraler Ort, an dem alle Teammitglieder sehen können, was auf Datenbank- und Instanzebene passiert, unerlässlich. 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 von Ihnen verwendeten Google Cloud-Ressourcen zu erfassen. 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 Google Cloudintegriert 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 Dokumentationsabschnitten:

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.

Einige wichtige allgemeine Empfehlungen für Cloud SQL sind:

  • 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 den Zeitaufwand für das Datenbankupgrade auswirken. Idealerweise sollten weniger als 10.000 Tabellen pro Instanz vorhanden sein.
  • Wählen Sie die passende Größe für Ihre Instanzen aus, um die Aufbewahrung von (binären) Transaktionslogs zu berücksichtigen, insbesondere bei Instanzen mit hoher Schreibaktivität.

Damit Sie alle Datenbankleistungsprobleme, die auftreten können, effizient beheben können, sollten Sie die folgenden Richtlinien befolgen, 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 für die betroffenen Objekte (Tabellen, Indexe). Prüfen Sie, ob es eine Änderung gegenüber den normalen Datenbankaktivitäten gab. Das kann beispielsweise der Fall sein, wenn Sie kürzlich eine neue Spalte hinzugefügt haben oder viele Aktualisierungen an einer Tabelle vorgenommen wurden.

Datenbank optimieren: Sind die Tabellen in Ihrer Datenbank richtig strukturiert? Haben die Spalten die richtigen Datentypen? Ist Ihr Datenmodell für den Arbeitslasttyp geeignet? Untersuchen Sie Ihre langsamen Abfragen und ihre Ausführungspläne. Werden die verfügbaren Indexe verwendet? Prüfen Sie, ob Indexscans, Sperren und Wartevorgänge für andere Ressourcen vorhanden sind. Fügen Sie Indexe hinzu, um Ihre wichtigen Abfragen zu unterstützen. Entfernen Sie nicht kritische Indexe und Fremdschlüssel. Erwägen Sie, komplexe Abfragen und Joins neu zu schreiben. Die Zeit, die für die Behebung des Problems benötigt wird, hängt von der Erfahrung und Verfügbarkeit Ihres Teams ab und kann zwischen Stunden und Tagen liegen.

Lesevorgänge horizontal skalieren: Erwägen Sie die Verwendung von Lesereplikaten. Wenn die vertikale Skalierung nicht ausreicht und Maßnahmen zur Optimierung der Datenbank 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.

Datenbank neu strukturieren: Erwägen Sie, die Datenbank zu partitionieren und zu 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 teilweise durch vertikale Skalierung kompensiert werden können. Ein richtiges Datenmodell ist jedoch eine langfristige Lösung. Partitionieren Sie Ihre Tabellen. Archivieren Sie nicht benötigte Daten, wenn möglich. Normalisieren Sie Ihre Datenbankstruktur. Denken Sie aber daran, dass eine Denormalisierung die Leistung verbessern kann.

Datenbank-Sharding: Sie können Ihre Schreibvorgänge skalieren, indem Sie Ihre Datenbank aufteilen. Die Fragmentierung ist ein komplizierter Vorgang, der eine Neugestaltung Ihrer Datenbank und Anwendungen auf bestimmte Weise sowie eine Datenmigration erfordert. Sie teilen Ihre Datenbankinstanz anhand bestimmter Partitionierungskriterien in mehrere kleinere Instanzen auf. Die Kriterien können auf Kunden oder Themen basieren. 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 unausgewogenen Shards kommen, die als Hotspots bezeichnet werden und den Vorteil des Shardings zunichte machen.

Für Cloud SQL for PostgreSQL und AlloyDB for PostgreSQL gelten 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 Replikate, da dies den VACUUM-Vorgang behindert. Weitere Informationen zur Verwendung von HAProxy finden Sie auf der offiziellen HAProxy.
  • Optimieren Sie den VACUUM-Vorgang, indem Sie den Systemspeicher und den Parameter maintenance_work_mem erhöhen. Wenn Sie den Systemspeicher erhöhen, können in jedem Durchlauf mehr Tupel in einem Batch verarbeitet werden.
  • Da größere Indexe viel Zeit für den Indexscan verbrauchen, setzen Sie den Parameter INDEX_CLEANUP auf OFF, um die Tabellendaten schnell zu bereinigen und zu fixieren.
  • Wenn Sie AlloyDB for PostgreSQL verwenden, nutzen Sie das AlloyDB for PostgreSQL-Systemstatistik-Dashboard und Audit-Logs. Im AlloyDB for PostgreSQL-Systemstatistik-Dashboard werden Messwerte für die von Ihnen verwendeten Ressourcen angezeigt. Sie können diese Messwerte auch überwachen. Weitere Informationen finden Sie in der AlloyDB for PostgreSQL-Dokumentation im Thema Instanzen überwachen.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Nächste Schritte

Beitragende

Autoren:

Weiterer Mitwirkender: Somdyuti Paul | Data Management Specialist