La compatibilité entre MariaDB et MySQL

MariaDB est un remplacement de MySQL prêt à exécuter

À toutes fins pratiques, MariaDB est un remplacement de la même version de MySQL (par exemple, MySQL 5.1 -> MariaDB 5.1, MariaDB 5.2 & MariaDB 5.3 sont compatibles. MySQL 5.5 sera compatible avec MariaDB 5.5).

Cela veut dire que:

• Les fichiers de données et de définition des tables (.frm) sont compatibles au niveau binaire.
  • Voir les notes ci-dessous pour une incompatibilité avec les vues
• Tous les APIs clients, les protocoles et les structures sont identiques.
• Tous les noms de fichiers, fichiers binaires, chemins, ports, sockets et etc.... devraient être les mêmes.
• Tous les connecteurs de MySQL (PHP, Perl, Python, Java.NET, MyODBC, Ruby, connecteur MySQL C etc.) travaillent de la même manière avec MariaDB.
  • Il existe certains problèmes d'installation avec PHP5 dont il faut tenir compte (il s'agit d'un bug sur la manière dont l'ancien client PHP5 vérifie la compatibilité de la librairie client).
• Le paquet mysql-client fonctionne aussi avec le serveur MariaDB.
• La librairie client partagée offre une compatibilité binaire avec la librairie client de MySQL.

Cela signifie que dans la plupart des cas, il suffis de désinstaller MySQL et d'installer MariaDB pour pouvoir l'utiliser. Il n'y a pas besoin de convertir les fichiers de données si la même version majeure est utilisée (par exemple, la version 5.5). Il faut néanmoins toujours exécuter mysql_upgrade pour finaliser la mise à jour, cette opération est requise pour s'assurer que les table contenant les privilèges et les events soient mises à niveau avec les nouveaux champs utilisés par MariaDB.

Tous les mois, le merge avec le code de MySQL est fait afin de garder la compatibilité et pour avoir accès à toutes les fonctionnalités et les corrections des bugs développés par Oracle.

Beaucoup de travail à également été fait sur la mise à niveau des scripts, ce qui fait qu'il est désormais plus facile de faire une mise à jour depuis MySQL 5.0 vers MariaDB 5.1 que depuis MySQL 5.0 vers MySQL 5.1.

MariaDB dispose d'une grande quantité de nouvelles options, extensions, moteurs de stockage et correction de bugs qui ne sont pas présentes dans MySQL. Les caractéristiques des différentes versions de MariaDB se trouvent sur la page Ce qu'il y a dans les différentes versions de MariaDB.

Voir également Les différences de fonctionnalités entre MariaDB et MySQL.

Les cas d'incompatibilité entre MariaDB 5.1 et MySQL 5.1

Dans quelques rares cas, MariaDB doit être incompatible avec MySQL afin de fournir un plus grand nombre d'informations et avec plus de détail que MySQL.

Voici la liste de toutes les incompatibilités connues de niveau utilisateur pouvant être rencontrées lorsque MariaDB 5.1 est utilisé au lieu de MySQL 5.1 :

