Re: problema al intentar recuperar PITR
Voy a probar Barman, la verdad que me sentía mas cómodo y con mas control haciendo "a mano". Pero dada la sugerencia, no me queda otra que probar :-) Saludos y muchas gracias a todos. El mar., 2 jun. 2020 a las 18:31, Alvaro Herrera () escribió: > Martín Marqués escribió: > > Mas que recomendar usar rsync, mejor instalar barman y ahorrarse tantos > > dolores de cabeza! > > Sí, yo pensé lo mismo desde hace bastantes mails en este hilo. > Escribir archive_commands y restore_commands no es fácil, aunque lo > parezca. Los ejemplos de la documentación tienen problemas :-( > > -- > Álvaro Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
Re: problema al intentar recuperar PITR
Martín Marqués escribió: > Mas que recomendar usar rsync, mejor instalar barman y ahorrarse tantos > dolores de cabeza! Sí, yo pensé lo mismo desde hace bastantes mails en este hilo. Escribir archive_commands y restore_commands no es fácil, aunque lo parezca. Los ejemplos de la documentación tienen problemas :-( -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: problema al intentar recuperar PITR
Mas que recomendar usar rsync, mejor instalar barman y ahorrarse tantos dolores de cabeza! El mar., 2 jun. 2020 a las 2:02, Carlos T. Groero Carmona (< cton...@gmail.com>) escribió: > Guillermo, > > te recomiendo usar rsync en vez the cp, por ejemplo mi archive_command > luce asi: > archive_command = 'rsync -az --compress-level=1 %p postgres@external_ip > :/pgsql_data/9.6/archive/%f' > A mi me gusta archivar todos los log en un solo lugar, asi quien lo > necesite lo encontrara en el mismo lugar y no necesito pasarlos de un lado > para otro. > > Lo otro has revisado cuantos logs estas manteniendo en x_logs por dia? > vamos a decir que tu PITR es de 12 horas pero por el numero de > transactions se elimina el log que necesitas antes de las 12 horas pues > entonces no lo encontraras cierto? > Analiza cuantos logs necesitas guardar en x_logs y revisa to archive > directory tambien, si tienes espacio es mejor mantener los logs por par de > dias que estos eliminen muy apresuradamente. > > Saludos, > Carlos > > > > > > On Mon, Jun 1, 2020 at 10:48 AM Juan > wrote: > >> Guillermo ese cp no tiene log, si falla no te enteraras nunca, es facil >> de ver , pero quería comentarlo. >> saludos >> jmdc >> >> On Mon, Jun 1, 2020 at 10:29 AM Guillermo E. Villanueva < >> guillermo...@gmail.com> wrote: >> >>> Muchas gracias a todos por sus últimas respuestas. >>> Me dicen que revise el log, es lo primero que hice y se los transcribí >>> en este hilo. >>> Todo está hecho con usuario postgres y con todos los permisos para tal >>> usuario. >>> Les transcribí el comando de restauración, creo que entre todas las >>> cosas que probé, no hice lo que dice Martin Marqués, usar el mismo comando >>> desde el shell, la próxima lo pruebo. >>> Alvaro mi achive command tiene esto: >>> archive_command = 'cp -i %p /home/postgres/backups/walbackup/%f >>> >> >>> Cada x tiempo copio todos los wal de ese directorio >>> /home/postgres/backups/walbackup a otro equipo y si necesito restaurar, me >>> los vuelvo a traer al mismo directorio, siempre manteniendo el usuario >>> postgres y las sin modificar fechas/horas >>> Gracias! >>> >>> >>> El mar., 26 may. 2020 a las 15:27, Alvaro Herrera (< >>> alvhe...@2ndquadrant.com>) escribió: >>> Guillermo E. Villanueva escribió: > Aclaro que pude realizar la restauración del server, pero copiando a mano > los wal al directori pg_xlog ¿qué hay en archive_command? Me pregunto si estarás borrando los WAL cuando los archivas (cosa que, obviamente, no debe hacerse) Saludos -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >>> -- Martín Marqués It’s not that I have something to hide, it’s that I have nothing I want you to see
Re: problema al intentar recuperar PITR
Guillermo, te recomiendo usar rsync en vez the cp, por ejemplo mi archive_command luce asi: archive_command = 'rsync -az --compress-level=1 %p postgres@external_ip :/pgsql_data/9.6/archive/%f' A mi me gusta archivar todos los log en un solo lugar, asi quien lo necesite lo encontrara en el mismo lugar y no necesito pasarlos de un lado para otro. Lo otro has revisado cuantos logs estas manteniendo en x_logs por dia? vamos a decir que tu PITR es de 12 horas pero por el numero de transactions se elimina el log que necesitas antes de las 12 horas pues entonces no lo encontraras cierto? Analiza cuantos logs necesitas guardar en x_logs y revisa to archive directory tambien, si tienes espacio es mejor mantener los logs por par de dias que estos eliminen muy apresuradamente. Saludos, Carlos On Mon, Jun 1, 2020 at 10:48 AM Juan wrote: > Guillermo ese cp no tiene log, si falla no te enteraras nunca, es facil de > ver , pero quería comentarlo. > saludos > jmdc > > On Mon, Jun 1, 2020 at 10:29 AM Guillermo E. Villanueva < > guillermo...@gmail.com> wrote: > >> Muchas gracias a todos por sus últimas respuestas. >> Me dicen que revise el log, es lo primero que hice y se los transcribí en >> este hilo. >> Todo está hecho con usuario postgres y con todos los permisos para tal >> usuario. >> Les transcribí el comando de restauración, creo que entre todas las cosas >> que probé, no hice lo que dice Martin Marqués, usar el mismo comando desde >> el shell, la próxima lo pruebo. >> Alvaro mi achive command tiene esto: >> archive_command = 'cp -i %p /home/postgres/backups/walbackup/%f >> > >> Cada x tiempo copio todos los wal de ese directorio >> /home/postgres/backups/walbackup a otro equipo y si necesito restaurar, me >> los vuelvo a traer al mismo directorio, siempre manteniendo el usuario >> postgres y las sin modificar fechas/horas >> Gracias! >> >> >> El mar., 26 may. 2020 a las 15:27, Alvaro Herrera (< >> alvhe...@2ndquadrant.com>) escribió: >> >>> Guillermo E. Villanueva escribió: >>> >>> > Aclaro que pude realizar la restauración del server, pero copiando a >>> mano >>> > los wal al directori pg_xlog >>> >>> ¿qué hay en archive_command? Me pregunto si estarás borrando los WAL >>> cuando los archivas (cosa que, obviamente, no debe hacerse) >>> >>> Saludos >>> >>> -- >>> Álvaro Herrerahttps://www.2ndQuadrant.com/ >>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >>> >>
Re: problema al intentar recuperar PITR
Guillermo ese cp no tiene log, si falla no te enteraras nunca, es facil de ver , pero quería comentarlo. saludos jmdc On Mon, Jun 1, 2020 at 10:29 AM Guillermo E. Villanueva < guillermo...@gmail.com> wrote: > Muchas gracias a todos por sus últimas respuestas. > Me dicen que revise el log, es lo primero que hice y se los transcribí en > este hilo. > Todo está hecho con usuario postgres y con todos los permisos para tal > usuario. > Les transcribí el comando de restauración, creo que entre todas las cosas > que probé, no hice lo que dice Martin Marqués, usar el mismo comando desde > el shell, la próxima lo pruebo. > Alvaro mi achive command tiene esto: > archive_command = 'cp -i %p /home/postgres/backups/walbackup/%f > Cada x tiempo copio todos los wal de ese directorio > /home/postgres/backups/walbackup a otro equipo y si necesito restaurar, me > los vuelvo a traer al mismo directorio, siempre manteniendo el usuario > postgres y las sin modificar fechas/horas > Gracias! > > > El mar., 26 may. 2020 a las 15:27, Alvaro Herrera (< > alvhe...@2ndquadrant.com>) escribió: > >> Guillermo E. Villanueva escribió: >> >> > Aclaro que pude realizar la restauración del server, pero copiando a >> mano >> > los wal al directori pg_xlog >> >> ¿qué hay en archive_command? Me pregunto si estarás borrando los WAL >> cuando los archivas (cosa que, obviamente, no debe hacerse) >> >> Saludos >> >> -- >> Álvaro Herrerahttps://www.2ndQuadrant.com/ >> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >> >
Re: problema al intentar recuperar PITR
Muchas gracias a todos por sus últimas respuestas. Me dicen que revise el log, es lo primero que hice y se los transcribí en este hilo. Todo está hecho con usuario postgres y con todos los permisos para tal usuario. Les transcribí el comando de restauración, creo que entre todas las cosas que probé, no hice lo que dice Martin Marqués, usar el mismo comando desde el shell, la próxima lo pruebo. Alvaro mi achive command tiene esto: archive_command = 'cp -i %p /home/postgres/backups/walbackup/%f ) escribió: > Guillermo E. Villanueva escribió: > > > Aclaro que pude realizar la restauración del server, pero copiando a mano > > los wal al directori pg_xlog > > ¿qué hay en archive_command? Me pregunto si estarás borrando los WAL > cuando los archivas (cosa que, obviamente, no debe hacerse) > > Saludos > > -- > Álvaro Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
Re: problema al intentar recuperar PITR
Guillermo E. Villanueva escribió: > Aclaro que pude realizar la restauración del server, pero copiando a mano > los wal al directori pg_xlog ¿qué hay en archive_command? Me pregunto si estarás borrando los WAL cuando los archivas (cosa que, obviamente, no debe hacerse) Saludos -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: problema al intentar recuperar PITR
Hola Guillermo, El mar., 26 may. 2020 a las 12:50, Guillermo E. Villanueva (< guillermo...@gmail.com>) escribió: > 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 > Usaste el mismo usuario para copiar los WAL? La forma de verificar que es lo que estaba mal es realizar "exactamente" lo mismo que haría postgres. El restore_command lo tenes que tomar como un comando shell que el usuario postgres ejecuta. Yo cuando tengo problemas con el restore_command me paro como usuario postgres y pruebo de ejecutarlo. Ahí salta el error, por lo general. Saludos, -- Martín Marqués It’s not that I have something to hide, it’s that I have nothing I want you to see
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 < 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 () > 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 () >>> 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 ; 0 LOG: database system was interrupted; last known up at 2020-05-17 14:55:03 ART ; ; 2020-05-20 16:33:16 ART ; 0 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/0001008F00FA" (log file 143, segment 250): No such file or directory ; ; 2020-05-20 16:33:16 ART ; 0 LOG: invalid primary checkpoint record ; ; 2020-05-20 16:33:16 ART ; 58P01 LOG: could not open file "pg_xlog/0001008F00FA" (log file 143, segment 250): No such file or directory ; ; 2020-05-20 16:33:16 ART ; 0 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 ; 0 LOG: startup process (PID 27121) was terminated by signal 6: Aborted ; ; 2020-05-20 16:33:16 ART ; 0 LOG: aborting startup due to startup process failure el archivo 0001008F00FA 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 Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
Re: problema al intentar recuperar PITR
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 () 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 () >> 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 ; 0 LOG: database system was >>> interrupted; last known up at 2020-05-17 14:55:03 ART >>> ; ; 2020-05-20 16:33:16 ART ; 0 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/0001008F00FA" (log file 143, segment 250): No such >>> file or directory >>> ; ; 2020-05-20 16:33:16 ART ; 0 LOG: invalid primary checkpoint >>> record >>> ; ; 2020-05-20 16:33:16 ART ; 58P01 LOG: could not open file >>> "pg_xlog/0001008F00FA" (log file 143, segment 250): No such >>> file or directory >>> ; ; 2020-05-20 16:33:16 ART ; 0 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 ; 0 LOG: startup process (PID 27121) >>> was terminated by signal 6: Aborted >>> ; ; 2020-05-20 16:33:16 ART ; 0 LOG: aborting startup due to >>> startup process failure >>> >>> el archivo >>> 0001008F00FA 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 Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >>>
Re: problema al intentar recuperar PITR
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 () > 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 ; 0 LOG: database system was >> interrupted; last known up at 2020-05-17 14:55:03 ART >> ; ; 2020-05-20 16:33:16 ART ; 0 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/0001008F00FA" (log file 143, segment 250): No such >> file or directory >> ; ; 2020-05-20 16:33:16 ART ; 0 LOG: invalid primary checkpoint >> record >> ; ; 2020-05-20 16:33:16 ART ; 58P01 LOG: could not open file >> "pg_xlog/0001008F00FA" (log file 143, segment 250): No such >> file or directory >> ; ; 2020-05-20 16:33:16 ART ; 0 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 ; 0 LOG: startup process (PID 27121) >> was terminated by signal 6: Aborted >> ; ; 2020-05-20 16:33:16 ART ; 0 LOG: aborting startup due to >> startup process failure >> >> el archivo >> 0001008F00FA 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 Herrerahttps://www.2ndQuadrant.com/ >>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >>> >>
Re: problema al intentar recuperar PITR
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 () 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 ; 0 LOG: database system was > interrupted; last known up at 2020-05-17 14:55:03 ART > ; ; 2020-05-20 16:33:16 ART ; 0 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/0001008F00FA" (log file 143, segment 250): No such > file or directory > ; ; 2020-05-20 16:33:16 ART ; 0 LOG: invalid primary checkpoint > record > ; ; 2020-05-20 16:33:16 ART ; 58P01 LOG: could not open file > "pg_xlog/0001008F00FA" (log file 143, segment 250): No such > file or directory > ; ; 2020-05-20 16:33:16 ART ; 0 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 ; 0 LOG: startup process (PID 27121) > was terminated by signal 6: Aborted > ; ; 2020-05-20 16:33:16 ART ; 0 LOG: aborting startup due to > startup process failure > > el archivo > 0001008F00FA 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 Herrerahttps://www.2ndQuadrant.com/ >> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >> >
Re: problema al intentar recuperar PITR
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 ; 0 LOG: database system was interrupted; last known up at 2020-05-17 14:55:03 ART ; ; 2020-05-20 16:33:16 ART ; 0 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/0001008F00FA" (log file 143, segment 250): No such file or directory ; ; 2020-05-20 16:33:16 ART ; 0 LOG: invalid primary checkpoint record ; ; 2020-05-20 16:33:16 ART ; 58P01 LOG: could not open file "pg_xlog/0001008F00FA" (log file 143, segment 250): No such file or directory ; ; 2020-05-20 16:33:16 ART ; 0 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 ; 0 LOG: startup process (PID 27121) was terminated by signal 6: Aborted ; ; 2020-05-20 16:33:16 ART ; 0 LOG: aborting startup due to startup process failure el archivo 0001008F00FA 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 (mailto: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
Re: problema al intentar recuperar PITR
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 ; 0 LOG: database system was interrupted; last known up at 2020-05-17 14:55:03 ART ; ; 2020-05-20 16:33:16 ART ; 0 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/0001008F00FA" (log file 143, segment 250): No such file or directory ; ; 2020-05-20 16:33:16 ART ; 0 LOG: invalid primary checkpoint record ; ; 2020-05-20 16:33:16 ART ; 58P01 LOG: could not open file "pg_xlog/0001008F00FA" (log file 143, segment 250): No such file or directory ; ; 2020-05-20 16:33:16 ART ; 0 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 ; 0 LOG: startup process (PID 27121) was terminated by signal 6: Aborted ; ; 2020-05-20 16:33:16 ART ; 0 LOG: aborting startup due to startup process failure el archivo 0001008F00FA 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? Gracias! El mié., 10 jul. 2019 a las 9:57, Alvaro Herrera () 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 Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
Re: problema al intentar recuperar PITR
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 Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: problema al intentar recuperar PITR
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 Gracias por las respuestas Guillermo El mar., 9 jul. 2019 a las 13:12, Daymel Bonne () escribió: > Buenas: > > El mar., 9 de jul. de 2019 a la(s) 11:02, Alvaro Herrera ( > alvhe...@2ndquadrant.com) escribió: > >> Guillermo E. Villanueva escribió: >> > Gracias por tu respuesta Alvaro, >> > recovery.con tiene: >> > restore_command = '/usr/local/pgsql/BK20190705/%f %p' >> > > No te falta el cp? o sea debería ser: > > restore_command = 'cp /usr/local/pgsql/BK20190705/%f %p' > > Saludos >
Re: problema al intentar recuperar PITR
Buenas: El mar., 9 de jul. de 2019 a la(s) 11:02, Alvaro Herrera ( alvhe...@2ndquadrant.com) escribió: > Guillermo E. Villanueva escribió: > > Gracias por tu respuesta Alvaro, > > recovery.con tiene: > > restore_command = '/usr/local/pgsql/BK20190705/%f %p' > No te falta el cp? o sea debería ser: restore_command = 'cp /usr/local/pgsql/BK20190705/%f %p' Saludos
Re: problema al intentar recuperar PITR
no no perdón fue un error de tipeo en el mensaje, el nombre es correcto, se llama recovery.conf El mar., 9 jul. 2019 a las 13:02, Alvaro Herrera () escribió: > Guillermo E. Villanueva escribió: > > Gracias por tu respuesta Alvaro, > > recovery.con tiene: > > restore_command = '/usr/local/pgsql/BK20190705/%f %p' > > > > Les cuento que pude resolverlo de una manera no muy convincente, antes > del > > start copié todos los archivos wal de respaldo al directorio pg_xlog y > > arrancó bien, pero... pero... y el restore_command? por qué no funcionó? > > Si el archivo realmente se llama recovery.con, eso lo explicaría, porque > el servidor sólo busca un archivo recovery.conf. > > -- > Álvaro Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
Re: problema al intentar recuperar PITR
Guillermo E. Villanueva escribió: > Gracias por tu respuesta Alvaro, > recovery.con tiene: > restore_command = '/usr/local/pgsql/BK20190705/%f %p' > > Les cuento que pude resolverlo de una manera no muy convincente, antes del > start copié todos los archivos wal de respaldo al directorio pg_xlog y > arrancó bien, pero... pero... y el restore_command? por qué no funcionó? Si el archivo realmente se llama recovery.con, eso lo explicaría, porque el servidor sólo busca un archivo recovery.conf. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: problema al intentar recuperar PITR
Gracias por tu respuesta Alvaro, recovery.con tiene: restore_command = '/usr/local/pgsql/BK20190705/%f %p' Les cuento que pude resolverlo de una manera no muy convincente, antes del start copié todos los archivos wal de respaldo al directorio pg_xlog y arrancó bien, pero... pero... y el restore_command? por qué no funcionó? El sáb., 6 jul. 2019 a las 0:21, Alvaro Herrera () escribió: > Guillermo E. Villanueva escribió: > > Hola, hice todos los pasos necesarios para una recuperación correcta > usando > > PITR. > > Es mas, hicimos pruebas en meses atras y funcionaron bien. > > Ahora que lo necesito en serio, tengo un problema, intento levantar en > modo > > de recuperación (recovery.conf) y obtengo lo siguiente: > > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > 5d1fc5bf.5a54 > > %; %; 0 LOG: comenzando proceso de recuperación > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > 5d1fc5bf.5a54 > > %; %; 58P01 LOG: no se pudo abrir «pg_xlog/000206DA00AC» > > (archivo de registro 1754, segmento 172): No existe el fichero o el > > directorio > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > 5d1fc5bf.5a54 > > %; %; 0 LOG: el registro del punto de control primario no es > válido > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > 5d1fc5bf.5a54 > > %; %; 58P01 LOG: no se pudo abrir «pg_xlog/000206DA00AC» > > (archivo de registro 1754, segmento 172): No existe el fichero o el > > directorio > > > El archivo 000206DA00AC si está en el directorio de > > recuperación: /usr/local/pgsql/BK20190705/ > > OK, pero no es ahí donde lo está buscando. ¿qué dice tu recovery.conf? > > -- > Álvaro Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
Re: problema al intentar recuperar PITR
Gracias por la respuesta y disculpas por no responder antes. si existe el archivo con el tamaño correcto. El vie., 5 jul. 2019 a las 23:10, Juan () escribió: > El archivo existe, cuánto mide? Cual es la longitud seteada de wall? > > El vie., 5 de jul. de 2019 11:07 PM, Horacio Miranda > escribió: > >> Revisa los permisos que tiene el archivo, revisa sí selinux esta >> habilitado. >> >> >> On 6/07/2019 10:08 AM, Guillermo E. Villanueva wrote: >> > Hola, hice todos los pasos necesarios para una recuperación correcta >> > usando PITR. >> > Es mas, hicimos pruebas en meses atras y funcionaron bien. >> > Ahora que lo necesito en serio, tengo un problema, intento levantar en >> > modo de recuperación (recovery.conf) y obtengo lo siguiente: >> > 2019-07-05 18:48:47.864 ART %; %; %; 0 %; %; 23124 %; >> > 5d1fc5bf.5a54 %; %; 0 LOG: el sistema de bases de datos fue >> > interrumpido; última vez en funcionamiento en 2019-06-30 22:25:09 ART >> > 2019-07-05 18:48:47.864 ART %; %; %; 0 %; %; 23124 %; >> > 5d1fc5bf.5a54 %; %; 0 LOG: creando el directorio WAL faltante >> > «pg_xlog/archive_status» >> > cp: no se puede efectuar `stat' sobre >> > «/usr/local/pgsql/BK20190705/0002.history»: No existe el fichero o >> > el directorio >> > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; >> > 5d1fc5bf.5a54 %; %; 0 LOG: comenzando proceso de recuperación >> > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; >> > 5d1fc5bf.5a54 %; %; 58P01 LOG: no se pudo abrir >> > «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento >> > 172): No existe el fichero o el directorio >> > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; >> > 5d1fc5bf.5a54 %; %; 0 LOG: el registro del punto de control >> > primario no es válido >> > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; >> > 5d1fc5bf.5a54 %; %; 58P01 LOG: no se pudo abrir >> > «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento >> > 172): No existe el fichero o el directorio >> > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; >> > 5d1fc5bf.5a54 %; %; 0 LOG: el registro del punto de control >> > secundario no es válido >> > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; >> > 5d1fc5bf.5a54 %; %; XX000 PANIC: no se pudo localizar un registro >> > de punto de control válido >> > 2019-07-05 18:48:47.869 ART %; %; %; 0 %; %; 23122 %; >> > 5d1fc5bf.5a52 %; %; 0 LOG: proceso de inicio (PID 23124) fue >> > terminado por una señal 6: Aborted >> > 2019-07-05 18:48:47.869 ART %; %; %; 0 %; %; 23122 %; >> > 5d1fc5bf.5a52 %; %; 0 LOG: abortando el inicio debido a una >> > falla en el procesamiento de inicio >> > >> > El archivo 000206DA00AC si está en el directorio de >> > recuperación: /usr/local/pgsql/BK20190705/ >> > >> > Por favor, me pueden orientar en que está pasando? >> > >> > Gracias >> >> >>
Re: problema al intentar recuperar PITR
Gracias por tu respuesta, perdón por no responder antes, para descartar le puse permisos 777 postgres:postgres. La verdad que no se si selinux estaba habilitado, pero si funcionó en las pruebas, creo que no sería un factor no? El vie., 5 jul. 2019 a las 23:07, Horacio Miranda () escribió: > Revisa los permisos que tiene el archivo, revisa sí selinux esta > habilitado. > > > On 6/07/2019 10:08 AM, Guillermo E. Villanueva wrote: > > Hola, hice todos los pasos necesarios para una recuperación correcta > > usando PITR. > > Es mas, hicimos pruebas en meses atras y funcionaron bien. > > Ahora que lo necesito en serio, tengo un problema, intento levantar en > > modo de recuperación (recovery.conf) y obtengo lo siguiente: > > 2019-07-05 18:48:47.864 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 0 LOG: el sistema de bases de datos fue > > interrumpido; última vez en funcionamiento en 2019-06-30 22:25:09 ART > > 2019-07-05 18:48:47.864 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 0 LOG: creando el directorio WAL faltante > > «pg_xlog/archive_status» > > cp: no se puede efectuar `stat' sobre > > «/usr/local/pgsql/BK20190705/0002.history»: No existe el fichero o > > el directorio > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 0 LOG: comenzando proceso de recuperación > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 58P01 LOG: no se pudo abrir > > «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento > > 172): No existe el fichero o el directorio > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 0 LOG: el registro del punto de control > > primario no es válido > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 58P01 LOG: no se pudo abrir > > «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento > > 172): No existe el fichero o el directorio > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 0 LOG: el registro del punto de control > > secundario no es válido > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; XX000 PANIC: no se pudo localizar un registro > > de punto de control válido > > 2019-07-05 18:48:47.869 ART %; %; %; 0 %; %; 23122 %; > > 5d1fc5bf.5a52 %; %; 0 LOG: proceso de inicio (PID 23124) fue > > terminado por una señal 6: Aborted > > 2019-07-05 18:48:47.869 ART %; %; %; 0 %; %; 23122 %; > > 5d1fc5bf.5a52 %; %; 0 LOG: abortando el inicio debido a una > > falla en el procesamiento de inicio > > > > El archivo 000206DA00AC si está en el directorio de > > recuperación: /usr/local/pgsql/BK20190705/ > > > > Por favor, me pueden orientar en que está pasando? > > > > Gracias >
Re: problema al intentar recuperar PITR
Guillermo E. Villanueva escribió: > Hola, hice todos los pasos necesarios para una recuperación correcta usando > PITR. > Es mas, hicimos pruebas en meses atras y funcionaron bien. > Ahora que lo necesito en serio, tengo un problema, intento levantar en modo > de recuperación (recovery.conf) y obtengo lo siguiente: > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 > %; %; 0 LOG: comenzando proceso de recuperación > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 > %; %; 58P01 LOG: no se pudo abrir «pg_xlog/000206DA00AC» > (archivo de registro 1754, segmento 172): No existe el fichero o el > directorio > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 > %; %; 0 LOG: el registro del punto de control primario no es válido > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 > %; %; 58P01 LOG: no se pudo abrir «pg_xlog/000206DA00AC» > (archivo de registro 1754, segmento 172): No existe el fichero o el > directorio > El archivo 000206DA00AC si está en el directorio de > recuperación: /usr/local/pgsql/BK20190705/ OK, pero no es ahí donde lo está buscando. ¿qué dice tu recovery.conf? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: problema al intentar recuperar PITR
El archivo existe, cuánto mide? Cual es la longitud seteada de wall? El vie., 5 de jul. de 2019 11:07 PM, Horacio Miranda escribió: > Revisa los permisos que tiene el archivo, revisa sí selinux esta > habilitado. > > > On 6/07/2019 10:08 AM, Guillermo E. Villanueva wrote: > > Hola, hice todos los pasos necesarios para una recuperación correcta > > usando PITR. > > Es mas, hicimos pruebas en meses atras y funcionaron bien. > > Ahora que lo necesito en serio, tengo un problema, intento levantar en > > modo de recuperación (recovery.conf) y obtengo lo siguiente: > > 2019-07-05 18:48:47.864 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 0 LOG: el sistema de bases de datos fue > > interrumpido; última vez en funcionamiento en 2019-06-30 22:25:09 ART > > 2019-07-05 18:48:47.864 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 0 LOG: creando el directorio WAL faltante > > «pg_xlog/archive_status» > > cp: no se puede efectuar `stat' sobre > > «/usr/local/pgsql/BK20190705/0002.history»: No existe el fichero o > > el directorio > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 0 LOG: comenzando proceso de recuperación > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 58P01 LOG: no se pudo abrir > > «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento > > 172): No existe el fichero o el directorio > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 0 LOG: el registro del punto de control > > primario no es válido > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 58P01 LOG: no se pudo abrir > > «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento > > 172): No existe el fichero o el directorio > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; 0 LOG: el registro del punto de control > > secundario no es válido > > 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; > > 5d1fc5bf.5a54 %; %; XX000 PANIC: no se pudo localizar un registro > > de punto de control válido > > 2019-07-05 18:48:47.869 ART %; %; %; 0 %; %; 23122 %; > > 5d1fc5bf.5a52 %; %; 0 LOG: proceso de inicio (PID 23124) fue > > terminado por una señal 6: Aborted > > 2019-07-05 18:48:47.869 ART %; %; %; 0 %; %; 23122 %; > > 5d1fc5bf.5a52 %; %; 0 LOG: abortando el inicio debido a una > > falla en el procesamiento de inicio > > > > El archivo 000206DA00AC si está en el directorio de > > recuperación: /usr/local/pgsql/BK20190705/ > > > > Por favor, me pueden orientar en que está pasando? > > > > Gracias > > >
Re: problema al intentar recuperar PITR
Revisa los permisos que tiene el archivo, revisa sí selinux esta habilitado. On 6/07/2019 10:08 AM, Guillermo E. Villanueva wrote: Hola, hice todos los pasos necesarios para una recuperación correcta usando PITR. Es mas, hicimos pruebas en meses atras y funcionaron bien. Ahora que lo necesito en serio, tengo un problema, intento levantar en modo de recuperación (recovery.conf) y obtengo lo siguiente: 2019-07-05 18:48:47.864 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 0 LOG: el sistema de bases de datos fue interrumpido; última vez en funcionamiento en 2019-06-30 22:25:09 ART 2019-07-05 18:48:47.864 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 0 LOG: creando el directorio WAL faltante «pg_xlog/archive_status» cp: no se puede efectuar `stat' sobre «/usr/local/pgsql/BK20190705/0002.history»: No existe el fichero o el directorio 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 0 LOG: comenzando proceso de recuperación 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 58P01 LOG: no se pudo abrir «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento 172): No existe el fichero o el directorio 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 0 LOG: el registro del punto de control primario no es válido 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 58P01 LOG: no se pudo abrir «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento 172): No existe el fichero o el directorio 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 0 LOG: el registro del punto de control secundario no es válido 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; XX000 PANIC: no se pudo localizar un registro de punto de control válido 2019-07-05 18:48:47.869 ART %; %; %; 0 %; %; 23122 %; 5d1fc5bf.5a52 %; %; 0 LOG: proceso de inicio (PID 23124) fue terminado por una señal 6: Aborted 2019-07-05 18:48:47.869 ART %; %; %; 0 %; %; 23122 %; 5d1fc5bf.5a52 %; %; 0 LOG: abortando el inicio debido a una falla en el procesamiento de inicio El archivo 000206DA00AC si está en el directorio de recuperación: /usr/local/pgsql/BK20190705/ Por favor, me pueden orientar en que está pasando? Gracias
problema al intentar recuperar PITR
Hola, hice todos los pasos necesarios para una recuperación correcta usando PITR. Es mas, hicimos pruebas en meses atras y funcionaron bien. Ahora que lo necesito en serio, tengo un problema, intento levantar en modo de recuperación (recovery.conf) y obtengo lo siguiente: 2019-07-05 18:48:47.864 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 0 LOG: el sistema de bases de datos fue interrumpido; última vez en funcionamiento en 2019-06-30 22:25:09 ART 2019-07-05 18:48:47.864 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 0 LOG: creando el directorio WAL faltante «pg_xlog/archive_status» cp: no se puede efectuar `stat' sobre «/usr/local/pgsql/BK20190705/0002.history»: No existe el fichero o el directorio 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 0 LOG: comenzando proceso de recuperación 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 58P01 LOG: no se pudo abrir «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento 172): No existe el fichero o el directorio 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 0 LOG: el registro del punto de control primario no es válido 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 58P01 LOG: no se pudo abrir «pg_xlog/000206DA00AC» (archivo de registro 1754, segmento 172): No existe el fichero o el directorio 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; 0 LOG: el registro del punto de control secundario no es válido 2019-07-05 18:48:47.868 ART %; %; %; 0 %; %; 23124 %; 5d1fc5bf.5a54 %; %; XX000 PANIC: no se pudo localizar un registro de punto de control válido 2019-07-05 18:48:47.869 ART %; %; %; 0 %; %; 23122 %; 5d1fc5bf.5a52 %; %; 0 LOG: proceso de inicio (PID 23124) fue terminado por una señal 6: Aborted 2019-07-05 18:48:47.869 ART %; %; %; 0 %; %; 23122 %; 5d1fc5bf.5a52 %; %; 0 LOG: abortando el inicio debido a una falla en el procesamiento de inicio El archivo 000206DA00AC si está en el directorio de recuperación: /usr/local/pgsql/BK20190705/ Por favor, me pueden orientar en que está pasando? Gracias
