मारियाडीबी गैलेरा क्लस्टर्स के बीच एसिंक्रोनस प्रतिकृति कैसे सेटअप करें

गैलेरा क्लस्टर, इसकी (वस्तुतः) तुल्यकालिक प्रतिकृति के साथ, आमतौर पर कई अलग-अलग प्रकार के वातावरण में उपयोग किया जाता है। नए नोड्स जोड़कर इसे स्केल करना कठिन नहीं है (या जब आप ClusterControl का उपयोग करते हैं तो बस कुछ ही क्लिक होते हैं)।

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

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

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

अंत में, प्रवास ही। फिर से, जो हमने पहले कहा था, भले ही गैलेरा नोड्स के पुराने और नए संस्करणों को एक ही क्लस्टर में मिलाना संभव हो, यह ऐसा करने का सबसे सुरक्षित तरीका नहीं है।

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

इस ब्लॉग पोस्ट में हम चर्चा करेंगे कि मारियाडीबी गैलेरा क्लस्टर के बीच एसिंक्रोनस प्रतिकृति को तैनात करने के लिए क्या कदम हैं।

मारियाडीबी गैलेरा क्लस्टर्स के बीच एसिंक्रोनस प्रतिकृति को कैसे कॉन्फ़िगर करें?

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

स्रोत क्लस्टर को कॉन्फ़िगर करना

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

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

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

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

1. MariaDB रिपॉजिटरी कॉन्फ़िगर करें
2. मारियाडीबी 10.3 पैकेज स्थापित करें
3. क्लस्टर बनाने के लिए नोड्स कॉन्फ़िगर करें

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

सबसे पहले, हमें एक निर्देशिका बनानी होगी जहां हम बैकअप स्टोर करेंगे:

mkdir /mnt/mariabackup

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

mariabackup --backup --user=root --password=pass --target-dir=/mnt/mariabackup/

इसके बाद, हमें बैकअप फ़ाइलों को दूसरे क्लस्टर में पहले नोड में कॉपी करना होगा। हमने उसके लिए scp का उपयोग किया है, आप जो चाहें उपयोग कर सकते हैं - rsync, netcat, कुछ भी जो काम करेगा।

