WordPress-Datenbank auf eine aktuelle MariaDB-Version umstellen

Viele WordPress-Websites laufen seit Jahren auf derselben Datenbank, während sich die Software darunter weiterentwickelt hat. MariaDB 10.6 hat im Juli 2026 das Ende der Community-Wartung erreicht, ältere Versionen noch früher. Ohne Sicherheitsupdates ist die Datenbank ein Risiko, auch wenn die Website scheinbar normal läuft. Diese Anleitung zeigt, wie Sie die eingesetzte Version prüfen, den Umstieg auf eine aktuelle MariaDB-Version planen und die WordPress-Datenbank sicher auf einen neuen Datenbankserver übertragen. Der Umzug wurde im Labor mit WordPress 7.1.2 von MariaDB 11.8.9 auf eine zweite, separate MariaDB-Instanz 11.8.6 durchgespielt.

Voraussetzungen

• WordPress: aktuelle Version, hier 7.1.2. WordPress selbst setzt technisch nur MySQL 5.5.5 voraus, empfiehlt aber MariaDB 10.11 oder MySQL 8.0 und höher.
• PHP: mindestens 7.4 laut WordPress-API, empfohlen ist eine aktuelle, unterstützte Version wie PHP 8.4 mit der Erweiterung mysqli.
• Rolle: Administrator in WordPress und Zugang zur Datenbankverwaltung beim Hoster bzw. Root-Rechte auf dem eigenen Server.
• Zugriff: SSH mit WP-CLI für Export und Import. Ohne SSH nutzen Sie phpMyAdmin oder das Werkzeug Ihres Hosters, die Schritte bleiben gleich.
• Ziel-Datenbank: eine neue, leere Datenbank auf dem aktuellen MariaDB-Server mit eigenem Benutzer. Bei Webhosting legen Sie diese im Kundenbereich an, viele Hoster bieten dort die Wahl der Version.
• Backup: eine vollständige, geprüfte Sicherung von Dateien und Datenbank. Planen Sie ein Zeitfenster mit wenig Besuchern ein.

Schritt 1: Aktuelle Datenbankversion prüfen

Öffnen Sie „Werkzeuge > Website-Zustand“ und wechseln Sie zum Reiter „Bericht“. Im Abschnitt „Datenbank“ stehen „Server-Version“, „Client-Version“ und „Datenbank-Kollation“. Im Labor lautete die Anzeige „11.8.9-MariaDB“ bei der Kollation utf8mb4_unicode_520_ci. Liegt die Version unter der Empfehlung, meldet der Reiter „Zustand“ den Test „Veralteter SQL-Server“. Die Empfehlungswerte 10.11 für MariaDB und 8.0 für MySQL stehen so im Quellcode von WordPress 7.1.2.

Per WP-CLI erhalten Sie dieselben Angaben:

wp db query "SELECT VERSION();"
wp db query "SELECT TABLE_NAME, ENGINE, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA = DATABASE();"

Die zweite Abfrage zeigt Speicher-Engine und Kollation jeder Tabelle. Tabellen mit der Engine MyISAM oder einer Kollation ohne utf8mb4 stammen meist aus sehr alten Installationen oder von Plugins. Sie funktionieren oft weiter, verdienen aber nach dem Umzug einen genaueren Blick.

Verifizieren: Sie kennen Produkt (MariaDB oder MySQL), Version, Kollation und eventuelle Sonderfälle bei den Tabellen.

Schritt 2: Zielversion wählen

MariaDB veröffentlicht jährlich eine Version mit langer Wartung (LTS). Die MariaDB Foundation nennt für die Community-Ausgabe folgende Wartungsenden (Stand September 2026):

Version	Veröffentlicht	Community-Wartung bis
10.6 LTS	Juli 2021	6. Juli 2026 (abgelaufen)
10.11 LTS	Februar 2023	16. Februar 2028
11.4 LTS	Mai 2024	29. Mai 2029
11.8 LTS	Juni 2025	4. Juni 2028
12.3 LTS	Mai 2026	12. Juni 2029

