क्या innodb_flush_log_at_trx_commit = 2 का उपयोग करना सुरक्षित है

Question

मैंने मुड़कर innodb_flush_log_at_trx_commit = 2बहुत तेज गति लिखी। लेकिन क्या यह उत्पादन वेब साइट में सुरक्षित है?

Answer 1

आप एक सेकंड के लेन-देन के लिए खो सकते हैं। डिफ़ॉल्ट मान 1 है, जो InnoDB ACID अनुरूप रखने में मदद करता है ।

MySQL प्रलेखन के अनुसार innodb_flush_log_at_trx_commit पर

यदि innodb_flush_log_at_trx_commit का मान 0 है, तो लॉग बफ़र लॉग फ़ाइल के लिए प्रति सेकंड एक बार लिखा जाता है और लॉग फ़ाइल पर फ़्लश टू डिस्क ऑपरेशन किया जाता है, लेकिन लेनदेन पर कुछ भी नहीं किया जाता है। जब मान 1 (डिफ़ॉल्ट) होता है, तो लॉग बफर को प्रत्येक ट्रांजेक्शन कमिट में लॉग फाइल पर लिखा जाता है और लॉग फाइल पर फ्लश टू डिस्क ऑपरेशन किया जाता है। जब मान 2 होता है, तो लॉग बफर प्रत्येक फ़ाइल पर फ़ाइल के बाहर लिखा जाता है, लेकिन इस पर फ्लश टू डिस्क ऑपरेशन नहीं किया जाता है। हालाँकि, लॉग फ़ाइल पर फ़्लशिंग प्रति सेकंड एक बार भी होता है जब मान 2 होता है। ध्यान दें कि प्रक्रिया शेड्यूलिंग मुद्दों के कारण, प्रति सेकंड फ़्लशिंग हर सेकंड होने की 100% गारंटी नहीं है।

पूर्ण ACID अनुपालन के लिए 1 का डिफ़ॉल्ट मान आवश्यक है। आप 1 से भिन्न मान सेट करके बेहतर प्रदर्शन प्राप्त कर सकते हैं, लेकिन फिर आप एक दुर्घटना में एक सेकंड के लेन-देन तक खो सकते हैं। 0 के मान के साथ, कोई भी mysqld प्रक्रिया क्रैश लेन-देन के अंतिम सेकंड को मिटा सकता है। 2 के मान के साथ, केवल एक ऑपरेटिंग सिस्टम क्रैश या पावर आउटेज लेनदेन के अंतिम सेकंड को मिटा सकता है। InnoDB का क्रैश रिकवरी मूल्य की परवाह किए बिना काम करता है।

लेनदेन के साथ InnoDB का उपयोग कर एक प्रतिकृति सेटअप में सबसे बड़ी संभव स्थायित्व और स्थिरता के लिए, अपने मास्टर सर्वर my.cnf फ़ाइल में innodb_flush_log_at_trx_commit = 1 और Sync_binlog = 1 का उपयोग करें।

सावधान

कई ऑपरेटिंग सिस्टम और कुछ डिस्क हार्डवेयर फ्लश-टू-डिस्क ऑपरेशन को मूर्ख बनाते हैं। वे mysqld को बता सकते हैं कि फ्लश हुआ है, भले ही यह नहीं हुआ है। तब लेनदेन की स्थायित्व की सेटिंग 1 के साथ भी गारंटी नहीं दी जाती है, और सबसे खराब स्थिति में एक बिजली आउटेज भी InnoDB डेटाबेस को दूषित कर सकता है। SCSI डिस्क कंट्रोलर या डिस्क में ही बैटरी-समर्थित डिस्क कैश का उपयोग करने से फ़ाइल फ्लश की गति बढ़ जाती है, और ऑपरेशन सुरक्षित हो जाता है। आप हार्डवेयर कैश में लिखी गई डिस्क के कैशिंग को अक्षम करने के लिए यूनिक्स कमांड hdparm का उपयोग करने का भी प्रयास कर सकते हैं, या हार्डवेयर विक्रेता के लिए कुछ अन्य कमांड का उपयोग कर सकते हैं।

इसके आधार पर, 1 सेकंड के अलावा अन्य मूल्यों में 1 सेकंड के लेन-देन, या लेन-देन के कमिट के डेटा के खोने का खतरा होता है।

प्रलेखन भी उपयोग कहते हैं sync_binlog=1।

MySQL प्रलेखन के अनुसार Sync_binlog पर

