क्या max_allowed_packet काफी बड़ा है, और मुझे इसे बदलने की आवश्यकता क्यों है?


14

मेरे पास मास्टर-स्लेव सेटअप में MySQL (5.5) है और एक और दास सर्वर बनाया है।

मैंने मूल दास को रोका, डेटा को डंप किया, कॉपी किया और पुन: आयात किया और यह ठीक काम किया। मैंने मूल दास के मास्टर_लॉग नोट पर ध्यान दिया और इन आदेशों का उपयोग इसे नए दास पर सेट करने के लिए किया

CHANGE MASTER TO MASTER_HOST='<ipaddress>', 
MASTER_USER='<username>', MASTER_PASSWORD='<password>', 
MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000851', 
MASTER_LOG_POS=15824150, 
MASTER_CONNECT_RETRY=10;

जब मैंने नया दास शुरू किया तो मुझे मिला

Last_IO_Error: बाइनरी लॉग से डेटा पढ़ते समय मास्टर से घातक त्रुटि 1236 मिली: 'लॉग इवेंट प्रविष्टि max_allowed_packet से अधिक हो गई; मास्टर पर max_allowed_packet बढ़ाएँ '

हालाँकि जब मैंने मूल गुलाम की शुरुआत की, तो यह ठीक-ठाक पकड़ा, और अब सिंक में है।

तो सवाल:

  • वर्तमान मूल्य 16M है, मुझे कैसे पता चलेगा कि कितना बड़ा जाना है? (मैं नहीं बल्कि एक उत्पादन सर्वर के साथ परीक्षण और त्रुटि से बचना होगा)।

  • मूल गुलाम के ठीक ठीक होने पर मुझे गुरु पर मूल्य बढ़ाने की आवश्यकता क्यों है, क्या समस्या वास्तव में नए दास के साथ हो सकती है?

अपडेट करें

रोलांडो ने मास्टर, पुराने गुलाम और नए गुलाम का सुझाव दिया और उन्हें फिर से शुरू किया ( SET GLOBAL max_allowed_packet = 1073741824;जैसा कि किसी कारण से नहीं लगा)

अब अंतिम IO त्रुटि पहले की तरह ही है, लेकिन अब मैं देखता हूं

Last_SQL_Error: रिले लॉग रीड विफलता: रिले लॉग इवेंट प्रविष्टि पार्स नहीं कर सका। संभावित कारण हैं: मास्टर का बाइनरी लॉग दूषित है (आप बाइनरी लॉग पर 'mysqlbinlog' चलाकर इसकी जांच कर सकते हैं), दास का रिले लॉग दूषित है (आप रिले लॉग पर 'mysqlbinlog' चलाकर इसे चेक कर सकते हैं), नेटवर्क की समस्या, या मास्टर या दास के MySQL कोड में एक बग। यदि आप मास्टर के बाइनरी लॉग या दास के रिले लॉग की जांच करना चाहते हैं, तो आप इस दास पर 'SHOW SLAVE STATUS' जारी करके उनके नाम जान सकेंगे।

अगर मैं मास्टर की फाइल पर mysqlbinlog करता हूं, तो यह उम्र के लिए बहुत खुशी से आदेशों के साथ अतीत को स्क्रॉल करता है - फाइल 722M है - अगर मैं गुलाम रिले लॉग के लिए ऐसा करता हूं तो मुझे मिलता है

त्रुटि: Log_event में त्रुटि :: read_log_event (): 'Sanity check विफल', data_len: 38916267, event_type: 69

त्रुटि: ऑफसेट 253 पर प्रविष्टि नहीं पढ़ सका: लॉग प्रारूप में त्रुटि या त्रुटि पढ़ें।

मैंने चरों की जाँच की और परिवर्तनों ने काम किया

mysql> वैरिएबल दिखाएं LIKE '% max_allowed_packet%';

नए गुलाम पर दिखाया max_allowed_packetऔर slave_max_allowed_packetजहां गुरु के रूप में यह केवल हैmax_allowed_packet

इसलिए मैंने मास्टर पर एक संस्करण की जाँच की:

mysql> show variables LIKE '%version%';
+-------------------------+--------------------------------------+
| Variable_name           | Value                                |
+-------------------------+--------------------------------------+
| innodb_version          | 1.1.6                                |
| protocol_version        | 10                                   |
| slave_type_conversions  |                                      |
| version                 | 5.5.11-log                           |
| version_comment         | MySQL Community Server (GPL) by Remi |
| version_compile_machine | x86_64                               |
| version_compile_os      | Linux                                |
+-------------------------+--------------------------------------+

और नए गुलाम पर

mysql> show variables LIKE '%version%';
+-------------------------+--------------------------------------+
| Variable_name           | Value                                |
+-------------------------+--------------------------------------+
| innodb_version          | 5.5.32                               |
| protocol_version        | 10                                   |
| slave_type_conversions  |                                      |
| version                 | 5.5.32-log                           |
| version_comment         | MySQL Community Server (GPL) by Remi |
| version_compile_machine | x86_64                               |
| version_compile_os      | Linux                                |
+-------------------------+--------------------------------------+

क्या ये 2 संस्करण बहुत दूर हैं?


यहां कुछ बात दिलचस्प है । आशा है कि यह मददगार होगा।
सतीश डी।

जवाबों:


18

यह max_allowed_packet1G करने के लिए अधिकतम करने के लिए ठीक है । जब भी एक MySQL पैकेट का निर्माण किया जाता है, तो यह शुरू से 1G तक नहीं जाएगा। क्यों?

सबसे पहले आपको यह जानना होगा कि एक MySQL पैकेट क्या है। पुस्तक का पृष्ठ ९९

MySQL इंटरनेशनल को समझना

इसे पैराग्राफ 1-3 में समझाता है:

MySQL नेटवर्क कम्युनिकेशन कोड इस धारणा के तहत लिखा गया था कि प्रश्न हमेशा बहुत कम होते हैं, और इसलिए इसे सर्वर द्वारा एक चंक में भेजा और संसाधित किया जा सकता है, जिसे MySQL शब्दावली में एक पैकेट कहा जाता है । पैकेट को संग्रहीत करने के लिए सर्वर अस्थायी बफर के लिए मेमोरी आवंटित करता है, और यह इसे पूरी तरह से फिट करने के लिए पर्याप्त अनुरोध करता है। इस आर्किटेक्चर को सर्वर के मेमोरी से बाहर चलने से बचने के लिए एहतियात की आवश्यकता होती है --- पैकेट के आकार पर एक कैप, जिसे यह विकल्प पूरा करता है।

इस विकल्प के संबंध में रुचि का कोड sql / net_serv.cc में पाया जाता है । My_net_read () पर एक नज़र डालें , फिर my_real_read () पर कॉल का अनुसरण करें और net_realloc () पर विशेष ध्यान दें

यह चर कई स्ट्रिंग फंक्शन्स के परिणाम की लंबाई को भी सीमित करता है। विवरण के लिए sql / field.cc और sql / intem_strfunc.cc देखें।

MySQL प्रलेखन के साथ उस पर तुलना करें max_allowed_packet:

एक पैकेट या किसी भी उत्पन्न / मध्यवर्ती स्ट्रिंग, या mysql_stmt_send_long_data () C API फ़ंक्शन द्वारा भेजे गए किसी भी पैरामीटर का अधिकतम आकार। डिफ़ॉल्ट MySQL 5.6.6 के रूप में 4MB है, उससे पहले 1MB।

पैकेट संदेश बफ़र को net_buffer_length बाइट्स से प्रारंभ किया जाता है, लेकिन जरूरत पड़ने पर max_allowed_packet बाइट्स तक बढ़ सकता है। डिफ़ॉल्ट रूप से यह मान छोटा है, बड़े (संभवतः गलत) पैकेट को पकड़ने के लिए।

यदि आप बड़े BLOB कॉलम या लंबे तार का उपयोग कर रहे हैं, तो आपको यह मान बढ़ाना होगा। यह आपके द्वारा उपयोग किए जाने वाले सबसे बड़े BLOB जितना बड़ा होना चाहिए। Max_allowed_packet के लिए प्रोटोकॉल सीमा 1GB है। मान 1024 से अधिक होना चाहिए; नॉनम्यूटिपल्स निकटतम बहु के लिए गोल होते हैं।

