Postgres Autovacuum, entmystifiziert — das Tuning, das die 3-Uhr-Wraparound-Panik verhindert

Transaction-ID-Wraparound steht oben auf meiner Liste von Postgres-Fehlermodi, die mich persönlich Schlaf gekostet haben. Der Morgen ist immer derselbe: Die Postgres eines Kunden ist um 2 Uhr read-only gegangen, jeder Write mit „database is not accepting commands to avoid wraparound data loss" abgewiesen, und der einzige Weg ist ein VACUUM FREEZE gegen eine 300-GB-Tabelle, das sechs Stunden dauern wird.

Autovacuum existiert seit 2005. Die Defaults sind auf „kleine DB, kleiner Server" zugeschnitten und sind bei jeder nennenswert großen Datenbank auf vorhersehbare Weise falsch.

Per-Tabelle-Tuning für große, churn-intensive Tabellen

ALTER TABLE orders SET (
  autovacuum_vacuum_scale_factor = 0.02,
  autovacuum_vacuum_threshold = 1000,
  autovacuum_analyze_scale_factor = 0.01,
  autovacuum_freeze_max_age = 100000000,
  autovacuum_vacuum_cost_limit = 2000
);

Jede Tabelle über 10 GB oder 10 Mio. Zeilen bekommt Per-Tabelle-Tuning. Die Defaults von 20 % Scale Factor und 200 Mio. XID-Age machen Autovacuums bei großen Tabellen zu selten und zu groß.

Der vollständige Beitrag behandelt:

• Was Autovacuum tatsächlich tut (Dead-Tuple-Cleanup vs XID-Freezing)
• Die drei zu beobachtenden Metriken (dead_ratio, last_autovacuum, xid_age)
• Warum das Default-autovacuum_vacuum_cost_limit = 200 auf SSDs lächerlich niedrig ist
• Proaktives Einfrieren, um Anti-Wraparound-Autovacuums während der Geschäftszeiten zu verhindern
• Index-Bloat und REINDEX CONCURRENTLY nach Zeitplan
• pg_repack für Tabellen, die Plattenspeicher an das OS zurückgeben müssen

Wir liefern dieses Baseline auf jeder gemanagten Postgres-Datenbank aus.