MySQL·引擎特性·InnoDBChangeBuffer介紹

前言

在前面幾節我們介紹了undo log、redo log以及InnoDB如何崩潰恢復來實現資料ACID的相關知識。本期我們介紹另外一種重要的資料變更日誌，也就是InnoDB change buffer。 Change buffer的主要目的是將對二級索引的資料操作快取下來，以此減少二級索引的隨機IO，並達到操作合併的效果。

在MySQL5.5之前的版本中，由於只支援快取insert操作，所以最初叫做insert buffer，只是後來的版本中支援了更多的操作型別快取，才改叫change buffer。這也是為什麼程式碼中有大量的ibuf字首開頭的函式或變數。為了表達方面，本文也將change buffer縮寫為ibuf。

由於歷史上ibuf的資料格式曾發生過多次變化，本文討論的相關內容基於如下設定：
版本為5.5及之後的版本，不涉及舊版本的邏輯
innodb_change_buffering設定為ALL，表示快取所有操作

ibuf btree

change buffer的物理上是一顆普通的btree，儲存在ibdata系統表空間中，根頁為ibdata的第4個page(FSP_IBUF_TREE_ROOT_PAGE_NO)。

一條ibuf 記錄大概包含如下列：

ibuf btree通過三列(space id, page no , counter)作為主鍵來唯一決定一條記錄， 其中counter是一個遞增值，目的是為了維持不同操作的有序性，例如可以通過counter來保證在merge時執行如下序列時的循序和使用者操作順序是一致的：INSERT x, DELETE-MARK x, INSERT x。

在插入ibuf記錄前我們是不知道counter的值的，因此總是先將對應tuple的counter設定為0xFFFF，然後將cursor以模式PAGE_CUR_LE定位到小於等於(space id, page no, 0xFFFF)的位置，新記錄的counter為當前位置記錄counter值加1。

ibuf btree最大預設為buffer pool size的25%，當超過25%時，可能觸發使用者執行緒同步縮減ibuf btree。為何要將ibuf btree的大小和buffer pool大小相關聯呢 ？ 一個比較重要的原因是防止ibuf本身佔用過多的buffer pool資源。

ibuf bitmap

由於ibuf快取的操作都是針對某個具體page的，因此在快取操作時必須保證該操作不會導致空Page 或索引分裂。

針對第一種情況，即避免空page，主要是對Purge執行緒而言。因為只有Purge執行緒才會去真正的刪除二級索引上的物理記錄。在準備插入型別為IBUF_OP_DELETE的操作快取時，會預估在apply完該page上所有的ibuf entry後還剩下多少記錄（ibuf_get_volume_buffered）， 如果只剩下一條記錄，則拒絕本次purge操作快取，改走正常的讀入物理頁邏輯。

針對第二種情況，InnoDB通過一種特殊的Page來維護每個資料頁的空閒空間大小，也就是ibuf bitmap page，該page存在於每個ibd檔案中，具有固定的page no，其檔案結構如下圖所示：

ibuf bitmap使用4個bit來描述一個page：

(a) IBUF_BITMAP_FREE：使用2個bit來描述空間空間大小，以16KB的Page size為例，能表示的空閒空間範圍為0（0 bytes），1（512 bytes），2（1024 bytes），3（2048 bytes）。很顯然，最大能夠快取的二級索引記錄最大不可能超過2048位元組。

由於只有INSERT操作才可能導致Page記錄滿，因此只需要對IBUF_OP_INSERT型別的操作進行判斷：

ibuf_insert_low:

       if (op == IBUF_OP_INSERT) {
               ulint   bits = ibuf_bitmap_page_get_bits(
                       bitmap_page, page_no, zip_size, IBUF_BITMAP_FREE,
                       &bitmap_mtr);

               if (buffered + entry_size + page_dir_calc_reserved_space(1)
                   > ibuf_index_page_calc_free_from_bits(zip_size, bits)) {
                       /* Release the bitmap page latch early. */
                       ibuf_mtr_commit(&bitmap_mtr);

                       /* It may not fit */
                       do_merge = TRUE;

                       ibuf_get_merge_page_nos(FALSE,
                                               btr_pcur_get_rec(&pcur), &mtr,
                                               space_ids, space_versions,
                                               page_nos, &n_stored);

                       goto fail_exit;
               }
       }

