Configuración de un clúster de bases de datos de alta disponibilidad con MariaDB Galera, ProxySQL, Keepalived y Debian 13

Introducción

A medida que tus aplicaciones crecen en escala e importancia, garantizar una disponibilidad continua se convierte en algo fundamental. El tiempo de inactividad de la base de datos puede provocar pérdidas de ingresos, usuarios frustrados y daños a tu reputación. Esta guía muestra cómo crear un clúster de MariaDB de alta disponibilidad (HA) aprovechando la replicación de Galera, ProxySQL para el enrutamiento inteligente de consultas y Keepalived para la gestión de direcciones IP virtuales en Debian.

Esta arquitectura combina los puntos fuertes de cada tecnología para ofrecer un entorno de base de datos robusto y resistente. MariaDB Galera proporciona replicación sincrónica multimaster, lo que garantiza la coherencia de los datos en varios nodos. ProxySQL actúa como enrutador de consultas y equilibrador de carga, proporcionando una gestión inteligente del tráfico y aliviando la carga de los servidores de bases de datos. Keepalived gestiona una dirección IP virtual, proporcionando un único punto de acceso al clúster y automatizando la conmutación por error en caso de fallos en los nodos.

Esta guía da por hecho que el lector tiene experiencia en administración de sistemas Linux, conoce los conceptos básicos de redes (TCP/IP, DNS) y está familiarizado con la administración de bases de datos. Nos centraremos en la configuración e integración de estas tecnologías en un entorno Debian.

Ventajas clave de esta arquitectura:

• Alta disponibilidad: la conmutación por error automatizada garantiza un tiempo de inactividad mínimo.
• Consistencia de los datos: la replicación síncrona garantiza la consistencia de los datos en todos los nodos.
• Rendimiento mejorado: ProxySQL optimiza el enrutamiento de consultas y reduce la carga en los servidores de bases de datos.
• Gestión simplificada: una única dirección IP virtual simplifica la configuración y el acceso a las aplicaciones.

Lo que necesitarás:

• Tres VPS o servidores con Debian 13.
• Acceso de root o con sudo a todos los servidores.
• Familiaridad con la interfaz de línea de comandos.
• Conocimientos básicos sobre redes TCP/IP y DNS.

Requisitos previos

Interconexión de nodos

Una resolución adecuada de los nombres de host es esencial para que el clúster funcione correctamente. Cada servidor debe poder localizar a los demás servidores por su nombre. Utilizamos nombres de host para simplificar la gestión. Las direcciones IP de los nodos deben estar en la misma subred.

Asignación de nombres de host y direcciones IP

• galera0 (nodo maestro): 192.168.10.10
• galera1 (nodo esclavo): 192.168.10.11
• galera2 (nodo esclavo): 192.168.10.12

Puedes resolver los nombres de host utilizando el archivo /etc/hosts o el DNS.

• Uso de /etc/hosts (configuración más sencilla): esta opción es adecuada para entornos de prueba y desarrollo. En cada servidor, añade entradas en el archivo /etc/hosts que asocien el nombre de host del servidor a su dirección IP estática.
• Uso de DNS (recomendado para producción): Para entornos más grandes o complejos, configura registros DNS (registros A) que asocien los nombres de host de los servidores a sus respectivas direcciones IP.

Verificación

Tras configurar la resolución de nombres de host, comprueba que cada servidor pueda resolver los nombres de host de los demás servidores mediante el comando ping. Por ejemplo, desde galera0, ejecuta ping galera1. Deberías recibir una respuesta.

Instalación de los paquetes necesarios

Antes de poder configurar el clúster de Galera, deberá instalar los paquetes necesarios de MariaDB en cada nodo. En esta sección se describen los pasos necesarios para los sistemas basados en Debian.

Añadir los repositorios necesarios

Añade los repositorios necesarios mediante los siguientes comandos:

apt-get update && apt-get install -y --no-install-recommends lsb-release wget apt-transport-https ca-certificates

wget -nv -O /usr/share/keyrings/proxysql-3.0.x-keyring.gpg 'https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/repo_pub_key.gpg'

echo "deb [signed-by=/usr/share/keyrings/proxysql-3.0.x-keyring.gpg] https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/bookworm/ ./" | tee /etc/apt/sources.list.d/proxysql.list

Actualización del sistema

En primer lugar, actualiza las listas de paquetes y los propios paquetes. Ejecuta el siguiente comando como root en cada nodo:

apt update && apt upgrade -y

Instalar paquetes

Instala los paquetes necesarios en cada nodo mediante este comando:

apt install rsync mariadb-server mariadb-client galera-4 proxysql keepalived -y

Instalación segura de MariaDB

Ejecuta el script de seguridad en cada nodo:

sudo mariadb-secure-installation

Este script realiza dos pasos cruciales: te pedirá que establezcas una contraseña de root segura para el servidor MariaDB y eliminará cualquier configuración predeterminada que no sea segura. Sigue las instrucciones que aparecen en pantalla para completar este proceso.

Habilitar el acceso remoto a MariaDB

Ejecuta estos comandos para habilitar el acceso remoto en cada nodo:

sed -i "s/.*bind-address.*/bind-address = 0.0.0.0/" /etc/mysql/mariadb.conf.d/50-server.cnf
systemctl restart mariadb

Galera

Galera proporciona replicación sincrónica de datos entre todos los nodos del clúster. Esto significa que cada cambio realizado en la base de datos de un nodo se propaga de forma automática y simultánea a todos los demás nodos. Ventajas clave de Galera en esta configuración:

• Alta disponibilidad: si falla un nodo, los demás nodos siguen sirviendo datos sin interrupción. El clúster promueve automáticamente a un nodo superviviente para que se convierta en el primario.
• Consistencia de los datos: gracias a la replicación sincrónica, los datos son siempre consistentes en todos los nodos. Esto elimina el riesgo de lecturas obsoletas: siempre se lee la versión más actualizada de los datos.
• Escalabilidad de lectura: dado que los datos se replican en varios nodos, puedes distribuir las consultas de lectura por todo el clúster para aumentar el rendimiento de lectura.

En esencia, Galera garantiza que tu base de datos MariaDB se mantenga altamente disponible, coherente y escalable, requisitos fundamentales para muchas aplicaciones.

Configuración

Crea un archivo de configuración /etc/mysql/conf.d/galera.cnf en cada nodo. El contenido será idéntico, salvo por el nombre y la dirección de cada nodo. Pega esta plantilla:

[mysqld]
# Basic MariaDB settings
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0 # Binds to all network interfaces. Adjust if you have a specific private IP for cluster traffic.
# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so # Adjust path if different (e.g., /usr/lib64/galera-4/libgalera_smm.so)
# Galera Cluster Configuration
wsrep_cluster_name="my_galera_cluster" # A unique name for your cluster
# IP addresses of ALL nodes in the cluster, comma-separated.
# Use private IPs if available for cluster communication.
wsrep_cluster_address="gcomm://galera0,galera1,galera2"
# This node's specific configuration
wsrep_node_name="<node_name>" # Must be unique for each node (e.g., node1, node2, node3)
wsrep_node_address="<node_address>" # This node's own IP address

Cambia <node_name> y <node_address> en cada nodo. Utiliza galera0 para el primer nodo y así sucesivamente.

Iniciar el clúster

Inicia el clúster en el primer nodo con este comando:

sudo systemctl stop mariadb && sudo galera_new_cluster

Reinicia MariaDB en los demás nodos:

sudo systemctl restart mariadb

Comprueba la configuración

Comprueba el tamaño del clúster

Conéctate a MariaDB desde cualquier nodo y comprueba el estado del clúster. Conéctate a la base de datos:

sudo mariadb -u root -p

Comprueba el estado de los nodos del clúster en el shell de MariaDB:

SHOW STATUS LIKE 'wsrep_cluster_size';

wsrep_cluster_size debería ser igual al número de nodos que tenemos.

MariaDB [galtest]> SHOW STATUS LIKE
'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+
1 row in set (0.001 sec)

MariaDB [galtest]>

Probar la replicación

Crea una base de datos de prueba en cualquier nodo e inserta un mensaje de prueba. Ejecuta los siguientes comandos desde el shell de MariaDB:

