错误总结分享: 使用了hadoop挺长时间了，多数人应该很熟悉它的特点了吧，但是今天突然遇到个错误，从来没见过，一时自己也想不到是什么原因，就在网上查了一些资料，得到了解决的办法，再次分享一下。
过程: 使用kettle 数据清洗工具在进行同步任务的过程中，最后数据是被加载到hdfs的，这里用shell脚本实现，hdfs dfs -put -r /hdfs的目录。 结果程序执行到这一步的时候报错了。错误描述就是文章标题的错误，翻译过来就是租赁不匹配，大概就是这样子，看了别人的 分析就理解了错误。开始还以为是集群中节点挂了呢。
HDFS（及大多数分布式文件系统）不支持文件并发写，Lease是HDFS用于保证唯一写的手段。
Lease可以看做是一把带时间限制的写锁，仅持有写锁的客户端可以写文件。
租约的有效期
HDFS的Lease设定了两个时间限制：softLimit（默认1m），hardLimit（默认1h）；
- Lease持有者在softLimit时限内可以写文件，且不用担心被其它写者抢走Lease；
- 在超过softLimit仅未及hardLimit时限可以续约，否则Lease可能被其它写者申请走；
- 在超过hardLimit后，Lease会被释放，写者需要重新申请Lease；对hardLimit的超时检查是由Namenode的lmthread线程执行；
-
mapper数超多，导致解析很长时间没有完成。
进一步发现FTP在合并文件的时候报错，再进一步发现同一个IP地址，同一个OMC启动了三个mapper进程去下载数据导致文件合并失败。
发现是修改了ftp.xml文件，没有删除原来的文件，而是以一个bak文件存放。
删除这些bak文件，mapper数量正常。
原mapper数1731个，删除之后mapper数41个,采集正常。
-
租约的释放
对应于有效期的设计，Lease会在三种情况下被释放： - 客户端显式地请求NameNode对某个文件进行 recoverLease操作；
- Lease超过softLimit，此时另一客户端申请该文件Lease；
- Lease超过harLimit，由Namenode的lmthread线程发现并执行释放；
-
租约的释放会引发DataNode对block的recovery过程，当DataNode完成recover block过程后，文件会被关闭。详见Recover Block
租约的结构
Lease由<holder, lastUpdate, paths>组成； - holder是客户端的名字，支持以holder为粒度对holder对应的所有Lease进行续约；
- lastUpdate是该holder上次续约时间，用于进行超时检查；
-
NameNodeResourceMonitor
NameNodeResourceMonitor默认每5秒执行一次检查，查看保存image/edits的目录所在的磁盘卷空间。
磁盘卷空间信息获取是通过调用linux的shell命令实现。
如果剩余可用空间小于默认的100M，则认为该卷磁盘空间不足。当所有磁盘卷空间都不足时，则NameNode会进入safeMode； - paths是指该holder对哪些路径持有租约；
- 先分享到这里