- 积分
- 16840
在线时间 小时
最后登录1970-1-1
|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?开始注册
x
Seconds_Behind_Master: 7600
5 y( e! b% W3 z) Y1 V; o5 k/ ~4 p/ D: b
1, 检查show full processlist; 没有任何slow的dml sql语句。; K0 P4 `/ B/ ^* G9 v
2, 检查innodb status,没有任何lock的块。* {' s! u8 W! U K3 L M
3, 检查cacti,里面cpu usage从4%上升到了15%,Percona InnoDB I/O GT 从90%降低到了50%%。3 D7 k, T; u, T7 w4 M+ E% F1 z" c
4, 检查当前connections,发现处于业务低峰期。4 H3 I' K: K7 |! u6 o
5, 尝试我重启了下mysql server,结果Seconds_Behind_Master还是不停的增长。
# I; t G1 U& O" R% ?( |# T7 h' O( I5 k% f8 g1 i
6,最后去检查写入参数看下:# U7 Q# O6 y- E) B
mysql> show variables like '%commit%';6 _+ m" }2 f1 A0 i- l+ {
+--------------------------------+-------+
" ^( T3 C5 _ t" A) o$ V# }| Variable_name | Value |$ Z' s7 y/ y) Y9 R4 V5 t6 z
+--------------------------------+-------+* }- { C8 o: {( A$ V+ R
| autocommit | ON |
1 e( `* f0 e8 Z9 c- Z| innodb_commit_concurrency | 0 |5 k) W- W" O- t z1 |# t( q$ h
| innodb_flush_log_at_trx_commit | 0 |7 Q2 h; L, `& o* ]" K' K g# x
+--------------------------------+-------+2 s3 w/ ]; u# ^& a' o9 L
3 rows in set (0.00 sec)
V9 x9 |4 I& Y
0 \: z4 H# Y% S) ucommit为0,已经算是最快的了。
( |, ^' W4 I% N9 ^再看binlog3 N/ c E- v& u8 {
mysql> show variables like 'sync_binlog';
' f! B; h* H. f( c9 u; e+---------------+-------+
. @: P6 y' o. I1 }) e| Variable_name | Value |. [% ~5 h; Q7 m8 \
+---------------+-------+0 w7 d- M4 I2 ]4 N) w, ?3 V+ x1 Z( L
| sync_binlog | 2 |5 A9 ?5 y2 S$ d' F0 g( p
+---------------+-------+
4 ]! v3 B X6 c6 T; E; p* v5 K1 row in set (0.00 sec)* [: o. E0 p4 r d; a. y7 o2 e! l
/ T% K% G5 x4 B0 g那么改成0试试看吧。0 p, \: O$ t) Z7 d$ R
set global sync_binlog=0;' u2 `- t4 ^7 K7 E5 Q% j% N8 W$ V
: ~: m n7 a" }
执行完后,从Seconds_Behind_Master: 9200变成了Seconds_Behind_Master: 8791,开始追了。 `3 K- X$ ~. a4 a* i3 D
又过了3分钟,已经是Seconds_Behind_Master: 0了。
j7 M" @* o2 f- F* H; o虽然问题解决了,但是主要问题不在sysn_binlog,估计是磁盘有问题了,不然不可能在晚上业务低峰期,会主从delay的。平常白天业务高峰期都没有主从delay过,把疑惑发给山姆大叔,让他去找system administrator吧,去check下disk的问题。 |
|