Migration von MySQL Enterprise zu MariaDB 10.3

MariaDB hat zwar dasselbe Erbe wie MySQL, ist aber eine andere Datenbank. Im Laufe der Jahre, als neue Versionen von MySQL und MariaDB veröffentlicht wurden, haben sich beide Projekte in zwei verschiedene RDBMS-Plattformen unterschieden.

MariaDB wird auf vielen Linux-Plattformen zur Hauptdatenbank-Distribution und erfreut sich heutzutage großer Beliebtheit. Gleichzeitig wird es für viele Unternehmen zu einem sehr attraktiven Datenbanksystem. Es erhält Funktionen, die den Unternehmensanforderungen nahe kommen, wie Verschlüsselung, Hot-Backups oder Kompatibilität mit proprietären Datenbanken.

Aber wie wirken sich neue Funktionen auf die MariaDB-Kompatibilität mit MySQL aus? Ist es immer noch Drop-Replacement für MySQL? Wie verstärken die neuesten Änderungen den Migrationsprozess? Wir werden versuchen, das in diesem Artikel zu beantworten.

Was Sie vor dem Upgrade wissen müssen

MariaDB und MySQL haben sich in den letzten zwei Jahren erheblich voneinander unterschieden, insbesondere mit der Einführung ihrer neuesten Versionen:MySQL 8.0, MariaDB 10.3 und MariaDB 10.4 RC (wir haben vor kurzem über neue Funktionen von MariaDB 10.4 RC gesprochen, also wenn Sie möchten Lesen Sie mehr darüber, was in 10.4 ansteht, lesen Sie bitte zwei Blogs meines Kollegen Krzysztof, What's New in MariaDB 10.4 und zweitens What's New in MariaDB Cluster 10.4).

Mit der Veröffentlichung von MariaDB 10.3 überraschte MariaDB viele, da es kein Drop-in-Ersatz für MySQL mehr ist. MariaDB führt keine neuen MySQL-Funktionen mehr mit MariaDB Noir zusammen, um MySQL-Fehler zu lösen. Dennoch entwickelt sich Version 10.3 nun zu einer echten Alternative zu Oracle MySQL Enterprise sowie anderen unternehmenseigenen Datenbanken wie Oracle 12c (MSSQL in Version 10.4).

Vorprüfung und Einschränkungen

Die Migration ist ein komplexer Prozess, unabhängig davon, auf welche Version Sie aktualisieren. Es gibt ein paar Dinge, die Sie bei der Planung beachten müssen, wie z. B. wesentliche Änderungen zwischen RDBMS-Versionen sowie detaillierte Tests, die jeden Upgrade-Prozess leiten müssen. Dies ist besonders wichtig, wenn Sie die Verfügbarkeit für die Dauer des Upgrades aufrechterhalten möchten.

Ein Upgrade auf eine neue Hauptversion ist mit Risiken verbunden, und es ist wichtig, den gesamten Prozess sorgfältig zu planen. In diesem Dokument sehen wir uns die wichtigen neuen Änderungen in der Version 10.3 (und der kommenden Version 10.4) an und zeigen Ihnen, wie Sie den Testprozess planen.

Um das Risiko zu minimieren, werfen wir einen Blick auf die Plattformunterschiede und -beschränkungen.

Beginnend mit der Konfiguration gibt es einige Parameter, die unterschiedliche Standardwerte haben. MariaDB stellt eine Matrix von Parameterunterschieden bereit. Es kann hier gefunden werden.

In MySQL 8.0 ist caching_sha2_password das Standard-Authentifizierungs-Plugin. Diese Erweiterung sollte die Sicherheit verbessern, indem der SHA-256-Algorithmus verwendet wird. MySQL hat dieses Plugin standardmäßig aktiviert, während MariaDB dies nicht tut. Obwohl es bereits eine Feature-Anfrage mit MariaDB MDEV-9804 gibt. MariaDB bietet stattdessen das ed25519-Plugin an, das eine gute Alternative zur alten Authentifizierungsmethode zu sein scheint.

MariaDBs Unterstützung für die Verschlüsselung von Tabellen und Tablespaces wurde in Version 10.1.3 hinzugefügt. Da Ihre Tabellen verschlüsselt sind, ist es fast unmöglich, Ihre Daten zu stehlen. Diese Art der Verschlüsselung ermöglicht es Ihrem Unternehmen auch, behördliche Vorschriften wie die DSGVO einzuhalten.

MariaDB unterstützt Verbindungs-Thread-Pools, die in Situationen am effektivsten sind, in denen Abfragen relativ kurz sind und die Last CPU-gebunden ist. In der Community Edition von MySQL ist die Anzahl der Threads statisch, was die Flexibilität in diesen Situationen einschränkt. Der Unternehmensplan von MySQL enthält Threadpool-Funktionen.

MySQL 8.0 enthält das sys-Schema, eine Reihe von Objekten, die Datenbankadministratoren und Softwareingenieuren dabei helfen, die vom Performance-Schema gesammelten Daten zu interpretieren. Sys-Schema-Objekte können für Optimierungs- und Diagnoseanwendungsfälle verwendet werden. MariaDB enthält diese Erweiterung nicht.

