디렉토리
머리말
우리는 우리가 어떤 소프트웨어 또는 하드웨어 오류가 발생하지 않습니다 자신의 서버에 충분한 자신감을 가지고 있더라도, 레디 스 서버는 메모리 알지만, 데이터 레디 스 서버 오류의 결과로, 갑자기 정전이 발생할 수있을 것입니다. 따라서, 우리는 데이터 백업에 대한 기존의 관계형 데이터베이스에 동일한 메모리에 레디 스 데이터는 데이터의 신뢰성을 보장하기 위해, 같은 하드 디스크와 같은 비 휘발성 매체 지속해야합니다.
서버에서 데이터 레디 스 메모리가 다시 시작한 후 우리의 서버가 이전 데이터를 재사용 또는 시스템 장애를 방지하고 원격 위치로 데이터를 백업하기 위해 수 있다는 것입니다 하드 디스크와 같은 미디어의 이익을 위해 지속되었다.
다음과 같은 몇 가지 시나리오가있다 :
对于一些需要进行大量计算而得到的数据，放置在Redis服务器，我们就有必要对其进行数据的持久化，如果需要对数据进行恢复的时候，我们就不需进行重新的计算，只需要简单的将这台机器上的数据复制到另一台需要恢复的Redis服务器就可以了。
레디 스 두 가지 다른 방법으로 지속성 방법을 우리에게 제공 : 스냅 샷 (스냅 숏) 만 추가 파일 (추가 전용 파일).
(1) 도입 명사
스냅 샷 (RDB)이 : 우리가 일반적으로 백업으로 알려진 것입니다, 그가 당신의 하드 드라이브 레디 스 서버 지속성 데이터 내에서 정기적으로 데이터를 백업 할 수 있습니다;
그냥 APPEND 파일 (AOF) : 그가 명령을 작성하면, 쓰기 명령이 늦게 복구가 만에이 쓰기 명령에 모습을 갈 필요가 하드 드라이브 내부를 복사합니다. 사용하여 시간의 마스터 복사본을 실시하는 우리의 MySQL 데이터베이스와 유사 binlog, 동일한 쓰기 명령을 다시 실행 바이너리 파일을;
(2) 지속적인 스냅 샷 일반적인 구성 :
save 60 1000 #60秒时间内有1000次写入操作的时候执行快照的创建stop-writes-on-bgsave-error no #创建快照失败的时候是否仍然继续执行写命令rdbcompression yes #是否对快照文件进行压缩dbfilename dump.rdb #如何命名硬盘上的快照文件dir ./ #快照所保存的位置
(3) 구성 AOP 지속성 :
appendonly no #是否使用AOF持久化appendfsync everysec #多久执行一次将写入内容同步到硬盘上no-appendfsync-on-rewrite no #对AOF进行压缩的时候能否执行同步操作auto-aof-rewrite-percentage 100 #多久执行一次AOF压缩auto-aof-rewrite-min-size 64mb #多久执行一次AOF压缩dir ./ #AOF所保存的位置
참고 :이 두 개의 영속 방식은 단독으로 사용할 수 있고는, 또한 어떤 방법의 구체적인 선택은 특정 상황에 따라 선택, 동시에 사용할 수 있습니다.
스냅 샷 지속성
우리가 백업 부르는의 스냅 샷. 사용자 데이터는 스냅 샷이 생성 된 후, 사용자가 백업 스냅 샷 수, 특정 시점에서 레디 스 메모리를 백업 할 수 있습니다. 일반적으로, 모든 데이터의 손실의 결과 단일 서버 실패를 방지하기 위해, 우리는이 경우, 동일한 데이터와 데이터의 복사본을 생성, 다른 서버에 스냅 샷을 복사 할 수 있습니다, 데이터 복구 또는 서버 다시 시작 당신이 사용할 수있는 경우 때 이러한 스냅 샷 정보 복구 데이터는, 당신은 또한 데이터를 하나의 서버 장애의 손실을 방지 할 수 있습니다.
길의 스냅 샷을 만드는 것입니다에 그러나, 우리는 완전히 당신이 스냅 샷을 생성 할 때, 우리가 잘 때문에, 아니 모든 업데이트 작업이 생성되는 타이밍이 이해할 수있는 우리의 데이터가 손실되지 않도록 보장하지 않습니다, 지불 관심을 필요로하지 않았다 스냅 샷. 시스템 충돌은, 사용자는 데이터 모두의 스냅 샷을 생성하는 가장 최근의 변경 후 손실됩니다 경우. 따라서, 영구 데이터의 스냅 샷뿐만 아니라 덜 자주 변경이나 데이터의 실종 일부 장면에 영향을 미칠 적합합니다.
첫째, 방법의 스냅 샷을 생성합니다
레디 스 클라이언트를 전송하여 (1) BGSAVE 스냅 샷 명령을 만들 수 있습니다.
사용 BGSAVE 시간은 레디 스는 자식 프로세스를 만들 포크를 호출하고 부모 프로세스가 명령 요청 처리를 계속하는 동안 자식 프로세스는 하드 디스크에 기록 된 스냅 샷에 대한 책임이 있습니다.
사용 시나리오 :
이 같은 설정 저장을 사용하는 경우 save 60 1000 생성 후 최근 스냅 샷 후 레디 스에서 계산 된 조건이 충족 될 때 "를 60 초 이내에 1000 쓰기 작업이있다"때 자동으로 BGSAVE 레디 스 명령을 트리거합니다.
구성 저장 어떤 시간의 조건을 충족 할 때 다음 설정 저장 하나,보다 더 사용하는 경우, 레디 스는 BGSAVE 명령을 트리거합니다.
레디 스 클라이언트를 전송하여 (2) SAVE 스냅 샷 명령을 만들 수 있습니다.
레디 스 서버는 스냅 샷이 다른 명령의 모든 요청에 응답하지 않습니다 생성되기 전에 SAVE 명령을 받는다. SAVE 명령없이이 명령 작업을 사용하지 않는 완성되는 SAVE 명령을 사용하여, 또는 사건의 지속성을 기다리는 BGSAVE 명령을 실행하기에 충분한 메모리가없는 우리는 보통 때 사용되지 않습니다
사용 시나리오 :
레디 스 요청 SHUTDOWN 명령 오프 서버에 의해 수신되면 기준 신호 용어를 수신 할 때, 또는 그것이 클라이언트에 의해 전송 된 명령을 수행하지 않는 클라이언트를 모두 차단하는 저장 명령을 수행하고, 저장 명령을 실행하는 것 서버를 종료 한 후.
둘째, 지속적인 스냅 샷 노트의 사용 :
길에서 우리는 데이터가 예를 들어, 시간, 몇 GB 경우 레디 스 서버보다 작은 경우, 데이터의 스냅 샷을 저장하는 데 사용합니다. 레디 스 자식 프로세스를 생성하고 하드 드라이브 내부에 데이터를 저장, 시간이 필요한 데이터도 짧은 읽지 시간의 스냅 샷을 생성하는 데 필요한.
자식 프로세스가 더 많은 시간이 소요됩니다 만들 때, 데이터의 증가와 함께, 레디 스 메모리 풋 프린트가 큰, BGSAVE을 받고, 그렇지 않은 경우 많은 경우 레디 스 서버 메모리의 나머지, 이 시스템 명령 행 BGSAVE 긴 일시 정지를 만들 것입니다, 서버를 사용할 수 없게 될 수 있습니다.
각각의 가상 머신의 종류는, 경과 시간의 서브 스레드를 생성 :
자식 프로세스를 생성 할 때 일시 정지, 우리는 차례 전송 BGSAVE SAVE 또는 수동으로 유지하기 위해 자동 저장 해제 고려할 수 있기 때문에 따라서 순서대로하는 레디 스를 방지하기 위해,
수동 BGSAVE이 현상을 일시 중지 보내지 만 일시 정지는 특정 서비스 요청에 영향을주지 않을 때 우리는 제어 명령을 전송하는 시간을 제어 할 수 있습니다.
또한 SAVE 명령을 사용할 때 레디 스 스냅 샷 생성이 완료 될 때까지하지만 차단 된 상태로 유지됩니다 것을 주목할 가치가있다, 그러나 레디 스의 결과가 중단 자식 프로세스를 만들로는되지 않도록 BGSAVE에, 자식 프로세스를 만들 필요가 없습니다. 정확하게이 때문에, SAVE 빠르게 BGSAVE 이상의 스냅 샷을 생성 빠른 속도의 스냅 샷을 만들 수 있습니다.
스냅 샷 만들기, 우리는 그런데 새벽 서너시 방향 필기 스크립트 실행의 타이밍으로 요청, 적은 시간을 서비스 할 수 있습니다.
AOF 지속성
기록 데이터 변경이 발생에 명령을 쓸 것 AOF 지속성 위해 마지막에 기록 AOF 파일을 실행됩니다. 우리는 데이터를 복구 할 때 이러한 방법으로, 당신은 단지 AOF 파일에 데이터를 복원하는 것을 처음부터 끝까지 수행해야합니다.
첫째, AOF 지속성 옵션을 엽니 다
우리는 다음과 같은 명령을 사용하여 AOF를 열 수 있습니다 :
appendonly yes
우리는 다음 명령을 사용하여 동기화 주파수 AOF 파일을 구성해야합니다 :
appendfsync everysec/always/no
두 appendfsync 동기 주파수 차이
appendfsync 이하의 주파수 차이를 동기화 :
물론 (1) 항상 방법은 데이터 저장 아주 좋은이 될 수는 없지만,이 동기화 전략은 처리 속도 레디 스 명령은 하드 드라이브의 성능을 제한 할 수 있도록, 하드 디스크 쓰기 작업이 많이 필요합니다.
일반 하드 디스크는 초당 쓰기 명령의 수만을 처리 할 수있는 SSD를 사용하여, 두 번째 쓰기 명령에 200에 대해 처리 할 수 있지만, 각 시간은 계속 쓰기 명령은 서면의 작은 금액을 비난 데이터의 연습 쓰기 증폭 심각한 문제가 발생할 수 있습니다,이 감소 심각 SSD의 수명에 영향을 미쳤다.
(2) everysec 방법은, 레디 스 번째 여단 AOF 파일마다 한번의 빈도로 동기화. 이 경우에만 또한 계정에 쓰기 성능을 취할 수 계정 데이터 보안에 걸릴 수 있습니다.
성능 레디 스, 당신은 데이터를 1 초 내에서 생성되는 데이터 누락, 오류가 발생하더라도 다음을 확인 할 수있는 방법의 모든 초를 업데이트하여, 두 번째 AOF 성능에 한 번 파일을 동기화하고 거의 동일한 특성 어떤 지속성을 사용하지 않는 경우 .
(3) 방법은, 레디 스 파일은 AOF하지 나타나는 동기화를 수행하지 않지만 때 AOF 파일 동기화 운영 체제에 의해 결정되어야한다.
이 명령은 일반적으로 많이 레디 스의 성능에 미치는 영향의 원인이하지 않지만 시스템이 데이터 손실이 옵션 레디 스 서버 변수 번호를 사용하지 못할 때.
사용자의 하드 디스크 기록 동작의 처리 속도가 충분히 빠르지 않을 때 또한, 그 버퍼가 하드 디스크에 기록 데이터를 채우기 위해 기다리고, 레디 스 기입 동작이 차단되고 레디 스 명령 요청 처리가 느려, 원인 이러한 이유로, 일반적으로이 옵션을 사용하지 않는 것이 좋습니다.
셋째, 재 작성 / AOF 파일 압축
데이터의 양이 증가와 함께, AOF 파일이 커질 수 있으므로 모든 데이터 복구 시간이 증가 AOF 파일을 해결하기 위해, 매우 긴 시간이 될 것입니다, 사용자는 레디 스의에 보낼 수있는 BGREWRITEAOF 명령의 명령이 중복 명령 파일을 제거하여 AOF AOF 파일을 다시 작성하기 위해, 가능한 한 작은 의료 AOF 파일입니다.
많은 BGREWRITEAOF 및 BGSAVE 같은 원리 작품 : 레디 스는 아이에 의해 AOF 파일의 작업을 재 작성을 담당하고, 자식 프로세스를 생성한다.
학과가 자식 프로세스를 만들 때 지속적인 성능 및 메모리 풋 프린트 문제의 스냅 샷 같은 파일을 이끄는 자식 프로세스를 생성하는 경우 AOF 덮어되기 때문에, 그래서 AOF이 파일을 다시 때문에.
넷째, 트리거 재 작성 / AOF 파일 압축 조건 세트
설정에 의해 AOF auto-aof-rewrite-percentage 및 auto-aof-rewrite-min-size 자동은 BGREWRITEAOF 옵션을 실행합니다.
다음과 같이 그것의 구체적인 의미는, 예를 들어 볼 수 있습니다 :
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
AOF가 64메가바이트보다 현재의 파일 크기 이상을 나타내고, 적어도 100 % 번, 레디 스 BGREWRITEAOF 다시 쓰기 명령을 수행 할 때 파일 개서 볼륨 후 AOF의 체적 비율은 커진다.
AOF 재 작성이 너무 자주 수행하는 경우에, 당신은 할 수 있습니다 auto-aof-rewrite-percentage 더, 당신은 AOF 파일 볼륨이 커지고 후에 만이 가장 뜻밖의 레디 스 재 작성 작업을 수행 할 수 있습니다 100 옵션의 값을 설정뿐만 아니라 수 있습니다 데이터 복구에 대한 시간 실행 시간이 더 길어집니다.
스냅 샷 파일과 파일 AOF 확인
당신은, 우리는 데이터 복구를 수행 할 때, 레디 스 두 개의 명령 줄 프로그램을 지속적으로 제공했다 방법에 상관없이 :
redis-check-aofredis-check-dump
그들이 다시 시스템을 실패 할 경우, 파일 스냅 샷 및 AOF의 상태를 확인하고 파일을 복구가 필요할 수 있습니다.
시간은 사용자가 레디 스 - 체크인 AOF 명령을 실행하는 경우, 지정 --fix 매개 변수를 프로그램 파일 복구 AOF 것입니다.
그는 AOF 파일, 첫 번째 오류 명령이 나타납니다이 프로그램이 잘못된 명령 및 오류 후 명령을 삭제 부정확 한 명령에 대해 살펴 주어진 모든 명령을 스캔 : 방법 수정 파일을 AOF 간단합니다 그 전에 실패한 명령에 위치한 유일한 올바른 명령을 떠나. 대부분의 경우, AOF의 끝에서 삭제 된 파일은 불완전 쓰기 명령입니다.
개요
위 연구는 우리가 함께 다른 한편으로는, 데이터 또는 AOF 지속성의 방법으로 스냅 샷을 필요로하는 한편 지원 지속성에 대한 두 가지 방법, 우리는 또한 얻을 파일의 지속적인 백업, 다른에 백업 할 필요가 서버 때문에 가능한 데이터 손실의 손실을 줄일 수있다.
참고 기사 :
1 액션 레디 스 - [美] 시아 L.Carlsono
