解决HDFS NameNode启动时Loading edits时间超长的问题(NameNode数据同步机制介绍)
背景
有個好久好久沒怎么維護的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数据同步机制介绍)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Hadoop Yarn任务优先级(作业优
- 下一篇: 利用 Arthas 解决启动 HDFS