Implantando o Microsoft SQL Server para recuperação de desastres multirregional

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Compreendendo a recuperação de desastres

Em Google Cloud, a recuperação de desastres (DR) trata de fornecer continuidade de processamento, especialmente quando uma região falha ou se torna inacessível. Para sistemas como um sistema de gerenciamento de banco de dados, você implementa a DR implantando o sistema em pelo menos duas regiões. Com esta configuração, o sistema continua a funcionar se uma região ficar indisponível.

Recuperação de desastres do sistema de banco de dados

O processo de disponibilização de um banco de dados secundário quando a instância do banco de dados primário falha é chamado de recuperação de desastres de banco de dados (ou DR de banco de dados ). Para obter uma discussão detalhada sobre esse conceito, consulte Recuperação de desastres para Microsoft SQL Server . Idealmente, o estado do banco de dados secundário é consistente com o banco de dados primário no momento em que o primário fica indisponível ou o banco de dados secundário está faltando apenas um pequeno conjunto de transações recentes do banco de dados primário.

Arquitetura de recuperação de desastres

Para o Microsoft SQL Server, o diagrama a seguir mostra uma arquitetura mínima que dá suporte à recuperação de desastres do banco de dados.

Figura 1. Arquitetura padrão de recuperação de desastres com Microsoft SQL Server.

Essa arquitetura funciona da seguinte maneira:

• Duas instâncias do Microsoft SQL Server (uma instância primária e uma instância em espera) estão localizadas na mesma região (R1), mas em zonas diferentes (zonas A e B). As duas instâncias em R1 coordenam seus estados usando o modo de confirmação síncrona. O modo síncrono é usado porque oferece suporte à alta disponibilidade e mantém um estado de dados consistente.
• Uma instância do Microsoft SQL Server (a instância secundária ou de recuperação de desastres) está localizada em uma segunda região (R2). Para DR, a instância secundária em R2 sincroniza com a instância primária em R1 usando o modo de confirmação assíncrona. O modo assíncrono é usado devido ao seu desempenho (ele não retarda o processamento de commit na instância primária).

No diagrama anterior, a arquitetura mostra um grupo de disponibilidade. O grupo de disponibilidade, se usado com um ouvinte, fornecerá a mesma cadeia de conexão aos clientes se os clientes forem atendidos pelo seguinte:

• A instância primária
• A instância de espera (após uma falha de zona)
• A instância secundária (após uma falha na região e após a instância secundária se tornar a nova instância primária)

Em uma variante da arquitetura acima, você implanta as duas instâncias que estão na primeira região (R1) na mesma zona. Esta abordagem pode melhorar o desempenho, mas não está altamente disponível; uma interrupção de zona única pode ser necessária para iniciar o processo de DR.

Processo básico de recuperação de desastres

O processo de DR começa quando uma região fica indisponível e o banco de dados primário faz failover para retomar o processamento em outra região operacional. O processo de DR prescreve as etapas operacionais que devem ser executadas, manual ou automaticamente, para mitigar a falha da região e estabelecer uma instância primária em execução em uma região disponível.

Um processo básico de DR de banco de dados consiste nas seguintes etapas:

1. A primeira região (R1), que está executando a instância do banco de dados primário, fica indisponível.
2. A equipe de operações reconhece e reconhece formalmente o desastre e decide se um failover é necessário.
3. Se um failover for necessário, a instância de banco de dados secundária na segunda região (R2) se tornará a nova instância primária.
4. Os clientes retomam o processamento no novo banco de dados primário e acessam a instância primária em R2.

Embora esse processo básico estabeleça novamente um banco de dados primário funcional, ele não estabelece uma arquitetura de DR completa, onde o novo primário tenha uma instância de banco de dados de espera e uma secundária.

Processo completo de recuperação de desastres

Um processo completo de DR estende o processo básico de DR adicionando etapas para estabelecer uma arquitetura completa de DR após um failover. O diagrama a seguir mostra uma arquitetura completa de DR de banco de dados.

Figura 2. Recuperação de desastres com região primária indisponível (R1).

Esta arquitetura completa de DR de banco de dados funciona da seguinte maneira:

