Software Engineer/Architect RedHat Certified Specialist in OpenShift Administration

13 분 소요

Redis persistence

Redis가 디스크에 데이터를 쓰는 방법 지속성은 SSD(반도체 디스크)와 같은 내구성 있는 스토리지에 데이터를 쓰는 것을 말합니다. Redis는 다양한 지속성 옵션을 제공합니다. 여기에는 다음이 포함됩니다.

  • RDB (Redis Database): RDB 지속성은 지정된 간격으로 데이터 세트의 특정 시점 스냅샷을 수행합니다.
  • AOF (Append Only File): AOF 지속성은 서버에서 받은 모든 쓰기 작업을 기록합니다. 그런 다음 서버 시작 시 이러한 작업을 다시 재생하여 원래 데이터 세트를 재구성할 수 있습니다. 명령은 Redis 프로토콜 자체와 동일한 형식을 사용하여 기록됩니다.
  • No persistence: 지속성을 완전히 비활성화할 수 있습니다. 캐싱할 때 사용되기도 합니다.
  • RDB + AOF: 동일한 인스턴스에서 AOF와 RDB를 모두 결합할 수도 있습니다.
    이러한 다양한 지속성 전략 간의 절충에 대해 생각하지 않으려면 UI를 사용하여 미리 구성할 수 있는 Redis Enterprise의 지속성 옵션을 고려할 수 있습니다.

Redis 지속성 전략을 평가하는 방법에 대해 자세히 알아보려면 다음을 읽어보세요

RDB의 장점

  • RDB는 Redis 데이터의 매우 간결한 특정 시점 의 단일 파일입니다. RDB 파일은 백업에 적합합니다. 예를 들어 최근 24시간 동안 매시간 RDB 파일을 보관하고 30일 동안 매일 RDB 스냅샷을 저장할 수 있습니다. 이를 통해 재해 발생 시 다양한 버전의 데이터 세트를 쉽게 복원할 수 있습니다.
  • RDB는 원거리 데이터 센터 또는 Amazon S3(암호화될 수 있음)로 전송할 수 있는 단일 압축 파일로, 재해 복구에 매우 적합합니다.
  • RDB는 Redis 부모 프로세스가 유지하기 위해 수행하는 유일한 작업은 모든 작업을 수행할 자식 프로세스를을 포크하는 것이기 때문에 Redis 성능을 최대화합니다. 부모 프로세스는 디스크 I/O 등을 수행하지 않습니다.
  • RDB를 사용하면 AOF에 비해 큰 데이터 세트로 더 빠르게 다시 시작할 수 있습니다.
  • 복제본에서 RDB는 다시 시작 및 장애 조치(failover) 후 부분 다시 동기화를 지원합니다.

    RDB disadvantages

  • RDB는 Redis가 작동을 멈추는 경우 (예 : 정전 후) 데이터 손실 가능성을 최소화해야하는 경우 좋지 않습니다. RDB가 생성되는 다른 저장 지점을 구성할 수 있습니다 (예: 데이터 세트에 대해 최소 5분 및 100회 쓰기 후 여러 저장 지점을 가질 수 있음). 그러나 일반적으로 5 분 이상마다 RDB 스냅 샷을 생성하므로 어떤 이유로 든 올바르게 종료하지 않고 Redis가 작동을 멈추는 경우 최신 데이터(분)를 잃어버릴 각오가 되어 있어야 합니다.
    . RDB는 자식 프로세스를 사용하여 디스크에 지속되기 위해 자주 fork ()해야합니다. fork()는 데이터 세트가 큰 경우 시간이 많이 소요될 수 있으며, 데이터 세트가 매우 크고 CPU 성능이 좋지 않은 경우 Redis가 몇 밀리초 동안 또는 1초 동안 클라이언트 서비스를 중지할 수 있습니다. AOF도 fork()해야 하지만 빈도는 적습니다. 또한 내구성에 대한 절충 없이 로그를 다시 작성하려는 빈도를 조정할 수 있습니다. AOF advantages
  • AOF Redis를 사용하면 훨씬 더 내구성이 있습니다 : fsync를 전혀 사용하지 않고, 매 초마다 fsync하고, 모든 쿼리에서 fsync와 같은 다른 fsync 정책을 가질 수 있습니다. fsync every second의 기본 정책을 사용하면 쓰기 성능이 여전히 뛰어납니다. fsync는 백그라운드 스레드를 사용하여 수행됩니다. 그리고 메인 스레드는 fsync가 진행 중이 없을 때 쓰기를 수행하기 위해 열심히 노력하므로 1 초 분량의 쓰기 만 잃을 수 있습니다.
  • AOF 로그는 추가 전용 로그이므로 정전이 발생해도 검색 또는 손상 문제가 없습니다. 로그가 어떤 이유로(디스크가 꽉 찼거나 다른 이유로) 반쯤 작성된 명령으로 끝나더라도 redis-check-aof 도구는 쉽게 수정할 수 있습니다.
  • Redis는 AOF가 너무 커지면 백그라운드에서 AOF를 자동으로 다시 작성할 수 있습니다. Redis가 이전 파일에 계속 추가하는 동안 현재 데이터 세트를 만드는 데 필요한 최소한의 작업 세트로 완전히 새로운 파일이 생성되므로 다시 쓰기는 완전히 안전합니다. 이 두 번째 파일이 준비되면 Redis는 두 파일을 전환하고 새 파일에 추가하기 시작합니다.
  • AOF에는 이해하기 쉽고 구문 분석하기 쉬운 형식으로 모든 작업에 대한 로그가 하나씩 포함되어 있습니다. AOF 파일을 쉽게 내보낼 수도 있습니다. 예를 들어 FLUSHALL 명령을 사용하여 실수로 모든 것을 플러시한 경우에도 그 동안 로그를 다시 쓰지 않는 한 서버를 중지하고 최신 명령을 제거하여 데이터 세트를 저장할 수 있습니다. Redis를 다시 시작합니다..

