हामीले कसरी PostgreSQL सँग विपद् रिकभरीको लागि ढिलाइ भएको प्रतिकृति प्रयोग गर्यौं

प्रतिकृति ब्याकअप होइन। कि हैन? गल्तिले सर्टकटहरू मेटाउनेबाट पुन: प्राप्ति गर्न हामीले स्थगित प्रतिकृति प्रयोग गर्ने तरिका यहाँ छ।

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

प्रतिकृति डेटाबेस ब्याकअप गर्ने माध्यम होइन (तल हेर्नुहोस्)। तर अब हामी अल्छी प्रतिकृति प्रयोग गरेर दुर्घटनावश मेटाइएको डाटा कसरी छिटो रिकभर गर्ने भनेर हेर्नेछौं: अन GitLab.com प्रयोगकर्ता सर्टकट हटाइयो परियोजनाको लागि gitlab-ce र मर्ज अनुरोध र कार्यहरु संग जडान हराएको छ।

स्थगित प्रतिकृतिको साथ, हामीले केवल 1,5 घण्टामा डाटा पुन: प्राप्त गर्यौं। हेरौ कस्तो भयो ।

PostgreSQL को साथ समय रिकभरीमा बिन्दु

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

चिसो ब्याकअपको लागि यो सुविधा प्रयोग गर्न, हामी नियमित रूपमा आधारभूत डाटाबेस ब्याकअप बनाउँछौं र यसलाई अभिलेखमा भण्डारण गर्छौं (GitLab अभिलेखहरू लाइभ इन गुगल क्लाउड भण्डारण)। हामी डाटाबेसको स्थितिमा भएका परिवर्तनहरू पनि लेख्ने-अगाडि लग संग्रह गरेर निगरानी गर्छौं (अगाडि लेख्नुहोस्, वाल)। र यी सबै ठाउँमा राखेर, हामी विपद् रिकभरीको लागि PITR गर्न सक्छौं: असफल हुनु अघि लिइएको स्न्यापसटबाट सुरु गर्दै, र WAL अभिलेखबाट असफलतासम्म परिवर्तनहरू लागू गर्दै।

स्थगित प्रतिकृति के हो?

अल्छी प्रतिकृति भनेको ढिलाइ संग WAL बाट परिवर्तनहरूको आवेदन हो। अर्थात्, लेनदेन एक घण्टामा भयो X, तर यो ढिलाइ संग प्रतिकृति मा देखा पर्नेछ d एक घण्टामा X + d.

PostgreSQL सँग भौतिक डाटाबेस प्रतिकृति सेटअप गर्ने २ तरिकाहरू छन्: ब्याकअप रिकभरी र स्ट्रिमिङ प्रतिकृति। अभिलेखबाट पुनर्स्थापना गर्दै, अनिवार्य रूपमा PITR जस्तै काम गर्दछ, तर लगातार: हामी निरन्तर WAL अभिलेखबाट परिवर्तनहरू पुन: प्राप्त गर्छौं र तिनीहरूलाई प्रतिकृतिमा लागू गर्छौं। ए स्ट्रिमिङ प्रतिकृति अपस्ट्रीम डाटाबेस होस्टबाट WAL स्ट्रिम सिधै पुन: प्राप्त गर्दछ। हामी अभिलेख रिकभरीलाई प्राथमिकता दिन्छौं - यो व्यवस्थापन गर्न सजिलो छ र उत्पादन क्लस्टरसँग कायम रहने सामान्य कार्यसम्पादन छ।

अभिलेखबाट ढिलाइ भएको रिकभरी कसरी सेट अप गर्ने

रिकभरी विकल्पहरू फाइलमा वर्णन गरिएको छ 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'

यी प्यारामिटरहरूसँग, हामीले ब्याकअप रिकभरीको साथ स्थगित प्रतिकृति कन्फिगर गर्यौं। यहाँ यो प्रयोग गरिन्छ wal-e WAL खण्डहरू निकाल्न (restore_command) अभिलेखबाट, र परिवर्तनहरू आठ घण्टा पछि लागू हुनेछन् (recovery_min_apply_delay)। प्रतिकृतिले सङ्ग्रहमा टाइमलाइन परिवर्तनहरू हेर्ने छ, उदाहरणका लागि क्लस्टर फेलओभरको कारण (recovery_target_timeline).

С recovery_min_apply_delay तपाइँ ढिलाइ संग स्ट्रिमिङ प्रतिकृति सेटअप गर्न सक्नुहुन्छ, तर यहाँ केहि समस्याहरू छन् जुन प्रतिकृति स्लटहरू, हट स्ट्यान्डबाइ प्रतिक्रिया, र यस्तै अन्यसँग सम्बन्धित छन्। WAL अभिलेखले तपाईंलाई तिनीहरूबाट बच्न अनुमति दिन्छ।

