Redis 백업과 장애 복구

Redis가 의도치 않게 종료되거나 큰 오류가 생겼을 경우 레디스 안에 데이터들은 휘발되어버린다.
그런 불상사를 최대한 막기 위하여 Redis를 백업 시키는 방법이 두개 존재한다.

RDB(Redis Database)를 사용한 백업

• 특정 시점의 스냅샷으로 데이터를 저장
  • 스냅샷 주기는 설정 가능
  • 재시작시 RDB 파일이 있으면 읽어서 복구
    

RDB 사용의 장점

• AOF에 비해 작은 파일 사이즈로 백업 파일 관리가 용이
  • aws와 같은 원격지에 백업이 가능, 스냅샷이 찍힌 시간 별로 따로 저장해서 버전 관리가 가능
• fork(child process)를 이용해 백업하므로 서비스 중인 프로세스는 성능에 영향 없음
• 데이터 스냅샷 방식이므로 빠른 복구가 가능

RDB 사용의 단점

• 스냅샷을 저장하는 시점 사이의 데이터 변경사항은 유실될 수 있음
  • 1분마다 스냅샷을 저장해도 마지막 저장 이후에 데이터는 복구할 수 없음
• fork를 이용하기 때문에 시간이 오래 걸릴 수 있고, CPU와 메모리 자원을 많이 소모
• 데이터 무결성이나 정합성에 대한 요구가 크지 않은 경우 사용 가능
• 백업 시 에러 발생 등의 문제
  • 백업 파일을 업로드 할 때도 redis에 문제가 생기면 마지막 백업 파일마저 오염

RDB 설정

• 설정파일이 없어도 기본값으로 RDB를 활성화되어 있음
• 설정 파일 만드려면 템플릿을 받아서 사용 설정파일 링크

저장 주기 설정(Ex: 60초마다 10개 이상의 변경이 있을 때 수행

save 60 10

스냅샷을 저장할 파일 이름

dbfilename dump.rdb

수동으로 스냅샷 저장

bgsave

Docker를 사용해 Redis 설정 파일 적용

• docker run 사용 시 -v 옵션을 이용해 디렉토리 또는 파일을 마운팅할 수 있음

• redis 이미지 실행 시 redis-server에 직접 redis 설정파일 경로 지정 가능

---

AOF(Append Only File)를 사용한 백업

• 모든 쓰기 요청에 대한 로그를 저장
• 재시작 시 AOF에 기록된 모든 동작을 재수행해서 데이터를 복구

AOF 사용의 장점

• 모든 변경사항이 기록되므로 RDB 방식 대비 안정적으로 데이터 백업 가능
• AOF 파일은 append-only 방식이므로 백업 파일이 손상될 위험이 적음
• 실제 수행된 명령어가 저장되어 있으므로 사람이 보고 이해할 수 있고 수정 가능
  • 만약 flushAll 같은 명령어가 잘못 입력되어도 파일에서 수정이 가능
    

AOF 사용의 단점

• RDB 방식보다 파일 사이즈가 커짐
• RDB 방식 대비 백업&복구 속도가 느림(백업 성능은 fsync 정책에 따라 조절가능)

AOF 설정

• AOF 사용(기본값은 no)

  appendonly yes

• AOF 사용(기본값은 no)

  appendfilename appendonly.aof

• fsync 정책 설정(always, everysec, no)

  appendfsync everysec

fsync 정책(appendfsync 설정 값)

• fsync() 호출은 OS에게 데이터를 디스크에 쓰도록 함
• 가능한 옵션과 설명
  • always: 새로운 커맨드가 추가될 때마다 수행. 가장 안전하지만 가장 느림.
  • everysec: 1초마다 수행. 성능은 RDB 수준에 근접.
  • no: OS에 맡김. 가장 빠르지만 덜 안전한 방법. (커널마다 수행 시간이 다를 수 있음)

AOF 관련 개념

• Log rewriting: 최종 상태를 만들기 위한 최소한의 로그만 남기기 위해 일부를 새로 씀
  • 1개의 key값을 100번 수정해도 최종 상태는 1개이므로 SET 1개로 대체 가능
• Multi Part AOF: Redis 7.0부터 AOF가 단일 파일에 저장되지 않고 여러 개가 사용됨
  • base file: 마지막 rewrite 시의 스냅샷을 저장
  • incremental file: 마지막으로 base file이 생성된 이후의 변경사항이 쌓임
  • manifest file: 파일들을 관리하기 위한 메타 데이터를 저장

적용

양식

docker run -v {경로} --name {name} redis redis-server /redis.conf

예제

docker run -v C:\Users\Desktop\soloproject\redis.conf:/redis.conf --name redis-cherhy -d -p 5000:6379 redis redis-server /redis.conf

---

Redis 복제

장점

• 백업 파일이 복구 도중 잘못되거나, 복구중일 경우 레디스 서버를 사용하지 못한다는 단점을 보완
  • redis 서버를 복제하면 메인 서버가 오류가 나도 복제가 된 서브 서버와 바꿔치기만 하면 바로 서버를 이용할 수 있음

※복제를 할 땐 항상 master(main) redis에 RDB파일이나 AOF파일로 백업을 해놓아야한다!!!!

복제

저는 docker-compose.yml 파일로 복제를 적용해보겠습니다.

bitnami/redis를 사용 (다양한 환경에서 설정이 용이)

docker pull bitnami/redis

compose파일 실행

docker-compose up --build

복제는 수동으로 실행해줘야하는데 그런 불편함을 redis-sentinel을 사용하여 자동으로 복제

Redis Sentinel

• redis에서 HA(high availability)를 제공하기 위한 장치
• master-replica 구조에서 master가 다운 시 replica를 master로 승격시키는 auto-failover를 수행
• sentinel의 기능
  • 모니터링
  • 알림
  • 자동 장애 복구
  • 환경 설정 제공자

Redis Sentinel의 실제 구성도

• Sentinel 노드는 3개 이상으로구성 (Quorum때문)
  • Quorum : 센티널이 네트워크적인 오류와 같이 센티넬의 부재가 생겼을 경우 master 노드를 교체 하지 않고 방치 할 수 있고 반대로 오작동을 하여 이상이 없을 때 교체를 할 수도 있기 때문
  • 센티널들은 과반수 이상이 master 노드가 다운되었다고 판단하면 Replica 노드와 변경
• Sentinel들은 서로 연결되어있음
• Sentinel들은 Redis master와 replica를 모니터링
• Client는 Sentinel을 통해 Redis에 접근
  • Client는 redis의 주소, redis container의 주소가 아닌 센티넬의 주소로 접근

Redis Sentinel 특징

• SDOWN(Subjective down)과 ODOWN(Objective down)의 2가지 판단이 있음
  • SDOWN: Sentinel 1대가 down으로 판단(주관적)
  • ODOWN: 정족수가 충족되어 down으로 판단(객관적)
• master 노드가 down된걸로 판단되기 위해서는 Sentinel 노드들이 정족수(Quorum)을 충족해야 함
• 클라이언트는 Sentinel을 통해 master의 주소를 얻어내야 함

출처 : fastcampus