Los registros binarios (binlogs) contienen registros de todos los cambios en las bases de datos. Son necesarios para la replicación y también se pueden usar para restaurar datos después de una copia de seguridad. Un servidor binlog es básicamente un repositorio de registros binarios. Puede pensar en él como un servidor con un propósito dedicado a recuperar registros binarios de un maestro, mientras que los servidores esclavos pueden conectarse a él como si se conectaran a un servidor maestro.
Algunas ventajas de tener un servidor binlog sobre un maestro intermedio para distribuir la carga de trabajo de replicación son:
- Puede cambiar a un nuevo servidor maestro sin que los esclavos se den cuenta de que el servidor maestro real ha cambiado. Esto permite una configuración de replicación de mayor disponibilidad donde la replicación es de alta prioridad.
- Reduzca la carga en el maestro sirviendo solo el servidor binlog de Maxscale en lugar de todos los esclavos.
- Los datos en el registro binario del maestro intermedio no son una copia directa de los datos que se recibieron del registro binario del maestro real. Como tal, si se utiliza la confirmación de grupo, esto puede provocar una reducción en el paralelismo de las confirmaciones y una reducción posterior en el rendimiento de los servidores esclavos.
- El esclavo intermedio tiene que volver a ejecutar cada instrucción SQL, lo que potencialmente agrega latencia y retrasos en la cadena de replicación.
En esta publicación de blog, veremos cómo reemplazar un maestro intermedio (un host esclavo que transmite a otros esclavos en una cadena de replicación) con un servidor binlog que se ejecuta en MaxScale para una mejor escalabilidad y rendimiento .
Arquitectura
Básicamente tenemos una configuración de replicación MariaDB v10.4 de 4 nodos con un MaxScale v2.3 encima de la replicación para distribuir las consultas entrantes. Solo un esclavo está conectado a un maestro (maestro intermedio) y los otros esclavos se replican desde el maestro intermedio para servir cargas de trabajo de lectura, como se ilustra en el siguiente diagrama.
Vamos a convertir la topología anterior en esto:
Básicamente, vamos a eliminar el rol de maestro intermedio y reemplazarlo con un servidor binlog que se ejecuta en MaxScale. El maestro intermedio se convertirá en un esclavo estándar, al igual que otros hosts esclavos. El servicio binlog escuchará en el puerto 5306 en el host MaxScale. Este es el puerto al que se conectarán todos los esclavos para la replicación más adelante.
Configuración de MaxScale como servidor Binlog
En este ejemplo, ya tenemos un MaxScale ubicado en la parte superior de nuestro clúster de replicación que actúa como un equilibrador de carga para nuestras aplicaciones. Si no tiene MaxScale, puede usar ClusterControl para implementar simplemente vaya a Acciones de clúster -> Agregar balanceador de carga -> MaxScale y complete la información necesaria de la siguiente manera:
Antes de comenzar, exportemos la configuración actual de MaxScale a un archivo de texto para respaldo MaxScale tiene un indicador llamado --export-config para este propósito, pero debe ejecutarse como usuario de maxscale. Por lo tanto, el comando para exportar es:
$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscaleEn el maestro MariaDB, cree un usuario esclavo de replicación llamado 'maxscale_slave' para que lo use MaxScale y asígnele los siguientes privilegios:
$ mysql -uroot -p -h192.168.0.91 -P3306
MariaDB> CREATE USER 'maxscale_slave'@'%' IDENTIFIED BY 'BtF2d2Kc8H';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.roles_mapping TO 'maxscale_slave'@'%';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale_slave'@'%';
MariaDB> GRANT REPLICATION SLAVE ON *.* TO 'maxscale_slave'@'%';Para usuarios de ClusterControl, vaya a Administrar -> Esquemas y usuarios para crear los privilegios necesarios.
Antes de continuar con la configuración, es importante revisar el estado actual y la topología de nuestros servidores backend:
$ maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬──────────────────────────────┬───────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_757 │ 192.168.0.90 │ 3306 │ 0 │ Master, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_758 │ 192.168.0.91 │ 3306 │ 0 │ Relay Master, Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_759 │ 192.168.0.92 │ 3306 │ 0 │ Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_760 │ 192.168.0.93 │ 3306 │ 0 │ Slave, Running │ 0-38001-8 │
└────────┴──────────────┴──────┴─────────────┴──────────────────────────────┴───────────┘Como podemos ver, el maestro actual es DB_757 (192.168.0.90). Tome nota de esta información ya que vamos a configurar el servidor binlog para replicar desde este maestro.
Abra el archivo de configuración de MaxScale en /etc/maxscale.cnf y agregue las siguientes líneas:
[replication-service]
type=service
router=binlogrouter
user=maxscale_slave
password=BtF2d2Kc8H
version_string=10.4.12-MariaDB-log
server_id=9999
master_id=9999
mariadb10_master_gtid=true
filestem=binlog
binlogdir=/var/lib/maxscale/binlogs
semisync=true # if semisync is enabled on the master
[binlog-server-listener]
type=listener
service=replication-service
protocol=MariaDBClient
port=5306
address=0.0.0.0Un poco de explicación:estamos creando dos componentes:servicio y escucha. El servicio es donde definimos la característica del servidor binlog y cómo debe ejecutarse. Los detalles de cada opción se pueden encontrar aquí. En este ejemplo, nuestros servidores de replicación se ejecutan con replicación semisincrónica, por lo que tenemos que usar semisync=true para que se conecte al maestro a través del método de replicación semisincrónica. El oyente es donde mapeamos el puerto de escucha con el servicio binlogrouter dentro de MaxScale.
Reinicie MaxScale para cargar los cambios:
$ systemctl restart maxscaleVerifique que el servicio binlog se inicie a través de maxctrl (observe la columna Estado):
$ maxctrl show service replication-serviceVerifique que MaxScale ahora esté escuchando un nuevo puerto para el servicio binlog:
$ netstat -tulpn | grep maxscale
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 0.0.0.0:3307 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 0.0.0.0:5306 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 127.0.0.1:8989 0.0.0.0:* LISTEN 4850/maxscaleAhora estamos listos para establecer un enlace de replicación entre MaxScale y el maestro.
Activación del servidor Binlog
Inicie sesión en el servidor maestro de MariaDB y recupere el archivo binlog actual y la posición:
MariaDB> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000005 | 4204 | | |
+---------------+----------+--------------+------------------+Utilice la función BINLOG_GTID_POS para obtener el valor GTID:
MariaDB> SELECT BINLOG_GTID_POS("binlog.000005", 4204);
+----------------------------------------+
| BINLOG_GTID_POS("binlog.000005", 4204) |
+----------------------------------------+
| 0-38001-31 |
+----------------------------------------+Volver al servidor MaxScale, instalar el paquete del cliente MariaDB:
$ yum install -y mysql-client
Conéctese a la escucha del servidor binlog en el puerto 5306 como usuario maxscale_slave y establezca un enlace de replicación con el maestro designado. Use el valor de GTID obtenido del maestro:
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SET @@global.gtid_slave_pos = '0-38001-31';
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.90', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=3306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Binlog Dump
Master_Host: 192.168.0.90
Master_User: maxscale_slave
Master_Port: 3306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 38001
Master_Info_File: /var/lib/maxscale/binlogs/master.ini
Slave_SQL_Running_State: Slave running
Gtid_IO_Pos: 0-38001-31Nota:el resultado anterior se ha truncado para mostrar solo las líneas importantes.
Apuntando esclavos al servidor Binlog
Ahora, en mariadb2 y mariadb3 (los esclavos finales), cambie el maestro que apunta al servidor binlog de MaxScale. Dado que estamos ejecutando con la replicación semi-sincronizada habilitada, primero debemos desactivarlos:
(mariadb2 & mariadb3)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.95
Master_User: maxscale_slave
Master_Port: 5306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 9999
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-38001-32
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update itNota:el resultado anterior se ha truncado para mostrar solo las líneas importantes.
Dentro de my.cnf, debemos comentar las siguientes líneas para deshabilitar la sincronización parcial en el futuro:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONEn este punto, el maestro intermedio (mariadb1) aún se está replicando desde el maestro (mariadb0) mientras que otros esclavos se han estado replicando desde el servidor binlog. Nuestra topología actual se puede ilustrar como el siguiente diagrama:
La parte final es cambiar el apuntamiento maestro del maestro intermedio (mariadb1 ) después de que todos los esclavos que solían unirse a él ya no estén allí. Los pasos son básicamente los mismos con los otros esclavos:
(mariadb1)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.95
Master_User: maxscale_slave
Master_Port: 5306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 9999
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-38001-32Nota:el resultado anterior se ha truncado para mostrar solo las líneas importantes.
No olvide deshabilitar también la replicación semi-sincronizada en my.cnf:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONPodemos verificar que el servicio de enrutador binlog tiene más conexiones ahora a través de maxctrl CLI:
$ maxctrl list services
┌─────────────────────┬────────────────┬─────────────┬───────────────────┬───────────────────────────────────┐
│ Service │ Router │ Connections │ Total Connections │ Servers │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rw-service │ readwritesplit │ 1 │ 1 │ DB_757, DB_758, DB_759, DB_760 │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rr-service │ readconnroute │ 1 │ 1 │ DB_757, DB_758, DB_759, DB_760 │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ replication-service │ binlogrouter │ 4 │ 51 │ binlog_router_master_host, DB_757 │
└─────────────────────┴────────────────┴─────────────┴───────────────────┴───────────────────────────────────┘Además, los comandos de administración de replicación comunes se pueden usar dentro del servidor binlog de MaxScale, por ejemplo, podemos verificar los hosts esclavos conectados usando este comando:
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SHOW SLAVE HOSTS;
+-----------+--------------+------+-----------+------------+
| Server_id | Host | Port | Master_id | Slave_UUID |
+-----------+--------------+------+-----------+------------+
| 38003 | 192.168.0.92 | 3306 | 9999 | |
| 38002 | 192.168.0.91 | 3306 | 9999 | |
| 38004 | 192.168.0.93 | 3306 | 9999 | |
+-----------+--------------+------+-----------+------------+En este punto, nuestra topología se parece a lo que anticipamos:
Nuestra migración de la configuración maestra intermedia a la configuración del servidor binlog ahora está completa.
