2 minute read

트랜잭션

데이터베이스상에서 더이상 쪼갤수 없는 작업의 단위

ACID (트랜잭션의 4가지 속성)

  • atomic (원자성): 트랜잭션 단위는 모두 실행 되거나 모두 실행되지 않거나 둘중 하나다. (커밋과 롤백, undo log)
  • consistancy (일관성): 여러 클라이언트에서 어떤 데이터에 동시에 접근 할때 동일한 버전을 제공하거나 동일한 규칙을 적용해야 한다. (MVCC, 클라이언트의 도움, 제약조건)
  • isolation (고립): 동시에 데이터를 수정할수 있는 트랜잭션의 수는 1개이다. (락)
  • durability (영속성): 트랜잭션이 한번 반영되면 해당 기록은 영구적이어야 한다 (redo log)

UNDO 로그

트랜잭션 진행시 데이터의 수정이 발생하면, 바뀌기 전의 버전을 임시로 로그에 저장하여 롤백에 활용한다.

REDO 로그

트랜잭션 커밋시 수정된 데이터의 버전을 우선 로그에 저장하여 향후 스토리지 엔진에 반영할때 사용한다.

exclusive lock과 shared lock

exclusive lock는 exclusive lock, shared lock과 공유가 안되지만, shared lock은 shared lock과 공유가 된다. exclusive lock은 트랜잭션이 데이터를 수정(쓰기)할 때 사용되며 X 락이 설정되면 다른 트랜잭션은 동일한 데이터에 접근할 수 없다. 즉, 해당 데이터는 X 락이 해제될 때까지 다른 트랜잭션에 의해 읽기나 쓰기가 차단된다.

IX, IS lock (intention lock의 목적)

intention lock은 mysql 엔진에 거는 테이블 레벨의 락이고, X, S lock은 스토리지 엔진 레벨에 거는 컬럼 레벨의 lock으로 성능 최적화의 여지가 생긴다.

insertion intention lock

repeatable read 레벨에서 데이터 추가시 gap 락이 걸리게 된다. 이때 다른 트랜잭션에서 데이터 추가시 gap락때문에 진행이 안될수 있다. 이때 insert intention lock을 통해 데이터 추가에 한해서는 락으로 인한 대기없이 데이터를 추가할수 있게 도와준다.

데드락

여러 프로세스가 동시에 자원을 요구하면서 생기는 경합상태이다. 다음 4가지 상황이 모두 터지면 데드락이 발생한다.

  • 상호 배제(Mutual Exclusion) 한 번에 한 개의 프로세스만이 공유자원을 사용할 수 있음
  • 점유 대기(Hold and Wait) 자원을 점유하고 대기하는 상태
  • 비선점(No Preemption) 스케줄링 알고리즘이 할당된 자원을 뺏을수 없음
  • 순환 대기(Circular Wait) 서로 필요로 하는 자원을 점유하여 경합하는 상태

데이터베이스 에서의 데드락 예방, 회피, 해결

  • 낙관적 트랜잭션: lock없이 일단 트랜잭션 진행후 나중에 충돌여부 확인후 반영하거나 버림: 읽기 위주 작업에 유리
  • 트랜잭션진행시 필요로 하는 자원을 모두 lock을 걸고 진행: 병행성에 문제가 있음
  • 타임아웃
  • 데드락의 4가지 상황을 피해보기
  • 데드락 발생시 타임스탬프 순서대로 진행하기

트랜잭션 격리수준

  • uncomitted read: 트랜잭션이 아직 커밋안된 데이터를 읽을수 있음, 가장 낮은 격리수준으로 병행성은 가장 높다.
  • committed read: 트랜잭션이 커밋된 데이터를 읽을수 있음, 반복 읽기시 데이터의 다른 버전을 조회할 가능성이 있다.
  • repeatable read: 트랜잭션 특정 커밋된 버전의 데이터만 읽는다. 팬텀 읽기의 문제가 있으며 next-key lock등의 방법으로 보완한다.
  • serializble: 읽/쓰기시 반드시 exclusive lock을 건다. 병행성이 가장 낮고 격리수준은 가장 높다.

트랜잭션 격리수준에 따라 트랜잭션들의 각자의 고유의 버전의 데이터를 일관성있게 참조하게 되고 이를 MVCC라고 한다.

팬텀 읽기 문제 와 next-key lock

select for update는 lock을 필요로 하는 쿼리이다. 이런 lock을 필요로 하는 쿼리들은 스냅샷에서 불러오는것이 불가능하여 커밋된 데이터를 직접 불러오게 된다. 이런 상황에서 repeatable read 레벨에서 범위 조회 쿼리를 날렸을때 조회되는 값들이 달라질수 있는데 이를 팬텀 읽기 문제라고 한다. 이문제의 해결을 위해 next-key lock 기법을 사용한다.

mysql 엔진에서는 next-key lock을 통해 조회 된 결과들의 인덱스들과 인덱스들 사이에 lock을 건다. 이를 통해 팬텀 읽기 문제를 예방한다.

Leave a comment