## 背景
在mysql主備環境下,主備同步過程如下,主庫更新產生binlog, 備庫io線程拉取主庫binlog生成relay log。備庫sql線程執行relay log從而保持和主庫同步。

理論上主庫有更新時,備庫都存在延遲,且延遲時間為備庫執行時間+網絡傳輸時間即t4-t2。
那么mysql是怎么來計算備庫延遲的?
先來看show slave status中的一些信息,io線程拉取主庫binlog的位置:
~~~
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 107
~~~
sql線程執行relay log的位置:
~~~
Relay_Log_File: slave-relay.000003
Relay_Log_Pos: 253
~~~
sql線程執行的relay log相對于主庫binlog的位置:
~~~
Relay_Master_Log_File: mysql-bin.000001
Exec_Master_Log_Pos: 107
~~~
## 源碼實現
Seconds_Behind_Master計算的源碼實現如下:
~~~
if ((mi->get_master_log_pos() == mi->rli->get_group_master_log_pos()) &&
(!strcmp(mi->get_master_log_name(), mi->rli->get_group_master_log_name())))
{
if (mi->slave_running == MYSQL_SLAVE_RUN_CONNECT)
protocol->store(0LL);
else
protocol->store_null();
}
else
{
long time_diff= ((long)(time(0) - mi->rli->last_master_timestamp)
- mi->clock_diff_with_master);
protocol->store((longlong)(mi->rli->last_master_timestamp ? max(0L, time_diff) : 0));
}
~~~
大致可以看出是通過時間和位點來計算的,下面詳細分析下。
if里面條件表示如果io線程拉取主庫binlog的位置和sql線程執行的relay log相對于主庫binlog的位置相等,那么認為延遲為0。一般情況下,io線程比sql線程快。但如果網絡狀況特別差,導致sql線程需等待io線程的情況,那么這兩個位點可能相等,會導致誤認為延遲為0。
再看else里:
* `clock_diff_with_master`
io線程啟動時會向主庫發送sql語句“SELECT UNIX_TIMESTAMP()”,獲取主庫當前時間,然而用備庫當前時間減去此時間或者主備時間差值即為`clock_diff_with_master`。這里如果有用戶中途修改了主庫系統時間或修改了timestamp變量,那么計算出備庫延遲時間就是不準確的。
* `last_master_timestamp`
表示主庫執行binlog事件的時間。此時間在并行復制和非并行復制時的計算方法是不同的
非并行復制:
備庫sql線程讀取了relay log中的event,event未執行之前就會更新`last_master_timestamp`,這里時間的更新是以event為單位。
~~~
rli->last_master_timestamp= ev->when.tv_sec + (time_t) ev->exec_time;
~~~
ev->when.tv_sec表示事件的開始時間。exec_time指事件在主庫的執行時間,只有`Query_log_event`和`Load_log_event`才會統計exec_time。
另外一種情況是sql線程在等待io線程獲取binlog時,會將`last_master_timestamp`設為0,按上面的算法Seconds_Behind_Master為0,此時任務備庫是沒有延遲的。
并行復制:
> 并行復制有一個分發隊列gaq,sql線程將binlog事務讀取到gaq,然后再分發給worker線程執行。并行復制時,binlog事件是并發穿插執行的,gaq中有一個checkpoint點稱為lwm, lwm之前的binlog都已經執行,而lwm之后的binlog有些執行有些沒有執行。
> 假設worker線程數為2,gap有1,2,3,4,5,6,7,8個事務。worker 1已執行的事務為1 4 6, woker 2執行的事務為2 3 ,那么lwm為4。
并行復制更新gap checkpiont時,會推進lwm點,同時更新`last_master_timestamp`為lwm所在事務結束的event的時間。因此,并行復制是在事務執行完成后才更新`last_master_timestamp`,更新是以事務為單位。同時更新gap checkpiont還受`slave_checkpoint_period`參數的影響。
這導致并行復制下和非并行復制統計延遲存在差距,差距可能為`slave_checkpoint_period`?+ 事務在備庫執行的時間。這就是為什么在并行復制下有時候會有很小的延遲,而改為非并行復制時反而沒有延遲的原因。
另外當sql線程等待io線程時且gaq隊列為空時,會將`last_master_timestamp`設為0。同樣此時認為沒有延遲,計算得出`seconds_Behind_Master`為0。
## 位點信息維護
* io線程拉取binlog的位點
~~~
Master_Log_File 讀取到主庫ROTATE_EVENT時會更新(process_io_rotate)
Read_Master_Log_Pos:io線程每取到一個event都會從event中讀取pos信息并更新
mi->set_master_log_pos(mi->get_master_log_pos() + inc_pos);
~~~
* sql線程執行relay log的位置
~~~
Relay_Log_File
sql線程處理ROTATE_EVENT時更新(Rotate_log_event::do_update_pos)
Relay_Log_Pos:
非并行復制時,每個語句執行完成更新(stmt_done)
并行復制時,事務完成時更新(Rotate_log_event::do_update_pos/ Xid_log_event::do_apply_event/stmt_done)
~~~
* sql線程執行的relay log相對于主庫binlog的位置
~~~
Relay_Master_Log_File
sql線程處理ROTATE_EVENT時更新(Rotate_log_event::do_update_pos)
Exec_Master_Log_Pos 和Relay_Log_Pos同時更新
非并行復制時,每個語句執行完成更新(stmt_done)
并行復制時,事務完成時更新(Rotate_log_event::do_update_pos/ Xid_log_event::do_apply_event/stmt_done)
~~~
談到位點更新就有必要說到兩個事件:HEARTBEAT_LOG_EVENT 和 ROTATE_EVENT。
* HEARTBEAT_LOG_EVENT
HEARTBEAT_LOG_EVENT我們的了解一般作用是,在主庫沒有更新的時候,每隔`master_heartbeat_period`時間都發送此事件保持主庫與備庫的連接。而HEARTBEAT_LOG_EVENT另一個作用是,在gtid模式下,主庫有些gtid備庫已經執行同時,這些事件雖然不需要再備庫執行,但讀取和應用binglog的位點還是要推進。因此,這里將這類event轉化為HEARTBEAT_LOG_EVENT,由HEARTBEAT_LOG_EVENT幫助我們推進位點。
* ROTATE_EVENT
主庫binlog切換產生的ROTATE_EVENT,備庫io線程收到時會也有切換relay log。此rotate也會記入relay log,sql線程執行ROTATE_EVENT只更新位點信息。備庫io線程接受主庫的HEARTBEAT_LOG_EVENT,一般不用戶處理。前面提到,gtid模式下,當HEARTBEAT_LOG_EVENT的位點大于當前記錄的位點時,會構建一個ROTATE_EVENT,從而讓sql線程推進位點信息。
~~~
if (mi->is_auto_position() && mi->get_master_log_pos() < hb。log_pos
&& mi->get_master_log_name() != NULL)
{
mi->set_master_log_pos(hb。log_pos);
write_ignored_events_info_to_relay_log(mi->info_thd, mi); //構建ROTATE_EVENT
......
}
~~~
另外,在`replicate_same_server_id`為0時,備庫接收到的binlog與主庫severid相同時,備庫會忽略此binlog,但位點仍然需要推進。為了效率,此binlog不需要記入relay log。而是替換為ROTATE_EVENT來推進位點。
## 延遲現象
初始主備是同步的,且沒有任何更新。假設主備庫執行某個DDL在都需要30s,執行某個大更新事務(例如insert..select * from )需要30s。
不考慮網絡延遲。

