Redis의 AOF 지속성에 대한 분석 예

1. AOF 소개

RDB는 데이터베이스에 키-값 쌍을 저장하여 데이터베이스의 상태를 기록할 수 있는 지속성 방식입니다. AOF는 Redis 서버에서 실행되는 쓰기 명령을 기록하여 데이터베이스 상태를 저장하는 지속성 방법입니다.

　예를 들어 다음 명령의 경우:

　

　 RDB 지속성 방법은 str1, str2 및 str3의 세 가지 키-값 쌍을 RDB 파일에 저장하는 반면 AOF 지속성은 세트를 실행하는 것입니다. sadd 및 lpush 세 가지 명령이 AOF 파일에 저장됩니다.

2. AOF 구성

　redis.conf 구성 파일의 APPEND ONLY MODE에서:

　

　①, appendonly: 기본값은 no입니다. 이는 redis가 기본적으로 rdb 지속성을 사용함을 의미합니다. AOF 지속성, 추가 전용을 예로 변경해야 합니다.

　　②、appendfilename：aof 파일 이름, 기본값은 "appendonly.aof"

　3、appendfsync：aof 지속성 전략 구성

　　은 fsync를 실행하지 않는 것을 의미하지 않으며 운영 체제는 다음을 보장합니다. 데이터가 디스크에 동기화되는 것이 가장 빠르지만 매우 안전하지는 않습니다.

　Always는 데이터가 디스크에 동기화되도록 하기 위해 각 쓰기마다 fsync가 실행됨을 의미하며 이는 매우 비효율적입니다. 1초에 한 번씩 fsync를 실행하면 1초 내에 데이터가 손실될 수 있습니다. 일반적으로 보안과 효율성의 균형을 맞추기 위해 Everysec을 선택합니다.

　 ④, no-appendfsync-on-rewrite: aof를 rdb 파일에 다시 쓰거나 쓸 때 많은 양의 IO가 수행되며, Everysec 및 Always aof 모드에 대해 fsync를 실행하면 a에 대한 차단이 발생합니다. no-appendfsync-on-rewrite 필드는 기본적으로 no로 설정됩니다. 애플리케이션에 높은 대기 시간 요구 사항이 있는 경우 이 필드를 예로 설정할 수 있습니다. 그렇지 않으면 지속성 기능에 더 안전한 선택인 아니요로 설정됩니다. yes로 설정하면 새 쓰기 작업이 다시 쓰기 중에 fsyncd되지 않고 메모리에 임시로 저장되며 다시 쓰기가 완료된 후 쓰기가 됨을 의미합니다. 기본값은 no이며 yes를 권장합니다. Linux의 기본 fsync 정책은 30초입니다. 30초 동안의 데이터가 손실될 수 있습니다. 기본값은 아니오입니다.

auto-aof-rewrite-percentage의 기본값은 100입니다. aof 자동 재작성 구성에서는 현재 aof 파일 크기가 마지막으로 다시 작성된 aof 파일 크기의 백분율을 초과하면 다시 작성됩니다. 즉, aof 파일이 특정 크기로 커지면 Redis는 bgrewriteaof를 호출하여 로그 파일을 다시 작성할 수 있습니다. AOF 파일 크기가 마지막 로그 재작성 크기(100으로 설정)의 두 배에 도달하면 새 로그 재작성 프로세스가 자동으로 시작됩니다.

auto-aof-rewrite-min-size는 64MB로 설정됩니다. 합의된 백분율에 도달했을 때 다시 작성할 필요가 없도록 하려면 최소 파일 크기를 설정할 수 있습니다.

