VPS für MySQL

MySQL und MariaDB sind die Datenbanken hinter WordPress, Bitrix, OpenCart und den meisten PHP-Projekten. Eine kleine Datenbank läuft problemlos auf demselben VPS wie die Website, die Standardeinstellungen sind jedoch auf einen minimalen Server ausgelegt: ein Buffer Pool von 128 MB, langsame Abfragen werden nicht protokolliert. Hier lesen Sie, was Sie ändern sollten und worauf es bei der Tarifwahl ankommt.

innodb_buffer_pool_size: der wichtigste Parameter

InnoDB hält die Seiten von Tabellen und Indizes im Buffer Pool. Solange die heißen Daten hineinpassen, greifen Abfragen kaum auf die Festplatte zu. Einen praktischen Richtwert liefert MySQL selbst: Der Modus innodb_dedicated_server weist dem Pool auf Servern mit 1–4 GB die Hälfte des Arbeitsspeichers zu und auf Servern mit mehr als 4 GB drei Viertel. Diese Regel gilt für eine Maschine, auf der nur die Datenbank läuft. Laufen auf demselben VPS PHP-FPM, Webserver und Redis, ziehen Sie deren Verbrauch ab und berechnen erst dann den Pool.

Ob der Pool ausreicht, verraten die Zähler: Vergleichen Sie Innodb_buffer_pool_reads (Lesezugriffe von der Festplatte) mit Innodb_buffer_pool_read_requests (alle Zugriffe). Ist der Anteil der Festplattenzugriffe spürbar und steigt er, ist der Speicher zu knapp. In MySQL 8 lässt sich die Pool-Größe im laufenden Betrieb per SET GLOBAL ändern, ohne Neustart, sodass Sie den Wert unter realer Last abstimmen können.

Der zweite Parameter, den Sie bei einer Datenbank mit vielen Schreibvorgängen prüfen sollten, ist die Größe des Redo-Logs. Ist es zu klein, schreibt InnoDB geänderte Seiten zu oft auf die Festplatte, und das Schreiben läuft stoßweise. Seit Version 8.0.30 legt innodb_redo_log_capacity die Größe fest, anstelle der früheren innodb_log_file_size und innodb_log_files_in_group; in MariaDB wird weiterhin innodb_log_file_size verwendet.

Der übrige Speicherverbrauch entfällt auf die Verbindungen: Sortier- und Join-Puffer werden pro Thread zugewiesen. Ein hoher Wert für max_connections „für alle Fälle“ führt bei Spitzenlast zu einem OOM. Für eine typische CMS-Website genügt ein VPS mit 4 GB; ein Shop mit großem Katalog braucht mehr.

Das Slow Query Log

Meist bremst den Datenbankserver nicht ein schwacher Tarif aus, sondern ein paar Abfragen ohne Index. Aktivieren Sie das Protokoll für langsame Abfragen:

• slow_query_log = ON und long_query_time = 1 – standardmäßig liegt die Schwelle bei 10 Sekunden, und das Log bleibt fast leer;
• log_queries_not_using_indexes – nur kurzzeitig bei der Fehlersuche: Auf einem ausgelasteten Server wächst das Log schnell;
• eine Zusammenfassung erstellen Sie mit mysqldumpslow oder pt-query-digest, eine verdächtige Abfrage analysieren Sie mit EXPLAIN.

Typische Funde sind eine Sortierung nach einem Feld ohne Index, LIKE '%…%' auf einer großen Tabelle und Abfragen auf Options- und Metadatentabellen von CMS-Plugins. Ein in fünf Minuten angelegter Index bringt oft mehr als der Umzug auf einen doppelt so teuren Tarif. Die Besonderheiten der Datenbanken beliebter CMS behandeln die Seiten VPS für WordPress und VPS für Bitrix.

Backups: Dump, physische Kopie und Binlog

• mysqldump mit der Option --single-transaction erstellt eine konsistente Kopie der InnoDB-Tabellen, ohne Schreibvorgänge zu blockieren. Geeignet für Datenbanken bis zu einigen zehn Gigabyte; das Einspielen eines großen Dumps dauert Stunden, weil alle Indizes neu aufgebaut werden.
• Physische Kopie – Percona XtraBackup für MySQL oder mariadb-backup für MariaDB. Sie kopiert die Datendateien im laufenden Betrieb und lässt sich um ein Vielfaches schneller wiederherstellen; für große Datenbanken ist das die Hauptmethode.
• Das Binärlog (Binlog) ermöglicht zusätzlich zu jeder dieser Kopien die Wiederherstellung auf einen bestimmten Zeitpunkt: Sie spielen die Kopie ein und anschließend die Binlog-Ereignisse bis zur gewünschten Position. Die Aufbewahrungsdauer legt binlog_expire_logs_seconds fest; in MySQL 8 sind es standardmäßig 30 Tage, und bei einer aktiven Datenbank belegen die Logs mehr Platz als die Daten selbst.

Schicken Sie die Kopien auf ein System außerhalb des Servers – etwa auf einen VPS für Backups – und testen Sie die Wiederherstellung regelmäßig auf einer Testmaschine. Ein Backup, das nie eingespielt wurde, ist nur die Hoffnung auf ein Backup.

Replikation und Schreibsicherheit

Eine Replik auf einem zweiten Server brauchen Sie, um bei einem Ausfall schnell umzuschalten und schwere Berichte von der Hauptdatenbank fernzuhalten. Richten Sie sie mit GTID ein: So lassen sich Rollen leichter tauschen und neue Repliken einfacher anbinden. Bedenken Sie, dass eine asynchrone Replik hinterherhinken kann und eine gerade geschriebene Zeile dort noch nicht sichtbar ist. Die Verzögerung sehen Sie in SHOW REPLICA STATUS (Feld Seconds_Behind_Source), und die Verbindung zwischen den Servern sollte über ein privates Netzwerk oder WireGuard laufen.

Für die Datensicherheit belassen Sie die Standardwerte innodb_flush_log_at_trx_commit = 1 und sync_binlog = 1: Jeder Commit wird auf die Festplatte geschrieben. Genau hier zeigt sich der Unterschied zwischen Festplatten – auf NVMe dauert ein synchroner Schreibvorgang Bruchteile einer Millisekunde, auf einem überlasteten gemeinsamen Array wird das Warten darauf zur größten Bremse.