閱讀210 返回首頁    go 技術社區[雲棲]

MySQL · 引擎特性 · InnoDB undo log 漫遊

本文是對整個Undo生命周期過程的闡述，代碼分析基於當前最新的MySQL5.7版本。本文也可以作為了解整個Undo模塊的代碼導讀。由於涉及到的模塊眾多，因此部分細節並未深入。

前言

Undo log是InnoDB MVCC事務特性的重要組成部分。當我們對記錄做了變更操作時就會產生undo記錄，Undo記錄默認被記錄到係統表空間(ibdata)中，但從5.6開始，也可以使用獨立的Undo 表空間。

Undo記錄中存儲的是老版本數據，當一個舊的事務需要讀取數據時，為了能讀取到老版本的數據，需要順著undo鏈找到滿足其可見性的記錄。當版本鏈很長時，通常可以認為這是個比較耗時的操作（例如bug#69812）。

大多數對數據的變更操作包括INSERT/DELETE/UPDATE，其中INSERT操作在事務提交前隻對當前事務可見，因此產生的Undo日誌可以在事務提交後直接刪除（誰會對剛插入的數據有可見性需求呢！！），而對於UPDATE/DELETE則需要維護多版本信息，在InnoDB裏，UPDATE和DELETE操作產生的Undo日誌被歸成一類，即update_undo。

基本文件結構

為了保證事務並發操作時，在寫各自的undo log時不產生衝突，InnoDB采用回滾段的方式來維護undo log的並發寫入和持久化。回滾段實際上是一種 Undo 文件組織方式，每個回滾段又有多個undo log slot。具體的文件組織方式如下圖所示：

01

上圖展示了基本的Undo回滾段布局結構，其中:

  1. rseg0預留在係統表空間ibdata中;
  2. rseg 1~rseg 32這32個回滾段存放於臨時表的係統表空間中;
  3. rseg33~ 則根據配置存放到獨立undo表空間中（如果沒有打開獨立Undo表空間，則存放於ibdata中）

