पोस्टग्रेस स्लेव पर हॉट स्टैंडबाय और लांग रनिंग क्वेरीज

Question

प्रश्न: क्या आपके पास लंबे समय तक चलने वाले प्रश्न (30s +) चल रहे हैं जबकि दास पर लागू वैल अपडेट (दास भूमिका एक रिपोर्टिंग डीबी सर्वर के रूप में है) हॉट स्टैंडबाय मोड में ? जिस तरह से यह अब काम कर रहा है, या तो आप लंबे समय से चलने वाले प्रश्नों को मारने के लिए नीचे दिए गए पैरा सेट करते हैं, इसलिए डब्ल्यूएएल अपडेट लागू किए जा सकते हैं, या वैल अपडेट को अनिश्चित काल तक देरी कर सकते हैं जब तक कि उन्हें लागू करने के लिए कोई प्रश्न नहीं चल रहा हो। क्या हम दोनों हो सकते हैं? लंबे समय से चल रहे प्रश्न और WAL अपडेट एक ही समय में लागू किए जा रहे हैं?

केस कार्यान्वयन: वर्तमान में हम एक मास्टर से एक दास में किसी भी बदलाव को सिंक करने के लिए हॉट स्टैंडबाय मोड का उपयोग कर रहे हैं। दास भूमिका एक रिपोर्टिंग डीबी सर्वर के रूप में लगातार पूछताछ और समवर्ती रूप से चल रही है (कुछ एमएस में, कुछ सेकंड में, कुछ मिनटों में।) दास पर चल रहे कोई सक्रिय प्रश्नों का अंतर होना बहुत दुर्लभ होगा।

हम इन दो पैरामीटर समायोजित किया है गर्म स्टैंडबाय पर लंबी क्वेरी अनुमति देने के लिए:

max_standby_archive_delay = -1 # max delay before canceling queries 
max_standby_streaming_delay = -1 # max delay before canceling queries 

और मेलिंग सूची का संग्रहीत मेल एक postgres में हमारे जैसे प्रश्न को देखकर:

http://www.postgresql.org/message-id/AANLkTinLg+bpzcjzdndsnGGNFC=D1OsVh+hKb85A-s=n@mail.gmail.com

