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

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

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

1、懸掛索引的定義

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

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

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

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

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

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

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

2.1 識別問題

首先，我使用如下命令確認(rèn)集群節(jié)點狀態(tài)，發(fā)現(xiàn)確實有一個數(shù)據(jù)節(jié)點丟失。通過重啟故障節(jié)點，虛擬機恢復(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ù)的機制，用于盡可能保留和恢復(fù)數(shù)據(jù)。

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

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

2.3 診斷原因

通過如下命令診斷未分配分片的具體原因，發(fā)現(xiàn)是因為之前的主分片副本已經(jīng)在集群中的其他節(jié)點上找不到了。

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個主分片因為被識別為懸掛索引并嘗試導(dǎo)入而未被分配。盡管有導(dǎo)入嘗試，但因為在集群的任何節(jié)點上都找不到這個分片的有效副本，導(dǎo)致這個分片無法被正確分配到任何節(jié)點上。

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

3、懸掛索引重要的操作和注意事項

3.1. 識別懸掛索引

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

GET?/_dangling

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

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

3.2 恢復(fù)懸掛索引

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

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

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

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

3.3 刪除懸掛索引

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

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

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

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

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

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

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

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

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

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

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

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

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

5、結(jié)語

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

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

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

希望本指南能幫助讀者在未來遇到類似問題時，能夠更加從容不迫地應(yīng)對，保障數(shù)據(jù)的完整性和可用性。文章來源地址http://www.zghlxwxcb.cn/news/detail-850128.html

到了這里，關(guān)于Elasticsearch 懸掛索引分析和自己的一點見解的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！