Hinweis:

Bereitstellen von Microsoft SQL Server Distributed Always On Availability Groups für DR auf OCI

Einführung

Verteilte Verfügbarkeitsgruppe "Immer verfügbar" (Verteilte Verfügbarkeitsgruppe) ist ein leistungsstarkes Feature in Microsoft SQL Server, das die Funktionen der traditionellen Verfügbarkeitsgruppe für SQL Server erweitert.

Mit verteilten Verfügbarkeitsgruppen können Sie eine Disaster Recovery-(DR-)Lösung erstellen, die mehrere Windows Server Failover Cluster (WSFCs) umfasst, die in verschiedenen Oracle Cloud Infrastructure-(OCI-)Regionen ausgeführt werden.

Auf diese Weise können Sie eine höhere Verfügbarkeit, Disaster Recovery-Funktionen und eine geografische Verteilung für Ihre kritischen SQL Server-Datenbanken erreichen, die auf OCI ausgeführt werden.

Ausschlüsse für dieses Tutorial

In diesem Tutorial werden wir nicht Schritt für Schritt die Erstellung der einzelnen Microsoft SQL Server Always On-Verfügbarkeitsgruppen behandeln. Weitere Informationen finden Sie unter Microsoft SQL Server Always On-Verfügbarkeitsgruppen für HA und DR auf OCI bereitstellen.

Bitte lesen Sie die folgende offizielle Microsoft-Dokumentation:

Ziele

Voraussetzungen

Aufgabe 1: Verteilte Verfügbarkeitsgruppe erstellen

Erstellen Sie eine verteilte Verfügbarkeitsgruppe (distributed-aoag), die aus den beiden zugrunde liegenden, bereits ausgeführten Always On-Verfügbarkeitsgruppen besteht.

Wie bereits erwähnt, gehen wir davon aus, dass zwei unabhängige Always On-Verfügbarkeitsgruppen bereits in zwei verschiedenen OCI-Regionen aktiv sind und ausgeführt werden.

Für die zweite Always On-Verfügbarkeitsgruppe (marseille-aoag), die Standbygruppe, müssen keine Datenbanken verknüpft sein. Daher muss praktisch die zweite Always On-Verfügbarkeitsgruppe leer sein, bevor die verteilte Verfügbarkeitsgruppe erstellt wird, also ohne dass eine Verfügbarkeitsdatenbank verknüpft ist. Sie können die zweite Always On-Verfügbarkeitsgruppe wie gewohnt mit einer verknüpften anfänglichen Datenbank erstellen. Anschließend können Sie diese Datenbank entfernen, die nur zum Erstellen der zweiten Always On-Verfügbarkeitsgruppe verwendet wurde. Dies liegt daran, dass die grafische Benutzeroberfläche keine Always On-Verfügbarkeitsgruppe mit einer verknüpften Datenbank erstellen kann.

  1. Erstellen Sie eine verteilte Verfügbarkeitsgruppe für die erste Verfügbarkeitsgruppe "Immer aktiviert".

    Stellen Sie eine Verbindung zu SQL Server auf dem ersten Server her (in diesem Beispiel Knoten sql-srv1 von Paris), und führen Sie die folgenden SQL-Befehle aus.

    Hinweis:

    • Die Listener-Namen sind paris-sql-list und mars-sql-list.

    • Der zu verwendende TCP-Port, 5022 ist der Port des Endpunkts und muss verwendet werden. Dies unterscheidet sich normalerweise vom Listener-Port (1433).

    • Verfügbarkeitsgruppennamen müssen genau die Namen sein, die von der bereits ausgeführten Always On-Verfügbarkeitsgruppe verwendet werden.

    USE MASTER;
CREATE AVAILABILITY GROUP [distributed-aoag]  
   WITH (DISTRIBUTED)   
   AVAILABILITY GROUP ON  
      'paris-aoag' WITH    
      (   
         LISTENER_URL = 'tcp://paris-sql-list.acme.corp:5022',    
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      ),   
      'marseille-aoag' WITH    
      (   
         LISTENER_URL = 'tcp://mars-sql-list.acme.corp:5022',   
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      );    
GO

  2. Treten Sie der verteilten Verfügbarkeitsgruppe in der zweiten Verfügbarkeitsgruppe "Immer aktiviert" bei.

    Stellen Sie eine Verbindung zu SQL Server auf dem ersten Server der zweiten Always On-Verfügbarkeitsgruppe (Server Marseille-Site sql-srv3) her, und führen Sie die folgenden SQL-Befehle aus.

    USE MASTER;
