GTID概念

GTID即全局事务ID (global transaction identifier), 其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID。GTID最初由google实现，官方MySQL在5.6才加入该功能。mysql主从结构在一主一从情况下对于GTID来说就没有优势了，而对于2台主以上的结构优势异常明显，可以在数据不丢失的情况下切换新主。使用GTID需要注意: 在构建主从复制之前，在一台将成为主的实例上进行一些操作（如数据清理等），通过GTID复制，这些在主从成立之前的操作也会被复制到从服务器上，引起复制失败。也就是说通过GTID复制都是从最先开始的事务日志开始，即使这些操作在复制之前执行。比如在server1上执行一些drop、delete的清理操作，接着在server2上执行change的操作，会使得server2也进行server1的清理操作。

GTID实际上是由UUID+TID (即transactionId)组成的。其中UUID(即server_uuid) 产生于auto.conf文件，是一个MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增，所以GTID能够保证每个MySQL实例事务的执行（不会重复执行同一个事务，并且会补全没有执行的事务）。GTID在一组复制中，全局唯一。

mysql> show master status;
+------------------+----------+--------------+------------------+------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000001 |      620 |              |                  | ec4eca2c-10b5-11ed-b6b8-000c29fb2070:1-2 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)GTID:ec4eca2c-10b5-11ed-b6b8-000c29fb2070:1-2
UUID:ec4eca2c-10b5-11ed-b6b8-000c29fb2070
TID:1-2
在整个复制架构中GTID是不变化的,即使在多个连环主从中也不会变。

了解了GTID的格式，通过UUID可以知道这个事务在哪个实例上提交的。通过GTID可以极方便的进行复制结构上的故障转移，新主设置

假设现在有server1、server2、server3三台数据库，server1为主，server2、server3为从，如图

现在Server1(Master)崩溃，根据从库上show slave status获得Master_log_File/Read_Master_Log_Pos的值，Server2(Slave)已经和主库同步，Server3(Slave)没有和主库同步。这时要把Server2提升为主，Server3变成Server2的从。那在Server3上执行change的时候需要做一些计算。

这个问题在5.6的GTID出现后，就显得非常的简单。由于同一事务的GTID在所有节点上的值一致，那么根据Server3当前停止点的GTID就能定位到Server2上的GTID。甚至由于MASTER_AUTO_POSITION功能的出现，我们都不需要知道GTID的具体值，直接使用change master to master_host=‘xxx’,master_auto_position命令就可以直接完成failover的工作。

GTID和binlog的关系

GTID在binlog中的结构

binlog
版本信息，binlog metadata，etc
previous_gtid_log_event
GTID event
GTID event
…

GITD event结构
Previous_gtid_log_event
Previous_gtid_log_event 在每个binlog 头部都会有，每次binlog rotate的时候存储在binlog头部，Previous-GTIDs在binlog中只会存储在这台机器上执行过的所有binlog，不包括手动设置gtid_purged值。

假设有4个binlog: bin.001,bin.002,bin.003,bin.004
bin.001 : Previous-GTIDs=empty; binlog_event有: 1-40
bin.002 : Previous-GTIDs=1-40; binlog_event有: 41-80
bin.003 : Previous-GTIDs=1-80; binlog_event有: 81-120
bin.004 : Previous-GTIDs=1-120; binlog_event有: 121-160
假设现在我们要找GTID=$A，那么MySQL的扫描顺序为从最后一个binlog也就是bin.004开始扫描

bin.004的Previous-GTIDs=1-120，如果$A>Previous-GTIDs，那么肯定在bin.004中
bin.004的Previous-GTIDs=1-120，如果$A包含在Previous-GTIDs中，那么继续对比上一个binlog文件 bin.003,然后再循环前面2个步骤，直到找到为止
GTID相关参数

参数	comment
gtid_executed	执行过的所有GTID
gtid_purged	丢弃掉的GTID
gtid_mode	GTID模式
gtid_next	session级别的变量，下一个gtid
gtid_owned	正在运行的GTID
enforce_gtid_consistency	保证GTID安全的参数

开启GTID的条件

gtid_mode=on (必选)
enforce-gtid-consistency=1 （必选）
log_bin=mysql-bin （可选） #高可用切换，最好开启该功能
log-slave-updates=1 （可选） #高可用切换，最好打开该功能

GTID工作原理

从服务器连接到主服务器之后，把自己执行过的GTID (Executed_Gtid_Set: 即已经执行的事务编码) 、获取到的GTID (Retrieved_Gtid_Set: 即从库已经接收到主库的事务编号) 发给主服务器，主服务器把从服务器缺少的GTID及对应的transactions发过去补全即可。当主服务器挂掉的时候，找出同步最成功的那台从服务器，直接把它提升为主即可。如果硬要指定某一台不是最新的从服务器提升为主，先change到同步最成功的那台从服务器，等把GTID全部补全了，就可以把它提升为主了。

GTID是MySQL 5.6的新特性，可简化MySQL的主从切换以及Failover。GTID用于在binlog中唯一标识一个事务。当事务提交时，MySQL Server在写binlog的时候，会先写一个特殊的Binlog Event，类型为GTID_Event，指定下一个事务的GTID，然后再写事务的Binlog。主从同步时GTID_Event和事务的Binlog都会传递到从库，从库在执行的时候也是用同样的GTID写binlog，这样主从同步以后，就可通过GTID确定从库同步到的位置了。也就是说，无论是级联情况，还是一主多从情况，都可以通过GTID自动找点儿，而无需像之前那样通过File_name和File_position找点了。

