Database Mirroring – Como fica o Backup do Log quando ocorre um Failover no Mirror
Olá Pessoal,
Esse será o último post de uma série com 12 posts sobre testes realizados com o Database Mirroring. Com a chegada do SQL Server 2012, o Database Mirroring parece ser uma tecnologia últrapassada, contudo, conseguimos implementar ele apenas no fim do ano passado em minha empresa. Até a migração do nosso ambiente para o SQL Server 2012, precisamos ter muito conhecimento sobre o Database Mirroring para saber como agir no dia a dia.
Para homologar o que acontece com os backups do log quando ocorre um failover no mirror, nesse teste foi feito um failover manual de uma instância A (AMBIENTE5) para uma instância B (AMBIENTE5\INST) e em seguida foi feito um failover de volta da instância B (AMBIENTE5\INST1) para a instância A (AMBIENTE5). Durante esses failovers, um loop de inserção de dados estava sendo executado nas duas instâncias e foi realizado vários backups do log nas duas instâncias gravando em um mesmo device.
1 – Inicialmente foi feito um backup FULL da database Mirror1 em uma instância do SQL Server chamada AMBIENTE5.
2 – Em seguida foi feito um backup do log da mesma base no device C:\Mirror1_Logs.bak.
3 – Para gerar inserções no log do SQL Server o loop abaixo foi iniciado:
while 1=1
begin
if exists (select null
from sys.databases
where name = ‘MIRROR1’ and state_desc = ‘ONLINE’)
insert into mirror1..Teste(texto)
select @@servername
End
4 – Após alguns segundos foi realizado outro backup do log no mesmo device que o passo 2.
5 – Após mais alguns segundos, com o loop do passo 3 sendo executado, foi realizado um failover manual da instância AMBIENTE5 para a instância AMBIENTE5\INST1 com o comando:
ALTER DATABASE Mirror1 SET PARTNER FAILOVER
6 – Agora conectado na instância AMBIENTE5\INST1, a database Mirror1 possui a role Principal do Database Mirroring. Nesse momento foi realizado um backup do log nessa base para o mesmo device do passo 2.
7 – Novamente foi deixado o loop do passo 3 executando, só que agora na instância AMBIENTE5\INST1.
8 – Após alguns segundos foi realizado outro backup do log no mesmo device que o passo 2.
9 – Realizando o mesmo processo do passo 5, foi feito um failover da instância AMBIENTE5\INST1 para a AMBIENTE5.
10 – Finalizando a sequencia de backups, com o loop já parado, foi realizado um último backup do Log na instância AMBIENTE5 para o mesmo device utilizado durante todo o teste.
Para visualizar a sequência de backups do log, pode-se abrir a tela de restore do backup device seguindo o caminho abaixo:
No Object Explorer do Management Studio-> Botão direito em Databases-> Restore Database… -> Em “Source for restore”-> Selecione “From device” e coloque o caminho do device utilizado:
Como é possível analisar na figura acima, seguindo a ordem da coluna “Position”, a sequência de backup começou na instancia AMBIENTE5, executou por duas vezes na instância AMBIENTE5\INST1 e voltou para a instância AMBIENTE5. Analisando as colunas “First LSN” e “Last LSN”, pode-se notar que o “LAST LSN” de um backup é o mesmo “FIRST LSN” do backup do Log seguinte, mesmo quando os backups são executados em instâncias diferentes.
Para finalizar o teste, foi realizado um restore do backup full realizado no Passo 1 do teste em uma database chamada “Mirror2” seguido de um restore dos 6 backups do log da figura acima.
Como pode ser visto na figura abaixo, a tabela onde os inserts foram realizados possui o mesmo número de registros na base restaurada (Mirror2), ou seja, os backups do log foram todos aplicados com sucesso na operação de restore.
Conclusão: O backup do log não é afetado quando temos um failover de uma database entre dois servidores configurados em uma solução de Database Mirroring.
Para Informação:
When you backup the log on the principal, the virtual log files (individual units within the log file) are marked as re-writable. The same VLF’s are marked as re-writable in the mirror log file as well. The VLF status is mirrored on the database.
Artigos relacionados:
Série de Posts sobre Database Mirroring
Database Mirroring – Como alterar o Operation Mode
Database Mirroring – Operation Mode High Performance – Parte 1
Database Mirroring – Operation Mode High Performance – Parte 2
Database Mirroring – Operation Mode High Performance – Parte 3
Database Mirroring – Operation Mode High Safety Without Failover – Parte 1
Database Mirroring – Operation Mode High Safety Without Failover – Parte 2
Database Mirroring – Operation Mode High Safety with Automatic Failover
Database Mirroring – Tempo Failover – HS With Automatic Failover com Timeout
Database Mirroring – Tirando o servidor de Witness do Mirror em caso de falha
Database Mirroring – Failover manual de várias bases ao mesmo tempo
Database Mirroring – Configurando um Snapshot no servidor Mirror
Gostou desse Post?
Cadastre seu e-mail para receber novos Posts e curta minha Página no Facebook para receber Dicas de Leituras e Eventos sobre SQL Server.
Abraços,
Fabrício Lima
MCITP – Database Administrator
Consultor e Instrutor SQL Server
Trabalha com SQL Server desde 2006