快捷導(dǎo)航

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

更新時(shí)間：2023年02月07日 15:58:30 作者：點(diǎn)滴星光

這篇文章主要為大家介紹了NameNode?重啟恢復(fù)數(shù)據(jù)的流程詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

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

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

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

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

FsImage 和 editslog 的聯(lián)系

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

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

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

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

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

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

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

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

在磁盤(pán)中的標(biāo)識(shí)

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

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

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