डॉकर पर मारियाडीबी मैक्सस्केल लोड बैलेंसिंग:प्रबंधन:भाग दो

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

सेवा नियंत्रण

मैक्सस्केल के लिए, सेवा को नियंत्रित करने का एकमात्र तरीका कंटेनर को शुरू करना और रोकना है। बशर्ते कंटेनर बनाया गया हो, हम सेवा को प्रबंधित करने के लिए निम्न कमांड का उपयोग कर सकते हैं:

$ docker start maxscale
$ docker stop maxscale
$ docker restart maxscale

रूट विशेषाधिकार के बिना चल रहा है

डिफ़ॉल्ट रूप से डॉकर कंटेनर रूट विशेषाधिकार के साथ चलते हैं और ऐसा ही कंटेनर के अंदर चलने वाला एप्लिकेशन भी करता है। सुरक्षा के दृष्टिकोण से यह एक और प्रमुख चिंता का विषय है क्योंकि हैकर्स कंटेनर के अंदर चल रहे एप्लिकेशन को हैक करके डॉकर होस्ट तक रूट एक्सेस प्राप्त कर सकते हैं।

डॉकर को गैर-रूट उपयोगकर्ता के रूप में चलाने के लिए, आपको अपने उपयोगकर्ता को डॉकर समूह में जोड़ना होगा। सबसे पहले, यदि कोई नहीं है तो एक डॉकर समूह बनाएं:

$ sudo groupadd docker

फिर, अपने उपयोगकर्ता को डॉकर समूह में जोड़ें। इस उदाहरण में हमारा उपयोगकर्ता "आवारा" है:

$ sudo usermod -aG docker vagrant

लॉग आउट करें और वापस लॉग इन करें ताकि आपकी समूह सदस्यता का पुनर्मूल्यांकन किया जा सके (या अगर यह काम नहीं करता है तो रीबूट करें)। इस बिंदु पर, आप MaxScale कंटेनर को मानक रन कमांड (कोई sudo आवश्यक नहीं) के साथ उपयोगकर्ता "आवारा" के रूप में चला सकते हैं:

$ docker run -d \
--name maxscale-unprivileged \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale

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

कॉन्फ़िगरेशन प्रबंधन

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

$ cat maxscale.cnf | docker config create maxscale_config_v2 -

फिर, पुराने कॉन्फिग (maxscale_config) को हटाकर सेवा को अपडेट करें और उसी लक्ष्य में नया (maxscale_config_v2) जोड़ें:

$ docker service update \
--config-rm maxscale_config \
--config-add source=maxscale_config_v2,target=/etc/maxscale.cnf \
maxscale-cluster

डॉकर झुंड तब कंटेनर हटाने को शेड्यूल करेगा और एक समय में एक कंटेनर की प्रक्रियाओं को तब तक बदल देगा जब तक कि प्रतिकृति की आवश्यकता पूरी न हो जाए।

अपग्रेड और डाउनग्रेड

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

$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.3
$ docker rm -f maxscale
$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.2

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

2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'master_reconnection' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'master_reconnection'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'delayed_retry' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'delayed_retry'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'transaction_replay_max_size' for object 'rw-service' of type 'service', or '1Mi' is an invalid value for parameter 'transaction_replay_max_size'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'transaction_replay' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'transaction_replay'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads_timeout' for object 'rw-service' of type 'service', or '10' is an invalid value for parameter 'causal_reads_timeout'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'causal_reads'.

कंटेनर छवि को डाउनग्रेड करने से पहले हमें जो करना है वह असमर्थित कॉन्फ़िगरेशन विकल्पों को हटाने के लिए है जैसा कि कॉन्फ़िगरेशन फ़ाइल में ऊपर दिखाया गया है:

master_reconnection
विलंबित_पुन:प्रयास
transaction_replay
causal_reads_timeout
कारण_पढ़ें

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

मैक्सस्केल फ़िल्टर

MaxScale अनुरोधों में हेरफेर करने या उन्हें संसाधित करने के लिए फ़िल्टर नामक एक घटक का उपयोग करता है क्योंकि वे इसके माध्यम से गुजरते हैं। ऐसे कई फ़िल्टर हैं जिनका आप उपयोग कर सकते हैं, जैसा कि इस पृष्ठ में सूचीबद्ध है, MaxScale 2.3 फ़िल्टर। उदाहरण के लिए, एक विशिष्ट क्वेरी को किसी फ़ाइल में लॉग इन किया जा सकता है यदि वह किसी मानदंड से मेल खाती है या आप आने वाली क्वेरी को बैकएंड सर्वर तक पहुंचने से पहले फिर से लिख सकते हैं।

फ़िल्टर को सक्रिय करने के लिए, आपको एक सेक्शन को परिभाषित करना होगा और परिभाषा नाम को संबंधित सेवा परिभाषा में शामिल करना होगा, जैसा कि नीचे दिए गए उदाहरणों में दिखाया गया है।

क्वेरी लॉगिंग ऑल (QLA)

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

सबसे पहले, घटक को type=filter और मॉड्यूल=qlafilter के साथ परिभाषित करें:

## Query Log All (QLA) filter
## Filter module for MaxScale to log all query content on a per client session basis
[qla-sbtest-no-pk]
type		= filter
module		= qlafilter
filebase	= /tmp/sbtest
match		= select.*from.*
exclude		= where.*id.*
user		= sbtest

फिर हमारी सेवाओं में फ़िल्टर घटक जोड़ें:

[rw-service]
...
filters        = qla-sbtest-no-pk
[rr-service]
...
filters        = qla-sbtest-no-pk

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

$ mkdir qla
$ chmod 777 qla

चूंकि हमें उपरोक्त निर्देशिका को कंटेनर में बाँधने की आवश्यकता है, इसलिए हमें चल रहे कंटेनर को रोकना और निकालना होगा और इसे निम्न कमांड के साथ फिर से चलाना होगा:

$ docker stop maxscale
$ docker run -d \
--name maxscale \
--restart always \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
-v $PWD/qla:/tmp \
mariadb/maxscale

फिर आप qla निर्देशिका के अंदर लॉग की गई क्वेरी की सामग्री को पुनः प्राप्त कर सकते हैं:

