Conmutación por error y replicación de PostgreSQL

Estoy evaluando PostgreSQL 9.1 y tengo algunas preguntas relacionadas con la conmutación por error y los detalles de replicación.

Tengo pocos escenarios de prueba. El primero con un servidor maestro y pocos esclavos. En caso de que Master falle, quiero que uno de los Slaves se convierta en Master. Después de que el Maestro vuelva al estado normal, debe sincronizarse con otros servidores en el clúster (aplicar todos los cambios realizados mientras estaba inactivo) y reclamar el rol de Maestro o convertirse en Esclavo.

Los problemas que veo con PostgreSQL y el escenario actual son los siguientes.

1) No veo herramientas integradas para detectar la interrupción del servidor maestro. Leí que pgpool puede manejarlo y crear un archivo de activación, también leí que la gente usa Linux heartbeat o herramientas similares para esto. De acuerdo, puedo detectar la conmutación por error y asignar un nuevo maestro en el clúster. ¿Los otros esclavos entenderán que hay un nuevo maestro y deberían respaldarlo ahora?

2) No entiendo el procedimiento de recuperación. Las configuraciones de host maestro y esclavo son diferentes. Entonces, ¿tendré dos Maestros después de la falla del Maestro? ¿Cómo volverán a sincronizarse los servidores? Solo vi soluciones manuales como "transferir la carpeta de datos al servidor y reiniciarlo". Entonces, ¿cuál es la solución o la mejor práctica o al menos el principal clave aquí?

3) ¿Cómo debo manejar la interrupción del servidor en el lado del cliente? Cuando creo una conexión, especifico explícitamente la IP del servidor. ¿Debo desarrollar algún tipo de ConnectionManager que conozca mi estructura Maestro-Esclavo, envíe solicitudes solo al Maestro y, en caso de pérdida de conexión, cambie a servidores de respaldo y así sucesivamente? Leí que pgpool puede ser un punto de entrada para aplicaciones y administrar conexiones de manera correcta. ¿Es pgpool la única solución aquí? ¿Maneja bien el failover y el failback?

4) ¿Hay alguna solución (comercial también) para poder evitar copiar manualmente los datos, reconfigurar instancias de PostgreSQL y otras cosas que deberían hacerse a mano? Entonces, ¿qué tipo de configuración del clúster cuando todos están sincronizados, está claro quién es el Maestro y todo cambia automáticamente sin la atención del operador?

De acuerdo con estos hilos y artículos

Streaming de replicación y failover en PostgreSQL

Automatización de failover en PostgreSQL 9.1

http://denishjpatel.blogspot.com/2010/11/posibility-of-graceful-switchover.html

No existe una única solución totalmente automática para resolver estas preguntas. Estoy en lo cierto?

¡Gracias!

1. los esclavos no entenderán nuevo amo. deberías hacer eso manualmente.

2. sí, son diferentes y debe crear nuevos para el antiguo maestro. Sin embargo, el antiguo modo de espera continuará funcionando como maestro, pero debe configurar max_wal_senders en ese nodo. También debe establecer pg_hba.conf del nuevo maestro después de la conmutación por error. después de la conmutación por error (cuando los nodos cambian los roles maestro-> esclavo esclavo-> maestro), debe transferir nuevos archivos wal al nuevo directorio de datos de carpetas en espera que establezca en el archivo recovery.conf. o simplemente puedes usar rsync.

3. puede ser que puedas usar pgbouncer. de esta manera solo cambiará las direcciones del servidor pgbouncer a un nuevo maestro.

4. EnterpriseDB tiene algunas herramientas comerciales. puede ser usted puede verificarlos.

y finalmente sí tienes razón. No existe una única solución totalmente automática para resolver estas preguntas.