کس طرح ہم نے PostgreSQL کے ساتھ ڈیزاسٹر ریکوری کے لیے سست نقل کا استعمال کیا۔

نقل بیک اپ نہیں ہے۔ یا نہیں؟ یہ ہے کہ ہم نے غلطی سے حذف ہونے والے شارٹ کٹس سے بازیافت کرنے کے لیے موخر شدہ نقل کا استعمال کیسے کیا۔

انفراسٹرکچر کے ماہرین GitLab کام کے لیے ذمہ دار ہے۔ GitLab.com - فطرت میں گٹ لیب کی سب سے بڑی مثال۔ 3 ملین صارفین اور تقریباً 7 ملین پروجیکٹس کے ساتھ، یہ ایک سرشار فن تعمیر کے ساتھ سب سے بڑی اوپن سورس SaaS سائٹس میں سے ایک ہے۔ PostgreSQL ڈیٹا بیس سسٹم کے بغیر، GitLab.com کا بنیادی ڈھانچہ زیادہ آگے نہیں بڑھے گا، اور ڈیٹا ضائع ہونے کی صورت میں کسی بھی ناکامی کی صورت میں غلطی برداشت کو یقینی بنانے کے لیے ہم کیا کر رہے ہیں۔ اس بات کا امکان نہیں ہے کہ اس طرح کی تباہی واقع ہوگی، لیکن ہم اچھی طرح سے تیار ہیں اور مختلف بیک اپ اور نقل کے میکانزم کے ساتھ ذخیرہ ہیں۔

نقل ڈیٹا بیس کو بیک اپ کرنے کا ذریعہ نہیں ہے (ذیل میں دیکھیں)۔ لیکن اب ہم دیکھیں گے کہ سست نقل کا استعمال کرتے ہوئے حادثاتی طور پر حذف شدہ ڈیٹا کو کیسے تیزی سے بازیافت کیا جائے: on GitLab.com صارف شارٹ کٹ کو حذف کر دیا۔ منصوبے کے لئے gitlab-ce اور انضمام کی درخواستوں اور کاموں کے ساتھ رابطے ختم ہو گئے۔

ایک موخر شدہ نقل کے ساتھ، ہم نے صرف 1,5 گھنٹے میں ڈیٹا بازیافت کیا۔ دیکھو کیسے ہوا؟

PostgreSQL کے ساتھ وقت کی وصولی میں پوائنٹ

PostgreSQL میں ایک بلٹ ان فنکشن ہے جو ڈیٹا بیس کی حالت کو وقت کے ایک خاص مقام پر بحال کرتا ہے۔ یہ کہا جاتا ہے پوائنٹ ان ٹائم ریکوری (PITR) اور وہی میکانزم استعمال کرتا ہے جو نقل کو تازہ ترین رکھتا ہے: پورے ڈیٹا بیس کلسٹر (بیس بیک اپ) کے قابل اعتماد سنیپ شاٹ کے ساتھ شروع کرتے ہوئے، ہم وقت کے ایک خاص نقطہ تک ریاستی تبدیلیوں کا سلسلہ لاگو کرتے ہیں۔

اس خصوصیت کو کولڈ بیک اپ کے لیے استعمال کرنے کے لیے، ہم باقاعدگی سے ایک بنیادی ڈیٹا بیس کا بیک اپ بناتے ہیں اور اسے ایک آرکائیو میں محفوظ کرتے ہیں (گٹ لیب آرکائیوز گوگل کلاؤڈ اسٹوریج)۔ ہم ڈیٹا بیس کی حالت میں ہونے والی تبدیلیوں کی بھی نگرانی کرتے ہیں تحریری لاگ (لکھنا آگے لاگ، وال)۔ اور ان سب کے ساتھ، ہم تباہی کی بحالی کے لیے ایک 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دوبارہ کوشش کرنے کے بعد مثال کو بند کرنے، فروغ دینے یا روکنے کے لیے (یہ بطور ڈیفالٹ معطل ہے)۔

اس بدقسمتی کی درخواست سے پہلے ڈیٹا بیس اپنی حالت میں واپس آگیا۔ اب آپ مثال کے طور پر ڈیٹا ایکسپورٹ کر سکتے ہیں۔ ہم نے حذف شدہ لیبل ڈیٹا اور مسائل کے تمام لنکس اور ضم کرنے کی درخواستوں کو برآمد کیا اور انہیں پروڈکشن ڈیٹا بیس میں منتقل کر دیا۔ اگر نقصانات بڑے پیمانے پر ہیں، تو آپ آسانی سے نقل کو فروغ دے سکتے ہیں اور اسے بنیادی کے طور پر استعمال کر سکتے ہیں۔ لیکن پھر اس مقام کے بعد تمام تبدیلیاں ختم ہو جائیں گی جہاں سے ہم بحال ہو چکے ہیں۔

ٹائم اسٹیمپ کے بجائے، ٹرانزیکشن آئی ڈی استعمال کرنا بہتر ہے۔ ان IDs کو ریکارڈ کرنا مفید ہے، مثال کے طور پر، DDL اسٹیٹمنٹس (جیسے DROP TABLE)، کا استعمال کرتے ہوئے log_statements = 'ddl'. اگر ہمارے پاس ٹرانزیکشن آئی ڈی ہوتی تو ہم لے لیتے recovery_target_xid اور درخواست سے پہلے ہر چیز کو لین دین تک پہنچا دیا۔ DELETE.

کام پر واپس جانا بہت آسان ہے: سے تمام تبدیلیاں ہٹا دیں۔ recovery.conf اور پوسٹگریس کو دوبارہ شروع کریں۔ نقل میں جلد ہی دوبارہ آٹھ گھنٹے کی تاخیر ہوگی، اور ہم مستقبل کی پریشانیوں کے لیے تیار ہیں۔

بازیابی کے فوائد

کولڈ بیک اپ کے بجائے موخر شدہ نقل کے ساتھ، آپ کو آرکائیو سے پوری تصویر کو بحال کرنے میں گھنٹے نہیں گزارنے پڑتے۔ مثال کے طور پر، پورا بنیادی 2 ٹی بی بیک اپ حاصل کرنے میں ہمیں پانچ گھنٹے لگتے ہیں۔ اور پھر آپ کو مطلوبہ حالت میں واپس آنے کے لیے پوری روزانہ 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