Nota

Distribuisci gruppi di disponibilità Always On distribuiti da Microsoft SQL Server per DR su OCI

Introduzione

Distributed Always On availability group (gruppo di disponibilità distribuita) è una potente funzione di Microsoft SQL Server che estende le funzionalità del gruppo di disponibilità tradizionale per SQL Server.

I gruppi di disponibilità distribuiti ti consentono di creare una soluzione di disaster recovery (DR) che si estende su più cluster WSFC (Windows Server Failover Clusters) in esecuzione in diverse aree di Oracle Cloud Infrastructure (OCI).

Ciò consente di ottenere livelli più elevati di disponibilità, funzionalità di disaster recovery e distribuzione geografica per i database SQL Server critici in esecuzione su OCI.

Esclusioni per questo tutorial

In questa esercitazione non verrà illustrata la creazione passo per passo dei singoli gruppi di disponibilità Microsoft SQL Server Always On. Per ulteriori informazioni, vedere Distribuire i gruppi di disponibilità Always On Microsoft SQL Server per HA e DR su OCI.

Fare riferimento alla seguente documentazione Microsoft ufficiale:

Obiettivi

Prerequisiti

Task 1: Crea gruppo disponibilità distribuita

Creare un gruppo di disponibilità distribuita (distributed-aoag) composto dai due gruppi di disponibilità Always On già in esecuzione.

Come già accennato, si suppone che due gruppi di disponibilità Always On indipendenti siano già attivi e in esecuzione in due region OCI diverse.

Il secondo gruppo di disponibilità Sempre attivo (marseille-aoag), quello in standby, non deve avere database associati. Pertanto, praticamente il secondo gruppo di disponibilità Sempre attivo deve essere vuoto prima della creazione del gruppo di disponibilità distribuito, quindi senza alcun database di disponibilità associato. È possibile creare il secondo gruppo di disponibilità Sempre attivo, come al solito, con un database iniziale associato e successivamente è possibile rimuovere questo database utilizzato solo per creare il secondo gruppo di disponibilità Sempre attivo. Questo perché l'interfaccia grafica non è possibile creare un gruppo di disponibilità Sempre attivo con qualsiasi database associato.

  1. Creare un gruppo di disponibilità distribuito nel primo gruppo di disponibilità Sempre attivo.

    Connettersi a SQL Server sul primo server (nodo sql-srv1 del sito di Parigi in questo esempio) ed eseguire i comandi SQL riportati di seguito.

    Nota:

    • I nomi del listener sono paris-sql-list e mars-sql-list.

    • Porta TCP da utilizzare, 5022 è la porta dell'endpoint e deve essere utilizzata. Di solito è diverso dalla porta del listener (1433).

    • I nomi dei gruppi di disponibilità devono corrispondere esattamente ai nomi utilizzati dal gruppo di disponibilità Always On già in esecuzione.

    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. Eseguire il join al gruppo di disponibilità distribuito nel secondo gruppo di disponibilità Sempre attivo.

    Connettersi a SQL Server sul primo server del secondo gruppo di disponibilità Always On (server sql-srv3 del sito Marsiglia) ed eseguire i seguenti comandi SQL.

    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. È importante comprendere che, a differenza dei gruppi di disponibilità tradizionali, i gruppi di disponibilità distribuita non richiedono gruppi di risorse o ruoli nel WSFC. Tutti i metadati vengono gestiti all'interno di SQL Server. Ciò significa che anche SQL Server Management Studio non visualizza direttamente i nomi dei database nel gruppo di disponibilità distribuito.

    Per visualizzare queste informazioni, eseguire il seguente script Transact-SQL.

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

    immagine

Nota: per soddisfare la potenziale latenza di rete tra le aree, è stato configurato il gruppo di disponibilità Always On primario e secondario con replica a commit asincrono. Ciò riduce al minimo il sovraccarico delle prestazioni nel database primario. All'interno di ciascun gruppo di disponibilità Always On, abbiamo scelto la replica a commit sincrono tra le repliche per garantire l'alta disponibilità. Tuttavia, per il failover tra le repliche di commit asincrono (in caso di gruppo di disponibilità distribuito), la riduzione della perdita di dati richiede un passaggio temporaneo alla modalità di commit sincrono prima di avviare il failover. Per failover_mode, l'unica modalità disponibile per il gruppo di disponibilità distribuita è manuale.

Task 2: procedura di failover per il gruppo di disponibilità distribuita

In questo task si parlerà di failover tra i due gruppi di disponibilità Always On. La procedura di failover del database è composta dai seguenti semplici passi e controlli.

Seguire i passi indicati:

  1. Eseguire gli script riportati di seguito per verificare se la sincronizzazione è corretta, prima sull'SQL primario corrente del sito primario e quindi sull'SQL primario del sito secondario.

    I risultati eseguiti devono essere CONNECTED_STATE = CONNECTED e SYNCHRONIZATION_HEALTH = HEALTHY.

    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

    immagine

    immagine

  2. Modificare la modalità di disponibilità. Eseguire lo script seguente prima sull'SQL Server primario corrente del sito primario e quindi sull'SQL Server primario del sito secondario.

    --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. Per evitare perdite di dati, verificare i risultati di questo passo. Lo stato deve essere SYNCHRONIZED e last_hardened_lsn deve corrispondere per ogni database sia nel database primario globale che nell'inoltro.

    -- 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;

    immagine

    immagine

  4. Ora è possibile impostare REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT su SQL Server primario corrente nel sito primario corrente.

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

    Ora è possibile modificare il ruolo del gruppo di disponibilità Sempre attivo principale da primario a secondario.

    --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);

    immagine

  5. Modificare il ruolo del gruppo di disponibilità Sempre attivo secondario da secondario a primario. Lo script seguente eseguirà questa modifica del ruolo, abilitando il database per le operazioni di lettura o scrittura. Inoltre, i ruoli dei gruppi di disponibilità Sempre attivo all'interno del gruppo di disponibilità distribuito verranno aggiornati di conseguenza.

    --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;

    Eseguire lo script seguente per controllare lo stato.

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

    immagine

    immagine

  6. Ora nel nuovo SQL Server primario, annullare l'impostazione di REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

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

    Ripristinare la modalità di disponibilità alla modalità standard eseguendo lo script seguente sia sui siti primari che su quelli secondari.

    --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 
);

Task 3: procedura di failback per il gruppo di disponibilità distribuito Sempre su

Per ripristinare Parigi come sito principale e Marsiglia come sito secondario, è sufficiente eseguire un nuovo switchover per invertire la sincronizzazione, come descritto nel Task 2.

Conferme

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti gratuiti sulla formazione su Oracle Learning YouTube channel. Inoltre, visita education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.

Per la documentazione del prodotto, visita l'Oracle Help Center.