परिमिति recovery_min_apply_delay PostgreSQL 9.3 मा मात्र देखा पर्‍यो। अघिल्लो संस्करणहरूमा, स्थगित प्रतिकृतिको लागि तपाईंले संयोजन कन्फिगर गर्न आवश्यक छ रिकभरी व्यवस्थापन कार्यहरू (pg_xlog_replay_pause(), pg_xlog_replay_resume()) वा ढिलाइको अवधिको लागि अभिलेखमा WAL खण्डहरू होल्ड गर्नुहोस्।

PostgreSQL ले यो कसरी गर्छ?

PostgreSQL ले अल्छी रिकभरी कसरी लागू गर्दछ भनेर हेर्नको लागि यो रोचक छ। हेरौं recoveryApplyDelay(XlogReaderState)। बाट बोलाइएको छ मुख्य दोहोरिने लूप WAL बाट प्रत्येक प्रविष्टिको लागि।

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, सबै कुरा फेरि मेटाइनेछ र तपाईंले फेरि सुरु गर्नुपर्नेछ (वा PITR को लागि चिसो ब्याकअप पनि लिनुहोस्)।

हामीले स्थगित पोस्टग्रेस उदाहरण पुन: सुरु गर्यौं र निर्दिष्ट समय सम्म WAL खण्डहरू दोहोर्याइयो। तपाईंले यस चरणमा सोधेर प्रगति ट्र्याक गर्न सक्नुहुन्छ:

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पुन: प्रयास पछि उदाहरण बन्द गर्न, प्रवर्द्धन गर्न वा पज गर्न (यो पूर्वनिर्धारित रूपमा निलम्बित हुन्छ)।

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

टाइमस्ट्याम्पको सट्टा, लेनदेन आईडीहरू प्रयोग गर्नु राम्रो हुन्छ। यी आईडीहरू रेकर्ड गर्न उपयोगी छ, उदाहरणका लागि, DDL कथनहरू (जस्तै DROP TABLE), प्रयोग गरेर log_statements = 'ddl'। यदि हामीसँग लेनदेन आईडी थियो भने, हामी लिन्छौं recovery_target_xid र अनुरोध अघि सबै लेनदेन तल दौडियो DELETE.

काममा फर्कन धेरै सरल छ: सबै परिवर्तनहरू हटाउनुहोस् recovery.conf र Postgres पुन: सुरु गर्नुहोस्। प्रतिकृति चाँडै नै फेरि आठ घण्टा ढिलाइ हुनेछ, र हामी भविष्य समस्याहरूको लागि तयार छौं।

रिकभरी लाभहरू

चिसो ब्याकअपको सट्टा स्थगित प्रतिकृतिको साथ, तपाईंले अभिलेखबाट सम्पूर्ण छवि पुनर्स्थापना गर्न घण्टा खर्च गर्नु पर्दैन। उदाहरणका लागि, सम्पूर्ण आधारभूत २ TB ब्याकअप प्राप्त गर्न हामीलाई पाँच घण्टा लाग्छ। र त्यसपछि तपाईंले अझै पनि आवश्यक स्थितिमा पुन: प्राप्ति गर्न सम्पूर्ण दैनिक WAL लागू गर्नुपर्नेछ (खराब अवस्थामा)।

एक स्थगित प्रतिकृति दुई तरिकामा कोल्ड ब्याकअप भन्दा राम्रो छ:

1. अभिलेखबाट सम्पूर्ण आधारभूत ब्याकअप हटाउन आवश्यक छैन।
2. त्यहाँ WAL खण्डहरूको निश्चित आठ-घण्टा सञ्झ्याल छ जुन दोहोर्याउनु पर्छ।

हामी WAL बाट PITR बनाउन सम्भव छ कि छैन भनेर निरन्तर जाँच गर्छौं, र स्थगित प्रतिकृतिको ढिलाइको अनुगमन गरेर हामी चाँडै भ्रष्टाचार वा WAL अभिलेखमा अन्य समस्याहरू देख्नेछौं।

यस उदाहरणमा, यसले हामीलाई पुनर्स्थापना गर्न 50 मिनेट लियो, यसको अर्थ गति 110 GB WAL डाटा प्रति घण्टा थियो (संग्रह अझै सक्रिय थियो। AWS S3)। कुलमा, हामीले समस्या समाधान गर्यौं र 1,5 घण्टामा डाटा पुन: प्राप्त गर्‍यौं।

नतिजाहरू: जहाँ स्थगित प्रतिकृति उपयोगी छ (र जहाँ यो छैन)

यदि तपाईंले गल्तिले डाटा हराउनुभयो र कन्फिगर गरिएको ढिलाइ भित्र यो समस्या देख्नुभयो भने, पहिलो सहायताको रूपमा ढिलाइ भएको प्रतिकृति प्रयोग गर्नुहोस्।

तर ध्यान राख्नुहोस्: प्रतिकृति ब्याकअप होइन।

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

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

भन्नु... माथि GitLab.com हामी हाल प्रणाली स्तरमा डाटा हानिबाट मात्र सुरक्षा गर्छौं र प्रयोगकर्ता स्तरमा डाटा रिकभर गर्दैनौं।

स्रोत: www.habr.com