大量删除hdfs历史文件导致全部DataNode心跳汇报超时为死亡状态问题解决

最新推荐文章于 2023-04-01 16:12:39 发布
置顶 最新推荐文章于 2023-04-01 16:12:39 发布
阅读量3.2k 收藏 4
点赞数 3
分类专栏： Hadoop 大数据 问题解决
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/JacksonKing/article/details/99872449
版权
大数据 同时被 3 个专栏收录
67 篇文章 1 订阅
订阅专栏
Hadoop
40 篇文章 1 订阅
订阅专栏
问题解决
38 篇文章 0 订阅
订阅专栏

目录

 

背景：

问题产生过程：

问题现象：

解决过程:

相关日志：

其他方案：

总结：

背景：

由于测试环境的磁盘满了，导致多个NodeManager出现不健康状态，查看了下，基本都是data空间满导致，不是删除日志文件等就能很快解决的，只能删除一些历史没有用的数据。于是从大文件列表中，找出2018年的spark作业的历史中间文件并彻底删除(跳过回收站)

/usr/local/hadoop-2.6.3/bin/hdfs dfs -rm -r -skipTrash /user/hadoop/.sparkStaging/application_1542856934835_1063/Job_20181128135837.jar

问题产生过程：

  1. hdfs删除大量历史文件过程中，standby的namenode节点gc停顿时间过长退出了
  2. 当时没注意stanby已经退出了，还在继续删除数据，后面发现stanby停了后，于是重启stanby的NN，
  3. 启动时active的namenode已经删除了许多文件，导致两个namenode保存的数据块信息不一致了，出现大量数据块不一致的报错，使得所有的DataNode在与NameNode节点汇报心跳时，超时而被当做dead节点。

问题现象：

  • active的namenode的webUI里datanode状态正常，
  • 但是standby的webUI里datanode全部dead，日志显示datanode频繁连接standby的NN且被远程standby的NN连接关闭，standby的NN显示一直在添加新的数据块

解决过程:

  1. 【重启stanby的NN】重启stanby的NN,重启后，stanby的NN存在GC停顿时间长的日志，之后出现大量写数据时管道断开(java.io.IOException: Broken pipe)的报错，stanby的节点列表还都是dead状态，且DataNode节点的日志大量报与stanby的NN的rpc端连接被重置错误(Connection reset by peer)，这个过程之前还不知道原理，原来DN也会往stanby的NN发送报告信息。
  2. 【active的NN诡异的挂掉】stanby的NN重启一段时间后发现active的NN也挂掉了，而且日志没有明显的报错，于是重启active的NN，过后发现active和stanby的NN的50070的webUI中DataNode列表都是dead了，且DataNode节点的日志依然大量报与NN的rpc端连接被重置错误(Connection reset by peer)
  3. 【尝试重启DataNode】尝试重启DataNode让其重新注册，发现重启后还是依然报与NN的rpc连接重置的错
  4. 【刷新节点操作】问了位大神后，尝试刷新节点，让全部节点重新注册，发现刷新节点失败，也是报的rpc连接被重置问题
  5. 【排查网络问题】由于服务并没有挂掉，且对应的rpc端口也有监听，猜测是网络、dns、防火墙、时间同步等问题，让运维一起排查都反馈没问题，不过运维帮忙反馈该rpc端口有时可以连接有时超时，连接中有大量的close_wait，一般情况下说明程序已经没有响应了，导致客户端主动断开请求。
  6. 【调整active的NN堆内存大小重启并刷新节点】于是猜想是不是现在active的NN的堆内存不足了，导致大量的rpc请求被阻塞，于是尝试调大active的NN的堆内存大小，停止可能影响NN性能的JobHistoryServer、Balancer和自身的agent监控服务，重启，重启后发现active的DN节点列表已恢复正常，但是stanby的DN节点列表还都是dead，尝试再次刷新节点，发现有刷新成功和刷新失败的rpc连接重置的日志，观察节点列表仍然还不能恢复正常
  7. 【发现JN挂掉了一个】于是查看stanby的DN的日志，发现报了JN连接异常的错误，发现确实active的NN中的JN挂了，重启JN，以为节点恢复了，发现还是不行，大神指点JN挂掉其实无所谓，确实，理论上数据块信息都是在NN，挂掉最多导致部分新数据没有，后面还会补上的
  8. 【重启stanby的NN】在大神的指点下，这时候重启stanby的NN能解决90%的问题，重启后果然active和stanby的DN列表都恢复正常了。

相关日志：

