MySQL 8.0 am Support-Ende: Shop-Datenbank migrieren

Mit MySQL 8.0.46 ist im April 2026 die letzte Version der 8.0-Serie erschienen. Oracle formuliert es in den offiziellen Release Notes unmissverständlich: Mit 8.0.46 erreicht MySQL 8.0 das End of Life, Anwender sollen auf MySQL 8.4 LTS oder eine aktuelle Innovation-Release wechseln (Oracle MySQL 8.0 Release Notes). Seit dem 21.04.2026 läuft die Version nur noch unter Oracle Sustaining Support (Oracle MySQL Product Support EOL Announcements) - für die frei verfügbare Community Edition bedeutet das schlicht: keine Security-Patches mehr. Für Shop-Betreiber ist das keine Sysadmin-Fußnote. Unter Shopware, WooCommerce oder jedem anderen Shopsystem liegt genau diese Datenbank - mit sämtlichen Bestellungen, Kundenkonten, Zahlungsreferenzen und Rechnungsdaten. Eine Datenbank ohne Sicherheitsupdates ist deshalb zuerst ein Compliance- und Auditproblem und erst danach ein technisches. Dieser Beitrag behandelt den Umstieg auf 8.4 LTS als Betriebsaufgabe mit Deadline: Breaking Changes, Kompatibilitätsprüfung, MariaDB als Alternativpfad und ein Migrationsablauf mit Dump-Restore-Test, Query-Regression und Rollback-Fenster. Hosting-Modelle klärt der Beitrag zum Managed Hosting für Online-Shops, Caching-Schichten das Redis-Caching für Shopware - hier geht es ausschließlich um die relationale Datenbank und ihren Lifecycle.

Was das Support-Ende von MySQL 8.0 konkret bedeutet

MySQL 8.0 war seit der Freigabe im April 2018 rund acht Jahre die Standard-Datenbank im PHP-Shop-Stack. Diese Ära endet mit 8.0.46 vom 21.04.2026 - laut Oracle die finale Version der Serie (Oracle MySQL 8.0 Release Notes). Danach greift Sustaining Support: Oracle-Kunden mit Supportvertrag behalten Zugriff auf bereits veröffentlichte Patches und Dokumentation, es entstehen aber keine neuen Sicherheitskorrekturen und keine Bugfixes mehr. Wer die Community Edition einsetzt - in der Shop-Praxis die deutliche Mehrheit - bekommt gar nichts mehr. Ein Extended Support, den man wie bei MySQL 5.7 noch hinzukaufen konnte, steht für die Community Edition nicht zur Verfügung. Der Stichtag ist damit hart, und er ist bereits vergangen.

Warum eine EOL-Datenbank ein Compliance- und Auditproblem ist

Der interessanteste Teil des Support-Endes ist nicht technisch, sondern regulatorisch. PCI DSS Anforderung 6.3.3 verlangt, dass kritische und hoch eingestufte Sicherheitspatches innerhalb eines Monats nach Veröffentlichung installiert werden, alle übrigen in einem selbst definierten, angemessenen Zeitraum (PCI Security Standards Council, PCI DSS v4.0). Bei einer EOL-Komponente ist diese Anforderung nicht etwa schwer zu erfüllen - sie ist strukturell unerfüllbar, weil der Patch schlicht nicht existiert. Ergänzend adressiert Anforderung 12.3.4 genau diesen Fall: Eingesetzte Technologien müssen mindestens jährlich darauf geprüft werden, ob sie noch vom Hersteller unterstützt werden; für auslaufende Komponenten ist ein dokumentierter Plan erforderlich (PCI Security Standards Council, PCI DSS v4.0). Wer Kartenzahlungen akzeptiert, beantwortet diese Fragen gegenüber Acquirer oder Zahlungsdienstleister - je nach Händlerstufe im Self-Assessment-Questionnaire oder im Rahmen eines Assessments.