其中ibuf_bitmap_page_get_bits函式根據space id 和page no 獲取對應的bitmap page，找到空閒空間描述資訊；如果本次插入操作可能超出限制，則從當前cursor位置附近開始，觸發一次非同步的ibuf merge，目的是儘量將當前page的快取操作做一次合併。

在正常的對物理頁的DML過程中，如果Page內空間發生了變化，總是需要去更新對應的IBUF_BITMAP_FREE值。參考函式：btr_compress、btr_cur_optimistic_insert。

(b)IBUF_BITMAP_BUFFERED：用於表示該page是否有操作快取，在ibuf_insert_low函式中，準備插入ibuf btree前設定成true。二級索引物理頁讀入記憶體時會根據該標記位判斷是否需要進行ibuf merge操作。

(c) IBUF_BITMAP_IBUF：該資料頁是否是ibuf btree的一部分
該標記位主要用於非同步AIO讀操作。InnoDB專門為change buffer模組分配了一個後臺AIO執行緒，如果page屬於change buffer的b樹，則使用該執行緒做非同步讀，參考函式：ibuf_page_low

操作型別

InnoDB change buffer可以對三種型別的操作進行快取： INSERT、DELETE-MARK 、DELETE操作，前兩種對應使用者執行緒操作，第三種則由Purge操作觸發。

使用者可以通過引數innodb_change_buffering來控制快取何種操作：

/** Allowed values of innodb_change_buffering */
static const char* innobase_change_buffering_values[IBUF_USE_COUNT] = {
        "none",         /* IBUF_USE_NONE */
        "inserts",      /* IBUF_USE_INSERT */
        "deletes",      /* IBUF_USE_DELETE_MARK */
        "changes",      /* IBUF_USE_INSERT_DELETE_MARK */
        "purges",       /* IBUF_USE_DELETE */
        "all"           /* IBUF_USE_ALL */
};

innodb_change_buffering預設值為all，表示快取所有操作。注意由於在二級索引上的更新操作總是先delete-mark，再insert新記錄，因此update會產生兩條Ibuf entry。

快取條件

只有滿足一定條件時，操作才會被快取，所有對ibuf操作的判斷，都從btr_cur_search_to_nth_level入口，該函式用於定位到btree上滿足條件的記錄，大概的判斷條件如下：

1. 使用者設定了選項innodb_change_buffering；
2. 只有葉子節點才會去考慮是否使用ibuf；
3. 對於聚集索引，不可以快取操作；
4. 對於唯一二級索引(unique key)，由於索引記錄具有唯一性，因此無法快取插入操作，但可以快取刪除操作；
5. 表上沒有flush 操作，例如執行flush table for export時，不允許對錶進行ibuf 快取 （通過dict_table_t::quiesce 進行標識）

參考函式：ibuf_should_try

當滿足ibuf快取條件時，會使用兩種模式去嘗試獲取資料頁：

BUF_GET_IF_IN_POOL： 如果資料頁在記憶體中，則獲取page並返回，否則返回NULL；
BUF_GET_IF_IN_POOL_OR_WATCH：如果資料頁在記憶體中，則獲取page並返回，否則為請求的page設定一個`sentinel`(buf_pool_watch_set)，相當於標記這個page，表示這個page上的記錄正在被purge。(下一小節介紹)

前者是前臺使用者執行緒觸發，後者為Purge執行緒在物理清除無效資料時觸發。如果資料已經在記憶體中了，則不進行快取。

隨後進入函式ibuf_insert， 經過一系列的檢查後（不可產生空page 和 索引分裂、未超出最大ibuf size限制）執行操作快取。

Purge操作快取

對於Purge操作，當page不存在於記憶體時設定的sentinel是什麼鬼？ 它是如何設定的，什麼時候會被清理掉，這幾個問題涉及到Purge操作的快取流程：

1. 如何設定sentinel

當Purge執行緒嘗試讀入page時，若資料頁不在buffer pool中，則呼叫函式buf_pool_watch_set，分為兩步：

Step 1. 首先檢查page hash，如果存在於page hash中：1. 若未被設定成`sentinel` （別的執行緒將資料頁讀入記憶體時會清理掉對應標記），返回資料頁；2. 否則返回NULL；

Step 2. 若page hash中不存在，則從buf_pool_t::watch陣列中找到一個空閒的（狀態為BUF_BLOCK_POOL_WATCH）page控制結構體物件buf_page_t，將其狀態設定為BUF_BLOCK_ZIP_PAGE，初始化相關變數，並插入到page hash中。buf_pool_t::watch陣列的大小為purge執行緒的個數，這意味著即使所有purge執行緒同時訪問同一個buffer pool instance，總會擁有一個空閒的watch陣列物件。

1. 判斷是否可以快取Purge操作

當設定sentinel並返回後，在決定快取purge之前，需要去判斷是否有別的執行緒對同一條記錄快取了新的操作，舉個簡單的例子：

Step 1: delete-mark X (sec index), session 1
Step 2: insert X (clust index), session 1
Step 3: delete X(sec index), Purge thread
Step 4: insert X (sec index), session 1

如果二級索引頁在記憶體中，那麼step 3 和Step4必然是有序的，因為需要獲取block鎖才能進行資料變更操作。但資料頁不在記憶體時，就需要確保Step 4在Step 3之後執行。因此在快取purge操作之前，需要根據當前要清理的記錄，找到對應的聚集索引記錄，並檢查相比當前Purge執行緒的readview是否有新版本的聚集索引記錄（即有新的插入操作發生）。

如果檢查到有新的插入，則本次purge操作直接放棄。因為當符合一定條件時，Step 4的操作可以直接把Step1產生的記錄刪除標記清除掉，重用物理空間。

參考函式：row_purge_poss_sec

但是注意上述檢查流程結束時，會在函式row_purge_poss_sec中將mtr提交掉，對應的聚集索引頁的Latch會被釋放掉，這意味著可能出現如下序列：

Step 1: delete-mark X；
Step 2: delete X，Purge執行緒為其設定watch，並完成在函式row_purge_poss_sec中的檢查，準備插入ibuf
Step 3: insert X，索引頁不在記憶體，準備插入Ibuf

在函式ibuf_insert中，針對IBUF_OP_INSERT和IBUF_OP_DELETE_MARK操作，會去檢查是否對應的二級索引頁被設定成‘sentinel’ （buf_page_get_also_watch），如果是的話，表明當前有一個pending的purge操作，目前的處理邏輯是放棄insert和delete-mark的快取操作，轉而讀取物理頁。

綜上，如果purge操作先進入ibuf_insert，則對應二級索引頁的watch必然被設定，insert操作將放棄快取，轉而嘗試讀入索引頁；如果insert先進入ibuf_insert，則Purge操作的快取放棄。

即使Purge執行緒完成一系列檢查，進入快取階段，這時候使用者執行緒依舊可能會去讀入物理頁；有沒有可能導致purge操作丟失呢 ？答案是否定的！ 因為Purge執行緒在快取操作時先將cursor定位到ibuf btree上，對應的ibuf page已將加上latch；而使用者執行緒如果讀入物理頁，為了Merge ibuf entry，也需要請求page latch； 當Purge執行緒在拿到latch後，會再檢查一次看看物理頁是否已讀入記憶體（buf_pool_watch_occurred），如果是的話，則放棄本次快取。

1. 何時清理sentinel

有兩種情況會清理sentinel：
第一種情況是Purge操作完成快取後（或者判斷無法進行Purge快取）進行清理。

第二種情況是從磁碟讀入檔案塊的時候，會呼叫buf_page_init_for_read->buf_page_init初始化一個page物件。這時候會做一個判斷，如果將被讀入的page被設定為sentinel(在watch陣列中被設定)，則呼叫buf_pool_watch_remove將其從page hash中移除，對應bp->watch的資料元素被重置成空閒狀態。

ibuf merge

有以下幾種場景會觸發ibuf merge操作：

1. 使用者執行緒選擇二級索引進行資料查詢，這時候必須要讀入二級索引頁，相應的ibuf entry需要merge到Page中。
2. 當嘗試快取插入操作時，如果預估Page的空間不足，可能導致索引分裂，則定位到嘗試快取的page no在ibuf btree中的位置，最多Merge 8個(IBUF_MERGE_AREA) page， merge方式為非同步，即發起非同步讀索引頁請求。

參考函式：ibuf_insert_low —> ibuf_get_merge_page_nos_func

