Von AWS zu Google Cloud migrieren: Von Amazon RDS for SQL Server zu Cloud SQL for SQL Server migrieren

Last reviewed 2024-06-28 UTC

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

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

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

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

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

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

Diese Grafik veranschaulicht den Migrationsprozess:

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

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

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

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

Quellumgebung bewerten

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

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

Die Bewertungsphase umfasst die folgenden Aufgaben:

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

Weitere Informationen zur Bewertungsphase und zu diesen Aufgaben finden Sie unter Zu Google Cloud migrieren: Arbeitslasten bewerten und erkennen. Die folgenden Abschnitte basieren auf Informationen in jenem Dokument.

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

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

Inventar Ihrer Amazon RDS-Instanzen erstellen

Um den Umfang der Migration zu definieren, erstellen Sie ein Inventar und erfassen Informationen zu Ihren Amazon RDS-Instanzen. Idealerweise sollte der Prozess automatisiert werden, da manuelle Ansätze fehleranfällig sind und zu falschen Annahmen führen können.

Amazon RDS und Cloud SQL haben möglicherweise keine ähnlichen Funktionen, Spezifikationen oder Abläufe. Einige Funktionen sind möglicherweise anders implementiert oder nicht verfügbar. Unterschiede können sich beispielsweise in Bezug auf Infrastruktur, Speicher, Authentifizierung und Sicherheit, Replikation, Sicherung, Hochverfügbarkeit, Ressourcenkapazitätsmodell sowie Integrationen und Erweiterungen bestimmter Datenbankmodulfunktionen ergeben. 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 zu migrierenden Arbeitslasten und hilft Ihnen, die richtige Architektur der Zielumgebung. Es ist wichtig, Informationen zur Leistung zu erfassen, um die Leistungsanforderungen der Google Cloud-Zielumgebung zu schätzen. Benchmarking-Konzepte und -Tools werden in der Test- und Validierungsphase des Migrationsprozesses durchgeführt, aber sie gelten auch für die Inventarerstellungsphase.

Tools für Bewertungen

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

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

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

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

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

Die migVisor-Datenbankbewertung enthält Folgendes:

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

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

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

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

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

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

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

Migrationsumfang und vertretbare Ausfallzeiten ermitteln und dokumentieren

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

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

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

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

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

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

Bereitstellungs- und Verwaltungsprozess bewerten

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

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

• Definieren und erzwingen Sie Sicherheitsrichtlinien für Ihre Instanzen: Sie müssen zum Beispiel Amazon Security Groups ersetzen. Sie können Google IAM-Rollen, VPC-Firewallregeln und VPC Service Controls verwenden, um den Zugriff auf Ihre Cloud SQL-Instanzen zu steuern und die Daten innerhalb einer VPC einzuschränken. Wenn Sie die Windows-Authentifizierung mit Cloud SQL for SQL Server verwenden wollen, müssen Sie einVerwaltetes Microsoft AD bereitstellen und eine Verbindung zu Ihrer vorhandenen Active Directory-Infrastruktur herstellen.
• Instanzen patchen und konfigurieren: Ihre vorhandenen Bereitstellungstools müssen möglicherweise aktualisiert werden. Vielleicht verwenden Sie benutzerdefinierte Konfigurationseinstellungen in Amazon-Parametergruppen oder Amazon-Optionsgruppen. Ihre Bereitstellungstools müssen möglicherweise angepasst werden, damit Sie Google Cloud Storage oder Secret Manager zum Lesen solcher benutzerdefinierten Konfigurationslisten verwenden können.
• Monitoring- und Benachrichtigungsinfrastruktur verwalten: Messwertkategorien für Ihre Amazon-Quelldatenbankinstanzen sorgen für Beobachtbarkeit während des Migrationsprozess. Zu den Messwertkategorien gehören unter anderem Amazon CloudWatch, Leistungsstatistiken, erweiterte Überwachung und Listen mit Betriebssystemprozessen.

Bewertung abschließen

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

Grundlage planen und aufbauen

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

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

Die Planungs- und Erstellungsphase besteht aus den folgenden Aufgaben:

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

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

Monitoring und Benachrichtigungen

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

Amazon RDS for SQL Server-Instanzen zu Cloud SQL for SQL Server migrieren

