LabHub

Redis 와 캐싱 · 영속성(RDB·AOF)과 한계 · 퀴즈

퀴즈: 영속성

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. `appendfsync everysec` 설정에서 최악의 유실 구간은?

    1. 유실 없음
    2. 약 1분어치
    3. 마지막 스냅샷 이후 전부
    4. 약 1초어치
  2. RDB 단독 방식의 가장 큰 약점은?

    1. 마지막 스냅샷 이후의 쓰기를 전부 잃는다
    2. AOF 보다 복구가 느리다
    3. 파일 크기가 AOF 보다 크다
    4. 복제본으로 전파되지 않는다
  3. RDB 스냅샷 중 메모리가 순간적으로 크게 늘어나는 이유는?

    1. 스냅샷을 압축하며 버퍼를 크게 잡아서
    2. AOF 리라이트와 시점이 겹치기 때문
    3. 복제본으로 보낼 네트워크 버퍼 때문
    4. fork 뒤 copy-on-write 로 페이지가 복제되기 때문
  4. 혼합 모드(RDB 프리앰블 + AOF)를 쓰는 이유는?

    1. 복구는 RDB 처럼 빠르면서 유실 구간은 AOF 처럼 1초로 유지하려고
    2. AOF 파일이 작아져 디스크를 아끼려고
    3. 복제본이 스냅샷을 그대로 받게 하려고
    4. 리라이트 중 메모리 사용을 줄이려고
  5. '절대 잃으면 안 되는' 데이터의 1차 저장소로 Redis 가 부적절한 주된 이유는?

    1. 디스크에 매번 기록해 읽기와 쓰기가 느려서
    2. 복제가 비동기라 마스터 장애 시 복제본에 도달하지 못한 쓰기가 있을 수 있어서
    3. 메모리에 담을 수 있는 용량이 작아서
    4. 조인이나 집계 같은 쿼리를 지원하지 않아서
  6. maxmemory 를 물리 메모리보다 충분히 낮게 잡는 이유로 옳은 것은?

    1. OS 페이지 캐시를 위한 공간만 남기려고
    2. 축출을 자주 일으켜 오래된 키를 지우려고
    3. 성능 벤치마크 숫자를 좋게 만들려고
    4. 스냅샷과 복제, 클라이언트 버퍼가 쓸 여유가 필요해서