mysqlGTID主从复制
mysqlGTID主从复制
文章目录
- mysqlGTID主从复制
-
- 1:GTID概念介绍
- 2：GTID和Binlog的关系
- 3：gtid工作原理
- 4：gtid主从配置
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