PostgreSQL त्रुटि: वसूली के साथ संघर्ष के कारण बयान को रद्द करना

Question

स्टैंडबाय मोड में PostgreSQL db पर क्वेरी चलाते समय मुझे निम्न त्रुटि हो रही है। जिस क्वेरी में त्रुटि होती है वह 1 महीने के लिए ठीक काम करती है, लेकिन जब आप क्वेरी को 1 महीने से अधिक के लिए त्रुटि परिणाम देते हैं।

ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed

कैसे हल करने के बारे में कोई सुझाव? धन्यवाद

Comments

कृपया AWS डॉक को खोजें जिसमें इस त्रुटि का उल्लेख किया गया है जिसका समाधान aws.amazon.com/blogs/database/…

— arunjos007

Answer 1

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

लंबी क्वेरी को अधिक बार रद्द कर दिया जाएगा।

आप प्राथमिक पर एक बार-बार पढ़ने योग्य लेन-देन शुरू करके इसके चारों ओर काम कर सकते हैं जो एक डमी क्वेरी करता है और फिर निष्क्रिय बैठता है जबकि एक वास्तविक क्वेरी द्वितीयक पर चलती है। इसकी उपस्थिति प्राथमिक पर पुराने पंक्ति संस्करणों की वैक्यूमिंग को रोक देगी।

इस विषय पर अधिक और अन्य वर्कअराउंड को हॉट स्टैंडबाई में समझाया गया है - प्रलेखन में क्वेरी संघर्ष अनुभाग को हैंडल करना।

Comments

PostgreSQL 9.1+ के उपयोगकर्ताओं के लिए: व्यावहारिक समाधान के लिए eradman का जवाब नीचे देखें।

— जोल्टन

PostgreSQL 9.1+ के उपयोगकर्ताओं के लिए: अधिकतम-मलीश का उत्तर बहुत ही पवित्र है। जब तक आप जोखिमों को नहीं समझते हैं, तब तक उन्मूलन का सुझाव न दें।

— दावोस

Answer 2

छूने की जरूरत नहीं hot_standby_feedback। जैसा कि दूसरों ने उल्लेख किया है, इसे स्थापित करने से onमास्टर को ब्लोट किया जा सकता है। एक दास पर लेनदेन खोलने और इसे बंद न करने की कल्पना करें।

इसके बजाय, सेट max_standby_archive_delayऔर max_standby_streaming_delayकुछ समझदार मूल्य के लिए:

# /etc/postgresql/10/main/postgresql.conf on a slave
max_standby_archive_delay = 900s
max_standby_streaming_delay = 900s

इस तरह से 900 सेकंड से कम अवधि वाले दासों के प्रश्नों को रद्द नहीं किया जाएगा। यदि आपके कार्यभार में लंबे समय तक प्रश्नों की आवश्यकता है, तो बस इन विकल्पों को उच्च मूल्य पर सेट करें।

Comments

यह वह समाधान है जिसका हमने उपयोग किया है। यहां प्रस्तुत सभी विकल्पों के बीच सबसे अच्छा समझौता जैसा लगता है।

— mohit6up

यह सबसे अच्छा जवाब है। डॉक्स के अनुसार ध्यान दें कि ये संचयी हैं; यदि आपके पास प्रतिकृति पर कई प्रश्न हैं, तो यह प्रतिकृति हो सकती है कि आप 899 तक पहुंच सकते हैं, फिर 2 सेकंड की दूसरी क्वेरी रद्द हो जाती है। अपने कोड में कुछ घातीय बैक-अप लागू करना सबसे अच्छा है। इसके अलावा, स्ट्रीमिंग देरी प्रभाव में है, जबकि प्रतिकृति स्ट्रीमिंग है। यदि प्रतिकृति स्ट्रीमिंग के साथ नहीं रह सकती है तो यह संग्रह से प्रतिकृति की ओर बढ़ेगा। यदि आप संग्रह से प्रतिकृति बना रहे हैं, तो आपको संभवतः इसे पकड़ने देना चाहिए, max_standby_archive_delayदूसरे से छोटा होने की आवश्यकता हो सकती है।

— दावोस

यह अभी भी यहां सबसे अच्छा समाधान है। ध्यान दें कि Redshift में, आप इसे पैरामीटर समूह सेटिंग्स के माध्यम से सेट कर सकते हैं, केवल यह कि इसमें होना चाहिए msअर्थात 900 s = 16 मिनट = 900000ms।

— नलदेव

GCP पर इसे अपडेट करने के लिए, ms cloud.google.com/sql/docs/postgres/…

— HowMuchCheeseIsTooMuchCheese

बशर्ते स्टैंडबाय का उद्देश्य उदाहरण के लिए रिपोर्टिंग है और यह एक हॉट स्टैंडबाय नहीं है जिसे विफलता से निपटने के लिए तैयार रहने की आवश्यकता है, यह बिल्कुल सबसे अच्छा जवाब है।

— सूपडॉग

Answer 3

मास्टर पर निष्क्रिय लेनदेन शुरू करने की कोई आवश्यकता नहीं है। Postgresql-9.1 में इस समस्या को हल करने का सबसे सीधा तरीका सेटिंग द्वारा है

hot_standby_feedback = on

यह मास्टर को लंबे समय तक चलने वाले प्रश्नों से अवगत कराएगा। से डॉक्स :

पहला विकल्प पैरामीटर hot_standby_feedback को सेट करना है, जो VACUUM को हाल ही में मृत पंक्तियों को हटाने से रोकता है और इसलिए क्लीनअप विरोध उत्पन्न नहीं होता है।

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

Comments

इस परम को स्टैंडबाय पर सेट किया जाना चाहिए।

— स्टीव केहलेट

इस मामले में मास्टर के लिए कुछ नुकसान हैं हॉट-स्टैंडबाय-प्रतिक्रिया

— एवगेनी लिस्कोवेट्स

Answer 4

जैसा कि कहा गया यहाँ के बारे में hot_standby_feedback = on:

खैर, इसका नुकसान यह है कि स्टैंडबाय मास्टर को फुला सकता है, जो कुछ लोगों के लिए भी आश्चर्यजनक हो सकता है

और यहाँ :

किस सेटिंग के साथ max_standby_streaming_delay? मैं इसके बजाय डिफ़ॉल्ट से -1 पर डिफ़ॉल्ट hot_standby_feedback पर जाऊंगा। इस तरह आप स्टैंडबाय पर जो करते हैं, वह केवल स्टैंडबाय को प्रभावित करता है

तो मैंने जोड़ा

max_standby_streaming_delay = -1

और pg_dumpन ही हमारे लिए और अधिक त्रुटि, और न ही मास्टर ब्लोट :)

AWS RDS उदाहरण के लिए, http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html देखें

Comments

@ लेन्नार्ड, यह मेरे लिए काम किया। मैंने इस कॉन्फिगरेशन को गुलाम के पोस्टग्रैसक्कल.कॉन्फ पर जोड़ा, फिर स्लेव को फिर से शुरू किया।

— अर्दी अराम

आप इस तरह से, बेशक प्रतिकृति अंतराल प्राप्त कर सकते हैं। और यदि आप प्रतिकृति प्रतिकृति का उपयोग कर रहे हैं, तो प्रतिकृति को मास्टर से कनेक्ट करने के लिए, जिसके परिणामस्वरूप मास्टर पर अत्यधिक क्लॉग प्रतिधारण हो सकता है, इसलिए यदि आप वाल आर्काइविंग का उपयोग कर रहे हैं तो यह वास्तव में केवल व्यवहार्य है।

— क्रेग रिंगर

AWS RDS पर इसे कैसे सेट करें?

— Kris MP

@KrisMP उपयोग psql

— Yehonatan

पैरामीटर समूह में @KMPMP

— docs.aws.amazon.com/AmazonRDS/latest/UserGuide/…

Answer 5

हॉट स्टैंडबाय स्लेव सर्वर पर तालिका डेटा को संशोधित किया गया है जबकि एक लंबी चलने वाली क्वेरी चल रही है। एक समाधान (PostgreSQL 9.1+) यह सुनिश्चित करने के लिए कि तालिका डेटा संशोधित नहीं है, क्वेरी के बाद प्रतिकृति को स्थगित करना और फिर से शुरू करना है:

select pg_xlog_replay_pause(); -- suspend
select * from foo; -- your query
select pg_xlog_replay_resume(); --resume

Comments

इसके लिए सुपरयुसर अधिकारों की आवश्यकता है। तो यह कुछ मामलों में एक समाधान नहीं हो सकता है।

