Hier sortait la version 2.0.0 de Mastodon, une version stable majeure qui apportait principalement des nouveautés dans l’UI, comme la gestion des emojis custom. (Et c’est absolument génial).

Cependant il y a aussi une grosse mise à jour concernant la structure de la base de données de Mastodon. Dans le changelog on peut lire ceci :

All id attributes in the REST API responses, including attributes that end in _id, are now returned as strings instead of integers. This is because large integers cannot be encoded in JSON losslessly, and all IDs in Mastodon are now bigint. Some apps will not work with this release until they are updated

Et ceci :

This release includes database migrations, that means you need to run RAILS_ENV=production bundle exec rails db:migrate (in Docker: docker-compose run --rm web rails db:migrate). Depending on your database size, this migration may take a long while! It may also lead to some downtime. Make sure you have backups. This is because we are upgrading a multitude of database columns from int to bigint to make sure they’re future-proof.

En gros de ce que je comprends une bonne partie des données stockées change de type.

Pour ma part la mise à jour de la base de données a pris à peu près 2 heures pour mon instances, mstdn.io, qui est assez grosse, mais encore loin des « piliers » de la fédération :

Après un bon moment à galérer à cause de problèmes dans la base de données, mon instance passe enfin en 2.0.0, et jette un coup d’œil à PgHero (accessible depuis l’admin Mastodon) pour voir si la mise à jour à touché de manière visible à la BDD.

Et là à ma grande surprise :

Ma base de données a plus que doublé en taille, puisqu’elle faisait environ 8 ou 9 GB avant. Et la table statuses fait 11 GB à elle seule !

Je tombe ensuite sur ce toot de @[email protected] qui donne la solution pour alléger la BDD après la mise à jour.

La solution est donc d’exécuter FULL VACUUM sur la base de données (sur la table statuses seule ça suffit, mais tant qu’à faire…).

Son explication :

In the case of the 2.0.0 migration that rewrote a large part of the table this means that the table size got much bigger but also won’t grow for a while. You can use vacuum full to force pg to rewrite the entire table and that is the only thing that can shrink table size in postgres (apart from truncate and drop database 😉 ).

Avant tout chose il est préférable de sauvegarder la BDD :

pg_dump -U mastodon mastodon_production > mastodon_bck

Ensuite on se connecte à PostgreSQL sur la base avec notre utilisateur (à adapter selon votre setup, donc), et on lance le nettoyage sur toute la BDD :

psql -d mastodon_production -U mastodon -c "VACUUM FULL"

Pour cela a pris moins de 10 minutes, mais cela peut varier selon votre BDD et la puissance de votre serveur. Aussi, cette opération lock la BDD donc votre instance sera indisponible jusqu’à qu’elle soit terminée.

Pour ma part, j’ai dû redémarrer les services Mastodon après la fin du nettoyage :

systemctl restart "mastodon*"

Résultat : la BDD prend presque 3 fois moins d’espace, c’est à dire même moins qu’avant la mise à jour !

Le changement le plus bluffant est bien sûr sur la table statuses, mais toutes les autres tables ont été aussi nettoyées.

Voilà donc la petite astuce du jour pour ceux qui gèrent des instances Mastodon, le gain de place peut être assez énorme suivant la taille de celles-ci. Même sur les plus petites bases, c’est très efficace !

Et pour ceux qui n’y sont toujours pas, on vous attends !