MySQL主从同步延迟原因及解决办法

MySQL主从延迟原因以及解决方案:谈到MySQL数据库主从同步延迟原理,得从mysql的数据库主从复制原理说起,mysql的主从复制都是单线程的操作(mysql5.6版本之前),主库对所有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数据库主从同步延迟解决方案

(1)最简单的减少slave同步延时的方案就是在架构上做优化,尽量让主库的DDL快速执行。还有就是主库是写,对数据安全性较高,比如sync_binlog=1,innodb_flush_log_at_trx_commit=1 之类的设置,而slave则不需要这么高的数据安全,完全可以讲sync_binlog设置为0或者关闭binlog,innodb_flushlog也可以设置为0来提高sql的执行效率。

(2)另外就是使用比主库更好的硬件设备作为slave。

就是把,一台从服务器当度作为备份使用,而不提供查询,那边他的负载下来了,执行relay log里面的SQL效率自然就高了。

(3)增加从服务器喽,这个目的还是分散读的压力,从而降低服务器负载。

4.MySQL数据库主从同步延迟产生的因素。

1. 网络延迟 2. master负载 3. slave负载 一般的做法是,使用多台slave来分摊读请求,再从这些slave中取一台专用的服务器,只作为备份用,不进行其他任何操作,就能相对最大限度地达到’实时’的要求了

另外,再介绍2个可以减少延迟的参数 –slave-net-timeout=seconds 参数含义:当slave从主数据库读取log数据失败后,等待多久重新建立连接并获取数据 slave_net_timeout单位为秒 默认设置为 3600秒 slave_net_timeout 3600 –master-connect-retry=seconds 参数含义:当重新建立主从连接时,如果连接建立失败,间隔多久后重试。 master-connect-retry单位为秒 默认设置为 60秒 通常配置以上2个参数可以减少网络问题导致的主从数据同步延迟。

?

?

---------------------------------------------------------------------自己总结———————————————————————

主从同步延迟的解决办法:

(1)参数:我们知道因为主服务器要负责更新操作, 他对安全性的要求比从服务器高,所有有些设置可以修改,比如sync_binlog=1,innodb_flush_log_at_trx_commit=1 之类的设置,而slave则不需要这么高的数据安全,完全可以讲sync_binlog设置为0或者关闭binlog,innodb_flushlog, innodb_flush_log_at_trx_commit 也 可以设置为0来提高sql的执行效率 这个能很大程度上提高效率。

从库优化Mysql参数。比如增大innodb_buffer_pool_size,让更多操作在Mysql内存中完成,减少磁盘操作。

(2)版本:主从同步以后, 主服务器会把更新语句写入binlog, ? 从服务器的IO 线程(这里要注意, 5.6.3 之前的IO线程仅有一个,5.6.3之后的有多线程去读了,速度自然也就加快了)回去读取主服务器的binlog 并且写到从服务器的Relay log 里面,然后从服务器的 的SQL thread 会一个一个执行 relay log 里面的sql , 进行数据恢复。

(2)硬件:使用比主库更好的硬件设备作为slave。

从库使用高性能主机。包括cpu强悍、内存加大。避免使用虚拟云主机,使用物理主机,这样提升了i/o方面性。

从库使用SSD磁盘。机械硬盘是靠磁头旋转到指定位置来读数据、写数据。转来转去的,我们叫做i/o。磁盘i/o存在速度瓶颈。固态硬盘是一个电子设备,电子设备不需要机械旋转,读写固态硬盘上任意位置的数据,速度都是一样的。

(3)网络:

网络优化。网络堵塞,也会导致同步延迟。跨机房的数据库同步,会存在同步延迟。保证主从在同一个机房里面去。

(4)代码:

业务代码的妥协。将实时性要求高的某些操作,使用主库做读操作。比如我写了数据到主库了,需要马上展示数据,不要到从库去读数据,因为从库可能还没同步过去呢。直接从主库读数据,保证是最新的数据展示。

?

原文地址:https://www.cnblogs.com/sqlservertongbu/p/11013653.html

时间: 2024-10-13 18:05:25

MySQL主从同步延迟原因及解决办法的相关文章

mysql主从同步延迟原因及解决方法

MySQL主从延迟原因以及解决方案:谈到MySQL数据库主从同步延迟原理,得从mysql的数据库主从复制原理说起,mysql的主从复制都是单线程的操作(mysql5.6版本之前),主库对所有DDL和DML产生binlog,binlog是顺序写,所以效率很高. slave的Slave_IO_Running线程会到主库取日志,效率会比较高,slave的Slave_SQL_Running线程将主库的DDL和DML操作都在slave实施.DML和DDL的IO操作是随机的,不是顺序的,因此成本会很高,还可