AOF 단점

  • AOF 파일은 일반적으로 동일한 데이터 세트에 해당하는 RDB 파일보다 큽니다.
  • AOF는 정확한 fsync 정책에 따라 RDB보다 느릴 수 있습니다. 일반적으로 fsync를 매 초마다 설정하면 성능은 여전히 매우 높습니다. fsync를 비활성화하면 부하가 높은 경우에도 RDB만큼 빠릅니다. 그러나 RDB는 쓰기 부하가 큰 경우에도 최대 대기 시간에 대해 더 많은 보장을 제공할 수 있습니다.

Redis < 7.0

  • AOF는 다시 쓰는 동안 데이터베이스에 쓰기가 있는 경우 많은 메모리를 사용할 수 있습니다RDB는 Redis의 성능을 최대해합니다.Redis parent 프로세스는 데이터를 유지하기 위해 작업합니다. 나머지 모든 작업을 수행하는 자식 프로세스를 생성합니다.
  • Redis는 이러한 write 명령은 rewrite가 끝날 때 새 AOF 파일에 write할 때 쓰기 및 동기화를 중지할 수 있습니다.

그럼 뭘 써야 할까요?

두 가지 지속성 방법을 모두 사용해야 하는 일반적인 표시는 PostgreSQL이 제공할 수 있는 것과 비슷한 수준의 데이터 보안을 원하는 경우입니다.
데이터에 대해 많은 관심을 갖고 있지만 재해 발생시 몇 분의 데이터 손실로 살 수 있다면 RDB 만 사용할 수 있습니다.
AOF만 사용하는 사용자가 많지만 데이터베이스 백업을 수행하고, 더 빠르게 다시 시작하고, AOF 엔진에 버그가 있는 경우 RDB 스냅샷을 수시로 사용하는 것이 좋습니다.
다음 섹션에서는 두 가지 지속성 모델에 대한 몇 가지 세부 정보를 설명합니다.

스냅샷

기본적으로 Redis는 데이터 세트의 스냅샷을 디스크의 dump.rdb라는 이진 파일에 저장합니다. 데이터 세트에 최소 M개의 변경 사항이 있는 경우 N초마다 데이터 세트를 저장하도록 Redis를 구성하거나 SAVE 또는 BGSAVE 명령을 수동으로 호출할 수 있습니다.
예를 들어 이 구성은 1,000개 이상의 키가 변경된 경우 Redis가 60초마다 데이터 세트를 디스크에 자동으로 덤프하도록 합니다:

save 60 1000

이 전략을 스냅샷이라고 합니다.
작동 원리 Redis가 데이터 세트를 디스크에 덤프해야 할 때마다 다음과 같은 일이 발생합니다:

  • Redis forks. 자식과 부모 프로세스가 있습니다.
  • 자식은 데이터 세트를 임시 RDB 파일에 쓰기 시작합니다.
  • 자식이 새 RDB 파일 쓰기를 마치면 이전 RDB 파일을 대체합니다.
    이 방법을 사용하면 Redis가 기록 중 복사 의미 체계의 이점을 활용할 수 있습니다.

Append-only file

스냅 샷은 내구성이 좋지 않습니다. Redis를 실행하는 컴퓨터가 중지되거나, 전력선에 장애가 발생하거나, 실수로 인스턴스를 -9로 종료하면 Redis에 기록된 최신 데이터가 손실됩니다. 일부 애플리케이션에서는 이것이 큰 문제가 아닐 수 있지만 완전한 내구성을 위한 사용 사례가 있으며 이러한 경우 Redis 스냅샷만으로는 실행 가능한 옵션이 아닙니다.
The append-only file 는 Redis를 위한 완전히 내구성 있는 대안 전략입니다. 버전 1.1에서 사용할 수 있게 되었습니다.
구성 파일에서 AOF를 켤 수 있습니다:

appendonly yes

이제부터 Redis는 데이터 세트를 변경하는 명령(예: SET)을 수신할 때마다 AOF에 추가합니다. Redis를 다시 시작하면 AOF가 다시 재생되어 상태가 다시 빌드됩니다.
Redis 7.0.0부터 Redis는 여러 부분으로 구성된 AOF 메커니즘을 사용합니다. 즉, 원래 단일 AOF 파일은 기본 파일(최대 1개)과 증분 파일(둘 이상이 있을 수 있음)로 분할됩니다. 기본 파일은 AOF를 다시 쓸 때 존재하는 데이터의 초기(RDB 또는 AOF 형식) 스냅숏을 나타냅니다. 증분 파일에는 마지막 기본 AOF 파일이 생성된 이후의 증분 변경 내용이 포함되어 있습니다. 이러한 모든 파일은 별도의 디렉토리에 저장되며 매니페스트 파일에 의해 추적됩니다.

Log rewriting

AOF는 쓰기 작업이 수행됨에 따라 점점 더 커집니다. 예를 들어 카운터를 100번 증가시키면 최종 값이 포함된 단일 키가 데이터 세트에 있지만 AOF에는 100개의 항목이 있게 됩니다. 이러한 항목 중 99개는 현재 상태를 다시 빌드하는 데 필요하지 않습니다.
재 작성은 완전히 안전합니다. Redis가 이전 파일에 계속 추가하는 동안 현재 데이터 세트를 만드는 데 필요한 최소한의 작업 세트로 완전히 새로운 파일이 생성되고 이 두 번째 파일이 준비되면 Redis는 두 파일을 전환하고 새 파일에 추가하기 시작합니다.
따라서 Redis는 클라이언트에 대한 서비스를 중단하지 않고 백그라운드에서 AOF를 다시 빌드 할 수 있다는 흥미로운 기능을 지원합니다. BGREWRITEAOF를 실행할 때마다 Redis는 메모리에 현재 데이터 세트를 다시 빌드하는 데 필요한 가장 짧은 명령 시퀀스를 작성합니다. Redis 2.2에서 AOF를 사용하는 경우 BGREWRITEAOF를 수시로 실행해야 합니다. Redis 2.4는 로그 재작성을 자동으로 트리거할 수 있기 때문에(자세한 내용은 예제 구성 파일 참조).

Redis 7.0.0부터 AOF 다시 쓰기가 예약되면 Redis 상위 프로세스는 쓰기를 계속하기 위해 새 증분 AOF 파일을 엽니다. 하위 프로세스는 재작성 로직을 실행하고 새로운 기본 AOF를 생성합니다. Redis는 임시 매니페스트 파일을 사용하여 새로 생성된 기본 파일 및 증분 파일을 추적합니다. 준비가 되면 Redis는 원자성 대체 작업을 수행하여 이 임시 매니페스트 파일을 적용합니다. AOF 재작성의 반복 실패 및 재시도가 발생할 경우 많은 증분 파일을 생성하는 문제를 방지하기 위해 Redis는 실패한 AOF 재작성이 점점 더 느린 속도로 재시도되도록 하는 AOF 재작성 제한 메커니즘을 도입합니다.

append only file은 얼마나 내구성이 있습니까?

Redis가 디스크에서 데이터를 fsync하는 횟수를 구성할 수 있습니다. 세 가지 옵션이 있습니다:

  • appendfsync always: AOF에 새 명령어가 추가될 때마다 fsync를 사용합니다. 매우 느리고 매우 안전합니다. 명령은 여러 클라이언트 또는 파이프라인의 명령 일괄 처리가 실행된 후 AOF에 추가되므로 단일 쓰기 및 단일 fsync(회신을 보내기 전)를 의미합니다.
  • appendfsync everysec: 매초마다 fsync. 충분히 빠르며(버전 2.4부터는 스냅샷만큼 빠를 수 있음) 재해가 발생하면 1초의 데이터가 손실될 수 있습니다.
  • appendfsync no: fsync하지 말고 데이터를 운영 체제의 손에 맡기십시오. 더 빠르고 덜 안전한 방법. 일반적으로 리눅스는 이 구성으로 30초마다 데이터를 플러시하지만, 커널의 정확한 튜닝에 달려 있습니다.
    제안된(및 기본) 정책은 매초마다 fsync하는 것입니다 . 빠르고 비교적 안전합니다. always 정책은 실제로 매우 느리지만 그룹 커밋을 지원하므로 병렬 쓰기가 여러 개인 경우 Redis는 단일 fsync 작업을 수행하려고 합니다.

AOF가 잘리면 어떻게 해야 합니까?

AOF 파일을 쓰는 동안 서버가 충돌했거나 AOF 파일이 저장된 볼륨이 쓰기 시 가득 찼을 수 있습니다. 이 경우 AOF에는 데이터 세트의 지정된 특정 시점 버전(기본 AOF fsync 정책을 사용하여 최대 1초까지 오래될 수 있음)을 나타내는 일관된 데이터가 포함되지만 AOF의 마지막 명령이 잘릴 수 있습니다. Redis의 최신 주요 버전은 AOF를로드 할 수 있으며 파일에서 마지막으로 제대로 구성되지 않은 명령을 버립니다. 이 경우 서버는 다음과 같은 로그를 내보냅니다.:

  • Reading RDB preamble from AOF file…
  • Reading the remaining AOF tail…
  • !!! Warning: short read while loading the AOF file !!!
  • !!! Truncating the AOF at offset 439 !!!
  • AOF loaded anyway because aof-load-truncated is enabled 이러한 경우 Redis를 강제로 중지하도록 기본 구성을 변경할 수 있지만, 기본 구성은 다시 시작한 후 가용성을 보장하기 위해 파일의 마지막 명령이 제대로 구성되지 않았다는 사실에 관계없이 계속하는 것입니다.
    이전 버전의 Redis는 복구되지 않을 수 있으며 다음 단계가 필요할 수 있습니다:
  • AOF 파일의 백업 복사본 만들기.
  • Redis와 함께 제공되는 redis-check-aof 도구를 사용하여 원본 파일을 수정합니다.:
  • $ redis-check-aof –fix .
  • 선택적으로 diff -u 를 사용하여 두 파일의 차이점을 확인하십시오..
  • 수정된 파일을 사용하여 서버를 다시 시작합니다.

AOF가 손상되면 어떻게 해야 합니까?

