본문 바로가기

DB/Mysql

Mysql purge lag


Mysql을 사용하면서 대량을 삭제가 발생할 때 purge lag이 싸여서 mysql 응답속도가 느려질 수 있다는 이야기를 들은 적이있다. 

괜찮은 페이지를 찾아서 정리해 놓는다.

http://mysqlha.blogspot.com/2008/07/how-do-you-know-when-innodb-gets-behind.html

 InnoDB does not remove deleted rows from a table until they cannot be read by any other transaction. This is done by a background thread. Deleted rows that have not been purged artificially increase the size of a table. They also increase the overhead of table scan operations. This line from SHOW INNODB STATUS displays the amount of work pending for the purge operation.

History list length 30

즉, delete된 row들이 바로 삭제되지 않는다는 것인데, 실제 삭제는 background thread가 담당한다.
너무 많은 삭제가 일어나 background Thread가 처리하지 못하고 pending(미해결)된 list를 Purge-lag이라고 한다. 

http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html#sysvar_innodb_max_purge_lag

위의 페이지에서 보면 innodb_max_purge_lag 변수에 대한 설명을 들을 수 있다.

 innodb_max_purge_lag

Command-Line Format --innodb_max_purge_lag=#
Option-File Format innodb_max_purge_lag
Option Sets Variable Yes, innodb_max_purge_lag
Variable Name innodb_max_purge_lag
Variable Scope Global
Dynamic Variable Yes
  Permitted Values
Type numeric
Default 0
Range 0 .. 4294967295

이 변수는 background thread들이 다 처리하지 못한 purge-lag가 얼마나 쌓였을 때 부터 Insert, update, delete가 delay될 것인가를 결정한다. 
background thread가 처리하지 못한 list를 purge-lag이라고 할때 insert,update,delete가 delay되는 시간은 아래의 공식으로 구해지며 매 10초마다 purge batch에 의해 갱신된다. 
((purge_lag/innodb_max_purge_lag)×10)–5 milliseconds

mysql에서 대량의 삭제를 진행할 때 이 값을 눈여겨 보길 바란다.