Für eine Unternehmenswebsite ist eine LTS-Version die richtige Wahl, keine der dazwischen liegenden Kurzzeit-Versionen. Welche Versionen Sie tatsächlich wählen können, bestimmt meist Ihr Hoster oder die Paketquelle Ihrer Linux-Distribution. Auf dem eigenen Server ist die Version der Distribution oft die bequemste, weil Sicherheitsupdates dann automatisch über die Paketverwaltung kommen. Im Labor lieferte Debian 13 MariaDB 11.8.

Ein Wechsel von MySQL zu MariaDB ist möglich, aber kein reines Versions-Update. Beide Systeme haben sich seit Jahren auseinanderentwickelt. Der Weg über Export und Import aus Schritt 3 und 4 ist hier die sichere Variante, direkte Upgrades der Datendateien funktionieren zwischen den Produkten nicht zuverlässig. Im Labor akzeptierte MariaDB 11.8 eine Tabelle mit der MySQL-8-Kollation utf8mb4_0900_ai_ci. Prüfen Sie Ihren Export trotzdem auf einer Testinstanz.

Verifizieren: Sie haben eine Zielversion festgelegt, deren Wartung mindestens bis 2028 reicht, und wissen, ob Ihr Hoster oder Ihre Distribution sie anbietet.

Schritt 3: Datenbank sichern und exportieren

Der Export ist zugleich Ihr Backup für den Rückweg. Führen Sie ihn im WordPress-Verzeichnis aus und speichern Sie die Datei außerhalb des öffentlich erreichbaren Webordners:

wp db export ~/backup/wp-vor-umzug.sql
wp db query "SELECT COUNT(*) FROM wp_options;"

Notieren Sie das Ergebnis der zweiten Zeile. Sie ist eine einfache Kontrollzahl für den Vergleich nach dem Import. Im Labor ergab sie 127 Einträge vor und nach dem Umzug. Der Tabellenpräfix wp_ kann bei Ihnen anders lauten, er steht in der wp-config.php als $table_prefix.

Damit während des Exports keine neuen Daten verloren gehen, etwa Bestellungen oder Formulareingänge, schalten Sie die Website für die Dauer des Umzugs in den Wartungsmodus. Im Labor lieferte die Website danach Statuscode 503 mit dem Titel „Maintenance“:

wp maintenance-mode activate

Ein Hinweis zu den Werkzeugen: Neuere MariaDB-Pakete und -Container bringen mariadb-dump statt mysqldump mit. Wer eigene Skripte nutzt, sollte das prüfen. wp db export wählt das vorhandene Programm selbst, im Labor stand im Kopf der Datei „MariaDB dump“.

Verifizieren: Die SQL-Datei existiert, ist deutlich größer als null Byte und enthält für jede Tabelle eine Zeile CREATE TABLE. Die Zahl prüfen Sie mit grep -c "CREATE TABLE" ~/backup/wp-vor-umzug.sql, im Labor waren es 12 Tabellen.

Schritt 4: Neue Datenbank anlegen und importieren

Legen Sie auf dem neuen MariaDB-Server eine leere Datenbank mit Zeichensatz utf8mb4 und einen eigenen Benutzer an. Bei Webhosting geschieht das im Kundenbereich. Auf dem eigenen Server als Datenbank-Administrator:

CREATE DATABASE wpneu CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;
CREATE USER 'wpneu'@'localhost' IDENTIFIED BY 'ein-langes-zufaelliges-passwort';
GRANT ALL ON wpneu.* TO 'wpneu'@'localhost';

Ersetzen Sie Namen und Passwort durch eigene Werte. Der Benutzer erhält Rechte nur auf diese eine Datenbank, nicht auf den ganzen Server. Importieren Sie dann den Export:

mariadb -u wpneu -p wpneu < ~/backup/wp-vor-umzug.sql
mariadb -u wpneu -p wpneu -e "CHECK TABLE wp_posts, wp_options;"

Im Labor meldete CHECK TABLE für beide Tabellen den Status „OK“. Umlaute blieben erhalten: Der Titel „Testbeitrag Größe Übergang“ lag nach dem Import mit korrekten UTF-8-Bytes in der Datenbank. Das liegt daran, dass der Export den Zeichensatz der Verbindung selbst festlegt. Importieren Sie die Datei deshalb unverändert und öffnen Sie sie nicht in einem Editor, der die Kodierung umstellt.

Verifizieren: CHECK TABLE meldet „OK“, und SELECT COUNT(*) FROM wp_options; in der neuen Datenbank ergibt dieselbe Zahl wie in Schritt 3.

Schritt 5: WordPress auf die neue Datenbank umstellen

Sichern Sie die wp-config.php als Kopie. Tragen Sie dann die Zugangsdaten der neuen Datenbank ein:

define( 'DB_NAME', 'wpneu' );
define( 'DB_USER', 'wpneu' );
define( 'DB_PASSWORD', 'ein-langes-zufaelliges-passwort' );
define( 'DB_HOST', 'localhost' );

Läuft der Datenbankserver auf einem anderen Rechner oder Port, gehört das in DB_HOST, etwa 127.0.0.1:3307. Im Labor lief die neue MariaDB-Instanz genau so auf Port 3307, und WordPress lieferte nach dem Umstellen alle Beiträge aus. Ein kleines Prüfskript bestätigte, dass WordPress mit der Server-Version 11.8.6 und der Datenbank wpneu verbunden war.

Schalten Sie danach den Wartungsmodus mit wp maintenance-mode deactivate ab. Die alte Datenbank lassen Sie vorerst unverändert stehen. Treten Probleme auf, genügt es, die gesicherte wp-config.php zurückzukopieren.

Verifizieren: „Werkzeuge > Website-Zustand > Bericht“ zeigt im Abschnitt „Datenbank“ die neue Server-Version. Startseite, ein Beitrag, das Backend und ein Formular funktionieren.

Schritt 6: Upgrade am selben Server nachbereiten

Aktualisieren Sie MariaDB nicht per Umzug, sondern direkt auf dem bestehenden Server über die Paketverwaltung, gilt eine zusätzliche Pflicht. Laut MariaDB-Dokumentation sollten Sie nach dem Upgrade auf eine neue Hauptversion mariadb-upgrade ausführen. Das Programm prüft alle Tabellen und aktualisiert die Systemtabellen auf das Format der neuen Version:

sudo mariadb-upgrade

Auf einer bereits aktuellen Installation antwortete das Programm im Labor mit „This installation of MariaDB is already upgraded to 11.8.6-MariaDB. There is no need to run mariadb-upgrade again.“ Diese Meldung ist harmlos. Viele Distributionspakete führen den Schritt beim Update bereits selbst aus. Springen Sie nicht über mehrere Hauptversionen auf einmal, ohne die Upgrade-Hinweise von MariaDB für jede übersprungene Version zu lesen. Der Umzug in eine neue Datenbank aus den Schritten 3 bis 5 umgeht dieses Risiko, weil die Daten per SQL neu geschrieben werden.

Datenbank-Updates sind wie WordPress-Updates keine einmalige Aufgabe. Sicherheitsupdates für MariaDB erscheinen laufend, und in einigen Jahren steht der nächste Versionswechsel an. Wer die Pflege auf WordPress-Ebene nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung und wöchentliche Backups auf externen Speicher mit vier Wochen Aufbewahrung.

Verifizieren: mariadb-upgrade meldet keinen Fehler oder bestätigt, dass die Installation bereits aktuell ist. SELECT VERSION(); zeigt die neue Version.

Typische Fehler

