Colin Kang

Mysql의 InnoDB는 MVCC ( Multi Version Concurrency Control )을 사용하며, 이는 이전 버전으 데이터와 rollback을 지원하기 위해서 변경된 row의 이전 데이터를 commit/rollback이 완료될 때까지 보관하고 있어서 한다. rollback을 위해서 이러한 데이터는 undo log에 저장이 되며, linked list 형태로 관리되기 때문에 History List 이며, 이 list가 길어지는 혹은 증가하고 있다는 것은 undo 데이터가 많아지고 있으며 transaction이 여전히 commit/rollback 되지 않고 있다는 것을 의미한다. undo데이터가 삭제되는 순간은 undo데이터가 더이상 필요 없어지는 순간이며, 이 것이 삭제 되지 않는 것은 어떤  transaction에서 이 데이터가 계속 필요하다고 혹은 참고하고 있다고 판단되기 때문이다. 

History List Length, undo로그가 증가되는 원인은 다음과 같다.

- read나 write에 long transaction : 

mysql의 default isolation model은 REPEATED_READ이므로 다른 transaction이 해당 row를 변경하고 commit했더라고 그 transaction이전부터 select를하고 지금도 하고 있다면 undo는 보관을 하고 변경되기 이전의 데이터를 select에서 repeat read했을 때에도 제공해야한다. ( 참고로 대부분의 사람들이 착각하는데 select 등의 read는 transaction이 없는 걸로 오해하는데, select도 tranaction과 항상 같이 고민해야하며, transaction의 범위 내에 있다고 생각해야한다. ) 하여 read에 long transaction도 HLL을 증가시킬수 있다.

- heavy write

많이 기록하는 경우에는 당연히 HLL이 발생할낟.

- commit을 하지 않은 user session

이 경우는 흔지 않지만, 찾기가 어려우며, DB에 문제를 줄 수 있다. 예들 들어 auto-commit false로 데이터를 한건 넣고 기다린다고 하면, 

commit이 아직 안되었기 때문에 HLL이 purge되지 않고 이후의 HLL에 기록되는 transaction도 purge 되지 않는다. user sessino이기 때문에 timeout이 적용안되서 rollback이 되지않으면서, idle하고 그 이후에 DB에 영향을 주기 않고 있기 때문에 각종 monitoring 지표에서 찾아내기가 어렵다. 해당 user session을 종료하기 전까지는 HLL은 계속 증가한다. 만약 HLL이 계속 증가하면 언젠가는 DB shutdown 혹은 restart상황으로 갈수 있다.

조치

long running transaction을 찾아서 commit 혹은 rollback 해야한다.

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/proactive-insights.history-list.html

https://lefred.be/content/a-graph-a-day-keeps-the-doctor-away-mysql-history-list-length/

https://www.percona.com/blog/chasing-a-hung-transaction-in-mysql-innodb-history-length-strikes-back/

https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html

https://www.percona.com/blog/mysql-performance-implications-of-innodb-isolation-modes/