Hadoop distcp hftp hdfs क्रॉस-क्लस्टर कॉपी आम समस्याएं संक्षेप में प्रस्तुत की जाती हैं

Hadoop Distcp Hftp Hdfs Cross Cluster Copy Common Problems Are Summarized



अंतर-विभागीय डेटा सहयोग के साथ काम करने की प्रक्रिया में, क्लस्टर के विभिन्न संस्करणों में डेटा की प्रतिलिपि बनाना, हडप 2.6.0-cdh5.7.0 से हडूप 2.7.1 तक डेटा की प्रतिलिपि बनाना, और समस्याओं और समाधानों को रिकॉर्ड करना है ।

Distcp का मूल उपयोग

उदाहरण के लिए, A क्लस्टर (src क्लस्टर) के B1 निर्देशिका B क्लस्टर (गंतव्य क्लस्टर) की A1 निर्देशिका की प्रतिलिपि बनाएँ



1. एक ही संस्करण (क्लस्टर प्रोटोकॉल) की क्लस्टर कॉपी



गंतव्य क्लस्टर (लक्ष्य क्लस्टर) में कमांड चलाएँ:



हूड hdfs : //10.190.11.303: 3333 / उपयोगकर्ता / आम / सीमित / A1 / hdfs: //10.120.20.22/user/zhangsan/B1/

जहाँ 10.190.11.303 src क्लस्टर का नामांकित पता है, और 3333 src क्लस्टर का आरपीसी पोर्ट (hdfs-site.xml में देखा जा सकता है) 10.120.20.22 गंतव्य क्लस्टर का नामकोड आईपी पता है

2. क्रॉस-क्लस्टर संस्करण की प्रतिलिपि (hftp प्रोटोकॉल)



गंतव्य क्लस्टर (लक्ष्य क्लस्टर) में कमांड भी चलाएं:

हूड Hftp : //10.190.11.303: 50070 है / उपयोगकर्ता / आम / सीमित / A1 / hdfs: //10.120.20.22/user/zhangsan/B1/

एचडीएफएस के समान, लेकिन लक्ष्य क्लस्टर की शुरुआत का उपयोग किया जाता है Hftp , और बंदरगाह को http पोर्ट में बदला जाना चाहिए (आप इसे hdfs-site.xml में देख सकते हैं, यदि कॉन्फ़िगर नहीं किया गया है, तो आपको कॉन्फ़िगर करने की आवश्यकता है)।

नोट: यदि क्लस्टर्स के बीच संस्करण की अवधि बड़ी नहीं है, जैसे कि हडूप 2.6.0 और हडूप 2.7.0, तो एचडीएफएस प्रोटोकॉल का भी उपयोग किया जा सकता है।

प्रश्न 1: Java.net.SocketTimeoutException: समयबद्ध कनेक्ट करें

कारण विश्लेषण: लॉग दिखाता है कि कनेक्शन समय समाप्त हो गया है। हमने hftp प्रोटोकॉल कॉपी का उपयोग किया और src क्लस्टर में 10.190.11.303 के 50070 पोर्ट से कनेक्ट करने की आवश्यकता है। इस समय, कनेक्शन समयबद्ध हो गया, यह दर्शाता है कि संबंधित प्राधिकरण नहीं खोला गया है।

समाधान: ओ एंड एम से संपर्क करें और सभी नामीनोड्स के पोर्ट 50070 के फायर क्लस्टर को src क्लस्टर में सेट करें। यदि फ़ायरवॉल चालू है और यह समस्या अभी भी होती है, तो आप src क्लस्टर के iptables को संशोधित कर सकते हैं और गंतव्य क्लस्टर की सभी मशीनों को iptables में जोड़ सकते हैं।

समस्या दो

कारण विश्लेषण: 's.apache.org/sbnn-error' के लिए खोजें और पता लगाएं कि यह एक वेबसाइट है, और वैसे, 'http://s.apache.org/sbnn-error' पर जाएँ, स्वचालित रूप से कूदें अपाचे का विकी पृष्ठ, प्रदर्शन:

3.17। क्या संदेश 'ऑपरेशन श्रेणी READ / WRITE राज्य स्टैंडबाय में समर्थित नहीं है' मतलब है?

