Alta disponibilidad en PostgreSQL con repmgr

La semana pasada se explicaron los pasos necesarios para la creación de un sistema de réplica con PostgreSQL. Esto es, un sistema mediante el cual se puede disponer de una copia de la base de datos en un segundo servidor. Pero un sistema de réplica no es un sistema de alta disponibilidad. La base de datos de réplica es de solo lectura, por lo que solamente se puede usar como copia de seguridad y para realizar parte de las operaciones de lectura, descargando de trabajo al servidor principal. El sistema de réplica no es un sistema de alta disponibilidad. Para implementar un sistema de alta disponibilidad en PostgreSQL es necesario usar además una herramienta como repmgr. En esta entrada se va a mostrar como configurar un repmgr en Rocky Linux 9, pasos que también se pueden seguir en otras distribuciones basadas en Red Hat Enterprise Linux 9, para crear un sistema de alta disponibilidad en PostgreSQL.

Introducción a repmgr

Repmgr es un software de código abierto diseñado para gestionar y supervisar clústeres de bases de datos PostgreSQL, implementando para ello las funcionalidades clave para la administración eficiente de sistemas distribuidos. Por lo que es una herramienta que se utiliza en entornos donde la alta disponibilidad y la tolerancia a fallos son clave. Su funcionalidad clave es la administración del proceso de replicación y la conmutación en caso de fallo de las bases de datos PostgreSQL, lo que permite crear y gestionar réplicas redundantes.

Instalación de PostgreSQL y repmgr

Aunque, como se ha visto cuando se explicó cómo instalar PostgreSQL en Rocky Linux, la propia distribución cuenta en el canal oficial con una versión de PostgreSQL no cuenta con repmgr, por lo que se debe instalar desde los repositorios de PostgreSQL. Para ello se debe agregar el repositorio al sistema usando el siguiente comando:

sudo dnf install https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

Comando que es válido en Rocky Linux 9, Alma Linux 9 o RHEL 9, si se usa otra versión se debe cambiar la URL. En este punto se debe actualizar el sistema

sudo dnf update -y

Para evitar conflictos con el módulo por defecto de PostgreSQL se debe desactivar, usando para ello el siguiente comando

sudo dnf -qy module disable postgresql

Una vez que el módulo se ha desactiva ya es posible instalar PostgreSQL 15 y una versión de repmgr preparado para la base de datos

sudo dnf install -y postgresql15-server repmgr_15

Si se desea utilizar otra versión de PostgreSQL, como puede ser la 16, solamente se tiene que reemplazar 15 por el número de la versión.

Inicialización de la base de datos

Una vez instalados los paquetes es necesario crear las carpeta y usuarios de la base de datos, para lo que se puede ejecutar el siguiente comando

/usr/pgsql-15/bin/postgresql-15-setup initdb

Lo que creará una base de datos con la configuración por defecto y el usuario postgres. Ahora ya se puede inicializar el servicio

systemctl start postgresql-15

Sin olvidar activar el servicio para que se cargue tras un reinicio del sistema

systemctl enable postgresql-15

Permitir el acceso remoto a PostgreSQL

La configuración por defecto de PostgreSQL no admite el acceso remoto, solamente se puede acceder desde el propio servidor. Para solucionar esto se debe abrir el archivo /var/lib/pgsql/data/postgresql.conf y cambiar la línea

listen_addresses = 'localhost'

por

listen_addresses = '*'

Lo que hace que la base de datos se pueda consultar desde cualquier IP. Además, también se tiene que indicar la dirección IP o el rango de IP desde el que se desea acceder a la base de datos en el archivo /var/lib/pgsql/data/pg_hba.conf. En este archivo se debe agregar una línea como la siguiente

host all all 192.168.1.39/24 md5

en la que se indica que se accede desde puede acceder a todas las bases de datos, por parte de todos los usuarios, desde cualquier IP en el rango 192.168.1.39/24 mediante autenticación md5. Solamente se debe reemplazar el rango de IP por aquel en el que se encuentre las máquinas que deben acceder.

Crear una regla para el cortafuegos

En los sistemas actuales el cortafuegos suele estar activado por defecto, por lo que se debe crear una regla para permitir el acceso a la base de datos. Esto es abrir el puerto 5432, salvo que se hubiese indicado uno diferente en el archivo de configuración. Para ello se debe escribir el comando

sudo firewall-cmd --zone=public --add-port 5432/tcp --permanent

