2012/6/21 Eduardo Morras <nec...@retena.com>: > At 19:41 20/06/2012, you wrote: >> >> 2012/6/20 Eduardo Morras <nec...@retena.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 - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
