La compatibilité entre MariaDB et MySQL

You are viewing an old version of this article. View the current version here.

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.
  • 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.
  • Le paquet mysql-client fonctionne aussi avec le serveur MariaDB.
  • Il y a quelques problèmes d'installation avec PHP5 dont il faut tenir compte (il s'agit d'un bug sur la manière utilisé par l'ancien PHP5 pour contrôler la compatibilité de la librairie client).

Cela veut dire que pour la plupart des cas, vous n'avez qu'à désinstaller MySQL et installer MariaDB pour pouvoir l'utiliser. Il n'y a pas besoin de convertir les fichiers de données si vous utilisez la même version principale, telle que 5.1.

Tous les mois on fait le merge avec le code de MySQL afin de garder la compatibilité et pour avoir accès à toutes les fonctionnalités et les corrections des bugs développés par Oracle. Nous avons également fait beaucoup de travail sur la mise à niveau des scripts ce qui fait que désormais il est plus facile de faire une mise à jour depuis MySQL 5.0 vers MariaDB 5.1 que depuis MySQL 5.0 à MySQL 5.1.

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

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

Les cas d'incompatibilité entre MariaDB 5.1 MySQL 5.1

Dans très peu de cas MariaDB peut être incompatible avec MySQL. Cela permet de fournir plus d'information que MySQL, information qui est, d'autre part, de meilleure qualité.

Voici la liste de toutes les incompatibilités connues, de niveau utilisateur, que vous pouvez rencontrer quand vous utilisez MariaDB 5.1 au lieu de MySQL 5.1 :

  • Le nom des paquets d'installation commencent par MariaDB au lieu de MySQL.
  • Les timings 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, notez cependant que les moteurs de stockage MyISAM et Aria dans MariaDB utilisent à l'interne le nouveau checksum, donc si vous utilisez --old, 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 vous avez un script qui analyse ce log.
  • MariaDB prend par défaut un peu plus de mémoire que MySQL car nous avons activé par défaut le moteur de stockage Aria pour manipuler les tables temporaires internes. S'il est nécessaire pour vous que MariaDB utilise peu de mémoire (au détriment des performances), vous pouvez définir la valeur de aria_pagecache_buffer_size à 1M (par défaut cette valeur est de 128M).
  • Attention, si vous utilisez les nouvelles options de commande, les nouvelles caractéristiques de MariaDB ou les nouveaux moteurs de stockage, vous ne pourrez plus 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 que pour MariaDB 5.1 et MySQL 5.1 avec en plus, celle qui suit:

  • On a ajouté une nouvelle valeur pour New SQL_MODE: IGNORE_BAD_TABLE_OPTIONS. Si ce n'est pas défini à l'aide d'une table ou d'un attribut (option) qui ne soit pas supporté par le moteur de stockage choisi, cela 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, utilisez mysql_upgrade.

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

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

  • 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 est mal tourné.
  • Les numéros des erreurs pour les erreurs spécifiques de MariaDB ont été déplacés pour commencer à partir de 1900 et ceci pour 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.
  • Les anciennes options de démarrage --maria- ont été supprimées. A sa place vous pourriez 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, vous pouvez la désactiver en faisant démarrer mysqld avec le flag --old.
  • 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 vous utilisez max_user_connections=0 (ce qui dans la pratique signifie qu'aucune limite au nombre de connexions n'est activée) quand vous démarrez mysqld vous ne pourrez plus changer la variable globale tant que mysqld reste en cours d'exécution, et cela parce que quand mysqld est démarré avec max_user_connections=0 les structures de comptage ne sont pas permises (ce qui comporte aussi un mutex pour chaque connexion). Ceci pourrait générer des compteurs incorrects si vous changez la variable postérieurement. Si vous voulez être en mesure de modifier cette variable en à chaud, définissez une valeur élevée au démarrage.
  • Vous pouvez définir max_user_connections (Aussi bien la variable globale que l'option GRANT) comme -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 abstraction seulement des choses qu'on peut ignorer sans problèmes.

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 vous utilisiez l'une d'entre elles dans l'un de vos fichiers my.cnf, vous devriez les supprimez 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.
  • 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_segment à 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

OptionAncienne valeurNouvelle valeur
innodb_adaptive_checkpointTRUE FALSE
innodb_change_bufferinginserts all
innodb_flush_neighbor_pages1 area

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
  • innodb_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

Les options de configuration anciennes et sans support

Si vous êtes en train d'utiliser l'une des suivantes options dans votre /etc/my.cnf ou un autre fichier my.cnf , vous devez les supprimer. C'est également vrai pour MySQL 5.1 ou une version plus récente:

  • skip-bdb

Comment remplacer un RPM de MySQL

Si vous désinstallez un RPM de MySQL pour installer MariaDB, notez que le RPM de MySQL dans la désinstallation prend le nom /etc/my.cnf to /etc/my.cnf.rpmsave.

Après l'installation de MariaDB vous devriez faire ce qui suit pour restaurer vos anciennes options de configuration:

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

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.