Re: Centralizar Datos

From: Mariano Reingart <reingart(at)gmail(dot)com>
To: Xavier Emilio Guerra Rodriguez <tomrero(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, ayuda de postgres en español <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Centralizar Datos
Date: 2011-02-05 04:16:51
Message-ID: AANLkTinKzyCEXR0-SR7FuAfi-8j+T-KMS9KkjdJcvaGS@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

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 <tomrero(at)gmail(dot)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 <reingart(at)gmail(dot)com>
> escribió:
>>
>> 2011/1/27 Xavier Emilio Guerra Rodriguez <tomrero(at)gmail(dot)com>:
>> >
>> >
>> > El 27 de enero de 2011 15:55, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
>
>

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Jaime Casanova 2011-02-05 04:31:16 Re: uso de select (function()).* es mucho mas lento que select * from function()
Previous Message Jaime Casanova 2011-02-05 03:13:19 Re: Sobre usuarios de solo lectura en postgres