Obnovení PostgreSQL bez zálohy 2.5 TB

Obnova PostgreSQL bez záloh: případová studie clusteru 2,5 TB

Cluster PostgreSQL od společnosti Postgres Professional o velikosti 2,5 TB běžel tři roky na virtuálním stroji bez zálohování. Disk bez rezervace prostoru překročil fyzickou velikost hostitele a rostl podle principu copy-on-write. Deset aktivních databází, včetně 1C, se zhroutilo po načtení nové informační báze: WAL logy zaplnily disk hypervizoru, kontrolní body se nedokončily.

Administrátoři ručně smazali WAL, pokusili se zastavit postmaster v režimu fast, ale neúspěšně. Vynucené zastavení SIGKILL vedlo k poškození dat kvůli obrovským shared_buffers. Spuštění přes pg_resetwal vypnulo obnovu WAL, ale jednoduché dotazy fungovaly, složité ne.

Diagnostika a první patche

Pomocí utility crash_info (dostupné v bezplatné sestavení Postgres Professional) po signálu SIGRTMIN+6 odhalili zaseknutí na _bt_moveright v btree-indexu systémového katalogu. Zapnuli parametr ignore_system_indexes nebo aplikovali patch pro obejití systémových indexů. REINDEX SYSTEM se nedokončila přes noc.

pg_dump zasekl při získávání seznamu tabulek kvůli chybějícím indexům. Parametr --data-only nepomohl: utilita požadovala rozšířenou statistiku. Patch pro pg_dump vyloučil zbytečné dotazy do systémového katalogu.

Export dat a důsledky

Během jednoho dne byla exportována data klíčové databáze do nového clusteru. Bugreport v komunitě PostgreSQL s patchem (pro verze 13–17) upozornil na problémy pg_dump při poškozených indexech. Komunita odmítla považovat toto za bug: bez záloh není obnova prioritou.

Klient zakoupil enterprise podporu Postgres Professional. Alternativa k pg_dump — COPY podle seznamu tabulek z 1C (50 000 tabulek v databázi), generovaného skriptem, bez přístupu k systémovému katalogu.

Klíčové chyby administrátorů

• Chybějící zálohy a repliky.
• Ruční mazání WAL.
• Zastavení postmaster SIGKILL místo SIGQUIT.
• Ignorování doporučení pro rezervaci disku.
• Spoléhání se na 'příručky' bez ověření záloh.
• Špatná volba pg_dump bez zohlednění poškození katalogu.

Co je důležité

• Bez záloh (dumpů, replik) není úplná obnova clusteru 2,5 TB možná.
• ignore_system_indexes umožňuje obejít poškozené systémové indexy.
• crash_info je užitečná pro dumpy stavu bez přístupu ke konzoli.
• pg_dump je zranitelný vůči poškození katalogu: použijte --data-only s patchi nebo COPY.
• SIGKILL postmaster ničí data při velkých shared_buffers.

Lekce pro DBA

Cluster na 1C vyžaduje čištění WAL, monitoring diskového prostoru a replikaci. Obrovské shared_buffers maskují problémy až do katastrofy. Pro 50 000 tabulek generujte COPY skripty z metadat 1C.

— Editorial Team