該文章同步發佈於：我的部落格

也歡迎關注我的 Facebook 以及 Instagram 接收軟體相關的資訊！

上一篇文章 中，我們提到了 Primary Shard ( 以下簡稱 PS ) 也介紹了其用處。

而 Replica shard ( 以下簡稱 RS ) 要解決的問題自然是 PS 沒辦法做到的事情。

當機器停止運作

關於 PS 現在我們都知道是將 index 拆分，存放到不同的 shard 之中，但如果有一個 node 的機器故障了，這時候資料就是直接消失 50 %，這樣會嚴重影響商業的運行。

所以 RS 如其所名，就是來複製 PS 來提高 Elasticsearch ( 以下簡稱 ES ) 的可用性，是怎麼辦到的呢？我們看看下面的圖片：

我們分別在兩個 node 上面做了 PS A 以及 PS B 兩個主要分片，而在各自從 PS A 增生出 RS A-1 到另外一個 node，另一邊同理。

為什麼 RS A-1 要放到 node 2 呢？很簡單，因為當 node 1 故障時，我們還是保有所有的資料提供 ES 做搜尋。

其實這就是 RS 主要在做的事情，單純的複製 PS 然後和其一起組成 Replication group

⚠️ ⚠️ ⚠️ 如果要把 ES 部署到正式環境的話，一定要注意的一件事，永遠不要把全部的資料放在一個 node 上面；這可以讓你在晚上安穩地睡個好覺。

建立 RS，輕鬆簡單

熟悉關聯式資料庫的人一定也理解 RS 的意義，但要實踐這件事在關聯式資料庫上常常需要尋求外部套件的協助，而 ES 在這點上是原生支持，等於是我們只需要做好設定即可。

但在這個設定的背後有一些小問題需要釐清，當你啟動只有一個 node 的 ES 時，RS 會變得無處可去，它只能被指派到和 PS 不同的 node 上面，這邊會做一個示範。

一樣到 Dev tools 輸入 PUT /users 來建立一個 index：

接著列出所有的 index GET /_cat/indices?v

可以看到上面紅框處是寫 Yellow 而不是 Green 這就是我前面提到的小問題，當只有啟動一個 node 的時候，RS 會沒有用，而這邊的 Yellow 就是在提示有 shard 沒有被指派。

怎麼證明其實真的有 RS 存在呢？看向上面的藍框處，我們可以看到 pri 就是 PS 是 1，而 rep RS 也是 1。

好的，這樣確實是證明了 RS 存在，但要怎麼證明他沒有被指派呢？

列出所有的 shard GET /_cat/shards?v

上圖就可以很清楚的看出有一個 r 的 shard 狀態是 UNASSIGNED

回到這個標題，我們可以感受到建立 RS 在 ES 有多簡單，甚至沒有進行任何的額外作業，就能夠自動地建立 RS。

為什麼預設的 index 沒有 replica 呢？

如果嘗試列出預設的 index 會發現，奇怪，為什麼他們本身沒有 RS 呢？

其實是有的，只是現在我的設定是單一節點，這些預設的 index 都是採用 auto_expand_replicas 的策略，也就是當有第二個節點出現時，才會建立 RS，而不是先建立然後變成 UNASSIGNED。

提升 index 的吞吐量

還記得我們前面提過的 Replication Group 的概念嗎？當今天的 shards 變多，意味著整個 Group 可以同時處理的查詢請求量就會提高，怎麼辦到的？

ES 採用的是『 並行 』的方式處理這些請求，當只有 2 個 shards 時，最多就是同時並行 2 個請求，而當今天 shards 變成 4 個，那就是成倍的提升。

RS 和 Snapshot ( 快照 ) 差在哪？

既然 RS 有一個很大的功能是來提升整個 ES 的可用性，那和 snapshot 差在哪呢？

首先，snapshot 本身是一種可以讓資料回到某個時間點的備份手段，這個就和 RS 有很大的不同，這個 ES 本身也有提供，很方便。

還有 snapshot 並不侷限在 index level，可以是整個 cluster 的 snapshot。

shard 只能應用在 index level

當然這兩者都是來提升整個 ES 的可用性，但本質上還是不一樣的。

可以這麼說，雖然 snapshot 提供了一個長期的資料恢復機制，但它們不會捕捉每一個即時的變化。另一方面，RS 提供了一個方式在節點或機器故障時保護即時的資料。