Database Foundation Stack: Production Tuning für PostgreSQL und Redis

Warum ein Database Foundation Stack

Die meisten Anwendungen beginnen mit einer einzigen PostgreSQL-Instanz und einer Standard-Redis-Konfiguration. Das funktioniert so lange, bis es nicht mehr funktioniert – Connection-Pool-Erschöpfung, stiller Datenverlust bei einem Redis-Neustart, beschädigte Datenbankdateien oder ein DROP TABLE ohne Backup zur Wiederherstellung.

Ein Production Database Foundation Stack behebt diese Fehlermodi, bevor sie auftreten. Es sind dieselben Postgres- und Redis-Instanzen, die Sie bereits verwenden, aber auf Resilienz statt auf Bequemlichkeit konfiguriert.

Architektur

PostgreSQL-Konfiguration

Memory Tuning

Die Performance von PostgreSQL wird maßgeblich durch die Speicherkonfiguration bestimmt. Diese Einstellungen setzen 4 GB RAM voraus, die dem Container zugewiesen wurden:

shared_buffers = '1GB'
effective_cache_size = '3GB'
maintenance_work_mem = '256MB'
work_mem = '32MB'
wal_buffers = '16MB'

Faustregel:

• shared_buffers = 25 % des verfügbaren RAMs
• effective_cache_size = 75 % des verfügbaren RAMs
• maintenance_work_mem = 5 % des verfügbaren RAMs (für VACUUM, CREATE INDEX)
• work_mem = Gesamt-RAM / (max_connections × 16) — unter 64 MB halten

Connection Pooling

Der Docker Compose Stack stellt PostgreSQL auf dem Standardport (5432) bereit. Für Produktions-Workloads mit mehr als 20 gleichzeitigen Verbindungen sollte PgBouncer als Sidecar hinzugefügt werden:

pgbouncer:
  image: edoburu/pgbouncer:latest
  environment:
    DB_USER: app
    DB_PASSWORD: "${POSTGRES_PASSWORD}"
    DB_HOST: postgres
    DB_PORT: "5432"
    POOL_MODE: transaction
    DEFAULT_POOL_SIZE: 25
    MAX_CLIENT_CONN: 100

PgBouncer im transaction-Modus verwendet Verbindungen zwischen Abfragen wieder, sodass 100 Anwendungsverbindungen sich 25 Datenbankverbindungen teilen können.

Automatisiertes Backup

Das Backup-System nutzt drei Strategien parallel:

1. Täglicher pg_dump (logisches Backup)

PGPASSWORD="${POSTGRES_PASSWORD}" pg_dump \
  -h postgres -U "${POSTGRES_USER}" -d "${POSTGRES_DB}" \
  --format=custom \
  --compress=9 \
  --file="/backups/daily/$(date +%Y%m%d).dump"

Das benutzerdefinierte Format (.dump) ermöglicht eine parallele Wiederherstellung mit pg_restore -j 4.

2. Kontinuierliches WAL-Archivierung (Point-in-Time Recovery)

archive_mode = on
archive_command = 'cp %p /wal_archive/%f'

Die WAL-Archivierung ermöglicht die Wiederherstellung zu jedem beliebigen Zeitpunkt, nicht nur zu den Zeitpunkten der Backup-Snapshots.

3. S3-Sync für externe Speicherung

aws s3 sync /backups s3://your-backup-bucket/postgres/ \
  --storage-class STANDARD_IA

Alle drei sind im backup-agent-Container des Stacks enthalten.

Redis-Konfiguration

Persistenzmodus

Redis bietet zwei Persistenzmechanismen. In Produktionsumgebungen werden beide verwendet:

Feature	RDB (Snapshot)	AOF (Append-Only)
Was	Point-in-Time-Dump des Datensatzes	Log jeder Schreiboperation
Recovery-Speed	Schnell	Langsamer (spielt Log ab)
Datenverlust-Fenster	Letztes Snapshot-Intervall	Letzte Sekunde (mit always)
Dateigröße	Kleiner	Größer

Der Stack konfiguriert:

# RDB every 5 minutes if at least 100 keys changed
save 300 100
save 60 1000

# AOF — fsync every second (balance of safety and performance)
appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Diese Kombination stellt sicher, dass bei einem Absturz maximal eine Sekunde an Daten verloren geht (AOF) und eine schnelle Wiederherstellung für große Datensätze gewährleistet ist (RDB).

Speicherverwaltung

Redis ist ein In-Memory-Store. Legen Sie eine maxmemory-Policy fest, um unbegrenztes Wachstum zu verhindern:

maxmemory 512mb
maxmemory-policy allkeys-lru

allkeys-lru evicts the least recently used keys when memory limit is hit. For caching workloads this is ideal. For queue data (Bull/BullMQ), use noeviction and monitor explicitly.

Recovery Procedures

Restore PostgreSQL from pg_dump

pg_restore -h new-host -U postgres -d appdb \
  --clean --if-exists \
  --jobs=4 \
  /backups/daily/20260525.dump

Point-in-Time Recovery (WAL)

# 1. Basis-Backup wiederherstellen
pg_restore ... /backups/daily/20260524.dump

# 2. WAL bis zum Zielzeitpunkt anwenden
# In postgres.conf setzen:
restore_command = 'cp /wal_archive/%f %p'
recovery_target_time = '2026-05-25 14:30:00 UTC'

Restore Redis from RDB + AOF

# Redis stoppen, dump.rdb und appendonly.aof ersetzen, neu starten
docker compose stop redis
cp /backups/redis/dump.rdb /data/dump.rdb
cp /backups/redis/appendonly.aof /data/appendonly.aof
docker compose start redis

Production-Checkliste

• shared_buffers und work_mem an den RAM Ihrer VM anpassen
• max_connections setzen, um Connection Leaks der App zu verhindern (Standard: 100)
• archive_mode und archive_command für das WAL-Archivieren konfigurieren
• Redis maxmemory und maxmemory-policy festlegen
• Restore-Prozess testen — ungetestete Backups sind keine Backups
• Replication Lag überwachen, falls Read Replicas hinzugefügt werden
• pg_stat_statements für die Analyse der Query-Performance einrichten

Wichtige Erkenntnisse

• Die Standard-Postgres-Konfiguration ist für Laptops optimiert, nicht für die Produktion — passen Sie immer shared_buffers, work_mem und effective_cache_size an
• Redis ohne AOF verliert Daten — aktivieren Sie in der Produktion immer appendonly yes
• WAL-Archivierung ermöglicht PITR — ohne diese Funktion können Sie nur zum Zeitpunkt des Backup-Snapshots wiederherstellen
• Testen Sie Ihre Backups — ein Backup, das noch nie wiederhergestellt wurde, ist ein Backup, das nicht funktioniert