stanby的NameNode因gc停顿时间过长导致退出日志

2019-08-20 14:06:38,841 INFO org.apache.hadoop.hdfs.server.namenode.FileJournalManager: Finalizing edits file /usr/local/hadoop-2.6.3/data/dfs/name/current/edits_inprogress_0000000000203838246 -> /usr/local/hadoop-2.6.3/data/dfs/name/current/edits_0000000000203838246-0000000000203838808
2019-08-20 14:06:38,841 INFO org.apache.hadoop.hdfs.server.namenode.FSEditLog: Starting log segment at 203838809
2019-08-20 14:06:40,408 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 1069ms
GC pool 'PS MarkSweep' had collection(s): count=1 time=1555ms
2019-08-20 14:06:45,513 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 2139ms
GC pool 'PS MarkSweep' had collection(s): count=2 time=2638ms
2019-08-20 14:06:45,513 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Rescanning after 30749 milliseconds
2019-08-20 14:07:03,010 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 3326ms
GC pool 'PS MarkSweep' had collection(s): count=11 time=14667ms
2019-08-20 14:07:14,188 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 1009ms
GC pool 'PS MarkSweep' had collection(s): count=1 time=1509ms
2019-08-20 14:07:18,175 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 2179ms
GC pool 'PS MarkSweep' had collection(s): count=2 time=2678ms
2019-08-20 14:07:19,723 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 1047ms
GC pool 'PS MarkSweep' had collection(s): count=1 time=1540ms

standby的Namenode重启后因合并editLog日志和数据块删除等操作导致gc停顿日志

The number of live datanodes 15 has reached the minimum number 0. Safe mode will be turned off automatically once the thresholds have been reached.
2019-08-20 14:54:31,557 INFO org.apache.hadoop.hdfs.StateChange: STATE* Safe mode ON. 
The reported blocks 447854 needs additional 1040262 blocks to reach the threshold 0.9990 of total blocks 1489605.
The number of live datanodes 15 has reached the minimum number 0. Safe mode will be turned off automatically once the thresholds have been reached.
2019-08-20 14:54:32,799 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 1387ms
GC pool 'PS MarkSweep' had collection(s): count=1 time=1886ms
2019-08-20 14:54:39,305 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 3923ms
GC pool 'PS MarkSweep' had collection(s): count=4 time=4422ms
2019-08-20 14:54:55,588 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 2695ms
GC pool 'PS MarkSweep' had collection(s): count=1 time=3195ms
2019-08-20 14:56:11,593 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 1670ms
GC pool 'PS MarkSweep' had collection(s): count=6 time=6936ms
2019-08-20 14:56:14,517 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 2424ms
GC pool 'PS MarkSweep' had collection(s): count=30 time=41545ms
2019-08-20 14:56:16,459 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 1441ms
GC pool 'PS MarkSweep' had collection(s): count=1 time=1942ms
2019-08-20 14:56:17,653 ERROR org.mortbay.log: Error for /jmx
2019-08-20 14:56:28,608 ERROR org.mortbay.log: /jmx?qry=Hadoop:service=NameNode,name=FSNamesystemState
2019-08-20 14:56:26,419 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 1309ms
GC pool 'PS MarkSweep' had collection(s): count=1 time=1809ms
2019-08-20 14:56:23,558 ERROR org.mortbay.log: Error for /jmx
2019-08-20 14:56:21,164 ERROR org.mortbay.log: handle failed
2019-08-20 14:56:19,957 ERROR org.mortbay.log: Error for /jmx

standby的Namenode重启后的写数据报错

The reported blocks 448402 needs additional 1039714 blocks to reach the threshold 0.9990 of total blocks 1489605.
The number of live datanodes 15 has reached the minimum number 0. Safe mode will be turned off automatically once the thresholds have been reached.
2019-08-20 14:58:08,273 WARN org.apache.hadoop.ipc.Server: IPC Server handler 5 on 9001, call org.apache.hadoop.hdfs.server.protocol.DatanodeProtocol.blockReceivedAndDeleted from 10.104.108.220:63143 Call#320840 Retry#0: output error
2019-08-20 14:58:08,290 INFO org.apache.hadoop.ipc.Server: IPC Server handler 5 on 9001 caught an exception
java.io.IOException: Broken pipe
	at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
	at sun.nio.ch.IOUtil.write(IOUtil.java:65)
	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
	at org.apache.hadoop.ipc.Server.channelWrite(Server.java:2574)
	at org.apache.hadoop.ipc.Server.access$1900(Server.java:135)
	at org.apache.hadoop.ipc.Server$Responder.processResponse(Server.java:978)
	at org.apache.hadoop.ipc.Server$Responder.doRespond(Server.java:1043)
	at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2095)
2019-08-20 14:58:08,273 WARN org.apache.hadoop.ipc.Server: IPC Server handler 1 on 9001, call org.apache.hadoop.hdfs.server.protocol.DatanodeProtocol.blockReceivedAndDeleted from 10.104.101.45:8931 Call#2372642 Retry#0: output error
2019-08-20 14:58:08,290 INFO org.apache.hadoop.ipc.Server: IPC Server handler 1 on 9001 caught an exception
java.io.IOException: Broken pipe
	at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
	at sun.nio.ch.IOUtil.write(IOUtil.java:65)
	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
	at org.apache.hadoop.ipc.Server.channelWrite(Server.java:2574)
	at org.apache.hadoop.ipc.Server.access$1900(Server.java:135)
	at org.apache.hadoop.ipc.Server$Responder.processResponse(Server.java:978)
	at org.apache.hadoop.ipc.Server$Responder.doRespond(Server.java:1043)
	at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2095)

active的NN诡异地无明显报错的挂掉

2019-08-20 16:27:55,477 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* allocateBlock: /user/hive/warehouse/bi_ucar.db/fact_complaint_detail/.hive-staging_hive_2019-08-20_16-27-19_940_4374739327044819866-1/-ext-10000/_temporary/0/_temporary/attempt_201908201627_0030_m_000199_0/part-00199. BP-535417423-10.104.104.128-1535976912717 blk_1089864054_16247563{blockUCState=UNDER_CONSTRUCTION, primaryNodeIndex=-1, replicas=[ReplicaUnderConstruction[[DISK]DS-77fcebb8-363e-4b79-8eb6-974db40231cb:NORMAL:10.104.108.157:50010|RBW], ReplicaUnderConstruction[[DISK]DS-6425eb5e-a10e-4f44-ae1e-eb0170d7e5c5:NORMAL:10.104.108.212:50010|RBW], ReplicaUnderConstruction[[DISK]DS-16b95ffb-ac8a-4c34-86bc-e0ee58380a60:NORMAL:10.104.108.170:50010|RBW]]}
2019-08-20 16:27:55,488 INFO BlockStateChange: BLOCK* addStoredBlock: blockMap updated: 10.104.108.170:50010 is added to blk_1089864054_16247563{blockUCState=UNDER_CONSTRUCTION, primaryNodeIndex=-1, replicas=[ReplicaUnderConstruction[[DISK]DS-77fcebb8-363e-4b79-8eb6-974db40231cb:NORMAL:10.104.108.157:50010|RBW], ReplicaUnderConstruction[[DISK]DS-6425eb5e-a10e-4f44-ae1e-eb0170d7e5c5:NORMAL:10.104.108.212:50010|RBW], ReplicaUnderConstruction[[DISK]DS-16b95ffb-ac8a-4c34-86bc-e0ee58380a60:NORMAL:10.104.108.170:50010|RBW]]} size 0
2019-08-20 16:27:55,489 INFO BlockStateChange: BLOCK* addStoredBlock: blockMap updated: 10.104.108.212:50010 is added to blk_1089864054_16247563{blockUCState=UNDER_CONSTRUCTION, primaryNodeIndex=-1, replicas=[ReplicaUnderConstruction[[DISK]DS-77fcebb8-363e-4b79-8eb6-974db40231cb:NORMAL:10.104.108.157:50010|RBW], ReplicaUnderConstruction[[DISK]DS-6425eb5e-a10e-4f44-ae1e-eb0170d7e5c5:NORMAL:10.104.108.212:50010|RBW], ReplicaUnderConstruction[[DISK]DS-16b95ffb-ac8a-4c34-86bc-e0ee58380a60:NORMAL:10.104.108.170:50010|RBW]]} size 0
2019-08-20 16:27:55,489 INFO BlockStateChange: BLOCK* addStoredBlock: blockMap updated: 10.104.108.157:50010 is added to blk_1089864054_16247563{blockUCState=UNDER_CONSTRUCTION, primaryNodeIndex=-1, replicas=[ReplicaUnderConstruction[[DISK]DS-77fcebb8-363e-4b79-8eb6-974db40231cb:NORMAL:10.104.108.157:50010|RBW], ReplicaUnderConstruction[[DISK]DS-6425eb5e-a10e-4f44-ae1e-eb0170d7e5c5:NORMAL:10.104.108.212:50010|RBW], ReplicaUnderConstruction[[DISK]DS-16b95ffb-ac8a-4c34-86bc-e0ee58380a60:NORMAL:10.104.108.170:50010|RBW]]} size 0
2019-08-20 16:27:55,492 INFO org.apache.hadoop.hdfs.StateChange: DIR* completeFile: /user/hive/warehouse/bi_ucar.db/fact_complaint_detail/.hive-staging_hive_2019-08-20_16-27-19_940_4374739327044819866-1/-ext-10000/_temporary/0/_temporary/attempt_201908201627_0030_m_000199_0/part-00199 is closed by DFSClient_NONMAPREDUCE_1289526722_42
2019-08-20 16:27:55,511 INFO BlockStateChange: BLOCK* BlockManager: ask 10.104.132.196:50010 to delete [blk_1089864025_16247534, blk_1089863850_16247357]
2019-08-20 16:27:55,511 INFO BlockStateChange: BLOCK* BlockManager: ask 10.104.108.213:50010 to delete [blk_1089864033_16247542, blk_1089864028_16247537]
2019-08-20 16:27:55,568 WARN org.apache.hadoop.security.UserGroupInformation: No groups available for user hadoop
2019-08-20 16:27:55,616 WARN org.apache.hadoop.security.UserGroupInformation: No groups available for user hadoop
2019-08-20 16:27:55,715 WARN org.apache.hadoop.security.UserGroupInformation: No groups available for user hadoop
2019-08-20 16:27:55,715 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: there are no corrupt file blocks.
2019-08-20 16:27:56,661 WARN org.apache.hadoop.security.UserGroupInformation: No groups available for user hadoop
2019-08-20 16:27:56,665 WARN org.apache.hadoop.security.UserGroupInformation: No groups available for user hadoop

