[Redis] 지속성(Persistence)에 대한 레퍼런스 한글문서, Failover

안녕하세요. yeTi입니다.

오늘은 Redis(레디스)의 레퍼런스문서중 Rersistence에 관한 부분을 한글로 번역하여 이해해보겠습니다.

(URL : https://redis.io/topics/persistence)

아시다시피 Redis는 NoSQL의 하나이고 메모리 저장방식을 사용합니다.

따라서 장애가 발생했을때 기본적으로는 모든 데이터가 날아가는 특성이 있는데요.

이를 데이터 스냅샷 기능과 명령어 저장 방식을 통해 

원본 데이터를 살려주고 있습니다.

하지만 이는 RDBMS와는 다르게 일정 주기로 데이터를 보존해 주기때문에

특정 주기동안에 메모리에만 저장한 데이터는 복원이 안되는 특성이 있다는 것을

이해하시면서 사용하시면 좋을꺼 같습니다.

자세한 부분은 아래에서 살펴보겠습니다.

이 페이지는 Redis 지속성에 대한 기술적 설명을 제공하며 모든 Redis 사용자에게 읽기를 권장합니다. Redis의 지속성(Persistence) 및 내구성 보증(Durability guarantees)에 대한 전반적인 설명은 Redis persistence demystified을 통해 확인할 수 있습니다.

Redis 지속성(Persistence)

Redis는 다른 범위의 지속성(Persistence) 옵션을 제공합니다.

• RDB 지속성(Persistence)은 지정된 간격으로 데이터 세트의 특정 시점을 스냅 샷을 저장합니다.
• AOF 지속성(Persistence)은 서버가 수신 한 모든 쓰기 명령어를 기록하며, 서버 시작시 재수행하여 원래 데이터 세트로 구성합니다. 명령어는 Redis 프로토콜과 동일한 형식으로 추가(Append) 기록됩니다. Redis는 로그가 너무 커지면 백그라운드로 로그를 기록합니다.
• 서버가 실행되는 동안만 데이터를 사용하려면 지속성(Persistence)을 사용하지 않도록 설정할 수 있습니다.
• AOF와 RDB를 동일한 인스턴스에서 결합 할 수 있습니다. 이 경우 Redis를 다시 시작하면 AOF 파일은 가장 완전 함이 보장되어 있기 때문에 원래의 데이터 세트를 구성하는데 사용됩니다.

여기서 가장 중요한 점은 RDB와 AOF 지속성(Persistence) 간의 장단점을 이해하는 것입니다. RDB부터 살펴보겠습니다.

RDB 장점

• RDB는 Redis 데이터의 매우 작은 단일 시점 파일 표현입니다. RDB 파일은 백업에 적합합니다. 예를 들어, 최신 24 시간 동안 매시간 RDB 파일을 아카이브하고 30 일 동안 매일 RDB 스 냄샷을 저장하려고 할 수 있습니다. 재난 발생시 다른 버전의 데이터 세트를 쉽게 복원 할 수 있습니다.
• RDB는 재해 복구에 매우 유용합니다. 단 하나의 소형 파일을 멀리있는 데이터 센터 또는 Amazon S3 (암호화 가능)로 전송할 수 있습니다.
• Redis 부모 프로세스가 지속하기 위해해야하는 유일한 작업은 나머지 작업을 수행하는 자식을 포크로 작업하기 때문에 RDB는 Redis 성능을 극대화합니다. 부모 인스턴스는 디스크 입출력을 수행하지 않습니다.
• RDB는 AOF와 비교하여 큰 데이터 세트를 사용하여 재시작을 빠르게합니다.

RDB 단점

• Redis가 작동을 멈춘 경우 (예 : 정전 후) 데이터 손실 가능성을 최소화해야하는 경우 RDB가 좋지 않습니다. RDB가 생성되는 다른 저장 지점을 구성 할 수 있습니다 (예를 들어 데이터 세트에 대해 최소 5 분 및 100 회 기록 후, 여러 저장 지점을 가질 수 있음). 그러나 일반적으로 5 분 이상마다 RDB 스냅 샷을 생성하므로 어떤 이유로 든 정상 종료없이 Redis가 작동을 멈추는 경우 최신 데이터 분을 잃어 버릴 준비를해야합니다.
• RDB는 자식 프로세스를 사용하여 디스크에 지속시키기 위해 fork ()를 자주 수행해야합니다. 데이터 세트가 크면 Fork ()에 시간이 많이 걸릴 수 있으며 데이터 세트가 매우 크고 CPU 성능이 좋지 않은 경우 Redis는 클라이언트에 수 밀리 초 또는 1 초 동안 서비스를 제공하지 않을 수 있습니다. 또한 AOF는 fork ()해야하지만 내구성에 대한 절충없이 로그를 다시 작성하려는 빈도를 조정할 수 있습니다.

AOF 이점

• AOF Redis를 사용하면 훨씬 더 오래 지속될 수 있습니다. 즉, fsync를 전혀 사용하지 않고 fsync를 매초마다 실행하고 모든 쿼리를 fsync 할 수 있습니다. fsync의 기본 정책을 사용하면 매 초마다 쓰기 성능이 여전히 우수합니다 (fsync는 백그라운드 스레드를 사용하여 수행되며 fsync가 진행 중이 지 않을 때 주 스레드는 쓰기를 수행하려고 시도합니다).하지만 1 초의 쓰기 만 손실 할 수 있습니다.
• AOF 로그는 추가 전용 로그이므로 정전이 발생해도 검색이 없으며 손상 문제가 없습니다. 어떤 이유로 (디스크가 가득 차거나 다른 이유로) 로그가 절반으로 작성된 명령으로 끝난 경우에도 redis-check-aof 도구를 사용하면 쉽게 수정할 수 있습니다.
• Redis는 너무 커지면 백그라운드에서 AOF를 자동으로 다시 쓸 수 있습니다. Redis가 이전 파일에 계속 추가하는 동안 현재 데이터 세트를 만드는 데 필요한 최소한의 작업 세트로 완전히 새로운 파일이 생성되고이 두 번째 파일이 준비되면 Redis가 두 파일을 전환하고 새로운 것.
• AOF에는 이해하기 쉽고 구문 분석 할 수있는 형식으로 차례로 모든 작업의 ​​로그가 포함됩니다. AOF 파일을 쉽게 내보낼 수도 있습니다. 예를 들어 FLUSHALL 명령을 사용하여 모든 오류를 플러시 했더라도 로그를 다시 작성하지 않으면 서버를 중지하고 최신 명령을 제거한 다음 Redis를 다시 시작하여 데이터 세트를 저장할 수 있습니다.

AOF 단점

• AOF 파일은 대개 동일한 데이터 세트에 해당하는 RDB 파일보다 큽니다.
• AFS는 정확한 fsync 정책에 따라 RDB보다 느릴 수 있습니다. 일반적으로 fsync를 매초마다 설정하면 성능은 여전히 ​​높으며 fsync를 사용하지 않으면 높은 부하에서도 RDB와 똑같은 속도를 유지해야합니다. 아직도 RDB는 거대한 쓰기로드의 경우에도 최대 대기 시간에 대해 더 많은 보장을 제공 할 수 있습니다.
• 과거에는 특정 명령에 희귀 한 버그가 발생했습니다 (예 : BRPOPLPUSH와 같은 명령을 차단하는 것과 관련된 명령). AOF로 인해 다시로드 할 때 동일한 데이터 세트가 정확하게 재현되지 않습니다. 이 버그는 드물고 테스트 스위트에서 테스트를 통해 임의의 복잡한 데이터 세트를 자동으로 생성하고 모든 데이터를 다시로드해도 괜찮은지 확인하지만 RDB 지속성을 사용하면 거의 불가능합니다. 이 점을보다 분명하게하기 위해 : Redis AOF는 MySQL이나 MongoDB와 같은 기존 상태를 점진적으로 업데이트하는 반면, RDB 스냅 샷팅은 모든 것을 처음부터 새로 생성합니다. 개념적으로 더 강력합니다. 그러나 - 1) AOF가 Redis에 의해 재 작성 될 때마다 데이터 세트에 포함 된 실제 데이터부터 처음부터 다시 작성된다는 점에 유의해야합니다. 항상 AOF 파일을 추가하는 것 (또는 메모리에있는 데이터를 읽는 대신 오래된 AOF를 읽는 것)보다 버그에 대한 저항력이 강합니다. 2) 실제 세계에서 발견 된 AOF 손상에 대한 사용자의 보고서는 한 번도 없었습니다.

