PostgreSQL-Wiederherstellung ohne 2.5 TB Backup

PostgreSQL-Wiederherstellung ohne Backups: Eine Fallstudie zu einem 2,5-TB-Cluster

Ein 2,5-TB-PostgreSQL-Cluster von Postgres Professional lief drei Jahre lang auf einer virtuellen Maschine ohne Backups. Die Festplatte war ohne Speicherreservierung konfiguriert und überschritt die physische Größe des Hosts, wobei sie sich via Copy-on-Write erweiterte. Zehn aktive Datenbanken, darunter 1C, stürzten nach dem Laden einer neuen Infobase ab: WAL-Protokolle füllten die Hypervisor-Festplatte, und Checkpoints konnten nicht abgeschlossen werden.

Administratoren löschten WAL-Dateien manuell und versuchten, den Postmaster im Fast-Mode zu stoppen, jedoch ohne Erfolg. Ein erzwungener Stopp via SIGKILL führte aufgrund massiver shared_buffers zu Datenkorruption. Der Start via pg_resetwal deaktivierte die WAL-Wiederherstellung; einfache Abfragen funktionierten, komplexe jedoch nicht.

Diagnose und erste Patches

Mithilfe des crash_info-Utility (verfügbar im kostenlosen Postgres Professional Build) via SIGRTMIN+6-Signal identifizierten wir einen Hang auf _bt_moveright in einem Btree-Index des Systemkatalogs. Wir aktivierten den Parameter ignore_system_indexes oder wandten einen Patch an, um Systemindizes zu umgehen. REINDEX SYSTEM wurde über Nacht nicht abgeschlossen.

pg_dump hing beim Abrufen der Tabellenliste aufgrund fehlender Indizes fest. Der Parameter --data-only half nicht: Das Utility forderte erweiterte Statistiken an. Ein Patch für pg_dump schloss unnötige Abfragen auf den Systemkatalog aus.

Datenexport und Konsequenzen

Nach 24 Stunden wurden Daten aus der Hauptdatenbank in einen neuen Cluster exportiert. Ein an die PostgreSQL-Community gesendeter Fehlerbericht mit Patch (für Versionen 13–17) hob pg_dump-Probleme mit korrupten Indizes hervor. Die Community weigerte sich, dies als Fehler zu klassifizieren: Wiederherstellung ohne Backups hat keine Priorität.

Der Kunde kaufte Enterprise-Support bei Postgres Professional. Eine Alternative zu pg_dump war COPY via einer Tabellenliste aus 1C (50.000 Tabellen in der Datenbank), generiert durch ein Skript ohne Zugriff auf den Systemkatalog.

Wichtige Administratorfehler

• Fehlen von Backups und Replikaten.
• Manuelles Löschen von WAL-Protokollen.
• Stoppen des Postmaster mit SIGKILL statt SIGQUIT.
• Ignorieren von Empfehlungen zur Speicherreservierung.
• Vertrauen auf 'Anleitungen' ohne Verifizierung der Backups.
• Falsche Wahl von pg_dump ohne Berücksichtigung von Katalogschäden.

Was zählt

• Ohne Backups (Dumps, Replikate) ist eine vollständige Wiederherstellung eines 2,5-TB-Clusters unmöglich.
• ignore_system_indexes ermöglicht das Umgehen korrupter Systemindizes.
• crash_info ist nützlich für State-Dumps ohne Konsolenzugriff.
• pg_dump ist anfällig für Katalogschäden: Nutzen Sie --data-only mit Patches oder COPY.
• Das Killen des Postmaster via SIGKILL zerstört Daten bei großen shared_buffers.

Lehren für DBAs

Ein 1C-Cluster erfordert WAL-Bereinigung, Überwachung des Festplattenspeichers und Replikation. Huge shared_buffers maskiert Probleme, bis die Katastrophe eintritt. Für 50.000 Tabellen generieren Sie COPY-Skripte aus den 1C-Metadaten.

— Editorial Team