由于mysql主从复制是基于binlog的一种异步复制通过网络传送binlog文件,理所当然网络延迟是主从不同步的绝大多数的原因,特别是跨机房的数据同步出现这种几率非常的大,所以做读写分离,注意从业务层进行前期设计。
由于mysql主从复制是主数据库上面启动1个io线程,而从上面启动1个sql线程和1个io线程,当中任何一台机器的负载很高,忙不过来,导致其中的任何一个线程出现资源不足,都将出现主从不一致的情况。
主数据库上面设置的max_allowed_packet比从数据库大,当一个大的sql语句,能在主数据库上面执行完毕,从数据库上面设置过小,无法执行,导致的主从不一致。
key自增键开始的键值跟自增步长设置不一致引起的主从不一致。
mysql异常宕机情况下,如果未设置sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出现binlog或者relaylog文件出现损坏,导致主从不一致。
mysql本身的bug引起的主从不同步
特别是高版本是主,低版本为从的情况下,主数据库上面支持的功能,从数据库上面不支持该功能。
在业务不保证数据强一致性的情况下,可以选择忽略(技术永远是为业务提供服务的!);
操作
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,现在主从同步状态正常了。。。
该方法适用于主从库数据相差较大,或者要求数据完全统一的情况
重新做主从,然后使用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
两项
percona-toolkit工具中最主要的三个组件分别是:
项目 | Value |
---|---|
pt-table-checksum | 负责监测mysql主从数据一致性 |
pt-table-sync | 负责当主从数据不一致时修复数据,让它们保存数据的一致性 |
pt-heartbeat | 负责监控mysql主从同步延迟 |
percona-toolkit工具安装详细
建议:master端和slave端都安装percona-toolkit工具
2.1 安装依赖包 yum install perl-IO-Socket-SSL perl-DBD-MySQL perl-Time-HiRes perl perl-DBI -y 2.2 安装percona-toolkit wget https://www.percona.com/redir/downloads/percona-release/redhat/0.1-6/percona-release-0.1-6.noarch.rpm yum install percona-release-0.1-6.noarch.rpm 2.3查看可下载的包 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.4 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
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值,该参数是不支持负值的,也就是不应该出现。