📃 트랜잭션(Transaction)과 동시성 제어 그리고 회복

Commit, Rollback, Auto Commit

Commit

• Commit 연산은 트랜잭션 처리가 정상적으로 종료되어 트랜잭션이 수행한 변경 내용을 데이터베이스에 반영하는 연산이다. 이것을 통해 데이터베이스가 일관성있는 상태가 된다.
• 내용을 변경한 트랜잭션이 완료되면 그 트랜잭션에 의해 데이터베이스는 새롭게 일관된 상태로 변경되며, 이 상태는 시스템 오류가 발생하더라도 취소되지 않는다.

Rollback

• Rollback 연산은 하나의 트랜잭션 처리가 비정상적으로 종료되어 데이터의 일관성이 깨졌을 때, 트랜잭션이 행한 모든 변경작업을 취소하고 이전 상태로 되돌리는 연산이다.
• Rollback 연산 시 해당 트랜잭션은 받았던 자원과 잠금을 모두 반환하고 재시작되거나 폐기된다.

Auto Commit

• AutoCommit이란 사용자가 Commit 명령을 따로 하지 않아도 자동으로 모든 명령을 Commit되어 즉시 반영되는 명령어이다.
• 주의해야 하는 이유는 AutoCommit을 활성화 해 놓은 후에 DB를 사용했을 경우, 실수를 하더라도 곧바로 즉시 반영이 된다.
• Commit이 된 트랜잭션은 RollBack이 불가능하다.

---

트랜잭션(Transaction)

• 데이터베이스의 상태를 변화시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위이다.
• 상태를 변화한다는 것은 SQL 질의어를 통해 DB에 접근하는 것이다.
• 작업 단위는 사람이 정하는 기준에 따라 한꺼번에 모두 수행되어야 하는 연산을 뜻한다.

원자성(Atomicity)

• 트랜잭션 내의 모든 명령은 반드시 완벽하게 수행되어야 하며 어느 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다.
• 트랜잭션의 연산은 모두 반영되기 위해 Commit을 사용하고 전부 반영하지 않기 위해서 Rollback을 사용해야 한다.

일관성(Consistency)

• 트랜잭션의 작업 처리 결과는 항상 일관성이 있어야 한다.

독립성(Isolation)

• 수행 중인 트랜잭션은 완전히 완료될 때 까지 다른 트랜잭션에서의 수행 결과를 참조할 수 없다.

영속성(Durability)

• 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영되어야 한다.

---

트랜잭션 고립 수준

트랜잭션 고립 수준은 트랜잭션들끼리 일관성있는 데이터를 얼마나 허용할 것인지 정해놓은 수준이다.
고립 수준이 높을수록 일관성은 보장되지만 그 만큼 동시성이 떨어져 성능이 하락한다.

이상 현상 종류

• Dirty Read : 어떤 트랜잭션에서 아직 실행이 끝나지 않은 트랜잭션에 의한 변경사항을 보게되는 경우
• Non Repeatable Read : 어떤 트랜잭션이 같은 쿼리를 2번 실행하는데 그 사이에 다른 트랜잭션이 수정, 삭제하는 경우
• Phantom Read : 어떤 트랜잭션이 같은 쿼리를 2번 실행하는데 그 사이에 없던 레코드가 추가된 경우

READ UNCOMMITTIED

• 트랜잭션 수행 중이거나 아직 commit 되지 않은 데이터를 다른 트랜잭션에서 Read 하는 것을 허용한다.
• 정합성에 문제가 많은 격리 수준으로 사용하지 않는 것이 좋다.
• 이상 현상 중 Dirty Read, Non Repeatable Read, Phantom Read 발생이 가능하다.

READ COMMITTED

• 트랜잭션 수행이 완료되고 commit 된 데이터만 다른 트랜잭션에서 Read 하도록 허용한다.
• 한 트랜잭션 내에서 같은 데이터를 여러 번 읽어도 트랜잭션이 종료되는 동안 데이터가 변경될 수 있다.
• 일반적으로 DBMS에서 Default로 설정하는 레벨이다.
• 이상 현상 중 Non Repeatable Read, Phantom Read이 발생 가능하다.

REPEATABLE READ

• 같은 트랜잭션 내에서 같은 데이터를 반복해서 읽더라도 데이터는 변하지 않는다.
• 특정 트랜잭션에서 읽고 있는 데이터는 다른 트랜잭션에서 수정, 삭제가 불가능하지만 삽입은 가능하다.
• 이상 현상 중 Phantom Read 발생이 가능하다.

SERIALIZABLE

• 동시에 실행되는 여러 트랜잭션들 간에 상호작용이 일어나지 않는다.
• 특정 트랜잭션에서 읽고 있는 데이터는 다른 트랜잭션에서 수정, 삭제, 삽입 모두 불가능하다.
• 모든 이상 현상을 방지 가능하지만 그만큼 동시성이 떨어져 성능이 하락한다.

---

DB 갱신 손실 문제

• 갱신 손실(lost update)는 동시성 문제의 원인 중 하나이다. 두 개의 트랜잭션이 한 개의 데이터를 동시에 갱신(update)할 때 발생한다. 동시성을 제어하기 위해 Lock을 활용한다. 여기서 동시성 제어는 트랜잭션이 동시에 실행될 때, 일관성을 해치지 않도록 트랜잭션의 데이터 접근을 제어하는 DBMS의 기능이다.

---

DB Lock

• 데이터베이스에서 여러 사용자들이 같은 데이터를 동시에 접근해야 하는 상황에서 무결성과 일관성을 지키고 동시성을 보장하기 위해 Lock을 사용한다.

낙관적 잠금(Optimisstic Lock)

• 데이터 갱신 시 경합이 발생하지 않을 것이라고 낙관적으로 바라보는 것이다. 자원에 락을 걸어 선점하지 않고 커밋할 때 동시성 문제가 발생하면 그때 처리하자는 방법론이다.
• 일반적으로 version의 상태를 보고 충돌을 확인하며, 충돌이 확인된 경우 롤백을 진행한다.
• DB단에서 동시성을 처리하는 것이 아닌 애플리케이션단에서 처리한다.
• 낙관적 잠금은 동시 업데이트가 거의 없는 경우에 사용하면 좋다.

비관적 잠금(Pessimistic Lock)

• 비관적 락은 자원 경쟁을 비관적으로 바라보기 때문에, 여러 트랜잭션이 동시에 수정할 것이라고 가정하는 기법이다.
• 그래서 하나의 트랜잭션이 데이터를 읽는 시점에서 Lock을 걸고 조회 또는 업데이트 처리가 완료될 때까지 유지한다.

Inno DB 스토리지 엔진 Lock 종류

공유 락(Shared Lock)

• 공유 락은 데이터를 변경하지 않는 읽기 명령에 대해 주어지는 락으로 Read Lock이라고 불리며, S로 표기한다.
• 여러 사용자가 동시에 데이터를 읽어도 데이터의 일관성에는 아무런 영향을 주지 않기 때문에, 공유 락끼리는 동시에 접근이 가능하다.
• 공유 락이 걸려있는 row에 다른 트랜잭션이 S Lock(공유 락)을 걸 수 있지만 X Lock(베타 락)은 걸 수 없다.

베타 락(Exclusive Lock)

• 베타 락은 데이터에 변경을 가하는 명령들에 대해 주어지는 락으로 Write Lock이라고 불리며, X로 표기한다.
• 베타 락은 다른 세션이 해당 자원에 접근하는 것을 막는다. 베타 락은 트랜잭션 동안 유지된다. 멀티 스레딩 환경에서 임계 영역을 안전하게 관리하기 위해 활용한 뮤텍스와 유사하다.
• X Lock(베타 락)이 걸려있으면 다른 트랜잭션은 S Lock(공유 락), X Lock 둘 다 걸 수 없다.

레코드 락(Record Lock)

• InnoDB에서 Record Lock은 실제 테이블의 Record가 아닌 DB Index Record에 걸리는 Lock이다.
• 테이블에 Index가 없다면 숨겨져 있는 Clusterd Index를 사용하여 record를 잠근다.

갭 락(Gap Lock)

• Index Record가 없는 부분에 걸리는 Lock이다. Index Record와 인접한 앞, 뒤 사이 공간에 Lock을 거는 것인데, 단독으로 사용되지 않고 넥스트 키 락에서 사용된다.
• 조건에 해당하는 새로운 Row가 추가되는 것을 방지하기 위한 것이다.

넥스트 키 락(Next key lock)

• 레코드 락과 갭 락을 합쳐놓은 것이다. Index Record도 잠그고 그 Index Record 앞, 뒤 갭도 잠근다.

---

DB 데드락

