2009/5/15 Luis D. García <[email protected]>: > > 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 -- TIP 8: explain analyze es tu amigo
