PostgreSQL এর সাথে দুর্যোগ পুনরুদ্ধারের জন্য আমরা কীভাবে অলস প্রতিলিপি ব্যবহার করেছি

প্রতিলিপি ব্যাকআপ নয়. অথবা না? ঘটনাক্রমে মুছে ফেলা শর্টকাটগুলি থেকে পুনরুদ্ধার করতে আমরা কীভাবে বিলম্বিত প্রতিলিপি ব্যবহার করেছি তা এখানে।

অবকাঠামো বিশেষজ্ঞ গিটল্যাব কাজের জন্য দায়ী GitLab.com - প্রকৃতির বৃহত্তম গিটল্যাব উদাহরণ। 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 অংশগুলি বের করতে (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 কিভাবে এটা করে?

পোস্টগ্রেএসকিউএল কীভাবে অলস পুনরুদ্ধার প্রয়োগ করে তা দেখতে আকর্ষণীয়। এদিকে তাকান 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 এবং Postgres পুনরায় চালু করুন। প্রতিরূপটি শীঘ্রই আবার আট ঘন্টা বিলম্বিত হবে, এবং আমরা ভবিষ্যতের সমস্যার জন্য প্রস্তুত।

পুনরুদ্ধারের সুবিধা

কোল্ড ব্যাকআপের পরিবর্তে একটি বিলম্বিত প্রতিরূপ সহ, আপনাকে সংরক্ষণাগার থেকে সম্পূর্ণ চিত্র পুনরুদ্ধার করতে ঘন্টা ব্যয় করতে হবে না। উদাহরণস্বরূপ, সম্পূর্ণ মৌলিক 2 টিবি ব্যাকআপ পেতে আমাদের পাঁচ ঘন্টা সময় লাগে। এবং তারপরেও আপনাকে কাঙ্ক্ষিত অবস্থায় পুনরুদ্ধার করতে (সবচেয়ে খারাপ ক্ষেত্রে) সম্পূর্ণ দৈনিক WAL প্রয়োগ করতে হবে।

একটি বিলম্বিত প্রতিরূপ দুটি উপায়ে একটি ঠান্ডা ব্যাকআপের চেয়ে ভাল:

1. সংরক্ষণাগার থেকে সম্পূর্ণ মৌলিক ব্যাকআপ অপসারণ করার প্রয়োজন নেই।
2. WAL সেগমেন্টগুলির একটি নির্দিষ্ট আট-ঘন্টা উইন্ডো রয়েছে যা পুনরাবৃত্তি করা আবশ্যক।

WAL থেকে পিআইটিআর তৈরি করা সম্ভব কিনা তাও আমরা ক্রমাগত পরীক্ষা করি এবং স্থগিত প্রতিরূপের ব্যবধান পর্যবেক্ষণ করে আমরা দ্রুত WAL সংরক্ষণাগারে দুর্নীতি বা অন্যান্য সমস্যা লক্ষ্য করব।

এই উদাহরণে, এটি পুনরুদ্ধার করতে আমাদের 50 মিনিট সময় লেগেছে, যার মানে গতি ছিল প্রতি ঘন্টায় 110 GB WAL ডেটা (আর্কাইভটি এখনও চালু ছিল এডাব্লুএস এস 3) মোট, আমরা সমস্যাটি সমাধান করেছি এবং 1,5 ঘন্টার মধ্যে ডেটা পুনরুদ্ধার করেছি।

ফলাফল: যেখানে একটি বিলম্বিত প্রতিরূপ দরকারী (এবং যেখানে এটি নয়)

আপনি যদি ভুলবশত ডেটা হারিয়ে ফেলেন এবং কনফিগার করা বিলম্বের মধ্যে এই সমস্যাটি লক্ষ্য করেন তবে প্রাথমিক চিকিৎসা হিসাবে বিলম্বিত প্রতিলিপি ব্যবহার করুন।

কিন্তু মনে রাখবেন: প্রতিলিপি ব্যাকআপ নয়।

ব্যাকআপ এবং প্রতিলিপি বিভিন্ন উদ্দেশ্য আছে. আপনি ভুলবশত তৈরি করলে একটি ঠান্ডা ব্যাকআপ কাজে আসবে DELETE বা DROP TABLE. আমরা কোল্ড স্টোরেজ থেকে একটি ব্যাকআপ তৈরি করি এবং টেবিলের পূর্ববর্তী অবস্থা বা সম্পূর্ণ ডাটাবেস পুনরুদ্ধার করি। কিন্তু একই সঙ্গে অনুরোধ DROP TABLE কার্যকারী ক্লাস্টারে সমস্ত প্রতিলিপিতে প্রায় তাত্ক্ষণিকভাবে পুনরুত্পাদন করা হয়, তাই সাধারণ প্রতিলিপি এখানে সাহায্য করবে না। যখন পৃথক সার্ভার ভাড়া করা হয় এবং লোড বিতরণ করা হয় তখন প্রতিলিপি নিজেই ডাটাবেস উপলব্ধ রাখে।

এমনকি একটি বিলম্বিত প্রতিরূপের সাথেও, ডেটা সেন্টারের ব্যর্থতা, লুকানো ক্ষতি, বা অবিলম্বে লক্ষণীয় নয় এমন ঘটনা ঘটলে আমাদের মাঝে মাঝে একটি নিরাপদ স্থানে একটি ঠান্ডা ব্যাকআপের প্রয়োজন হয়। একা প্রতিলিপি এখানে কোন কাজে আসে না.

মন্তব্য। উপর GitLab.com আমরা বর্তমানে শুধুমাত্র সিস্টেম স্তরে ডেটা ক্ষতির বিরুদ্ধে রক্ষা করি এবং ব্যবহারকারী স্তরে ডেটা পুনরুদ্ধার করি না।

উত্স: www.habr.com