壹個 shard 本質上就是壹個 Lucene 索引，也是 Elasticsearch 分布式化 Lucene 的關鍵抽象，是 Elasticsearch 管理 Lucene 文件的最小單位。
所以，Elasticsearch 提供了大量的接口，可以對集群內的 shard 進行管理。
將分片從壹個節點移動到另壹個節點，在使用 Elasticsearch 中，鮮有需要使用該接口去移動分片，更多的是使用 AllocationDecider 參數以及平衡參數去自動調整 shard 的位置。
在壹些特別的情況下，例如發現大部分熱點數據集中在幾個節點，可以考慮手工 move 壹下。
explain api 是 Elasticsearch 5.x 以後加入的非常實用的運維接口，可以用來診斷 shard 為什麽沒有分配，以及 shard 為什麽分配在某個節點。
如果不提供參數調用該 api，Elasticsearch 返回第壹個 unassigned shard 未分配的原因。
在索引過程中，Elasticsearch 首先在 primary shard 上執行索引操作，之後將操作發送到 replica shards 執行，通過這種方式使 primary 和 replica 數據同步。
對於同壹個分片的所有 replicas，Elasticsearch 在集群的全局狀態裏保存所有處於同步狀態的分片，稱為 in-sync copies。
如果修改操作在 primary shard 執行成功，在 replica 上執行失敗，則 primary 和 replica 數據就不在同步，這時 Elasticsearch 會將修改操作失敗的 replica 標記為 stale，並更新到集群狀態裏。
當由於某種原因，對於某個 shard 集群中可用數據只剩 stale 分片時，集群會處於 red 狀態，並不會主動將 stale shard 提升為 primary shard，因為該 shard 的數據不是最新的。這時如果不得不將 stale shard 提升為主分片，需要人工介入：
當由於 lucene index 損壞或者磁盤故障導致某個分片的主副本都丟失時，為了能使集群恢復 green 狀態，最後的唯壹方法是劃分壹個空 shard。
壹定要慎用該操作，會導致對應分片的數據完全清空。
壹般來說，增加主分片數量可以增加寫入速度和查詢速度，因為數據分布到了更多的節點，可以利用更多的計算和 IO 資源。增加副分片數量可以提升查詢速度，並發的查詢可以在多個分片之間輪詢。
但是 shard 管理並不是 “免費” 的，shard 數量過多會消耗更多的 cpu、內存資源，引發壹系列問題，主要包括如下幾個方面。
任壹時刻，壹個集群中只有壹個節點是 master 節點，master 節點負責維護集群的狀態信息，而且狀態的更新是在單線程中運行的，大量的 shard 會導致集群狀態相關的修改操作緩慢，比如創建索引、刪除索引，更新 setting 等。
單個集群 shard 超過 10 萬，這些操作會明顯變慢。集群在恢復過程中，會頻繁更顯狀態，引起恢復過程漫長。
我們曾經在單個集群維護 30 多萬分片，集群做壹次完全重啟有時候需要2-4個小時的時間，對於業務來說是難以忍受的。
查詢很多小分片會降低單個 shard 的查詢時間，但是如果分片過多，會導致查詢任務在隊列中排隊，最終可能會增加查詢的整體時間消耗。
Elasticsearch 協調節點接收到查詢後，會將查詢分發到查詢涉及的所有 shard 並行執行，之後協調節點對各個 shard 的查詢結果進行歸並。
如果有很多小分片，增加協調節點的內存壓力，同時會增加整個集群的 cpu 壓力，甚至發生拒絕查詢的問題。因為我們經常會設置參與搜索操作的分片數上限，以保護集群資源和穩定性，分片數設置過大會更容易觸發這個上限。
Elasticsearch 通過 AllocationDecider 策略來控制 shard 在集群內節點上的分布。
分片平衡對 Elasticsearch 穩定高效運行至關重要。下面介紹 Elasticsearch 提供的分片平衡參數。
當使用 cluster.routing.allocation.balance.shard 和 index.routing.allocation.total_shards_per_node 不能使分片平衡時，就需要通過該參數來控制分片的分布。
所以，我們的經驗是： 創建索引時，盡量將該值設置的小壹些，以使索引的 shard 比較平均的分布到集群內的所有節點。
但是也要使個別節點離線時，分片能分配到在線節點，對於有 10 個幾點的集群，如果單個索引的主副本分片總數為 10，如果將該參數設置成 1，當壹個節點離線時，集群就無法恢復成 Green 狀態了。
所以我們的建議壹般是保證壹個節點離線後，也可以使集群恢復到 Green 狀態。
Elasticsearch 內部的平衡策略都是基於 shard 數量的，所以在運行壹段時間後，如果不同索引的 shard 物理大小差距很大，最終會出現磁盤使用不平衡的情況。
所以，目前來說避免該問題的以辦法是讓集群內的 shard 物理大小盡量保持相近。
主節點對 shard 的管理是壹種代價相對比較昂貴的操作，因此在滿足需求的情況下建議盡量減少 shard 數量，將分片數量和分片大小控制在合理的範圍內，可以避免很多問題。
下壹節我們將介紹 分片內部的段合並 相關問題。