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 (<hmira...@gmail.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.fo...@gmail.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@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 (< >> asotolo...@gmail.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. >>> > >>> > >>> > >>> > >>> >>> >>>
