MySQL EOL: Was das Ende des Lebenszyklus für Ihre Datenbankinfrastruktur bedeutet

Das EOL von MySQL ist eines der folgenreichsten und am häufigsten aufgeschobenen Ereignisse im Lebenszyklus der Unternehmensdatenbankverwaltung. MySQL bildet die Grundlage für E-Commerce-Plattformen, SaaS-Anwendungen, Content-Management-Systeme, interne Tools und Datenpipelines in praktisch jeder Branche. Genau diese Allgegenwärtigkeit macht das Lebenszyklusmanagement so folgenreich – und so leicht aufzuschieben, bis es dringlich wird.

MySQL-Versionen altern jedoch nicht einfach so mit der Zeit. Jede Version hat einen festgelegten Supportzeitraum, und sobald dieser abgelaufen ist, stellt Oracle die Veröffentlichung von Sicherheitspatches für diese Version ein. Jede nach diesem Zeitpunkt bekannt gegebene CVE betrifft Ihre Version, aber keine der Korrekturen mehr. Wenn Sie MySQL 5.7 einsetzen, endete der Support für MySQL im Oktober 2023. Wenn Sie MySQL 8.0 einsetzen, endet er im April 2026, und dieses Datum rückt schneller näher, als den meisten Teams bewusst ist.

In diesem Beitrag wird erläutert, wie der Release-Zyklus von MySQL tatsächlich funktioniert, was das EOL von MySQL in Bezug auf Sicherheit und Compliance konkret bedeutet und welche Möglichkeiten Sie haben, wenn ein Upgrade nicht einfach für den nächsten Sprint eingeplant werden kann.

Wichtigste Erkenntnisse

• Abhängigkeiten vergrößern die Angriffsfläche von MySQL im Zusammenhang mit dem EOL: MySQL bündelt C-Bibliotheken von Drittanbietern wie OpenSSL, curl, LZ4, zlib und andere, von denen jede ihre eigenen CVE-Sicherheitslücken mit sich bringt, für die keine Patches mehr bereitgestellt werden, sobald die MySQL-Version das Ende ihrer Lebensdauer erreicht hat.
• Überstürzte Upgrades sind kostspielig: Umfassende Versions-Upgrades von MySQL erfordern die Überprüfung der Schemakompatibilität, das Testen von Anwendungsabfragen, die Neukonfiguration der Replikation sowie koordinierte Rollouts über die gesamte Infrastruktur hinweg. Die technischen Kosten einer ungeplanten Migration sind selten gering.
• Das Ende des Supports für MySQL bedeutet nicht das Ende der Sicherheit. Der Endless Lifecycle Support (ELS) von TuxCare liefert fortlaufend Patches für MySQL-Versionen, deren Support ausgelaufen ist, und deckt dabei die gesamte Abhängigkeitsfläche ab, sodass Ihre Datenbankinfrastruktur geschützt bleibt, während Sie das Upgrade nach Ihrem eigenen Zeitplan durchführen.

Wie sieht der Produktlebenszyklus von MySQL aus?

Der Lebenszyklus von MySQL folgt der „Lifetime Support Policy“ von Oracle, die für jede Hauptversion drei verschiedene Phasen definiert:

• Premier-Support  5 Jahre ab dem Datum der allgemeinen Verfügbarkeit. Während dieser Phase stellt Oracle im Rahmen des Oracle Critical Patch Update (CPU)-Programms regelmäßig vierteljährlich neue Funktionen, Fehlerbehebungen, Sicherheitswarnungen und kritische Patch-Updates bereit.
• Erweiterter Support  3 Jahre nach Ablauf des Premier-Supports gegen eine zusätzliche Gebühr. Sicherheitswarnungen und kritische Patch-Updates werden weiterhin bereitgestellt, jedoch keine neuen Funktionen oder allgemeine Fehlerbehebungen.
• Weiterführender Support  Verfügbar nach Ablauf des erweiterten Supports, für einen beliebigen Zeitraum. Entscheidend ist, dass diese Phase keine neuen Releases, keine neuen Fehlerbehebungen und keine neuen Sicherheitspatches. Es bleiben nur bereits vorhandene Korrekturen verfügbar.