So migrieren Sie Ihre Instanzen:

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

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

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

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

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

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

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

8. Führen Sie die Migration aus.

9. Führen Sie die Produktionsumstellung durch.

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

11. Optimieren Sie die Kampagne.

Die einzelnen Phasen werden in folgenden Abschnitten beschrieben.

Migrationsstrategie auswählen

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

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

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

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

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

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

Das obige Flussdiagramm zeigt die folgenden Entscheidungspunkte:

• Können Sie sich Ausfallzeiten leisten?

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

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

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

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

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

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

Ausfallzeiten und Auswirkungen auf die Migration minimieren

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

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

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

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

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

Auswahl der Tools für die Migration

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

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

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

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

Verwaltete Migrationsdienste bieten folgende Vorteile:

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

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

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

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

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

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

Tools für geplante Wartungsmigrationen

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

Integrierte Sicherungen des Datenbankmoduls

Wenn eine erhebliche Ausfallzeit akzeptabel ist und Ihre Quelldatenbanken relativ statisch sind, können Sie die integrierten Sicherungs- und Wiederherstellungsfunktionen der Datenbank-Engine verwenden.

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

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

• Sicherungen können fehleranfällig sein, insbesondere wenn sie manuell ausgeführt werden.
• Daten sind nicht gesichert, wenn die Sicherungen nicht ordnungsgemäß verwaltet werden.
• Für Back-ups gibt es keine geeigneten Überwachungsmöglichkeiten.

Beachten Sie bei dieser Vorgehensweise die folgenden Einschränkungen und Best Practices:

• Verwenden Sie für Sicherungen von Datenbanken, die größer als 5 TB sind, eine Stripe-Sicherung (eine Sicherung mehrerer Dateien).
• Bei einer stripebasierten Sicherung können Sie nicht gleichzeitig mehr als 10 Sicherungsdateien sichern oder daraus wiederherstellen.
• Sie müssen die Sicherung in einem Amazon S3-Bucket in derselben Amazon-Region wie Ihre Quelldatenbankinstanz vornehmen.
• Sicherungen enthalten keine SQL Server-Anmeldungen, ‐Berechtigungen und Serverrollen, da sie sich auf Instanzebene befinden. Um diesen Datentyp von der Quellinstanz zur Zielinstanz zu übertragen, verwenden Sie PowerShell-Skripte oder Tools wie DBAtools.

Weitere Informationen zu Einschränkungen und Best Practices finden Sie unter Best Practices für das Importieren und Exportieren von Daten mit Cloud SQL für SQL Server und Bekannte Probleme bei Cloud SQL for SQL Server.

Andere Ansätze für geplante Wartungsmigrationen

Die Verwendung anderer Ansätze ermöglicht mehr Kontrolle und Flexibilität für Ihren geplanten Wartungsmigrationsprozess.

Zum Beispiel durch Verwendung von Flatfiles zum Exportieren und Importieren Ihrer Daten (oder durch Verwendung benutzerdefinierter Skripts) haben Sie folgende Möglichkeiten:

• Während der Migration Daten transformieren, prüfen oder andere Vorgänge ausführen. Dazu gehören beispielsweise Validierungen, Aggregationen oder Normalisierungen und Denormalisierungen Ihrer Quelldaten.
• Auswählen, welche Strukturen migriert werden sollen und welche nicht. Vielleicht möchten Sie auch nur einen Teil Ihrer Tabellen in Flatfiles für den Import extrahieren.
• Daten nach Domain, Quelle, Alter oder anderen benutzerdefinierten Kriterien filtern. Sie können beispielsweise Daten ausschließen, die ein bestimmtes Alter erreicht haben, und sie vor der Migration in Dateien oder in der endgültigen Sicherung Ihrer Quelldatenbank speichern.
• Ihre Datenbankstrukturen refaktorieren und die anfallende Ausfallzeit mit der Migrationsausfallzeit synchronisieren.
• Mehrere Instanzen oder Datenbanken in einer einzigen Instanz oder Datenbank konsolidieren, um die Betriebskosten zu minimieren und Skalierbarkeitsprobleme zu verringern. Beispielsweise möchten Sie möglicherweise von einer Instanz, Datenbank oder einem Schema pro Kunde zu einer einzelnen, für die Mehrfachnutzung optimierten Datenbankstruktur wechseln.

