Atualizar ou aplicar patches a bancos de dados replicados

Aplica-se a: SQL Server - somente Windows

O SQL Server suporta a atualização de bancos de dados replicados de versões anteriores do SQL Server; não é necessário interromper a atividade de outros nós durante a atualização de um nó. Verifique se você está em conformidade com as regras que dizem respeito às versões suportadas em uma topologia:

• Um Distribuidor pode ser de qualquer versão, desde que ela seja maior ou igual à do Publicador (em muitos casos, o Distribuidor tem a mesma instância que o Publicador).
• Um Publicador pode ser de qualquer versão, contanto que ela seja menor ou igual à versão do Distribuidor.
• A versão de assinante depende do tipo de publicação:
  • Um Assinante de uma publicação transacional pode ser de qualquer uma das duas versões do Publicador. Por exemplo: um publicador do SQL Server 2012 (11.x) pode ter assinantes do SQL Server 2014 (12.x) e SQL Server 2016 (13.x); e um publicador do SQL Server 2016 (13.x) pode ter assinantes do SQL Server 2014 (12.x) e SQL Server 2012 (11.x).
  • Um assinante de uma publicação de mesclagem pode ser todas as versões iguais ou anteriores à versão do publicador com suporte, de acordo com o ciclo de vida de suporte das versões.

O caminho de atualização para o SQL Server é diferente dependendo do padrão de implantação. O SQL Server oferece dois caminhos de atualização em geral:

• Lado a lado: Implantar um ambiente paralelo e mover bancos de dados juntamente com os objetos de nível de instância associada, como logons, trabalhos, etc. para o novo ambiente.
• Atualização in-loco: permitir que a mídia de instalação do SQL Server atualize a instalação do SQL Server existente, substituindo os bits do SQL Server e atualizando os objetos de banco de dados. Para ambientes que executam Grupos de Disponibilidade AlwaysOn ou Instâncias do Cluster de Failover, uma atualização in-loco é combinada com uma atualização sem interrupção para minimizar o tempo de inatividade.

Uma abordagem comum que tem sido adotada para atualizações lado a lado de topologias de replicação é mover os pares publicador-assinante em partes para o novo ambiente lado a lado em vez de uma movimentação de toda a topologia. Essa abordagem em fases ajuda a controlar o tempo de inatividade e a minimizar o impacto a uma determinada medida para o negócio dependente de replicação.

A maior parte deste artigo está no escopo para atualizar a versão do SQL Server. No entanto, o processo de atualização in-loco também deve ser usado ao aplicar um patch ao SQL Server com um service pack ou atualização cumulativa também.

Matriz de replicação

Matriz de compatibilidade de replicação de instantâneo e transacional

Matriz de compatibilidade de replicação de mesclagem

Executar o Log Reader Agent para replicação transacional antes da atualização

Antes de fazer upgrade para o SQL Server, você deve verificar se todas as transações confirmadas das tabelas publicadas foram processadas pelo Agente de Leitor de Log. Para isso, execute as seguintes etapas para cada banco de dados que contém publicações transacionais:

1. Verifique se o Log Reader Agent está executando para o banco de dados. Por padrão, o agente é executado continuamente.
2. Interrompa a atividade de usuário em tabelas publicadas.
3. Conceda um tempo para que o Log Reader Agent copie transações para o banco de dados de distribuição e, depois, interrompa o agente.
4. Execute sp_replcmds para verificar se todas as transações foram processadas. O conjunto de resultados deste procedimento deve ser vazio.
5. Execute sp_replflush para fechar a conexão de sp_replcmds.
6. Execute a atualização do servidor para a última versão do SQL Server.
7. Reinicie o SQL Server Agent e o Log Reader Agent se eles não iniciarem automaticamente depois da atualização.

Executar agentes para replicação de mesclagem após a atualização

Depois da atualização, execute o Snapshot Agent para cada publicação de mesclagem e o Merge Agent para cada assinatura a fim de atualizar os metadados de replicação. Você não precisa aplicar o novo instantâneo, pois não é necessário reinicializar assinaturas. Metadados de assinatura são atualizados a primeira vez que o Merge Agent é executado após a atualização. Isso significa que o banco de dados de assinatura pode permanecer online e ativo durante a atualização do Publicador.

A replicação de mesclagem armazena metadados de publicação e de assinatura em várias tabelas do sistema nos bancos de dados de publicação e de assinatura. Executar o Snapshot Agent atualiza os metadados de publicação, e executar o Merge Agent atualiza os metadados de assinatura. Só é necessário gerar um instantâneo de publicação. Se uma publicação de mesclagem usar filtros com parâmetros, cada partição também terá um instantâneo. Não é necessário atualizar esses instantâneos particionados.

Execute os agentes do SQL Server Management Studio, Replication Monitor ou da linha de comando. Para obter mais informações sobre como executar o Agente de Instantâneo, consulte os seguintes artigos:

• Criar e aplicar o instantâneo inicial
• Iniciar e interromper um Agente de Replicação (SQL Server Management Studio)
• Criar e aplicar o instantâneo inicial
• Conceitos dos executáveis do Replication Agent

Para obter mais informações sobre como executar o Agente de Mesclagem, consulte os seguintes artigos:

• Sincronizar uma assinatura pull
• Sincronizar uma assinatura push

Depois de atualizar o SQL Server em uma topologia que utiliza a replicação de mesclagem, altere o nível de compatibilidade de publicação de qualquer publicação caso queira usar novos recursos.

