Operação diária e cenários de falha da replicação MySQL (8.0 / 8.4)

Runbook de operação diária e recuperação de falhas para uma topologia source + replica já instalada (async / semi-sync, GTID ou posição do binlog): verificação de saúde e de atraso, switchover planejado, failover, reintegração do source antigo, reconstrução de uma replica (clone / XtraBackup / mysqldump), errant GTID, erros 1062/1032, recuperação de dados com uma replica atrasada, troca de source de uma replica e limpeza de binlogs. Cada cenário segue o padrão diagnóstico → rede de segurança → execução → verificação → acompanhamento. Este não é um guia de instalação: para configurar a replicação pela primeira vez, abra o guia «Replicação GTID do MySQL»; para InnoDB Cluster (Group Replication), o guia «Operação do InnoDB Cluster».

Topologia: 1 source + 1..5 replicas (async / semi-sync)

Cenários

• Verificação de status e de atraso (a replicação está saudável?) — Somente leitura: threads IO/SQL, últimos erros, atraso real, status do semi-sync e verificação de errant GTID; nada é alterado, sem downtime. Se você não tiver certeza do que fazer, comece por aqui: o último passo indica o cenário certo com base na saída.
• Switchover planejado (passar o papel de source para uma replica) — O source e as replicas estão saudáveis; você está passando o papel de source para uma replica de forma planejada, para manutenção, troca de hardware ou upgrade. As gravações param por alguns minutos, sem perda de dados; voltar é o mesmo cenário no sentido inverso.
• Source perdido: failover para a replica mais adiantada — O source caiu ou está inacessível e não voltará em pouco tempo (thread IO Connecting nas replicas, 2003/2013). A replica mais adiantada vira o novo source e as demais se conectam a ela. As gravações ficam indisponíveis até o novo source ser aberto; no modo async, as últimas transações do source podem ser perdidas.
• Reintegrar o source antigo como replica após o failover — O failover foi feito e o servidor do source antigo voltou. Primeiro ele é fechado para gravação e seus binlogs são copiados; em seguida é verificada a existência de errant transactions. Se estiver limpo, vira replica diretamente; caso contrário, é reconstruído a partir do novo source. Sem downtime no novo source.
• Reconstruir uma replica do zero (clone / XtraBackup / mysqldump) — Os binlogs de que a replica precisa foram apagados no source (1236), os dados dela divergiram do source, 1062/1032 voltam a aparecer seguidamente ou o disco da replica foi perdido. Todos os dados da replica são substituídos por uma cópia do source; o source continua no ar e a replica de destino fica indisponível durante esse tempo.
• Errant GTID: a replica tem transações que o source não tem — Há transações gravadas diretamente na replica (com super_read_only desativado) ou herdadas de um source antigo; num failover essas transações se propagam para as outras replicas ou param a replicação com 1236. Solução: transação vazia, aplicar no source ou reconstruir. Sem downtime.
• Replicação parada: 1062 Duplicate entry / 1032 Can't find record — A thread SQL parou com um erro de dados (Replica_SQL_Running: No, Last_SQL_Errno 1062/1032/1146/1677…). Primeiro a linha é levada ao estado que tem no source; se não for possível, como último recurso uma única transação é ignorada. Só esta replica é afetada: ela fica para trás e as aplicações que leem dela veem dados desatualizados.
• Replica atrasada (SOURCE_DELAY): configurar ou recuperar dados apagados — Você quer manter uma replica deliberadamente N segundos atrás (definir / remover o atraso) ou recuperar, a partir da replica atrasada, dados apagados/alterados por engano (DROP, DELETE/UPDATE sem WHERE) antes que a alteração seja aplicada nela. O source continua no ar.
• Mover uma replica para outro source (encadeamento / reconexão) — Você quer ligar uma replica abaixo de outra replica (cadeia / replica intermediária) ou de volta ao source; nenhum dado é copiado, só a conexão muda. A replica movida para por alguns segundos.
• Limpeza e retenção de binlogs (disco enchendo) — Os binlogs estão enchendo o disco ou você quer definir o período de retenção; a limpeza é feita sem apagar os arquivos de que as replicas e o PITR ainda precisam. Sem downtime.

Antes de começar

