Redis 재시작 때 최근 쓰기가 일부 사라져 지속성 설정을 바꾸려 합니다. RDB와 AOF는 유실 범위·복구 시간·디스크 비용을 어떻게 바꾸나요?

RDB는 특정 시점의 메모리 상태를 스냅샷 파일로 저장하고, AOF는 쓰기 명령을 기록해 재시작 때 재생하는 방식입니다. RDB만 사용하면 마지막 스냅샷 이후 쓰기를 잃을 수 있습니다. AOF도 fsync 정책에 따라 디스크로 내구화되지 않은 최근 명령의 유실 범위가 달라지므로 AOF라고 무손실인 것은 아닙니다. 선택은 허용 가능한 RPO, 복구 시간, 디스크·CPU·메모리 예산으로 결정하겠습니다.

RDB와 AOF의 실패 지점을 비교합니다

RDB는 상태를 비교적 간결하게 저장해 백업·전송·복구가 단순하고 재생 시간이 예측 가능할 수 있지만 스냅샷 사이의 변경을 표현하지 않습니다. AOF는 더 촘촘한 기록 지점을 제공할 수 있으나 로그가 커지고 rewrite가 필요합니다. rewrite는 누적 명령을 현재 상태에 가까운 짧은 형식으로 정리하는 과정이지 장애 직전 모든 쓰기의 내구성을 자동으로 높이는 작업은 아닙니다. 마지막 AOF 부분 손상, rewrite 중 중단, 저장장치 오류에서 어떤 범위까지 복구할 수 있는지 설정·버전별로 확인합니다.

백그라운드 fork 기반 RDB 저장·AOF rewrite 동안 부모가 쓰기를 계속하면 copy-on-write 페이지가 늘어 메모리 피크가 생길 수 있습니다. rewrite의 디스크 I/O와 명령 처리 지연도 봅니다. Redis의 appendfsync와 운영체제·저장장치 flush 계약은 관계형 DB의 WAL 설정과 같은 단어로 단순 비교할 수 없습니다. 복제본이 있어도 잘못된 DEL이나 논리 오류를 그대로 복제하므로 독립 백업을 대체하지 않습니다.

지속성 설정을 재시작 시험으로 검증합니다

RDB와 AOF를 함께 켜는 경우 실제 재시작 시 어떤 파일·형식이 선택되는지 운영 버전의 문서와 로그로 확인하겠습니다. AOF rewrite 중 쓰인 명령이 새 파일·증분 버퍼에 어떤 순서로 포함되는지, 재시작 중 손상된 끝부분을 수리할 때 유실 범위가 서비스 RPO 안인지 시험합니다. fsync always, everysec, no 등의 차이는 지연과 유실 가능성을 바꾸므로 숫자 이름만으로 판단하지 않겠습니다.

테스트는 쓰기 부하 중 강제 중단, 저장 직후 장애, rewrite 중 장애, 디스크 여유 부족, replica 승격을 재현합니다. 복구 후 키 수·값·TTL·최근 요청 ID를 비교하고, 백업에서 별도 복원되는지도 확인합니다. 캐시라면 일부 유실을 허용할 수 있지만 계정 잔액·처리 상태의 권위 저장소라면 Redis 지속성만으로 충분한지 다시 검토합니다. 결론은 RDB의 간격, AOF의 flush·rewrite, 복제와 독립 백업을 서로 다른 보장으로 보고 실제 장애에서 허용 손실과 복구 시간을 확인하는 것입니다.

지속성 파일이 생성됐다는 사실도 백업 성공과 다릅니다. 파일을 다른 장애 도메인으로 복사하고 복구 가능한지 정기적으로 열어 보며, RDB·AOF의 보존 기간과 디스크 여유를 관리하겠습니다. 캐시 데이터라면 재생성 시간을 RTO에 포함하고, 권위 데이터라면 Redis 단독 지속성의 한계를 넘어 DB·원장·대사 경로를 검토합니다. fork 기반 저장이나 rewrite 중 쓰기가 겹치는 순간의 메모리 피크를 정상 평균으로 축소하지 않고 최대 쓰기율에서 시험하겠습니다.