ग्रीनप्लम 4 से ग्रीनप्लम 5 में डेटा माइग्रेट करते समय हम असंगतता को कैसे दूर करते हैं

जब हमने बड़े डेटा को संसाधित करने के लिए एक उपकरण चुना, तो हमने विभिन्न विकल्पों पर विचार किया - मालिकाना और खुला स्रोत दोनों। हमने प्रौद्योगिकियों के तेजी से अनुकूलन, पहुंच और लचीलेपन की संभावनाओं का मूल्यांकन किया। संस्करणों के बीच प्रवास भी शामिल है। नतीजतन, हमने खुले स्रोत ग्रीनप्लम समाधान को चुना, जिसमें से सभी हमारी आवश्यकताओं को पूरा करते थे, लेकिन एक महत्वपूर्ण मुद्दे के समाधान की आवश्यकता थी।



तथ्य यह है कि ग्रीनप्लम डेटाबेस फ़ाइलें संस्करण 4 और 5 एक दूसरे के साथ संगत नहीं हैं, और इसलिए एक संस्करण से दूसरे संस्करण में एक साधारण उन्नयन असंभव है। डेटा माइग्रेशन केवल डेटा अपलोड करने और डाउनलोड करने के माध्यम से किया जा सकता है। इस पोस्ट में मैं इस प्रवास के संभावित विकल्पों के बारे में बात करूंगा।

प्रवासन विकल्प का मूल्यांकन

pg_dump और psql (या pg_restore)

दर्जनों टेराबाइट्स की बात आने पर यह बहुत धीमा है, क्योंकि सभी डेटा को मास्टर नोड्स के माध्यम से अपलोड और डाउनलोड किया जाता है। लेकिन डीडीएल और छोटे तालिकाओं को स्थानांतरित करने के लिए पर्याप्त तेजी से। आप एक स्रोत क्लस्टर और एक गंतव्य क्लस्टर पर एक पाइप के माध्यम से एक ही समय में एक फ़ाइल और pg_dump और psql दोनों को अपलोड कर सकते हैं। pg_dump केवल एक फाइल अपलोड करता है जिसमें DDL कमांड और COPY डेटा कमांड दोनों होते हैं। प्राप्त आंकड़ों को आसानी से संसाधित किया जा सकता है, जो नीचे दिखाया जाएगा।

gptransfer

संस्करण ग्रीनप्लम 4.2 या बाद के संस्करण की आवश्यकता है। यह आवश्यक है कि स्रोत क्लस्टर और गंतव्य क्लस्टर दोनों एक साथ काम करें। ओपन सोर्स संस्करण के लिए बड़ी डेटा तालिकाओं को स्थानांतरित करने का सबसे तेज़ तरीका। लेकिन यह पद्धति उच्च ओवरहेड के कारण खाली और छोटी तालिकाओं को स्थानांतरित करने के लिए बहुत धीमी है।

gptransfer डेटा ट्रांसफर करने के लिए DDL और gpfdist को ट्रांसफर करने के लिए pg_dump का उपयोग करता है। गंतव्य क्लस्टर पर प्राथमिक सेगमेंट की संख्या स्रोत क्लस्टर पर होस्ट सेगमेंट से कम नहीं होनी चाहिए। "सैंडबॉक्स" क्लस्टर बनाते समय यह विचार करना महत्वपूर्ण है, अगर मुख्य समूहों से डेटा उन्हें स्थानांतरित किया जाएगा, और गैन्ट्रांसफ़ायर उपयोगिता का उपयोग करने की योजना बनाई गई है। यहां तक ​​कि अगर सेगमेंट होस्ट कम हैं, तो आप उनमें से प्रत्येक पर आवश्यक सेगमेंट की तैनाती कर सकते हैं। गंतव्य क्लस्टर पर खंडों की संख्या स्रोत क्लस्टर की तुलना में कम हो सकती है, हालांकि, इससे डेटा ट्रांसफर गति पर प्रतिकूल प्रभाव पड़ेगा । समूहों के बीच, प्रमाणपत्रों पर ssh प्रमाणीकरण को कॉन्फ़िगर किया जाना चाहिए।



