Gerenciar um banco de dados publicador replicado como parte de um grupo de disponibilidade Always On

Aplica-se a:SQL Server

Este tópico discute considerações especiais para manter um banco de dados de publicação quando você usa grupos de disponibilidade AlwaysOn.

Mantendo um banco de dados publicado em um grupo de disponibilidade

Manter um banco de dados de publicação AlwaysOn é basicamente o mesmo que manter um banco de dados de publicação padrão, com as seguintes considerações:

Administração deve ocorrer no host de réplica primária. No SQL Server Management Studio, as publicações aparecem sob a pasta Publicações Locais para o host de réplica primária e também para réplicas secundárias legíveis. Depois do failover, talvez você precise atualizar manualmente o Management Studio para que a alteração seja refletida se a réplica secundária elevada a primária não estiver legível.
O monitor de replicação sempre exibe informações de publicação sob o publicador original. Entretanto, estas informações podem ser exibidas no Monitor de Replicação de qualquer réplica, adicionando o publicador original como um servidor.
Ao usar procedimentos armazenados ou o RMO (Replication Management Objects) para administrar a replicação no publicador primário atual, nos casos em que você especificar o nome do Publicador, deverá especificar o nome da instância na qual o banco de dados foi habilitado para replicação (o publicador original). Para determinar o nome apropriado, use a função PUBLISHINGSERVERNAME . Quando um banco de dados de publicação ingressa em um grupo de disponibilidade, os metadados de replicação armazenados nas réplicas de banco de dados secundárias são idênticos aos da réplica primária. Portanto, para os bancos de dados de publicação habilitados para replicação na réplica primária, o nome da instância do publicador armazenado nas tabelas do sistema na réplica secundária é o nome da instância primária, e não da secundária. Isso afeta a configuração e a manutenção da replicação, em caso de falha do banco de dados de publicação para uma réplica secundária. Por exemplo, se você estiver configurando a replicação com procedimentos armazenados em uma réplica secundária após o failover e desejar uma assinatura pull para um banco de dados de publicação habilitado em outra réplica, deverá especificar o nome do publicador original em vez do publicador atual como o parâmetro @publisher de sp_addpullsubscription ou sp_addmergepullsubscription. Entretanto, se você habilitar um banco de dados de publicação após o failover, o nome da instância do publicador armazenado nas tabelas do sistema corresponderá ao nome do host primário atual. Neste caso, você usaria o nome de host da réplica primária atual para o parâmetro @publisher .

Observação

Para alguns procedimentos, como sp_addpublication, há suporte para o parâmetro @publisher apenas nos publicadores que não são instâncias do SQL Server; nesses casos, ele não é relevante para o Always On do 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.

Removendo um banco de dados publicado de um grupo de disponibilidade

Considere os seguintes problemas se um banco de dados publicado for removido de um grupo de disponibilidade ou se um grupo de disponibilidade que tenha um banco de dados membro publicado for excluído.

Se o banco de dados de publicação do publicador original for removido de uma réplica primária de um grupo de disponibilidade, você deverá executar sp_redirect_publisher sem especificar um valor para o parâmetro @redirected_publisher, a fim de remover o redirecionamento do par publicador/banco de dados.
```
EXEC sys.sp_redirect_publisher   
    @original_publisher = 'MyPublisher',  
    @published_database = 'MyPublishedDB';  
```
O banco de dados ficará no estado de recuperação no primário e deverá ser recuperado. Depois de fazer isso, a replicação deve continuar funcionando sem alterações com o Publicador original.
Se o banco de dados de publicação sofrer failover do publicador original para uma réplica, e o banco de dados for removido da réplica primária do grupo de disponibilidade, use o procedimento armazenado sp_redirect_publisher para redirecionar explicitamente o publicador original para o novo publicador. O banco de dados será deixado no estado de recuperação e deverá ser restaurado. Depois de fazer isso, a replicação deve continuar funcionando como funcionava no grupo de disponibilidade.
```
EXEC sys.sp_redirect_publisher   
    @original_publisher = 'MyPublisher',  
    @published_database = 'MyPublishedDB',  
    @redirected_publisher = 'MyNewPublisher';  
```
Não remova o servidor remoto para o publicador original do distribuidor, mesmo que o servidor não possa mais ser acessado. Os metadados de servidor para o publicador original são necessários no distribuidor para atender consultas de metadados de publicação.
Se um grupo de disponibilidade completo for removido, o comportamento em relação a um banco de dados replicado de membro será igual ao de um banco de dados publicado que é removido de um grupo de disponibilidade. A replicação poderá ser retomada da réplica primária mais recente assim que o banco de dados for restaurado e o redirecionamento for modificado. Se o banco de dados for restaurado em seu publicador original, o redirecionamento deverá ser removido. Se o banco de dados for restaurado em um host diferente, o redirecionamento deverá ser direcionado explicitamente ao novo host.

