Por: Fábio Oliveira
Neste artigo vou mostrar um pouco sobre o Availability Group no SQL Server RDS:
O que é Multi-AZ
Quais edições e versões suportam esta feature
Endpoint de conexão
Como adicionar uma base no AG
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:
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
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