Redis 튜토리얼(10): 지속성에 대한 자세한 설명

1. Redis가 제공하는 지속성 메커니즘:

1) RDB 지속성:
이 메커니즘은 지정된 시간 간격 내에 메모리에 있는 데이터 세트의 스냅샷을 디스크에 쓰는 것을 의미합니다.
2) AOF 지속성:
이 메커니즘은 Redis 서버 시작 시 서버에서 처리하는 모든 쓰기 작업을 로그 형식으로 기록하여 데이터베이스를 재구축합니다. 시작 후 데이터베이스의 데이터가 완료됩니다.
3) 지속성 없음:
구성을 통해 Redis 서버의 지속성 기능을 비활성화하여 Redis를 memcached의 향상된 버전으로 처리할 수 있습니다.
4) AOF와 RDB를 동시에 적용합니다.

2. RDB 메커니즘의 장점과 단점:

RDB의 장점은 무엇인가요?

1) 이 방법을 채택하면 전체 Redis 데이터베이스에 하나의 파일만 포함되므로 파일 백업에 적합합니다. 예를 들어 지난 24시간 동안의 데이터를 매시간 보관하고 지난 30일간의 데이터를 매일 보관하도록 계획할 수 있습니다. 이러한 백업 전략을 통해 시스템에 치명적인 장애가 발생하면 매우 쉽게 복원할 수 있습니다.
2) 재해 복구에는 RDB가 매우 좋은 선택입니다. 단일 파일을 쉽게 압축한 다음 다른 저장 매체로 전송할 수 있기 때문입니다.
3) 성능을 극대화합니다. Redis 서비스 프로세스의 경우 지속성을 시작할 때 해야 할 일은 하위 프로세스를 분기하는 것뿐입니다. 그러면 하위 프로세스가 지속성 작업을 완료합니다. 이렇게 하면 IO 작업을 수행하는 서비스 프로세스를 크게 피할 수 있습니다.
4) AOF 메커니즘과 비교하여 데이터 세트가 클수록 RDB 시작 효율성이 높아집니다.

RDB의 단점은 무엇인가요?

1) 데이터의 높은 가용성을 보장하려는 경우, 즉 데이터 손실을 최대한 방지하려는 경우 RDB는 좋은 선택이 아닙니다. 예약된 지속성 전에 시스템이 충돌하면 디스크에 쓸 시간이 없었던 데이터가 손실되기 때문입니다.
2) RDB는 포크 하위 프로세스를 통해 데이터 지속성을 지원하므로 데이터 세트가 큰 경우 전체 서버가 수백 밀리초 또는 심지어 1초 동안 서비스를 중지할 수 있습니다.

3. AOF 메커니즘의 장점과 단점:

AOF의 장점은 무엇인가요?

1) 이 메커니즘은 더 높은 데이터 보안, 즉 데이터 지속성을 가져올 수 있습니다. Redis는 세 가지 동기화 전략, 즉 매초 동기화, 수정마다 동기화, 동기화 없음을 제공합니다. 실제로 매 초 동기화도 비동기식으로 완료되며 효율성도 매우 높습니다. 유일한 차이점은 시스템이 다운되면 이 초 내에 수정된 데이터가 손실된다는 것입니다. 수정 사항이 동기화될 때마다 이를 동기식 지속성이라고 생각할 수 있습니다. 즉, 발생하는 모든 데이터 변경 사항이 즉시 디스크에 기록됩니다. 이 방법은 효율성이 가장 낮을 것으로 예측할 수 있습니다. 동기화가 없다는 것은 더 말할 필요도 없이 모두가 정확하게 이해할 수 있다고 생각합니다.
2) 이 메커니즘은 로그 파일 쓰기에 추가 모드를 사용하므로 쓰기 프로세스 중에 다운타임이 발생하더라도 로그 파일의 기존 내용은 삭제되지 않습니다. 그러나 이 작업에서 데이터의 절반만 쓰고 시스템 충돌이 발생하더라도 걱정하지 마십시오. 다음에 Redis가 시작되기 전에 redis-check-aof 도구를 사용하여 데이터 일관성 문제를 해결할 수 있습니다.
3) 로그가 너무 크면 Redis가 자동으로 다시 쓰기 메커니즘을 활성화할 수 있습니다. 즉, Redis는 수정된 데이터를 추가 모드에서 이전 디스크 파일에 지속적으로 기록하는 동시에 이 기간 동안 어떤 수정 명령이 실행되었는지 기록하기 위해 새 파일도 생성합니다. 따라서 다시 쓰기 전환을 수행할 때 데이터 보안이 더 잘 보장될 수 있습니다.
4) AOF에는 모든 수정 작업을 기록하기 위한 명확하고 이해하기 쉬운 형식의 로그 파일이 포함되어 있습니다. 실제로 이 파일을 통해 데이터 재구성을 완료할 수도 있습니다.

AOF의 단점은 무엇인가요?
1) 동일한 수의 데이터 세트에 대해 AOF 파일은 일반적으로 RDB 파일보다 큽니다.
2) 동기화 전략에 따라 AOF는 운영 효율성 측면에서 RDB보다 느린 경우가 많습니다. 간단히 말해서, 초당 동기화 전략의 효율성은 상대적으로 높으며, 동기화 비활성화 전략의 효율성은 RDB만큼 효율적입니다.

4. 기타:

1. 스냅샷:

기본적으로 Redis는 데이터 세트의 스냅샷을 dump.rdb 파일에 덤프합니다. 또한 구성 파일을 통해 Redis 서버 덤프 스냅샷의 빈도를 수정할 수도 있습니다. 6379.conf 파일을 연 후 save를 검색하면 다음 구성 정보를 볼 수 있습니다.
save 900 1 #In 900 second( 15분), 키가 1개 이상 변경되면 메모리 스냅샷을 덤프합니다.
save 300 10 #300초(5분) 후 10개 이상의 키가 변경된 경우 메모리 스냅샷을 덤프합니다.
save 60 10000 #60초(1분) 후 10,000개 이상의 키가 변경된 경우 메모리 스냅샷을 덤프합니다.

2. 덤프 스냅샷 메커니즘:

1) Redis는 하위 프로세스를 먼저 포크합니다.
2) 하위 프로세스는 스냅샷 데이터를 임시 RDB 파일에 씁니다.
3) 하위 프로세스가 데이터 쓰기 작업을 완료하면 이전 파일을 임시 파일로 교체합니다.

3. AOF 파일:

위에서 여러 번 언급했듯이 RDB의 스냅샷 예약 덤프 메커니즘은 좋은 데이터 내구성을 보장할 수 없습니다. 우리 애플리케이션이 이에 대해 정말로 우려하고 있다면 Redis에서 AOF 메커니즘을 사용하는 것을 고려해 볼 수 있습니다. Redis 서버의 경우 기본 메커니즘은 RDB입니다. AOF를 사용해야 하는 경우 구성 파일에서 다음 항목을 수정해야 합니다.
appendonly no를 addonly yes로 변경
이제부터 Redis는 time 데이터 수정 명령을 받은 후 AOF 파일에 추가됩니다. 다음에 Redis가 다시 시작되면 최신 데이터를 메모리에 구축하기 위해 AOF 파일의 정보를 로드해야 합니다.

4. AOF 구성:

Redis 구성 파일에는 세 가지 동기화 방법이 있습니다.
AOF 파일에서 데이터 수정이 발생할 때마다 항상 #Written입니다.
appendfsynceverysec #초마다 한 번씩 동기화하는 전략은 AOF의 기본 전략입니다.
appendfsync no #동기화하지 않음. 효율적이지만 데이터가 유지되지 않습니다.

5. 손상된 AOF 파일을 복구하는 방법:

1) 손상된 기존 AOF 파일의 추가 복사본을 만듭니다.
2) "redis-check-aof --fix " 명령을 실행하여 손상된 AOF 파일을 복구합니다.
3) 복구된 AOF 파일로 Redis 서버를 다시 시작합니다.

6. Redis 데이터 백업:

Redis에서는 실행 중인 Redis 데이터 파일을 복사하여 온라인으로 백업할 수 있습니다. 이는 RDB 파일이 생성되면 수정되지 않기 때문입니다. Redis는 매번 최신 데이터를 임시 파일에 덤프한 다음 이름 바꾸기 기능을 사용하여 임시 파일의 이름을 원래 데이터 파일 이름으로 원자적으로 바꿉니다. 따라서 데이터 파일 복사는 언제든지 안전하고 일관적이라고 말할 수 있습니다. 이를 고려하여 cron 작업을 생성하여 Redis 데이터 파일을 정기적으로 백업하고 백업 파일을 안전한 디스크 매체에 복사할 수 있습니다.

위는 Redis Tutorial(10)의 내용입니다. Persistence에 대한 자세한 설명은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!