MySQL主从服务器数据一致性的核对与修复

运维 系统运维
当遇到MySQL主从服务器数据一致性问题时,该怎么解决呢?本文记录了类似问题的解决方法,希望能给朋友们带来帮助,遇到此类问题时,不会手忙脚乱。

  我上一次遇到MySQL主从服务器数据一致性问题,想想是几年前的事情了,还依稀记得当时惊慌失措的情景,好在最后借助Maatkit解决了问题。几年后,当我再次面对同样的问题时,Maatkit已经不复存在,转而成为了Percona Toolkit的一部分,不变的是我依旧手忙脚乱,所以还是记录一下吧,保不准啥时候又会遇到这个问题。

  如果你在MySQL从服务器上遇到类似下面的错误信息,那么恭喜你中招了:

  1. mysql> SHOW SLAVE STATUS\G 
  2. Last_Error: Error 'Duplicate entry '...' for key ...' on query. 

  为啥会出现唯一索引键值重复?最大的可能是错误的对从服务器做了写操作!出现此类错误的时候,很多人会用sql_slave_skip_counter操作跳过错误,甚至有人写了脚本,如果有多个错误,就循环多次执行sql_slave_skip_counter:

  1. mysql> SET GLOBAL sql_slave_skip_counter = 1
  2. mysql> START SLAVE; 

  可惜,即便sql_slave_skip_counter操作能够暂时让主从恢复工作,但多半数据一致性已经被破坏的更严重了,早晚有一天被掩盖的问题会再次爆发出来。

  Percona Toolkit里的pt-table-checksum和pt-table-sync可以搞定此类问题。它们的安装很简单,可以依照自己的操作系统选择下载rpm或者deb软件包来安装,当然也可以使用源代码来安装,不过要注意的是,必须确保系统已经安装了依赖的Perl软件包:

  1. shell> perl -MCPAN -e 'install DBI' 
  2. shell> perl -MCPAN -e 'install DBD::mysql' 
  3. shell> perl -MCPAN -e 'install Term::ReadKey' 

  顺便说一下,我在安装某些Perl模块的时候,出现类似下面的错误提示:

  1. Can’t locate object method “install” via package “…” 

  如果你也遇到了类似的问题,可以进入到Perl命令行安装:

  1. shell> perl -MCPAN -e shell 
  2. cpan> install ... 

  安装Percona Toolkit的剩余步骤就是Perl软件的固定打法了:

  1. shell> perl Makefile.PL 
  2. shell> make 
  3. shell> make install 

  前戏进行到这里应该可以了,下面让我们直捣黄龙,看看如何解决问题:

  MySQL主从服务器数据一致性的核对

  通过在主服务器上运行pt-table-checksum,它会通过一系列的MySQL函数计算每个表的散列值,利用主从复制关系,把同样的计算过程在从服务器上重放,从而就拿到了主从服务器各自的散列值,只要比较散列值是否相同就OK了。

  这里面有两点需要说明:

  计算表的散列值时,pt-table-checksum并不是直接计算整个表的散列值,而是分块计算,这样就避免了造成从服务器长时间的延迟。

  因为通过MySQL函数计算散列的过程需要在从服务器上重放,所以主从复制的格式必须是基于STATEMENT的,不能是基于ROW的。

  实际操作时的命令大致如下:

  1. shell> pt-table-checksum \ 
  2. --replicate=percona.checksums \ 
  3. --host=<MASTER_HOST> \ 
  4. --user=<MASTER_USER> \ 
  5. --password=<MASTER_PASSWORD> 

  说明:replicate选项指定了结果保存到哪个库和表中,如果你愿意,可以手动查询:

  1. SELECT db, tbl, SUM(this_cnt) AS total_rows, COUNT(*) AS chunks 
  2. FROM percona.checksums 
  3. WHERE ( 
  4. master_cnt <> this_cnt 
  5. OR master_crc <> this_crc 
  6. OR ISNULL(master_crc) <> ISNULL(this_crc)) 
  7. GROUP BY db, tbl; 

  BTW:多数情况下,只要比较「master_crc <> this_crc」就可以了。

  MySQL主从服务器数据一致性的修复

  通过在主服务器上运行pt-table-sync,它会重建数据,数据通过复制从主服务器同步到从服务器,从而修复了一致性,在操作过程中,可以利用pt-table-checksum的结果。

  1. shell> pt-table-sync \ 
  2. --execute \ 
  3. --replicate=percona.checksums \ 
  4. --charset=<CHARSET> \ 
  5. --host=<MASTER_HOST> \ 
  6. --user=<MASTER_USER> \ 
  7. --password=<MASTER_PASSWORD> 

  说明:因为pt-table-sync会重建数据,所以有一定的风险,最好提前备份好数据。如果仍然不放心,可以使用它提供的「print」选项,它会打印出相应的SQL,你可以审查一下到底执行了那些操作,然后通过手动执行来完成同步。

  本文例子中,我们为了方便,在运行Percona Toolkit命令的时候直接键入了密码等敏感信息,这在很多时候是不安全的,比如说别人可以通过查看命令历史拿到密码。还好我们有「ask-pass」选项可以解决此类问题,实际上我们还可以更进一步,直接把密码等敏感信息保存到配置文件中,最容易想到的配置文件是「~/.my.cnf」,此外,还有几个更官方的配置文件可供选择,我们可以在源代码里看到它们的踪影:

  1. default_files => [ 
  2. "/etc/percona-toolkit/percona-toolkit.conf", 
  3. "/etc/percona-toolkit/$program_name.conf", 
  4. "$home/.percona-toolkit.conf", 
  5. "$home/.$program_name.conf", 
  6. … 

  俗话说:不怕贼偷,就怕贼惦记着。看待问题的态度亦是如此:不怕出问题,就怕问题潜伏在暗处窥视着你,而你却一无所知。大家没事儿的时候多查查主从一致性吧。

责任编辑:黄丹 来源: 火丁笔记
相关推荐

2024-08-20 16:13:52

2023-12-01 13:51:21

数据一致性数据库

2009-06-18 09:18:08

Oracle检索数据数据一致性事务恢复

2019-01-15 17:58:03

微服务架构数据

2019-12-17 08:40:33

微服务架构数据

2023-11-22 12:55:59

微服务架构数据库

2023-05-26 07:34:50

RedisMySQL缓存

2022-02-17 21:04:27

数据库MysqlRedis

2022-09-15 10:37:46

MySQLRedis数据一致性

2021-12-14 07:15:57

MySQLRedis数据

2021-11-01 21:15:54

微服务系统数据

2023-09-24 14:35:43

Redis数据库

2023-09-07 08:11:24

Redis管道机制

2019-11-21 10:19:45

数据应用场景系统

2023-12-27 14:23:10

微服务数据存储

2021-12-05 21:06:27

软件

2021-10-18 10:30:59

流计算阿里云

2021-10-13 09:55:11

流计算引擎数据

2024-07-04 12:36:50

2023-06-07 08:10:29

点赞
收藏

51CTO技术栈公众号