En este post veremos cómo añadir un nuevo nodo a un cluster MySQL en producción. Las pruebas se han hecho con este escenario:
- Cluster Percona XtraDB Cluster 5.6 (basado en Galera) sobre máquinas CentOS 6.
- Cluster en producción formado por 2 nodos y un árbitro.
- Creación del nuevo nodo a partir de un backup realizado mediante XtraBackup asegurándo incorporar la Global Transaction ID (necesario para recuperar un nodo sin necesidad del SST inicial). Aquí puedes ver cómo hacer este tipo de backups.
Lo primero que haremos será situarnos sobre el que será el nuevo nodo y seguir los pasos descritos a continuación:
1. Si no lo tiene ya, deberemos instalar Percona-XtraDB Cluster, para posteriormente poder restaurar el backup. Recuerda:
- Instala socat (Instrucciones)
- Instala el paquete Percona-XtraDB-Cluster-56 (Instrucciones)
2. Una vez instalado (pero sin iniciar el servicio), deberemos dejar listo el fichero de configuración en /etc/my.cnf. Para ello:
- Copiaremos el fichero de configuración de uno de los nodos existentes en el cluster, y lo adaptaremos a nuestras necesidades, modificando las siguientes líneas (la IP del nuevo nodo, en el ejemplo, es la 192.168.1.13, y lo hemos llamado «percona3»).
wsrep_cluster_address=gcomm://192.168.1.11,192.168.1.12,192.168.1.13
wsrep_node_name=percona3
wsrep_node_address=192.168.1.13
3. Con el fichero my.cnf listo, pasaremos a restaurar el backup en el datadir, en mi caso, en /data/mysql. Como se trata de un backup realizado con XtraBackup, podremos restaurarlo así:
- Si no existe nuestro datadir, lo crearemos
[root@percona3]# mkdir /data
[root@percona3]# mkdir /data/mysql
[root@percona3]# chown mysql:mysql /data/mysql
- Si guardamos el backup en el nodo con IP 192.168.1.12, podemos usar rsync para restaurarlo en el nuevo nodo
[root@percona3]# rsync -e ssh -avprP [email protected]:/root/backups/FULL/2014-03-28_11-02-08/ /data/mysql/
[root@percona3]# chown -R mysql:mysql /data/mysql/
4. Una vez tengamos el backup restaurado en el nuevo nodo, deberemos seguir las indicaciones de Percona para iniciar el nodo evitando el SST inicial. Para ello:
- En uno de los nodos del cluster, recuperaremos la versión, que necesitaremos para el siguiente paso:
show global status like 'wsrep_provider_version';
+------------------------+-----------+
| Variable_name | Value |
+------------------------+-----------+
| wsrep_provider_version | 3.4(r176) |
+------------------------+-----------+
- En el nuevo nodo, crearemos el fichero grastate.dat en el datadir, con la información sacada del fichero xtrabackup_galera_info que encontraremos en el mismo datadir, una vez restaurado el backup.
[root@percona3]# cat /data/mysql/xtrabackup_galera_info
ebf4fa86-b4ff-11e3-96f9-9ec4e4397b29:1003
[root@percona3]# vi /data/mysql/grastate.dat
# GALERA saved state
version: 3.4
uuid: ebf4fa86-b4ff-11e3-96f9-9ec4e4397b29
seqno: 1003
cert_index:
[root@percona3]# chown mysql:mysql /data/mysql/grastate.dat
5. En este momento, estaremos listos para iniciar el nuevo nodo
[root@percona3]# /etc/init.d/mysql start
Starting MySQL (Percona XtraDB Cluster)............ SUCCESS!
6. Decir que desde que se inicia el nuevo nodo, el cluster habrá incrementado su tamaño y por tanto, las operaciones de escritura se propagarán a todos los nodos desde el primer momento, incluyendo como no podía ser de otra manera, al nuevo nodo.
[root@percona2]# mysql -u root -pPASS -D mydb -e "select count(*) from t;"
+----------+
| count(*) |
+----------+
| 999 |
+----------+
[root@percona2]# mysql -u root -pPASS -D mydb -e "insert t(a,b) values (22,33);"
Query OK, 1 row affected (0,06 sec)
[root@percona3]# mysql -u root -pPASS -D mydb -e "select count(*) from t;"
+----------+
| count(*) |
+----------+
| 1000 |
+----------+
Felicidades, ya tienes un nodo más en tu Cluster.
Foto por Pulmonary Pathology
Hi my friend! I want to say that this post is amazing, great written and include almost all significant infos. I’d like to see more posts like this. ckaekggeadab
Hola,
No sé si te has encontrado con un posible error. Desde que hemos empezado con la replicación. Tenemos 3 DB Master. Tenemos un problema con la correlación de Id’s.
Tenemos una columna es una tabla que los id’s eran correlativos antes de pasar a la replicación. Ahora a veces son correlativos y otras no.
¿Te has encontrado con este problema? ¿Cómo lo solucionarias?
Saludos,
Joel Cantarero
Hola Joel,
Pues sí que lo había visto, sí. En realidad es una de las limitaciones de Galera. Aquí te lo explican:
Si quieres más info:
https://mariadb.com/kb/en/mariadb/documentation/replication-cluster-multi-master/galera/mariadb-galera-cluster-known-limitations/
¡Salud!