基于gtid的复制
Ⅰ、GTID的介绍
- global transaction id identifier 全局事务id
- gtid = server_uuid + transaction_id
- server_uuid是全局唯一的,5.6开始才有,表示当前实例的uuid,保存在数据目录中的auto.conf文件中
- transaction_id是自增的
- gtid的作用是替代filename + position
主：show master status;
(root@localhost) [test]> show master status;
+------------+----------+--------------+------------------+----------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------+----------+--------------+------------------+----------------------------------------+
| bin.000006 | 408 | | | d565cde8-0573-11e8-89b2-525400a4dac1:1 |
+------------+----------+--------------+------------------+----------------------------------------+
1 row in set (0.00 sec)
Executed_Gtid_set：server_id:1-xxxx 表示产生了xxx个事务
从：show master status;
Retrieved_Gtid_Set: d565cde8-0573-11e8-89b2-525400a4dac1:1
Executed_Gtid_Set: d565cde8-0573-11e8-89b2-525400a4dac1:1
也能看到事务号
tips：
如果做了A和B做了双主,B上一直在同步A上数据,这时候在B上写入一个事务
A上看下Executed_Gtid_set,会发现有两个值
一个是自己做主当前的事务号,一个是同步的从上的事务号
Ⅱ、GTID的意义
之前的复制基于(file,pos),当主从发生宕机,切换的时候有问题
slave保存的是原master上的(file,pos),无法直接指向新master上的(file,pos)
mha通过relay log来判断(非常有技术性)
gtid实现了真正的全局唯一位置(所有机器上都是统一的)
更容易进行failover操作
举例：
a是master,b c d是slave,a挂了,b做主,c d做change master
此时c d 上的pos却还是a上面的pos,和b没有对应关系,文件名,文件大小,position完全不一样,change不起来
使用gtid的话,b上保存着c和d回放的位置G_a、G_b(b是通过选举出来的,保存着最多的日志)
Ⅲ、gtid配置
[mysqld]
log_bin
gtid_mode = ON
enforce_gtid_consistency = ON
log_slave_updates = 1 5.6必须开,5.7可以不开
tips：
- MySQL5.6必须开启参数log_slave_updates,5.7.6开始无需配置
- MySQL5.6升级到gtid模式需要停机重启
- MySQL5.7.6版本开始可以在线升级gtid模式
- 5.6中gtid用的比较少,最重要的原因在于gtid要么开要么不开,不能做到非gtid升级到gtid
- gtid是一切高可用基础(gr,mha),强烈建议打开,5.6就有了,很成熟了
5.7的gtid_mode可选值
ON 完全打开GTID,如果打开状态的备库接受到不带GTID的事务,则复制中断
ON_PERMISSIVE 可以认为是打开gtid前的过渡阶段,主库在设置成该值后会产生GTID,同时备库依然容忍带GTID和不带GTID的事务
OFF_PERMISSIVE 可以认为是关闭GTID前的过渡阶段,主库在设置成该值后不再生成GTID,备库在接受到带GTID和不带GTID事务都可以容忍
主库在关闭GTID时,执行事务会产生一个Anonymous_Gtid事件,会在备库执行：set @@session.gtid_next='anonymous'
OFF 彻底关闭GTID,如果关闭状态的备库收到带GTID的事务,则复制中断
之前只有ON和OFF
平滑开启gtid
set global gtid_mode = 'off_permissive';
set global gtid_mode = 'on_permissive';
set global enforce_gtid_consistency = 'on';
set global gtid_mode = 'ON';
平滑关闭gtid
stop slave;
set global gtid_mode = 'on_permissive';
set global gtid_mode = 'off_permissive';
change master to master_auto_position = 0;
set global gtid_mode = 'OFF';
set global enforce_gtid_consistency = 'off';
start slave;
主从上都依次敲下来
Ⅳ、简单说下搭建过程
大同小异,全备+binlog
开启gtid后,mysqldump备份单库时会报warning,意思是gtid包含所有事务,只备份了单库,忽略即可
用mydumper备份,看下metadata文件,找到gitd：xxxxxx:x-xxx
这玩意等同于mysqldump备份文件中set @@global.gtid_purged='xxxx:x-xxx';
表示这部分gtids对应的事务已经在备份中了,slave在还原备份后复制时,需要跳过这些gtids
reset master; 清空@@GLOBAL.GTID_EXECUTED,不然执行下一步会报错
SET @@GLOBAL.GTID_PURGED = '找出来的位置'
以上操作mysqldump出来的文件导入无需操作,mydumper要手动,因为myloader不执行这个
最后一把change master送给大家
change master to master_host='127.0.0.1', master_port=3306, master_user='rpl', master_password='123', MASTER_AUTO_POSITION=1;
start slave;
tips:
- binlog文件中会有两个关于gtid的event——Previous_gtids和Anonymous_Gtid
- 通过扫描binlog中的gtid值,可以知道gtid与filename-pos的对应关系,如果binlog很大,扫描量也很大,所以用Previous_gtid来记录之前一个binlog文件中最大的gtid
- 如果要找的gtid比previous_gtids大,就扫描当前文件,反之扫之前的文件,依次类推
- binlog在rotate的时候,是知道当前最大gtid的,将该值,写入下个binlog的文件头,即Previous_gtids
Ⅴ、GTID复制中处理报错小技巧
这里模拟一个1062错误即可,不演示
报错会告诉你对应的gtid
操作步骤如下：
- 我们将gtid_next指向报错的gtid
报错中没有gtid,则用Retrieved_Gtid_Set和Executed_Gtid_Set对比一下就知道哪个事务执行出错了
(root@localhost) [(none)]> set gtid_next='xxxxxx:xxxx'; # 设置为之前失败的那个GTID的值
Query OK, 0 rows affected (0.00 sec)
- 执行一个空事务
(root@localhost) [(none)]> begin;commit;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
- 将gtid_next还原为automatic
(root@localhost) [(none)]> set gtid_next="automatic";
Query OK, 0 rows affected (0.00 sec)
(root@localhost) [(none)]> stop slave;
Query OK, 0 rows affected (0.01 sec)
(root@localhost) [(none)]> start slave;
Query OK, 0 rows affected (0.07 sec)
该操作类似于sql_slave_skip_counter,只是跳过错误,不能保证数据一致性,需要人工介入,固强烈建议从机开启read_only=1
Ⅵ、GTID的限制
- 在开启GTID后,不能在一个事物中使用创建临时表的语句
- 在开启GTID后,不能使用create table select ... 的语法来创建表了,因为这其实是多个事物了,GTID没法对应
