PostgreSQL에서 재해 복구를 위해 지연 복제를 사용하는 방법

복제는 백업이 아닙니다. 아니면? 실수로 삭제된 바로가기를 복구하기 위해 지연 복제를 사용한 방법은 다음과 같습니다.

인프라 전문가 GitLab이 작업을 담당합니다. GitLab.com - 자연계에서 가장 큰 GitLab 인스턴스입니다. 3백만 명의 사용자와 약 7백만 개의 프로젝트를 보유한 이 사이트는 전용 아키텍처를 갖춘 최대 오픈 소스 SaaS 사이트 중 하나입니다. PostgreSQL 데이터베이스 시스템이 없으면 GitLab.com 인프라는 멀리 가지 못할 것이며, 데이터가 손실될 수 있는 오류가 발생할 경우 내결함성을 보장하기 위해 우리는 무엇을 하고 있습니까? 이러한 재난이 발생할 가능성은 거의 없지만 다양한 백업 및 복제 메커니즘을 잘 준비하고 비축하고 있습니다.

복제는 데이터베이스를 백업하는 수단이 아닙니다(아래 참조). 하지만 이제 지연 복제를 사용하여 실수로 삭제된 데이터를 신속하게 복구하는 방법을 살펴보겠습니다. GitLab.com 사용자 바로가기를 삭제했습니다 프로젝트를 위해 gitlab-ce 병합 요청 및 작업과의 연결이 끊어졌습니다.

지연된 복제본을 사용하여 단 1,5시간 만에 데이터를 복구했습니다. 어떻게 된 일인지 보세요.

PostgreSQL을 사용한 특정 시점 복구

PostgreSQL에는 데이터베이스 상태를 특정 시점으로 복원하는 기능이 내장되어 있습니다. 그것은이라고 특정 시점 복구 (PITR) 복제본을 최신 상태로 유지하는 것과 동일한 메커니즘을 사용합니다. 전체 데이터베이스 클러스터의 안정적인 스냅샷(기본 백업)부터 시작하여 특정 시점까지 일련의 상태 변경을 적용합니다.

콜드 백업에 이 기능을 사용하기 위해 우리는 정기적으로 기본 데이터베이스 백업을 만들어 아카이브에 저장합니다(GitLab 아카이브는 구글 클라우드 스토리지). 또한 미리 쓰기 로그를 보관하여 데이터베이스 상태의 변경 사항을 모니터링합니다(미리 쓰기 로그, 월). 그리고 이 모든 것이 준비되면 재해 복구를 위한 PITR을 수행할 수 있습니다. 오류가 발생하기 전에 찍은 스냅샷부터 시작하여 WAL 아카이브의 변경 사항을 오류까지 적용합니다.

지연 복제란 무엇입니까?

지연 복제는 WAL의 변경 사항을 지연하여 적용하는 것입니다. 즉, 거래가 한 시간 안에 이루어졌습니다. X, 그러나 지연과 함께 복제본에 표시됩니다. d 1시에 X + d.

PostgreSQL에는 물리적 데이터베이스 복제본을 설정하는 두 가지 방법, 즉 백업 복구와 스트리밍 복제가 있습니다. 아카이브에서 복원, 기본적으로 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) 아카이브에서 삭제되며 변경사항은 XNUMX시간(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). 보시다시피 지연은 커밋에만 적용되며 다른 항목에는 영향을 주지 않습니다. 모든 변경 사항은 직접 적용되고 커밋이 지연되므로 구성된 지연 후에만 변경 사항이 표시됩니다.

지연된 복제본을 사용하여 데이터를 복원하는 방법

프로덕션이 XNUMX시간 지연된 데이터베이스 클러스터와 복제본이 있다고 가정해 보겠습니다. 예제를 사용하여 데이터를 복구하는 방법을 살펴 보겠습니다. 실수로 바로가기 삭제.

