Datenbank-Server-Hosting: MySQL, PostgreSQL und MongoDB

Probleme mit der Datenbankleistung haben meistens drei Ursachen: zu wenig Speicher, sodass Daten vom Datenträger in den Pufferpool gelesen werden müssen, Speicher-E/A, die den Transaktionsdurchsatz nicht halten können, oder CPU-Konflikte, weil zu viele gleichzeitige Abfragen sich einen Ressourcenpool teilen. Spezielle Bare-Metal-Server lösen alle drei Probleme auf der Hosting-Seite.

Dieser Artikel geht auf bestimmte Konfigurationsparameter für MySQL, PostgreSQL und MongoDB auf dedizierter Hardware ein und gibt Referenzwerte für die Serverstufen InMotion Hosting. Das sind nur Ausgangspunktwerte, keine allgemeingültigen Einstellungen. Je nachdem, wie deine Workload aussieht, musst du die Werte anpassen, aber mit geprüften Startwerten geht's schneller als mit den Standardeinstellungen.

Warum Datenbank-Workloads auf dedizierte Hardware gehören

Datenbanken reagieren besonders empfindlich auf die Ressourcenkonflikte, die beim Shared Hosting auftreten. Wenn der InnoDB-Pufferpool von MySQL seine Größenbeschränkung erreicht und anfängt, Seiten zu löschen, muss jede weitere Abfrage, die eine gelöschte Seite braucht, von der Festplatte gelesen werden. In einer geteilten Umgebung kann der Datenverkehr eines anderen Nutzers die Auslastung deines Pufferpools im ungünstigsten Moment runterziehen.

Auf einem dedizierten Server speichert der Pufferpool genau das, was du ihm zugewiesen hast. Wenn du InnoDB 100 GB zuweist, hast du 100 GB. Punkt. Die damit verbundene Vorhersehbarkeit ist kein unbedeutender Vorteil. Sie macht den Unterschied zwischen einer Datenbank, die unter Last konsistent arbeitet, und einer, die sich unvorhersehbar verhält.

Das überrascht viele Datenbankadministratoren, die Leistungsschwankungen als einen festen Bestandteil von Datenbanken sehen. Tatsächlich ist das meistens ein Problem des Hostings.

MySQL-/MariaDB-Konfiguration

Größe des InnoDB-Pufferspeichers

Die wichtigste Entscheidung bei der MySQL-Konfiguration ist die Größe des InnoDB-Pufferpools. Das Ziel ist, den gesamten Arbeitsdatensatz im Speicher zu behalten. Auf einem 64-GB-Server (InMotion Essential oder Advanced) solltest du 40 bis 48 GB für den Pufferpool reservieren. Auf einem 192-GB-System kannst du vernünftigerweise 140 bis 160 GB reservieren:

• innodb_buffer_pool_size = 140 GB ( auf einem 192 GB Extreme-Server)
• innodb_buffer_pool_instances = 8 ( verringert Mutex-Konflikte auf Multi-Core-Systemen)
• innodb_log_file_size = 2G ( größere Redo-Protokolle verringern die Häufigkeit von Checkpoints)
• innodb_flush_log_at_trx_commit = 1 ( vollständige ACID-Konformität; für schreibintensive, nicht kritische Workloads auf 2 setzen)
• innodb_io_capacity = 2000 ( für NVMe auf 4000+ erhöhen, um die volle I/O-Auslastung zu ermöglichen)

NVMe Optimierung für MySQL

Die Standardeinstellungen von MySQL wurden für Spinning-Festplatten oder SSD geschrieben. Bei NVMe müssen ein paar Parameter angepasst werden, um eine künstliche Drosselung des E/A-Durchsatzes zu vermeiden:

• innodb_io_capacity_max = 8000 ( ermöglicht Burst-I/O-Auslastung auf NVMe)
• innodb_read_io_threads = 8 ( von Standardwert 4 erhöhen, um NVMe zu nutzen)
• innodb_write_io_threads = 8 ( aus dem gleichen Grund)
• innodb_flush_method = O_DIRECT ( umgeht den Seitencache des Betriebssystems, um doppeltes Puffern mit dem InnoDB-Pufferpool zu vermeiden)

Wenn O_DIRECT auf NVMe aktiviert ist, umgeht MySQL den Seitencache des Betriebssystems und verwaltet seinen eigenen Pufferpool komplett selbst. So wird verhindert, dass der Pufferpool und das Betriebssystem dieselben Daten unabhängig voneinander zwischenspeichern, was auf einem 192-GB-System viel Speicherplatz verschwenden würde, wenn beide Ebenen versuchen würden, den Datensatz zwischenzuspeichern.

Protokollierung langsamer Abfragen

Aktiviere die Protokollierung langsamer Abfragen bei einem Schwellenwert von 100 ms als dauerhaftes Überwachungswerkzeug, nicht nur während der Fehlerbehebung:

• slow_query_log = EIN
• long_query_time = 0,1 ( Schwellenwert 100 ms)
• log_queries_not_using_indexes = ON ( fängt vollständige Tabellenscans ab, auch wenn sie schnell abgeschlossen sind)