$ cat qla/*
Date,[email protected],Query
2019-06-18 08:25:13,[email protected]::ffff:192.168.0.19,select * from sbtest.sbtest1

क्वेरी पुनर्लेखन

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

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

निम्न फ़िल्टर कई SHOW कमांड से मेल खाएगा जिन्हें हम केवल-पढ़ने वाले क्लाइंट के सामने प्रदर्शित नहीं करना चाहते:

## Rewrite query based on regex match and replace
[block-show-commands]
type            = filter
module          = regexfilter
options         = ignorecase
match           = ^show (variables|global variables|global status|status|processlist|full processlist).*
replace         = SELECT 'Not allowed'

फिर हम फ़िल्टर को उस सेवा में जोड़ सकते हैं जिसे हम लागू करना चाहते हैं। उदाहरण के लिए, उपरोक्त के लिए सभी रीड-ओनली कनेक्शनों को फ़िल्टर करना होगा:

[rr-service]
...
filters        = qla-sbtest-no-pk | block-show-commands

ध्यान रखें कि लिनक्स शेल पाइप "|" के समान सिंटैक्स का उपयोग करके एकाधिक फ़िल्टर को परिभाषित किया जा सकता है वाक्य - विन्यास। कॉन्फ़िगरेशन परिवर्तन लागू करने के लिए कंटेनर को पुनरारंभ करें:

$ docker restart maxscale

फिर हम निम्नलिखित क्वेरी से सत्यापित कर सकते हैं:

$ mysql -usbtest -p -h192.168.0.200 -P4006 -e 'SHOW VARIABLES LIKE "max_connections"'
+-------------+
| Not allowed |
+-------------+
| Not allowed |
+-------------+

आपको उम्मीद के मुताबिक परिणाम मिलेगा।

क्लस्टर पुनर्प्राप्ति

MaxScale 2.2.2 और बाद में निम्नलिखित घटनाओं के लिए स्वचालित या मैन्युअल MariaDB प्रतिकृति या क्लस्टर पुनर्प्राप्ति का समर्थन करता है:

विफलता
स्विचओवर
फिर से शामिल हों
रीसेट-प्रतिकृति

मास्टर-स्लेव क्लस्टर के लिए विफलता को स्वचालित रूप से सक्रिय करने के लिए सेट किया जा सकता है और अक्सर सेट किया जाना चाहिए। स्विचओवर को MaxAdmin, MaxCtrl या REST इंटरफ़ेस के माध्यम से मैन्युअल रूप से सक्रिय किया जाना चाहिए। रीजॉइन को स्वचालित या मैन्युअल रूप से सक्रिय करने के लिए सेट किया जा सकता है। ये सुविधाएँ "mariadbmon" मॉड्यूल में लागू की गई हैं।

यदि हम जानबूझकर सक्रिय मास्टर, 192.168.0.91 को बंद करते हैं, तो निम्नलिखित स्वचालित विफलता घटनाएँ हुईं:

$ docker logs -f maxscale
...
2019-06-19 03:53:02.348   error  : (mon_log_connect_error): Monitor was unable to connect to server mariadb1[192.168.0.91:3306] : 'Can't connect to MySQL server on '192.168.0.91' (115)'
2019-06-19 03:53:02.351   notice : (mon_log_state_change): Server changed state: mariadb1[192.168.0.91:3306]: master_down. [Master, Running] -> [Down]
2019-06-19 03:53:02.351   warning: (handle_auto_failover): Master has failed. If master status does not change in 4 monitor passes, failover begins.
2019-06-19 03:53:16.710   notice : (select_promotion_target): Selecting a server to promote and replace 'mariadb1'. Candidates are: 'mariadb2', 'mariadb3'.
2019-06-19 03:53:16.710   warning: (warn_replication_settings): Slave 'mariadb2' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   warning: (warn_replication_settings): Slave 'mariadb3' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   notice : (select_promotion_target): Selected 'mariadb2'.
2019-06-19 03:53:16.711   notice : (handle_auto_failover): Performing automatic failover to replace failed master 'mariadb1'.
2019-06-19 03:53:16.723   notice : (redirect_slaves_ex): Redirecting 'mariadb3' to replicate from 'mariadb2' instead of 'mariadb1'.
2019-06-19 03:53:16.742   notice : (redirect_slaves_ex): All redirects successful.
2019-06-19 03:53:17.249   notice : (wait_cluster_stabilization): All redirected slaves successfully started replication from 'mariadb2'.
2019-06-19 03:53:17.249   notice : (handle_auto_failover): Failover 'mariadb1' -> 'mariadb2' performed.
2019-06-19 03:53:20.363   notice : (mon_log_state_change): Server changed state: mariadb2[192.168.0.92:3306]: new_master. [Slave, Running] -> [Master, Running]

फ़ेलओवर पूर्ण होने के बाद, हमारी टोपोलॉजी अब इस तरह दिख रही है:

स्विचओवर ऑपरेशन के लिए, इसमें मानवीय हस्तक्षेप की आवश्यकता होती है और इसे MaxCtrl कंसोल के माध्यम से करने का एक तरीका है। मान लें कि पुराना मास्टर वापस चालू हो गया है और एक मास्टर के रूप में पदोन्नत होने के लिए तैयार है, हम निम्नलिखित कमांड भेजकर स्विचओवर ऑपरेशन कर सकते हैं:

$ docker exec -it maxscale maxctrl
maxctrl: call command mariadbmon switchover monitor mariadb1 mariadb2
OK

कहां, स्वरूपण है:

$ call command <monitoring module> <operation> <monitoring section name> <new master> <current master>

फिर, सर्वरों को सूचीबद्ध करके नई टोपोलॉजी सत्यापित करें:

 maxctrl: list servers
┌──────────┬──────────────┬──────┬─────────────┬─────────────────┬──────────────┐
│ Server   │ Address      │ Port │ Connections │ State           │ GTID         │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb1 │ 192.168.0.91 │ 3306 │ 0           │ Master, Running │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb2 │ 192.168.0.92 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb3 │ 192.168.0.93 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
└──────────┴──────────────┴──────┴─────────────┴─────────────────┴──────────────┘

हमने अभी-अभी अपने पुराने गुरु को उसके मूल स्थान पर पदोन्नत किया है। मजेदार तथ्य, ClusterControl स्वचालित पुनर्प्राप्ति सुविधा सक्षम होने पर ठीक यही काम करती है।

अंतिम विचार

डॉकर पर मारियाडीबी मैक्सस्केल चलाने से मैक्सस्केल क्लस्टरिंग, अपग्रेड और डाउनग्रेड करने में आसान, और MySQL और मारियाडीबी क्लस्टर के लिए उन्नत प्रॉक्सीइंग कार्यक्षमता जैसे अतिरिक्त लाभ मिलते हैं।