संस्करण 9.4 के बाद से PostgreSQL में दिलचस्प विशेषताओं में से एक प्रतिकृति स्लॉट का उपयोग करके WAL फ़ाइलों को हटाने को नियंत्रित करने की क्षमता है। अंधेरा पक्ष यह है कि प्रतिकृति स्लॉट डिस्क को पुराने WAL से भरने का कारण बन सकते हैं, जिससे मुख्य उत्पादन सर्वर की मृत्यु हो जाती है। इस लेख में मैं PostgreSQL प्रतिकृति स्लॉट की व्याख्या करता हूं, और कैसे PostgreSQL 13 में एक नई सुविधा इस समस्या को रोकने में मदद करती है।

वाल प्रोडक्शन

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

(ऐसी विशेष परिस्थितियाँ हैं जैसे गतिविधि में वृद्धि जो अतिरिक्त फ़ाइलों के निर्माण की ओर ले जाती है; जब बाद में उछाल समाप्त हो जाता है, तो उन अतिरिक्त फ़ाइलों को पुनर्नवीनीकरण के बजाय हटा दिया जाता है।)

क्योंकि सभी डेटाबेस लेखन गतिविधि WAL उत्पन्न करती है, डिस्क स्थान उपलब्ध होना महत्वपूर्ण है। जब WAL को संग्रहीत करने वाली डिस्क भर जाती है, तो सर्वर नए लेनदेन को संसाधित करने में असमर्थ होगा और अटक सकता है, या इससे भी बदतर:यह पूरी तरह से गिर सकता है। तो यह एक ऐसी स्थिति है जिससे हर संभव तरीके से बचा जा सकता है।

प्रतिकृति स्लॉट

PostgreSQL में प्रतिकृति WAL फ़ाइलों को संसाधित करके काम करती है। इसे काम करने के लिए, सभी WAL फ़ाइलों को संसाधित होने तक क्षणिक रूप से उपलब्ध होना चाहिए। इसलिए मुख्य वाल प्रबंधन को फाइलों को रीसायकल या हटाने के लिए नहीं बताने के लिए एक तंत्र की आवश्यकता है।

प्रतिकृति स्लॉट दर्ज करें। स्लॉट एक तंत्र है जो इंगित करता है कि यह हम जो बैकअप ले रहे हैं उसके लिए उस की आवश्यकता होगी WAL फ़ाइल, और क्या आप कृपया इसे अभी तक नहीं हटा सकते हैं; या यह प्रतिकृति अभी भी संसाधित नहीं हुई है कि WAL फ़ाइल है, तो क्या कृपया इसे थोड़ी देर के लिए अकेला छोड़ दिया जाए।

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

वाल की खपत

किसी भौतिक प्रतिकृति को डेटा फीड करने का अर्थ है उसके प्राथमिक सर्वर से WAL डेटा की प्रतिलिपि बनाना। इसी तरह, एक तार्किक प्रतिकृति को वाल डेटा को पढ़ने की आवश्यकता होती है (और एक व्याख्या किए गए संस्करण को प्रतिकृति में प्रेषित करता है)। WAL स्थिति पढ़ी जा रही है जो स्लॉट का ट्रैक रखता है। एक बार जब प्रतिकृति ने वाल डेटा को किसी तरह सुरक्षित कर लिया है, तो स्लॉट को उन्नत किया जा सकता है; यह प्राथमिक में वाल प्रबंधन को बताता है कि वाल फाइल तब हटाने के लिए उपलब्ध है। यह तब होता है जब प्रतिकृति सक्रिय होती है, ताकि प्राथमिक सर्वर में WAL समान मात्रा में डिस्क स्थान का उपयोग करेगा या शायद थोड़ा अधिक। यहां तक ​​कि शर्तों के आधार पर दोगुना या दस गुना अधिक स्वीकार्य हो सकता है।

समस्या यह है कि यदि एक प्रतिकृति पूरी तरह से मर जाती है और लंबे समय तक ठीक नहीं होती है; या प्रतिकृति नष्ट हो जाती है और डीबीए प्रतिकृति स्लॉट को हटाना भूल जाता है; या स्लॉट किसी प्रयोग का भूला हुआ बचा हुआ भाग है; या यहां तक ​​कि प्रतिकृति को धीमे नेटवर्क लिंक पर फीड किया जा रहा है, तो आरक्षित वाल बिना सीमा के बढ़ेगा। और वह एक टिक-टिक बम बन जाता है।

स्लॉट आकार सीमित करना

इस समस्या से लड़ने के लिए, क्योटारो होरिगुची फरवरी 2017 से एक पोस्टग्रेएसक्यूएल पैच में एक स्लॉट द्वारा आरक्षित वाल के आकार को सीमित करने के लिए काम कर रहा था। बहुत लंबी समीक्षा और फिर से काम करने की प्रक्रिया के बाद मैंने इसे PostgreSQL 13 के लिए एकीकृत किया, उच्च उपलब्धता वाले PostgreSQL फ़ार्म के प्रबंधन में सुधार किया।