좋아, 그럼 내가 뭘 써야 할까?

일반적인 지시 사항은 PostgreSQL이 제공 할 수있는 정도의 데이터 안전성을 원한다면 두 가지 지속성 방법을 모두 사용해야한다는 것입니다.

데이터를 많이 신경 써야하지만 재해 발생시 몇 분의 데이터 손실이 발생하더라도 RDB 만 사용하면됩니다.

AOF 만 사용하는 사용자가 많지만 때때로 RDB 스냅 샷을 가지고 있기 때문에 데이터베이스 백업, 빠른 재시작 및 AOF 엔진의 버그 발생시에 좋은 방법입니다.

참고 : 이러한 모든 이유 때문에 향후 AOF 및 RDB를 단일 지속성 모델로 통일하게 될 것입니다 (장기 계획).

다음 섹션에서는 두 가지 지속성 모델에 대해 자세히 설명합니다.

스냅 샷

기본적으로 Redis는 데이터 세트의 스냅 샷을 디스크의 바이너리 파일에 저장합니다 dump.rdb. 데이터 세트에 적어도 M 개의 변경 사항이있을 경우 매 N 초마다 데이터 세트를 저장하도록 Redis를 구성하거나 수동으로 SAVE 또는 BGSAVE 명령을 호출 할 수 있습니다 .

예를 들어,이 구성을 사용하면 최소한 1000 개의 키가 변경된 경우 Redis가 자동으로 데이터 세트를 60 초마다 디스크에 덤프합니다.

save 60 1000

이 전략은 스냅 샷 으로 알려져 있습니다 .

작동 원리

Redis가 데이터 세트를 디스크에 덤프해야 할 때마다 이런 일이 발생합니다.

• Redis 포크 . 우리에게는 이제 자녀와 부모 과정이 있습니다.

• 자식이 임시 RDB 파일에 데이터 집합을 작성하기 시작합니다.

• 자식이 새로운 RDB 파일 작성을 마치면 이전 RDB 파일을 대체합니다.

이 방법을 사용하면 Redis는 copy-on-write 의미 체계의 이점을 누릴 수 있습니다.

추가 전용 파일

스냅 샷은 매우 내구성이 없습니다. Redis를 실행하는 컴퓨터가 중지되거나 전원 선이 실패하거나 kill -9인스턴스가 실수로 실행되면 Redis에서 작성된 최신 데이터가 손실됩니다. 일부 애플리케이션의 경우 큰 문제는 아니지만 완전한 내구성을위한 사용 사례가 있으며 이러한 경우 Redis는 실행 가능한 옵션이 아닙니다.

추가 전용 파일은 레디 스에 대한 대안, 완벽한 내구성 전략이다. 버전 1.1에서 사용할 수있게되었습니다.

구성 파일에서 AOF를 켤 수 있습니다.

appendonly yes

이제 Redis는 데이터 세트 (예 : SET ) 를 변경하는 명령을 수신 할 때마다 이를 AOF에 추가합니다. Redis를 다시 시작하면 AOF가 다시 재생되어 상태를 다시 작성합니다.

로그 다시 쓰기

추측 할 수 있듯이 AOF는 쓰기 작업이 수행 될수록 커집니다. 예를 들어, 카운터를 100 번 증가 시키면 최종 값을 포함하는 데이터 세트의 단일 키가되지만 AOF의 항목은 100 개가됩니다. 99 개 항목은 현재 상태를 다시 작성하는 데 필요하지 않습니다.

따라서 Redis는 흥미로운 기능을 지원합니다. 클라이언트에 대한 서비스를 중단하지 않고 백그라운드에서 AOF를 재구성 할 수 있습니다. BGREWRITEAOF 를 실행할 때마다 Redis는 현재 데이터 세트를 메모리에 다시 작성하는 데 필요한 가장 짧은 명령 시퀀스를 작성합니다. Redis 2.2에서 AOF를 사용하는 경우 BGREWRITEAOF 를 수시로 실행해야합니다 . Redis 2.4는 로그 재 작성을 자동으로 트리거 할 수 있습니다 (자세한 내용은 2.4 예제 구성 파일을 참조하십시오).

첨부 파일은 얼마나 오래 지속됩니까?

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

• fsync 새로운 명령이 AOF에 추가 될 때마다 아주 아주 천천히, 아주 안전합니다.

