MySQL Governor: Datenbankressourcen einzelner Hosting-Kunden begrenzen

Was MySQL Governor begrenzt

MySQL Governor ist eine CloudLinux-Komponente für Shared-Hosting-Server, kein allgemeines Feature von MySQL. Sie erfasst Datenbanklast anhand der zugeordneten Benutzer und kann Abfragen bei überschrittenen Schwellen über Lightweight Virtual Environments, kurz LVE, einschränken. So lässt sich die Last einzelner Hosting-Konten differenzierter betrachten als allein die Gesamtauslastung des Datenbankservers.

Im Mittelpunkt stehen CPU und Festplatten-I/O: Der Governor betrachtet Rechenlast sowie Lese- und Schreibaktivität. Eine hohe Nutzung kann etwa durch einen Import oder eine häufig ausgeführte Shop-Abfrage entstehen. Die Zuordnung zu einem Konto macht diese Nutzung sichtbar; ob sie für den jeweiligen Vorgang angemessen ist, muss anschließend im Kontext beurteilt werden.

Ein Datenbanklimit für diese Ressourcen ist keine Speicherplatzquote. Eine große, selten genutzte Datenbank kann wenig laufende CPU- und I/O-Last verursachen; umgekehrt kann eine kleine Datenbank durch viele aufwendige Zugriffe stark beansprucht werden. Auch Verbindungslimits beantworten eine andere Frage: Sie begrenzen Zugriffe, ersetzen aber nicht automatisch die Steuerung von CPU und I/O.

Wird eine Abfrage gedrosselt, ist sie nicht zwangsläufig fehlerhaft. Die Einschränkung kann andere Konten vor hoher Last schützen, zugleich aber eine legitime Anwendung verlangsamen. Garantierte Antwortzeiten folgen daraus nicht, denn Datenbankdienst, Hardware und weitere Anwendungskomponenten bleiben gemeinsam genutzte Teile des Systems.

Für die Einordnung des Zusammenspiels von Konten, Last und LVE bietet der ergänzende Überblick zur Begrenzung der Datenbanklast mit CloudLinux MySQL Governor einen weiteren Einstieg. Entscheidend für die konkrete Einrichtung bleiben die tatsächlich installierte Umgebung und die dort geltenden Einstellungen.

Edition und Kompatibilität prüfen

Vor der Planung der Datenbanklimits prüfst du zunächst Edition und Lizenz. CloudLinux OS Admin enthält MySQL Governor laut Hersteller nicht. Ein CloudLinux-System allein ist deshalb kein Nachweis, dass die Komponente für die gewählte Edition verfügbar, lizenziert und auf dem Server installiert ist.

Anschließend betrachtest du die Kombination aus CloudLinux-Version, Governor-Paket und Datenbankserver. MySQL und MariaDB sind dabei getrennte Entwicklungszweige: Ein unterstützter MySQL-Stand sagt nicht aus, dass ein gleich alter MariaDB-Stand unter denselben Bedingungen funktioniert. Auch das verwendete Control Panel und dessen Integration gehören zur Prüfung.

Die Mindeststände zeigen, warum eine pauschale Freigabe nicht genügt: Für MySQL 8.4 nennt CloudLinux mindestens MySQL Governor 1.2-129. MariaDB 11.4 benötigt mindestens Version 1.2-122 des Governors und wird in der Herstellerdokumentation nicht für CloudLinux OS 7 unterstützt. Diese Angaben betreffen die genannten Zweige und ersetzen nicht die Prüfung der übrigen Kombination.

Als Installationsumgebungen nennt der Hersteller unter anderem cPanel, Plesk, DirectAdmin, ISPmanager und InterWorx sowie Server ohne Control Panel. Bei einem abweichenden oder selbst integrierten Panel solltest du die konkrete Unterstützung und insbesondere die Benutzerzuordnung gesondert klären. Eine aufgelistete Datenbankversion ist keine Zusage für jede Panel- und Betriebssystemkombination.

Halte die vorhandenen Versionen und Pakete vor einer Änderung fest und vergleiche sie mit der Dokumentation für die geplante Zielkonfiguration. So erkennst du, ob zunächst ein Komponentenwechsel nötig wäre, statt eine vorhandene Installation allein anhand des Datenbanknamens als kompatibel einzustufen.

Datenbankbenutzer Hosting-Konten zuordnen

Damit die Last einem Hosting-Kunden zugeordnet werden kann, muss die Verbindung zwischen Datenbankbenutzern und Hosting-Konten stimmen. Bei einer Panel-Integration wird dafür üblicherweise die Datei /etc/container/dbuser-map gepflegt. Der Governor übernimmt Änderungen an dieser Zuordnung laut Integrationsdokumentation innerhalb von fünf Minuten.

Ein Beispiel: Ein Hosting-Konto betreibt einen Shop und ein separates Blog, die jeweils mit einem eigenen Datenbankbenutzer arbeiten. Sind beide Benutzer demselben Konto zugeordnet, kann die Datenbanklast entsprechend diesem Konto erfasst werden. Fehlt einer der Einträge oder zeigt er auf das falsche Konto, ist die angezeigte Zuordnung für eine kundenbezogene Bewertung nicht verlässlich.

Prüfe die Benutzerzuordnung deshalb nicht nur bei der Erstinstallation. Auch nach dem Anlegen oder Verschieben von Datenbanken und Benutzern muss das Panel die Zuordnung korrekt nachführen. Bei einer Kontrolle direkt nach einer Änderung ist die dokumentierte Übernahmefrist zu berücksichtigen, bevor du aus einem noch alten Stand auf einen dauerhaften Fehler schließt.

Besonders wichtig ist ein fehlendes Mapping im Modus Abusers: Laut Hersteller emuliert dieser dann Single. Eingeschränkte Kunden teilen sich in Single ein gemeinsames eingeschränktes LVE, statt jeweils im eigenen Kunden-LVE begrenzt zu werden. Ein aktivierter Abusers-Modus allein belegt daher noch nicht, dass die beabsichtigte kontoindividuelle Einschränkung tatsächlich greift.

Gleiche bei Auffälligkeiten die betroffenen Datenbankbenutzer, die gepflegte Zuordnung und die gewählte Betriebsart miteinander ab. Selbst ein korrektes Mapping verspricht keine vollständige Isolation: Der Datenbankdienst und die zugrunde liegende Hardware werden weiterhin gemeinsam genutzt. Die Zuordnung ist eine Voraussetzung für die kundengenaue Steuerung, kein Ersatz für Kapazitätsplanung.

Betriebsarten im Vergleich

Die Betriebsart bestimmt, ob MySQL Governor Datenbanklast nur beobachtet oder Abfragen in einer begrenzten Umgebung ausführt. Für die Wahl sind nicht allein die Schwellen wichtig: Auch die Zuordnung der Datenbankbenutzer und die Frage, welche Kunden sich ein LVE teilen, beeinflussen die Wirkung.

Für eine Bestandsaufnahme bietet sich Off an: Die beobachtete Nutzung zeigt, welche Konten und Zeiträume eine genauere Prüfung verdienen, ohne dass der Governor dabei Abfragen drosselt. Ein einzelner hoher Momentwert sagt allerdings noch nicht, ob ein Konto dauerhaft viel Last erzeugt oder gerade eine legitime Wartungsarbeit erledigt.

Bei Abusers teilen sich eingeschränkte Datenbankabfragen das LVE-Ressourcenbudget mit anderen Prozessen desselben Kontos, etwa PHP. Eine Einschränkung kann deshalb nicht nur Abfragen verlängern: Auch die Anwendung kann langsamer reagieren, wenn ihre Prozesse um dieselben begrenzten Ressourcen konkurrieren. Umgekehrt kann bereits beschäftigtes PHP-Budget die Datenbankarbeit beeinflussen.

Single ist veraltet und vor allem für Bestandskonfigurationen sowie das dokumentierte Ersatzverhalten relevant: Mehrere eingeschränkte Kunden teilen sich eine Umgebung und können dort miteinander konkurrieren. Fehlt die dbuser-map, emuliert Abusers dieses Verhalten; aus der gewählten Einstellung allein lässt sich dann nicht auf eine kundeneigene Einschränkung schließen. Auch All ist veraltet und keine reguläre Empfehlung für eine Neuinstallation.

Datenbanklimits und Zeitfenster planen

MySQL Governor unterscheidet CPU-Nutzung sowie Lese- und Schreib-I/O. Die dokumentierte CLI zeigt CPU in Prozent und I/O in MB/s; für Lesen und Schreiben können getrennte Werte konfiguriert sein. Diese Größen beschreiben unterschiedliche Belastungen: Ein rechenintensiver Vorgang muss nicht zugleich besonders viel auf den Datenträger schreiben.

Die Schwellen current, short, middle und long betrachten kurzfristige und länger anhaltende Nutzung. Ihre Überschreitung löst je nach Betriebsart und Konfiguration eine Einschränkung aus. Sie sind weder garantierter Durchsatz noch vier unabhängig voneinander permanent hart durchgesetzte Leistungszusagen. Welche Einschränkung tatsächlich wirkt, hängt auch vom gewählten Verfahren und den LVE-Limits ab.

Ein Import verdeutlicht den Unterschied: Steigt die Schreiblast kurz an und fällt danach wieder ab, kann das zu einem geplanten Arbeitsvorgang gehören. Bleibt sie über längere Zeit hoch, beansprucht der Import Ressourcen länger. Für die Entscheidung solltest du neben dem Spitzenwert prüfen, welche Ressource betroffen ist, wie lange der Vorgang dauert und ob er sich wiederholt.

Niedrige Auslöseschwellen können andere Kunden früher vor anhaltender Last schützen, bremsen aber möglicherweise legitime Importe oder Wartungsjobs. Hohe Schwellen lassen solchen Arbeiten mehr Spielraum, erlauben zugleich aber länger eine höhere Belastung. Ein Wartungsfenster oder eine gezielt geplante Kapazität kann sinnvoller sein als eine dauerhafte Ausnahme.

Plane die Governor-Werte im Verhältnis zu den LVE-Limits und zu den tatsächlich angebotenen Tarifen. Die Herstellerempfehlungen betrachten diesen Zusammenhang ausdrücklich; allgemeingültige Produktionswerte lassen sich daraus nicht ableiten. Beobachtete Anfragelast, Abfrageeffizienz und die Art der Kundenarbeiten liefern die Grundlage, um Schwellen nach Einführung kontrolliert anzupassen.

Einführung und Tariflimits vorbereiten

Vor Installation oder Upgrade steht ein vollständiges Datenbankbackup einschließlich der Systemtabellen. Plane auch, wie die Wiederherstellung im Bedarfsfall erfolgen soll. Der Hersteller weist darauf hin, dass Datenbankpakete dabei aus CloudLinux-Repositories aktualisiert werden können; ein Paketwechsel ist deshalb keine folgenlose Nebenwirkung, die du erst nach der Installation prüfen solltest.

Prüfe anschließend die Kombination aus CloudLinux-Edition und -Version, Lizenz, Datenbankzweig, Governor-Paket und Control Panel. Eine unterstützte Datenbankversion allein belegt nicht, dass jede Kombination dieser Komponenten unterstützt wird. Stimmen Paketstände oder Panel-Integration nicht, muss die konkrete Unterstützung vor einem Eingriff geklärt werden.

Beginne nach der technischen Vorbereitung mit Beobachtung statt sofortiger Drosselung. Vergleiche typische Geschäftszeiten mit bekannten Imports und Wartungsfenstern und prüfe dabei, ob die Datenbankbenutzer den richtigen Hosting-Konten zugeordnet sind. Ohne verlässliche Zuordnung lässt sich aus einer scheinbar niedrigen Kontolast nicht sicher auf den tatsächlichen Ressourcenbedarf schließen.

Leite aus dieser Bestandsaufnahme eine begrenzte Einführung ab: Lege fest, welche Konten oder Tarife betroffen sein sollen, wie Beschwerden erfasst werden und anhand welcher Beobachtungen du die Einstellung überprüfst. Gleiche nach der Aktivierung Einschränkungen mit Anwendungsvorgängen ab, statt jede Überschreitung unmittelbar als Fehlverhalten zu bewerten.

Der CloudLinux Manager kann Governor-Limits paketbezogen verwalten; für einzelne Kunden können davon abweichende Werte gelten. Dokumentiere daher bei jeder Änderung die Herkunft des Limits: Stammt es aus dem Paket oder ist es individuell gesetzt? So lässt sich später nachvollziehen, welche Kunden eine Tarifänderung betrifft und welche Ausnahme separat überprüft werden muss.

Aktuelle Last und Verlauf prüfen

Für die Diagnose benötigst du sowohl eine Momentaufnahme als auch den zeitlichen Verlauf. Die folgenden Befehle werden im Terminal des CloudLinux-Servers ausgeführt, nicht in der MySQL-Konsole. Sie dienen der Einsicht und ändern keine Limits; für eine sinnvolle Auswertung müssen die jeweiligen Werkzeuge installiert und die relevanten Daten verfügbar sein.

Gleiche auffällige Konten mit der Benutzerzuordnung und der gewählten Betriebsart ab. Fehlt ein Datenbankbenutzer im Mapping, kann die sichtbare Last für das Hosting-Konto unvollständig sein. Die Integrationsdokumentation nennt für Änderungen an der Zuordnungsdatei eine Übernahme innerhalb von fünf Minuten; eine unmittelbar danach geprüfte Ausgabe kann daher noch nicht den neuen Stand zeigen.

