案例 - percona-online-schema-change各种坑

标签：percona

线上环境复制使用ROW模式，对于上亿的表，使用pt online schema change 在把数据从旧表拷贝到临时表这步操作，会产生大量的binlog，这会导致主从延迟

在pt工具包2.1之前，pt-online-schema-change是不会打印binlog的，如果要在主从上加索引，需要分别在主库执行一次，在从库执行一次

它提供了一个--log-bin产生，并且默认是关闭的

• --bin-log

• Allow binary logging (SET SQL_LOG_BIN=1). By default binary logging is turned off because in most cases the --tmp-tabledoes not need to be replicated. 

而在pt工具2.2版本以后，会默认打binlog，好处是在不用分别在各个节点执行一次改表操作，只需要在主库执行一次改表，就会通过binlog让下面的从库的表都被修改

pt工具3.0版本，有一个 --set-vars=‘sql_log_bin=0‘ 参数能取代 --bin-log=0 效果

刚好有一个1.5亿表加索引的需求，就使用如下命令，1.5亿生成的binlog预计会有20G，为了不产生binlog，准备在每个点执行一次，先在主库执行

pt-online-schema-change                             
--host=主机                                   
--port=端口号                                        
--user=节点号                                        
--database=数据库名                                 
t=t_room_impeach                                   
--alter="ADD INDEX idx_psr(A,B,C)"  
--set-vars=‘sql_log_bin=0‘                           
--execute

这条语句一下去，主库下面的4个从库同步都中断了，show slave status报错

Last_SQL_Errno: 1146
Last_SQL_Error: Error executing row event: ‘Table ‘live_oss._t_room_impeach_new‘ doesn‘t exist‘

报错_t_room_impeach_new表存在，为什么这张表要存在呢？

posc工具的原理是，先创建一个临时表，表名是 _原来的表名_new，这张临时表是已经加入了你想要的索引，不停把旧表的数据拷贝到这张临时表，新插入，修改，删除的旧表的数据，都会根据触发器，同样新插入，修改，删除到临时表，等拷贝数据，旧表和临时表就是一模一样了，这个时候把临时表rename成为就表的名字，而实际的旧表就会被drop掉，在线完成

当主库执行命令是会显示创建临时表，创建触发器

Creating new table...
Created new table live_oss._t_room_impeach_new OK.
Altering new table...
Altered `live_oss`.`__t_room_impeach_new` OK.
2017-08-02T16:38:48 Creating triggers...
2017-08-02T16:38:48 Created triggers OK.
2017-08-02T16:38:48 Copying approximately 141559863 rows...

因为 --set-vars=‘sql_log_bin=0‘的原因，创建表的DDL语句，无法通过binlog在从库建表，所以从库是表不存在的，问题是从库不需要存在临时表啊，因为只操作主库一个点就足够了

这个是posc第一个坑，主库因触发器触发器产生的数据，会产生binlog，从而同步到从库，当从库要执行这些数据时，发现表不存在，导致同步中断

这时解决方法是在从库，去建立同样一张临时表 _xxxx_new，好让触发器的数据，能够顺利插入到这张表，当建了以后可以看到从库的临时表有数据了，再次验证sql_log_bin=0没有效果

explain select count(*) from  __t_room_impeach_new;
+----+-------------+----------------------+-------+---------------+------+---------+------+----------+-------------+
| id | select_type | table                | type  | possible_keys | key  | key_len | ref  | rows     | Extra       |
+----+-------------+----------------------+-------+---------------+------+---------+------+----------+-------------+
|  1 | SIMPLE      | __t_room_impeach_new | index | NULL          | uid  | 4       | NULL | 176| Using index |
+----+-------------+----------------------+-------+---------------+------+---------+------+----------+-------------+

几个从库都有176条数据，再看看主库的临时表，有差不多1亿数据，因为除了触发器还有来自旧表的

