Backup online y consistente en MySQL Cluster

En MySQL Cluster existen diferentes formas de hacer backup y debido a su arquitectura distribuida hay unas más recomendables que otras. Aquí vamos a ver la nativa, usando el cliente nbd_mgm. Desde esta herramienta de control podremos lanzar ordenes de backup que ejecutará cada nodo de almacenamiento, sacando un snapshot consistente de los datos y sin necesidad de parar el sistema.

Un backup en MySQL Cluster consiste en tres ficheros:

• Metadatos

BACKUP-backup_id.node_id.ctl

Es un fichero donde se guardan las definiciones de las tablas.

• Datos de las tablas

BACKUP-backup_id-0.node_id.data

Cada nodo guardará en este fichero los fragmentos de las tablas que gestiona.

• Log de transacciones

BACKUP-backup_id.node_id.log

Es el log de las transacciones con commit de las que se harán backup.

Siendo backup_id el identificador del backup y node_id el identificador del nodo. Cada nodo guardará los ficheros en su disco local, pero es recomendable que todos escriban al mismo destino, posiblemente un NAS, ya que a la hora de recuperar tendremos que tener accesibles todos los ficheros de cada nodo desde una única ubicación.

Para lanzar el backup nos conectamos con la utilidad ndb_mgm al management node y ejecutamos:

ndb_mgm> START BACKUP

Por defecto la herramienta se quedará parada (no podremos ejecutar más comandos) hasta que el backup se complete (WAIT COMPLETED). Pero podremos cambiar este comportamiento añadiendo el parámetro NOWAIT o WAIT STARTED.

Para parar un backup:

ndb_mgm> ABORT BACKUP id

Para definir donde queremos que vayan nuestros backups debemos hacer global para todos los nodos el parámetro BackupDataDir.

Como hemos visto, hacer un backup en caliente es sencillo y no tienen ningún tipo de downtime. Esto no es así para el proceso de restauración, que no debería hacerse online. Como indica la documentación de MySQL, el engine NDB no soporta repeatable reads. Por lo tanto durante el proceso de restauración las transacciones en ejecución reciben lecturas no repetidas (nonrepeatable) y por lo tanto tendremos datos incosistentes.

Se recomienda por ello hacer la restauración con el Cluster parado para evitar esta serie de problemas. Para ello lanzamos el Cluster en Single Mode de forma que un único API node (ndb_restore) tenga acceso a los datos.

Para restaurar un backup haremos uso de la utilidad ndb_restore:

ndb_restore [-c connectstring] -n node_id [-m] -b backup_id -r 
--backup_path=/path/to/backup/files

Donde:

• connectstring: dirección ip y puerto del management node.
• node_id: número de nodo a restaurar
• backup_id: id de backup a restaurar
• -m: si deseamos recrear las tablas a partir de los metadatos
• backup_path: ruta donde se encuentran los archivos con nuestros backups

Habrá que ejecutarlo una vez por cada nodo. Una vez restaurado podemos salir del Single Mode y permitir así de nuevo el acceso a los lusers.

Añadir nodos online a nuestro MySQL Cluster

A partir de la versión 7.0 y 7.1 se han añadido nuevas funcionalidades a MySQL Cluster que aumentan tanto la escalabilidad como el rendimiento de la base de datos. La nueva mejora que hoy voy a tratar aquí es la posibilidad de añadir nuevos nodos de almacenamiento a nuestro cluster en caliente sin necesidad de hacer una parada de mantenimiento.

A la hora de escalar nuestro cluster hay que tener en cuenta siempre el número de réplicas (NoOfReplicas) y el número de nodos que queremos. Debemos recordar que dicho número debe ser divisible y al mismo tiempo que tanto uno como otro tienen un límite. En el ejemplo que voy a mostrar tendremos la base de datos con dos réplicas y dos nodos y lo pasaremos a 2 réplicas y 4 nodos. De esta forma, pasaremos de tener un único Node Group (2/2=1) a tener dos Node Groups (4/2=2).

El primer paso es configurar los Management Node. Para ello añadimos los dos nuevos ndbd a los ficheros config.ini:

[ndbd]
Id = 1
Hostname = 192.168.1.10
[ndbd]
Id = 2
Hostname = 192.168.1.11
[ndbd]
Id = 3
Hostname = 192.168.1.12
[ndbd]
Id = 4
Hostname = 192.168.1.13

