Como implantar o Microsoft SQL Server para recuperação de desastres multirregional

Last reviewed 2020-08-21 UTC

---

Neste tutorial, descrevemos como implantar e gerenciar um sistema de banco de dados do Microsoft SQL Server em duas regiões do Google Cloud como uma solução de recuperação de desastres (DR) e como fazer failover de uma instância de banco de dados com falha para uma instância que opera normalmente. Para os fins deste documento, um desastre é um evento em que um banco de dados primário falha ou fica indisponível.

Um banco de dados primário pode falhar quando a região onde ele está localizado falha ou fica inacessível. Mesmo que uma região esteja disponível e operando normalmente, um banco de dados primário pode falhar por causa de um erro do sistema. Nesses casos, a recuperação de desastres é o processo de disponibilizar um banco de dados secundário para os clientes continuarem o processamento.

Este tutorial se destina a arquitetos de bancos de dados, administradores e engenheiros.

Objetivos

• Implantar um ambiente de recuperação de desastres multirregional no Google Cloud usando os Grupos de Disponibilidade AlwaysOn do Microsoft SQL Server.
• Simular um evento de desastre e executar um processo de recuperação completo para validar a configuração de recuperação de desastres.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

• Compute Engine
• VMs do SQL Server

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

Para este tutorial, você precisa de um projeto do Google Cloud. É possível criar um novo projeto ou selecionar um que já foi criado:

1. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

   Observação: se você não pretende manter os recursos criados neste procedimento, crie um projeto novo em vez de selecionar um que já existe. Depois de concluir essas etapas, é possível excluir o projeto. Para fazer isso, basta remover todos os recursos associados a ele.

   Acessar o seletor de projetos

2. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

3. No Console do Google Cloud, ative o Cloud Shell.

   Ativar o Cloud Shell

Noções básicas sobre a recuperação de desastres

No Google Cloud, a recuperação de desastres (DR) significa fornecer a continuidade do processamento, especialmente quando uma região falha ou fica inacessível. Para sistemas como o de gerenciamento de banco de dados, implemente a DR implantando o sistema em pelo menos duas regiões. Com essa configuração, o sistema continuará funcionando 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 primária falha é chamado de recuperação de desastres do banco de dados (ou DR do banco de dados). Para uma discussão detalhada sobre esse conceito, consulte Recuperação de desastres para o Microsoft SQL Server. O ideal é que o estado do banco de dados secundário seja consistente com o primário no momento em que o primário fica indisponível, ou que o banco de dados secundário não tenha apenas um pequeno grupo de transações recentes do primário.

Arquitetura de recuperação de desastres

No Microsoft SQL Server, o diagrama a seguir mostra uma arquitetura mínima compatível com a DR do banco de dados.

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

Essa arquitetura funciona da seguinte maneira:

• Duas instâncias do Microsoft SQL Server (uma instância primária e uma de espera) estão localizadas na mesma região (R1), mas em zonas diferentes (zonas A e B). As duas instâncias na R1 coordenam os estados usando o modo de confirmação síncrona. O modo síncrono é usado porque aceita 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 a DR, a instância secundária na R2 é sincronizada com a instância primária na R1 usando o modo de confirmação assíncrona. O modo assíncrono é usado devido ao desempenho, já que ele não desacelera o processamento de confirmação na instância primária.

No diagrama anterior, a arquitetura mostra um grupo de disponibilidade. O grupo de disponibilidade, se usado com um listener, fornecerá a mesma string de conexão aos clientes se eles forem processados por instâncias destes tipos:

• Instância primária
• Instância de espera (após uma falha da zona)
• Instância secundária (após uma falha da região e depois que a instância secundária torna-se 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. Essa abordagem pode melhorar o desempenho, mas não é altamente disponível. Uma única falha da zona 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 o failover para retomar o processamento em outra região operacional. O processo de DR determina as etapas operacionais que precisam ser executadas, manual ou automaticamente, para reduzir 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 do banco de dados consiste nas seguintes etapas:

1. A primeira região (R1), que está executando a instância primária do banco de dados, fica indisponível.
2. A equipe de operações reconhece e confirma formalmente o desastre e decide se um failover é necessário.
3. Se for necessário um failover, 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 na R2.

Ainda que esse processo básico estabeleça um banco de dados primário de trabalho novamente, ele não estabelece uma arquitetura de DR completa, em que o novo primário tem uma instância de banco de dados de espera e uma secundária.

Processo completo de recuperação de desastres

O processo completo de DR é uma extensão do processo básico porque adiciona etapas para estabelecer uma arquitetura completa de DR após um failover. No diagrama a seguir, mostramos uma arquitetura completa de DR de banco de dados.

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

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

1. A primeira região (R1), que está executando a instância primária do banco de dados, fica indisponível.
2. A equipe de operações reconhece e confirma formalmente o desastre e decide se um failover é necessário.
3. Se for necessário um failover, 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 de espera, é criada e iniciada na R2 e adicionada à instância primária. A instância de espera está em uma zona diferente da instância primária. Agora, o banco de dados primário consiste em duas instâncias, primária e de espera, que estão altamente disponíveis.
5. Em uma terceira região (R3), uma nova instância de banco de dados secundária (de espera) é criada e iniciada. Essa instância secundária é conectada de maneira assíncrona à nova instância primária na R2. Nesse ponto, a arquitetura original de recuperação de desastres é recriada e está operante.

Fallback para uma região recuperada

Depois que a primeira região (R1) voltar a ficar on-line, ela poderá hospedar o novo banco de dados secundário. Se a R1 logo ficar disponível, será possível implementar a etapa 5 do processo de recuperação completo na R1, em vez da R3 (a terceira região). Nesse caso, uma terceira região não é necessária.

No diagrama a seguir, mostramos a arquitetura caso a R1 fique disponível a tempo.

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

Nesta 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 a R1 torna-se o local das instâncias secundárias, em vez da R3.

Como escolher uma edição do SQL Server

Este tutorial considera as seguintes versões do Microsoft SQL Server:

• SQL Server 2016 Enterprise Edition
• SQL Server 2017 Enterprise Edition
• SQL Server 2019 Enterprise Edition

Neste tutorial, o recurso Grupos de Disponibilidade AlwaysOn é usado no SQL Server.

Se você não precisar de um banco de dados primário do Microsoft SQL Server com alta disponibilidade (HA, na sigla em inglês), e uma instância primária de banco de dados for suficiente, use as seguintes versões do SQL Server:

• SQL Server 2016 Standard Edition
• SQL Server 2017 Standard Edition
• SQL Server 2019 Standard Edition

As versões 2016, 2017 e 2019 do SQL Server têm o Microsoft SQL Server Management Studio instalado na imagem. Você não precisa instalá-lo separadamente. No entanto, em um ambiente de produção, recomendamos instalar uma instância do Microsoft SQL Server Management Studio em uma VM separada em cada região. Se você configurar um ambiente de HA, convém instalar o Microsoft SQL Server Management Studio uma vez em cada zona para garantir que ele continue disponível se outra zona ficar indisponível.

Como configurar o Microsoft SQL Server para DR multirregional

Nesta seção, usamos a imagem sql-ent-2016-win-2016 do Microsoft SQL Server 2016 Enterprise Edition. Se você instalar o Microsoft SQL Server 2017 Enterprise Edition, use sql-ent-2017-win-2016. Para o Microsoft SQL Server 2019 Enterprise Edition, use sql-ent-2019-win-2019. Para 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, na sigla em inglês) de duas instâncias em uma região. Uma delas serve como primária e a outra como secundária. Para realizar esta etapa, siga as instruções em Como configurar grupos de disponibilidade AlwaysOn do SQL Server. Neste tutorial, usamos us-central1 para a região primária (chamada de R1). Antes de começar, leia as considerações a seguir.

Primeiro, se você seguir as etapas em Como configurar grupos de disponibilidade AlwaysOn do SQL Server, criará duas instâncias do SQL Server na mesma zona (us-central1-f). Essa configuração não protege você contra uma falha de us-central1-f. Portanto, para oferecer suporte a alta disponibilidade, implante uma instância do SQL Server (cluster-sql1) em us-central1-c e uma segunda instância (cluster-sql2) em us-central1-f. Nas etapas da próxima seção (como adicionar uma instância secundária para recuperação de desastres), consideramos essa configuração de implantação.

Segundo, as etapas em Como configurar grupos de disponibilidade AlwaysOn do SQL Server incluem a execução desta instrução:

BACKUP DATABASE TestDB to disk = '\\cluster-sql2\SQLBackup\TestDB.bak' WITH INIT

Essa instrução faz com que a instância de espera falhe. Em vez disso, execute o seguinte comando (o nome do arquivo de backup é diferente):

BACKUP DATABASE TestDB to disk = '\\cluster-sql2\SQLBackup\TestDB-backup.bak' WITH INIT