Dazu kommt die datenschutzrechtliche Seite. Artikel 32 DSGVO verlangt technische und organisatorische Maßnahmen nach dem Stand der Technik - eine Datenbank, die vom Hersteller offiziell als End of Life geführt wird und für die keine Sicherheitsupdates mehr erscheinen, lässt sich im Schadensfall schwer als solche verteidigen. Für Hersteller digitaler Produkte kommt mittelfristig der Cyber Resilience Act mit seinen Pflichten hinzu, der Schwachstellenbehandlung über den Supportzeitraum verbindlich regelt. Wie real der Patch-Strom ist, den eine 8.0-Installation ab sofort verpasst, zeigen die Zahlen: Allein das Critical Patch Update vom April 2026 enthielt 34 neue Sicherheitspatches für Oracle MySQL, von denen 3 aus der Ferne ohne Authentifizierung ausnutzbar waren; die schwerwiegendste Lücke, CVE-2025-15467 mit einem CVSS-Score von 9,8, betraf die Komponente MySQL Enterprise Backup und konnte zu Remote Code Execution führen (Oracle Critical Patch Update April 2026 / Qualys).

Die folgenden Fragen tauchen erfahrungsgemäß in Assessments, Lieferantenprüfungen und Cyber-Versicherungs-Fragebögen auf - und sie lassen sich mit einer EOL-Datenbank nicht sauber beantworten:

• Welche Datenbankversion läuft in Produktion, und wird sie vom Hersteller noch unterstützt? Die Antwort steht in einer Zeile - und entscheidet über den Rest des Gesprächs.
• Wie stellen Sie sicher, dass kritische Patches innerhalb von 30 Tagen eingespielt werden? Ohne verfügbare Patches gibt es keinen Prozess, der das leisten könnte.
• Wann haben Sie zuletzt geprüft, ob eingesetzte Komponenten das End of Life erreichen? PCI DSS 12.3.4 erwartet diese Prüfung mindestens jährlich (PCI Security Standards Council).
• Existiert ein dokumentierter Migrationsplan mit Zieldatum, und welche kompensierenden Maßnahmen laufen bis dahin? Netzsegmentierung und restriktive Grants mindern das Risiko - den Befund beseitigen sie nicht.

Eine End-of-Life-Datenbank ist selten die Ursache eines Vorfalls - aber regelmäßig der Punkt, an dem im Nachgang die Frage nach der Sorgfalt gestellt wird.

XICTRON Entwicklungsteam

Breaking Changes beim Sprung von 8.0 auf 8.4

Die gute Nachricht zuerst: Der Upgrade-Pfad ist direkt. Oracle führt den Schritt von einer LTS- oder Bugfix-Serie zur nächsten LTS-Serie ausdrücklich als unterstützt auf und nennt als Beispiel 8.0.37 auf 8.4.x LTS - per In-place-Upgrade, logischem Dump-and-Load oder Replikation (Oracle MySQL 8.4 Reference Manual, Upgrade Paths). Ein Zwischenschritt ist nicht erforderlich; die Regel, dass keine Serie übersprungen werden darf, greift erst beim Weg von 5.7 aufwärts. Die schlechte Nachricht: 8.4 ist kein reines Wartungs-Update. Zwischen 8.0 und 8.4 liegen mehrere Innovation-Releases, deren Aufräumarbeiten sich hier gebündelt entladen. Der häufigste Stolperstein ist dabei nicht der Anwendungscode, sondern die Konfigurationsdatei: Entfernte Server-Variablen führen beim Start zu einem Fehler - der Server startet schlicht nicht mehr (Oracle MySQL 8.4 Reference Manual).

