क्षमा करें, मैंने आपकी वसूली तोड़ दी

PostgreSQL में बहुत पुराने समय से पहले से ही संस्करण 8.0, 2005 में वापस जारी किया गया था, एक विशेष कॉन्फ़िगरेशन फ़ाइल पुनर्प्राप्ति .conf का उपयोग समय में एक विशिष्ट बिंदु को पुनर्स्थापित करने के लिए किया गया था । बाद में उसी फ़ाइल को स्टैंडबाय मोड और स्ट्रीमिंग प्रतिकृति के लिए उपयोग किया जाने लगा।

हालाँकि, PostgreSQL 12 की अगली रिलीज़ के बाद से, Recovery.conf अब काम नहीं करेगा: मैंने इसे तोड़ दिया।
लेकिन क्यों?

Recovery.conf की एक विशेषता थी: यह केवल DBMS की शुरुआत में पढ़ा गया था। और अगर पॉइंट-इन-टाइम रिकवरी, जिसे वर्ष में एक बार से कम की आवश्यकता होती है, तब भी इसके साथ सामंजस्य स्थापित किया जा सकता है, तो अपस्ट्रीम प्रतिकृति सर्वर का पता बदलने के लिए पूरे डेटाबेस को पुनरारंभ करने की आवश्यकता कुछ हद तक निराशाजनक है। मैंने इस प्रतिबंध को दरकिनार करने के लिए विकृतियों के विभिन्न तरीकों को देखा, जैसे कि L3 रूटिंग, कैस्केडिंग प्रतिकृति योजनाओं (ताकि सभी प्रतिकृतियां नहीं, बल्कि कम से कम केवल भाग, क्रमशः) और यहां तक ​​कि (भले ही मैंने इसे उत्पादन में नहीं देखा हो) वालबॉन्सर ।

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

फिर, हिम्मत रखते हुए, उसे पोस्टग्रेक्यूएल डेवलपर मेलिंग सूची में भेज दिया । माइकल Paquier क्या बल्कि जल्दी जवाब दिया:

उनमें से कुछ को पुनः लोड करने योग्य बनाने से पहले, आइए हम उन्हें पहले GUCs पर स्विच करें और मापदंडों के SIGHUP हैंडलिंग को फिर से आविष्कार न करें जैसा कि आपका पैच करता है।

उफ़, यह पता चला कि मैंने खोज इंजन को गलत प्रश्न पूछा था। प्रश्न पुनर्प्राप्ति पुनर्प्राप्ति .conf के बारे में नहीं था, लेकिन सभी अन्य DBMS मापदंडों के लिए उपयोग किए जाने वाले GUC अवसंरचना (भव्य एकीकृत कॉन्फ़िगरेशन) के लिए एक अलग पुनर्प्राप्ति .conf से मापदंडों के रूपांतरण के बारे में था। यही है, निश्चित रूप से नहीं, हमें ऐसे पैच की आवश्यकता नहीं है, हम यह नहीं चाहते हैं। आइए पहले इन सभी सेटिंग्स को पुनर्प्राप्ति से स्थानांतरित करें। हमारे मानक सेटिंग्स बुनियादी ढांचे के लिए।

इस उदास खबर पर, मैं जल गया और सोचा: "लेकिन चलो स्थानांतरण!"। मैंने सही खोज क्वेरी पर संग्रहीत चर्चाएँ पढ़ीं, सेटिंग्स को स्थानांतरित करने पर पाई गई अंतिम चर्चा खोली (लिंक कृपया उनके जवाब में माइकल Paquier द्वारा प्रदान की गई थी, जिसके लिए मैं उन्हें अलग से धन्यवाद देता हूं, साथ ही त्वरित प्रतिक्रिया के लिए भी)। उस समय, मई 2018 में, पैच को एक वर्ष से अधिक समय के लिए छोड़ दिया गया था। तो, यहाँ हम शुरू करते हैं। या "जारी" कहना अधिक सही है? मनोरंजन योजना के अनुसार:

1. पैच के नवीनतम प्रकाशित संस्करण में परिवर्तन पढ़ें और सूचीबद्ध करें
2. पैच में परिवर्तन को पार्स करें और कोड बेस के वर्तमान संस्करण में आवश्यक स्थानांतरण करें
3. पुनर्प्राप्ति में सभी संदर्भों को ठीक करें। प्रलेखन में पैरामीटर और उसके पैरामीटर
4. मरम्मत परीक्षण
5. मेलिंग सूची में एक नया पैच भेजें
6. कोई प्रतिक्रिया प्राप्त करें
7. इच्छाओं के अनुसार कुछ ठीक करने के लिए और पैराग्राफ 5 पर लौटें
8. फिर से पैच स्वीकार करने से इनकार करने के लिए (डेढ़ साल में)