Terceiro, as etapas em Como configurar grupos de disponibilidade AlwaysOn do SQL Server criam diretórios de backup. Esses backups são usados somente quando você sincroniza inicialmente a instância primária com a de espera, e não posteriormente. Uma abordagem alternativa à criação de diretórios de backup é escolher uma propagação automática nessas etapas. Essa abordagem simplifica o processo de configuração.

Quarto, se os bancos de dados não forem sincronizados, execute o seguinte comando em cluster-sql2:

ALTER DATABASE [TestDB] SET HADR AVAILABILITY GROUP = [cluster-ag]

Quinto, para os fins deste tutorial, crie um controlador de domínio em us-central1-f, como mostrado no diagrama a seguir.

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

Ainda que você implemente a arquitetura anterior neste tutorial, é recomendável 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 houver uma interrupção em uma zona, ela não se tornará um ponto único de falha da arquitetura implantada.

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

A seguir, configure uma terceira instância do SQL Server (uma instância secundária chamada cluster-sql3) com a rede:

1. No Cloud Shell, na mesma nuvem privada virtual (VPC) usada para a região primária, crie uma sub-rede na região secundária (us-east1):

   gcloud compute networks subnets create wsfcsubnet4 --network wsfcnet \
       --region us-east1 --range 10.3.0.0/24
   

2. Modifique a regra de firewall chamada allow-internal-ports para permitir que a nova sub-rede receba o tráfego:

   gcloud compute firewall-rules update allow-internal-ports \
       --source-ranges 10.0.0.0/24,10.1.0.0/24,10.2.0.0/24,10.3.0.0/24
   

   A regra allow-internal-ports está incluída nas etapas das instruções seguidas anteriormente.

3. Crie uma instância do SQL Server:

   gcloud compute instances create cluster-sql3 --machine-type n1-highmem-4 \
       --boot-disk-type pd-ssd --boot-disk-size 200GB \
       --image-project windows-sql-cloud --image-family sql-ent-2016-win-2016 \
       --zone us-east1-b \
       --network-interface "subnet=wsfcsubnet4,private-network-ip=10.3.0.4,aliases=10.3.0.5;10.3.0.6" \
       --can-ip-forward --metadata sysprep-specialize-script-ps1="Install-WindowsFeature Failover-Clustering -IncludeManagementTools;"
   

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.

      Acessar o Compute Engine

   2. Na coluna Conectar do cluster do Compute Engine cluster-sql3, selecione a lista suspensa Configurar a senha do Windows .

   3. Defina o nome de usuário e a senha. Anote-os para usar mais tarde.

5. Clique em RDP para se conectar à instância cluster-sql3.

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

7. Abra uma janela do Windows PowerShell como administrador e configure o DNS e as portas abertas:

   netsh interface ip set dns Ethernet static 10.2.0.100
   
   netsh advfirewall firewall add rule name="Open Port 5022 for Availability Groups" dir=in action=allow protocol=TCP localport=5022
   
   netsh advfirewall firewall add rule name="Open Port 1433 for SQL Server" dir=in action=allow protocol=TCP localport=1433
   

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

   Add-Computer -DomainName "dbeng.com" -Credential "dbeng.com\Administrator" -Restart -Force
   

   Esse comando encerra a conexão RDP.

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

Em seguida, adicione a instância secundária (cluster-sql3) ao cluster de failover do Windows:

1. Conecte-se às instâncias cluster-sql1 ou cluster-sql2 usando RDP e faça login como administrador.

2. Abra uma janela do PowerShell como administrador e defina variáveis para o ambiente do cluster neste tutorial:

   $node3 = "cluster-sql3"
   $nameWSFC = "cluster-dbclus" # Name of cluster
   

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

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

   A execução desse comando pode levar um tempo. Como o processo pode parar de responder e não retornar automaticamente, pressione Enter ocasionalmente.

4. No nó, ative o recurso Alta Disponibilidade AlwaysOn:

   Enable-SqlAlwaysOn -ServerInstance $node3 -Force
   

5. Crie duas pastas em C:\SQLData e C:\SQLLog para armazenar os dados do banco de dados e os arquivos de registros:

   New-item -ItemType Directory "C:\SQLData"
   
   New-item -ItemType Directory "C:\SQLLog"
   

Agora o nó está mesclado com o cluster de failover.

Adicionar a instância secundária ao grupo de disponibilidade atual

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

1. Em qualquer um dos três nós da instância (cluster-sql1, cluster-sql2 ou cluster-sql3), abra o Microsoft SQL Server Management Studio e conecte-se à instância primária (cluster-sql1):

   1. Acesse o Pesquisador de Objetos.
   2. Selecione a lista suspensa Conectar.
   3. Selecione Mecanismo do banco de dados.
   4. Na lista suspensa Nome do servidor, selecione cluster-sql1. Se o cluster não constar na lista, insira-o no campo.