Wenn in der Datenbank-Community davon die Rede ist, dass eine MySQL-Version das Ende ihrer Lebensdauer erreicht hat, bedeutet dies, dass die Version entweder vollständig aus dem erweiterten Support (Extended Support) genommen wurde oder – wie im Fall von MySQL 5.7 – von Oracle in den Sustaining Support überführt wurde, was in der Praxis bedeutet, dass ab diesem Zeitpunkt keine neuen Sicherheitspatches mehr bereitgestellt werden.

MySQL führte 2023 ein zweigleisiges Release-Modell ein, um Unternehmen künftig eine bessere Vorhersehbarkeit des Lebenszyklus zu ermöglichen:

• Long-Term Support (LTS)-Versionen sind auf Produktionsstabilität ausgelegt. Jede LTS-Version erhält 5 Jahre Premier Support sowie 3 Jahre Extended Support. MySQL 8.4 ist die aktuelle LTS-Version.
• Innovations-Releases Vierteljährliche Releases mit den neuesten Funktionen. Jedes Innovation-Release wird nur bis zur Veröffentlichung des nächsten Releases unterstützt, wodurch sie für Produktionsumgebungen ungeeignet sind, die vorhersehbare Patch-Fenster benötigen.

Das Fazit in der Praxis: Wenn Ihre Infrastruktur mit MySQL 5.7 läuft, arbeiten Sie seit Oktober 2023 ohne Sicherheitspatches vom Hersteller. Wenn sie mit MySQL 8.0 läuft, tickt die Uhr bereits auf das EOL-Datum von MySQL im April 2026 zu.

Was bedeutet das Ende der Lebensdauer von MySQL?

Keine Sicherheitspatches mehr

Sobald eine MySQL-Version in den Sustaining Support übergeht, stellt Oracle die Entwicklung von Sicherheitspatches für diese Version ein. Das bedeutet, dass für jede ab diesem Zeitpunkt bekannt gewordene Sicherheitslücke in den Kernkomponenten von MySQL, im Abfrageoptimierer, im Replikationssystem und in den mitgelieferten Bibliotheken ein Patch für die unterstützten Versionen bereitgestellt wird, für Ihre Version jedoch nicht.

Dies ist die zentrale Sicherheitsrealität beim großflächigen Einsatz von Software, für die kein Support mehr angeboten wird: Die Sicherheitsforscher-Community und Oracles eigenes Sicherheitsteam entdecken und veröffentlichen kontinuierlich neue Sicherheitslücken. Der vierteljährliche „Critical Patch Update“-Zyklus, über den früher Korrekturen für Ihre Version bereitgestellt wurden, gilt für diese Version einfach nicht mehr. Ihr Sicherheitsrisiko steigt mit jedem CPU-Zyklus, der verstreicht, ohne dass Ihre Version davon erfasst wird.

Sicherheits- und Compliance-Risiken nach dem Ende des Supports für MySQL

Auch in Bezug auf die Compliance ist die Lage eindeutig. PCI DSS (Anforderung 6.3.3) schreibt vor, dass kritische und schwerwiegende Sicherheitslücken mit einem CVSS-Wert von 7,0 oder höher innerhalb eines Monats nach Veröffentlichung des Patches für betroffene Systeme behoben werden müssen. HIPAA, FedRAMP und SOC 2 enthalten vergleichbare Anforderungen für die von ihnen geregelten Umgebungen. Der Betrieb einer nicht mehr unterstützten MySQL-Version in einer regulierten Umgebung bedeutet, dass Sie eine Datenbank betreiben, die Sie nicht innerhalb der von diesen Rahmenwerken geforderten Fristen patchen können, was eine Compliance-Lücke schafft, die durch kompensierende Kontrollen nur teilweise geschlossen werden kann.

Da MySQL als Datenspeicher für Anwendungs-Workloads dient, die Kundendaten, Finanztransaktionen, Anmeldedaten und geschäftskritische Daten enthalten, ist es ein bevorzugtes Ziel für jeden Angreifer, der eine nicht gepatchte Installation auf einer Version entdeckt, für die kein Support mehr angeboten wird.

Die CVE-Historie von MySQL

Die CVE-Auflistung von MySQL veranschaulicht, wie Sicherheitslücken nach dem Ende des Supportzeitraums in der Praxis aussehen.

