Data Backup

레디스는 모든 데이터를 메모리에 저장하므로, 예기치 않은 서버 장애나 재시작 시 데이터가 유실될 수 있어, 영속성을 확보하기 위한 데이터 백업 메커니즘이 필요하다.

RDB(Redis DataBase)

RDB는 특정 시점의 메모리 상태 전체를 하나의 바이너리 파일(dump.rdb)로 저장하는 스냅샷 방식이다.

• 동작 원리

  • BGSAVE 명령어가 실행되면, 레디스는 현재 메인 프로세스를 복제(fork())하여 자식 프로세스를 생성
  • 자식 프로세스가 디스크에 데이터를 쓰는 동안, 부모 프로세스는 다른 클라이언트의 요청을 블로킹(blocking) 없이 계속 처리

• 파일 생성 시점

  1. 자동: redis.conf 파일의 save 옵션에 설정된 조건을 만족할 때
  2. 수동: 관리자가 CLI에서 BGSAVE 명령어를 직접 실행할 때
  3. 복제 시: 슬레이브(Replica) 노드가 마스터(Primary) 노드와 최초 동기화를 시작할 때

• 장점

  • 데이터 전체가 하나의 파일에 담겨있어 파일 크기가 작고 관리 용이
  • 서버 재시작 시 RDB 파일을 읽는 속도가 AOF보다 빨라 대용량 데이터 복원에 유리

• 단점

  • 스냅샷은 특정 시점에만 생성되므로, 마지막 스냅샷 이후 발생한 데이터 변경분은 장애 시 유실 가능

AOF(Append Only File)

AOF는 레디스 서버에서 실행된 모든 쓰기(write) 명령을 로그 파일에 순차적으로 기록하는 방식이다.

• 동작 원리

  • 클라이언트로부터 쓰기 요청이 들어올 때마다 해당 명령어를 AOF 파일의 끝에 추가
  • 서버 재시작 시, 이 파일에 기록된 모든 명령어를 처음부터 순서대로 재실행하여 데이터 복원

• fsync 정책: AOF 파일에 데이터를 쓰는 시점은 appendfsync 옵션으로 조절하며, 이는 데이터 내구성과 성능 간의 트레이드오프를 결정

  • always: 모든 쓰기 명령마다 디스크에 동기화(가장 안전하지만 성능 저하 심함)
  • everysec (기본값): 1초에 한 번씩 백그라운드 스레드에서 디스크 동기화(성능과 안정성 사이의 적절한 균형을 제공하며, 장애 시 최대 1초 분량의 데이터가 유실 가능)
  • no: 디스크 동기화를 운영체제(OS)에 맡김(가장 빠르지만 데이터 유실 위험이 가장 높음)

• AOF 재구성 (Rewrite)

  • AOF 파일은 시간이 지남에 따라 계속 커지므로, BGREWRITEAOF 명령어를 통해 파일 크기를 최적화
  • 해당 과정은 현재 메모리에 있는 데이터를 기반으로 가장 짧은 명령어 조합을 만들어 새로운 AOF 파일을 생성하는 방식(기존 로그 파일을 읽는 것이 아님)

• 장점

  • fsync 정책에 따라 데이터 유실을 최소화할 수 있어 RDB보다 높은 내구성 제공

• 단점

  • 동일한 데이터라도 RDB 파일보다 파일 크기가 더 클 수 있음
  • 서버 재시작 시 모든 명령어를 재실행해야 하므로 RDB보다 복원 속도가 느릴 수 있음

데이터 복원 과정

레디스 서버는 오직 재시작될 때만 데이터를 복원한다.

1. 서버가 시작되면 먼저 AOF 파일(appendonly.aof)의 존재 여부를 확인
2. AOF 파일이 존재하면, 해당 파일을 로드하여 데이터를 복원(AOF 파일이 RDB 파일보다 우선)
3. AOF 파일이 없고 RDB 파일(dump.rdb)만 존재하면, RDB 파일을 로드

권장 구성

데이터의 안정성을 극대화하기 위해 두 가지 방식을 모두 활성화하는 것이 강력하게 권장된다.

• 평상시 내구성: AOF가 데이터의 실시간 변경 사항을 기록하여 데이터 유실 최소화
• 주기적 백업 및 빠른 복원: RDB는 주기적으로 전체 데이터의 스냅샷을 만들어두어, 재해 발생 시 특정 시점으로의 빠른 복구 지원
• 시너지 효과: AOF 재구성 시, 레디스는 가장 최근의 RDB 스냅샷을 활용하여 재구성 속도를 높이고 효율성 극대화

참고자료

• 개발자를 위한 레디스