प्रश्नों के चलते दासों पर लागू होने वाले वाल अपडेट को रोकने की अवधारणा को मैं समझता हूं। हालांकि, मैंने एमवीसीसी, के उपयोग के साथ सोचा था कि दास पर एक सक्रिय क्वेरी (लंबी दौड़, 30 सेकंड +) एक संस्करण/स्नैपशॉट से पढ़ने को चला सकती है, जबकि डब्ल्यूएएल अपडेट लागू किया जा रहा है, इसलिए बाद के प्रश्नों को WAL मिल जाएगा अद्यतन जब उस डब्ल्यूएएल लेनदेन प्रतिबद्ध है। मैंने PostgreSQL में अभी तक [https://devcenter.heroku.com/articles/postgresql-concurrency] में उपयोग किए गए एमवीसीसी मॉडल को पूरी तरह से पच नहीं किया है, इसलिए यह सिर्फ मेरी धारणा है - भले ही WAL अद्यतन के दौरान एक तालिका को गिरा दिया/छोटा कर दिया गया हो, वर्तमान चलती क्वेरी अभी भी काम करनी चाहिए संस्करण/स्नैपशॉट का उपयोग करके यह पूछताछ कर रहा है?

सारांश: वहाँ वैसे भी (यहां तक ​​कि एक तीसरी पार्टी के विस्तार के साथ) है हम दास एक मास्टर से सिंक और गुरु से उन अपडेट दास को लागू किया जा तुरंत किसी भी निष्पादन समय की दे प्रश्नों जारी रखने के लिए, जबकि हो सकता है तक स्टैंडबाय/गुलाम पर पूरा होने तक चलते हैं? यदि हॉट स्टैंडबाय ऐसा नहीं कर सकता है, आप इस स्थिति के लिए क्या सिफारिश करेंगे? हमारा परिदृश्य यह है कि हम लगातार प्रश्नों के साथ पोस्टग्रेस मार रहे हैं और समवर्ती रूप से चल रहे हैं (कुछ एमएस, कुछ सेकंड में, कुछ मिनटों में), WAL अपडेट के लिए लगभग कोई समय नहीं छोड़ते हैं। हमने बुकार्डो का उपयोग किया है, लेकिन यह इस परिदृश्य में विकल्प अच्छा नहीं होगा, क्योंकि हम 200+ से अधिक टेबलों को सिंक्रनाइज़ करने की आवश्यकता होगी, जिसमें हमारे मुख्य डेटाबेस से अलग-अलग 40+ अन्य डेटाबेस भी शामिल हैं।

किसी भी मदद की सराहना की जाएगी।

धन्यवाद!

Answer 1

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

लॉग भी देरी के लिए बहुत प्रतिरोधी हैं, और जब तक आपके पास भारी ट्रैफिक नहीं है, यह हमेशा किसी बिंदु पर पकड़ लेगा।

बस सुनिश्चित करें कि आप लॉक कमांड का उपयोग नहीं करते हैं, और आप ठीक होंगे।

Answer 2

धन्यवाद आपके उत्तर के लिए गिलाउम, लेकिन सौभाग्य से, PostgreSQL 9.1 में शुरू होने पर, PostgreSQL में hot_standby_feedback विकल्प है (आप इसे postgresql.conf में स्टैंडबाय सर्वर पर सेट करते हैं) जो लंबे समय तक चलने वाले प्रश्नों को मार नहीं पाएगा और WAL अपडेट को अनुमति देगा स्टैंडबाय सर्वर। इस उत्तर के लिए क्रेडिट PostgreSQL मेल सूची (राजा/अल्बे/स्कॉट) पर तीन लोगों को जाता है जिन्होंने मुझे उस मेलिंग थ्रेड में इस पर मदद की। उम्मीद है कि यह इस जवाब को स्टैक ओवरफ्लो पर खोजने में मददगार हो सकता है। ईमेल थ्रेड यहां पाया जा सकता:

http://www.postgresql.org/message-id/D274E3C1.1113E8%awilliams@dresourcesgroup.com

http://www.postgresql.org/docs/9.1/static/hot-standby.html

अंश:

उपचारात्मक संभावनाएं मौजूद हैं, तो अतिरिक्त क्वेरी रद्दीकरण की संख्या अस्वीकार्य हो पाया है। पहला विकल्प पैरामीटर hot_standby_feedback सेट करना है, जो VACUUM को हाल ही में मृत पंक्तियों को हटाने से रोकता है और इसलिए क्लीनअप विवाद नहीं होते हैं। यदि आप ऐसा करते हैं, तो आपको ध्यान रखना चाहिए कि इससे प्राथमिक पर मृत पंक्तियों की सफाई में देरी होगी, जिसके परिणामस्वरूप अवांछनीय तालिका ब्लोट हो सकती है। हालांकि, क्लीनअप स्थिति प्राथमिक सर्वर पर सीधे चलने वाले प्रश्नों से भी बदतर नहीं होगी, और आपको अभी भी स्टैंडबाय पर ऑफ-लोडिंग निष्पादन का लाभ मिल रहा है। इस मामले में max_standby_archive_delay को बड़ा रखा जाना चाहिए, क्योंकि देरी हुई WAL फ़ाइलों में पहले से ही प्रविष्टियां हो सकती हैं जो वांछित स्टैंडबाय क्वेरी के साथ संघर्ष करती हैं।

समाधान कार्यान्वयन:

गया है कि आपकी postgresql.conf अतिरिक्त सर्वर पर करने के लिए कॉन्फ़िगर किया जाना चाहिए है: पर

max_standby_archive_delay = -1 
max_standby_streaming_delay = -1 
hot_standby_feedback = on