Que tal Alvaro, mi idea es la siguiente [image: Imágenes integradas 1] Agregando el repmgr para hacer el failover de las réplicas de Master.
Está correcto esto? Saludos El 3 de octubre de 2014, 5:44, Álvaro Hernández Tortosa <[email protected]> escribió: > > On 01/10/14 22:27, marcelo mendoza wrote: > > Buenas tardes, cual sería una forma de colocar un pgbouncer en alta > disponibilidad? o sea dos nodos pgbouncer que se conecten a un Postgres que > se está replicando por medio de un repmgr? ya que si pongo sólo un > pgbouncer sería un unico punto de falla, como podría configurar las IP de > modo a que los dos pgbouncer balanceen las conexiones para mi Postgres? > > Saludos > > > Hola, Marcelo. No sé si estás preguntando sólo por HA o también por > balanceo de carga. Para lo primero, como te han comentado en el thread, > pgbouncer no está preparado. Necesitarás tener un pgbouncer en cada nodo de > aplicación (lo que suele funcionar bien), y que todos se conecten a las > bases de datos. Pero esta arquitectura no está exenta de problemas: > > - Puede requerir un alto número final (agregado de todos los > app+pgbouncer) de conexiones a la base de datos, lo que puede degradar > mucho su rendimiento. > - El diseño de max_connections es difícil (porque el número de > app+pgbouncer pueden crecer "elásticamente") > - No tiene balanceo de carga > - Es complejo que cada pgbouncer debe configurar conexiones a todas las > bases de datos del cluster (maesto y esclavos) > > Alternativamente, puedes meter haproxy en la ecuación, que te da > balanceo de carga y te va a permitir reducir el número global de > conexiones. Puedes tener por ejemplo app+pgbouncer y dichos pgbouncer > conectan a haproxy, que balancea la carga. Esto sólo aplica a esclavos, > obviamente, pues sólo hay un maestro. Pero me imagino esto ya lo tienes > resuelto a nivel de app (distingues entre rw y ro). Es fundamental en este > caso que en la gestión de la promoción de un esclavo a maestro por la caída > de éste, se actualice la configuración de haproxy (basta con un reload). > Pan comido (ironía). > > Suerte y saludos, > > Álvaro > > > > > > El 25 de septiembre de 2014, 20:57, Álvaro Hernández Tortosa < > [email protected]> escribió: > >> >> On 24/09/14 05:02, Alvaro Herrera wrote: >> >>> Jaime Casanova escribió: >>> >>>> 2014-09-23 9:00 GMT-05:00 marcelo mendoza <[email protected]>: >>>> >>>>> Muchas gracias por su respuesta, estoy leyendo que el repmgr tiene >>>>> failover >>>>> automático también, alguien ya lo probó? En comparación con pgpool cual >>>>> proyecto es mas estable? >>>>> >>>>> Empieza por eliminar de tu cabeza la idea de usar RHCS, al menos si no >>>> quieres tener dolores de cabeza. RHCS no usa replicación sino >>>> almacenamiento compartido lo que significa que si tu storage falla te >>>> fregaste. >>>> >>> Jaime está siendo amable. RHCS no sólo "te fregaste si el storage >>> falla"; en algunos clientes (sí, más de uno) hemos visto que el RHCS >>> activamente corrompe datos. Yo no conozco la tecnología pero la >>> evidencia incontestablemente indica que el cluster por alguna razón en >>> ciertas circunstancias levanta los dos servidores simultáneamente, lo >>> cual corrompe los datos en muy poco tiempo. >>> >>> >> Por si sirve de algo, nosotros hemos realizado una instalación hace >> unos meses de un cluster activo-pasivo con RHCS (petición expresa del >> cliente) y la verdad ha funcionado a las mil maravillas. Hemos realizado >> pruebas muy agresivas de failover y failback sin el menor de los problemas. >> Lleva en producción desde entonces. Es bien cierto que es costoso montarlo >> bien, y que dependiendo de qué tecnología de disco compartido puede tener >> más riesgos. En el caso que montamos, se usaba iSCSI con multipath y esta >> propia tecnología ya impide (independientemente de RHCS) que se use el >> disco por dos máquinas simultáneamente, por lo que no debería haber >> corrupción de datos. >> >> Obviamente, es una solución con ventajas: >> >> - El failover es rapidísimo (pocos segundos) >> - Nunca hay pérdida de datos (por que se caiga el maestro) >> - Es transparente para los clientes (los servidores tienen una IP virtual >> y el cliente no se entera del cambio, salvo las conexiones abiertas, claro, >> pero esto es inevitable siempre) >> >> e inconvenientes: >> >> - Sólo dos nodos, sólo uno activo >> - Más complejo y más partes móviles >> - Traslada el SPOF al almacenamiento, si bien lograr almacenamiento >> suficientemente redundado (a nivel de hw) no es complejo, sino algo muy >> habitual a día de hoy >> >> En todo caso, no entiendo la combinación de RHCS con pgpool. Si >> alguien monitoriza es, precisamente, RHCS y no pgpool. >> >> Espero que sirva la información. Saludos, >> >> Álvaro >> >> >> >> -- >> Álvaro Hernández Tortosa >> >> >> ----------- >> 8Kdata >> >> >> - >> Enviado a la lista de correo pgsql-es-ayuda ( >> [email protected]) >> Para cambiar tu suscripción: >> http://www.postgresql.org/mailpref/pgsql-es-ayuda >> > > > > -- > Marcelo Mendoza > (0983) 383-752 > > > -- > Álvaro Hernández Tortosa > > > ----------- > 8Kdata > > > -- Marcelo Mendoza (0983) 383-752
