共计 6216 个字符，预计需要花费 16 分钟才能阅读完成。
本篇内容主要讲解“Mysql 5.7 中 Gtid 带来的运维改变分析”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“Mysql 5.7 中 Gtid 带来的运维改变分析”吧!
一、如何跳过一个事物
和传统基于位置的主从不同，如果从库报错我们需要获得从库执行的最后一个事物，方法有如下：
show slave status \G 中的 Executed_Gtid_Set。
show global variables like %gtid% 中的 gtid_executed。
show master status; 中的 Executed_Gtid_Set。
然后构建一个空事物如下：
stop slave ;
set gtid_next= 4a6f2a67-5d87-11e6-a6bd-000c29a879a3:34
begin;commit;
set gtid_next= automatic
start slave ;如果是多个如下：
stop slave ;
set gtid_next= 89dfa8a4-cb13-11e6-b504-000c29a879a3:3
begin;commit;
set gtid_next= 89dfa8a4-cb13-11e6-b504-000c29a879a3:4
begin;commit;
set gtid_next= automatic
start slave ;二、mysqldump 导出行为的改变
使用 mysqldump 受到选项 set-gtid-purged=AUTO 的影响，假如我们在 Gtid 开启和关闭的情况下使用如下语句导出数据：
mysqldump --single-transaction --master-data=2 -R -E --triggers --all-databases在 Gtid 开启的情况下会多如下设置：
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= ec9bdd78-a593-11e7-9315-5254008138e4:1-105为什么要这么设置呢？因为如果做基于 Gtid 的主从，是否生成 binlog 就意味着在导入数据的时候是否基于本地数据库生成新的 Gtid 事物，显然这是不合理的，所以将 SQL_LOG_BIN 设置为 0 是必须的。接着 GTID_PURGED 被设置为备份时刻已经执行过的 Gtid 事物，如前文第五节源码剖析设置 GTID_PURGED 会设置三个地方的 Gtid 如下:
mysql.gtid_executed 表
gtid_purge 变量
gtid_executed 变量
看起来是合理的，但是如果这里忽略了整个 mysql.gtid_executed 表是 innodb 表，导入过程中某些版本 (已知 percona 5.7.14，5.7.17) 会重新删除和建立，因此通过 GTID_PURGED 设置的 mysql.gtid_executed 表会重新改变，重启数据库后需要读取 mysql.gtid_executed 表可能获得错误 Gtid 集合导致复制错误。这也为我的故障案例埋下了伏笔，案例中在详细描述。
当然也可以使用 –set-gtid-purged=OFF 选项来告诉 mysqldump 不需要加入 SQL_LOG_BIN= 0 和 GTID_PURGED，但是初始化搭建基于 Gtid 的主从一定不要设置为 OFF。下面是这个选项的含义。
--set-gtid-purged[=name]
Add SET @@GLOBAL.GTID_PURGED to the output. Possible
values for this option are ON, OFF and AUTO. If ON is
used and GTIDs are not enabled on the server, an error is
generated. If OFF is used, this option does nothing. If
AUTO is used and GTIDs are enabled on the server, SET
@@GLOBAL.GTID_PURGED is added to the output. If GTIDs
are disabled, AUTO does nothing. If no value is supplied
then the default (AUTO) value will be considered.三、5.7 中搭建基于 Gtid 的主从
这里存在一个注意点，也是我案例中会提到的。我们还是直接说步骤
注意主备库必须开启 Gtid 和设置好 server_id
enforce_gtid_consistency = ON
gtid_mode = ON
server_id = 9910
binlog_format = row
同时主备库都开启 binlog 如果不设置级联从库，从库不要设置 log_slave_updates 参数。
这是最合理的设置。
建立复制用户
CREATE USER repl @ % IDENTIFIED BY test123
GRANT REPLICATION SLAVE ON *.* TO repl @ % ;导出数据
mysqldump --single-transaction --master-data=2 -R -E --triggers --all-databases test.sql
从库导入数据
source 即可。
从库执行 reset master 语句
这一步主要防止 gtid_executed 被更改过。这个问题在在 percona 5.7.14 5.7.17 存在但是在 percona 5.7.15 5.7.19 又不存在。所以为了安全还是执行下面的两步。
reset master；
提取 GTID_PURGED，并且执行
使用 head -n 40 命令可以快速的得到比如我这里的
--
-- GTID state at the beginning of the backup
SET @@GLOBAL.GTID_PURGED= ec9bdd78-a593-11e7-9315-5254008138e4:1-21执行
SET @@GLOBAL.GTID_PURGED= ec9bdd78-a593-11e7-9315-5254008138e4:1-21语句即可，完成本部分 mysql.gtid_executed 表会重构。
使用 MASTER_AUTO_POSITION 建立同步
change master to
master_host= 192.168.99.41 ,
master_user= repl ,
master_password= test123 ,
master_port=3310,
MASTER_AUTO_POSITION = 1;启动 slave
start slave四、5.7 中 Gtid 的主从的切换
切换中必须要确认从库 (新主库) 没有做过本地的事物，如果做过，否则切换主库 (新从库) 需要拉取这一部分的 Gtid 事物，如果这些 binlog 已经不存在了那么势必会报错。这种情况下还是从建从库吧。那么我们来说正常的切换步骤。
从库(新主库)
stop slave;
reset slave all;主库(新从库)
change master to
master_host= 192.168.99.40 ,
master_user= repl ,
master_password= test123 ,
master_port=3310,
MASTER_AUTO_POSITION = 1;
start slave;
实际就这么简单，从库 (新主库) 会生成自己的 Gtid 事物，新主库接受到后执行即可。此时会出现如下有两个 server_uuid 对应的 Gtid，如下的 gtid_executed
mysql show global variables like %gtid%
+----------------------------------+-------------------------------------------------------------------------------------+
| Variable_name | Value |
+----------------------------------+-------------------------------------------------------------------------------------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | ON |
| gtid_executed | 31704d8a-da74-11e7-b6bf-525400a7d243:1-9,
ec9bdd78-a593-11e7-9315-5254008138e4:1-25 |
| gtid_executed_compression_period | 1000 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | ec9bdd78-a593-11e7-9315-5254008138e4:1-25 |
| session_track_gtids | OFF |
+----------------------------------+-------------------------------------------------------------------------------------+总的说来如果要作为的切换的从库，不要在从库本地做任何事物。如果确实要做比如加索引等不影响数据的操作可以是使用如下：
mysql set sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)
mysql create index test_jjj on jjj(id);
Query OK, 0 rows affected (0.42 sec)
Records: 0 Duplicates: 0 Warnings: 0这样也是不会增加本地 Gtid 的。
五、在线修改 Gtid 模式
这是 5.7.6 以后实现的功能其主要依赖了我们前面分析的 Previous gtid Event 以及参数 gtid_mode 新加入的 2 个值。我们具体来看看 gitd_mode 各个值的含义：
OFF(0): Both new and replicated transactions must be anonymous.(生成的是匿名事物，slave 也只能应用匿名事物)
OFF_PERMISSIVE:(1) New transactions are anonymous. Replicated transactions can be either
anonymous or GTID transactions.(生成的是匿名事物，slave 可以应用匿名和 GTID 事物)
ON_PERMISSIVE(2): New transactions are GTID transactions. Replicated transactions can be either
anonymous or GTID transactions.(生成的是 GTID 事物，slave 可以应用匿名和 GTID 事物)
ON(3): Both new and replicated transactions must be GTID transactions(生成的是 GTID 事物，slave 也只能应用 GTID 事物)
注意每次修改值必然导致一次 binlog 的切换，如果发生 binlog 删除也能够依托 Previous gtid Event 快速准确的找到 gtid_purged(Gtid_state.lost_gtids)。
在线启动
主库 / 从库执行
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;
确定事物都支持 gtid，不会在 err log 中出现警告如下：
2017-02-26T22:35:24.322055Z 55 [Warning] Statement violates GTID consistency: CREATE TABLE … SELECT.
主库 / 从库执行
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;主库 / 从库执行
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;生成的是匿名事物，slave 可以应用匿名和 GTID 事物
主库 / 从库执行
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;生成的是 GTID 事物，slave 可以应用匿名和 GTID 事物
主库 / 从库执行
确定已经没有匿名的事物
SHOW GLOBAL STATUS LIKE ONGOING_ANONYMOUS_TRANSACTION_COUNT
同时确认从库
Retrieved_Gtid_Set
Executed_Gtid_Set
正常增长
到这一步实际上 gtid 事物已经开始使用了。
主库 / 从库执行
SET @@GLOBAL.GTID_MODE = ON;从库执行
stop slave;CHANGE MASTER TO MASTER_AUTO_POSITION = 1;start slave;
主库 / 从库执行
修改配置文件 my.cnf，将参数的更改加入到配置文件
在线关闭
从库执行
stop slave;记录从库执行状态值
Exec_Master_Log_Pos: 7631438
Relay_Master_Log_File: bin_log.000016执行
CHANGE MASTER TO MASTER_AUTO_POSITION = 0,
MASTER_LOG_FILE = bin_log.000016 ,
MASTER_LOG_POS = 7631438
start slave;
主库 / 从库执行
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;生成的是 GTID 事物，slave 可以应用匿名和 GTID 事物
主库 / 从库执行
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;生成的是匿名事物，slave 可以应用匿名和 GTID 事物
从库执行
等待从库
Retrieved_Gtid_Set
Executed_Gtid_Set
不再变动。
完成这一步实际上 GTID 事物已经没有生成和应用了
主库 / 从库执行
SET @@GLOBAL.GTID_MODE = OFF;主库 / 从库执行
修改配置文件 my.cnf，将参数的更改加入到配置文件
到此，相信大家对“Mysql 5.7 中 Gtid 带来的运维改变分析”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
