MySQL रिले लॉग दूषित हो गया, मैं इसे कैसे ठीक करूं? कोशिश की लेकिन असफल रहे

Question

मशीन के अचानक बंद होने पर एक MySQL v5.1.61 रिले दूषित हो गया। मैंने इसे ठीक करने की कोशिश की लेकिन यह काम नहीं किया।
- मैं इसे कैसे ठीक करूं? क्या मैंने कुछ गलत किया?

जहाँ तक मैंने पढ़ा है, भ्रष्ट MySQL रिले लॉग आसानी से तय हो गए हैं:

change master to master_log_file='<Relay_Master_Log_File>',
                 master_log_pos=<Exec_Master_Log_Pos>;

कहां Relay_Master_Log_Fileऔर Exec_Master_Log_Posकिसके द्वारा सूचीबद्ध हैं:
mysql> show slave status;

हालांकि जब मैंने किया change master status ..., मुझे प्राथमिक कुंजी उल्लंघन त्रुटि मिली। वो कैसे संभव है? क्या उपरोक्त प्रक्रिया सही नहीं है, या जैसे कुछ +1 गायब है?

_{(अभी के लिए मैंने केवल मास्टर से दास के लिए - मास्टर डेटा mysqldump को फिर से आयात किया है, और समस्या को हल किया है। हालांकि, भविष्य में, ऐसा करना उचित नहीं हो सकता है।)}

यहाँ मेरी विशेष समस्या के बारे में विवरण दिया गया है:

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: the-master-host
                  Master_User: replication
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000021
          Read_Master_Log_Pos: 33639968
               Relay_Log_File: mysql-relay-bin.000271
                Relay_Log_Pos: 2031587
        Relay_Master_Log_File: mysql-bin.000020
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: the_database
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1594
                   Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 66395191
              Relay_Log_Space: 36559177
              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: 1594
               Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.

और यही मैंने किया:

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_host='the-master-host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

और यही हुआ, एक PK त्रुटि:

131122 15:17:29 [Note] Slave I/O thread: connected to master 'replication@the-master-host:3306',replication started in log 'mysql-bin.000020' at position 66395191
131122 15:17:29 [ERROR] Slave SQL: Error 'Duplicate entry '71373' for key 'PRIMARY'' on query. Default database: 'the_database'. Query: 'insert into ...  values ...', Error_code: 1062
131122 15:17:29 [Warning] Slave: Data truncated for column 'date' at row 1 Error_code: 1265
131122 15:17:29 [Warning] Slave: Duplicate entry '71373' for key 'PRIMARY' Error_code: 1062

