SQL Server-Datenbank von AWS EC2 zu Compute Engine migrieren

In dieser Anleitung werden die verschiedenen Ansätze beschrieben, mit denen Sie eine Microsoft SQL Server-Datenbank in Amazon Elastic Compute Cloud (AWS EC2) zu Compute Engine migrieren können.

Auf dieser Seite werden die folgenden Ansätze erläutert:

• Mit vollständiger Sicherung und Wiederherstellung migrieren
• Mit einer BACPAC-Datei migrieren
• Mit Always On-Verfügbarkeitsgruppen migrieren
• Mit verteilten Verfügbarkeitsgruppen migrieren

Jede Migrationsmethode hat unterschiedliche Vor- und Nachteile. Die am besten geeignete Migrationsstrategie hängt von Ihren spezifischen Umständen und Prioritäten ab. Wir empfehlen, eine Migrationsmethode auszuwählen, die am besten zu Ihnen passt. Berücksichtigen Sie dabei die folgenden Punkte:

• Verfügbarkeit: Prüfen Sie, ob ein Migrationsansatz von allen Versionen und Lizenzen Ihrer SQL Server-Datenbank unterstützt wird.

• Datenbankgröße: Die Größe der Datenbank kann die möglichen Migrationsoptionen erheblich beeinflussen, da für größere Datenbanken möglicherweise andere Strategien erforderlich sind als für kleinere. Berücksichtigen Sie bei der Auswahl eines Migrationsansatzes die Dauer der Datenübertragung, potenzielle Ausfallzeiten und Ressourcenanforderungen.

• Toleranz für Ausfallzeiten: Die akzeptable Ausfallzeit während der Migration ist ein entscheidender Faktor. Einige Methoden ermöglichen minimale bis nahezu keine Ausfallzeiten, während andere längere Ausfallzeiten erfordern. Wählen Sie einen Migrationsansatz, der eine für Sie akzeptable Ausfallzeit bietet.

• Komplexität: Die Komplexität des Datenbankschemas, der Anwendungsabhängigkeiten und der Gesamtumgebung kann den Migrationsansatz beeinflussen. Achten Sie darauf, dass die von Ihnen gewählte Migrationsmethode die Migration von Nicht-Datenbankobjekten wie SQL-Agent-Jobs, verknüpften Servern, Berechtigungen und Nutzerobjekten unterstützt.

• Kosten: Der finanzielle Aspekt der Migration kann ebenfalls eine Rolle spielen. Die verschiedenen Migrationsmethoden sind mit unterschiedlichen Kosten für Datenübertragung, Rechenressourcen und andere Dienste verbunden. Wählen Sie die Migrationsmethode aus, die am besten zu Ihnen passt.

• Datensicherheit und Compliance: Achten Sie darauf, dass die gewählte Migrationsmethode Ihren Anforderungen an Datensicherheit und Compliance entspricht. Berücksichtigen Sie die Datenverschlüsselung, die Zugriffssteuerung und alle branchenspezifischen Anforderungen, die für Ihre Daten gelten.

Ziele

In dieser Anleitung erfahren Sie, wie Sie die folgenden Aufgaben ausführen, um Ihre SQL Server-Datenbank von AWS EC2 zu Compute Engine zu migrieren:

• SQL Server-Instanz in Compute Engine bereitstellen
• Mit Vollsicherung und Wiederherstellung migrieren
• Mit einer BACPAC-Datei migrieren
• Mit Always On-Verfügbarkeitsgruppen migrieren
• Migration mit verteilten Verfügbarkeitsgruppen

Kosten

In dieser Anleitung werden kostenpflichtige Komponenten von Google Cloudverwendet, darunter:

• Compute Engine
• Cloud Load Balancing

Sie können mithilfe des Preisrechners eine Kostenschätzung für Ihre voraussichtliche Nutzung erstellen.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

1. Wählen Sie in der Google Cloud Console auf der Seite für die Projektauswahl ein Projekt von Google Cloud aus oder erstellen Sie eines.

   Erforderliche Rollen zum Auswählen oder Erstellen eines Projekts

   • Projekt auswählen: Für die Auswahl eines Projekts ist keine bestimmte IAM-Rolle erforderlich. Sie können jedes Projekt auswählen, für das Ihnen eine Rolle zugewiesen wurde.
   • Projekt erstellen: Zum Erstellen eines Projekts benötigen Sie die Rolle „Project Creator“ (roles/resourcemanager.projectCreator), die die Berechtigung resourcemanager.projects.create enthält. Informationen zum Zuweisen von Rollen
   Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.

   Zur Projektauswahl

