TIL

7장 레디스 데이터 백업 방법

레디스에서 데이터를 영구 저장하기

• 레디스의 데이터는 메모리에서 관리되기에 서비스 장애로 데이터가 손실될 수 있다.
• 레디스를 캐시가 아닌 영구 저장소와 같은 용도로 사용한다면 주기적인 백업이 필요하다.
  • 레디스는 RDB와 AOF 두 가지 백업 방식을 지원한다.
• AOF(Append Only File) - 레디스 인스턴스가 처리한 모든 쓰기 작업을 차례대로 기록, 복원 시에는 파일을 다시 읽어가며 데이터 세트 재구성
  • AOF 파일은 레디스 프로토콜 형태로 저장
  • 모든 쓰기 작업이 기록되기에 데이터가 변경된 내역도 모두 기록된다.
  • 파일 크기가 RDB보다 크고 주기적으로 압축해 재작성해야 한다.
  • 원하는 시점으로 복구할 수 있다.
• RDB (Redis DataBase) - 일정 시점에 메모리에 저장된 데이터 전체를 저장 (snapshot 방식)
  • RDB 파일은 바이너리 형태로 저장
  • 저장되는 시점의 메모리가 그대로 저장되기에 마지막 결과값만 저장된다.
  • 시점 단위로 백업본을 저장 가능하며 AOF 파일보다 복원이 빠르다.
  • 단 특정 시점으로의 복구는 불가능
• 한 인스턴스에서 RDB와 AOF 옵션을 동시에 사용할 수도 있다.
  • 일반적 RDB만큼의 안정성을 원한다면 둘 다 사용하기를 권장
  • 두 개 다 있다면 레디스는 AOF 데이터를 로드한다.

RDB 방식의 데이터 백업

• RDB 파일은 원하는 시점에 메모리 자체를 스냅숏 찍듯 저장한다.
• 하지만 장애가 발생하면 저장 시점 ~ 장애 발생 시간 사이의 데이터는 손실될 수 있다.
• RDB 파일 생성 방법은 크게 세 가지다.
  • 특정 조건에 자동 RDB 파일 생성
  • 사용자 지정 시점에 커맨드를 이용해 수동으로 RDB 파일 생성
  • 복제 기능으로 자동 RDB 파일 생성

특정 조건에 자동으로 RDB 파일 생성

• save 옵션을 사용해 원하는 조건에 RDB 파일을 저장하도록 설정 가능하다.
  • redis.conf에서 설정 가능

save <기간(초)> <기간 내 변경된 키의 개수> dbfilename <RDB 파일 이름> dir <RDB 파일 저장 경로>

# 900초 간 1개 이상 키가 변경된 경우
save 900 1

# 300초 동안 10개 이상의 키가 변경된 경우
save 300 10

• save “” 옵션으로 RDB 파일을 비활성화할 수 있다.
  • CONFIG SET save “”

CONFIG REWRITE - 레디스 인스턴스 실행 중에 설정 파일을 변경할 수는 없다. 실행 중에 설정을 변경하려면 redis-cli에서 CONFIG SET 커맨드로 설정을 변경한 뒤 CONFIG REWRITE 커맨드로 설정 파일을 재작성해야 한다. 재작성하지 않으면 인스턴스가 재작성 되어도 변경 전 옵션으로 설정된다.

수동으로 RDB 파일 생성

• SAVE, BGSAVE 커맨드로 원하는 시점에 RDB 파일을 생성할 수 있다.
  • SAVE - 동기 방식으로 파일을 저장
  • BGSAVE - 자식 프로세스가 백그라운드에서 RDB 파일을 생성

복제를 사용할 경우 자동으로 RDB 파일 생성

• 복제본에서 REPLICAOF 커맨드를 이용해 마스터 노드에서 RDB 파일을 새로 생성해 복제본에 전달한다.
• 네트워크 등 이슈로 복제가 끊어졌다 복구된 경우에도 마스터 노드는 복제본으로 RDB 파일을 전송한다.

AOF 방식의 데이터 백업

• AOF는 레디스에서 수행된 모든 쓰기 작업 로그를 차례로 기록한다.
  • FLUSHALL 커맨드로 데이터를 모두 날려버려도 AOF 파일에서 FLUSHALL 커맨드만 삭제하면 데이터를 바로 복구 가능
• 설정 파일에서 appendonly 옵션을 yes로 지정하면 AOF 파일에 데이터가 저장된다.
• AOF 파일은 레디스 인스턴스가 실행되는 시간에 비례해서 크기가 증가한다.

AOF 파일을 재구성하는 방법

• AOF 백업을 안정적으로 사용하려면 주기적으로 압축시키는 재구성(rewrite) 작업이 필요하다.
  • 자동 또는 수동으로 할 수 있다.
