पोस्टग्रेज में एक चलती घटना क्षितिज होता है, जो वर्तमान लेनदेन आईडी के आगे या पीछे लगभग 2 अरब लेनदेन के प्रभाव में होता है। वर्तमान लेन-देन आईडी से 2 बिलियन तक या 2 बिलियन से अधिक पीछे के लेन-देन को भविष्य में माना जाता है, और इस प्रकार वर्तमान लेनदेन के लिए अदृश्य होगा।
पोस्टग्रेज विशेष रूप से पुरानी पंक्तियों को चिह्नित करके इस भयावह डेटा हानि से बचाते हैं ताकि कोई फर्क नहीं पड़ता कि वे वर्तमान लेनदेन आईडी के संबंध में कहां हैं, वे दिखाई देंगे।
फ्रीजिंग पुराने लाइव टुपल्स (यानी डेटाबेस पंक्तियों) को चिह्नित करने की यह प्रक्रिया है ताकि वे चलती घटना क्षितिज से आगे न बढ़ें जो अन्यथा उन्हें भविष्य में दिखाई दें। यह वैक्यूमिंग के विपरीत है, जो पुराने मृत टुपल्स द्वारा खपत की गई जगह को खाली करना है जो अब किसी भी लेनदेन के लिए दृश्यमान नहीं हैं।
दोनों प्रक्रियाओं को वैक्यूम द्वारा प्रबंधित किया जाता है।
ऐसी कई सेटिंग्स हैं जो नियंत्रित करती हैं कि फ्रीजिंग कैसे की जाती है।
सबसे पहले, vacuum_freeze_min_age यह नियंत्रित करता है कि एक टपल जमे हुए होगा या नहीं, जबकि वैक्यूम पहले से ही एक पृष्ठ को देख रहा है कि क्या इसमें मृत ट्यूपल हैं जिन्हें साफ किया जा सकता है। vacuum_freeze_min_age . से पुराने टुपल्स इस मामले में जमे रहेंगे। इसे कम करने का मतलब है कि बाद में करने के लिए कम काम होगा, लेकिन सीपीयू और आईओ या वाल गतिविधि दोनों में अतिरिक्त प्रयास की संभावित कीमत पर। आम तौर पर आप शायद इस सेट को कम से कम कुछ घंटों के लेन-देन के लिए चाहते हैं। मान लें कि आप निरंतर दर के रूप में प्रति सेकंड 2000 लेनदेन करने की उम्मीद कर रहे हैं। 2000 TPS प्रति घंटे 7.2m लेनदेन है। इस प्रकार इस मामले के लिए काफी आक्रामक सेटिंग 20 मी कह सकते हैं। डिफ़ॉल्ट सेटिंग 50 मीटर है। इसी तरह vacuum_multixact_freeze_min_age . के लिए . ध्यान दें कि transaction_id और multixid काउंटर स्वतंत्र हैं - आपको उन दोनों पर नज़र रखने की आवश्यकता है।
दूसरा, vacuum_freeze_table_age . हैं और vacuum_multixact_freeze_table_age . ये सेटिंग्स तब नियंत्रित होती हैं जब ऑटोवैक्यूम केवल उन पृष्ठों को नहीं देखेगा जिनमें मृत पंक्तियाँ हो सकती हैं, बल्कि कोई भी पृष्ठ जिसमें बिना फ्रोजन पंक्तियाँ हो सकती हैं। इन सेटिंग्स के लिए डिफ़ॉल्ट 150 मी हैं। अगर आपने vacuum_freeze_min_age को कम कर दिया है पर्याप्त, कई मामलों में इस अधिक आक्रामक निर्वात में करने के लिए बहुत कम या कोई काम नहीं होगा। किसी भी मामले में, यह प्रक्रिया उतनी व्यस्त नहीं है जितनी पहले हुआ करती थी, क्योंकि पोस्टग्रेज के आधुनिक संस्करण (9.6 और ऊपर) उन पृष्ठों का नक्शा रखते हैं जहां सभी टुपल्स जमे हुए हैं, और केवल उन पृष्ठों पर जाएं जो सभी जमे हुए नहीं हैं। इसका मतलब है कि यह अब एक पूर्ण तालिका स्कैन नहीं है।
अंत में autovacuum_freeze_max_age है . यदि पिछली बार तालिका को पूरी तरह से अनफ्रोजेन पंक्तियों के लिए स्कैन किया गया था, तो यह कई लेनदेन पहले की तुलना में अधिक था, ऑटोवैक्यूम टेबल पर एक एंटी-रैपरअराउंड वैक्यूम शुरू करेगा। डिफ़ॉल्ट 200 मीटर है। इसी तरह autovacuum_multixact_freeze_max_age . के लिए जिसके लिए डिफ़ॉल्ट 400m है। यह कुछ ऐसा है जिससे आप वास्तव में बचना चाहते हैं। दो चीजें हैं जो की जा सकती हैं। सबसे पहले, अपने आप को अधिक हेडरूम देने के लिए, इन सेटिंग्स को 1 बिलियन तक बढ़ाना बहुत आम है, खासकर उन प्रणालियों पर जो लेनदेन के भारी उपभोक्ता हैं। आप इसे और अधिक कर सकते हैं लेकिन आप अपने सबसे पुराने टपल और घटना क्षितिज के बीच बहुत अधिक लेनदेन स्थान रखना चाहते हैं। दूसरा, किसी भी डेटाबेस को इसमें चलाने से पहले अपने सिस्टम की निगरानी करना और उपचारात्मक कार्रवाई करना महत्वपूर्ण है। इस उपचारात्मक कार्रवाई में अक्सर मैनुअल वैक्यूमिंग शामिल होती है।
एक समस्या यह हो सकती है कि आपके पास डीडीएल है जो सामान्य (यानी एंटी-रैपराउंड नहीं) ऑटोवैक्यूम को खुद को रद्द करने का कारण बनता है। यदि आप इसे पर्याप्त रूप से करते हैं तो अंततः आपको एक एंटी-रैपअराउंड वैक्यूम मजबूर हो जाएगा, और कोई भी डीडीएल वैक्यूम प्रक्रिया के पीछे कतार में खड़ा हो जाएगा, और बदले में किसी भी डीएमएल को अवरुद्ध कर देगा। इस स्तर पर वैक्यूम खत्म होने तक आपकी तालिका प्रभावी रूप से अपठनीय है। यह आपके डेटाबेस के उपयोग पैटर्न पर निर्भर करता है, लेकिन यह केवल एक सैद्धांतिक संभावना नहीं है और पोस्टग्रेज परिनियोजन और डीबीए को इसे ध्यान में रखने की आवश्यकता है।
इसे प्रबंधित करने के लिए अपने डेटाबेस क्लस्टर की निगरानी करना महत्वपूर्ण है। विशेष रूप से आपको datfrozenxid . की निगरानी करने की आवश्यकता है और datminmxid क्लस्टर में प्रत्येक डेटाबेस का, और यदि ये बहुत पुराने हो जाते हैं तो एंटी-रैपअराउंड वैक्यूम की आवश्यकता होने से पहले उपचारात्मक कार्रवाई करें। अक्सर समस्या डेटाबेस में एक या कुछ तालिकाओं के साथ होती है। relfrozenxid . की जांच करके कौन सी समस्या का पता लगाया जा सकता है? और relminmxid डेटाबेस में तालिकाओं की। age() और mxid_age() फंक्शन क्रमशः ट्रांजेक्शन आईडी और मल्टीक्सिड काउंटरों की आयु का पता लगाने के लिए उपयोगी होते हैं।
फ्रीजिंग ऐसी चीज नहीं है जिससे आप बच सकते हैं, यह पोस्टग्रेज में एक आवश्यक रखरखाव गतिविधि है जिसे सक्रिय रूप से प्रबंधित करने की आवश्यकता है।