एक्शन प्लान जैसा लगता है? खैर, यहाँ हम इसके साथ चलते हैं!

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

मैं पैच पर गया और छोटे शोधन का एक गुच्छा किया। मैंने प्रलेखन को भी बड़े पैमाने पर अद्यतन किया है। संलग्न पैच मेरे लिए सराहनीय है।

यही है, पीटर आइसेंटरट ने अपने विवेक पर कुछ और छोटी चीजों को ठीक किया, प्रलेखन को अद्यतन किया, पूरी तरह से पुनर्प्राप्ति-config.sgml अनुभाग को जला दिया और उनका मानना ​​है कि इस रूप में पैच पहले से ही स्वीकार किया जा सकता है। ओह, और मुझे लगा कि यह केवल पोस्टग्रैस्कल 13 के लिए होगा, भले ही यह इतना भाग्यशाली हो कि पैच आम तौर पर प्रतिबद्ध होने के लिए तत्परता की स्थिति में पहुंच जाएगा।

और कुछ दिनों बाद, इस 2018 के 25 नवंबर को, पीटर आइजेंटरट वास्तव में इस पैच को स्वीकार करता है :

पुनर्प्राप्ति .conf सेटिंग्स अब postgresql.conf (या अन्य GUC स्रोतों) में सेट की गई हैं। वर्तमान में, सभी प्रभावित सेटिंग्स PGC_POSTMASTER हैं; इसे भविष्य में केस द्वारा परिष्कृत किया जा सकता है।
रिकवरी अब एक फ़ाइल पुनर्प्राप्ति द्वारा शुरू की गई है। स्टैंडबाय मोड एक फ़ाइल स्टैंडबाई.सिग्नल द्वारा शुरू किया गया है। स्टैंडबाय_मोड सेटिंग चली गई है। यदि पुनर्प्राप्ति .conf फ़ाइल पाई जाती है, तो एक त्रुटि जारी की जाती है।
ट्रिगर_फाइल सेटिंग का नाम बदलकर इस कदम के हिस्से के रूप में Prom_trigger_file रखा गया है।
प्रलेखन अध्याय "रिकवरी कॉन्फ़िगरेशन" को "सर्वर कॉन्फ़िगरेशन" में एकीकृत किया गया है।
pg_basebackup -R अब सेटिंग्स को postgresql.auto.conf में जोड़ता है और एक स्टैंडबाय.सिग्नल फ़ाइल बनाता है।
लेखक: फ़ूजी मसाओ <मसाओ (डॉट) फूजी (एट) जीमेल (डॉट) कॉम>
लेखक: साइमन रिग्स <साइमन (एट) 2ndquadrant (डॉट) com>
लेखक: अभिजीत मेनन-सेन <ams (at) 2ndquadrant (dot) com>
लेखक: सर्गेई कोर्निलोव <sk (at) zsrv (डॉट) org>

दो हफ्ते बीत चुके हैं और इस कमिट को वापस नहीं लाया गया है। यह आश्चर्यजनक है। और ऐसा लगता है कि वे भी नहीं जा रहे हैं यह अद्भुत है। यह ज्ञात नहीं है कि समुदाय किसी भी दिशा में फिर से व्यवहार को बदलने का फैसला करेगा, खासकर क्योंकि अप्रैल में पोस्टग्रैस 12 की सुविधा फ्रीज रिलीज से पहले अभी भी थोड़ा समय है। लेकिन ऐसा लगता है कि हमारे पास अधिक वसूली नहीं होगी ।conf।

तो क्या बदल गया है

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

पुराना स्टैंडबाय_मोड सेटिंग चली गई है। अब यह, साथ ही पुनर्प्राप्ति मोड को सक्षम करने के लिए पुनर्प्राप्ति के अस्तित्व का बहुत तथ्य है। इसे दो फ़ाइलों (किसी भी सामग्री, आमतौर पर खाली) द्वारा प्रतिस्थापित किया जाता है:

• $ PGDATA / Recovery.signal - वैचारिक उत्तराधिकारी स्टैंडबाय_मॉड = बंद, संग्रह से बहाली को विन्यास में निर्दिष्ट बिंदु पर किया जाएगा;
• $ PGDATA / स्टैंडबाय.सिग्नल - क्रमशः, स्टैंडबाय_मॉड = पर। हम इस फाइल को सभी प्रतिकृतियों पर देखेंगे।

यदि डेटाबेस की स्टार्टअप प्रक्रिया में दोनों फाइलें मिलीं, तो हम मानते हैं कि हम स्टैंडबाय मोड में हैं।