2. Prüfen Sie, ob die Abrechnung für Ihr Google Cloud -Projekt aktiviert ist.

3. Aktivieren Sie Cloud Shell in der Google Cloud Console.

   Cloud Shell aktivieren

Projekt und Netzwerk vorbereiten

So bereiten Sie Ihr Google Cloud -Projekt und Ihre Virtual Private Cloud (VPC) für die Bereitstellung von SQL Server für die Migration vor:

1. Klicken Sie in der Google Cloud Console auf Cloud Shell aktivieren , um Cloud Shell zu öffnen.

   Rufen Sie die Google Cloud Console auf.

2. Legen Sie Ihre standardmäßige Projekt-ID fest:

   gcloud config set project PROJECT_ID
   

   Ersetzen Sie PROJECT_ID durch die ID Ihres Google Cloud Projekts.

3. Legen Sie Ihre Standardregion fest:

   gcloud config set compute/region REGION
   

   Ersetzen Sie REGION durch die ID der Region, in der die Bereitstellung erfolgen soll.

4. Legen Sie Ihre Standardzone fest:

   gcloud config set compute/zone ZONE
   

   Ersetzen Sie ZONE durch die ID der Zone, in der die Bereitstellung erfolgen soll. Achten Sie darauf, dass die Zone in der Region gültig ist, die Sie im vorherigen Schritt angegeben haben.

SQL Server-Instanz in der Compute Engine erstellen

Bevor Sie Ihre SQL Server-Datenbank zu Compute Engine migrieren können, müssen Sie eine virtuelle Maschine (VM) in Compute Engine erstellen, um sie zu hosten.

Verwenden Sie den folgenden Befehl, um eine SQL Server-Instanz in Compute Engine zu erstellen:

2022 Standard

gcloud compute instances create sql-server-std-migrate-vm \
--project=PROJECT_ID \
--zone ZONE \
--machine-type n4-standard-8 \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/windows-sql-cloud/global/images/sql-2022-standard-windows-2022-dc-v20250213,mode=rw,size=50,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

Ersetzen Sie Folgendes:

• PROJECT_ID: durch die ID Ihres Google Cloud -Projekts.
• ZONE: durch die ID der Zone.
• SUBNET_NAME: durch den Namen Ihres VPC-Subnetzes.

2022 Enterprise

gcloud compute instances create sql-server-ent-migrate-vm \
--project=PROJECT_ID \
--zone ZONE \
--machine-type n4-standard-8 \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/windows-sql-cloud/global/images/sql-2022-enterprise-windows-2022-dc-v20250213,mode=rw,size=50,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

Ersetzen Sie Folgendes:

• PROJECT_ID: durch die ID Ihres Google Cloud -Projekts.
• ZONE: durch die ID der Zone.
• SUBNET_NAME: durch den Namen Ihres VPC-Subnetzes.

Weitere Informationen zum Erstellen von SQL Server-Instanzen in Compute Engine finden Sie unter SQL Server-Instanz erstellen.

SQL Server-VM konfigurieren und Verbindung herstellen

So konfigurieren Sie Ihre SQL Server-VM und stellen eine Verbindung zu ihr her:

1. Legen Sie das erste Windows-Passwort für Ihr Konto fest:

   1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

      Zu „VM-Instanzen“

   2. Klicken Sie auf den Namen der SQL Server-VM.

   3. Klicken Sie auf den Button Windows-Passwort festlegen.

   4. Geben Sie ein Passwort ein und klicken Sie auf Festlegen, wenn Sie aufgefordert werden, das neue Windows-Passwort festzulegen.

   5. Speichern Sie den Nutzernamen und das Passwort.

2. Stellen Sie eine Verbindung zur SQL Server-VM her:

   1. Verwenden Sie die öffentliche IP-Adresse der SQL Server-VM von der Seite VM-Instanzen und die im vorherigen Schritt gespeicherten Anmeldedaten, um über Microsoft Remote Desktop (RDP) eine Verbindung zu Ihrer SQL Server-VM herzustellen.

   2. Führen Sie SQL Server Management Studio (SSMS) als Administrator aus.

   3. Prüfen Sie, ob das Kästchen Serverzertifikat vertrauen ausgewählt ist, und klicken Sie auf Verbinden.

Ihre SQL Server-VM kann jetzt für die Datenbankmigration verwendet werden. Informationen zum Erstellen neuer Nutzeranmeldungen, um eine Verbindung zu Ihrer SQL Server-VM herzustellen und diese zu verwalten, finden Sie unter Anmeldung erstellen.

