Sessões de espelhamento de banco de dados
O espelhamento de banco de dados ocorre no contexto de uma sessão de espelhamento de banco de dados. Este tópico assume que você esteja familiarizado com funções principais, de espelhamento e de testemunha, modos de operação e troca de função no espelhamento de banco de dados. Para obter mais informações, consulte Visão geral do espelhamento de banco de dados.
Quando o banco de dados espelho estiver pronto e as instâncias do servidor estiverem configuradas, o proprietário do banco de dados poderá iniciar o espelhamento de banco de dados. Assim que o espelhamento for iniciado, cada parceiro começará a manter as informações de estado no seu banco de dados sobre aquele banco de dados, assim como o outro parceiro e a testemunha, se houver. Essas informações de estado permitem que as instâncias de servidor mantenham uma relação conhecida como uma sessão de espelhamento de banco de dados. Ao longo de uma sessão de espelhamento de banco de dados, as instâncias de servidor monitoram umas às outras. As informações de estado são mantidas até que o proprietário do banco de dados pare a sessão. Para obter mais informações, consulte Estados de espelhamento e Monitorando o espelhamento de banco de dados.
No início de uma sessão de espelhamento de banco de dados, o servidor espelho identifica o LSN (número de seqüência de log) da mais recente aplicação do log de transações no banco de dados espelho e solicita ao servidor principal o log de transações para todas as futuras transações, se houver. Como resposta, o servidor principal envia ao servidor espelho qualquer registro de log ativo acumulado desde a última restauração de log no banco de dados espelho ou enviado ao servidor espelho. O log não enviado que acumulou no disco de log do banco de dados principal é conhecido como fila de envio.
O servidor espelho, imediatamente, grava o log de entrada no disco, onde é mantido até que seja aplicado ao banco de dados espelho. O log que aguarda o disco do espelho é conhecido como fila de restauração. A quantidade de log não restaurado que está aguardando na fila de restauração para ser refeito é um indicador de tempo necessário para a falha do banco de dados de espelhamento. Para obter mais informações, consulte Estimando interrupção de serviço durante troca de função.
O servidor principal continua disponibilizando o banco de dados principal para clientes e conexões cliente. Depois de iniciado o espelhamento, sempre que um cliente atualiza o banco de dados principal, gravando a transação do log do banco de dados principal, o servidor principal também envia o registro de log para o servidor espelho. Então, o servidor espelho grava imediatamente o registro de log no disco como o último registro na fila de restauração.
Em plano de fundo, começando com o registro de log mais antigo, o servidor espelho refaz o log no banco de dados espelho, registro a registro, o mais rápido possível. Refazer o log envolve a aplicação dos registros de log em fila no banco de dados espelho, em seqüência, começando pelo registro mais antigo. Cada registro de log é refeito apenas uma vez. Como o servidor espelho refaz o log, o banco de dados espelho efetua roll forward continuamente. Quando o servidor principal trunca ou reduz o log do banco de dados principal, o servidor espelho também reduz o log no mesmo ponto no fluxo de log.
Normalmente, refazer isso rapidamente captura o banco de dados espelho em relação ao banco de dados principal. Se o banco de dados espelho sempre capturar completamente o banco de dados principal, isso dependerá do modo de operação da sessão. Sob o modo síncrono e de alta-segurança, o servidor principal espera confirmar as novas transações até que elas sejam escritas no disco de log do servidor espelho. Depois que os registros de log acumulados forem enviados ao servidor espelho, o banco de dados espelho ficará sincronizado com o banco de dados principal.
Durante a sessão, se o servidor principal não conseguir enviar imediatamente nenhum registro de log, os registros não enviados serão acumulados na fila de envio. No modo síncrono de alta-segurança , depois da sincronização, o novo log não enviado será acumulado apenas se o espelhamento for pausado ou suspenso. Por outro lado, no modo de alto desempenho assíncrono, o log não enviado é acumulado sempre que o servidor espelho falha durante o espelhamento e quando o espelhamento é pausado ou suspenso. A quantidade de logs não enviados é um indicador de possível perda de dados em caso de falha no servidor principal.
.gif "Observação") Observação |
|---|
Se as falhas persistirem, o servidor espelho pausará a sessão colocando o banco de dados no estado SUSPENSO. O proprietário do banco de dados deverá resolver a causa da falha antes de retomar a sessão. |
Sessões simultâneas
Uma determinada instância do servidor pode participar de várias sessões de espelhamento de banco de dados simultâneas (uma para cada banco de dados espelhado) com as mesmas ou diferentes instâncias do servidor. Freqüentemente, uma instância do servidor atua exclusivamente como um parceiro ou uma testemunha em todo o processo das sessões de espelhamento de banco de dados. Porém, como cada sessão é independente das demais, uma instância do servidor pode agir como um parceiro em algumas sessões e uma testemunha em outras. Por exemplo, considere as quatro sessões a seguir entre três instâncias de servidor (SSInstance_1, SSInstance_2 e SSInstance_3). Cada instância do servidor atua como parceiro em algumas sessões e como testemunha em outras.
Instância do servidor |
Sessão para banco de dados A |
Sessão para banco de dados B |
Sessão para banco de dados C |
Sessão para banco de dados D |
|---|---|---|---|---|
SSInstance_1 |
Testemunha |
Parceiro |
Parceiro |
Parceiro |
SSInstance_2 |
Parceiro |
Testemunha |
Parceiro |
Parceiro |
SSInstance_3 |
Parceiro |
Parceiro |
Testemunha |
Testemunha |
A figura a seguir ilustra duas instâncias de servidor que estão participando como parceiros de duas sessões de espelhamento. Uma sessão é para um banco de dados nomeado Db_1 e a outra para um banco de dados nomeado Db_2.
.gif "Duas instâncias de servidor em duas sessões simultâneas")
Cada um dos bancos de dados é independente dos outros. Por exemplo, uma instância de servidor poderia ser, inicialmente, o servidor espelho para dois bancos de dados. Se um dos bancos de dados falhar, a instância de servidor torna-se o servidor principal para o banco de dados com falha enquanto que o servidor espelho será para o outro banco de dados.
Em outro exemplo, considere uma instância de servidor como servidor principal para dois ou mais bancos de dados que estão sendo executados em modo de alta segurança, com failover automático. Se a instância do servidor falhar, todos os bancos de dados ativarão automaticamente o failover nos seus respectivos bancos de dados espelho.
Ao configurar a instância de um servidor para operar como parceiro e como testemunha, assegure-se de que o ponto de extremidade do espelhamento de banco de dados ofereça suporte para as duas funções (para obter mais informações, consulte Ponto de extremidade de espelhamento de banco de dados). Assegure-se também de que o sistema tenha recursos suficientes para reduzir contenção de recurso.
| Observação |
|---|
Como os bancos de dados espelhados são independentes, eles não podem realizar failover em grupo. |
Threads criados para uma sessão de espelhamento de banco de dados
Os tipos de threads criados por uma instância do servidor para uma sessão de espelhamento de banco de dados depende parcialmente das funções de espelhamento executadas pela instância do servidor. Uma determinada sessão tem alguns ou todos os seguintes threads:
Um thread global para comunicação do espelhamento de banco de dados. Este thread é iniciado pelo Service Broker.
Se a instância do servidor está agindo como um parceiro de espelhamento (se é o servidor principal ou o servidor espelho):
Um thread por banco de dados espelhado para o processamento de evento.
Um thread por banco de dados espelhado para tarefas assíncronas (como envio e gravação de logs, por exemplo) que de outro modo bloqueariam o thread de eventos.
Sempre que a instância estiver agindo como um servidor espelho:
Um thread do gerenciador de restauração, que envia o log para restauração, executa leituras read-ahead da página, bloqueia a reaquisição e assim por diante.
No SQL Server Standard, um thread de restauração por banco de dados espelho ou, no SQL Server Enterprise, um thread de restauração por banco de dados espelho para cada quatro CPUs. Esses threads executam a restauração real do log.
Se a instância estiver agindo como uma testemunha:
- Um thread global para processamento de mensagens de testemunhas para todas as sessões de espelhamento nas quais a instância estiver atuando como testemunha.
Pré-requisitos para uma sessão de espelhamento de banco de dados
Antes de uma sessão de espelhamento ser iniciada, o proprietário do banco de dados ou o administrador do sistema deverá criar o banco de dados espelho, estabelecer os pontos de extremidades e logons e, em alguns casos, criar e configurar certificados. Para obter mais informações, consulte Configurando espelhamento de banco de dados.
A criação de um novo banco de dados espelho requer, no mínimo, um backup completo do banco de dados principal e um backup de log subseqüente e a restauração de ambos sobre a instância do servidor espelho, usando WITH NORECOVERY. Além disso, antes de iniciar o espelhamento, se algum backup de log adicional for feito depois do backup de log exigido, você deverá também aplicar manualmente todo o backup de log adicional (sempre usando WITH NORECOVERY). Depois de aplicar o último backup de log, será possível iniciar o espelhamento. Para obter mais informações, consulte Preparando um banco de dados espelho para espelhamento.
Impacto ao pausar uma sessão no log de transações principal
O proprietário de banco de dados pode pausar uma sessão a qualquer momento. Ao fazer a pausa, preserva-se o estado da sessão enquanto durante a remoção do espelhamento. Quando uma sessão é pausada, o servidor principal não envia nenhum log novo registrado ao servidor espelho. Todos esses registros permanecem ativos e são acumulados no log de transações do banco de dados principal. Desde que uma sessão de espelhamento de banco de dados permaneça pausada, o log de transações não poderá ser truncado. No entanto, se a sessão de espelhamento de banco de dados permanecer pausada por muito tempo, o log poderá ser preenchido.
Para obter mais informações, consulte Pausando e continuando espelhamento de banco de dados.
Conexões cliente
O suporte à conexão cliente para sessões de espelhamento de banco de dados é fornecido pelo Microsoft .NET Data Provider for SQL Server. Para obter mais informações, consulte Conectando clientes a um banco de dados espelhado.
Consulte também