HowtoForge

Tutoriales de Linux

Cómo configurar la replicación síncrona multimaster de MariaDB en Debian 10

MariaDB ofrece dos soluciones diferentes de alta disponibilidad (HA) y clustering. La primera es la replicación maestra/esclava estándar de MariaDB, que puede configurarse en diversas topologías, principalmente para equilibrar la carga, la HA y las copias de seguridad. La segunda es MariaDB Galera, una solución de clustering síncrono multimaster. Sus principales características son las siguientes

  • Multi-maestro: Todos los nodos de un clúster Galera pueden realizar operaciones de lectura y escritura, lo que ofrece una mayor escalabilidad.
  • Los nodos pueden unirse a un clúster automáticamente, y son desalojados en caso de fallo.
  • La replicación de Galera es sincrónica, lo que significa que se garantiza que los cambios en un nodo se apliquen en los demás nodos. En teoría, esto asegura que no se pierden datos cuando falla un nodo.

Esta guía te guiará a través de la instalación de MariaDB y su configuración en un clúster de Galera. Utilizaremos tres nodos Debian 10 para la demostración, aunque se puede utilizar cualquier número (≥3) de nodos. Configurar dos nodos en un clúster de Galera es técnicamente posible, pero no proporciona tolerancia a fallos, ya que un nodo que falle hará que el otro se detenga.

Requisitos

  • Tres o más instancias de Debian 10.
  • Acceso al usuario root o a cualquier usuario con privilegios sudo.
  • La variable de entorno $EDITOR debe estar activada.

NOTA: Los clusters de Galera pueden funcionar a través de WAN o LAN. Si tus nodos comparten una red privada, utiliza direcciones IP privadas cuando corresponda. En caso contrario, deben utilizarse direcciones WAN.

Si utilizas un usuario sudo, abre y utiliza un shell de root para la duración de esta configuración utilizando:

sudo -s

Paso 1: Instalación de MariaDB

Este paso debe ejecutarse en todos los nodos.

Utiliza los siguientes comandos para instalar MariaDB, la biblioteca Galera y Rsync. Este último es utilizado por Galera.

apt update
apt install -y mariadb-server mariadb-client galera-3 rsync

Asegúrate de que el servicio MariaDB está activado:

systemctl enable mariadb.service

Asegura tus instancias de MariaDB utilizando el script mysql_secure_installation:

mysql_secure_installation

Responde a las preguntas que se muestran a continuación y asegúrate de elegir una contraseña segura para el usuario raíz de MySQL.

Enter current password for root (enter for none): Press <Enter>
Set root password? [Y/n] y
New password: your_password
Re-enter new password: your_password
Remove anonymous users? [Y/n] y
Disallow root login remotely? [Y/n] y
Remove test database and access to it? [Y/n] y
Reload privilege tables now? [Y/n] y
All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.

Paso 2: Configurar MariaDB

Este paso debe ejecutarse en todos los nodos.

Detén el servicio MariaDB en todos los nodos:

systemctl stop mariadb.service

Por defecto, el demonio MariaDB sólo escucha conexiones en localhost. Para que el clúster funcione, debe cambiarse a una dirección de acceso externo. Para ello, edita el archivo de opciones /etc/mysql/mariadb.conf.d/50-server.cnf:

$EDITOR /etc/mysql/mariadb.conf.d/50-server.cnf

Busca la siguiente línea:

bind-address = 127.0.0.1

Si utilizas una red privada para el clúster y no quieres exponer MariaDB a otras redes (es decir, a la WAN), especifica la dirección IPv4 local de cada nodo. De lo contrario, utiliza 0.0.0.0, que indica a MariaDB que escuche en todas las interfaces. Por ejemplo:

bind-address = 0.0.0.0

Guarda el cambio y sal de tu editor de texto.

Ahora configuraremos las opciones relacionadas con el clúster. Crea un nuevo archivo de opciones:

$EDITOR /etc/mysql/mariadb.conf.d/99-cluster.cnf

Introduce la siguiente configuración sensata en el archivo, sustituyendo las direcciones IP. Debe ser idéntica en todos los nodos.

[galera]

wsrep_on = on 
wsrep_provider = /lib/galera/libgalera_smm.so 
wsrep_cluster_address = gcomm://192.0.2.1,192.0.2.2,192.0.2.3 
wsrep_cluster_name = galera_cluster_0 

default_storage_engine = InnoDB 
innodb_autoinc_lock_mode = 2 
innodb_doublewrite = 1 

binlog_format = ROW
  • wsrep_on = on activa la replicación de conjuntos de escritura, la funcionalidad subyacente utilizada por Galera.
  • wsrep_provider especifica la ruta a la biblioteca de galera. La proporciona el paquete galera-3 en /lib/galera/libgalera_smm.so en Debian 10.
  • wsrep_cluster_address debe contener al menos una dirección de otro miembro del clúster. Se recomienda listar todos los miembros del clúster. No es necesario ningún orden concreto.
  • wsrep_cluster_name debe ser único para el clúster y debe ser idéntico en todos los nodos del mismo clúster de galera.
  • El resto de opciones son necesarias para que Galera funcione correctamente y no deben modificarse.

Paso 3: Arrancar el clúster

Asegúrate de que MariaDB está parada/inactiva en todos los nodos antes de proceder:

systemctl status mariadb.service

Para iniciar el clúster, primero hay que crear un nodo. En Debian 10, esto puede hacerse con el script galera_new_cluster. El script sólo debe ejecutarse en un nodo, y sólo una vez para inicializar el clúster.

