Atualizar réplicas do grupo de disponibilidade

Aplica-se a: SQL Server

Ao atualizar uma instância do SQL Server que hospeda um AG (Grupo de Disponibilidade) do AlwaysOn para uma nova versão do SQL Server, um novo service pack ou uma atualização cumulativa do SQL Server ou ao instalar um novo service pack ou uma atualização cumulativa do Windows, você poderá reduzir o tempo de inatividade para a réplica primária para um único failover manual executando uma atualização sem interrupção (ou dois failovers manuais em caso de failback para a primária original).

Durante o processo de atualização, uma réplica secundária não estará disponível para failover ou para operações somente leitura e, depois da atualização, poderá levar algum tempo para que a réplica secundária fique atualizada com o nó da réplica primária, dependendo do volume de atividade no nó da réplica primária (portanto, espere alto tráfego de rede).

Além disso, lembre-se de que depois do failover inicial para uma réplica secundária executando uma versão mais recente do SQL Server, os bancos de dados nesse AG passarão por um processo de atualização para colocá-los na versão mais recente. Durante esse tempo, não haverá nenhuma réplica legível para nenhum desses bancos de dados. O tempo de inatividade depois do failover inicial dependerá do número de bancos de dados no AG. Se você planeja realizar o failback no primário original, essa etapa não será repetida ao realizar o failback.

Observação

Este artigo limita a discussão à atualização do próprio SQL Server. Ele não aborda a atualização do sistema operacional que contém o Cluster de Failover do Windows Server (WSFC). Não há suporte para atualização do sistema operacional do Windows que hospeda o cluster de failover para sistemas operacionais anteriores ao Windows Server 2012 R2. Para atualizar um nó de cluster em execução no Windows Server 2012 R2, confira o artigo Atualização sem interrupção do Sistema Operacional do Cluster.

Pré-requisitos

Antes de começar, examine as seguintes informações importantes:

• Versão com suporte e atualizações da edição: verifique se você pode atualizar para a versão mais recente do SQL Server com a sua versão do sistema operacional Windows e a versão do SQL Server. Por exemplo, se você atualizar diretamente de uma instância do SQL Server 2005, o nível de compatibilidade do banco de dados será atualizado.

• Escolha um método de atualização do mecanismo de banco de dados: para atualizar na ordem correta, selecione o método e as etapas de atualização apropriados com base em sua análise de atualizações de versão e de edição com suporte e também com base em outros componentes instalados em seu ambiente.

• Planejar e testar o plano de atualização do mecanismo de banco de dados: Analise as notas de versão e os problemas conhecidos da atualização, a lista de verificação pré-atualização, e desenvolva e teste o plano de atualização.

• Requisitos de hardware e software para a instalação do SQL Server: revise os requisitos de software para a instalação do SQL Server. Se for necessário um software adicional, instale-o em cada nó antes de começar o processo de atualização para minimizar qualquer tempo de inatividade.

• Verifique se a replicação ou captura de dados de alteração é usada em algum banco de dados AG: se qualquer banco de dados no AG estiver habilitado para CDC (captura de dados de alteração), conclua estas instruções.

Observação

Não há suporte para combinar versões das instâncias do SQL Server no mesmo AG fora de uma atualização sem interrupção e não deve existir nesse estado por longos períodos, já que a atualização deve ocorrer rapidamente. A outra opção para atualizar o SQL Server 2016 (13.x) e versões posteriores é usando o grupo de disponibilidade distribuído.

Observação

Não há suporte para o uso do recurso CAU (Atualização com Suporte a Cluster) do Windows para atualizar grupos de disponibilidade AlwaysOn.

Noções básicas de atualização sem interrupção para grupos de disponibilidade

Observe as diretrizes a seguir ao realizar atualizações de servidor para minimizar o tempo de inatividade e a perda de dados dos seus AGs:

