No, no puede deshacer, revertir o revertir una confirmación.
¡DETÉN LA BASE DE DATOS!
(Nota:si eliminó el directorio de datos del sistema de archivos, NO detenga la base de datos. El siguiente consejo se aplica a una confirmación accidental de un DELETE o similar, no un rm -rf /data/directory escenario).
Si estos datos eran importantes, DETENGA SU BASE DE DATOS AHORA y no lo reinicies. Utilice pg_ctl stop -m immediate para que no se ejecute ningún punto de control al apagar.
No puede revertir una transacción una vez que se ha confirmado. Deberá restaurar los datos de las copias de seguridad o utilizar la recuperación de un momento dado, que debe haberse configurado antes ocurrió el accidente.
Si no configuró ningún archivado PITR/WAL y no tiene copias de seguridad, está en serios problemas.
Mitigación urgente
Una vez que se detiene su base de datos, debe hacer una copia a nivel del sistema de archivos de todo el directorio de datos:la carpeta que contiene base , pg_clog , etc. Copiar todo a una nueva ubicación. No le hagas nada a la copia en la nueva ubicación, es tu única esperanza de recuperar tus datos si no tienes copias de seguridad. Haga otra copia en algún almacenamiento extraíble si puede, y luego desconecte ese almacenamiento de la computadora. Recuerde, necesita absolutamente cada parte del directorio de datos, incluido pg_xlog etc. Ninguna parte carece de importancia.
Exactamente cómo hacer la copia depende del sistema operativo que esté ejecutando. La ubicación del directorio de datos depende del sistema operativo que esté ejecutando y de cómo instaló PostgreSQL.
Formas en que algunos datos podrían haber sobrevivido
Si detiene su base de datos lo suficientemente rápido, es posible que tenga la esperanza de recuperar algunos datos de las tablas. Esto se debe a que PostgreSQL usa el control de concurrencia de múltiples versiones (MVCC) para administrar el acceso simultáneo a su almacenamiento. A veces escribirá nuevas versiones de las filas que actualiza en la tabla, dejando las antiguas en su lugar pero marcadas como "eliminadas". Después de un tiempo, aparece el autovaccum y marca las filas como espacio libre, para que puedan ser sobrescritas por un INSERT posterior. o UPDATE . Por lo tanto, las versiones antiguas de UPDATE Es posible que d filas aún estén por ahí, presentes pero inaccesibles.
Además, Pg escribe en dos fases. Los primeros datos se escriben en el registro de escritura anticipada (WAL). Solo una vez que se ha escrito en el WAL y en el disco, se copia en el "montón" (las tablas principales), posiblemente sobrescribiendo los datos antiguos que estaban allí. bgwriter copia el contenido WAL en el montón principal y por controles periódicos. Por defecto, los puntos de control ocurren cada 5 minutos. Si logra detener la base de datos antes de que haya ocurrido un punto de control y la detuvo matándola, desconectando la máquina o usando pg_ctl en immediate Es posible que haya capturado los datos antes de que ocurriera el punto de control, por lo que es más probable que sus datos antiguos aún estén en el montón.
Ahora que ha realizado una copia completa del directorio de datos a nivel del sistema de archivos, puede iniciar una copia de seguridad de su base de datos si realmente lo necesita; los datos seguirán desaparecidos, pero ha hecho todo lo posible para tener alguna esperanza de recuperarlos. Dada la opción, probablemente mantendría la base de datos cerrada solo para estar seguro.
Recuperación
Es posible que ahora deba contratar a un experto en las entrañas de PostgreSQL para que lo ayude en un intento de recuperación de datos. Esté preparado para pagarle a un profesional por su tiempo, posiblemente bastante tiempo.
Publiqué sobre esto en la lista de correo de Pg, y Виктор Егоров se vinculó a la publicación de depesz en pg_dirtyread, que parece justo lo que quieres, aunque no recupera TOAST ed datos por lo que es de utilidad limitada. Pruébalo, si tienes suerte, podría funcionar.
Consulte:pg_dirtyread en GitHub.
Eliminé lo que había escrito en esta sección porque esa herramienta lo dejó obsoleto.
Consulte también los fundamentos del almacenamiento de filas de PostgreSQL
Prevención
Consulte la entrada de mi blog Prevención de la corrupción de la base de datos de PostgreSQL.
En una nota al margen semi-relacionada, si estuviera usando una confirmación de dos fases, podría ROLLBACK PREPARED para una transacción que se preparó para compromiso pero no se comprometió por completo. Eso es lo más cerca que está de revertir una transacción ya comprometida y no se aplica a su situación.
