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? ¿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."? ¿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. 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 > >
