Replicação e envio de logs
O envio de logs envolve duas cópias de um único banco de dados que, normalmente, residem em computadores diferentes. Apenas uma cópia do banco de dados está atualmente disponível aos clientes. Esta cópia é conhecida como o banco de dados primário. As atualizações feitas pelos clientes no banco de dados primário são propagadas por meio do envio de logs para a outra cópia do banco de dados, conhecida como banco de dados secundário. O envio de logs envolve a aplicação de um log de transações de todas as inserções, atualizações ou exclusões feitas no banco de dados primário para o banco de dados secundário.
O envio de logs pode ser usado em combinação com a replicação, com o seguinte comportamento:
A replicação não continua depois de um failover de envio de logs. Se ocorrer um failover, os agentes de replicação não conectarão ao secundário, assim as transações não são replicadas para os Assinantes. Se ocorrer um failback para o primário, a replicação é retomada. Todas as transações que o envio de logs copia do secundário para o primário são replicadas para os Assinantes.
Se o primário estiver permanentemente perdido, o secundário poderá ser renomeado de forma que a replicação possa continuar. O restante deste tópico descreve os requisitos e procedimentos para manipular este caso. O exemplo fornecido é o banco de dados de publicação, que é o banco de dados mais comum de envio de logs, porém, também pode ser aplicado em um processo similar para bancos de dados de assinatura e distribuição.
Para obter informações sobre como recuperar bancos de dados envolvidos em replicação sem qualquer necessidade de reconfigurar a replicação, consulte Fazendo backup e restaurando bancos de dados replicados.
.gif "Observação") Observação |
|---|
Nós recomendamos usar espelhamento de banco de dados, em vez de envio de logs, para dar mais disponibilidade ao banco de dados de publicação. Para obter mais informações, consulte Replicação e espelhamento do banco de dados. |
Requisitos e procedimentos para replicação do secundário caso o primário estiver perdido
Esteja ciente dos requisitos e considerações a seguir:
Se o primário contiver mais de um banco de dados de publicação, faça o envio de logs de todos os bancos de dados de publicação ao mesmo secundário.
O caminho de instalação para a instância de servidor secundário deve ser igual ao primário. Os locais do banco de dados de usuário no servidor secundário devem ser iguais aos do primário.
Faça o backup da chave mestra de serviço no primário. Esta chave será restaurada no secundário. Para obter mais informações, consulte BACKUP SERVICE MASTER KEY (Transact-SQL).
O envio de logs não oferece garantia contra perda de dados. Uma falha no banco de dados primário pode resultar na perda de dados para os quais ainda não foi feito o backup ou para backups perdidos durante a falha.
Envio de logs com replicação transacional
Para replicação transacional, o comportamento do envio de logs depende da opção sincronizar com backup. Essa opção pode ser definida no banco de dados de publicação e no banco de dados de distribuição; no envio de logs para o Publicador, só é relevante a definição do banco de dados de publicação.
Definir essa opção no banco de dados de publicação assegura que as transações não serão entregues ao banco de dados de distribuição até ser feito o backup do banco de dados de publicação. O último backup do banco de dados de publicação poderá então ser restaurado no servidor secundário sem qualquer possibilidade do banco de dados de distribuição possuir transações que o banco de dados de publicação restaurado não possua. Essa opção garante que se ocorrer failover do Publicador para o servidor secundário, será mantida a consistência entre o Publicador, o Distribuidor e os Assinantes. A latência e a taxa de transferência serão afetadas porque as transações não poderão ser entregues ao banco de dados de distribuição até que tenha sido feito backup no Publicador; recomendamos que você defina essa opção no banco de dados de publicação caso o seu aplicativo possa tolerar essa latência. Se a opção sincronizar com backup ainda não estiver definida, os Assinantes poderão receber alterações que não estão mais incluídas no banco de dados recuperado no servidor secundário. Para obter mais informações, consulte Estratégias para fazer backup e restaurar o instantâneo e a replicação transacional.
Para configurar a replicação transacional e envio de logs com a opção sincronizar com backup
Se a opção sincronizar com backup não estiver definida no banco de dados de publicação, execute sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'. Para obter mais informações, consulte sp_replicationdboption (Transact-SQL).
Configure o envio de logs para o banco de dados de publicação. Para obter mais informações, consulte Implantação do envio de logs.
Se ocorrer falha no Publicador, restaure o último log do banco de dados no servidor secundário usando a opção KEEP_REPLICATION do RESTORE LOG. Isso retém todas as configurações de replicação para o banco de dados. Para obter mais informações, consulte Fazendo failover para um envio de logs secundário e RESTORE (Transact-SQL).
Restaure o banco de dados do msdb e os bancos de dados mestre do primário ao secundário. Para obter mais informações, consulte Considerações sobre restauração de bancos de dados modelo e msdb e Considerações sobre restauração do banco de dados mestre. Se o primário também era um Distribuidor, restaure o banco de dados de distribuição do primário ao secundário.
Esses bancos de dados devem estar consistentes com o banco de dados de publicação no primário em termos de configuração de replicação e definições.
No servidor secundário, renomeie o computador e então renomeie a instância do Microsoft SQL Server para corresponder ao nome do servidor primário. Para obter informações sobre como renomear um computador, consulte a documentação do Windows. Para obter informações sobre como renomear o servidor, consulte Como renomear um computador que hospeda uma instância autônoma do SQL Server e Como renomear uma instância do cluster de failover do SQL Server.
No servidor secundário, restaure a chave mestra de serviço da qual foi feito o backup do primário. Para obter mais informações, consulte RESTORE SERVICE MASTER KEY (Transact-SQL).
Para configurar a replicação transacional e envio de logs sem a opção sincronizar com backup
Configure o envio de logs para o banco de dados de publicação. Para obter mais informações, consulte Implantação do envio de logs.
Se ocorrer falha no Publicador, restaure o último log do banco de dados no servidor secundário usando a opção KEEP_REPLICATION do RESTORE LOG. Isso retém todas as configurações de replicação para o banco de dados. Para obter mais informações, consulte Fazendo failover para um envio de logs secundário e RESTORE (Transact-SQL).
Restaure o banco de dados do msdb e os bancos de dados mestre do primário ao secundário. Para obter mais informações, consulte Considerações sobre restauração de bancos de dados modelo e msdb e Considerações sobre restauração do banco de dados mestre. Se o primário também era um Distribuidor, restaure o banco de dados de distribuição do primário ao secundário.
Esses bancos de dados devem estar consistentes com o banco de dados de publicação no primário em termos de configuração de replicação e definições.
No servidor secundário, renomeie o computador e então renomeie a instância do SQL Server para corresponder ao nome do servidor primário. Para obter informações sobre como renomear um computador, consulte a documentação do Windows. Para obter informações sobre como renomear o servidor, consulte Como renomear um computador que hospeda uma instância autônoma do SQL Server e Como renomear uma instância do cluster de failover do SQL Server.
Você poderá receber uma mensagem de erro do Log Reader Agent informando que o banco de dados de publicação e o banco de dados de distribuição não estão sincronizados.
No servidor secundário, restaure a chave mestra de serviço da qual foi feito o backup do primário. Para obter mais informações, consulte RESTORE SERVICE MASTER KEY (Transact-SQL).
Execute sp_replrestart. Esse procedimento armazenado pode ser usado para forçar o Log Reader Agent a ignorar todas as transações replicadas anteriormente no log do banco de dados de publicação. As transações aplicadas depois da conclusão do procedimento armazenado serão processadas pelo Log Reader Agent. Para obter mais informações, consulte sp_replrestart (Transact-SQL).
Reinicie o Log Reader Agent depois que o procedimento armazenado for executado com êxito. Para obter mais informações, consulte Como iniciar e parar um Replication Agent (SQL Server Management Studio).
As transações que já foram distribuídas ao Assinante poderiam ser aplicadas no Publicador. Para assegurar que o Distribution Agent não falhe com um erro ao tentar aplicar novamente essas transações a um Assinante, especifique o perfil do agente intitulado Continuar em caso de erros de consistência de dados. Para obter mais informações, consulte Ignorando erros na replicação transacional.
Envio de logs com replicação de mesclagem
Siga as etapas do procedimento abaixo para configurar a replicação de mesclagem e envio de logs.
Para configurar a replicação de mesclagem e envio de logs
Configure o envio de logs para o banco de dados de publicação. Para obter mais informações, consulte Implantação do envio de logs.
Se ocorrer falha no Publicador, restaure o último log do banco de dados no servidor secundário usando a opção KEEP_REPLICATION do RESTORE LOG. Isso retém todas as configurações de replicação para o banco de dados. Para obter mais informações, consulte Fazendo failover para um envio de logs secundário e RESTORE (Transact-SQL).
Restaure o banco de dados do msdb e os bancos de dados mestre do primário ao secundário. Para obter mais informações, consulte Considerações sobre restauração de bancos de dados modelo e msdb e Considerações sobre restauração do banco de dados mestre. Se o primário também era um Distribuidor, restaure o banco de dados de distribuição do primário ao secundário.
Esses bancos de dados devem estar consistentes com o banco de dados de publicação no primário em termos de configuração de replicação e definições.
No servidor secundário, renomeie o computador e então renomeie a instância do SQL Server para corresponder ao nome do servidor primário. Para obter informações sobre como renomear um computador, consulte a documentação do Windows. Para obter informações sobre como renomear o servidor, consulte Como renomear um computador que hospeda uma instância autônoma do SQL Server e Como renomear uma instância do cluster de failover do SQL Server.
No servidor secundário, restaure a chave mestra de serviço da qual foi feito o backup do primário. Para obter mais informações, consulte RESTORE SERVICE MASTER KEY (Transact-SQL).
Sincronize o banco de dados de publicação com um ou mais bancos de dados de assinatura. Isto permite que você carregue as alterações que foram feitas anteriormente no banco de dados de publicação, mas que não estão representadas no backup restaurado. Os dados que podem ser carregados dependem do modo como uma publicação é filtrada:
Se a publicação não é filtrada, você deve conseguir atualizar o banco de dados de publicação sincronizando-o com o Assinante mais atualizado.
Se a publicação é filtrada, você talvez não consiga atualizar o banco de dados de publicação. Imagine uma tabela particionada, de modo que cada assinatura receba os dados de clientes somente de uma região: norte, leste, sul e oeste. Se existe pelo menos um Assinante para cada partição de dados, a sincronização com um Assinante para cada partição deverá atualizar o banco de dados de publicação. Entretanto, se os dados da partição oeste, por exemplo, não foram replicados para nenhum Assinante, eles não poderão ser atualizados no Publicador. Neste caso, recomendamos reinicializar todas as assinaturas de forma que os dados no Publicador e nos Assinantes convirjam. Para obter mais informações, consulte Reinicializando uma assinatura.
Se você sincronizar com um Assinante que está executando uma versão do SQL Server anterior à SQL Server 2005, a assinatura não poderá ser anônima; ela deverá ser assinatura de cliente ou de servidor (referidas como assinaturas locais e assinaturas globais nas versões anteriores). Para obter mais informações, consulte Sincronizando dados.
Consulte também