Streaming de replicación y failover en PostgreSQL

14

Estoy haciendo una prueba de concepto sobre la replicación de PostgreSQL. Después de la discusión en el foro, decidimos optar por la replicación de transmisión ya que el rendimiento es bueno en comparación con otras soluciones. PostgreSQL no proporciona conmutación por error automática para la replicación de transmisión. Podemos cambiar el esclavo a maestro usando un archivo de activación pero no es manejable. Por lo tanto, me gustaría una solución con conmutación por error automática y alta disponibilidad.

Hay diferentes soluciones disponibles:

  1. Repmgr
  2. Linux Heartbeat
  3. Pgpool-II (solo para conmutación por error automática)
  4. Cualquier otra herramienta en caso de que la hayas utilizado.

Mi pregunta es ¿qué solución se debe usar?

Saurabh
fuente

Respuestas:

8

En nuestra tienda seleccionamos repmgr y pgbouncer en lugar de pgpool. repmgr tiene algunas herramientas útiles para configurar y mantener el clúster de servidores de bases de datos replicados. En nuestro caso, 1 maestro y 2 esclavos (un failover y una prueba de rendimiento de lectura en vivo que puede convertirse en el failover del nuevo maestro). pgpool tiene problemas con los cambios en la configuración, en la mayoría de los casos debe reiniciar el servicio y, por lo tanto, tiene algún tiempo de inactividad. Este es un problema cuando necesita disponibilidad 24x7x365.

repmgrd (el demonio) ayuda a seleccionar el nuevo maestro después de una conmutación por error, realmente no quieres una situación de cerebro dividido. Tenemos una dirección IP virtual para la base de datos maestra, la base de datos que es maestra en ese momento. Cuando otro servidor se convierte en maestro, este es el único servidor que utiliza esta dirección. Cada servidor de base de datos también tiene su propia dirección IP para consultas de solo lectura.

repmgr es mantenido por los mismos tipos que crearon la replicación de transmisión en primer lugar, para que sepan de qué hablan. La versión 2.0 está a punto de ser lanzada.

¡Prepárese para la peor situación, haga algunas pruebas serias sacando algunos enchufes de alimentación y de red! Cuando algo sale mal, muchas otras cosas ya salieron mal y te morderán por la espalda cuando no puedas pagarlo.

La replicación es una cosa, una conmutación por error que funciona después de algunos problemas graves, es otra cosa.

Frank Heikens
fuente
1

Estamos usando dos soluciones diferentes en combinación al mismo tiempo ...

Pgpool-II para replicación sincrónica y Slony2 para replicación asincrónica (disparada).

El rendimiento es excelente.

usuario5701
fuente
Gracias por la respuesta ... En realidad estoy intentando Pgpool-II con replicación de transmisión. Está proporcionando la conmutación por error automática. Pero si voy a iniciar el nodo primario nuevamente, ¿pgpool-II puede comenzar como maestro nuevamente o como nodo en espera?
Saurabh
Por lo que sé, definitivamente no. Tendrá que hacer una recuperación manual del nodo primario. Nuestra configuración es un poco diferente. Es un entorno multimaestro y todos los nodos tienen los mismos derechos. Si un nodo se desincroniza, los equilibradores de carga rechazan redirigir clientes a este nodo.
user5701