

# Implantações multi-AZ para o Amazon RDS for Microsoft SQL Server
<a name="USER_SQLServerMultiAZ"></a>

As implantações Multi-AZ oferecem maior disponibilidade, durabilidade de dados e tolerância a falhas para instâncias de banco de dados. No caso de uma manutenção planejada do banco de dados ou de uma interrupção não planejada do serviço, o Amazon RDS faz failover automático para a instância de banco de dados secundário atualizada. Essa funcionalidade permite que as operações do banco de dados sejam retomadas rapidamente sem intervenção manual. As instâncias primária e em espera usam o mesmo endpoint, cujo endereço de rede física faz a transição para a réplica secundária como parte do processo de failover. Não é necessário reconfigurar seu aplicativo quando ocorre um failover.

O Amazon RDS comporta implantações multi-AZ para Microsoft SQL Server usando o SQL Server Database Mirroring (DBM) ou grupos de disponibilidade Always On (AGs) ou replicação em nível de bloco. O Amazon RDS monitora e mantém a integridade de sua implantação Multi-AZ. Caso ocorram problemas, o RDS repara automaticamente instâncias de banco de dados não íntegras, reestabelece a sincronização e inicia os failovers. O failover só ocorrerá se o modo em espera e o primário estiverem totalmente sincronizados. Você não precisa gerenciar tudo.

Quando você configura o multi-AZ do SQL Server, o RDS configura automaticamente todos os bancos de dados na instância para usar DBM, AGs ou replicação em nível de bloco. O Amazon RDS processa as instâncias primária, a testemunha e de banco de dados secundária para você ao configurar o DBM ou AGs. Para replicação em nível de bloco, o RDS processa as instâncias primária e de banco de dados secundária. Como a configuração é automática, o RDS selecione DBM, Always On AGS ou replicação em nível de bloco com base na versão do SQL Server implantada.

O Amazon RDS oferece suporte a Multi-AZ com Always On AGs para as seguintes versões e edições do SQL Server:
+ SQL Server 2022:
  + Edição Standard
  + Edição Enterprise
+ SQL Server 2019:
  + Standard Edition 15.00.4073.23 e posteriores
  + Edição Enterprise
+ SQL Server 2017:
  + Standard Edition 14.00.3401.7 e posteriores
  + Enterprise Edition 14.00.3049.1 e posteriores
+ SQL Server 2016: Enterprise Edition 13.00.5216.0 e posterior

O Amazon RDS oferece suporte a Multi-AZ com DBM para as seguintes versões e edições do SQL Server, exceto para as versões indicadas anteriormente:
+ SQL Server 2019: Standard Edition 15.00.4043.16
+ SQL Server 2017: Standard e Enterprise Editions
+ SQL Server 2016: Standard e Enterprise Editions 

O Amazon RDS comporta multi-AZ com replicação em nível de bloco para SQL Server 2022 Web Edition 16.00.4215.2 e posterior.

**nota**  
Somente novas instâncias de banco de dados criadas com 16.00.4215.2 ou posterior comportam implantações multi-AZ com replicação em nível de bloco. As seguintes restrições se aplicam às instâncias existentes do SQL Server 2022 Web Edition:  
Para instâncias existentes na versão 16.00.4215.2, você deve restaurar um snapshot em uma nova instância com a mesma versão secundária ou posterior para permitir a replicação em nível de bloco.
As instâncias Web do SQL Server 2022 com uma versão secundária mais antiga podem ser atualizadas para a versão secundária 16.00.4215.2 ou posterior para habilitar a replicação em nível de bloco.

Você pode usar a seguinte consulta SQL para determinar se sua instância de banco de dados do SQL Server é single-AZ, multi-AZ com DBM ou multi-AZ com AGs Always On: Essa consulta não se aplica a implantações multi-AZ no SQL Server Web Edition.

```
SELECT CASE WHEN dm.mirroring_state_desc IS NOT NULL THEN 'Multi-AZ (Mirroring)'
    WHEN dhdrs.group_database_id IS NOT NULL THEN 'Multi-AZ (AlwaysOn)'
    ELSE 'Single-AZ'
    END 'high_availability'
FROM sys.databases sd
LEFT JOIN sys.database_mirroring dm ON sd.database_id = dm.database_id
LEFT JOIN sys.dm_hadr_database_replica_states dhdrs ON sd.database_id = dhdrs.database_id AND dhdrs.is_local = 1
WHERE DB_NAME(sd.database_id) = 'rdsadmin';
```

A saída será semelhante à seguinte.

```
high_availability
Multi-AZ (AlwaysOn)
```

## Adicionar Multi-AZ a uma instância de banco de dados do Microsoft SQL Server
<a name="USER_SQLServerMultiAZ.Adding"></a>

Ao criar uma instância de banco de dados do SQL Server usando o Console de gerenciamento da AWS, você pode adicionar multi-AZ com Database Mirroring (DBM), AGs Always On ou replicação em nível de bloco. Faça isso selecionando **Sim (Espelhamento/Always On/Replica em nível de bloco)** em **Implantação multi-AZ**. Para obter mais informações, consulte [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md).

Ao modificar uma instância de banco de dados do SQL Server existente usando o console, você pode adicionar multi-AZ com DBM, AGs ou replicação em nível de bloco escolhendo **Sim (Espelhamento/Always On/Replicação em nível de bloco)** na lista **Implantação multi-AZ** na página **Modificar instância de banco de dados**. Para obter mais informações, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md).

**nota**  
Se a instância de banco de dados estiver executando o DBM (Database Mirroring) — e não AGs (Grupos de disponibilidade Always On) — talvez seja necessário desabilitar a otimização na memória antes de adicionar Multi-AZ. Desabilite a otimização na memória com DBM antes de adicionar multi-AZ se a instância de banco de dados executar o SQL Server 2016 ou 2017 Enterprise Edition e tiver a otimização na memória habilitada.   
Se a instância de banco de dados estiver executando AGs ou replicação em nível de bloco para as edições Web do SQL Server, não será necessário realizar essa etapa. 

## Remover multi-AZ de uma instância de banco de dados do Microsoft SQL Server
<a name="USER_SQLServerMultiAZ.Removing"></a>

Ao modificar uma instância de banco de dados do SQL Server existente usando o Console de gerenciamento da AWS, você pode remover multi-AZ com DBM, AGs ou replicação em nível de bloco. Para fazer isso, escolha **Não (Espelhamento/Always On/Replicação em nível de bloco)** em **Implantação multi-AZ** na página **Modificar instância de banco de dados**. Para obter mais informações, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md).

# Limitações, observações e recomendações de implantação multi-AZ do Microsoft SQL Server
<a name="USER_SQLServerMultiAZ.Recommendations"></a>

