MySQL लेनदेन जर्नलिंग

आप निश्चित रूप से यहां सही रास्ते पर हैं।

जब भी InnoDB कोई लेन-देन करता है जिसे प्रतिबद्ध करना होता है, तो इसे दो-चरण की प्रतिबद्धता के रूप में किया जाता है। इन लॉग में पहले लेन-देन लिखा जाता है। फिर, वे वहां से प्रतिबद्ध हैं।

यह MySQL क्रैश या सर्वर क्रैश की स्थिति में बहुत मदद करता है।

जब आप mysql को पुनरारंभ करते हैं, तो ib_logfile0 और ib_logfile1 में सभी अप्रतिबद्ध प्रविष्टियों को InnoDB की क्रैश रिकवरी के हिस्से के रूप में फिर से चलाया जाता है ताकि InnoDB को एक सामंजस्यपूर्ण स्थिति में लाया जा सके (यह एसिड अनुपालन )

यदि आप ib_logfile0 और ib_logfile1 को हटाते हैं और mysql प्रारंभ करते हैं, तो उन फ़ाइलों में निहित कोई भी अप्रतिबद्ध लेनदेन खो जाता है। क्रैश पुनर्प्राप्ति चक्र के दौरान, यदि लॉग फ़ाइलें अनुपलब्ध हैं, तो उन्हें innodb_log_file_size सेटिंग।

विस्तृत जानकारी के लिए कृपया MySQL दस्तावेज़ देखें। InnoDB की व्याख्या ।

@karatedog InnoDB का MVCC हिस्सा सिस्टम टेबलस्पेस के भीतर होता है, जिसे ibdata1 के रूप में जाना जाता है। लेन-देन शुरू होने से पहले जो भी डेटा दिखाई देता है, उसे रिकॉर्ड किया जाता है ताकि किसी भी अपडेट को लागू करने से पहले आवश्यक पंक्तियों तक पहुंचने वाले अन्य लोगों को डेटा देखने की अनुमति मिल सके। यह एक दोहराने योग्य-पढ़ने के लिए अनुमति देता है। यह एसीआईडी अनुपालन I के अंतर्गत आता है, जिसका अर्थ है अलगाव। मैंने इसके बारे में डीबीए स्टैक एक्सचेंज में विभिन्न परिदृश्यों के संबंध में पोस्ट लिखी हैं जहां लेनदेन अलगाव अच्छा, बुरा या बदसूरत है।

MyISAM के लिए, क्रैश रिकवरी स्वचालित नहीं है। यह काफी आसानी से क्रैश हो जाता है . इसलिए SQL कमांड REPAIR TABLE मौजूद। यही कारण है कि MySQL उपयोगिता myisamchk इसमें -r है REPAIR TABLE करने का विकल्प MyISAM तालिकाओं के लिए जो ऑनलाइन नहीं हैं।

MariaDB और Aria MyISAM के प्रतिस्थापन के रूप में क्रैश-सुरक्षित स्टोरेज इंजन बनाने का प्रयास किया गया है।