Verwaltung großer Datenbanken auf virtuellen Servern

Warum sich große Datenbanken auf einem VPS anders verhalten

Ein virtueller privater Server gibt Ihnen einen Ausschnitt einer physischen Maschine: eine feste Anzahl virtueller CPUs, eine bestimmte Menge RAM und einen Datenträger, der oft über das Netzwerk angebunden ist oder mit anderen Kunden geteilt wird. Kleine Datenbanken bemerken diese Grenzen selten. Sobald eine Datenbank aber auf Dutzende oder Hunderte Gigabyte anwächst oder viele gleichzeitige Abfragen verarbeitet, bestimmen die Einschränkungen der virtuellen Umgebung zunehmend die Performance.

Die gute Nachricht: Die meisten Probleme folgen vorhersehbaren Mustern. Dieser Leitfaden zeigt, wie Sie einen VPS für eine Datenbank dimensionieren, welche Einstellungen Sie zuerst anpassen sollten, wie Sie mit Speicher und Backups umgehen und wann es Zeit ist, über einen einzelnen Server hinaus zu skalieren. Die Beispiele beziehen sich auf MySQL/MariaDB und PostgreSQL, die beiden Engines, die am häufigsten auf VPS-Tarifen laufen.

Den Server dimensionieren: RAM, CPU und Datenträger

Eine allgemeingültige Formel gibt es nicht, doch das Verhältnis zwischen Ihren Daten und Ihren Ressourcen verrät viel.

Arbeitsspeicher

Datenbanken halten Daten und Indizes im Speicher vor. Passt das „Working Set“ – also die Daten, die tatsächlich regelmäßig gelesen werden – in den RAM, kommen die meisten Abfragen ganz ohne Festplattenzugriff aus. Passt es nicht hinein, wird jeder Cache-Fehltreffer zu einem Lesezugriff auf den Datenträger, und die Performance kann deutlich einbrechen. Sie brauchen nicht so viel RAM, wie die Datenbank insgesamt groß ist; Sie brauchen genug für die heißen Daten plus Reserven für Verbindungen, Sortiervorgänge und das Betriebssystem.

CPU

Die CPU ist wichtig bei komplexen Abfragen, vielen gleichzeitigen Verbindungen und Kompression. Prüfen Sie auf geteilten virtuellen Hosts, ob Ihr Tarif dedizierte oder geteilte vCPUs bietet; geteilte Kerne können gedrosselt werden, wenn Nachbarn stark ausgelastet sind. Das zeigt sich in schwankenden Abfragezeiten.

Datenträger

Datenbank-Workloads bestehen überwiegend aus kleinen, zufälligen Lese- und Schreibzugriffen. Latenz und IOPS sind daher weit wichtiger als sequenzieller Durchsatz. SSD- oder NVMe-Speicher ist für große Datenbanken praktisch Pflicht. Unser Artikel über SSDs und Hosting-Performance erklärt, warum.

Die zentralen Einstellungen anpassen

Standardkonfigurationen sind bewusst zurückhaltend, damit sie auch auf winzigen Maschinen laufen. Eine Handvoll Einstellungen bringt auf einem größeren Server den Großteil des Nutzens. Ändern Sie immer nur eine Sache und messen Sie das Ergebnis.

MySQL und MariaDB (InnoDB)

• innodb_buffer_pool_size: der wichtigste Cache für Daten und Indizes. Auf einem Server, der nur für die Datenbank da ist, liegt ein üblicher Ausgangswert bei etwa der Hälfte bis drei Vierteln des RAM, damit Platz für Betriebssystem und Verbindungen bleibt.
• innodb_log_file_size (bzw. innodb_redo_log_capacity in neueren MySQL-Versionen): Größere Redo-Logs glätten schreiblastige Workloads.
• max_connections: Bleiben Sie realistisch; jede Verbindung verbraucht Speicher.

[mysqld]
innodb_buffer_pool_size = 12G
innodb_redo_log_capacity = 2G
max_connections = 200
slow_query_log = 1
long_query_time = 1

PostgreSQL

