mysql 主从延迟及对应解决方案

MySQL的主从同步是一个很成熟的架构，优点为：①在从服务器可以执行查询工作(即我们常说的读功能)，降低主服务器压力;②在从主服务器进行备份，避免备份期间影响主服务器服务;③当主服务器出现问题时，可以切换到从服务器。

相信大家对于这些好处已经非常了解了，在项目的部署中也采用这种方案。但是MySQL的主从同步一直有从库延迟的问题，那么为什么会有这种问题。这种问题如何解决呢？

1. MySQL数据库主从同步延迟原理。

2. MySQL数据库主从同步延迟是怎么产生的。

3. MySQL数据库主从同步延迟解决方案。

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。

附加：

sync_binlog 配置说明：

sync_binlog”：这个参数是对于MySQL系统来说是至关重要的，他不仅影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下：

sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。

sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

在MySQL中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。

从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。

innodb_flush_log_at_trx_commit 配置说明：

默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电池供电缓存（Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统挂了时才可能丢数据。

mysql-5.6.3已经支持了多线程的主从复制。原理和丁奇的类似，丁奇的是以表做多线程，Oracle使用的是以数据库(schema)为单位做多线程，不同的库可以使用不同的复制线程。

基于局域网的master/slave机制在通常情况下已经可以满足'实时'备份的要求了。如果延迟比较大，就先确认以下几个因素：
1. 网络延迟
2. master负载
3. slave负载
一般的做法是，使用多台slave来分摊读请求，再从这些slave中取一台专用的服务器，只作为备份用，不进行其他任何操作，就能相对最大限度地达到'实时'的要求了

slave_net_timeout单位为秒默认设置为 3600秒

参数含义：当slave从主数据库读取log数据失败后，等待多久重新建立连接并获取数据

master-connect-retry单位为秒默认设置为 60秒

参数含义：当重新建立主从连接时，如果连接建立失败，间隔多久后重试。

通常配置以上2个参数可以减少网络问题导致的主从数据同步延迟

判断主从延时，通常有两个方法：

1. Seconds_Behind_Master vs 2. mk-heartbeat，下面具体说下两者在实现功能的差别。

可以通过监控show slave status\G命令输出的Seconds_Behind_Master参数的值来判断，是否有发生主从延时。
其值有这么几种：
NULL - 表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No,而非Yes.
0 - 该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为lag不存在。
正值 - 表示主从已经出现延时，数字越大表示从库落后主库越多。
负值 - 几乎很少见，只是听一些资深的DBA说见过，其实，这是一个BUG值，该参数是不支持负值的，也就是不应该出现。

Seconds_Behind_Master是通过比较sql_thread执行的event的timestamp和io_thread复制好的 event的timestamp(简写为ts)进行比较，而得到的这么一个差值。我们都知道的relay-log和主库的bin-log里面的内容完全一样，在记录sql语句的同时会被记录上当时的ts，所以比较参考的值来自于binlog，其实主从没有必要与NTP进行同步，也就是说无需保证主从时钟的一致。你也会发现，其实比较真正是发生在io_thread与sql_thread之间，而io_thread才真正与主库有关联，于是，问题就出来了，当主库I/O负载很大或是网络阻塞，io_thread不能及时复制binlog（没有中断，也在复制），而sql_thread一直都能跟上 io_thread的脚本，这时Seconds_Behind_Master的值是0，也就是我们认为的无延时，但是，实际上不是，你懂得。这也就是为什么大家要批判用这个参数来监控数据库是否发生延时不准的原因，但是这个值并不是总是不准，如果当io_thread与master网络很好的情况下，那么该值也是很有价值的。（就好比：妈–儿子–媳妇的关系，妈与儿子亲人，媳妇和儿子也亲人，不见得媳妇与妈就很亲。开个玩笑:-）之前，提到 Seconds_Behind_Master这个参数会有负值出现，我们已经知道该值是io_thread的最近跟新的ts与sql_thread执行到的ts差值，前者始终是大于后者的，唯一的肯能就是某个event的ts发生了错误，比之前的小了，那么当这种情况发生时，负值出现就成为可能。

方法2. mk-heartbeat，Maatkit万能工具包中的一个工具，被认为可以准确判断复制延时的方法。

