MariaDB Aurora 모드에서 Snapshot 미갱신으로 인한 데이터 조회 실패 원인 분석

Master DB에 INSERT된 회원 데이터가 Slave DB에서는 조회되지만, Master DB의 다른 Session에서는 조회되지 않는 간헐적 오류가 발생했다. 초기에는 Replica Lag을 의심했으나, 디버깅 결과 쿼리가 Slave가 아닌 Master DB에서 실행되고 있었으며 실제 원인은 COMMIT 미실행이었다.

InnoDB의 MVCC(다중 버전 동시성 제어) 구조에서 REPEATABLE READ 격리 수준이 적용되면 트랜잭션 내 모든 읽기는 최초 읽기 시점의 Snapshot을 참조한다. autocommit=false 상태인 HikariCP 환경에서 개발자가 정의한 쿼리 메서드(findByMemberNo 등)에는 @Transactional이 자동 적용되지 않아 COMMIT이 발생하지 않았다. 이로 인해 Connection 종료 시 ROLLBACK이 실행되어 Snapshot이 갱신되는 것이 정상 동작이었다.

하지만 프로젝트에 jpa.open-in-view=true가 설정되어 있어 API 요청 전체 구간 동안 Connection이 유지되었다. 하위 메서드에 **@Transactional(readOnly=true)**가 적용되어 Slave DB로 라우팅된 경우, 해당 메서드 종료 시 COMMIT이 발생하여 Slave Session의 Snapshot은 갱신되었다. 반면 Master Session은 outerMethod에 @Transactional이 없어 COMMIT이 발생하지 않아 Snapshot이 갱신되지 않은 상태로 유지되었다.

결과적으로 Slave DB는 최신 데이터를 조회했지만, Master DB는 이전 Snapshot을 참조하여 신규 데이터를 보지 못하는 현상이 발생했다. 해결을 위해 READ COMMITTED 격리 수준 변경이나 Locking Read 사용이 검토되었으나, Phantom Read 위험과 락 경합 문제로 인해 제외되었다. 최종적으로 @Transactional(readOnly=true) 설정을 통해 매 요청 시 Snapshot을 갱신하거나, open-in-view 설정을 조정하여 트랜잭션 경계를 명확히 하는 방식으로 대응했다.