MariaDB ofrece dos soluciones diferentes de alta disponibilidad (HA) y clústeres. El primero es la replicación estándar de maestro/esclavo de MariaDB, que se puede configurar en diferentes topologías, principalmente con fines de equilibrio de carga, alta disponibilidad y respaldo. El segundo es MariaDB Galera, una solución de agrupamiento síncrono multimaestro. Sus principales características son las siguientes:
- Multimaestro:todos los nodos en un clúster de Galera pueden realizar operaciones de lectura y escritura, lo que ofrece una mejor escalabilidad.
- Los nodos pueden unirse a un clúster automáticamente y se desalojan si fallan.
- La replicación de Galera es síncrona, lo que significa que se garantiza que los cambios en un nodo se aplicarán en los otros nodos. En teoría, esto garantiza que no se pierdan datos cuando falla un nodo.
Esta guía lo guiará a través de la instalación de MariaDB y su configuración en un clúster de Galera. Usaremos tres nodos de Debian 10 para la demostración, aunque se puede usar cualquier número (≥3) de nodos. La configuración de dos nodos en un clúster de Galera es técnicamente posible, pero no proporciona tolerancia a fallas, ya que un nodo fallido hará que el otro nodo se detenga.
Requisitos
- Tres o más instancias de Debian 10.
- Acceso al usuario raíz o cualquier usuario con privilegios sudo.
- El $EDITOR se debe establecer la variable de entorno.
Si usa un usuario sudo, abra y use un shell raíz durante la duración de esta configuración usando:
sudo -s
Paso 1:Instalación de MariaDB
Este paso debe ejecutarse en todos los nodos.
Use 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úrese de que el servicio MariaDB esté habilitado:
systemctl enable mariadb.service
Asegure sus instancias de MariaDB usando el script mysql_secure_installation:
mysql_secure_installation
Responda las preguntas como se muestra a continuación y asegúrese de elegir una contraseña segura para el usuario root 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:Configuración de MariaDB
Este paso debe ejecutarse en todos los nodos.
Detenga el servicio MariaDB en todos los nodos:
systemctl stop mariadb.service
De forma predeterminada, el demonio de MariaDB escucha las conexiones solo en localhost. Para que el clúster funcione, debe cambiarse a una dirección accesible externamente. Para hacerlo, edite el archivo de opciones /etc/mysql/mariadb.conf.d/50-server.cnf:
$EDITOR /etc/mysql/mariadb.conf.d/50-server.cnf
Busque la siguiente línea:
bind-address = 127.0.0.1
Si está utilizando una red privada para el clúster y no desea exponer MariaDB a otras redes (es decir, WAN), especifique la dirección IPv4 local para cada nodo. De lo contrario, use 0.0.0.0 que le indica a MariaDB que escuche en todas las interfaces. Por ejemplo:
bind-address = 0.0.0.0
Guarde el cambio y salga de su editor de texto.
Ahora configuraremos las opciones relacionadas con el clúster. Cree un nuevo archivo de opciones:
$EDITOR /etc/mysql/mariadb.conf.d/99-cluster.cnf
Ingrese la siguiente configuración sensible en el archivo, reemplazando las direcciones IP. Debe ser idéntico 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 habilita la replicación de conjuntos de escritura, la funcionalidad subyacente utilizada por Galera.
- wsrep_provider especifica la ruta a la biblioteca galera. Lo 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 enumerar todos los miembros del clúster. No es necesario ningún orden en particular.
- 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.
- Las opciones restantes son necesarias para que Galera funcione correctamente y no deben cambiarse.
Paso 3:arranque del clúster
Asegúrese de que MariaDB esté detenido/inactivo en todos los nodos antes de continuar:
systemctl status mariadb.service
Para iniciar el clúster, primero se debe crear un nodo. En Debian 10, esto se puede hacer con el script galera_new_cluster. El script solo debe ejecutarse en un nodo y solo una vez para inicializar el clúster.
galera_new_cluster
Esto iniciará MariaDB en el nodo actual. Asegúrese de que se está ejecutando con:
systemctl status mariadb.service
Luego inicie MariaDB en los otros nodos con:
systemctl start mariadb.service
El clúster ahora debería estar operativo.
Paso 4:Prueba
Para asegurarse de que el clúster funcione según lo previsto, elija cualquier nodo e inicie sesión en MariaDB:
mysql -u root -p
Emita la siguiente instrucción para crear una base de datos:
> CREATE DATABASE test0; > \q
Luego busque 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 desee realizar pruebas más exhaustivas escribiendo en el clúster desde cada nodo. Una vez que esté satisfecho con las pruebas, limpie las bases de datos innecesarias del clúster. Se puede utilizar cualquier nodo.
mysql -u root -p -e "DROP DATABASE test0;"
Paso 5:Sugerencias para la resolución de problemas
Utilice 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 como un todo.
- WSREP_EVS_DELAYED muestra una lista de nodos que están retrasados. Se espera un valor vacío de los clústeres en buen estado.
- 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 un rendimiento degradado.
- WSREP_LOCAL_STATE_COMMENT muestra el estado actual del nodo.
- WSREP_READY indica si el nodo puede aceptar consultas.
Cuando un nodo en un clúster de 3 nodos pierde la conectividad, el clúster se divide en un componente principal que consta de 2 nodos y un componente no principal. El componente principal no se ve afectado por la interrupción y sigue funcionando con normalidad. Desde la perspectiva del componente no principal, la consulta que se muestra arriba 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 | +---------------------------+--------------------------------------------------------------------------------------------------------------------------------+
Observe el valor WSREP_EVS_DELAYED, que indica problemas de conectividad con los otros nodos.
En los nodos de componentes principales, 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 fallas de un solo nodo, no se requiere intervención manual. Cuando el nodo fallido se vuelve a conectar al clúster, se sincroniza con el clúster automáticamente.
Más información
Para conocer las opciones de configuración avanzada, consulte Variables del sistema de clúster de Galera.