MySQL · TokuDB · TokuDB之黑科技工具-阿里云RDS 数据库内核月报

MySQL · TokuDB · TokuDB之黑科技工具

TokuDB之黑科技工具

刚过完年，美女程序员静静想学习下 TokuDB 相关技术，从何处入手呢？TokuDB的技术资料可是出了名的少！
本篇就给大家介绍下两个“黑科技”工具，来帮助我们更深入的了解TokuDB。

黑科技之tokuftdump

此工具用来dump一个Fractal-Tree结构的数据文件。

这样我们就可以很直观的知道我写入的数据在磁盘上是个什么样子(disk layout)。

废话少说，一切尽在“栗子”中。

创建表t1:

CREATE TABLE `t1` (
  `a` int(11) NOT NULL,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`a`)
) ENGINE=TokuDB

写入数据并刷到磁盘:

mysql> INSERT INTO t1 VALUES(1,1);
mysql> INSERT INTO t1 VALUES(2,2);
mysql> INSERT INTO t1 VALUES(3,3);
mysql> UPDATE t1 SET b=4 WHERE a=3;
mysql> FLUSH TABLES t1;

使用tokuftdump进行数据dump:

./bin/tokuftdump data/_test_t1_main_90_2_1b.tokudb
...
{key={len=5 data="0001000000"} cI: xid=0000000000000000 val={len=5 data="37501000000"}}
{key={len=5 data="0002000000"} cI: xid=0000000000000000 val={len=5 data="37502000000"}}
{key={len=5 data="0003000000"} cI: xid=0000000000000000 val={len=5 data="37503000000"} pI: xid=000000009a93a265 val={len=5 data="37504000000"}}

可以看到，在数据文件里每一行数据都是一个对，再维护一个MVCC结构就可以满足ACID特性了。

最后一条记录就是执行完UPDATE后MVCC：有2个val存在，xid(transaction id)不同，需要注意的是 tokuftdump 会对数据进行重组织展现，并非磁盘上的原生结构。

如果你想深入了解TokuDB的Fractal-Tree结构，这是个必不可少的工具，它不仅可以 dump 数据，还可以 dump Fractal-Tree 的全部信息，让底层存储结构“跃然屏上”。

黑科技之 tdb_logprint

此工具用来dump TokuDB的redo-log，让我们了解TokuDB redo-log是如何组织的。

接下来我们看下执行完刚才的SQL后，窥探下redo-log里又是些什么鬼:

./tdb_logprint < data/log000000000002.tokulog27

