MariaDB / Changer le répertoire de données sous Ubuntu et Windows
Pour changer l’emplacement des données de MariaDB, arrêtez proprement le serveur, copiez tout le répertoire de données, puis modifiez l’option serveur datadir et les droits d’accès. Modifier uniquement l’option ne déplace pas les bases existantes, et une copie ordinaire pendant le fonctionnement peut être incohérente : prévoyez d’abord une sauvegarde indépendante et une interruption des écritures.
Périmètre et préparatifs
Le répertoire de données contient les bases et les fichiers de gestion des moteurs de stockage. La variable serveur datadir indique son emplacement actuel. Cette procédure concerne une instance autonome, sur le même ordinateur et avec la même version de MariaDB. Une mise à niveau, un changement de système, la réplication, un cluster Galera ou un volume de conteneur exigent un plan distinct.
Connectez-vous avec un compte d’administration MariaDB et conservez les résultats SQL suivants. Sous Ubuntu, sudo mariadb convient généralement à l’authentification locale par socket. Sous Windows, utilisez bin\mariadb.exe -u root -p dans le dossier d’installation. Adaptez le compte si l’authentification de votre instance diffère.
SELECT VERSION(), @@datadir, @@port;
SHOW VARIABLES WHERE Variable_name IN (
'log_error', 'log_bin_basename', 'innodb_data_home_dir',
'innodb_log_group_home_dir', 'aria_log_dir_path'
);
- Sauvegarde indépendante : disposez d’une sauvegarde restaurable ailleurs et vérifiez sa restauration pour les données de production. Garder l’ancien dossier ne remplace pas cette sauvegarde. La présentation des sauvegardes MariaDB distingue les approches logiques et physiques.
- Chemins et capacité : relevez la source réelle et une destination disposant d’assez d’espace. Le chemin Ubuntu
/var/lib/mysql/et la version Windows11.4ci-dessous sont des exemples à remplacer. - Fichiers externes : journaux binaires définis par chemin absolu, tablespaces externes, clés de chiffrement, liens symboliques et points d’analyse Windows nécessitent une vérification séparée. Changer
datadirne déplace pas automatiquement tous les fichiers. - Maintenance : suspendez les écritures applicatives, les tâches planifiées et les mécanismes de redémarrage automatique. Ne rétablissez pas les écritures externes avant la fin des vérifications.
N’exécutez pas mariadb-install-db dans la destination d’une instance existante. Cet outil initialise une nouvelle instance ; ici, il faut copier intégralement les données déjà présentes.
Déplacer le répertoire sous Ubuntu
Identifier la configuration et le montage
Une installation classique par paquets sur Ubuntu 24.04 utilise /etc/mysql/mariadb.conf.d/50-server.cnf, mais cela dépend de l’installation. Examinez les arguments et compléments du service avec systemctl cat, puis les options lues dans les fichiers avec mariadbd --print-defaults. Ne publiez pas une sortie contenant des paramètres sensibles.
sudo systemctl cat mariadb
sudo mariadbd --print-defaults
sudo du -sh /var/lib/mysql
df -h /data
findmnt -T /data
Si /data n’existe pas, préparez et montez d’abord le disque cible. Vérifiez avec df et findmnt qu’il s’agit du bon système de fichiers. La documentation des fichiers d’options MariaDB explique que des options lues plus tard ou des arguments de lancement peuvent remplacer une valeur. Sauvegardez le fichier réellement utilisé par le service avant de le modifier.
Arrêter le serveur et copier toutes les données
L’exemple suppose le service mariadb, le compte système mysql et la destination /data/mariadb/. Installez rsync avant l’arrêt si nécessaire. Après l’arrêt, confirmez l’état inactive et la fin du processus serveur. is-active peut renvoyer un code non nul quand le service est inactif. Ne copiez pas si l’arrêt a échoué ou si une autre instance utilise encore ce répertoire.
sudo systemctl stop mariadb
sudo systemctl is-active mariadb
sudo systemctl status mariadb --no-pager
Utilisez une destination vide, sans mélanger les fichiers d’instances différentes. Les commandes suivantes créent le dossier, fixent son propriétaire et ses droits et copient aussi les fichiers cachés et ceux des moteurs. L’option -a conserve notamment propriétaire et permissions. cp -a peut également préserver les attributs ; une copie simple n’a pas nécessairement le même effet.
sudo mkdir -p /data/mariadb
sudo chown mysql:mysql /data/mariadb
sudo chmod 750 /data/mariadb
sudo rsync -aHAX --numeric-ids /var/lib/mysql/ /data/mariadb/
sudo rsync -aHAXnci --numeric-ids /var/lib/mysql/ /data/mariadb/
Le premier rsync copie réellement ; le second compare par sommes de contrôle sans modifier les fichiers. Vérifiez leur réussite et analysez toute différence annoncée par le second. Le / final de la source signifie « copier le contenu ». Une erreur liée aux ACL, listes de contrôle d’accès, ou aux attributs étendus doit être résolue en examinant le système de fichiers et les options de copie.
Modifier datadir et les règles de sécurité
Modifiez l’entrée datadir existante dans un groupe d’options serveur effectivement lu. Évitez plusieurs entrées contradictoires.
[mysqld]
datadir=/data/mariadb
Un propriétaire correct ne garantit pas à lui seul l’accès. AppArmor limite les accès aux fichiers des programmes sous Linux. Vérifiez les profils actifs et les messages DENIED du journal noyau associés à l’exécutable MariaDB.
sudo aa-status
sudo journalctl -k -b --no-pager
Si le profil réellement appliqué autorise seulement l’ancien chemin, adaptez ses règles locales ou un alias applicable. Le guide MariaDB des échecs de démarrage décrit cet alias dans /etc/apparmor.d/tunables/alias. Vérifiez d’abord que le profil actif utilise ce fichier, sauvegardez-le puis contrôlez la réussite de sudo systemctl reload apparmor. Les profils varient selon les distributions et paquets ; cet alias n’est pas obligatoire partout.
alias /var/lib/mysql/ -> /data/mariadb/,
Dans systemctl cat mariadb, contrôlez aussi ReadWritePaths, ProtectSystem et les autres restrictions. Pour un disque séparé, sudo systemctl edit mariadb permet d’ajouter cette dépendance de montage. Elle ne formate pas le disque et ne remplace pas sa configuration de montage permanent dans /etc/fstab. Consultez l’option RequiresMountsFor de systemd.
[Unit]
RequiresMountsFor=/data/mariadb
L’exemple évite /home et /root, que la politique du service peut bloquer. Si un accès supplémentaire est nécessaire, autorisez précisément le chemin utile plutôt que de désactiver tout le mécanisme de protection. La documentation MariaDB sur systemd détaille ces restrictions.
Démarrer et vérifier le chemin actif
Rechargez le gestionnaire de services si vous avez modifié les paramètres de l’unité, puis démarrez MariaDB. Le résultat SQL doit indiquer /data/mariadb/. Déplacer les données n’oblige pas à modifier aussi le chemin du socket client ; évitez les changements sans rapport.
sudo systemctl daemon-reload
sudo systemctl start mariadb
sudo systemctl status mariadb --no-pager
sudo mariadb -e "SELECT @@datadir;"
Si le démarrage échoue ou si l’ancien chemin apparaît, gardez les applications déconnectées et passez au diagnostic ci-dessous.
Déplacer le répertoire sous Windows
Repérer le service, le compte et my.ini
Exécutez ces commandes dans PowerShell en administrateur pour identifier le nom réel du service, son compte et sa ligne de commande. Remplacez partout MariaDB et la version 11.4 par vos valeurs. Le nom par défaut du guide d’installation MSI sous Windows peut différer du service enregistré.
Get-CimInstance Win32_Service |
Where-Object { $_.PathName -match 'mariadbd|mysqld' } |
Select-Object Name, State, StartName, PathName
sc.exe qc MariaDB
Repérez le my.ini désigné par --defaults-file. Sans cette option, examinez les chemins de recherche affichés par --help --verbose de cet exécutable et les fichiers existants. Activez dans l’Explorateur Afficher → Afficher → Extensions de noms de fichiers afin d’éviter un enregistrement en my.ini.txt. Notez @@datadir et sauvegardez la configuration active ailleurs.
Arrêter le service et copier les fichiers
L’exemple déplace C:\Program Files\MariaDB 11.4\data vers un nouveau dossier vide C:\MariaDB. Confirmez l’état Stopped avant la copie. Si la destination existe, examinez-la d’abord et ne fusionnez pas des données sans rapport.
Stop-Service -Name 'MariaDB'
Get-Service -Name 'MariaDB'
New-Item -ItemType Directory -Path 'C:\MariaDB'
robocopy "C:\Program Files\MariaDB 11.4\data" "C:\MariaDB" /E /COPY:DAT /DCOPY:DAT /R:1 /W:1 /XJ /XF my.ini
$copyExit = $LASTEXITCODE
if ($copyExit -ge 8) { throw "Robocopy failed: $copyExit" }
La commande copie les sous-dossiers mais exclut my.ini, conservé à son emplacement initial. /COPY:DAT copie données, attributs et horodatages ; les permissions sont réglées séparément ensuite. /XJ exclut les jonctions, dont les contenus externes doivent être traités explicitement. La référence Microsoft Robocopy indique qu’un code de retour supérieur ou égal à 8 signale un échec. Pour 0 à 7, examinez aussi les échecs, différences et fichiers supplémentaires inattendus dans le résumé.
Accorder les droits au service et modifier datadir
Dans services.msc, ouvrez Propriétés → Connexion du service concerné. Dans Propriétés → Sécurité → Modifier → Ajouter du dossier cible, accordez le droit Modifier au compte réellement utilisé. Le compte SQL root est distinct du compte Windows exécutant le service. Donner un contrôle total à Everyone est inutile.
N’utilisez l’exemple suivant qu’après avoir confirmé le compte virtuel NT SERVICE\MariaDB. Si le nom du service diffère ou s’il utilise un compte local ou de domaine, adaptez l’identité. (OI)(CI)M accorde une modification héritée par les fichiers et sous-dossiers. Voir la référence Microsoft icacls.
icacls "C:\MariaDB" /grant "NT SERVICE\MariaDB:(OI)(CI)M"
icacls "C:\MariaDB"
Modifiez le groupe serveur existant dans le my.ini initial et enregistrez au même endroit. Les barres obliques évitent les problèmes d’échappement des barres inverses. Laissez --defaults-file pointer vers le fichier initial ; ne déplacez pas aussi la configuration pendant cette opération.
[mysqld]
datadir=C:/MariaDB
Démarrer le service et se connecter
Démarrez MariaDB, puis ouvrez le client. Saisissez le mot de passe à l’invite et non directement après -p dans la commande.
Start-Service -Name 'MariaDB'
Get-Service -Name 'MariaDB'
& 'C:\Program Files\MariaDB 11.4\bin\mariadb.exe' -u root -p
Exécutez SELECT @@datadir; et confirmez C:\MariaDB\ ou sa notation équivalente avec des barres obliques. L’état Running seul ne prouve pas que les bonnes données sont ouvertes.
Vérifier les données et leur persistance
Comparez les bases existantes, les nombres de lignes représentatifs et les valeurs connues à vos relevés précédents. Vérifiez ensuite que le nom de test suivant est libre, puis exécutez le SQL avec une connexion administrative. Sinon, choisissez un autre nom unique et remplacez-le dans toutes les instructions. Ne créez pas d’objets de test dans une base métier.
SELECT @@datadir;
CREATE DATABASE datadir_move_check_13862;
CREATE TABLE datadir_move_check_13862.probe (id INT PRIMARY KEY);
INSERT INTO datadir_move_check_13862.probe VALUES (1);
SELECT * FROM datadir_move_check_13862.probe;
La dernière requête doit retourner une ligne avec id = 1. Gardez les écritures externes bloquées, redémarrez proprement le service une nouvelle fois, reconnectez-vous et lancez :
SELECT @@datadir;
SELECT * FROM datadir_move_check_13862.probe;
Le nouveau chemin et la ligne 1 doivent être conservés. Supprimez uniquement la base de test avec l’instruction suivante, puis vérifiez la connexion applicative et ses lectures et écritures avant de reprendre le trafic. La création d’un simple dossier ne valide pas une migration complète des données InnoDB.
DROP DATABASE datadir_move_check_13862;
Conservez la source jusqu’à la fin des vérifications et selon votre politique de rétention. Mettez les sauvegardes et la supervision à jour pour couvrir le nouvel emplacement.
Diagnostiquer un échec ou un chemin inchangé
- Ancien datadir : vérifiez si le mauvais fichier a été modifié, si une option ultérieure ou un argument remplace la valeur, ou si le client utilise le port ou le socket d’une autre instance.
- Permission denied ou fichier de test impossible à créer : contrôlez le compte du service, les droits de traversée des dossiers parents et l’écriture à destination. Examinez AppArmor et systemd sous Ubuntu, les ACL du compte réel sous Windows.
- Bases ou tables système manquantes : recherchez un niveau de dossier supplémentaire ou une copie incomplète. N’initialisez pas la destination et ne supprimez pas
ibdata1ou les journaux pour tenter de réparer. - Échec après redémarrage du système : vérifiez le montage permanent, l’ordre de démarrage et la stabilité des lettres de lecteur.
Sous Ubuntu, recherchez l’heure et le chemin de l’échec dans les journaux. namei permet d’examiner les permissions de chaque dossier parent.
sudo journalctl -u mariadb -b -n 100 --no-pager
sudo journalctl -k -b --no-pager
namei -l /data/mariadb
sudo systemctl cat mariadb
Sous Windows, consultez l’emplacement log_error, les fichiers .err des anciens et nouveaux dossiers, ainsi que l’Observateur d’événements. Un code général comme l’erreur de service 1067 ne suffit pas à établir la cause. Le diagnostic de démarrage MariaDB fournit des vérifications selon les erreurs.
Quand et comment revenir en arrière
Si les écritures externes n’ont pas encore été autorisées au nouvel emplacement, arrêtez complètement MariaDB puis restaurez la configuration sauvegardée ou la valeur initiale de datadir. Annulez uniquement l’alias AppArmor ou le complément systemd ajouté pour ce déplacement, sans toucher aux autres réglages. Après une modification d’unité, exécutez daemon-reload avant de démarrer, puis vérifiez le chemin d’origine et les données.
Si de vraies écritures ont déjà eu lieu au nouvel emplacement, la source conservée est obsolète. Revenir simplement à son chemin peut perdre ces changements. Bloquez à nouveau les écritures, sauvegardez les données récentes et préparez une migration inverse à l’arrêt ou une restauration adaptée. Ne mélangez pas les fichiers des deux répertoires et ne lancez pas les deux copies simultanément.