galera_new_cluster

Esto iniciará MariaDB en el nodo actual. Asegúrate de que se está ejecutando con:

systemctl status mariadb.service

A continuación, inicia MariaDB en los demás nodos con:

systemctl start mariadb.service

Ahora el clúster debería estar operativo.

Paso 4: Prueba

Para asegurarte de que el clúster funciona como es debido, elige cualquier nodo y entra en MariaDB:

mysql -u root -p

Emite la siguiente sentencia para crear una base de datos:

> CREATE DATABASE test0;
> \q

A continuación, comprueba esta nueva base de datos en todos los demás nodos:

mysql -u root -p -e "SHOW DATABASES;"

El comando anterior debería devolver una lista que contenga test0:

+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test0              |
+--------------------+

Es posible que quieras hacer una prueba más exhaustiva escribiendo en el clúster desde todos los nodos. Una vez que estés satisfecho con las pruebas, limpia las bases de datos innecesarias del clúster. Se puede utilizar cualquier nodo.

mysql -u root -p -e "DROP DATABASE test0;"

Paso 5: Consejos para la resolución de problemas

Utiliza la siguiente consulta para ver información sobre el estado actual del nodo/clúster:

mysql -u root -p -e "SELECT * FROM information_schema.global_status WHERE variable_name IN ('WSREP_CLUSTER_STATUS','WSREP_LOCAL_STATE_COMMENT','WSREP_CLUSTER_SIZE','WSREP_EVS_REPL_LATENCY','WSREP_EVS_DELAYED','WSREP_READY');"

Un clúster de 3 nodos en buen estado debería devolver lo siguiente

+---------------------------+----------------+
| VARIABLE_NAME             | VARIABLE_VALUE |
+---------------------------+----------------+
| WSREP_CLUSTER_SIZE        | 3              |
| WSREP_CLUSTER_STATUS      | Primary        |
| WSREP_EVS_DELAYED         |                |
| WSREP_EVS_REPL_LATENCY    | 0/0/0/0/0      |
| WSREP_LOCAL_STATE_COMMENT | Synced         |
| WSREP_READY               | ON             |
+---------------------------+----------------+
  • WSREP_CLUSTER_SIZE representa el número actual de nodos en el componente del clúster.
  • WSREP_CLUSTER_STATUS representa el estado del componente del clúster y no del clúster en su conjunto.
  • WSREP_EVS_DELAYED muestra una lista de nodos que están retrasados. Se espera un valor vacío en los clusters sanos.
  • WSREP_EVS_REPL_LATENCY muestra la latencia de replicación en el formato min/avg/max/stddev/samplesize. Los valores se muestran en segundos. Las latencias muy altas pueden provocar una degradación del rendimiento.
  • WSREP_LOCAL_STATE_COMMENT muestra el estado actual del nodo.
  • WSREP_READY indica si el nodo puede aceptar consultas.

Cuando un nodo de un cluster de 3 nodos pierde la conectividad, el cluster se divide en un componente primario formado por 2 nodos y un componente no primario. El componente primario no se ve afectado por la interrupción y sigue funcionando normalmente. Desde la perspectiva del componente no primario, la consulta mostrada anteriormente devolvería lo siguiente:

+---------------------------+--------------------------------------------------------------------------------------------------------------------------------+
| VARIABLE_NAME             | VARIABLE_VALUE                                                                                                                 |
+---------------------------+--------------------------------------------------------------------------------------------------------------------------------+
| WSREP_CLUSTER_SIZE        | 1                                                                                                                              |
| WSREP_CLUSTER_STATUS      | non-Primary                                                                                                                    |
| WSREP_EVS_DELAYED         | 6b7864f2-fe7d-11e9-84ab-93e58c0d2907:tcp://192.0.2.1:4567:3,a421be89-fe7d-11e9-a91e-7e62f7562e58:tcp://192.0.2.3:4567:2        |
| WSREP_EVS_REPL_LATENCY    | 0/0/0/0/0                                                                                                                      |
| WSREP_LOCAL_STATE_COMMENT | Initialized                                                                                                                    |
| WSREP_READY               | OFF                                                                                                                            |
+---------------------------+--------------------------------------------------------------------------------------------------------------------------------+

Fíjate en el valor WSREP_EVS_DELAYED, que indica problemas de conectividad con los demás nodos.

En los nodos del componente primario, la misma consulta devuelve:

+---------------------------+----------------------------------------------------------------+
| VARIABLE_NAME             | VARIABLE_VALUE                                                 |
+---------------------------+----------------------------------------------------------------+
| WSREP_CLUSTER_SIZE        | 2                                                              |
| WSREP_CLUSTER_STATUS      | Primary                                                        |
| WSREP_EVS_DELAYED         | a2217526-fe7d-11e9-8692-1f2f0cdb403d:tcp://192.0.2.2:4567:2    |
| WSREP_EVS_REPL_LATENCY    | 0/0/0/0/0                                                      |
| WSREP_LOCAL_STATE_COMMENT | Synced                                                         |
| WSREP_READY               | ON                                                             |
+---------------------------+----------------------------------------------------------------+

Para recuperarse de los fallos de un solo nodo, no es necesaria la intervención manual. Cuando el nodo que ha fallado se vuelve a conectar al clúster, se sincroniza con él automáticamente.

Más información

Para conocer las opciones de configuración avanzadas, consulta Variables del Sistema del Clúster Galera.

También te podría gustar...