Tidak, Anda tidak dapat membatalkan, mengembalikan, atau membalikkan komit.
HENTIKAN DATABASE!
(Catatan:jika Anda menghapus direktori data dari sistem file, JANGAN hentikan database. Saran berikut berlaku untuk komit DELETE yang tidak disengaja. atau serupa, bukan rm -rf /data/directory skenario).
Jika data ini penting, HENTIKAN DATABASE ANDA SEKARANG dan jangan restart. Gunakan pg_ctl stop -m immediate sehingga tidak ada pos pemeriksaan yang dijalankan saat dimatikan.
Anda tidak dapat mengembalikan transaksi setelah dilakukan. Anda perlu memulihkan data dari cadangan, atau menggunakan pemulihan tepat waktu, yang harus telah disiapkan sebelum kecelakaan itu terjadi.
Jika Anda tidak menyiapkan pengarsipan PITR / WAL dan tidak memiliki cadangan, Anda berada dalam masalah besar.
Mitigasi mendesak
Setelah database Anda dihentikan, Anda harus membuat salinan tingkat sistem file dari seluruh direktori data - folder yang berisi base , pg_clog , dll. Salin semuanya ke lokasi baru. Jangan lakukan apa pun pada salinan di lokasi baru, itu adalah satu-satunya harapan Anda untuk memulihkan data Anda jika Anda tidak memiliki cadangan. Buat salinan lain di beberapa penyimpanan yang dapat dilepas jika Anda bisa, lalu cabut penyimpanan itu dari komputer. Ingat, Anda membutuhkan benar-benar setiap bagian dari direktori data, termasuk pg_xlog dll. Tidak ada bagian yang tidak penting.
Cara persisnya membuat salinan tergantung pada sistem operasi yang Anda jalankan. Lokasi direktori data bergantung pada OS yang Anda jalankan dan cara Anda menginstal PostgreSQL.
Cara beberapa data bisa bertahan
Jika Anda menghentikan DB Anda cukup cepat, Anda mungkin memiliki harapan untuk memulihkan beberapa data dari tabel. Itu karena PostgreSQL menggunakan kontrol konkurensi multi-versi (MVCC) untuk mengelola akses bersamaan ke penyimpanannya. Terkadang ia akan menulis versi baru dari baris yang Anda perbarui ke tabel, meninggalkan yang lama di tempatnya tetapi ditandai sebagai "dihapus". Setelah beberapa saat, autovaccum muncul dan menandai baris sebagai ruang kosong, sehingga dapat ditimpa oleh INSERT nanti atau UPDATE . Jadi, versi lama UPDATE baris d mungkin masih ada, ada tetapi tidak dapat diakses.
Selain itu, Pg menulis dalam dua fase. Data pertama ditulis ke write-ahead log (WAL). Hanya setelah itu ditulis ke WAL dan tekan disk, itu kemudian disalin ke "heap" (tabel utama), mungkin menimpa data lama yang ada di sana. Konten WAL disalin ke tumpukan utama oleh bgwriter dan melalui pos pemeriksaan berkala. Secara default, pos pemeriksaan terjadi setiap 5 menit. Jika Anda berhasil menghentikan database sebelum pos pemeriksaan terjadi dan menghentikannya dengan mematikannya, mencabut steker pada mesin, atau menggunakan pg_ctl dalam immediate mode Anda mungkin telah mengambil data dari sebelum pos pemeriksaan terjadi, sehingga data lama Anda kemungkinan besar masih berada di tumpukan.
Sekarang setelah Anda membuat salinan lengkap di tingkat sistem file dari direktori data, Anda dapat memulai pencadangan basis data jika Anda benar-benar perlu; data akan tetap hilang, tetapi Anda telah melakukan apa yang Anda bisa untuk memberi diri Anda harapan untuk memulihkannya. Diberi pilihan, saya mungkin akan mematikan DB hanya untuk amannya.
Pemulihan
Anda sekarang mungkin perlu menyewa seorang ahli dalam jeroan PostgreSQL untuk membantu Anda dalam upaya pemulihan data. Bersiaplah untuk membayar seorang profesional untuk waktu mereka, mungkin sedikit waktu.
Saya memposting tentang ini di milis Pg, dan ор оров menautkan ke posting depesz di pg_dirtyread, yang terlihat seperti yang Anda inginkan, meskipun tidak memulihkan TOAST ed data sehingga utilitas terbatas. Cobalah, jika Anda beruntung mungkin berhasil.
Lihat:pg_dirtyread di GitHub.
Saya telah menghapus apa yang saya tulis di bagian ini karena sudah usang oleh alat itu.
Lihat juga Dasar-dasar penyimpanan baris PostgreSQL
Pencegahan
Lihat entri blog saya Mencegah korupsi database PostgreSQL.
Pada catatan sampingan semi-terkait, jika Anda menggunakan komit dua fase, Anda dapat ROLLBACK PREPARED untuk transaksi yang disiapkan untuk dikomit tetapi tidak dikomit sepenuhnya. Itu yang paling dekat dengan Anda untuk mengembalikan transaksi yang sudah dilakukan, dan tidak berlaku untuk situasi Anda.
