Operação diária e cenários de falha do MySQL InnoDB Cluster (MySQL Shell 8.4)

Não é instalação: runbook por cenários para a operação diária e a recuperação de falhas de um InnoDB Cluster já em funcionamento (Group Replication + MySQL Router, implantado com a AdminAPI do MySQL Shell). Escolha um cartão de cenário: verificação de saúde, inclusão de membros (clone / incremental) e remoção (inclusive com force), reintegração de um membro que caiu, reinício depois que o cluster inteiro parou (rebootClusterFromCompleteOutage), forceQuorumUsingPartitionOf na perda da maioria, troca planejada de primary, inclusão / novo bootstrap do Router, opções do cluster (consistency, expelTimeout, memberWeight, autoRejoinTries, exitStateAction) e rescan() para os metadados. Todo cenário segue o padrão diagnóstico → rede de segurança → execução → verificação → acompanhamento. Se for montar o cluster pela primeira vez, abra o guia de instalação do InnoDB Cluster; para replicação clássica source–replica, o guia de operação da replicação; para a migração 8.0 → 8.4, o guia de upgrade.

Topologia: 3–9 nós MySQL (single-primary) + MySQL Router

Cenários

• Status e verificação de saúde do cluster (está tudo bem?) — Somente leitura: cluster.status({extended: 1}), papel/estado/versão dos membros, filas de aplicação, lista de Routers e error log; nada muda, sem downtime. Comece por aqui se não tiver certeza ou se chegou um alerta; o último passo indica o cenário certo.
• Adicionar um novo membro (addInstance: clone / incremental) — Você quer adicionar um novo nó MySQL ao cluster, aumentar a tolerância a falhas (3 → 5) ou trazer de volta um nó que foi removido. O cluster continua aceitando gravações; durante o clone há carga de disco/rede no donor e o novo nó é reiniciado.
• Remover um membro (removeInstance, com force se necessário) — Você quer remover um nó do cluster de forma permanente (devolução de hardware, redução) ou o nó foi perdido e precisa ser apagado dos metadados (force). Remover um secondary não causa downtime; remover o primary causa uma interrupção de gravação de alguns segundos.
• Reintegrar um membro que caiu (MISSING / ERROR / OFFLINE) — Um membro foi reiniciado, perdeu a rede ou foi expulso do grupo (expelled); a maioria está funcionando e a aplicação consegue gravar. Com rejoinInstance o membro recebe o que perdeu e volta; o cluster não tem downtime.
• O cluster inteiro parou: reiniciá-lo (rebootClusterFromCompleteOutage) — Todos os nós caíram e voltaram por um motivo como falta de energia / falha do data center / do hipervisor; o Group Replication não está rodando em nenhum membro e a aplicação não consegue gravar (o downtime continua). O cluster é reiniciado a partir do membro mais atualizado.
• Perda da maioria (NO_QUORUM): forçar o quorum com os membros restantes — A maioria dos membros sumiu ao mesmo tempo (ex.: 2 de 3) e os restantes pararam de aceitar gravações com NO_QUORUM (as gravações ficam travadas). Se tiver certeza de que os membros perdidos estão de fato parados, o cluster volta a funcionar com a partição que sobrou. O uso incorreto cria split-brain; a perda de um único membro (a maioria continua de pé) não é este cenário.
• Troca planejada de primary (setPrimaryInstance) — Você quer passar o papel de primary, de forma planejada, para um secondary específico por manutenção (patch do SO, hardware), balanceamento de carga ou ensaio de DR. As gravações esperam alguns segundos e as transações abertas são concluídas; o Router redireciona para o novo primary sozinho.
• Adicionar o Router ou fazer novo bootstrap — Você quer instalar o Router em um novo servidor de aplicação, fazer novo bootstrap do Router (upgrade de versão, cluster recriado, aviso routerErrors) ou limpar registros antigos de Router. Durante o novo bootstrap, as conexões da aplicação que passam por esse Router caem por um instante.
• Alterar as opções do cluster (consistency, expelTimeout, memberWeight…) — Você quer ajustar a consistência no failover, o tempo até um membro ser expulso em oscilações de rede, a prioridade de failover, a reintegração automática ou o comportamento do membro em caso de erro. As alterações são feitas com o cluster em funcionamento, sem restart; consistency vale para novas sessões.
• Sincronizar os metadados com o grupo real (rescan) — cluster.status() menciona um membro que não está nos metadados ou um registro antigo que não está mais no grupo (START GROUP_REPLICATION feito à mão, membro antigo não removido, servidor reinstalado). Sem downtime; apenas os metadados são atualizados.

