pt-table-checksum原理详解

环境

MySQL: MySQL 5.6.27
OS: centos 6.6
tool: pt-table-checksum 2.2.15

它能做什么

业界最流行的MySQL主从数据对比工具，数据一致性检测最好的的工具，没有之一

如何使用

./pt-table-checksum -hxx -P 3306 -u backup -p backup --no-check-binlog-format --databases=xx_db,yy_db,zz_db --no-check-replication-filters

如何找到不一致的地方

* slave上执行:
SELECT db, tbl, SUM(this_cnt) AS total_rows, COUNT(*) AS chunks
FROM percona.checksums
WHERE (
 master_cnt <> this_cnt
 OR master_crc <> this_crc
 OR ISNULL(master_crc) <> ISNULL(this_crc))
GROUP BY db, tbl;

原理

大致的原理网上都能看到，这里会描述几个核心的点
这里假设就一个库，一张表，100条记录
pt-table-checksum进行比对的时候，不是一条条记录比的，而是一个个chunk进行对比
这里我们将100条记录分为10个chunk，一个chunk 10条记录。
每个chunk对比完后，再进行下一个chunk对比，直到全部结束。所以，这里我们就以一个chunk来描述下面的原理即可

1. master> /!50108 SET @@binlog_format := 'STATEMENT'/ 设置binlog-format为statement
2. master> SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 这是隔离级别为RR，利用RR的特性让数据在这一刻静止，就不用加锁了。
3. master> checksums表：REPLACE INTO select设置this_cnt, this_crc(传递到slave，这其实设置slave每个chunk的cnt,crc)，算法来自：COALESCE(LOWER(CONV(BIT_XOR(CAST(CRC32(主键) AS UNSIGNED)), 10, 16)), 0)
4. slave> 当同步追上后，开始执行REPLACE INTO select，然后设置slave每个chunk的cnt,crc
5. master> checksums表：update master_cnt,master_crc ，这是设置master每个chunk的cnt，crc
6. slave> 当同步追上后，开始执行update master_cnt,master_crc ，这是设置master每个chunk的cnt，crc

以上，基本完成。 接下来只需要去checksums表中找 master_cnt <> this_cnt or OR master_crc <> this_crc 的记录就行

常问的问题

• 一般在什么场景下使用pt-table-checksum？会在生产环境的master上用吗？

1. 如果不太在乎master和slave之间的一致性的话，在master上设置ROW模式后，就基本可以保证数据一致了。
2. pt-table-checksum虽然很智能，但还是会对服务器造成一定的影响，所以一般不会用在master上,除非迫不得已
3. 一般检查数据一致性，我们都会在两台slave上进行对比，如果两台slave ok，基本就ok了

• 听说该工具只对statement格式有用，如果是row格式，还能检查一致性吗？为什么？

1. 如果是row模式，pt-table-checksum会报错，但是加上--no-check-binlog-format 即可
2. 此工具会自动设置row-format=statement，所以用户不用担心。即便设置row，也没事

• 它是怎么做到master和slave的记录对比的，master不是一直再更新吗？会有锁吗？

1. 详细原理，请看上面的原理分析。
2. master一直再更新没错，但是不会有锁，利用RR隔离级别的特性就能保证当前事务的数据是不会变的

• RR隔离级别是什么鬼？为什么能够保证当前事务的数据不变呢？

1. 可参看之前的分享: SELECT 你知多少

缺陷

• 如果master和slave直接的表结构不一致，目前是没办法检测出来的

* 场景

master：table xx( A int,B char)
slave:  table xx( A int)

pt-table-checksum 无法检测B字段。。。

重要

• 风险1

这里设置了SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 直到对比完成，才结束这个session.
那这样意味什么呢？意味着如果这个session不结束，这个事务对应的undo一直不会被purge，会导致undo不断变大，即ibdata会一直变大。
措施：尽量在低峰期执行

• 风险2

这里是通过RR隔离级别来保证select CRC的值一致的，那么如果RR被破坏了呢？
没错，这样的对比，很容易被DDL所破坏。
措施：DDL是可以人为控制时间窗口和周期的