一場源于服務器遷移的數(shù)據(jù)災難

正常的數(shù)據(jù)遷移可能使用備份導入導出的方式，我偏偏選擇了虛機的硬盤全盤更換，由于采用docker部署，所以數(shù)據(jù)遷移搞得有些肆無忌憚。由于新建節(jié)點上有一個節(jié)點有以前的同名index（這也是個大坑，以后再詳細講），導致沖突，同名index刪除后，一切正常的Shards 在新的機器上丟了2組，Cluster 狀態(tài)變成Red。開源軟件就是出現(xiàn)問題抓瞎，全靠google和自己折騰，不然原廠怎么賣服務掙錢呢？這個問題google也沒有啊，我得發(fā)個英文版出來。

圍繞該問題的各種探索，都說最美的風景在路上，現(xiàn)在回味起來都是滿滿的心流

網(wǎng)上總結了多種原因 ，我覺得最相關的是allocation。

• allocation的官方命令 就是強制讓ES去傳送一遍數(shù)據(jù)，結果提示源文件沒有找到。
• allocation/explain 這個工具不錯，列出了全部節(jié)點上的shard分布狀態(tài)和失敗的原因。 發(fā)現(xiàn)indices文件都在，就是不能識別。跑到對應的data目錄下，查看文件大小全部正常。
• 希望刪除unsigned shard ，沒有找到官方的辦法。
  -查詢發(fā)現(xiàn)已經(jīng)正常的shard上的數(shù)據(jù)仍然可讀，通過外部程序重新reindex一遍，結果仍然提示id 對應的shard 沒有找到。

最終解決

經(jīng)過前面的折騰，基本明白：既然數(shù)據(jù)都在，只是數(shù)據(jù)同步出現(xiàn)了問題，那就隨便指定一個副本吧，大不了就重新導數(shù)據(jù)。下面列出

//查找原因
GET /_cluster/allocation/explain
{
  "index": "indexname",
  "shard": 2,
  "primary": true
}
//強制指定shard文件來源
POST /_cluster/reroute
{
    "commands" : [
        {
            "allocate_stale_primary" : {
                "index" : "indexname", "shard" : 2,
                "node" : "Frt1jHV",
                "accept_data_loss" : true
            }
        }
    ]
}

總結

數(shù)據(jù)備份非常重要，其實在動手前可以做磁盤快照，日?？梢宰鰝浞莨?jié)點。