pt-online引发的生产小事故

事故

大白天，业务反馈给我说数据同步有问题，但是我这边排查数据同步的链路，全部正常（数据同步是利用canal监听binlog实现的）。后来发现，原来是因为业务开发提交了一个增加索引的工单，工单执行后，数据同步出现延迟。

可是出现数据同步延迟的原因只可能是:

1. binlog产生的太快，来不及消费，堆积了。
2. binlog文件太多，触发了阿里云binlog文件的清理机制。

一般增加索引没理由发生堆积呀，难道这里有故事？赶紧咨询dba同学，原来，像这种在线ddl，都是使用pt-online-schema-change完成的，这里就有坑。

原因

为了避免线上在线ddl引起锁表，pt会先创建一个临时表，然后将旧表的数据拷贝到临时表中，这个过程会产生binlog，如果原表的数据很多，那产生的binlog就会很多，由于临时表的binlog数据对业务是没有意义的，因此临时表产生的binlog会造成业务的数据同步延迟现象。

pt-online-schema-change其实默认情况下是关闭了临时表记录binlog的，因为临时表的binlog是没用的，但是在集群环境需要小心这个配置。

--bin-log

Allow binary logging (SET SQL_LOG_BIN=1). By default binary logging is turned off because in most cases the –tmp-table does not need to be replicated. Also, performing an online schema change in a replication environment requires careful planning else replication may be broken; see “REPLICATION”.

从dba同学那里了解到，我司的数据库平台，这个选项是打开的，dba的解释是为了避免集群环境主从不一致的情况。

措施

说实话，本来我是想和dba商量一下能不能把这个配置项关闭了的，但是他这个解释也很合理。后续如何规避此类风险呢？

1. 知悉原理：配合dba同学将在线ddl的原理、风险告知开发同学
2. 规范行事：制定规范，白天生产环境的工单需谨慎审核
3. 监控预警：对影响行数较多的工单，在发起后审核前就提前预警，确保不会影响业务后再进行
4. 补救方案：对于此类事故涉及的下游系统，需要制定事故快速恢复方案