트랜잭션이란?
데이터베이스의 상태를 변화시키기 위해 수행하는 작업 단위
트랜잭션의 특징
Atomicity - 원자성
트랜잭션이 DB에 모두 반영되거나, 혹은 전혀 반영되지 않아야 한다.
Consistency - 일관성
트랜잭션의 작업 처리 결과는 항상 일관성 있어야 한다.
Isolation - 독립성
둘 이상의 트랜잭션이 동시에 병행 실행되고 있을 때, 어떤 트랜잭션도 다른 트랜잭션 연산에 끼어들 수 없다.
Durability - 지속성
트랜잭션이 성공적으로 완료되었으면, 결과는 영구적으로 반영되어야 한다.
commit
하나의 트랜잭션이 성공적으로 끝났고, DB가 일관성 있는 상태일 때 이를 알려주기 위해 사용하는 연산
Rollback
하나의 트랜잭션 처리가 비정상적으로 처리되어 트랜잭션의 원자성이 깨진 경우
transaction의 시작 상태로 rollback할 수 있다.
isolation level
Read Uncommited
각 트랜잭션의 내용이 commit이나 rollback과 상관 없이 다른 트랜잭션에 보여진다.
이러한 경우 dirty read의 문제가 발생한다.
dirty read
- 트랜잭션 A가 데이터 D를 넣었다.
- 트랜잭션 B가 데이터 D를 읽었다.
- 트랜잭션 A가 어떠한 오류로 인해 rollback이 된다.
- 데이터 D는 rollback되어 사라진다.
- 하지만 트랜잭션 B는 이 사실을 모른 채 동작한다.
Read Commited
어떠한 트랜잭션에서 데이터를 변경하더라도 Commit이 완료된 데이터만 다른 트랜잭션에서 조회할 수 있다.
이는 UNDO영역으로 가능하다.
UNDO
한 트랜잭션이 데이터 D의 내용을 1에서 2로 변경한다고 생각하자.
데이터베이스에 데이터 D의 내용은 2로 저장되며, 이전 값은 Undo 영역으로 백업된다.
다른 트랜잭션에서 데이터 D를 조회하면, 이 값은 Undo 영역에서 가져와 1을 반환한다.
이는 rollback에서도 사용한다.
이러한 경우 non-repeatable read의 문제가 발생한다.
non-repeatable read
- 트랜잭션 A가 데이터 D를 조회하지만 존재하지 않아 결과를 리턴하지 않는다.
- 트랜잭션 B가 데이터 D를 insert 한다.
- 트랜잭션 B가 commit 한다.
- 트랜잭션 A가 데이터 D를 다시 조회하면 데이터 D가 반한된다.
이는 같은 트랜잭션 안에서(트랜잭션 B) 동일한 select 쿼리를 실행시켰을 때 항상 같은 결과를 보장해야 한다는 repeatable read 정합성에 어긋난다.
Repeatable Read
InnoDB 스토리지 엔진은 MVCC를 이용하여 repeatable read 정합성을 보장한다.
MVCC
multi version concurrency control
서로 다른 세션이 동일한 데이터에 접근했을 때 각 세션마다 스냅샷 이미지를 보장해주는 메커니즘.
모든 InnoDB의 트랜잭션은 고유한 트랜잭션 번호를 가지며, 언두 영역에 백업된 모든 레코드에는 변경을 발생시킨 트랜잭션의 번호가 포함된다.
MVCC를 보장하기 위해 트랜잭션 가운데 가장 오래된 트랜잭션 번호보다 트랜잭션 번호가 앞선 언두 영역의 데이터는 삭제할 수 없다.
이러한 경우 phantom read가 발생할 수 있다.
하지만 InnoDB의 경우 snapshot을 이용하여 이를 방지한다.
phantom read
하나의 트랜잭션 안에서 조회하는 쿼리의 결과가 다른 것.
외부에 동시에 실행중인 트랜잭션의 Insert 작업에 의해 발생하는 read 현상.
Serializable
가장 엄격하고 단순한 격리 수준.
한 트랜잭션에서 읽고 쓰는 레코드를 다른 트랜잭션에서는 절대 접근할 수 없다.
동시 처리 성능이 다른 격리 수준보다 현저히 떨어진다.
Buffer
Undo
commit 되지 않은 트랜잭션이 rollback될 경우 해당 트랜잭션이 변경한 페이지들을 원상복구되어야 한다.
만약, 한 트랜잭션이 변경한 내용을 디스크에 저장하기 전이라면, 메모리 버퍼에 대해서만 처리하면 된다.
STEAL
STEAL 정책은 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책이다.
해당 정책을 채택하면 메모리의 내용을 복구하여 디스크에 저장해야 하므로, UNDO 버퍼가 필수이다.
REDO
커밋한 트랜잭션의 수정은 어떠한 경우에도 유지되어야 한다.
이미 커밋한 트랜잭션의 수정을 재반영하는 복구 작업을 REDO 복구라고 한다.
FORCE
FORCE 정책은 수정했던 모든 페이지를 커밋 시점에 디스크에 반영하는 정책이다.
이를 채택하면 commit 시에 디스크에 반영되므로, REDO 복구가 필요 없게 된다.(일반적인 경우)
하지만 대부분의 경우 FORCE 정책을 채택하지 않아 REDO 버퍼가 필요하다.
복구
장애 이후 데이터베이스가 복구되는 경우 3단계를 거친다.
로그 분석
마지막 체크포인트로부터 최근 로그까지 로그를 탐색하면서 어디서부터 시스템이 복구를 시작해야 하는지 알아낸다.
REDO 복구 단계
장애 발생 직전 시점까지 REDO가 필요한 모든 로그를 REDO복구를 한다.
-> 장애 발생 시점의 상태와 같게 된다.
UNDO 복구 단계
로그를 최신 시점으로부터 다시 역방향으로 탐색하면서 UNDO복구가 필요한 로그들에 대해서 UNDO 복구를 수행한다.
Lock
Pessimistic lock
비관적 lock. 다른 사용자들이 동시에 사용할 것이라고 가정.
shared lock
읽고자 하는 raw에 lock이 걸려 있을 때, 읽기는 가능한 방식
Exclusive lock
읽기조차 불가능 한 방식
Optimistic lock
낙관적 lock. 다른 사용자들이 동시에 사용하지 않을 것이라 가정.
version 파일을 제공해서, 수정을 방지함.
수정 시에 값이 변경되었는지 검사.
참고 자료