1. A primeira região (R1), que está executando a instância do banco de dados primário, fica indisponível.
2. A equipe de operações reconhece e reconhece formalmente o desastre e decide se um failover é necessário.
3. Se um failover for necessário, a instância de banco de dados secundária na segunda região (R2) se tornará a instância primária.
4. Outra instância secundária, a nova instância em espera, é criada e iniciada em R2 e adicionada à instância primária. A instância em espera está em uma zona diferente da instância primária. O banco de dados primário agora consiste em duas instâncias (principal e em espera) altamente disponíveis.
5. Numa terceira região (R3), uma nova instância de banco de dados secundária (standby) é criada e iniciada. Esta instância secundária está conectada de forma assíncrona à nova instância primária em R2. Neste ponto, a arquitetura original de recuperação de desastres está recriada e operacional.

Fallback para uma região recuperada

Depois que a primeira região (R1) for colocada on-line novamente, ela poderá hospedar o novo banco de dados secundário. Se R1 estiver disponível em breve, você poderá implementar a etapa 5 do processo de recuperação completo em R1 em vez de R3 (a terceira região). Neste caso, uma terceira região não é necessária.

O diagrama a seguir mostra a arquitetura se R1 ficar disponível a tempo.

Figura 3. Recuperação de desastres após a região com falha R1 ficar disponível novamente.

Nessa arquitetura, as etapas de recuperação são as mesmas descritas anteriormente em Processo completo de recuperação de desastres , com a diferença de que R1 se torna o local para as instâncias secundárias em vez de R3.

Escolhendo uma edição do SQL Server

Este tutorial oferece suporte às seguintes versões do Microsoft SQL Server:

• SQL Server 2016 Edição Empresarial
• SQL Server 2017 Edição Empresarial
• SQL Server 2019 Edição Empresarial
• SQL Server 2022 Edição Empresarial

O tutorial usa o recurso AlwaysOn Availability Groups no SQL Server.

Se você não precisar de um banco de dados primário do Microsoft SQL Server altamente disponível (HA) e uma única instância de banco de dados for suficiente como primário, você poderá usar as seguintes versões do SQL Server:

• SQL Server 2016 Edição Padrão
• SQL Server 2017 Edição Padrão
• SQL Server 2019 Edição Padrão
• SQL Server 2022 Edição Padrão

As versões 2016, 2017, 2019 e 2022 do SQL Server possuem o Microsoft SQL Server Management Studio instalado na imagem; você não precisa instalá-lo separadamente. No entanto, num ambiente de produção, recomendamos que instale uma instância do Microsoft SQL Server Management Studio numa VM separada em cada região. Se você configurar um ambiente de alta disponibilidade, deverá instalar o Microsoft SQL Server Management Studio uma vez para cada zona para garantir que ele permaneça disponível se outra zona ficar indisponível.

Configurando o Microsoft SQL Server para DR multirregional

Esta seção usa as seguintes imagens para Microsoft SQL Server:

• sql-ent-2016-win-2016 para Microsoft SQL Server 2016 Enterprise Edition
• sql-ent-2017-win-2016 para Microsoft SQL Server 2017 Enterprise Edition
• sql-ent-2019-win-2019 para Microsoft SQL Server 2019 Enterprise Edition
• sql-ent-2022-win-2022 para Microsoft SQL Server 2022 Enterprise Edition

Para obter uma lista completa de imagens, consulte Imagens .

Configurar um cluster de alta disponibilidade de duas instâncias

Para configurar uma arquitetura de DR de banco de dados multirregional para SQL Server, primeiro crie um cluster de alta disponibilidade (HA) de duas instâncias em uma região. Uma instância serve como primária e a outra instância serve como secundária. Para realizar esta etapa, siga as instruções em Configurando grupos de disponibilidade AlwaysOn do SQL Server . Este tutorial usa us-central1 para a região primária (conhecida como R1 ). Antes de começar, revise as seguintes considerações:

• Se você seguiu as etapas em Configurando grupos de disponibilidade AlwaysOn do SQL Server , terá criado duas instâncias do SQL Server na mesma região ( us-central1 ). Você terá implantado a instância primária do SQL Server ( node-1 ) em us-central1-a e uma instância de espera ( node-2 ) em us-central1-b .

• Embora você implemente a arquitetura na Figura 4 para este tutorial, é uma prática recomendada configurar um controlador de domínio em mais de uma zona. Essa abordagem garante que você estabeleça uma arquitetura de banco de dados habilitada para HA e DR. Por exemplo, se ocorrer uma interrupção numa zona, essa zona não se tornará um ponto único de falha para a sua arquitetura implantada.

