HAProxy कनेक्शन बनाम MySQL कनेक्शन - आपको क्या पता होना चाहिए

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

यदि आपके पास ऐसा सेटअप है, तो इन घटकों को समझना महत्वपूर्ण है क्योंकि वे आपकी डेटाबेस सेवा के समग्र प्रदर्शन को प्रभावित कर सकते हैं। इस ब्लॉग पोस्ट में, हम MySQL के max_connections . के बारे में जानेंगे और हैप्रोक्सी मैक्सकॉन क्रमशः विकल्प। ध्यान दें कि टाइमआउट एक और महत्वपूर्ण पैरामीटर है जिसे हमें जानना चाहिए, लेकिन हम इसे एक अलग पोस्ट में कवर करने जा रहे हैं।

MySQL के अधिकतम कनेक्शन

MySQL सर्वर के लिए अनुमत कनेक्शनों की संख्या max_connections . द्वारा नियंत्रित होती है सिस्टम चर। डिफ़ॉल्ट मान 151 (MySQL 5.7) है।

max_connections . के लिए एक अच्छी संख्या निर्धारित करने के लिए , मूल सूत्र हैं:

कहां,

**चर innodb_additional_mem_pool_size MySQL 5.7.4+ में हटा दिया गया है। यदि आप पुराने संस्करण में चल रहे हैं, तो इस चर को ध्यान में रखें।

और,

उपरोक्त सूत्रों का उपयोग करके, हम एक उपयुक्त max_connections . की गणना कर सकते हैं इस विशेष MySQL सर्वर के लिए मूल्य। प्रक्रिया शुरू करने के लिए, क्लाइंट से सभी कनेक्शन बंद करें और MySQL सर्वर को पुनरारंभ करें। सुनिश्चित करें कि आपके पास केवल उस विशेष क्षण में चलने वाली प्रक्रियाओं की न्यूनतम संख्या है। आप इस उद्देश्य के लिए 'mysqladmin' या 'SHOW PROCESSLIST' का उपयोग कर सकते हैं:

$ mysqladmin -uroot -p processlist
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| Id     | User | Host      | db   | Command | Time | State | Info             | Progress |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| 232172 | root | localhost | NULL | Query   |    0 | NULL  | show processlist |    0.000 |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
1 row in set (0.00 sec)

उपरोक्त आउटपुट से, हम बता सकते हैं कि केवल एक उपयोगकर्ता MySQL सर्वर से जुड़ा है जो रूट है। फिर, होस्ट की उपलब्ध रैम (एमबी में) प्राप्त करें ('उपलब्ध' कॉलम के अंतर्गत देखें):

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           3778        1427         508         148        1842        1928
Swap:          2047           4        2043

केवल जानकारी के लिए, 'उपलब्ध' कॉलम यह अनुमान देता है कि नए अनुप्रयोगों को शुरू करने के लिए कितनी मेमोरी उपलब्ध है, बिना स्वैप किए (केवल कर्नेल 3.14+ में उपलब्ध)।

फिर, निम्नलिखित कथन में उपलब्ध मेमोरी, 1928 एमबी निर्दिष्ट करें:

mysql> SELECT ROUND((1928 - (ROUND((@@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@query_cache_size + @@tmp_table_size + @@key_buffer_size) / 1024 / 1024))) / (ROUND(@@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size + @@thread_stack + @@join_buffer_size + @@binlog_cache_size) / 1024 / 1024)) AS 'Possible Max Connections';
+--------------------------+
| Possible Max Connections |
+--------------------------+
|                      265 |
+--------------------------+

**वैरिएबल innodb_additional_mem_pool_size MySQL 5.7.4+ में हटा दिया गया है। यदि आप पुराने संस्करण में चल रहे हैं, तो इस चर को ध्यान में रखें।

इस उदाहरण से, हमारे पास होस्ट के पास उपलब्ध RAM के अनुसार एक साथ 265 MySQL कनेक्शन हो सकते हैं। इससे अधिक मान को कॉन्फ़िगर करने का कोई मतलब नहीं है। फिर, [mysqld] निर्देश के तहत, MySQL कॉन्फ़िगरेशन फ़ाइल के अंदर निम्न पंक्ति संलग्न करें:

max_connections = 265

