Re: problema al intentar recuperar PITR

Guillermo, tendrás que ver porque el restore command fallo.. en ese caso
una mirada al log, algo tuvo que pasar y pasará de nuevo
sinó corriges el problema, espacio en disco? ...

On Tue, May 26, 2020 at 12:50 PM Guillermo E. Villanueva <
guillermovil(at)gmail(dot)com> wrote:

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