Figura 4. Arquitetura padrão de recuperação de desastres implementada neste tutorial.

Adicione uma instância secundária para recuperação de desastres

Em seguida, você configura uma terceira instância do SQL Server (uma instância secundária chamada node-3 ) e configura a rede da seguinte maneira:

1. Crie um script especializado para os nós do Cluster de Failover do Windows Server. O script instala o recurso necessário do Windows e cria regras de firewall para WSFC e SQL Server. Ele também formata o disco de dados e cria pastas de dados e log para SQL Server:

   cat << "EOF" > specialize-node.ps1
   
   $ErrorActionPreference = "stop"
   
   # Install required Windows features
   Install-WindowsFeature Failover-Clustering -IncludeManagementTools
   Install-WindowsFeature RSAT-AD-PowerShell
   
   # Open firewall for WSFC
   netsh advfirewall firewall add rule name="Allow SQL Server health check" dir=in action=allow protocol=TCP localport=59997
   
   # Open firewall for SQL Server
   netsh advfirewall firewall add rule name="Allow SQL Server" dir=in action=allow protocol=TCP localport=1433
   
   # Open firewall for SQL Server replication
   netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022
   
   # Format data disk
   Get-Disk |
    Where partitionstyle -eq 'RAW' |
    Initialize-Disk -PartitionStyle MBR -PassThru |
    New-Partition -AssignDriveLetter -UseMaximumSize |
    Format-Volume -FileSystem NTFS -NewFileSystemLabel 'Data' -Confirm:$false
   
   # Create data and log folders for SQL Server
   md d:\Data
   md d:\Logs
   EOF
   

2. Inicialize as seguintes variáveis:

   VPC_NAME=VPC_NAME
   SUBNET_NAME=SUBNET_NAME
   REGION=us-east1
   PD_SIZE=200
   MACHINE_TYPE=n2-standard-8
   

   Onde:

   • VPC_NAME : nome da sua VPC
   • SUBNET_NAME : nome da sua sub-rede para a região us-east1

3. Crie uma instância do SQL Server:

   gcloud compute instances create node-3 \
   --zone $REGION-b \
   --machine-type $MACHINE_TYPE \
   --subnet $SUBNET_NAME \
   --image-family sql-ent-2022-win-2022 \
   --image-project windows-sql-cloud \
   --tags wsfc,wsfc-node \
   --boot-disk-size 50 \
   --boot-disk-type pd-ssd \
   --boot-disk-device-name "node-3" \
   --create-disk=name=node-3-datadisk,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
   --metadata enable-wsfc=true \
   --metadata-from-file=sysprep-specialize-script-ps1=specialize-node.ps1
   

4. Defina uma senha do Windows para a nova instância do SQL Server:

   1. No console do Google Cloud, acesse a página do Compute Engine.

      Acesse o Compute Engine

   2. Na coluna Conectar do cluster node-3 do Compute Engine, selecione a lista suspensa Definir senha do Windows .

   3. Defina o nome de usuário e a senha. Anote-os para uso posterior.

5. Clique em RDP para conectar-se à instância do node-3 .

6. Digite o nome de usuário e a senha da etapa anterior e clique em OK .

7. Adicione a instância ao domínio do Windows:

   1. Clique com o botão direito no botão Iniciar (ou pressione Win+X) e clique em Windows PowerShell (Admin).

   2. Confirme o prompt de elevação clicando em Sim.

   3. Junte o computador ao seu domínio do Active Directory e reinicie:

      Add-Computer -Domain DOMAIN -Restart
      

      Substitua DOMAIN pelo nome DNS do seu domínio do Active Directory.

      Aguarde aproximadamente 1 minuto para que a reinicialização seja concluída.

Adicione a instância secundária ao cluster de failover

Em seguida, você adiciona a instância secundária ( node-3 ) ao cluster de failover do Windows:

1. Conecte-se às instâncias do node-1 ou node-2 usando RDP e faça login como usuário administrador.

2. Abra uma janela do PowerShell como usuário Administrador e defina variáveis ​​para o ambiente de cluster neste tutorial:

   $node3 = "node-3"
   $nameWSFC = "SQLSRV_CLUSTER" # Name of cluster 
   

   Substitua SQLSRV_CLUSTER pelo nome do cluster do SQL Server.

