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 atualização cumulativa do SQL Server, ou ao instalar em um novo service pack ou atualização cumulativa do Windows, pode reduzir o tempo de inatividade da réplica primária para apenas uma única alternância manual executando uma atualização contínua (ou duas alternâncias manuais se houver reversão 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 ou para operações somente leitura e, após a atualização, pode levar algum tempo para que a réplica secundária alcance 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).

Lembre-se também 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 trazê-los para a versão mais recente. Durante esse período, não haverá réplicas legíveis 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 falhar de volta à primária original, esta etapa não será repetida quando você falhar de volta.

Pré-requisitos

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

• Atualizações de versão e edição com suporte: Verifique se você pode atualizar para a versão mais recente do SQL Server a partir da sua versão do sistema operacional Windows e da versão do SQL Server. Por exemplo, se você atualizar diretamente de uma instância do SQL Server 2005, seu nível de compatibilidade de 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 revisão das atualizações de versão e edição suportadas 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: revise as notas de versão e os problemas de atualização conhecidos, a lista de verificação de pré-atualização e desenvolva e teste o plano de atualização.

• Requisitos de hardware e software para instalar o SQL Server: Revise os requisitos de software para instalar o SQL Server. Se for necessário software adicional, instale-o em cada nó antes de iniciar o processo de atualização para minimizar qualquer tempo de inatividade.

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

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

Observe as seguintes diretrizes ao executar atualizações ou upgrades de servidor para minimizar o tempo de inatividade e a perda de dados para seus AGs:

• Antes de iniciar a atualização contínua:

  • Execute um failover manual prático em pelo menos uma de suas instâncias de réplica de confirmação síncrona.

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

  • Execute DBCC CHECKDB em todos os bancos de dados de disponibilidade.

• Sempre atualize as instâncias de réplica secundária remota primeiro, depois as instâncias de réplica secundária local em seguida e a instância de réplica primária por último.

• Os backups não podem ocorrer em um banco de dados que está em processo de atualização. Antes de atualizar as réplicas secundárias, configure a preferência de backup automatizado para executar backups somente na réplica primária. Durante uma atualização de versão, nenhuma réplica é legível ou está 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, os secundários legíveis não podem ser lidos após uma atualização do secundário legível e antes que a réplica primária seja transferida para um secundário atualizado ou a réplica primária seja atualizada.

• Para evitar que o AG faça failovers não intencionais 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 de réplica primária antes de realizar o failover do AG para uma instância atualizada com uma réplica secundária primeiro. Caso contrário, os aplicativos cliente poderão sofrer um tempo de inatividade prolongado durante a atualização na instância de réplica primária.

• Realize sempre o failover do AG para uma instância de réplica secundária com 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 ficarão vulneráveis à perda de dados e a movimentação de dados será suspensa automaticamente até que você retome manualmente a movimentação de dados.

• Não atualize a instância de réplica primária antes de atualizar ou fazer upgrades em qualquer outra instância de réplica secundária. Uma réplica primária atualizada não pode mais enviar logs para qualquer 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 de dados para uma réplica secundária é suspensa, nenhum failover automático pode ocorrer para essa réplica e seus bancos de dados de disponibilidade ficam vulneráveis à perda de dados. Isso também se aplica durante uma atualização contínua, em que você faz failover manualmente de um primário antigo para um novo primário. Como tal, depois de atualizar o primário antigo, talvez seja necessário retomar a sincronização.

• Antes de realizar um failover sobre um AG, verifique se o estado de sincronização do alvo do failover é SYNCHRONIZED.

  Advertência

  A instalação de 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 dos grupos de disponibilidade existentes na função principal no servidor. Portanto, é altamente recomendável que você siga um destes 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:

  • Instale 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 ele não seja primário durante a instalação da nova instância do SQL Server.

Processo de atualização contínuo

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

1. Remova 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. Atualize todas as instâncias de réplica secundária remota com confirmação síncrona.
4. Faça o upgrade de todas as instâncias locais de réplicas secundárias com confirmação síncrona.
5. Realize a transferência manual do AG para uma réplica secundária local de confirmação síncrona (recém-atualizada).
6. Melhore ou atualize a instância de réplica local que anteriormente tenha hospedado a réplica principal.
7. Configure 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 offline não atrasará as transações na principal. Depois que a réplica secundária é desconectada, as transações são confirmadas na réplica primária sem esperar que os logs sejam protegidos na réplica secundária. Se REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT estiver definido como ou 12, a réplica primária pode não estar disponí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 de sincronização/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 a movimentação de dados é interrompida, 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 o(s) banco(s) de dados forem atualizado(s) para o novo formato.

