云服务器内容精选

  • 回答 当用户在distcp命令中使用webhdfs://时,会发生上述异常,是由于集群所使用的HTTP政策为HTTPS,即配置在“core-site.xml”的“dfs.http.policy”值为“HTTPS_ONLY”。所以要避免出现此异常,应使用swebhdfs://替代webhdfs://。 例如: ./hadoop distcpswebhdfs://IP:PORT/testfile hdfs://IP:PORT/testfile1
  • 回答 通常,HDFS执行Balance操作结束后,会自动释放“/system/balancer.id”文件,可再次正常执行Balance。 但在上述场景中,由于第一次的Balance操作是被异常停止的,所以第二次进行Balance操作时,“/system/balancer.id”文件仍然存在,则会触发append /system/balancer.id操作,进而导致Balance操作失败。 如果“/system/balancer.id”文件的释放时间超过了软租期60s,则第二次执行Balance操作的客户端的append操作会抢占租约,此时最后一个block处于under construction或者under recovery状态,会触发block的恢复操作,那么“/system/balancer.id”文件必须等待block恢复完成才能关闭,所以此次append操作失败。 append /system/balancer.id操作失败后,会向客户端发生RecoveryInProgressException异常: org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.protocol.RecoveryInProgressException): Failed to APPEND_FILE /system/balancer.id for DFSClient because lease recovery is in progress. Try again later. 如果该文件的释放时间没有超过默认设置60s,原有客户端会继续持有该租约,则会发生AlreadyBeingCreatedException异常,实际上向客户端返回的是null,导致客户端出现如下异常: java.io.IOException: Cannot create any NameNode Connectors.. Exiting... 可通过以下方法避免上述问题: 方案1:等待硬租期超过1小时后,原有客户端释放租约,再执行第二次Balance操作。 方案2:执行第二次Balance操作之前删除“/system/balancer.id”文件。
  • 回答 目前出现上述问题时使用的是默认配置,如表1所示,HDFS客户端到NameNode的RPC连接存在keep alive机制,保持连接不会超时,尽力等待服务器的响应,因此导致已经连接的HDFS客户端的操作会卡住。 对于已经卡住的HDFS客户端,可以进行如下操作: 等待NameNode响应,一旦NameNode所在节点的CPU利用率回落,NameNode可以重新获得CPU资源时,HDFS客户端即可得到响应。 如果无法等待更长时间,需要重启HDFS客户端所在的应用程序进程,使得HDFS客户端重新连接空闲的NameNode。 解决措施: 为了避免该问题出现,可以在“客户端安装路径/HDFS/hadoop/etc/hadoop/core-site.xml”中做如下配置。 表1 参数说明 参数 描述 默认值 ipc.client.ping 当配置为true时,客户端会尽力等待服务端响应,定期发送ping消息,使得连接不会因为tcp timeout而断开。 当配置为false时,客户端会使用配置项“ipc.ping.interval”对应的值,作为timeout时间,在该时间内没有得到响应,即会超时。 在上述问题场景下,建议配置为false。 true ipc.ping.interval 当“ipc.client.ping”配置为true时,表示发送ping消息的周期。 当“ipc.client.ping”设置为false时,表示连接的超时时间。 在上述问题场景下,建议配置一个较大的超时时间,避免服务繁忙时的超时,建议配置为900000,单位为ms。 60000
  • 回答 由于断电,当写操作完成之后,缓存中的block不会立即被写入磁盘,如果要同步地将缓存的block写入磁盘,用户需要将“客户端安装路径/HDFS/hadoop/etc/hadoop/hdfs-site.xml”中的“dfs.datanode.synconclose”设置为“true”。 默认情况下,“dfs.datanode.synconclose”为“false”,虽然性能很高,但是断电之后,存储在缓存中的数据会丢失。将“dfs.datanode.synconclose”设置为“true”,可以解决此问题,但对性能有很大影响。请根据具体的应用场景决定是否开启该参数。