Consolidation des bases — 6 instances vers 1
Contexte
Le nœud Pi4 héberge la majorité des services « données » de l'atelier : capteurs santé, agenda, projets, knowledge base, music intel, dashboards. Au fil du temps, six instances MariaDB distinctes avaient été créées — une par sous-projet, démarrée comme un container isolé. Le résultat : 91 % de RAM occupée en stable, swap qui montait, et plus aucune marge pour ajouter un nouveau service.
Contrainte
La règle d'or de l'atelier : jamais de coupure visible côté services consommateurs. Plusieurs apps écrivent en permanence (santé, ntfy, dashboards), un redémarrage brutal aurait été détecté en quelques secondes par les sondes externes.
Contrainte additionnelle, apprise à la dure :
sur Pi4 saturé, un docker restart peut crasher
sshd. Donc pas de redémarrage de masse, on travaille
instance par instance.
Décision
Plutôt que d'optimiser six moteurs, on en garde un seul —
mln-mariadb — et on rapatrie les six bases dedans,
chacune avec son utilisateur dédié et ses droits restreints.
Migration progressive, base par base, avec la procédure :
mysqldump→ fichier sur disque externe- Création de la base et de l'utilisateur sur
mln-mariadb - Restauration
mysql < dump.sql - Bascule de la chaîne de connexion côté app (variable d'env)
- Vérification fonctionnelle 24 h avant suppression de l'ancienne instance
Mesure
Avant : 6 instances MariaDB, 91 % de RAM occupée, swap actif en permanence. Après : 1 instance, 47 % de RAM occupée, swap au repos, latence des requêtes inchangée. Les sondes externes n'ont rien vu.
Ce qu'il en reste
Côté apprentissage : une procédure de migration éprouvée, réutilisable pour des consolidations équivalentes (Postgres, Redis). Côté ops : un seul moteur à sauvegarder, à patcher, à surveiller. Côté capacité : assez de marge pour absorber les deux services suivants (knowledge api + meilisearch) sans racheter de matériel.