Vollständige Datenbanksicherung und -wiederherstellung

Die vollständige Sicherung und Wiederherstellung einer Datenbank ist die gängigste und einfachste Methode der Datenbankmigration. Bei diesem Ansatz wird eine Vollsicherung der SQL Server-Datenbank aus der Quellumgebung erstellt und dann in der Zielumgebung von Google Cloud wiederhergestellt. Diese Methode ist zwar relativ unkompliziert, kann aber bei großen Datenbanken zeitaufwendig sein, da das Erstellen und Wiederherstellen der Sicherung Zeit in Anspruch nimmt.

In diesem Abschnitt wird beschrieben, wie Sie mit SSMS Ihre SQL Server-Datenbank anhand einer AdventureWorks2022-Beispieldatenbank exportieren können.

Eine vollständige Datenbanksicherung erstellen

So erstellen Sie eine vollständige Datenbanksicherung:

1. Melden Sie sich mit Microsoft RDP bei Ihrer AWS EC2-VM an.

2. Stellen Sie über SSMS eine Verbindung zu SQL Server her.

3. Maximieren Sie den Ordner „Databases“ im Objekt-Explorer.

4. Klicken Sie mit der rechten Maustaste auf den Datenbanknamen und wählen Sie im Menü Tasks aus.

5. Klicken Sie auf Sichern, um den Assistenten für die Datenbanksicherung zu öffnen.

   1. Prüfen Sie, ob der Name der zu sichernden Datenbank und der Sicherungstyp auf „Vollständig“ festgelegt sind.

   2. Klicken Sie unter dem Ziel für die Vollsicherung auf Hinzufügen.

   3. Klicken Sie auf das Dreipunkt-Menü (…), um den Ordner und den Namen der Sicherungsdatei auszuwählen.

   4. Klicken Sie auf OK, um den Dateinamen festzulegen, und noch einmal auf OK, um das Ziel festzulegen.

      

   5. Klicken Sie auf OK, um die Datenbanksicherung zu starten, und warten Sie, bis die Sicherung abgeschlossen ist.

      Nach Abschluss des Sicherungsvorgangs wird eine Sicherungsdatei erstellt. Sie können diese Sicherungsdatei jetzt verwenden, um die Datenbankinhalte zu einer Compute Engine-VM zu migrieren.

   6. Klicken Sie auf OK, um den Assistenten für die Datenbanksicherung zu schließen.

Sicherungsdatei auf eine Compute Engine-VM übertragen

Wenn Sie den Inhalt Ihrer SQL Server-Datenbank migrieren möchten, müssen Sie die im vorherigen Schritt erstellte Sicherungsdatei auf die von Ihnen erstellte Compute Engine-VM übertragen. Informationen zu den verschiedenen Übertragungsoptionen finden Sie unter Dateien auf Windows-VMs übertragen.

SQL Server-Datenbank aus der Sicherungsdatei wiederherstellen

So stellen Sie die Datenbank aus der Sicherungsdatei wieder her:

1. Melden Sie sich über RDP bei Ihrer Compute Engine-VM an.

2. Stellen Sie über SSMS eine Verbindung zu SQL Server her.

3. Klicken Sie im Objekt-Explorer mit der rechten Maustaste auf den Ordner Datenbanken und dann auf Datenbank wiederherstellen.

4. Klicken Sie unter Quelle auf Gerät und dann auf das Dreipunkt-Menü (…), um die Seite „Sicherungsgerät auswählen“ zu öffnen.

5. Prüfen Sie, ob der Sicherungsmedientyp auf „Datei“ festgelegt ist, und klicken Sie auf Hinzufügen, um die Sicherungsdatei auszuwählen.

   

6. Klicken Sie auf OK, um die Sicherungsdatei als Wiederherstellungsgerät festzulegen.

7. Klicken Sie auf OK, um die Datenbank wiederherzustellen.

   Wenn der Vorgang abgeschlossen ist, wird Ihre Datenbank zum SQL Server-Ziel in Compute Engine migriert.

8. Wenn Sie prüfen möchten, ob der Vorgang erfolgreich abgeschlossen wurde, können Sie den Ordner Datenbanken im Objekt-Explorer maximieren und nachsehen, ob die migrierte Datenbank angezeigt wird.

   

Mit einer BACPAC-Datei migrieren

