PostgreSQL سان اسان آفت جي بحالي لاءِ سست نقل ڪيئن استعمال ڪئي

نقل هڪ بيڪ اپ نه آهي. يا نه؟ ھتي آھي ڪيئن اسان استعمال ڪيو سستي نقل کي بحالي لاءِ حادثاتي طور شارٽ ڪٽس کي حذف ڪرڻ سان.

انفراسٽرڪچر ماهر GitLab ڪم لاء ذميوار آهي GitLab.com - فطرت ۾ GitLab جو سڀ کان وڏو مثال. 3 ملين استعمال ڪندڙن ۽ لڳ ڀڳ 7 ملين منصوبن سان، اھو ھڪڙو وڏو اوپن سورس SaaS سائيٽن مان ھڪڙو وقف فن تعمير سان آھي. PostgreSQL ڊيٽابيس سسٽم جي بغير، GitLab.com انفراسٽرڪچر گهڻو پري نه ٿيندو، ۽ اسان صرف اهو نه ڪندا آهيون غلطي رواداري لاءِ ڪنهن به ناڪامي جي صورت ۾ جڏهن توهان ڊيٽا وڃائي سگهو ٿا. اهو ممڪن ناهي ته اهڙي تباهي ٿيندي، پر اسان چڱي طرح تيار ڪيو ۽ مختلف بيڪ اپ ۽ نقل ڪرڻ واري ميڪانيزم سان گڏ ڪيو.

نقل نه آهي توهان جي ڊيٽابيس جي بيڪ اپ اوزار (هيٺ ڏسو). پر ھاڻي اسان ڏسنداسين ته ڪيئن تڪڙو تڪڙو ڊليٽ ٿيل ڊيٽا کي سستي نقل استعمال ڪندي بحال ڪجي: on GitLab.com استعمال ڪندڙ هٽايو ويو شارٽ ڪٽ منصوبي لاء gitlab-ce ۽ ضم ٿيڻ جي درخواستن ۽ ڪمن سان لاڳاپا گم ٿي ويا.

دير سان نقل ڪرڻ سان، اسان صرف 1,5 ڪلاڪن ۾ ڊيٽا حاصل ڪئي. ڏسو ته ڪيئن هو.

PostgreSQL سان پوائنٽ ۾ وقت جي بحالي

PostgreSQL ۾ هڪ تعمير ٿيل فنڪشن آهي جيڪو ڊيٽابيس جي حالت کي وقت ۾ هڪ خاص نقطي تي بحال ڪري ٿو. ان کي سڏيو ويندو آهي پوائنٽ-۾-وقت بحالي (PITR) ۽ ساڳيو ميکانيزم استعمال ڪريون ٿا جيڪي ريپليڪا کي اپ ڊيٽ رکن ٿا: پوري ڊيٽابيس ڪلسٽر جي هڪ قابل اعتماد سنيپ شاٽ سان شروع ڪندي (بيس بيڪ اپ)، اسان لاڳو ڪريون ٿا رياستي تبديلين جو هڪ سلسلو وقت جي هڪ خاص نقطي تائين.

ٿڌي بيڪ اپ لاءِ ھن خصوصيت کي استعمال ڪرڻ لاءِ، اسين باقاعدگي سان ھڪ بنيادي ڊيٽابيس جو بيڪ اپ ٺاھيندا آھيون ۽ ان کي آرڪائيو ۾ ذخيرو ڪندا آھيون (GitLab آرڪائيوز گوگل ڪلائوڊ اسٽوريج). اسان ڊيٽابيس اسٽيٽ تبديلين کي پڻ مانيٽر ڪريون ٿا آرڪائيو ڪندي لکت-اڳتي لاگ (اڳيان لکو، وال). ۽ ان سان گڏ، اسان ڪري سگھون ٿا PITR آفت جي بحالي لاءِ: اسان شروعات ڪريون ٿا ھڪڙي سنيپ شاٽ سان جيڪو غلطي کان اڳ ورتو ويو آھي ۽ تبديلين کي لاڳو ڪريون ٿا WAL آرڪائيو کان وٺي حادثي تائين.

دير سان نقل ڪرڻ ڇا آهي؟

Delayed replication هڪ دير سان WAL کان تبديلين جي درخواست آهي. اهو آهي، ٽرانزيڪشن ڪلاڪ تي واقع آهي X، پر اهو دير سان نقل ۾ ظاهر ٿيندو d هڪ ڪلاڪ ۾ X + d.