PostgreSQL

Speichereinstellungen

Die PostgreSQL ist standardmäßig weniger aggressiv als die von MySQL, weil sie dafür gemacht ist, neben anderen Prozessen zu laufen. Auf einem dedizierten Datenbankserver kannst du viel höhere Werte einstellen:

• shared_buffers = 48 GB ( 25 % des Arbeitsspeichers auf einem System mit 192 GB; PostgreSQL empfiehlt 25 % als Startwert, obwohl manche Workloads von höheren Werten profitieren)
• effective_cache_size = 144 GB ( sagt dem Abfrageplaner, wie viel Speicherplatz für das Caching da ist; auf 75 % des RAM festgelegt)
• work_mem = 256 MB ( pro Sortier-/Hash-Vorgang; mal max_connections für die potenzielle Gesamtnutzung; konservativer Startwert)
• maintenance_work_mem = 4 GB ( wird für VACUUM, CREATE INDEX und ähnliche Vorgänge genutzt)
• max_wal_size = 8 GB ( macht die Checkpoint-Häufigkeit bei Schreib-lastigen Aufgaben weniger oft)

shared_buffers bei 25 % ist eine PostgreSQL , kein Höchstwert. Bei Arbeitslasten mit großen, oft genutzten Datensätzen kann man bis zu 40 % des RAM nutzen, wobei effective_cache_size proportional erhöht werden sollte. Der Abfrageplaner entscheidet anhand von effective_cache_size zwischen Index-Scans und sequenziellen Scans, sodass ein ungenauer Wert zu suboptimalen Abfrageplänen führt.

Verbindungspooling mit PgBouncer

PostgreSQL pro Verbindung einen Prozess. Bei mehr als 200 gleichzeitigen Verbindungen wird der Aufwand für den Prozesskontextwechsel spürbar. PgBouncer fungiert als Verbindungsproxy, der einen kleineren Pool tatsächlicher PostgreSQL verwaltet und Hunderte von Anwendungsverbindungen über diese multiplexiert.

Für Anwendungen mit vielen gleichzeitigen Benutzern solltest du PgBouncer auf demselben Server installieren und die Anwendungen so einrichten, dass sie sich über Port 6432 mit PgBouncer verbinden. Das Pooling im Transaktionsmodus passt für die meisten Webanwendungs-Workloads; das Pooling im Sitzungsmodus ist für Anwendungen nötig, die temporäre Tabellen oder Advisory Locks verwenden.

NVMe WAL-Leistung

Die PostgreSQL hängt stark vom Schreibdurchsatz von WAL (Write-Ahead Log) ab. Jede bestätigte Transaktion schreibt einen WAL-Datensatz, bevor sie zum Client zurückkehrt. Auf NVMe dauern WAL-fsync-Operationen nur Mikrosekunden, während sie auf SATA-SSDs Millisekunden brauchen. Das verbessert direkt den Transaktionsdurchsatz bei Workloads mit vielen Schreibvorgängen.

Stell wal_compression = on ein, um das WAL-Volumen für leseintensive Workloads mit gelegentlichen großen Schreibvorgängen zu reduzieren. Für Analyse-Replikate, die Streaming-Replikation empfangen, sorgt NVMe sowohl NVMe dem Primärserver als auch NVMe dem Replikat dafür, dass die Replikationsverzögerung auch während intensiver Schreibphasen minimal bleibt.

MongoDB-Konfiguration

Größe des WiredTiger-Caches

Die WiredTiger-Speicher-Engine von MongoDB nutzt einen internen Cache, der vom Seitencache des Betriebssystems getrennt ist. Standardmäßig ist der WiredTiger-Cache auf 50 % des RAM minus 1 GB eingestellt. Bei einem System mit 192 GB sind das ungefähr 95 GB. Bei dedizierten Datenbankservern kannst du diesen Wert erhöhen:

• storage.wiredTiger.engineConfig.cacheSizeGB: 120 ( in mongod.conf für einen dedizierten Server mit 192 GB)

WiredTiger komprimiert seinen internen Cache (standardmäßig mit Snappy). Auf NVMe mit freiem CPU-Spielraum bietet die zstd-Komprimierung bessere Komprimierungsraten bei akzeptablem CPU-Overhead, wodurch die effektive E/A-Last für große Dokumentensammlungen reduziert wird.

Lese-/Schreibvorgänge und Journal-Konfiguration

Für Replikatsatzbereitstellungen auf einem einzelnen dedizierten Server, auf dem mehrere mongod-Instanzen laufen, musst du die Schreibsicherheit richtig einstellen:

• w: Mehrheit für finanzielle oder wichtige Daten (wartet, bis die Mehrheit des Replikatsatzes bestätigt hat)
• j: true aktiviert Journaling, das NVMe der Bestätigung auf NVMe schreibt; akzeptable Latenzkosten auf NVMe
• readPreference: secondaryPreferred für leseintensive Workloads verteilt die Leselast auf die Replikate