Eine BACPAC-Datei (Backup Package) ist eine logische Darstellung einer SQL Server-Datenbank. Sie kann aus der AWS-Quellumgebung exportiert und dann in die Google Cloud -Zielumgebung importiert werden. Diese Methode ist bei kleineren Datenbanken in der Regel schneller als eine Vollsicherung und ‑wiederherstellung, eignet sich aber möglicherweise nicht für sehr große Datenbanken oder Datenbanken mit komplexen Abhängigkeiten.

Im folgenden Abschnitt wird beschrieben, wie Sie Ihre SQL Server-Datenbank mithilfe einer BACPAC-Datei migrieren können.

BACPAC-Export erstellen

So erstellen Sie einen BACPAC-Export:

1. Melden Sie sich mit Microsoft RDP bei der AWS EC2-VM an.

2. Stellen Sie über SSMS eine Verbindung zu SQL Server her.

3. Maximieren Sie im Objekt-Explorer den Ordner Datenbanken.

4. Rechtsklicken Sie auf den Datenbanknamen und dann auf Aufgaben.

5. Klicken Sie auf Datenebenenanwendung exportieren, um den Export-Assistenten zu öffnen.

   1. Klicken Sie auf Weiter.

   2. Klicken Sie unter der Option Auf lokaler Festplatte speichern auf Durchsuchen und wählen Sie die BACPAC-Datei aus.

   3. Klicken Sie auf den Tab Erweitert und wählen Sie die Schemas aus, die Sie exportieren möchten.

   4. Klicken Sie auf Weiter, um zur Zusammenfassung zu gelangen.

   5. Klicken Sie auf Fertigstellen, um die BACPAC-Datei zu exportieren, und warten Sie, bis der Export abgeschlossen ist.

   6. Klicken Sie auf Schließen, um den Assistenten zu beenden.

6. Übertragen Sie die in den vorherigen Schritten erstellte BACPAC-Datei auf Ihre Ziel-VM in Compute Engine. Informationen zu den Übertragungsoptionen finden Sie unter Dateien auf Windows-VMs übertragen.

SQL Server-Datenbank aus einer BACPAC-Datei wiederherstellen

So stellen Sie die Datenbank aus der BACPAC-Datei wieder her:

1. Melden Sie sich über RDP bei der Compute Engine-VM an.

2. Stellen Sie über SSMS eine Verbindung zu SQL Server her.

3. Klicken Sie im Objekt-Explorer mit der rechten Maustaste auf den Ordner Datenbanken und dann auf Datenebenenanwendung importieren.

4. Klicken Sie auf Weiter.

5. Klicken Sie auf Durchsuchen, wählen Sie die BACPAC-Datei aus, die Sie wiederherstellen möchten, und klicken Sie dann auf Weiter.

6. Prüfen Sie den Namen der neuen Datenbank und klicken Sie auf Weiter.

7. Klicken Sie auf Fertigstellen und warten Sie, bis der Import abgeschlossen ist.

8. Klicken Sie auf Schließen, um den Assistenten zu beenden.

9. Wenn Sie prüfen möchten, ob der Vorgang erfolgreich abgeschlossen wurde, können Sie den Ordner Datenbanken im Objekt-Explorer maximieren und nachsehen, ob die migrierte Datenbank angezeigt wird.

Mit Always On-Verfügbarkeitsgruppen migrieren

Eine AOAG ist ein Feature für Hochverfügbarkeit und Notfallwiederherstellung von SQL Server. Sie können eine AOAG verwenden, um vorhandene AOAG-Cluster, eigenständige SQL-Server und Windows Server-Failover-Cluster (WSFC) zu migrieren. Bei dieser Methode wird ein Replikat der Datenbank in der Zielumgebung von Google Cloud erstellt und die Daten werden zwischen Quelle und Ziel synchronisiert. Nach Abschluss der Synchronisierung kann das Replikat in der Zielumgebung von Google Cloud zum primären Replikat gemacht werden. Diese Methode minimiert die Ausfallzeit, erfordert jedoch eine zusätzliche Konfiguration und Einrichtung. Für einfache Migrationen mit hoher Ausfallzeittoleranz sind andere Methoden möglicherweise einfacher und kostengünstiger.

Hinweis

Prüfen Sie vor Beginn der Migration Folgendes:

• Um eine sichere und nahtlose Datenübertragung zu gewährleisten, richten Sie eine Peering-Verbindung zwischen AWS und Google Cloudein. Weitere Informationen finden Sie unter HA VPN-Verbindungen zwischen Google Cloud und AWS erstellen.

