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