MaxScale con Replicación de MariaDB en Instancias Virtuales

7-minute read
MariaDB
MaxScale • MariaDB • Google Cloud

Introducción

Cuando instalas un cluster de Replicación de MariaDB tendrás dos o más instancias de base de datos que deben actuar como una sola unidad. Para las aplicaciones sólo hay una sola base y ellas deben poderse conectar y trabajar, independientemente de la arquitectura de la base de datos.
Para resolver esto necesitamos usar MaxScale, un software proxy que provee un único punto de acceso a la base de datos y que también incluye otros beneficios como el Balanceo de Carga y el Failover.
Vamos a configurar MaxScale y probar sus funcionalidades de Failover.

Prerrequisitos

Necesitamos un cluster de Replicación Master Esclavo de MariaDB. Para este ejercicio vamos a usar nuestra instalación en Google Cloud Platform para la Replicación Master Esclavo de MariaDB en virtual machine instances.

Instalación de MaxScale

Instancia para MaxScale

Crea una nueva Máquina Virtual con los siguientes parámetros:

En Google Cloud Platform - Compute Engine - VM Instances - Create Instance

  • Name: patomaxscale
  • Type: f1-micro (1 vCPU, 0.6 GB memory)
  • Image: Ubuntu 20.04 LTS
    • Standard persistent disk: 10GB
  • Identity and API access
    • Access scopes: Set access for each API
      • Compute Engine: Read Write
      • Storage: Full
  • Networking
    • Hostname: patomaxscale.databases

Valida que la nueva instancia de MaxScale y las instancias de base de datos estén arriba y funcionando:

$ gcloud compute instances list
NAME          ZONE           MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP     STATUS
patomariadb   us-central1-f  f1-micro                   10.128.0.40  34.69.159.12    RUNNING
patomariarp   us-central1-f  f1-micro                   10.128.0.41  35.192.48.122   RUNNING
patomaxscale  us-central1-f  f1-micro                   10.128.0.42  104.197.32.181  RUNNING

Software de MaxScale

Conéctate vía ssh a tu nueva instancia. Descarga e instala el software de MaxScale:

pato@patomaxscale:~$ wget https://downloads.mariadb.com/MaxScale/2.4.9/ubuntu/dists/bionic/main/binary-amd64/maxscale-2.4.9-1.ubuntu.bionic.x86_64.deb

maxscale-2.4.9-1.ubuntu.b 100%[====================================>]  37.63M  16.5MB/s    in 2.3s

pato@patomaxscale:~$ sudo dpkg -i maxscale-2.4.9-1.ubuntu.bionic.x86_64.deb
Selecting previously unselected package maxscale.
(Reading database ... 93284 files and directories currently installed.)
Preparing to unpack maxscale-2.4.9-1.ubuntu.bionic.x86_64.deb ...
Unpacking maxscale (2.4.9) ...
Setting up maxscale (2.4.9) ...
...
pato@patomaxscale:~$

Configuración de MaxScale

Crear un Usuario de Base de Datos para MaxScale

Conéctate a la base de datos Master y crea el usuario de monitoreo de MaxScale maxpato con los privilegios adecuados de acuerdo a la Documentación del Monitor de Maria DB:

SUPER, para modificar las conexiones esclavo y configurar variables globales como read_only
REPLICATION CLIENT, para listar las conexiones esclavo
RELOAD, para liberar los binary logs
PROCESS, para revisar si el proceso event_scheduler está en ejecución
SHOW DATABASES y EVENT, para listar y modificar los eventos del servidor

pato@patomariadb:~$ mysql

MariaDB [mysql]> GRANT SELECT ON mysql.* TO 'maxpato'@'%' IDENTIFIED BY '********';
Query OK, 0 rows affected (0.095 sec)

MariaDB [mysql]> GRANT SUPER, REPLICATION CLIENT, REPLICATION SLAVE, RELOAD, PROCESS, SHOW DATABASES, EVENT ON *.* TO 'maxpato'@'%';
Query OK, 0 rows affected (0.000 sec)

MariaDB [mysql]> flush privileges ;
Query OK, 0 rows affected (0.001 sec)

Crear un Archivo de Configuración para Master-Esclavo

Crea un nuevo archivo de configuración con los siguientes parámetros:

pato@patomaxscale:~$ sudo mv /etc/maxscale.cnf /etc/maxscale.bkp
pato@patomaxscale:~$ sudo nano /etc/maxscale.cnf
  • Definir el host y puerto de los servidores en la replicación
[Pato-Master]
type=server
address=patomariadb
port=3306
protocol=MariaDBBackend

[Pato-Slave]
type=server
address=patomariarp
port=3306
protocol=MariaDBBackend
  • Designar el monitor de MaxScale, usando el módulo mariadbmon ya que ésta es una replicación Master-Esclavo.
    Configurar el usuario y contraseña para el usuario de monitoreo.
    Definir los parámetros para Failover y Rejoin automáticos
[Pato-Monitor]
type=monitor
module=mariadbmon
servers=Pato-Master,Pato-Slave
user=maxpato
password=xxxxxxxx
monitor_interval=2000
auto_failover=true
auto_rejoin=true
  • Definir el Servicio para la distribución lectura escritura entre el Master y Esclavo escuchando en el puerto 4006.
[RW-Service]
type=service
router=readwritesplit
servers=Pato-Master,Pato-Slave
user=maxpato
password=********

[RW-Listener]
type=listener
service=RW-Service
protocol=MariaDBClient
port=4006
  • Definir el Servicio para la interface de Línea de Comandos maxadmin y maxctrl escuchando en el puerto 6603.
[CLI]
type=service
router=cli

[CLI-Listener]
type=listener
service=CLI
protocol=maxscaled
address=127.0.0.1
port=6603

Guarda el archivo y reinicia el MaxScale para que la nueva configuración se cargue:

pato@patomaxscale:~$ sudo systemctl restart maxscale
pato@patomaxscale:~$

Validar que MaxScale está en Ejecución

Conéctate a la instancia de MaxScale y valida que esté monitoreando las bases de datos configuradas enviando el comando maxadmin list servers:

pato@patomaxscale:~$ maxadmin -pmariadb list servers
Servers.
-------------------+-----------------+-------+-------------+--------------------
Server             | Address         | Port  | Connections | Status
-------------------+-----------------+-------+-------------+--------------------
Pato-Master        | patomariadb     |  3306 |           0 | Master, Running
Pato-Slave         | patomariarp     |  3306 |           0 | Slave, Running
-------------------+-----------------+-------+-------------+--------------------

y valida que los servicios estén en ejecución y escuchando:

pato@patomaxscale:~$ maxadmin -pmariadb list listeners
Listeners.
---------------------+---------------------+--------------------+-----------------+-------+--------
Name                 | Service Name        | Protocol Module    | Address         | Port  | State
---------------------+---------------------+--------------------+-----------------+-------+--------
RW-Listener          | RW-Service          | MariaDBClient      | ::              |  4006 | Running
CLI-Listener         | CLI                 | maxscaled          | 127.0.0.1       |  6603 | Running
---------------------+---------------------+--------------------+-----------------+-------+--------

Conexión a la Base de Datos usando MaxScale

Ahora que nuestro MaxScale está funcionando ya no tenemos que conectarnos directamente a la base de datos Master. Para las conexiones remotas debemos apuntar nuestro cliente o aplicación hacia el puerto 4006 de la instancia de MaxScale y así las actividades se balancearán entre el Master y el Esclavo:

$ mysql -u remoto -p -h patomaxmsr -P 4006
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.

MariaDB [(none)]>

Functionalidades Automáticas

En nuestro archivo de configuración de MaxScale configuramos las opciones de auto_failover y auto_rejoin:

auto_failover=true
auto_rejoin=true

Con estas opciones MaxScale ayuda a nuestro Cluster de MariaDB a automatizar las actividades del failover, rejoin y switchover en caso de que algunos de los nodos falle y se recupere:

Failover reemplaza un master fallido usando el esclavo en ejecución
Rejoin vuelve a unir a un servidor al cluster e inicia ahí la replicación esclavo
Switchover intercambio entre un master y un esclavo en ejecución

Probemos estas funcionalidades.

Failover

Vamos a detener la base de datos Master y probemos el failover automático:

pato@patomariadb:~$ sudo systemctl stop mariadb
pato@patomariadb:~$

