致敬那些运维过程中踩到的坑（转）

一、MySQL+MMM集群中服务的启动顺序

           小弟最近心血来潮，在实验环境值部署MySQL+MMM集群，刚开始顺风顺水，一路到底，没出现任何问题。此时，个人也觉得，MySQL+MMM集群部署起来也没什么难度啊，但是随后出现的问题，却彻底打脸了。

其实，原因是这样的：

MySQL+MMM部署很顺利，运行也没问题，但是有一天，机房断电，服务器随后也就GG了。等了一段时间，机房来电，开始启动服务器，启动服务，博主的服务启动顺序是这样的：

mysqld---------mmm_agent---------mmm_mond

            mysqld、mmm_agent 启动没问题，但是检查 mmm_mond 的时候，发现进程存在，端口未监听，没有写错误日志，这就奇怪了，正常思维，杀掉进程，重新启动，但是，遗憾的是又失败了，还是端口未监听，百思不得其解啊。于是博主怀疑是不是文件损坏了，趁着这个思路，博主麻溜的将 mmm_monitor 服务重新安装，以为这次就可以正常监听端口。于是，开始启动服务，服务起来了，赶紧 netstat –tpnl 查看一下，可惜了，想法是美好的，而结果却是残酷的，端口还是未监听。难道，问题的关键不在 mmm_mond 服务，博主抱着尝试的心态，先关掉了 mmm_agent、mysqld 服务，单独启动 mmm_mond 服务，这次，进程存在，端口也在监听中，万事大吉了，赶紧再把 mysqld、mmm_agent 服务开启吧。按照惯例，先开启了 mysqld 服务，接着开启 mmm_agent 服务，再 mmm_control show 查看集群状态，结果，你猜发生什么了？mmm_control show 运行后，竟然一直卡在那，无任何返回，于是乎，尝试 mmm_control checks all 查看一下集群中各个服务的状态，结果呢，还是无返回，我去，这又是什么梗啊，搞不懂。哎，还是关掉服务再来一次吧，于是啊，博主又关掉了 mysqld、mmm-agent、mmm_mond 三个服务，这次，博主是先启动 mmm_agent 服务，然后启动 mmm_mond 服务，最后启动 mysqld ，好啦，服务起来了，我们再检查一下 mmm_mond 启动结果，进程存在、端口在监听状态，算是正常，最后，博主运行了 mmm_control show 和 mmm_control checks all 两条命令，均有返回。

终于解决了，废了老半天时间，不过还好，踩进一次坑，自己的经验又会多一份。所以，我们在日常运维过程中，遇见问题，不要心急，静下心来好好分析问题，最后解决问题，切记，不要随意重装服务，只有在尝遍各种方法无效后可重装。

二、LVS-NAT集群中，真实服务器上多网卡会影响数据解析与发送

            LVS集群 ，在现在企业中可谓是应用广泛啊，最近，博主在实验环境中也部署了 LVS 集群。其实 LVS 集群的部署可谓是简单至极，先准备两台服务器做 Real server ，在准备一台服务器做 LVS 调度器，Real server 中不需要做任何事情，只需要你安装好 LAMP 或者 LNMP 即可，最主要的就是 LVS 调度器的部署了，其实很简单，安装好 ipvsadm 包，部署配置就三条命令博主表示，内心是奔溃的，准备这么久，竟然三条命令就搞定，不过，别着急，虽然简单，但是问题总还是有的，怎么回事呢？

           事情是这样的，博主部署完 LVS-NAT 集群，怀着激动的心情测试一下通过 LVS-NAT 去访问防火墙内部的网站，结果呢，访问失败，连接超时。于是，博主开始进行各种检查，发现 LVS-NAT 配置没错，系统内核转发也是开启的，没有其他配置了，到底怎么回事呢，使用命令 ipvsadm –Ln 查看连接状态，发现有很多无效链接，再使用命令 ipvsadm –lnc 查看请求状态，发现所有的请求全部处于 TCP SYN_RECV 状态。

首先，我们来弄清楚，SYN_RECV 状态是什么，为什么会产生？

所谓 TCP SYN_RECV 状态，指的是，在 TCP 三次握手过程中，服务端接收到了来自客户端发送的 SYN ACK 请求后，发送一个空闲数据包给客户端，告诉客户端，它已经收到了客户端的请求，此时服务器就会进入 SYN_RECV 状态。

所谓 TCP 三次握手，是这样的：

在TCP/IP协议中，TCP协议提供的是可靠的连接服务，采用三次握手建立一个连接。
第一次握手：建立连接时，客户端发送syn包(syn=i)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=i+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

          了解清楚了 TCP 三次握手，我们回过头看这个问题，结果很显然，服务器接收到了客户端的请求，也已确认客户端的请求，但是未收到客户端的确认，什么原因呢，原因是服务器发出去的 SYN 包没有到达客户端，为什么不是客户端发送的 ACK 包没有到达服务器呢，因为，经过了 TCP的第一次握手，我们可以确定，客户端发送的数据包是可以到达服务器的，所以问题出在了 TCP 第二次握手。

         经过了上面分析，其实我们已经可以看出端倪，可能有两点原因，第一，服务器发送给客户端的 SYN 应答包中的目的地址错误，导致客户端无法接收到服务器发送的 SYN 应答包，第二，服务器端对 SYN 应答包的路由错误，导致 SYN 应答包无法到达客户端。一般开说，在一个正常的网络环境中，目标地址错误的可能性不大，除非有 SYN Flood ***存在，所以，基本可以判断是路由问题引起的。于是博主检查了两台 Real Server 服务器，配置倒没发现什么问题，只是网卡有两块，我们都知道，在服务器中，如果存在双网卡，就需要做特殊的设置，一般是做负载均衡使用，但是在这里，貌似我们没有 必要使用双网卡，于是禁掉一块连接外网的网卡，重启网络。再访问一下我们的网站，发现正常了，博主心中瞬间一万个草泥马奔腾而过啊，这，我还能说什么呢。

好啦，问题，导致里是解决了，但是日常运维过程中，我们一定要注意，不要让一些本不该出问题的地方除了问题，这些地方除了问题，我们往往很难想到。

三、MySQL+MMM集群中，客户端长时间未请求VIP，重新请求会无法连接

        其实，这个问题可算做是坑，也可不算，对于MySQL+MMM的 VIP 无法连接的问题，表面上看似是无法连接 VIP ，其实不然。MySQL数据库的默认超时时间为28800，也就是 8 小时，当客户端在超过 8 小时未请求MySQL数据库时，MySQL数据库就会自动与客户端断开连接，这时候，客户端在重新请求MySQL数据库时的表现就无法连接数据库，这个问题就属于MySQL的经典8小时问题。所以，此问题并不是MySQL+MMM集群的VIP无法连接，而是，MySQL数据库无法连接，因此，当我们在部署完MySQL数据库时，一般都会将这个超时时间修改，至于修改未多久，根据我们自身的情况而定，建议，将此值修改为24小时，也就是604800。这里，建议在配置文件中添加下面两个参数：

interactive_timeout = 604800
wait_timeout = 604800

不建议直接在命令下修改，因为命令行下修改完后，如果数据库重启，就会失效。

  https://blog.51cto.com/4746316/2319766?source=dra