Redis 와 캐싱 · 영속성(RDB·AOF)과 한계 · 퀴즈
퀴즈: 영속성
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
`appendfsync everysec` 설정에서 최악의 유실 구간은?
- 유실 없음
- 약 1분어치
- 마지막 스냅샷 이후 전부
- 약 1초어치
RDB 단독 방식의 가장 큰 약점은?
- 마지막 스냅샷 이후의 쓰기를 전부 잃는다
- AOF 보다 복구가 느리다
- 파일 크기가 AOF 보다 크다
- 복제본으로 전파되지 않는다
RDB 스냅샷 중 메모리가 순간적으로 크게 늘어나는 이유는?
- 스냅샷을 압축하며 버퍼를 크게 잡아서
- AOF 리라이트와 시점이 겹치기 때문
- 복제본으로 보낼 네트워크 버퍼 때문
- fork 뒤 copy-on-write 로 페이지가 복제되기 때문
혼합 모드(RDB 프리앰블 + AOF)를 쓰는 이유는?
- 복구는 RDB 처럼 빠르면서 유실 구간은 AOF 처럼 1초로 유지하려고
- AOF 파일이 작아져 디스크를 아끼려고
- 복제본이 스냅샷을 그대로 받게 하려고
- 리라이트 중 메모리 사용을 줄이려고
'절대 잃으면 안 되는' 데이터의 1차 저장소로 Redis 가 부적절한 주된 이유는?
- 디스크에 매번 기록해 읽기와 쓰기가 느려서
- 복제가 비동기라 마스터 장애 시 복제본에 도달하지 못한 쓰기가 있을 수 있어서
- 메모리에 담을 수 있는 용량이 작아서
- 조인이나 집계 같은 쿼리를 지원하지 않아서
maxmemory 를 물리 메모리보다 충분히 낮게 잡는 이유로 옳은 것은?
- OS 페이지 캐시를 위한 공간만 남기려고
- 축출을 자주 일으켜 오래된 키를 지우려고
- 성능 벤치마크 숫자를 좋게 만들려고
- 스냅샷과 복제, 클라이언트 버퍼가 쓸 여유가 필요해서