Karuta’s ASP & M$ SQLserver

Dicas, códigos e outras coisinhas de meus estudos para não esquecer…

DATABASE MIRRORING

Posted by karuta em outubro 22, 2015

Surgido no SQL Server 2005 esta tecnologia consegue realizar a “cópia” da database do servidor primário e a disponibiliza para o servidor Mirror. Esta operação é realizada através da transferência dos registros do transaction log (Primário para o Mirror), aplicando assim todas as transações ocorridas. Vale ressaltar que o Database Mirroring é compatível com qualquer tipo de hardware suportado pelo SQL Server.

Servidor Primário: Servidor que será a referência para a aplicação armazenar seus dados.

Servidor Mirror: Este será o servidor espelho do servidor principal. O servidor Mirror irá permanecer no estado de restore e este não pode ser acessado diretamente.

Servidor Witness: Este servidor é responsável por monitorar a disponibilidade do servidor principal e em caso de falha o mesmo notifica as aplicações através de um parâmetro na string de conexão e assim direciona para o servidor secundário. Para maiores informações referente ao funcionamento e criação da string de conexão, disponibilizo para vocês uma publicação da Microsoft abordando este tema:

https://msdn.microsoft.com/subscriptions/index/ms175484

Observação: A solução Database Mirroring não permite o espelhamento das databases de sistema (Master, Msdb, Tempdb e Model.)

MODOS DE OPERAÇÃO

Possuímos três modos operacionais para o Database Mirroring, são eles:


TABELA 1: FUNCIONALIDADES.

Apresentaremos primeiro de forma resumida os modos operacionais e funcionalidades que o Database Mirroring nos possibilita, logo a diante iremos detalharemos os componentes envolvidos em cada modo (TRANSACTION SAFETY, WITNESS, FAILOVER).

Alta Disponibilidade

O modo de alta disponibilidade ou High Availability é o único que trabalha com o failover automático e com o servidor Witness. Para o seu funcionamento o mesmo necessitará operar de forma ¹síncrona, que nos garantirá que não haverá perda de dados.

Caso o servidor principal esteja indisponível, ocorrerá o processo conhecido como “role switching”, na qual significará que o servidor mirror assumirá o papel do servidor principal e quando servidor principal antigo retornar sua disponibilidade, este assumirá o papel de servidor Mirror.

Alta Proteção

O modo de alta proteção ou High Protection requer que o transaction safety seja definido como FULL, que representará que as transações deverão trabalhar de forma síncrona, garantindo assim que não haverá perda de dados, mas este também não nos garantirá a disponibilidade da aplicação, devido a não possuir um servidor Witness, tornando assim um failover manual.

Alta Performance

O modo de alta performance ou High Performance, é o modo mais performático (rápido) comparado com outros modos operacionais, isto se dá devido a possuir o modo de transação do tipo ²assíncrona, ou seja, a transação não necessita de ser efetivada em ambos os parceiros para confirmar a transação, entretanto este método não previne na perda de dados, caso ocorra a troca de papéis dos servidores primário e Mirror.

  TABELA 2: MODOS DE OPERAÇÃO

TRANSACTION SAFETY

Este irá definir o nível de segurança que a transação terá no Database Mirror, podendo ser operada de duas formas:

FULL: Virá configurada como default, este representará o nível máximo de     segurança, onde as transações serão operadas de forma ¹ Síncrona.

OFF: Este representará o modo de alto desempenho, onde as transações serão operadas de forma ² Assíncrona.

¹ Síncrona: Essa opção exige que ambos os servidores (Principal e Mirror) confirmem a transação antes que a mesma seja efetivada. Lembramos que este tipo de sincronização eleva o nível de latência das transações.

² Assíncrona: Ao contrário da síncrona, a assíncrona confirma a transação antes que a mesma seja efetivada em ambos os nós, tornando-a mais performática, entretanto esta não previne a perda de dados.

WITNESS

Este campo informará se o modo operacional utilizará o Witness.

FAILOVER

Failover Manual: Este failover requer uma ação manual do DBA para realizar a troca do servidor principal para o Mirror, não acarretando na perda de dados, devido ao tipo de failover operar de forma síncrona.

Failover Forçado: Este também realizará a transferência de forma manual do servidor primário para o servidor Mirror, entretanto este modo do failover possibilitará a perda de dados, isto se dá por possuir o tipo de transação assíncrona.

Failover Automático: Suportado apenas pelo modo operacional de Alta Disponibilidade, este necessita do Witness para realizar o failover automático em caso de falha do servidor principal.

 

Redigida por

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

 
%d blogueiros gostam disto: