Réplica cassé / resynchronisation nécessaire
La synchronisation entre le réplica/standby et le primaire est rompue. Déterminez si la réplication s'est arrêtée, quel est son retard et si la chaîne de position/GTID est rompue ; puis choisissez la bonne voie entre ignorer une erreur, attendre ou reconstruire (reseed). Comprend un avertissement sur le split-brain.
Quel est l'état général de la réplication ?
Lisez d'abord la santé de la réplication : les threads d'application tournent-ils, quelle est l'ampleur du retard, y a-t-il une erreur ? Vérifiez aussi que les deux nœuds n'acceptent pas tous deux des écritures (split-brain).
SHOW REPLICA STATUS\G
-- Check: Replica_IO_Running, Replica_SQL_Running, Seconds_Behind_Source, Last_Error, Retrieved/Executed_Gtid_Set- La réplication s'est arrêtée / échoue
- Elle tourne mais avec un fort retard
- GTID/position rompu(e), incohérent — reconstruire
- Les deux nœuds écrivent en tant que primaire (split-brain suspecté)
L'erreur est-elle réparable, ou faut-il reconstruire ?
Examinez l'erreur d'application. Certaines erreurs (clé en double, ligne manquante) se résolvent en ignorant prudemment un seul événement ; mais en cas d'incohérence/corruption des données, la seule voie correcte est de reconstruire le réplica.
SHOW REPLICA STATUS\G
-- Check: Last_SQL_Errno, Last_SQL_Error, Last_IO_Errno, Last_IO_Error- Une ou quelques erreurs d'application (ignorables)
- Incohérence / corruption irréparable
Le retard est-il temporaire ou persistant ?
Examinez l'évolution du retard dans le temps. Se résorbe-t-il (rattrapage) après un pic de charge temporaire, ou continue-t-il de croître si bien que le réplica ne rattrape jamais le primaire ?
SHOW REPLICA STATUS\G
-- Measure Seconds_Behind_Source several times: is it decreasing or increasing?- Pic de charge temporaire ; le retard se résorbe
- Il continue de croître ; impossible de rattraper
Solution : ignorez l'erreur d'application avec prudence
Si la réplication s'est arrêtée sur une seule erreur d'application (par ex. une clé en double) et que vous êtes sûr que les données sont réellement cohérentes, vous pouvez ignorer cet événement et poursuivre le flux. C'est un dernier recours ; ignorer à l'aveugle crée une dérive silencieuse des données.
Solution : reconstruire le réplica (reseed / rebuild)
Si la chaîne de position/GTID est rompue, si les données ont dérivé ou en cas d'erreur irréparable, la seule voie fiable est de reconstruire le réplica à partir d'une copie fraîche prise sur le primaire.
Cause racine : pic de charge temporaire (le retard se résorbe)
La réplication est saine ; le retard s'est creusé à cause d'une rafale d'écritures temporaire sur le primaire ou d'une fluctuation réseau, mais le réplica rattrape son retard.
Cause racine : le réplica ne suit pas le primaire
Le côté application (apply/redo) ne suit pas le rythme des modifications produites par le primaire ; le retard ne cesse de croître. En général : application mono-thread, matériel du réplica lent ou goulot réseau.
AVERTISSEMENT : split-brain (deux primaires) — risque de perte de données
Si les deux nœuds acceptent des écritures dans le rôle de primaire, des modifications conflictuelles s'accumulent des deux côtés ; c'est la situation la plus dangereuse et elle peut entraîner une perte de données. Ramener les écritures sur un seul nœud est la priorité.