ALTER AVAILABILITY GROUP [distributed-aoag]   
   JOIN   
   AVAILABILITY GROUP ON  
      'paris-aoag' WITH    
      (   
         LISTENER_URL = 'tcp://paris-sql-list.acme.corp:5022',    
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      ),   
      'marseille-aoag' WITH    
      (   
         LISTENER_URL = 'tcp://mars-sql-list.acme.corp:5022',   
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      );    
GO

  3. Im Gegensatz zu herkömmlichen Verfügbarkeitsgruppen sind für verteilte Verfügbarkeitsgruppen keine Ressourcengruppen oder Rollen in WSFC erforderlich. Alle Metadaten werden in SQL Server verwaltet. Dies bedeutet, dass selbst SQL Server Management Studio die Namen von Datenbanken in der verteilten Verfügbarkeitsgruppe nicht direkt anzeigt.

    Um diese Informationen anzuzeigen, führen Sie das folgende Transact-SQL-Skript aus.

    --View metadata and status of the Distributed Availability Group
SELECT r.replica_server_name, r.endpoint_url,
rs.connected_state_desc, rs.role_desc, rs.operational_state_desc,
rs.recovery_health_desc,rs.synchronization_health_desc,
r.availability_mode_desc, r.failover_mode_desc
FROM sys.dm_hadr_availability_replica_states rs 
INNER JOIN sys.availability_replicas r
ON rs.replica_id=r.replica_id
ORDER BY r.replica_server_name

    image

Hinweis: Um potenzielle Netzwerklatenzzeiten zwischen Regionen zu berücksichtigen, haben wir die primäre und die sekundäre Always On-Verfügbarkeitsgruppe mit asynchroner Commit-Replikation konfiguriert. Dadurch wird der Performance-Overhead in der Primärdatenbank minimiert. Innerhalb jeder Always On-Verfügbarkeitsgruppe haben wir uns für die synchrone Commit-Replikation zwischen Replikaten entschieden, um High Availability sicherzustellen. Bei einem Failover zwischen asynchronen Commit-Replikaten (bei verteilter Verfügbarkeitsgruppe) erfordert die Reduzierung des Datenverlusts jedoch einen temporären Wechsel in den Modus für synchrones Commit, bevor das Failover initiiert wird. Für failover_mode ist der einzige verfügbare Modus für die verteilte Verfügbarkeitsgruppe manuell.

Aufgabe 2: Failover-Prozedur für verteilte Verfügbarkeitsgruppe

In dieser Aufgabe wird über das Failover zwischen den beiden Always On-Verfügbarkeitsgruppen gesprochen. Die Failover-Prozedur der Datenbank besteht aus den folgenden einfachen Schritten und Prüfungen.

Führen Sie die Schritte aus:

  1. Führen Sie die folgenden Skripte aus, um zu prüfen, ob die Synchronisierung in Ordnung ist, zuerst auf der aktuell primären SQL der aktuellen primären Site und dann auf der primären SQL der sekundären Site.

    Die ausgeführten Ergebnisse müssen CONNECTED_STATE = CONNECTED und SYNCHRONIZATION_HEALTH = HEALTHY sein.

    select ag.name, ag.is_distributed, ar.replica_server_name, ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc, 
   ars.operational_state_desc, ars.synchronization_health_desc from sys.availability_groups ag  
   join sys.availability_replicas ar on ag.group_id=ar.group_id
   left join sys.dm_hadr_availability_replica_states ars
   on ars.replica_id=ar.replica_id
   where ag.is_distributed=1
GO

    image

    image

  2. Ändern Sie den Verfügbarkeitsmodus. Führen Sie das folgende Skript zuerst auf dem aktuell primären SQL Server der aktuell primären Site und dann auf dem primären SQL Server der sekundären Site aus.

    --Run this first on the primary replica of the primary AOAG and then again on the secondary AOAG
