Heim >Datenbank >MySQL-Tutorial >mmm-master漂移问题的分析

mmm-master漂移问题的分析

WBOY
WBOYOriginal
2016-06-01 13:12:591125Durchsuche

一、问题描述
线上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

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn