MariaDB 10.4 est une branche de développement actuelle de MariaDB. Récemment, le 21 mai, la troisième Release Candidate (10.4.5) a été publiée, nous rapprochant de la sortie officielle. C'est pourquoi nous avons pensé qu'il serait peut-être bon de jeter un coup d'œil aux nouvelles fonctionnalités de la 10.4. Nous partagerons également quelques réflexions sur un récent article de blog publié par MariaDB Corporation. Pour plus d'informations sur la version elle-même, vous pouvez trouver tous les détails dans le changelog de MariaDB 10.4.0.
Modifications des performances
Les jeux de caractères Unicode sont généralement plus lents que les jeux de caractères comme latin1, principalement en raison de leur taille. MySQL 8.0 a apporté des améliorations significatives dans ce domaine, et MariaDB 10.4 devrait également être sensiblement plus rapide que 10.3 à cet égard. C'est une amélioration assez importante - les gens aiment vraiment utiliser les emojis, qui nécessitent l'activation de l'UTF8. Certains travaux ont été effectués dans l'optimiseur - MariaDB 10.4 devrait mieux fonctionner pour les sous-requêtes IN() car il est désormais possible de pousser des conditions dans des sous-requêtes matérialisées.
Le démarrage et l'arrêt d'InnoDB peuvent prendre un certain temps, en fonction de la quantité de données dans les journaux redo. MariaDB 10.4 améliorera le démarrage, l'arrêt et la purge. Ces améliorations sont particulièrement importantes compte tenu de la popularité des outils de sauvegarde à chaud tels que mariabackup et xtrabackup. Ces outils, en fin de compte, passent par le processus de démarrage d'InnoDB à partir d'un arrêt incorrect lorsqu'ils appliquent des journaux redo, donc chaque amélioration dans ce domaine devrait réduire le temps nécessaire pour restaurer les sauvegardes.
Modifications d'InnoDB
MariaDB 10.4 a reçu une opération DROP COLUMN instantanée. Il est désormais également possible de réorganiser les colonnes de la table sans avoir à la reconstruire. Nous ne pouvons pas souligner à quel point cela est important. Vous vous demandez peut-être quelles sont les opérations les plus courantes que vous effectuez dans l'environnement de production ? Nous dirions qu'il s'agit d'ajouter ou de supprimer un index. Une autre opération la plus courante serait les opérations sur les colonnes - ajouter une nouvelle colonne et supprimer la colonne existante. Jusqu'à présent, l'approche la plus courante consistait à utiliser des outils externes pour faire le travail :pt-online-schema-change ou, plus récemment, gh-ost. Les deux ont leurs limites (gh-ost ne fonctionne pas pour Galera Cluster, par exemple), ce qui peut rendre impossible leur utilisation sur votre système. Les clés étrangères sont particulièrement délicates. Avec instant DROP COLUMN (instant ADD COLUMN est déjà disponible), une grande partie des modifications de schéma peuvent être effectuées ad hoc, sans planification ni planification détaillées, comme cela doit être fait maintenant. Il est important de garder à l'esprit que les changements instantanés sont ce que nous voulons avoir. Il existe des changements de schéma non bloquants, comme la création d'un index, mais de telles opérations posent de sérieux défis lorsque la réplication est utilisée car elles induisent un décalage de réplication. Ainsi, même si l'opération aurait pu être exécutée sur le système en direct, nous préférons utiliser des solutions de contournement comme pt-online-schema-change pour garder un meilleur contrôle sur le processus.
Ce n'est pas la seule amélioration dans la façon dont les changements de schéma sont exécutés. MariaDB 10.4 bénéficiera d'une extension plus rapide des colonnes VARCHAR. De plus, les changements de jeu de caractères et de classement sur les colonnes non indexées seront instantanés.
Modifications générales
L'un des changements les plus importants concerne les changements dans la gestion des utilisateurs. La table mysql.host ne sera pas créée, la table mysql.user est obsolète. Les comptes utilisateurs et les privilèges globaux seront conservés dans la table mysql.global_priv. C'est potentiellement un changement sérieux pour tous les outils (y compris ClusterControl), qui ont une option pour gérer les utilisateurs MySQL et MariaDB - de nouveaux cas devront être écrits pour couvrir la gestion des utilisateurs dans MariaDB 10.4 et versions ultérieures. Bien que nous reconnaissions que des changements sont nécessaires, cela n'aide certainement pas à maintenir les outils pour MariaDB et MySQL, ce qui rend le paysage des outils encore plus divisé qu'il ne l'est déjà. En parlant d'utilisateurs, MariaDB 10.4 est livré avec une option d'expiration du mot de passe utilisateur. C'est certainement un pas dans la bonne direction - cela aide à appliquer les bonnes pratiques en matière de gestion des mots de passe.
Même si nous le couvrirons plus en détail dans un blog séparé, nous devons mentionner ici la prise en charge de Galera 26.4 - MariaDB 10.4 bénéficiera d'une nouvelle version de Galera avec des fonctionnalités telles que la réplication en streaming ou l'amélioration du SST grâce aux verrous de sauvegarde.
Enfin, dans MariaDB 10.4, vous pouvez définir sql_mode=MSSQL. Il s'agit d'une implémentation initiale, mais sql_mode=ORACLE était également une implémentation initiale à un moment donné. Cela montre l'accent mis par MariaDB sur les clients d'entreprise - si les clients Oracle décident de migrer, il est fort probable que l'adoption de MariaDB parmi Microsoft SQL Server augmentera également à mesure que davantage de fonctionnalités seront ajoutées et que la migration deviendra moins problématique.
MariaDB étant une fourchette
Tout récemment, nous avons vu un article de blog expliquant la position de MariaDB sur les modifications et la compatibilité d'InnoDB. L'essentiel est que MariaDB ne fusionnera plus les fonctionnalités InnoDB de MySQL, l'accent sera mis sur la stabilité et l'amélioration des performances apportées par MariaDB. Cela signifie essentiellement que MariaDB deviendra incompatible avec MySQL. Même si vous pouviez faire la mise à niveau binaire dans le passé, cela ne sera plus possible à l'avenir. Même en ce moment, cela peut être difficile à exécuter. Cela augmente l'importance d'outils tels que mydumper/myloader car la sauvegarde logique sera le seul moyen de migration. Ce qui est bien, MariaDB sera en mesure de posséder la stabilité de leur fork d'InnoDB - ils n'auront pas à gérer les problèmes introduits par les développeurs en amont, nous pouvons donc nous attendre à moins de bogues introduits.
En termes de performances, nous devons attendre les benchmarks, mais compte tenu des données historiques, nous pouvons supposer que MariaDB sera plus lent que MySQL. Dans les benchmarks passés, nous constatons généralement que l'augmentation des performances de MariaDB se déclenche lorsqu'une version plus récente d'InnoDB a été intégrée. Ce ne sera plus le cas, ce qui nous amène à nous demander comment MariaDB se comportera désormais dans la comparaison des performances et si les améliorations introduites par MariaDB seront suffisantes pour suivre MySQL 8.0 et les versions ultérieures.
Pour nous, utilisateurs, tout cela signifie que MariaDB 10.4 devrait être plus stable que les versions précédentes. Cela signifie également que nous devrons éventuellement apprendre les composants internes de deux moteurs de stockage différents, en particulier si nous nous soucions des performances. C'est loin d'être idéal mais c'est comme ça. Les outils devront être conçus pour fonctionner avec l'une ou l'autre version d'InnoDB (ou des travaux supplémentaires devront être ajoutés pour supporter à la fois MySQL et MariaDB). Nous garderons un œil sur la façon dont cela va évoluer. Quand on y pense, ce n'est pas si surprenant - MariaDB a toujours dû prendre son temps pour s'intégrer à la version plus récente d'InnoDB. Avec de plus en plus de fonctionnalités incompatibles ajoutées à MariaDB et d'énormes changements introduits dans MySQL 8.0, il est logique de se concentrer sur le développement de nouvelles fonctionnalités plutôt que sur le portage d'InnoDB incompatible depuis MySQL en amont.
Nous espérons que ce court article de blog vous a donné un aperçu des changements qui affecteront les systèmes de production lors du passage à MariaDB 10.4.