जब आप max_allowed_packet चर के मान को बदलकर संदेश बफ़र का आकार बदलते हैं, तो आपको क्लाइंट साइड पर बफ़र आकार भी बदलना चाहिए यदि आपका क्लाइंट प्रोग्राम इसे अनुमति देता है। क्लाइंट की ओर, max_allowed_packet में 1GB का डिफ़ॉल्ट है। Mysql और mysqldump जैसे कुछ प्रोग्राम आपको कमांड लाइन पर या एक विकल्प फ़ाइल में max_allowed_packet सेट करके क्लाइंट-साइड मान को बदलने में सक्षम करते हैं।

इस जानकारी को देखते हुए, आपको खुशी होनी चाहिए कि MySQL विस्तार और आवश्यकतानुसार MySQL पैकेट का विस्तार करेगा। इसलिए, आगे बढ़ो और

  • max_allowed_packetमास्टर और गुलाम दोनों के लिए 1G पर सेट करें
  • net_buffer_lengthमास्टर और गुलाम दोनों पर 1M के अपने अधिकतम मूल्य पर सेट करें

मास्टर और दास को उन लोगों के संदर्भ में मेल खाना चाहिए जो वे डेटा प्रसारित करते हैं, विशेष रूप से बीएलओबी डेटा।

अद्यतन 2013-07-04 07:03 EDT

रिले लॉग के विषय में आपके संदेशों से, ऐसा लगता है कि आपके पास निम्नलिखित हैं

  • एक भ्रष्ट रिले लॉग
  • एक अच्छा मास्टर लॉग

सुझाव

SHOW SLAVE STATUS\G
STOP SLAVE;
CHANGE MASTER TO
MASTER_LOG_FILE='(Relay_Master_Log_File from SHOW SLAVE STATUS\G)',
MASTER_LOG_POS=(Exec_Master_Log_Pos from SHOW SLAVE STATUS\G);
START SLAVE;

रनिंग CHANGE MASTER TOसभी रिले लॉग को साफ़ करता है और एक नए के साथ शुरू होता है। आपको लास्ट मास्टर बिनलॉग इवेंट (बिनलॉग, पोजीशन) से दोहराया जाएगा जो दास पर निष्पादित किया गया था।

कोशिश करो !!!


धन्यवाद, यह बहुत अच्छा है कि यह सुरक्षित है; लेकिन मुझे अभी भी नहीं मिलता है कि मुझे इसे बदलने की आवश्यकता क्यों है जब वर्तमान मूल्य मास्टर से मेल खाता है, और दूसरा दास जो पूरी तरह से काम कर रहा है?
कोडमोनकी

कुछ और चल रहा है, मैंने और अधिक विवरण जोड़ दिए हैं
CodeMonkey

1
आपकी जानकारी के लिए: यह तब हुआ जब मैंने प्रतिकृति प्रक्रिया को रीसेट कर दिया और गलती से गलत MASTER_LOG_FILEनाम दर्ज कर लिया। जैसे mysql-bin.000001जब मुझे अंदर mysql-bin.000003से इस्तेमाल करना चाहिए SHOW MASTER STATUSथा CHANGE MASTER TO
मिको ओकटामा

8

बल्कि शर्मिंदगी के साथ समस्या लॉग के लिए गलत फाइलनाम थी, जिसके परिणामस्वरूप अजीब परिणाम थे, सही फ़ाइल नाम के साथ पुन: आयात किया गया और सब कुछ ठीक था शर्म की बात है


आपका बहुत बहुत धन्यवाद! इस गलती को करने वाले आप अकेले नहीं थे।
मिको ओकटामा

3
यह हमेशा मूर्खतापूर्ण होने पर भी उत्तर पोस्ट करने के लायक है। हर कोई मूर्खतापूर्ण गलतियाँ करता है जैसा कि हम सभी मानव हैं। हमारे अलावा जो रोबोट हैं।
जॉन हंट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.