🥇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ಮರುಪ್ರಯತ್ನದ ನಂತರ ನಿದರ್ಶನವನ್ನು ಮುಚ್ಚಲು, ಪ್ರಚಾರ ಮಾಡಲು ಅಥವಾ ವಿರಾಮಗೊಳಿಸಲು (ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅಮಾನತುಗೊಳಿಸಲಾಗಿದೆ).

ಆ ದುರದೃಷ್ಟಕರ ವಿನಂತಿಯ ಮೊದಲು ಡೇಟಾಬೇಸ್ ತನ್ನ ಸ್ಥಿತಿಗೆ ಮರಳಿತು. ಈಗ ನೀವು ಉದಾಹರಣೆಗೆ, ಡೇಟಾವನ್ನು ರಫ್ತು ಮಾಡಬಹುದು. ನಾವು ಅಳಿಸಲಾದ ಲೇಬಲ್ ಡೇಟಾ ಮತ್ತು ಸಮಸ್ಯೆಗಳಿಗೆ ಎಲ್ಲಾ ಲಿಂಕ್‌ಗಳನ್ನು ರಫ್ತು ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ವಿನಂತಿಗಳನ್ನು ವಿಲೀನಗೊಳಿಸಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಉತ್ಪಾದನಾ ಡೇಟಾಬೇಸ್‌ಗೆ ಸರಿಸಿದೆವು. ನಷ್ಟಗಳು ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿದ್ದರೆ, ನೀವು ಸರಳವಾಗಿ ಪ್ರತಿಕೃತಿಯನ್ನು ಪ್ರಚಾರ ಮಾಡಬಹುದು ಮತ್ತು ಅದನ್ನು ಮುಖ್ಯವಾಗಿ ಬಳಸಬಹುದು. ಆದರೆ ನಾವು ಚೇತರಿಸಿಕೊಂಡ ನಂತರದ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳು ಕಳೆದುಹೋಗುತ್ತವೆ.

ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳ ಬದಲಿಗೆ, ವಹಿವಾಟು ಐಡಿಗಳನ್ನು ಬಳಸುವುದು ಉತ್ತಮ. ಈ ಐಡಿಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಲು ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ಡಿಡಿಎಲ್ ಹೇಳಿಕೆಗಳಿಗೆ (ಉದಾಹರಣೆಗೆ 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 ನೊಂದಿಗೆ ವಿಪತ್ತು ಮರುಪಡೆಯುವಿಕೆಗಾಗಿ ನಾವು ಲೇಜಿ ರೆಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೇಗೆ ಬಳಸಿದ್ದೇವೆ