Atenção: esse artigo tem um vídeo complementar. Clique e assista!
De que se trata o artigo?
Nesse artigo iremos abordar a solução de alta-disponibilidade Database Mirroring e características de seus diferentes modos de implementações, acompanhar a preparação de um ambiente de laboratório, configurar a sessão de espelhamento e realizar o monitoramento da base de dados espelhada, utilizando-se das recomendações do fabricante.
Para que serve?
Este artigo visa auxiliar profissionais no planejamento e configuração de um modelo de ambiente de alta-disponibilidade para bancos de dados de usuários, demonstrando não apenas como configurar e monitorar o recurso Database Mirroring, mas também seus principais conceitos e recomendações.
Em que situação o tema é útil?
Este tema é útil para profissionais e empresas que desejam ter uma visão ampla de uma opção de solução robusta para alta-disponibilidade de suas aplicações de bancos de dados, bem como familiarizar-se com os comandos de configuração do recurso em um ambiente com mais de uma instância de gerenciador de banco de dados.
Na preservação e controle sobre ativos de uma corporação, bancos de dados estão normalmente associados aos custos intangíveis. Assim, para grandes empresas, perder parte deste ativo poderá gerar prejuízos para todo o sistema, não associado apenas ao lado financeiro, mas também na preservação da imagem positiva e solidez da mesma.
Uma visão clara de o quanto a empresa está disposta a perder de seus bens intangíveis e por quanto tempo se aceita que seus serviços fiquem indisponíveis, direcionará a escolha apropriada para o modelo de alta-disponibilidade e contingência de dados no ambiente de tecnologia da informação.
Uma solução de alta-disponibilidade mascara os efeitos de uma eventual falha de hardware ou de software do servidor de rede, e mantém a disponibilidade de aplicações e serviços com o mínimo de impacto para os usuários, sendo em determinados momentos imperceptível para eles o tempo de ocorrência do problema.
Com o lançamento da versão SQL Server 2005, o administrador de banco de dados passou a ter quatro opções para criar ambientes de alta-disponibilidade em servidores de gerenciamento de bancos de dados: Failover Clustering, Log Shipping, Replication e Database Mirroring.
Failover Clustering
Um cluster de proteção a falhas é uma tecnologia que nos permite criar um ambiente de alta disponibilidade, onde um servidor passa a ter a capacidade de assumir as tarefas e responsabilidades de outro servidor em caso de uma falha de hardware ou software.
Normalmente é utilizado em cenários de missão crítica, em que é necessário ter hardwares específicos para sua configuração. Seu principal objetivo é diminuir o tempo de indisponibilidade de aplicações para os usuários finais em caso de falha.
Para configurar um cluster é necessário ter no mínimo dois servidores. Cada servidor configurado é representado como um nó e todos os nós são representados através de um servidor virtual, que fica disponível para os acessos realizados pelos usuários.
Este servidor virtual sempre aponta apenas para um nó, e caso este nó falhe por qualquer motivo, é realizado automaticamente um failover, onde o servidor virtual passará a apontar para o nó que estiver disponível. Este comportamento faz com que a ocorrência da falha em um dos nós do cluster se torne imperceptível ao usuário.
Ambos os nós utilizam o mesmo espaço e conteúdo em disco, e este espaço é disponibilizado através de uma solução conhecida como Storage.
Devido a todos os nós (servidores) utilizarem o mesmo espaço em disco (Storage), uma solução baseada em Cluster não protege contra falhas em disco, pois caso o dispositivo que armazena as informações falhe, mesmo que todos os nós estejam disponíveis, não haverá dados para ser acessado.
Aplicações como o SQL Server, quando utilizadas em Cluster, são instaladas em um grupo do Serviço de Cluster da Microsoft (MSCS), conhecido como Grupo de Recursos.
Failover Clustering é suportado na versão SQL Server Standard Edition com somente dois nós e na versão Enterprise Edition, onde o número máximo de nós do cluster depende da versão do sistema operacional Windows Server.
Log Shipping
Similar ao espelhamento de banco de dados, log shipping trabalha ao nível de banco de dados, mantendo um ou mais bancos de dados em espera, denominados Bancos de Dados Secundários.
Esta tecnologia permite enviar backups dos logs de transações realizados na base de dados principal para os servidores com as bases de dados secundárias. Estes logs são restaurados nas bases secundárias em intervalos de tempo que devem ser configurados pelo administrador de banco de dados.
Diferentemente do Database Mirroring, ao utilizar esta solução os bancos de dados secundários não recebem as atualizações realizadas na base de dados principal pelos usuários em tempo real. Este fato ocorre porque os logs contendo as transações realizadas pelos usuários são restaurados em períodos programados. No intervalo entre os períodos de restauração, a base de dados secundária permanece desatualizada.
Esta solução de alta disponibilidade deve ser utilizada em ambientes em que é aceitável uma pequena porcentagem de perda de dados ou como uma solução a mais de contingência, em conjunto com Cluster ou Mirror.
Log Shipping é suportado nas edições SQL Server Enterprise Edition, Standard Edition e Workgroup Edition.
Replication
Replicação é um conjunto de tecnologias capaz de copiar dados e/ou objetos de um banco de dados para outro, com objetivo de manter a consistência entre as bases de dados replicadas.
Sua configuração se dá através de um modelo de assinaturas e publicações, de forma que um servidor primário (Publicação) distribui os dados e/ou objetos para um ou mais servidores secundários, denominados Assinantes.
Diferente das soluções de Database Mirroring e Log Shipping que sincronizam todas as alterações realizadas na base de dados Principal, a replicação suporta filtros, que proporcionam aos usuários uma parametrização detalhada do que deve ser replicado.
O SQL Server oferece três tipos de replicação: Snapshot, Transactional e Merge. Cada tipo se comporta de uma maneira diferente e deve ser utilizada de acordo com cada cenário.
A replicação é indicada para aumentar a escalabilidade e disponibilidade em ambientes heterogêneos, onde deve-se, por exemplo, sincronizar bases de dados atualizadas por diferentes sistemas, ou centralizar informações de diversas origens.
A replicação é suportada em todas as edições do SQL Server 2005 e SQL Server 2008.
Database Mirroring
Database Mirroring (Espelhamento de Banco de Dados) é uma solução de software para aumentar a disponibilidade dos bancos de dados que mantém um único banco de dados recebendo todas as alterações realizadas no banco de dados Principal em “espera à quente”. Desta forma, se o banco de dados Principal se tornar indisponível o banco de dados espelhado se torna o Principal.
Pode ser utilizada como solução de alta disponibilidade individualmente, ou em conjunto com outras tecnologias como Cluster, Log Shipping e Replicação, aumentando assim a segurança e disponibilidade de aplicações de missão crítica.
Para configurar um espelhamento de banco de dados é necessário um servidor Principal contendo o banco de dados dos usuários, um servidor espelho, contendo o banco de dados espelhado e um servidor opcional (“inspetor”).
Database Mirroring mantém duas cópias de banco de dados em diferentes instâncias, transferindo porções do arquivo de log alterado por transações diretamente de um servidor para outro, e pode rapidamente realizar um failover para o servidor em espera.
A instância Principal (Principal Server) é utilizada pela aplicação do cliente enquanto a instância de espelhamento (Mirror Server) permanece em espera (standby), recebendo todas as atualizações realizadas na instância Principal. Normalmente estas instâncias estão em servidores de diferentes localizações.
O Database Mirroring trabalha com dois modos de operação, assíncrono ou “high-performance” e síncrono ou “high-safety”, onde a grande vantagem do modo síncrono é a garantia que no caso de um failover nenhum dado será perdido.
É suportado nas versões SQL Server 2005 Enterprise Edition SP1, Standard Edition SP1 e SQL Server 2008 Standard Edition ou superior.
High-Performance
No modo assíncrono a transação é confirmada para o usuário logo após o envio e gravação do commit no arquivo de log do servidor Principal. Neste modo, para o usuário receber a confirmação da transação, basta a confirmação do servidor Principal; não é necessária a confirmação da efetivação da transação no arquivo de log pelo servidor Mirror.
Como não é necessária a confirmação de atualização do Log no servidor Mirror, pode haver perda de dados. Em caso de falha no servidor Principal, ao realizar o failover, pode ocorrer perda das últimas transações confirmadas para o usuário, porém, não enviadas para o servidor Mirror.
A Figura 1 demonstra os eventos de uma transação no modo assíncrono:
1. Usuário submete uma nova transação;
2. A transação é enviada ao servidor Principal;
3. As alterações realizadas pela transação são gravadas no buffer cache;
4. As alterações realizadas pela transação são gravadas em disco no arquivo de log;
5. O servidor Principal recebe a confirmação que as alterações realizadas pela transação foram salvas em log;
6. A porção alterada do log pela transação é enviada para o Mirror;
7. O servidor Principal registra a porção alterada do log que foi enviada ao servidor Mirror através do mirroring_failover_lsn e retorna ao passo 3, onde, sem aguardar a resposta de confirmação do servidor Mirror, irá efetivar a confirmação da transação através de um commit inicialmente no buffer e depois em disco no arquivo de log;
8. O servidor Principal envia uma mensagem para o usuário com a confirmação da transação;
9. O servidor Mirror recebe a porção alterada do log e envia para o buffer cache;
10. A porção de log enviada pelo servidor Principal é gravada em disco no arquivo de log do servidor Mirror;
11. O servidor Mirror recebe a confirmação que a porção alterada do log foi gravada com sucesso em disco;
12. O servidor Mirror envia a confirmação para o servidor Principal informando que as transações recebidas foram gravadas no arquivo de log com sucesso;
13. O servidor Principal recebe a confirmação que as alterações em log, contendo o commit para a transação foram gravadas em disco e altera o número sequencial do log de transações do servidor Mirror.
Figura 1. Operação em modo assíncrono (High Performance)
High-Safety
No modo síncrono a transação só pode ser confirmada quando a mesma for realmente efetivada através do envio das alterações realizadas no log de transações do servidor Principal para o servidor espelho, de forma que, a base de dados espelhada esteja sempre na mesma posição que a base de dados Principal.
Neste cenário, caso ocorra um failover, não haverá perda de transações confirmadas, garantindo que o banco de dados antes espelho agora Principal tenha recebido todas as alterações realizadas na antiga base Principal.
A Figura 2 demonstra os eventos de uma transação no modo síncrono:
1. Usuário submete uma nova transação;
2. A transação é enviada ao servidor Principal;
3. As alterações realizadas pela transação são gravadas no buffer cache;
4. As alterações realizadas pela transação são gravadas em disco no arquivo de log;
5. O servidor Principal recebe a confirmação que as alterações realizadas pela transação foram salvas em log;
6. A porção alterada do log pela transação é enviada para o Mirror;
7. O servidor Principal registra a porção alterada do log que foi enviada ao servidor Mirror através do mirroring_failover_lsn e aguarda a confirmação do servidor Mirror da alteração em disco da porção de log enviada com as alterações realizadas pela transação;
...
