Cómo configurar la replicación de grupo de MySQL en Ubuntu 20.04

Introducción

La replicación de MySQL refleja de manera confiable los datos y las operaciones de una base de datos a otra. La replicación convencional implica un servidor primario configurado para aceptar operaciones de escritura de la base de datos con servidores secundarios que copian y aplican acciones desde el registro del servidor primario a sus propios conjuntos de datos. Estos servidores secundarios pueden ser utilizados para lecturas, pero generalmente no pueden ejecutar escrituras de datos.

La replicación de grupo es una forma de implementar un mecanismo de replicación más flexible y tolerante a fallos. Este proceso implica establecer un conjunto de servidores, cada uno de los cuales participa en garantizar que los datos se copien correctamente. Si el servidor primario experimenta problemas, las elecciones de miembros pueden seleccionar un nuevo primario del grupo. Esto permite que los nodos restantes continúen operando, incluso ante problemas. La negociación de membresía, la detección de fallos y la entrega de mensajes se realizan a través de una implementación del algoritmo de consenso Paxos.

En este tutorial, configurarás la replicación de grupo de MySQL utilizando un conjunto de tres servidores Ubuntu 20.04. Ten en cuenta que tres es el número mínimo de instancias de MySQL que necesitas implementar para la replicación de grupo en MySQL, mientras que nueve es el máximo. A medida que avances en este tutorial, tendrás la opción de configurar el grupo como un grupo de replicación de un único primario o de varios primarios.

Prerrequisitos

Para completar esta guía, necesitarás:

• Tres servidores ejecutando Ubuntu 20.04. Cada uno debería tener un usuario administrativo no root con privilegios sudo y un firewall configurado con UFW. Siga nuestra guía de configuración inicial del servidor para Ubuntu 20.04 para configurar cada servidor.
• MySQL instalado en cada servidor. Esta guía asume que estás utilizando la última versión de MySQL disponible en los repositorios predeterminados de Ubuntu que, hasta la fecha de esta escritura, es la versión 8.0.28. Para instalar esto en todos sus servidores, siga nuestra guía sobre Cómo instalar MySQL en Ubuntu 20.04 para cada máquina.

Para mantener las cosas claras, esta guía se referirá a los tres servidores como miembro1, miembro2 y miembro3. En los ejemplos a lo largo de esta guía, estos miembros tendrán las siguientes direcciones IP:

Cualquier comando que deba ejecutarse en miembro1 tendrá un fondo azul, como este:

Del mismo modo, cualquier comando que deba ejecutarse en miembro2 tendrá un fondo rojo:

Y cualquier comando que deba ejecutarse en miembro3 tendrá un fondo verde:

Por último, cualquier comando que deba ejecutarse en cada uno de los tres servidores tendrá un fondo estándar:

Paso 1 — Generar un UUID para Identificar el Grupo de MySQL

Antes de abrir el archivo de configuración de MySQL para configurar los ajustes de replicación de grupo, necesitas generar un UUID que puedas usar para identificar el grupo de MySQL que crearás.

En miembro1, utiliza el comando uuidgen para generar un UUID válido para el grupo:

uuidgen

Output
168dcb64-7cce-473a-b338-6501f305e561

Copia el valor que recibas, ya que tendrás que hacer referencia a él en un momento cuando configures un nombre de grupo para tu conjunto de servidores.

Paso 2 — Configurar la Replicación de Grupo en el Archivo de Configuración de MySQL

Ahora estás listo para modificar el archivo de configuración principal de MySQL. Abre el archivo de configuración principal de MySQL en cada servidor de MySQL utilizando tu editor de texto preferido. Aquí, usaremos nano:

sudo nano /etc/mysql/my.cnf

En Ubuntu, MySQL viene instalado con varios archivos diferentes que puedes usar para definir varios cambios de configuración. De forma predeterminada, el archivo my.cnf solo se utiliza para incluir archivos adicionales de subdirectorios. Deberás agregar tu propia configuración debajo de las líneas !includedir. Esto te permitirá anular cualquier configuración de los archivos incluidos.

