[Redis]레디스 데이터 백업 방법

Jeongyeon Kim·2024년 3월 4일

nosql redis 개발자를 위한 레디스

Redis

목록 보기

6/7

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

레디스에서 모든 데이터는 메모리에서 관리된다. 메모리에 있던 모든 데이터는 손실될 가능성이 있다.
따라서 레디스를 영구 저장소와 같은 용도로 사용한다면 디스크에 데이터를 주기적으로 백업하는 것이 필요하다.

복제와 백업의 차이

복제: 가용성을 위한 것

백업: 장애 상황에서 데이터의 복구를 위한 것

레디스 백업 방식

AOF(Append Only File): 레디스 인스턴스가 처리한 모든 쓰기 작업을 차례대로 기록. 복원 시에는 파일을 다시 읽어가며 데이터 세트 재구성

RDB(Redis DataBase): 일정 시점에 메모리에 저장된 데이터 전체를 저장(snapshot 방식)

AOF

레디스 프로토콜(RESP) 형태로 저장됨
레디스에서 실행된 모든 쓰기 작업이 기록됨
RDB 파일보다 크기가 크고 주기적으로 압축해 재작성해야 하지만, 원하는 시점으로 복구 가능

RDB

바이너리 형태로 저장
저장되는 시점의 메모리 데이터가 그대로 저장됨
시점 단위로 여러 백업본을 저장할 수 있고, AOF 파일보다 복원이 빠르다는 장점이 있지만 특정 시점으로의 복구는 불가능

레디스에서 데이터를 복원할 수 있는 시점은 서버가 재시작될 때뿐!!
레디스 인스턴스 실행 도중에 데이터 파일을 익어올 수 있는 방법은 없음

2. RDB 방식의 데이터 백업

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

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

레디스 설정 파일에서 save 옵션을 사용해 원하는 조건에 RDB 파일을 저장하도록 설정
일정한 기간(초) 동안 변경된 키의 개수가 조건에 맞을 때 레디스 서버는 자동으로 RDB 파일 저장
RBD 파일을 저장하고 싶지 않다면 save ""로 설정해 옵션 비활성화
CONFIG SET: 실행 중인 레디스 인스턴스에서 설정 변경
CONFIG REWRITE: 설정 파일 재작성
레디스 인스턴스가 실행 중인 상태에서 설정 파일을 변경하는 것은 실행 중인 레디스 인스턴스에는 반영되지 않음
- CONFIG SET(설정 변경) -> CONFIG REWRITE(설정 파일 재작성) 과정을 거쳐야 함

수동으로 RBD 파일 생성

SAVE: 동기 방식으로 파일 저장
BGSAVE: fork를 호출해 자식 프로세스를 생성하며 생성된 자식 프로세스가 백그라운드에서 RDB 파일을 생성한 뒤 종료
- 이미 백그라운드로 데이터가 저장되고 있을 때 이 커맨드를 수행하면 에러 반환
- SCHEDULE 옵션: 이미 파일이 백그라운드에서 저장 중일 때 이 커맨드를 입력받은 레디스는 일단 OK 반환한 뒤, 기존에 진행 중이던 백업이 완료됐을 때 다시 BGSAVE 실행
LASTSAVE: RDB 파일이 정상적으로 저장됐는지 확인, 마지막으로 RDB 파일이 저장된 시점을 유닉스 타임스탬프로 반환

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

REPLICAOF: 복제본에서 이 커맨드를 이용해 복제를 요청하면 마스터 노드에서는 RDB 파일을 새로 생성해 복제본에 전달
복제 연결을 처음 시작했을 때뿐만 아니라 이미 복제 연결이 되어 있는 상태에서도 상황에 따라 마스터에서는 언제든지 RDB 파일을 재생성할 수 있음

3. AOF 방식의 데이터 백업

AOF는 레디스 인스턴스에서 수행된 모든 쓰기 작업의 로그를 차례대로 기록

appendonly yes	// AOF 파일에 주기적으로 데이터 저장
appendfilename "appendonly.aof"
appenddirname "appendonlydir"

AOF 파일에는 메모리상의 데이터가 변경되는 커맨드만 기록됨
항상 AOF 파일이 사용자가 실행한 커맨드를 그대로 저장하는 것은 아님
- BRPOP -> RPOP
- INCRBYFLOAT -> 증분 후의 값을 직접 SET
AOF는 실행되는 커맨드가 파일 뒤쪽에 계속 추가되는 방식으로 동작하기 때문에 인스턴스가 실행되는 시간에 비례해서 파일 크기 계속 증가

