[Redis] Persistence

Snapshotting

Redis는 기본적으로 binary 파일, dump.rdb에 dataset의 snapshot을 저장한다.dataset에 최소 M번 변경된 경우에 매 N초마다 dataset을 저장할수 있게 Redis를 조절할 수 있다. 또는 당신이 SAVE, BGSAVE 명령어를 이용하여 수동으로 조절할수있다.

key값들이 최소 1000번 변경된 경우에 60초마다 Redis가 자동으로 dataset을 disk에
백업하는 예는 다음과 같다.

save 60 1000

이 전략은 아시다시피 snapshotting. 라고 한다.

How it works

다음과 상황이 발생하면 Redis는 dataset을 디스크에 백업을 하게된다.

• Redis forks. 이젠 자식과 부모 프로세스 두개가 존재한다.
• 자식프로세스가 임시 RDB파일에 dataset을 쓰기 시작한다.
• 자식프로세스가 새로운 RDB파일에 쓰는것이 완료되면, 기존에 있는것과 바꾼다.

이 기능은 copy-on-write에서 얻을수있는 이점을 가져왔다.(copy-on-write라는거...처음알았다...)

 

Append-only file

Snapshotting은 내구성이 대단히 좋지는 않다. 만약에 당신의 컴퓨터가 Redis 중단을 실행하던가, 전원이 나갔다거나, 당신이 실수로 kill -9를 실행했을때 마지막 data는 잃어버릴것이다. 이것은 다른 어플리케이션에서는 큰 문제는 되지 않지만, Redis는 완전한 내구성에 영향을 미치고, Redis가 죽을수도 있다.

그래서 Redis가 완전한 내구성의 대안으로 나온것이 append-only file이다. 버젼 1.1부터 사용할수 있게 되었다.
당신은 설정파일에서 AOF옵션을 활성화 시킬수 있다.

appendonly yes

설정 이후부터는 매시간 Redis는 명령어를 받아 dataset이 변경될때마다(e.g. SET) AOF에 추가 될것이다.
Redis를 재시작하면, AOF을 이용하여 상태를 재구성 할것이다.

Log rewriting

당신이 추측 할수있듯이, AOF는 쓰기연산을 수행할때마다 계속 커진다. 만약 당신이 100번 카운터를 증가했다면, 끝날때는 dataset에는 single key와 최종값이 저장되어있겠지만, AOF에는 100개의 정보가 있다.
99개의 정보는 현재 상태에서는 필요하지 않는것인데도 말이다.

그래서 Redis는 재밌는 기능을 지원한다: 클라이언트에게 인터럽트 요청없이 백그라운드에서 AOF를 재조정 할수있다. 언제든지 BGREWRITEAOF 사용하게되면 Redis는 현재 메모리에 dataset를 재구성하기위해 작은 단위로 명령어를 순서대로 쓰기 시작할 것이다.
당신이 AOF를 사용한다면, 때론 BGREWRITEAOF 실행하는게 필요할것이다.

 

How durable is the append only file?

Redis가 disk에 있는 data와 fsync를 몇번할지 정할수 있다. 여기 옵션이 있다.
(지금 옵션보니까 appendfsync [no, everysec, always]로 되어있다.)

• fsync every time, 새 명령어를 AOF에 추가한다. 엄청 느리지만, 매우 안전하다.
• fsync every second, 충분히 빠르다. 자연재해가 발생한다면 당신은 1초의 data를 잃어버릴수도있다.
• Never fsync, data를 저장하는것은 OS에 맡기는것이다. 빠르지만 안전하지 않은 방법이다.

추천하는(그리고 default로 설정되어있는)건 fsync every second로 설정하는것이다. 매우 빠르면서 매우 안전하다always설정은(위에보면 every time인것같다.) 매우 느리다(Redis 2.0에서 성능향상이 있었지만 아직도 느리다) 더 빠르게 하는 방법은 없다.

 

AOF파일이 충돌나면 어떻게 해야될까요?

서버가 AOF파일에 쓰는도중 충돌 나는건 충분히 가능한 얘기이다.충돌난 파일은 Redis에서 더 이상 사용하지않는다. 충돌이 났을경우 당신은 아래와 같은 방법으로 문제를 해결할 수 있다.

• AOF파일의 백업 파일을 생성한다.
• Fix the original file using the redis-check-aof tool을 사용하여 원본 파일을 고친다

• $ redis-check-aof --fix <filename>

• Optionally use diff -u 명령을 사용하여 백업파일과 원본 파일의 차이를 점검한다.
• 수정된 원본 파일로 Redis를 시작한다.

How it works

이미 snapshotting에서 사용했던것처럼 로그 다시쓰기도 copy-on-write방법을 사용한다.
다음과 같이 진행한다.

• Redis forks, 자식노드와 부모노드가 존재한다.
• 자식노드는 임시 AOF파일에 쓰기 시작한다.
• 부모노드는 메모리 버퍼에 새로 변경된 내용들을 모두 계산한다. (동시에 파일에 쓰게되면 다시쓰기는 실패하게 된다. 안전한 장치인것이다.)
• 자식 노드가 쓰기 작업이 완료가 되면, 부모노드는 신호를 받고, 자식노드로부터 생성한 파일의 끝에 메모리 버퍼에 있는 내용을 이어 쓴다.
• Redis는 자동으로 이전파일명을 새로운 파일명으로 변경하고, 새로운 파일에 새로운 데이타를 쓰기 시작한다.

 

AOF를 어떻게 바꾸나요? dump.rdb snapshots을 이용하면 되나요?

Redis2.0과 Redis2.2가 절차가 다릅니다. Redis2.2가 간단하고, 재시작할 필요가 없습니다.

Redis 2.2

• 마지막 dump.rdb파일의 백업 파일을 만든다.
• 백업파일을 안전한 곳으로 전송한다.
• 아래 두 명령어를 실행한다.
• redis-cli config set appendonly yes
• redis-cli config set save ""
• 당신의 database는 같은 key에 대해 같은 value를 가지는지 확인한다.
• AOF에 올바르게 쓰기작업을 실행하는지 확인한다.

첫번째 CONFIG 명령은 AOF 기능을 활성화 한다. Redis는 초기 dump파일을 생성하기위해서 차단될 것이다.
그리고 기록할  파일을 열고, 다음 쿼리부터 이어쓸것이다.
두번째 CONFIG 명령은 snapshotting persistence을 끌때 사용한다. 이것은 선택사항이다.

IMPORTANT: redis.conf를 수정할때는 AOF기능을 키고 수정해야한다. 그렇지 않고 서버를 재시작하면 변경된 설정은 잃어버릴수도 있다. 그리고 변경전 설정파일로 서버는 시작할것이다.

Redis 2.0

• 마지막 dump.rdb 파일의 백업 파일을 만든다.
• 백업파일을 안전한 곳으로 전송한다.
• database가 쓰는작업을 모두 멈춘다.
• redis-cli가 bgrewriteaof 수행하면, AOF파일을 만들것이다.
• Redis가 AOF dump 생성이 끝나면 서버는 멈춘다.
• redis.conf 수정을 마치면 AOF 기능이 활성화된다.
• 서버를 재시작한다.
• 당신의 database는 같은 key에 대해 같은 value를 가지는지 확인해보자
• AOF에 올바르게 쓰기작업을 실행하는지 확인해보자.

원문 링크 :

Persistence