https://redis.io/docs/management/persistence/
RDB(Redis Database)를 활용한 백업
- 특정 시점의 스냅샷으로 데이터 자체를 저장한다.
- 재시작 시 RDB 파일이 있으면 읽어서 복구
장점
- 메모리 상태를 그대로 스냅샷으로 저장하기 때문에 AOF대비 작은 파일 사이즈
- SAVE 백업 시 Redis의 Single Thread를 활용하여 백업 하기 때문에 실제 서비스에 성능에 영향이 가해질 수 있음.
- 따라서 일반적으로는 BGSAVE를 활용.
- BGSAVE 백업 시 fork를 이용해 백업하므로 서비스 중인 프로세스는 성능에 영향 없음.
💡 단, fork로 백업을 위한 프로세스를 생성하면서 메모리 사용량이 2배까지 증가할 수 있고 장애 발생의 요인이 될 수 있음. (기본적으로 fork 프로세스는 부모 프로세스와 비교하여 달라지는 페이지만 copy on write를 수행함. 하지만 redis에 write가 많아 페이지가 모두 변한 경우 2배까지 증가할 수 있음.)
단점
- 스냅샷을 저장하는 시점 사이의 데이터 변경사항은 유실될 수 있음
- fork를 이용하기 때문에 시간이 오래 걸릴 수 있고, CPU와 메모리 자원을 많이 소모
- 데이터 무결성이나 정합성에 대한 요구가 크지 않은 경우 사용 가능(마지막 백업 시 에러 발생하면 이 경우 백업이 불가능.)
RDB설정
AOF(Append Only File)를 사용한 백업
- 모든 쓰기 요청에 대한 로그를 저장
- 재시작 시 AOF에 기록된 모든 동작을 재수행해서 데이터를 복구
AOF 백업 상세 사항.
- fsync 정책 설정
- AOF파일 내용을 언제 디스크에 쓸지
- always: 항상 바로 디스크에 저장, 안정성은 뛰어나지만 성능이 떨어짐.
- everysec: 1초마다
- no: OS에게 맡김, 가장 성능이 뛰어나지만 안정성이 가장 떨어짐, 커널마다 수행시간이 다를 수 있음.
- Log rewriting: 최종 상태를 만들기 위해 커맨드 로그를 최소화함.
- 예를들어 특정 key를 100번 수정하는 내용이 있다고 했을 때 최종 한번의 set만 수행해도 되므로 1개의 커맨드로 줄일 수 있음.
- Multi Part AOF: Redis 7.0부터 AOF가 단일 파일에 저장되지 않고 여러 개가 사용됨.
- base file: 마지막 rewrite시의 스냅샷을 저장.
- incremental file: 마지막으로 rewrite로 base file을 생성하고 나서의 변경사항이 쌓임.
- manifest file: 파일들을 관리하기 위한 메타 데이터를 저장.
장점
- 모든 변경 사항이 기록되므로 RDB 백업 간격으로 인한 유실이 없음.
- 백업 파일이 손상될 여지가 적음.
- 실제 수행된 명령어가 저장되어 있으므로 사람이 보고 이해할 수 있고 수정할 수 있음.
단점
- 모든 명령어를 실행해야하기 때문에 백업, 복구 속도가 느림(백업 성능은 fsync 정책에 따라 조절 가능)
- 복구 파일도 RDB보다 큼.
AOF 설정
- default 로 비활성화
- appendonly yes 로 활성화 시켜야함.
- AOF파일 이름
- appendfilename appendonly.aof
AOF vs RDB 어떤걸 선택해야할까
- RDB의 경우 완벽하게 백업되기 힘들기 때문에 유실되면 안되는 경우에는 사용하기 힘들다. 이런 경우에는 AOF를 fsync everysec 혹은 always로 설정하여 활용하는 것이 좋다.
- 반면 Caching으로 Redis를 사용하는 경우에는 유실 되어도 상관없으므로 RDB만을 사용하거나 아예 백업을 하지않을 수도 있다.
- 일반적으로는 RDB, AOF를 사용 목적에 맞게 적절히 설정하여 둘 다 사용한다.
- 주기적으로 RDB의 백업을 활용하고 스냅샷 사이에서 백업이 안되는 부분은 AOF를 활용하여 백업하는 것이 좋음.