यदि, स्पष्टता के लिए, प्लेट में पैरामीटर परिवर्तन को कम करने के लिए:

पुरानी वसूली	PostgreSQL 12+ postgresql.conf
primary_conninfo	primary_conninfo
primary_slot_name	primary_slot_name
trigger_file	promote_trigger_file
recovery_min_apply_delay	recovery_min_apply_delay
recovery_target	recovery_target
recovery_target_name	recovery_target_name
recovery_target_time	recovery_target_time
recovery_target_xid	recovery_target_xid
recovery_target_lsn	recovery_target_lsn
recovery_target_inclusive	recovery_target_inclusive
recovery_target_timeline	recovery_target_timeline
recovery_target_action	recovery_target_action
restore_command	restore_command
archive_cleanup_command	archive_cleanup_command
recovery_end_command	recovery_end_command

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

recovery_target_lsn = '1/1D9FEA00' recovery_target_xid = '5238954' 

पुनर्प्राप्ति से अंतिम पंक्ति .conf का उपयोग वास्तव में पुनर्प्राप्ति के लिए किया गया था। यह अब संभव नहीं है, वसूली के लिए लक्ष्य को सबसे अधिक एक द्वारा इंगित किया जाना चाहिए। हालाँकि, GUC अवसंरचना के तर्क के कारण, आप अभी भी एक ही नाम के पैरामीटर को कई बार निर्दिष्ट कर सकते हैं:

 recovery_target_lsn = '1/1D9FEA00' recovery_target_lsn = '1/16AC7D0' 

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

और, सामान्य तौर पर, यह सब PostgreSQL के बाहर से दिखाई देने वाले परिवर्तनों के बारे में कहा जाना चाहिए। pg_basebackup -R (- -राइट-रिकवरी-कॉन्फेंस) अपनी जगह पर बना रहा और वही करता है, जो इसका इरादा है, केवल अब यह पुनर्प्राप्ति.conf के बजाय postgresql.auto.conf में पैरामीटर जोड़ देगा और एक स्टैंडबाय बना देगा।

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

मैंने पहले से ही एक पैच प्रकाशित किया है जो प्राथमिक_कोनइनफो और प्राइमरी_साल्ट_नाम को मक्खी पर बदलने की अनुमति देगा। देखते हैं क्या होता है।

क्षमा करें, मैंने आपकी वसूली तोड़ दी

यूपीडी 7 अप्रैल 2019

अंतिम दिन फीचर फ्रीज संस्करण 12 से पहले, आप संक्षेप में बता सकते हैं। रिलीज़ में प्रतिकृति सेटिंग बदलना शामिल नहीं था। बेशक, यह भी एक जिज्ञासु कहानी है। एक बार एक बार, साइमन रिग्स पैच मैंने एक आधार के रूप में लिया जिसमें पहले से ही कनेक्शन सेटिंग्स बदलते समय वालरेसीवर को पुनरारंभ करने के लिए संपादन शामिल थे। मैंने उन्हें प्रलेखन और परीक्षणों के साथ एक अलग पैच पूरक में चुना। और 6 पैच अपडेट और कुछ महीनों की चर्चा के बाद, यह स्पष्ट तथ्य सामने आता है कि यदि आप वालरेसीवर को पुनः आरंभ करते हैं, तो डेटाबेस रिस्टोर_कॉम से फ़ाइलों को पुनर्स्थापित करने के लिए स्विच करने का प्रयास करेगा। किसी भी कारण से वालरेसीवर को बंद करके ट्रिगर किया गया एक साधारण राज्य मशीन व्यवहार, काफी। लेकिन यह पता चला है "कुछ हम नहीं चाहते हैं।" अच्छा, पहले यह कहना असंभव था? ठीक है, मैंने इसे किसी तरह से छुटकारा दिया, लेकिन कैलेंडर में पहले से ही संस्करण 12 के लिए अंतिम प्रतिबद्ध था और कोई भी यहां नहीं देखा गया था। सामान्य तौर पर, यह एक त्वरित बात नहीं है, PostgreSQL में पैच। लेकिन मुझे अपने आप को लोगों की सूची में शामिल करने का पूरा अधिकार है, जिसकी बदौलत सबसे महाकाव्य अधूरा अधूरा REINDEX CONCURRENTLY को संस्करण 12 में शामिल किया गया !

यह अंत में ध्यान देने योग्य है कि कई सेटिंग्स को मक्खी पर बदलने का अवसर मिलता है: संग्रह_क्लीनअप_कमांड, प्रमोटर_टाइगर_फाइल, रिकवरी_एंड_कमांड, रिकवरी_मिन_प्पली_डेल