怎么迅速判断mysql是否为主从

连接数据库，运行：

showmasterstatus;

showslavestatus;

可以判断是否是这样通过查看上图中的信息。

mysql怎么检查主从数据一致性

使用pt-table-checksum会影响业务性能吗？

实验

在实验开始之前，我想跟大家分享一点经验：每当评估性能时，不要相信别人的评估结果，在自己的环境中测试一下并且（大约）知道原理。

我们首先创建主从对：

然后我们使用mysqlslap进行连续打印：

再打开一个会话，打开master上的通用日志：

然后通过pt-table-checksum进行比较：

显示master一般日志，由于影响MySQLslap，总日志中有很多与pt-table-checksum相关的内容：

单独列出该线程的操作：

操作有很多，我们一一解释：

这里的工具减少了Innodb锁的等待时间。
这样一来，只要innodb有轻微的锁等待期，后续操作就会立即停止，对业务影响不大。

该工具还缩短了wait_timeout时间，但没有特别的效果。

该工具将隔离级别调整为RR级别。
交易维护成本比RC高。
不过，后面我们会看到，该工具所使用的每一个事务，如上所述，Innodb锁等待时间都被设置为一个很小的值，在线业务的成本是比较低的。

RR级别是数据比对的基本要求。

该工具通过一系列操作提供表格的概览。
该工具用于逐个数据块检查数据。
这里确定第一数据块的下限。

然后工具获取下一个数据块的下限。
它会在每个SQL语句之前执行EXPLAIN来确定执行成本，并且要非常小心。

然后该工具接收数据块的校验和。
如果与业务事务冲突，会立即触发Innodb锁超时，并立即撤销。

以上是pt-table-checksum的一些设计。
可以看到这些都是经过精心维护的，以确保业务交易不受影响。

该工具还开发了一些其他机制来确保业务交易，例如：比如--max-load和--pause-file参数等，还有精心设计的数据块分割方式和索引选择方式等，大家根据自己的情况一起应用，一定能收到不错的效果。

总结

本期我们简单分析了pt-table-checksum是否影响业务交易。
市面上流传的各种工具参数建议，不建议使用。
算命的例子有很多。
任何人都可以通过简单的实验来分析其机制。

但是，性能测试不能道听途说，必须通过实验来分析。