Re: problema al intentar recuperar PITR

Gracias Juan, en mi caso, la copia (para el restore_command) era en el
mismo server, y si, tuve que copiar a mano todos los wal

El mar., 26 may. 2020 a las 11:47, Juan (<smalltalker(dot)marcelo(at)gmail(dot)com>)
escribió:

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