ਅਸੀਂ 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.

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 ਲਈ ਕੋਲਡ ਬੈਕਅੱਪ ਵੀ ਲੈਣਾ ਹੋਵੇਗਾ)।

ਅਸੀਂ ਮੁਲਤਵੀ ਪੋਸਟਗ੍ਰੇਸ ਉਦਾਹਰਨ ਨੂੰ ਮੁੜ-ਚਾਲੂ ਕੀਤਾ ਅਤੇ 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ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਬਾਅਦ ਉਦਾਹਰਨ ਨੂੰ ਬੰਦ ਕਰਨ, ਪ੍ਰਚਾਰ ਕਰਨ ਜਾਂ ਰੋਕਣ ਲਈ (ਇਹ ਮੂਲ ਰੂਪ ਵਿੱਚ ਮੁਅੱਤਲ ਹੈ)।

ਉਸ ਮੰਦਭਾਗੀ ਬੇਨਤੀ ਤੋਂ ਪਹਿਲਾਂ ਡੇਟਾਬੇਸ ਆਪਣੀ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਆ ਗਿਆ। ਹੁਣ ਤੁਸੀਂ, ਉਦਾਹਰਨ ਲਈ, ਡਾਟਾ ਨਿਰਯਾਤ ਕਰ ਸਕਦੇ ਹੋ। ਅਸੀਂ ਮਿਟਾਏ ਗਏ ਲੇਬਲ ਡੇਟਾ ਅਤੇ ਮੁੱਦਿਆਂ ਦੇ ਸਾਰੇ ਲਿੰਕਾਂ ਨੂੰ ਨਿਰਯਾਤ ਕੀਤਾ ਅਤੇ ਬੇਨਤੀਆਂ ਨੂੰ ਮਿਲਾਇਆ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਉਤਪਾਦਨ ਡੇਟਾਬੇਸ ਵਿੱਚ ਭੇਜ ਦਿੱਤਾ। ਜੇਕਰ ਨੁਕਸਾਨ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਮੁੱਖ ਵਜੋਂ ਵਰਤ ਸਕਦੇ ਹੋ। ਪਰ ਫਿਰ ਉਸ ਬਿੰਦੂ ਤੋਂ ਬਾਅਦ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਖਤਮ ਹੋ ਜਾਣਗੀਆਂ ਜਿਸ ਤੱਕ ਅਸੀਂ ਮੁੜ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ।

ਟਾਈਮਸਟੈਂਪਾਂ ਦੀ ਬਜਾਏ, ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਆਈਡੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ। ਇਹਨਾਂ IDs ਨੂੰ ਰਿਕਾਰਡ ਕਰਨਾ ਲਾਭਦਾਇਕ ਹੈ, ਉਦਾਹਰਨ ਲਈ, DDL ਸਟੇਟਮੈਂਟਾਂ (ਜਿਵੇਂ ਕਿ DROP TABLE), ਵਰਤ ਕੇ log_statements = 'ddl'. ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਆਈਡੀ ਹੁੰਦੀ, ਤਾਂ ਅਸੀਂ ਲੈ ਲੈਂਦੇ recovery_target_xid ਅਤੇ ਬੇਨਤੀ ਤੋਂ ਪਹਿਲਾਂ ਲੈਣ-ਦੇਣ ਲਈ ਸਭ ਕੁਝ ਹੇਠਾਂ ਚਲਾ ਗਿਆ DELETE.

ਕੰਮ 'ਤੇ ਵਾਪਸ ਜਾਣਾ ਬਹੁਤ ਸੌਖਾ ਹੈ: ਇਸ ਤੋਂ ਸਾਰੇ ਬਦਲਾਅ ਹਟਾਓ recovery.conf ਅਤੇ ਪੋਸਟਗ੍ਰੇਸ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰੋ। ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਿੱਚ ਜਲਦੀ ਹੀ ਅੱਠ ਘੰਟੇ ਦੀ ਦੇਰੀ ਹੋਵੇਗੀ, ਅਤੇ ਅਸੀਂ ਭਵਿੱਖ ਦੀਆਂ ਮੁਸੀਬਤਾਂ ਲਈ ਤਿਆਰ ਹਾਂ।

ਰਿਕਵਰੀ ਲਾਭ

ਕੋਲਡ ਬੈਕਅਪ ਦੀ ਬਜਾਏ ਮੁਲਤਵੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਨਾਲ, ਤੁਹਾਨੂੰ ਪੁਰਾਲੇਖ ਤੋਂ ਪੂਰੀ ਚਿੱਤਰ ਨੂੰ ਬਹਾਲ ਕਰਨ ਲਈ ਘੰਟੇ ਬਿਤਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਪੂਰਾ ਮੂਲ 2 ਟੀਬੀ ਬੈਕਅੱਪ ਲੈਣ ਵਿੱਚ ਸਾਨੂੰ ਪੰਜ ਘੰਟੇ ਲੱਗਦੇ ਹਨ। ਅਤੇ ਫਿਰ ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਲੋੜੀਂਦੀ ਸਥਿਤੀ (ਸਭ ਤੋਂ ਮਾੜੀ ਸਥਿਤੀ ਵਿੱਚ) ਵਿੱਚ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਪੂਰਾ ਰੋਜ਼ਾਨਾ 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