Artigo
04/01/2012

Replicação e espelhamento do banco de dados

O espelhamento de banco de dados pode ser usado para melhorar a disponibilidade de certos bancos de dados de replicação. O suporte para combinar a replicação transacional com o espelhamento de banco de dados depende de qual banco de dados de replicação está sendo considerado. Não há suporte para a replicação ponto a ponto em combinação com o espelhamento de banco de dados. Para obter mais informações sobre espelhamento de banco de dados, consulte Administração de espelhamento de banco de dados.

A tabela a seguir lista os bancos de dados de replicação e o nível correspondente de suporte para o espelhamento.

Banco de dados de replicação	Tem suporte para uso com espelhamento de banco de dados
Publicação	Sim. Tem suporte para replicação transacional e de mesclagem com failover automático. Os agentes de replicação que se conectam ao banco de dados de publicação podem fazer o failover automaticamente para o banco de dados de publicação espelhado. Em caso de falha, os agentes que se conectam ao banco de dados de publicação se reconectarão automaticamente ao novo banco de dados principal.
Distribuição	Não. Não há suporte para o espelhamento de banco de dados de distribuição. O banco de dados de distribuição é onde a configuração de replicação é armazenada, e os metadados de configuração são fortemente vinculados ao nome do servidor onde o distribuidor é configurado. O nome do servidor mudará durante o failover para o banco de dados espelhado, mas os dados de configuração armazenados no banco de dados de distribuição apontará para o servidor de banco de dados de distribuição antigo.
Assinatura	Sim. Tem suporte a partir do SQL Server 2008 para replicação transacional com failover e configuração manuais. Os agentes de replicação que se conectam ao banco de dados de assinatura não são sensíveis ao espelhamento. Se o banco de dados de assinatura principal falhar, o failover para o banco de dados secundário exigirá que você execute várias etapas manuais para restaurar o fluxo de replicação. Para obter mais informações, consulte Replicação do SQL Server: fornecendo alta disponibilidade usando o espelhamento de banco de dados (artigo técnico do SQL Server).

Publicação

Sim.

Tem suporte para replicação transacional e de mesclagem com failover automático. Os agentes de replicação que se conectam ao banco de dados de publicação podem fazer o failover automaticamente para o banco de dados de publicação espelhado. Em caso de falha, os agentes que se conectam ao banco de dados de publicação se reconectarão automaticamente ao novo banco de dados principal.

Distribuição

Não.

Não há suporte para o espelhamento de banco de dados de distribuição. O banco de dados de distribuição é onde a configuração de replicação é armazenada, e os metadados de configuração são fortemente vinculados ao nome do servidor onde o distribuidor é configurado. O nome do servidor mudará durante o failover para o banco de dados espelhado, mas os dados de configuração armazenados no banco de dados de distribuição apontará para o servidor de banco de dados de distribuição antigo.

Assinatura

Sim.

Tem suporte a partir do SQL Server 2008 para replicação transacional com failover e configuração manuais. Os agentes de replicação que se conectam ao banco de dados de assinatura não são sensíveis ao espelhamento. Se o banco de dados de assinatura principal falhar, o failover para o banco de dados secundário exigirá que você execute várias etapas manuais para restaurar o fluxo de replicação. Para obter mais informações, consulte Replicação do SQL Server: fornecendo alta disponibilidade usando o espelhamento de banco de dados (artigo técnico do SQL Server).

Para obter informações sobre como recuperar um banco de dados de distribuição ou banco de dados de assinatura, sem precisar reconfigurar a replicação, consulte Fazendo backup e restaurando bancos de dados replicados.

Observação
Após um failover, o espelho se torna o principal. Nesse tópico, "principal" e "espelho" sempre se referem ao principal original e ao espelho.

Exigências e considerações no uso de replicação com espelhamento do banco de dados

Esteja atento quanto às exigências e às considerações a seguir, quando for usar a replicação com o espelhamento do banco de dados:

O principal e o espelho devem compartilhar um Distribuidor. Recomendamos que esse seja um Distribuidor remoto que ofereça tolerância maior a falhas, caso o Publicador tenha um failover não programado.
O Publicador e o Distribuidor devem ser o Microsoft SQL Server 2005 ou uma versão posterior. Os Assinantes podem ter qualquer versão, mas as assinaturas pull de replicação de mesclagem de uma versão anterior ao SQL Server 2005 não oferece suporte ao failover; neste caso, o agente executa no Assinante e as versões anteriores do agente não consideram o espelho. A replicação desses Assinantes é retomada se ocorrer um failback de banco de dados do espelho para o principal.
A replicação dá suporte ao espelhamento do banco de dados de publicação para a replicação de mesclagem e para a replicação de transação com Assinantes somente leitura ou Assinantes de atualização em fila. Não há suporte para Assinantes de atualização imediata, Editores Oracle, Publicadores em uma topologia ponto a ponto e republicadores.
Os metadados e os objetos que existem fora do banco de dados não são copiados para o espelho, inclusive logons, trabalhos, servidores vinculados, etc. Se precisar dos metadados e dos objetos no espelho, será preciso copiá-los manualmente. Para obter mais informações, consulte Administrando logons e trabalhos depois de troca de funções.

Configurando a replicação do espelhamento do banco de dados

A configuração da replicação e do espelhamento do banco de dados compreende cinco etapas. Cada etapa está descrita com mais detalhes na próxima seção.

Configurar o Publicador.
Configure o espelhamento do banco de dados
Configurar o espelho para usar o mesmo Distribuidor como principal.
Configurar os agentes de replicação para failover.
Adicione o principal e o espelho ao Replication Monitor.

As Etapas 1 e 2 podem ser realizadas também em ordem oposta.

Para configurar o espelhamento de banco de dados para um banco de dados de publicação

Configure o Publicador:
1. Recomendamos o uso de um Distribuidor remoto. Para obter mais informações sobre como configurar a distribuição, consulte Configurando a distribuição.
2. Você pode habilitar um banco de dados para instantâneos e publicações transacionais e/ou publicações de mesclagem. Para bancos de dados espelhados com mais de um tipo de publicação, você deverá habilitar os dois tipos de banco de dados no mesmo nó, usando sp_replicationdboption. Por exemplo, você pode executar as chamadas do procedimento armazenado a seguir, no principal:
```
exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='publish', @value=true
exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='mergepublish', @value=true
```
  Para obter mais informações sobre como criar publicações, consulte Publicando dados e objetos de banco de dados.
Configure o espelhamento do banco de dados Para obter mais informações, consulte Como configurar uma sessão de espelhamento de banco de dados (SQL Server Management Studio) e Configurando espelhamento de banco de dados.
Configure a distribuição para o espelho. Especifique o nome do espelho como Publicador e especifique o mesmo Distribuidor e a pasta de instantâneos usada pelo principal. Por exemplo, caso esteja configurando a replicação com procedimentos armazenados, execute sp_adddistpublisher no Distribuidor e, em seguida, execute sp_adddistributor no espelho. Para sp_adddistpublisher:
- Defina o valor do parâmetro @publisher para o nome de rede do espelho.
- Defina o valor do parâmetro @working_directory para a pasta de instantâneos usada pela entidade.
Especifique o nome de espelho para o parâmetro de agente –PublisherFailoverPartner. Esse parâmetro de agente é exigido pelos seguintes agentes para identificar o espelho, após o failover:
- Snapshot Agent (para todas as publicações)
- Log Reader Agent (para todas as publicações transacionais)
- Queue Reader Agent (para publicações transacionais que dão suporte às assinaturas de atualização em fila).
- Merge Agent (para assinaturas de mesclagem)
- Ouvinte de replicação SQL Server (replisapi.dll: para assinaturas de mesclagem sincronizadas usando a sincronização da Web)
- SQL Merge ActiveX Control (para assinaturas de mesclagem sincronizadas com o controle)
O Distribution Agent e o Distribution ActiveX Control não têm esse parâmetro porque não se conectam ao Publicador.