AOF 파일이 잘린 것이 아니라 중간에 잘못된 바이트 시퀀스로 손상된 경우 상황이 더 복잡해집니다. Redis는 시작시 불평하고 중단됩니다.:

  • Reading the remaining AOF tail…
  • *Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof –fix . 가장 좋은 방법은 처음에 --fix 옵션 없이 redis-check-aof 유틸리티를 실행한 다음 문제를 이해하고 파일의 지정된 오프셋으로 이동하여 파일을 수동으로 복구할 수 있는지 확인하는 것입니다. AOF는 Redis 프로토콜과 동일한 형식을 사용하며 수동으로 수정하기가 매우 간단합니다. 그렇지 않으면 유틸리티가 파일을 수정하도록 할 수 있지만이 경우 잘못된 부분부터 파일 끝까지의 모든 AOF 부분이 삭제되어 손상이 발생하면 막대한 양의 데이터 손실이 발생할 수 있습니다.

작동 원리

로그 다시 쓰기는 스냅샷에 이미 사용 중인 것과 동일한 기록 중 복사 트릭을 사용합니다. 작동 방식은 다음과 같습니다.:

Redis >= 7.0

  • Redis 포크, 이제 자식과 부모 프로세스가 있습니다..
  • 자식은 임시 파일에 새 기본 AOF를 쓰기 시작합니다.
  • 부모는 새 증분 AOF 파일을 열어 업데이트 작성을 계속합니다. 재작성에 실패하면 이전 기본 및 증분 파일(있는 경우)과 새로 열린 이 증분 파일이 완전히 업데이트된 데이터 세트를 나타내므로 안전합니다.
  • 자식이 기본 파일 다시 쓰기를 완료하면 부모는 신호를 받고 새로 열린 증분 파일과 자식 생성 기본 파일을 사용하여 임시 매니페스트를 빌드하고 유지합니다.
  • 이익! 이제 Redis는 매니페스트 파일의 원자성 교환을 수행하여 이 AOF 재작성의 결과가 적용됩니다. 또한 Redis는 이전 기본 파일과 사용되지 않는 증분 파일을 정리합니다.

Redis < 7.0

  • Redis 포크, 이제 자식과 부모 프로세스가 있습니다..
  • 자식은 임시 파일에 새 AOF를 쓰기 시작합니다.
  • 부모는 메모리 내 버퍼에 모든 새 변경 사항을 누적합니다 (그러나 동시에 이전 추가 전용 파일에 새 변경 사항을 기록하므로 다시 쓰기가 실패하더라도 안전합니다).
  • 자식이 파일 다시 쓰기를 완료하면 부모는 신호를 받고 자식이 생성한 파일의 끝에 메모리 내 버퍼를 추가합니다.
  • 이제 Redis는 새 파일의 이름을 이전 파일로 원자적으로 바꾸고 새 파일에 새 데이터를 추가하기 시작합니다.
    현재 dump.rdb 스냅샷을 사용하고 있는 경우 AOF로 전환하려면 어떻게 해야 합니까?
    버전 2.0 이상에서는 Redis 2.2부터 더 간단하고 다시 시작할 필요가 전혀 없다고 짐작할 수 있으므로 이 작업을 수행하는 다른 절차가 있습니다.

Redis >= 2.2

  • 최신 dump.rdb 파일을 백업합니다..
  • 이 백업을 안전한 장소로 전송.
  • 다음 두 명령을 실행합니다.:
    ```bash
  • redis-cli config set appendonly yes
  • redis-cli config set save “” ```
  • 데이터베이스에 포함된 것과 동일한 수의 키가 포함되어 있는지 확인합니다.
  • 쓰기가 추가 전용 파일에 올바르게 추가되었는지 확인합니다..
    첫 번째 CONFIG 명령은 파일만 추가 지속성을 사용하도록 설정합니다.
    두 번째 CONFIG 명령은 스냅샷 지속성을 해제하는 데 사용됩니다. 두 가지 지속성 메서드를 모두 사용하도록 설정할 수 있는 경우 선택 사항입니다.
    IMPORTANT: redis.conf를 편집하여 AOF를 켜야 하며, 그렇지 않으면 서버를 다시 시작할 때 구성 변경 사항이 손실되고 서버가 이전 구성으로 다시 시작됩니다.

