目录
percona-toolkit工具（数据一致性监测、延迟监控）使用梳理
pt-table-checksum与pt-table-sync使用
pt-table-checksum使用dsn方式连接检测从库
percona-toolkit工具（数据一致性监测、延迟监控）使用梳理
参考资料：https://www.cnblogs.com/kevingrace/p/6261091.html
参考资料：https://www.cnblogs.com/gered/p/12882447.html
参考资料：https://www.cnblogs.com/wanbin/p/9899598.html
percona-toolkit工具安装
rpm -e perl-IO-Socket-SSL perl-DBD-MySQL perl-Time-HiRes perl perl-DBI perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker perl-Digest-MD5 --nodeps #卸载原有pt依赖包
rpm -e $(rpm -qf $(which pt-table-checksum)) --nodeps #卸载原有pt软件包
yum install perl-IO-Socket-SSL perl-DBD-MySQL perl-Time-HiRes perl perl-DBI perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker perl-Digest-MD5 #安装新的pt依赖包
#########################################
percona-toolkit-3.3.1-1.el7.x86_64.rpm下载
链接：https://pan.baidu.com/s/1LlLjR1FcXauEqe1AotO_KA
提取码：1221
#########################################
rpm -ivh percona-toolkit-3.3.1-1.el7.x86_64.rpm #安装新的pt软件包
查看帮助:
# pt-**** --helppt-table-checksum与pt-table-sync使用
主库ip：192.168.220.108 mysql 5.7.42 centos7.9
从库ip：192.168.220.128 mysql 5.7.42 centos7.9
从库(主从已同步)： #前提条件
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.220.108
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000029
Read_Master_Log_Pos: 154
Relay_Log_File: zabbix-agent-relay-bin.000037
Relay_Log_Pos: 367
Relay_Master_Log_File: mysql-bin.000029
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 154
Relay_Log_Space: 794
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: d29fd3a8-0b26-11ee-85e3-000c29d1462e
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
主库(授权用户登录)：
mysql> set global validate_password_policy=0;
Query OK, 0 rows affected (0.00 sec)
mysql> set global validate_password_length=1;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE,CREATE,DELETE,INSERT,UPDATE ON *.* TO 'ceshi1'@'192.168.220.108' identified by '123456';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
从库(授权主库登录)：
mysql> set global validate_password_policy=0;
Query OK, 0 rows affected (0.00 sec)
mysql> set global validate_password_length=1;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO 'ceshi1'@'192.168.220.108' IDENTIFIED BY '123456';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
主库；
[root@master ~]# pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=test.checksums --create-replicate-table --databases=test --tables=orders h=192.168.220.108,u=ceshi1,p=123456,P=3306 #第一次加--create-replicate-table参数后面不用
Cannot connect to P=3306,h=192.168.45.128,p=...,u=ceshi1 ##无法连接到从库原因见第二章：pt-table-checksum使用dsn方式连接检测从库
Diffs cannot be detected because no slaves were found. Please read the --recursion-method documentation for information.
*******************************************************************
Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
is deprecated! Please set SSL_verify_mode to SSL_VERIFY_PEER
possibly with SSL_ca_file|SSL_ca_path for verification.
If you really don't want to verify the certificate and keep the
connection open to Man-In-The-Middle attacks please set
SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
*******************************************************************
at /usr/bin/pt-table-checksum line 331.
*******************************************************************
Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
is deprecated! Please set SSL_verify_mode to SSL_VERIFY_PEER
possibly with SSL_ca_file|SSL_ca_path for verification.
If you really don't want to verify the certificate and keep the
connection open to Man-In-The-Middle attacks please set
SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
*******************************************************************
at /usr/bin/pt-table-checksum line 331.
# A software update is available:
# * The current version for Percona::Toolkit is 3.0.5
TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE
09-14T11:39:00 0 0 5 0 1 0 0.019 test.orders
处理完无法连接从库问题后主库执行；
[root@master ~]# pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=test.checksums --databases=test --tables=orders h=192.168.220.108,u=ceshi1,p=123456,P=3306 #第一次加--create-replicate-table参数后面不用
Checking if all tables can be checksummed ...
Starting checksum ...
TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE
09-14T11:39:00 0 1 5 0 1 0 0.019 test.orders
[root@master ~]# pt-table-sync --replicate=test.checksums h=192.168.220.108,u=ceshi1,p=123456,P=3306 h=192.168.220.128,u=ceshi1,p=123456,P=3306 --print
REPLACE INTO `test`.`orders`(`order_num`, `order_date`, `cust_id`) VALUES ('20009', '2005-10-08 00:00:00', '10001') /*percona-toolkit src_db:test src_tbl:orders src_dsn:P=3306,h=192.168.220.108,p=...,u=ceshi1 dst_db:test dst_tbl:orders dst_dsn:P=3306,h=192.168.220.128,p=...,u=ceshi1 lock:1 transaction:1 changing_src:test.checksums replicate:test.checksums bidirectional:0 pid:7570 user:root host:centos7*/;
##说明：REPLACE INTO `test`.`orders`(`order_num`, `order_date`, `cust_id`) VALUES ('20009', '2005-10-08 00:00:00', '10001')从库执行此SQL语句，数据来源为主库(主库信息src_db:test src_tbl:orders src_dsn:P=3306,h=192.168.220.108,p=...,u=ceshi1)，在从库更新数据(从库信息dst_db:test dst_tbl:orders dst_dsn:P=3306,h=192.168.220.128,p=...,u=ceshi1)
[root@centos7 mysql_script]# pt-table-sync --replicate=test.checksums h=192.168.220.108,u=ceshi1,p=123456,P=3306 h=192.168.220.128,u=ceshi1,p=123456,P=3306 --execute
Cannot delete or update a parent row: a foreign key constraint fails (`test`.`orderitems`, CONSTRAINT `fk_orderitems_orders` FOREIGN KEY (`order_num`) REFERENCES `orders` (`order_num`)) [for Statement "REPLACE INTO `test`.`orders`(`order_num`, `order_date`, `cust_id`) VALUES ('20009', '2005-10-08 00:00:00', '10001') /*percona-toolkit src_db:test src_tbl:orders src_dsn:P=3306,h=192.168.220.108,p=...,u=ceshi1 dst_db:test dst_tbl:orders dst_dsn:P=3306,h=192.168.220.128,p=...,u=ceshi1 lock:1 transaction:1 changing_src:test.checksums replicate:test.checksums bidirectional:0 pid:7576 user:root host:centos7*/"] at line 10950 while doing test.orders on 192.168.220.128
##说明：从库更新数据，执行语句REPLACE INTO `test`.`orders`(`order_num`, `order_date`, `cust_id`) VALUES ('20009', '2005-10-08 00:00:00', '10001')报错，报错原因为外键约束(`test`.`orderitems`, CONSTRAINT `fk_orderitems_orders` FOREIGN KEY (`order_num`) REFERENCES `orders` (`order_num`))
##处理办法：在主库表上删除外键约束，修复从数据库后在主库手工添加约束
[root@master ~]# mysql test -uroot -pxxxxxx <<EOF #删除外键约束
> alter table orderitems drop foreign key fk_orderitems_orders;
> EOF
mysql: [Warning] Using a password on the command line interface can be insecure.
[root@master ~]# pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=test.checksums --databases=test --tables=orders h=192.168.220.108,u=ceshi1,p=123456,P=3306
Checking if all tables can be checksummed ...
Starting checksum ...
TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE
09-14T17:43:37 0 1 5 0 1 0 0.015 test.orders
[root@master ~]# pt-table-sync --replicate=test.checksums h=192.168.220.108,u=ceshi1,p=123456,P=3306 h=192.168.220.128,u=ceshi1,p=123456,P=3306 --print
REPLACE INTO `test`.`orders`(`order_num`, `order_date`, `cust_id`) VALUES ('20009', '2005-10-08 00:00:00', '10001') /*percona-toolkit src_db:test src_tbl:orders src_dsn:P=3306,h=192.168.220.108,p=...,u=ceshi1 dst_db:test dst_tbl:orders dst_dsn:P=3306,h=192.168.220.128,p=...,u=ceshi1 lock:1 transaction:1 changing_src:test.checksums replicate:test.checksums bidirectional:0 pid:7945 user:root host:centos7*/;
[root@master ~]# pt-table-sync --replicate=test.checksums h=192.168.220.108,u=ceshi1,p=123456,P=3306 h=192.168.220.128,u=ceshi1,p=123456,P=3306 --execute
[root@master ~]# pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=test.checksums --databases=test --tables=orders h=192.168.220.108,u=ceshi1,p=123456,P=3306
Checking if all tables can be checksummed ...
Starting checksum ...
TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE
09-14T17:44:02 0 0 5 0 1 0 0.019 test.orders
[root@master ~]# mysql test -uroot -pxxxxxx <<EOF #添加约束
alter table test.orderitems add CONSTRAINT fk_orderitems_orders FOREIGN KEY (order_num) REFERENCES orders (order_num);
EOF
mysql: [Warning] Using a password on the command line interface can be insecure.
操作多表与库；
[root@master ~]# pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=test.checksums --databases=test --tables=aaa,bbb h=192.168.220.108,u=ceshi1,p=123456,P=3306 #--tables= ：指定执行同步的表，多个用逗号隔开
Checking if all tables can be checksummed ...
Starting checksum ...
TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE
05-23T23:30:21 0 1 5 2 1 0 0.017 test.aaa
05-23T23:30:21 0 1 0 1 1 0 0.055 test.bbb
[root@master ~]# pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=test.checksums --databases=test h=192.168.220.108,u=ceshi1,p=123456,P=3306 #--databases= : 指定执行同步的数据库，使用逗号添加多库
Checking if all tables can be checksummed ...
Starting checksum ...
TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE
05-23T23:31:34 0 1 5 2 1 0 0.017 test.aaa
05-23T23:31:34 0 1 0 1 1 0 0.014 test.bbb
05-23T23:31:34 0 0 5 0 1 0 0.014 test.customers
05-23T23:31:34 0 0 11 0 1 0 0.014 test.orderitems
05-23T23:31:34 0 0 5 0 1 0 0.014 test.orders
05-23T23:31:34 0 0 14 0 1 0 0.017 test.productnotes
05-23T23:31:34 0 0 14 0 1 0 0.015 test.products
05-23T23:31:34 0 0 6 0 1 0 0.014 test.vendors
[root@master ~]# pt-table-sync --replicate=test.checksums h=192.168.220.108,u=ceshi1,p=123456 h=192.168.220.128,u=ceshi1,p=123456 --print #--print ：打印，但不执行命令
DELETE FROM `test`.`aaa` WHERE `id`='1111' LIMIT 1 /*percona-toolkit src_db:test src_tbl:aaa src_dsn:h=192.168.220.108,p=...,u=check dst_db:test dst_tbl:aaa dst_dsn:h=192.168.220.128,p=...,u=check lock:1 transaction:1 changing_src:test.checksums replicate:test.checksums bidirectional:0 pid:3926 user:root host:master*/;
DELETE FROM `test`.`aaa` WHERE `id`='1112' LIMIT 1 /*percona-toolkit src_db:test src_tbl:aaa src_dsn:h=192.168.220.108,p=...,u=check dst_db:test dst_tbl:aaa dst_dsn:h=192.168.220.128,p=...,u=check lock:1 transaction:1 changing_src:test.checksums replicate:test.checksums bidirectional:0 pid:3926 user:root host:master*/;
DELETE FROM `test`.`bbb` WHERE `id`='1112' LIMIT 1 /*percona-toolkit src_db:test src_tbl:bbb src_dsn:h=192.168.220.108,p=...,u=check dst_db:test dst_tbl:bbb dst_dsn:h=192.168.220.128,p=...,u=check lock:1 transaction:1 changing_src:test.checksums replicate:test.checksums bidirectional:0 pid:3926 user:root host:master*/;
[root@master ~]# pt-table-sync --replicate=test.checksums h=192.168.220.108,u=ceshi1,p=123456 h=192.168.220.128,u=ceshi1,p=123456 --execute #--execute ：执行命令
[root@master ~]# pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=test.checksums --databases=test h=192.168.220.108,u=ceshi1,p=123456,P=3306
Checking if all tables can be checksummed ...
Starting checksum ...
TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE
05-23T23:32:07 0 0 5 0 1 0 0.036 test.aaa
05-23T23:32:07 0 0 0 0 1 0 0.013 test.bbb
05-23T23:32:07 0 0 5 0 1 0 0.017 test.customers
05-23T23:32:07 0 0 11 0 1 0 0.014 test.orderitems
05-23T23:32:07 0 0 5 0 1 0 0.014 test.orders
05-23T23:32:07 0 0 14 0 1 0 0.014 test.productnotes
05-23T23:32:07 0 0 14 0 1 0 0.025 test.products
05-23T23:32:07 0 0 6 0 1 0 0.013 test.vendors
数据恢复脚本编写：
[root@master ~]# cat pt-table-sync.sh
#!/bin/bash
pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=test.checksums --databases=test h=192.168.220.108,u=ceshi1,p=123456,P=3306
for value in `pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=test.checksums --databases=test h=192.168.220.108,u=ceshi1,p=123456,P=3306|awk '{print $3}'|sed -n '4,$p'`
do
if [ "$value" -eq 1 ]
then
pt-table-sync --replicate=test.checksums h=192.168.220.108,u=ceshi1,p=123456 h=192.168.220.128,u=ceshi1,p=123456 --print
pt-table-sync --replicate=test.checksums h=192.168.220.108,u=ceshi1,p=123456 h=192.168.220.128,u=ceshi1,p=123456 --execute
break
fi
done
pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=test.checksums --databases=test h=192.168.220.108,u=ceshi1,p=123456,P=3306
[root@master ~]# sh pt-table-sync.sh
Checking if all tables can be checksummed ...
Starting checksum ...
TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE
05-24T03:58:01 0 0 5 0 1 0 0.044 test.aaa
05-24T03:58:01 0 1 0 1 1 0 0.014 test.bbb
05-24T03:58:01 0 0 5 0 1 0 0.016 test.customers
05-24T03:58:01 0 0 11 0 1 0 0.026 test.orderitems
05-24T03:58:01 0 0 5 0 1 0 0.015 test.orders
05-24T03:58:01 0 0 14 0 1 0 0.021 test.productnotes
05-24T03:58:01 0 0 14 0 1 0 0.016 test.products
05-24T03:58:01 0 0 6 0 1 0 0.014 test.vendors
DELETE FROM `test`.`bbb` WHERE `id`='1113' LIMIT 1 /*percona-toolkit src_db:test src_tbl:bbb src_dsn:h=192.168.220.108,p=...,u=check dst_db:test dst_tbl:bbb dst_dsn:h=192.168.220.128,p=...,u=check lock:1 transaction:1 changing_src:test.checksums replicate:test.checksums bidirectional:0 pid:10607 user:root host:master*/;
Checking if all tables can be checksummed ...
Starting checksum ...
TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE
05-24T03:58:02 0 0 5 0 1 0 0.014 test.aaa
05-24T03:58:02 0 0 0 0 1 0 0.014 test.bbb
05-24T03:58:02 0 0 5 0 1 0 0.017 test.customers
05-24T03:58:02 0 0 11 0 1 0 0.016 test.orderitems
05-24T03:58:02 0 0 5 0 1 0 0.015 test.orders
05-24T03:58:02 0 0 14 0 1 0 0.015 test.productnotes
05-24T03:58:02 0 0 14 0 1 0 0.017 test.products
05-24T03:58:02 0 0 6 0 1 0 0.017 test.vendors
##个人理解
在开启主从模式下主库数据变化从库一定随着变化。若出现不一致情况，一定是从库数据遭受篡改，pt-table-sync将从库数据恢复与主库一致。
另外说一个问题：
在上面的操作中，在主库里添加pt-table-checksum检查的权限（从库可以不授权）后，进行数据一致性检查操作，会在操作的库（实例中是huanqiu、huanpc）下产生一个checksums表！
这张checksums表是pt-table-checksum检查过程中产生的。这张表一旦产生了，默认是删除不了的，并且这张表所在的库也默认删除不了，删除后过一会儿就又会出来。
mysql> use huanqiu;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+-------------------+
| Tables_in_huanqiu |
+-------------------+
| checksums |
| haha |
+-------------------+
2 rows in set (0.00 sec)
mysql> drop table checksums;
Query OK, 0 rows affected (0.01 sec)
mysql> show tables;
+-------------------+
| Tables_in_huanqiu |
+-------------------+
| haha |
+-------------------+
1 row in set (0.00 sec)
mysql> show tables; //过一段时间再次查看，发现checksums表还在
+-------------------+
| Tables_in_huanqiu |
+-------------------+
| checksums |
| haha |
+-------------------+
2 rows in set (0.00 sec)
不仅这张表删除不了，这张表所在的库也删除不了，删除后过一会儿就是自动生成。
mysql> drop database huanqiu;
Query OK, 1 row affected (0.01 sec)
mysql> drop database huanpc;
Query OK, 1 row affected (0.02 sec)
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| huanqiu |
| mysql |
| performance_schema |
| test |
+--------------------+
5 rows in set (0.00 sec)
mysql> drop database huanqiu;
Query OK, 1 row affected (0.01 sec)
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| huanpc |
| huanqiu |
| mysql |
| performance_schema |
| test |
+--------------------+
6 rows in set (0.00 sec)
要想删除的话，一定要先把pt-table-checksum检查前添加的权限收回！
mysql> show grants for 'root'@'192.168.1.101';
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for root@192.168.1.101 |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO 'root'@'192.168.1.101' IDENTIFIED BY PASSWORD '*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9' |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> revoke SELECT, INSERT, UPDATE, DELETE, CREATE, PROCESS, SUPER, REPLICATION SLAVE ON *.* FROM 'root'@'192.168.1.101';
Query OK, 0 rows affected (0.01 sec)
mysql> show grants for 'root'@'192.168.1.101';
+-----------------------------------------------------------------------------------------------------------------+
| Grants for root@192.168.1.101 |
+-----------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'root'@'192.168.1.101' IDENTIFIED BY PASSWORD '*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9' |
+-----------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> select user,host,password from mysql.user;
+-------+---------------+-------------------------------------------+
| user | host | password |
+-------+---------------+-------------------------------------------+
| root | localhost | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 |
| root | master-server | |
| root | 127.0.0.1 | |
| root | ::1 | |
| | localhost | |
| | master-server | |
| root | 192.168.1.101 | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 |
| slave | 192.168.1.102 | *4F0FF134CC4C1A2872D972373A6AA86CA0A81872 |
+-------+---------------+-------------------------------------------+
8 rows in set (0.00 sec)
mysql> delete from mysql.user where user="root" and host="192.168.1.101"; //这一步其实不必操作，此步删除操作不能在上面revoke执行前进行，否则revoke回收权限失败！
Query OK, 1 row affected (0.00 sec)
mysql> select user,host,password from mysql.user;
+-------+---------------+-------------------------------------------+
| user | host | password |
+-------+---------------+-------------------------------------------+
| root | localhost | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 |
| root | master-server | |
| root | 127.0.0.1 | |
| root | ::1 | |
| | localhost | |
| | master-server | |
| slave | 192.168.1.102 | *4F0FF134CC4C1A2872D972373A6AA86CA0A81872 |
+-------+---------------+-------------------------------------------+
7 rows in set (0.00 sec)
权限删除后，就能成功删除checksums这张表和它所在的库了！
主库的checksums删除了，从库的这张表也会跟着删除
mysql> use huanpc;
Database changed
mysql> show tables;
+------------------+
| Tables_in_huanpc |
+------------------+
| checksums |
| heihei |
+------------------+
2 rows in set (0.00 sec)
mysql> drop table checksums;
Query OK, 0 rows affected (0.01 sec)
mysql> show tables;
+------------------+
| Tables_in_huanpc |
+------------------+
| heihei |
+------------------+
1 row in set (0.01 sec)
mysql> use huanqiu;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+-------------------+
| Tables_in_huanqiu |
+-------------------+
| checksums |
| haha |
+-------------------+
2 rows in set (0.00 sec)
mysql> drop table checksums;
Query OK, 0 rows affected (0.00 sec)
mysql> show tables;
+-------------------+
| Tables_in_huanqiu |
+-------------------+
| haha |
+-------------------+
1 row in set (0.00 sec)
也就是说，checksums表一旦产生，不仅这张表默认删除不了，连同它所在的库，要是想删除它们，只能如上操作先撤销权限。pt-heartbeat监控mysql主从复制延迟梳理
对于MySQL数据库主从复制延迟的监控，可以借助percona的有力武器pt-heartbeat来实现。
pt-heartbeat的工作原理通过使用时间戳方式在主库上更新特定表，然后在从库上读取被更新的时间戳然后与本地系统时间对比来得出其延迟。具体流程：
1）在主上创建一张heartbeat表，按照一定的时间频率更新该表的字段（把时间更新进去）。监控操作运行后，heartbeat表能促使主从同步！
2）连接到从库上检查复制的时间记录，和从库的当前系统时间进行比较，得出时间的差异。
使用方法（主从和从库上都可以执行监控操作）：
pt-heartbeat [OPTIONS] [DSN] --update|--monitor|--check|--stop
注意：需要指定的参数至少有 --stop，--update，--monitor，--check。
其中--update，--monitor和--check是互斥的，--daemonize和--check也是互斥。
--ask-pass 隐式输入MySQL密码
--charset 字符集设置
--check 检查从的延迟，检查一次就退出，除非指定了--recurse会递归的检查所有的从服务器。
--check-read-only 如果从服务器开启了只读模式，该工具会跳过任何插入。
--create-table 在主上创建心跳监控的表，如果该表不存在，可以自己手动建立，建议存储引擎改成memory。通过更新该表知道主从延迟的差距。
CREATE TABLE heartbeat (
ts varchar(26) NOT NULL,
server_id int unsigned NOT NULL PRIMARY KEY,
file varchar(255) DEFAULT NULL,
position bigint unsigned DEFAULT NULL,
relay_master_log_file varchar(255) DEFAULT NULL,
exec_master_log_pos bigint unsigned DEFAULT NULL
);
heratbeat 表一直在更改ts和position,而ts是我们检查复制延迟的关键。
--daemonize 执行时，放入到后台执行
--user=-u， 连接数据库的帐号
--database=-D， 连接数据库的名称
--host=-h， 连接的数据库地址
--password=-p， 连接数据库的密码
--port=-P， 连接数据库的端口
--socket=-S， 连接数据库的套接字文件
--file 【--file=output.txt】 打印--monitor最新的记录到指定的文件，很好的防止满屏幕都是数据的烦恼。
--frames 【--frames=1m,2m,3m】 在--monitor里输出的[]里的记录段，默认是1m,5m,15m。可以指定1个，如：--frames=1s，多个用逗号隔开。可用单位有秒（s）、分钟（m）、小时（h）、天（d）。
--interval 检查、更新的间隔时间。默认是见是1s。最小的单位是0.01s，最大精度为小数点后两位，因此0.015将调整至0.02。
--log 开启daemonized模式的所有日志将会被打印到制定的文件中。
--monitor 持续监控从的延迟情况。通过--interval指定的间隔时间，打印出从的延迟信息，通过--file则可以把这些信息打印到指定的文件。
--master-server-id 指定主的server_id，若没有指定则该工具会连到主上查找其server_id。
--print-master-server-id 在--monitor和--check 模式下，指定该参数则打印出主的server_id。
--recurse 多级复制的检查深度。模式M-S-S...不是最后的一个从都需要开启log_slave_updates，这样才能检查到。
--recursion-method 指定复制检查的方式,默认为processlist,hosts。
--update 更新主上的心跳表。
--replace 使用--replace代替--update模式更新心跳表里的时间字段，这样的好处是不用管表里是否有行。
--stop 停止运行该工具（--daemonize），在/tmp/目录下创建一个“pt-heartbeat-sentinel” 文件。后面想重新开启则需要把该临时文件删除，才能开启（--daemonize）。
--table 指定心跳表名，默认heartbeat。
实例说明：
master：192.168.220.108
slave：192.168.220.128
同步的库：test、xuexi
主从库都能使用ceshi1账号、密码123456登录
先操作针对test库的检查，其他同步的库的检查操作类似！
mysql> use test;
Database changed
mysql> CREATE TABLE heartbeat ( //主库上的对应库下创建heartbeat表，一般创建后从库会同步这张表（不同步的话，就在从库那边手动也手动创建）
-> ts varchar(26) NOT NULL,
-> server_id int unsigned NOT NULL PRIMARY KEY,
-> file varchar(255) DEFAULT NULL,
-> position bigint unsigned DEFAULT NULL,
-> relay_master_log_file varchar(255) DEFAULT NULL,
-> exec_master_log_pos bigint unsigned DEFAULT NULL
-> );
Query OK, 0 rows affected (0.02 sec)
更新主库上的heartbeat,--interval=1表示1秒钟更新一次（注意这个启动操作要在主库服务器上执行）
[root@master ~]# pt-heartbeat --user=ceshi1 --ask-pass --host=192.168.220.108 --create-table -D test --interval=1 --update --replace --daemonize #无论主库或从库运行监测同步延迟命令前必须先运行这条命令(更新主库上的heartbeat)，否则检测时间不准确！！
Enter password:
[root@master ~]#
[root@master ~]# ps -ef|grep pt-heartbeat
root 2984 1 0 17:57 ? 00:00:00 perl /usr/bin/pt-heartbeat --user=ceshi1 --ask-pass --host=192.168.220.108 --create-table -D test --interval=1 --update --replace --daemonize
root 2987 2140 0 17:57 pts/0 00:00:00 grep --color=auto pt-heartbeat
在主库运行监测同步延迟：
[root@master ~]# pt-heartbeat -D test --table=heartbeat --monitor --host=192.168.220.128 --user=ceshi1 --password=123456 ##运行监测同步延迟命令
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
........
解释：0表示从没有延迟。 [ 0.00s, 0.00s, 0.00s ] 表示1m,5m,15m的平均值。可以通过--frames去设置。
或者加上--master-server-id参数（主库my.cnf里配置的server-id值）
[root@master ~]# pt-heartbeat -D test --table=heartbeat --monitor --host=192.168.220.128 --user=ceshi1 --password=123456 --master-server-id=1
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
.........
也可以将主库的server-id打印出来（--print-master-server-id）
[root@master ~]# pt-heartbeat -D test --table=heartbeat --monit --host=192.168.220.128 --user=ceshi1 --password=123456 --print-master-server-id
0.00s [ 0.00s, 0.00s, 0.00s ] 1
0.00s [ 0.00s, 0.00s, 0.00s ] 1
0.00s [ 0.00s, 0.00s, 0.00s ] 1
0.00s [ 0.00s, 0.00s, 0.00s ] 1
.........
[root@master ~]# pt-heartbeat -D test --table=heartbeat --check --host=192.168.220.128 --user=ceshi1 --password=123456 --print-master-server-id
0.00 1
上面的监测命令会一直在运行状态中，可以使用--check监测一次就退出
注意：使用了--check，就不能使用--monit
--update，--monitor和--check是互斥的，--daemonize和--check也是互斥。
[root@master ~]# pt-heartbeat -D test --table=heartbeat --check --host=192.168.220.128 --user=ceshi1 --password=123456
0.00
[root@master ~]#
注意：
如果想把这个输出结果加入自动化监控，那么可以使用如下命令使监控输出写到文件，然后使用脚本定期过滤文件中的最大值作为预警即可：
注意--log选项必须在有--daemonize参数的时候才会打印到文件中，且这个文件的路径最好在/tmp下，否则可能因为权限问题无法创建
[root@master ~]# pt-heartbeat -D test --table=heartbeat --monitor --host=192.168.220.128 --user=ceshi1 --password=123456 --log=/opt/master-slave.txt --daemonize
[root@master ~]# tail -f /opt/master-slave.txt //可以测试，在主库上更新数据时，从库上是否及时同步，如不同步，可以在这里看到监控的延迟数据
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
.......
下面是编写的主从同步延迟监控脚本，就是定期过滤--log文件中最大值（此脚本运行的前提是：启动更新主库heartbeat命令以及带上--log的同步延迟检测命令）。如果发生延迟，发送报警邮件。postfix邮件发送环境部署参考：https://blog.csdn.net/weixin_47680367/article/details/129277197
[root@master ~]# cat /root/check-slave-monit.sh
#!/bin/bash
cat /opt/master-slave.txt > /opt/master_slave.txt
echo > /opt/master-slave.txt
max_time=`cat /opt/master_slave.txt |grep -v '^$' |awk '{print $1}' |sort -k1nr |head -1`
NUM=$(echo "$max_time"|cut -d"s" -f1)
if [ $NUM == "0.00" ];then
echo "Mysql主从数据一致"
else
echo "Mysql主从数据同步有延迟"|mailx -s "Mysql主从数据同步有延迟" 379775623@qq.com
fi
[root@master ~]# chmod +x /root/check-slave-monit.sh
[root@master ~]# sh /root/check-slave-monit.sh
Mysql主从数据一致
结合crontab，每隔一分钟检查一次
[root@master ~]# crontab -e
#mysql主从同步延迟检查
* * * * * /bin/bash -x /root/check-slave-monit.sh > /dev/null 2>&1
在从库上运行监测同步延迟(非'root'@'localhost'用户要在命令后加上--master-server-id=1或--print-master-server-id，同上操作)
从库mysql执行(添加用户'ceshi'@'localhost')：
mysql> set global validate_password_policy=0;
Query OK, 0 rows affected (0.00 sec)
mysql> set global validate_password_length=1;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO 'ceshi1'@'localhost' IDENTIFIED BY '123456';
Query OK, 0 rows affected, 1 warning (0.03 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
[root@slave ~]# pt-heartbeat -D test --table=heartbeat --monitor --user=ceshi1 --password=123456 --master-server-id=1
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
........
[root@slave ~]# pt-heartbeat -D test --table=heartbeat --user=ceshi1 --password=123456 --check --master-server-id=1
0.00
[root@slave ~]# pt-heartbeat -D test --table=heartbeat --monitor --user=ceshi1 --password=123456 --log=/opt/master-slave.txt --daemonize --master-server-id=1
[root@slave ~]# tail -f /opt/master-slave.txt
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
如何关闭上面在主库上执行的heartbeat更新进程呢？
方法一：可以用参数--stop去关闭
[root@master ~]# ps -ef|grep heartbeat
[root@master ~]# ps aux|grep pt-heartbeat
root 2984 0.0 0.8 226104 16028 ? Ss 17:57 0:01 perl /usr/bin/pt-heartbeat --user=ceshi1 --ask-pass --host=192.168.220.108 --create-table -D test --interval=1 --update --replace --daemonize
root 3113 0.0 0.8 224024 16208 ? Ss 18:05 0:00 perl /usr/bin/pt-heartbeat -D test --table=heartbeat --monitor --host=192.168.220.128 --user=ceshi1 --password=123456 --log=/opt/master-slave.txt --daemonize
root 3331 0.0 0.0 112812 984 pts/0 S+ 18:24 0:00 grep --color=auto pt-heartbeat
[root@master ~]# pt-heartbeat --stop
Successfully created file /tmp/pt-heartbeat-sentinel
[root@master ~]# ps -ef|grep heartbeat
root 15558 31932 0 20:14 pts/2 00:00:00 grep heartbeat
[root@master ~]#
这样就把在主上开启的进程杀掉了。
但是后续要继续开启后台进行的话，记住一定要先把/tmp/pt-heartbeat-sentinel 文件删除，否则启动不了
方法二：直接kill掉进程pid（推荐这种方法）
[root@master ~]# ps aux|grep pt-heartbeat
root 2984 0.0 0.8 226104 16028 ? Ss 17:57 0:01 perl /usr/bin/pt-heartbeat --user=ceshi1 --ask-pass --host=192.168.220.108 --create-table -D test --interval=1 --update --replace --daemonize
root 3113 0.0 0.8 224024 16208 ? Ss 18:05 0:00 perl /usr/bin/pt-heartbeat -D test --table=heartbeat --monitor --host=192.168.220.128 --user=ceshi1 --password=123456 --log=/opt/master-slave.txt --daemonize
root 3331 0.0 0.0 112812 984 pts/0 S+ 18:24 0:00 grep --color=auto pt-heartbeat
[root@master ~]# kill -9 2984 3113
[root@master ~]# ps -ef|grep heartbeat
root 15558 31932 0 20:14 pts/2 00:00:00 grep heartbeat
最后总结：
通过pt-heartbeart工具可以很好的弥补默认主从延迟的问题，但需要搞清楚该工具的原理。
默认的Seconds_Behind_Master值是通过将服务器当前的时间戳与二进制日志中的事件时间戳相对比得到的，所以只有在执行事件时才能报告延时。备库复制线程没有运行，也会报延迟null。
还有一种情况：大事务，一个事务更新数据长达一个小时，最后提交。这条更新将比它实际发生时间要晚一个小时才记录到二进制日志中。当备库执行这条语句时，会临时地报告备库延迟为一个小时，执行完后又很快变成0。pt-table-checksum使用dsn方式连接检测从库
实际应用::
环境:
主库ip：192.168.220.108 mysql 5.7.42 centos7.9
从库ip：192.168.220.128 mysql 5.7.42 centos7.9
从库：
[root@slave ~]# mysql -uroot -pxxxxxx <<EOF
> set global validate_password_policy=0;
> set global validate_password_length=1;
> GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO 'ceshi2'@'192.168.220.%' IDENTIFIED BY '123456'; #创建ceshi2用户并授权
> EOF
mysql: [Warning] Using a password on the command line interface can be insecure.
[root@slave ~]# mysql -uroot -pxxxxxx -Bse 'select user,host from mysql.user;'
mysql: [Warning] Using a password on the command line interface can be insecure.
root %
ceshi2 192.168.220.%
ceshi1 192.168.220.108
repl 192.168.220.108
ceshi1 localhost
mysql.session localhost
mysql.sys localhost
root localhost
主库：
mysql> show slave hosts;
+-----------+------+------+-----------+--------------------------------------+
| Server_id | Host | Port | Master_id | Slave_UUID |
+-----------+------+------+-----------+--------------------------------------+
| 2 | | 3306 | 1 | 5a19f478-4c9b-11ee-acce-000c29401801 |
+-----------+------+------+-----------+--------------------------------------+
1 row in set (0.00 sec)
mysql> show full processlist;
+----+--------+-----------------------+--------+-------------+------+---------------------------------------------------------------+-----------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+--------+-----------------------+--------+-------------+------+---------------------------------------------------------------+-----------------------+
...........
| 73 | repl | 192.168.220.128:33990 | NULL | Binlog Dump | 657 | Master has sent all binlog to slave; waiting for more updates | NULL |
| 82 | root | localhost | NULL | Query | 0 | starting | show full processlist |
+----+--------+-----------------------+--------+-------------+------+---------------------------------------------------------------+-----------------------+
27 rows in set (0.00 sec)
[root@master ~]# mysql -uroot -pxxxxxx <<EOF
> create database percona_schema; #主库创建percona_schema数据库
> CREATE TABLE percona_schema.dsns ( id int(11) NOT NULL AUTO_INCREMENT, parent_id int(11) DEFAULT NULL, dsn varchar(255) NOT NULL, PRIMARY KEY (id)); #创建dsns表
> INSERT INTO percona_schema.dsns(dsn) VALUES ("h=192.168.220.128,P=3306,u=ceshi2,p=123456"); #将从库的DSN信息写入DSN表
> EOF
mysql: [Warning] Using a password on the command line interface can be insecure.
[root@master ~]# pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=test.checksums --databases=test --tables=orders h=192.168.220.108,u=ceshi1,p=123456,P=3306 --recursion-method dsn=t=percona_schema.dsns,h=192.168.220.128,P=3306,u=ceshi2,p=123456 ##--recursion-method指定从库dsn
Checking if all tables can be checksummed ...
Starting checksum ...
TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE
09-18T17:44:25 0 1 5 0 1 0 0.013 test.orders
[root@master ~]# pt-table-sync --replicate=test.checksums h=192.168.220.108,u=ceshi1,p=123456,P=3306 h=192.168.220.128,u=ceshi2,p=123456,P=3306 --print
REPLACE INTO `test`.`orders`(`order_num`, `order_date`, `cust_id`) VALUES ('20009', '2005-10-08 00:00:00', '10005') /*percona-toolkit src_db:test src_tbl:orders src_dsn:P=3306,h=192.168.220.108,p=...,u=ceshi1 dst_db:test dst_tbl:orders dst_dsn:P=3306,h=192.168.220.128,p=...,u=ceshi1 lock:1 transaction:1 changing_src:test.checksums replicate:test.checksums bidirectional:0 pid:5021 user:root host:centos7*/;
[root@master ~]# pt-table-sync --replicate=test.checksums h=192.168.220.108,u=ceshi1,p=123456,P=3306 h=192.168.220.128,u=ceshi2,p=123456,P=3306 --execute
[root@master ~]# pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=test.checksums --databases=test --tables=orders h=192.168.220.108,u=ceshi1,p=123456,P=3306 --recursion-method dsn=t=percona_schema.dsns,h=192.168.220.128,P=3306,u=ceshi2,p=123456
Checking if all tables can be checksummed ...
Starting checksum ...
TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE
09-18T17:45:10 0 0 5 0 1 0 0.015 test.orders
[root@master ~]#
pt-table-checksum配置主从校验无法连接从库具体分析:::
测试环境::
OS: CentOS 7
DB Version: MariaDB 10.0.23
PT Version: pt-table-checksum 2.2.18
主从环境::
Master: 192.168.0.17:53309
Slave: 192.168.0.18:3309
问题::
在使用pt-table-checksum配置主从校验的时候，本地和生产环境都可以正常校验，而在测试环境校验的时候，却输出以下警告信息：
Cannot connect to h=192.168.0.18,p=...,u=pt_table_check
Diffs cannot be detected because no slaves were found. Please read the --recursion-method documentation for information.
pt-table-checksum无法连接从库。
由于没有发现从库，数据校验时无法实时检测从库与主库的数据是否一致（DIFFS列始终为0），需要通过--recursion-method选项指定其他的方式来搜索、连接从库（此处--recursion-method使用的是默认值processlist,hosts）。
原因::
执行的详细命令及输出如下：
shell> ./bin/pt-table-checksum --socket=/var/lib/mysql/mysql.sock --user=pt_table_check --password='checksum123' --tables=road_to_dba.test1 --replicate=percona_schema.checksums --no-check-binlog-format --no-check-replication-filters
Cannot connect to h=192.168.0.18,p=...,u=pt_table_check
Diffs cannot be detected because no slaves were found. Please read the --recursion-method documentation for information.
TS ERRORS DIFFS ROWS CHUNKS SKIPPED TIME TABLE
09-21T20:57:37 0 0 972 1 0 0.033 road_to_dba.test1
虽然在校验时pt-table-checksum没有连接到从库，但校验能够在主库正常运行，而且能够通过复制传递到从库。校验完成后，在从库也可以通过checksums表查询到数据校验不一致的表信息。
本着严(qiang)谨(po)的(zheng)态度，决定还是对于上述警告信息彻底解决掉。经过分析，具体原因如下：
默认情况下，pt-table-checksum使用的从库连接参数，是从主库的连接参数继承而来的，包括用户名（--user）、密码（--password）、端口（--port）等。
在本次校验中，没有显式指定从库的用户名（--slave-user），密码（--slave-password），及端口。
所以，在没有显式指定从库的连接参数的情况下，默认是，主库和从库的用户名、密码、端口是相同的；但是在我的测试环境中，主从环境的端口是不同的。所以导致pt-table-checksum虽然搜索到了从库，但是无法连接从库（Cannot connect to h=192.168.0.18,p=...,u=pt_table_check），紧接着报没有发现从库的错误。
由于pt-table-checksum没有参数可以用来指定从库的端口，所以使用dsn方式来指定从库的连接信息（--recursion-method dsn=D=percona,t=dsns,h=host,P=3309,u=username,p=passwd）。
--recursion-method参数:
参数有四：processlist/hosts/dsn=DSN/no，默认是processlist,hosts，但最好还是指定一下，建议指定--recursion-method=processlist，no一般不使用
dsn=DSN方法使用时，需要先去库里创建一个表，比如在percona库中建一个dnsn表
建表语句是::
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 table dsns(dsn) values(h=slave_host,u=repl_user,p=repl_password,P=port );
然后就可以使用DSN方法了：命令为：--recursion-method dsn=D=percona,t=dsns.
dsn是什么::
首先介绍俩名词：
dsn方法：dsn是参数--recursion-method的一个参数值。注意是dsn，不是dns…
DSN：DSN，即DATA SOURCE NAME，数据源名称。DSN包含从库的各个连接参数（user、password、port等），由逗号分隔的多个option=value字符串组成。如：h=host,P=3309,u=username,p=passwd。
dsn方法是指将从库的DSN信息存储在表（DSN表）里，然后将该表和DSN信息赋值给dsn，作为--recursion-method的参数值。
格式如：--recursion-method dsn=D=percona,t=dsns,h=host,P=3309,u=username,p=passwd。
当指定pt-table-checksum的--recursion-method参数值为dsn时，它只会连接和检测这些指定的从库。当从库的MySQL用户名、密码、端口与主库不相同时，也可以通过dsn的方式来指定。
DSN的部分选项如下：
D：DSN表所在的数据库名。
h；从库的host。
p：小写p，从库的密码。当密码包括逗号（,）时，需要使用反斜杠转义。
P：大写P，从库的端口。
S：连接使用的socket文件。
t：存储DSN信息的DSN表名。
u：从库的MySQL用户名。每一个选项和其值的形式为option=value，=的前后不能空格，如果选项值有空格，则必须使用引号引起来。
将DSN作为--recursion-method的参数值时，必须包含D和t选项；或者只包含t选项，同时DSN表指定数据库前缀（如percona.dsns）。
DSN表结构如下：
CREATE TABLE `dsns` ( `id` int(11) NOT NULL AUTO_INCREMENT, `parent_id` int(11) DEFAULT NULL, `dsn` varchar(255) NOT NULL, PRIMARY KEY (`id`));
存储在表中的DSNs以id值排序，但是这里可以忽略id和parent_id列，只需将从库的DSN信息存储在dsn列即可。存储的DSN格式如前面在命令行上指定DSN一样，如：h=host,P=3309,u=username,p=passwd。
DSN的详细介绍可参考Percona官方文档：https://www.percona.com/doc/percona-toolkit/2.2/dsn_data_source_name_specifications.html
解决问题::
上面绕的有点晕。。。其实只需要知道如何使用dsn指定从库连接信息即可。
下面通过指定--recursion-method为dsn的方式，解决测试环境在数据校验时无法连接从库的问题。
在主库新建DSN表
CREATE TABLE `percona_schema.dsns` ( `id` int(11) NOT NULL AUTO_INCREMENT, `parent_id` int(11) DEFAULT NULL, `dsn` varchar(255) NOT NULL, PRIMARY KEY (`id`));
这里为了测试，和主库的MySQL账号区分开，新建了一个账号pt_table_check2专用于连接从库
主库账号是pt_table_check
GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO pt_table_check2@'192.168.0.%' IDENTIFIED BY 'checksum123'; #从库mysql程序内执行
将从库的DSN信息写入DSN表
INSERT INTO percona_schema.dsns(dsn) VALUES ("h=192.168.0.18,P=3309,u=pt_table_check2,p=checksum123");
在主库使用dsn方式，重新运行pt-table-checksum进行校验
shell> ./bin/pt-table-checksum --socket=/var/lib/mysql/mysql.sock --user=pt_table_check --password='checksum123' --tables=road_to_dba.test1 --replicate=percona_schema.checksums --no-check-binlog-format --no-check-replication-filters --recursion-method dsn=t=percona_schema.dsns,h=192.168.0.18,P=3309,u=pt_table_check2,p=checksum123
TS ERRORS DIFFS ROWS CHUNKS SKIPPED TIME TABLE
09-21T21:22:30 0 1 972 1 0 0.273 road_to_dba.test1
从第4步可以看到，pt-table-checksum已经能够检测到从库，并且检测到主从数据不一致（DIFFS = 1）。问题解决。
无法连接/检测从库的影响
虽然在使用pt-table-checksum时，如果无法连接/检测到从库，仍可以完成主从一致性校验。但是，这样可能会产生一些其他的问题，如下：
pt-table-checksum在执行校验时，无法实时检测主从的数据是否一致。即，输出的DIFFS列始终为0。
无法检测到从库是否有使用复制过滤，可能会造成从库复制卡住。
当某个表在主库上作为一个分块进行校验时，无法检测其在从库的数据量，当该表在从库的数据量很大时，会造成从库负载过高。
无法检测到从库的复制延迟状态，造成从库复制延迟过大。
参考文章：https://www.modb.pro/db/56034
参考文章：https://www.cnblogs.com/paul8339/p/10813911.html
1209
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
