Atualização e aprimoramento dos servidores do grupo de alta disponibilidade com tempo mínimo de inatividade e perda de dados

Ao atualizar ou fazer upgrade de instâncias de servidor do SQL Server 2012 para um pacote de serviço ou uma versão mais recente, você pode reduzir o tempo de inatividade de um grupo de disponibilidade para apenas uma única transferência manual executando uma atualização ou upgrade sequencial. Para atualizar versões do SQL Server, ela é conhecida como atualização sem interrupção; para atualizar a versão atual do SQL Server com hotfixes ou service packs, ela é conhecida como atualização sem interrupção.

Este tópico limita a discussão somente para atualizações/atualizações do SQL Server. Para atualizações relacionadas ao sistema operacional em que as instâncias altamente disponíveis do SQL Server estão em execução, consulte Migração entre Clusters de Grupos de Disponibilidade AlwaysOn para Atualizações do Sistema Operacional

Práticas recomendadas para atualização gradual de grupos de disponibilidade AlwaysOn

As práticas recomendadas a seguir devem ser observadas ao executar atualizações/atualizações de servidor para minimizar o tempo de inatividade e a perda de dados para seus grupos de disponibilidade:

• Antes de iniciar a atualização sem interrupções,

  • Executar um failover manual de teste em pelo menos uma das suas réplicas de confirmação síncrona

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

  • Executar DBCC CHECKDB em todos os bancos de dados de disponibilidade

• Sempre atualize os nós de réplica secundária remotos primeiro, depois os nós de réplica secundária locais, e a 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 apenas na réplica primária. Antes de atualizar a réplica primária, modifique essa configuração para executar backups apenas nas réplicas secundárias.

• Para impedir que o grupo de disponibilidade faça failovers não intencionais durante o processo de atualização/atualização, remova o failover de disponibilidade de todas as réplicas de confirmação síncrona antes de começar.

• Não atualize o nó de réplica primária antes de fazer failover do grupo de disponibilidade para um nó atualizado 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 réplica primária.

• Sempre troque o grupo de disponibilidade para um nó de réplica secundária com confirmação síncrona. Se você realizar um failover para uma réplica secundária de confirmação assíncrona, os bancos de dados sofrerão perda de dados, e a movimentação de dados será suspensa automaticamente até que você retome manualmente essa movimentação.

• Não atualize o nó de réplica primária antes de atualizar os outros nós de réplica secundários. Uma réplica primária atualizada não pode mais enviar logs para nenhuma réplica secundária que 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.

• Antes de efetuar o failover de um grupo de disponibilidade, verifique se o estado de sincronização do destino do failover está como SINCRONIZADO.

Processo de atualização/melhoria contínua sem interrupção

Na prática, o processo exato dependerá de fatores como a topologia de implantação de seus grupos de disponibilidade e o modo de confirmação de cada réplica. Mas, no cenário mais simples, uma atualização/atualização sem interrupção é um processo de vários estágios 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 servidor remoto executando réplicas secundárias com confirmação assíncrona

3. Atualizar/atualizar todas as instâncias de servidor local que não estão executando a réplica primária no momento

4. Realizar transferência manual do grupo de disponibilidade para uma réplica secundária síncrona de confirmação

5. Atualizar/atualizar a instância do servidor que anteriormente hospedava a réplica primária

6. Configurar parceiros de failover automático conforme desejado

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

Grupo de disponibilidade com uma réplica secundária remota

Se você implantou um grupo de disponibilidade apenas para recuperação de desastres, talvez seja necessário efetuar o failover do grupo de disponibilidade para uma réplica secundária de confirmação assíncrona. Essa configuração é ilustrada na figura a seguir:

Nessa situação, você deve executar o failover do grupo de disponibilidade 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 grupo de disponibilidade. Portanto, o processo de atualização contínua pode ser o seguinte:

1. Atualizar/melhorar o servidor remoto

2. Alterar o modo de confirmação para confirmação síncrona

3. Aguarde até que o estado de sincronização seja SINCRONIZADO

4. Realizar a transferência do grupo de disponibilidade para o site remoto

5. Atualizar/atualizar o servidor local (site primário)

6. Fazer failover do grupo de disponibilidade para o site 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 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 reconhecidas sejam descartadas. A quantidade de mensagens de log descartadas pode ser bastante grande 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 impacto nos aplicativos cliente fazendo o seguinte:

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

• Ao atualizar o SQL Server no site primário, mude o modo de disponibilidade para confirmação assíncrona novamente e, em seguida, mude para confirmação síncrona quando estiver pronto para realizar o failover para o site primário novamente.

Grupo de disponibilidade com nós da instância do cluster de failover

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

1. Fazer upgrade/atualizar REMOTE2

2. Transferir a comutação da FCI2 para REMOTE2

3. Atualizar/modernizar REMOTE1

4. Fazer upgrade/atualizar PRIMARY2

5. Executar failover da FCI1 para o PRIMARY2

6. Atualizar PRIMARY1

Atualizar/atualizar instâncias do SQL Server com vários grupos de disponibilidade

Se você estiver executando vários grupos de disponibilidade com réplicas primárias em nós de servidor separados (uma configuração Ativa/Ativa), o caminho de atualização/atualização envolverá mais etapas de failover para preservar a alta disponibilidade no processo. Suponha que você esteja executando três grupos de disponibilidade em três nós de servidor, conforme mostrado na tabela a seguir, e todas as réplicas secundárias estejam em execução no modo de confirmação síncrona.

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

1. Transferir o AG2 para o Nó3 (para liberar o Nó2)

2. Fazer upgrade/atualizar o Node2

3. Fazer failover do AG1 para o Node2 (para liberar o Node1)

4. Atualizar/atualizar o Node1

5. Realizar o failover dos AG2 e AG3 para o Node1 (para liberar o Node3)

6. Atualizar/melhorar o Node3

7. Realizar failover do AG3 para o Node3

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

Com base em sua implementação específica, a trajetória de atualização pode variar, e o período de inatividade que os aplicativos cliente experimentam também possa variar.