MySQL pt-slave-restart工具的使用简介
在MySQL主从复制环境的搭建中，常常会遇到一种场景，主库和从库都要初始化用户的账号密码，正常的情况下，需要在主库和从库都关闭session级别的binlog，然后再进行用户信息导入。
但是有时候会忽略关闭session级别binlog这个前置动作，例如在基于GTID的复制模式下，主从库都直接导入了用户的账号密码信息，主库和从库都将账号密码的事务记录到了自己的GTID中，此时我们如果利用GTID的方式搭建复制，会出现报错，因为从库已经有账号了，所以主库上同步到从库的用户信息会出现报错现象，提示用户已经存在，这种情况下，我们需要在从库跳过从主库复制过来的创建用户的SQL语句。
在GTID模式下，通过下面的办法可以跳过一个事务：
stop slave; set gtid_next=xxxxx; begin; commit; set gtid_next=automatic; start slave;
但是在事务数很多的情况下，我们不能一个一个跳过，需要批量跳过同一个错误，这里有几种方式可以进行处理;
MySQL复制问题的三个参数介绍
分别是调整slave_skip_errors参数或者slave_exec_mode参数
今天我们来看另外一种方法，就是利用pt-slave-restart工具来进行事务跳过，命令如下：
./pt-slave-restart -uroot -proot123 --error-numbers=1062
命令很容易理解，写清楚错误编码，直接跳过就行，它会打印出来很多信息，默认情况下打印内容为：时间戳、连接信息、中继日志文件、中继日志位置以及上一个错误号。例如：
2020-09-22T00:59:09P=3306,h=192.168.7.194,p=...,u=rootrelay-bin.0000053691032
2020-09-22T00:59:09P=3306,h=192.168.7.194,p=...,u=rootrelay-bin.0000057261032
2020-09-22T00:59:09P=3306,h=192.168.7.194,p=...,u=rootrelay-bin.00000510851032
2020-09-22T00:59:09P=3306,h=192.168.7.194,p=...,u=rootrelay-bin.00000514441032
2020-09-22T00:59:09P=3306,h=192.168.7.194,p=...,u=rootrelay-bin.00000518001032
你可以使用--verbose选项添加更多信息，也可以使用--quiet选项阻止所有输出。
注意事项：
当采用多线程复制（slave_parallel_workers > 0）时，pt-slave-restart不能跳过事务。pt-slave-restart不能确定GTID事件是哪个特定slave线程执行失败的事务。
如果需要使用，请暂时关闭多线程复制的workers
关于pt-slave-restart的其他参数，可以使用pt-slave-restart --help的命令查看，也可以参考下面的常见参数列表：
--always:永不停止slave线程，手工停止也不行 --ask-pass:替换-p命令，防止密码输入被身后的开发窥屏 --error-numbers ：指定跳过哪些错误，可用,进行分隔 --error-text ：根据错误信息进行匹配跳过 --log ：输出到文件 --recurse ：在主端执行，监控从端 --runtime ：工具执行多长时间后退出：默认秒，m=minute,h=hours,d=days --slave-user --slave-password ：从库的账号密码，从主端运行时使用 --skip-count ：一次跳过错误的个数，胆大的可以设置大些，不指定默认1个 --master-uuid:级联复制的时候，指定跳过上级或者上上级事务的错误 --until-master :到达指定的master_log_pos,file位置后停止，格式：”file:pos“ --until-relay :和上面一样，但是根据relay_log的位置来停止
以上就是MySQL pt-slave-restart工具的使用简介的详细内容，更多关于MySQL pt-slave-restart工具的使用的资料请关注编程宝库其它相关文章！
MySQL主从复制断开的常用修复方法： 01 问题描述 在生产环境中，我们经常会遇见MySQL主从复制断开的情况，在遇到主从复制断开是，通常情况，解决问题的步骤如下：1、从库上show slave status查看复制断开的直观 ...