Como configurar a geo-replicação em um Azure SQL Database

Olá pessoal, tudo certo?

No post de hoje vou dar continuidade ao post anterior “Criando um banco de dados Azure SQL Database“. Agora vamos configurar a replicação geográfica de banco de dados.

O Azure disponibiliza a opção de replicarmos as nossas bases de dados para outra região ou na mesma. Também podemos configurar até 4 réplicas. Esses bancos de dados ficam habilitados para leitura e failover em caso de falha da base de dados primária. O serviço de replicação geográfica está disponível para todos os tier de serviço e em todas as regiões.

Oficialmente podemos realizar somente failover manual, mas já está em preview a possibilidade de efetuar o failover automático. Entretanto, com a limitação de apenas uma replica secundária (“lembrando que isso pode mudar com o tempo“), enquanto como já foi dito no caso de failover manual podemos ter até 4 réplicas.

Quando estamos utilizando a replicação geográfica, se por algum motivo o banco ficar indisponível ou ser necessário ficar offline, será possível fazer o failover para qualquer réplica configurada. Após o failover, a atualização do DNS é realizada automaticamente.

O serviço de replicação do Azure SQL Database utiliza a mesma tecnologia do Always On, existente desde o SQL Server 2012. A replicação é feita de forma assíncrona, onde as transações comitadas no banco de dados primário utilizam o RCSI (read committed snapshot isolation). Embora o banco de dados secundário possa estar um pouco defasado em relação ao banco de dados primário, os dados secundários têm a garantia de nunca terem transações parciais.

Os bancos de dados secundários podem ser utilizados para leitura e geração de relatórios. Se você estiver usando replicação geográfica, é possível criar o banco de dados secundário na mesma região que o primário, mas isso não significa que estamos aumentando a resiliência a falhas. Se você configurar a replicação com failover automático, os bancos de dados secundários terão que ser criados em uma região diferente.

Todas as réplicas devem ter as mesmas configurações que a base de dados principal, ou seja, se a sua base foi configurada utilizando 200 DTUs, as réplicas também devem ser configuradas com 200 DTUs. Não é possível criar a base de dados principal utilizando DTUs e as réplicas utilizando vCore.

Configurando a Replica Geográfica

Para fazer a configuração de uma réplica, você pode utilizar alguns meios conhecidos como Powershell ou pelo Portal de Gerenciamento. Como não conheço muito o Powershell, vou utilizar o portal de gerenciamento.

Primeiro devemos entrar no Portal de Gerenciamento.

Após entrar no portal, devemos abrir o dashboard da base de dados.

No painel esquerdo teremos a opção “Geo-Replication“. O primeiro passo é escolher em qual região vamos criar a nossa réplica, lembrando que quanto mais perto ela estiver de você menor será a latência.

Como a minha base de dados está alocada na região East US, e a minha assinatura não me permite criar em outra região então vou manter a réplica no East US.

Após selecionar a região da réplica, agora precisamos configurar um novo servidor. Observe que as opções de configuração de preços ficam desabilitadas, porque vamos utilizar as mesmas configurações da base de origem.

Após a conclusão da configuração da base de dados e do servidor, elas ficarão disponíveis no Portal de Gerenciamento após alguns instantes.

Conectando utilizando o SSMS

Para fazer uma conexão na base de dados, podemos utilizar o Management Studio ou próprio painel gerenciamento. Para conectar através do Management Studio, basta pegar a URL de acesso.

O processo para acessar a base de dados da réplica é o mesmo para acessar a base de dados principal. Primeiro precisamos criar uma regra no firewall.

Após criar a regra no firewall, você consegue acessar a base de dados replicada e fazer consultas.

Se eu tentar inserir um novo registro no servidor da réplica, será exibido o erro abaixo, pois a réplica é somente leitura.

Realizando um failover manual

Você pode iniciar um failover forçado ou programado (com sincronização total de dados). O failover programado pode ser usado para realocar o servidor ativo para a região primária. Quando o failover estiver concluído, os registros do DNS serão atualizados automaticamente para garantir a conectividade com o servidor correto.

Para efetuar um failover manual, precisamos conectar no portal de gerenciamento e abrir a nossa database.

No painel de gerenciamento do servidor, devemos abrir a database..

No painel de gerenciamento da database, no painel esquerdo devemos abrir as configurações da replicação “Geo-Replication“.

No painel de gerenciamento “Geo-Replication”, devemos selecionar a nossa replicação.

Nas configurações devemos selecionar a opção “Forced Failover”.

Após realizar o failover, a nossa base principal passou a ser a réplica.

Recomendação de quando utilizar o failover

Você pode realizar um upgrade ou downgrade de um banco de dados primário para um nível de desempenho diferente, dentro do mesmo tier de serviço sem desconectar nenhum banco de dados secundário. Ao realizar um upgrade, a Microsoft recomenda que você atualize primeiro o banco de dados secundário e depois, atualize o primário.

Para realizar uma operação de downgrade, inverta a ordem: faça primeiro o downgrade do banco de dados primário e depois, faça no secundário. Essa é a recomendação da Microsoft quando você faz um upgrade ou downgrade do banco de dados para um tier de serviço diferente.

Se você quiser conhecer mais sobre a replicação no Azure, o Fabricio Lima fez um vídeo sobre replicação “Azure SQL Database – Permitindo que sua empresa pequena tenha uma base replicada“.

Bom pessoal, por hoje é isso espero ter ajudado e ter agregado algum conhecimento novo a vocês.

Qualquer dúvida deixe um comentário.

Abraços,

Tiago Neves