Sin olvidar reiniciar el servicio del cortafuegos para que se apliquen los cambios.

sudo systemctl restart firewalld

Todos los pasos indicados hasta ahora se deben realizar en todos los servidores del clúster.

Configuración de rpmgr

El proceso de configuración de rpmgr solo se tiene que hacer en la máquina maestro, la configuración se copiara posteriormente a las réplicas. Antes de poder usar rpmgr en PostgreSQL es necesario crear primero un usuario, lo que se puede hacer desde la base de datos con un comando como el siguiente comando

CREATE USER replicator password '';

Reemplazando '<rep_pass>' con la contraseña del usuario. Una vez hecho esto se le debe asignar a propiedad shared_preload_libraries el valor 'repmgr' en el archivo /var/lib/pgsql/15/data/postgresql.conf

shared_preload_libraries = 'repmgr'

y autorizar el local y en red a la base de datos repmgr y darle permisos de replicación al usuario repmgr, para lo que se agregaran las siguientes líneas.

 local   repmgr          repmgr                                  trust
 host    repmgr          repmgr          192.168.1.0/24          trust
 local   replication     repmgr                                  trust
 host    replication     repmgr          192.168.1.0/24          trust

Ahora, una vez reiniciada la base de datos, el usuario repmgr debería poder acceder desde cualquier máquina de la red.

Archivo de configuración de repmgr

Ahora se debe crear en la carpeta del usuario postgres se debe copiar el archivo repmgr.conf.sample como repmgr.conf y modificar las siguiente líneas.

node_id=1               
node_name='node1'
conninfo='host=192.168.1.41 port=5432 dbname=repmgr user=repmgr'
data_directory='/var/lib/pgsql/15/data'
failover='automatic'

promote_command='repmgr standby promote -f /var/lib/pgsql/repmgr.conf'
follow_command='repmgr standby follow -f /var/lib/pgsql/repmgr.conf -W --upstream-node-id=2

En donde se indica que este es el nodo 1 y se indica la IP del host. Cuando se copie el archivo al nodo 2 de debe cambiar el ideal del nodo (node_id), el nombre (node_name) y la configuración de la base de datos (conninfo). Además, se tiene que agregar al la ruta a los binarios agregado la siguiente línea

port PATH=$PATH:/usr/pgsql-15/bin/

Configuración del nodo maestro

Ahora el sistema ya está configurado, se tiene que registrar el servidor principal como nodo maestro, lo que se hace con el comando

repmgr -f repmgr.conf master register

Con lo que se le indica al repmgr que lea la configuración del archivo repmgr.conf y registre este nodo como maestro.

Creación de una réplica

El servidor donde se ejecutará la réplica se debe instalar la base de datos, repmgr y crear un archivo repmgr.conf como el del nodo 1 cambiado los datos para este nodo. Una vez hecho esto se debe para PostgreSQL e iniciar el proceso de réplica con el siguiente comando

repmgr -h 192.168.1.41 -U repmgr -d repmgr -f repmgr.conf standby clone -F

Con lo que se le indicará a repmgr que replique la base de datos 192.168.1.41 en base al archivo repmgr.conf y la configure como réplica. El tiempo de réplica dependerá del tamaño de la base de datos y la velocidad de red. Una vez finalizado el proceso, se debe indicar PostgreSQL y registrar la base de datos como réplica.

repmgr -f repmgr.conf standby register

En cada uno de los servidores se debe iniciar repmgrd para monitorizar la base de datos y promocionar la réplica a maestra en caso de fallo

repmgrd -f repmgr.conf --verbose

Comprobar el estado del cluster

Para comprobar el estado del cluster se puede acceder, en cualquiera de los dos servidores a la base de datos repmgr para ver los eventos en la tabla events y el estado de los nodos en la tabla nodes.

En la tabla eventos se debe ver cuándo se ha agregado un nodo, cuando se pierde la conexión y cuando un nodo es promocionado a maestro. Una vez configurado el clúster solamente se debería ver los registros. Por otro lado, en la tabla nodes se debe ver todos los nodos y su estado actual.

Conclusiones

En esta entrada se ha visto cómo configurar un sistema de alta disponibilidad en PostgreSQL con repmgr. Un proceso complejo pero que permite disponer de una base de datos con tolerancia a fallos.

La semana que viene veremos cómo verificar el funcionamiento del clúster y recuperar este en caso de caída.

Imagen de lavivm en Pixabay