PostgreSQL सह आपत्ती पुनर्प्राप्तीसाठी आळशी प्रतिकृती कशी वापरली

प्रतिकृती बॅकअप नाही. किंवा नाही? चुकून हटवलेल्या शॉर्टकटमधून पुनर्प्राप्त करण्यासाठी आम्ही पुढे ढकललेली प्रतिकृती कशी वापरली ते येथे आहे.

पायाभूत सुविधा तज्ञ GitLab या कामासाठी जबाबदार आहे GitLab.com - निसर्गातील सर्वात मोठी GitLab उदाहरण. 3 दशलक्ष वापरकर्ते आणि सुमारे 7 दशलक्ष प्रकल्पांसह, ही समर्पित आर्किटेक्चरसह सर्वात मोठी मुक्त स्रोत SaaS साइट आहे. PostgreSQL डेटाबेस सिस्टीम शिवाय, GitLab.com पायाभूत सुविधा फार पुढे जाणार नाही आणि डेटा हरवल्यास कोणत्याही बिघाड झाल्यास फॉल्ट टॉलरन्स सुनिश्चित करण्यासाठी आम्ही काय करत आहोत. अशी आपत्ती घडण्याची शक्यता नाही, परंतु आम्ही विविध बॅकअप आणि प्रतिकृती यंत्रणेसह तयार आणि साठा केलेला आहे.

प्रतिकृती हे डेटाबेसचा बॅकअप घेण्याचे साधन नाही (खाली पहा). पण आता आळशी प्रतिकृती वापरून चुकून हटवलेला डेटा त्वरीत कसा पुनर्प्राप्त करायचा ते आपण पाहू: चालू GitLab.com वापरकर्ता शॉर्टकट हटवला प्रकल्पासाठी gitlab-ce आणि विलीन विनंत्या आणि कार्यांसह कनेक्शन गमावले.

स्थगित प्रतिकृतीसह, आम्ही फक्त 1,5 तासांमध्ये डेटा पुनर्प्राप्त केला. ते कसे घडले ते पहा.

PostgreSQL सह पॉइंट इन टाइम रिकव्हरी

PostgreSQL मध्ये एक अंगभूत फंक्शन आहे जे डेटाबेसची स्थिती वेळेत विशिष्ट बिंदूवर पुनर्संचयित करते. असे म्हणतात पॉइंट-इन-टाइम पुनर्प्राप्ती (PITR) आणि तीच यंत्रणा वापरते जी प्रतिकृती अद्ययावत ठेवते: संपूर्ण डेटाबेस क्लस्टरच्या (बेस बॅकअप) विश्वासार्ह स्नॅपशॉटसह प्रारंभ करून, आम्ही एका विशिष्ट बिंदूपर्यंत राज्य बदलांची मालिका लागू करतो.

कोल्ड बॅकअपसाठी हे वैशिष्ट्य वापरण्यासाठी, आम्ही नियमितपणे बेसिक डेटाबेस बॅकअप बनवतो आणि संग्रहणात संग्रहित करतो (GitLab संग्रहण Google क्लाउड स्टोरेज). आम्ही राईट-अहेड लॉग (लिहा-पुढे लॉग, WAL). आणि या सर्व ठिकाणी, आम्ही आपत्ती पुनर्प्राप्तीसाठी PITR करू शकतो: अयशस्वी होण्यापूर्वी घेतलेल्या स्नॅपशॉटपासून सुरुवात करणे आणि WAL संग्रहणातील बदल अयशस्वी होईपर्यंत लागू करणे.

स्थगित प्रतिकृती म्हणजे काय?

आळशी प्रतिकृती म्हणजे WAL कडून विलंबाने केलेले बदल. म्हणजेच तासाभरात व्यवहार झाला X, परंतु ते विलंबाने प्रतिकृतीमध्ये दिसून येईल d तासात X + d.

पोस्टग्रेएसक्यूएलकडे भौतिक डेटाबेस प्रतिकृती सेट करण्याचे 2 मार्ग आहेत: बॅकअप पुनर्प्राप्ती आणि प्रवाह प्रतिकृती. संग्रहणातून पुनर्संचयित करत आहे, मूलत: 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पुन्‍हा प्रयत्‍न केल्‍यानंतर घटना बंद करणे, प्रचार करणे किंवा विराम देणे (ते डीफॉल्टनुसार निलंबित केले जाते).

त्या दुर्दैवी विनंतीपूर्वी डेटाबेस त्याच्या स्थितीत परत आला. आता आपण, उदाहरणार्थ, डेटा निर्यात करू शकता. आम्ही हटवलेला लेबल डेटा आणि समस्यांचे सर्व दुवे निर्यात केले आणि विनंत्या एकत्र केल्या आणि त्यांना उत्पादन डेटाबेसमध्ये हलवले. नुकसान मोठ्या प्रमाणात असल्यास, तुम्ही फक्त प्रतिकृतीला प्रोत्साहन देऊ शकता आणि मुख्य म्हणून वापरू शकता. परंतु नंतर आपण ज्या बिंदूपर्यंत पुनर्प्राप्त झालो आहोत त्या नंतरचे सर्व बदल गमावले जातील.