CREATE DATABASE galtest;
USE galtest;
CREATE TABLE messages (id INT AUTO_INCREMENT PRIMARY KEY, text VARCHAR(255));
INSERT INTO messages (text) VALUES ('Test from galera0!');

A continuación, comprueba los datos en los demás nodos utilizando la siguiente consulta SQL a través del shell de MariaDB:

USE galtest;
SELECT * FROM messages;

Debería aparecer el mensaje de prueba:

MariaDB [galtest]> USE galtest;
Database changed
MariaDB [galtest]> SELECT * FROM messages;
+----+--------------------+
| id | text               |
+----+--------------------+
|  7 | Test from galera0! |
+----+--------------------+
1 row in set (0.001 sec)

MariaDB [galtest]>

ProxySQL

ProxySQL, en esta configuración de clúster, es más que un simple intermediario; mejora drásticamente el rendimiento, la fiabilidad y la facilidad de gestión de su base de datos. ProxySQL actúa como una capa crucial entre sus aplicaciones y su clúster de Galera. Sus objetivos principales son:

• Almacenamiento en caché de consultas: ProxySQL almacena en caché de forma activa las consultas que se ejecutan con frecuencia. En lugar de consultar repetidamente el clúster de Galera para obtener los mismos datos, proporciona el resultado almacenado en caché, lo que reduce significativamente la carga de la base de datos y mejora los tiempos de respuesta. Esto resulta especialmente beneficioso para aplicaciones con un uso intensivo de lecturas.
• Agrupación de conexiones: ProxySQL mantiene un conjunto de conexiones persistentes con el clúster de Galera. Establecer una conexión con la base de datos es una operación que consume muchos recursos. La agrupación de conexiones evita esta sobrecarga al reutilizar las conexiones existentes, lo que potencia aún más el rendimiento.
• Equilibrio de carga y enrutamiento de consultas: ProxySQL puede enrutar de forma inteligente las consultas a diferentes nodos de tu clúster de Galera en función de factores como la carga del servidor, el tipo de consulta o la afinidad de los datos. Esto te permite distribuir la carga de trabajo y maximizar el rendimiento de tu clúster.
• Optimización de consultas: ProxySQL puede reescribir las consultas para que sean más eficientes, aprovechando potencialmente las capacidades de Galera para una ejecución óptima.
• Detección de fallos y enrutamiento: ProxySQL supervisa continuamente el estado de sus nodos de Galera. Si un nodo falla, ProxySQL redirige automáticamente las consultas a los nodos que funcionan correctamente, garantizando un servicio ininterrumpido.

En esencia, ProxySQL actúa como un gestor inteligente del tráfico y un optimizador del rendimiento para su clúster de Galera, mejorando significativamente su eficiencia y resiliencia.

Precauciones

Configuración de usuarios

Usuario de supervisión

El usuario de supervisión de ProxySQL es una cuenta de base de datos dedicada exclusivamente a que las herramientas de supervisión puedan acceder de forma segura a las estadísticas y métricas internas. Está configurada con permisos mínimos —solo acceso SELECT— para garantizar la integridad y la seguridad de tus datos, al tiempo que permite una supervisión exhaustiva del rendimiento.

Ejecuta esta consulta en el shell de MariaDB del nodo maestro para añadir el usuario de supervisión:

CREATE USER 'monitor'@'%' IDENTIFIED BY 'monitor';
GRANT SELECT ON *.* TO 'monitor'@'%';
FLUSH PRIVILEGES;

Usuario de aplicación

El usuario de aplicación de ProxySQL es una cuenta de base de datos estándar que utilizan sus aplicaciones para conectarse y ejecutar consultas en el clúster Galera subyacente. Es a través de este usuario como su aplicación interactúa directamente con la base de datos, recuperando y manipulando datos.

Ejecuta esta consulta en el shell de MariaDB del nodo maestro para añadir el usuario de aplicación:

GRANT ALL PRIVILEGES ON *.* TO 'test'@'%' IDENTIFIED BY 'test' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Verificación

Comprueba que se ha creado el usuario en todos los nodos con este comando:

mariadb -u root -e "SELECT user, host FROM mysql.user;"

Configuración

Crea un archivo de configuración /etc/proxysql.cnf en cada nodo y pega el siguiente contenido:

