Atualizar ou corrigir 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
Certifique-se de aderir às regras relativas às versões suportadas em uma topologia:
Um Distribuidor pode ser qualquer versão, desde que seja maior ou igual à versão do Publisher (em muitos casos, o Distribuidor é a mesma instância que o Editor).
Um Publicador pode ser qualquer versão, desde que seja menor ou igual à versão do Distribuidor.
O Editor e o Distribuidor devem ser o mesmo produto. Ambos são SQL Server ou ambos são Instância Gerenciada SQL do Azure.
A versão para assinante depende do tipo de publicação:
Um assinante de uma publicação transacional pode ser qualquer versão dentro de duas versões da versão do Publisher. Por exemplo: um Publicador do SQL Server 2012 (11.x) pode ter Assinantes do SQL Server 2014 (12.x) e do SQL Server 2016 (13.x); e um Publicador do SQL Server 2016 (13.x) pode ter Assinantes do SQL Server 2014 (12.x) e do SQL Server 2012 (11.x).
Um assinante de uma publicação de mesclagem pode ser de qualquer versão igual ou inferior à versão do Publisher, conforme suportado de acordo com o ciclo de suporte 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: implante um ambiente paralelo e mova bancos de dados junto com os objetos de nível de instância associados, como logins, trabalhos, etc. para o novo ambiente.
Atualização no local: permitir ao suporte de instalação do SQL Server atualizar a instalação existente do SQL Server substituindo os componentes do SQL Server e atualizando os objetos da base de dados. Para ambientes que executam grupos de disponibilidade (AGs) ou instâncias de cluster de failover (FCIs), uma atualização no local é combinada com uma atualização gradual para minimizar o tempo de inatividade.
Uma abordagem comum para atualizações de topologias de replicação paralelas é transferir gradualmente pares editor-assinante para o novo ambiente, em vez de mover toda a topologia de uma só vez. 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 no local também deve ser usado ao aplicar patches no SQL Server com um service pack ou atualização cumulativa.
Comentários
O upgrade de uma topologia de replicação é um processo de várias etapas. Recomendamos tentar atualizar 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 qualquer documentação operacional necessária para lidar com a atualização sem problemas, sem incorrer em longos e caros períodos de inatividade durante o processo de atualização real. Você pode reduzir significativamente o tempo de inatividade utilizando AGs e/ou FCIs nos ambientes de produção enquanto atualiza a topologia de replicação destes ambientes. 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 tiveres um banco de dados de distribuição num caso de cluster de failover, certifica-te de que todos os nós participantes usem a mesma versão. Não recomendamos uma instalaçã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, é adicionado suporte para o uso de 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 seu banco de dados de distribuição estiver numa instância de cluster de failover e estiver a realizar uma migração faseada (e não puder atualizar todos os nós para a mesma versão do SQL Server), durante o curto período de migração, recomendamos que execute tarefas como adicionar um novo assinante, assinatura, editor ou publicação no nó que tem a versão mais recente do SQL Server.
Matriz de replicação
Matriz de compatibilidade de replicação transacional e de snapshot
| Editora | Distribuidor | Assinante |
|---|---|---|
| Instância Gerenciada SQL do AzureAUTD | Instância Gerenciada SQL do AzureAUTD | Banco de Dados SQL do Azure Instância Gerenciada SQL do AzureAUTD Instância Gerenciada SQL do Azure2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) |
| Instância Gerenciada SQL do Azure2022 | Instância Gerenciada SQL do AzureAUTD Instância Gerenciada SQL do Azure2022 |
Banco de Dados SQL do Azure Instância Gerenciada SQL do AzureAUTD Instância Gerenciada 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 SQL do AzureAUTD Instância Gerenciada 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 SQL do AzureAUTD Instância Gerenciada 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 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) | 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 SQL do Azure configurada com a política de atualização do SQL Server 2022 .
Aplica-se à Instância Gerenciada SQL do Azure configurada com a política de atualização Always-up-to-date.
Mesclar matriz de compatibilidade de replicação
| Editora | 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
Execute o Log Reader Agent para replicação transacional antes da atualização
Antes de atualizar o SQL Server, você deve certificar-se de que 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á em execução para o banco de dados. Por defeito, o agente funciona continuamente.
Pare a atividade do usuário em tabelas publicadas.
Dê tempo para o Log Reader Agent copiar transações para o banco de dados de distribuição e, em seguida, pare o agente.
Execute sp_replcmds para verificar se todas as transações são processadas. O conjunto de resultados deste procedimento deve estar vazio.
Execute sp_replflush para fechar a conexão a partir de
sp_replcmdsExecute a atualização do servidor para a versão mais recente do SQL Server.
Reinicie o SQL Server Agent e o Log Reader Agent se eles não iniciarem automaticamente após a atualização.
Executar agentes para replicação de mesclagem após a atualização
Após a atualização, execute o Snapshot Agent para cada publicação de mesclagem e o Merge Agent para cada assinatura para atualizar os metadados de replicação. Não é necessário aplicar o novo instantâneo, pois não é necessário reiniciar assinaturas. Os metadados da assinatura são atualizados na 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 Publisher.
A replicação por mesclagem armazena metadados de publicação e subscrição em várias tabelas do sistema nos bancos de dados de publicação e subscrição. A execução do Snapshot Agent atualiza os metadados da publicação e a execução do Merge Agent atualiza os metadados da assinatura. Só é necessário gerar um instantâneo de publicação. Se uma publicação de mesclagem usa filtros parametrizados, cada partição também tem um instantâneo. Não é necessário atualizar esses instantâneos particionados.
Execute os agentes do SQL Server Management Studio, do Replication Monitor ou da linha de comando. Para obter mais informações sobre como executar o Snapshot Agent, consulte os seguintes artigos:
- Criar e Aplicar o Snapshot Inicial
- Iniciar e parar um agente de replicação (SQL Server Management Studio)
- Criar e Aplicar o Snapshot Inicial
- Conceitos de Executáveis do Agente de Replicação
Para obter mais informações sobre como executar o Merge Agent, consulte os seguintes artigos:
Depois de atualizar o SQL Server em uma topologia que usa replicação de mesclagem, altere o nível de compatibilidade de publicação de quaisquer publicações se quiser 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
Estas etapas descrevem a ordem na qual os servidores em uma topologia de replicação devem ser atualizados. As mesmas etapas se aplicam se você estiver executando replicação transacional ou de mesclagem. No entanto, essas etapas não abrangem replicação ponto a ponto, assinaturas de atualização em fila nem assinaturas de atualização imediata.
Atualização in-situ
- Atualize o Distribuidor.
- Atualize o Editor e o Assinante. Estes 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 alinhar com a 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 editor nem um 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 Paralela
- Atualize o Distribuidor.
- Reconfigure a configuração de distribuição na nova instância do SQL Server.
- Atualize o Editor.
- Atualizar o/a assinante.
- Reconfigure todos os pares de Publisher-Subscriber, incluindo a reinicialização do Assinante.
Etapas para migração lado a lado do Distribuidor para o Windows Server
Uma atualização 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 em uma FCI (Instância de Cluster de Failover).
Configure uma nova instância do SQL Server (autônoma ou FCI), edição e versão como seu distribuidor no Windows Server com um cluster do Windows diferente e um nome FCI do SQL Server ou nome de host autônomo. Você precisa manter a estrutura de diretórios igual à do distribuidor antigo para garantir que os executáveis dos agentes de replicação, as pastas de replicação e os caminhos de arquivos de banco de dados sejam encontrados no mesmo caminho no novo ambiente. Isso reduz todas as etapas de pós-migração/atualização necessárias.
Verifique se a 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 esta for uma instância autônoma, desligue o servidor. Se esta for uma FCI do SQL Server, coloque toda a função do SQL Server offline no gerenciador de clusters, incluindo o nome da rede.
Remova as entradas de objeto de computador DNS e Ative Directory para o ambiente antigo (instância de distribuidor atual).
Altere o nome do host do novo servidor para corresponder ao do servidor antigo.
- Se esta for uma FCI do SQL Server, renomeie a nova FCI do SQL Server com o mesmo nome de servidor virtual da instância antiga.
Copie os arquivos de banco de dados da instância anterior usando o redirecionamento de SAN, a cópia de armazenamento ou a 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 o 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 execute a migração lado a lado do distribuidor como uma atividade e a atualização no local para o SQL Server como outra atividade. Isso permite que você adote uma abordagem em fases, reduza o risco e minimize o tempo de inatividade.
Sincronização web para replicação de fusão
A opção de sincronização da Web para replicação de mesclagem requer que se copie o SQL Server Replication Listener (replisapi.dll) para o diretório virtual no servidor do 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á copiá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, consulte Configurar a sincronização da Web.
Restaurar um banco de dados replicado de uma versão anterior
Para garantir que as configurações de replicação sejam mantidas ao restaurar um backup de um banco de dados replicado de uma versão anterior: restaure para um servidor e banco de dados com os mesmos nomes do servidor e do banco de dados no qual o backup foi feito.
Conteúdo relacionado
- de replicação do SQL Server
- Perguntas frequentes sobre administração de replicação
- Compatibilidade retroativa da replicação
- Atualizações de versão e edição com suporte (SQL Server 2022)
- Atualizar SQL Server
- Atualizando uma topologia de replicação para o SQL Server 2016