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.
Deja una respuesta