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

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

इस ब्लॉग के भाग 1 के कुछ मुख्य बिंदुओं को संक्षेप में बताने के लिए, हमने तीन अलग-अलग डॉकर होस्ट पर ProxySQL और Keepalived के साथ एक तीन-नोड गैलेरा क्लस्टर तैनात किया है, जहां सभी मारियाडीबी इंस्टेंसेस डॉकर कंटेनर के रूप में चलते हैं। निम्नलिखित आरेख अंतिम परिनियोजन को दर्शाता है:

सुंदर शटडाउन

एक सुंदर MySQL शटडाउन करने के लिए, कंटेनर में SIGTERM (सिग्नल 15) भेजने का सबसे अच्छा तरीका है:

$ docker kill -s 15 {db_container_name}

यदि आप क्लस्टर को बंद करना चाहते हैं, तो उपरोक्त आदेश को सभी डेटाबेस कंटेनर, एक समय में एक नोड पर दोहराएं। उपरोक्त मारियाडीबी के लिए सिस्टमड सेवा में "systemctl stop mysql" करने के समान है। डेटाबेस सेवा के लिए "डॉकर स्टॉप" कमांड का उपयोग करना बहुत जोखिम भरा है क्योंकि यह 10 सेकंड के टाइमआउट की प्रतीक्षा करता है और यदि यह अवधि पार हो जाती है तो डॉकर सिगकिल को बाध्य करेगा (जब तक कि आप उचित --टाइमआउट का उपयोग नहीं करते हैं) मूल्य)।

अंतिम नोड जो इनायत से बंद हो जाता है, उसके पास seqno . होगा -1 और safe_to_bootstrap . के बराबर नहीं डॉकर होस्ट के /{datadir Volume}/grastate.dat में ध्वज 1 पर सेट है, उदाहरण के लिए host2 पर:

$ cat /containers/mariadb2/datadir/grastate.dat
# GALERA saved state
version: 2.1
uuid:    e70b7437-645f-11e8-9f44-5b204e58220b
seqno:   7099
safe_to_bootstrap: 1

सबसे उन्नत नोड का पता लगाना

यदि क्लस्टर इनायत से बंद नहीं हुआ, या जिस नोड को आप बूटस्ट्रैप करने का प्रयास कर रहे थे, वह क्लस्टर छोड़ने के लिए अंतिम नोड नहीं था, तो संभवतः आप गैलेरा नोड में से किसी एक को बूटस्ट्रैप करने में सक्षम नहीं होंगे और निम्न त्रुटि का सामना कर सकते हैं :

2016-11-07 01:49:19 5572 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node.
It was not the last one to leave the cluster and may not contain all the updates.
To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

गैलेरा उस नोड का सम्मान करता है जिसमें safe_to_bootstrap . है ध्वज को पहले संदर्भ नोड के रूप में 1 पर सेट किया गया है। यह डेटा हानि से बचने का सबसे सुरक्षित तरीका है और यह सुनिश्चित करता है कि सही नोड हमेशा बूटस्ट्रैप हो।

यदि आपको त्रुटि मिली है, तो हमें सबसे पहले सबसे उन्नत नोड का पता लगाना होगा, इससे पहले कि सबसे पहले नोड को बूटस्ट्रैप किया जाए। एक क्षणिक कंटेनर बनाएं (--rm . के साथ) ध्वज), इसे उसी डेटादिर और वास्तविक डेटाबेस कंटेनर की कॉन्फ़िगरेशन निर्देशिका में दो MySQL कमांड फ़्लैग के साथ मैप करें, --wsrep_recover और --wsrep_cluster_address . उदाहरण के लिए, यदि हम mariadb1 अंतिम प्रतिबद्ध संख्या जानना चाहते हैं, तो हमें चलाने की आवश्यकता है:

$ docker run --rm --name mariadb-recover \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/conf.d \
        mariadb:10.2.15 \
        --wsrep_recover \
        --wsrep_cluster_address=gcomm://
2018-06-12  4:46:35 139993094592384 [Note] mysqld (mysqld 10.2.15-MariaDB-10.2.15+maria~jessie) starting as process 1 ...
2018-06-12  4:46:35 139993094592384 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
...
2018-06-12  4:46:35 139993094592384 [Note] Plugin 'FEEDBACK' is disabled.
2018-06-12  4:46:35 139993094592384 [Note] Server socket created on IP: '::'.
2018-06-12  4:46:35 139993094592384 [Note] WSREP: Recovered position: e70b7437-645f-11e8-9f44-5b204e58220b:7099

