缘起
正在欢乐的逗着孩子玩耍，突然间来了一通电话，值班人员告诉我误重启了一台服务器，是我负责的服务，感觉都要吓飞了，赶紧打开电脑查看次服务器上跑的是什么业务，
不看不知道，一看吓一跳，尼玛，是著名的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的配置文件出现不完整信息原因是因为服务器硬重启导致，而服务器重启是人为的误操作导致，最根本的还是在人。慢一点可以，但是千万不要搞错啊。。。。