在 Elasticsearch 的實(shí)戰(zhàn)中，懸掛索引是一個(gè)既常見又容易引起困擾的概念。

今天，我將分享一次處理集群狀態(tài)為RED，原因?yàn)?strong>DANGLING_INDEX_IMPORTED 的實(shí)戰(zhàn)經(jīng)驗(yàn)，深入探討懸掛索引的定義、產(chǎn)生原因、管理方法，以及如何有效處理它們，確保讀者能夠明白并解決自己面臨的問題。

值得一提的是，類似問題恰巧是某企業(yè)的面試題。

1、懸掛索引的定義

當(dāng) Elasticsearch 集群的某個(gè)節(jié)點(diǎn)因故障（如宕機(jī)）暫時(shí)離開集群，而該節(jié)點(diǎn)上存有的某些索引分片在集群的其他節(jié)點(diǎn)上沒有副本時(shí)，這些索引分片在節(jié)點(diǎn)重新加入集群后會(huì)被標(biāo)記為“懸掛”狀態(tài)。

簡而言之，懸掛索引（dangling index）是存在于節(jié)點(diǎn)上、但未被集群元數(shù)據(jù)所識(shí)別的索引分片，這意味著它們不會(huì)參與到集群的正常索引操作中。

讓我們不僅聯(lián)想到十多年前學(xué)過的一個(gè)C語言的知識(shí)點(diǎn)：野指針。

野指針（Dangling Pointer）是指向“不可預(yù)知”內(nèi)存區(qū)域的指針。具體來說，當(dāng)指針變量在釋放了其所指向的內(nèi)存后未被設(shè)為 NULL，或者是指向了一個(gè)已經(jīng)被回收利用的內(nèi)存塊時(shí)，這個(gè)指針就變成了野指針。

使用野指針訪問或操作內(nèi)存是危險(xiǎn)的，因?yàn)樗赡軙?huì)導(dǎo)致不可預(yù)知的行為或程序崩潰，類似于懸掛索引在集群中的狀態(tài)，指向了集群中不存在的元數(shù)據(jù)。

2、遇到的問題及解決步驟

之前遇到過 Elasticsearch 集群狀態(tài)為RED，原因是出現(xiàn)了大量UNASSIGNED的分片，具體來說是DANGLING_INDEX_IMPORTED的情況。

2.1 識(shí)別問題

首先，我使用如下命令確認(rèn)集群節(jié)點(diǎn)狀態(tài)，發(fā)現(xiàn)確實(shí)有一個(gè)數(shù)據(jù)節(jié)點(diǎn)丟失。通過重啟故障節(jié)點(diǎn)，虛擬機(jī)恢復(fù)，但分片仍然未分配。

GET?/_cat/nodes

2.2 深入分析

進(jìn)一步使用如下命令查看未分配的分片，發(fā)現(xiàn)都標(biāo)記為了 DANGLING_INDEX_IMPORTED。

GET?/_cat/shards?h=index,shard,prirep,state,unassigned.reason

返回結(jié)果：

index1????????????0?p?UNASSIGNED???DANGLING_INDEX_IMPORTED
index2????????????0?p?UNASSIGNED???DANGLING_INDEX_IMPORTED
index3????????????0?p?UNASSIGNED???DANGLING_INDEX_IMPORTED

上面提到的 DANGLING_INDEX_IMPORTED 就是前文提及的懸垂索引導(dǎo)入標(biāo)記。

DANGLING_INDEX_IMPORTED 標(biāo)記表示集群已經(jīng)嘗試恢復(fù)這些原本丟失的索引分片，將它們重新集成回集群中。這是一種Elasticsearch集群自我恢復(fù)的機(jī)制，用于盡可能保留和恢復(fù)數(shù)據(jù)。

然而，這種自動(dòng)導(dǎo)入懸掛索引的操作可能會(huì)帶來數(shù)據(jù)完整性和一致性的風(fēng)險(xiǎn)，因?yàn)闊o法保證這些索引的數(shù)據(jù)是最新的或完整的。

因此，在Elasticsearch的較新版本（7.9之后版本，不含7.9）中，建議使用專門的懸掛索引API來手動(dòng)管理和恢復(fù)這些索引，以確保數(shù)據(jù)的安全性和一致性。

2.3 診斷原因

通過如下命令診斷未分配分片的具體原因，發(fā)現(xiàn)是因?yàn)橹暗闹鞣制北疽呀?jīng)在集群中的其他節(jié)點(diǎn)上找不到了。

GET?/_cluster/allocation/explain?pretty

返回信息類似如下：

{
??"index"?:?"XXXX",
??"shard"?:?0,
??"primary"?:?true,
??"current_state"?:?"unassigned",
??"unassigned_info"?:?{
????"reason"?:?"DANGLING_INDEX_IMPORTED",
????"at"?:?"2021-05-03T11:58:14.859Z",
????"last_allocation_status"?:?"no_valid_shard_copy"
??},
??"can_allocate"?:?"no_valid_shard_copy",
??"allocate_explanation"?:?"cannot?allocate?because?a?previous?copy?of?the?primary?shard?existed?but?can?no?longer?be?found?on?the?nodes?in?the?cluster",

這段信息表明：

XXXX索引的第0個(gè)主分片因?yàn)楸蛔R(shí)別為懸掛索引并嘗試導(dǎo)入而未被分配。盡管有導(dǎo)入嘗試，但因?yàn)樵诩旱娜魏喂?jié)點(diǎn)上都找不到這個(gè)分片的有效副本，導(dǎo)致這個(gè)分片無法被正確分配到任何節(jié)點(diǎn)上。