RAID-Strategie für Datenbank-Workloads

Die dedizierten Server von InMotion nutzen Software-RAID, das mit mdadm konfiguriert ist. Das ist wichtig, um die Leistungsmerkmale zu verstehen, weil sich Software-RAID auf NVMe einer modernen Multi-Core-CPU anders verhält als herkömmliche Hardware-RAID-Controller mit batteriegepuffertem Schreibcache.

RAID-Level	Nutzbare Kapazität	Leistung lesen	Schreibleistung	Anwendungsfall
RAID 0 (Stripe)	7,68 TB (voll)	2x nacheinander	2x nacheinander	Arbeitsspeicher, unwichtige Daten
RAID 1 (Spiegelung, Standard bei InMotion)	3,84 TB	Von beiden Laufwerken lesen	Schreib auf beide Laufwerke	Produktionsdatenbanken
Kein RAID (ein einzelnes Laufwerk)	3,84 TB	Volle NVMe	Volle NVMe	Replikate mit externer Sicherung lesen

Für Produktionsdatenbankserver ist RAID 1 über mdadm die richtige Standardeinstellung. Der Schreibverlust ist bei NVMe minimal NVMe beide Laufwerke sind schnell genug, dass gespiegelte Schreibvorgänge die meisten Anwendungsdurchsatzanforderungen übertreffen), und die Redundanz schützt vor einem Ausfall eines einzelnen Laufwerks, ohne dass während des Austauschzeitraums Daten verloren gehen.

RAID ist keine Backup-Strategie. Ein Softwarefehler, der das Datenverzeichnis beschädigt, ein versehentliches DROP TABLE oder Ransomware wirken sich gleichzeitig auf beide gespiegelten Laufwerke aus. Der automatisierte 500-GB-Backup-Speicher von Premier Care bietet echten Schutz vor diesen Ausfallarten.

Backup-Strategie für Produktionsdatenbanken

MySQL-Sicherung

Für MySQL-Datenbanken unter 50 GB macht das nächtliche mysqldump mit –single-transaction konsistente Backups, ohne Tabellen zu sperren. Bei größeren Datenbanken macht Percona XtraBackup physische Backups im laufenden Betrieb, die schneller wiederhergestellt werden können als SQL-Dumps. Speichere Backups auf dem 500 GB großen Backup-Volume von Premier Care, das sich außerhalb des Servers befindet.

PostgreSQL

pg_dump für kleinere Datenbanken; pg_basebackup für physische Basis-Backups größerer Instanzen. Für RPO-Anforderungen nahe Null solltest du die kontinuierliche WAL-Archivierung auf das Backup-Volume einrichten: Jedes fertige WAL-Segment wird automatisch verschickt, was eine Point-in-Time-Wiederherstellung mit einer Granularität von normalerweise 5 bis 10 Minuten ermöglicht.

MongoDB-Sicherung

mongodump macht logische Backups; bei größeren Installationen sind Snapshots auf Dateisystemebene des WiredTiger-Datenverzeichnisses (die gemacht werden, wenn die Datenbank gerade nicht benutzt wird oder an einem konsistenten Punkt ist) schneller wiederherzustellen. Bei Replikatsatz-Installationen vermeidet das Erstellen von Backups von einem sekundären Mitglied jegliche Auswirkungen auf den primären Schreibdurchsatz.

Die richtige Stufe für deinen dedizierten Server auswählen

Datenbankgröße	Gleichzeitige Verbindungen	Empfohlene Stufe	Monatliche Kosten
Unter 20 GB Arbeitsspeicher	Bis zu 100	Essential (64 GB DDR4)	99,99 $/Monat
20–50 GB Arbeitsspeicher	100–300	Fortgeschritten (64 GB DDR4, RAID-1)	149,99 $/Monat
50–140 GB Arbeitsspeicher	300–500	Elite	199,99 $/Monat
140 GB+ Arbeitsspeicher	500+	Extrem (192 GB DDR5 ECC)	349,99 $/Monat

Diese Schwellenwerte gehen davon aus, dass der Server nur für die Datenbank-Workload genutzt wird. Gemischte Server, die neben der Datenbank auch die Anwendungsschicht hosten, brauchen mehr Speicherplatz auf allen Ebenen.

Erste Schritte

• Preise für dedizierte Server: inmotionhosting .com/dedicated-servers/dedicated-server-price
• NVMe Server: inmotionhosting .nvme
• Premier Care für automatische Backups: inmotionhosting .com/blog/inmotion-premier-care/

Das APS-Team InMotion Hostingkümmert sich um die Verwaltung auf Betriebssystemebene und kann dir bei der Erstkonfiguration im Rahmen von Premier Care helfen. Die monatliche einstündige Beratung von InMotion Solutions lohnt sich für die Überprüfung der Datenbankoptimierung, vor allem wenn du eine Produktionsdatenbank von einem Shared Hosting migrierst, wo die Leistungssteigerung normalerweise ziemlich groß ist.