Pyreplica es multimaestro limitado porque al ser asincrónico, no hace resolución de conflictos automáticamente (si los puede llegar a detectar, pero se detendrá la sincronización en caso de claves duplicadas y similares). Igualmente para evitar conflictos en general alcanza con dividir logicamente las tablas (por ej., secuencias distintas en distintos servidores)
Disculpa no tuve tiempo de ver lo de los esquemas, es un ajuste bastante sencillo (pasar el nombre del esquema como primer argumento del trigger y luego agregarlo a los registros sql guardados en el log, ya lo he usado en algunas bases), en cuanto pueda lo subo y libero una nueva version, Sds Mariano Reingart http://www.sistemasagiles.com.ar http://reingart.blogspot.com 2011/2/3 Xavier Emilio Guerra Rodriguez <tomr...@gmail.com>: > Hola Mariano, en la documentacion de pyreplica dice que es multimaestro > limitado, > > Cual es el limite..? > > El 28 de enero de 2011 13:21, Mariano Reingart <reing...@gmail.com> > escribió: >> >> 2011/1/27 Xavier Emilio Guerra Rodriguez <tomr...@gmail.com>: >> > >> > >> > El 27 de enero de 2011 15:55, Alvaro Herrera <alvhe...@alvh.no-ip.org> >> > escribió: >> >> >> >> Excerpts from Xavier Guerra's message of jue ene 27 17:03:11 -0300 >> >> 2011: >> >> > Muchas Gracias alvaro es exactamente lo que necesito, el único >> >> > detalle >> >> > que >> >> > se me presenta es >> >> > que la base de datos tiene varios schema ya que según el tutorial la >> >> > idea es >> >> > crear schema por n clientes >> >> > que tengas no sé si estoy en lo cierto, y pues bueno ya lo veo muy >> >> > complejo. >> >> >> >> Sí, bueno, puedes ampliar la idea para tener N esquemas por cliente. >> >> Lo >> >> otro es que consideres si todas las tablas requieren escritura en los >> >> clientes o sólo algunas; en los casos que me ha tocado implementar (no >> >> muchos) había un conjunto de tablas "administrativas" que sólo son >> >> modificables en la central, y otras tablas que la central no toca y >> >> sólo son modificadas en los clientes. Estas últimas necesitan esquemas >> >> "federados", las primeras no. Con eso te puede simplificar el >> >> problema. >> >> >> >> Si es muy difícil, pues no lo hagas y dedícate a vender helados en la >> >> playa, que es mucho más sencillo. >> >> >> >> -- >> >> Álvaro Herrera -- Se vende casa en Ñuñoa: >> >> www.portalinmobiliario.com/993147 >> > >> > >> > Si en eso estaba pesando para simplificar y exactamente solo son algunas >> > tablas >> > que modifican los clientes. >> > >> > Muchas gracias por el apoyo >> > >> >> Para un caso similar desarrolle PyReplica, IMHO es más simple y un >> poco más flexible que slony y londiste, puede que te sirva: >> >> http://www.sistemasagiles.com.ar/trac/wiki/PyReplica >> >> Puede que tengas algunas dificultades con el manejo de esquemas, si >> necesitas algo avisame. >> >> Sds >> >> Mariano Reingart >> http://www.sistemasagiles.com.ar >> http://reingart.blogspot.com > > - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