1 का एक मूल्य सबसे सुरक्षित विकल्प है क्योंकि दुर्घटना की स्थिति में आप बाइनरी लॉग से अधिकांश एक बयान या लेन-देन में खो जाते हैं। हालांकि, यह सबसे धीमा विकल्प है (जब तक कि डिस्क में बैटरी-समर्थित कैश न हो, जो सिंक्रनाइज़ेशन को बहुत तेज करता है)।

आपकी सबसे सुरक्षित पसंद है

[mysqld]
innodb_flush_log_at_trx_commit=1
sync_binlog=1

यदि आप संभावित डेटा हानि (1 सेकंड के मूल्य तक) का बुरा नहीं मानते हैं, तो आप अपने जोखिम पर 0 या 2 का उपयोग कर सकते हैं यदि पुरस्कार (तेज लिखने की गति) इसके लायक हैं।

Comments

रोलैंडो: +1 अंतिम कुछ पंक्तियों के लिए Sync_binlog = 1 ...

— अब्दुल

@ अब्दुलमनाफ, हमेशा गति से डेटा अखंडता के लिए जाना। यदि आप डेटा अखंडता के लिए गति का त्याग करना चाहते हैं, तो आप खुद को डेटा समस्याओं से निपटने के लिए अधिक समय खो देंगे।

— पचेरियर

@RolandoMySQLDBA, "लेन-देन के एक दूसरे के मूल्य को खोने" से, क्या आपका मतलब है कि एक सफल commit वास्तव में खो सकता है?

— पचेरियर

पेसियर, हाँ। डेटा केवल "डिस्क से फ्लश" होने के बाद डिस्क पर लिखे जाने की गारंटी है। तब तक यह रैम मैमोरी में ही हो सकता है।

— एमिल विक्रोस्टम

@RolandoMySQLDBA आप आदमी हैं, गंभीरता से। यदि आप पूर्णकालिक mysql कंसल्टेंसी गिग्स के अलावा कुछ भी करते हैं, तो आपको संभवतः अपना कैरियर मार्ग बदलना चाहिए।

— जज

Answer 2

इस innodb_flush_log_at_trx_commitउद्देश्य के साथ प्रयोग किया जाता है ..

यदि मान innodb_flush_log_at_trx_commit 0 है, तो लॉग बफ़र लॉग फ़ाइल के लिए प्रति सेकंड एक बार लिखा जाता है और लॉग फ़ाइल पर फ़्लश टू डिस्क ऑपरेशन किया जाता है, लेकिन लेन-देन प्रतिबद्ध पर कुछ भी नहीं किया जाता है।

जब मान 1 (डिफ़ॉल्ट) होता है, तो लॉग बफर को प्रत्येक ट्रांजेक्शन कमिट में लॉग फाइल पर लिखा जाता है और लॉग फाइल पर फ्लश टू डिस्क ऑपरेशन किया जाता है।

जब मान 2 होता है, तो लॉग बफर प्रत्येक फ़ाइल पर फ़ाइल के बाहर लिखा जाता है, लेकिन इस पर फ्लश टू डिस्क ऑपरेशन नहीं किया जाता है। हालाँकि, लॉग फ़ाइल पर फ़्लशिंग प्रति सेकंड एक बार भी होता है जब मान 2 होता है। ध्यान दें कि प्रक्रिया शेड्यूलिंग समस्याओं के कारण, प्रति सेकंड फ़्लशिंग हर सेकंड होने की 100% गारंटी नहीं है।

पूर्ण ACID अनुपालन के लिए 1 का डिफ़ॉल्ट मान आवश्यक है। आप 1 से भिन्न मान सेट करके बेहतर प्रदर्शन प्राप्त कर सकते हैं, लेकिन फिर आप एक दुर्घटना में एक सेकंड के लेन-देन तक खो सकते हैं। 0 के मान के साथ, कोई भी mysqld प्रक्रिया क्रैश लेन-देन के अंतिम सेकंड को मिटा सकता है। 2 के मान के साथ, केवल एक ऑपरेटिंग सिस्टम क्रैश या पावर आउटेज लेनदेन के अंतिम सेकंड को मिटा सकता है। InnoDB का क्रैश रिकवरी मूल्य की परवाह किए बिना काम करता है।

मेरी राय innodb_flush_log_at_trx_commitमें 2 का उपयोग करना एक मुद्दा नहीं होना चाहिए। लेकिन 1 का उपयोग करना सबसे सुरक्षित है।