मुख्य सिद्धांत यह है कि उस प्रतिकृति को खिलाने वाले प्राथमिक सर्वर को मारने और उसके साथ सभी उत्पादन को नीचे ले जाने की तुलना में एक प्रतिकृति को मारना बेहतर है (किसी तरह इसके स्लॉट को अमान्य बनाकर; नीचे उस पर और अधिक)।

इसके काम करने का तरीका बहुत सीधा है:max_slot_wal_keep_size . सेट करें (दस्तावेज़ीकरण) postgresql.conf में WAL के डिस्क स्थान की अधिकतम मात्रा के लिए जो प्रतिकृति स्लॉट को आरक्षित करने की अनुमति है। यदि कोई स्लॉट उस बिंदु तक पहुंचता है और एक चेकपॉइंट होता है, तो उस स्लॉट को अमान्य के रूप में चिह्नित किया जाएगा और कुछ WAL फ़ाइलें हटाई जा सकती हैं। यदि स्लॉट वाल्सेंडर . द्वारा सक्रिय रूप से उपयोग में था प्रक्रिया, उस प्रक्रिया को संकेत दिया जाएगा ताकि वह समाप्त हो जाए। यदि वालसेंडर फिर से शुरू होता है, तो वह पाएगा कि आवश्यक WAL फाइलें अब वहां नहीं रहेंगी। उस स्लॉट का उपयोग करने वाली प्रतिकृति को फिर से क्लोन करना होगा।

अगर max_slot_wal_keep_size शून्य है, जो कि डिफ़ॉल्ट मान है, तो कोई सीमा नहीं है। मैं इसकी अनुशंसा नहीं करता, क्योंकि जब स्लॉट डिस्क भरते हैं तो यह विफलताओं की ओर ले जाता है।

स्लॉट स्वास्थ्य की निगरानी

कुछ निगरानी सुविधाएँ भी शामिल हैं। pg_replication_slots में दो कॉलम प्रासंगिक हैं। सबसे महत्वपूर्ण है wal_status . अगर वह कॉलम reserved है , तो स्लॉट max_wal_size . के भीतर डेटा की ओर इशारा कर रहा है; अगर यह extended है तो यह max_wal_size . को पार कर गया , लेकिन अभी भी wal_keep_size . द्वारा सुरक्षित है या max_slot_wal_keep_size (जब max_slot_wal_keep_size . सहित शून्य है)। कोई भी राज्य अच्छा और सामान्य है। हालाँकि, जब कोई स्लॉट सीमा से अधिक हो जाता है, तो वह पहले unreserved बन जाता है , जिसका अर्थ है कि यह आसन्न खतरे में है, लेकिन यदि यह काफी जल्दी हो तो फिर भी ठीक हो सकता है। अंत में, स्थिति lost . बन जाती है जब WAL फ़ाइलें हटा दी गई हों और कोई पुनर्प्राप्ति संभव न हो।

दूसरा कॉलम है safe_wal_size :यह WAL के बाइट्स की संख्या को दिखाता है जिसे इस स्लॉट के WAL फ़ाइलों को हटाने के खतरे में पड़ने से पहले लिखा जा सकता है। हमारा सुझाव है कि अपने मॉनिटरिंग सिस्टम में इस कॉलम पर कड़ी नज़र रखें, और कम होने पर फायर अलर्ट करें। शून्य या नकारात्मक का मतलब है कि चेकपॉइंट होते ही आपकी प्रतिकृति मृत हो जाएगी:

SELECT slot_name, active, wal_status, safe_wal_size
  FROM pg_catalog.pg_replication_slots;

हमारा मानना ​​है कि यह नई सुविधा प्रतिकृतियों के रखरखाव को आसान और अधिक मजबूत बनाती है; उम्मीद है कि इन समस्याओं के कारण उत्पादन में कमी के साथ हम और कोई आपदा नहीं देखेंगे।

(एक नोट:safe_wal_size 13beta3 में पेश किया गया था, इसलिए अप-टू-डेट दस्तावेज़ देखना सुनिश्चित करें, या आपको min_safe_lsn दिखाई देगा बजाय। उस पर ध्यान न दें।)

धन्यवाद

इस समस्या को हल करने पर काम करने के लिए क्योटारो होरिगुची का विशेष धन्यवाद। कई समीक्षकों ने इस पर गहराई से विचार किया, जिनमें से मैं विशेष रूप से मासाहिको सवादा, फुजी मसाओ, जहान-गिलौम डी रोर्थिस और अमित कपिला (किसी विशेष क्रम में) को धन्यवाद देना चाहता हूं।