MariaDB 10.4 ist ein aktueller Entwicklungszweig von MariaDB. Kürzlich, am 21. Mai, wurde der dritte Release Candidate (10.4.5) veröffentlicht, was uns der offiziellen Veröffentlichung näher bringt. Aus diesem Grund hielten wir es für eine gute Idee, einen Blick auf die neuen Funktionen von 10.4 zu werfen. Wir werden auch einige Gedanken zu einem kürzlich von MariaDB Corporation veröffentlichten Blogbeitrag teilen. Informationen zum Release selbst finden Sie im Changelog von MariaDB 10.4.0.
Leistungsänderungen
Unicode-Zeichensätze sind normalerweise langsamer als Zeichensätze wie latin1, hauptsächlich aufgrund ihrer Größe. MySQL 8.0 brachte in diesem Bereich deutliche Verbesserungen, und auch MariaDB 10.4 sollte in dieser Hinsicht merklich schneller sein als 10.3. Es ist eine ziemlich wichtige Verbesserung – die Leute lieben es wirklich, Emojis zu verwenden, für die UTF8 aktiviert sein muss. Am Optimierer wurde einige Arbeit geleistet - MariaDB 10.4 sollte besser für IN()-Unterabfragen funktionieren, da es jetzt möglich ist, Bedingungen in materialisierte Unterabfragen zu verschieben.
Das Starten und Stoppen von InnoDB kann je nach Datenmenge in Redo-Logs eine Weile dauern. MariaDB 10.4 wird das Starten, Herunterfahren und Löschen verbessern. Solche Verbesserungen sind angesichts der Beliebtheit von Hot-Backup-Tools wie mariabackup und xtrabackup besonders wichtig. Diese Tools durchlaufen am Ende den InnoDB-Startprozess von einem unsauberen Herunterfahren, wenn sie Redo-Protokolle anwenden, daher sollte jede Verbesserung in diesem Bereich die Zeit reduzieren, die zum Wiederherstellen von Backups benötigt wird.
InnoDB-Änderungen
MariaDB 10.4 hat eine sofortige DROP COLUMN-Operation erhalten. Es ist jetzt auch möglich, die Spalten in der Tabelle neu anzuordnen, ohne sie neu erstellen zu müssen. Wir können nicht betonen, wie wichtig das ist. Sie fragen sich vielleicht, was die häufigsten Vorgänge sind, die Sie in der Produktionsumgebung ausführen? Wir würden sagen, es wird ein Index hinzugefügt oder entfernt. Eine weitere häufigste Operation wären Operationen an den Spalten - fügen Sie eine neue Spalte hinzu und entfernen Sie eine vorhandene Spalte. Bisher bestand der häufigste Ansatz darin, externe Tools zu verwenden, um die Arbeit zu erledigen:pt-online-schema-change oder neuerdings gh-ost. Beide haben ihre Einschränkungen (Ghost funktioniert zum Beispiel nicht für Galera Cluster), die es unmöglich machen können, sie auf Ihrem System zu verwenden. Besonders heikel sind Fremdschlüssel. Mit Instant DROP COLUMN (Instant ADD COLUMN ist bereits verfügbar) kann ein großer Teil der Schemaänderungen ad hoc durchgeführt werden, ohne detaillierte Zeitplanung und Planung, wie es jetzt getan werden muss. Es ist wichtig, im Hinterkopf zu behalten, dass sofortige Änderungen das sind, was wir haben wollen. Es gibt nicht blockierende Schemaänderungen wie das Erstellen eines Index, aber solche Vorgänge stellen eine ernsthafte Herausforderung dar, wenn die Replikation verwendet wird, da sie eine Replikationsverzögerung verursachen. Obwohl die Operation auf einem Live-System hätte ausgeführt werden können, ziehen wir es daher vor, Workarounds wie pt-online-schema-change zu verwenden, um eine bessere Kontrolle über den Prozess zu behalten.
Dies ist nicht die einzige Verbesserung bei der Ausführung von Schemaänderungen. MariaDB 10.4 profitiert von einer schnelleren Erweiterung von VARCHAR-Spalten, zusätzlich werden Zeichensatz- und Sortierungsänderungen für nicht indizierte Spalten sofort vorgenommen.
Allgemeine Änderungen
Eine der größten Änderungen sind Änderungen in der Benutzerverwaltung. Die Tabelle mysql.host wird nicht erstellt, die Tabelle mysql.user ist veraltet. Benutzerkonten und globale Berechtigungen werden in der Tabelle mysql.global_priv gespeichert. Dies ist möglicherweise eine schwerwiegende Änderung für alle Tools (einschließlich ClusterControl), die eine Option zum Verwalten von MySQL- und MariaDB-Benutzern haben – es müssen neue Fälle geschrieben werden, um die Benutzerverwaltung in MariaDB 10.4 und höher abzudecken. Obwohl wir anerkennen, dass Änderungen erforderlich sind, trägt dies definitiv nicht dazu bei, Tools sowohl für MariaDB als auch für MySQL zu warten, wodurch die Tooling-Landschaft noch mehr gespalten wird, als sie bereits ist. Apropos Benutzer:MariaDB 10.4 bietet eine Option zum Ablaufen des Benutzerkennworts. Dies ist definitiv ein Schritt in eine gute Richtung – es hilft, bewährte Praktiken in Bezug auf die Passwortverwaltung durchzusetzen.
Auch wenn wir in einem separaten Blog ausführlicher darauf eingehen, müssen wir hier die Unterstützung für Galera 26.4 erwähnen - MariaDB 10.4 wird von einer neuen Galera-Version mit Funktionen wie Streaming-Replikation oder verbessertem SST dank Backup-Sperren profitieren.
Schließlich können Sie in MariaDB 10.4 sql_mode=MSSQL festlegen. Dies ist eine anfängliche Implementierung, aber sql_mode=ORACLE war irgendwann auch eine anfängliche Implementierung. Dies zeigt den Fokus von MariaDB auf Unternehmenskunden – wenn sich Oracle-Kunden für eine Migration entscheiden, ist es sehr wahrscheinlich, dass die Akzeptanz von MariaDB bei Microsoft SQL Server ebenfalls zunehmen wird, da mehr Funktionen hinzugefügt werden und die Migration weniger problematisch wird.
MariaDB ist ein Fork
Vor kurzem haben wir einen Blogbeitrag gesehen, in dem die Haltung von MariaDB zu InnoDB-Änderungen und -Kompatibilität erläutert wird. Das Wesentliche ist, dass MariaDB InnoDB-Funktionen nicht mehr mit MySQL zusammenführen wird, der Fokus wird auf der Stabilitäts- und Leistungsverbesserung von MariaDB liegen. Dies bedeutet im Grunde, dass MariaDB mit MySQL inkompatibel wird. Auch wenn Sie in der Vergangenheit das binäre Upgrade durchführen konnten, wird dies in Zukunft nicht mehr möglich sein. Selbst jetzt kann es schwierig sein, es auszuführen. Dies erhöht die Bedeutung von Tools wie mydumper/myloader, da ein logisches Backup der einzige Weg für die Migration sein wird. Was gut ist, MariaDB wird in der Lage sein, die Stabilität ihres Forks von InnoDB zu besitzen – sie müssen sich nicht mit Problemen befassen, die von Upstream-Entwicklern eingeführt werden, daher können wir damit rechnen, dass weniger Fehler eingeführt werden.
In Bezug auf die Leistung müssen wir auf Benchmarks warten, aber angesichts der historischen Daten können wir davon ausgehen, dass MariaDB langsamer als MySQL sein wird. In den vergangenen Benchmarks sehen wir typischerweise, dass die Leistungssteigerung für MariaDB einsetzt, wenn eine neuere InnoDB-Version integriert wurde. Dies wird nicht mehr der Fall sein, weshalb wir uns fragen, wie MariaDB von nun an im Leistungsvergleich abschneiden wird und ob die von MariaDB eingeführten Verbesserungen ausreichen werden, um mit MySQL 8.0 und weiteren Versionen mitzuhalten.
All dies bedeutet für uns Benutzer, dass MariaDB 10.4 stabiler sein sollte als die vorherigen Versionen. Es bedeutet auch, dass wir irgendwann die Interna von zwei verschiedenen Speicher-Engines lernen müssen – besonders wenn uns die Leistung wichtig ist. Das ist alles andere als ideal, aber so ist es. Tools müssen so entworfen werden, dass sie mit der einen oder anderen Version von InnoDB funktionieren (oder zusätzliche Arbeit muss hinzugefügt werden, um sowohl MySQL als auch MariaDB zu unterstützen). Wir werden beobachten, wie sich dies entwickelt. Wenn Sie darüber nachdenken, ist es kein so überraschender Schritt - MariaDB musste sich immer Zeit nehmen, um sich in neuere InnoDB-Versionen zu integrieren. Da immer mehr inkompatible Funktionen zu MariaDB hinzugefügt werden und große Änderungen in MySQL 8.0 eingeführt werden, ist es sinnvoll, sich auf die Entwicklung neuer Funktionen zu konzentrieren, anstatt inkompatible InnoDB von Upstream-MySQL zu portieren.
Wir hoffen, dass Ihnen dieser kurze Blogbeitrag einen Einblick in die Änderungen gegeben hat, die die Produktionssysteme treffen werden, wenn Sie zu MariaDB 10.4 wechseln.
