Migration de MySQL Enterprise vers MariaDB 10.3

Bien qu'elle partage le même héritage avec MySQL, MariaDB est une base de données différente. Au fil des ans, à mesure que de nouvelles versions de MySQL et de MariaDB ont été publiées, les deux projets se sont différenciés en deux plates-formes RDBMS différentes.

MariaDB devient la principale distribution de bases de données sur de nombreuses plates-formes Linux et gagne en popularité ces jours-ci. En même temps, il devient un système de base de données très attractif pour de nombreuses entreprises. Il bénéficie de fonctionnalités proches des besoins de l'entreprise, telles que le chiffrement, les sauvegardes à chaud ou la compatibilité avec les bases de données propriétaires.

Mais comment les nouvelles fonctionnalités affectent-elles la compatibilité de MariaDB avec MySQL ? Est-ce toujours un remplacement de chute pour MySQL ? Comment les derniers changements amplifient-ils le processus de migration ? Nous essaierons d'y répondre dans cet article.

Ce que vous devez savoir avant la mise à jour

MariaDB et MySQL diffèrent considérablement l'une de l'autre au cours des deux dernières années, notamment avec l'arrivée de leurs versions les plus récentes :MySQL 8.0, MariaDB 10.3 et MariaDB 10.4 RC (nous avons discuté des nouvelles fonctionnalités de MariaDB 10.4 RC assez récemment, donc si vous souhaitez en savoir plus sur les nouveautés de la version 10.4, veuillez consulter deux blogs de mon collègue Krzysztof, What's New in MariaDB 10.4 et le second sur What's New in MariaDB Cluster 10.4).

Avec la version MariaDB 10.3, MariaDB en a surpris plus d'un puisqu'il ne remplace plus MySQL. MariaDB ne fusionne plus les nouvelles fonctionnalités MySQL avec MariaDB noir résolvant les bogues MySQL. Néanmoins la version 10.3 devient désormais une véritable alternative à Oracle MySQL Enterprise ainsi qu'à d'autres bases de données propriétaires d'entreprise comme Oracle 12c (MSSQL en version 10.4).

Vérification préliminaire et limites

La migration est un processus complexe, quelle que soit la version vers laquelle vous effectuez la mise à niveau. Il y a quelques éléments que vous devez garder à l'esprit lors de la planification, tels que les changements essentiels entre les versions du SGBDR ainsi que les tests détaillés qui doivent mener tout processus de mise à niveau. Ceci est particulièrement important si vous souhaitez maintenir la disponibilité pendant toute la durée de la mise à niveau.

La mise à niveau vers une nouvelle version majeure comporte des risques, et il est important de planifier l'ensemble du processus de manière réfléchie. Dans ce document, nous examinerons les nouveaux changements importants dans la version 10.3 (et la prochaine version 10.4) et vous montrerons comment planifier le processus de test.

Pour minimiser les risques, examinons les différences et les limites des plates-formes.

À partir de la configuration, certains paramètres ont des valeurs par défaut différentes. MariaDB fournit une matrice des différences de paramètres. Il peut être trouvé ici.

Dans MySQL 8.0, caching_sha2_password est le plugin d'authentification par défaut. Cette amélioration devrait améliorer la sécurité en utilisant l'algorithme SHA-256. MySQL a ce plugin activé par défaut, contrairement à MariaDB. Bien qu'il y ait déjà une demande de fonctionnalité ouverte avec MariaDB MDEV-9804. MariaDB propose à la place le plugin ed25519 qui semble être une bonne alternative à l'ancienne méthode d'authentification.

La prise en charge par MariaDB du chiffrement sur les tables et les espaces de table a été ajoutée dans la version 10.1.3. Vos tables étant cryptées, vos données sont presque impossibles à voler. Ce type de chiffrement permet également à votre organisation de se conformer aux réglementations gouvernementales telles que le RGPD.

MariaDB prend en charge les pools de threads de connexion, qui sont plus efficaces dans les situations où les requêtes sont relativement courtes et la charge est liée au CPU. Sur l'édition communautaire de MySQL, le nombre de threads est statique, ce qui limite la flexibilité dans ces situations. Le plan d'entreprise de MySQL inclut des fonctionnalités de pool de threads.

MySQL 8.0 inclut le schéma sys, un ensemble d'objets qui aide les administrateurs de bases de données et les ingénieurs logiciels à interpréter les données collectées par le schéma de performances. Les objets de schéma Sys peuvent être utilisés pour des cas d'utilisation d'optimisation et de diagnostic. MariaDB n'inclut pas cette amélioration.