Para comenzar, inicia una nueva sección incluyendo un encabezado [mysqld] y luego agrega las configuraciones que necesitas para habilitar la replicación de grupo, como se destaca en el siguiente ejemplo. Ten en cuenta que estas configuraciones se modifican a partir de las configuraciones mínimas requeridas para la replicación de grupo descritas en la documentación oficial de MySQL. El prefijo loose- permite a MySQL manejar opciones que no reconoce con gracia y sin fallos. Pronto deberás completar y personalizar algunas de estas configuraciones:

. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/

[mysqld]

# General replication settings
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1

# Shared replication group configuration
loose-group_replication_group_name = ""
loose-group_replication_ip_whitelist = ""
loose-group_replication_group_seeds = ""

# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON

# Host specific replication configuration
server_id = 
bind-address = ""
report_host = ""
loose-group_replication_local_address = ""

Para explicar todas estas opciones de configuración con mayor claridad, se han dividido en las siguientes subsecciones. Por favor, léelas cuidadosamente, ya que algunas secciones te presentan opciones sobre cómo deseas implementar tu grupo de replicación o requieren que ingreses detalles específicos de tu propia configuración.

Configuraciones Básicas de Replicación de Grupo

La primera sección contiene configuraciones generales requeridas para la replicación de grupo que no requieren modificación:

. . .
# Configuraciones generales de replicación
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
. . .

Un requisito particular para la replicación de grupo en MySQL es que los datos deben almacenarse en el motor de almacenamiento InnoDB. La documentación de MySQL recomienda desactivar explícitamente el uso de otros motores de almacenamiento que podrían causar errores de manera similar a la primera línea sin comentar en esta sección.

Las configuraciones restantes activan los identificadores globales de transacción, configuran el registro binario que es necesario para la replicación de grupo y configuran SSL para el grupo. Esta configuración también establece algunos otros elementos que ayudan en la recuperación y el arranque. No necesitas modificar nada en esta sección y debería ser idéntica en los tres servidores, así que puedes continuar después de agregarla.

Configuraciones compartidas de replicación de grupo

La segunda sección establece configuraciones compartidas para el grupo. Deberás personalizar esto una vez y luego usar las mismas configuraciones en cada uno de tus nodos. Específicamente, debes agregar el UUID del grupo (que creaste en el paso anterior), una lista de miembros autorizados del grupo y los miembros semilla para contactar y obtener los datos iniciales al unirse al grupo.

Establezca el loose-group_replication_group_name en el valor UUID que generó previamente con el comando uuidgen. Asegúrese de colocar el UUID entre el par vacío de comillas dobles.

A continuación, configure loose-group_replication_ip_whitelist en una lista de todas las direcciones IP de su servidor MySQL, separadas por comas. El ajuste de loose-group_replication_group_seeds debe ser casi igual que la lista blanca, pero debe agregar un puerto designado de replicación de grupo al final de cada miembro. Para los fines de esta guía, utilice el puerto de replicación de grupo recomendado, 33061:

. . .
# Configuración de grupo de replicación compartida
loose-group_replication_group_name = "168dcb64-7cce-473a-b338-6501f305e561"
loose-group_replication_ip_whitelist = "203.0.113.1,203.0.113.2,203.0.113.3"
loose-group_replication_group_seeds = ""203.0.113.1:33061,203.0.113.2:33061,203.0.113.3:33061"
. . .

Esta sección debe ser la misma en cada uno de sus servidores MySQL, así que asegúrese de copiarla cuidadosamente en cada uno.

Elección de primario único o múltiple

A continuación, debe decidir si configurar un grupo de primario único o de primarios múltiples. En una configuración de primario único, MySQL designa un único servidor primario (casi siempre el primer miembro del grupo) para manejar las operaciones de escritura. Un grupo de primarios múltiples permite que cualquiera de los miembros del grupo realice escrituras.

