PostgreSQL
 sql >> डेटाबेस >  >> RDS >> PostgreSQL

हॉट स्टैंडबाय डिप्लॉयमेंट में ट्रेड-ऑफ

आगामी पोस्टग्रेएसक्यूएल 9.0 में नया हॉट स्टैंडबाय फीचर स्टैंडबाय नोड्स के खिलाफ चल रहे प्रश्नों की अनुमति देता है जो पहले कुछ भी नहीं करते थे, लेकिन पुनर्प्राप्ति प्रक्रिया को निष्पादित करते थे। इस सुविधा का अनुमान लगाने वाले उपयोगकर्ताओं से मैंने जो दो सामान्य अपेक्षाएँ सुनी हैं, वह यह है कि यह या तो दोनों नोड्स में छोटे प्रश्नों को वितरित करने की अनुमति देगा, या मास्टर पर संसाधनों का उपयोग किए बिना स्टैंडबाय के खिलाफ लंबी रिपोर्ट चलाने की अनुमति देगा। ये दोनों अभी करना संभव है, लेकिन जब तक आप हॉट स्टैंडबाय के काम करने के तरीके में शामिल ट्रेड-ऑफ को नहीं समझते हैं, तब तक यहां कुछ अप्रत्याशित व्यवहार हो सकता है।

लंबे समय तक चलने वाली मानक क्वेरी

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

हॉट स्टैंडबाय सीमाएं

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

  • एक हॉट अपडेट या VACUUM संबंधित अपडेट किसी ऐसी चीज को हटाने के लिए आता है जिसे क्वेरी दिखाई देने की उम्मीद करती है
  • एक बी-ट्री विलोपन प्रकट होता है
  • आपके द्वारा चलाई जा रही क्वेरी और अपडेट को संसाधित करने के लिए कौन से लॉक की आवश्यकता है, के बीच एक लॉकिंग समस्या है।

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

अच्छा, तेज़, सस्ता:दो चुनें

अनिवार्य रूप से, तीन चीजें हैं जिन्हें लोग प्राथमिकता देना चाहेंगे:

  1. मास्टर लिमिटिंग से बचें:xids और संबंधित स्नैपशॉट को मास्टर पर असीमित रूप से आगे बढ़ने दें, ताकि VACUUM और इसी तरह की क्लीनअप स्टैंडबाय द्वारा किए जा रहे कार्यों से पीछे न रहे
  2. असीमित क्वेरी:किसी भी समय के लिए स्टैंडबाय पर क्वेरी चलाएँ
  3. वर्तमान पुनर्प्राप्ति:मास्टर पर क्या हो रहा है, इसके साथ पुनर्प्राप्ति प्रक्रिया को स्टैंडबाय पर रखें, जिससे HA के लिए तेज़ी से विफल हो जाए

हॉट स्टैंडबाय के साथ किसी भी स्थिति में, तीनों को एक साथ रखना सचमुच असंभव है। आप केवल अपना ट्रेड-ऑफ चुन सकते हैं। उपलब्ध ट्यून करने योग्य पैरामीटर आपको पहले से ही कुछ तरीकों से अनुकूलित करने देते हैं:

  • इन सभी विलंब/स्थगित सेटिंग्स को अक्षम करना हमेशा वर्तमान पुनर्प्राप्ति के लिए अनुकूलित करता है, लेकिन फिर आप पाएंगे कि आपकी अपेक्षा से अधिक क्वेरी रद्द होने की संभावना है।
  • अधिकतम_स्टैंडबाय_देरी पुनर्प्राप्ति को चालू रखने की कीमत पर, लंबी क्वेरी के लिए अनुकूलित करता है। यह एक बार स्टैंडबाय में अपडेट लागू करने में देरी करता है जो एक समस्या पैदा करेगा (HOT, VACUUM, B-tree delete, आदि) प्रकट होता है।
  • vacuum_defer_cleanup_age और कुछ स्नैपशॉट हैक कुछ मास्टर को अन्य दो मुद्दों पर सुधार करने के लिए सीमित कर सकते हैं, लेकिन ऐसा करने के लिए एक कमजोर यूआई के साथ। वैक्यूम_डेफर_क्लीनअप_एज लेनदेन आईडी की इकाइयों में है। इस समस्या के बारे में लोगों के सोचने के तरीके ("कम से कम 1 घंटे के लिए टाल दें ताकि मेरी रिपोर्ट चलेंगी") को इस मान के लिए एक सेटिंग में बदलने के लिए आपको अपने सिस्टम पर प्रति यूनिट समय पर xid मंथन की औसत मात्रा का कुछ अंदाजा होना चाहिए। xid खपत दर को मापने/भविष्यवाणी करने के लिए एक सामान्य या यहां तक ​​कि उचित बात नहीं है। वैकल्पिक रूप से, आप स्टैंडबाय पर लंबे समय तक चलने वाली क्वेरी शुरू करने से पहले प्राथमिक पर एक स्नैपशॉट खोल सकते हैं। इसे पूरा करने के तरीके के रूप में हॉट स्टैंडबाय प्रलेखन में dblink का सुझाव दिया गया है। सैद्धांतिक रूप से स्टैंडबाय पर एक डेमॉन उपयोगकर्ता-भूमि में लिखा जा सकता है, प्राथमिक पर रह रहा है, इस समस्या के आसपास भी काम करने के लिए (साइमन के पास एक के लिए एक बुनियादी डिजाइन है)। मूल रूप से, आप प्रक्रियाओं की एक श्रृंखला शुरू करते हैं जो प्रत्येक एक स्नैपशॉट प्राप्त करते हैं और फिर इसे जारी करने से पहले एक अवधि के लिए सोते हैं। यह अंतर करके कि वे आपके लिए कितने समय तक सोए थे, यह सुनिश्चित कर सकता है कि xid स्नैपशॉट कभी भी मास्टर पर बहुत तेज़ी से आगे नहीं बढ़े। यह पहले से ही स्पष्ट होना चाहिए कि यह कितना भयानक हैक होगा।

संभावित सुधार

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


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. PostgreSQL में मुख्य मूल्य जोड़ी

  2. रेल:पीजी रत्न स्थापित करने में त्रुटि

  3. रिकॉर्ड के कॉलम के माध्यम से लूप

  4. एक एक्सटेंशन बनाने का प्रयास करते समय PostgreSQL त्रुटि

  5. PostgreSQL में कर्सर आधारित रिकॉर्ड