MySQL与NFS锁问题的分析与处理

  MySQL与NFS锁问题的分析与处理  事件背景在周五晚上，对行内zabbix监控中的告警主机做一些参数调优与异常处理的过程中，进入了一台运行Redis与MySQL的服务器，发现mysqld进程运行，但是没有发现监听端口或套接字，重新启动mysqld依旧无法开启监听，但显示日志都是正常级别，这个问题一下子就让笔者打起了精神。首先查看该MySQL的版本号是5.6.36-x86_64，glibc方式部署，是一个系统使用的应用性能监控（APM）数据库，无集群架构，操作系统是RHEL7.3并且SELinux已关闭。问题分析首先是对mysqld进程进行重启，沿用当前的配置参数文件：启动后没有错误状态返回，进程保持运行但没有开启监听，查看log-error也没有显示错误级别的日志，并且看日志显示InnoDB的快速缓冲池已经初始化完毕了。但是这个日志是比较奇怪的，没有socketcreated...的相关信息，仅在InnoDB的启动后结束了。首先考虑是否因配置文件覆写或歧义的原因导致参数异常，而且检查配置文件也是大部分MySQL问题排查的第一步。这里查看了默认配置文件，发现[mysqld]节中并未有异常点，端口与目录配置都是正常。因为该数据库打开了binlog，所以也查看auto.cnf文件配置，发现也是正常的uuid格式。并且没有修改过主机名。下一步分析是否由于权限问题导致，但日志回显并未报错，这个的可能性已经不大。不过还是需要确定一下，发现数据库使用了--user指定appuser用户运行数据库进程，并且basedir与datadir下权限都是正常的。后续申请了root用户查看/var/log/message等，也没有看到有关于端口冲突、服务异常等日志。这个时候，选择直接分析mysqld运行的过程，使用strace查看程序栈，绕开mysqld_safe的干扰，直接追踪mysqld。strace./bin/mysqld--defaults-file=./my.cnf追踪到运行至系统函数fcntl时出现了诡异的停止，查看上下文，发现是打开了InnoDB的共享表空间文件后，对其进行加锁行为中挂起。通过分析参数的结构体，发现是将ibdata1添加整个文件的排斥锁，为了明确判断该锁是否真的没有加上，使用lsof来判断。文件描述符一栏中可见，ibdata1是被O_RDWR的标志位打开（u），但是没有F_WRLCK的描述位（W，forawritelockontheentirefile），因此可见fcntl的加锁出现了问题。查看文件系统，发现该MySLQ的datadir是在挂载的NFSv3上，这个时候问题的原因差不多可以定位到与NFS有关了。NFSv2/v3存在NLM的锁机制管理，所以很有可能是在这个环节出现了问题。为了验证是NFS导致的，使用当前环境进行测试，重新指定一个本地存储作为datadir，然后启动MySQL。避免影响原始数据，保证id_logfile等日志路径均在datadir下，以避免事务覆盖，将NFS卸载：umount$MYSQL_DATADIR然后重新初始化一个数据库目录，并且指向与系统本地存储：mkdir/tmpdbchown-Rappuser:/tmpdbmysql版本为5.6，还不能使用mysqld来初始化数据库目录，需使用自带脚本scripts/mysql_install_db--user=mysql--basedir=/export/app/mysql--datadir=/tmpdbcp-a./my.cnf./my.cnf.baksed-i's/^datadir=.*/datadir=/tmpdb/g'my.cnfmysqld--defaults-file=./my.cnf--read-only=1启动成功，并查看完整的启动日志如下：至此，问题的关键似乎指向了存放了数据库目录的NFS，而mysql软件目录、操作系统网络栈的问题都被排除在外了。为了追究NFS问题的具体原因，查看与NASServer的rpc检查。发现其中nlm的端口2052通过nc测试无法连接，而nlockmgr是NFSv2/v3的加锁服务，那么问题极有可能就是由这个网络权限引起。回想起最近网络组同事有调整过这个区的网络防火墙，而NFS的rpc类端口仅在初次mount或需要portmap时才调用，不具有网络是否可达的实时验证。例如挂载成功后，111端口的断开不会影响挂载保持，但下次重新挂载会无法mount上。为了支撑此结论，尝试分析系统日志回溯，首先查看dmesg：得知是在lockd模块上的处理出现了请求超时，于是在message上查看lockd的日志信息：先从kernel的nlm_bind_host发送rpc任务进行通信。但是尝试加锁出现fatal。512的ErrorCode在头文件查找到是ERESTARTSYS，属于一种重试机制的退出，因此会在60000节拍后在此尝试。问题处理因为该NFS目录仅export给该服务器，则考虑到尽快恢复，先修改/etc/fstab将NFS的挂载参数修改为nolock，重新启动mysqld，启动正常，性能监控平台恢复数据库可用。使用lsof查看表空间数据文件的句柄标志位已成功加上锁（W）。后续 通知 关于发布提成方案的通知关于xx通知关于成立公司筹建组的通知关于红头文件的使用公开通知关于计发全勤奖的通知 网络组同事，开启rpcinfo返回的端口访问权限，并排查挂载该NAS的主机的网络策略是否有这方面的缺失。问题复盘知道了此次故障的原因后，大概的解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 也就清晰了，但这里选择再次深入分析，了解此次造成问题的深层次原因。于是笔者在电脑上重建一个类似的环境，通过抓包的方式进行复盘分析。选择的环境是两台RHEL7.3，MySQL也是mysql-5.6的glibc版，nfs服务由nfs-utils提供（通过vers指定为版本3）。注意，这里并非完全模拟问题中的NAS服务器，而且部分端 口号 管理印章的关于负责的工作口号抗洪救灾口号体育运动口号宣誓口号公司企业文化口号 并不一致。在服务端配置完rpc和nfs并正常提供服务后，rpc的的转发信息如下。首先是测试客户端正常访问服务端nlm端口，且不适用nolock参数。在客户端执行mount-a时，流量显示如下。rpc通过端口映射（Portmap）请求100003，获得服务端的2049端口提供NFS 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 ；NFS之间通过协议ID（XID）交互获取版本等信息；请求100005，通过MOUNT协议进行交互，主要交流了挂载点和部分权限的信息；其中还会有NFSACL的参与，最后则是客户端mount挂载完成。然后则是执行mysqld--defaults-file=./my.cnf来启动mysqld。这个时候mysqld通过调用POSIX的系统函数进行文件锁添加；NFS则会调用NLM（NetworkLockManager）协议，其由100021获取到映射的端口为33918。nfs中会对操作文件产生一次crc32的校验和一个filehanle，NLM通过这些元素进行锁请求；收到回包后，会重新在nfs的文件系统上获取该文件属性（ATTR），至此锁添加完毕。然后模拟此次故障中的情况，在服务端通过iptables将nlm端口请求流量丢弃。iptables-AINPUT-ptcp--dport33918-jDROP再次启动mysqld，出现问题，与上述现象一致，获取流量如下。可见，通过portmap获取到NLM端口后却无法正常握手，导致NLM服务丢失。在mysql一端，一次添加排斥锁演变为网络请求，导致启动挂起，而在笔者的测试中，这个等待还没有等到一个超时的时间。再补充一点，如果NFS服务器端上由于与客户端的nfs协议冲突或是lcokd模块异常而导致nlockmgr不能提供服务，mysqld则会感知到加锁失败，并且追加错误日志。另外，Linux上关于nfs的配置文件有/etc/exports/etc/sysconfig/nfs/etc/modprobe.d/lockd.conflockd运行时参数可以在/sys/module/lockd/parameters/目录中获得。问题 总结 初级经济法重点总结下载党员个人总结TXt高中句型全总结.doc高中句型全总结.doc理论力学知识点总结pdf 1.服务协议中有一些是用时调用的，在网络调整时需要注意这一点。2.nfs中nlm、acl等是通过rpc的portmap发现的，不是默认的services端口，所以要了解使用的NAS存储设备的端口配置。3.NFS不单有NLM这个影响表空间写保护的机制，还有nfs多协议版本之间的差异，以及文件系统自身的限制。所以对于mysql数据库，使用块存储还是NAS，也是需要好好考虑的一点。本人水平有限，以上内容如有纰漏，请各位读者主动联系笔者指正。 -全文完-