注:本文来自真实生产案例,感谢网友小豚提供,本人加以故障重现校验。
场景
因想整理一下线上的独立表空间碎片,故使用了pt-online-schema-change在slave从库上执行,目的是怕影响主库的CPU,维护的时候再进行一次主从切换,然后再收缩主库上的表空间碎片。
slave从库上执行的命令如下:
1
2
3
|
# pt-online-schema-change -S /tmp/mysql.sock --alter="engine=innodb"
--no-check-replication-filters --recursion-method=none
--user=root D=
test
,t=sbtest --execute
|
故障
DBA在修改完表结构以后,业务方反馈数据不准确,在排查的过程中发现同步报错1032。
分析
1、主库和从库的binlog格式为ROW
2、pt-online-schema-change在拷贝原表数据时,原表的数据变更会通过触发器insert/updete/delete到临时表_sbtest_new里,完成之后原表改名为_sbtest_old老表,_sbtest_new临时表改为原表sbtest,最后删除_sbtest_old老表。过程如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
Altering `
test
`.`sbtest`...
Creating new table...
Created new table
test
._sbtest_new OK.
Altering new table...
Altered `
test
`.`_sbtest_new` OK.
2016-12-06T12:15:30 Creating triggers...
2016-12-06T12:15:30 Created triggers OK.
2016-12-06T12:15:30 Copying approximately 1099152 rows...
2016-12-06T12:15:54 Copied rows OK.
2016-12-06T12:15:54 Analyzing new table...
2016-12-06T12:15:54 Swapping tables...
2016-12-06T12:15:54 Swapped original and new tables OK.
2016-12-06T12:15:54 Dropping old table...
2016-12-06T12:15:54 Dropped old table `
test
`.`_sbtest_old` OK.
2016-12-06T12:15:54 Dropping triggers...
2016-12-06T12:15:54 Dropped triggers OK.
Successfully altered `
test
`.`sbtest`.
|
3、基于binlog为ROW行的复制,触发器不会在slave从库上工作,这就导致了主从数据不一致。但基于binlog为statement语句的复制,触发器会在slave从库上工作。
With statement-based replication, triggers executed on the master also execute on the slave. With row-based replication, triggers executed on the master do not execute on the slave.
参考文献:http://dev.mysql.com/doc/refman/5.7/en/replication-features-triggers.html
注:在二进制日志里,MIXED默认还是采用STATEMENT格式记录的,但在下面这6种情况下会转化为ROW格式。
第一种情况:NDB引擎,表的DML操作增、删、改会以ROW格式记录。
第二种情况:SQL语句里包含了UUID()函数。
第三种情况:自增长字段被更新了。
第四种情况:包含了INSERT DELAYED语句。
第五种情况:使用了用户定义函数(UDF)
第六种情况:使用了临时表。
参考文献:https://dev.mysql.com/doc/refman/5.7/en/binary-log-mixed.html
复现
1、主库创建t1表
1
2
3
4
|
CREATE TABLE `t1` (
`
id
` int(11) NOT NULL,
PRIMARY KEY (`
id
`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
|
2、从库创建t2表并创建触发器
1
2
3
4
|
CREATE TABLE `t2` (
`
id
` int(11) NOT NULL,
PRIMARY KEY (`
id
`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
|
触发器
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
DELIMITER $$
USE `
test
`$$
DROP TRIGGER IF EXISTS `t1_1`$$
CREATE
TRIGGER `t1_1` AFTER INSERT ON `t1`
FOR EACH ROW BEGIN
INSERT INTO t2(
id
) VALUES(NEW.
id
);
END;
$$
DELIMITER ;
|
3、主库插入
1
2
|
insert into t1 values(1),(2),(3);
select
* from t2;
|
此时t2表里没有任何数据,触发器没有工作。
结论
如果你使用pt-online-schema-change修改表结构在主库上运行,数据不一致的情况不会发生。但如果在从库上运行,且主库的binlog格式为ROW,那将是危险的。
本文转自hcymysql51CTO博客,原文链接:http://blog.51cto.com/hcymysql/1879962 ,如需转载请自行联系原作者