यह फास्ट मोड के लिए योजना है जब गंतव्य क्लस्टर पर खंडों की संख्या स्रोत क्लस्टर पर संख्या से अधिक या उसके बराबर होती है। उपयोगिता का प्रक्षेपण रिसीवर क्लस्टर के मास्टर नोड पर आरेख में दिखाया गया है। इस मोड में, स्रोत क्लस्टर पर एक बाहरी लेखन तालिका बनाई जाती है, जो प्रत्येक खंड पर नामित पाइप पर डेटा लिखती है। कमांड INSERT INTO writable_external_table का चयन करें * Source_table से निष्पादित किया जाता है। पाइप नाम के डेटा को gpfdist द्वारा पढ़ा जाता है। केवल पढ़ने के लिए, गंतव्य क्लस्टर पर एक बाहरी तालिका भी बनाई गई है। तालिका उस डेटा को इंगित करती है जो एक ही नाम के प्रोटोकॉल पर gpfdist प्रदान करता है। INSERT INTO target_table select * से external_gpfdist_table कमांड को निष्पादित किया जाता है। गंतव्य क्लस्टर के खंडों के बीच डेटा को स्वचालित रूप से पुनर्वितरित किया जाता है।



और यह धीमे मोड के लिए योजना है, या, जैसा कि स्वयं gptransfer बाहर देता है, मानक मोड। मुख्य अंतर यह है कि स्रोत क्लस्टर के प्रत्येक खंड-मेजबान पर, इस खंड-होस्ट के सभी खंडों के लिए एक gpfdist जोड़ी लॉन्च की जाती है। एक बाहरी रिकॉर्ड तालिका एक डेटा रिसीवर के रूप में gpfdist अभिनय को संदर्भित करती है। इसके अलावा, अगर बाहरी तालिका के LOCATION पैरामीटर में लिखने के लिए कई मान इंगित किए जाते हैं, तो डेटा लिखते समय समान रूप से खंडों को gpfdist द्वारा वितरित किया जाता है। मेजबान खंड पर gpfdist के बीच डेटा नामित पाइप के माध्यम से पारित किया जाता है। इस वजह से, डेटा ट्रांसफर की गति कम है, लेकिन यह अभी भी मास्टर नोड के माध्यम से डेटा स्थानांतरित करते समय की तुलना में तेजी से निकलता है।

