一、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 伺服器，配置倒沒發現什麼問題，只是網絡卡有兩塊，我們都知道，在伺服器中，如果存在雙網絡卡，就需要做特殊的設定，一般是做負載均衡使用，但是在這裡，貌似我們沒有 必要使用雙網絡卡，於是禁掉一塊連線外網的網絡卡，重啟網路。再訪問一下我們的網站，發現正常了，博主心中瞬間一萬個草泥馬奔騰而過啊，這，我還能說什麼呢。

好啦，問題，導致裡是解決了，但是日常運維過程中，我們一定要注意，不要讓一些本不該出問題的地方除了問題，這些地方除了問題，我們往往很難想到。