MariaDB versus MySQL – Kompatibilität

MariaDB ist ein binärkompatibler 1:1-Ersatz für MySQL

In praktisch allen Fällen ist MariaDB ein 1:1-Ersatz derselben MySQL-Version (beispielsweise MySQL 5.1 → MariaDB 5.1, MariaDB 5.2 & MariaDB 5.3 sind kompatibel. MySQL 5.5 ist mit MariaDB 5.5 und in der Praxis mit MariaDB 10.0 kompatibel). Das bedeutet, dass

• Datendateien sowie Tabellendefinitionsdateien (.frm) binärkompatibel sind,
  • Siehe die Anmerkung unten für eine Inkompatibilität mit Views.
• alle Schnittstellen (APIs), Protokolle und Strukturen identisch sind,
• alle Dateinamen, Binärdateien, Pfade, Ports, Sockets usw. gleich sein sollten,
• alle MySQL-Konnektoren (PHP, Perl, Python, Java, .NET, MyODBC, Ruby, MySQL C Konnektor, usw.) ohne Änderung mit MariaDB arbeiten,
  • Es gibt ein paar Installationsstolpersteine mit PHP5, auf die Sie achten sollten (ein Fehler, wie der alte PHP5-Client die Bibliothekskompatibilität prüft).
• das mysql-client-Paket ebenfalls mit dem MariaDB-Server arbeitet,
• die gemeinsam genutzte Client-Bibliothek (shared library) binärkompatibel mit MySQLs Client-Bibliothek ist.

Das bedeutet, dass Sie in den meisten Fällen einfach MySQL deinstallieren und MariaDB installieren, und Sie startklar sind. (Es ist nicht nötig, irgendwelche Datendateien zu konvertieren, wenn Sie die gleiche Hauptversion nutzen, wie 5.1). Sie müssen jedoch noch mysql_upgrade laufen lassen, um das Upgrade abzuschließen. Das ist nötig um sicherzustellen, dass Ihre MySQL-Berechtigungen und Event-Tabellen mit den neuen von MariaDB genutzten Feldern aktualisiert werden.

Wir führen monatlich unseren Code mit dem MySQL-Code zusammen um sicherzustellen, dass wir weiterhin kompatibel sind und jegliche Features und Fehlerkorrekturen erhalten, die Oracle einbaut.

Wir haben außerdem viel Arbeit in die Upgradeskripts gesteckt, bis dahin, dass es nun einfacher ist, den Upgrade von MySQL 5.0 zu MariaDB 5.1 zu machen als von MySQL 5.0 zu MySQL 5.1.

Abgesehen davon hat MariaDB neue Optionen, Erweiterungen, Speicher-Engines und Fehlerkorrekturen, die es nicht in MySQL gibt. Der Umfang der Features der unterschiedlichen MariaDB-Versionen steht auf der Seite Was enthalten die verschiedenen MariaDB-Releases.

Inkompatibilitäten zwischen MariaDB 5.1 und MySQL 5.1

In einigen wenigen Fällen muss MariaDB inkompatibel sein, damit MariaDB mehr und bessere Informationen als MySQL liefern kann.

Die ist die Liste aller bekannten Endnutzer-Inkompatibilitäten, die Ihnen begegnen können, wenn Sie MariaDB 5.1 anstelle von MySQL 5.1 nutzen:

