El 12/04/2011 16:15, Alvaro Herrera escribió:
Excerpts from Alejandro Brust at federacion's message of mar abr 12 16:06:06
-0300 2011:
pero por la mañana me encuentro con el server esclavo parado con error de:
"FATAL invalid page header in block 1532 of relation
base/308876290/370614752"
"CONTEXT xlog redo vacuum: rel 1663/308876290/370614752; blk 1889,
lastBlockVacuuned 1525"
Todo a las 24:00hs (horas despues de probar la replicacion) pongo los
horarios porque a las 24hs yo realizo en el master
un vacuumdb --all -analyze todos los dias (que me daba error y no lo
terminaba...con esto empezo el primer post).
Mi pregunta es:
Tomando en cuenta que es muy dificil que dos servidores DL380 nuevos
anden mal,
Ehm, ¿por qué es tan difícil que anden mal? ¿Has hecho otras pruebas
para descartar problemas de hardware? Si no entiendo mal, es tercera
vez que uno de estos servidores se comporta de manera errática.
La verdad es que en el server que estaba como esclavo nunca tuve ningún
error,
los puse a replicar hace 5 meses(sin suspender) y solo el que esta como
maestro me dio 2 veces el mismo error (invalid...)
y ahora al hacer una copia base con pg_start_backup me lo tiro en el
esclavo.
En cuanto a las pruebas, al instalarlos les corri un varias veces fsck,
hicimos las copias de los backups (carpeta entera del dir "data"
(50Gb)), copiamos los archivos del pg_dump, los restauramos sin
problemas, las dos veces que tiro el error realice una verificación del
disco (fsck) y copie el directorio sin problemas, continuamente estamos
restaurando bases y tablas en estos discos sin problemas tampoco.
Hoy que tengo el esclavo fuera de linea le mande a la gente de HP el
reporte que genera el server (controladora y los 8 discos en raid 1+0)
espero respuesta pronto (versiones de firmware, etc).
A mi me sorprenderia mucho Alvaro si es un error de los servidores HP
(es mas no sabría q hacer con ellos.... ja!)
en cuanto al
"FATAL: invalid page header in block 1532 of relation base/308876290/370614752"
"CONTEXT: xlog redo vacuum: rel 1663/308876290/370614752; blk
1889,lastBlockVacuuned 1525"
esto no tiene ninguna vinculación con streaming replication y el vacuundb en el
master? es justo a la hora que el master esta haciendo el vacuumdb...
muchas graciasnuevamente