* 非并行復制時
執行DDL:t2時刻主庫執行完,t2時刻備庫執行show slave status,Seconds_Behind_Master值為0。同時t2至t3 Seconds_Behind_Master依次增大至30,然后跌0。
執行大事務:t2時刻主庫執行完,t2時刻備庫執行show slave status,Seconds_Behind_Master值為30。同時t2至t3 Seconds_Behind_Master依次增大至60,然后跌0。
以上區別的原因是exec_time只有`Query_log_event`和`Load_log_event`才會統計,普通更新沒有統計導致。
* 并行復制時
執行DDL:t2時刻主庫執行完,t2至t3備庫執行show slave status,Seconds_Behind_Master值一直為0
執行大事務:t2時刻主庫執行完,t2至t3備庫執行show slave status,Seconds_Behind_Master值一直為0
這是因為執行語句之前主備是完全同步的,gaq隊列為空,會將`last_master_timestamp`設為0。而執行DDL過程中,gap checkpoint一直沒有推進,`last_master_timestamp`一直未0,直到DDL或大事務完成。
所以t2至t3時刻Seconds_Behind_Master值一直為0。而t3時刻有一瞬間`last_master_timestamp`是會重置的,但又因`slave_checkpoint_period`會推進checkpoint,gaq隊列變為空,會將`last_master_timestamp`重設為0。
因此t3時刻可能看到瞬間有延遲(對于DDL是延遲30s,對于大事務時延遲60s)。
這似乎很不合理,gaq隊列為空,會將`last_master_timestamp`設為0,這條規則實際可以去掉。
## 相關bug
[BUG#72376](http://bugs.mysql.com/bug%E3%80%82php?id=72376), PREVIOUS_GTIDS_LOG_EVENT 事件記錄在每個binlog的開頭,表示先前所有文件的gtid集合。relay-log本身event記錄是主庫的時間,但relay log開頭的PREVIOUS_GTIDS_LOG_EVENT事件,是在slave端生成的,時間也是以slave為準的。因此不能用此時間計算`last_master_timestamp`。修復方法是在relay log寫PREVIOUS_GTIDS_LOG_EVENT事件是標記是relay log產生的,在統計`last_master_timestamp`時,發現是relay產生的事件則忽略統計。
~~~
if (is_relay_log)
prev_gtids_ev。set_relay_log_event();
......
if (!(ev->is_artificial_event()||...))
rli->last_master_timestamp= ev->when。tv_sec + (time_t) ev->exec_time;
~~~
## 總結
Seconds_Behind_Master的計算并不準確和可靠。并行復制下Seconds_Behind_Master值比非并行復制時偏大。因此當我們判斷備庫是否延遲時,根據Seconds_Behind_Master=0不一定可靠。但是,當我們進行主備切換時,在主庫停寫的情況下,我們可以根據位點來判斷是否完全同步。
如果(Relay_Master_Log_File, Exec_Master_Log_Pos)和(Relay_Master_Log_File, Read_Master_Log_Pos)位置相等且Seconds_Behind_Master=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團隊