|
|
게시됨 2021. 2. 4. 오후 1:47:27
|
|
|
|
1. 서문
최근에는 Redis가 프로젝트 내 캐시로 사용되어 여러 비즈니스 프로세스 간 데이터 공유를 촉진하고 있습니다. Redis 데이터는 메모리에 저장되기 때문에 지속성이 설정되지 않으면 Redis가 재시작된 후 모든 데이터가 사라지므로, redis의 지속성 기능을 활성화해 데이터를 디스크에 저장해야 합니다. 그리고 redis가 재시작되면 디스크에서 데이터를 복구할 수 있습니다. Redis는 두 가지 지속 방식을 제공합니다. RDB 영속성(원칙은 Reids의 데이터베이스 레코드를 디스크 내 RDB 영속성으로 덤프하는 것)이고, 다른 하나는 AOF 지속성(원칙은 Reids의 작업 로그를 부록 형태의 파일에 쓰는 것입니다). 그렇다면 이 두 지속성 방법의 차이점은 무엇이며, 어떻게 변경할지 선택할 수 있을까요? 인터넷에서 읽은 대부분의 자료는 이 두 방법의 구성과 사용법을 소개하지만, 두 방법의 차이나 어떤 응용 시나리오에서 사용해야 하는지에 대한 소개는 없습니다.
2. 두 가지의 차이점
RDB 지속성은 지정된 시간 내에 메모리에 데이터셋의 스냅샷을 디스크로 기록하는 것을 의미하며, 실제 작업 과정은 하위 프로세스를 포크하여 먼저 데이터셋을 임시 파일에 쓰고, 쓰기가 성공한 후 이전 파일을 교체한 뒤 이진 압축으로 저장하는 것입니다.
AOF의 지속성은 서버가 처리하는 모든 쓰기 및 삭제 작업을 로그 형식으로 기록하며, 쿼리 작업은 기록되지 않고 텍스트로 기록됩니다. 파일을 열면 상세한 작업 기록을 볼 수 있습니다.
3. 두 가지의 장단점
RDB의 장점은 무엇인가요?
1). 이 기능을 사용하면 전체 Redis 데이터베이스에 하나의 파일만 포함하게 되어, 파일 백업에 적합합니다. 예를 들어, 최근 24시간을 매시간 아카이브하고, 매일 지난 30일도 아카이브할 수 있습니다. 이러한 백업 전략을 통해 시스템에 치명적인 장애가 발생했을 때 쉽게 복구할 수 있습니다.
2). RDB는 재해 복구에 매우 좋은 선택입니다. 왜냐하면 우리는 단일 파일을 쉽게 압축해서 다른 저장 매체로 옮길 수 있기 때문입니다.
3). 성능 극대화. Redis 서비스 프로세스의 경우, 지속 작업을 시작할 때 필요한 것은 자식 프로세스를 포크하는 것뿐이며, 자식 프로세스가 이 지속성 작업을 수행하여 서비스 프로세스가 IO 작업을 수행하는 것을 크게 피할 수 있습니다.
4). 데이터셋이 클수록 RDB의 시작 효율이 더 높습니다.
RDB의 단점은 무엇인가요?
1). 데이터의 높은 가용성, 즉 데이터 손실을 최대한 피하고 싶다면 RDB는 좋은 선택이 아닙니다. 왜냐하면 시스템이 예정된 지속 시간 전에 다운되면, 이전에 디스크에 기록된 데이터가 사라지기 때문입니다.
2). RDB는 포크 서브프로세스를 통해 데이터 지속성을 지원하기 때문에, 데이터 세트가 크면 서버 전체가 수백 밀리초 또는 심지어 1초 동안 서비스를 중단할 수 있습니다.
AOF의 장점은 무엇인가요?
1). 이 메커니즘은 더 큰 데이터 보안, 즉 데이터 지속성을 가져올 수 있습니다. Redis에는 3가지 동기화 전략이 제공되며, 즉 초당 동기화, 수정 당시 동기화, 그리고 동기화 해제가 있습니다. 사실 초당 동기화도 비동기식으로 이루어지며, 효율도 매우 높습니다. 다만 시스템이 다운되면 수정된 데이터가 이 초 내에 사라진다는 점이 다릅니다. 수정이 동기화될 때마다 동기화 지속성(synchronization Persistence)으로 생각할 수 있는데, 즉 발생하는 모든 데이터 변경이 즉시 디스크에 기록됩니다. 이 방법이 가장 비효율적일 것으로 예상된다. 동기화가 없다는 점에 대해서는 더 말할 필요 없고, 모두가 이해할 수 있을 거라 생각합니다.
2). 이 메커니즘이 로그 파일 작성에 추가 모드를 채택하기 때문에, 작성 과정 중 다운타임이 있더라도 로그 파일에 이미 존재하는 내용은 파괴되지 않습니다. 하지만 만약 데이터의 절반만 쓰고 이번에 시스템이 다운된다면, 걱정하지 마세요. Redis-check-aof 도구를 사용해 다음 Redis 시작 전에 데이터 일관성 문제를 해결할 수 있습니다.
3). 로그가 너무 클 경우, Redis는 자동으로 재작성 메커니즘을 활성화할 수 있습니다. 즉, Redis는 추가 모드에서 수정 데이터를 계속 이전 디스크 파일에 쓰고, 이 기간 동안 어떤 수정 명령이 실행되는지 기록하는 새 파일도 생성합니다. 따라서 재작성 간 전환 시 데이터 보안을 더 잘 보장할 수 있습니다.
4). AOF는 모든 수정 사항을 기록하는 명확하고 이해하기 쉬운 로그 파일을 포함하고 있습니다. 사실, 이 파일을 통해 데이터 재구성을 완료할 수도 있습니다.
OV의 단점은 무엇인가요?
1). 같은 수의 데이터셋에 대해 OF 파일은 보통 RDB 파일보다 큽니다. RDB는 AOF보다 대용량 데이터셋을 더 빠르게 복구합니다.
2). 동기화 전략에 따라 AOF는 실행 효율성 면에서 RDB보다 느린 경향이 있습니다. 요컨대, 초당 동기화 정책의 효율성은 비교적 높으며, 동기식 비활성화 정책의 효율성은 RDB만큼 효율적입니다.
두 가지를 선택하는 기준은 시스템이 더 높은 캐시 일관성(AOF)을 위해 일부 성능을 희생할 의향이 있는지, 또는 쓰기 작업이 빈번할 때 더 높은 성능을 위해 백업을 활성화하지 않고 수동으로 저장할 때 백업(RDB)을 할 의향이 있는지입니다. RDB는 더 최종적이고 일관된 의미를 가집니다. 하지만 생산 환경은 사실 두 가지가 결합된 형태입니다.
4. 일반적인 구성
RDB 지속성 구성
Redis는 데이터셋의 스냅샷을 dump.rdb 파일에 덤프합니다. 또한, 구성 파일을 통해 Redis 서버 덤프 스냅샷의 빈도를 수정할 수 있습니다. 6379.conf 파일을 열어 저장 파일을 검색하면 다음과 같은 구성 정보를 확인할 수 있습니다:
AOF의 영구 구성
Redis 프로필에서 동기화하는 방법은 세 가지가 있는데, 다음과 같습니다:
전체 구성:
테스트 디렉터리 아래에 다음과 같이 새로운 파일 "appendonly.aof"가 생성됩니다:
|
이전의:DataTables는 테이블 내보내기, Excel, CSV, 인쇄를 구현합니다다음:SQL Server는 트랜잭션 격리 레벨을 설정합니다
|
집주인|
게시됨 2021. 2. 8. 오전 11:45:25
|
게시됨 2021. 9. 22. 오후 8:26:16