Home > Database > Mysql Tutorial > body text

[MySQLDelay]生产环节主从延迟的问题解决过程记录:sync_binlog=

WBOY
Release: 2016-06-07 15:28:23
Original
1375 people have browsed it

接到山姆大叔的电话,主从延迟半个小时了 Seconds_Behind_Master: 7600 1, 检查show full processlist; 没有任何slow的dml sql语句。 2, 检查innodb status,没有任何lock的块。 3, 检查cacti,里面cpu usage从4%上升到了15%,Percona InnoDB I/O GT 从90

接到山姆大叔的电话,主从延迟半个小时了

Seconds_Behind_Master: 7600

1, 检查show full processlist; 没有任何slow的dml sql语句。

2, 检查innodb status,没有任何lock的块。

3, 检查cacti,里面cpu usage从4%上升到了15%,Percona InnoDB I/O GT 从90%降低到了50%%。

4, 检查当前connections,发现处于业务低峰期。

5, 尝试我重启了下mysql server,结果Seconds_Behind_Master还是不停的增长。

6,最后去检查写入参数看下:

mysql> show variables like '%commit%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| autocommit | ON |
| innodb_commit_concurrency | 0 |
| innodb_flush_log_at_trx_commit | 0 |
+--------------------------------+-------+
3 rows in set (0.00 sec)

commit为0,已经算是最快的了。

再看binlog

mysql> show variables like 'sync_binlog';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 2 |
+---------------+-------+
1 row in set (0.00 sec)

那么改成0试试看吧。

set global sync_binlog=0;

执行完后,从Seconds_Behind_Master: 9200变成了Seconds_Behind_Master: 8791,开始追了。

又过了3分钟,已经是Seconds_Behind_Master: 0了。

虽然问题解决了,但是主要问题不在sysn_binlog,估计是磁盘有问题了,不然不可能在晚上业务低峰期,会主从delay的。平常白天业务高峰期都没有主从delay过,把疑惑发给山姆大叔,让他去找system administrator吧,去check下disk的问题。

Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template