• Antes de iniciar a atualização sem interrupção:

  • Execute um failover manual em, pelo menos, uma das instâncias de réplica de confirmação síncrona

  • Proteja os dados executando um backup completo em cada banco de dados de disponibilidade

  • Executar DBCC CHECKDB em cada banco de dados de disponibilidade

• Sempre execute a atualização das instâncias remotas da réplica secundária primeiro; depois, das instâncias locais da réplica secundária; por fim, da instância da réplica primária.

• Os backups não podem ocorrer em um banco de dados que está no processo de ser atualizado. Antes de atualizar as réplicas secundárias, configure a preferência de backup automatizado para executar backups apenas na réplica primária. Durante uma atualização de versão, nenhuma réplica será legível ou estará disponível para backups. Durante uma atualização sem versão, você pode configurar backups automatizados para serem executados em réplicas secundárias antes de atualizar a réplica primária.

• Durante uma atualização de versão, secundários legíveis não podem ser lidos após uma atualização do secundário legível e antes do failover de uma réplica primária para uma secundária atualizada ou a da atualização da réplica primária.

• Para proteger o AG contra failovers indesejados durante o processo de atualização, remova o failover de disponibilidade de todas as réplicas de confirmação síncrona antes de começar.

• Não atualize a instância da réplica primária antes de fazer failover do AG para a instância atualizada com uma réplica secundária primeiro. Do contrário, os aplicativos cliente poderão passar por um longo tempo de inatividade durante a atualização na instância da réplica primária.

• Sempre faça failover do AG em uma instância da réplica secundária de confirmação síncrona. Se você fizer failover para uma instância de réplica secundária de confirmação assíncrona, os bancos de dados estarão vulneráveis a perda de dados e a movimentação de dados será automaticamente suspensa até que você a retome manualmente.

• Não atualize a instância da réplica primária antes de atualizar qualquer outra instância da réplica secundária. Uma réplica primária atualizada não pode mais enviar logs para nenhuma réplica secundária cuja instância do SQL Server ainda não tenha sido atualizada para a mesma versão. Quando a movimentação dos dados para uma réplica secundária for suspensa, nenhum failover automático poderá ocorrer nessa réplica, e os bancos de dados de disponibilidade ficarão vulneráveis à perda de dados. Isso também se aplica durante uma atualização sem interrupção, em que você faz failover manual de um primário antigo para um novo. Assim, depois de atualizar o primário antigo, talvez seja necessário retomar a sincronização.

• Antes de fazer failover em um AG, verifique se o estado da sincronização do destino do failover é SYNCHRONIZED.

  Aviso

  Instalar uma nova instância ou nova versão do SQL Server em um servidor que tenha uma versão mais antiga do SQL Server instalado pode causar inadvertidamente uma interrupção para qualquer grupo de disponibilidade hospedado pela versão mais antiga do SQL Server. Isso ocorre porque durante a instalação da instância ou versão do SQL Server, o módulo de alta disponibilidade do SQL Server (RHS.EXE) é atualizado. Isso resulta em uma interrupção temporária de seus grupos de disponibilidade existentes na função primária no servidor. Portanto, é altamente recomendável que você execute uma das opções a seguir ao instalar uma versão mais recente do SQL Server para um sistema que já está hospedando uma versão mais antiga do SQL Server com um grupo de disponibilidade:

  • Instalar a nova versão do SQL Server durante uma janela de manutenção.

  • Fazer failover do grupo de disponibilidade na réplica secundária, de modo que não seja a primária durante a instalação da nova instância do SQL Server.

Processo de atualização sem interrupção

Na prática, o processo exato depende de fatores como a topologia da implantação dos AGs e o modo de confirmação de cada réplica. Mas, no cenário mais simples, a atualização sem interrupção é um processo de vários estágios que, na sua forma mais simples, envolve as seguintes etapas:

1. Remover o failover automático em todas as réplicas de confirmação síncrona
2. Atualizar todas as instâncias de réplica secundária de confirmação assíncrona.
3. Atualizar todas as instâncias de réplica secundária remota de confirmação síncrona.
4. Atualizar todas as instâncias de réplica secundária local de confirmação síncrona.
5. Fazer failover manual do AG em uma réplica secundária local de confirmação síncrona (recém-atualizadas).
6. Atualizar a instância de réplica local que hospedava anteriormente a réplica primária.
7. Configurar parceiros de failover automático conforme desejado.

Se necessário, você pode executar um failover manual extra para retornar o AG à sua configuração original.

Observação

A atualização de uma réplica de confirmação síncrona e sua colocação offline não atrasarão as transações na primária. Depois que a réplica secundária for desconectada, as transações serão confirmadas na primária sem aguardar a proteção dos logs na réplica secundária.

Se REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT for definido como 1 ou 2, a réplica primária poderá ficar indisponível para leituras/gravações quando um número correspondente de réplicas secundárias de sincronização não estiver disponível durante o processo de atualização.

Observação

Quando você executa uma atualização in-loco de uma réplica secundária para uma versão mais recente do SQL Server, o banco de dados dentro do grupo de disponibilidade permanece no estado Sincronizado/Em recuperação ou Sincronizado/Em Recuperação até que o grupo de disponibilidade faça failover manualmente, o que conclui a recuperação e atualiza o banco de dados. Uma réplica primária atualizada não pode mais enviar logs para nenhuma réplica secundária de versão inferior. A movimentação de dados é interrompida, nenhum failover automático pode ocorrer para essa réplica e os bancos de dados de disponibilidade são vulneráveis à perda de dados. Depois de atualizar o primário antigo, talvez seja necessário retomar a sincronização. É recomendável atualizar todas as réplicas secundárias antes de fazer failover para uma réplica com a nova versão. Dessa forma, você tem a opção de fazer um failover depois que os bancos de dados são atualizados para o novo formato.

AG com uma réplica secundária remota

Se você tiver implantado um AG somente para recuperação de desastre, talvez seja necessário fazer failover do AG para uma réplica secundária de confirmação assíncrona. Essa configuração é ilustrada na figura a seguir:

Nesse caso, você deve fazer failover do AG para uma réplica secundária de confirmação assíncrona durante a atualização sem interrupção. Para evitar a perda de dados, altere o modo de confirmação para confirmação síncrona e aguarde a réplica secundária ser sincronizada para que você possa fazer o failover do AG. Portanto, o processo de atualização sem interrupção possivelmente será o seguinte:

1. Atualizar a instância de réplica secundária no local remoto
2. Alterar o modo de confirmação para confirmação síncrona
3. Aguardar até que o estado da sincronização seja SYNCHRONIZED
4. Fazer failover do AG para a réplica secundária no site remoto
5. Atualizar a instância da réplica local (local primário)
6. Fazer failover do AG de volta para o local primário
7. Alterar o modo de confirmação para confirmação assíncrona

Como o modo de confirmação síncrona não é uma configuração recomendada para a sincronização de dados em um site remoto, os aplicativos cliente podem observar um aumento imediato na latência do banco de dados depois que a configuração é alterada. Além disso, a execução de um failover fará com que todas as mensagens de log não confirmadas sejam descartadas. O número de mensagens de log descartadas pode ser significante devido à alta latência da rede entre os dois locais, fazendo com que os clientes experimentem um alto volume de falha transacional. Você pode minimizar o efeito nos aplicativos cliente ao executar as seguintes ações:

• Selecione cuidadosamente uma janela de manutenção durante o baixo tráfego do cliente

• Durante a atualização do SQL Server no local primário, altere o modo de disponibilidade novamente para confirmação assíncrona e, em seguida, reverta para confirmação síncrona quando estiver pronto para fazer failover para o local primário novamente

AG com nós da instância de cluster de failover

Se um AG contiver nós de FCI (instância de cluster de failover), você deverá atualizar os nós inativos antes de atualizar os nós ativos. A figura a seguir ilustra um cenário de AG comum com FCIs para alta disponibilidade local e confirmação assíncrona entre as FCIs de recuperação de desastre remota e a sequência de upgrade.

