आश्चर्य fsync () PostgreSQL

डीबीएमएस डेवलपर्स, आवश्यकता के आधार पर, चिंतित हैं कि डेटा सुरक्षित रूप से स्थायी भंडारण में आता है। इसलिए, जब PostgreSQL समुदाय को पता चला कि जिस तरह से कर्नेल I / O त्रुटियों को संभालता है, वह बिना किसी त्रुटि के उपयोगकर्ता स्थान पर रिपोर्ट किए बिना डेटा हानि हो सकती है, तो बहुत असंतोष पैदा हुआ। समस्या, जो इस तथ्य से बढ़ी है कि PostgreSQL आई / ओ को बफ़र करता है, लिनक्स के लिए अद्वितीय नहीं है, और वहां भी हल करना आसान नहीं होगा।

क्रेग रिंगर ने पहली बार मार्च के अंत में pgsql-hackers मेलिंग सूची में समस्या की सूचना दी । संक्षेप में, PostgreSQL मानता है कि एक सफल fsync() कॉल इंगित करता है कि अंतिम सफल कॉल के बाद से रिकॉर्ड किए गए सभी डेटा को लगातार भंडारण में सुरक्षित रूप से स्थानांतरित कर दिया गया था। जब हार्डवेयर त्रुटि के कारण बफ़र किया गया I / O लिखते हैं, तो फ़ाइल सिस्टम अलग तरह से प्रतिक्रिया करता है, लेकिन इस व्यवहार में आमतौर पर संबंधित पृष्ठों पर डेटा को हटाने और उन्हें साफ के रूप में चिह्नित करना शामिल होता है। इसलिए, पढ़ने वाले ब्लॉक जो केवल लिखे गए थे, सबसे अधिक संभावना कुछ और लौटाएंगे, लेकिन रिकॉर्ड किए गए डेटा नहीं।

त्रुटि रिपोर्टिंग के बारे में क्या? एक साल पहले, लिनक्स फाइल सिस्टम, स्टोरेज और मेमोरी-मैनेजमेंट समिट (एलएसएफएमएम) शिखर सम्मेलन में एक बग रिपोर्ट सत्र शामिल था, जिसमें इसे "गड़बड़" कहा गया था; त्रुटियों को आसानी से खो दिया जा सकता है, इसलिए कोई भी एप्लिकेशन उन्हें कभी नहीं देखेगा। 4.13 में शामिल कुछ पैच ने विकास चक्र के दौरान स्थिति को कुछ हद तक सुधार दिया (और 4.16 में इसमें और सुधार करने के लिए कुछ बदलाव किए गए थे), हालांकि, त्रुटि सूचनाओं को खोने के तरीके हैं, जैसा कि नीचे वर्णित है। यदि यह PostgreSQL सर्वर पर होता है, तो यह स्वचालित डेटाबेस भ्रष्टाचार को जन्म दे सकता है।

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

कहां कुछ गलत हुआ?

हालाँकि, कर्नेल समुदाय के चर्चा में आने से पहले ही, यह स्पष्ट हो गया था कि स्थिति इतनी सरल नहीं थी जितनी कि यह प्रतीत हो सकती है। थॉमस मुनरो ने कहा कि इस व्यवहार में लिनक्स अद्वितीय नहीं है; OpenBSD और NetBSD भी रिपोर्ट नहीं कर सकते हैं उपयोगकर्ता स्थान में त्रुटियाँ लिखें। और, जैसा कि यह निकला, जिस तरह से PostgreSQL ने बफ़र किए I / O ऑपरेशन को बहुत जटिल बना दिया है।

