El siguiente instructivo tiene como finalidad, mostrar los pasos básicos necesarios para la promoción de servidor esclavo en caso de falla del master en una repliaction modo Streaming Replication.
Si el servidor principal (master) falla, entonces el servidor esclavo debe comenzar el procedimiento de conmutación por error (failover). PostgreSQL no proporciona un software específico para identificar una falla en el servidor master y notificar al servidor esclavo, el procedimiento por tanto es manual.
Requisitos:
- Se debe contar con suficiente privilegios para la configuración de aplicativos
- Se debe tener instalado y ejecución la replicación de BD PostgreSQL en modo: Streaming Replication, tal como se indica en éste enlace
Plataforma:
- Equipos de arquitectura 64 bits
- Sistema operativo ‘GNU/Linux’ Debian versión 9.0 (actualmente estable)
A continuación se demostrará dos (02) formas de promoción, la 1era a través del archivo recovery.conf y la 2da a través del comando pg_ctlcluster con la opción “promote”
Configuración
NOTA: Antes de intentar la conmutación por error (failover), hay que garantizar que el servidor esclavo tenga la configuración idéntica (postgresql.conf, pg_hba.conf, otros) al servidor maestro. Además, después de una conmutación por error (failover) con éxito, el viejo servidor maestro debe ser desactivado “fuera de servicio”.
1. Comprimir los archivos de configuración
root@postgreSQL01:/etc/postgresql/9.x/main# tar -cvzf server_master_config.tar.gz *
environment pg_ctl.conf pg_hba.conf pg_ident.conf postgresql.conf start.conf
2. Enviarlos al servidor esclavo
root@postgreSQL01:/etc/postgresql/9.x/main# scp server_master_config.tar.gz root@IP_SERVER_ESCLAVO:/tmp
3. Descomprimirlo en el servidor esclavo
root@postgreSQL02:# tar -xvzf server_master_config.tar.gz -C /etc/postgresql/9.x/main/
Método #1: Archivo recovery.conf
En la ruta (/var/lib/postgresql/9.4/main) de la configuración del servidor esclavo existe un archivo denominado recovery.conf, el cual contiene la opción:
trigger_file = '/tmp/trigger_failover'
Dicha opción se puede describir de la siguiente forma: Especifica un archivo desencadenante, que en caso de crearse/existir, podrá fin a la replicación, sacará al servidor esclavo del modo “hot standby” y de recuperación continua. Esto en caso de falla del master y promover el servidor esclavo como master
En pocas palabras, Postgres hará una conmutación por error (failover) y promoverá el servidor esclavo si comprueba que el archivo ha sido creado.
1. Crear archivo:
root@postgreSQL02:/# touch /tmp/trigger_failover
Después de una conmutación por error, el archivo recovery.conf será renombrado a recovery.done
2. Listar archivos:
root@postgreSQL02:/# ls -la | grep recovery
-rw-r--r-- 1 postgres postgres 288 dic 28 11:50 recovery.done
3. Verificar log
root@postgreSQL02:/# tail -10 /var/log/postgresql/postgresql-9.x-main.log
2017-12-29 11:46:22.272 -04 [3504] LOG: seleccionado nuevo ID de timeline: 2 cp: no se puede efectuar `stat' sobre '/opt/archive/00000001.history': No existe el fichero o el directorio 2017-12-29 11:46:22.542 -04 [3504] LOG: recuperación completa 2017-12-29 11:46:22.678 -04 [3504] LOG: las protecciones de reciclaje de miembros de multixact están habilitadas 2017-12-29 11:46:22.694 -04 [3503] LOG: el sistema de bases de datos está listo para aceptar conexiones 2017-12-29 11:46:22.695 -04 [7393] LOG: lanzador de autovacuum iniciado
4. Reiniciar servicio:
root@postgreSQL02:/etc/postgresql/9.6/main# /etc/init.d/postgresql restart
[ ok ] Restarting postgresql (via systemctl): postgresql.service.
En éste punto el servidor se encuentra listo para recibir conexión y ser utilizado como un nuevo servidor master.
Método #2: Uso comando pg_ctlclueter con la opción promote
Los esclavos pueden ser promovidos a ser un maestro. Esto se puede hacer mediante la ejecución del comando:
root@postgreSQL02:# pg_ctlcluster 9.X main promote
Enlaces:
Replicacion WAL Shipping y Streamming
Promoting a Standby to the Main server
26.3. conmutación por error
postgresql streaming replication howto
