錯誤總結分享:  使用了hadoop挺長時間了，多數人應該很熟悉它的特點了吧，但是今天突然遇到個錯誤，從來沒見過，一時自己也想不到是什麼原因，就在網上查了一些資料，得到了解決的辦法，再次分享一下。

               過程: 使用kettle 資料清洗工具在進行同步任務的過程中，最後資料是被載入到hdfs的，這裡用shell指令碼實現，hdfs  dfs  -put  -r  /hdfs的目錄。 結果程式執行到這一步的時候報錯了。錯誤描述就是文章標題的錯誤，翻譯過來就是租賃不匹配，大概就是這樣子，看了別人的 分析就理解了錯誤。開始還以為是叢集中節點掛了呢。

           HDFS（及大多數分散式檔案系統）不支援檔案併發寫，Lease是HDFS用於保證唯一寫的手段

• 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對哪些路徑持有租約；
• 先分享到這裡