5분 동안 데이터베이스 잠금이 사라진 장면과 해결 방법을 신속하게 이해하다

앞말

잠금(Locking)은 데이터베이스가 병렬 접근할 때 데이터의 일치성과 완전성을 확보하는 주요 메커니즘이다.모든 업무는 상응하는 대상의 자물쇠를 얻어야 데이터에 접근할 수 있으며, 데이터를 읽는 업무는 보통 자물쇠(공유 자물쇠)를 얻어야 하고, 데이터를 수정하는 업무는 자물쇠(배타 자물쇠)를 얻어야 한다.두 가지 업무가 서로 상대방이 얻은 자원을 방출하기를 기다려야 할 때, 시스템이 관여하지 않으면 계속 기다린다. 즉, 자물쇠 (deadlock) 상태에 들어간다.
다음은 Oracle, MySQL, Microsoft SQL Server, PostgreSQL 등 다양한 일반적인 데이터베이스 관리 시스템에 적용됩니다.

사쇄는 어떻게 생겼습니까?

데모 자물쇠의 생성은 매우 간단합니다. 우리는 두 줄의 데이터를 포함하는 간단한 예시표를 만들 수 있습니다.

CREATE TABLE t_lock(id int PRIMARY KEY, col int);
INSERT INTO t_lock VALUES (1, 100);
INSERT INTO t_lock VALUES (2, 200);

SELECT * FROM t_lock;
id|col|
--+---+
 1|100|
 2|200|

만약 우리가 서로 다른 업무에서 서로 다른 순서로 데이터를 수정한다면, 업무 간의 상호 대기를 일으킬 수 있다.한 사무가 다른 사무가 자원을 방출하기를 기다리는 것은 문제가 되지 않지만, 만약 두 사무가 서로 상대방의 자원을 기다린다면 데이터베이스 관리 시스템은 두 가지 선택만 있을 뿐이다. 무한 기다림 또는 한 사무를 중지하고 다른 사무를 성공적으로 집행하는 것이다.
분명히 무한 대기는 문제를 해결하는 방법이 아니기 때문에 데이터베이스는 보통 일정 시간을 기다린 후에 그 중의 일을 중단한다.
다음은 잠금이 해제된 데모 사례입니다.
사무1
사무2
비고
BEGIN;
BEGIN;
각각 두 가지 사무를 시작하다
UPDATE t_lock
SET col = col + 100
WHERE id = 1;
UPDATE t_lock
SET col = col + 200
WHERE id = 2;
사무 1 수정 id=1의 데이터, 사무 2 수정 id=2의 데이터
UPDATE t_lock
SET col = col + 100
WHERE id = 2;
사무 1 수정 id=2 데이터, 사무 2 쓰기 자물쇠 해제 대기
대기 중...
UPDATE t_lock
SET col = col + 200
WHERE id = 1;
사무2 수정 id=1의 데이터, 사무가 자물쇠를 놓을 때까지 기다려야 합니다
고정 자물쇠
고정 자물쇠
데이터베이스에서 자물쇠가 사라졌습니다. 업무 중단을 선택하십시오
업데이트 성공
오류 반환
ySQL InnoDB의 경우 innodb_가 기본적으로 사용됩니다.deadlock_detect 옵션, 트랜잭션 2에서 다음 오류 정보를 반환합니다.
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
InnoDB 잠금 해제 감지 옵션을 비활성화하면 트랜잭션 2는 50s(innodb_lock_wait_timeout)를 기다린 후 시간 초과를 알립니다.
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
Oracle에서 잠금 해제가 감지되면 다음 오류가 반환됩니다.
ORA-0060: 자원 대기 중 잠금 해제 감지
Microsoft SQL Server에서 잠금이 해제되었을 때 반환되는 오류는 다음과 같습니다.
메시지 1205, 레벨 13, 상태 51, 7행
트랜잭션 (프로세스 ID 67) 과 다른 프로세스는 자물쇠 자원에 잠겨 있으며, 자물쇠 희생물로 선택되었습니다.이 업무를 다시 실행하십시오.
PostgreSQL에서 잠금이 해제되었을 때 반환되는 오류는 다음과 같습니다.
SQL 오류 [40P01]: 오류: 잠금 해제 감지
상세: 프로세스 32가 트랜잭션 4765의 ShareLock에서 대기합니다.프로세스가 16552로 막혔다.
프로세스 16552 트랜잭션 4766에 있는 ShareLock 대기;프로세스 32에서 막힙니다.
권장 사항: 자세한 내용은 서버 로그를 참조하십시오.
위치: 관계식 "t_lock"의 메타그룹 (0, 1) 을 업데이트할 때

어떻게 해결하고 사라진 자물쇠를 피할 것인가

사라진 자물쇠는 데이터베이스 자체의 문제가 아니다. 우리는 데이터베이스 설정을 최적화하여 해결하거나 사라진 자물쇠를 피할 수 없고 응용 프로그램을 수정해서만 해결할 수 있다.간단하게 말하자면, 우리는 프로그램에서 같은 순서에 따라 데이터를 수정하여 서로 자원을 기다리는 상황이 발생하지 않도록 해야 한다.예:
사무1
사무2
비고
BEGIN;
BEGIN;
각각 두 가지 사무를 시작하다
UPDATE t_lock
SET col = col + 100
WHERE id = 1;
UPDATE t_lock
SET col = col + 200
WHERE id = 1;
사무1과 사무2 모두 id=1의 데이터를 수정하고 실행된 사무는 기다려야 합니다
UPDATE t_lock
SET col = col + 100
WHERE id = 2;
대기 중...
사무1 수정 id=1 데이터, 사무2 대기 중
COMMIT;
대기 중...
사무 1 제출
UPDATE t_lock
SET col = col + 200
WHERE id = 2;
사무2 id=2 데이터 계속 수정
COMMIT;
트랜잭션 2 제출
상기 장면은 자물쇠가 생기지 않습니다.그러나 우리는 실제 응용에서 같은 순서에 따라 데이터를 완전히 수정할 수 없을 수도 있다.만약 피할 수 없는 자물쇠 상태가 발생한다면 또 다른 해결 방법은 시스템이 되돌아오는 자물쇠 이상을 포착하고 프로그램에 다시 시도하는 메커니즘을 넣는 것이다.

총결산

본고는 데이터베이스 자물쇠가 사라진 원인과 해결 방법을 간략하게 소개하였다.5분 동안 데이터베이스 잠금 해제 장면과 해결 방법을 신속하게 알아보는 이 글은 여기까지 소개되었습니다. 더 많은 관련 데이터베이스 잠금 해제 내용은 저희 이전의 글을 검색하거나 아래의 관련 글을 계속 훑어보십시오. 앞으로 많은 응원 부탁드립니다!