• fsync 매 초. 빠르면 (스냅 샷만큼 빨리 처리 할 가능성이 높음) 재난이 발생하면 1 초의 데이터가 손실 될 수 있습니다.

• 절대로 fsync, 데이터를 운영 체제의 손에 넣기 만하면됩니다. 더 빠르고 안전하지 않은 방법.

제안 된 (및 기본) 정책은 fsync 매 초입니다. 그것은 매우 빠르고 안전합니다. always(가 레디 스 2.0에서 개선되었다하더라도) 정책은 실제로는 매우 느립니다 - 할 수있는 방법이 없습니다 fsync빨리 그것보다가.

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

AOF 파일을 쓰는 동안 서버가 충돌 할 수 있습니다 (여전히 불일치가 발생해서는 안 됨). Redis에서 더 이상로드 할 수없는 방식으로 파일을 손상시킬 수 있습니다. 이 경우 다음 절차를 사용하여이 문제를 해결할 수 있습니다.

• AOF 파일의 백업 사본을 만드십시오.

• redis-check-aof Redis와 함께 제공 되는 도구를 사용하여 원본 파일을 수정하십시오 .

  $ redis-check-aof --fix

• 선택적으로 diff -u 두 파일의 차이점을 확인하는 데 사용 합니다.

• 고정 파일로 서버를 다시 시작하십시오.

작동 원리

로그 재 작성은 스냅 샷 작성에 이미 사용중인 것과 동일한 쓰기 복사 트릭을 사용합니다. 이것이 작동하는 방법입니다.

• Redis forks , 이제 우리에게는 자식과 부모 프로세스가 있습니다.

• 새 AOF를 임시 파일에 작성하기 시작합니다.

• 부모는 모든 새로운 변경 사항을 메모리상의 버퍼에 축적합니다 (그러나 이전의 추가 전용 파일에 새로운 변경 사항을 기록하므로 다시 쓰기가 실패하면 안전합니다).

• 자식이 파일을 다시 작성하면 부모는 신호를 받고 자식이 생성 한 파일의 끝에 메모리 내부 버퍼를 추가합니다.

• 이익! 이제 Redis는 이전 파일을 새로운 파일로 원자 적으로 이름을 변경하고 새 파일에 새 데이터를 추가하기 시작합니다.

현재 dump.rdb 스냅 샷을 사용하고 있다면 AOF로 어떻게 전환 할 수 있습니까?

Redis 2.0과 Redis 2.2에서는 다른 절차를 사용합니다. Redis 2.2에서는 더 간단하고 다시 시작할 필요가 없습니다.

Redis> = 2.2

• 최신 dump.rdb 파일을 백업하십시오.
• 이 백업을 안전한 장소로 옮깁니다.
• 다음 두 명령을 실행하십시오.
• redis-cli config set appendonly yes
• redis-cli config set save ""
• 데이터베이스에 포함 된 동일한 수의 키가 데이터베이스에 포함되어 있는지 확인하십시오.
• 쓰기가 추가 전용 파일에 올바르게 추가되는지 확인하십시오.

첫 번째 CONFIG 명령은 추가 전용 파일을 활성화합니다. 이렇게하기 위해 Redis는 초기 덤프를 생성하도록 차단 한 다음 쓰기를 위해 파일을 열어 다음 쓰기 쿼리를 모두 추가하기 시작합니다.

두 번째 CONFIG 명령은 스냅 샷 영속성을 끄는 데 사용됩니다. 두 가지 지속성 메소드를 모두 사용 가능하게하려면이 옵션을 선택하십시오.

중요 : redis.conf를 편집하여 AOF를 켜야합니다. 그렇지 않으면 서버를 다시 시작하면 구성 변경 사항이 손실되고 서버가 이전 구성으로 다시 시작됩니다.

Redis 2.0

• 최신 dump.rdb 파일을 백업하십시오.
• 이 백업을 안전한 장소로 옮깁니다.
• 데이터베이스에 대한 모든 쓰기를 중지하십시오!
• redis-cli bgrewriteaof를 발행하십시오. 그러면 추가 전용 파일이 생성됩니다.
• Redis가 AOF 덤프 생성을 완료하면 서버를 중지하십시오.
• redis.conf 끝을 편집하여 파일 지속성 만 추가합니다.
• 서버를 다시 시작하십시오.
• 데이터베이스에 포함 된 동일한 수의 키가 데이터베이스에 포함되어 있는지 확인하십시오.
• 쓰기가 추가 전용 파일에 올바르게 추가되는지 확인하십시오.

