一場源于服務(wù)器遷移的數(shù)據(jù)災(zāi)難
正常的數(shù)據(jù)遷移可能使用備份導(dǎo)入導(dǎo)出的方式，我偏偏選擇了虛機(jī)的硬盤全盤更換咧擂，由于采用docker部署逞盆，所以數(shù)據(jù)遷移搞得有些肆無忌憚。由于新建節(jié)點上有一個節(jié)點有以前的同名index（這也是個大坑松申，以后再詳細(xì)講）云芦，導(dǎo)致沖突俯逾，同名index刪除后，一切正常的Shards 在新的機(jī)器上丟了2組舅逸，Cluster 狀態(tài)變成Red桌肴。開源軟件就是出現(xiàn)問題抓瞎，全靠google和自己折騰琉历，不然原廠怎么賣服務(wù)掙錢呢坠七？這個問題google也沒有啊，我得發(fā)個英文版出來旗笔。
圍繞該問題的各種探索彪置，都說最美的風(fēng)景在路上，現(xiàn)在回味起來都是滿滿的心流
網(wǎng)上總結(jié)了多種原因 蝇恶，我覺得最相關(guān)的是allocation拳魁。
- allocation的官方命令 就是強(qiáng)制讓ES去傳送一遍數(shù)據(jù)，結(jié)果提示源文件沒有找到艘包。
- allocation/explain 這個工具不錯的猛，列出了全部節(jié)點上的shard分布狀態(tài)和失敗的原因。 發(fā)現(xiàn)indices文件都在想虎，就是不能識別卦尊。跑到對應(yīng)的data目錄下，查看文件大小全部正常舌厨。
- 希望刪除unsigned shard 岂却，沒有找到官方的辦法。
-查詢發(fā)現(xiàn)已經(jīng)正常的shard上的數(shù)據(jù)仍然可讀裙椭，通過外部程序重新reindex一遍躏哩，結(jié)果仍然提示id 對應(yīng)的shard 沒有找到。
最終解決
經(jīng)過前面的折騰揉燃，基本明白：既然數(shù)據(jù)都在扫尺，只是數(shù)據(jù)同步出現(xiàn)了問題，那就隨便指定一個副本吧炊汤，大不了就重新導(dǎo)數(shù)據(jù)正驻。下面列出
//查找原因
GET /_cluster/allocation/explain
{
"index": "indexname",
"shard": 2,
"primary": true
}
//強(qiáng)制指定shard文件來源
POST /_cluster/reroute
{
"commands" : [
{
"allocate_stale_primary" : {
"index" : "indexname", "shard" : 2,
"node" : "Frt1jHV",
"accept_data_loss" : true
}
}
]
}
總結(jié)
數(shù)據(jù)備份非常重要，其實在動手前可以做磁盤快照抢腐，日彻檬铮可以做備份節(jié)點。
