Artigo
09/28/2010

Serviço forçado (com possível perda de dados)

O espelhamento de banco de dados fornece o forçamento do serviço (com possível perda de dados), como método de recuperação de desastres, para permitir o uso de um servidor espelho como servidor em espera passiva. Só é possível forçar o serviço se o servidor principal estiver desconectado do servidor espelho em uma sessão de espelhamento. Já que forçar o serviço pode ocasionar a perda de dados, esse recurso deve ser usado de forma cautelosa e moderada.

O suporte para o serviço forçado depende do modo operacional e do estado da sessão, conforme a seguir:

Normalmente, o modo de alto desempenho oferecerá suporte ao serviço forçado sempre que o servidor principal estiver desconectado. Entretanto, embora não seja necessário, pode haver uma testemunha para a sessão de modo de alto desempenho. Nesse caso, para forçar o serviço é preciso que o servidor espelho e a testemunha estejam conectados entre si.
O modo de segurança alta sem failover automático oferecerá suporte ao recurso para forçar serviço sempre que o servidor principal estiver desconectado.
O modo de segurança alta com failover automático oferece suporte ao forçamento do serviço sempre que o servidor espelho e a testemunha estiverem conectados entre si e nenhum dos dois estiver conectado ao servidor principal (contanto que o servidor espelho não esteja no processo de reversão do banco de dados espelho quando foi conectado ao principal pela última vez).

Recomendamos que o serviço seja forçado somente se for preciso restaurar imediatamente o serviço para o banco de dados e se estiver disposto a perder dados. O efeito do forçamento do serviço é similar à remoção de espelhamento, com exceção de que o forçamento do serviço facilitará a resincronização dos bancos de dados quando o espelhamento for reiniciado, com o risco de perda de dados. Forçar o serviço inicia uma transição uniforme da função principal para o banco de dados espelho. O servidor espelho assume a função de servidor principal e, imediatamente, serve sua cópia do banco de dados a clientes. O novo banco de dados principal é executado sem um espelho (ou seja, é executado exposto).

Importante
Se o servidor principal foi simplesmente desconectado da sessão de espelhamento de banco de dados e ainda estiver em execução, alguns clientes poderão continuar acessando o banco de dados principal original. Antes de forçar o serviço, é importante impedir que os clientes acessem o servidor principal original. Caso contrário, depois que o serviço for forçado, o banco de dados principal original e o banco de dados principal atual poderão ser atualizados de forma independente.

Se o servidor principal foi simplesmente desconectado da sessão de espelhamento de banco de dados e ainda estiver em execução, alguns clientes poderão continuar acessando o banco de dados principal original. Antes de forçar o serviço, é importante impedir que os clientes acessem o servidor principal original. Caso contrário, depois que o serviço for forçado, o banco de dados principal original e o banco de dados principal atual poderão ser atualizados de forma independente.

Casos comuns de serviço forçado

A figura a seguir ilustra um caso comum de serviço forçado (com possível perda de dados).

Serviço forçado com possível perda de dados

Na figura, o servidor principal original, Partner_A, torna-se indisponível para o servidor espelho, Partner_B, fazendo com que o banco de dados espelho seja desconectado. Após garantir que Partner_A não está disponível aos clientes, o administrador do banco de dados força o serviço, com possível perda de dados, no Partner_B. O Partner_B se torna o servidor principal e é executado com o banco de dados exposto (ou seja, sem estar espelhado). Nesse momento, os clientes podem reconectar-se ao Partner_B.

Quando Partner_A se torna disponível, reconecta-se ao novo servidor principal, associando-se novamente à sessão e assumindo a função espelho. A sessão de espelhamento fica imediatamente suspensa, sem sincronizar o novo banco de dados espelho. A suspensão da sessão permite que o administrador do banco de dados decida retomar a sessão ou, em casos extremos, remover e tentar recuperar os dados do antigo banco de dados principal. Nesse caso, o administrador do banco de dados escolhe retomar o espelhamento. Nesse momento, o Partner_A assume a função de servidor espelho e reverte o antigo banco de dados principal ao pont-in-time da última transação sincronizada com êxito; se nenhuma transação confirmada foi gravada em disco no servidor espelho antes de o serviço ser forçado, essas transações são perdidas. Em seguida, Partner_A confirma o novo banco de dados espelho, aplicando as alterações feitas no novo banco de dados principal, já que o servidor espelho antigo tornou-se o novo servidor principal.

Observação
Embora o modo de alto desempenho não exija testemunhas, caso uma seja configurada, só será possível forçar o serviço se a testemunha estiver conectada ao servidor espelho no momento.

Riscos de forçar o serviço

É essencial compreender que forçar o serviço pode causar perda de dados. É possível que haja perda de dados porque o servidor espelho não pode se comunicar com o servidor principal e, conseqüentemente, não pode garantir que os dois bancos de dados estejam sincronizados. O forçamento do serviço cria uma bifurcação da recuperação nova. Já que o banco de dados principal original e o banco de dados espelho estão em bifurcações da recuperação diferentes, cada banco de dados contém agora os dados que o outro banco de dados não tem: o banco de dados principal original contém as alterações que ainda não foram enviadas da sua fila de envio para o antigo banco de dados espelho (o log que não foi enviado); o antigo banco de dados espelho contém as alterações feitas depois que o serviço foi forçado.

Observação
Para obter mais informações sobre bifurcação da recuperação, consulte Caminhos de recuperação.

