Re: problema al intentar recuperar PITR

Guillermo,

ME pasó lo mismo, porque el destino de la copia no estaba en el mismo
servidor y parece que la conexion se pierde,
Alli esta el nombre del file que debes copiar, copias los files hasta que
el pitr sigue, el tiene una lista y la va siguiendo
si no esta ese wall frena, pero espera, si lo copias sigue y eventualmente
llega a estado sync,
suerte con ello.

On Tue, May 26, 2020 at 9:14 AM Guillermo E. Villanueva <
guillermovil(at)gmail(dot)com> wrote:

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