GTID के साथ MySQL 5.6 गैर-GTID से MySQL 5.7 में ऑनलाइन स्थानांतरण

इस ब्लॉग पोस्ट में, हम यह देखने जा रहे हैं कि MySQL 5.6 स्टैंडअलोन सेटअप से MySQL 5.7 पर चलने वाले एक नए प्रतिकृति सेट में ऑनलाइन माइग्रेशन कैसे करें, जिसे ClusterControl द्वारा परिनियोजित और प्रबंधित किया जाता है।

योजना MySQL 5.7 पर चलने वाले नए क्लस्टर से MySQL 5.6 (क्लस्टरकंट्रोल प्रावधान के बाहर) पर चलने वाले मास्टर के लिए एक प्रतिकृति लिंक स्थापित करने की है, जो बिना GTID का उपयोग करता है। MySQL एक प्रतिकृति श्रृंखला में GTID और गैर-GTID को मिलाने का समर्थन नहीं करता है। इसलिए हमें माइग्रेशन के दौरान गैर-GTID और GTID मोड के बीच स्विच करने के लिए कुछ तरकीबें करने की आवश्यकता है।

हमारी वास्तुकला और प्रवासन योजना को नीचे दिखाया जा सकता है:

सेटअप में निम्नलिखित प्रतिनिधित्व के साथ 4 सर्वर होते हैं:

mysql56a - Old Master - Oracle MySQL 5.6 बिना GTID के
गुलाम समूह:
- mysql57a - नया मास्टर - GTID के साथ Oracle MySQL 5.7
- mysql57b - न्यू स्लेव - Oracle MySQL 5.7 GTID के साथ
cc - ClusterControl Server - डेटाबेस नोड्स के लिए परिनियोजन/प्रबंधन/निगरानी सर्वर।

सभी MySQL 5.7 होस्ट डेबियन 10 (बस्टर) पर चल रहे हैं, जबकि MySQL 5.6 डेबियन 9 (स्ट्रेच) पर चल रहे हैं।

गुलाम क्लस्टर परिनियोजित करना

सबसे पहले, हम पुराने मास्टर से प्रतिकृति लिंक स्थापित करने से पहले दास क्लस्टर तैयार करते हैं। दास क्लस्टर का अंतिम कॉन्फ़िगरेशन GTID सक्षम के साथ MySQL 5.7 पर चल रहा होगा। ClusterControl सर्वर (cc) पर ClusterControl स्थापित करें:

$ wget https://severalnines.com/downloads/install-cc
$ chmod 755 install-cc
$ ./install-cc

इंस्टॉलेशन पूर्ण होने तक निर्देशों का पालन करें। फिर, पासवर्ड रहित SSH को ClusterControl से mysql57a और mysql57b पर सेट करें:

$ whoami
root
$ ssh-keygen -t rsa # press Enter on all prompts
$ ssh-copy-id [email protected] # enter the target host root password
$ ssh-copy-id [email protected] # enter the target host root password

फिर, ClusterControl UI में लॉग इन करें, प्रारंभिक फॉर्म भरें और ClusterControl -> Deploy -> MySQL प्रतिकृति अनुभाग पर जाएं और निम्नलिखित भरें:

फिर जारी रखें पर क्लिक करें और विक्रेता के रूप में Oracle चुनें, और प्रदाता के रूप में 5.7 चुनें संस्करण। फिर टोपोलॉजी सेक्शन में आगे बढ़ें और इसे नीचे के रूप में कॉन्फ़िगर करें:

तैनाती पूर्ण होने तक प्रतीक्षा करें और आपको नया क्लस्टर नीचे जैसा दिखाई देगा:

जीटीआईडी के साथ MySQL 5.7 पर चलने वाला हमारा स्लेव क्लस्टर अब तैयार है।

पुराने मास्टर को तैयार करना