active节点刷新节点失败报rpc连接重置错误

 

DataNode节点大量报与NN的RPC连接重置错误

2019-08-20 16:20:15,284 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Copied BP-535417423-10.104.104.128-1535976912717:blk_1089743067_16126311 to /10.104.132.198:22528
2019-08-20 16:20:15,288 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Copied BP-535417423-10.104.104.128-1535976912717:blk_1089743066_16126310 to /10.104.132.198:22540
2019-08-20 16:20:17,097 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Receiving BP-535417423-10.104.104.128-1535976912717:blk_1089862867_16246374 src: /10.104.108.170:55257 dest: /10.104.108.156:50010
2019-08-20 16:20:17,111 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Received BP-535417423-10.104.104.128-1535976912717:blk_1089862867_16246374 src: /10.104.108.170:55257 dest: /10.104.108.156:50010 of size 43153
2019-08-20 16:20:19,102 WARN org.apache.hadoop.hdfs.server.datanode.DataNode: IOException in offerService
java.io.IOException: Failed on local exception: java.io.IOException: Connection reset by peer; Host Details : local host is: "datanodetest17.bi/10.104.108.156"; destination host is: "namenodetest02.bi.10101111.com":9001; 
	at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:772)
	at org.apache.hadoop.ipc.Client.call(Client.java:1473)
	at org.apache.hadoop.ipc.Client.call(Client.java:1400)
	at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
	at com.sun.proxy.$Proxy13.sendHeartbeat(Unknown Source)
	at org.apache.hadoop.hdfs.protocolPB.DatanodeProtocolClientSideTranslatorPB.sendHeartbeat(DatanodeProtocolClientSideTranslatorPB.java:140)
	at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.sendHeartBeat(BPServiceActor.java:617)
	at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.offerService(BPServiceActor.java:715)
	at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.run(BPServiceActor.java:889)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Connection reset by peer
	at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
	at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
	at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
	at sun.nio.ch.IOUtil.read(IOUtil.java:197)
	at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
	at org.apache.hadoop.net.SocketInputStream$Reader.performIO(SocketInputStream.java:57)
	at org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:142)
	at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:161)
	at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:131)
	at java.io.FilterInputStream.read(FilterInputStream.java:133)
	at java.io.FilterInputStream.read(FilterInputStream.java:133)
	at org.apache.hadoop.ipc.Client$Connection$PingInputStream.read(Client.java:514)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
	at java.io.DataInputStream.readInt(DataInputStream.java:387)
	at org.apache.hadoop.ipc.Client$Connection.receiveRpcResponse(Client.java:1072)
	at org.apache.hadoop.ipc.Client$Connection.run(Client.java:967)
