下文主要给大家带来如何使用percona-toolkit工具检查及修复MySQL数据库的主从不一致，希望这些内容能够带给大家实际用处，这也是我如何使用percona-toolkit工具检查及修复MySQL数据库的主从不一致编辑这篇文章的主要目的。好了，废话不多说，大家直接看下文吧。
pt-table-checksum是Percona-Toolkit的组件之一，用于检测MySQL主、从库的数据是否一致。其原理是在主库执行基于statement的sql语句来生成主库数据块的checksum，把相同的sql语句传递到从库执行，并在从库上计算相同数据块的checksum，最后，比较主从库上相同数据块的checksum值，由此判断主从数据是否一致。检测过程根据唯一索引将表按row切分为块（chunk），以为单位计算，可以避免锁表。检测时会自动判断复制延迟、 master的负载， 超过阀值后会自动将检测暂停，减小对线上服务的影响。pt-table-checksum默认情况下可以应对绝大部分场景，官方说，即使上千个库、上万亿的行，它依然可以很好的工作，这源自于设计很简单，一次检查一个表，不需要太多的内存和多余的操作；必要时，pt-table-checksum 会根据云服务器负载动态改变chunk大小，减少从库的延迟。为了减少对数据库的干预，pt-table-checksum还会自动侦测并连接到从库，当然如果失败，可以指定–recursion-method选项来告诉从库在哪里。它的易用性还体现在，复制若有延迟，在从库checksum会暂停直到赶上主库的计算时间点（也通过选项–设定一个可容忍的延迟最大值，超过这个值也认为不一致）。打开官网：https://www.percona.com/downloads/percona-toolkit/LATEST/
选择软件版本：Version，一般默认最新版即可；
选择系统版本：Software，也可以源码编译；我的CentOS6
系统架构：Hardware；我的64位；我的下载为：
https://www.percona.com/downloads/percona-toolkit/3.0.13/binary/redhat/6/x86_64/percona-toolkit-debuginfo-3.0.13-1.el6.x86_64.rpm
https://www.percona.com/downloads/percona-toolkit/3.0.13/binary/redhat/6/x86_64/percona-toolkit-3.0.13-1.el6.x86_64.rpmCentOS6.*依赖：查看安装的文件：–recursion-method：发现从库的方式。pt-table-checksum 默认可以在主库的 processlist 中找到从库复制进程，从而识别出有哪些从库，但如果使用是非标准3306端口，会导致找不到从库信息。此时就会自动采用host方式，但需要提前在从库 my.cnf 里面配置report_host、report_port信息，如：最终极的办法是dsn，dsn指定的是某个表（如 percona.dsns ），表行记录是改主库的（多个）从库的连接信息。适用以下任一情形：我比较倾向使用DSN的方式。这个dsns表只需要在执行 pt-table-checksum 命令的云服务器上能够访问到就行。这里纠正一个认识，网上很多人说 pt-table-checksum 要在主库上执行，其实不是的，我的mysql实例比较多，只需在某一台云服务器上安装percona-toolkit，这台服务能够同时访问主库和从库就行了。具体用法见后面实例。从库node2的bbinlog日志为ROW，这可能导致pt-table-checksum中断复制。可以指定–no-check-binlog-format以禁用此检查。看到已经检查出主从数据有不一致了，DIFFS下的值为1，怎么不一致呢？ 通过指定–replicate=test.checksums 参数，就说明把检查信息都写到了checksums表中master库用pt-table-sync命令和–print选项打印出master下的check_sum.test1和slave库的check_sum.test1的不一致的数据，如下：接下的操作就是把slave上少的数据，从master同步过去(master操作)；通过(–execute)，让它们数据保持一致性:可以看到再次检查的时候，DIFFS已经是0了；已经跟master上的数据一致了。没有创建CREATE表的权限；不能自动找到从库，确认processlist或host或dsns方式用对了。可以在pt-table-checksum命令前加PTDEBUG=1来看详细的执行过程，如端口、用户名、权限错误。问题出在 percona.checksums 表在从库不存在，根本原因是没有从主库同步过来，所以看一下从库是否延迟严重。反复打印出类似上面停止检查的信息。这是因为当前数据库正在运行的线程数大于默认25，pt-table-checksum 为了减少对库的压力暂停检查了。等数据库压力过了就好了，或者也可以直接 Ctrl+C 终端，下一次加上–resume继续执行，或者加大–max-load=值。对于以上关于如何使用percona-toolkit工具检查及修复MySQL数据库的主从不一致，大家是不是觉得非常有帮助。如果需要了解更多内容，请继续关注我们的行业资讯，相信你开发云主机域名会喜欢上这些内容的。
日本DeNA公司youshimaton (现就职于Facebook公司) 开发一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件MHA Manager (管理节点)MHA Node (数据节点)自动故障切换过程中，MHA试图从宕机的主服务器上…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
