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.marc...@gmail.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 < > guillermo...@gmail.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 (<hmira...@gmail.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 (< >>> alvhe...@2ndquadrant.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 >>>> >>>
