Automatización de conmutación por error en PostgreSQL 9.1

18

¿Cómo se configuran dos servidores idénticos para la conmutación por error automática en PostgreSQL 9.1?

OS

Centos 5
PostgreSQL 9.1 compilado desde la fuente
La cuenta de usuario de postgres existe en ambas máquinas y tiene una clave ssh sin contraseña para conectarse a ambas máquinas.

Mi configuración actual:

Configuración del servidor maestro:

postgresql.conf:

listen_address = '*'
wal_level = hot_standby
max_wal_senders = 3
checkpoint_segments = 16    
wal_keep_segments = 8 
archive_mode = on    
archive_command = 'cp "%p" /opt/pgsql91/archive/"%f"'

pg_hba.conf:

 host  replication   all   10.0.66.1/32      trust
 host  replication   all   10.0.66.2/32      trust

Servidor en espera

postgresql.conf y pg_hba.conf son idénticos a los configurados en el servidor maestro.

recovery.conf:

 standby_mode = 'on'
 primary_conninfo = 'host=10.0.66.1'
 trigger_file = '/opt/pgsql91/data/trigger.txt'

Gracias a hzRoot, ahora entiendo cómo cambiar el servidor del modo de espera al maestro.

Usando los siguientes comandos, puedo sincronizar el nuevo esclavo con el nuevo maestro y luego obtener una copia de seguridad de replicación y ejecutarla.

En el nuevo maestro (10.0.66.2)

  1. su - postgres
  2. toque trigger.txt en / opt / pgsql91 / data /
  3. recovery.conf se convierte en recovery.done
  4. psql -c "; SELECCIONAR pg_start_backup ('copia de seguridad', verdadero)";
  5. rsync -a -v -e ssh / opt / pgsql91 / data / 10.0.66.1:/opt/pgsql91/data/ --exclude postmaster.pid
  6. psql -c "; SELECCIONAR pg_stop_backup ()";

Sobre el nuevo esclavo (10.0.66.1)

  1. cree el recovery.conf: cp recovery.done para recovery.conf
  2. vi recovery.conf cambie la dirección IP: primary_conninfo = 'host = 10.0.66.2'
  3. iniciar postgresql

Entonces mis preguntas son ahora:

  1. ¿Es esta la forma correcta de cambiar de roles?
  2. ¿Alguien ha automatizado este proceso? De ser así, ¿qué hizo?
  3. Si la replicación sincrónica está habilitada, noté que el nuevo servidor maestro no confirmará ninguna transacción porque está esperando que el esclavo responda. Sin embargo, no hay esclavo porque el otro servidor, el viejo maestro, está inactivo. ¿Es correcto o necesito deshabilitar temporalmente la replicación síncrona mientras el nuevo esclavo está inactivo?
postgresql failover Craig Efrein
fuente
1. sí correcto 2. puede ser mejor no automatizar ese proceso. 3. entonces necesita 2 esclavos y 1 maestro al menos. porque como dijiste sincronizar. La replicación necesita al menos 2 nodos para impulsar la sincronización de confirmaciones. si solo hay un nodo maestro, no podrá comprometerse ..
sftsz
los pasos 4, 5 y 6 no son necesarios en el nuevo maestro porque, para empezar, está replicando. En segundo lugar, ¿qué pasaría si el maestro muriera y estuviera fuera de línea? No podría conectarse a él. Los pasos 4,5 y 6 generalmente se realizan en un nuevo nodo esclavo que se une al grupo de replicación.
Eric
@Eric mientras jugaba con esto, se requieren los pasos 4,5,6 para devolver el antiguo maestro al estado de trabajo. Al hacer que el primario en espera sea nuevo, inmediatamente se hace una nueva entrada de WAL, por lo que ahora está 1 entrada por delante del viejo maestro. Iniciar el viejo maestro en el modo de espera me arrojó errores, así que tuve que hacer los pasos 4,5,6 en el viejo maestro para sincronizarlo con el nuevo maestro (usando pg_basebackup, que puede transmitir todo el xlog desde el nuevo maestro - reemplaza los pasos 4,5,6 en postgres> = 9.1 creo). ¿Estoy en lo correcto o hice algo mal y esto no debería ser necesario?
Dalibor Filus

