MariaDB aktualisieren: Upgrade & EOL auf dem Managed Server

Die MariaDB-Version auf deinem Managed Server aktualisieren wir auf Zuruf — du beauftragst das Upgrade formlos per Ticket. Deine Datenbanken, Benutzer und Rechte bleiben dabei erhalten; die Datenbank ist nur ca. 1–2 Minuten nicht erreichbar. Dieser Artikel klärt vorab die drei wichtigen Fragen: Wie dringend ist ein EOL-Stand wirklich, welche Version passt zu deiner Anwendung, und wie sieht der Rückweg aus.

Gilt für Managed Server

Auf Managed-Hosting-Tarifen (geteilte Plattform) verwalten wir die Datenbank-Versionen zentral — dort musst du nichts beauftragen.

Was bedeutet EOL bei MariaDB?

EOL End of Life — der Hersteller liefert für diese Versionslinie keine Updates mehr, auch keine Sicherheits-Fixes. heißt: Für diese MariaDB-Linie erscheinen keine Sicherheits-Updates mehr. Das klingt dramatischer, als es im Server-Alltag ist. In der Standard-Konfiguration ist die Datenbank nur intern erreichbar — sie lauscht nicht offen im Internet und ist von außen nicht direkt angreifbar. Der realistische Angriffsweg führt über deine Webanwendung, nicht über den Datenbank-Port.

Ein Freifahrtschein ist das trotzdem nicht. Wird eine Lücke bekannt, die sich über die Anwendung ausnutzen lässt, bekommt eine EOL-Version keinen Fix mehr. Unsere Empfehlung deshalb: kein Notfall, aber ein geplantes Upgrade — so wenig EOL-Software wie möglich im Einsatz.

Dass auf einem neueren Server eine ältere MariaDB läuft, ist übrigens kein Versehen: Die Version wird bei der Auslieferung passend zur Anwendung gewählt und danach nicht automatisch auf die nächste Hauptversion gehoben. Ein Major-Upgrade kann Anwendungen brechen — diesen Schritt gehen wir nur mit dir zusammen.

Support-Status der MariaDB-Versionen

Wir installieren die LTS Long-Term Support — Versionslinie mit mehrjährigem Wartungszeitraum, im Gegensatz zu kurzlebigen Zwischenversionen. -Linien von MariaDB. Status-Stand: August 2026 — die tagesaktuellen Laufzeiten listet endoflife.date/mariadb.

MariaDB-Version	Support-Status
11.4	Aktiv — Support bis Mai 2029
10.11	Aktiv — Support bis Februar 2028
10.6	EOL seit Juli 2026
10.5	EOL seit Sommer 2025

Für Upgrades empfehlen wir entsprechend 10.11 oder 11.4. MariaDB veröffentlicht laufend neuere Linien — ob eine davon für deinen Server schon bereitsteht, klärst du direkt im Upgrade-Ticket.

Welche MariaDB-Version für welche Anwendung?

Maßgeblich sind die Systemanforderungen des Herstellers, nicht das Bauchgefühl. Für die aktuellen Versionen der gängigen Anwendungen sieht die Lage so aus (Stand: August 2026):

Anwendung	Unterstützte MariaDB-Version
Magento 2.4.8	11.4 — die Folgeversion 2.4.9 streicht 10.6
Shopware 6.7	ab 10.11 — 11.4 damit eingeschlossen
WordPress (aktuell)	ab 10.11 empfohlen

Die Faustregel: die neueste LTS-Linie, die deine Anwendung offiziell unterstützt. Für die aktuellen Versionen aller drei Anwendungen ist das MariaDB 11.4.

Ältere Anwendungs-Versionen

Läuft dein Projekt noch auf einer älteren Version (z. B. Magento 2.4.6), gilt deren eigene Kompatibilitäts-Matrix — dann meist erst die Anwendung aktualisieren, danach die Datenbank. Die Reihenfolge klären wir gern mit dir im Ticket.

Vor dem Upgrade klären

Aktuelle Version prüfen: phpMyAdmin zeigt die Server-Version auf der Startseite rechts. Alternativ per SSH:

mysql -e "SELECT VERSION();"

Zielversion wählen: anhand der beiden Tabellen oben — die neueste LTS-Linie, die deine Anwendung offiziell unterstützt.

Backup anlegen: Vor dem Upgrade brauchst du einen aktuellen Export deiner Datenbanken. Er ist dein Rückweg, falls die Anwendung mit der neuen Version nicht zurechtkommt.

Vorher testen statt hoffen

Wenn du auf Nummer sicher gehen willst: Spiel deinen Dump in eine Test-Datenbank auf einer Umgebung mit der Zielversion ein und klick die Anwendung einmal durch. Sprich uns an — für solche Tests richten wir dir gern eine Testumgebung ein.

So läuft das Upgrade ab

1. Wähle die Zielversion anhand der Systemanforderungen deiner Anwendung.
2. Erstelle ein aktuelles Backup deiner Datenbanken.
3. Eröffne ein Ticket im Kundencenter mit Zielversion und Wunschtermin.
4. Wir spielen das Upgrade zum vereinbarten Termin ein. Die Datenbank ist dabei ca. 1–2 Minuten nicht erreichbar; alle Daten und Benutzer bleiben bestehen.
5. Prüfe danach deine Anwendung: Startseite, Login, bei Shops ein Test-Checkout — und wirf einen Blick ins Error-Log.

Wenn etwas schiefläuft

Die Anwendung meldet nach dem Upgrade Datenbank-Fehler

Die Anwendungs-Version ist zu alt für die neue MariaDB — einzelne SQL-Konstrukte oder Verhaltensweisen haben sich zwischen den Hauptversionen geändert.

Lösung: Fehlermeldung aus dem Error-Log kopieren und an den Support schicken. Lässt sich das Problem nicht schnell beheben, stellen wir die alte Version wieder her und spielen dein Backup zurück.

Während des Upgrade-Fensters: Verbindungsfehler oder Fehler 500

Kein Grund zur Sorge — während der 1–2 Minuten Umbauzeit nimmt die Datenbank keine Verbindungen an, die Website zeigt solange Fehler.

Lösung: Abwarten. Leg den Wunschtermin in eine besucherarme Zeit, bei Shops z. B. früh morgens.

Du willst zurück zur alten Version

Ein Downgrade auf den alten Datenbestand ist nicht vorgesehen — das Upgrade migriert das interne Datenformat, der Weg zurück führt nicht in-place.

Lösung: Rollback heißt: alte MariaDB-Version plus Einspielen deines Dumps. Genau dafür ist das Backup aus Schritt 2 da. Melde dich per Ticket, wir begleiten den Rückweg.

Verwandte Artikel

• MySQL-Datenbank sichern (Export) — das Pflicht-Backup vor jedem Upgrade.
• MySQL-Datenbank wiederherstellen (Import) — der Rückweg, falls die neue Version Probleme macht.
• Wie oft werden meine Daten gesichert? — was unsere Server-Backups zusätzlich abdecken.
• MySQL-Fehler 1227 beim Import beheben — häufiger Stolperstein beim Einspielen von Dumps.

Du kommst nicht weiter?

Du bist unsicher, welche Version zu deiner Anwendung passt? Eröffne ein Ticket im Kundencenter — nenn deine Anwendung samt Version und dein Wunsch-Zeitfenster, den Rest klären wir gemeinsam.