本文接上篇《mysql5.7基于GTID搭建主从》。
当前有master,slave,standby,其中slave和standby节点都是slave身份。
现在,我将通过stop slave模拟slave节点同步延迟,然后kill -9模拟master宕机,然后将拥有最新数据的standby提升为master,并令slave同步standby的数据。
真正的failover主从切换,还会多一个步骤,就是如果master机器仍旧可以登录则将master上未同步到slave的binlog重放给slave,本篇博客不研究这个问题。
模拟主从切换
应读者要求,在此首先列出3台服务器的SERVER_ID映射关系:
- master:a805814a–99c2–11e7–9c9e–525400caafe4
- standby:a9012235-99d3-11e7-a3f2-525400caafe4
- slave:6d167b53-99c4-11e7-bada-525400caafe4
首先登录slave,令其停止同步,这相当于模拟了slave节点同步延迟。
1 2 3 4 |
[liangdong@10-10-162-70 mysql]$ mysql -S /home/liangdong/mysql/slave/mysql.sock -u root -p mysql> stop slave; Query OK, 0 rows affected (0.00 sec) |
然后,我们对master内的数据做一次更新,这样slave相当于延迟没有同步到新的变更,而standby可以立即同步到新的变更:
1 |
mysql > update user set name="john"; |
接着找出master进程ID,将其杀死:
1 |
[liangdong@10-10-162-70 master]$ kill -9 30561 |
现在相当于master出现了故障。在紧急故障处理时,优先确保master已经死绝,避免半死不死造成脑裂。
然后,我们登录slave和standby执行show slave status,确认它们已经将现有relay-log全部重放完成,以standby为例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 |
mysql -S /home/liangdong/mysql/standby/mysql.sock -u root -p mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Reconnecting after a failed master event read Master_Host: localhost Master_User: root Master_Port: 3306 Connect_Retry: 60 Master_Log_File: binlog.000005 Read_Master_Log_Pos: 194 Relay_Log_File: relay.000003 Relay_Log_Pos: 401 Relay_Master_Log_File: binlog.000005 Slave_IO_Running: Connecting Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 194 Relay_Log_Space: 2281 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: NULL Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 2003 Last_IO_Error: error reconnecting to master 'root@localhost:3306' - retry-time: 60 retries: 4 Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1 Master_UUID: a805814a-99c2-11e7-9c9e-525400caafe4 Master_Info_File: /home/liangdong/mysql/standby/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: 170915 13:22:44 Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: a805814a-99c2-11e7-9c9e-525400caafe4:1-6 Executed_Gtid_Set: a805814a-99c2-11e7-9c9e-525400caafe4:1-6, a9012235-99d3-11e7-a3f2-525400caafe4:1 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec) |
可见提示,Slave has read all relay log,说明standby节点重放完成,它最新GTID是a805814a-99c2-11e7-9c9e-525400caafe4:6。同样的,观察slave节点确保它也重放完成,最新GTID是a805814a-99c2-11e7-9c9e-525400caafe4:5:
1 2 3 |
Retrieved_Gtid_Set: a805814a-99c2-11e7-9c9e-525400caafe4:1-5 Executed_Gtid_Set: 6d167b53-99c4-11e7-bada-525400caafe4:1, a805814a-99c2-11e7-9c9e-525400caafe4:1-5 |
接着,我们对比slave和standby这两个从节点谁的数据比较新,拥有较新数据的应该提为master,这样可以尽量减少宕机带来的数据损失,
slave节点的Executed_Gtid_Set为a805814a-99c2-11e7-9c9e-525400caafe4:1-5(我们模拟了同步延迟),而standby是a805814a-99c2-11e7-9c9e-525400caafe4:1-6,说明standby数据比较新,因为我们刻意模拟slave节点同步延迟并在master做了一次更新。
另外也可以通过观察同步master binlog的偏移量来判断谁更新。
slave节点:
1 2 |
Master_Log_File: binlog.000002 Read_Master_Log_Pos: 1343 |
standby节点:
1 2 |
Master_Log_File: binlog.000005 Read_Master_Log_Pos: 194 |
可见,standby节点已经读到master的binlog.00005了,显然要领先于slave读取的binlog.00002文件。
接下来,我令standby成为master,也就是关闭它的read_only和super_read_only:
1 2 3 4 5 |
mysql> set global read_only=0; Query OK, 0 rows affected (0.00 sec) mysql> set global super_read_only=0; Query OK, 0 rows affected (0.00 sec) |
然后,令slave节点停止同步,并定向到standby(端口是3308)作为master:
1 2 3 4 5 |
mysql> stop slave; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> CHANGE MASTER TO MASTER_HOST="localhost", MASTER_PORT=3308,MASTER_USER='root',MASTER_PASSWORD='baidu',MASTER_AUTO_POSITION=1; Query OK, 0 rows affected, 2 warnings (0.01 sec) |
观察此时slave节点的同步状态:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Master_Host: localhost Master_User: root Master_Port: 3308 Connect_Retry: 60 Master_Log_File: Read_Master_Log_Pos: 4 Relay_Log_File: relay.000001 Relay_Log_Pos: 4 Relay_Master_Log_File: Slave_IO_Running: No Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 0 Relay_Log_Space: 194 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: NULL Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 0 Master_UUID: Master_Info_File: /home/liangdong/mysql/slave/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: 6d167b53-99c4-11e7-bada-525400caafe4:1, a805814a-99c2-11e7-9c9e-525400caafe4:1-5 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec) |
可见当前slave最新GTID还指在5,落后于standby的1-6。现在我们启动slave对standby的同步,并再次观察:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 |
mysql> start slave; Query OK, 0 rows affected (0.00 sec) mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: localhost Master_User: root Master_Port: 3308 Connect_Retry: 60 Master_Log_File: binlog.000002 Read_Master_Log_Pos: 1856 Relay_Log_File: relay.000002 Relay_Log_Pos: 927 Relay_Master_Log_File: binlog.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 1856 Relay_Log_Space: 1164 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 3 Master_UUID: a9012235-99d3-11e7-a3f2-525400caafe4 Master_Info_File: /home/liangdong/mysql/slave/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: a805814a-99c2-11e7-9c9e-525400caafe4:6, a9012235-99d3-11e7-a3f2-525400caafe4:1 Executed_Gtid_Set: 6d167b53-99c4-11e7-bada-525400caafe4:1, a805814a-99c2-11e7-9c9e-525400caafe4:1-6, a9012235-99d3-11e7-a3f2-525400caafe4:1 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec) |
可见Executed_Gtid_Set已经完成对6的同步,查看数据已经得到更新:
1 2 3 4 5 6 7 8 9 10 11 12 |
mysql> use mydb; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> select * from user; +----+------+ | id | name | +----+------+ | 1 | john | +----+------+ 1 row in set (0.00 sec) |
现在,我们向新master节点更新一次数据:
1 2 3 4 5 6 7 8 |
mysql> use mydb; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> update user set name = "body"; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 |
登录slave,确认是否可以正常同步:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 |
mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: localhost Master_User: root Master_Port: 3308 Connect_Retry: 60 Master_Log_File: binlog.000002 Read_Master_Log_Pos: 2138 Relay_Log_File: relay.000002 Relay_Log_Pos: 1209 Relay_Master_Log_File: binlog.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 2138 Relay_Log_Space: 1446 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 3 Master_UUID: a9012235-99d3-11e7-a3f2-525400caafe4 Master_Info_File: /home/liangdong/mysql/slave/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: a805814a-99c2-11e7-9c9e-525400caafe4:6, a9012235-99d3-11e7-a3f2-525400caafe4:1-2 Executed_Gtid_Set: 6d167b53-99c4-11e7-bada-525400caafe4:1, a805814a-99c2-11e7-9c9e-525400caafe4:1-6, a9012235-99d3-11e7-a3f2-525400caafe4:1-2 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec) |
a9012235-99d3-11e7-a3f2-525400caafe4:1-2的前半部分就是standby节点的SERVER_ID哈希值,1-2是自增ID,可见最新一次修改应该是正常同步了过来。查看数据表以便确认:
1 2 3 4 5 6 7 8 9 |
mysql> use mydb; Database changed mysql> select * from user; +----+------+ | id | name | +----+------+ | 1 | body | +----+------+ 1 row in set (0.00 sec) |
当然,我们最好也确认一下master和slave生成的binlog是否保持了一致:
1 2 3 4 5 6 7 8 |
mysql> show master status; +---------------+----------+--------------+------------------+------------------------------------------------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +---------------+----------+--------------+------------------+------------------------------------------------------------------------------------+ | binlog.000002 | 2138 | | | a805814a-99c2-11e7-9c9e-525400caafe4:1-6, a9012235-99d3-11e7-a3f2-525400caafe4:1-2 | +---------------+----------+--------------+------------------+------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) |
1 2 3 4 5 6 7 8 9 |
mysql> show master status; +---------------+----------+--------------+------------------+----------------------------------------------------------------------------------------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +---------------+----------+--------------+------------------+----------------------------------------------------------------------------------------------------------------------------+ | binlog.000002 | 2373 | | | 6d167b53-99c4-11e7-bada-525400caafe4:1, a805814a-99c2-11e7-9c9e-525400caafe4:1-6, a9012235-99d3-11e7-a3f2-525400caafe4:1-2 | +---------------+----------+--------------+------------------+----------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) |
slave上多的6d167b53-99c4-11e7-bada-525400caafe4:1是我们初始化slave时候set password留下的一个本机GTID,其他均是一样的。
更多问题
假设standby机器性能一般,但是数据较新;slave机器性能好,但数据较旧。那么,我可能选择用slave节点作为新的master,但是它数据比standby少,怎么办?
以当前掌握的知识,我只能先让slave同步standby的数据,然后再将这个关系反转回来,这样基于主从同步技术完成数据补齐最简单,直接操作binlog的方法我暂时还没有学到。另外一个思路是,直接把最新slave的所有数据通过dump工具(xtrabackup )拷贝出来,然后对其他slave逐个停机完整替换数据重启,这样也是一种追平数据的思路,可以参考这里。
其实,官方已经提供了failover切换的工具:mysqlfailover,它需要单独安装。这个工具可以帮我们监视mysql集群的健康情况,当master宕机后自动完成整个切换过程,你可以参考这个博客《mysql5.6自动failover》。
添加新的slave
添加新的slave并不复杂,从master dump出最新的数据,拷贝给新的slave,然后再change master to即可。
首先,我去新的master节点(standby)做一次数据的dump,这里我使用mysqldump工具,生产环境应该使用更快的开源工具xtrabackup。
1 |
mysqldump --triggers --routines --events --single-transaction --all-databases -S /home/liangdong/mysql/standby/mysql.sock --user=root --password > dump.sql |
假设现在master机器修理完成,我想让老的master机器成为一个slave节点,所以先要删除master的所有数据,然后重新初始化并启动它。
作为一个slave,必须首先关闭super_read_only(因为my.cnf里配置了On):
1 |
set global super_read_only=off; |
然后set password设置你的密码,最后恢复read_only:
1 |
set global super_read_only=on; |
上述改密码是写操作,所以会导致产生了binlog,你可以查看一下:
1 2 3 4 5 6 |
mysql> show master status; +---------------+----------+--------------+------------------+----------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +---------------+----------+--------------+------------------+----------------------------------------+ | binlog.000002 | 398 | | | 52ba1b1a-99ec-11e7-9f32-525400caafe4:1 | +---------------+----------+--------------+------------------+----------------------------------------+ |
作为一个slave,应该保障binlog和master一致,这样后续failover充当master时才能保证一致性,所以我们这里执行reset master来清理掉当前产生的binlog,另外这也是恢复dump要求的一个必须操作,否则dump文件无法复原:
1 2 3 4 5 6 7 8 9 10 |
mysql> reset master; Query OK, 0 rows affected (0.01 sec) mysql> show master status; +---------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +---------------+----------+--------------+------------------+-------------------+ | binlog.000001 | 154 | | | | +---------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec) |
现在Executed_Gtid_Set已清空,binlog恢复为00001文件,这是一台完全崭新的mysql节点。现在,我们将dump文件导入进来:
1 |
mysql -S /home/liangdong/mysql/master/mysql.sock -u root -p < dump.sql |
再次连接mysql,查看gtid状态:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
mysql> show variables like '%gtid%'; +----------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Variable_name | Value | +----------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | binlog_gtid_simple_recovery | ON | | enforce_gtid_consistency | ON | | gtid_executed_compression_period | 1000 | | gtid_mode | ON | | gtid_next | AUTOMATIC | | gtid_owned | | | gtid_purged | 199282bc-99e8-11e7-9191-525400caafe4:1, 52ba1b1a-99ec-11e7-9f32-525400caafe4:1, a805814a-99c2-11e7-9c9e-525400caafe4:1-6, a9012235-99d3-11e7-a3f2-525400caafe4:1-2 | | session_track_gtids | OFF | +----------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 8 rows in set (0.01 sec) |
1 2 3 4 5 6 7 8 9 10 |
mysql> show master status; +---------------+----------+--------------+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +---------------+----------+--------------+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | binlog.000001 | 154 | | | 199282bc-99e8-11e7-9191-525400caafe4:1, 52ba1b1a-99ec-11e7-9f32-525400caafe4:1, a805814a-99c2-11e7-9c9e-525400caafe4:1-6, a9012235-99d3-11e7-a3f2-525400caafe4:1-2 | +---------------+----------+--------------+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) |
发现binlog文件并没有增长,但其实已经将来自standby的事务全部执行完成(Executed_Gtid_Set),同时因为binlog文件并没有记录下来,所以gtid_purged=executed_gtid_set,表示这些gtid的binlog都已删除,不在本机存在。
为什么会有这种效果呢?其实看看dump文件里的语句就知道是什么原理了。
在dump头部首先关闭了log_bin,也就是不再输出binlog,并且设置了GTID_PURGED包含了这些即将执行的GTID SET:
1 2 3 4 5 6 7 8 9 10 11 |
SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN; SET @@SESSION.SQL_LOG_BIN= 0; -- -- GTID state at the beginning of the backup -- SET @@GLOBAL.GTID_PURGED='199282bc-99e8-11e7-9191-525400caafe4:1, 52ba1b1a-99ec-11e7-9f32-525400caafe4:1, a805814a-99c2-11e7-9c9e-525400caafe4:1-6, a9012235-99d3-11e7-a3f2-525400caafe4:1-2'; |
接下来执行所有的事务,最后再恢复log_bin配置:
1 2 |
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN; /*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */; |
现在要做的,就是change master to,让这个新的slave(原master)和新的master(standby)自动进行GTID交互,完成主从同步。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 |
mysql> CHANGE MASTER TO MASTER_HOST="localhost", MASTER_PORT=3308,MASTER_USER='root',MASTER_PASSWORD='baidu',MASTER_AUTO_POSITION=1; Query OK, 0 rows affected, 2 warnings (0.02 sec) mysql> start slave; Query OK, 0 rows affected (0.00 sec) mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: localhost Master_User: root Master_Port: 3308 Connect_Retry: 60 Master_Log_File: binlog.000002 Read_Master_Log_Pos: 2626 Relay_Log_File: relay.000002 Relay_Log_Pos: 405 Relay_Master_Log_File: binlog.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 2626 Relay_Log_Space: 602 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 3 Master_UUID: a9012235-99d3-11e7-a3f2-525400caafe4 Master_Info_File: /home/liangdong/mysql/master/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: 199282bc-99e8-11e7-9191-525400caafe4:1, 52ba1b1a-99ec-11e7-9f32-525400caafe4:1, a805814a-99c2-11e7-9c9e-525400caafe4:1-6, a9012235-99d3-11e7-a3f2-525400caafe4:1-2 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec) |
大功告成!
具体过程可以参考博客:基于mysqldump搭建gtid主从。
如果文章帮助您解决了工作难题,您可以帮我点击屏幕上的任意广告,或者赞助少量费用来支持我的持续创作,谢谢~

👍