Herramientas

Mantener un sistema de alta disponibilidad con PostgreSQL y repmgr

En la entrada de la semana pasada se explicaron los pasos necesarios para la instalación y configuración de un sistema de alta disponibilidad en PostgreSQL con repmgr. Para lo que se emplearon dos máquinas virtuales con Rocky Linux 9. En esta publicación se va a usar el clúster para ver cómo mantener un sistema de alta disponibilidad con PostgreSQL y comprobar que este funciona de forma correcta.

Comprobar el estado de las máquinas en el clúster

Una de las primeras tareas que se deben hacer una vez configurado el sistema de alta disponibilidad es comprobar el estado del clúster para comprobar que las máquinas se han sido agregadas de forma correcta. Lo que se puede comprobar en la tabla nodes de la base de datos repmgr. Para lo que se puede ejecutar la consulta SELECT * FROM repmgr.nodes; en la terminal con psql o en una máquina cliente con pgAdmin. En la siguiente captura de pantalla se puede ver el resultado de esta consulta en el clúster de ejemplo.

En este caso se pueden ver el clúster contiene los dos nodos que se habían registrado la semana pasada. Ambos nodos están activos como se puede ver en la columna active. El nodo que se ha denominado nodo2 su archivo repmgt.conf es la base de datos que está funcionando como réplica (la columna type tiene el valor standby). Por otro lado, node1 es la base de datos primaria.

Creación de una nueva base de datos de prueba

Ahora se puede crear una base de datos de prueba para comprobar que el sistema funciona y replica los datos de forma correcta. Para ello se debe seleccionar la base de datos que esté funcionando como maestra, ya que la réplica solamente funciona en modo lectura. Algo que se puede comprobar intentando crear la base de datos en la réplica.

Operación que se puede realizar sin problemas en la base de datos maestra.

Ahora si se refresca la base de datos réplica debería aparecer la nueva base de datos.

Iniciar el demonio para monitorizar el clúster

Ahora se puede iniciar el demonio de repmgr para monitorizar la red, lo que se debe hacer en ambas máquinas usando el comando

repmgrd -f repmgr.conf --verbose

Usando la opción --verbose para que muestre toda la información por pantalla.

Funcionamiento del clúster en caso de fallo

Ahora, en el caso de que el servidor réplica caiga, el servidor maestro no se ve afectado, solamente se perderá la capacidad de réplica. Si la caída es temporal al recuperarse la base de datos esta actualizará los cambios pendientes.

En el caso de que caiga la base de datos maestra y pase el tiempo indicado en el archivo repmgr.conf la réplica será promocionada como base de datos maestra. Pasando a ser el nodo principal. Una vez pase esto la base de datos original no se puede agregar al clúster, ya que no cuenta con los cambios, y es necesario crear una nueva base de datos y agregarla al clúster como réplica.

Conclusiones

En esta entrada se ha visto cómo mantener un sistema de alta disponibilidad con PostgreSQL y repmgr.


Imagen de lavivm en Pixabay

¿Te ha parecido de utilidad el contenido?

Daniel Rodríguez

Share
Published by
Daniel Rodríguez

Recent Posts

Analytics Lane lanza la versión 1.4 del laboratorio con nuevas herramientas de conversión y modelos avanzados de CLV

Seguimos ampliando el laboratorio de Analytics Lane con el lanzamiento de la versión 1.4, que…

4 días ago

Lanzamos el video de ScoreFlow: crea scorecards de crédito de forma ágil y sin IT

En Analytics Lane seguimos apostando por desarrollar herramientas que simplifiquen el trabajo de analistas y…

6 días ago

Data Leakage en Credit Scoring: El Error que Invalida tu Modelo

Imagina que construyes un scorecard con un Gini de 0,85. Un resultado extraordinario, muy por…

7 días ago

Analytics Lane lanza ScoreFlow, un SaaS para construir y desplegar scorecards de crédito

En Analytics Lane seguimos evolucionando nuestras herramientas y damos un paso más con el lanzamiento…

2 semanas ago

This website uses cookies.