SxMDBSync 1.2 : synchroniser des bases MariaDB et MySQL par SSH

SxMDBSync

SxMDBSync est un outil Bash sous licence GPL qui synchronise une ou plusieurs bases MariaDB ou MySQL entre deux serveurs en faisant transiter le dump directement dans une connexion SSH.

Il est fait pour les migrations et les synchronisations maîtrisées, pas pour installer une réplication permanente. Aucun gros fichier SQL intermédiaire n’est nécessaire : les données sont exportées, transportées puis importées dans le même flux.

Antesync et retrosync

Les deux méthodes décrivent le sens du transfert par rapport à la machine depuis laquelle la commande est lancée :

– antesync envoie les bases locales vers le serveur distant ;
– retrosync récupère les bases distantes vers la machine locale.

Envoyer une base locale :

./sxmdbsync.sh \
  --method antesync \
  --user root \
  --host 192.0.2.10 \
  --database production

Récupérer une base distante :

./sxmdbsync.sh \
  --method retrosync \
  --user root \
  --host 192.0.2.10 \
  --database production

Le port SSH par défaut est 65022. Il peut être changé avec --port. L’option --ssh-option est répétable pour ajouter des options ssh -o.

Sélection et changement de nom

--database peut être répété pour synchroniser plusieurs bases. La forme SOURCE:CIBLE permet de changer le nom à l’arrivée :

./sxmdbsync.sh -m retrosync -u root -H 192.0.2.10 \
  --database production:staging \
  --database reporting

--all-user-databases sélectionne toutes les bases non système présentes du côté source. Les bases information_schema, performance_schema, mysql et sys sont exclues.

Attention : la cible est réinitialisée par défaut

Par défaut, SxMDBSync supprime puis recrée chaque base cible avant l’import. Ce comportement est volontaire : une vraie synchronisation doit également faire disparaître de la cible les tables qui n’existent plus dans la source. Le script vérifie que la base a bien disparu après le DROP DATABASE, puis qu’elle existe bien après le CREATE DATABASE, avant d’envoyer les données.

Cette opération détruit donc le contenu précédent de la base cible. Vérifiez le sens antesync ou retrosync, le serveur, les noms source/cible et vos sauvegardes avant de lancer la commande.

L’option --no-reset-target désactive cette réinitialisation et importe dans la base existante, ou la crée si elle n’existe pas. C’est utile quand le compte SQL n’a pas le droit de recréer le schéma, mais ce mode ne garantit plus un miroir strict.

Toujours commencer par un dry-run

--dry-run, ou -n, affiche le plan des opérations sans effectuer les suppressions, créations ou imports :

./sxmdbsync.sh \
  --method antesync \
  --user deploy \
  --host db.example.net \
  --database production:production \
  --dry-run

Avec --all-user-databases, le dry-run doit tout de même interroger la source afin d’établir la liste réelle des bases concernées. Il ne faut donc pas le confondre avec une simple validation hors connexion.

Identifiants et fichiers secrets

SxMDBSync sait utiliser l’authentification locale par socket lorsqu’il est lancé par root, ainsi que ~/.my.cnf pour un utilisateur non privilégié. Le même principe s’applique sur la machine distante selon l’utilisateur SSH.

Pour une configuration explicite, utilisez de préférence :

– --local-db-cnf et --remote-db-cnf pour des fichiers de configuration MariaDB/MySQL ;
– --local-db-pass-file et --remote-db-pass-file pour des fichiers ne contenant que le mot de passe.

Les fichiers de mots de passe doivent être réguliers, ne pas être des liens symboliques, appartenir à l’utilisateur courant et n’être accessibles ni au groupe ni aux autres utilisateurs. Les options historiques --local-db-pass et --remote-db-pass existent encore, mais placent le secret dans les arguments visibles du processus : ne les utilisez pas pour une automatisation normale.

Garde-fous

La version 1.2 valide les noms de bases, les utilisateurs, l’hôte et le port ; refuse les correspondances de cibles en double ; protège son exécution avec un verrou ; vérifie les fichiers sensibles ; détecte les clients MariaDB ou MySQL disponibles ; et s’arrête dès qu’une étape critique échoue.

Le journal est écrit par défaut dans ~/sxmdbsync.log. La variable SXMDBSYNC_LOG permet de changer son emplacement.

Ressources

Script : sxmdbsync.sh

—
Christophe Casalegno (retrouvez tous mes liens, mes projets et mes réseaux sur all.bo)