[MySQL5.6] Innodb獨立的undo tablespace
在MySQL5.6中開始支持把undo log分離到獨立的表空間，並放到單獨的文件目錄下；這給我們部署不同IO類型的文件位置帶來便利，對於並發寫入型負載，我們可以把undo文件部署到單獨的高速存儲設備上.
1.使用
有幾個參數來控制該行為
用於設定創建的undo表空間的個數，在Install db時初始化后，就再也不能被改動了；
默認值為0，表示不獨立設置undo的tablespace，默認記錄到ibdata中；否則，則在undo目錄下創建這么多個undo文件，例如假定設置該值為16，那么就會創建命名為undo001~undo016的undo tablespace文件，每個文件的默認大小為10M
修改該值可能會導致Innodb無法完成初始化；
用於表示回滾段的個數（早期版本的命名為
innodb_rollback_segments ），該變量可以動態調整，但是物理上的回滾段不會減少，只是會控制用到的回滾段的個數;
默認為128個回滾段
當開啟獨立undo表空間時，指定undo文件存放的目錄
如果我們想轉移undo文件的位置，只需要修改下該配置，並將undo文件拷貝過去就可以了。
2.相關代碼
#在innodb啟動時(innobase_start_or_create_for_mysql)，會進行undo表空間初始化，細節見函數srv_undo_tablespaces_init
–>如果是新建實例，會去創建undo log文件，undo表空間的space id從1開始；默認初始化大小為10M，由宏SRV_UNDO_TABLESPACE_SIZE_IN_PAGES控制;
–>讀取當前實例的所有undo表空間的space id （trx_rseg_get_n_undo_tablespaces）
首先從ibdata中讀取到事務系統的文件頭，然后再從其中記錄的回滾段信息，找到回滾段對應的space id和page no（trx_sysf_rseg_get_space，trx_sysf_rseg_get_page_no），並按照space id排序后返回；
–>根據上一步讀到的space id依次打開undo文件(srv_undo_tablespace_open)，如果不存在，就標識啟動失敗
所以undo文件也是類似ibdata的重要文件，目前是不可以刪除的。。。所以不要試圖刪除undo文件來釋放空間- -!
可以容忍定義的table space個數比已有的undo文件個數要少(但所有的undo文件依然會打開)，反之則報錯初始化失敗
#undo回滾段初始化 （trx_sys_create_rsegs）
如果是正常shutdown重啟，並且設置的回滾段個數大於目前已經使用的回滾段個數(trx_sysf_rseg_find_free)，就會去新建回滾段(trx_rseg_create)
這里總是從第一個undolog tablespace開始初始化回滾段，看起來似乎有些問題，極端情況下，如果我每次重啟遞增innodb_undo_logs，是不是意味着所有的undo回滾段都會寫入到第一個undo tablespace中?
完成初始化后，將當前可用的undo 回滾段的個數復制給srv_available_undo_logs，可以通過show status查看：
root@performance_schema 12:16:18>show status like ‘Innodb_available_undo_logs';
+—————————-+——-+
| Variable_name | Value |
+—————————-+——-+
| Innodb_available_undo_logs | 128 |
+—————————-+——-+
1 row in set (0.00 sec)
啟動后，innodb_undo_logs是可以動態調整的，但最大不可以超過Innodb_available_undo_logs
#在一個非只讀的事務開啟時，會為其分配回滾段(trx_assign_rseg_low)，動態的調整innodb_undo_logs可以限定分配的回滾段范圍；
TODO
當有長時間運行的事務時，可能導致purge操作來不及回收undo空間，進而導致undo空間急劇膨脹；理論上講，如果做一次干凈的shutdown，應該可以安全的將將這些undo文件刪除並重新做一次初始化；也許未來的某個MySQL版本可能實現這個功能，這對於某些服務（比如按磁盤空間收費的雲計算提供商）是非常有必要的功能
轉載自Simple Life