mmm-master漂移问题的分析

date:20140527
auth:Jin

一、问题描述
线上store应用,偶尔出现慢的现象。检查发现是writer角色在master-backup之前漂移
检查mysql-log没有发现异常,也没前端nginx/php以及mysql-proxy无关
master show processlist500多个线程

二、分析
1.查看mmm-monitor检测mysql状态的代码,确认漂移的条件
1).无法链接 return "ERROR: Invalid host '$host'" unless ($peer_host); 帐号密码的问题
2).链接过多的情况 return "UNKNOWN: Too many connections! "
3).执行SELECT NOW()语句,无法执行
4).超时

2.打开mmm-monitor debug日志,确认详细的漂移原因
# vim /etc/mysql-mmm/mmm_mon_log_3310.conf
修改
log4perl.logger = DEBUG, MMMLog
log4perl.appender.MMMLog.Threshold = DEBUG
# /etc/init.d/mysql-mmm-monitor restart 3310

3.等待重现,获取漂移原因
# grep -n move mmm_mond_3310.log
143932:2014/05/15 10:54:24 INFO Removed role 'writer(192.168.201.10)' from host 'db2'
2014/05/15 10:54:21 DEBUG Received Answer: OK: Status applied successfully!|UP:7818568.42
2014/05/15 10:54:22 ERROR Check 'mysql' on 'db2' has failed for 10 seconds! Message: ERROR: Connect error (host = 192.168.201.2:3310, user = dbslave)! Can't create a new thread (errno 11); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug
2014/05/15 10:54:23 DEBUG Listener: Waiting for connection...
2014/05/15 10:54:24 FATAL State of host 'db2' changed from ONLINE to HARD_OFFLINE (ping: OK, mysql: not OK)
2014/05/15 10:54:24 INFO Removing all roles from host 'db2':
2014/05/15 10:54:24 INFO Removed role 'writer(192.168.201.10)' from host 'db2'
2014/05/15 10:54:24 DEBUG Sending command 'SET_STATUS(HARD_OFFLINE, , )' to db2 (192.168.201.2:43310)
2014/05/15 10:54:24 DEBUG Received Answer: OK: Status applied successfully!|UP:34710477.06
2014/05/15 10:54:24 INFO Orphaned role 'writer(192.168.201.10)' has been assigned to 'db3'
2014/05/15 10:54:24 DEBUG Sending command 'SET_STATUS(ONLINE, reader(192.168.201.11), db3)' to db216 (192.168.201.216:43310)
2014/05/15 10:54:24 DEBUG Received Answer: OK: Status applied successfully!|UP:28460505.74

漂移原因:
Message: ERROR: Connect error (host = 192.168.201.2:3310, user = dbslave)! Can't create a new thread (errno 11); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug

4.原因分析
if you are not out of available memory
内存不够?
实际内存是够的,排除。系统最大连接数问题?

原因分析:
和mysql本身没关系
操作系统连接数太小。(centos6 默认的 max user process只有 1024个。当mysql process大于这个值时 就会出现Can't create a new thread的问题)

确认系统限制
# su -s /bin/bash mysql
bash-4.1$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 256352
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 1024
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

5.解决问题
修改
test -f /etc/security/limits.d/90-nproc.conf && echo "mysql soft nproc 65536" >> /etc/security/limits.d/90-nproc.conf
或者:
#vim /etc/bashrc
#su -s /bin/bash mysql
ulimit -u 65536

确认
# su -s /bin/bash mysql
bash-4.1$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 256352
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimit ed
max user processes (-u) 65536
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

diff一下发现变化信息
max user processes (-u) 1024
max user processes (-u) 65536
这个是64位的。32位的变化情况为(同样配置为mysql soft nproc 65536的情况下)
max user processes (-u) 15036

6. 将write角色从backup move回来
mmm_control @3310 move_role writer db2

 

posted on 2014-05-27 15:48  @Jin  阅读(548)  评论(0编辑  收藏  举报

导航