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。

 

分析

一、主庫和從庫的binlog格式爲ROW

二、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`.

三、基於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

復現

一、主庫建立t1表

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

二、從庫建立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 ;

三、主庫插入

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

此時t2表裏沒有任何數據，觸發器沒有工做。

結論

若是你使用pt-online-schema-change修改表結構在主庫上運行，數據不一致的狀況不會發生。但若是在從庫上運行，且主庫的binlog格式爲ROW，那將是危險的。