MySQL主从同步延迟717秒?!!

原标题:MySQL主从同步延迟717秒?!! 最近业务MySQL主从监控刚加好,随后总收到延迟几百秒的告警,但实际排查下来却没有大碍,告警信息如下: 网上找下来也有人遇到同样的问题,(但这个问题属于MySQL的BUG还是zabbix的BUG呢?..) 分析的很有深度,原理透彻,这里分享给大家 MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ,用于衡量主备之间的复制延迟,但是 今天碰到了一个场景,发现 Seconds_Behind_Ma

Mysql主从同步延迟与系统时间的关系

Mysql主从同步延迟受到多种因素影响, 比如大事务, 从库查询压力, 网路延迟等: 这些比较常见: 但还受到主从机器系统时钟差的影响,这一点可能容易被忽视.上周, 就遇到了这样的情况, 主库的系统时间由于某种原因落后于从库几十秒, 结果频繁的出现大的主从延迟同步 ,查了N久业务方面的问题,都找不出原因: 在和同事的交流中,发现大家对参数Seconds_Behind_Master的理解有点补一样,基本有两种理解: 一种理解是来源于 Mysql手册上的描述,大体意思是这个时间是从库线程处理的最近的

pt-heartbeat监测mysql主从同步延迟

pt-heartbeat监测mysql主从同步延迟: 安装percona toolkit(pt-heartbeat为该软件的子命令): http://repo.percona.com/release/6/RPMS/x86_64/percona-toolkit-3.0.13-1.el6.x86_64.rpm yum install perl-DBD-MySQL yum install perl-IO-Socket-SSL yum install perl-TermReadKey 在主库上创建hea

MySQL主从同步延迟的原因及解决办法

由于历史原因,MySQL复制基于逻辑的二进制日志,而非重做日志.多次被问到何时MySQL能支持基于物理的复制,其实这就看MySQL各位大佬的想法.上次和赖老师脑暴,倏地说道:MySQL会不会来个基于Paxos的redo复制? 物理复制的真正好处不在于正确性,因为基于ROW格式的日志复制也已能完全保证复制的正确性.由于物理日志的写入是在事务执行过程中就不断写入,而二进制日志的写入仅仅在事务提交时.因此物理日志的优势如下所示: 复制架构下,大事务日志提交速度快: 复制架构下,主从数据延迟小: 假设执

使用MySQL Proxy解决MySQL主从同步延迟

MySQL的主从同步机制非常方便的解决了高并发读的应用需求,给Web方面开发带来了极大的便利.但这种方式有个比较大的缺陷在于MySQL的同步机制 是依赖Slave主动向Master发请求来获取数据的,而且由于服务器负载.网络拥堵等方面的原因,Master与Slave 之间的数据同步延迟是完全没有保证的.短在1秒内,长则几秒.几十秒甚至更长都有可能. 由于数据延迟问题的存在,当应用程序在Master 上进行数据更新,然后又立刻需要从数据库中读取数据时,这时候如果应用程序从Slave上取数据(这也是

[转载] 使用MySQL Proxy解决MySQL主从同步延迟

原文地址:http://koda.iteye.com/blog/682547 MySQL的主从同步机制非常方便的解决了高并发读的应用需求,给Web方面开发带来了极大的便利.但这种方式有个比较大的缺陷在于MySQL的同步机制是依赖Slave主动向Master发请求来获取数据的,而且由于服务器负载.网络拥堵等方面的原因,Master与Slave 之间的数据同步延迟是完全没有保证的.短在1秒内,长则几秒.几十秒甚至更长都有可能. 由于数据延迟问题的存在,当应用程序在Master 上进行数据更新,然后又

mysql主从同步异常原因及恢复syncnavigator

mysql数据库做主从复制,不仅可以为数据库的数据做实时备份,保证数据的完整性,还能做为读写分离,提升数据库的整体性能.但是,mysql主从复制经常会因为某些原因使主从数据同步出现异常.因此,下面介绍的是mysql主从同步异常的原因及恢复的方法. 这个问题是在部署主从复制的时候,可能会遇到的 回到顶部 Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL s

mysql主从同步延迟zabbix怎么监控

这个涉及到zabbix自定义监控项与MySQL主从同步两个技术,首先确保MySQL主从同步的前提下,在从库show slave status\G中找到"Seconds_Behind_Master"参数,改参数表示从库与主库同步的延迟间隔:然后在被监控端的zabbix-agent配置文件中添加"UserParameter=db_status,mysql -uzabbix -pzabbixpass -e "show slave status\G" 2>/