Operação do SQL Server Always On AG (Windows e Linux)

Não é uma instalação: operação diária e cenários de falha de um Always On Availability Group já instalado: verificação de saúde, diagnóstico de atraso e crescimento do log, failover planejado, failover forçado (FORCE_FAILOVER_ALLOW_DATA_LOSS) e o que vem depois, suspensão/retomada da movimentação de dados, modo síncrono/assíncrono, adição de bancos de dados (automatic seeding ou backup/restore), adição/remoção de réplicas, read-only routing e alterações do listener. Com comandos do WSFC no Windows e do Pacemaker (pcs) no Linux.

Escolha o que fazer no cartão de cenários; você também pode abrir diretamente o cenário em questão digitando o número do erro (ex.: 9002, 35264, 41142) na busca do catálogo. Se ainda não houver AG: AG (Windows) ou AG (Linux).

Topologia: AG com 2–9 réplicas (Windows WSFC ou Linux Pacemaker)

Cenários

• Verificação de saúde do AG (consultas do dashboard) — Está tudo certo? Estado das réplicas / bancos de dados, prontidão para failover, o cluster e as últimas mudanças de papel. Não altera nada.
• Secondary ficando para trás / arquivo de log crescendo (diagnóstico de atraso) — A fila de send/redo está crescendo, os dados no secondary estão desatualizados, o log no primary está prestes a encher (log_reuse_wait = AVAILABILITY_REPLICA) ou os commits estão lentos (HADR_SYNC_COMMIT).
• Failover planejado (switchover, sem perda de dados) — Move o primary para um secondary síncrono e SYNCHRONIZED para manutenção, patch ou teste; alguns segundos de indisponibilidade, sem perda de dados.
• Primary perdido: failover forçado (FORCE_FAILOVER_ALLOW_DATA_LOSS) — O primary (ou todo o site / o quorum do cluster) foi perdido e não é possível esperar: um secondary é tornado primary, aceitando perda de dados; depois os dados são comparados e as outras réplicas são retomadas.
• Suspender / retomar a movimentação de dados (SUSPEND / RESUME) — Interromper temporariamente o envio de dados para um secondary (manutenção de rede, operação em lote) ou retomar um banco de dados que ficou suspenso (SUSPENDED).
• Alterar o modo síncrono / assíncrono — Mudar uma réplica entre SYNCHRONOUS_COMMIT ↔ ASYNCHRONOUS_COMMIT (site remoto, rede lenta, teste de DR) e configurar a proteção de commit (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT).
• Adicionar um banco de dados ao AG (automatic seeding ou backup/restore) — Colocar um banco de dados novo ou existente no AG: automatic seeding para bancos pequenos/médios, a partir de backup para bancos grandes ou em rede lenta.
• Adicionar uma réplica (node) — Adicionar um novo secondary ao AG: o node entra no cluster, o endpoint é preparado, ADD REPLICA + JOIN, e os bancos de dados chegam por seeding.
• Remover uma réplica (node) — Remover do AG e do cluster um secondary que será desativado definitivamente ou reinstalado.
• Roteamento de leitura (read-only routing) — Direcionar as conexões ApplicationIntent=ReadOnly, pelo listener, para secondaries legíveis (tirar a carga de relatórios do primary).
• Criar ou alterar o listener (IP, porta) — Criar o listener se não existir, alterar a porta dele ou (Windows) adicionar um IP para uma segunda sub-rede.

Antes de começar

