MySQL undo log 의 특징

이 페이지에서는 MySQL 에서 쓰이는 undo log 의 특징을 알아본다.

 

해당 글은 아래의 URL 들을 참고한다.

 

[1] https://theone79.tistory.com/43

 

[2] https://bugs.mysql.com/bug.php?id=72362 

 

[3] https://myinfrabox.tistory.com/262

 

또한 이 글은 아래의 이전 게시글과 연관되어 있다.

 

[4] 2021.03.30 - [MySQL/아키텍처 및 내부 구조] - MySQL / MariaDB 기본 아키텍처 (Data - InnoDB)

 

[5] 2021.03.03 - [MySQL/아키텍처 및 내부 구조] - MySQL / MariaDB MVCC

 

 

MySQL 의 undo log 구조

 

MySQL 은 ORACLE 과 유사하게 undo log 를 통하여 commit, rollback 이 되지 않는 트랜잭션에 대하여 변경이력을 보관한다. 이는 MVCC 및 트랜잭션 격리 수준 (Transaction Isolation) 과도 매우 밀접하게 연관되어 있다.

 

다만, MySQL 은 다른 DB engine 와 다르게 가지고 있는 대표적인 특성이 몇개 있다.

 

 

MySQL 내 트랜잭션들은 각각 독립된 undo log 영역을 배정받아 사용한다.

 

이 특징을 지니게 되면 얻게 되는 장점 중 하나는 서로간의 트랜잭션 수행에 영향을 주지 않는다는 것이다.

 

예를 들어, ORACLE 은 각각의 트랜잭션들이 수행 시, 하나의 트랜잭션이 다른 트랜잭션에서 사용 중이던 undo log 를 overwrite 하여 ORACLE 에서 보이는 대표적인 에러 중 하나인 'snapshot too old' 가 발생 할 수 있지만 MySQL 은 그렇지 않다는 것이다. 

 

이는 아키텍처적으로 MySQL 은 undo tablespace 에서 개별 트랜잭션에 독립된 undo log 를 할당하기 때문이다.

그리고 이렇게 undo log 들이 배정된 조합을 segment 단위로 관리하게 된다. (Rollback segment)

 

그렇기 때문에 서로간의 트랜잭션들이 서로 간섭을 하지 않게 된다.

물론, 이런 구조에서는 DB 가 각 트랜잭션별로 undo 를 생성하는 것은 무한하지 않다.

 

그래서 특정 DB 환경에서 얼마만큼의 트랜잭션을 동시에 관리 할 수 있는지 계산이 필요 할 수 있는데 이는 [3] 의 내용을 확인하면 된다.

 

 

MySQL 에선 undo 영역이 무한히 커질 수 있다.

 

이 또한 다른 DB engine 에서 볼 수 없는 특징이다.

ORACLE 의 snapshot too old 도 결국 생각해 보면 undo size 가 한정되어있기에 overwrite 가 발생하는데

MySQL 에서는 그냥 size 를 늘려서 어떻게든 트랜잭션을 보존하려고 한다.

물론, 무한적으로 늘어나는 특징을 이용하는 것은 데이터 보존적인 측면에서는 장점이지만

이에 따라 트랜잭션 관리를 하지 않으면 storage full 을 겪는다는 점에서는 큰 단점이다.

그래서 MySQL 을 관리 할 때는 이에 대해서 유념을 하고 undo 영역이 계속 커질 위험이 있다면, 이에 따른

long transaction 을 미리 차단 또는 개선하여 undo 사용을 최대한 줄여주는 것이 좋다.

[2] 와 같이 몇몇 사용자들은 이를 제한해야 한다는 의견이 있으나 아직 이에 대해서는 명확히 정정된 것은 없다.