Cómo configurar la replicación en MySQL

Etel Sverdlov escribió una versión anterior de este tutorial .

Introducción

Al trabajar con bases de datos, puede resultar útil tener varias copias de los datos. Esto proporciona redundancia en caso de que uno de los servidores de bases de datos falle y puede mejorar la disponibilidad, la escalabilidad y el rendimiento general de una base de datos. La práctica de sincronizar datos en varias bases de datos independientes se denomina replicación .

MySQL es un sistema de gestión de bases de datos relacionales y es la base de datos relacional de código abierto más popular del mundo en la actualidad. Viene con una serie de funciones de replicación integradas que le permiten mantener varias copias de sus datos.

Este tutorial describe cómo configurar una instancia MySQL en un servidor como base de datos de origen y luego configurar una instancia MySQL en otro servidor para que funcione como su réplica. También incluye una descripción general de cómo MySQL maneja la replicación.

Nota : Históricamente, este tipo de replicación de bases de datos se ha denominado replicación “maestro-esclavo”. En una publicación de blog publicada en julio de 2020 , el equipo de MySQL reconoció el origen negativo de esta terminología y anunció sus esfuerzos por actualizar el programa de base de datos y su documentación para utilizar un lenguaje más inclusivo.

Sin embargo, este es un proceso continuo. Aunque la documentación de MySQL y gran parte de los comandos de la versión8del programa se han actualizado para referirse a los servidores en una topología de replicación como la fuente y sus réplicas , hay lugares donde todavía aparece la terminología negativa. Esta guía utilizará de manera predeterminada la terminología más inclusiva de origen-réplica siempre que sea posible, pero hay algunos casos en los que inevitablemente aparecen los términos más antiguos.

Prerrequisitos

Para completar esta guía, necesitarás:

• Dos servidores con Ubuntu 20.04. Ambos deben tener un usuario administrativo no root con sudoprivilegios y un firewall configurado con UFW. Siga nuestra guía de configuración inicial de servidores para Ubuntu 20.04 para configurar ambos servidores.
• MySQL instalado en cada servidor. Esta guía asume que estás usando la última versión de MySQL disponible en los repositorios predeterminados de Ubuntu que, al momento de escribir este artículo, es la versión8.0.25Para instalarlo en ambos servidores, siga nuestra guía sobre Cómo instalar MySQL en Ubuntu 20.04 .

Tenga en cuenta que el procedimiento descrito en esta guía implica designar la instalación de MySQL en un servidor como la base de datos de origen y luego configurar la instalación de MySQL en el otro servidor para que sea la réplica de la base de datos de origen . Para que todo quede claro, todos los comandos que se deben ejecutar en el servidor de la base de datos de origen tendrán un fondo azul, como este:

Del mismo modo, cualquier comando que deba ejecutarse en el servidor de la instancia MySQL de réplica tendrá un fondo rojo:

Por último, este tutorial incluye instrucciones opcionales sobre cómo migrar datos de una base de datos existente desde el origen a la réplica. Este proceso implica crear una instantánea de la base de datos del origen y copiar el archivo resultante a la réplica. Para ello, recomendamos que configure claves SSH en el servidor de origen y, a continuación, se asegure de que la clave pública del origen se haya copiado a la réplica.

Comprender la replicación en MySQL

En MySQL, la replicación implica que la base de datos de origen anote cada cambio realizado en los datos almacenados en una o más bases de datos en un archivo especial conocido como registro binario . Una vez que se ha inicializado la instancia de réplica, crea dos procesos enhebrados. El primero, llamado subproceso IO , se conecta a la instancia MySQL de origen y lee los eventos del registro binario línea por línea, y luego los copia a un archivo local en el servidor de la réplica llamado registro de retransmisión . El segundo subproceso, llamado subproceso SQL , lee eventos del registro de retransmisión y luego los aplica a la instancia de réplica lo más rápido posible.

Las versiones recientes de MySQL admiten dos métodos para replicar datos. La diferencia entre estos métodos de replicación tiene que ver con la forma en que las réplicas rastrean los eventos de la base de datos de la fuente que ya han procesado.