A seguir você encontrará algumas restrições aplicáveis ao trabalhar com implantações multi-AZ em instâncias de banco de dados do RDS para SQL Server:
+ O Multi-AZ entre regiões não é compatível.
+ Não há suporte para a interrupção de um para a instância de banco de dados SQL Server em uma implantação Multi-AZ.
+ Não é possível configurar a instância de banco de dado secundária para aceitar a atividade de leitura de banco de dados.
+ Multi-AZ com grupos de disponibilidade (AGs) Always On oferece suporte à otimização na memória.
+ O Multi-AZ com grupos de disponibilidade (AGs) Always On não oferece suporte à autenticação Kerberos para o listener do grupo de disponibilidade. Isso ocorre, pois o listener não tem nome principal do serviço (SPN).
+ No momento, só é possível usar multi-AZ com replicação em nível de bloco com instâncias do SQL Server Web Edition.
+ Não é possível renomear um banco de dados em uma instância de banco de dados do SQL Server que esteja em uma implantação Multi-AZ do SQL Server. Se você precisar renomear um banco de dados em uma instância assim, primeiro desative o Multi-AZ da instância de banco de dados e renomeie o banco de dados. Por fim, reative Multi-AZ para a instância de banco de dados. 
+ Você só pode restaurar instâncias de banco de dados Multi-AZ com backup feito usando-se o modelo de recuperação completo.
+ As implantações multi-AZ têm um limite de cem trabalhos do SQL Server Agent.

  Se um limite mais alto for necessário, solicite um aumento de cota entrando em contato com o Suporte. Abra a página do [AWS Support Center](https://console.aws.amazon.com/support/home#/), faça login, se necessário, e escolha **Create case** (Criar caso). Escolha **Service limit increase** (Aumento de limite do serviço). Preencha e envie o formulário.
+ Não é possível ter um banco de dados off-line em uma instância de banco de dados do SQL Server que esteja em uma implantação multi-AZ do SQL Server.
+ O RDS para SQL Server não replica as permissões do banco de dados MSDB para a instância secundária. Se você precisar dessas permissões na instância secundária, deverá recriá-las manualmente.
+ As métricas de volume não estão disponíveis para o host secundário da instância usando a replicação em nível de bloco.

Veja a seguir algumas observações sobre como trabalhar com implantações multi-AZ em instâncias de banco de dados do RDS para SQL Server:
+ O Amazon RDS expõe o [endpoint de listener do grupo de disponibilidade](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover) de Always On AGs. O endpoint está visível no console e é retornado pela operação de API `DescribeDBInstances` como uma entrada no campo de endpoints.
+ O Amazon RDS oferece suporte a [failovers de sub-rede do grupo de disponibilidade](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover).
+ Para usar o multi-AZ do SQL Server com uma instância de banco de dados do SQL Server em uma nuvem privada virtual (VPC), primeiro crie um grupo de sub-rede de banco de dados que tenha sub-redes em pelo menos duas zonas de disponibilidade distintas. Em seguida, atribua o grupo de sub-rede de banco de dados à réplica primária da instância de banco de dados do SQL Server. 
+ Quando uma instância de banco de dados é modificada para ser uma implantação Multi-AZ, durante a modificação, ela tem o status **modifying**. O Amazon RDS cria o modo de espera e faz um backup da instância de banco de dados primária. Depois que o processo estiver concluído, o status da instância de banco de dados primária se tornará **available (disponível)**.
+ Implantações Multi-AZ mantém todos os bancos de dados no mesmo nó. Se um banco de dados no host primário fizer failover, todos os bancos de dados do SQL Server farão failover como uma unidade atômica para o host em espera. O Amazon RDS provisiona um novo host íntegro e substitui o host não íntegro.
+ O multi-AZ com DBM, AGs ou replicação em nível de bloco aceitam uma única réplica em espera.
+ Os usuários, os logins e as permissões são replicados automaticamente para você na secundária. Não é necessário recriá-los. Os perfis de servidor definidos pelo usuário só são replicados em instâncias de banco de dados que usam AGs Always On ou replicação em nível de bloco para implantações multi-AZ. 
+ Em implantações multi-AZ, o RDS para SQL Server cria logins do SQL Server para permitir AGs Always On ou o Database Mirroring. O RDS cria logins com o seguinte padrão, `db_<dbiResourceId>_node1_login`, `db_<dbiResourceId>_node2_login` e `db_<dbiResourceId>_witness_login`.
+ O RDS para SQL Server cria um login do SQL Server para permitir o acesso às réplicas de leitura. O RDS cria um login com o seguinte padrão: `db_<readreplica_dbiResourceId>_node_login`.
+ Em implantações multi-AZ, os trabalhos do SQL Server Agent são replicados do host primário para o host secundário quando o recurso de replicação de trabalhos é ativado. Para obter mais informações, consulte [Ativar a replicação de trabalhos do SQL Server Agent](Appendix.SQLServer.CommonDBATasks.Agent.md#SQLServerAgent.Replicate).
+ Convém observar latências elevadas em comparação com uma implantação de instância de banco de dados padrão (em uma única zona de disponibilidade) por causa da replicação de dados síncrona.
+ Os tempos de failover são afetados pelo tempo necessário para completar o processo de recuperação. Transações grandes aumentam o tempo de failover.
+ Em implantações Multi-AZ do SQL Server, a reinicialização com failover reinicializa somente a instância de banco de dados principal. Após o failover, a instância de banco de dados primária torna-se a nova instância de banco de dados secundária. Os parâmetros podem não ser atualizados para instâncias Multi-AZ. Para a reinicialização sem failover, as instâncias de banco de dados primárias e secundárias são reinicializadas e os parâmetros são atualizados após a reinicialização. Se a instância de banco de dados não responder, recomendamos reinicializar sem failover.

A seguir você encontrará algumas recomendações para trabalhar com implantações Multi-AZ em instâncias de banco de dados do RDS for Microsoft SQL Server:
+ Para bancos de dados usados em produção ou pré-produção, recomendamos as seguintes opções:
  + Implantações Multi-AZ para alta disponibilidade
  + "IOPS provisionadas" para performance rápida e consistente
  + "Memória otimizada" em vez de "Uso geral"
+ Não é possível selecionar a zona de disponibilidade (AZ) para a instância secundária. Por isso, quando implantar hosts de aplicativo, leve isso em conta. O banco de dados pode fazer failover para outro AZ, e os hosts de aplicativo podem não estar no mesmo AZ do banco de dados. Por esse motivo, recomendamos equilibrar os hosts de aplicação em todas as AZs na região da AWS indicada.
+ Para ter a melhor performance, não habilite o Database Mirroring ou os AGs Always On ou a replicação em nível de bloco durante uma operação grande de carregamento de dados. Se quiser que o carregamento de dados seja o mais rápido possível, termine o carregamento de dados antes de converter a instância de banco de dados em uma implantação Multi-AZ. 
+ Os aplicativos que acessam os bancos de dados do SQL Server devem ter um tratamento de exceção que capte erros de conexão. O exemplo de código a seguir mostra um bloco try/catch que capta um erro de comunicação. Neste exemplo, a `break` instrução sai do `while` loop se a conexão for bem-sucedida, mas tenta novamente até 10 vezes se uma exceção for lançada.

  ```
  int RetryMaxAttempts = 10;
  int RetryIntervalPeriodInSeconds = 1;
  int iRetryCount = 0;
  while (iRetryCount < RetryMaxAttempts)
  {
     using (SqlConnection connection = new SqlConnection(DatabaseConnString))
     {
        using (SqlCommand command = connection.CreateCommand())
        {
           command.CommandText = "INSERT INTO SOME_TABLE VALUES ('SomeValue');";
           try
           {
              connection.Open();
              command.ExecuteNonQuery();
              break;
           }
           catch (Exception ex) 
           {
              Logger(ex.Message);
              iRetryCount++;
           }
           finally {
              connection.Close();
           }
        }
     }
     Thread.Sleep(RetryIntervalPeriodInSeconds * 1000);
  }
  ```
+ Não use o comando `Set Partner Off` ao trabalhar com instâncias multi-AZ utilizando DBM ou AGs. Esse comando não é aceito em instâncias que usam replicação em nível de bloco. Por exemplo, não faça o seguinte. 

  ```
  --Don't do this
  ALTER DATABASE db1 SET PARTNER off
  ```
+ Não defina o modo de recuperação como `simple`. Por exemplo, não faça o seguinte. 

  ```
  --Don't do this
  ALTER DATABASE db1 SET RECOVERY simple
  ```
+ Não use o parâmetro `DEFAULT_DATABASE` ao criar novos login em instâncias de banco de dados multi-AZ, a menos que você use a replicação em nível de bloco para alta disponibilidade, porque essas configurações não podem ser aplicadas ao espelho em espera. Por exemplo, não faça o seguinte. 

  ```
  --Don't do this
  CREATE LOGIN [test_dba] WITH PASSWORD=foo, DEFAULT_DATABASE=[db2]
  ```

  Além disso, não faça o seguinte.

  ```
  --Don't do this
  ALTER LOGIN [test_dba] WITH DEFAULT_DATABASE=[db3]
  ```

# Determinar a localização do secundário
<a name="USER_SQLServerMultiAZ.Location"></a>

Determine a localização da réplica secundária usando o Console de gerenciamento da AWS. Você precisará saber a localização da secundária se estiver configurando a instância de banco de dados primária em uma VPC. 

![\[AZ secundária\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/SQLSvr-MultiAZ.png)


Também é possível visualizar a zona de disponibilidade da secundária usando o comando AWS CLI da `describe-db-instances` ou a operação da API do RDS `DescribeDBInstances`. O resultado mostra a AZ secundária onde o espelho em espera está localizado. 

# Migrar do Database Mirroring para Grupos de Disponibilidade Always On
<a name="USER_SQLServerMultiAZ.Migration"></a>

Na versão 14.00.3049.1 do Microsoft SQL Server Enterprise Edition, os Grupos de Disponibilidade (AGs) Always On estão sempre habilitados por padrão.

Para migrar do Database Mirroring (DBM) para AGs, verifique sua versão primeiramente. Se você estiver usando uma instância de banco de dados com uma versão anterior à Enterprise Edition 13.00.5216.0, modifique a instância a fim de atualizá-la para a 13.00.5216.0 ou posterior. Se você estiver usando uma instância de banco de dados com uma versão anterior à Enterprise Edition 14.00.3049.1, modifique a instância a fim de atualizá-la para a 14.00.3049.1 ou posterior.

Se você deseja atualizar uma instância de banco de dados espelhada para usar AGs, execute a atualização primeiro, modifique a instância para remover o Multi-AZ e depois modifique-a novamente para adicionar o Multi-AZ. Isso converterá a instância para usar AGs Always On.