2. Clique em Nova consulta.

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

   ALTER AVAILABILITY GROUP [cluster-ag] MODIFY LISTENER 'cluster-listene' (ADD IP ('10.3.0.6', '255.255.255.0'))
   

4. No Pesquisador de Objetos, expanda o nó Alta Disponibilidade AlwaysOn e, em seguida, expanda o nó Grupos de Disponibilidade.

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

6. Na página Introdução, clique no nó Alta Disponibilidade AlwaysOn e depois no nó Grupos de Disponibilidade.

7. Na página Conectar às Réplicas, clique em Conectar para se conectar à réplica secundária atual cluster-sql2.

8. Na página Especificar Réplicas, clique em Adicionar Réplica e adicione o novo nó cluster-sql3. Não selecione Failover Automático, porque ele gera uma confirmação síncrona. Essa configuração ultrapassa os limites regionais, o que não é recomendado.

9. Na página Selecionar Sincronização de Dados, selecione Propagação automática.

   Como não há um listener, a página Validação gera um aviso, que pode ser ignorado.

10. Conclua as etapas do assistente.

O modo de failover para cluster-sql1 e cluster-sql2 é automático, enquanto o de cluster-sql3 é manual. Essa diferença é uma maneira 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.

Como simular uma recuperação de desastres

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

Simular uma interrupção e executar um failover de DR

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

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

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

      USE TestDB
      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 cluster-sql2 --zone us-central1-f --quiet
      gcloud compute instances stop cluster-sql1 --zone us-central1-c --quiet
      

   Observação: uma maneira alternativa de criar uma falha é parar as VMs que executam cluster-sql1 e cluster-sql2. Essa abordagem simula uma falha grave em vez de um desligamento de instância normal.

