MySQL主备库数据一致性校验及修复

MySQL主备库数据一致性校验及修复,第1张

很多时候需要把一个从库提升为主库,但对从库和主库的数据一致性不敢保证,这时我们就可以利用 pt-table-checksum来检查主库数据的一致性,如果存在不一致的数据,我们可以利用pt-table-sync来修复这些不一致的数据。

在主(master)上通过执行校验的查询对复制的一致性进行检查,对比主从的校验值,从而产生结果

下面通过实际的例子来解释该工具如何使用:

主库(10.8.23.209)数据:

从库(10.8.23.208)数据:

从库(10.8.23.210)数据:

很明显主备数据不一致,我们使用工具来检测下:

校验命令参数解释:

校验结果字段解释:

好了,命令以及常用参数都介绍了,一起解释下上面执行的效果,通过DIFFS 是1 就可以看出主从的表数据不一致。怎么不一致呢? 通过指定—replicate=test.checksums 参数,就说明把检查信息都写到了checksums表中。

进入备库(10.8.23.208)中查看checksums表的信息:

进入备库(10.8.23.210)中查看checksums表的信息:

通过上面找到了这些不一致的数据,如何修复呢?利用另外一个工具 pt-table-sync。

高效的同步MySQL表之间的数据,他可以做单向和双向同步的表数据。他可以同步单个表,也可以同步整个库。它不同步表结构、索引、或任何其他模式对象。所以在修复一致性之前需要保证他们表存在。接着上面的复制情况,主库和从库的aaa表数据不一致,需要修复。

参数解释:

命令介绍完了,一起解释下执行的效果:通过(--print)打印出来了修复数据的sql语句,可以手动的去从行执行,让他们数据保持一致性。那能否直接执行?当然可以,通过(--execute)

没发现任何异常,然后检查主从数据的一致性:

主库(10.8.23.209)数据:

从库(10.8.23.208)数据:

从库(10.8.23.210)数据:

OK,数据已经保持一致了。

不过建议还是--print 打印出来的好,这样就可以知道那些数据有问题,可以人为的干预下。

不然直接执行了,出现问题之后不好处理。总之还是在处理之前做好数据的备份工作。

select *,if(sva=1,"男","女") as ssva from tableame where id =1

Quote

控制流程函数

CASE value WHEN [compare-value] THEN result [WHEN [compare-value] THEN result ...] [ELSE result] END CASE WHEN [condition] THEN result [WHEN [condition] THEN result ...] [ELSE result] END

在第一个方案的返回结果中, value=compare-value。而第二个方案的返回结果是第一种情况的真实结果。如果没有匹配的结果值,则返回结果为ELSE后的结果,如果没有ELSE 部分,则返回值为 NULL。

mysql>SELECT CASE 1 WHEN 1 THEN 'one'

->WHEN 2 THEN 'two' ELSE 'more' END

->'one'

mysql>SELECT CASE WHEN 1>0 THEN 'true' ELSE 'false' END

->'true'

mysql>SELECT CASE BINARY 'B'

->WHEN 'a' THEN 1 WHEN 'b' THEN 2 END

->NULL

一个CASE表达式的默认返回值类型是任何返回值的相容集合类型,但具体情况视其所在语境而定。如果用在字符串语境中,则返回结果味字符串。如果用在数字语境中,则返回结果为十进制值、实值或整数值。

IF(expr1,expr2,expr3)

如果 expr1 是TRUE (expr1 <>0 and expr1 <>NULL),则 IF()的返回值为expr2否则返回值则为 expr3。IF() 的返回值为数字值或字符串值,具体情况视其所在语境而定。

mysql>SELECT IF(1>2,2,3)

->3

mysql>SELECT IF(1<2,'yes ','no')

->'yes'

mysql>SELECT IF(STRCMP('test','test1'),'no','yes')

->'no'

如果expr2 或expr3中只有一个明确是 NULL,则IF() 函数的结果类型 为非NULL表达式的结果类型。

expr1 作为一个整数值进行计算,就是说,假如你正在验证浮点值或字符串值, 那么应该使用比较运算进行检验。

mysql>SELECT IF(0.1,1,0)

->0

mysql>SELECT IF(0.1<>0,1,0)

->1