AOF와 RDB 지속성 사이의 상호 작용

Redis> = 2.4는 RDB 스냅 샷 작업이 이미 진행 중일 때 AOF 재 작성을 트리거하거나 AOF 재 작성이 진행되는 동안 BGSAVE를 허용하지 않도록합니다. 이렇게하면 두 개의 Redis 백그라운드 프로세스가 동시에 많은 양의 디스크 I / O를 수행하는 것을 방지 할 수 있습니다.

스냅 샷이 진행 중이고 사용자가 BGREWRITEAOF를 사용하여 로그 다시 쓰기 작업을 명시 적으로 요청하면 서버는 작업이 예약되었음을 알리는 OK 상태 코드로 응답하고 스냅 샷이 완료되면 다시 쓰기가 시작됩니다.

이 경우 AOF 및 RDB 지속성이 모두 활성화되고 Redis가 다시 시작되면 AOF 파일이 가장 완벽하게 보장되므로 원본 데이터 집합을 재구성하는 데 사용됩니다.

Redis 데이터 백업

이 섹션을 시작하기 전에 다음 문장을 읽으 십시오 . 데이터베이스 백업을 확인하십시오 . 디스크 끊김, 클라우드의 인스턴스 사라짐 등 : 백업이 없으면 / dev / null로 데이터가 사라지는 위험이 커집니다.

Redis는 데이터베이스가 실행되는 동안 RDB 파일을 복사 할 수 있기 때문에 매우 데이터 백업입니다. RDB는 생성 된 후에는 결코 수정되지 않으며, 생성되는 동안 임시 이름을 사용하고 이름 바꾸기 (2)를 사용하여 최종 대상으로 원자 적으로 이름이 변경됩니다 새 스냅 샷이 완료되면

이는 서버가 실행 중일 때 RDB 파일을 복사하는 것이 완전히 안전함을 의미합니다. 이것이 우리가 제안하는 것입니다.

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

재해 복구

Redis의 맥락에서 재난 복구는 기본적으로 백업과 동일한 스토리이며 여러 다른 외부 데이터 센터에서 백업을 전송하는 기능입니다. 이렇게하면 Redis가 실행중인 주요 데이터 센터에 영향을 미치고 스냅 샷을 생성하는 치명적인 이벤트가 발생하더라도 데이터가 안전하게 보호됩니다.

많은 Redis 사용자가 시작 화면에 있기 때문에 쓸 돈이별로 없기 때문에 비용이 너무 많이 들지 않는 가장 재난 복구 기술을 검토하게됩니다.

• Amazon S3 및 기타 유사한 서비스는 재해 복구 시스템을 설치하는 좋은 방법입니다. 일일 또는 시간별 RDB 스냅 샷을 암호화 된 형식으로 S3에 전송하면됩니다. gpg -c대칭 암호화 모드에서 데이터를 암호화 할 수 있습니다 . 많은 다른 안전한 장소에 암호를 저장하십시오 (예 : 조직의 가장 중요한 사람들에게 사본을 제공하십시오). 향상된 데이터 안전성을 위해 여러 스토리지 서비스를 사용하는 것이 좋습니다.
• SCP (SSH의 일부)를 사용하여 멀리있는 서버로 스냅 샷을 전송하십시오. 이것은 매우 간단하고 안전한 경로입니다. 아주 먼 곳에 작은 VPS를 설치하고, ssh를 설치하고, passphrase없이 ssh 클라이언트 키를 생성 한 다음 작은 VPS의 authorized_keys 파일에 추가하십시오. 자동화 된 방식으로 백업을 전송할 준비가되었습니다. 최상의 결과를 얻으려면 2 개의 다른 제공 업체에서 2 개 이상의 VPS를 확보하십시오.

올바른 방식으로 코딩되지 않으면이 시스템이 쉽게 실패 할 수 있음을 이해하는 것이 중요합니다. 적어도 전송이 완료된 후에는 VPS를 사용하는 경우 파일 크기 (복사 한 파일 중 하나와 일치해야 함)와 가능하면 SHA1 다이제스트를 확인할 수 있어야합니다.

또한 어떤 이유로 든 새로운 백업의 전송이 작동하지 않는 경우 일종의 독립 경고 시스템이 필요합니다.