As alterações do parâmetro de agente entrarão em vigor na próxima vez o agente for iniciado. Se o agente ficar execução continuamente, será necessário parar e reiniciar o agente. Os parâmetros podem ser especificados em perfis de agente e no prompt de comando. Para obter mais informações, consulte:
Recomendamos adicionar o –PublisherFailoverPartner a um perfil de agente e especificar o nome do espelho no perfil. Por exemplo, se você estiver configurando uma replicação com procedimentos armazenados:
```
-- Execute sp_help_agent_profile in the context of the distribution database to get the list of profiles.
-- Select the profile id of the profile that needs to be updated from the result set.
-- In the agent_type column returned by sp_help_agent_profile: 
-- 1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent; 4 = Merge Agent; 9 = Queue Reader Agent.

exec sp_help_agent_profile

-- Setting the -PublisherFailoverPartner parameter in the default Snapshot Agent profile (profile 1).
-- Execute sp_add_agent_parameter in the context of the distribution database.
exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>'

-- Setting the -PublisherFailoverPartner parameter in the default Merge Agent profile (profile 6).
-- Execute sp_add_agent_parameter in the context of the distribution database.
exec sp_add_agent_parameter @profile_id = 6, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>'
```
Adicione o principal e o espelho ao Replication Monitor. Para obter mais informações, consulte Como adicionar e remover Publicadores do Replication Monitor (Replication Monitor).

Mantendo um banco de dados espelhado

Manter um banco de dados de publicação espelhado é praticamente o mesmo que manter um banco de dados não espelhado, com as considerações a seguir:

A administração e o monitoramento devem ocorrer no servidor ativo. No SQL Server Management Studio, as publicações aparecem sob a pasta Publicações Locais, somente para o servidor ativo. Por exemplo, se um failover for realizado no espelho, as publicações serão exibidas no espelho; mas não, no principal. Se ocorrer um failover de banco de dados no espelho, talvez seja necessário atualizar manualmente o Management Studio e o Replication Monitor, para que a alteração seja refletida.
O Replication Monitor exibe os nós do Publicador na árvore de objetos para ambos, o principal e o espelho. Se o principal for o servidor ativo, as informações da publicação só serão exibidas sob o nó principal, no Replication Monitor.

Se o espelho for o servidor ativo:
- Se ocorrer um erro em um agente, esse erro será indicado somente no nó principal, não no nó espelho.
- Se o principal estiver indisponível, os nós principal e espelho exibem listas de publicações idênticas. O monitoramento deve ser realizado nas publicações sob o nó espelho.

Ao usar os procedimentos armazenados ou RMO (Replication Management Objects) para gerenciar a replicação no espelho, nos casos em que você especifica o nome do Publicador, especifique o nome da instância na qual o banco de dados foi habilitado para a replicação. Para determinar o nome apropriado, use a função publishingservername.

Quando um banco de dados de publicação é espelhado, os metadados de replicação armazenados no banco de dados espelhado são idênticos aos metadados armazenados no banco de dados principal. Portanto, para os bancos de dados de publicação habilitados para replicação no principal, o nome da instância do Publicador armazenado nas tabelas do sistema no espelho será o nome do principal, não do espelho. Isso afetará a configuração e a manutenção da replicação, em caso de failover do banco de dados de publicação no espelho. Por exemplo, se você configurar a replicação com procedimentos armazenados no espelho, após o failover; e deseja adicionar uma assinatura pull a um banco de dados de publicação habilitado no principal, especifique o nome do principal, em vez do nome do espelho para o parâmetro @publisher de sp_addpullsubscription ou sp_addmergepullsubscription.

Ao habilitar um banco de dados de publicação no espelho, após o failover para o espelho, o nome da instância do Publicador, armazenado nas tabelas do sistema, será o nome do espelho; neste caso, você usará o nome do espelho para o parâmetro @publisher.

Observação
Em alguns casos, como o sp_addpublication, o parâmetro @publisher tem suporte apenas para os Publicadores não SQL Server; nesses casos, não é relevante para o espelhamento do banco de dados SQL Server.

Para sincronizar uma assinatura no Management Studio, após o failover: sincronize as assinaturas pull do Assinante e sincronize as assinaturas push do Publicador ativo.