Redis 2.0

  • 최신 dump.rdb 파일을 백업합니다..
  • 이 백업을 안전한 장소로 전송.
  • 데이터베이스에 대한 모든 쓰기를 중지합니다!
  • redis-cli BGREWRITEAOF를 실행합니다. 이렇게 하면 추가 전용 파일이 만들어집니다.
  • Redis가 AOF 덤프 생성을 완료하면 서버를 중지합니다..
  • redis.conf파일을 편집하여, appendonly persistence를 enable 합니다.
  • 서버를 다시 시작합니다..
  • 데이터베이스에 전환 전에 포함된 것과 동일한 수의 키가 포함되어 있는지 확인합니다.
  • 쓰기가 추가 전용 파일에 올바르게 추가되었는지 확인합니다.

AOF와 RDB 지속성 간의 상호 작용

Redis >= 2.4는 RDB 스냅샷 작업이 이미 진행 중일 때 AOF 다시 쓰기를 트리거하거나 AOF 다시 쓰기가 진행 중인 동안 BGSAVE를 허용하지 않도록 합니다. 이렇게 하면 두 개의 Redis 백그라운드 프로세스가 동시에 많은 디스크 I/O를 수행하는 것을 방지할 수 있습니다. 스냅숏이 진행 중이고 사용자가 BGREWRITEAOF를 사용하여 로그 다시 쓰기 작업을 명시적으로 요청하면 서버는 사용자에게 작업이 예약되었음을 알리는 OK 상태 코드로 회신하고 스냅숏이 완료되면 다시 쓰기가 시작됩니다. AOF 및 RDB 지속성이 모두 활성화되고 Redis가 다시 시작되는 경우 AOF 파일은 가장 완전한 데이터 세트로 보장되므로 원래 데이터 세트를 재구성하는 데 사용됩니다.

Redis 데이터 백업

이 섹션을 시작하기 전에 다음 문장을 읽어야 합니다. 디스크가 고장나고, 클라우드의 인스턴스가 사라지는 등: 백업이 없다는 것은 데이터가 /dev/null로 사라질 위험이 크다는 것을 의미합니다..
Redis는 데이터베이스가 실행되는 동안 RDB 파일을 복사 할 수 있기 때문에 데이터 백업 친화적입니다 : RDB는 한 번 생성되면 수정되지 않으며, 생성되는 동안 임시 이름을 사용하고 새 스냅 샷이 완료 될 때만 rename(2)를 사용하여 원자 적으로 최종 대상으로 이름이 바뀝니다. 즉, 서버가 실행되는 동안 RDB 파일을 복사하는 것이 완전히 안전합니다. 이것이 우리가 제안하는 것입니다:

  • 서버에 cron 작업을 만들어 한 디렉터리에 RDB 파일의 시간별 스냅샷을 만들고 다른 디렉터리에 일일 스냅샷을 만듭니다.
  • cron 스크립트가 실행될 때마다, find 명령을 호출하여 너무 오래된 스냅샷이 삭제되었는지 확인해야 합니다: 예를 들어, 최근 48시간 동안 시간별 스냅샷을 찍을 수 있고, 1-2개월 동안 매일 스냅샷을 찍을 수 있습니다. 스냅샷의 이름을 날짜 및 시간 정보로 지정해야 합니다.
  • 매일 한 번 이상 RDB 스냅샷을 데이터 센터 외부 또는 최소한 Redis 인스턴스를 실행하는 물리적 시스템 외부로 전송해야 합니다.

Backing up AOF persistence

