Re: PITR Point in Time Recovery en linea administrado

From: "Ivan Perales M(dot)" <ivan(dot)perales(at)gmail(dot)com>
To: Hellmuth Vargas <hivs77(at)gmail(dot)com>
Cc: Cesar Erices <caerices(at)gmail(dot)com>, Lista Postgres ES <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: PITR Point in Time Recovery en linea administrado
Date: 2015-11-20 16:14:23
Message-ID: CAHMuS06-bfW5oBxzPmjyj8p2W1-NXy=444hk1i63BCLebDpEQg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Hmm, en realidad no, a mi nunca me ha pasado lo que comentas, no sabia que
algún desarrollador trabajara sobre una base de datos de producción en
lugar de una base de datos de pruebas. Alomejor sería conveniente que
mejoraran su proceso de desarrollo en lugar de buscar soluciones a
problemas que no deberían existir.

2015-11-20 10:10 GMT-06:00 Hellmuth Vargas <hivs77(at)gmail(dot)com>:

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

--
Lindolfo Iván Perales Mancinas
Solo existen 10 tipos de personas en el mundo, las que saben binario y las
que no.

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Gerardo Herzig 2015-11-20 16:28:30 Re: PITR Point in Time Recovery en linea administrado
Previous Message Hellmuth Vargas 2015-11-20 16:10:16 Re: PITR Point in Time Recovery en linea administrado