Percona-tookit学习笔记（六）

• 2019 年 10 月 5 日
• 笔记

pt-variable-advisor

功能：

    分析mysql的参数变量，并对可能存在的问题提出建议

例1：

    pt-variable-advisor --user=root--password=root localhost

例2：

    pt-variable-advisor --user=root--password=root  --source-of-variablesmy.cnf

# pt-variable-advisor --user=root--password=root localhost > pt-variables-adv.log

结果如下：

说明: 下面的只是提示，各位根据自己的业务需求来改即可。

# NOTE connect_timeout: A largevalue of this setting can create a denial of service vulnerability.

# WARN delay_key_write: MyISAMindex blocks are never flushed until necessary.   【设置delay_key_write = OFF 】

# NOTE log_warnings-2:Log_warnings must be set greater than 1 to log unusual events such as abortedconnections.

【可设置log_warnings = 2 】

# NOTE max_binlog_size: Themax_binlog_size is smaller than the default of 1GB.  【设置max_binlog_size = 1G】

# NOTE read_buffer_size-1: Theread_buffer_size variable should generally be left at its default unless anexpert determines it is necessary to change it.

# NOTE read_rnd_buffer_size-1: Theread_rnd_buffer_size variable should generally be left at its default unless anexpert determines it is necessary to change it.

# WARN slave_net_timeout: Thisvariable is set too high.    【根据这条提示，可以设置slave_net_timeout = 60】

# NOTE sort_buffer_size-1: Thesort_buffer_size variable should generally be left at its default unless anexpert determines it is necessary to change it. 【可以修改下innodb_data_file_path =ibdata1:1G：autoextend：max:2G】

# NOTE innodb_data_file_path:Auto-extending InnoDB files can consume a lot of disk space that is verydifficult to reclaim later.

# WARN key_buffer_size: The keybuffer size is set to its default value, which is not good  for most production systems. 【根据这条提示，可以设置key_buffer_size = 100M】

# WARN expire_logs_days: Binarylogs are enabled, but automatic purging is not enabled.【可设置expire_logs_days = 20解决】

# NOTE innodb_flush_method: Mostproduction database servers that use InnoDB should set innodb_flush_method toO_DIRECT to avoid double-buffering, unless the I/O system is very lowperformance. 【根据这条提示，可以设置innodb_flush_method =O_DIRECT】

# NOTE max_relay_log_size: Acustom max_relay_log_size is defined.

# WARN myisam_recover_options:myisam_recover_options should be set to some value such as BACKUP,FORCE toensure that table corruption is noticed.

# WARN sync_binlog: Binary loggingis enabled, but sync_binlog isn't configured so that every transaction isflushed to the binary log for durability. 【根据这条提示，为了更高的数据安全性，可以设置sync_binlog = 1】

pt-deadlock-logger

作用：

    收集和保存mysql上最近的死锁信息，可以直接打印死锁信息和存储死锁信息到数据库中，死锁信息包括发生死锁的服务器、最近发生死锁的时间、死锁线程id、死锁的事务id、发生死锁时事务执行了多长时间等等非常多的信息。

范例1：打印本地mysql的死锁信息

# pt-deadlock-logger  --user=root --password=root h=localhost–print

范例2：将本地的mysql死锁信息记录到数据库的表中，也打印出来

# pt-deadlock-logger  --user=root --password=root h=localhost--print D=test,t=deadlocks

pt-fk-error-logger

作用：

    记录外键错误信息。

    通过SHOW INNODB STATUS提取和保存mysql数据库最近发生的外键错误信息。可以通过参数控制直接打印错误信息或者将错误信息存储到数据库的表中。

pt-mext

作用：

    Lookat many samples of MySQL "SHOW GLOBAL STATUS" side-by-side

    –relative  缩写为 -r  Subtract each column from the previous column

 范例：

    获取系统消息(结果和show global status一样)

    #pt-mext -r -- mysqladmin ext -i10 -c3 --user=root --password=root

pt-heartbeat

说明：

    监控mysql复制延迟。测量复制落后主mysql或者主PostgreSQL多少时间，你可以使用这个脚本去更新主或者监控复制。

    pt-heartbeat measures replication lag on aMySQL or PostgreSQL server.  You can useit to update a master or monitor a replica. If possible, MySQL connectionoptions are read from your .my.cnf file.

在主节点执行pt-heartbeat这个命令。

原理：

    pt-heartbeat通过真实的复制数据来确认mysql和postgresql复制延迟，这个避免了对复制机制的依赖，从而能得出准确的落后复制时间。

    包含两部分：

       第一部分在主上pt-heartbeat的–update线程会在指定的时间间隔更新一个时间戳；

       第二部分是pt-heartbeat的–monitor线程或者–check线程连接到从上检查复制的心跳记录（前面更新的时间戳），并和当前系统时间进行比较，得出时间的差异。

