MySQL 主从延迟几万秒 Queueing master event to the relay log(转)

数据库版本
Server version:    5.6.24-log Source distribution

问题描述

数据采集平台业务数据库由于批量灌数据导致主从延迟上万秒。

复制线程长期处于Queueing master event to the relay log状态。

监控数据显示
1.Seconds_Behind_Master 维持在6w秒左右,且有上升趋势。
2.主库有大量的binlog积压无法同步到从库,但主从库的网卡流量都很低远未达到瓶颈。
3.从库的qps与tps很低,维持在几百左右。
4.cpu 负载不高,但iowait维持在 12%左右
5.iostat -xmd 2 发现util维持在99%

问题分析
1.从监控数据分析貌似磁盘IO瓶颈,首先尝试用fileio,dd等工具测试,发现磁盘io确实很差。
考虑在从库禁用双1参数后(sync_binlog,innodb_flush_log_at_trx_commit)主从延迟时未见明显下降.
 
2.从其它主机拷大量拷贝小文件未发现网络传输问题
 
3.关闭并行复制
MySQL5.6版本中开启了库级别的并行复制,但show processlist发现从库大部分并行复制同步线程都处于空闲状态。
关闭并行复制后,主从延迟时间仍未得到缓解
stop slave sql_thread;set global slave_parallel_workers=0;start slave sql_thread;

4.解析binlog 未发现SQL执行效率低,无主键等问题

5.检查MySQL参数配置,问题浮出水面。

mysql> show variables where variable_name in(‘slave_parallel_workers‘,‘read_only‘, ‘master_info_repository‘,‘relay_log_info_repository‘,‘slave_net_timeout‘,‘log_slave_updates‘, ‘slave_compressed_protocol‘,‘sync_master_info‘,‘sync_relay_log‘,‘sync_relay_log_info‘,‘relay_log_purge‘);
    +---------------------------+-------+
    | Variable_name             | Value |
    +---------------------------+-------+
    | log_slave_updates         | ON    |
    | master_info_repository    | FILE  |
    | read_only                 | OFF   |
    | relay_log_info_repository | FILE  |
    | relay_log_purge           | OFF   |
    | slave_compressed_protocol | ON    |
    | slave_net_timeout         | 10    |
    | slave_parallel_workers    | 6     |
    | sync_master_info          | 1     |
    | sync_relay_log            | 10000 |
    | sync_relay_log_info       | 10000 |
    +---------------------------+-------+

检查发现:master_info_repository设置为FILE,同时sync_master_info设置为1。
这两个参数组合起来的意思就是slave要同步每一个sync_master_info events 到 master.info文件中。由于磁盘的性能问题,导致fdatasync()的效率比较低, 所以引起复制延迟。

解决办法

把master_info_repository设置为table后,主从延迟直线下降。
stop slave;set global relay_log_info_repository=table;set global master_info_repository=table;start slave;

官方文档中对master_info_repository参数的说明

https://dev.mysql.com/doc/refman/5.6/en/replication-options-slave.html#sysvar_sync_master_info
master_info_repository = FILE.  If the value of sync_master_info is greater than 0, the slave synchronizes its master.info file to disk (using fdatasync()) after every sync_master_info events. If it is 0, the MySQL server performs no synchronization of the master.info file to disk; instead, the server relies on the operating system to flush its contents periodically as with any other file.
master_info_repository = TABLE.  If the value of sync_master_info is greater than 0, the slave updates its master info repository table after every sync_master_info events. If it is 0, the table is never updated.

---------------------
作者:lwei_998
来源:CSDN
原文:https://blog.csdn.net/lwei_998/article/details/80068498
版权声明:本文为博主原创文章,转载请附上博文链接!

原文地址:https://www.cnblogs.com/zping/p/10861902.html

时间: 2024-10-12 01:03:01

MySQL 主从延迟几万秒 Queueing master event to the relay log(转)的相关文章

