WHM/cPanel सर्वर पर ProxySQL के साथ MySQL प्रतिकृति:भाग दो

श्रृंखला के पहले भाग में, हमने आपको दिखाया कि WHM और cPanel के साथ ProxySQL के साथ MySQL प्रतिकृति सेटअप को कैसे परिनियोजित किया जाए। इस भाग में, हम रखरखाव, प्रबंधन, विफलता के साथ-साथ स्टैंडअलोन सेटअप पर लाभ के लिए कुछ पोस्ट-डिप्लॉयमेंट ऑपरेशन दिखाने जा रहे हैं।

MySQL उपयोगकर्ता प्रबंधन

इस एकीकरण के सक्षम होने के साथ, MySQL उपयोगकर्ता प्रबंधन को WHM या cPanel से करना होगा। अन्यथा, ProxySQL mysql_users तालिका हमारे प्रतिकृति मास्टर के लिए कॉन्फ़िगर की गई चीज़ों के साथ समन्वयित नहीं होगी। मान लीजिए कि हमने पहले से ही एक उपयोगकर्ता बनाया है जिसे कहा जाता है anyn_user1 (MySQL उपयोगकर्ता नाम स्वचालित रूप से cPanel द्वारा MySQL सीमा का अनुपालन करने के लिए प्रीफ़िक्स किया गया है), और हम नीचे दिए गए डेटाबेस की तरह anyn_db1 को असाइन करना चाहते हैं:

उपरोक्त के परिणामस्वरूप ProxySQL में निम्न mysql_users तालिका आउटपुट होगा:

यदि आप cPanel के बाहर MySQL संसाधन बनाना चाहते हैं, तो आप ClusterControl -> प्रबंधित करें -> स्कीमा और उपयोगकर्ता का उपयोग कर सकते हैं सुविधा और फिर डेटाबेस उपयोगकर्ता को ProxySQL में आयात करें ClusterControl -> Nodes -> ProxySQL नोड चुनें -> उपयोगकर्ता -> उपयोगकर्ता आयात करें .

Proxysqlhook मॉड्यूल जिसका उपयोग हम ProxySQL उपयोगकर्ताओं को सिंक करने के लिए करते हैं, डिबगिंग लॉग को /usr/local/cpanel/logs/error_log. इस फ़ाइल का उपयोग यह देखने और समझने के लिए करें कि पर्दे के पीछे क्या होता है। यदि हम सॉफ्टेकुलस का उपयोग करके ज़िकुला नामक एक वेब एप्लिकेशन इंस्टॉल करते हैं, तो निम्नलिखित पंक्तियाँ cPanel लॉग फ़ाइल में दिखाई देंगी:

[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL database severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL virtual user severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [cpanel] **** Reading ProxySQL information: Host: 192.168.0.16, Port: 6032, User: proxysql-admin *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Inserting severaln_ziku703 into ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Updating severaln_ziku703 default schema in ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****

आपको कुछ दोहराई जाने वाली पंक्तियाँ दिखाई देंगी जैसे "चेकिंग अगर {DB उपयोगकर्ता} मौजूद है" क्योंकि WHM प्रत्येक डेटाबेस उपयोगकर्ता अनुरोध के लिए कई MySQL उपयोगकर्ता / होस्ट बनाता है। हमारे उदाहरण में, WHM इन 3 उपयोगकर्ताओं को बनाएगा:

उपयोगकर्ता जोड़ते समय ProxySQL को केवल उपयोगकर्ता नाम, पासवर्ड और डिफ़ॉल्ट होस्टग्रुप जानकारी की आवश्यकता होती है। इसलिए, एक ही उपयोगकर्ता के कई इंसर्ट से बचने के लिए चेकिंग लाइनें हैं।

यदि आप मॉड्यूल को संशोधित करना चाहते हैं और उसमें कुछ सुधार करना चाहते हैं, तो WHM सर्वर पर निम्न कमांड चलाकर मॉड्यूल को फिर से पंजीकृत करना न भूलें:

(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHook

क्वेरी मॉनिटरिंग और कैशिंग

ProxySQL के साथ, आप उस एप्लिकेशन से आने वाले सभी प्रश्नों की निगरानी कर सकते हैं जो पास हो चुके हैं या इससे गुजर रहे हैं। मानक WHM MySQL क्वेरी मॉनिटरिंग में इस स्तर का विवरण प्रदान नहीं करता है। निम्नलिखित सभी MySQL क्वेरीज़ को दिखाता है जिन्हें ProxySQL द्वारा कैप्चर किया गया है:

ClusterControl के साथ, आप आसानी से सबसे अधिक बार-बार पूछे जाने वाले प्रश्नों को देख सकते हैं और उन्हें ProxySQL क्वेरी कैश सुविधा के माध्यम से कैश कर सकते हैं। "काउंट स्टार" द्वारा प्रश्नों को सॉर्ट करने के लिए "ऑर्डर बाय" ड्रॉपडाउन का उपयोग करें, उस क्वेरी को रोलओवर करें जिसे आप कैश करना चाहते हैं और उसके नीचे "कैश क्वेरी" बटन पर क्लिक करें। निम्न संवाद दिखाई देगा:

कैश्ड प्रश्नों के परिणाम को ProxySQL द्वारा ही संग्रहीत और परोसा जाएगा, जिससे बैकएंड पर हिट की संख्या कम हो जाएगी जो आपके MySQL प्रतिकृति क्लस्टर को समग्र रूप से ऑफ़लोड कर देगा। ProxySQL क्वेरी कैश कार्यान्वयन मूल रूप से MySQL क्वेरी कैश से अलग है। यह समय-आधारित कैश है और "कैश टीटीएल" नामक टाइमआउट के बाद समाप्त हो जाएगा। इस कॉन्फ़िगरेशन में, हम पाठक समूह को हिट करने से 5 सेकंड (5000 एमएस) के लिए उपरोक्त क्वेरी को कैश करना चाहते हैं जहां गंतव्य होस्टग्रुप 20 है।

विभाजन और संतुलन पढ़ें/लिखें

MySQL डिफॉल्ट पोर्ट 3306 को सुनकर, ProxySQL एक तरह से MySQL सर्वर की तरह काम कर रहा है। यह फ्रंटएंड और बैकएंड दोनों पर MySQL प्रोटोकॉल बोलता है। ProxySQL की स्थापना करते समय ClusterControl द्वारा परिभाषित क्वेरी नियम स्वचालित रूप से सभी रीड्स (^ SELECT .* Regex भाषा में) को होस्टग्रुप 20 में विभाजित कर देगा जो कि रीडर ग्रुप है, और बाकी को राइटर होस्टग्रुप 10 को अग्रेषित किया जाएगा, जैसा कि इसमें दिखाया गया है निम्नलिखित क्वेरी नियम अनुभाग:

इस आर्किटेक्चर के साथ, आपको पढ़ने/लिखने के प्रश्नों को विभाजित करने के बारे में चिंता करने की ज़रूरत नहीं है क्योंकि ProxySQL आपके लिए काम करेगा। उपयोगकर्ताओं के पास कोड में न्यूनतम या कोई भी परिवर्तन नहीं है, जिससे होस्टिंग उपयोगकर्ता WHM और cPanel द्वारा प्रदान किए गए सभी एप्लिकेशन और सुविधाओं का उपयोग मूल रूप से एक स्टैंडअलोन MySQL सेटअप से कनेक्ट करने के समान कर सकते हैं।

कनेक्शन संतुलन के संदर्भ में, यदि आपके पास किसी विशेष होस्टग्रुप में एक से अधिक सक्रिय नोड हैं (जैसे इस उदाहरण में रीडर होस्टग्रुप 20), तो ProxySQL स्वचालित रूप से कई मानदंडों के आधार पर उनके बीच लोड को फैला देगा - वजन, प्रतिकृति अंतराल, उपयोग किए गए कनेक्शन , समग्र भार और विलंबता। ProxySQL एक उन्नत कनेक्शन पूलिंग तंत्र को लागू करके उच्च समवर्ती वातावरण में बहुत अच्छा माना जाता है। ProxySQL ब्लॉग पोस्ट से उद्धृत, ProxySQL न केवल परसिस्टेंट कनेक्शन को लागू करता है, बल्कि कनेक्शन मल्टीप्लेक्सिंग को भी लागू करता है। वास्तव में, ProxySQL सैकड़ों हजारों क्लाइंट को संभाल सकता है, फिर भी अपने सभी ट्रैफ़िक को बैकएंड के कुछ कनेक्शनों पर अग्रेषित कर सकता है। तो ProxySQL N क्लाइंट कनेक्शन और M बैकएंड कनेक्शन को हैंडल कर सकता है, जहां N> M (यहां तक कि N, M से हजारों गुना बड़ा)।

MySQL विफलता और पुनर्प्राप्ति

क्लस्टर कंट्रोल के साथ प्रतिकृति क्लस्टर का प्रबंधन, स्वचालित पुनर्प्राप्ति सक्षम होने पर विफलता स्वचालित रूप से की जाती है। मास्टर विफलता के मामले में:

ClusterControl MySQL क्लाइंट, SSH और पिंग के माध्यम से मास्टर विफलता का पता लगाएगा और सत्यापित करेगा।
ClusterControl विफलता प्रक्रिया शुरू करने से पहले 3 सेकंड तक प्रतीक्षा करेगा।
ClusterControl सबसे अप-टू-डेट स्लेव को अगला मास्टर बनने के लिए प्रोत्साहित करेगा।
यदि पुराना मास्टर ऑनलाइन वापस आता है, तो इसे सक्रिय प्रतिकृति में भाग लिए बिना, केवल-पढ़ने के लिए शुरू किया जाएगा।
यह तय करना उपयोगकर्ताओं पर निर्भर है कि पुराने मास्टर का क्या होगा। इसे ClusterControl में "पुनर्निर्माण प्रतिकृति स्लेव" कार्यक्षमता का उपयोग करके प्रतिकृति श्रृंखला में वापस लाया जा सकता है।
ClusterControl केवल एक बार मास्टर फ़ेलओवर करने का प्रयास करेगा। यदि यह विफल हो जाता है, तो उपयोगकर्ता के हस्तक्षेप की आवश्यकता होती है।

आप ClusterControl -> Activity -> Jobs -> Failover to a new Master के अंतर्गत पूरी विफलता प्रक्रिया की निगरानी कर सकते हैं जैसा कि नीचे दिखाया गया है:

विफलता के दौरान, डेटाबेस सर्वर के सभी कनेक्शन ProxySQL में कतारबद्ध हो जाएंगे। उन्हें mysql-default_query_timeout द्वारा नियंत्रित टाइमआउट तक समाप्त नहीं किया जाएगा चर जो 8640000 मिलीसेकंड या 24 घंटे है। अनुप्रयोगों को इस बिंदु पर डेटाबेस में त्रुटियों या विफलताओं की सबसे अधिक संभावना नहीं दिखाई देगी, लेकिन एक विन्यास योग्य सीमा के भीतर ट्रेडऑफ़ बढ़ा हुआ विलंबता है।

इस बिंदु पर, ClusterControl टोपोलॉजी को नीचे के रूप में प्रस्तुत करेगा:

यदि हम पुराने मास्टर को प्रतिकृति में वापस आने और उपलब्ध होने के बाद अनुमति देना चाहते हैं, तो हमें ClusterControl -> Nodes -> पुराने मास्टर चुनें -> प्रतिकृति को फिर से बनाएँ पर जाकर एक गुलाम के रूप में इसे फिर से बनाना होगा गुलाम -> नया गुरु चुनें -> आगे बढ़ें . एक बार पुनर्निर्माण पूरा हो जाने पर, आपको निम्नलिखित टोपोलॉजी मिलनी चाहिए (नोटिस 192.168.0.32 अब मास्टर है):

सर्वर समेकन और डेटाबेस स्केलिंग

इस वास्तुकला के साथ, हम कई MySQL सर्वरों को समेकित कर सकते हैं जो प्रत्येक WHM सर्वर पर एक एकल प्रतिकृति सेटअप में रहते हैं। जैसे-जैसे आप बढ़ते हैं, आप अधिक डेटाबेस नोड्स को स्केल कर सकते हैं, या उन सभी का समर्थन करने के लिए कई प्रतिकृति क्लस्टर हैं और एक क्लस्टर कंट्रोल सर्वर द्वारा प्रबंधित किया जाता है। निम्न आर्किटेक्चर आरेख दिखाता है कि क्या हमारे पास दो WHM सर्वर हैं जो ProxySQL सॉकेट फ़ाइल के माध्यम से एक एकल MySQL प्रतिकृति क्लस्टर से जुड़े हैं:

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

एक अलग स्तरीय आर्किटेक्चर के साथ MySQL प्रतिकृति क्लस्टर को स्केल करना बहुत आसान होगा। यदि मान लें कि मास्टर को स्केल अप (अपग्रेड RAM, हार्ड डिस्क, RAID, NIC) रखरखाव की आवश्यकता है, तो हम मास्टर भूमिका को दूसरे स्लेव में बदल सकते हैं (ClusterControl -> Nodes -> एक स्लेव चुनें -> स्लेव को बढ़ावा दें ) और फिर पूरी तरह से MySQL सेवा को प्रभावित किए बिना रखरखाव कार्य करें। स्केल आउट ऑपरेशन (अधिक दास जोड़ने) के लिए, आप किसी भी सक्रिय दास से सीधे स्टेजिंग करके मास्टर को प्रभावित किए बिना भी प्रदर्शन कर सकते हैं। ClusterControl के साथ, आप मौजूदा MySQL बैकअप (केवल PITR-संगत) से एक नया स्लेव भी बना सकते हैं:

बैकअप से एक गुलाम को फिर से बनाने से मालिक पर अतिरिक्त बोझ नहीं पड़ेगा। ClusterControl चयनित बैकअप फ़ाइल को ClusterControl सर्वर से लक्ष्य नोड में कॉपी करेगा और वहां पुनर्स्थापन करेगा। एक बार हो जाने के बाद, नोड मास्टर से जुड़ जाएगा और पुनर्स्थापना समय के बाद से सभी लापता लेनदेन को पुनः प्राप्त करना शुरू कर देगा और मास्टर के साथ पकड़ लेगा। जब यह पिछड़ रहा होता है, तो ProxySQL लोड संतुलन सेट में नोड को तब तक शामिल नहीं करेगा जब तक कि प्रतिकृति अंतराल 10 सेकंड से कम न हो (ProxySQL व्यवस्थापक इंटरफ़ेस के माध्यम से mysql_servers तालिका जोड़ते समय कॉन्फ़िगर करने योग्य)।

अंतिम विचार

ProxySQL MySQL प्रतिकृति के प्रबंधन में WHM cPanel की क्षमताओं का विस्तार करता है। ClusterControl आपके प्रतिकृति क्लस्टर के प्रबंधन के साथ, प्रतिकृति क्लस्टर के प्रबंधन में शामिल सभी जटिल कार्य अब पहले से कहीं अधिक आसान हो गए हैं।