परिवर्तन लागू करने के लिए MySQL सेवा को पुनरारंभ करें। जब कुल एक साथ कनेक्शन 265 तक पहुंच जाता है, तो आपको mysqld सर्वर से कनेक्ट करने का प्रयास करते समय "बहुत अधिक कनेक्शन" त्रुटि मिलेगी। इसका मतलब है कि सभी उपलब्ध कनेक्शन अन्य क्लाइंट द्वारा उपयोग में हैं। MySQL वास्तव में max_connections . की अनुमति देता है कनेक्ट करने के लिए +1 क्लाइंट। अतिरिक्त कनेक्शन सुपर विशेषाधिकार वाले खातों द्वारा उपयोग के लिए आरक्षित है। इसलिए यदि आप इस त्रुटि का सामना करते हैं, तो आपको सर्वर को रूट उपयोगकर्ता (या किसी अन्य सुपर उपयोगकर्ता) के रूप में एक्सेस करने का प्रयास करना चाहिए और समस्या निवारण शुरू करने के लिए प्रक्रिया सूची को देखना चाहिए।

HAProxy के अधिकतम कनेक्शन

HAProxy में 3 प्रकार के अधिकतम कनेक्शन (maxconn) हैं - वैश्विक, डिफ़ॉल्ट/सुनो और डिफ़ॉल्ट-सर्वर। दो श्रोताओं के साथ कॉन्फ़िगर किया गया एक HAProxy उदाहरण मान लें, एक पोर्ट 3307 पर बहु-लेखक सुनने के लिए (कनेक्शन सभी बैकएंड MySQL सर्वर पर वितरित किए जाते हैं) और दूसरा पोर्ट 3308 पर एकल-लेखक है (कनेक्शन एक एकल MySQL सर्वर पर अग्रेषित किए जाते हैं):

global
    ...
    maxconn 2000 #[a]
    ...
defaults
    ...
    maxconn 3 #[b]
    ...
listen mysql_3307
    ...
    maxconn 8 #[c]
    balance leastconn
    default-server port 9200 maxqueue 10 weight 10 maxconn 4 #[d]
    server db1 192.168.55.171 check
    server db2 192.168.55.172 check
    server db3 192.168.55.173 check
listen mysql_3308
    ...
    default-server port 9200 maxqueue 10 weight 10 maxconn 5 #[e]
    server db1 192.168.55.171 check
    server db2 192.168.55.172 check backup #[f]

आइए कुछ विन्यास पंक्तियों का अर्थ देखें:

global.maxconn [a]

समवर्ती कनेक्शनों की कुल संख्या जिन्हें इस HAProxy उदाहरण से कनेक्ट करने की अनुमति है। आमतौर पर, यह मान सभी का उच्चतम मूल्य होता है। इस मामले में, HAProxy एक बार में अधिकतम 2000 कनेक्शन स्वीकार करेगा और उन्हें HAProxy प्रक्रिया में परिभाषित सभी श्रोताओं, या कार्यकर्ता (आप nbproc का उपयोग करके कई HAProxy प्रक्रियाओं को चला सकते हैं) में वितरित करेंगे। विकल्प)।

इस सीमा तक पहुंचने पर HAProxy कनेक्शन स्वीकार करना बंद कर देगा। "ulimit-n" पैरामीटर स्वचालित रूप से इस मान में समायोजित हो जाता है। चूंकि सॉकेट को सिस्टम के नजरिए से फाइलों के बराबर माना जाता है, इसलिए डिफ़ॉल्ट फाइल डिस्क्रिप्टर की सीमा छोटी होती है। आप फ़ाइल डिस्क्रिप्टर के लिए कर्नेल को ट्यून करके शायद डिफ़ॉल्ट सीमा बढ़ाना चाहेंगे।

defaults.maxconn [b]

सभी श्रोताओं के लिए डिफ़ॉल्ट अधिकतम कनेक्शन मान। इसका कोई मतलब नहीं है अगर यह मान global.maxconn . से अधिक है ।

अगर "मैक्सकॉन" लाइन "सुनो" श्लोक के तहत गायब है (listen.maxconn ), श्रोता इस मान का पालन करेगा। ऐसे में mysql_3308 श्रोता को एक बार में अधिकतम 3 कनेक्शन मिलेंगे। सुरक्षित रहने के लिए, इस मान को global.maxconn . के बराबर सेट करें , श्रोताओं की संख्या से विभाजित। हालांकि, यदि आप अन्य श्रोताओं को अधिक कनेक्शन के लिए प्राथमिकता देना चाहते हैं, तो listen.maxconn का उपयोग करें इसके बजाय।

सुनो.मैक्सकॉन [c]

संबंधित श्रोता के लिए अनुमत अधिकतम कनेक्शन। श्रोता defaults.maxconn . पर वरीयता लेता है यदि निर्दिष्ट किया गया हो। इसका कोई मतलब नहीं है अगर यह मान global.maxconn . से अधिक है ।

