## 介绍
TokuDB也有类似InnoDB的buffer pool叫做cachetable,存储数据节点(包括叶节点和中间节点)和rollback段,本文中为了表达简单,叶节点,中间节点和rollback段统称数据节点。Cachetable是全局唯一的,它与MySQL实例存在一一对应的关系。TokuDB没有采用常见的BTREE(BTREE+,BTREE*)表示索引,而是采用Fractal Tree,简称FT。FT跟BTREE+类似,维护了一个树形的有序结构,中间节点存储pivot(TokuDB的中间节点还包含message buffer),叶节点存储数据。
数据库启动的时候会去初始化cachetable。Client线程(调用栈上下文所在的线程)要访问某个数据节点会首先在cachetable里面查找,找到就立即返回;否则会在cachetable申请一个cache项,然后从磁盘上加载数据到那个cache项。TokuDB里表示cache项的数据结构叫做pair,记录(节点块号/页号,数据节点)的对应关系。在MySQL的缺省引擎InnoDB中,数据和索引是存储在一个文件里的,而TokuDB中每个索引对应一个单独的磁盘文件。
Cachetable是一个hash表,每个bucket里面包含多个pair,共1024*1024个bucket。属于相同索引的pair由cachefile来管理。TokuDB有一个优化在后面会涉及到,这里先简单提一下。当server层显示关闭某个TokuDB表时FT层会调用`toku_cachefile_close`关闭表或者索引,并把缓存的数据节点从cachetable删除;但这些数据节点仍然保留在cachefile中(保留在内存中)。这种cachefile会被加到的stale列表里面,它包含的数据节点会在内存里呆一段时间。近期再次访问这个索引时,首先会在active列表里查找索引对应的cachefile。若没有找到会尝试在stale列表查找并把找到的cachefile的数据节点重新加到cachetable里去。近期再次访问相同的数据集就不必从磁盘上加载了。
## Cachetable的工作线程(worker thead)
Cachetable创建了三个工作线程:
1. evictor线程:释放部分cachetable内存空间;
2. cleaner线程:flush中间节点的message buffer到叶节点;
3. checkpointer线程:写回dirty数据。
## Cachetable的线程池
Cachetable创建了三个线程池:
1. client线程池:帮助cleaner线程flush中间节点的message buffer;
2. cachetable线程池:
* 帮助client线程fetch/partial fetch数据节点
* 帮助evictor线程evict/partial evict数据节点
* 从cachetable删除时,后台删除数据节点
3. checkpoint线程池:帮助client线程写回处于checkpoint_pending状态的数据节点。
## Cachetable的几个主要队列
1. m_clock_head:新加载的数据节点除了加入hash方便快速定位,也会加入此队列。可以理解成cachetable的LRU队列;
2. m_cleaner_head:指向m_clock_head描述LRU队列,cleaner线程从这个位置开始扫描找到memory pressure最大的中间节点发起message buffer flush操作;
3. m_checkpoint_head:指向m_clock_head描述LRU队列,checkpointer线程在begin checkpoint阶段从这个位置开始扫描,把每个数据节点加到m_pending_head队列;
4. m_pending_head:checkpointer线程在end checkpoint阶段从这个位置开始扫描,把ditry数据节点写回到磁盘上。
## Evictor线程
随着数据逐渐加载到cachetable,其消耗的内存空间越来越大,当达到一定程度时evictor工作线程会被唤醒尝试释放一些数据节点。Evitor线程定期运行(缺省1秒)。Evictor定义四个watermark来评价当前cachetable消耗内存的程度:
1. m_low_size_watermark: 达到此watermark以后,evictor线程停止释放内存空间。通俗的说,这就是cachetable消耗内存的上限;
2. m_low_size_hysteresis: 达到此watermark以后,client线程(也就是server层线程)唤醒evictor线程释放内存。一般是m_low_size_watermark的1.1倍;
3. m_high_size_hysteresis: 达到此watermark以后,阻塞的client线程会被唤醒。一般是m_low_size_watermark的1.2倍;
4. m_high_size_watermark:达到此watermark以后,client线程会被阻塞在m_flow_control_cond条件变量上等待evictor线程释放内存。一般是m_low_size_watermark的1.5倍。
### Evictor线程被唤醒的时机
1. 添加新pair;
2. Get pair时,需要fetch或者partial fetch数据节点;
3. Evictor destroy时,唤醒等待的client线程;
4. 释放若干数据节点后,Evictor判断是否要继续运行。
铺垫了这么多,下面一起来看一下evictor线程的主体函数`run_eviction`。`run_eviction`是一个while循环调用`eviction_needed`判断是否要进行eviction。如下所示:m_size_current表示cachetable的当前size,m_size_evicting表示当前正在evicting的数据节点消耗的内存空间。两者的差就是这次eviction运行前,cachetable最终能到达的size。
伪码如下:
~~~
bool eviction_needed() {
return (m_size_current - m_size_evicting) > m_low_size_watermark;
}
void run_eviction(){
uint32_t num_pairs_examined_without_evicting = 0;
while (eviction_needed()) {
if (m_num_sleepers > 0 && should_sleeping_clients_wakeup()) {
/* signal the waiting client threads */
}
bool some_eviction_ran = evict_some_stale_pair();
if (!some_eviction_ran) {
get m_pl->read_list_lock;
if (!curr_in_clock) {
/* nothing to evict */
break;
}
if (num_pairs_examined_without_evicting > m_pl->m_n_in_table) {
/* everything is in use */
break;
}
bool eviction_run = run_eviction_on_pair(curr_in_clock);
if (eviction_run) {
// reset the count
num_pairs_examined_without_evicting = 0;
}
else {
num_pairs_examined_without_evicting++;
}
release m_pl->read_list_lock;
}
}
}
~~~
eviction_needed 返回true时evictor尝试释放内存。它首先看一下当前的cachetable是否降到m_high_size_hysteresis以下,若是就唤醒等待在m_flow_control_cond条件变量上的client线程。然后,cachetable会先尝试回收stale列表里面cachefile上的数据节点。若stale列表里面没有可回收的数据节点,就会从m_clock_head开始尝试回收内存。对于近期没有被访问过的数据节点,会调用`try_evict_pair`尝试回收;否则会使之逐渐退化并尝试partial evict。如果把整个m_clock_head队列扫描一遍都没发现可回收的数据节点,那么这次evictor线程的工作就完成了,等下次被唤醒时再次尝试回收内存。
## Cleaner线程
Cleaner是另一个定期运行(缺省1秒)的工作线程,从m_cleaner_head开始最多扫8个数据节点,从中找到cache pressure最大的节点(这个过程会skip掉正在被其他线程访问的节点)。由于叶节点和rollback段的cache pressure为0,找到的节点一定是中间节点。如果这个节点设置了checkpoint_pending标记,那么需要先调用`write_locked_pair_for_checkpoint`把数据写回再调用`cleaner_callback`把中间节点的message buffer刷到叶节点上去。数据写回的过程,如果节点设置了`clone_callback`,写回是由checkpoint线程池来完成的;没有设置`clone_callback`的情况,写回是由cleaner线程完成的。中间节点flush message buffer是一个很复杂的过程,涉及到message apply和merge等操作,打算另写一篇文章介绍。
伪码如下:
~~~
run_cleaner(){
uint32_t num_iterations = get_iterations(); // by default, iteration == 1
for (uint32_t i = 0; i < num_iterations; ++i) {
get pl->read_list_lock;
PAIR best_pair = NULL;
int n_seen = 0;
long best_score = 0;
const PAIR first_pair = m_cleaner_head;
if (first_pair == NULL) {
/* nothing to clean */
break;
}
/* pick up best_pair */
do {
get m_cleaner_head pair lock;
skip m_cleaner_head if which was being referenced by others
n_seen++;
long score = 0;
bool need_unlock = false;
score = m_cleaner_head cache pressure
if (best_score < score) {
best_score = score;
if (best_pair) {
need_unlock = true;
}
best_pair = m_cleaner_head;
} else {
need_unlock = true;
}
if (need_unlock) {
release m_cleaner_head pair lock;
}
m_cleaner_head = m_cleaner_head->clock_next;
} while (m_cleaner_head != first_pair && n_seen < 8);
release m_pl->read_list_lock;
if (best_pair) {
get best_pair->value_rwlock;
if (best_pair->checkpoint_pending) {
write_locked_pair_for_checkpoint(ct, best_pair, true);
}
bool cleaner_callback_called = false;
if (best_pair cache pressure > 0) {
r = best_pair->cleaner_callback(best_pair->value_data, best_pair->key, best_pair->fullhash, best_pair->write_extraargs);
cleaner_callback_called = true;
}
if (!cleaner_callback_called) {
release best_pair->value_rwlock;
}
}
}
}
~~~
## Checkpointer线程
Cachetable的脏数据是由checkpointer线程定期(缺省60秒)刷到磁盘上。
Checkpointer线程执行过程分为两个阶段:
begin checkpoint阶段
1. 为每个active的cache file打for_checkpoint标记;
2. 写日志;
3. 为每个数据节点打checkpoint_pending标记,并加到m_pending_head队列;
4. clone checkpoint_header: FT的metadata在内存中的数据结构是FT_HEADER,这个header有两个版本:
* h表示当前版本
* checkpoint_header表示当前正在进行checkpoint的版本,是h在checkpoint开始时刻的副本
5. clone BTT(block translation table): TokuDB采用BTT记录逻辑页号(blocknum)到文件offset的映射关系。每次刷新数据节点时申请一个未使用的offset,把脏页刷到新的offset位置上,不覆盖老的数据。
BTT表也采用类似的机制被映射到FT文件不同的offset上。BTT的起始地址记录在FT_HEADER中。checkpoint完成时FT_HEADER会被更新,使新数据生效。用户可以使用checkpoint机制生成backup加速重建数据库的过程。BTT表有三个版本
* 当前版本(_current)
* 正在checkpoint的版本(_inprogress)
* 上次checkpoint的版本(_checkpointed)
end checkpoint阶段
1. 把m_pending_head队列里的数据节点挨个写回到磁盘。写的时候首先检查是否设置`clone_callback`方法,如有调用`clone_callback`生成clone节点,在`clone_callback`里可能会对叶节点做rebalance操作,clone完成后调用`cachetable_only_write_locked_data`把cloned pair写回。没有设置clone_callback的情况会直接调用`cachetable_write_locked_pair`把节点写回。
伪码如下:
~~~
void write_pair_for_checkpoint_thread (evictor* ev, PAIR p) {
get p->value_rwlock.write_lock;
if (p->dirty && p->checkpoint_pending) {
if (p->clone_callback) {
get p->disk_nb_mutex;
clone_pair(ev, p);
} else {
cachetable_write_locked_pair(ev, p, true /* for_checkpoint */);
}
}
p->checkpoint_pending = false;
put p->value_rwlock.write_lock;
if (p->clone_callback) {
cachetable_only_write_locked_data(ev, p, true /* for_checkpoint */,
&attr, true /* is_clone */);
}
}
~~~
2. 调用`checkpoint_userdata`:
* 写回BTT的_inprogress版本
* 写回FT_HEADER的checkpoint_header版本,后面会把checkpoint_header释放掉
3. 调用`end_checkpoint_userdata`:
* 释放BTT _checkpointed版本占用的地址空间
* 把_inprogress版本切换成_checkpointed
- 数据库内核月报目录
- 数据库内核月报 - 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团队