mysql出现主从同步不一致的情况分析
本篇内容主要讲解“MySQL出现主从同步不一致的情况分析”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“mysql出现主从同步不一致的情况分析”吧!
10余年的金昌网站建设经验,针对设计、前端、开发、售后、文案、推广等六对一服务,响应快,48小时及时工作处理。网络营销推广的优势是能够根据用户设备显示端的尺寸不同,自动调整金昌建站的显示方式,使网站能够适用不同显示终端,在浏览器中调整网站的宽度,无论在任何一种浏览器上浏览网站,都能展现优雅布局与设计,从而大程度地提升浏览体验。创新互联公司从事“金昌网站设计”,“金昌网站推广”以来,每个客户项目都认真落实执行。
1. MySQL数据库主从同步延迟原理。
答:谈到MySQL数据库主从同步延迟原理,得从mysql的数据库主从复制原理说起,mysql的主从复制都是单线程的操作,主库对所有DDL和 DML产生binlog,binlog是顺序写,所以效率很高,slave的Slave_IO_Running线程到主库取日志,效率很比较高,下一步, 问题来了,slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的,不是顺 序的,成本高很多,还可能可slave上的其他查询产生lock争用,由于Slave_SQL_Running也是单线程的,所以一个DDL卡主了,需要 执行10分钟,那么所有之后的DDL会等待这个DDL执行完才会继续执行,这就导致了延时。有朋友会问:“主库上那个相同的DDL也需要执行10分,为什 么slave会延时?”,答案是master可以并发,Slave_SQL_Running线程却不可以。
2. MySQL数据库主从同步延迟是怎么产生的。
答:当主库的TPS并发较高时,产生的DDL数量超过slave一个sql线程所能承受的范围,那么延时就产生了,当然还有就是可能与slave的大型query语句产生了锁等待。
3. MySQL数据库主从同步延迟解决方案
答:最简单的减少slave同步延时的方案就是在架构上做优化,尽量让主库的DDL快速执行。还有就是主库是写,对数据安全性较高,比如 sync_binlog=1,innodb_flush_log_at_trx_commit = 1 之类的设置,而slave则不需要这么高的数据安全,完全可以讲sync_binlog设置为0或者关闭binlog,innodb_flushlog也 可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。
mysql-5.6.3已经支持了多线程的主从复制。
GTID的概念
普通的复制过程中,从库通过记录主库的binlog文件名和偏移量来记录和接收主库binlog的事件工作进展。下次开始复制的时候告知主库这些信息,让主库可以从正确的位置开始发送binlog的事件给从库。但基于GTID的复制就不再需要告知这些事情,在执行 CHANGE MASTER TO 命令,也不需要指定MASTER_LOG_FILE 和 MASTER_LOG_POS参数。只需要指定MASTER_AUTO_POSTION = 1 就可以了,主库会根据从库发送过来的一个GTID集合信息来决定从哪里开始发送binlog事件。大大简化了数据库管理员在复制中的工作。
GTID是在数据库提交事务时创建的唯一的标示符。该标示符与事务是一一相关的。
GTID有两部分组成,如下所示:
GTID = source_id:transaction_id
source_id 用于标识这个事务是在哪个数据库实例上执行的。用的是uuid作为source_id 。
transaction_id 是一个序列号,取决于该事务在数据库上的提交顺序。该序列号初始为1.
在MySQL5.6以前的版本,同步复制都是单线程的,只能一个一个执行。在5.6做到了多个库多线程复制。
但是需要注意的是。一个库只能由一个线程去复制。也就是说若复制的库只有1个,那么线程也只有一个。复制的库有2个。那么线程可以增加到两个。
GTID的作用,具体归纳下来有以下两点:
1.根据GTID来确认事务最初的是在哪个实例上提交的
2.GTID的存在方便了Replication和failover。
到此,相信大家对“mysql出现主从同步不一致的情况分析”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!
网站标题:mysql出现主从同步不一致的情况分析
路径分享:http://scyanting.com/article/jpoijo.html