Se o serviço for forçado porque o servidor principal falhou, a perda potencial de dados dependerá se os logs de transação não foram enviado ao servidor espelho antes da ocorrência da falha. No modo de segurança alta, isso só é possível até que o banco de dados espelho esteja sincronizado. No modo de alto desempenho, o log não enviado acumulado é sempre uma possibilidade.

As implicações de se forçar o serviço dependem, em parte, se a sessão tem uma testemunha:

Na ausência de uma testemunha, o serviço poderá ser forçado se os parceiros forem desconectados, por exemplo, devido à interrupção na conexão de rede. Se o servidor principal original ainda estiver sendo executado, ambos os parceiros possuirão a função principal. Os clientes conectados ao novo servidor principal acessarão a versão atual do banco de dados, enquanto os clientes conectados ao servidor principal original acessarão o banco de dados principal original. Essa situação aumenta a possibilidade de perda de dados. Se os parceiros puderem reconectar-se, o servidor principal original assume a função espelho e altera o estado do seu banco de dados para "recuperando", antes que o espelhamento seja suspenso. Se a sessão for continuada, as transações no banco de dados principal original, cujo log estava na fila de envio na desconexão mais recente, serão perdidas. Além disso, todas as transações que ocorreram depois que o serviço foi forçado também serão perdidas.
Na presença de uma testemunha, se o servidor espelho estiver desconectado do servidor principal e da testemunha, contanto que os dois mais recentes permaneçam conectados entre si, o principal será executado exposto. Em seguida, se o servidor principal for desconectado da testemunha, o serviço ao banco de dados será interrompido. Posteriormente, se o servidor espelho reconectar-se à testemunha, será possível forçar o serviço. Se o serviço for forçado, todas as alterações feitas enquanto o servidor principal original estiver em execução serão perdidas caso o servidor principal original seja reconectado.

Para obter mais informações, consulte "Gerenciando a perda potencial de dados", mais adiante neste tópico.

Gerenciando a perda potencial de dados

Depois que o serviço é forçado, assim que o antigo servidor principal estiver disponível, pressupondo que o seu banco de dados não foi danificado, é possível tentar gerenciar a perda potencial de dados. A abordagem disponível para o gerenciamento da perda potencial de dados depende se o servidor principal original foi conectado ao seu parceiro e se une novamente à sessão de espelhamento. Presumindo que o servidor principal original pode acessar a instância principal nova, a reconexão ocorre de forma automática e transparente.

O servidor principal original foi reconectado

Normalmente, depois de uma falha, quando o servidor principal original reinicia, reconecta-se rapidamente ao seu parceiro. Na reconexão, o servidor principal original se torna o servidor espelho. Seu banco de dados se torna o banco de dados espelho e insere o estado recuperando antes de a sessão ser suspensa. O banco de dados espelho não será revertido a menos que o espelhamento seja continuado.

Entretanto, o banco de dados de recuperação não pode ser acessado, por isso, não é possível inspecioná-lo para avaliar os dados que seriam perdidos caso o espelhamento continuasse. Assim, a decisão de continuar ou remover o espelhamento depende se é aceitável a perda dos dados.

Se a perda dos dados for inaceitável, é necessário remover o espelhamento para resgatá-los.

A remoção do espelhamento permitiria que os administradores de banco de dados recuperassem o banco de dados principal original e tentassem recuperar os dados perdidos. Entretanto, quando o antigo banco de dados espelho fica online, os parceiros antigos estarão servindo bancos de dados divergentes com o mesmo nome. O administrador do banco de dados precisa tornar um dos bancos de dados inacessível aos clientes para evitar divergência posterior do banco de dados e para impedir problemas de failover do cliente.
Se perder todos dados for aceitável, será possível continuar o espelhamento.

Continuar o espelhamento faz com que o banco de dados espelho novo seja revertido, conforme a primeira etapa da sincronização do banco de dados. Se houver registros de log aguardando na fila de envio no momento da falha, as transações correspondentes serão perdidas, mesmo se tiverem sido confirmadas.

O servidor principal original não foi reconectado

Se for possível impedir temporariamente que o servidor principal original seja reconectado na rede ao servidor principal novo, você poderá inspecionar o banco de dados principal original para avaliar os dados que seriam perdidos caso o espelhamento continuasse.

Se a perda potencial de dados for aceitável

Permita que o servidor principal original reconecte-se a seu parceiro. A reconexão faz com que o espelhamento seja suspenso. Para continuar o espelhamento, simplesmente retome a sessão. O antigo servidor principal assume a função de espelho. O servidor espelho novo libera a bifurcação de recuperação original, perdendo as transações que nunca foram enviadas ou recebidas pelo servidor espelho antigo.
Se a perda de dados for inaceitável

Se o banco de dados principal contiver dados críticos que seriam perdidos caso a sessão continuasse, será possível preservar os dados no servidor principal original, removendo o espelhamento. Nós recomendamos que se tente fazer backup da parte final do log principal neste momento. Em seguida, é possível atualizar o servidor principal atual (antigo banco de dados espelho) exportando os dados que devem ser recuperados do banco de dados principal original e importando-os para o banco de dados principal atual. Recomendamos fazer um backup completo do banco de dados atualizado o mais rápido possível.

Para restabelecer o espelhamento com o banco de dados atualizado como banco de dados principal inicial, use esse backup (pelo menos, um backup de log subseqüente) para criar um novo banco de dados espelho. Todo backup de log feito depois que o espelhamento foi removido deve ser aplicado. Conseqüentemente, recomendamos que os backups de log adicionais do banco de dados principal sejam adiados até que a nova sessão de espelhamento seja iniciada.