Weitere Ansätze:

• CSV- oder JSON-Dateien verwenden: Bei diesem Ansatz extrahieren Sie die Daten der Datenbank in die Dateien und importieren die Dateien anschließend in Ihre Zielinstanzen.

  • Diese Methode ist in der Regel langsamer, hilft Ihnen aber, eine Teilmenge von Tabellen (oder Daten in einer bestimmten Tabelle) zu migrieren.
  • Die CSV- und JSON-Formate werden von vielen Tools unterstützt.
  • Wenn Sie den Prozess automatisieren, haben Sie die Möglichkeit, zu einer Batch-Migration mit kontinuierlicher Replikation überzugehen.

• Verwenden Sie den SQL Server Import- und Export-Assistent von Microsoft: Dieses Tool verwendet die SQL Server-Integration Services (SSIS) und ermöglicht den Import von Daten aus verschiedenen Quellen, wie z. B. aus Datenbankmodulen oder Flatfiles.

• Mit dem SQL Server-Assistenten zum Generieren und Veröffentlichen von Scripts und dem bcp-Dienstprogramm: Dieses Tool ist Teil von Microsoft SQL Server Management Studio.

  • Mit diesem Ansatz können Sie Scripts für das gesamte Datenbankschema oder nur für Teile davon erstellen.
  • Mit dem bcp-Dienstprogramm können Sie die Daten in ein Script schreiben und in Dateien exportieren.

• Verwenden Sie die Snapshot-Replikation, wenn Ihre Quelle Amazon RDS Standard verwendet:

  • Bei diesem Ansatz stellen Sie die SQL Server-Sicherung der RDS-Instanz zu einer anderen eigenständigen Instanz von SQL Server in Compute Engine wieder her. Migrieren Sie dann mithilfe der Snapshot-Replikation zu Cloud SQL for SQL Server.
  • Bei der Snapshot-Generierung werden Sperren für Quelltabellen beibehalten, was sich möglicherweise auf Ihre Arbeitslasten auswirkt.
  • Die Snapshot-Replikation kann zusätzliche Lasten auf Ihrem Amazon RDS-Server einführen.
  • Sie können jedoch auswählen, welche Objekte migriert oder repliziert werden, was Flexibilität bietet.
  • Details finden Sie unter Daten mithilfe von Snapshot-Replikation von SQL Server 2017 zu Cloud SQL for SQL Server migrieren.

Tools für Migrationen mit kontinuierlichen Replikationen

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

Das obige Flussdiagramm zeigt die folgenden Entscheidungspunkte:

• Verwenden Sie lieber verwaltete Migrationsdienste?

  • Falls ja, fahren Sie mit der nächsten Entscheidung fort. Wenn Sie sich minimale Ausfallzeiten erlauben können und keine Datentransformation oder Synchronisation in Echtzeit benötigen, empfehlen wir Database Migration Service. Andernfalls sollten Sie die Optionen von Drittanbietern prüfen.
  • Falls nicht, fahren Sie mit der nächsten Entscheidung fort. Wenn die integrierte Replikation des Datenbankmoduls unterstützt wird, empfehlen wir die Verwendung der integrierten Replikation. Andernfalls empfehlen wir, andere Migrationsoptionen zu prüfen.

• Können Sie sich minimale Ausfallzeiten leisten und ohne Datentransformation oder Echtzeitsynchronisierung migrieren?

  • Falls ja, empfehlen wir den Database Migration Service.
  • Falls nicht, sollten Sie die Optionen von Drittanbietern prüfen.

• Wird die integrierte Replikation des Datenbankmoduls unterstützt?

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

In den folgenden Abschnitten werden die Tools beschrieben, die für kontinuierliche Replikationsmigrationen 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 unterstützt homogene Migrationen zu Cloud SQL for SQL Server, wenn Amazon RDS die Quelle ist.

Der Database Migration Service ist ein kostengünstiges und unkompliziertes Tool. Wir empfehlen den Database Migration Service in den folgenden Fällen:

• Sie können sich nur minimale Ausfallzeiten leisten.
• Sie benötigen keine Echtzeitsynchronisierung.
• Während der Migration müssen keine Datentransformationen durchgeführt werden.

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

