Aurora MySQL의 숨겨진 idle close 동작 — HikariCP "Failed to validate connection" 추적기
4
AI 요약
이 글은 AI가 원문을 분석하여 핵심 내용을 요약한 것입니다.
이 게시물은 HikariCP의 “HikariPool - Failed to validate connection” WARN 로그 원인을 추적하다 Aurora MySQL의 비표준 idle close 동작을 발견한 내용이다.
keepaliveTime(30초)으로도 validate 시점에 “connection closed 이후 작업 불가” 예외가 발생해 server의 idle 종료가 더 빠를 가능성을 확인한다.
표준 MySQL 모델 가설로 설정 적용 여부, pool size 영향, JDBC non-interactive 기준 interactive_timeout 무관성 등을 검증했으며 interactive_timeout을 올리자 WARN이 즉시 멈춰 원인 변수가 interactive_timeout임을 확인한다.
하지만 JDBC는 non-interactive로 연결되는 것으로 확인되어 모순이 생겼고, Aurora MySQL은 non-interactive에서도 wait_timeout과 interactive_timeout을 모두 평가해 둘 중 작은 값(min)이 effective idle timeout으로 동작한다.
따라서 wait_timeout(120초)보다 interactive_timeout(20초)이 먼저 적용되어 30초 keepalive 전에 close되고, 결과적으로 HikariCP validate 실패 로그가 분당 다수 누적되는 흐름을 설명한다.
Aurora는 thread-pool + monitor thread 구조로 idle 연결을 주기적으로 검사하며, 기본 검사 주기(약 60초) 영향으로 타이밍에 따라 발생 패턴이 들쭉날쭉할 수 있음을 정리한다.