　7, aof-load-truncated: aof 파일이 마지막에 불완전할 수 있습니다. redis가 시작되면 aof 파일의 데이터가 메모리에 로드됩니다. 특히 ext4 파일 시스템이 data=ordered 옵션을 추가하지 않은 경우 redis가 위치한 호스트 운영 체제가 다운된 후 다시 시작될 수 있습니다. redis를 종료하도록 선택하거나 가능한 한 많은 데이터를 가져오십시오. 예 옵션을 선택하면 잘린 aof 파일을 가져올 때 로그가 클라이언트에 자동으로 전송되고 로드됩니다. 대답이 '아니요'인 경우 사용자는 redis-check-aof 명령을 수동으로 실행하여 AOF 파일을 복구해야 합니다. 기본값은 예입니다.

3. AOF

를 켭니다. redis.conf의 추가 전용 구성을 yes로 변경합니다.

　　AOF가 파일을 저장하는 위치는 RDB가 파일을 저장하는 위치와 동일합니다. redis.conf 구성 파일의 디렉토리를 통해 구성됩니다.

　　

　저장된 경로는 config get dir 명령을 통해 얻을 수 있습니다. .

4.AOF 파일 복구

　Redis를 다시 시작하면 AOF 파일이 로드됩니다.

　예외 복구 명령: redis-check-aof --fix to Repair

5.AOF rewriting

AOF 지속성은 Redis가 계속 진행됨에 따라 쓰기 명령을 AOF 파일에 지속적으로 기록하므로 AOF 파일은 파일이 클수록 서버 메모리를 더 많이 차지하게 되고 AOF 복구 시간도 길어집니다. 이 문제를 해결하기 위해 Redis는 AOF 파일의 크기가 설정된 임계값을 초과하는 경우 데이터를 복구할 수 있는 최소 명령 세트만 유지하면서 AOF 파일의 콘텐츠 압축을 시작하는 새로운 재작성 메커니즘을 추가했습니다. bgrewriteaof 명령을 사용하여 다시 작성할 수 있습니다.

　예를 들어 다음 명령의 경우:

　

AOF 파일을 다시 작성하지 않으면 AOF 파일은 4개의 SADD 명령을 저장합니다. AOF 다시 쓰기를 사용하면 다음 명령만 AOF 파일에 유지됩니다.

1	sadd animals "dog" "tiger" "panda" "lion" "cat"

　즉, AOF 파일 재작성은 원본 파일을 재구성하지 않고, 서버의 기존 키-값 쌍을 직접 읽어와서 명령어를 사용하는 것입니다. 이전에 이 키-값 쌍을 기록한 여러 명령을 바꾸려면 새 파일을 생성하고 원본 AOF 파일을 바꾸십시오.

　　AOF 파일 재작성 트리거링 메커니즘: redis.conf 구성 파일의 auto-aof-rewrite-percentage를 통해: 기본값은 100이고 auto-aof-rewrite-min-size: 64mb 구성, 이는 기본 Redis를 의미합니다. 마지막 재작성 당시의 AOF 크기가 기록됩니다. 기본 구성은 AOF 파일 크기가 마지막 재작성 후 크기의 두 배가 되고 파일이 64M보다 클 때 트리거되는 것입니다.

　

다시 언급하자면, Redis는 단일 스레드 작업이라는 것을 알고 있습니다. AOF를 다시 작성하는 데 시간이 오래 걸리면 AOF를 다시 작성하는 동안 Redis는 오랫동안 다른 명령을 처리할 수 없습니다. , 이는 분명히 용납할 수 없는 일입니다. 이 문제를 극복하기 위해 Redis의 솔루션은 AOF 재작성 프로그램을 서브루틴에 넣는 것입니다. 여기에는 두 가지 이점이 있습니다. 　　① 하위 프로세스의 AOF 재작성 중에 서버 프로세스(상위 프로세스)는 계속해서 다른 명령을 처리할 수 있습니다. .

스레드 대신 하위 프로세스를 사용하면 하위 프로세스에 상위 프로세스의 데이터 복사본이 있으므로 잠금 사용을 피하고 데이터 보안을 보장할 수 있습니다.