USE MASTER;     
ALTER AVAILABILITY GROUP [distributed-aoag]     
MODIFY 
AVAILABILITY GROUP ON
'paris-aoag' WITH 
( 
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT 
), 
'marseille-aoag' WITH     
( 
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT 
);

  3. Um sicherzustellen, dass keine Daten verloren gehen, prüfen Sie die Ergebnisse dieses Schritts. Der Status muss SYNCHRONIZED lauten, und last_hardened_lsn muss für jede Datenbank sowohl auf der globalen Primärdatenbank als auch auf dem Forwarder übereinstimmen.

    -- Run this query on the Global Primary and the forwarder
-- Check the results to see if synchronization_state_desc is SYNCHRONIZED, and the last_hardened_lsn is the same per database on both the global primary and forwarder 
-- If not rerun the query on both side every 5 seconds until it is the case
--
SELECT ag.name
         , drs.database_id
         , db_name(drs.database_id) as database_name
         , drs.group_id
         , drs.replica_id
         , drs.synchronization_state_desc
         , drs.last_hardened_lsn  
FROM sys.dm_hadr_database_replica_states drs 
INNER JOIN sys.availability_groups ag on drs.group_id = ag.group_id;

    image

    image

  4. Jetzt können Sie REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf dem aktuellen primären SQL Server auf der aktuellen primären Site festlegen.

    --Run this script into Primary AOAG
USE MASTER;
ALTER AVAILABILITY GROUP [distributed-aoag]
SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);

    Jetzt können Sie die Rolle der primären Verfügbarkeitsgruppe "Immer verfügbar" von "Primär" in "Sekundär" ändern.

    --Run this script into Primary AOAG, this will terminate client applications connected to the primary replica of the primary AOAG
USE MASTER;
ALTER AVAILABILITY GROUP [distributed-aoag] SET (ROLE = SECONDARY);

    image

  5. Ändern Sie die Rolle der sekundären Verfügbarkeitsgruppe "Immer aktiviert" von "Sekundär" in "Primär". Das folgende Skript führt diese Rollenänderung durch und aktiviert die Datenbank für Lese- oder Schreibvorgänge. Außerdem werden die Rollen der Verfügbarkeitsgruppen "Immer aktiviert" innerhalb der verteilten Verfügbarkeitsgruppe entsprechend aktualisiert.

    --Run this script into Secondary AOAG, this will terminate client applications connected to the primary replica of the primary AOAG
ALTER AVAILABILITY GROUP [distributed-aoag] FORCE_FAILOVER_ALLOW_DATA_LOSS;

    Führen Sie das folgende Skript aus, um den Status zu prüfen.

    --check the status on the new primary (formerly standby site)
select ag.name, ag.is_distributed, ar.replica_server_name, ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc, 
   ars.operational_state_desc, ars.synchronization_health_desc from sys.availability_groups ag  
   join sys.availability_replicas ar on ag.group_id=ar.group_id
   left join sys.dm_hadr_availability_replica_states ars
   on ars.replica_id=ar.replica_id
   where ag.is_distributed=1
GO

    image

    image

  6. Heben Sie nun auf dem neuen primären SQL Server die Einstellung REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf.

    --Run this script into Primary AOAG
ALTER AVAILABILITY GROUP [distributed-aoag] 
SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);

    Ändern Sie den Verfügbarkeitsmodus wieder in den Standardmodus, indem Sie das folgende Skript sowohl auf der primären als auch auf der sekundären Site ausführen.

    --Run this first on the primary replica of the primary AOAG and then again on the secondary AOAG
ALTER AVAILABILITY GROUP [distributed-aoag]     
MODIFY 
AVAILABILITY GROUP ON
'paris-aoag' WITH 
( 
   AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT 
), 
'marseille-aoag' WITH     
( 
   AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT 
);

Aufgabe 3: Failback-Prozedur für verteilte Always On-Verfügbarkeitsgruppe

Um Paris als primären Standort und Marseille als sekundären Standort wiederherzustellen, führen Sie einfach einen neuen Switchover aus, um die Synchronisierung umzukehren, wie in Aufgabe 2 beschrieben.

Danksagungen

Weitere Lernressourcen

Sehen Sie sich andere Übungen zu docs.oracle.com/learn an, oder greifen Sie im Oracle Learning YouTube-Channel auf weitere kostenlose Lerninhalte zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.