A continuación reiniciamos todos los Management Nodes para que lean el nuevo fichero de configuración y una vez en marcha haremos lo mismo con los Data Nodes que ya están en funcionamiento:

# db_mgmd -f config.ini –reload
ndb_mgm> 1 RESTART
ndb_mgm> 2 RESTART

De la misma forma, reiniciamos nuestros SQL Nodes con el típico /etc/init.d/mysqld restart

Iniciamos los dos nuevos nodos con --initial:

3 #> ndbd --initial
4 #> ndbd --initial

Desde la consola de administración creamos el nuevo Node Group incluyendo los nuevos nodos 3 y 4:

ndb_mgm> CREATE NODEGROUP 3,4

Desde un SQL Node lanzamos el reparticionado de cada tabla para que los datos y los índices se repartan entre los 4 nodos existentes.

mysql> ALTER ONLINE TABLE productos REORGANIZE PARTITION;
mysql> ALTER ONLINE TABLE clientes REORGANIZE PARTITION;
mysql> ALTER ONLINE TABLE ventas REORGANIZE PARTITION;

Una vez hecho, se recomienda un OPTIMIZE TABLE en las tablas para "desfragmentar" los dos nodos originales.

Listo, hemos pasado de una infraestructura de dos nodos a una de cuatro sin ninguna parada de servicio. Nadie se ha enterado y hemos aumentado el throughput y la disponibilidad de nuestro cluster.

Ya soy certificado en MySQL Cluster 5.1

Finalmente, aunque estuve a punto de tirar la toalla, estoy certificado en MySQL Cluster. Después de múltiples problemas con el soporte de Oracle y el /ignore que me había puesto Prometric, pude hacer el exámen. Tengo que dar las gracias a Brandye Barrington de Oracle, sin su ayuda mi certificado de MySQL DBA5.0 aún estaría en el limbo entre PearsonVUE y Prometric. Gracias a el tuve mi certificado migrado y pude examinarme :)

Sobre MySQL Cluster que decir... una gran herramienta pensada para ofrecer un rendimiento brutal y una alta disponibilidad casi perfecta. La verdad, tener un servidor MySQL Cluster con 50 GB de RAM y que toda la BBDD e índices estén en RAM y particionados por múltiples nodos... me suena como una poesía :) Espero que la herramienta siga avanzando, ya que es la mejor solución libre que existe para bases de datos gigantes, con necesidades de alto throughput, escalabilidad, alta disponibildiad y failover. Vamos, que la replicación master-master es para pobres ;) Próximamente iré publicando distintos posts relacionados con MySQL Cluster para todos vosotr@s.

Ahora estoy preparando la certificación OCA de Oracle 11g, que es otro mundo completamente distinto. Pero de momento, aquí va el logo de mi nueva certificación en MySQL Cluster 5.1.

YEAHHH!!!!111

Arrancando nuestro primer cluster

Una vez que conocemos la teoría, vamos a poner en marcha nuestro primer Cluster. Estará compuesto únicamente por 3 ordenadores.

Nodo 1 (192.168.1.106):

• ndb_mgmd
• mysqld

Nodo 2 (192.168.1.104):

• ndbd

Nodo 3 (192.168.1.105):

• ndbd

Esto es, el nodo 1 será un Management Node + API Node y los dos restantes Data Nodes.

Lo primero de todo es descargarnos MySQL Cluster de http://dev.mysql.com/downloads/cluster/

La instalación es tan sencilla como descomprimir el fichero y copiar a nuestro PATH los ejecutables que necesitemos. Por lo tanto, llevaremos a /usr/bin/ los ejecutables ndbd, ndb_mgmd, ndb_mgm, mysqld, mysqld_safe.

Para tener un poco ordenadas las cosas, creamos la carpeta /etc/mysql-cluster/ donde alojaremos el fichero de configuración del cluster config.ini.

# cat /etc/mysql-cluster/config.ini 
[ndbd default]
NoOfReplicas=2
DataDir=/var/lib/mysql-cluster
DataMemory=512M
IndexMemory=128M
TransactionDeadlockDetectionTimeout=5000
MaxNoOfConcurrentOperations=100000
MaxNoOfLocalOperations=110000
[ndb_mgmd]
Id=1
HostName=192.168.1.106
[ndbd]
Id=5
HostName=192.168.1.104
[ndbd]
Id=6
HostName=192.168.1.105
[mysqld]
Id=7

