[MySQL Delay]生产环节主从延迟的问题解决过程记录: sync_binlog=0
2014-01-20 06:18
330 查看
接到山姆大叔的电话,主从延迟半个小时了
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的问题。
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的问题。
相关文章推荐
- [MySQL Delay]生产环节主从延迟的问题解决过程记录: sync_binlog=0
- 记录一奇葩scp问题的分析与解决过程
- 【hadoop2.2(yarn)】基于yarn成功执行分布式map-reduce,记录问题解决过程。
- 实验过程中遇到的mysql DateTime类型与java Calendar问题与解决过程记录
- SweetAlert2 使用过程中弹框报错问题记录与解决
- 记录一奇葩scp问题的分析与解决过程
- 关于解决 MySQL 数据库主从复制延迟的问题
- MySQL生产库Insert了2次同样的记录但是主键ID是不一样的问题的分析过程
- DRML(2016-CVPR)重现过程记录---(9)问题解决与最终结果
- 如何解决主从数据库同步延迟问题?
- struts2改spring boot过程中一些问题及解决办法记录
- 怎样解决MySQL数据库主从复制延迟的问题
- 使用存储过程中的虚拟表解决同时从几个数据库服务器中读取记录的问题
- 记录一次bug解决过程:eclipse Installed JREs 配置引出的问题
- 调试过程中尚未研究的问题,先记录下,以后解决
- 怎样解决MySQL数据库主从复制延迟的问题
- 【Linux】无法添加用户,报“useradd: cannot open /etc/passwd”问题解决过程记录
- 记录sqoop同步失败问题解决过程,过程真的是很崎岖。(1月6日解决)