AOF 파일을 재구성하는 방법

AOF 파일을 이용한 백업 기능을 안정적으로 사용하려면 점점 커지는 파일을 주기적으로 압축시키는 재구성(rewrite) 작업 필요
재구성은 레디스 메모리에 있는 데이터를 읽어와서 새로운 파일로 저장하는 형태로 동작
aof-use-rdb-preamble yes -> RDB 파일 형태로 저장
AOF 파일을 재구성할 때에도 fork를 이용해 자식 프로세스를 생성하며, 이 자식 프로세스가 AOF 파일을 재구성해 저장
버전 7 이전
- AOF는 하나의 파일로 관리
- RDB 파일이 저장되는 동안 데이터가 변경된 동일한 로그가 AOF와 인메모리 버퍼에 이중으로 저장됨
- 하나의 AOF 파일 내에 바이너리 형태와 RESP의 텍스트 형태의 데이터가 함께 저장돼 수동으로 AOF 파일을 처리할 때 관리 복잡
버전 7 이후
- AOF는 기본이 되는 바이너리 형태의 RDB 파일, 증가하는 RESP의 텍스트 형태의 AOF 파일로 나누어 데이터 관리
- 현재 레디스가 바라보고 있는 파일이 어떤 것인지 나타내는 매니페스트 파일
AOF 파일 재구성 과정은 모두 순차 입출력만 사용하기 때문에 디스크에 접근하는 모든 과정이 효율적
- 파일 내에서 직접 데이터를 검색할 필요가 없기 때문에 랜덤 입출력을 고려할 이유 없음

자동 AOF 재구성

auto-aof-rewrite-percentage: AOF 파일을 다시 쓰기 위한 시점을 정하기 위한 옵션
auto-aof-rewrite-min-size: 재구성된 이후의 AOF 파일의 최소 크기 지정 옵션
마지막으로 작성된 AOF 파일 크기를 기준으로 재구성하되, 적어도 AOF 파일이 특정 크기 이상일 때에만 재구성을 하도록 지정해 비효율적인 작업을 최소화

수동 AOF 재구성

BGREWRITEAOF: 원하는 시점에 직접 AOF 파일 재구성. 자동으로 재구성할 때와 동일하게 동작

AOF 타임스탬프

aof-timestamp-enabled 옵션을 활성화 시키면 AOF 데이터가 저장될 때 타임스탬프도 함께 저장됨
redis-check-aof 프로그램을 사용해 데이터 복구

AOF 파일 복원

redis-check-aof 프로그램은 AOF 파일이 손생됐을 때도 사용 가능
의도치 않은 서버의 장애 발생 시 AOF 파일 작성 도중 레디스가 중지됐을 가능성 존재

AOF 파일의 안전성

파일 저장 내구성 제어 옵션
- APPENDFSYNC no: AOF 데이터를 저장할 때 WRITE 시스템 콜 호출. 데이터는 커널 영역에 데이터가 잘 저장되는지만 확인하기 때문에 쓰기 성능 가장 빠름
- APPENDFSYNC always: AOF 데이터를 저장할 때 항상 WRITE와 FSYNC 시스템 콜 함께 호출. 매번 쓰고자 하는 데이터가 파일에 정확하게 저장되는 것을 기다리기 때문에 쓰기 성능 가장 느림
- APPENDFSYNC everysec: 데이터를 저장할 때 WRITE 시스템 콜을 호출하며, 1초에 한번씩 FSYNC 시스템 콜을 호출. 성능은 no 옵션을 사용했을 때와 거의 비슷

4. 백업을 사용할 때 주의할 점

인스턴스의 maxmemory 값은 실제 서버 메모리보다 여유를 갖고 설정하는 것이 좋음
레디스는 Copy-On-Write(COW) 방식을 이용해 메모리상의 데이터를 하나 더 복사하는 방법을 이용해 백업을 진행하면서도 클라이언트의 요청 사항을 받아 메모리의 데이터를 읽고 수정하는 작업 진행
maxmemory 값을 너무 크게 설정한 경우(최악의 경우 기존 메모리 용량의 2배 사용), 레디스의 copy-on-write 동작으로 인해 OS 메모리가 가득차 OOM(Out Of Memory) 문제로 서버가 다운될 수 있음
RDB 스냅샷을 저장하는 도중엔 AOF의 재구성 기능을 사용할 수 없고, AOF 재구성이 진행될 때에는 BGSAVE를 실행할 수 없음