- 积分
- 16843
在线时间 小时
最后登录1970-1-1
|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?开始注册
x
Seconds_Behind_Master: 76005 R% f. F ^$ ?! ~
; U1 e& ~" C/ Q5 w y/ v! v1, 检查show full processlist; 没有任何slow的dml sql语句。
, C) U( u- U5 i3 `4 P2, 检查innodb status,没有任何lock的块。9 K1 M6 b& H8 M1 B# [% O3 j
3, 检查cacti,里面cpu usage从4%上升到了15%,Percona InnoDB I/O GT 从90%降低到了50%%。( [% D. ^, u; P6 ^' H. [4 F
4, 检查当前connections,发现处于业务低峰期。/ h, a5 e, s9 T6 [0 n8 _2 O/ }
5, 尝试我重启了下mysql server,结果Seconds_Behind_Master还是不停的增长。
& ?$ [8 |5 h4 |/ N/ @/ F, z+ E# |1 p' X/ A, E
6,最后去检查写入参数看下:8 h1 _8 D: M! ^2 n% l
mysql> show variables like '%commit%';
, n1 z7 g- C/ F8 W8 { C+--------------------------------+-------+
, M; N# {# c+ x4 `% p| Variable_name | Value |1 `( k8 o# ^8 U% }3 j5 u" R8 _- Z! l
+--------------------------------+-------+( h' D: W- s; U3 R
| autocommit | ON |# F8 p0 W8 l1 r, C
| innodb_commit_concurrency | 0 |+ b" F2 T) B' p( E
| innodb_flush_log_at_trx_commit | 0 |9 L6 W4 F$ s" Z
+--------------------------------+-------+
, l. X+ K9 u3 P8 I" U3 rows in set (0.00 sec)0 n$ M$ w+ i* v2 g+ B% f
" Z! ~* @- @' `( X2 D, F- ^
commit为0,已经算是最快的了。
& l: ?: @; m9 r# W再看binlog
; p/ t" X* Z. G: U# i8 @- ~$ B$ q( Wmysql> show variables like 'sync_binlog';
/ C: x4 |5 M- C+---------------+-------+$ j+ z' L- e, n: F; p
| Variable_name | Value |6 z3 s, r7 k. B
+---------------+-------+
4 t. \7 I7 H* l. m| sync_binlog | 2 |# ]0 O$ b8 O7 K; b) a
+---------------+-------+
- U6 E8 t7 I; E! D$ H+ e; ~1 row in set (0.00 sec). Q0 m/ C3 ^5 y5 ^+ O- Y$ l/ k
/ H; _, {# C% T4 f那么改成0试试看吧。
, G! r h; v. y. Vset global sync_binlog=0;2 m/ F" K& N( U. \; M# A
% z" n- A$ X& G. Y) t! B执行完后,从Seconds_Behind_Master: 9200变成了Seconds_Behind_Master: 8791,开始追了。3 ^% N' D# x9 U" y+ u7 p4 V
又过了3分钟,已经是Seconds_Behind_Master: 0了。
* b3 z& v3 }8 i0 `* P9 k' g虽然问题解决了,但是主要问题不在sysn_binlog,估计是磁盘有问题了,不然不可能在晚上业务低峰期,会主从delay的。平常白天业务高峰期都没有主从delay过,把疑惑发给山姆大叔,让他去找system administrator吧,去check下disk的问题。 |
|