MySQL主从复制延迟的监测及缓解

标签: mysql 复制 延迟 | 发表时间:2016-05-07 12:12 | 作者:fireinwind
出处:http://www.iteye.com
 

MySQL的主从复制有多种原因可以导致延迟,这个是公认的了,下面我们谈谈怎样监测复制的延迟,以及怎样尽量的解决延迟的问题。

 

延迟的监测

Seconds_behind_master

在SLAVE上执行SHOW SLAVE STATUS,监控Seconds_behind_master列值,备库Seconds_Behind_Master值是通过将服务器当前的时间戳(这里其实有个主从服务器时间差的问题,但是实际上主从在连接上后会做一次主从时间差的对比并记录该偏移量)与二进制日志中的事件时间戳相对比得到的,如果在I/O线程没有延时的情况下,这个还是准的。

 

Master_Log_Pos

如果I/O有延迟,那么Seconds_behind_master列值就不准确了,这时应该在主库上SHOW MASTER STATUS,记录LogFile和Log Position值,然后再在从库上SHOW SLAVE STATUS,查看Read_Master_Log_Pos和Exec_Master_Log_Pos,看看BinLog在主从上各自的位置,可以知道是否延迟。

 

利用pt-heartbeat或mk-heartbeat监控工具

该工具可以计算出MySQL复制,它可以更新master或者监控复制,还可以从my.cnf 读取配置。它借助timestmp的比较实现的,首先需要保证主从服务器时间必须要保持一致,通过与相同的一个NTP server同步时钟。它需要在主库上创建一个heartbeat的表,里面的时间戳ts就是当前的时间戳 now(),该结构也会被复制到从库上。表建好以后,会在主库上以后台进程的模式去执行一行更新操作的命令,定期去向表中的插入数据,这 个周期默认为1 秒,同时从库也会在后台执行一个监控命令,与主库保持一致的周期+0.5S(默认0.5S延迟检查)去比较,复制过来记录的ts值与主库上的同一条ts值,差值为0表示无延时,差值越大表示 延时的秒数越多。

 

利用pt-table-checksum确定主备是否一致

复制延时或网络问题并总是会让主备数据不完全一致。主备一致应该是一种规范,而不是例外,也就是说,检查你的主备一致性应该是一个日常工作,特别是是当使用备库来做备份时尤为重要。pt-table-checksum能够用于确认主备库数据是否一致。

 

延迟的缓解(只能是缓解而无法彻底解决)

最简单的办法是配置InnoDB

使其不要那么频繁地刷新磁盘,这样事务提交的更快些。设置innodb_flush_log_at_trx_commit=2来实现。还可以在备库上禁止二进制日志记录,把innodb_locks_unsafe_for_binlog设置为1,并把MyISAM的delay_key_write设置为ALL。但是这些设置以牺牲安全换取速度。如果需要将备库提升为主库,记得把这些选项设置回安全值。

 

不要重要写操作中代价较高的部分

重构应用程序或者优化查询通常是最好的保持备库同步的办法。如果可以把工作转移备库,那么就只有一台备库需要执行,然后我们可以把写的结果回传到主库,例如,通过执行LOAD DATA INFILE。

  

限制主库过大的包

修改主库max_allowed_packet值,太大的包会使二进制事务变的复杂。

 

利用MySQL5.5以上的半同步

事实上半同步复制在某些场景下确实能够提供足够的灵活性以改善性能,在主库关闭sync_binlog的情况下保证更加安全。写入远程的内存(一台备库反馈)比写入本地的磁盘(写入并刷新)要更快。有人进行过测试,使用半同步复制相比在主库上进行强持久化的性能有两倍改善。在任何系统上都没有绝对的持久化,只有更高的持久化层次,并且看起来半同步复制应该是一种比其他替代方案开销更小的系统数据持久化方法。

 

在复制之外并行写入

所有写操作都应该从主库传递到备库?如果能确定一些写入可以轻易地在复制之外执行,就可以并行化这些操作以利用备库的写入容量。例如,一些归档数据,可以在主备上分别进行归档操作。

 

为复制线程预取缓存

通过程序实现,在SQL线程更新前提前读取中继日志并将其转化为SELECT语句执行。这会使服务器将数据从磁盘加载到内存中,这样SQL线程执行到相应语句时,就无需从磁盘读取数据。

这个办法目前已经有一种工具叫relayfetch,这个主意的想法是通过程序,让他比从服务器的sql线程稍微提前一点在中继日志中读取到查询语句,并将其作为select语句来执行,这导致服务器把一些数据从磁盘读取到内存,因此当从服务器的sql线程从中继日志中执行命令的时候,它就不需要等待从磁盘读取数据。Select并行处理从服务器必须串行处理的I/O。后面会有单独的对这个工作的介绍和使用。

 

多线程同步