• Entfernte Authentifizierungs-Plugins: authentication_fido und authentication_fido_client sind in 8.4.0 entfernt, Ersatz ist authentication_webauthn (Oracle MySQL 8.4 Reference Manual).
• mysql_native_password ist nicht mehr Standard: Das Plugin ist ab 8.4.0 nicht mehr per Default aktiviert und muss bei Bedarf mit mysql_native_password=ON eingeschaltet werden. In MySQL 9.0 ist es vollständig entfernt (Oracle MySQL 8.4 Reference Manual).
• default_authentication_plugin entfernt: Ersetzt durch authentication_policy - eine Zeile, die in vielen älteren Shop-Konfigurationen steht (Oracle MySQL 8.4 Reference Manual).
• expire_logs_days entfernt: Nur noch binlog_expire_logs_seconds ist gültig - betrifft praktisch jede Konfiguration mit aktivem Binärlog (Oracle MySQL 8.4 Reference Manual).
• Replikations-Statements entfernt, nicht deprecated: CHANGE MASTER TO, START SLAVE, STOP SLAVE, SHOW SLAVE STATUS, RESET SLAVE, RESET MASTER und SHOW MASTER STATUS existieren nicht mehr - sie erzeugen Syntaxfehler. Ersatz sind CHANGE REPLICATION SOURCE TO, START REPLICA, STOP REPLICA, SHOW REPLICA STATUS, RESET REPLICA, RESET BINARY LOGS AND GTIDS und SHOW BINARY LOG STATUS. Auch die MASTER_-Optionen weichen den SOURCE_-Entsprechungen (Oracle MySQL 8.4 Reference Manual).
• Weitere entfernte Replikations-Variablen: relay_log_info_repository, master_info_repository, log_bin_use_v1_events, transaction_write_set_extraction und slave_rows_search_algorithms - Letzteres ist jetzt fest HASH_SCAN,INDEX_SCAN (Oracle MySQL 8.4 Reference Manual).
• Entfernte Keyring-Plugins: keyring_file und keyring_encrypted_file weichen den Komponenten component_keyring_file und component_keyring_encrypted_file - relevant bei verschlüsselten Tablespaces (Oracle MySQL 8.4 Reference Manual).
• Entfernte Server-Optionen: --ssl (jetzt --tls-version), --skip-host-cache (jetzt --host-cache-size=0) sowie --innodb und --skip-innodb, da InnoDB dauerhaft aktiv ist (Oracle MySQL 8.4 Reference Manual).
• Nicht-standardkonforme Fremdschlüssel und Grant-Wildcards: Fremdschlüssel auf nicht-eindeutige oder partielle Schlüssel sind deprecated und verlangen restrict_fk_on_non_standard_key=OFF; % und _ in Datenbank-Grants sollen künftig als Literale gelten. Beides betrifft gewachsene Schemata (Oracle MySQL 8.4 Reference Manual).

Für die Praxis lässt sich die Liste auf zwei Arbeitspakete verdichten. Erstens die Konfiguration: my.cnf, Docker-Compose-Kommandozeilen, Ansible-Rollen und Provisionierungs-Skripte auf entfernte Variablen absuchen. Zweitens die Skripte rund um die Datenbank: Backup-Jobs, Monitoring-Checks, Replikations-Setups und Deployment-Automatisierung enthalten erfahrungsgemäß genau die Statements, die jetzt Syntaxfehler erzeugen. Der Anwendungscode von Shopware und WooCommerce selbst ist dabei selten das Problem - die Systeme sprechen normales SQL und werden von ihren Herstellern gegen aktuelle MySQL-Versionen getestet. Kritisch sind eigene Auswertungen, gewachsene Reporting-Queries und Individual-Erweiterungen, die wir typischerweise im Rahmen der Programmierung mit prüfen.

# ---------- MySQL 8.0: haeufig gewachsener Bestand ----------
[mysqld]
# expire_logs_days = 7 # in 8.4 ENTFERNT -> Server startet nicht
# default_authentication_plugin = mysql_native_password # in 8.4 ENTFERNT
# master_info_repository = TABLE # in 8.4 ENTFERNT
# relay_log_info_repository = TABLE # in 8.4 ENTFERNT
# transaction_write_set_extraction = XXHASH64 # in 8.4 ENTFERNT
# log_bin_use_v1_events = OFF # in 8.4 ENTFERNT
# skip-host-cache # in 8.4 ENTFERNT

# ---------- MySQL 8.4: gueltige Entsprechungen ----------
[mysqld]
binlog_expire_logs_seconds = 604800 # statt expire_logs_days = 7
authentication_policy = caching_sha2_password # statt default_authentication_plugin
host_cache_size = 0 # statt skip-host-cache

# Nur setzen, wenn Altclients es zwingend brauchen (in 9.0 entfaellt es ganz):
# mysql_native_password = ON

# Shopware-Anforderung: max_allowed_packet >= 32M (Shopware Hosting-Guide)
max_allowed_packet = 64M

# Defaults, die 8.4 aendert - hier bewusst am 8.0-Verhalten festhalten,
# bis auf der eigenen Hardware gemessen wurde:
innodb_io_capacity = 200 # 8.4-Default waere 10000
innodb_adaptive_hash_index = ON # 8.4-Default waere OFF

Geänderte Defaults: was sich im Betrieb messbar ändert

Neben den entfernten Variablen verschiebt 8.4 eine ganze Reihe von InnoDB-Standardwerten (Oracle MySQL 8.4 Reference Manual). Das ist der unterschätzte Teil der Migration: Der Server startet, die Anwendung funktioniert, das Lastverhalten ist trotzdem ein anderes. Oracle hat die neuen Defaults an moderner Hardware ausgerichtet - viele Kerne, NVMe-Speicher, großzügig bemessener RAM. Genau diese Annahme trifft auf typische Shop-Hostings nicht in jedem Fall zu, insbesondere bei virtualisierten Umgebungen mit Netzwerk-Storage oder geteilten IOPS-Kontingenten.