• MySQL …… (8.0.26 e posteriores)… na mesma versão minor em todos os servidores…, gtid_mode = ON e enforce_gtid_consistency = ON…, binlog ativado…; o root do sistema operacional conecta com mysql sem senha (auth_socket ou ~/.mylogin.cnf). A topologia foi montada com o guia de instalação da replicação ou de forma equivalente.
• Os papéis foram verificados e correspondem às entradas: … (…)… é o source antigo perdido… é o source atual (read_only = 0, sem configuração de replica)…; os servidores da lista são replicas.… Promovido a source no failover: … (…).…
• A senha da conta … é conhecida. A conta existe para o IP de cada servidor ('…'@'<ip>', REQUIRE SSL); os passos a usam para ler valores como o conjunto de GTIDs nos outros servidores e, numa troca de papel, na conexão de replicação. A senha não contém ', " nem \.
• Os servidores se alcançam pela porta ….
• Os dois plugins de semi-sync estão instalados e ACTIVE em todos os servidores: rpl_semi_sync_source (semisync_source.so) e rpl_semi_sync_replica (semisync_replica.so); numa troca de papel, os dois lados são ativados ou desativados em cada servidor. Se os plugins com nome antigo rpl_semi_sync_master / rpl_semi_sync_slave (anteriores à 8.0.26, obsoletos na 8.4) estiverem carregados, as variáveis rpl_semi_sync_source_enabled / rpl_semi_sync_replica_enabled usadas nos passos não existem: primeiro remova o plugin antigo com UNINSTALL PLUGIN e instale o novo (os dois não podem ser carregados no mesmo servidor; INSTALL PLUGIN é recusado num servidor somente leitura, então super_read_only é desativado temporariamente).
• Na replica que será o novo source / servidor intermediário, log_bin = ON e log_replica_updates = ON (padrão na 8.x); caso contrário, o binlog dela não contém as transações vindas do source e as outras replicas não conseguem se conectar a ela.
• Há acesso SSH de root (por chave) entre os servidores envolvidos para a transferência de arquivos…: … → ……. Se não houver, mova os arquivos pelo método aprovado na sua organização; os passos mostram os caminhos dos arquivos.
• Percona XtraBackup da mesma versão principal do MySQL instalado no donor (…) e no destino (…); a conta de backup bkpuser (auth_socket) existe no donor — as duas primeiras fases do guia do XtraBackup.
• Aprovação da mudança e canal de comunicação prontos (equipe da aplicação, janela de manutenção). Para a troca de papel, sabe-se quem altera o endereço de gravação da aplicação (VIP, DNS, ProxySQL / HAProxy / Router) e como.

Fases do guia

• Status: source, replicas e atraso (somente leitura) — Mostrar o papel do source, a posição do binlog e as replicas conectadas · Mostrar o status das threads, os erros e o atraso das replicas · Medir o atraso real e a fila de aplicação pelo performance_schema · Verificação de errant GTID (a replica tem transações que o source não tem?) · Interpretar o resultado e escolher o cenário certo
• 1. Diagnóstico: está pronto para o switchover? — Verificar o source e as replicas conectadas · Verificar se a replica candidata é adequada · Verificar se todas as replicas estão saudáveis
• 2. Rede de segurança — Registrar o estado atual em todos os servidores
• 3. Execução: passar o papel — Parar as gravações da aplicação · Fechar o source para gravação e obter a última posição · Esperar as replicas alcançarem o source · Promover o candidato a source (promote) · Tornar o source antigo replica do novo source · Conectar as outras replicas ao novo source (…) …
• 4. Verificação — Fazer uma gravação de teste no novo source · Verificar a replicação e a linha de teste em todos os servidores
• 5. Acompanhamento — Apagar o banco de teste e atualizar a operação
• 1. Diagnóstico: o source está mesmo perdido e qual replica é a mais adiantada? — Tentar alcançar o source uma última vez (a partir da replica candidata) · Isolar o source antigo (fencing) · Esperar em cada replica a aplicação das transações do relay log · Determinar a replica mais adiantada · Determinar a replica mais adiantada (baseado em posição)
• 2. Rede de segurança — Registrar o estado atual nas replicas
• 3. Execução: failover — Promover o candidato a source (promote) · Conectar as outras replicas ao novo source (…) · Liberar as gravações no novo source · Redirecionar a aplicação para o novo source
• 4. Verificação — Fazer uma gravação de teste no novo source · Verificar a replicação e a linha de teste nas replicas
• 5. Acompanhamento — Planejar as transações perdidas, o backup e o source antigo
• 1. Diagnóstico: o source antigo está limpo? — Mostrar o status do source antigo · Encontrar errant transactions (comparar com o novo source) · Decisão de reintegração na replicação baseada em posição
• 2. Rede de segurança — Fechar imediatamente o source antigo para gravação e registrar seu estado · Extrair as errant transactions para um arquivo separado
• 3. Execução: conectar como replica — Conectar o source antigo ao novo source
• 4. Verificação — Verificar se o source antigo está rodando como replica
• 5. Acompanhamento — Planejar a topologia e o futuro do source antigo
• 1. Diagnóstico: qual é o conjunto errant? — Calcular o conjunto de errant GTIDs
• 2. Rede de segurança: salvar o conteúdo das errant transactions — Decodificar as errant transactions a partir do binlog e salvá-las
• 3. Execução: injetar transações vazias no source — Executar os errant GTIDs como transações vazias no source
• 3. Execução: aplicar as errant transactions no source — Extrair as errant transactions para um arquivo e copiá-lo para o source · Aplicar as transações no source
• 4. Verificação — Verificar se não restou conjunto errant
• 5. Acompanhamento: evitar que se repita — Encontrar a causa raiz e proteger as replicas
• 1. Diagnóstico: qual transação, qual linha? — Mostrar o erro e a transação com erro · Decodificar a partir do relay log as linhas da transação com erro · Comparar a linha no source e na replica
• 2. Rede de segurança — Registrar o status da replica e o estado atual da tabela
• 3. Execução: corrigir a linha na replica — Preparar o SQL de correção · Aplicar a correção sem gravar no binlog e iniciar a replicação
• 3. Execução: ignorar a transação com erro (último recurso) — Ignorar só a transação com erro
• 4. Verificação — Comparar a linha e o checksum da tabela nos dois lados
• 5. Acompanhamento — Encontrar a causa raiz
• 1. Diagnóstico — Mostrar a configuração atual de atraso da replica
• 2. Rede de segurança — Registrar o status da replica