Implantações multi-AZ para o Amazon RDS for Microsoft SQL Server - Amazon Relational Database Service

Implantações multi-AZ para o Amazon RDS for Microsoft SQL Server

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 oferece suporte a implantações Multi-AZ para Microsoft SQL Server usando o SQL Server Database Mirroring (DBM) ou grupos de disponibilidade Always On (AGs). 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 ou AGs. O Amazon RDS processa as instâncias primária, testemunha e de banco de dados secundária para você. Como a configuração é automática, o RDS selecione DBM ou Always On AGS 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

  • SQL Server 2014: Standard e Enterprise Editions

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:

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

Ao criar uma nova instância de banco de dados do SQL Server usando o AWS Management Console, você pode adicionar Multi-AZ com Database Mirroring (DBM) ou AGs Always On. Faça isso selecionando Yes (Mirroring / Always On) (Sim (Mirroring/Always On)) na Multi-AZ deployment (Implantação Multi-AZ). Para obter mais informações, consulte Criar uma instância de banco de dados do Amazon RDS.

Ao modificar uma instância de banco de dados do SQL Server existente usando o console, você pode adicionar multi-AZ com DBM ou AGs escolhendo Yes (Mirroring / Always On) (Sim (Mirroring/Always On)) na lista Multi-AZ Deployment (Implantação multi-AZ) na página Modify DB Instance (Modificar instância de banco de dados). Para obter mais informações, consulte Modificar uma instância de banco de dados do Amazon RDS.

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 2014, 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, não será necessário realizar essa etapa.

Remover multi-AZ de uma instância de banco de dados do Microsoft SQL Server

Ao modificar uma instância de banco de dados do SQL Server existente usando o AWS Management Console, você pode remover multi-AZ com DBM ou AGs. Para fazer isso, escolha No (Mirroring / Always On) (Não (Mirroring/Always On)) em Multi-AZ deployment (Implantação multi-AZ) na página Modify DB instance (Modificar instância de banco de dados). Para obter mais informações, consulte Modificar uma instância de banco de dados do Amazon RDS.

Limitações, observações e recomendações de implantação multi-AZ do Microsoft SQL Server

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

  • 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 AWS Support. 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.

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 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 ou AGs oferece suporte a 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 para implantações multi-AZ.

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

  • 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 obter a melhor performance, não habilite o Database Mirroring ou os AGs Always On 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. 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, 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] SET DEFAULT_DATABASE=[db3]

Determinar a localização do secundário

Determine a localização da réplica secundária usando o AWS Management Console. 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

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

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.