Installer MariaDB dépend surtout de l’usage prévu. Sur un serveur Linux, une installation native convient bien à un service durable ; sur Windows ou macOS, elle facilite le développement local ; avec Docker, elle permet de lancer une instance isolée et reproductible.
Le choix n’est pas qu’une affaire de confort : il détermine où résident les fichiers, comment les mises à jour sont appliquées et ce qu’il faudra sauvegarder en cas de panne.
Pour éviter les mauvaises surprises, mieux vaut distinguer la base de données de l’application qui s’y connecte. Une instance de test peut tourner sur un poste de travail, mais un serveur de base de données en production demande une configuration MariaDB suivie : comptes limités, accès réseau maîtrisés, stockage persistant et sauvegardes vérifiées.
Les commandes ci-dessous couvrent les principales plateformes et précisent les points à contrôler après l’installation.
En bref
- Linux : installer MariaDB avec la gestion des paquets de la distribution, puis activer le service.
- Windows et macOS : utiliser les installateurs ou outils propres à chaque plateforme et vérifier le service avant de connecter une application.
- Docker : préférer une version identifiée, un volume persistant et un fichier Compose aux commandes temporaires.
- Dans tous les cas : protéger le compte administrateur, limiter l’exposition réseau et tester les sauvegardes.
Installer MariaDB sur Linux avec les paquets de la distribution
Sur un serveur Linux, la gestion des paquets reste le choix le plus simple à maintenir. Le gestionnaire de paquets installe le serveur, les outils clients et les dépendances adaptées à la distribution. Pour une machine Debian ou Ubuntu, commencez par actualiser l’index des paquets, puis installez le service :
sudo apt update
sudo apt install mariadb-server
Sur une distribution fondée sur Red Hat, comme AlmaLinux ou Rocky Linux, la commande équivalente utilise DNF :
sudo dnf install mariadb-server
Les dépôts disponibles et les versions proposées varient selon la distribution et sa politique de maintenance.
Pour une application métier, vérifiez la version fournie avant l’installation ; évitez d’ajouter un dépôt tiers uniquement pour obtenir un numéro plus récent sans avoir validé sa provenance et son cycle de support.
Une fois le paquet installé, vérifiez l’état du service. Sur la plupart des systèmes utilisant systemd, le nom du service est mariadb :
sudo systemctl enable –now mariadb
sudo systemctl status mariadb
La première commande active le démarrage automatique et lance immédiatement le serveur. La seconde permet de confirmer qu’il tourne ; si le service est en échec, consultez les journaux avec sudo journalctl -u mariadb. Un statut actif ne prouve pas encore que les comptes et les droits correspondent au besoin, mais il confirme que le moteur est démarré.
Vérifier l’accès et durcir l’installation Linux
Sur une installation locale, l’accès administrateur passe souvent par l’authentification système, sans mot de passe MariaDB saisi dans le terminal. Essayez :
sudo mariadb
Si l’invite MariaDB s’affiche, le serveur répond. La commande SELECT VERSION(); permet ensuite de contrôler la version chargée. Pour quitter le client, utilisez QUIT;. La configuration initiale peut être durcie avec l’outil fourni par le paquet :
sudo mariadb-secure-installation
Les questions proposées dépendent de la version. L’outil aide notamment à retirer certains réglages de démonstration et à traiter les comptes ou bases préinstallés. Lisez chaque choix plutôt que d’accepter mécaniquement une série de réponses : sur les versions récentes, l’authentification locale de l’administrateur peut déjà s’appuyer sur le compte système, et modifier son fonctionnement sans nécessité peut compliquer l’administration.
Pour une application, créez un compte dédié et accordez-lui uniquement les droits requis sur sa base. Un compte applicatif ne devrait pas utiliser le compte root : une fuite du fichier de configuration de l’application donnerait alors un accès trop large. Dans une petite PME, ce cloisonnement évite aussi qu’un outil de test puisse modifier les bases d’un autre service.
Par défaut, une base destinée à la même machine n’a pas besoin d’être accessible depuis Internet. Avant d’ouvrir le port 3306 dans un pare-feu, vérifiez la directive d’écoute dans la configuration et définissez les adresses autorisées. Une règle réseau ne remplace pas les permissions SQL ; les deux couches doivent être cohérentes.
Sur Linux, l’installation par paquets est généralement le meilleur point de départ pour un service suivi par l’équipe système : les mises à jour et le démarrage restent intégrés aux outils de la distribution.
Installation MariaDB sur Windows et macOS pour le développement
Sur un poste de travail, l’objectif est souvent de disposer d’une base locale pour développer ou tester une application. L’installation MariaDB doit alors rester distincte des données de production : une base de test peut être supprimée ou recréée, mais elle ne doit jamais contenir par inadvertance des données client non anonymisées.
Installer MariaDB sur Windows
Sous Windows, téléchargez l’installateur MSI depuis le site officiel MariaDB et choisissez une version adaptée au projet. L’assistant propose les composants serveur et client, ainsi que la configuration du service. Définissez un mot de passe administrateur robuste pendant l’installation et notez le port configuré, généralement 3306.
Si l’option de service est activée, MariaDB démarre avec Windows. Vous pouvez contrôler son état dans l’application Services, ou depuis PowerShell avec les commandes de gestion des services. Le nom exact peut dépendre de la version installée ; vérifiez-le dans la liste plutôt que de supposer qu’il est identique sur toutes les machines.
Le client en ligne de commande est utile pour valider l’installation. Depuis un terminal où le chemin du programme est accessible, connectez-vous en demandant le mot de passe de façon interactive :
mariadb -h 127.0.0.1 -P 3306 -u root -p
L’option -p déclenche une demande de mot de passe sans l’inscrire dans l’historique de commande. C’est préférable à une commande contenant directement le secret, qui pourrait rester visible dans l’historique du terminal ou dans la liste des processus.
Pour un environnement de développement, créez une base et un utilisateur spécifiques au projet. Les interfaces comme DBeaver ou HeidiSQL peuvent simplifier l’exploration des tables, mais elles ne changent rien aux permissions accordées au compte. Une connexion graphique avec un compte administrateur reste une mauvaise habitude, même sur un poste individuel.
Installer MariaDB sur macOS
Sur macOS, Homebrew permet d’installer et de gérer MariaDB depuis le Terminal. Après avoir vérifié que Homebrew est présent et à jour, lancez :
brew install mariadb
Le démarrage du service peut se faire à la demande ou automatiquement à l’ouverture de session. Pour le lancer en arrière-plan avec Homebrew :
brew services start mariadb
Vérifiez ensuite l’accès avec mariadb -u root ou en précisant l’hôte local si votre configuration le demande. Le comportement d’authentification dépend de la version et de la méthode d’installation ; si la connexion échoue, consultez le message exact et les instructions affichées par les outils plutôt que de réinitialiser le mot de passe à l’aveugle.
Un point pratique : macOS peut déjà héberger d’autres outils qui utilisent le port 3306. Si MariaDB ne démarre pas, vérifiez d’abord qu’un autre service n’occupe pas ce port. Changer le port est possible, mais il faut alors le reporter dans les paramètres de connexion de chaque application.
Windows et macOS conviennent bien aux tests locaux. Pour une équipe, documenter la version du serveur et les paramètres de connexion évite le classique « chez moi, ça marche » quand deux postes n’exécutent pas le même moteur.
Déployer MariaDB avec Docker et conserver les données
Docker est pratique pour lancer rapidement une instance isolée, notamment dans un laboratoire, un environnement d’intégration ou un projet de développement. La conteneurisation permet de séparer MariaDB des paquets installés sur le système hôte et de reproduire plus facilement une configuration sur plusieurs machines. Elle ne dispense toutefois pas de gérer les mises à jour, les secrets et les sauvegardes.
Il faut d’abord disposer du moteur Docker en fonctionnement. Sur Windows et macOS, Docker Desktop fournit l’environnement courant ; sur Linux, Docker Engine peut être installé selon les instructions officielles de la distribution. Vérifiez le client avec docker version et assurez-vous que la commande peut contacter le moteur.
Pour éviter qu’une mise à jour de l’étiquette latest change le serveur sans contrôle, choisissez une branche précise, par exemple mariadb:11.4 si elle correspond aux exigences de votre application et à sa politique de support. Téléchargez l’image avec :
docker pull mariadb:11.4
Le mot de passe administrateur ne doit pas être une valeur évidente comme « password ». Pour un essai local, créez un secret aléatoire et évitez de le publier dans un dépôt Git. Une commande de démarrage simple, avec un volume persistant et une exposition limitée à la machine locale, peut ressembler à ceci :
docker run –name mariadb-lab -e MARIADB_ROOT_PASSWORD=secret_a_remplacer -v mariadb_data:/var/lib/mysql -p 127.0.0.1:3306:3306 –restart unless-stopped -d mariadb:11.4
L’image officielle accepte les variables d’initialisation MariaDB, dont MARIADB_ROOT_PASSWORD. Le volume nommé mariadb_data conserve les fichiers de la base au-delà de la suppression ou du remplacement du conteneur. La liaison à 127.0.0.1 évite de rendre le port accessible à toutes les interfaces réseau de l’hôte.
Contrôlez l’état et les journaux avec :
docker ps
docker logs mariadb-lab
Pour ouvrir un client dans le conteneur, utilisez docker exec -it mariadb-lab mariadb -u root -p. La connexion depuis un outil graphique se fait sur l’hôte local, le port 3306, avec le compte prévu. Si ce port est déjà utilisé, choisissez un port hôte différent, par exemple 3307, tout en conservant 3306 côté conteneur.
Préférer Docker Compose dès que la configuration doit être partagée
Une commande longue est acceptable pour un essai, mais devient vite difficile à relire et à reproduire. Un fichier Compose rassemble l’image, le réseau, le stockage et la politique de redémarrage. Voici un exemple à adapter :
services:
mariadb:
image: mariadb:11.4
container_name: mariadb-lab
environment:
MARIADB_ROOT_PASSWORD: ${MARIADB_ROOT_PASSWORD}
MARIADB_DATABASE: exemple_db
ports:
– « 127.0.0.1:3306:3306 »
volumes:
– mariadb_data:/var/lib/mysql
restart: unless-stopped
volumes:
mariadb_data:
Placez la variable dans un fichier local non versionné et ajoutez ce fichier à .gitignore. Pour un environnement sensible, préférez un mécanisme de secrets adapté à la plateforme plutôt qu’un mot de passe conservé en clair dans le fichier Compose. Le volume persistant protège contre la suppression du conteneur, mais ne constitue pas une sauvegarde : une suppression accidentelle du volume ou une corruption du stockage reste possible.
Docker fait gagner du temps lorsqu’on maîtrise le cycle de vie complet : image identifiée, secret protégé, volume sauvegardé et ports exposés uniquement au besoin.
Choisir la bonne méthode d’installation selon le contexte
La même installation MariaDB ne répond pas à tous les usages. Un serveur Linux administré par une équipe système n’a pas les mêmes contraintes qu’un développeur qui veut tester une migration sur son ordinateur portable. Le choix doit tenir compte de la durée de vie des données, du niveau d’isolation recherché et des outils de maintenance déjà en place.
| Environnement | Usage adapté | Point de vigilance |
|---|---|---|
| Linux avec paquets | Service durable sur un serveur géré par la distribution | Vérifier la version du dépôt et planifier les mises à jour |
| Windows | Développement local et compatibilité avec les outils Windows | Contrôler le service et les conflits de port |
| macOS avec Homebrew | Tests et développement sur poste Apple | Documenter la version et le mode de démarrage |
| Docker | Laboratoire, intégration et environnements reproductibles | Persistance, secrets, sauvegarde et exposition réseau |
Pour une application déployée sur un serveur Linux, installer le moteur directement par les paquets facilite souvent l’intégration avec systemd, la supervision et les outils de sauvegarde existants. Docker devient intéressant quand plusieurs versions doivent cohabiter ou que le déploiement est déjà automatisé avec Compose ou une plateforme de conteneurs. Le conteneur n’est pas automatiquement plus sécurisé : une mauvaise publication de port annule une bonne partie de l’isolation recherchée.
Sur un poste Windows ou macOS, une installation native donne un accès direct au service et convient si le développeur travaille régulièrement sur MariaDB. Docker est plus propre lorsque le projet doit imposer une version commune à toute l’équipe. Dans les deux cas, inscrivez la version du serveur dans la documentation du dépôt et prévoyez un jeu de données de test reproductible.
Un scénario courant : une petite équipe développe un site sur trois systèmes différents. Si chacun installe une version différente, les écarts de comportement apparaissent tard, parfois au moment de la migration. Une définition Compose partagée réduit ces variations, à condition que les volumes et paramètres soient documentés et que chaque développeur sache réinitialiser son environnement sans supprimer par erreur des données utiles.
La base doit aussi être accessible depuis le bon réseau. Pour un service local, un port lié à l’interface de boucle locale suffit. Pour une application distante, autorisez uniquement le réseau applicatif ou les hôtes nécessaires, utilisez un compte dédié et chiffrez les connexions lorsque les échanges traversent un réseau non maîtrisé. N’ouvrez pas 3306 à Internet « pour dépanner » : créez plutôt un accès VPN ou un tunnel temporaire contrôlé.
Le critère déterminant n’est donc pas la popularité d’une méthode, mais la façon dont l’équipe saura la mettre à jour et la restaurer. Une installation facile à lancer mais impossible à sauvegarder proprement n’est pas un bon choix pour une base utile.
Contrôler la configuration MariaDB, les accès et les sauvegardes
Une fois le serveur lancé, validez la connexion avant d’y brancher l’application. Le client MariaDB permet de tester le nom d’hôte, le port et le compte séparément. Utilisez l’option -p pour saisir le mot de passe à l’invite :
mariadb -h 127.0.0.1 -P 3306 -u application -p
Si l’accès échoue, séparez le diagnostic en étapes : le service est-il actif ? Le port écoute-t-il ? Le compte est-il autorisé depuis cet hôte ? Le pare-feu laisse-t-il passer la connexion ? Une erreur d’identification ne se corrige pas en ouvrant davantage le réseau ; inversement, un compte valide ne peut pas compenser un service qui n’écoute que sur une interface locale.
Un serveur de base de données ne devrait pas être administré au quotidien avec root. Créez un compte pour l’application, accordez les privilèges nécessaires à une base précise et gardez les opérations d’administration pour un compte distinct. Cette séparation limite les dégâts lorsqu’un secret applicatif est exposé.
Sur Linux, les paramètres se trouvent généralement dans les fichiers de configuration de la distribution, souvent sous /etc/mysql/ ou /etc/my.cnf.d/, selon le système. Ne modifiez pas un fichier au hasard : repérez d’abord les fichiers inclus par la configuration active et conservez une copie avant tout changement. Après une modification, redémarrez le service si le paramètre n’est pas rechargeable à chaud, puis vérifiez les journaux.
Pour Docker, une sauvegarde doit inclure les données, pas seulement le fichier Compose. Un volume est un espace de stockage persistant lié au cycle de vie du conteneur, mais il ne protège pas contre la panne du disque, une erreur de manipulation ou un incident sur l’hôte. Utilisez un outil de sauvegarde adapté à MariaDB, stockez une copie séparée et faites régulièrement un test de restauration sur une instance temporaire.
Avant une mise à jour, consultez les notes de version et sauvegardez les données. Pour une base de production, ne testez pas une montée de version directement sur l’unique instance active. Une copie de préproduction permet de vérifier les migrations, les pilotes clients et le comportement des requêtes importantes sans exposer les utilisateurs à une panne évitable.
Les contrôles à conserver dans une procédure d’exploitation peuvent rester courts :
- Confirmer la version, l’état du service et l’espace disque disponible.
- Vérifier que seuls les clients prévus peuvent joindre le port MariaDB.
- Créer une sauvegarde, puis restaurer périodiquement une copie pour valider le processus.
- Mettre à jour les secrets et retirer les comptes de test devenus inutiles.
Une installation réussie n’est pas celle qui affiche simplement « actif » : c’est celle dont les données peuvent être restaurées et dont les accès restent compréhensibles après le départ de la personne qui l’a configurée.
Quelle méthode choisir pour installer MariaDB sur un serveur Linux ?
Sur un serveur Linux classique, privilégiez les paquets de la distribution afin de bénéficier de son système de mises à jour et de gestion des services. Vérifiez la version proposée et son cycle de maintenance avant de l’utiliser pour une application.
Docker convient-il à une base MariaDB de production ?
Oui, si l’exploitation des conteneurs est maîtrisée : version d’image identifiée, secrets protégés, port limité, volume persistant, sauvegardes testées et mises à jour planifiées. Un volume Docker seul ne remplace pas une sauvegarde.
Comment éviter de perdre les données MariaDB dans Docker ?
Montez un volume nommé sur /var/lib/mysql et sauvegardez aussi son contenu avec une méthode cohérente avec MariaDB. Testez la restauration sur une instance distincte ; supprimer un conteneur et supprimer son volume sont deux opérations différentes.
Peut-on utiliser le compte root pour une application ?
Ce n’est pas recommandé. Créez un utilisateur réservé à l’application et limitez ses privilèges à la base nécessaire. Gardez le compte administrateur pour la maintenance et ne stockez pas son mot de passe dans le code source.
