Base de Datos, PostgreSQL

Promover Servidor Esclavo (Failover Master). Replicación PostgreSQL modo: Streaming Replication

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

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s