Replicação e envio de logs (SQL Server)

Aplica-se a:SQL Server

O envio de logs envolve duas cópias de um único banco de dados que, normalmente, residem em computadores diferentes. Em determinado momento, apenas uma cópia do banco de dados está atualmente disponível aos clientes. Essa 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 transporte de logs envolve a aplicação do log de transações de cada inserção, atualização ou exclusão feita no banco de dados primário ao 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 se conectam ao secundário; portanto, as transações não são replicadas para os Assinantes. Se ocorrer um failback para o primário, a replicação será retomada. Todas as transações que são copiadas pelo envio de logs do secundário para o primário são replicadas para os assinantes.

• Se o primário for permanentemente perdido, o secundário poderá ser renomeado para 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 semelhante para bancos de dados de assinatura e distribuição.

Para obter informações sobre como recuperar bancos de dados envolvidos em replicação sem nenhuma necessidade de reconfigurar a replicação, consulte Fazer backup e restaurar bancos de dados replicados.

Requisitos e procedimentos para replicação a partir do secundário se o primário for perdido

Lembre-se dos requisitos e considerações a seguir:

• Se o primário contiver mais de um banco de dados de publicação, envie os logs de todos os bancos de dados de publicação ao mesmo secundário.

• O caminho de instalação da instância do servidor secundário deve ser igual ao do primário. Os locais do banco de dados do usuário no servidor secundário devem ser iguais aos do primário.

• Faça backup da chave mestra do serviço na instância primária. Essa chave será restaurada no secundário. Para obter mais informações, consulte BACKUPSERVICEBACKUP SERVICE MASTER KEY (Transact-SQL).

• O envio de logs não oferece garantia contra a 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, apenas a configuração no banco de dados de publicação é relevante.

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 realizado 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 o Publicador fizer failover para um servidor secundário, a consistência seja mantida 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. É recomendável definir 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 o envio de logs com a opção sincronizar com backup

1. 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, confira sp_replicationdboption (Transact-SQL).

2. Configure o envio de logs para o banco de dados de publicação. Para obter mais informações, veja Configurar o envio de logs (SQL Server).

3. Se o Publisher falhar, restaure o último log do banco de dados para o servidor secundário usando a opção KEEP_REPLICATION de RESTORE LOG. Isso retém todas as configurações de replicação do banco de dados. Para obter mais informações, consulte FailOver para um Secundário de Envio de Logs (SQL Server) e RESTORE (Transact-SQL).

4. Restaure os bancos de dados msdb e master do primário para o secundário. Para obter mais informações, confira Backup e restauração de bancos de dados do sistema (SQL Server). Se o primário também era um Distribuidor, restaure o banco de dados de distribuição do primário para o secundário.

   Esses bancos de dados devem estar em conformidade com o banco de dados de publicação no servidor primário em termos de configuração e configurações de replicação.

5. No servidor secundário, renomeie o computador e, em seguida, renomeie a instância do SQL Server para que corresponda 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 Renomear um computador que hospeda uma instância autônoma do SQL Server e Renomear uma instância do cluster de failover do SQL Server.

6. 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 RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

Para configurar a replicação transacional e o envio de logs sem a opção de sincronização com backup

1. Configure o envio de logs para o banco de dados de publicação. Para obter mais informações, veja Configurar o envio de logs (SQL Server).

2. Se o Publisher falhar, restaure o último log do banco de dados para o servidor secundário usando a opção KEEP_REPLICATION de RESTORE LOG. Isso retém todas as configurações de replicação do banco de dados. Para obter mais informações, consulte FailOver para um Secundário de Envio de Logs (SQL Server) e RESTORE (Transact-SQL).

3. Restaure os bancos de dados msdb e master do primário para o secundário. Para obter mais informações, confira Backup e restauração de bancos de dados do sistema (SQL Server). Se o primário também era um Distribuidor, restaure o banco de dados de distribuição do servidor primário para o servidor secundário.

   Esses bancos de dados devem estar em conformidade com o banco de dados de publicação no servidor primário quanto à configuração e às definições de replicação.

4. No servidor secundário, renomeie o computador e, em seguida, renomeie a instância do SQL Server para que corresponda 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 Renomear um computador que hospeda uma instância autônoma do SQL Server e 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.

5. 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 RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

6. 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, confira sp_replrestart (Transact-SQL).

7. Reinicie o Log Reader Agent depois que o procedimento armazenado for executado com êxito. Para obter mais informações, confira Iniciar e interromper um agente de replicação (SQL Server Management Studio).

8. As transações que já foram distribuídas ao Assinante podem ser aplicadas no Publicador. Para garantir que o Agente de Distribuição não falhe com um erro ao tentar reaplicar essas transações no Assinante, especifique o perfil do agente com o título Continue On Data Consistency Errors.

Envio de logs com replicação de mesclagem

Siga as etapas do procedimento abaixo para configurar a replicação de mesclagem e o envio de logs.

Para configurar a replicação de mesclagem e envio de logs

1. Configure o envio de logs para o banco de dados de publicação. Para obter mais informações, veja Configurar o envio de logs (SQL Server).

2. Se ocorrer falha no Publicador, no servidor secundário, renomeie o computador e, em seguida, renomeie a instância do SQL Server para que corresponda 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 Renomear um computador que hospeda uma instância autônoma do SQL Server e Renomear uma instância do cluster de failover do SQL Server.

3. Restaure o último log do banco de dados para o servidor secundário, usando a opção KEEP_REPLICATION do RESTORE LOG. Isso retém todas as configurações de replicação do banco de dados. Para obter mais informações, consulte FailOver para um Secundário de Envio de Logs (SQL Server) e RESTORE (Transact-SQL).

4. Restaure os bancos de dados msdb e master do primário para o secundário. Para obter mais informações, confira Backup e restauração de bancos de dados do sistema (SQL Server). Se o primário também era um Distribuidor, restaure o banco de dados de distribuição da primária para a secundária.

   Esses bancos de dados devem ser compatíveis com o banco de dados de publicação no servidor primário em termos de configuração e de definições de replicação.

5. 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 RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

6. Sincronize o banco de dados de publicação com um ou mais bancos de dados de assinatura. Isso permite que você carregue as alterações 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 for filtrada, você deverá conseguir atualizar o banco de dados de publicação com uma sincronização com o Assinante mais atualizado.

   • Se a publicação estiver filtrada, talvez você não consiga atualizar o banco de dados da publicação. Considere uma tabela particionada, de modo que cada assinatura receba os dados de clientes somente de uma região: norte, leste, sul e oeste. Se existir 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 por exemplo, os dados da partição oeste, não foram replicados para nenhum Assinante, então esses dados no Publicador não poderão ser atualizados. Nesse caso, é recomendável reinicializar todas as assinaturas de forma que os dados no Publicador e nos Assinantes convirjam. Para obter mais informações, consulte Reinicializar as assinaturas.

   Se você sincronizar com um Assinante que está executando uma versão do SQL Server anterior à SQL Server 2005 (9.x), a assinatura não poderá ser anônima; ela deverá ser a assinatura de um cliente ou de um servidor (referenciadas como assinaturas locais e assinaturas globais nas versões anteriores). Para obter mais informações, consulte Sincronizar dados.

Consulte Também

Replicação do SQL Server
Sobre a Remessa de Logs (SQL Server)Configurar a replicação usando grupos de disponibilidade Always On