• shared_buffers: PostgreSQL nutzt zusätzlich den Page Cache des Betriebssystems, daher wird dieser Wert als Ausgangspunkt oft auf etwa ein Viertel des RAM gesetzt.
• effective_cache_size: ein Hinweis für den Planer, wie viel Speicher insgesamt für Caching zur Verfügung steht.
• work_mem: Speicher pro Sortier- oder Hash-Operation; er kann pro Abfrage mehrfach belegt werden, erhöhen Sie ihn also vorsichtig.

shared_buffers = 4GB
effective_cache_size = 12GB
work_mem = 32MB
maintenance_work_mem = 1GB
log_min_duration_statement = 1000

Diese Beispielwerte gehen von einem Server mit etwa 16 GB RAM aus, der nur der Datenbank dient. Sie dienen der Veranschaulichung und sind keine Empfehlung für Ihren Workload; lesen Sie die Dokumentation Ihrer Engine-Version, denn Namen und Standardwerte von Einstellungen ändern sich zwischen Releases.

Indizes, Abfragen und Schema

Hardware und Tuning stoßen irgendwann an Grenzen. Bei großen Datenmengen kann ein einziger fehlender Index eine Abfrage von Millisekunden in einen vollständigen Table Scan verwandeln, der Gigabytes liest. Machen Sie diese Gewohnheiten zur Routine:

• Aktivieren Sie das Slow Query Log und werten Sie es regelmäßig aus.
• Nutzen Sie EXPLAIN (bzw. EXPLAIN ANALYZE in PostgreSQL), um zu sehen, wie Abfragen tatsächlich ausgeführt werden.
• Indizieren Sie Spalten, die häufig in WHERE-, JOIN- und ORDER BY-Klauseln vorkommen, aber nicht alles, denn jeder Index verlangsamt Schreibvorgänge und belegt Platz.
• Archivieren oder partitionieren Sie alte Daten. Zeitbasierte Partitionierung macht es günstig, alte Monate zu entfernen, statt riesige DELETE-Befehle auszuführen.
• Achten Sie in PostgreSQL darauf, dass Autovacuum hinterherkommt; aufgeblähte Tabellen bei großen, häufig aktualisierten Daten verschlechtern die Performance mit der Zeit.

Schemaänderungen an großen Tabellen

Eine Spalte oder einen Index zu einer Tabelle mit Hunderten Millionen Zeilen hinzuzufügen, kann sie sperren oder stundenlang laufen. Prüfen Sie, ob Ihre Engine-Version für die gewünschte Operation Online- oder Instant-Schemaänderungen unterstützt, testen Sie die Änderung zuerst an einer Kopie der Produktionsdaten und planen Sie sie für eine ruhige Phase ein. Für MySQL sind Online-Schema-Change-Tools zu diesem Zweck weit verbreitet; in PostgreSQL vermeidet CREATE INDEX CONCURRENTLY, dass Schreibzugriffe während des Indexaufbaus blockiert werden.

Speicheraufteilung und Datenträgerverwaltung

Große Datenbanken füllen Datenträger schneller als erwartet, besonders wenn man Binärlogs, Write-Ahead-Logs, temporäre Dateien und lokale Backups mitzählt. Ist der Platz erschöpft, kann die Datenbank stehen bleiben und im schlimmsten Fall Datenkorruption drohen.

• Getrennte Volumes für Daten und Backups erleichtern die Größenänderung und verhindern, dass Backups den Datenträger der Daten füllen.
• Legen Sie Aufbewahrungsfristen fest für die Binärlogs von MySQL und behalten Sie das WAL-Wachstum von PostgreSQL im Blick, besonders wenn Replication Slots genutzt werden.
• Warnen Sie bei freiem Speicherplatz lange bevor er ausgeht, etwa bei 80 und 90 Prozent Belegung.
• Kennen Sie die Limits Ihres Anbieters. Manche VPS-Tarife begrenzen IOPS oder Durchsatz pro Volume; größere Volumes oder höhere Tarife können diese Grenzen anheben.

df -h
iostat -x 5
du -sh /var/lib/mysql /var/lib/postgresql

Backups und Wiederherstellung

Bei einer großen Datenbank ist die Backup-Strategie ebenso wichtig wie die Performance. Ein Plan sollte zwei Fragen beantworten: Wie viele Daten dürfen Sie höchstens verlieren, und wie lange darf ein Ausfall höchstens dauern?

Logische Backups

