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, após a atualização, pode levar algum tempo para que a réplica secundária acompanhe o nó da réplica primária, dependendo do volume de atividade no nó de réplica primária (portanto, espere um 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 após o failover inicial depende 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.

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.

• Planeje e teste o plano de atualização do mecanismo de banco de dados: examine as notas de versão e os problemas de atualização conhecidos, a lista de verificação de pré-graduaçã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.

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 de prática em pelo menos uma das instâncias de réplica de confirmação síncrona.

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

  • Execute DBCC CHECKDB em todos os bancos 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 de não reversã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. Caso contrário, os aplicativos cliente poderão sofrer tempo de inatividade estendido durante a atualização na instância de 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 manualmente de um primário antigo para um novo primário. 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 instalada 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ê faça um dos seguintes procedimentos ao instalar uma versão mais recente do SQL Server em um sistema que já hospeda 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.

  • Faça failover do grupo de disponibilidade para a réplica secundária para que ela não seja 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. Porém, no cenário mais simples, uma atualização sem interrupção é um processo de várias fases que, em 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.

Atualizar uma réplica de confirmação síncrona e tirá-la offline não atrasará as transações no primário. 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 estiver definido como ou 12, a réplica primária poderá estar indisponível para leitura/gravação quando um número correspondente de réplicas secundárias de sincronização não estiver disponível durante o processo de atualizaçã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 e paradas de movimentação de dados, nenhum failover automático pode ocorrer para essa réplica e seus bancos de dados de disponibilidade estão vulneráveis à perda de dados. Depois de atualizar o primário antigo, talvez seja necessário retomar a sincronização. Recomendamos 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ê implantou um AG apenas para recuperação de desastre, talvez seja necessário fazer failover do AG para uma réplica secundária de confirmação assíncrona. A figura a seguir ilustra essa configuração:

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 sincronização da réplica secundária antes de fazer failover do AG. Portanto, o processo de atualização sem interrupção pode ter a seguinte aparência:

1. Atualize a instância de réplica secundária no site remoto.
2. Altere o modo de confirmação para confirmação síncrona.
3. Aguarde até que o estado de sincronização seja SYNCHRONIZED.
4. Faça failover do AG para a réplica secundária no site remoto.
5. Atualize ou atualize a instância de réplica local (site primário).
6. Faça failover do AG de volta para o site primário.
7. Altere 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 sincronização de dados com um site remoto, os aplicativos cliente podem notar um aumento imediato na latência do banco de dados após a alteração da configuração. 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 significativo devido à alta latência de rede entre os dois sites, 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.

• Ao atualizar ou atualizar o SQL Server no site primário, altere o modo de disponibilidade de volta para confirmação assíncrona e, em seguida, reverta para confirmação síncrona quando estiver pronto para fazer failover para o site 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 Ativa/Ativa), o caminho de atualização envolverá mais etapas de failover para preservar a alta disponibilidade no processo. Suponha que você esteja executando três AGs em três nós de servidor com todas as réplicas no modo de confirmação síncrona, conforme mostrado na tabela a seguir:

Pode ser apropriado em sua situação executar uma atualização sem interrupção com balanceamento de carga na seguinte sequência:

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.

Com base em sua implementação específica, seu caminho de atualização pode variar e o tempo de inatividade que os aplicativos cliente experimentam também pode variar.

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 outras réplicas tiverem sido atualizadas, faça failover do primário global e atualize a última instância restante do primeiro grupo de disponibilidade. Um diagrama detalhado com etapas é fornecido em uma seção posterior.

Com base em sua implementação específica, seu caminho de atualização pode variar e o tempo de inatividade que os aplicativos cliente experimentam também pode variar.

Etapas gerais para atualizar um grupo de disponibilidade distribuído

1. Faça backup de todos os bancos de dados, incluindo bancos de dados do sistema e aqueles 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.

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

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, você a atualizaria antes NODE3\SQLAG e NODE1\SQLAG.

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

Dependendo da atualização que está sendo aplicada, etapas adicionais podem ser necessárias para bancos de dados de réplica de AG habilitados para captura ou replicação 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

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

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

Para obter informações em segundo plano, consulte a funcionalidade CDC que pode ser interrompida após a atualização para a mais recente.

Conteúdo relacionado

• Fazer upgrade do SQL Server usando o Assistente de Instalação (Instalação)
• Instalar e configurar o SQL Server no Windows por meio do prompt de comando