1. 若當前ibuf tree size 超過ibuf->max_size + 10（IBUF_CONTRACT_DO_NOT_INSERT）時，執行一次同步的ibuf merge（ibuf_contract），merge的page no為隨機定位的cursor，最多一次merge 8個page， 同時放棄本次快取。

其中ibuf->max_size預設為25% * buffer pool size，百分比由引數innodb_change_buffer_max_size控制，可動態調整。

參考函式：ibuf_insert_low —> ibuf_contract

1. 若本次插入ibuf操作可能產生ibuf btree索引分裂（BTR_MODIFY_TREE）時

   當前ibuf->size < ibuf->max_size， 不做處理;
   
   當前ibuf->size >= ibuf->max_size + 5 (IBUF_CONTRACT_ON_INSERT_SYNC)時，執行一次同步ibuf merge，位置隨機;
   
   當前Ibuf->size介於ibuf->max_size 和ibuf->max_size +5 之間時。執行一次非同步ibuf merge，位置隨機。
   

參考函式：ibuf_insert_low —> ibuf_contract_after_insert

1. 後臺master執行緒發起merge

master執行緒有三種工作狀態：

IDLE：例項處於空閒狀態，以100%的io capacity來作merge操作：

n_pages = PCT_IO(100);

相當於一次merge的page數等於innodb_io_capacity

參考函式：srv_master_do_idle_tasks

ACTIVE：例項處於活躍狀態，這時候會以如下演算法計算需要merge的page數：

                /* By default we do a batch of 5% of the io_capacity */
                n_pages = PCT_IO(5);

                mutex_enter(&ibuf_mutex);

                /* If the ibuf->size is more than half the max_size
                then we make more agreesive contraction.
                +1 is to avoid division by zero. */
                if (ibuf->size > ibuf->max_size / 2) {
                        ulint diff = ibuf->size - ibuf->max_size / 2;
                        n_pages += PCT_IO((diff * 100)
                                           / (ibuf->max_size + 1));
                }

                mutex_exit(&ibuf_mutex);

可見在系統active時，會以比較溫和的方式去做merge，如果當前ibuf btree size超過最大值的一半，則嘗試多做一些merge操作。

參考函式： srv_master_do_active_tasks

SHUTDOWN：當執行slow shutdown時，會強制做一次全部的ibuf merge

參考函式：srv_master_do_shutdown_tasks

1. 對某個表執行flush table 操作時，會觸發對該表的強制ibuf merge，例如執行：

   flush table tbname for export;
   flush table tbname with read lock;

實際上強制ibuf merge主要是為flush for export準備的，當執行該命令後，為了保證能安全的將ibd拷貝到其他例項上， 需要對該表應用全部的ibuf 快取。

參考函式：row_quiesce_table_start

“著名” bug

在change buffer的應用史上，最著名的bug要屬 bug#61104，其現象為當例項意外crash後，無法從崩潰中恢復，錯誤日誌中報如下斷言：

InnoDB: Failing assertion: page_get_n_recs(page) > 1

最初官方花了很長的時間都沒有找到這個問題的root cause，只能加了一些程式碼邏輯避免不斷crash重啟，讓使用者有機會登入例項，重建二級索引。

後來Percona的開發人員Alexey Kopytov在bug#66819 提出了該問題的根本原因，指出ibuf entry的刪除和merge 並不是一個原子的操作（即處於兩個mtr事務中），當merge ibuf的mtr提交後crash，就可能在重啟時重複做ibuf merge。如果上次執行DELETE操作導致對應索引頁上記錄數只剩下一條；第二次apply時認為本次操作會產生空頁，從而導致斷言錯誤。

官方很快根據Alexey的意見做了修復，修復方式也比較簡單：

在第一個mtr裡，merge ibuf entry 到二級索引頁，並標記刪除ibuf entry，提交mtr;
在第二個mtr裡，執行真正的悲觀刪除ibuf entry;
在執行merge操作前，對於被delete mark的ibuf entry，不做merge操作。

具體的參考函式：ibuf_merge_or_delete_for_page 和 ibuf_delete_rec

比較烏龍的是，我們發現第一次修復並沒有處理Purge執行緒產生的delete快取；我們將該發現公佈到社群，很快得到了響應，並由上游快速fix掉了，因此完整的補丁分佈在兩個版本中：

官方第一次fix(MySQL5.5.29)
官方第二次fix(MySQL5.5.31)