हा-इनेबल्ड क्लस्टर में, DFS क्लाइंट पहले से नहीं जान सकते कि कौन सा नामेनोड एक निश्चित समय पर सक्रिय है। इसलिए जब कोई क्लाइंट किसी नेमेनोड से संपर्क करता है और यह स्टैंडबाय होता है, तो READ या WRITE ऑपरेशन से इनकार कर दिया जाएगा और यह संदेश लॉग हो जाएगा। क्लाइंट तब स्वचालित रूप से अन्य नामीनोड से संपर्क करेगा और फिर से ऑपरेशन का प्रयास करेगा। जब तक क्लस्टर में एक सक्रिय और एक स्टैंडबाय नमनोड है, तब तक इस संदेश को सुरक्षित रूप से अनदेखा किया जा सकता है।

सामान्य विचार यह है कि डीएफएस क्लाइंट को यह पता नहीं होता है कि कौन सा नामेनोड सक्रिय है, इसलिए जब ग्राहक स्टैंडबाय नमनोड से जुड़ता है, तो रीड या राइट ऑपरेशन को अस्वीकार कर दिया जाएगा, इसलिए यह लॉग मुद्रित होता है। क्लाइंट स्वचालित रूप से किसी अन्य नामेनोड से कनेक्ट होगा और ऑपरेशन को पुनरारंभ करेगा।

लेकिन वास्तव में, हमने स्वचालित रूप से एक और नामीनोड कनेक्ट नहीं किया है, और मुझे नहीं पता कि क्यों।

समाधान: यह सुनिश्चित करने के लिए कि नया नामेनोड सक्रिय है, एक नेमोडोड बदलें। हडॉप डिस्टक hftp का उपयोग करने के लिए तैयार: // सक्रिय उद्देश्य : 50070 / पाथ…।

प्रश्न तीन: java.net.UnknowHostException

कारण विश्लेषण: आप देख सकते हैं कि डिस्टकैप काम शुरू कर दिया गया है, 0% मैप किया गया है, लेकिन अनजाने रिपोर्ट किया गया है: pslaves55। संभावित कारण यह है कि डेटा डेटनोड से लाते समय, होस्ट pslave55 का उपयोग किया जाता है, और यह होस्ट src क्लस्टर के लिए अद्वितीय है। हां, गंतव्य क्लस्टर को मान्यता नहीं दी गई है, इसलिए अनजानेहॉस्टसेप्शन की सूचना दी गई है।

समाधान: होस्ट फ़ाइल को क्लस्टर क्लस्टर में कॉन्फ़िगर करें, सभी होस्ट और ips के बीच पत्राचार को src क्लस्टर में होस्ट्स फ़ाइल को गंतव्य क्लस्टर में जोड़ दें, ताकि होस्ट नाम का उपयोग करते समय गंतव्य क्लस्टर स्वचालित रूप से आईपी पर मैप कर सके (जैसे as pslave55)।

प्रश्न 4: 100% मानचित्र के बाद कनेक्शन का समय Java.net.SocketTimeoutException: समयबद्ध कनेक्ट करें

त्रुटि विश्लेषण: नक्शा 100% पूरा हुआ, यह दर्शाता है कि डेटा रीडिंग पूरी हो गई है, लेकिन लक्ष्य क्लस्टर में नहीं लिखा गया है, यह दर्शाता है कि लक्ष्य क्लस्टर के साथ कोई समस्या है।

सही विश्लेषण: चूंकि मुझे इंटरनेट पर प्रासंगिक जानकारी नहीं मिली, इसलिए मैंने हैडूप सोर्स कोड डाउनलोड किया और रिट्रीएबलफिल्पीकोमांड.जवा के सोर्स कोड की जांच की। त्रुटि स्थान रेखा 302 है, जैसा कि नीचे दिखाया गया है।

कोड को देखना जारी रखें, getInputStream विधि में कनेक्शन टाइमआउट की रिपोर्ट करना संभव है। संबंधित स्रोत कोड का अध्ययन करना जारी रखें, और स्रोत कोड में डिबगिंग जानकारी जोड़ें। यह पता चला है कि फ़ाइल सिस्टम fs को इनिशियलाइज़ किया गया है। यह HftpFileSystem है, और अन्य चर जैसे पथ सही हैं। तो यह फ़ाइल सिस्टम ओपन src क्लस्टर फ़ाइल कनेक्शन टाइमआउट है, और संबंधित पोर्ट खुला नहीं है।