वर्तमान मास्टर जिसे हम दोहराना चाहते हैं वह एक स्टैंडअलोन MySQL 5.6 (बाइनरी लॉग सक्षम, सर्वर-आईडी कॉन्फ़िगर किया गया, बिना GTID के) है और यह उत्पादन डेटाबेस की सेवा कर रहा है। इसलिए इस माइग्रेशन के लिए डाउनटाइम कोई विकल्प नहीं है। दूसरी ओर, ClusterControl नए MySQL 5.7 को GTID-सक्षम के साथ कॉन्फ़िगर करता है, जिसका अर्थ है कि हमें इस स्टैंडअलोन मास्टर से सही ढंग से दोहराने में सक्षम होने के लिए स्लेव क्लस्टर के अंदर GTID कार्यक्षमता को बंद करने की आवश्यकता है।

निम्नलिखित पंक्तियाँ [mysqld] निर्देश के तहत मास्टर /etc/mysql/mysql.conf.d/mysqld.cnf के लिए हमारे वर्तमान प्रतिकृति-संबंधित कॉन्फ़िगरेशन को दिखाती हैं:

server_id=1
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
relay_log=relay-bin
expire_logs_days=7
sync_binlog=1

सत्यापित करें कि MySQL सर्वर GTID के बिना बाइनरी लॉग बना रहा है:

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000007 |   734310 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+

1 row in set (0.00 sec)

गैर-GTID के लिए, Executed_Gtid_Set के खाली रहने की उम्मीद है। ध्यान दें कि ClusterControl द्वारा परिनियोजित हमारा नया MySQL 5.7 प्रतिकृति क्लस्टर GTID सक्षम के साथ कॉन्फ़िगर किया गया है।

1) mysql57a द्वारा उपयोग किए जाने के लिए एक प्रतिकृति उपयोगकर्ता बनाएं:

mysql> CREATE USER 'slave'@'192.168.10.31' IDENTIFIED BY 'slavepassword';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@192.168.10.31';

2) ClusterControl स्वचालित पुनर्प्राप्ति अक्षम करें। ClusterControl UI के अंतर्गत -> क्लस्टर चुनें -> सुनिश्चित करें कि ऑटो रिकवरी क्लस्टर और नोड बंद हैं (लाल पावर आइकन), जैसा कि नीचे स्क्रीनशॉट में दिखाया गया है:

हम नहीं चाहते कि क्लस्टर कंट्रोल इस प्रतिकृति कॉन्फ़िगरेशन के दौरान नोड को पुनर्प्राप्त करे।

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

$ mysqldump -u root -p --single-transaction --master-data=2 --all-databases > mysql56a-fullbackup.sql

ध्यान दें कि उपरोक्त कमांड --single-transaction के कारण किसी भी InnoDB टेबल को ब्लॉक नहीं करेगा। इसलिए यदि आपके पास MyISAM टेबल हैं, तो निरंतरता बनाए रखने के लिए बैकअप की अवधि के दौरान तालिकाओं को ब्लॉक कर दिया जाएगा।

4) बैकअप को mysql56a से mysql57a और mysql57b में कॉपी करें:

$ scp mysql56a-fullbackup.sql [email protected]:~
$ scp mysql56a-fullbackup.sql [email protected]:~

गुलाम समूह तैयार करना

इस चरण में, हम पुराने मास्टर, mysql56a से GTID के बिना प्रतिकृति शुरू करने के लिए स्लेव क्लस्टर को कॉन्फ़िगर करेंगे।

1) mysql57a और mysql57b के बीच प्रतिकृति को रोकें, ClusterControl द्वारा कॉन्फ़िगर किए गए सभी दास-संबंधित क्रेडेंशियल्स को हटा दें और mysql57b पर केवल पढ़ने के लिए अक्षम करें:

mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;

2) mysql57a पर GTID अक्षम करें:

mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF';
mysql> SET GLOBAL enforce_gtid_consistency = 'OFF';