CVE-2023-21980 CVSS 7.1 Hoch. Diese Sicherheitslücke betraf die Client-Programmkomponente von MySQL Server in den Versionen 5.7.41 und früher sowie 8.0.32 und früher. Ein Angreifer mit geringen Berechtigungen und Netzwerkzugang konnte diese Schwachstelle ausnutzen, um die vollständige Kontrolle über den MySQL Server zu erlangen und gleichzeitig die Vertraulichkeit, Integrität und Verfügbarkeit zu gefährden. Oracle veröffentlichte im Rahmen des Critical Patch Updates vom April 2023 Patches für unterstützte Versionen. Für jede Bereitstellung, auf der MySQL 5.7 nach dem EOL-Datum im Oktober 2023 lief, gab es von Oracle künftig keinen Behebungsweg mehr; der Fix existierte zwar, aber nur für unterstützte Versionen. Dies ist das charakteristische Muster der EOL-Sicherheitslücke bei MySQL: Patches werden für unterstützte Versionen veröffentlicht, während sich bei EOL-Bereitstellungen ungelöste CVEs ansammeln, für die kein Upstream-Fix verfügbar ist.

Was dieses Muster besonders bedeutsam macht, ist das Ausmaß. In den vierteljährlichen CPU-Zyklen von Oracle werden regelmäßig zweistellige Zahlen von MySQL-Sicherheitslücken in verschiedenen Komponenten behoben, darunter InnoDB, der Optimierer, die Replikation, DDL, Client-Programme und vieles mehr. Jeder CPU-Zyklus, der nach dem EOL von MySQL verstreicht, bedeutet eine Reihe von Korrekturen, die Ihre Installation nie erhält. Das kumulative Risiko wächst mit jedem Quartal.

Das Problem der Abhängigkeitsfläche

MySQL ist keine eigenständige Binärdatei, sondern ein kompilierter Server, der eine umfangreiche Sammlung von C-Bibliotheken von Drittanbietern bündelt, von denen jede ihre eigenen Sicherheitslücken mit sich bringt. Bei der Auslieferung von MySQL werden unter anderem Bibliotheken wie OpenSSL für die TLS-Verschlüsselung, curl für HTTP-Operationen, LZ4 für die Komprimierung, zlib für die allgemeine Datenkomprimierung und libevent für die Verarbeitung von Netzwerkereignissen eingebunden oder mitgeliefert.

Jede dieser gebündelten Bibliotheken verfügt über eine eigene CVE-Historie und einen eigenen, unabhängigen Release-Rhythmus. Das vierteljährliche Critical Patch Update von Oracle behebt Sicherheitslücken in diesen gebündelten Komponenten, aktualisiert die in MySQL enthaltene OpenSSL-Version, wenn eine kritische TLS-Sicherheitslücke bekannt wird, oder patcht das gebündelte curl, wenn ein Fehler bei der Netzwerkverarbeitung entdeckt wird.

Nach dem EOL von MySQL werden auch keine dieser gebündelten Bibliotheksaktualisierungen mehr auf Ihre Version übertragen. Eine kritische OpenSSL-Sicherheitslücke, ein Speicherfehler in curl und ein Pufferüberlauf in LZ4 – all diese Probleme werden in den unterstützten MySQL-Versionen behoben, in Ihrer Version jedoch nicht. Die Angriffsfläche beschränkt sich nicht nur auf den eigenen Abfrageverarbeitungscode von MySQL, sondern erstreckt sich auf jede Bibliothek, die in MySQL integriert ist.

Dies zeigte sich während der Support-Laufzeit von MySQL 5.7: In den Patch-Hinweisen von Tenable für MySQL 5.7-Versionen wurden durchweg CVEs in mitgelieferten Komponenten wie curl (CVE-2021-22901, ein „Use-after-free“, der potenziellen RCE ermöglicht), LZ4 (CVE-2019-17543, ein Heap-Überlauf) und OpenSSL (CVE-2021-3711, ein Pufferüberlauf, der zu einer Serverübernahme führen könnte) als Schwachstellen auf, die durch MySQL-Patch-Releases behoben wurden, was genau zeigt, wie tief die Sicherheitsrisiken der gebündelten Bibliotheken in der Angriffsfläche von MySQL verankert sind. Sobald das EOL von MySQL erreicht ist, werden alle diese Behebungsmöglichkeiten geschlossen.

Möglichkeiten, nach dem EOL von MySQL die Sicherheit und Compliance zu gewährleisten

Auf eine unterstützte MySQL-Version aktualisieren