Como vemos, en primer lugar indicamos los valores por defecto para todos los Data Nodes (ndbd). Por ejemplo se indican el número de replicas, donde se almacenarán los datos, la cantidad de memoria usada para almacenar datos e índices, número de operaciones concurrentes, etc. Estos valores no están ni calculados ni ajustados a la realidad, solamente son funcionales para este ejemplo y para trabajar con la base de datos employees. Cada caso y cada base de datos necesitará distintos valores que se deberán ajustar en función de la carga y cantidad de datos a almacenar.

El Management Node será el número 1 con la IP indicada, mientras que los Data Nodes serán los ID 5 y 6 con sus respectivas IPs. El API node (o en este caso más concreto Mysql Node) no tiene una ip asignada, por lo que se podría conectar desde cualquier equipo de la red.

Una vez que tenemos el fichero procedemos a arrancar el Management Node:

# ndb_mgmd -f /etc/mysql-cluster/config.ini
2010-07-25 19:30:06 [MgmtSrvr] INFO     -- NDB Cluster Management Server. mysql-5.1.44 ndb-7.1.4b
2010-07-25 19:30:06 [MgmtSrvr] INFO     -- Reading cluster configuration from '/etc/mysql-cluster/config.ini'

Arrancamos la consola y vemos que nodos tenemos arrancados:

# ndb_mgm
-- NDB Cluster -- Management Client --
ndb_mgm> show
Connected to Management Server at: localhost:1186
Cluster Configuration
\---------------------
[ndbd(NDB)] 2 node(s)
id=5 (not connected, accepting connect from 192.168.1.104)
id=6 (not connected, accepting connect from 192.168.1.105)
[ndb_mgmd(MGM)] 1 node(s)
id=1    @192.168.1.106  (mysql-5.1.44 ndb-7.1.4)
[mysqld(API)]   1 node(s)
id=7 (not connected, accepting connect from any host)

Solo tenemos el Management Node en marcha. Vamos a proceder a arrancar los Data Nodes. Nos conectamos a cada nodo y ejecutamos:

# ndbd --connect-string=192.168.1.106 --initial -n
2010-07-25 19:31:38 [ndbd] INFO     -- Configuration fetched from '192.168.1.106:1186', generation: 1

La opción --initial se usa cuando iniciamos por primera vez el Cluster para arrancar con el sistema de ficheros limpio. -n indica que el nodo no se autoarranque y --connect-string indica la IP del Management Node al que nos conectaremos.

Una vez que Data Node se conecta al Management Node, este último les entrega el fichero de configuración con los parametros necesarios para que se configuren. Ahora, desde la consola de administración podremos arrancar los dos Data Nodes:

ndb_mgm> 5 start
Database node 5 is being started.
ndb_mgm> Node 5: Start initiated (version 7.1.4)
ndb_mgm> 6 start
Database node 6 is being started.
ndb_mgm> Node 6: Start initiated (version 7.1.4)
ndb_mgm> show
Cluster Configuration
\---------------------
[ndbd(NDB)] 2 node(s)
id=5    @192.168.1.104  (mysql-5.1.44 ndb-7.1.4, Nodegroup: 0, Master)
id=6    @192.168.1.105  (mysql-5.1.44 ndb-7.1.4, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=1    @192.168.1.106  (mysql-5.1.44 ndb-7.1.4)
[mysqld(API)]   1 node(s)
id=7    @192.168.1.106  (mysql-5.1.44 ndb-7.1.4)

Ya tenemos los Data Nodes en marcha.

Para arrancar el Api Node únicamente hay que ejecutar el demonio mysqld:

# mysqld_safe --ndbcluster &

No es necesario indicarle la IP del Management Node ya que se encuentran en la misma máquina.

Listo! Si ahora nos conectamos con el cliente mysql a localhost y creamos una base de datos usando tablas ndbcluster, estas se almacenarán en nuestro recién creado Cluster :)

Introducción a MySQL Cluster

MySQL Cluster es una base de datos que como su nombre indica funciona en un Cluster de servidores. Mucha gente confunde terminos y define un conjunto de servidores con replicación como un MySQL Cluster, pero hay que tener en cuenta que son dos conceptos totalmente distintos. MySQL Cluster nos ofrece:

• Alta disponibilidad
• Escalabilidad
• Failover automático
• Redundancia
• Alto throughput

La versión actual es la 7.1 y puede descargarse de http://www.mysql.com/products/database/cluster/

Componentes

