Espelhamento de banco de dados assíncrono (Modo de alto desempenho)
.gif "Observação") Observação |
|---|
O espelhamento de banco de dados assíncrono é suportado somente pelo SQL Server 2005 Enterprise Edition Service Pack 1 (SP1) e versões posteriores. |
Quando a segurança de transação está definida como OFF, a sessão de espelhamento de banco de dados opera de maneira assíncrona. A operação assíncrona dá suporte apenas a um modo de operação — modo de alto desempenho. Esse modo aumenta desempenho às custas de alta disponibilidade. O modo de alto desempenho usa apenas o servidor principal e o servidor espelho. Problemas no servidor espelho nunca causam impacto no servidor principal. Com a perda do servidor principal, o banco de dados espelho fica marcado como DESCONECTADO, mas está disponível em espera passiva.
O modo de alto desempenho oferece suporte apenas a uma forma de troca de função: serviço forçado (com possível perda de dados), que usa o servidor espelho como um servidor em espera passiva. O serviço forçado é uma das possíveis respostas à falha do servidor principal. Como a perda de dados é possível, devem ser consideradas outras alternativas antes de forçar serviço ao espelho. Para obter mais informações, consulte "Respondendo à falha do principal", mais adiante neste tópico.
A figura a seguir mostra a configuração de uma sessão que usa modo de alto desempenho.
.gif "Configuração de parceiro apenas de uma sessão")
No modo de alto desempenho, assim que o servidor principal envia o log para uma transação para o servidor espelho, o servidor principal envia uma confirmação para o cliente, sem esperar uma confirmação do servidor espelho. As transações são confirmadas sem esperar que o servidor espelho grave o log no disco. A operação assíncrona permite a execução do servidor principal com latência de transação mínima.
O servidor espelho tenta acompanhar os registros de log enviados pelo servidor principal. Mas, o banco de dados espelho pode ficar um pouco atrasado em relação ao banco de dados principal, embora normalmente a lacuna entre os bancos de dados seja pequena. Entretanto, a lacuna pode ser significativa se o servidor principal estiver com grande carga de trabalho ou se o sistema do servidor espelho estiver sobrecarregado.
Quando o modo de alto desempenho é apropriado?
O modo de alto desempenho pode ser útil em um cenário de recuperação de desastre no qual os servidores principal e espelho estão separados por uma distância significativa e onde você não deseja que erros pequenos causem impacto ao servidor principal.
| Observação |
|---|
O envio de logs pode ser um suplemento ao espelhamento de banco de dados e uma alternativa favorável ao espelhamento de banco de dados assíncrono. Para obter informações sobre as vantagens do envio de logs, consulteVisão geral das soluções de alta disponibilidade. Para obter informações sobre como usar o envio de logs com espelhamento de banco de dados, consulte Espelhamento de banco de dados e envio de logs. |
O impacto de uma testemunha no modo de alto desempenho
Se você usar a Transact-SQL para configurar o modo de alto desempenho, sempre que a propriedade SAFETY for definida como OFF, é altamente recomendável que a propriedade WITNESS também seja definida como OFF. Uma testemunha pode coexistir com modo de alto desempenho, mas a testemunha não fornece nenhum benefício e representa um risco.
Se a testemunha estiver desconectada da sessão quando qualquer parceiro abaixar, o banco de dados ficará indisponível. Isso ocorre por que mesmo com o modo de alto desempenho não exigindo testemunhas, se uma delas é definida, a sessão exige um quorum que consista em duas ou mais instâncias do servidor. Se a sessão não tem quorum, não pode servir o banco de dados.
Quando uma testemunha é definida em modo de alto desempenho, a aplicação de quorum significa que:
Se o servidor espelho for perdido, o servidor principal deve ser conectado à testemunha. Caso contrário, o servidor principal deixa seu banco de dados offline até que a testemunha ou o servidor espelho se reúna novamente à sessão.
Se o servidor principal for perdido, forçar o serviço para o servidor espelho exige que o servidor espelho esteja conectado à testemunha.
| Observação |
|---|
Para obter mais informações sobre os tipos de quoruns, consulte Quorum: como uma testemunha afeta a disponibilidade do banco de dados. |
Respondendo à falha no principal
Quando o principal falhar, o proprietário do banco de dados tem várias escolhas, como se segue:
Deixar o banco de dados indisponível até que o principal fique disponível novamente.
Se o banco de dados principal e seu log de transações estiverem intactos, essa escolha preserva todas as transações confirmadas às custas da disponibilidade.
Interrompa a sessão de espelhamento de banco de dados, atualize manualmente o banco de dados e, então, inicie uma nova sessão de espelhamento de banco de dados.
Se o banco de dados principal estiver perdido mas o servidor principal ainda estiver sendo executado, tente imediatamente fazer o backup da parte final do log no banco de dados principal. Se o backup da parte final do log for bem-sucedido, a remoção do espelhamento pode ser a melhor alternativa. Após a remoção do espelhamento, é possível restaurar o log no banco de dados espelho anterior, que preserva todos os dados.
ObservaçãoSe o backup da parte final do log falhar e você não puder esperar pela recuperação do servidor principal, considere forçar o serviço, que tem a vantagem de manter o estado da sessão.
Serviço forçado (com possível perda de dados) no servidor espelho.
O serviço forçado é estritamente um método de recuperação de desastres e deve ser usado com moderação. Forçar um serviço é possível somente se o servidor principal não estiver conectado, a sessão for assíncrona (a segurança de transação estiver definida como OFF) e quando a sessão não tiver qualquer testemunha (a propriedade WITNESS estiver definida como OFF) ou a testemunha estiver conectada ao servidor espelho (ou seja, quando houver quorum).
Forçar um serviço leva o servidor espelho a assumir a função de principal e a disponibilizar sua cópia do banco de dados aos clientes. Quando o serviço é forçado, quaisquer logs de transação que o principal ainda não tiver enviado ao servidor espelho serão perdidos. Assim, deve-se limitar o serviço forçado a situações onde a possível perda de dados é aceitável e a disponibilidade imediata do banco de dados é crítica. Para obter informações sobre o funcionamento do serviço forçado e sobre as práticas recomendadas, consulte Serviço forçado (com possível perda de dados).