state.dir — 로컬 체크포인트 파일이 재시작을 빠르게 만든다
Kafka num.replica.fetchers 및 Kafka Streams state.dir 공식 문서·기술 블로그 종합 (웹 리서치, 2026) — Apache Kafka 공식문서(Broker Configs), Confluent 기술 블로그(RocksDB 성능 튜닝) Kafka Streams RocksDB 관련 기술 블로그 종합
이 모듈을 다 읽으면
- state.dir이 kafka-learn-37에서 다룬 RocksDB+changelog 조합의 로컬 저장 위치라는 것을 설명할 수 있다
- 체크포인트 파일이 있을 때와 없을 때(디스크 유실 시) 재시작 복구 방식이 어떻게 달라지는지 설명할 수 있다
kafka-learn-37에서 다룬 Kafka Streams 상태 저장소(RocksDB로 로컬 캐싱하고 changelog 토픽으로 내구성을 보장하는 조합)를 전제로, 그 RocksDB 파일이 실제로 어디에 저장되고, 재시작 시 어떤 파일이 복구 속도를 좌우하는지를 정리한다.
state.dir — 애플리케이션 ID별 서브디렉터리에 RocksDB 파일이 쌓인다
Kafka Streams는 kafka-learn-37에서 다룬 로컬 상태를 state.dir 설정이 가리키는 경로 아래에 저장한다 — 그 안에 애플리케이션 ID 이름의 서브디렉터리가 만들어지고, 그 안에 RocksDB의 실제 데이터 파일들이 쌓인다. 즉 state.dir은 '이 인스턴스가 로컬 캐시로 쓰는 디스크 공간이 정확히 어디인지'를 가리키는 설정이다.
핵심 포인트
- state.dir 아래에 애플리케이션 ID 이름의 서브디렉터리가 생성되고, 그 안에 RocksDB 데이터 파일이 저장됨
- state.dir = kafka-learn-37에서 다룬 로컬 상태(RocksDB) 캐시가 실제로 저장되는 디스크 위치
로컬 체크포인트 파일 — 디스크가 살아있으면 changelog 전체를 다시 읽을 필요가 없다
kafka-learn-37에서 다룬 것처럼 changelog 토픽은 상태 저장소의 내구성 보장책이라 로컬 RocksDB가 통째로 사라져도 changelog로부터 처음부터 복원할 수 있다 — 다만 이건 시간이 걸리는 작업이다. Kafka Streams는 이 복구를 가속하기 위해, 마지막으로 처리한 오프셋을 state.dir 안의 로컬 체크포인트 파일에 기록해둔다. 재시작할 때 이 체크포인트 파일과 RocksDB 데이터가 그대로(디스크 유실 없이) 남아있으면, changelog 전체를 처음부터 다시 재생할 필요 없이 그 체크포인트 지점부터 이어서 빠르게 복구할 수 있다 — 반대로 디스크(state.dir) 자체가 사라진 인스턴스 교체 상황에서는 이 지름길이 없어 changelog 전체 재생이 불가피하다.
핵심 포인트
- state.dir 안의 로컬 체크포인트 파일에 마지막 처리 오프셋을 기록 — 재시작 시 RocksDB+체크포인트가 그대로 남아있으면 changelog 전체 재생 없이 그 지점부터 빠르게 복구
- 디스크(state.dir) 자체가 사라진 인스턴스 교체 상황에서는 이 지름길이 없어 changelog 전체 재생이 불가피(kafka-learn-37의 근본 내구성 보장책으로 되돌아감)