[redis] data persistence - aof
aof
aof = append only file
rdb snapshot과 달리 모든 쓰기 명령을 로그 파일에 순차적으로 기록하는 방식이다
따라서 서버 재시작시 aof에 적힌 명령들을 그대로 실행함으로서 데이터의 변경을 반영해줄 수 있다
이에 따라 데이터 변경에 따른 누락이 없다
이때 읽기 명령의 경우는 저장하지 않는다
실제로 데이터베이스에 영향을 주는 것은 쓰기 명령이기 때문이다
aof의 동기화 전략
이러한 특성을 바탕으로,
aof는 언제 디스크에 내용을 저장할 것인가에 대한 동기화 전략이 중요하다
운영체제가 성능을 위해 파일에 대한 쓰기를 버퍼링하고,
따라서 운영체제의 메모리 버퍼에 쓴 후 적당한 때에 디스크로 저장한다
즉, 디스크에 저장하기 전에 서버가 다운되는 경우는 마찬가지로 유실이 가능하다
이에 따라 동기화 전략은 밑과 같다
- arrays : 모든 쓰기 명령 시 매번 디스크에 aof를 저장
잃어서는 안되는 데이터 대상 - 1초마다 동기화(권장)
이 두가지는 rdb에 비해 약간의 오버헤드가 있다
*disk io 의 비용이 있기 때문이다
- no : os가 적절하게 저장하는 형태로, 리눅스의 경우는 30초마다 저장한다
성능이 최우선이며 데이터 유실을 어느 정도 감수할 수 있는 경우에 해당한다
재작성
append하게 되면 파일은 계속해서 커진다
따라서 많은 명령의 중복이 가능하다
예를 들어 10000개의 set 명령이 있을 때 실제로 중요한 것은 마지막이다
따라서 aof는 모든 쓰기 명령을 모두 저장하기보다 재작성을 통해 그 부피를 줄인다
즉, 현재 메모리 상태를 나타내는데 필요한 최소한의 명령만 남기는 것이다
이는 rdb snapshot과 마찬가지로 background로 돌아간다
부모는 클라이언트의 요청을 처리하고 자식은 재작성을 처리하는 것이다
이때, 부모는 요청 처리 + aof 작성을 함께 한다
*자식이 aof를 작성하는 것은 아니다
따라서 같은 키를 반복해 수정하는 패턴이 클 때 효과가 좋다
aof의 장점
- 데이터 손실이 거의 없음
- 덮어쓰지 않음(모든 명령어를 작성)
- 바이너리 파일이 아니기 때문에 사람이 직접 읽고 수정해 반영할 수 있음
- 재작성 과정에서 임시 파일을 만들고 완성되면 원본 교체(부모가 생성한 것)
aof의 단점
- 같은 파일이라도 aof이 rdb보다 크다
- 복구 속도가 느릴 수 있다 - 모든 명령을 순차 실행하기 때문
- 재작성 중에 메모리를 추가로 사용한다
rdb와 마찬가지로 fork 시 cow를 활용하기 때문
