목표
트랜잭션을 쉽게 접근했을 때는 여러 처리에 대해 일관적이고 정확하게 반영시켜주는 수단으만 생각할 수 있다. 그럼으로서 데이터가 안전하게 지켜진다는 느낌에 안주하게 된다.
이번 포스트는 MySQL이 데이터 정합성을 이룬 방법을 이해하고, 트랜잭션을 알고 정확하게 사용하고자 한다.
요구 사항
문제 상황을 예시로 가져왔다.
S3 업로드와 업로드 정보(AttachFile) 생성의 트랜잭션을 분리하였다. I/O 작업 이후에 롤백이 발생하더라도 오브젝트 삭제를 위한 정보는 온전하게 남기기 위한 이유였다.
하지만 Commit된 데이터인 AttachFile이 트랜잭션 A에서 조회되지 않았다.
격리 수준
격리 수준별 부정합 문제점😓
MySQL은 Repeatable Read의 격리 수준을 사용하고 InnoDB 엔진을 사용함에 따라 Phantom Read 문제 또한 해결했다.
- Consistent Nonlocking Reads 방식 사용
- 명시적으로 Locking Read를 사용하도록
SELECT ... FOR SHARE,SELECT ... FOR UPDATE구문 제공
Phantom Read
먼저 Repeatable Read의 문제가 되는 Phantom Read의 발생 시점을 확인해보자.
하나의 트랜잭션 내에서 같은 쿼리를 두 번 실행 시, 첫 번째 쿼리에서 없던 레코드가 두 번째 쿼리에서 발생하는 현상
MySQL에서는 트랜잭션마다 트랜잭션 ID를 부여하여 트랜잭션 ID보다 작은 트랜잭션 번호에서 변경한 것만 읽게 되고, 자신의 트랜잭션 번호보다 높은 트랜잭션에서 변경된 것은 UNDO 영역에 백업된 레코드를 읽게 된다.
즉, 트랜잭션 ID만 낮다면 부정합 문제가 발생할 수 있다.
또한 앞서 구현했던 로직은 Phantom Read가 발생하길 기대한 것과 다름이 없었다. Wrong!
Consistent Read
트랜잭션의 4가지 특징 중 하나는 일관성(Consistency)이다. InnoDB 엔진은 일관성을 위해 어떤 것을 보완하여 문제를 해결했을까?
Consistent Snapshot
트랜잭션이 열리는 특정 시점의 스냅샷을 생성한다. 이후 트랜잭션 내에서 필요한 데이터는 해당 스냅샷을 기준 조회해서 가져온다.
그럼 Snapshot 생성 시점은 언제?
start transaction시점에 생성되는 것이 아니다!- 스냅샷은 트랜잭션이 열린 후 최초의 조회 쿼리가 발생할 때 생성된다.
MySQL Reference - InnoDB Consistent Read
해결?
MySQL에서는 Consistent Read는 아래와 같은 문제가 발생할 수 있다고 한다.
Update, Delete 쿼리의 경우 이미 커밋된 데이터에 대해서 실행될 수 있다.
UPDATE
SELECT COUNT(c2) FROM t1 WHERE c2 = 'abc';
-- Returns 0: no rows match.
UPDATE t1 SET c2 = 'cba' WHERE c2 = 'abc';
-- Affects 10 rows: another txn just committed 10 rows with 'abc' values.
SELECT COUNT(c2) FROM t1 WHERE c2 = 'cba';
-- Returns 10: this txn can now see the rows it just updated.DELETE
SELECT COUNT(c1) FROM t1 WHERE c1 = 'xyz';
-- Returns 0: no rows match.
DELETE FROM t1 WHERE c1 = 'xyz';
-- Deletes several rows recently committed by other transaction.첫 번째 조회 쿼리에서 데이터가 확인되지 않더라도 실제로 수정, 삭제가 발생하는 데이터는 다를 수 있다. 변경 쿼리 이후에는 조회된다.
즉, 스냅샷은 데이터 조회 시에만 영향이 있다는 것을 추측해볼 수 있다.
- 스냅샷 생성 시점
- 수정, 삭제는 스냅샷 데이터 변경 후 추가 반영이 아닌 데이터 블럭에 직접 접근
따봉