Replicación

La replicación permite que los datos de un servidor de base de datos MySQL (conocido como fuente) se copien a uno o más servidores de base de datos MySQL (conocidos como réplicas). La replicación es asíncrona de forma predeterminada; las réplicas no necesitan estar conectadas permanentemente para recibir actualizaciones de una fuente. Dependiendo de la configuración, puede replicar todas las bases de datos, bases de datos seleccionadas o incluso tablas seleccionadas dentro de una base de datos.

Las ventajas de la replicación en MySQL incluyen:

  • Soluciones de escalamiento horizontal: repartir la carga entre varias réplicas para mejorar el rendimiento. En este entorno, todas las escrituras y actualizaciones deben tener lugar en el servidor de origen. Sin embargo, las lecturas pueden tener lugar en una o más réplicas. Este modelo puede mejorar el rendimiento de las escrituras (ya que la fuente está dedicada a las actualizaciones), al tiempo que aumenta drásticamente la velocidad de lectura en un número cada vez mayor de réplicas.

  • Seguridad de los datos: debido a que la réplica puede pausar el proceso de réplica, es posible ejecutar servicios de copia de seguridad en la réplica sin dañar los datos de origen correspondientes.

  • Análisis: se pueden crear datos en vivo en la fuente, mientras que el análisis de la información puede tener lugar en la réplica sin afectar el rendimiento de la fuente.

  • Distribución de datos a larga distancia: puede usar la replicación para crear una copia local de datos para que la use un sitio remoto, sin acceso permanente a la fuente.

MySQL 8.0 admite diferentes métodos de replicación. El método tradicional se basa en replicar eventos del registro binario de la fuente y requiere que los archivos de registro y las posiciones en ellos estén sincronizados entre la fuente y la réplica. El método más nuevo basado en identificadores de transacciones globales (GTID) es transaccional y, por lo tanto, no requiere trabajar con archivos de registro o posiciones dentro de estos archivos, lo que simplifica en gran medida muchas tareas comunes de replicación. La replicación mediante GTID garantiza la coherencia entre la fuente y la réplica siempre que todas las transacciones comprometidas en la fuente también se hayan aplicado en la réplica.

La replicación en MySQL admite diferentes tipos de sincronización. El tipo original de sincronización es la replicación asíncrona unidireccional, en la que un servidor actúa como fuente, mientras que uno o más servidores actúan como réplicas. Esto contrasta con la replicación sincrónica que es una característica de NDB Cluster. En MySQL 8.0, se admite la replicación semisincrónica además de la replicación asincrónica incorporada. Con la replicación semisincrónica, se realiza una confirmación en los bloques de origen antes de regresar a la sesión que realizó la transacción hasta que al menos una réplica reconoce que ha recibido y registrado los eventos de la transacción. MySQL 8.0 también admite la replicación retrasada, de modo que una réplica se retrasa deliberadamente con respecto a la fuente al menos una cantidad de tiempo especificada. Para escenarios donde se requiere replicación síncrona, use NDB Cluster.

Puede usar la replicación para resolver una serie de problemas diferentes, incluido el rendimiento, el respaldo de la copia de seguridad de diferentes bases de datos y como parte de una solución más grande para aliviar las fallas del sistema.

Configuración de la replicación

Esta sección describe cómo configurar los diferentes tipos de replicación disponibles en MySQL e incluye la instalación y configuración necesarias para un entorno de replicación, incluidas las instrucciones paso a paso para crear un nuevo entorno de replicación.

Descripción general de la configuración de la replicación basada en la posición del archivo de registro binario

Esta sección describe la replicación entre servidores MySQL basada en el método de posición del archivo de registro binario, donde la instancia de MySQL que opera como fuente (donde tienen lugar los cambios en la base de datos) escribe actualizaciones y cambios como " eventos " en el registro binario. La información en el registro binario se almacena en diferentes formatos de registro de acuerdo con los cambios en la base de datos que se registran. Las réplicas están configuradas para leer el registro binario de la fuente y ejecutar los eventos en el registro binario en la base de datos local de la réplica.

Cada réplica recibe una copia de todo el contenido del registro binario. Es responsabilidad de la réplica decidir qué declaraciones del registro binario deben ejecutarse. A menos que especifique lo contrario, todos los eventos del registro binario de origen se ejecutan en la réplica. Si es necesario, puede configurar la réplica para procesar solo eventos que se apliquen a bases de datos o tablas particulares.

Importante: No puede configurar la fuente para registrar solo ciertos eventos.

Cada réplica mantiene un registro de las coordenadas del registro binario: el nombre del archivo y la posición dentro del archivo que ha leído y procesado desde la fuente. Esto significa que se pueden conectar varias réplicas al origen y ejecutar diferentes partes del mismo registro binario. Debido a que las réplicas controlan este proceso, las réplicas individuales se pueden conectar y desconectar del servidor sin afectar el funcionamiento de la fuente. Además, debido a que cada réplica registra la posición actual dentro del registro binario, es posible que las réplicas se desconecten, se vuelvan a conectar y luego reanuden el procesamiento.

La fuente y cada réplica deben configurarse con un ID único (utilizando la variable del sistema [server_id]. Además, cada réplica debe configurarse con información sobre el nombre de host de la fuente, el nombre del archivo de registro y la posición dentro de ese archivo. Estos detalles se pueden controlar desde una sesión de MySQL mediante una declaración [CHANGE REPLICATION SOURCE TO] o una declaración CHANGE MASTER TO en la réplica. Los detalles se almacenan en el repositorio de metadatos de conexión de la réplica.

Configuración de la replicación basada en la posición del archivo de registro binario

Esta sección describe cómo configurar un servidor MySQL para usar la replicación basada en la posición del archivo de registro binario. Hay varios métodos diferentes para configurar la replicación, y el método exacto a utilizar depende de cómo esté configurando la replicación y de si ya tiene datos en la base de datos en el origen que desea replicar.

Establecimiento de la configuración de la fuente de replicación

Para configurar una fuente para utilizar la replicación basada en la posición del archivo de registro binario, debe asegurarse de que el registro binario esté habilitado y establecer una ID de servidor única.

Cada servidor dentro de una topología de replicación debe configurarse con un ID de servidor único, que puede especificar mediante la variable del sistema [server_id]. Esta ID de servidor se utiliza para identificar servidores individuales dentro de la topología de replicación y debe ser un número entero positivo entre 1 y (2 ^32^ ) -1. El valor predeterminado en MySQL 8.0 para [server_id] es 1. Puede cambiar el valor de [server_id] dinámicamente emitiendo una declaración como esta:

SET GLOBAL server_id = 2;

La forma en que organiza y selecciona los ID de servidor es su elección, siempre que cada ID de servidor sea diferente de cualquier otro ID de servidor utilizado por cualquier otro servidor en la topología de replicación. Tenga en cuenta que si se estableció previamente un valor de 0 (que era el valor predeterminado en versiones anteriores) para la ID del servidor, debe reiniciar el servidor para inicializar la fuente con su nueva ID de servidor distinta de cero. De lo contrario, no es necesario reiniciar el servidor cuando cambie la ID del servidor, a menos que realice otros cambios de configuración que lo requieran.

El registro binario es necesario en el origen porque el registro binario es la base para replicar los cambios del origen a sus réplicas. El registro binario está habilitado de forma predeterminada (la variable del sistema [log_bin] está activada). La opción [--log-bin] le dice al servidor qué nombre base usar para los archivos de registro binarios. Se recomienda que especifique esta opción para dar a los archivos de registro binarios un nombre base no predeterminado, de modo que si el nombre de host cambia, pueda seguir utilizando fácilmente los mismos nombres de archivo de registro binarios. Si el registro binario se deshabilitó anteriormente en el origen con la opción [--skip-log-bin], debe reiniciar el servidor sin esta opción para habilitarlo.

Nota Las siguientes opciones también tienen un impacto en la fuente:

  • Para obtener la mayor durabilidad y consistencia posible en una configuración de replicación que usa [InnoDB] con transacciones, debe usar innodb_flush_log_at_trx_commit=1 y sync_binlog=1 en el archivo de origen my.cnf.

  • Asegúrese de que la variable del sistema [skip_networking] no esté habilitada en la fuente. Si la red se ha deshabilitado, la réplica no se puede comunicar con el origen y falla la réplica.

Configuración de la réplica

Cada réplica debe tener un ID de servidor único, según lo especificado por la variable del sistema [server_id]. Si está configurando varias réplicas, cada una debe tener un valor único [server_id] que difiera del de origen y de cualquiera de las otras réplicas. Si el ID del servidor de la réplica aún no está configurado, o el valor actual entra en conflicto con el valor que ha elegido para la fuente u otra réplica, debe cambiarlo.

El valor predeterminado [server_id] para es 1. Puede cambiar el valor dinámicamente [server_id] emitiendo una declaración como esta:

SET GLOBAL server_id = 21;

Tenga en cuenta que un valor de 0 para el ID del servidor evita que una réplica se conecte a una fuente. Si ese valor de ID de servidor (que era el predeterminado en versiones anteriores) se estableció previamente, debe reiniciar el servidor para inicializar la réplica con su nueva ID de servidor distinta de cero. De lo contrario, no es necesario reiniciar el servidor cuando cambie la ID del servidor, a menos que realice otros cambios de configuración que lo requieran. Por ejemplo, si el registro binario se deshabilitó en el servidor y desea que esté habilitado para su réplica, es necesario reiniciar el servidor para habilitarlo.

Si está cerrando el servidor de réplica, puede editar la sección [mysqld] del archivo de configuración para especificar una ID de servidor única. Por ejemplo:

[mysqld]
server-id=21

El registro binario está habilitado de forma predeterminada en todos los servidores. No es necesario que una réplica tenga habilitado el registro binario para que se lleve a cabo la réplica. Sin embargo, el registro binario en una réplica significa que el registro binario de la réplica se puede utilizar para copias de seguridad de datos y recuperación de fallos. Las réplicas que tienen habilitado el registro binario también se pueden utilizar como parte de una topología de réplica más compleja. Por ejemplo, es posible que desee configurar servidores de replicación utilizando este arreglo encadenado:

A -> B -> C

Aquí, Asirve como fuente para la réplica B y Bsirve como fuente para la réplica C. Para que esto funcione, B debe ser tanto una fuente como una réplica. Las actualizaciones recibidas de A deben registrarse B en su registro binario para poder pasar a C. Además del registro binario, esta topología de replicación requiere que la variable del sistema [log_replica_updates] (de MySQL 8.0.26) o [log_slave_updates] (antes de MySQL 8.0.26) esté habilitada. Con las actualizaciones de réplica habilitadas, la réplica escribe las actualizaciones que se reciben de una fuente y las realiza el subproceso SQL de la réplica en el propio registro binario de la réplica. los [log_replica_updates] o la variable del sistema [log_slave_updates] está habilitada de forma predeterminada.

Si es necesario deshabilitar el registro binario o una réplica de actualización de registro en una réplica, puede hacerlo especificando las opciones para la réplica [--skip-log-bin] e [--log-replica-updates=OFF] o [--log-slave-updates=OFF]. Si decide volver a habilitar estas funciones en la réplica, elimine las opciones relevantes y reinicie el servidor.

Creación de un usuario para la replicación

Cada réplica se conecta a la fuente mediante un nombre de usuario y contraseña de MySQL, por lo que debe haber una cuenta de usuario en la fuente que la réplica pueda usar para conectarse. El nombre de usuario se especifica mediante la opción SOURCE_USER| MASTER_USER de la declaración [CHANGE REPLICATION SOURCE TO] o [CHANGE MASTER TO] cuando configura una réplica. Se puede utilizar cualquier cuenta para esta operación, siempre que se le haya otorgado el privilegio [REPLICATION SLAVE] privilegio. Puede optar por crear una cuenta diferente para cada réplica o conectarse a la fuente utilizando la misma cuenta para cada réplica.

Aunque no es necesario crear una cuenta específicamente para la replicación, debe tener en cuenta que el nombre de usuario y la contraseña de replicación se almacenan en texto sin formato en el repositorio de metadatos de conexión de la réplica mysql.slave_master_info. Por lo tanto, es posible que desee crear una cuenta separada que tenga privilegios solo para el proceso de replicación, para minimizar la posibilidad de comprometer otras cuentas.

Para crear una nueva cuenta, use [CREATE USER]. Para otorgar a esta cuenta los privilegios necesarios para la replicación, use la declaración [GRANT].Si crea una cuenta únicamente con fines de replicación, esa cuenta solo necesita el privilegio [REPLICATION SLAVE]. Por ejemplo, para configurar un nuevo usuario, repl que puede conectarse para la replicación desde cualquier host dentro del dominio example.com, emita estas declaraciones en la fuente:

mysql> CREATE USER 'repl'@'%.example.com' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.example.com';

Obtención de las coordenadas del registro binario de la fuente de replicación

Para configurar la réplica para iniciar el proceso de réplica en el punto correcto, debe anotar las coordenadas actuales de la fuente dentro de su registro binario.

Advertencia

Este procedimiento utiliza [FLUSH TABLES WITH READ LOCK], que bloquea las operaciones [COMMIT] de las tablas [InnoDB].

Si planea cerrar la fuente para crear una instantánea de datos, opcionalmente puede omitir este procedimiento y, en su lugar, almacenar una copia del archivo de índice de registro binario junto con la instantánea de datos. En esa situación, la fuente crea un nuevo archivo de registro binario al reiniciar. Las coordenadas del registro binario de origen donde la réplica debe iniciar el proceso de replicación son, por lo tanto, el inicio de ese nuevo archivo, que es el siguiente archivo de registro binario en el origen que sigue a los archivos que se enumeran en el archivo de índice de registro binario copiado.

Para obtener las coordenadas del registro binario de origen, siga estos pasos:

  1. Inicie una sesión en la fuente conectándose a ella con el cliente de línea de comandos, y vacíe todas las tablas y bloquee las declaraciones de escritura ejecutando la declaración [FLUSH TABLES WITH READ LOCK]:

    mysql> FLUSH TABLES WITH READ LOCK;

    Advertencia

    Deje en ejecución el cliente desde el que emitió la declaración [FLUSH TABLES] para que el bloqueo de lectura permanezca en vigor. Si sale del cliente, se libera el bloqueo.

  2. En una sesión diferente en la fuente, use la declaración [SHOW MASTER STATUS] para determinar el nombre y la posición del archivo de registro binario actual:

    mysql > SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 73       | test         | manual,mysql     |
+------------------+----------+--------------+------------------+

    La columna File muestra el nombre del archivo de registro y la columna Position muestra la posición dentro del archivo. En este ejemplo, el archivo de registro binario es mysql-bin.000003y la posición es 73. Registre estos valores. Los necesitará más adelante cuando esté configurando la réplica. Representan las coordenadas de replicación en las que la réplica debe comenzar a procesar nuevas actualizaciones desde la fuente.

    Si la fuente se ha estado ejecutando anteriormente con el registro binario deshabilitado, el nombre del archivo de registro y los valores de posición mostrados por [SHOW MASTER STATUS] o [mysqldump --master-data] están vacíos. En ese caso, los valores que necesita usar más adelante al especificar el archivo de registro binario y la posición de la fuente son la cadena vacía ( '') y 4.

Ahora tiene la información que necesita para permitir que la réplica comience a leer desde el registro binario de la fuente en el lugar correcto para iniciar la réplica.

El siguiente paso depende de si tiene datos existentes en la fuente. Elige una de las siguientes opciones:

  • Si tiene datos existentes que deben sincronizarse con la réplica antes de iniciar la réplica, deje el cliente en ejecución para que el bloqueo permanezca en su lugar. Esto evita que se realicen más cambios, de modo que los datos copiados en la réplica estén sincronizados con la fuente. Continúe en el punto siguiente.

  • Si está configurando una nueva combinación de fuente y réplica, puede salir de la primera sesión para liberar el bloqueo de lectura. Puede pasar al punto: ["Configuración de la replicación con una nueva fuente y réplicas"]

Elección de un método para instantáneas de datos

Si la base de datos de origen contiene datos existentes, es necesario copiar estos datos en cada réplica. Hay diferentes formas de volcar los datos de la base de datos de origen. Las siguientes secciones describen posibles opciones.

Para seleccionar el método apropiado de volcado de la base de datos, elija entre estas opciones:

  • Utilice la herramienta [mysqldump] para crear un volcado de todas las bases de datos que desea replicar. Este es el método recomendado, especialmente cuando se usa [InnoDB].

  • Si su base de datos está almacenada en archivos portátiles binarios, puede copiar los archivos de datos sin procesar en una réplica. Esto puede ser más eficiente que usar [mysqldump] e importar el archivo en cada réplica, porque omite la sobrecarga de actualizar índices a medida INSERTque se reproducen las declaraciones. Con motores de almacenamiento como [InnoDB] esto no se recomienda.

  • Utilice el complemento de clonación de MySQL Server para transferir todos los datos de una réplica existente a un clon.

Creación de una instantánea de datos con mysqldump

Para crear una instantánea de los datos en una base de datos de origen existente, use la herramienta [mysqldump]. Una vez que se haya completado el volcado de datos, importe estos datos a la réplica antes de iniciar el proceso de réplica.

El siguiente ejemplo vuelca todas las bases de datos en un archivo con nombre dbdump.dbe incluye la opción [--master-data] que agrega automáticamente la declaración [CHANGE REPLICATION SOURCE TO] | [CHANGE MASTER TO] requerida en la réplica para iniciar el proceso de réplica:

$> mysqldump --all-databases --master-data > dbdump.db

Nota

Si no usa [--master-data], entonces es necesario bloquear todas las tablas en una sesión separada manualmente.

Es posible excluir ciertas bases de datos del volcado usando la herramienta [mysqldump]. Si desea elegir qué bases de datos incluir en el volcado, no utilice [--all-databases]. Elija una de estas opciones:

  • Excluya todas las tablas de la base de datos usando la opción[--ignore-table].

  • Nombra solo aquellas bases de datos que quieras que se vuelquen usando la opción [--databases].

Nota

De forma predeterminada, si los GTID están en uso en el origen ( [gtid_mode=ON]), [mysqldump] incluye los GTID del conjunto de origen [gtid_executed] en la salida del volcado para agregarlos al conjunto de la réplica [gtid_purged]. Si está volcando solo bases de datos o tablas específicas, es importante tener en cuenta que el valor que incluye [mysqldump] incluye los GTID de todas las transacciones en el [gtid_executed] conjunto en la fuente, incluso aquellas que cambiaron partes suprimidas de la base de datos u otras bases de datos en el servidor que no se incluyó en el volcado parcial. Verifique la descripción de mysqldump's la opción --set-gtid-purged para encontrar el resultado del comportamiento predeterminado para las versiones de MySQL Server que está utilizando y cómo cambiar el comportamiento si este resultado no es adecuado para su situación.

Para importar los datos, copie el archivo de volcado en la réplica o acceda al archivo desde el origen cuando se conecte de forma remota a la réplica.

Creación de una instantánea de datos utilizando archivos de datos sin procesar

Esta sección describe cómo crear una instantánea de datos utilizando los archivos sin procesar que componen la base de datos. Emplear este método con una tabla que usa un motor de almacenamiento que tiene algoritmos complejos de almacenamiento en caché o de registro requiere pasos adicionales para producir una instantánea perfecta de " punto en el tiempo " : el comando de copia inicial podría omitir información de caché y actualizaciones de registro, incluso si ha adquirido una bloqueo de lectura global. La forma en que el motor de almacenamiento responde a esto depende de sus capacidades de recuperación ante fallos.

Para crear una instantánea de datos sin procesar de tbla [MyISAM] cuando sus archivos de datos MySQL existen en un solo sistema de archivos, puede usar herramientas de copia de archivos estándar como cp o copy , una herramienta de copia remota como scp o rsync , una herramienta de archivo como zip o tar , o una herramienta de instantáneas del sistema de archivos como dump . Si está replicando solo determinadas bases de datos, copie solo los archivos que se relacionen con esas tablas.Porque InnoDB, todas las tablas de todas las bases de datos se almacenan en el archivo [espacio de tabla del sistema, a menos que tenga la la opción [innodb_file_per_table].

Los siguientes archivos no son necesarios para la replicación:

  • Archivos relacionados con la base de datosmysql.

  • El archivo de repositorio de metadatos de conexión de la réplica master.info, si se utiliza; el uso de este archivo ha quedado obsoleto.

  • Los archivos de registro binario de origen, con la excepción del archivo de índice de registro binario si va a utilizarlo para localizar las coordenadas del registro binario de origen para la réplica.

  • Cualquier archivo de registro de retransmisión.

Dependiendo de si está usando tablas InnoDB o no, elija una de las siguientes opciones:

Si está utilizando tablas [InnoDB], y también para obtener los resultados más consistentes con una instantánea de datos sin procesar, apague el servidor de origen durante el proceso, de la siguiente manera:

  1. Adquiera un bloqueo de lectura y obtenga el estado de la fuente.

  2. En una sesión separada, apague el servidor de origen:

    $> mysqladmin shutdown

  3. Haga una copia de los archivos de datos de MySQL. Los siguientes ejemplos muestran formas comunes de hacer esto. Debe elegir solo uno de ellos:

    $> tar cf /tmp/db.tar ./data
$> zip -r /tmp/db.zip ./data
$> rsync --recursive ./data /tmp/dbdata

  4. Reinicie el servidor de origen.

Si no está utilizando tablas [InnoDB], puede obtener una instantánea del sistema de una fuente sin apagar el servidor como se describe en los siguientes pasos:

  1. Adquiera un bloqueo de lectura y obtenga el estado de la fuente.

  2. Haga una copia de los archivos de datos de MySQL. Los siguientes ejemplos muestran formas comunes de hacer esto. Debe elegir solo uno de ellos:

    $> tar cf /tmp/db.tar ./data
$> zip -r /tmp/db.zip ./data
$> rsync --recursive ./data /tmp/dbdata

  3. En el cliente donde adquirió el bloqueo de lectura, libere el bloqueo:

    mysql> UNLOCK TABLES;

Una vez que haya creado el archivo o la copia de la base de datos, copie los archivos en cada réplica antes de iniciar el proceso de réplica.

Configurar réplicas

Antes de comenzar con la configuración asegurarse de: 1. Haber seguido el punto Establecimiento de la configuración de la fuente de replicación 2. Obtuvo la información de la fuente o una copia de del archivo de índice del registro binario de la fuente 3. En la fuente se liberó el bloque de lectura 

    mysql> UNLOCK TABLES;
4. En la réplica editó la configuración de MySQL

Ahora dependiendo de si se tiene los datos existentes para importar a la réplica. - Si no los tiene, siga por el punto Configuración de la replicación con una nueva fuente y réplicas - Si los tiene, siga por el punto Configuración de la replicación con datos existentes

Configuración de la replicación con una nueva fuente y réplicas

Cuando no haya una instantánea de una base de datos anterior para importar, configure la réplica para iniciar la réplica desde la nueva fuente.

Para configurar la replicación entre una fuente y una nueva réplica:

  1. Inicie la réplica.

  2. Ejecute la declaración [CHANGE REPLICATION SOURCE TO] | [CHANGE MASTER TO] en la réplica para establecer la configuración de origen.

Realice estos pasos de configuración de réplicas en cada réplica.

Este método también se puede utilizar si está configurando nuevos servidores pero tiene un volcado existente de las bases de datos de un servidor diferente que desea cargar en su configuración de replicación. Al cargar los datos en una nueva fuente, los datos se replican automáticamente en las réplicas.

Si está configurando un nuevo entorno de replicación utilizando los datos de un servidor de base de datos existente diferente para crear una nueva fuente, ejecute el archivo de volcado generado desde ese servidor en la nueva fuente. Las actualizaciones de la base de datos se propagan automáticamente a las réplicas:

$> mysql -h source < fulldb.dump
Configuración de la replicación con datos existentes

Al configurar la replicación con datos existentes, transfiera la instantánea desde el origen a la réplica antes de iniciar la replicación. El proceso para importar datos a la réplica depende de cómo creó la instantánea de datos en la fuente.

Siga este procedimiento para configurar la replicación con datos existentes:

  1. Si usó el complemento de clonación de MySQL Server para crear un clon a partir de una réplica existente , los datos ya están transferidos. De lo contrario, importe los datos a la réplica mediante uno de los siguientes métodos.

    1. Si usó [mysqldump], inicie el servidor de réplica, asegurándose de que la réplica no se inicie usando la opción [--skip-slave-start], o desde MySQL 8.0.24, la variable [skip_slave_start] del sistema. Luego importe el archivo de volcado:

      $> mysql < fulldb.dump

    2. Si creó una instantánea con los archivos de datos sin procesar, extraiga los archivos de datos en el directorio de datos de su réplica. Por ejemplo:

      $> tar xvf dbdump.tar

      Es posible que deba establecer los permisos y la propiedad de los archivos para que el servidor de réplica pueda acceder a ellos y modificarlos. Luego, inicie el servidor de réplica, asegurándose de que la réplica no se inicie utilizando la opción [--skip-slave-start] opción, o desde MySQL 8.0.24, la variable [skip_slave_start] del sistema.

  2. Configure la réplica con las coordenadas de réplica de la fuente. Esto le dice a la réplica el archivo de registro binario y la posición dentro del archivo donde debe comenzar la replicación. Además, configure la réplica con las credenciales de inicio de sesión y el nombre de host de la fuente.

  3. Inicie los subprocesos de replicación emitiendo una declaración [START REPLICA] (o antes de MySQL 8.0.22 [START SLAVE]).

Una vez realizado este procedimiento, la réplica se conecta al origen y replica las actualizaciones que se hayan producido en el origen desde que se tomó la instantánea. Los mensajes de error se envían al registro de errores de la réplica si no se puede replicar por algún motivo.

Establecer la configuración de origen en la réplica

Para configurar la réplica para que se comunique con el origen de la réplica, configure la réplica con la información de conexión necesaria. Para hacer esto, en la réplica, ejecute la instrucción [CHANGE REPLICATION SOURCE TO] o la instrucción [CHANGE MASTER TO] (antes de MySQL 8.0.23), reemplazando los valores de las opciones con los valores reales relevantes para su sistema:

mysql> CHANGE MASTER TO
    ->     MASTER_HOST='source_host_name',
    ->     MASTER_USER='replication_user_name',
    ->     MASTER_PASSWORD='replication_password',
    ->     MASTER_LOG_FILE='recorded_log_file_name',
    ->     MASTER_LOG_POS=recorded_log_position;

-- Or from MySQL 8.0.23:
mysql> CHANGE REPLICATION SOURCE TO
    ->     SOURCE_HOST='source_host_name',
    ->     SOURCE_USER='replication_user_name',
    ->     SOURCE_PASSWORD='replication_password',
    ->     SOURCE_LOG_FILE='recorded_log_file_name',
    ->     SOURCE_LOG_POS=recorded_log_position;

Nota

La replicación no puede utilizar archivos de socket Unix. Debe poder conectarse al servidor MySQL de origen mediante TCP / IP.

Implementación de la replicación

La replicación se basa en que el servidor de origen realiza un seguimiento de todos los cambios en sus bases de datos (actualizaciones, eliminaciones, etc.) en su registro binario. El registro binario sirve como un registro escrito de todos los eventos que modifican la estructura o el contenido (datos) de la base de datos desde el momento en que se inició el servidor. Normalmente, las declaraciones [SELECT] no se registran porque no modifican ni la estructura ni el contenido de la base de datos.

Cada réplica que se conecta a la fuente solicita una copia del registro binario. Es decir, extrae los datos de la fuente, en lugar de que la fuente envíe los datos a la réplica. La réplica también ejecuta los eventos del registro binario que recibe. Esto tiene el efecto de repetir los cambios originales tal como se hicieron en la fuente. Se crean tablas o se modifica su estructura, y los datos se insertan, eliminan y actualizan de acuerdo con los cambios que se realizaron originalmente en la fuente.

Dado que cada réplica es independiente, la reproducción de los cambios del registro binario de la fuente se produce de forma independiente en cada réplica que está conectada a la fuente. Además, debido a que cada réplica recibe una copia del registro binario solo solicitándola a la fuente, la réplica puede leer y actualizar la copia de la base de datos a su propio ritmo y puede iniciar y detener el proceso de replicación a voluntad sin afectar la capacidad de actualizar al último estado de la base de datos en el lado de la fuente o de la réplica.

Los servidores de origen y las réplicas informan su estado con respecto al proceso de réplica con regularidad para que pueda supervisarlos.

El registro binario de la fuente se escribe en un registro de retransmisión local en la réplica antes de que se procese. La réplica también registra información sobre la posición actual con el registro binario de la fuente y el registro de retransmisión local.

Los cambios de la base de datos se filtran en la réplica de acuerdo con un conjunto de reglas que se aplican de acuerdo con las diversas opciones de configuración y variables que controlan la evaluación de eventos.

Formatos de replicación

La replicación funciona porque los eventos escritos en el registro binario se leen desde el origen y luego se procesan en la réplica. Los eventos se registran dentro del registro binario en diferentes formatos según el tipo de evento. Los diferentes formatos de replicación utilizados corresponden al formato de registro binario utilizado cuando los eventos se registraron en el registro binario de la fuente. La correlación entre los formatos de registro binario y los términos utilizados durante la replicación son:

  • Cuando se utiliza el registro binario basado en declaraciones, la fuente escribe declaraciones SQL en el registro binario. La replicación de la fuente a la réplica funciona mediante la ejecución de declaraciones SQL en la réplica. Esto se denomina replicación basada en sentencias (que puede abreviarse como SBR ), que corresponde al formato de registro binario basado en sentencias de MySQL.

  • Cuando se usa el registro basado en filas, la fuente escribe eventos en el registro binario que indican cómo se cambian las filas individuales de la tabla. La replicación del origen en la réplica funciona copiando los eventos que representan los cambios en las filas de la tabla en la réplica. Esto se denomina replicación basada en filas (que se puede abreviar como RBR ).

    El registro basado en filas es el método predeterminado.

  • También puede configurar MySQL para utilizar una combinación de registros basados en sentencias y en filas, según cuál sea el más apropiado para que se registre el cambio. A esto se le llama registro de formato mixto . Cuando se usa el registro de formato mixto, se usa un registro basado en declaraciones de forma predeterminada. Dependiendo de ciertas declaraciones, y también del motor de almacenamiento que se utilice, el registro se cambia automáticamente a basado en filas en casos particulares. La replicación que usa el formato mixto se conoce como replicación basada en mixto o replicación de formato mixto

Ventajas y desventajas de la replicación basada en sentencias y basada en filas

Cada formato de registro binario tiene ventajas y desventajas. Para la mayoría de los usuarios, el formato de replicación mixto debería proporcionar la mejor combinación de integridad y rendimiento de los datos. Sin embargo, si desea aprovechar las funciones específicas del formato de replicación basado en instrucciones o en filas al realizar determinadas tareas, puede utilizar la información de esta sección, que proporciona un resumen de sus ventajas y desventajas relativas, para Determine cuál es mejor para sus necesidades.

Ventajas de la replicación basada en declaraciones

  • Tecnología probada.

  • Menos datos escritos en archivos de registro. Cuando las actualizaciones o eliminaciones afectan a muchas filas, se requiere mucho menos espacio de almacenamiento para los archivos de registro. Esto también significa que la toma y la restauración de copias de seguridad se pueden realizar más rápidamente.

  • Los archivos de registro contienen todas las declaraciones que realizaron cambios, por lo que pueden usarse para auditar la base de datos.

Desventajas de la replicación basada en declaraciones

  • Declaraciones que no son seguras para SBR. No todas las declaraciones que modifican datos se pueden replicar mediante la replicación basada en declaraciones. Cualquier comportamiento no determinista es difícil de replicar cuando se usa la replicación basada en declaraciones.

    • Una declaración que depende de una función cargable o programa almacenado que no es determinista, ya que el valor devuelto por dicha función o programa almacenado o depende de factores distintos de los parámetros que se le suministran. (La replicación basada en filas, sin embargo, simplemente replica el valor devuelto por la función o el programa almacenado, por lo que su efecto en las filas de la tabla y los datos es el mismo tanto en la fuente como en la réplica).

    • [DELETE] declaraciones que usan una cláusula LIMIT sin un ORDER BY no son deterministas.

    • Bloquear declaraciones de lectura ([SELECT ... FOR UPDATE] y [SELECT ... FOR SHARE]) que usan opciones NOWAITu SKIP LOCKED.

    • Se deben aplicar funciones cargables deterministas en las réplicas.

    • Las declaraciones que utilizan cualquiera de las siguientes funciones no se pueden replicar correctamente mediante la replicación basada en declaraciones:

      • [LOAD_FILE()]
      • [UUID()]
      • [USER()]
      • [FOUND_ROWS()]
      • [SYSDATE()]
      • [GET_LOCK()]
      • [IS_FREE_LOCK()]
      • [IS_USED_LOCK()]
      • [MASTER_POS_WAIT()]
      • [RAND()]
      • [RELEASE_LOCK()]
      • [SOURCE_POS_WAIT()]
      • [SLEEP()]
      • [VERSION()]

      Sin embargo, todas las demás funciones se replican correctamente mediante la replicación basada en instrucciones, incluidas, [NOW()]

    Las declaraciones que no se pueden replicar correctamente mediante la replicación basada en declaraciones se registran con una advertencia como la que se muestra aquí:

    [Warning] Statement is not safe to log in statement format.

    También se emite una advertencia similar al cliente en tales casos. El cliente puede mostrarlo usando [SHOW WARNINGS].

  • [INSERT ... SELECT] requiere una mayor cantidad de bloqueos a nivel de fila que con la replicación basada en filas.

  • [UPDATE] Las declaraciones que requieren un escaneo de tabla (porque no se usa índice en la cláusula WHERE) deben bloquear un mayor número de filas que con la replicación basada en filas.

  • Para declaraciones complejas, la declaración debe evaluarse y ejecutarse en la réplica antes de que las filas se actualicen o inserten. Con la replicación basada en filas, la réplica solo tiene que modificar las filas afectadas, no ejecutar la declaración completa.

  • Si hay un error en la evaluación de la réplica, especialmente al ejecutar sentencias complejas, la réplica basada en sentencias puede aumentar lentamente el margen de error en las filas afectadas con el tiempo.

  • Las funciones almacenadas se ejecutan con el mismo valor [NOW()] que la declaración de llamada. Sin embargo, esto no ocurre con los procedimientos almacenados.

  • Se deben aplicar funciones cargables deterministas en las réplicas.

  • Las definiciones de tabla deben ser (casi) idénticas en fuente y réplica.

Ventajas de la replicación basada en filas

  • Todos los cambios se pueden replicar. Ésta es la forma más segura de replicación.

    Nota

    Las declaraciones que actualizar la información en el esquema mysql del sistema, como por ejemplo [GRANT], [REVOKE] y la manipulación de los factores desencadenantes, almacenado rutinas (tales como procedimientos almacenados), y vistas, se replican en toda réplicas utilizando la replicación basada en la declaración.

    Para declaraciones como [CREATE TABLE ... SELECT], una declaración CREATE se genera a partir de la definición de la tabla y se replica usando un formato basado en declaraciones, mientras que las inserciones de filas se replican usando un formato basado en filas.

  • Se requieren menos bloqueos de fila en el origen, lo que, por lo tanto, logra una mayor simultaneidad para los siguientes tipos de declaraciones:

    • [INSERT ... SELECT]

    • [INSERT] con AUTO_INCREMENT

    • [UPDATE] o [DELETE] con cláusulas WHERE que no usan claves o no cambian la mayoría de las filas examinadas.

  • Son necesarios Menos bloqueos de registro en la réplica para cualquier [INSERT], [UPDATE] o [DELETE].

Desventajas de la replicación basada en filas

  • RBR puede generar más datos que deben registrarse. Para replicar una declaración DML (como una declaración [UPDATE] o [DELETE]), la replicación basada en declaraciones escribe solo la declaración en el registro binario. Por el contrario, la replicación basada en filas escribe cada fila modificada en el registro binario. Si la declaración cambia muchas filas, la replicación basada en filas puede escribir significativamente más datos en el registro binario; esto es cierto incluso para las declaraciones que se deshacen. Esto también significa que hacer y restaurar una copia de seguridad puede requerir más tiempo. Además, el registro binario se bloquea durante más tiempo para escribir los datos, lo que puede causar problemas de concurrencia. Usar [binlog_row_image=minimal] para reducir considerablemente la desventaja.

  • Las funciones cargables deterministas que generan valores [BLOB] grandes tardan más en replicarse con la replicación basada en filas que con la replicación basada en instrucciones. Esto se debe a que se registra el valor de la columna, en lugar de la declaración que genera los datos.

  • No puede ver en la réplica qué declaraciones se recibieron de la fuente y se ejecutaron. Sin embargo, puede ver qué datos se cambiaron usando [mysqlbinlog].

  • Para las tablas que utilizan el motor [MyISAM] de almacenamiento, se requiere un bloqueo más fuerte en la réplica para las [INSERT] cuando se aplican como eventos basados en filas en el registro binario que cuando se aplican como declaraciones. Esto significa que las inserciones simultáneas en tablas [MyISAM] no son compatibles cuando se usa la replicación basada en filas.

Canales de replicación

En la replicación de múltiples fuentes de MySQL, una réplica abre múltiples canales de replicación, uno para cada servidor de origen. Los canales de replicación representan la ruta de las transacciones que fluyen desde una fuente a la réplica. Cada canal de replicación tiene su propio subproceso de receptor (E / S), uno o más subprocesos de aplicador (SQL) y registro de retransmisión. Cuando las transacciones de una fuente son recibidas por el subproceso receptor de un canal, se agregan al archivo de registro de retransmisión del canal y se pasan a los subprocesos del aplicador del canal. Esto permite que cada canal funcione de forma independiente.

En esta sección se describe cómo se pueden usar los canales en una topología de replicación y el impacto que tienen en la replicación de origen único. Para obtener instrucciones para configurar fuentes y réplicas para la replicación de múltiples fuentes, para iniciar, detener y restablecer réplicas de múltiples fuentes y para monitorear la replicación de múltiples fuentes.

El número máximo de canales que se pueden crear en un servidor de réplica en una topología de réplica de múltiples fuentes es 256. Cada canal de réplica debe tener un nombre único (no vacío). Los códigos de error y los mensajes que se emiten cuando se habilita la replicación de múltiples fuentes especifican el canal que generó el error.

Nota

Cada canal en una réplica de múltiples fuentes debe replicarse desde una fuente diferente. No puede configurar varios canales de replicación desde una única réplica a una única fuente. Esto se debe a que los ID de servidor de las réplicas deben ser únicos en una topología de réplica. La fuente distingue las réplicas solo por sus ID de servidor, no por los nombres de los canales de replicación, por lo que no puede reconocer diferentes canales de replicación de la misma réplica.

Una réplica de múltiples fuentes también se puede configurar como una réplica de subprocesos múltiples, estableciendo la variable del sistema [replica_parallel_workers] (de MySQL 8.0.26) o [slave_parallel_workers]( (antes de MySQL 8.0.26) en un valor mayor que 0. Cuando hace esto en un réplica de múltiples fuentes, cada canal de la réplica tiene el número especificado de subprocesos del aplicador, más un subproceso coordinador para administrarlos. No puede configurar el número de subprocesos del aplicador para canales individuales.

Desde MySQL 8.0, las réplicas de múltiples fuentes se pueden configurar con filtros de replicación en canales de replicación específicos. Los filtros de replicación específicos del canal se pueden usar cuando la misma base de datos o tabla está presente en varias fuentes y solo necesita la réplica para replicarla desde una fuente. Para la replicación basada en GTID, si la misma transacción puede llegar de varias fuentes (como en una topología de diamante), debe asegurarse de que la configuración del filtrado sea la misma en todos los canales.

Para proporcionar compatibilidad con versiones anteriores, el servidor MySQL crea automáticamente al iniciar un canal predeterminado cuyo nombre es la cadena vacía ( ""). Este canal está siempre presente; el usuario no puede crearlo ni destruirlo. Si no se han creado otros canales (con nombres no vacíos), las declaraciones de replicación actúan solo en el canal predeterminado, de modo que todas las declaraciones de replicación de las réplicas más antiguas funcionan como se esperaba.

Repositorios de metadatos de replicación y registro de retransmisión

Un servidor de réplica crea varios repositorios de información para usar en el proceso de réplica:

  • El registro de retransmisión de la réplica , que está escrito por el subproceso de E/S de réplica (receptor), contiene las transacciones leídas del registro binario del servidor de origen de la réplica. Las transacciones en el registro de retransmisión se aplican en la réplica mediante el subproceso SQL de réplica.

  • El repositorio de metadatos de conexión de la réplica contiene información que el subproceso del receptor de réplica necesita para conectarse al servidor de origen de réplica y recuperar transacciones del registro binario de origen. El repositorio de metadatos de conexión se escribe en la tabla mysql.slave_master_info.

  • El repositorio de metadatos del aplicador de la réplica contiene información que el subproceso del aplicador de la réplica necesita para leer y aplicar transacciones del registro de retransmisión de la réplica. El repositorio de metadatos del aplicador se escribe en la tabla mysql.slave_relay_log_info.

El repositorio de metadatos de conexión de la réplica y el repositorio de metadatos del aplicador se conocen colectivamente como repositorios de metadatos de replicación.

Hacer que la replicación sea resistente a paradas inesperadas. Las tablas mysql.slave_master_info y mysql.slave_relay_log_info se crean utilizando el motor de almacenamiento transaccional [InnoDB]. Las actualizaciones de la tabla del repositorio de metadatos del aplicador de la réplica se comprometen junto con las transacciones, lo que significa que la información de progreso de la réplica registrada en ese repositorio siempre es coherente con lo que se ha aplicado a la base de datos, incluso en el caso de una parada inesperada del servidor. Para obtener información sobre la combinación de configuraciones en la réplica que es más resistente a paradas inesperadas.

El registro de retransmisiones

El registro de retransmisión, como el registro binario, consta de un conjunto de archivos numerados que contienen eventos que describen los cambios en la base de datos y un archivo de índice que contiene los nombres de todos los archivos de registro de retransmisión utilizados. La ubicación predeterminada para los archivos de registro de retransmisión es el directorio de datos.

El término " archivo de registro de retransmisión " generalmente denota un archivo individual numerado que contiene eventos de la base de datos. El término " registro de retransmisión " denota colectivamente el conjunto de archivos de registro de retransmisión numerados más el archivo de índice.

Los archivos de registro de retransmisión tienen el mismo formato que los archivos de registro binarios y se pueden leer usando [mysqlbinlog]. Si se utiliza la compresión de transacciones de registro binario (disponible a partir de MySQL 8.0.20), las cargas útiles de transacciones escritas en el registro de retransmisión se comprimen de la misma manera que para el registro binario.

Para el canal de replicación predeterminado, los nombres de los archivos de registro de retransmisión tienen el formato predeterminado , donde es el nombre del host del servidor de réplica y es un número de secuencia. Los archivos de registro de relés sucesivos se crean utilizando números de secuencia sucesivos, comenzando por . Para los canales de replicación no predeterminados, el nombre base predeterminado es , donde es el nombre del canal de replicación registrado en el registro de retransmisión. *host_name*-relay-bin.*nnnnnn*host_namennnnnn000001``*host_name*-relay-bin-*channel*channel

La réplica utiliza un archivo de índice para rastrear los archivos de registro de retransmisión que se utilizan actualmente. El nombre de archivo de índice de registro de retransmisión predeterminado es *host_name*-relay-bin.index para el canal predeterminado y para los canales de replicación no predeterminados. *host_name*-relay-bin-*channel*.index

Si encuentra el problema después de que la replicación ya ha comenzado, una forma de solucionarlo es detener el servidor de réplica, anteponer el contenido del antiguo archivo de índice de registro de retransmisión al nuevo y luego reiniciar la réplica. En un sistema Unix, esto se puede hacer como se muestra aquí:

$> cat new_relay_log_name.index >> old_relay_log_name.index
$> mv old_relay_log_name.index new_relay_log_name.index

Un servidor de réplica crea un nuevo archivo de registro de retransmisión en las siguientes condiciones:

  • Cada vez que se inicia el subproceso de replicación de E/S (receptor).

  • Cuando los registros se vacían (por ejemplo, con [FLUSH LOGS].

  • Cuando el tamaño del archivo de registro de retransmisión actual es demasiado grande, se determina de la siguiente manera:

    • Si el valor de [max_relay_log_size]es mayor que 0, ese es el tamaño máximo del archivo de registro de retransmisión.

    • Si el valor de [max_relay_log_size] es 0, [max_binlog_size] determina el tamaño máximo del archivo de registro de retransmisión.

El subproceso de replicación SQL (aplicador) elimina automáticamente cada archivo de registro de retransmisión después de que ha ejecutado todos los eventos en el archivo y ya no lo necesita. No existe un mecanismo explícito para eliminar los registros de retransmisión porque el subproceso SQL de replicación se encarga de hacerlo. Sin embargo, [FLUSH LOGS] rota los registros de retransmisión, lo que influye en el momento en que el subproceso SQL de replicación los elimina.

Seguridad de la replicación

Soluciones de replicación

La replicación se puede utilizar en muchos entornos diferentes para una variedad de propósitos. Esta sección proporciona notas generales y consejos sobre el uso de la replicación para tipos de soluciones específicos.

Uso de la replicación para copias de seguridad

Para usar la replicación como una solución de respaldo, replique los datos del origen a una réplica y luego haga una copia de respaldo de la réplica. La réplica se puede pausar y cerrar sin afectar la operación de ejecución de la fuente, por lo que puede producir una instantánea efectiva de los datos "en vivo " que, de otro modo, requerirían que la fuente se apague.

La forma de hacer una copia de seguridad de una base de datos depende de su tamaño y de si está haciendo una copia de seguridad solo de los datos o de los datos y el estado de la réplica para poder reconstruir la réplica en caso de falla. Por tanto, hay dos opciones:

  • Si está utilizando la replicación como una solución para permitirle hacer una copia de seguridad de los datos en la fuente, y el tamaño de su base de datos no es demasiado grande, la herramienta [mysqldump].

  • Para bases de datos más grandes, donde [mysqldump] sería poco práctico o ineficiente, puede hacer una copia de seguridad de los archivos de datos sin procesar. El uso de la opción de archivos de datos sin procesar también significa que puede realizar una copia de seguridad de los registros binarios y de retransmisión que hacen posible volver a crear la réplica en caso de que la réplica falle.

Hacer una copia de seguridad de una réplica mediante mysqldump

El uso de [mysqldump] para crear una copia de una base de datos le permite capturar todos los datos de la base de datos en un formato que permite importar la información a otra instancia de MySQL Server. Debido a que el formato de la información son declaraciones SQL, el archivo se puede distribuir y aplicar fácilmente a servidores en ejecución en caso de que necesite acceder a los datos en caso de emergencia. Sin embargo, si el tamaño de su conjunto de datos es muy grande, [mysqldump]

Al usar [mysqldump], debe detener la replicación en la réplica antes de iniciar el proceso de volcado para asegurarse de que el volcado contenga un conjunto de datos coherente:

  1. Detenga la réplica para que no procese solicitudes. Puede detener la replicación por completo en la réplica usando [mysqladmin]

    $> mysqladmin stop-slave

    Alternativamente, puede detener solo el subproceso SQL de replicación para pausar la ejecución del evento:

    $> mysql -e 'STOP SLAVE SQL_THREAD;'
Or from MySQL 8.0.22:
$> mysql -e 'STOP REPLICA SQL_THREAD;'

    Esto permite que la réplica continúe recibiendo eventos de cambio de datos del registro binario de la fuente y los almacene en los registros de retransmisión utilizando el subproceso del receptor de replicación, pero evita que la réplica ejecute estos eventos y cambie sus datos. En entornos de replicación ocupados, permitir que el subproceso del receptor de replicación se ejecute durante la copia de seguridad puede acelerar el proceso de actualización cuando reinicia el subproceso del aplicador de replicación.

  2. Ejecute [mysqldump] para volcar sus bases de datos. Puede volcar todas las bases de datos o seleccionar las bases de datos que desee volcar. Por ejemplo, para volcar todas las bases de datos:

    $> mysqldump --all-databases > fulldb.dump

  3. Una vez que se haya completado el volcado, comience la replicación nuevamente:

    $> mysqladmin start-slave

En el ejemplo anterior, es posible que desee agregar credenciales de inicio de sesión (nombre de usuario, contraseña) a los comandos y agrupar el proceso en un script que pueda ejecutar automáticamente todos los días.

Si usa este enfoque, asegúrese de monitorear el proceso de replicación para asegurarse de que el tiempo necesario para ejecutar la copia de seguridad no afecte la capacidad de la réplica para mantenerse al día con los eventos de la fuente.

17.4.1.2 Copia de seguridad de datos sin procesar desde una réplica

Para garantizar la integridad de los archivos que se copian, la copia de seguridad de los archivos de datos sin procesar en su réplica de MySQL debe realizarse mientras su servidor de réplica está apagado. Si el servidor MySQL aún se está ejecutando, es posible que las tareas en segundo plano sigan actualizando los archivos de la base de datos, particularmente aquellas que involucran motores de almacenamiento con procesos en segundo plano como InnoDB. Con InnoDB, estos problemas deben resolverse durante la recuperación de fallos, pero dado que el servidor de réplica se puede apagar durante el proceso de copia de seguridad sin afectar la ejecución de la fuente, tiene sentido aprovechar esta capacidad.

Para apagar el servidor y hacer una copia de seguridad de los archivos:

  1. Apague la réplica del servidor MySQL:

    $> mysqladmin shutdown

  2. Copie los archivos de datos. Puede utilizar cualquier utilidad de copia o archivo adecuada, incluidos cp , tar o WinZip . Por ejemplo, suponiendo que el directorio de datos se encuentra debajo del directorio actual, puede archivar el directorio completo de la siguiente manera:

    $> tar cf /tmp/dbbackup.tar ./data

  3. Inicie el servidor MySQL nuevamente. Bajo Unix:

    $> mysqld_safe &

    Bajo Windows:

    C:\> "C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqld"

Normalmente, debe realizar una copia de seguridad de todo el directorio de datos para la réplica del servidor MySQL. Si desea poder restaurar los datos y operar como una réplica (por ejemplo, en caso de falla de la réplica), además de los datos, debe tener el repositorio de metadatos de conexión de la réplica y el repositorio de metadatos del aplicador, y los archivos de registro de retransmisión. Estos elementos son necesarios para reanudar la replicación después de restaurar los datos de la réplica. Suponiendo que se hayan utilizado tablas para el repositorio de metadatos de conexión de la réplica y el repositorio de metadatos del [aplicador] que es el valor predeterminado en MySQL 8.0, estas tablas se respaldan junto con el directorio de datos. Si se han utilizado archivos para los repositorios, lo que está en desuso, debe realizar una copia de seguridad de estos por separado. Los archivos de registro de retransmisión deben respaldarse por separado si se han colocado en una ubicación diferente al directorio de datos.

Si pierde los registros de retransmisión pero aún tiene el archivo relay-log.info, puede verificarlo para determinar hasta qué punto se ha ejecutado el subproceso SQL de replicación en los registros binarios de la fuente. Luego puede usar la [CHANGE REPLICATION SOURCE TO] (de MySQL 8.0.23) o [CHANGE MASTER TO] (antes de MySQL 8.0.23) con las opciones SOURCE_LOG_FILE| MASTER_LOG_FILEy SOURCE_LOG_POS| MASTER_LOG_POS para decirle a la réplica que vuelva a leer los registros binarios desde ese punto. Esto requiere que los registros binarios sigan existiendo en el servidor de origen.