Antes de começar

• O MySQL Shell … e o MySQL … estão instalados nos nós envolvidos; o cluster foi montado com o guia de instalação do InnoDB Cluster ou de forma equivalente com a AdminAPI (os metadados existem). O root do sistema operacional consegue se conectar ao mysql local sem senha. Obtenha o nome do cluster do formulário com dba.getCluster().getName() e os endereços dos membros nas linhas ip:port da topologia em cluster.status().
• A senha da conta … é conhecida (a mesma em todos os nós). O MySQL Shell pede a senha a cada conexão; com --save-passwords=never ele não a armazena.
• Os nós se alcançam pelas portas do MySQL (……:……, ……) e pelas portas de comunicação do Group Replication.
• O MySQL … está instalado no novo nó na mesma versão minor dos membros do cluster (exigência do clone), o GTID está habilitado, o server_id é diferente dos outros nós e as configurações do Group Replication do guia de instalação estão no my.cnf; as portas do firewall/SELinux estão liberadas.
• O servidor do Router alcança os nós pela porta do MySQL… e consegue acessar repo.mysql.com….
• Aprovação da mudança, janela de manutenção (se necessária) e comunicação com a equipe da aplicação estão prontas.

Fases do guia

• Status: cluster, membros e Router (somente leitura) — Obter e salvar o status detalhado do cluster · Verificar membros e filas com SQL · Examinar os registros de erro do Group Replication · Verificar o roteamento RW/RO pelo Router · Interpretar o resultado e escolher o cenário certo
• 1. Diagnóstico: o novo nó e o cluster estão prontos? — Verificar a versão e a identidade do novo nó · Verificar o status do cluster e as versões dos membros
• 2. Rede de segurança — Salvar a topologia atual
• 3. Execução: adicionar o membro — Configurar o novo nó e criar a conta de administrador · Fazer o cluster verificar a elegibilidade do novo nó · Adicionar o nó ao cluster (…)
• 4. Verificação — Verificar que o novo membro está ONLINE
• 5. Acompanhamento — Atualizar o Router, o monitoramento e o inventário
• 1. Diagnóstico: é seguro remover o membro? — Mostrar o estado do membro alvo e a tolerância restante
• 2. Rede de segurança — Salvar a topologia atual
• 3. Execução: remover o membro — Remover o membro do cluster… (force)…
• Se o nó removido com force voltar — Parar e limpar o Group Replication no nó que voltou
• 4. Verificação — Verificar os membros restantes
• 5. Acompanhamento — Número ímpar, Router e monitoramento
• 1. Diagnóstico: por que o membro caiu? Ele pode ser reintegrado? — Estado do membro alvo visto pelo cluster · Mostrar o estado do MySQL e do Group Replication no nó alvo · Verificação de errant transactions (no alvo, mas não no cluster)
• 2. Rede de segurança — Salvar o estado atual
• 3. Execução: reintegrar o membro — Reintegrar o membro com rejoinInstance
• 4. Verificação — Verificar que o membro está ONLINE
• 5. Acompanhamento — Causa raiz e reintegração automática
• 1. Diagnóstico: o cluster inteiro está mesmo parado? Qual membro é o mais atualizado? — Iniciar o MySQL em cada nó e mostrar o estado do Group Replication · Perguntar ao Shell qual é o membro mais atualizado (dryRun)
• 2. Rede de segurança — Salvar o GTID set de todos os nós
• 3. Execução: iniciar o cluster a partir do membro mais atualizado — Reiniciar o cluster
• 4. Verificação — Verificar que todos os membros estão ONLINE
• 5. Acompanhamento — Router, aplicação e causa raiz
• 1. Diagnóstico: o quorum foi mesmo perdido? — Mostrar o status do cluster a partir do nó que sobreviveu
• 2. Rede de segurança: isolar os membros perdidos — Garantir que os nós perdidos estejam parados (fencing) · Salvar o estado da partição que sobreviveu
• 3. Execução: forçar o quorum — Estabelecer o quorum com a partição que sobreviveu
• 4. Verificação e retorno dos membros perdidos — Verificar que as gravações foram liberadas · Reintegrar os membros perdidos (…)
• 5. Acompanhamento — Revisar a topologia
• 1. Diagnóstico: o alvo pode se tornar primary? — Verificar o estado e as versões dos membros
• 2. Rede de segurança — Salvar o estado atual
• 3. Execução: trocar o primary — Transferir o papel de primary para …