1. Atualizar ou fazer upgrade de REMOTE2
2. Fazer failover do FCI2 para REMOTE2
3. Atualizar ou fazer upgrade de REMOTE1
4. Atualizar ou fazer upgrade de PRIMARY2
5. Fazer failover de FCI1 para PRIMARY2
6. Atualizar ou fazer upgrade de PRIMARY1

Atualizar instâncias do SQL Server com vários AGs

Se você estiver executando vários AGs com réplicas primárias em nós de servidor separados (uma configuração Ativo/Ativo), o caminho da atualização envolverá mais etapas de failover para preservar a alta disponibilidade no processo. Suponhamos que você esteja executando três AGs nos três nós de servidor, com todas as réplicas no modo de confirmação síncrona na tabela a seguir:

AG	Node1	Node2	Node3
AG1	Primária
AG2		Primária
AG3			Primária

Talvez seja apropriado na sua situação executar uma atualização sem interrupção com balanceamento de carga na sequência a seguir:

1. Fazer failover de AG2 para Node3 (para liberar Node2)
2. Atualizar ou fazer upgrade de Node2
3. Fazer failover de AG1 para Node2 (para liberar Node1)
4. Atualizar ou fazer upgrade de Node1
5. Fazer failover de AG2 e AG3 para Node1 (para liberar Node3)
6. Atualizar ou fazer upgrade de Node3
7. Fazer failover de AG3 para Node3

Essa sequência de atualização tem um tempo de inatividade médio inferior a dois failovers por AG. A configuração resultante é mostrada na tabela a seguir.

AG	Node1	Node2	Node3
AG1		Primária
AG2	Primária
AG3			Primária

Com base na sua implementação, o caminho da atualização pode variar, bem como o tempo de inatividade experimentado pelos aplicativos cliente.

Observação

Em muitos casos, após a atualização sem interrupção, você executará o failback para a réplica primária original.

Atualização sem interrupção de um grupo de disponibilidade distribuído

Para executar uma atualização sem interrupção de um grupo de disponibilidade distribuído, atualize primeiro todas as réplicas secundárias. Em seguida, faça failover do encaminhador e atualize a última instância restante do segundo grupo de disponibilidade. Depois que todas as réplicas tiverem sido atualizadas, faça failover do primário global e atualize a última instância restante do primeiro grupo de disponibilidade. É fornecido abaixo um diagrama detalhado com etapas.

Com base na sua implementação, o caminho da atualização pode variar, bem como o tempo de inatividade experimentado pelos aplicativos cliente.

Observação

Em muitos casos, após a atualização sem interrupção, você executará o failback para as réplicas primárias originais.

Etapas gerais para atualizar um grupo de disponibilidade distribuído

1. Faça backup de todos os bancos de dados, incluindo os bancos de dados do sistema e os que participam do grupo de disponibilidade.
2. Atualize e reinicie todas as réplicas secundárias do segundo grupo de disponibilidade (o downstream).
3. Atualize e reinicie todas as réplicas secundárias do primeiro grupo de disponibilidade (o upstream).
4. Faça failover do encaminhador primário para uma réplica secundária atualizada do grupo de disponibilidade secundário.
5. Aguarde a sincronização de dados. Os bancos de dados devem ser mostrados como sincronizados em todas as réplicas de confirmação síncrona, e o primário global deve ser sincronizado com o encaminhador.
6. Atualize e reinicie a última instância restante do grupo de disponibilidade secundário.
7. Faça failover do primário global para um secundário atualizado do primeiro grupo de disponibilidade.
8. Atualize a última instância restante do grupo de disponibilidade primário.
9. Reinicie o servidor recém-atualizado.
10. (opcional) Execute failback de ambos os grupos de disponibilidade para suas réplicas primárias originais.

Importante

