🥇අපි PostgreSQL සමඟ ආපදා ප්‍රතිසාධනය සඳහා ප්‍රමාද වූ අනුකරණය භාවිතා කළ ආකාරය

අනුකරණය යනු උපස්ථ නොවේ. නැත්ද? මෙන්න අපි අහම්බෙන් මකා දැමූ කෙටිමං වලින් ප්‍රතිසාධනය කිරීමට විලම්බිත අනුකරණය භාවිතා කළ ආකාරය.

යටිතල පහසුකම් විශේෂඥයින් GitLab වැඩ සඳහා වගකිව යුතුය GitLab.com - ස්වභාවධර්මයේ විශාලතම GitLab අවස්ථාව. මිලියන 3 ක පරිශීලකයින් සහ මිලියන 7 කට ආසන්න ව්‍යාපෘති සමඟ, එය කැපවූ ගෘහ නිර්මාණ ශිල්පයක් සහිත විශාලතම විවෘත කේත SaaS අඩවි වලින් එකකි. PostgreSQL දත්ත සමුදා පද්ධතිය නොමැතිව, GitLab.com යටිතල ව්‍යුහය බොහෝ දුර නොයනු ඇත, සහ දත්ත නැති විය හැකි විට කිසියම් අසාර්ථක වීමක් සිදු වුවහොත් දෝෂ ඉවසීම සහතික කිරීමට අප කරන්නේ කුමක්ද? එවැනි ව්‍යසනයක් සිදුවනු ඇතැයි සිතිය නොහැක, නමුත් අපි හොඳින් සූදානම් වී විවිධ උපස්ථ සහ අනුකරණ යාන්ත්‍රණයන් සමඟ ගබඩා කර ඇත්තෙමු.

අනුකරණය යනු දත්ත සමුදායන් උපස්ථ කිරීමේ මාධ්‍යයක් නොවේ (පහත බලන්න) නමුත් දැන් අපි බලමු කම්මැලි අනුකරණය භාවිතයෙන් අහම්බෙන් මකා දැමූ දත්ත ඉක්මනින් ප්‍රතිසාධනය කරන්නේ කෙසේදැයි බලන්න GitLab.com පරිශීලකයා කෙටිමඟ මකා දැමුවා ව්යාපෘතිය සඳහා gitlab-ce සහ ඒකාබද්ධ ඉල්ලීම් සහ කාර්යයන් සමඟ සම්බන්ධතා නැති විය.

කල් දැමූ අනුරුවක් සමඟ, අපි පැය 1,5ක් තුළ දත්ත ප්‍රතිසාධනය කළෙමු. එය සිදු වූ ආකාරය බලන්න.

PostgreSQL සමඟින් කාල ප්‍රතිසාධනය පෙන්වා දෙන්න

PostgreSQL සතුව දත්ත සමුදායේ තත්වය නිශ්චිත වේලාවකට ප්‍රතිසාධනය කරන බිල්ට්-ඉන් ශ්‍රිතයක් ඇත. එය හැඳින්වේ පොයින්ට්-ඉන්-ටයිම් ප්‍රතිසාධනය (PITR) සහ අනුරුව යාවත්කාලීනව තබා ගන්නා එකම යාන්ත්‍රණ භාවිතා කරයි: සම්පූර්ණ දත්ත සමුදා පොකුරේ (මූලික උපස්ථය) විශ්වාසදායක සැණෙකින් පටන් ගෙන, අපි නිශ්චිත කාලයක් දක්වා රාජ්‍ය වෙනස්කම් මාලාවක් යොදන්නෙමු.

සීතල උපස්ථ සඳහා මෙම විශේෂාංගය භාවිතා කිරීම සඳහා, අපි නිතිපතා මූලික දත්ත සමුදා උපස්ථයක් සාදා එය සංරක්ෂිතයක ගබඩා කරමු (GitLab ලේඛනාගාරය ජීවත් වන්නේ ගූගල් වලාකුළු ආචයනය) අපි ලිවීමේ-ඉදිරි ලොගය සංරක්ෂණය කිරීමෙන් දත්ත සමුදායේ තත්ත්වයෙහි වෙනස්කම් ද නිරීක්ෂණය කරමු (ඉදිරියට ලියන්න, WAL). මේ සියල්ල සමඟින්, අපට ආපදා ප්‍රතිසාධනය සඳහා 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 සඳහා සීතල උපස්ථයක් පවා ගන්න).

අපි කල් දැමූ Postgres අවස්ථාව නැවත ආරම්භ කළ අතර 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නැවත උත්සාහ කිරීමෙන් පසු අවස්ථාව වැසීමට, ප්‍රවර්ධනය කිරීමට හෝ විරාම කිරීමට (එය පෙරනිමියෙන් අත්හිටුවා ඇත).

එම අවාසනාවන්ත ඉල්ලීමට පෙර දත්ත සමුදාය එහි තත්වයට පත් විය. දැන් ඔබට උදාහරණයක් ලෙස දත්ත අපනයනය කළ හැකිය. අපි මකා දැමූ ලේබල් දත්ත සහ ගැටළු වෙත සියලුම සබැඳි අපනයනය කර ඉල්ලීම් ඒකාබද්ධ කර නිෂ්පාදන දත්ත ගබඩාවට ගෙන ගියෙමු. පාඩු මහා පරිමාණ නම්, ඔබට අනුරුව ප්‍රවර්ධනය කර එය ප්‍රධාන එක ලෙස භාවිතා කළ හැකිය. නමුත් එවිට අප යථා තත්ත්වයට පත් වූ ස්ථානයෙන් පසු සියලු වෙනස්කම් නැති වී යයි.

වේලා මුද්දර වෙනුවට, ගනුදෙනු හැඳුනුම්පත් භාවිතා කිරීම වඩා හොඳය. මෙම හැඳුනුම්පත් පටිගත කිරීම ප්‍රයෝජනවත් වේ, උදාහරණයක් ලෙස, DDL ප්‍රකාශ සඳහා (උදා DROP TABLE), භාවිතා කිරීම මගින් log_statements = 'ddl'. ගනුදෙනු හැඳුනුම්පතක් තිබුණා නම් අපි ගන්නවා recovery_target_xid සහ ඉල්ලීමට පෙර ගනුදෙනුව දක්වා සියල්ල ධාවනය කළේය DELETE.

නැවත වැඩට යාම ඉතා සරලයි: සියලු වෙනස්කම් ඉවත් කරන්න recovery.conf සහ Postgres නැවත ආරම්භ කරන්න. අනුරුව ළඟදීම නැවත පැය අටක ප්‍රමාදයක් ඇති වන අතර, අපි අනාගත කරදර සඳහා සූදානම්ව සිටිමු.

ප්රතිසාධන ප්රතිලාභ

සීතල උපස්ථයක් වෙනුවට කල් දැමූ අනුරුවක් සමඟ, ඔබට ලේඛනාගාරයෙන් සම්පූර්ණ රූපය ප්‍රතිස්ථාපනය කිරීමට පැය ගණනක් වැය කිරීමට අවශ්‍ය නොවේ. උදාහරණයක් ලෙස, සම්පූර්ණ මූලික 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 සමඟ ආපදා ප්‍රතිසාධනය සඳහා ප්‍රමාද වූ අනුකරණය භාවිතා කළ ආකාරය