MySQL se refiere a su método de replicación tradicional como replicación basada en la posición del archivo de registro binario . Cuando convierte una instancia MySQL en una réplica mediante este método, debe proporcionarle un conjunto de coordenadas de registro binario. Estas consisten en el nombre del archivo de registro binario en la fuente que la réplica debe leer y una posición específica dentro de ese archivo que representa el primer evento de base de datos que la réplica debe copiar a su propia instancia MySQL.

Estas coordenadas son importantes porque las réplicas reciben una copia del registro binario completo de su fuente y, sin las coordenadas correctas, comenzarán a replicar todos los eventos de la base de datos registrados en ella. Esto puede generar problemas si solo desea replicar datos después de un determinado momento o solo desea replicar un subconjunto de los datos de la fuente.

La replicación basada en la posición de los archivos de registro binarios es viable para muchos casos de uso, pero este método puede volverse complicado en configuraciones más complejas. Esto llevó al desarrollo del nuevo método de replicación nativo de MySQL, que a veces se denomina replicación basada en transacciones . Este método implica la creación de un identificador de transacción global (GTID) para cada transacción (o una parte aislada del trabajo realizado por una base de datos) que ejecuta la instancia MySQL de origen.

La mecánica de la replicación basada en transacciones es similar a la de la replicación basada en archivos de registro binarios: siempre que se produce una transacción de base de datos en la fuente, MySQL asigna y registra un GTID para la transacción en el archivo de registro binario junto con la transacción misma. El GTID y la transacción se transmiten a las réplicas de la fuente para que las procesen.

La replicación basada en transacciones de MySQL tiene una serie de ventajas sobre su método de replicación tradicional. Por ejemplo, debido a que tanto una fuente como sus réplicas conservan los GTID, si la fuente o una réplica encuentran una transacción con un GTID que ya han procesado antes, omitirán esa transacción. Esto ayuda a garantizar la coherencia entre la fuente y sus réplicas. Además, con la replicación basada en transacciones, las réplicas no necesitan conocer las coordenadas del registro binario del próximo evento de la base de datos que se va a procesar. Esto significa que iniciar nuevas réplicas o cambiar el orden de las réplicas en una cadena de replicación es mucho menos complicado.

Tenga en cuenta que esta es solo una explicación general de cómo MySQL maneja la replicación; MySQL ofrece muchas opciones que puede modificar para optimizar su propia configuración de replicación. Esta guía describe cómo configurar la replicación basada en la posición de archivos de registro binarios. Sin embargo, si está interesado en configurar un tipo diferente de entorno de replicación, le recomendamos que consulte la documentación oficial de MySQL .

Paso 1: Ajuste del firewall de su servidor de origen

Suponiendo que haya seguido los requisitos previos de la Guía de configuración inicial del servidor , habrá configurado un firewall en ambos servidores con UFW. Esto ayudará a mantener seguros ambos servidores, pero el firewall de la fuente bloqueará cualquier intento de conexión desde su instancia MySQL de réplica.

Para cambiar esto, deberá incluir una regla UFW que permita conexiones desde su réplica a través del firewall de origen. Puede hacerlo ejecutando un comando como el siguiente en su servidor de origen .

Este comando en particular permite cualquier conexión que se origine desde la dirección IP del servidor de réplica, representada por replica_server_ip, al número de puerto predeterminado de MySQL 3306:

sudo ufw allow from replica_server_ip to any port 3306

Asegúrese de reemplazarla replica_server_ipcon la dirección IP real de su servidor de réplica. Si la regla se agregó correctamente, verá el siguiente resultado:

OutputRule added

A continuación, no necesitará realizar ningún cambio en las reglas del firewall de la réplica, ya que el servidor de réplica no recibirá ninguna conexión entrante y las conexiones salientes al servidor MySQL de origen no están bloqueadas por UFW. Puede continuar actualizando la configuración de la instancia MySQL de origen para habilitar la replicación.

Paso 2: Configuración de la base de datos de origen

Para que su base de datos MySQL de origen comience a replicar datos, debe realizar algunos cambios en su configuración.

En Ubuntu 20.04, el archivo de configuración del servidor MySQL predeterminado se llama mysqld.cnfy se puede encontrar en el /etc/mysql/mysql.conf.d/directorio. Abra este archivo en el servidor de origen con su editor de texto preferido. Aquí, usaremos nano:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Dentro del archivo, busque la bind-addressdirectiva. Por defecto, se verá así:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .bind-address            = 127.0.0.1. . .

