MySQL गुलाम असंगत हो सकते हैं। आप इससे बचने की कोशिश कर सकते हैं, लेकिन यह वास्तव में कठिन है। Super_read_only सेट करना और पंक्ति-आधारित प्रतिकृति का उपयोग करने से बहुत मदद मिल सकती है, लेकिन आप जो भी करते हैं, यह अभी भी संभव है कि आपका दास असंगत हो जाएगा।
एक असंगत MySQL स्लेव के पुनर्निर्माण के लिए क्या किया जा सकता है? इस ब्लॉग पोस्ट में हम इस समस्या पर एक नज़र डालेंगे।
सबसे पहले, आइए चर्चा करें कि गुलाम को फिर से बनाने के लिए क्या करना होगा। MySQL प्रतिकृति में एक नोड लाने के लिए, इसे प्रतिकृति टोपोलॉजी में किसी एक नोड से डेटा के साथ प्रावधान करना होगा। यह डेटा उस समय सुसंगत होना चाहिए जब इसे एकत्र किया गया था। आप इसे तालिका के आधार पर या स्कीमा के आधार पर स्कीमा के आधार पर नहीं ले सकते, क्योंकि यह प्रावधानित नोड को आंतरिक रूप से असंगत बना देगा। मतलब कुछ डेटा डेटासेट के किसी अन्य हिस्से से पुराना होगा।
डेटा संगतता के अलावा, डेटा और प्रतिकृति की स्थिति के बीच संबंध के बारे में जानकारी एकत्र करना भी संभव होना चाहिए। आप या तो बाइनरी लॉग स्थिति चाहते हैं जिस पर एकत्रित डेटा सुसंगत है या लेन-देन की वैश्विक लेनदेन आईडी जो डेटा के स्रोत नोड पर निष्पादित अंतिम थी।
यह हमें निम्नलिखित बातों की ओर ले जाता है। आप किसी भी बैकअप टूल का उपयोग करके एक गुलाम का पुनर्निर्माण कर सकते हैं जब तक कि यह उपकरण लगातार बैकअप उत्पन्न कर सकता है और इसमें उस समय के लिए प्रतिकृति निर्देशांक शामिल हैं जिसमें बैकअप सुसंगत है। यह हमें कुछ विकल्पों में से चुनने की अनुमति देता है।
एक असंगत MySQL स्लेव के पुनर्निर्माण के लिए Mysqldump का उपयोग करना
Mysqldump सबसे बुनियादी उपकरण है जिसे हमें प्राप्त करना है। यह हमें दूसरों के बीच, SQL कथनों के रूप में एक तार्किक बैकअप बनाने की अनुमति देता है। महत्वपूर्ण बात यह है कि बुनियादी होते हुए भी, यह हमें लगातार बैकअप लेने की अनुमति देता है:यह लेनदेन का उपयोग यह सुनिश्चित करने के लिए कर सकता है कि डेटा लेनदेन की शुरुआत में सुसंगत है। यह उस बिंदु के लिए प्रतिकृति निर्देशांक भी लिख सकता है, यहां तक कि एक संपूर्ण CHANGE MASTER कथन भी, जिससे बैकअप का उपयोग करके प्रतिकृति प्रारंभ करना आसान हो जाता है।
एक असंगत MySQL स्लेव के पुनर्निर्माण के लिए Mydumper का उपयोग करना
एक अन्य विकल्प mydumper का उपयोग करना है - यह उपकरण, mysqldump की तरह, एक तार्किक बैकअप उत्पन्न करता है और, mysqldump की तरह, डेटाबेस का एक सुसंगत बैकअप बनाने के लिए उपयोग किया जा सकता है। mydumper और mysqldump के बीच मुख्य अंतर यह है कि mydumper, जब myloader के साथ जोड़ा जाता है, डेटा को समानांतर में डंप और पुनर्स्थापित कर सकता है, डंप में सुधार कर सकता है और, विशेष रूप से, समय को पुनर्स्थापित कर सकता है।
असंगत MySQL स्लेव को फिर से बनाने के लिए स्नैपशॉट का उपयोग करना
क्लाउड प्रदाताओं का उपयोग करने वालों के लिए, अंतर्निहित ब्लॉक संग्रहण का एक स्नैपशॉट लेने की संभावना है। स्नैपशॉट डेटा का पॉइंट-इन-टाइम दृश्य उत्पन्न करते हैं। हालांकि यह प्रक्रिया काफी मुश्किल है, क्योंकि डेटा की स्थिरता और इसे पुनर्स्थापित करने की क्षमता ज्यादातर MySQL कॉन्फ़िगरेशन पर निर्भर करती है।
आपको यह सुनिश्चित करना चाहिए कि डेटाबेस एक टिकाऊ मोड में काम करता है (इसे इस तरह से कॉन्फ़िगर किया गया है कि MySQL के क्रैश होने से कोई डेटा हानि नहीं होगी)। ऐसा इसलिए है क्योंकि (MySQL के दृष्टिकोण से) वॉल्यूम स्नैपशॉट लेना और फिर उसमें संग्रहीत डेटा से एक और MySQL इंस्टेंस शुरू करना, मूल रूप से, वही प्रक्रिया है जैसे कि आप -9 को mysqld को मार देंगे और फिर इसे फिर से शुरू करेंगे। InnoDB पुनर्प्राप्ति होनी चाहिए, बाइनरी लॉग में संग्रहीत लेनदेन को फिर से चलाएं, रोलबैक लेनदेन जो क्रैश से पहले पूरा नहीं हुआ है और इसी तरह।
स्नैपशॉट-आधारित पुनर्निर्माण प्रक्रिया का नकारात्मक पक्ष यह है कि यह वर्तमान विक्रेता से दृढ़ता से जुड़ा हुआ है। आप स्नैपशॉट डेटा को एक क्लाउड प्रदाता से दूसरे क्लाउड प्रदाता में आसानी से कॉपी नहीं कर सकते। आप इसे विभिन्न क्षेत्रों के बीच स्थानांतरित करने में सक्षम हो सकते हैं लेकिन यह अभी भी एक ही प्रदाता होगा।
एक असंगत MySQL स्लेव को फिर से बनाने के लिए एक्स्ट्राबैकअप या मारियाबैकअप का उपयोग करना
अंत में, xtrabackup/mariabackup - यह Percona द्वारा लिखित और MariaDB द्वारा फोर्क किया गया एक टूल है जो एक भौतिक बैकअप उत्पन्न करने की अनुमति देता है। यह तार्किक बैकअप की तुलना में तेज़ है - यह ज्यादातर हार्डवेयर प्रदर्शन द्वारा सीमित है - डिस्क या नेटवर्क सबसे संभावित अड़चनें हैं। अधिकांश कार्यभार MySQL डेटा निर्देशिका से फ़ाइलों को किसी अन्य स्थान पर (उसी होस्ट या नेटवर्क पर) कॉपी करने से संबंधित है।
ब्लॉक स्टोरेज स्नैपशॉट जितना तेज़ नहीं होने के बावजूद, xtrabackup अधिक लचीला है और किसी भी वातावरण में उपयोग किया जा सकता है। इसके द्वारा उत्पादित बैकअप में फाइलें होती हैं, इसलिए बैकअप को अपनी पसंद के किसी भी स्थान पर कॉपी करना पूरी तरह से संभव है। एक अन्य क्लाउड प्रदाता, आपका स्थानीय डेटासेंटर, यह तब तक मायने नहीं रखता जब तक आप अपने वर्तमान स्थान से फ़ाइलें स्थानांतरित कर सकते हैं।
इसमें नेटवर्क कनेक्टिविटी होना भी आवश्यक नहीं है - आप बैकअप को USB SSD या यहां तक कि USB स्टिक जैसे कुछ "हस्तांतरणीय" डिवाइस पर कॉपी कर सकते हैं, जब तक कि इसमें सभी शामिल हो सकते हैं जब आप एक डेटासेंटर से दूसरे में स्थानांतरित करते हैं तो डेटा और इसे अपनी जेब में संग्रहीत करते हैं।
Xtrabackup का उपयोग करके एक MySQL स्लेव का पुनर्निर्माण कैसे करें?
हमने xtrabackup पर ध्यान केंद्रित करने का निर्णय लिया, इसकी लचीलेपन और अधिकांश वातावरण में काम करने की क्षमता को देखते हुए जहां MySQL मौजूद हो सकता है। आप xtrabackup का उपयोग करके अपने दास का पुनर्निर्माण कैसे करते हैं? आइए एक नज़र डालते हैं।
शुरू में, हमारे पास एक मास्टर और एक गुलाम है, जो कुछ प्रतिकृति मुद्दों से पीड़ित था:
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.141
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000004
Read_Master_Log_Pos: 386
Relay_Log_File: relay-bin.000008
Relay_Log_Pos: 363
Relay_Master_Log_File: binlog.000004
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1007
Last_Error: Error 'Can't create database 'mytest'; database exists' on query. Default database: 'mytest'. Query: 'create database mytest'
Skip_Counter: 0
Exec_Master_Log_Pos: 195
Relay_Log_Space: 756
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1007
Last_SQL_Error: Error 'Can't create database 'mytest'; database exists' on query. Default database: 'mytest'. Query: 'create database mytest'
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1001
Master_UUID: 53d96192-53f7-11ea-9c3c-080027c5bc64
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 200306 11:47:42
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 53d96192-53f7-11ea-9c3c-080027c5bc64:9
Executed_Gtid_Set: 53d96192-53f7-11ea-9c3c-080027c5bc64:1-8,
ce7d0c38-53f7-11ea-9f16-080027c5bc64:1-3
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
Master_public_key_path:
Get_master_public_key: 0
Network_Namespace:
1 row in set (0.00 sec)जैसा कि आप देख सकते हैं, किसी एक स्कीमा में समस्या है। आइए मान लें कि हमें इस नोड को प्रतिकृति में वापस लाने के लिए पुनर्निर्माण करना होगा। यहां वे चरण दिए गए हैं जो हमें करने हैं।
सबसे पहले, हमें यह सुनिश्चित करना होगा कि xtrabackup स्थापित है। हमारे मामले में हम MySQL 8.0 का उपयोग करते हैं इसलिए हमें संगतता सुनिश्चित करने के लिए संस्करण 8 में xtrabackup का उपयोग करना होगा:
[email protected]:~# apt install percona-xtrabackup-80
Reading package lists... Done
Building dependency tree
Reading state information... Done
percona-xtrabackup-80 is already the newest version (8.0.9-1.bionic).
0 upgraded, 0 newly installed, 0 to remove and 143 not upgraded.Xtrabackup Percona रिपॉजिटरी द्वारा प्रदान किया जाता है और इसे स्थापित करने के लिए गाइड यहां पाया जा सकता है:
https://www.percona.com/doc/percona-xtrabackup/8.0/installation/apt_repo.html
उपकरण को मास्टर और स्लेव दोनों पर स्थापित करना होगा जिसे हम पुनर्निर्माण करना चाहते हैं।
अगले कदम के रूप में हम "टूटे हुए" दास से सभी डेटा निकाल देंगे:
[email protected]:~# service mysql stop
[email protected]:~# rm -rf /var/lib/mysql/*अगला, हम मास्टर पर बैकअप लेंगे और इसे स्लेव में स्ट्रीम करेंगे। कृपया ध्यान रखें कि इस विशेष वन-लाइनर के लिए मास्टर से स्लेव तक पासवर्ड रहित SSH रूट कनेक्टिविटी की आवश्यकता होती है:
[email protected]:~# xtrabackup --backup --compress --stream=xbstream --target-dir=./ | ssh [email protected] "xbstream -x --decompress -C /var/lib/mysql/"
अंत में आपको एक महत्वपूर्ण पंक्ति दिखनी चाहिए:
200306 12:10:40 completed OK!यह एक संकेतक है कि बैकअप ठीक हो गया है। कुछ चीजें अभी भी गलत हो सकती हैं लेकिन कम से कम हमें डेटा सही मिला है। इसके बाद, स्लेव पर, हमें बैकअप तैयार करना होगा।
[email protected]:~# xtrabackup --prepare --target-dir=/var/lib/mysql/
.
.
.
200306 12:16:07 completed OK!आपको फिर से देखना चाहिए कि प्रक्रिया पूरी हुई ठीक है। अब आप डेटा को वापस MySQL डेटा निर्देशिका में कॉपी करना चाह सकते हैं। हमें ऐसा करने की आवश्यकता नहीं है क्योंकि हमने स्ट्रीमिंग बैकअप को सीधे /var/lib/mysql. हालांकि, हम जो करना चाहते हैं, वह फाइलों का सही स्वामित्व सुनिश्चित करना है:
[email protected]:~# chown -R mysql.mysql /var/lib/mysqlअब, बैकअप के GTID निर्देशांकों की जांच करते हैं। प्रतिकृति सेट करते समय हम बाद में उनका उपयोग करेंगे।
[email protected]:~# cat /var/lib/mysql/xtrabackup_binlog_info
binlog.000007 195 53d96192-53f7-11ea-9c3c-080027c5bc64:1-9ठीक है, सब ठीक लग रहा है, आइए MySQL शुरू करें और प्रतिकृति को कॉन्फ़िगर करने के साथ आगे बढ़ें:
[email protected]:~# service mysql start
[email protected]:~# mysql -ppass
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.18-9 Percona Server (GPL), Release '9', Revision '53e606f'
Copyright (c) 2009-2019 Percona LLC and/or its affiliates
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>अब हमें gtid_purged को GTID सेट पर सेट करना होगा जो हमें बैकअप में मिला था। वे GTID हैं जिन्हें हमारे बैकअप द्वारा "कवर" किया गया है। केवल नए GTID को मास्टर से दोहराया जाना चाहिए।
mysql> SET GLOBAL gtid_purged='53d96192-53f7-11ea-9c3c-080027c5bc64:1-9';
Query OK, 0 rows affected (0.00 sec)
Now we can start the replication:
mysql> CHANGE MASTER TO MASTER_HOST='10.0.0.141', MASTER_USER='rpl_user', MASTER_PASSWORD='yIPpgNE4KE', MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.02 sec)
mysql> START SLAVE;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.141
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000007
Read_Master_Log_Pos: 380
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 548
Relay_Master_Log_File: binlog.000007
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 380
Relay_Log_Space: 750
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1001
Master_UUID: 53d96192-53f7-11ea-9c3c-080027c5bc64
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 53d96192-53f7-11ea-9c3c-080027c5bc64:10
Executed_Gtid_Set: 53d96192-53f7-11ea-9c3c-080027c5bc64:1-10
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
Master_public_key_path:
Get_master_public_key: 0
Network_Namespace:
1 row in set (0.00 sec)जैसा कि आप देख सकते हैं, हमारा गुलाम अपने मालिक से नकल कर रहा है।
ClusterControl का उपयोग करके एक MySQL स्लेव का पुनर्निर्माण कैसे करें?
यदि आप एक ClusterControl उपयोगकर्ता हैं, तो इस प्रक्रिया से गुजरने के बजाय आप बस कुछ ही क्लिक में दास का पुनर्निर्माण कर सकते हैं। प्रारंभ में हमारे पास प्रतिकृति के साथ एक स्पष्ट समस्या है:
एक त्रुटि के कारण हमारा गुलाम ठीक से नकल नहीं कर रहा है।
हमें बस इतना करना है कि हम "पुनर्निर्माण स्लेव" कार्य को चलाएं ।
आपको एक संवाद के साथ प्रस्तुत किया जाएगा जहां आपको इसके लिए एक मास्टर नोड चुनना चाहिए। वह दास जिसे आप पुनर्निर्माण करना चाहते हैं। फिर, Proceed पर क्लिक करें और आप पूरी तरह तैयार हैं। ClusterControl स्लेव का पुनर्निर्माण करेगा और आपके लिए प्रतिकृति सेट करेगा।
जल्द ही, डेटा सेट आकार के आधार पर, आपको काम करने वाला दास दिखाई देगा:
जैसा कि आप देख सकते हैं, बस कुछ ही क्लिक के साथ ClusterControl ने असंगत प्रतिकृति दास के पुनर्निर्माण का कार्य पूरा किया।
