목록 보기
데이터가 있었는데요, 아니 없어요
백엔드

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

마켓컬리
마켓컬리
2024년 6월 13일

두줄요약

회원 조회가 간헐적으로 실패하던 원인을 COMMIT, MVCC, autocommit 설정 관점에서 분석했습니다. `@Transactional(readOnly = true)`와 open-in-view 영향까지 확인해 조회 흐름을 정리했습니다.

문제 상황

  • Master DB에 INSERT된 회원 데이터가 같은 서비스 흐름에서 간헐적으로 조회되지 않는 현상
  • 다시 요청하면 조회되는 비정상적 반복 패턴
  • Master/Slave 조회, COMMIT 누락, open-in-view, readOnly 트랜잭션 설정이 얽힌 복합 이슈

원인 분석

  • Replica Lag이 아니라 Master DB에서 실행된 조회가 COMMIT 없이 종료되며 오래된 Snapshot을 유지한 점
  • hikari.auto-commit: false와 @Transactional 부재로 인해 쿼리 종료 시 COMMIT 대신 ROLLBACK이 발생한 점
  • open-in-view: true와 하위 @Transactional(readOnly = true) 조합으로 Snapshot 갱신이 기대와 다르게 동작한 점

해결 방법

  • 조회 경로에 @Transactional(readOnly = true)를 명시해 메서드 종료 시 COMMIT이 발생하도록 조정
  • 전체 조회 흐름을 Slave DB에서 일관되게 실행되도록 트랜잭션 경계 재정의
  • READ COMMITTED, 잠금 읽기 등 대안은 사이드 이펙트와 락 경합 가능성 때문에 제외

다음 읽기

#transaction 주제를 다룬 다른 회사 글

실무에서 만나는 DB isolation level

MySQL 기본 격리 수준인 REPEATABLE READ 때문에 결제 트랜잭션에서 오래된 잔액이 유지되는 문제를 겪었습니다. 락 위치와 격리 수준을 조정해 동시성 이슈를 해결하는 과정을 정리했습니다.

네이버 페이
네이버 페이
백엔드

댓글 0개

댓글을 작성하려면 로그인이 필요합니다.

댓글을 불러오는 중...