## 前言 在前面幾期月報我們介紹了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： 1. 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`。 2. IBUF_BITMAP_BUFFERED：用于表示該page是否有操作緩存，在`ibuf_insert_low`函數中，準備插入ibuf btree前設置成true。二級索引物理頁讀入內存時會根據該標記位判斷是否需要進行ibuf merge操作。 3. 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`，分為兩步： * Step1: 首先檢查page hash，如果存在于page hash中：1）若未被設置成sentinel （別的線程將數據頁讀入內存時會清理掉對應標記），返回數據頁；2）否則返回NULL； * Step2: 若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數組對象。 2. 判斷是否可以緩存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`），如果是的話，則放棄本次緩存。 3. 何時清理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` 3. 若當前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` 4. 若本次插入ibuf操作可能產生ibuf btree索引分裂（BTR_MODIFY_TREE）時: * 當前ibuf->size 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` 5. 后臺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` 6. 對某個表執行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](https://bugs.mysql.com/bug.php?id=61104)，其現象為當實例意外crash后，無法從崩潰中恢復，錯誤日志中報如下斷言： ~~~ InnoDB: Failing assertion: page_get_n_recs(page) > 1 ~~~ 最初官方花了很長的時間都沒有找到這個問題的root cause，只能加了一些代碼邏輯避免不斷crash重啟，讓用戶有機會登錄實例，重建二級索引。 后來Percona的開發人員Alexey Kopytov在[bug#66819](https://bugs.mysql.com/bug.php?id=66819)?提出了該問題的根本原因，指出ibuf entry的刪除和merge 并不是一個原子的操作（即處于兩個mtr事務中），當merge ibuf的mtr提交后crash，就可能在重啟時重復做ibuf merge。如果上次執行DELETE操作導致對應索引頁上記錄數只剩下一條，第二次apply時認為本次操作會產生空頁，從而導致斷言錯誤。 官方很快根據Alexey的意見做了修復，修復方式也比較簡單： 1. 在第一個mtr里，merge ibuf entry 到二級索引頁，并標記刪除ibuf entry，提交mtr; 2. 在第二個mtr里，執行真正的悲觀刪除ibuf entry; 3. 在執行merge操作前，對于被delete mark的ibuf entry，不做merge操作。 具體的參考函數：`ibuf_merge_or_delete_for_page`?和?`ibuf_delete_rec`。 比較烏龍的是，我們發現第一次修復并沒有處理purge線程產生的delete緩存；我們將該發現公布到社區，很快得到了響應，并由上游快速fix掉了，因此完整的補丁分布在兩個版本中： [官方第一次fix(MySQL5.5.29)](http://bazaar.launchpad.net/~mysql/mysql-server/5.5/revision/3979) [官方第二次fix(MySQL5.5.31)](http://bazaar.launchpad.net/~mysql/mysql-server/5.5/revision/4177)