Hola, favor de leer la sección sugerencia.
Flash back es otra cosa. Distinto a lo que te mencione de los ETL
(convertir los delete/update en solo insert ) para poder recuperarse de
estos errores.
El flash back es una opción donde puedes poner leer datos pasados en el
tiempo ( dependiendo de la retención ).
Ejemplo:
10:00 pm alguien hizo un delete de todos los registros y el sistema
tiene registros nuevos desde las 10:00 pm...
La forma de recuperarte es de dos formas ( con Oracle o postgres esta
forma es similar ), clonando la base de datos justo antes del delete. (
Lo ideal es que tengas auditado cuando alguien hace delete/truncate (
que no sea un usuario de aplicación ), para eso vas a tener que jugar
con los ACL y crear grant para poder auditar de forma correcta.
La otra forma ( solo se que Oracle tiene esta opción ), es con
FlashBack, es un área de recuperación online que tiene Oracle del tamaño
( que tu configures ), incluido guarda las tablas que borras, pasado el
tiempo X, se borran los datos. Pero básicamente es para recuperarse de
errores como esos, de esa forma puedes insertar de nuevo los datos o
crear una tabla con los datos antes que los modificaran.
https://docs.oracle.com/cd/B12037_01/appdev.101/b10795/adfns_fl.htm
Pero ojo, sin un audit, no sabes cuando paso eso...
## Sugerencia ##
Por lo que me comentas, los problemas no son del sistema, si no de los
desarrolladores, creo que lo que te hace falta hacer, es:
1. Cerrar acceso de producción a los desarrolladores.
2. Tener un proceso de respaldo lógico para cuando tengas que hacer
limpieza de datos.
3. Auditar de alguna forma delete masivos/update que no sean de la
aplicación.
4. Clonar producción de forma automatica para que los desarrolladores
hagan lo que quieran.
5. Generar un ambiente QA ( probar tu proceso antes de pasarlo a
producción).
6. Usar algo como cucumber o selenium ( para hacer pruebas automaticas
despues de aplicar el proceso en tu QA.
7. Hacer otra cosa con tu tiempo ya que tus problemas deberian desaparecer.
PS: Recuerda, que no hay sistemas a prueba de idiotas, y los idiotas son
super ingeniosos para romper cosas... solo hay formas de contenerlos lo
mejor posible.
On 11/21/2015 8:58 AM, Hellmuth Vargas wrote:
Hola Horacio Muchas gracias por el comentario
La inquietud surge porque estuve leyendo algo similar en Oracle
https://moisesespinosa.wordpress.com/2011/09/19/flashback-i-introduccion/
y dado que PostgreSQL implementa una replica retrasada pensé ..."y
porque no tener la posibilidad de ir aplicando los cambios paso a paso
hasta lograr la instantánea de los datos justo antes de que se hubiesen
borrado." en un caso hipotético que seria algo mas inmediato, expedito
que hacerlo por PITR
El 20 de noviembre de 2015, 2:41 p. m., Horacio
Miranda<hmira...@gmail.com <mailto:hmira...@gmail.com>> escribió:
Hola, para tu problema ( ignoro si esto es util ), en un cliente (
Oracle ) teniamos el mismo problema, la forma de solucionarlo fue
implemetnar Oracle Stream con WTL ( convirtiendo todos los update,
delete en insert ) para poder volver atras sin recuperar, la base de
datos era de unos 10 Teras eso si.
Ignoro si en postgresql existe una forma de replicar y modificar lo
que llega a la replica ( cosa de poder volver atras las transacciones ).
Si no existe sería un feature que valdría la pena trabajar y hacer. :D
On 11/21/2015 3:45 AM, Hellmuth Vargas wrote:
Buenos dias Lista
Dado que en algunas oportunidades (mas de las que quisiera) se
borran
datos de tablas,o incluso las tablas mismas, se actualizan con datos
errores, etc etc, etc (otro tema es que entren usuario con
privilegios a
hacer estas calamidades... ) para subsanar esto hay que restaurar
backups y con los WAL archivados restaurar los datos alterados, esto
toma tiempo, mas cuando las bases son grandes y mas cuando no se
sabe
exactamente la hora del suceso; para la versión 9.4 existe la
posibilidad de mantener una replica retasada un X tiempo
(http://www.depesz.com/2013/12/20/waiting-for-9-4-allow-time-delayed-standbys-and-recovery/)
que ayuda bastante, pues es una base EN LINEA con la foto de
nuestra
base de hace X tiempo, mas si el cambio fue antes de este tiempo, ni
modos... Entonces la pregunta es:
Que posibilidades hay de mantener una replica en linea retrasada X
tiempo (casi una semana, por ejemplo) pero que se pudiera
administrar la
aplicación de los WAL de forma manual, para permitir operaciones
como (todas ojala dentro de una transaccion para poder
devolver el
cambio en el caso que uno se 'pasara' de la hora del suceso):
- Aplicación de cambios hasta un timestamp defnido
- Aplicación de WAL interactivamente, algo como aplique el
siguiente WAL
para que por tanteo se pueda llegar a los datos mas próximos
antes de la
calamidad
Y con todas las bondades de las replicas en linea. Muchas
gracias Lista
y quedo atento a sus comentarios.
--
Cordialmente,
Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate
--
Cordialmente,
Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