मुझे लगता है कि मैंने अनुशंसित प्रक्रिया का पालन किया (नीचे दिए गए लिंक देखें), अभी भी एक पीके त्रुटि थी :-(? Http://bugs.mysql.com/bug.php?id=26489 , "Workarounds" के लिए खोज करें। http । //mhrr.wordpress.com/2013/07/26/mysql-slave-corrupted-relay-log/ /programming//a/14438408

Comments

हां, ऐसा लगता है कि इसे काम करना चाहिए था, और वास्तव में ऐसा लगता है कि यह वास्तव में काम करता है, जैसा कि शायद मूल रिले लॉग, भ्रष्ट अनुभाग से पहले, उस मास्टर लॉग की स्थिति में पहले से ही डाला था, लेकिन अग्रिम नहीं कर सका अगले पॉइंटर को मास्टर की स्थिति प्रदर्शित की जाती है, क्योंकि पॉइंटर रिले लॉग में संग्रहीत किया जाता है (जो कि भ्रष्ट था।) तो आप उस घटना को छोड़ कर अगले कार्यक्रम में जा सकते हैं, फिर उस मास्टर और गुलाम का सत्यापन करना वास्तव में समान डेटा था ... मुझे अभी तक विस्तार से प्रश्न की समीक्षा करने का अवसर नहीं मिला है।

— माइकल - sqlbot 15

धन्यवाद @ माइकल- sqlbot, तो मुझे लगता है कि अगर यह समस्या फिर से होती है, तो मैं SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;एक घटना को दास पर छोड़ दूंगा , और आशा करता हूं कि इससे मदद मिलती है - क्या इसका कोई मतलब है? यदि यह मदद नहीं करता है (यदि अभी भी एक पीके त्रुटि है), तो मैं --master-dataफिर से एक डंप आयात करूंगा ।

— काजगामेनस

Answer 1

त्रुटि: Last_SQL_Errno: 1594 Last_SQL_Error: रिले लॉग रीड विफलता: रिले लॉग इवेंट प्रविष्टि पार्स नहीं कर सका।

इस त्रुटि का अर्थ है कि या तो मास्टर लॉग फ़ाइल दूषित है या रिले लॉग फ़ाइल दूषित है।

• कुछ भी बैकअप करने से पहले अपने सभी डेटाबेस, लॉग, छवि सर्वर, दोहराएं, कई बार, और केवल अपने जोखिम पर जारी रखें।

पहले गुलाम और नोट पर "गुलाम का दर्जा दिखाएँ"

Master_Log_File: mysql-bin.000026
Read_Master_Log_Pos: 2377104
Relay_Log_File: mysqld-relay-bin.000056
Relay_Log_Pos: 1097303
Relay_Master_Log_File: mysql-bin.000026
Exec_Master_Log_Pos: 1097157

पहले हम यह सुनिश्चित करना चाहते हैं कि मास्टर लॉग फ़ाइल बरकरार है, इसलिए मास्टर सर्वर पर जाएं और Relay_Master_Log_File (चेक / var / log / mysql) ढूंढें और निम्न कमांड चलाएँ:

mysqlbinlog mysql-bin.000026

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

आगे गुलाम रिले लॉग पर एक ही कमांड चलाएं (अक्सर / var / lib / mysql में)

mysqlbinlog mysqld-relay-bin.000056

आपको संभावना है कि भ्रष्टाचार को दर्शाने वाली कुछ त्रुटियां दिखाई देंगी, जिन्होंने प्रतिकृति को रोक दिया है, जैसे:

ERROR: Error in Log_event::read_log_event(): 'read error', data_len: 336, event_type: 2
ERROR: Could not read entry at offset 1097414: Error in log format or read error.
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
root@db:/var/lib/mysql#

यदि आपको कोई त्रुटि दिखाई देती है, तो लॉग मास्टर पर ठीक है और केवल दास का रिले लॉग भ्रष्ट है। यह अच्छी खबर है, हम दास को रीसेट कर सकते हैं और इसे मास्टर्स विवरण बता सकते हैं और कहां से जारी रखना है। यदि आपको कोई त्रुटि नहीं दिखती है तो अब पढ़ना बंद कर दें, आपको एक अलग समस्या है।

यदि गुलाम रिले लॉग में त्रुटियां हैं, तो मास्टर को फिर से जोड़ने के लिए दास और दूषित लॉग को रीसेट करने के लिए निम्न आदेश चलाएँ, ठीक लॉग प्राप्त करें और फिर से स्लेव करना शुरू करें। ध्यान दें कि MASTER_LOG_POS है Exec_Master_Log_Pos, और MASTER_LOG_FILE Relay_Master_Log_File( पहले वाला नहीं है, जो रिले लॉग से मेल खाता है और जो फेंक दिया गया है) दोनों पहले कमांड से हैं।

mysql> stop slave;
Query OK, 0 rows affected (0.14 sec)

mysql> reset slave all;
Query OK, 0 rows affected (0.43 sec)

mysql>  CHANGE MASTER TO MASTER_HOST='master.host.com', MASTER_USER='masteruser', MASTER_PASSWORD='masterpass', MASTER_LOG_FILE='mysql-bin.000026', MASTER_LOG_POS=1097157;
Query OK, 0 rows affected (0.93 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

Comments

नमस्कार, आपके जवाब के लिए धन्यवाद। यदि आप प्रश्न को ध्यान से पढ़ते हैं, तो आप इसे "रिले लॉग दूषित" कहते हैं - क्योंकि हम पहले से ही mysqlbinlogआपके द्वारा सुझाए गए तरीके से उपयोग कर चुके हैं, और पता चला कि रिले लॉग (मास्टर लॉग नहीं) दूषित हो गया था। आपके द्वारा सुझाए गए फिक्स को ध्यान में रखते हुए - यदि आप प्रश्न को ध्यान से पढ़ते हैं, तो आप देखेंगे कि आपके द्वारा सुझाए गए फ़िक्स वही हैं जो हमने पहले ही प्रयास किए थे। लेकिन यह काम नहीं किया, और यही सवाल है। - लेकिन आपका जवाब समान समस्या वाले अन्य लोगों के लिए उपयोगी हो सकता है।

— काजागमनस

यह शायद ध्यान दिया जाना चाहिए, कि MASTER_LOG_FILEमें CHANGE MASTERसे लिया जाना चाहिए Relay_Master_Log_Fileऔर नहीं से Master_Log_File। आमतौर पर वे समान होंगे लेकिन यह हमेशा ऐसा नहीं हो सकता (देखें percona.com/blog/2008/07/07/… )।

— brablc

@brablc सही है। Relay_Master_Log_Fileइस्तेमाल किया जाना चाहिए, नहीं Master_Log_File। यह भी देखें: percona.com/blog/2008/07/07/…

— Mircea Vutcovici

ज्यादातर मामलों में, इसकी कोई आवश्यकता नहीं है reset slave allक्योंकि मास्टर सेटिंग्स को बदलने की आवश्यकता नहीं है (उदाहरण के लिए master_host, master_user, master_password), केवल MASTER_LOG_FILE और MASTER_LOG_POS, फिर reset_slaveपर्याप्त होना चाहिए

— Ympostor

इस सवाल और जवाब ने मेरे बट को पहले ही कई बार बचाया है। धन्यवाद।

— आर्टेम रसाकोवस्की

Answer 2

[गुलामों के रिले लॉग के खराब होने के बाद MySQL प्रतिकृति तय करना]

गुलाम (संस्करण 5.XX) पर MySQL प्रतिकृति बंद हो गई है। Slave_IO_Running को हां के रूप में चिह्नित किया गया था, लेकिन Slave_SQL_Running के रूप में नहीं। सरल स्टॉप / स्टार्ट दास ने मदद नहीं की इसलिए आगे की समस्या विश्लेषण की आवश्यकता थी। ऐसा लगता था कि वर्तमान दास के रिले लॉग को दूषित कर दिया गया था क्योंकि "mysqlbinlog" के साथ परीक्षण ने एक त्रुटि का प्रिंट आउट किया है। इसलिए, समाधान वर्तमान रिले बिनलॉग्स को त्यागने और दास को अंतिम मास्टर बिनलॉग स्थिति में इंगित करने के लिए था।

त्रुटि को ठीक करने के लिए, दास पर वर्तमान बिनलॉग फाइलों को छोड़ दिया जाना चाहिए और नई स्थिति निर्धारित करनी चाहिए। नई बिनलॉग स्थिति सेट करने से पहले यह याद रखना महत्वपूर्ण है कि Relay_Master_Log_File और Exec_Master_Log_Pos मानों का उपयोग भ्रष्ट दास सर्वर से कमांड SHOW SLAT STATUS \ G का उपयोग करके किया जाता है :

Relay_Master_Log_File: mysql-bin.002045
Exec_Master_Log_Pos: 103641119

ठीक है, इस मान के साथ, नया बिनलॉग स्थिति सेट की जा सकती है:

# stop slave
mysql> stop slave;

# make slave forget its replication position in the master's binary log
mysql> reset slave;

# change slave to start reading from stopped position
mysql> change master to master_log_file='mysql-bin.002045', master_log_pos=103641119;

# start slave
mysql> start slave;

बस ध्यान दें कि reset slaveहटा देगा master.info, relay-log.infoऔर सभी रिले लॉग फाइलें, इसलिए /var/lib/mysqlनिर्देशिका में बचे हुए को साफ करने की आवश्यकता नहीं है ।

Comments

अच्छा जवाब - आमतौर पर हमें मास्टर होस्ट, पासवर्ड आदि को बदलने की जरूरत नहीं होती है।

— andy250

Answer 3

मुझे पता है कि यह एक साल से अधिक हो गया है, लेकिन यहां इस विशेष समस्या के लिए क्या हुआ है हो सकता है।

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_host='the-master-host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

ऐसा लगता है कि इसे ठीक कर देना चाहिए क्योंकि इसने भ्रष्ट रिले लॉग को हटा दिया।

फिर, आपको 1062 त्रुटि मिली।

एक उत्कृष्ट बग ( http://bugs.mysql.com/bug.php?id=60847 ) है जो अभी भी MySQL 5.5 में सक्रिय है

हालाँकि यह बग mysql --single-transaction --flush-लॉग का उपयोग करने से संबंधित है, फिर भी एक संबंधित quirk मौजूद है।

मैंने देखा है कि पिछले हफ्ते MySQL 5.5.15 में एक क्लाइंट के लिए स्लेव्स के रूप में चलने वाले कुछ EC2 सर्वर पर क्वर्की

मास्टर पर, एक अजीब एकाधिक पंक्ति विस्तारित INSERT थी जहां प्रत्येक टपल डाला जा रहा था एक चयन था। ऐसा क्या हुआ कि रिले लॉग में LAST_INSERT_ID, जो असाइन करने के लिए अगला ऑटो वेतन वृद्धि बनाता है, पहले से ही कई-पंक्ति आवेषण के कारण स्लेव पर पहले से ही उपयोग में था।

रिले लॉग में क्रमबद्ध INSERT जैसा दिखता था

INSERT INTO tablname (column,column) VALUES (value,value,...)

कॉलम सूची में संख्यात्मक प्राथमिक कुंजी शामिल नहीं थी। जब 1062 त्रुटि वापस आई, तो मैं उसी क्वेरी का उपयोग करूंगा जो उस पर विफल रही, क्वेरी को मैन्युअल रूप से चलाएं। इसमें 1062 त्रुटि नहीं हुई। फिर, मैंने सामान्य स्किप स्लेव कमांड चलाए:

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE;
SET @sleepnumber = SLEEP(3);
SHOW SLAVE STATUS\G

फिर, प्रतिकृति पकड़ा गया।

मेरी सलाह होगी कि आप अपने INSERTs को मास्टर पर ठीक से अनुक्रमित करें क्योंकि यह बग जैसी स्थिति वास्तव में काफी परिहार्य है।

Answer 4

आपने इसे काफी सही किया है (जैसा कि पहले ही कहा जा चुका है)।

एकमात्र समस्या master.info फ़ाइल के साथ है (इसमें मास्टर की mysql-bin.log में स्थिति के बारे में जानकारी शामिल है) क्योंकि यह फ़ाइल संसाधित किए गए प्रत्येक क्वेरी के बाद डिस्क के लिए सिंक नहीं की गई है।

तो मास्टर लॉग में पदों के बारे में आपकी जानकारी पुरानी है और आप पहले से ही संसाधित प्रश्नों को संसाधित कर रहे हैं जिनके साथ छोड़ दिया जाना चाहिए SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;।

दुर्भाग्य से, यदि आप कुछ प्रश्नों UPDATE table SET counter=counter+1 WHERE id = 12345का उपयोग binlog_format=STATEMENTकरते हैं जैसे और आपके डेटाबेस का उपयोग करना सिंक से बाहर जा सकता है, तो मुझे लगता है।

आप माई SQL सर्वर को हर घटना के बाद वेरिएबल सिंक_मास्टर_इनफो को सेट करके मास्टर.इनको सिंक करने के लिए कह सकते हैं, लेकिन इसका प्रदर्शन संभवतया बहुत बड़ा होगा।