127.0.0.1es una dirección de loopback IPv4 que representa localhost y, al configurarla como valor para la bind-addressdirectiva, se le indica a MySQL que solo escuche conexiones en la dirección localhost . En otras palabras, esta instancia MySQL solo podrá aceptar conexiones que se originen en el servidor donde está instalada.

Recuerde que está convirtiendo su otra instancia MySQL en una réplica de esta, por lo que la réplica debe poder leer cualquier dato nuevo que se escriba en la instalación de origen. Para permitir esto, debe configurar su instancia MySQL de origen para que escuche conexiones en una dirección IP a la que la réplica pueda acceder, como la dirección IP pública del servidor de origen.

Reemplace 127.0.0.1con la dirección IP del servidor de origen. Después de hacerlo, la bind-addressdirectiva se verá así, con la dirección IP de su propio servidor en lugar de source_server_ip:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .bind-address            = source_server_ip. . .

A continuación, busque la server-iddirectiva que define un identificador que MySQL utiliza internamente para distinguir servidores en una configuración de replicación. Cada servidor en un entorno de replicación, incluida la fuente y todas sus réplicas, debe tener su propio server-idvalor único. Esta directiva estará comentada de forma predeterminada y tendrá el siguiente aspecto:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .# server-id             = 1. . .

Quite el comentario de esta línea quitando el signo de almohadilla ( #). Puede elegir cualquier número como valor de esta directiva, pero recuerde que el número debe ser único y no puede coincidir con ningún otro server-iden su grupo de replicación. Para simplificar las cosas, el siguiente ejemplo deja este valor como predeterminado 1:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .server-id               = 1. . .

Debajo de la server-idlínea, busque la log_bindirectiva. Esta define el nombre base y la ubicación del archivo de registro binario de MySQL.

Cuando se comenta, como ocurre de forma predeterminada con esta directiva, se desactiva el registro binario. El servidor de réplica debe leer el archivo de registro binario de la fuente para saber cuándo y cómo replicar los datos de la fuente, por lo que debe descomentar esta línea para habilitar el registro binario en la fuente. Después de hacerlo, se verá así:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .log_bin                       = /var/log/mysql/mysql-bin.log. . .

binlog_do_dbPor último, desplácese hasta la parte inferior del archivo para encontrar la directiva comentada :

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .# binlog_do_db          = include_database_name

Elimine el signo de almohadilla para descomentar esta línea y reemplácela include_database_namecon el nombre de la base de datos que desea replicar. Este ejemplo muestra la binlog_do_dbdirectiva que apunta a una base de datos llamada db, pero si tiene una base de datos existente en su fuente que desea replicar, use su nombre en lugar de db:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .binlog_do_db          = db

Nota : Si desea replicar más de una base de datos, puede agregar otra binlog_do_dbdirectiva para cada base de datos que desee agregar. Este tutorial continuará replicando solo una base de datos, pero si desea replicar más, podría verse así:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .binlog_do_db          = dbbinlog_do_db          = db_1binlog_do_db          = db_2

Alternativamente, puede especificar qué bases de datos MySQL no debe replicar agregando una binlog_ignore_dbdirectiva para cada una:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .binlog_ignore_db          = db_to_ignore

Después de realizar estos cambios, guarde y cierre el archivo. Si solía nanoeditar el archivo, hágalo presionando CTRL + X, Yy luego ENTER.

Luego reinicie el servicio MySQL ejecutando el siguiente comando:

sudo systemctl restart mysql

Con esto, esta instancia MySQL está lista para funcionar como la base de datos de origen que replicará el otro servidor MySQL. Sin embargo, antes de poder configurar la réplica, todavía hay algunos pasos más que debe realizar en la fuente para garantizar que su topología de replicación funcione correctamente. El primero de ellos es crear un usuario MySQL dedicado que realizará todas las acciones relacionadas con el proceso de replicación.

Paso 3: creación de un usuario de replicación

Cada réplica en un entorno de replicación MySQL se conecta a la base de datos de origen con un nombre de usuario y una contraseña. Las réplicas pueden conectarse utilizando cualquier perfil de usuario MySQL que exista en la base de datos de origen y que tenga los privilegios adecuados, pero este tutorial describirá cómo crear un usuario dedicado para este propósito.

Comience abriendo el shell MySQL:

sudo mysql

Nota : Si configuró un usuario MySQL dedicado que se autentica usando una contraseña, puede conectarse a su MySQL con un comando como este:

mysql -u sammy -p

Reemplace sammycon el nombre de su usuario dedicado e ingrese la contraseña de este usuario cuando se le solicite.

Tenga en cuenta que algunas operaciones a lo largo de esta guía, incluidas algunas que deben realizarse en el servidor de réplica, requieren privilegios avanzados. Por este motivo, puede resultar más conveniente conectarse como usuario administrativo, como puede hacerlo con el sudo mysqlcomando anterior. Sin embargo, si desea utilizar un usuario MySQL con menos privilegios a lo largo de esta guía, se le deben otorgar al menos los privilegios CREATE USER, RELOAD, REPLICATION CLIENT, REPLICATION SLAVEy .REPLICATION_SLAVE_ADMIN

Desde el mensaje, crea un nuevo usuario MySQL. El siguiente ejemplo creará un usuario llamado replica_user , pero puedes ponerle el nombre que desees. Asegúrate de cambiar replica_server_ipa la dirección IP pública de tu servidor de réplica y passworda una contraseña segura de tu elección:

CREATE USER 'replica_user'@'replica_server_ip' IDENTIFIED WITH mysql_native_password BY 'password';

Tenga en cuenta que este comando especifica que replica_user utilizará el mysql_native_passwordcomplemento de autenticación. Es posible utilizar en su lugar el mecanismo de autenticación predeterminado de MySQL, caching_sha2_passwordpero esto requeriría configurar una conexión cifrada entre la fuente y la réplica. Este tipo de configuración sería óptima para entornos de producción, pero la configuración de conexiones cifradas está fuera del alcance de este tutorial. La documentación de MySQL incluye instrucciones sobre cómo configurar un entorno de replicación que utilice conexiones cifradas si desea configurar esto.

Después de crear el nuevo usuario, otórguele los privilegios adecuados. Como mínimo, un usuario de replicación MySQL debe tener los REPLICATION SLAVEpermisos:

GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'replica_server_ip';

A continuación, se recomienda ejecutar el FLUSH PRIVILEGEScomando. Esto liberará la memoria que el servidor haya almacenado en caché como resultado de las instrucciones CREATE USERy anteriores GRANT:

FLUSH PRIVILEGES;

Con esto, ha terminado de configurar un usuario de replicación en su instancia MySQL de origen. Sin embargo, no salga del shell MySQL . Déjelo abierto por ahora, ya que lo usará en el siguiente paso para obtener información importante sobre el archivo de registro binario de la base de datos de origen.

Paso 4: Recuperación de las coordenadas del registro binario de la fuente

Recuerde que en la sección Descripción de la replicación en MySQL , MySQL implementa la replicación copiando los eventos de la base de datos desde el archivo de registro binario de la fuente línea por línea e implementando cada evento en la réplica. Cuando se utiliza la replicación basada en la posición del archivo de registro binario de MySQL, debe proporcionar a la réplica un conjunto de coordenadas que detallen el nombre del archivo de registro binario de la fuente y una posición específica dentro de ese archivo. Luego, la réplica utiliza estas coordenadas para determinar el punto en el archivo de registro desde el cual debe comenzar a copiar los eventos de la base de datos y realizar un seguimiento de los eventos que ya ha procesado.

En este paso se describe cómo obtener las coordenadas del registro binario actual de la instancia de origen para configurar las réplicas para que comiencen a replicar datos desde el último punto del archivo de registro. Para asegurarse de que ningún usuario cambie ningún dato mientras recupera las coordenadas, lo que podría generar problemas, deberá bloquear la base de datos para evitar que los clientes lean o escriban datos mientras obtiene las coordenadas. Desbloqueará todo en breve, pero este procedimiento hará que su base de datos pase por un tiempo de inactividad.

Aún debe tener abierto el shell MySQL de su servidor de origen desde el final del paso anterior. Desde el indicador, ejecute el siguiente comando que cerrará todas las tablas abiertas en cada base de datos en su instancia de origen y las bloqueará:

FLUSH TABLES WITH READ LOCK;

Luego, ejecute la siguiente operación que devolverá la información del estado actual de los archivos de registro binarios de la fuente:

SHOW MASTER STATUS;

Verá una tabla similar a este ejemplo en su salida:

Output+------------------+----------+--------------+------------------+-------------------+| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+------------------+----------+--------------+------------------+-------------------+| mysql-bin.000001 |      899 | db           |                  |                   |+------------------+----------+--------------+------------------+-------------------+1 row in set (0.00 sec)

Esta es la posición desde la que la réplica comenzará a copiar eventos de la base de datos. Registre el Filenombre y el Positionvalor, ya que los necesitará más adelante cuando inicie la replicación.

Lo que debe hacer inmediatamente después de obtener esta información depende de si su base de datos de origen tiene datos existentes que desea migrar a sus réplicas. Pase a la subsección que tenga más sentido para su situación.

Si su fuente no tiene datos existentes para migrar

Si su instancia MySQL de origen es una nueva instalación o no tiene datos existentes que desee migrar a sus réplicas, en este punto puede desbloquear las tablas:

UNLOCK TABLES;

Si aún no lo ha hecho, puede crear la base de datos que ha elegido replicar mientras aún tiene abierto el shell MySQL. Siguiendo el ejemplo dado en el paso 2, la siguiente operación creará una base de datos denominada db:

CREATE DATABASE db;

OutputQuery OK, 1 row affected (0.01 sec)

Después de esto, cierre el shell MySQL:

exit

Después de esto, puedes pasar al siguiente paso .

Si su fuente tiene datos existentes para migrar

Si tiene datos en su instancia MySQL de origen que desea migrar a sus réplicas, puede hacerlo creando una instantánea de la base de datos con la mysqldumputilidad. Sin embargo, su base de datos debería seguir bloqueada. Si realiza algún cambio nuevo en la misma ventana, la base de datos se desbloqueará automáticamente. Del mismo modo, las tablas se desbloquearán automáticamente si sale del cliente.

Desbloquear las tablas podría ocasionar problemas, ya que significaría que los clientes podrían volver a cambiar los datos en la base de datos. Esto podría generar una discrepancia entre la instantánea de datos y las coordenadas del registro binario que acaba de recuperar.

Por este motivo, debes abrir una nueva ventana o pestaña de terminal en tu máquina local para poder crear la instantánea de la base de datos sin desbloquear MySQL.

Desde la nueva ventana o pestaña de terminal , abra otra sesión SSH en el servidor que aloja su instancia MySQL de origen :

ssh sammy@source_server_ip

Luego, desde la nueva pestaña o ventana, exporta tu base de datos usando mysqldump. El siguiente ejemplo crea un archivo de volcado llamado db.sqla partir de una base de datos llamada db, pero asegúrate de incluir el nombre de tu propia base de datos en su lugar. Además, asegúrate de ejecutar este comando en el shell bash, no en el shell MySQL:

sudo mysqldump -u root db  db.sql

A continuación, puede cerrar esta ventana o pestaña de terminal y volver a la primera, que aún debería tener abierta la consola MySQL. Desde el símbolo del sistema de MySQL, desbloquee las bases de datos para que se puedan volver a escribir en ellas:

UNLOCK TABLES;

Luego puedes salir del shell MySQL:

exit

Ahora puede enviar su archivo de instantánea a su servidor de réplica. Suponiendo que haya configurado claves SSH en su servidor de origen y haya agregado la clave pública de origen al authorized_keysarchivo de su réplica, puede hacerlo de forma segura con un scpcomando como este:

scp db.sql sammy@replica_server_ip:/tmp/

Asegúrese de reemplazarlo sammycon el nombre del perfil de usuario administrativo de Ubuntu que creó en su servidor de réplica y replica_server_ipcon la dirección IP del servidor de réplica. Además, tenga en cuenta que este comando coloca la instantánea en el /tmp/directorio del servidor de réplica.

Después de enviar la instantánea al servidor de réplica, acceda a él mediante SSH:

ssh sammy@replica_server_ip

Luego abra el shell MySQL:

sudo mysql

Desde el indicador, cree la nueva base de datos que replicará desde la fuente:

CREATE DATABASE db;

No es necesario crear ninguna tabla ni cargar esta base de datos con datos de muestra. Todo esto se solucionará cuando importe la base de datos utilizando la instantánea que acaba de crear. En su lugar, salga del shell MySQL:

exit

Luego importe la instantánea de la base de datos:

sudo mysql db  /tmp/db.sql

Ahora, su réplica tiene todos los datos existentes de la base de datos de origen. Puede completar el paso final de esta guía para configurar su servidor de réplica para que comience a replicar los nuevos cambios realizados en la base de datos de origen.

Paso 5: Configuración de la base de datos de réplica

Lo único que queda por hacer es cambiar la configuración de la réplica de forma similar a como cambiaste la de la fuente. Abre el archivo de configuración de MySQL, mysqld.cnfesta vez en tu servidor de réplica :

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Como se mencionó anteriormente, cada instancia de MySQL en una configuración de replicación debe tener un valor único server-id. Busque la server-iddirectiva de la réplica, descomentela y cambie su valor a cualquier entero positivo, siempre que sea diferente al de la fuente:

/etc/mysql/mysql.conf.d/mysqld.cnf

server-id               = 2

A continuación, actualice los valores log_biny binlog_do_dbpara que se alineen con los valores que estableció en el archivo de configuración de la máquina de origen:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .log_bin                 = /var/log/mysql/mysql-bin.log. . .binlog_do_db            = db. . .

Por último, agregue una relay-logdirectiva que defina la ubicación del archivo de registro de retransmisión de la réplica. Incluya la siguiente línea al final del archivo de configuración:

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .relay-log               = /var/log/mysql/mysql-relay-bin.log

Después de realizar estos cambios, guarde y cierre el archivo. Luego, reinicie MySQL en la réplica para implementar la nueva configuración:

sudo systemctl restart mysql

Después de reiniciar el mysqlservicio, finalmente estará listo para comenzar a replicar datos desde su base de datos de origen.

Paso 6: iniciar y probar la replicación

En este punto, ambas instancias de MySQL están completamente configuradas para permitir la replicación. Para comenzar a replicar datos desde su fuente, abra el shell de MySQL en su servidor de réplica :

sudo mysql

Desde el indicador, ejecute la siguiente operación, que configura varias opciones de replicación de MySQL al mismo tiempo. Después de ejecutar este comando, una vez que habilite la replicación en esta instancia, intentará conectarse a la siguiente dirección IP SOURCE_HOSTutilizando el nombre de usuario y la contraseña que aparecen después de SOURCE_USERy SOURCE_PASSWORD, respectivamente. También buscará un archivo de registro binario con el nombre que aparece a continuación SOURCE_LOG_FILEy comenzará a leerlo desde la posición que aparece después de SOURCE_LOG_POS.

Asegúrese de reemplazarla source_server_ipcon la dirección IP de su servidor de origen. Asimismo, replica_usery passworddebe coincidir con el usuario de replicación que creó en el Paso 2; y mysql-bin.000001y 899debe reflejar las coordenadas del registro binario que obtuvo en el Paso 3.

Es posible que desees escribir este comando en un editor de texto antes de ejecutarlo en tu servidor de réplica para que puedas reemplazar más fácilmente toda la información relevante:

CHANGE REPLICATION SOURCE TO
SOURCE_HOST='source_server_ip',
SOURCE_USER='replica_user',
SOURCE_PASSWORD='password',
SOURCE_LOG_FILE='mysql-bin.000001',
SOURCE_LOG_POS=899;

A continuación, active el servidor de réplica:

START REPLICA;

Si ingresó todos los detalles correctamente, esta instancia comenzará a replicar cualquier cambio realizado en la dbbase de datos en la fuente.

Puede ver detalles sobre el estado actual de la réplica ejecutando la siguiente operación. El Gmodificador de este comando reorganiza el texto para que sea más legible:

SHOW REPLICA STATUSG;

Este comando devuelve mucha información que puede ser útil para solucionar problemas:

Output*************************** 1. row ***************************             Replica_IO_State: Waiting for master to send event                  Source_Host: 138.197.3.190                  Source_User: replica_user                  Source_Port: 3306                Connect_Retry: 60              Source_Log_File: mysql-bin.000001          Read_Source_Log_Pos: 1273               Relay_Log_File: mysql-relay-bin.000003                Relay_Log_Pos: 729        Relay_Source_Log_File: mysql-bin.000001. . .

Nota : Si su réplica tiene un problema de conexión o la replicación se detiene inesperadamente, es posible que un evento en el archivo de registro binario de la fuente esté impidiendo la replicación. En tales caso