desarrollo deaAplicacion grande

[Alvaro Herrera]

Ricardo Mun~oz A. escribió:
> Alvaro Herrera wrote:

>> Bueno, lo que hace Slony-I es dejar una cola de operaciones en el
>> maestro, que se va vaciando a medida que los esclavos las reciben y
>> aplican.  Si se cae la conexion, la cola empieza a crecer hasta que la
>> conexion vuelve.
>>
>> En realidad ese es el modelo de operacion normal de Slony-I: todas las
>> operaciones pasan siempre por una cola.  Lo que pasa en condiciones
>> normales es que la cola se transmite en forma "instantanea".
>
> claro, por lo mismo si hay operaciones encoladas que modifican datos en la 
> BD de una sucursal sin enlace, y esos mismos datos fueron modificados en la 
> BD "central" podria quedar la c*!#$...

No, porque el central no puede modificar tablas para las que la sucursal
es maestra, y viceversa.

Es por ese motivo que Slony-I es maestro-esclavo y no multimaestro: no
hay manejo de conflictos.

Hay soluciones multimaestro como Postgres-R: http://postgres-r.org/ pero
es un problema muchisimo mas complejo de lo que parece; por ej. MySQL
Cluster tiene limitaciones y problemas que cuando las miras te das
cuenta de lo absurdas que son y de lo limitado de los casos en que se
pueden aplicar.  Las soluciones comerciales como Oracle RAC tambien
tienen limitaciones super raras que obviamente no te cuentan en los
folletos de marketing.

La unica diferencia entre las soluciones de replicacion de Postgres
versus otros gestores de BDs es que Postgres es honesto respecto de las
limitaciones.  Los desarrolladores de Postgres no estan interesados en
soluciones parciales que funcionan la mitad del tiempo; si quieres cosas
asi, puedes hacerlas perfectamente tu mismo.

-- 
Alvaro Herrera                 http://www.amazon.com/gp/registry/DXLWNGRJD34J
"Ciencias políticas es la ciencia de entender por qué
 los políticos actúan como lo hacen"  (netfunny.com)