टाइमस्टॅम्पऐवजी, व्यवहार आयडी वापरणे चांगले. हे आयडी रेकॉर्ड करणे उपयुक्त आहे, उदाहरणार्थ, डीडीएल स्टेटमेंटसाठी (जसे की DROP TABLE), वापरून log_statements = 'ddl'. आमच्याकडे ट्रान्झॅक्शन आयडी असेल तर आम्ही घेऊ recovery_target_xid आणि विनंती करण्यापूर्वी व्यवहारापर्यंत सर्व काही केले DELETE.

कामावर परत जाणे खूप सोपे आहे: सर्व बदल काढून टाका recovery.conf आणि पोस्टग्रेस रीस्टार्ट करा. प्रतिकृतीला लवकरच पुन्हा आठ तासांचा विलंब होईल आणि आम्ही भविष्यातील त्रासांसाठी तयार आहोत.

पुनर्प्राप्ती फायदे

कोल्ड बॅकअपऐवजी स्थगित प्रतिकृतीसह, आपल्याला संग्रहणातून संपूर्ण प्रतिमा पुनर्संचयित करण्यासाठी काही तास घालवावे लागणार नाहीत. उदाहरणार्थ, संपूर्ण मूलभूत 2 TB बॅकअप मिळविण्यासाठी आम्हाला पाच तास लागतात. आणि मग तुम्हाला अजूनही इच्छित स्थितीत (सर्वात वाईट परिस्थितीत) पुनर्प्राप्त करण्यासाठी संपूर्ण दैनिक WAL लागू करावे लागेल.

एक स्थगित प्रतिकृती दोन प्रकारे कोल्ड बॅकअपपेक्षा चांगली आहे:

1. संग्रहणातून संपूर्ण मूलभूत बॅकअप काढण्याची गरज नाही.
2. WAL विभागांची एक निश्चित आठ-तास विंडो आहे जी पुनरावृत्ती करणे आवश्यक आहे.

WAL वरून PITR बनवणे शक्य आहे की नाही हे देखील आम्ही सतत तपासत असतो आणि स्थगित प्रतिकृतीच्या अंतरावर लक्ष ठेवून WAL संग्रहणातील भ्रष्टाचार किंवा इतर समस्या आम्हाला त्वरीत लक्षात येतील.

या उदाहरणात, आम्हाला पुनर्संचयित करण्यासाठी 50 मिनिटे लागली, याचा अर्थ वेग प्रति तास 110 GB WAL डेटा होता (संग्रहण अद्याप सुरू होते एडब्ल्यूएस एस 3). एकूण, आम्ही समस्येचे निराकरण केले आणि 1,5 तासांमध्ये डेटा पुनर्प्राप्त केला.

परिणाम: जिथे स्थगित प्रतिकृती उपयुक्त आहे (आणि कुठे नाही)

जर तुम्ही चुकून डेटा गमावला आणि कॉन्फिगर केलेल्या विलंबामध्ये ही समस्या लक्षात आली तर प्रथमोपचार म्हणून विलंबित प्रतिकृती वापरा.

परंतु लक्षात ठेवा: प्रतिकृती बॅकअप नाही.

बॅकअप आणि प्रतिकृतीचे वेगवेगळे उद्देश आहेत. तुम्ही चुकून बनवल्यास कोल्ड बॅकअप उपयोगी पडेल DELETE किंवा DROP TABLE. आम्ही कोल्ड स्टोरेजमधून बॅकअप बनवतो आणि टेबलची किंवा संपूर्ण डेटाबेसची मागील स्थिती पुनर्संचयित करतो. पण त्याच वेळी विनंती DROP TABLE कार्यरत क्लस्टरवरील सर्व प्रतिकृतींमध्ये जवळजवळ त्वरित पुनरुत्पादित केले जाते, म्हणून सामान्य प्रतिकृती येथे मदत करणार नाही. वैयक्तिक सर्व्हर डाउन असताना आणि लोडचे वितरण करताना प्रतिकृती स्वतः डेटाबेस उपलब्ध ठेवते.

अगदी लांबणीवर टाकलेल्या प्रतिकृतीसह, डेटा सेंटरमध्ये बिघाड, लपविलेले नुकसान किंवा लगेच लक्षात न येणार्‍या घटना घडल्यास आम्हाला कधीकधी सुरक्षित ठिकाणी थंड बॅकअपची आवश्यकता असते. येथे केवळ प्रतिकृतीचा उपयोग नाही.

शेरा. चालू GitLab.com आम्ही सध्या फक्त सिस्टम स्तरावर डेटा गमावण्यापासून संरक्षण करतो आणि वापरकर्ता स्तरावर डेटा पुनर्प्राप्त करत नाही.

स्त्रोत: www.habr.com