On 03/10/14 15:14, marcelo mendoza wrote:
Que tal Alvaro, mi idea es la siguiente
Imágenes integradas 1
Agregando el repmgr para hacer el failover de las réplicas de Master.
Está correcto esto?
Yo la verdad creo que los pgbouncer tienen mucho mejor efecto
cuando están en la misma máquina que el app server, porque de lo
contrario no evitas el coste de establecimiento de conexión entre app
server y pgbouncer.
Saludos,
Álvaro
Saludos
El 3 de octubre de 2014, 5:44, Álvaro Hernández Tortosa
<[email protected] <mailto:[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] <mailto:[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]
<mailto:[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]
<mailto:[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
--
Álvaro Hernández Tortosa
-----------
8Kdata
