共计 4332 个字符，预计需要花费 11 分钟才能阅读完成。
本篇内容主要讲解“怎么解决 Mysql 主从不同步问题的”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“怎么解决 Mysql 主从不同步问题的”吧!
由于各种原因，mysql 主从架构经常会出现数据不一致的情况出现，大致归结为如下几类
1: 备库写数据
2: 执行 non-deterministic query
3: 回滚掺杂事务表和非事务表的事务
4:binlog 或者 relay log 数据损坏
数据不同步给应用带来的危害是致命的，当出现主从数据不一致的情况，常见的应对方法是先把从库下线，然后找个半夜三更的时间把应用停掉，重新执行同步，如果数据库的体积十分庞大，那工作量可想而知，会让人崩溃。本文介绍使用 percona-toolkit 工具对 mysql 主从数据库的同步状态进行检查和重新同步。
一：安装 percona-toolkit
# yum -y install perl-Time-HiRes # wget http://www.percona.com/downloads/percona-toolkit/2.2.13/tarball/percona-toolkit-2.2.13.tar.gz # tar -zxvpf percona-toolkit-2.2.13.tar.gz # cd percona-toolkit-2.2.13 # perl Makefile.PL # make # make install二：修改 mysql 的 binlog 格式 binlog_format 参数为 row 格式
mysql binlog 日志有三种格式，分别为 Statement, Mixed, 以及 ROW！
1.Statement：
每一条会修改数据的 sql 都会记录在 binlog 中。
优点：不需要记录每一行的变化，减少了 binlog 日志量，节约了 IO，提高性能。(相比 row 能节约多少性能与日志量，这个取决于应用的 SQL 情况，正常同一条记录修改或者插入 row 格式所产生的日志量还小于 Statement 产生的日志量，但是考虑到如果带条件的 update 操作，以及整表删除，alter 表等操作，ROW 格式会产生大量日志，因此在考虑是否使用 ROW 格式日志时应该跟据应用的实际情况，其所产生的日志量会增加多少，以及带来的 IO 性能问题。)
缺点：由于记录的只是执行语句，为了这些语句能在 slave 上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在 slave 得到和在 master 端执行时候相同 的结果。另外 mysql 的复制, 像一些特定函数功能，slave 可与 master 上要保持一致会有很多相关问题 (如 sleep() 函数，last_insert_id()，以及 user-defined functions(udf)会出现问题).
2.Row
不记录 sql 语句上下文相关信息，仅保存哪条记录被修改。
优点：binlog 中可以不记录执行的 sql 语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以 rowlevel 的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或 function，以及 trigger 的调用和触发无法被正确复制的问题
缺点: 所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容, 比如一条 update 语句，修改多条记录，则 binlog 中每一条修改都会有记录，这样造成 binlog 日志量会很大，特别是当执行 alter table 之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。
3.Mixed
是以上两种 level 的混合使用，一般的语句修改使用 statment 格式保存 binlog，如一些函数，statement 无法完成主从复制的操作，则采用 row 格式保存 binlog,MySQL 会根据执行的每一条具体的 sql 语句来区分对待记录的日志形式，也就是在 Statement 和 Row 之间选择一种. 新版本的 MySQL 中队 row level 模式也被做了优化，并不是所有的修改都会以 row level 来记录，像遇到表结构变更的时候就会以 statement 模式来记录。至于 update 或者 delete 等修改数据的语句，还是会记录所有行的变更。
主从数据库分别修改 my.cnf 文件相关配置项如下：
binlog_format=ROW
三：使用 pt-table-checksum 工具检查数据一致性情况
用法参考：
假设 192.168.1.205 是主库，192.168.1.207 是它的从库，端口在 3306。
1. 先校验
# pt-table-checksum --user=root --password=123456 \ --host=192.168.1.205 --port=3306 \ --databases=test --tables=t2 --recursion-method=processlist \ --no-check-binlog-format --nocheck-replication-filters \ --replicate=test.checksums2. 根据校验结果，只修复 192.168.1.207 从库与主库不一致的地方：
# pt-table-sync --execute --replicate \ test.checksums --sync-to-master h=192.168.1.207,P=3306,u=root,p=1234563. 修复后，再重新校验一次。执行 *** 步的语句即可。
4. 检查修复结果：登陆到 192.168.1.207，执行如下 sql 语句返回若为空，则说明修复成功：
SELECT * FROM test.checksums WHERE master_cnt this_cnt OR master_crc this_crc OR ISNULL(master_crc) ISNULL(this_crc)各参数含义
–nocheck-replication-filters: 不检查复制过滤器，建议启用。后面可以用 –databases 来指定需要检查的数据库。
–no-check-binlog-format: 不检查复制的 binlog 模式，要是 binlog 模式是 ROW，则会报错。
–replicate-check-only: 只显示不同步的信息。
–replicate=: 把 checksum 的信息写入到指定表中，建议直接写到被检查的数据库当中。
–databases=: 指定需要被检查的数据库，多个则用逗号隔开。
–tables=：指定需要被检查的表，多个用逗号隔开
h=127.0.0.1:Master 的地址
u=root: 用户名
p=123456: 密码
P=3306: 端口
下面我们来模拟下主从数据库不同步情况下的 pt-table-checksum，为了方便，这里我们采用 test schema
1: 主库上建表，插入测试数据
mysql create table t2 (id int primary key,name varchar(100) not null,salary int); mysql CREATE PROCEDURE test_insert () BEGIN DECLARE i INT DEFAULT 0; WHILE i 10000 DO INSERT INTO t2 VALUES (i,CONCAT( 员工 ,i), i); SET i=i+1; END WHILE ; END;; mysql CALL test_insert();从库上校验当前数据的同步情况为正常。
从库上删除一半的数据
mysql delete from t2 where id 5000; Query OK, 4999 rows affected (0.14 sec) mysql select count(*) from t2; +----------+ | count(*) | +----------+ | 5001 | +----------+ 1 row in set (0.01 sec)2：使用 pt-table-checksum 工具进行校验：
# pt-table-checksum --user=root --password=123456 \
--host=192.168.1.205 --port=3306 \
--databases=test --tables=t2 --recursion-method=processlist \
--no-check-binlog-format --nocheck-replication-filters \
--replicate=test.checksums
3：登陆从库进行查询 checksum 表
mysql SELECT
*
FROM
test.checksums
WHERE
master_cnt this_cnt
OR master_crc this_crc
OR ISNULL(master_crc) ISNULL(this_crc)
4：使用 pt-table-sync 工具进行数据重新同步
# pt-table-sync --execute --replicate \ test.checksums --sync-to-master h=192.168.1.207,P=3306,u=root,p=1234565：从库上验证数据，中文“员工”变成了“??”
检查主库，发现出现一样的情况，中文“员工”变成了“??”，猜想和字符集设置相关。
于是检查数据库字符集设置，发现 test 库字符集非 utf8
主从库 my.cnf 文件添加如下配置项后重启数据库实例
character_set_client=utf8
character_set_server=utf8
重新执行以上 1 - 4 步，发现一切正常！关键第 4 步要加 –charset=utf8 参数
# pt-table-sync --execute --replicate \
test.checksums --charset=utf8 \
--sync-to-master h=192.168.1.207,P=3306,u=root,p=123456
到此，相信大家对“怎么解决 Mysql 主从不同步问题的”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