— जोआ बाल्टाजार

PostgreSQL 10 में, के xlogसाथ प्रतिस्थापित किया गया था wal, इसलिए आप कॉल करना चाहते हैं pg_wal_replay_pause()और pg_wal_replay_resume()।

— Womble

Answer 6

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

इसलिए हम Postgres प्रॉपर्टी में hot_standby_feedback प्रॉपर्टी को एनेबल करके इसे हल करते हैं। हमने निम्न लिंक का उल्लेख किया है

https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/

मुझे उम्मीद है इससे मदद मिलेगी।

Answer 7

मैं कुछ अपडेट की गई जानकारी और संदर्भों को जोड़ने जा रहा हूं @ अधिकतम-मालिष का उत्कृष्ट उत्तर।

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

1. थोड़ी देर के लिए वाल एक्शन के आवेदन में देरी करें, गुलाम को अपने परस्पर विरोधी लेनदेन को समाप्त करने की अनुमति दें, फिर कार्रवाई लागू करें।
2. दास पर परस्पर विरोधी क्वेरी को रद्द करें।

हम # 1, और दो मूल्यों से चिंतित हैं:

• max_standby_archive_delay - यह मास्टर और दास के बीच लंबे समय तक वियोग के बाद उपयोग में देरी है, जब डेटा को वाल आर्क से पढ़ा जा रहा है, जो वर्तमान डेटा नहीं है।
• max_standby_streaming_delay - जब वाल एंट्री स्ट्रीमिंग प्रतिकृति के माध्यम से प्राप्त की जाती है, तो प्रश्नों को रद्द करने के लिए उपयोग में देरी।

आमतौर पर, यदि आपका सर्वर उच्च उपलब्धता प्रतिकृति के लिए है, तो आप इन नंबरों को छोटा रखना चाहते हैं। की डिफ़ॉल्ट सेटिंग 30000(मिलीसेकंड यदि कोई इकाई नहीं दी गई है) इसके लिए पर्याप्त है। यदि, फिर भी, आप संग्रह, रिपोर्टिंग- या रीड-प्रतिकृति जैसी कोई चीज़ सेट करना चाहते हैं, जिसमें बहुत लंबे समय तक चलने वाले प्रश्न हो सकते हैं, तो आप रद्द किए गए प्रश्नों से बचने के लिए इसे कुछ और ऊपर सेट करना चाहेंगे। 900sऊपर दी गई अनुशंसित सेटिंग एक अच्छे शुरुआती बिंदु की तरह लगती है। मैं -1एक अच्छा विचार होने के रूप में एक अनंत मूल्य की स्थापना पर आधिकारिक डॉक्स से असहमत हूं - जो कि कुछ छोटी गाड़ी कोड को मुखौटा बना सकता है और बहुत सारे मुद्दों का कारण बन सकता है।

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

कैसे max_standby_archive_delayऔर max_standby_streaming_delayकाम की पूरी व्याख्या के लिए , यहां क्यों जाएं ।

Answer 8

इसी तरह, यहां ऊपर-ऊपर, दोनों के ऊपर @ अधिकतम-मल्श के शानदार जवाब @ आर्टिफ 3 एक्स के विस्तार के लिए दूसरा कैविएट है।

मास्टर से लेन-देन के किसी भी विलंबित आवेदन के साथ अनुयायी के पास डेटा का एक पुराना, बासी दृश्य होगा। इसलिए, अधिकतम_मस् ताव_आर्काइव_डेल और मैक्सिमम_स्टेब_स्ट्रीमिंग_डेल को सेट करके फॉलोअर को क्वेरी के लिए समय प्रदान करने से समझ में आता है, इन दोनों को ध्यान में रखें:

• एक स्टैंडबाय / बैकअप के रूप में अनुयायी का मूल्य कम हो जाता है
• अनुयायी पर चल रहे किसी भी अन्य प्रश्नों से बासी डेटा वापस आ सकता है ।

यदि बैकअप क्वेरी के लिए अनुयायी का मूल्य होस्टिंग प्रश्नों के साथ बहुत अधिक संघर्ष हो रहा है, तो एक समाधान कई अनुयायियों का होगा, प्रत्येक को एक या दूसरे के लिए अनुकूलित किया जाएगा।

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