You are using an outdated browser. Please update your browser for a better user experience.

Retour sur l'incident du 31/12/2019

Comme vous avez surement pu le constater, les services principaux de DryCat ont subit de forte perturbation entre le 31 décembre 2019 et le 1er janvier 2020.

L'origine de l'incident n'est pas que les serveurs qui avaient envie de fêter le nouvel an comme il ce doit, mais une quantité phénoménale de requête provenant de Matrix.org à saturé la base de donnée. Entre le 30 décembre et le 31 décembre la base de donnée de Synapse à augmenté de 45Go.
À 9h le 31 décembre, nous avons entrepris l'analyse et la recherche de solution, en vain. Vers 10h ce même jour, une opération visant à réduire la taille de la base de donnée a endommagé celle de Synapse la rendant inutilisable. Nous avons donc extrait les bases intacts et récupéré le backup de 9h. Un problème ne vient jamais seul, et lors de la restauration, nous avons rencontré un problème d'espace disque qui nous a contraint à relancer l'import.
Une fois l'import fini, nous avons réimporté les bases de données saines. Sauf celle de Mastodon qui n'a pas pu être correctement réimporté car celle ci possédait une entré dupliqué sur un index (ce qui reste curieux car cela fonctionnait même avec cette erreur). Nous avons supprimé l'index et relancé l'import avec succès. Tout refonctionne, on passe le nouvel an.

Après avoir verifié les services le 1er janvier, nous constatons que la base de donnée PostgreSQL surconsomme les ressources des machines et ne répond pas correctement. Nous avions un load de 15 pour 4 CPU et un débit de lecture de 60Mo/s sur les disques mécaniques de l'hyperviseur.

Je tente de recréer l'index supprimé la veille et je constate que tout les tags à partir du 25 décembre sont dupliqué. Je les supprimes et recréer l'index.
L'IOwait (la file d'attente pour lire ou écrire sur le disque) ne diminue pas. Après plusieurs tentative de correction, nous avons décidé de repartir sur une backup saine, celle de 9h du mardi 31 décembre 2019.

L'importation des backups est lente du fait de la granularité (à la minute près) et du poids du backups (75Go), cependant il s'agit du meilleur choix afin de ne pas perdre 2 jours de données.

Toutes nos excuses pour cette perte de donnée et l'indisponibilité pendant plus de 24h.