Distcp निष्पादित करते समय, मशीन के बीच tcp कनेक्शन को खींचने के लिए tcpdump का उपयोग करें जो वास्तव में मैप और src क्लस्टर होस्ट को चलाता है। जैसा कि निम्नलिखित आंकड़े में दिखाया गया है, आप यह भी पा सकते हैं कि डेटा की लंबाई = 0 है और कोई वास्तविक प्रतिलिपि डेटा नहीं है।

समाधान: डेस्ट क्लस्टर में src क्लस्टर (डिफ़ॉल्ट 50075) में सभी डेटाटोड के HTTP से संबंधित पोर्ट खोलें।

(इस परियोजना में, हमने गलती से क्लस्टर में सभी डेटाैनोड्स के कंट्रोल पोर्ट्स को src क्लस्टर में खोल दिया, और फिर क्लस्टर संस्करण में डेटा कॉपी करने के लिए hdfs प्रोटोकॉल चलाएं, इसलिए 50075 पोर्ट का कोई भी उद्घाटन नहीं होता है।

प्रश्न 5: java.io.IOException: चेक-सम मिसमैच

विश्लेषण: यह समस्या बहुत आम है और इसे ऑनलाइन पाया जा सकता है क्योंकि Hadoop के विभिन्न संस्करणों के चेकसम संस्करण भिन्न हैं। पुराना संस्करण crc32 का उपयोग करता है और नया संस्करण crc32c का उपयोग करता है।

जब हम विभिन्न संस्करणों के साथ स्रोत और गंतव्य समूहों के बीच distcp चलाते हैं, तो हमें नीचे अपवाद मिल सकता है। ऐसा इसलिए है, क्योंकि पुराने संस्करण से नए संस्करण में MRV2 (YARN) का उपयोग करके distcp, इन चेकसम त्रुटि संदेशों के साथ विफल हो सकता है। प्रत्येक हडॉप संस्करण विभिन्न चेकसम संस्करणों का उपयोग करते हैं। पुराना एक CRC32 का उपयोग करता है और नए संस्करण CRC32C का उपयोग करते हैं।

प्रेषक: http://www.catchdba.com/2014/03/18/distcp-between-two-different-versions-of-hadoop/

समाधान: distcp के दौरान बस दो पैरामीटर (-Sipcrccheck -update) जोड़ें और crc चेक को अनदेखा करें। ध्यान दें कि -cipcrccheck पैरामीटर को प्रभावी होने के लिए -update के साथ एक साथ उपयोग किया जाना चाहिए।

सारांश में

क्रॉस-क्लस्टर कॉपी प्राप्त करने के लिए, जैसे कि src क्लस्टर के डेटा को डेस्ट क्लस्टर में कॉपी करना, आपको निम्न बातों की पुष्टि करने की आवश्यकता है:

(1) पुष्टि करें कि नियति क्लस्टर मशीन src क्लस्टर में सभी IP को पिंग कर सकती है।

(२) आवश्यकतानुसार निम्नलिखित बंदरगाहों का फ़ायरवॉल खोलें। यदि आप hdfs प्रोटोकॉल का उपयोग करते हैं, तो आपको 1, 2 आइटम खोलने की आवश्यकता है यदि आप hftp प्रोटोकॉल का उपयोग करते हैं, तो आपको कम से कम 1, 3, 4 आइटम खोलने की आवश्यकता है।

(3) यदि विभागों के बीच पोर्ट फ़ायरवॉल खोला गया है, लेकिन टेलनेट अलग है, तो कृपया पुष्टि करें कि src क्लस्टर के iptables को डेस्ट क्लस्टर आईपी में जोड़ा गया है।

(4) यदि गंतव्य क्लस्टर में UnknowHostException है, तो आपको गंतव्य क्लस्टर के होस्ट फ़ाइल के लिए src क्लस्टर के होस्ट और आईपी के बीच मैपिंग संबंध को जोड़ने की आवश्यकता है।

(5) यदि कोई org.apache.hadoop.ipc.StandbyException होती है, तो एक और सक्रिय नामेनोड का प्रयास करें।

समाप्त।

जुड़ा हुआ: आम HDFS पोर्ट कॉन्फ़िगरेशन

संदर्भ वेब पेज:

distcp आधिकारिक दस्तावेज: https://hadoop.apache.org/docs/r1.0.4/cn/distcp.html, https://hadoop.apache.org/docs/r1.2.1/distcp.html

एचडीएफएस पोर्ट कॉन्फ़िगरेशन: http://www.cnblogs.com/ggjucheng/archive/2012/04/17/2454590.html