कंटेनर ऑर्केस्ट्रेशन टूल्स के बिना मारियाडीबी गैलेरा क्लस्टर चलाना:भाग एक

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

इस ब्लॉग पोस्ट में, हम यह देखने जा रहे हैं कि झुंड या कुबेरनेट्स जैसे ऑर्केस्ट्रेशन टूल की मदद के बिना, कई डॉकर होस्ट पर मानक डॉकर छवि का उपयोग करके डॉकर कंटेनरों पर मारियाडीबी गैलेरा क्लस्टर कैसे चलाया जाए। यह दृष्टिकोण मानक होस्ट पर गैलेरा क्लस्टर चलाने के समान है, लेकिन प्रक्रिया प्रबंधन डॉकर के माध्यम से कॉन्फ़िगर किया गया है।

इससे पहले कि हम विवरण में आगे बढ़ें, हम मानते हैं कि आपने डॉकर, अक्षम SElinux/AppArmor स्थापित किया है और iptables, फ़ायरवॉल या ufw (जो भी आप उपयोग कर रहे हैं) के अंदर नियमों को साफ़ कर दिया है। हमारे डेटाबेस क्लस्टर के लिए निम्नलिखित तीन समर्पित डॉकर होस्ट हैं:

host1.local - 192.168.55.161
host2.local - 192.168.55.162
host3.local - 192.168.55.163

मल्टी-होस्ट नेटवर्किंग

सबसे पहले, डिफ़ॉल्ट डॉकर नेटवर्किंग स्थानीय होस्ट के लिए बाध्य है। डॉकर झुंड एक और नेटवर्किंग परत पेश करता है जिसे ओवरले नेटवर्क कहा जाता है, जो झुंड नामक क्लस्टर में कई डॉकर होस्टों के लिए कंटेनर इंटरनेटवर्किंग का विस्तार करता है। इस एकीकरण के आने से बहुत पहले, इसका समर्थन करने के लिए कई नेटवर्क प्लगइन्स विकसित किए गए थे - फलालैन, केलिको, वीव उनमें से कुछ हैं।

यहां, हम मल्टी-होस्ट नेटवर्किंग के लिए वीव को डॉकर नेटवर्क प्लगइन के रूप में उपयोग करने जा रहे हैं। यह मुख्य रूप से इसे स्थापित करने और चलाने के लिए इसकी सादगी के कारण है, और DNS रिज़ॉल्वर के लिए समर्थन (इस नेटवर्क के तहत चलने वाले कंटेनर एक दूसरे के होस्टनाम को हल कर सकते हैं)। वीव को चलाने के दो तरीके हैं - सिस्टमड या डॉकर के माध्यम से। हम इसे सिस्टमड यूनिट के रूप में स्थापित करने जा रहे हैं, इसलिए यह डॉकर डेमॉन से स्वतंत्र है (अन्यथा, वीव सक्रिय होने से पहले हमें पहले डॉकर शुरू करना होगा)।

वीव डाउनलोड और इंस्टॉल करें:

$ curl -L git.io/weave -o /usr/local/bin/weave
$ chmod a+x /usr/local/bin/weave

वेव के लिए सिस्टमड यूनिट फाइल बनाएं:

$ cat > /etc/systemd/system/weave.service << EOF
[Unit]
Description=Weave Network
Documentation=http://docs.weave.works/weave/latest_release/
Requires=docker.service
After=docker.service
[Service]
EnvironmentFile=-/etc/sysconfig/weave
ExecStartPre=/usr/local/bin/weave launch --no-restart $PEERS
ExecStart=/usr/bin/docker attach weave
ExecStop=/usr/local/bin/weave stop
[Install]
WantedBy=multi-user.target
EOF

/etc/sysconfig/weave के अंदर साथियों के आईपी पते या होस्टनाम को परिभाषित करें:
```
$ echo 'PEERS="192.168.55.161 192.168.55.162 192.168.55.163"' > /etc/sysconfig/weave
```
बूट पर बुनाई शुरू करें और सक्षम करें:
```
$ systemctl start weave
$ systemctl enable weave
```

सभी डॉकर होस्ट पर उपरोक्त 4 चरणों को दोहराएं। एक बार हो जाने के बाद निम्नलिखित कमांड से सत्यापित करें:

$ weave status

साथियों की संख्या वह है जो हम देख रहे हैं। यह 3 होना चाहिए:

          ...
          Peers: 3 (with 6 established connections)
          ...

गैलेरा क्लस्टर चलाना

अब नेटवर्क तैयार है, यह हमारे डेटाबेस कंटेनरों को सक्रिय करने और एक क्लस्टर बनाने का समय है। बुनियादी नियम हैं:

मल्टी-होस्ट कनेक्टिविटी के लिए --net=weave के तहत कंटेनर बनाया जाना चाहिए।
प्रकाशित किए जाने वाले कंटेनर पोर्ट 3306, 4444, 4567, 4568 हैं।
डॉकर छवि को गैलेरा का समर्थन करना चाहिए। यदि आप Oracle MySQL का उपयोग करना चाहते हैं, तो कोडरशिप संस्करण प्राप्त करें। यदि आप Percona's चाहते हैं, तो इसके बजाय इस चित्र का उपयोग करें। इस ब्लॉग पोस्ट में, हम मारियाडीबी का उपयोग कर रहे हैं।

हमने मारियाडीबी को गैलेरा क्लस्टर विक्रेता के रूप में चुनने के कारण इस प्रकार हैं:

गैलेरा को मारियाडीबी 10.1 से शुरू करके मारियाडीबी में एम्बेड किया गया है।
MariaDB छवि का रखरखाव Docker और MariaDB टीमों द्वारा किया जाता है।
सबसे लोकप्रिय डॉकर छवियों में से एक।

गैलेरा क्लस्टर को बूटस्ट्रैपिंग क्रम में किया जाना है। सबसे पहले, सबसे अद्यतित नोड को "wsrep_cluster_address=gcomm://" से प्रारंभ किया जाना चाहिए। फिर, शेष नोड्स को क्लस्टर में सभी नोड्स से युक्त एक पूर्ण पते के साथ प्रारंभ करें, उदाहरण के लिए, "wsrep_cluster_address=gcomm://node1,node2,node3"। कंटेनर का उपयोग करके इन चरणों को पूरा करने के लिए, हमें यह सुनिश्चित करने के लिए कुछ अतिरिक्त कदम उठाने होंगे कि सभी कंटेनर सजातीय रूप से चल रहे हैं। तो योजना है:

हमें इस क्रम में 4 कंटेनरों से शुरुआत करनी होगी - mariadb0 (बूटस्ट्रैप), mariadb2, mariadb3, mariadb1।
कंटेनर mariadb0 mariadb1 के साथ एक ही datadir और configdir का उपयोग करेगा।
पहले बूटस्ट्रैप के लिए host1 पर mariadb0 का उपयोग करें, फिर host2 पर mariadb2 को, host3 पर mariadb3 को प्रारंभ करें।
mariadb1 को रास्ता देने के लिए mariadb0 को host1 से हटा दें।
आखिरकार, host1 पर mariadb1 शुरू करें।

दिन के अंत में, आपके पास तीन-नोड गैलेरा क्लस्टर (mariadb1, mariadb2, mariadb3) होगा। पहला कंटेनर (mariadb0) क्लस्टर पते "gcomm://" का उपयोग करके केवल बूटस्ट्रैपिंग उद्देश्यों के लिए एक क्षणिक कंटेनर है। यह mariadb1 के साथ समान डेटादिर और कॉन्फिगर को साझा करता है और एक बार क्लस्टर बनने के बाद हटा दिया जाएगा (mariadb2 और mariadb3 ऊपर हैं) और नोड्स सिंक हो गए हैं।

डिफ़ॉल्ट रूप से, गैलेरा को मारियाडीबी में बंद कर दिया जाता है और इसे wsrep_on नामक ध्वज के साथ सक्षम करने की आवश्यकता होती है। (चालू पर सेट) और wsrep_provider (गैलेरा लाइब्रेरी पथ पर सेट) प्लस कई गैलेरा-संबंधित पैरामीटर। इस प्रकार, हमें गैलेरा को सही ढंग से कॉन्फ़िगर करने के लिए कंटेनर के लिए एक कस्टम कॉन्फ़िगरेशन फ़ाइल को परिभाषित करने की आवश्यकता है।

आइए पहले कंटेनर से शुरू करते हैं, mariadb0. /containers/mariadb1/conf.d/my.cnf के अंतर्गत एक फ़ाइल बनाएँ और निम्नलिखित पंक्तियाँ जोड़ें:

$ mkdir -p /containers/mariadb1/conf.d
$ cat /containers/mariadb1/conf.d/my.cnf
[mysqld]

default_storage_engine          = InnoDB
binlog_format                   = ROW

innodb_flush_log_at_trx_commit  = 0
innodb_flush_method             = O_DIRECT
innodb_file_per_table           = 1
innodb_autoinc_lock_mode        = 2
innodb_lock_schedule_algorithm  = FCFS # MariaDB >10.1.19 and >10.2.3 only

wsrep_on                        = ON
wsrep_provider                  = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method                = xtrabackup-v2

चूंकि छवि मारियाडीबी बैकअप के साथ नहीं आती है (जो मारियाडीबी 10.1 और मारियाडीबी 10.2 के लिए पसंदीदा एसएसटी विधि है), हम फिलहाल के लिए xtrabackup-v2 के साथ रहने जा रहे हैं।

क्लस्टर के लिए पहला बूटस्ट्रैप करने के लिए, बूटस्ट्रैप कंटेनर (mariadb0) को host1 पर mariadb1 के "datadir" और "conf.d" के साथ चलाएं:

$ docker run -d \
        --name mariadb0 \
        --hostname mariadb0.weave.local \
        --net weave \
        --publish "3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --env MYSQL_USER=proxysql \
        --env MYSQL_PASSWORD=proxysqlpassword \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm:// \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb0.weave.local

उपरोक्त कमांड में प्रयुक्त पैरामीटर हैं:

--नाम , "mariadb0" नाम का कंटेनर बनाता है,
--होस्टनाम , कंटेनर को एक होस्टनाम "mariadb0.weave.local" निर्दिष्ट करता है,
--नेट , मल्टी-होस्ट नेटवर्किंग समर्थन के लिए कंटेनर को बुनाई नेटवर्क में रखता है,
--प्रकाशित करें , होस्ट के लिए कंटेनर पर पोर्ट 3306, 4444, 4567, 4568 प्रदर्शित करता है,
$(डीएनएस-आर्ग बुनें) , इस कंटेनर के लिए DNS रिज़ॉल्वर को कॉन्फ़िगर करता है। इस कमांड का अनुवाद डॉकर रन में "--dns=172.17.0.1 --dns-search=weave.local" के रूप में किया जा सकता है,
--env MYSQL_ROOT_PASSWORD , MySQL रूट पासवर्ड,
--env MYSQL_USER , "proxysql" उपयोगकर्ता बनाता है जिसे बाद में डेटाबेस रूटिंग के लिए ProxySQL के साथ उपयोग किया जाएगा,
--env MYSQL_PASSWORD , "proxysql" उपयोगकर्ता पासवर्ड,
--वॉल्यूम /कंटेनर/mariadb1/datadir:/var/lib/mysql , बनाता है /containers/mariadb1/datadir यदि मौजूद नहीं है और इसे कंटेनर के /var/lib/mysql (MySQL डेटादिर) के साथ मैप करें (बूटस्ट्रैप नोड के लिए, इसे छोड़ा जा सकता है),
--वॉल्यूम /कंटेनर/mariadb1/conf.d:/etc/mysql/mariadb.conf.d , डॉकर होस्ट की निर्देशिका /containers/mariadb1/conf.d के अंतर्गत फ़ाइलों को /etc/mysql/mariadb.conf.d पर कंटेनर में माउंट करता है।
मारियाडीबी:10.2.15 , यहां से मारियाडीबी 10.2.15 छवि का उपयोग करता है,
--wsrep_cluster_address , क्लस्टर के लिए गैलेरा कनेक्शन स्ट्रिंग। "gcomm://" का अर्थ बूटस्ट्रैप है। बाकी कंटेनरों के लिए, हम इसके बजाय एक पूर्ण पते का उपयोग करने जा रहे हैं।
--wsrep_sst_auth , एसएसटी उपयोगकर्ता के लिए प्रमाणीकरण स्ट्रिंग। रूट के समान उपयोगकर्ता का उपयोग करें,
--wsrep_node_address , नोड होस्टनाम, इस मामले में हम Weave द्वारा प्रदान किए गए FQDN का उपयोग करने जा रहे हैं।

बूटस्ट्रैप कंटेनर में कई महत्वपूर्ण चीज़ें होती हैं:

नाम, होस्टनाम और wsrep_node_address mariadb0 है, लेकिन यह mariadb1 के वॉल्यूम का उपयोग करता है।
क्लस्टर पता "gcomm://" है
दो अतिरिक्त --env पैरामीटर हैं - MYSQL_USER और MYSQL_PASSWORD। यह पैरामीटर हमारे प्रॉक्सीएसक्यूएल निगरानी उद्देश्य के लिए अतिरिक्त उपयोगकर्ता तैयार करेगा।

निम्न आदेश के साथ सत्यापित करें:

$ docker ps
$ docker logs -f mariadb0

एक बार जब आप निम्न पंक्ति देखते हैं, तो यह इंगित करता है कि बूटस्ट्रैप प्रक्रिया पूरी हो गई है और गैलेरा सक्रिय है:

2018-05-30 23:19:30 139816524539648 [Note] WSREP: Synchronized with group, ready for connections

हमारी कस्टम कॉन्फ़िगरेशन फ़ाइल को शेष होस्ट में लोड करने के लिए निर्देशिका बनाएँ:

$ mkdir -p /containers/mariadb2/conf.d # on host2
$ mkdir -p /containers/mariadb3/conf.d # on host3

फिर, हमारे द्वारा बनाए गए my.cnf को क्रमशः mariadb0 और mariadb1 से mariadb2 और mariadb3 में कॉपी करें:

$ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb2/conf.d/ # on host1
$ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb3/conf.d/ # on host1

इसके बाद, क्रमशः host2 और host3 पर एक और 2 डेटाबेस कंटेनर (mariadb2 और mariadb3) बनाएं:

$ docker run -d \
        --name ${NAME} \
        --hostname ${NAME}.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/${NAME}/datadir:/var/lib/mysql \
        --volume /containers/${NAME}/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=${NAME}.weave.local

** ${NAME} को क्रमशः mariadb2 या mariadb3 से बदलें।

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

018-05-30 23:27:13 140003794790144 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
MySQL init process in progress…
MySQL init process failed.

चाल विफल कंटेनरों को एक बार फिर से शुरू करना है, क्योंकि इस बार, MySQL डेटादिर बनाया गया होगा (पहले रन प्रयास में) और यह डेटाबेस आरंभीकरण भाग को छोड़ देगा:

$ docker start mariadb2 # on host2
$ docker start mariadb3 # on host3

एक बार शुरू करने के बाद, निम्न पंक्ति को देखकर सत्यापित करें:

$ docker logs -f mariadb2
…
2018-05-30 23:28:39 139808069601024 [Note] WSREP: Synchronized with group, ready for connections

इस समय, 3 कंटेनर चल रहे हैं, mariadb0, mariadb2 और mariadb3। ध्यान दें कि mariadb0 बूटस्ट्रैप कमांड (gcomm://) का उपयोग करके शुरू किया गया है, जिसका अर्थ है कि यदि भविष्य में कंटेनर को डॉकर द्वारा स्वचालित रूप से पुनरारंभ किया जाता है, तो यह संभावित रूप से प्राथमिक घटक से अलग हो सकता है। इस प्रकार, हमें इस कंटेनर को हटाने और इसे mariadb1 के साथ बदलने की आवश्यकता है, बाकी के साथ समान गैलेरा कनेक्शन स्ट्रिंग का उपयोग करके और उसी डेटादिर और configdir का उपयोग mariadb0 के साथ करें।

सबसे पहले, SIGTERM भेजकर mariadb0 को रोकें (यह सुनिश्चित करने के लिए कि नोड इनायत से बंद होने वाला है):

$ docker kill -s 15 mariadb0

फिर, mariadb1 को mariadb2 या mariadb3 के समान कमांड का उपयोग करके host1 पर शुरू करें:

$ docker run -d \
        --name mariadb1 \
        --hostname mariadb1.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb1.weave.local

इस बार, आपको पुनरारंभ करने की चाल करने की आवश्यकता नहीं है क्योंकि MySQL डेटादिर पहले से मौजूद है (mariadb0 द्वारा निर्मित)। कंटेनर शुरू होने के बाद, सत्यापित करें कि क्लस्टर का आकार 3 है, स्थिति प्राथमिक में होनी चाहिए और स्थानीय स्थिति समन्वयित हो:

$ docker exec -it mariadb3 mysql -uroot "-pPM7%[email protected]^1" -e 'select variable_name, variable_value from information_schema.global_status where variable_name in ("wsrep_cluster_size", "wsrep_local_state_comment", "wsrep_cluster_status", "wsrep_incoming_addresses")'
+---------------------------+-------------------------------------------------------------------------------+
| variable_name             | variable_value                                                                |
+---------------------------+-------------------------------------------------------------------------------+
| WSREP_CLUSTER_SIZE        | 3                                                                             |
| WSREP_CLUSTER_STATUS      | Primary                                                                       |
| WSREP_INCOMING_ADDRESSES  | mariadb1.weave.local:3306,mariadb3.weave.local:3306,mariadb2.weave.local:3306 |
| WSREP_LOCAL_STATE_COMMENT | Synced                                                                        |
+---------------------------+-------------------------------------------------------------------------------+

इस समय, हमारी वास्तुकला कुछ इस तरह दिख रही है:

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

ProxySQL के साथ डेटाबेस रूटिंग

अब हमारे पास तीन डेटाबेस कंटेनर चल रहे हैं। क्लस्टर तक पहुंचने का एकमात्र तरीका अब अलग-अलग डॉकर होस्ट के MySQL के प्रकाशित पोर्ट तक पहुंचना है, जो कि 3306 है (कंटेनर के लिए 3306 का नक्शा)। तो क्या होता है यदि डेटाबेस कंटेनरों में से एक विफल हो जाता है? आपको अगले उपलब्ध नोड में क्लाइंट के कनेक्शन को मैन्युअल रूप से विफल करना होगा। एप्लिकेशन कनेक्टर के आधार पर, आप नोड्स की एक सूची भी निर्दिष्ट कर सकते हैं और कनेक्टर को आपके लिए विफलता और क्वेरी रूटिंग करने दें (कनेक्टर/जे, PHP mysqlnd)। अन्यथा, डेटाबेस संसाधनों को एक एकल संसाधन में एकीकृत करना एक अच्छा विचार होगा, जिसे एक सेवा कहा जा सकता है।

यह वह जगह है जहाँ ProxySQL तस्वीर में आता है। ProxySQL क्वेरी राउटर के रूप में कार्य कर सकता है, जो कि झुंड या कुबेरनेट्स दुनिया में "सेवा" के समान डेटाबेस कनेक्शन को संतुलित करता है। हमने इस उद्देश्य के लिए एक प्रॉक्सीएसक्यूएल डॉकर छवि बनाई है और हम अपने सर्वोत्तम प्रयास के साथ हर नए संस्करण के लिए छवि को बनाए रखेंगे।

ProxySQL कंटेनर चलाने से पहले, हमें कॉन्फ़िगरेशन फ़ाइल तैयार करनी होगी। निम्नलिखित वह है जिसे हमने प्रॉक्सीएसक्यूएल 1 के लिए कॉन्फ़िगर किया है। हम host1 पर /containers/proxysql1/proxysql.cnf के अंतर्गत एक कस्टम कॉन्फ़िगरेशन फ़ाइल बनाते हैं:

$ cat /containers/proxysql1/proxysql.cnf
datadir="/var/lib/proxysql"
admin_variables=
{
        admin_credentials="admin:admin"
        mysql_ifaces="0.0.0.0:6032"
        refresh_interval=2000
}
mysql_variables=
{
        threads=4
        max_connections=2048
        default_query_delay=0
        default_query_timeout=36000000
        have_compress=true
        poll_timeout=2000
        interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
        default_schema="information_schema"
        stacksize=1048576
        server_version="5.1.30"
        connect_timeout_server=10000
        monitor_history=60000
        monitor_connect_interval=200000
        monitor_ping_interval=200000
        ping_interval_server=10000
        ping_timeout_server=200
        commands_stats=true
        sessions_sort=true
        monitor_username="proxysql"
        monitor_password="proxysqlpassword"
}
mysql_servers =
(
        { address="mariadb1.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb1.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=20, max_connections=100 }
)
mysql_users =
(
        { username = "sbtest" , password = "password" , default_hostgroup = 10 , active = 1 }
)
mysql_query_rules =
(
        {
                rule_id=100
                active=1
                match_pattern="^SELECT .* FOR UPDATE"
                destination_hostgroup=10
                apply=1
        },
        {
                rule_id=200
                active=1
                match_pattern="^SELECT .*"
                destination_hostgroup=20
                apply=1
        },
        {
                rule_id=300
                active=1
                match_pattern=".*"
                destination_hostgroup=10
                apply=1
        }
)
scheduler =
(
        {
                id = 1
                filename = "/usr/share/proxysql/tools/proxysql_galera_checker.sh"
                active = 1
                interval_ms = 2000
                arg1 = "10"
                arg2 = "20"
                arg3 = "1"
                arg4 = "1"
                arg5 = "/var/lib/proxysql/proxysql_galera_checker.log"
        }
)

उपरोक्त विन्यास होगा:

दो होस्ट समूह कॉन्फ़िगर करें, एकल-लेखक और बहु-लेखक समूह, जैसा कि "mysql_servers" अनुभाग के अंतर्गत परिभाषित किया गया है,
सभी गैलेरा नोड्स (होस्टग्रुप 20) को रीड्स भेजें, जबकि राइट ऑपरेशंस सिंगल गैलेरा सर्वर (होस्टग्रुप 10) पर जाएंगे,
proxysql_galera_checker.sh शेड्यूल करें,
जब हमने पहली बार क्लस्टर (mariadb0) को बूटस्ट्रैप किया था, तब बनाए गए मॉनिटरिंग क्रेडेंशियल के रूप में मॉनिटर_यूज़रनेम और मॉनिटर_पासवर्ड का उपयोग करें।

ProxySQL अतिरेक के लिए कॉन्फ़िगरेशन फ़ाइल को host2 में कॉपी करें:

$ mkdir -p /containers/proxysql2/ # on host2
$ scp /containers/proxysql1/proxysql.cnf /container/proxysql2/ # on host1

फिर, ProxySQL कंटेनर को क्रमशः host1 और host2 पर चलाएँ:

$ docker run -d \
        --name=${NAME} \
        --publish 6033 \
        --publish 6032 \
        --restart always \
        --net=weave \
        $(weave dns-args) \
        --hostname ${NAME}.weave.local \
        -v /containers/${NAME}/proxysql.cnf:/etc/proxysql.cnf \
        -v /containers/${NAME}/data:/var/lib/proxysql \
        severalnines/proxysql

** ${NAME} को क्रमशः proxysql1 या proxysql2 से बदलें।

हमने निर्दिष्ट किया है --restart=always बाहर निकलने की स्थिति की परवाह किए बिना इसे हमेशा उपलब्ध कराने के लिए, साथ ही डॉकर डेमॉन शुरू होने पर स्वचालित स्टार्टअप। यह सुनिश्चित करेगा कि ProxySQL कंटेनर डेमॉन की तरह काम करें।

दोनों ProxySQL इंस्टेंसेस द्वारा मॉनिटर किए गए MySQL सर्वर की स्थिति को सत्यापित करें (OFFLINE_SOFT एकल-लेखक होस्ट समूह के लिए अपेक्षित है):

$ docker exec -it proxysql1 mysql -uadmin -padmin -h127.0.0.1 -P6032 -e 'select hostgroup_id,hostname,status from mysql_servers'
+--------------+----------------------+--------------+
| hostgroup_id | hostname             | status       |
+--------------+----------------------+--------------+
| 10           | mariadb1.weave.local | ONLINE       |
| 10           | mariadb2.weave.local | OFFLINE_SOFT |
| 10           | mariadb3.weave.local | OFFLINE_SOFT |
| 20           | mariadb1.weave.local | ONLINE       |
| 20           | mariadb2.weave.local | ONLINE       |
| 20           | mariadb3.weave.local | ONLINE       |
+--------------+----------------------+--------------+

इस समय, हमारी वास्तुकला कुछ इस तरह दिख रही है:

6033 से आने वाले सभी कनेक्शन (होस्ट 1, होस्ट 2 या कंटेनर के नेटवर्क से) प्रॉक्सीएसक्यूएल का उपयोग करके बैकएंड डेटाबेस कंटेनर में संतुलित लोड होंगे। यदि आप किसी व्यक्तिगत डेटाबेस सर्वर तक पहुँच प्राप्त करना चाहते हैं, तो इसके बजाय भौतिक होस्ट के पोर्ट 3306 का उपयोग करें। ProxySQL सेवा के लिए कॉन्फ़िगर किए गए एकल समापन बिंदु के रूप में कोई वर्चुअल IP पता नहीं है, लेकिन हम इसे Keepalived का उपयोग करके प्राप्त कर सकते हैं, जिसे अगले भाग में समझाया गया है।

कीपलाइव के साथ वर्चुअल आईपी पता

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

हमेशा की तरह, हमारी Keepalived सेवा के लिए एक कस्टम कॉन्फ़िगरेशन फ़ाइल बनाएँ। यहां /containers/keepalived1/keepalived.conf की सामग्री दी गई है:

vrrp_instance VI_DOCKER {
   interface ens33               # interface to monitor
   state MASTER
   virtual_router_id 52          # Assign one ID for this route
   priority 101
   unicast_src_ip 192.168.55.161
   unicast_peer {
      192.168.55.162
   }
   virtual_ipaddress {
      192.168.55.160             # the virtual IP
}

दूसरे उदाहरण के लिए कॉन्फ़िगरेशन फ़ाइल को host2 पर कॉपी करें:

$ mkdir -p /containers/keepalived2/ # on host2
$ scp /containers/keepalived1/keepalived.conf /container/keepalived2/ # on host1

होस्ट2 पर कॉपी की गई कॉन्फ़िगरेशन फ़ाइल के अंदर प्राथमिकता को 101 से 100 में बदलें:

$ sed -i 's/101/100/g' /containers/keepalived2/keepalived.conf

**उच्च प्राथमिकता वाला उदाहरण वर्चुअल आईपी पता (इस मामले में होस्ट1 है) को तब तक धारण करेगा, जब तक कि VRRP संचार बाधित नहीं हो जाता (होस्ट1 के नीचे जाने की स्थिति में)।

फिर, क्रमशः host1 और host2 पर निम्न कमांड चलाएँ:

$ docker run -d \
        --name=${NAME} \
        --cap-add=NET_ADMIN \
        --net=host \
        --restart=always \
        --volume /containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf \ osixia/keepalived:1.4.4

** ${NAME} को Keepalived1 और Keepalived2 से बदलें।

रन कमांड डॉकर को बताता है:

--नाम , इसके साथ एक कंटेनर बनाएं
--cap-add=NET_ADMIN , नेटवर्क व्यवस्थापक क्षेत्र के लिए Linux क्षमताएं जोड़ें
--net=होस्ट , कंटेनर को होस्ट नेटवर्क में संलग्न करें। यह होस्ट इंटरफ़ेस पर वर्चुअल IP पता प्रदान करेगा, ens33
--restart=हमेशा , कंटेनर को हमेशा चालू रखें,
--volume=/containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf , कंटेनर के उपयोग के लिए कस्टम कॉन्फ़िगरेशन फ़ाइल को मैप करें।

दोनों कंटेनरों के शुरू होने के बाद, मास्टर नोड के भौतिक नेटवर्क इंटरफेस को देखकर वर्चुअल आईपी एड्रेस के अस्तित्व को सत्यापित करें:

$ ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 192.168.55.161/24 brd 192.168.55.255 scope global ens33
    inet 192.168.55.160/32 scope global ens33

क्लाइंट और एप्लिकेशन अब डेटाबेस सेवा तक पहुंचने के लिए वर्चुअल आईपी एड्रेस, 192.168.55.160 का उपयोग कर सकते हैं। यह वर्चुअल IP पता इस समय host1 पर मौजूद है। यदि होस्ट1 नीचे चला जाता है, तो Keepalived2 IP पते को ले लेगा और उसे होस्ट2 पर लाएगा। ध्यान दें कि इस Keepalived के लिए कॉन्फ़िगरेशन ProxySQL कंटेनरों की निगरानी नहीं करता है। यह केवल Keepalived साथियों के VRRP विज्ञापन की निगरानी करता है।

इस समय, हमारी वास्तुकला कुछ इस तरह दिख रही है:

सारांश

तो, अब हमारे पास एक अत्यधिक उपलब्ध प्रॉक्सीएसक्यूएल सेवा के सामने एक मारियाडीबी गैलेरा क्लस्टर है, जो सभी डॉकर कंटेनरों पर चल रहा है।

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

हैप्पी कंटेनराइज़िंग!