ClusterControl में ProxySQL क्लस्टरिंग का अवलोकन

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

आप हाथ से सभी नोड्स को अपडेट करने का प्रयास कर सकते हैं, जो निश्चित रूप से कुशल नहीं है। आप किसी ज्ञात स्थिति में नोड्स में कॉन्फ़िगरेशन रखने के लिए Ansible या Chef जैसे कुछ प्रकार के इंफ्रास्ट्रक्चर ऑर्केस्ट्रेशन टूल का भी उपयोग कर सकते हैं, संशोधनों को सीधे ProxySQL पर नहीं बल्कि उस टूल के माध्यम से जो आप अपने पर्यावरण को व्यवस्थित करने के लिए उपयोग करते हैं।

यदि आप ClusterControl का उपयोग करते हैं, तो यह सुविधाओं के एक सेट के साथ आता है जो आपको ProxySQL इंस्टेंस के बीच कॉन्फ़िगरेशन को सिंक्रनाइज़ करने की अनुमति देता है लेकिन इस समाधान की अपनी कमियां हैं - यह एक मैन्युअल क्रिया है, जिसे आपको याद रखना होगा कॉन्फ़िगरेशन परिवर्तन के बाद इसे निष्पादित करें। यदि आप ऐसा करना भूल जाते हैं, तो आपको एक बुरा आश्चर्य हो सकता है, उदाहरण के लिए, Keepalived वर्चुअल IP को गैर-अपडेट किए गए ProxySQL इंस्टेंस में स्थानांतरित कर देगा।

उनमें से कोई भी तरीका सरल या 100% विश्वसनीय नहीं है और स्थिति यह है कि ProxySQL नोड्स के अलग-अलग कॉन्फ़िगरेशन हैं और संभावित रूप से खतरनाक हो सकते हैं।

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

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

एक बार जब आप ऐसा कर लेते हैं, तो आप बहुत कुछ कर चुके होते हैं - बाकी के तहत होता है हुड।

MySQL [(none)]> select * from proxysql_servers;

+------------+------+--------+----------------+

| hostname   | port | weight | comment        |

+------------+------+--------+----------------+

| 10.0.0.131 | 6032 | 0      | proxysql_group |

| 10.0.0.132 | 6032 | 0      | proxysql_group |

+------------+------+--------+----------------+

2 rows in set (0.001 sec)

दोनों सर्वरों पर proxysql_servers तालिका को क्लस्टर बनाने वाले नोड्स के होस्टनाम के साथ ठीक से सेट किया गया था। हम यह भी सत्यापित कर सकते हैं कि कॉन्फ़िगरेशन परिवर्तन पूरे क्लस्टर में ठीक से प्रचारित हैं:

हमने ProxySQL नोड्स में से एक पर अधिकतम कनेक्शन सेटिंग बढ़ा दी है (10.0 .0.131) और हम सत्यापित कर सकते हैं कि अन्य नोड (10.0.0.132) समान कॉन्फ़िगरेशन देखेंगे:

प्रक्रिया को डीबग करने की आवश्यकता के मामले में, हम हमेशा देख सकते हैं ProxySQL लॉग (आमतौर पर /var/lib/proxysql/proxysql.log में स्थित है) जहां हम इस तरह की जानकारी देखेंगे:

2020-11-26 13:40:47 [INFO] Cluster: detected a new checksum for mysql_servers from peer 10.0.0.131:6032, version 11, epoch 1606398059, checksum 0x441378E48BB01C61 . Not syncing yet ...

2020-11-26 13:40:49 [INFO] Cluster: detected a peer 10.0.0.131:6032 with mysql_servers version 12, epoch 1606398060, diff_check 3. Own version: 9, epoch: 1606398022. Proceeding with remote sync

2020-11-26 13:40:50 [INFO] Cluster: detected a peer 10.0.0.131:6032 with mysql_servers version 12, epoch 1606398060, diff_check 4. Own version: 9, epoch: 1606398022. Proceeding with remote sync

2020-11-26 13:40:50 [INFO] Cluster: detected peer 10.0.0.131:6032 with mysql_servers version 12, epoch 1606398060

2020-11-26 13:40:50 [INFO] Cluster: Fetching MySQL Servers from peer 10.0.0.131:6032 started. Expected checksum 0x441378E48BB01C61

2020-11-26 13:40:50 [INFO] Cluster: Fetching MySQL Servers from peer 10.0.0.131:6032 completed

2020-11-26 13:40:50 [INFO] Cluster: Fetching checksum for MySQL Servers from peer 10.0.0.131:6032 before proceessing

2020-11-26 13:40:50 [INFO] Cluster: Fetching checksum for MySQL Servers from peer 10.0.0.131:6032 successful. Checksum: 0x441378E48BB01C61

2020-11-26 13:40:50 [INFO] Cluster: Writing mysql_servers table

2020-11-26 13:40:50 [INFO] Cluster: Writing mysql_replication_hostgroups table

2020-11-26 13:40:50 [INFO] Cluster: Loading to runtime MySQL Servers from peer 10.0.0.131:6032

यह 10.0.0.132 से लॉग है जहां हम स्पष्ट रूप से देख सकते हैं कि तालिका mysql_servers के लिए कॉन्फ़िगरेशन परिवर्तन 10.0.0.131 को पता चला था और फिर इसे सिंक किया गया था और इसे 10.0.0.132 पर लागू किया गया था, इसे सिंक में बना दिया गया था। क्लस्टर में दूसरे नोड के साथ।

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