关于Hadoop NameNode启动时Loading edits时间超长的问题 2019-09-27 02:30:03 ## 背景 有个好久好久没怎么维护的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 非特殊说明，均为原创，原创文章，未经允许谢绝转载。 原始链接：关于Hadoop NameNode启动时Loading edits时间超长的问题 赏 Prev JFrog Artifactory使用中遇到的一些坑 Next Nginx反向代理神奇的斜线/及跳转问题
