pt-slave-restart的功能是监控和出错后重启MySQL复制。
用法如下：
pt-slave-restart [OPTIONS] [DSN]pt-slave-restart监控一个或者多个MySQL复制slave的错误，然后当复制停止时试图重启。
pt-slave-restart监控一个或者多个MySQL复制slave，试图跳过引起错误的语句。它以指数变化的睡眠时间职能地检查slave。你可以指定要跳过的错误然后运行slave一直到一个确定的binlog位置。
虽然该工具可以帮助slave跳过错误继续运行，但是你不能依赖它去修复复制。如果slave错误频繁或者意外发生，你应该识别和修复其根本产生源。
pt-slave-restart一旦检测到slave有错误就会打印一行。默认情况下该打印行为：时间戳、连接信息、中继日志文件、中继日志位置以及上一个错误号。你可以使用--verbose选项添加更多信息，也可以使用--quiet选项阻止所有输出。
pt-slave-restart检查slave的过程中智能地睡眠。当前的睡眠时间是变化的。
- 初始睡眠时间通过--sleep选项给出。
- 如果检测发现错误，它对半之前的睡眠时间。
- 如果检测到没有错误，它倍增之前的睡眠时间。
- 通过--min-sleep和--max-sleep参数限定睡眠时间的下界和上界。
- 一旦检测到错误，pt-slave-restart假定接下来很可能发生另一个错误，因此它采用当前的睡眠时间或者初始睡眠时间，取决于哪个值更小。
从Percona Toolkit 2.2.8版本起，pt-slave-restart开始支持由MySQL 5.6.5版本引入的GTID复制。重点牢记：
- 当采用多线程复制（slave_parallel_workers > 0）时，pt-slave-restart不能跳过事务。pt-slave-restart不能确定GTID事件是哪个特定slave线程执行失败的事务。
- 默认行为是跳过来自master的下一个事务。写可以来自不同的服务器，每个服务器都有它自己的UUID。参考--master-uuid选项。
以下为个人本地环境的测试数据。过程是master和slave上复制同步的一张表，首先是在slave上手动分5次删除5条数据，然后再去master上面replay同样的操作。因为slave上该5条数据已经不存在了，所以master上的复制事件到了slave就会出错，但是借助pt-slave-restart工具就可以智能地跳过保证复制工作继续进行了。
root@ubuntu:~# pt-slave-restart -h192.168.112.128 -P3306 -uroot -p123456 --sleep=11
2018-05-04T00:59:09 P=3306,h=192.168.112.128,p=...,u=root relay-bin.000005 369 1032
2018-05-04T00:59:20 P=3306,h=192.168.112.128,p=...,u=root relay-bin.000005 726 1032
2018-05-04T00:59:31 P=3306,h=192.168.112.128,p=...,u=root relay-bin.000005 1085 1032
2018-05-04T00:59:39 P=3306,h=192.168.112.128,p=...,u=root relay-bin.000005 1444 1032
2018-05-04T00:59:43 P=3306,h=192.168.112.128,p=...,u=root relay-bin.000005 1800 1032参考：
https://www.percona.com/doc/percona-toolkit/LATEST/pt-slave-restart.html