"लेन-देन आईडी रैपराउंड" के बारे में

Question

अब, मैंने "लेन-देन आईडी रैपराउंड" के बारे में दस्तावेज़ पढ़ा है, लेकिन कुछ चीजें हैं जो मुझे वास्तव में समझ में नहीं आती हैं, दस्तावेज़ निम्नलिखित url है http://www.postgresql.org/docs/9.0/static/routine.acacuuming .html # वैक्यूम के लिए-wraparound

23.1.4। लेन-देन की रोकथाम आईडी रैपराउंड की विफलता

PostgreSQL के MVCC लेन-देन शब्दार्थक लेनदेन आईडी (XID) संख्याओं की तुलना करने में सक्षम होने पर निर्भर करते हैं: वर्तमान लेनदेन के XID से अधिक प्रविष्टि XID के साथ एक पंक्ति संस्करण "भविष्य में" है और वर्तमान लेनदेन के लिए दृश्यमान नहीं होना चाहिए। लेकिन चूंकि लेन-देन आईडी में सीमित आकार (32 बिट्स) होता है, एक क्लस्टर जो लंबे समय तक चलता है (4 बिलियन से अधिक लेनदेन) लेनदेन आईडी रैपराउंड को भुगतना होगा: XID काउंटर शून्य के आसपास घूमता है, और अचानक लेनदेन जो सभी में थे अतीत भविष्य में प्रकट होता है - जिसका अर्थ है कि उनका उत्पादन अदृश्य हो जाता है। संक्षेप में, विपत्तिपूर्ण डेटा हानि। (वास्तव में डेटा अभी भी है, लेकिन अगर आप इसे प्राप्त नहीं कर सकते हैं तो यह ठंडा आराम है।) इससे बचने के लिए, हर डेटाबेस में हर दो बिलियन लेनदेन के बाद कम से कम एक बार प्रत्येक तालिका को वैक्यूम करना आवश्यक है।

मुझे समझ में नहीं आता है कि "लेन-देन आईडी रैपअराउंड को भुगतना होगा: XID काउंटर शून्य के आसपास घूमता है, और अतीत में अचानक हुए सभी लेनदेन भविष्य में दिखाई देते हैं - जिसका अर्थ है कि उनका आउटपुट अदृश्य हो गया है"

क्या कोई इसे समझा सकता है? क्यों डेटाबेस के बाद लेन-देन आईडी रैपराउंड से पीड़ित होता है जो अतीत में थे लेनदेन भविष्य में दिखाई देते हैं? संक्षेप में, मैं यह जानना चाहता हूं कि क्या ऑटोरेवोयूम द्वारा लेन-देन आईडी रैपराउंड के बाद "डेटा हानि" स्थिति में PostgreSQL होगा to

मेरे निजी विचारों के लिए, हम txid_current () फ़ंक्शन का उपयोग करके वर्तमान लेन-देन आईडी प्राप्त कर सकते हैं, जिसका आउटपुट 64 बिट है और इसे साइकल नहीं किया जाएगा। तो मुझे लगता है कि tuples का सम्मिलन लेनदेन आईडी, जो xmin के रूप में जानता है, जो xid से अधिक प्राप्त करेगा txid_current () फ़ंक्शन द्वारा। सिवाय इसके कि आप PostgreSQL सर्वर बंद करने के बाद pg_resetxlog रीसेट रीसेट ID का उपयोग करेंगे। क्या मैं सही हू ? धन्यवाद

Comments

मुझे लगता है कि यदि संभव हो तो आपका नवीनतम संपादन एक नया प्रश्न होना चाहिए

— जैक कहते हैं कि topanswers.xyz

Answer 1

क्यों डेटाबेस के बाद लेन-देन आईडी रैपराउंड से पीड़ित होता है जो अतीत में थे लेनदेन भविष्य में दिखाई देते हैं?

वे नहीं करते। उद्धृत पाठ सिर्फ यह बताता है कि क्यों पोस्टग्रास को मॉडुलो 2 ³¹ अंकगणितीय (जिसका अर्थ है कि लेन-देन लगभग तभी तक लपेट सकते हैं जब तक पुराने लेन-देन पर्याप्त रूप से जल्दी शुरू हो जाते हैं) का उपयोग करने की आवश्यकता होती है:

सामान्य XIDs की तुलना modulo-2 ^ 31 अंकगणितीय के उपयोग से की जाती है। इसका मतलब है कि प्रत्येक सामान्य XID के लिए, दो बिलियन XID हैं जो "पुराने" हैं और दो बिलियन "नए" हैं

विस्तार से:

पुराने पंक्ति संस्करणों को दो-बिलियन-लेन-देन के पुराने चिह्न तक पहुंचने से कुछ समय पहले XID फ्रोजनएक्सआईडी को फिर से असाइन किया जाना चाहिए

या चारों ओर XID लपेटने से चीज़ें टूट जाएँगी। इसे रोकने के लिए, पोस्टग्रेट्स चेतावनी देना शुरू कर देंगे, और अंततः बंद हो जाएंगे और यदि आवश्यक हो तो नए लेनदेन शुरू करने से इनकार कर सकते हैं:

यदि किसी कारण से ऑटोवैक्यूम पुराने एक्सआईडी को एक मेज से साफ करने में विफल रहता है, तो सिस्टम इस तरह से चेतावनी संदेशों का उत्सर्जन करना शुरू कर देगा जब डेटाबेस के सबसे पुराने एक्सआईडी रैपपाउंड बिंदु से दस मिलियन लेनदेन तक पहुंचते हैं:

WARNING:  database "mydb" must be vacuumed within 177009986 transactions 
HINT:  To avoid a database shutdown, execute a database-wide VACUUM in "mydb". 

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

दूसरे शब्दों में, "लेनदेन जो अतीत में था, भविष्य में दिखाई देता है" और "डेटा हानि" पूरी तरह से सैद्धांतिक हैं और व्यवहार में लेनदेन आईडी रैपराउंड के कारण नहीं होंगे।

Comments

आइए हम इस चर्चा को चैट में जारी रखें

— जैक कहते हैं कि topanswers.xyz

Answer 2

आपके द्वारा पेस्ट किया गया ब्लॉक प्रश्न का उत्तर देता है। यह सब उस तर्क पर निर्भर करता है जिसका उपयोग 'भविष्य' के लेनदेन को छिपाने के लिए किया जाता है।

लेन-देन आईडी (XID) काउंटर 32 बिट्स तक सीमित है और यदि यह कभी भी उस अगली संख्या तक पहुंच जाता है, तो पुराने अधिकतम लेनदेन को बदलने के बजाय, यह शून्य पर नए सिरे से शुरू होता है।

खैर, अब यह शून्य है, इसलिए PostgreSQL लेनदेन के सभी> 0 से छिपा रहा है। भले ही 20 सेकंड पहले Transaction # 2,147,483,633 हुआ, PostgreSQL को लगता है कि यह एक और 2,147,483,633 लेनदेन के लिए नहीं होगा।

Comments

डॉक्स को 2013 के दिसंबर में ठीक किया गया था। XIDs की गणना modulo-2 ^ 31 का उपयोग करके की जाती है।

— eradman