• Die Ausfallzeit hängt von der Häufigkeit des Sicherung der Transaktionslogs ab:
• Sicherungen enthalten keine SQL Server-Anmeldungen, -Berechtigungen oder -Serverrollen, da sie auf Instanzebene erfolgen. Schreiben Sie sie aus der Quellinstanz und übertragen sie dann mithilfe von PowerShell-Scripts oder -Tools wie DBAtools.

Eine vollständige Liste der Beschränkungen finden Sie unter bekannte Einschränkungen.

Integrierte Replikation des Datenbankmoduls

Cloud SQL unterstützt die Replikation für SQL Server. Standard-Amazon RDS für SQL Server kann jedoch nur Abonnent sein. Integrierte Replikation von Amazon RDS Standard ist nicht verfügbar. Nur Amazon RDS Custom for SQL Server kann als integrierter Publisher eingerichtet werden.

Eine Liste der unterstützten und nicht unterstützten Funktionen in Amazon RDS finden Sie unter Amazon RDS für Microsoft SQL Server

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

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

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

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

• Funktionen implementieren, die in regelmäßigen Abständen Daten in Ihrer Quellinstanz abfragen, nur neue Daten herausfiltern und Daten in CSV-, JSON- oder Parquet-Dateien schreiben.

  • Diese Dateien werden in einem Google Cloud Storage-Bucket gespeichert.
  • Die Dateien können mithilfe von Cloud Run-Funktionen sofort in Ihre Zieldatenbankinstanz geschrieben werden.
  • Change Data Capture (CDC)-Funktionen können Replikationsmigration nahezu in Echtzeit durchführen.
  • Sie können CDC in einen Amazon S3-Data Lake im Parquet-Format streamen. Verwenden Sie dazu AWS Database Migration Service (AWS DMS).
  • Sie können eine benutzerdefinierte Implementierung verwenden, um die Dateien zu lesen und ihren Inhalt in Cloud SQL zu schreiben.

Drittanbietertools für Migrationen mit kontinuierlicher Replikation

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

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

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

• Vorteile:

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

• Nachteile:

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

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

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

• Vorteile:

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

• Nachteile:

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

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

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

• Vorteile:

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

• Nachteile:

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

Migrationsplan und Zeitplan definieren

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

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

Ihre Dokumentation zur Migrationsplanung sollte folgende Dokumente enthalten:

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

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

TDD

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

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

RACI-Matrix

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

Zeitplan

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

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

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

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

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

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

Mehrere Datenbankmigrationen

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

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

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

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

Vorbereitungsaufgaben definieren

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

Vorbereitungsaufgaben können in folgende Kategorien unterteilt werden:

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

Amazon RDS-Instanz – Vorbereitung und Voraussetzungen

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

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

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

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

• Für die fortlaufende Replikation (Streamingänderungen über CDC) müssen Sie eine vollständige RDS-Instanz und kein Lesereplikat mit aktiviertem CDC verwenden. Weitere Informationen siehe Change Data Capture mit SQL Server verwenden

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

Vorbereitung der Quelldatenbank und Voraussetzungen

• Achten Sie darauf, dass während der Migrationsvorgänge in der Quelldatenbank Bufferspeicher und Arbeitsspeicher verfügbar sind. Wenn Sie zum Beispiel Sicherungsdateien für Transaktionslogs verwenden, überwachen Sie die Speichernutzung und stellen Sie sicher, dass Sie über zusätzlichen Pufferspeicherplatz verfügen.
• Dokumentieren Sie die Einstellungen Ihrer Datenbankparameter und wenden Sie sie auf Ihre Zielinstanz an, bevor Sie Migrationstests und ‑validierungen durchführen.

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

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

Cloud SQL-Einrichtung

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

Prüfen Sie, ob das Ziel richtig ist. Die Konfigurationsoptionen von Amazon RDS können sich von denen von Cloud SQL unterscheiden. Falls Cloud SQL Ihre Anforderungen nicht erfüllt, sollten Sie Optionen erwägen. die Datenbanken in Compute Engine enthalten.

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

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