• Die Namen der Installationspakete starten mit MariaDB statt MySQL.
• Zeiten können abweichen, weil MariaDB in vielen Fällen schneller als MySQL ist.
• mysqld in MariaDB liest auch den Abschnitt [mariadb] Ihrer Datei my.cnf.
• Sie können eine nur in Binärform vorliegende Speicherengine-Bibliothek mit MariaDB nicht nutzen, wenn sie nicht für die exakt gleiche MariaDB-Version kompiliert ist (Das liegt daran, dass die interne Serverstruktur THD sich zwischen MySQL und MariaDB unterscheidet. Das ist üblicherweise auch zwischen verschiedenen MySQL-Versionen so). Dies sollte kein Problem sein, weil die meisten Leute keine neue Speicherengine laden und MariaDB mit mehr Speicherengines kommt als MySQL.
• CHECKSUM TABLE kann zu einem anderen Ergebnis kommen, weil MariaDB nicht NULLs in den Spalten ignoriert, wie es MySQL 5.1 tut (Zukünftige MySQL-Versionen sollten Prüfsummen genauso wie bei MariaDB berechnen). Sie können die Prüfsumme der alten Art in MariaDB verwenden, indem Sie mysqld mit der Option --old starten. Beachten Sie jedoch, dass die MyISAM- und Aria-Speicherengines in MariaDB die neue Prüfsumme intern verwenden, wenn Sie also --old nutzen, wird das Kommando CHECKSUM langsamer, weil es die Prüfsumme Zeile für Zeile berechnen muss.
• Die Logdatei für langsame Anfragen (slow query log) hat mehr Informationen über die Anfrage, was ein Problem werden kann, wenn Sie ein Skript haben, das die Logdatei für langsame Anfragen parst.
• MariaDB benötigt standardmäßig etwas mehr Hauptspeicher als MySQL, weil wir standardmäßig die Speicherengine Aria für das Management interner temporärer Tabellen eingestellt haben. Wenn Sie möchten, dass MariaDB sehr wenig Hauptspeicher verwendet (zulasten der Performance), können Sie den Wert von aria_pagecache_buffer_size auf 1M setzen (die Voreinstellung ist 128M).
• Wenn Sie neue Kommandozeilenoptionen, neue Features von MariaDB oder neue Speicherengines nutzen, können Sie nicht mehr einfach zwischen MySQL und MariaDB hin und her wechseln.

Inkompatibilitäten zwischen MariaDB 5.2 und MySQL 5.1

Die Liste ist die gleiche wie zwischen MariaDB 5.1 und MySQL 5.1, mit einer Ergänzung:

• Ein neuer SQL_MODE-Wert wurde hinzugefügt: IGNORE_BAD_TABLE_OPTIONS. Wenn er nicht gesetzt ist, erzeugt es einen Fehler, wenn man eine Tabelle, ein Feld oder ein Indexattribut (Option) nutzen will, welches von der gewählten Speicherengine nicht unterstützt wird. Diese Änderung kann Warnungen im Fehlerlog über falsch definierte Tabellen der mysql-Datenbank hervorrufen, beheben Sie dies mit mysql_upgrade.

In praktisch allen Fällen ist MariaDB 5.2 ein 1:1-Ersatz für MariaDB 5.1 und MySQL 5.1.

Inkompatibilitäten zwischen MariaDB 5.3 und MySQL 5.1 und MariaDB 5.2

