Databáze přepnula na repliku. Které potvrzené zápisy přežily?
Automatické přepnutí zkrátí nedostupnost databáze. Neodpoví však samo na otázku, zda nová primární instance obsahuje všechny transakce, které aplikace uživatelům potvrdila. O výsledku rozhoduje režim replikace, zpoždění, pravidla povýšení a chování aplikace po ztrátě spojení. Tato otázka patří do návrhu služby dřív, než ji položí zákazník po incidentu.
Přepnutí databáze má datovou a provozní cenu
RPO a RTO musí být skutečně domluvené
RPO určuje přípustnou ztrátu dat v čase, RTO čas návratu služby. U účetních nebo platebních toků však samotné minuty často nestačí: jedna potvrzená operace může mít větší dopad než tisíc nezávazných záznamů. Vlastník produktu proto musí určit, které události nesmějí zmizet po potvrzení, které lze znovu vyžádat a které lze smířit z externí evidence. Infrastrukturní tým pak může zvolit režim replikace podle skutečného významu dat, místo aby o něm rozhodovala výchozí hodnota databáze.
Pravidelný test obnovy by měl mít vedle technických časů i obchodní kontrolní součty: počet potvrzených objednávek, plateb a následných zpráv před a po přepnutí. Tím se odhalí chyby, které monitor dostupnosti nevidí. Záznam z cvičení patří zpět do návrhu aplikace, protože při nejasném commitu často rozhodne idempotentní zpracování a smíření, nikoli rychlost samotné databáze.
Režim replikace mění význam potvrzení
V PostgreSQL záleží na nastavení
synchronous_commit
i na tom, zda je určená synchronní replika. Bez ní vzdálené režimy čekají jen na místní disk. Záruka pro přepnutí navíc platí pouze tehdy, když novým primárním uzlem bude replika s potvrzeným záznamem WAL.
Režim
Co znamená potvrzení klientovi
Provozní kompromis
Asynchronní replikace (
local
)
WAL je trvale zapsaný na primárním uzlu; replika jej ještě mít nemusí.
Při ztrátě primárního uzlu mohou potvrzené transakce chybět.
remote_write
Synchronní replika zapsala WAL do souborového systému, ale nemusela jej ještě trvale uložit na disk.
Při ztrátě primárního uzlu a havárii operačního systému repliky může potvrzený zápis zmizet.
on
Synchronní replika potvrdila trvalé uložení WAL.
Zápis čeká na repliku; při její nedostupnosti může čekat i klient.
remote_apply
Synchronní replika WAL trvale uložila a změna je viditelná pro její dotazy.
Potvrzení čeká také na přehrání WAL, takže latence může dál vzrůst.
PROVOZNÍ PRAVIDLO
Pro každou obchodně důležitou operaci napište, co přesně smí služba potvrdit zákazníkovi a z jakého důkazu po poruše pozná její výsledek. Nastavení clusteru musí odpovídat tomuto závazku.
Při přepnutí smí zapisovat jediný primární uzel
Jiný problém vzniká při síťové izolaci. Původní primární uzel může dál pracovat, zatímco řídicí vrstva vyhodnotí ztrátu spojení jako výpadek a povýší repliku. Pokud aplikace může zapisovat do obou, vznikají dvě pravdy. PostgreSQL upozorňuje na nutnost zajistit, aby starý primární uzel po návratu nezačal znovu přijímat zápisy. Odříznutí starého uzlu, směrování klientů a pravidla návratu uzlu jsou součástí automatického přepnutí stejně jako samotný příkaz k povýšení.
Při testu proto nestačí vypnout službu databáze. Simulujte oddělení sítě, pomalou repliku, ztrátu řídicího uzlu a restart starého primárního uzlu. Změřte, kdy aplikace přestane potvrzovat zápisy, kdy začne používat novou instanci a jak ověří poslední potvrzený identifikátor transakce. Zvlášť se ptejte, co udělají fronty, cache a externí integrace, které si uložily starý stav.
PORUCHOVÝ TEST
Připravte známé identifikátory objednávek, vyvolejte ztrátu spojení i izolaci původního primárního uzlu a po přepnutí porovnejte potvrzené operace s platbami a zprávami. Zvlášť ověřte, že zápisy nepřijímaly dva uzly.
Modelový incident: platba je potvrzená, objednávka chybí
Objednávková služba zapíše transakci na primární databázi a odešle zákazníkovi potvrzení. Primární uzel se zhroutí dřív, než asynchronní replika převezme poslední záznamy. Automatizace repliku povýší a aplikace znovu přijímá požadavky. Z pohledu dostupnosti je incident krátký. Z pohledu dat však vznikla potvrzená objednávka, kterou nová databáze nezná. Pokud mezitím odešla platba do externího systému, návrat pouhým opakováním requestu může vytvořit další nekonzistenci.
Dokumentace PostgreSQL výslovně popisuje okno ztráty dat u asynchronní replikace. Synchronní potvrzení přidává silnější záruku, ale každý zápis čeká na vzdálené potvrzení a může zhoršit latenci nebo dostupnost při výpadku pohotovostní repliky. Volba proto není technická kolonka „HA zapnuto“. Je to dohoda o přípustném RPO, latenci zápisu a chování služby při nedostupnosti druhého uzlu.
POZNÁMKA Z PRAXE
Rychlý návrat databázového spojení může skrýt několik nejasných plateb. Cvičení proto uzavřete až po smíření obchodních identifikátorů, nikoli při zeleném stavu clusteru.
Starý primární uzel se nesmí jen vrátit do provozní skupiny
Po obnovení sítě může starý primární uzel obsahovat transakce, které nová primární instance nemá. Prosté připojení starého uzlu jako repliky bez posouzení rozdílu může data zahodit; povolení zápisů do obou může vytvořit rozpor. Runbook musí určit, kdo potvrdí autoritativní datovou linii, jak se zachová kopie starého uzlu pro vyšetření a kdy lze provoz znovu zjednodušit. Při automatickém přepnutí je snadné investovat do minut před povýšením a zapomenout na hodiny bezpečného návratu.
Tato fáze bývá také zkouškou komunikace. Zákaznické centrum potřebuje vědět, které požadavky mohou být nejasné, finanční tým co smiřovat a vývojáři které operace opakovat. Incident je uzavřený až po ověření konzistence obchodních záznamů, nikoli v okamžiku, kdy databázový cluster opět hlásí zdravý stav.
HRANICE DŮKAZU
Zelený stav replikace před poruchou nedokládá nulovou ztrátu potvrzených zápisů. Úspěšné povýšení repliky neprokazuje konzistenci plateb, front a externích systémů. Ta se musí ověřit na obchodních identifikátorech.
Aplikace musí znát výsledek nejasného commitu
Po přerušení spojení může klient nevědět, zda transakce prošla. Bez idempotentního identifikátoru a možnosti bezpečného dotazu na stav se slepé opakování změní v duplicitní objednávku. Pro důležité zápisy proto navrhujte stabilní business klíč, záznam výsledku a obnovu, která umí nejasné operace smířit. Databázová replikace chrání kopie dat, ale neřeší automaticky vztah k platbě, e-mailu nebo zprávě odeslané mimo její transakci.
Za užitečný výstup cvičení považuji seznam posledních potvrzených zápisů, skutečné RPO a RTO, počet nejasných operací a délku smíření s platbami i frontami. Vedení služby pak ví, co přesně znamená „přepnutí fungovalo“. Nosná teze zní: databáze je po přepnutí obnovená až tehdy, když lze doložit osud zákazníkovi potvrzených operací a bezpečně vyřešit ty nejasné.