Atualizando as edições Standard, Workgroup ou Express

Antes de fazer upgrade de uma edição do SQL Server para outra, verifique se há suporte para a funcionalidade atualmente utilizada na edição para a qual deseja fazer upgrade. Para obter mais informações, consulte a seção sobre Replicação em Edições e recursos com suporte do SQL Server 2022.

Etapas para atualizar uma topologia de replicação

Essas etapas descrevem a ordem na qual os servidores em uma topologia de replicação devem ser atualizados. As mesmas etapas serão aplicáveis se você estiver executando uma replicação transacional ou de mesclagem. No entanto, essas etapas não abrangem a replicação Ponto a Ponto, assinaturas de atualização enfileiradas nem assinaturas de atualização imediatas.

Atualização in-loco

1. Atualize o distribuidor.
2. Atualize o publicador e o assinante. Eles podem ser atualizados em qualquer ordem.

Atualização lado a lado

1. Atualize o distribuidor.
2. Reconfigure a distribuição na nova instância do SQL Server.
3. Atualize o publicador.
4. Atualize o assinante.
5. Reconfigure todos os pares publicador-assinante, incluindo a reinicialização do assinante.

Etapas para a migração lado a lado do distribuidor para o Windows Server 2012 R2

Se estiver planejando atualizar a instância do SQL Server para o SQL Server 2016 (ou superior) e seu sistema operacional atual for o Windows 2008 (ou 2008 R2), será necessário realizar uma atualização lado a lado do sistema operacional para o Windows Server R2 ou superior. O motivo dessa atualização intermediária do sistema operacional é que o SQL Server 2016 não pode ser instalado em um Windows Server 2008/2008 R2 e o Windows Server 2008/20008 R2 não permite atualizações in-loco diretamente para Windows Server 2016. Embora seja possível executar uma atualização in-loco do Windows Server 2008/2008 R2 para o Windows Server 2012 e, em seguida, para o Windows Server 2016, isso geralmente não é recomendado devido ao tempo de inatividade e à complexidade adicional, impedindo um caminho de reversão fácil. Um upgrade lado a lado é o único caminho de atualização disponível para instâncias do SQL Server que participam de um cluster de failover. As etapas a seguir podem ser executadas de uma instância autônoma do SQL Server ou em uma dentro de uma FCI (Instância do Cluster de Failover) Always On.

1. Configure uma nova instância do SQL Server (autônoma ou Cluster de Failover Always On), uma edição e uma versão como seu distribuidor no Windows Server 2012 R2/2016 com um cluster do Windows diferente um nome do FCI do SQL Server ou nome do host autônomo. Será necessário manter a mesma estrutura de diretório que a do distribuidor antigo para garantir que os executáveis dos agentes de replicação, pastas de replicação e caminhos do arquivo de banco de dados sejam encontrados no mesmo caminho no novo ambiente. Isso reduzirá quaisquer etapas de pós-migração/atualização necessárias.
2. Certifique-se de que sua replicação está sincronizada e, em seguida, desligue todos os agentes de replicação.
3. Desligue a instância atual do Distribuidor do SQL Server. Se for uma instância autônoma, desligue o servidor. Se for um FCI do SQL, coloque toda a função do SQL Server offline no gerenciador de cluster, incluindo o nome da rede.
4. Remova a DNS e as entradas do objeto de computador do AD do ambiente antigo (instância de distribuidor atual).
5. Altere o nome do host do novo servidor para coincidir com o do servidor antigo.
   1. Se for um FCI do SQL, renomeie o novo FCI do SQL com o mesmo nome do servidor virtual que o da instância antiga.
6. Copie os arquivos de banco de dados da instância anterior usando o redirecionamento SAN, cópia de armazenamento ou cópia de arquivo.
7. Coloque a nova instância do SQL Server online.
8. Reinicie todos os agentes de replicação e verifique se eles estão sendo executados com êxito.
9. Valide se a replicação está funcionando conforme esperado.
10. Use a mídia de instalação do SQL Server para executar uma atualização in-loco de sua instância do SQL Server para a nova versão do SQL Server.

Sincronização da Web para replicação de mesclagem.

A opção de sincronização da Web para replicação de mesclagem requer que o SQL Server Replication Listener (replisapi.dll) seja copiado para o diretório virtual do servidor IIS (Serviços de Informações da Internet) usado para sincronização. Quando você configura a sincronização da Web, o arquivo é copiado para o diretório virtual pelo Assistente para Configuração da Sincronização da Web. Se você atualizar os componentes do SQL Server instalados no servidor IIS, deverá copiar replisapi.dll manualmente do diretório COM para o diretório virtual no servidor IIS. Para obter mais informações sobre como configurar a sincronização da Web, veja Configurar sincronização da Web.

Restaurando um banco de dados replicado de uma versão anterior

Para assegurar que as configurações de replicação sejam mantidas na restauração do backup de um banco de dados replicado de uma versão anterior, restaure para um servidor e um banco de dados que tenham os mesmos nomes que o servidor e o banco de dados dos quais foi obtido o backup.

Consulte Também

Replicação do SQL Server
Perguntas Frequentes sobre Administração de Replicação
Compatibilidade com versões anteriores de replicação
Atualizações de versão e edição com suporte
Atualizar o SQL Server
Atualizando uma topologia de replicação para o SQL Server 2016