mysqlGTID主从复制

mysqlGTID主从复制

1:GTID概念介绍

GTID为全局事务标识符，用于记录不同的事务。 GTID主要由两部分组成：一部分是服务的UUID，保存在MySQL数据目录的auto.cnf文件中；而另一部分就是事务的ID，会随着事务的增加而递增。GTID模式下使用新的复制协议COM_BINLOG_DUMP_GTID进行复制，在配置主从复制集群时，可以配置系统使用GTID来自动识别二进制文件中不同事务的位置，这样可以避免再配置过程中产生不必要的错误

2：GTID和Binlog的关系

GTID在binlog中的结构

GTID event 结构

Previous_gtid_log_event
Previous_gtid_log_event 在每个binlog 头部都会有每次binlog rotate的时候存储在binlog头部Previous-GTIDs在binlog中只会存储在这台机器上执行过的所有binlog，不包括手动设置gtid_purged值。换句话说，如果你手动set global gtid_purged=xx； 那么xx是不会记录在Previous_gtid_log_event中的。

GTID和Binlog之间的关系是怎么对应的呢? 如何才能找到GTID=? 对应的binlog文件呢？
假设有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=140 > Previous-GTIDs,那么肯定在bin.004中

bin.004的Previous-GTIDs=1-120，如果$A=88 包含在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     （可选）       #高可用切换，最好打开该功能

3：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找点儿了。

简而言之，GTID的工作流程为：

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

4：gtid主从配置

数据库角色	IP	应用与系统版本
主数据库	192.168.226.139	centos8
从数据库	192.168.226.158	redhat8

配置主数据库配置文件如下：

vim /etc/my.cnf
log-bin=g
server-id=2000
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=on

配置从数据库配置文件如下

vim /etc/my.cnf
server-id=2001
relay-log=myrelay
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=on
read_only=on
master-info-repository=TABLE
relay-log-info-repository=TABLE

关闭主从数据库的防火墙和selinux

[root@master local]# systemctl stop firewalld.service
[root@master local]# vim /etc/selinux/config
SELINUX=disable
[root@master local]# setenforce 0
[root@slave local]# systemctl stop firewalld.service
[root@slave local]# vim /etc/selinux/config
SELINUX=disable
[root@slave local]# setenforce 0

登录主数据库授权复制用户

mysql> grant replication slave on *.* to 'xuanning'@'192.168.226.158' identified by 'xuanning123';
Query OK, 0 rows affected, 1 warning (0.01 sec)

到从库开启同步

mysql> change master to master_host='192.168.226.139', \
    -> master_port=3306, \
    -> master_user='xuanning', \
    -> master_password='xuanning', \
    -> master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> start slave;
Query OK, 0 rows affected (0.01 sec)
mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.226.139
                  Master_User: xuanning
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql_bin.000001
          Read_Master_Log_Pos: 441
               Relay_Log_File: myrelay.000002
                Relay_Log_Pos: 654
        Relay_Master_Log_File: mysql_bin.000001
             Slave_IO_Running: Yes  //此处必须要为yes
            Slave_SQL_Running: Yes