Si deseas configurar un grupo multi-primario, descomenta las directivas loose-group_replication_single_primary_mode y loose-group_replication_enforce_update_everywhere_checks. Esto establecerá un grupo multi-primario. Para un grupo de un solo primario, simplemente deja esas dos líneas comentadas:

. . .
# ¿Modo de un solo primario o multi-primario? Descomenta estas dos líneas
# para el modo multi-primario, donde cualquier host puede aceptar escrituras
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON
. . .

Estas configuraciones deben ser las mismas en cada uno de tus servidores MySQL.

Puedes cambiar esta configuración más adelante, pero después de hacerlo debes reiniciar cada miembro de tu grupo MySQL. Para cambiar a la nueva configuración, tendrás que detener cada una de las instancias de MySQL en el grupo, iniciar cada miembro con las nuevas configuraciones y luego volver a iniciar la replicación del grupo. Esto no afectará ninguno de tus datos, pero requiere una pequeña ventana de tiempo de inactividad.

Configuraciones específicas del host

La cuarta sección contiene configuraciones que serán diferentes en cada uno de los servidores, incluyendo:

• El ID del servidor
• La dirección a la que enlazar
• La dirección para informar a otros miembros
• La dirección de replicación local y el puerto de escucha

La directiva server_id debe establecerse en un número único. Para el primer miembro, establezca esto en 1 e incremente el número en cada host adicional. Establezca bind-address y report_host en la dirección IP respectiva del servidor para que la instancia de MySQL escuche conexiones externas y reporte correctamente su dirección a otros hosts. La directiva loose-group_replication_local_address también debe establecerse en la dirección IP actual del servidor con el puerto de replicación de grupo (33061), añadido a la dirección IP.

Como ejemplo, aquí está esta parte de la configuración para miembro1 usando su dirección IP de muestra:

. . .
# Configuración de replicación específica del host
server_id = 1
bind-address = "203.0.113.1"
report_host = "203.0.113.1"
loose-group_replication_local_address = "203.0.113.1:33061"

Complete este proceso en cada uno de sus servidores MySQL. Aquí está la configuración para miembro2:

. . .
# Configuración de replicación específica del host
server_id = 2
bind-address = "203.0.113.2"
report_host = "203.0.113.2"
loose-group_replication_local_address = "203.0.113.2:33061"

Y aquí está la configuración para miembro3:

. . .
# Configuración de replicación específica del host
server_id = 3
bind-address = "203.0.113.3"
report_host = "203.0.113.3"
loose-group_replication_local_address = "203.0.113.3:33061"

Asegúrese de actualizar cada dirección IP resaltada con la del servidor cuya configuración está editando.

Cuando haya terminado, verifique que la configuración de replicación compartida sea la misma en cada host y que la configuración específica del host esté personalizada para cada host. Guarde y cierre el archivo en cada host cuando haya terminado. Si usó nano para editar el archivo, puede hacerlo presionando CTRL + X, luego Y, y finalmente ENTER.

Cada uno de los archivos de configuración de MySQL de sus servidores ahora contiene las directivas necesarias para iniciar la replicación de grupo de MySQL. Para aplicar los nuevos ajustes a la instancia de MySQL, reinicie el servicio en cada uno de sus servidores con el siguiente comando:

sudo systemctl restart mysql

Con eso, puede pasar a habilitar el acceso remoto actualizando las reglas del firewall de cada uno de sus servidores.

Paso 3 — Actualización de las Reglas de UFW de Cada Servidor

Suponiendo que siguió la guía de configuración inicial del servidor como requisito previo, habrá configurado un firewall en cada uno de los servidores en los que ha instalado MySQL y habilitado el acceso para el perfil UFW OpenSSH. Esta es una medida de seguridad importante, ya que estos firewalls bloquean actualmente las conexiones a cualquier puerto en sus servidores, excepto las conexiones ssh que presentan claves que coinciden con las de cada archivo authorized_keys respectivo de cada servidor.