3. Adicione a instância secundária ao cluster:

   Get-Cluster | WHERE Name -EQ $nameWSFC | Add-ClusterNode -NoStorage -Name $node3
   

   Este comando pode demorar um pouco para ser executado. Como o processo pode parar de responder e não retornar automaticamente, pressione Enter de vez em quando.

4. No nó, habilite o recurso de alta disponibilidade AlwaysOn:

   Enable-SqlAlwaysOn -ServerInstance $node3 -Force
   

O nó agora faz parte do cluster de failover.

Adicione a instância secundária ao grupo de disponibilidade existente

Em seguida, adicione a instância do SQL Server (a instância secundária) e o banco de dados ao grupo de disponibilidade:

1. Conecte-se ao node-3 usando a Área de Trabalho Remota . Faça login com sua conta de usuário de domínio.

2. Abra o Gerenciador de configuração do SQL Server .

3. No painel de navegação, selecione Serviços SQL Server

4. Na lista de serviços, clique com o botão direito em SQL Server (MSSQLSERVER) e selecione Propriedades .

5. Em Fazer logon como , altere a conta:

   • Nome da conta : DOMAIN \sql_server onde DOMAIN é o nome NetBIOS do seu domínio do Active Directory.
   • Senha : Digite a senha que você escolheu anteriormente para a conta de domínio sql_server.

6. Clique em OK .

7. Quando solicitado a reiniciar o SQL Server, selecione Sim .

8. Em qualquer um dos três nós de instância node-1 , node-2 ou node-3 , abra o Microsoft SQL Server Management Studio e conecte-se à instância primária node-1 .

   1. Vá para o Explorador de Objetos.
   2. Selecione a lista suspensa Conectar .
   3. Selecione Mecanismo de Banco de Dados .
   4. Na lista suspensa Nome do servidor , selecione node-1 . Se o cluster não estiver listado, insira-o no campo.

9. Clique em Nova consulta .

10. Cole o seguinte comando para adicionar um endereço IP ao ouvinte usado para o nó e clique em Executar :

    ALTER AVAILABILITY GROUP [bookshelf-ag] MODIFY LISTENER 'bookshelf' (ADD IP ('LOAD_BALANCER_IP_ADDRESS', '255.255.255.0'))
    

    Substitua LOAD_BALANCER_IP_ADDRESS pelo endereço IP do balanceador de carga na região us-east1 .

11. No Pesquisador de Objetos, expanda o nó AlwaysOn High Availability e, em seguida, expanda o nó Grupos de Disponibilidade .

12. Clique com o botão direito do mouse no grupo de disponibilidade denominado bookshelf-ag e selecione Adicionar Réplica .

13. Na página Introdução , clique no nó AlwaysOn High Availability e, em seguida, clique no nó Grupos de Disponibilidade .

14. Na página Conectar às réplicas , clique em Conectar para conectar-se à réplica secundária existente node-2 .

15. Na página Especificar Réplicas , clique em Adicionar Réplica e adicione o novo nó node-3 . Não selecione Failover Automático porque o failover automático causa uma confirmação síncrona. Tal configuração ultrapassa fronteiras regionais, o que não recomendamos.

16. Na página Selecionar sincronização de dados , selecione Propagação automática .

    Como não há ouvinte, a página Validação gera um aviso, que você pode ignorar.

17. Conclua as etapas do assistente.

O modo de failover para node-1 e node-2 é automático, enquanto é manual para node-3 . Esta diferença é uma forma de distinguir a alta disponibilidade da recuperação de desastres.

O grupo de disponibilidade agora está pronto. Você configurou dois nós para alta disponibilidade e um terceiro nó para recuperação de desastres.

Simulando uma recuperação de desastres

Nesta seção, você testará a arquitetura de recuperação de desastres deste tutorial e considerará implementações opcionais de DR.

Simule uma interrupção e execute um failover de DR

