Cluster Settings — transient는 재시작하면 사라진다
Elasticsearch Snapshot Repository 및 Cluster Settings API 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(snapshots-register-repository, cluster-put-settings, deploy-manage/stack-settings) Elastic 공식문서 Update the cluster settings, Elastic Stack settings
이 모듈을 다 읽으면
- persistent와 transient 설정의 차이(재시작 후 유지 여부)를 설명할 수 있다
- 왜 공식 문서가 transient 대신 persistent를 권장하는지 설명할 수 있다
elasticsearch-learn-30(샤드 할당 필터링)이나 elasticsearch-learn-37(Allocation Awareness) 같은 클러스터 설정을 동적으로 바꿀 때 쓰는 Cluster Settings API의 두 가지 적용 방식과, 그중 하나를 왜 피해야 하는지를 정리한다.
persistent vs transient — 재시작 이후에도 남는가
Cluster Settings API로 설정을 바꿀 때 persistent로 적용하면 클러스터를 재시작해도 그 설정이 그대로 유지되고, transient로 적용하면 클러스터가 재시작되는 순간 초기화(리셋)된다. 같은 설정을 여러 방식으로 동시에 지정했을 때의 우선순위는 transient > persistent > elasticsearch.yml > 기본값 순이다 — 즉 transient가 임시로 다른 설정들을 덮어쓰는 용도로 쓰일 수 있다는 뜻이기도 하다.
핵심 포인트
- persistent: 클러스터 재시작 후에도 유지 / transient: 클러스터 재시작 시 초기화
- 동시 지정 시 우선순위: transient > persistent > elasticsearch.yml > 기본값
왜 transient를 더 이상 권장하지 않는가
공식 문서는 transient 클러스터 설정을 더 이상 권장하지 않고 persistent를 쓰라고 명시한다 — 클러스터가 불안정해지면 transient 설정이 예상치 못하게 사라져 의도치 않은 클러스터 구성 상태로 되돌아갈 수 있기 때문이다. 즉 사용자가 명시적으로 재시작한 게 아닌, 노드 장애나 클러스터 불안정으로 인한 재시작 상황에서도 transient 설정은 조용히 초기화될 수 있다는 예측 불가능성이 문제다 — '분명히 설정했는데 왜 다시 기본값으로 돌아갔지'라는 흔한 운영 함정의 원인이 바로 이것이다.
핵심 포인트
- 클러스터가 불안정해져 (사용자가 의도하지 않은) 재시작이 일어나면 transient 설정이 예상치 못하게 사라짐 — 이 예측 불가능성 때문에 공식적으로 비권장
- '설정했는데 다시 기본값으로 돌아갔다'는 흔한 운영 함정의 원인 — persistent로 적용해야 이런 사고를 피할 수 있음