एक बहु-लेखक श्रोता (mysql_3307) के मामले में बैकएंड सर्वर से कनेक्शन के उचित वितरण के लिए, इस मान को listen.default-server.maxconn के रूप में सेट करें। बैकएंड सर्वर की संख्या से गुणा करें। इस उदाहरण में, एक बेहतर मान 8 [c] के बजाय 12 होना चाहिए। यदि हम इस कॉन्फ़िगरेशन के साथ रहना चुनते हैं, तो db1 और db2 को अधिकतम 3 कनेक्शन प्राप्त होने की उम्मीद है, जबकि db3 को अधिकतम 2 कनेक्शन (कम से कम संतुलन के कारण) प्राप्त होंगे, जो कुल मिलाकर 8 कनेक्शन हैं। यह [डी] में निर्दिष्ट सीमा तक नहीं पहुंचेगा।

एकल-लेखक श्रोता (mysql_3308) के लिए जहां कनेक्शन एक समय में एक और केवल एक बैकएंड सर्वर को आवंटित किया जाना चाहिए, इस मान को listen.default-server.maxconn से समान या उच्चतर पर सेट करें। ।

listen.default-server.maxconn [d][e]

यह कनेक्शन की अधिकतम संख्या है जो प्रत्येक बैकएंड सर्वर एक बार में प्राप्त कर सकता है। इसका कोई मतलब नहीं है अगर यह मान listen.maxconn . से अधिक है या defaults.maxconn . यह मान MySQL के max_connections . से कम या बराबर होना चाहिए चर। अन्यथा, आप बैकएंड MySQL सर्वर से कनेक्शन को समाप्त करने का जोखिम उठाते हैं, खासकर जब MySQL के टाइमआउट चर HAProxy के टाइमआउट से कम कॉन्फ़िगर किए जाते हैं।

इस उदाहरण में, हमने प्रत्येक MySQL सर्वर को मल्टी-राइटर गैलेरा नोड्स [d] के लिए एक बार में अधिकतम 4 कनेक्शन प्राप्त करने के लिए सेट किया है। जबकि [बी] से लागू होने वाली सीमा के कारण सिंगल-राइटर गैलेरा नोड को एक बार में अधिकतम 3 कनेक्शन मिलेंगे। चूंकि हमने दूसरे नोड के लिए "बैकअप" [f] निर्दिष्ट किया है, इसलिए सक्रिय नोड को इस श्रोता को आवंटित सभी 3 कनेक्शन तुरंत मिल जाएंगे।

ऊपर दिए गए विवरण को निम्नलिखित चित्र में दिखाया जा सकता है:

कनेक्शन वितरण का योग करने के लिए, db1 को अधिकतम 6 कनेक्शन मिलने की उम्मीद है (3307 से 3 + 3308) से। db2 को 3 कनेक्शन मिलेंगे (जब तक कि db1 नीचे नहीं जाता है, जहां इसे अतिरिक्त 3 मिलेगा) और db3 क्लस्टर में टोपोलॉजी परिवर्तन की परवाह किए बिना 2 कनेक्शनों से चिपके रहेंगे।

ClusterControl के साथ कनेक्शन मॉनिटरिंग

ClusterControl के साथ, आप UI से MySQL और HAProxy कनेक्शन उपयोग की निगरानी कर सकते हैं। निम्न स्क्रीनशॉट MySQL कनेक्शन सलाहकार (ClusterControl -> प्रदर्शन -> सलाहकार) का एक सारांश प्रदान करता है जहां यह क्लस्टर में प्रत्येक सर्वर के लिए वर्तमान और कभी उपयोग किए गए MySQL कनेक्शन की निगरानी करता है:

HAProxy के लिए, ClusterControl मीट्रिक एकत्र करने के लिए HAProxy आँकड़े पृष्ठ के साथ एकीकृत होता है। ये नोड्स टैब के अंतर्गत प्रस्तुत किए जाते हैं:

उपरोक्त स्क्रीनशॉट से, हम बता सकते हैं कि बहु-लेखक श्रोता पर प्रत्येक बैकएंड सर्वर को अधिकतम 8 कनेक्शन मिलते हैं। 4 समवर्ती सत्र चल रहे हैं। इन्हें शीर्ष लाल वर्ग में हाइलाइट किया गया है, जबकि एकल-लेखक श्रोता क्रमशः 2 कनेक्शन प्रदान कर रहा है और उन्हें एक नोड पर अग्रेषित कर रहा है।

निष्कर्ष

HAProxy और MySQL सर्वर के लिए अधिकतम कनेक्शन कॉन्फ़िगर करना हमारे डेटाबेस सर्वर पर अच्छा लोड वितरण सुनिश्चित करने के लिए महत्वपूर्ण है, और MySQL सर्वर को इसके कनेक्शन को ओवरलोड या समाप्त होने से बचाने के लिए महत्वपूर्ण है।