Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a:
SQL Server
Um determinado banco de dados pode ser espelhado ou enviado em log; ele também pode ser simultaneamente espelhado e enviado log. Para escolher qual abordagem usar, considere o seguinte:
Quantos servidores de destino são necessários?
Se você precisar apenas de um único banco de dados de destino, o espelhamento de banco de dados é a solução recomendada.
Se você precisar de mais de um banco de dados de destino, precisará usar o envio de logs, sozinho ou com espelhamento de banco de dados. A combinação dessas abordagens oferece os benefícios do espelhamento de banco de dados, juntamente com o suporte para vários destinos fornecido pelo envio de logs.
Caso precise atrasar a restauração do log na base de dados de destino (normalmente, para se proteger contra erros lógicos), use a transmissão de logs, sozinho ou com espelhamento de base de dados.
Este tópico discute considerações para combinar envio de logs e espelhamento de banco de dados.
Observação
Para obter introduções a essas tecnologias, consulte Espelhamento de banco de dados (SQL Server) e Sobre o envio de logs (SQL Server).
Combinando envio de logs e espelhamento de banco de dados
O banco de dados principal em uma sessão de espelhamento também pode atuar como o banco de dados primário em uma configuração de envio de logs, ou vice-versa, pois o compartilhamento de backup de envio de logs está intacto. A sessão de espelhamento do banco de dados é executada em qualquer modo operacional, seja síncrono (com a segurança da transação definida como FULL) ou assíncrono (com a segurança da transação definida como OFF).
Observação
Para usar o espelhamento de banco de dados em um banco de dados, o modelo de recuperação completa é sempre necessário.
Normalmente, ao combinar envio de logs e espelhamento de banco de dados, a sessão de espelhamento é estabelecida antes do envio de logs, embora isso não seja necessário. Em seguida, o banco de dados principal atual é configurado como o primário de envio de logs (o banco de dados principal/primário), juntamente com um ou mais bancos de dados secundários remotos. Além disso, o banco de dados espelho deve ser configurado como primário no envio de logs (o banco de dados espelho/primário). Os bancos de dados secundários de envio de logs devem estar em instâncias de servidor diferentes do servidor principal/primário ou do servidor espelho/primário.
Observação
As configurações de diferenciação de maiúsculas e minúsculas dos servidores envolvidos no envio de logs devem corresponder.
Durante uma sessão de envio de logs, os trabalhos de backup no banco de dados primário criam backups de log em uma pasta de backup. A partir daí, os backups são copiados pelas tarefas de cópia dos servidores secundários. Para que os trabalhos de backup e cópia sejam bem-sucedidos, eles devem ter acesso à pasta de backup de envio de logs. Para maximizar a disponibilidade do servidor primário, recomendamos que você estabeleça a pasta de backup em um local de backup compartilhado em um computador host separado. Certifique-se de que todos os servidores de envio de logs, incluindo o servidor espelho/primário, possam acessar o local de backup compartilhado (conhecido como compartilhamento de backup).
Para permitir que o envio de logs continue após o espelhamento do banco de dados falhar, deve também configurar o servidor espelho como um servidor primário, utilizando a mesma configuração que usa para o primário no banco de dados principal. O banco de dados espelho está no estado de restauração, o que impede que os trabalhos de backup façam backup do log no banco de dados espelho. Isso garante que o banco de dados espelho/primário não interfira com o banco de dados principal/primário cujos backups de log estão sendo copiados por servidores secundários. Para evitar alertas espúrios, após a tarefa de backup ser executada no banco de dados espelho/primário, a tarefa de backup regista uma mensagem na tabela log_shipping_monitor_history_detail e a tarefa do agente indica um estado de sucesso.
O banco de dados espelho/primário está inativo na sessão de envio de logs. No entanto, se o espelhamento falhar, o banco de dados espelho anterior entra em operação como o banco de dados principal. Nesse ponto, esse banco de dados também se torna ativo como o banco de dados primário de envio de logs. Os trabalhos de backup de envio de logs, que anteriormente não conseguiam enviar logs para esse banco de dados, começam agora a enviar os logs. Por outro lado, uma mudança de serviço faz com que o antigo banco de dados principal/primário se torne o novo banco de dados espelho/primário e entre no estado de restauração, e os trabalhos de backup nesse banco de dados param de fazer o backup do log.
Observação
No caso de um failover automático, a mudança para a função de espelho ocorre quando o antigo banco de dados principal/primário reingressa na sessão de espelhamento.
Para ser executada no modo de alta segurança com failover automático, a sessão de espelhamento é configurada com uma instância de servidor adicional conhecida como testemunha. Se o banco de dados principal for perdido por qualquer motivo depois que o banco de dados for sincronizado e se o servidor espelho e a testemunha ainda puderem se comunicar entre si, ocorrerá failover automático. Um failover automático faz com que o servidor espelho assuma a função principal e coloque seu banco de dados online como o banco de dados principal. Se o local de backup de envio de logs estiver acessível ao novo servidor principal/primário, seus trabalhos de backup começarão a enviar backups de log para esse local. O modo síncrono de espelhamento da base de dados garante que a cadeia de registos não seja afetada por um failover de espelhamento e que apenas o registo válido seja restaurado. Os servidores secundários continuam a copiar backups de log sem saber que uma instância de servidor diferente se tornou o servidor primário.
Ao usar um monitor de envio de logs local, nenhuma consideração especial é necessária para acomodar esse cenário. Para obter informações sobre como usar uma instância de monitoramento remoto com esse cenário, consulte "O impacto do espelhamento de banco de dados em uma instância de monitoramento remoto", mais adiante neste tópico.
Failover do banco de dados principal para o banco de dados espelho
A figura a seguir mostra como o envio de logs e o espelhamento de banco de dados funcionam juntos quando o espelhamento é executado no modo de alta segurança com failover automático. Inicialmente, Server_A é o servidor principal para espelhamento e o servidor primário para envio de logs. Server_B é o servidor espelho e também está configurado como um servidor primário, que está inativo no momento. Server_C e Server_D são servidores secundários de envio de logs. Para maximizar a disponibilidade da sessão de envio de logs, o local de backup está em um diretório de compartilhamento em um computador host separado.
Após um failover de espelhamento, o nome do servidor primário, conforme definido no servidor secundário, permanece inalterado. .
O impacto do espelhamento de banco de dados em uma instância de monitoramento remoto
Quando o envio de logs é usado com uma instância de monitoramento remoto, a combinação da sessão de envio de logs e do espelhamento do banco de dados afeta as informações nas tabelas do monitor. As informações sobre o primário são uma combinação do configurado no principal/primário e do monitor configurado em cada secundário.
Para manter o monitoramento o mais transparente possível, quando você usa um monitor remoto, recomendamos que especifique o nome primário original ao configurar o primário no secundário. Essa abordagem também facilita a alteração da configuração de envio de logs do Microsoft SQL Server Agent. Para obter mais informações sobre monitoramento, consulte Monitorar envio de logs (Transact-SQL).
Configurando o espelhamento e o envio de logs juntos
Para configurar o espelhamento de banco de dados e o envio de logs juntos, as seguintes etapas são necessárias:
Restaure os backups da base de dados principal/primária com NORECOVERY noutra instância de servidor para serem usados posteriormente como base de dados espelho de espelhamento. Para obter mais informações, consulte Preparar um banco de dados espelho para espelhamento (SQL Server).
Configure o espelhamento do banco de dados. Para obter mais informações, consulte Estabelecer uma sessão de espelhamento de banco de dados usando a autenticação do Windows (SQL Server Management Studio) ou Configurando o espelhamento de banco de dados (SQL Server).
Restaure backups do banco de dados principal/primário para outras instâncias do servidor para serem usados posteriormente como bancos de dados secundários de envio de logs para o banco de dados primário.
Configure o envio de logs no banco de dados principal como o banco de dados primário para um ou mais bancos de dados secundários.
Você deve configurar uma única partilha como o diretório de backup (uma partilha de backup). Isso garante que, após a alternância de função entre os servidores principal e espelho, os trabalhos de backup continuem a ser gravados no mesmo diretório que antes. Uma prática recomendada é garantir que esse compartilhamento esteja localizado em um servidor físico diferente dos servidores que hospedam os bancos de dados envolvidos no espelhamento e envio de logs.
Para obter mais informações, consulte Configurar envio de logs (SQL Server).
Realizar o failover manual do principal para o espelho.
Para executar um failover manual:
Configure o envio de logs na nova base de dados principal (anteriormente espelho) como a base de dados primária.
Importante
Não execute nenhuma configuração a partir de uma fonte secundária.
Você deve usar o mesmo compartilhamento de backup que você usou na etapa 4.
A interface de envio de log de transações no SQL Server Management Studio oferece suporte a apenas um banco de dados primário por configuração de envio de logs. Portanto, você deve usar procedimentos armazenados para configurar a nova entidade como principal.
Execute outro failover manual para retornar ao principal original.