緣起
正在歡樂的逗着孩子玩耍，突然間來了一通電話，值班人員告訴我誤重啟了一台服務器，是我負責的服務，感覺都要嚇飛了，趕緊打開電腦查看次服務器上跑的是什么業務，
不看不知道，一看嚇一跳，尼瑪，是著名的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的配置文件出現不完整信息原因是因為服務器硬重啟導致，而服務器重啟是人為的誤操作導致，最根本的還是在人。慢一點可以，但是千萬不要搞錯啊。。。。