Gerir uma base de dados replicada do Publisher como parte de um grupo de disponibilidade Always On

Aplica-se a: SQL Server

Este tema discute considerações especiais para manter uma base de dados de publicações quando utiliza grupos de disponibilidade Always On.

Manter uma Base de Dados Publicada num Grupo de Disponibilidade

Manter uma base de dados de publicações Always On é basicamente o mesmo que manter uma base de dados padrão de publicações, com as seguintes considerações:

  • A administração deve ocorrer no hospedeiro réplica primário. No SQL Server Management Studio, as publicações aparecem na pasta Publicações Locais para o host principal da réplica e também para réplicas secundárias legíveis. Após o failover, pode ser necessário atualizar manualmente o Management Studio para que a alteração seja refletida se o secundário promovido a primário não fosse legível.

  • O Replication Monitor apresenta sempre a informação de publicação sob o editor original. No entanto, esta informação pode ser visualizada no Replication Monitor a partir de qualquer réplica, adicionando o editor original como servidor.

  • Ao utilizar procedimentos armazenados ou Objetos de Gestão de Replicação (RMO) para administrar a replicação no primário atual, nos casos em que especifica o nome do Publisher, deve especificar o nome da instância na qual a base de dados foi ativada para replicação (o Publisher original). Para determinar o nome apropriado, utilize a função PUBLISHINGSERVERNAME . Quando uma base de dados publicadora se junta a um grupo de disponibilidade, os metadados de replicação armazenados nas réplicas secundárias da base de dados são idênticos aos da base primária. Consequentemente, para bases de dados de publicação habilitadas para replicação na primária, o nome da instância do editor armazenado em tabelas de sistema na secundária é o nome da primária, não da secundária. Isto afeta a replicação, configuração e manutenção se a base de dados de publicações passar para uma secundária. Por exemplo, se estiver a configurar a replicação com procedimentos armazenados num servidor secundário após o failover, e pretender uma subscrição pull para uma base de dados de publicação que foi ativada numa réplica diferente, tem de especificar o nome do publicador original em vez do publicador atual como o parâmetro @publisher de sp_addpullsubscription ou sp_addmergepullsubscription. No entanto, se ativar uma base de dados de publicação após o failover, o nome da instância do Publicador, armazenado nas tabelas do sistema, é o nome do host principal atual. Neste caso, usaria o nome do host da réplica primária atual para o parâmetro @publisher .

    Note

    Para alguns procedimentos, como o sp_addpublication, o parâmetro @publisher é suportado apenas para editoras que não são instâncias de SQL Server; nestes casos, não é relevante para SQL Server Always On.

  • Para sincronizar uma subscrição no Management Studio após um failover, sincronize as subscrições pull do assinante e as subscrições push do publisher ativo.

Remoção de uma Base de Dados Publicada de um Grupo de Disponibilidade

Considere as seguintes questões se uma base de dados publicada for removida de um grupo de disponibilidade, ou se um grupo de disponibilidade que tem uma base de dados de membros publicada for eliminado.

  • Se a base de dados de publicações do publicador original for removida de uma réplica primária de um grupo de disponibilidade, tem de executar sp_redirect_publisher sem especificar um valor para o parâmetro @redirected_publisher, de modo a remover o redirecionamento do par publicador/base de dados.

    EXEC sys.sp_redirect_publisher   
    @original_publisher = 'MyPublisher',  
    @published_database = 'MyPublishedDB';

    A base de dados será deixada em estado de recuperação no servidor primário e terá de ser restaurada. Depois de fazer isto, a replicação deverá funcionar inalterada contra o Publisher original.

  • Se a base de dados de publicações fizer failover do editor original para uma réplica e a base de dados for removida da réplica principal do grupo de disponibilidade, use o procedimento armazenado sp_redirect_publisher para redirecionar explicitamente o editor original para o novo editor. A base de dados ficará em estado de recuperação e terá de ser restaurada. Depois de fazer isto, a replicação deverá continuar a funcionar como funcionava no grupo de disponibilidade.

    EXEC sys.sp_redirect_publisher   
    @original_publisher = 'MyPublisher',  
    @published_database = 'MyPublishedDB',  
    @redirected_publisher = 'MyNewPublisher';

    Não remova do distribuidor o servidor remoto do editor original, mesmo que o servidor já não possa ser acedido. Os metadados do servidor do editor original são necessários no distribuidor para dar resposta a consultas sobre os metadados da publicação.

  • Se um grupo completo de disponibilidade for removido, o comportamento relativamente a uma base de dados replicada por membros é o mesmo que quando uma base de dados publicada é removida de um grupo de disponibilidade. A replicação pode ser retomada a partir do último primário assim que a base de dados for restaurada e o redirecionamento modificado. Se a base de dados for restaurada no seu editor original, o redirecionamento deve ser removido. Se a base de dados for restaurada num host diferente, o redirecionamento deve ser explicitamente direcionado para o novo host.

    Note

    Quando um grupo de disponibilidade é removido que tem bases de dados membros publicadas, ou uma base de dados publicada é removida de um grupo de disponibilidade, todas as cópias das bases de dados publicadas ficam no estado de recuperação. Se restaurado, cada um aparecerá como uma base de dados publicada. Apenas uma cópia deve ser mantida com os metadados da publicação. Para desativar a replicação de uma cópia publicada na base de dados, remova primeiro todas as subscrições e publicações da base de dados.

    Execute sp_dropsubscription para remover subscrições de publicações. Certifique-se de definir o parâmetro @ignore_distributor para 1 para preservar os metadados da base de dados de publicação ativa no distribuidor.

    USE MyDBName;  
