प्रतिकृति MySQL और MariaDB के लिए उच्च उपलब्धता प्राप्त करने के सबसे सामान्य तरीकों में से एक है। यह GTID के जुड़ने के साथ और अधिक मजबूत हो गया है, और हजारों और हजारों उपयोगकर्ताओं द्वारा इसका पूरी तरह से परीक्षण किया गया है। MySQL प्रतिकृति एक 'सेट एंड फॉरगेट' संपत्ति नहीं है, हालांकि संभावित मुद्दों के लिए इसकी निगरानी की जानी चाहिए और इसे बनाए रखा जाना चाहिए ताकि यह अच्छी स्थिति में रहे। इस ब्लॉग पोस्ट में, हम MySQL प्रतिकृति के साथ समस्याओं को बनाए रखने, उनका निवारण करने और उन्हें ठीक करने के बारे में कुछ सुझाव और तरकीबें साझा करना चाहते हैं।
कैसे निर्धारित करें कि MySQL प्रतिकृति अच्छी स्थिति में है या नहीं?
यह सबसे महत्वपूर्ण कौशल है जो MySQL प्रतिकृति सेटअप की देखभाल करने वाले किसी भी व्यक्ति के पास होना चाहिए। आइए देखें कि प्रतिकृति की स्थिति के बारे में जानकारी कहां देखें। MySQL और MariaDB में थोड़ा सा अंतर है और हम इस पर भी चर्चा करेंगे।
गुलाम की स्थिति दिखाएं
दास मेजबान पर प्रतिकृति की स्थिति की जांच करने का यह सबसे आम तरीका है - यह हमेशा से हमारे साथ है और आमतौर पर यह पहला स्थान होता है जहां हम उम्मीद करते हैं कि प्रतिकृति के साथ कुछ समस्या है।
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.101
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000002
Read_Master_Log_Pos: 767658564
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 405
Relay_Master_Log_File: binlog.000002
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: 767658564
Relay_Log_Space: 606
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: 1
Master_UUID: 5d1e2227-07c6-11e7-8123-080027495a77
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:
Executed_Gtid_Set: 5d1e2227-07c6-11e7-8123-080027495a77:1-394233
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)MySQL और MariaDB के बीच कुछ विवरण भिन्न हो सकते हैं लेकिन अधिकांश सामग्री समान दिखाई देगी। परिवर्तन GTID अनुभाग में दिखाई देंगे क्योंकि MySQL और MariaDB इसे अलग तरीके से करते हैं। SHOW SLAVE STATUS से, आप कुछ जानकारी प्राप्त कर सकते हैं - किस मास्टर का उपयोग किया जाता है, किस उपयोगकर्ता और किस पोर्ट का उपयोग मास्टर से कनेक्ट करने के लिए किया जाता है। हमारे पास वर्तमान बाइनरी लॉग स्थिति के बारे में कुछ डेटा है (अब वह महत्वपूर्ण नहीं है क्योंकि हम GTID का उपयोग कर सकते हैं और बिनलॉग के बारे में भूल सकते हैं) और SQL और I/O प्रतिकृति थ्रेड्स की स्थिति। फिर आप देख सकते हैं कि फ़िल्टरिंग को कॉन्फ़िगर किया गया है या नहीं। आप त्रुटियों, प्रतिकृति अंतराल, एसएसएल सेटिंग्स और जीटीआईडी के बारे में कुछ जानकारी भी प्राप्त कर सकते हैं। ऊपर दिया गया उदाहरण MySQL 5.7 स्लेव से आया है जो स्वस्थ अवस्था में है। आइए कुछ उदाहरण देखें जहां प्रतिकृति टूट गई है।
MariaDB [test]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.104
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000003
Read_Master_Log_Pos: 636
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 765
Relay_Master_Log_File: binlog.000003
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: 1032
Last_Error: Could not execute Update_rows_v1 event on table test.tab; Can't find record in 'tab', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000003, end_log_pos 609
Skip_Counter: 0
Exec_Master_Log_Pos: 480
Relay_Log_Space: 1213
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: 1032
Last_SQL_Error: Could not execute Update_rows_v1 event on table test.tab; Can't find record in 'tab', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000003, end_log_pos 609
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-1-73243
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
1 row in set (0.00 sec)यह नमूना MariaDB 10.1 से लिया गया है, आप इसे MariaDB GTID के साथ काम करने के लिए आउटपुट के निचले भाग में परिवर्तन देख सकते हैं। हमारे लिए जो महत्वपूर्ण है वह त्रुटि है - आप देख सकते हैं कि SQL थ्रेड में कुछ सही नहीं है:
Last_SQL_Error: Could not execute Update_rows_v1 event on table test.tab; Can't find record in 'tab', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000003, end_log_pos 609हम इस विशेष समस्या पर बाद में चर्चा करेंगे, अभी के लिए यह पर्याप्त है कि आप देखेंगे कि आप कैसे जांच सकते हैं कि SHOW SLAVE STATUS का उपयोग करके प्रतिकृति में कोई त्रुटि है या नहीं।
एक और महत्वपूर्ण जानकारी जो SHOW SLAVE STATUS से आती है वह है - हमारा गुलाम कितना पिछड़ा हुआ है। आप इसे “Seconds_Behind_Master” कॉलम में देख सकते हैं। यह मीट्रिक ट्रैक करने के लिए विशेष रूप से महत्वपूर्ण है यदि आप जानते हैं कि आपका एप्लिकेशन पुराने पठन के लिए संवेदनशील है।
ClusterControl में आप इस डेटा को "अवलोकन" अनुभाग में ट्रैक कर सकते हैं:
हमने SHOW SLAVE STATUS कमांड से सभी महत्वपूर्ण जानकारी दिखाई। आप प्रतिकृति की स्थिति की जांच कर सकते हैं, जो मास्टर है, यदि कोई प्रतिकृति अंतराल है या नहीं, बाइनरी लॉग स्थिति। आप पुनर्प्राप्त और निष्पादित GTID को भी ढूंढ सकते हैं।
प्रदर्शन स्कीमा
एक अन्य स्थान जहां आप प्रतिकृति के बारे में जानकारी देख सकते हैं वह है performance_schema. यह केवल Oracle के MySQL 5.7 - पुराने संस्करणों पर लागू होता है और MariaDB इस डेटा को एकत्र नहीं करती है।
mysql> SHOW TABLES FROM performance_schema LIKE 'replication%';
+---------------------------------------------+
| Tables_in_performance_schema (replication%) |
+---------------------------------------------+
| replication_applier_configuration |
| replication_applier_status |
| replication_applier_status_by_coordinator |
| replication_applier_status_by_worker |
| replication_connection_configuration |
| replication_connection_status |
| replication_group_member_stats |
| replication_group_members |
+---------------------------------------------+
8 rows in set (0.00 sec)नीचे आपको उनमें से कुछ तालिकाओं में उपलब्ध डेटा के कुछ उदाहरण मिल सकते हैं।
mysql> select * from replication_connection_status\G
*************************** 1. row ***************************
CHANNEL_NAME:
GROUP_NAME:
SOURCE_UUID: 5d1e2227-07c6-11e7-8123-080027495a77
THREAD_ID: 32
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 1
LAST_HEARTBEAT_TIMESTAMP: 2017-03-17 19:41:34
RECEIVED_TRANSACTION_SET: 5d1e2227-07c6-11e7-8123-080027495a77:715599-724966
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
1 row in set (0.00 sec)mysql> select * from replication_applier_status_by_worker\G
*************************** 1. row ***************************
CHANNEL_NAME:
WORKER_ID: 0
THREAD_ID: 31
SERVICE_STATE: ON
LAST_SEEN_TRANSACTION: 5d1e2227-07c6-11e7-8123-080027495a77:726086
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
1 row in set (0.00 sec)जैसा कि आप देख सकते हैं, हम प्रतिकृति की स्थिति, अंतिम त्रुटि, प्राप्त लेनदेन सेट और कुछ और डेटा को सत्यापित कर सकते हैं। क्या महत्वपूर्ण है - यदि आपने बहु-थ्रेडेड प्रतिकृति को सक्षम किया है, तो प्रतिकृति_एप्लियर_स्टैटस_बाय_वर्कर तालिका में, आप प्रत्येक कार्यकर्ता की स्थिति देखेंगे - इससे आपको प्रत्येक कार्यकर्ता थ्रेड के लिए प्रतिकृति की स्थिति को समझने में मदद मिलती है।
प्रतिकृति अंतराल
MySQL प्रतिकृति के साथ काम करते समय अंतराल निश्चित रूप से सबसे आम समस्याओं में से एक है। प्रतिकृति अंतराल तब दिखाई देता है जब दासों में से एक मास्टर द्वारा किए गए लेखन कार्यों की मात्रा को बनाए रखने में असमर्थ होता है। कारण अलग-अलग हो सकते हैं - अलग-अलग हार्डवेयर कॉन्फ़िगरेशन, दास पर भारी भार, मास्टर पर उच्च स्तर की लेखन समांतरता जिसे क्रमबद्ध किया जाना है (जब आप प्रतिकृति के लिए एकल धागे का उपयोग करते हैं) या लेखन को उसी हद तक समानांतर नहीं किया जा सकता है जैसा कि है मास्टर पर रहा है (जब आप बहु-थ्रेडेड प्रतिकृति का उपयोग करते हैं)।
इसका पता कैसे लगाएं?
प्रतिकृति अंतराल का पता लगाने के लिए कुछ तरीके हैं। सबसे पहले, आप SHOW SLAVE STATUS आउटपुट में "Seconds_Behind_Master" चेक कर सकते हैं - यह आपको बताएगा कि गुलाम पिछड़ रहा है या नहीं। यह ज्यादातर मामलों में अच्छी तरह से काम करता है लेकिन अधिक जटिल टोपोलॉजी में, जब आप इंटरमीडिएट मास्टर्स का उपयोग करते हैं, तो मेजबानों पर प्रतिकृति श्रृंखला में कहीं कम होता है, यह सटीक नहीं हो सकता है। एक और, बेहतर, समाधान पीटी-दिल की धड़कन जैसे बाहरी उपकरणों पर भरोसा करना है। आइडिया सरल है - एक टेबल, अन्य के साथ, एक टाइमस्टैम्प कॉलम के साथ बनाई जाती है। यह कॉलम नियमित अंतराल पर मास्टर पर अपडेट किया जाता है। एक गुलाम पर, आप उस कॉलम के टाइमस्टैम्प की तुलना वर्तमान समय से कर सकते हैं - यह आपको बताएगा कि दास कितना पीछे है।
आप जिस तरह से अंतराल की गणना करते हैं, सुनिश्चित करें कि आपके मेजबान समय-समय पर सिंक में हैं। ntpd या टाइम सिंकिंग के अन्य साधनों का उपयोग करें - यदि समय का बहाव होता है, तो आप अपने दासों पर "झूठा" अंतराल देखेंगे।
लैग कैसे कम करें?
इस सवाल का ज़वाब देना आसान नहीं है। संक्षेप में, यह इस बात पर निर्भर करता है कि अंतराल का कारण क्या है, और क्या अड़चन बन गया। दो विशिष्ट पैटर्न हैं - दास I/O बाध्य है, जिसका अर्थ है कि इसका I/O सबसिस्टम लिखने और पढ़ने के संचालन की मात्रा का सामना नहीं कर सकता है। दूसरा - स्लेव सीपीयू-बाउंड है, जिसका अर्थ है कि प्रतिकृति थ्रेड सभी सीपीयू का उपयोग करता है (एक थ्रेड केवल एक सीपीयू कोर का उपयोग कर सकता है) और यह अभी भी सभी लेखन कार्यों को संभालने के लिए पर्याप्त नहीं है।
जब सीपीयू एक बाधा है, तो समाधान बहु-थ्रेडेड प्रतिकृति का उपयोग करने जितना आसान हो सकता है। उच्च समांतरता की अनुमति देने के लिए काम करने वाले धागे की संख्या बढ़ाएं। हालांकि यह हमेशा संभव नहीं होता है - ऐसे मामले में आप थोड़े समय के लिए कमिट करने में देरी करने के लिए ग्रुप कमिट वेरिएबल्स (MySQL और MariaDB दोनों के लिए) के साथ थोड़ा खेलना चाहते हैं (हम यहां मिलीसेकंड के बारे में बात कर रहे हैं) और, इस तरह , कमिट्स के समानांतरीकरण को बढ़ाएं।
यदि समस्या I/O में है, तो समस्या को हल करना थोड़ा कठिन है। बेशक, आपको अपनी InnoDB I/O सेटिंग्स की समीक्षा करनी चाहिए - शायद इसमें सुधार की गुंजाइश है। अगर my.cnf ट्यूनिंग मदद नहीं करेगी, तो आपके पास बहुत अधिक विकल्प नहीं हैं - अपने प्रश्नों को सुधारें (जहाँ भी संभव हो) या अपने I/O सबसिस्टम को और अधिक सक्षम करने के लिए अपग्रेड करें।
अधिकांश प्रॉक्सी (उदाहरण के लिए, सभी प्रॉक्सी जिन्हें ClusterControl से तैनात किया जा सकता है:ProxySQL, HAProxy और MaxScale) आपको एक गुलाम को रोटेशन से बाहर निकालने की संभावना देते हैं यदि प्रतिकृति अंतराल कुछ पूर्वनिर्धारित सीमा को पार करता है। यह किसी भी तरह से अंतराल को कम करने का एक तरीका नहीं है, लेकिन यह बासी पढ़ने से बचने में मददगार हो सकता है और, एक साइड इफेक्ट के रूप में, एक दास पर भार को कम करने के लिए जो इसे पकड़ने में मदद कर सकता है।
बेशक, क्वेरी ट्यूनिंग दोनों ही मामलों में एक समाधान हो सकता है - सीपीयू या आई/ओ भारी प्रश्नों को सुधारना हमेशा अच्छा होता है।
गलत लेनदेन
त्रुटिपूर्ण लेन-देन वे लेन-देन हैं जो केवल दास पर निष्पादित किए गए हैं, स्वामी पर नहीं। संक्षेप में, वे दास को स्वामी के साथ असंगत बना देते हैं। GTID- आधारित प्रतिकृति का उपयोग करते समय, यदि दास को मास्टर के रूप में पदोन्नत किया जाता है, तो यह गंभीर समस्या पैदा कर सकता है। इस विषय पर हमारे पास एक गहन पोस्ट है और हम आपको इस पर गौर करने और त्रुटिपूर्ण लेन-देन की समस्याओं का पता लगाने और उन्हें ठीक करने के तरीके से परिचित होने के लिए प्रोत्साहित करते हैं। हमने इसमें यह जानकारी भी शामिल की है कि कैसे ClusterControl गलत लेनदेन का पता लगाता है और उन्हें संभालता है।
मास्टर पर कोई बिनलॉग फ़ाइल नहीं
समस्या की पहचान कैसे करें?
कुछ परिस्थितियों में, ऐसा हो सकता है कि दास मास्टर से जुड़ता है और गैर-मौजूदा बाइनरी लॉग फ़ाइल मांगता है। इसका एक कारण गलत लेन-देन हो सकता है - किसी समय दास पर लेन-देन किया गया हो और बाद में यह दास स्वामी बन जाता है। अन्य होस्ट, जो उस मास्टर को बंद करने के लिए कॉन्फ़िगर किए गए हैं, उस लापता लेनदेन के लिए कहेंगे। यदि इसे बहुत समय पहले निष्पादित किया गया था, तो संभावना है कि बाइनरी लॉग फ़ाइलें पहले ही शुद्ध हो चुकी हैं।
एक और, अधिक विशिष्ट, उदाहरण - आप xtrabackup का उपयोग करके एक गुलाम का प्रावधान करना चाहते हैं। आप बैकअप को होस्ट पर कॉपी करते हैं, लॉग लागू करते हैं, MySQL डेटा निर्देशिका के स्वामी को बदलते हैं - बैकअप को पुनर्स्थापित करने के लिए आप जो विशिष्ट ऑपरेशन करते हैं। आप निष्पादित करें
SET GLOBAL gtid_purged=xtrabackup_binlog_info के डेटा के आधार पर और आप CHANGE MASTER TO… MASTER_AUTO_POSITION=1 (यह MySQL में है, MariaDB की प्रक्रिया थोड़ी अलग है), स्लेव को प्रारंभ करें और फिर आप एक त्रुटि के साथ समाप्त होते हैं:
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'MySQL में या:
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find GTID state requested by slave in any binlog files. Probably the slave state is too old and required binlog files have been purged.'मारियाडीबी में।
इसका मूल रूप से मतलब है कि मास्टर के पास सभी लापता लेनदेन को निष्पादित करने के लिए आवश्यक सभी बाइनरी लॉग नहीं हैं। सबसे अधिक संभावना है, बैकअप बहुत पुराना है और मास्टर ने बैकअप बनाए जाने और स्लेव के प्रावधान के समय के बीच बनाए गए कुछ बाइनरी लॉग को पहले ही शुद्ध कर दिया था।
इस समस्या का समाधान कैसे करें?
दुर्भाग्य से, इस विशेष मामले में आप बहुत कुछ नहीं कर सकते। यदि आपके पास कुछ MySQL होस्ट हैं जो मास्टर की तुलना में अधिक समय तक बाइनरी लॉग स्टोर करते हैं, तो आप दास पर लापता लेनदेन को फिर से चलाने के लिए उन लॉग का उपयोग करने का प्रयास कर सकते हैं। आइए देखें कि यह कैसे किया जा सकता है।
सबसे पहले, आइए मास्टर के बाइनरी लॉग में सबसे पुराने GTID पर एक नज़र डालें:
mysql> SHOW BINARY LOGS\G
*************************** 1. row ***************************
Log_name: binlog.000021
File_size: 463
1 row in set (0.00 sec)तो, 'binlog.000021' नवीनतम (और केवल) फ़ाइल है। आइए देखें कि इस फ़ाइल में पहली GTID प्रविष्टि क्या है:
[email protected]:~# mysqlbinlog /var/lib/mysql/binlog.000021
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @[email protected]@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#170320 10:39:51 server id 1 end_log_pos 123 CRC32 0x5644fc9b Start: binlog v 4, server v 5.7.17-11-log created 170320 10:39:51
# Warning: this binlog is either in use or was not closed properly.
BINLOG '
d7HPWA8BAAAAdwAAAHsAAAABAAQANS43LjE3LTExLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AZv8RFY=
'/*!*/;
# at 123
#170320 10:39:51 server id 1 end_log_pos 194 CRC32 0x5c096d62 Previous-GTIDs
# 5d1e2227-07c6-11e7-8123-080027495a77:1-1106668
# at 194
#170320 11:21:26 server id 1 end_log_pos 259 CRC32 0xde21b300 GTID last_committed=0 sequence_number=1
SET @@SESSION.GTID_NEXT= '5d1e2227-07c6-11e7-8123-080027495a77:1106669'/*!*/;
# at 259जैसा कि हम देख सकते हैं, उपलब्ध सबसे पुरानी बाइनरी लॉग प्रविष्टि है:5d1e2227-07c6-11e7-8123-080027495a77:1106669
हमें यह भी जांचना होगा कि बैकअप में शामिल अंतिम GTID क्या है:
[email protected]:~# cat /var/lib/mysql/xtrabackup_binlog_info
binlog.000017 194 5d1e2227-07c6-11e7-8123-080027495a77:1-1106666
यह है:5d1e2227-07c6-11e7-8123-080027495a77:1-1106666 इसलिए हमारे पास दो इवेंट नहीं हैं:
5d1e2227-07c6-11e7-8123-080027495a77:1106667-1106668
आइए देखें कि क्या हम उन लेन-देन को दूसरे दास पर ढूंढ सकते हैं।
mysql> SHOW BINARY LOGS;
+---------------+------------+
| Log_name | File_size |
+---------------+------------+
| binlog.000001 | 1074130062 |
| binlog.000002 | 764366611 |
| binlog.000003 | 382576490 |
+---------------+------------+
3 rows in set (0.00 sec)ऐसा लगता है कि 'binlog.000003' नवीनतम बाइनरी लॉग है। हमें यह जांचने की आवश्यकता है कि क्या हमारे लापता GTID इसमें पाए जा सकते हैं:
slave2:~# mysqlbinlog /var/lib/mysql/binlog.000003 | grep "5d1e2227-07c6-11e7-8123-080027495a77:110666[78]"
SET @@SESSION.GTID_NEXT= '5d1e2227-07c6-11e7-8123-080027495a77:1106667'/*!*/;
SET @@SESSION.GTID_NEXT= '5d1e2227-07c6-11e7-8123-080027495a77:1106668'/*!*/;कृपया ध्यान रखें कि आप बिनलॉग फ़ाइलों को उत्पादन सर्वर के बाहर कॉपी करना चाह सकते हैं क्योंकि उन्हें संसाधित करने से कुछ भार जुड़ सकता है। जैसा कि हमने सत्यापित किया है कि वे GTID मौजूद हैं, हम उन्हें निकाल सकते हैं:
slave2:~# mysqlbinlog --exclude-gtids='5d1e2227-07c6-11e7-8123-080027495a77:1-1106666,5d1e2227-07c6-11e7-8123-080027495a77:1106669' /var/lib/mysql/binlog.000003 > to_apply_on_slave1.sqlएक त्वरित scp के बाद, हम उन घटनाओं को दास पर लागू कर सकते हैं
slave1:~# mysql -ppass < to_apply_on_slave1.sqlएक बार हो जाने के बाद, हम SHOW SLAVE STATUS के आउटपुट को देखकर सत्यापित कर सकते हैं कि क्या उन GTID को लागू किया गया है:
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 5d1e2227-07c6-11e7-8123-080027495a77
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: 170320 10:45:04
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set: 5d1e2227-07c6-11e7-8123-080027495a77:1-1106668Executed_GTID_set अच्छा लग रहा है इसलिए हम स्लेव थ्रेड शुरू कर सकते हैं:
mysql> START SLAVE;
Query OK, 0 rows affected (0.00 sec)आइए देखें कि क्या यह ठीक काम करता है। हम, फिर से, SHOW SLAVE STATUS आउटपुट का उपयोग करेंगे:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 5d1e2227-07c6-11e7-8123-080027495a77:1106669
Executed_Gtid_Set: 5d1e2227-07c6-11e7-8123-080027495a77:1-1106669अच्छा लग रहा है, यह चल रहा है!
इस समस्या को हल करने का एक और तरीका यह होगा कि एक बार फिर से बैकअप लिया जाए और नए डेटा का उपयोग करके दास को फिर से प्रावधान किया जाए। यह काफी तेज और निश्चित रूप से अधिक विश्वसनीय होने की संभावना है। ऐसा अक्सर नहीं होता है कि आपके पास मास्टर और दासों पर अलग-अलग बिनलॉग पर्ज नीतियां हों)
हम अगले ब्लॉग पोस्ट में अन्य प्रकार के प्रतिकृति मुद्दों पर चर्चा करना जारी रखेंगे।
