6

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

dfs.hosts.exclude我已经在and文件中添加了要退役的节点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
4

3 回答 3

7

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

首先，当您停用时，这意味着数据必须复制相当多的块（取决于您的块大小），这很容易使您的集群不堪重负并导致操作问题，因此我认为这在一定程度上受到了限制。

此外，根据您使用的 Hadoop 版本，监控停用的线程只会每隔一段时间唤醒一次。在早期版本的 Hadoop 中，它曾经是大约 5 分钟，但我相信现在是每分钟或更短。

正在进行的停用意味着正在复制块，所以我想这真的取决于你有多少数据，你只需要等待，因为这不会完全利用你的集群来完成这项任务。

于 2013-07-22T18:59:53.757 回答
1

在停用过程中，临时或暂存文件会自动清理。这些文件现在丢失了，hadoop 无法识别这些文件是如何丢失的。因此，即使所有其他文件的实际停用已完成，停用过程也会一直等待直到解决。

在 Hadoop GUI 中 - 如果您注意到参数“复制不足的块数”没有随时间减少或几乎恒定，那么这可能是原因。

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

hadoop fsck / -files -blocks -racks

如果您看到这些文件是临时文件且不需要，则删除这些文件或文件夹

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

这将立即解决问题。退役节点将在 5 分钟内转移到死节点。

于 2014-11-10T07:37:20.100 回答
1

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

于 2016-06-02T05:27:14.693 回答