来到杭州快1年了，不知道干什么，在不同数据库和代码之间徘徊，好久没有写blog了。备战相关技术，准备对某些数据库技术个系列出来。
print("hellow db");
db.isMaster();use I_S;
MHA v0.58搭建说明
第一部分:MYSQL MHA架构介绍说明
一、MHA简述
本次简述来官方
MHA通常在10-30秒内以最小的停机时间自动执行master故障转移和slave升级为new master。
MHA可以防止复制一致性问题，并节省购买其他服务器的开销。所有这些都没有性能下降，没有复杂性(易于安装)，不需要更改现有部署
MHA还提供了预定的在线master切换，可以在停机(仅阻塞写操作)后几秒内(0.5-2秒)安全地将当前正在运行的master更改为new master。
MHA具有如下功能：
1.Automated master monitoring and failover
MHA可以已建好的复制环境中监视MySQL主机，在检测到master故障时执行自动主故障转移。
MHA通过获取日志最新的slave服务器中继日志事件，并将其应用于所有其他slave(包括那些仍然没有接收到最新中继日志事件的slave)来保证所有slave的一致性。
MHA通常可以在几秒钟内执行故障转移:9-12秒检测主设备故障，7-10秒关闭主设备电源以避免大脑分裂，几秒向新主设备应用差异继电器日志。总的停机时间通常为10-30秒。
可以在配置文件中将特定的slave节点点指定为候选主节点(设置优先级)。
由于MHA保持了slave之间的一致性，所以任何slave都可以被提升为new master。
通常下，复制突然失败的一致性问题不会发生。
2.Interactive (manually initiated) Master Failover
MHA可以配置为手动启动(非自动)、交互式故障转移，而无需监视主服务器。
3.Non-interactive master failover
还支持非交互式的自动主故障转移，无需监视主服务器。当MySQL主软件监控已经在使用时，这个特性特别有用。例如，您可以使用Pacemaker(Heartbeat)检测主故障和虚拟IP地址接管，同时使用MHA进行主故障转移和从服务器升级。
4.Online switching master to a different host
通常有必要将现有的主服务器迁移到另一台机器上，比如当前主服务器有H/W RAID控制器或RAM问题，或者希望用更快的机器替换它，等等。这不是主崩溃，但是需要定期的主维护。
计划的主程序维护应该尽快完成，因为它需要部分停机(主程序写被禁用)。另一方面，您应该非常小心地阻塞/终止当前正在运行的会话，因为不同的主机之间可能会出现一致性问题(如“更新master1，更新master 2，提交master1，提交master 2出错”将导致数据不一致)。快速主开关和优雅的阻塞写都是必需的。
MHA在写入器阻塞后0.5-2秒内提供优雅的主开关。0.5-2秒的写程序停机时间通常是可以接受的，因此即使不分配计划维护窗口，也可以切换主程序。诸如升级到更高版本、更快的机器等操作变得容易得多。
5.选主时面对的困难
主故障转移并不像看上去那么简单。以最典型的MYSQL部署为例，一个master有多个slave。
如果主服务器崩溃，您需要选择一个最新的slave，将其提升到new master，并让其他slave从new master开始复制，这并不是小事。
即使可以识别出当前的slave，其他slave也可能还没有收到所有的二进制日志事件。如果在复制开始时连接到new master，这些slave将丢失事务。这会导致一致性问题。为了避免这些一致性问题，需要在提升slave为new master的复制之前，依次标识丢失的binlog事件(还没有到达所有从属服务器)，并将其应用于每个从属服务器。这种操作非常复杂，很难手工执行。
MHA的目标是尽可能快地实现主故障转移和恢复过程的完全自动化。恢复包括确定new master、确定所有slave的差异中继日志事件、向new master应用必要的事件、同步其他slave并让它们从新主服务器开始复制。
MHA通常可以在10-30秒的停机时间内进行故障转移(10秒检测主机故障，可选7-10秒关闭主机电源以避免大脑分裂，几秒或更长时间进行恢复)，具体取决于复制延迟。
MHA提供自动和手动故障转移命令。自动故障转移命令“masterha_manager (MHA Manager)”由主监视和主故障转移组成。masterha_manager永久地监视主服务器的可用性。如果MHA Manager无法到达主服务器，它将自动启动非交互式故障转移过程。
手动故障转移命令“masterha_master_switch”最初会检查master是否已经死亡。如果主服务器确实已死，masterha_master_switch将从服务器中选择一个作为新主服务器(您可以选择首选的主服务器)，并启动恢复和故障转移。
在内部，它可以执行更多的操作，但是只执行一个命令，而不需要自己执行复杂的主恢复和故障转移操作。
二、MHA架构
1.When a master crashes, MHA recovers rest slaves as below.
在从服务器上的中继日志文件中，主服务器的二进制日志位置写在“end_log_pos”部分(示例)。通过比较从服务器之间最新的end_log_pos，我们可以确定哪些中继日志事件没有发送到每个从服务器。MHA通过使用此机制在内部恢复从服务器(修复一致性问题)。MHA做了一些优化和增强，比如非常快速地生成差分中继日志(独立于中继日志文件大小)，binlog基于row格式等等。
2.MHA consists of MHA Manager and MHA Node
MHA Manager具有监控MySQL主机、控制主机故障转移等管理程序。
MHA Node有故障转移帮助脚本，例如解析MySQL二进制/中继日志、确定中继日志的位置(中继日志应该从哪个位置应用到其他从节点)、将事件应用到目标从节点等等。MHA节点在每个MySQL服务器上运行。
当MHA Manager执行故障转移时，MHA Manager通过SSH连接MHA节点，并在需要时执行MHA节点命令。
3.MHA Manager里可以扩展的脚本。
secondary_check_script:用于检查来自多个网络路由的主可用性
master_ip_failover_script:用于更新应用程序中使用的主ip地址
shutdown_script:用于强制关闭主服务器
report_script:用于发送报告
init_con_load_script:用于加载初始配置参数
master_ip_online_change_script:用于更新主ip地址。这不是用于主故障转移，而是用于在线master切换
三、MHA优点
1.Master failover and slave promotion can be done very quickly
MHA通常可以在几秒钟内故障转移(9 – 12秒检测主失败,选择7 – 10秒关机主机避免分裂的大脑,几秒钟应用差异中继日志到new master上,所以总停机时间通常是10 – 30秒),只要slave不延迟复制严重。
在选举出一个new master后，MHA并行地恢复其他slave。即使您有数十个slave，它也不会影响master恢复时间，而且您可以非常快速地恢复slave。
2.Master crash does not result in data inconsistency
当前主服务器崩溃时，MHA自动标识从服务器之间的差异中继日志事件，并应用于每个从服务器。因此，只要所有从服务器都是活动的，所有从服务器就可以保持同步。通过与增强半同步复制一起使用，(几乎)没有数据丢失也可以得到保证。
3.No need to modify current MySQL settings
MHA最重要的设计原则之一是使MHA尽可能长时间地易于使用。MHA与现有的传统MySQL 5.0+主从复制环境兼容。尽管许多其他HA解决方案需要更改MySQL部署设置，但MHA并不强制dba执行此类任务。MHA使用最常见的两层单主机和多个从机环境。MHA同时支持异步和半同步MySQL复制。启动/停止/升级/降级/安装/卸载MHA无需更改(包括启动/停止)MySQL复制。当您需要将MHA升级到新版本时，不需要停止MySQL。只需替换为较新的MHA版本并重新启动MHA管理器即可。
MHA可以从MySQL 5.0开始使用普通MySQL版本。一些HA解决方案需要特殊的MySQL版本(例如MySQL集群、带有全局事务ID的MySQL等)，但是您可能不喜欢只为主HA迁移应用程序。在很多情况下，人们已经部署了许多遗留的MySQL应用程序，他们不想花太多时间迁移到不同的存储引擎或更新的主流发行版上，而仅仅是为了主HA。MHA支持包括5.0/5.1/5.5在内的普通MySQL版本，因此不需要迁移。
4.No need to increase lots of servers
MHA由MHA管理器和MHA节点组成。当发生故障转移/恢复时，MHA节点在MySQL服务器上运行，因此它不需要额外的服务器。MHA Manager通常运行在专用服务器上，所以您需要为HA服务器添加一个(或两个)主机，但是MHA Manager可以从单个服务器监视很多(甚至100多个)主机，所以服务器的总数不会增加太多。注意，甚至可以在一个从服务器上运行MHA Manager。在这种情况下，服务器的总数根本没有增加。
5.No performance penalty
MHA支持常规的异步或半同步MySQL复制。在监视主服务器时，MHA只是每N秒向主服务器发送ping包(默认值为3)，并不发送繁重的查询。您可以期望与常规MySQL复制一样快的性能。
6.Works with any storage engine
只要MySQL复制能够工作，MHA就可以与任何存储引擎一起工作，而不限于InnoDB(安全的事务存储引擎)。即使使用不易迁移的遗留MyISAM环境，也可以使用MHA。
7.Using together with Semi-Synchronous Replication
尽管MHA试图从崩溃的主服务器中保存二进制日志，但这并不总是可能的。例如，如果崩溃的主机死于H/W故障或无法通过SSH访问，MHA不能保存二进制日志，并且必须在不应用仅存在于崩溃的主机上的二进制日志事件的情况下进行故障转移。这将导致丢失最新的数据。
使用半同步复制大大降低了此类数据丢失的风险。MHA使用半同步复制，因为它基于MySQL复制机制。值得注意的是，如果只有一个从服务器收到了最新的二进制日志事件，那么MHA可以将这些事件应用于所有其他从服务器，这样它们就可以彼此保持一致。
四、MHA限制条件或缺点
1.SSH public key authentication（配置对等性，安全性需要注意）
MHA Manager通过SSH在内部连接MySQL服务器。因为通过SSH(scp)向其他从服务器内部发送中继日志文件。为了使这些过程自动化，通常建议启用SSH公钥身份验证而不使用密码短语。可以使用MHA Manager中包含的masterha_check_ssh命令检查SSH连接是否正常工作。
2.MHA只运行在linux系统下
3.如果master机器掉电导致，slave提升为new master，可能会导致数据丢失（增强半同步解决）
4.如果因为网络波动导致监听master故障误判，导致slave提升为new master，可能会导致数据丢失
5.MHA默认不支持三层或多层复制结构(即Master1 -> Master2 -> Slave3)，当master1崩溃时，MHA可以管理master1和master2并提升new master，但是MHA不能监控和恢复slave3，因为slave3从不同的master2复制。要使MHA能够使用这些结构，可以配置如下：
需在MHA配置文件中设置主主机和第二层主机(master1和master2)，使用“multi_tier_slave=1”参数并在MHA配置文件中设置所有主机
6.MHA支持5.1之后的版本并且binlog格式时候v4，
7.MHA要求mysqlbinlog版本需要在5.1以上，否
8.如果当前的slave没开启binlog，显然他们不能成为new master。MHA Manager在内部检查binlog设置，并且不将它们提升到new master。如果当前从服务器中都没有设置binlog, MHA Manager将不进行故障转移。
9.复制过滤规则(binlog-do-db、replicate-ignore-db等)在所有MySQL服务器上必须是相同的。MHA在启动时检查过滤规则，如果过滤规则彼此不相同，则不启动监视或故障转移（建议不要配置任何过滤规则）
10.主故障转移完成后，所有其他从服务器执行CHANGE master TO语句。要启动复制，new master上必须存在一个拥有REPLICATION SLAVE权限用户。
11.默认情况下，如果SQL线程已经执行完从服务器上的中继日志，则会自动删除它们。但中继日志可能仍然需要用于恢复其他的slave。因此，您需要禁用自动中继日志清除，并定期清除旧的中继日志。但是在手动清除中继日志时，需要注意复制延迟问题。在ext3文件系统上，删除大型文件需要大量的时间，这将导致严重的复制延迟。
12.如果要使用LOAD数据，请设置sql_log_bin=0;加载数据…;设置sql_log_bin = 1;是比较推荐的方法。
五.使用时总结
1.使用MHA时，可能需要自己编写一些脚本取弥补MHA的不足，例如：加强主从之间的延迟监控，进行vip自动故障切换功能
2.MHA后台守护进程，每次进行切换完之后，会自动关闭管理进程，需要再启动
3.建议使用GTID+ROW+semi-sync-replication加强数据不丢失
4.主库和slave的用户权限一样，集群里禁止使用过滤规则
5.进行选主后，其他slave如果落后很大，会导致恢复slave时很慢
6.基于gtid模式下，截止0.58版本，mysql master crash之后，不会做补偿机制（普通的binlogserver（利用mysqlbinlog工具搭建的）解决不了这个问题，通过增强半同步或者sync的binlogserver解决这个问题）
7.传统复制注意relay_log_purge需要关闭，每天需要手工清理relay_log_purge，防止在利用relay进行日志补偿时日志已经被删除了
8.super_read_only mha不支持这个参数开关，需要自己改动源码
第二部分：构建生产MHA架构
一、安装包选择
MHA有现在比较常见的版本0.56 0.57.0.58
0.56 最佳操作系统：centos6 支持GTID
0.57 最佳操作系统：centos7 支持0.56
0.58 最佳操作系统：centos7 支持ipv6+支持0.57特性（本次选择）
note:l利用源码编译安装0.58在centos6上
mysql：5.7.24版本
二、资源规划
1.本次MHA整个架构 mysql拓扑结构
主机名 ip地址 作用
trsen191 172.18.0.191 master trsen192 172.18.0.192 slave trsen193 172.18.0.193 slave zabbix24 172.18.0.11 mha manager
vip资源 172.18.0.200 节点间浮动
2.拓扑结构如下：
三、mha软件包安装
github下载安装软件
先安装node，再安装manager，实际上针对数据库节点只需要安装node即可（线上建议）
1.node包及依赖包安装
yum -y install perl-DBD-MySQL ncftp perl-DBI
[root@trsen191 dfile]# rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm Preparing... ################################# [100%] Updating / installing... 1:mha4mysql-node-0.58-0.el7.centos ################################# [100%]
会在/usr/bin目录生成如下四个命令
apply_diff_relay_logs filter_mysqlbinlog purge_relay_logs save_binary_logs
2.manager包及依赖包安装
yum install -y perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager
[root@trsen191 dfile]# rpm -ivh mha4mysql-manager-0.58-0.el7.centos.noarch.rpm Preparing... ################################# [100%] Updating / installing... 1:mha4mysql-manager-0.58-0.el7.cent################################# [100%]
会在/usr/bin目录生成如下就个命令
masterha_check_repl masterha_check_ssh masterha_check_status masterha_conf_host masterha_manager masterha_master_monitor masterha_master_switch masterha_secondary_check masterha_stop
四、服务间之间对等配置
1.生成key，一路回车即可
[root@trsen191 .ssh]# cd ~/.ssh/ & ssh-keygen
2.创建ssh需要的秘钥文件
[root@trsen191 .ssh]# cat id_rsa.pub >> authorized_keys
3.copy key文件
[root@trsen191 ~]# scp -r .ssh/ 172.18.0.192:~/ [root@trsen191 ~]# scp -r .ssh/ 172.18.0.193:~/ [root@trsen191 ~]# scp -r .ssh/ 172.18.0.11:~/
4..ssh目录权限为700，id_rsa,authorized_keys权限为600
5.测试
五、安装mysql，这里不多介绍说明，见文章mysql5.7.24二进制快速安装，里面参数要根据生产上的信息进行相关配置
需要指出创建管理用户和一个复制用户
mysql> create user 'trsen'@'172.18.0.%' identified by 'trsen'; Query OK, 0 rows affected (1.02 sec) mysql> grant all privileges on *.* to 'trsen'@'172.18.0.%'; Query OK, 0 rows affected (0.04 sec) mysql> create user 'repl'@'172.18.0.%' identified by 'repl'; Query OK, 0 rows affected (0.03 sec) mysql> grant replication slave on *.* to 'repl'@'172.18.0.%'; Query OK, 0 rows affected (0.01 sec)
六、MHA配置
1.在manager节点和node节点创建目录
mkir -p /usr/local/masterha/mha1
2.管理节点touch一个空的masterha_default.cnf文件
touch /etc/masterha_default.cnf
3.创建配置文件
vi /usr/local/masterha/masterha_mha1.cnf ###################global############### [server default] #log_level=debug #MySQL的用户和密码 user=trsen password=trsen #系统ssh用户 ssh_user=root ssh_port=22 #复制用户 repl_user=repl repl_password=repl #监控 ping_interval=3 #shutdown_script="" #切换调用的脚本 master_ip_failover_script= /usr/local/masterha/master_ip_failover master_ip_online_change_script= /usr/local/masterha/master_ip_online_change #################################cluster1############################################# #mha manager工作目录 manager_workdir = /usr/local/masterha/mha1 manager_log = /usr/local/masterha/mha1/mha1.log remote_workdir = /usr/local/masterha/mha1 port = 3309 [server1] hostname=172.18.0.191 master_binlog_dir = /data/mysql/mha/logs candidate_master = 1 check_repl_delay = 0 #用防止master故障时，切换时slave有延迟，卡在那里切不过来。 [server2] hostname=172.18.0.192 master_binlog_dir=/data/mysql/mha/logs candidate_master=1 check_repl_delay=0 [server3] hostname=172.18.0.193 master_binlog_dir=/data/mysql/mha/logs candidate_master=1 check_repl_delay=0
4.将master_ip_failover和master_ip_online_change放进配置文件里指定目录位置，但是需要进行手工的修改，样例代码去tar包文件中的sample目录获取或者
5.检查ssh对等性
[root@zabbix24 masterha]# masterha_check_ssh --conf=/usr/local/masterha/masterha_mha1.cnf Wed Jul 24 16:29:41 2019 - [info] Reading default configuration from /etc/masterha_default.cnf.. Wed Jul 24 16:29:41 2019 - [info] Reading application default configuration from /usr/local/masterha/masterha_mha1.cnf.. Wed Jul 24 16:29:41 2019 - [info] Reading server configuration from /usr/local/masterha/masterha_mha1.cnf.. Wed Jul 24 16:29:41 2019 - [info] Starting SSH connection tests.. Wed Jul 24 16:29:42 2019 - [debug] Wed Jul 24 16:29:41 2019 - [debug] Connecting via SSH from root@172.18.0.191(172.18.0.191:22) to root@172.18.0.192(172.18.0.192:22).. Wed Jul 24 16:29:42 2019 - [debug] ok. Wed Jul 24 16:29:42 2019 - [debug] Connecting via SSH from root@172.18.0.191(172.18.0.191:22) to root@172.18.0.193(172.18.0.193:22).. Wed Jul 24 16:29:42 2019 - [debug] ok. Wed Jul 24 16:29:43 2019 - [debug] Wed Jul 24 16:29:42 2019 - [debug] Connecting via SSH from root@172.18.0.192(172.18.0.192:22) to root@172.18.0.191(172.18.0.191:22).. Wed Jul 24 16:29:42 2019 - [debug] ok. Wed Jul 24 16:29:42 2019 - [debug] Connecting via SSH from root@172.18.0.192(172.18.0.192:22) to root@172.18.0.193(172.18.0.193:22).. Wed Jul 24 16:29:43 2019 - [debug] ok. Wed Jul 24 16:29:44 2019 - [debug] Wed Jul 24 16:29:42 2019 - [debug] Connecting via SSH from root@172.18.0.193(172.18.0.193:22) to root@172.18.0.191(172.18.0.191:22).. Wed Jul 24 16:29:43 2019 - [debug] ok. Wed Jul 24 16:29:43 2019 - [debug] Connecting via SSH from root@172.18.0.193(172.18.0.193:22) to root@172.18.0.192(172.18.0.192:22).. Wed Jul 24 16:29:43 2019 - [debug] ok. Wed Jul 24 16:29:44 2019 - [info] All SSH connection tests passed successfully.
6.检查复制是不是正常
[root@zabbix24 masterha]# masterha_check_repl --conf=/usr/local/masterha/masterha_mha1.cnf Wed Jul 24 16:38:12 2019 - [info] Reading default configuration from /etc/masterha_default.cnf.. Wed Jul 24 16:38:12 2019 - [info] Reading application default configuration from /usr/local/masterha/masterha_mha1.cnf.. Wed Jul 24 16:38:12 2019 - [info] Reading server configuration from /usr/local/masterha/masterha_mha1.cnf.. Wed Jul 24 16:38:12 2019 - [info] MHA::MasterMonitor version 0.58. Wed Jul 24 16:38:13 2019 - [info] GTID failover mode = 1 Wed Jul 24 16:38:13 2019 - [info] Dead Servers: Wed Jul 24 16:38:13 2019 - [info] Alive Servers: Wed Jul 24 16:38:13 2019 - [info] 172.18.0.191(172.18.0.191:3309) Wed Jul 24 16:38:13 2019 - [info] 172.18.0.192(172.18.0.192:3309) Wed Jul 24 16:38:13 2019 - [info] 172.18.0.193(172.18.0.193:3309) Wed Jul 24 16:38:13 2019 - [info] Alive Slaves: Wed Jul 24 16:38:13 2019 - [info] 172.18.0.192(172.18.0.192:3309) Version=5.7.24-log (oldest major version between slaves) log-bin:enabled Wed Jul 24 16:38:13 2019 - [info] GTID ON Wed Jul 24 16:38:13 2019 - [info] Replicating from 172.18.0.191(172.18.0.191:3309) Wed Jul 24 16:38:13 2019 - [info] Primary candidate for the new Master (candidate_master is set) Wed Jul 24 16:38:13 2019 - [info] 172.18.0.193(172.18.0.193:3309) Version=5.7.24-log (oldest major version between slaves) log-bin:enabled Wed Jul 24 16:38:13 2019 - [info] GTID ON Wed Jul 24 16:38:13 2019 - [info] Replicating from 172.18.0.191(172.18.0.191:3309) Wed Jul 24 16:38:13 2019 - [info] Primary candidate for the new Master (candidate_master is set) Wed Jul 24 16:38:13 2019 - [info] Current Alive Master: 172.18.0.191(172.18.0.191:3309) Wed Jul 24 16:38:13 2019 - [info] Checking slave configurations.. Wed Jul 24 16:38:13 2019 - [info] Checking replication filtering settings.. Wed Jul 24 16:38:13 2019 - [info] binlog_do_db= , binlog_ignore_db= Wed Jul 24 16:38:13 2019 - [info] Replication filtering check ok. Wed Jul 24 16:38:13 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking. Wed Jul 24 16:38:13 2019 - [info] Checking SSH publickey authentication settings on the current master.. Wed Jul 24 16:38:13 2019 - [info] HealthCheck: SSH to 172.18.0.191 is reachable. Wed Jul 24 16:38:13 2019 - [info] 172.18.0.191(172.18.0.191:3309) (current master) +--172.18.0.192(172.18.0.192:3309) +--172.18.0.193(172.18.0.193:3309) Wed Jul 24 16:38:13 2019 - [info] Checking replication health on 172.18.0.192.. Wed Jul 24 16:38:13 2019 - [info] ok. Wed Jul 24 16:38:13 2019 - [info] Checking replication health on 172.18.0.193.. Wed Jul 24 16:38:13 2019 - [info] ok. Wed Jul 24 16:38:13 2019 - [info] Checking master_ip_failover_script status: Wed Jul 24 16:38:13 2019 - [info] /usr/local/masterha/master_ip_failover --command=status --ssh_user=root --orig_master_host=172.18.0.191 --orig_master_ip=172.18.0.191 --orig_master_port=3309 Wed Jul 24 16:38:13 2019 - [info] OK. Wed Jul 24 16:38:13 2019 - [warning] shutdown_script is not defined. Wed Jul 24 16:38:13 2019 - [info] Got exit code 0 (Not master dead). MySQL Replication Health is OK.
pt-osc 3.0.13 mysql5.7.24
0、mysql ddl操作的流程思路（来自percona）
一、pt-osc的缺点：
1.原表不能存在触发器，因为pt-osc需要通过触发器将原表copy数据阶段产生的数据应用到新表去。
2.表必须具有主键和唯一键。
3.原表不能是其他外键的父表，需要添加—alter-foreign-keys-method参数即可。
4.字段属性为NOT NULL时，必须有DEFAULT属性，否则会报错。
5.可能会导致主从数据延迟
6.如果运行过程中报错了，无法从上一个位置继续进行，需要从头开始
7.不支持MySQL5.7的虚拟列功能
二、pt-osc工作过程创建一个和要执行 alter 操作的表一样的新的空表结构(是alter之前的结构)在新表执行alter table 语句（速度应该很快）在原表中创建触发器3个触发器分别对应insert,update,delete操作以一定大小chunk从原表拷贝数据到临时表，拷贝过程中通过原表上的触发器在原表进行的写操作都会更新到新建的临时表Rename原表到old表中，在把临时表Rename为原表如果有参考该表的外键，根据alter-foreign-keys-method参数的值，检测外键相关的表，做相应设置的处理默认最后将旧原表删除
通过源码查看一下pt-osc的操作步骤
[root@hpaybbcx2:/root]#egrep ‘Step’ /usr/local/bin/pt-online-schema-change
# Step 1: Create the new table.
# Step 2: Alter the new, empty table. This should be very quick,
# Step 3: Create the triggers to capture changes on the original table and
# Step 4: Copy rows.
# Step 5: Rename tables: orig -> old, new -> orig
# Step 6: Update foreign key constraints if there are child tables.
# Step 7: Drop the old table.
[root@hpaybbcx2:/root]#egrep ‘Step’ /usr/local/bin/pt-online-schema-change
# Step 1: Create the new table.
# Step 2: Alter the new, empty table. This should be very quick,
# Step 3: Create the triggers to capture changes on the original table and
# Step 4: Copy rows.
# Step 5: Rename tables: orig -> old, new -> orig
# Step 6: Update foreign key constraints if there are child tables.
# Step 7: Drop the old table.
三、常用选项说明
–host=xxx –user=xxx –password=xxx
连接实例信息，缩写-h xxx -u xxx -p xxx，密码可以使用参数–ask-pass 手动输入。
–alter
结构变更语句，不需要 ALTER TABLE关键字。与原始ddl一样可以指定多个更改，用逗号分隔。
绝大部分情况下表上需要有主键或唯一索引，因为工具在运行当中为了保证新表也是最新的，需要旧表上创建 DELETE和UPDATE 触发器，同步到新表的时候有主键会更快。个别情况是，当alter操作就是在c1列上建立主键时，DELETE触发器将基于c1列。
子句不支持 rename 去给表重命名。
alter命令不支持给索引重命名，需要先drop再add，在pt-osc也一样。(mysql 5.7 支持 RENAME INDEX old_index_name TO new_index_name);但给字段重命名，千万不要drop-add，整列数据会丢失，使用change col1 col1_new type constraint（保持类型和约束一致，否则相当于修改 column type，不能online）
子句如果是add column并且定义了not null，那么必须指定default值，否则会失败。
如果要删除外键（名 fk_foo），使用工具的时候外键名要加下划线，比如–alter “DROP FOREIGN KEY _fk_foo”
D=db_name,t=table_name <<<<<<注意格式
指定要ddl的数据库名和表名
–max-load
默认为Threads_running=25。每个chunk拷贝完后，会检查 SHOW GLOBAL STATUS 的内容，检查指标是否超过了指定的阈值。如果超过，则先暂停。这里可以用逗号分隔，指定多个条件，每个条件格式： status指标=MAX_VALUE或者status指标:MAX_VALUE。如果不指定MAX_VALUE，那么工具会这只其为当前值的120%。
因为拷贝行有可能会给部分行上锁，Threads_running 是判断当前数据库负载的绝佳指标。
–max-lag
默认1s。每个chunk拷贝完成后，会查看所有复制Slave的延迟情况（Seconds_Behind_Master）。要是延迟大于该值，则暂停复制数据，直到所有从的滞后小于这个值。–check-interval配合使用，指定出现从库滞后超过 max-lag，则该工具将睡眠多长时间，默认1s，再检查。如–max-lag=5 –check-interval=2。
熟悉percona-toolkit的人都知道–recursion-method可以用来指定从库dsn记录。另外，如果从库被停止，将会永远等待，直到从开始同步，并且延迟小于该值。
–chunk-time
默认0.5s，即拷贝数据行的时候，为了尽量保证0.5s内拷完一个chunk，动态调整chunk-size的大小，以适应服务器性能的变化。
也可以通过另外一个选项–chunk-size禁止动态调整，即每次固定拷贝 1k 行，如果指定则默认1000行，且比 chunk-time 优先生效
–set-vars
使用pt-osc进行ddl要开一个session去操作，set-vars可以在执行alter之前设定这些变量，比如默认会设置–set-vars “wait_timeout=10000,innodb_lock_wait_timeout=1,lock_wait_timeout=60”。
因为使用pt-osc之后ddl的速度会变慢，所以预计2.5h只能还不能改完，记得加大wait_timeout。
–dry-run
创建和修改新表，但不会创建触发器、复制数据、和替换原表。并不真正执行，可以看到生成的执行语句，了解其执行 步骤与细节，和–print配合最佳
–execute
确定修改表，则指定该参数。真正执行alter。–dry-run与–execute必须指定一个，二者相互排斥
–chunk-size
默认为1000 row
三、使用疑惑（限制）
3.1原表上不能有触发器存在
这个在mysql 5.7.7+版本得以解决，并且在这个pt版本中也有参数来做支持了
3.2通过触发器写数据到临时新表，会不会出现数据不一致或异常（可能会）
在pt-osc一张表时，有应用发生delete操作，通过trigger触发删除操作，此时old表老数据还没有通过chunk复制到新表中，trigger动作结束后，chunk copy的老数据出现在新表中，导致数据不一致
3.3.为什么外键那么特殊
假设 tb1 是要修改的表，tb2 有外键依赖于 tb1，_tb1_new 是 alter tb1 产生的新临时表。
这里的外键不是看tb1上是否存在外键，而是作为子表的 tb2。主要问题在 rename tb1 时，tb1“不存在”导致tb2的外键认为参考失败，不允许rename。
pt-osc提供–alter-foreign-keys-method选项来决定怎么处理这种情况：
rebuild_constraints，优先采用这种方式
它先通过 alter table tb2 drop fk1,add _fk1 重建外键参考，指向新表
再 rename tb1 tb1_old, _tb1_new tb1 ，交换表名，不影响客户端
删除旧表 tb1_old
但如果字表tb2太大，以致alter操作可能耗时过长，有可能会强制选择 drop_swap。
涉及的主要方法在 pt-online-schema-change 文件的 determine_alter_fk_method, rebuild_constraints, swap_tables三个函数中。
drop_swap，
禁用t2表外键约束检查 FOREIGN_KEY_CHECKS=0
然后 drop tb1 原表
再 rename _tb1_new tb1
这种方式速度更快，也不会阻塞请求。但有风险，
第一，drop表的瞬间到rename过程，原表t1是不存在的，遇到请求会报错；
第二，如果因为bug或某种原因，旧表已删，新表rename失败，那就太晚了，但这种情况很少见。
This method forces –no-swap-tables and –no-drop-old-table.
表间存在外键参考关系，建议不通过表定义强制约束
3.4.使用之前需要对磁盘容量进行评估
使用OSC会使增加一倍的空间，包括索引
而且在 Row Based Replication 下，还会写一份binlog。不要想当然使用–set-vars去设置 sql_log_bin=0，因为在这个session级别，alter语句也要在从库上执行，除非你对从库另有打算。
3.5.使用pt-osc原生5.6 online ddl相比，如何选择
online ddl在必须copy table时成本较高，不宜采用
pt-osc工具在存在触发器时，不适用
修改索引、外键、列名时，优先采用online ddl，并指定 ALGORITHM=INPLACE
其它情况使用pt-osc，虽然存在copy data
pt-osc比online ddl要慢一倍左右，因为它是根据负载调整的
无论哪种方式都选择的业务低峰期执行
特殊情况需要利用主从特性，先alter从库，主备切换，再改原主库
四、操作流程分析1、开启模拟业务
./sysbench --mysql-user=mzhang --mysql-db=ptosc --mysql-password=mzhang --mysql-host=10.148.180.103 --mysql-port=3307 --test=tests/db/oltp.lua --oltp_tables_count=5 --oltp-table-size=1000 --rand-init=on prepare ./sysbench --mysql-user=mzhang --mysql-db=ptosc --mysql-password=mzhang --mysql-host=10.148.180.103 --mysql-port=3307 --test=tests/db/oltp.lua --oltp_tables_count=5 --oltp-table-size=100000 --num-threads=8 --oltp-read-only=off --report-interval=10 --rand-type=uniform --max-time=12000 --max-requests=0 --percentile=99 run
2、通过general log来看pt-osc流程
pt-online-schema-change --host=10.148.180.103 --port=3307 --user=mzhang --password=mzhang \ --alter "add column c5 varchar(8) not null default '' " \ D=ptosc,t=sbtest1 --execute --recursion-method=none
2019-08-06T07:34:06.885522Z 81 Connect mzhang@10.148.180.103 on ptosc using TCP/IP 2019-08-06T07:34:06.885749Z 81 Query set autocommit=1 2019-08-06T07:34:06.885989Z 81 Query SHOW VARIABLES LIKE 'innodb\_lock_wait_timeout' 2019-08-06T07:34:06.887454Z 81 Query SET SESSION innodb_lock_wait_timeout=1 2019-08-06T07:34:06.887606Z 81 Query SHOW VARIABLES LIKE 'lock\_wait_timeout' 2019-08-06T07:34:06.888503Z 81 Query SET SESSION lock_wait_timeout=60 2019-08-06T07:34:06.888652Z 81 Query SHOW VARIABLES LIKE 'wait\_timeout' 2019-08-06T07:34:06.889558Z 81 Query SET SESSION wait_timeout=10000 2019-08-06T07:34:06.889705Z 81 Query SELECT @@SQL_MODE 2019-08-06T07:34:06.889836Z 81 Query SET @@SQL_QUOTE_SHOW_CREATE = 1/*!40101, @@SQL_MODE='NO_AUTO_VALUE_ON_ZERO,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'*/ 2019-08-06T07:34:06.889968Z 81 Query SELECT @@server_id /*!50038 , @@hostname*/ 2019-08-06T07:34:06.890471Z 82 Connect mzhang@10.148.180.103 on ptosc using TCP/IP 2019-08-06T07:34:06.890581Z 82 Query set autocommit=1 2019-08-06T07:34:06.890749Z 82 Query SHOW VARIABLES LIKE 'innodb\_lock_wait_timeout' 2019-08-06T07:34:06.892091Z 82 Query SET SESSION innodb_lock_wait_timeout=1 2019-08-06T07:34:06.892216Z 82 Query SHOW VARIABLES LIKE 'lock\_wait_timeout' 2019-08-06T07:34:06.893003Z 82 Query SET SESSION lock_wait_timeout=60 2019-08-06T07:34:06.893128Z 82 Query SHOW VARIABLES LIKE 'wait\_timeout' 2019-08-06T07:34:06.893933Z 82 Query SET SESSION wait_timeout=10000 2019-08-06T07:34:06.894017Z 82 Query SELECT @@SQL_MODE 2019-08-06T07:34:06.894098Z 82 Query SET @@SQL_QUOTE_SHOW_CREATE = 1/*!40101, @@SQL_MODE='NO_AUTO_VALUE_ON_ZERO,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'*/ 2019-08-06T07:34:06.894195Z 82 Query SELECT @@server_id /*!50038 , @@hostname*/ 2019-08-06T07:34:06.894360Z 81 Query SHOW VARIABLES LIKE 'wsrep_on' 2019-08-06T07:34:06.895293Z 81 Query SHOW VARIABLES LIKE 'version%' 2019-08-06T07:34:06.896313Z 81 Query SHOW ENGINES 2019-08-06T07:34:06.896626Z 81 Query SHOW VARIABLES LIKE 'innodb_version' 2019-08-06T07:34:06.897846Z 81 Query SHOW VARIABLES LIKE 'innodb_stats_persistent' 2019-08-06T07:34:06.898858Z 81 Query SHOW GLOBAL STATUS LIKE 'Threads_running' 2019-08-06T07:34:06.899581Z 81 Query SHOW GLOBAL STATUS LIKE 'Threads_running' 2019-08-06T07:34:06.900290Z 81 Query SELECT CONCAT(@@hostname, @@port) 2019-08-06T07:34:06.900556Z 81 Query SHOW TABLES FROM `ptosc` LIKE 'sbtest1' 2019-08-06T07:34:06.900740Z 81 Query SELECT VERSION() 2019-08-06T07:34:06.900853Z 81 Query SHOW TRIGGERS FROM `ptosc` LIKE 'sbtest1' <<<查看操作表上是否已存在触发器 2019-08-06T07:34:06.901211Z 81 Query /*!40101 SET @OLD_SQL_MODE := @@SQL_MODE, @@SQL_MODE := '', @OLD_QUOTE := @@SQL_QUOTE_SHOW_CREATE, @@SQL_QUOTE_SHOW_CREATE := 1 */ 2019-08-06T07:34:06.901287Z 81 Query USE `ptosc` 2019-08-06T07:34:06.901423Z 81 Query SHOW CREATE TABLE `ptosc`.`sbtest1` 2019-08-06T07:34:06.901574Z 81 Query /*!40101 SET @@SQL_MODE := @OLD_SQL_MODE, @@SQL_QUOTE_SHOW_CREATE := @OLD_QUOTE */ 2019-08-06T07:34:06.901907Z 81 Query EXPLAIN SELECT * FROM `ptosc`.`sbtest1` WHERE 1=1 2019-08-06T07:34:06.902262Z 81 Query SELECT table_schema, table_name FROM information_schema.key_column_usage WHERE referenced_table_schema='ptosc' AND referenced_table_name='sbtest1' 2019-08-06T07:34:06.921415Z 81 Query SHOW VARIABLES LIKE 'wsrep_on' 2019-08-06T07:34:06.922466Z 81 Query /*!40101 SET @OLD_SQL_MODE := @@SQL_MODE, @@SQL_MODE := '', @OLD_QUOTE := @@SQL_QUOTE_SHOW_CREATE, @@SQL_QUOTE_SHOW_CREATE := 1 */ 2019-08-06T07:34:06.922531Z 81 Query USE `ptosc` 2019-08-06T07:34:06.922608Z 81 Query SHOW CREATE TABLE `ptosc`.`sbtest1` 2019-08-06T07:34:06.922733Z 81 Query /*!40101 SET @@SQL_MODE := @OLD_SQL_MODE, @@SQL_QUOTE_SHOW_CREATE := @OLD_QUOTE */ 2019-08-06T07:34:06.922906Z 81 Query CREATE TABLE `ptosc`.`_sbtest1_new` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `k` int(10) unsigned NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `k_1` (`k`) ) ENGINE=InnoDB AUTO_INCREMENT=99995 DEFAULT CHARSET=utf8 MAX_ROWS=1000000 <<<<基于老表的定义创建一个新表与其结构一样 2019-08-06T07:34:06.956386Z 81 Query ALTER TABLE `ptosc`.`_sbtest1_new` add column c5 varchar(8) not null default '' <<<<在新表上添加新字段 2019-08-06T07:34:07.002789Z 81 Query /*!40101 SET @OLD_SQL_MODE := @@SQL_MODE, @@SQL_MODE := '', @OLD_QUOTE := @@SQL_QUOTE_SHOW_CREATE, @@SQL_QUOTE_SHOW_CREATE := 1 */ 2019-08-06T07:34:07.002903Z 81 Query USE `ptosc` 2019-08-06T07:34:07.003017Z 81 Query SHOW CREATE TABLE `ptosc`.`_sbtest1_new` 2019-08-06T07:34:07.003216Z 81 Query /*!40101 SET @@SQL_MODE := @OLD_SQL_MODE, @@SQL_QUOTE_SHOW_CREATE := @OLD_QUOTE */ 2019-08-06T07:34:07.003833Z 81 Query SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER, ACTION_STATEMENT, SQL_MODE, CHARACTER_SET_CLIENT, COLLATION_CONNECTION, EVENT_MANIPULATION, ACTION_TIMING FROM INFORMATION_SCHEMA.TRIGGERS WHERE EVENT_MANIPULATION = 'DELETE' AND ACTION_TIMING = 'AFTER' AND TRIGGER_SCHEMA = 'ptosc' AND EVENT_OBJECT_TABLE = 'sbtest1' 2019-08-06T07:34:07.004407Z 81 Query SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER, ACTION_STATEMENT, SQL_MODE, CHARACTER_SET_CLIENT, COLLATION_CONNECTION, EVENT_MANIPULATION, ACTION_TIMING FROM INFORMATION_SCHEMA.TRIGGERS WHERE EVENT_MANIPULATION = 'UPDATE' AND ACTION_TIMING = 'AFTER' AND TRIGGER_SCHEMA = 'ptosc' AND EVENT_OBJECT_TABLE = 'sbtest1' 2019-08-06T07:34:07.004843Z 81 Query SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER, ACTION_STATEMENT, SQL_MODE, CHARACTER_SET_CLIENT, COLLATION_CONNECTION, EVENT_MANIPULATION, ACTION_TIMING FROM INFORMATION_SCHEMA.TRIGGERS WHERE EVENT_MANIPULATION = 'INSERT' AND ACTION_TIMING = 'AFTER' AND TRIGGER_SCHEMA = 'ptosc' AND EVENT_OBJECT_TABLE = 'sbtest1' 2019-08-06T07:34:07.005313Z 81 Query SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER, ACTION_STATEMENT, SQL_MODE, CHARACTER_SET_CLIENT, COLLATION_CONNECTION, EVENT_MANIPULATION, ACTION_TIMING FROM INFORMATION_SCHEMA.TRIGGERS WHERE EVENT_MANIPULATION = 'DELETE' AND ACTION_TIMING = 'BEFORE' AND TRIGGER_SCHEMA = 'ptosc' AND EVENT_OBJECT_TABLE = 'sbtest1' 2019-08-06T07:34:07.005749Z 81 Query SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER, ACTION_STATEMENT, SQL_MODE, CHARACTER_SET_CLIENT, COLLATION_CONNECTION, EVENT_MANIPULATION, ACTION_TIMING FROM INFORMATION_SCHEMA.TRIGGERS WHERE EVENT_MANIPULATION = 'UPDATE' AND ACTION_TIMING = 'BEFORE' AND TRIGGER_SCHEMA = 'ptosc' AND EVENT_OBJECT_TABLE = 'sbtest1' 2019-08-06T07:34:07.006234Z 81 Query SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER, ACTION_STATEMENT, SQL_MODE, CHARACTER_SET_CLIENT, COLLATION_CONNECTION, EVENT_MANIPULATION, ACTION_TIMING FROM INFORMATION_SCHEMA.TRIGGERS WHERE EVENT_MANIPULATION = 'INSERT' AND ACTION_TIMING = 'BEFORE' AND TRIGGER_SCHEMA = 'ptosc' AND EVENT_OBJECT_TABLE = 'sbtest1' <<<<再次仔细检查是否相关DELETE,UPDATE,INSERT AFTER|BEFOR触发器信息 2019-08-06T07:34:07.006630Z 81 Query CREATE TRIGGER `pt_osc_ptosc_sbtest1_del` AFTER DELETE ON `ptosc`.`sbtest1` FOR EACH ROW DELETE IGNORE FROM `ptosc`.`_sbtest1_new` WHERE `ptosc`.`_sbtest1_new`.`id` <=> OLD.`id` 2019-08-06T07:34:07.033552Z 81 Query CREATE TRIGGER `pt_osc_ptosc_sbtest1_upd` AFTER UPDATE ON `ptosc`.`sbtest1` FOR EACH ROW BEGIN DELETE IGNORE FROM `ptosc`.`_sbtest1_new` WHERE !(OLD.`id` <=> NEW.`id`) AND `ptosc`.`_sbtest1_new`.`id` <=> OLD.`id`;REPLACE INTO `ptosc`.`_sbtest1_new` (`id`, `k`, `c`, `pad`) VALUES (NEW.`id`, NEW.`k`, NEW.`c`, NEW.`pad`);END 2019-08-06T07:34:07.034996Z 81 Query CREATE TRIGGER `pt_osc_ptosc_sbtest1_ins` AFTER INSERT ON `ptosc`.`sbtest1` FOR EACH ROW REPLACE INTO `ptosc`.`_sbtest1_new` (`id`, `k`, `c`, `pad`) VALUES (NEW.`id`, NEW.`k`, NEW.`c`, NEW.`pad`)<<<<<创建触发器，这里注意update时，pt做了两件事情分别在新表里删除操作记录，然后在replace into一条记录 2019-08-06T07:34:07.036635Z 81 Query EXPLAIN SELECT * FROM `ptosc`.`sbtest1` WHERE 1=1 2019-08-06T07:34:07.037567Z 81 Query SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `ptosc`.`sbtest1` FORCE INDEX(`PRIMARY`) ORDER BY `id` LIMIT 1 /*first lower boundary*/ 2019-08-06T07:34:07.037877Z 81 Query SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `ptosc`.`sbtest1` FORCE INDEX (`PRIMARY`) WHERE `id` IS NOT NULL ORDER BY `id` LIMIT 1 /*key_len*/ 2019-08-06T07:34:07.098227Z 81 Query EXPLAIN SELECT /*!40001 SQL_NO_CACHE */ * FROM `ptosc`.`sbtest1` FORCE INDEX (`PRIMARY`) WHERE `id` >= '1' /*key_len*/ 这个过程是个循环过程 2019-08-06T07:34:07.112361Z 81 Query EXPLAIN SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `ptosc`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= '1')) ORDER BY `id` LIMIT 999, 2 /*next chunk boundary*/ <<<按照约定chunk来查询数据，减少后续锁持有范围 2019-08-06T07:34:07.112558Z 81 Query SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `ptosc`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= '1')) ORDER BY `id` LIMIT 999, 2 /*next chunk boundary*/ 2019-08-06T07:34:07.113002Z 81 Query EXPLAIN SELECT `id`, `k`, `c`, `pad` FROM `ptosc`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= '1')) AND ((`id` <= '1000')) LOCK IN SHARE MODE /*explain pt-online-schema-change 133584 copy nibble*/ 2019-08-06T07:34:07.113349Z 81 Query INSERT LOW_PRIORITY IGNORE INTO `ptosc`.`_sbtest1_new` (`id`, `k`, `c`, `pad`) SELECT `id`, `k`, `c`, `pad` FROM `ptosc`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= '1')) AND ((`id` <= '1000')) LOCK IN SHARE MODE /*pt-online-schema-change 133584 copy nibble*/ <<<<向新表中批量插入数据 2019-08-06T07:34:07.190021Z 81 Query SHOW WARNINGS 2019-08-06T07:34:07.190352Z 81 Query SHOW GLOBAL STATUS LIKE 'Threads_running' <<检查一次批量后，mysql thread running负载情况，满足条件，继续下批量循环 2019-08-06T07:34:07.192028Z 81 Query EXPLAIN SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `ptosc`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= '1001')) ORDER BY `id` LIMIT 6526, 2 /*next chunk boundary*/ 2019-08-06T07:34:07.192349Z 81 Query SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `ptosc`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= '1001')) ORDER BY `id` LIMIT 6526, 2 /*next chunk boundary*/ 2019-08-06T07:34:07.194379Z 81 Query EXPLAIN SELECT `id`, `k`, `c`, `pad` FROM `ptosc`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= '1001')) AND ((`id` <= '20450')) LOCK IN SHARE MODE /*explain pt-online-schema-change 133584 copy nibble*/ 2019-08-06T07:34:07.194697Z 81 Query INSERT LOW_PRIORITY IGNORE INTO `ptosc`.`_sbtest1_new` (`id`, `k`, `c`, `pad`) SELECT `id`, `k`, `c`, `pad` FROM `ptosc`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= '1001')) AND ((`id` <= '20450')) LOCK IN SHARE MODE /*pt-online-schema-change 133584 copy nibble*/ 2019-08-06T07:34:07.416409Z 81 Query SHOW WARNINGS 2019-08-06T07:34:07.416753Z 81 Query SHOW GLOBAL STATUS LIKE 'Threads_running' ..... 2019-08-06T07:34:07.771898Z 81 Query SHOW VARIABLES LIKE 'version%' 2019-08-06T07:34:07.773669Z 81 Query SHOW ENGINES 2019-08-06T07:34:07.773975Z 81 Query SHOW VARIABLES LIKE 'innodb_version' 2019-08-06T07:34:07.775721Z 81 Query ANALYZE TABLE `ptosc`.`_sbtest1_new` /* pt-online-schema-change */ <<<收集新表统计信息 2019-08-06T07:34:07.779636Z 81 Query RENAME TABLE `ptosc`.`sbtest1` TO `ptosc`.`_sbtest1_old`, `ptosc`.`_sbtest1_new` TO `ptosc`.`sbtest1` <<<rename 表，交换表名 2019-08-06T07:34:07.783906Z 81 Query DROP TABLE IF EXISTS `ptosc`.`_sbtest1_old` <<<默认删除操作后的老表 2019-08-06T07:34:07.807794Z 81 Query DROP TRIGGER IF EXISTS `ptosc`.`pt_osc_ptosc_sbtest1_del` 2019-08-06T07:34:07.808163Z 81 Query DROP TRIGGER IF EXISTS `ptosc`.`pt_osc_ptosc_sbtest1_upd` 2019-08-06T07:34:07.808467Z 81 Query DROP TRIGGER IF EXISTS `ptosc`.`pt_osc_ptosc_sbtest1_ins` <<<<删除pt-osc工具创建的trigger 2019-08-06T07:34:07.808877Z 81 Query SHOW TABLES FROM `ptosc` LIKE '\_sbtest1\_new' <<<查看表结构信息 2019-08-06T07:34:07.809315Z 82 Quit 2019-08-06T07:34:07.809400Z 81 Quit
3、表常用修改操作
如果要验证查看将
–execute 替换成–print –dry-run
添加删除索引
pt-online-schema-change --host=10.148.180.103 --port=3307 --user=mzhang --password=mzhang \ --alter "DROP KEY idx_01, ADD KEY idx_02(c5) " \ D=ptosc,t=sbtest1 --execute --recursion-method=none
添加列字段
pt-online-schema-change --host=10.148.180.103 --port=3307 --user=mzhang --password=mzhang \ --alter "add column c5 varchar(8) not null default '' " \ D=ptosc,t=sbtest1 --execute --recursion-method=none
修改列类型
pt-online-schema-change --host=10.148.180.103 --port=3307 --user=mzhang --password=mzhang \ --alter "CHANGE c5 varchar(60) NOT NULL DEFAULT '' " \ D=ptosc,t=sbtest1 --execute --recursion-method=none
修改删除主键
使用pt-osc去修改删除主键，务必同时添加原主键为 UNIQUE KEY，否则触发delete操作时很有可能导致性能问题
DELETE 触发器：新表上_sbtest1_new的主键字段在旧表sbtest1上不存在，无法根据主键条件触发删除新表_sbtest1_new数据，所以pt-osc修改了trigger
非沙删除主键：CREATE TRIGGER `pt_osc_ptosc_sbtest1_del` AFTER DELETE ON `ptosc`.`sbtest1` FOR EACH ROW DELETE IGNORE FROM `ptosc`.`_sbtest1_new` WHERE `ptosc`.`_sbtest1_new`.`id` <=> OLD.`id`
CREATE TRIGGER `pt_osc_ptosc_sbtest1_del` AFTER DELETE ON `ptosc`.`sbtest1` FOR EACH ROW DELETE IGNORE FROM `ptosc`.`_sbtest1_new` WHERE `ptosc`.`_sbtest1_new`.`id` <=> OLD.`id` AND `ptosc`.`_sbtest1_new`.`k` <=> OLD.`k`
pt-online-schema-change --host=10.148.180.103 --port=3307 --user=mzhang --password=mzhang \ --alter "DROP PRIMARY KEY,add column pk int auto_increment primary key,add unique key uk_id_k(id,k)" \ D=ptosc,t=sbtest1 --execute --recursion-method=none
mysql5.7 1032 1062自动化修复
mysql5.7 1032 1062自动修复
随着mysql MS批量式线上部署，带来的问题也较多，今天我们就介绍一下最棘手的一个问题：复制中断，我们该怎么办？
遇到最多的是1032和1062错误，至于错误的原理，这里不想过多分析：记住一条即可，mysql是基于逻辑的复制。很多网上教程使用slave_skip_errors进行跳过（这是掩耳盗铃）；在我们的环境里是禁止的。手工修复，这里也不废话：结合业务和报错位置利用mysqlbinlog工具找出报错位置进行解决即可，速度太慢；结合历史的操作中，整个恢复过程估计需要30min-1h，还是需要熟悉业务。为了解决这个问题，利用python写了一个复制报错的1032和1062自动化修复脚本
脚本见https://github.com/trsenzhang/AOMmysql/项目中的replCheckStatus.py
感觉还可以请:star一下，哈哈
满足如下条件可自动修复1032和1062导致复制中断的错误：
1.数据库的binlog是基于ROW格式
2.binlog版本为v4
3.数据库的版本为5.7
4.脚本运行在slave端
5.在进行大批量的数据修复时，拉去master端binlog时，会导致MS之间网络带宽消耗
6.实际上生产中，建议自己的测试环境中测试后，
mysql> select * from sbtest1 where id>=99800; +-------+-----+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ | id | k | c | pad | +-------+-----+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ | 99811 | 100 | 90165491267-07275869234-19011205074-26444610383-72122436809-46694151734-03204627361-95242202339-88068233961-87971936484 | 89276814852-51067567943-14894208093-22203139505-76590959776 | | 99831 | 100 | 33781043000-25534118395-26582187843-30125017791-34879940111-81915141800-78796130797-48796519170-69301562901-89603068188 | 21473874594-31729191357-49416492581-96928763763-88555030957 | | 99850 | 100 | 52997681569-07256577082-70696020254-58728313014-64278657880-11737495601-96272462709-19907083505-55161413902-04166827371 | 03943355714-15233939093-77191977933-80871069856-13998664867 | | 99860 | 100 | 22149089534-99257768432-42374479937-27983548918-34777085571-60122511474-68156039839-93575679803-25858461064-38693071750 | 61706698622-03408243288-81616510318-77675951439-83647865812 | | 99866 | 100 | 97130276471-62038331816-81543705125-03598493850-89399270787-00769389132-67423665424-86329756265-55055790846-35049166232 | 29710875742-96213160947-25350860664-06705248824-91892213385 | | 99887 | 100 | 69817170669-41710523781-33204590013-59847767425-06017308425-48878655484-03102622366-86054674368-67448987765-56237448865 | 77033115449-02879844350-86983597796-12759679132-70415094822 | | 99897 | 100 | 37254441279-25082190545-71567616264-11611592521-17733316489-36596964903-46764438796-48309081109-47254822344-70662900915 | 45935391601-84007613456-49474460762-07492663463-61332150729 | | 99949 | 100 | | 34580886030-82638848912-17448500901-05181865304-45488435594 | | 99968 | 100 | | 00859334580-40505270334-09446901828-56582294486-93512954382 | +-------+-----+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ mysql> delete from sbtest1 where id>=99800; Query OK, 9 rows affected (0.02 sec) mysql> select * from sbtest1 where id>=99800; Empty set (0.00 sec)
1.模拟一条数据删除操作
update trsen.sbtest1 set c='111111111111' where id=99968; delete from trsen.sbtest1 where id=99949;
利用脚本修复后结果如下:
slave端数据 mysql> select * from sbtest1 where id>=99800; +-------+-----+--------------+-------------------------------------------------------------+ | id | k | c | pad | +-------+-----+--------------+-------------------------------------------------------------+ | 99968 | 100 | 111111111111 | 00859334580-40505270334-09446901828-56582294486-93512954382 | +-------+-----+--------------+-------------------------------------------------------------+
master端数据:
因为99811-99897区间数据还没有进行操作，主从复制不会出现sql_thread异常 mysql> select * from sbtest1 where id>=99800; +-------+-----+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ | id | k | c | pad | +-------+-----+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ | 99811 | 100 | 90165491267-07275869234-19011205074-26444610383-72122436809-46694151734-03204627361-95242202339-88068233961-87971936484 | 89276814852-51067567943-14894208093-22203139505-76590959776 | | 99831 | 100 | 33781043000-25534118395-26582187843-30125017791-34879940111-81915141800-78796130797-48796519170-69301562901-89603068188 | 21473874594-31729191357-49416492581-96928763763-88555030957 | | 99850 | 100 | 52997681569-07256577082-70696020254-58728313014-64278657880-11737495601-96272462709-19907083505-55161413902-04166827371 | 03943355714-15233939093-77191977933-80871069856-13998664867 | | 99860 | 100 | 22149089534-99257768432-42374479937-27983548918-34777085571-60122511474-68156039839-93575679803-25858461064-38693071750 | 61706698622-03408243288-81616510318-77675951439-83647865812 | | 99866 | 100 | 97130276471-62038331816-81543705125-03598493850-89399270787-00769389132-67423665424-86329756265-55055790846-35049166232 | 29710875742-96213160947-25350860664-06705248824-91892213385 | | 99887 | 100 | 69817170669-41710523781-33204590013-59847767425-06017308425-48878655484-03102622366-86054674368-67448987765-56237448865 | 77033115449-02879844350-86983597796-12759679132-70415094822 | | 99897 | 100 | 37254441279-25082190545-71567616264-11611592521-17733316489-36596964903-46764438796-48309081109-47254822344-70662900915 | 45935391601-84007613456-49474460762-07492663463-61332150729 | | 99968 | 100 | 111111111111 | 00859334580-40505270334-09446901828-56582294486-93512954382 | +-------+-----+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
2.模拟批量删除和更新
update trsen.sbtest1 set c='222222222' where id>=99811 and id<=99850; delete from trsen.sbtest1 where id >=99860 and id <=99968
slave端数据:
mysql> select * from sbtest1 where id>=99800; +-------+-----+-----------+-------------------------------------------------------------+ | id | k | c | pad | +-------+-----+-----------+-------------------------------------------------------------+ | 99811 | 100 | 222222222 | 89276814852-51067567943-14894208093-22203139505-76590959776 | | 99831 | 100 | 222222222 | 21473874594-31729191357-49416492581-96928763763-88555030957 | | 99850 | 100 | 222222222 | 03943355714-15233939093-77191977933-80871069856-13998664867 | +-------+-----+-----------+-------------------------------------------------------------+ 3 rows in set (0.00 sec)
master端数据
mysql> select * from sbtest1 where id>=99800; +-------+-----+-----------+-------------------------------------------------------------+ | id | k | c | pad | +-------+-----+-----------+-------------------------------------------------------------+ | 99811 | 100 | 222222222 | 89276814852-51067567943-14894208093-22203139505-76590959776 | | 99831 | 100 | 222222222 | 21473874594-31729191357-49416492581-96928763763-88555030957 | | 99850 | 100 | 222222222 | 03943355714-15233939093-77191977933-80871069856-13998664867 | +-------+-----+-----------+-------------------------------------------------------------+ 3 rows in set (0.00 sec)
测试中日志信息如下：
[root@dzst151 log]# more auto_check_repl_status_repair-2019-07-02.log 2019-07-02 16:00:17.522898 : INFO : The platform check pass. 2019-07-02 16:00:17.522898 : INFO : get_rpl_mode r -> ON 2019-07-02 16:00:17.522898 : INFO : rpl_mode 1 2019-07-02 16:00:17.522898 : INFO : 1032 2019-07-02 16:00:17.522898 : INFO : multi dml have SMTM_END_F,is ok. 2019-07-02 16:00:17.522898 : INFO : end_log_pos :2646 2019-07-02 16:00:17.522898 : INFO : row_recode : ['---line---', '### DELETE `trsen`.`sbtest1`', '### WHERE', '### @1=99949', '### @2=100', "### @3=''", "### @4='34580886030-82638848912-17448500901-05181865304-45488435594'", ' ---line---'] 2019-07-02 16:00:17.522898 : INFO : sql_list : ['DELETE `trsen`.`sbtest1`', 'WHERE', 'id=99949', 'and k=100', "and c=''", "and pad='34580886030-82638848912-17448500901-05181865304-45488435594'", '---line---'] 2019-07-02 16:00:17.522898 : INFO : will execute sql: SELECT 1 from `trsen`.`sbtest1` WHERE id=99949 and k=100 and c='' and pad='34580886030-82638848912-17448500901-05181865304-45488435594'; 2019-07-02 16:00:17.522898 : INFO : slave execute sql: error:1032 --run SQL: INSERT INTO `trsen`.`sbtest1` VALUES( 99949 , 100 , '' , '34580886030-82638848912-17448500901-05181865304-45488435594'); 2019-07-02 16:00:17.522898 : INFO : slave repaired. 2019-07-02 16:01:10.580024 : INFO : The platform check pass. 2019-07-02 16:01:10.580024 : INFO : get_rpl_mode r -> ON 2019-07-02 16:01:10.580024 : INFO : rpl_mode 1 2019-07-02 16:01:10.580024 : INFO : 1032 2019-07-02 16:01:10.580024 : INFO : multi dml have SMTM_END_F,is ok. 2019-07-02 16:01:10.580024 : INFO : end_log_pos :3138 2019-07-02 16:01:10.580024 : INFO : row_recode : ['---line---', '### UPDATE `trsen`.`sbtest1`', '### WHERE', '### @1=99968', '### @2=100', "### @3=''", "### @4='00859334580-40505270334-09446901828-56582294486-93512954382'", ' ---line---'] 2019-07-02 16:01:10.580024 : INFO : sql_list : ['UPDATE `trsen`.`sbtest1`', 'WHERE', 'id=99968', 'and k=100', "and c=''", "and pad='00859334580-40505270334-09446901828-56582294486-93512954382'", '---line---'] 2019-07-02 16:01:10.580024 : INFO : will execute sql: SELECT 1 from `trsen`.`sbtest1` WHERE id=99968 and k=100 and c='' and pad='00859334580-40505270334-09446901828-56582294486-93512954382'; 2019-07-02 16:01:10.580024 : INFO : slave execute sql: error:1032 --run SQL: INSERT INTO `trsen`.`sbtest1` VALUES( 99968 , 100 , '' , '00859334580-40505270334-09446901828-56582294486-93512954382'); 2019-07-02 16:01:10.580024 : INFO : slave repaired. 2019-07-02 16:05:30.649844 : INFO : The platform check pass. 2019-07-02 16:05:30.649844 : INFO : get_rpl_mode r -> ON 2019-07-02 16:05:30.649844 : INFO : rpl_mode 1 2019-07-02 16:05:30.649844 : INFO : 1032 2019-07-02 16:05:30.649844 : INFO : multi dml have SMTM_END_F,is ok. 2019-07-02 16:05:30.649844 : INFO : end_log_pos :4303 2019-07-02 16:05:30.649844 : INFO : row_recode : ['---line---', '### UPDATE `trsen`.`sbtest1`', '### WHERE', '### @1=99811', '### @2=100', "### @3='90165491267-07275869234-19011205074-26444610383-72122436809-46694151734-0320462 7361-95242202339-88068233961-87971936484'", "### @4='89276814852-51067567943-14894208093-22203139505-76590959776'", '---line---', '### UPDATE `trsen`.`sbtest1`', '### WHERE', '### @1=99831', '### @2=100', "### @3='33781043000 -25534118395-26582187843-30125017791-34879940111-81915141800-78796130797-48796519170-69301562901-89603068188'", "### @4='21473874594-31729191357-49416492581-96928763763-88555030957'", '---line---', '### UPDATE `trsen`.`sbtest1`', ' ### WHERE', '### @1=99850', '### @2=100', "### @3='52997681569-07256577082-70696020254-58728313014-64278657880-11737495601-96272462709-19907083505-55161413902-04166827371'", "### @4='03943355714-15233939093-77191977933-808710 69856-13998664867'", '---line---'] 2019-07-02 16:05:30.649844 : INFO : sql_list : ['UPDATE `trsen`.`sbtest1`', 'WHERE', 'id=99811', 'and k=100', "and c='90165491267-07275869234-19011205074-26444610383-72122436809-46694151734-03204627361-95242202339-88068233961-8797193 6484'", "and pad='89276814852-51067567943-14894208093-22203139505-76590959776'", '---line---', 'UPDATE `trsen`.`sbtest1`', 'WHERE', 'id=99831', 'and k=100', "and c='33781043000-25534118395-26582187843-30125017791-34879940111-81915141 800-78796130797-48796519170-69301562901-89603068188'", "and pad='21473874594-31729191357-49416492581-96928763763-88555030957'", '---line---', 'UPDATE `trsen`.`sbtest1`', 'WHERE', 'id=99850', 'and k=100', "and c='52997681569-072565770 82-70696020254-58728313014-64278657880-11737495601-96272462709-19907083505-55161413902-04166827371'", "and pad='03943355714-15233939093-77191977933-80871069856-13998664867'", '---line---'] 2019-07-02 16:05:30.649844 : INFO : will execute sql: SELECT 1 from `trsen`.`sbtest1` WHERE id=99811 and k=100 and c='90165491267-07275869234-19011205074-26444610383-72122436809-46694151734-03204627361-95242202339-88068233961-879719 36484' and pad='89276814852-51067567943-14894208093-22203139505-76590959776'; 2019-07-02 16:05:30.649844 : INFO : slave execute sql: error:1032 --run SQL: INSERT INTO `trsen`.`sbtest1` VALUES( 99811 , 100 , '90165491267-07275869234-19011205074-26444610383-72122436809-46694151734-03204627361-95242202339-88068 233961-87971936484' , '89276814852-51067567943-14894208093-22203139505-76590959776'); 2019-07-02 16:05:30.649844 : INFO : will execute sql: SELECT 1 from `trsen`.`sbtest1` WHERE id=99831 and k=100 and c='33781043000-25534118395-26582187843-30125017791-34879940111-81915141800-78796130797-48796519170-69301562901-896030 68188' and pad='21473874594-31729191357-49416492581-96928763763-88555030957'; 2019-07-02 16:05:30.649844 : INFO : slave execute sql: error:1032 --run SQL: INSERT INTO `trsen`.`sbtest1` VALUES( 99831 , 100 , '33781043000-25534118395-26582187843-30125017791-34879940111-81915141800-78796130797-48796519170-69301 562901-89603068188' , '21473874594-31729191357-49416492581-96928763763-88555030957'); 2019-07-02 16:05:30.649844 : INFO : will execute sql: SELECT 1 from `trsen`.`sbtest1` WHERE id=99850 and k=100 and c='52997681569-07256577082-70696020254-58728313014-64278657880-11737495601-96272462709-19907083505-55161413902-041668 27371' and pad='03943355714-15233939093-77191977933-80871069856-13998664867'; 2019-07-02 16:05:30.649844 : INFO : slave execute sql: error:1032 --run SQL: INSERT INTO `trsen`.`sbtest1` VALUES( 99850 , 100 , '52997681569-07256577082-70696020254-58728313014-64278657880-11737495601-96272462709-19907083505-55161 413902-04166827371' , '03943355714-15233939093-77191977933-80871069856-13998664867'); 2019-07-02 16:05:30.649844 : INFO : get_rpl_mode r -> ON 2019-07-02 16:05:30.649844 : INFO : rpl_mode 1 2019-07-02 16:05:30.649844 : INFO : 1032 2019-07-02 16:05:30.649844 : INFO : multi dml have SMTM_END_F,is ok. 2019-07-02 16:05:30.649844 : INFO : end_log_pos :5489 2019-07-02 16:05:30.649844 : INFO : row_recode : ['---line---', '### DELETE `trsen`.`sbtest1`', '### WHERE', '### @1=99860', '### @2=100', "### @3='22149089534-99257768432-42374479937-27983548918-34777085571-60122511474-6815603 9839-93575679803-25858461064-38693071750'", "### @4='61706698622-03408243288-81616510318-77675951439-83647865812'", '---line---', '### DELETE `trsen`.`sbtest1`', '### WHERE', '### @1=99866', '### @2=100', "### @3='97130276471 -62038331816-81543705125-03598493850-89399270787-00769389132-67423665424-86329756265-55055790846-35049166232'", "### @4='29710875742-96213160947-25350860664-06705248824-91892213385'", '---line---', '### DELETE `trsen`.`sbtest1`', ' ### WHERE', '### @1=99887', '### @2=100', "### @3='69817170669-41710523781-33204590013-59847767425-06017308425-48878655484-03102622366-86054674368-67448987765-56237448865'", "### @4='77033115449-02879844350-86983597796-127596 79132-70415094822'", '---line---', '### DELETE `trsen`.`sbtest1`', '### WHERE', '### @1=99897', '### @2=100', "### @3='37254441279-25082190545-71567616264-11611592521-17733316489-36596964903-46764438796-48309081109-47254822344- 70662900915'", "### @4='45935391601-84007613456-49474460762-07492663463-61332150729'", '---line---', '### DELETE `trsen`.`sbtest1`', '### WHERE', '### @1=99968', '### @2=100', "### @3='111111111111'", "### @4='00859334580-4 0505270334-09446901828-56582294486-93512954382'", '---line---'] 2019-07-02 16:05:30.649844 : INFO : sql_list : ['DELETE `trsen`.`sbtest1`', 'WHERE', 'id=99860', 'and k=100', "and c='22149089534-99257768432-42374479937-27983548918-34777085571-60122511474-68156039839-93575679803-25858461064-3869307 1750'", "and pad='61706698622-03408243288-81616510318-77675951439-83647865812'", '---line---', 'DELETE `trsen`.`sbtest1`', 'WHERE', 'id=99866', 'and k=100', "and c='97130276471-62038331816-81543705125-03598493850-89399270787-00769389 132-67423665424-86329756265-55055790846-35049166232'", "and pad='29710875742-96213160947-25350860664-06705248824-91892213385'", '---line---', 'DELETE `trsen`.`sbtest1`', 'WHERE', 'id=99887', 'and k=100', "and c='69817170669-417105237 81-33204590013-59847767425-06017308425-48878655484-03102622366-86054674368-67448987765-56237448865'", "and pad='77033115449-02879844350-86983597796-12759679132-70415094822'", '---line---', 'DELETE `trsen`.`sbtest1`', 'WHERE', 'id=998 97', 'and k=100', "and c='37254441279-25082190545-71567616264-11611592521-17733316489-36596964903-46764438796-48309081109-47254822344-70662900915'", "and pad='45935391601-84007613456-49474460762-07492663463-61332150729'", '---line--- ', 'DELETE `trsen`.`sbtest1`', 'WHERE', 'id=99968', 'and k=100', "and c='111111111111'", "and pad='00859334580-40505270334-09446901828-56582294486-93512954382'", '---line---'] 2019-07-02 16:05:30.649844 : INFO : will execute sql: SELECT 1 from `trsen`.`sbtest1` WHERE id=99860 and k=100 and c='22149089534-99257768432-42374479937-27983548918-34777085571-60122511474-68156039839-93575679803-25858461064-386930 71750' and pad='61706698622-03408243288-81616510318-77675951439-83647865812'; 2019-07-02 16:05:30.649844 : INFO : slave execute sql: error:1032 --run SQL: INSERT INTO `trsen`.`sbtest1` VALUES( 99860 , 100 , '22149089534-99257768432-42374479937-27983548918-34777085571-60122511474-68156039839-93575679803-25858 461064-38693071750' , '61706698622-03408243288-81616510318-77675951439-83647865812'); 2019-07-02 16:05:30.649844 : INFO : will execute sql: SELECT 1 from `trsen`.`sbtest1` WHERE id=99866 and k=100 and c='97130276471-62038331816-81543705125-03598493850-89399270787-00769389132-67423665424-86329756265-55055790846-350491 66232' and pad='29710875742-96213160947-25350860664-06705248824-91892213385'; 2019-07-02 16:05:30.649844 : INFO : slave execute sql: error:1032 --run SQL: INSERT INTO `trsen`.`sbtest1` VALUES( 99866 , 100 , '97130276471-62038331816-81543705125-03598493850-89399270787-00769389132-67423665424-86329756265-55055 790846-35049166232' , '29710875742-96213160947-25350860664-06705248824-91892213385'); 2019-07-02 16:05:30.649844 : INFO : will execute sql: SELECT 1 from `trsen`.`sbtest1` WHERE id=99887 and k=100 and c='69817170669-41710523781-33204590013-59847767425-06017308425-48878655484-03102622366-86054674368-67448987765-562374 48865' and pad='77033115449-02879844350-86983597796-12759679132-70415094822'; 2019-07-02 16:05:30.649844 : INFO : slave execute sql: error:1032 --run SQL: INSERT INTO `trsen`.`sbtest1` VALUES( 99887 , 100 , '69817170669-41710523781-33204590013-59847767425-06017308425-48878655484-03102622366-86054674368-67448 987765-56237448865' , '77033115449-02879844350-86983597796-12759679132-70415094822'); 2019-07-02 16:05:30.649844 : INFO : will execute sql: SELECT 1 from `trsen`.`sbtest1` WHERE id=99897 and k=100 and c='37254441279-25082190545-71567616264-11611592521-17733316489-36596964903-46764438796-48309081109-47254822344-706629 00915' and pad='45935391601-84007613456-49474460762-07492663463-61332150729'; 2019-07-02 16:05:30.649844 : INFO : slave execute sql: error:1032 --run SQL: INSERT INTO `trsen`.`sbtest1` VALUES( 99897 , 100 , '37254441279-25082190545-71567616264-11611592521-17733316489-36596964903-46764438796-48309081109-47254 822344-70662900915' , '45935391601-84007613456-49474460762-07492663463-61332150729'); 2019-07-02 16:05:30.649844 : INFO : will execute sql: SELECT 1 from `trsen`.`sbtest1` WHERE id=99968 and k=100 and c='111111111111' and pad='00859334580-40505270334-09446901828-56582294486-93512954382'; 2019-07-02 16:05:30.649844 : INFO : slave repaired.