Limitações, observações e recomendações de implantação multi-AZ do Microsoft 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, 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.

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.

O Amazon RDS expõe o endpoint de listener do grupo de disponibilidade 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.

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.

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.

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.

Para bancos de dados usados em produção ou pré-produção, recomendamos as seguintes opções:

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]