AG com uma réplica secundária remota

Se você implantou um AG apenas para recuperação de desastres, 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:

Nessa situação, deve-se realizar o failover do AG à réplica secundária de confirmação assíncrona durante a atualização gradual. 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 contínua 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 principal.
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, executar um failover faz com que todas as mensagens de log não reconhecidas 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 falhas transacionais. Você pode minimizar o efeito em aplicativos cliente executando as seguintes ações:

• Selecione cuidadosamente uma janela de manutenção durante o baixo tráfego de clientes.

• 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 de instância de cluster de alta disponibilidade

Se um AG contiver nós de instância de cluster de failover (FCI), você deverá atualizar os nós inativos antes de atualizar os nós ativos. A figura a seguir ilustra um cenário comum 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. Melhorar ou atualizar REMOTE2
2. Mudança de FCI2 para REMOTE2
3. Melhorar ou atualizar REMOTE1
4. Melhorar ou atualizar PRIMARY2
5. Transferência de FCI1 para PRIMARY2
6. Melhorar ou atualizar PRIMARY1

Atualizar ou fazer um upgrade das instâncias do SQL Server com múltiplos Grupos de Disponibilidade

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 contínua com balanceamento de carga na seguinte sequência:

1. Execute o failover de AG2 para Node3 para libertar Node2.
2. Melhorar ou atualizar Node2
3. Failover de AG1 para Node2 (para liberar Node1)
4. Melhorar ou atualizar Node1
5. Executar o failover de AG2 e AG3 para Node1 (para liberar Node3)
6. Melhorar ou atualizar Node3
7. Failover de AG3 para Node3

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

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

Atualização contínua de um grupo de disponibilidade distribuído

Para executar uma atualização contínua de um grupo de disponibilidade distribuído, primeiro atualize 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, o 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 grupo downstream).
3. Atualize e reinicie todas as réplicas secundárias do primeiro grupo de disponibilidade (o upstream).
4. Execute o 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. As bases de dados devem aparecer como sincronizadas em todas as réplicas de confirmação síncrona, e o primário global deve estar sincronizado com o encaminhador.
6. Atualize e reinicie a última instância remanescente 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 principal.
9. Reinicie o servidor recém-atualizado.
10. (opcional) Reverter ambos os grupos de disponibilidade para as suas réplicas primárias originais.

Exemplo de diagrama para uma atualização contínua de um grupo de disponibilidade distribuída

As etapas para atualizar as instâncias neste diagrama:

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 NODE4\SQLAG (secundário do AG2) e reinicie o servidor.
3. Atualize NODE2\SQLAG (secundário do AG1) e reinicie o servidor.
4. Falha AG2 de NODE3\SQLAG para NODE4\SQLAG.
5. Atualize NODE3\SQLAG e reinicie o servidor.
6. Falha AG1 de NODE1\SQLAG para NODE2\SQLAG.
7. Atualize NODE1\SQLAG e reinicie o servidor.
8. (facultativo) Reverter para as réplicas primárias originais.
   1. Falha AG2 a partir de NODE4\SQLAG até NODE3\SQLAG.
   2. Falhar AG1 de NODE2\SQLAG para NODE1\SQLAG.

Se existisse uma terceira réplica em cada grupo de disponibilidade, você a atualizaria antes NODE3\SQLAG e NODE1\SQLAG.

Etapas especiais para captura ou replicação 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 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 seguintes etapas são necessárias:

1. Atualize cada réplica secundária.

2. Depois que todas as réplicas secundárias tiverem sido atualizadas, faça 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 você estiver no SQL Server 2019 CU1 ou posterior. Para saber mais, consulte KB4530283.

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

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

Conteúdo relacionado

• atualizar o SQL Server usando o Assistente de Instalação (Instalação)
• Instalar e configurar o SQL Server no Windows a partir do prompt de comando