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

¿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?

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.

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.

¿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.