En el archivo de configuración de MySQL, configuró el servicio para escuchar conexiones externas en el puerto predeterminado 3306. También definió 33061 como el puerto que los miembros deben usar para la coordinación de replicación.

En cada uno de tus servidores miembros, necesitas abrir el acceso a ambos de estos puertos para los otros miembros de este grupo para que puedan comunicarse entre sí. Para abrir el acceso a estos puertos en miembro1 para miembro2, ejecuta los siguientes comandos de ufw en miembro1:

sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

Asegúrate de cambiar member2_server_ip para reflejar la dirección IP real de tu servidor miembro2. Luego, para abrir los mismos puertos para miembro3, ejecuta estos comandos:

sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

A continuación, actualiza las reglas del firewall para tus otros dos servidores. Ejecuta los siguientes comandos en miembro2, asegurándote de cambiar las direcciones IP para reflejar las de miembro1 y miembro3, respectivamente:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

Por último, ejecuta estos dos comandos en miembro3. Nuevamente, asegúrate de ingresar las direcciones IP correctas para cada servidor:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

Después de agregar estas reglas de UFW, cada una de tus tres instancias de MySQL tendrá acceso a los puertos utilizados por MySQL en los otros dos servidores.

Con acceso a los puertos de MySQL abiertos, ahora puedes crear un usuario de replicación y habilitar el plugin de replicación de grupo.

Paso 4 — Configurando Usuarios de Replicación y Habilitando el Plugin de Replicación de Grupo

Para establecer conexiones con los otros servidores en el grupo de replicación, cada instancia de MySQL debe tener un usuario de replicación dedicado.

En cada uno de sus servidores MySQL, inicie sesión en su instancia de MySQL con el usuario administrativo para comenzar una sesión interactiva:

sudo mysql

Debido a que cada servidor tendrá su propio usuario de replicación, debe desactivar el registro binario durante el proceso de creación. De lo contrario, una vez que comience la replicación, el grupo intentaría propagar el usuario de replicación desde el principal a los otros servidores, creando un conflicto con el usuario de replicación ya existente. Ejecute el siguiente comando desde el indicador de MySQL en cada uno de sus servidores:

SET SQL_LOG_BIN=0;

Ahora puede ejecutar una declaración CREATE USER para crear su usuario de replicación. Ejecute el siguiente comando, que crea un usuario llamado repl. Este comando especifica que el usuario de replicación debe conectarse utilizando SSL. Además, asegúrese de usar una contraseña segura en lugar de password al crear este usuario de replicación:

CREATE USER 'repl'@'%' IDENTIFIED BY 'password' REQUIRE SSL;

A continuación, otorgue al nuevo usuario privilegios de replicación en el servidor:

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

Luego, limpie los privilegios para implementar los cambios:

FLUSH PRIVILEGES;

Después de eso, vuelva a habilitar el registro binario para reanudar las operaciones normales:

SET SQL_LOG_BIN=1;

A continuación, establezca el canal group_replication_recovery para usar su nuevo usuario de replicación y su contraseña asociada. Luego, cada servidor usará estas credenciales para autenticarse en el grupo:

CHANGE REPLICATION SOURCE TO SOURCE_USER='repl', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

Con el usuario de replicación configurado, puedes habilitar el complemento group_replication para prepararte para inicializar el grupo:

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

Verifica que el complemento esté activo ejecutando el siguiente comando:

SHOW PLUGINS;

El complemento group_replication aparecerá en la parte inferior de la lista ya que es el complemento más recientemente agregado:

Output
+----------------------------+----------+--------------------+----------------------+---------+
| Name                       | Status   | Type               | Library              | License |
+----------------------------+----------+--------------------+----------------------+---------+
|                            |          |                    |                      |         |
| . . .                      | . . .    | . . .              | . . .                | . . .   |
|                            |          |                    |                      |         |
| group_replication          | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)

