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="\000\001\000\000\000"} cI: xid=0000000000000000 val={len=5 data="\375\001\000\000\000"}} {key={len=5 data="\000\002\000\000\000"} cI: xid=0000000000000000 val={len=5 data="\375\002\000\000\000"}} {key={len=5 data="\000\003\000\000\000"} cI: xid=0000000000000000 val={len=5 data="\375\003\000\000\000"} pI: xid=000000009a93a265 val={len=5 data="\375\004\000\000\000"}} ~~~ 可以看到，在數據文件里每一行數據都是一個對，再維護一個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-main\000"} value={len=31 data="./_test_t1_main_90_2_1b.tokudb\000"} 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="\011\000\000\000\001\000\000\004\000\005\000\000\000\001\004\000\000\000"} 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="\000\001\000\000\000"} value={len=5 data="\375\001\000\000\000"} 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="\000\002\000\000\000"} value={len=5 data="\375\002\000\000\000"} 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="\000\003\000\000\000"} value={len=5 data="\375\003\000\000\000"} 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="\000\003\000\000\000"} src_val={len=5 data="\375\004\000\000\000"} 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