Native SQL Server -Sicherung/Wiederherstellung

Microsoft SQL Server -Datenbanken unterstützen native Sicherungs-und Zurückschreibungsoperationen, die vollständige und differenzielle Sicherungsdateien (.bak) oder differenzielle Zurückschreibungen und Protokollzurückschreibungen verwenden. Die Verwendung von nativen .bak-Dateien ist die einfachste Methode zum Sichern und Zurückschreiben von SQL Server -Datenbanken und eine einfache Migrationsmethode für einzelne oder mehrere Datenbanken in einer Instanz. Vollständige Sicherungen der Datenbank auf Ihrem vorhandenen Server werden erstellt und in ein IBM Cloud Object Storage -Bucket kopiert. Anschließend wird sie über einen Staging-Server mit der Freigabe s3fs oder rclone und SMB\Samba auf Ihrem virtuellen Server der SQL Server -Datenbankinstanz in IBM Cloud VPC

Transaktionsorientierte Replikation

Die transaktionsorientierte Replikation ermöglicht die Übertragung von Änderungen zwischen Datenbanken. Diese Änderungen können Daten, Tabellen, gespeicherte Prozeduren, Ansichten usw. umfassen. Die Architektur besteht aus folgenden Komponenten:

• Publisher-Die primäre Datenbank, die Daten veröffentlicht
• Subskribent-eine sekundäre Datenbank, die replizierte Daten empfängt
• Distributor-Ein Server, der Metadaten und Transaktionen für die transaktionsorientierte Replikation speichert und im Idealfall ein separater Server für den Publisher oder Subskribenten ist.

Der Prozess funktioniert wie folgt:

• Bei der transaktionsorientierten Replikation wird eine Momentaufnahme der Objekte und Daten in der Veröffentlichungsdatenbank erstellt und an die Subskribentendatenbank gesendet. Die Momentaufnahme wird auf die Abonnentendatenbank angewendet.
• Datenänderungen und Schemaänderungen, die beim Bereitsteller vorgenommen wurden, werden in der Reihenfolge an den Subskribenten gesendet, in der sie aufgetreten sind, und in derselben Reihenfolge auf den Subskribenten angewendet.
• Wenn die beiden Datenbanken synchronisiert sind und sich in einem Wartungsfenster befinden:
  • Stoppen Sie den Zugriff auf den Publisher.
  • Stellen Sie sicher, dass die Replikation abgeschlossen ist.
  • Löschen Sie die Subskription.
  • Zugriff auf das aktivieren, was der Abonnent war.
  • Stilllegen des Verlages.

Weitere Informationen finden Sie unter Transaktionsorientierte Replikation .

Datenbankspiegelung

Die Datenbankspiegelung gilt in SQL Server 2012 als veraltet, wird jedoch weiterhin in der Dokumentation zu SQL 2019 referenziert. Informationen hierzu finden Sie unter Datenbankspiegelung in SQL Server. Hier wird die Vollständigkeit der Migrationsmethoden erläutert. Sie sollten diesen Ansatz jedoch sorgfältig untersuchen, wenn Sie ihn in Ihrer Migration einsetzen möchten.

Mit der Datenbankspiegelung in SQL Server können Sie eine Kopie oder Spiegelung einer SQL Server -Datenbank auf einem Standby-Server aufbewahren. Durch die Spiegelung wird sichergestellt, dass immer zwei separate Kopien der Daten vorhanden sind. Im Vergleich zur Protokollübertragung ist die Einrichtung der Datenbankspiegelung etwas komplizierter und hat mehr Einschränkungen. Die Datenbankspiegelung ist einfacher einzurichten, wenn sich beide Server in der Partnerschaft in derselben Windows-Domäne befinden. Ist dies jedoch nicht der Fall, können Sie Zertifikate für Ihre Endpunktauthentifizierung verwenden. Die grundlegenden Schritte für die Migration umfassen Folgendes:

• Konfigurieren Sie die Datenbankspiegelung.
• Stoppen Sie die Anwendungen, die die Principaldatenbanken auf dem primären Server verwenden, nach dem erforderlichen Zeitschnitt.
• Stellen Sie sicher, dass sich jede Datenbank in einem synchronisierten Status befindet.
• Führen Sie eine Übernahme jeder gespiegelten Benutzerdatenbank durch.
• Entfernen Sie die Spiegelungspartnerschaft.
• Leiten Sie die Anwendungen an den neuen Datenbankserver um.
• Den ursprünglichen Server stilllegen.

Protokollübertragung