3) mysql57b पर GTID अक्षम करें:

mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'OFF';
mysql> SET GLOBAL enforce_gtid_consistency = 'OFF';

4) mysql57a पर mysqldump बैकअप पुनर्स्थापित करें:

$ mysql -uroot -p < mysql56a-fullbackup.sql

5) mysql57b पर mysqldump बैकअप पुनर्स्थापित करें:

$ mysql -uroot -p < mysql56a-fullbackup.sql

6) mysql57a पर MySQL अपग्रेड स्क्रिप्ट चलाएँ (वर्तमान संस्करण में सभी तालिकाओं की जाँच और अद्यतन करने के लिए):

$ mysql_upgrade -uroot -p

7) MySQL अपग्रेड स्क्रिप्ट को mysql57b पर चलाएँ (वर्तमान संस्करण में सभी तालिकाओं की जाँच और अद्यतन करने के लिए):

$ mysql_upgrade -uroot -p

स्लेव क्लस्टर पर दोनों सर्वर अब पुराने मास्टर, mysql56a के डेटा स्नैपशॉट के साथ मंचित हैं, और अब दोहराने के लिए तैयार हैं।

गुलाम समूह के लिए प्रतिकृति सेट करना

1) mysql57a पर RESET MASTER का उपयोग करके बाइनरी लॉग को रीसेट करें, इसलिए हमें बाद में mysql57b पर बाइनरी फ़ाइल और लॉग पोजिशनिंग निर्दिष्ट करने की आवश्यकता नहीं है। साथ ही, हम उन सभी मौजूदा GTID संदर्भों को हटा देते हैं जिन्हें पहले कॉन्फ़िगर किया गया था:

mysql> RESET MASTER;
mysql> SET @@global.gtid_purged='';

2) mysql57a पर, बिनलॉग फ़ाइल और डंप फ़ाइल से स्थिति पुनर्प्राप्त करें, mysql56a-fullbackup.sql:

$ head -100 mysql56a-fullbackup.sql | grep LOG_POS
-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987;

3) पिछले चरण में प्राप्त सही MASTER_LOG_FILE और MASTER_LOG_POS मान निर्दिष्ट करके पुराने मास्टर, mysql56a से नए मास्टर mysql57a में प्रतिकृति स्लेव प्रारंभ करें। Mysql57a पर:

mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.22', MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=4677987;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

सुनिश्चित करें कि आपको निम्न पंक्तियां दिखाई दे रही हैं:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

आपको शायद तब तक इंतजार करना होगा जब तक mysql57a "Seconds_Behind_Master" की निगरानी करके और सुनिश्चित कर लें कि यह 0 हो जाता है।

4) इस बिंदु पर, mysql57a mysql56a से डेटा की नकल कर रहा है, जिसका अर्थ है कि ClusterControl द्वारा बनाए गए सभी उपयोगकर्ता अब सर्वर से गायब हैं (क्योंकि mysql57a अब mysql56a पर डेटा का अनुसरण कर रहा है)। ClusterControl को mysql57a से कनेक्ट करने में समस्या होगी और यह "डाउन" के रूप में दिखाई देगा। इसका मूल रूप से मतलब है कि ClusterControl MySQL सर्वर से कनेक्ट करने में असमर्थ है क्योंकि अनुदान गायब हैं। लापता उपयोगकर्ता हैं:

[email protected]
[email protected]'{एक विशेष क्लस्टर में सभी नोड्स}'
[email protected]'{ClusterControl host}'

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

अब, लापता उपयोगकर्ताओं को नए मास्टर, mysql57a पर फिर से बनाएँ:

a) बैकअप उपयोगकर्ता बनाएं (mysql57a पर /etc/mysql/secrets-backup.cnf से लिया गया पासवर्ड):

mysql> CREATE USER [email protected] IDENTIFIED BY '[email protected]!65%JlNB1z';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, SUPER, REPLICATION CLIENT ON *.* TO [email protected];

