리더와 동기화가 유지되고 있는 복제본 집합(In-Sync Replicas).
Kafka의 복제 구조
각 파티션은 리더 1개와 팔로워 여러 개로 이루어진다.
파티션 0
├── 리더 (브로커 1) ← 읽기·쓰기는 전부 여기로
├── 팔로워1 (브로커 2) ← 리더를 따라가며 복사
└── 팔로워2 (브로커 3)
팔로워는 리더에게 계속 "다음 데이터 줘"라고 요청하며 따라간다(pull 방식).
ISR에서 빠지는 조건
replica.lag.time.max.ms(기본 30초) 안에 리더를 따라잡지 못하면 ISR에서 제외된다.
느린 팔로워 때문에 전체 쓰기가 막히는 것을 막기 위해서다. 다시 따라잡으면 복귀한다.
acks 설정과 짝을 이룬다
프로듀서의 acks는 "몇 군데 기록되면 성공으로 볼 것인가"다.
acks | 응답 시점 | 유실 위험 | 속도 |
|---|---|---|---|
0 | 보내고 안 기다림 | 큼 | 가장 빠름 |
1 | 리더만 기록 | 리더가 죽으면 유실 | 중간 |
all(=-1) | ISR 전체 기록 | 가장 안전 | 가장 느림 |
min.insync.replicas — 함께 봐야 의미가 있다
acks=all만 걸면 함정이 있다.
복제본 3개 → 장애로 ISR이 리더 1개만 남음
- acks=all — → "ISR 전체" = 리더 하나 → 사실상 acks=1
- 그 리더가 죽으면 유실 ← 보장이 무너졌는데 모른다
그래서 min.insync.replicas=2를 함께 건다. ISR이 2개 미만이 되면
쓰기를 아예 거부(NotEnoughReplicasException)해서 조용한 유실 대신 명시적 실패를 택한다.
실무 표준 조합
replication.factor = 3 min.insync.replicas = 2 acks = all 브로커 1대가 죽어도 쓰기가 계속되고(2개 남음), 2대가 죽으면 멈춘다(유실보다 낫다).
unclean.leader.election
ISR에 아무도 없을 때 뒤처진 팔로워를 리더로 승격할 것인가를 정한다.
true면 서비스는 계속되지만 데이터가 유실된다. 기본값은 false(가용성보다 정합성).
이것도 CAP 선택의 한 예다.