點(diǎn)擊上方“IT那活兒”公眾號(hào)，關(guān)注后了解更多內(nèi)容，不管IT什么活兒，干就完了?。?！

1.1 關(guān)于分片

elasticsearch分片可以理解為數(shù)據(jù)的容器。

elasticsearch的索引文檔存儲(chǔ)在分片中，然后分片分配到集群中的節(jié)點(diǎn)上。當(dāng)集群擴(kuò)容或縮小，Elasticsearch 將會(huì)自動(dòng)在節(jié)點(diǎn)間遷移分片，以使集群保持平衡。這類似于 MySql 的分庫(kù)分表，只不過(guò) Mysql 分庫(kù)分表需要借助第三方組件而 ES 內(nèi)部自身實(shí)現(xiàn)了此功能。

分片分為主分片和副本分片，在索引寫(xiě)入時(shí)，新文檔首先被索引進(jìn)主分片然后再同步到其它所有的副本分片。副本分片可以服務(wù)于讀請(qǐng)求，如果你的索引也如常見(jiàn)的那樣是偏向查詢使用的，那你可以通過(guò)增加副本的數(shù)目來(lái)提升查詢性能。

與幾乎所有的分布式組件存儲(chǔ)數(shù)據(jù)一樣，如果主分片和所有副本的分片都失效了，那么這部分?jǐn)?shù)據(jù)也意味著丟失了。本文涉及的索引副本數(shù)為1，也就是索引的所有分片存在1個(gè)主分片和1個(gè)副本分片。

1.2 故障問(wèn)題

此次elasticsearch故障是因?yàn)閚ode04節(jié)點(diǎn)數(shù)據(jù)盤(pán)損壞，原本集群一個(gè)節(jié)點(diǎn)的一塊數(shù)據(jù)盤(pán)損壞，因?yàn)榉制懈北镜年P(guān)系，并不會(huì)對(duì)數(shù)據(jù)的完整性造成威脅，如上文描述，主分片失效后，副本分片會(huì)成為主分片，并在后續(xù)會(huì)重新生成一份副本分片，達(dá)到索引的主副分片要求。

當(dāng)異常節(jié)點(diǎn)恢復(fù)啟動(dòng)完成后，丟失副本的分片會(huì)成為主分片，然后進(jìn)行同步生成新的副本分片，但是在同步的過(guò)程中，另一個(gè)節(jié)點(diǎn)node01出現(xiàn)服務(wù)崩潰，最終定位也損壞了一塊硬盤(pán)，短時(shí)間內(nèi)同時(shí)損壞不同節(jié)點(diǎn)的2塊硬盤(pán)，對(duì)于副本為1的分片來(lái)說(shuō)，就有較大的概率丟失數(shù)據(jù)了，事實(shí)證明確實(shí)有索引存在數(shù)據(jù)丟失的情況，好在node01的盤(pán)還部分可讀，于是我們嘗試讀取恢復(fù)了一部分索引的數(shù)據(jù)，詳細(xì)步驟如下。 

2.1 某日elasticsearch集群node04節(jié)點(diǎn)服務(wù)崩潰，檢查發(fā)現(xiàn)磁盤(pán)損壞，硬件進(jìn)行了磁盤(pán)更換和掛載，node04節(jié)點(diǎn)啟動(dòng)后集群正在同步數(shù)據(jù)。

2.2 此時(shí)node01節(jié)點(diǎn)服務(wù)出現(xiàn)崩潰，嘗試啟動(dòng)node01節(jié)點(diǎn)的服務(wù)，發(fā)現(xiàn)elasticsearch無(wú)法拉起，檢查日志發(fā)現(xiàn)加載過(guò)程中就直接關(guān)閉了，完成不了啟動(dòng)。

檢查messages發(fā)現(xiàn)sde盤(pán)出現(xiàn)讀取錯(cuò)誤，懷疑磁盤(pán)問(wèn)題，為了快速恢復(fù)業(yè)務(wù)，決定先注釋sde盤(pán)的/data04目錄，再次啟動(dòng)可以拉起服務(wù)了。

報(bào)錯(cuò)信息：

對(duì)elasticsearch.yml配置修改：

2.3 經(jīng)過(guò)較為漫長(zhǎng)的恢復(fù)后，發(fā)現(xiàn)仍然有3個(gè)索引處于red狀態(tài)，可以確認(rèn)這部分索引已經(jīng)丟失了主分片和副本分片，也即數(shù)據(jù)丟失了。

2.4 對(duì)此3個(gè)索引進(jìn)行indices檢查，確認(rèn)索引分片名分別為：

red   open  eopstat-2022.03.03                                na8D2ItQQt2aY1M8Mka_Lg

red   open  eopstat-2022.03.12                                kLybkgdoSluZTpcLnnraeQ

red   open  eopstat-2022.03.13                                4uvJV5zeQ6az7cUBhXyhbQ

2.5 因sde磁盤(pán)尚未完全損壞，/data04目錄部分?jǐn)?shù)據(jù)是可以讀寫(xiě)的，所以我們考慮將以上三個(gè)索引在/data04上的分片先備份出來(lái)，然后更換磁盤(pán)后恢復(fù)，以達(dá)到修復(fù)數(shù)據(jù)的目的。

2.6 備份過(guò)程中發(fā)現(xiàn)某索引報(bào)錯(cuò)padding with zeros，估計(jì)磁盤(pán)上這個(gè)索引的數(shù)據(jù)已經(jīng)損壞了，但是另外的索引備份正常。

2.7 我們將其備份至/tmp目錄下，待磁盤(pán)重新更換后將其恢復(fù)。

2.8 然后對(duì)node01節(jié)點(diǎn)進(jìn)行磁盤(pán)更換和重新掛載，再將兩個(gè)備份的分片恢復(fù)至原目錄/data04/es/nodes/0/indices。

2.9 恢復(fù)完成后，我們將node01節(jié)點(diǎn)配置還原，將/data04目錄加入，然后再進(jìn)行es服務(wù)的重啟。

2.10 待完全啟動(dòng)后，發(fā)現(xiàn)原本狀態(tài)為red的索引2022.03.13/12已變?yōu)閥ellow，也就表示主分片正常了，正在恢復(fù)副本分片。

2.11 恢復(fù)完成后，檢查索引狀態(tài)，發(fā)現(xiàn)已經(jīng)恢復(fù)為green了，數(shù)據(jù)恢復(fù)完成。

此次故障雖然恢復(fù)，但是部分索引的數(shù)據(jù)依舊是主副都丟失了，只能進(jìn)行清理，無(wú)法恢復(fù)了。所以此恢復(fù)方法也只能建立在原數(shù)據(jù)盤(pán)數(shù)據(jù)部分依舊可讀的前提下進(jìn)行，如果兩個(gè)數(shù)據(jù)盤(pán)全部徹底損壞，也基本是不具備從系統(tǒng)層面進(jìn)行恢復(fù)的，只能找專業(yè)人士從磁盤(pán)底層進(jìn)行嘗試了，這也是本文恢復(fù)方法的局限性。

另外針對(duì)老舊服務(wù)器搭建的集群，比如本文中的節(jié)點(diǎn)服務(wù)器其實(shí)服役年限都超過(guò)8年了，我們還是強(qiáng)烈適當(dāng)增加集群的冗余配置，比如配置副本數(shù)為2，也即一主兩副的配置，從而降低因?yàn)橛布收显斐傻臄?shù)據(jù)損失的風(fēng)險(xiǎn)。