|
|
Seconds_Behind_Master: 76003 z8 ~6 g% _: ?3 H8 Y
! z2 H) R1 R W4 b/ T
1, 检查show full processlist; 没有任何slow的dml sql语句。- ?: n' X7 s5 t
2, 检查innodb status,没有任何lock的块。
2 E; e& }* ~/ N5 \4 E5 I& u% ?3, 检查cacti,里面cpu usage从4%上升到了15%,Percona InnoDB I/O GT 从90%降低到了50%%。! |. S3 U, H6 X0 s
4, 检查当前connections,发现处于业务低峰期。
- ?1 z4 J3 Z) `! D4 Y5 D4 @1 [5, 尝试我重启了下mysql server,结果Seconds_Behind_Master还是不停的增长。
9 e+ ?. f- l8 I! ?: S4 `# C
7 l4 R9 x) ^+ f4 T5 D6,最后去检查写入参数看下:% B' B/ n8 {7 x4 I3 R9 B! i
mysql> show variables like '%commit%';9 ?8 O0 @* f2 z
+--------------------------------+-------+2 n% W) y; I7 B. m3 Y
| Variable_name | Value |
# n0 k* e8 m5 N2 f* I+--------------------------------+-------+
8 O. V$ @& b F5 n5 ^7 M' ~| autocommit | ON |$ {4 |5 O. G% p
| innodb_commit_concurrency | 0 |
% h- J# {$ |* z7 x; u' V# v| innodb_flush_log_at_trx_commit | 0 |
5 w/ q4 V4 }0 W+--------------------------------+-------+( ~8 ]% n2 n/ G- d+ j
3 rows in set (0.00 sec)' S) G, }* v) v
' R# w. L+ U$ n3 l+ n# q$ Gcommit为0,已经算是最快的了。
4 |/ Y" f6 v/ Z6 A# W再看binlog
) I" C5 S1 [: l" D {4 T# [mysql> show variables like 'sync_binlog';
1 C& G* W' [5 ^7 U: N* {$ Z" t6 m$ F+---------------+-------+
2 K% e# e1 s% r| Variable_name | Value |) h$ s4 g. ?/ c" c% _( B1 m
+---------------+-------+' @/ ^0 h6 j, V3 X7 C9 i% _* }
| sync_binlog | 2 |4 C: Q% E+ R4 C) X1 [" ^3 Y7 o
+---------------+-------+
$ Q( n2 O) V. s6 {2 I r5 H1 row in set (0.00 sec) }; `% ~7 d( h! f3 L$ d& u
( J* G1 Q1 u+ U4 u( R5 J6 y, ?那么改成0试试看吧。8 s% v( t( O5 ~1 ]; @/ p5 P
set global sync_binlog=0;
! w) N" I# ?; s! v0 @6 \3 I/ X8 b; C; s; Z
执行完后,从Seconds_Behind_Master: 9200变成了Seconds_Behind_Master: 8791,开始追了。6 a% U" `; f9 G6 s x2 i) ?
又过了3分钟,已经是Seconds_Behind_Master: 0了。
0 t% Y7 s( I6 I) }虽然问题解决了,但是主要问题不在sysn_binlog,估计是磁盘有问题了,不然不可能在晚上业务低峰期,会主从delay的。平常白天业务高峰期都没有主从delay过,把疑惑发给山姆大叔,让他去找system administrator吧,去check下disk的问题。 |
|