In the process of implementing the mysql master-slave architecture, you can use the mysqldump method to build the master-slave. Mysqldump has generated GTID related information during the backup process, that is, these GTIDs can be skipped. For unskipped GTIDs, the IO thread will copy them to the slave server and be executed by the SQL thread. This article mainly demonstrates how mysqldump builds mysql master-slave in GTID mode.
Reference for relevant knowledge points:
Configuring MySQL GTID master-slave replication
Quickly build a slave database based on mysqldump
Use mysqldump to export the database
1.如果master所有的binlog还在，安装slave后，直接change master 到master 原理是直接获取master所有的gtid并执行 优点是简单 缺点是如果binlog太多，数据完全同步需要的时间较长，并且需要master一开始就启用了GTID 总结：适用于master也是新建不久的情况 2.通过master或者其它slave的mysqldump备份搭建新的slave. 原理：备份时获取master的数据和这些数据对应的GTID，在Slave端跳过备份包含的GTID 优点是可以避免第一种方法中的不足 缺点操作相对复杂 总结：适用于拥有较大数据集的情况 3、percona xtrabackup 基于xtrabackup备份文件xtrabackup_binlog_info包含了GTID信息 做从库恢复后，需要手工设置：set@@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497';恢复后，执行change master to 缺点操作相对复杂 总结：适用于拥有较大数据集的情况
1、演示环境 mysql> system cat /etc/redhat-release CentOS release 6.7 (Final)mysql> show variables like 'version'; +---------------+------------+| Variable_name | Value | +---------------+------------+| version | 5.7.12-log | +---------------+------------+主服务器：192.168.1.245:3306 server_id : 245 从服务器：192.168.1.247:3306 server_id : 247 --在主库端创建复制用户 mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'%' IDENTIFIED BY '123456'; 2、直接使用change master(针对本文第一部分，第1小点情形) 此处省略基于gtid配置的参数描述，具体可以参考：配置MySQL GTID 主从复制 在从服务器端直接change master，如下：SLAVE> show variables like 'server_id'; +---------------+-------+| Variable_name | Value | +---------------+-------+| server_id | 247 | +---------------+-------+Slave> CHANGE MASTER TO -> MASTER_HOST='192.168.1.245', -> MASTER_USER='repl', -> MASTER_PASSWORD='123456', -> MASTER_PORT=3306, -> MASTER_AUTO_POSITION = 1;Query OK, 0 rows affected, 2 warnings (0.12 sec) Slave> start slave; Query OK, 0 rows affected (0.01 sec) Slave> start slave; Query OK, 0 rows affected (0.01 sec) Slave> show slave status \G*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.245 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: node3-binlog.000001 Read_Master_Log_Pos: 457 Relay_Log_File: node5-relay-bin.000002 Relay_Log_Pos: 676 Relay_Master_Log_File: node3-binlog.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes ...............--主服务器端操作如下 Master> create database tempdb; Query OK, 1 row affected (0.02 sec) Master> use tempdb Database changed Master> create table t1(id int,ename varchar(20)); Query OK, 0 rows affected (0.09 sec) Master> insert into t1 values(1,'leshami'); Query OK, 1 row affected (0.08 sec) --从服务器端验证Slave> select * from tempdb.t1; +------+---------+| id | ename | +------+---------+| 1 | leshami | +------+---------+1 row in set (0.01 sec) 3、基于mysqldump搭建gtid从库 --准备环境，从库端执行 Slave> stop slave; --停止重库 Query OK, 0 rows affected (0.01 sec) Slave> reset slave all; --重置主从配置信息 Query OK, 0 rows affected (0.02 sec) --准备环境，主库端执行 Master> source sakila-db/sakila-schema.sql --导入mysql自带的sakila数据库 Master> source sakila-db/sakila-data.sql --填充数据 --使用mysqldump导出数据库 # mysqldump --all-databases --single-transaction --triggers --routines --events \ > --host=localhost --port=3306 --user=root --password=MyP@ssw0rd >/tmp/alldb.sql --导出的文件中已经包含了GTID_PURGED的信息 # grep GTID_PURGED /tmp/alldb.sql SET @@GLOBAL.GTID_PURGED='78336cdc-8cfb-11e6-ba9f-000c29328504:1-38';--将备份文件copy到从服务器 # scp /tmp/alldb.sql 192.168.1.247:/tmp-- 执行reset master，重置从服务器上的binlog Slave> reset master; Query OK, 0 rows affected (0.03 sec) Slave> source /tmp/alldb.sqlSlave> show databases; --此时tempdb已产生 +--------------------+| Database | +--------------------+| information_schema | | mysql | | performance_schema | | sakila | | sys || tempdb | +--------------------+--执行change master Slave> CHANGE MASTER TO -> MASTER_HOST='192.168.1.245', -> MASTER_USER='repl', -> MASTER_PASSWORD='123456', -> MASTER_PORT=3306, -> MASTER_AUTO_POSITION = 1;Query OK, 0 rows affected, 2 warnings (0.06 sec) Slave> start slave; Query OK, 0 rows affected (0.00 sec) Slave> show slave status \G*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.245 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: node3-binlog.000001 Read_Master_Log_Pos: 25637 Relay_Log_File: node5-relay-bin.000002 Relay_Log_Pos: 423 Relay_Master_Log_File: node3-binlog.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes--主库端执行一些事务 Master> alter table tempdb.t1 modify ename varchar(50); Query OK, 0 rows affected (0.05 sec) Records: 0 Duplicates: 0 Warnings: 0 Master> insert into tempdb.t1 values(2,'http://blog.csdn.net/leshami'); Query OK, 1 row affected (0.02 sec) --从库端验证结果Slave> desc tempdb.t1; +-------+-------------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra | +-------+-------------+------+-----+---------+-------+| id | int(11) | YES | | NULL | || ename | varchar(50) | YES | | NULL | | +-------+-------------+------+-----+---------+-------+2 rows in set (0.00 sec)Slave> select * from tempdb.t1; +------+------------------------------+| id | ename | +------+------------------------------+| 1 | leshami || 2 | //m.sbmmt.com/ | +------+------------------------------+
In the process of implementing the mysql master-slave architecture, you can use the mysqldump method to build the master from. Mysqldump has generated GTID related information during the backup process, that is, these GTIDs can be skipped. For unskipped GTIDs, the IO thread will copy them to the slave server and be executed by the SQL thread. This article mainly demonstrates how mysqldump builds mysql master-slave in GTID mode.
Reference to relevant knowledge points:
Configure MySQL GTID master-slave replication
Quickly build a slave database based on mysqldump
Use mysqldump to export the database
1.如果master所有的binlog还在，安装slave后，直接change master 到master 原理是直接获取master所有的gtid并执行 优点是简单 缺点是如果binlog太多，数据完全同步需要的时间较长，并且需要master一开始就启用了GTID 总结：适用于master也是新建不久的情况 2.通过master或者其它slave的mysqldump备份搭建新的slave. 原理：备份时获取master的数据和这些数据对应的GTID，在Slave端跳过备份包含的GTID 优点是可以避免第一种方法中的不足 缺点操作相对复杂 总结：适用于拥有较大数据集的情况 3、percona xtrabackup 基于xtrabackup备份文件xtrabackup_binlog_info包含了GTID信息 做从库恢复后，需要手工设置：set@@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497';恢复后，执行change master to 缺点操作相对复杂 总结：适用于拥有较大数据集的情况
1、演示环境 mysql> system cat /etc/redhat-release CentOS release 6.7 (Final)mysql> show variables like 'version'; +---------------+------------+| Variable_name | Value | +---------------+------------+| version | 5.7.12-log | +---------------+------------+主服务器：192.168.1.245:3306 server_id : 245 从服务器：192.168.1.247:3306 server_id : 247 --在主库端创建复制用户 mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'%' IDENTIFIED BY '123456'; 2、直接使用change master(针对本文第一部分，第1小点情形) 此处省略基于gtid配置的参数描述，具体可以参考：配置MySQL GTID 主从复制 在从服务器端直接change master，如下：SLAVE> show variables like 'server_id'; +---------------+-------+| Variable_name | Value | +---------------+-------+| server_id | 247 | +---------------+-------+Slave> CHANGE MASTER TO -> MASTER_HOST='192.168.1.245', -> MASTER_USER='repl', -> MASTER_PASSWORD='123456', -> MASTER_PORT=3306, -> MASTER_AUTO_POSITION = 1;Query OK, 0 rows affected, 2 warnings (0.12 sec) Slave> start slave; Query OK, 0 rows affected (0.01 sec) Slave> start slave; Query OK, 0 rows affected (0.01 sec) Slave> show slave status \G*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.245 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: node3-binlog.000001 Read_Master_Log_Pos: 457 Relay_Log_File: node5-relay-bin.000002 Relay_Log_Pos: 676 Relay_Master_Log_File: node3-binlog.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes ...............--主服务器端操作如下 Master> create database tempdb; Query OK, 1 row affected (0.02 sec) Master> use tempdb Database changed Master> create table t1(id int,ename varchar(20)); Query OK, 0 rows affected (0.09 sec) Master> insert into t1 values(1,'leshami'); Query OK, 1 row affected (0.08 sec) --从服务器端验证Slave> select * from tempdb.t1; +------+---------+| id | ename | +------+---------+| 1 | leshami | +------+---------+1 row in set (0.01 sec) 3、基于mysqldump搭建gtid从库 --准备环境，从库端执行 Slave> stop slave; --停止重库 Query OK, 0 rows affected (0.01 sec) Slave> reset slave all; --重置主从配置信息 Query OK, 0 rows affected (0.02 sec) --准备环境，主库端执行 Master> source sakila-db/sakila-schema.sql --导入mysql自带的sakila数据库 Master> source sakila-db/sakila-data.sql --填充数据 --使用mysqldump导出数据库 # mysqldump --all-databases --single-transaction --triggers --routines --events \ > --host=localhost --port=3306 --user=root --password=MyP@ssw0rd >/tmp/alldb.sql --导出的文件中已经包含了GTID_PURGED的信息 # grep GTID_PURGED /tmp/alldb.sql SET @@GLOBAL.GTID_PURGED='78336cdc-8cfb-11e6-ba9f-000c29328504:1-38';--将备份文件copy到从服务器 # scp /tmp/alldb.sql 192.168.1.247:/tmp-- 执行reset master，重置从服务器上的binlog Slave> reset master; Query OK, 0 rows affected (0.03 sec) Slave> source /tmp/alldb.sqlSlave> show databases; --此时tempdb已产生 +--------------------+| Database | +--------------------+| information_schema | | mysql | | performance_schema | | sakila | | sys || tempdb | +--------------------+--执行change master Slave> CHANGE MASTER TO -> MASTER_HOST='192.168.1.245', -> MASTER_USER='repl', -> MASTER_PASSWORD='123456', -> MASTER_PORT=3306, -> MASTER_AUTO_POSITION = 1;Query OK, 0 rows affected, 2 warnings (0.06 sec) Slave> start slave; Query OK, 0 rows affected (0.00 sec) Slave> show slave status \G*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.245 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: node3-binlog.000001 Read_Master_Log_Pos: 25637 Relay_Log_File: node5-relay-bin.000002 Relay_Log_Pos: 423 Relay_Master_Log_File: node3-binlog.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes--主库端执行一些事务 Master> alter table tempdb.t1 modify ename varchar(50); Query OK, 0 rows affected (0.05 sec) Records: 0 Duplicates: 0 Warnings: 0 Master> insert into tempdb.t1 values(2,'http://blog.csdn.net/leshami'); Query OK, 1 row affected (0.02 sec) --从库端验证结果Slave> desc tempdb.t1; +-------+-------------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra | +-------+-------------+------+-----+---------+-------+| id | int(11) | YES | | NULL | || ename | varchar(50) | YES | | NULL | | +-------+-------------+------+-----+---------+-------+2 rows in set (0.00 sec)Slave> select * from tempdb.t1; +------+------------------------------+| id | ename | +------+------------------------------+| 1 | leshami || 2 | //m.sbmmt.com/ | +------+------------------------------+
The above is the content of building gtid master and slave based on mysqldump. For more related content, please pay attention to the PHP Chinese website (m.sbmmt.com) !
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
