Replicação e Envio de Registos (SQL Server)

Aplica-se a: SQL Server

O envio de registos envolve duas cópias de uma única base de dados que normalmente residem em computadores diferentes. Em qualquer momento, apenas uma cópia da base de dados está atualmente disponível para os clientes. Esta cópia é conhecida como base de dados primária. As atualizações feitas pelos clientes à base de dados primária são propagadas através do envio de registos para a outra cópia da base de dados, conhecida como base de dados secundária. O envio de registos envolve aplicar o registo de transações de cada inserção, atualização ou eliminação feita na base de dados primária na base de dados secundária.

O transporte de registos pode ser usado em conjunto com a replicação, com o seguinte comportamento:

• A replicação não continua após um failover de envio de log. Se ocorrer um failover, os agentes de replicação não se ligam ao secundário, pelo que as transações não são replicadas para os Assinantes. Se ocorrer um retorno ao primário, a replicação recomeça. Todas as transações que registam cópias enviadas do secundário para o primário são replicadas para os Assinantes.

• Se o primário for perdido permanentemente, o secundário pode ser renomeado para que a replicação possa continuar. O restante deste tópico descreve os requisitos e procedimentos para tratar este caso. O exemplo dado é a base de dados de publicações, que é a base de dados mais comum a enviar log, mas um processo semelhante pode também ser aplicado a bases de dados de subscrição e distribuição.

Para informações sobre a recuperação de bases de dados envolvidas na replicação sem necessidade de reconfigurar a replicação, consulte Backup e Restore Databases Replicadas.

Requisitos e Procedimentos para Replicar a partir do Secundário Se o Primário For Perdido

Esteja ciente dos seguintes requisitos e considerações:

• Se um primário contiver mais do que uma base de dados de publicações, faça o log e envie todas as bases de dados de publicações para a mesma secundária.

• O caminho de instalação para a instância secundária do servidor deve ser o mesmo do primário. As localizações da base de dados de utilizadores no servidor secundário devem ser as mesmas que no servidor principal.

• Faz uma cópia de segurança da chave mestra de serviço no primário. Esta chave será restaurada no secundário. Para mais informações, vejaBACKUPSERVICEBACKUP SERVICE MASTER KEY (Transact-SQL).

• O envio de registos não garante a perda de dados. Uma falha na base de dados primária pode resultar na perda de dados que ainda não foram copiados ou na perda de backups durante a falha.

Envio de Registos com Replicação Transacional

Para a replicação transacional, o comportamento do envio de log depende da opção de sincronizar com backup . Esta opção pode ser definida na base de dados de publicações e na base de dados de distribuição; no envio de log para o Publisher, apenas a definição na base de dados de publicações é relevante.

Definir esta opção na base de dados de publicações garante que as transações não são entregues à base de dados de distribuição até que sejam guardadas na base de dados de publicações. A última cópia de segurança da base de dados de publicações pode então ser restaurada no servidor secundário sem qualquer possibilidade de a base de dados de distribuição ter transações que a base de dados de publicações restaurada não possui. Esta opção garante que, se o Publisher fizer failover para um servidor secundário, a consistência é mantida entre o Publisher, o Distribuidor e os Assinantes. A latência e o rendimento são afetados porque as transações não podem ser entregues à base de dados de distribuição até terem sido copiadas no Publisher; se a sua aplicação tolerar esta latência, recomendamos que defina esta opção na base de dados de publicações. Se a opção de sincronização com backup não estiver definida, os Assinantes podem receber alterações que já não estão incluídas na base de dados recuperada no servidor secundário. Para mais informações, consulte Estratégias para Backup e Restauração de Snapshots e Replicação Transacional.

Para configurar a replicação transacional e o registo do envio com a opção sincronizar com backup

1. Se a opção de sincronização com backup não estiver definida na base de dados de publicação, execute sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'. Para mais informações, consulte sp_replicationdboption (Transact-SQL).

2. Configure o envio de registos para a base de dados de publicações. Para obter mais informações, consulte Configurar envio de logs (SQL Server).

3. Se o Publisher falhar, restaure o último registo da base de dados no servidor secundário, usando a opção KEEP_REPLICATION LOGRESTORE. Isto mantém todas as definições de replicação da base de dados. Para mais informações, veja Failover para um Expediente de Troncos Secundário (SQL Server) e RESTORE (Transact-SQL).

4. Restaure a base de dados MSDB e as bases de dados mestres da principal para a secundária. Para obter mais informações, consulte Backup e restauração de bancos de dados do sistema (SQL Server). Se o primário também era um Distribuidor, restaure a base de dados de distribuição do primário para o secundário.

   Estas bases de dados devem ser consistentes com a base de dados de publicação na primária em termos de configuração e definições de replicação.

5. No servidor secundário, renomeia o computador e depois renomeia a instância do SQL Server para corresponder ao nome do servidor principal. Para informações sobre a mudança de nome do computador, consulte a documentação do Windows. Para informações sobre como renomear o servidor, consulte Renomear um Computador que Aloja uma Instância Stand-Alone de SQL Server e Renomear uma Instância de Cluster de Failover SQL Server.

6. No servidor secundário, restaurar a chave mestra de serviço que foi feita backup a partir do primário. Para mais informações, vejaRESTORESERVICERESTORE 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 registos para a base de dados de publicações. Para obter mais informações, consulte Configurar envio de logs (SQL Server).

2. Se o Publisher falhar, restaure o último registo da base de dados no servidor secundário, usando a opção KEEP_REPLICATION LOGRESTORE. Isto mantém todas as definições de replicação da base de dados. Para mais informações, veja Failover para um Expediente de Troncos Secundário (SQL Server) e RESTORE (Transact-SQL).

3. Restaure a base de dados MSDB e as bases de dados mestres da principal para a secundária. Para obter mais informações, consulte Backup e restauração de bancos de dados do sistema (SQL Server). Se o primário também era um Distribuidor, restaure a base de dados de distribuição do primário para o secundário.

   Estas bases de dados devem ser consistentes com a base de dados de publicação na primária em termos de configuração e definições de replicação.

4. No servidor secundário, renomeia o computador e depois renomeia a instância do SQL Server para corresponder ao nome do servidor principal. Para informações sobre a mudança de nome do computador, consulte a documentação do Windows. Para informações sobre como renomear o servidor, consulte Renomear um Computador que Aloja uma Instância Stand-Alone de SQL Server e Renomear uma Instância de Cluster de Failover SQL Server.

   Pode receber uma mensagem de erro do Agente Leitor de Registos a informar que a base de dados de publicação e a base de dados de distribuição não estão sincronizadas.

5. No servidor secundário, restaurar a chave mestra de serviço que foi feita backup a partir do primário. Para mais informações, vejaRESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

6. Executa sp_replrestart. Este procedimento armazenado pode ser usado para forçar o Agente Leitor de Registos a ignorar todas as transações replicadas anteriores no registo da base de dados de publicação. As transações aplicadas após a conclusão do procedimento armazenado são processadas pelo Agente Leitor de Log. Para mais informações, consulte sp_replrestart (Transact-SQL).

7. Reinicie o Agente Leitor de Registo após a execução com sucesso do procedimento armazenado. Para mais informações, consulte Iniciar e Parar um Agente de Replicação (SQL Server Management Studio).

8. Transações que já tenham sido distribuídas ao Assinante podem ser aplicadas no Publisher. Para garantir que o Distribution Agent não falha com um erro ao tentar reaplicar estas transações num Assinante, especifique o perfil do agente intitulado Continue On Data Consistency Errors.

Envio de Registos com Replicação de Fusão

Siga os passos do procedimento abaixo para configurar a replicação de fusões e o envio de logs.

Para configurar a replicação de fusão e o envio de registos

1. Configure o envio de registos para a base de dados de publicações. Para obter mais informações, consulte Configurar envio de logs (SQL Server).

2. Se o Publisher falhar, no servidor secundário, renomeie o computador e depois renomeie a instância do SQL Server para corresponder ao nome do servidor principal. Para informações sobre a mudança de nome do computador, consulte a documentação do Windows. Para informações sobre como renomear o servidor, consulte Renomear um Computador que Aloja uma Instância Stand-Alone de SQL Server e Renomear uma Instância de Cluster de Failover SQL Server.

3. Restaurar o último registo da base de dados no servidor secundário, usando a opção KEEP_REPLICATION LOG RESTORE . Isto mantém todas as definições de replicação da base de dados. Para mais informações, veja Failover para um Expediente de Troncos Secundário (SQL Server) e RESTORE (Transact-SQL).

4. Restaure a base de dados MSDB e as bases de dados mestres da principal para a secundária. Para obter mais informações, consulte Backup e restauração de bancos de dados do sistema (SQL Server). Se o primário também era um Distribuidor, restaure a base de dados de distribuição do primário para o secundário.

   Estas bases de dados devem ser consistentes com a base de dados de publicação na primária em termos de configuração e definições de replicação.

5. No servidor secundário, restaurar a chave mestra de serviço que foi feita backup a partir do primário. Para mais informações, vejaRESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

6. Sincronize a base de dados de publicações com uma ou mais bases de dados por subscrição. Isto permite-lhe carregar as alterações feitas anteriormente na base de dados de publicações, mas que não são representadas no backup restaurado. Os dados que podem ser carregados dependem da forma como uma publicação é filtrada:

   • Se a publicação não estiver filtrada, deverá conseguir trazer a base de dados da publicação up-todata sincronizando com o assinante com a data mais up-to.

   • Se a publicação for filtrada, pode não conseguir trazer a base de dados de publicações up-todata. Considere uma tabela particionada de modo que cada subscrição receba dados do cliente apenas para uma única região: Norte, Este, Sul e Oeste. Se houver pelo menos um Assinante para cada partição de dados, a sincronização com um Assinante para cada partição deve trazer a base de dados de publicação up-to-data. No entanto, se os dados da partição Ocidental, por exemplo, não foram replicados para nenhum Assinante, esses dados no Publisher não podem ser trazidos up-to-data. Neste caso, recomendamos reinicializar todas as subscrições para que os dados no Publisher e nos Subscritores convergam. Para mais informações, consulte Reinicializar Subscrições.

   Se sincronizar com um Assinante que esteja a correr uma versão do SQL Server anterior ao SQL Server 2005 (9.x), a subscrição não pode ser anónima; deve ser uma subscrição de cliente ou de servidor (referida como subscrições locais e subscrições globais em versões anteriores). Para mais informações, consulte Sincronizar Dados.

Ver também

Replicação do SQL Server
Sobre o Log Shipping (SQL Server)Configurar a replicação com grupos de disponibilidade Always On