1. Simule uma falha ou interrupção na região primária:

   1. No Microsoft SQL Server Management Studio em node-1 , conecte-se a node-1 .

   2. Crie uma mesa. Depois de adicionar réplicas em etapas posteriores, verifique se a réplica funciona verificando se esta tabela está presente.

      USE bookshelf
      GO
      CREATE TABLE dbo.TestTable_Before_DR (ID INT NOT NULL)
      GO
      

   3. No Cloud Shell, desligue os dois servidores na região primária us-central1 :

      gcloud compute instances stop node-2 --zone us-central1-b --quiet
      gcloud compute instances stop node-1 --zone us-central1-a --quiet
      

2. No Microsoft SQL Server Management Studio em node-3 , conecte-se a node-3 .

3. Execute um failover e defina o modo de disponibilidade como confirmação síncrona. Forçar um failover é necessário porque o nó está no modo de confirmação assíncrona.

   ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
   GO
   ALTER AVAILABILITY GROUP [bookshelf-ag]
   MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
   GO
   

   Você pode retomar o processamento; node-3 agora é a instância primária.

4. (Opcional) Crie uma nova tabela em node-3 . Depois de sincronizar as réplicas com o novo primário, verifique se esta tabela está replicada para as réplicas.

   USE bookshelf
   GO
   CREATE TABLE dbo.TestTable_After_DR (ID INT NOT NULL)
   GO
   

Embora node-3 seja o primário neste momento, talvez você queira voltar para a região original ou configurar uma nova instância secundária e uma instância de espera para recriar novamente uma arquitetura de DR completa. A próxima seção discute essas opções.

(Opcional) Recrie uma arquitetura de DR que replique completamente as transações

Este caso de uso aborda uma falha na qual todas as transações são replicadas do banco de dados primário para o secundário antes que o primário falhe. Neste cenário ideal, nenhum dado é perdido; o estado do secundário é consistente com o primário no ponto de falha.

Neste cenário, é possível recriar uma arquitetura de DR completa de duas maneiras:

• Volte para o primário original e o modo de espera original (se estiverem disponíveis).
• Crie um novo standby e um secundário para node-3 caso o primário e o standby originais estejam indisponíveis.

Abordagem 1: retornar ao primário e ao modo de espera originais

1. No Cloud Shell, inicie o primário e o modo de espera originais (antigos):

   gcloud compute instances start node-1 --zone us-central1-a --quiet
   gcloud compute instances start node-2 --zone us-central1-b --quiet
   

2. No Microsoft SQL Server Management Studio, adicione node-1 e node-2 novamente como réplicas secundárias:

   1. No node-3 , adicione os dois servidores no modo de confirmação assíncrona:

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

   2. No node-1 , comece a sincronizar os bancos de dados novamente:

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

   3. No node-2 , comece a sincronizar os bancos de dados novamente:

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

3. Torne node-1 o primário novamente:

   1. Em node-3 , altere o modo de disponibilidade de node-1 para confirmação síncrona. A instância node-1 torna-se a primária novamente.

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      

   2. Em node-1 , altere node-1 para ser o primário e os outros dois nós para serem os secundários:

      USE [master]
      GO
      -- Node 1 becomes primary
      ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS;
      GO
      
      -- Node 2 has synchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      
      -- Node 3 has asynchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

Depois que todos os comandos forem bem-sucedidos, node-1 será o primário e os outros nós serão secundários, conforme mostrado no diagrama a seguir.

Abordagem 2: configurar um novo primário e um novo modo de espera

É possível que você não consiga recuperar as instâncias primárias e de espera originais da falha, ou demore muito para recuperá-las ou a região esteja inacessível. Uma abordagem é manter node-3 como primário e, em seguida, criar um novo standby e uma nova instância secundária, conforme mostrado no diagrama a seguir.

Figura 5. Recuperação de desastres com região primária original R1 indisponível.

Esta implementação exige que você faça o seguinte:

• Mantenha node-3 como primário em us-east1 .

• Adicione uma nova instância de espera ( node-4 ) em uma zona diferente em us-east1 . Esta etapa estabelece a nova implantação como altamente disponível.

• Crie uma nova instância secundária ( node-5 ) em uma região separada, por exemplo, us-west2 . Esta etapa configura a nova implantação para recuperação de desastres. A implantação geral está concluída. A arquitetura do banco de dados oferece suporte total a HA e DR.

(Opcional) Execute um substituto quando faltarem transações

Uma falha abaixo do ideal ocorre quando uma ou mais transações confirmadas no primário não são replicadas para o secundário no ponto de falha (também conhecida como falha grave ). Num failover, todas as transações confirmadas que não são replicadas são perdidas.

