अपने प्रॉक्सीएसक्यूएल लोड बैलेंसर्स को कैसे क्लस्टर करें

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

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

सबसे पहले, आइए क्लस्टरकंट्रोल द्वारा परिनियोजित एक विशिष्ट प्रतिकृति वातावरण पर एक नज़र डालें।

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

इसके बाद, हमें उस उपयोगकर्ता को admin-cluster_password और admin-cluster_username सेटिंग में परिभाषित करना होगा।

यह सिर्फ एक नोड (10.0.0.126) पर किया गया है। आइए इस कॉन्फ़िगरेशन परिवर्तन को शेष ProxySQL नोड्स में सिंक करें।

जैसा कि हमने कहा, ClusterControl आपको केवल कुछ चरणों के साथ ProxySQL नोड्स के बीच कॉन्फ़िगरेशन को सिंक्रनाइज़ करने की अनुमति देता है। जब कार्य 10.0.0.127 को 10.0.0.126 के साथ समन्वयित करना समाप्त कर देता है, तो केवल अंतिम नोड होता है जिसे हमें समन्वयित करने की आवश्यकता होती है।

इसके बाद, हमें ProxySQL प्रशासनिक कमांड लाइन इंटरफ़ेस में एक छोटा सा बदलाव करने की आवश्यकता है, जो आमतौर पर पोर्ट 6032 पर पहुंच योग्य है। हमें 'proxysql_servers' तालिका में प्रविष्टियां बनानी होंगी जो हमारे ProxySQL क्लस्टर में नोड्स को परिभाषित करेगी।

mysql> INSERT INTO proxysql_servers (hostname) VALUES ('10.0.0.126'), ('10.0.0.127'), ('10.0.0.128');
Query OK, 3 rows affected (0.00 sec)

mysql> LOAD PROXYSQL SERVERS TO RUNTIME;
Query OK, 0 rows affected (0.01 sec)

mysql> SAVE PROXYSQL SERVERS TO DISK;
Query OK, 0 rows affected (0.01 sec)

रनटाइम में परिवर्तन लोड करने के बाद, प्रॉक्सीएसक्यूएल को नोड्स को सिंक करना शुरू करना चाहिए। ऐसे कुछ स्थान हैं जहां आप क्लस्टर की स्थिति को ट्रैक कर सकते हैं।

mysql> SELECT * FROM stats_proxysql_servers_checksums;
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
| hostname   | port | name              | version | epoch      | checksum           | changed_at | updated_at | diff_check |
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
| 10.0.0.128 | 6032 | admin_variables   | 0       | 0          |                    | 0          | 1539773916 | 0          |
| 10.0.0.128 | 6032 | mysql_query_rules | 2       | 1539772933 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0          |
| 10.0.0.128 | 6032 | mysql_servers     | 4       | 1539772933 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0          |
| 10.0.0.128 | 6032 | mysql_users       | 2       | 1539772933 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0          |
| 10.0.0.128 | 6032 | mysql_variables   | 0       | 0          |                    | 0          | 1539773916 | 0          |
| 10.0.0.128 | 6032 | proxysql_servers  | 2       | 1539773835 | 0x8EB13E2B48C3FDB0 | 1539773835 | 1539773916 | 0          |
| 10.0.0.127 | 6032 | admin_variables   | 0       | 0          |                    | 0          | 1539773916 | 0          |
| 10.0.0.127 | 6032 | mysql_query_rules | 3       | 1539773719 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0          |
| 10.0.0.127 | 6032 | mysql_servers     | 5       | 1539773719 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0          |
| 10.0.0.127 | 6032 | mysql_users       | 3       | 1539773719 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0          |
| 10.0.0.127 | 6032 | mysql_variables   | 0       | 0          |                    | 0          | 1539773916 | 0          |
| 10.0.0.127 | 6032 | proxysql_servers  | 2       | 1539773812 | 0x8EB13E2B48C3FDB0 | 1539773813 | 1539773916 | 0          |
| 10.0.0.126 | 6032 | admin_variables   | 0       | 0          |                    | 0          | 1539773916 | 0          |
| 10.0.0.126 | 6032 | mysql_query_rules | 1       | 1539770578 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0          |
| 10.0.0.126 | 6032 | mysql_servers     | 3       | 1539771053 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0          |
| 10.0.0.126 | 6032 | mysql_users       | 1       | 1539770578 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0          |
| 10.0.0.126 | 6032 | mysql_variables   | 0       | 0          |                    | 0          | 1539773916 | 0          |
| 10.0.0.126 | 6032 | proxysql_servers  | 2       | 1539773546 | 0x8EB13E2B48C3FDB0 | 1539773546 | 1539773916 | 0          |
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
18 rows in set (0.00 sec)