如果我們使用獨立Undo tablespace，則總是從第一個Undo space開始輪詢分配undo 回滾段。大多數情況下這是OK的，但假設我們將回滾段的個數從33開始依次遞增配置到128，就可能導致所有的回滾段都存放在同一個undo space中。(參考函數trx_sys_create_rsegs 以及 bug#74471)

每個回滾段維護了一個段頭頁，在該page中又劃分了1024個slot(TRX_RSEG_N_SLOTS)，每個slot又對應到一個undo log對象，因此理論上InnoDB最多支持 96 * 1024個普通事務。

關鍵結構體

為了便於管理和使用undo記錄，在內存中維持了如下關鍵結構體對象：

  1. 所有回滾段都記錄在trx_sys->rseg_array，數組大小為128，分別對應不同的回滾段；
  2. rseg_array數組類型為trx_rseg_t，用於維護回滾段相關信息；
  3. 每個回滾段對象trx_rseg_t還要管理undo log信息，對應結構體為trx_undo_t，使用多個鏈表來維護trx_undo_t信息;
  4. 事務開啟時，會專門給他指定一個回滾段，以後該事務用到的undo log頁，就從該回滾段上分配;
  5. 事務提交後，需要purge的回滾段會被放到purge隊列上(purge_sys->purge_queue)。

各個結構體之間的聯係如下：

02

分配回滾段

當開啟一個讀寫事務時（或者從隻讀事務轉換為讀寫事務），我們需要預先為事務分配一個回滾段：

對於隻讀事務，如果產生對臨時表的寫入，則需要為其分配回滾段，使用臨時表回滾段（第1~32號回滾段），函數入口：trx_assign_rseg -->trx_assign_rseg_low-->get_next_noredo_rseg。

在MySQL5.7中事務默認以隻讀事務開啟，當隨後判定為讀寫事務時，則轉換成讀寫模式，並為其分配事務ID和回滾段，調用函數：trx_set_rw_mode -->trx_assign_rseg_low --> get_next_redo_rseg。

普通回滾段的分配方式如下：

  1. 采用round-robin的輪詢方式來賦予回滾段給事務，如果回滾段被標記為skip_allocation（這個undo tablespace太大了，purge線程需要對其進行truncate操作），則跳到下一個；
  2. 選擇一個回滾段給事務後，會將該回滾段的rseg->trx_ref_count遞增，這樣該回滾段所在的undo tablespace文件就不可以被truncate掉；
  3. 臨時表回滾段被賦予trx->rsegs->m_noredo，普通讀寫操作的回滾段被賦予trx->rsegs->m_redo；如果事務在隻讀階段使用到臨時表，隨後轉換成讀寫事務，那麼會為該事務分配兩個回滾段。

使用回滾段

當產生數據變更時，我們需要使用Undo log記錄下變更前的數據以維護多版本信息。insert 和 delete/update 分開記錄undo，因此需要從回滾段單獨分配Undo slot。

入口函數：trx_undo_report_row_operation

流程如下：

  1. 判斷當前變更的是否是臨時表，如果是臨時表，則采用臨時表回滾段來分配，否則采用普通的回滾段；
  2. 臨時表操作記錄undo時不寫redo log；
  3. 操作類型為TRX_UNDO_INSERT_OP，且未分配insert undo slot時，調用函數trx_undo_assign_undo進行分配；
  4. 操作類型為TRX_UNDO_MODIFY_OP，且未分配Update undo slot時，調用函數trx_undo_assign_undo進行分配。

我們來看看函數trx_undo_assign_undo的流程：

  1. 首先總是從cahced list上分配trx_undo_t （函數trx_undo_reuse_cached，當滿足某些條件時，事務提交時會將其擁有的trx_undo_t放到cached list上，這樣新的事務可以重用這些undo 對象，而無需去掃描回滾段，尋找可用的slot，在後麵的事務提交一節會介紹到）；

    • 對於INSERT，從trx_rseg_t::insert_undo_cached上獲取，並修改頭部重用信息（trx_undo_insert_header_reuse）及預留XID空間（trx_undo_header_add_space_for_xid）
    • 對於DELETE/UPDATE，從trx_rseg_t::update_undo_cached上獲取， 並在undo log hdr page上創建新的Undo log header(trx_undo_header_create)，及預留XID存儲空間（trx_undo_header_add_space_for_xid）
    • 獲取到trx_undo_t對象後，會從cached list上移除掉。並初始化trx_undo_t相關信息（trx_undo_mem_init_for_reuse），將trx_undo_t::state設置為TRX_UNDO_ACTIVE

  2. 如果沒有cache的trx_undo_t，則需要從回滾段上分配一個空閑的undo slot（trx_undo_create），並創建對應的undo頁，進行初始化；

    一個回滾段可以支持1024個事務並發，如果不幸回滾段都用完了（通常這幾乎不會發生），會返回錯誤DB_TOO_MANY_CONCURRENT_TRXS

    每一個Undo log segment實際上對應一個獨立的段，段頭的起始位置在UNDO 頭page的TRX_UNDO_SEG_HDR+TRX_UNDO_FSEG_HEADER偏移位置（見下圖）

  3. 已分配給事務的trx_undo_t會加入到鏈表trx_rseg_t::insert_undo_list或者trx_rseg_t::update_undo_list上；

  4. 如果是數據詞典操作（DDL）產生的undo，主要是表級別操作，例如創建或刪除表，還需要記錄操作的table id到undo log header中(TRX_UNDO_TABLE_ID)，同時將TRX_UNDO_DICT_TRANS設置為TRUE。(trx_undo_mark_as_dict_operation)。

總的來說，undo header page主要包括如下信息：
03

如何寫入undo日誌

入口函數：trx_undo_report_row_operation

當分配了一個undo slot，同時初始化完可用的空閑區域後，就可以向其中寫入undo記錄了。寫入的page no取自undo->last_page_no，初始情況下和hdr_page_no相同。

對於INSERT_UNDO，調用函數trx_undo_page_report_insert進行插入，記錄格式大致如下圖所示：
04

對於UPDATE_UNDO，調用函數trx_undo_page_report_modify進行插入，UPDATE UNDO的記錄格式大概如下圖所示：
05

在寫入的過程中，可能出現單頁麵空間不足的情況，導致寫入失敗，我們需要將剛剛寫入的區域清空重置(trx_undo_erase_page_end)，同時申請一個新的page(trx_undo_add_page) 加入到undo log段上，同時將undo->last_page_no指向新分配的page，然後重試。

完成Undo log寫入後，構建新的回滾段指針並返回（trx_undo_build_roll_ptr），回滾段指針包括undo log所在的回滾段id、日誌所在的page no、以及page內的偏移量，需要記錄到聚集索引記錄中。

事務Prepare階段

入口函數：trx_prepare_low

當事務完成需要提交時，為了和BINLOG做XA，InnoDB的commit被劃分成了兩個階段：prepare階段和commit階段，本小節主要討論下prepare階段undo相關的邏輯。

為了在崩潰重啟時知道事務狀態，需要將事務設置為Prepare，MySQL 5.7對臨時表undo和普通表undo分別做了處理，前者在寫undo日誌時總是不需要記錄redo，後者則需要記錄。

分別設置insert undo 和 update undo的狀態為prepare，調用函數trx_undo_set_state_at_prepare，過程也比較簡單，找到undo log slot對應的頭頁麵(trx_undo_t::hdr_page_no)，將頁麵段頭的TRX_UNDO_STATE設置為TRX_UNDO_PREPARED，同時修改其他對應字段，如下圖所示（對於外部顯式XA所產生的XID，這裏不做討論）：
06

Tips：InnoDB層的XID是如何獲取的呢？ 當Innodb的參數innodb_support_xa打開時，在執行事務的第一條SQL時，就會去注冊XA，根據第一條SQL的query id拚湊XID數據，然後存儲在事務對象中。參考函數trans_register_ha。

事務Commit

當事務commit時，需要將事務狀態設置為COMMIT狀態，這裏同樣通過Undo來實現的。

入口函數：trx_commit_low-->trx_write_serialisation_history

在該函數中，需要將該事務包含的Undo都設置為完成狀態，先設置insert undo，再設置update undo（trx_undo_set_state_at_finish），完成狀態包含三種：

  • 如果當前的undo log隻占一個page，且占用的header page大小使用不足其3/4時(TRX_UNDO_PAGE_REUSE_LIMIT)，則狀態設置為TRX_UNDO_CACHED，該undo對象會隨後加入到undo cache list上；
  • 如果是Insert_undo（undo類型為TRX_UNDO_INSERT），則狀態設置為TRX_UNDO_TO_FREE；
  • 如果不滿足a和b，則表明該undo可能需要Purge線程去執行清理操作，狀態設置為TRX_UNDO_TO_PURGE。

在確認狀態信息後，寫入undo header page的TRX_UNDO_STATE中。

如果當前事務包含update undo，並且undo所在回滾段不在purge隊列時，還需要將當前undo所在的回滾段（及當前最大的事務號）加入Purge線程的Purge隊列（purge_sys->purge_queue）中（參考函數trx_serialisation_number_get）。

對於undate undo需要調用trx_undo_update_cleanup進行清理操作，清理的過程包括：

  1. 將undo log加入到history list上，調用trx_purge_add_update_undo_to_history：

  • 如果該undo log不滿足cache的條件（狀態為TRX_UNDO_CACHED，如上述），則將其占用的slot設置為FIL_NULL，意為slot空閑，同時更新回滾段頭的TRX_RSEG_HISTORY_SIZE值，將當前undo占用的page數累加上去；

  • 將當前undo加入到回滾段的TRX_RSEG_HISTORY鏈表上，作為鏈表頭節點，節點指針為UNDO頭的TRX_UNDO_HISTORY_NODE；

  • 更新trx_sys->rseg_history_len（也就是show engine innodb status看到的history list），如果隻有普通的update_undo，則加1，如果還有臨時表的update_undo，則加2，然後喚醒purge線程；

  • 將當前事務的trx_t::no寫入undo頭的TRX_UNDO_TRX_NO段；

  • 如果不是delete-mark操作，將undo頭的TRX_UNDO_DEL_MARKS更新為false;

  • 如果undo所在回滾段的rseg->last_page_no為FIL_NULL，表示該回滾段的舊的清理已經完成，進行如下賦值，記錄這個回滾段上第一個需要purge的undo記錄信息：

       rseg->last_page_no = undo->hdr_page_no;
   rseg->last_offset = undo->hdr_offset;
   rseg->last_trx_no = trx->no;
   rseg->last_del_marks = undo->del_marks;
  1. 如果undo需要cache，將undo對象放到回滾段的update_undo_cached鏈表上；否則釋放undo對象（trx_undo_mem_free）。

注意上麵隻清理了update_undo，insert_undo直到事務釋放記錄鎖、從讀寫事務鏈表清除、以及關閉read view後才進行，調用函數trx_undo_insert_cleanup：

  1. 如果Undo狀態為TRX_UNDO_CACHED，則加入到回滾段的insert_undo_cached鏈表上；

  2. 否則，將該undo所占的segment及其所占用的回滾段的slot全部釋放掉（trx_undo_seg_free），修改當前回滾段的大小(rseg->curr_size)，並釋放undo對象所占的內存（trx_undo_mem_free），和Update_undo不同，insert_undo並未放到History list上。

事務完成提交後，需要將其使用的回滾段引用計數rseg->trx_ref_count減1；

事務回滾

如果事務因為異常或者被顯式的回滾了，那麼所有數據變更都要改回去。這裏就要借助回滾日誌中的數據來進行恢複了。

入口函數為：row_undo_step --> row_undo

操作也比較簡單，析取老版本記錄，做逆向操作即可：對於標記刪除的記錄清理標記刪除標記；對於in-place更新，將數據回滾到最老版本；對於插入操作，直接刪除聚集索引和二級索引記錄（row_undo_ins）。

具體的操作中，先回滾二級索引記錄（row_undo_mod_del_mark_sec、row_undo_mod_upd_exist_sec、row_undo_mod_upd_del_sec），再回滾聚集索引記錄（row_undo_mod_clust）。這裏不展開描述，可以參閱對應的函數。

多版本控製

InnoDB的多版本使用undo來構建，這很好理解，undo記錄中包含了記錄更改前的鏡像，如果更改數據的事務未提交，對於隔離級別大於等於read commit的事務而言，它不應該看到已修改的數據，而是應該給它返回老版本的數據。

入口函數： row_vers_build_for_consistent_read

由於在修改聚集索引記錄時，總是存儲了回滾段指針和事務id，可以通過該指針找到對應的undo 記錄，通過事務Id來判斷記錄的可見性。當舊版本記錄中的事務id對當前事務而言是不可見時，則繼續向前構建，直到找到一個可見的記錄或者到達版本鏈尾部。（關於事務可見性及read view，可以參閱我們之前的月報）

Tips 1：構建老版本記錄（trx_undo_prev_version_build）需要持有page latch，因此如果Undo鏈太長的話，其他請求該page的線程可能等待時間過長導致crash，最典型的就是備庫備份場景：

當備庫使用innodb表存儲複製位點信息時（relay_log_info_repository=TABLE），邏輯備份顯式開啟一個read view並且執行了長時間的備份時，這中間都無法對slave_relay_log_info表做purge操作，導致版本鏈極其長；當開始備份slave_relay_log_info表時，就需要去花很長的時間構建老版本；複製線程由於需要更新slave_relay_log_info表，因此會陷入等待Page latch的場景，最終有可能導致信號量等待超時，實例自殺。 （bug#74003）

Tips 2：在構建老版本的過程中，總是需要創建heap來存儲舊版本記錄，實際上這個heap是可以重用的，無需總是重複構建（bug#69812）

Tips 3：如果回滾段類型是INSERT，就完全沒有必要去看Undo日誌了，因為一個未提交事務的新插入記錄，對其他事務而言總是不可見的。

Tips 4: 對於聚集索引我們知道其記錄中存有修改該記錄的事務id，我們可以直接判斷是否需要構建老版本(lock_clust_rec_cons_read_sees)，但對於二級索引記錄，並未存儲事務id，而是每次更新記錄時，同時更新記錄所在的page上的事務id（PAGE_MAX_TRX_ID），如果該事務id對當前事務是可見的，那麼就無需去構建老版本了，否則就需要去回表查詢對應的聚集索引記錄，然後判斷可見性（lock_sec_rec_cons_read_sees）。

Purge清理操作

從上麵的分析我們可以知道：update_undo產生的日誌會放到history list中，當這些舊版本無人訪問時，需要進行清理操作；另外頁內標記刪除的操作也需要從物理上清理掉。後台Purge線程負責這些工作。

入口函數：srv_do_purge --> trx_purge

  1. 確認可見性

    在開始嚐試purge前，purge線程會先克隆一個最老的活躍視圖（trx_sys->mvcc->clone_oldest_view），所有在readview開啟之前提交的事務所做的事務變更都是可以清理的。

  2. 獲取需要purge的undo記錄（trx_purge_attach_undo_recs）

    從history list上讀取多個Undo記錄，並分配到多個purge線程的工作隊列上（(purge_node_t*) thr->child->undo_recs），默認一次最多取300個undo記錄，可通過參數innodb_purge_batch_size參數調整。

  3. Purge工作線程

    當完成任務的分發後，各個工作線程（包括協調線程）開始進行purge操作
    入口函數： row_purge_step -> row_purge -> row_purge_record_func

    主要包括兩種：一種是記錄直接被標記刪除了，這時候需要物理清理所有的聚集索引和二級索引記錄（row_purge_record_func）；另一種是聚集索引in-place更新了，但二級索引上的記錄順序可能發生變化，而二級索引的更新總是標記刪除 + 插入，因此需要根據回滾段記錄去檢查二級索引記錄序是否發生變化，並執行清理操作（row_purge_upd_exist_or_extern）。

  4. 清理history list

    從前麵的分析我們知道，insert undo在事務提交後，Undo segment 就釋放了。而update undo則加入了history list，為了將這些文件空間回收重用，需要對其進行truncate操作；默認每處理128輪Purge循環後，Purge協調線程需要執行一次purge history List操作。

    入口函數：trx_purge_truncate --> trx_purge_truncate_history

    從回滾段的HISTORY 文件鏈表上開始遍曆釋放Undo log segment，由於history 鏈表是按照trx no有序的，因此遍曆truncate直到完全清除，或者遇到一個還未purge的undo log（trx no比當前purge到的位置更大）時才停止。

關於Purge操作的邏輯實際上還算是比較複雜的代碼模塊，這裏隻是簡單的介紹了下，以後有時間再展開描述。

崩潰恢複

當實例從崩潰中恢複時，需要將活躍的事務從undo中提取出來，對於ACTIVE狀態的事務直接回滾，對於Prepare狀態的事務，如果該事務對應的binlog已經記錄，則提交，否則回滾事務。

實現的流程也比較簡單，首先先做redo (recv_recovery_from_checkpoint_start)，undo是受redo 保護的，因此可以從redo中恢複（臨時表undo除外，臨時表undo是不記錄redo的）。

在redo日誌應用完成後，初始化完成數據詞典子係統（dict_boot），隨後開始初始化事務子係統（trx_sys_init_at_db_start），undo 段的初始化即在這一步完成。

在初始化undo段時(trx_sys_init_at_db_start -> trx_rseg_array_init -> ... -> trx_undo_lists_init)，會根據每個回滾段page中的slot是否被使用來恢複對應的undo log，讀取其狀態信息和類型等信息，創建內存結構，並存放到每個回滾段的undo list上。

當初始化完成undo內存對象後，就要據此來恢複崩潰前的事務鏈表了(trx_lists_init_at_db_start)，根據每個回滾段的insert_undo_list來恢複插入操作的事務(trx_resurrect_insert)，根據update_undo_list來恢複更新事務(tex_resurrect_update)，如果既存在插入又存在更新，則隻恢複一個事務對象。另外除了恢複事務對象外，還要恢複表鎖及讀寫事務鏈表，從而恢複到崩潰之前的事務場景。

當從Undo恢複崩潰前活躍的事務對象後，會去開啟一個後台線程來做事務回滾和清理操作（recv_recovery_rollback_active -> trx_rollback_or_clean_all_recovered），對於處於ACTIVE狀態的事務直接回滾，對於既不ACTIVE也非PREPARE狀態的事務，直接則認為其是提交的，直接釋放事務對象。但完成這一步後，理論上事務鏈表上隻存在PREPARE狀態的事務。

隨後很快我們進入XA Recover階段，MySQL使用內部XA，即通過Binlog和InnoDB做XA恢複。在初始化完成引擎後，Server層會開始掃描最後一個Binlog文件，搜集其中記錄的XID（MYSQL_BIN_LOG::recover），然後和InnoDB層的事務XID做對比。如果XID已經存在於binlog中了，對應的事務需要提交；否則需要回滾事務。

Tips：為何隻需要掃描最後一個binlog文件就可以了？ 因為在每次rotate到一個新的binlog文件之前，總是要保證前一個binlog文件中對應的事務都提交並且sync redo到磁盤了，也就是說，前一個binlog文件中的事務在崩潰恢複時肯定是出於提交狀態的。

最後更新：2017-04-01 13:44:33

  上一篇：go 如何把關聯性的告警智能添加到 Nagios 上？（2）
  下一篇：go SqlServer 時間格式轉換