Vergleiche anschließend den Zeitpunkt einer Einschränkung mit dem beobachteten Anwendungsvorgang. Ein hoher Einzelwert kann zu einem Import gehören und ist für sich genommen kein Beleg für dauerhaft übermäßige Nutzung. Die Anleitung zum Lesen von MySQL-Governor-Reports ergänzt die Einordnung der angezeigten Kennzahlen.

Drosselung und Ursachen unterscheiden

Wenn eine Website langsam wird, prüfe zunächst, ob zum betreffenden Zeitpunkt überhaupt eine Einschränkung aktiv war und welcher Grund angezeigt wird. Ordne diesen Befund dem konkreten Vorgang zu: Ein langsamer Checkout und ein gleichzeitig laufender Import können zusammenhängen, müssen es aber nicht. Ohne zeitliche Übereinstimmung wäre der Governor als alleinige Ursache vorschnell festgelegt.

Im Modus Abusers werden eingeschränkte Datenbankabfragen im LVE des zugeordneten Kontos ausgeführt. Dort teilen sie das Ressourcenbudget mit anderen Kontoprozessen, etwa PHP. Betrachte deshalb bei einer Beschwerde beide Seiten: Eine datenbankintensive Aufgabe kann mit PHP um Ressourcen konkurrieren; umgekehrt kann bereits beanspruchte LVE-Kapazität die eingeschränkten Abfragen beeinflussen.

Wiederholt sich die Last bei einer Shop-Funktion, untersuche die betreffende Abfrage und ihren Abfrageplan zusammen mit geeigneten Datenbankstatistiken. Ein fehlender oder ungeeigneter Index ist eine mögliche Ursache, aber nicht die einzige. Die Begrenzung kann die Auswirkungen auf gemeinsam genutzte Ressourcen reduzieren; sie korrigiert weder den Plan noch die Anwendungslogik.

Für Single und Abusers beschreibt CloudLinux, dass Einschränkungen aufgehoben werden, nachdem die Nutzung eine Minute unter den Schwellen lag. Prüfe dennoch das tatsächlich konfigurierte Restrict-Verfahren und den zeitlichen Verlauf auf dem eigenen System, statt aus einer kurzen Entlastung sofort auf eine dauerhafte Lösung zu schließen. Eine erneut anlaufende Aufgabe kann später wieder eine Schwelle überschreiten.

Limits nachjustieren oder Architektur ändern

Beginne eine Anpassung mit der Frage, ob die beobachtete Spitze zu einer erwarteten Aufgabe gehört oder regelmäßig den Betrieb beeinträchtigt. Ein geplanter Import lässt sich möglicherweise in ein Wartungsfenster verschieben. Erfasse dabei Dauer, betroffene Ressource und Auswirkungen auf die Anwendung, bevor du aus einem einzelnen Ausschlag eine dauerhafte Tarifänderung ableitest.

Reicht das Zeitfenster nicht aus, kann eine gezielte Tarifausnahme geeigneter sein als eine pauschale Anhebung für alle Kunden. Dokumentiere den Anlass, den verantwortlichen Kontakt und den Zeitpunkt der erneuten Prüfung. Halte auch fest, ob der bisherige Wert vom Paket stammt oder individuell gesetzt wurde: CloudLinux Manager unterstützt paketbezogene Limits und individuelle Abweichungen.

Prüfe nach einer Änderung über einen repräsentativen Zeitraum, ob die beabsichtigte Arbeit besser durchläuft und ob Einschränkungen oder Beschwerden an anderer Stelle auftreten. Setze die Governor-Schwellen dabei in Beziehung zu den LVE-Limits. Eine höhere Schwelle lässt potenziell länger mehr Last zu; sie ist weder ein garantierter Durchsatz noch eine Zusage für bestimmte Antwortzeiten.

Eine andere Stellschraube ist die Ursachenbehebung: Abfrageoptimierung, passende Indizes oder Caching können wiederkehrende Arbeit reduzieren, statt nur deren Auswirkungen zu begrenzen. Datenbankseitige Verbindungslimits beschränken dagegen gleichzeitige Zugriffe und ersetzen nicht automatisch die CPU- und I/O-Steuerung des Governors.

Weichen die Anforderungen eines Kunden dauerhaft stark vom Shared Hosting ab, kann eine eigene Datenbankinstanz oder ein eigener Server sinnvoll sein. Das verschiebt die Entscheidung allerdings von einzelnen Schwellen zur Planung von Kapazität, Wartung und Betrieb. Auch eine solche Trennung sollte nicht pauschal als Garantie für vollständige Isolation oder feste Antwortzeiten dargestellt werden.