Nie, nie możesz cofnąć, wycofać ani cofnąć zatwierdzenia.
ZATRZYMAJ BAZĘ DANYCH!
(Uwaga:jeśli usunąłeś katalog danych z systemu plików, NIE zatrzymuj bazy danych. Poniższa rada dotyczy przypadkowego zatwierdzenia DELETE lub podobny, a nie rm -rf /data/directory scenariusz).
Jeśli te dane były ważne, ZATRZYMAJ SWOJĄ BAZĘ DANYCH TERAZ i nie uruchamiaj go ponownie. Użyj pg_ctl stop -m immediate aby żaden punkt kontrolny nie był uruchamiany przy wyłączaniu.
Nie można wycofać transakcji, która została już zatwierdzona. Konieczne będzie przywrócenie danych z kopii zapasowych lub skorzystanie z odzyskiwania do określonego momentu, które musi być skonfigurowane przed wypadek się wydarzył.
Jeśli nie masz skonfigurowanej archiwizacji PITR / WAL i nie masz kopii zapasowych, masz poważne kłopoty.
Pilne łagodzenie
Po zatrzymaniu bazy danych należy wykonać kopię całego katalogu danych na poziomie systemu plików — folderu zawierającego base , pg_clog itp. Skopiuj wszystkie do nowej lokalizacji. Nie rób nic z kopią w nowej lokalizacji, to jedyna nadzieja na odzyskanie danych, jeśli nie masz kopii zapasowych. Jeśli to możliwe, utwórz kolejną kopię na jakimś nośniku wymiennym, a następnie odłącz ten nośnik od komputera. Pamiętaj, że potrzebujesz absolutnie każdej części katalogu danych, w tym pg_xlog itp. Żadna część nie jest nieważna.
Dokładny sposób wykonania kopii zależy od używanego systemu operacyjnego. Miejsce, w którym znajduje się katalog danych, zależy od używanego systemu operacyjnego i sposobu instalacji PostgreSQL.
Sposoby, w jakie niektóre dane mogły przetrwać
Jeśli zatrzymasz bazę danych wystarczająco szybko, możesz mieć nadzieję na odzyskanie niektórych danych z tabel. Dzieje się tak, ponieważ PostgreSQL wykorzystuje kontrolę współbieżności wielu wersji (MVCC) do zarządzania równoczesnym dostępem do swojej pamięci. Czasami napisze nowe wersje wierszy aktualizowanych do tabeli, pozostawiając stare na miejscu, ale oznaczone jako „usunięte”. Po chwili pojawia się autovaccum i oznacza wiersze jako wolne miejsce, aby można je było nadpisać przez późniejsze INSERT lub UPDATE . Tak więc stare wersje UPDATE d rzędów może nadal leżeć, obecne, ale niedostępne.
Dodatkowo Pg pisze w dwóch fazach. Pierwsze dane są zapisywane w dzienniku zapisu z wyprzedzeniem (WAL). Dopiero po zapisaniu na WAL i trafieniu na dysk jest następnie kopiowany na „stertę” (główne tabele), prawdopodobnie nadpisując stare dane, które tam były. Zawartość WAL jest kopiowana do głównej sterty przez bgwriter oraz przez okresowe punkty kontrolne. Domyślnie punkty kontrolne pojawiają się co 5 minut. Jeśli zdołasz zatrzymać bazę danych przed wystąpieniem punktu kontrolnego i zatrzymasz go, zatrzymując go, wyciągając wtyczkę na maszynie lub używając pg_ctl w immediate mogłeś przechwycić dane sprzed wystąpienia punktu kontrolnego, więc jest większe prawdopodobieństwo, że stare dane nadal będą znajdować się na stercie.
Teraz, po wykonaniu kompletnej kopii katalogu danych na poziomie systemu plików, możesz rozpocząć tworzenie kopii zapasowej bazy danych, jeśli naprawdę tego potrzebujesz; dane nadal znikną, ale zrobiłeś wszystko, co w Twojej mocy, aby mieć nadzieję na ich odzyskanie. Mając wybór, prawdopodobnie zatrzymałbym DB, aby być bezpiecznym.
Odzyskiwanie
Być może będziesz musiał teraz zatrudnić eksperta od wnętrzności PostgreSQL, który pomoże Ci w próbie odzyskania danych. Przygotuj się na zapłacenie profesjonalistom za ich czas, być może sporo czasu.
Napisałem o tym na liście dyskusyjnej Pg, a Виктор Егоров połączył się z postem depesz na pg_dirtyread, który wygląda dokładnie tak, jak chcesz, chociaż nie przywraca TOAST ed danych, więc ma ograniczoną użyteczność. Spróbuj, jeśli masz szczęście, może się udać.
Zobacz:pg_dirtyread na GitHub.
Usunąłem to, co napisałem w tej sekcji, ponieważ jest przestarzałe przez to narzędzie.
Zobacz także Podstawy przechowywania wierszy PostgreSQL
Zapobieganie
Zobacz mój wpis na blogu Zapobieganie uszkodzeniom bazy danych PostgreSQL.
Na marginesie, jeśli używałeś zatwierdzania dwufazowego, możesz ROLLBACK PREPARED dla transakcji przygotowanej do zatwierdzenia, ale nie w pełni zrealizowanej. Jest to najbliższe wycofaniu już dokonanej transakcji i nie dotyczy Twojej sytuacji.
