Re: PITR Point in Time Recovery en linea administrado

Hola cesar

Gracias por la respuesta, pero esas soluciones basadas en triggers
penalizan mucho el rendimiento al menos en mi caso,tenemos una base de
call center y otra de registros GPS de muchas operaciones por segundo
concurrentes. Una replica retrasada si funciona pues si un desarrollador
por equivocación corre una sentencia DML por error (un UPDATE sin WHERE
por ejemplo y a quien no le halla pasado que tire la primera piedra) y si
avisa rápidamente se puede rescatar los datos de la replica retrasada. Lo
que consulto es si puede contar con una replica retrasada donde los cambios
se puedan aplicar de forma manual como lo expuse en el anterior correo.

El 20 de noviembre de 2015, 10:21 a. m., Cesar Erices<caerices(at)gmail(dot)com>
escribió:

> Estimado, buenas tardes.
>
> No se si entendi bien tu consulta, pero cuando hablas de borar datos te
> refieres a que por sistema se modifican o elimina información? de ser sí,
> creo que lo que solicitas (Replica) no te serviria, porque habitualmente
> las replicas mantienen la misma información que las originales y si
> eliminas un dato en X tiempo se te borrara en la replica y no te sirvira de
> mucho. Para esto te sugiero generar unas tablas de auditorias (replicas
> exactas de las tablas originales) que registren de manera interna (es decir
> por medio de triger) todos los cambios que se han realizado y a estas
> tablas generar un procedimiento para mantener la información de un X tiempo.
>
> Espero haber sido claro cualquier consulta me avisas.
>
> El 20 de noviembre de 2015, 11:45, Hellmuth Vargas <hivs77(at)gmail(dot)com>
> escribió:
>
>> 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
>>
>>
>
>
> --
> Sin más que decir se despide de Usted, muy atentamente
>
> Cesar Erices Vergara
> Ingeniero en Gestión Informática
> Analista de Sistema
> Especialista en ISO 27001 e ITIL
>
> Cuenta Twitter: @caerices
>
> Santiago - Chile
>

--
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