NameNode 重啟恢復(fù)數(shù)據(jù)的流程

我們都知道 NameNode 中存儲的是分布式存儲系統(tǒng)的元數(shù)據(jù)，在 NameNode 重啟之后，內(nèi)存的數(shù)據(jù)已經(jīng)丟失了的，所以需要重新加載數(shù)據(jù)。

這時候我們采用的方法是 FsImage 快照 + editslog 操作日志兩種結(jié)合的方法；

那它們是怎么結(jié)合的呢？換句話說，這兩種機(jī)制是通過什么聯(lián)系起來的呢？？

FsImage 和 editslog 的聯(lián)系

在內(nèi)存時的標(biāo)識

FsImage 是由 editslog 經(jīng)過 checkpoint 機(jī)制而得到的，也就是說先有 editslog 再有 FsImage，那么我們來回顧一下 editslog 的組織格式：

message EditLog {
  int64 txId = 1;
  // 操作類型
  int32 opType = 2;
  string path = 3;
  map<string, string> attr = 4;
}

可以看到 editslog 中是有一個 txId 的屬性的，這個屬性是自增的（long 類型，64位取值范圍非常大，理論上不會超出了的）；txId 是 editslog 的唯一標(biāo)識。

txId 是在內(nèi)存中維護(hù)著的，每生成一個 editslog 都會將當(dāng)前 txid 賦值給它，并將 txid + 1；這個在內(nèi)存維護(hù)的 txid 是當(dāng)前系統(tǒng)中最大的 txid 即 max_txid ，在生成 FsImage 會將系統(tǒng)中所有數(shù)據(jù)生成快照，并將當(dāng)前 max_txid 賦值給它。

我們都知道 FsImage 中有兩個重要的屬性：

public class FsImage {
    ......
    /**
     * 當(dāng)前最大的txId
     */
    private long maxTxId;
    /**
     * 內(nèi)容
     */
    private INode iNode;
    ......
}

iNode 其實就是元數(shù)據(jù)，而 maxTxId 其實就是生成 FsImage 時，系統(tǒng)中的 max_txid。

在磁盤中的標(biāo)識

上述我們介紹了 FsImage 和 editslog 數(shù)據(jù)在內(nèi)存中的標(biāo)識，但是這兩樣數(shù)據(jù)都是需要持久化的，那么在持久化之后，怎么標(biāo)識他們呢？

我們都知道他們的數(shù)據(jù)中包含了 txid ，可是這個數(shù)據(jù)是需要加載進(jìn)內(nèi)存才能看到的。。。

為了在剛恢復(fù)數(shù)據(jù)的時候，也能看到 txid （系統(tǒng)是根據(jù) txid 來聯(lián)系 FsImage 和 editslog， 進(jìn)行數(shù)據(jù)恢復(fù)的），所以在持久化的時候，我們對這兩種文件的命名進(jìn)行了特殊的組織格式：

fsimage文件的文件名是"fsimage_txid"，其中 txid 是文件系統(tǒng)狀態(tài)的事務(wù)ID

editslog 文件的文件名是類似 “1_1000.log” 這種格式（editslog 記錄的可能是多條數(shù)據(jù)）

恢復(fù)元數(shù)據(jù)的流程

• 根據(jù)指定路徑，找到 FsImage 文件的存放地點
• 排序，找出 txid 最大的 FsImage （即最新的 FsImage）
• 解析最新的 FsImage 數(shù)據(jù)進(jìn)內(nèi)存
• 找到 editslog，并將其排序，找出 txid 比最新 FsImage 的 txid 還大的所有 editslog 文件
• 將返回的editslog文件數(shù)據(jù)解析進(jìn)內(nèi)存

以上就是NameNode 重啟恢復(fù)數(shù)據(jù)的流程詳解的詳細(xì)內(nèi)容，更多關(guān)于NameNode 重啟恢復(fù)數(shù)據(jù)的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論