અમે PostgreSQL સાથે ડિઝાસ્ટર રિકવરી માટે આળસુ પ્રતિકૃતિનો ઉપયોગ કેવી રીતે કર્યો

પ્રતિકૃતિ બેકઅપ નથી. કે નહીં? આકસ્મિક રીતે કાઢી નાખવામાં આવેલા શૉર્ટકટ્સમાંથી પુનઃપ્રાપ્ત કરવા માટે અમે કેવી રીતે વિલંબિત પ્રતિકૃતિનો ઉપયોગ કર્યો તે અહીં છે.

ઈન્ફ્રાસ્ટ્રક્ચર નિષ્ણાતો GitLab કામ માટે જવાબદાર છે GitLab.com - પ્રકૃતિમાં સૌથી મોટો ગિટલેબ દાખલો. 3 મિલિયન વપરાશકર્તાઓ અને લગભગ 7 મિલિયન પ્રોજેક્ટ્સ સાથે, તે સમર્પિત આર્કિટેક્ચર સાથેની સૌથી મોટી ઓપન સોર્સ SaaS સાઇટ્સમાંની એક છે. PostgreSQL ડેટાબેઝ સિસ્ટમ વિના, GitLab.com ઈન્ફ્રાસ્ટ્રક્ચર વધુ આગળ વધશે નહીં, અને જ્યારે ડેટા ગુમ થઈ શકે ત્યારે કોઈપણ નિષ્ફળતાના કિસ્સામાં ફોલ્ટ સહિષ્ણુતાની ખાતરી કરવા માટે અમે શું કરી રહ્યા છીએ. તે અસંભવિત છે કે આવી આપત્તિ થશે, પરંતુ અમે વિવિધ બેકઅપ અને પ્રતિકૃતિ પદ્ધતિઓ સાથે સારી રીતે તૈયાર છીએ અને સંગ્રહિત છીએ.

પ્રતિકૃતિ એ ડેટાબેસેસનો બેકઅપ લેવાનું સાધન નથી (નીચે જુઓ). પરંતુ હવે આપણે જોઈશું કે આળસુ પ્રતિકૃતિનો ઉપયોગ કરીને આકસ્મિક રીતે કાઢી નાખવામાં આવેલ ડેટાને ઝડપથી કેવી રીતે પુનઃપ્રાપ્ત કરવો: ચાલુ GitLab.com વપરાશકર્તા શોર્ટકટ કાઢી નાખ્યો પ્રોજેક્ટ માટે gitlab-ce અને મર્જ વિનંતીઓ અને કાર્યો સાથે જોડાણો ગુમાવ્યા.

વિલંબિત પ્રતિકૃતિ સાથે, અમે માત્ર 1,5 કલાકમાં ડેટા પુનઃપ્રાપ્ત કર્યો. તે કેવી રીતે થયું તે જુઓ.

PostgreSQL સાથે પોઈન્ટ ઇન ટાઇમ રિકવરી

PostgreSQL માં બિલ્ટ-ઇન ફંક્શન છે જે ડેટાબેઝની સ્થિતિને ચોક્કસ સમયે પુનઃસ્થાપિત કરે છે. તે કહેવાય છે પોઈન્ટ-ઈન-ટાઇમ રિકવરી (PITR) અને તે જ મિકેનિઝમ્સનો ઉપયોગ કરે છે જે પ્રતિકૃતિને અદ્યતન રાખે છે: સમગ્ર ડેટાબેઝ ક્લસ્ટર (બેઝ બેકઅપ) ના વિશ્વસનીય સ્નેપશોટથી શરૂ કરીને, અમે ચોક્કસ સમય સુધી રાજ્યના ફેરફારોની શ્રેણી લાગુ કરીએ છીએ.

કોલ્ડ બેકઅપ માટે આ સુવિધાનો ઉપયોગ કરવા માટે, અમે નિયમિતપણે મૂળભૂત ડેટાબેઝ બેકઅપ બનાવીએ છીએ અને તેને આર્કાઇવમાં સંગ્રહિત કરીએ છીએ (GitLab આર્કાઇવ્સ ગૂગલ ક્લાઉડ સ્ટોરેજ). અમે લખવા-આગળના લોગને (લખો-આગળ લોગ, WAL). અને આ બધા સાથે, અમે આપત્તિ પુનઃપ્રાપ્તિ માટે 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 આ કેવી રીતે કરે છે?

પોસ્ટગ્રેએસક્યુએલ આળસુ પુનઃપ્રાપ્તિને કેવી રીતે લાગુ કરે છે તે જોવાનું રસપ્રદ છે. ચાલો જોઈએ 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પુનઃપ્રયાસ પછી દાખલાને બંધ કરવા, પ્રમોટ કરવા અથવા થોભાવવા માટે (તે ડિફૉલ્ટ રૂપે સસ્પેન્ડ છે).

તે કમનસીબ વિનંતી પહેલાં ડેટાબેઝ તેની સ્થિતિમાં પાછો ફર્યો. હવે તમે, ઉદાહરણ તરીકે, ડેટા નિકાસ કરી શકો છો. અમે કાઢી નાખેલ લેબલ ડેટા અને સમસ્યાઓ અને મર્જ વિનંતીઓની બધી લિંક્સ નિકાસ કરી અને તેમને ઉત્પાદન ડેટાબેઝમાં ખસેડ્યા. જો નુકસાન મોટા પાયે હોય, તો તમે ફક્ત પ્રતિકૃતિને પ્રોત્સાહન આપી શકો છો અને તેનો મુખ્ય તરીકે ઉપયોગ કરી શકો છો. પરંતુ તે પછી જે બિંદુ સુધી આપણે પુનઃપ્રાપ્ત થયા છીએ તે પછીના બધા ફેરફારો ખોવાઈ જશે.

ટાઇમસ્ટેમ્પને બદલે, ટ્રાન્ઝેક્શન ID નો ઉપયોગ કરવો વધુ સારું છે. આ ID ને રેકોર્ડ કરવું ઉપયોગી છે, ઉદાહરણ તરીકે, DDL સ્ટેટમેન્ટ્સ માટે (જેમ કે DROP TABLE), ઉપયોગ કરીને log_statements = 'ddl'. જો અમારી પાસે ટ્રાન્ઝેક્શન આઈડી હશે તો અમે લઈશું recovery_target_xid અને વિનંતિ પહેલા વ્યવહારમાં બધું જ ચલાવ્યું DELETE.

કામ પર પાછા આવવું ખૂબ જ સરળ છે: માંથી બધા ફેરફારો દૂર કરો recovery.conf અને Postgres પુનઃપ્રારંભ કરો. પ્રતિકૃતિમાં ટૂંક સમયમાં ફરીથી આઠ કલાકનો વિલંબ થશે, અને અમે ભવિષ્યની મુશ્કેલીઓ માટે તૈયાર છીએ.

પુનઃપ્રાપ્તિ લાભો

કોલ્ડ બેકઅપને બદલે વિલંબિત પ્રતિકૃતિ સાથે, તમારે આર્કાઇવમાંથી સંપૂર્ણ છબીને પુનઃસ્થાપિત કરવામાં કલાકો પસાર કરવાની જરૂર નથી. ઉદાહરણ તરીકે, સંપૂર્ણ મૂળભૂત 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