【复制系列】基于 GTID 的复制

GTID复制详解

最新推荐文章于 2025-12-12 11:13:55 发布

转载最新推荐文章于 2025-12-12 11:13:55 发布 · 100 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://my.oschina.net/starglm/blog/1377591

文章标签：

#数据库 #python #开发工具

本文深入解析GTID（全局事务标识符）的基础概念及其在MySQL复制中的应用，包括基于GTID的复制搭建流程、添加新从库的方法及GTID相关参数说明。

2019独角兽企业重金招聘Python工程师标准>>>

前言

上篇文章写了传统复制的原理和搭建，本文将主要写一些基于GTID的复制，主要内容有：GTID基础知识、基于GTID复制的搭建、添加一个新从库的操作、一些GTID相关参数的解释。

现在常用的复制也是基于GTID的复制+binlog的格式为Row。

GTID基础知识

GTID的概念：

GTID 即事务的全局唯一编号，每一个事务都会使用一个唯一的GTID来标识。
GTID和事务都会被写到binlog文件中。
GTID由server-uuid:seq_num组成。server-uuid是每个MySQL的唯一标识；seq_num是一个序列编号。

GTID的复制：

使用GTID复制时，在主和从都要开启GTID。

在主库，由GTID标识事务，事务写入binlog并提交后，IO线程将该事务写到从库的relay log中，从库有一个变量gtid_next，它会存放将要执行的事务gtid，在SQL线程执行该事务之前，系统会通过检查mysql.gtid_executed表（在MySQL5.7中才出现的该表，在MySQL5.6中依赖于binlog和gtid_purge记录执行过的事务gtid），来判断该gtid是否被执行过，确定未被执行过，才会执行，这样也保证了数据的一致性。

使用GTID时的限制：

不可以使用create table …… select ……语句。
在事务中不可以包含非事务表（比如某些表属于myisam）。
在事务中不可以包含创建或删除临时表的操作。
不支持 sql_slave_skip_counter。

基于GTID复制的搭建

机器环境：

以一主一从为例。
Master IP: 172.16.100.100
Slave IP: 172.16.100.101
两机器均已安装MySQL。

配置步骤：

# 主库（master）

在配置文件添加：

# binlog
log-bin = /data/mysql/mysql3306/binlog
binlog_format = row

# GTID
gtid_mode = on
enforce_gtid_consistency = 1

server-id = 1003306

创建一个复制用户

mysql> create user 'repl'@'172.16.100.101' identified by '123123';
mysql> grant replication slave on *.* to 'repl'@'172.16.100.101' ;  
mysql> flush privileges;

# 从库（slave）

在配置文件添加：

# binlog
log-bin = /data/mysql/mysql3306/binlog
binlog_format = row

# GTID
gtid_mode = on
enforce_gtid_consistency = 1

server-id = 1013306

建立连接，开始复制：

mysql> change master to master_host='172.16.100.100',master_port=3306,master_user='repl',master_password='repl',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.03 sec)

mysql> start slave;
Query OK, 0 rows affected (0.02 sec)

至此，基于GTID的复制搭建完成！

添加一个新从库的操作

主要思想：

在主库进行备份，然后将备份在从库中执行，最后让新从库和主库建立复制连接，同步数据。

# 备份
[root@os mysql3306]# mysqldump  -uroot –p  --single-trasation  --master-date=2 --all-databases   >mysql3306100.sql

[root@os mysql3306]# vim mysql3306100.sql
……
SET @@GLOBAL.GTID_PURGED='5e037a78-834a-11e6-bc00-000c2966173a:1-19';
……
# 注：备份文件中的GLOBAL.GTID_PURGED 表示 备份开始的时刻show master status 中的Executed_Gtid_Set字段内容，即那一刻已经执行的那些事务的GTID集，方便将备份导入从库之后，可以从那个已有的事务自动继续同步。

# 建立主从连接，开始同步数据（在从库操作）
mysql> change master to master_host='172.16.100.100',master_port=3306,master_user='repl',master_password='repl',master_auto_position=1;

mysql> start slave;

一些GTID相关参数解释

gtid_mode=on # 开启GTID，即为使用GTID来标识事务
- OFF 即：不产生GTID，slave只接受不带GTID的事务
- OFF_PERMISSIVE 即：不产生GTID，slave接收不带GTID和带GTID的事务
- ON_PERMISSIVE 即：产生GTID，slave接收不带GTID和带GTID的事务
- ON 即：产生GTID，slave只接受带GTID的事务
enforce-gtid-consistency=1 # 开启之后强制使用GTID一致
- OFF 即：不检测是否有GTID不支持的语句和事务
- WARN 即：当发现不支持的语句或事务是，返回警告，并在error.log中记录警告信息
- ON 即：当发现语句或事务不支持GTID时，返回错误。
- 在线上，从非GTID切换成GTID过程中，可以先设置成WARN，避免直接报错，使复制断掉
log-bin=mysql-bin # 开启binlog日志
log_slave_updates=1 # 在从库开启后，可以将执行的relay-log的数据更新写入的binlog
- 在5.7中，使用GTID，slave可以不开启binlog和log_slave_updates，因为有一个表mysql.gtid_executed，表里面存储了已执行的GTID信息。
- 在5.6中，slave一定要开启binlog和log_slave_updates，需要依靠它来判断事务GTID是否已执行过了。

转载于:https://my.oschina.net/starglm/blog/1377591