• Migrieren Sie zu einer übereinstimmenden Hauptversion in Cloud SQL. Wenn in Ihrer Quelle beispielsweise SQL Server 15.0 verwendet wird, migrieren Sie zu Cloud SQL for SQL Server 15.0. Wenn die Versionen unterschiedlich sind, sollte die Einstellung für die Kompatibilitätsebene gleich sein, damit dieselben Engine-Funktionen verfügbar sind.

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

• Prüfen Sie die Datenbank-Engine-spezifischen Konfigurationsflags und vergleichen Sie die Werte der Quell- und Zielinstanz. Stellen Sie sicher, dass Sie deren Auswirkungen verstehen und ob sie gleich sein müssen oder nicht. Vergleichen Sie z. B. die Werte in der Ansicht „sys.configurations“ in der Quelldatenbank mit den Werten in der Cloud SQL-Instanz. Beachten Sie, dass nicht alle Flags gleich sein müssen und nicht alle Flagänderungen sind auf einer Cloud SQL-Instanz zulässig.

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

• Allgemeine Best Practices für SQL Server
• Instanzkonfigurationsoptionen für SQL Server
• Datenbankmodulspezifische Flags für SQL Server

Migrationsspezifische Einrichtung

Wenn Sie für die Migration den Dateiexport und ‑import oder das Migrationstool des Database Migration Service verwenden, müssen Sie einen Cloud Storage-Bucket erstellen. Im Bucket werden die Datenbank- und Transaktionslog-Sicherungsdateien gespeichert. Weitere Informationen zur Verwendung von Database Migration Service, siehe Sicherungsdateien in einem Cloud Storage-Bucket speichern

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

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

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

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

Ausführungsaufgaben definieren

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

Integrierte Sicherungen des Datenbankmoduls

Weitere Informationen und Anleitungen für datenbankspezifische Sicherungen finden Sie unter Importieren von Daten aus einer BAK-Datei in Cloud SQL für SQL Server und Exportieren von Daten aus RDS für SQL Server. Weitere Informationen zum Automatisieren von Uploads von Transaktionslogdateien finden Sie unter Uploads von Transaktionslogdateien für Amazon RDS planen.

Database Migration Service-Migrationsjobs

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

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

Der Migrationsprozess umfasst in der Regel die folgenden Aufgaben:

• Exportieren Sie eine vollständige Sicherung der Quelldatenbank und laden Sie sie dann in einen Cloud Storage-Bucket.
• Erstellen Sie eine Sicherung der Transaktionslog-Dateien und laden Sie sie in denselben Cloud Storage-Bucket hoch. Weitere Informationen dazu, wie Sie diesen Prozess automatisieren, siehe Planen Sie Uploads von Transaktionslogdateien für Amazon RDS.
• Im Database Migration Service können Sie die Verarbeitung der Transaktionslog-Sicherungen überwachen.
• Beenden Sie das Schreiben in die Quelldatenbank.
• Warten Sie, bis die Quelle und das Ziel synchronisiert sind. Dann wird die letzte Sicherung des Transaktionslogs verarbeitet.
• Beenden Sie die laufende Replikation und stufen Sie den Migrationsjob hoch.Durch das Hochstufen eines Migrationsjobs wird die Cloud SQL-Ziel-Instanz von der Quelldatenbankinstanz getrennt und dann zu einer primären Instanz hochgestuft.
• Stellen Sie die Anwendungen bereit, die auf die neue Zieldatenbank verweisen.

Eine ausführliche Anleitung zur Migration finden Sie unter SQL Server-Datenbanken zu Cloud SQL for SQL Server migrieren.

Integrierte Replikation des Datenbankmoduls

Wenn Sie Amazon RDS Standard verwenden, müssen Sie möglicherweise zuerst zur benutzerdefinierten Version von Amazon RDS migrieren und dann zu Cloud SQL replizieren.

Cloud SQL unterstützt die Replikation für SQL Server. Weitere Informationen zur Replikation von einem externen Server finden Sie unter Daten mithilfe von Snapshot-Replikation von SQL Server 2017 zu Cloud SQL for SQL Server migrieren.

Drittanbieter-Tools

Definieren Sie alle Ausführungsaufgaben für das ausgewählte Drittanbietertool. Wenn Sie beispielsweise Striim verwenden möchten, müssen Sie Apps in Ihrem Namespace erstellen und den CDC-Reader so konfigurieren, dass eine Verbindung zur Amazon-Instanz hergestellt wird. Weitere Informationen finden Sie in der Striim-Dokumentation unter „SQL Server-Einrichtung“.

