MySQL中slave监控的延迟情况分析

在MySQL复制环境中,我们通常只根据 Seconds_Behind_Master 的值来判断SLAVE的延迟。这么做大部分情况下尚可接受,但并不够准确,而应该考虑更多因素。

首先,我们先看下SLAVE的状态:

代码如下:

yejr@imysql.com [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
***
Master_Log_File: mysql-bin.000327
Read_Master_Log_Pos: 668711237
Relay_Log_File: mysql-relay-bin.002999
Relay_Log_Pos: 214736858
Relay_Master_Log_File: mysql-bin.000327
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
***
Skip_Counter: 0
Exec_Master_Log_Pos: 654409041
Relay_Log_Space: 229039311
***
Seconds_Behind_Master: 3296
***

可以看到 Seconds_Behind_Master 的值是 3296,也就是SLAVE至少延迟了 3296 秒。

我们再来看下SLAVE上的2个REPLICATION进程状态:

代码如下:

yejr@imysql.com [(none)]> show full processlist\G
*************************** 1. row ***************************
Id: 6
User: system user
Host:
db: NULL
Command: Connect
Time: 22005006
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 7
User: system user
Host:
db: NULL
Command: Connect
Time: 3293
State: Updating
Info: UPDATE ** SET ** WHERE **

可以看到SQL线程一直在执行UPDATE操作,注意到 Time 的值是 3293,看起来像是这个UPDATE操作执行了3293秒,一个普通的SQL而已,肯定不至于需要这么久。
实际上,在REPLICATION进程中,Time 这列的值可能有几种情况:
1、SQL线程当前执行的binlog(实际上是relay log)中的timestamp和IO线程最新的timestamp的差值,这就是通常大家认为的 Seconds_Behind_Master 值,并不是某个SQL的实际执行耗时;
2、SQL线程当前如果没有活跃SQL在执行的话,Time值就是SQL线程的idle time;

而IO线程的Time值则是该线程自从启动以来的总时长(多少秒),如果系统时间在IO线程启动后发生修改的话,可能会导致该Time值异常,比如变成负数,或者非常大。

来看下面几个状态:

#设置pager,只查看关注的几个status值
yejr@imysql.com [(none)]> pager cat | egrep -i 'system user|Exec_Master_Log_Pos|Seconds_Behind_Master|Read_Master_Log_Pos'

#这是没有活跃SQL的情况,Time值是idle time,并且 Seconds_Behind_Master 为 0
yejr@imysql.com [(none)]> show processlist; show slave status\G
| 6 | system user | | NULL | Connect | 22004245 | Waiting for master to send event | NULL |
| 7 | system user | | NULL | Connect | 13 | Has read all relay log;**
Read_Master_Log_Pos: 445167889
Exec_Master_Log_Pos: 445167889
Seconds_Behind_Master: 0

#和上面一样
yejr@imysql.com [(none)]> show processlist; show slave status\G
| 6 | system user | | NULL | Connect | 22004248 | Waiting for master to send event | NULL |
| 7 | system user | | NULL | Connect | 16 | Has read all relay log;**
Read_Master_Log_Pos: 445167889
Exec_Master_Log_Pos: 445167889
Seconds_Behind_Master: 0

#这时有活跃SQL了,Time值是和 Seconds_Behind_Master 一样,即SQL线程比IO线程“慢”了1秒
yejr@imysql.com [(none)]> show processlist; show slave status\G
| 6 | system user | | NULL | Connect | 22004252 | Waiting for master to send event | NULL |
| 7 | system user | | floweradmin | Connect | 1 | Updating | update **
Read_Master_Log_Pos: 445182239
Exec_Master_Log_Pos: 445175263
Seconds_Behind_Master: 1

#和上面一样
yejr@imysql.com [(none)]> show processlist; show slave status\G
| 6 | system user | | NULL | Connect | 22004254 | Waiting for master to send event | NULL |
| 7 | system user | | floweradmin | Connect | 1 | Updating | update **
Read_Master_Log_Pos: 445207174
Exec_Master_Log_Pos: 445196837
Seconds_Behind_Master: 1

好了,最后我们说下如何正确判断SLAVE的延迟情况:
1、首先看 Relay_Master_Log_File 和 Master_Log_File 是否有差异;
2、如果Relay_Master_Log_File 和 Master_Log_File 是一样的话,再来看Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差异,对比SQL线程比IO线程慢了多少个binlog事件;
3、如果Relay_Master_Log_File 和 Master_Log_File 不一样,那说明延迟可能较大,需要从MASTER上取得binlog status,判断当前的binlog和MASTER上的差距;

因此,相对更加严谨的做法是:
在第三方监控节点上,对MASTER和SLAVE同时发起SHOW BINARY LOGS和SHOW SLAVE STATUS\G的请求,最后判断二者binlog的差异,以及 Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差异。

例如:
在MASTER上执行SHOW BINARY LOGS 的结果是:

+------------------+--------------+
| Log_name | File_size |
+------------------+--------------+
| mysql-bin.000009 | 1073742063 |
| mysql-bin.000010 | 107374193 |
+------------------+--------------+

而在SLAVE上执行SHOW SLAVE STATUS\G 的结果是:

Master_Log_File: mysql-bin.000009
 Read_Master_Log_Pos: 668711237
Relay_Master_Log_File: mysql-bin.000009
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
***
Exec_Master_Log_Pos: 654409041

***
Seconds_Behind_Master: 3296
***

这时候,SLAVE实际的延迟应该是:
mysql-bin.000009 这个binlog中的binlog position 1073742063 和 SLAVE上读取到的binlog position之间的差异延迟,即:

1073742063 - 654409041 = 419333022 个binlog event

并且还要加上 mysql-bin.000010这个binlog已经产生的107374193个binlog event,共

107374193 + 419333022 = 526707215 个binlog event

时间: 2015-05-06

mysql5.5 master-slave(Replication)配置方法

一主一从: Master: OS:centos release 5.6 DB:mysql 5.5.8 IP:192.168.1.2 Slave: OS:centos release 5.6 DB:mysql 5.5.8 IP:192.168.1.3 修改主机Master配置文件 (/etc/my.cnf) 复制代码 代码如下: [mysqld] //至少要有server-id.与log-bin两项 server-id=1 log-bin=/var/lib/mysql/mysql-bin data

MYSQL同步 Slave_IO_Running: No 或者Slave_SQL_Running: No的解决方法[已测]

今天在测试mysql是否同步时,检查数据库发现一台MySQL Slave未和主机同步,查看Slave状态: mysql> show slave status\G Slave_IO_Running: Yes Slave_SQL_Running: No Last_Errno: 1062 .... Seconds_Behind_Master:NULL 原因: 1.程序可能在slave上进行了写操作 2.也可能是slave机器重起后,事务回滚造成的. 解决办法I: 1.首先停掉Slave服务:slave

mysql(master/slave)主从复制原理及配置图文详解

1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置.从服务器接收

解决MySQL中的Slave延迟问题的基本教程

一.原因分析 一般而言,slave相对master延迟较大,其根本原因就是slave上的复制线程没办法真正做到并发.简单说,在master上是并发模式(以InnoDB引擎为主)完成事务提交的,而在slave上,复制线程只有一个sql thread用于binlog的apply,所以难怪slave在高并发时会远落后master. ORACLE MySQL 5.6版本开始支持多线程复制,配置选项 slave_parallel_workers 即可实现在slave上多线程并发复制.不过,它只能支持一个实

MYSQL5 masterslave数据同步配置方法第1/3页

测试环境.基本上数据是瞬间同步,希望对大家有帮助 RedHat ES 3 update 3 MYSQL 5.0.15 MYSQL数据同步备份 A服务器: 192.168.1.2 主服务器master B服务器: 192.168.1.3 副服务器slave A服务器设置 #mysql –u root –p mysql>GRANT FILE ON *.* TO backup@192.168.1.3 IDENTIFIED BY '1234'; mysql>exit 上面是Master开放一个账号ba

mysql5.5 master-slave(Replication)主从配置

一主一从: Master: OS:centos release 5.6 DB:mysql 5.5.8 IP:192.168.1.2 Slave: OS:centos release 5.6 DB:mysql 5.5.8 IP:192.168.1.3 修改主机Master配置文件 (/etc/my.cnf) 复制代码 代码如下: [mysqld] //至少要有server-id.与log-bin两项 server-id=1 log-bin=/var/lib/mysql/mysql-bin data

mysql同步问题之Slave延迟很大优化方法

一般而言,slave相对master延迟较大,其根本原因就是slave上的复制线程没办法真正做到并发.简单说,在master上是并发模式(以InnoDB引擎为主)完成事务提交的,而在slave上,复制线程只有一个sql thread用于binlog的apply,所以难怪slave在高并发时会远落后master. ORACLE MySQL 5.6版本开始支持多线程复制,配置选项 slave_parallel_workers 即可实现在slave上多线程并发复制.不过,它只能支持一个实例下多个 da

Mysql主从复制(master-slave)实际操作案例

在这一章节里, 我们来了解下如何在 Mysql 中进行用户授权及主从复制   这里先来了解下 Mysql 主从复制的优点:   1. 如果主服务器出现问题, 可以快速切换到从服务器提供的服务 2. 可以在从服务器上执行查询操作, 降低主服务器的访问压力 3. 可以在从服务器上执行备份, 以避免备份期间影响主服务器的服务 注意一般只有更新不频繁的数据或者对实时性要求不高的数据可以通过从服务器查询, 实时性要求高的数据仍然需要从主数据库获得   在这里我们首先得完成用户授权, 目的是为了给从服务器有

解读mysql主从配置及其原理分析(Master-Slave)

1.在主数据库服务器为从服务器添加一个拥有权限访问主库的用户:GRANT REPLICATION SLAVE ON *.* TO ' test'@'%' IDENTIFIED BY 'test'; (%表示允许所有IP,可设置指定从服务器IP)添加用户后:可在从服务器上用mysql -h127.0.0.1 -utest -ptest;  来测试是否有权限访问主数据库 2.在主据库配置文件加上:#master configserver-id       = 1log-bin          =

基于MySQL Master Slave同步配置的操作详解

环境:PC:ubuntu 10.10  192.168.1.112(master) 192.168.10.245(slave) MySQL : 5.1.49-1ubuntu8.1-log在master中已经存在数据库test 首先修改mysql配置文件:/etc/mysql/my.cnf[master]#author:zhxia 复制代码 代码如下: #master 同步设置 server-id               = 1 log_bin                 = /var/l

mysql 数据同步 出现Slave_IO_Running:No问题的解决方法小结

下面写一下,这两个要是有no了,怎么恢复.. 如果是slave_io_running no了,那么就我个人看有三种情况,一个是网络有问题,连接不上,像有一次我用虚拟机搭建replication,使用了nat的网络结构,就是死都连不上,第二个是有可能my.cnf有问题,配置文件怎么写就不说了,网上太多了,最后一个是授权的问题,replication slave和file权限是必须的.如果不怕死就all咯.. 一旦io为no了先看err日志,看看爆什么错,很可能是网络,也有可能是包太大收不了,这个时

MYSQL数据表损坏的原因分析和修复方法小结(推荐)

1.表损坏的原因分析 以下原因是导致mysql 表毁坏的常见原因: 1. 服务器突然断电导致数据文件损坏. 2. 强制关机,没有先关闭mysql 服务. 3. mysqld 进程在写表时被杀掉. 4. 使用myisamchk 的同时,mysqld 也在操作表. 5. 磁盘故障. 6. 服务器死机. 7. mysql 本身的bug . 2.表损坏的症状 一个损坏的表的典型症状如下: 1 .当在从表中选择数据之时,你得到如下错误: Incorrect key file for table: '...

安装MySQL 5后无法启动(不能Start service)解决方法小结

安装的 MySQL 5.1.48 或是 MySQL 5.5.8,配置好最后点击 Execute 按钮了,但是进行不到 Start service 这一步.检查了下 MySQL 系统服务已添加,但是无法启动,手工也不行.这时候用事件查看器可以看到程序事件里有几个来自于 MySQL 的错误: Plugin 'InnoDB' registration as a STORAGE ENGINE failed. Unknown/unsupported table type: INNODB 原来是因为这两版本

怎么使 Mysql 数据同步

怎么使 Mysql 数据同步 先假设有主机 A 和 B ( Linux 系统),主机 A 的 IP 分别是 1.2.3.4 (当然,也可以是动态的),主机 B 的 IP 是 5.6.7.8 .两个主机都装上了 PHP+Mysql ,现在操作的是主机 A 上的资料,如果另外一个主机 B 想跟 A 的资料进行同步,应该怎么做呢? OK,我们现在就动手. 首先,如果要想两个主机间的资料同步,一种方法就是主机 A 往主机 B 送资料,另外一种主法就是主机 B 到主机 A 上拿资料,因为 A 的 IP 是

用python简单实现mysql数据同步到ElasticSearch的教程

之前博客有用logstash-input-jdbc同步mysql数据到ElasticSearch,但是由于同步时间最少是一分钟一次,无法满足线上业务,所以只能自己实现一个,但是时间比较紧,所以简单实现一个 思路: 网上有很多思路用什么mysql的binlog功能什么的,但是我对mysql了解实在有限,所以用一个很呆板的办法查询mysql得到数据,再插入es,因为数据量不大,而且10秒间隔同步一次,效率还可以,为了避免服务器之间的时间差和mysql更新和查询产生的时间差,所以在查询更新时间条件时是

MySQL无法创建外键的原因及解决方法

关联2张表时出现了无法创建外键的情况,从这个博客看到,问题出在第六点的Charset和Collate选项在表级和字段级上的一致性上.我的2张表的编码charset和collate不一致,2张表都执行执行SQL语句: alter table 表名 convert to character set utf8; 完美解决问题: ps:下面看下MySQL无法创建外键.查询外键的属性 MyISAM 和InnoDB 讲解 InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型,这两个表类型各

MySQL 出现错误1418 的原因分析及解决方法

MySQL 出现错误1418 的原因分析及解决方法 具体错误: 使用mysql创建.调用存储过程,函数以及触发器的时候会有错误符号为1418错误. ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL,or READS SQL DATA in its declaration and binary logging is enabled(you *might* want to use the less safe log

Oracle客户端与plsql查询数据乱码修改成中文的快速解决方法

1.查询ORACLE服务器的语言.地域和字符集 select * from nls_database_paameters; 查询结果如下图, NLS_LANGUAGE 表示"语言",NLS_TERRITORY 表示"地域",NLS_CHARACTSET 表示"字符集",将他们三个按照"语言_地域.字符集"的格式拼接起来,就有了"AMERICAN_AMERICA.ZHS16GBK". 下面正式的来操作: 2.

MySql中表单输入数据出现中文乱码的解决方法

 MySQL会出现中文乱码的原因在于 1.server本身设定问题,一般来说是latin1 2.建库建表时没有制定编码格式. MySql中表单输入数据出现中文乱码的解决方法: 1.建库的时候 CREATE DATABASE test CHARACTER SET 'utf8' COLLATE 'utf8_general_ci'; 2.建表的时候 CREATE TABLE content ( text VARCHAR(100) ) ENGINE=InnoDB DEFAULT CHARSET=utf8

jQuery通过ajax方法获取json数据不执行success的原因及解决方法

1.jquery通过ajax方法获取json数据不执行success回调 问题描述:jquery通过ajax方法获取json数据不执行success回调方法 问题原因:json格式存在问题或不符合标准写法,导致总是执行error回调方法 解决方案:使json格式务必符合下述3个标准写法: 1)键名称:用双引号括起: 2)字符串:用双引号括起: 3)数字,布尔值不需要使用双引号括起 : 注意:一定是双括号! 2.jQuery中ajax使用json数据类型总是跳过success执行error语句 执