आखिरी पंक्ति वह है जिसे हम ढूंढ रहे हैं। मारियाडीबी क्लस्टर यूयूआईडी और सबसे हाल ही में किए गए लेनदेन की अनुक्रम संख्या को प्रिंट करता है। जिस नोड में सबसे अधिक संख्या होती है उसे सबसे उन्नत नोड माना जाता है। चूंकि हमने --rm . निर्दिष्ट किया है , एक बार बाहर निकलने पर कंटेनर अपने आप हटा दिया जाएगा। --volume . के स्थान पर प्रत्येक डॉकर होस्ट पर उपरोक्त चरण को दोहराएं संबंधित डेटाबेस कंटेनर वॉल्यूम के लिए पथ।

एक बार जब आप सभी डेटाबेस कंटेनरों द्वारा रिपोर्ट किए गए मान की तुलना कर लेते हैं और तय कर लेते हैं कि कौन सा कंटेनर सबसे अद्यतित नोड है, तो safe_to_bootstrap बदलें मैन्युअल रूप से /{datadir Volume}/grastate.dat के अंदर 1 पर फ़्लैग करें। मान लें कि सभी नोड्स समान सटीक अनुक्रम संख्या की रिपोर्ट कर रहे हैं, हम safe_to_bootstrap को बदलकर बस mariadb3 को बूटस्ट्रैप करने के लिए चुन सकते हैं 1 का मान:

$ vim /containers/mariadb3/datadir/grasate.dat
...
safe_to_bootstrap: 1

फ़ाइल को सहेजें और उस नोड से क्लस्टर को बूटस्ट्रैप करना प्रारंभ करें, जैसा कि अगले अध्याय में वर्णित है।

क्लस्टर को बूटस्ट्रैप करना

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

$ docker start mariadb0 # on host1

अन्यथा, यदि बूटस्ट्रैप कंटेनर चुने हुए नोड पर मौजूद नहीं है, तो मान लें कि host2 पर, बूटस्ट्रैप कंटेनर कमांड चलाएँ और मौजूदा mariadb2 के वॉल्यूम को मैप करें। हम mariadb0 को host2 पर कंटेनर नाम के रूप में उपयोग कर रहे हैं यह इंगित करने के लिए कि यह एक बूटस्ट्रैप कंटेनर है:

$ 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" \
        --volume /containers/mariadb2/datadir:/var/lib/mysql \
        --volume /containers/mariadb2/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

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

• --env MYSQL_USER=proxysql
• --env MYSQL_PASSWORD=proxysqlpassword

फिर, शेष मारियाडीबी कंटेनर शुरू करें, बूटस्ट्रैप कंटेनर को हटा दें और बूटस्ट्रैप्ड होस्ट पर मौजूदा मारियाडीबी कंटेनर शुरू करें। मूल रूप से आदेशों का क्रम होगा:

$ docker start mariadb1 # on host1
$ docker start mariadb3 # on host3
$ docker stop mariadb0 # on host2
$ docker start mariadb2 # on host2

इस बिंदु पर, क्लस्टर प्रारंभ हो गया है और पूरी क्षमता से चल रहा है।

संसाधन नियंत्रण

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

मेमोरी आवंटन को सीमित करने और हमारे डेटाबेस कंटेनर में फ़ाइल डिस्क्रिप्टर की सीमा बढ़ाने के लिए, कोई --memory जोड़ देगा , --स्मृति-स्वैप और --ulimit "डॉकर रन" कमांड में पैरामीटर:

$ docker kill -s 15 mariadb1
$ docker rm -f mariadb1
$ docker run -d \
        --name mariadb1 \
        --hostname mariadb1.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --memory 16g \
        --memory-swap 16g \
        --ulimit nofile:16000:16000 \
        --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

ध्यान दें कि यदि --स्मृति-स्वैप --स्मृति . के समान मान पर सेट है , और --स्मृति एक सकारात्मक पूर्णांक पर सेट है, तो कंटेनर के पास स्वैप तक पहुंच नहीं होगी। अगर --स्मृति-स्वैप सेट नहीं है, कंटेनर स्वैप डिफ़ॉल्ट रूप से --स्मृति . होगा 2 से गुणा करें। यदि --स्मृति और --स्मृति-स्वैप समान मान पर सेट हैं, यह कंटेनरों को किसी भी स्वैप का उपयोग करने से रोकेगा। ऐसा इसलिए है क्योंकि --स्मृति-स्वैप संयुक्त मेमोरी और स्वैप की मात्रा है जिसका उपयोग किया जा सकता है, जबकि --memory केवल भौतिक स्मृति की मात्रा है जिसका उपयोग किया जा सकता है।

मेमोरी और सीपीयू जैसे कुछ कंटेनर संसाधनों को "डॉकर अपडेट" कमांड के माध्यम से गतिशील रूप से नियंत्रित किया जा सकता है, जैसा कि कंटेनर mariadb1 की मेमोरी को 32G ऑन-द-फ्लाई में अपग्रेड करने के लिए निम्नलिखित उदाहरण में दिखाया गया है:

$ docker update \
    --memory 32g \
    --memory-swap 32g \
    mariadb1

नए स्पेक्स के अनुरूप my.cnf को ट्यून करना न भूलें। कॉन्फ़िगरेशन प्रबंधन को अगले भाग में समझाया गया है।

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

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

$ vim /containers/mariadb3/conf.d/my.cnf

और फिर परिवर्तन लागू करने के लिए डेटाबेस कंटेनर को पुनरारंभ करें:

$ docker restart mariadb3

सत्यापित करें कि कंटेनर डॉक लॉग को देखकर प्रक्रिया शुरू करता है। यदि आप क्लस्टर-व्यापी परिवर्तन करना चाहते हैं, तो इस ऑपरेशन को एक बार में एक नोड पर करें।

बैकअप

तार्किक बैकअप लेना बहुत सीधा है क्योंकि मारियाडीबी छवि भी mysqldump बाइनरी के साथ आती है। आप बस mysqldump चलाने के लिए "docker exec" कमांड का उपयोग करते हैं और आउटपुट को होस्ट पथ से संबंधित फ़ाइल में भेजते हैं। निम्न आदेश mariadb2 पर mysqldump बैकअप करता है और इसे host2 के अंदर /backups/mariadb2 में सहेजता है:

$ docker exec -it mariadb2 mysqldump -uroot -p --single-transaction > /backups/mariadb2/dump.sql

Percona Xtrabackup या MariaDB बैकअप जैसे बाइनरी बैकअप को सीधे MariaDB डेटा निर्देशिका तक पहुँचने की प्रक्रिया की आवश्यकता होती है। आपको या तो इस उपकरण को कंटेनर के अंदर, या मशीन होस्ट के माध्यम से स्थापित करना होगा या इस उद्देश्य के लिए एक समर्पित छवि का उपयोग करना होगा जैसे "पेरकोनालाब/पेरकोना-एक्सट्राबैकअप" छवि बैकअप बनाने के लिए और इसे डॉकर होस्ट पर/tmp/बैकअप के अंदर संग्रहीत किया जाता है:

$ docker run --rm -it \
    -v /containers/mariadb2/datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --backup --host=mariadb2 --user=root --password=mypassword

आप कंटेनर को innodb_fast_shutdown . से भी रोक सकते हैं 0 पर सेट करें और डेटादिर वॉल्यूम को भौतिक होस्ट में किसी अन्य स्थान पर कॉपी करें:

$ docker exec -it mariadb2 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'
$ docker kill -s 15 mariadb2
$ cp -Rf /containers/mariadb2/datadir /backups/mariadb2/datadir_copied
$ docker start mariadb2

पुनर्स्थापित करें

Mysqldump के लिए पुनर्स्थापित करना बहुत सरल है। आप भौतिक होस्ट से बस स्टड को कंटेनर में पुनर्निर्देशित कर सकते हैं:

$ docker exec -it mariadb2 mysql -uroot -p < /backups/mariadb2/dump.sql

आप इस "docker exec" कमांड का उपयोग करने के बजाय उचित होस्टनाम और पोर्ट वैल्यू के साथ दूरस्थ रूप से मानक mysql क्लाइंट कमांड लाइन का उपयोग कर सकते हैं:

$ mysql -uroot -p -h127.0.0.1 -P3306 < /backups/mariadb2/dump.sql

Percona Xtrabackup और MariaDB बैकअप के लिए, हमें पहले से बैकअप तैयार करना होगा। यह बैकअप को उस समय तक आगे ले जाएगा जब बैकअप समाप्त हो गया था। मान लें कि हमारी Xtrabackup फ़ाइलें डॉकर होस्ट के /tmp/backup के अंतर्गत स्थित हैं, इसे तैयार करने के लिए, बस:

$ docker run --rm -it \
    -v mysql-datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --prepare --target-dir /xtrabackup_backupfiles

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

$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /tmp/backup:/var/lib/mysql \
    mariadb:10.2.15

