Databázová replika nenahrádza zálohu. Ako sa vrátiť pred chybnú zmenu?

Replika preberá aj zmenu, ktorú ste nechceli

Fyzický standby priebežne prehráva WAL, teda záznamy zmien prijaté z primárneho servera. Ak sa do nich dostane potvrdené zmazanie, replika po prehratí príslušných záznamov prevezme aj jeho výsledok. Nízke oneskorenie preto nedokazuje ochranu pred takouto chybou. Znamená malý odstup od stavu, ktorý môže byť práve neželaný.

Pri incidente najprv určte, či riešite výpadok stroja alebo chybný obsah dát. Ak už replika zmenu prevzala, samotné prepnutie klientov na ňu staré záznamy nevráti. Uložte časovú os, identifikáciu operácie a dostupné dôkazy. O ďalších zápisoch rozhodnite podľa dopadu na službu; automatické prepínanie serverov nemá nahradiť toto posúdenie.

Na návrat v čase potrebujete pripravenú históriu

Point-in-time recovery, skrátene PITR, potrebuje vhodnú fyzickú základnú zálohu a súvislú sekvenciu WAL od jej začiatku po cieľ. Záloha musí byť pre zvolený bod už dokončená. pg_basebackup vie vytvoriť základnú zálohu bežiaceho clustra. Odlíšte ju od pg_dump, ktorý predstavuje logický snímok databázy. Formát zálohy a postup obnovy overte vopred.

V pg_stat_archiver sledujte failed_count a last_archived_time. Posledná úspešná archivácia sama nepotvrdzuje úplnosť všetkých starších segmentov. Archivačný mechanizmus pracuje s dokončenými WAL segmentmi, preto pri menšom objeme zápisov zohľadnite oneskorenie ich odoslania. Retenciu záloh a WAL posudzujte spolu. Overte, že potrebné súbory aj prístupy zostanú dostupné počas celého dohodnutého obdobia obnovy.

Cieľ obnovy najprv overte mimo produkcie

Zvoľte bod pred neželanou potvrdenou transakciou. Pri recovery_target_time použite jednoznačné časové pásmo, napríklad číselný posun od UTC. recovery_target_inclusive určuje aj zahrnutie transakcií s presne cieľovým časom potvrdenia. Čas poslednej úpravy zobrazený v aplikácii preto nepoužívajte automaticky ako overený cieľ. Výber potvrďte skúšobnou obnovou a kontrolou dotknutých záznamov.

PITR touto cestou obnovuje celý databázový cluster, nie samostatnú tabuľku. Obnovenú kópiu spustite v oddelenom prostredí s kontrolovaným prístupom a vypnutými odchádzajúcimi integráciami. Porovnajte stav pred neželanou zmenou aj správne operácie, ktoré nastali neskôr. Úplný návrat produkcie do minulosti by vyradil aj tieto neskoršie zmeny; spôsob návratu dát musí zohľadniť ich význam a väzby.

Úspech merajte správnymi dátami a funkciou služby

pg_verifybackup kontroluje integritu podporovanej fyzickej zálohy oproti backup_manifest. Dokumentácia výslovne upozorňuje, že nenahrádza skúšobnú obnovu a overenie dát. Zaznamenajte použitú zálohu, dosiahnutý bod a výsledok kontroly. Samotný úspešný štart databázy ani zelený stav replikácie nepotvrdzuje, že ste získali požadovanú verziu záznamov.

V bezpečnej skúške pripravte známy stav, vykonajte riadenú testovaciu zmenu a obnovte kópiu pred ňu. Overte konkrétne záznamy, väzby a príslušnú funkciu aplikácie. Zmerajte celý postup vrátane získania súborov a prístupov. Po zmene zálohovacieho nástroja alebo retencie skúšku zopakujte. Replika aj záloha potom budú mať overenú úlohu v dvoch odlišných scenároch.

• Rozlíšte výpadok servera od nechcenej zmeny dát.
• Overte vhodnú základnú zálohu a súvislú históriu WAL.
• V oddelenej kópii potvrďte správny bod aj obsah obnovy.
• Naplánujte návrat dát so zachovaním správnych neskorších zmien.