炼数成金 门户 大数据 Mysql 查看内容

GTID!MySQL复制中的核武器

2018-3-27 15:48| 发布者: 炼数成金_小数| 查看: 19054| 评论: 0|来自: 今日头条

摘要: GTID又叫全局事务ID(Global Transaction ID),是一个已提交事务的编号,并且是一个全局唯一的编号。MySQL5.6版本之后在主从复制类型上新增了GTID复制。GTID是由server_uuid和事务id组成的,即GTID = server_uuid:t ...

SQL Java MySQL Hadoop 服务器 模式

今儿的这篇博文,可以让大家快速了解GTID特性,并能灵活地运用到生产环境中,希望对大家有帮助。

GTID原理介绍
GTID又叫全局事务ID(Global Transaction ID),是一个已提交事务的编号,并且是一个全局的编号。MySQL5.6版本之后在主从复制类型上新增了GTID复制。

GTID是由server_uuid和事务id组成的,即GTID = server_uuid:transaction_id。 server_uuid是在数据库启动过程中自动生成的,每台机器的server-uuid不一样。uuid存放在数据目录的auto.cnf文件下。而transaction_id就是事务提交时由系统顺序分配的一个不会重复的序列号。

GTID存在的价值
(1)GTID使用master_auto_position=1代替了基于binlog和position号的主从复制搭建方式,更便于主从复制的搭建。

(2)GTID可以知道事务在最开始是在哪个实例上提交的。

(3)GTID方便实现主从之间的failover,再也不用不断地去找position和binlog 了。

主从复制中GTID的管理与维护
GTID带来最方便的一点就是主从复制的搭建过程了。它跟异步复制、半同步复制类似,只不过不再利用传统复制模式的binlog文件和position号了,而是在从库“change master to”时使用master_auto_position=1的方式进行搭建,这就让操作变得更加方便和可靠。

GTID搭建过程中的注意事项

主从库需要设置的参数如下。

主库配置:
gtid_mode=onenforce_gtid_consistency=onlog_bin=on
server-id不能与从库一样。

binlog_format=row

从库配置:
gtid_mode=onenforce_gtid_consistency=onlog_slave_updates=1
虽然在MySQL5.7版本之后可以关闭掉log_slave_updates,使用gtid_executed这张表。但还是建议在从库中开启。server-id不能与主库一样。

配置好参数之后,主库也创建了复制账号,如果是新搭建的主从环境,就可以直接在从库就可以执行change master to语句了。如果是已经运行了一段期间的主库,还需要利用备份方式从主库“dump”出数据到从库中,先完成基于某个点的GTID复制,然后从库从那个点之后再开始追主库。利用mysqldump备份,备份后的文件中会有SET @@GLOBAL.GTID_PURGED= *,利用xtrabackup工具备份,备份后的文件中会直接记录需要跳过的GTID。启动复制之后,从库会直接跳过已经执行过GTID的范围,直接从主库获取新的GTID信息。

在主库执行show master status命令,通过Executed_Gtid_Set来查看执行过的GTID。


在MySQL5.7版本之后,gtid_executed这个值持久化了。在MySQL库下新增了一张表gtid_executed:


该表会记录已经执行的GTID集合的信息,有了这张表,就不用再像MySQL5.6版本时,必须开启log_slave_updates参数,从库才可以进行复制。GTID信息会保存在gtid_executed表中,可以关闭从库的binlog,节约binlog的记录开销。在执行reset master时,会清空表内所有的数据。

MySQL5.7还有一个参数gtid_executed_compression_period,用来控制gtid_executed表的压缩。该参数默认值为1000,意味着表压缩在执行完1000个事务之后开始。


从MySQL5.7.6开始,gtid_mode支持动态修改,gtid_mode可取值为:

OFF—不支持GTID的事务;

OFFPERMISSIVE—新的事务是匿名的,同时允许复制的事务可以是GTID,也可以是匿名的;

ON PERMISSIVE—新的事务使用GTID,同时允许复制的事务可以是GTID,也可以是匿名的;

ON—支持GTID的事务。

在生产环境中,可能有把传统复制改为GTID的复制模式的需求。这里特意强调一点,gtidmode虽然支持动态修改,但不支持跳跃式修改。从ON PERMISSIVE修改为OFF是不可以的。下面会有实验来展示传统复制与GTID复制之间的切换过程。

在从库上可通过show slave status命令来获取接收的gtid(retrieve_gtid_set)和执行的gtid(execute_gtid_set)。

