Attention, ce billet se traine depuis plus de 3 mois. Les informations qu'il contient ne sont peut-être plus à jour.
Rapport d'incident : j'ai cassé diaspodon.fr
Rédigé par Aucun commentaire
/ /Il y a des jours où la confiance vous embarque bêtement.
Fin février, je me lançais dans la mise à niveau de l'intégralité de l'infrastructure qui propulse les différents services que j'ai sous ma responsabilité : des instances Mobilizon, Peertube, Pixelfed et Mastodon. Une mise à niveau, c'est quand on passe d'une version majeure à une autre d'un système d'exploitation. Ce n'est jamais anodin (update != upgrade).
Étape 1 - 27 février 2022 - 15h45
Après avoir testé avec succès ces mises à niveau sur des serveurs de moindre importance, plein de confiance, je finis par couper diaspodon.fr pour m'en occuper. D'abord, un dump de la base de données PostgreSQL 9.6 puis un snapshot complet des volumes et, hop, la mise à niveau.
Étape 2 - 27 février 2022 - 16h30
Une fois la mise à niveau terminée sans problème, je relance le serveur, teste un ou deux trucs et retourne vaquer à mes occupations passionnantes du moment (coucou TWW3).
Étape 3 - 4 mars 2022 environ
Une semaine plus tard, Greenman me signale qu'on ne peut plus correctement le mentionner (le fameux @ + pseudo). Pas grave, me dis-je, c'est le seul avec ce souci. 48h plus tard, après un week-end chargé, je suis réveillé par des SMS des copains qui signalent tous une inactivité bizarre depuis au moins 9h. C'est cassé.
Étape 4 - 7 mars 2022 - 10h ~ 12h
La documentation était pourtant claire : à la fin de la mise à niveau (cf Étape 1), il fallait impérativement mettre à jour les index des bases de données pour éviter le cauchemar absolu : les duplicated entries. Chose que je n'ai pas faite sans sourciller. Devinez quoi ? J'ai du en virer, de ces cochonneries. Merci encore à Luc pour son aide formidable. Une fois corrigé à la main les dizaines de duplicate, je passe à la mise à jour qui fini par passer.
La tant attendue et redoutée mise à niveau de PostgreSQL 9.6 à PostgreSQL 13 est correctement finalisée. Il était temps.
Étape 5 - 7 mars 2022 - 12h ~ 13h
J'ai l'impression de voir le bout du tunnel quand, finalement, non. Sidekiq, outil nécessaire au fonctionnement de Mastodon, refuse de redémarrer.
Il s'avère, chers ami-e-s, que Debian 11 n'est pas complètement compatible avec la configuration officielle de Mastodon. Cette version de Debian n'a plus les bonnes dépendances pour faire tourner jemalloc, bidule connu des admin d'instance Mastodon pour contrôler la consommation en mémoire du logiciel. Quand, le 28 février, j'ai nettoyé les vieux paquets « inutilisés », j'ai cassé une deuxième fois l'instance.
Une fois compris, j'ai réinstallé les dépendances Ruby de Mastodon en virant l'option RUBY_CONFIGURE_OPTS=--with-jemalloc et l’occurrence dans la configuration du service systemd de sidekiq.
Étape 6 - 7 mars 2022 - 13h15
Sauvé. On est en ligne.
Une conclusion
Lisez la doc, ou Luc, bordel !