यदि आपने स्टॉप और कॉपी दृष्टिकोण का उपयोग करके बैकअप किया है, तो आप बस डेटादिर को डुप्लिकेट कर सकते हैं और डुप्लिकेट निर्देशिका का उपयोग वॉल्यूम मैप्स के रूप में मारियाडीबी डेटादिर को दूसरे कंटेनर पर चलाने के लिए कर सकते हैं। मान लें कि बैकअप को /backups/mariadb2/datadir_copied के तहत कॉपी किया गया था, हम चलाकर एक नया कंटेनर चला सकते हैं:

$ mkdir -p /containers/mariadb-restored/datadir
$ cp -Rf /backups/mariadb2/datadir_copied /containers/mariadb-restored/datadir
$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /containers/mariadb-restored/datadir:/var/lib/mysql \
    mariadb:10.2.15

MYSQL_ROOT_PASSWORD को उस विशेष बैकअप के लिए वास्तविक रूट पासवर्ड से मेल खाना चाहिए।

डेटाबेस संस्करण अपग्रेड

अपग्रेड दो प्रकार के होते हैं - इन-प्लेस अपग्रेड या लॉजिकल अपग्रेड।

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

तार्किक उन्नयन में एक तार्किक बैकअप उपयोगिता जैसे कि mysqldump का उपयोग करके वर्तमान संस्करण से SQL का निर्यात करना, उन्नत संस्करण बायनेरिज़ के साथ नया कंटेनर चलाना और फिर SQL को नए MySQL/MariaDB संस्करण में लागू करना शामिल है। यह पिछले अनुभाग में वर्णित बैकअप और पुनर्स्थापना दृष्टिकोण के समान है।

फिर भी, किसी भी विनाशकारी संचालन को करने से पहले हमेशा अपने डेटाबेस का बैकअप लेना एक अच्छा तरीका है। वर्तमान छवि से अपग्रेड करते समय निम्न चरणों की आवश्यकता होती है, मारियाडीबी 10.1.33 दूसरे प्रमुख संस्करण में, मारियाडीबी 10.2.15 mariadb3 पर होस्ट3 पर रहता है:

0. डेटाबेस का बैकअप लें। यह भौतिक या तार्किक बैकअप से कोई फर्क नहीं पड़ता लेकिन बाद में mysqldump का उपयोग करने की अनुशंसा की जाती है।

1. नवीनतम छवि डाउनलोड करें जिसे हम अपग्रेड करना चाहते हैं:

   $ docker pull mariadb:10.2.15

2. हमारे डेटाबेस कंटेनर के लिए innodb_fast_shutdown को 0 पर सेट करें:

   $ docker exec -it mariadb3 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'

3. डेटाबेस कंटेनर को ग्रेसफुल शट डाउन करें:

   $ docker kill --signal=TERM mariadb3

4. हमारे डेटाबेस कंटेनर के लिए नई छवि के साथ एक नया कंटेनर बनाएं। नए कंटेनर नाम का उपयोग करने के अलावा बाकी के मापदंडों को बरकरार रखें (अन्यथा यह विरोध करेगा):

   $ docker run -d \
           --name mariadb3-new \
           --hostname mariadb3.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/mariadb3/datadir:/var/lib/mysql \
           --volume /containers/mariadb3/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=mariadb3.weave.local

5. mysql_upgrad स्क्रिप्ट चलाएँ:

   $ docker exec -it mariadb3-new mysql_upgrade -uroot -p

6. यदि कोई त्रुटि नहीं हुई, तो पुराने कंटेनर को हटा दें, mariadb3 (नया है mariadb3-new):

   $ docker rm -f mariadb3

7. अन्यथा, यदि अपग्रेड प्रक्रिया बीच में विफल हो जाती है, तो हम पिछले कंटेनर पर वापस आ सकते हैं:

   $ docker stop mariadb3-new
   $ docker start mariadb3

मेजर वर्जन अपग्रेड को माइनर वर्जन अपग्रेड के समान ही किया जा सकता है, सिवाय इसके कि आपको यह ध्यान रखना होगा कि MySQL/MariaDB केवल पिछले वर्जन से बड़े अपग्रेड का समर्थन करता है। यदि आप MariaDB 10.0 पर हैं और 10.2 में अपग्रेड करना चाहते हैं, तो आपको पहले MariaDB 10.1 में अपग्रेड करना होगा, उसके बाद एक और अपग्रेड चरण MariaDB 10.2 में करना होगा।

प्रमुख संस्करणों के बीच शुरू किए जा रहे और बहिष्कृत किए जा रहे कॉन्फ़िगरेशन परिवर्तनों पर ध्यान दें।

विफलता

