replication-manager 3.1 — Ce qui a été livré en 2025 (3.1.1 à 3.1.16)
La branche 3.1 a été lancée en mai 2025 et a livré seize versions jusqu'à la fin de l'année. Ce billet couvre les fonctionnalités majeures visibles pour l'utilisateur : un framework complet de provisionnement applicatif, la gestion des sauvegardes Restic, des outils d'analyse de schémas, une fiabilité améliorée du basculement, et une couche d'authentification renforcée.
Framework de provisionnement applicatif
La 3.1.7 a introduit une couche complète de provisionnement applicatif au-dessus de la gestion des clusters.
Les opérateurs peuvent désormais :
- Provisionner et supprimer des applications directement depuis l'API et l'interface du cluster
- Définir des paramètres de topologie HA par application, avec gestion des ressources par crédits
- Utiliser des dépôts de templates : sauvegarder une configuration en cours d'exécution comme template, restaurer depuis un template, ou cloner depuis un dépôt Git avec support des volumes et sous-chemins
- Monter du stockage S3 et configurer des chemins de stockage par application
- Exécuter des commandes Docker dans la configuration applicative
La 3.1.14 a ajouté le support de scripts post-sauvegarde, permettant de déclencher des actions automatisées après une sauvegarde réussie — utile pour le transfert, la notification, ou le chaînage de pipelines de sauvegarde.
Pourquoi c'est important : Gérer des applications s'appuyant sur MariaDB à grande échelle nécessite plus que l'orchestration des clusters. Le framework de provisionnement place le cycle de vie applicatif — déploiement, configuration, sauvegarde, suppression — sous le même plan de contrôle que la gestion de la réplication.
Gestion des sauvegardes Restic
L'intégration Restic a été progressivement renforcée tout au long du cycle 3.1.
File d'attente de tâches avec contrôle complet du cycle de vie (3.1.16)
La file d'attente de tâches Restic supporte désormais les opérations d'annulation, de pause et de reprise, exposées via des endpoints API dédiés. Les opérateurs peuvent inspecter l'état de la file, mettre en pause des opérations non urgentes et annuler des tâches devenues inutiles sans redémarrer le manager.
Gestion des mots de passe (3.1.11)
Les mots de passe des dépôts Restic peuvent désormais être gérés directement depuis l'API, avec sauvegarde et restauration du fichier de configuration Restic lui-même. Cela comble le risque où un mot de passe perdu rendait un dépôt irrécupérable.
Support de la topologie active-passive (3.1.16)
Les opérations de sauvegarde Restic sont désormais conscientes de la topologie : elles gèrent correctement les configurations active-passive et acheminent les tâches de sauvegarde vers le serveur approprié sans intervention de l'opérateur.
Pourquoi c'est important : Les pipelines de sauvegarde qu'on ne peut pas surveiller ni contrôler sous charge sont un risque. La gestion de la file d'attente, la gestion des mots de passe et la conscience de la topologie transforment Restic d'un outil configuré en un service géré.
Analyse de schémas et ANALYZE persistant
La 3.1.3 a introduit le support de l'analyse persistante : les opérateurs peuvent déclencher ANALYZE TABLE avec persistance entre les redémarrages, configurable par cluster. La fonctionnalité inclut un ACL dédié cluster-analyze et une documentation Swagger.
Un composant DataTable a été ajouté à l'interface avec des fonctionnalités de groupement et d'expansion pour parcourir les résultats d'analyse de schémas.
La 3.1.12 a ajouté des niveaux d'optimisation des logs configurables avec support dans l'interface, et des endpoints API pour vérifier si des tâches d'analyse de schémas doivent être effectuées sur un serveur donné — évitant les analyses redondantes dans les grands clusters.
Pourquoi c'est important : Les statistiques de tables dérivent silencieusement dans les clusters actifs. Une analyse orchestrée et persistante maintient les plans de requêtes optimaux sans intervention manuelle du DBA.
Fiabilité du basculement
Plusieurs versions se sont concentrées sur la réduction des faux positifs et l'amélioration de la justesse du basculement.
Heartbeat et réduction des faux positifs (3.1.4)
Les vérifications de heartbeat pour les réplicas ont été refactorisées pour utiliser des goroutines avec des timeouts de contexte configurables. Le timeout de contexte pour la vérification heartbeat a été augmenté, réduisant significativement les déclenchements de basculement intempestifs dans les environnements avec une latence réseau transitoire.
Compatibilité MySQL 8.4 (3.1.15)
Une incompatibilité d'option mysqlbinlog après les opérations de rejoin sur MySQL 8.4 a été corrigée. Les vérifications du mode SSL ont été mises à jour pour refléter les dépréciations de MySQL 8.0.
Régression de la surveillance des processus (3.1.3)
Une régression de la surveillance des processus affectant les serveurs MySQL antérieurs à la version 8 a été corrigée. Le mode maintenance déclenche désormais correctement l'exécution de scripts bash lors des changements d'état.
Pourquoi c'est important : Les basculements intempestifs sont coûteux — ils causent des indisponibilités inutiles, divisent le trafic et nécessitent une récupération manuelle. Chacun de ces correctifs réduit la probabilité d'un changement de topologie non justifié.
Gestion des logs d'erreurs et de requêtes lentes
La 3.1.10 a ajouté une gestion par cookies pour les opérations de récupération des logs d'erreurs et de requêtes lentes, avec des niveaux de récupération configurables exposés dans le fichier de configuration et l'API. Les niveaux de logs sont ajustables indépendamment pour chaque type de log.
La 3.1.12 a ajouté des endpoints API pour vérifier si un cluster peut récupérer des logs depuis un serveur donné, évitant les tentatives de récupération sur des serveurs indisponibles ou non configurés.
La 3.1.16 a étendu cela avec la configuration du niveau de récupération des logs d'audit et le support du tailer, intégrant les logs d'audit dans le même modèle de gestion que les logs d'erreurs et de requêtes lentes.
Pourquoi c'est important : Dans les environnements réglementés, les logs d'audit sont aussi importants que la santé de la réplication. Une récupération unifiée et configurable par niveau donne aux équipes opérationnelles une interface cohérente quel que soit le type de log.
Améliorations de l'intégration OpenSVC
La 3.1.13 a ajouté l'intégration des composants de charge de travail OpenSVC avec la récupération des statistiques exposée dans les vues Home, Top et cluster. La visualisation de la charge CPU et les vérifications de seuils ont été ajoutées à la carte de nœud OpenSVC.
L'accès aux statistiques OpenSVC est contrôlé par ACL, avec une authentification conditionnelle basée sur le flag UseAPI.
Pourquoi c'est important : Pour les équipes qui font tourner replication-manager sur une infrastructure OpenSVC, une visibilité unifiée sur la consommation de ressources au niveau des nœuds aux côtés de la santé de la base de données réduit le nombre d'outils nécessaires lors d'un incident.
Authentification et sécurité
La 3.1.6 a corrigé le masquage des credentials de scripts dans les sorties de logs — les mots de passe de scripts étaient précédemment visibles en clair sous certaines configurations de logging.
La 3.1.7 a refactorisé le flux d'authentification pour utiliser la gestion d'état Redux avec des souscriptions aux clusters basées sur JWT, supprimant la dépendance au localStorage pour les données de session sensibles.
La 3.1.11 a ajouté le support des variables d'environnement pour le nom d'utilisateur et le mot de passe dans le CLI, permettant l'injection de credentials depuis des gestionnaires de secrets sans exposition dans les fichiers de configuration.
La 3.1.14 a ajouté des vérifications d'immuabilité pour la rotation des mots de passe ProxySQL et MDBS Proxy, empêchant la rotation accidentelle de credentials qui doivent rester stables.
Pourquoi c'est important : Les failles de sécurité dans les orchestrateurs ont un impact élevé — ils se trouvent au-dessus des bases de données de production avec des credentials administratifs. Chacun de ces changements réduit la surface d'attaque et ferme un vecteur concret d'exposition des credentials.
API de gestion des services applicatifs
La 3.1.10 a ajouté des endpoints API pour la gestion du cycle de vie des services applicatifs : actions de démarrage, arrêt et redémarrage des services au sein d'une application provisionnée. Cela permet l'intégration avec des outils d'automatisation externes sans nécessiter d'accès direct à l'infrastructure sous-jacente.
Notes de mise à jour
3.1.4 : Si vous vous appuyez sur le basculement basé sur le heartbeat dans des environnements à haute latence, revoyez la nouvelle configuration du timeout de contexte. Les valeurs par défaut sont conservatrices ; ajustez par cluster si nécessaire.
3.1.7 : La refactorisation de l'authentification déplace l'état de session du localStorage vers Redux. Les utilisateurs avec des outils personnalisés lisant les tokens du localStorage devront s'adapter.
3.1.11 : L'injection de credentials via variables d'environnement dans le CLI est désormais supportée. Revoyez vos scripts de déploiement pour en profiter dans les environnements conteneurisés.
3.1.14 : Les scripts post-sauvegarde sont opt-in. Configurez post-backup-script par cluster si vous souhaitez des actions automatisées après sauvegarde.
replication-manager 3.1.16 est disponible sur GitHub. Les paquets pour les distributions RPM et DEB sont disponibles via le pipeline de release standard.