• Achten Sie darauf, dass die Quelldatenbank im eigenständigen Modus ausgeführt wird und sowohl der Quell- als auch der Zielserver mit einem Active Directory (AD) verbunden sind. Wenn die Quelldatenbank bereits Teil eines WSFC-Clusters mit einer AOAG ist, lesen Sie den Abschnitt Mit verteilten Verfügbarkeitsgruppen migrieren.

• Achten Sie darauf, dass alle Verschlüsselungsschlüssel der SQL Server-Quelldatenbank auf allen SQL Server-Instanzen installiert sind, die der AOAG beitreten.

SQL Server für die Aufnahme in eine AOAG vorbereiten

Damit Sie SQL Server zu einer AOAG hinzufügen können, müssen Sie die AOAG-Funktion auf allen SQL Server-Instanzen aktivieren, die Sie der Gruppe hinzufügen möchten.

So aktivieren Sie die AOAG-Funktion auf allen SQL Server-VMs, die Sie einer AOAG hinzufügen möchten:

1. Aktivieren Sie AOAG auf Ihrem SQL Server.

   1. Melden Sie sich über RDP bei Ihrer SQL Server-VM an.

   2. Öffnen Sie PowerShell im Administratormodus.

   3. Führen Sie den folgenden Befehl aus, um AOAG auf Ihrem SQL Server zu aktivieren.

      Enable-SqlAlwaysOn -ServerInstance $env:COMPUTERNAME -Force
      

   4. Führen Sie den folgenden Befehl aus, um einen Firewall-Port für die Datenreplikation zu öffnen.

      netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022
      

   5. Wiederholen Sie Schritt 1 für alle SQL Server-VMs, die Sie der AOAG hinzufügen möchten.

2. Erstellen Sie in Ihrem AD einen neuen Nutzer für Ihren SQL Server.

   $Credential = Get-Credential -UserName sql_server -Message 'Enter password'
   New-ADUser `
   -Name "sql_server" `
   -Description "SQL Admin account." `
   -AccountPassword $Credential.Password `
   -Enabled $true -PasswordNeverExpires $true
   

3. Führen Sie die folgenden Schritte auf allen SQL Server-Instanzen aus, die Teil der AOAG sind:

   1. Öffnen Sie den SQL Server-Konfigurations-Manager.
   2. Wählen Sie im Navigationsbereich SQL Server-Dienste aus.
   3. Klicken Sie in der Liste der Dienste mit der rechten Maustaste auf SQL Server (MSSQLSERVER) und wählen Sie Eigenschaften aus.
   4. Ändern Sie unter Anmelden als das Konto so:
      • Kontoname: DOMAIN\sql_server, wobei DOMAIN der NetBIOS-Name Ihrer AD-Domain ist.
      • Passwort: Geben Sie das Passwort ein, das Sie im vorherigen Schritt 2 dieses Abschnitts ausgewählt haben.

   5. Klicken Sie auf OK.

   6. Wenn Sie aufgefordert werden, SQL Server neu zu starten, wählen Sie Ja.

Ihr SQL Server wird jetzt unter einem Domainnutzerkonto ausgeführt.

Hinweis: Achten Sie darauf, dass Sie diese Konfigurationsschritte auf allen VM-Instanzen ausgeführt haben, die Sie der AOAG hinzufügen möchten. Andernfalls schlägt die Einrichtung der AOAG fehl.

Spiegelungsendpunkt für Ihre SQL Server-Datenbank einrichten

So erstellen Sie den Endpunkt für Ihre AOAG:

1. Wenn die SQL Server-Quelldatenbank mit Transparent Data Encryption (TDE) verschlüsselt ist, führen Sie diesen Schritt aus, um die Zertifikate und Schlüssel zu sichern, zu übertragen und auf dem SQL Server-Ziel zu installieren.

2. Melden Sie sich mit SSMS in der Quelldatenbank in AWS an.

3. Führen Sie den folgenden T-SQL-Befehl aus, um den Endpunkt für die Verfügbarkeitsgruppe zu erstellen.

   USE [master]
   GO
   CREATE LOGIN [NET_DOMAIN\sql_server] FROM WINDOWS
   GO
   
   USE [DATABASE_NAME]
   GO
   CREATE USER [NET_DOMAIN\sql_server] FOR LOGIN [NET_DOMAIN\sql_server]
   GO
   
   USE [master]
   GO
   CREATE ENDPOINT migration_endpoint
       STATE=STARTED
       AS TCP (LISTENER_PORT=5022)
       FOR DATABASE_MIRRORING (ROLE=ALL);
   GO
   
   GRANT CONNECT ON ENDPOINT::[migration_endpoint] TO [NET_DOMAIN\sql_server]
   GO
   

   Ersetzen Sie NET_DOMAIN durch den NetBIOS-Namen Ihrer AD-Domain und DATABASE_NAME durch den Namen der zu migrierenden Datenbank.

   Tipp: Der Standard-Überwachungsport ist 5022. Sie können jedoch auch jeden anderen verfügbaren Port verwenden.

