Sauvegardes MariaDB
mariadb-dump vs mydumper / myloader : quel outil de dump logique choisir ?
Les deux produisent un dump SQL logique. La différence se joue sur le parallélisme, la restauration partielle et le temps qu'il faut pour remettre une base en ligne. Voici quand garder mariadb-dump et quand passer à mydumper / myloader.
Dump logique ou sauvegarde physique : situer la question
Pour la sauvegarde de production d'une grosse base, la réponse est souvent ni l'un ni l'autre : une sauvegarde physique avec mariabackup restaure beaucoup plus vite qu'un dump SQL. Nous détaillons ce choix dans mysqldump vs mariabackup : temps de restauration réels.
Le dump logique redevient souvent le bon outil quand il faut changer de moteur, d'hébergeur ou sauter plusieurs versions : migration MySQL vers MariaDB, sortie d'AWS RDS où la sauvegarde physique n'est pas accessible, reconstruction propre d'une base lors d'une montée de version (qui peut aussi se faire en place). C'est là que le choix entre mariadb-dump et mydumper compte.
mariadb-dump ou mysqldump : c'est le même outil
Depuis MariaDB 10.5, l'outil s'appelle mariadb-dump et mysqldump n'est plus qu'un alias de compatibilité, déprécié depuis MariaDB 11.0 et absent de certaines installations (l'image Docker officielle, par exemple). Les options sont les mêmes : utilisez le nom mariadb-dump dans vos scripts.
À ne pas confondre avec le mysqldump de MySQL 8, qui est un binaire différent. Utilisé contre un serveur MariaDB, il peut échouer sur des requêtes propres à MySQL (typiquement les statistiques de colonnes, à désactiver avec --column-statistics=0). Règle simple : dumpez un serveur MariaDB avec le client MariaDB.
mariadb-dump : simple, déjà là, séquentiel
mariadb-dump lit les tables une par une et écrit un flux SQL (CREATE TABLE puis INSERT). Avec --single-transaction, il ouvre une transaction cohérente sur InnoDB sans bloquer les écritures pendant l'export.
Ses atouts : il fait partie des outils clients MariaDB, en général installés avec le serveur, et le fichier produit est du SQL lisible, facile à rejouer ou à inspecter. Pour un dump du schéma seul (--no-data), un export ponctuel ou une base de quelques Go, il n'y a pas de raison d'aller chercher plus loin.
Sa limite : en dump SQL classique, tout est séquentiel, à l'export comme à la restauration. Le client rejoue le fichier sur une seule connexion, table après table, index après index, même sur un serveur à 16 cœurs. Et pour récupérer une seule table dans un fichier de 200 Go, le plus sûr est de restaurer le dump sur une instance à part puis de réexporter la table. Depuis MariaDB 11.4 et 11.5, --parallel avec --tab ou --dir exporte plusieurs tables à la fois, rechargées ensuite par mariadb-import --parallel (et --dir depuis 11.6) : c'est un autre format (définitions SQL et données tabulées) que le fichier SQL unique.
mydumper / myloader : le dump logique parallèle
mydumper est un projet open source qui exporte plusieurs tables en même temps, avec un thread par table ou par tranche de table. Dans son mode par défaut, il pose un verrou global, ouvre un snapshot transactionnel cohérent partagé par tous ses threads, puis relâche le verrou : si tout est en InnoDB, ce verrou est bref (mais il attend la fin des requêtes longues en cours, et bloque les écritures pendant ce temps) et l'export se poursuit sans bloquer l'application. Les tables non transactionnelles (MyISAM, Aria) le prolongent pendant leur export.
Le résultat est un répertoire : un fichier de schéma et un ou plusieurs fichiers de données par table, plus un fichier metadata qui contient la position binlog et le GTID au moment du snapshot, quand les binlogs sont actifs sur la source. Les grosses tables sont découpées en tranches (--rows), ce qui permet de les recharger en parallèle.
myloader fait le chemin inverse, avec plusieurs threads. Les versions récentes savent créer les tables sans leurs index secondaires, charger les données, puis ajouter les index à la fin (--optimize-keys) : sur une base très indexée, c'est souvent là que se trouve le plus gros gain, à mesurer sur vos données.
Les contreparties : c'est un paquet à installer (les versions des distributions ont souvent plusieurs versions de retard sur GitHub), le format (des fichiers SQL) se recharge à la main en théorie, mais c'est myloader qui gère l'ordre et les dépendances, et le gain dépend de la forme de la base. Une base dominée par une seule table géante, sans découpage en tranches, reste limitée par cette table.
Comparatif côte à côte
Même famille d'outils (dump SQL logique), mais pas le même usage.
| Critère | mariadb-dump | mydumper / myloader |
|---|---|---|
| Parallélisme (dump) | Séquentiel pour un dump SQL ; parallèle seulement avec --tab / --dir (--parallel, MariaDB 11.4+ / 11.5+) | Multi-thread, un thread par table ou par tranche |
| Parallélisme (restauration) | Une seule connexion (mariadb < dump.sql) ; mariadb-import --parallel pour les exports --tab / --dir | Multi-thread avec myloader |
| Format produit | Un fichier SQL (ou --tab par table) | Un répertoire : un fichier de schéma + des fichiers de données par table, plus un fichier metadata |
| Cohérence | --single-transaction (InnoDB) | Verrou global (bref si tout est en InnoDB), puis un snapshot cohérent partagé par tous les threads |
| Grosses tables | Exportées d'un bloc | Découpées en tranches (--rows), restaurées en parallèle |
| Restaurer une seule table | L'extraire du fichier (sed/awk) ou refaire un dump | Natif : on prend les fichiers de la table |
| Coordonnées de réplication | --master-data / --gtid dans l'en-tête du dump | Position binlog / GTID dans le fichier metadata, si les binlogs sont actifs |
| Disponibilité | Fait partie des outils clients MariaDB, en général installés avec le serveur | Paquet séparé, versions des distributions souvent en retard |
| Portabilité du résultat | Du SQL, mais les dumps récents commencent par une ligne « sandbox » que les anciens clients et le client MySQL refusent | Du SQL aussi, mais myloader gère l'ordre et les dépendances |
| Pour qui | Petites bases, exports ponctuels, dump du schéma seul | Dumps logiques de dizaines à centaines de Go, migrations où la sauvegarde physique est impossible |
Les commandes de base
Exemples minimaux à adapter (identifiants, bases, compression). Vérifiez les options disponibles dans votre version de mydumper.
mariadb-dump : export complet (cohérent pour InnoDB), avec coordonnées de réplication
mariadb-dump --single-transaction --routines --events \
--master-data=2 --gtid --all-databases \
| zstd -T0 > full-$(date +%F).sql.zstmydumper : export parallèle sur 8 threads, grosses tables découpées
mydumper --threads 8 --rows 500000 --compress \
--routines --events --triggers \
--outputdir /backup/dump-$(date +%F)myloader : restauration parallèle
# --drop-table: recent versions / --overwrite-tables: older ones
myloader --threads 8 --drop-table --optimize-keys \
--directory /backup/dump-2026-09-28Quel outil pour quelle situation ?
Base de quelques Go, export ou copie ponctuelle
mariadb-dump. Rien à installer, un fichier SQL lisible.
Dump du schéma seul, revue ou diff de structure
mariadb-dump --no-data.
Montée de version majeure sur une base de plusieurs dizaines de Go
mydumper / myloader. La restauration parallèle raccourcit la fenêtre de bascule.
Sortie d'AWS RDS ou d'un DBaaS sans accès aux fichiers
mydumper / myloader, suivi d'une réplication pour rattraper l'écart avant la bascule.
Restaurer une table supprimée par erreur
mydumper, si vos dumps sont faits avec : on ne recharge que la table concernée.
Sauvegarde de production d'une grosse base
Ni l'un ni l'autre en premier : mariabackup, avec un dump logique en complément.
Pièges fréquents
- Oublier les routines, événements et triggers :
--routines --eventscôté mariadb-dump, options équivalentes côté mydumper. Si l'application s'appuie sur des procédures stockées, un dump sans elles ne la remet pas en marche. - Restaurer un dump MariaDB récent avec un vieux client ou le client
mysqlde MySQL : la première ligne (mode « sandbox ») les fait échouer. Restaurez avec un clientmariadbà jour, ou retirez cette ligne en connaissance de cause. - Utiliser
--single-transactionavec des tables MyISAM ou Aria : elles ne sont pas couvertes par le snapshot et peuvent être incohérentes. - Lancer un DDL (
ALTER TABLE) pendant le dump : il casse la cohérence ou bloque l'export. - Dumper sur le primaire en pleine charge : faites-le sur un réplica quand vous en avez un.
- Ne jamais tester la restauration. Un dump qui n'a jamais été rechargé n'est pas une sauvegarde.
Ce que nous faisons chez RDEM Systems
Sur les serveurs que nous infogérons, la sauvegarde combine des snapshots ZFS, une sauvegarde de la VM vers Proxmox Backup Server et un dump SQL quotidien (mysqldump / mariadb-dump) piloté par Signal18 Replication Manager : c'est ce dump qui sert de filet portable, restaurable sur n'importe quel serveur compatible. Le détail est sur notre page sauvegardes MariaDB.
Pour une migration volumineuse (MySQL vers MariaDB, sortie d'AWS RDS), c'est mydumper / myloader que nous recommandons, avec une règle simple : mesurer le temps de chargement réel sur une copie avant de fixer la fenêtre de bascule, plutôt que de l'estimer.
Questions fréquentes
Quelle différence entre mariadb-dump et mysqldump ?
Sur MariaDB, aucune : depuis MariaDB 10.5, mysqldump est un alias de mariadb-dump, déprécié depuis 11.0 et absent de certaines installations. Le mysqldump fourni avec MySQL 8 est un autre binaire, qui peut échouer contre un serveur MariaDB (statistiques de colonnes notamment).
mydumper est-il compatible avec MariaDB ?
Oui, mydumper et myloader fonctionnent avec MariaDB comme avec MySQL. Utilisez une version récente depuis les releases GitHub : celles des distributions sont souvent anciennes.
mydumper remplace-t-il mariabackup ?
Non. mydumper reste un dump logique : la restauration rejoue du SQL et reconstruit les index. Pour restaurer vite une grosse base de production, la sauvegarde physique (mariabackup) reste plus rapide. mydumper sert quand il faut un format portable.
Combien de threads donner à mydumper et myloader ?
En pratique, un point de départ est le nombre de cœurs disponibles, en surveillant les I/O disque et la charge du serveur source. Ajustez ensuite par la mesure : si quelques tables concentrent l'essentiel du volume, ajouter des threads n'apporte presque rien sans découpage en tranches (--rows).
Une migration ou une montée de version à préparer ?
On mesure le temps réel de dump et de restauration sur une copie de votre base avant de fixer la fenêtre de bascule.
Démarrez votre projet MariaDB infogéré
Discutons de vos besoins en bases de données. Notre équipe DBA vous conseille sur l'architecture optimale pour votre cas d'usage.
RDEM Systems SAS — SIREN 820 338 671 — 5 B rue des Noyers, 95300 Pontoise