문제에 대해 알게 되었을 때 우리는 아카이브 복원이 일시 중지되었습니다 지연된 복제본의 경우:

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재시도 후 인스턴스를 닫거나 승격하거나 일시 중지합니다(기본적으로 일시 중지됨).

데이터베이스는 불행한 요청 이전의 상태로 돌아갔습니다. 이제 데이터를 내보낼 수 있습니다. 삭제된 라벨 데이터와 이슈 및 병합 요청에 대한 모든 링크를 내보내고 이를 프로덕션 데이터베이스로 옮겼습니다. 손실 규모가 큰 경우 복제본을 승격하여 기본 복제본으로 사용할 수 있습니다. 그러나 복구한 지점 이후의 모든 변경 사항은 손실됩니다.

타임스탬프 대신 트랜잭션 ID를 사용하는 것이 더 좋습니다. 예를 들어 DDL 문(예: DROP TABLE), 사용하여 log_statements = 'ddl'. 거래 ID가 있다면 recovery_target_xid 요청 전에 트랜잭션까지 모든 것을 실행했습니다. DELETE.

작업으로 돌아가는 것은 매우 간단합니다. 모든 변경 사항을 제거하세요. recovery.conf Postgres를 다시 시작하십시오. 복제본은 곧 다시 XNUMX시간 지연될 예정이며 향후 문제에 대비하고 있습니다.

회복 혜택

콜드 백업 대신 지연된 복제본을 사용하면 아카이브에서 전체 이미지를 복원하는 데 몇 시간을 소비할 필요가 없습니다. 예를 들어 기본 2TB 백업 전체를 가져오는 데 XNUMX시간이 걸립니다. 그런 다음 원하는 상태(최악의 경우)로 복구하려면 전체 일일 WAL을 적용해야 합니다.

지연된 복제본은 두 가지 측면에서 콜드 백업보다 우수합니다.

1. 아카이브에서 전체 기본 백업을 제거할 필요가 없습니다.
2. 반복해야 하는 WAL 세그먼트의 고정된 XNUMX시간 기간이 있습니다.

또한 WAL에서 PITR을 만드는 것이 가능한지 지속적으로 확인하고 지연된 복제본의 지연을 모니터링하여 WAL 아카이브의 손상이나 기타 문제를 신속하게 발견할 수 있습니다.

이 예에서는 복원하는 데 50분이 걸렸습니다. 즉, 속도는 시간당 110GB의 WAL 데이터였습니다(아카이브는 여전히 남아 있음). AWS S3). 전체적으로 우리는 문제를 해결하고 1,5시간 만에 데이터를 복구했습니다.

결과: 지연된 복제본이 유용한 경우와 그렇지 않은 경우

실수로 데이터를 손실하고 구성된 지연 내에 이 문제를 발견한 경우 지연된 복제를 응급 처치로 사용하십시오.

하지만 명심하세요: 복제는 백업이 아닙니다.

백업과 복제는 목적이 다릅니다. 실수로 만든 경우 콜드 백업이 유용합니다. DELETE 또는 DROP TABLE. 콜드 스토리지에서 백업을 만들고 테이블 또는 전체 데이터베이스의 이전 상태를 복원합니다. 그러나 동시에 요청 DROP TABLE 작업 클러스터의 모든 복제본에서 거의 즉각적으로 복제되므로 여기서는 일반적인 복제가 도움이 되지 않습니다. 복제 자체는 개별 서버를 임대하고 로드를 분산할 때 데이터베이스를 사용 가능한 상태로 유지합니다.

지연된 복제본을 사용하더라도 데이터 센터 오류, 숨겨진 손상 또는 즉시 눈에 띄지 않는 기타 이벤트가 발생할 경우 안전한 장소에 콜드 백업이 필요한 경우가 있습니다. 여기서는 복제만으로는 소용이 없습니다.

주의. 에 GitLab.com 현재는 시스템 수준의 데이터 손실만 방지하고 사용자 수준의 데이터는 복구하지 않습니다.

출처 : habr.com