2019-08-20 16:20:20,458 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Receiving BP-535417423-10.104.104.128-1535976912717:blk_1089862871_16246378 src: /10.104.108.170:55263 dest: /10.104.108.156:50010
2019-08-20 16:20:20,712 INFO org.apache.hadoop.hdfs.server.datanode.DataNode.clienttrace: src: /10.104.108.170:55263, dest: /10.104.108.156:50010, bytes: 196672, op: HDFS_WRITE, cliID: DFSClient_NONMAPREDUCE_-1795425359_1146224, offset: 0, srvID: 9f1f3a39-a45d-4961-859f-c1953bde9a73, blockid: BP-535417423-10.104.104.128-1535976912717:blk_1089862871_16246378, duration: 98410715

其他方案：

在尝试解决的过程中，大神指点了尝试调大以下参数，默认是10

dfs.namenode.handler.count
dfs.namenode.service.handler.count

我认为目前在未有明确报错信息的情况下，不要盲目更改参数，否则可能有其他副作用

 

总结：

  1. 大量删除文件过程中，必须时刻关注active和stanby的NN的状态和日志，一旦发现异常信息，及时停止删除，避免发生后续NN挂掉或者其数据丢失问题
  2. 当active和stanby的NN都启动且WebUI中的DN列表如果都是dead的情况下，可以尝试先刷新节点让其重新注册，有机会恢复正常
  3. stanby的NN在大量的操作导致edits过大，standby节点合并的时候就可能发生gc暂停时间过长而退出，应避免连续的大量文件操作
  4. rpc端口有时可以连接有时超时，连接中有大量的close_wait，一般情况下说明程序已经没有响应了，导致客户端主动断开请求，可能是NN所在节点的对内存不足触发gc，导致大量线程阻塞使得rpc请求超时而重置
  5. 调整NameNode的堆内存大小，在hadoop-env.sh中配置HADOOP_NAMENODE_OPTS

参考：


https://blog.csdn.net/zhangjun5965/article/details/75579238

https://yq.aliyun.com/articles/578858

RunningShare
关注
  • 3
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 5
    评论
