Trabalhar com gerenciamento de dados é uma atividade de alto nível de criticidade no que diz respeito à segurança e integridade das informações. Sabendo disso, torna-se compreensível o quão fundamental é garantir que os sistemas de gerenciamento operem de forma ininterrupta e mantenham os dados íntegros em qualquer circunstância. Isso quer dizer que, mesmo em cenários diversos, como desastres naturais, falhas a nível de hardware ou determinada situação que possa causar instabilidade, o sistema deve permanecer disponível e funcional.

Basicamente, essa é a ideia de business continuity, um conjunto de práticas que assegura a disponibilidade de um negócio e minimiza os impactos gerados por eventuais incidentes. Com esse intuito, são utilizadas as estratégias de High Availability (Alta Disponibilidade) e Disaster Recovery (Recuperação de Desastres) em ambientes como os Sistemas de Gerenciamento de Banco de Dados ou em Plataformas Cloud.

Para simplificar a compreensão desses métodos, podemos pensar em um cenário em que eles são aplicáveis, como é o caso de uma base de dados utilizada por um hospital. Nessa circunstância, a base contendo informações como histórico de pacientes, medicações, procedimentos cirúrgicos e demais dados, não pode ficar indisponível e, se ficar, deve ser pelo menor período de tempo possível. Além disso, perdas significativas dos dados não podem acontecer nesse contexto e, por esse motivo, utilizam-se os mecanismos de HA e DR.

High availability

Basicamente, High Availability diz respeito à capacidade de um sistema manter-se disponível 24/7 e com o mínimo de interrupções possível, para que os dados estejam sempre acessíveis. Para atingir isso, uma das principais estratégias é utilização da redundância de serviços ou bases, seja de forma física (on-premise) ou lógica (cloud), para garantir a existência de um componente extra que possa assumir o funcionamento caso o principal seja interrompido.

Em um ambiente on-premise a redundância é aplicada principalmente em componentes que gerenciam a hospedagem e armazenamento dos dados, que é o caso dos servidores e discos, podendo fazer o mesmo procedimento com redes e fontes de energia. Além desse processo, ao utilizar o SQL Server como gerenciador de banco de dados, existem as seguintes features (principais) que permitem construir HA no ambiente:

• Always On Availability Groups (AG):

Método que permite a replicação de bancos de dados entre diferentes instâncias do SQL Server. Cada transação realizada em uma base é enviada para outra instância (réplica), que mantém uma cópia do banco de dados. O envio dos dados da instância primária para a instância secundária pode ser feito de forma síncrona ou assíncrona, conforme as necessidades de consistência e desempenho do ambiente. Quanto ao failover nesse modelo, existem duas opções: automático, em que a falha é detectada pelo Windows Server Failover Cluster (WSFC) e inicia imediatamente o failover, ou manual, que é ativado pelo administrador de banco de dados em manutenções planejadas por exemplo, permitindo maior controle sobre o processo.

Nesse caso, se a instância primária falhar, a instância secundária pode assumir o funcionamento como instância primária, garantindo a continuidade do serviço. Além disso, utilizando AGs não há compartilhamento de armazenamento, ou seja, as instâncias têm as informações sincronizadas mas com seus próprios arquivos locais. Os Availability Groups podem ser aplicados tanto nas edições Standard quanto Enterprise do SQL Server, sendo que a última opção permite deixar a réplica como Read Only.

• Always On Failover Cluster Instances (FCIs):

Os FCIs têm o mesmo intuito que o AG, porém, a nível de instância. Em suma, são duas instâncias com a mesma nomenclatura que operam em servidores diferentes, mas que são vinculados ao mesmo armazenamento. Um único FCI é uma instância do SQL Server em nodes do Windows Server Failover Clustering (WSFC), um cluster composto por dois ou mais nodes (servidores) que utilizam um disco compartilhado. Esse esquema de compartilhamento faz com que os dados estejam disponíveis para todos os nodes, não apenas para aquele da instância primária.

Sendo assim, se o node primário apresenta alguma falha a nível de hardware, S.O, aplicação ou outra estrutura, todos os componentes de uma instância do SQL Server (bancos, logons, jobs…) serão movimentados para outro nó do WSFC. E, assim como no AG, o failover pode ser configurado para ser ativado manualmente ou automaticamente ao detectar uma falha.

• Database Mirroring:

Essa tecnologia, como o próprio nome sugere, realiza o espelhamento síncrono ou assíncrono (se a edição do SQL Server for Enterprise) de uma base de dados para outro servidor, para que, caso o servidor principal fique indisponível, os dados permaneçam acessíveis e atualizados. Para esse processo, configura-se uma base de dados principal (Recovery Model Full) em uma instância e a base secundária (espelhada) em outra instância, que recebe as transações realizadas no ambiente primário enquanto permanece em standby. Essas transações são feitas por meio do Transaction Log do banco primário, portanto, alterações e exclusões de dados feitos no banco principal também são feitas no banco espelhado.

Nessa feature, o failover também pode acontecer de forma manual ou automática, dependendo da infraestrutura e das necessidades do ambiente em que será aplicado.

Disaster Recovery

Disaster Recovery (DR) é o conjunto de estratégias e procedimentos aplicados com a finalidade de recuperar dados e aplicações em casos de eventos como desastres naturais, falhas de hardware, erros humanos e outros incidentes que possam causar perdas significativas. O objetivo do DR frente a essas situações é minimizar o tempo de inatividade e a perda de dados.

Os tópicos a seguir abordam algumas técnicas de DR em ambientes on- premise (SQL Server) e cloud (Azure).

• Backup e Restore

Estratégia simples e clássica de DR que se resume em rotinas de backup dos bancos de dados para que, em caso de desastre, os dados mais recentes possíveis possam ser restaurados.

• Log Shipping

Essa técnica envolve o envio contínuo de backups de log de transações de um banco de dados primário para um ou mais servidores secundários, automatizados por jobs de backup e restore na base secundária. Esses backups contêm arquivos de log com todas as operações de modificação de dados (inserção, atualização, exclusão) que ocorreram no banco de dados de origem desde a última cópia de log.

Em caso de falha do servidor principal, um dos servidores secundários pode ser promovido para o papel de servidor primário (podendo realizar leitura/escrita), já que os bancos de dados de destino estão sincronizados com o banco de dados de origem. Essa ação é feita de forma assíncrona (manual), por isso, deve-se ter o conhecimento de que podem existir delays nas informações e perda de dados.

• SQL Server Replication

A estratégia de replicação é uma tecnologia do SQL Server que realiza a duplicação e, posteriormente, a distribuição de objetos e dados de uma base para outra. Existem três principais tipos de replicação no SQL Server: Snapshot replication, Transactional replication e Merge replication.

Uma replicação do tipo Snapshot é feita a partir de uma cópia de um banco feita no publisher (base de origem) em determinado momento e enviado ao subscriber (base de destino), ideal para ambientes com bancos pequenos/médios e pouca movimentação e alteração dos dados.

As replicações do tipo Transacional são realizadas através de cópias das transações identificadas no publisher (registradas em arquivos de log) para o subscriber praticamente em tempo real. Esse modelo é ideal para ambientes que contam com alterações mais frequentes e necessitam de dados atualizados e íntegros em ambas as bases (origem e destino).

Já a estratégia de replicação Merge permite que a sincronização das bases aconteça independente de onde as alterações foram feitas (banco de origem ou réplicas). Nesse sentido, ambos bancos podem ser modificados estando conectados ou não, já que, quando a conexão é restabelecida, os dados são sincronizados continuamente, de forma programada ou sob demanda.

Em resumo, enquanto os objetivos de High Availability e Disaster Recovery são os mesmos em qualquer circunstância, os recursos e funcionalidades são divergentes devido às características únicas de cada ambiente. A escolha de qual estratégia será adotada é feita a partir da análise das necessidades e dos recursos disponíveis em cada empresa, mas a garantia de disponibilidade contínua e a recuperação rápida sempre serão essenciais para manter a continuidade dos negócios.

Esperamos ter te ajudado a entender um pouco mais sobre as ferramentas de HA e DR do SQL Server.

Até o próximo post, Pessoal! 😊