replication-manager 3.1 — Les nouveautés de 3.1.17 à 3.1.22

La branche 3.1 a considérablement mûri en six versions. Ce billet résume les fonctionnalités majeures livrées entre 3.1.17 et 3.1.22 : surveillance des schémas, pipeline de sauvegarde Restic prêt pour la production, vérification de la cohérence des tables, et outillage opérationnel pour les DBAs et les équipes SRE.

Surveillance des schémas et détection des dérives

Depuis la 3.1.17, replication-manager surveille les différences de schémas entre le maître et les réplicas — tables, colonnes et index. La fonctionnalité s'intègre avec la couche shardproxy et expose les divergences avant qu'elles ne deviennent des échecs de réplication ou des incohérences applicatives.

La 3.1.21 a considérablement renforcé cette fonctionnalité :

• Les scans de schémas chargent désormais les métadonnées en bloc avec des CRC structurés, réduisant la pression de verrouillage sur les serveurs surveillés
• Un timeout de scan configurable empêche les requêtes de métadonnées intempestives d'impacter le trafic de production
• Une fuite de mot de passe dans les logs de scan de schéma a été corrigée
• Le scan est automatiquement ignoré lorsque le shardproxy n'est pas utilisé, supprimant toute surcharge inutile (3.1.19)

Pourquoi c'est important : La dérive de schéma entre maître et réplicas est une source fréquente et silencieuse d'échecs de réplication. La détecter de manière proactive — avant qu'une requête n'échoue — donne aux opérateurs le temps d'agir.

Checksum et réparation des tables

La 3.1.18 a introduit la planification du checksum des tables avec gestion du cache de schéma et interrogation bornée. Les versions 3.1.21 et 3.1.22 ont étendu la fonctionnalité de façon significative :

• Support des clés primaires multi-colonnes avec conditions de plage correctes et validité des clés min/max par chunk
• Utilisation de requêtes préparées pour l'efficacité du checksum et parcours forcé par clé primaire
• Tri déterministe des tables de shards par taille
• Opérations de réparation par chunk (3.1.22) : répare les chunks divergents directement depuis le schéma de référence via une table temporaire
• Support des ACL pour les opérations de réparation globale
• Alertes à la fin des opérations de réparation

Pourquoi c'est important : Le checksum à grande échelle exige de la justesse avec les clés composites et de l'efficacité sous charge. Le workflow de réparation ferme la boucle — détecter la divergence, puis la corriger, sans intervention manuelle.

Pipeline de sauvegarde Restic

L'intégration Restic a reçu le plus grand nombre de développements sur ce cycle de versions. Le pipeline est désormais prêt pour la production, aussi bien pour des backends locaux que cloud.

Améliorations du backend S3 (3.1.22)

• Endpoint AWS et préfixe configurables pour les stores S3 compatibles privés
• Support du force-init pour les dépôts existants
• Contrôle du mode append par dépôt
• Le mode append est correctement ignoré pour les backends AWS S3 natifs

Surcharges par variables d'environnement (3.1.19)

Des surcharges supplémentaires par variables d'environnement permettent un contrôle fin de la configuration S3 et des backends personnalisés sans modifier les fichiers de configuration — utile dans les déploiements conteneurisés où les secrets sont injectés à l'exécution.

Suivi de la progression (3.1.22)

• Affichage d'une barre de progression dans le suivi des tâches
• Exposition de la progression via l'API pour l'intégration avec les outils de monitoring externes
• Format legacy de l'API de snapshots supporté via ?format=legacy pour les outils existants

Support du montage multi-plateforme (3.1.21)

Le démontage Restic fonctionne désormais sur toutes les plateformes. Les répertoires de montage sont sélectionnables par l'administrateur sous contrôle strict des chemins, éliminant les conflits de permissions des versions précédentes.

Affichage lisible des tailles de sauvegardes

Les tailles des sauvegardes sont désormais affichées dans un format lisible par l'humain, aussi bien dans les réponses API que dans les tableaux de l'interface.

Pourquoi c'est important : Un système de sauvegarde que l'on ne peut pas surveiller ni intégrer est un risque. La visibilité sur la progression, la flexibilité S3 et l'affichage lisible réduisent l'écart opérationnel entre « les sauvegardes sont configurées » et « les sauvegardes sont fiables ».

Splitdump : découpage des sauvegardes logiques

La 3.1.17 a introduit l'outil CLI splitdump. La 3.1.18 l'a intégré pleinement dans les workflows de sauvegarde des clusters.

Fonctionnalités clés :

• Taille de shard configurable depuis l'interface et par cluster
• Gestion du GTID lors de la restauration, pour que les réplicas se reconnectent correctement
• Résilience aux tables manquantes : la restauration continue malgré les tables absentes plutôt que d'avorter
• Suppression des binlogs pendant la restauration pour éviter l'amplification des événements
• Helpers de préambule et identification des fichiers de schéma pour un ordre de restauration correct
• Flux de réensemencement logique asynchrone : workflows de restauration renforcés pour un re-seeding plus sûr des réplicas
• Exposition du tuning pgzip : compression parallèle configurable pour les performances sur les gros jeux de données
• Suppression des sauvegardes locales pour libérer de l'espace disque après restauration

Pourquoi c'est important : Les grandes sauvegardes logiques sont difficiles à paralléliser et à restaurer sélectivement. Splitdump résout les deux problèmes — les dumps fragmentés permettent une restauration parallèle et une récupération sélective des tables sans outils tiers.

Surcharge des variables et dérive de configuration

Un système de variables préservées à trois niveaux permet des surcharges manuelles et contrôlées des variables de base de données, avec des indicateurs visuels dans l'interface. Le champ HasConfigDiff et l'onglet Variables permettent aux opérateurs de voir en un coup d'œil quelles variables s'écartent de la configuration attendue.

Pourquoi c'est important : En production, les variables dérivent dans le temps — correctifs urgents, modifications d'urgence, recommandations fournisseurs. Suivre cette dérive dans l'orchestrateur donne aux DBAs un seul endroit pour l'auditer et la corriger.

Nombre de tentatives de reconnexion au maître

Le nombre de tentatives de reconnexion au maître de réplication est désormais configurable depuis le fichier de configuration et depuis l'interface. Ce paramètre contrôle combien de fois un réplica tente de se reconnecter avant de déclarer le maître perdu.

Pourquoi c'est important : Dans les environnements réseau instables, la valeur par défaut entraîne des basculements prématurés. Ajuster ce paramètre par cluster évite des changements de topologie inutiles.

Images Docker sans privilèges

Toutes les variantes d'images Docker disposent désormais d'une version rootless s'exécutant en tant qu'utilisateur non-root repman avec UID/GID fixe 10001:10001.

Pour utiliser les images rootless avec des volumes montés :

sudo chown -R 10001:10001 /chemin/vers/data /chemin/vers/config

Pourquoi c'est important : Les exigences de sécurité des conteneurs dans les environnements réglementés ou multi-tenants imposent une exécution sans privilèges. Un UID/GID fixe garantit des permissions cohérentes entre les hôtes et les reconstructions d'images.

Correctifs notables

• Compatibilité MyDumper : gestion des flags selon la version, plus d'échecs silencieux de restauration en environnement mixte
• Démarrage de l'arbitrateur : ne plante plus si le répertoire de sauvegarde de configuration est absent
• Prévention des injections SQL : le package dbhelper réécrit avec des requêtes paramétrées et une couche d'abstraction des vendors
• CVE-2025-12421 Mattermost : vulnérabilité de prise de contrôle de compte corrigée
• Analyse des tables : injection SQL bloquée dans les identifiants qualifiés, noms multi-points rejetés (3.1.19)
• Deadlock dans la purge Restic éliminé (3.1.18)

Notes de mise à jour

Docker rootless : vérifiez la propriété des volumes avant de passer aux images rootless.

Restic S3 : les nouveaux champs endpoint et préfixe sont optionnels. Les configurations existantes continuent de fonctionner sans modification.

Splitdump : la taille de shard par défaut s'applique par cluster. Revoyez le nouveau contrôle dans l'interface pour l'aligner avec vos exigences de stockage et de SLA de restauration.

Surveillance des schémas : le timeout de scan est configurable. Définissez-le en fonction de la taille de vos plus grandes tables pour éviter des délais dans la boucle de monitoring.

replication-manager 3.1.22 est disponible sur GitHub. Les paquets pour les distributions RPM et DEB sont disponibles via le pipeline de release standard.