• sqlcmd (/opt/mssql-tools18/bin/sqlcmd) em cada node e … como sysadmin; privilégio de root (pcs). Senha: read -rsp 'Senha: ' SQLCMDPASSWORD; export SQLCMDPASSWORD e sudo --preserve-env=SQLCMDPASSWORD bash <script>.sh.
• O PowerShell foi aberto como administrador, com uma conta de domínio que é sysadmin no SQL Server e administradora no WSFC; sqlcmd e o módulo FailoverClusters estão disponíveis.
• A linha 1 da lista de réplicas no formulário é o primary atual (confirme com a primeira consulta da verificação de saúde); os passos são colocados no node certo de acordo com essa ordem.
• A janela de mudança foi aprovada e a equipe da aplicação foi informada…: o listener fica indisponível por alguns segundos e as transações abertas são revertidas……: a mudança de porta/IP afeta as connection strings….
• A decisão pelo failover forçado foi tomada por uma pessoa autorizada e a perda de dados foi aceita: o primary está inacessível e não voltará em um tempo razoável. Se o primary puder voltar, esperar ou fazer um failover planejado é sempre melhor.

Fases do guia

• Verificação de saúde do AG — Painel do AG: réplicas, bancos de dados, prontidão para failover · Estado do cluster (WSFC) · Estado do cluster (Pacemaker) · Últimas mudanças de papel (AlwaysOn_health)
• Diagnóstico de atraso e crescimento do log — Diagnóstico: filas, taxas e tempo estimado para alcançar (primary) · Diagnóstico: esperas de commit (primary) · Diagnóstico: o redo está bloqueado? (nos secondaries) · Opções de solução e verificação do log
• Failover planejado — Diagnóstico: o alvo está pronto para failover? (…) · Rede de segurança: há transações longas ou jobs em execução? (primary) · Failover: tornar … o primary (T-SQL) · Failover: tornar … o primary (pcs) · Verificar: novo primary e listener
• Failover forçado (pode haver perda de dados) — Diagnóstico: estado do alvo e possível perda de dados (…) · Iniciar à força o quorum do WSFC (…) · Impedir que o Pacemaker gerencie o recurso do AG (…) · Failover forçado: tornar … o primary · Verificar: novo primary aberto, os outros SUSPENDED · Criar um snapshot no antigo primary para recuperar os dados perdidos (…, quando voltar) …
• Suspender / retomar a movimentação de dados — Diagnóstico: bancos de dados suspensos e o motivo · …Suspender a movimentação de dados (SUSPEND)…Retomar a movimentação de dados (RESUME)… · Verificar e monitorar
• Alteração do availability mode — Diagnóstico: modos atuais e proteção de commit · … → … · Configurar a proteção de commit (Windows) · Configurar a proteção de commit (Pacemaker) · Verificar
• Adicionar um banco de dados ao AG — Diagnóstico: o banco de dados pode entrar no AG? (primary) · Preparar: recovery FULL e backup (primary) · Passar as réplicas para seeding manual (primary) · Adicionar o banco de dados ao AG (primary) · Acompanhar o seeding (primary) · Preparar no secondary a partir de backup (NORECOVERY): … …
• Adicionar réplica — Adicionar o novo node ao WSFC (primary) · Habilitar o Always On (novo node) · Criar o endpoint e conceder permissões (novo node) · Preparar o novo node: agente de HA, Always On, software de cluster · Copiar o certificado do endpoint para o novo node (primary) · Certificado, endpoint e login do Pacemaker (novo node) …
• Remover uma réplica — Diagnóstico: a réplica a remover e a configuração restante · Remover o node do cluster Pacemaker (primary) · Remover a réplica do AG (primary) · Remover o node do WSFC (opcional) · Limpar os bancos de dados em RESTORING no node removido (…)
• Read-only routing — Diagnóstico: permissões de leitura e routing atual · Definir as routing URLs e as listas (primary) · Verificar: routing list · Teste: para onde vai uma conexão ReadOnly? · Teste: para onde vai uma conexão ReadOnly?
• Listener — Diagnóstico: listeners atuais · Criar o recurso de IP virtual e as constraints (Pacemaker) · …Criar o listener…Alterar a porta do listener…Adicionar um IP ao listener… (primary) · Configurações de firewall e DNS · Configurações de firewall · Verificar: conexão pelo listener