Mysql 5.7中Gtid带来的运维改变分析
本篇内容主要讲解“Mysql 5.7中Gtid带来的运维改变分析”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Mysql 5.7中Gtid带来的运维改变分析”吧!
一、如何跳过一个事物和传统基于位置的主从不同，如果从库报错我们需要获得从库执行的最后一个事物，方法有如下：
show slave status \G 中的 Executed_Gtid_Set。
show global variables like '%gtid%'; 中的 gtid_executed 。
show master status;中的Executed_Gtid_Set。
然后构建一个空事物如下：
stopslave;setgtid_next='4a6f2a67-5d87-11e6-a6bd-000c29a879a3:34';begin;commit;setgtid_next='automatic';startslave;
如果是多个如下：
stopslave;setgtid_next='89dfa8a4-cb13-11e6-b504-000c29a879a3:3';begin;commit;setgtid_next='89dfa8a4-cb13-11e6-b504-000c29a879a3:4';begin;commit;setgtid_next='automatic';startslave;二、 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;----GTIDstateatthebeginningofthebackup--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'totheoutput.PossiblevaluesforthisoptionareON,OFFandAUTO.IfONisusedandGTIDsarenotenabledontheserver,anerrorisgenerated.IfOFFisused,thisoptiondoesnothing.IfAUTOisusedandGTIDsareenabledontheserver,'SET@@GLOBAL.GTID_PURGED'isaddedtotheoutput.IfGTIDsaredisabled,AUTOdoesnothing.Ifnovalueissuppliedthenthedefault(AUTO)valuewillbeconsidered.三、5.7中搭建基于Gtid的主从
这里存在一个注意点，也是我案例中会提到的。我们还是直接说步骤
注意主备库必须开启Gtid和设置好server_id
enforce_gtid_consistency=ONgtid_mode=ONserver_id=9910binlog_format=row
同时主备库都开启binlog如果不设置级联从库，从库不要设置log_slave_updates参数。
这是最合理的设置。
建立复制用户
CREATEUSER'repl'@'%'IDENTIFIEDBY'test123';GRANTREPLICATIONSLAVEON*.*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又不存在。所以为了安全还是执行下面的两步。
resetmaster；
提取GTID_PURGED，并且执行
使用head -n 40 命令可以快速的得到比如我这里的
----GTIDstateatthebeginningofthebackup--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建立同步
changemastertomaster_host='192.168.99.41',master_user='repl',master_password='test123',master_port=3310,MASTER_AUTO_POSITION=1;
启动slave
startslave四、5.7中Gtid的主从的切换
切换中必须要确认从库(新主库)没有做过本地的事物，如果做过，否则切换主库(新从库)需要拉取这一部分的Gtid事物，如果这些binlog已经不存在了那么势必会报错。这种情况下还是从建从库吧。那么我们来说正常的切换步骤。
从库(新主库)
stopslave;resetslaveall;
主库(新从库)
changemastertomaster_host='192.168.99.40',master_user='repl',master_password='test123',master_port=3310,MASTER_AUTO_POSITION=1;startslave;
实际就这么简单，从库(新主库)会生成自己的Gtid事物，新主库接受到后执行即可。此时会出现如下有两个server_uuid对应的Gtid，如下的gtid_executed
mysql>showglobalvariableslike'%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>setsql_log_bin=0;QueryOK,0rowsaffected(0.00sec)mysql>createindextest_jjjonjjj(id);QueryOK,0rowsaffected(0.42sec)Records:0Duplicates:0Warnings: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事物
主库/从库执行
确定已经没有匿名的事物
SHOWGLOBALSTATUSLIKE'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
同时确认从库
Retrieved_Gtid_Set
Executed_Gtid_Set
正常增长
到这一步实际上gtid事物已经开始使用了。
主库/从库执行
SET@@GLOBAL.GTID_MODE=ON;
从库执行
stopslave;CHANGEMASTERTOMASTER_AUTO_POSITION=1;startslave;
主库/从库执行
修改配置文件my.cnf，将参数的更改加入到配置文件
在线关闭
从库执行
stopslave;
记录从库执行状态值
Exec_Master_Log_Pos:7631438Relay_Master_Log_File:bin_log.000016
执行
CHANGEMASTERTOMASTER_AUTO_POSITION=0,MASTER_LOG_FILE='bin_log.000016',MASTER_LOG_POS=7631438startslave;
主库/从库执行
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带来的运维改变分析”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
声明：本站所有文章资源内容，如无特殊说明或标注，均为采集网络资源。如若本站内容侵犯了原著者的合法权益，可联系本站删除。