हास द्वारा इस तंत्र का विस्तार से वर्णन किया गया है । एक PostgreSQL सर्वर प्रक्रियाओं के एक सेट के रूप में काम करता है, जिनमें से कई डेटाबेस फ़ाइलों पर I / O प्रदर्शन कर सकते हैं। fsync() कॉल fsync() , हालांकि, एक एकल चेकपॉइंट ("चेकपॉइंट" प्रक्रिया) प्रक्रिया में संभाला जाता है, जो विफलताओं से उबरने के लिए एक सुसंगत स्थिति में डिस्क भंडारण रखने के बारे में है। चेकपॉइंट आमतौर पर सभी प्रासंगिक फाइलों को खुला नहीं रखता है, इसलिए इसे अक्सर fsync() कॉल करने से पहले फ़ाइल को खोलना fsync() । यह वह जगह है जहां समस्या उत्पन्न होती है: यहां तक ​​कि गुठली 4.13 और बाद के संस्करणों में, चेकपॉइंट को कोई भी त्रुटि नहीं दिखाई देगी जो फ़ाइल खोलने से पहले हुई थी। यदि open() कॉलिंग open() चेकपॉइंट-ए से पहले कुछ खराब होता है, तो fsync() लिए अगला कॉल सफलता लौटाएगा। fsync() बाहर I / O त्रुटि पैदा करने के कई तरीके हैं; उदाहरण के लिए, कर्नेल पृष्ठभूमि लिखने के दौरान उनमें से एक का सामना कर सकता है। किसी को कॉल sync() भी एक I / O त्रुटि का सामना कर सकता है और परिणामी त्रुटि स्थिति को "अवशोषित" कर सकता है।

हास ने इस व्यवहार को पोस्टग्रेक्यूएल की अपेक्षाओं को पूरा करने में असमर्थ बताया।

वह सब जो आप (या कोई) मूल रूप से एक अप्रमाणित धारणा है
कौन सी फाइल डिस्क्रिप्टर एक विशेष त्रुटि के लिए प्रासंगिक हो सकती है, लेकिन यह इतना हुआ कि पोस्टग्रेक्यूएल ने इसका मिलान कभी नहीं किया। आप यह कहना जारी रख सकते हैं कि समस्या हमारे अनुमानों में है, लेकिन मेरे लिए यह मानना ​​गलत है कि हम केवल एक ही कार्यक्रम है जो कभी उन्हें किया है।

परिणामस्वरूप, यहोशू ड्रेक ने बातचीत को ext4 के लिए विकास सूची में स्थानांतरित कर दिया , जिसमें कर्नेल विकास समुदाय का हिस्सा भी शामिल है। डेव चिनर ने इस व्यवहार को जल्दी से " आपदा के लिए एक नुस्खा, विशेष रूप से क्रॉस-प्लेटफ़ॉर्म कोड में वर्णित किया , जहां प्रत्येक ओएस प्लेटफ़ॉर्म अलग तरीके से व्यवहार करता है और लगभग कभी भी मेल नहीं खाता है जो अपेक्षित था ।" इसके बजाय, टेड त्सो ने बताया कि क्यों प्रभावित पृष्ठों को I / O त्रुटि के बाद स्वच्छ के रूप में चिह्नित किया जाता है; संक्षेप में, I / O त्रुटियों का सबसे आम कारण है जब उपयोगकर्ता गलत समय पर USB ड्राइव को निकालता है। यदि एक प्रक्रिया ने इस डिस्क पर बहुत सारे डेटा की प्रतिलिपि बनाई है, तो परिणाम मेमोरी में गंदे पृष्ठों का संचय होगा, संभवतः इस बिंदु पर कि सिस्टम में अन्य कार्यों के लिए पर्याप्त मेमोरी नहीं है। इस प्रकार, इन पृष्ठों को सहेजा नहीं जा सकता है और साफ कर दिया जाएगा कि क्या उपयोगकर्ता इस तरह की घटना के बाद सिस्टम को प्रयोग करने योग्य बनाए रखना चाहता है।

चिनर और त्सो, दोनों ने, दूसरों के साथ, पोस्टग्रेक्सेल ने कहा कि इसका सही समाधान है - स्विच I / O (DIO)। डीआईओ का उपयोग राइटबैक और आई / ओ पर सामान्य रूप से नियंत्रण का एक बड़ा स्तर देता है; इसमें उन सूचनाओं तक पहुंच शामिल है जिनके बारे में I / O संचालन विफल हो सकता है। कई पोस्टग्रेक्सेल डेवलपर्स की तरह, एंड्रेस फ्रायंड ने स्वीकार किया कि डीआईओ सबसे अच्छा दीर्घकालिक समाधान है। लेकिन उन्होंने यह भी कहा कि किसी को डेवलपर्स से इस कार्य के कार्यान्वयन में गहराई से उतरने की उम्मीद नहीं करनी चाहिए। इस बीच, उन्होंने कहा कि अन्य कार्यक्रम हैं (उन्होंने dpkg का उल्लेख किया) जो इस व्यवहार के लिए भी प्रवण हैं।

