PostgreSQL-നൊപ്പം ദുരന്ത വീണ്ടെടുക്കലിനായി ഞങ്ങൾ എങ്ങനെയാണ് കാലതാമസം വരുത്തിയ പകർപ്പ് ഉപയോഗിച്ചത്

റെപ്ലിക്കേഷൻ ബാക്കപ്പ് അല്ല. അല്ലെങ്കിൽ അല്ല? ആകസ്മികമായി ഇല്ലാതാക്കുന്ന കുറുക്കുവഴികളിൽ നിന്ന് വീണ്ടെടുക്കാൻ ഞങ്ങൾ മാറ്റിവെച്ച പകർപ്പ് എങ്ങനെ ഉപയോഗിച്ചുവെന്നത് ഇതാ.

ഇൻഫ്രാസ്ട്രക്ചർ സ്പെഷ്യലിസ്റ്റുകൾ GitLab ആണ് ജോലിയുടെ ചുമതല GitLab.com - പ്രകൃതിയിലെ ഏറ്റവും വലിയ GitLab ഉദാഹരണം. 3 ദശലക്ഷം ഉപയോക്താക്കളും ഏകദേശം 7 ദശലക്ഷം പ്രോജക്റ്റുകളും ഉള്ള ഇത് സമർപ്പിത ആർക്കിടെക്ചറുള്ള ഏറ്റവും വലിയ ഓപ്പൺ സോഴ്‌സ് SaaS സൈറ്റുകളിലൊന്നാണ്. PostgreSQL ഡാറ്റാബേസ് സിസ്റ്റം ഇല്ലാതെ, GitLab.com ഇൻഫ്രാസ്ട്രക്ചർ അധികം മുന്നോട്ട് പോകില്ല, ഡാറ്റ നഷ്‌ടപ്പെടുമ്പോൾ എന്തെങ്കിലും പരാജയങ്ങൾ ഉണ്ടായാൽ തെറ്റ് സഹിഷ്ണുത ഉറപ്പാക്കാൻ ഞങ്ങൾ എന്താണ് ചെയ്യുന്നത്. അത്തരമൊരു ദുരന്തം സംഭവിക്കാൻ സാധ്യതയില്ല, പക്ഷേ ഞങ്ങൾ നന്നായി തയ്യാറെടുക്കുകയും വിവിധ ബാക്കപ്പ്, റെപ്ലിക്കേഷൻ മെക്കാനിസങ്ങൾ ഉപയോഗിച്ച് സംഭരിക്കുകയും ചെയ്യുന്നു.

ഡാറ്റാബേസുകൾ ബാക്കപ്പ് ചെയ്യുന്നതിനുള്ള ഒരു മാർഗമല്ല റെപ്ലിക്കേഷൻ (ചുവടെ കാണുക). എന്നാൽ അലസമായ പകർപ്പ് ഉപയോഗിച്ച് ആകസ്മികമായി ഇല്ലാതാക്കിയ ഡാറ്റ എങ്ങനെ വേഗത്തിൽ വീണ്ടെടുക്കാമെന്ന് ഇപ്പോൾ നമ്മൾ കാണും: ഓൺ GitLab.com ഉപയോക്താവ് കുറുക്കുവഴി ഇല്ലാതാക്കി പദ്ധതിക്കായി gitlab-ce ലയന അഭ്യർത്ഥനകളും ടാസ്ക്കുകളും ഉള്ള കണക്ഷനുകൾ നഷ്ടപ്പെട്ടു.

മാറ്റിവെച്ച ഒരു പകർപ്പ് ഉപയോഗിച്ച്, വെറും 1,5 മണിക്കൂറിനുള്ളിൽ ഞങ്ങൾ ഡാറ്റ വീണ്ടെടുത്തു. അത് എങ്ങനെ സംഭവിച്ചുവെന്ന് നോക്കൂ.

PostgreSQL ഉപയോഗിച്ച് സമയ വീണ്ടെടുക്കൽ പോയിന്റ് ചെയ്യുക

PostgreSQL-ന് ഒരു ബിൽറ്റ്-ഇൻ ഫംഗ്ഷൻ ഉണ്ട്, അത് ഒരു ഡാറ്റാബേസിന്റെ അവസ്ഥയെ ഒരു നിശ്ചിത സമയത്തേക്ക് പുനഃസ്ഥാപിക്കുന്നു. ഇത് വിളിക്കപ്പെടുന്നത് പോയിന്റ്-ഇൻ-ടൈം വീണ്ടെടുക്കൽ (PITR) കൂടാതെ പകർപ്പ് കാലികമായി നിലനിർത്തുന്ന അതേ മെക്കാനിസങ്ങൾ ഉപയോഗിക്കുന്നു: മുഴുവൻ ഡാറ്റാബേസ് ക്ലസ്റ്ററിന്റെ (ബേസ് ബാക്കപ്പ്) വിശ്വസനീയമായ സ്നാപ്പ്ഷോട്ടിൽ നിന്ന് ആരംഭിച്ച്, ഒരു നിശ്ചിത സമയം വരെ ഞങ്ങൾ സംസ്ഥാന മാറ്റങ്ങളുടെ ഒരു ശ്രേണി പ്രയോഗിക്കുന്നു.

കോൾഡ് ബാക്കപ്പിനായി ഈ ഫീച്ചർ ഉപയോഗിക്കുന്നതിന്, ഞങ്ങൾ പതിവായി ഒരു അടിസ്ഥാന ഡാറ്റാബേസ് ബാക്കപ്പ് ഉണ്ടാക്കുകയും അത് ഒരു ആർക്കൈവിൽ സൂക്ഷിക്കുകയും ചെയ്യുന്നു (GitLab ആർക്കൈവുകൾ ജീവിക്കുന്നത് Google ക്ലൗഡ് സംഭരണം). റൈറ്റ്-എഹെഡ് ലോഗ് ആർക്കൈവ് ചെയ്തുകൊണ്ട് ഡാറ്റാബേസിന്റെ അവസ്ഥയിലെ മാറ്റങ്ങളും ഞങ്ങൾ നിരീക്ഷിക്കുന്നു (എഴുതാനുള്ള ലോഗ്, 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 സെഗ്‌മെന്റുകൾ വേർതിരിച്ചെടുക്കാൻ (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വീണ്ടും ശ്രമിച്ചതിന് ശേഷം സംഭവം അടയ്‌ക്കാനോ പ്രമോട്ട് ചെയ്യാനോ താൽക്കാലികമായി നിർത്താനോ (ഡിഫോൾട്ടായി ഇത് താൽക്കാലികമായി നിർത്തിവച്ചിരിക്കുന്നു).

നിർഭാഗ്യകരമായ ആ അഭ്യർത്ഥനയ്ക്ക് മുമ്പ് ഡാറ്റാബേസ് അതിന്റെ അവസ്ഥയിലേക്ക് മടങ്ങി. ഇപ്പോൾ നിങ്ങൾക്ക്, ഉദാഹരണത്തിന്, ഡാറ്റ എക്സ്പോർട്ട് ചെയ്യാം. ഞങ്ങൾ ഇല്ലാതാക്കിയ ലേബൽ ഡാറ്റയും പ്രശ്‌നങ്ങളിലേക്കുള്ള എല്ലാ ലിങ്കുകളും എക്‌സ്‌പോർട്ടുചെയ്‌തു, അഭ്യർത്ഥനകൾ ലയിപ്പിക്കുകയും അവ പ്രൊഡക്ഷൻ ഡാറ്റാബേസിലേക്ക് നീക്കുകയും ചെയ്തു. നഷ്ടങ്ങൾ വലിയ തോതിലുള്ളതാണെങ്കിൽ, നിങ്ങൾക്ക് പകർപ്പ് പ്രമോട്ട് ചെയ്യാനും പ്രധാനമായി ഉപയോഗിക്കാനും കഴിയും. എന്നാൽ നമ്മൾ വീണ്ടെടുക്കുന്ന പോയിന്റിന് ശേഷമുള്ള എല്ലാ മാറ്റങ്ങളും നഷ്ടപ്പെടും.

ടൈംസ്റ്റാമ്പുകൾക്ക് പകരം, ഇടപാട് ഐഡികൾ ഉപയോഗിക്കുന്നതാണ് നല്ലത്. ഈ ഐഡികൾ റെക്കോർഡ് ചെയ്യുന്നത് ഉപയോഗപ്രദമാണ്, ഉദാഹരണത്തിന്, DDL പ്രസ്താവനകൾക്ക് (ഉദാ DROP TABLE), ഉപയോഗിച്ച് log_statements = 'ddl'. ഞങ്ങൾക്ക് ഒരു ഇടപാട് ഐഡി ഉണ്ടെങ്കിൽ, ഞങ്ങൾ എടുക്കും recovery_target_xid അഭ്യർത്ഥനയ്‌ക്ക് മുമ്പുള്ള ഇടപാട് വരെ എല്ലാം നടത്തി DELETE.

ജോലിയിൽ തിരിച്ചെത്തുന്നത് വളരെ ലളിതമാണ്: ഇതിൽ നിന്ന് എല്ലാ മാറ്റങ്ങളും നീക്കം ചെയ്യുക recovery.conf പോസ്റ്റ്ഗ്രെസ് പുനരാരംഭിക്കുക. പകർപ്പിന് ഉടൻ തന്നെ വീണ്ടും എട്ട് മണിക്കൂർ കാലതാമസം ഉണ്ടാകും, ഭാവിയിലെ പ്രശ്‌നങ്ങൾക്ക് ഞങ്ങൾ തയ്യാറാണ്.

വീണ്ടെടുക്കൽ ആനുകൂല്യങ്ങൾ

തണുത്ത ബാക്കപ്പിന് പകരം മാറ്റിവെച്ച ഒരു പകർപ്പ് ഉപയോഗിച്ച്, ആർക്കൈവിൽ നിന്ന് മുഴുവൻ ചിത്രവും പുനഃസ്ഥാപിക്കാൻ നിങ്ങൾ മണിക്കൂറുകളോളം ചെലവഴിക്കേണ്ടതില്ല. ഉദാഹരണത്തിന്, അടിസ്ഥാന 2 TB ബാക്കപ്പ് ലഭിക്കാൻ ഞങ്ങൾക്ക് അഞ്ച് മണിക്കൂർ എടുക്കും. ആവശ്യമുള്ള അവസ്ഥയിലേക്ക് (ഏറ്റവും മോശം അവസ്ഥയിൽ) വീണ്ടെടുക്കാൻ നിങ്ങൾ ഇപ്പോഴും മുഴുവൻ പ്രതിദിന 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