背景

有個好久好久沒怎么維護的Hadoop集群，一直在提供服務，也做了HA，由于某些原因要對HDFS做重啟，重啟前檢查了遍服務，發現另一個NameNode已經掛了有一段時間了。

重啟過程倒是沒啥問題，但NameNode的Startup Progress特別久，持續Loading edits，將近3個小時。

分析

到NameNode的數據目錄看了下，發現有大量的edits_*文件，加起來得有60G，這些文件也存在很久了，最早的文件貌似和StandBy NameNode掛掉的時間比較接近。edits文件很久沒有做合并了，懷疑是跟另一個NameNode掛掉有關。

在網上也查了下NameNode合并的機制，果不其然，StandBy的NameNode平時并不是閑著的，雖然不對外提供服務，但是它會在后臺默默的做edits的合并和JournalNode的同步等工作，合并edits文件后，也會同步給Active的NameNode，讓它清理無用的edits文件。

SecondaryNamenode（也是StandBy NameNode）最重要作用，是定期合并FsImage和EditLog文件，并替換NameNode上的舊的FsImage文件，生成新的EditLog文件，替換原來的舊的EditLog文件。這樣可以保證SecondaryNameNode上的文件為最近的信息。當發生宕機時候，可以快速恢復。

強制刷新edits文件

執行

hdfs dfsadmin -safemode enter

然后再執行

hdfs dfsadmin -saveNamespace

總結

以上是生活随笔為你收集整理的解决HDFS NameNode启动时Loading edits时间超长的问题（NameNode数据同步机制介绍）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。