• Views mit der Definition ALGORITHM=MERGE oder ALGORITHM=TEMPTABLE wurden zwischen MariaDB 5.2 und MariaDB 5.3 versehentlich vertauscht. Sie müssen Views mit einer dieser Definitionen neu erzeugen.
• Wenige Fehlermeldungen, die falsche Konvertierungen betreffen, sind unterschiedlich, da MariaDB mehr Informationen in der Meldung darüber bereitstellt, was falschgelaufen ist.
• Fehlernummern für MariaDB-spezifische Fehler wurden verschoben, sodass sie ab 1900 starten und damit nicht mit MySQL-Fehlern kollidieren.
• Mikrosekunden funktionieren nun in allen Situationen; MySQL verliert in einigen Situationen den Mikrosekundenteil von datetime und time.
• UNIX_TIMESTAMP(konstanter Datumsstring) liefert einen timestamp mit 6 Dezimalstellen bei MariaDB zurück, während MySQL es ohne Dezimalstellen zurückliefert. Dies kann Probleme verursachen, wenn Sie UNIX_TIMESTAMP() als Partitionierungsfunktion verwenden. Sie können dies beheben, indem Sie FLOOR(UNIX_TIMESTAMP(…)) verwenden oder den Datumsstring in eine Datumszahl wie 20080101000000 umwandeln.
• MariaDB prüft die Werte von date, datetime und timestamp schärfer. Beispielsweise liefert UNIX_TIMESTAMP('x') nun NULL zurück anstatt 0.
• Die alten Startoptionen --maria- wurden beseitigt. Sie sollten den Präfix --aria- stattdessen nutzen. (MariaDB 5.2 unterstützt sowohl --maria- als auch --aria-.)
• SHOW PROCESSLIST hat eine zusätzliche Spalte Progress, die den Fortschritt für manche Kommandos zeigt. Sie können sie abschalten, indem Sie mysqld mit entweder --old-mode=NO_PROGRESS_INFO oder dem Flag --old (siehe OLD_MODE) starten.
• INFORMATION_SCHEMA.PROCESSLIST hat drei neue Spalten für Fortschrittsmeldungen: STAGE, MAX_STAGE und PROGRESS.
• Lange Kommentare, die mit /*M! oder /*M!##### starten, werden ausgeführt.
• Wenn Sie beim Start von mysqld max_user_connections=0 nutzen (was unbeschränkte Anzahl an Verbindungen bedeutet), können Sie die globale Variable nicht mehr ändern, solange mysqld noch läuft. Das liegt daran, dass bei einem Start von mysqld mit max_user_connections=0 es keine Zählstrukturen reserviert (was auch einen Mutex für jede Verbindung beinhaltet). Dies würde zu falschen Zählern führen, wenn Sie später die Variable ändern. Wenn Sie die Variable während der Laufzeit ändern möchten, setzen Sie sie beim Start auf einen hohen Wert.
• Sie können max_user_connections (sowohl die globale Variable als auch die Option GRANT) auf -1 setzen, um Nutzer davon auszuschließen, sich mit dem Server zu verbinden. Die globale Variable max_user_connections wirkt sich nicht auf Nutzer mit SUPER-Rechten aus.
• Die Direktive IGNORE ignoriert nicht alle Fehler (wie fatale Fehler), sondern nur Dinge, die ohne Bedenken ignoriert werden können.

Inkompatibilitäten zwischen MariaDB 5.5 und MariaDB 5.3

XtraDB

Percona, der Anbieter von XtraDB, bietet nicht alle früheren XtraDB-Features im 5.5er-Code. Deshalb kann auch MariaDB 5.5 sie nicht bieten.

XtraDB-Optionen, die in 5.5 fehlen

Die folgenden Optionen werden von XtraDB 5.5 nicht unterstützt. Wenn Sie sie in einer Ihrer my.cnf-Dateien nutzen, sollten Sie sie entfernen, bevor Sie auf 5.5 upgraden.

• innodb_adaptive_checkpoint; verwenden Sie stattdessen innodb_adaptive_flushing_method.
• innodb_auto_lru_dump; verwenden Sie stattdessen innodb_buffer_pool_restore_at_startup (und innodb_buffer_pool_load_at_startup in MariaDB 10.0).
• innodb_blocking_lru_restore; verwenden Sie stattdessen innodb_blocking_buffer_pool_restore.
• innodb_enable_unsafe_group_commit
• innodb_expand_import; verwenden Sie stattdessen innodb_import_table_from_xtrabackup.
• innodb_extra_rsegments; verwenden Sie stattdessen innodb_rollback_segments.
• innodb_extra_undoslots
• innodb_fast_recovery
• innodb_flush_log_at_trx_commit_session
• innodb_overwrite_relay_log_info
• innodb_pass_corrupt_table; verwenden Sie stattdessen innodb_corrupt_table_action.
• innodb_use_purge_thread
• xtradb_enhancements

XtraDB-Optionen, die ihre Voreinstellung geändert haben

Neue Optionen in XtraDB 5.5

Die folgenden neuen Optionen wurden bei XtraDB / InnoDB 5.5 ergänzt. (Hier aufgelistet, um alle XtraDB-Informationen an einer Stelle zu haben.)

• 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

Siehe auch Perconas Anleitung für den Upgrade auf 5.5

Inkompatibilitäten zwischen MariaDB 5.5 und MariaDB 5.3 und MySQL 5.5

• Views mit der Definition ALGORITHM=MERGE oder ALGORITHM=TEMPTABLE wurden zwischen MariaDB 5.2 und MariaDB 5.3 versehentlich vertauscht. Sie müssen Views mit einer dieser Definitionen neu erzeugen.
• INSERT IGNORE erzeugt auch eine Warnung für den Fehler bei einem doppelten Schlüssel. Sie können dies ausschalten, indem Sie OLD_MODE=NO_DUP_KEY_WARNINGS_WITH_IGNORE (see OLD_MODE) setzen.
• Vor MariaDB 5.5.31 arbeitete X'HHHH', die Standard-SQL-Syntax für binäre String-Literale, fälschlicherweise genauso wie 0xHHHH, was abhängig vom Kontext eine Zahl oder einen String ergab. Mit 5.5.31 wurde dies dahingehend korrigiert, dass es sich in jedem Kontext als String verhält (und nie als Zahl), was eine Inkompatibilität mit früheren Versionen von MariaDB and allen Versionen von MySQL schuf. Siehe CAST zu mehr Details und für ein Beispiel.
• Siehe auch die ausführliche Aufschlüsselung Unterschiede bei Systemvariablen zwischen MariaDB 5.5 und MySQL 5.5.

Inkompatibilitäten zwischen MariaDB 10.0 und MariaDB 5.5 / MySQL 5.5

• Die Syntax von SET OPTION ist seit MariaDB 10.0 und MySQL 5.6 abgekündigt. Verwenden Sie nur SET.

Inkompatibilitäten zwischen MariaDB 10.0 und MySQL 5.6

• Alle MySQL-Binärdateien (mysqld, myisamchk usw.) geben eine Warnung aus, wenn man den Präfix einer Option verwendet (wie --big-table anstatt --big-tables). MariaDB-Binärdateien arbeiten auf die gleiche Art wie die meisten anderen Unix-Kommandos und geben keine Warnung aus, wenn ein eindeutiger Präfix genutzt wird.
• MariaDB GTID ist nicht kompatibel mit MySQL 5.6. Das bedeutet, dass man MySQL 5.6 nicht als Slave für MariaDB 10.0 verwenden kann. Es kann jedoch MariaDB 10.0 ein Slave von MySQL 5.6 oder jeder früheren MySQL-/MariaDB-Version sein.
• Um CREATE TABLE … SELECT auf die gleiche Art bei anweisungs- und zeilenbasierter Replikation arbeiten zu lassen, wird es standardmäßig als CREATE OR REPLACE TABLE auf dem Slave ausgeführt. Ein Vorteil von diesem ist, dass es weiterarbeiten kann, wenn der Slave in der Mitte von CREATE … SELECT stirbt.
  • Man kann die Variable slave-ddl-exec-mode nutzen um festzulegen, wie CREATE TABLE und DROP TABLE repliziert wird.
• Siehe auch die ausführliche Aufschlüsselung Unterschiede bei Systemvariablen zwischen MariaDB 10.0 und MySQL 5.6.
• MySQL 5.6 hat performance schema standardmäßig aktiviert. Aus Performancegründen hat MariaDB 10.0 es standardmäßig deaktiviert. Sie können es aktivieren, indem Sie mysqld mit der Option --performance-schema aufrufen.

Alte, nicht unterstützte Konfigurationsoptionen

Wenn Sie eine der folgenden Optionen in Ihrer /etc/my.cnf- oder anderen my.cnf-Dateien verwenden, sollten Sie sie löschen. Das gilt auch für MySQL 5.1 oder später:

• skip-bdb

Ein MySQL-RPM ersetzen

Wenn Sie ein MySQL-RPM deinstallieren, um MariaDB zu installieren, beachten Sie, dass das MySQL-RPM beim Deinstallieren /etc/my.cnf zu /etc/my.cnf.rpmsave umbenennt.

Nach dem Installieren von MariaDB sollten Sie das Folgende tun, um Ihre alten Konfigurationsoptionen wiederherzustellen:

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

Inkompatibilitäten zwischen MariaDB und dem MySQL-Proxy

Eine MySQL-Client-API kann sich zu MariaDB über den MySQL-Proxy verbinden, aber eine MariaDB-Client-API wird Informationen mit dem Fortschrittsbericht erhalten, die der MySQL-Proxy nicht implementiert; um volle Kompatibilität in allen Fällen zu erhalten, deaktivieren Sie einfach Fortschrittsberichte auf der Client- oder Serverseite.

Related Links

• MariaDB versus MySQL – Features
• Umzug von MySQL
• Problemlösung bei der Installation
• Projekte und Anwendungen, die MariaDB einsetzen