Database Transaction Isolation Level

[su3inni]

존재하는 회원 데이터가 조회되지 않는 문제

• Master DB : insert #session1
• Slave DB : select
• Master DB : select #session2 [ 불가능 ]

  회원 서비스에서 데이터를 insert하고 select 하는 것은 가능하지만 다른 멤버십 서비스에서 데이터를 select 할 때 에러 발생하는 상황

0-1. 확인해야할 설정

• DB 의 모드
• JDBC 커넥션풀 확인 ex. Hikari
  • hikari.auto-commit 설정
• JPA(Java Persistence API) 설정 확인
  • jpa.open-in-view 설정

0-2. 발생 가능한 현상

• Replica Lag Slave DB가 Master DB에서 발생하는 업데이트를 따라잡을 수 없을 때 발생하는 현상
  • 적용되지 않은 변경 사항은 Slave DB의 릴레이 로그에 누적

1. 문제가 발생한 부분

• outerMethod() 의 @Transactional 설정과
• innerMethod()의 @Transactional(readOnly=true) 설정이 다른 점

1-1. 원인

• COMMIT 이 실행되지 않음
  • hikari.auto-commit 설정이 false로 되어있는 경우 COMMIT이 반드시 실행되어야한다.
  • 개발자가 명시적으로 실행하거나, @Transactional 을 사용해서 COMMIT 혹은 ROLLBACK할 수 있도록 한다.

COMMIT이 실행되지 않으면, Consistent Nonlocking Reads로 인해 Snapshot이 갱신되지 않아 최초 쿼리 실행시점 이후에 실행된 트랜잭션의 변경사항을 확인하지 못하는 문제가 발생한다.

1-2. Consistent Nonlocking Reads?

• InnoDB가 특정 시점의 데이터베이스 snapshot을 쿼리에 제공하기 위해 MVCC를 사용하는 것을 의미한다.

• 트랜잭션 격리 수준 기본값인 REPEATABLE READ일 경우, 같은 트랜잭션 내의 모든 일관된 읽기는 처음 읽기를 수행한 시점의 Snapshot을 읽는다.

  • 현재 트랜잭션을 커밋한 후 새로운 쿼리를 실행하면 최신의 snapshot을 얻을 수 있다.

2. 해결 방법

2-1. READ COMMITTED 격리 수준으로 낮추기

• READ COMMITTED 격리 수준에서는 각 select 명령어가 별도의 snapshot을 사용한다.
  • 단, 격리수준을 낮추는 경우 Phantom Read 이슈가 발생하기 때문에 주의해야한다.

2-2. 잠금읽기 사용하기

• Locking Read를 사용하면 InnoDB는 Snapshot이 안라 테이블의 최신 데이터를 읽는다.
  • 데이터의 일관성을 유지하기 위해
  • select 명령어가 실행될 때 해당 행을 잠그고, 다른 트랜잭션이 그 행을 수정하거나 삭제하지 못해서 락 경합 및 데드락 발생 가능성이 증가하는 이슈 발생할 수 있다.

2-3. Transactional(readOnly=true)설정 추가하기

• 메서드가 종료될 때 COMMIT을 통해 Snapshot을 갱신하는 방법을 사용한다.
• 매 요청마다 테이블의 최신 데이터가 포함된 Snapshot 기준으로 데이터를 조회하여 존재하는 데이터를 정상적으로 조회할 수 있다.

3. 확인하면 좋은 개념

• Spring Data JPA의 기본 메서드 @Transactional
• HikariCP의 Connection 종료시 COMMIT 여부
• 데이터베이스의 snapshot 사용 방법

[su3inni]

Reference

https://helloworld.kurly.com/blog/commit-mvcc-set-autocommit/