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