• 데드락은 두 개 이상의 트랜잭션이 각각 자신의 데이터에 대해서 락을 획득하고 상대방 데이터에 대해서 락을 요청하면 무한 대기 상태에 빠질 수 있는 현상이다. 운영체제의 데드락과 유사하다.
• 해결 방안으로는 트랜잭션 진행방향은 같은 방향으로 처리하거나 트랜잭션 처리 속도를 최소화 합니다. 그리고 LOCK TIMEOUT을 이용하여 잠금해제 시간을 조절한다.

---

DB 회복

• 데이터 베이스에 장애가 발생했을 때 데이터베이스를 일관성있는 상태로 되돌리는 DBMS의 기능이다. 장애의 유형으로는 트랜잭션 장애, 시스템 장애, 미디어 장애 등이 있다.
• 회복 기법은 로그 파일을 이용한 회복, 체크포인트를 이용한 회복이 있다.

로그 파일

• 로그 파일은 트랜잭션이 반영한 모든 데이터의 변경 사항을 데이터베이스에 기록하기 전에 미리 기록해두는 데이터베이스이다. 안전한 하드디스크에 저장되며 전원과 관계없이 기록이 존재한다.

로그 파일을 이용한 회복

• 로그 파일을 이용한 회복은 데이터의 변경 기록을 저장해 둔 로그 파일을 이용해 시스템 장애를 복구하는 것이 가능하다.
• 로그 파일의 회복 방법으로 즉시 갱신(Immediate Update)과 지연 갱신(Deferred Update)이 있다.
• 즉시 갱신은 갱신된 데이터를 로그에 기록하는 작업과 버퍼의 데이터를 데이터베이스에 옮기는 작업이 동시에 진행될 수 있다.
• 지연 갱신은 갱신된 데이터를 로그에 기록하는 작업이 끝난 후에 버퍼의 데이터를 데이터베이스로 옮기는 과정을 진행할 수 있다.

REDO, UNDO

• DBMS는 트랜잭션이 종료되었는지 중단되었는지 여부를 판단하여 종료된 경우에는 종료를 확정하기 위해 REDO(재실행)을 하고 중단된 경우에는 없던 일로 되돌리기 위해 UNDO(취소)를 진행한다.
• REDO는 장애가 발생한 후 시스템을 다시 가동했을 때, 로그 파일에 트랜잭션의 시작(START)이 있고 종료(COMMIT)이 있는 경우, 로그를 사용하여 커밋된 변경 내용을 재실행하여 데이터베이스를 복구할 수 있다.
• UNDO는 장애가 발생한 후 시스템을 다시 가동했을 때, 로그 파일에 트랜잭션의 시작(START)만 있고 종료(COMMIT)이 없는 경우, 완료하지 못했지만 버퍼의 변경 내용이 데이터베이스에 기록되어있을 가능성이 있기 때문에 로그를 보면서 트랜잭션이 변경한 내용을 이전 상태로 원상복구시키는 과정이다.

체크포인트 회복 기법

• DBMS에서 회복을 할 때 처음부터 마지막 로그 기록까지 한 번에 처리하려면 시간이 오래 걸리는데, 특정 시간 마다 검사를 하여 문제가 없음을 확인하면 다음번 에러 발생 시 회복을 시작하는 시점을 앞당길 수 있다.

• 주 기억장치(RAM)에 로그 레코드를 모두 하드디스크의 로그 파일에 저장한다. 그리고 트랜잭션 수행 중에 변경된 버퍼 내의 내용을 하드디스크의 데이터베이스에 저장한다.

• 체크포인트 이전에 COMMIT 기록이 있는 경우 아무 작업이 필요 없다. 로그에 체크포인트가 나타나는 시점은 이미 변경된 내용이 데이터베이스에 모두 기록된 후 이기 때문이다.

• 체크포인트 이후에 COMMIT 기록이 있는 경우 REDO를 진행한다. 체크포인트 이후에 변경 내용이 데이터베이스에 반영되지 않아서 REDO를 진행해야 한다.

• 체크포인트 이후에 COMMIT 기록이 없는 경우 즉시 갱신 방법을 사용했다면 UNDO를 진행한다. 왜냐하면 버퍼의 내용이 반영됐을 수도 있기 때문에 원상복구 시켜야 한다. 반면 지연 갱신 방법을 사용했다면 아무것도 할 필요가 없다. 왜냐하면 지연 갱신 방법은 COMMIT 이전에는 버퍼의 내용을 데이터베이스에 반영하지 않기 때문이다.