Fallback-Szenarien definieren

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

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

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

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

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

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

Einfaches Fallback

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

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

Rückwärtsreplikation

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

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

Vorwärtsreplikation

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

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

Doppelte Schreibvorgänge

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

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

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

Testen und Validieren

In diesem Schritt werden folgende Punkte getestet und validiert:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Datenvalidierungstool

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

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

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

Die DVT unterstützt die folgenden Validierungstypen:

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

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

Migration ausführen

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

Beachten Sie bei der Datenmigration die folgenden Best Practices:

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

Führen Sie die Migration gemäß Ihrer definierte Ausführungsaufgaben aus und erfahren Sie mehr in der Dokumentation des ausgewählten Migrationstools.

Produktionsumstellung ausführen

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

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

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

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

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

Beachten Sie die Best Practices für die Produktionsumstellung:

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

Quellumgebung bereinigen und Cloud SQL-Instanz konfigurieren

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

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

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

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

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

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

Neben der Bereinigung der Quellumgebung müssen die folgenden wichtigen Konfigurationen für Ihre Cloud SQL-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.

Hier finden Sie weitere Informationen:

• Informationen zur Wartung von Cloud SQL-Instanzen
• Spezifische Einstellungen für die SQL Server-Engine

Umgebung nach der Migration optimieren

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

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

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

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

Optimierungsanforderungen festlegen

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

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

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

• Fügen Sie bei leselastigen Arbeitslasten Lesereplikate hinzu, um die primäre Instanz zu entlasten.
• Verwenden Sie für geschäftskritische Arbeitslasten die Hochverfügbarkeitskonfiguration, Replikate für den regionalen Failover und eine robuste Notfallwiederherstellungskonfiguration.
• Bei weniger kritischen Arbeitslasten reichen automatische und On-Demand-Sicherungen aus.
• Um ein versehentliches Löschen von Instanzen zu verhindern, verwenden Sie den Instanzlöschschutz.
• Aktivieren Sie die Wiederherstellung zu einem bestimmten Zeitpunkt für Ihre Cloud SQL for SQL Server-Instanz.
• Automatisieren Sie SQL-Datenbanksicherungen mit Wartungsplänen.

Kosteneffizienz Ihrer Datenbankinfrastruktur erhöhen

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

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

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

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

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

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

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

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

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

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

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

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

Um die Lizenzkosten insbesondere für Cloud SQL for SQL Server zu senken, sollten Sie Folgendes prüfen:

• Migrieren Sie zu SQL Server Standard Edition, wenn die SLAs Ihren Anforderungen entsprechen.
• Deaktivieren Sie das gleichzeitige Multithreading (SMT) und fügen Sie 25 % mehr Kerne hinzu. Die zusätzlichen Kerne können Leistungseinbußen durch das Deaktivieren von SMT ausgleichen. Mit dieser Strategie können Sie die Lizenzkosten senken, sie kann sich jedoch auf die Leistung Ihrer Instanz auswirken. Wir empfehlen Ihnen, Lasttests mit Ihrer Instanz durchzuführen, um sicherzustellen, dass Ihre SLAs nicht betroffen sind.
• Je nach Arbeitslast können Sie eine heterogene Migration von Cloud SQL for SQL Server zu Cloud SQL for PostgreSQL oder AlloyDB for PostgreSQL in Betracht ziehen.

Leistung der Datenbankinfrastruktur erhöhen

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

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

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

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

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

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

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

• Daten- und Indexfragmentierung verhindern. Legen Sie einen Zeitplan für die Neuerstellung Ihrer Indexe in SQL Server fest, je nachdem, wie häufig sich Ihre Daten ändern.

• Ändern Sie die Spezifischen Einstellungen für die SQL Server-Engine, damit sie optimal für Cloud SQL funktionieren.

• Informationen zur Wartung von Index und Statistiken finden Sie unter SQL Server-Wartungslösung.

• Aktualisieren Sie Statistiken regelmäßig in Cloud SQL for SQL Server.

• Führen Sie ETL-Vorgänge nicht auf einem Lesereplikat aus, da sie sich auf den Cache Ihrer Instanz auswirken können.

