MaxScale con MariaDB Galera Cluster en Instancias Virtuales

May 15, 2020 8-minute read

MaxScale • MariaDB • Galera • Google Cloud

Introducción

MaxScale tiene un módulo llamado galeramon que nos ayuda a monitorear e interactuar con un Cluster de Galera para MariaDB. Como se describe en la Documentación del Monitor de Galera sus principales funcionalidades son:

Detecta si los nodos son parte del cluster y si ellos están sincronizados con el resto del cluster.

También puede asignar roles Master y Esclavo dentro de MaxScale

En una nota previa instalamos y configuramos MaxScale para Replicación Master Esclavo en esta ocasión vamos a explorar las funcionalidades de MaxScale para Cluster de Galera.

Prerrequisitos

Necesitamos un ambiente de replicación Cluster de Galera para MariaDB.
Para este ejercicio vamos a usar nuestra instalación que realizamos con la nota Cluster de Galera para MariaDB en virtual machine instances de Google Cloud Platform.

Instalación de MaxScale

Instancia de MaxScale

Crea una nueva máquina virtual con los siguientes parámetros:

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

Name: patomaxgalera
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: patomaxgalera.databases

Valida que la nueva instancia de MaxScale junto con las instancias de base de datos estén levantadas y en ejecución:

$ gcloud compute instances list
NAME           ZONE           MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP     STATUS
patomariag1    us-central1-f  f1-micro                   10.128.0.48  35.223.249.103  RUNNING
patomariag2    us-central1-f  f1-micro                   10.128.0.49  35.226.17.216   RUNNING
patomariagm    us-central1-f  f1-micro                   10.128.0.47  34.66.218.222   RUNNING
patomaxgalera  us-central1-f  f1-micro                   10.128.0.39  34.72.63.92     RUNNING

Software de MaxScale

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

pato@patomaxgalera:~$ 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@patomaxgalera:~$ 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@patomaxgalera:~$

Configuración de MaxScale

Crear un Usuario de Base de Datos para MaxScale

Accede a cualquiera de los nodos en Galera, conéctate a la base de datos y crea el usuario de monitoreo de MaxScale maxpato con los siguientes privilegios:

pato@patomariag1:~$ mysql

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

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

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

Crear un Archivo de Configuración para Cluster de Galera

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

pato@patomaxgalera:~$ sudo mv /etc/maxscale.cnf /etc/maxscale.bkp
pato@patomaxgalera:~$ sudo nano /etc/maxscale.cnf

Definir el host y puerto de los servidores en la replicación.

[Pato-Node0]
type=server
address=patomariagm
port=3306
protocol=MariaDBBackend

[Pato-Node1]
type=server
address=patomariag1
port=3306
protocol=MariaDBBackend

[Pato-Node2]
type=server
address=patomariag2
port=3306
protocol=MariaDBBackend

Designar el monitor de MaxScale usando el módulo galeramon ya que ésta es una replicación de Galera.
Configurar el usuario y contraseña para el usuario de monitoreo.

[Pato-Monitor]
type=monitor
module=galeramon
servers=Pato-Node0,Pato-Node1,Pato-Node2
user=maxpato
password=********
monitor_interval=2000

Definir el Servicio para la distribución lectura escritura entre el Node0 y el Node1 escuchando en el puerto 4006.

[RW-Service]
type=service
router=readwritesplit
servers=Pato-Node0,Pato-Node1
user=maxpato
password=********

[RW-Listener]
type=listener
service=RW-Service
protocol=MariaDBClient
port=4006

Definir el Servicio para sólo lectura en el Node2 escuchando en el puerto 4008.

[RO-Service]
type=service
router=readconnroute
servers=Pato-Node2
user=maxpato
password=********
router_options=slave

[RO-Listener]
type=listener
service=RO-Service
protocol=MariaDBClient
port=4008

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@patomaxgalera:~$ sudo systemctl restart maxscale
pato@patomaxgalera:~$

Validar que MaxScale está en Ejecución

Valida que los servicios estén en ejecución y escuchando enviando el comando maxadmin -pmariadb list listeners:

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
RO-Listener          | RO-Service          | MariaDBClient      | ::              |  4008 | Running
---------------------+---------------------+--------------------+-----------------+-------+--------

Funcionalidades de MaxScale

Punto Único de Acceso y Balanceo de Carga

Como ya tenemos nuestro MaxScale corriendo ya no necesitamos conectarnos directamente a alguna de las instancias de base de datos.
Para las conexiones remotas necesitamos apuntar nuestro cliente o aplicación hacia la instancia de MaxScale en el puerto 4006 para que las actividades de lectura escritura se balanceen entre el Node0 y el Node1:

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

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

o conectarnos al puerto 4008 para una conexión de sólo lectura fija en el Node2:

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

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

Podemos ver que nos estamos conectando al servidor de MaxScale y que somos redireccionados hacia los nodos del cluster de acuerdo a nuestra configuración.

Monitorar que los Nodos están Sincronizados

Como se mencionó anteriormente, una particularidad del monitor galeramon es su capacidad de monitorear cuando los nodos del cluster están sincronizados:

pato@patomaxscale:~$ maxadmin -pmariadb list servers
Servers.
-------------------+-----------------+-------+-------------+--------------------
Server             | Address         | Port  | Connections | Status
-------------------+-----------------+-------+-------------+--------------------
Pato-Node0         | patomariagm     |  3306 |           0 | Master, Synced, Running
Pato-Node1         | patomariag1     |  3306 |           0 | Slave, Synced, Running
Pato-Node2         | patomariag2     |  3306 |           0 | Slave, Synced, Running
-------------------+-----------------+-------+-------------+--------------------

Podemos ver que los nodos de Galera no solo están marcados en ejecución Running sino también sincronizados Synced.

Asignar Roles Master Esclavo

La otra funcionalidad es poder asignar roles Maestro y Esclavo dentro de MaxScale para que podamos ver cuál es el nodo bootstrap/donante.

Por defecto, el Monitor de Galera escogerá aquel nodo con el menor valor en wsrep_local_index como el Master.

Mandemos el comando maxctrl list servers:

pato@patomaxscale:~$ maxctrl list servers
+---------------------------------------------------------------------------------+
¦ Server     ¦ Address     ¦ Port ¦ Connections ¦ State                   ¦ GTID  ¦
+------------+-------------+------+-------------+-------------------------+-------¦
¦ Pato-Node0 ¦ patomariagm ¦ 3306 ¦ 0           ¦ Master, Synced, Running ¦ 1-1-8 ¦
+------------+-------------+------+-------------+-------------------------+-------¦
¦ Pato-Node1 ¦ patomariag1 ¦ 3306 ¦ 0           ¦ Slave, Synced, Running  ¦ 1-1-8 ¦
+------------+-------------+------+-------------+-------------------------+-------+
¦ Pato-Node2 ¦ patomariag2 ¦ 3306 ¦ 0           ¦ Slave, Synced, Running  ¦ 1-1-8 ¦
+------------+-------------+------+-------------+-------------------------+-------+

Como podemos ver la columa State muestra los roles asignados y también se muestra el GTID compartido en el cluster.

Master FailBack

Ahora vamos a probar el comportamiento de los roles cuando el nodo Master falla, como se describe aquí:

Si un nodo marcado como Master dentro de MaxScale falla y ese estatus es asignado a otro nodo, el MaxScale normalmente regresará el estatus de Master al nodo original luego de que regrese.

Detengamos el servidor designado patomariagm:

pato@patomariagm:~$ sudo systemctl stop mariadb

y validemos su estado mandando el comando maxctrl list servers:

pato@patomaxscale:~$ maxctrl list servers
+---------------------------------------------------------------------------------+
¦ Server     ¦ Address     ¦ Port ¦ Connections ¦ State                   ¦ GTID  ¦
+------------+-------------+------+-------------+-------------------------+-------¦
¦ Pato-Node0 ¦ patomariagm ¦ 3306 ¦ 0           ¦ Down                    ¦       ¦
+------------+-------------+------+-------------+-------------------------+-------¦
¦ Pato-Node1 ¦ patomariag1 ¦ 3306 ¦ 0           ¦ Master, Synced, Running ¦ 1-1-9 ¦
+------------+-------------+------+-------------+-------------------------+-------¦
¦ Pato-Node2 ¦ patomariag2 ¦ 3306 ¦ 0           ¦ Slave, Synced, Running  ¦ 1-1-9 ¦
+------------+-------------+------+-------------+-------------------------+-------+

nuestro servidor queda marcado como Down y el siguiente servidor es promovido a Master. Podemos ver que el cambio de roles fue detectado en el registro de MaxScale:

pato@patomaxscale:~$ tail -f /var/log/maxscale/maxscale.log

2020-05-15 20:14:37   notice : Server changed state: Pato-Node0[patomariagm:3306]: master_down. [Master, Synced, Running] -> [Down]
2020-05-15 20:14:37   notice : Server changed state: Pato-Node1[patomariag1:3306]: new_master. [Slave, Synced, Running] -> [Master, Synced, Running]
2020-05-15 20:14:37   notice : Master switch detected: lost a master and gained a new one

Entonces si iniciamos el servidor patomariagm éste recobrará su estaus de Master:

pato@patomariagm:~$ sudo systemctl star mariadb

y lo validamos mandando el comando maxctrl list servers:

pato@patomaxscale:~$ maxctrl list servers

+----------------------------------------------------------------------------------+
¦ Server     ¦ Address     ¦ Port ¦ Connections ¦ State                   ¦ GTID   ¦
+------------+-------------+------+-------------+-------------------------+--------¦
¦ Pato-Node0 ¦ patomariagm ¦ 3306 ¦ 0           ¦ Master, Synced, Running ¦ 1-1-10 ¦
+------------+-------------+------+-------------+-------------------------+--------¦
¦ Pato-Node1 ¦ patomariag1 ¦ 3306 ¦ 0           ¦ Slave, Synced, Running  ¦ 1-1-10 ¦
+------------+-------------+------+-------------+-------------------------+--------¦
¦ Pato-Node2 ¦ patomariag2 ¦ 3306 ¦ 0           ¦ Slave, Synced, Running  ¦ 1-1-10 ¦
+------------+-------------+------+-------------+-------------------------+--------+

Podemos ver que el cambio fue detectado en el registro de MaxScale:

pato@patomaxscale:~$ tail -f /var/log/maxscale/maxscale.log

2020-05-15 20:35:37   notice : Server changed state: Pato-Node0[patomariagm:3306]: master_up. [Down] -> [Master, Synced, Running]
2020-05-15 20:35:37   notice : Server changed state: Pato-Node1[patomariag1:3306]: new_slave. [Master, Synced, Running] -> [Slave, Synced, Running]

Hemos validado que el role Master fue reasignado al nodo original.

Conclusión

Hemos instalado exitosamente MaxScale en nuestro ambiente de máquinas virtuales de Google Cloud y lo hemos configurado para monitorear nuestro Cluster de Galera para MariaDB. Asimismo fuimos capaces de validar las funcionalidades descritas tales como detección de Sincronía, asignación de Roles y el Master Failback.