Esta salida confirma que el complemento se cargó y está actualmente activo. Antes de continuar con el próximo paso, asegúrate de haber ejecutado cada comando de esta sección en cada una de tus instancias de MySQL.

Paso 5 — Iniciando la Replicación de Grupo

Ahora que cada servidor MySQL tiene un usuario de replicación configurado y el complemento de replicación de grupo habilitado, puedes comenzar a levantar tu grupo.

Iniciando el Primer Nodo

Para iniciar el grupo, completa los siguientes pasos en un único miembro del grupo. Para fines de demostración, esta guía completará estos pasos en miembro1.

Los miembros del grupo dependen de los miembros existentes para enviar datos de replicación, listas de miembros actualizadas y otra información al unirse inicialmente al grupo. Debido a esto, es necesario utilizar un procedimiento ligeramente diferente para iniciar al miembro del grupo inicial para que sepa que no debe esperar esta información de otros miembros en su lista de semillas.

Si se establece, la variable group_replication_bootstrap_group indica a un miembro que no debe esperar recibir información de sus pares y en su lugar debe establecer un nuevo grupo y elegirse a sí mismo como el miembro principal. Puedes activar esta variable con el siguiente comando:

SET GLOBAL group_replication_bootstrap_group=ON;

Luego puedes iniciar la replicación para el miembro inicial del grupo:

START GROUP_REPLICATION;

Después de eso, puedes volver a establecer la variable group_replication_bootstrap_group en OFF, ya que la única situación en la que esto es apropiado es cuando no hay miembros existentes en el grupo:

SET GLOBAL group_replication_bootstrap_group=OFF;

El grupo se iniciará con este servidor como el único miembro. Verifica esto revisando las entradas dentro de la tabla replication_group_members en la base de datos performance_schema:

SELECT * FROM performance_schema.replication_group_members;

Esta consulta devolverá una sola fila que representa el host actual:

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
1 row in set (0.00 sec)

El valor ONLINE para MEMBER_STATE indica que este nodo está completamente operativo dentro del grupo.

A continuación, crea una base de datos de prueba y una tabla con algunos datos de muestra. Una vez que se agreguen más miembros a este grupo, estos datos se replicarán automáticamente hacia ellos.

Comienza creando una base de datos de muestra llamada playground:

CREATE DATABASE playground;

A continuación, crea una tabla de ejemplo llamada equipment dentro de la base de datos playground con el siguiente comando:

CREATE TABLE playground.equipment ( 
id INT NOT NULL AUTO_INCREMENT,
type VARCHAR(50),
quant INT,
color VARCHAR(25),
PRIMARY KEY(id)
);

Esta tabla contiene las siguientes cuatro columnas:

• id: Esta columna contendrá valores enteros que se incrementan automáticamente, lo que significa que no tendrás que especificar valores para esta columna cuando cargues la tabla con datos de ejemplo
• type: Esta columna contendrá valores de cadena que describen qué tipo de equipo de parque representa la fila
• quant: Esta columna contendrá valores enteros para representar la cantidad del tipo dado de equipo de parque
• color: Esta columna contendrá valores de cadena que especifican el color del equipo dado

También, ten en cuenta que la columna id se especifica como la clave primaria de esta tabla. En MySQL, cada tabla replicada a un grupo debe tener una columna designada como la clave primaria de la tabla.

Por último, ejecuta el siguiente comando para insertar una fila de datos en la tabla:

INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");

Consulta la tabla para asegurarte de que los datos se ingresaron correctamente:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.00 sec)

Después de verificar que este servidor es un miembro del grupo y que tiene capacidades de escritura, los otros servidores pueden unirse al grupo.

Iniciando los Nodos Restantes

A continuación, inicie la replicación de grupo en miembro2. Dado que ya tiene un miembro activo, no es necesario inicializar el grupo y este miembro puede unirse directamente:

START GROUP_REPLICATION;

En miembro3, inicie la replicación de grupo de la misma manera:

START GROUP_REPLICATION;

Revise nuevamente la lista de miembros en cualquiera de los tres servidores. Esta vez, habrá tres servidores listados en la salida:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)

Todos los miembros deberían tener un valor de MEMBER_STATE de ONLINE. Para un grupo nuevo, si alguno de los nodos está listado como RECOVERING durante más de unos pocos segundos, usualmente es una indicación de que ha ocurrido un error o algo ha sido mal configurado. Revise los registros en /var/log/mysql/error.log para obtener información adicional sobre qué salió mal.

A continuación, verifique si la información de la base de datos de prueba ha sido replicada en los nuevos miembros:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.01 sec)

Si los datos están disponibles en los nuevos miembros, significa que la replicación de grupo está funcionando correctamente.

Paso 6 — Probando las Capacidades de Escritura de los Nuevos Miembros del Grupo

A continuación, puede intentar escribir en la base de datos desde sus nuevos miembros del grupo de replicación. Si esto tiene éxito o no es una función de si eligió configurar un grupo de un único primario o de múltiples primarios.

Pruebas de escrituras en un entorno de un solo primario

En un grupo de un solo primario, debes esperar que cualquier operación de escritura desde un servidor no primario sea rechazada por razones de consistencia. Puedes encontrar el primario actual en cualquier momento ejecutando la siguiente consulta en cualquier miembro de tu grupo de replicación:

SHOW STATUS LIKE '%primary%';

Output
+----------------------------------+--------------------------------------+
| Variable_name                    | Value                                |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |
+----------------------------------+--------------------------------------+
1 row in set (0.01 sec)

El valor de la consulta será un ID_DE_MIEMBRO que puedes relacionar con un host consultando la lista de miembros del grupo como lo hiciste antes:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

Como indica esta salida de ejemplo, el host en 203.0.113.1 — miembro1 — es actualmente el servidor primario. Si intentas escribir en la base de datos desde otro miembro, la operación fallará:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

Esto es esperado ya que el grupo está actualmente configurado con un único primario capaz de escribir. Si el servidor primario tiene problemas y abandona el grupo, el grupo elegirá automáticamente un nuevo miembro para ser el primario y aceptar escrituras.

Pruebas de escrituras en un entorno de varios primarios

Para grupos que han sido configurados en una orientación de varios primarios, cualquier miembro debería poder realizar escrituras en la base de datos.

Puedes verificar que tu grupo esté funcionando en modo multi-primario revisando el valor de la variable group_replication_primary_member nuevamente:

SHOW STATUS LIKE '%primary%';

Output
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| group_replication_primary_member |       |
+----------------------------------+-------+
1 row in set (0.02 sec)

Si la variable está vacía, significa que no hay un host primario designado y que cualquier miembro debería poder aceptar escrituras.

Prueba esto en miembro2 intentando escribir algunos datos en la tabla equipment:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
Query OK, 1 row affected (0.00 sec)

miembro2 realizó la operación de escritura sin errores.

En miembro3, ejecuta la siguiente consulta para verificar si se agregó el nuevo elemento:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+--------+
| id | type  | quant | color  |
+----+-------+-------+--------+
|  1 | slide |     2 | blue   |
|  2 | swing |    10 | yellow |
+----+-------+-------+--------+
2 rows in set (0.00 sec)

Esto confirma que la escritura de miembro2 se replicó correctamente.

Ahora, prueba las capacidades de escritura en miembro3 ejecutando la siguiente instrucción INSERT:

INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");

Output
Query OK, 1 row affected (0.02 sec)

De vuelta en miembro1, verifica que las operaciones de escritura de ambos nuevos miembros se hayan replicado:

SELECT * FROM playground.equipment;