mk-heartbeat的实现也是借助timestmp的比较实现的，它首先需要保证主从服务器必须要保持一致，通过与相同的一个NTP server同步时钟。它需要在主库上创建一个heartbeat的表，里面至少有id与ts两个字段，id为server_id，ts就是当前的时间戳 now()，该结构也会被复制到从库上，表建好以后，会在主库上以后台进程的模式去执行一行更新操作的命令，定期去向表中的插入数据，这个周期默认为1 秒，同时从库也会在后台执行一个监控命令，与主库保持一致的周期去比较，复制过来记录的ts值与主库上的同一条ts值，差值为0表示无延时，差值越大表示延时的秒数越多。我们都知道复制是异步的ts不肯完全一致，所以该工具允许半秒的差距，在这之内的差异都可忽略认为无延时。这个工具就是通过实打实的复制，巧妙的借用timestamp来检查延时，赞一个！

from:https://www.cnblogs.com/cnmenglang/p/6393769.html

mysql 主从延迟及对应解决方案相关推荐

MySQL主从延迟的解决方案
之前项目中基于 MySQL 主从复制以及 AOP 的方式实现了读写分离,也写了博客记录了这个实现过程.既然配置了 MySQL 主从复制,那么自然会存在主从延迟,如何尽可能减小主从延迟对应用系统的影响是 ...
mysql主从延迟过高
mysql主从延迟过高怎么发现主从有延迟的,因为架构是通过mycat做的主从读写分析,一主一从.在业务上有实时修改配置的需求,发现改了配置之后不生效,但是过一会就好了.就怀疑是主从有延迟. 我这里m ...
redis mysql主从延迟_MySQL主从延迟问题解决
今天我们就来看看为什么会产生主从延迟以及主从延迟如何处理等相关问题. 坐好了,准备发车! 主从常见架构随着日益增长的访问量,单台数据库的应接能力已经捉襟见肘.因此采用主库写数据,从库读数据这种将读写 ...
【运维面试】面试官：mysql主从延迟是怎么处理的
前言运维关于mysql的面试题,最常见的就是mysql主从同步,对于主从同步这一块稍微深入一点的就是mysql主从延迟怎么产生的,怎么解决的. 现阶段的互联网公司,一般都是读多写少,一个主库配几个从 ...
php mysql主从延迟_如何解决主从数据库同步延迟问题？php连接 mysql 数据库如何添加一个公共的配置文件50...
在上一篇文章中,小编为您详细介绍了关于<图上属标注的什么样元器件?火车购票明明显示无座为什么样乘车后却发现有很多空座>相关知识.本篇中小编将再为您讲解标题如何解决主从数据库同步延迟问题?p ...
mysql主从延迟_MySQL主从同步个般是多久的延迟？
这次单独调查一下主从延迟的时间.这里说的主从延迟,并不是指"从库更新性能跟不上主库", 而是"一个命令从主库更新完成到从库更新完成的延迟时间. 基本流程: 对于每一个连上 ...
如何判断mysql主从延迟_【转】MySQL主从延迟如何解决
一. 如何检测主从延迟html 能够经过监控 show slave status\G 命令输出的Seconds_Behind_Master 参数值来判断,是否存在主从延时. NULLmysql 表示i ...
26 | MySQL主从延迟分析以及HA保障（柯南版的中篇）
〇.前言下面的笔记都是一主一备,或者叫一主一从. 一.前置背景上一篇中讲到主从延迟场景对于从库的影响一般是分钟级别的,备库恢复之后都可以追上来,但是第四点如果备库执行日志的速度低于主库生成日志的速 ...
京东二面：MySQL 主从延迟、读写分离 7 种解决方案！
我们都知道互联网数据有个特性,大部分场景都是读多写少,比如:微博.微信.淘宝电商,按照二八原则,读流量占比甚至能达到 90% 结合这个特性,我们对底层的数据库架构也会做相应调整.采用读写分离处 ...
zabbix mysql主从延迟_zabbix监控mysql主从同步和延迟
一.环境需求主机A: zabbix-server 主机B: zabbix-agent/mysql从二.主机B操作 1.添加监控脚本 vim /data/zabbix/mysql_slave_che ...

mysql 主从延迟及对应解决方案

mysql 主从延迟及对应解决方案相关推荐

最新文章

热门文章