Nein, Sie können einen Commit nicht rückgängig machen, rückgängig machen oder rückgängig machen.
DATENBANK STOPPEN!
(Hinweis:Wenn Sie das Datenverzeichnis aus dem Dateisystem gelöscht haben, halten Sie die Datenbank NICHT an. Der folgende Rat gilt für ein versehentliches Festschreiben eines DELETE oder ähnliches, kein rm -rf /data/directory Szenario).
Wenn diese Daten wichtig waren, HALTEN SIE IHRE DATENBANK JETZT und nicht neu starten. Verwenden Sie pg_ctl stop -m immediate damit beim Herunterfahren kein Prüfpunkt ausgeführt wird.
Sie können eine Transaktion nicht rückgängig machen, nachdem sie festgeschrieben wurde. Sie müssen die Daten aus Sicherungen wiederherstellen oder die Point-in-Time-Wiederherstellung verwenden, die vorher eingerichtet worden sein muss der Unfall ist passiert.
Wenn Sie keine PITR/WAL-Archivierung eingerichtet haben und keine Backups haben, haben Sie echte Probleme.
Dringende Minderung
Sobald Ihre Datenbank gestoppt ist, sollten Sie eine Kopie des gesamten Datenverzeichnisses auf Dateisystemebene erstellen - des Ordners, der base enthält , pg_clog usw. Kopieren Sie alles an einen neuen Standort. Machen Sie nichts mit der Kopie am neuen Speicherort, es ist Ihre einzige Hoffnung, Ihre Daten wiederherzustellen, wenn Sie keine Backups haben. Erstellen Sie eine weitere Kopie auf einem Wechseldatenträger, wenn Sie können, und trennen Sie diesen Speicher dann vom Computer. Denken Sie daran, dass Sie absolut jedes Teil benötigen des Datenverzeichnisses, einschließlich pg_xlog etc. Kein Teil ist unwichtig.
Wie genau die Kopie erstellt wird, hängt davon ab, welches Betriebssystem Sie verwenden. Wo sich das Datenverzeichnis befindet, hängt davon ab, welches Betriebssystem Sie verwenden und wie Sie PostgreSQL installiert haben.
Wie einige Daten überlebt haben könnten
Wenn Sie Ihre DB schnell genug stoppen, haben Sie vielleicht die Hoffnung, einige Daten aus den Tabellen wiederherzustellen. Das liegt daran, dass PostgreSQL Multi-Version Concurrency Control (MVCC) verwendet, um den gleichzeitigen Zugriff auf seinen Speicher zu verwalten. Manchmal schreibt es neue Versionen der Zeilen, die Sie in der Tabelle aktualisieren, wobei die alten an Ort und Stelle bleiben, aber als "gelöscht" markiert sind. Nach einer Weile kommt autovaccum daher und markiert die Zeilen als freien Platz, damit sie durch ein späteres INSERT überschrieben werden können oder UPDATE . Somit sind die alten Versionen des UPDATE d Zeilen könnten noch herumliegen, vorhanden aber unzugänglich.
Außerdem schreibt Pg in zwei Phasen. Zuerst werden Daten in das Write-Ahead-Protokoll (WAL) geschrieben. Erst wenn es auf die WAL geschrieben und auf die Festplatte getroffen wurde, wird es dann auf den "Heap" (die Haupttabellen) kopiert, wobei möglicherweise alte Daten, die dort waren, überschrieben werden. Der WAL-Inhalt wird vom bgwriter auf den Hauptheap kopiert und durch regelmäßige Kontrollpunkte. Standardmäßig finden Checkpoints alle 5 Minuten statt. Wenn Sie es schaffen, die Datenbank zu stoppen, bevor ein Checkpoint passiert ist, und sie durch Hard-Killing, Ziehen des Steckers auf der Maschine oder Verwenden von pg_ctl gestoppt haben in immediate Modus, in dem Sie die Daten möglicherweise vor dem Kontrollpunkt erfasst haben, sodass sich Ihre alten Daten wahrscheinlich noch auf dem Haufen befinden.
Nachdem Sie nun eine vollständige Kopie des Datenverzeichnisses auf Dateisystemebene erstellt haben, können Sie Ihre Datenbank sichern, wenn dies wirklich erforderlich ist. Die Daten werden immer noch weg sein, aber Sie haben getan, was Sie können, um sich Hoffnung zu machen, sie vielleicht wiederherzustellen. Wenn ich die Wahl hätte, würde ich wahrscheinlich die DB geschlossen lassen, nur um sicher zu gehen.
Wiederherstellung
Möglicherweise müssen Sie jetzt einen Experten für die Innereien von PostgreSQL beauftragen, der Sie bei einem Datenwiederherstellungsversuch unterstützt. Seien Sie bereit, einen Profi für seine Zeit zu bezahlen, möglicherweise ziemlich viel Zeit.
Ich habe darüber auf der Pg-Mailingliste gepostet, und Виктор Егоров hat auf depesz' Post auf pg_dirtyread verlinkt, was genau so aussieht, wie Sie es wollen, obwohl es TOAST nicht wiederherstellt ed Daten, so dass es von begrenztem Nutzen ist. Probieren Sie es aus, wenn Sie Glück haben, könnte es funktionieren.
Siehe:pg_dirtyread auf GitHub.
Ich habe entfernt, was ich in diesem Abschnitt geschrieben hatte, da es durch dieses Tool veraltet ist.
Siehe auch PostgreSQL-Grundlagen zur Zeilenspeicherung
Prävention
Siehe meinen Blogeintrag Verhindern von Beschädigungen der PostgreSQL-Datenbank.
Nebenbei bemerkt:Wenn Sie zweiphasiges Commit verwenden, können Sie ROLLBACK PREPARED verwenden für eine Transaktion, die zum Festschreiben vorbereitet, aber nicht vollständig festgeschrieben wurde. Das kommt dem Rollback einer bereits festgeschriebenen Transaktion am nächsten und trifft nicht auf Ihre Situation zu.
