在停用过程中，临时或暂存文件会自动清除。这些文件现在丢失了，hadoop无法识别这些文件是如何丢失的。因此，即使其他所有文件的实际停用都已完成，停用过程仍会一直等待，直到问题得到解决。
在hadoopgui中，如果您注意到参数“under-replicated blocks”没有随着时间的推移而减少或几乎保持不变，那么这就是可能的原因。
所以使用下面的命令列出文件
hadoop fsck/-文件-块-机架
如果您看到这些文件是临时的，并且不是必需的，那么请删除这些文件或文件夹
示例：hadoopfs-rmr/var/local/hadoop/hadoop/.staging/*（在这里给出正确的路径）
这将立即解决问题。解除委托的节点将在5分钟内移动到死节点。

您应该知道，由于hadoop要想表现良好，它确实希望数据有多个副本。通过删除节点，您消除了数据以最佳方式可用的可能性，并对集群施加了额外的压力，以确保可用性。
i、 e.通过删除一个节点，您可以强制在其他地方创建其所有数据的额外副本。因此，您不应该只是为了好玩而这样做，除非您使用与默认配置不同的数据管理模式（即在集群中保留3个副本）。
为了让hadoop集群运行良好，您需要将数据实际存储在集群中。否则，您就不能真正地将计算移到数据上，因为数据也不在那里。关于hadoop的很多内容都是关于在通过网络发送数据之前可以执行计算的“智能驱动器”。
因此，为了使这一点合理化，您可能需要以某种方式拆分集群。让一组节点保留原始数据的3个主副本，并让一些“附加”节点仅用于存储中间数据并对该部分执行计算。永远不要更改主节点，因此它们不需要重新分发数据。仅在加载项节点为空时关闭它们？但这可能还没有实现。

如果您以前没有设置过dfs排除文件，请按照1-3进行操作。否则从4开始。
关闭namenode。
将dfs.hosts.exclude设置为指向空的排除文件。
重新启动namenode。
在dfs排除文件中，使用完整主机名或ip或ip:端口格式指定节点。
在mapred.exclude中执行相同操作
执行 bin/hadoop dfsadmin -refreshNodes . 这将强制namenode重新读取排除文件并启动停用过程。
执行 bin/hadoop mradmin -refreshNodes 监视namenode和jobtracker web ui，并确认正在进行解除委托过程。更新可能需要几秒钟。像这样的消息 "Decommission complete for node XXXX.XXXX.X.XX:XXXXX" 将在完成停用时出现在namenode日志文件中，此时您可以从集群中删除节点。
当这个过程完成后，namenodeui将把datanode列为decommissioned。jobtracker页面将显示活动节点的更新数量。跑 bin/hadoop dfsadmin -report 验证。在排除的节点上停止datanode和tasktracker进程。
如果不打算将计算机重新引入集群，请将其从包含和排除文件中删除。
要将节点添加为datanode和tasktracker，请参见hadoop常见问题页面
编辑：当要从集群中删除活动节点时，作业会发生什么变化？
在要取消委托的节点上运行的作业将受到影响，因为在该节点上计划的作业的任务将被标记为killed\u unclean（对于map和reduce任务）或killed（对于作业设置和清理任务）。有关详细信息，请参见jobtracker.java中的第4633行。作业将被通知无法完成该任务。大多数情况下，作业跟踪器会重新安排执行时间。但是，在多次重复失败之后，它可能会决定让整个作业失败或成功。请参见jobinprogress.java中的第2957行。