Re: Consulta por STOP desprolijo por falta de espacio.

Hola Federico:

> On 20 May 2024, at 8:50 AM, Guillermo E. Villanueva <guillermovil(at)gmail(dot)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(dot)pascual(at)gmail(dot)com <mailto:federico(dot)pascual(at)gmail(dot)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