- 积分
- 16843
在线时间 小时
最后登录1970-1-1
|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?开始注册
x
Seconds_Behind_Master: 7600
. l) q1 L; `2 q' y% K9 J
7 H' S: k- o+ l* P9 c1, 检查show full processlist; 没有任何slow的dml sql语句。' k h' \8 T0 g. C& u9 T8 ~# c
2, 检查innodb status,没有任何lock的块。" `# g, L2 f& }% P m
3, 检查cacti,里面cpu usage从4%上升到了15%,Percona InnoDB I/O GT 从90%降低到了50%%。
0 G1 k! I7 Z( u2 w4, 检查当前connections,发现处于业务低峰期。
% u1 Z0 L |, f* d5, 尝试我重启了下mysql server,结果Seconds_Behind_Master还是不停的增长。
* ^- a6 U' a, p( Z! J$ X/ \) p; B5 k- R! f2 a3 j3 x) m- a5 k
6,最后去检查写入参数看下:
4 A0 q* y& c0 I9 V+ G0 emysql> show variables like '%commit%';5 B+ H' {/ W& G$ q8 ?, S! q
+--------------------------------+-------+
0 g6 X8 Q) v$ m/ O; i| Variable_name | Value |) i5 z7 {1 [/ |$ I" Q
+--------------------------------+-------+0 k& w' U$ z: s d Q
| autocommit | ON |3 b. d. v% U. h/ E0 g: Y
| innodb_commit_concurrency | 0 |8 K1 c4 g" P- k5 E
| innodb_flush_log_at_trx_commit | 0 |# L% r h9 G" [8 [/ B& _, s% S! P
+--------------------------------+-------+# i, l0 @2 a" O
3 rows in set (0.00 sec): @( C0 E4 m) B6 l0 j
1 D7 X' Z8 b7 k7 W! [4 ?2 Hcommit为0,已经算是最快的了。7 F; P/ ^# ^. f
再看binlog- k2 q/ W* T8 a) n; B3 |4 W& s
mysql> show variables like 'sync_binlog';
/ I: @ y8 R2 s7 N! m% z+---------------+-------+
% e% @: p! l/ B7 u" b0 u6 x: k$ k| Variable_name | Value |9 i- J+ {3 x/ n
+---------------+-------+1 T {4 a* n. S0 e' r; J
| sync_binlog | 2 |
: u" {% x, o, D+---------------+-------+
3 a* N2 n: L- H0 o1 row in set (0.00 sec)
& g- h* B9 ? q! h( f4 J- U
/ l7 r- g2 L1 e7 y, p那么改成0试试看吧。' y' l6 T2 o/ l/ a5 N% ~" y% o
set global sync_binlog=0;
* x3 o. |0 V2 ^* F. ]; v( M% j
+ t7 n$ h* p- g, M- q执行完后,从Seconds_Behind_Master: 9200变成了Seconds_Behind_Master: 8791,开始追了。
! Z1 G; O a" z+ z1 K又过了3分钟,已经是Seconds_Behind_Master: 0了。
4 d0 L* h& h O$ p( p. a虽然问题解决了,但是主要问题不在sysn_binlog,估计是磁盘有问题了,不然不可能在晚上业务低峰期,会主从delay的。平常白天业务高峰期都没有主从delay过,把疑惑发给山姆大叔,让他去找system administrator吧,去check下disk的问题。 |
|