Note:

Despliegue de grupos de disponibilidad Always On distribuidos de Microsoft SQL Server para la recuperación ante desastres en OCI

Introducción

Distributed Always On Availability Group (Distributed Availability Group) es una potente función de Microsoft SQL Server que amplía las capacidades del grupo de disponibilidad tradicional para SQL Server.

Los grupos de disponibilidad distribuida permiten crear una solución de recuperación ante desastres (DR) que abarque varios clusters de failover de Windows Server (WSFC) que se ejecuten en distintas regiones de Oracle Cloud Infrastructure (OCI).

Esto le permite lograr niveles más altos de disponibilidad, capacidades de recuperación ante desastres y distribución geográfica para sus bases de datos críticas de SQL Server que se ejecutan en OCI.

Exclusiones para este tutorial

En este tutorial, no trataremos paso a paso la creación de los grupos de disponibilidad Always On de Microsoft SQL Server. Para obtener más información, consulte Despliegue de grupos de disponibilidad Always On de Microsoft SQL Server para alta disponibilidad y recuperación ante desastres en OCI.

Consulte la siguiente documentación oficial de Microsoft:

Objetivos

Requisitos

Tarea 1: Crear grupo de disponibilidad distribuida

Cree un grupo de disponibilidad distribuida (distributed-aoag) compuesto por los dos grupos de disponibilidad Always On que ya se están ejecutando.

Como ya se ha mencionado, suponemos que dos grupos de disponibilidad Always On independientes ya están activos y en ejecución en dos regiones de OCI diferentes.

El segundo grupo de disponibilidad Always On (marseille-aoag), el en espera, no necesita tener ninguna base de datos asociada, por lo que prácticamente el segundo grupo de disponibilidad Always On debe estar vacío antes de la creación del grupo de disponibilidad distribuido, por lo que sin ninguna base de datos de disponibilidad asociada. Puede crear el segundo grupo de disponibilidad Always On como de costumbre con una base de datos inicial asociada y, a continuación, puede eliminar esta base de datos que solo se ha utilizado para crear el segundo grupo de disponibilidad Always On. Esto se debe a que la interfaz gráfica no es posible crear un grupo de disponibilidad Always On con ninguna base de datos asociada.

  1. Cree un grupo de disponibilidad distribuido en el primer grupo de disponibilidad Always On.

    Conéctese a SQL Server en el primer servidor (el nodo sql-srv1 del sitio de París en este ejemplo) y ejecute los siguientes comandos SQL.

    Nota:

    • Los nombres del listener son paris-sql-list y mars-sql-list.

    • Puerto TCP que se va a utilizar, 5022 es el puerto del punto final y se debe utilizar. Normalmente es diferente del puerto del listener (1433).

    • Los nombres de grupo de disponibilidad deben ser exactamente los nombres utilizados por el grupo de disponibilidad Always On que ya se está ejecutando.

    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. Únase al grupo de disponibilidad distribuido en el segundo grupo de disponibilidad Always On.

    Conéctese a SQL Server en el primer servidor del segundo grupo de disponibilidad Always On (servidor sql-srv3 del sitio de Marsella) y ejecute los siguientes comandos 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. Es importante comprender que, a diferencia de los grupos de disponibilidad tradicionales, los grupos de disponibilidad distribuida no necesitan grupos de recursos ni roles en el WSFC. Todos los metadatos se gestionan dentro de SQL Server. Esto significa que incluso SQL Server Management Studio no muestra directamente los nombres de las bases de datos en el grupo de disponibilidad distribuida.

    Para ver esta información, ejecute el siguiente 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

    image

Nota: Para admitir una posible latencia de red entre regiones, hemos configurado el grupo de disponibilidad Always On principal y secundario con replicación de confirmación asíncrona. Esto minimiza la sobrecarga de rendimiento en la base de datos primaria. Dentro de cada grupo de disponibilidad Always On, hemos optado por la replicación de confirmación síncrona entre réplicas para garantizar una alta disponibilidad. Sin embargo, para la conmutación por error entre réplicas de confirmación asíncrona (en el caso de un grupo de disponibilidad distribuido), la reducción de la pérdida de datos requiere un cambio temporal al modo de confirmación síncrona antes de iniciar la conmutación por error. Para failover_mode, el único modo disponible para el grupo de disponibilidad distribuida es manual.

Tarea 2: Procedimiento de failover para grupo de disponibilidad distribuida

En esta tarea, hablaremos sobre el failover entre los dos grupos de disponibilidad Always On. El procedimiento de failover de la base de datos se compone de los siguientes sencillos pasos y comprobaciones.

Realice los pasos:

  1. Ejecute los siguientes scripts para comprobar si la sincronización es correcta, primero en el SQL principal actual del sitio principal actual y, a continuación, en el SQL principal del sitio secundario.

    Los resultados ejecutados deben ser CONNECTED_STATE = CONNECTED y 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

    image

    image

  2. Cambie el modo de disponibilidad. Ejecute primero el siguiente script en el SQL Server principal actual del sitio principal actual y, a continuación, en el SQL Server principal del sitio secundario.

    --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. Para garantizar que no se pierdan datos, verifique los resultados de este paso. El estado debe ser SYNCHRONIZED y last_hardened_lsn debe coincidir para cada base de datos tanto en la base de datos principal global como en el reenviador.

    -- 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. Ahora está listo para definir REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT en el SQL Server principal actual en el sitio principal actual.

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

    Y ahora está listo para cambiar el rol del grupo de disponibilidad Always On principal de principal a secundario.

    --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. Cambie el rol del grupo de disponibilidad Always On secundario de secundario a principal. La siguiente secuencia de comandos realizará este cambio de rol, activando la base de datos para operaciones de lectura o escritura. Además, los roles de los grupos de disponibilidad Always On del grupo de disponibilidad distribuido también se actualizarán según corresponda.

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

    Ejecute el siguiente script para comprobar el estado.

    --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. Ahora, en el nuevo SQL Server principal, anule la definición de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

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

    Vuelva a cambiar el modo de disponibilidad al modo estándar ejecutando el siguiente script en los sitios principal y secundario.

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

Tarea 3: Procedimiento de failback para el grupo de disponibilidad Always On distribuido

Para restaurar París como el sitio principal y Marsella como el sitio secundario, simplemente realice un nuevo switchover para revertir la sincronización, como se describe en la Tarea 2.

Agradecimientos

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de formación gratuita en el canal YouTube de Oracle Learning. Además, visita education.oracle.com/learning-explorer para convertirte en un Oracle Learning Explorer.

Para obtener documentación sobre el producto, visite Oracle Help Center.