• Le nom des paquets d'installation commencent par MariaDB au lieu de MySQL.
• Les temps d'exécution peuvent être différents car MariaDB est souvent plus rapide que MySQL.
• mysqld dans MariaDB lit aussi les sections [mariadb] de vos fichiers my.cnf.
• Il n'est pas possible d'utiliser un moteur de stockage binaire s'il n'est pas compilé avec la même et exacte version de MariaDB (car la structure THD interne du serveur dans le cas de MariaDB est différente de celle de MySQL, c'est également le cas entre les différentes versions de MySQL). Cela ne devrait pas poser de problème car la plupart des gens ne rajoutent pas de nouveaux moteurs de stockage et aussi par le fait que MariaDB dispose de plus de moteurs de stockage que MySQL.
• CHECKSUM TABLE pourrait donner des résultats différents car MariaDB n'ignore pas NULL dans les colonnes comme le fait MySQL 5.1 (les versions futures de MySQL devraient calculer les checksums de la même manière que MariaDB). Il est possible de calculer le checksum à la manière ancienne en faisant démarrer mysqld avec l'option --old, il faut cependant noter que les moteurs de stockage MyISAM et Aria dans MariaDB utilisent à l'interne le nouveau checksum donc si l'option --old est utilisée, la commande CHECKSUM sera plus lente car elle devra calculer le checksum ligne par ligne.
• Le log de requêtes lentes dispose de plus d'information sur la requête, ce qui peut poser un problème si un script analyse ce log.
• MariaDB prend par défaut un peu plus de mémoire que MySQL car le moteur de stockage Aria (non présent dans MySQL) est activé par défaut pour manipuler les tables temporaires internes. Il est possible d'utiliser moins de mémoire (au détriment des performances) en définissant la valeur de aria_pagecache_buffer_size à 1M (par défaut cette valeur est de 128M).
• Attention, en cas d'utilisation des nouvelles options de commande, des nouvelles caractéristiques de MariaDB ou des nouveaux moteurs de stockage, il ne sera plus possible de basculer facilement entre MySQL and MariaDB.

Les cas d'incompatibilité entre MariaDB 5.2 et MySQL 5.1

La liste d'incompatibilités est la même qu'entre MariaDB 5.1 et MySQL 5.1 avec en plus, celle qui suit :

• Une nouvelle valeur pour SQL_MODE à été ajoutée : IGNORE_BAD_TABLE_OPTIONS. Si non défini, utiliser une table, champs ou un attribut d'index (option) n'étant pas supporté par le moteur de stockage choisi provoquera une erreur. Ce changement pourrait entraîner des alertes dans le journal d'erreurs en ce qui concerne la manière incorrecte de définir les tables dans la base de données mysql. Pour corriger ce problème, il faut executer mysql_upgrade.

À toutes fins pratiques, MariaDB 5.2 est un remplacement de MariaDB 5.1 et de MySQL 5.1.

Les incompatibilités entre MariaDB 5.3 et MySQL 5.1 et MariaDB 5.2

• Les vues définies avec ALGORITHM=MERGE ou ALGORITHM=TEMPTABLE ont accidentellement été interverties entre MariaDB 5.2 et MariaDB 5.3 ! Il faut re-créer les vues crées avec l'une de ces définitions !
• Quelques messages d'erreur liés a des mauvaises conversions sont différents, étant donné que MariaDB fournit dans ces messages plus d'information sur ce qui a mal tourné.
• Les codes d'erreurs pour les erreurs spécifiques à MariaDB ont été déplacés pour commencer à partir de 1900 afin de ne pas entrer en conflit avec ceux de MySQL.
• Les microsecondes fonctionnent à présent dans tous les contextes ; Dans certains cas, MySQL perdait la partie des microsecondes correspondante à DATETIME et TIME.
• UNIX_TIMESTAMP(constante-date-chaine) retourne un timestamp avec 6 décimales dans MariaDB alors que MySQL n'en retourne aucune. Cela peux poser problème si UNIX_TIMESTAMP() est utilisé dans une fonction de partitionnement. Il est possible de corriger cela en utilisant FLOOR(UNIX_TIMESTAMP(..)) ou en changeant la chaine de date pour une date numérique tel que 20080101000000.
• MariaDB effectue une vérification plus stricte des valeurs de date, datetime et timestamp. Par exemple UNIX_TIMESTAMP('x') retourne désormais NULL au lieu de 0.
• Les anciennes options de démarrage --maria- ont été supprimées. A sa place, il faut utiliser le préfixe --aria- (MariaDB 5.2 supporte aussi bien --maria- que --aria-).
• SHOW PROCESSLIST dispose d'une colonne supplémentaire Progress qui affiche l'état d'avancement pour certaines commandes, elle peut être désactivée en faisant démarrer mysqld soit avec le paramètre --old-mode=NO_PROGRESS_INFO soit avec le paramètre --old (voir OLD_MODE).
• INFORMATION_SCHEMA.PROCESSLIST dispose de trois nouvelles colonnes pour les rapports des avancement: STAGE, MAX_STAGE, et PROGRESS.
• Les Commentaires longs qui commencent avec /*M! ou avec /*M!##### sont exécutés.
• Si la variable max_user_connections est définie à 0 (ce qui dans la pratique signifie qu'aucune limite n'est active) au démarrage de mysqld, il n'est plus possible de changer la valeur de la variable globale tant que mysqld reste en cours d'exécution. Cela est dû au fait que si mysqld est démarré avec max_user_connections=0, les structures de comptage ne sont pas allouées (ce qui implique aussi un mutex pour chaque connexion). Cela pourrait générer des comptages incorrects si la variable était changée en cours d'exécution. Afin de pouvoir de modifier cette variable à chaud, il faut définir une valeur positive au démarrage.
• Il est possible de définir max_user_connections (aussi bien la variable globale que l'option GRANT) à -1 pour empêcher les utilisateurs de se connecter au serveur. La variable globale max_user_connections n'affecte pas les utilisateurs avec le privilège SUPER.
• La directive IGNORE ne fait pas abstraction de toutes les erreurs (comme les erreurs fatales), elle fait seulement abstraction de celles pouvant être ignorées sans risque.

Incompatibilités entre MariaDB 5.5 et MariaDB 5.3

XtraDB

Percona, le fournisseur de XtraDB, n'a pas inclus toutes les anciennes fonctions de XtraDB dans la version 5.5 du code. De par ce fait, MariaDB 5.5 ne peut pas, lui non plus les fournir.

Options de XtraDB manquantes dans la version 5.5

Les options suivantes ne sont plus supportées par la version 5.5 de XtraDB. Si l'une d'entre elles était encore utilisée dans l'un des fichiers de configuration de MariaDB, il faudrait la supprimer (ou commenter) préalablement à la mise à niveau en version 5.5.

• innodb_adaptive_checkpoint; Utiliser innodb_adaptive_flushing_method à la place.
• innodb_auto_lru_dump; Utiliser innodb_buffer_pool_restore_at_startup à la place (et innodb_buffer_pool_load_at_startup in MariaDB 10.0).
• innodb_blocking_lru_restore; Utiliser innodb_blocking_buffer_pool_restore à la place.
• innodb_enable_unsafe_group_commit
• innodb_expand_import; Utiliser innodb_import_table_from_xtrabackup à la place.
• innodb_extra_rsegments; Utiliser innodb_rollback_segments à la place.
• innodb_extra_undoslots
• innodb_fast_recovery
• innodb_flush_log_at_trx_commit_session
• innodb_overwrite_relay_log_info
• innodb_pass_corrupt_table; Utiliser innodb_corrupt_table_action à la place.
• innodb_use_purge_thread
• xtradb_enhancements

Options de XtraDB ayant une nouvelle valeur par défaut

Nouvelles options dans XtraDB 5.5

Les nouvelles options suivantes ont été ajoutées à XtraDB / InnoDB en version 5.5. (Listées ici seulement pour permettre d'avoir toutes les informations XtraDB au même endroit)

• innodb_adaptive_flushing_method
• innodb_adaptive_hash_index_partitions
• innodb_blocking_buffer_pool_restore
• innodb_buffer_pool_instances
• nnodb_buffer_pool_restore_at_startup
• innodb_change_buffering_debug
• innodb_corrupt_table_action
• innodb_flush_checkpoint_debug
• innodb_force_load_corrupted
• innodb_import_table_from_xtrabackup
• innodb_large_prefix
• innodb_purge_batch_size
• innodb_purge_threads
• innodb_recovery_update_relay_log
• innodb_rollback_segments
• innodb_sys_columns
• innodb_sys_fields
• innodb_sys_foreign
• innodb_sys_foreign_cols
• innodb_sys_tablestats
• innodb_use_global_flush_log_at_trx_commit
• innodb_use_native_aio

Voir également le guide de Percona sur la mise à niveau en 5.5

Incompatibilités entre MariaDB 5.5, MariaDB 5.3 et MySQL 5.5

• Les vues définies avec ALGORITHM=MERGE ou ALGORITHM=TEMPTABLE ont accidentellement été interverties entre MariaDB et MySQL ! Il faut re-créer les vues crées avec l'une de ces définitions !
• INSERT IGNORE génère également une alerte pour les erreurs de clé dupliquée. Il est possible de désactiver ce comportement en définissant OLD_MODE=NO_DUP_KEY_WARNINGS_WITH_IGNORE (voir OLD_MODE).
• Avant MariaDB 5.5.31, X'HHHH', la syntaxe SQL standard pour les littérales de chaînes binaires fonctionnait à tort tel que 0xHHHH, qui peux fonctionner en tant que nombre ou chaine en fonction du contexte. Dans la version 5.5.31, cela à été corrigé pour se comporter tel une chaine dans tous les contextes (et jamais comme un nombre), introduisant une incompatibilité avec les précédentes versions de MariaDB et toutes les versions de MySQL. Voir CAST pour plus de détails et un exemple.
• A voir également, un explication détaillée des différences au niveau des variables système entre MariaDB 5.5 et MySQL 5.5.

Les incompatibilités entre MariaDB 10.0 et MySQL 5.6

• Tous les binaires MySQL (mysqld, myisamchk etc.) affichent une alerte si un préfixe d'option est utilisé (par exemple --big-table au lieu de --big-tables). Les binaires MariaDB fonctionnent de la même manière que la majorité des autres commandes Unix et ne produisent pas d'alerte lorsque un préfixe unique est utilisé.
• Les GTID de MariaDB ne sont pas compatible avec MySQL 5.6. Cela signifie qu'il n'est pas possible d'utiliser MySQL 5.6 en tant qu'esclave de MariaDB 10.0.
• Pour faire fonctionner un CREATE TABLE ... SELECT de la même manière en réplication de type "statement" ou de type "row", la requête est exécutée sous la forme CREATE OR REPLACE TABLE sur l'esclave. L'un des avantages est qu'en cas d'arrêt inopiné de l'esclave au milieu du CREATE ... SELECT, il sera capable de continuer.
  • Il est possible d'utiliser la variable slave-ddl-exec-mode pour spécifier comment CREATE TABLE et DROP TABLE sont répliqués.
• A voir également, un explication détaillée des différences au niveau des variables système entre MariaDB 10.0 et MySQL 5.6.
• MySQL 5.6 a le performance schema activé par défaut. Pour des raisons de performance, il est par défaut désactivé sur MariaDB 10.0. Il est possible de l'activer en lancant mysqld avec l'option --performance-schema.

Les options de configuration anciennes et sans support

L'option suivante ne doit plus être utilisée dans my.cnf (ou un n'importe quel autre fichier de configuration de MariaDB) et ce dès MariaDB 5.1 :

• skip-bdb

Comment remplacer un RPM de MySQL

Si le RPM de MySQL est désinstallé avant d'installer MariaDB, il faut noter que la configuration de MySQL est renommée depuis /etc/my.cnf vers /etc/my.cnf.rpmsave.

Après l'installation de MariaDB, il est possible de restaurer l'ancien fichier de configuration de MySQL :

mv -vi /etc/my.cnf.rpmsave /etc/my.cnf

Incompatibilités entre MariaDB et MySQL-Proxy

Un client utilisant l'API MySQL est capable de se connecter à MariaDB en utilisant MySQL-Proxy mais un client utilisant l'API MariaDB recevra les informations de progrès des requêtes que MySQL-Proxy n'a pas implémenté, pour obtenir une compatibilité complète dans tous les cas, il faut simplement désactiver la transmission des informations de progrès côté client ou serveur.