재시작할 때마다 WAL replay에서 오래 멈추면 데이터를 지우기 전에 같은 구간을 반복하는지 확인합니다. 프로세스가 살아 있지만 readiness가 아직 실패하는 경우와 OOM으로 죽어 처음부터 다시 시작하는 경우는 운영 판단이 다릅니다.
한 번의 시작을 시간 순서로 붙여 보기
프로세스 시작, WAL replay 시작·진행, readiness 변화, 종료 시각을 한 표에 기록합니다. 동시에 프로세스 RSS와 컨테이너 또는 cgroup의 메모리 제한·OOM 기록을 비교합니다. “readiness 실패 뒤 재시작”만 보이면 liveness나 supervisor가 살아 있는 복원을 중단시키는지 먼저 확인하세요. 메모리 수치를 올리는 조치는 그 다음 판단입니다.
promtool --version
promtool tsdb list --help
promtool tsdb analyze --help설치된 버전의 도움말부터 확인합니다. storage 문서의 WAL과 압축된 블록은 같은 자료가 아닙니다. promtool tsdb analyze의 블록 분석 결과만으로 현재 WAL의 모든 series나 replay 최고 메모리를 측정했다고 주장하면 안 됩니다. 큰 분석은 운영 1 GB 서버에서 복원과 동시에 실행하지 않습니다.
증거 조합에 따라 다음 행동을 고르기
진행 로그가 계속 늘고 종료가 없다면 복원 시간을 관찰합니다. 동일 구간에서 OOM 기록과 함께 종료되면 메모리 제한·동시 작업·최근 cardinality 증가를 조사합니다. 특정 손상 오류가 반복되면 먼저 백업·복사본을 확보하고 해당 버전의 복구 절차로 넘어갑니다. 세 경우 모두 WAL 삭제를 첫 조치로 사용할 근거는 없습니다.
복구 판단은 readiness뿐 아니라 새 scrape의 성공과 과거 시계열 조회까지 포함합니다. 이 글은 자료별로 무엇을 알 수 있는지 정리한 문서 분석이며, 특정 용량·복원 시간이나 실서비스 복구 성공을 측정하지 않았습니다.