|
|
Seconds_Behind_Master: 7600& _% A! ?/ e" F4 G' k- f; N
% c0 [! J, B( A* \- |/ e% P
1, 检查show full processlist; 没有任何slow的dml sql语句。9 ~9 l$ Q( L' z4 D5 R; G1 [+ u
2, 检查innodb status,没有任何lock的块。# _4 J/ @$ m% c
3, 检查cacti,里面cpu usage从4%上升到了15%,Percona InnoDB I/O GT 从90%降低到了50%%。
/ ]2 P0 f- L" u5 }( d; a4, 检查当前connections,发现处于业务低峰期。
% {# m7 x4 d& ^5, 尝试我重启了下mysql server,结果Seconds_Behind_Master还是不停的增长。
, s5 W7 u) T- r/ d- T$ S$ M
/ u4 ^8 \+ X3 Y# i! I6,最后去检查写入参数看下:1 j4 R% ^. v, A& J2 j1 F
mysql> show variables like '%commit%';' a* ^1 j, M! D6 F, S
+--------------------------------+-------+
, F o! B( n; W/ ? [. P+ ^| Variable_name | Value |+ C4 S1 H: S8 ^! [ ?6 `
+--------------------------------+-------+
* V# ]" X' j. H| autocommit | ON |
# ]4 j3 | B0 h3 r" q| innodb_commit_concurrency | 0 |" n1 p* u4 Z2 o/ Z) Y. Z
| innodb_flush_log_at_trx_commit | 0 |
5 l( _! x9 g1 J+--------------------------------+-------+
8 e6 ^% y9 m2 A9 N! }+ t% }* o3 rows in set (0.00 sec)
! M; C/ n; b$ Z: Y4 L. ^+ ~9 j4 N7 k) |
commit为0,已经算是最快的了。
3 P0 q0 e9 R# }4 R再看binlog9 S8 a0 u% D2 Y0 \) r: ^% X" S: W, v
mysql> show variables like 'sync_binlog';; C3 {$ l' m7 E/ l! S8 [
+---------------+-------+" d) a( Q3 r% {, }
| Variable_name | Value |
4 x6 N2 U% f P/ w6 i- D, D: G+---------------+-------+9 t4 ^" l2 D) V3 v( l
| sync_binlog | 2 |9 Z; C& B7 l# }/ i |7 @
+---------------+-------+; X1 |" S. A6 A2 X4 e: `" f
1 row in set (0.00 sec)
7 n% X. ~2 c; m+ F, Z8 \8 I! R! d8 @3 w% d. K3 a
那么改成0试试看吧。7 |$ M$ O7 O7 s3 x5 m; K- k4 s
set global sync_binlog=0;
3 [6 V. h# e2 R- \+ E+ `' w7 ?$ u9 `2 D1 `6 ?. t
执行完后,从Seconds_Behind_Master: 9200变成了Seconds_Behind_Master: 8791,开始追了。
! O" c; a) W( r; `+ b/ ?: s又过了3分钟,已经是Seconds_Behind_Master: 0了。* ?( @9 p3 t. F# ]5 ^- l) U$ N
虽然问题解决了,但是主要问题不在sysn_binlog,估计是磁盘有问题了,不然不可能在晚上业务低峰期,会主从delay的。平常白天业务高峰期都没有主从delay过,把疑惑发给山姆大叔,让他去找system administrator吧,去check下disk的问题。 |
|