Respuestas:

8

Echa un vistazo a repmrg :

repmgr es un conjunto de herramientas de código abierto que ayuda a los administradores de sistemas y administradores de bases de datos a administrar un grupo de bases de datos PostgreSQL.

Al aprovechar la capacidad Hot Standby introducida en PostgreSQL 9, repmgr simplifica enormemente el proceso de configuración y administración de bases de datos con requisitos de alta disponibilidad y escalabilidad.

repmgr simplifica la administración y la gestión diaria, mejora la productividad y reduce los costos generales de un clúster PostgreSQL al:

  • monitorear el proceso de replicación; permitiendo que los DBA emitan altos
  • operaciones de disponibilidad como cambios y fallas.

Hace dos cosas:

  1. repmgr: programa de comando que realiza tareas en su clúster y luego sale
  2. repmgrd: daemon de administración y monitoreo que vigila el clúster y puede automatizar acciones remotas.

Para la conmutación por error automática, repmgrd hace el truco y no es un SPOF en su red, como pgPool. Sin embargo, aún es importante monitorear todos los demonios y recuperarlos después de la falla.

La versión 2.0 está a punto de ser lanzada, incluidos los RPM.

Frank Heikens
fuente
Hola Frank, gracias por tu respuesta. No he oído hablar de repmrg y definitivamente lo intentaré.
Craig Efrein
Hola de nuevo Frank, gracias por la respuesta, fue exactamente lo que estaba buscando. Finalmente pude probarlo hoy.
Craig Efrein
4

en su archivo recovery.conf debe agregar una línea que le indique a postgres que realice la conmutación por error de maestro a esclavo. deberías agregar

trigger_file = '/any/file/to/trigger'

cuando crea este archivo en la ruta dada. los nodos cambiarán. (el archivo no incluye nada, es solo un disparador)

puede encontrar información adicional sobre la replicación de transmisión

Por otro lado, es posible que sea posible crearlo automáticamente con algunos trucos, pero usar herramientas de monitoreo y hacer una falla en el manual será mejor.

sftsz
fuente
Gracias por la respuesta. Pueden pasar un par de días antes de que pueda probarlo, pero definitivamente me pondré en contacto con usted.
Craig Efrein
Voy a darle +1 para la respuesta trigger_file que me ha ayudado a simplificar en gran medida el proceso. No se trata de la respuesta completa, sino de cómo automatizar completamente el proceso. Otra cosa que he notado es que mientras el maestro estaba inactivo, las transacciones no se completaban porque estaba esperando que el maestro lo reconociera. Esto se resolvió mediante el uso de la replicación asincrónica
Craig Efrein el
Eso es bastante asombroso. Tengo muchas críticas sobre la falta de flexibilidad en la implementación de replicación de PostgreSQL, pero esta es una forma sencilla y excelente de manejar la conmutación por error.
Aaron Brown
1
Sin embargo, asume el rol de maestro incluso cuando el maestro mismo todavía se está ejecutando (por lo que tiene dos maestros). Esto no está automatizado por postgres en sí.
Dalibor Filus
0

¿Alguien ha considerado usar pgpool-II para esto?

http://pgpool.projects.postgresql.org/contrib_docs/simple_sr_setting/index.html

Estoy configurando la replicación para PostgreSQL. Parece que la parte difícil sucede cuando el viejo maestro regresa.

Por lo que he leído, pgpool parece que puede automatizar la mayor parte de eso. Sin embargo, no estoy seguro de si aprovecha las características de replicación ya presentes en PostgreSQL 9.1.

Paulo SantAnna
fuente
1
pgPool es un punto único de falla, pierdes todo cuando se cae.
Frank Heikens
1
Gracias por su respuesta. He probado PGPool II con resultados mixtos tanto en CentOS como en Debian y finalmente me di por vencido.
Craig Efrein
1
¿Por qué no usar pgpool II con HAproxy? Con un latido del corazón y la escucha flotante de ip?
mikiemorales
Solo como referencia histórica, pgpool-ii tampoco se ejecuta actualmente en Windows.
Tommed