Output
+----+--------+-------+--------+
| id | type   | quant | color  |
+----+--------+-------+--------+
|  1 | slide  |     2 | blue   |
|  2 | swing  |    10 | yellow |
|  3 | seesaw |     3 | green  |
+----+--------+-------+--------+
3 rows in set (0.01 sec)

Esto confirma que la replicación está funcionando en ambas direcciones y que cada miembro es capaz de realizar operaciones de escritura.

Paso 7 — Volviendo a Levantar el Grupo

Una vez que se ha iniciado el grupo, los miembros individuales pueden unirse y salir sin afectar la disponibilidad, siempre y cuando haya suficientes miembros para elegir servidores primarios. Sin embargo, si se realizan ciertos cambios de configuración (como cambiar entre entornos de servidor único y multiprimario), o si todos los miembros del grupo abandonan, es posible que necesite reiniciar el grupo de la misma manera que lo hizo inicialmente.

En miembro1, configure la variable group_replication_bootstrap_group en ON:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;

Luego inicialice el grupo:

START GROUP_REPLICATION;

Después de eso, puede volver a configurar la variable group_replication_bootstrap_group en OFF:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=OFF;

Una vez que el primer miembro haya iniciado el grupo, otros miembros pueden unirse:

START GROUP_REPLICATION;

Siga este proceso para cualquier miembro adicional:

START GROUP_REPLICATION;

El grupo ahora debería estar en línea con todos los miembros disponibles:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

Este proceso se puede utilizar para iniciar el grupo nuevamente cuando sea necesario.

Paso 8 — Unirse a un Grupo Automáticamente al Iniciar MySQL

Con la configuración actual, si un servidor miembro se reinicia, no se volverá a unir automáticamente al grupo al iniciar. Si desea que los miembros se vuelvan a unir automáticamente al grupo, puede modificar ligeramente el archivo de configuración.

El ajuste descrito en este paso es útil cuando desea que los miembros se unan automáticamente al iniciar. Sin embargo, hay algunas cosas de las que debe ser consciente. En primer lugar, este ajuste solo afecta cuando se inicia la instancia de MySQL en sí misma. Si el miembro es eliminado del grupo debido a problemas de tiempo de espera, pero la instancia de MySQL sigue en línea, el miembro no se volverá a unir automáticamente.

En segundo lugar, tener este ajuste habilitado al inicializar un grupo por primera vez puede ser perjudicial. Cuando no hay un grupo existente al que unirse, el proceso de MySQL tardará mucho tiempo en iniciarse porque intentará contactar a otros miembros no existentes para inicializar. Solo después de un largo tiempo de espera se rendirá y comenzará normalmente. Después, deberá utilizar el procedimiento descrito anteriormente para inicializar el grupo.

Teniendo en cuenta las advertencias anteriores, si desea configurar nodos para unirse automáticamente al grupo cuando MySQL se inicia, abra el archivo de configuración principal de MySQL:

sudo nano /etc/mysql/my.cnf

Dentro, encuentre la variable loose-group_replication_start_on_boot y configúrela en ON:

[mysqld]
. . .
loose-group_replication_start_on_boot = ON
. . .

Guarde y cierre el archivo cuando haya terminado. El miembro debería intentar unirse automáticamente al grupo la próxima vez que se inicie su instancia de MySQL.

Conclusión

Al completar este tutorial, aprendiste cómo configurar la replicación de grupo de MySQL entre tres servidores Ubuntu 20.04. Para configuraciones de un único primario, los miembros elegirán automáticamente un primario con capacidad de escritura cuando sea necesario. Para grupos de varios primarios, cualquier miembro puede realizar escrituras y actualizaciones.

La replicación de grupo proporciona una topología de replicación flexible que permite a los miembros unirse o abandonar a voluntad al mismo tiempo que garantiza la consistencia de los datos y el orden de los mensajes. La replicación de grupo de MySQL puede ser un poco más compleja de configurar, pero proporciona capacidades que no son posibles en la replicación tradicional.