Не, не можете да отмените, връщате назад или да отмените записване.
СПРЕТЕ БАЗАТА ДАННИ!
(Забележка:ако сте изтрили директорията с данни извън файловата система, НЕ спирайте базата данни. Следните съвети се отнасят за случайно записване на DELETE или подобен, а не rm -rf /data/directory сценарий).
Ако тези данни са били важни, СПРЕТЕ ВАШАТА БАЗА ДАННИ СЕГА и не го рестартирайте. Използвайте pg_ctl stop -m immediate така че при изключване не се изпълнява контролна точка.
Не можете да отмените транзакция, след като е била ангажирана. Ще трябва да възстановите данните от архивни копия или да използвате възстановяване в момента, което трябва да е било настроено преди инцидентът е станал.
Ако не сте настроили PITR/WAL архивиране и нямате резервни копия, имате истински проблеми.
Спешно смекчаване
След като вашата база данни бъде спряна, трябва да направите копие на ниво файлова система на цялата директория с данни - папката, която съдържа base , pg_clog , и др. Копирайте всичко на ново място. Не правете нищо с копието на новото място, това е единствената ви надежда да възстановите данните си, ако нямате резервни копия. Направете друго копие на някакво сменяемо хранилище, ако можете, и след това изключете това хранилище от компютъра. Не забравяйте, че имате нужда от абсолютно всяка част на директорията с данни, включително pg_xlog и т.н. Никоя част не е маловажна.
Как точно да направите копието зависи от коя операционна система използвате. Къде е папката с данни зависи от коя ОС използвате и как сте инсталирали PostgreSQL.
Начини, по които някои данни биха могли да оцелеят
Ако спрете вашата DB достатъчно бързо, може да имате надежда да възстановите някои данни от таблиците. Това е така, защото PostgreSQL използва многоверсионен контрол на паралелността (MVCC), за да управлява едновременния достъп до неговото хранилище. Понякога ще пише нови версии от редовете, които актуализирате в таблицата, оставяйки старите на място, но маркирани като "изтрити". След известно време идва autovaccum и маркира редовете като свободно пространство, така че те могат да бъдат презаписани с по-късен INSERT или UPDATE . По този начин старите версии на UPDATE d редове може да са все още наоколо, налични, но недостъпни.
Освен това Pg пише на две фази. Първите данни се записват в дневника за предварителна запис (WAL). Само след като бъде записан в WAL и ударен диск, след това се копира в "хийпа" (основните таблици), като евентуално се презаписват стари данни, които са били там. Съдържанието на WAL се копира в основния диск от bgwriter и чрез периодични контролни пунктове. По подразбиране контролните точки се случват на всеки 5 минути. Ако успеете да спрете базата данни преди да се е случила контролна точка и я спрете, като я убиете, издърпате щепсела на машината или използвате pg_ctl в immediate режим, в който може да сте заснели данните, преди да се случи контролната точка, така че е по-вероятно старите ви данни все още да са в купчината.
Сега, когато сте направили пълно копие на ниво файлова система на директорията с данни, можете да стартирате резервно копие на вашата база данни, ако наистина трябва; данните все още ще изчезнат, но вие сте направили всичко възможно, за да си дадете някаква надежда може би да ги възстановите. Като се има предвид изборът, вероятно бих оставил БД затворен, само за да съм в безопасност.
Възстановяване
Сега може да се наложи да наемете експерт по вътрешностите на PostgreSQL, който да ви помогне при опит за възстановяване на данни. Бъдете готови да платите на професионалист за отделеното време, вероятно доста време.
Публикувах за това в пощенския списък на Pg и Виктор Егоров направи връзка към публикацията на depesz в pg_dirtyread, която изглежда точно това, което искате, макар че не се възстановява TOAST ed данни, така че е с ограничена полезност. Опитайте, ако имате късмет, може да проработи.
Вижте:pg_dirtyread на GitHub.
Премахнах това, което бях написал в този раздел, тъй като е остаряло от този инструмент.
Вижте също основите за съхранение на редове в PostgreSQL
Превенция
Вижте записа в моя блог Предотвратяване на повреда на PostgreSQL база данни.
От друга страна, ако сте използвали двуфазен комит, можете да ROLLBACK PREPARED за транзакция, която е била подготвена за извършване, но не е напълно ангажирана. Това е най-близо до отмяната на вече ангажирана транзакция и не се отнася за вашата ситуация.
