一、dits和fsimage
首先要提到兩個檔案edits和fsimage，下面來說說他們是做什麼的。
那麼問題來了，只有在名稱節點（namenode）啟動的時候才會合併fsimage和edits，那麼久而久之edits檔案會越來越大，特別是大型繁忙的hdfs集群。這種情況下，由於某種原因你要重啟名稱節點（namenode），那麼會花費很長的時間去合併fsimge和edits，然後hdfs才能執行。
二、secondary namenode
目前使用的版本hadoop-0.20.2可以使用secondary namenode來解決上面的問題。secondary namenode定期合併fsimage和edits日誌，把edits日誌檔案大小控制在乙個限度下。因為記憶體需求和namenode差不多(on the same order)，所以sencondary namenode通常要執行在另外個機器上。
secondary namenode配置在conf/masters檔案，啟動命令:bin/start-dfs.sh（如果你使用不建議的start-all.sh也是會啟動的）。
三、什麼時候checkpiont
secondary namenode 什麼時候執行checkpoint來合併fsimage和eidts。呢？有兩個配置引數控制：
secondary namenode 儲存最後一次checkpoint的結果，儲存結構和主節點（namenode）的一樣，所以主節點（namenode）可以隨時來讀取。
如果你沒有啟動secondary namenode 那麼可以試試 bin/hadoop secondarynamenode -checkpoint 甚至 bin/hadoop secondarynamenode -checkpoint force. 看看生成的檔案。
checkpoint可以解決重啟namenode時間過長的弊端。另外還有偏方：
四、import checkpoint（恢復資料）
如果主節點掛掉了，硬碟資料需要時間恢復或者不能恢復了，現在又想立刻恢復hdfs，這個時候就可以import checkpoint。步驟如下：
這樣namenode會讀取checkpoint檔案，儲存到dfs.name.dir。但是如果你的dfs.name.dir包含合法的fsimage，是會執行失敗的。因為namenode會檢查fs.checkpoint.dir目錄下映象的一致性，但是不會去改動它。
值得推薦的是，你要注意備份你的dfs.name.dir和 $/dfs/namesecondary。
五、checkpoint node 和 backup node
在後續版本中hadoop-0.21.0，還提供了另外的方法來做checkpoint：checkpoint node 和 backup node。則兩種方式要比secondary namenode好很多。所以 the secondary namenode has been deprecated. instead, consider using the checkpoint node or backup node.
checkpoint node像是secondary namenode的改進替代版，backup node提供更大的便利，這裡就不再介紹了。
Elasticsearch的資料備份和恢復以及遷移
目錄 1.為什麼備份？2.資料備份 3.資料恢復 4.es備份資料遷移目標伺服器 5.指令碼備份恢復 常見的資料庫都會提供備份機制，以解決在資料庫無法使用的情況下通過備份來恢復資料減少損失。elasticsearch 雖然有良好的容災性，但以下原因，其依然需要備份機制 1 資料災備 在整個集群無法正...
mysql利用mysqldump備份和恢復
mysqldump使用語法 mysqldump u 使用者 h host p 密碼 dbname table 路徑 遠端備份單庫例子 mysqldump uroot pabc123456 h192.168.1.101 zabbix gzip mysql data back zabbix users....
安裝 gitlab 和 gitlab的備份與恢復
官方文件 配置yum源 vim etc yum.repos.d gitlab ce.repo gitlab ce name gitlab ce baseurl enabled 1 gpgcheck 0 gpgkey 安裝花費的時間有點長 yum install gitlab ce y配置與gitla...