Lectura recomendada:
Modelo de arquitectura principal de replicación maestro-esclavo de MySQL
Podemos replicar un servidor MySQL basado en Binlog, o múltiples, dependiendo de las funciones que queramos implementar. La arquitectura del sistema principal tiene los siguientes métodos:
1. Un maestro, un esclavo / un maestro, varios esclavos
Las arquitecturas maestro-esclavo más comunes son un maestro-uno-esclavo y un maestro-esclavo múltiple. Generalmente, esta arquitectura se puede utilizar para lograr la configuración maestro-esclavo o la separación de lectura y escritura.
Si se trata de un modo de un maestro, múltiples esclavos, cuando el número de esclavos aumenta a un cierto número, la carga del esclavo en el maestro y el ancho de banda de la red se convertirán en un problema grave.
2. Varios amos y un esclavo
MySQL 5.7 comenzó a admitir un modo multimaestro-uno-esclavo, haciendo copias de seguridad de datos de varias bases de datos en una base de datos para su almacenamiento.
3. Replicación de maestro dual
En teoría, es lo mismo que el maestro-esclavo, pero los dos servidores MySQL actúan como esclavos el uno del otro, y cualquier cambio en cualquiera de los lados copiará los datos del otro en su propia base de datos. El maestro dual es adecuado para escenarios comerciales donde la presión de escritura es relativamente alta, o donde el DBA necesita cambiar entre maestro y esclavo para mantenimiento La arquitectura de maestro dual evita el problema de crear bibliotecas esclavas repetidamente. (El proceso de la conexión de autorización mutua maestro-esclavo, leer el registro binlog de la otra parte y actualizar a la base de datos local; siempre que cambien los datos de la otra parte, usted cambiará en consecuencia)
4. Replicación en cascada
En el modo cascada, debido a que hay muchos nodos esclavos involucrados, si todos están conectados al maestro, la presión sobre el servidor maestro definitivamente no es pequeña. Por lo tanto, algunos nodos esclavos están conectados a los nodos esclavos del nivel superior. Esto alivia la presión sobre el servidor principal.
La replicación en cascada resuelve la presión de la replicación de múltiples bibliotecas esclavas en la biblioteca maestra en el escenario de un maestro y múltiples esclavos El inconveniente es que el retardo de sincronización de datos es relativamente grande.
Principio de replicación maestro-esclavo de MySQL
La replicación maestro-esclavo de MySQL involucra tres subprocesos:
Un hilo en el nodo principal:log dump thread
Se generarán dos subprocesos a partir de la biblioteca: un subproceso de E / S y un subproceso de SQL
Como se muestra abajo:
La biblioteca principal generará un subproceso de volcado de registros para transferir datos de Binlog al subproceso de E / S de la biblioteca esclava.
El subproceso de E / S de la biblioteca esclava solicitará el Binlog de la biblioteca principal y escribirá el Binlog obtenido en el archivo de registro de retransmisión local (registro de retransmisión).
El subproceso SQL leerá el registro en el archivo de registro de retransmisión y lo analizará en declaraciones SQL para ejecutar una por una.
Subproceso de volcado de registro del nodo principal
Cuando el nodo esclavo se conecta al nodo maestro, el nodo maestro creará un hilo de volcado de registro para que envíe y lea el contenido de Binlog. Al leer la operación en Binlog, el hilo de volcado de registros bloqueará el Binlog en el nodo maestro; el bloqueo se liberará antes de que se complete la lectura y se envíe al nodo esclavo. El nodo maestro creará un subproceso de volcado de registro para cada uno de sus nodos esclavos .
Hilo de E / S del nodo esclavo
Después de ejecutar el start slavecomando en el nodo esclavo , el nodo esclavo creará un subproceso de E / S para conectarse al nodo maestro y solicitará el Binlog actualizado en la biblioteca maestra. Una vez que el subproceso de E / S recibe la actualización enviada por el proceso de volcado de registro del nodo maestro, la guarda en el registro de retransmisión local (registro de retransmisión).
registro de relé
Aquí hay un nuevo concepto de registro. Cuando MySQL realiza la replicación maestro-maestro o la replicación maestro-esclavo, se generará un registro de retransmisión correspondiente en el servidor que se replicará.
¿Cómo se genera el registro de retransmisión?
El subproceso de E / S del servidor esclavo lee el registro de Binlog del servidor maestro, analiza los distintos eventos y los registra en el archivo local del servidor esclavo. Este archivo se denomina registro de retransmisión. Luego, el hilo SQL leerá el contenido del registro de retransmisión y lo aplicará al servidor esclavo, de modo que los datos del servidor esclavo y el servidor maestro sean consistentes. El registro del relé actúa como un búfer para que el maestro no tenga que esperar a que se complete la ejecución del esclavo antes de enviar el siguiente evento.
Consulta de parámetros relacionados con el registro de retransmisión:
mysql> show variables like '%relay%';
+---------------------------+------------------------------------------------------------+
| Variable_name | Value |
+---------------------------+------------------------------------------------------------+
| max_relay_log_size | 0 |
| relay_log | yangyuedeMacBook-Pro-relay-bin |
| relay_log_basename | /usr/local/mysql/data/yangyuedeMacBook-Pro-relay-bin |
| relay_log_index | /usr/local/mysql/data/yangyuedeMacBook-Pro-relay-bin.index |
| relay_log_info_file | relay-log.info |
| relay_log_info_repository | TABLE |
| relay_log_purge | ON |
| relay_log_recovery | OFF |
| relay_log_space_limit | 0 |
| sync_relay_log | 10000 |
| sync_relay_log_info | 10000 |
+---------------------------+------------------------------------------------------------+
11 rows in set (0.03 sec)
max_relay_log_size
Marque el registro de relé máximo permitido. Si el valor es 0, el valor predeterminado es max_binlog_size (1G); si no es 0, entonces max_relay_log_size es el tamaño máximo de archivo de relay_log.
relay_log_purge
Ya sea para borrar automáticamente el registro de retransmisión cuando ya no sea necesario. El valor predeterminado es 1 (habilitado).
relay_log_recovery
Cuando el esclavo se desconecta de la biblioteca, si el registro del relé está dañado, lo que hace que parte del registro del relé no se procese, todos los registros del relé no ejecutados se descartan automáticamente y el registro se vuelve a obtener del maestro, lo que garantiza la integridad del registro del relé. Esta función está desactivada de forma predeterminada.Cuando el valor de relay_log_recovery se establece en 1, la función se puede activar en la biblioteca esclava. Se recomienda activarla.
relay_log_space_limit
Para evitar que los registros de relé llenen el disco, establezca aquí el límite máximo de registros de relé. Sin embargo, esta configuración tiene la situación de que la biblioteca principal se bloquea y el registro de retransmisión de la biblioteca secundaria está incompleto. No es un último recurso y no se recomienda.
sync_relay_log
Este parámetro tiene el sync_binlogmismo efecto que en Binlog . Cuando se establece en 1, cada vez que el subproceso de E / S del esclavo recibe el registro de Binlog enviado por el maestro, debe escribirse en el búfer del sistema y luego vaciarse en el registro de relé. Esta es la forma más segura, porque en el bloqueo En este momento, perderá como máximo una transacción, pero provocará una gran cantidad de E / S de disco.
Cuando se establece en 0, no se descarga inmediatamente en el registro de retransmisión, pero el sistema operativo decide cuándo escribir. Aunque la seguridad se reduce, se reducen muchas operaciones de E / S del disco. Este valor es 0 por defecto y se puede modificar dinámicamente Se recomienda utilizar el valor por defecto.
sync_relay_log_info
Cuando se establece en 1, cada vez que el subproceso de E / S del esclavo recibe el registro de Binlog enviado por el maestro, debe escribirse en el búfer del sistema y luego vaciarse en relay-log.info Esta es la forma más segura porque está fallando. En este momento, perderá como máximo una transacción, pero provocará una gran cantidad de E / S de disco. Cuando se establece en 0, no se actualiza inmediatamente en relay-log.info, pero el sistema operativo decide cuándo escribir. Aunque la seguridad se reduce, se reducen muchas operaciones de E / S del disco. Este valor es 0 por defecto y se puede modificar dinámicamente Se recomienda utilizar el valor por defecto.
Subproceso SQL del nodo esclavo
El hilo SQL es responsable de leer el contenido en el registro de retransmisión, analizarlo en operaciones específicas y ejecutarlas, y en última instancia, garantizar la coherencia de los datos maestro-esclavo.
Para cada conexión maestro-esclavo, estos tres procesos deben completarse. Cuando el nodo maestro tiene varios nodos esclavos, el nodo maestro creará un proceso de volcado de registro para cada nodo esclavo actualmente conectado, y cada nodo esclavo tiene su propio proceso de E / S, proceso SQL.
El nodo esclavo utiliza dos subprocesos para extraer actualizaciones y ejecutarlas desde la biblioteca principal en tareas independientes, de modo que el rendimiento de las operaciones de lectura no se reduzca cuando se ejecute la tarea de sincronización de datos. Por ejemplo, si el nodo esclavo no se está ejecutando, el proceso de E / S puede obtener rápidamente actualizaciones del nodo maestro, aunque el proceso SQL aún no se haya ejecutado. Si el servicio del nodo esclavo se detiene antes de que se ejecute el proceso SQL, al menos el proceso de E / S ha extraído los últimos cambios del nodo maestro y los ha guardado en el registro de retransmisión local. Cuando el servicio vuelve a estar activo, la sincronización de datos puede completarse.
Para implementar la replicación, primero debe habilitar la función Binlog en el lado Master, de lo contrario no será posible.
Porque todo el proceso de replicación consiste en que el esclavo obtiene el registro del maestro y luego ejecuta las diversas operaciones registradas en el registro en orden completo sobre sí mismo. Como se muestra abajo:
El proceso básico de copiar
- Ejecute el
sart slavecomando en el nodo esclavo para activar el conmutador de replicación maestro-esclavo e iniciar la replicación maestro-esclavo. El proceso de E / S en el nodo esclavo se conecta al nodo maestro y solicita el contenido del registro desde la ubicación especificada del archivo de registro especificado (o el registro desde el principio). - Una vez que el nodo maestro recibe la solicitud de E / S del nodo esclavo, el proceso de E / S (log Dump Thread) responsable de la replicación lee la información de registro después de la ubicación de registro especificada de acuerdo con la información de la solicitud y la devuelve al nodo esclavo. Además de la información contenida en el registro, la información devuelta también incluye el archivo Binlog y la posición de Binlog de la información devuelta esta vez (la siguiente posición de lectura de datos de Binlog).
- Una vez que el proceso de E / S del nodo recibe el contenido del registro, el archivo de registro y el punto de ubicación enviado por el nodo principal, el contenido del registro recibido se actualiza al final del archivo de registro de retransmisión (Mysql-relay-bin.xxx) de la máquina. , Y guarde el nombre y la ubicación del
master-infoarchivo Binlog leído en el archivo, de modo que la próxima vez que lo lea, pueda decirle claramente al Maestro: "¿En qué ubicación del Binlog necesito iniciar el contenido del registro, por favor envíeme" . - Después de que el hilo SQL del esclavo detecta que el nuevo contenido se agrega al registro de retransmisión, analizará el contenido del registro de retransmisión en declaraciones SQL que se pueden ejecutar, y luego las ejecutará en el orden analizado en esta base de datos, y
relay log.inforegistrará el registro de retransmisión de la aplicación actual en ella. El nombre del archivo y el punto de ubicación.
MySQL se basa en la introducción del modo de replicación maestro-esclavo de Binlog
La replicación maestro-esclavo de MySQL es asíncrona de forma predeterminada . Las operaciones de adición, eliminación y modificación de MySQL se registrarán en Binlog.Cuando el nodo esclavo se conecta al maestro, obtendrá activamente el último archivo Binlog del maestro. Y almacene el Binlog en el registro de retransmisión local y luego ejecute el contenido actualizado del registro de retransmisión.
Modo asíncrono (modo asíncrono)
El modo asincrónico se muestra a continuación:
En este modo, el nodo maestro no enviará datos de forma activa a los nodos esclavos. La biblioteca maestra devolverá inmediatamente los resultados al cliente después de ejecutar la transacción enviada por el cliente, y no le importa si la biblioteca esclava la ha recibido y procesado. Habrá un problema. Si el nodo maestro falla, es posible que las transacciones que se han comprometido en el nodo maestro no se transmitan a los nodos esclavos. Si en este momento, la promoción forzosa se promoverá al nodo maestro, lo que puede hacer que se pierdan los datos del nuevo nodo maestro. completar.
Modo semisincronización (semisincronización)
Entre la replicación asincrónica y la replicación completamente sincrónica, la biblioteca principal no regresa al cliente inmediatamente después de ejecutar la transacción enviada por el cliente, sino que espera al menos una recibida de la biblioteca y escrita en el registro de retransmisión antes de devolver un mensaje de éxito al cliente. (Solo puede garantizar que el Binlog de la biblioteca principal se transmita a al menos un nodo esclavo), de lo contrario, debe esperar hasta el período de tiempo de espera y luego cambiar al modo asíncrono antes de enviar.
En comparación con la replicación asincrónica, la replicación semisincrónica mejora la seguridad de los datos y garantiza que los datos se puedan respaldar correctamente en la base de datos esclava hasta cierto punto. Al mismo tiempo, también causa un cierto grado de retraso, pero es menor que el modo síncrono completo y tiene el menor retraso. Es un tiempo de ida y vuelta de TCP / IP. Por lo tanto, la replicación semisincrónica se utiliza mejor en redes de baja latencia.
El modo semisincrónico no está integrado en MySQL. A partir de MySQL 5.5, el maestro y el esclavo deben instalar complementos para habilitar el modo semisincrónico.
Modo de sincronización completa
Se refiere a cuando la biblioteca principal ha completado una transacción, y luego todas las bibliotecas esclavas han copiado la transacción y la han ejecutado con éxito antes de devolver un mensaje de éxito al cliente. Debido a que debe esperar a que todos los esclavos completen la transacción antes de devolver un mensaje de éxito, el rendimiento de la replicación sincrónica completa inevitablemente se verá gravemente afectado.
Combate de replicación de Binlog
Configurar my.cnf
[mysqld]
log-bin
server-id
gtid_mode=off #禁掉 gtid
Agregue usuarios de replicación maestro-esclavo:
grant replication slave on *.* to 'repl'@'%' identified by 'gtidUser';
flush privileges;
Luego agregamos una biblioteca esclava.
Luego usamos la línea de comando para cargar el Binlog de la biblioteca principal a la biblioteca esclava, donde puede establecer el archivo binlog especificado y el valor de desplazamiento. Ejecute los siguientes comandos en la biblioteca esclava:
mysql>change master to
master_host='192.168.199.117',
master_user='slave',
master_port=7000,
master_password='slavepass',
master_log_file='mysql-bin.000008',
master_log_pos=0;
mysql>start slave;
mysql>show slave status\G;
Si ocurre un error de código durante el proceso de copia, la persona determina si debe omitir el error y continuar la ejecución de acuerdo con el registro de errores:
mysql>stop slave;
mysql>set global sql_slave_skip_counter=1;
Problemas que pueden surgir en la replicación maestro-esclavo
Retardo de sincronización esclavo
Debido a que el lado esclavo implementa el análisis y el almacenamiento de datos a través de un solo subproceso de E / S; y el Binlog en el lado maestro escribe en orden porque es muy eficiente.Cuando el TPS de la biblioteca principal es muy alto, la eficiencia de escritura del lado maestro debe ser mayor que la del lado esclavo. Leer eficiencia, en este momento hay un problema de retraso de sincronización.
La sincronización de subprocesos de E / S se basa en bibliotecas, es decir, la sincronización de varias bibliotecas abrirá varios subprocesos de E / S.
Puede show slave status verificar Seconds_Behind_Master el valor del comando para ver si hay un retraso de sincronización. Este valor representa el tiempo del retraso de sincronización maestro-esclavo. Cuanto mayor sea el valor, más grave será el retraso. Un valor de 0 es normal. Un valor positivo indica que se ha producido un retraso. Cuanto mayor sea el número, más se retrasará la biblioteca esclava con respecto a la biblioteca maestra.
El método de replicación basado en Binlog debe tener este problema. El funcionario de MySQL también se dio cuenta de que un solo subproceso no es tan fuerte como el subproceso múltiple, por lo que en la versión 5.7 de MySQL, se introdujo la replicación paralela basada en el envío de grupo (oficialmente llamado esclavos multiproceso mejorados o MTS). , Configuración de parámetros:
slave_parallel_workers>0 Sí, y global.slave_parallel_type＝‘LOGICAL_CLOCK’,
Puede admitir un esquema (biblioteca), slave_parallel_workersun hilo de trabajo ejecuta simultáneamente la transacción enviada por la biblioteca principal en el registro de retransmisión.
Su idea central:
Todas las transacciones enviadas por un grupo se pueden reproducir en paralelo (con la confirmación del grupo de registros binarios);
La misma última transacción comprometida (número de secuencia diferente) en el registro de retransmisión de la máquina esclava se puede ejecutar al mismo tiempo. Entre ellos, la variable slave-parallel-type puede tener dos valores:
- Valor predeterminado de BASE DE DATOS, copia paralela basada en la biblioteca
- LOGICAL_CLOCK, replicación paralela basada en envío de grupo
Es muy simple habilitar MTS en MySQL 5.7. Solo necesita configurar lo siguiente en el archivo my.cnf de la base de datos esclava:
# slave
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=8 #一般建议设置4-8，太多的线程会增加线程之间的同步开销
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON
Por supuesto, la solución de replicación paralela que ofrece el subproceso múltiple también tiene muchas dificultades de implementación. Por ejemplo, las transacciones se ejecutan de manera ordenada. Si se realiza la reproducción en paralelo, habrá problemas con el desorden de los datos de ejecución. Estos temas no se explican en esta sección y todos los interesados pueden seguir estudiándolos.
Una nueva generación de modo de replicación maestro-esclavo-modo de replicación GTID
En la replicación tradicional, cuando ocurre una falla, se requiere un conmutador maestro-esclavo. Es necesario encontrar la información de ubicación y binlog. Después de restaurar los datos, el nodo maestro se dirige al nuevo nodo maestro. En MySQL 5.6, se proporciona una nueva idea de recuperación de datos. Solo necesita conocer la IP, el puerto y la contraseña de la cuenta del nodo maestro. Debido a que la replicación es automática, MySQL encontrará automáticamente un punto de sincronización a través del mecanismo interno GTID .
La replicación basada en GTID es un nuevo método de replicación agregado después de MySQL 5.6.5.
GTID (identificador de transacción global) es el ID de transacción global. Una transacción corresponde a un GTID, que asegura que cada transacción enviada en la biblioteca principal tenga un ID único en el clúster.
Principio de replicación de GTID
En la replicación original basada en registros, la base de datos esclava necesita informar a la base de datos maestra desde qué compensación realizar la sincronización incremental Si se especifica el error especificado, los datos se perderán y los datos serán inconsistentes.
En la replicación basada en GTID, la biblioteca esclava informará a la biblioteca maestra del valor GTID de la transacción que se ha ejecutado, y luego la biblioteca maestra devolverá la lista de GTID de todas las transacciones no ejecutadas a la biblioteca esclava y puede garantizar que solo se especifique la misma transacción La biblioteca esclava se ejecuta una vez y el ID de transacción global se usa para determinar la transacción que se ejecutará desde la biblioteca en lugar del método anterior que requiere Binlog y la ubicación para determinar la transacción que se ejecutará desde la biblioteca .
El proceso de replicación basado en GTID es el siguiente:
- Cuando el maestro actualiza los datos, generará GTID antes de la transacción y lo registrará en el registro de Binlog juntos.
- El subproceso de E / S en el lado del esclavo escribe el Binlog modificado en el registro del relé local El valor de lectura se basa en
gitd_next变量decirnos qué GTID ejecutará el esclavo a continuación. - El hilo SQL obtiene el GTID del registro de retransmisión y luego compara si hay un registro en el Binlog en el lado esclavo. Si hay un registro, significa que la transacción GTID se ha ejecutado y el esclavo lo ignorará.
- Si no hay ningún registro, el esclavo ejecutará la transacción GTID desde el registro de retransmisión y la registrará en Binlog.
- En el proceso de análisis, se juzgará si hay una clave primaria, si no, use un índice secundario, si no hay un índice secundario, use un escaneo completo.
Composición GTID
GTID = source_id: transaction_id
source_id Lo normal es que se server_uuidgenera (función generate_server_uuid) en el primer inicio y persiste en el DATADIR/auto.cnf archivo.
transaction_id Sí 顺序化的序列号(número de secuencia), que es una secuencia que aumenta automáticamente a partir de 1 en cada servidor MySQL, y es el identificador único de la transacción.
Generación GTID
La generación de GTID está gtid_next controlada.
En el Master, gtid_next es el predeterminado AUTOMATIC, es decir , el GTID se genera automáticamente cada vez que se confirma una transacción. Encuentra un valor mínimo no utilizado mayor que 0 del conjunto GTID actualmente ejecutado (es decir, gtid_executed) como la siguiente transacción GTID. Escriba el GTID en Binlog antes del registro de la transacción de actualización real.
En esclavo, el GTID de la biblioteca principal se lee primero de Binlog (es decir, establece el registro gtid_next), y luego la transacción ejecutada usa este GTID.
Beneficios de GTID
- GTID utiliza
master_auto_position=1una solución de replicación maestro-esclavo en lugar de Binlog, que es más fácil de construir una replicación maestro-esclavo que Binlog. - GTID facilita la conmutación por error (conmutación maestro-esclavo) entre maestro y esclavo, sin tener que ubicar los archivos de registro de Binlog y encontrar la información de ubicación de Binlog paso a paso.
Limitaciones de la replicación del modo GTID
-
El uso mixto de motores en una transacción, como Innodb (transacciones de soporte), MyISAM (transacciones sin soporte), resulta en errores asociados con múltiples GTID y la misma transacción.
-
CREATE TABLE…..SELECTNo se pueden utilizar los dos eventos generados por esta declaración. En una determinada situación, se usará el mismo GTID (el mismo GTID solo se puede usar una vez en el esclavo):- evento uno: crear tabla declaración crear tabla
- evento dos: insertar declaración de datos insertar
-
CREATE TEMPORARY TABLE and DROP TEMPORARY TABLENo se puede utilizar dentro de una transacción (los–enforce-gtid-consistencyparámetros están habilitados ). -
Cuando se usa GTID para copiar de la biblioteca para omitir errores,
sql_slave_skip_counterla sintaxis del parámetro no es compatible .
Combate de replicación maestro-esclavo GTID
1. Operaciones en la base de datos principal principal
Configurar la replicación maestro-esclavo GTID en el archivo my.cnf
[root@mysql-master ~]# cp /etc/my.cnf /etc/my.cnf.bak
[root@mysql-master ~]# >/etc/my.cnf
[root@mysql-master ~]# cat /etc/my.cnf
[mysqld]
datadir = /var/lib/mysql
socket = /var/lib/mysql/mysql.sock
symbolic-links = 0
log-error = /var/log/mysqld.log
pid-file = /var/run/mysqld/mysqld.pid
#GTID:
server_id = 1
gtid_mode = on
enforce_gtid_consistency = on
#binlog
log_bin = mysql-bin
log-slave-updates = 1
binlog_format = row
sync-master-info = 1
sync_binlog = 1
#relay log
skip_slave_start = 1
Después de la configuración, reinicie el servicio MySQL:
[root@mysql-master ~]# systemctl restart mysqld
Inicie sesión en MySQL y verifique el estado del Master. Hay un elemento más Executed_Gtid_Set:
mysql> show master status;
+-------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 | 154 | | | |
+-------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
mysql> show global variables like '%uuid%';
+---------------+--------------------------------------+
| Variable_name | Value |
+---------------+--------------------------------------+
| server_uuid | 317e2aad-1565-11e9-9c2e-005056ac6820 |
+---------------+--------------------------------------+
1 row in set (0.00 sec)
Compruebe que la función GTID esté activada:
mysql> show global variables like '%gtid%';
+----------------------------------+-------+
| Variable_name | Value |
+----------------------------------+-------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | ON |
| gtid_executed | |
| gtid_executed_compression_period | 1000 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | |
| session_track_gtids | OFF |
+----------------------------------+-------+
8 rows in set (0.00 sec)
Compruebe que la función de registro de Binlog esté activada:
mysql> show variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin | ON |
+---------------+-------+
1 row in set (0.00 sec)
Autorice al esclavo a copiar usuarios y actualizar los permisos:
mysql> flush privileges;
Query OK, 0 rows affected (0.04 sec)
mysql> show grants for slave@'172.23.3.66';
+-------------------------------------------------------------------------------+
| Grants for [email protected] |
+-------------------------------------------------------------------------------+
| GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'172.23.3.66' |
+-------------------------------------------------------------------------------+
1 row in set (0.00 sec)
Verifique el estado del maestro nuevamente:
mysql> show master status;
+-------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000001 | 622 | | | 317e2aad-1565-11e9-9c2e-005056ac6820:1-2 |
+-------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)
Nota aquí:
Antes de comenzar la configuración, el servidor esclavo también debe inicializarse. El método para inicializar el servidor esclavo es básicamente el mismo que el basado en el punto de registro, excepto que después de que se inicia el modo GTID, lo que se registra en la copia de seguridad no es el nombre del archivo de registro binario y el desplazamiento durante la copia de seguridad, sino la copia de seguridad. El último valor de GTID en ese momento.
Primero debe hacer una copia de seguridad de la base de datos de destino en la máquina de la base de datos principal, asumiendo que la base de datos de destino es slave_test:
mysql> CREATE DATABASE slave_test CHARACTER SET utf8 COLLATE utf8_general_ci;
Query OK, 1 row affected (0.02 sec)
mysql> use slave_test;
Database changed
mysql> create table user (id int(10) PRIMARY KEY AUTO_INCREMENT,name varchar(50) NOT NULL);
Query OK, 0 rows affected (0.27 sec)
mysql> insert into slave_test.user values(1,"xiaoming"),(2,"xiaohong"),(3,"xiaolv");
Query OK, 3 rows affected (0.06 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> select * from slave_test.user;
+----+----------+
| id | name |
+----+----------+
| 1 | xiaoming |
| 2 | xiaohong |
| 3 | xiaolv |
+----+----------+
3 rows in set (0.00 sec)
Haga una copia de seguridad de la biblioteca slave_test:
[root@mysql-master ~]# mysqldump --single-transaction --master-data=2 --triggers --routines --databases slave_test -uroot -p123456 > /root/user.sql
Aquí hay un problema de versión:
Cuando MySQL 5.6 usa mysqldump respaldo, especifique la base de datos específica para respaldo y uso --database.
Cuando MySQL 5.7 usa mysqldump respaldo, especifique la base de datos específica para respaldo y uso--databases。
Luego /root/user.sql copie el archivo de respaldo al servidor de la base de datos esclavo.
[root@mysql-master ~]# rsync -e "ssh -p20" -avpgolr /root/user.sql
En este punto, la operación de la biblioteca principal ha terminado, los datos de respaldo que contienen GTID se han copiado a la biblioteca esclava y la operación de la biblioteca esclava se realiza a continuación.
2. Funcionamiento desde la biblioteca
Configurar la replicación maestro-esclavo GTID en el archivo my.cnf
La configuración del servidor maestro es aproximadamente la misma. Además de la inconsistencia de server_id, el servidor esclavo también se puede agregar en el archivo de configuración read_only＝on para que el servidor esclavo solo pueda realizar operaciones de lectura. Este parámetro no es válido para los superusuarios y no afectará la replicación del servidor esclavo.
[root@mysql-slave1 ~]# >/etc/my.cnf
[root@mysql-slave1 ~]# vim /etc/my.cnf
[mysqld]
datadir = /var/lib/mysql
socket = /var/lib/mysql/mysql.sock
symbolic-links = 0
log-error = /var/log/mysqld.log
pid-file = /var/run/mysqld/mysqld.pid
#GTID:
server_id = 2
gtid_mode = on
enforce_gtid_consistency = on
#binlog
log_bin = mysql-bin
log-slave-updates = 1
binlog_format = row
sync-master-info = 1
sync_binlog = 1
#relay log
skip_slave_start = 1
read_only = on
Una vez completada la configuración, reinicie el servicio mysql.
[root@mysql-slave1 ~]# systemctl restart mysql
Luego user.sqlimporte los datos de respaldo de la base de datos de destino de la base de datos maestra a la base de datos esclava.
[root@mysql-slave1 ~]# ls /root/user.sql
/root/user.sql
[root@mysql-slave1 ~]# mysql -p123456
.........
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
+--------------------+
4 rows in set (0.00 sec)
mysql> source /root/user.sql;
mysql> select * from slave.test;
+----+----------+
| id | name |
+----+----------+
| 1 | xiaoming |
| 2 | xiaohong |
| 3 | xiaolv |
+----+----------+
3 rows in set (0.00 sec)
En la base de datos esclava, use la change master configuración de replicación maestro-esclavo:
mysql> stop slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> change master to master_host='172.23.3.66',master_user='slave1',master_password='123456',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.26 sec)
mysql> start slave;
Query OK, 0 rows affected (0.02 sec)
mysql> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.23.3.66
Master_User: slave1
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 1357
Relay_Log_File: mysql-slave1-relay-bin.000002
Relay_Log_Pos: 417
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
................
................
Executed_Gtid_Set: 317e2aad-1565-11e9-9c2e-005056ac6820:1-5
Auto_Position: 1
Por lo tanto, los nodos maestro y esclavo se han configurado con una relación de sincronización maestro-esclavo. A continuación, puede insertar un dato en la biblioteca maestra para observar si la biblioteca esclava está sincronizada.
Hay dos formas de agregar una biblioteca esclava usando GTID
Sincronizar directamente todos los GTID de la biblioteca principal
Si GTID está habilitado en la biblioteca principal desde el principio, todos los GTID de la biblioteca principal se pueden obtener directamente para sincronizar con la biblioteca esclava. Pero si hay demasiados registros de Binlog en la biblioteca principal, el tiempo de sincronización correspondiente también será más largo. Este método es adecuado para la sincronización de pequeños volúmenes de datos.
Utilice este método para sincronizar los comandos correspondientes:
mysql>change master to master_host='xxxxxxx',master_user='xxxxxx',master_password='xxxxx',MASTER_AUTO_POSITION=1;
mysql> start slave;
mysql> stop slave io_thread; #重启 io 线程,刷新状态
mysql> start slave io_thread;
Cuando se utilizan MASTER_AUTO_POSITION parámetros MASTER_LOG_FILE, los MASTER_LOG_POS parámetros no se pueden utilizar.
Si desea GTID 配置回 posseguir, ejecute esta instrucción nuevamente, pero establezca MASTER_AUTO_POSITION en 0.
Sincronizar por rango de configuración
Especificando el rango de GTID y luego configurando el esclavo @@GLOBAL.GTID_PURGED para omitir el GTID incluido en la copia de seguridad.
Esta solución es adecuada para datos cuyo volumen de datos es relativamente grande y una sincronización requiere una gran cantidad de tiempo. Pero al mismo tiempo, también existe el problema de las operaciones complicadas, que requiere recordar el alcance de cada sincronización.
Los comandos correspondientes para sincronizar de esta forma son:
mysql>change master to master_host='xxxxxxx',master_user='xxxxxx',master_password='xxxxx',MASTER_LOG_POS='xxxx';
mysql> start slave;
mysql> stop slave io_thread; #重启 io 线程,刷新状态
mysql> start slave io_thread;
Tenga en cuenta aquí que nuestros parámetros han sido modificados:, MASTER_LOG_POSeste parámetro representa el valor inicial de la transacción GTID que actualmente necesita sincronizarse.
para resumir
Este artículo presenta dos formas de replicación maestro-esclavo: el método de replicación tradicional basado en Binlog y la información del sitio; y el nuevo método de replicación basado en Binlog y GTID. Es posible que muchas empresas sigan utilizando la versión 5.6 de MySQL, por lo que es posible que GTID no esté disponible.