## TokuDB日志子系统
MySQL重启后自动加载InnoDB和其他的动态plugin,包括TokuDB。每一plugin在注册的时候指定init和deinit回调函数。TokuDB的init/deinit函数分别是`tokudb_init_func`和`tokudb_done_func`。
MySQL重启过程中调用`tokudb_init_func`进行必要的初始化。在`tokudb_init_func`里面,调用`db_env_create`创建一个env实例,进行参数设置和callback设置。`db_env_create`是一个简单的封装,最终会调用`toku_env_create`来进行参数设置,callback设置和初始化的。`toku_env_create`初始化工作中一个很重要的事情就是调用`toku_logger_create`初始化TokuDB的日志子系统。
在TokuDB中,日志子系统是由tokulogger数据结构管理的。下面仅列出了主要的数据成员。
~~~
struct tokulogger {
struct mylock input_lock; // 保护lsn和in_buf的mutex
toku_mutex_t output_condition_lock; // 保护written_lsn ,fsynced_lsn ,等待out_buf可用的条件变量的mutex
toku_cond_t output_condition; // 等待out_buf可用的条件变量
bool output_is_available; // 标志out_buf可用的条件
bool is_open; // 标志logger是否已打开
bool write_log_files; // 标示是否将redo log buffer写到redo log file
bool trim_log_files; // 标志是否要trim redo log file
char *directory; // redo log所在目录
int lg_max; // redo log最大长度,缺省100M
LSN lsn; // 下一个可用的lsn
struct logbuf inbuf; // 接收redo log entry的buffer
LSN written_lsn; // 最后一次写入的lsn
LSN fsynced_lsn; // 最后一次fsync的lsn
LSN last_completed_checkpoint_lsn; // 最近一次checkpoint开始时刻的logger的lsn
long long next_log_file_number; // 下一个可用的redo log file的序列号
struct logbuf outbuf; // 写入redo log file的buf
int n_in_file; // 当前redo log file存储日志的字节数
TOKULOGFILEMGR logfilemgr; // log file manager的handle
TXN_MANAGER txn_manager; // txn manager的handle
};
~~~
### Logger初始化
Logger子系统在env->create阶段由`toku_logger_create`进行初步的初始化工作。代码片段如下:
~~~
int toku_logger_create (TOKULOGGER *resultp) {
TOKULOGGER CALLOC(result);
if (result==0) return get_error_errno();
result->is_open=false;
result->write_log_files = true;
result->trim_log_files = true;
result->directory=0;
result->lg_max = 100<<20; // 100MB default
// lsn is uninitialized
result->inbuf = (struct logbuf) {0, LOGGER_MIN_BUF_SIZE, (char *) toku_xmalloc(LOGGER_MIN_BUF_SIZE), ZERO_LSN};
result->outbuf = (struct logbuf) {0, LOGGER_MIN_BUF_SIZE, (char *) toku_xmalloc(LOGGER_MIN_BUF_SIZE), ZERO_LSN};
// written_lsn is uninitialized
// fsynced_lsn is uninitialized
result->last_completed_checkpoint_lsn = ZERO_LSN;
// next_log_file_number is uninitialized
// n_in_file is uninitialized
toku_logfilemgr_create(&result->logfilemgr);
*resultp=result;
ml_init(&result->input_lock);
toku_mutex_init(&result->output_condition_lock, NULL);
toku_cond_init(&result->output_condition, NULL);
result->output_is_available = true;
return 0;
}
~~~
Logger子系统在env->open阶段,调用`toku_logger_open`函数进行进一步的初始化。函数`toku_logger_open`是`toku_logger_open_with_last_xid`的简单封装。Env->open最终调用`toku_logger_open_with_last_xid`解析redo log file获取下一个可用的lsn,下一个可用的redo log file的序列号index并打开相应redo log file。在env->open时,调用`toku_logger_open_with_last_xid`的最后一个参数last_xid为TXNID_NONE,表示由`toku_logger_open_with_last_xid`指定事务子系统初始化时最新的txnid。
解析redo log file的过程在函数`toku_logfilemgr_init`实现,依次解析redo log目录下的每一个文件名符合特定格式的redo log file,从中读取最后一个log entry的lsn保存下来。Redo log文件名遵循”log$index.tokulog$version”格式,$index是64位无符号整数表示的redo log file的序列号index,$version是32位无符号整数表示版本信息。
如果最新的redo log file最后一个log entry是LT_shutdown(表示正常关闭不需要进行recovery),那么把对应的txnid记录在last_xid_if_clean_shutdown变量,作为TokuDB事务子系统初始化时最新的txnid。在解析redo log file的时候,还会用最新的redo log file的最后一个log entry的lsn更新logger的lsn,written_lsn,fsynced_lsn。接着,`toku_logger_find_next_unused_log_file`找到下一个可用的redo log文件的序列号,并创建新的redo log file。每个redo log file最开始的12个字节是固定的,首先是8个字节的magic字符串“tokulogg“,紧接着4个字节是log的版本信息。代码片段如下:
~~~
int
toku_logger_open_with_last_xid(const char *directory /* redo log dir */, TOKULOGGER logger, TXNID last_xid) {
if (logger->is_open) return EINVAL;
TXNID last_xid_if_clean_shutdown = TXNID_NONE;
r = toku_logfilemgr_init(logger->logfilemgr, directory, &last_xid_if_clean_shutdown);
if ( r!=0 )
return r;
logger->lsn = toku_logfilemgr_get_last_lsn(logger->logfilemgr);
logger->written_lsn = logger->lsn;
logger->fsynced_lsn = logger->lsn;
logger->inbuf.max_lsn_in_buf = logger->lsn;
logger->outbuf.max_lsn_in_buf = logger->lsn;
r = open_logdir(logger, directory);
if (r!=0) return r;
long long nexti;
r = toku_logger_find_next_unused_log_file(logger->directory, &nexti);
if (r!=0) return r;
logger->next_log_file_number = nexti;
r = open_logfile(logger);
if (r!=0) return r;
if (last_xid == TXNID_NONE) {
last_xid = last_xid_if_clean_shutdown;
}
toku_txn_manager_set_last_xid_from_logger(logger->txn_manager, last_xid);
logger->is_open = true;
return 0;
}
~~~
到这里,TokuDB的logger子系统就初始化好了,在处理DDL或者DML或者TokuDB执行checkpoint的时候,都需要先写rollback(undo)log,redo log。Rollback在之前的月报[MySQL · TokuDB · 事务子系统和 MVCC 实现](http://mysql.taobao.org/monthly/2016/03/01/) 谈到过,这里不再赘述。
### 写redo log
下面我们一起看一下往redo log新加一条insert的过程。函数`toku_log_enq_insert`的第2,第5,第6,第7,第8参数表示描述一条insert的五元组(lsn, FT, xid, key, value)。代码片段如下:
~~~
void toku_log_enq_insert (TOKULOGGER logger, LSN *lsnp, int do_fsync, TOKUTXN txn, FILENUM filenum, TXNID_PAIR xid, BYTESTRING key, BYTESTRING value) {
if (logger == NULL) {
return;
}
if (txn && !txn->begin_was_logged) {
invariant(!txn_declared_read_only(txn));
// 记录txn begin
toku_maybe_log_begin_txn_for_write_operation(txn);
}
if (!logger->write_log_files) {
// logger->write_log_files为FALSE,表示不写redo,递增lsn就可以返回了。
ml_lock(&logger->input_lock);
logger->lsn.lsn++;
if (lsnp) *lsnp=logger->lsn;
ml_unlock(&logger->input_lock);
return;
}
const unsigned int buflen= (+4 // log entry的长度,参与crc计算
+1 // log命令,对应insert来说是‘I’
+8 // lsn
+toku_logsizeof_FILENUM(filenum) // filenum,表示哪个FT文件
+toku_logsizeof_TXNID_PAIR(xid) // xid,表示txnid
+toku_logsizeof_BYTESTRING(key) // key
+toku_logsizeof_BYTESTRING(value) // data
+8 // crc + len // crc和log entry长度(不参与crc计算)
);
struct wbuf wbuf;
ml_lock(&logger->input_lock);
toku_logger_make_space_in_inbuf(logger, buflen);
wbuf_nocrc_init(&wbuf, logger->inbuf.buf+logger->inbuf.n_in_buf, buflen);
wbuf_nocrc_int(&wbuf, buflen);
wbuf_nocrc_char(&wbuf, 'I');
logger->lsn.lsn++;
logger->inbuf.max_lsn_in_buf = logger->lsn;
wbuf_nocrc_LSN(&wbuf, logger->lsn);
if (lsnp) *lsnp=logger->lsn;
wbuf_nocrc_FILENUM(&wbuf, filenum);
wbuf_nocrc_TXNID_PAIR(&wbuf, xid);
wbuf_nocrc_BYTESTRING(&wbuf, key);
wbuf_nocrc_BYTESTRING(&wbuf, value);
wbuf_nocrc_int(&wbuf, toku_x1764_memory(wbuf.buf, wbuf.ndone));
wbuf_nocrc_int(&wbuf, buflen);
assert(wbuf.ndone==buflen);
logger->inbuf.n_in_buf += buflen;
toku_logger_maybe_fsync(logger, logger->lsn, do_fsync, true);
}
~~~
TokuDB的logger有两个buffer:inbuf和outbuf。Inbuf表示接收log entry的buffer,而outbuf表示写到redo log文件的buffer。这两个buffer是如何切换的呢?当inbuf满或者inbuf里的free space无法满足新来的log entry的存储需求时,需要触发redo buffer flush过程,即将inbuf日志flush到redo log文件里。这个过程比较耗时,而且很可能inbuf里面还有free space,只是由于当前这个log entry比较大而无法满足存储需求,TokuDB实现了output permission机制,使得需要free space的请求等待在output permission的条件变量上,其他client thread上下文的redo log请求可以继续使用inbuf写日志。等待上一个flush完成后(即条件变量被signaled),检查当前inbuf的free space,如果可以满足这条redo log entry就直接返回,说明别的线程帮我们flush好了。如果free space不够,需要在当前线程的上下文去做flush,实际上是把inbuf和outbuf互换,然后把outbuf写到redo log文件中。写完之后适当调整inbuf的大小使之满足当前redo log entry请求。最后唤醒等待inbuf提供足够空间的线程(阻塞在output permission上的线程)。简而言之,把redo log buffer拆分成inbuf和outbuf,最重要的作用是在redo log flush的时候不会阻塞新的log entry写入,感兴趣的朋友可以看一下函数`toku_logger_maybe_fsync`的实现,这里就不一一展开了。函数`toku_logger_make_space_in_inbuf`的代码片段如下:
~~~
void
toku_logger_make_space_in_inbuf (TOKULOGGER logger, int n_bytes_needed)
{
if (logger->inbuf.n_in_buf + n_bytes_needed <= LOGGER_MIN_BUF_SIZE) {
return;
}
ml_unlock(&logger->input_lock);
LSN fsynced_lsn;
// 等待前面的redo log flush完成
grab_output(logger, &fsynced_lsn);
ml_lock(&logger->input_lock);
if (logger->inbuf.n_in_buf + n_bytes_needed <= LOGGER_MIN_BUF_SIZE) {
// 其他线程帮助flush redo log,直接返回。
release_output(logger, fsynced_lsn);
return;
}
if (logger->inbuf.n_in_buf > 0) {
// 交换inbuf,outbuf
swap_inbuf_outbuf(logger);
// 把outbuf里的日志写回
write_outbuf_to_logfile(logger, &fsynced_lsn);
}
// 适当调整inbuf大小
if (n_bytes_needed > logger->inbuf.buf_size) {
assert(n_bytes_needed < (1<<30)); // redo log entry必须小于1G
int new_size = max_int(logger->inbuf.buf_size * 2, n_bytes_needed);
assert(new_size < (1<<30)); // inbuf必须小于1G
XREALLOC_N(new_size, logger->inbuf.buf);
logger->inbuf.buf_size = new_size;
}
// 唤醒等待flush redo log的线程
release_output(logger, fsynced_lsn);
}
~~~
## TokuDB崩溃恢复过程
### 判断是否进行recovery
前面提到MySQL重启过程中会调用`db_env_create`创建env实例,进行参数设置和callback设置,然后调用env->open来做进一步初始化。同样env->open也是一个回调函数,它是在`db_env_create`设置的,指向env_open函数。
在env_open里调用validate_env判断是否需要进行recovery。validate_env函数返回时表明这个env是否是emptyenv (env目录为空,且不存在rollback文件,不存在数据文件),是否是newnev (env目录不存在),是否是emptyrollback (env目录存在,rollback文件为空)。
如果满足条件 !emptyenv && !new_env && is_set(DB_RECOVERY) 就尝试进行recovery。简单地说recovery的条件就是env存在,log_dir存在,redo log存在。
判断是否真正做recovery的函数是`tokuft_needs_recovery`。代码如下:
~~~
int tokuft_needs_recovery(const char *log_dir, bool ignore_log_empty) {
int needs_recovery;
int r;
TOKULOGCURSOR logcursor = NULL;
r = toku_logcursor_create(&logcursor, log_dir);
if (r != 0) {
needs_recovery = true; goto exit;
}
struct log_entry *le;
le = NULL;
r = toku_logcursor_last(logcursor, &le);
if (r == 0) {
needs_recovery = le->cmd != LT_shutdown;
}
else {
needs_recovery = !(r == DB_NOTFOUND && ignore_log_empty);
}
exit:
if (logcursor) {
r = toku_logcursor_destroy(&logcursor);
assert(r == 0);
}
return needs_recovery;
}
~~~
`tokuft_needs_recovery`尝试读取最后一条redo log entry,如果不是LT_shutdown,就需要真正做recovery。读取最后一条redo log entry的代码片段如下:
~~~
int toku_logcursor_last(TOKULOGCURSOR lc, struct log_entry **le) {
// 打开最后一个redo log文件
if ( !lc->is_open ) {
r = lc_open_logfile(lc, lc->n_logfiles-1);
if (r!=0)
return r;
lc->cur_logfiles_index = lc->n_logfiles-1;
}
while (1) {
// 移到最后一个redo log的文件末尾
r = fseek(lc->cur_fp, 0, SEEK_END); assert(r==0);
// 从当前位置(redo log末尾)向前读一个log entry
r = toku_log_fread_backward(lc->cur_fp, &(lc->entry));
if (r==0) // 读成功
break;
if (r>0) {
// 读失败
toku_log_free_log_entry_resources(&(lc->entry));
// 从当前redo log头部开始向后scan直到找到第一非法log Entry的位置,并把redo log文件truncate到那个位置。
r = lc_fix_bad_logfile(lc);
if ( r != 0 ) {
fprintf(stderr, "%.24s TokuFT recovery repair unsuccessful\n", ctime(&tnow));
return DB_BADFORMAT;
}
// 重新读redo log entry
r = toku_log_fread_backward(lc->cur_fp, &(lc->entry));
if (r==0) // 读到好的redo log entry
break;
}
// 当前redo log没有访问的log entry,切换到上一个redo log文件
r = lc_close_cur_logfile(lc);
if (r!=0)
return r;
if ( lc->cur_logfiles_index == 0 )
return DB_NOTFOUND;
lc->cur_logfiles_index--;
r = lc_open_logfile(lc, lc->cur_logfiles_index);
if (r!=0)
return r;
}
}
~~~
在读最后一个log entry的过程中,在读log entry出错的情况下(crash的时候把redo log写坏了)会调用`lc_fix_bad_logfile`尝试修复redo log文件。修复的过程很简单:从当前redo log头部开始向后scan直到找到第一非法log entry的位置,并把redo log文件truncate到那个位置。此时,文件指针也指向文件末尾。极端的情况是,修复完redo log,发现当前redo log中的所有entry都是坏的,那样需要切换到前面一个redo log文件。
### Recovery过程
如果需要做recovery,TokuDB会调用do_recovery进行恢复,恢复的时候先做redo log apply,然后进行undo rollback。代码片段如下:
~~~
static int do_recovery(RECOVER_ENV renv, const char *env_dir, const char *log_dir) {
r = toku_logcursor_create(&logcursor, log_dir);
assert(r == 0);
scan_state_init(&renv->ss);
for (unsigned i=0; 1; i++) {
// 读取前一个log entry,第一次读的是最后一个log entry
le = NULL;
r = toku_logcursor_prev(logcursor, &le);
if (r != 0) {
if (r == DB_NOTFOUND)
break;
rr = DB_RUNRECOVERY;
goto errorexit;
}
// backward阶段处理log entry
assert(renv->ss.ss == BACKWARD_BETWEEN_CHECKPOINT_BEGIN_END ||
renv->ss.ss == BACKWARD_NEWER_CHECKPOINT_END);
logtype_dispatch_assign(le, toku_recover_backward_, r, renv);
if (r != 0) {
rr = DB_RUNRECOVERY;
goto errorexit;
}
if (renv->goforward)
break;
}
for (unsigned i=0; 1; i++) {
// forward阶段处理log entry,首先处理的是checkpoint begin的那个log entry
assert(renv->ss.ss == FORWARD_BETWEEN_CHECKPOINT_BEGIN_END ||
renv->ss.ss == FORWARD_NEWER_CHECKPOINT_END);
logtype_dispatch_assign(le, toku_recover_, r, renv);
if (r != 0) {
rr = DB_RUNRECOVERY;
goto errorexit;
}
// 读取下一个log entry
le = NULL;
r = toku_logcursor_next(logcursor, &le);
if (r != 0) {
if (r == DB_NOTFOUND)
break;
rr = DB_RUNRECOVERY;
goto errorexit;
}
}
// parse redo log结束
assert(renv->ss.ss == FORWARD_NEWER_CHECKPOINT_END);
r = toku_logcursor_destroy(&logcursor);
assert(r == 0);
// 重启logger
toku_logger_restart(renv->logger, lastlsn);
// abort所有未提交的事务
recover_abort_all_live_txns(renv);
// 在recovery退出前做一个checkpoint
r = toku_checkpoint(renv->cp, renv->logger, NULL, NULL, NULL, NULL, RECOVERY_CHECKPOINT);
assert(r == 0);
return 0;
}
~~~
Scan log entry分别两个阶段:backward阶段和forward阶段。这两个阶段是由scan_state状态机控制的。在scan开始之前在`scan_state_init`函数中把状态机ss的初始状态设置为BACKWARD_NEWER_CHECKPOINT_END。
![](https://box.kancloud.cn/2016-06-02_574fe05b51a95.jpg)
* Backward阶段:从最后一个log entry开始向前读,直到读到checkpoint end。对在这个过程中读到的每一个log entry调用`logtype_dispatch_assign(le, toku_recover_backward_, r, renv)`。在这个阶段对于checkpoint以外的操作,toku_recover_backward_前缀的处理函数都是noop。当读到checkpoint end的log entry时,会把ss状态设置为BACKWARD_BETWEEN_CHECKPOINT_BEGIN_END,并记录这个checkpoint的begin_lsn和lsn。然后继续向前scan直到读到checkpoint begin的log entry,确保ss中记录的checkpoint_begin_lsn和log entry的lsn是相等的,然后 把ss的状态设置为FORWARD_BETWEEN_CHECKPOINT_BEGIN_END,并设置renv->goforward为TRUE。
* Forward阶段:对当前的log entry调用`logtype_dispatch_assign(le, toku_recover_, r, renv)`重放redo log。然后向后scan直到读到checkpoint end,确保ss中记录的`checkpoint_begin_lsn`和`checkpoint_end_lsn`与log entry里面记录的`lsn_begin_checkpoint`和lsn是相等的,然后把ss的状态设置为FORWARD_NEWER_CHECKPOINT_END。这样,崩溃之前的最后一个checkpoint就回放完成了。下面要做的事情就是,回放committed txn的redo log。代码片段如下:
~~~
static void scan_state_init(struct scan_state *ss) {
ss->ss = BACKWARD_NEWER_CHECKPOINT_END;
ss->checkpoint_begin_lsn = ZERO_LSN;
ss->checkpoint_end_lsn = ZERO_LSN;
ss->checkpoint_num_fassociate = 0;
ss->checkpoint_num_xstillopen = 0;
ss->last_xid = 0;
}
static int toku_recover_backward_end_checkpoint (struct logtype_end_checkpoint *l, RECOVER_ENV renv) {
switch (renv->ss.ss) {
case BACKWARD_NEWER_CHECKPOINT_END:
renv->ss.ss = BACKWARD_BETWEEN_CHECKPOINT_BEGIN_END;
renv->ss.checkpoint_begin_lsn.lsn = l->lsn_begin_checkpoint.lsn;
renv->ss.checkpoint_end_lsn.lsn = l->lsn.lsn;
renv->ss.checkpoint_end_timestamp = l->timestamp;
return 0;
case BACKWARD_BETWEEN_CHECKPOINT_BEGIN_END:
abort();
default:
break;
}
abort();
}
static int toku_recover_backward_begin_checkpoint (struct logtype_begin_checkpoint *l, RECOVER_ENV renv) {
int r;
switch (renv->ss.ss) {
case BACKWARD_NEWER_CHECKPOINT_END:
// incomplete checkpoint, nothing to do
r = 0;
break;
case BACKWARD_BETWEEN_CHECKPOINT_BEGIN_END:
assert(l->lsn.lsn == renv->ss.checkpoint_begin_lsn.lsn);
renv->ss.ss = FORWARD_BETWEEN_CHECKPOINT_BEGIN_END;
renv->ss.checkpoint_begin_timestamp = l->timestamp;
renv->goforward = true;
r = 0;
break;
default:
abort();
break;
}
return r;
}
static int toku_recover_begin_checkpoint (struct logtype_begin_checkpoint *l, RECOVER_ENV renv) {
int r;
TXN_MANAGER mgr = toku_logger_get_txn_manager(renv->logger);
switch (renv->ss.ss) {
case FORWARD_BETWEEN_CHECKPOINT_BEGIN_END:
assert(l->lsn.lsn == renv->ss.checkpoint_begin_lsn.lsn);
invariant(renv->ss.last_xid == TXNID_NONE);
renv->ss.last_xid = l->last_xid;
toku_txn_manager_set_last_xid_from_recovered_checkpoint(mgr, l->last_xid);
r = 0;
break;
case FORWARD_NEWER_CHECKPOINT_END:
assert(l->lsn.lsn > renv->ss.checkpoint_end_lsn.lsn);
// Verify last_xid is no older than the previous begin
invariant(l->last_xid >= renv->ss.last_xid);
// Verify last_xid is no older than the newest txn
invariant(l->last_xid >= toku_txn_manager_get_last_xid(mgr));
r = 0; // ignore it (log only has a begin checkpoint)
break;
default:
abort();
break;
}
return r;
}
static int toku_recover_end_checkpoint (struct logtype_end_checkpoint *l, RECOVER_ENV renv) {
int r;
switch (renv->ss.ss) {
case FORWARD_BETWEEN_CHECKPOINT_BEGIN_END:
assert(l->lsn_begin_checkpoint.lsn == renv->ss.checkpoint_begin_lsn.lsn);
assert(l->lsn.lsn == renv->ss.checkpoint_end_lsn.lsn);
assert(l->num_fassociate_entries == renv->ss.checkpoint_num_fassociate);
assert(l->num_xstillopen_entries == renv->ss.checkpoint_num_xstillopen);
renv->ss.ss = FORWARD_NEWER_CHECKPOINT_END;
r = 0;
break;
case FORWARD_NEWER_CHECKPOINT_END:
assert(0);
return 0;
default:
assert(0);
return 0;
}
return r;
}
~~~
上面我们是TokuDB recovery的过程。对读redo log一笔带过。现在一起看看读log entry的过程:
* 向后读:从当前位置读4个字节的长度len1,然后读1个字节cmd。然后按照不同cmd的定义来读log entry。
* 向前读:从当前位置读nocrc的长度len2,把文件指针向前移动len2个字节。从那个位置向后读。
* Verify:读的过程需要计算crc校验码。Len1是参与crc计算的,而len2不参与crc计算。计算得到的crc应该与log entry里面记录的crc相等。而且len1应该等于len2。
- 数据库内核月报目录
- 数据库内核月报 - 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团队