pt-online-schema-change你今天滥用了吗?

注:本文来自真实生产案例,感谢网友小豚提供,本人加以故障重现校验。

场景

因想整理一下线上的独立表空间碎片,故使用了 pt-online-schema-change slave 从库上执行,目的是怕影响主库的 CPU ,维护的时候再进行一次主从切换,然后再收缩主库上的表空间碎片。

slave 从库上执行的命令如下:

# 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 老表。过程如下:

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.

注: 在二进制日志里, MIXED 默认还是采用 STATEMENT 格式记录的,但在下面这 6 种情况下会转化为 ROW 格式

第一种情况: NDB 引擎,表的 DML 操作增、删、改会以 ROW 格式记录。

第二种情况: SQL 语句里包含了 UUID() 函数。

第三种情况:自增长字段被更新了。

第四种情况:包含了 INSERT DELAYED 语句。

第五种情况:使用了用户定义函数( UDF

第六种情况:使用了临时表。

复现

1、 主库创建 t1

 CREATE TABLE `t1` (
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

2、 从库创建 t2 表并创建触发器

CREATE TABLE `t2` (
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

触发器

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、 主库插入

insert into t1 values(1),(2),(3);
select * from t2;

此时 t2 表里没有任何数据,触发器没有工作。

结论

如果你使用 pt-online-schema-change 修改表结构在主库上运行,数据不一致的情况不会发生。但如果在从库上运行,且主库的 binlog 格式为 ROW ,那将是危险的。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章