Werkzeuge wie mysqldump oder pg_dump exportieren Daten als SQL- oder Archivdateien. Sie sind portabel und einfach, werden bei wachsenden Datenbanken aber langsam in der Erstellung und vor allem in der Wiederherstellung.

Physische Backups

Werkzeuge wie Percona XtraBackup oder MariaDB Backup für Datenbanken der MySQL-Familie und pg_basebackup für PostgreSQL kopieren die Datendateien direkt. Zusammen mit Binärlogs oder WAL-Archivierung ermöglichen sie eine Point-in-Time-Recovery.

Snapshots

Datenträger-Snapshots des Anbieters sind bequem, doch ein Snapshot einer laufenden Datenbank ist nur dann sicher, wenn die Engine daraus konsistent wiederherstellen kann. Lesen Sie die Hinweise Ihres Anbieters und testen Sie Wiederherstellungen, bevor Sie sich darauf verlassen.

pg_dump -Fc -d appdb -f /backup/appdb.dump
mysqldump --single-transaction --routines appdb | gzip > /backup/appdb.sql.gz

Welche Methode Sie auch nutzen: Bewahren Sie Kopien außerhalb des Servers auf, idealerweise bei einem anderen Anbieter oder in einer anderen Region, und planen Sie regelmäßige Test-Wiederherstellungen ein. Ein Backup, das Sie nie wiederhergestellt haben, ist eine Annahme, kein Plan.

Ein einfacher Wiederherstellungstest

Spielen Sie das letzte Backup in regelmäßigen Abständen auf einen separaten Testserver ein, starten Sie die Datenbank, prüfen Sie Zeilenzahlen wichtiger Tabellen und führen Sie einige typische Abfragen der Anwendung aus. Notieren Sie, wie lange der gesamte Vorgang gedauert hat. Diese Zahl ist Ihre realistische Wiederherstellungszeit – und sie zeigt früh, wann logische Dumps für Ihre Datenmenge zu langsam werden.

Monitoring und Wartung

Beobachten Sie Trends statt einzelner Momente. Nützliche Kennzahlen sind Cache-Trefferquote, Abfragen pro Sekunde, langsame Abfragen, Replikationsverzögerung, genutzte Verbindungen, freier Speicherplatz, I/O-Wait und Speicherdruck. Viele Monitoring-Lösungen bringen fertige Datenbank-Dashboards mit; schon einfache Skripte, die bei Speicherplatz und Replikationsstatus Alarm schlagen, verhindern die häufigsten Ausfälle.

Vergessen Sie nicht die Infrastruktur rund um die Datenbank. Ein abgelaufener VPS-Tarif, eine unbezahlte Rechnung oder eine verfallene Domain kann eine Anwendung genauso zuverlässig lahmlegen wie eine abgestürzte Datenbank. Mit TLDix verfolgen Sie Hosting- und Domainverlängerungen gemeinsam im Hosting-Panel, sodass die Verlängerungstermine der Server hinter Ihren Datenbanken nicht vom Gedächtnis abhängen.

Wann Sie über einen VPS hinaus skalieren sollten

Ein einzelner, gut abgestimmter Server leistet viel. Anzeichen dafür, dass Sie ihm entwachsen sind, sind ein Working Set, das nicht mehr in den größten bezahlbaren Tarif passt, dauerhafte CPU-Auslastung trotz optimierter Abfragen oder Backup- und Wiederherstellungszeiten, die Ihre Wiederherstellungsziele überschreiten.

Übliche nächste Schritte, grob nach Komplexität geordnet:

1. Vertikale Skalierung: Wechsel in einen größeren Tarif mit mehr RAM und schnellerem Speicher.
2. Read Replicas: Reporting und lesintensiven Traffic auf eine oder mehrere Repliken verlagern.
3. Connection Pooling: Werkzeuge wie PgBouncer oder ProxySQL verringern den Overhead vieler kurzlebiger Verbindungen.
4. Caching-Schicht: häufige Abfrageergebnisse in einem In-Memory-Cache speichern.
5. Verwaltete Datenbankdienste oder Sharding für Workloads, die eine einzelne Maschine wirklich übersteigen.

Wenn Sie für die nächste Stufe einen neuen Anbieter suchen, behandelt unser Leitfaden zur Wahl des besten Webhostings die Fragen, die Sie zu Speicher, Support und Upgrade-Möglichkeiten stellen sollten.