mysql 数据一致性校验

工作上需要把一个从库提升为主库,但对从库和主库的数据一致性不能保证一样,所以就利用

pt-table-checksum 工作来检查主从的一致性,操作前需要注意的事项:

(1)在有些情况下,recursion-method如果不设会报错:Diffs cannot be detected because no slaves were found. 其参数有四:processlist/hosts/dsn=DSN/no,用来决定查找slave的方式是show full processlist还是show slave  hosts还是命令行直接指定还是压根就不准备找从库,具体见下面参数介绍

(2)主从的端口必须一致,如果不一致就需要用DSN方法进行指定,否则会报找不到从库的错误,如果能连到从库服务器但没有指定端口,默认会寻找3306端口

(3)被检查的主从binlog_format必须为statement,如果不是statement-based,那就添加参数--no-check-binlog-format来避开binlog格式检查

(4)检查结果会输出到默认建立的percona库中的checksums表中,并会输出统计信息到屏幕,diffs列展示主从数据不一致的块的数目,如果都是0,恭喜,数据是一致的

(5)表的数据是唯一性,有主键或者唯一约束

(6)该工具检查的表,需要检查连接的帐号需要有很高的权限,在一般权限行需要加SELECT, PROCESS, SUPER, REPLICATION SLAVE等权限

(7)该工具检查的是数据,若表不存在是会报错的

(8)指定多个库或者表,中间用逗号隔开即可

(9)还原的时候会锁表,主要是通过record lock 和gap lock结合(主要是delete和replace操作,具体还要看事务隔离级别,这里说的是RR隔离级别)

实验环境、测试过程简单描述:

1、搭建好主从库,然后在主库添加一个pt使用的用户,测试给all 权限

GRANT all privileges ON *.* TO ‘dlan‘@‘%‘ IDENTIFIED BY ‘root123‘;

2、在主库上执行命令,对指定的库进行检查:

/usr/bin/pt-table-checksum h="192.168.15.57",u=‘dlan‘,p=‘root123‘,P=5700 -d dbconfig --nocheck-replication-filters --replicate=test.checksums --no-check-binlog-format --recursion-method=processlist;

TS ERRORS     DIFFS     ROWS  CHUNKS SKIPPED    TIME TABLE

01-16T16:47:00      0      0        2       1       0   0.461 dbconfig.checksums

01-16T16:47:00      0      0        2       1       0   0.346 dbconfig.mysql_backup_list

01-16T16:47:01      0      0       13       1       0   0.343 dbconfig.mysql_backup_log

在数据一致的情况下,都为0

3、在从库上操作,删除数据

truncate table mysql_backup_log;

4、在主库上执行:

/usr/bin/pt-table-checksum h="192.168.15.57",u=‘dlan‘,p=‘root123‘,P=5700 -d dbconfig --nocheck-replication-filters --replicate=test.checksums --no-check-binlog-format --recursion-method=processlist;

TS             ERRORS    DIFFS     ROWS  CHUNKS SKIPPED    TIME TABLE

01-16T17:01:08      0      0        2       1       0   0.351 dbconfig.checksums

01-16T17:01:08      0      0        2       1       0   0.342 dbconfig.mysql_backup_list

01-16T17:01:09      0      1       13       1       0   0.344 dbconfig.mysql_backup_log

删除了表里的数据,DIFFS值为1

4、在主从上执行SQL,会看到不一样的结果。

SELECT db,tbl, SUM(this_cnt) AS total_rows, COUNT(*) AS chunks FROM test.checksums WHERE ( master_cnt <> this_cnt OR master_crc <> this_crc OR ISNULL(master_crc) <> ISNULL(this_crc)) GROUP BY db, tbl;

5、因为从库删除了数据,所以通过pt-table-sync来恢复,命令:

1、打印不一致的数据:

/usr/local/bin/pt-table-sync --print --replicate test.checksums --sync-to-master h=‘从库的IP地址‘,u=‘dlan‘,p=‘root123‘,P=5700

2、执行恢复主从一致的数据:

/usr/local/bin/pt-table-sync --execute --replicate test.checksums --sync-to-master h=‘从库的IP地址‘,u=‘dlan‘,p=‘root123‘,P=5700

#--sync-to-master :指定一个DSN,即从的IP,他会通过show processlist或show slave status 去自动的找主。

#--replicate :指定通过pt-table-checksum得到的表,这2个工具差不多都会一直用。

#--print :打印,但不执行命令。

#--execute  :执行命令。

时间: 2024-08-25 01:27:45

mysql 数据一致性校验的相关文章

mysql主从数据一致性校验及纠错工具

目录 1.概述 2.percona-tooldit工具的安装 3.新建用户 4.pt-table-checksum使用 5.pt-table-sync使用 6.个人总结 1.概述 假如你是一位运维人员,假如你生产环境上部署了mysql系统,再假如你线上的mysql是基于主从复制的架构,那恭喜你,它将可能会带给你主从数据不一致的"恶运". 由于mysql复制架构原生特性,主从服务器上的数据不可能做"同步"复制,所以延时是必然会有的,即使是不那么繁忙的服务器上,在业务不

