हमने PostgreSQL के साथ आपदा वसूली के लिए आस्थगित प्रतिकृति का उपयोग कैसे किया

प्रतिकृति बैकअप नहीं है। या नहीं? यहां बताया गया है कि कैसे हमने गलती से शॉर्टकट डिलीट करके रिकवरी के लिए आस्थगित प्रतिकृति का उपयोग किया।

GitLab पर इन्फ्रास्ट्रक्चर विशेषज्ञ GitLab.com को चलाने के लिए जिम्मेदार हैं, जो कि प्रकृति में GitLab का सबसे बड़ा उदाहरण है। 3 मिलियन उपयोगकर्ता और लगभग 7 मिलियन प्रोजेक्ट हैं, और यह समर्पित आर्किटेक्चर के साथ सबसे बड़े ओपन सोर्स सास साइटों में से एक है। PostgreSQL डेटाबेस सिस्टम के बिना, GitLab.com इन्फ्रास्ट्रक्चर बहुत दूर नहीं जाएगा, और डेटा खो जाने पर किसी भी विफलता के मामले में हम गलती के लिए इसे बर्दाश्त नहीं करेंगे। यह संभावना नहीं है कि इस तरह की तबाही होगी, लेकिन हम अलग-अलग बैकअप और प्रतिकृति तंत्र के साथ अच्छी तरह से तैयार और तैयार हैं।

प्रतिकृति आपके लिए एक डेटाबेस बैकअप उपकरण नहीं है ( नीचे देखें )। लेकिन अब हम देखेंगे कि कैसे जल्दी से हटाए गए प्रतिकृति का उपयोग करके गलती से हटाए गए डेटा को पुनर्प्राप्त किया जा सकता है: GitLab.com पर , उपयोगकर्ता ने gitlab-ce परियोजना के लिए शॉर्टकट को हटा दिया और मर्ज अनुरोधों और कार्यों के साथ संपर्क खो दिया।

विलंबित प्रतिकृति के साथ, हमने केवल 1.5 घंटों में डेटा पुनर्प्राप्त किया। देखिए कैसा था।

PostgreSQL के साथ प्वाइंट-इन-टाइम रिकवरी

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

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

आस्थगित प्रतिकृति क्या है?

विलंबित प्रतिकृति विलंब परिवर्तन के अनुप्रयोग है। यही है, लेन-देन घंटे X पर हुआ, लेकिन यह प्रति घंटे X + d देरी से प्रतिकृति में दिखाई देगा।

PostgreSQL में डेटाबेस की भौतिक प्रतिकृति को कॉन्फ़िगर करने के 2 तरीके हैं: संग्रह और स्ट्रीमिंग प्रतिकृति से पुनर्स्थापित करें। संग्रह से पुनर्स्थापित करना , वास्तव में, PITR की तरह काम करता है, लेकिन लगातार: हम लगातार वाल आर्क से परिवर्तन निकालते हैं और उन्हें प्रतिकृति पर लागू करते हैं। और स्ट्रीमिंग प्रतिकृति सीधे अपस्ट्रीम डेटाबेस होस्ट से वाल स्ट्रीम को पुनः प्राप्त करता है। हम संग्रह से पुनर्प्राप्ति पसंद करते हैं - यह प्रबंधन करना आसान है और सामान्य प्रदर्शन है, जो काम करने वाले क्लस्टर से पीछे नहीं है।

संग्रह से आस्थगित पुनर्प्राप्ति कैसे सेट करें

पुनर्प्राप्ति विकल्प recovery.conf . recovery.conf फ़ाइल में वर्णित हैं । एक उदाहरण:

 standby_mode = 'on' restore_command = '/usr/bin/envdir /etc/wal-ed/env /opt/wal-e/bin/wal-e wal-fetch -p 4 "%f" "%p"' recovery_min_apply_delay = '8h' recovery_target_timeline = 'latest' 

इन मापदंडों के साथ, हमने संग्रह से पुनर्प्राप्ति के साथ एक आलसी प्रतिकृति की स्थापना की। यहां वॉक-ई का उपयोग restore_command से वाल सेगमेंट ( restore_command ) निकालने के लिए किया जाता है, और बदलाव आठ घंटे ( recovery_min_apply_delay ) के बाद लागू किए जाएंगे। प्रतिकृति संग्रह में समयरेखा में परिवर्तन की निगरानी करेगी, उदाहरण के लिए, क्लस्टर में recovery_target_timeline कारण ( recovery_target_timeline )।