4. Stellen Sie mit SSMS eine Verbindung zum Ziel-SQL-Server auf Google Cloud her und führen Sie den folgenden T-SQL-Befehl aus, um den Endpunkt für die Datenbankspiegelung zu erstellen.

   CREATE LOGIN [NET_DOMAIN\sql_server] FROM WINDOWS
   GO
   
   CREATE ENDPOINT migration_endpoint
       STATE=STARTED
       AS TCP (LISTENER_PORT=5022)
       FOR DATABASE_MIRRORING (ROLE=ALL);
   GO
   
   GRANT CONNECT ON ENDPOINT::[migration_endpoint] TO [NET_DOMAIN\sql_server]
   GO
   

   Ersetzen Sie NET_DOMAIN durch den NetBIOS-Namen Ihrer AD-Domain.

5. Prüfen Sie die Endpunkte, indem Sie im Objekt-Explorer in SSMS zu Serverobjekte > Endpunkte > Datenbankspiegelung gehen.

   

AOAG erstellen

So erstellen Sie eine AOAG:

1. Melden Sie sich mit SSMS in der Quelldatenbank in AWS an.

2. Führen Sie den folgenden T-SQL-Befehl aus, um den Wiederherstellungsmodus der Datenbank auf „Vollständig“ festzulegen und eine Vollsicherung zu erstellen.

   USE [master]
   GO
   
   ALTER DATABASE [DATABASE_NAME]
   SET RECOVERY FULL;
   BACKUP DATABASE [DATABASE_NAME]
   TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Backup\DATABASE_NAME.bak';
   

   Ersetzen Sie DATABASE_NAME durch den Namen der zu migrierenden Datenbank.

3. Führen Sie den folgenden T-SQL-Befehl aus, um die AOAG zu erstellen.

   USE [master]
   GO
   
   CREATE AVAILABILITY GROUP [migration-ag]
   WITH (
       AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
       DB_FAILOVER = OFF,
       DTC_SUPPORT = NONE,
       REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0
   )
   FOR DATABASE [DATABASE_NAME]
   REPLICA ON
   N'SOURCE_SERVERNAME' WITH (
       ENDPOINT_URL = 'TCP://SOURCE_HOSTNAME:5022',
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
       FAILOVER_MODE = MANUAL,
       BACKUP_PRIORITY = 50,
       SEEDING_MODE = AUTOMATIC,
       SECONDARY_ROLE(ALLOW_CONNECTIONS = READ_ONLY)
   ),
   N'DEST_SERVERNAME' WITH (
       ENDPOINT_URL = 'TCP://DEST_HOSTNAME:5022',
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
       FAILOVER_MODE = MANUAL,
       BACKUP_PRIORITY = 50,
       SEEDING_MODE = AUTOMATIC,
       SECONDARY_ROLE(ALLOW_CONNECTIONS = READ_ONLY)
   );
   GO
   

   Ersetzen Sie Folgendes:

   • DATABASE_NAME: durch den Namen der zu migrierenden Datenbank.
   • SOURCE_SERVERNAME: durch den Servernamen der Quelldatenbank.
   • DEST_SERVERNAME: durch den Servernamen der Zieldatenbank.
   • SOURCE_HOSTNAME: durch den voll qualifizierten Domainnamen (FQDN) der Quelle.
   • DEST_HOSTNAME: durch den FQDN des Ziels.
   Hinweis: Die AOAG verwendet den asynchronen Commit-Modus und hat das automatische Failover deaktiviert, um die Auswirkungen auf den primären SQL Server zu minimieren.

4. Führen Sie den folgenden T-SQL-Befehl in der Zieldatenbank aus, um sie der AOAG hinzuzufügen.

   USE [master]
   GO
   
   ALTER AVAILABILITY GROUP [migration-ag] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
   ALTER AVAILABILITY GROUP [migration-ag] GRANT CREATE ANY DATABASE;
   GO
   

5. Prüfen Sie die neu erstellte AOAG und den Datenbankstatus im Objekt-Explorer oder führen Sie den folgenden T-SQL-Befehl aus.

   SELECT * FROM sys.dm_hadr_availability_group_states
   GO
   

   