एक अल्पकालिक समाधान की ओर

चर्चा के दौरान, इस विचार पर काफी ध्यान दिया गया था कि एक लेखन विफलता इस तथ्य को जन्म दे सकती है कि प्रभावित पृष्ठों को उनकी गंदी स्थिति में स्मृति में संग्रहीत किया जाएगा। लेकिन PostgreSQL डेवलपर्स जल्दी से इस विचार से दूर चले गए और इसकी मांग नहीं की। क्या वे वास्तव में की जरूरत है अंततः पता लगाने के लिए एक विश्वसनीय तरीका है अगर कुछ गलत हो गया। इसे ध्यान में रखते हुए, सामान्य PostgreSQL त्रुटि हैंडलिंग तंत्र इसे संभाल सकता है; हालाँकि, उसकी अनुपस्थिति में बहुत कम किया जा सकता है।

चर्चा के कुछ बिंदु पर, त्सो ने उल्लेख किया कि Google का अपना I / O त्रुटि हैंडलिंग तंत्र है। कर्नेल को netlink सॉकेट के माध्यम से I / O त्रुटियों की रिपोर्ट करने का निर्देश दिया गया था; समर्पित प्रक्रिया इन सूचनाओं को प्राप्त करती है और तदनुसार प्रतिक्रिया करती है। फिर भी इस तंत्र ने प्रवेश द्वार पर ऐसा नहीं किया। Freind ने बताया कि यह तंत्र PostgreSQL के लिए "आदर्श" होगा, इसलिए यह निकट भविष्य में सार्वजनिक डोमेन में दिखाई दे सकता है।

इस बीच, जेफ लीटन एक और विचार के बारे में सोच रहा था: जब I / O त्रुटि होती है, तो फ़ाइल सिस्टम के सुपरब्लॉक में एक ध्वज सेट करना। तब syncfs() लिए एक कॉल इस झंडे को साफ कर देगा और यदि यह सेट किया गया था तो एक त्रुटि लौटाएगा। PostgreSQL चेकपॉइंट समय-समय पर syncfs() को कॉल कर सकता है ताकि डेटाबेस वाले फाइल सिस्टम पर त्रुटियों के लिए पोल किया जा सके। फ्रंड ने सहमति व्यक्त की कि यह समस्या का एक व्यवहार्य समाधान हो सकता है।

बेशक, कोई भी ऐसा तंत्र केवल नई गुठली में दिखाई देगा; इस बीच, PostgreSQL स्थापना आमतौर पर उद्यम वितरण द्वारा समर्थित पुराने कर्नेल पर चलती है। इन गुठली में, ऐसा लगता है कि वे भी सुधार नहीं हैं जो 4.13 में शामिल किए गए थे। इन प्रणालियों के लिए, PostgreSQL I / O त्रुटियों का पता लगाने में मदद करने के लिए बहुत कम किया जा सकता है। यह एक डेमॉन शुरू करने के लिए पर्याप्त हो सकता है जो सिस्टम लॉग को स्कैन करता है और वहां I / O त्रुटि संदेशों की तलाश करता है। सबसे सुरुचिपूर्ण समाधान नहीं है, और यह इस तथ्य से जटिल है कि विभिन्न ब्लॉक ड्राइवर और फाइल सिस्टम, एक नियम के रूप में, विभिन्न तरीकों से त्रुटियों की रिपोर्ट करते हैं, लेकिन यह सबसे अच्छा विकल्प उपलब्ध हो सकता है।

अगले चरण में 23 अप्रैल को एलएसएफएमएम 2018 कार्यक्रम में चर्चा होने की संभावना है। यदि आप भाग्यशाली हैं, तो किसी प्रकार का समाधान होगा जो इच्छुक पार्टियों के लिए काम करेगा। हालांकि, एक चीज जो नहीं बदलेगी, वह सरल तथ्य यह है कि त्रुटि से निपटने को सही ढंग से करना मुश्किल है।