Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Aplica-se a:
SQL Server
Este tópico descreve os modos de funcionamento síncronos e assíncronos para sessões de espelhamento de bases de dados.
Observação
Para uma introdução ao espelhamento de bases de dados, veja Espelhamento de Bases de Dados (SQL Server).
Termos e Definições
Esta secção apresenta alguns termos centrais para este tema.
Modo de alto desempenho
A sessão de espelhamento de banco de dados opera de forma assíncrona e usa apenas o servidor principal e o servidor espelho. A única forma de mudança de função é o serviço forçado (com possível perda de dados).
Modo de alta segurança
A sessão de espelhamento de banco de dados opera de forma síncrona e, opcionalmente, usa uma testemunha, bem como o servidor principal e o servidor espelho.
Segurança das transações
Uma propriedade de banco de dados específica de espelhamento que determina se uma sessão de espelhamento de banco de dados opera de forma síncrona ou assíncrona. Existem dois níveis de segurança: TOTAL e DESLIGADO.
Witness
Para uso apenas com modo de alta segurança, uma instância opcional de SQL Server que permite ao servidor espelho reconhecer se deve iniciar um failover automático. Ao contrário dos dois parceiros de failover, a testemunha não desempenha a função de gerir a base de dados. Apoiar o failover automático é o único papel da testemunha.
Espelhamento Assíncrono de Base de Dados (Modo Alto Desempenho)
Esta secção descreve como funciona o espelhamento assíncrono da base de dados, quando é apropriado usar o modo de alto desempenho e como responder caso o servidor principal falhe.
Observação
A maioria das edições do SQL Server suporta apenas espelhamento síncrono de bases de dados ("Apenas Segurança Total"). Para informações sobre edições que suportam totalmente o espelhamento de bases de dados, consulte "Alta Disponibilidade (Sempre Ativa)" em Edições e funcionalidades suportadas pelo SQL Server 2022.
Quando a segurança das transações está definida para DESLIGADO, a sessão de espelhamento da base de dados opera de forma assíncrona. A operação assíncrona suporta apenas um modo de operação: modo de alto desempenho. Este modo melhora o desempenho à custa da alta disponibilidade. O modo de alto desempenho utiliza apenas o servidor principal e o servidor espelho. Os problemas no servidor espelho nunca afetam o servidor principal. Com a perda do servidor principal, a base de dados espelhada é marcada como DESCONECTADA, mas está disponível como reserva quente.
Modo de alto desempenho, suporta apenas uma forma de troca de papéis: serviço forçado (com possível perda de dados), que utiliza o servidor espelho como servidor de reserva quente. O serviço forçado é uma das possíveis respostas à falha do servidor principal. Como a perda de dados é possível, deve considerar outras alternativas antes de forçar a ativação do serviço no espelho. Para mais informações, consulte Responder à Falha do Principal, mais adiante neste tópico.
A figura seguinte mostra a configuração de uma sessão usando o modo de alto desempenho.
No modo de alto desempenho, assim que o servidor principal envia o registo de uma transação para o servidor espelho, o servidor principal envia uma confirmação ao cliente, sem esperar um reconhecimento do servidor espelho. As transações são confirmadas sem esperar que o servidor espelho escreva o log no disco. A operação assíncrona permite que o servidor principal funcione com latência mínima de transação.
O servidor espelho tenta acompanhar os registos enviados pelo servidor principal. Mas a base de dados espelhada pode ficar um pouco atrás da base de dados principal, embora normalmente a diferença entre as bases de dados seja pequena. No entanto, a lacuna pode tornar-se significativa se o servidor principal estiver sob uma carga de trabalho elevada ou se o sistema do servidor espelho estiver sobrecarregado.
Nesta secção:
Quando é apropriado o modo de alto desempenho?
O modo de alto desempenho pode ser útil num cenário de recuperação de desastres em que os servidores principal e espelho estão separados por uma distância significativa e onde não se pretende que pequenos erros afetem o servidor principal.
Observação
O envio de registos pode ser um complemento ao espelhamento de base de dados e é uma alternativa favorável ao espelhamento assíncrono de base de dados. Para informações sobre as vantagens do transporte de logs, consulte Soluções de Alta Disponibilidade (SQL Server). Para informações sobre o uso do envio de logs com espelhamento de bases de dados, consulte Espelhamento de Bases de Dados e Envio de Logs (SQL Server).
O Impacto de uma Testemunha no Modo High-Performance
Se usar Transact-SQL para configurar o modo de alto desempenho, sempre que a propriedade SAFETY estiver definida como OFF, recomendamos fortemente que a propriedade WITNESS também esteja definida como OFF. Uma testemunha pode coexistir com o modo de alto desempenho, mas não traz qualquer benefício e introduz risco.
Se a testemunha se desconectar da sessão quando um dos parceiros falhar, a base de dados ficará indisponível. Isto porque, embora o modo de alto desempenho não exija uma testemunha, se for definida uma, a sessão requer um quórum composto por duas ou mais instâncias de servidor. Se a sessão perder quórum, não pode servir a base de dados.
Quando uma testemunha é colocada numa sessão em modo de alto desempenho, a aplicação do quórum significa que:
Se o servidor espelho for perdido, o servidor principal deve estar ligado à testemunha. Caso contrário, o servidor principal desliga a sua base de dados até que o servidor testemunha ou o servidor espelho volte a entrar na sessão.
Se o servidor principal for perdido, forçar o serviço ao servidor espelho requer que o servidor espelho esteja ligado à testemunha.
Observação
Para informações sobre os tipos de quórums, veja Quórum: Como uma Testemunha Afeta a Disponibilidade da Base de Dados (Espelhamento de Bases de Dados).
Responder ao Fracasso do Diretor
Quando o principal falha, o proprietário da base de dados tem várias opções, a saber:
Deixe a base de dados indisponível até que o servidor principal volte a estar disponível.
Se a base de dados principal e o seu registo de transações estiverem intactos, esta escolha preserva todas as transações comprometidas à custa da disponibilidade.
Parar a sessão de espelhamento da base de dados, atualizar manualmente a base de dados e depois iniciar uma nova sessão de espelhamento da base de dados.
Se a base de dados principal for perdida mas o servidor principal continuar a funcionar, tente imediatamente fazer backup da cauda do registo na base de dados principal. Se o backup do tail-log for bem-sucedido, remover o espelhamento pode ser a melhor alternativa. Depois de remover o espelhamento, podes restaurar o registo na antiga base de dados espelhada, que preserva todos os dados.
Observação
Se o backup do tail-log falhou e não puder esperar que o servidor principal se recupere, considere forçar o serviço, o que tem a vantagem de manter o estado da sessão.
Forçar o serviço (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 o serviço só é possível se o servidor principal estiver fora de serviço, a sessão for assíncrona (a segurança das transações está definida para DESLIGADO), e ou a sessão não tiver qualquer testemunha (a propriedade WITNESS está definida para DESLIGADO) ou se a testemunha estiver ligada ao servidor espelho (ou seja, tiver quórum).
Forçar o serviço faz com que o servidor espelho assuma a função de servidor principal e disponibilize a sua cópia da base de dados para os clientes. Quando o serviço é forçado, todos os registos de transações que o principal ainda não enviou para o servidor espelho são perdidos. Por isso, deve limitar o serviço forçado a situações em que a possível perda de dados seja aceitável e a disponibilidade imediata da base de dados seja crítica. Para informações sobre como funciona o serviço forçado e sobre as melhores práticas para o utilizar, veja Troca de Papéis Durante uma Sessão de Espelhamento de Base de Dados (SQL Server).
Espelhamento Síncrono da Base de Dados (Modo de Alta Segurança)
Esta secção descreve como funciona o espelhamento de base de dados síncrono, incluindo os modos alternativos de alta segurança (com mudança automática e sem mudança automática), e contém informações sobre o papel da testemunha na mudança automática.
Quando a segurança das transações está definida para FULL, a sessão de espelhamento da base de dados corre em modo de alta segurança e opera de forma síncrona após uma fase inicial de sincronização. Esta secção descreve os detalhes das sessões de espelhamento de bases de dados configuradas para operação síncrona.
Para alcançar a operação síncrona para uma sessão, o servidor espelho deve sincronizar a base de dados espelhada com a base de dados principal. Quando a sessão começa, o servidor principal começa a enviar o seu registo ativo para o servidor espelho. O servidor espelho escreve todos os registos de logs recebidos no disco o mais rapidamente possível. Assim que todos os registos de registo recebidos são escritos no disco, as bases de dados são sincronizadas. Enquanto os parceiros mantiverem comunicação, as bases de dados mantêm-se sincronizadas.
Observação
Para monitorizar alterações de estado numa sessão de espelhamento de base de dados, utilize a classe de evento Database Mirroring State Change . Para mais informações, consulte Classe de Evento de Mudança de Estado com Espelhamento de Base de Dados.
Após o término da sincronização, todas as transações comprometidas na base de dados principal são também confirmadas no servidor espelho, garantindo a proteção dos dados. Isto é conseguido aguardando para confirmar uma transação na base de dados principal, até que o servidor principal receba uma mensagem do servidor espelho a indicar que gravou o log da transação no disco. Note que a espera por esta mensagem aumenta a latência da transação.
O tempo necessário para sincronização depende essencialmente de quão atrasada a base de dados espelhada estava em relação à base de dados principal no início da sessão (medido pelo número de registos de registo inicialmente recebidos do servidor principal), da carga de trabalho na base de dados principal e da velocidade do sistema espelho. Depois de uma sessão ser sincronizada, o log endurecido que não foi ainda refeito na base de dados espelhada permanece na fila de refazimento.
Assim que a base de dados espelhada se sincroniza, o estado de ambas as cópias da base de dados muda para SINCRONIZADO.
A operação síncrona é mantida da seguinte forma:
Ao receber uma transação de um cliente, o servidor principal escreve o registo da transação no registo de transações.
O servidor principal escreve a transação na base de dados e, simultaneamente, envia o registo de logs para o servidor espelho. O servidor principal aguarda um reconhecimento do servidor espelho antes de confirmar qualquer um dos seguintes pontos ao cliente: uma confirmação de transação ou um rollback.
O servidor espelho grava o registo no disco e devolve uma confirmação ao servidor principal.
Ao receber o confirmação do servidor espelho, o servidor principal envia uma mensagem de confirmação ao cliente.
O modo de alta segurança protege os seus dados ao exigir que os dados estejam sincronizados entre dois locais. Todas as transações comprometidas são garantidas para serem escritas no disco no servidor espelho.
Nesta secção:
Modo de Alta Segurança sem Failover Automático
Modo de Alta Segurança sem Failover Automático
A figura seguinte mostra a configuração do modo de alta segurança sem failover automático. A configuração consiste apenas nos dois parceiros.
Quando os parceiros estão ligados e a base de dados já está sincronizada, é suportado o failover manual. Se a instância do servidor espelho falhar, a instância principal do servidor não é afetada e vai continuar a funcionar exposta (isto é, sem espelhar os dados). Se o servidor principal for perdido, o espelho é suspenso, mas o serviço pode ser forçado para o servidor espelho (com possível perda de dados). Para obter mais informações, consulte Comutação de função durante uma sessão de espelhamento de banco de dados (SQL Server).
Modo de Alta Segurança com Comutação Automática
O failover automático proporciona alta disponibilidade ao garantir que a base de dados continua a ser servida após a perda de um servidor. O failover automático requer que a sessão possua uma terceira instância de servidor, a testemunha, que idealmente reside num terceiro computador. A figura seguinte mostra a configuração de uma sessão em modo de alta segurança que suporta failover automático.
Ao contrário dos dois sócios, a testemunha não trabalha com a base de dados. A testemunha apenas suporta o failover automático ao verificar se o servidor principal está ativo e a funcionar. O servidor espelho inicia o failover automático somente se o espelho e a testemunha permanecerem conectados um ao outro depois que ambos tiverem sido desconectados do servidor principal.
Quando um "witness" é configurado, a sessão requer um quórum, uma relação entre pelo menos duas instâncias de servidor que permite que a base de dados seja disponibilizada. Para mais informações, consulte Testemunha de Espelhamento de Base de Dados e Quórum: Como uma Testemunha Afeta a Disponibilidade da Base de Dados (Espelhamento de Base de Dados).
O failover automático requer as seguintes condições:
A base de dados já está sincronizada.
A falha ocorre enquanto as três instâncias do servidor estão conectadas, e o servidor testemunho e o servidor espelho permanecem ligados.
A perda de um parceiro tem o seguinte efeito:
Se o servidor principal ficar indisponível nas condições acima, ocorre failover automático. O servidor espelho passa para o papel de principal e oferece a sua base de dados como base de dados principal.
Se o servidor principal ficar indisponível quando essas condições não forem cumpridas, pode ser possível forçar o serviço (com possível perda de dados). Para obter mais informações, consulte Comutação de função durante uma sessão de espelhamento de banco de dados (SQL Server).
Se o único servidor espelho ficar indisponível, o principal e a testemunha continuam.
Se a sessão perder a sua testemunha, o quórum exige ambos os parceiros. Se algum dos parceiros perder quórum, ambos os parceiros perdem quórum, e a base de dados torna-se indisponível até que o quórum seja restabelecido. Este requisito de quórum garante que, na ausência de uma testemunha, a base de dados nunca fica exposta, ou seja, sem ser espelhada.
Observação
Se esperar que a testemunha permaneça desligada durante um período significativo, recomendamos que a retire da sessão até que esta esteja disponível.
Transact-SQL Definições e Modos de Operação de Espelhamento de Bases de Dados
Esta secção descreve uma sessão de espelhamento de base de dados em termos das definições ALTER DATABASE e dos estados da base de dados espelhada e da testemunha, se existirem. A secção destina-se a utilizadores que gerem o espelhamento de bases de dados principalmente ou exclusivamente usando o Transact-SQL, em vez do SQL Server Management Studio.
Sugestão
Como alternativa ao uso do Transact-SQL, pode controlar o modo de funcionamento de uma sessão no Explorador de Objetos usando a página de Espelhamento da caixa de diálogo Propriedades da Base de Dados . Para mais informações, consulte Estabelecer uma Sessão de Espelhamento de Base de Dados Usando Autenticação Windows (SQL Server Management Studio).
Nesta secção:
Como a Segurança da Transação e o Estado das Testemunhas Afetam o Modo de Operação
Consulta da Configuração de Segurança e Estado da Testemunha
Fatores que Afetam o Comportamento na Perda do Servidor Principal
Como a Segurança da Transação e o Estado das Testemunhas Afetam o Modo de Operação
O modo de funcionamento de uma sessão é determinado pela combinação da configuração de segurança da transação e do estado do testemunho. A qualquer momento, o proprietário da base de dados pode alterar o nível de segurança da transação e pode adicionar ou remover a testemunha.
Nesta secção:
Segurança de Transações
A segurança das transações é uma propriedade específica da base de dados de espelhamento que determina se uma sessão de espelhamento da base de dados opera de forma síncrona ou assíncrona. Existem dois níveis de segurança: TOTAL e DESLIGADO.
SEGURANÇA COMPLETA
A segurança total das transações faz com que a sessão opere de forma síncrona em modo de alta segurança. Se uma testemunha estiver presente, uma sessão suporta failover automático.
Quando estabelece uma sessão usando instruções ALTER DATABASE, a sessão começa com a propriedade SAFETY definida como FULL; ou seja, a sessão começa em modo de alta segurança. Depois do início da sessão, pode adicionar uma testemunha.
Para mais informações, consulte Synchronous Database Mirroring (Modo de Alta Segurança), anteriormente neste tópico.
SEGURANÇA DESLIGADA
Desligar a segurança das transações faz com que a sessão opere de forma assíncrona, em modo de alto desempenho. Se a propriedade SAFETY estiver definida como DESLIGADA, a propriedade TESTEMUNHA também deve ser definida como DESLIGADA (o padrão). Para informações sobre o impacto da testemunha em modo de alto desempenho, veja O Estado da Testemunha, mais adiante neste tópico. Para mais informações sobre execução com a segurança das transações desligada, veja Espelhamento Assíncrono de Base de Dados (ModoHigh-Performance), anteriormente neste tópico.
A segurança das transações da base de dados é registada em cada parceiro na vista de catálogo sys.database_mirroring nas colunas mirroring_safety_level e mirroring_safety_level_desc. Para mais informações, consulte sys.database_mirroring (Transact-SQL).
O proprietário da base de dados pode alterar o nível de segurança da transação a qualquer momento.
O Estado da Testemunha
Se uma testemunha foi definida, é exigido quórum, pelo que o estado da testemunha é sempre significativo.
Se existir, a testemunha tem um de dois estados:
Quando a testemunha está ligada a um parceiro, a testemunha está no estado CONNECTED relativo a esse parceiro e tem quórum com esse parceiro. Neste caso, a base de dados pode ser disponibilizada, mesmo que um dos parceiros não esteja disponível.
Quando a testemunha existe mas não está ligada a um parceiro, a testemunha está no estado DESCONHECIDO ou DESCONECTADO em relação a esse parceiro. Neste caso, a testemunha não tem quórum com esse parceiro e, se os parceiros não estiverem ligados entre si, a base de dados torna-se indisponível.
Para informações sobre quórum, consulte Quórum: Como uma Testemunha Afeta a Disponibilidade da Base de Dados (Espelhamento de Base de Dados).
O estado de cada testemunha numa instância de servidor é registado na vista de catálogo sys.database_mirroring nas colunas mirroring_witness_state e mirroring_witness_state_desc. Para mais informações, consulte sys.database_mirroring (Transact-SQL).
A tabela seguinte resume como o modo de funcionamento de uma sessão depende da sua configuração de segurança de transação e do estado do testemunho.
| Modo de funcionamento | Segurança das transações | Estado observador |
|---|---|---|
| Modo de alto desempenho | DESLIGADO | NULL (sem testemunha)** |
| Modo de alta segurança sem failover automático | COMPLETO | NULL (sem testemunha) |
| Modo de alta segurança com failover automático* | COMPLETO | LIGADO |
Se a testemunha ficar desconectada, recomendamos que defina WITNESS OFF até que a instância do servidor de testemunha fique disponível.
**Se uma testemunha estiver presente em modo de alto desempenho, a testemunha não participa na sessão. No entanto, para disponibilizar a base de dados, pelo menos duas das instâncias do servidor devem permanecer conectadas. Por isso, recomendamos manter a propriedade WITNESS definida como OFF nas sessões de modo de alto desempenho. Para mais informações, consulte Quórum: Como uma Testemunha Afeta a Disponibilidade da Base de Dados (Espelhamento de Bases de Dados).
Visualizar as Configurações de Segurança e o Estado da Testemunha
Para visualizar a definição de segurança e o estado da testemunha numa base de dados, utilize a vista de catálogo sys.database_mirroring . As colunas relevantes são as seguintes:
| Fator | Columns | Description |
|---|---|---|
| Segurança das transações | nível_de_segurança_de_espelhamento ou descrição_do_nível_de_segurança_de_espelhamento | Definição de segurança de transação para atualizações na base de dados espelhada, uma das seguintes opções: UNKNOWN DESLIGADO COMPLETO A base de dados NULL= não está online. |
| Existe uma testemunha? | mirroring_witness_name | Nome do servidor da base de dados que espelha testemunha ou NULL, indicando que não existe nenhuma testemunha. |
| Estado de Testemunho | mirroring_witness_state ou mirroring_witness_state_desc | Estado da testemunha na base de dados sobre um dado parceiro: UNKNOWN LIGADO DISCONNECTED NULL = não existe testemunha ou a base de dados não está online. |
Por exemplo, no servidor principal ou espelho, introduza:
SELECT mirroring_safety_level_desc, mirroring_witness_name, mirroring_witness_state_desc FROM sys.database_mirroring
Para mais informações sobre esta visualização de catálogo, consulte sys.database_mirroring (Transact-SQL).
Fatores que Afetam o Comportamento na Perda do Servidor Principal
A tabela seguinte resume o efeito combinado da definição de segurança da transação, do estado da base de dados e do estado da testemunha no comportamento de uma sessão de espelhamento devido à perda do servidor principal.
| Segurança das transações | Espelhamento do estado da base de dados espelhada | Estado de testemunho | Comportamento quando se perde a entidade principal |
|---|---|---|---|
| COMPLETO | SINCRONIZADO | LIGADO | Ocorre um failover automático. |
| COMPLETO | SINCRONIZADO | DISCONNECTED | O servidor espelho para de funcionar, o failover não é possível, e o banco de dados não pode ser tornado disponível. |
| DESLIGADO | SUSPENSO ou DESLIGADO | NULL (sem testemunha) | O serviço pode ser forçado a usar o servidor de espelhamento (com possível perda de dados). |
| COMPLETO | SINCRONIZAÇÃO OU SUSPENSO | NULL (sem testemunha) | O serviço pode ser forçado a usar o servidor de espelhamento (com possível perda de dados). |
Tarefas relacionadas
Remover a testemunha de uma sessão de espelhamento de banco de dados (SQL Server)
Alterar a segurança da transação em uma sessão de espelhamento de banco de dados (Transact-SQL)
Ver também
Monitorização do Espelhamento de Bases de Dados (SQL Server)
Testemunha de Espelhamento de Base de Dados