गैलेरा में, सभी नोड मास्टर हैं और समान भूमिका निभाते हैं। तस्वीर में प्रॉक्सीएसक्यूएल के साथ, इस गेटवे से गुजरने वाले कनेक्शन स्वचालित रूप से विफल हो जाएंगे जब तक कि गैलेरा क्लस्टर के लिए एक प्राथमिक घटक चल रहा हो (यानी, अधिकांश नोड्स ऊपर हैं)। यदि एक डेटाबेस नोड नीचे चला जाता है तो एप्लिकेशन को कोई अंतर नहीं दिखाई देगा क्योंकि ProxySQL कनेक्शन को अन्य उपलब्ध नोड्स पर रीडायरेक्ट करेगा।

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

• स्थिति wsrep_local_state_comment समन्‍वयित है (स्थिति "डिसिंक/दाता" भी संभव है, केवल तभी जब wsrep_sst_method xtrabackup, xtrabackup-v2 या मारियाबैकअप है)।
• स्थिति wsrep_cluster_status प्राथमिक है।

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

स्केलिंग आउट

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

होस्ट3 पर स्केल आउट करने के लिए निम्न कमांड चलाएँ:

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

एक बार कंटेनर बन जाने के बाद, यह क्लस्टर में शामिल हो जाएगा और SST करेगा। इसे पोर्ट 3307 पर बाहरी रूप से या वीव नेटवर्क के बाहर, या पोर्ट 3306 होस्ट के भीतर या वीव नेटवर्क के भीतर एक्सेस किया जा सकता है। अब mariadb0.weave.local को क्लस्टर पते में शामिल करना आवश्यक नहीं है। एक बार क्लस्टर का विस्तार हो जाने के बाद, हमें नए मारियाडीबी कंटेनर को प्रॉक्सीएसक्यूएल लोड बैलेंसिंग सेट में व्यवस्थापक कंसोल के माध्यम से जोड़ना होगा:

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (10,'mariadb4.weave.local',3306);
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (20,'mariadb4.weave.local',3306);
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

उपरोक्त आदेशों को दूसरे ProxySQL उदाहरण पर दोहराएं।

अंत में अंतिम चरण के लिए, (यदि आप पहले से ही ProxySQL में "SAVE .. TO DISK" स्टेटमेंट चलाते हैं तो आप इस भाग को छोड़ सकते हैं), निम्न पंक्ति को प्रॉक्सीएसक्यूएल में जोड़ें। /पी>

$ vim /containers/proxysql1/proxysql.cnf # host1
$ vim /containers/proxysql2/proxysql.cnf # host2

और mysql_server निर्देश के तहत mariadb4 संबंधित पंक्तियों को संलग्न करें:

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="mariadb4.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 },
        { address="mariadb4.weave.local" , port=3306 , hostgroup=20, max_connections=100 }
)

फ़ाइल सहेजें और हमें अगले कंटेनर पुनरारंभ पर अच्छा होना चाहिए।

कम करना

स्केल डाउन करने के लिए, बस कंटेनर को इनायत से बंद कर देता है। सबसे अच्छा आदेश होगा:

$ docker kill -s 15 mariadb4
$ docker rm -f mariadb4

याद रखें, अगर डेटाबेस नोड ने क्लस्टर को अनजाने में छोड़ दिया, तो यह स्केलिंग का हिस्सा नहीं था और कोरम गणना को प्रभावित करेगा।

ProxySQL से कंटेनर को निकालने के लिए, दोनों ProxySQL कंटेनरों पर निम्न कमांड चलाएँ। उदाहरण के लिए, proxysql1 पर:

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> DELETE FROM mysql_servers WHERE hostname="mariadb4.weave.local";
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

फिर आप या तो proxysql.cnf के अंदर संबंधित प्रविष्टि को हटा सकते हैं या इसे ऐसे ही छोड़ सकते हैं। वैसे भी ProxySQL के दृष्टिकोण से इसे ऑफ़लाइन के रूप में पहचाना जाएगा।

सारांश

डॉकर के साथ, MySQL या MariaDB सर्वर को संभालने के पारंपरिक तरीके से चीजें थोड़ी अलग हो जाती हैं। गैलेरा क्लस्टर जैसी स्टेटफुल सेवाओं को संभालना स्टेटलेस एप्लिकेशन जितना आसान नहीं है, और इसके लिए उचित परीक्षण और योजना की आवश्यकता होती है।

इस विषय पर अपने अगले ब्लॉग में, हम बिना किसी ऑर्केस्ट्रेशन टूल के डॉकर पर गैलेरा क्लस्टर चलाने के पेशेवरों और विपक्षों का मूल्यांकन करेंगे।