Configuración de un clúster de base de datos de alta disponibilidad utilizando MariaDB Galera, ProxySQL, Keepalived y Debian 13. | INTROSERV
EUR
european

EUR

usa

USD

Spanish Es
Ex. VAT Ex. VAT 0%

Configuración de un clúster de base de datos de alta disponibilidad utilizando MariaDB Galera, ProxySQL, Keepalived y Debian 13.

Introducción

A medida que sus aplicaciones crecen en escala e importancia, garantizar la disponibilidad continua se vuelve crítico. El tiempo de inactividad de la base de datos puede llevar a la pérdida de ingresos, usuarios frustrados y daño a su reputación. Esta guía demuestra cómo construir un clúster de MariaDB altamente disponible (HA) aprovechando la replicación de Galera, ProxySQL para el enrutamiento inteligente de consultas y Keepalived para la gestión de IP virtual en Debian.

Esta arquitectura combina las fortalezas de cada tecnología para ofrecer un entorno de base de datos robusto y resiliente. MariaDB Galera proporciona replicación multi-maestro sincrónica, asegurando la consistencia de los datos a través de múltiples nodos. ProxySQL actúa como un enrutador de consultas y balanceador de carga, proporcionando una gestión inteligente del tráfico y descargando 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 de nodos.

Esta guía asume experiencia en administración de sistemas Linux, conceptos básicos de redes (TCP/IP, DNS) y familiaridad con la administración de bases de datos. Nos centraremos en la configuración e integración de estas tecnologías dentro de un entorno Debian.

Beneficios clave de esta arquitectura:

  • Alta Disponibilidad: La conmutación por error automatizada asegura un tiempo de inactividad mínimo.
  • Consistencia de Datos: La replicación sincrónica garantiza la consistencia de los datos en todos los nodos.
  • Mejora del Rendimiento: 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 de la aplicación.

Lo que necesitarás:

  • Tres VPS o servidores Debian 13.
  • Acceso root o sudo a todos los servidores.
  • Familiaridad con la interfaz de línea de comandos.
  • Una comprensión básica de redes TCP/IP y DNS.

Requisitos Previos

Interconexión de Nodos

La resolución adecuada de nombres de host es esencial para que el clúster funcione correctamente. Cada servidor necesita poder encontrar los otros servidores por nombre. Estamos usando nombres de host para simplificar la gestión. Las direcciones IP de los nodos deben estar en la misma subred.

Mapeo 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

Puede lograr la resolución de nombres de host utilizando /etc/hosts o DNS.

  • Usando /etc/hosts (Configuración más simple): Esto es adecuado para entornos de prueba y desarrollo. En cada servidor, agregue entradas que mapeen el nombre de host del servidor a su dirección IP estática en el archivo /etc/hosts.
  • Usando DNS (Recomendado para Producción): Para entornos más grandes o complejos, configure registros DNS (registros A) que mapeen los nombres de host del servidor a sus respectivas direcciones IP.

Verificación

Después de configurar la resolución de nombres de host, verifique que cada servidor pueda resolver los nombres de host de los otros servidores usando el comando ping. Por ejemplo, desde galera0, ejecute ping galera1. Debería recibir una respuesta.

Instalación de Paquetes Requeridos

Antes de poder configurar el clúster de Galera, necesitará instalar los paquetes necesarios de MariaDB en cada nodo. Esta sección describe los pasos requeridos para sistemas basados en Debian.

Agregar repositorios requeridos

Agregue los repositorios requeridos usando 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

Primero, actualice sus listas de paquetes y paquetes. Ejecute el siguiente comando como root en cada nodo:

apt update && apt upgrade -y

Instalar paquetes

Instale los paquetes requeridos en cada nodo usando este comando:

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

Proteger la instalación de MariaDB

Ejecute el script de seguridad en cada nodo:

sudo mariadb-secure-installation

Este script realiza dos pasos cruciales: le pedirá que establezca una contraseña root fuerte para el servidor MariaDB y eliminará cualquier configuración predeterminada insegura. Siga las indicaciones en pantalla para completar este proceso.

Habilitar acceso remoto a MariaDB

Ejecute 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 a través de todos los nodos en el clúster. Esto significa que cada cambio realizado en la base de datos en un nodo se propaga automática y simultáneamente a todos los demás nodos. Beneficios clave de Galera en esta configuración:

  • Alta Disponibilidad: Si un nodo falla, los otros nodos continúan sirviendo datos sin interrupción. El clúster automáticamente promueve un nodo sobreviviente para convertirse en el primario.
  • Consistencia de Datos: Debido a la replicación sincrónica, los datos siempre son consistentes en todos los nodos. Esto elimina el riesgo de lecturas obsoletas: siempre está leyendo la versión más actualizada de los datos.
  • Escalabilidad de Lectura: Debido a que los datos se replican a través de múltiples nodos, puede distribuir consultas de lectura a través del clúster para aumentar el rendimiento de lectura.

