Hadoop集羣中，NameNode節點存儲着HDFS上所有文件和目錄的元數據信息
如果NameNode掛了，也就意味着整個Hadoop集羣也就完了
所以，NameNode節點的備份很重要，可以從以下2個方面來備份NameNode節點
1. 在hdfs-site.xml中，配置多個name的dir到不同的磁盤分區上：
<property>
<name>dfs.name.dir</name>
<value>/pvdata/hadoopdata/name/,/opt/hadoopdata/name/</value>
</property>
2. 在另外的一臺服務器上配置Secondary NameNode：它是NameNode的一個備份
Secondary NameNode會定期合併fsimage和edits日誌，將edits日誌文件大小控制在一個限度下
合併的時機是由2個配置參數決定的：
fs.checkpoint.period，指定連續兩次檢查點的最大時間間隔， 默認值是1小時。
fs.checkpoint.size定義了edits日誌文件的最大值，一旦超過這個值會導致強制執行檢查點（即使沒到檢查點的最大時間間隔）。默認值是64MB。
Secondary NameNode的配置過程如下：
- 在conf/masters中指定第二名稱節點的主機名
- 在core-site.xml中指定checkpoint的目錄
<property>
<name>fs.checkpoint.dir</name>
<value>/opt/hadoopdata/secondname,/pvdata/hadoopdata/secondname</value>
<description>Determines where on the local filesystem the DFS secondary
name node should store the temporary images to merge.
If this is a comma-delimited list of directories then the image is
replicated in all of the directories for redundancy.
</description>
</property>
如果NameNode節點掛了，可以按照如下步驟來從Secondary NameNode來恢復：
- 在dfs.name.dir指定的位置建立一個空文件夾
- 從Secondary NameNode上把secondname的目錄給scp到新的NameNode機器的fs.checkpoint.dir下
- 使用hadoop/bin/hadoop namenode -importCheckpoint來啓動NameNode，主要不要執行format命令
- 使用hadoop fsck /user命令檢查文件Block的完整性
詳細的Secondary NameNode細節可參考Hadoop官方文檔：
http://hadoop.apache.org/common/docs/r0.20.2/hdfs_user_guide.html#Secondary+NameNode
==========================================================
這兩天在操作Hadoop集羣時，由於一個誤操作，製作了一個天大的悲劇
不小心把Hadoop集羣上的所有文件全部刪除了，具體情況是這樣的：
我用hadoop的超級帳戶要建立一個目錄，結果發現位置錯了
也是，想使用rmr刪掉那個目錄，可是不小心把命令寫成了
hadoop fs -rmr /user
於是，悲劇出現了，所有user目錄下的所有目錄和文件全都沒有了
當時我就慌神了，趕緊從web查看50070的服務
眼看着DFS Used空間從100多G不停的減少
後來才反應過來，趕緊停掉namenode節點，然後上網google辦法
後來，從secondname節點重新恢復了一個checkpoint
但絕大部分數據都已經丟失了，只恢復了一小部分數據，已經沒啥用了
幸好，原始log我們在其它服務器上還保留的有，只能重新分析再入Hadoop了
總結了一下幾點教訓：
- 首先一定要控制好hadoop上各用戶的權限，使各user只能操作自己的目錄
- 儘量少用hadoop的超級用戶進行操作，可以減少誤操作
- hadoop的rm和rmr命令，設計的太BT了，連一個確認提示都沒有，直接就刪除了。看到有人給官方提了這個建議，但人家回覆說：已經有了trash機制了，所以不需要提示，真是無語….
- hadoop的trash功能：很遺憾，之前沒有配置trash，所以就直接給刪除了，經過這次誤操作，趕緊配置上trash，並設置保留時間爲7天。
在core-site.xml中增加如下配置，表明rm後會在trash中保留多少分鐘：
<property>
<name>fs.trash.interval</name>
<value>10080</value>
<description>
Number of minutes between trash checkpoints. If zero, the trash feature is disabled
</description>
</property>
很遺憾的是，hadoop的這個默認值是0，就是直接刪除了，爲什麼要這麼設計呢？鬱悶….
經過簡單的測試，這個trash功能還是不錯的，當rm後，它會move到當前文件夾下的.Trash目錄下
如果你刪除一個文件或目錄多次，則hadoop會自動在name後加上數字序列號
這樣，如果你誤刪除後，就可以有選擇的恢復文件了
hadoop fs -mkdir /user/oplog/test
hadoop fs -put *.txt /user/oplog/test
hadoop fs -rmr /user/oplog/test
hadoop fs -ls /user/oplog/.Trash/Current/user/oplog
drwxr-xr-x – oplog oplog 0 2010-11-16 10:44 /user/oplog/.Trash/Current/user/oplog/test
hadoop fs -mv /user/oplog/.Trash/Current/user/oplog/test /user/oplog/
hadoop fs -ls /user/oplog/.Trash/Current/user/oplog
drwxr-xr-x – oplog oplog 0 2010-11-16 10:44 /user/oplog/.Trash/Current/user/oplog/test
drwxr-xr-x – oplog oplog 0 2010-11-16 10:47 /user/oplog/.Trash/Current/user/oplog/test.1