轉(zhuǎn)載自：https://blog.csdn.net/iceman1952/article/details/79957290
這是一篇譯文怨绣，原文（Every shard deserves a home）于2016-11-11發(fā)布在elastic官方博客旗们。譯文稍有更改
文章包含很多gif動(dòng)圖丰榴，你可以使用“2345看圖王”查看/暫停/回放gif動(dòng)圖的每一幀
所有圖片都可以在新標(biāo)簽頁(yè)中查看大圖
“索引”有時(shí)作動(dòng)詞怠褐，有時(shí)作名詞淆两。例如“當(dāng)索引第一個(gè)文檔到新的索引中時(shí)...”接奈，第一個(gè)索引是動(dòng)詞师骗，第二個(gè)索引是名詞
術(shù)語(yǔ)及翻譯。有些術(shù)語(yǔ)不翻譯薪韩，直接使用英文原詞
rebalance重新平衡
relocation重新安置确沸。即：集群已經(jīng)選定了目標(biāo)shard，需要從primary shard向這個(gè)目標(biāo)shard復(fù)制數(shù)據(jù)
reallocation重新分配俘陷。即：集群把某個(gè)/ 些索引的shard分布到集群中節(jié)點(diǎn)上
shard allocationshard分配
shard copy分片副本（即可以是primary shard也可以是replica shard）
mastermaster（主節(jié)點(diǎn)罗捎。使用英文原詞，不再翻譯）
shardshard（分片拉盾。使用英文原詞桨菜，不再翻譯）
primary shardprimary shard（主分片。使用英文原詞捉偏，不再翻譯）
replica shardreplica shard（副分片倒得。使用英文原詞，不再翻譯）
segmentsegment（段夭禽，Lucene中的概念霞掺。使用英文原詞，不再翻譯）
文中這些優(yōu)秀的幻燈片來(lái)自于Core Elasticsearch: Operations課程讹躯，它們有助于解釋shard分配（shard allocation）的概念菩彬。我們推薦您參加完整課程以更好的理解這些概念缠劝，但，我會(huì)在此列出培訓(xùn)的梗概
Shard分配（shard allocation）是把shard分配給節(jié)點(diǎn)的過(guò)程骗灶。 當(dāng)初始恢復(fù)（initial recovery）惨恭、副分片分配（replica allocation）、重新平衡（rebalancing）或向集群中加入/移除節(jié)點(diǎn)時(shí)就會(huì)發(fā)生shard分配耙旦。大部分時(shí)間脱羡，你無(wú)需掛心它，它在后臺(tái)由elasticsearch完成免都。如果你發(fā)現(xiàn)自己對(duì)這些細(xì)節(jié)感到好奇锉罐，這篇博客將探索幾種不同場(chǎng)景下的shard分配
本文的集群由4個(gè)節(jié)點(diǎn)組成，如下圖所示琴昆。文中的例子都使用此集群完成
我們將覆蓋四種不同的場(chǎng)景
如上圖所示，這是最簡(jiǎn)單的用例业舍。我們創(chuàng)建了索引c，于是我們必須得為它分配新的shard升酣。當(dāng)索引第一個(gè)文檔到這個(gè)新的索引時(shí)舷暮，就會(huì)為它分配shard。上圖使用Kinaba中的Console插件（之前稱為Sense）來(lái)執(zhí)行灰色高亮的命令噩茄，索引一個(gè)文檔到索引中
對(duì)于索引c下面，我們正在創(chuàng)建一個(gè)primary shard和一個(gè)replica shard。master需要?jiǎng)?chuàng)建索引c绩聘，并為它分配2個(gè)shard沥割，即一個(gè)primary shard和一個(gè)replica shard。集群會(huì)通過(guò)以下方式來(lái)平衡集群
考察集群中每個(gè)節(jié)點(diǎn)所包含shard的平均數(shù)量凿菩，然后机杜，盡可能使得每個(gè)節(jié)點(diǎn)上的此數(shù)字保持一致
基于集群中每一個(gè)索引來(lái)做評(píng)估，使得shard跨所有索引而保持平衡
Shard分配過(guò)程中存在一些限制衅谷，分配決定器（allocation decider）在做分配時(shí)會(huì)遵從這些限制椒拗。分配決定器會(huì)評(píng)估集群要做的每一個(gè)決定，并給出yes/no的回復(fù)获黔。分配決定器運(yùn)行在master上蚀苛。你可以認(rèn)為是master給出修改提議，分配決定器則告知master此修改提議是否能通過(guò)
關(guān)于此最簡(jiǎn)單的一個(gè)例子就是玷氏，你不能把同一個(gè)shard的primary shard和replica shard放到同一個(gè)節(jié)點(diǎn)上
關(guān)于此還有一些其他例子
1. 基于Hot/Warm配置作分配過(guò)濾
這允許你把shard只放到具有特定屬性的節(jié)點(diǎn)上堵未，分配決定器會(huì)根據(jù)Hot/Warm配置接受或拒絕集群所作的決定。這是用戶決定直接控制分配決定器的例子
2. 磁盤使用情況分配器（Disk usage allocator）
master監(jiān)控集群中磁盤的使用情況盏触，并根據(jù)高水位/低水位閾值控制shard分配（見下面的：“場(chǎng)景二渗蟹、 是時(shí)候移動(dòng)shard了”）
3. 抑制（Throttles）
這意味著块饺，理論上我們可以把shard分配到某節(jié)點(diǎn)，但拙徽，此節(jié)點(diǎn)上有太多正在進(jìn)行中的恢復(fù)（recovery）刨沦。為了保護(hù)節(jié)點(diǎn)并且也允許恢復(fù)進(jìn)行，分配決定器讓集群進(jìn)行等待膘怕，然后在下一個(gè)迭代中再重試把shard分配給同一個(gè)節(jié)點(diǎn)
一旦我們做出了primary shard將分配到哪個(gè)節(jié)點(diǎn)的決定想诅，這個(gè)shard的狀態(tài)就被標(biāo)注為"initializing"（正在初始化），并且這個(gè)決定會(huì)通過(guò)一個(gè)modified ClusterState廣播到集群中所有節(jié)點(diǎn)岛心，然后集群中所有節(jié)點(diǎn)都將應(yīng)用這個(gè)ClusterState
在shard狀態(tài)被標(biāo)注為"initializing"后来破，會(huì)進(jìn)行如下動(dòng)作。如下面動(dòng)圖所示
被選中的節(jié)點(diǎn)探測(cè)到它自己被分配了一個(gè)新的shard
在被選中的節(jié)點(diǎn)上忘古，將創(chuàng)建一個(gè)空的lucene索引(譯注：每一個(gè)shard都是一個(gè)獨(dú)立的lucene索引)徘禁，創(chuàng)建完成后被選中的節(jié)點(diǎn)向master發(fā)送“shard已經(jīng)就緒”的通知
master收到通知后，master需要把被選中的節(jié)點(diǎn)上shard的狀態(tài)標(biāo)注"started"髓堪，為了做到這一點(diǎn)送朱，master發(fā)送一個(gè)modified ClusterState
被選中的節(jié)點(diǎn)收到master發(fā)送的modified ClusterState，于是被選中的節(jié)點(diǎn)激活此shard干旁，并把shard的狀態(tài)標(biāo)注為"started"
因?yàn)檫@是一個(gè)primary shard驶沼，自此，我們就可以向其索引文檔了
正如你所見争群，所有的通信都是通過(guò)modified ClusterState進(jìn)行的回怜。一旦這個(gè)周期結(jié)束，master會(huì)執(zhí)行re-route换薄，重新評(píng)估shard分配玉雾，有可能對(duì)先前迭代中被抑制的內(nèi)容做出決定
現(xiàn)在，master要分配剩下的replica shard c0了轻要，這也是由分配決定器來(lái)作決定的复旬。分配決定器必須得等到包含primary shard的節(jié)點(diǎn)把primary shard的狀態(tài)標(biāo)注為"started"后，才能開始分配replica shard c0伦腐。如下圖所示赢底，primary shard c0已經(jīng)在node2上分配完成且狀態(tài)已經(jīng)被標(biāo)注為"started"，現(xiàn)在master需要分配剩下的replica shard c0了柏蘑，replica shard c0的狀態(tài)是unassigned
此時(shí)幸冻，會(huì)進(jìn)行重新平衡，過(guò)程就和前面所描述的一樣咳焚，重新平衡的目的是使數(shù)據(jù)在集群中是平衡的洽损。在當(dāng)前例子中，集群將把replica shard c0分配到node3革半，以使得集群是平衡的碑定。最終流码，集群中每個(gè)節(jié)點(diǎn)包含3個(gè)shard。如下面兩幅圖所示延刘，重新平衡把replilca shard c0分配給了node node3
上例子中漫试，我們只是創(chuàng)建了一個(gè)空的replica shard，這比碘赖，假設(shè)說(shuō)已經(jīng)存在某個(gè)狀態(tài)為"started"且包含數(shù)據(jù)的primary shard驾荣，要簡(jiǎn)單。對(duì)于這種情況普泡，我們必須得確保新的replica shard包含有和primary shard同樣的數(shù)據(jù)播掷。如下面兩幅圖所示，第一幅撼班，master把需要初始化replica shard c0的ClusterState廣播到整個(gè)集群歧匈；第二幅，node2探測(cè)到自己被分配了一個(gè)新的shard
當(dāng)replica shard分配完成后砰嘁，需要理解的很重要的一點(diǎn)是件炉，我們會(huì)從primary shard復(fù)制所有缺失的數(shù)據(jù)到replica shard，數(shù)據(jù)復(fù)制完成后矮湘，master才會(huì)把replica shard的狀態(tài)標(biāo)注為"started"妻率，并且向集群中廣播一個(gè)新的ClusterState。如下面動(dòng)圖所示
場(chǎng)景二板祝、 是時(shí)候移動(dòng)shard了
有時(shí)你的集群可能需要在集群內(nèi)部移動(dòng)已經(jīng)存在的shard。這可能會(huì)有很多原因
1. 用戶配置
這方面最常見的一個(gè)例子就是Hot/Warm配置走净，當(dāng)數(shù)據(jù)老化時(shí)券时，會(huì)根據(jù)Hot/Warm配置把數(shù)據(jù)移動(dòng)到訪問速度較慢的磁盤上。如下圖所示
2. 用戶使用命令顯式移動(dòng)shard
用戶通過(guò)cluster re-route命令來(lái)使得elasticsearch將shard從一個(gè)地方移到另一個(gè)地方
3. 磁盤相關(guān)的配置
存在與磁盤使用空間相關(guān)的以下兩個(gè)設(shè)置伏伯，分配決定器會(huì)根據(jù)這些設(shè)置的閾值來(lái)移動(dòng)shard
cluster.routing.allocation.disk.watermark.low
cluster.routing.allocation.disk.watermark.high
超過(guò)低水位閾值時(shí)橘洞，elasticsearch將阻止我們寫入新的shard。同樣说搅，超過(guò)高水位閾值時(shí)炸枣，elasticsearch會(huì)把此節(jié)點(diǎn)上shard重新分配到其他節(jié)點(diǎn)上，直到當(dāng)前節(jié)點(diǎn)的磁盤占用低于高水位閾值弄唧。如下圖所示
4. 集群添加節(jié)點(diǎn)
可能你的集群已經(jīng)達(dá)到最大容量适肠，于是你添加了一個(gè)新的節(jié)點(diǎn)，此時(shí)elasticsearch會(huì)重新平衡（rebalance）整個(gè)集群候引。如下圖所示
Shard可能會(huì)包含很多G的數(shù)據(jù)侯养，因此，在集群間移動(dòng)它們可能產(chǎn)生極大的性能影響澄干。為使這個(gè)過(guò)程對(duì)用戶透明逛揩，移動(dòng)shard必須在后臺(tái)運(yùn)行柠傍。也就是盡可能的降低移動(dòng)shard對(duì)elasticsearch其他方面的影響。為此辩稽，引入了一個(gè)抑制參數(shù)（indices.recovery.max_bytes_per_sec/cluster.routing.allocation.node_concurrent_recoveries) ）惧笛，以保證移動(dòng)shard期間依然可以繼續(xù)向這些shard索引數(shù)據(jù)。如下圖所示
記壮研埂：elasticsearch的所有數(shù)據(jù)都是通過(guò)Lucene存儲(chǔ)的患整。Lucene使用被稱為segment的一組文件來(lái)存儲(chǔ)一組倒排索引。給定的tokens/words時(shí)炭懊，倒排索引結(jié)構(gòu)可以方便的告訴你這些tokens/words包含在哪些文檔中并级，出現(xiàn)在文檔中的什么位置。當(dāng)Lucene索引文檔時(shí)侮腹，文檔暫存于內(nèi)存中的indexing buffer嘲碧。當(dāng)indexing buffer滿或，elasticsearch發(fā)出refresh操作（從而引發(fā)lucene flush）時(shí)父阻，indexing buffer中的數(shù)據(jù)就被強(qiáng)制寫入被稱為segment的倒排索引中愈涩。如下圖所示
隨著我們繼續(xù)索引文檔，我們會(huì)用同樣的方式創(chuàng)建新的segment加矛。關(guān)于segment履婉，一個(gè)重要的事情就是segment是不可變的（immutable）。這意味著斟览，一旦寫了一個(gè)segment毁腿，這個(gè)segment就永遠(yuǎn)不會(huì)改變了。如果你發(fā)出刪除或任何改變苛茂，這些動(dòng)作將發(fā)生在新的segment上已烤，在新的segment上同樣發(fā)生合并過(guò)程。如下圖所示
既然數(shù)據(jù)是存儲(chǔ)在內(nèi)存的妓羊，理論上在數(shù)據(jù)提交到segment文件之前（譯注：即使已寫入segment也可能會(huì)丟失胯究，因?yàn)閟egment寫入filesystem時(shí)，只是寫入了內(nèi)存即filesystem cache躁绸，只有調(diào)用filesystem的fsync后裕循，內(nèi)容才真正寫入了磁盤。而出于性能考慮净刮，filesystem是周期性而不是實(shí)時(shí)的調(diào)用fsync的）剥哑，數(shù)據(jù)是有可能丟失的。elasticsearch使用transaction log來(lái)緩解這種情況庭瑰。每當(dāng)文檔索引進(jìn)Lucene時(shí)星持，文檔也會(huì)被寫入transaction log。如下圖所示
Transaction log是順序?qū)懭氲牡穑詈笠粋€(gè)請(qǐng)求位于文件的末尾督暂。借助transaction log揪垄，我們就可以恢復(fù)尚未寫入Lucene中的文檔。elasticsearch的持久化模型如下圖所示
生成segment時(shí)可能并未執(zhí)行fsync逻翁，此時(shí)segment會(huì)暫存于filesystem cache內(nèi)存中饥努，OS會(huì)暫緩刷新數(shù)據(jù)到磁盤。這么作是出于性能原因八回，因此酷愧，必須要把filesystem cache內(nèi)存中的segment寫入到磁盤，同時(shí)清空transaction log缠诅，這個(gè)工作是通過(guò)elasticsearch flush來(lái)完成的
當(dāng)發(fā)出elasticsearch flush（從而引發(fā)lucene commit）命令時(shí)溶浴，會(huì)做兩件事情
把indexing buffer中的數(shù)據(jù)寫入磁盤，從而生成一個(gè)新的segment
遍歷所有的segment文件管引，請(qǐng)求filesystem使用fsync將所有segment寫入磁盤
執(zhí)行elasticsearch flush就把內(nèi)存中所有數(shù)據(jù)（即indexing buffer中的數(shù)據(jù)以及filesystem cache內(nèi)存中的segment）士败，統(tǒng)統(tǒng)寫入了磁盤，并且清空了transaction log褥伴，這確保我們不會(huì)丟失任何數(shù)據(jù)谅将。對(duì)于重新安置（relocation）shard，如果我們捕獲并保存一組給定的segment重慢，則我們得到一個(gè)時(shí)間點(diǎn)一致且數(shù)據(jù)不可變的數(shù)據(jù)快照
譯注：參考Elasticsearch: 權(quán)威指南-->持久化變更了解文檔寫入過(guò)程饥臂。梗概總結(jié)如下圖所示
以下面動(dòng)圖為例，集群想要把node4上的a0移動(dòng)到node5似踱，于是master標(biāo)注a0為正在從node4重新安置到node5隅熙，node5收到請(qǐng)求后在node5上初始化一個(gè)shard。對(duì)這個(gè)行為核芽，有一個(gè)非常重要的事情需要注意猛们，當(dāng)進(jìn)行重新平衡時(shí)，看起來(lái)replica shard正在從node4移動(dòng)到node5狞洋，但事實(shí)上，重新安置shard時(shí)總是從primary shard復(fù)制數(shù)據(jù)的（即：node1上的a0）
以下面動(dòng)圖為例绿店，我們來(lái)演示“把node1上的primary shard重新安置到node5”吉懊。記住我們前面所說(shuō)的兩種數(shù)據(jù)存儲(chǔ)機(jī)制，transaction log和lucene segment
此例中node5是空節(jié)點(diǎn)假勿，node1上有primary shard借嗽。全部步驟如下
master向node5發(fā)送了一個(gè)modified ClusterState，master要求node5初始化一個(gè)新的shard
node5探測(cè)到自己被分配了一個(gè)新的shard
node5向node1（node1上有primary shard）發(fā)送請(qǐng)求转培，請(qǐng)求開始恢復(fù)過(guò)程
node1收到node5的請(qǐng)求恶导，然后，node1驗(yàn)證它自己知道node5發(fā)送的請(qǐng)求
node1驗(yàn)證通過(guò)浸须，于是在node1上惨寿，elasticsearch固定transaction log以防止其被刪除并捕獲索引的segment快照邦泄，確保我們捕獲了shard中的所有數(shù)據(jù)
node1將segment數(shù)據(jù)發(fā)送到node5上的目標(biāo)文件
在node5重放node1的transaction log，這會(huì)確保數(shù)據(jù)復(fù)制期間新索引進(jìn)來(lái)的文檔也能復(fù)制進(jìn)入到node5上的目標(biāo)文件
node1發(fā)送“數(shù)據(jù)恢復(fù)已完成”給node5
node5告知master“node5上的shard已經(jīng)就緒”
master發(fā)送modified ClusterState到node5裂垦，激活shard顺囊，將shard狀態(tài)標(biāo)注為"started"。同時(shí)蕉拢，master刪除掉node1上的源shard
上面這一切都在后臺(tái)發(fā)生特碳，因此整個(gè)過(guò)程中你依然可以向primary shard中索引數(shù)據(jù)。在這個(gè)過(guò)程中晕换，如果確實(shí)又向primary shard中索引了新的數(shù)據(jù)午乓，那么，這些新的數(shù)據(jù)并不包含在步驟5所捕獲快照中闸准，但這沒有關(guān)系益愈，因?yàn)橥ㄟ^(guò)步驟7重放node1的transaction log就可以確保這些新的數(shù)據(jù)也被復(fù)制進(jìn)入了新的shard
現(xiàn)在問題來(lái)了，何時(shí)才能停下恕汇？復(fù)制過(guò)程中可能依然有新索引的文檔進(jìn)入primary shard腕唧，這意味著transaction log是一直增長(zhǎng)的。在1.x中瘾英，我們的措施是鎖定transaction log枣接，從鎖定點(diǎn)開始，所有再進(jìn)來(lái)的請(qǐng)求都被阻塞缺谴，直到重放transaction log完成
在2.x/5.x中但惶，我們作的更好。一旦我們開始重新安置（relocation）湿蛔，primary shard會(huì)把所有的索引操作發(fā)送到新的primary shard（位于node5上）膀曾。因?yàn)槲覀冎牢覀兒螘r(shí)捕獲的lucene快照，我們也知道shard是何時(shí)被初始化的阳啥，于是我們就確切的知道需要重放transaction log中的哪些數(shù)據(jù)
一旦恢復(fù)完成添谊，目標(biāo)節(jié)點(diǎn)（target node）給master發(fā)送通知，告知master“shard都已就緒”察迟。master處理請(qǐng)求斩狱，復(fù)制剩余的primary shard（譯注：因?yàn)橐粋€(gè)索引可能存儲(chǔ)多個(gè)primary shard），并激活shard扎瓶。然后所踊，源shard可以被移除了，這個(gè)過(guò)程一直重復(fù)概荷，直到重新平衡（rebalancing）完成
我們要考察的下一個(gè)場(chǎng)景是重啟整個(gè)集群。在這個(gè)場(chǎng)景中，我們并不處理激活的segment继薛，而是在每個(gè)節(jié)點(diǎn)上找到本地?cái)?shù)據(jù)修壕。重啟整個(gè)集群可能會(huì)發(fā)生在 維護(hù)周期，升級(jí)以及與計(jì)劃中維護(hù)相關(guān)的任何事情
這里惋增，master被選舉出來(lái)叠殷，然后會(huì)新建一個(gè)ClusterState或者從磁盤恢復(fù)一個(gè)ClusterState。現(xiàn)在我們有了一個(gè)待分配的shard的列表诈皿，這些shard第一次被分配時(shí)林束，分配決定器可以把它們分配到任何一個(gè)節(jié)點(diǎn)上，但稽亏，現(xiàn)在不能再隨便分配了壶冒。這意味著，我們需要找到這些數(shù)據(jù)截歉，并確保我們能打開這些我們之前創(chuàng)建的lucene索引胖腾。如下圖所示
為了做到這點(diǎn)（找到數(shù)據(jù)并打開之前創(chuàng)建的索引），master在集群中每一個(gè)節(jié)點(diǎn)上分配一個(gè)primary shard瘪松，且要求此primary shard返回磁盤上的所有內(nèi)容咸作。這意味著，我們物理上打開segment宵睦，然后通過(guò)確認(rèn)一個(gè)shard副本來(lái)響應(yīng)master记罚。這時(shí)，master決定哪個(gè)節(jié)點(diǎn)將得到primary shard壳嚎。在5.x中桐智，我們會(huì)優(yōu)先選擇之前的primary shard（這是一個(gè)優(yōu)化）。如下圖所示
在下面的例子中烟馅，我們可以看到说庭，node1上的a0之前是primary shard，但郑趁，其他任何副本都可能變成primary shard刊驴。在這個(gè)例子中，node4上的shard被標(biāo)注為"initializing"寡润，但缺脉，不同之處在于，這一次我們要使用已經(jīng)存在的數(shù)據(jù)悦穿，并且可以檢查節(jié)點(diǎn)上的lucene索引來(lái)驗(yàn)證lucene索引有效且可以打開。master會(huì)收到“shard已經(jīng)就緒”业踢、“shard已被分配”的通知栗柒，然后，master把這些shard的分配結(jié)果加入到集群狀態(tài)中。如下面動(dòng)圖所示
為了驗(yàn)證兩個(gè)shard上數(shù)據(jù)是一樣的瞬沦，我們會(huì)有一個(gè)復(fù)制過(guò)程太伊，這個(gè)過(guò)程和重新安置非常類似，不同之處在于因?yàn)樗衧hard副本都是從磁盤恢復(fù)得來(lái)的逛钻，這些shard可能已經(jīng)是匹配的了僚焦，因此可能無(wú)需傳輸shard。此鏈接詳細(xì)描述了這個(gè)過(guò)程曙痘。如下圖所示
因?yàn)閟egment就是獨(dú)立的lucene索引芳悲，大量索引文檔之后，非潮呃ぃ可能磁盤上的segment和其他節(jié)點(diǎn)上相同的segment并不一致名扛。有些segment用了更多資源，有些segment擁有煩人的鄰居（nosy neighbors）茧痒。如下圖所示
在v1.6之前肮韧，必須得復(fù)制所有segment。正是由于這些旺订，v1.6之前的恢復(fù)是很慢的弄企。我們必須得同步primary shard和replic shard，卻又不能使用本地?cái)?shù)據(jù)区拳。為了解決這個(gè)問題拘领，我們添加了sync_flush和sync_id。取不發(fā)生索引文檔的某個(gè)時(shí)刻劳闹，使用一個(gè)唯一標(biāo)識(shí)符來(lái)表示捕獲的信息院究，確保同一個(gè)shard的各個(gè)副本是完全一致的。因此本涕，當(dāng)我們進(jìn)行恢復(fù)時(shí)业汰，我們發(fā)送sync_id標(biāo)識(shí)符，如果標(biāo)識(shí)符一致菩颖，則無(wú)需復(fù)制文件了样漆，就可以重用老的副本。因?yàn)閘ucene中的segment是不可變的晦闰，這只對(duì)非激活的shard有效放祟。注意：下圖展示的是不同節(jié)點(diǎn)上的同一個(gè)shard，復(fù)制的數(shù)字就是發(fā)生的變化
場(chǎng)景四呻右、 單個(gè)節(jié)點(diǎn)丟失（node3丟失）
在下圖中跪妥，node3從集群中被移除了，node3上存儲(chǔ)有b1的primary shard声滥。此時(shí)眉撵，首先立即采取的步驟是master把當(dāng)前位于node1上的b1的replica shard提升為primary shard。b1所在索引的健康狀態(tài)以及集群的健康狀態(tài)變成黃色，因?yàn)榇嬖谀硞€(gè)shard備份并沒有全部被分配（shard所有備份的數(shù)量是用戶在定義索引時(shí)指定的）纽疟。因此罐韩，master要嘗試在剩下的某個(gè)節(jié)點(diǎn)上再分配一個(gè)新的b1的replica shard。如果node3是由于暫時(shí)的網(wǎng)絡(luò)故障（或JVM GC引起的長(zhǎng)時(shí)間STW）所導(dǎo)致污朽，且散吵，在網(wǎng)絡(luò)故障恢復(fù)和節(jié)點(diǎn)再回到集群前，并未向shard中索引任何文檔蟆肆，則在node3缺席的這段時(shí)間內(nèi)矾睦，在某個(gè)剩下的節(jié)點(diǎn)上重新復(fù)制一個(gè)新的b1的replica shard就純屬是浪費(fèi)資源。如下面動(dòng)圖所示
在v1.6中颓芭，引入了基于index（per-index）設(shè)置來(lái)解決這個(gè)問題（index.unassigned.node_left.delayed_timeout顷锰，默認(rèn)1分鐘）。當(dāng)node3離開時(shí)亡问，會(huì)先延遲此處指定的時(shí)長(zhǎng)再進(jìn)行重新分配shard官紫。如果在此時(shí)長(zhǎng)之前node3回來(lái)了，則考察primary shard較node3上的shard是否發(fā)生了變化州藕，若在此期間束世，primary shard并未有任何變化，則node3上的shard就被指定為replica shard床玻；若primary shard發(fā)生了變化毁涉，則丟棄node3上的shard，并且重新從primary shard復(fù)制shard到node3
在v2.0中锈死，引入了一個(gè)改進(jìn)贫堰，如果node3在延遲超時(shí)之后才回來(lái)，對(duì)于位于node3上且依然匹配primary shard的任何shard（使用sync_id標(biāo)識(shí)符來(lái)決定匹配與否）待牵，即使重新復(fù)制已經(jīng)開始了其屏，這些重新復(fù)制過(guò)程也會(huì)被停止，然后缨该，node3上的這些shard被指定為replica shard偎行。如下圖所示
