Re: vacuumdb excluir tablas

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