Redis 퍼시스턴스 방식(RDB, AOF), 읽고 나서 충분히 이해함

Redis 지속성 방식(RDB, AOF)

Redis는 RDB(Redis DataBase)와 AOF(Append of File)로 구분되는 지속적인 작업을 지원한다는 것을 알고 있습니다.

RDB 지속성

RDB의 전체 이름을 통해 이 방식이 redis의 주요 지속 방식임을 알 수 있습니다.

RDB 이해

  • 지정된 간격으로 데이터 세트의 메모리 내 스냅샷을 디스크에 씁니다.
  • 즉, 전문 용어의 Snapshot 스냅샷은 스냅샷 파일이 복원될 때 메모리로 직접 읽어들입니다.

백업 프로세스

  • Redis는 지속성을 위해 자식 프로세스를 별도로 생성(fork)합니다. 먼저 데이터를 임시 파일에 기록합니다. 지속성 프로세스가 끝나면 임시 파일을 사용하여 마지막 영구 파일을 대체합니다.
  • 전체 프로세스 동안 메인 프로세스는 IO 작업을 수행하지 않으므로 매우 높은 성능을 보장합니다. 대규모 데이터 복구가 필요하고 데이터 복구 무결성이 그다지 민감하지 않은 경우 RDB 방법이 AOF 방법보다 효율적입니다. . 효율성. RDB의 단점은 마지막 지속성 후에 데이터가 손실될 수 있다는 것입니다.

기록 중 복사 메커니즘: 기록해야 할 때 복사

RDB 파일 위치

redis.conf에서 파일 이름을 구성합니다. 기본값은 dump.rdb입니다.여기에 이미지 설명 삽입

이 파일은 redis가 시작될 때 명령줄이 있는 디렉터리에 있습니다.
여기에 이미지 설명 삽입

RDB의 보존 전략

여기에 이미지 설명 삽입

redis.conf 파일에서도 설정됩니다.
위의 save 900 1은 900초 이내에 하나 이상의 키가 변경되면 현재 스냅샷이 rdb 파일에 저장됨을 의미합니다.
save 300 10은 300초 이내에 10개 이상의 키가 변경되면 현재 스냅샷을 rdb 파일에 저장한다는 의미입니다.
60 10000을 저장합니다. 이는 60초 이내에 최소 10,000개의 키가 변경되었음을 의미합니다. 그런 다음 현재 스냅샷을 rbd 파일에 저장합니다.

Redis가 정상적으로 종료되면 RDB 지속성도 트리거됩니다.

RDB의 장점과 단점

이점:

  • 데이터를 저장하는 rdb 파일이 압축되기 때문에 AOF와 비교하여 디스크 공간을 절약합니다.
  • 빠른 복구.
    결점:
  • Redis는 분기할 때 copy-on-write 기술을 사용하지만 데이터가 방대할 경우 성능을 소모합니다.
  • 백업 주기는 특정 시간 간격으로 백업을 수행하며 이 주기를 벗어나면 마지막 스냅샷 이후의 모든 수정 사항이 손실됩니다.

기타 일반적인 작업

여기에 이미지 설명 삽입

RDB 백업 및 복원

백업
여기에 이미지 설명 삽입
복원

여기에 이미지 설명 삽입


AOF 지속성

AOF(Append of File)의 전체 이름을 통해 AOF가 파일을 추가하여 데이터를 기록한다는 것을 알 수 있습니다.

AOF는 기본적으로 활성화되어 있지 않습니다
. 활성화하는 방법은 무엇입니까? 또한 redis.conf 구성 파일을 통해.
여기에 이미지 설명 삽입
AOF 의 파일 이름 구성
여기에 이미지 설명 삽입
참고: AOF는 AOF와 RDB가 동시에 활성화된 경우 적용됩니다.

지속하는 방법

쓰기 작업을 사용할 때마다 Redis의 AOF 메커니즘은 작업 명령을 AOF 파일에 추가하므로 AOF 파일은 명령을 저장합니다.

데이터 동기화 시기

여전히 위와 같이 redis.conf 파일에 구성되어 있으며
여기에 이미지 설명 삽입
기본값은 1초에 한 번 동기화하는 것입니다. 또한 모든 쓰기 작업에 대해 동기화할 수 있습니다. 또한 능동적으로 동기화되어 운영 체제에 넘겨줄 수도 없습니다.

질문: 파일을 계속 추가하면 파일이 점점 더 커지나요? 그것을 처리하는 방법?
Redis는 다시 쓰기 메커니즘을 사용하며 임계값(구성 파일 구성)을 초과하면 다시 쓰기가 활성화됩니다.
참고: 다시 쓰기는 원본 파일에서 작동하지 않지만 데이터베이스의 기존 데이터를 기반으로 지침을 작성하고 임시 파일을 생성하고 이름 바꾸기에서 원본 AOF 파일을 덮어씁니다.
여기에 이미지 설명 삽입
위 그림과 같이 원래 크기의 2배가 되거나 64mb 이상이 되면 AOF를 다시 작성하게 됩니다.

다시 작성하는 방법?

간단한 예를 들어

127.0.0.1:6379>set a 123
127.0.0.1:6379>set a 132

그러면 다음과 같이 다시 작성됩니다.

127.0.0.1:6379>set a 132

AOF가 더 움푹 들어간 곳:

flushdb와 같은 작업을 수행하면 이 명령도 AOF 파일에 기록되고 이 명령은 다음에 복원할 때 계속 실행되므로 AOF 파일을 열어 이러한 작업이 있는지 확인해야 합니다.

AOF의 장점과 단점

이점:

  • 백업 메커니즘이 더 강력하고 데이터 손실 가능성이 낮습니다.
  • 읽을 수 있는 로그 텍스트(RDB 파일은 압축되어 있어 읽을 수 없음), AOF 파일을 조작하여 오작동을 처리할 수 있습니다.

결점:

  • RDB 파일보다 더 많은 공간을 차지합니다.
  • AOF의 모든 명령어를 실행해야 하기 때문에 백업 속도가 느립니다.
  • 각 읽기 및 쓰기가 동기화되면 특정 성능 압력이 있습니다.
  • 복구 실패를 일으키는 개별 버그가 있습니다.

누가 AOF와 RDB를 사용합니까?

  • 공식 권장 사항은 둘 다 사용하는 것입니다.
  • 데이터가 민감하지 않은 경우 RDB를 사용하십시오.
  • AOF 단독 사용은 권장하지 않으며 버그가 있을 수 있습니다.
  • 순수한 메모리 작업을 위해 redis를 사용하는 경우에는 다음을 수행할 필요가 없습니다.

추천

출처blog.csdn.net/qq_41570752/article/details/108522375