Database Mirroring – Operation Mode High Performance – Parte 3 – Fabricio Lima

Database Mirroring – Operation Mode High Performance – Parte 3

31 de maio de 201224 de julho de 2016Fabrício LimaAdministração de Banco de Dados, Virtual PASS BR

Fala Pessoal,

Neste post continuarei o teste do Operation Mode High Performance. Caso ainda não tenham visto os posts anteriores, sugiro que os leia antes de continuar:

Database Mirroring – Operation Mode High Performance – Parte 1

Database Mirroring – Operation Mode High Performance – Parte 2

Novamente, com o loop de insert rodando no servidor A (Principal), para esse teste, eu parei o serviço do SQL Server do servidor A:

Contudo, dessa vez o pessoal da infraestrutura não conseguiu resolver o problema do Servidor A. Logo, eu tive que acabar com o mirror para que o Log da database do servidor B não ficasse crescendo sem parar.

Para acabar com o mirror, executei o comando: alter database mirror1 set partner off

Logo após, rodando a query abaixo, é possível ver que o mirror não existe mais:
SELECT db.name, mirroring_state_desc, mirroring_safety_level_desc,mirroring_witness_state_desc
FROM sys.database_mirroring m
JOIN sys.databases db ON db.database_id = m.database_id
where name = ‘Mirror1’

Mesmo com o mirror não existindo mais, a base do servidor B continua com o status restoring:

Para deixá-la online, deve-se rodar o comando: restore database mirror1 with recovery

Entretanto, ao executá-lo, recebi o seguinte erro:

Msg 5094, Level 16, State 2, Line 1
The operation cannot be performed on a database with database snapshots or active DBCC replicas.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

Isso aconteceu porque eu tinha um snapshot na database do servidor B que era o mirror.

Esse snapshot deve ser excluído com o comando abaixo:
drop database mirror1_snapshot

Onde Mirror1_Snapshot é o nome da database snapshot que eu criei. Posteriormente farei um post sobre database snapshot no database mirroring.

Executando o comando “restore database mirror1 with recovery” novamente, a database ficou online.

Algum tempo depois a galera da Infraestrutura abriu um chamado no fornecedor de Hardware e conseguiram voltar o servidor A. Ao fazer isso, a database desse servidor também ficou online automaticamente. Isso pode gerar um problema grave, pois imagina se existirem muitas aplicações e serviços apontando para o servidor A. Quando o servidor A morre e o servidor B passa a receber as aplicações e serviços, ele se torna o servidor com dados mais atualizados. Agora, imagina que você esqueceu de redirecionar alguma aplicação ou serviço do servidor A para o B, quando o servidor A fica disponível, suas aplicações e serviços podem ficar manipulando dados no servidor A e B. Isso vai gerar um GRANDE problema dependendo do tamanho do seu ambiente. Então, deve-se ter um cuidado especial com essa situação e mapear TODAS as aplicações e serviços que utilizam uma database presente em um Database Mirroring.

Uma solução para isso seria um redirecionamento de DNS. As aplicações utilizariam um ALIAS chamado DBProducao e esse ALIAS apontaria para um servidor físico chamado ServerA com IP 192.0.0.1. Caso aconteça algum problema com esse servidor, o database mirror fará um failover para o serverB com IP 192.0.0.2. Assim, basta você realizar o redirecionamento de DNS do Alias DBProducao para que ele responda pelo IP 192.0.0.2. Com isso, não existe o risco de nenhuma aplicação ou serviço gravar dados em um local indevido.

Continuando o teste, agora vamos verificar como ficou a sincronização dos dados entre os dois servidores com a volta do servidor A.

O servidor B (ambiente5\inst1) que era o mirror, possui dados até o Cod e data abaixo:
Cod: 32610 Data: 2012-01-05 15:25:12.710

Após o servidor A (que era o Principal) ficar online, executei a query abaixo para selecionar os dados que existiam no servidor A, mas ainda não haviam sido espelhados para o servidor B:

select * from mirror1..Teste where cod >= 32610 order by data desc

Comparando o resultado cheguei à conclusão:

Perdi dados de 2012-01-05 15:25:12.710 até 2012-01-05 15:25:22.747, ou seja, 10 segundos.

Isso porque meu ambiente estava fazendo apenas um insert em uma tabela. Agora imagina em um ambiente grande onde a quantidade de dados atualizados é alta. A perda de dados seria considerável. Contudo, ela ainda pode ser menor do que se você tivesse apenas uma rotina de backup e perdesse os arquivos de log de alguma database. Nesse caso, você não conseguiria salvar o Tail Log e só teria os backups do log já realizados. Como esse job deve rodar a cada 5 minutos, por exemplo, a perda de dados pode ser muito maior do que em um mirror com High Performance.

Database Mirroring – Operation Mode High Performance – Parte 3

Curtir isso:

Relacionado

Deixe uma respostaCancelar resposta

Compartilhe isso:

Curtir isso:

Relacionado

Deixe uma respostaCancelar resposta