PostgreSQL ۾ فزيڪل ڊيٽابيس ريپليڪا کي ترتيب ڏيڻ لاءِ 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 حصن کي ڪڍڻ لاء (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ٻيهر ڪوشش ڪرڻ کان پوءِ مثال کي بند ڪرڻ، فروغ ڏيڻ يا روڪڻ لاءِ (اهو ڊفالٽ طور روڪي ٿو).

ڊيٽابيس ان بي رحم درخواست کان اڳ رياست ۾ آيو. هاڻي توهان ڪري سگهو ٿا، مثال طور، برآمد ڊيٽا. اسان ريموٽ ليبل ڊيٽا برآمد ڪيو آهي ۽ مسئلن جي سڀني لنڪس ۽ درخواستن کي ضم ڪيو ۽ انهن کي پيداوار جي ڊيٽابيس ڏانهن منتقل ڪيو. جيڪڏهن نقصان وڏا آهن، توهان صرف نقل کي فروغ ڏئي سگهو ٿا ۽ ان کي بنيادي طور استعمال ڪري سگهو ٿا. پر پوءِ سڀ تبديليون ان لمحي کان پوءِ گم ٿي وينديون جن کي اسان بحال ڪيو.

اهو بهتر آهي ته ٽرانزيڪشن IDs استعمال ڪرڻ بدران ٽائم اسٽيمپ. اهو انهن IDs کي رڪارڊ ڪرڻ لاء مفيد آهي، مثال طور، DDL بيانن لاء (جهڙوڪ DROP TABLE)، استعمال ڪندي log_statements = 'ddl'. جيڪڏهن اسان وٽ هڪ ٽرانزيڪشن ID هجي ها، اسان وٺون ها recovery_target_xid ۽ درخواست کان اڳ ٽرانزيڪشن تائين هر شي کي هلائي ڇڏيو DELETE.

ڪم تي واپس حاصل ڪرڻ تمام سادو آهي: سڀني تبديلين کي هٽائي ڇڏيو recovery.conf ۽ پوسٽ گريس ٻيهر شروع ڪريو. جلد ئي ڪيو ٻيهر اٺن ڪلاڪن جي دير ٿي ويندي، ۽ اسان مستقبل جي مشڪلاتن لاء تيار آهيون.

بحالي جا فائدا

دير واري نقل سان، ٿڌي بيڪ اپ جي بدران، توهان کي آرڪائيو مان مڪمل سنيپ شاٽ بحال ڪرڻ ۾ ڪلاڪ خرچ ڪرڻ جي ضرورت ناهي. مثال طور، اسان کي پنجن ڪلاڪن جي ضرورت آهي پوري 2 TB بنيادي بيڪ اپ حاصل ڪرڻ لاء. ۽ پوءِ توھان کي اڃا تائين پوري روزاني WAL کي لاڳو ڪرڻو پوندو مطلوب حالت ڏانھن موٽڻ لاءِ (بدترين صورت ۾).

دير ٿيل نقل ٻن طريقن سان ٿڌي بيڪ اپ کان بهتر آهي:

1. توهان کي آرڪائيو مان پوري بنيادي بيڪ اپ حاصل ڪرڻ جي ضرورت ناهي.
2. WAL حصن جي ھڪڙي مقرر ٿيل اٺ ڪلاڪ ونڊو آھي جنھن کي ورجائڻ گھرجي.

انهي سان گڏ، اسان مسلسل جانچ ڪري رهيا آهيون ته ڇا WAL کي PITRed ٿي سگهي ٿو، ۽ اسان جلدي طور تي دير سان ريپليڪا جي بيڪ لاگ جي نگراني ڪندي WAL آرڪائيو سان بدعنواني يا ٻين مسئلن کي نوٽيس ڪنداسين.

ھن مثال ۾، اسان کي بحال ڪرڻ ۾ 50 منٽ لڳا، اھو آھي، رفتار 110 GB جي WAL ڊيٽا في ڪلاڪ ھئي (آرڪائيو اڃا تائين جاري ھو. AWS S3). مجموعي طور تي، اسان مسئلو حل ڪيو ۽ ڊيٽا کي 1,5 ڪلاڪن ۾ بحال ڪيو.

خلاصو: جتي دير ٿيل نقل مفيد آهي (۽ ڪٿي نه)

پهرين امداد جي طور تي دير ٿيل نقل استعمال ڪريو جيڪڏهن توهان اتفاقي طور تي ڊيٽا وڃائي ڇڏيو ۽ ترتيب ڏنل دير جي اندر هن آفت کي نوٽيس ڪيو.

پر ذهن ۾ رکو: نقل هڪ بيڪ اپ نه آهي.

بيڪ اپ ۽ نقل جا مختلف مقصد آهن. جيڪڏهن توهان اتفاقي طور تي ٺاهيو ته هڪ ٿڌو بيڪ اپ هٿ ۾ اچي ويندو DELETE يا DROP TABLE. اسان کولڊ اسٽوريج مان بيڪ اپ ٺاهيندا آهيون ۽ ٽيبل يا پوري ڊيٽابيس جي پوئين حالت کي بحال ڪندا آهيون. پر ساڳئي وقت درخواست DROP TABLE تقريبن فوري طور تي ڪم ڪندڙ ڪلستر تي سڀني نقلن ۾ ٻيهر پيدا ڪيو ويو، تنهنڪري باقاعده نقل هتي محفوظ نه ٿيندو. نقل پاڻ کي ڊيٽابيس کي دستياب رکي ٿو جڏهن انفرادي سرور ليز تي آهن ۽ لوڊ کي ورهائي ٿو.

جيتوڻيڪ دير سان نقل ڪرڻ سان، اسان کي ڪڏهن ڪڏهن واقعي هڪ محفوظ جڳهه تي ٿڌي بيڪ اپ جي ضرورت آهي، جيڪڏهن اوچتو ڊيٽا سينٽر جي ناڪامي، لڪيل نقصان، يا ٻيا واقعا جيڪي توهان کي فوري طور تي نوٽيس نه ڪندا آهن. هتي هڪ نقل مان ڪو به احساس ناهي.

ويچاري. تي GitLab.com اسان في الحال صرف سسٽم جي سطح تي ڊيٽا جي نقصان جي خلاف حفاظت ڪندا آهيون ۽ صارف جي سطح تي ڊيٽا کي بحال نه ڪندا آهيون.

جو ذريعو: www.habr.com