गैलेरा क्लस्टर कई उल्लेखनीय विशेषताओं के साथ आता है जो मानक MySQL प्रतिकृति (या समूह प्रतिकृति) में उपलब्ध नहीं हैं; स्वचालित नोड प्रावधान, संघर्ष समाधान और स्वचालित विफलता के साथ वास्तविक बहु-मास्टर। ऐसी कई सीमाएँ भी हैं जो क्लस्टर प्रदर्शन को संभावित रूप से प्रभावित कर सकती हैं। सौभाग्य से, यदि आप इनके बारे में नहीं जानते हैं, तो इसके समाधान हैं। और अगर आप इसे सही तरीके से करते हैं, तो आप इन सीमाओं के प्रभाव को कम कर सकते हैं और समग्र प्रदर्शन में सुधार कर सकते हैं।
हमने पहले गैलेरा क्लस्टर से संबंधित कई टिप्स और ट्रिक्स को कवर किया है, जिसमें एडब्ल्यूएस क्लाउड पर गैलेरा चलाना शामिल है। गैलेरा का अधिकतम लाभ उठाने के उदाहरणों के साथ, यह ब्लॉग पोस्ट प्रदर्शन पहलुओं में स्पष्ट रूप से गोता लगाता है।
प्रतिकृति पेलोड
थोड़ा सा परिचय - गैलेरा प्रतिबद्ध चरण के दौरान राइटसेट को दोहराता है, राइटसेट को मूल नोड से रिसीवर नोड्स में wsrep प्रतिकृति प्लगइन के माध्यम से सिंक्रोनाइज़ करता है। यह प्लगइन रिसीवर नोड्स पर राइटसेट को भी प्रमाणित करेगा। यदि प्रमाणन प्रक्रिया पास हो जाती है, तो यह क्लाइंट को ओरिजिनेटर नोड पर ओके लौटाता है और बाद में एसिंक्रोनस रूप से रिसीवर नोड्स पर लागू किया जाएगा। अन्यथा, लेन-देन को ओरिजिनेटर नोड (क्लाइंट को रिटर्निंग एरर) पर वापस रोल किया जाएगा और राइटसेट जो रिसीवर नोड्स में स्थानांतरित कर दिए गए हैं, उन्हें छोड़ दिया जाएगा।
एक राइटसेट में एक लेन-देन के अंदर लेखन संचालन होता है जो डेटाबेस स्थिति को बदलता है। गैलेरा क्लस्टर में, ऑटोकॉमिट 1 (सक्षम) के लिए डिफ़ॉल्ट है। शाब्दिक रूप से, गैलेरा क्लस्टर में निष्पादित किसी भी SQL कथन को लेन-देन के रूप में संलग्न किया जाएगा, जब तक कि आप स्पष्ट रूप से BEGIN, START TRANSACTION या SET autocommit=0 से प्रारंभ नहीं करते हैं। निम्नलिखित आरेख एक डीएमएल स्टेटमेंट के एक राइटसेट में इनकैप्सुलेशन को दिखाता है:
DML (INSERT, UPDATE, DELETE..) के लिए, राइटसेट पेलोड में किसी विशेष लेनदेन के लिए बाइनरी लॉग इवेंट होते हैं जबकि DDL (ALTER, GRANT, CREATE..) के लिए, राइटसेट पेलोड DDL स्टेटमेंट ही होता है। डीएमएल के लिए, राइटसेट को रिसीवर नोड पर विरोध के खिलाफ प्रमाणित करना होगा जबकि डीडीएल के लिए (wsrep_osu_method के आधार पर) , टीओआई के लिए डिफ़ॉल्ट), क्लस्टर क्लस्टर डीडीएल स्टेटमेंट को सभी नोड्स पर एक ही कुल क्रम क्रम में चलाता है, डीडीएल के प्रगति के दौरान अन्य लेनदेन को करने से रोकता है (आरएसयू भी देखें)। सरल शब्दों में, गैलेरा क्लस्टर डीडीएल और डीएमएल प्रतिकृति को अलग तरह से संभालता है।
दौर की यात्रा का समय
आम तौर पर, निम्नलिखित कारक निर्धारित करते हैं कि गैलेरा एक मूल नोड से सभी रिसीवर नोड्स में एक राइटसेट को कितनी तेजी से दोहरा सकता है:
- राउंड ट्रिप टाइम (RTT) से क्लस्टर में ओरिजिनेटर नोड से सबसे दूर के नोड तक।
- रिसीवर नोड पर विरोध के लिए हस्तांतरित और प्रमाणित किए जाने वाले राइटसेट का आकार।
उदाहरण के लिए, यदि हमारे पास तीन-नोड गैलेरा क्लस्टर है और नोड्स में से एक 10 मिलीसेकंड (0.01 सेकंड) दूर स्थित है, तो यह बहुत कम संभावना है कि आप प्रति सेकंड 100 से अधिक बार एक ही पंक्ति में परस्पर विरोधी के बिना लिखने में सक्षम हो सकते हैं। मार्क कैलाघन का एक लोकप्रिय उद्धरण है जो इस व्यवहार का बहुत अच्छी तरह से वर्णन करता है:
"[एक गैलेरा क्लस्टर में] एक दी गई पंक्ति को प्रति आरटीटी एक से अधिक बार संशोधित नहीं किया जा सकता"
RTT मान को मापने के लिए, बस क्लस्टर में सबसे दूर के नोड के लिए ओरिजिनेटर नोड पर पिंग करें:
$ ping 192.168.55.173 # the farthest nodeकुछ सेकंड (या मिनट) तक प्रतीक्षा करें और कमांड को समाप्त करें। पिंग सांख्यिकी अनुभाग की अंतिम पंक्ति वह है जिसकी हम तलाश कर रहे हैं:
--- 192.168.55.172 ping statistics ---
65 packets transmitted, 65 received, 0% packet loss, time 64019ms
rtt min/avg/max/mdev = 0.111/0.431/1.340/0.240 msअधिकतम मान 1.340 ms (0.00134s) है और न्यूनतम का अनुमान लगाते समय हमें यह मान लेना चाहिए इस क्लस्टर के लिए प्रति सेकंड लेनदेन (टीपीएस)। औसत मान 0.431ms (0.000431s) है और हम इसका उपयोग औसत . का अनुमान लगाने के लिए कर सकते हैं tps जबकि मिनट मान 0.111ms (0.000111s) है जिसका उपयोग हम अधिकतम . का अनुमान लगाने के लिए कर सकते हैं टीपीएस mdev का अर्थ है कि औसत से RTT नमूने कैसे वितरित किए गए। कम मान का मतलब है ज़्यादा स्थिर RTT.
इसलिए, RTT (सेकंड में) को 1 सेकंड में विभाजित करके प्रति सेकंड लेनदेन का अनुमान लगाया जा सकता है:
परिणामी,
- न्यूनतम टीपीएस:1 / 0.00134 (अधिकतम आरटीटी) =746.26 ~ 746 टीपीएस
- औसत टीपीएस:1 / 0.000431 (औसत आरटीटी) =2320.19 ~ 2320 टीपीएस
- अधिकतम टीपीएस:1 / 0.000111 (न्यूनतम आरटीटी) =9009.01 ~ 9009 टीपीएस
ध्यान दें कि यह प्रतिकृति प्रदर्शन का अनुमान लगाने के लिए सिर्फ एक अनुमान है। एक बार हमारे पास सब कुछ तैनात और चलने के बाद, डेटाबेस पक्ष में इसे बेहतर बनाने के लिए हम बहुत कुछ नहीं कर सकते हैं। सिवाय, यदि आप नोड्स के बीच RTT में सुधार करने, या नेटवर्क बाह्य उपकरणों या बुनियादी ढांचे को अपग्रेड करने के लिए डेटाबेस सर्वर को एक-दूसरे के करीब ले जाते हैं या माइग्रेट करते हैं। इसके लिए रखरखाव खिड़की और उचित योजना की आवश्यकता होगी।
बड़े लेन-देन करें
एक अन्य कारक लेनदेन का आकार है। राइटसेट ट्रांसफर होने के बाद सर्टिफिकेशन की प्रक्रिया होगी। प्रमाणन यह निर्धारित करने की एक प्रक्रिया है कि नोड राइटसेट लागू कर सकता है या नहीं। गैलेरा प्रत्येक पूर्ण पंक्ति से MD5 चेकसम छद्म कुंजी उत्पन्न करता है। प्रमाणन की लागत राइटसेट के आकार पर निर्भर करती है, जो प्रमाणन सूचकांक (एक हैश तालिका) में कई अद्वितीय कुंजी लुकअप में तब्दील हो जाती है। उदाहरण के लिए, यदि आप एक लेन-देन में 500,000 पंक्तियों को अपडेट करते हैं:
# a 500,000 rows table
mysql> UPDATE mydb.settings SET success = 1;उपरोक्त 500,000 बाइनरी लॉग इवेंट्स के साथ एक सिंगल राइटसेट जेनरेट करेगा। यह विशाल राइटसेट wsrep_max_ws_size . से अधिक नहीं है (डिफ़ॉल्ट 2GB) इसलिए इसे गैलेरा प्रतिकृति प्लगइन द्वारा क्लस्टर में सभी नोड्स में स्थानांतरित कर दिया जाएगा, जो कि किसी भी परस्पर विरोधी लेनदेन के लिए रिसीवर नोड्स पर इन 500,000 पंक्तियों को प्रमाणित करता है जो अभी भी गुलाम कतार में हैं। अंत में, प्रमाणन स्थिति समूह प्रतिकृति प्लगइन में वापस आ जाती है। लेन-देन का आकार जितना बड़ा होगा, उतना ही अधिक जोखिम यह दूसरे मास्टर से आने वाले अन्य लेनदेन के साथ विरोधाभासी होगा। परस्पर विरोधी लेन-देन सर्वर संसाधनों को बर्बाद करते हैं, साथ ही प्रवर्तक नोड के लिए एक बड़ा रोलबैक का कारण बनते हैं। ध्यान दें कि MySQL में रोलबैक ऑपरेशन प्रतिबद्ध ऑपरेशन की तुलना में धीमा और कम अनुकूलित है।
उपरोक्त SQL कथन को सरल लूप की सहायता से अधिक गैलेरा-अनुकूल कथन में फिर से लिखा जा सकता है, जैसा कि नीचे दिया गया उदाहरण है:
(bash)$ for i in {1..500}; do \
mysql -uuser -ppassword -e "UPDATE mydb.settings SET success = 1 WHERE success != 1 LIMIT 1000"; \
sleep 2; \
doneउपरोक्त शेल कमांड प्रति लेनदेन 1000 पंक्तियों को 500 बार अपडेट करेगा और निष्पादन के बीच 2 सेकंड तक प्रतीक्षा करेगा। आप समान परिणाम प्राप्त करने के लिए संग्रहीत कार्यविधि या अन्य साधनों का भी उपयोग कर सकते हैं। यदि SQL क्वेरी को फिर से लिखना एक विकल्प नहीं है, तो बस एप्लिकेशन को एक रखरखाव विंडो के दौरान बड़े लेनदेन को निष्पादित करने का निर्देश दें ताकि विरोधों के जोखिम को कम किया जा सके।
भारी डिलीट के लिए, Percona टूलकिट से pt-archiver का उपयोग करने पर विचार करें - OLTP प्रश्नों को अधिक प्रभावित किए बिना पुराने डेटा को तालिका से बाहर निकालने के लिए एक कम प्रभाव वाला, केवल फॉरवर्ड करने वाला कार्य।
समानांतर स्लेव थ्रेड
गैलेरा में, एप्लायर एक बहुप्रचारित प्रक्रिया है। एप्लायर एक थ्रेड है जो गैलेरा के भीतर दूसरे नोड से आने वाले राइट-सेट को लागू करने के लिए चल रहा है। जिसका अर्थ है, सभी रिसीवरों के लिए एक साथ कई डीएमएल संचालन निष्पादित करना संभव है जो एक साथ प्रवर्तक (मास्टर) नोड से आते हैं। गैलेरा समानांतर प्रतिकृति केवल लेनदेन पर लागू होती है जब ऐसा करना सुरक्षित होता है। यह मूल नोड के साथ समन्वयित होने के लिए नोड की संभावना में सुधार करता है। हालाँकि, प्रतिकृति गति अभी भी RTT और राइटसेट आकार तक सीमित है।
इसका सर्वोत्तम लाभ उठाने के लिए, हमें दो बातें जानने की जरूरत है:
- सर्वर के पास जितने कोर हैं।
- wsrep_cert_deps_distance . का मान स्थिति।
स्थिति wsrep_cert_deps_distance हमें समांतरता की संभावित डिग्री बताता है। यह उच्चतम और निम्नतम seqno मानों के बीच की औसत दूरी का मान है जिसे संभवतः समानांतर में लागू किया जा सकता है। आप wsrep_cert_deps_distance . का उपयोग कर सकते हैं स्थिति चर संभव दास धागे की अधिकतम संख्या निर्धारित करने के लिए। ध्यान दें कि यह पूरे समय का औसत मान है। इसलिए, एक अच्छा मूल्य प्राप्त करने के लिए, आपको परीक्षण कार्यभार या बेंचमार्क के माध्यम से लिखने के संचालन के साथ क्लस्टर को हिट करना होगा जब तक कि आप एक स्थिर मूल्य बाहर नहीं आते।
कोर की संख्या प्राप्त करने के लिए, आप बस निम्न आदेश का उपयोग कर सकते हैं:
$ grep -c processor /proc/cpuinfo
4आदर्श रूप से, प्रति CPU कोर में 2, 3 या 4 थ्रेड स्लेव एप्लायर एक अच्छी शुरुआत है। इस प्रकार, स्लेव थ्रेड्स के लिए न्यूनतम मान CPU कोर की संख्या 4 x होना चाहिए, और wsrep_cert_deps_distance से अधिक नहीं होना चाहिए मूल्य:
MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_cert_deps_distance';
+--------------------------+----------+
| Variable_name | Value |
+--------------------------+----------+
| wsrep_cert_deps_distance | 48.16667 |
+--------------------------+----------+आप wsrep_slave_thread . का उपयोग करके स्लेव एप्लायर थ्रेड्स की संख्या को नियंत्रित कर सकते हैं चर। हालांकि यह एक गतिशील चर है, केवल संख्या बढ़ाने से ही तत्काल प्रभाव पड़ेगा। यदि आप मूल्य को गतिशील रूप से कम करते हैं, तो इसमें कुछ समय लगेगा, जब तक कि लागू करने वाला धागा लागू होने के बाद बाहर नहीं निकल जाता। अनुशंसित मान 16 से 48 के बीच कहीं भी होता है:
mysql> SET GLOBAL wsrep_slave_threads = 48;ध्यान दें कि समानांतर दास धागे काम करने के लिए, निम्नलिखित सेट किया जाना चाहिए (जो आमतौर पर गैलेरा क्लस्टर के लिए पूर्व-कॉन्फ़िगर किया जाता है):
innodb_autoinc_lock_mode=2गैलेरा कैशे (gcache)
गैलेरा एक विशिष्ट आकार के साथ एक प्रीआलोकेटेड फ़ाइल का उपयोग करता है जिसे gcache कहा जाता है, जहां एक गैलेरा नोड सर्कुलर बफर शैली में राइटसेट की एक प्रति रखता है। डिफ़ॉल्ट रूप से, इसका आकार 128MB है, जो कि छोटा है। इंक्रीमेंटल स्टेट ट्रांसफर (IST) दाता के gcache में उपलब्ध केवल लापता राइटसेट भेजकर एक जॉइनर तैयार करने की एक विधि है। आईएसटी स्टेट स्नैपशॉट ट्रांसफर (एसएसटी) से तेज है, यह गैर-अवरुद्ध है और दाता पर इसका कोई महत्वपूर्ण प्रदर्शन प्रभाव नहीं पड़ता है। जब भी संभव हो यह पसंदीदा विकल्प होना चाहिए।
IST तभी हासिल किया जा सकता है जब जॉइनर द्वारा छूटे सभी परिवर्तन अभी भी दाता की gcache फ़ाइल में हों। इसके लिए अनुशंसित सेटिंग पूरे MySQL डेटासेट जितनी बड़ी होनी चाहिए। यदि डिस्क स्थान सीमित या महंगा है, तो gcache आकार का सही आकार निर्धारित करना महत्वपूर्ण है, क्योंकि यह गैलेरा नोड्स के बीच डेटा सिंक्रनाइज़ेशन प्रदर्शन को प्रभावित कर सकता है।
नीचे दिया गया बयान हमें गैलेरा द्वारा दोहराए गए डेटा की मात्रा का अंदाजा देगा। पीक आवर्स के दौरान गैलेरा नोड्स में से किसी एक पर निम्नलिखित कथन चलाएँ (मारियाडीबी> 10.0 और पीएक्ससी> 5.6, गैलेरा> 3.x पर परीक्षण):
mysql> SET @start := (SELECT SUM(VARIABLE_VALUE/1024/1024) FROM information_schema.global_status WHERE VARIABLE_NAME LIKE 'WSREP%bytes'); do sleep(60); SET @end := (SELECT SUM(VARIABLE_VALUE/1024/1024) FROM information_schema.global_status WHERE VARIABLE_NAME LIKE 'WSREP%bytes'); SET @gcache := (SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(@@GLOBAL.wsrep_provider_options,'gcache.size = ',-1), 'M', 1)); SELECT ROUND((@end - @start),2) AS `MB/min`, ROUND((@end - @start),2) * 60 as `MB/hour`, @gcache as `gcache Size(MB)`, ROUND(@gcache/round((@end - @start),2),2) as `Time to full(minutes)`;
+--------+---------+-----------------+-----------------------+
| MB/min | MB/hour | gcache Size(MB) | Time to full(minutes) |
+--------+---------+-----------------+-----------------------+
| 7.95 | 477.00 | 128 | 16.10 |
+--------+---------+-----------------+-----------------------+
हम अनुमान लगा सकते हैं कि गैलेरा नोड में लगभग 16 मिनट का डाउनटाइम हो सकता है, बिना एसएसटी में शामिल होने की आवश्यकता के (जब तक कि गैलेरा जॉइनर स्थिति का निर्धारण नहीं कर सकता)। यदि यह बहुत कम समय है और आपके नोड्स पर पर्याप्त डिस्क स्थान है, तो आप wsrep_provider_options="gcache.size=
gcache.recover=yes . का उपयोग करने की भी अनुशंसा की जाती है wsrep_provider_options . में (गैलेरा> 3.19), जहां गैलेरा gcache फ़ाइल को हटाने के बजाय स्टार्टअप पर उपयोग करने योग्य स्थिति में पुनर्प्राप्त करने का प्रयास करेगा, इस प्रकार IST रखने की क्षमता को संरक्षित करता है और जितना संभव हो सके एसएसटी से बचता है। कोडरशिप और पेरकोना ने अपने ब्लॉग में इसे विस्तार से कवर किया है। नोड के क्लस्टर में फिर से जुड़ने के बाद सिंक करने के लिए IST हमेशा सबसे अच्छा तरीका है। यह xtrabackup या mariabackup से 50% तेज और mysqldump से 5x तेज है।
एसिंक्रोनस स्लेव
गैलेरा नोड्स कसकर युग्मित होते हैं, जहां प्रतिकृति प्रदर्शन सबसे धीमा नोड जितना तेज़ होता है। सदस्यों के बीच प्रतिकृति प्रवाह को नियंत्रित करने और किसी भी दास अंतराल को खत्म करने के लिए गैलेरा प्रवाह नियंत्रण तंत्र का उपयोग करता है। प्रतिकृति हर नोड पर सभी तेज या सभी धीमी हो सकती है और गैलेरा द्वारा स्वचालित रूप से समायोजित की जाती है। यदि आप प्रवाह नियंत्रण के बारे में जानना चाहते हैं, तो पेरकोना के जे जानसेन द्वारा इस ब्लॉग पोस्ट को पढ़ें।
ज्यादातर मामलों में, लंबे समय तक चलने वाले एनालिटिक्स (रीड-इंटेंसिव) और बैकअप (रीड-इंटेंसिव, लॉकिंग) जैसे भारी ऑपरेशन अक्सर अपरिहार्य होते हैं, जो संभावित रूप से क्लस्टर के प्रदर्शन को खराब कर सकते हैं। इस प्रकार के प्रश्नों को निष्पादित करने का सबसे अच्छा तरीका है कि उन्हें एक शिथिल-युग्मित प्रतिकृति सर्वर, उदाहरण के लिए, एक अतुल्यकालिक दास पर भेज दिया जाए।
एक अतुल्यकालिक दास मानक MySQL अतुल्यकालिक प्रतिकृति प्रोटोकॉल का उपयोग करके गैलेरा नोड से प्रतिकृति करता है। एक गैलेरा नोड से जुड़े दासों की संख्या की कोई सीमा नहीं है, और इसे एक मध्यवर्ती मास्टर के साथ जंजीर से बाहर निकालना भी संभव है। इस सर्वर पर निष्पादित MySQL संचालन क्लस्टर प्रदर्शन को प्रभावित नहीं करेगा, प्रारंभिक सिंकिंग चरण के अलावा जहां प्रतिकृति लिंक स्थापित करने से पहले दास को चरणबद्ध करने के लिए गैलेरा नोड पर एक पूर्ण बैकअप लिया जाना चाहिए (हालांकि क्लस्टरकंट्रोल आपको एसिंक बनाने की अनुमति देता है क्लस्टर से कनेक्ट करने से पहले, पहले मौजूदा बैकअप से स्लेव करें)।
GTID (ग्लोबल ट्रांजैक्शन आइडेंटिफ़ायर) नोड्स में बेहतर लेनदेन मैपिंग प्रदान करता है, और यह MySQL 5.6 और MariaDB 10.0 में समर्थित है। GTID के साथ, सटीक लॉग फ़ाइल और स्थिति का पता लगाने की आवश्यकता के बिना, किसी अन्य मास्टर (एक अन्य गैलेरा नोड) के दास पर फेलओवर ऑपरेशन को सरल बनाया जाता है। गैलेरा भी अपने स्वयं के GTID कार्यान्वयन के साथ आता है लेकिन ये दोनों एक दूसरे से स्वतंत्र हैं।
यदि आप ClusterControl का उपयोग कर रहे हैं तो एसिंक्रोनस स्लेव को स्केल करना एक-क्लिक दूर है -> प्रतिकृति स्लेव सुविधा जोड़ें:
ध्यान दें कि इस सेटअप के साथ आगे बढ़ने से पहले बाइनरी लॉग को मास्टर (चुने हुए गैलेरा नोड) पर सक्षम होना चाहिए। हमने इस पिछली पोस्ट में मैन्युअल तरीके से भी कवर किया है।
ClusterControl से निम्न स्क्रीनशॉट क्लस्टर टोपोलॉजी दिखाता है, यह हमारे गैलेरा क्लस्टर आर्किटेक्चर को एक एसिंक्रोनस स्लेव के साथ दिखाता है:
ClusterControl स्वचालित रूप से टोपोलॉजी की खोज करता है और ऊपर की तरह सुपर कूल आरेख उत्पन्न करता है। आप प्रत्येक बॉक्स के शीर्ष-दाएं गियर आइकन पर क्लिक करके सीधे इस पृष्ठ से व्यवस्थापन कार्य भी कर सकते हैं।
एसक्यूएल-अवेयर रिवर्स प्रॉक्सी
ProxySQL और MariaDB MaxScale बुद्धिमान रिवर्स-प्रॉक्सी हैं जो MySQL प्रोटोकॉल को समझते हैं और आपके गैलेरा नोड्स के सामने गेटवे, राउटर, लोड बैलेंसर और फ़ायरवॉल के रूप में कार्य करने में सक्षम हैं। LVS या Keepalived जैसे वर्चुअल IP एड्रेस प्रदाता की मदद से, और इसे गैलेरा मल्टी-मास्टर प्रतिकृति तकनीक के साथ जोड़कर, हमारे पास एक अत्यधिक उपलब्ध डेटाबेस सेवा हो सकती है, जो एप्लिकेशन बिंदु से सभी संभावित सिंगल-पॉइंट-ऑफ-विफलताओं (SPOF) को समाप्त करती है। -मानना है कि। यह निश्चित रूप से संपूर्ण वास्तुकला की उपलब्धता और विश्वसनीयता में सुधार करेगा।
इस दृष्टिकोण के साथ एक और लाभ यह है कि आपके पास आने वाले SQL प्रश्नों को वास्तविक डेटाबेस सर्वर पर हिट करने से पहले नियमों के एक सेट के आधार पर मॉनिटर, पुनर्लेखन या पुन:रूट करने की क्षमता होगी, एप्लिकेशन या क्लाइंट साइड पर परिवर्तनों को कम करने और प्रश्नों को रूट करने के लिए इष्टतम प्रदर्शन के लिए एक अधिक उपयुक्त नोड। गैलेरा के लिए जोखिम भरे प्रश्नों जैसे LOCK TABLES और FLUSH TABLES with READ LOCK को सिस्टम को नुकसान पहुंचाने से पहले रोका जा सकता है, जबकि "हॉटस्पॉट" क्वेरीज़ (एक पंक्ति जिसे अलग-अलग क्वेरी एक ही समय में एक्सेस करना चाहते हैं) जैसे प्रश्नों को प्रभावित कर सकते हैं। लेन-देन के विरोध के जोखिम को कम करने के लिए फिर से लिखा जाना या एकल गैलेरा नोड पर पुनर्निर्देशित किया जाना। OLAP या बैकअप जैसे भारी-भरकम केवल-पढ़ने वाले प्रश्नों के लिए, यदि आपके पास कोई है तो आप उन्हें एसिंक्रोनस स्लेव पर रूट कर सकते हैं।
रिवर्स प्रॉक्सी टोपोलॉजी परिवर्तनों को समझने के लिए डेटाबेस स्थिति, प्रश्नों और चरों पर भी नज़र रखता है और बैकएंड सर्वरों के लिए एक सटीक रूटिंग निर्णय उत्पन्न करता है। परोक्ष रूप से, यह प्रत्येक गैलेरा नोड पर नियमित रूप से जांच करने की आवश्यकता के बिना नोड्स की निगरानी और क्लस्टर अवलोकन को केंद्रीकृत करता है। निम्न स्क्रीनशॉट ClusterControl में ProxySQL मॉनिटरिंग डैशबोर्ड दिखाता है:
ऐसे कई अन्य लाभ भी हैं जो एक लोड बैलेंसर गैलेरा क्लस्टर को महत्वपूर्ण रूप से बेहतर बनाने के लिए ला सकता है, जैसा कि इस ब्लॉग पोस्ट में विवरण में शामिल है, क्लस्टर कंट्रोल डीबीए बनें:लोड बैलेंसर्स के माध्यम से अपने डीबी घटकों को एचए बनाना।
अंतिम विचार
गैलेरा क्लस्टर आंतरिक रूप से कैसे काम करता है, इस पर अच्छी समझ के साथ, हम कुछ सीमाओं के आसपास काम कर सकते हैं और डेटाबेस सेवा में सुधार कर सकते हैं। हैप्पी क्लस्टरिंग!