जब ग्रीनप्लम 4 से ग्रीनप्लम 5 तक डेटा माइग्रेट किया जा रहा है, तो गंतव्य क्लस्टर के मास्टर नोड पर gptransfer चलना चाहिए। यदि हम स्रोत क्लस्टर पर gptransfer चलाते हैं, तो हमें pg_catalog.gp_segment_configuration तालिका में san_mounts फ़ील्ड की अनुपस्थिति की त्रुटि pg_catalog.gp_segment_configuration है:

 gptransfer -t big_db.public.test_table --dest-host=gpdb-target-master.local --dest-database=big_db --source-map-file=/data/master/gpseg-1/host_and_IP_segments --batch-size=10 --sub-batch-size=50 --truncate 20190109:12:46:13:010893 gptransfer:gpdb-source-master.local:gpadmin-[INFO]:-Starting gptransfer with args: -t big_db.public.test_table --dest-host=gpdb-target-master.local --dest-database=big_db --source-map-file=/data/master/gpseg-1/host_and_IP_segments --batch-size=10 --sub-batch-size=50 --truncate 20190109:12:46:13:010893 gptransfer:gpdb-source-master.local:gpadmin-[INFO]:-Validating options... 20190109:12:46:13:010893 gptransfer:gpdb-source-master.local:gpadmin-[INFO]:-Retrieving configuration of source Greenplum Database... 20190109:12:46:13:010893 gptransfer:gpdb-source-master.local:gpadmin-[INFO]:-Retrieving configuration of destination Greenplum Database... 20190109:12:46:14:010893 gptransfer:gpdb-source-master.local:gpadmin-[CRITICAL]:-gptransfer failed. (Reason='error 'ERROR: column "san_mounts" does not exist LINE 2: ... SELECT dbid, content, status, unnest(san_mounts... ^ ' in ' SELECT dbid, content, status, unnest(san_mounts) FROM pg_catalog.gp_segment_configuration WHERE content >= 0 ORDER BY content, dbid '') exiting... 

आपको GPHOME चरों की भी जांच करनी होगी ताकि वे स्रोत क्लस्टर और गंतव्य क्लस्टर के बीच मेल खा सकें। अन्यथा, हम एक अजीब तरह की त्रुटि प्राप्त करते हैं (स्रोत और लक्ष्य के अलग-अलग GPHOME पथ होने पर gptransfer उपयोगिता विफल हो जाती है)।

 gptransfer -t big_db.public.test_table --source-host=gpdb-source-master.local --dest-database=big_db --source-map-file=/data1/master/gpseg-1/source_host_and_IP_segments --b atch-size=10 --sub-batch-size=50 --truncate 20190109:14:12:07:031438 gptransfer:mdw:gpadmin-[INFO]:-Starting gptransfer with args: -t big_db.public.test_table --source-host=gpdb-spurce-master.local --dest-database=big_db --source-map-file=/data1/master/gpseg-1/source_host_and_IP_segments --b atch-size=10 --sub-batch-size=50 --truncate 20190109:14:12:07:031438 gptransfer:mdw:gpadmin-[INFO]:-Validating options... 20190109:14:12:07:031438 gptransfer:mdw:gpadmin-[ERROR]:-gptransfer: error: GPHOME directory does not exist on gpdb-source-master.local 

आप बस संगत सिमिलिंक बना सकते हैं और सत्र में GPHOME चर को ओवरराइड कर सकते हैं जिसमें gptransfer शुरू होता है।

जब गंतव्य क्लस्टर पर gptransfer शुरू किया जाता है, तो विकल्प "--source-map-file" को एक फ़ाइल की ओर इशारा करना चाहिए जिसमें स्रोत क्लस्टर के प्राथमिक सेगमेंट वाले मेजबानों और उनके आईपी पते की सूची होती है। उदाहरण के लिए:

 sdw1,192.0.2.1 sdw2,192.0.2.2 sdw3,192.0.2.3 sdw4,192.0.2.4 

विकल्प - "-फुल" के साथ न केवल टेबल, बल्कि पूरे डेटाबेस को स्थानांतरित करना संभव है, हालांकि, उपयोगकर्ता डेटाबेस को गंतव्य क्लस्टर पर नहीं बनाया जाना चाहिए। आपको यह भी याद रखना चाहिए कि बाहरी तालिकाओं को स्थानांतरित करते समय सिंटैक्स परिवर्तनों के कारण समस्याएं हैं।

आइए, अतिरिक्त ओवरहेड का मूल्यांकन करें, उदाहरण के लिए, gptarnsfer का उपयोग करके 10 खाली तालिकाओं (big_db.public.test_table_2 से big_db.public.test_table_11) की प्रतिलिपि बनाकर:

 gptransfer -f temp_filelist.txt --source-host=gpdb-source-master.local --dest-database=big_db --source-map-file=/data1/master/gpseg-1/source_host_and_IP_segments_dev --batch-size=10 --sub-ba tch-size=50 --truncate 20190118:06:14:08:031521 gptransfer:mdw:gpadmin-[INFO]:-Starting gptransfer with args: -f temp_filelist.txt --source-host=gpdb-source-master.local --dest-database=big_db --source-map-file=/data1/master/gpseg-1/source_host_and_IP_segments_dev --batch-size=10 --sub-batch-size=50 --truncate 20190118:06:14:08:031521 gptransfer:mdw:gpadmin-[INFO]:-Validating options... 20190118:06:14:08:031521 gptransfer:mdw:gpadmin-[INFO]:-Retrieving configuration of source Greenplum Database... 20190118:06:14:08:031521 gptransfer:mdw:gpadmin-[INFO]:-Retrieving configuration of destination Greenplum Database... 20190118:06:14:09:031521 gptransfer:mdw:gpadmin-[INFO]:-Retrieving source tables... 20190118:06:14:12:031521 gptransfer:mdw:gpadmin-[INFO]:-Checking for gptransfer schemas... 20190118:06:14:22:031521 gptransfer:mdw:gpadmin-[INFO]:-Retrieving list of destination tables... 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-Reading source host map file... 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-Building list of source tables to transfer... 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-Number of tables to transfer: 10 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-gptransfer will use "standard" mode for transfer. 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-Validating source host map... 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-Validating transfer table set... 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-The following tables on the destination system will be truncated: 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-   big_db.public.test_table_2 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-   big_db.public.test_table_3 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-   big_db.public.test_table_4 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-   big_db.public.test_table_5 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-   big_db.public.test_table_6 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-   big_db.public.test_table_7 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-   big_db.public.test_table_8 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-   big_db.public.test_table_9 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-   big_db.public.test_table_10 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-   big_db.public.test_table_11 … 20190118:06:14:34:031521 gptransfer:mdw:gpadmin-[INFO]:-Using batch size of 10 20190118:06:14:34:031521 gptransfer:mdw:gpadmin-[INFO]:-Using sub-batch size of 16 20190118:06:14:34:031521 gptransfer:mdw:gpadmin-[INFO]:-Creating work directory '/home/gpadmin/gptransfer_31521' 20190118:06:14:34:031521 gptransfer:mdw:gpadmin-[INFO]:-Creating schema public in database edw_prod... 20190118:06:14:40:031521 gptransfer:mdw:gpadmin-[INFO]:-Starting transfer of big_db.public.test_table_5 to big_db.public.test_table_5... … 20190118:06:15:02:031521 gptransfer:mdw:gpadmin-[INFO]:-Validation of big_db.public.test_table_4 successful 20190118:06:15:02:031521 gptransfer:mdw:gpadmin-[INFO]:-Removing work directories... 20190118:06:15:02:031521 gptransfer:mdw:gpadmin-[INFO]:-Finished. 

नतीजतन, 10 खाली तालिकाओं के हस्तांतरण में लगभग 16 सेकंड (14: 40-15: 02) लगे, यानी एक तालिका - 1.6 सेकंड। इस समय के दौरान, हमारे मामले में, लगभग 100 एमबी डेटा को pg_dump और psql का उपयोग करके डाउनलोड किया जा सकता है।

gp_dump और gp_restore

एक विकल्प के रूप में: उन पर ऐड-ऑन का उपयोग करें, gpcrondump & gpdbrestore, क्योंकि gp_dump & gp_restore को पदावनत घोषित किया गया है। हालाँकि gpcrondump & gpdbrestore स्वयं इस प्रक्रिया में gp_dump & gp_restore का उपयोग करते हैं। यह सबसे सार्वभौमिक तरीका है, लेकिन सबसे तेज़ नहीं है। Gp_dump के साथ बनाई गई बैकअप फाइलें मास्टर नोड पर DDL कमांड के एक सेट का प्रतिनिधित्व करती हैं, और प्राथमिक खंडों पर, मुख्य रूप से COPY कमांड और डेटा के सेट। ऐसे मामलों के लिए उपयुक्त है जब गंतव्य क्लस्टर और स्रोत क्लस्टर का एक साथ संचालन प्रदान करना संभव नहीं है। ग्रीनप्लम के पुराने संस्करणों में दोनों हैं, और नए में: gp_dump , gp_restore ।

Gpbackup और gprestore उपयोगिताओं

Gp_dump और gp_restore के प्रतिस्थापन के रूप में बनाया गया। उनके काम के लिए, ग्रीनप्लम संस्करण न्यूनतम 4.3.17 आवश्यक है ( const MINIMUM_GPDB4_VERSION = "4.3.17" )। काम की योजना gpbackup और gprestore के समान है, जबकि काम की गति बहुत तेज है। बड़े डेटाबेस के लिए DDL कमांड प्राप्त करने का सबसे तेज़ तरीका। डिफ़ॉल्ट रूप से, यह वैश्विक वस्तुओं को स्थानांतरित करता है, पुनर्प्राप्ति के लिए आपको "gprestore --with-globals" निर्दिष्ट करने की आवश्यकता होती है। वैकल्पिक पैरामीटर "- मुखमैथुन" बैकअप बनाते समय नौकरियों की संख्या (और सत्रों को डेटाबेस में) सेट कर सकता है। इस तथ्य के कारण कि कई सत्र बनाए जाते हैं, सभी तालों को प्राप्त होने तक डेटा की स्थिरता सुनिश्चित करना महत्वपूर्ण है। एक उपयोगी विकल्प "--with- आँकड़े" भी है, जो आपको निष्पादन योजनाओं के निर्माण के लिए उपयोग की जाने वाली वस्तुओं पर आँकड़े स्थानांतरित करने की अनुमति देता है। अधिक जानकारी यहाँ ।

Gpcopy उपयोगिता

डेटाबेस की प्रतिलिपि बनाने के लिए एक उपयोगिता gpcopy है - gptansfer के लिए एक प्रतिस्थापन। लेकिन यह केवल धुरी से ग्रीनप्लम के मालिकाना संस्करण में शामिल है, 4.3.26 से शुरू - खुले स्रोत संस्करण में यह उपयोगिता नहीं है । स्रोत क्लस्टर पर काम करते समय, कमांड COPY source_table TO PROGRAM 'gpcopy_helper ...' ऑन सेगमेंट CSV IGNORE EXTERNAL PARTITIONS को निष्पादित किया जाता है। क्लस्टरिंग साइड पर, एक अस्थायी बाहरी तालिका CREATE EXTERNAL WEB TEMP TABLE external_temp_table (LIKE target_table) EXECUTE '... gpcopy_helper –listen ...' बनाई गई है और INSERT INTO target_table SELECT * external_temp_table कमांड को निष्पादित किया गया है। परिणामस्वरूप, gpcopy_helper-the -enen पैरामीटर के साथ गंतव्य क्लस्टर के प्रत्येक खंड पर लॉन्च किया जाता है, जो स्रोत क्लस्टर के खंडों से gpcopy_helper का डेटा प्राप्त करता है। इस तरह की डेटा ट्रांसमिशन योजना के कारण, साथ ही साथ संपीड़न, ट्रांसमिशन की गति बहुत अधिक है। क्लस्टर के बीच, प्रमाणपत्रों पर ssh प्रमाणीकरण को भी कॉन्फ़िगर किया जाना चाहिए। मैं यह भी नोट करना चाहता हूं कि उन मामलों के लिए जहां एक ही सर्वर पर स्रोत और गंतव्य क्लस्टर स्थित हैं, उन मामलों के लिए gpcopy के पास एक सुविधाजनक विकल्प "--truncate-source-after" (और "--validate") है।

डेटा ट्रांसफर रणनीति

स्थानांतरण रणनीति निर्धारित करने के लिए, हमें यह निर्धारित करने की आवश्यकता है कि हमारे लिए क्या अधिक महत्वपूर्ण है: डेटा को जल्दी से स्थानांतरित करें, लेकिन अधिक श्रम और संभवतः कम मज़बूती से (gpbackup, gptransfer या एक संयोजन) या कम श्रम के साथ, लेकिन धीमी (gpbackup या युग्मन के बिना gptransfer)।

डेटा स्थानांतरित करने का सबसे तेज़ तरीका - जब कोई स्रोत क्लस्टर और गंतव्य क्लस्टर है - निम्न:

• DDL को gpbackup --metadata-only का उपयोग करके प्राप्त करें, कन्वर्ट करें और psql का उपयोग करके पाइप लाइन के माध्यम से लोड करें
  
• सूचकांक हटाएं
  
• 100 एमबी या उससे अधिक के आकार के साथ तालिकाएँ स्थानांतरण करें
  
• Pg_dump का उपयोग करके तालिका को 100 एमबी से कम के आकार के साथ स्थानांतरित करें | पहले पैराग्राफ में के रूप में psql
  
• हटाए गए इंडेक्स बनाएं
  

यह विधि हमारे माप में gp_dump & gp_restore से कम से कम 2 गुना तेज़ निकली। वैकल्पिक विधियाँ: सभी डेटाबेस को gptransfer –full, gpbackup और gprestore, या gp_dump & gp_restore का उपयोग करके स्थानांतरित करना।

निम्न क्वेरी द्वारा तालिका आकार प्राप्त किए जा सकते हैं:

 SELECT nspname AS "schema", coalesce(tablename, relname) AS "name", SUM(pg_total_relation_size(class.oid)) AS "size" FROM pg_class class JOIN pg_namespace namespace ON namespace.oid = class.relnamespace LEFT JOIN pg_partitions parts ON class.relname = parts.partitiontablename AND namespace.nspname = parts.schemaname WHERE nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast', 'pg_bitmapindex', 'pg_aoseg', 'gp_toolkit') GROUP BY nspname, relkind, coalesce(tablename, relname), pg_get_userbyid(class.relowner) ORDER BY 1,2; 

आवश्यक रूपांतरण

Greenplum संस्करण 4 और 5 में बैकअप फ़ाइलें भी पूरी तरह से संगत नहीं हैं। इसलिए, Greenplum 5 में, सिंटैक्स में बदलाव के कारण, CREATE EXTERNAL TABLE और COPY कमांड में INTO ERROR TABLE पैरामीटर नहीं है, और आपको SET पैरामीटर gp_ignore -error_table को सही पर सेट करने की आवश्यकता है ताकि बैकअप की पुनर्स्थापना गलती से विफल न हो। पैरामीटर सेट के साथ, हमें बस एक चेतावनी मिलती है।

इसके अलावा, पांचवें संस्करण ने बाहरी pxf तालिकाओं के साथ बातचीत करने के लिए एक अलग प्रोटोकॉल पेश किया, और इसका उपयोग करने के लिए, आपको LOCATION पैरामीटर को बदलने और pxf सेवा को कॉन्फ़िगर करने की आवश्यकता है।
यह भी ध्यान देने योग्य है कि gp_dump & gp_restore बैकअप फ़ाइलों में दोनों मास्टर नोड पर और प्रत्येक प्राथमिक सेगमेंट पर, SET gp_strict_xml_parse पैरामीटर को झूठा करने के लिए सेट किया गया है। Greenplum 5 में ऐसा कोई पैरामीटर नहीं है, और परिणामस्वरूप, हमें एक त्रुटि संदेश मिलता है।

यदि बाह्य तालिकाओं के लिए gphdfs प्रोटोकॉल का उपयोग किया गया था, तो आपको लाइन 'gphdfs: //' पर बाहरी तालिकाओं के लिए LOCATION पैरामीटर में स्रोतों की सूची बैकअप फ़ाइलों की जाँच करने की आवश्यकता है। उदाहरण के लिए, केवल 'gphdfs: //hadoop.local: 8020' होना चाहिए। यदि अन्य रेखाएं हैं, तो उन्हें सादृश्य द्वारा मास्टर नोड पर प्रतिस्थापन स्क्रिप्ट में जोड़ा जाना चाहिए।

 grep -o gphdfs\:\/\/.*\/ /data1/master/gpseg-1/db_dumps/20181206/gp_dump_-1_1_20181206122002.gz | cut -d/ -f1-3 | sort | uniq gphdfs://hadoop.local:8020 

हम मास्टर नोड (उदाहरण के रूप में gp_dump डेटा फ़ाइल का उपयोग करके) पर प्रतिस्थापन करते हैं:

 mv /data1/master/gpseg-1/db_dumps/20181206/big_db_gp_dump_1_1_20181206080001.gz /data1/master/gpseg-1/db_dumps/20181206/big_db_gp_dump_1_1_20181206080001.old.gz gunzip -c /data1/master/gpseg-1/db_dumps/20181206/big_db_gp_dump_1_1_20181206080001.old.gz | sed "s#'gphdfs://hadoop.local:8020#'pxf:/#g" | sed "s/\(^.*pxf\:\/\/.*'\)/\1\\&\&\?PROFILE=HdfsTextSimple'/" |sed "s#'&#g" | sed 's/SET gp_strict_xml_parse = false;/SET gp_ignore_error_table = true;/g' | gzip -1 > /data1/master/gpseg-1/db_dumps/20181206/big_db_gp_dump_1_1_20181206080001.gz nets 

हाल के संस्करणों में, HdfsTextSimple प्रोफ़ाइल नाम को पदावनत घोषित किया गया है , नया नाम hdfs: पाठ है।

परिणाम

इम्प्लिक्ट टेक्स्ट कास्टिंग , नए रिसोर्स ग्रुप्स क्लस्टर रिसोर्स मैनेजमेंट मैकेनिज्म, रिसोर्स क्यूज, जीपीओआरसीए ऑप्टिमाइज़र की जगह, जो कि ग्रीनप्लम 5 में डिफ़ॉल्ट रूप से शामिल है, क्लाइंट के साथ छोटी-मोटी समस्याएं आर्टिकल के दायरे से बाहर रहीं।

मैं ग्रीनप्लाम के छठे संस्करण की रिलीज़ की प्रतीक्षा कर रहा हूं, जो वसंत 2019 के लिए निर्धारित है: पोस्टग्रेसीक्यू 9.4 के साथ संगतता स्तर, पूर्ण पाठ खोज, जीआईएन सूचकांक समर्थन, रेंज प्रकार, JSONB, zStd संपीड़न। इसके अलावा, ग्रीनप्लम 7 के लिए प्रारंभिक योजनाएं ज्ञात हुईं: पोस्टग्रेक्यूएल न्यूनतम 9.6, पंक्ति स्तर सुरक्षा, स्वचालित मास्टर विफलता के साथ संगतता स्तर। डेवलपर्स प्रमुख संस्करणों के बीच अपडेट के लिए डेटाबेस अपग्रेड यूटिलिटीज की उपलब्धता का भी वादा करते हैं, इसलिए इसे जीना आसान हो जाएगा।

यह लेख रोस्टेलकॉम डेटा प्रबंधन टीम द्वारा तैयार किया गया था