Si el servidor primario falla, el servidor standby debe comenzar los procedimientos de conmutación por error.
Si el servidor standby falla, no es necesario realizar ninguna conmutación por error. Si el servidor standby se puede reiniciar, incluso algún tiempo después, el proceso de recuperación también se puede reiniciar inmediatamente, aprovechando la recuperación reiniciable. Si el servidor standby no se puede reiniciar, se debe crear una nueva instancia completa de servidor standby.
Si el servidor primario falla y el servidor standby se convierte en el nuevo primario, y luego el antiguo primario se reinicia, debes tener un mecanismo para informar al antiguo primario de que ya no es el primario. Esto se conoce a veces como STONITH (Shoot The Other Node In The Head), que es necesario para evitar situaciones en las que ambos sistemas crean que son el primario, lo que conducirá a la confusión y, en última instancia, a la pérdida de datos.
Muchos sistemas de conmutación por error utilizan solo dos sistemas, el primario y el standby, conectados por algún tipo de mecanismo de latido (heartbeat) para verificar continuamente la conectividad entre los dos y la viabilidad del primario. También es posible utilizar un tercer sistema (llamado servidor testigo o witness server) para evitar algunos casos de conmutación por error inapropiada, pero la complejidad adicional podría no valer la pena a menos que se configure con suficiente cuidado y pruebas rigurosas.
PostgreSQL no proporciona el software del sistema requerido para identificar una falla en el primario y notificar al servidor de base de datos standby. Existen muchas herramientas de este tipo que están bien integradas con los servicios del sistema operativo necesarios para una conmutación por error exitosa, como la migración de direcciones IP.
Una vez que se produce la conmutación por error al standby, solo queda un único servidor en funcionamiento. Esto se conoce como un estado degenerado. El antiguo standby es ahora el primario, pero el antiguo primario está caído y podría permanecer caído. Para volver al funcionamiento normal, se debe volver a crear un servidor standby, ya sea en el antiguo sistema primario cuando se recupere, o en un tercer sistema, posiblemente nuevo. La utilidad pg_rewind se puede utilizar para acelerar este proceso en clústeres grandes. Una vez completado, se puede considerar que el primario y el standby han intercambiado sus roles. Algunas personas optan por utilizar un tercer servidor para proporcionar respaldo al nuevo primario hasta que se vuelva a crear el nuevo servidor standby, aunque está claro que esto complica la configuración del sistema y los procesos operativos.
Por lo tanto, cambiar del servidor primario al standby puede ser rápido, pero requiere algún tiempo para volver a preparar el clúster de conmutación por error. El cambio regular de primario a standby es útil, ya que permite un tiempo de inactividad regular en cada sistema para el mantenimiento. Esto también sirve como prueba del mecanismo de conmutación por error para garantizar que realmente funcionará cuando lo necesites. Se aconseja disponer de procedimientos de administración escritos.
Si has optado por la sincronización de slots de replicación lógica (consulta Section 47.2.3), se recomienda verificar, antes de cambiar al servidor standby, si los slots lógicos sincronizados en el servidor standby están listos para la conmutación por error. Esto se puede hacer siguiendo los pasos descritos en la Section 29.3.
Para activar la conmutación por error de un servidor standby de envío de registros, ejecuta pg_ctl promote o llama a pg_promote(). Si estás configurando servidores de informes que solo se utilizan para descargar consultas de solo lectura del primario, no para propósitos de alta disponibilidad, no necesitas promoverlos.