Alta disponibilidade com Mirror e Log Shipping

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Aprenda neste artigo como criar o espelhamento de banco de dados e usar o recurso de Log Shipping.

Fique por dentro
O espelhamento de banco de dados (Mirror) surgiu com o SQL Server 2005 sendo um grande avanço e sucesso, pois foi a primeira solução de Disaster/Recovery sustentada pelo banco e é até hoje usada como solução redundância. Embora a Microsoft tenha sinalizado que, após a versão do SQL Server 2016, o Mirror será uma solução aposentada, ainda sim é muito importante o domínio dessa tecnologia, pois existem muitas empresas que ainda hoje usam até mesmo o SQL Server 2005, e não será de imediato que a grande maioria delas vai partir para a nova versão, sendo que muitas não migraram nem mesmo para a versão 2014. O Log Shipping é uma solução tanto para Disaster/Recovery quanto para aliviar a carga de leitura do banco de produção. Ele é um banco de dados em standby somente leitura. Dessa forma, você pode apontar instruções somente leitura para o banco de Log Shipping aliviando a carga de trabalho do banco de produção. Neste artigo você irá aprender como criar e manter um banco em Mirror assim como o Log Shipping.

O recurso de Mirror é importante ainda nos dias de hoje, pois fornece muitas vantagens, como a alta disponibilidade do banco de dados e a recuperação automática do banco. No caso de o servidor principal falhar, o servidor secundário pode assumir como banco principal de forma automática ou manual. Na forma automática, é necessária a configuração de um outro servidor chamado witness (Testemunha), sendo essa uma configuração opcional e que será apresentada também neste artigo.

Além de ser uma solução para prevenir possíveis desastres em sua base principal, o recurso de Mirror ainda pode aumentar a proteção a dados através da redundância completa ou semi completa dos dados. Nesse ponto, definimos se usamos uma configuração de sincronização síncrona ou assíncrona.

O novo recurso de AlwaysOn que foi lançado na versão 2012 do SQL Server é baseado no recurso de Mirror, sendo assim, é expressamente necessário o conhecimento de Mirror para a criação de recursos em AlwaysOn. Dessa forma, nos beneficiaremos também do Reparo de página automática. O banco de dados de espelhamento suporta o reparo automático de páginas de dados que estejam corrompidas ou apresentem algum tipo de erro que as tornam ilegíveis. No caso, um parceiro de banco de dados (sendo principal ou espelho) tenta recuperar automaticamente a página. O parceiro que não pode ler a página solicita uma nova cópia da página a partir do seu parceiro ou de uma réplica. Se esse pedido for bem-sucedido, a página ilegível é substituída pela cópia legível e o erro é corrigido.

Além disso, dentro do recurso de Mirror, podemos melhorar a disponibilidade do banco de produção durante as atualizações. Para isso, fazemos uso da atualização sem interrupção, na qual sincronizamos de forma sequencial as instâncias do SQL Server que estão hospedando os parceiros de failover.

Quando em Mirror, o SQL Server mantém duas cópias de um único banco de dados que deve residir em duas instâncias do SGBD. Basicamente, teremos uma instância de banco de dados sendo um servidor principal, esse principal será o servidor em produção onde clientes e sistemas fazem acessos constantes gerando relatórios, alimentando tabelas, executando procedures e outras transações. O outro servidor será o servidor secundário. Esse servidor estará arquivando constantemente arquivos de log transaction do servidor principal. Os clientes não acessam o servidor secundário, o mesmo fica em estado de Recovery apenas recebendo atualizações do servidor primário.

Os dois servidores irão intercalar entre os papéis de principal e secundário. Caso o servidor de produção, tido como principal, sofra algum problema e seu acesso fique indisponível, o servidor espelho, também chamado de secundário, irá assumir o papel de servidor primário no lugar daquele que ficou indisponível. Assim que restabelecido o servidor problemático, o mesmo volta como servidor de mirror, ou seja, secundário, e o outro servidor mantém seu novo papel como servidor de produção, ou primário.

Existe uma opção no recurso de mirror onde se inclui um terceiro servidor como sendo o servidor witness, ou servidor testemunha. Esse servidor não pode estar incluído em uma instância que participe do mirror. A vantagem de se ter um servidor witness é que todos os registros e atividades que ocorram no espelhamento são registrados nesse servidor, assim é possível reunir evidências para problemas que tenham ocorrido e tomar as devidas providências para que elas não ocorram novamente.

O nome “testemunha” é usado porque é esse servidor witness que avisa a um servidor mirror quando o principal fica indisponível, faz com que o servidor secundário passe a ser o principal e sinaliza ao antigo servidor principal para assumir o papel de secundário. Caso um novo erro aconteça no atual principal, os papéis se invertem de forma automática evitando uma indisponibilidade prolongada dos sistemas em operação na base de dados.

Modos de operação (síncrono ou assíncrono)

Uma configuração de espelhamento funciona através de duas formas de operação: síncrona ou assíncrona. Essas duas formas impactam diretamente a performance que você terá em um servidor mirror assim como a segurança dos dados. No " [...]

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Ficou com alguma dúvida?