背景

Innodb使用undo log來實現MVCC，這意味著如果一個很老的事務長時間不提交，那么新產生的undo log都無法被及時清理掉。在MySQL 5.5及之前版本中，undo log是存儲在ibdata中。從5.6開始可以使用獨立的undo log表空間來存儲undo。但是直到5.6，一旦undo log膨脹，依然沒有任何辦法為其 “減肥”。因此我們經常看到ibdata被膨脹到幾十上百G。

改進

在MySQL5.7.5版本中終于增加了這個眾望所歸的功能，實現了在線truncate undo log的功能。對應的changeling entry如下：

InnoDB: You can now truncate undo logs that reside in undo tablespaces. This feature is enabled using the innodb_undo_log_truncate configuration option. For more information, see Truncating Undo Logs That Reside in Undo Tablespaces.

在能夠使用該特性之前，需要先打開獨立undo表空間，注意現在只能在install db的時候才能開啟，因為在初始化階段是寫死占用了最小的幾個space id的。這種實現方式。。。只能無限吐槽了。

有幾個參數控制undo tablespace：

innodb_undo_directory：undo文件的存儲目錄。

innodb_undo_tablespaces：undo tablespace的個數，實現在線truncate undo，需要大于等于2，因為在truncate一個undo log文件時，要保證另外一個是可用的，這樣就無需停止業務了。

innodb_undo_logs：undo回滾段的數量需要大于34。原因是1~32個回滾段會被臨時表占用（5.7針對臨時表做了大量優化），第33、34分配給undospace1 和undospace2。

這里有個比較有意思的問題，由于undo 回滾段總是從第一個undospace分配，如果每次從1開始，每次重啟遞增innodb_undo_logs，所有的回滾段都會被分配到第一個undo space，在truncate第一個undo space時，將無可用的undo回滾分配給正常的用戶事務。

innodb_purge_rseg_truncate_frequency：用于控制purge回滾段的頻度。 Innodb Purge操作的協調線程每隔這么多次purge事務分發后，就會觸發一次History purge，并檢查當前的undo log 表空間狀態是否會觸發truncate。

innodb_max_undo_log_size：控制最大undo tablespace文件的大小，超過這個閥值時才會去嘗試truncate。truncate后的大小默認為10M。

innodb_undo_log_truncate：用于打開/關閉undo log 在線truncate特性，可動態調整。

undo log 的truncate操作由purge 協調線程發起，在truncate 某個undo log 表空間的過程中，保證有一個可用的undo log tablespace能提供給用戶使用，從而實現所謂的在線truncate。

當選定一個需要truncate的undo log space時，需要檢查其是否是可釋放的，也就是說是否還有活躍的事務可能訪問其中的回滾段。如果沒有，就將該tablespace中的回滾段設置為不可分配，然后對undo log space文件進行truncate，并重新初始化到10M，初始化文件頭等一系列操作。

這里引入了比較有意思的方法來保證truncate的原子性，即在開始truncate時，創建一個獨立的文件，命名為undo_<space_id>_trunc.log，在做完truncate操作后，刪除文件。如果在中間發生crash，崩潰恢復時發現該文件，會繼續完成truncate操作。

更具體的參考WL#6965?及對應補丁Rev:8615

總結

以上是生活随笔為你收集整理的MySQL内核月报 2014.11-MySQL·　5.7特性·在线Truncate undo log 表空间的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。