Observação:

Implantar Grupos de Disponibilidade Always On Distribuídos do Microsoft SQL Server para DR no OCI

Introdução

O grupo de disponibilidade Distributed Always On (Grupo de disponibilidade distribuído) é um recurso poderoso no Microsoft SQL Server que estende os recursos do grupo de disponibilidade tradicional para o SQL Server.

Os grupos de disponibilidade distribuídos permitem criar uma solução de DR (Recuperação de Desastre) que abrange vários WSFCs (Clusters de Failover) do Windows Server em execução em diferentes regiões do OCI (Oracle Cloud Infrastructure).

Isso permite que você alcance níveis mais altos de disponibilidade, recursos de recuperação de desastres e distribuição geográfica para seus bancos de dados críticos do SQL Server em execução na OCI.

Exclusões deste Tutorial

Neste tutorial, não abordaremos a criação passo a passo dos únicos grupos de disponibilidade do Microsoft SQL Server Always On. Para obter mais informações, consulte Implantar Grupos de Disponibilidade Always On do Microsoft SQL Server para HA e DR na OCI.

Consulte a seguinte documentação oficial da Microsoft:

Objetivos

Pré-requisitos

Tarefa 1: Criar Grupo de Disponibilidade Distribuído

Crie um grupo de disponibilidade distribuída (distributed-aoag) composto pelos dois grupos de disponibilidade subjacentes já em execução Sempre Ativo.

Como já mencionado, assumimos que dois grupos de disponibilidade Always On independentes já estão ativos e em execução em duas regiões OCI diferentes.

O segundo grupo de disponibilidade Sempre Ativo (marseille-aoag), o stand-by, não precisa ter bancos de dados associados; portanto, praticamente o segundo grupo de disponibilidade Sempre Ativo precisa estar vazio antes da criação do grupo de disponibilidade distribuído, portanto, sem nenhum banco de dados de disponibilidade associado. Você pode criar o segundo grupo de disponibilidade Sempre Ativo como de costume com um banco de dados inicial associado e, depois disso, pode remover esse banco de dados que foi usado apenas para criar o segundo grupo de disponibilidade Sempre Ativo. Isso ocorre porque a interface gráfica não é possível criar um grupo de disponibilidade Sempre Ativo com qualquer banco de dados associado.

  1. Crie um grupo de disponibilidade distribuído no primeiro grupo de disponibilidade Sempre Ativo.

    Conecte-se ao SQL Server no primeiro servidor (nó sql-srv1 do site de Paris neste exemplo) e execute os comandos SQL a seguir.

    Observação:

    • Os nomes do listener são paris-sql-list e mars-sql-list.

    • A porta TCP a ser usada, 5022 é a porta do ponto final e deve ser usada. Geralmente, isso é diferente da porta do listener (1433).

    • Os nomes do grupo de disponibilidade devem ser exatamente os nomes usados pelo grupo de disponibilidade Always On já em execução.

    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. Junte-se ao grupo de disponibilidade distribuído no segundo grupo de disponibilidade Always On.

    Conecte-se ao SQL Server no primeiro servidor do segundo grupo de disponibilidade Always On (servidor do site Marselha sql-srv3) e execute os comandos SQL a seguir.

    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 entender que, ao contrário dos grupos de disponibilidade tradicionais, os grupos de disponibilidade distribuídos não exigem grupos de recursos ou funções no WSFC. Todos os metadados são gerenciados no SQL Server. Isso significa que mesmo o SQL Server Management Studio não exibe diretamente os nomes dos bancos de dados no grupo de disponibilidade distribuída.

    Para exibir essas informações, execute o script Transact-SQL a seguir.

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

Observação: Para acomodar a latência de rede potencial entre regiões, configuramos o grupo de disponibilidade Always On principal e secundário com replicação de commit assíncrono. Isso minimiza a sobrecarga de desempenho no banco de dados principal. Dentro de cada grupo de disponibilidade Always On, optamos pela replicação de commit síncrono entre réplicas para garantir alta disponibilidade. No entanto, para failover entre réplicas de commit assíncrono (no caso de grupo de disponibilidade distribuído), a redução da perda de dados requer uma alternância temporária para o modo de commit síncrono antes de iniciar o failover. Para o failover_mode, o único modo disponível para o grupo de disponibilidade distribuída é manual.

Tarefa 2: Procedimento de Failover para Grupo de Disponibilidade Distribuído

Nesta tarefa, falaremos sobre failover entre os dois grupos de disponibilidade Always On. O procedimento de failover do banco de dados é composto pelas seguintes etapas e verificações fáceis.

Siga as etapas:

  1. Execute os scripts a seguir para verificar se a sincronização está correta, primeiro no SQL principal atual do site principal atual e depois no SQL principal do site secundário.

    Os resultados executados precisam ser 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

    image

    image

  2. Altere o modo de disponibilidade. Execute o script a seguir primeiro no SQL Server principal atual do site principal atual e, em seguida, no SQL Server principal do site secundário.

    --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 garantir que não haja perda de dados, verifique os resultados desta etapa. O status deve ser SYNCHRONIZED e last_hardened_lsn deve corresponder para cada banco de dados no principal global e no encaminhador.

    -- 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. Agora você está pronto para definir REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT no SQL Server principal atual no site principal atual.

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

    E agora você está pronto para alterar a função do grupo de disponibilidade Always On principal de principal para secundário.

    --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. Altere a função do grupo de disponibilidade Always On secundário de secundário para principal. O script a seguir executará essa alteração de atribuição, ativando o banco de dados para operações de leitura ou gravação. Além disso, as funções dos grupos de disponibilidade Sempre Ativo dentro do grupo de disponibilidade distribuído também serão atualizadas de acordo.

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

    Execute o seguinte script para verificar o status.

    --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. Agora, no novo SQL Server principal, cancele a definição de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

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

    Altere o modo de disponibilidade de volta para o modo padrão executando o script a seguir nos sites principal e secundário.

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

Tarefa 3: Procedimento de Failback para Distribuído Sempre no Grupo de Disponibilidade

Para restaurar Paris como o site principal e Marselha como o site secundário, basta executar um novo switchover para reverter a sincronização, conforme descrito na Tarefa 2.

Confirmações

Mais Recursos de Aprendizagem

Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal Oracle Learning YouTube. Além disso, visite education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.

Para obter a documentação do produto, visite o Oracle Help Center.