Deshabilitar Master Failback en MaxScale para Galera
Introducción
El monitor de MaxScale galeramon incluye una opción para prevenir que un nodo que era Master recobre su rol original cuando se vuelva a unir a un Cluster de Galera.
Previamente probamos las funcionalidades de FailBack en la nota MaxScale con MariaDB Galera Cluster,
esta vez queremos configurar la opción disable_master_failback y validar que el nodo se vuelve a unir con el rol de Esclavo.
Deshabilitar el Master FailBack
Configurar el Monitor de MaxScale
Edita el archivo de configuración de MaxScale:
pato@patomaxgalera:~$ sudo nano /etc/maxscale.cnf
Ve a la sección del monitor de MaxScale y agrega el parámetro disable_master_failback=true:
[Pato-Monitor]
type=monitor
module=galeramon
servers=Pato-Node0,Pato-Node1,Pato-Node2
user=maxpato
password=xxxxxxxx
monitor_interval=2000
disable_master_failback=true
Guarda el archivo y reinicia MaxScale para que la nueva configuración se cargue:
pato@patomaxgalera:~$ sudo systemctl restart maxscale
pato@patomaxgalera:~$
FailBack
Ahora vamos a probar el comportamiento de los roles con esta nueva configuración cuando el nodo Master falla como se describe aquí:
Con esta opción habilitada, si el estatus master es asignado a un nuevo nodo éste on será reasignado al nodo original mientras el nuevo master siga en ejecución.
Revisemos el estado del Cluster de Galera enviando 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 ¦
+----------------------------------------------------------------------------------+
Detengamos el servidor designado patomariagm:
pato@patomariagm:~$ sudo systemctl stop mariadb
y valida el estado enviando 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-11 ¦
+------------+-------------+------+-------------+-------------------------+--------¦
¦ Pato-Node2 ¦ patomariag2 ¦ 3306 ¦ 0 ¦ Slave, Synced, Running ¦ 1-1-11 ¦
+------------+-------------+------+-------------+-------------------------+--------+
nuestro servidor es 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-06-08 21:43:16 notice : Server changed state: Pato-Node0[patomariagm:3306]: master_down. [Master, Synced, Running] -> [Down]
2020-06-08 21:43:16 notice : Server changed state: Pato-Node1[patomariag1:3306]: new_master. [Slave, Synced, Running] -> [Master, Synced, Running]
2020-06-08 21:43:16 notice : Master switch detected: lost a master and gained a new one
Entonces si iniciamos el servidor patomariagm éste no recobrará su estaus de Master:
pato@patomariagm:~$ sudo systemctl start 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 ¦ Slave, Synced, Running ¦ 1-1-12 ¦
+------------+-------------+------+-------------+--------------------------------------------+--------¦
¦ Pato-Node1 ¦ patomariag1 ¦ 3306 ¦ 0 ¦ Master, Synced, Master Stickiness, Running ¦ 1-1-12 ¦
+------------+-------------+------+-------------+--------------------------------------------+--------¦
¦ Pato-Node2 ¦ patomariag2 ¦ 3306 ¦ 0 ¦ Slave, Synced, Running ¦ 1-1-12 ¦
+-----------------------------------------------------------------------------------------------------+
Podemos ver que el cambio fue detectado en el registro de MaxScale:
pato@patomaxscale:~$ tail -f /var/log/maxscale/maxscale.log
2020-06-08 21:43:52 notice : Server changed state: Pato-Node0[patomariagm:3306]: slave_up. [Down] -> [Slave, Synced, Running]
Hemos validado que el role Master no fue reasignado al nodo original.
Restaurar el Rol de Master
Con el fin de regresar el rol de Master al servidor original necesitamos detener el Master actual:
pato@patomariag1:~$ sudo systemctl stop mariadb
y validamos enviando 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-14 ¦
+------------+-------------+------+-------------+-------------------------+--------¦
¦ Pato-Node1 ¦ patomariag1 ¦ 3306 ¦ 0 ¦ Down ¦ ¦
+------------+-------------+------+-------------+-------------------------+--------¦
¦ Pato-Node2 ¦ patomariag2 ¦ 3306 ¦ 0 ¦ Slave, Synced, Running ¦ 1-1-14 ¦
+----------------------------------------------------------------------------------+
Podemos ver que el cambio fue detectado en el registro de MaxScale:
pato@patomaxscale:~$ tail -f /var/log/maxscale/maxscale.log
2020-06-08 21:46:14 notice : Server changed state: Pato-Node0[patomariagm:3306]: new_master. [Slave, Synced, Running] -> [Master, Synced, Running]
2020-06-08 21:46:14 notice : Server changed state: Pato-Node1[patomariag1:3306]: master_down. [Master, Synced, Master Stickiness, Running] -> [Down]
2020-06-08 21:46:14 notice : Master switch detected: lost a master and gained a new one
Y finalmente volvemos a iniciar el servidor para regresar el estado original del cluster:
pato@patomariag1:~$ sudo systemctl start 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-15 ¦
+------------+-------------+------+-------------+-------------------------+--------¦
¦ Pato-Node1 ¦ patomariag1 ¦ 3306 ¦ 0 ¦ Slave, Synced, Running ¦ 1-1-15 ¦
+------------+-------------+------+-------------+-------------------------+--------¦
¦ Pato-Node2 ¦ patomariag2 ¦ 3306 ¦ 0 ¦ Slave, Synced, Running ¦ 1-1-15 ¦
+----------------------------------------------------------------------------------+
Podemos ver que el cambio fue detectado en el registro de MaxScale:
2020-06-08 21:47:04 notice : Server changed state: Pato-Node1[patomariag1:3306]: slave_up. [Down] -> [Slave, Synced, Running]
Conclusión
Hemos configurado MaxScale para evitar que un nodo Master fallido recobre su rol Master cuando se recupera y se vuelve a unir al Cluste de Galera y validamos este comportamiento en nuestra instalacion de Cluster de Galera para MariaDB con virtual machines en la Google Cloud Platform.