Partilhar via

Mantendo um Banco de Dados de Publicação AlwaysOn (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 PUBLISHINGSERVERNAME função. 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 um secundário após o failover e quiser uma assinatura pull para um banco de dados de publicação habilitado em uma réplica diferente, especifique o nome do publicador original em vez do publicador atual como o parâmetro @publisher de sp_addpullsubscription ou sp_addmergepulllsubscription. 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_addpublicationo parâmetro @publisher tem suporte apenas para editores que não são instâncias do SQL Server; nesses casos, não é relevante para o ALWAYSOn 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, você deve executar sp_redirect_publisher sem especificar um valor para o parâmetro @redirected_publisher a fim de remover o redirecionamento por 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 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 sp_redirect_publisher armazenado 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á o mesmo de quando um banco de dados publicado é 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 de publicação. Defina o parâmetro @ignore_distributributor 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 do 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.

Tarefas Relacionadas

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 AlwaysOn: Interoperabilidade (SQL Server)
Replicação do SQL Server

  • Last updated on