explain select count(*) from  __t_room_impeach_new;
+----+-------------+----------------------+-------+---------------+------+---------+------+----------+-------------+
| id | select_type | table                | type  | possible_keys | key  | key_len | ref  | rows     | Extra       |
+----+-------------+----------------------+-------+---------------+------+---------+------+----------+-------------+
|  1 | SIMPLE      | __t_room_impeach_new | index | NULL          | uid  | 4       | NULL | 10527757 | Using index |
+----+-------------+----------------------+-------+---------------+------+---------+------+----------+-------------

当时有个担心

主库临时表 __t_room_impeach_new 数据 =  触发器产生数据  + 旧表产生数据

从库临时表 __t_room_impeach_new数据 = 触发器产生的数据

如果所有点执行最后一步操作 rename 临时表__t_room_impeach_new to t_room_impeach 正式表，岂不是主从数据不一致,从库少了很多数据？ 

不过按道理这种情况不会发生，因为--set-vars=‘sql_log_bin=0‘会把rename这个DDL语句，像create table一样给阻隔掉，不会导致从库改表成功

为了不冒险，打算重新执行一次，这次加入2个参数，

--no-drop-old-table 即使执行完了命令，也不要drop表，让我确认旧表新表是一致的再手动drop

--no-drop-triggers 触发器也保留

执行命令之前，先把临时表，触发器都手动删除，正如提示说的

Not dropping triggers because the tool was interrupted.  To drop the triggers, execute:
DROP TRIGGER IF EXISTS `live_oss`.`pt_osc_live_oss_t_room_impeach_del`;
DROP TRIGGER IF EXISTS `live_oss`.`pt_osc_live_oss_t_room_impeach_upd`;
DROP TRIGGER IF EXISTS `live_oss`.`pt_osc_live_oss_t_room_impeach_ins`;
Not dropping the new table `live_oss`.`_t_room_impeach_new` because the tool was interrupted.  To drop the new table, execute:
DROP TABLE IF EXISTS `live_oss`.`_t_room_impeach_new`;
`live_oss`.`t_room_impeach` was not altered.

另外还有在从库先把临时表建立起来，这次执行到一半的时候，4个从库又报错，同步中断了

Last_SQL_Errno: 1032

Last_SQL_Error: Could not execute Update_rows event on table live_oss._t_room_impeach_new; Can‘t find record in ‘_t_room_impeach_new‘, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event‘s master log mysql-bin.056637, end_log_pos 41767716

这次的报错是update语句失败了，row模式的update语句是  set 新值 where 旧值 ，如果在从库的临时表上，找不到旧值，就会报这样的错

同样因为--set-vars=‘sql_log_bin=0‘，导致从库临时表，比主库临时表少很多数据，所以很可能一条update语句下来，就会因为找不到数据而中断

总结-在myqsl主从复制下，主库不要用这种模式，因为无法阻止触发器带来binlog，仅仅在从库执行时可以的

另外如果使用--no-drop-old-table和--no-drop-triggers参数，最终结果是命令到99%一直卡住

Copying `live_oss`.`t_room_impeach`:  99% 01:01 remain

Copying `live_oss`.`t_room_impeach`:  99% 00:47 remain

Copying `live_oss`.`t_room_impeach`:  99% 00:35 remain

Copying `live_oss`.`t_room_impeach`:  99% 00:21 remain

Copying `live_oss`.`t_room_impeach`:  99% 00:09 remain

还有一个坑就是业务时不时会反馈一吧报错，一张临时表不存在，但这张临时表应该是对业务透明才对的,真心奇怪

XXXX 说: (17:19:49)
Base table or view not found: 1146 Table ‘live_oss.__t_room_impeach_new‘ doesn‘t exist

报了这个错误的
xxxx 说: (17:21:00)
怎么表名变为t_room_impeach_new了
XXXXXX 说: (17:25:27)
原来的表还存在把
XXXXX说: (17:25:47)
现在又恢复了

本文出自 “数据库运维” 博客，请务必保留此出处http://dadaman.blog.51cto.com/11373912/1953177

案例 - percona-online-schema-change各种坑

标签：percona

原文地址：http://dadaman.blog.51cto.com/11373912/1953177