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.0 00003',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⼯具安装
建议：master 端和 slave 端都安装 percona-toolkit ⼯具
2.1 安装yum仓库（两个仓库都有下）
#percona-toolkit的yum仓库
yum install repo.percona/arch.rpm -y
#MYSQL的yum仓库
yum install -y sql//arch.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.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.16 8.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值，该参数是不⽀持负值的，也就是不应该出现。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论