Ne, odevzdání nelze vrátit zpět, vrátit zpět nebo vrátit zpět.
ZASTAVTE DATABÁZI!
(Poznámka:pokud jste vymazali datový adresář ze souborového systému, NEZASTAVUJTE databázi. Následující rada platí pro náhodné odevzdání DELETE nebo podobný, nikoli rm -rf /data/directory scénář).
Pokud byla tato data důležitá, ZASTAVTE SVOU DATABÁZI NYNÍ a nerestartujte jej. Použijte pg_ctl stop -m immediate takže při vypnutí nebude spuštěn žádný kontrolní bod.
Jakmile je transakce potvrzena, nelze ji vrátit zpět. Budete muset obnovit data ze záloh nebo použít obnovení v určitém okamžiku, které musí být nastaveno před k nehodě došlo.
Pokud jste neměli nastavenou archivaci PITR / WAL a nemáte zálohy, máte skutečný problém.
Naléhavé zmírnění
Jakmile je databáze zastavena, měli byste vytvořit kopii celého datového adresáře na úrovni systému souborů – složku, která obsahuje base , pg_clog atd. Zkopírujte vše na nové místo. S kopií v novém umístění nic nedělejte, je to vaše jediná naděje na obnovu dat, pokud nemáte zálohy. Pokud je to možné, vytvořte další kopii na nějakém vyměnitelném úložišti a poté toto úložiště odpojte od počítače. Pamatujte, že potřebujete naprosto každý díl datového adresáře, včetně pg_xlog atd. Žádná část není nedůležitá.
Jak přesně vytvořit kopii závisí na operačním systému, který používáte. Kde je datový adresář, závisí na tom, jaký OS používáte a jak jste PostgreSQL nainstalovali.
Způsoby, jak mohla některá data přežít
Pokud zastavíte svou DB dostatečně rychle, můžete mít naději na obnovení některých dat z tabulek. Je to proto, že PostgreSQL používá řízení souběžnosti více verzí (MVCC) ke správě souběžného přístupu ke svému úložišti. Někdy napíše nové verze řádků, které aktualizujete do tabulky, přičemž staré ponecháte na místě, ale budou označeny jako „smazané“. Po chvíli přijde autovaccum a označí řádky jako volné místo, takže je lze přepsat pozdějším INSERT nebo UPDATE . Tedy staré verze UPDATE d řádků může stále ležet, jsou přítomné, ale nepřístupné.
Pg navíc zapisuje ve dvou fázích. První data jsou zapsána do protokolu WAL (write-ahead). Pouze jakmile je zapsáno do WAL a zasaženo na disk, je pak zkopírováno do "hromady" (hlavních tabulek), přičemž možná přepíše stará data, která tam byla. Obsah WAL je zkopírován do hlavní haldy pomocí bgwriter a pravidelnými kontrolními body. Ve výchozím nastavení se kontrolní body konají každých 5 minut. Pokud se vám podaří zastavit databázi dříve, než dojde ke kontrolnímu bodu a zastavíte ji tvrdým zabitím, vytažením zástrčky do počítače nebo použitím pg_ctl immediate režimu, ze kterého jste možná získali data předtím, než došlo ke kontrolnímu bodu, takže vaše stará data budou pravděpodobně stále na hromadě.
Nyní, když jste vytvořili úplnou kopii datového adresáře na úrovni souborového systému, můžete spustit zálohování databáze, pokud to opravdu potřebujete; data budou stále pryč, ale udělali jste, co jste mohli, abyste si dali nějakou naději, že je možná obnovíte. Vzhledem k této volbě bych pravděpodobně nechal DB vypnout, abych byl v bezpečí.
Obnovení
Možná budete muset najmout odborníka na vnitřnosti PostgreSQL, který vám pomůže s pokusem o obnovu dat. Buďte připraveni zaplatit profesionálovi za jeho čas, možná docela dost času.
Psal jsem o tom na mailing listu Pg a Виктор Егоров se spojil s depeszovým příspěvkem na pg_dirtyread, který vypadá jako přesně to, co chcete, i když se neobnoví TOAST ed data, takže má omezenou použitelnost. Zkuste to, pokud budete mít štěstí, může to fungovat.
Viz:pg_dirtyread na GitHubu.
Odstranil jsem to, co jsem napsal v této sekci, protože je to tímto nástrojem zastaralé.
Viz také Základy úložiště řádků PostgreSQL
Prevence
Viz můj blogový záznam Prevence poškození databáze PostgreSQL.
Na druhou stranu, pokud jste používali dvoufázové potvrzení, mohli byste ROLLBACK PREPARED pro transakci, která byla připravena k potvrzení, ale nebyla plně potvrzena. To je asi nejblíže, jak se můžete vrátit zpět k již provedené transakci, a nevztahuje se na vaši situaci.