格式：

    pt-heartbeat-D test –update -h master-server –daemonize

    pt-heartbeat-D test –monitor -h slave-server

    pt-heartbeat-D test –check h=slave-server

实例：

1、在主节点192.168.2.11执行启动更新test.heartbeat表操作：

    #pt-heartbeat -D test --update --user=root --password=root -h 192.168.2.11--create-table –daemonize

2、在主节点192.168.2.11执行启动监控复制在slave上的落后程度（会一直监控）：

    #pt-heartbeat -D test --monitor --user=root --password=root  -h 192.168.2.12   结果如下图所示：

3、检查Slave节点落于Master多长时间

    #pt-heartbeat -D test --check --user=root --password=root h=192.168.2.12        结果如下图所示,0表示没有延迟：

4、监控完毕，记得关闭第一步的pt-heartbeat后台进程

    #kill -9 `ps aux|grep pt-heartbeat|grep -v grep|awk '{print $2}'`

pt-slave-delay

作用：

    设置从服务器落后于主服务器指定时间。

    Makea MySQL slave server lag behind its master

    pt-slave-delaystarts and stops a slave server as needed to make it lag behind the master.TheSLAVE_DSN and MASTER_DSN use DSN syntax, and values are copied from theSLAVE_DSN to the MASTER_DSN if omitted.

原理：

    通过启动和停止复制sql线程来设置从落后于主指定时间。默认是基于从上relay日志的二进制日志的位置来判断，因此不需要连接到主服务器，如果IO进程不落后主服务器太多的话，这个检查方式工作很好，如果网络通畅的话，一般IO线程落后主通常都是毫秒级别。一般是通过–delay and–delay"+"–interval来控制。–interval是指定检查是否启动或者停止从上sql线程的频繁度，默认的是1分钟检查一次。

例：

    使主从之间延迟1分钟，每隔15秒检测一次，运行10分钟

    #pt-slave-delay --user=root --password=root --delay 1m --interval 15s --run-time10m --host=192.168.2.12

    如果不加–run-time 参数，这个命令会一直在前台运行下去

    –daemonize表示以后台守护进程执行

    –quiet表示静默执行

    –port=3306  指明端口

    说明：用了这个工具的话，slave节点执行show slave statusG可以看到从节点的Slave_SQL_Running状态是在Yes和No之间不断切换的。

pt-slave-find

作用：找到主节点下的所有从节点

原理：连接mysql主服务器并查找其所有的从，然后打印出所有从服务器的层级关系

语法：pt-slave-find –user=xx –password=xxx –host=master_ip

示例：

# pt-slave-find --user=root --password=root --host=192.168.2.11

pt-slave-restart

作用：

    监视mysql复制错误，当复制停止的时候尝试重启mysql复制。Watch and restart MySQLreplication after errors

示例：

    监视IP为192.168.2.12的从节点，跳过1个错误

    #pt-slave-restart –user=root –password=root –host=192.168.2.12 –skip-count=1

    监视192.168.2.12的从节点，跳过错误代码为1062的错误。

    #pt-slave-restart –user=root –password= root –host=192.168.2.12 –error-numbers=1062

    –verbose  显示详细信息

pt-table-checksum

作用：

    检查复制的完整性    VerifyMySQL replication integrity

原理：

    pt-table-checksum在主上执行检查语句在线检查mysql复制的一致性，生成replace语句，然后通过复制传递到从，再通过update更新master_src的值。通过检测从上this_src和master_src的值从而判断复制是否一致。

注意：

    使用的时候选择业务低谷的时候运行，因为运行的时候会造成表的部分记录锁定。此外，还要确保从库的IO/SQL线程都是YES状态的。

    使用–max-load来指定最大的负载情况，如果达到那个负载这个暂停运行。如果发现有不一致的数据，可以使用pt-table-sync工具来修复。

示例：比较hellodb数据库下所有的表同步是否一致，结果显示hellodb库所有的表的校验和

首先，我们在Slave节点修改下hellodb.students一条数据，模拟出主从之间数据不一致的情况。

step1、在主节点执行：

# pt-table-checksum--nocheck-replication-filters   --databases=hellodb--replicate=hellodb.checksums   --host=192.168.2.11 --user=root--password=root --port 3306   --no-check-binlog-format

参数说明：

–host=主节点的IP地址

–no-check-binlog-format        :因为我们的日志用的MIXED格式，所有这里要加上不检查复制的binlog模式

–replicate-check-only          :只显示不同步的信息【对于需要比较大量数据库时候排除干扰的条目,很有用】

–replicate=db_name.tb_name     ：把checksum的信息写入到指定表中，建议直接写到被检查的数据库当中。

–databases=db1,db2             ：指定需要被检查的数据库，多个则用逗号隔开。

