pt-table-checksum原理详解

简介: 环境 MySQL: MySQL 5.6.27 OS: centos 6.6 tool: pt-table-checksum 2.2.15 它能做什么 业界最流行的MySQL主从数据对比工具,数据一致性检测最好的的工具,没有之一 如何使用 ./pt-table-che

环境

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是可以人为控制时间窗口和周期的

目录
相关文章
|
存储 关系型数据库 MySQL
|
关系型数据库 MySQL 数据库
MySQL新增字段报错:ERROR 1118 -- Row size too large. The maximum row size for the used table type
MySQL新增字段报错:ERROR 1118 -- Row size too large. The maximum row size for the used table type
1687 0
|
6月前
|
关系型数据库 MySQL
mysql 5.5.62版本建表语句报错: Index column size too large. The maximum column size is 767 bytes
mysql 5.5.62版本建表语句报错: Index column size too large. The maximum column size is 767 bytes
227 0
|
关系型数据库
PG/GP limit...offset...实现机制
PG/GP limit...offset...实现机制
113 0
|
存储 关系型数据库 MySQL
MySQL出现Data too long for column...(错误号1406)和 Data truncated for column...(错误号1265)
MySQL出现Data too long for column...(错误号1406)和 Data truncated for column...(错误号1265)
1005 0
MySQL出现Data too long for column...(错误号1406)和 Data truncated for column...(错误号1265)
|
关系型数据库 MySQL Oracle
|
SQL 索引
pt-query-digest
pt-query-digest 可以用来分析binlog、General log、slowlog,也可以通过show processlist或者通过tcpdump抓取的MySQL协议数据来进行分析 用法: (1)直接分析slow日志:  pt-query-digest INDEX01184W-slow.
1287 0
|
关系型数据库 数据库 索引
pt-table-checksum
pt-table-checksum是目前可以说是最好的查看主从一致性的工具 先来个使用例子,有助快速上手使用 在主库执行:mysql>GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE,CREATE,DELETE,INSERT,UPDATE ON .
1706 0