Re: PITR Point in Time Recovery en linea administrado

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Hellmuth Vargas <hivs77(at)gmail(dot)com>
Cc: Lista Postgres ES <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: PITR Point in Time Recovery en linea administrado
Date: 2015-11-21 19:51:23
Message-ID: 20151121195123.GR614468@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Hellmuth Vargas escribió:

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

Con un restore_command suficientemente complicado podrías hacerlo. Por
ejemplo podrías hacer uno que consdere un archivo "trigger", que hace
que el restore_command entre en modo "uno a uno" (digamos
/tmp/modo_1a1); en este modo, en vez de retornar inmediatamente con el
archivo que el servidor le pide, el restore_command se pondría a dormir
hasta que apareciera un archivo trigger distinto (digamos
/tmp/continuar_restore). Cuando aparece, deja de dormir, elimina
/tmp/continuar_restore y envía el archivo. (Es importante eliminar el
archivo, para que la creación de ese archivo sólo autorice un único
segmento WAL a restaurar).

Eso te provee la interactividad. Cuando elimines el /tmp/modo_1a1
entonces el restore_command se comporta normalmente, para evitar
apilamientos de archivos WAL cuando no necesitas esta funcionalidad.

Para aplicar hasta un timestamp determinado, podrías hacer que tu
restore_command verifique existencia de otro archivo trigger. Si
existe, lo lee y en él encuentra un recovery_target, y lo graba en el
recovery.conf, luego da un reload que si mal no recuerdo debería ser
suficiente para que el recovery no continúe indefinidamente sino que se
detenga cuando llegue al punto indicado.

Esa es la ventaja de que el restore_command y archive_command sean
programas arbitrarios que tú escribes: puedes hacer lo que se te ocurra,
siempre y cuando tengas la imaginación suficiente.

Ahora, estoy totalmente de acuerdo con César Erices: si tu problema es
que los DBAs se mandan cagadas por estar operando en la BD de producción
con exceso de alcohol en sangre, lo que deberías hacer en vez de perder
tiempo en esto es mejorar el entorno para que tengan donde jugar.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Hellmuth Vargas 2015-11-21 22:08:34 Re: PITR Point in Time Recovery en linea administrado
Previous Message Horacio Miranda 2015-11-20 20:26:34 Re: PITR Point in Time Recovery en linea administrado