Comments

मैंने सिर्फ यह देखा कि आपने अनिवार्य रूप से एक ही उत्तर के साथ मेरे बाद केवल १ after सेकंड का उत्तर दिया। +1 !!!

— RolandoMySQLDBA

Answer 3

मेरी राय दूसरे से अलग है। innodb_flush_log_at_trx_commit = 0 यदि: यह मेरा विकास कंप्यूटर या होम मिनी डेटाबेस है जहाँ कोई संवेदनशील डेटा नहीं है।

innodb_flush_log_at_trx_commit = 2 यदि: यह ब्लॉग / आँकड़े / ई-कॉमर्स (दिन में ~ 100x दुकान के साथ), आदि है।

innodb_flush_log_at_trx_commit = 1 if: यदि आपके पास बहुत सारे ग्राहक हैं या आपको बैंक जैसे पैसे के लेनदेन के साथ काम करने की आवश्यकता है। इसलिए इस बार आपको गति और सुरक्षा के लिए कई सर्वरों के बीच अपने डेटाफ़्लो को विभाजित करना चाहिए।

मैं 2 पसंद करता हूं, क्योंकि इसमें ~ 75x तेज गति लिखी गई है और यह केवल विफल रहता है यदि हार्डवेयर विफल रहता है।

वैसे भी आपको पता होना चाहिए कि आपको अधिक लिखने की गति या 1 सेकंड की जानकारी तक और क्या चाहिए?

Comments

+1 के लिए75x faster write speed and it fails ONLY if hardware fails.

— नमन गाला

75 गुना तेज? प्रशस्ति पत्र की जरूरत।

— पचेरियर

मेरा अपना बेंचमार्क: 5000 के UPDATEसाथ innodb_flush_log_at_trx_commit = 1: 179 सेकंड। के साथ innodb_flush_log_at_trx_commit = 2: 1.12 सेकंड। यह मेरे मामले में १६० गुना तेज गति है।

— केविन

अच्छा उत्तर। सोचने वाली बात यह है कि - यदि आपकी मशीन सफल लेनदेन के बाद दुर्घटनाग्रस्त हो जाती है, तो संभावना है कि लेनदेन को डिस्क के साथ innodb_flush_log_at_trx_commit = 2 के साथ नहीं लिखा गया था , और फिर भी सफलता आपके आवेदन को इंगित की गई (यानी mykqld एक नेटवर्क पैकेट भेजने का प्रबंधन करता है जो लेनदेन को सफलतापूर्वक इंगित करता है। आपके ऐप में ड्राइवर), वह मौका बहुत कम है

— व्लादिस्लाव वैंट्रॉब

आपके द्वारा निर्दिष्ट करके अपने जवाब imrove कर सकते हैं डॉक्स क्या मतलब हैcrash

— शरीफ

Answer 4

मैं जवाब देने की कोशिश कर रहा हूं, इसका उद्देश्य क्या है innodb_flush_log_at_trx_commit?

InnoDB अपने अधिकांश ऑपरेशन मेमोरी ( InnoDB Buffer Pool) में करता है। अल संशोधित डेटा InnoDB transaction log fileटिकाऊ भंडारण (हार्ड डिस्क) के लिए लिखा और फिर फ्लश (लिखित) किया जाता है।

डेटा सुरक्षा ( Durability from ACID) के लिए, InnoDB को प्रत्येक लेनदेन के संशोधित डेटा को स्थायी भंडारण में संग्रहीत करना है। एक ही समय में, प्रत्येक लेनदेन के लिए डिस्क के लिए प्रतिबद्ध महंगा प्रक्रिया है।

डिस्क I / O एक अवरोधक प्रक्रिया है और यह बहुत धीमी है, यह एक धीमी डिस्क है, आगे यह InnoDB transaction per seconds(डिस्क विवादास्पद) की संख्या को कम कर देगी ।

InnoDB प्रदान करता है, innodb_flush_log_at_trx_commitइस फ्लश ऑपरेशन की आवृत्ति को नियंत्रित करने के लिए चर। मूल्य के आधार पर, InnoDB फ्लश ऑपरेशन अलग तरह से व्यवहार करता है।

(पहले से ही अन्य उत्तरों में समझाया गया है)

