Question

编辑：我终于找到了问题所在。一些文件具有非常高的复制因子集，我将我的集群减少到2个节点。一旦我减少了对这些文件的复制因子，退役就会很快成功结束。

我已在dfs.hosts.exclude和mapred.hosts.exclude文件中添加了要停用的节点，并执行了此命令：

bin/hadoop dfsadmin -refreshNodes。

在NameNode UI中，我在Decommissioning Nodes下看到了这个节点，但它花了太长时间，而且我没有太多关于该节点退役的数据。

解析节点总是需要很长时间，还是我应该看一些地方？我不确定到底发生了什么。

我在此节点上也没有看到任何损坏的块：

$ ./hadoop/bin/hadoop fsck -blocks /
 Total size:    157254687 B
 Total dirs:    201
 Total files:   189 (Files currently being written: 6)
 Total blocks (validated):      140 (avg. block size 1123247 B) (Total open file blocks (not validated): 1)
 Minimally replicated blocks:   140 (100.0 %)
 Over-replicated blocks:        6 (4.285714 %)
 Under-replicated blocks:       12 (8.571428 %)
 Mis-replicated blocks:         0 (0.0 %)
 Default replication factor:    2
 Average block replication:     1.9714285
 Corrupt blocks:                0
 Missing replicas:              88 (31.884058 %)
 Number of data-nodes:          3
 Number of racks:               1
FSCK ended at Mon Jul 22 14:42:45 IST 2013 in 33 milliseconds


The filesystem under path '/' is HEALTHY

$ ./hadoop/bin/hadoop dfsadmin -report
Configured Capacity: 25357025280 (23.62 GB)
Present Capacity: 19756299789 (18.4 GB)
DFS Remaining: 19366707200 (18.04 GB)
DFS Used: 389592589 (371.54 MB)
DFS Used%: 1.97%
Under replicated blocks: 14
Blocks with corrupt replicas: 0
Missing blocks: 0

-------------------------------------------------
Datanodes available: 3 (3 total, 0 dead)

Name: 10.40.11.107:50010
Decommission Status : Decommission in progress
Configured Capacity: 8452341760 (7.87 GB)
DFS Used: 54947840 (52.4 MB)
Non DFS Used: 1786830848 (1.66 GB)
DFS Remaining: 6610563072(6.16 GB)
DFS Used%: 0.65%
DFS Remaining%: 78.21%
Last contact: Mon Jul 22 14:29:37 IST 2013


Name: 10.40.11.106:50010
Decommission Status : Normal
Configured Capacity: 8452341760 (7.87 GB)
DFS Used: 167412428 (159.66 MB)
Non DFS Used: 1953377588 (1.82 GB)
DFS Remaining: 6331551744(5.9 GB)
DFS Used%: 1.98%
DFS Remaining%: 74.91%
Last contact: Mon Jul 22 14:29:37 IST 2013


Name: 10.40.11.108:50010
Decommission Status : Normal
Configured Capacity: 8452341760 (7.87 GB)
DFS Used: 167232321 (159.49 MB)
Non DFS Used: 1860517055 (1.73 GB)
DFS Remaining: 6424592384(5.98 GB)
DFS Used%: 1.98%
DFS Remaining%: 76.01%
Last contact: Mon Jul 22 14:29:38 IST 2013

Answer 1

即使您没有太多数据，退役也不是即时过程。

首先，当您退役时，这意味着数据必须被复制很多块（取决于您的块大小有多大），这可能很容易压倒您的群集并导致操作问题，所以我相信这有点节流。

此外，根据您使用的Hadoop版本，监视decomissions的线程只会经常唤醒。在早期版本的Hadoop中，它过去大约需要5分钟，但我相信现在这是每分钟或更短时间。

停止正在进行意味着正在复制这些块，所以我想这实际上取决于您拥有多少数据，而您只需要等待，因为这不会完全利用您的群集这个任务。

Answer 2

在退役过程中，临时或临时文件会自动清除。现在缺少这些文件，hadoop无法识别它是如何丢失的。因此，即使对所有其他文件进行了实际的解除授权，退役过程也会一直等待直到解决。

在Hadoop GUI中 - 如果您注意到参数“Under-Replicated Blocks的数量”并未随时间减少或几乎不变，那么这就是可能的原因。

所以使用以下命令列出文件

hadoop fsck / -files -blocks -racks

如果您看到这些文件是临时的而不是必需的，请删除这些文件或文件夹

示例：hadoop fs -rmr /var/local/hadoop/hadoop/.staging/*（在此处给出正确的路径）

这样可以立即解决问题。取消调试的节点将在5分钟内移动到死节点。

Answer 3

请注意，如果您没有比文件级别或默认级别的复制因子更多的活动数据节点，则状态将不会更改或将花费更长时间（并最终失败）。

Hadoop节点需要很长时间才能退役

3 个答案: