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 uma reversão para o primário, a replicação é retomada. 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 obter informações sobre a recuperação de bases de dados envolvidas na replicação sem necessidade de reconfigurar a replicação, consulte Efetuar Cópias de Segurança e Restaurar Bases de Dados 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 servidor primário contiver mais de uma base de dados de publicação, configure o envio dos registos de transações de todas as bases de dados de publicação para o mesmo servidor secundário.

• 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.

• Efetuar uma cópia de segurança da chave mestra de serviço no servidor primário. Esta chave será restaurada na secundária. 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 Publicador mudar para um servidor secundário, a consistência seja mantida entre o Publicador, o Distribuidor e os Subscritores. 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 a expedição de registos com a opção de sincronização com cópia de segurança

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 de transações da base de dados para o servidor secundário, utilizando a opção KEEP_REPLICATION de 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 as bases de dados msdb e master da primária 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 no servidor primário, em termos de configuração e definições da 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, restaure a chave mestra do serviço da qual foi feita uma cópia de segurança no servidor 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 de transações da base de dados para o servidor secundário, utilizando a opção KEEP_REPLICATION de LOG RESTORE. Isto mantém todas as definições de replicação da base de dados. Para mais informações, consulte Efetuar a ativação pós-falha para um secundário de envio de registos (SQL Server) e RESTORE (Transact-SQL).

3. Restaure a base de dados msdb e a base de dados master da primária 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 no servidor primário, em termos de configuração da replicação e respetivas definições.

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, restaure a chave mestra do serviço cuja cópia de segurança foi criada no servidor 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. As transações que já tenham sido distribuídas ao Assinante podem ser aplicadas no Publicador. Para garantir que o Agente de Distribuição não falhe com erro ao tentar reaplicar estas transações num Subscritor, especifique o perfil de agente com o nome Continuar em Erros de Consistência de Dados.

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 log da base de dados para o servidor secundário, usando a opção KEEP_REPLICATION de RESTORE LOG. 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 as bases de dados msdb e master da primária 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 no servidor primário, em termos de configuração e definições da replicação.

5. No servidor secundário, restaure a chave mestra do serviço da qual foi feita uma cópia de segurança no servidor 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 atualizar a base de dados da publicação sincronizando-a com o Assinante mais atualizado.

   • Se a publicação for filtrada, poderá não conseguir atualizar a base de dados da publicação. 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 deverá atualizar a base de dados da publicação. No entanto, se os dados da partição Oeste, por exemplo, não tiverem sido replicados para nenhum subscritor, estes dados no Publicador não podem ser atualizados. 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