Die SQL Server-AOAG ist jetzt konfiguriert und wird zwischen AWS und Google Cloudsynchronisiert. Als Nächstes müssen Sie einen WSFC und einen Listener für Hochverfügbarkeit und Notfallwiederherstellung konfigurieren. Weitere Informationen finden Sie unter Windows Server Failover Clustering mit SQL Server und Was ist ein Listener für eine Verfügbarkeitsgruppe?.

Mit verteilten Verfügbarkeitsgruppen migrieren

Eine verteilte Verfügbarkeitsgruppe ist ein spezieller Typ von Verfügbarkeitsgruppe, der sich über zwei separate Verfügbarkeitsgruppen erstreckt. Sie ist so konzipiert, dass sie Hochverfügbarkeit und Notfallwiederherstellung an geografisch verteilten Standorten bietet. Diese Architektur ermöglicht eine nahtlose Datenreplikation und ein Failover zwischen den primären und sekundären Verfügbarkeitsgruppen, was ideal für die Datenmigration ist. Weitere Informationen finden Sie unter Verteilte Verfügbarkeitsgruppen.

Hinweis: Verteilte Verfügbarkeitsgruppen werden für Verfügbarkeitsgruppen, die verteilte Netzwerknamen (Distributed Network Names, DNN) verwenden, nicht unterstützt. Weitere Informationen finden Sie unter Feature-Interoperabilität mit AG- und DNN-Listener

.

In den folgenden Abschnitten wird beschrieben, wie Sie Ihre SQL Server-Datenbank mit verteilten Verfügbarkeitsgruppen migrieren können.

Hinweis

Sie benötigen einen WSFC mit SQL Server, der eine Verfügbarkeitsgruppe mit einem VNN-Listener (Virtual Network Name) verwendet und auf AWS ausgeführt wird.

Zielumgebung vorbereiten

So bereiten Sie die Zielumgebung vor:

1. Informationen zum Konfigurieren eines WSFC mit SQL Server mithilfe einer Verfügbarkeitsgruppe mit einem internen Load Balancer auf Google Cloudfinden Sie unter SQL Server Always-on-Verfügbarkeitsgruppen mit synchronem Commit mithilfe eines internen Load Balancers konfigurieren.

2. Prüfen Sie im Objekt-Explorer, ob bookshelf-ag erstellt wurde und die Datenbank bookshelf repliziert. Nachdem Sie das überprüft haben, führen Sie die folgenden Schritte aus, um sowohl die Verfügbarkeitsgruppe als auch die Datenbank von beiden Knoten im Failover-Cluster zu entfernen.

   

3. Stellen Sie in SSMS eine Verbindung zu node-1 her und speichern Sie die IP-Adresse des bookshelf-Listeners.

   SELECT * FROM sys.availability_group_listeners
   

4. Führen Sie den folgenden T-SQL-Befehl aus, um die Verfügbarkeitsgruppe bookshelf-ag und die Datenbank bookshelf zu entfernen.

   USE master
   GO
   
   DROP AVAILABILITY GROUP [bookshelf-ag]
   GO
   ALTER DATABASE [bookshelf] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   GO
   DROP DATABASE [bookshelf]
   GO
   

5. Führen Sie den folgenden T-SQL-Befehl für node-2 in SSMS aus, um die replizierte Datenbank zu entfernen.

   USE master
   GO
   
   DROP DATABASE [bookshelf]
   GO
   

Verteilte Verfügbarkeitsgruppe erstellen

So erstellen Sie eine neue Verfügbarkeitsgruppe für die verteilte Verfügbarkeitsgruppe:

1. Führen Sie den folgenden T-SQL-Befehl in node-1 aus.

   USE master
   GO
   
   CREATE AVAILABILITY GROUP [gcp-dest-ag]
   FOR
   REPLICA ON
       N'NODE-1' WITH
       (
           ENDPOINT_URL = N'TCP://NODE-1:5022',
           FAILOVER_MODE = MANUAL,
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
           BACKUP_PRIORITY = 50,
           SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
           SEEDING_MODE = AUTOMATIC
       ),
       N'NODE-2' WITH
       (
           ENDPOINT_URL = N'TCP://NODE-2:5022',
           FAILOVER_MODE = MANUAL,
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
           BACKUP_PRIORITY = 50,
           SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
           SEEDING_MODE = AUTOMATIC
       );
   GO
   

2. Erstellen Sie einen Listener.

   USE master;
   GO
   
   ALTER AVAILABILITY GROUP [gcp-dest-ag]
   ADD LISTENER N'gcp-dest-lsnr' (
   WITH IP (
   (N'LISTENER_IP', N'255.255.255.0')
   ),
   PORT = 1433);
   GO
   

   Ersetzen Sie LISTENER_IP durch die IP-Adresse des Listeners.

