## 背景
InnoDB buffer pool中的page管理牽涉到兩個鏈表,一個是lru鏈表,一個是flush 臟塊鏈表,由于數據庫的特性:
1. 臟塊的刷新,是異步操作;
2. page存在兩個版本,一個是ibd文件的持久化版本,和buffer pool內存中的當前版本。
所以在對table對象進行ddl變更的時候,要維護兩個版本之間的一致性,有一些操作需要同步進行page緩存的管理。例如以下三種ddl操作:
1\. flush table t for export
這是MySQL 5.6提供的InnoDB transportable tablespace功能,用于在不同實例之間進行表傳輸。由于需要透明的在物理層面遷移ibd文件,所以需要保證buffer pool中的page和ibd文件中的page的一致性。其操作步驟如下:
1. 持有t表的MDL鎖,保證在t表上沒有活躍事務,即buffer pool中的臟page都是已提交事務;
2. 掃描buffer pool中的flush list,同步刷下臟塊;
3. 記錄數據字典信息到cfg文件,用于目標端的表結構匹配和驗證,最后在目標端import的時候,變更page的space,max_lsn等。
2\. drop table t
在對表進行刪除的時候,需要清理掉buffer pool中的page,但如果表比較大,占用過多的buffer pool,清理的動作會影響到在線的業務,所以MySQL提供了lazy drop table的方式。
1. 同步方式: 掃描lru鏈表,如果page屬于t表,就從lru鏈表,hash表, flush list中刪除,回收block到free list中。
2. lazy方式: 掃描lru鏈表,如果page屬于t表,就給page設置一個`space_was_being_deleted`屬性,等lru置換或者checkpoint flush dirty block的時候進行清理。
3\. alter table t rename to t1
rename table name操作,雖然是DDL,但rename操作只是變更了數據字典中的table name和文件系統的ibd文件名稱,所以,在rename的過程中,不存在對buffer pool中屬于t表的page的同步操作,但由于要變更表名,即需要同步對文件的IO操作。
而今天要講的主題,就發生在這里,由于rename table進行IO操作同步的過程中,產生的死鎖。
## 問題現象
在MySQL 5.5版本上,error日志大量報出以下的錯誤信息:
~~~
InnoDB: fil_sys open file LRU len 0
InnoDB: Warning: too many (300) files stay open while the maximum
InnoDB: allowed value would be 300.
InnoDB: You may need to raise the value of innodb_open_files in my.cnf.
...
InnoDB: Warning: problems renaming 'db_1/#sql-xxx_xxx' to 'db_1/xxx', 1000 iterations
InnoDB: Warning: tablespace './db_1/#sql-xxx_xxx.ibd' has i/o ops stopped for a long time 1000
~~~
查看操作日志,是一個普通的rename語句操作,但持續很久,因為rename只是數據字典的變更,除了MDL鎖阻塞以外
不應該持續這么長時間,pstack查看線程棧信息:
~~~
Thread 5 (Thread 0x50ad7940 (LWP 25047)):
#0 0x000000364aacced2 in select () from /lib64/libc.so.6
#1 0x00002aaab2e595fb in os_thread_sleep ()
#2 0x00002aaab2e1a3e2 in fil_rename_tablespace ()
#3 0x00002aaab2e0672b in dict_table_rename_in_cache ()
#4 0x00002aaab2e86af5 in row_rename_table_for_mysql ()
#5 0x00002aaab2e316db in ha_innodb::rename_table ()
#6 0x00000000006bea6c in mysql_rename_table ()
#7 0x00000000006c77ff in mysql_alter_table ()
#8 0x00000000005c6a8e in mysql_execute_command ()
#9 0x00000000005cd371 in mysql_parse ()
#10 0x00000000005cd773 in dispatch_command ()
#11 0x00000000005cea04 in do_command ()
#12 0x00000000005bf0d7 in handle_one_connection ()
#13 0x000000364b6064a7 in start_thread () from /lib64/libpthread.so.0
#14 0x000000364aad3c2d in clone () from /lib64/libc.so.6
Thread 100 (Thread 0x42945940 (LWP 3870)):
#0 0x000000364b60ab99 in pthread_cond_wait@@GLIBC_2.3.2 ()
#1 0x00002aaab2e589a5 in os_event_wait_low ()
#2 0x00002aaab2e57dd4 in os_aio_simulated_handle ()
#3 0x00002aaab2e14ccc in fil_aio_wait ()
#4 0x00002aaab2ea2418 in io_handler_thread ()
#5 0x000000364b6064a7 in start_thread () from /lib64/libpthread.so.0
#6 0x000000364aad3c2d in clone () from /lib64/libc.so.6
Thread 120 (Thread 0x40da6940 (LWP 3882)):
#0 0x000000364aacced2 in select () from /lib64/libc.so.6
#1 0x00002aaab2e595fb in os_thread_sleep ()
#2 0x00002aaab2e18838 in fil_mutex_enter_and_prepare_for_io ()
#3 0x00002aaab2e18aa5 in fil_io ()
#4 0x00002aaab2df5b63 in buf_flush_buffered_writes ()
#5 0x00002aaab2df6048 in buf_flush_batch ()
#6 0x00002aaab2ea13d8 in srv_master_thread ()
#7 0x000000364b6064a7 in start_thread () from /lib64/libpthread.so.0
#8 0x000000364aad3c2d in clone () from /lib64/libc.so.6
~~~
這里我只列了有意義的三個線程:
1. 用戶線程Thread 5
用戶線程確實在進行rename操作,但阻塞在`fil_rename_tablespace`函數中。
2. master線程Thread 120
InnoDB的master線程阻塞在`fil_mutex_enter_and_prepare_for_io`函數中。
3. IO線程Thread 100
InnoDB的IO線程一共有8個,4個讀,4個寫線程,發現都在`os_event_wait_low`中,也就是都空閑著等待condition中。
從上面的調用棧來看,線程之間長時間維持在這種狀態下,明顯發生了死鎖,在我們解這個死鎖之前,我們先來回顧一點背景知識,然后再說明死鎖的真正原因。
## InnoDB背景
### checkpoint
由于對數據庫的數據操作也遵循read-update-write的方式,所以數據的更新,會把buffer pool中的page變成臟塊,由于write-ahead logs機制保證事務的完整性,臟塊的write可以變成異步的,但又由于buffer pool的大小終究有限,而且對于recovery的時間的要求,又要求臟塊的flush又要持續保證。
MySQL 5.5的版本由master thread來承擔dirty flush的角色, dirty flush的過程就稱為making checkpoint,lsn的推進保證了recovery的時間不被持續的變長。刷新的策略,受到當前IO pending的情況,double write-buffer是否打開,buffer pool中dirty page所占的比例,以及`innodb_max_dirty_pages_pct`參數的設置,進行靈活刷新,具體的代碼細節,這里就不展開了。
### 異步IO
由于dirty flush是異步的,所以,master thread只負責提交IO請求,真正的IO操作是由IO helper thread來完成的。InnoDB使用的simulate AIO和native AIO會有一些差別,我們這里以simulate AIO為例進行說明。假設double write-buffer是打開的:
1. 首先master thread搜集dirty pages,同步寫入double write-buffer;
2. 由于double write-buffer的方式是buffered write,所以等double write-buffer寫滿了之后;
3. 同步把double write-buffer的page順序寫入到ibdata系統表空間中,如果完成之后系統crash,可以使用持久化的double write-buffer進行page恢復;
4. 開始把 double write-buffer中的page,寫入真正的ibd文件中。依次提交異步IO操作,提交IO操作的步驟分為:
* 持有fil_system mutex,判斷當前tablespace是否可用,
* 判斷當前fil_space的stop_io標示,如果設置就循環等待
* 如果stop_io沒有標示,就打開fil_space對應的ibd文件句柄,然后遞增 fil_space->n_pending
* 提交IO請求
5. 等double write-buffer中的pages提交完所有的IO請求,使用`os_aio_simulated_wake_handler_threads`來喚醒IO helper thread來完成IO操作。
### Rename 操作
接下來我們來看下rename操作的步驟:
1. 首先在server層hold MDL鎖;
2. 進入InnoDB層,首先使用自治事務變更數據字典,包括SYS_TABLES,SYS_FOREIGN;
3. 變更數據字典的內存對象,包括table, index, foreign list等;
4. 變更fil_space對象以及對應的ibd數據文件名稱,其中變更文件系統名稱的時候:
* 設置當前的fil_space的stop_io,阻止再進行IO操作
* 判斷當前是否有IO pending,如果有,就等IO pending結束
* 如果沒有IO pending,就關閉opened的句柄,并rename文件名稱
* 恢復stop_io標示
5. 提交自治事務。
有了這些操作的具體步驟,我們就可以清晰的分析出死鎖的原因。
## 死鎖原因
兩個線程,一個是master thread,需要提交flush dirty block的異步IO請求;一個是user thread,需要進行rename操作。
Rename操作,只變更數據字典和ibd文件名,并不需要同步buffer pool中的page,唯一需要同步的就是IO操作,通俗一點說,也就是在user thread進行rename table需要變更ibd文件名的時候,其它線程暫時不要對這個文件進行IO操作,等rename完成后,可以重新打開這個ibd文件,接著進行IO操作。
InnoDB使用兩個標識來進行IO同步操作,即stop_io,n_pending。
stop_io:user thread要進行rename操作,提前設置這個標識,表示IO操作可以先hold暫停。
n_pending:master thread要進行flush操作,我已經提交了IO請求,user thread要進行rename可以先hold,等IO完成。
假設下面的時序:
1. master thread提交了1個IO請求,設置了n_pending;
2. rename操作設置stop_io,判斷n_pending>0 就等待;
3. master thread需要提交剩下的幾個IO,發現stop_io已設置,就等待;
4. 由于master thread沒有提交完這批IO,沒有喚醒IO helper thread,導致第1個IO請求無法完成,n_pending一直等于1;
5. rename操作因為n_pending一直等于1,陷入了死等;
6. master thread發現stop_io等于true,陷入了死等。
具體的代碼可以參考:
1\. master thread
fil0fil.cc:?`fil_mutex_enter_and_prepare_for_io`
~~~
space = fil_space_get_by_id(space_id);
if (space != NULL && space->stop_ios) {
/* We are going to do a rename file and want to stop new i/o's for a while */
if (count2 > 20000) {
fputs("InnoDB: Warning: tablespace ", stderr);
ut_print_filename(stderr, space->name);
fprintf(stderr,
" has i/o ops stopped for a long time %lu\n",
(ulong) count2);
}
mutex_exit(&fil_system->mutex);
os_thread_sleep(20000);
count2++;
goto retry;
}
~~~
2\. user thread
fil0fil.cc:?`fil_rename_tablespace`
~~~
/* We temporarily close the .ibd file because we do not trust that
operating systems can rename an open file. For the closing we have to
wait until there are no pending i/o's or flushes on the file. */
space->stop_ios = TRUE;
ut_a(UT_LIST_GET_LEN(space->chain) == 1);
node = UT_LIST_GET_FIRST(space->chain);
if (node->n_pending > 0 || node->n_pending_flushes > 0) {
/* There are pending i/o's or flushes, sleep for a while and retry */
mutex_exit(&fil_system->mutex);
os_thread_sleep(20000);
goto retry;
~~~
## 修復方法
修復的方法也比較簡單,在`fil_rename_tablespace`的時候,如果發現node->n_pending > 0的時候,在sleep之前,發起一次喚醒動作,即`os_aio_simulated_wake_handler_threads`,IO helper thread去完成master thread已經提交的IO請求,這樣n_pending就會降到0,死鎖就解開了。
- 數據庫內核月報目錄
- 數據庫內核月報 - 2016/09
- MySQL · 社區貢獻 · AliSQL那些事兒
- PetaData · 架構體系 · PetaData第二代低成本存儲體系
- MySQL · 社區動態 · MariaDB 10.2 前瞻
- MySQL · 特性分析 · 執行計劃緩存設計與實現
- PgSQL · 最佳實踐 · pg_rman源碼淺析與使用
- MySQL · 捉蟲狀態 · bug分析兩例
- PgSQL · 源碼分析 · PG優化器淺析
- MongoDB · 特性分析· Sharding原理與應用
- PgSQL · 源碼分析 · PG中的無鎖算法和原子操作應用一則
- SQLServer · 最佳實踐 · TEMPDB的設計
- 數據庫內核月報 - 2016/08
- MySQL · 特性分析 ·MySQL 5.7新特性系列四
- PgSQL · PostgreSQL 邏輯流復制技術的秘密
- MySQL · 特性分析 · MyRocks簡介
- GPDB · 特性分析· Greenplum 備份架構
- SQLServer · 最佳實踐 · RDS for SQLServer 2012權限限制提升與改善
- TokuDB · 引擎特性 · REPLACE 語句優化
- MySQL · 專家投稿 · InnoDB物理行中null值的存儲的推斷與驗證
- PgSQL · 實戰經驗 · 旋轉門壓縮算法在PostgreSQL中的實現
- MySQL · 源碼分析 · Query Cache并發處理
- PgSQL · 源碼分析· pg_dump分析
- 數據庫內核月報 - 2016/07
- MySQL · 特性分析 ·MySQL 5.7新特性系列三
- MySQL · 特性分析 · 5.7 代價模型淺析
- PgSQL · 實戰經驗 · 分組TOP性能提升44倍
- MySQL · 源碼分析 · 網絡通信模塊淺析
- MongoDB · 特性分析 · 索引原理
- SQLServer · 特性分析 · XML與JSON應用比較
- MySQL · 最佳實戰 · 審計日志實用案例分析
- MySQL · 性能優化 · 條件下推到物化表
- MySQL · 源碼分析 · Query Cache內部剖析
- MySQL · 捉蟲動態 · 備庫1206錯誤問題說明
- 數據庫內核月報 - 2016/06
- MySQL · 特性分析 · innodb 鎖分裂繼承與遷移
- MySQL · 特性分析 ·MySQL 5.7新特性系列二
- PgSQL · 實戰經驗 · 如何預測Freeze IO風暴
- GPDB · 特性分析· Filespace和Tablespace
- MariaDB · 新特性 · 窗口函數
- MySQL · TokuDB · checkpoint過程
- MySQL · 特性分析 · 內部臨時表
- MySQL · 最佳實踐 · 空間優化
- SQLServer · 最佳實踐 · 數據庫實現大容量插入的幾種方式
- 數據庫內核月報 - 2016/05
- MySQL · 引擎特性 · 基于InnoDB的物理復制實現
- MySQL · 特性分析 · MySQL 5.7新特性系列一
- PostgreSQL · 特性分析 · 邏輯結構和權限體系
- MySQL · 特性分析 · innodb buffer pool相關特性
- PG&GP · 特性分析 · 外部數據導入接口實現分析
- SQLServer · 最佳實踐 · 透明數據加密在SQLServer的應用
- MySQL · TokuDB · 日志子系統和崩潰恢復過程
- MongoDB · 特性分析 · Sharded cluster架構原理
- PostgreSQL · 特性分析 · 統計信息計算方法
- MySQL · 捉蟲動態 · left-join多表導致crash
- 數據庫內核月報 - 2016/04
- MySQL · 參數故事 · innodb_additional_mem_pool_size
- GPDB · 特性分析 · Segment事務一致性與異常處理
- GPDB · 特性分析 · Segment 修復指南
- MySQL · 捉蟲動態 · 并行復制外鍵約束問題二
- PgSQL · 性能優化 · 如何瀟灑的處理每天上百TB的數據增量
- Memcached · 最佳實踐 · 熱點 Key 問題解決方案
- MongoDB · 最佳實踐 · 短連接Auth性能優化
- MySQL · 最佳實踐 · RDS 只讀實例延遲分析
- MySQL · TokuDB · TokuDB索引結構--Fractal Tree
- MySQL · TokuDB · Savepoint漫談
- 數據庫內核月報 - 2016/03
- MySQL · TokuDB · 事務子系統和 MVCC 實現
- MongoDB · 特性分析 · MMAPv1 存儲引擎原理
- PgSQL · 源碼分析 · 優化器邏輯推理
- SQLServer · BUG分析 · Agent 鏈接泄露分析
- Redis · 特性分析 · AOF Rewrite 分析
- MySQL · BUG分析 · Rename table 死鎖分析
- MySQL · 物理備份 · Percona XtraBackup 備份原理
- GPDB · 特性分析· GreenPlum FTS 機制
- MySQL · 答疑解惑 · 備庫Seconds_Behind_Master計算
- MySQL · 答疑解惑 · MySQL 鎖問題最佳實踐
- 數據庫內核月報 - 2016/02
- MySQL · 引擎特性 · InnoDB 文件系統之文件物理結構
- MySQL · 引擎特性 · InnoDB 文件系統之IO系統和內存管理
- MySQL · 特性分析 · InnoDB transaction history
- PgSQL · 會議見聞 · PgConf.Russia 2016 大會總結
- PgSQL · 答疑解惑 · PostgreSQL 9.6 并行查詢實現分析
- MySQL · TokuDB · TokuDB之黑科技工具
- PgSQL · 性能優化 · PostgreSQL TPC-C極限優化玩法
- MariaDB · 版本特性 · MariaDB 的 GTID 介紹
- MySQL · 特性分析 · 線程池
- MySQL · 答疑解惑 · mysqldump tips 兩則
- 數據庫內核月報 - 2016/01
- MySQL · 引擎特性 · InnoDB 事務鎖系統簡介
- GPDB · 特性分析· GreenPlum Primary/Mirror 同步機制
- MySQL · 專家投稿 · MySQL5.7 的 JSON 實現
- MySQL · 特性分析 · 優化器 MRR & BKA
- MySQL · 答疑解惑 · 物理備份死鎖分析
- MySQL · TokuDB · Cachetable 的工作線程和線程池
- MySQL · 特性分析 · drop table的優化
- MySQL · 答疑解惑 · GTID不一致分析
- PgSQL · 特性分析 · Plan Hint
- MariaDB · 社區動態 · MariaDB on Power8 (下)
- 數據庫內核月報 - 2015/12
- MySQL · 引擎特性 · InnoDB 事務子系統介紹
- PgSQL · 特性介紹 · 全文搜索介紹
- MongoDB · 捉蟲動態 · Kill Hang問題排查記錄
- MySQL · 參數優化 ·RDS MySQL參數調優最佳實踐
- PgSQL · 特性分析 · 備庫激活過程分析
- MySQL · TokuDB · 讓Hot Backup更完美
- PgSQL · 答疑解惑 · 表膨脹
- MySQL · 特性分析 · Index Condition Pushdown (ICP)
- MariaDB · 社區動態 · MariaDB on Power8
- MySQL · 特性分析 · 企業版特性一覽
- 數據庫內核月報 - 2015/11
- MySQL · 社區見聞 · OOW 2015 總結 MySQL 篇
- MySQL · 特性分析 · Statement Digest
- PgSQL · 答疑解惑 · PostgreSQL 用戶組權限管理
- MySQL · 特性分析 · MDL 實現分析
- PgSQL · 特性分析 · full page write 機制
- MySQL · 捉蟲動態 · MySQL 外鍵異常分析
- MySQL · 答疑解惑 · MySQL 優化器 range 的代價計算
- MySQL · 捉蟲動態 · ORDER/GROUP BY 導致 mysqld crash
- MySQL · TokuDB · TokuDB 中的行鎖
- MySQL · 捉蟲動態 · order by limit 造成優化器選擇索引錯誤
- 數據庫內核月報 - 2015/10
- MySQL · 引擎特性 · InnoDB 全文索引簡介
- MySQL · 特性分析 · 跟蹤Metadata lock
- MySQL · 答疑解惑 · 索引過濾性太差引起CPU飆高分析
- PgSQL · 特性分析 · PG主備流復制機制
- MySQL · 捉蟲動態 · start slave crash 診斷分析
- MySQL · 捉蟲動態 · 刪除索引導致表無法打開
- PgSQL · 特性分析 · PostgreSQL Aurora方案與DEMO
- TokuDB · 捉蟲動態 · CREATE DATABASE 導致crash問題
- PgSQL · 特性分析 · pg_receivexlog工具解析
- MySQL · 特性分析 · MySQL權限存儲與管理
- 數據庫內核月報 - 2015/09
- MySQL · 引擎特性 · InnoDB Adaptive hash index介紹
- PgSQL · 特性分析 · clog異步提交一致性、原子操作與fsync
- MySQL · 捉蟲動態 · BUG 幾例
- PgSQL · 答疑解惑 · 詭異的函數返回值
- MySQL · 捉蟲動態 · 建表過程中crash造成重建表失敗
- PgSQL · 特性分析 · 談談checkpoint的調度
- MySQL · 特性分析 · 5.6 并行復制恢復實現
- MySQL · 備庫優化 · relay fetch 備庫優化
- MySQL · 特性分析 · 5.6并行復制事件分發機制
- MySQL · TokuDB · 文件目錄談
- 數據庫內核月報 - 2015/08
- MySQL · 社區動態 · InnoDB Page Compression
- PgSQL · 答疑解惑 · RDS中的PostgreSQL備庫延遲原因分析
- MySQL · 社區動態 · MySQL5.6.26 Release Note解讀
- PgSQL · 捉蟲動態 · 執行大SQL語句提示無效的內存申請大小
- MySQL · 社區動態 · MariaDB InnoDB表空間碎片整理
- PgSQL · 答疑解惑 · 歸檔進程cp命令的core文件追查
- MySQL · 答疑解惑 · open file limits
- MySQL · TokuDB · 瘋狂的 filenum++
- MySQL · 功能分析 · 5.6 并行復制實現分析
- MySQL · 功能分析 · MySQL表定義緩存
- 數據庫內核月報 - 2015/07
- MySQL · 引擎特性 · Innodb change buffer介紹
- MySQL · TokuDB · TokuDB Checkpoint機制
- PgSQL · 特性分析 · 時間線解析
- PgSQL · 功能分析 · PostGIS 在 O2O應用中的優勢
- MySQL · 引擎特性 · InnoDB index lock前世今生
- MySQL · 社區動態 · MySQL內存分配支持NUMA
- MySQL · 答疑解惑 · 外鍵刪除bug分析
- MySQL · 引擎特性 · MySQL logical read-ahead
- MySQL · 功能介紹 · binlog拉取速度的控制
- MySQL · 答疑解惑 · 浮點型的顯示問題
- 數據庫內核月報 - 2015/06
- MySQL · 引擎特性 · InnoDB 崩潰恢復過程
- MySQL · 捉蟲動態 · 唯一鍵約束失效
- MySQL · 捉蟲動態 · ALTER IGNORE TABLE導致主備不一致
- MySQL · 答疑解惑 · MySQL Sort 分頁
- MySQL · 答疑解惑 · binlog event 中的 error code
- PgSQL · 功能分析 · Listen/Notify 功能
- MySQL · 捉蟲動態 · 任性的 normal shutdown
- PgSQL · 追根究底 · WAL日志空間的意外增長
- MySQL · 社區動態 · MariaDB Role 體系
- MySQL · TokuDB · TokuDB數據文件大小計算
- 數據庫內核月報 - 2015/05
- MySQL · 引擎特性 · InnoDB redo log漫游
- MySQL · 專家投稿 · MySQL數據庫SYS CPU高的可能性分析
- MySQL · 捉蟲動態 · 5.6 與 5.5 InnoDB 不兼容導致 crash
- MySQL · 答疑解惑 · InnoDB 預讀 VS Oracle 多塊讀
- PgSQL · 社區動態 · 9.5 新功能BRIN索引
- MySQL · 捉蟲動態 · MySQL DDL BUG
- MySQL · 答疑解惑 · set names 都做了什么
- MySQL · 捉蟲動態 · 臨時表操作導致主備不一致
- TokuDB · 引擎特性 · zstd壓縮算法
- MySQL · 答疑解惑 · binlog 位點刷新策略
- 數據庫內核月報 - 2015/04
- MySQL · 引擎特性 · InnoDB undo log 漫游
- TokuDB · 產品新聞 · RDS TokuDB小手冊
- PgSQL · 社區動態 · 說一說PgSQL 9.4.1中的那些安全補丁
- MySQL · 捉蟲動態 · 連接斷開導致XA事務丟失
- MySQL · 捉蟲動態 · GTID下slave_net_timeout值太小問題
- MySQL · 捉蟲動態 · Relay log 中 GTID group 完整性檢測
- MySQL · 答疑釋惑 · UPDATE交換列單表和多表的區別
- MySQL · 捉蟲動態 · 刪被引用索引導致crash
- MySQL · 答疑釋惑 · GTID下auto_position=0時數據不一致
- 數據庫內核月報 - 2015/03
- MySQL · 答疑釋惑· 并發Replace into導致的死鎖分析
- MySQL · 性能優化· 5.7.6 InnoDB page flush 優化
- MySQL · 捉蟲動態· pid file丟失問題分析
- MySQL · 答疑釋惑· using filesort VS using temporary
- MySQL · 優化限制· MySQL index_condition_pushdown
- MySQL · 捉蟲動態·DROP DATABASE外鍵約束的GTID BUG
- MySQL · 答疑釋惑· lower_case_table_names 使用問題
- PgSQL · 特性分析· Logical Decoding探索
- PgSQL · 特性分析· jsonb類型解析
- TokuDB ·引擎機制· TokuDB線程池
- 數據庫內核月報 - 2015/02
- MySQL · 性能優化· InnoDB buffer pool flush策略漫談
- MySQL · 社區動態· 5.6.23 InnoDB相關Bugfix
- PgSQL · 特性分析· Replication Slot
- PgSQL · 特性分析· pg_prewarm
- MySQL · 答疑釋惑· InnoDB丟失自增值
- MySQL · 答疑釋惑· 5.5 和 5.6 時間類型兼容問題
- MySQL · 捉蟲動態· 變量修改導致binlog錯誤
- MariaDB · 特性分析· 表/表空間加密
- MariaDB · 特性分析· Per-query variables
- TokuDB · 特性分析· 日志詳解
- 數據庫內核月報 - 2015/01
- MySQL · 性能優化· Group Commit優化
- MySQL · 新增特性· DDL fast fail
- MySQL · 性能優化· 啟用GTID場景的性能問題及優化
- MySQL · 捉蟲動態· InnoDB自增列重復值問題
- MySQL · 優化改進· 復制性能改進過程
- MySQL · 談古論今· key分區算法演變分析
- MySQL · 捉蟲動態· mysql client crash一例
- MySQL · 捉蟲動態· 設置 gtid_purged 破壞AUTO_POSITION復制協議
- MySQL · 捉蟲動態· replicate filter 和 GTID 一起使用的問題
- TokuDB·特性分析· Optimize Table
- 數據庫內核月報 - 2014/12
- MySQL· 性能優化·5.7 Innodb事務系統
- MySQL· 踩過的坑·5.6 GTID 和存儲引擎那會事
- MySQL· 性能優化·thread pool 原理分析
- MySQL· 性能優化·并行復制外建約束問題
- MySQL· 答疑釋惑·binlog event有序性
- MySQL· 答疑釋惑·server_id為0的Rotate
- MySQL· 性能優化·Bulk Load for CREATE INDEX
- MySQL· 捉蟲動態·Opened tables block read only
- MySQL· 優化改進· GTID啟動優化
- TokuDB· Binary Log Group Commit with TokuDB
- 數據庫內核月報 - 2014/11
- MySQL· 捉蟲動態·OPTIMIZE 不存在的表
- MySQL· 捉蟲動態·SIGHUP 導致 binlog 寫錯
- MySQL· 5.7改進·Recovery改進
- MySQL· 5.7特性·高可用支持
- MySQL· 5.7優化·Metadata Lock子系統的優化
- MySQL· 5.7特性·在線Truncate undo log 表空間
- MySQL· 性能優化·hash_scan 算法的實現解析
- TokuDB· 版本優化· 7.5.0
- TokuDB· 引擎特性· FAST UPDATES
- MariaDB· 性能優化·filesort with small LIMIT optimization
- 數據庫內核月報 - 2014/10
- MySQL· 5.7重構·Optimizer Cost Model
- MySQL· 系統限制·text字段數
- MySQL· 捉蟲動態·binlog重放失敗
- MySQL· 捉蟲動態·從庫OOM
- MySQL· 捉蟲動態·崩潰恢復失敗
- MySQL· 功能改進·InnoDB Warmup特性
- MySQL· 文件結構·告別frm文件
- MariaDB· 新鮮特性·ANALYZE statement 語法
- TokuDB· 主備復制·Read Free Replication
- TokuDB· 引擎特性·壓縮
- 數據庫內核月報 - 2014/09
- MySQL· 捉蟲動態·GTID 和 DELAYED
- MySQL· 限制改進·GTID和升級
- MySQL· 捉蟲動態·GTID 和 binlog_checksum
- MySQL· 引擎差異·create_time in status
- MySQL· 參數故事·thread_concurrency
- MySQL· 捉蟲動態·auto_increment
- MariaDB· 性能優化·Extended Keys
- MariaDB·主備復制·CREATE OR REPLACE
- TokuDB· 參數故事·數據安全和性能
- TokuDB· HA方案·TokuDB熱備
- 數據庫內核月報 - 2014/08
- MySQL· 參數故事·timed_mutexes
- MySQL· 參數故事·innodb_flush_log_at_trx_commit
- MySQL· 捉蟲動態·Count(Distinct) ERROR
- MySQL· 捉蟲動態·mysqldump BUFFER OVERFLOW
- MySQL· 捉蟲動態·long semaphore waits
- MariaDB·分支特性·支持大于16K的InnoDB Page Size
- MariaDB·分支特性·FusionIO特性支持
- TokuDB· 性能優化·Bulk Fetch
- TokuDB· 數據結構·Fractal-Trees與LSM-Trees對比
- TokuDB·社區八卦·TokuDB團隊