這可能指向了數(shù)據(jù)丟失或數(shù)據(jù)一致性問題，需要進(jìn)一步的手動(dòng)干預(yù)和數(shù)據(jù)恢復(fù)操作。

問題參見：https://t.zsxq.com/18SWm6kxF

3、懸掛索引重要的操作和注意事項(xiàng)

3.1. 識(shí)別懸掛索引

使用如下命令，可以列出所有的懸掛索引。

GET?/_dangling

此命令將返回索引名稱、索引UUID、創(chuàng)建時(shí)間以及所在節(jié)點(diǎn)等信息，如下所示：

{
??"dangling_indices":?[
???{
????"index_name":?"my-index-000001",
????"index_uuid":?"zmM4e0JtBkeUjiHD-MihPQ",
????"creation_date_millis":?1589414451372,
????"node_ids":?[
??????"pL47UN3dAb2d5RCWP6lQ3e"
????]
???}
??]
}

3.2 恢復(fù)懸掛索引

通過如下命令恢復(fù)指定的懸掛索引。

這一步驟要求明確接受可能的數(shù)據(jù)丟失，因?yàn)?Elasticsearch 無法確定懸掛索引的數(shù)據(jù)是否是最新的。

POST?/_dangling/<index-uuid>?accept_data_loss=true

這里 index-uuid 就是 3.1 小節(jié)返回的 index_uuid。

3.3 刪除懸掛索引

使用如下API可以通過指定其UUID來刪除一個(gè)懸掛索引，而UUID可以通過使用列出懸掛索引的API找到。

DELETE?/_dangling/<index-uuid>?accept_data_loss=true

這個(gè)操作需要在Elasticsearch安全特性啟用的情況下?lián)碛泄芾砑旱臋?quán)限。

簡而言之，這個(gè)API提供了一種方法，允許管理員在確認(rèn)數(shù)據(jù)丟失的風(fēng)險(xiǎn)后，清理集群中未被識(shí)別為當(dāng)前部分的懸掛索引。

3.4 ?自動(dòng)化腳本恢復(fù)

如果存在大量懸掛索引，可以編寫腳本自動(dòng)化處理恢復(fù)操作。

3.5 檢查集群狀態(tài)

完成恢復(fù)操作后，需檢查集群狀態(tài)以確保數(shù)據(jù)的完整性和集群的健康。

4、避免懸掛索引的預(yù)防措施

• 確保所有節(jié)點(diǎn)正確配置并加入集群。

• 在節(jié)點(diǎn)離開集群前，正確移除所有索引。

• 避免手動(dòng)修改 Elasticsearch 數(shù)據(jù)路徑，以防產(chǎn)生懸掛索引。

• 刪除大量索引時(shí)需確保所有集群節(jié)點(diǎn)均在線，以避免產(chǎn)生懸掛索引。

5、結(jié)語

通過對Elasticsearch中懸掛索引問題的深入探討與解決，我們不僅增強(qiáng)了對集群管理的理解，也學(xué)會(huì)了如何應(yīng)對潛在的數(shù)據(jù)一致性風(fēng)險(xiǎn)。

本次實(shí)戰(zhàn)經(jīng)歷強(qiáng)調(diào)了預(yù)防、診斷和恢復(fù)懸掛索引的重要策略，提醒我們在集群運(yùn)維過程中必須保持警惕，采取適當(dāng)措施以維護(hù)集群的健康狀態(tài)。

正確的集群管理實(shí)踐和對懸掛索引的有效處理，是確保Elasticsearch集群穩(wěn)定運(yùn)行、數(shù)據(jù)安全的關(guān)鍵。

希望本指南能幫助讀者在未來遇到類似問題時(shí)，能夠更加從容不迫地應(yīng)對，保障數(shù)據(jù)的完整性和可用性。

6、參考

[1] https://tomasz-gintowt.medium.com/elasticsearch-dangling-index-imported-64b008949074

[2] https://opster.com/guides/elasticsearch/how-tos/how-to-recover-dangling-indices/

[3] https://bigdataboutique.com/blog/dangling-indexes-in-elasticsearch-how-to-prevent-fix-and-recover-37bcea

[4] https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-gateway.html#dangling-indices

7 年+積累、 Elastic 創(chuàng)始人Shay Banon 等 15 位專家推薦的 Elasticsearch 8.X新書已上線

更短時(shí)間更快習(xí)得更多干貨！

和全球?近2000+?Elastic 愛好者一起精進(jìn)！

elastic6.cn——ElasticStack進(jìn)階助手

比同事?lián)屜纫徊綄W(xué)習(xí)進(jìn)階干貨！文章來源地址http://www.zghlxwxcb.cn/news/detail-844771.html