背景原理
green狀態：每個索引的primary shard和replica shard都是active狀態
yellow ： 每個索引的primary shard都是active狀態，但是部分replica shard不是active狀態，處於不可用狀態
red: 不是所有的索引的primary shard都是active狀態，部分索引有數據丟失了
爲什麼現在處於一個yellow狀態
我們現在就一臺機器，就啓動了一個es進程。相當於就起了一個節點，由於默認的配置是每個index分配5個primary shard和1 個replica shard，而且primary shard和replica shard不能在一個機器上（爲了容錯）。所以，現在的replica shard沒法被分配
ps -ef | grep ela
後發現只有一個進程
此時，我們再啓動一個進程，觀察下
果然：
我們需要釋放一點內存來啓動
通過top查看現在最佔內存的應用：
我們去看看1330這個進程
ps -ef |grep 1330
發現是之前測試的一個高版本的es進程，果斷幹掉
再次查看內存後ok
再次嘗試啓動es 5.4
報錯如下：
應該是配置最大節點數目爲1了，日誌說的也比較明顯了
因爲默認配置的1，我們一般也只在一臺機子上部署一個節點，不過我們開發環境爲了演示變爲green，這裏配置下爲2
配置如下：
這次啓動沒上面這個問題了
不過我們忘了改端口
注意，ES的配置文件必須使用elasticsearch.yml這個命名，因此必須創建出兩個目錄來。所以，我這裏copy一份配置，重新建立一個目錄進行操作，並配置如下：
把默認的端口改掉
修改日誌位置：
修改節點名：
重新啓動成功
再次查看es的狀態
任然是yellow，查看節點2 的日誌：
意思是不能組成一個集羣。最後查看相關文獻，刪除掉從master複製來的data目錄下的nodes節點內容，啓動ok！
節點02 加入集羣：
之前的這個索引已經有一個replica分配過來了
因爲我這邊之前程序創建索引沒指定個數，默認是1個主分片，5個副本
通過查看索引setting配置
所以，我這裏手動將副本改爲1個
再次查看
修復成功！
