Re: Replicacion Multimaster y Hot Standby

At 14:55 21/06/2012, you wrote:

> > 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?

Tiene que funcionar 24x7 y desconozco el nivel de carga en
produccion, ya que depende del numero de clientes conectado simultaneamente.

> >> 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

No, el tema de indices hash viene limitado por usar
HotSatandby/StreamingReplication, los indices hash dependen de cada
servidor y cada vez que haya un insert/update/delete hay que
reindexar en el slave. No sabia que ademas tuvieran problemas de eficiencia.

> >> 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

... Voy a estudiar esta opcion mas a fondo

Un saludo y gracias