innodb history length가 성능에 영향을 미치는 이유가 뭘까요?

Question

안녕하세요.예전에 개발자 PC db client에서 트랜잭션 시작하고 오랜 시간동안 안 닫아서해당 트랜잭션 이후 변경된 레코드들이 undo log에 아주 오랜동안 기록되면서 장애가 발생했던 적이 있습니다. 그 당시 - show engine innodb status- select * from INNODB_METRICS where name like '%history%로 조회했던 history length가 백만이 넘었었는데요... 개발자 PC에서 트랜잭션 끊고, interactive timeout 시간 조절해서 장애는 해소 되었는데.. 이유가 이해가 안가네요. 가령 12시에 트랜잭션을 시작한 뒤 트랜잭션을 2시간동안 안닫았는데,그 사이에 10만개의 DML 쿼리가 발생했다고 했을때.. 이러면 10만개의 데이터가 undo log에 쌓이게 되는데요.이게 DB cpu를 증가시키는 이유와, 이후에 발생한 select 쿼리들의 속도를 저하시키는 이유를 모르겠습니다 ㅜㅜ저 undo log를 신경쓰는 트랜잭션은 12시에 시작한 트랜잭션 뿐이라고 생각하는데.. ㅠㅠ혹시 어떤 이유가 있을까요? 그리고 추가로 궁금한게 있는데요.replication이 설정되어 있을 때 writer db의 history length가 길어지는 것이 reader db에게도 영향을 주나요? 답변 해주시면 감사하겠습니다!

yeori · Answer

간략하게 요약하면 아래와 같은 상태에서..undo log에 히스토리가 쌓일때 linked list 로 히스토리를 남김 히스토리를 남긴 트랙잭션(들)이 안죽고 살아있음(commit도 rollback도 안되고...)update, insert(delete) dml을 실행했던 트랜잭션이 끝나지 않았기때문에 undo로그는 지워지지 않고 켜켜이 쌓여있음. 이제 또다른 트랜잭션(trx_id :&#61; 2311) 이 생성되고 select 를 실행합니다.새로운 트랜잭션(trx_id 2311)이 바라볼 수 있는 값을 찾기 위해서 undo 로그를 링크를 따라서 역으로 쭉 검색해 나갑니다(repeatable read, read commited). mysql(mariadb)의 트랜잭션이 dml을 실행하면 테이블의 row를 수정해버립니다.그리고 rollback이 발생했을때 데이터를 되돌리기 위해서 undo log에다가 값을 수정하기 직전의 데이터를 담아서 linked list로 쌓아둡니다(리스트 뒤쪽의 데이터일수록 훨씬 이전의 데이터)정상적인 경우 이 undo 로그의 리스트(히스토리)가 그리 길지 않을텐데, 100만개씩 쌓여있으면 다른 트랜잭션에서 select 할때마다 스냅샷을 만들기 위해서 undo log를 헤집고 다닐겁니다. replication 설정시에는 물리적으로 디비가 분리되니까 undo log 등으로 인한 문제가 없지 않을까 추측해봅니다(정확한건 아니고 그냥 얼핏 생각하기에...). 확실하지는 않아요. 나도 잘 모름

준티 · Answer

안녕하세요 답변 감사드립니다.이제 또다른 트랜잭션(trx_id :&#61; 2311) 이 생성되고 select 를 실행합니다.새로운 트랜잭션(trx_id 2311)이 바라볼 수 있는 값을 찾기 위해서 undo 로그를 링크를 따라서 역으로 쭉 검색해 나갑니다(repeatable read, read commited).이 부분이 조금 이해가 되지 않는데요, 왜 undo 로그를 검색하나요?바로 아래서 언급해주셨듯이 mysql의 경우 dml 실행 시 테이블 row를 바로 수정해버리니까, 새로운 트랜잭션이 생성되면 undo 로그를 뒤질 필요없이 바로 row에 접근하면 되지 않나요??

innodb history length가 성능에 영향을 미치는 이유가 뭘까요?

2개의 답변

#replication 목록