Aujourd’hui, on aborde la migration du serveur de base de données : nous passons de l’historique MySQL à son fork libre MariaDB.
Les raisons de remplacer Oracle MySQL avec MariaDB sont nombreuses.
MySQL vs MariaDB
Tout d’abord, MariaDB assure la compatibilité et la continuité de service avec MySQL. Les librairies sont exactement équivalentes et permettent d’utiliser les APIs et commandes de MySQL.
Les performances de MariaDB sont souvent meilleures que celles de MySQL, notamment grâce à l’amélioration de l’optimiseur de requêtes et l’intégration du moteur XtraDB de Percona, qui vise à remplacer InnoDB.
Un nouveau moteur de stockage, Aria, a été écrit pour devenir un moteur à la fois transactionnel et non-transactionnel pour remplacer MyISAM. Il pourrait même être inclus dans de prochaines versions de MySQL.
Dans un autre registre, Oracle semble ne pas vouloir garder le modèle libre de MySQL : pas mal de choses (rapports de bugs, scénarios de test) sont maintenant disponibles uniquement pour les grands comptes payants.
Michael “Monty” Widenius, le fondateur de MySQL AB, a quitté Sun Microsystems lors de son rachat par Oracle pour créer Monty Program AB puis la Fondation MariaDB. Il est rapidement rejoint par de nombreux développeurs originaux de MySQL.
Ces développeurs maîtrisent donc parfaitement le code source du système de gestion de base de données, cela promet encore de nombreuses nouveautés et optimisations pour les versions suivantes.
Installation de MariaDB
Notre serveur dédié tourne toujours sur Debian stable et les paquets de MariaDB sont disponibles dans les dépôts officiels.
MariaDB est un “drop-in replacement” pour MySQL, c’est -à-dire qu’il suffit de désinstaller MySQL et d’installer MariaDB : rien ne change, pas de pertes de données, pas de lignes de code à changer, tout est compatible.
L’installation est donc très simple :
apt-get install mariadb-server
Code language: JavaScript (javascript)
Résultat:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common
mariadb-server-10.0 mariadb-server-core-10.0
Suggested packages:
mariadb-test tinyca
The following packages will be REMOVED:
mysql-client-5.6 mysql-client-core-5.6 mysql-server mysql-server-5.6
mysql-server-core-5.6
The following NEW packages will be installed:
mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common mariadb-server
mariadb-server-10.0 mariadb-server-core-10.0
0 upgraded, 6 newly installed, 5 to remove and 0 not upgraded.
Need to get 11.8 MB of archives.
After this operation, 18.4 MB disk space will be freed.
Code language: CSS (css)
L’installation vous demandera de donner un mot de passe pour l’utilisateur root
. De manière à assurer la continuité avec MySQL, j’ai redonné le même mot de passe que pour mon utilisateur root
sous MySQL.
Enfin, l’installation vous demande si vous désirez vraiment migrer vers MariaDB, en vous expliquant qu’il est très aisé de migrer dans le sens MySQL-MariaDB mais que l’inverse (MariaDB-MySQL) peut poser des problèmes étant donné que MariaDB propose plus de fonctionnalités que MySQL.
Il suffit d’accepter la migration. Tout est transparent. Testez vos services, tout devrait fonctionner parfaitement.
Configuration de MariaDB
Lors de l’installation, j’ai préféré installer le fichier my.cnf de mariaDB plutôt que de garder celui de MySQL que j’avais modifié pour passer de MySQL à InnoDB.
Le fichier par défaut est bien mais il faut absolument désactiver la réplication des logs binaires parce que cela remplit la partition /root en seulement quelques heures!
On édite donc la configuration du serveur mariaDB:
nano /etc/mysql/my.cnf
et on commente ces deux lignes:
#log_bin = /var/log/mysql/mariadb-bin
#log_bin_index = /var/log/mysql/mariadb-bin.index
Code language: PHP (php)
On sauvegarde nos changements et on relance le serveur:
service mysql restart
Conclusion
Je suis très content d’avoir migré vers MariaDB : le processus d’installation est extrêmement simple et tout est compatible avec MySQL.
En tout et pour tout, c’est une migration qui m’a pris dix minutes : huit minutes pour sauvegarder et rapatrier mes bases de données et deux minutes pour passer à MariaDB.
La charge serveur a bien baissé également : MySQL occupait souvent dans les 18% de la mémoire du serveur. Comparativement, MariaDB se stabilise dans les 12%, ce qui est un gain non négligeable.
Synopsis » Monter un serveur dédié de A à Z
- Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
- Serveur dédié : créer la base de données MySQL et importer WordPress
- Serveur dédié : créer et activer un Virtual Host sous Apache
- Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
- Serveur dédié : sécurisation des services avec iptables et fail2ban
- Serveur dédié : sécurisation de la couche TCP/IP
- Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
- Serveur dédié : sécuriser Apache 2 avec ModSecurity
- Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
- Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
- Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
- Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
- Serveur dédié : installer la dernière version d’APC par SVN
- Serveur dédié : analyse des performances du serveur
- Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
- Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
- Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
- Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
- Serveur dédié : impossible de se connecter à un port distant
- Rsync: rapatrier les fichiers du serveur à la maison
- Bash : réparer les tables MySQL en cas de crash
- Serveur dédié : création d’une seedbox avec Transmission
- Serveur dédié : des paquets LAMP à jour sous Debian
- Serveur dédié : mise à jour vers Debian 7 Wheezy
- Serveur dédié : activer X11 forwarding pour SSH
- Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
- Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
- Serveur dédié : mise en place de l’IPv6
- WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
- WordPress : héberger les images sur un sous-domaine
- Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
- Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
- Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
- Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
- Serveur dédié : configurer Webmin en TLS avec un certificat SSL
- Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
- Serveur dédié : installer et configurer Varnish 4
- Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
- Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
- Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
- Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
- Serveur dédié : installer la dernière version d’OpenSSL sous Debian
- Serveur dédié : activer l’IP canonique du serveur sous Apache
- Serveur dédié : mise à jour vers PHP 5.6
- MySQL : convertir les tables MyISAM au format InnoDB
- Serveur dédié : optimiser toutes les images GIF avec GIFsicle
- Serveur dédié : migration de MySQL vers MariaDB
- BASH : lister, bloquer et débloquer des adresses IP avec iptables
- Serveur dédié : produire une meilleure réserve d’entropie avec haveged
- Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
- Serveur dédié : mise en place du protocole DANE
- 8 règles d’or pour bien déployer DNSSEC et DANE
- Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
- Serveur dédié : optimiser la couche TCP
- Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
- Serveur dédié : mettre à jour Apache pour HTTP/2
- Serveur dédié : ajouter le domaine à la liste HSTS preload
- Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
- Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
- Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Vous avez un projet WordPress ou WooCommerce en tête? Transformez votre vision en réalité avec mon expertise reconnue.
Cela n’est t’il pas plus pertinent en terme de performance de réimporter les bases de données dans MariaDB plutôt que de changer juste MySQL, puisqu’il est dit que la migration vers MariaDB n’est pas un problème mais que l’inverse peu créer des problèmes, c’est qu’il y a des différences et que cela peut-être bénéfique pour la structure des données, supposition bien sur ?
Salut imars,
MariaDB garde le même format de fichiers de base de données que MySQL (.frm/.ibd pour InnoDB et .MYD/.MYI pour MyISAM) mais utilise des moteurs différents pour les gérer au lancement du serveur.
Le moteur XtraDB est une version optimisée d’InnoDB et Aria de MyISAM – c’est à dire que mes bases sont gérées par les nouveaux moteurs de manière transparentes, sans avoir à réimporter les bases.
Les versions de MariaDB et MySQL semblent être assez synchrones pour l’instant (du moins pour les versions stables) donc cela ne devrait pas poser de problèmes. Il ne me semble pas que les bases aient été fondamentalement modifiées. Le retour vers MySQL ne devrait pas être problématique si besoin était.