DB LOCK

유튜브 채널 쉬운코드의 강의 영상을 공부하면서 작성한 게시글입니다.

키워드 : lock, deadlock, 2PL, conservative 2PL, strict 2PL, strong strict 2PL, MVCC, postgresql

---

LOCK

데이터마다 lock있어서 변경하거나 읽으려면 lock을 취득해야하고 취득하지 못하면 기다려야하도록 만들어주는 장치.

OS의 Lock과 비슷하다.

 

write_lock (exclusive): 다른 트랜잭션이 같은 데이터를 read/write 하는걸 허용 안함. write할때만 쓰는건 아님.

read_lock (shared lock): 다른 트랜잭션이 같은 데이터를 read하는 것은 허용.

 

락을 사용하는것 만으로는 트랜잭션의 이상현상을 완전히 방지할 수 없다.

예시

x = 100, y = 200

1. x와 y합 구해서 x에 저장
2. x와 y합 구해서 y에 저장

1 -> 2 순서로 작동하면 x = 300, y = 500

2 -> 1 순서로 작동하면 x = 400, y = 300

 

그런데 동시에 작동하면 아래와 같은 이상현상이 발생할 수 있다.

두 serial schedule에서는 나오지 않았던 300, 300 값이 저장되어버린다. Nonserializable!!

이걸 해결하려면  트랜잭션2의 unlock(x)와 write_lock(y)의 순서만 바꿔주면 된다. 그러면 2 -> 1 serial schedule과 같은 결과가 도출된다. 마찬가지로 T1에서도 unlock(y)와 write_lock(x) 순서를 바꿔주면 1 ->2 serial schedule도 해결된다.

2PL protocol

여기서 lock 관련 부분만 뜯어서 보면 이렇다.

각 트랜잭션에서 모든 lock은 최초의 unlock보다 먼저 수행되도록 구성됐다.

 

이런 식으로 트랜잭션이 lock을 취득하는 단계와 반환하는 단계를 명확히 나누는 동시성 제어 규칙을 2PL protocol(two-phase locking) 이라고 한다. lock을 취득만 하는 phase, lock을 반환만 하는 phase로 나뉘어서 2 phase 인것.

2PL protocol 은 Serializability를 보장한다. 

 

그런데 어떤 경우에는 데드락에 걸릴 수 있다.

서로의 x, y의 read_lock때문에 write_lock이 걸린 상태에서 빠져나올 수 없다.

이 데드락의 해결 방식은 OS 의 데드락 해결 방식과 같다.

 

2PL의 종류

• conservative 2PL

모든 lock을 취득한 뒤에 트랜잭션 시작.

deadlock-free

실용적이진 않음 - 모든락을 취득하기 어려우면 트랜잭션 실행자체가 어렵기 때문

• strict 2PL (S2PL)

strict schedule을 보장하는2PL

recoverability 보장

write-lock을 commit/rollback 될 때 반환

데드락은 발생 가능함

• strong strict 2PL (SS2PL or rigorous 2PL)

strict schedule을 보장하는2PL

recoverability 보장

모든 lock을 commit/rollback 될 때 반환 - read lock을 오래 잡고있는 문제가 있다

S2PL보다 구현이 쉽다

데드락은 발생 가능함

MVCC (Multi Version Concurrency Control)

그런데 Lock은 read-read lock을 제외하고 모두 서로를 block하니 처리량이 좋지 않다.

이것을 해결하기 위해 MVCC가 나왔다. MVCC는 write 작업과 read작업도 서로 block 하지 않는다.

많은 RDBMS가 LOCK과 MVCC를 혼용해서 사용한다고 한다.

 

postgreSQL 에서의 Lock

postgresql은 기본적으로 MVCC를 사용한다. CRUD같은 일반적인 쿼리는 내부적으로 적절한 lock을 걸어준다.