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