GTID复制与传统复制的切换
前面已经搭建好了MySQL5.7版本的GTID复制模式,下面先来操作从GTID复制模式切换为传统复制模式的过程。

环境介绍:主库为192.168.56.101,从库为192.168.56.102。

当前主从状态展示。


实施过程如下:
(1)先在从库中执行stop slave,停掉主从复制。然后调整为传统复制模式,让master_auto_position=0。

执行如下命令:
CHANGE MASTER TO master_auto_position=0,Master_Host='192.168.56.101',MASTER_USER='bak',MASTER_PASSWORD='bak123','Master_Log_File='mysql-binlog.000002',MASTER_LOG_POS=1141;

执行完成之后,开启复制功能start slave。

针对上面的技术我特意整理了一下,有很多技术不是靠几句话能讲清楚,所以干脆找朋友录制了一些视频,很多问题其实答案很简单,但是背后的思考和逻辑不简单,要做到知其然还要知其所以然。如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring,MyBatis,Netty源码分析的朋友可以加我的Java进阶群:582505643,群里有阿里大牛直播讲解技术,以及Java大型互联网技术的视频免费分享给大家。

(2)需要在主从服务器上同时调整GTID模式为on_permissive。


(3)需要在主从服务器上同时调整GTID模式为off_permissive。


(4)需要在主从服务器上同时关闭GTID功能。


(5)然后把gtid_mode=off和enforce_gtid_consistency=off写入配置文件my.cnf中。下次重启直接生效。

(6)测试是否切换成功。

首先向主库的zs库下的tt表中插入一条数据:


查看从库,这条数据同步成功。


然后在从库中执行show slave status查看主从复制状态,发现GTID的值没有增加,证明切换成功:


然后再操作从传统复制模式切换为GTID复制模式的过程。

实施过程如下:
(1)在主从库上同时修改参数enforce_gtid_consistency=warn,确保在error log中不会出现警告信息。如果有,需要先修复,才能往后继续执行。


(2)在主从服务器上把enforce_gtid_consistency改为on,保证GTID的一致性。


(3)在主从服务器上同时调整GTID模式为off_permissive。


(4)在主从服务器上同时调整GTID模式为on_permissive。


(5)确认从库的Ongoing_anonymous_transaction_count参数是否0,如果为0,意味着没有等待的事务,可以直接进行下一步操作了。


(6)在主从库上同时设置gtid_mode=on。


查看GTID参数设置,目前都是开启状态。


(7)把传统复制模式改为GTID复制。先要把原有的传统复制停掉,执行stop slave操作,然后再执行change master to master_auto_position=1。

针对上面的技术我特意整理了一下,有很多技术不是靠几句话能讲清楚,所以干脆找朋友录制了一些视频,很多问题其实答案很简单,但是背后的思考和逻辑不简单,要做到知其然还要知其所以然。如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring,MyBatis,Netty源码分析的朋友可以加我的Java进阶群:582505643,群里有阿里大牛直播讲解技术,以及Java大型互联网技术的视频免费分享给大家。

执行完stop slave,查看当前主从的状态为:


然后再执行change master to master_auto_position=1,开启主从复制start slave。

(8)验证是否切换成功。

首先向主库的zs库下的tt表中插入一条数据:


查看从库,这条数据同步成功。


然后在从库中执行show slave status查看主从复制状态,发现GTID的值增加了。证明开启了GTID复制方式,切换成功。


GTID使用中的限制条件
GTID复制是针对事务来说的,一个事务只对应一个GTID,好多的限制就在于此。

(1)不能使用create table table_name select * from table_name。

(2)在一个事务中既包含事务表的操作又包含非事务表。

(3)不支持CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE语句操作。

(4)使用GTID复制从库跳过错误时,不支持执行该sql_slave_skip_counter参数的语法

欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括:Java,C/C++,Python,PHP,Ruby,shell等各种语言开发经验交流,各种框架使用,外包项目机会,学习、培训、跳槽等交流
QQ群:26931708

Hadoop源代码研究群
兴趣范围包括:Hadoop源代码解读,改进,优化,分布式系统场景定制,与Hadoop有关的各种开源项目,总之就是玩转Hadoop
QQ群:288410967 

鲜花

握手

雷人

路过

鸡蛋

相关阅读

最新评论

热门频道

  • 大数据
  • 商业智能
  • 量化投资
  • 科学探索
  • 创业

即将开课

 

GMT+8, 2018-12-15 14:51 , Processed in 0.140147 second(s), 24 queries .