Table lock vs Row lock

실무에서 실수하지 않는 것이 목표이며, 시나리오 중심으로 개념을 공고히 합니다.

개념 정리

구문에 따라서 lock되는 데이터의 범위 & 양이 달라질 수 있다.

Table locks

테이블 전체를 잠근다.
데드락이 발생하지 않는다.
Row-level locking을 하더라도 조건 필드에 인덱스가 없으면 전체 테이블에 lock이 걸린다.
- - MySQL이 조회된 행을 기억하는 방법이 인덱스 범위를 기억하는 것이기 때문.
많은 수의 Row-level locking을 시도할 때 Table locking이 더 효율적이라면, 전체 테이블에 lock이 걸릴 수도 있다. 이는 Lock Escalation 이라고 한다.

Single-row locks

트랜잭션 격리 레벨에 따라 다르게 적용된다.
데드락이 발생하지 않도록 주의해야한다. 특히 innoDB나 BDB 타입의 테이블들은 deadlock-free하지 않으므로 주의할 것.

사용

Table locks

사용 방법

READ lock인지 WRITE lock인지 설정할 수 있다.

-- MySQL
LOCK TABLES table_name [READ | WRITE];

Rails에서는 Table lock을 공식적으로 지원하지는 않는다. 그래서 아래처럼 직접 SQL문을 넣어줘야한다.

ActiveRecord::Base.transaction do
  ActiveRecord::Base.connection.execute('LOCK TABLES table_name READ')
  ...
end

사용 시나리오

Table lock은 전체 테이블에 대한 데이터 변경이 있을 경우 사용한다. 테이블을 제어하는 DDL 구문을 사용할 때 Lock이 걸린다고 하여 DDL Lock이라고도 한다.

운영 중인 테이블을 복제(CREATE SELECT)하거나 다른 테이블로 옮길 경우(INSERT SELECT) Transaction Isolation Level을 READ COMMITTED 변경하고 작업하기를 권장한다.

그렇지 않으면 관련된 Table은 Exclusive Lock이 걸리고, 관련 Query들이 대기 상태로 빠지면서 시스템 장애가 발생할지도 모르기 때문.

Row locks

사용방

FOR UPDATE 를 붙여주면 Exclusive lock을 건다. 이 때 MySQL은 Row 전체에 lock을 거는 것이 아니라 인덱스에 건다고 하니 참고.

-- MySQL
SELECT * FROM table_name WHERE id=10 FOR UPDATE;

lock 모드를 SHARE MODE로 걸 수도 있다.

-- MySQL
SELECT * FROM table_name WHERE id=10 LOCK IN SHARE MODE

ActiveReocrd에서는 lock 구문이나 with_lock 구문을 이용하면, 위 FOR UPDATE SQL 구문을 생성해준다.

# lock
user = User.lock.find_by(id: params[:id])
user.reward = user.reward + params[:reward].to_i
user.save!

# with_lock
user = User.find_by(id: params[:id])
user.with_lock do
  user.reward = user.reward + params[:reward].to_i
  user.save!
end

사용 시나리오

특정 user의 reward 컬럼 값을 100만큼 증가시키는 API가 있다고 하자. 그리고 user.reward가 원래 0원인 상태에서 200원이 되도록 하기 위해 이 API를 동시에 2차례 호출한다고 생각해보자. 그리고 이 API 호출을 각각 1번 API 호출, 2번 API 호출로 명명해보겠다.

만약 이 API에 lock 처리가 되어있지 않은 상태라면, 이 1번 호출, 2번 호출이 동시에 진행되었을 때 문제가 생길 수 있다.

1번 호출과 2번 호출에서 user 값을 read해올 때, 아직 update가 되기 전의 값을 read 해올 수 있기 때문.
구체적으로는 user.reward를 0원으로 불러오고, 결과적으로 두 요청 모두 user.reward 값을 0원에서 100원으로 증가시킨 뒤 최종적으로 100원이 된 상태에서 user.save 를 호출하게 되어, 0원에서 200원이 되는 것이 아니라 0원에서 100원이 될 수 있다.

대신 Exclusive lock 처리를 하면, 1번 호출, 2번 호출이 동시에 진행되더라도 문제를 방지할 수 있다.

1번 호출과 2번 호출에서 user 값을 read해올 때, 다른 호출에서 lock을 들고 있으면, lock이 풀릴 때까지 기다렸다가 값을 read해오기 때문에, 순차적으로 reward 값을 증가시킬 수 있기 때문이다.