Comportamento da replicação se o espelhamento for removido

Considere as questões a seguir, em caso de remoção do espelhamento do banco de dados de um banco de dados publicado:

Se o banco de dados de publicação no principal não estiver mais espelhado, a replicação continuará a funcionar sem-alteração no principal original.
Se ocorrer um failover de banco de dados de publicação do principal para o espelho, e a relação de espelhamento for subsequentemente desabilitada ou removida, os agentes de replicação não funcionarão com o espelho. Se o principal estiver permanentemente perdido, desabilite e, em seguida, reconfigure a replicação com o espelho especificado como Publicador.
Se o espelhamento do banco de dados for completamente removido, o banco de dados espelho estará em um estado de recuperação e deverá ser restaurado para tornar-se funcional. O comportamento do banco de dados recuperado com relação à replicação depende da especificação da opção KEEP_REPLICATION. Essa opção força a operação de restauração para preservar as configurações da replicação, quando for restaurar um banco de dados publicado em um servidor que não seja naquele em que o backup foi criado. Use a opção KEEP_REPLICATION somente quando o outro banco de dados de publicação estiver indisponível. A opção não terá suporte se o outro banco de dados de publicação continuar intacto e replicando. Para obter mais informações sobre a opção KEEP_REPLICATION, consulte RESTORE (Transact-SQL).

Comportamento do Log Reader Agent

A tabela a seguir descreve o comportamento do Log Reader Agent nos vários modos operacionais do espelhamento do banco de dados. Para obter mais informações sobre os modos de operação, consulte Configurações Transact-SQL e modos de operação de espelhamento de banco de dados.

Modo de operação	Comportamento do Log Reader Agent se o espelho estiver indisponível
Modo de segurança alta com failover automático	Se o espelho estiver indisponível, o Log Reader Agent propagará os comandos no banco de dados de distribuição. O principal não pode realizar o failover no espelho, até que este esteja on-line novamente e tenha todas as transações do principal.
Modo de alto desempenho	Se o espelho estiver indisponível, o banco de dados principal estará em execução exposto (isto é, sem-espelho). Porém, o Log Reader Agent só replica as transações que estão intensificadas no espelho. Caso o serviço seja forçado e o servidor espelho assumir a função do principal, o Log Reader Agent funcionará no espelho e iniciará a seleção de novas transações. Para obter mais informações, consulte Serviço forçado (com possível perda de dados). Fique ciente de que a latência de replicação aumentará, se o espelho ficar atrás do principal.
Modo de segurança alta sem failover automático	Todas as transações confirmadas têm a garantia de serem intensificadas em disco, no servidor espelho. O Log Reader Agent só replica as transações que estão intensificadas no espelho. Se o espelho estiver indisponível, o principal proíbe qualquer atividade adicional no banco de dados; portanto, o Log Reader Agent não terá nenhuma transação a ser replicada.

Modo de segurança alta com failover automático

Se o espelho estiver indisponível, o Log Reader Agent propagará os comandos no banco de dados de distribuição. O principal não pode realizar o failover no espelho, até que este esteja on-line novamente e tenha todas as transações do principal.

Modo de alto desempenho

Se o espelho estiver indisponível, o banco de dados principal estará em execução exposto (isto é, sem-espelho). Porém, o Log Reader Agent só replica as transações que estão intensificadas no espelho. Caso o serviço seja forçado e o servidor espelho assumir a função do principal, o Log Reader Agent funcionará no espelho e iniciará a seleção de novas transações. Para obter mais informações, consulte Serviço forçado (com possível perda de dados).

Fique ciente de que a latência de replicação aumentará, se o espelho ficar atrás do principal.

Modo de segurança alta sem failover automático

Todas as transações confirmadas têm a garantia de serem intensificadas em disco, no servidor espelho. O Log Reader Agent só replica as transações que estão intensificadas no espelho. Se o espelho estiver indisponível, o principal proíbe qualquer atividade adicional no banco de dados; portanto, o Log Reader Agent não terá nenhuma transação a ser replicada.