Un Cluster MySQL está compuesto por los siguientes componentes:

Manager (ndb_mgmd): es un servicio encargado de poner en marcha el cluster, conectar nuevos servidores y ejecutar distintos comandos de administración mediante el CLI ndb_mgm. Una vez que hemos levantado el cluster no es necesario ni un requisito indispensable que esté levantado.

Data Nodes (ndbd): son nodos encargados del almacenamiento de los datos. Se recomiendan al menos dos para disponer de redundancia y alta disponibilidad. Estas serán las máquinas más potentes del cluster, almacenarán los índices en memoria y los datos en memoria o disco. Todos los Data Nodes deben tener el mismo hardware para evitar crear cuellos de botella.

API nodes (mysqld): aunque el más usado sea mysqld, un API node puede ser cualquier aplicación que haciendo uso de la API acceda al cluster. El típico, también conocido como SQL Node, es el demonio mysqld típico (compilado con soporte nbdcluster). De esta forma podremos escribir o leer datos de nuestra BBDD como hemos hecho hasta ahora, mediante comandos SQL.

Se recomienda que cada componente esté instalado en una máquina física distinta.

Funcionamiento interno

Internamente, el funcionamiento del cluster se basa en dos conceptos básicos. Replicación interna síncrona y auto particionado de datos. La primera nos ofrece la redundancia y el segundo nos da la escalabilidad. Importante diferenciarlo de la replicación típica de MySQL (asíncrona). En este caso, hasta que los datos no han sido replicados en los nodos seleccionados no se devuelve el control al usuario, obteniendo de esta forma la consistencia que no tenemos en la replicación asíncrona.

El particionado (PARTITION BY KEY) es también totalmente automático. El cluster se encarga de dividir las tablas en distintas particiones y dividir los datos entre los distintos Data Nodes. Aunque es posible que definamos nuestro propio particionado, no se recomienda. Añades complejidad y posiblemente el rendimiento no sea el esperado.

Replicas

A la hora de configurar nuestro cluster, una de los valores más importantes a tener en cuenta es decidir el número de replicas que tendremos de nuestros datos. No podemos decidir cualquier número, si no que tendremos que seguir unas sencillas reglas. Pongamos por ejemplo que tenemos 4 Data Nodes. En este caso podremos tener 1, 2 y 4 replicas. Esto es, el número de nodos debe poder ser divisible por el numero de replicas. Aún así, no se debería tener una única replica, ya que eso no nos da ningún tipo de alta disponibilidad ya que al caerse un solo nodo perderíamos el acceso a los datos.

Node Groups

MySQL Cluster agrupa automáticamente los Data Nodes en grupos. Esto no está bajo nuestro control ni podemos decidir que nodo está en que grupo, será trabajo del cluster hacer estas agrupaciones. Siguiendo el ejemplo anterior, si tenemos 4 Data Nodes y 2 réplicas, MySQL Cluster nos generará dos Node Groups (4/2=2). Además hay que tener en cuenta que el número de particiones que se harán de nuestros datos siempre será igual al número de Data Nodes.

Por lo tanto, imaginemos que tenemos el N1 y N2 en el grupo 1 (G1) y N3 y N4 en el grupo 2 (G2). A la hora de particionar y repartir los datos es necesario pensar en la alta disponibilidad, por lo que el particionado se hará de la siguiente forma:

G1
N1 = P1 y P2'
N2 = P2 y P1'

G2
N3 = P3 y P4'
N4 = P4 y P3'

Siendo PX el número de la partición y PX' una copia de la partición de Backup.

Sabiendo esto, podemos imaginar cuando dispondremos de alta disponibilidad. Mientras al menos uno de los nodos de un grupo esté levantado, el cluster estará online. Por ejemplo se podrían caer N1 y N4 o N3 y N2 y todo seguiría funcionando. Pero una caida de N1 y N2 dejaría el cluster completamente caido.

A mayor número de replicas menos posibilidades de fallo, más escalabe y más throughput :)

Próximamente extenderé el tema de MySQL Cluster con más entradas según vaya profundizando en el estudio de la certificación. La intención será termianr teniendo un mini manual para andar por casa que nos permita dar los primeros pasos.

Alta disponibilidad en replicación con Mysql-MMM

Montar un sistema de replicación es sencillo y rápido. Nos ofrece muchas ventajas, siempre y cuando funcione correctamente y no fallen los equipos. Ahora imagina con las siguientes características:

• Dos equipos en maestro-maestro.
• 50 equipos esclavos, 25 colgando del maestro 1 y otros 25 del maestro 2.

Ahora imagina que el maestro 1 se cae. Bien, recuerda que todo esto está en tu imaginación, no te intentes suicidar, aunque he de admitir que sería la solución mas razonable. Con la caida de ese Master, 25 equipos esclavos se han quedado desincronizados. Tenemos usuarios que ni pueden escribir y lo que leen está posiblemente anticuado. Cuando pones de nuevo el servidor en marcha compruebas que no se replican correctamente ya que alguna transacción quedó a medías. Tienes 26 ordenadores desincronizados y tienes que entrar uno a uno parando el proceso Slave, ejecutando el change_master, arranco de nuevo el slave, comprobando si se resincroniza o no. En el peor de los casos tienes que borrar la base de datos importándola de nuevo... El infierno convertido en SQL.

La solución

Para ayudarnos en esta tarea tenemos Mysql MMM (Multi-Master Replication Manager). Son una serie de scripts y demonios que se encargan de hacer esta tarea más sencilla. Entre sus características tenemos:

- Monitorización de la replicación
- Monitorización de los hosts
- Gestión del failover
- Balanceo de IPs entre nodos
- Gestión de grupos de escritura/lectura

El esquema de nuestra red cambia poco, si antes teniamos 52 servidores, ahora serán 53. El nuevo será un sistema de control que se encargará de conectarse a cada nodo y comprobar el estado y ejecutar las ordenes que le indiquemos mediante las utilidades de consola. Además será necesario más IPs que se asignarán al vuelo de un host a otro dependiendo de los hosts que se encuentren online.

A la hora de gestionar las IPs virtuales tenemos dos formas de hacerlo:

Exclusivo: Una única IP para muchos hosts. Si el host que la tiene se cae se balancea a otro. Generalmente se usa en los nodos de escritura.

Balanceado: Una IP por cada host. Si uno de los hosts se cae la IP se balancea a cualquier otro, pasando a tener dos IPs virtuales. Se usa para nodos en lectura.

Yo no voy a hacer el ejemplo con 52 hosts, siendo sincero me da mucha pereza. Así que el esquema de nuestro sistema de replicación en alta disponibilidad es el siguiente:

Al turrón

La parte de montar la arquitectura maestro/esclavo la damos por hecha :P Nos centraremos únicamente en MMM. Como vemos, el host de control tendrá la IP 10.100.1.14. Las IPs virtuales que usaremos serán 10.100.1.10 en modo exclusivo para las escrituras (DB1 y DB2) y 10.100.1.11 y 10.100.1.12 en modo balanceado para la lectura.

De esta forma, ya sea mediante un balanceador hardware o software (en la propia aplicación), los usuarios leerán de 10.100.1.11 y 10.100.1.12 (round robin) y escribirán en 10.100.1.10.

En el sistema de control se debe instalar:

• mysql-mmm-common_2.0.10-1_all.deb
• mysql-mmm-monitor_2.0.10-1_all.deb

Mientras que en los servidores de MySQL instalaremos:

• mysql-mmm-common_2.0.10-1_all.deb
• mysql-mmm-agent_2.0.10-1_all.deb

Sin olvidarnos de todas sus dependencias.

Los ficheros de configuración se guardan en /etc/mysql-mmm. Todos tienen uno en común llamado mmm_common.conf con este contenido:

active_master_role  writer
<host default>
    cluster_interface       eth1
    pid_path                /var/run/mmmd_agent.pid
    bin_path                /usr/bin/mysql-mmm/
        replication_user        replication
        replication_password    slave
    agent_user              mmm_agent
    agent_password          RepAgent
</host>
<host db1>
    ip                  10.100.1.1
    mode                    master
    peer                    db2
</host>
<host db2>
    ip                  10.100.1.2
    mode                    master
    peer                    db1
</host>
<host db3>
    ip                  10.100.1.3
    mode                    slave
</host>
<host db4>
    ip                  10.100.1.4
    mode                    slave
</host>
<role writer>
    hosts                   db1, db2
    ips                 10.100.1.10
    mode                    exclusive
</role>
<role reader>
    hosts                   db3, db4
    ips                 10.100.1.11, 10.100.1.12
    mode                    balanced
</role>

