版本:pt-online-schema-change 2.2.19
执行pt-osc 发现slave lag后，pt-osc 一直wait，实在等不下去后直接强制kill pt-osc ，从日志看到：
Not dropping triggers because the tool was interrupted. To drop the triggers, execute:
DROP TRIGGER IF EXISTS hhl.pt_osc_hhl_t1_del;
DROP TRIGGER IF EXISTS hhl.pt_osc_hhl_t1_upd;
DROP TRIGGER IF EXISTS hhl.pt_osc_hhl_t1_ins;
Not dropping the new table hhl._t1_new because the tool was interrupted. To drop the new table, execute:
DROP TABLE IF EXISTS hhl._t1_new;
Event Count
====== =====
INSERT 1
hhl.t1 was not altered.
这种强制中断或者失败后新表 和 触发器没有删除，会是一个坑，曾经线上遇到过一次pt-osc任务失败，但是没有检查日志，白天发现所在MySQL 机器负载、IO特别高，找了很久发现是pt-osc 失败后触发器没有删除。
靠谱的做法：脚本里每次pt-osc 完成后检查触发器、新表是否都已经删除。
.check 主从延时超过--max-lag 就暂停，直到小于--max-lag 才继续：
检查某个从库：
--check-slave-lag "h=x.x.x.x,P=3307"
执行输出如下
检查多个从库：
使用--recursion-method 的方式：
比如检查2个从库对应端口是3307、3308，操作如下：
create database IF NOT EXISTS pt;
use pt;
CREATE TABLE
dsns (id int(11) NOT NULL AUTO_INCREMENT,parent_id int(11) DEFAULT NULL,dsn varchar(255) NOT NULL,PRIMARY KEY (
id));
INSERT INTO dsns (parent_id,dsn) values(1, "h=x.x.x.x,u=repl,p=xx,P=3307");
INSERT INTO dsns (parent_id,dsn) values(1, "h=x.x.x.x,u=repl,p=xxx,P=3308");
/usr/bin/pt-online-schema-change
....
--recursion-method "dsn=D=pt,t=dsns"
....
执行输出部分：
