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 < guillermo...@gmail.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.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 >>>>> >>>>
