在工作中遇到部門間數據合作，需跨不同版本集群拷貝數據，從hadoop 2.6.0-cdh5.7.0 拷貝數據到hadoop 2.7.1， 記錄所碰到的問題及解決方案。
distcp基礎用法
比如拷貝A集群（src集群）的A1目錄到B集群（dest集群）的B1目錄，
1.同版本集群拷貝（hdfs協議）：
在dest集群（目標集群）運行命令：
hadoop distcp ?hdfs://10.190.11.303:3333/user/common/liming/A1/ ? ?hdfs://10.120.20.22/user/zhangsan/B1/
其中10.190.11.303是src集群的namenode地址， 3333是src集群的rpc端口（hdfs-site.xml中可查看）。10.120.20.22是dest集群的namenode IP地址
2.跨集群版本拷貝（hftp協議）：
同樣在dest集群（目標集群）運行命令：
hadoop distcp hftp://10.190.11.303:50070/user/common/liming/A1/? hdfs://10.120.20.22/user/zhangsan/B1/
類似hdfs，但是目標集群的開頭要用hftp, 而且端口要變為http端口（hdfs-site.xml中可查看，如果未配置，則需要配置）。
注意：如果集群間版本跨度不大，比如hadoop 2.6.0和hadoop2.7.0則也可以使用hdfs協議。
問題一：Java.net.SocketTimeoutException: connect timed out
原因分析：日志顯示連接超時， 我們用的是hftp協議拷貝，需要連接src集群10.190.11.303 的50070端口，而此時連接超時，說明相關權限未開通。
解決辦法：聯系運維開通dest集群到src集群所有namenode 的50070端口的防火墻。如果防火墻開通了，還是出現此問題，可以修改src集群的iptables，將dest集群的所有機器加入iptables。
問題二： org.apache.hadoop.ipc.StandbyException : //s.apache.org/sbnn-error
原因分析：搜索"s.apache.org/sbnn-error", 發現它是個網站，順便訪問了一下“ http://s.apache.org/sbnn-error ” , 自動跳轉到apache的wiki頁面， 顯示：
3.17. What does the message "Operation category READ/WRITE is not supported in state standby" mean?
In an HA-enabled cluster, DFS clients cannot know in advance which namenode is active at a given time. So when a client contacts a namenode and it happens to be the standby, the READ or WRITE operation will be refused and this message is logged. The client will then automatically contact the other namenode and try the operation again. As long as there is one active and one standby namenode in the cluster, this message can be safely ignored.
大意是說，DFS的客戶端不知道哪一個namenode是活躍（active）的，所以當客戶端連接一個備用的（standby）namenode時，讀或寫操作會被拒絕，所以打出這個日志。客戶端會自動連接另一個namenode，重新操作。
但事實上，在我們這并沒有自動連接另一個namenode，我也不知道為什么。
解決辦法：換一個namenode, 保證新的namenode是活躍的。即用 hadoop distcp hftp://活躍的namenode:50070/path ....
問題三：java.net.UnknowHostException
原因分析：圖中可以看到，distcp job已經啟動了，map 0%,? 但是報了UnknowHostException:pslaves55，可能的原因是在從datanode取數據時，用的是host pslave55, 而這個host是src集群特有的，dest集群不識別，所以報UnknowHostException.
解決辦法：在dest集群中配置hosts文件，將src集群中所有的host和ip的對應關系追加到dest集群中的hosts文件中，使得dest集群在訪問host名時（如pslave55）能自動映射到ip。
問題四： map 100%之后連接超時Java.net.SocketTimeoutException: connect timed out
錯誤的分析：map 100% 完成了，說明數據讀取完畢，但是沒有寫進目標集群，說明寫目標集群有問題。
正確分析：由于在網上沒找到相關資料，我下載了hadoop源碼， 查看了RetriableFileCopyCommand.java的源碼，報錯的位置是302行，如下圖。
繼續查看代碼，getInputStream方法中有可能報連接超時的就是fs.open(path)這一行代碼。繼續研究相關源碼，以及在源碼中增加調試信息，運行得知，該文件系統fs已經初始化完畢，正是HftpFileSystem,其他的變量，如path等均正確。所以是文件系統open src集群上的文件時連接超時，還有相關的端口沒有打開。
在執行distcp時，用tcpdump 抓取實際運行map的機器到src集群 host的tcp連接情況，如下圖，也能發現數據length =0 ， 沒有真正的拷貝數據。
解決方案：開通dest集群到src集群所有datanode的http相關端口（默認為50075）。
(在本次項目中，我們誤打誤撞開通了dest集群到src集群所有datanode的控制端口50010， 然后運行hdfs協議就能跨集群版本拷貝數據了，所以沒有再開通50075端口。)
問題五： java.io.IOException:Check-sum mismatch?
分析：該問題很常見，能在網上查到，是因為不同版本hadoop 的checksum版本不同，老版本用crc32,新版本用crc32c。
When we run distcp between source and destination clusters with different versions, we may get the below exception. This is because, distcp using MRV2(YARN) from older version to newer version, may fail with these checksum error messages. Each hadoop versions use different checksum versions. Older one uses CRC32 and newer versions use CRC32C.
來自：http://www.catchdba.com/2014/03/18/distcp-between-two-different-versions-of-hadoop/
解決辦法：只要在distcp時增加兩個參數（-skipcrccheck -update），忽略crc檢查即可。注意-skipcrccheck參數要與-update同時使用才生效。
總結
要實現跨集群拷貝，如拷貝src集群的數據到dest集群，需要確認以下事情：
（1）確認dest集群機器都能ping通src集群所有ip。
（2）按需開通如下端口的防火墻，如使用hdfs協議需要開通1，2項；如使用hftp協議至少需要開通1，3，4項。
（3）如果部門間的端口防火墻已經開通，但還是telnet不同，請確認src集群的iptables已經加入了dest集群ip。
（4）如果在dest集群有UnknowHostException，則需要將src集群的host與ip映射關系追加到dest集群的hosts文件中。
（5）如果出現org.apache.hadoop.ipc.StandbyException, 換一個活躍的namenode試一試。
完。
附:常用HDFS端口配置
參考網頁：
distcp 官方文檔：https://hadoop.apache.org/docs/r1.0.4/cn/distcp.html? ， ? ? ? ? ? https://hadoop.apache.org/docs/r1.2.1/distcp.html?
hdfs端口配置: http://www.cnblogs.com/ggjucheng/archive/2012/04/17/2454590.html
