云服务器内容精选

  • 解决方法 找到重启前的主NameNode,进入其数据目录(查看配置项“dfs.namenode.name.dir”可获取,例如/srv/BigData/namenode/current),得到最新的FSImage文件的序号。一般如下: 查看各JournalNode的数据目录(查看配置项“dfs.journalnode.edits.dir”可获取,例如/srv/BigData/journalnode/hacluster/current),查看序号从第一步获取到的序号开始的edits文件,看是否有不连续的情况(即前一个edits文件的最后一个序号和后一个edits文件的第一个序号不是连续的,如下图中的edits_0000000000013259231-0000000000013259237和后一个edits_0000000000013259239-0000000000013259246就是不连续的)。 如果有这种不连续的edits文件,则需要查看其它的JournalNode的数据目录或NameNode数据目录中,有没有连续的该序号相关的连续的edits文件。如果可以找到,复制一个连续的片段到该JournalNode。 如此把所有的不连续的edits文件全部都修复。 重启NameNode,观察是否成功。如还是失败,请联系技术支持。
  • 解决方法 找到重启前的主NameNode,进入其数据目录(查看配置项“dfs.namenode.name.dir”可获取,例如/srv/BigData/namenode/current),得到最新的FSImage文件的序号。一般如下: 查看各JournalNode的数据目录(查看配置项“dfs.journalnode.edits.dir”可获取,例如/srv/BigData/journalnode/hacluster/current),查看序号从第一步获取到的序号开始的edits文件,看是否有不连续的情况(即前一个edits文件的最后一个序号和后一个edits文件的第一个序号不是连续的,如下图中的edits_0000000000013259231-0000000000013259237和后一个edits_0000000000013259239-0000000000013259246就是不连续的)。 如果有这种不连续的edits文件,则需要查看其它的JournalNode的数据目录或NameNode数据目录中,有没有连续的该序号相关的连续的edits文件。如果可以找到,复制一个连续的片段到该JournalNode。 如此把所有的不连续的edits文件全部都修复。 重启NameNode,观察是否成功。如还是失败,请联系技术支持。
  • 回答 由于在删除了大量文件之后,DataNode需要时间去删除对应的Block。当立刻重启NameNode时,NameNode会去检查所有DataNode上报的Block信息,发现已删除的Block时,会输出对应的INFO日志信息,如下所示: 2015-06-10 19:25:50,215 | INFO | IPC Server handler 36 on 25000 | BLOCK* processReport: blk_1075861877_2121067 on node 10.91.8.218:9866 size 10249 does not belong to any file | org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.processReport(BlockManager.java:1854) 每一个被删除的Block会产生一条日志信息,一个文件可能会存在一个或多个Block。当删除的文件数过多时,NameNode会花大量的时间打印日志,然后导致NameNode启动慢。 当出现这种现象时,您可以通过如下方式提升NameNode的启动速度。 删除大量文件时,不要立刻重启NameNode,待DataNode删除了对应的Block后重启NameNode,即不会存在这种情况。 您可以通过hdfs dfsadmin -report命令来查看磁盘空间,检查文件是否删除完毕。 如已大量出现以上日志,您可以将NameNode的日志级别修改为ERROR,NameNode不会再打印此日志信息。 等待NameNode启动完毕后,再将此日志级别修改为INFO。修改日志级别后无需重启服务。