Weitere Informationen zur Leistungssteigerung finden Sie unter Leistung im Abschnitt „Probleme diagnostizieren“ und unter Cloud SQL – SQL Server-Leistungsanalyse und Abfrageoptimierung.

Beobachtbarkeit von Datenbanken erhöhen

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

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

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

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

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

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

• Logs für Ihre Cloud SQL-Instanz aufrufen und abfragen

• Beobachten Sie den Status Ihrer Datenbanken, um die Leistung Ihrer Umgebung zu verbessern und eventuelle Probleme zu beheben.

Allgemeine Best Practices und Betriebsrichtlinien für Cloud SQL

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

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

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

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

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

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

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

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

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

Datenbank-Sharding: Sie können Ihre Schreibvorgänge skalieren, indem Sie Ihre Datenbank in Shards aufteilen. Das Sharding ist ein komplexer Vorgang, der die Neustrukturierung Ihrer Datenbank und Anwendungen auf eine bestimmte Weise und die Durchführung einer Datenmigration umfasst. Sie teilen Ihre Datenbankinstanz mithilfe bestimmter Partitionierungskriterien in mehrere kleinere Instanzen auf. Die Kriterien können sich auf den Kunden oder das Thema beziehen. Mit dieser Option können Sie Schreib- und Lesevorgänge horizontal skalieren. Dadurch wird jedoch die Komplexität Ihrer Datenbank- und Anwendungsarbeitslasten erhöht. Außerdem kann es zu ungleich verteilten Shards führen, die sogenannten Hotspots, die den Vorteil des Sharding überwiegen würden.

Speziell für Cloud SQL for SQL Server gelten die folgenden Best Practices:

• Zum Aktualisieren der SQL Server-Einstellungen für optimale Leistung mit Cloud SQL, siehe SQL Server-Einstellungen
• Bestimmen Sie die Kapazität des E/A-Subsystems, bevor Sie SQL Server bereitstellen.

• Teilen Sie große Instanzen nach Möglichkeit in kleinere Instanzen auf:

  • Eine Laufwerkgröße von 4 TB oder mehr bietet mehr Durchsatz und IOPS.
  • Eine höhere vCPU bietet mehr IOPS und Durchsatz. Überwachen Sie bei Verwendung einer höheren vCPU die Datenbankwartezeit auf Parallelität, was auch zunehmen kann.

• Deaktivieren Sie SMT, wenn die Leistung in bestimmten Situationen beeinträchtigt ist. Zum Beispiel, wenn eine Anwendung Threads ausführt, die zu einem Engpass werden und die Architektur der CPU dies nicht effektiv verarbeitet.

• Legen Sie einen Zeitplan für die Reorganisierung oder Neuerstellung Ihrer Indexe fest, je nachdem, wie häufig Sie Daten ändern.

• Legen Sie einen geeigneten Füllfaktor fest, um die Fragmentierung zu reduzieren. Überwachen Sie SQL Server auf fehlende Indexe, die möglicherweise eine bessere Leistung bieten.

• 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. Verwalten Sie das Wachstum außerdem proaktiv, bevor der Grenzwert von autogrow erreicht wird.

• Wenn die Speicherkapazität automatisch skaliert werden soll, aktivieren Sie die automatische Speichererweiterung. Cloud SQL kann Speicherplatz hinzufügen, wenn der Speicherplatz der Datenbank und der Instanz aufgebraucht ist.

• Sie müssen die Sprachanforderungen, die Sortierreihenfolge sowie die Groß- und Kleinschreibung der Daten, mit denen Sie arbeiten, kennen. Wenn Sie eine Sortierung für Ihren Server, Ihre Datenbank, Ihre Spalte oder Ihren Ausdruck auswählen, weisen Sie Ihren Daten bestimmte Merkmale zu.

• Rekursive Hash-Joins oder Hash-Bailouts führen zu einer geringeren Leistung auf einem Server. Wenn in einem Trace viele Hash-Warnungsereignisse angezeigt werden, aktualisieren Sie die Statistiken zu den zu verknüpfenden Spalten. Weitere Informationen finden Sie unter Hash-Warnung – Ereignisklasse.

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

Nächste Schritte

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

Beitragende

Autoren:

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

Weitere Beitragende:

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