MaxScale का उपयोग करके एक इंटरमीडिएट MySQL या MariaDB मास्टर को बिनलॉग सर्वर से कैसे बदलें

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

प्रतिकृति कार्यभार वितरित करने के लिए मध्यवर्ती मास्टर पर बिनलॉग सर्वर होने के कुछ लाभ हैं:

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

इस ब्लॉग पोस्ट में, हम यह देखने जा रहे हैं कि बेहतर मापनीयता और प्रदर्शन के लिए मैक्सस्केल पर चलने वाले बिनलॉग सर्वर के साथ एक मध्यवर्ती मास्टर (एक प्रतिकृति श्रृंखला में अन्य दासों के लिए एक दास होस्ट रिले) को कैसे बदला जाए ।

आर्किटेक्चर

हमारे पास मूल रूप से 4-नोड MariaDB v10.4 प्रतिकृति सेटअप है जिसमें एक MaxScale v2.3 है जो आने वाले प्रश्नों को वितरित करने के लिए प्रतिकृति के शीर्ष पर बैठा है। केवल एक दास एक मास्टर (मध्यवर्ती मास्टर) से जुड़ा है और अन्य दास मध्यवर्ती मास्टर से दोहराए गए कार्यभार को पढ़ने के लिए दोहराते हैं, जैसा कि निम्नलिखित आरेख में दिखाया गया है।

हम उपरोक्त टोपोलॉजी को इसमें बदलने जा रहे हैं:

मूल रूप से, हम मध्यवर्ती मास्टर भूमिका को हटाने जा रहे हैं और इसे प्रतिस्थापित करने जा रहे हैं मैक्सस्केल पर चलने वाला एक बिनलॉग सर्वर। मध्यवर्ती मास्टर को अन्य दास मेजबानों की तरह ही एक मानक दास में बदल दिया जाएगा। बिनलॉग सेवा मैक्सस्केल होस्ट पर पोर्ट 5306 पर सुन रही होगी। यह वह बंदरगाह है जिससे सभी दास बाद में प्रतिकृति के लिए कनेक्ट होंगे।

MaxScale को बिनलॉग सर्वर के रूप में कॉन्फ़िगर करना

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

शुरू करने से पहले, आइए मौजूदा मैक्सस्केल कॉन्फ़िगरेशन को टेक्स्ट फ़ाइल में निर्यात करें बैकअप के लिए। MaxScale के पास इस उद्देश्य के लिए --export-config नामक एक ध्वज है, लेकिन इसे maxscale उपयोगकर्ता के रूप में निष्पादित किया जाना चाहिए। इस प्रकार, निर्यात करने का आदेश है:

$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscale

MariaDB मास्टर पर, MaxScale द्वारा उपयोग किए जाने के लिए 'maxscale_slave' नामक एक प्रतिकृति स्लेव उपयोगकर्ता बनाएं और इसे निम्नलिखित विशेषाधिकारों के साथ असाइन करें:

$ mysql -uroot -p -h192.168.0.91 -P3306
MariaDB> CREATE USER 'maxscale_slave'@'%' IDENTIFIED BY 'BtF2d2Kc8H';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.roles_mapping TO 'maxscale_slave'@'%';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale_slave'@'%';
MariaDB> GRANT REPLICATION SLAVE ON *.* TO 'maxscale_slave'@'%';

ClusterControl उपयोगकर्ताओं के लिए, प्रबंधित करें -> स्कीमा और उपयोगकर्ता आवश्यक विशेषाधिकार बनाने के लिए जाएं।

कॉन्फ़िगरेशन के साथ आगे बढ़ने से पहले, हमारे बैकएंड सर्वर की वर्तमान स्थिति और टोपोलॉजी की समीक्षा करना महत्वपूर्ण है:

$ maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬──────────────────────────────┬───────────┐
│ Server │ Address      │ Port │ Connections │ State                        │ GTID      │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_757 │ 192.168.0.90 │ 3306 │ 0           │ Master, Running              │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_758 │ 192.168.0.91 │ 3306 │ 0           │ Relay Master, Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_759 │ 192.168.0.92 │ 3306 │ 0           │ Slave, Running               │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_760 │ 192.168.0.93 │ 3306 │ 0           │ Slave, Running               │ 0-38001-8 │
└────────┴──────────────┴──────┴─────────────┴──────────────────────────────┴───────────┘

जैसा कि हम देख सकते हैं, वर्तमान मास्टर DB_757 (192.168.0.90) है। इस जानकारी पर ध्यान दें क्योंकि हम इस मास्टर से दोहराने के लिए बिनलॉग सर्वर को सेटअप करने जा रहे हैं।

MaxScale कॉन्फ़िगरेशन फ़ाइल को /etc/maxscale.cnf पर खोलें और निम्न पंक्तियाँ जोड़ें:

[replication-service]
type=service
router=binlogrouter
user=maxscale_slave
password=BtF2d2Kc8H
version_string=10.4.12-MariaDB-log
server_id=9999
master_id=9999
mariadb10_master_gtid=true
filestem=binlog
binlogdir=/var/lib/maxscale/binlogs
semisync=true # if semisync is enabled on the master

[binlog-server-listener]
type=listener
service=replication-service
protocol=MariaDBClient
port=5306
address=0.0.0.0

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

परिवर्तनों को लोड करने के लिए MaxScale को पुनरारंभ करें:

$ systemctl restart maxscale

सत्यापित करें कि binlog सेवा maxctrl के माध्यम से शुरू की गई है (राज्य कॉलम देखें):

$ maxctrl show service replication-service

सत्यापित करें कि मैक्सस्केल अब बिनलॉग सेवा के लिए एक नया पोर्ट सुन रहा है:

$ netstat -tulpn | grep maxscale
tcp        0 0 0.0.0.0:3306            0.0.0.0:* LISTEN   4850/maxscale
tcp        0 0 0.0.0.0:3307            0.0.0.0:* LISTEN   4850/maxscale
tcp        0 0 0.0.0.0:5306            0.0.0.0:* LISTEN   4850/maxscale
tcp        0 0 127.0.0.1:8989          0.0.0.0:* LISTEN   4850/maxscale

अब हम MaxScale और मास्टर के बीच एक प्रतिकृति लिंक स्थापित करने के लिए तैयार हैं।

बिनलॉग सर्वर को सक्रिय करना

MariaDB मास्टर सर्वर में लॉग इन करें और वर्तमान बिनलॉग फ़ाइल और स्थिति को पुनः प्राप्त करें:

MariaDB> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000005 |     4204 |              |                  |
+---------------+----------+--------------+------------------+

GTID मान प्राप्त करने के लिए BINLOG_GTID_POS फ़ंक्शन का उपयोग करें:

MariaDB> SELECT BINLOG_GTID_POS("binlog.000005", 4204);
+----------------------------------------+
| BINLOG_GTID_POS("binlog.000005", 4204) |
+----------------------------------------+
| 0-38001-31                             |
+----------------------------------------+

MaxScale सर्वर पर वापस, MariaDB क्लाइंट पैकेज स्थापित करें:

$ yum install -y mysql-client

पोर्ट 5306 पर binlog सर्वर श्रोता से maxscale_slave उपयोगकर्ता के रूप में कनेक्ट करें और निर्दिष्ट मास्टर के लिए एक प्रतिकृति लिंक स्थापित करें। मास्टर से प्राप्त GTID मान का उपयोग करें:

(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SET @@global.gtid_slave_pos = '0-38001-31';
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.90', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=3306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
                 Slave_IO_State: Binlog Dump
                  Master_Host: 192.168.0.90
                  Master_User: maxscale_slave
                  Master_Port: 3306
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
             Master_Server_Id: 38001
             Master_Info_File: /var/lib/maxscale/binlogs/master.ini
      Slave_SQL_Running_State: Slave running
                  Gtid_IO_Pos: 0-38001-31

ध्यान दें:उपरोक्त आउटपुट केवल महत्वपूर्ण पंक्तियों को दिखाने के लिए छोटा किया गया है।

दासों को बिनलॉग सर्वर की ओर इंगित करना

अब mariadb2 और mariadb3 (अंत दास) पर, MaxScale binlog सर्वर की ओर इशारा करते हुए मास्टर को बदलें। चूंकि हम सेमी-सिंक प्रतिकृति सक्षम के साथ चल रहे हैं, इसलिए हमें पहले उन्हें बंद करना होगा:

(mariadb2 & mariadb3)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
                Slave_IO_State: Waiting for master to send event
                   Master_Host: 192.168.0.95
                   Master_User: maxscale_slave
                   Master_Port: 5306
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
              Master_Server_Id: 9999
                    Using_Gtid: Slave_Pos
                   Gtid_IO_Pos: 0-38001-32
       Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

ध्यान दें:उपरोक्त आउटपुट केवल महत्वपूर्ण पंक्तियों को दिखाने के लिए छोटा किया गया है।

my.cnf के अंदर, हमें भविष्य में सेमी-सिंक को अक्षम करने के लिए निम्नलिखित पंक्तियों पर टिप्पणी करनी होगी:

#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ON

इस बिंदु पर, मध्यवर्ती मास्टर (mariadb1) अभी भी मास्टर (mariadb0) से नकल कर रहा है जबकि अन्य दास बिनलॉग सर्वर से नकल कर रहे हैं। हमारे वर्तमान टोपोलॉजी को नीचे दिए गए चित्र की तरह दिखाया जा सकता है:

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

(mariadb1)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
                Slave_IO_State: Waiting for master to send event
                   Master_Host: 192.168.0.95
                   Master_User: maxscale_slave
                   Master_Port: 5306
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
              Master_Server_Id: 9999
                    Using_Gtid: Slave_Pos
                   Gtid_IO_Pos: 0-38001-32

नोट:उपरोक्त आउटपुट केवल महत्वपूर्ण पंक्तियों को दिखाने के लिए छोटा किया गया है।

my.cnf में भी सेमी-सिंक प्रतिकृति को अक्षम करना न भूलें:

#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ON

हम यह सत्यापित कर सकते हैं कि binlog राउटर सेवा में अब maxctrl CLI के माध्यम से अधिक कनेक्शन हैं:

$ maxctrl list services
┌─────────────────────┬────────────────┬─────────────┬───────────────────┬───────────────────────────────────┐
│ Service             │ Router         │ Connections │ Total Connections │ Servers                           │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rw-service          │ readwritesplit │ 1           │ 1                 │ DB_757, DB_758, DB_759, DB_760    │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rr-service          │ readconnroute  │ 1           │ 1                 │ DB_757, DB_758, DB_759, DB_760    │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ replication-service │ binlogrouter   │ 4           │ 51                │ binlog_router_master_host, DB_757 │
└─────────────────────┴────────────────┴─────────────┴───────────────────┴───────────────────────────────────┘

साथ ही, मैक्सस्केल बिनलॉग सर्वर के अंदर सामान्य प्रतिकृति व्यवस्थापन कमांड का उपयोग किया जा सकता है, उदाहरण के लिए, हम इस कमांड का उपयोग करके कनेक्टेड स्लेव होस्ट को सत्यापित कर सकते हैं:

(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SHOW SLAVE HOSTS;
+-----------+--------------+------+-----------+------------+
| Server_id | Host         | Port | Master_id | Slave_UUID |
+-----------+--------------+------+-----------+------------+
| 38003     | 192.168.0.92 | 3306 | 9999      |            |
| 38002     | 192.168.0.91 | 3306 | 9999      |            |
| 38004     | 192.168.0.93 | 3306 | 9999      |            |
+-----------+--------------+------+-----------+------------+

इस समय, हमारी टोपोलॉजी वैसी दिख रही है जैसी हमने उम्मीद की थी:

इंटरमीडिएट मास्टर सेटअप से बिनलॉग सर्वर सेटअप में हमारा माइग्रेशन अब पूरा हो गया है।