专栏目录
10、HDFS小文件解决方案-Archive
05-29
【Hadoop Archive（HAR）】是Hadoop分布式文件系统（HDFS）处理大量小文件问题的一种解决方案。在HDFS中，小文件的存在会导致NameNode的内存压力增大，因为每个文件的元数据都需要存储在NameNode内存中。当小文件...
docker-hdfs-datanode:用于运行 hdfs 数据节点的 Docker 容器
06-23
在 docker 容器中运行 hdfs 数据节点 暴露端口 TCP 50010 dfs.datanode.address 数据传输端口 TCP 50020 dfs.datanode.ipc.address ipc 服务器 TCP 50075 dfs.datanode.http.address http 服务器 TCP 50475 dfs....
HDFS集群繁忙时删除大量的文件导致NameNode服务不可用原理解析
大数据训练营
09-23 8701
一、HDFS 核心组件简介： HDFS 主要核心组件：NameNode + DataNode HDFS 采用 Master/Slave架构，一个HDFS集群由两个NameNode 和 一定数目的DataNodes组成，其中NameNode一个为Active，另一个作为Standby。NameNode几个核心：FSNameSystem（名字空间）、blockManager（块管理器）、Lease
01.大数据从节点datanode死掉了
weixin_42517765的博客
08-27 465
大数据hadoop集群的一个datanode死掉了，内存溢出，信息提示如下 查网上一大堆东西，说是让我修改hdfs的线程 参考腾讯云链接 没有这么做，暂时只是修改了文件打开数，觉得和这一块没有多大的关系 * soft nofile 655350 * hard nofile 655350 hadoop soft ...
大数据-Hadoop-HDFS(四)：DataNode【数据完整性校验算法：crc、md5、sha1】【DataNode掉线时限：HDFS默认超过10分钟+30秒无心跳则死亡】
u013250861的博客
04-01 507
思考：如果电脑磁盘里面存储的数据是控制高铁信号灯的红灯信号（1）和绿灯信号（0），但是存储该数据的磁盘坏了，一直显示是绿灯，是否很危险？（1）一个数据块在DataNode上以文件形式存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括数据块的长度，块数据的校验和，以及时间戳。（2）DataNode启动后向NameNode注册，通过后，周期性（6小时）的向NameNode上报所有的块信息。（4）常见的校验算法crc（32），md5（128），sha1（160）。
【Hadoop】超大规模集群大批量写操作引发Namenode性能瓶颈
m0_37956758的博客
09-12 1169
namenode 单一锁机制
hdfs清理数据后，Blocks Pending Deletion持续增长导致磁盘不释放问题记录
10-31 2858
hdfs清理数据后，Blocks Pending Deletion持续增长导致磁盘不释放问题记录
Hadoop3.1删除大量文件(清理回收站，程序删除)导致RPC飙高
gaofeng的博客
12-03 4274
1、现象： Hadoop3.1删除大量文件（程序删除、清理回收站）导致RPC高延迟 2、调研与监控分析 2.1、逻辑如下图 2.2监控分析 采用Alibaba arthas监控方法栈耗时 Arthas监控NameNode删除大量大文件方法栈耗时截图 3、结论 Hadoop新版本的FoldedTreeSet（存储block Info）的红黑树实现是有问题的，尤其在删除大量文件时，表现很糟糕 4、解决(优化)方案 将JIRA 中linyiqun先生提出的HDFS-13831的patch打入(对应github
11HDFS的读写流程&NameNode、DataNode工作机制——好程序
01-20
Hadoop Distributed File System（HDFS）是一种基于分布式计算的文件系统，它遵循“分而治之”的原则，将大文件和大量文件分割成小块，并在多台服务器上分布式存储，以便于并行处理和分析大规模数据。在大数据处理中...
【HDFS篇10】DataNode相关概念1
08-04
心跳机制确保了NameNode能及时获取DataNode的状态，心跳间隔通常设置为3秒。 3. **故障检测**: 如果NameNode在设定的时间内（默认10分钟，可通过`dfs.namenode.heartbeat.recheck-interval`配置）未收到某个...
HDFS分布式文件系统
01-27
HDFS的设计灵感来源于Google的GFS（Google File System），旨在为分布式计算环境提供可靠的、可扩展的存储解决方案。 【文件系统基础】：文件系统是计算机中组织和管理数据的一种方式，它通过文件名来定位文件的...
分布式文件系统HDFS的起源、架构、组成、特性以及数据操作方式
01-27
分布式文件系统HDFS，全称为Hadoop Distributed File System，是为了解决大数据处理场景下存储问题而诞生的。HDFS的出现是分布式技术发展的重要里程碑，尤其在云计算、大数据领域，分布式系统已经成为不可或缺的一...
hadoophdfs写入文件原理详解共2页.pdf.zip
10-30
这些是HDFS写入文件的基本原理，但实际操作中还会涉及更多细节，如RPC（Remote Procedure Call）协议用于客户端与服务器之间的通信，心跳机制确保DataNode与NameNode之间的状态同步，以及HDFS的故障恢复机制等。...
详解HDFS多文件Join操作的实例
08-29
HDFS 多文件 Join 操作实例详解 HDFS（Hadoop Distributed File System）是一种分布式文件系统，用于存储和管理大规模数据。在数据处理过程中， Join 操作是一种常见的数据处理方式，用于将多个文件或表格中的数据...
解码超大bson文件,并上传到hdfs解决方案.doc
最新发布
03-06
解码超大bson文件,并上传到hdfs解决方案
【Hadoop】文件删除过程以及Namenode RPC处理请求优化之IBR
m0_37956758的博客
09-21 984
描述hadoop删除文件过程以及IBR
hadoop之datanode节点超时时间设置与HDFS冗余数据块的自动删除
ZG_24的博客
06-17 1779
一  Datanode节点超时时间设置datanode进程死亡或者网络故障造成datanode无法与namenode通信，namenode不会立即把该节点判定为死亡，要经过一段时间，这段时间暂称作超时时长。HDFS默认的超时时长为10分钟+30秒。如果定义超时时间为timeout，则超时时长的计算公式为： timeout  = 2 * heartbeat.recheck.interval + 10...
HDFS源码解析之DataNode启动流程与心跳机制(四)
百看不如一RUN
07-05 493
DataNode 启动流程 1. 查看DataNode类的注释 1.1 DataNode类注释 /********************************************************** * DataNode is a class (and program) that stores a set of * blocks for a DFS deployment. A single deployment can * have one or many DataNodes.
hdfs datanode节点死掉
weixin_38374023的博客
03-28 5968
1 现象一个节点dead，日志如下： GC pool 'PS MarkSweep' had collection(s): count=13 time=24256ms 2018-03-28 17:52:51,624 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: opWriteBlock BP-229667812-10.100.208.
评论 5
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值