Para testar as etapas de failover para esse cenário, é necessário gerar uma falha grave. A melhor abordagem para gerar uma falha grave é a seguinte:

• Altere a rede para que não haja conectividade entre as instâncias primária e secundária.
• Altere o primário de alguma forma — por exemplo, adicione uma tabela ou insira alguns dados.
• Percorra o processo de failover conforme descrito anteriormente para que o secundário se torne o novo primário.

As etapas do processo de failover são idênticas às do cenário ideal , exceto que a tabela adicionada ao primário após a interrupção da conectividade de rede não é visível no secundário.

Sua única opção para lidar com uma falha grave é remover as réplicas ( node-1 e node-2 ) do grupo de disponibilidade e sincronizar as réplicas novamente. A sincronização altera seu estado para corresponder ao secundário. Qualquer transação que não foi replicada antes da falha será perdida.

Para adicionar node-1 como uma instância secundária, você pode seguir as mesmas etapas para adicionar node-3 anteriormente (consulte Adicionar a instância secundária ao cluster de failover anteriormente) com a seguinte diferença: node-3 agora é o primário, não node-1 . Você precisa substituir qualquer instância do node-3 pelo nome do servidor adicionado ao grupo de disponibilidade. Se você reutilizar a mesma VM ( node-1 e node-2 ), não será necessário adicionar o servidor ao cluster de failover do Windows Server; adicione apenas a instância do SQL Server de volta ao grupo de disponibilidade.

Neste ponto, node-3 é o primário e node-1 e node-2 são secundários. Agora é possível voltar ao node-1 , tornar node-2 o modo de espera e tornar node-3 o secundário. O sistema agora tem o mesmo estado que tinha antes da falha.

Failover automático

O failover automático para uma instância secundária como a primária pode criar problemas. Depois que o primário original ficar disponível novamente, poderá ocorrer uma situação de divisão cerebral se alguns clientes acessarem o secundário enquanto outros gravarem no primário restaurado. Neste caso, o primário e o secundário são possivelmente atualizados em paralelo e seus estados divergem. Para evitar esta situação, este tutorial fornece instruções para um failover manual no qual você decide se (ou quando) realizar o failover.

Se você implementar um failover automático, deverá garantir que apenas uma das instâncias configuradas seja a primária e possa ser modificada. Qualquer instância auxiliar ou secundária não deve fornecer acesso de gravação a nenhum cliente (exceto o primário para replicação de estado). Além disso, você deve evitar uma cadeia rápida de failovers subsequentes em pouco tempo. Por exemplo, um failover a cada cinco minutos não seria uma estratégia confiável de recuperação de desastres. Para processos de failover automatizados, você pode criar proteções contra cenários problemáticos como esses e até mesmo envolver um administrador de banco de dados para decisões complexas, se necessário.

Arquitetura de implantação alternativa

Este tutorial configura uma arquitetura de recuperação de desastres com uma instância secundária que se torna a instância primária em um failover, conforme mostrado no diagrama a seguir.

Figura 6. Arquitetura padrão de recuperação de desastres usando Microsoft SQL Server.

Isso significa que, no caso de um failover, a implantação resultante terá uma única instância até que um fallback seja possível ou até que você configure uma espera (para HA) e uma secundária (para DR).

Uma arquitetura de implantação alternativa é configurar duas instâncias secundárias. Ambas as instâncias são réplicas da primária. Se ocorrer um failover, você poderá reconfigurar um dos secundários como standby. Os diagramas a seguir mostram a arquitetura de implantação antes e depois de um failover.

Figura 7. Arquitetura padrão de recuperação de desastres com duas instâncias secundárias.

Figura 8. Arquitetura padrão de recuperação de desastres com duas instâncias secundárias após failover.

Embora você ainda deva tornar um dos dois secundários em espera (Figura 8), esse processo é muito mais rápido do que criar e configurar um novo modo de espera do zero.

Você também pode abordar a DR com uma configuração análoga a esta arquitetura de uso de duas instâncias secundárias. Além de ter dois secundários em uma segunda região (Figura 7), é possível implantar outros dois secundários em uma terceira região. Essa configuração permite criar com eficiência uma arquitetura de implantação habilitada para HA e DR após uma falha na região primária.