云服务器内容精选

  • 回答 由于在删除了大量文件之后,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。修改日志级别后无需重启服务。
  • 回答 当Standby NameNode存储元数据(命名空间)时,出现断电的情况,Standby NameNode启动失败,MD5文件会损坏。通过移除损坏的fsimage,然后启动Standby NameNode,可以修复此问题。Standby NameNode会加载先前的fsimage并重现所有的edits。 修复步骤: 移除损坏的fsimage。 rm -rf ${BIGDATA_DATA_HOME}/namenode/current/fsimage_0000000000000096 启动Standby NameNode。
  • 问题 HDFS调用FileInputFormat的getSplit方法的时候,出现ArrayIndexOutOfBoundsException: 0,日志如下: java.lang.ArrayIndexOutOfBoundsException: 0 at org.apache.hadoop.mapred.FileInputFormat.identifyHosts(FileInputFormat.java:708) at org.apache.hadoop.mapred.FileInputFormat.getSplitHostsAndCachedHosts(FileInputFormat.java:675) at org.apache.hadoop.mapred.FileInputFormat.getSplits(FileInputFormat.java:359) at org.apache.spark.rdd.HadoopRDD.getPartitions(HadoopRDD.scala:210) at org.apache.spark.rdd.RDD$$anonfun$partitions$2.apply(RDD.scala:239) at org.apache.spark.rdd.RDD$$anonfun$partitions$2.apply(RDD.scala:237) at scala.Option.getOrElse(Option.scala:120) at org.apache.spark.rdd.RDD.partitions(RDD.scala:237) at org.apache.spark.rdd.MapPartitionsRDD.getPartitions(MapPartitionsRDD.scala:35)
  • 问题 为什么在往HDFS写数据时报"java.net.SocketException: No buffer space available"异常? 这个问题发生在往HDFS写文件时。查看客户端和DataNode的错误日志。 客户端日志如下: 图1 客户端日志 DataNode日志如下: 2017-07-24 20:43:39,269 | ERROR | DataXceiver for client DFSClient_NONMAPREDUCE_996005058_86 at /192.168.164.155:40214 [Receiving block BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 with io weight 10] | DataNode{data=FSDataset{dirpath='[/srv/BigData/hadoop/data1/dn/current, /srv/BigData/hadoop/data2/dn/current, /srv/BigData/hadoop/data3/dn/current, /srv/BigData/hadoop/data4/dn/current, /srv/BigData/hadoop/data5/dn/current, /srv/BigData/hadoop/data6/dn/current, /srv/BigData/hadoop/data7/dn/current]'}, localName='192-168-164-155:9866', datanodeUuid='a013e29c-4e72-400c-bc7b-bbbf0799604c', xmitsInProgress=0}:Exception transfering block BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 to mirror 192.168.202.99:9866: java.net.SocketException: No buffer space available | DataXceiver.java:870 2017-07-24 20:43:39,269 | INFO | DataXceiver for client DFSClient_NONMAPREDUCE_996005058_86 at /192.168.164.155:40214 [Receiving block BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 with io weight 10] | opWriteBlock BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 received exception java.net.SocketException: No buffer space available | DataXceiver.java:933 2017-07-24 20:43:39,270 | ERROR | DataXceiver for client DFSClient_NONMAPREDUCE_996005058_86 at /192.168.164.155:40214 [Receiving block BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 with io weight 10] | 192-168-164-155:9866:DataXceiver error processing WRITE_BLOCK operation src: /192.168.164.155:40214 dst: /192.168.164.155:9866 | DataXceiver.java:304 java.net.SocketException: No buffer space available at sun.nio.ch.Net.connect0(Native Method) at sun.nio.ch.Net.connect(Net.java:454) at sun.nio.ch.Net.connect(Net.java:446) at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648) at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:192) at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:531) at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:495) at org.apache.hadoop.hdfs.server.datanode.DataXceiver.writeBlock(DataXceiver.java:800) at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.opWriteBlock(Receiver.java:138) at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.processOp(Receiver.java:74) at org.apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.java:265) at java.lang.Thread.run(Thread.java:748)
  • 解决方法 找到重启前的主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,观察是否成功。如还是失败,请联系技术支持。
  • 回答 当Standby NameNode存储元数据(命名空间)时,出现断电的情况,Standby NameNode启动失败,MD5文件会损坏。通过移除损坏的fsimage,然后启动Standby NameNode,可以修复此问题。Standby NameNode会加载先前的fsimage并重现所有的edits。 修复步骤: 移除损坏的fsimage。 rm -rf ${BIGDATA_DATA_HOME}/namenode/current/fsimage_0000000000000096 启动Standby 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,观察是否成功。如还是失败,请联系技术支持。
  • 问题 HDFS调用FileInputFormat的getSplit方法的时候,出现ArrayIndexOutOfBoundsException: 0,日志如下: java.lang.ArrayIndexOutOfBoundsException: 0 at org.apache.hadoop.mapred.FileInputFormat.identifyHosts(FileInputFormat.java:708) at org.apache.hadoop.mapred.FileInputFormat.getSplitHostsAndCachedHosts(FileInputFormat.java:675) at org.apache.hadoop.mapred.FileInputFormat.getSplits(FileInputFormat.java:359) at org.apache.spark.rdd.HadoopRDD.getPartitions(HadoopRDD.scala:210) at org.apache.spark.rdd.RDD$$anonfun$partitions$2.apply(RDD.scala:239) at org.apache.spark.rdd.RDD$$anonfun$partitions$2.apply(RDD.scala:237) at scala.Option.getOrElse(Option.scala:120) at org.apache.spark.rdd.RDD.partitions(RDD.scala:237) at org.apache.spark.rdd.MapPartitionsRDD.getPartitions(MapPartitionsRDD.scala:35)