TokuDB的数据库文件组织方式比较随意，给我们一种“乱”的假象，今天就来漫谈下TokuDB数据库文件。

一个“新生”的TokuDB数据库，基础文件是这样的：

1
2
3
4
5

tokudb.directory --表/索引文件信息
tokudb.environment --TokuDB版本号信息
tokudb.rollback --undo记录
log000000000001.tokulog27 --redo记录
__tokudb_lock_dont_delete_me_* --文件锁，保证同一个datadir只能被一个TokuDB进程使用

背景

修改PG源码时，在elog.c文件中准备调用timestamp.c中的TimestampTz GetCurrentTimestamp(void)，以获取当前时间，TimestampTz是个int64类型，但是返回值类型不是期望的（是个int32值），但是在另外一个文件postgres.c调用返回的是正常的，如下：

1
2

elog.c: GetCurrentTimestamp() = 3891376011
postgres.c: GetCurrentTimestamp() = 495621643471576

也就是说，同一个函数在不同文件返回值的长度完全不同！

在PG的众多参数中，参数checkpoint相关的几个参数颇为神秘。这些参数与checkpoint的调度有关，对系统的稳定性还是比较重要的，下面我们为大家解析一下，这要先从PG的数据同步机制谈起。

本文分为三节，分别介绍clog的fsync频率，原子操作，与异步提交一致性。

PostgreSQL pg_clog fsync 频率分析

分析一下pg_clog是在什么时候需要调用fsync的？

业务背景

MySQL 主备通过 binlog 实现数据同步的功能，主库将生成的 binlog 通过 binlog send 线程发送到备库，备库通过应用这些 binlog 来更新数据，实现主备数据一致，其应用 binlog 的读取操作与更新操作的堆栈分别如下。

问题描述

主库的create table语句传到备库，备库SQL线程执行过程中报错：

1

Error 'Can't create table 'XXX.XX' (errno: -1)' on query. Default database: 'XXX'. Query: 'CREATE TABLE XX (  column_a char(32) NOT NULL,  column_b int(10) DEFAULT NULL,  column_c int(10) DEFAULT NULL,  PRIMARY KEY (column_a),  KEY expiry (column_b)) ENGINE=HEAP DEFAULT CHARSET=gbk'

随着RDS MySQL用户越来越多，隐藏很久很深的bug也逐渐被挖出来了，下面分享一下最近遇到的三例bug，都是官方版本存在的。

并行复制相关线程

在MySQL 5.6并行复制中，当设置set global slave_parallel_workers=2时，共有4个复制相关的线程，如下：

1
2
3
4
5
6
7
8

+----+-------------+------+-------+---------+------+------------------------------------------------------------------+------+
| ID | USER        | HOST | DB    | COMMAND | TIME | STATE                                                            | INFO |
+----+-------------+------+-------+---------+------+------------------------------------------------------------------+------+
| 23 | system user |      | NULL  | Connect |    3 | Waiting for master to send event                                 | NULL |
| 24 | system user |      | mysql | Connect |    3 | Slave has read all relay log; waiting for the slave I/O thread t | NULL |
| 25 | system user |      | NULL  | Connect |    3 | Waiting for an event from Coordinator                            | NULL |
| 26 | system user |      | NULL  | Connect |    3 | Waiting for an event from Coordinator                            | NULL |
+----+-------------+------+-------+---------+------+------------------------------------------------------------------+------+

其中第一个为IO线程，负责从主库拉取binlog到备库并存为relay log; 第二个为分发线程，负责解析relay log，并将解析后的事件分发给worker线程处理； 其余两个为worker线程负责处理分发后的事件，类型非并行复制时的sql线程。

在上一期的月报中，我们分析了 MySQL 5.6 并行复制是如何实现的，介绍了主要数据结构、Coordinator 线程的分发、Worker 线程的执行和checkpoint过程，读者朋友可以回顾下，本篇将对恢复逻辑进行介绍。

在并行复制之前，SQL线程的恢复很简单，从 relay-log.info 中取得上次执行到的位点，然后从这个位点开始执行即可。有了并行复制之后，情况就变得稍微复杂了些，worker 线程各自执行自己队列的事务，在stop slave或者 mysqld crash的时候，队列中的事务很可能没有执行完，比如crash时GAQ的状态如下图1所示，中间存在空隙(gap)，先分发给 worker a 的事务还未完成，而后分发给 worker b 的事务已经完成，对应就是 relay log 中间有一部分event没执行。我们知道，SQL执行或者分发是顺序读relay log的，如果恢复时从 2 开始执行，3 和 4就会重复执行，如果从4开始执行，2就会被跳过，都不行。并行复制恢复的逻辑就是把 2 找出来执行，把空隙给填上，然后SQL线程就可以 5 开始愉快地跑下去了。

前言

我们知道InnoDB的索引组织结构为Btree。通常情况下，我们需要根据查询条件，从根节点开始寻路到叶子节点，找到满足条件的记录。为了减少寻路开销，InnoDB本身做了几点优化。