recovery_min_apply_delay साथ recovery_min_apply_delay आप विलंबित स्ट्रीमिंग प्रतिकृति को कॉन्फ़िगर कर सकते हैं, लेकिन कुछ ऐसे ट्रिक्स हैं जो प्रतिकृति स्लॉट्स, हॉट स्पेयर फीडबैक और इसी तरह से जुड़े हैं। वाल संग्रह आपको उनसे बचने की अनुमति देता है।

recovery_min_apply_delay पैरामीटर केवल PostgreSQL 9.3 में दिखाई दिया। पिछले संस्करणों में, आस्थगित प्रतिकृति के लिए, आपको पुनर्प्राप्ति प्रबंधन फ़ंक्शन ( pg_xlog_replay_pause(), pg_xlog_replay_resume() ) के संयोजन को कॉन्फ़िगर करने की आवश्यकता होती है या समय की देरी के लिए संग्रह में वाल सेगमेंट रखने की आवश्यकता होती है।

PostgreSQL यह कैसे करता है?

यह देखने के लिए उत्सुक है कि PostgreSQL कैसे पुनर्प्राप्ति को स्थगित करता है। चलो recoveryApplyDelay(XlogReaderState) पर नजर recoveryApplyDelay(XlogReaderState) । यह वाल में प्रत्येक प्रविष्टि के लिए मुख्य लूप से कहा जाता है।

 static bool recoveryApplyDelay(XLogReaderState *record) { uint8 xact_info; TimestampTz xtime; long secs; int microsecs; /* nothing to do if no delay configured */ if (recovery_min_apply_delay <= 0) return false; /* no delay is applied on a database not yet consistent */ if (!reachedConsistency) return false; /* * Is it a COMMIT record? * * We deliberately choose not to delay aborts since they have no effect on * MVCC. We already allow replay of records that don't have a timestamp, * so there is already opportunity for issues caused by early conflicts on * standbys. */ if (XLogRecGetRmid(record) != RM_XACT_ID) return false; xact_info = XLogRecGetInfo(record) & XLOG_XACT_OPMASK; if (xact_info != XLOG_XACT_COMMIT && xact_info != XLOG_XACT_COMMIT_PREPARED) return false; if (!getRecordTimestamp(record, &xtime)) return false; recoveryDelayUntilTime = TimestampTzPlusMilliseconds(xtime, recovery_min_apply_delay); /* * Exit without arming the latch if it's already past time to apply this * record */ TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime, &secs, &microsecs); if (secs <= 0 && microsecs <= 0) return false; while (true) { // Shortened: // Use WaitLatch until we reached recoveryDelayUntilTime // and then break; } return true; } 

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

डेटा को पुनर्प्राप्त करने के लिए आलसी प्रतिकृति का उपयोग कैसे करें

मान लीजिए कि हमारे पास उत्पादन में एक डेटाबेस क्लस्टर और आठ घंटे की देरी के साथ एक प्रतिकृति है। आइए देखें कि गलती से शॉर्टकट हटाने के उदाहरण का उपयोग करके डेटा को कैसे पुनर्प्राप्त किया जाए।

जब हमें समस्या के बारे में पता चला, तो हमने आलसी प्रतिकृति के लिए संग्रह से पुनर्प्राप्ति रोक दी:

 SELECT pg_xlog_replay_pause(); 

विराम के साथ, हमें कोई जोखिम नहीं था कि प्रतिकृति DELETE अनुरोध DELETE । उपयोगी बात अगर आपको इसे जानने का समय चाहिए।

लब्बोलुआब यह है कि DELETE प्रतिकृति को DELETE अनुरोध से पहले बिंदु तक पहुंचना चाहिए। हम मोटे तौर पर हटाने का भौतिक समय जानते थे। हमने recovery_min_apply_delay हटा दिया और recovery_target_time को recovery.conf जोड़ दिया। तो देरी के बिना प्रतिकृति सही समय पर पहुंचती है:

 recovery_target_time = '2018-10-12 09:25:00+00' 

स्टैम्प के साथ, अतिरिक्त को कम करना बेहतर है ताकि याद न हो। सच है, अधिक से अधिक कमी, अधिक डेटा हम खो देते हैं। फिर से, यदि हम DELETE अनुरोध के माध्यम से DELETE हैं, तो सब कुछ फिर से हटा दिया जाएगा और आपको फिर से शुरू करना होगा (या PITR के लिए एक ठंडा बैकअप भी लेना होगा)।

हमने पोस्टग्रेज के स्थगित उदाहरण को फिर से शुरू किया और निर्दिष्ट समय तक वाल सेगमेंट को दोहराया गया। आप अनुरोध द्वारा इस स्तर पर प्रगति को ट्रैक कर सकते हैं:

 SELECT -- current location in WAL pg_last_xlog_replay_location(), -- current transaction timestamp (state of the replica) pg_last_xact_replay_timestamp(), -- current physical time now(), -- the amount of time still to be applied until recovery_target_time has been reached '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay; 

यदि समय की मोहर अब नहीं बदलती है, तो वसूली पूरी हो जाती है। आप recovery_target_action बाद (उदाहरण के लिए इसे रोक सकते हैं) द्वारा recovery_target_action क्रिया को बंद, अग्रिम, या कॉन्फ़िगर करने के लिए कॉन्फ़िगर कर सकते हैं।

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

टाइमस्टैम्प के बजाय, लेनदेन आईडी का उपयोग करना बेहतर है। इन आईडी को लिखना उपयोगी है, उदाहरण के लिए, डीडीएल स्टेटमेंट्स (जैसे log_statements = 'ddl' DROP TABLE ) के लिए, log_statements = 'ddl' का उपयोग log_statements = 'ddl' । यदि हमारे पास कोई लेन-देन आईडी है, तो हम recovery_target_xid लेंगे और DELETE अनुरोध से पहले लेनदेन के लिए सब कुछ नीचे चलाएंगे।

काम पर वापस जाना बहुत सरल है: recovery.conf से सभी परिवर्तनों को हटा दें। कॉन्फ़िगर करें और पोस्टग्रेज पुनः आरंभ करें। जल्द ही, प्रतिकृति में आठ घंटे की देरी फिर से दिखाई देगी, और हम भविष्य की परेशानियों के लिए तैयार हैं।

वसूली लाभ

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

एक विलंबित प्रतिकृति दो तरीकों से ठंडे बैकअप से बेहतर है:

1. संग्रह से संपूर्ण आधार बैकअप प्राप्त करने की आवश्यकता नहीं है।
2. वाल सेगमेंट की एक निश्चित आठ घंटे की खिड़की है जिसे दोहराया जाना चाहिए।

हम लगातार यह भी जांचते हैं कि क्या वाल से पीआईटीआर बनाना संभव है, और हम वाल आर्क के साथ नुकसान या अन्य समस्याओं को जल्दी से नोटिस करेंगे, विलंबित प्रतिकृति के अंतराल की निगरानी करेंगे।

इस उदाहरण में, हमें ठीक होने में 50 मिनट का समय लगा, यानी गति 110 GB वाल डेटा प्रति घंटा (संग्रह अभी भी AWS S3 पर था)। कुल मिलाकर, हमने समस्या को हल किया और 1.5 घंटे में डेटा को पुनर्स्थापित किया।

नीचे पंक्ति: जहां विलंबित प्रतिकृति काम में आती है (और जहां नहीं)

यदि आप गलती से डेटा खो देते हैं और कॉन्फ़िगर देरी के भीतर इस आपदा को नोटिस करते हैं, तो प्राथमिक उपचार के रूप में आलसी प्रतिकृति का उपयोग करें।

लेकिन ध्यान रखें: प्रतिकृति बैकअप नहीं है।

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

एक विलंबित प्रतिकृति के साथ भी, हमें कभी-कभी एक सुरक्षित स्थान पर ठंडे बैकअप की आवश्यकता होती है यदि कोई डेटा केंद्र क्रैश हो जाता है, छिपी हुई क्षति या अन्य घटनाएँ जिन्हें आप तुरंत नोटिस नहीं करते हैं। एक प्रतिकृति से कोई मतलब नहीं है।

नोट। GitLab.com पर, अब हम केवल सिस्टम स्तर पर डेटा हानि से सुरक्षा करते हैं और उपयोगकर्ता स्तर पर डेटा को पुनर्स्थापित नहीं करते हैं।