Jaime, Hola. Bárbaro muchas gracias por la info. Efectivamente, hasta ahora parece estar todo en condiciones.
Se han realizado bkups lógicos en los días posteriores sin inconvenientes. Saludos y gracias nuevamente. Federico. El lun, 20 may 2024 a las 12:13, Jaime Soler (<jaime.so...@gmail.com>) escribió: > > > El lun, 20 may 2024 a las 17:03, Federico Pascual (< > federico.pasc...@gmail.com>) escribió: > >> Guillermo, Daymel, >> Estimados, muchas gracias por la info. >> Voy a revisar los parámetros que me comentan. >> >> Al ver los logs, me pareció que el motor en el inicio había encontrado un >> problema, pero que luego había continuado con su "trabajo" y había logrado >> alcanzar un estado consistente. Pero la verdad es que me quedaba la duda de >> si no había hecho "su mejor esfuerzo" pero no me estaba GARANTIZANDO la >> consistencia total. >> >> ¿Tonces, si el motor no hubiera podido resolver el problema que me >> hubiera dicho en el log? >> > Cuando la base de datos arranca desde una parada abrupta arranca en modo > recuperación desde el último checkpoint. Si no hubiera podido recuperar > desde ahí, entonces hubiera dado un fallo de no poder recuperar y también > puede que no llegase a arrancar. > > >> ¿Se hubiera quedado en "2024-05-20 09:08:40.014 -03 [361405] HINT: Esto >> probablemente significa que algunos datos están corruptos y tendrá que usar >> el respaldo más reciente para la recuperación."? >> > > Normalmente ese mensaje sale cuando se ha intentado arrancar más de una > vez , después de una parada con error y sin que se acabase el proceso de > recuperación en una primera vez. > Yo no me preocuparía, si después terminó sin problemas el arranque. > > >> >> ¿Hay algún proceso que puede seguir adelante en cualquier momento para >> garantizar de que la db está consistente? es decir que por ejemplo no hay >> archivo corrupto o que no quedó algo inconsistente a nivel de datos. >> > > Para detectar corrupciones y la integridad de los datos, se puede usar > pg_dump y ver que el backup termina sin errores, es decir, si hubieran > problemas en ficheros de datos se pueden ver con un pg_dump sobre todas las > bbdds de la instancia, porque así estas obligando a que se lean todos los > registros de la bases. > > >> Saludos y gracias nuevamente. >> >> Federico. >> >> El lun, 20 may 2024 a las 10:58, Daymel Bonne Solís (< >> daymelbo...@gmail.com>) escribió: >> >>> Hola Federico: >>> >>> On 20 May 2024, at 8:50 AM, Guillermo E. Villanueva < >>> guillermo...@gmail.com> wrote: >>> >>> Federico, ya responderá alguno que sepa mas, pero para mi el mismo >>> postgres ya te hizo la recuperación que necesitaba y los datos quedaron >>> bien. >>> >>> El lun, 20 may 2024 a las 9:20, Federico Pascual (< >>> federico.pasc...@gmail.com>) escribió: >>> >>>> Estimados, >>>> Buen día. >>>> Una consulta. >>>> Un PSQL 15.6 fue "apagado" sin los cuidados correspondientes por un >>>> problema de espacio en la partición donde guarda los datos y el wal (que se >>>> llenó al 100 %). >>>> Yo hice espacio en la partición SIN borrar ningún archivo de PSQL y >>>> arranqué nuevamente el motor. >>>> >>>> Cuando arranca, en el log figura lo siguiente: >>>> -- >>>> 2024-05-20 09:08:39.999 -03 [361401] LOG: escuchando en el socket Unix >>>> «/var/run/postgresql/.s.PGSQL.5432» >>>> 2024-05-20 09:08:40.014 -03 [361405] LOG: el sistema de bases de datos >>>> fue interrumpido durante la recuperación en 2024-05-19 19:46:55 -03 >>>> 2024-05-20 09:08:40.014 -03 [361405] HINT: Esto probablemente >>>> significa que algunos datos están corruptos y tendrá que usar el respaldo >>>> más reciente para la recuperación. >>>> 2024-05-20 09:08:40.226 -03 [361405] LOG: el sistema de bases de datos >>>> no fue apagado apropiadamente; se está efectuando la recuperación >>>> automática >>>> 2024-05-20 09:08:40.233 -03 [361405] LOG: redo comienza en 286/E2D24BE0 >>>> 2024-05-20 09:08:40.745 -03 [361405] LOG: redo listo en 286/E8FFEA98 >>>> utilización del sistema: CPU: usuario: 0.35 s, sistema: 0.15 s, >>>> transcurrido: 0.51 s >>>> 2024-05-20 09:08:40.834 -03 [361403] LOG: empezando checkpoint: >>>> end-of-recovery immediate wait >>>> 2024-05-20 09:08:41.189 -03 [361403] LOG: checkpoint completado: se >>>> escribió 10058 buffers (3.1%); 0 archivo(s) WAL añadido(s), 0 eliminado(s), >>>> 0 reciclado(s); escritura=0.306 s, sincronización=0.015 s, total=0.359 s; >>>> archivos sincronizados=393, más largo=0.006 s, promedio=0.001 s; >>>> distancia=101229 kB, estimado=101229 kB >>>> 2024-05-20 09:08:41.214 -03 [361401] LOG: el sistema de bases de datos >>>> está listo para aceptar conexiones >>>> -- >>>> >>>> Consulto: >>>> ¿Es efectivamente NECESARIO restaurar desde un bkup para estar seguro >>>> de que está todo bien? >>>> ¿No hay una forma de verificar si la bajada produjo efectivamente >>>> alguna corrupción o no? >>>> >>> >>> Tal como te cuenta Guillermo, postgres levantó sin problemas y puedes >>> operarlo con normalidad. >>> >>> Para que no te suceda otra vez, y puedas controlar la cantidad de WALs >>> que puedas tener en esa partición, te recomiendo que revises los parámetros >>> wal_keep_size y max_slot_wal_keep_size (si tienes réplicas que usen slots). >>> >>> Saludos >>> >>>