工作流程

master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。
slave端的i/o 线程将变更的binlog，写入到本地的relay log中。
sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。
如果有记录，说明该GTID的事务已经执行，slave会忽略。
如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。
在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

GTID主从配置

主数据库IP：192.168.159.100 mysql-5.7
从数据库IP：192.168.159.139 mysql-5.7

主库配置

[root@100 ~]# vim /etc/my.cnf       //添加以下内容
log-bin=mysql-bin
server-id=10
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=on[root@100 ~]# service mysqld restart
Shutting down MySQL.. SUCCESS!
Starting MySQL. SUCCESS!

从库配置

[root@139 ~]# vim /etc/my.cnf       //添加以下内容
server-id=20
relay-log=mysql-relay
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=on
read_only=on
master-info-repository=TABLE
relay-log-info-repository=TABLE[root@139 ~]# service mysqld restart
Shutting down MySQL.. SUCCESS!
Starting MySQL. SUCCESS!

在主库授权用户

mysql> grant replication slave on *.* to 'slave'@'192.168.159.139' identified by '123456';
Query OK, 0 rows affected, 1 warning (0.00 sec)

在从库设置要同步的主库信息

mysql> change master to master_host='192.168.159.100',master_user='slave',master_password='123456',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.01 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 eventMaster_Host: 192.168.159.100Master_User: slaveMaster_Port: 3306Connect_Retry: 60Master_Log_File: mysql-bin.000001Read_Master_Log_Pos: 452Relay_Log_File: mysql-relay.000002Relay_Log_Pos: 665Relay_Master_Log_File: mysql-bin.000001Slave_IO_Running: Yes     //此处要为yesSlave_SQL_Running: Yes     //此处要为yes

测试

//在主库进行一些操作
mysql> insert into test1(id,name,age) values(6,'six',21);
Query OK, 1 row affected (0.00 sec)mysql> update test1 set age = 28 where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0mysql> select * from test1;
+----+-------+------+
| id | name  | age  |
+----+-------+------+
|  1 | one   |   28 |
|  2 | two   |   22 |
|  3 | three |   25 |
|  4 | four  |   23 |
|  5 | five  |   26 |
|  6 | six   |   21 |
+----+-------+------+
6 rows in set (0.00 sec)//在从库查看是否同步
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -ADatabase changed
mysql> select * from test1;
+----+-------+------+
| id | name  | age  |
+----+-------+------+
|  1 | one   |   28 |
|  2 | two   |   22 |
|  3 | three |   25 |
|  4 | four  |   23 |
|  5 | five  |   26 |
|  6 | six   |   21 |
+----+-------+------+
6 rows in set (0.00 sec)

MySQL主从之GTID主从相关推荐

美团面试官：MySQL主备、主从、读写分离你知道多少？
一.MySQL主备的基本原理在状态1中,客户端的读写都直接访问节点A,而节点B是A的备库,只是将A的更新都同步过来,到本地执行.这样可以保持节点B和A的数据是相同的.当需要切换的时候,就切成状态2. ...
mysql 5.7 gtid 主从_MySQL 5.7基于GTID的主从复制实践
GTID是基于mysql事务实现的,如果对mysql事务没啥概念的话,建议先看看不在单独说明如何搭建mysql单点请参考然后再看这个gtid的现在有这样一个需求: 主1mysql 是个单点的m ...
mysql 5.6 gtid 主从_MySQL5.6基于GTID的主从复制
一.GTID简介 MySQL 5.6 的新特性之一,是加入了全局事务 ID (GTID) 来强化数据库的主备一致性,故障恢复,以及容错能力. 什么是GTID? 官方文档:http://dev.mysq ...
mysql主从之slave-skip-errors和sql_slave_skip_counter
一般来说,为了保险起见,在主从库维护中,有时候需要跳过某个无法执行的命令,需要在slave处于stop状态下,执行 set global sql_slave_skip_counter=1以跳过命令.但 ...
mysql主原理_mysql 主从配置实现原理
MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ,用于衡量主备之间的复制延迟,但是今天碰到了一个场景,发现 Seconds_Behind ...
mysql一主多从的配置gtid主从配置
mysql一主多从配置&gtid主从配置 mysql一主多从的配置环境: 主数据库 centOS8IP=192.168.147.10 从数据库从库1: centOS8IP=192.168. ...
MySQL主从——GTID主从
1 GTID概念介绍 GTID即全局事务ID (global transaction identifier), 其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID.GTID最初由goog ...
MySQL主从配置和gtid主从配置
文章目录 1.为什么需要主从复制? 2.什么是mysql的主从复制? 3.GTID的工作原理: 4.GTID与传统主从复制的区别是什么 5.mysql主从 5. 1mysql主从配置 5.1.1 确保 ...
mysql主从配置 GTID 主从配置
mysql一主多从配置查看主库的数据库 [root@localhost ~]# mysql -P3306 -h127.0.0.1 -e 'show databases;' +------------ ...

MySQL主从之GTID主从

文章目录

GTID概念

GTID工作原理

GTID主从配置

MySQL主从之GTID主从相关推荐

最新文章

热门文章