레디스 데이터 백업 방식

 

❐ Description

---

redis를 캐시가 아닌 영구 저장소와 같은 용도로 사용한다면, 데이터를 디스크에 주기적으로

백업하는 것이 안전하다. 데이터를 안전하게 저장하기 위해 Redis에서는 RDB와 AOF 두 가지

백업 방식을 지원한다. 오늘은 각 백업 방식의 특징과 차이점을 학습해보자.

 

 

 

 

 

❐ RDB

---

1. RDB란?

RDB 파일은 레디스에서 데이터를 백업하기 위한 가장 단순한 방법이다.

• 원하는 시점에 메모리  자체를 스냅숏 찍듯 저장할 수 있다.
• 바이너리 파일이다.
• AOF 파일보다 사이즈가 작아서, 로딩 속도가 더 빠르다.

 

2. 저장 시점 정하기

save 900 1           #900초(15분) 동안 1번 이상 key 변경이 발생하면 저장
save 300 10         #300초(5분) 동안 10번 이상 key 변경이 발생하면 저장
save 60 10000    #60초(1분) 동안 10000번 이상 key 변경이 발생하면 저장

• SAVE 조건은 여러 개를 지정할 수 있고, 모두 or 조건이다. 즉 어느 것 하나라도 만족하면 저장한다.
• RDB를 저장하지 않으려면 redis.conf 에서 SAVE를 모두 주석 처리하면 된다

 

3. 저장하는 두 가지 방법 

RDB 저장 방식에는 SAVE와 BGSAVE 두 가지 방식이 있다.

 

🧩 SAVE ⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯

Blocking 방식으로, RDB를 저장하는 동안 다른 클라이언트의 요청을 처리하지 못함.

 

🧩 BGSAVE ⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯

Non-Blocking 방식으로, 백그라운드에서 RDB를 저장하는 방식.

 

 

4. 문제점 

하지만 장애가 발생했을 때 손실 가능성을 최소화해야 하는 서비스에는 RDB 파일을 이용한

백업만 사용하는 것은 적절하지 않다. 사용자가 지정한 시간 단위로 파일이 저장되기 때문에

저장 시점부터 장애가 발생한 직전까지의 데이터는 손실될 수 있다.

 

 

 

 

 

❐ AOF

---

1. AOF란?

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

이 처럼 operation이 발생할때 마다 매번 기록되기 때문에, RDB 방식과는 달리 특정 시점이

아니라 항상 현재 시점까지의 로그를 기록할수 있으면 기본적으로 Non-blocking 방식으로

통작한다. 

 

 

2. 파일을 수정할 수 있다.

AOF는 레디스 프로토콜(RESP) 형태로 저장되기 때문에 파일 수정이 가능하다.

Text 형식으로 저장된다.

따라서 실수로 flushall을 했더라도, 파일을 수정하여 flushall을 지우면 이전 데이터를 복구할 수 있다.

 

 

3. 재구성하기

AOF는 모든 쓰기 연산이 기록된다고 했다. 즉, 모든 시간이 지남에 따라 파일의 크기가 커지게 된다.

AOF 파일을 이용한 백업 기능을 안정적으로 사용하려면 점점 커지는 파일을 주기적으로 압축시키는

재구성(rewirte) 작업이 필요하다. 

 

이때 압축, 즉 재구성은 기존 디스크에 저장됐던 AOF 파일을 사용하는 것이 아니라 레디스 메모리에

있는 데이터를 읽어와서 새로운 파일로 저장하는 형태로 동작한다.

 

🧩 ver.7 이전 ⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯

버전 7 이전까지 AOF는 하나의 파일로 관리됐다. 

파일의 앞부분은 고정영역이고 뒷 부분은 증분영역

고정역역은 RDB 스냅샷을 바이너리 형식으로 저장하는 곳으로 데이터의 초기 상태(기본값)를 기록한다.

증분영역은 이후의 변경 사항을 RESP 프로토콜 형식으로 기록하는 곳으로 RDB 이후 추가된 명령어

로그들이 쌓이다.

 

즉, 하나의 파일 내에서 고정 영역과 증분 영역이 논리적으로 구분되지만, 물리적으로는 하나의 파일로 관리된다.

 

 

🧩 ver.7 이후 ⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯

버전 7 이후부터는 파일이 물리적으로 고정 영역과 증분 영역으로 분리되었다.

 

고정영역의 파일 명은 기본으로 `appendonly.aof.1.base.rdb` 이다. 

증분 영역의 파일 명은 기본으로 `appendonly.aof.1.incr.aof` 이다.

 

그리고 manifest 파일이 추가되었다.

manifest는파일 메타정보를 관리하여 고정 영역과 증분 영역의 관계를 정의한다. 

또한 순서, 타입, 파일명을 관리해 파일을 조합하여 재구성할 수 있도록 해준다.

 

 

4.  자동 재구성하기 설정 

# AOF 파일 사이즈가 특정 퍼센트 이상 커지면 rewrite 한다.
# 비교 기준은 레디스 서버가 시작할 시점의 AOF파일 사이즈이다.
# 0으로 설정하면 rewrite를 하지 않는다
auto-aof-rewrite-percentage 100

# AOF 파일 사이즈가 64mb 이하면 rewrite를 하지 않는다.
auto-aof-rewrite-min-size 64mb

`min-size`를 설정해주지 않으면, 파일이 작을 때 불필요한 rewirte가 자주 발생하기 때문에

설정해주는 것이 좋다.

 

 

4. 문제점 

AOF는 모든 쓰기 연산을 기록하기 때문엔 데이터 유실 문제에 비교적 안전하다. 

따라서 AOF만 쓰는것이 좋을 수도 있겠지만, 다음의 경우를 생각해보자.

 

⛔️ 0부터 50까지 1씩 증가 ⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯

최종적으로 저장된 데이터 50을 만들기 위해서 불가피하게 50번의 연산이 필요하다.

RDB를 하면 한 번에 50을 저장할 수 있는데 말이다. 

 

 

 

 

 

❐ 어떤 방식을 사용해야 할까?

---

위에서 각 방식의 문제점을 확인하였다. 각 문제점을 보완하는 방법은 두 가지를 혼용해서 사용하는 것이다.

물론 Redis를 단순 캐시의 역할로만 사용한다면 백업 정책은 필요하지 않을 것으로 생각된다.

 

# RDB 저장 시점 설정
save 900 1
save 300 10
save 60 10000
dir /data

# AOF 활성화
appendonly yes

위와 같이 AOF와 RDB를 혼용해서 사용하면 서로의 문제점을 보완하며 안정적이고 고가용성의

레디스 서버를 운영할 수 있을 것 같다.

 

 

 

 

 

---