datadir="/var/lib/proxysql"

admin_variables=
{
        admin_credentials="admin:admin"
        mysql_ifaces="127.0.0.1:6032"
}

mysql_variables=
{
        threads=4
        max_connections=2048
        monitor_username="monitor"
        monitor_password="monitor"
}

mysql_servers=
(
        { address="galera0" , port=3306 , hostgroup=0 },
        { address="galera1" , port=3306 , hostgroup=0 },
        { address="galera2" , port=3306 , hostgroup=0 }
)

mysql_users=
(
        { username = "test" , password = "test" , default_hostgroup = 0 , active = 1 }
)

mysql_query_rules=
(
        {
                rule_id=2
                active=1
                match_pattern="^SELECT.*"
                destination_hostgroup=0
                apply=1
        }
)

Habilita e inicia ProxySQL con estos comandos:

sudo systemctl start proxysql
sudo systemctl enable proxysql
sudo proxysql --reload

Comprueba la configuración de ProxySQL con este comando:

mysql -u admin -padmin -h 127.0.0.1 -P6032 -e "SELECT hostname, status FROM mysql_servers;"

Todos los nodos deben estar en línea:

+----------+--------+
| hostname | status |
+----------+--------+
| galera0  | ONLINE |
| galera1  | ONLINE |
| galera2  | ONLINE |
+----------+--------+

Keepalived

Keepalived gestiona una dirección IP virtual, proporcionando un único punto de acceso al clúster y automatizando la conmutación por error en caso de fallos en los nodos. Supervisa el estado de los nodos de MariaDB y redirige el tráfico a un nodo operativo si se produce un fallo, manteniendo así una alta disponibilidad. La configuración define el ID de enrutador virtual 51 y utiliza la interfaz eth0. En el nodo maestro, el estado se establece en MASTER con una prioridad de 100. Los nodos de respaldo se configuran con un estado de BACKUP, con prioridades de 90 y 80, respectivamente. La dirección virtual_ipaddress se establece en 192.168.10.50 en todos los nodos. La VIP y los nodos deben estar en la misma subred. El servicio de alojamiento debe admitir la VIP para VPS. La autenticación está habilitada con una contraseña compartida de 1234. El parámetro advert_int define la frecuencia con la que el nodo maestro envía anuncios VRRP. Un valor más bajo implica anuncios más frecuentes, lo que puede acelerar la detección de la conmutación por error; un valor más alto implica anuncios menos frecuentes, lo que puede retrasar la conmutación por error pero reduce la sobrecarga de la red.

Configuración

Crea un archivo de configuración /etc/keepalived/keepalived.conf en cada nodo y pega el siguiente contenido:

vrrp_instance VI_1 {
    state <NODE_STATE>
    interface eth0
    virtual_router_id 51
    priority <NODE_PRIORITY>
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.10.50/24
    }
}

Modifica <NODE_STATE> y <NODE_PRIORITY> tal y como se ha descrito anteriormente. Activa e inicia el servicio keepalived:

sudo systemctl enable keepalived && sudo systemctl start keepalived

Verificación

Para verificar la configuración, utilice la VIP configurada a través de Keepalived y el puerto configurado a través de ProxySQL. Compruebe el tamaño del clúster, por ejemplo:

mariadb -u test -ptest -h 192.168.10.50 -P6033 -D galtest -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

La respuesta esperada debe coincidir con la verificación de Galera:

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

Ahora puede reiniciar los nodos al azar, comprobar el tamaño del clúster y la disponibilidad de los datos.

Conclusión

Esta guía ha mostrado cómo crear un clúster de MariaDB de alta disponibilidad utilizando la replicación Galera, ProxySQL para el enrutamiento de consultas y Keepalived para la gestión de la IP virtual en Debian. Esta arquitectura ofrece varias ventajas clave, entre las que se incluyen la alta disponibilidad con conmutación automática ante fallos, la consistencia de los datos mediante la replicación síncrona y un rendimiento mejorado gracias a ProxySQL. Al combinar estas tecnologías, puedes crear un entorno de base de datos robusto y resistente, capaz de gestionar mayores cargas de trabajo y minimizar el tiempo de inactividad.