Re: Cache lookup failed for type - Slony-I

2009/5/15 Luis D. García <ldgarc(at)gmail(dot)com>:
>
> Por el IRC #postgresql estuve conversando con alguien y lo primero que me
> preguntó fue si en algún momento había creado/dropeado/recreado el esquema
> de replicación generado por el Slony, y de hecho así fue, ya que se hicieron
> algunos cambios sobre la estructura de la BD y se quería generar toda la
> replicación de nuevo desde cero. Al parecer al definir los esquemas y
> levantar el Slony, se definen algunos "prepared queries", los cuales podrían
> fallar debido a que surgirían cambios en los OIDs de las tablas a replicar o
> algo similar.
>

ah! ok. cuando hagas cambios a la estructura de la base una vez
iniciada la replicacion debes hacerlo usando el comando de slony
"EXECUTE SCRIPT" (http://www.slony.info/documentation/ddlchanges.html)

lo malo es que te va a bloquear todo el SET hasta terminar pero en
cambio te asegura que no tengas estos problemas... una solucion que a
veces funciona es hacer las alteraciones en la replica primero y luego
en el real

> Otra cosa que nos pareció extraño, es que la replicación del maestro al
> esclavo se hizo a medias, es decir, teníamos casi 25Gb de información en el
> nodo maestro y cerca de 16Gb en el esclavo al momento de presentarse los
> fallos.
>

claro una vez que no pudo replicar una parte se quedo atascado hasta
poder replicar esa parte y ya luego se ponia al dia con el resto

> Después de discutir esto por un tiempo, opté por recrear el esquema de
> replicación con un nuevo nombre para el Cluster, a ver si de esta manera se
> evitaba el error, y de hecho hasta ahora así ha sido. Reconfiguré el Slony
> con un nuevo CLUSTER NAME y recreé todo desde cero y hasta ahora no hemos
> tenido problemas con ello.
>

tambien funciona ;)

>
>>
>> >
>> > LOG:  archive command failed with exit code 1
>> > DETAIL:  The failed archive command was: cp -i
>> > pg_xlog/000000010000003200000050
>> > /var/lib/pgsql/logs/wal/000000010000003200000050
>> > WARNING:  transaction log file "000000010000003200000050" could not be
>> > archived: too many failures
>> > LOG:  unexpected EOF on client connection
>> >
>>
>> no. esto es un intento de tener los WAL archivados pero el comando co
>> no pudo mover el archivo... quiza falta de permisos en la carpeta wal?
>
> Eso mismo estuve viendo luego, al parecer lo que sucedió es que en algún
> punto el administrador del servidor optó por eliminar todos los logs
> ubicados en pg_xlog y el archive_command de los WALs se quedó asociado a los
> archivos anteriores, de hecho, resulta que desde hace ya algún tiempo los
> WALs no se están moviendo a la carpeta indicada y están almacenándose
> únicamente sobre pg_xlog.
>

ah! nunca borren lo que esta dentro de pg_xlog!
mmm... bueno, que les pague la pizza a todos de castigo :)

>
>
> Bueno hasta ahora tengo el mecanismo de replicación configurado con un nuevo
> nombre y funcionando en producción, se han replicado 25Gb de 29Gb que son en
> total y no ha surgido problema alguno.
>

esperemos que siga asi

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157