Der auffälligste Wert ist innodb_io_capacity, der von 200 auf 10000 springt (Oracle MySQL 8.4 Reference Manual) - ein Faktor 50. Auf lokalem NVMe-Speicher ist das sinnvoll. Auf einem virtualisierten Server mit Netzwerk-Storage oder gedeckelten IOPS kann dasselbe Setting dazu führen, dass das Hintergrund-Flushing genau die IO-Kapazität belegt, die der Shop im Verkauf braucht. Ähnlich differenziert ist innodb_adaptive_hash_index beim Wechsel von ON auf OFF: Oracle hat den Default geändert, weil der Index unter hoher Parallelität selbst zum Engpass werden kann - bei sehr vielen wiederholten Punkt-Lookups kann das Abschalten die Latenz aber auch erhöhen. Beide Werte gehören deshalb nicht blind übernommen, sondern gemessen. Wie sich Lastspitzen sauber abbilden lassen, behandelt der Beitrag zum Auto-Scaling bei Traffic-Spitzen.

Kompatibilität prüfen: Shopware- und WooCommerce-Anforderungen

Bevor eine Zielversion feststeht, muss der Abgleich mit den Systemanforderungen des Shopsystems erfolgen. Shopware 6 nennt im Hosting-Guide MySQL ab 8.0.22 als Minimum und MySQL 8.4 als Empfehlung, alternativ MariaDB ab 10.11.6 als Minimum bei MariaDB 11.4 als Empfehlung (Shopware Developer Documentation, Hosting). Die Empfehlung deckt sich damit exakt mit dem naheliegenden Migrationsziel. Ebenfalls dokumentiert: max_allowed_packet von mindestens 32M sowie PHP ab 8.2 bei einer Empfehlung von PHP 8.4. Besonders wichtig für die Versionsplanung ist ein Satz aus derselben Quelle: Innovation-Releases werden nicht unterstützt (Shopware Developer Documentation, Hosting). Der Sprung auf die neueste verfügbare MySQL-Generation ist damit ausdrücklich kein Ziel.

WooCommerce formuliert die Anforderungen breiter: Empfohlen werden MySQL 8.0 oder höher beziehungsweise MariaDB 10.6 oder höher, dazu PHP 8.3 oder höher und WordPress 6.9 oder höher (WooCommerce Server Requirements). Formal lauffähig ist WooCommerce noch mit MySQL ab 5.6 oder MariaDB ab 10.4 - die Dokumentation weist allerdings selbst darauf hin, dass diese Versionen ihr offizielles End of Life erreicht haben und die Website Sicherheitsrisiken aussetzen können (WooCommerce Server Requirements). Für WooCommerce-Projekte heißt das: Die Anforderungen sind nachsichtiger, das Sicherheitsargument bleibt identisch. Wer die WooCommerce-Umgebung sauber führen will, orientiert sich an der Empfehlung, nicht am Minimum.

Ein Punkt, der in der Planung oft untergeht: Datenbank- und PHP-Migration sind zwei getrennte Vorhaben, die gern zusammengelegt werden - und dann gemeinsam schiefgehen. Wenn nach dem Wartungsfenster die Antwortzeiten steigen, ist bei einer Doppelmigration nicht mehr zuordenbar, ob die Datenbank-Defaults oder die neue PHP-Version die Ursache sind. Wir trennen die beiden Schritte deshalb in der Regel; wie die PHP-Seite abläuft, beschreibt der Beitrag zur PHP-8.5-Migration aus Agentursicht. Wer ohnehin vor einem größeren Technologiewechsel steht, findet im Beitrag zur CMS-Migration von Legacy auf ein modernes System den übergeordneten Rahmen.

MariaDB als Alternativpfad