En esencia, Galera asegura que su base de datos MariaDB permanezca altamente disponible, consistente y escalable, requisitos cruciales para muchas aplicaciones.

Configuración

Cree un archivo de configuración /etc/mysql/conf.d/galera.cnf en cada nodo. El contenido será idéntico, con la excepción del nombre y la dirección de cada nodo. Pegue esta plantilla:

[mysqld] # Configuración básica de MariaDB binlog_format=ROW default_storage_engine=InnoDB innodb_autoinc_lock_mode=2 bind-address=0.0.0.0 # Configuración del Proveedor de Galera wsrep_on=ON wsrep_provider=/usr/lib/galera/libgalera_smm.so # Configuración del Clúster de Galera wsrep_cluster_name="my_galera_cluster" wsrep_cluster_address="gcomm://galera0,galera1,galera2" # Configuración específica de este nodo wsrep_node_name="<node_name>" wsrep_node_address="<node_address>"

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

Info

Importante: wsrep_cluster_address — liste los nombres de host de todos los nodos en el clúster en cada nodo. wsrep_node_name — debe ser único para cada nodo (por ejemplo, galera0, galera1, galera2). wsrep_node_address — configúrelo al nombre de host del nodo que está configurando.

Iniciar el clúster

Inicie el clúster en el primer nodo usando este comando:

sudo systemctl stop mariadb && sudo galera_new_cluster

Reinicie MariaDB en otros nodos:

sudo systemctl restart mariadb

Verificar la configuración

Verificar tamaño del clúster

Conéctese a MariaDB en cualquier nodo y verifique el estado del clúster. Conéctese a la base de datos:

sudo mariadb -u root -p

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

SHOW STATUS LIKE 'wsrep_cluster_size';

wsrep_cluster_size debe ser igual a nuestro conteo de nodos.

+--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 3 | +--------------------+-------+ 1 row in set (0.001 sec)

Probar Replicación

Cree una base de datos de prueba en cualquier nodo e inserte un mensaje de prueba. Ejecute 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!');

Luego verifique los datos en otros nodos usando la siguiente consulta SQL a través del shell de MariaDB:

USE galtest;

SELECT * FROM messages;

El mensaje de prueba debería aparecer:

+----+--------------------+ | id | text | +----+--------------------+ | 7 | Test from galera0! | +----+--------------------+ 1 row in set (0.001 sec)

ProxySQL

ProxySQL dentro de esta configuración de clúster es más que un simple intermediario; mejora drásticamente el rendimiento, la fiabilidad y la manejabilidad de su base de datos. ProxySQL se sitúa como una capa crucial entre su(s) aplicación(es) y su clúster de Galera. Sus propósitos principales son:

  • Cacheo de Consultas: ProxySQL almacena en caché agresivamente las consultas ejecutadas con frecuencia. En lugar de consultar repetidamente el clúster de Galera por los mismos datos, sirve el resultado en caché, reduciendo significativamente la carga de la base de datos y mejorando los tiempos de respuesta. Esto es particularmente beneficioso para aplicaciones con muchas lecturas.
  • Pooling de Conexiones: ProxySQL mantiene un pool de conexiones persistentes al clúster de Galera. Establecer una conexión de base de datos es una operación que consume muchos recursos. El pooling de conexiones evita este sobrecarga reutilizando conexiones existentes, mejorando aún más el rendimiento.
  • Balanceo de Carga y Enrutamiento de Consultas: ProxySQL puede enrutar inteligentemente las consultas a diferentes nodos en su clúster de Galera basándose en factores como la carga del servidor, el tipo de consulta o la afinidad de datos. Esto le permite distribuir la carga de trabajo y maximizar el rendimiento de su clúster.
  • Optimización de Consultas: ProxySQL puede reescribir consultas para que sean más eficientes, potencialmente aprovechando las capacidades de Galera para una ejecución óptima.
  • Detección de Fallos y Enrutamiento: ProxySQL monitorea continuamente la salud de sus nodos de Galera. Si un nodo falla, ProxySQL automáticamente redirige las consultas a nodos saludables, asegurando un servicio ininterrumpido.

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

Precauciones

Info

Los inicios de sesión y contraseñas a continuación son solo para fines educativos. Use contraseñas fuertes para la configuración de producción.

Configuración de Usuarios

Usuario monitor

El usuario monitor dentro de ProxySQL es una cuenta de base de datos dedicada únicamente para que las herramientas de monitoreo accedan de manera segura a estadísticas y métricas internas. Está configurado con permisos mínimos: solo acceso SELECT, asegurando la integridad y seguridad de sus datos mientras permite un monitoreo de rendimiento integral.

Ejecute esta consulta en el shell de MariaDB en el nodo maestro para agregar el usuario monitor:

CREATE USER 'monitor'@'%' IDENTIFIED BY 'monitor';

GRANT SELECT ON *.* TO 'monitor'@'%';

FLUSH PRIVILEGES;

Usuario de aplicación

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

Ejecute esta consulta en el shell de MariaDB en el nodo maestro para agregar el usuario de aplicación:

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

FLUSH PRIVILEGES;

Verificación

Verifique la creación de usuarios en todos los nodos usando este comando:

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

Configuración

Cree un archivo de configuración /etc/proxysql.cnf en cada nodo y pegue 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 })

Habilite e inicie ProxySQL usando estos comandos:

sudo systemctl start proxysql

sudo systemctl enable proxysql

sudo proxysql --reload

Verifique su configuración de ProxySQL usando 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 de nodos. Monitorea la salud de los nodos de MariaDB y redirige el tráfico a un nodo saludable si ocurre un fallo, manteniendo alta disponibilidad. La configuración define el ID del Router 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 están configurados con un estado de BACKUP, teniendo prioridades de 90 y 80 respectivamente. La virtual_ipaddress se establece en 192.168.10.50 en todos los nodos. VIP y nodos deben estar en la misma subred. El hosting debe soportar VIP para VPS. La autenticación está habilitada con una contraseña compartida de 1234. La configuración advert_int define con qué frecuencia el nodo maestro envía anuncios VRRP. Un valor más bajo significa anuncios más frecuentes, potencialmente acelerando la detección de fallos; un valor más alto significa anuncios menos frecuentes, potencialmente retrasando el fallo pero reduciendo la sobrecarga de la red.

Configuración

Cree un archivo de configuración /etc/keepalived/keepalived.conf en cada nodo y pegue 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 } }

Cambie <NODE_STATE> y <NODE_PRIORITY> como se describió anteriormente. Habilite e inicie el servicio keepalived:

sudo systemctl enable keepalived && sudo systemctl start keepalived

Verificación

Para verificar la configuración, use el VIP configurado a través de Keepalived y el puerto configurado a través de ProxySQL. Verifique 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 nodos al azar, verificar el tamaño del clúster y la disponibilidad de datos.

Resultado de verificación del clúster de Keepalived

Conclusión

Esta guía ha demostrado cómo construir un clúster de MariaDB altamente disponible utilizando la replicación de Galera, ProxySQL para el enrutamiento de consultas y Keepalived para la gestión de IP virtual en Debian. Esta arquitectura proporciona varios beneficios clave, incluyendo alta disponibilidad con conmutación por error automatizada, consistencia de datos a través de replicación sincrónica y mejora del rendimiento a través de ProxySQL. Al combinar estas tecnologías, puede construir un entorno de base de datos robusto y resiliente capaz de manejar cargas de trabajo aumentadas y minimizar el tiempo de inactividad.

VAT

  • Other

    Ex. VAT

    0%
  • austria

    Austria

    20%
  • Belgium

    Belgium

    21%
  • Bulgaria

    Bulgaria

    20%
  • Croatia

    Croatia

    25%
  • Cyprus

    Cyprus

    19%
  • Czech Republic

    Czech Republic

    21%
  • Denmark

    Denmark

    25%
  • Estonia

    Estonia

    22%
  • France

    France

    20%
  • Finland

    Finland

    24%
  • Germany

    Germany

    19%
  • Greece

    Greece

    24%
  • Hungary

    Hungary

    27%
  • Ireland

    Ireland

    23%
  • Italy

    Italy

    22%
  • Latvia

    Latvia

    21%
  • Lithuania

    Lithuania

    21%
  • Luxembourg

    Luxembourg

    17%
  • Malta

    Malta

    18%
  • Netherlands

    Netherlands

    21%
  • Poland

    Poland

    23%
  • Portugal

    Portugal

    23%
  • Romania

    Romania

    19%
  • Slovakia

    Slovakia

    20%
  • Slovenia

    Slovenia

    22%
  • Spain

    Spain

    21%
  • Sweden

    Sweden

    25%
  • USA

    USA

    0%
european
states
  • germany
  • Español
  • Italiano
  • Poland
  • Русский
  • Slovenski
  • Türkçe
  • ukraine
  • kingdom
  • French
  • Hrvatska
  • Other
  • Austria
  • Belgium
  • Bulgaria
  • Croatia
  • Cyprus
  • Czech Republic
  • Denmark
  • Estonia
  • Finland
  • France
  • Germany
  • Greece
  • Hungary
  • Ireland
  • Italy
  • Latvia
  • Lithuania
  • Luxembourg
  • Malta
  • Netherlands
  • Poland
  • Portugal
  • Romania
  • Slovakia
  • Slovenia
  • Spain
  • Sweden
  • USA