[업무일지] 컨슈머 6개에 스레드 5개, 조용히 멈춘 회수 배치
회수 배치가 에러도 경보도 없이 멈췄습니다. 원인을 공유 스레드풀 설정에서 찾았고, maxPoolSize 가 왜 처음부터 닿을 수 없는 값이었는지까지 짚었습니다.
회수 배치가 에러도 경보도 없이 멈췄습니다. 원인을 공유 스레드풀 설정에서 찾았고, maxPoolSize 가 왜 처음부터 닿을 수 없는 값이었는지까지 짚었습니다.
TTL 을 길게 잡으면 pod 가 죽을 때 락이 5시간 방치되고, 짧게 잡으면 작업 중간에 풀립니다. 이 딜레마를 Redisson Watchdog 으로 풀고 세 서비스의 락 구현을 하나로 합친 과정을 적었습니다.
활성 테이블 265개에서 12개를 추리고도 바로 DROP하지 않았습니다. RENAME과 2주 유예로 되돌릴 시간을 확보한 판단 기록입니다.
전각 공백 때문에 예금주명 검증이 틀리던 원인을 파다가, 정규화 결과가 빈 문자열이면 검증이 통째로 무력해진다는 걸 알았습니다.
레거시 Spring API를 정리하며 관리자 저장소까지 검색했지만, 수동 인벤토리에서 호출 하나가 빠졌습니다. 복구 뒤 사용 여부를 판단하는 범위를 다시 잡은 기록입니다.
같은 파일 참조 컬럼에 S3 URL과 객체 키, 인코딩된 값이 섞였습니다. 읽기 경계에서 객체 키로 수렴시키고 수정한 업로드 경로의 저장 형식을 고정한 기록입니다.