Re: Corrupción de datos

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 <mailto: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,
>
> --
>
> daniel.bojorge
> 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 <mailto: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.
> >
> >
> >
> >
>
>