Die Migration auf MySQL 8.4 LTS ist der empfohlene langfristige Weg für alle Unternehmen, die noch MySQL 5.7 einsetzen oder sich auf das Ende des Lebenszyklus von MySQL 8.0 im April 2026 vorbereiten. MySQL 8.4 LTS ist die aktuelle, für den produktiven Einsatz geeignete und langfristig unterstützte Version von Oracle, für die bis etwa 2029 Premier Support angeboten wird.

Die Komplexität dieser Migration hängt stark von Ihrer Umgebung ab. Eine Flotte von MySQL-Servern lässt sich nicht so einfach aktualisieren wie eine einzelne Entwicklungsinstanz – sie erfordert koordinierte Rollouts mit Änderungskontrolle, schrittweise Bereitstellungen über Anwendungsteams hinweg, die Überprüfung der Schemakompatibilität mit ORM-Schichten und Anwendungsabfragen, die Neukonfiguration von Replikationstopologien sowie Tests in Staging-Umgebungen, die die Produktion widerspiegeln. Für Unternehmen, die MySQL 5.7 einsetzen und direkt auf 8.4 aktualisieren, umfasst die Lücke zwei Hauptversionen, was zusätzliche Kompatibilitätsaspekte zur Überprüfung mit sich bringt.

Auf eine alternative Datenbank umstellen

Manche Unternehmen nutzen das Ende des Supports für MySQL als Anlass, um Alternativen wie PostgreSQL, MariaDB oder verwaltete Cloud-Datenbankdienste zu prüfen, die die Verwaltung des Versionslebenszyklus übernehmen. Für bestimmte Umgebungen sind dies durchaus sinnvolle langfristige Lösungen, doch handelt es sich dabei um mehrmonatige Entwicklungsprojekte und nicht um Maßnahmen, die als Reaktion auf eine Patch-Frist ergriffen werden.

Für die meisten Unternehmen, deren Software bald das Ende ihrer Lebensdauer erreicht, ist eine Plattformmigration keine praktikable Lösung für die unmittelbaren Sicherheits- und Compliance-Lücken.

In unserem ausführlichen Leitfaden können Sie außerdem erfahren, was das Ende des Supportzyklus (EOL) von MariaDB 10.6 für Teams bedeutet, die diesen Weg in Betracht ziehen.

Der empfohlene Weg: TuxCare – Lebenslanger Support für MySQL

Der „Endless Lifecycle Support“ (ELS) von TuxCare für MySQL löst das Problem der Sicherheit und Compliance nach dem Ende des Supports (EOL) für MySQL direkt, ohne dass eine sofortige Migration auf eine neue Hauptversion erforderlich ist. TuxCare stellt fortlaufend Sicherheitspatches für nicht mehr unterstützte MySQL-Versionen bereit, die sowohl die eigenen Komponenten von MySQL als auch die darin enthaltenen Abhängigkeiten von Bibliotheken von Drittanbietern abdecken – und das ohne zusätzliche Kosten. So kann Ihre Datenbankflotte ein solides Sicherheitsniveau aufrechterhalten, während Sie das von Ihnen gewünschte Upgrade planen.

Die Vorgehensweise ist praxisorientiert: TuxCare überwacht das NVD, die Sicherheitshinweise von Oracle sowie die Sicherheits-Feeds der Upstream-Bibliotheken auf Schwachstellen, die MySQL und die darin enthaltenen Komponenten betreffen. Anschließend werden Korrekturen für EOL-Versionen zurückportiert und im Rahmen von SLA-gestützten Prozessen bereitgestellt. Ihre MySQL-Version läuft weiter. Ihre Compliance-Situation bleibt gewahrt. Und der Zeitplan für Ihr Upgrade richtet sich nach Ihren Vorgaben.

Die Risiken einer überstürzten MySQL-Aktualisierung

Wenn die EOL-Termine für MySQL näher rücken, ist der Druck, sofort zu reagieren, groß, doch die Kosten einer falschen Reaktion sind höher, als die meisten Teams erwarten.

Was ein MySQL-Upgrade eigentlich beinhaltet

