HDFS 中文件操作的錯誤集錦

問題1  Java ApI執行追加寫入時：無法寫入
問題描述： ①當前數據節點無法寫入，②追加文件需要再次請求。

 

問題2  命令行執行追加寫入時：無法寫入
問題描述： 當前數據節點無法寫入

 

 

 

 

 

 

問題3  Java ApI上傳時.crc校驗文件的校檢失敗
問題描述： Java ApI上傳文件時對原文件進行檢驗，導致無法正常上傳

 

 

問題4   多次使用hadoop namenode  -format 格式化導致數據節點無法正常啟動
問題描述：  使用hadoop namenode  -format 格式化時多次格式化造成了spaceID不一致	Jps命令沒有datanode

 

三、解決方案：（列出遇到的問題和解決辦法，列出沒有解決的問題）：

問題1/2  Java ApI或命令行執行追加寫入時：無法寫入
問題原因	我的環境中有3個datanode，備份數量設置的是3。在寫操作時，它會在pipeline中寫3個機器。默認replace-datanode-on-failure.policy是DEFAULT,如果系統中的datanode大於等於3，它會找另外一個datanode來拷貝。目前機器只有3台，因此只要一台datanode出問題，就一直無法寫入成功。
問題解決： （針對JAVA API）	在所要執行的代碼中添加兩句：       conf.set("dfs.client.block.write.replace-datanode-on-failure.policy","NEVER"); conf.set("dfs.client.block.write.replace-datanode-on-failure.enable","true");  一次執行，可能無響應，再次請求即可。 詳細內容可參考以下教程解釋：https://blog.csdn.net/caiandyong/article/details/44730031?utm_source=copy
問題解決： （針對命令行）	修改hdfs-site.xml文件，添加或者修改如下兩項：     <property>         <name>dfs.client.block.write.replace-datanode-on-failure.enable</name>         <value>true</value>     </property>         <property>     <name>dfs.client.block.write.replace-datanode-on-failure.policy</name>         <value>NEVER</value>     </property>
注解	對於dfs.client.block.write.replace-datanode-on-failure.enable，客戶端在寫失敗的時候，是否使用更換策略，默認是true沒有問題 對於，dfs.client.block.write.replace-datanode-on-failure.policy，default在3個或以上備份的時候，是會嘗試更換結點嘗試寫入datanode。而在兩個備份的時候，不更換datanode，直接開始寫。對於3個datanode的集群，只要一個節點沒響應寫入就會出問題，所以可以關掉。   詳解參考：https://blog.csdn.net/themanofcoding/article/details/79512754?utm_source=copy

 

 

問題3 Java ApI上傳時.crc校驗文件的校檢失敗
問題原因	Hadoop客戶端將本地文件text.txt上傳到hdfs上時，hadoop會通過fs.FSInputChecker判斷需要上傳的文件是否存在.crc校驗文件。如果存在.crc校驗文件，則會進行校驗。如果校驗失敗，自然不會上傳該文件。 可能因為之前對原文件有更改，所以會對校檢文件的校驗進行干擾。
問題解決：	cd到文件所在路徑，ls -a查看，果然存在.text.crc文件 $ ls -a 問題就很簡單了，刪除.crc文件 $ rm .text.crc 再上傳即可。如下圖所示。     詳細內容可參考以下教程解釋：https://blog.csdn.net/bitcarmanlee/article/details/50969025?utm_source=copy
注解	crc文件來源 DFS命令：hadoop fs -getmerge srcDir destFile 這類命令在執行的時候，會將srcDir目錄下的所有文件合並成一個文件，保存在destFile中，同時會在本地磁盤生成一個. destFile.crc的校驗文件。 DFS命令：hadoop fs -get -crc src dest 這類命令在執行的時候，會將src文件，保存在dest中，同時會在本地磁盤生成一個. dest.crc的校驗文件。 如何避免 在使用hadoop fs -getmerge srcDir destFile命令時，本地磁盤一定會（沒有參數可以關閉）生成相應的.crc文件。 所以如果需要修改getmerge獲取的文件的內容，再次上傳到DFS時，可以采取以下2種策略進行規避： 1. 刪除.crc文件 2. 將getmerge獲取的文件修改后重新命名，如使用mv操作，再次上傳到DFS中。 更多關於Hadoop的文章，可以參考：http://www.cnblogs.com/gpcuster/tag/Hadoop/

 

 

問題4   多次使用hadoop namenode  -format 格式化導致數據節點無法正常啟動
問題原因	在第一次格式化dfs后，啟動並使用了hadoop，后來又重新執行了格式化命令（hdfs namenode -format)，這時namenode的clusterID會重新生成，而datanode的clusterID 保持不變。
問題解決：  使用hadoop namenode  -format 格式化時多次格式化造成了spaceID不一致	1、停止集群（切換到/sbin目錄下） $./stop-all.sh 2、刪除在hdfs中配置的data目錄（即在core-site.xml中配置的hadoop.tmp.dir對應文件件）下面的所有數據; $ rm -rf /home/hadoop/hdpdata/* 3、重新格式化namenode(切換到hadoop目錄下的bin目錄下) $ ./hadoop namenode -format 4、重新啟動hadoop集群（切換到hadoop目錄下的sbin目錄下） $./start-all.sh 在使用hadoop dfsadmin -report查看使用情況，結果如下圖所示： ok沒有錯誤了。再次上傳文件，成功。 轉載：http://blog.csdn.net/weiyongle1996/article/details/74094989 詳見：https://blog.csdn.net/love666666shen/article/details/74350358