scp -r /mnt/mariabackup/* 10.0.0.104:/root/mariabackup/

बैकअप कॉपी हो जाने के बाद, हमें लॉग फाइल्स लगाकर इसे तैयार करना होगा:

mariabackup --prepare --target-dir=/root/mariabackup/
mariabackup based on MariaDB server 10.3.16-MariaDB debian-linux-gnu (x86_64)
[00] 2019-06-24 08:35:39 cd to /root/mariabackup/
[00] 2019-06-24 08:35:39 This target seems to be not prepared yet.
[00] 2019-06-24 08:35:39 mariabackup: using the following InnoDB configuration for recovery:
[00] 2019-06-24 08:35:39 innodb_data_home_dir = .
[00] 2019-06-24 08:35:39 innodb_data_file_path = ibdata1:100M:autoextend
[00] 2019-06-24 08:35:39 innodb_log_group_home_dir = .
[00] 2019-06-24 08:35:39 InnoDB: Using Linux native AIO
[00] 2019-06-24 08:35:39 Starting InnoDB instance for recovery.
[00] 2019-06-24 08:35:39 mariabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
2019-06-24  8:35:39 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-06-24  8:35:39 0 [Note] InnoDB: Uses event mutexes
2019-06-24  8:35:39 0 [Note] InnoDB: Compressed tables use zlib 1.2.8
2019-06-24  8:35:39 0 [Note] InnoDB: Number of pools: 1
2019-06-24  8:35:39 0 [Note] InnoDB: Using SSE2 crc32 instructions
2019-06-24  8:35:39 0 [Note] InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
2019-06-24  8:35:39 0 [Note] InnoDB: Completed initialization of buffer pool
2019-06-24  8:35:39 0 [Note] InnoDB: page_cleaner coordinator priority: -20
2019-06-24  8:35:39 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=3448619491
2019-06-24  8:35:40 0 [Note] InnoDB: Starting final batch to recover 759 pages from redo log.
2019-06-24  8:35:40 0 [Note] InnoDB: Last binlog file '/var/lib/mysql-binlog/binlog.000003', position 865364970
[00] 2019-06-24 08:35:40 Last binlog file /var/lib/mysql-binlog/binlog.000003, position 865364970
[00] 2019-06-24 08:35:40 mariabackup: Recovered WSREP position: e79a3494-964f-11e9-8a5c-53809a3c5017:25740

[00] 2019-06-24 08:35:41 completed OK!

किसी भी त्रुटि के मामले में आपको बैकअप को फिर से निष्पादित करना पड़ सकता है। अगर सब कुछ ठीक रहा, तो हम पुराने डेटा को हटा सकते हैं और इसे बैकअप जानकारी से बदल सकते हैं

rm -rf /var/lib/mysql/*
mariabackup --copy-back --target-dir=/root/mariabackup/
…
[01] 2019-06-24 08:37:06 Copying ./sbtest/sbtest10.frm to /var/lib/mysql/sbtest/sbtest10.frm
[01] 2019-06-24 08:37:06         ...done
[00] 2019-06-24 08:37:06 completed OK!

हम फ़ाइलों का सही स्वामी भी सेट करना चाहते हैं:

chown -R mysql.mysql /var/lib/mysql/

हम प्रतिकृति को सुसंगत रखने के लिए GTID पर निर्भर रहेंगे, इसलिए हमें यह देखने की आवश्यकता है कि इस बैकअप में अंतिम बार लागू GTID क्या था। वह जानकारी xtrabackup_info फ़ाइल में मिल सकती है जो बैकअप का हिस्सा है:

[email protected]:~/mariabackup# cat /var/lib/mysql/xtrabackup_info | grep binlog_pos
binlog_pos = filename 'binlog.000003', position '865364970', GTID of the last change '9999-1002-23012'

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

प्रतिकृति को स्थापित करने से पहले हमें जो आखिरी काम करना होगा वह एक उपयोगकर्ता बनाना है जिसका उपयोग हम प्रतिकृति चलाने के लिए करेंगे:

MariaDB [(none)]> CREATE USER 'repuser'@'10.0.0.104' IDENTIFIED BY 'reppass';
Query OK, 0 rows affected (0.077 sec)

MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.*  TO 'repuser'@'10.0.0.104';
Query OK, 0 rows affected (0.012 sec)

हमें बस इतना ही चाहिए। अब, हम दूसरे क्लस्टर में पहला नोड शुरू कर सकते हैं, हमारा होने वाला गुलाम:

galera_new_cluster

एक बार यह शुरू हो जाने के बाद, हम MySQL सीएलआई में प्रवेश कर सकते हैं और इसे दास बनने के लिए कॉन्फ़िगर कर सकते हैं, जीआईटीडी स्थिति का उपयोग करके हमने कुछ कदम पहले पाया:

mysql -ppass

MariaDB [(none)]> SET GLOBAL gtid_slave_pos = '9999-1002-23012';
Query OK, 0 rows affected (0.026 sec)

एक बार ऐसा करने के बाद, हम अंत में प्रतिकृति सेट कर सकते हैं और इसे शुरू कर सकते हैं:

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='10.0.0.101', MASTER_PORT=3306, MASTER_USER='repuser', MASTER_PASSWORD='reppass', MASTER_USE_GTID=slave_pos;
Query OK, 0 rows affected (0.016 sec)

MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.010 sec)

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

MariaDB [(none)]> show global status like 'wsrep_last_committed';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| wsrep_last_committed | 106   |
+----------------------+-------+
1 row in set (0.001 sec)

MariaDB [(none)]> show global status like 'wsrep_last_committed';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| wsrep_last_committed | 114   |
+----------------------+-------+
1 row in set (0.001 sec)

ClusterControl का उपयोग करके MariaDB गैलेरा क्लस्टर्स के बीच अतुल्यकालिक प्रतिकृति को कैसे कॉन्फ़िगर करें?

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

हमने पहले जो दिखाया था, उससे हम यह निष्कर्ष निकाल सकते हैं कि दो गैलेरा समूहों के बीच प्रतिकृति स्थापित करते समय ये सामान्य कदम हैं:

1. एक नया गैलेरा क्लस्टर तैनात करें
2. पुराने से डेटा का उपयोग करके नए क्लस्टर का प्रावधान करें
3. नया क्लस्टर कॉन्फ़िगर करें (SST कॉन्फ़िगरेशन, बाइनरी लॉग)
4. पुराने और नए क्लस्टर के बीच प्रतिकृति सेट करें

पहले तीन बिंदु कुछ ऐसे हैं जिन्हें आप अभी भी ClusterControl का उपयोग करके आसानी से कर सकते हैं। हम आपको यह दिखाने जा रहे हैं कि यह कैसे करना है।

ClusterControl का उपयोग करके एक नया MariaDB गैलेरा क्लस्टर परिनियोजित और प्रावधान करें

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

तीन चरणों में हमने बैकअप लेने के लिए नोड को चुना। यह नोड (10.0.0.101) मास्टर बन जाएगा। इसमें बाइनरी लॉग सक्षम होना चाहिए। हमारे मामले में सभी नोड्स में बिनलॉग सक्षम है, लेकिन यदि उनके पास क्लस्टर कंट्रोल से इसे सक्षम करना बहुत आसान नहीं है - तो हम बाद में चरणों को दिखाएंगे, जब हम इसे दूसरे क्लस्टर के लिए करेंगे।

एक बार बैकअप पूरा हो जाने पर, यह सूची में दिखाई देने लगेगा। फिर हम आगे बढ़ सकते हैं और इसे पुनर्स्थापित कर सकते हैं:

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

फिर हम बैकअप से क्लस्टर बनाने का विकल्प चुनते हैं। यह एक और संवाद खोलता है:

यह एक पुष्टि है कि किस बैकअप का उपयोग किया जाएगा, बैकअप किस होस्ट से लिया गया था, इसे बनाने के लिए किस विधि का उपयोग किया गया था और कुछ मेटाडेटा यह सत्यापित करने में मदद करता है कि बैकअप ध्वनि दिखता है या नहीं।

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

यह सब तैनाती और प्रावधान के संबंध में है। ClusterControl नया क्लस्टर स्थापित करेगा और यह पुराने क्लस्टर के डेटा का उपयोग करके इसका प्रावधान करेगा।

हम गतिविधि टैब में प्रगति की निगरानी कर सकते हैं। एक बार पूरा हो जाने पर, दूसरा क्लस्टर क्लस्टर नियंत्रण में क्लस्टर सूची में दिखाई देगा।

ClusterControl का उपयोग करके नए क्लस्टर का पुन:कॉन्फ़िगरेशन

अब, हमें क्लस्टर को फिर से कॉन्फ़िगर करना होगा - हम बाइनरी लॉग्स को सक्षम करेंगे। मैनुअल प्रक्रिया में हमें wsrep_sst_auth कॉन्फिगरेशन में बदलाव करना पड़ा और कॉन्फिगरेशन के [mysqldump] और [xtrabackup] सेक्शन में कॉन्फिगरेशन एंट्री भी करनी पड़ी। उन सेटिंग्स को secrets-backup.cnf फ़ाइल में पाया जा सकता है। इस बार इसकी आवश्यकता नहीं है क्योंकि ClusterControl ने क्लस्टर के लिए नए पासवर्ड जेनरेट किए और फाइलों को सही तरीके से कॉन्फ़िगर किया। क्या ध्यान रखना महत्वपूर्ण है, हालांकि, क्या आपको मूल क्लस्टर में 'बैकअपयूसर'@'127.0.0.1' उपयोगकर्ता का पासवर्ड बदलना चाहिए, आपको दूसरे क्लस्टर में भी कॉन्फ़िगरेशन परिवर्तन करना होगा ताकि यह प्रतिबिंबित हो सके कि पहला क्लस्टर दूसरे क्लस्टर को दोहराएगा।

नोड्स अनुभाग से बाइनरी लॉग को सक्षम किया जा सकता है। आपको नोड द्वारा नोड चुनना होगा और "बाइनरी लॉगिंग सक्षम करें" कार्य चलाना होगा। आपको एक संवाद के साथ प्रस्तुत किया जाएगा:

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

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

यदि हमारे पास पहले से निर्मित प्रतिकृति उपयोगकर्ता नहीं है, तो हमें वह करना होगा। पहले क्लस्टर में हमें मैनेज -> स्कीमा और यूजर्स पर जाना होगा:

दाईं ओर हमारे पास एक नया उपयोगकर्ता बनाने का विकल्प है:

यह प्रतिकृति सेट करने के लिए आवश्यक कॉन्फ़िगरेशन को समाप्त करता है।

ClusterControl का उपयोग करके समूहों के बीच प्रतिकृति सेट करना

जैसा कि हमने कहा, हम इस हिस्से को स्वचालित करने पर काम कर रहे हैं। वर्तमान में इसे मैन्युअल रूप से किया जाना है। जैसा कि आपको याद होगा, हमें अपने बैकअप की GITD स्थिति की आवश्यकता है और फिर MySQL CLI का उपयोग करके युगल कमांड चलाएं। बैकअप में GTID डेटा उपलब्ध होता है। ClusterControl xbstream/mbstream का उपयोग करके बैकअप बनाता है और इसे बाद में संपीड़ित करता है। हमारा बैकअप ClusterControl होस्ट पर स्टोर किया जाता है जहां हमारे पास mbstream बाइनरी तक पहुंच नहीं है। आप इसे स्थापित करने का प्रयास कर सकते हैं या आप बैकअप फ़ाइल को उस स्थान पर कॉपी कर सकते हैं, जहां ऐसी बाइनरी उपलब्ध है:

scp /root/backups/BACKUP-2/ backup-full-2019-06-24_144329.xbstream.gz 10.0.0.104:/root/mariabackup/

एक बार ऐसा करने के बाद, 10.0.0.104 को हम xtrabackup_info फ़ाइल की सामग्री की जांच करना चाहते हैं:

cd /root/mariabackup
zcat backup-full-2019-06-24_144329.xbstream.gz | mbstream -x
[email protected]:~/mariabackup# cat /root/mariabackup/xtrabackup_info | grep binlog_pos
binlog_pos = filename 'binlog.000007', position '379', GTID of the last change '9999-1002-846116'

अंत में, हम प्रतिकृति को कॉन्फ़िगर करते हैं और इसे शुरू करते हैं:

MariaDB [(none)]> SET GLOBAL gtid_slave_pos ='9999-1002-846116';
Query OK, 0 rows affected (0.024 sec)

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='10.0.0.101', MASTER_PORT=3306, MASTER_USER='repuser', MASTER_PASSWORD='reppass', MASTER_USE_GTID=slave_pos;
Query OK, 0 rows affected (0.024 sec)

MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.010 sec)

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