这个办法目前也已经有一种工具叫MySQL-Transefer(下称Transfer),是一个基于MySQL+patch后得到的主从同步工具。该工具的原理是以多线程的方式来读取relaylog更新SlAVE的方式。后面会有单独的对这个工作的介绍和使用。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [mysql 复制 延迟] 推荐:

[MySQL FAQ]系列 — MySQL复制中slave延迟监控

- - MySQL中文网
在MySQL复制环境中,我们通常只根据 Seconds_Behind_Master 的值来判断SLAVE的延迟. 这么做大部分情况下尚可接受,但并不够准确,而应该考虑更多因素. 首先,我们先看下SLAVE的状态:. 可以看到 Seconds_Behind_Master 的值是 3296,也就是SLAVE至少延迟了 3296 秒.

MySQL主从复制延迟的监测及缓解

- - 数据库 - ITeye博客
MySQL的主从复制有多种原因可以导致延迟,这个是公认的了,下面我们谈谈怎样监测复制的延迟,以及怎样尽量的解决延迟的问题. 在SLAVE上执行SHOW SLAVE STATUS,监控Seconds_behind_master列值,备库Seconds_Behind_Master值是通过将服务器当前的时间戳(这里其实有个主从服务器时间差的问题,但是实际上主从在连接上后会做一次主从时间差的对比并记录该偏移量)与二进制日志中的事件时间戳相对比得到的,如果在I/O线程没有延时的情况下,这个还是准的.

意想不到的 MySQL 复制延迟原因

- - IT瘾-dev
线上有个MySQL实例,存在严重的复制延迟问题,原因出乎意料. 线上有个MySQL 5.7版本的实例,从服务器延迟了3万多秒,而且延迟看起来好像还在加剧. 我们看到, binlog文件落后了64个,相当的夸张. MySQL 5.7不是已经实现并行复制了吗,怎么还会延迟这么厉害. 看到 mysqld进程其实负载还好,不算太高,也不存在严重的SWAP等问题.

记一次 MySQL 主从复制延迟的踩坑

- - 文章 – 伯乐在线
最近开发中遇到的一个 MySQL 主从延迟的坑,记录并总结,避免再次犯同样的错误. 一个活动信息需要审批,审批之后才能生效. 因为之后活动要编辑,编辑后也可能触发审批,审批中展示的是编辑前的活动内容,考虑到字段比较多,也要保存审批活动的内容,因此设计采用了一张临时表,审批中的活动写进审批表(activity_tmp),审批通过之后才把真正的活动内容写进活动表(activity).

mysql主从复制

- - SQL - 编程语言 - ITeye博客
从库的配置,mysql5.5不支持配置文件的配置了,问了数据库的人,用命令行指定. 修改从库的配置 #default-storage-engine = InnoDB #修改 default-storage-engine = blackhole server-id = 11215004 #新增 replicate-do-db = test log-bin = mysql-bin #新增 binlog_format = row.

relay fetch 解决mysql replication 主从延迟

- - CSDN博客推荐文章
      mysql replication 中主从延迟是一个比较常见的问题,请看前期一篇博文: 怎样解决MySQL数据库主从复制延迟的问题. 根据目前有些公司使用的方案,最近测试了两个,其中之一是阿里的relay fetch ,业绩说法数据预热,当然也有其他开源类似开源工具,目前诸如 mk-slave-prefetch及 replication-prefetch等,感兴趣可以去看看.

MySQL主从复制配置

- - 天空极速
在实际企业应用环境当中,单台MySQL数据库是不足以满足日后业务需求的. 譬如服务器发生故障,没有备份服务器来提供服务的话,业务就得停止. 使用MySQL主从复制的好处有:. 1、采用主从服务器这种架构,稳定性得以提升. 如果主服务器发生故障,我们可以使用从服务器来提供服务;. 2、在主从服务器上分开处理用户的请求,可以提升数据处理效率;.

MySQL 主从延迟监控脚本(pt-heartbeat)

- - CSDN博客数据库推荐文章
    对于MySQL数据库主从复制延迟的监控,我们可以借助percona的有力武器pt-heartbeat来实现. pt-heartbeat通过使用时间戳方式在主库上更新特定表,然后在从库上读取被更新的时间戳然后与本地系统时间对比来得出其延迟. 本文主要是通过脚本来定期检查从库与主库复制的延迟度并发送邮件,供大家参考.

[MySQL优化案例]系列 — slave延迟很大优化方法

- - MySQL中文网
备注:插图来自网络搜索,如果觉得不当还请及时告知 :). 一般而言,slave相对master延迟较大,其根本原因就是slave上的复制线程没办法真正做到并发. 简单说,在master上是并发模式(以InnoDB引擎为主)完成事务提交的,而在slave上,复制线程只有一个sql thread用于binlog的apply,所以难怪slave在高并发时会远落后master.