Re: Consulta por STOP desprolijo por falta de espacio.

[Federico Pascual]

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 ()
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 pueda

Re: Consulta por STOP desprolijo por falta de espacio.

[Jaime Soler]

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

Re: Consulta por STOP desprolijo por falta de espacio.

[Federico Pascual]

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

Re: Consulta por STOP desprolijo por falta de espacio.

[Daymel Bonne Solís]

Hola Federico:

> On 20 May 2024, at 8:50 AM, Guillermo E. Villanueva  
> 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 ( >) 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



signature.asc
Description: Message signed with OpenPGP

Re: Consulta por STOP desprolijo por falta de espacio.

[Guillermo E. Villanueva]

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?
>
> Saludos y gracias de antemano.
> Federico.
>
>