प्राधिकरण के साथ ClickHouse को प्राधिकरण के बिना ClickHouse से माइग्रेशन का परिणाम क्या था

थोड़ा पृष्ठभूमि के साथ शुरू करते हैं। हमारी कंपनी में, एक परियोजना रखरखाव के अधीन है, जो हाल ही में परीक्षण / विकास के चरण में थी। उस समय, इसने 3 शर्ड्स, 2 रेप्लिकाज़ के साथ ClickHouse का उपयोग किया। यह देखते हुए कि इस परियोजना के बुनियादी ढांचे का परीक्षण किया गया था और इसके लिए किसी अतिरिक्त प्राधिकरण की आवश्यकता नहीं थी (क्लिकहाउस बंद खंड में था), किसी ने भी यह सवाल नहीं पूछा।

समय के साथ, यह परियोजना बढ़ती गई, ClickHouse एक उत्पादन का आधार बन गया और हमने पुराने बुनियादी ढांचे से डेटा को नए 1 शार्क, 1 प्रतिकृति के साथ 3 अलग-अलग सर्वरों पर क्लिक किया (ClickHouse को स्टेटफुलसेट्स के आधार पर कुबेरनेट्स में होस्ट किया गया है) और निश्चित रूप से प्राधिकरण के साथ।

यहां आगे क्या हुआ।

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

परीक्षण डेटाबेस की तालिका Table_1 के ClickHouse प्रतिकृतियों में से एक के लिए कंसोल आउटपुट निम्न है:

ls -l /var/lib/clickhouse/data/test/table_1/test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000 | tail -n 10 -rw-r----- 1 clickhouse clickhouse 1472 Jul 8 08:26 9983.bin -rw-r----- 1 clickhouse clickhouse 1453 Jul 8 08:26 9985.bin -rw-r----- 1 clickhouse clickhouse 1383 Jul 8 08:26 9987.bin -rw-r----- 1 clickhouse clickhouse 1461 Jul 8 08:27 9989.bin -rw-r----- 1 clickhouse clickhouse 1458 Jul 8 08:28 9991.bin -rw-r----- 1 clickhouse clickhouse 1468 Jul 8 08:29 9993.bin -rw-r----- 1 clickhouse clickhouse 1413 Jul 8 08:29 9995.bin -rw-r----- 1 clickhouse clickhouse 1509 Jul 8 08:32 9997.bin -rw-r----- 1 clickhouse clickhouse 1504 Jul 8 08:32 9999.bin drwxr-x--- 2 clickhouse clickhouse 4096 Sep 16 12:59 tmp 

यानी डेटा को एक विशिष्ट प्रतिकृति के स्थानीय वितरित तालिका में रखा गया था, लेकिन उस समय किसी अज्ञात कारण से, इसे एक पोस्टफ़िक्स शार्पड (जैसे कि प्रतिकृतिमेजरट्री) के साथ एक तालिका में नहीं ले जाया गया था, जो स्थानीय तालिका के माध्यम से इसे एक्सेस करके सभी क्लस्टर साइकस से पहुँचा जा सकता है (पोस्टफ़िक्स के बिना) sharded)।

जैसा कि यह विश्लेषण के बाद निकला, डेटा जो पुराने बुनियादी ढांचे पर क्लिकहाउस डेटाबेस में दर्ज किया गया था, अर्थात्। प्राधिकरण को सक्षम करने से पहले, उन्हें अब नए बुनियादी ढांचे पर प्रतिकृतियों के बीच वितरित नहीं किया जा सकता है, क्योंकि नए ClickHouse सर्वर पर, प्राधिकरण पहले ही सक्षम हो चुका है।

ऐसा क्यों? जब डेटा को बिना प्राधिकरण के ClickHouse को लिखा जाता है, तो निम्न प्रपत्र का लिंक संबंधित डेटाबेस निर्देशिकाओं में क्लिकहाउस डेटादिर निर्देशिका और तालिका (डेटाबेस से किए गए अनुरोध के आधार पर लिंक उत्पन्न होता है) में उत्पन्न होता है:

 test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000 