在所示的第一个例子中,IF(0.1)的返回值为0,原因是 0.1 被转化为整数值,从而引起一个对 IF(0)的检验。这或许不是你想要的情况。在第二个例子中,比较检验了原始浮点值,目的是为了了解是否其为非零值。比较结果使用整数。

IF() (这一点在其被储存到临时表时很重要 ) 的默认返回值类型按照以下方式计算:

表达式

返回值

expr2 或expr3 返回值为一个字符串。

字符串

expr2 或expr3 返回值为一个浮点值。

浮点

expr2 或 expr3 返回值为一个整数。

整数

假如expr2 和expr3 都是字符串,且其中任何一个字符串区分大小写,则返回结果是区分大小写。

http://blog.knowsky.com/

IFNULL(expr1,expr2)

假如expr1 不为 NULL,则 IFNULL() 的返回值为 expr1否则其返回值为 expr2。IFNULL()的返回值是数字或是字符串,具体情况取决于其所使用的语境。

mysql>SELECT IFNULL(1,0)

->1

mysql>SELECT IFNULL(NULL,10)

->10

mysql>SELECT IFNULL(1/0,10)

->10

mysql>SELECT IFNULL(1/0,'yes')

->'yes'

IFNULL(expr1,expr2)的默认结果值为两个表达式中更加“通用”的一个,顺序为STRING、 REAL或 INTEGER。假设一个基于表达式的表的情况, 或MySQL必须在内存储器中储存一个临时表中IFNULL()的返回值:

CREATE TABLE tmp SELECT IFNULL(1,'test') AS test;

在这个例子中,测试列的类型为 CHAR(4)。

NULLIF(expr1,expr2)

如果expr1 = expr2 成立,那么返回值为NULL,否则返回值为 expr1。这和CASE WHEN expr1 = expr2 THEN NULL ELSE expr1 END相同。

mysql>SELECT NULLIF(1,1)

->NULL

mysql>SELECT NULLIF(1,2)

->1

注意,如果参数不相等,则 MySQL 两次求得的值为 expr1

用 pt-table-checksum 时,会不会影响业务性能?

实验

实验开始前,给大家分享一个小经验:任何性能评估,不要相信别人的评测结果,要在自己的环境上测试,并(大概)知晓原理。

我们先建一对主从:

然后用 mysqlslap跑一个持续的压力:

开另外一个会话,将 master 上的 general log 打开:

然后通过 pt-table-checksum 进行一次比较:

查看 master 的 general log,由于 mysqlslap 的影响,general log 中有很多内容,我们找到与 pt-table-checksum 相关的线程:

将该线程的 *** 作单独列出来:

*** 作比较多,我们一点一点来说明:

这里工具调小了 innodb 锁等待时间。使得之后的 *** 作,只要在 innodb 上稍微有锁等待,就会马上放弃 *** 作,对业务影响很小。

另外工具调小了 wait_timeout 时间,倒是没有特别的作用。

工具将隔离级别调整为了 RR 级别,事务的维护代价会比 RC 要高,不过后面我们会看到工具使用的每个事务都很小,加上之前提到 innodb 锁等待时间调到很小,对线上业务产生的成本比较小。

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

工具通过一系列 *** 作,了解表的概况。工具是一个数据块一个数据块进行校验,这里获取了第一个数据块的下边界。

接下来工具获取了下一个数据块的下边界,每个 SQL前都会 EXPLAIN 一下,看一下执行成本,非常小心翼翼。

之后工具获取了一个数据块的 checksum,这个数据块不大,如果跟业务流量有冲突,会马上出发 innodb 的锁超时,立刻退让。

以上是 pt-table-checksum 的一些设计,可以看到这几处都是精心维护了业务流量不受影响。

工具还设计了其他的一些机制保障业务流量,比如参数 --max-load 和 --pause-file 等,还有精心设计的数据块划分方法,索引选择方法等。大家根据自己的情况配合使用即可达到很好的效果。

总结

本期我们介绍了简单分析 pt-table-checksum 是否会影响业务流量,坊间会流传工具的各种参数建议或者不建议使用,算命的情况比较多,大家都可以用简单的实验来分析其中机制。

还是那个观点,性能测试不能相信道听途说,得通过实验去分析。


欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/zaji/8587320.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-04-18
下一篇2023-04-18

发表评论

登录后才能评论

评论列表(0条)

    保存