Da Shopware und WooCommerce beide Datenbanken unterstützen, ist MariaDB ein legitimer Zielpfad - allerdings aus anderen Gründen, als oft angenommen wird. Der Lifecycle sieht so aus: MariaDB 11.4 LTS wird bis Mai 2029 gepflegt, MariaDB 11.8 LTS bis Juni 2028 (MariaDB Foundation). Der auf den ersten Blick paradoxe Befund - die ältere LTS läuft länger als die neuere - erklärt sich durch eine Änderung der Maintenance-Policy: LTS-Versionen erscheinen jährlich und werden nur noch drei statt fünf Jahre mit Bug- und Sicherheitskorrekturen versorgt; die Fünf-Jahres-Regel galt letztmalig bis 11.4 (MariaDB Foundation). Für die Versionswahl heißt das: Nicht automatisch die höchste Nummer nehmen, sondern das Enddatum vergleichen. Genau deshalb empfiehlt Shopware aktuell 11.4 und nicht 11.8 (Shopware Developer Documentation, Hosting).

Entscheidend ist die zweite Hälfte der Wahrheit: MariaDB ist längst kein Drop-in-Replacement für MySQL 8.0 mehr. Ein In-place-Wechsel scheidet aus, der Weg führt zwingend über Dump und Restore. Die Unterschiede betreffen dabei Speicherformate, nicht nur Syntax. JSON ist in MariaDB ein Alias für LONGTEXT mit CHECK-Constraint, während MySQL 8.0 und 8.4 ein natives Binärformat nutzen - bei einer Replikation von MySQL nach MariaDB müssen JSON-Spalten deshalb vorher auf TEXT umgestellt oder statementbasierte Replikation verwendet werden (MariaDB Documentation, Incompatibilities and Feature Differences). Auch die GTIDs sind untereinander nicht kompatibel, sodass hybride Setups während einer Migration positionsbasierte Replikation erfordern; ergänzend dokumentiert MariaDB Vorgaben wie binlog-row-value-options auf einem leeren Wert und binlog_transaction_compression auf 0 (MariaDB Documentation, Replication Compatibility Between MariaDB and MySQL).

Migrationsablauf: Dump-Restore-Test, Query-Regression und Rollback-Fenster

Der Ablauf, der sich für Shop-Datenbanken bewährt hat, trennt konsequent zwischen Erkenntnis am Klon und Ausführung in Produktion. Alles, was auf einem Klon herausgefunden werden kann, wird dort herausgefunden - das Wartungsfenster ist zum Ausführen da, nicht zum Lernen. Die folgenden acht Schritte beschreiben das Vorgehen, das wir typischerweise im Hosting und der Wartung fahren:

1. Bestand aufnehmen: Exakte Version (SELECT VERSION()), Größe pro Tabelle, Storage-Engines und Kollationen dokumentieren. Dazu die effektive Konfiguration über SHOW GLOBAL VARIABLES sichern - nicht nur die my.cnf, sonst gehen zur Laufzeit gesetzte Werte verloren.
2. Upgrade-Checker am Klon: util.checkForServerUpgrade() der MySQL Shell gegen eine Kopie laufen lassen. Der Report listet entfernte Variablen, veraltete Datentypen und problematische Objekte - das ist die Arbeitsliste für alles Weitere.
3. Konfiguration bereinigen: Entfernte Variablen ersetzen, expire_logs_days auf binlog_expire_logs_seconds überführen, default_authentication_plugin auf authentication_policy umstellen. Abweichende 8.4-Defaults zunächst bewusst auf den 8.0-Werten festschreiben.
4. Umgebende Skripte anpassen: Ein grep nach SHOW SLAVE STATUS, CHANGE MASTER TO und RESET MASTER über alle Repositories und Cron-Verzeichnisse findet erfahrungsgemäß mehr, als die Beteiligten erwarten.
5. Dump-Restore-Test auf dem Klon: Vollständigen Dump ziehen, auf einer frischen 8.4-Instanz einspielen, mysqlcheck --check-upgrade laufen lassen - und dabei die Dauer messen. Diese Zahl ist die Grundlage für die Länge des Wartungsfensters.
6. Query-Regression fahren: Top-Queries aus Slow-Query-Log und Performance Schema gegen 8.0 und 8.4 vergleichen - EXPLAIN-Pläne, Laufzeiten, gelesene Zeilen. Im Fokus: Kategorielisting, Filter, Warenkorb, Checkout. Wie Suchlast ausgelagert wird, behandelt der Beitrag zur Suchrelevanz mit OpenSearch-Tuning.
7. Funktionale Abnahme: Bestellstrecke, Zahlungsarten, Rechnungserzeugung und Retouren auf dem Klon durchspielen. Auch Preisdarstellung und Rabattlogik - rechtliche Anforderungen an Streichpreise und Rabattwerbung nach PAngV hängen an denselben Datensätzen.
8. Wartungsfenster ausführen: Shop in den Wartungsmodus, finaler Dump als Rollback-Anker, Binlog-Position notieren, Upgrade, Smoke-Tests, Freigabe. Danach 48 bis 72 Stunden erhöhte Aufmerksamkeit auf Slow-Query-Log und Antwortzeiten.

Rollback-Fenster und Wartungsfenster realistisch planen

Der Punkt, an dem Datenbank-Migrationen sich von PHP-Migrationen grundlegend unterscheiden: Der Rückweg ist nicht symmetrisch. Eine PHP-Version lässt sich über einen Image-Tag oder einen zweiten FPM-Pool binnen Sekunden zurückdrehen, weil PHP zustandslos ist. Eine Datenbank ist es nicht. Ein In-place-Downgrade von 8.4 zurück auf 8.0 ist kein vorgesehener Weg - sobald die Datenverzeichnisse aktualisiert sind, führt der Rückweg über den Dump von vorher. Und dieser Dump ist ab dem Moment der Freigabe veraltet: Jede Bestellung, jede Registrierung, jede Zahlungsrückmeldung, die nach dem Dump eingeht, existiert dort nicht.

Daraus folgen zwei Konsequenzen. Erstens: Das Wartungsfenster braucht einen echten Schreib-Stopp - der Shop gehört für die Dauer von Dump und Upgrade in den Wartungsmodus, sonst ist der Rollback-Anker unvollständig. Zweitens: Wer das Fenster kurz halten muss, notiert die Binlog-Position des Dumps - --source-data=2 schreibt sie als Kommentar hinein - und kann später aufgelaufene Transaktionen im Rollback-Fall per mysqlbinlog nachspielen. Ohne diesen Schritt bedeutet ein Rollback den Verlust aller Bestellungen seit dem Dump - ein Schaden, der den ursprünglichen Anlass der Migration regelmäßig übersteigt.

Die Datenbankversion als Betriebsaufgabe mit Datum führen

Das Support-Ende von MySQL 8.0 ist kein Sonderfall, sondern der Normalzustand jeder Softwarekomponente - nur eben mit einem Datum, das diesmal überschritten ist. Wer jetzt auf 8.4 LTS geht, hat bis April 2029 Premier-Support und bis April 2032 Extended Support (Oracle Lifetime Support Policy for Technology Products), also einen Planungshorizont von mehreren Jahren. Die nächste LTS-Generation steht mit MySQL 9.7 bereits bereit, veröffentlicht am 21.04.2026 mit Premier-Support bis April 2034 - trotzdem ist sie für Shop-Betreiber heute kein Ziel, solange das eingesetzte Shopsystem sie nicht ausdrücklich freigibt. Shopware etwa schließt Innovation-Releases explizit aus und empfiehlt 8.4 (Shopware Developer Documentation, Hosting). Die Regel lautet deshalb nicht so neu wie möglich, sondern so aktuell wie vom Hersteller freigegeben.

Damit derselbe Fall in drei Jahren nicht erneut überrascht, gehört der Lifecycle in den Wartungsvertrag statt in den Kopf einzelner Beteiligter. Konkret: Version und EOL-Datum jeder Kernkomponente - Datenbank, PHP, Suchdienst, Cache, Betriebssystem - stehen im Asset-Inventar, und einmal jährlich prüft jemand die Liste gegen die Herstellerankündigungen. Dieser Review ist ohnehin fällig, denn PCI DSS 12.3.4 verlangt ihn mindestens jährlich (PCI Security Standards Council) - und er kostet Stunden, während eine Migration unter Zeitdruck Wochen kostet.

XICTRON prüft die Datenbankversion im Bestandsshop, testet die Migration auf einem Klon der Produktionsdaten und führt sie im abgestimmten Wartungsfenster durch - inklusive Konfigurations-Bereinigung, Query-Regression und definiertem Rollback-Pfad. Ob 8.4 LTS oder MariaDB der passende Zielpfad ist, klären wir vorab anhand Ihres Shopsystems und Ihrer Hosting-Umgebung, statt eine Standardantwort zu geben. Sprechen Sie uns über die Kontaktseite an oder lassen Sie den Bestand im Rahmen einer Beratung aufnehmen - der erste Schritt bleibt dieselbe Zeile: welche Version läuft eigentlich in Produktion?

Häufige Fragen zum MySQL-8.0-Support-Ende