# « Un cluster protège toujours contre les pannes » : le cas où la réplication a propagé l’incident > Retour d'expérience sur une corruption de données répliquée sur tous les nœuds d'un cluster avant d'être détectée, et ce que cela change à la confiance dans la redondance. - Auteur : Clément Hadrot - Publié le : 2026-07-05 - Mis à jour le : 2026-07-05 - Catégorie : Hébergement & serveurs - URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/cluster-protege-toujours-pannes-replication-propage-incident/ ## L’essentiel - La réplication synchrone propage une corruption aussi vite qu'une écriture valide - Un cluster protège contre la panne matérielle, pas contre l'erreur logique - Une sauvegarde froide reste indispensable même avec un cluster en place La croyance est répandue et confortable : un cluster de haute disponibilité protège contre les pannes, puisque chaque nœud possède une copie à jour des données des autres. Cette croyance tient tant que la panne est matérielle, physique, franche, un disque qui lâche, un serveur qui s'éteint. Elle s'effondre dès que le problème n'est pas une panne mais une corruption logique, silencieuse, qui se propage exactement de la même façon qu'une écriture légitime. Ce billet ne traite pas de la mise en place initiale d'un cluster, un sujet déjà couvert ailleurs, mais d'un incident précis où la redondance censée protéger a activement aggravé la situation. Le cluster en question reposait sur trois nœuds MariaDB en réplication synchrone Galera, une configuration réputée robuste, capable de tolérer la perte complète d'un nœud sans interruption de service ni perte de données. C'est précisément cette robustesse qui a rendu l'incident plus difficile à contenir qu'une simple panne matérielle classique. ## Ce qu'on voit : une requête défectueuse traitée comme n'importe quelle autre Une migration de contenu, exécutée par un script maison lors d'une mise à jour de structure de table, contenait une erreur de logique qui a supprimé partiellement des lignes dans une table de métadonnées, en raison d'une condition `WHERE` mal construite qui correspondait à un périmètre plus large que prévu. Cette requête, syntaxiquement valide, a été exécutée sur le nœud primaire, puis répliquée en quelques millisecondes sur les deux autres nœuds du cluster, exactement comme n'importe quelle transaction légitime. Le cluster Galera a fait exactement ce qu'on attend de lui : garantir que les trois nœuds restent parfaitement synchronisés. Le problème est que la synchronisation ne distingue pas une écriture correcte d'une écriture erronée : les deux sont propagées avec la même fiabilité et la même rapidité. ## Pourquoi c'est un problème La détection de l'incident n'est intervenue que quarante minutes plus tard, lorsqu'un utilisateur a signalé l'absence de métadonnées sur plusieurs fiches produit. Pendant ce délai, les trois nœuds du cluster contenaient déjà la même version corrompue des données, rendant impossible toute restauration en basculant simplement vers un autre nœud du cluster, une opération qui aurait suffi face à une panne matérielle classique. > L'essentiel à retenir : La réplication synchrone propage une corruption aussi vite qu'une écriture valide ; Un cluster protège contre la panne matérielle, pas contre l'erreur logique ; Une sauvegarde froide reste indispensable même avec un cluster en place Cette situation illustre une confusion fréquente entre deux notions distinctes : la tolérance aux pannes matérielles, que le cluster assure effectivement très bien, et la protection contre l'erreur logique ou humaine, qu'aucune architecture de réplication synchrone ne peut apporter par construction. Un cluster qui synchronise parfaitement ses nœuds synchronise aussi parfaitement leurs erreurs. ## Ce qu'on voit trop souvent dans les plans de reprise - Une confiance excessive placée dans la haute disponibilité, au point de considérer les sauvegardes froides comme un filet de sécurité secondaire, presque superflu. - Des scripts de migration exécutés directement en production sans étape de validation préalable sur un environnement isolé du cluster. - Une absence de délai volontaire de réplication différée, qui aurait pu donner une fenêtre de rattrapage avant la propagation complète de l'erreur. ## Quoi faire différemment La restauration effective a nécessité de revenir à une sauvegarde froide antérieure à l'incident, prise plusieurs heures avant, avec une perte de données limitée aux transactions survenues dans cet intervalle. Cette étape a confirmé que la sauvegarde froide, souvent perçue comme une redondance excessive une fois un cluster en place, reste le seul mécanisme réellement capable d'absorber une corruption logique propagée par la réplication elle-même. 1. Conserver des sauvegardes froides à fréquence régulière, indépendantes du mécanisme de réplication du cluster, avec un test de restauration périodique. 2. Systématiser une validation préalable de tout script de migration sur un environnement séparé, avant toute exécution en production, même pour une opération jugée simple. 3. Envisager un nœud de réplication différée de quelques minutes, qui offre une fenêtre de rattrapage avant qu'une erreur ne soit propagée sur l'ensemble du cluster. > Un cluster protège contre la panne du matériel, jamais contre l'erreur du logiciel qui tourne dessus : les deux problèmes se ressemblent en apparence, mais aucune architecture de réplication ne résout le second. ## En résumé La haute disponibilité apportée par un cluster synchrone n'immunise pas contre une corruption logique introduite par une requête défectueuse : elle la propage au contraire avec la même efficacité qu'une écriture légitime. Cet incident a confirmé qu'une sauvegarde froide, testée régulièrement, reste indispensable même sur une infrastructure redondante, précisément parce qu'elle constitue le seul point de restauration qui échappe au mécanisme de réplication lui-même.