Re: problema al intentar recuperar PITR

On 22/05/2020 12:56 am, Guillermo E. Villanueva wrote:
> Buen día, ayer me pasó lo mismo amigos, el pitr ignoró totalmente el
> restore command y el log me decía que no encontraba los wal en pg_xlog.
> Permisos: ok
> Sintaxis del recovery: ok
>
> *recovery.conf
> *restore_command = 'cp /home/postgres/backups/walbackup/%f %p'
> recovery_target_time = '2020-05-20 11:02:00'
>
> *log *al intentar recuperar:
>  ;  ; 2020-05-20 16:33:16 ART ; 00000 LOG:  database system was
> interrupted; last known up at 2020-05-17 14:55:03 ART
>  ;  ; 2020-05-20 16:33:16 ART ; 00000 LOG:  starting point-in-time
> recovery to 2020-05-20 11:02:00-03
>  ;  ; 2020-05-20 16:33:16 ART ; 58P01 LOG:  could not open file
> "pg_xlog/000000010000008F000000FA" (log file 143, segment 250): No
> such file or directory
>  ;  ; 2020-05-20 16:33:16 ART ; 00000 LOG:  invalid primary checkpoint
> record
>  ;  ; 2020-05-20 16:33:16 ART ; 58P01 LOG:  could not open file
> "pg_xlog/000000010000008F000000FA" (log file 143, segment 250): No
> such file or directory
>  ;  ; 2020-05-20 16:33:16 ART ; 00000 LOG:  invalid secondary
> checkpoint record
>  ;  ; 2020-05-20 16:33:16 ART ; XX000 PANIC:  could not locate a valid
> checkpoint record
>  ;  ; 2020-05-20 16:33:16 ART ; 00000 LOG:  startup process (PID
> 27121) was terminated by signal 6: Aborted
>  ;  ; 2020-05-20 16:33:16 ART ; 00000 LOG:  aborting startup due to
> startup process failure
>
> el archivo
> 000000010000008F000000FA  si existía en
> /home/postgres/backups/walbackup  y con los permisos correctos para el
> usuario postgres
>
> Para solucionarlo momentaneamente y por la urgencia del caso, copiamos
> manualmente los archivos wal del directorio de recuperación al
> directorio pg_xlog y la recuperación se hizo correctamente incluso
> tomando el parámetro recovery_target_time de forma correcta.
>
> Ven algo raro? alguna sugerencia?
>
Revisa los logs viejos  puede que hay algo ahí.

Revisa con tail los logs cuando detectes el string que buscar, genera
una acción no es ideal pero le dará autonomía a la maquina ( no depender
de humanos es bueno para las maquinas ). Es un parche hasta que
encuentres la solución correcta.

> Gracias!
>
>
>
>
>
> El mié., 10 jul. 2019 a las 9:57, Alvaro Herrera
> (<alvherre(at)2ndquadrant(dot)com <mailto:alvherre(at)2ndquadrant(dot)com>>) escribió:
>
> Guillermo E. Villanueva escribió:
> > Alvaro y Dayme les pido disculpas, dos errores consecutivos en
> el pedido de
> > ayuda,  no tenía acceso al servidor estos días (vacaciones
> invernales)
> > ahora si estoy frente al server postgres.
> > El contenido de recovery.conf es:
> > restore_command = 'cp /usr/local/pgsql/BK20190705/%f %p'
> >
> > Como les comenté, para zafar copié los archivos WAL directamente
> al pg_xlog
> > y la recuperación se pudo hacer, el archivo se renombró a
> recovery.done
> > Gracias a Dios! pude recuperar todo pero me queda la intriga de
> por qué no
> > se pudo hacer como una recuperación normal de PITR
>
> Hmm, bueno, eso debería haber funcionado.  Sospecho que hay algo en la
> configuración de lo cual no te diste cuenta que no estaba totalmente
> correcto ... pero habría que haber mirado los logs del sistema para
> saber qué pudo haber sido.
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>