TOKUDB参数优化之一

摘抄自：MYSQL内核月报 http://blog.csdn.net/longxibendi/article/details/39297025

TokuDB· 参数故事·数据安全和性能

TokuDB里可调优的参数不多，今天把＂最重要＂的几个拉出来晒晒。

与性能相关的参数及说明:

 tokudb_cache_size(bytes):
 缓存大小，读写时候，数据会首先会缓存到这里。
 默认大小为机器物理内存的一半。

 tokudb_commit_sync(ON/OFF):
 当事务提交的时候，是否要fsync log到磁盘。
 默认开启(ON)，如果设置为OFF，性能会提升，但可能会丢失事务(commit记录到log buffer，但是未fsync到磁盘的事务)。

 tokudb_directio(ON/OFF):
 是否开启Direct I/O功能，TokuDB在写盘的时候，无论是否开启Direct I/O，都是按照512字节对齐的。
 默认为OFF。

 tokudb_fsync_log_period(ms):
 多久fsync一下log buffer到磁盘，TokuDB的log buffer总大小为32MB且不可更改。
 默认为0ms(此时做fsync的后台线程一直处于wait状态)，此时受tokudb_commit_sync开关控制是否要fsync log到磁盘(checkpoint也会fsync log buffer的，默认为1分钟)。

针对不同的使用场景：

1) 对数据要求较高(不允许丢失数据，事务ACID完整性)，只需根据内存调整tokudb_cache_size大小即可，建议开启tokudb_directio。

2) 对数据要求不太高(允许部分数据丢失，不要求事务ACID完整性)，可配置:

 tokudb_commit_sync=OFF
 tokudb_fsync_log_period=1000 #1s

在此配置下，每1秒对log buffer做下fsync，可充分利用log的group commit功能，如果TokuDB挂掉，则可能会丢失最多1秒的数据。

TokuDB· HA方案·TokuDB热备

TokuDB企业版提供热备功能(与社区版唯一的区别)。

该功能以plugin方式提供，当backup plugin加载后，它会拦截所有的文件操作(比如文件读写／目录操作等)，从而实现在备份的过程中增量同步，具体原理请看:

 
 

社区版如何实现热备呢？

官方推荐的方式是mylvmbackup，不过可能会有一些＂坑＂。

Percona的Vadim同学写过一篇TokuDB tips，介绍了Percona在使用mylvmbackup热备TokuDB中遇到的＂坑＂及解决方法：

不能只备份TokuDB自身的数据以及日志文件，还要备份最新的binlog，否则启动的时候可能就＂跪＂了！

还有一个比较geek的方式，直接基于TokuDB自身的机制，轻松的热备出一个备库。

上攻略：

 1) SET TOKUDB_CHECKPOINT_LOCK=ON;
 2) 开始拷贝TokuDB的数据文件(不包含日志文件)
 3) FLUSH TABLES WITH READ LOCK;
 4) 记录binlog位置，拷贝最新的binlog和TokuDB的日志文件(*.tokulog)
 5) UNLOCK TABLES;
 6) SET TOKUDB_CHECKPOINT_LOCK=OFF;

＂大杀器＂就是，它的作用是允许拿到checkpoint锁，此时TokuDB的checkpoint会一直block到该锁释放(执行前要把tokudb_checkpoint_on_flush_logs关掉)，目的是防止拷贝TokuDB数据文件的过程中做sharp checkpoint(注意：由于不做checkpoint，TokuDB的日志文件会逐渐增多)，从而导致数据文件内部不一致(已拷贝的文件被修改)。

整个热备过程中，只有步骤4是阻塞写的，但耗时较短。