Tabla de contenido
Prefacio
El siguiente contenido está basado en documentos oficiales de MySQL5.7
Replicación de Mysql
Puede copiar datos de un servidor de base de datos MySQL (fuente) a uno o más servidores de base de datos MySQL (réplicas). De forma predeterminada, la replicación es asincrónica y funciona mejor; la réplica no necesita estar conectada permanentemente para recibir actualizaciones de la fuente. Dependiendo de la configuración, puede copiar todas las bases de datos en la base de datos, bases de datos seleccionadas e incluso tablas seleccionadas.
Las ventajas de la replicación en MySQL incluyen:
- Solución de escalamiento horizontal: distribuya la carga entre varias copias para mejorar el rendimiento. En este entorno, todas las escrituras y actualizaciones deben realizarse en el servidor de origen de la replicación (servidor primario). Sin embargo, la lectura puede ocurrir en una o más réplicas (servidores esclavos). Este modelo puede mejorar el rendimiento de escritura (porque la fuente está dedicada a las actualizaciones), mientras que puede aumentar significativamente las velocidades de lectura en más y más réplicas.
- Seguridad de los datos: debido a que los datos se han copiado en la copia y la copia puede suspender el proceso de copia, los servicios de respaldo se pueden ejecutar en la copia sin destruir los datos de origen correspondientes.
- Análisis: se pueden crear datos en tiempo real en la fuente y el análisis de la información se puede realizar en la copia sin afectar el rendimiento de la fuente.
- Distribución remota de datos: puede usar la replicación para crear copias locales de datos para que las utilicen sitios remotos sin tener que acceder permanentemente a la fuente.
MySQL 5.7 admite diferentes métodos de replicación. Los métodos tradicionales se basan en copiar eventos en el registro binario de origen y requieren que los archivos de registro y sus ubicaciones estén sincronizados entre el origen y la copia. Basado en Global Transaction Identifier (GTID) es un método más nuevo, es transaccional, por lo que no es necesario tratar con archivos de registro o ubicaciones en estos archivos, lo que simplifica en gran medida muchas tareas de replicación comunes. El uso de GTID para la replicación puede garantizar la coherencia entre la fuente y la réplica, siempre que todas las transacciones comprometidas en la fuente también se hayan aplicado a 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 y uno o más servidores actúan como réplicas. Esto es contrario a la función de replicación sincrónica de NDB Cluster. En MySQL 5.7, además de la replicación asincrónica incorporada, también admite la replicación semisincrónica. Para la replicación semisincrónica, antes de regresar a la sesión que realizó la transacción, la confirmación se realiza en el bloque de origen hasta que al menos una réplica confirme que ha recibido y registrado el evento de transacción; MySQL 5.7 también admite la replicación retrasada para que la réplica sea después del tiempo especificado por la fuente Haga una copia. Para escenarios que requieren replicación síncrona, use NDB Cluster
Hay dos tipos principales de formatos de replicación: replicación basada en instrucciones (SBR), que replica la instrucción SQL completa; y replicación basada en filas (RBR), que solo replica las filas cambiadas. También puede utilizar el tercer tipo de replicación híbrida híbrida (MBR).
Puede usar la replicación para resolver muchos problemas diferentes, incluido el rendimiento, el respaldo de copias de seguridad de diferentes bases de datos y como parte de una solución más grande para mitigar fallas del sistema.
Replicación basada en la ubicación del archivo de registro binario
Esta sección presenta la replicación entre servidores MySQL basada en el método de ubicación del archivo de registro binario. En este método de replicación, la instancia de origen MySQL (los cambios en la base de datos se originan en esta instancia) escribe actualizaciones y cambios como "eventos" en el registro binario. La información del registro binario se almacena en diferentes formatos de registro de acuerdo con los cambios registrados en la base de datos. Configure la réplica para leer el registro binario de la fuente y ejecutar eventos en el registro binario en la base de datos local de la réplica.
Cada copia recibe una copia de todo el contenido del registro binario. La copia es responsable de determinar 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 copia. Si es necesario, la réplica se puede configurar para procesar solo eventos que se aplican a una base de datos o tabla específica.
Cada copia registra las coordenadas del registro binario: el nombre del archivo leído y procesado desde la fuente y la ubicación del archivo en el archivo. Esto significa que se pueden conectar varias copias a la fuente y ejecutar diferentes partes del mismo registro binario. Dado que la réplica controla este proceso, es posible conectar y desconectar una única réplica del servidor sin afectar el funcionamiento de la fuente. De manera similar, dado que cada copia registra la posición actual en el registro binario, la copia se puede desconectar, volver a conectar y luego reanudar el procesamiento.
Se debe configurar un ID único para el origen y cada réplica (utilizando la variable de sistema server_id). Además, la información sobre el nombre del host de origen, el nombre del archivo de registro y la ubicación en el archivo debe configurarse para cada copia. Puede usar la instrucción CHANGE MASTER TO en la copia para controlar estos detalles en la sesión de MySQL.
Nota: La fuente de la copia representa la base de datos maestra (maestra) y la copia representa la base de datos esclava (esclava)
Copiar configuración relacionada
A continuación se presentará la configuración básica basada en la replicación de archivos de registro binario, después de leerla, podrá conocerla y configurarla claramente.
Establecer la configuración de la fuente de replicación
Para configurar la fuente para que utilice la replicación según la ubicación del archivo de registro binario, debe asegurarse de que el registro binario esté habilitado y establecer una ID de servidor única.
Cada servidor de la topología de replicación debe configurarse con un ID de servidor exclusivo, que puede especificar mediante la variable de sistema server_id. Esta ID de servidor se utiliza para identificar cada servidor en la topología de replicación y debe ser un número entero positivo entre 1 y (2 32) -1. Puede cambiar dinámicamente el valor de server_id emitiendo la siguiente declaración:
SET GLOBAL server_id = 2;
Cuando el ID de servidor predeterminado es 0, la fuente rechaza cualquier conexión desde la réplica y la réplica se niega a conectarse a la fuente, por lo que este valor no se puede usar en la topología de replicación. Además de esto, puede elegir cómo organizar y seleccionar las ID de servidor, siempre que cada ID de servidor sea diferente de cualquier otra ID de servidor utilizada por cualquier otro servidor en la topología de replicación. Tenga en cuenta que si previamente estableció un valor de 0 para la ID del servidor, debe reiniciar el servidor para inicializar la fuente con la nueva ID de servidor distinta de cero. De lo contrario, no es necesario reiniciar el servidor a menos que necesite habilitar el registro binario o realizar otros cambios de configuración que requieran reiniciar.
El registro binario debe estar habilitado en la fuente porque el registro binario es la base para copiar los cambios desde la fuente a su copia. Si el registro binario no está habilitado en el origen mediante la opción log-bin, la replicación no puede tener lugar. Para habilitar el registro binario en un servidor que no se ha habilitado para el registro binario, debe reiniciar el servidor. En este caso, cierre el servidor MySQL y edite el archivo my.cnf o my.ini. En la sección del archivo de configuración [mysqld], agregue las opciones log-bin y server-id. Si estas opciones ya existen pero se han comentado, descomente estas opciones y realice los cambios necesarios. Por ejemplo, para usar el prefijo del nombre del archivo de registro para habilitar el registro binario mysql-bin y configurar el ID del servidor en 1, use las siguientes líneas:
[mysqld]
log-bin=mysql-bin
server-id=1
Después de realizar los cambios, reinicie el servidor.
Nota Las
siguientes opciones afectan este proceso:
Para obtener la máxima durabilidad y consistencia en la configuración de replicación donde se usa InnoDB con transacciones, debe usarse en el archivo fuente
innodb_flush_log_at_trx_commit=1
和
sync_binlog=1
Asegúrese de que la variable de sistema skip_networking no esté habilitada en su fuente. Si esta variable está habilitada, la conexión de red se deshabilitará, la copia no se puede comunicar con la fuente y la copia fallará.
Crear un usuario para la replicación
Cada réplica necesita usar un nombre de usuario y una contraseña de MySQL para conectarse a la fuente, por lo que debe haber una cuenta de usuario en la fuente y la réplica se puede usar para conectarse. Al configurar una copia, el nombre de usuario se especifica mediante la opción CAMBIAR MAESTRO A en el comando MASTER_USER. Siempre que a la cuenta se le hayan otorgado privilegios de REPLICATION SLAVE, se puede utilizar cualquier cuenta para esta operación. Puede optar por crear una cuenta diferente para cada copia o utilizar la misma cuenta para cada copia para conectarse a la fuente.
Aunque no es necesario crear una cuenta específicamente para la replicación, se debe tener en cuenta que el nombre de usuario y la contraseña de la replicación se almacenan en texto sin formato en el repositorio de metadatos de replicación. Por lo tanto, es posible que desee crear una cuenta separada que solo tenga privilegios para el proceso de copia para minimizar la posibilidad de dañar otras cuentas.
Para crear una nueva cuenta, use el comando CREAR USUARIO. Para otorgar a la cuenta los privilegios necesarios para la replicación, utilice la siguiente declaración GRANT. Si la cuenta se crea solo con fines de replicación, la cuenta solo necesita el privilegio REPLICATION SLAVE. Por ejemplo, para configurar un nuevo usuario, responda que el usuario puede replicar conexiones desde cualquier host en el dominio example.com, emita la siguiente declaración en la fuente:
mysql> CREATE USER 'repl'@'%.example.com' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.example.com';
Obtenga las coordenadas del registro binario de la fuente de copia
Para configurar la copia para iniciar el proceso de copia en el punto correcto, debe escribir las coordenadas actuales de la fuente en su registro binario.
Si planea cerrar la fuente para crear una instantánea de datos, puede optar por omitir este proceso y, en su lugar, almacenar una copia del archivo de índice de registro binario con la instantánea de datos. En este caso, la fuente creará un nuevo archivo de registro binario al reiniciar. Por lo tanto, las coordenadas del registro binario de la fuente donde la copia debe comenzar a copiarse es el inicio del nuevo archivo, que es el siguiente archivo de registro binario en la fuente, después del archivo que aparece en el archivo de índice de registro binario copiado.
Para obtener las coordenadas del registro binario de la fuente, siga estos pasos:
1. Conéctese a la fuente utilizando el cliente de línea de comandos para iniciar una sesión en la fuente, y vacíe todas las tablas y evite las sentencias de escritura ejecutando la siguiente sentencia FLUSH TABLES WITH READ LOCK:
mysql> FLUSH TABLES WITH READ LOCK;
Nota: FLUSH TABLES WITH READ LOCK evitará la operación COMMIT de la tabla, es decir, evitará el envío de operaciones de escritura
2. En otra sesión en la fuente, use la instrucción SHOW MASTER STATUS para determinar el nombre y la ubicació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 Archivo muestra el nombre del archivo de registro y la columna Posición muestra la posición en el archivo. En este ejemplo, el archivo de registro binario es mysql-bin.000003 y la ubicación es 73. Registre estos valores. Los necesitará más adelante cuando configure la copia. Representan coordenadas copiadas desde las que la copia debe procesar nuevas actualizaciones en la fuente.
Si la fuente se ha estado ejecutando antes y el registro binario no está habilitado, el nombre del archivo de registro y el valor de ubicación que muestra SHOW MASTER STATUS o mysqldump --master-data están vacíos. En este caso, el valor que debe usarse al especificar el archivo de registro de origen y la ubicación más adelante es una cadena vacía ('')
Ahora tiene la información para hacer que la copia comience a leerse y copiarse desde el registro binario en la ubicación correcta.
#Copy settings
Las siguientes secciones describen cómo configurar una copia.
1. Cada copia debe tener un ID de servidor exclusivo especificado por la variable de sistema server_id. Si desea configurar varias réplicas, cada réplica debe tener un valor de server_id único, que debe ser diferente de la réplica de origen y cualquier otra réplica. Si no se ha establecido el ID de servidor del servidor de réplica, o el valor actual entra en conflicto con el valor que seleccionó para el servidor de origen u otros servidores de réplica, debe cambiarlo. El valor predeterminado de server_id es 0, lo que significa que la réplica se niega a conectarse a la fuente.
Puede cambiar dinámicamente el valor de server_id emitiendo la siguiente declaración:
SET GLOBAL server_id = 21;
Si server_id ha establecido previamente el valor predeterminado en 0, el servidor debe reiniciarse para inicializar la réplica con el nuevo ID de servidor distinto de cero. De lo contrario, no es necesario que reinicie el servidor cuando cambie el ID del servidor a menos que realice otros cambios de configuración que lo requieran. Por ejemplo, si el registro binario está deshabilitado en el servidor y desea habilitar el registro binario en la copia, debe reiniciar el servidor para habilitar esta función.
Si desea apagar el servidor de réplica, puede editar la sección [mysqld] del archivo de configuración para especificar una ID de servidor única. P.ej:
[mysqld]
server-id=21
La copia se puede replicar sin habilitar el registro binario. Sin embargo, los registros binarios de la copia se pueden utilizar para la copia de seguridad de datos y la recuperación de fallos. Las réplicas con el registro binario habilitado también se pueden utilizar como parte de topologías de réplica más complejas. Si desea habilitar el registro binario en la réplica, configure la opción log-bin en la sección [mysqld] del archivo de configuración. El servidor debe reiniciarse para iniciar el registro binario en un servidor que no se ha utilizado antes.
2. Establezca la configuración de origen en el servidor de réplica.
Para configurar la réplica para que se comunique con la fuente de réplica, configure la información de conexión necesaria para la réplica. Para hacer esto, ejecute la siguiente declaración en la copia, reemplazando el valor de la opción con el valor real relacionado con el 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;
3. Inicie el hilo de replicación:
mysql> START SLAVE;
Después de realizar este proceso, el servidor de réplica se conectará a la fuente y copiará la instantánea tomada por usted mismo en todas las actualizaciones que ocurrieron en la fuente.