🥇 څنګه موږ د 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 د فزیکي ډیټابیس ریپلیکا تنظیم کولو لپاره 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د بیا هڅه کولو وروسته مثال بندول، وده کول، یا بندول (دا په ډیفالټ تعلیق شوی).

ډیټابیس د دې بدبختانه غوښتنې دمخه خپل حالت ته راستون شو. اوس تاسو کولی شئ، د بیلګې په توګه، ډاټا صادر کړئ. موږ د حذف شوي لیبل ډیټا او د مسلو ټول لینکونه صادر کړل او غوښتنې یې ضمیمه کړې او د تولید ډیټابیس ته مو لیږدول. که زیانونه په لویه پیمانه وي، تاسو کولی شئ په ساده ډول نقل ته وده ورکړئ او د اصلي په توګه یې وکاروئ. مګر بیا ټول بدلونونه وروسته له هغه چې موږ بیرته ترلاسه شوي یو له لاسه ورکول کیږي.

د مهال ویش پر ځای، دا غوره ده چې د لیږد IDs وکاروئ. دا ګټوره ده چې دا IDs ثبت کړئ، د بیلګې په توګه، د DDL بیاناتو لپاره (لکه DROP TABLE)، په کارولو log_statements = 'ddl'. که موږ د راکړې ورکړې ID درلود، موږ به یې واخلو recovery_target_xid او هر څه د غوښتنې څخه دمخه لیږد ته واستول DELETE.

کار ته بیرته راستنیدل خورا ساده دي: ټول بدلونونه لرې کړئ recovery.conf او پوسټګریس بیا پیل کړئ. نقل به ډیر ژر بیا اته ساعته ځنډ ولري، او موږ د راتلونکو ستونزو لپاره چمتو یو.

د بیا رغونې ګټې

د سړې بیک اپ پرځای د ځنډول شوي نقل سره ، تاسو اړتیا نلرئ د آرشیف څخه د بشپړ عکس په بحالولو کې ساعتونه مصرف کړئ. د مثال په توګه، دا موږ ته پنځه ساعته وخت نیسي ترڅو د بشپړ لومړني 2 TB بیک اپ ترلاسه کړو. او بیا تاسو لاهم باید مطلوب حالت ته د بیرته راستنیدو لپاره ټوله ورځنۍ WAL پلي کړئ (په بدترین حالت کې).

ځنډول شوی نقل په دوه لارو کې د سړې بیک اپ څخه غوره دی:

له آرشیف څخه د بشپړ بنسټیز بیک اپ لرې کولو ته اړتیا نشته.
د WAL برخو یو ټاکلی اته ساعته کړکۍ شتون لري چې باید تکرار شي.

موږ هم په دوامداره توګه وګورو چې ایا دا ممکنه ده چې د WAL څخه PITR جوړ کړئ، او موږ به ژر تر ژره د ځنډول شوي نقل د ځنډ په څارلو سره د WAL آرشیف سره فساد یا نورې ستونزې په ګوته کړو.

په دې مثال کې، موږ د بیا رغونې لپاره 50 دقیقې وخت نیولی، پدې معنی چې سرعت په ساعت کې 110 GB د WAL ډیټا وه (آرشیف لاهم روان و. AWS S3). په مجموع کې، موږ ستونزه حل کړه او په 1,5 ساعتونو کې ډاټا بیرته ترلاسه کړه.

پایلې: چیرته چې ځنډول شوی نقل ګټور دی (او چیرې چې نه وي)

ځنډول شوي نقل د لومړنۍ مرستې په توګه وکاروئ که چیرې تاسو په ناڅاپي ډول ډیټا له لاسه ورکړئ او دا ستونزه په ترتیب شوي ځنډ کې ولیدله.

مګر په یاد ولرئ: نقل کول بیک اپ ندي.

بیک اپ او نقل کول مختلف اهداف لري. یو سړه بیک اپ به په لاس کې راشي که تاسو په ناڅاپي ډول جوړ کړئ DELETE او یا DROP TABLE. موږ د سړې خونې څخه بیک اپ کوو او د میز پخوانی حالت یا ټول ډیټابیس بیرته راګرځوو. مګر په ورته وخت کې غوښتنه DROP TABLE نږدې سمدستي په کاري کلستر کې په ټولو نقلونو کې بیا تولید کیږي، نو عادي نقل به دلته مرسته ونه کړي. نقل کول پخپله ډیټابیس ساتي کله چې انفرادي سرورونه کرایه کیږي او بار توزیع کوي.

حتی د ځنډول شوي نقل سره ، موږ ځینې وختونه واقعیا په خوندي ځای کې سړې بیک اپ ته اړتیا لرو که چیرې د ډیټا مرکز ناکامي ، پټ زیان ، یا نورې پیښې چې سمدستي د پام وړ نه وي پیښیږي. یوازې نقل کول دلته هیڅ ګټه نلري.

تبصره. په GitLab.com موږ اوس مهال یوازې د سیسټم په کچه د معلوماتو له لاسه ورکولو څخه ساتنه کوو او د کارونکي په کچه ډاټا بیرته نه ترلاسه کوو.

سرچینه: www.habr.com

څنګه موږ د PostgreSQL سره د ناورین بیا رغونې لپاره ځنډول شوي نقل کارولی