참고

PreviousActiveRecord lock vs with_lock NextWHERE 1=1 구문에 대하여

Last updated 3 years ago

Was this helpful?

Table lock vs Row lock

실무에서 실수하지 않는 것이 목표이며, 시나리오 중심으로 개념을 공고히 합니다.

개념 정리

구문에 따라서 lock되는 데이터의 범위 & 양이 달라질 수 있다.

Table locks

테이블 전체를 잠근다.
데드락이 발생하지 않는다.
Row-level locking을 하더라도 조건 필드에 인덱스가 없으면 전체 테이블에 lock이 걸린다.
- - MySQL이 조회된 행을 기억하는 방법이 인덱스 범위를 기억하는 것이기 때문.
많은 수의 Row-level locking을 시도할 때 Table locking이 더 효율적이라면, 전체 테이블에 lock이 걸릴 수도 있다. 이는 Lock Escalation 이라고 한다.

Single-row locks

트랜잭션 격리 레벨에 따라 다르게 적용된다.
데드락이 발생하지 않도록 주의해야한다. 특히 innoDB나 BDB 타입의 테이블들은 deadlock-free하지 않으므로 주의할 것.

사용

Table locks

사용 방법

READ lock인지 WRITE lock인지 설정할 수 있다.

-- MySQL
LOCK TABLES table_name [READ | WRITE];

Rails에서는 Table lock을 공식적으로 지원하지는 않는다. 그래서 아래처럼 직접 SQL문을 넣어줘야한다.

ActiveRecord::Base.transaction do
  ActiveRecord::Base.connection.execute('LOCK TABLES table_name READ')
  ...
end

사용 시나리오

Table lock은 전체 테이블에 대한 데이터 변경이 있을 경우 사용한다. 테이블을 제어하는 DDL 구문을 사용할 때 Lock이 걸린다고 하여 DDL Lock이라고도 한다.

운영 중인 테이블을 복제(CREATE SELECT)하거나 다른 테이블로 옮길 경우(INSERT SELECT) Transaction Isolation Level을 READ COMMITTED 변경하고 작업하기를 권장한다.

그렇지 않으면 관련된 Table은 Exclusive Lock이 걸리고, 관련 Query들이 대기 상태로 빠지면서 시스템 장애가 발생할지도 모르기 때문.

Row locks

사용방

FOR UPDATE 를 붙여주면 Exclusive lock을 건다. 이 때 MySQL은 Row 전체에 lock을 거는 것이 아니라 인덱스에 건다고 하니 참고.

-- MySQL
SELECT * FROM table_name WHERE id=10 FOR UPDATE;

lock 모드를 SHARE MODE로 걸 수도 있다.

-- MySQL
SELECT * FROM table_name WHERE id=10 LOCK IN SHARE MODE

ActiveReocrd에서는 lock 구문이나 with_lock 구문을 이용하면, 위 FOR UPDATE SQL 구문을 생성해준다.

# lock
user = User.lock.find_by(id: params[:id])
user.reward = user.reward + params[:reward].to_i
user.save!

# with_lock
user = User.find_by(id: params[:id])
user.with_lock do
  user.reward = user.reward + params[:reward].to_i
  user.save!
end

사용 시나리오

만약 이 API에 lock 처리가 되어있지 않은 상태라면, 이 1번 호출, 2번 호출이 동시에 진행되었을 때 문제가 생길 수 있다.

1번 호출과 2번 호출에서 user 값을 read해올 때, 아직 update가 되기 전의 값을 read 해올 수 있기 때문.
구체적으로는 user.reward를 0원으로 불러오고, 결과적으로 두 요청 모두 user.reward 값을 0원에서 100원으로 증가시킨 뒤 최종적으로 100원이 된 상태에서 user.save 를 호출하게 되어, 0원에서 200원이 되는 것이 아니라 0원에서 100원이 될 수 있다.

대신 Exclusive lock 처리를 하면, 1번 호출, 2번 호출이 동시에 진행되더라도 문제를 방지할 수 있다.

1번 호출과 2번 호출에서 user 값을 read해올 때, 다른 호출에서 lock을 들고 있으면, lock이 풀릴 때까지 기다렸다가 값을 read해오기 때문에, 순차적으로 reward 값을 증가시킬 수 있기 때문이다.

참고

PreviousActiveRecord lock vs with_lock NextWHERE 1=1 구문에 대하여

Last updated 3 years ago

Was this helpful?