ホームページ > データベース > mysql チュートリアル > [MySQLDelay]生产环节主从延迟的问题解决过程记录:sync_binlog=

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

WBOY
リリース: 2016-06-07 15:28:23
オリジナル
1383 人が閲覧しました

接到山姆大叔的电话,主从延迟半个小时了 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的问题。

関連ラベル:
ソース:php.cn
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート