PostgreSQL: कैसे और क्यों वाल सूज

निगरानी को उपयोगी बनाने के लिए, हमें संभावित समस्याओं के विभिन्न परिदृश्यों और डैशबोर्ड और ट्रिगर्स को इस तरह से तैयार करना होगा कि वे घटना के कारण को तुरंत समझ सकें।

कुछ मामलों में, हम अच्छी तरह से समझते हैं कि बुनियादी ढांचे का यह या वह घटक कैसे काम करता है, और फिर यह पहले से ही जाना जाता है कि कौन सी मीट्रिक उपयोगी होगी। और कभी-कभी हम अधिकतम विस्तार के साथ लगभग सभी संभावित मीट्रिक निकालते हैं और फिर देखते हैं कि उन पर कुछ समस्याएं कैसे दिखाई देती हैं।

आज हम देखेंगे कि कैसे और क्यों लिखें-आगे लॉग (वाल) पोस्टग्रैज सूज सकते हैं। हमेशा की तरह - तस्वीरों में वास्तविक जीवन से उदाहरण।

Postgresql में थोड़ा वाल सिद्धांत

डेटाबेस में कोई भी परिवर्तन पहली बार वाल में दर्ज किया गया है, और उसके बाद ही बफर कैश में पेज में डेटा को बदल दिया जाता है और इसे गंदगी के रूप में चिह्नित किया जाता है - जिसे डिस्क में सहेजने की आवश्यकता होती है। इसके अलावा, CHECKPOINT प्रक्रिया समय-समय पर शुरू होती है, जो सभी गंदे पृष्ठों को डिस्क पर सहेजती है और वाल सेगमेंट नंबर को बचाती है, जिसके ऊपर सभी परिवर्तित पृष्ठ पहले से ही डिस्क पर लिखे गए हैं।

यदि अचानक किसी कारण से क्रैश हो जाता है और फिर से शुरू होता है, तो अंतिम चेकपॉइंट के सभी वाल सेगमेंट को पुनर्प्राप्ति प्रक्रिया के दौरान खेला जाएगा।

चेकपॉइंट से पहले वाले वाल सेगमेंट हमारे लिए पोस्ट-क्रैश डेटाबेस रिकवरी के लिए उपयोगी नहीं होंगे, लेकिन पोस्टग्रैज वाल में भी प्रतिकृति प्रक्रिया में भाग लेते हैं, और प्वाइंट इन टाइम रिकवरी के लिए सभी सेगमेंट का बैकअप - PITR भी कॉन्फ़िगर किया जा सकता है।

एक अनुभवी इंजीनियर शायद पहले से ही सब कुछ समझ गया है, यह वास्तविक जीवन में कैसे टूटता है :)
चलो चार्ट देखो!

वाल सूजन # 1

पोस्टग्रेज के प्रत्येक पाए जाने वाले उदाहरण के लिए हमारा मॉनिटरिंग एजेंट डिस्क के साथ डिस्क पर पथ की गणना करता है और कुल आकार और फ़ाइलों की संख्या (सेगमेंट) दोनों को हटाता है:

सबसे पहले, हम देखते हैं कि हम कब तक CHECKPOINT चला रहे हैं।

हम pg_stat_bgwriter से मैट्रिक्स लेते हैं:

• चौकियों_टिमेड - चेकपॉइंट का काउंटर इस शर्त पर लॉन्च किया गया था कि अंतिम चेकपॉइंट का समय pg_settings.checkpoint_timeout से अधिक हो गया था
• चौकियों_रेक - चेकपॉइंट के शुरू होने का काउंटर इस शर्त के साथ कि पिछले चेकपॉइंट से वाल का आकार पार हो गया है

हम देखते हैं कि चेकपॉइंट लंबे समय से लॉन्च नहीं किया गया है। इस मामले में, इस प्रक्रिया को शुरू नहीं करने का कारण सीधे तौर पर समझना असंभव है (लेकिन यह निश्चित रूप से अच्छा होगा), लेकिन हम जानते हैं कि पोस्टग्रेज में लंबे लेनदेन के कारण बहुत सारी समस्याएं पैदा होती हैं!

हम जाँच करते हैं:

इसके अलावा यह स्पष्ट है कि क्या करना है:

• एक लेन-देन को मार डालो
• लंबे समय तक कारणों से निपटें
• प्रतीक्षा करें, लेकिन जांचें कि पर्याप्त जगह है

एक और महत्वपूर्ण बिंदु: इस सर्वर से जुड़े प्रतिकृतियों पर, वाल भी सूज गया है !

वाल अभिलेखागार

मैं आपको इस अवसर पर याद दिलाता हूं: प्रतिकृति बैकअप नहीं है!

एक अच्छा बैकअप आपको किसी भी समय पुनर्प्राप्त करने की अनुमति देगा। उदाहरण के लिए, अगर किसी ने "गलती से" प्रदर्शन किया

DELETE FROM very_important_tbl; 

तब हमें इस लेन-देन से पहले डेटाबेस को राज्य में पुनर्स्थापित करने में सक्षम होना चाहिए। इसे PITR (पॉइंट-इन-टाइम रिकवरी) कहा जाता है और डेटाबेस में समय-समय पर पूर्ण बैकअप के साथ पोस्टग्रेजेकल में लागू किया जाता है + डंप के बाद सभी वाल सेगमेंट की बचत।

संग्रह_कैंड सेटिंग, वॉक का बैकअप लेने के लिए ज़िम्मेदार है, केवल आपके द्वारा निर्दिष्ट कमांड को शुरू करता है, और यदि यह बिना किसी त्रुटि के पूरा होता है, तो सेगमेंट को सफलतापूर्वक प्रतिलिपि माना जाता है। यदि कोई त्रुटि होती है, तो यह जीत तक कोशिश करेगा, खंड डिस्क पर झूठ होगा।

खैर, और एक दृष्टांत के रूप में - टूटे हुए संग्रह के ग्राफिक्स:

यहां, सभी वॉल सेगमेंट के आकार के अलावा, एक अनारक्षित आकार है - यह उन सेगमेंट का आकार है जो अभी तक सफलतापूर्वक सहेजे जाने योग्य नहीं माने जाते हैं।

हम pg_stat_archiver के काउंटरों के अनुसार स्थितियों पर विचार करते हैं। फ़ाइलों की संख्या के लिए, हमने सभी ग्राहकों के लिए एक ऑटो-ट्रिगर बनाया, क्योंकि यह अक्सर टूट जाता है, खासकर जब कुछ क्लाउड स्टोरेज का उपयोग गंतव्य (एस 3, उदाहरण के लिए) के रूप में किया जाता है।

प्रतिकृति अंतराल

प्रगति में स्ट्रीमिंग प्रतिकृति प्रतिकृति पर चलने और खेलने के माध्यम से काम करती है। यदि किसी कारण से प्रतिकृति पीछे रह जाती है और एक निश्चित संख्या में सेगमेंट नहीं खोती है , तो विज़ार्ड इसके लिए pg_settings.wal_keep_seolution सेगमेंट संग्रहीत करेगा। यदि प्रतिकृति बड़ी संख्या में खंडों के पीछे आती है, तो यह अब मास्टर से कनेक्ट नहीं हो पाएगी (इसे फिर से डालना होगा)।

किसी भी वांछित सेगमेंट की सुरक्षा की गारंटी देने के लिए, प्रतिकृति स्लॉट की कार्यक्षमता 9.4 में दिखाई दी, जिस पर बाद में चर्चा की जाएगी।

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

यदि प्रतिकृति प्रतिकृति स्लॉट का उपयोग करके कॉन्फ़िगर किया गया है और स्लॉट में कम से कम एक सफल प्रतिकृति कनेक्शन था, तो यदि प्रतिकृति गायब हो जाती है, तो पोस्टग्रैस सभी नए वॉल सेगमेंट को स्टोर करेगा जब तक कि जगह खत्म नहीं हो जाती।

यही है, एक भूल प्रतिकृति स्लॉट वाल सूजन का कारण बन सकता है। लेकिन सौभाग्य से, हम pg_replication_slots के माध्यम से स्लॉट की स्थिति की निगरानी कर सकते हैं।

यहाँ यह एक जीवंत उदाहरण में दिखता है:

ऊपरी आकार में, वाल आकार के बगल में, हम हमेशा संचित खंडों की अधिकतम संख्या के साथ एक स्लॉट प्रदर्शित करते हैं, लेकिन एक विस्तृत ग्राफ़ भी है जो दिखाएगा कि कौन सा स्लॉट सूज गया है।

एक बार जब हम समझ जाते हैं कि किस प्रकार का स्लॉट डेटा एकत्र कर रहा है, तो हम या तो इससे जुड़ी प्रतिकृतियों की मरम्मत कर सकते हैं, या बस इसे हटा सकते हैं।

मैंने वाल सूजन के सबसे आम मामलों का हवाला दिया, लेकिन मुझे यकीन है कि अन्य मामले हैं (पोस्टग्रेज में बग भी कभी-कभी पाए जाते हैं)। इसलिए, डिस्क के आकार की निगरानी करना और डिस्क स्थान से बाहर होने से पहले समस्याओं का जवाब देना महत्वपूर्ण है और डेटाबेस अनुरोधों को पूरा करना बंद कर देगा।

हमारी निगरानी सेवा पहले से ही जानती है कि यह सब कैसे इकट्ठा किया जाए, सही ढंग से कल्पना करें और सतर्क रहें। और हमारे पास उन लोगों के लिए एक ऑन-प्रिमाइसेस डिलीवरी विकल्प भी है जिनके लिए क्लाउड सूट नहीं करता है।