llm-wiki/raw/official-docs/redis-replication-asynchronous-read-routing.md

---
title: "official-doc / Redis Replication — Asynchronous Propagation, Stale Reads, WAIT Semantics"
source_type: official-doc
url: https://redis.io/docs/latest/operate/oss_and_stack/management/replication/
archive_url:
related_branches: [feature-redis-runtime-role-isolation-contract]
related_projects: [ca-skeleton]
tags: [official-doc, ca-skeleton, persistence, redis, replication]
created: 2026-07-28
---

# official-doc / Redis Replication — Asynchronous Propagation, Stale Reads, WAIT Semantics

> Layer: `raw/` — 외부 자료(공식 문서)의 **원문 발췌·출처 기록**.
> 본 문서는 Redis 공식 replication 문서 원문 발췌. 검증된 요약은 `/ingest` 후 `wiki/concepts/`에 별도 작성.

## source_type 허용값

- `official-doc` — Redis 공식 레퍼런스 (redis.io/docs)

## Parent / 활용 branch

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-redis-runtime-role-isolation-contract]] | coordination/session/idempotency/lease/rate role 은 primary read 만 쓰고 stale 을 허용하는 cache region 만 replica read 를 opt-in 한다는 read routing 결정의 근거 |

## 출처

- 원본 URL: https://redis.io/docs/latest/operate/oss_and_stack/management/replication/
- 아카이브 URL: (미등록)
- 저자 / 조직: Redis (공식 문서, redis.io/docs)
- 발행일: (문서 내 명시 없음 — "latest" 채널 문서, 버전 미고정)
- 마지막 확인일: 2026-07-28

## 왜 저장했는지

Redis 는 기본적으로 비동기(asynchronous) replication 을 쓰고, replica 는 stale 데이터를 반환할 수 있으며, `WAIT` 명령조차 strong consistency(CP)를 보장하지 않는다는 공식 근거. coordination/session/idempotency/lease/rate 처럼 정확성이 중요한 role 은 replica read 를 쓰면 안 되고 primary read 만 써야 한다는 role-isolation 결정을 뒷받침한다.

## 핵심 인용

> [§Important facts about Redis replication] "Redis uses asynchronous replication, with asynchronous replica-to-master acknowledges of the amount of data processed."

> [§Important facts about Redis replication] "While the replica is performing the initial synchronization, it can handle queries using the old version of the dataset, assuming you configured Redis to do so in redis.conf."

> [§Allow writes only with N attached replicas] "However, because Redis uses asynchronous replication it is not possible to ensure the replica actually received a given write, so there is always a window for data loss."

> [§Read-only replica] "Since Redis 2.6, replicas support a read-only mode that is enabled by default."

> [intro, before §Important facts — WAIT 명령 관련, 원문은 `WAIT` 를 `/commands/wait` 로 하이퍼링크 처리함] "However `WAIT` is only able to ensure there are the specified number of acknowledged copies in the other Redis instances, it does not turn a set of Redis instances into a CP system with strong consistency: acknowledged writes can still be lost during a failover, depending on the exact configuration of the Redis persistence."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| REDIS-REPL-C1 | Redis 는 기본적으로 비동기 replication 을 쓰고, replica 는 master 에게 처리한 데이터 양을 비동기적으로 ack 한다 (master 는 매 command 마다 replica 응답을 기다리지 않음) | [§Important facts] "Redis uses asynchronous replication, with asynchronous replica-to-master acknowledges of the amount of data processed." | `official-vendor-doc` | Redis OSS/Stack 기본 replication 설정 전반 (master-replica) | Redis Cluster·Sentinel 이 이 기본 동작 위에 추가하는 failover 세부 동작까지 증명하지 않음(문서가 "이 문서는 기본 replication 특성만 다룬다"고 명시) |
| REDIS-REPL-C2 | replica 는 초기 동기화(initial synchronization) 중에도 설정에 따라 이전 버전의 데이터셋으로 쿼리를 처리할 수 있다 — 즉 replica read 는 stale 데이터를 반환할 수 있는 경로가 존재한다 | [§Important facts] "While the replica is performing the initial synchronization, it can handle queries using the old version of the dataset, assuming you configured Redis to do so in redis.conf." | `official-vendor-doc` | initial full sync 구간의 replica read 동작 | 정상 steady-state(sync 이후) replication lag 에 의한 stale read 크기(초/밀리초 단위)는 이 문장만으로는 정량화되지 않음 — 별도 latency 측정 필요 |
| REDIS-REPL-C3 | 비동기 replication 특성상 특정 write 가 replica 에 실제로 도달했는지 보장할 수 없고, 따라서 항상 data loss 가능 구간(window)이 존재한다 | [§Allow writes only with N attached replicas] "However, because Redis uses asynchronous replication it is not possible to ensure the replica actually received a given write, so there is always a window for data loss." | `official-vendor-doc` | master 장애/failover 시 최근 write 유실 가능성 일반 (min-replicas-to-write 설정 여부와 무관하게 근본 원인) | `min-replicas-to-write` 를 설정하면 이 window 가 "완전히 사라진다"는 뜻은 아님 — 문서는 이 설정도 "best effort" 라고 명시(별도 인용은 미등록, 같은 섹션 서술) |
| REDIS-REPL-C4 | Redis 2.6 이후 replica 는 기본적으로 read-only 모드다 | [§Read-only replica] "Since Redis 2.6, replicas support a read-only mode that is enabled by default." | `official-vendor-doc` | `replica-read-only` 설정을 명시적으로 바꾸지 않은 모든 Redis 2.6+ replica | writable replica 로 전환 가능하다는 사실 자체가 그것이 권장된다는 뜻은 아님(문서는 반대로 "writable replica 는 권장하지 않는다"고 별도 서술) |
| REDIS-REPL-C5 | `WAIT` 명령은 지정한 수의 replica 에 acknowledge 된 복사본이 있음을 보장할 뿐, Redis 인스턴스 집합을 strong consistency 를 갖는 CP 시스템으로 만들지 않는다 — ack 된 write 도 failover 중 유실될 수 있다 | [intro] "it does not turn a set of Redis instances into a CP system with strong consistency: acknowledged writes can still be lost during a failover, depending on the exact configuration of the Redis persistence." | `official-vendor-doc` | `WAIT` 를 사용하는 준-동기(quasi-synchronous) write 패턴 전반 | `WAIT` 가 무의미하다는 뜻은 아님 — 문서는 이어서 "WAIT dramatically reduces the probability of losing a write" 라고 명시. 즉 "손실 확률을 낮추지만 0으로 만들지 않는다"가 정확한 범위 |

### Strength 허용값 참고

전부 `official-vendor-doc` — Redis 공식 문서(redis.io/docs)이며 벤더가 직접 발행. `company-case-study` 아님(회사 사례가 아니라 제품 자체의 공식 동작 명세).

## Usage Boundaries / 적용 경계

- 이 자료가 직접 증명하는 것:
  - `REDIS-REPL-C1`~`C5`: Redis 기본 replication 이 비동기이고, replica read 는 stale 을 반환할 수 있으며, `WAIT` 조차 acknowledged write 의 failover 유실을 완전히 막지 못한다는 것. 이는 "정확성이 중요한 role(coordination/session/idempotency/lease/rate) 은 replica read 를 쓰면 안 된다"는 branch 결정의 **일반 원리 근거**로 충분하다.
- 이 자료가 증명하지 않는 것:
  - ca-skeleton 이 실제로 어떤 Redis 배포 토폴로지(managed service, Sentinel, Cluster 등)를 쓰는지 — 이 문서는 "basic replication" 만 다루고 Cluster/Sentinel 세부는 별도 문서로 위임한다고 명시.
  - stale read 의 정량적 크기(수 ms vs 수 초) — 배포·네트워크 환경에 의존, 이 문서만으로 SLA 수치를 도출할 수 없음.
  - cache region 에 replica read 를 opt-in 했을 때 실제 애플리케이션 정확성에 문제가 없다는 것 — 그건 ca-skeleton 이 cache region 을 "stale 허용" 으로 설계했다는 branch-local 결정이지, 이 문서가 그 설계를 승인하는 것이 아님.
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  - ca-skeleton 이 사용할 실제 Redis 배포(managed / self-hosted, Sentinel 유무)에서 replication lag 실측치
  - `replica-read-only`, `min-replicas-to-write`, `min-replicas-max-lag` 등 세부 설정값이 branch 구현 가이드에 실제로 반영되는지

## 메모

- REDIS-REPL-C3 는 `min-replicas-to-write` best-effort 서술과 함께 읽으면 "설정을 켜도 window 를 줄일 뿐 제거하지 못한다"는 뉘앙스가 더 명확해짐 — 필요하면 해당 서술도 별도 인용으로 추가 가능(미검증 상태로 남겨둠).
- 추가로 봐야 할 동일 출처 페이지: Redis Sentinel 문서(failover 세부), Redis Cluster 문서(샤딩된 환경에서의 replication) — 이 문서는 두 문서로 위임하고 있음.

## Related

- 같은 주제 다른 official-doc: `[[raw/official-docs/redis-lua-api-determinism-replication]]` (Lua effects replication — 다른 주제, replication 메커니즘의 다른 단면)
- 이 자료를 인용한 wiki 요약: (생성 시 추가)