2. No Microsoft SQL Server Management Studio em cluster-sql3, conecte-se a cluster-sql3.

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

   ALTER AVAILABILITY GROUP [cluster-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
   GO
   ALTER AVAILABILITY GROUP [cluster-ag]
   MODIFY REPLICA ON 'CLUSTER-SQL3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
   GO
   

   É possível retomar o processamento. cluster-sql3 agora é a instância primária.

4. (Opcional) Crie uma nova tabela em cluster-sql3. Depois de sincronizar as réplicas com a nova instância primária, verifique se esta tabela foi replicada para as réplicas.

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

Neste momento, cluster-sql3 é a instância primária, mas convém voltar à região original ou configurar uma nova instância secundária e de espera para recriar uma arquitetura de DR completa novamente. Na próxima seção, discutiremos essas opções.

Recriar uma arquitetura de DR que replique totalmente as transações (opcional)

Neste caso de uso, resolvemos uma falha em que todas as transações são replicadas do banco de dados primário para o secundário antes da falha no primário. Neste cenário ideal, os dados não são perdidos. O estado do banco de dados secundário está consistente com o primário no ponto de falha.

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

• Retornar ao banco de dados primário e de espera originais, se estiverem disponíveis.
• Criar um novo banco de dados de espera e secundário para cluster-sql3, caso o primário e de espera originais não estejam disponíveis.

Abordagem 1: retornar ao banco de dados primário original e de espera

1. No Cloud Shell, inicie o banco de dados primário original (antigo) e de espera:

   gcloud compute instances start cluster-sql1 --zone us-central1-c --quiet
   gcloud compute instances start cluster-sql2 --zone us-central1-f --quiet
   

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

   1. Em cluster-sql3, adicione os dois servidores no modo de confirmação assíncrona:

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

   2. Em cluster-sql1, comece a sincronizar os bancos de dados novamente:

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

   3. Em cluster-sql2, comece a sincronizar os bancos de dados novamente:

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

3. Torne cluster-sql1 o primário novamente:

   1. Em cluster-sql3, altere o modo de disponibilidade de cluster-sql1 para confirmação síncrona. A instância cluster-sql1 se tornará a primária novamente.

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      

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

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

Depois que todos os comandos forem concluídos, cluster-sql1 será o primário, e os outros nós serão os secundários, como mostrado no diagrama a seguir.

Abordagem 2: configurar uma nova instância primária e de espera

Talvez não seja possível recuperar as instâncias primária original e de espera da falha, pode levar muito tempo para recuperá-las ou a região pode ficar inacessível. Uma abordagem é manter cluster-sql3 como a instância primária e criar uma nova instância de espera e secundária, como mostrado no diagrama a seguir.

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

Essa implementação requer que você faça o seguinte:

• Mantenha cluster-sql3 como instância primária em us-east1.

• Adicione uma nova instância de espera (cluster-sql4) em uma zona diferente em us-east1. Nesta etapa, a nova implantação é estabelecida como altamente disponível.

• Crie uma nova instância secundária (cluster-sql5) em uma região separada, por exemplo, us-west2. Nesta etapa, a nova implantação é configurada para recuperação de desastres. A implantação geral foi concluída. A arquitetura de banco de dados é totalmente compatível com HA e DR.

Executar fallback quando as transações estiverem ausentes (opcional)

Uma falha longe do ideal é quando uma ou mais transações confirmadas na instância primária não são replicadas para a secundária no momento da falha (também conhecida como falha grave). Em um failover, todas as transações confirmadas que não são replicadas são perdidas.

Para testar as etapas de failover desse cenário, é preciso gerar uma falha grave. Veja a seguir a melhor abordagem para gerar uma falha grave:

• Altere a rede para que não haja conectividade entre as instâncias primária e secundária.
• Altere a instância primária de alguma maneira. Por exemplo, adicione uma tabela ou insira alguns dados.
• Siga o processo de failover conforme descrito anteriormente para que a instância secundária torne-se a nova primária.

As etapas do processo de failover são idênticas às do cenário ideal. A diferença é que a tabela adicionada à instância primária após a interrupção da conexão de rede não fica visível na instância secundária.

Sua única opção para lidar com uma falha grave é remover as réplicas (cluster-sql1 e cluster-sql2) do grupo de disponibilidade e sincronizar as réplicas novamente. A sincronização altera o estado para corresponder à instância secundária. Qualquer transação não replicada antes da falha é perdida.

Para adicionar cluster-sql1 como uma instância secundária, siga as mesmas etapas para adicionar cluster-sql3 anteriormente (consulte Adicionar a instância secundária ao cluster de failover já abordado neste documento), com a seguinte diferença: cluster-sql3 agora é a instância primária, e não cluster-sql1. É preciso substituir qualquer instância de cluster-sql3 pelo nome do servidor adicionado ao grupo de disponibilidade. Se você reutilizar a mesma VM (cluster-sql1 e cluster-sql2), não precisará adicionar o servidor ao cluster de failover do Windows Server. Adicione apenas a instância do SQL Server novamente ao grupo de disponibilidade.

Neste momento, cluster-sql3 é a instância primária, e cluster-sql1 e cluster-sql2 são secundárias. Agora é possível voltar a cluster-sql1 para tornar cluster-sql2 a instância de espera e cluster-sql3 a instância secundária. O sistema agora tem o mesmo estado que tinha antes da falha.

Failover automático

Fazer o failover automaticamente para uma instância secundária como primária pode causar problemas. Depois que a instância primária original for disponibilizada novamente, uma situação de dupla personalidade poderá ocorrer se alguns clientes acessarem a instância secundária enquanto outros gravarem na instância primária restaurada. Nesse caso, as instâncias primária e secundária poderão ser atualizadas em paralelo, e os estados delas serão divergentes. Para evitar essa situação, este tutorial apresenta instruções para um failover manual em que você decide se (ou quando) fará o failover.

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

Arquitetura de implantação alternativa

Neste tutorial, configuramos 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 de recuperação de desastres padrão usando o Microsoft SQL Server.

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

Uma arquitetura de implantação alternativa é configurar duas instâncias secundárias. As duas instâncias são réplicas da primária. Se ocorrer um failover, será possível reconfigurar uma das secundárias como espera. Veja no diagrama a seguir a arquitetura de implantação antes e depois de um failover.

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

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

Mesmo que ainda seja necessário transformar uma das duas instâncias secundárias em espera (Figura 8), esse processo é muito mais rápido do que criar e configurar uma nova instância de espera do zero.

Também é possível executar a DR com uma configuração análoga a esta arquitetura que usa duas instâncias secundárias. Além de ter duas instâncias secundárias em uma segunda região (Figura 7), é possível implantar outras duas instâncias secundárias 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.

Limpeza

Para evitar cobranças dos recursos usados neste tutorial na conta do Google Cloud, siga estas etapas:

Excluir o projeto

Cuidado: excluir um projeto tem os seguintes efeitos:
• Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.
1. No Console do Google Cloud, acesse a página Gerenciar recursos.

   Acessar "Gerenciar recursos"

2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

A seguir

• Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.