Ein weiteres sind unsichtbare Spalten. Unsichtbare Spalten bieten die Flexibilität, Spalten zu vorhandenen Tabellen hinzuzufügen, ohne befürchten zu müssen, dass eine Anwendung beschädigt wird. Diese Funktion ist in MySQL nicht verfügbar. Es ermöglicht das Erstellen von Spalten, die nicht in den Ergebnissen einer SELECT *-Anweisung aufgeführt sind, noch muss ihnen in einer INSERT-Anweisung ein Wert zugewiesen werden, wenn ihr Name nicht in der Anweisung erwähnt wird.

MariaDB hat sich entschieden, keine native JSON-Unterstützung (eine der Hauptfunktionen von MySQL 5.7 und 8.0) zu implementieren, da sie behauptet, dass es nicht Teil des SQL-Standards ist. Stattdessen haben sie zur Unterstützung der Replikation von MySQL nur einen Alias ​​für JSON definiert, der eigentlich eine LONGTEXT-Spalte ist. Um sicherzustellen, dass ein gültiges JSON-Dokument eingefügt wird, kann die Funktion JSON_VALID als CHECK-Einschränkung verwendet werden (Standard für MariaDB 10.4.3). MariaDB kann nicht direkt auf das MySQL-JSON-Format zugreifen.

Oracle automatisiert viele Aufgaben mit MySQL Shell. Zusätzlich zu SQL bietet MySQL Shell auch Skriptfunktionen für JavaScript und Python.

Migrationsprozess mit mysqldump

Sobald wir unsere Einschränkungen kennen, ist der Installationsprozess ziemlich einfach. Es ist ziemlich verwandt mit der Standardinstallation und dem Import mit mysqldump. Das Sicherungstool MySQL Enterprise ist nicht mit MariaDB kompatibel, daher wird die Verwendung von mysqldump empfohlen. Hier ist der Beispielprozess, der auf Centos 7 und MariaDB 10.3 ausgeführt wird.

Dump auf dem MySQL Enterprise-Server erstellen

$ mysqldump --routines --events --triggers --single-transaction db1 > export_db1.sql

Bereinigen Sie den Yum-Cache-Index

sudo yum makecache fast

Installieren Sie MariaDB 10.3

sudo yum -y install MariaDB-server MariaDB-client

Starten Sie den MariaDB-Dienst.

sudo systemctl start mariadb
sudo systemctl enable mariadb

Sichern Sie MariaDB, indem Sie mysql_secure_installation ausführen.

# mysql_secure_installation 

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user.  If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none): 
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

Set root password? [Y/n] y
New password: 
Re-enter new password: 
Password updated successfully!
Reloading privilege tables..
 ... Success!


By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y
 ... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y
 ... Success!

Cleaning up...

All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!

Dump importieren

Mysql -uroot -p
> tee import.log
> source export_db1.sql
Review the import log.

$vi import.log

Um eine Umgebung bereitzustellen, können Sie auch ClusterControl verwenden, das eine Option zur Bereitstellung von Grund auf bietet.

ClusterControl kann auch verwendet werden, um eine Replikation einzurichten oder ein Backup von MySQL Enterprise Edition zu importieren.

Migrationsprozess mit Replikation

Der andere Ansatz für die Migration zwischen MySQL Enterprise und MariaDB ist die Verwendung des Replikationsprozesses. MariaDB-Versionen ermöglichen die Replikation von MySQL-Datenbanken zu ihnen – was bedeutet, dass Sie MySQL-Datenbanken problemlos zu MariaDB migrieren können. MySQL Enterprise-Versionen erlauben keine Replikation von MariaDB-Servern, daher ist dies eine Einbahnstraße.

Hier sind einige allgemeine Regeln, auf die MariaDB hinweist.

• Die Replikation von MySQL 5.5 auf MariaDB 5.5+ sollte einfach funktionieren. Sie möchten, dass MariaDB die gleiche oder eine höhere Version als Ihr MySQL-Server hat.
• Wenn Sie MariaDB 10.2+ als Slave verwenden, kann es notwendig sein, binlog_checksum auf NONE zu setzen.
• Die Replikation von MySQL 5.6 ohne GTID auf MariaDB 10+ sollte funktionieren.
• Die Replikation von MySQL 5.6 mit GTID, binlog_rows_query_log_events und ignorierbaren Ereignissen funktioniert ab MariaDB 10.0.22 und MariaDB 10.1.8. In diesem Fall entfernt MariaDB die MySQL-GTIDs und andere unnötige Ereignisse und fügt stattdessen ihre eigenen GTIDs hinzu.

Auch wenn Sie nicht vorhaben, die Replikation im Migrations-/Umstellungsprozess zu verwenden, ist es ein guter Vertrauensaufbau, Ihren Produktionsserver in einer Test-Sandbox zu replizieren und dann darauf zu üben.

Wir hoffen, dass dieser einführende Blogbeitrag Ihnen geholfen hat, den Bewertungs- und Implementierungsprozess der MySQL Enterprise Migration zu MariaDB zu verstehen.