Stats_proxysql_servers_checksums तालिका में, दूसरों के बीच, क्लस्टर में नोड्स की एक सूची, सिंक की गई तालिकाएं, संस्करण और तालिका का चेकसम शामिल है। यदि चेकसम लाइन में नहीं है, तो ProxySQL क्लस्टर पीयर से नवीनतम संस्करण प्राप्त करने का प्रयास करेगा। इस तालिका की सामग्री के बारे में अधिक विस्तृत जानकारी ProxySQL दस्तावेज़ीकरण में पाई जा सकती है।

प्रक्रिया के बारे में जानकारी का एक अन्य स्रोत प्रॉक्सीएसक्यूएल का लॉग है (डिफ़ॉल्ट रूप से यह /var/lib/proxysql/proxysql.log में स्थित है)।

2018-10-17 11:00:25 [INFO] Cluster: detected a new checksum for mysql_query_rules from peer 10.0.0.126:6032, version 2, epoch 1539774025, checksum 0xD615D5416F61AA72 . Not syncing yet …
2018-10-17 11:00:27 [INFO] Cluster: detected a peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025, diff_check 3. Own version: 2, epoch: 1539772933. Proceeding with remote sync
2018-10-17 11:00:28 [INFO] Cluster: detected a peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025, diff_check 4. Own version: 2, epoch: 1539772933. Proceeding with remote sync
2018-10-17 11:00:28 [INFO] Cluster: detected peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025
2018-10-17 11:00:28 [INFO] Cluster: Fetching MySQL Query Rules from peer 10.0.0.126:6032 started
2018-10-17 11:00:28 [INFO] Cluster: Fetching MySQL Query Rules from peer 10.0.0.126:6032 completed
2018-10-17 11:00:28 [INFO] Cluster: Loading to runtime MySQL Query Rules from peer 10.0.0.126:6032
2018-10-17 11:00:28 [INFO] Cluster: Saving to disk MySQL Query Rules from peer 10.0.0.126:6032

जैसा कि आप देख सकते हैं, हमारे पास यहां जानकारी है कि एक नए चेकसम का पता चला है और समन्वयन प्रक्रिया लागू है।

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

Cluster_check_interval_ms - यह निर्धारित करता है कि ProxySQL को कितनी बार कॉन्फ़िगरेशन परिवर्तनों की जांच करनी चाहिए। डिफ़ॉल्ट रूप से यह 1000ms है।

Cluster_mysql_servers_diffs_before_sync - यह हमें बताता है कि सिंक होने से पहले चेक को कितनी बार कॉन्फ़िगरेशन परिवर्तन का पता लगाना चाहिए। डिफ़ॉल्ट सेटिंग 3 है।

इसका मतलब यह है कि, भले ही आप उसी होस्ट पर कॉन्फ़िगरेशन परिवर्तन करेंगे, यदि आप इसे 4 सेकंड से कम बार करेंगे, तो शेष प्रॉक्सीएसक्यूएल नोड्स इसे सिंक्रनाइज़ करने में सक्षम नहीं हो सकते हैं क्योंकि एक नया परिवर्तन पिछले एक से पहले दिखाई देगा। सिंक्रनाइज़ किया गया था। इसका यह भी अर्थ है कि यदि आप कई ProxySQL इंस्टेंस पर कॉन्फ़िगरेशन परिवर्तन करते हैं, तो आपको उनके बीच कम से कम 4 सेकंड के ब्रेक के साथ बनाना चाहिए, अन्यथा कुछ परिवर्तन खो जाएंगे और परिणामस्वरूप, कॉन्फ़िगरेशन अलग हो जाएंगे। उदाहरण के लिए, आप Proxy1 पर Server1 जोड़ते हैं, और 2 सेकंड के बाद आप Proxy2 पर Server2 जोड़ते हैं। अन्य सभी प्रॉक्सी प्रॉक्सी 1 पर परिवर्तन को अस्वीकार कर देंगे क्योंकि वे पता लगाएंगे कि प्रॉक्सी 2 में एक नया कॉन्फ़िगरेशन है। Proxy2 में परिवर्तन के 4 सेकंड बाद, सभी प्रॉक्सी (Proxy1 सहित) Proxy2 से कॉन्फ़िगरेशन खींच लेंगे।

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

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

इन सब के अलावा, ProxySQL क्लस्टर नोड्स के स्वत:पुन:जुड़ने का समर्थन करता है - वे शुरू करते समय अपने कॉन्फ़िगरेशन को सिंक करेंगे। अधिक नोड्स जोड़कर इसे आसानी से बढ़ाया भी जा सकता है।

हमें उम्मीद है कि यह ब्लॉग पोस्ट आपको इस बात की जानकारी देगा कि कैसे ProxySQL क्लस्टर को कॉन्फ़िगर किया जा सकता है। ProxySQL क्लस्टर ClusterControl के लिए पारदर्शी होगा और यह किसी भी ऑपरेशन को प्रभावित नहीं करेगा जिसे आप ClusterControl UI से निष्पादित करना चाहते हैं।