Escrito en el frente: Las preguntas avanzadas de la entrevista de back-end de Java necesarias para la entrevista en 2020. Una guía de revisión se resume en Github. El contenido es detallado, con imágenes y textos. ¡Los amigos que necesitan aprender pueden protagonizar!
Dirección de GitHub: https://github.com/abel-max/Java-Study-Note/tree/master
La función principal del registro de Binlog es la recuperación de datos y la replicación maestro-esclavo. Es un archivo de registro en formato binario y la transmisión por red no requiere conversión de protocolo. La alta disponibilidad, el equilibrio de carga, la separación de lectura y escritura del clúster MySQL y otras funciones se basan en Binlog.
Modelo de arquitectura principal de replicación maestro-esclavo de MySQL
Basándonos en Binlog, podemos replicar un servidor MySQL o varios, 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 es 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 serio.
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 cualquier lado 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 en 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 retraso 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 el Binlog, el hilo de volcado de registro 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
Cuando se ejecuta desde el nodo start slavedespués del comando, el nodo crea un subproceso de E / S que se utiliza para conectar el nodo maestro, la solicitud Binlog actualiza el repositorio maestro. 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 varios 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)</pre>
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 falla y el registro de retransmisión de la biblioteca esclava está incompleto. No es un último recurso y no se recomienda.
sync_relay_log
Este parámetro y Binlog tienen el sync_binlogmismo efecto. 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, reduce 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 sincronizar 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
sart slave
master-info
relay log.info
MySQL se basa en la introducción del modo de replicación maestro-esclavo de Binlog
La replicación maestro-esclavo de MySQL es el modo asíncrono predeterminado . 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 activamente 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 al nodo esclavo. Si en este momento, la actualización forzosa será el 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 al menos a 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.
[Error al cargar la imagen ... (image-d63820-1603346152190)]
En comparación con la replicación asincrónica, la replicación semisincrónica mejora la seguridad de los datos y garantiza que se pueda realizar una copia de seguridad de los datos 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 altamente eficiente.Cuando el TPS de la biblioteca principal es alto, la eficiencia de escritura del lado maestro debe ser mayor que la del lado esclavo Lea la 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.
Por show slave statuscomando para ver Seconds_Behind_Mastersi hay un punto de vista del valor de retardo de sincronización, este valor representa la sincronización maestro-esclavo del retardo de tiempo, cuanto mayor es el valor, más graves son los retardos. 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 retrasa 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>0Sí, 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. Donde la variable slave-parallel-typepuede 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 multihilo 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 copia convencional que, cuando ocurre una falla, necesita cambiar el primario y la necesidad de encontrar información del sitio Binlog, después de completar los datos de recuperación en el nuevo sitio primario. 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 alguna 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 decirle 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 método para determinar la transacción que ejecutará la biblioteca esclava a través del ID de transacción global reemplaza el método anterior de usar 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:
gitd_next变量
Composición de GTID
GTID = source_id: transaction_id
source_idEso normalmente se server_uuidgenera (funciona cuando se inicia por primera vez generate_server_uuid) y persiste en el DATADIR/auto.cnfarchivo.
transaction_idSí 顺序化的序列号(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
GTID generado por el gtid_nextcontrol.
En el Master, gtid_nextes 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
master_auto_position=1
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), causa múltiples GTID y errores asociados con 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 (–enforce-gtid-consistencyparámetro habilitado ). -
Use la copia GTID de la biblioteca para omitir el error, no admite los
sql_slave_skip_counterparámetros de sintaxis.
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 iniciar la configuración, también es necesario inicializar el servidor esclavo. 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:
Uso de MySQL 5.6 mysqldumpdurante la copia de seguridad, la copia de seguridad designó bibliotecas específicas para su uso --database.
Uso de MySQL 5.7 mysqldumpdurante la copia de seguridad, la copia de seguridad designó bibliotecas específicas, uso--databases。
Luego, la /root/user.sqlcopia de seguridad del archivo al servidor esclavo desde la base de datos.
[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, de modo que el servidor esclavo solo puede realizar operaciones de lectura. Este parámetro no es válido para el superusuario 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
A continuación, los datos de respaldo de la base de datos de la biblioteca de destino principal user.sqlen la base de datos.
[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, usando change masterla configuración de replicación maestra:
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 MASTER_AUTO_POSITIONlos parámetros de tiempo MASTER_LOG_FILE, MASTER_LOG_POSlos parámetros no se pueden utilizar.
Si desea GTID 配置回 posseguir, ejecute esta declaración nuevamente, pero establezca MASTER_AUTO_POSITION en 0.
Sincronizar por rango de configuración
GTID al especificar un rango, luego se proporciona el esclavo @@GLOBAL.GTID_PURGEDpara omitir el GTID de respaldo incluido.
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 todavía utilicen la versión 5.6 de MySQL, por lo que es posible que GTID no esté disponible.
Este artículo es extenso, por lo que puede revisar brevemente el principio.