AOF 지속성만 활성화된 상태에서 Redis 인스턴스를 실행하는 경우에도 백업을 수행할 수 있습니다. Redis 7.0.0부터 AOF 파일은 appenddirname 구성에 의해 결정된 단일 디렉터리에 상주하는 여러 파일로 분할됩니다 . 정상 작동 중에는 백업을 위해 이 디렉토리의 파일을 복사/타르하기만 하면 됩니다. 그러나 다시 쓰는 동안 이 작업을 수행하면 잘못된 백업이 발생할 수 있습니다. 이 문제를 해결하려면 백업 중에 AOF 다시 쓰기를 사용하지 않도록 설정해야 합니다:

  1. Turn off automatic rewrites with CONFIG SET auto-aof-rewrite-percentage 0 이 시간 동안 수동으로 다시 쓰기(BGREWRITEAO 사용)를 시작하지 않도록 합니다.
  2. 다음을 사용하여 현재 다시 쓰기가 진행 중이 없는지 확인합니다. 
    INFO persistence

    and aof_rewrite_in_progress 확인하는 것은 0입니다. 1이면 다시 쓰기가 완료될 때까지 기다려야 합니다.

  3. 이제 appenddirname 디렉토리의 파일을 안전하게 복사 할 수 있습니다.
  4. 완료되면 다시 쓰기 다시 사용:
    CONFIG SET auto-aof-rewrite-percentage . Note: AOF 다시 쓰기를 사용하지 않도록 설정하는 시간을 최소화하려면 appenddirname의 파일에 대한 하드 링크를 만든 다음(위의 3단계에서) 하드 링크를 만든 후 다시 쓰기를 다시 사용하도록 설정(4단계)할 수 있습니다. 이제 하드링크를 복사/타르하고 완료되면 삭제할 수 있습니다. 이는 Redis가 이 디렉터리의 파일에만 추가하거나 필요한 경우 완전히 대체하도록 보장하므로 콘텐츠가 특정 시점에 일관성을 유지해야 하기 때문에 작동합니다. Note: 백업 중에 서버가 다시 시작되는 경우를 처리하고 다시 시작한 후 다시 쓰기가 자동으로 시작되지 않도록 하려면 위의 1단계를 변경하여 CONFIG REWRITE를 통해 업데이트된 구성을 유지할 수도 있습니다. 완료되면 자동 다시 쓰기를 다시 활성화하고(4단계) 다른 CONFIG REWRITE로 유지해야 합니다. 버전 7.0.0 이전에는 AOF 파일을 복사하기만 하면 AOF 파일을 백업할 수 있습니다(예: RDB 스냅샷 백업). 파일에 최종 부분이 없을 수 있지만 Redis는 여전히 파일을 로드할 수 있습니다(잘린 AOF 파일에 대한 이전 섹션 참조).

재해 복구

Redis의 맥락에서 재해 복구는 기본적으로 백업과 동일한 이야기이며 이러한 백업을 다양한 외부 데이터 센터로 전송할 수 있는 기능입니다. 이러한 방식으로 Redis가 실행되고 스냅샷을 생성하는 기본 데이터 센터에 영향을 미치는 치명적인 이벤트가 발생하는 경우에도 데이터를 보호할 수 있습니다.
비용이 너무 많이 들지 않는 가장 흥미로운 재해 복구 기술을 검토합니다.

  • Amazon S3 및 기타 유사한 서비스는 재해 복구 시스템을 구현하는 좋은 방법입니다. 일별 또는 시간별 RDB 스냅샷을 암호화된 형태로 S3로 전송하기만 하면 됩니다. gpg -c(대칭 암호화 모드)를 사용하여 데이터를 암호화할 수 있습니다. 암호를 여러 가지 안전한 장소에 저장해야 합니다(예: 조직의 가장 중요한 사람에게 복사본 제공). 데이터 안전성 향상을 위해 여러 스토리지 서비스를 사용하는 것이 좋습니다.
  • SCP(SSH의 일부)를 사용하여 원거리 서버로 스냅샷을 전송합니다. 이것은 매우 간단하고 안전한 경로입니다 : 아주 멀리 떨어져있는 곳에서 작은 VPS를 얻고, 거기에 ssh를 설치하고, 암호없이 ssh 클라이언트 키를 생성 한 다음 작은 VPS의 authorized_keys 파일에 추가하십시오. 자동화된 방식으로 백업을 전송할 준비가 되었습니다. 최상의 결과를 얻으려면 두 개의 다른 공급자에서 최소 두 개의 VPS를 받으십시오..
    이 시스템은 올바른 방식으로 구현되지 않으면 쉽게 실패할 수 있음을 이해하는 것이 중요합니다. 적어도 전송이 완료된 후 VPS를 사용하는 경우 파일 크기 (복사 한 파일 중 하나와 일치해야 함)와 SHA1 다이제스트를 확인할 수 있는지 확인하십시오.
    어떤 이유로 새로운 백업 전송이 작동하지 않는 경우 일종의 독립적 인 경고 시스템이 필요합니다.

태그:

카테고리:

업데이트:

댓글남기기

참고

최대 1 분 소요

1 분 소요

최대 1 분 소요

최대 1 분 소요