Re: problema al intentar recuperar PITR

Gracias por tu respuesta Horacio, perdón pero no entiendo bien cual es tu
sugerencia.
Saludos!

Aclaro que pude realizar la restauración del server, pero copiando a mano
los wal al directori pg_xlog

El jue., 21 may. 2020 a las 10:16, Horacio Miranda (<hmiranda(at)gmail(dot)com>)
escribió:

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