分布式数据库集群节点数据一致性校验

某500强客户要上线一个功能,其后台所有数据库是我司设计开发的NoSQL数据库. 为了避免数据库集群中,数据节点不一致而导致问题,需要对数据库节点间的数据进行校验. 理论上说,数据库节点之间的数据,应当保持最终一致性.而我司的数据库,是在对主节点对数据进行操作时,coord节点会(立即)通知备节点拉取数据,从而保持数据的一致性.所以,对于正常运行的数据库来说,一个集群内每个节点上的数据,是完全一致的. 客户是上帝,我们所作的就是要让客户放心.虽然我们强调我们的数据库集群内的节点中数据是一致的,让

mysql数据校验之字符集问题

场景:主库DB:utf8字符集备库DB:gbk字符集 需求:校验主备数据是否一致,并且修复 校验过程:设置主库连接为utf8,设置备库连接为gbk,分别进行查询,将返回的的结果集按记录逐字段比较. 显示结果:原本相同的汉字字符,数据校验认为不一致. 原因分析:对于主库而已,由于建立连接的字符集为UTF8,则返回的汉字字符编码为UTF8格式:对于备库而言则是GBK格式,而程序中通过字符串比较函数strcasecmp进行比较,显然不同的字符集编码,相同的字符有不同的二进制,因此结果肯定不会相等. 进

高并发架构系列:Redis缓存和MySQL数据一致性方案详解

一.需求起因在高并发的业务场景下,数据库大多数情况都是用户并发访问最薄弱的环节.所以,就需要使用redis做一个缓冲操作,让请求先访问到redis,而不是直接访问MySQL等数据库.这个业务场景,主要是解决读数据从Redis缓存,一般都是按照下图的流程来进行业务操作.读取缓存步骤一般没有什么问题,但是一旦涉及到数据更新:数据库和缓存更新,就容易出现缓存(Redis)和数据库(MySQL)间的数据一致性问题. 不管是先写MySQL数据库,再删除Redis缓存:还是先删除缓存,再写库,都有可能出现数

基于pt-table-checksum和pt-table-sync实现MySQL主从数据一致性校验

在基于MySQL逻辑复制原理的下的主从架构,经常会由于某些缘故产生主从数据不一致,从而导致主从复制进程报错中断.而基于定期去检查从库的show slave status\G的IO线程和SQL线程的状态,只能确认当前replication是正常的,却无法确认当前主从数据是否一致.幸好percona公司提供pt工具包,其中的pt-table-checksum和pt-table-sync相互配合,在基于一定的前提条件下,可以较好的完成主从数据一致性校验和修复,而不会较大程度上影响线上数据库的性能. p

生产环境使用 pt-table-checksum 检查MySQL数据一致性

公司数据中心从托管机房迁移到阿里云,需要对mysql迁移(Replication)后的数据一致性进行校验,但又不能对生产环境使用造成影响,pt-table-checksum 成为了绝佳也是唯一的检查工具. pt-table-checksum 是 Percona-Toolkit 的组件之一,用于检测MySQL主.从库的数据是否一致.其原理是在主库执行基于statement的sql语句来生成主库数据块的checksum,把相同的sql语句传递到从库执行,并在从库上计算相同数据块的checksum,最

复制数据一致性校验

借鉴:https://segmentfault.com/a/1190000004309169 mysql学习:http://www.itdks.com/dakashuo/playback/267 怎么保证数据复制一致 半同步(5.7 loss zero replication) 异步类的复制: 1.要安装规范来 2.要敏锐的观察力 3.对于异常切换要有数据验证机制(使用GTID) 记账类数据:对比工具 pt-table-checksum使用 percona-tools里的一个工具,用来校验主从数

MySQL中校验规则的选取对数据的影响

在mysql中存在着各种utf8编码格式,如下表:1)utf8_bin2)utf8_general_ci utf8_bin将字符串中的每一个字符用二进制数据存储,区分大小写.utf8_genera_ci不区分大小写,ci为case insensitive的缩写,即大小写不敏感. 现在假设执行如下命令:create table test_bin (name varchar(32) not null primary key,age int unsigned not null) engine = In

pt-table-checksum校验mysql主从数据一致性

主从数据的一致性校验是个头疼的问题,偶尔被业务投诉主从数据不一致,或者几个从库之间的数据不一致,这会令人沮丧.通常我们仅有一种办法,热备主库,然后替换掉所有的从库.这不仅代价非常大,而且类似治标不治本的方案,让人十分不安.因此我们需要合适的工具,至少帮我们回答下面三个问题: 是从库延迟导致了用户看到的数据不一致,还是真的主从数据就不一致? 如果不一致,这个比例究竟多大? 下次还会出现吗? 回答清楚这几个问题,有助于我们决定是否修复,以及修复的方式,还可以帮我们找出不一致的数据,进而定位问题根源.