elasticsearch學習筆記（九）——shard&replica機制以及ES集羣節點的問題

一、shard和replica知識概括梳理

（1）一個index包含多個shard
（2）每一個shard都是一個最小工做單元，承載部分數據，能夠說就是一個lucene實例，擁有完整的創建索引和處理請求的能力
（3）每當ES集羣增長節點時，shard會自動在nodes中實現負載均衡
（4）對於primary shard和replica shard，每一個document確定只存在於某一個primary shard以及其對應的replica shard中，不可能存在於多個primary shard中
（5）replica shard時primary shard的副本，主要負責容錯，以及承擔讀請求的負載
（6）primary shard的數量在建立索引的時候就已經固定了，可是replica shard的數量能夠隨時修改
（7）primary shard的默認數量是5個，replica默認是1，也就是在默認的狀況下，有5個primary shard和5個replica shard
（8）primary shard不能和本身的replica shard放在同一個節點上（不然節點宕機，primary shard和副本都丟失，也就起不到容錯的做用了），可是能夠和其它primary shard的replica shard放在同一個節點上

二、對於單節點ES集羣存在的問題

假設咱們建立一個索引test_index

PUT /test_index
{
  "settings": {
    "number_of_shards": 5,
    "number_of_replicas": 1
  }
}

（1）單node環境下，建立一個index叫test_index,有5個primary shard,5個replica shard
（2）集羣的status是yellow

GET /_cat/health?v
epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1555495650 10:07:30  elasticsearch yellow          1         1      8   8    0    0        6             0                  -                 57.1%

（3）這個時候，只會將5個primary shard分配到僅有的一個node上去，另外5個replica shard是沒法分配的
（4）此時集羣是能夠正常工做的，可是一旦出現節點宕機，數據就會所有丟失，此時節點也不可用，沒法承擔任何請求
結構以下：

三、對於兩個節點ES集羣

上面test_index索引的shard分配的結構就會變成：

此時即便存放primary shard的節點掛掉了，ES的shard allocation 會被觸發，此時對應的primary shard的一個副本會變成primary shard

在什麼場景下會觸發Shard的Allocation：

建立/刪除一個Index；
加入/離開一個Node；
手動執行了Reroute命令；
修改了Replica設置；