Overview AlwaysOn Availability Groups no RDS

Por: Fábio Oliveira

Neste artigo vou mostrar um pouco sobre o Availability Group no SQL Server RDS:

  1. O que é Multi-AZ

  2. Quais edições e versões suportam esta feature

  3. Endpoint de conexão

  4. Como adicionar uma base no AG

  5. Alguns testes como: – Consigo alterar o modo de sincronismo? – Consigo ler da minha réplica secundária? – Meus logins são replicados? – Meus Jobs são replicados?

Mas antes, precisamos reforçar alguns conceitos e o que é permitido hoje na AWS.

O que é o Multi-AZ para SQL Server?

Antes de darmos início é importante ter este conceito. Uma instância em Multi-AZ significa que ela será replicada de forma síncrona para uma diferente zona da AWS. A instância pode ser replicada utilizando Database Mirroring ou Availability Groups. Atualmente não é suportado Multi-AZ entre regiões distintas.

Multi-AZ tem para todas as edições e versões do SQL Server?

Não. Apenas instâncias igual ou maior à 2012 e no mínimo em Standard.

Quando minha instância terá um Mirroring ou um AG?

Depende de sua edição e versão:

  1. AlwaysOn Availability Groups:

SQL Server 2019: Standard and Enterprise Editions

SQL Server 2017: Enterprise Edition 14.00.3049.1 or later

SQL Server 2016: Enterprise Edition 13.00.5216.0 or later

  1. Database Mirroring (Exceto para as versões destacadas acima):

SQL Server 2017: Standard and Enterprise Editions SQL Server 2016: Standard and Enterprise Editions

SQL Server 2014: Standard and Enterprise Editions

SQL Server 2012: Standard and Enterprise Editions

A minha instância está configurada da seguinte forma com um SQL Server 2019 Enterprise com Multi-AZ habilitado: Obs.: A AWS fornece um mesmo endpoint para escrita e leitura.

Caso sua instância seja Standalone e você queira habilitar o Availability Groups, basta ir nas configurações da instância e marcar a opção:

Apresentado a instância acima, vamos realizar alguns testes.

Se eu criar um novo banco de dados, ele será adicionado automaticamente no AG?

Após alguns minutos:

Obviamente que o tempo irá considerar o tamanho do banco de dados. E também não conseguirá adicionar automaticamente caso a base seja criada no recovery model SIMPLE.

Posso alterar o modo de sincronismo?

Não, você não consegue. Uma vez que o conceito de Multi-AZ é justamente oferecer alta disponibilidade, com failover automático e sem perda de dados:

Consigo ler da minha réplica secundária?

Em ambientes On Premises a grande sacada do AG é você conseguir fazer o offload de queries, DBCCs entre outros nas réplicas secundárias. Porém na AWS não funciona desta forma:

E se alterarmos?

Como destacado no início, a AWS fornece um único endpoint listener para conectarmos à instância. Com isso, meus Jobs e logins são replicados?

Criei um Login chamado TesteLogin, com as permissões de db_datawriter e db_ddladmin.

Criado também um job chamado TesteJob:

Agora para verificar se foi replicado, temos que fazer o failover da nossa instância.

Mas antes vamos deixar anotado o nome do servidor primário no momento:

Para realizar o Failover vá até o console:

Internamente funciona como o On Premises, com todos os steps de um failover:

Confira o novo primário:

Meu login foi replicado com as mesmas permissões? Sim.

E quanto ao meu Job? Este não é replicado.

Como os Jobs são armazenados na msdb, o mesmo não está no AG, com isso não é replicado. Desta forma, temos que replicar de forma manual. Este é um ponto que incomoda um pouco, visto que a cada job que você criar/alterar num ambiente Multi-AZ, você terá sempre que fazer o failover para replicar esta alteração.

Caso queira remover esta feature, um ponto de atenção é que ao remover nas configurações da instância, ele removerá a réplica secundária.

Espero que tenham gostado deste overview sobre Availability Groups no RDS.

Fontes: Multi-AZ deployments for Amazon RDS for Microsoft SQL Server – Amazon Relational Database Service