3. Stellen Sie mit SSMS eine Verbindung zu node-2 her und führen Sie den folgenden T-SQL-Befehl aus, um die Instanz der Verfügbarkeitsgruppe gcp-dest-ag hinzuzufügen.

   USE master
   GO
   
   ALTER AVAILABILITY GROUP [gcp-dest-ag] JOIN;
   ALTER AVAILABILITY GROUP [gcp-dest-ag] GRANT CREATE ANY DATABASE;
   

4. Stellen Sie über SSMS eine Verbindung zum primären Replikat des Quell-SQL-Servers in AWS her und führen Sie den folgenden T-SQL-Befehl aus, um eine verteilte Verfügbarkeitsgruppe zu erstellen.

   USE [master]
   GO
   
   CREATE AVAILABILITY GROUP [distributed-ag]
   WITH (DISTRIBUTED)
   AVAILABILITY GROUP ON
   'AWS_AG' WITH
   (
       LISTENER_URL = 'tcp://AWS_LISTENER:5022',
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
       FAILOVER_MODE = MANUAL,
       SEEDING_MODE = AUTOMATIC
   ),
   'gcp-dest-ag' WITH
   (
       LISTENER_URL = 'tcp://gcp-dest-lsnr:5022',
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
       FAILOVER_MODE = MANUAL,
       SEEDING_MODE = AUTOMATIC
   )
   GO
   

   Ersetzen Sie AWS_AG durch den Namen der Verfügbarkeitsgruppe in AWS und AWS_LISTENER durch den Listener der AWS-Verfügbarkeitsgruppe.

   Hinweis: Die für jede Verfügbarkeitsgruppe angegebene Listener-URL ist der Listener-Hostname zusammen mit dem Port des Datenbankspiegelungsendpunkts. Wenn Sie einen anderen Port als 5022 verwenden, müssen Sie die Ports ändern, bevor Sie das T-SQL ausführen.

5. Führen Sie den folgenden T-SQL-Befehl in SSMS auf node-1 aus, um ihn der verteilten Verfügbarkeitsgruppe hinzuzufügen.

   Tipp: Verwenden Sie ein Tool wie Netcat oder Test-NetConnection, um zu prüfen, ob die Quell- und Ziellistener über den Endpunktport (5022) von den primären Replikaten der Quelle und des Ziels erreichbar sind. Möglicherweise sind zusätzliche Firewallregeln erforderlich, um den Traffic zuzulassen.

   USE [master]
   GO
   
   ALTER AVAILABILITY GROUP [distributed-ag]
   JOIN
   AVAILABILITY GROUP ON
   'AWS_AG' WITH
   (
       LISTENER_URL = 'tcp://AWS_LISTENER:5022',
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
       FAILOVER_MODE = MANUAL,
       SEEDING_MODE = AUTOMATIC
   ),
   'gcp-dest-ag' WITH
   (
       LISTENER_URL = 'tcp://gcp-dest-lsnr:5022',
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
       FAILOVER_MODE = MANUAL,
       SEEDING_MODE = AUTOMATIC
   )
   GO
   

   Ersetzen Sie AWS_AG durch den Namen der Verfügbarkeitsgruppe in AWS und AWS_LISTENER durch den Listener der AWS-Verfügbarkeitsgruppe.

6. Führen Sie den folgenden T-SQL-Befehl auf „node-1“ aus, um zu prüfen, ob alle Verfügbarkeitsgruppen fehlerfrei sind und über die verteilte Verfügbarkeitsgruppe auf den neuen SQL Server-Cluster in Google Cloudrepliziert werden.

   SELECT * FROM sys.dm_hadr_availability_group_states
   GO
   

Bereinigen

Nachdem Sie die Anleitung abgeschlossen haben, können Sie die erstellten Ressourcen bereinigen, damit sie keine Kontingente mehr nutzen und keine Gebühren mehr anfallen. In den folgenden Abschnitten erfahren Sie, wie Sie diese Ressourcen löschen oder deaktivieren.

Projekt löschen

Am einfachsten vermeiden Sie weitere Kosten, wenn Sie das zum Ausführen der Anleitung erstellte Projekt löschen.

So löschen Sie das Projekt:

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, zum Beispiel eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, anstatt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

1. Wechseln Sie in der Google Cloud -Console zur Seite Ressourcen verwalten.

   Zur Seite „Ressourcen verwalten“

2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.