• „Error establishing a database connection“: WordPress erreicht die Datenbank nicht. Im Labor erschien die Meldung mit Statuscode 500 nach einem falschen Port in DB_HOST. Prüfen Sie Name, Benutzer, Passwort und Host in der wp-config.php und ob der Datenbankserver läuft.
• Umlaute als Fragezeichen oder „ä“: Der Export wurde mit falscher Kodierung verändert oder mit einem abweichenden Zeichensatz importiert. Importieren Sie die unveränderte Datei erneut in eine leere Datenbank.
• mysqldump: command not found: Neuere MariaDB-Installationen liefern mariadb-dump. Nutzen Sie dieses Programm oder wp db export.
• Neue Beiträge oder Bestellungen fehlen nach dem Umzug: Die Website war während des Exports erreichbar. Deshalb den Wartungsmodus für die Dauer des Umzugs aktivieren.
• Plugin meldet Datenbankfehler nach dem Wechsel von MySQL: Einzelne Plugins nutzen herstellerspezifische SQL-Funktionen. Testen Sie den Wechsel zwischen MySQL und MariaDB immer zuerst auf einer Staging-Kopie.

Häufige Fragen

Merken Besucher etwas vom Umzug?

Nur für die Dauer des Wartungsmodus. Bei kleinen Unternehmenswebsites dauern Export und Import meist wenige Minuten, abhängig von der Größe der Datenbank.

Muss ich danach etwas in WordPress anpassen?

Nein. Die Adressen der Website bleiben gleich, daher ist kein wp search-replace nötig. Nur die Zugangsdaten in der wp-config.php ändern sich.

Wann kann ich die alte Datenbank löschen?

Wenn die Website einige Tage fehlerfrei mit der neuen Datenbank läuft und mindestens ein reguläres Backup der neuen Datenbank vorliegt. Die alte Datenbank enthält personenbezogene Daten und sollte dann gelöscht werden.

Kann ich die Umstellung meinem Hoster überlassen?

Bei Webhosting ja, dort liegt der Datenbankserver in der Verantwortung des Hosters. Fragen Sie nach, welche Version im Einsatz ist und wann ein Wechsel geplant ist.

Testumfang

Im Labor mit WordPress 7.1.2 (deutsch), PHP 8.4.26 und WP-CLI 2.12.0 durchgespielt: Versionsanzeige unter „Website-Zustand“, Empfehlungswerte im Quellcode, Export mit wp db export, zweite MariaDB-Instanz 11.8.6 aus Debian 13 auf Port 3307, neue Datenbank mit eigenem Benutzer, Import, CHECK TABLE, Umlaut-Prüfung, Umstellung der wp-config.php, Fehlerbild bei falschem Port, Wartungsmodus mit Statuscode 503, mariadb-upgrade auf aktueller Installation, MySQL-8-Kollation unter MariaDB 11.8. Nicht getestet: ein echtes In-Place-Upgrade über mehrere Hauptversionen und die Migration aus einer produktiven MySQL-Datenbank.

Fazit

Der sicherste Weg auf eine aktuelle MariaDB-Version führt über eine neue, leere Datenbank: exportieren, importieren, Zugangsdaten umstellen. Die alte Datenbank bleibt als Rückweg unangetastet, und der Wechsel dauert für Besucher nur wenige Minuten. Wählen Sie eine LTS-Version und prüfen Sie die Datenbankversion künftig bei jeder Wartungsrunde mit. Wer Updates und Backups dauerhaft abgeben möchte, findet diese Unterstützung bei der WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• WordPress-Datenbank mit WP-CLI sichern und wiederherstellen
• PHP-Version für WordPress aktualisieren und Kompatibilität prüfen
• Staging-Umgebung für WordPress einrichten
• WordPress: Anforderungen
• MariaDB Foundation: Wartungsrichtlinie und Versionen
• MariaDB-Dokumentation: mariadb-upgrade
• WP-CLI: wp db export