繼上三期月報:
[MySQL 5.7新特性之一](http://mysql.taobao.org/monthly/2016/05/02/)介紹了一些新特性及兼容性問題
[MySQL 5.7新特性之二](http://mysql.taobao.org/monthly/2016/06/02/)介紹了臨時表的優化和實現
[MySQL 5.7新特性之三](http://mysql.taobao.org/monthly/2016/07/01/)介紹了undo表空間的truncate功能
這期我們一起來學習下MySQL 5.7的并行復制。
### 1\. 背景
MySQL的masterslave的部署結構,使用binlog日志保持數據的同步,全局有序的binlog在備庫按照提交順序進行回放。
由于新硬件的發展,SSD的引入和多core的CPU,master節點的并發處理能力持續提升,slave節點完全按照binlog寫入順序的單線程回放,已完全跟不上master節點的吞吐能力,導致HA切換和數據保護帶來巨大的挑戰。
### 2\. 并行復制的演進
從MySQL5.5版本以后,開始引入并行復制的機制,是MySQL的一個非常重要的特性。
MySQL5.6開始支持以schema為維度的并行復制,即如果binlog row event操作的是不同的schema的對象,在確定沒有DDL和foreign key依賴的情況下,就可以實現并行復制。
社區也有引入以表為維度或者以記錄為維度的并行復制的版本,不管是schema,table或者record,都是建立在備庫slave實時解析row格式的event進行判斷,保證沒有沖突的情況下,進行分發來實現并行。
MySQL5.7的并行復制,multi-threaded slave即MTS,期望最大化還原主庫的并行度,實現方式是在binlog event中增加必要的信息,以便slave節點根據這些信息實現并行復制。
下面我們就來看下MySQL 5.7的實現方式:
### 3\. MySQL 5.7 并行復制
MySQL 5.7的并行復制建立在group commit的基礎上,所有在主庫上能夠完成prepared的語句表示沒有數據沖突,就可以在slave節點并行復制。?
我們先來回顧一下group commit的情況:
~~~
1\. group commit的過程:
1. binlog prepare
2. InnoDB prepare
3. binlog commit(ordered commit)
--3.1 Stage #1: flushing transactions to binary log
--3.2 Stage #2: Syncing binary log file to disk
--3.3 Stage #3: Commit all transactions in order.
4. InnoDB commit
~~~
在ordered commit的過程中:
1\. 由leader線程幫助FLUSH隊列中的線程完成flush binlog操作,
2\. 由leader線程幫助SYNC隊列中的線程完成sync binlog操作,
為了表示主庫并行度,在binlog row event增加了如下的標識:
~~~
#160807 15:48:10 server id 100 end_log_pos 739 CRC32 0x2237b2ef GTID last_committed=0 sequence_number=3
SET @@SESSION.GTID_NEXT= '8108dc48-47de-11e6-8690-a0d3c1f20ae4:3'/*!*/;
~~~
即在gtid_event中增加兩個字段:
~~~
class Gtid_event: public Binary_log_event
{
public:
/*
The transaction's logical timestamps used for MTS: see
Transaction_ctx::last_committed and
Transaction_ctx::sequence_number for details.
Note: Transaction_ctx is in the MySQL server code.
*/
long long int last_committed;
long long int sequence_number;
/**
Ctor of Gtid_event
The layout of the buffer is as follows
+-------------+-------------+------------+---------+----------------+
| commit flag | ENCODED SID | ENCODED GNO| TS_TYPE | logical ts(:s) |
+-------------+-------------+------------+---------+----------------+
TS_TYPE is from {G_COMMIT_TS2} singleton set of values
~~~
代碼中為每一個transaction準備了如下的字段:
~~~
class Transaction_ctx
{
......
int64 last_committed;
int64 sequence_number;
}
~~~
MYSQL_BIN_LOG全局對象中維護了兩個結構:
~~~
class MYSQL_BIN_LOG: public TC_LOG
{
......
/* Committed transactions timestamp */
Logical_clock max_committed_transaction;
/* "Prepared" transactions timestamp */
Logical_clock transaction_counter;
}
~~~
事務中的sequence_number是一個全局有序遞增的數字,每個事務遞增1,來源mysql_bin_log.tranaction_counter.?
和gtid一對一的關系,即在flush階段,和gtid生成的時機一致,代碼參考:
~~~
binlog_cache_data::flush
{
if (flags.finalized) {
Transaction_ctx *trn_ctx= thd->get_transaction();
trn_ctx->sequence_number= mysql_bin_log.transaction_counter.step();
}
.......
mysql_bin_log.write_gtid(thd, this, &writer)))
mysql_bin_log.write_cache(thd, this, &writer);
}
~~~
事務中last_committed表示在這個commit下的事務,都是可以并行的,即沒有沖突,
Transaction_ctx中的last_committed在每個語句prepared的時候進行初始化,來源mysql_bin_log.max_committed_transaction
~~~
static int binlog_prepare(handlerton *hton, THD *thd, bool all)
{
......
Logical_clock& clock= mysql_bin_log.max_committed_transaction;
thd->get_transaction()->
store_commit_parent(clock.get_timestamp());
}
~~~
而mysql_bin_log.max_committed_transaction的更新是在group commit提交的時候進行變更。
~~~
MYSQL_BIN_LOG::process_commit_stage_queue(THD *thd, THD *first)
{
......
for (THD *head= first ; head ; head = head->next_to_commit)
{
if (thd->get_transaction()->sequence_number != SEQ_UNINIT)
update_max_committed(head);
}
}
~~~
即獲取這個group commit隊列中的最大的sequence_number當成當前的max_committed_transaction。
所以,這個機制可以理解成,在group commit完成之前,所有可以成功prepared的語句,沒有事實上的沖突,
分配成相同的last_committed,就可以在slave節點并行復制。
例如下面時序的事務:
~~~
session 1:insert into t1 value(100, 'xpchild');
session 2:insert into t1 value(101, 'xpchild');
session 2:commit
session 1:commit
~~~
Binlog日志片段如下:
~~~
# at 1398
#160807 15:38:14 server id 100 end_log_pos 1463 CRC32 0xd6141f71 GTID last_committed=5 sequence_number=6
SET @@SESSION.GTID_NEXT= '8108dc48-47de-11e6-8690-a0d3c1f20ae4:6'/*!*/;
'/*!*/;
### INSERT INTO `tp`.`t1`
### SET
### @1=101 /* INT meta=0 nullable=0 is_null=0 */
### @2='xpchild' /* VARSTRING(100) meta=100 nullable=1 is_null=0 */
COMMIT/*!*/;
# at 1658
#160807 15:38:24 server id 100 end_log_pos 1723 CRC32 0xa24923a8 GTID last_committed=5 sequence_number=7
SET @@SESSION.GTID_NEXT= '8108dc48-47de-11e6-8690-a0d3c1f20ae4:7'/*!*/;
### INSERT INTO `tp`.`t1`
### SET
### @1=100 /* INT meta=0 nullable=0 is_null=0 */
### @2='xpchild' /* VARSTRING(100) meta=100 nullable=1 is_null=0 */
~~~
兩個insert語句在prepared的時候,沒有事實上的沖突,都獲取當前最大的committed number = 5.
提交的過程中,保持sequence_number生成時候的全局有序性,備庫恢復的時候,這兩個事務就可以并行完成。
但又如下面的case:
~~~
session 1: insert into t1 value(100, 'xpchild');
session 2: insert into t1 value(101, 'xpchild');
session 2: commit;
session 3: insert into t1 value(102, 'xpchild');
session 3: commit;
session 1: commit;
~~~
產生如下的順序:
~~~
#160807 15:47:58 server id 100 end_log_pos 219 CRC32 0x3f295e2b GTID last_committed=0 sequence_number=1
### INSERT INTO `tp`.`t1`
### SET
### @1=101 /* INT meta=0 nullable=0 is_null=0 */
.....
#160807 15:48:05 server id 100 end_log_pos 479 CRC32 0xda52bed0 GTID last_committed=1 sequence_number=2
### INSERT INTO `tp`.`t1`
### SET
### @1=102 /* INT meta=0 nullable=0 is_null=0 */
......
#160807 15:48:10 server id 100 end_log_pos 739 CRC32 0x2237b2ef GTID last_committed=0 sequence_number=3
### INSERT INTO `tp`.`t1`
### SET
### @1=100 /* INT meta=0 nullable=0 is_null=0 */
....
~~~
session 1和session 2語句執行不沖突,分配了相同的last_committed,?
session 2提交,推高了last_committed,所以session 3的laste_committed變成了1,?
最后session 1提交。
注意: 這就是MySQL 5.7.3之后的改進:
在MySQL 5.7.3之前,必須在一個group commit之內的事務,才能夠在slave節點并行復制,但如上面的這個case。
session 1 和session 2雖然commit的時間有差,并且不在一個group commit,生成的binlog也沒有連續,但事實上是可以并行恢復執行的。
所以從MySQL 5.7.3之后,并行恢復,減少了group commit的依賴,但group commit仍然對并行恢復起著非常大的作用。
### 4\. MySQL 5.7 并行復制參數
MySQL 5.7增加了如下參數:
~~~
mysql> show global variables like '%slave_parallel_type%';
+---------------------+---------------+
| Variable_name | Value |
+---------------------+---------------+
| slave_parallel_type | LOGICAL_CLOCK |
+---------------------+---------------+
1 row in set (0.00 sec)
~~~
slave_parallel_type取值:
1\. DATABASE: 默認值,兼容5.6以schema維度的并行復制
2\. LOGICAL_CLOCK: MySQL 5.7基于組提交的并行復制機制
### 5\. MySQL 5.7 并行復制影響因素
group commit delay
首先,并行復制必須建立在主庫的真實負載是并行的基礎上,才能使MTS有機會在slave節點上完成并行復制,
其次,MySQL 5.7前面討論的實現機制,可以人工的增加group commit的delay,打包更多的事務在一起,提升slave復制的并行度。但從5.7.3開始,已經減少了group commit的依賴,
盡量減少delay參數設置對主庫的影響。
合理設置如下參數;
~~~
mysql> show global variables like '%group_commit%';
+-----------------------------------------+--------+
| Variable_name | Value |
+-----------------------------------------+--------+
| binlog_group_commit_sync_delay | 100000 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+--------+
~~~
### 6\. 一點建議
1. 盡量使用row格式的binlog
2. slave_parallel_workers 太多的線程會增加線程間同步的開銷,建議4-8個slave線程,根據測試來最終確定。
3. 如果客戶端有并行度,不用刻意增加master的group commit,減少對主庫的影響。
另外:?
booking在使用的時候遇到的如下case:
數據庫的部署結構是:master->slave1->slave2
假設,當t1,t2,t3,t4四個事務在master group commit中,那么slave1線程就可以并行執行這四個事務,
但在slave1執行的過程中,分成了兩個group commit,那么在slave2節點上,并行度就降低了一倍。
booking給出的后續的解法,如果slave不多,建議都掛載在master上,如果slave過多,考慮使用binlog server,來避免這樣的問題。
但其實在slave1節點上進行并行恢復的時候,保持著主庫的last_committed和sequence_number不變,雖然無法保證binlog寫入的順序完全和主庫一致,但可以緩解這種情況。
- 數據庫內核月報目錄
- 數據庫內核月報 - 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團隊