본문 바로가기
🛠 백엔드/데이터베이스

[DB] Redis에서의 Persistence

by meteorfish 2025. 2. 13.
728x90

Redis Database (Snapshotting)

주기적으로 RDB의 스냅샷을 만들고 백업하여 필요 시 롤백하는 방식

장점

  1. 장애 복구 탁월
  2. 단일 파일로 파일 전송이 쉬움
  3. AOF보다 빠른 재시작 가능

단점

  1. 스냅샷 사이의 텀 발생 시, 데이터 유실 가능
  2. 자식 프로세스를 통해 디스크에 스냅샷을 지속시킨다. 데이터 셋이 큰 경우 fork()가 오래 걸리기에 CPU 성능에 좋지 않음 (AOF는 fork()를 덜 자주 실행함)

AOF (Append Only File)

트랜잭션 커밋 시 RAM과 redo 로그(Append Only File)에 모두 저장

fsync 정책을 통해 파일과 장치를 동기화한다. 기본적으로 1초마다 fsync를 하고 백그라운드 스레드로 동작한다. 메인 스레드는 fsync가 진행 중이지 않을 때 쓰기 작업을 받으려고 노력함 (100% 아님)

장점

  1. 추가만 가능하기에 데이터 유실에 대응
  2. redis-check-aof-tool을 통해 로그 절반으로도 복구 가능

단점

  1. AOF 파일이 커진다. (RDB 스냅샷 보다 큼)
  2. fsync은 쓰기 부하가 심하기 때문에 정책에 따라 RDB보다 느려질 수 있음

어떤 걸 사용해야 하는가?

혼용하여 사용하면 일반 RDB 수준의 데이터 보안 가능

다만, AOF 엔진 버그의 가능성이 있고, fsync의 성능이 느릴 수 있기에 AOF 단독 사용을 권장하지 않음

기본적으로 RDB만 설정되어 있는 것을 확인할 수 잇음

728x90