ProxySQL ने अभी MySQL और MariaDB डेटाबेस की दुनिया में बहुत रुचि प्राप्त की है, क्लिकहाउस का उल्लेख नहीं करने के लिए जो ProxySQL के लिए मामला बनाने में मदद करता है।
यह कहना सुरक्षित है कि ProxySQL डेटाबेस के MySQL परिवार (जैसे Percona Server, Oracle MySQL, Galera Cluster या यहां तक कि MariaDB के साथ) के लिए डिफ़ॉल्ट डेटाबेस प्रॉक्सी बन गया है।
ProxySQL, वास्तव में, अत्यधिक समृद्ध कार्यात्मकताओं के साथ एक कुशल समस्या समाधानकर्ता है जो डेटाबेस क्लाइंट-सर्वर संचार का प्रबंधन करता है; एक बहुत ही उन्नत और प्रदर्शनकारी दृष्टिकोण में मिडलवेयर के रूप में कार्य करना।
इसने तेजी से प्रश्नों को देरी, कैशिंग या पुनर्लेखन करके डेटाबेस ट्रैफ़िक को आकार देने की क्षमता को संभव बनाया है। इसका उपयोग एक ऐसा वातावरण बनाने के लिए भी किया जा सकता है जिसमें विफलता अनुप्रयोगों को प्रभावित नहीं करेगी और उनके लिए पारदर्शी होगी। ProxySQL समुदाय बहुत प्रतिक्रियाशील है और समय-समय पर लगातार सुधार, पैच और संस्करण रिलीज़ बनाता है।
लेकिन आपका ProxySQL सेटअप कितना अच्छा है, और आप यह कैसे निर्धारित कर सकते हैं कि आपका सेटअप सही तरीके से ट्यून किया गया है? यह ब्लॉग यह निर्धारित करने पर केंद्रित है कि आपके प्रॉक्सीएसक्यूएल नोड्स कितने प्रदर्शनकारी हैं और इसे कुशलतापूर्वक कैसे मॉनिटर किया जाए।
सामान्य समस्याएं जिनका आप ProxySQL से सामना कर सकते हैं
ProxySQL का डिफ़ॉल्ट इंस्टॉलेशन एक हल्के, सरल ट्यूनिंग टूल के साथ आता है जो औसत से भारी भार को संभालने में सक्षम है। हालांकि यह मिडलवेयर को भेजे गए प्रश्नों के प्रकार पर निर्भर हो सकता है, यह प्रभावित कर सकता है और बाधाओं और विलंबता का अनुभव करना शुरू कर सकता है।
विलंबता संबंधी समस्याएं
उदाहरण के लिए, विलंबता समस्याओं का कारण क्या हो सकता है, यह निर्धारित करना कठिन हो सकता है कि आपके पास निगरानी प्रणाली की कमी है या नहीं। इसी तरह, आप नीचे की तरह ही मैन्युअल रूप से आंकड़े स्कीमा की निगरानी या जांच कर सकते हैं:
mysql> select * from stats_mysql_connection_pool\G
*************************** 1. row ***************************
hostgroup: 20
srv_host: 192.168.10.225
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 1151
*************************** 2. row ***************************
hostgroup: 20
srv_host: 192.168.10.226
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 470
*************************** 3. row ***************************
hostgroup: 10
srv_host: 192.168.10.227
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 10855
*************************** 4. row ***************************
hostgroup: 40
srv_host: 192.168.10.225
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 1151
*************************** 5. row ***************************
hostgroup: 40
srv_host: 192.168.10.226
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 470
5 rows in set (0.01 sec)यह आपको होस्टग्रुप के आधार पर विलंबता की निगरानी करने की अनुमति देता है। लेकिन यह परेशानी को तब तक बढ़ा देता है जब तक कि आपको एक ऐसी स्क्रिप्ट (ओं) को नया और विकसित नहीं करना पड़ता है जो आपको सूचित करने का प्रबंधन करेगी।
क्लाइंट कनेक्शन त्रुटियां
बैकएंड में अधिकतम कनेक्शन के कारण अधिकतम कनेक्शन टाइमआउट (डेटाबेस नोड ही) आपको परेशानी में डाल सकता है यदि आप यह निर्धारित करने में सक्षम नहीं हैं कि समस्या का मुख्य स्रोत क्या है। आप क्लाइंट या सर्वर में इस तरह के निरस्त कनेक्शन की जांच करने के लिए आंकड़े डेटाबेस की जांच कर सकते हैं और यह निम्नानुसार कनेक्शन से इनकार कर दिया गया है,
mysql> select * from stats.stats_mysql_global where variable_name like '%connect%';
+-------------------------------------+----------------+
| Variable_Name | Variable_Value |
+-------------------------------------+----------------+
| Client_Connections_aborted | 0 |
| Client_Connections_connected | 205 |
| Client_Connections_created | 10067 |
| Server_Connections_aborted | 44 |
| Server_Connections_connected | 30 |
| Server_Connections_created | 14892 |
| Server_Connections_delayed | 0 |
| Client_Connections_non_idle | 205 |
| Access_Denied_Max_Connections | 0 |
| Access_Denied_Max_User_Connections | 0 |
| MySQL_Monitor_connect_check_OK | 41350 |
| MySQL_Monitor_connect_check_ERR | 92 |
| max_connect_timeouts | 0 |
| Client_Connections_hostgroup_locked | 0 |
| mysql_killed_backend_connections | 0 |
+-------------------------------------+----------------+
15 rows in set (0.01 sec)यदि आप बैकएंड उपयोगकर्ता के कनेक्शन की अधिकतम संख्या को सत्यापित और जांच सकते हैं तो यह भी आदर्श है कि यह कितनी कनेक्शन सीमाएं खोल सकता है या उपयोग कर सकता है। उदाहरण के लिए, मेरे परीक्षण में मेरे पास निम्नलिखित हैं,
mysql> select username, active, transaction_persistent, max_connections from mysql_users;
+---------------+--------+------------------------+-----------------+
| username | active | transaction_persistent | max_connections |
+---------------+--------+------------------------+-----------------+
| proxydemo | 1 | 1 | 10000 |
| proxysql-paul | 1 | 1 | 10000 |
+---------------+--------+------------------------+-----------------+
2 rows in set (0.00 sec)धीमी क्वेरी
प्रॉक्सीएसक्यूएल में धीमी क्वेरी की पहचान करना इतना मुश्किल नहीं हो सकता है, लेकिन अगर इसे मैन्युअल रूप से किया जाए तो यह अक्षम हो सकता है। यदि आप चर के साथ मैनुअल कर रहे हैं, तो आप इसे देख सकते हैं,
mysql> select * from stats_mysql_global where variable_name like '%slow%';
+---------------+----------------+
| Variable_Name | Variable_Value |
+---------------+----------------+
| Slow_queries | 2 |
+---------------+----------------+
1 row in set (0.00 sec)हालांकि यह आपको कुछ संख्याएं प्रदान कर सकता है, यदि आप अधिक गहराई तक जाना चाहते हैं तो आप आंकड़े स्कीमा के अंतर्गत stats_mysql_query_digest तालिका पर जांच कर सकते हैं। उदाहरण के लिए नीचे,
mysql> select count_star,sum_time,(sum_time/count_star)/1000 as average_time_ms,digest_text
-> from stats_mysql_query_digest
-> where count_star > 100 order by average_time_ms desc limit 10;
+------------+----------+-----------------+--------------------------------------+
| count_star | sum_time | average_time_ms | digest_text |
+------------+----------+-----------------+--------------------------------------+
| 884 | 15083961 | 17 | UPDATE sbtest1 SET k=k+? WHERE id=? |
| 930 | 16000111 | 17 | UPDATE sbtest9 SET k=k+? WHERE id=? |
| 914 | 15695810 | 17 | UPDATE sbtest4 SET k=k+? WHERE id=? |
| 874 | 14467420 | 16 | UPDATE sbtest8 SET k=k+? WHERE id=? |
| 904 | 15294520 | 16 | UPDATE sbtest3 SET k=k+? WHERE id=? |
| 917 | 15228077 | 16 | UPDATE sbtest6 SET k=k+? WHERE id=? |
| 907 | 14613238 | 16 | UPDATE sbtest2 SET k=k+? WHERE id=? |
| 900 | 15113004 | 16 | UPDATE sbtest5 SET k=k+? WHERE id=? |
| 917 | 15299381 | 16 | UPDATE sbtest7 SET k=k+? WHERE id=? |
| 883 | 15010119 | 16 | UPDATE sbtest10 SET k=k+? WHERE id=? |
+------------+----------+-----------------+--------------------------------------+
10 rows in set (0.01 sec)
जो 100 के नमूने के आधार पर शीर्ष 10 धीमी क्वेरी को पकड़ता है।
स्मृति उपयोग
हार्डवेयर आइटम जैसे CPU, डिस्क, और मेमोरी की निगरानी यह सुनिश्चित करने के लिए की जानी चाहिए कि आपका ProxySQL अच्छा प्रदर्शन कर रहा है। हालांकि, सबसे महत्वपूर्ण चीज मेमोरी है, क्योंकि प्रॉक्सीएसक्यूएल क्वेरी कैश मैकेनिज्म के कारण मेमोरी में भारी उपयोग करेगा। डिफ़ॉल्ट रूप से, क्वेरी कैश, जो चर mysql-query_cache_size_MB पर निर्भर है, डिफ़ॉल्ट रूप से 256 Mib है। इस संबंध में, यह ऐसी स्थिति में आ सकता है जहां यह स्मृति का उपयोग करता है और आपको यह निर्धारित करने और निदान करने की आवश्यकता है कि क्या आपको अपने प्रॉक्सीएसक्यूएल नोड के भीतर समस्याएं मिलती हैं या यहां तक कि एप्लिकेशन परत के भीतर भी देखा जा रहा है।
इसकी पहचान करते समय, आप stats_history और stats schemas में तालिकाओं की जांच कर सकते हैं। आप उन तालिकाओं की सूची देख सकते हैं जो निदान के दौरान आपकी सहायता कर सकती हैं,
mysql> show tables from stats;
| stats_memory_metrics |
19 rows in set (0.00 sec)
or,
mysql> show tables from stats_history;
+------------------------+
| tables |
+------------------------+
| mysql_connections |
| mysql_connections_day |
| mysql_connections_hour |
| mysql_query_cache |
| mysql_query_cache_day |
| mysql_query_cache_hour |
| system_cpu |
| system_cpu_day |
| system_cpu_hour |
| system_memory |
| system_memory_day |
| system_memory_hour |
+------------------------+
15 rows in set (0.00 sec)आपके ProxySQL के प्रदर्शन को कुशलतापूर्वक निर्धारित करना
आपके ProxySQL नोड के प्रदर्शन को निर्धारित करने के कई तरीके हैं। ClusterControl का उपयोग करना आपको इसे सरल लेकिन सीधे ग्राफ़ के साथ निर्धारित करने की क्षमता प्रदान करता है। उदाहरण के लिए, जब ProxySQL को आपके क्लस्टर में एकीकृत किया जाता है, तो आप अपने क्वेरी नियमों को सेट करने, उपयोगकर्ता के max_connections को बदलने, शीर्ष प्रश्नों को निर्धारित करने, उपयोगकर्ता होस्ट समूह को बदलने और आपको अपने ProxySQL नोड का प्रदर्शन प्रदान करने में सक्षम होंगे। नीचे स्क्रीनशॉट देखें...
आप जो देखते हैं वह इस बात का प्रमाण है कि ClusterControl आपको किस प्रकार की जानकारी दे सकता है आपके ProxySQL नोड का प्रदर्शन। लेकिन यह आपको यहीं तक सीमित नहीं रखता है। ClusterControl में समृद्ध और शक्तिशाली डैशबोर्ड भी हैं जिन्हें हम SCUMM कहते हैं, जिसमें ProxySQL अवलोकन डैशबोर्ड शामिल है।
यदि आप धीमी क्वेरी निर्धारित करना चाहते हैं, तो आप बस डैशबोर्ड पर एक नज़र डाल सकते हैं। आपके बैकएंड नोड्स को असाइन किए गए विभिन्न होस्टग्रुप पर अपने विलंबता वितरण की जाँच करने से आपको वितरण के आधार पर प्रदर्शन की त्वरित जानकारी प्राप्त करने में मदद मिलती है। आप क्वेरी कैश अंतर्दृष्टि प्रदान करते हुए क्लाइंट और सर्वर कनेक्शन की निगरानी कर सकते हैं। सबसे महत्वपूर्ण और कम से कम नहीं, यह आपको वह मेमोरी उपयोग देता है जो ProxySQL नोड उपयोग कर रहा है। नीचे दिए गए ग्राफ़ देखें...
ये ग्राफ़ डैशबोर्ड का हिस्सा हैं जो आपको आसानी से निर्धारित करने में मदद करता है आपके ProxySQL नोड का प्रदर्शन।
ProxySQL के साथ व्यवहार करते समय ClusterControl आपको सीमित नहीं करता है। साथ ही, यहां एक समृद्ध विशेषता है जहां आप बैकअप भी ले सकते हैं या कॉन्फ़िगरेशन आयात कर सकते हैं जो आपके ProxySQL नोड्स के लिए उच्च उपलब्धता के साथ काम करते समय बहुत महत्वपूर्ण है।
निष्कर्ष
मॉनिटर करना और यह निर्धारित करना कभी आसान नहीं रहा कि क्या आपको अपने ProxySQL के साथ कोई समस्या है। जैसे इस ब्लॉग के उदाहरण में, हम ClusterControl को एक उपकरण के रूप में प्रदर्शित कर रहे हैं जो आपको दक्षता प्रदान कर सकता है और आपको उन बकाया मुद्दों को निर्धारित करने के लिए अंतर्दृष्टि प्रदान कर सकता है जो आप अपनी प्रदर्शन संबंधी समस्याओं से निपट रहे हैं।