Ein Upgrade auf eine neue Hauptversion von MySQL, insbesondere von 5.7 auf 8.4 in einer gesamten Produktionsumgebung, ist kein schrittweiser Neustart. Es erfordert eine Codeanpassung für alle Anwendungsabfragen, gespeicherten Prozeduren oder ORM-generierten SQL-Anweisungen, die auf Syntax oder Verhalten beruhen, das sich zwischen den Versionen geändert hat. Dazu gehört Kompatibilitätsprüfung für jede Datenbank-Client-Bibliothek, jeden Connector und jede ORM-Version, die Ihr Anwendungsstack verwendet, da die Versionsunterstützungsmatrizen für Frameworks wie Django, Rails, Hibernate und andere anhand der Ziel-MySQL-Version überprüft werden müssen. Dazu gehört Anpassung der Toolchain für Backup-Pipelines, Monitoring-Exporter und Datenbankmigrations-Tools, die direkt in die MySQL-Interna integriert sind. Und sie umfasst Testaufwand von Abfrageplänen, Änderungen zwischen Optimierer-Versionen, Veränderungen im Indexverhalten sowie von Randfällen in Anwendungsabfragen, die nur unter Last in produktionsähnlichen Bedingungen auftreten.

In einer Unternehmensflotte mit Hunderten oder Tausenden von Datenbank-Hosts, heterogenen Anwendungsabhängigkeiten, durch Änderungskontrollprozesse geregelten Patch-Fenstern und Serviceabhängigkeiten, die eine koordinierte Validierung erfordern, handelt es sich um ein koordiniertes Arbeitsprogramm und nicht um eine Migration, die sich über ein Wochenende erledigen lässt.

Was passiert, wenn das Upgrade überstürzt durchgeführt wird?

Wenn Teams aufgrund einer Compliance-Frist und nicht aufgrund ihrer tatsächlichen Bereitschaft zu einem MySQL-Upgrade gezwungen werden, ist das daraus resultierende Muster immer dasselbe. Die Support-Auslastung steigt sprunghaft an, da die Anwendungsteams Kompatibilitätsprobleme bei Abfragen entdecken, die in der Staging-Umgebung nicht erkannt wurden. Die Instabilität des Systems äußert sich in Replikationsverzögerungen, unerwartetem Indexverhalten oder Verschlechterungen der Abfragepläne, die sich auf die Latenz im Produktionsbetrieb auswirken. Technische Schulden häufen sich an, da Workarounds eingesetzt werden, um die Frist einzuhalten, was Nacharbeiten verursacht, die in nachfolgenden Sprints behoben werden müssen. Und ungeplante Kosten eskalieren in Form von Entwicklungszeit, potenziellen Serviceunterbrechungen und dem betrieblichen Aufwand für die Verwaltung einer Migration, deren Umfang vor Beginn nicht richtig abgeschätzt wurde.

Unternehmen, die den Übergang nach dem Ende des Supports für MySQL gut bewältigen, behandeln ihn als geplante Migration mit klar definiertem Umfang, ausreichender Testzeit und einer durchgehend stabilen Sicherheitslage – und nicht als Notfallmaßnahme, um eine Frist einzuhalten, auf die sie nicht vorbereitet waren.

Die einfache Lösung: TuxCare ELS für MySQL

TuxCare hat über ein Jahrzehnt damit verbracht, die Automatisierung, das Fachwissen und die Prozesse zu optimieren, die es dem Unternehmen ermöglichen, Sicherheitspatches für Software, deren Lebenszyklus abgelaufen ist, zuverlässig und in großem Umfang bereitzustellen. Mit mehr als 220.000 bereitgestellten Patches für sein gesamtes Produktportfolio hat TuxCare einen Patching-Workflow entwickelt, der sowohl schnell als auch produktionssicher ist.

Speziell für MySQL schließt der ELS von TuxCare die Sicherheitslücke, die durch das EOL von MySQL entsteht:

• Schnelle, SLA-gestützte Sicherheitspatches. TuxCare überwacht kontinuierlich die Veröffentlichung von Sicherheitslücken und liefert Patches für hochgradige und kritische CVEs (CVSS 7.0+) gemäß festgelegten SLAs, sodass Ihre MySQL-Bereitstellungen die von PCI DSS, HIPAA, FedRAMP und anderen Compliance-Rahmenwerken geforderten Patch-Fristen einhalten.
• Vollständige Abdeckung der Abhängigkeitsfläche: TuxCare deckt sowohl die eigene Sicherheitslücke von MySQL als auch die gebündelten Bibliotheken von Drittanbietern wie OpenSSL, curl, LZ4 und andere ohne zusätzliche Kosten ab. Die versteckten EOL-Risiken in den kompilierten Abhängigkeiten von MySQL werden nicht zu Ihrem Problem.
• Nahtlose Integration in Ihre bestehenden Arbeitsabläufe. Ganz gleich, ob Sie MySQL-Updates derzeit über Paketmanager, Konfigurationsmanagement-Tools oder Ihre bestehenden CI/CD-Pipelines verwalten – Sie können Ihre Update-Quelle auf das sichere Repository von TuxCare umstellen, ohne Ihren bestehenden Workflow wesentlich zu verändern. Ihre aktuelle Toolchain bleibt davon unberührt.
• Signierte, manipulationssichere Pakete. Jeder von TuxCare bereitgestellte Patch wird vor der Übernahme in Ihr Repository umfassend auf Integrität, Funktionalität und Regression getestet, und die Pakete sind kryptografisch signiert, sodass Sie genau wissen, was Sie bereitstellen.
• Kompetenter Support rund um die Uhr  Das Sicherheitsteam von TuxCare steht Ihnen rund um die Uhr für die Einstufung von Sicherheitslücken, Patch-Anfragen und Fehlerbehebung zur Verfügung, sodass Sie bei Sicherheitsvorfällen im Zusammenhang mit dem EOL von MySQL stets auf fachkundige Unterstützung zählen können.

Um zu sehen, welche MySQL-CVE-Probleme bereits behoben wurden, unterhält TuxCare einen Live-CVE-Tracker. Weitere Informationen zum Patching-Prozess und zu den Validierungsstandards von TuxCare finden Sie im technischen Whitepaper.

Lassen Sie nicht zu, dass das EOL von MySQL Ihre Datenbankinfrastruktur gefährdet

Das Ende des Supportzyklus für MySQL bedeutet nicht, dass Ihre Datenbanken sofort gefährdet sind. Es bedeutet jedoch, dass der Sicherheitsschutz, auf den sich Ihre Infrastruktur bisher verlassen hat, wegfällt und jede ab diesem Zeitpunkt veröffentlichte CVE eine Sicherheitslücke darstellt, für die es keine Möglichkeit zur Behebung durch den Hersteller gibt.

Die Teams, die dies gut bewältigen, sind diejenigen, die das Ende der Lebensdauer von MySQL als ein Sicherheitsproblem betrachten, das bewusst gemanagt werden muss, und nicht als eine Frist, auf die man unter Druck reagieren muss. Sie können eine wohlüberlegte Migration auf MySQL 8.4 LTS planen, wenn dies tatsächlich mit der Kapazität Ihrer Infrastruktur, der Bereitschaft Ihrer Anwendungsteams und den Change-Management-Prozessen Ihres Unternehmens vereinbar ist. Sie können den Umfang der Migration sorgfältig festlegen, bevor Sie sich auf einen Zeitplan festlegen. Oder Sie können TuxCare ELS nutzen, um die Sicherheit und Compliance-Abdeckung aufrechtzuerhalten, während Sie diese Entscheidungen nach Ihren eigenen Vorstellungen treffen – und nicht nach dem Zeitplan eines Compliance-Audits.

ELS for MySQL ist keine Notlösung. Es ist die Lösung, die Ihre Datenbankinfrastruktur schützt, Ihre Compliance-Anforderungen erfüllt und es Ihren Entwicklerteams ermöglicht, sich auf die Entwicklung zu konzentrieren, anstatt Notfallmigrationen zu bewältigen.

Wenn das EOL von MySQL derzeit auf Ihrem Sicherheitsradar steht, besuchen Sie den Endless Lifecycle Support für Open-Source-Software von TuxCare und erfahren Sie, wie erweiterter Support Ihre Datenbankinfrastruktur so lange schützen kann, wie Sie es benötigen.

Zusammenfassung

Artikel Name

MySQL EOL: Mit TuxCare ELS auf der sicheren Seite

Beschreibung

Steht Ihnen das Ende der Lebensdauer von MySQL bevor? Sorgen Sie für Sicherheit und Compliance, ohne ein überstürztes Upgrade durchführen zu müssen. TuxCare ELS deckt MySQL und dessen gesamte Abhängigkeitslandschaft ab.

Autor

Artem Karasev

Name des Herausgebers

TuxCare

Logo des Herausgebers