문서

데이터가 있었는데요, 아니 없어요

호선우 컬리 · 컬리 기술 블로그

AI 핵심 요약

회원 데이터가 Master DB에 저장되고 Slave DB에서도 조회되는데, Master의 다른 세션에서는 간헐적으로 보이지 않는 문제가 발생했다. 원인은 Replica Lag이 아니라 HikariCP의 auto-commit 비활성화, REPEATABLE READ의 MVCC 스냅샷, 그리고 OSIV와 하위 메서드의 트랜잭션 경계가 맞물려 기존 스냅샷이 유지된 것이었다. 팀은 격리 수준 변경이나 잠금 읽기의 부작용을 검토한 뒤, 바깥 조회 메서드에 @Transactional(readOnly = true)를 적용해 트랜잭션 종료 시 커밋으로 스냅샷을 갱신하도록 했다. 또한 auto-commit 비활성화로 트랜잭션 전후의 설정 쿼리를 줄여 응답 시간을 개선했으며, 이 설정을 사용할 때는 쿼리 메서드의 트랜잭션 적용과 커밋·롤백 로그를 확인해야 한다고 정리했다.

InnoDB의 REPEATABLE READ에서는 트랜잭션의 첫 일관 읽기 시점에 만들어진 스냅샷을 유지하므로, 다른 세션의 커밋만으로 기존 세션의 조회 결과가 최신화되지는 않는다.
HikariCP의 auto-commit을 false로 설정하면 트랜잭션 경계와 커밋·롤백 동작을 명시적으로 점검해야 하며, 커넥션 종료 시 미커밋 상태는 롤백될 수 있다.
Spring Data JPA에서 직접 정의한 쿼리 메서드는 기본 CRUD 메서드와 달리 자동으로 @Transactional이 적용되지 않을 수 있으므로 로그로 트랜잭션 적용 여부를 확인한다.
OSIV가 활성화되면 커넥션이 API 처리 동안 유지될 수 있어, 하위 메서드의 트랜잭션 설정이 스냅샷과 커넥션 동작에 미치는 영향을 함께 살펴야 한다.