¡Hola!
Hoy vamos hacer algo más divertido y es montar nuestro primer Cluster de Percona XtraDB Cluster. El objetivo será de montar un entorno multi master (sí en el cual poder escribir en todos los nodos) y tener alta disponibilidad en ello (esto es obvio si es multi master).
Dentro de las múltiples ventajas que nos da este tipo de plataformas podemos destacar las siguientes:
- Alta disponibilidad (si un nodo cae el resto sigue).
- Consistencia de datos ya que la forma de sincronizar es síncrona.
- Multi Master.
- Se puede Leer y Escribir en cualquiera de los nodos.
- Los nodos al entrar se sincronizan automáticamente.
- Si algún nodo se cae, automáticamente se desconecta del cluster.
No todo será bueno en esta vida, pero tampoco soy un experto en la materia de base de datos, así que por mi parte pienso que es posible que pierda un poco a la hora de velocidad de escritura masiva.
Aparte de ello solo permite InnoDB (Xtradb es un fork) así que si estás buscando para otro tipo de ENGINE no te valdrá.
También decir que he probado este entorno en 3 servidores virtuales que estaban situados en Nueva York, Singapur y Alemania e iba todo correcto. Aunque no he realizado pruebas de Insert.
Instalando Percona XtraDB Cluster
Requisitos
- Ubuntu 16.04/18.04
- Sistema actualizado
- Desinstalar cualquier instancia de MySQL.
- Puertos abiertos: 3306, 4444, 4567,4568
Instalación
Para dejarlo listo vamos a desinstalar apparmor, no vaya a ser que nos de problema en la instalación:
apt-get remove apparmor
Ahora vamos a instalar el repositorio oficial.
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
dpkg -i percona-release_latest.generic_all.deb
Y ahora instalamos la versión full de Percona con Mysql 5.7.
apt-get install percona-xtradb-cluster-57
Configurando Percona XtraDB Cluster
Lo que vamos a informar ahora es de como será nuestra configuración:
- Tendremos 3 nodos todos en Master.
- 1 de ellos tiene que ser el «Mega Master» (esto es necesario aunque pueda funcionar sin el).
Nodo1 (Mega Master): 192.168.1.69
Nodo2: 192.168.1.70
Nodo3: 192.168.1.71
Configurando Nodo1 (Mega Master)
Lo primero que haremos será parar el servicio de MySQL en el NODO1.
service mysql stop
Antes de crear la configuración se tiene que crear un usuario para poder realizar los backups y nuestra configuración:
# Se entiende que el password y el usuario se sustituyen por el que creamos oportuno. CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'passw0rd'; GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost'; CREATE USER 'sstuser'@'%' IDENTIFIED BY 'passw0rd'; GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost'; FLUSH PRIVILEGES;
Editamos el siguiente fichero /etc/mysql/my.cnf
wsrep_provider=/usr/lib/libgalera_smm.so wsrep_cluster_name=thebigonecluster wsrep_cluster_address=gcomm://192.168.1.69,192.168.1.70,192.168.1.71 wsrep_node_name=mycluster01 wsrep_node_address=192.168.1.69 wsrep_sst_method=xtrabackup-v2 wsrep_sst_auth=sstuser:passw0rd pxc_strict_mode=ENFORCING binlog_format=ROW default_storage_engine=InnoDB innodb_autoinc_lock_mode=2
Ahora explicaremos un poco lo que significa cada parámetro:
wsrep_provider: Es la librería que nos permitirá configurar el cluster con Galera. wsrep_cluster_name: Es el nombre genérico del cluster, el cual será el mismo para todos los que componen el grupo. wsrep_cluster_address: Son las distintas IP que componen el cluster suele tomar la primera como el "MegaMaster" y en caso de no estar disponible cogería el siguiente nodo. En realidad solo requiere una IP pero es recomendable poner todas. wsrep_node_name: Nombre de cada uno de los nodos, es decir nada nodo que componga el cluster debe tener un nombre distinto. wsrep_node_address: IP específica para este nodo. wsrep_sst_method: Es el método para poder realizar backups de una manera más óptima (State Snapshot Transfer) y es propio de PerconaDB. Es muy recomendable el método "xtrabackup-v2" y siempre va acompañada de la directiva "wsrep_sst_auth". wsrep_sst_auth: La contraseña que se necesita para configurar con el parámetro de xtrabackup-v2. pxc_strict_mode: Por defecto se pone "ENFORCING" y evita que se levante en el caso de que haya algún fallo. binlog_format: Galera solo soporta "row", por lo tanto es el método que usaremos. default_storage_engine: Galera solo soporta "InnoDB" por lo tanto es obligatorio este parámetro. Con MyISAM no aseguran que funcione correctamente. innodb_autoinc_lock_mode: Galera solo soporta el modo "2" ya que los estados "0" y "1" hacen que puede haber "deadlocks" sin resolver.
Vamos arrancar nuestro primer nodo:
/etc/init.d/mysql bootstrap-pxc
Como véis no arrancamos el MySQL de manera habitual y ahora lo que tenemos que hacer es comprobar que se ha levantado. Para ello ejecutamos en la consola de MySQL el siguiente comando:
show status like 'wsrep%';
Fijaos sobre todo en estas variables:
wsrep_local_state_uuid = c2883338-834d-11e2-0800-03c9c68e41ec wsrep_local_state = 4 wsrep_local_state_comment = Synced wsrep_cluster_size = 1 wsrep_cluster_status = Primary wsrep_connected = ON wsrep_ready = ON
He dejado los 4 parámetros que nos indican acerca del estado de nuestro cluster. Para resumir nos dice que estamos en Cluster, que además este nodo hace de primario y para finalizar el Cluster solo está este servido (1).
En realidad todos los nodos harán de primario ya que tenemos el modo Multi Master con Galera Cluster.
Configurando Nodo2 y Nodo3
La única diferencia que vamos a tener con respecto al primer nodo son en las variables «wsrep_node_name y wsrep_node_adrees». Las he dejado en negrita de acuerdo a la configuración que habíamos hablado.
Nodo2
wsrep_provider=/usr/lib/libgalera_smm.so wsrep_cluster_name=thebigonecluster wsrep_cluster_address=gcomm://192.168.1.69,192.168.1.70,192.168.1.71 wsrep_node_name=mycluster02 wsrep_node_address=192.168.1.70 wsrep_sst_method=xtrabackup-v2 wsrep_sst_auth=sstuser:passw0rd pxc_strict_mode=ENFORCING binlog_format=ROW default_storage_engine=InnoDB innodb_autoinc_lock_mode=2
Nodo3
wsrep_provider=/usr/lib/libgalera_smm.so wsrep_cluster_name=thebigonecluster wsrep_cluster_address=gcomm://192.168.1.69,192.168.1.70,192.168.1.71 wsrep_node_name=mycluster03 wsrep_node_address=192.168.1.71 wsrep_sst_method=xtrabackup-v2 wsrep_sst_auth=sstuser:passw0rd pxc_strict_mode=ENFORCING binlog_format=ROW default_storage_engine=InnoDB innodb_autoinc_lock_mode=2
Ahora lo único que nos queda es arrancar nuestro cluster, en este caso sí que arrancamos los MySQL de manera habitual.
#Nodos 2 y 3 /etc/init.d/mysql start
Ahora vamos a comprobar el cluster en cualquiera de los 2 nodos:
show status like 'wsrep%'; wsrep_local_state_uuid = c2883338-834d-11e2-0800-03c9c68e42ec wsrep_local_state = 4 wsrep_local_state_comment = Synced wsrep_cluster_size = 3 wsrep_cluster_status = Primary wsrep_connected = ON wsrep_ready = ON
Verificando Replicación de Percona XtraDB Cluster
Comprobando replicación
Para hacer las pruebas lo que haremos será crear una base de datos en el nodo3 por ejemplo y además insertar un par de registros en la misma.
Después de ello lo único que nos queda es comprobar que la información está en cada uno de los nodos.
CREATE DATABASE ttt; USE ttt; CREATE TABLE ejemplo (id INT PRIMARY KEY, texto VARCHAR(50)); # Varios Inserts INSERT INTO ejemplo VALUES (1, 'Prueba#1'); INSERT INTO ejemplo VALUES (1, 'Prueba#2'); INSERT INTO ejemplo VALUES (1, 'Prueba#3');
El último paso que nos queda por comprobar es entrar en los nodos 1 y 2 para ver que se ha replicado todo correctamente.
Comprobando tirando nodos
Otra de las pruebas que es interesante es la de tirar nodos y ver que pasa … sobre todo para ver como se comporta.
Vamos a realizar las siguientes pruebas:
- Tirar uno de los nodos sin ser el nodo1 (recordamos que tiene que haber uno como «Mega Master»).
- Tirar el que hace de «Mega Master» (Nodo1)
- Tirar todos los nodos y recuperar el cluster.
Creo que con esto cubrimos todos los casos de lo que pueda pasar.
Tirando un nodo (Que no sea el NODO1)
Existen 2 maneras de realizar esto:
#Deteniendo el servicio service mysql stop o systemcl mysql stop #Poniendo las bases de datos en modo lectura flush tables with read lock; # Para quitar el modo lectura unlock tables;
Podemos parar cualquier nodo (2 o 3 o inclusive ambos) para ver que la carga quedaría en el nodo1.
Es interesante que se agreguen datos (más inserts sobre nuestra base de datos de pruebas) y se compruebe al levantar los nodos que se ha replicado todo correctamente.
Cuando lo monte de nuevo os dejaré las pruebas de los comandos...
Tirando el NODO1
Recordamos a todos que el NODO1 hacía de «Mega Master» es decir siempre tiene que haber uno levantado.
Vamos a ver que ocurre y como recuperarlo de nuevo …
Cuando lo monte de nuevo os dejaré las pruebas de los comandos...
Tirando todos los NODOS
A la hora de tirar todos los nodos el procedimiento a seguir es lo mismo que hicimos a la hora de montarlo. Es decir, que levantaremos el «Mega Master» y de ahí levantaremos el resto.
Es decir que no pasa nada si se cae todo el cluster, ya que tenemos las configuraciones en nuestros servidores.
¿Qué sincronizará?
Pues lo que tengas en el nodo «Mega Master» en el caso de que el resto de los nodos no estén sincronizados.
Conclusión
Hemos aprendido a montar nuestro sistema de base de datos síncrono con Galera + Percona en el cual se puede escribir en cualquier de nuestros nodos para tener una mayor redundancia.
Lo único que nos faltaría sería tener un balanceador que reparta la carga (HAPROXY o algo de pago en tu proveedor) o algo similar a lo que queremos montar (ROUTE 53) para repartir la carga dependiendo de donde venga la conexión.
Otra cosa que nos queda pendiente de este procedimiento son las pruebas de rendimiento el cual creo que haremos más adelante.