• 압축, 즉 재구성은 기존 AOF 파일이 아닌 레디스 메모리의 데이터를 새 파일로 저장하는 형태로 동작한다.
  • 설정 파일에서 기본 옵션인 aof-use-rdb-preamble yes를 no로 변경하지 않으면 RDB 파일 형태로 저장한다.
  • 재구성 시에도 자식 프로세스가 백그라운드에서 진행한다.
• AOF 파일 재구성 동작
  1. 레디스 인스턴스가 자식 프로세스를 생성해 메모리의 데이터를 신규 임시 파일에 저장
  2. 백그라운드로 1이 진행되는 동안 변경된 데이터 내역은 신규 AOF 파일에 저장된다.
  3. 1의 AOF 재구성 과정이 끝나면 임시 매니페스트 파일을 생성한 뒤 변경된 버전으로 매니페스트 파일 내용을 업데이트
  4. 임시 매니페스트 파일로 기존 매니페스트 파일을 덮어 씌우고 이전 버전 AOF, RDB 파일을 삭제한다.
• 레디스의 AOF 파일 재구성 과정은 모두 순차 입출력만 사용하기 때문에 디스크 접근 과정이 굉장히 효율적이다.
  • 랜덤 I/O를 고려하지 않는다는 점이 모든 데이터 저장소에서 굉장히 드문 기능이다.

자동 AOF 재구성

• BGREWRITEAOF 커맨드로 원하는 시점에 AOF 파일을 재구성할 수 있다.

AOF 타임스탬프

• AOF를 저장할 때 타임스탬프를 남길 수 있다.
  • aof-timestamp-enabled 옵션 활성화
• 이를 이용하면 시스템상에서 시점 복원이 가능하다.
• 레디스에서 제공하는 redis-check-aof 프로그램을 이용하면 된다.
  • src/redis-check-aof — truncate-to-timestamp 1669532844 appendonlydir/

AOF 파일 복원

• 시점 복원 때 사용한 redis-check-aof 프로그램은 AOF 파일이 손상됐을 때도 사용할 수 있다.
  • AOF 파일의 상태가 정상적인지 확인할 수 있다.
  • src/redis-check-aof —fix appendonlydir/appendonly.aof.manifest

AOF 파일의 안정성

• AOF는 RDB 보다 더 안전한데 얼마나 안전할까?
• 운영체제에서 시스템 콜을 이용해 데이터를 파일에 저장하는 방법
  1. 애플리케이션에서 데이터를 저장하겠다고 WRITE 시스템 콜
  2. 데이터는 커널 영역의 OS 버퍼에 임시 저장
  3. OS는 커널이 여유 있거나 최대 지연 시간 30초에 도달하면 FSYNC 시스템 콜로 버퍼의 데이터를 디스크에 내려 쓴다.
  4. FSYNC - OS에 부하가 있더라도 무조건 디스크에 플러시
• 레디스에서 AOF 파일을 저장할 때 APPENDFSYNC 옵션으로 FSYNC 호출을 제어할 수 있다.
  • no: 데이터 저장 시 WRITE 시스템 콜 호출
    • 커널 영역으로의 저장만 확인하기에 쓰기 성능이 가장 좋음
  • always: 데이터 저장 시 항상 WRITE와 FSYNC를 함께 호출
    • 매번 데이터가 정확하게 저장되는 것을 기다리기에 성능은 가장 느림
  • everysec: 데이터 저장 시 WRITE만 호출하며 1초에 한 번씩 FSYNC 호출
    • 성능은 no와 거의 비슷
    • 기본 옵션으로 권장하는 옵션이다.

백업을 사용할 때 주의할 점

• RDB와 AOF 파일을 사용하는 경우 인스턴스의 maxmoemory 값은 실제 서버 메모리보다 여유를 갖고 설정하는 것이 좋다.
  • 자식 프로세스가 RDB 파일을 저장하거나 AOF 재구성을 진행할 때 최악의 경우 레디스가 기존 메모리 용량의 2배를 사용하게 될 수 있다.
  • maxmemory를 너무 크게 설정하면 OS 메모리가 가득 차는 상황이 발생할 수 있고 Out of Memory로 서버가 다운될 수도 있다.
• 다음 표와 같이 서버의 메모리 유형에 따라 적절한 값을 지정해야 한다.

RAM	Maxmemory	비율
2GB	638MB	33%
4GB	2048MB	50%
8GB	4779MB	58%
16GB	10249MB	63%
32GB	21163MB	65%
64GB	43008MB	66%

• RDB 스냅샷 저장과 AOF 재구성은 동시에 실행할 수 없다.