緣起

　　正在歡樂的逗著孩子玩耍，突然間來了一通電話，值班人員告訴我誤重啟了一臺服務器，是我負責的服務，感覺都要嚇飛了，趕緊打開電腦查看次服務器上跑的是什麽業務，

不看不知道，一看嚇一跳，尼瑪，是著名的redis cluster集群中的一臺服務器，此時此刻心中一萬個草泥馬奔騰而過。。。。

剖析

　　此集群是26臺512G內存搭建的redis cluster，數據量已經達到了4T，每個服務器上篇對應24個實例，每個實例的內存配置為20G。

首先我登錄了一臺集群中的另外一臺服務器B，通過B連接上redis 集群，使用cluster info 命令查看發現集群狀態是ok的，顯然已經自動failover。不幸中的大幸，辛虧是這個集群，

此集群是有副本的，解決了單點故障問題，若是其它兩個集群中的主機後果不敢想象。此時此刻就展示出HA的重要性了，Down掉一臺服務器，集群整體不受影響，另外服務請求

可能會出現少量的錯誤，因為有可能槽位再切換中。

恢復

　　我登錄剛剛重啟的這個服務器之後，使用腳本啟動所有的實例，大約過了30分鐘，22個實例啟動完畢，數據完全加載到內存，並且實例再集群中的狀態已經恢復，此過程是自動的，redis cluster 還是很給力從這方面來講。當我使用 redis-cli -p 6381 cluster nodes|grep fail 的時候發現還有兩個實例是fail狀態。趕緊檢查。

53faad9cd4257f33eaaa92f40f7439bf2f30db21 10.34.2.15:6396 slave,fail 8269ee58f563a5961755ee7f782794c7f79f8077 1506431668362 1506431655787 908 disconnected
2cc8f7f49bb7f28dc383b6113080bae4f3b2e375 10.34.2.15:6388 slave,fail ceb54aabf39b0c8c88a205294724be76295c4ab9 1506431660074 1506431647510 1272 disconnected

故障主機 10.34.2.15 的 6396redis日誌中發現了如下的報錯：

5927:M 26 Sep 21:39:37.527 # Unrecoverable error: corrupted cluster config file.

檢查cluster生成的node文件，發現文件中缺失信息，最後一行出現了半行不完整的數據記錄。我的處理方法是將所有的都清理掉，只保留myself那行。

然後再次啟動redis實例，則加載成功。

反思

　　cluster的配置文件出現不完整信息原因是因為服務器硬重啟導致，而服務器重啟是人為的誤操作導致，最根本的還是在人。慢一點可以，但是千萬不要搞錯啊。。。。

Unrecoverable error: corrupted cluster config file.