PostgreSQL Failover: ¿qué herramientas debo usar?

Aquí está el escenario:

Hay dos máquinas que ejecutan CentOS 6.2: machine0 y machine1

Ambos tienen instalado PostgreSQL 9.1.

Uno de ellos debe estar activo, como sistema maestro y mediante la replicación de transmisión asíncrona de la otra máquina, el modo de espera debe copiar los cambios a la base de datos desde el sistema maestro.

Asumiendo que machine0 es el maestro y machine1 es el modo de espera al principio.

Si el maestro (por ejemplo, machine0) falla (el fallo aquí significa que el servidor postgresql se bloquea), el modo de espera debería tomar el control del maestro y convertirse en el nuevo maestro.

machine1, el nuevo maestro maneja todas las operaciones de la base de datos y cuando el servidor postgresql en machine0 vuelve a estar en línea, debería volverse en espera, comenzar a sincronizar desde el punto en que perdió contacto con machine1 y copiar todos los cambios a la base de datos y permanecer en modo de espera.

Cuando la máquina1 falla, todo el ciclo se repite.

Cuando el modo de espera falla y vuelve a estar en línea, debe comenzar a leer del maestro y sincronizar los datos.

Estoy confundido sobre cuáles son las herramientas que necesito usar para configurar esto, ya que entiendo que PostgreSQL no viene con conmutación por error de forma predeterminada.

Si alguien puede vincularme a hilos / páginas que describan cómo hacer lo que estoy intentando, estaré realmente agradecido.

Si está interesado en la replicación y conmutación por error de base de datos síncrona, tengo una sugerencia. Podrías considerar usar dos herramientas:

• DRBD (dispositivo de bloque replicado en disco) proporciona replicación a nivel de disco (sincrónico) entre discos en dos servidores diferentes. Los cambios en el disco se replican a través de la red. Es mejor usar un cable cruzado en eth2 para las NIC que usan el netblock 192.168.xx.

• ucarp permite la administración de DBVIP y la conmutación por error entre dos servidores diferentes.

Puede usarlos en conjunto de la siguiente manera:

• DBServer1 tiene IP 10.1.2.30
• DBServer2 tiene IP 10.1.2.40
• DB VIP es 10.1.2.70

Configure ucarp en dos servidores diferentes de tal manera que cada instancia de ucarp se comunique con la otra a través de una ID de enrutador virtual

DBServer1 tendrá

/usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.30 -b 3 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B

DBServer2 tendrá

/usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.40 -b 4 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B

¿Cuál es la razón -b (transmisiones) es 3 en un servidor y 4 en el otro? En caso de que ambos servidores se reinicien, el servidor con el -b más bajo traerá ucarp primero. En cuanto a -r, esa es la relación muerta. Por lo tanto, DBServer1 aparecerá en 15 segundos (3X5) y DBServer2 aparecerá en 20 segundos (4X5).

Digamos que DBServer1 se bloquea. ucarp en DBServer2 verificará durante 20 segundos un apretón de manos para ucarp en DBServer1. Si no se detecta nada, el script vip-up.sh en DBServer2 tomará el control de DBVIP.

OK, todo esto es solo para failover y administración de DBVIP. ¿Qué pasa con la base de datos PostgreSQL? Sorprendentemente, PostgreSQL solo se ejecuta en un servidor a la vez. Quien tenga el DBVIP debe tener DRBD en estado primario. Esto se relaciona nuevamente con el script vip-up. ¿Cómo lo escribes?

Aquí está el script /usr/local/sbin/vip-down.sh (conceptual)

#! /bin/sh
exec 2> /dev/null
/sbin/drbdadm disconnect drbd0
/sbin/drbdadm  primary drbd0 &&
/bin/mount postgres-data-folder /mnt/drbd0
/sbin/ip addr add 10.1.2.70/24 dev eth2
/sbin/service postgres start &&
/usr/local/sbin/vipmon.sh &
touch /tmp/vip-up

Aquí está el script /usr/local/sbin/vip-down.sh (conceptual)

#! /bin/sh
exec 2> /dev/null
/sbin/service postgres stop
/bin/umount -l  /dev/drbd0
/sbin/drbdadm secondary drbd0
/sbin/ip addr del 10.1.2.70/24 dev eth2
/bin/rm /tmp/vip-up
/usr/bin/killall -9 ucarp
/usr/local/sbin/vip-down.sh
kill `ps auxww | grep vipmon | awk '{print $2}'`

Todo lo que necesita hacer es configurar pg_hba.conf para asegurarse de que todos los usuarios accedan a través de 10.1.2.70

Esencialmente, vip-up realiza esta secuencia

• Tener DRBD ir primaria
• Montar la carpeta de datos de Postgres en / dev / drbd0
• Inicio postgres
• iniciar el proceso vipmon

Por el contrario, vip-down realiza esta secuencia

• Cierre postgres
• unount / dev / drbd0
• Que DRBD pase a secundaria

¿Qué pasa con vipmon.sh? Puede escribir ese script para verificar, en un bucle indefinido, el estado de postgres (se está ejecutando), verificar el dispositivo DRBD (¿aún puede escribir en la carpeta de datos de publicaciones)

Con esta configuración, tiene postgres en DRBD Primary y una copia a nivel de disco de la carpeta de datos de postgres en el otro DBServer (el DRBD Secondary). postgres no se está ejecutando en DRBD Secondary.

Cuando ocurre una conmutación por error, solo necesita tiempo para que ucarp detecte si es seguro montar los datos de postgres, iniciar postgres y activar el script vipmon.

Lo bueno de esta configuración es que, en caso de una conmutación por error, el DBServer que se convierte en DRBD primario debe tener una copia del servidor al 100% del nivel del disco del que falló. Por lo tanto, comenzar postgres debería nivelarlo en un estado consistente. Los registros de transacciones (en pg_xlog) deben estar en contacto (menos la intermitencia debido a la conmutación por error)

Espero que estas sugerencias ayuden. Aunque soy un DBA MySQL, uso MySQL y DRBD en la empresa de alojamiento web de mi empleador de manera regular. Instalé MySQL / DRBD de la manera mencionada anteriormente. Lo hice una vez para un cliente que usa PostgreSQL / DRBD. Funciona muy bien Es de código abierto. Solo necesita realizar la debida diligencia para aprender DRBD y ucarp. Esto incluiría volver a conectar DRBD después de una conmutación por error, manejar un escenario de cerebro dividido en el que ambos servidores DB se vuelven primarios y cosas como estas.