El Master se cae y el Esclavo es promovido al rol de Master automáticamente. Validemos esto ejecutando el comando maxctrl list servers:

pato@patomaxscale:~$ maxctrl list servers
+-----------------------------------------------------------------------------+
¦ Server      ¦ Address     ¦ Port ¦ Connections ¦ State           ¦ GTID     ¦
+-------------+-------------+------+-------------+-----------------+----------¦
¦ Pato-Master ¦ patomariadb ¦ 3306 ¦ 0           ¦ Down            ¦ 0-1-9    ¦
+-------------+-------------+------+-------------+-----------------+----------¦
¦ Pato-Slave  ¦ patomariarp ¦ 3306 ¦ 0           ¦ Master, Running ¦ 0-11-130 ¦
+-------------+-------------+------+-------------+-----------------+----------+

notar que el GTID se sigue moviendo en el nodo en ejecución ya que todas las actualizaciones se realizan ahora en el nuevo Master.

Disponibilidad

Como usamos el MaxScale para conectarnos a la base de datos, aun cuando la instancia patomariadb Pato-master ha fallado, los usuarios aún pueden trabajar ya que las conexiones se redireccionan transparentemente a la instancia patomariarp Pato-Slave:

$ mysql -u remoto -p -h patomaxscale -P 4006
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 6

MariaDB [(none)]> select @@hostname;
+-------------+
| @@hostname  |
+-------------+
| patomariarp |
+-------------+
1 row in set (0.001 sec)

Rejoin

Cuando el servidor patomariadb se recupere éste se unirá automáticamente al cluster de replicación pero esta vez en el rol de Esclavo. Validemos esto ejecutando el comando maxctrl list servers:

pato@patomariadb:~$ sudo systemctl start mariadb
pato@patomariadb:~$

pato@patomaxscale:~$ maxctrl list servers
+-----------------------------------------------------------------------------+
¦ Server      ¦ Address     ¦ Port ¦ Connections ¦ State           ¦ GTID     ¦
+-------------+-------------+------+-------------+-----------------+----------¦
¦ Pato-Master ¦ patomariadb ¦ 3306 ¦ 0           ¦ Slave, Running  ¦ 0-11-130 ¦
+-------------+-------------+------+-------------+-----------------+----------¦
¦ Pato-Slave  ¦ patomariarp ¦ 3306 ¦ 0           ¦ Master, Running ¦ 0-11-130 ¦
+-------------+-------------+------+-------------+-----------------+----------+

También podemos ver que el identificador global de transacciones GTID es de nuevo el mismo en ambas instancias, es decir que se han sincronizado después del Rejoin.

Switchover

Si todo está bien con el servidor Master original, tal vez querramos cambiar los roles Master-Esclavo a los que eran originalmente. Para esto tenemos que ejecutar manualmente el comando mariadbmon switchover:

pato@patomaxscale:~$ maxctrl call command mariadbmon switchover Pato-Monitor Pato-Master Pato-Slave -t 600000
OK
pato@patomaxscale:~$ maxctrl list servers
+----------------------------------------------------------------------------+
¦ Server      ¦ Address     ¦ Port ¦ Connections ¦ State           ¦ GTID    ¦
+-------------+-------------+------+-------------+-----------------+---------¦
¦ Pato-Master ¦ patomariadb ¦ 3306 ¦ 0           ¦ Master, Running ¦ 0-1-131 ¦
+-------------+-------------+------+-------------+-----------------+---------¦
¦ Pato-Slave  ¦ patomariarp ¦ 3306 ¦ 0           ¦ Slave, Running  ¦ 0-1-131 ¦
+-------------+-------------+------+-------------+-----------------+---------+

Después del intercambio de roles podemos ver que el GTID ha cambiado de 0-11-# a 0-1-# (ya que el serverid de patomariadb es 1 y el de patomariarp es 11).

Conclusión

Hemos instalado exitosamente MaxScale en nuestro ambiente de máquinas virtuales de Google Cloud y lo hemos configurado para monitorear y controlar a nuestro cluster de Replicación Master Esclavo de MariaDB.

Al conectarnos a MariaDB a través de MaxScale aseguramos la Disponibilidad por la automatización de las actividades de Failover cuando algun nodo falla, y también nos ayuda con el Balanceo de Carga cuando todos los nodos están disponibles.