Atualizar ou aplicar patches a bancos de dados replicados
Aplica-se a:
SQL Server - somente Windows
O SQL Server dá suporte à atualização de bancos de dados replicados de versões anteriores do SQL Server; não é necessário interromper a atividade em outros nós enquanto um nó está sendo atualizado.
Pré-requisitos
Verifique se você está em conformidade com as regras que dizem respeito às versões suportadas em uma topologia:
Um Distribuidor pode ser qualquer versão, desde que seja maior ou igual à versão do Publicador (em muitos casos, o Distribuidor é 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 do 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 ter todas as versões iguais ou inferiores à versão do Editor, de acordo com o suporte do ciclo de vida das versões.
Caminhos de atualização
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 AGs (grupos de disponibilidade) ou FCIs (instâncias de cluster de failover), uma atualização in-loco é combinada com uma atualização contínua para minimizar o tempo de inatividade.
Uma abordagem comum para atualizações lado a lado de topologias de replicação é mover pares editor-assinante em partes para o novo ambiente lado a lado, em vez de mover toda a topologia. Essa abordagem em fases ajuda a controlar o tempo de inatividade e minimiza o impacto até certo ponto para os negócios dependentes da replicação.
A maioria deste artigo tem como escopo 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.
Comentários
A atualização de uma topologia de replicação é um processo de várias etapas. Recomendamos tentar uma atualização de uma réplica de sua topologia de replicação em um ambiente de teste antes de executar a atualização no ambiente de produção real. Isso ajuda a eliminar quaisquer problemas em documentação operacional necessária para lidar com a atualização de maneira suave, sem incorrer em tempos de inatividade caros e longos durante o processo de atualização. Você pode reduzir significativamente o tempo de inatividade com o uso de AGs e/ou FCIs para os ambientes de produção ao fazer upgrade da topologia de replicação. Além disso, recomendamos fazer backups de todos os bancos de dados, incluindo msdb, master, bancos de dados de distribuição e os bancos de dados de usuário que participam da replicação antes de tentar a atualização.
Quando você tiver um banco de dados de distribuição em uma instância de cluster de failover, verifique se todos os nós participantes usam a mesma compilação. Não recomendamos uma configuração na qual um nó é uma versão do SQL Server anterior ao SQL Server 2016 (13.x) SP2-CU3 ou SQL Server 2017 (14.x) CU6 e o outro nó é uma versão do SQL Server posterior ao SQL Server 2016 (13.x) SP2-CU3 ou SQL Server 2017 (14.x) CU6. A partir do SQL Server 2016 (13.x) SP2-CU3 e do SQL Server 2017 (14.x) CU6, o suporte é adicionado para usar um banco de dados de distribuição em um AG e para novos objetos (tabelas, procedimentos armazenados) em bancos de dados de distribuição. Se o banco de dados de distribuição estiver em uma instância de cluster de failover e você estiver fazendo uma migração em fases (e não puder atualizar todos os nós para a mesma versão do SQL Server), para o período de migração curto, recomendamos que você faça tarefas de conta como adicionar um novo assinante, assinatura, publicador ou publicação ao nó que tem a versão mais recente do SQL Server.
Matriz de replicação
Matriz de compatibilidade de replicação de instantâneo e transacional
| Publicador | Distribuidor | Assinante |
|---|---|---|
| Instância Gerenciada de SQL do AzureAUTD | Instância Gerenciada de SQL do AzureAUTD | Banco de Dados SQL do Azure Instância Gerenciada de SQL do AzureAUTD Instância Gerenciada de SQL do Azure2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) |
| Instância Gerenciada de SQL do Azure2022 | Instância Gerenciada de SQL do AzureAUTD Instância Gerenciada de SQL do Azure2022 |
Banco de Dados SQL do Azure Instância Gerenciada de SQL do AzureAUTD Instância Gerenciada de SQL do Azure2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) |
| SQL Server 2022 (16.x) | SQL Server 2022 (16.x) | Banco de Dados SQL do Azure Instância Gerenciada de SQL do AzureAUTD Instância Gerenciada de SQL do Azure2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) |
| SQL Server 2019 (15.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) |
Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure AUTD Instância Gerenciada de SQL do Azure2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) |
| SQL Server 2017 (14.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) |
Instância Gerenciada de SQL do Azure2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) |
| SQL Server 2016 (13.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) |
SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) |
| SQL Server 2014 (12.x) | Instância Gerenciada de SQL do AzureAUTD Instância Gerenciada de SQL do Azure2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) |
SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2012 (11.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) |
SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
2022 aplica-se à Instância Gerenciada de SQL do Azure configurada com a política de atualização SQL Server 2022. AUTD Aplica-se à Instância Gerenciada de SQL do Azure configurada com a política de atualização Sempre atualizado.
Matriz de compatibilidade de replicação de mesclagem
| Publicador | Distribuidor | Assinante |
|---|---|---|
| SQL Server 2022 (16.x) | SQL Server 2022 (16.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2019 (15.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) |
SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2017 (14.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) |
SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2016 (13.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) |
SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2014 (12.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) |
SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2012 (11.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) |
SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
Considerações sobre a atualização
Executar o Agente de Leitor de Log para replicação transacional antes da atualização
Antes de atualizar o SQL Server, você deve verificar se todas as transações confirmadas de tabelas publicadas foram processadas pelo Log Reader Agent. Para garantir que todas as transações sejam processadas, execute as seguintes etapas para cada banco de dados que contém publicações transacionais:
Verifique se o Log Reader Agent está executando para o banco de dados. Por padrão, o agente é executado continuamente.
Interrompa a atividade de usuário em tabelas publicadas.
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.
Execute sp_replcmds para verificar se todas as transações são processadas. O conjunto de resultados deste procedimento deve ser vazio.
Execute sp_replflush para fechar a conexão com
sp_replcmdsExecute a atualização do servidor para a última versão do SQL Server.
Reinicie o SQL Server Agent e o Log Reader Agent se eles não forem iniciados automaticamente após a atualização.
Executar agentes para a 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, porque não é necessário reinicializar as 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 assinatura em diversas tabelas do sistema nos bancos de dados de publicação e 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 da 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 os 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:
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.
Atualizar para as edições Standard, Workgroup ou Express
Antes de atualizar de uma edição do SQL Server para outra, verifique se a funcionalidade que você está usando atualmente tem suporte na edição para a qual você está atualizando. 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, as assinaturas de atualização enfileiradas nem as assinaturas de atualização imediata.
Atualização in-loco
- Atualize o distribuidor.
- Atualize o publicador e o assinante. Eles podem ser atualizados em qualquer ordem.
Observação
Para o SQL Server 2008 (10.0.x) e o SQL Server 2008 R2 (10.50.x), a atualização do editor e do assinante deve ser feita ao mesmo tempo para se alinhar à matriz de topologia de replicação. Os editores ou assinantes do SQL Server 2008 (10.0.x) e do SQL Server 2008 R2 (10.50.x) não podem ter um publicador ou assinante do SQL Server 2016 (13.x) (ou superior). Se a atualização ao mesmo tempo não for possível, use uma atualização intermediária para atualizar as instâncias do SQL Server para o SQL Server 2014 (12.x) e atualize-as novamente para o SQL Server 2016 (13.x) (ou superior).
Atualização lado a lado
- Atualize o distribuidor.
- Defina novamente a opção Configurar distribuição na nova instância do SQL Server.
- Atualize o publicador.
- Atualize o assinante.
- 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
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 em uma instância autônoma do SQL Server ou uma em uma FCI (Instância de Cluster de Failover).
Configure uma nova instância do SQL Server (autônoma ou FCI), uma edição e uma versão como distribuidor no Windows Server com um cluster diferente do Windows e um nome FCI do SQL Server ou um nome de host autônomo. Você precisa manter a estrutura do diretório igual ao distribuidor antigo para garantir que os executáveis dos agentes de replicação, as pastas de replicação e os caminhos de arquivo de banco de dados sejam encontrados no mesmo caminho no novo ambiente. Isso reduz as etapas pós-migração/atualização necessárias.
Certifique-se de que sua replicação está sincronizada e, em seguida, desligue todos os agentes de replicação.
Desligue a instância atual do Distribuidor do SQL Server. Se for uma instância autônoma, desligue o servidor. Se essa for uma FCI do SQL Server, leve toda a função do SQL Server offline no gerenciador de cluster, incluindo o nome da rede.
Remova as entradas de objeto de computador do DNS e do Active Directory para o ambiente antigo (instância atual do distribuidor).
Altere o nome do host do novo servidor para coincidir com o do servidor antigo.
- Se essa for uma FCI do SQL Server, renomeie a nova FCI do SQL Server com o mesmo nome do servidor virtual que a instância antiga.
Copie os arquivos de banco de dados da instância anterior usando o redirecionamento SAN, cópia de armazenamento ou cópia de arquivo.
Coloque a nova instância do SQL Server online.
Reinicie todos os agentes de replicação e verifique se eles estão sendo executados com êxito.
Valide se a replicação está funcionando conforme esperado.
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.
Observação
Para reduzir o tempo de inatividade, recomendamos que você execute a migração lado a lado do distribuidor como uma atividade e a atualização in-loco para o SQL Server como outra. Isso permite que você use uma abordagem em fases, reduza o risco e minimize o tempo de inatividade.
Sincronização da Web para replicação de mesclagem
A opção de sincronização da Web para a replicação de mesclagem requer que você copie o ouvinte da Replicação do SQL Server (replisapi.dll) para o diretório virtual no servidor de IIS (Serviços de Informações da Internet) usado para sincronização. Quando você configura a sincronização da Web, o Assistente para Configurar Sincronização da Web copia o arquivo para o diretório virtual. 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.
Restaurar 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.