MySQL 主从延迟复制方法总结

mysql 5.6开始已经支持主从延迟复制,可设置从库延迟的时间.延迟复制的意义在于:主库误删除对象时,在从库可以查询对象没改变前状态. 方法介绍 1.percona公司pt-slave-delay工具 主库: [[email protected] ~]$ login Logging to file '/tmp/master.log' Warning: Using a password on the command line interface can be insecure. Welcome

MySQL主从延迟复制实践及生产故障案例恢复实践

1.1 MySQL主从延迟复制介绍 从MySQL5.6开始支持了主从延迟复制,这个功能主要解决的问题是,当主库有逻辑的数据删除或错误更新后,所有的从库都会进行错误的更新,从而导致所有的数据库数据异常,即使有定时的备份数据可以用于数据恢复,特别是数据库数据量很大时,恢复时间会很长,再恢复期间数据库数据被删或错误数据影响正常的访问体验. 而延迟复制就可以较好的解决这个问题.例如,可以设定某一个从库和主库的更新延迟1小时,这样主库数据出问题以后,1个小时以内发现,可以对这个从库进行无害恢复处理,使之依

实时刷新缓存-处理mysql主从延迟的一些设计方案

概要: 在项目开发当中,经常有这样一种场景,对数据库进行添加.修改.删除操作的应用直接连接master库,只对数据库进行查询的应用,会先建立一个中央缓 存,例如redis或者memcache,如果缓存没有命中,那么直接访问slave库.下文会介绍一下在刷新中央缓存时,如果发生主从延迟,应该如何处 理.也即是,当应用System-A 把数据库写入master库的时候,System-B应用在读取slave库的时候,master库的数据还没同步到slave库,如果这个时候刷新缓存 的话,会直接把旧的数

mysql 主从 Got fatal error 1236 from master when reading data from binary log: 'Could not find first 错误

本地MySQL环境,是两台MySQL做M-M复制.今天发现错误信息: mysql 5.5.28-log> show slave status\G *************************** 1. row ***************************                Slave_IO_State:                   Master_Host: 88.88.88.88                   Master_User: replicate

mysql主从延迟设置

Mysql (需5.6以上版本)延迟复制配置,通过设置Slave上的MASTER TO MASTER_DELAY参数实现: CHANGE MASTER TO MASTER_DELAY = N: N为多少秒,该语句设置从数据库延时N秒后,再与主数据库进行数据同步复制 具体操作: 登陆到Slave数据库服务器 mysql>stop slave; mysql>CHANGE MASTER TO MASTER_DELAY = 600: mysql>start slave; mysql>sho

MySQL主从延迟现象及原理分析详解

一.现象 凌晨对线上一张表添加索引,表数据量太大(1亿+数据,数据量50G以上),造成主从延迟几个小时,各个依赖从库的系统无法查询数据,最终影响业务. 现在就梳理下主从延迟的原理. 二.原理 根据 MySQL 官方文档 MySQL Replication Implementation Details 中的描述,MySQL 主从复制依赖于三个线程:一个线程(),两个线程(和).主从复制流程如下图: master 服务器和 slave 服务器连接时,创建以发送数据: 一个对应一个 slave 服务器

MySQL主从延迟原因以及解决方案

1.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 主从延迟监控脚本(pt-heartbeat)

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

MySQL主从同步机制与同步延时问题追查过程

前言 作为一名DBA,在工作中会经常遇到一些MySQL主从同步延迟的问题,这些同步慢的问题,其实原因非常多,可能是因为主从的网络问题导致,可能是因为网络带宽问题导致,可能是因为大事务导致,也可能是因为单线程复制导致的延迟. 今天遇到一个问题,Mysql持续报错,主从同步延时数过大或错误.所以这篇文章给大家分享下主从同步的机制原理以及问题排查思路. 故障表现 最直观的表现为: ? 1 2 3 4 5 6 7 mysql> show slave status\G;  // 状态一  Seconds_