Es bastante descriptivo :) Se identifican los hosts con su nombre, su ip y las IPs virtuales que compartirán (y en que modo lo harán). También se indica el usuario y contraseña para el usuario de replicación así como del del agente (serán usuarios de MySQL).

El nodo de control tendrá el fichero mmm_mon.conf:

include mmm_common.conf
<monitor>
    ip                  127.0.0.1
    pid_path                /var/run/mmmd_mon.pid
    bin_path                /usr/bin/mysql-mmm/
    status_path             /var/lib/misc/mmmd_mon.status
    ping_ips                10.100.1.1, 10.100.1.2, 10.100.1.3, 10.100.1.4
</monitor>
<host default>
    monitor_user            mmm_monitor
    monitor_password        RepMonitor
</host>
debug 0

Y cada de los servidores de mysql tendrá un mmm_agent.conf.

include mmm_common.conf
this db1

En cada host, se cambiará dbi por el nombre que corresponda.

Crear usuarios en Mysql

Hay que crear los siguiente usuarios:

GRANT REPLICATION CLIENT                 ON \*.* TO 'mmm_monitor'@'10.100.1.%' IDENTIFIED BY 'RepMonitor';
GRANT SUPER, REPLICATION CLIENT, PROCESS ON \*.* TO 'mmm_agent'@'10.100.1.%'   IDENTIFIED BY 'RepAgent';
GRANT REPLICATION SLAVE                  ON \*.* TO 'replication'@'10.100.1.%' IDENTIFIED BY 'slave';

- El usuario monitor se usa para comprobar el estado de los servidores Mysql.
- El usuario agent se usa para cambiar el read only mode, poner offline un equipo, ejecutar un change_master, etc.
- El usuario replication slave... para replicación ;)

Una vez todo configurado y montado, arrancarmos los servicios en cada host, uno el monitor y los demás los agentes.

Jugar con la consola

Una vez puesto en marcha todos los servidores saldrán en modo AWAITING_RECOVERY. La primera vez es necesario ponerlos online a mano:

MMM:~# mmm_control show
  db1(10.100.1.1) master/AWAITING_RECOVERY. Roles: 
  db2(10.100.1.2) master/AWAITING_RECOVERY. Roles: 
  db3(10.100.1.3) slave/AWAITING_RECOVERY. Roles: 
  db4(10.100.1.4) slave/AWAITING_RECOVERY. Roles:

Asi que los ponemos online :P

MMM:~# mmm_control set_online db1
OK: State of 'db1' changed to ONLINE. Now you can wait some time and check its new roles!
MMM:~# mmm_control set_online db2
OK: State of 'db2' changed to ONLINE. Now you can wait some time and check its new roles!
MMM:~# mmm_control set_online db3
OK: State of 'db3' changed to ONLINE. Now you can wait some time and check its new roles!
MMM:~# mmm_control set_online db4
OK: State of 'db4' changed to ONLINE. Now you can wait some time and check its new roles!

MMM:~# mmm_control show
  db1(10.100.1.1) master/ONLINE. Roles: writer(10.100.1.10)
  db2(10.100.1.2) master/ONLINE. Roles: 
  db3(10.100.1.3) slave/ONLINE. Roles: reader(10.100.1.12)
  db4(10.100.1.4) slave/ONLINE. Roles: reader(10.100.1.11)

Como podemos ver, ya están online. La IP virutal de escritura la tiene el nodo db1 mientras que los otros están en lectura. A partir de ahora el funcionamiento ya es automático. Si db1 se cae, la IP pasará a db2 y los esclavos db3 y db4 pasarán a tener como maestro a db2.

Si es necesario hacer alguna parada de servicio (cambiar hardware, mover el equipo de ubicación física, etc.) podemos dejar offline la máquina en cuestión de nuestro cluster. Por ejemplo, voy a dar de baja temporalmente db1:

MMM:~# mmm_control set_offline db1
OK: State of 'db1' changed to ADMIN_OFFLINE. Now you can wait some time and check all roles!


MMM:~# mmm_control show
  db1(10.100.1.1) master/ADMIN_OFFLINE. Roles: 
  db2(10.100.1.2) master/ONLINE. Roles: writer(10.100.1.10)
  db3(10.100.1.3) slave/ONLINE. Roles: reader(10.100.1.12)
  db4(10.100.1.4) slave/ONLINE. Roles: reader(10.100.1.11)

¿Mola verdad? Has parado un servidor maestro, no te has tenido que preocupar de los esclavos y ningún cliente se ha enterado de nada :)