Un autre est les colonnes invisibles. Les colonnes invisibles offrent la possibilité d'ajouter des colonnes aux tables existantes sans craindre de casser une application. Cette fonctionnalité n'est pas disponible dans MySQL. Il permet de créer des colonnes qui ne sont pas répertoriées dans les résultats d'une instruction SELECT *, et il n'est pas non plus nécessaire de leur attribuer une valeur dans une instruction INSERT lorsque leur nom n'est pas mentionné dans l'instruction.

MariaDB a décidé de ne pas implémenter le support JSON natif (l'une des principales fonctionnalités de MySQL 5.7 et 8.0) car ils prétendent que cela ne fait pas partie de la norme SQL. Au lieu de cela, pour prendre en charge la réplication à partir de MySQL, ils ont uniquement défini un alias pour JSON, qui est en fait une colonne LONGTEXT. Afin de s'assurer qu'un document JSON valide est inséré, la fonction JSON_VALID peut être utilisée comme contrainte CHECK (par défaut pour MariaDB 10.4.3). MariaDB ne peut pas accéder directement au format MySQL JSON.

Oracle automatise de nombreuses tâches avec MySQL Shell. En plus de SQL, MySQL Shell offre également des fonctionnalités de script pour JavaScript et Python.

Processus de migration à l'aide de mysqldump

Une fois que nous connaissons nos limites, le processus d'installation est assez simple. C'est à peu près lié à l'installation standard et à l'importation à l'aide de mysqldump. L'outil de sauvegarde MySQL Enterprise n'est pas compatible avec MariaDB, la méthode recommandée consiste donc à utiliser mysqldump. Voici l'exemple de processus effectué sur Centos 7 et MariaDB 10.3.

Créer un dump sur le serveur MySQL Enterprise

$ mysqldump --routines --events --triggers --single-transaction db1 > export_db1.sql

Nettoyer l'index du cache yum

sudo yum makecache fast

Installer MariaDB 10.3

sudo yum -y install MariaDB-server MariaDB-client

Démarrez le service MariaDB.

sudo systemctl start mariadb
sudo systemctl enable mariadb

Sécurisez MariaDB en exécutant mysql_secure_installation.

# mysql_secure_installation 

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user.  If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none): 
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

Set root password? [Y/n] y
New password: 
Re-enter new password: 
Password updated successfully!
Reloading privilege tables..
 ... Success!


By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y
 ... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y
 ... Success!

Cleaning up...

All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!

Importer le vidage

Mysql -uroot -p
> tee import.log
> source export_db1.sql
Review the import log.

$vi import.log

Pour déployer un environnement, vous pouvez également utiliser ClusterControl qui a une option de déploiement à partir de zéro.

ClusterControl peut également être utilisé pour configurer la réplication ou pour importer une sauvegarde depuis MySQL Enterprise Edition.

Processus de migration utilisant la réplication

L'autre approche pour la migration entre MySQL Enterprise et MariaDB consiste à utiliser le processus de réplication. Les versions de MariaDB permettent la réplication vers celles-ci, à partir des bases de données MySQL - ce qui signifie que vous pouvez facilement migrer les bases de données MySQL vers MariaDB. Les versions de MySQL Enterprise n'autorisant pas la réplication à partir des serveurs MariaDB, il s'agit donc d'une route à sens unique.

Voici quelques règles générales pointées par MariaDB.

• La réplication de MySQL 5.5 vers MariaDB 5.5+ devrait fonctionner. Vous voudrez que MariaDB ait la même version ou une version supérieure à celle de votre serveur MySQL.
• Lorsque vous utilisez MariaDB 10.2+ en tant qu'esclave, il peut être nécessaire de définir binlog_checksum sur NONE.
• La réplication de MySQL 5.6 sans GTID vers MariaDB 10+ devrait fonctionner.
• La réplication à partir de MySQL 5.6 avec GTID, binlog_rows_query_log_events et les événements ignorables fonctionne à partir de MariaDB 10.0.22 et MariaDB 10.1.8. Dans ce cas, MariaDB supprimera les GTID MySQL et autres événements inutiles et ajoutera à la place ses propres GTID.

Même si vous ne prévoyez pas d'utiliser la réplication dans le processus de migration/transfert, en avoir une est un bon facteur de confiance, c'est répliquer votre serveur de production sur un bac à sable de test, puis vous entraîner dessus.

Nous espérons que cet article de blog d'introduction vous a aidé à comprendre le processus d'évaluation et de mise en œuvre de MySQL Enterprise Migration vers MariaDB.