测验：持久化

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

• 유실 없음
• 약 1분어치
• 마지막 스냅샷 이후 전부
• 약 1초어치

RDB 단독 방식의 가장 큰 약점은?

• 마지막 스냅샷 이후의 쓰기를 전부 잃는다
• AOF 보다 복구가 느리다
• 파일 크기가 AOF 보다 크다
• 복제본으로 전파되지 않는다

RDB 스냅샷 중 메모리가 순간적으로 크게 늘어나는 이유는?

• 스냅샷을 압축하며 버퍼를 크게 잡아서
• AOF 리라이트와 시점이 겹치기 때문
• 복제본으로 보낼 네트워크 버퍼 때문
• fork 뒤 copy-on-write 로 페이지가 복제되기 때문

혼합 모드(RDB 프리앰블 + AOF)를 쓰는 이유는?

• 복구는 RDB 처럼 빠르면서 유실 구간은 AOF 처럼 1초로 유지하려고
• AOF 파일이 작아져 디스크를 아끼려고
• 복제본이 스냅샷을 그대로 받게 하려고
• 리라이트 중 메모리 사용을 줄이려고

'절대 잃으면 안 되는' 데이터의 1차 저장소로 Redis 가 부적절한 주된 이유는?

• 디스크에 매번 기록해 읽기와 쓰기가 느려서
• 복제가 비동기라 마스터 장애 시 복제본에 도달하지 못한 쓰기가 있을 수 있어서
• 메모리에 담을 수 있는 용량이 작아서
• 조인이나 집계 같은 쿼리를 지원하지 않아서

maxmemory 를 물리 메모리보다 충분히 낮게 잡는 이유로 옳은 것은?

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