MySQL数据库数据归档回收工具使用场景分享-爱可生更方便的数据归档pt-archiver某些存在

文章插图
更方便的数据归档 pt-archiver
某些存在时效性的数据，在达到一定条件后，需要进行归档和回收处理。
pt-archiver 工具可以帮助我们快速的进行数据行的归档和回收。
# 归档到其他数据库,并删除原表中对应的行pt-archiver --source h=172.20.134.1,P=5722,u=repl,p=repl,D=sbtest,t=sbtest1,A=utf8--where "id<=1000" --dest h=172.20.134.3,P=5722,u=dba,p=dba,D=sbtest,t=sbtest1,A=utf8# 归档到其他数据库, 不删除原表中对应的行pt-archiver --source h=172.20.134.1,P=5722,u=repl,p=repl,D=sbtest,t=sbtest1,A=utf8 --no-delete --where "id<=1000" --dest h=172.20.134.3,P=5722,u=dba,p=dba,D=sbtest,t=sbtest1,A=utf8# 归档到文件,并删除原表中对应的行pt-archiver --source h=172.20.134.1,P=5722,u=repl,p=repl,D=sbtest,t=sbtest1,A=utf8 --file=/tmp/archive.save --where "id<=1000"# 归档到文件, 不删除原表中对应的行pt-archiver --source h=172.20.134.1,P=5722,u=repl,p=repl,D=sbtest,t=sbtest1,A=utf8 --no-delete --file=/tmp/archive.save --where "id<=1000"# 导入归档文件mysql> load data infile "/tmp/archive.save" into table sbtest.sbtest1;Query OK, 1000 rows affected (0.49 sec)Records: 1000Deleted: 0Skipped: 0Warnings: 0更快速的配置对比 pt-config-diff
在我们日常工作中，大家一定遇到过以下场景：

若干套 MySQL 环境，只有一套：

° 行为异常，怀疑触发 bug
° 性能异常，比其他环境都要低
在这种场景下，我们一般的做法是首先控制变量，查看软硬件配置，以及 MySQL 的参数配置。
关于 MySQL 的参数配置对比，如果我们人工对比的话只会关注某些重点参数，而缺少了整体细节上的的对比。
在这里我们推荐给大家 Percona Toolkit 中的一个工具 pt-config-diff

# 指定DSN, 对比所有运行时参数# 指定 --report-width 200,防止某些参数过长被截断[root@172-20-134-1 /]#pt-config-diff h=172.20.134.1,P=5722,u=repl,p=replh=172.20.134.3,P=5722,u=dba,p=dba --report-width 2004 config differencesVariable172-20-134-1172-20-134-3========================== ======================================== ========================================general_log_file/data/mysql/data/5.7.22/172-20-134-1.log /data/mysql/data/5.7.22/172-20-134-3.loggtid_executed234303e2-20cb-11ea-a5a3-0242ac148601:12348904f-20cb-11ea-a565-0242ac148603:1hostname172-20-134-1172-20-134-3server_uuid234303e2-20cb-11ea-a5a3-0242ac1486012348904f-20cb-11ea-a565-0242ac148603# 指定配置文件, 对比配置文件的差异[root@172-20-134-1 /]# pt-config-diff /data/mysql/etc/5.7.22.cnf /tmp/5.7.22.cnf --report-width 2002 config differencesVariable/data/mysql/etc/5.7.22.cnf /tmp/5.7.22.cnf========================= ========================== ===============max_allowed_packet1677721667108864relay_log_recovery10

更准确的复制延时 pt-heartbeat
在 MySQL 中，复制延迟可以理解为由两部分组成：
1. 主库已经生成了 BINLOG ，但是还没有发送给从库 -- 我们在这里称之为：日志延迟
2. 从库已经接收到了 BINLOG ，但是还没有应用完成 -- 我们在这里称之为：应用延迟
MySQL 原生的查看复制延迟的手段为：show slave status\G 中的 Seconds_Behind_Master。
这种观测手法只能观测出应用延迟。在异步复制或降级的半同步复制下，误差较大，无法准确的反映出整体复制延时。