Atualizar réplicas do grupo de disponibilidade

Aplica-se a:SQL Server

Ao atualizar uma instância do SQL Server que hospeda um grupo de disponibilidade Always On (AG) para uma nova versão do SQL Server, para um novo service pack ou uma nova atualização cumulativa do SQL Server, ou ao instalar um novo service pack ou uma nova atualização cumulativa do Windows, você pode reduzir o tempo de inatividade da réplica primária para apenas um único failover manual realizando uma atualização gradual (ou dois failovers manuais, se houver failback para a réplica primária original).

Durante o processo de atualização, uma réplica secundária não estará disponível para failover nem para operações de somente leitura e, após a atualização, pode levar algum tempo para que a réplica secundária se sincronize com o nó da réplica primária, dependendo do volume de atividade no nó da réplica primária (portanto, espere um tráfego de rede intenso).

Além disso, esteja ciente de que, após o 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 atualizá-los para a 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 retornar ao primário original, essa etapa não será repetida quando isso ocorrer.

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: revise as notas de versão, os problemas conhecidos de atualização e 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.

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:

  • Realize um failover manual de teste em pelo menos uma de suas instâncias de réplica com commit síncrono.

  • 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, as réplicas secundárias legíveis não podem ser lidas após a atualização da réplica secundária legível e antes que o failover da réplica primária para uma secundária atualizada seja realizado ou que a réplica primária seja atualizada.

• Para evitar que o AG faça failovers inesperados durante o processo de atualização, remova o failover automático de todas as réplicas de confirmação síncrona antes de iniciar.

• 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 para uma instância de réplica secundária com commit síncrono. 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 de 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 gradual em que você executa manualmente a transferência do primário antigo para o novo primário. Assim, depois de atualizar o primário antigo, talvez seja necessário retomar a sincronização.

• Antes de executar um failover de um AG, verifique se o estado de 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.

  • Realize o failover do grupo de disponibilidade para a réplica secundária, de modo que ele não permaneça como primário 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 de 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. Atualize 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 com confirmação síncrona.
4. Atualizar todas as instâncias locais de réplica secundária de confirmação síncrona.
5. Executar o failover manual do AG para uma réplica secundária local de confirmação síncrona (recém-atualizada).
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 colocá-la fora de operação não atrasará as transações na réplica primária. Depois que a réplica secundária é desconectada, as transações são confirmadas na primária sem esperar que os logs sejam gravados de forma persistente na réplica secundária. Se REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT estiver definido como 1 ou 2, a réplica primária poderá ficar indisponível para operações de leitura/gravação quando um número correspondente de réplicas secundárias síncronas 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 anterior, a movimentação de dados é interrompida, nenhum failover automático pode ocorrer para essa réplica, e seus bancos de dados de disponibilidade ficam 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 executar o failover do AG para a réplica secundária de confirmação assíncrona durante a atualização contínua. 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. Realize a comutação do AG para a réplica secundária no local remoto.
5. Faça upgrade ou atualize a instância de réplica local (site primário).
6. Realize o failover do AG de volta ao 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 fazer upgrade ou atualizar o SQL Server no site primário, altere novamente o modo de disponibilidade para confirmação assíncrona e, em seguida, retorne à confirmação síncrona quando estiver pronto para executar o failover para o site primário novamente.

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

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

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

Fazer upgrade ou 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 processo de atualização exigirá mais etapas de failover para preservar a alta disponibilidade durante o 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, na sua situação, realizar uma atualização contínua com balanceamento de carga na sequência a seguir:

1. Realizar failover de AG2 para Node3 (para liberar Node2)
2. Fazer upgrade ou atualizar Node2
3. Fazer failover do AG1 para Node2 (para liberar Node1)
4. Atualizar ou mudar para uma versão superior Node1
5. Fazer failover de AG2 e AG3 para Node1 (para liberar Node3)
6. Fazer upgrade ou atualizar 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, realize o failover do encaminhador e atualize a última instância remanescente 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 aparecer como sincronizados em todas as réplicas com confirmação síncrona, e o primário global deve estar sincronizado com o servidor de encaminhamento.
6. Atualize e reinicie a última instância restante do grupo de disponibilidade secundária.
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. Realize o failover de AG2 de NODE3\SQLAG para NODE4\SQLAG.
5. Atualize o NODE3\SQLAG e reinicie o servidor.
6. Realize a comutação por failover de AG1 de NODE1\SQLAG para NODE2\SQLAG.
7. Atualize o NODE1\SQLAG e reinicie o servidor.
8. (opcional) Reverter para as réplicas primárias originais.
   1. Realizar 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 de NODE3\SQLAG e NODE1\SQLAG.

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

Dependendo da atualização que está sendo aplicada, etapas adicionais poderão ser necessárias para bancos de dados de réplica de AG que estejam habilitados para captura de dados de alterações ou replicaçã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, execute o failover do AG para uma 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 adicionais, consulte a funcionalidade do CDC pode deixar de funcionar após a atualização para o CU 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