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

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

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

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

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

PostgreSQL के साथ समय पुनर्प्राप्ति को इंगित करें

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

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

विलंबित प्रतिकृति क्या है?

आलसी प्रतिकृति वाल से परिवर्तनों को देरी से लागू करना है। यानी एक घंटे में ट्रांजैक्शन हो गया X, लेकिन यह प्रतिकृति में देरी से दिखाई देगा d ज X + d.

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

किसी संग्रह से विलंबित पुनर्प्राप्ति कैसे सेट करें

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

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

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

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

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

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

यह देखना दिलचस्प है कि PostgreSQL आलसी पुनर्प्राप्ति को कैसे कार्यान्वित करता है। आइए देखें 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. हम हटाने का भौतिक समय लगभग जानते थे। हमने हटा दिया है recovery_min_apply_delay और जोड़ा recovery_target_time в recovery.conf. इस प्रकार प्रतिकृति बिना किसी देरी के सही समय पर पहुंचती है:

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

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

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

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पुनः प्रयास के बाद इंस्टेंस को बंद करना, बढ़ावा देना या रोकना (यह डिफ़ॉल्ट रूप से निलंबित है)।

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

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

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

पुनर्प्राप्ति लाभ

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

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

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

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

इस उदाहरण में, हमें पुनर्स्थापित करने में 50 मिनट लगे, जिसका अर्थ है कि गति प्रति घंटे 110 जीबी वाल डेटा थी (संग्रह अभी भी चालू था) एडब्ल्यूएस एस 3). कुल मिलाकर, हमने 1,5 घंटे में समस्या हल कर दी और डेटा पुनर्प्राप्त कर लिया।

परिणाम: जहां एक विलंबित प्रतिकृति उपयोगी है (और जहां यह नहीं है)

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

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

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

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

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

स्रोत: www.habr.com