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

Artigo
04/26/2023

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:

A 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 os procedimentos armazenados ou RMO (Replication Management Objects) para gerenciar na réplica primária atual, 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 (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 em tabelas do sistema na réplica secundária é o nome da réplica 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 secundária após o failover e desejar uma assinatura pull de um banco de dados de publicação que foi habilitado em outra réplica, especifique 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 depois do failover, o nome de instância de publicador armazenado nas tabelas do sistema será o 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 problemas a seguir se um banco de dados publicado for removido de um grupo de disponibilidade, ou se um grupo de disponibilidade que tem um banco de dados de membro publicado for removido.

Se o banco de dados de publicação no publicador original for removido de uma réplica primária do grupo de disponibilidade, execute sp_redirect_publisher sem especificar um valor para o parâmetro @redirected_publisher para remover o redirecionamento para o par publicador/banco de dados.
```
EXEC sys.sp_redirect_publisher   
    @original_publisher = 'MyPublisher',  
    @published_database = 'MyPublishedDB';  
```
O banco de dados será deixado no estado de recuperação na réplica primária e deve ser restaurado. Quando você faz isso, a replicação deve funcionar inalterada no Publicador original.
Se o banco de dados de publicação fizer o 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. Quando você faz isso, a replicação deve continuar a funcionar como ocorria 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. Verifique se o parâmetro @ignore_distributor está definido como 1 para preservar os metadados para o 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 N3 como um fornecedor com D1 como seu 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 SQL Server Management Studio.
Depois que N3 for sincronizado, reprovará o grupo de disponibilidade para o N3 como primário.
Remova N1 do grupo de disponibilidade AG1.

Considere também o seguinte:

Não remova o servidor remoto para o fornecedor original (neste caso, N1) ou quaisquer metadados associados a ele pelo distribuidor, mesmo que o servidor não possa mais ser acessado. Os metadados de servidor para o fornecedor original são necessários no distribuidor para atender consultas de metadados de publicação. Sem isso, 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 fornecedor no Replication Monitor, as informações não serão mostradas, pois não há metadados associados a ela. 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, o SQL Server 2017 CU6 e posterior, registre o ouvinte do fornecedor do grupo de disponibilidade no Replication Monitor para administrar a replicação usando SQL Server Management Studio versão 17.7 e superior.

Related Tasks

Consulte Também

Pré-requisitos, restrições e recomendações para Grupos de Disponibilidade AlwaysOn (SQL Server)
Visão geral dos Grupos de Disponibilidade AlwaysOn (SQL Server)
Grupos de disponibilidade Always On: interoperabilidade (SQL Server)
Replicação do SQL Server

Compartilhar via