[데이터베이스] 트랜잭션

애플리케이션 개발에서는 '오류처리' 를 바드시 고려하지 않으면 안된다. 즉, 갱신하는 동안 오류가 발생했을 때 어떤 상황이 발생하며 거기에서 어떻게 복구할 수 있는지를 생각할 필요가 있다.

데이터베이스가 일관성 있는 상태로 자동 복구해 주면 그러한 편이 좋은 것은 당연하다. 이것을 실현해 주는 구조가 '트랜잭션' 이다.

어디선가 실패하면 어중간한 상태로 갱신이 확정되는 것이 아니라 전부 없었던 것으로 해준다. (ACID 특성 중에 Atomicity 원자성 에 해당하는 기능)

마지막까지 처리를 마치고 결과를 확정시키니느 것을 COMMIT, 커밋하지 않고 모든 작업을 원래대로 되돌리는 것을 ROLLBACK 이라고 한다.

무정지성 확보하기

OS 장애 등의 서버 장애가 발생하여 그로부터 데이터베이스를 재기동한 때에 '장애 직전까지의 커밋 결과를 손실하지 않고 마치는 것' 이 가능하다. Oracle이나 InnoDB 같은 트랜잭션 대응의 데이터베이스에서는 REDO 로그(데이터베이스에서 수행한 작업을 다시 실행하는 로그) 를 이용한 아키텍처로 무정지성을 보장하고 있다.

REDO 로그

InnoDB에서는 트랜잭션 커밋 시 LSN(Log Sequence Number)이라는 시퀀스 번호가 증가하고, 그 번호와 갱신 대상의 블록의 정보 (갱산할 곳의 블록 ID 및 갱산할 곳의 위치 및 값)을 REDO 로그 파일에 쓴다.

한편, 열 값과 인덱스를 갖는 데이터 파일에는 커밋을 할 때마다 기록을 하는 것이 아니라 캐시 영역에 보관해 두고 정기적으로 디스크에 기록하는 동작을 한다. (체크 포인트)

서버 장애 등의 이유로 재기동을 하게 되는 경우, 캐시 영역의 데이터는 없어졌기 때문에 데이터 파일과 REDO 로그에 기록되어 있는 데이터가 올바르다. 그러나 데이터 파일은 이전 데이터밖에 남지 않았기 때문에 최신 데이터를 읽지 못하고 모순된 결과가 되어 버린다.

그래서 이러한 상황에서는 REDO 로그의 내용을 데이터 파일에 적용시켜 나감으로써 데이터 파일과 REDO 로그의 LSN과 일치시키는 작업을 수행한다. 이 과정을 '충돌 복구(Clash Recovery)' 라고 한다. 복구 시에는 적용을 시작할 가장 오래된 LSN을 특정 한 뒤 그 위치로부터 REDO로그의 내용을 순서대로 대응해 나가면 된다.

※ NoSQL의 대부분은 트랜잭션 기능을 갖고 있지 않으므로 비정상계의 처리에 대응하기 위해서는 그에 상응하는 애플리케이션 로직을 만들어 내지 않으면 안 된다.

복제 및 트랜잭션

MySQL에서는 MySQL5.6 과 InnoDB의 경우 처음으로 원자성 있는 갱신이 가능하게 되었다. 

복제 구성에서 슬레이브에서는 마스터에서 전송되어 온 업데이트성 쿼리를 실행하는 역할과 쿼리 중에서 어디까지를 실행했는지 라는 정보도 관리할 필요가 있다. 

마스터는 트랜잭션이 커밋될 때마다 그 갱신 SQL 문을 바이너리 로그에 기록한다. 슬레이브에서는 바이너리 로그의 내용을 실행하여 나가지만 '현재 어디까지 실행했는지'를 관리하기 위해 '실행을 마친 바이너리 로그의 위치 정보'를 관리하는  InnoDB 테이블을 제공한다.