0 - लॉग फ़ाइल में लिखें और डिस्क को हर सेकंड पर फ्लश करें (डेटा बफर पूल में लॉग फ़ाइल के लिए नहीं लिखा गया है - प्रदर्शन लाभ के लिए)। 1 - लेन-देन शुरू होने पर डिस्क में फ्लश करें - डिफ़ॉल्ट (डेटा सुरक्षा के लिए - एसीआईडी ​​अनुपालन) 2 - प्रत्येक लेनदेन के लिए लॉग फ़ाइल में लिखें और हर सेकंड में डिस्क पर फ्लश करें। (प्रदर्शन लाभ के लिए)

आवेदन की आवश्यकता ( Performance Vs data safety) पर निर्भर करता है , आप इस चर को सेट कर सकते हैं। 0 और 2 के बीच का अंतर - दोनों प्रदर्शन में वृद्धि करेंगे, मूल्य 2 लेनदेन फ़ाइल में डेटा को संग्रहीत करता है और दुर्घटना या विफलता के मामले में पुनर्प्राप्त करने योग्य हो सकता है, लेकिन 0 में नहीं।

कई मामलों में, फ्लश टू डिस्क मतलब है, डेटा को InnoDB buffer pool (memory) to Operating systems cacheवास्तव में स्टोरेज डिस्क (स्थायी भंडारण) से नहीं लिखा जाता है। मामले में विफलता, सबसे खराब स्थिति में, आप एक सेकंड तक डेटा खो सकते हैं)

प्रदर्शन का लाभ पर्यावरण पर निर्भर करता है और आप बेंचमार्क और पहचान कर सकते हैं। एक प्रतिकृति वातावरण में, डेटा सुरक्षा और स्थिरता, सेट innodb_flush_log_trx_commit = 1और के लिए sync_binlog=1।

यदि प्रदर्शन एप्लिकेशन का मुख्य लक्ष्य है, तो InnoDB लॉग फ्लशिंग की आवृत्ति को नियंत्रित करने के लिए एक चर प्रदान करता है - innodb_flush_log_at_timeout- जो आपको लॉग फ्लशिंग आवृत्ति रेंज को सेट करने की अनुमति देता है 1 to 2700 seconds, डिफ़ॉल्ट रूप से यह 1 है।

जागरूक रहें, जब आप एन सेकंड तक फ्लशिंग अंतराल बढ़ाते हैं, तो प्रदर्शन लाभ एन सेकंड तक डेटा सुरक्षा में समझौता के साथ आता है। उदाहरण के लिए - यदि आप हर 5 सेकंड पर फ्लशिंग सेट करते हैं - थ्रूपुट का लाभ बहुत अधिक है, लेकिन बिजली की विफलता या सिस्टम क्रैश के मामले में, आप 5 सेकंड के लिए डेटा खो देंगे।

इस लेख में InnoDB निस्तब्धता और लेनदेन प्रतिबद्ध कार्यों के बारे में चर्चा की गई है।

Aws rds पर मोड 2 करने के बाद आप बदल सकते हैं:

कुछ मामलों में असंबद्ध जैसे कि यदि आपके पास प्रतिकृति मल्टी एज है:

Answer 5

यदि आपका हार्डवेयर विफल हो जाता है, तो आप अपने सभी डेटा को ढीला कर सकते हैं, इसलिए मैं बिना किसी चिंता के param = 2 का उपयोग करता हूं। वैसे भी आप 2 डीबी सर्वर के बीच संवेदनशील (आदेश, आभासी धन, ...) और नियमित (सांख्यिकी, कार्ट, ...) डेटा को विभाजित कर सकते हैं और उन्हें सुरक्षित और तेज़ रख सकते हैं। डेटाबेस के बीच लेनदेन के लिए आप http://dev.mysql.com/doc/refman/5.7/en/xa.html का उपयोग कर सकते हैं

Comments

"अपना सारा डेटा खो दें", या क्या आपका मतलब है कि लेनदेन पिछले कुछ सेकंड में हो रहे थे?

— नीक न्यूमैन

एक हार्डवेयर विफलता का मतलब हो सकता है कि पूरी हार्ड ड्राइव खो जाना, इसलिए "अपना सारा डेटा खो दें"। इसलिए जब तक आपके पास एक प्रतिकृति सेटअप नहीं होता है, तब तक आपका डेटा इस बात की दया पर होता है कि आप कितनी भी बार बैकअप करते हैं, इसलिए यह उत्तर जो बिंदु बना रहा है वह यह है कि एक या दो खोए हुए डेटा की तुलना में चिंता की कोई बात नहीं है

— thomasrutter