शुरू करने के लिए...
http://yoshinorimatsunobu.blogspot.com/2009 /08/great-performance-effect-of-fixing.html
InnoDB प्लगइन 1.0.4 से पहले, यह ऐसा था:
obtain mutex
write innodb log and fsync, for prepare-phase (skip if innodb_support_xa=0)
write binlog (fsync as appropriate if sync_binlog > 0)
write innodb log and fsync, for commit-phase
release mutex
InnoDB प्लगइन 1.0.4 (और MySQL 5.5) पर और बाद में, यह अब है:
write innodb log and fsync, for prepare-phase (skip if innodb_support_xa=0)
obtain mutex
write binlog (fsync as appropriate if sync_binlog > 0)
write innodb log, for commit-phase
release mutex
fsync innodb log, for commit-phase
जैसा कि आप देख सकते हैं, नए संस्करण में, कुछ भी नहीं (सिवाय sync_binlog . के मामले में)> 0) क्रिटिकल सेक्शन में fsync'd है। इस तरह, ग्रुप कमिट अब काम करता है और बेहतर समवर्ती थ्रूपुट सुनिश्चित करता है।
उदाहरण के लिए, पिछले "टूटे हुए" संस्करण के साथ, यदि आपके पास 100 थ्रेड समवर्ती कमिट थे, तो सभी fsyncs को क्रमबद्ध किया गया था और आपको 100 fsyncs तैयार करने के लिए और अन्य 100 fsyncs कमिट करने के लिए मिलेंगे। इसलिए ग्रुप कमिटमेंट पूरी तरह से टूट गया।
अब नए कार्यान्वयन के साथ, fsyncs को लेन-देन की समरूपता के आधार पर समूहीकृत किया जाता है, जबकि innodb लॉग और बिनलॉग के बीच ऑपरेशन ऑर्डरिंग सुनिश्चित करता है। इसका यह भी अर्थ है कि यदि केवल एक धागा है, तो कोई प्रदर्शन लाभ नहीं है।
आपके प्रश्न के अनुसार, जब बिनलॉग में लेन-देन लिखे जाने के बाद दुर्घटना होती है, लेकिन लेन-देन लॉग में लिखे जाने से पहले - मैं आपके समान पृष्ठ पर हूं।
यदि सर्वर अंतिम चरण से पहले दुर्घटनाग्रस्त हो जाता है, तो इस बात की थोड़ी बहुत संभावना है कि आपके पास innodb लॉग और बिनलॉग (या तो एक दूसरे से आगे हो सकता है) के बीच एक विसंगति है, लेकिन यह गारंटी है कि आपके पास सभी जानकारी है कि क्या करना है जांच करें इनोडब लॉग में, जैसा कि तैयारी-चरण में दर्ज किया गया है।
हालांकि, अप्रतिबद्ध के साथ क्या करना है यह अभी भी तय नहीं है। उदाहरण के लिए, जब तक sync_binlog = 1 एक मौका है कि एक दास ने डेटा प्राप्त किया लेकिन अभी तक मास्टर पर बिनलॉग को पूरी तरह से fsync'd नहीं किया है। आप असफल लेन-देन को फिर से नहीं कर सकते क्योंकि यह पहले से ही दासों में से एक पर चल सकता है।
जिसका अर्थ यह भी है कि बिनलॉग इनोडब लॉग से छोटा हो सकता है, "बाइनरी लॉग [file_name] इसके अपेक्षित आकार से छोटा है।" जैसा कि आधिकारिक दस्तावेज़ में वर्णित है, और आपको दास को खरोंच से पुनर्निर्माण करना होगा। बहुत मानवीय मित्रवत नहीं।
http://dev.mysql.com/doc/refman /5.1/hi/binary-log.html
चूंकि ऑपरेशन ऑर्डरिंग के मामले में निरंतरता की गारंटी innodb_support_xa . से स्वतंत्र है सेटिंग (जो innodb_support_xa पर आधिकारिक दस्तावेज़ में कही गई बातों के विपरीत है , हो सकता है क्योंकि यह समवर्ती फिक्स से बहुत पहले स्टॉक इनोडब 5.0.3 के बारे में लिखा गया था), और मास्टर पर इनोडब लॉग और दास पर रिले लॉग के बीच स्थिरता की गारंटी innodb_support_xa के साथ भी नहीं है। , मुझे innodb_support_xa . का उपयोग करने का कोई मतलब नहीं दिखता . हालांकि, आधिकारिक अनुशंसा का पालन न करना डरावना है, हालांकि यह कई बिंदुओं पर बासी और गलत लगता है।
मैं सोच रहा हूं कि innodb_flush_log_at_trx_commit के बीच कोई संबंध है या नहीं सेटिंग और innodb_support_xa व्यवहार जब पूर्व को 2 या 0 पर सेट किया जाता है।
सोचने का एक व्यावहारिक तरीका यह है कि, दास के लिए विफलता सुरक्षित है - आखिरकार, असफल लेन-देन कुछ ऐसा था जिसे आप करना चाहते थे - लेकिन मास्टर के पास कभी भी असफल न हों, क्योंकि डेटा में कुछ विसंगति हो सकती है। मास्टर को नया दास बनाने से पहले, आपको दास से डेटा को पूरी तरह से कॉपी करना होगा। दूसरे शब्दों में, जब मास्टर दुर्घटनाग्रस्त हो गया, तब से दास पर भरोसा करें - इस तरह, आपको क्रैश पुनर्प्राप्ति के लिए innodb लॉग के साथ गड़बड़ करने की आवश्यकता नहीं है।
यह भी ध्यान दें कि MySQL 5.5 सेमी-सिंक्रोनस प्रतिकृति का समर्थन करता है, उसी पंक्ति के साथ जैसे "ट्रस्ट द स्लेव" - सोचा कि आपकी रुचि हो सकती है।
http://dev.mysql.com/doc/refman /5.5/hi/replication-semisync.html