Die SQL Server -Protokollübertragung kann auf Datenbankebene konfiguriert werden. In einem angegebenen Zeitraum wird die SQL Server -Transaktionsprotokollsicherung erstellt und auf den Zielserver kopiert und zurückgeschrieben. Transaktionsprotokolle enthalten ein Protokoll aller Transaktionen, die in einer SQL Server -Datenbank stattfinden. Die SQL Server -Instanz, von der die Transaktionsprotokollsicherung versendet wird, wird als primäre Instanz und die SQL Server -Instanz, an die die Transaktionsprotokollsicherung übertragen wird, als sekundäre Instanz bezeichnet. Vor der Konfiguration der Protokollübertragung muss sich die Datenbank im vollständigen Wiederherstellungsmodell oder im Modus für Massenprotokollierung befinden.

Die Sicherungseinstellungen des SQL Server -Transaktionsprotokolls ermöglichen die Adressierung an einen Netzpfad und der Sicherungsjob-Scheduler kann definiert werden, um einen Sicherungsjob auszuführen. Standardmäßig wird ein Sicherungsjob alle 15 Minuten ausgeführt. Sobald die Datenbanksicherung geplant ist, erstellt sie eine Gesamtsicherung der Datenbank, die auf dem sekundären Server wiederhergestellt werden muss. Während der Wartungszeiten kann ein Wechsel vom primären Server zum sekundären Server durchgeführt werden, die Protokollübertragung inaktiviert und der primäre Server stillgelegt werden.

Immer in Verfügbarkeitsgruppen

SQL Server Always On-Verfügbarkeitsgruppen bieten Hochverfügbarkeitslösungen und Disaster-Recovery-Lösungen, die in Versionen von SQL Server 2012 und höher verfügbar sind. Dieses Feature kann verwendet werden, um Ihre vorhandenen SQL Server -Datenbanken mit minimaler Ausfallzeit auf IBM Cloud zu migrieren. Wenn Sie über einen vorhandenen Windows-Server-Failover-Cluster mit Verfügbarkeitsgruppen mit "Immer auf" verfügen, können Sie den Cluster während der Migration vorübergehend erweitern, indem Sie eine zusätzliche sekundäre Replik mit asynchroner Replikation erstellen. Während eines Wartungsfensters kann eine manuelle Funktionsübernahme durchgeführt werden.

Immer in verteilten Verfügbarkeitsgruppen

Eine SQL Server Always On-Verfügbarkeitsgruppe umfasst zwei verschiedene Verfügbarkeitsgruppen. Jede Verfügbarkeitsgruppe ist in zwei verschiedenen Windows Server Failover Clusters (WSFC) konfiguriert, einem an der Quellenposition und einem in IBM Cloud VPC. Die Betriebssysteme und SQL Server -Versionen müssen nicht identisch sein, solange sie WSFC und Verfügbarkeitsgruppen unterstützen. Diese Migrationsmethode eignet sich zum erneuten Hosten geschäftskritischer SQL Server -Datenbanken. Die Architektur der verteilten Verfügbarkeitsgruppe ist eine effiziente Datenübertragungsmethode, da das primäre Replikat nur Daten des Weiterleitungsreplikats in IBM Cloudüberträgt und der Weiterleitungsserver für die Synchronisation von Daten mit den sekundären Replikaten in IBM Cloudverantwortlich ist. Eine typische Architektur sieht wie folgt aus:

• Der WSFC-Quellencluster hostet eine Verfügbarkeitsgruppe "Immer aktiv", verfügt über zwei Knoten und verwendet synchrone Replikation mit automatischem Failover.
• Der WSFC-Zielcluster, der in IBM Cloud gehostet wird, verfügt über eine Verfügbarkeitsgruppe "Immer aktiv", verfügt über zwei Knoten, einen in einer Verfügbarkeitszone (AZ) in einer Region mit mehreren Zonen (MZR) und verwendet die synchrone Replikation mit automatischem Failover.
• Eine Netzverbindung, in der Regel eine Direktverbindung, verbindet die beiden Cluster.
• Es wird eine immer verteilte Verfügbarkeitsgruppe konfiguriert, und die Daten werden vom primären Replikat des WSFC-Quellenclusters an das primäre Replikat (den Forwarder) im WSFC-Zielcluster übertragen.
• Der Weiterleitungsserver ist für die Übertragung von Daten an das sekundäre Replikat im WSFC-Zielcluster verantwortlich.

Während eines Wartungsfensters kann eine manuelle Funktionsübernahme durchgeführt werden, um das Cut-over zu aktivieren, und die Primärdatenbank in der Ziel-WSFC wird zur Quelle für Schreib-/Lesezugriff von den Anwendungen.

Weitere Informationen finden Sie unter Verteilte Verfügbarkeitsgruppen.