Fwd: Corrupción de datos

Hola Horacio. Hice un sosreport pero está bien grande y todavía lo estoy
checando, pues debo ir haciendo otras tareas a la par.
Pero ejecuté un 'dmesg -f kern -H' y me devolvió esto:

[Mar29 16:08] print_req_error: I/O error, dev loop0, sector 0

Revisé los logs para ver si PostgreSQL había dado otro error después del
print_req_error, pero no nada, lo que no sé si PostgreSQL utiliza esos loop
devices.
Revisé todos los logs del journal y del kernel y no hay ningún fallo de I/O
anteriormente.
Los errores del block los sigue dando a la misma hora porque hay un proceso
que se ejecuta a esa hora y trabaja sobre esa tabla.
El archivo dañado pesa 1.0 GB y la base de datos en total unos 26 GB.

Saludos

El vie., 29 mar. 2019 a las 2:41, Horacio Miranda (<hmiranda(at)gmail(dot)com>)
escribió:

>
> On 29/03/2019 11:42 AM, Frank Alberto Rodriguez Solana wrote:
>
> Gracias Daniel. El problema es que es un servidor virtual en la nuve, por
> lo que quiero descartar los problemas de software, para asegurarme lo más
> que pueda de que sea el hardware antes de tomar la desición de migrar de
> cloud puesto que mi empresa tiene casi todos los servidores con ese
> proveedor.
>
> Si son problemas de discos, debes revisar /var/log/messages o hace un
> dmesg ( mensajes del kernel ).
>
> Sí puedes sacar una foto de como esta tu sistema ( sosreport o algo
> similar ).
>
> Ahora no creo que tu posgres tenga problemas de software y sí lo tiene
> creo que lo unico que se me puede ocurrir es que por alguna forma extraña o
> casi imposible dos procesos estan arriba ( escribiendo en la misma base )
> cosa que solo una vez me paso en la vida y tuve que usar respaldos ( fue
> con postgres 6.1 creo ) pero eso fue la unica vez que eh tenido problemas
> con software.
>
> Saludos
>
> El jue., 28 mar. 2019 a las 15:18, Ing.Daniel Bojorge (<
> debs(dot)foros(at)gmail(dot)com>) escribió:
>
>> Estimados, alguna vez supe de ese error y el problema fue el
>> almacenamiento donde estaba postgre (osea los discos duros).
>>
>> Te recomendaría los revises para evitar nuevamente corrupción en los
>> archivos.
>>
>>
>> Dios L(at)s Bendiga
>>
>> Saludos,
>>
>>
>>
>> [image: --]
>>
>> daniel.bojorge
>> [image: http://]about.me/daniel.bojorge
>> <http://about.me/daniel.bojorge?promo=email_sig>
>> *Curso Desarrollo Web con Python usando Django 2.1 Para Principiantes*
>> <https://goo.gl/oeT5Sx>
>> *WebService RestFul API con Python usando Django RestFrameWork*
>> <https://goo.gl/j8i34C>
>> *Fácil Replicación de Cualquier Base de Datos y/o Sistema Operativo*
>> <https://goo.gl/HjtExs>
>> *Programación en Capas (Web y Escritorio)* <https://goo.gl/zGZpSD>
>> Mi Blog <http://debsconsultores.blogspot.com>
>> Nicaragua
>>
>> "Si ustedes permanecen unidos a mí, y si permanecen fieles a mis
>> enseñanzas, pidan lo que quieran y se les dará.
>> (Juan 15:7 DHH)
>> Bendito el varón que se fía en el SEÑOR, y cuya confianza es el SEÑOR.
>> (Jeremías 17:7 RV2000)
>>
>>
>>
>> El jue., 28 mar. 2019 a las 13:21, Anthony Sotolongo (<
>> asotolongo(at)gmail(dot)com>) escribió:
>>
>>> Hola Frank, cuanto tiempo!!!, que bueno que aun estás trabajando en PG
>>>
>>> Tuve una vez una situación similar de errores ...contains unexpected
>>> zero page at block ...
>>>
>>> y no se si "casualmente" o era el motivo real de los problemas que
>>> tenia, los discos donde estaba el servidor de PG estaban teniendo
>>> problemas,
>>>
>>> cuando se hizo el cambio a otro servidor se solucionó el tema de una vez
>>>
>>>
>>> Tal vez revisando con alguna herramienta que le hace pruebas a la RAM y
>>> Discos te pueda dar más indicios del estado
>>>
>>>
>>> Puedes chequear si los temas solucionados a continuación puede causar
>>> estos temas de corrupción y si está resuelto de la versión 10.5 a la
>>> 10.7:
>>>
>>> https://why-upgrade.depesz.com/show?from=10.5&to=10.7&keywords=
>>>
>>> Saludos
>>>
>>>
>>>
>>> El 28-03-19 a las 15:17, Frank Alberto Rodriguez Solana escribió:
>>> > Hola. Estoy teniendo varios problemas con un servidor dedicado a
>>> > PostgreSQL 10.5, que pueden ser de corrupción de datos o un bug y me
>>> > gustaría me dieran opiniones.
>>> >
>>> > Primero fueron estos errores:
>>> >
>>> > ERROR: index "pg_proc_proname_args_nsp_index" contains unexpected
>>> > zero page at block 16 at character 56
>>> > ERROR: index "pg_proc_proname_args_nsp_index" contains unexpected
>>> > zero page at block 21 at character 241
>>> > ERROR: index "pg_proc_proname_args_nsp_index" contains unexpected
>>> > zero page at block 16 at character 61
>>> > ERROR: index "pg_proc_proname_args_nsp_index" contains unexpected
>>> > zero page at block 17 at character 37
>>> >
>>> >
>>> > que surgieron porque los IDEs lo mostraban al hacer operaciones en la
>>> > base de datos, y como eran índices no me alarmé y se solucionaron
>>> > haciendo un reindex a las tablas pg_proc y pg_description.
>>> >
>>> > Pero luego checando los logs me aparecen, en varias ocaciones, estos
>>> > otros errores en otra base de datos dos días antes:
>>> >
>>> > ERROR: invalid page in block 1478644 of relation
>>> > pg_tblspc/117936/PG_10_201707211/117939/259612
>>> > ERROR: invalid page in block 1478651 of relation
>>> > pg_tblspc/117936/PG_10_201707211/117939/259612
>>> >
>>> > que pertenecen a la misma tabla:
>>> > pg_filenode_relation(117936,259612);
>>> > pg_filenode_relation
>>> > ----------------------
>>> > ph_smart.products
>>> > (1 row)
>>> >
>>> > Y surgieron luego de 1068 inserciones con errores de "duplicate key
>>> > value violates unique constraint" en otra tabla de la misma base de
>>> datos.
>>> >
>>> > También he notado que hay alrededor de 575 esquemas entre pg_temp y
>>> > pg_toast_temp, que se me hacen muchos y según lo que he leído esos los
>>> > crea y borra el mismo Postgres.
>>> >
>>> > El servidor está virtualizado en la nube, y el almacenamiento está
>>> > montado sobre disco SSD, tiene 8 cores y 32 GB de RAM.
>>> > Además el postgres cuenta con un sistema de backup incremental con
>>> > barman, montado en otro servidor con mucha más capacidad.
>>> > También existen 2 servidores iguales con las mismas características y
>>> > la misma carga de trabajo para el postgres, y no han mostrado errores
>>> > de corrupción en los logs.
>>> > Lo que quisiera saber si hay alguna forma para asegurarme que sea un
>>> > error del hardware o un bug, puesto que los demás servidores de
>>> > Potgres están en la misma nube y debo evaluar una posible migración en
>>> > el servicio de la nube o tal vez un cambio de versión en el Postgres.
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>>