18. Dezember 2019
Nachdem ich inzwischen einige Upgrades von MariaDB 10.3 nach MariaDB 10.4 begleitet oder durchgeführt habe hier ein paar Erfahrungen mit diesem Vorhaben. Dabei möchte ich sowohl auf das Upgrade von einzelnen Datenbankservern wie auch auf Cluster eingehen.
MariaDB 10.4 bringt eine Reihe Neuerungen, die man beim Upgrade mit berücksichtigen sollte.
ARIA Systemtabellen
Ab Version 10.4 sind die Systemtabellen im mysql-Schema nicht mehr als MyISAM Tabellen angelegt sondern als ARIA. Zudem wurde die Tabelle mysql.user durch eine View ersetzt, die Lesezugriffe wie auf die Tabelle bis Version 10.3 erlaubt. Die Informationen aus der ehemaligen user-Tabelle finden sich jetzt in der Tabelle mysql.global_priv. Beim Upgrade ist es deshalb wichtig das Dienstprogramm mysql_upgrade nach dem Start des Servers auszuführen, damit diese Anpassungen gemacht werden.
Authentifizierung und Accounts
Ab Version 10.4 ist das auth_socket Plugin per Default aktiviert. Zudem können jetzt jedem Benutzer mehrere Authentifizierungsverfahren zugeordnet werden. Bei Neuinstallationen werden automatisch die Benutzer root und mysql so angelegt. Damit kann der Linux Benutzer root sich ohne Passwort einloggen. Beim Upgrade allerdings werden die User nicht entsprechend aktualisiert. Dies muss man explizit nachvollziehen, wenn man diese Funktionalität nutzen will.
ALTER USER 'root'@'localhost' IDENTIFIED VIA unix_socket OR mysql_native_password USING password('your_password');ALTER USER 'root'@'127.0.0.1' IDENTIFIED VIA unix_socket OR mysql_native_password USING password('your_password');CREATE USER mysql@localhost IDENTIFIED VIA unix_socket OR mysql_native_password USING 'invalid'
Danach kann man dem User mysql entsprechende Rechte erteilen. Bei einer Neuinstallation erhält 'mysql'@'localhost' alle Rechte mit GRANT OPTION. Dies ist aus meiner Sicht nicht unbedingt sinnvoll. Eine sinnvolle Anwendung des Users mysql ist für Backups. Gerade bei der Automatisierung von Backups hat man immer wieder das Problem, dass man das Passwort des Backup-Users irgendwo hinterlegen muss. Zudem benötigt der Backup-Prozess Leserechte auf dem Datenverzeichnis. Da der Linux-Benutzer mysql genau die Dateisystemrechte hat, die man für das Backup braucht, eignet sich dieser User hervorragend für das Backup. Als Backup-User benötigt 'mysql'@'localhost' für MariaDB Backup die Rechte RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT. Das entsprechende GRANT Statement lautet also:
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'mysql'@'localhost'
Neben dem bisherigen Passwort-Hash kann jetzt auch ed25519 als Hash-Algorithmus verwendet werden. Für eine sanfte Migration auf diese Möglichkeit kann die Authentifizierung mit ed25519 als zusätzliche Authentifizierungsart hinzugefügt werden und nach einer Übergangsphase kann man dann das mysql_native_password entfernen und das Plugin deaktivieren.
Ebenfalls neu in 10.4 sind die Möglichkeiten der Password Expiry und des Account Locking.
Nähere Informationen dazu erhält man in der MariaDB Knowledgebase.
Verbesserungen in InnoDB
In InnoDB wurden weitere Schema Changes ohne Neuaufbau (Rebuild) der Tabelle und damit längerer Sperre realisiert. Dazu gehören das INSTANT DROP COLUMN und Typänderungen von CHAR und VARCHAR Feldern sowie Änderungen des Character Sets und der Collation für nicht indizierte Spalten. Zudem wurden weitere interne Verbesserungen umgesetzt, die sich positiv auf die Performance auswirken dürften.
Galera Cluster
Mit MariaDB 10.4 kommt nun auch Galera in der Version 4 zum Einsatz. Diese bietet als wichtigste Neuerung die Streaming Replication. Mit den beiden Variablen
kann diese Funktion konfiguriert werden. Damit fällt auch die Grenze für die Write Set Größe.
Die Änderungen bei InnoDB seit Version 10.3 in bezug auf Online Schema Changes kommen auch dem Galera Cluster zu gute. Da nun viele Schema Changes ohne Rebuild möglich sind, sind auf diese Weise durchführbare Änderungen nicht mehr in dem Maße blockierend für den Cluster. Zwar wird der Cluster im TOI-Modus (Total Order Isolation) weiterhin bis zur Durchführung des entsprechenden Schema Changes isoliert, da die meisten dieser Änderungen kaum mehr Ressourcen und Zeit benötigen wie ein INSERT oder UPDATE auf eine Zeile ist diese Isolationszeit allerdings sehr kurz.