binlog group commit中：把prepare_commt_lock（redo里的）去掉了。
https://dev.mysql.com/worklog/找binlog croup commit，启用commit后就没有这个锁了。
以前一次提交一个，现在一次提交一个队列，队列里有3个状态：
crash recovery的话，可能一组事物需要commit。
master：
use zst;
create table zst_1(id int not null ,uname varchar(32) ,primary key(id));
insert into zst_1(id, uname) values(1,’wubx'),(2,'mysql');
Slave
set sql_log_bin=0;
insert into zst_1(id, uname) values(3,’python');
master : insert into zst_1(id, uname) values(3,'java');
主键不能设置varbinary
解决：
set sql_log_bin=0; //禁用gtid，不记录binlog
delete from ssyebch.t1 where 主键列=3;
set sql_log_bin=1;
master：
use zst;
create table zst_1(id int not null ,uname varchar(32) ,primary key(id));
insert into zst_1(id, uname) values(1,’wubx'),(2,'mysql');
insert into zst_1(id, uname) values(3,’python’);
slave:
set sql_log_bin=0;
delete from zst_1 where id=3;
set sql_log_bin=1;
master： update zst_1 set uname=‘java’ where id=3;
原因：sql_thread找不到位置了。
开始找：
relay_master_log_file
通过补数据，解决。
任何一个错误，不允许跳过。->人工干预，写脚本
上边那是delete的1032，还有update的1032错误。
。。。。。。。。。。
1032
use zst;
create table zst_1(id int not null ,uname varchar(32) ,primary key(id));
insert into zst_1(id, uname) values(1,’wubx'),(2,'mysql');
insert into zst_1(id, uname) values(3,’python’);
#等待slave上执行上半部分
slave:
set sql_log_bin=0;
delete from zst_1 where id=3;
set sql_log_bin=1;
delete from zst_1 where id=3;
上边的错误，可以跳过
如果事务里有多个SQL，都跳过吗？这么问题怎么解决啊
delete可以跳过，update的不可以。
如果遇到没见过的错误，->解析binlog，定位位置：
relay_master_log_file, exec_master_log_pos
分析下这个东西为啥在从库上执行不过去。
如果遇到复制类的错误 ->当天晚上要安排主从一致性校验
咋让他们三个S处于绝对一致性的位置？
法1：stop slave until
法2：
Master：
set sql_log_bin=0;
create table zst(id int);
set sql_log_bin=1;
drop table zst;
然后从库都报错了，这样从库就都停到一个位置上了。
s1: show master status；造出 change master语句。
并行复制-> 串行复制
但是S1现在还会报错，因为少了一张表，现在可以跳过这个错，stop slave ; set 或就在S1上创建这个表。
为啥做这样的变更？
1、主库机器很老了，需要下线。->把S2，S3 ->S1
传统类的复制是这样做的，那GTID环境怎么办？
stop slave;change master to S1;
从右边变到左边，
传统复制怎么办？
s1. -> sql_thread执行到的位置
Relay_Master_Log_File: mysql-bin.000016
【管理员】wubx@知数堂(82565387) 21:35:59
Exec_Master_Log_Pos: 219798
stop slave;
分别在S2，S3上执行：
Exec_Master_Log_Pos: 219798
change master to master_host=m ,master_port=N , master_log_file=’mysql-bin.000016’, master_log_pos=219798;
GTID怎么办？直接在S2上change，S3上change。
100分：
如果S1挂了，S2怎么跟Master交互起来？
传统复制里边怎么办？
复制延迟排查
干什么？
->show slave status; exec_master_log_pos看是不是卡住不动了->大事务？或动得很慢。
大事务->到主库上解析relay_master_log_file ，exec_master_log_pos
如果卡住了，看下有没有索引，stop slave卡住了-> 重启mysql，添加索引。
遇到大事务，没索引，重启。
。。。。。。有索引，不要搞大事务。
在从库上建索引，
如果是 一个大表 alter 加索引 或者字段 在主库上搞 从库有延迟,从库抗查询的业务,卡着了 有什么好的办法
statics
ddl搞延迟了，pt-osc，gh-ost
https://github.com/github/gh-ost
主从一致性校验
pt-table-checksum
www.percona.com
-> software ->database tools ->percona
pt-table-checksum –recursion-method=”processlist” \
–replicate=”zst.checksums” \
–host=’172.17.0.2’ \
–port=3306 \
–user=’wubx’ \
–password=’wubxwubx’ \
–databases=zst \
–no-check-binlog-format
只要diff这一列 > 0,就是不一致。
他们是怎么校验呢？
打开general log
再搞一行不一致：
再次校验：
看general_log
REPLACE INTO zst.checksums (db, tbl, chunk, chunk_in
dex, lower_boundary, upper_boundary, this_cnt, this_crc) SELECT ‘zst’, ‘wubx’, ‘1’, NULL, NULL, NULL, COUNT(*) A
S cnt,
把每个trunk做成一个hashcode校验。
COALESCE(LOWER(CONV(BIT_XOR(CAST(CRC32(CONCAT_WS(‘#’, id, convert(c1 using utf8mb4), CONCAT(ISNULL(c )))) AS UNSIGNED)), 10, 16)), 0) AS crc FROM
1zst.wubx /checksum table/
this指的是slave，
先形成一致性快照，
分trunk比较：
1、比较行数是否一致，->this_cnt
2、把所有行进行hash code运算，this_crc
select this_cnt，this_crc from ..
update master_cnt, master_crc
补充：
先去M上找，
找到binlog的last event里的timestamp，再看具体时间，找具体的sql，
测试的话用sysbench，