b) सभी DB होस्ट के लिए प्रतिकृति उपयोगकर्ता बनाएं (ClusterControl सर्वर पर /etc/cmon.d/cmon_X.cnf के अंदर repl_password चर से लिया गया पासवर्ड, जहां X स्लेव क्लस्टर की क्लस्टर आईडी है):

mysql> CREATE USER 'rpl_user'@'192.168.10.31' IDENTIFIED BY '68n61F+bdsW1}[email protected]}x5J';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rpl_user'@'192.168.10.31';
mysql> CREATE USER 'rpl_user'@'192.168.10.32' IDENTIFIED BY '68n61F+bdsW1}[email protected]}x5J';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rpl_user'@'192.168.10.32';

c) ClusterControl उपयोग के लिए दो cmon डेटाबेस उपयोगकर्ता (एक IP पते के लिए और एक होस्टनाम के लिए) बनाएँ (पासवर्ड mysql_password के अंदर /etc/cmon.d/cmon_X.cnf के अंदर ClusterControl सर्वर पर लिया गया है, जहाँ X स्लेव की क्लस्टर आईडी है। क्लस्टर):

mysql> CREATE USER [email protected]'192.168.10.19' IDENTIFIED BY 'My&Passw0rd90';
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'192.168.10.19' WITH GRANT OPTION;
mysql> CREATE USER [email protected]'cc.local' IDENTIFIED BY 'My&Passw0rd90';
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'cc.local' WITH GRANT OPTION;

5) इस समय, mysql57a को ClusterControl में हरा दिखना चाहिए। अब, हम mysql57a से mysql57b में एक प्रतिकृति लिंक सेट कर सकते हैं। Mysql57b पर:

mysql> RESET MASTER;
mysql> SET @@global.gtid_purged='';
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.31', MASTER_USER = 'rpl_user', MASTER_PASSWORD = '68n61F+bdsW1}[email protected]}x5J';
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

**हमें MASTER_LOG_FILE और MASTER_LOG_POS निर्दिष्ट करने की आवश्यकता नहीं है क्योंकि यह चरण #1 पर RESET MASTER के बाद हमेशा एक निश्चित प्रारंभिक स्थिति से शुरू होगा।

सुनिश्चित करें कि आप निम्न पंक्तियाँ देखते हैं:

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

प्रतिकृति स्थिति की निगरानी करें और सुनिश्चित करें कि mysql57b mysql57a के साथ बना रहता है, और mysql57a mysql56a के साथ बना रहता है। इसके बाद आपको आकस्मिक लिखने से बचाने के लिए mysql57b (और/या mysql57a) पर केवल-पढ़ने के लिए सक्षम करने की आवश्यकता हो सकती है।

mysql> SET GLOBAL super_read_only = 1;
mysql> SET GLOBAL read_only = 1;

ClusterControl UI से, आप अवलोकन अनुभाग के अंतर्गत वर्तमान स्थिति देखते हैं:

इस समय, नया मास्टर mysql57a, 192.168.10.31 से नकल कर रहा है पुराना स्टैंडअलोन होस्ट mysql56a, 192.168.10.22, जबकि नया दास mysql57b (केवल-पढ़ने के लिए) mysql57a, 192.168.10.31 से नकल कर रहा है। सभी नोड्स प्रतिकृति लैग 0 के साथ समन्वयित हैं।

वैकल्पिक रूप से, आप [mysqld] अनुभाग के अंतर्गत MySQL कॉन्फ़िगरेशन फ़ाइलों के अंदर निम्न पंक्तियों पर टिप्पणी कर सकते हैं:

#gtid_mode=ON
#enforce_gtid_consistency=1

स्लेव क्लस्टर पर GTID सक्षम करना

