MySQL · 社區動態 · MySQL5.6.26 Release Note解讀 · 數據庫內核月報

最近上游發布了MySQL 5.6.26版本，從Release Note來看，MySQL 5.6版本已經相當成熟，fix的bug數越來越少了。本文主要分析releae note上fix的相關bug，去除performance scheama、mac及windows平臺、企業版、package相關內容。從本期開始，我們會在新版本發布時，在當月的月報上為大家做詳細的版本Release Note分析。 ## InnoDB storage engine 問題描述在類Unix平臺上，當innodb_flush_method設置為O_DIRECT時，函數`os_file_create_simple_no_error_handling_func`沒有使用O_DIRECT方式打開數據文件。例如在函數`fil_node_open_file`中，可能先以函數`os_file_create_simple_no_error_handling_func`打開文件，確定文件的大小，然后關閉文件；再以`os_file_create`打開數據文件，前者使用Buffered IO，后者使用DIRECT IO。這種混合使用可能引發性能問題。根據man手冊建議： > Applications should avoid mixing O_DIRECT and normal I/O to the same file, and especially to overlapping byte regions in handles the coherency issues in this situation, overall I/O the same file. Even when the filesystem correctly throughput is likely to be slower than using either mode of files with direct I/O to the same files.” alone. Likewise, applications should avoid mixing mmap(2) (Bug #21113036, Bug #76627) 解決在函數`os_file_create_simple_no_error_handling_func`?中禁止OS Cache（函數`os_file_set_nocache`）補丁 [b4daac21f52ced96c11632b83445111c0acede56](https://github.com/mysql/mysql-server/commit/b4daac21f52ced96c11632b83445111c0acede56) 問題描述在將一個臟頁從非壓縮page拷貝到壓縮頁后，在寫page到文件時(`buf_flush_write_block_low`)，在設置壓縮頁的修改LSN之前先調用了函數`page_zip_verify_checksum`，由于此時壓縮頁上的LSN為0，而計算出來的checksum也可能為0，此時`page_zip_verify_checksum`認為要嘗試寫入一個空page，返回false，導致斷言失敗(Bug #21086723)。解決先設置LSN，再調用`page_zip_verify_checksum`。補丁 [5b6041b2c7cbee8a1d917631d3a051122b8c4f8d](https://github.com/mysql/mysql-server/commit/5b6041b2c7cbee8a1d917631d3a051122b8c4f8d) 問題描述當以如下序列執行時，實例會crash: ~~~ create database `b`; use b; create table `#mysql50#q.q` select 1; drop database `b`; ~~~ 在創建表時，發現非法的表名，表名被reset成一個空字符串，傳遞到引擎層就是”dbname/”，而引擎層的數據詞典定義中，是通過“dbname/tablename”這樣的字符串來定位的，這就違反了數據詞典的約定。隨后如果執行drop database, 會去遍歷以db名作為前綴的數據詞典項，觸發crash。PS：即使重啟實例，drop database，也無法執行清理操作，用戶線程會不停的在drop db的邏輯里loop(Bug #19929435)。解決在引擎層拒絕創建空的表名。補丁 [8fd710e06024a890e08e35009da541194ca0e5a4](https://github.com/mysql/mysql-server/commit/8fd710e06024a890e08e35009da541194ca0e5a4) 問題描述在函數`innobase_get_foreign_key_info`中，需要根據子表中存儲的父表表名去打開父表，但子表上是根據系統字符集system_charset_info存儲的，而innodb是使用my_charset_filename存儲表名和庫名，因此如果包含父表包含特殊字符，就會造成無法打開父表，導致報錯。(Bug #21094069) 解決將系統字符集的表名和庫名轉換成my_charset_filename格式（tablename_to_filename）。補丁 [1fae0d42c352908fed03e29db2b391a0d2969269](https://github.com/mysql/mysql-server/commit/1fae0d42c352908fed03e29db2b391a0d2969269) 問題描述 * 當一個IO后臺線程為了做ibuf merge，需要讀入對應數據文件的bitmap page時(check 函數`buf_page_io_complete`?–>?`ibuf_merge_or_delete_for_page`),讀取方式為同步讀,?`space->n_pending_ops`遞增； * 另外一個用戶線程準備刪除對應的tablespace，因此將`space->stop_new_ops`設置為true，并等待直到`space->n_pending_ops`為0（`fil_check_pending_operations`）； * 后臺線程嘗試讀入ibuf bitmap page，但由于在`fil_io`函數中，如果發現`space->stop_new_ops`被設置，所有的讀操作都被拒絕，直接返回DB_TABLESPACE_DELETED錯誤，但在函數`ibuf_merge_or_delete_for_page`中總是認為ibuf bitmap page被成功讀入內存，后面直接引用這個page（實際上是空指針），可能會導致實例crash。解決在進行fil_io時，如果表空間正在被刪除(`space->stop_new_ops`被設置為true），不允許異步讀操作，但允許寫操作和同步讀操作。補丁 [3ba4563a757e07c3052c780b63e2626c78ca5c47](https://github.com/mysql/mysql-server/commit/3ba4563a757e07c3052c780b63e2626c78ca5c47) 問題描述當表上的索引存在前綴索引時(prefix index)，對表進行export，再import tablespace可能會失敗，并報Schema mismatch錯誤，錯誤碼為ER_TABLE_SCHEMA_MISMATCH。test case見bug#76877 (Bug #20977779, Bug #76877)。原因是cfg文件和表的索引定義相匹配時邏輯錯誤，例如如下表： ~~~ CREATE TABLE t1 (c1 VARCHAR(128), PRIMARY KEY (c1(16))) ENGINE=InnoDB; ~~~ 在索引對象中定義了4個列：(c1, prefix_len=16), (DB_TRX_ID), (DB_ROLL_PTR)，(c1, prefix_len=0)。 cfg和表索引對象相比較時，其實兩者是一樣的，但cfg在取列時，如果存在相同列名的，總是取第一個，如上例，在比較第四個列的schema是否一致時，取的實際上是第一個，從而產生報錯。參考函數：`row_import::match_index_columns`?((Bug #20977779, Bug #76877))。解決一個列一個列的依次校驗。補丁： [db23392bac27ad3e84319229ee3db9921b734abd](https://github.com/mysql/mysql-server/commit/db23392bac27ad3e84319229ee3db9921b734abd) 問題描述考慮如下場景： 1. purge線程讀取一個undo ，解析出對應的記錄 (`row_purge`?—>?`row_purge_parse_undo_rec`)； 2. 先 purge 二級索引(`row_purge_remove_sec_if_poss`)，再purge聚集索引(`row_purge_remove_clust_if_poss`)； 3. 當 purge 二級索引頁時，需要檢查二級索引記錄是否可以被物理purge掉(`row_purge_remove_sec_if_poss_leaf`)。參考函數：`row_purge_poss_sec` ~~~ can_delete = !row_purge_reposition_pcur(BTR_SEARCH_LEAF, node, &mtr) || !row_vers_old_has_index_entry(TRUE, btr_pcur_get_rec(&node->pcur), &mtr, index, entry, node->roll_ptr, node->trx_id); ~~~ `row_purge_reposition_pcur`定位到聚集索引上，`node->found_clust`設置為true，定位到clust index上的cursor存儲在node->pour上。 * 然后再檢查二級索引記錄是否被標記刪除了，(`row_purge_remove_sec_if_poss_leaf`?—>?`red_get_deleted_flag`)，如果沒有被標記刪除，則報warning。但是步驟3中，即時二級索引沒有被標記刪除，在函數`row_purge_poss_sec`也返回了true，這是因為重新定位cursor的邏輯錯誤。函數`row_purge_reposition_pcur`: ~~~ if (node->found_clust) { ibool found; found = btr_pcur_restore_position(mode, &node->pcur, mtr); return(found); } else { node->found_clust = row_search_on_row_ref( &node->pcur, mode, node->table, node->ref, mtr); if (node->found_clust) { btr_pcur_store_position(&node->pcur, mtr); } } return(node->found_clust); ~~~ 考慮如下序列： 1. purge Index1時，根據node->ref找到對應的聚集索引記錄，node->found_clust設置為true，當前cursor存到node->pour中； 2. 其他用戶線程操作了聚集索引頁，導致在purge index2時，restore position可能失敗，因此返回false； 3. 隨后purge index2，發現node->found_clust為true，依舊用上次restore的position來作restore，依然失敗；在函數`row_purge_reposition_pcur`返回false就認為對應的聚集索引不存在，然后就去嘗試刪除二級索引記錄；但注意這次想purge的二級索引記錄可能是一個新鮮插入的記錄，并沒有被delete mark，我們實際上需要根據node->ref重新定位。解決在函數`row_purge_reposition_pcur`中，若是restore cursor失敗，需要重置node->found_clust為false (Bug #19138298, Bug #70214, Bug #21126772, Bug #21065746) 補丁 [982a157c71667040838def7a00d951ffc55eccbc](https://github.com/mysql/mysql-server/commit/982a157c71667040838def7a00d951ffc55eccbc) [4b8304a9a41c8382d18e084608c33e5c27bec311](https://github.com/mysql/mysql-server/commit/4b8304a9a41c8382d18e084608c33e5c27bec311) [e59914034ab695035c3fe48f046a96bb98d53044](https://github.com/mysql/mysql-server/commit/e59914034ab695035c3fe48f046a96bb98d53044) [92b4683d59c066f099be1d283c7d61b00caeedb2](https://github.com/mysql/mysql-server/commit/92b4683d59c066f099be1d283c7d61b00caeedb2) ## InnoDB 全文索引問題描述嘗試為表上rebuild 全文索引，但表上已經有損壞的索引時，會觸發assert。(Bug #20637494) 解決拋出錯誤，提示用戶先刪掉損壞的索引。返回錯誤碼為ER_INNODB_INDEX_CORRUPT。補丁 [4395ad1755c3ed86c4210f76001a76eb0a69b553](https://github.com/mysql/mysql-server/commit/4395ad1755c3ed86c4210f76001a76eb0a69b553) [3bdb4573e9b25357eea2421647263216c36367cb](https://github.com/mysql/mysql-server/commit/3bdb4573e9b25357eea2421647263216c36367cb) 問題描述構建full-text的表上存在隱藏的FTS_DOC_ID和唯一索引FTS_DOC_ID_INDEX（FTS_DOC_ID），當刪除全文索引時，對應的隱藏列并沒有刪除，但在當前的邏輯中，如果存在FTS_DOC_ID，則不允許ONLINE DDL(Bug #20590013, Bug #76012)。解決當表上只有FTS_DOC_ID_INDEX和FTS_DOC_ID 但沒有定義全文索引時，允許ONLINE DDL。這些隱藏列直到全表rebuild時才被刪除。補丁 [5610e5354a8be6609b2fc2a37902961be26af3cf](https://github.com/mysql/mysql-server/commit/5610e5354a8be6609b2fc2a37902961be26af3cf) ## InnoDB API/Memcached 問題描述 `ib_cursor_moveto`?函數沒有判斷構建的tuple的列個數是否小于索引列個數，而是直接用索引列的個數來做遍歷，可能導致段錯誤(Bug #21121197, Bug #77083)。解決加上對應的判斷。補丁： [d511b503353c1588e90907f59b947e31796c1fc1](https://github.com/mysql/mysql-server/commit/d511b503353c1588e90907f59b947e31796c1fc1) 問題描述 `ib_table_truncate`函數中，當truncate失敗時，沒有正確的釋放事務對象，可能導致shutdown hang住。解決: 總是釋放事務對象。補丁: [aeef8dc2c7af8be4f8ac91be6963e5252e8a9d3f](https://github.com/mysql/mysql-server/commit/aeef8dc2c7af8be4f8ac91be6963e5252e8a9d3f) [e0e1f02d97f54252c1e6ea386dc029560c9f7d08](https://github.com/mysql/mysql-server/commit/e0e1f02d97f54252c1e6ea386dc029560c9f7d08) 問題描述 `ib_open_table_by_id`函數中，已經加了`dict_sys->mutex`鎖，但該函數中調用`dict_table_open_on_id`傳遞的第二個參數為FALSE，認為沒有持有mutex，屬于基本的邏輯錯誤(Bug #21121084, Bug #77100)。解決調整傳參。補丁 [a2353c5d7ff6430e853de435d007ac64d91fd17d](https://github.com/mysql/mysql-server/commit/a2353c5d7ff6430e853de435d007ac64d91fd17d) 上面幾個bug看起來都是非常“低級”的代碼缺陷，這也側面證明了InnoDB API接口在推出后社區用的人實在太少了，這三個Bug都是facebook的工程師提出的，很好奇他們會利用InnoDB API做些什么。問題描述 InnoDB memcached plugin在處理unsigned NOT NULL類型時沒有正確處理，導致返回的數據錯誤。 * 對于unsigned類型，對應的IB_COL_UNSIGNED = 2 * 對于NOT NULL類型，對應的IB_COL_NOT_NULL = 1 但是代碼里很多地方都使用類似`m_col->attr == IB_COL_UNSIGNED`，導致大量的邏輯錯誤(Bug #20535517, Bug #75864)。解決修改成`m_col->attr & IB_COL_UNSIGNED`。補丁： [6ff8d5d2940b9c9079e07641b2beb12e8dd84b38](https://github.com/mysql/mysql-server/commit/6ff8d5d2940b9c9079e07641b2beb12e8dd84b38) ## 復制問題描述當使用多線程復制時，執行STOP SLAVE需要等待所有的worker線程完成其各自的工作隊列中的事務。如果Pending的事務很多，可能要等待很長時間才能完成STOP SLAVE，另外在STOP SLAVE的過程中，是無法SHOW SLAVE STATUS的，一種比較常見的場景就是大量的監控程序SQL堵塞堆積(Bug #75525, Bug #20369401)。解決解決方案是先找到任意worker線程中最新的commit的事務，確定一個上限位點，所有的worker線程執行到這個位置停止，剩下的事務暫時不執行。具體的： 1. 執行STOP SLAVE，coordinator線程首先將所有worker線程的狀態設置成STOP（`slave_stop_workers(rli, &mts_inited)`），并更新`rli->max_updated_index`為最新的已經執行（或正在執行）的事務的group index(`set_max_updated_index_on_stop`)； 2. 所有worker的工作隊列中索引序號小于等于?`rli->max_updated_index`?的事務都需要被執行完，否則worker狀態設置為STOP_ACCEPTED，表示已經完成了max_updated_index 之前的事務，可以退出(`set_max_updated_index_on_stop`)； 3. coordinator線程等待所有worker線程退出，并做一次checkpoint(`slave_stop_workers`?–>?`mts_checkpoint_routine`)。但是上述方案并不能解決正在執行的大事務過慢的問題。補丁 [37f2e969bd36a7455e81ea2350685707bc859866](https://github.com/mysql/mysql-server/commit/37f2e969bd36a7455e81ea2350685707bc859866) 問題描述 MySQL使用InnoDB + binlog做XA的方式來進行crash recovery，但在之前的版本中如果寫Binlog到磁盤發生了錯誤，group commit的邏輯并沒有感知到這個錯誤，而是繼續在引擎層提交事務，備庫沒有接收到對應的Binlog，導致主備數據不一致 (Bug #76795, Bug #20938915)。解決從MySQL 5.6.22版本開始，引入了一個新參數binlog_error_action (5.6.20及21版本叫做binlogging_impossible_mode)，若設置為ABORT_SERVER，則在發生binlog寫入錯誤時直接讓實例退出，避免引發更大的錯誤；若設置為IGNORE_ERROR，則忽略本次寫入失敗，同時禁止Binlog記錄，需要重啟才能讓binlog再次開啟。為了主備數據的強一致性，通常應該將binlog_error_action設置為ABORT_SERVER，這樣在打開文件、rotate新文件、從IO Cache寫binlog到文件出現磁盤錯誤時，都會退出實例。補丁 [3b6b4bf8c5d1bfada58678acebafdf6f813c2dfe](https://github.com/mysql/mysql-server/commit/3b6b4bf8c5d1bfada58678acebafdf6f813c2dfe) 問題描述 relay_log_recovery參數打開時，備庫在重啟時就可以根據SQL線程執行到的位置重新拉binlog，這可以有效處理備庫發生機器宕機導致relay log文件損壞的情況，無需人工去change master，在之前版本中，如果使用了多線程復制，是無法開啟該特性的，在啟動實例時會報如下錯誤： > relay-log-recovery cannot be executed when the slave was stopped with an error or killed in MTS mode 實際上，如果開啟了GTID，就無需關心各個worker線程之間的gap，通過備庫的GTID集合充拉relay log即可(Bug #73397, Bug #19316063)。解決在重啟recovery時檢查是否開啟了GTID。補丁 [fce558959bd0e5af1ae6aac3d8573db00c271dfd](https://github.com/mysql/mysql-server/commit/fce558959bd0e5af1ae6aac3d8573db00c271dfd) 問題描述當兩臺備庫錯誤的配置了相同的server_uuid，并指向同一個主庫時，備庫的IO線程會被頻繁的斷開并嘗試重連。而在備庫來看，并沒有足夠的信息提示產生重連的原因。解決這種場景下，主庫會生產一個錯誤信息傳遞到備庫，當備庫接受到這樣的錯誤信息時不再嘗試重連。(Bug #72581, Bug #18731252) 補丁 [751a3da76dfd66b92395f90f11fce6bd890c9db5](https://github.com/mysql/mysql-server/commit/751a3da76dfd66b92395f90f11fce6bd890c9db5) ## 分區表問題描述 bug被隱藏，無test case，對應release note: > Partitioning: In certain cases, ALTER TABLE … REBUILD PARTITION was not handled correctly when executed on a locked table. (Bug #75677, Bug #20437706) 解決參考commit log. 補丁 [6b0e6683416dc6f8274a460bd2512e7b037ec75f](https://github.com/mysql/mysql-server/commit/6b0e6683416dc6f8274a460bd2512e7b037ec75f) ## 優化器小編對優化器模塊代碼理解不深，感興趣的同學可以自行閱讀對應的bug report及commit log，手動嘗試復現bug。問題描述 > While calculating the cost for doing semjoin_dupsweedout strategy inner_fnout is calculated wrongly when max_outer_fanout becomes 0\. This causes mysql server to exit later (Bug #21184091) 解決 > Calculate the inner_fanout only when max_outer_fanout is > 0\. Else there is no need to recalculate inner_fanout w.r.t max_outer_fanout. 補丁 [bfba2338902a81927d116c30eaa1245eaea025c8](https://github.com/mysql/mysql-server/commit/bfba2338902a81927d116c30eaa1245eaea025c8) 問題描述 > GROUP BY or ORDER BY on a CHAR(0) NOT NULL column could lead to a server exit. (Bug #19660891) > ASSERTION `PARAM.SORT_LENGTH != 0’ FAILED IN SQL/FILESORT.CC:361 解決參考commit log. 補丁： [60c6920509516a1e05b855799479a59c27803191](https://github.com/mysql/mysql-server/commit/60c6920509516a1e05b855799479a59c27803191) [b62c5daa646434290c9b2d1c9b162487cb8edf04](https://github.com/mysql/mysql-server/commit/b62c5daa646434290c9b2d1c9b162487cb8edf04) 問題描述 > When choosing join order, the optimizer could incorrectly calculate the cost of a table scan and choose a table scan over a more efficient eq_ref join. (Bug #71584, Bug #18194196) 解決參考commit log. 補丁： [7a36c155ea3f484799c213a5be5a3deb464251dc](https://github.com/mysql/mysql-server/commit/7a36c155ea3f484799c213a5be5a3deb464251dc) ## 其他問題描述 MySQL String庫下的字符串處理問題，在`cs_values`函數中，對字符串長度的處理存在缺陷，可能導致內存損壞(Bug #20359808)。解決調整長度判斷。補丁 [1cdd3b832ae32d3c236869954f0c7a8a851ed94a](https://github.com/mysql/mysql-server/commit/1cdd3b832ae32d3c236869954f0c7a8a851ed94a) 問題描述當會話斷開或者執行類似change user時，session status會merge到全局status中（`add_to_status(&global_status_var, &status_var)`），但沒有立刻對thd的status_var做reset，這時候另外一個session去查詢global status時，會重復把這些session的status值加到全局。解決在`THD::change_user`、`THD::release_resources`函數中累加到全局status后，重置session的status。補丁 [c8243dd36047debb76134344d761e48f0cedf78e](https://github.com/mysql/mysql-server/commit/c8243dd36047debb76134344d761e48f0cedf78e)