Re: Replicacion Multimaster y Hot Standby

2012/6/21 Eduardo Morras <nec556(at)retena(dot)com>:
> At 19:41 20/06/2012, you wrote:
>>
>> 2012/6/20 Eduardo Morras <nec556(at)retena(dot)com>:
>> >
>> > Muy buenas, una duda sobre Replicacion Multimaster y Hot Standby.
>> > Supongamos
>> > que tengo 1 servidor con pgpoolII manejando 2 servidores Maestros donde
>> > van
>> > a parar todas las escrituras y un bucardo o similar comprobando que los
>> > maestros tienen todos la misma informacion.
>> >
>>
>> solo por curiosidad como esta configurado ese pgpool? hasta donde se
>> lo que va a pasar si lo tienes en balanceo de carga es que las
>> escrituras van a parar a un servidor y las lecturas al otro... claro
>> que si tienes cosas como "SELECT funcion_que_escribe()" entonces si
>> tendrias un balanceo de escrituras pero solo de esas consultas, la
>> otra ventaja que le veo es que no necesitas preocuparte de las bobadas
>> que pudiera hacer el pgpool.
>
>
> En realidad son mas servidores, estos 2 son para la escritura y otros 2 para
> lectura. Aunque de momento tienen poca carga por estar en desarrollo, cuando
> entre en produccion espero poder escalar bien las lecturas. O sea, quiero
> que si falla un servidor de escritura el otro siga funcionando (HA/FailOver)
> y que las lecturas sean lo mas rapidas posibles (HP). Aqui el unico punto
> que me puede fallar es el pgpool, por lo que probare a tenerlo en HA tambien
> con otro en standby.
>

y en verdad necesitas eso o solo estas queriendo prever una situacion
que quiza nunca llegue?

>
>> PS: actualmente se esta trabajando en tener replicacion multi master
>> integrado. aunque probablemente tome algun tiempo antes de tener algo
>> de esto disponible.
>
>
> Espero, por que actualmente estoy limitado, ya que no puedo usar triggers
> que hagan modificaciones a los datos (espero que bucardo/slony u otro me
> ayuden en esto) ni usar indices de tipo hash (muchas consultas son de '=').
>

esto no tiene nada que ver con la replicacion multi master, en
postgres los indices hash no son tan eficientes como los btree. no los
uses

>
>> PS2: lo que quieres hacer podria solucionarse con plproxy
>> (http://wiki.postgresql.org/wiki/PL/Proxy) si es que tienes las
>> escrituras a traves de funciones
>
>
> Intento que sea lo mas transparente posible para no tener que modificar las
> aplicaciones. Cambiar los INSERT/UPDATE/DELETE por funciones en cada tabla
> obligaria a rehacer parte del codigo.
>

no, no es transparente pero soluciona todo el problema de escalabilidad de golpe

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación