Grande parte dos Sistemas de Gerenciamento de Banco de Dados (SGBDs) do mercado possuem funcionalidades voltadas para alta disponibilidade, que é uma prática comum em empresas que querem diminuir o Tempo de Recuperação (RTO) após um desastre.

Quando os servidores que hospedam os dados de negócio sofrem um ataque ou uma pane – que impede a continuidade do serviço – algumas das primeiras coisas pensadas são: Será que houve perda de dados? Em quanto tempo consigo restabelecer meus serviços?

Para situações como esta, é necessário um planejamento prévio do que fazer para diminuir a indisponibilidade, mas também existem diversas ações que podem ser tomadas para evitar uma perda considerável de informações e acelerar a volta da operação.

Se tratando de bancos de dados MS SQL Server, existe uma funcionalidade que pode auxiliar quem procura deixar os dados do banco disponíveis de maneira mais rápida em caso de desastres, estamos falando do database mirroring.

Sobre o database mirroring

Primeiramente, ele é uma funcionalidade que faz a cópia síncrona ou assíncrona das bases de dados de uma instância, fazendo com que os dados sejam copiados para um servidor secundário ativo.

É importante salientar que o processo síncrono pode afetar mais o desempenho, porém gera mais segurança no que se refere a perda mínima de dados. Já o processo assíncrono foca mais no desempenho, enviando dados entre servidores em tempos mais espaçados e cabe ao dono do negócio optar pelo o que é prioridade.

Tecnicamente falando, para o database mirroring funcionar precisa-se de, no mínimo, outra instância ao qual os dados serão replicados.

Recomenda-se que essas instâncias estejam em servidores e locais físicos apartados, a fim de potencializar a disponibilidade evitando que uma queda de luz ou pane no servidor venha deixar ambas inutilizadas.

Como funciona?

Na instância A será configurado a base, que será principal e nela estão todos dados gravados pela aplicação. Na instância B está a base espelho, que fica em standby recebendo informações da base da instância A a medida que novos dados estão sendo salvos.

Em caso de indisponibilidade na instância A, deverá ser realizado um failover manual para que a instância B se torne a principal.

Uma alternativa ao failover manual é criar uma instância chamada de testemunha, usada para monitorar a atividade das instâncias principal e espelho. Em caso de indisponibilidade, o failover ocorre de forma automática.

Dentre as vantagens do processo está a velocidade no restabelecimento do serviço, no entanto, um ponto de atenção é que tudo que está gravado na base da instância A também será gravado na base da instância B, logo, uma remoção de dados em A ocasionará um remoção de dados em B.

Independente do processo de failover automático ou manual, os dados do SGBD da base que está sendo espelhada estarão disponíveis de forma mais rápida, cabendo à equipe de TI do cliente apontar suas aplicações para o segundo endereço, encurtando bastante o tempo de indisponibilidade.

Pensa em diminuir o tempo de indisponibilidade do seu banco de dados? Deseja espelhar uma base de dados específica? A AMT pode te ajudar! Clique aqui para falar com um de nossos especialistas.

Wallace Mendes
Especialista em Banco de Dados na AMT