आइए इसे और अधिक विस्तार से देखें। उपर्युक्त लिंक को उपयोगकर्ता test_usr द्वारा एक्सेस किया गया है, लेकिन प्राधिकरण के लिए पासवर्ड निर्दिष्ट नहीं है। और क्या होता है, यदि डेटाबेस में प्राधिकरण को सक्षम करने से पहले, ClickHouse में बहुत बड़ी मात्रा में डेटा दर्ज किया गया था, जो बिन लॉग का गठन किया था, और पुराने सर्वर पर ClickHouse के पास उन्हें खोने का समय नहीं था, तो नए ClickHouse सर्वर पर प्राधिकरण को सक्षम करने और पुराने को नष्ट करने के बाद पुराना नहीं खोया नए सर्वरों के लिए बिन-लॉग, ये बिन-लॉग अब नहीं खेले जा सकते, क्योंकि लिंक पहले ही उपयोगकर्ता test_usr के लिए प्राधिकरण के बिना उत्पन्न हो गया है।

ClickHouse में सभी नए आने वाले डेटा भी इसी डेटाबेस निर्देशिका और तालिकाओं में बिन-लॉग उत्पन्न करेंगे, जो तब खेला जाएगा, लेकिन एक अलग लिंक के साथ, जहां प्राधिकरण का संकेत दिया गया है (क्योंकि एप्लिकेशन पहले से ही नए बुनियादी ढांचे पर ClickHouse का उपयोग कर रहा है उपयोगकर्ता test_usr के लिए पासवर्ड के साथ बनाया गया है, अन्यथा अनुरोध डेटाबेस तक नहीं पहुंचेगा):

 test_usr:password@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000 

क्योंकि डेटा को अतुल्यकालिक रूप से डेटाबेस को लिखा जाता है, अर्थात, उन्हें पहले एक स्थानीय क्लिकहाउस प्रतिकृति पर रखा जाता है जिसे एक्सेस किया गया था, और उसके बाद ही उन्हें क्लस्टर के अन्य प्रतिकृतियों पर भेजा जाता है।

इसलिए, पुराना डेटा जो स्थानीय क्लिकहाउस प्रतिकृतियों में से एक पर दर्ज किया गया था, लेकिन बाकी क्लस्टर प्रतिकृतियों के बीच वितरित नहीं किया गया था (क्योंकि उत्पन्न लिंक में उपयोगकर्ता के लिए पासवर्ड नहीं था, लेकिन यह पहले से ही सेट था), फिर उन्हें एक्सेस भी नहीं किया जा सकता है प्रतिकृति पर पढ़ने के लिए जिस पर अनपेक्षित बिन-लॉग सीधे स्थित थे।

हमने समस्या को कैसे हल किया और बिना डेटा खोए नहीं छोड़ा?

सब कुछ काफी सरल निकला। यह डेटाबेस में बिना डेटा के निम्नलिखित हेरफेर करने के लिए पर्याप्त है:

1. समस्या डेटाबेस की तालिकाओं में से प्रत्येक के लिए उत्पन्न लिंक को आवश्यक रूप में बदला (बदला हुआ) नाम दिया जाना चाहिए:
   

    mv /var/lib/clickhouse/data/test/table_1/test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000 /var/lib/clickhouse/data/test/table_1/test_usr:password@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000 

2. ClickHouse प्रतिकृतियों को पुनः आरंभ करें, जो बिन लॉग्स को वापस खेलने की प्रक्रिया शुरू करता है और उन्हें हमारे शार्प टेबल (ReplicatedMergeTree) में रखता है।

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

हमारे ब्लॉग पर अन्य लेख भी पढ़ें:

• नगीनेक्स वेब सर्वर के साथ स्प्रिंग एप्लीकेशन की ब्लू-ग्रीन तैनाती
• GitLab CI / CD का उपयोग करके कई पाइपलाइन कैसे चलाएं
• /etc/resolv.conf कुबेरनेट्स पॉड्स के लिए, ndots: 5 विकल्प, क्योंकि इससे एप्लिकेशन के प्रदर्शन पर प्रतिकूल प्रभाव पड़ सकता है
• गोलंग में प्रसंग पैकेज को समझना
• डॉक छवियों को कम करने के लिए तीन सरल ट्रिक्स