PostgreSQL-Architektur für Gaming-Netzwerke: Connection-Pooling und Point-in-Time-Recovery

In verteilten Minecraft-Netzwerken greifen dutzende Server-Instanzen (Lobbys, Citybuild, Minigames) gleichzeitig auf gemeinsame Datensätze zu: Spielerprofile, Berechtigungen (LuckPerms), Wirtschaftsguthaben, Ticket-Verläufe und Strafregister. Eine unzuverlässige Datenbankanbindung führt zu quälenden Login-Verzögerungen oder fatalen Duplizierungs-Glizzen.

In diesem Architektur-Leitfaden behandeln wir die Dimensionierung von Connection-Pools mit HikariCP und PgBouncer, transaktionale Integrität und unterbrechungsfreie Backup-Strategien mit Point-in-Time-Recovery (PITR).

1. Die Physik des Connection-Poolings: HikariCP richtig berechnen

Viele Server-Administratoren stellen in ihren Plugin-Konfigurationen (z. B. luckperms.conf oder coreprotect.properties) blind Werte wie maximumPoolSize: 50 ein. Wenn 10 Unterserver jeweils 50 Verbindungen öffnen, schlagen 500 aktive PostgreSQL-Backend-Prozesse auf dem Datenbank-Host auf.

PostgreSQL nutzt ein prozessbasiertes Modell (Fork), bei dem jede Verbindung eigenen virtuellen Speicher alloziiert und mit anderen Prozessen um CPU-Kerne und Festplatten-I/O konkurriert.

Die offizielle Berechnungsformel für HikariCP lautet:

$$\text{Pool-Größe} = (\text{CPU-Kerne} \times 2) + \text{Spindelanzahl}$$

Bei einem dedizierten Datenbankserver mit 8 CPU-Kernen und NVMe-Speicher (effektive Spindelanzahl = 1 bei wahlfreiem I/O) ergibt dies:

$$\text{Optimale Gesamtzahl} = (8 \times 2) + 1 = 17 \text{ aktive Verbindungen}$$

Ein Pool von 10 bis 16 Verbindungen bedient Anfragen schneller als ein überdimensionierter Pool von 100 Verbindungen, da CPU-Kontextwechsel minimiert werden:

# Empfohlene HikariCP-Einstellung für Minecraft-Plugins
data-source-properties {
  maximumPoolSize: 10
  minimumIdle: 5
  idleTimeout: 600000
  maxLifetime: 1800000
  connectionTimeout: 5000
  leakDetectionThreshold: 10000
}

2. PgBouncer als vorgeschalteter Transaktions-Multiplexer

Skaliert das Netzwerk auf mehr als 20 Minecraft-Server, stößt selbst die strikte Begrenzung an Grenzen. Die Lösung ist PgBouncer, ein leichtgewichtiger Connection-Pooler, der im Transaction-Pooling-Modus arbeitet:

# /etc/pgbouncer/pgbouncer.ini
[databases]
kirocloud = host=127.0.0.1 port=5432 dbname=kirocloud

[pgbouncer]
listen_port = 6432
listen_addr = 127.0.0.1
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 25
reserve_pool_size = 5
reserve_pool_timeout = 5

Im transaction-Modus hält PgBouncer lediglich 25 echte Serververbindungen zu PostgreSQL offen, bedient darüber jedoch hunderte Client-Verbindungen. Sobald eine Transaktion mit COMMIT oder ROLLBACK abschließt, wird die Verbindung sofort für den nächsten wartenden Minecraft-Server freigegeben.

3. Schutz vor Race Conditions: Transaktionen und Row-Level Locking

Bei serverübergreifenden Spielertransaktionen (z. B. Überweisung von Ingame-Geld) kommt es ohne striktes Locking zu Duplizierungs-Fehlern, wenn der Spieler gleichzeitig auf Server A und Server B Aktionen auslöst:

-- Sicherer Überweisungsvorgang mit Row-Level Lock
BEGIN;

-- Zeile sperren, bis Transaktion beendet ist
SELECT balance FROM player_economy WHERE uuid = '3a6b8c9d-...' FOR UPDATE;

-- Guthaben prüfen und abbuchen
UPDATE player_economy 
SET balance = balance - 500 
WHERE uuid = '3a6b8c9d-...' AND balance >= 500;

-- Empfänger gutschreiben
UPDATE player_economy 
SET balance = balance + 500 
WHERE uuid = '7e8f9a0b-...';

COMMIT;

Durch das FOR UPDATE-Schlüsselwort blockiert PostgreSQL jede konkurrierende Transaktion auf diesem spezifischen Datensatz, bis die aktuelle Operation vollständig abgeschlossen ist.

4. Index-Optimierung für Audit-Logs und Spielerevents

Tabellen wie audit_logs oder player_transactions wachsen in aktiven Netzwerken rasch auf Millionen von Datensätzen an. Herkömmliche B-Tree-Indizes auf Zeitstempeln (created_at) belegen viel Speicher und belasten Schreiboperationen.

Für sequenziell geschriebene Logdaten empfiehlt sich ein BRIN-Index (Block Range Index):

-- BRIN-Index für append-only Zeitreihendaten
CREATE INDEX idx_audit_logs_created_at_brin 
ON audit_logs USING brin (created_at) 
WITH (pages_per_range = 32);

Ein BRIN-Index speichert lediglich Minimal- und Maximalwerte zusammenhängender Speicherblöcke. Dadurch ist er bis zu 95 % kleiner als ein B-Tree-Index und hält Abfragen nach Zeiträumen dennoch hochgradig performant.

5. Unterbrechungsfreie Backups mit pgBackRest & WAL-Archivierung

Reguläre SQL-Dumps (pg_dump) belasten die Datenbank während des Exports und hinterlassen bei Datenverlust eine Lücke zwischen dem letzten Dump und dem Crash. Für Produktivsysteme ist Point-in-Time-Recovery (PITR) unverzichtbar.

Konfiguration der WAL-Archivierung in postgresql.conf

# /etc/postgresql/16/main/postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'pgbackrest --stanza=kiro-db archive-push %p'
max_wal_senders = 5

pgBackRest-Konfiguration

# /etc/pgbackrest/pgbackrest.conf
[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
repo1-retention-diff=7
process-max=4
log-level-console=info
start-fast=y
compress-type=zst
compress-level=3

[kiro-db]
pg1-path=/var/lib/postgresql/16/main
pg1-user=postgres

Mit dieser Architektur werden wöchentlich vollwertige Basis-Backups und täglich differentielle Schnappschüsse erstellt. Jedes abgeschlossene Transaktionsprotokoll (WAL) wird binnen Sekunden zstandard-komprimiert ins Archiv geschoben.

6. Das Notfall-Szenario: Point-in-Time Wiederherstellung

Tritt um 14:32:10 Uhr ein schwerwiegender Exploit oder Datenkorruptionsfall auf, lässt sich der Datenbestand exakt auf den Zustand um 14:31:00 Uhr zurückrollen:

# PostgreSQL stoppen
systemctl stop postgresql

# Wiederherstellung bis zu einem definierten Zeitpunkt starten
pgbackrest --stanza=kiro-db \
  --type=time \
  "--target=2026-11-08 14:31:00" \
  --target-action=promote \
  restore

# PostgreSQL mit konsistentem Datenstand neu starten
systemctl start postgresql

Das System spielt automatisch das letzte physische Backup ein und wendet exakt die WAL-Logs bis zur Zielsekunde an. Es gehen keinerlei Daten aus dem regulären Spielbetrieb vor dem Vorfall verloren.