desarrollo deaAplicacion grande

[Alvaro Herrera]

Ricardo Mun~oz A. escribió:
> Alvaro Herrera wrote:
>> 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.
>
> cierto. pero depende del modelo y la aplicacion si es que en algun momento 
> se puede producir un conflicto... por algo los mismos desarrolladores de 
> Slony-I indican que sirve cuando todos los nodos estan disponibles todo el 
> tiempo...

Estas confundiendo una limitacion de arquitectura con una recomendación.
Slony-I funciona sin problemas cuando hay fallas de red, aunque la cola
de eventos va a ocupar espacio en disco.  Pero eso es totalmente
independiente de una hipotetica resolucion de conflictos, que no existe
porque es innecesaria.  Es innecesaria debido a que Slony-I es una
solucion maestro-esclavo, por lo tanto es imposible que existan
conflictos debido a que un servidor esclavo no puede escribir en la
tabla para la cual es esclavo.


> volviendo al mail original, le recomendarias a Graciela el uso de Postgres 
> + Slony-I?

Depende mucho de la naturaleza de la aplicacion.  Lo que yo intentaria
hacer seria tener copias esclavas de la base de dato en cada una de las
sucursales, de solo lectura (con Slony-I); y que las escrituras vayan a
la base de datos central.  De este modo no se notaria la lentitud del
enlace en las consultas de solo lectura (puesto que son locales a la
sucursal), y se requeriria contactar al central solamente para las
escrituras.

De esa forma, te ahorras todo el problema de la resolucion de conflictos
y de replicacion multimaestro.  El inconveniente es que cuando se caiga
la conexion sucursal-servidor, no podrias escribir (pero ojo, que eso
sucede en casi todos los sistemas multimaestro, incluso los
comerciales).

-- 
Alvaro Herrera                        http://www.advogato.org/person/alvherre
"On the other flipper, one wrong move and we're Fatal Exceptions"
(T.U.X.: Term Unit X  - http://www.thelinuxreview.com/TUX/)