2010-08-27 9 views
5

SQLite documentation में संस्करण 3.7 में प्रस्तुत लिखने-आगे-लॉग सुविधा पर, कुछ टिप्पणियां हैं जो मुझे थोड़ा उलझन में डालती हैं।बिजली विफलताओं पर SQLite WAL कितना सुरक्षित है?

लिंक किए गए पृष्ठ का कहना है कि "डिस्क पर सामग्री को समन्वयित करने की आवश्यकता नहीं है, जब तक कि एप्लिकेशन बिजली के नुकसान के बाद स्थायित्व बलिदान के लिए तैयार हो।" फिर कुछ अनुच्छेद नीचे दिए गए हैं, यह कहता है "पावर लॉस या हार्ड रीबूट के बाद डेटाबेस भ्रष्टाचार की संभावना से बचने के लिए चेकपॉइंटिंग को सिंक ऑपरेशंस की आवश्यकता होती है।"

तो मेरा डेटाबेस बिजली के नुकसान पर भ्रष्टाचार के अधिक जोखिम पर है अगर मैं वाल का उपयोग करें?

उत्तर

4

वहाँ वाल के साथ भ्रष्टाचार का कोई जोखिम के बढ़ने (क्योंकि यह सिंक के संचालन का उपयोग करता है जब checkpointing), अगर वहाँ एक दुर्घटना (बिजली हानि या हार्ड रिबूट) यदि आप किसी भी खो देंगे है।

हालांकि अंतिम चेकपॉइंट के बाद लेनदेन; इसका मतलब है "स्थायित्व बलिदान"।

+3

मुझे पता है कि यह उत्तर पुराना है, लेकिन इसमें इसकी एक महत्वपूर्ण त्रुटि है। अंतिम चेकपॉइंट के बाद से आप लेनदेन नहीं खोलेंगे, आप लेनदेन खो देंगे जो अभी तक डब्ल्यूएएल को पूरी तरह से लिखे गए नहीं हैं। यदि तुल्यकालिक = सामान्य, यह WAL पर लेनदेन लिखते समय fsync() की प्रतीक्षा नहीं करता है, तो यदि आप पूरी तरह लिखे जाने से पहले पावर खो देते हैं तो आप उस लेनदेन को खो सकते हैं। एक बार यह वाल में हो जाने पर, चेकपॉइंटिंग के बावजूद, यह खो नहीं जाएगा। –

+1

2016-02-17 तक https://www.sqlite.org/docsrc/info/3540d671bcc4835c SQLite प्रलेखन ने कहा कि WAL मोड में डिफ़ॉल्ट रूप से सिंक्रोनस = सामान्य ... यह अब सिंक्रोनस = पूर्ण - अधिक सुरक्षित डिफ़ॉल्ट कहता है। इसलिए, यदि आप सिंक्रोनस = सामान्य मोड सेट करते हैं तो आप केवल चेकपॉइंट से पहले लेनदेन खो देंगे –

5

पूरी तरह उत्तर देने के लिए, हमें यह जानने की जरूरत है कि आपके पास PRAGMA synchronous सेट है, क्योंकि यह fdatasync() कहलाता है और इस प्रकार जब बफर भौतिक ड्राइव पर निकलते हैं तो यह प्रभावित होता है।

जब आप उद्धरण देते हैं, "जब तक एप्लिकेशन बिजली की हानि के बाद स्थायित्व बलिदान देने के इच्छुक है", यह synchronous=NORMAL होने का जिक्र कर रहा है। यहां डब्ल्यूएएल केवल डिस्क पर सिंक्रनाइज़ किया जाता है जब चेकपॉइंटिंग होती है (WAL के लिए एक fdatasync() और विलय के बाद मुख्य डीबी के लिए एक)। आपको भ्रष्टाचार के खिलाफ बहुत अच्छी तरह से संरक्षित किया जाना चाहिए, लेकिन कुछ लिख सकते हैं जो इसे प्लेटर में कभी नहीं बनाते हैं और इस तरह खो जाते हैं: इसलिए खोया स्थायित्व। यद्यपि डेटा को वास्तव में सिंक करने के लिए धीमी fdatasync() की तुलना में उल्टा है।

डेटा खोने के खिलाफ सबसे अच्छा लचीलापन रखने के लिए, आप synchronous=FULL चाहते हैं। यह पुन: लाभ स्थायित्व है, लेकिन प्रति लेखन लेनदेन एक fdatasync() है। हालांकि, यह अभी भी गैर-वाल मोड से बेहतर है जहां दो fdatasync() कॉल होंगे - लेनदेन पत्रिका के लिए एक और मुख्य डीबी के लिए एक।

0

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

डौग क्यूरी को सही करने के लिए (मैटआर का पोस्ट देखें): यदि आप @ synchronous = NORMAL @ को केवल लेनदेन खोने का जोखिम उठाते हैं। यदि @ सिंक्रोनस = पूर्ण @ (जो डिफ़ॉल्ट है) तो आप स्थायित्व का त्याग नहीं करते हैं। इस पर अधिक जानकारी के लिए http://www.sqlite.org/draft/wal.html देखें।

मेरा मानना ​​है कि वाल जर्नलिंग वास्तव में 'क्लासिक' जर्नलिंग (अपूर्ण सिस्टम सिंक के मामले में) से अधिक सुरक्षित है, क्योंकि किसी भी क्षण में डीबी कुछ महत्वपूर्ण करता है, जहां तक ​​मैं वाल जर्नलिंग को समझता हूं। हालांकि वर्तमान में इसका समर्थन करने के लिए मेरे पास कोई कठोर डेटा नहीं है।

संबंधित मुद्दे