Observação

Quando um grupo de disponibilidade que publicou bancos de dados de membro é removido, ou um banco de dados publicado é removido de um grupo de disponibilidade, todas as cópias dos bancos de dados publicados permanecem no estado de recuperação. Se restaurado, cada um aparecerá como um banco de dados publicado. Apenas uma cópia deve ser retida com metadados de publicação. Para desabilitar a replicação para uma cópia de banco de dados publicada, primeiro remova todas as assinaturas e publicações do banco de dados.

Execute sp_dropsubscription para remover assinaturas da publicação. Defina o parâmetro @ignore_distributor como 1 para preservar os metadados do banco de dados de publicação ativo no distribuidor.
```
USE MyDBName;  
GO  

EXEC sys.sp_dropsubscription   
    @subscriber = 'MySubscriber',  
    @publication = 'MyPublication',  
    @article = 'all',  
    @ignore_distributor = 1;  
```
Execute sp_droppublication para remover todas as publicações. Novamente, defina o parâmetro @ignore_distributor como 1 para preservar os metadados do banco de dados de publicação ativo no distribuidor.
```
EXEC sys.sp_droppublication   
    @publication = 'MyPublication',  
    @ignore_distributor = 1;  
```
Execute sp_replicationdboption para desabilitar a replicação para o banco de dados.
```
EXEC sys.sp_replicationdboption  
    @dbname = 'MyDBName',  
    @optname = 'publish',  
    @value = 'false';  
```
Neste momento, a cópia do banco de dados publicado pode ser retida ou removida.

Remover fornecedor original

Pode haver instâncias (substituir servidor mais antigo, upgrade do sistema operacional etc.) nas quais você deseja remover um fornecedor original de um grupo de disponibilidade Always On. Siga as etapas nesta seção para remover o fornecedor do grupo de disponibilidade.

Suponha que você tenha os servidores N1, N2 e D1, em que N1 e N2 sejam a réplica primária e secundária do grupo de disponibilidade AG1, N1 é o fornecedor original de uma publicação transacional e D1 é o distribuidor. Você gostaria de substituir o fornecedor original N1 pelo novo fornecedor N3.

Para remover o fornecedor, siga estas etapas:

Instale e configure o SQL Server no nó N3. A versão do SQL Server deve ser a mesma do fornecedor original.
No servidor do distribuidor D1, adicione N3 como um fornecedor usando sp_adddistpublisher.
Configure o N3 como editor, com o D1 como distribuidor.
Adicione N3 como uma réplica ao grupo de disponibilidade AG1.
Na réplica N3, verifique se os assinantes de push da publicação aparecem como servidores vinculados. Use o sp_addlinkedserver ou o SQL Server Management Studio.
Depois que o N3 estiver sincronizado, execute o failover do grupo de disponibilidade para que o N3 se torne o primário.
Remova N1 do grupo de disponibilidade AG1.

Considere também o seguinte:

Não remova do distribuidor o servidor remoto do publicador original (N1, neste caso) nem nenhum metadado associado a ele, mesmo que o servidor não esteja mais acessível. Os metadados do servidor para o publicador original são necessários no distribuidor para satisfazer consultas de metadados de publicação, e, sem eles, a replicação falhará.
Para o SQL Server 2014, depois que o fornecedor original for removido, você não poderá usar o nome do fornecedor original para administrar a replicação no Replication Monitor. Se você tentar registrar novas réplicas como publicador no Replication Monitor, as informações não serão exibidas, pois não há metadados associados a elas. Para administrar a replicação nesse cenário, você terá que clicar com o botão direito do mouse em publicações e assinaturas individuais no SSMS (SQL Server Management Studio).
Para o SQL Server 2016 SP2-CU3, SQL Server 2017 CU6 e versões posteriores, registre o listener do publicador do grupo de disponibilidade no Monitor de Replicação para administrar a replicação usando o SQL Server Management Studio versão 17.7 e posteriores.

Tarefas Relacionadas

Comentários

Esta página foi útil?

Last updated on 2026-08-24