ध्यान दें कि MySQL 5.6 और बाद के संस्करण के लिए, ClusterControl गैर-GTID कार्यान्वयन का समर्थन नहीं करता है, जैसे कि इसके कुछ प्रबंधन सुविधाओं जैसे कि रीबिल्ड रेप्लिकेशन स्लेव और चेंज रेप्लिकेशन मास्टर। इसलिए, स्टैंडअलोन MySQL सर्वर (mysql56a) से कट-ऑफ समय (जब आप नए क्लस्टर पर एप्लिकेशन इंगित करते हैं) के दौरान, निम्न चरणों के साथ GTID को mysql57a और mysql57b पर वापस सक्षम करने की अनुशंसा की जाती है:

1) ClusterControl स्वचालित पुनर्प्राप्ति सुविधा को बंद करना सुनिश्चित करें:

2) कट-ऑफ रखरखाव विंडो के दौरान, हमें नकल करना बंद करना होगा पुराने मास्टर, mysql56a से, mysql57a पर सभी स्लेव कॉन्फ़िगरेशन को हटा दें और GTID को वापस सक्षम करें। Mysql57a पर, निम्नलिखित कमांड को सही क्रम में चलाएँ:

mysql> SHOW SLAVE STATUS\G # Make sure you see "Slave has read all relay log"
mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL enforce_gtid_consistency = 'ON';
mysql> SET GLOBAL gtid_mode = 'ON';

इस बिंदु पर, आपके एप्लिकेशन के लिए नए मास्टर, mysql57a को लिखना शुरू करना व्यावहारिक रूप से सुरक्षित है। पुराना स्टैंडअलोन MySQL अब प्रतिकृति श्रृंखला से बाहर हो गया है और इसे बंद किया जा सकता है।

3) mysql57b के लिए समान चरणों को दोहराएं। सही क्रम में चरणों का पालन करना याद रखें:

mysql> SHOW SLAVE STATUS\G # Make sure you see "Slave has read all relay log"
mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;
mysql> SET GLOBAL super_read_only = 0;
mysql> SET GLOBAL read_only = 0;
mysql> SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
mysql> SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
mysql> SET GLOBAL enforce_gtid_consistency = 'ON';
mysql> SET GLOBAL gtid_mode = 'ON';

4) फिर, मास्टर को नए मास्टर, mysql57a पर रीसेट करें:

mysql> RESET MASTER;

3) फिर नए स्लेव पर, mysql57b ने GTID का उपयोग करके mysql57a में प्रतिकृति लिंक सेटअप किया:

mysql> RESET MASTER;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.31', MASTER_USER = 'rpl_user', MASTER_PASSWORD = '68n61F+bdsW1}[email protected]}x5J', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS\G

सुनिश्चित करें कि आप देखते हैं कि पुनर्प्राप्त_Gtid_Set और Executed_Gtid_Set फ़ील्ड का GTID मान है।

4) इस बिंदु पर, हमने क्लस्टर परिनियोजन चरण के दौरान ClusterControl द्वारा पहले कॉन्फ़िगर किए जा रहे प्रतिकृति कॉन्फ़िगरेशन को वापस बहाल कर दिया है। फिर हम नए दास पर केवल पढ़ने के लिए सक्षम कर सकते हैं, mysql57b इसे आकस्मिक लेखन से बचाने के लिए:

mysql> SET GLOBAL super_read_only = 1;
mysql> SET GLOBAL read_only = 1;

आखिरकार, पावर आइकन को हरे रंग में टॉगल करके क्लस्टर के लिए क्लस्टरकंट्रोल स्वचालित पुनर्प्राप्ति को पुन:सक्षम करें। फिर आप पुराने मास्टर, mysql56a को बंद कर सकते हैं। हमने अभी बहुत कम डाउनटाइम के साथ MySQL 5.6 से MySQL 5.7 में अपना ऑनलाइन माइग्रेशन पूरा किया है। इसी तरह के चरणों को MySQL 8.0 में माइग्रेशन के लिए भी काम करना चाहिए।