Mysql如何解决主从数据不一致的问题

一、MySQL主从不同步情况

1、网络的延迟

由于mysql主从复制是基于binlog的一种异步复制通过网络传送binlog文件，理所当然网络延迟是主从不同步的绝大多数的原因，特别是跨机房的数据同步出现这种几率非常的大，所以做读写分离，注意从业务层进行前期设计。

2、主从两台机器的负载不一致

由于mysql主从复制是主数据库上面启动1个io线程，而从上面启动1个sql线程和1个io线程，当中任何一台机器的负载很高，忙不过来，导致其中的任何一个线程出现资源不足，都将出现主从不一致的情况。

3、max_allowed_packet设置不一致

主数据库上面设置的max_allowed_packet比从数据库大，当一个大的sql语句，能在主数据库上面执行完毕，从数据库上面设置过小，无法执行，导致的主从不一致。

4、自增键不一致

key自增键开始的键值跟自增步长设置不一致引起的主从不一致。

5、同步参数设置问题

mysql异常宕机情况下，如果未设置sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出现binlog或者relaylog文件出现损坏，导致主从不一致。

6、自身bug

mysql本身的bug引起的主从不同步

7、版本不一致

特别是高版本是主，低版本为从的情况下，主数据库上面支持的功能，从数据库上面不支持该功能。

二、解决办法

1、忽略错误后，继续同步

在业务不保证数据强一致性的情况下，可以选择忽略（技术永远是为业务提供服务的！）；
操作

1.停止slave从节点
stop slave; 
2.跳过一步错误，后面的数字可变 
set global sql_slave_skip_counter =1; 
3.开启slave
start slave; 
4.查看slave状态
show slave status\G  
Slave_IO_Running: Yes 
Slave_SQL_Running: Yes 
ok，现在主从同步状态正常了。。。 

2、重新做主从，完全同步

该方法适用于主从库数据相差较大，或者要求数据完全统一的情况
重新做主从，然后使用change master指定同步位置，这种耗时长

主库执行

1.先进入主库，进行锁表，防止数据写入 
mysql> flush tables with read lock; 
注意：该处是锁定为只读状态，语句不区分大小写 
2.进行数据备份
mysqldump -uroot -p123456 --lock-all-tables --flush-logs hadoop > /data/hadoop.sql
cp /data/hadoop.sql root@192.168.20.201:/data/
mysql> unlock tables;

从库执行

1.停止从库的状态
mysql> stop slave;
2.清除从节点配置信息（仅清理master.info 和 relay-log.info 文件）
mysql> reset slave;
3.从库执行mysql命令，导入数据备份
mysql> source /data/hadoop.sql
4.设置从库同步
mysql> change master to master_host='192.168.20.195', master_port=3306, master_user='test',master_password='123456', master_log_file='mysql-bin.000003',master_log_pos=932;

注：注意同步点，就是主库show master status信息里的File| Position两项

3、使用第三方工具如pt-table-sync

1、percona-toolkit工具介绍

percona-toolkit工具中最主要的三个组件分别是：

项目	Value
pt-table-checksum	负责监测mysql主从数据一致性
pt-table-sync	负责当主从数据不一致时修复数据，让它们保存数据的一致性
pt-heartbeat	负责监控mysql主从同步延迟

2、percona-toolkit工具安装

percona-toolkit工具安装详细

建议：master 端和 slave 端都安装 percona-toolkit 工具

2.1 安装yum仓库（两个仓库都有下）

#percona-toolkit的yum仓库
yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm -y
#MYSQL的yum仓库
yum install -y  https://repo.mysql.com//mysql80-community-release-el7-3.noarch.rpm 

2.2 安装mysql相关的libs-compat软件。

yum list | grep mysql | grep libs-compat
mysql-community-libs-compat.i686         5.7.30-1.el7                  mysql57-community
mysql-community-libs-compat.x86_64       5.7.30-1.el7                  mysql57-community

yum -y install mysql-community-libs-compat.x86_64

2.3 安装依赖包

yum install perl-IO-Socket-SSL perl-DBD-MySQL perl-Time-HiRes perl perl-DBI -y

2.4 查看可下载的包

yum list | grep percona-toolkit
percona-toolkit.noarch                   2.2.20-1                      percona-release-noarch
percona-toolkit.x86_64                   3.0.10-1.el7                  percona-release-x86_64
percona-toolkit-debuginfo.x86_64         3.0.10-1.el7                  percona-release-x86_64

2.5 安装

yum install percona-toolkit -y

验证安装是否成功

[root@host-47-106-141-17 ~]# pt-table-checksum --help
[root@host-47-106-141-17 ~]# pt-query-digest --help

三、使用

在主库执行授权（一定要对主库ip授权，授权的用户名和密码可以自行定义，不过要保证这个权限能同时登陆主库和从库）

grant select,process,super,replication slave,create,delete,insert,update on *.* to 'repsta'@'%' identified by 'QianFeng@123';

在主库上执行的一个检查主从数据一致性的命令

 pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=test.checksums   --create-replicate-table --databases=mysql h=192.168.130.181,u=repsta,p='QianFeng@123',P=3306

三、监控MySQL的监控项

Slave_IO_Running

该参数可作为io_thread的监控项，Yes表示io_thread的和主库连接正常并能实施复制工作，No则说明与主库通讯异常，多数情况是由主从间网络引起的问题；

Slave_SQL_Running

该参数代表sql_thread是否正常，具体就是语句是否执行通过，常会遇到主键重复或是某个表不存在。

Seconds_Behind_Master

是通过比较sql_thread执行的event的timestamp和io_thread复制好的event的timestamp(简写为ts)进行比较，而得到的这么一个差值；NULL—表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No，而非Yes。0 — 该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为lag不存在。
正值 — 表示主从已经出现延时，数字越大表示从库落后主库越多。负值 — 几乎很少见，我只是听一些资深的DBA说见过，其实，这是一个BUG值，该参数是不支持负值的，也就是不应该出现。