Verifique a sincronização entre cada etapa. Antes de passar para a próxima etapa, confirme que suas réplicas de confirmação síncrona estão sincronizadas dentro do grupo de disponibilidade e que seu primário global está sincronizado com o encaminhador no grupo de disponibilidade distribuído.

Recomendação: Sempre que você verificar a sincronização, atualize o nó do banco de dados e o nó do grupo de disponibilidade distribuído no SQL Server Management Studio. Depois de tudo for sincronizado, salve uma captura de tela dos estados de cada réplica. Isso ajudará você a manter o controle de qual etapa você está, a fornecer provas de que tudo estava funcionando corretamente antes da próxima etapa e a auxiliar na solução de problemas se algo der errado.

Diagrama de exemplo de uma atualização sem interrupção de um grupo de disponibilidade distribuído

grupo de disponibilidade	Réplica primária	Réplica secundária
AG1	NODE1\SQLAG	NODE2\SQLAG
AG2	NODE3\SQLAG	NODE4\SQLAG
DistributedAG	AG1 (global)	AG2 (encaminhador)

As etapas para atualizar as instâncias neste diagrama:

1. Faça backup de todos os bancos de dados, incluindo os bancos de dados do sistema e os que participam do grupo de disponibilidade.
2. Atualize NODE4\SQLAG (secundário do AG2) e reinicie o servidor.
3. Atualize NODE2\SQLAG (secundário do AG1) e reinicie o servidor.
4. Fazer failover de AG2 de NODE3\SQLAG para NODE4\SQLAG.
5. Atualize o NODE3\SQLAG e reinicie o servidor.
6. Fazer failover de AG1 de NODE1\SQLAG para NODE2\SQLAG.
7. Atualize o NODE1\SQLAG e reinicie o servidor.
8. (opcional) Execute failback para as réplicas primárias originais.
   1. Fazer failover de AG2 de NODE4\SQLAG de volta para NODE3\SQLAG.
   2. Fazer failover de AG1 de NODE2\SQLAG de volta para NODE1\SQLAG.

Se uma terceira réplica existisse em cada grupo de disponibilidade, ela seria atualizada antes de NODE3\SQLAG e NODE1\SQLAG.

Importante

Verifique a sincronização entre cada etapa. Antes de passar para a próxima etapa, confirme que suas réplicas de confirmação síncrona estão sincronizadas dentro do grupo de disponibilidade e que seu primário global está sincronizado com o encaminhador no grupo de disponibilidade distribuído.

Recomendação: sempre que você verificar a sincronização, atualize o nó do banco de dados e o nó do grupo de disponibilidade distribuído no SQL Server Management Studio. Após tudo ser sincronizado, tire uma captura de tela e salve-a. Isso ajudará você a manter o controle de qual etapa você está, a fornecer provas de que tudo estava funcionando corretamente antes da próxima etapa e a auxiliar na solução de problemas se algo der errado.

Etapas especiais para replicação ou captura de dados de alteração

Dependendo da atualização aplicada, outras etapas podem ser necessárias para bancos de dados de réplica de AG que são habilitados para a replicação ou captura de dados de alteração. Consulte as notas de versão da atualização para determinar se as etapas a seguir são necessárias:

1. Atualize todas as réplicas secundárias.

2. Depois de atualizar todas as réplicas secundárias, faça o failover no AG para a instância atualizada.

3. Execute o seguinte Transact-SQL na instância que hospeda a réplica primária:

   EXECUTE [master].[sys].[sp_vupgrade_replication];
   

   Observação

   Este comando pode levar vários minutos para ser executado. Ignore esta etapa se estiver no SQL Server 2019 CU1 ou posterior. Para saber mais, confira KB4530283

4. Atualize a instância que foi originalmente a réplica primária.

Para obter mais informações, consulte Funcionalidade de CDC pode falhar após a atualização para a atualização cumulativa mais recente.

Confira também

• Fazer upgrade do SQL Server usando o Assistente de Instalação (Instalação)
• Instalar o SQL Server do prompt de comando