GO  

EXEC sys.sp_dropsubscription   
    @subscriber = 'MySubscriber',  
    @publication = 'MyPublication',  
    @article = 'all',  
    @ignore_distributor = 1;

    Faça sp_droppublication para remover todas as publicações. Mais uma vez, defina o parâmetro @ignore_distributor para 1 para preservar os metadados da base de dados de publicação ativa no distribuidor.

    EXEC sys.sp_droppublication   
    @publication = 'MyPublication',  
    @ignore_distributor = 1;

    Execute sp_replicationdboption para desativar a replicação da base de dados.

    EXEC sys.sp_replicationdboption  
    @dbname = 'MyDBName',  
    @optname = 'publish',  
    @value = 'false';

    Neste ponto, a cópia da base de dados publicada pode ser mantida ou retirada.

Remover o publicador original

Podem existir situações (substituindo servidores antigos, atualização do sistema operativo, etc.) em que queiras remover um editor original de um grupo de disponibilidade Always On. Siga os passos nesta secção para remover o editor do grupo de disponibilidade.

Suponha que tem os servidores N1, N2 e D1, onde N1 e N2 são a réplica primária e secundária do grupo de disponibilidade AG1, N1 é o editor original de uma publicação transacional e D1 é o distribuidor. Gostaria de substituir o editor original N1 pelo novo editor N3.

Para remover o editor, siga estes passos:

  1. Instale e configure o SQL Server no nó N3. A versão do SQL Server tem de ser a mesma que a do publicador original.
  2. No servidor distribuidor D1, adicione o N3 como editor usando sp_adddistpublisher.
  3. Configura o N3 como editor, com o D1 como distribuidor.
  4. Adicionar o N3 como réplica ao grupo de disponibilidade AG1.
  5. Na réplica N3, verifique se os subscritores push da publicação aparecem como servidores ligados. Usa sp_addlinkedserver ou SQL Server Management Studio.
  6. Uma vez sincronizado o N3, passe o grupo de disponibilidade para o N3 como primário.
  7. Remova o N1 do grupo de disponibilidade AG1.

Por favor, considere o seguinte:

  • Não remova o servidor remoto do editor original (N1 neste caso) nem quaisquer metadados associados do distribuidor, mesmo que o servidor já não possa ser acedido. Os metadados do servidor do editor original são necessários no distribuidor para satisfazer as consultas de metadados de publicação e, sem eles, a replicação falhará.
  • Para o SQL Server 2014, uma vez removido o editor original, não poderá usar o nome original do editor para administrar a replicação no Replication Monitor. Se tentar registar nova(s) réplica(s) como publisher no Replication Monitor, a informação não será mostrada porque não há metadados associados. Para administrar a replicação neste cenário, terá de clicar com o botão direito em publicações individuais e subscrições no SQL Server Management Studio (SSMS).
  • Para o SQL Server 2016 SP2-CU3, o SQL Server 2017 CU6 e posterior, registe o listener do publicador do grupo de disponibilidade no Replication Monitor para administrar a replicação com o SQL Server Management Studio versão 17.7 e posterior.

Tarefas relacionadas

Conteúdo relacionado

  • Last updated on