xbegin                   "b": lsn=64 xid=144,2 parentxid=144,0 crc=97572838 len=53
enq_insert               "I": lsn=65 filenum=3 xid=144,2 key={len=15 data="./test/t1-main00"} value={len=31 data="./_test_t1_main_90_2_1b.tokudb00"} crc=d259724f len=95
fcreate                  "F": lsn=66 xid=144,2 filenum=7 iname={len=30 data="./_test_t1_main_90_2_1b.tokudb"} mode=0666 treeflags=0 nodesize=4194304 basementnodesize=65536 compression_method=11 crc=3755db8b len=95
xcommit                  "C": lsn=67 xid=144,2 crc=ffad0139 len=37
change_fdescriptor       "D": lsn=68 filenum=7 xid=144,0 old_descriptor={len=0 data=""} new_descriptor={len=18 data="110000000100000400050000000104000000"} update_cmp_descriptor=true crc=acef9cdb len=68
xcommit                  "C": lsn=69 xid=144,0 crc=ffa0c139 len=37
fclose                   "e": lsn=70 iname={len=32 data="./_test_t1_status_90_1_1b.tokudb"} filenum=5 crc=73c0dbf1 len=61
fclose                   "e": lsn=71 iname={len=30 data="./_test_t1_main_90_2_1b.tokudb"} filenum=7 crc=060f6b9f len=59
fopen                    "O": lsn=72 iname={len=32 data="./_test_t1_status_90_1_1b.tokudb"} filenum=9 treeflags=0 crc=c8de90f1 len=65
fopen                    "O": lsn=73 iname={len=30 data="./_test_t1_main_90_2_1b.tokudb"} filenum=11 treeflags=0 crc=b38239c5 len=63
xbegin                   "b": lsn=74 xid=146,0 parentxid=0,0 crc=9a083238 len=53
enq_insert               "I": lsn=75 filenum=11 xid=146,0 key={len=5 data="0001000000"} value={len=5 data="37501000000"} crc=658a7b0b len=59
xcommit                  "C": lsn=76 xid=146,0 crc=ff98be39 len=37
xbegin                   "b": lsn=77 xid=148,0 parentxid=0,0 crc=8602ef38 len=53
enq_insert               "I": lsn=78 filenum=11 xid=148,0 key={len=5 data="0002000000"} value={len=5 data="37502000000"} crc=59dad00b len=59
xcommit                  "C": lsn=79 xid=148,0 crc=ff9f3339 len=37
xbegin                   "b": lsn=80 xid=150,0 parentxid=0,0 crc=821b8438 len=53
enq_insert               "I": lsn=81 filenum=11 xid=150,0 key={len=5 data="0003000000"} value={len=5 data="37503000000"} crc=926d5d14 len=59
xcommit                  "C": lsn=82 xid=150,0 crc=ff93b439 len=37
xbegin                   "b": lsn=83 xid=152,0 parentxid=0,0 crc=8e1ca138 len=53
enq_insert_multiple      "m": lsn=84 src_filenum=11 dest_filenums={num=1 filenums="0xb"} xid=152,0 src_key={len=5 data="0003000000"} src_val={len=5 data="37504000000"} crc=ecb1c6f0 len=67
xcommit                  "C": lsn=85 xid=152,0 crc=ff962939 len=37
fclose                   "e": lsn=86 iname={len=30 data="./_test_t1_main_90_2_1b.tokudb"} filenum=11 crc=8709a890 len=59
fclose                   "e": lsn=87 iname={len=32 data="./_test_t1_status_90_1_1b.tokudb"} filenum=9 crc=c43070f7 len=61
begin_checkpoint         "x": lsn=88 timestamp=1455623796540257 last_xid=153 crc=470dd9ea len=37
fassociate               "f": lsn=89 filenum=0 treeflags=0 iname={len=15 data="tokudb.rollback"} unlink_on_close=0 crc=8606e9b1 len=49
fassociate               "f": lsn=90 filenum=1 treeflags=4 iname={len=18 data="tokudb.environment"} unlink_on_close=0 crc=92dc4c1c len=52
fassociate               "f": lsn=91 filenum=3 treeflags=4 iname={len=16 data="tokudb.directory"} unlink_on_close=0 crc=86323b7e len=50
end_checkpoint           "X": lsn=92 lsn_begin_checkpoint=88 timestamp=1455623796541659 num_fassociate_entries=3 num_xstillopen_entries=0 crc=5cde4ff2 len=45

wow，redo-log其实就是FT(TokuDB底层存储引擎缩写，ft-index)所有操作指令的回放。

当我们执行CREATE TABLE的时候，FT执行指令是：

1) 开启事务
2) 把创建的表信息记录到元数据库 tokudb.directory
3) 创建表文件
4) 提交事务

创建表的过程是不是很清晰了？

接着看写数据，FT执行的指令：

1) 打开表文件
2) 事务开始
3) 写入记录
4) 事务提交
...
5) 关闭表文件
...

在redo-log的最后我们还看到checkpoint信息，包括checkpoint时的lsn以及时间等。

通过 tdb_logprint，我们可以很轻松的知道TokuDB底层到底在干什么，如果你想了解TokuDB底层行为，请开启你的 tdb_logprint 之旅吧。

如果你对TokuDB某个细节不清楚，请执行下你的SQL，结合这两个工具，再加上源码，基本可以做到胸中有数了。

静静你可以静静的学习TokuDB了 :D