–tables=                       ：指定需要被检查的表，多个用逗号隔开[不写就是检查给出的库里涉及到的所有表]

h=127.0.0.1   ：Master的地址

u=root        ：用户名

p=123456      ：密码

P=3306        ：端口

执行结果如下图所示，我们可以看到有一个DIFFS：

TS            ：完成检查的时间。

ERRORS        ：检查时候发生错误和警告的数量。

DIFFS         ：0表示一致，1表示不一致。当指定–no-replicate-check时，会一直为0，当指定–replicate-check-only会只显示不同的信息。

ROWS          ：表的行数。

CHUNKS        ：被划分到表中的块的数目。

SKIPPED       ：由于错误或警告或过大，则跳过块的数目。

TIME          ：执行的时间。

TABLE         ：被检查的表名。

说明：如果加上–replicate-check-only 参数的话，只会显示有不同的表的地方。如下图：

另外，操作完成后，会在hellodb库下生成一个checksums表。

step2、到Slave节点上查询下结果如下

[因为在Master节点查看的话this_crc和master_crc是一样的，没比较的意义]：

MySQL [test] >select * fromhellodb.checksumsG  可以看到主从的students的行数不一样

MySQL [test] >select * fromhellodb.checksums;

pt-table-sync

功能：

    高效地同步MySQL Table表数据。他可以做单向和双向同步的表数据。他可以同步单个表，也可以同步整个库。它不同步表结构、索引、或任何其他模式对象。所以在修复一致性之前需要保证他们表存在。

说明：

    为了安全起见，建议修改前先备份数据。

原理：

    总是在主上执行数据的更改，再同步到从上，不会直接更改成从的数据，在主上执行更改是基于主上现在的数据，不会更改主上的数据。注意使用之前先备份你的数据，避免造成数据的丢失.执行execute之前最好先换成–print或–dry-run查看一下会变更哪些数据。

范例1：同步从的test库的aaa表到主的，在执行之前可以用–execute参数换成–print来查看会变更什么东西，后面那个主机必须是master

pt-table-sync--user=root --password=root h=192.168.2.12,D=hellodb,t=students h=192.168.2.11 --print

pt-table-sync --user=root--password=root h=192.168.2.12,D=hellodb,t=students h=192.168.2.11 --execute

范例2：将主的test数据库同步到从节点192.168.2.12，使从上具有一样的数据   [在主节点执行该命令]

pt-table-sync –sync-to-master–user=root –password=root  h=192.168.2.12 –database test –execute

范例3：只同步指定的表[在主节点执行该命令]

pt-table-sync –sync-to-master–user=root –password=root  h=192.168.2.12,D=test,t=aaa –execute

范例4：根据pt-table-checksum的结果进行数据同步，使得从节点数据能和主节点数据一致  [在主节点执行该命令]

pt-table-sync –replicatetest.checksums –user=root –password=root  h=192.168.2.11 –execute

范例5：根据pt-table-checksum使从的数据和主的数据一致

pt-table-sync –replicatetest.checksums –user=root –password=root 

–sync-to-master h=192.168.2.12,D=test,t=aaa–execute

同步host1上的db.tbl到host2:

# pt-table-sync –executeh=host1,D=db,t=tbl h=host2

同步host1上的所有表到host2和host3:

# pt-table-sync –execute host1host2 host3

Same as above butonly resolve differences on slave1:

# pt-table-sync –sync-to-master –replicatetest.checksum slave1 –execute

Sync master2 in amaster-master replication configuration, where master2’s copy of db.tbl isknown or suspected to be incorrect:

# pt-table-sync –execute–sync-to-master h=master2,D=db,t=tbl

下面补充一个很不错的主从数据不一致的数据修复案例：

step0、修改从节点数据让主从不一致

> delete from hellodb.studentswhere StuID=24;   # 在从节点执行删除行操作

step1、发现主从数据不一致 [该命令在主节点执行]

# pt-table-checksum--nocheck-replication-filters --databases=hellodb   --replicate=test.checksums   --host=192.168.2.11 --user=root--password=root --port 3306   --no-check-binlog-format

step2、输出不一致的数据条目  [该命令在主节点执行]

# pt-table-sync --replicate=test.checksums h=192.168.2.11,u=root,p=root h=192.168.2.12,u=root,p=root --print

step3、修复操作，确保主从数据一致 [该命令在主节点执行]

# pt-table-sync--replicate=test.checksums  h=192.168.2.11,u=root,p=rooth=192.168.2.12,u=root,p=root --execute

step4、再次检查主从数据是否一致

# pt-table-checksum--nocheck-replication-filters --databases=hellodb   --replicate=test.checksums   --host=192.168.2.11 --user=root--password=root --port 3306   --no-check-binlog-format

这样就数据同步了，如果不放心的话可以到从节点去看下hellodb.students的数据是否和主节点的一致了。