　하위 프로세스를 사용하면 위의 문제가 해결되지만 새로운 문제도 발생합니다. 서버 프로세스가 하위 프로세스의 AOF 재작성 중에 다른 명령을 계속 처리하고 있기 때문에 이 새로운 명령으로 인해 현재 데이터베이스가 수정될 수도 있습니다. 상태와 다시 작성된 AOF 파일 상태가 일치하지 않습니다.

　일관되지 않은 데이터 상태 문제를 해결하기 위해 Redis 서버는 AOF 다시 쓰기 버퍼를 설정합니다. 이 버퍼는 Redis 서버가 쓰기 명령을 실행할 때 사용됩니다. AOF 재작성 버퍼. 하위 프로세스가 AOF 재작성을 완료하면 상위 프로세스에 신호를 보냅니다. 상위 프로세스가 신호를 받은 후 AOF 재작성 버퍼의 내용을 새 AOF 파일에 쓰는 함수를 호출합니다.

　이렇게 하면 AOF 재작성이 서버에 미치는 영향이 최소화됩니다.

6. AOF의 장점과 단점

장점:

　①. AOF 지속성 방법은 기본 동기화 빈도를 사용하여 초당 한 번씩 동기화하더라도 Redis는 1초의 데이터만 손실합니다. 최대. .

　②. AOF 파일은 Redis 명령 추가를 사용하여 구성됩니다. 따라서 Redis가 AOF 파일에 명령 조각만 쓸 수 있더라도 redis-check-aof 도구를 사용하면 AOF 파일을 쉽게 수정할 수 있습니다.

AOF 파일의 형식은 읽기 쉬우므로 사용자가 보다 유연하게 처리할 수 있습니다. 예를 들어, 다시 쓰기가 진행되기 전에 실수로 FLUSHALL 명령을 사용한 경우 마지막 FLUSHALL 명령을 수동으로 제거한 다음 AOF를 사용하여 데이터를 복구할 수 있습니다.

　단점:

　①. 동일한 데이터를 사용하는 Redis의 경우 일반적으로 AOF 파일이 RDF 파일보다 큽니다.

AOF의 기본 동기화 빈도는 초당 1회이며 다양한 동기화 빈도 옵션을 제공하지만 성능은 여전히 ​​높습니다. Redis 로드가 높을 때 RDB는 AOF보다 더 나은 성능을 보장합니다.

　3. RDB는 스냅샷을 사용하여 전체 Redis 데이터를 유지하는 반면, AOF는 실행된 각 명령만 AOF 파일에 추가합니다. 따라서 이론적으로 RDB는 AOF보다 강력합니다. 공식 문서에 따르면 AOF에는 RDB에는 없는 몇 가지 버그가 있습니다.

　그럼 AOF와 RDB라는 두 가지 지속성 방법 중에서 어떻게 선택해야 할까요?

　단기간 내에 데이터 손실을 견딜 수 있다면 RDB를 사용하는 것이 가장 좋다는 것은 의심의 여지가 없습니다. 정기적으로 RDB 스냅샷을 생성하는 것은 데이터베이스 백업에 매우 편리하며 데이터 세트의 RDB 복구 속도도 좋습니다. AOF 복구보다 빠릅니다. RDB를 사용하면 AOF의 숨겨진 버그를 피할 수도 있습니다. 그렇지 않으면 AOF 재작성을 사용하세요. 그러나 일반적으로 특정 지속성 메커니즘을 단독으로 사용하지 않고 두 가지를 함께 사용하는 것이 좋습니다. 이 경우 Redis가 다시 시작되면 AOF 파일이 먼저 로드되어 원래 데이터를 복원합니다. 왜냐하면 정상적인 상황에서는 데이터 세트가 저장되기 때문입니다. AOF 파일의 데이터 세트는 RDB 파일에 저장된 데이터 세트보다 더 완전합니다. 아마도 앞으로 Redis 관계자는 두 가지 지속성 방법을 하나의 지속성 모드로 병합할 것입니다.

위 내용은 Redis의 AOF 지속성에 대한 분석 예의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!