Percona TokuDB
1. TokuDB说明
具体看：
https://www.percona.com/doc/percona-server/5.7/tokudb/tokudb_intro.html
2. TokuDB安装
Percona Server兼容独立可用的TokuDB存储引擎包。TokuDB引擎必须分开下载然后以插件的形式启用。这个包可以独立安装，不需要任何特定的版本的Percona Server。
TokuDB存储引擎是可扩展，ACID，MVCC的存储引擎，提供基于索引查询，提供online的框架修改和减少slave延迟。这个存储引擎设计师为了写入性能，是基于fractal tree的。
警告：
目前percona提供的TokuDB被使用在Percona Server 5.7。TokuDB引擎从其他地方下载的不能被兼容。TokuDB文件格式和MySQL变种不是一样的。从一个变种到另外一个可能需要做数据导入导出。
前置需要
Libjemalloc库
ToKuDB需要libjemalloc 3.3.0或者更高版本。可以从percona或者其他地方下载。如果libjemalloc，之前没有安装，TokuDB存储引擎在使用apt,yum安装的时候自动安装，但是并不会被加载到mysql，可以使用如下配置导入。
[mysqld_safe]
malloc-lib= /path/to/jemalloc
大页面转化
TokuDB如果在大页面转化启动的时候不会被启动。大页面转化是新内核版本的功能。可以通过以下语句检查时候启动。
$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
如果启动了大页面转化，启动TokuDB引擎会受到错误日志里面有如下信息：
Transparent huge pages are enabled, according to /sys/kernel/mm/redhat_transparent_hugepage/enabled
Transparent huge pages are enabled, according to /sys/kernel/mm/transparent_hugepage/enabled
你也可以关闭大页面转化功能，把transparent_hugepage=never传递到内核bottloader工具。但是要重启。也可以使用以下命令关闭：
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
安装
现在TukoDB可以使用Percona的源安装：
如果为yum：
[root@centos ~]# yum install Percona-Server-tokudb-57.x86_64
如果为apt：
root@wheezy:~# apt-get install percona-server-tokudb-5.7
启动TokuDB存储引擎
一旦安装好TokuDB就会有如下输出：
* This release of Percona Server is distributed with TokuDB storage engine.
* Run the following script to enable the TokuDB storage engine in Percona Server:
ps_tokudb_admin --enable -u <mysql_admin_user> -p[mysql_admin_pass] [-S <socket>] [-h <host> -P <port>]
* See http://www.percona.com/doc/percona-server/5.7/tokudb/tokudb_installation.html for more installation details
* See http://www.percona.com/doc/percona-server/5.7/tokudb/tokudb_intro.html for an introduction to TokuDB
Percona Server实现了ps_tokudb_admin脚本启动TokuDB存储引擎。脚本会自动关闭大页面转化。需要sudo 运行一下语句：
ps_tokudb_admin --enable -uroot -pPassw0rd
运行后会输出：
Checking if Percona server is running with jemalloc enabled...
>> Percona server is running with jemalloc enabled.
Checking transparent huge pages status on the system...
>> Transparent huge pages are currently disabled on the system.
Checking if thp-setting=never option is already set in config file...
>> Option thp-setting=never is not set in the config file.
>> (needed only if THP is not disabled permanently on the system)
Checking TokuDB plugin status...
>> TokuDB plugin is not installed.
Adding thp-setting=never option into /etc/mysql/my.cnf
>> Successfuly added thp-setting=never option into /etc/mysql/my.cnf
Installing TokuDB engine...
>> Successfuly installed TokuDB plugin.
如果脚本没有返回错误，那么TokuDB被成功安装，可以使用show engins检查：
mysql> SHOW ENGINES;
...
| TokuDB | YES | Tokutek TokuDB Storage Engine with Fractal Tree(tm) Technology | YES | YES | YES |
...
手动启动TokuDB存储引擎
如果你不想用ps_tokudb_admin脚本，就需要手动安装存储引擎，加载plugins：
INSTALL PLUGIN tokudb SONAME 'ha_tokudb.so';
INSTALL PLUGIN tokudb_file_map SONAME 'ha_tokudb.so';
INSTALL PLUGIN tokudb_fractal_tree_info SONAME 'ha_tokudb.so';
INSTALL PLUGIN tokudb_fractal_tree_block_map SONAME 'ha_tokudb.so';
INSTALL PLUGIN tokudb_trx SONAME 'ha_tokudb.so';
INSTALL PLUGIN tokudb_locks SONAME 'ha_tokudb.so';
INSTALL PLUGIN tokudb_lock_waits SONAME 'ha_tokudb.so';
INSTALL PLUGIN tokudb_background_job_status SONAME 'ha_tokudb.so';
然后获取当前存储引擎列表：
mysql> SHOW ENGINES;
...
| TokuDB | YES | Tokutek TokuDB Storage Engine with Fractal Tree(tm) Technology | YES | YES | YES |
...
然后show plugins检查是否安装正确：
mysql> SHOW PLUGINS;
...
| TokuDB | ACTIVE | STORAGE ENGINE | ha_tokudb.so | GPL |
| TokuDB_file_map | ACTIVE | INFORMATION SCHEMA | ha_tokudb.so | GPL |
| TokuDB_fractal_tree_info | ACTIVE | INFORMATION SCHEMA | ha_tokudb.so | GPL |
| TokuDB_fractal_tree_block_map | ACTIVE | INFORMATION SCHEMA | ha_tokudb.so | GPL |
| TokuDB_trx | ACTIVE | INFORMATION SCHEMA | ha_tokudb.so | GPL |
| TokuDB_locks | ACTIVE | INFORMATION SCHEMA | ha_tokudb.so | GPL |
| TokuDB_lock_waits | ACTIVE | INFORMATION SCHEMA | ha_tokudb.so | GPL |
| TokuDB_background_job_status | ACTIVE | INFORMATION SCHEMA | ha_tokudb.so | GPL |
...
TokuDB版本
查看TokuDB版本：
mysql> SELECT @@tokudb_version;
+------------------+
| @@tokudb_version |
+------------------+
| 5.7.10-1rc1 |
+------------------+
1 row in set (0.00 sec)
3. 使用TokuDB
3.1 快速插入和富索引
TokuDB使用富索引，让更快的索引，可以让查询更快。比如覆盖或者聚集索引。
3.2 聚集secondary索引
TokuDB允许一个secondary索引定义为聚集索引。以为这所有的表上的列都在这个secondary索引上。Percona Server解析并且查询优化的时候支持多聚集键，当TokuDB被使用的时候。也就是说在特定环境下，查询优化器会避免主键聚集索引读取，而是使用secondary 聚集索引读取。
现在解析式支持一下语法：
CREATE TABLE ... ( ..., CLUSTERING KEY identifier (column list), ...
CREATE TABLE ... ( ..., UNIQUE CLUSTERING KEY identifier (column list), ...
CREATE TABLE ... ( ..., CLUSTERING UNIQUE KEY identifier (column list), ...
CREATE TABLE ... ( ..., CONSTRAINT identifier UNIQUE CLUSTERING KEY identifier (column list), ...
CREATE TABLE ... ( ..., CONSTRAINT identifier CLUSTERING UNIQUE KEY identifier (column list), ...
CREATE TABLE ... (... column type CLUSTERING [UNIQUE] [KEY], ...)
CREATE TABLE ... (... column type [UNIQUE] CLUSTERING [KEY], ...)
ALTER TABLE ..., ADD CLUSTERING INDEX identifier (column list), ...
ALTER TABLE ..., ADD UNIQUE CLUSTERING INDEX identifier (column list), ...
ALTER TABLE ..., ADD CLUSTERING UNIQUE INDEX identifier (column list), ...
ALTER TABLE ..., ADD CONSTRAINT identifier UNIQUE CLUSTERING INDEX identifier (column list), ...
ALTER TABLE ..., ADD CONSTRAINT identifier CLUSTERING UNIQUE INDEX identifier (column list), ...
CREATE CLUSTERING INDEX identifier ON ...
定义secondary聚集索引：
CREATE TABLE table (
column_a INT,
column_b INT,
column_c INT,
PRIMARY KEY index_a (column_a),
CLUSTERING KEY index_b (column_b)) ENGINE = TokuDB;
TokuDB可以使用聚集索引是因为它出色的压缩和很高的索引率。
3.3 在线索引创建
TokuDB可以让你在线的添加索引到已经存在的表中。不是使用online 关键字，还是使用tokudb_create_index_online的会话系统变量：
mysql> SET tokudb_create_index_online=on;
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE INDEX index ON table (field_name);
也可以使用，alter table命令离线方式的创建索引，不管有没有开启tokudb_create_index_online都是离线的。只有create index方式可以在线的创建。
Online创建索引比offline 的满，和服务繁忙程度有关。创建索引的精度可以通过命令show processlist查看。一旦索引创建完成，新的索引在下个查询计划中就会被使用。
如果在同一个表上有多余一个的创建索引，索引会线性的被创建。索引创建会等待另外一个完成，在show processlist中会显示被锁定。推荐在创建索引完成之后再来执行下一个。
3.4 在线添加，删除，扩展，重命名列
TokuDB可以让你添加和删除已经存在表的列，扩展char，varchar，varbinary，integer类型，或者重命名已经存在的列。HCADER会短暂的锁定表，修改数据字段。然后当数据从磁盘读入的时候都会被修改。对于列重命名，所有的工作在几秒钟内完成，在磁盘上的数据不会被修改。
获取HCADER的好性能，的几点：
Ÿ 添加，删除或者扩展操作的后续会被认为是fractal tree的一部分。
可以使用optimize table x来一次性处理，optimize
table并不会重建索引，但是会诱发HCADER的运行。
Ÿ 每个HCADER必须独立的运行。如果想要增删改多个列，那么就写多个语句。
Ÿ 避免HCADER和在线索引操作一起处理。
Ÿ 表锁的事件有所不同，HCADER的锁定事件是脏数据刷新的事件，因为mysql会在alter table之后关闭。如果最近发生过检查点，那么操作就会很快。如果有太多的脏数据，那么刷新事件可能会很长。
Ÿ 避免删除的列是索引的一部分。如果列是索引的一部分，那么删除会很慢。
Ÿ 在线扩展只支持char，varchar，varbinary和integer。如果字段是主键或者任何secondary索引的一部分也不支持。
Ÿ 重命名只能是一句一个列。
注意所有的列属性必须制定，alter table change可能会很慢：
Ÿ 在线列重命名不支持以下字段，time，enum，blob，tinyblob，mediumblob，longblob。这些列的重命名会走标准的流程。
Ÿ 临时表不能使用HCADER。
3.5 压缩细节
TokuDB提供不同级别的压缩，是cpu和压缩率之间的一些平衡。标准的压缩使用少量的cpu但是压缩级别也比较低，高级别的压缩比较消耗cpu。
TokuDB压缩发生在后台线程，表示高压缩率并不会延迟数据库。事实上，在某些某些情况下，压缩率越高性能越好。。
注意：
一般在6核一下的推荐标准的压缩，6核以上的推荐高压缩
压缩率的选择还是取决于数据库的时候，推荐使用默认配置。
压缩在create table，alter table的基于每张表设置行格式：
CREATE TABLE table (
column_a INT NOT NULL PRIMARY KEY,
column_b INT NOT NULL) ENGINE=TokuDB
ROW_FORMAT=row_format;
如果在create table 的时候没有设置行格式，那么是怎么压缩看tokudb_row_format的设置。如果没有设置tokudb_row_format,那么压缩就使用zlib。
Row_format和tokudb_row_format取值如下：
· TOKUDB_DEFUALT:以默认方式压缩。在TokuDB 7.1，默认的使用zlib进行压缩，之后可能会改。
· TOKUDB_FAST:这个设置使用quicklz压缩。
· TOKUDB_SMALL:使用lzma进行压缩。
另外也可以直接选择压缩库，可用的压缩库：
· TOKUDB_ZLIB:使用zlib进行压缩，提供中等的压缩和cpu使用率
· TOKUDB_QUICKLZ:使用quicklz进行压缩，提供轻量级的压缩和低cpu使用率。
· TOKUDB_LZMA：使用lzma进行压缩，提供最高的压缩和cpu使用率。
· TOKUDB_SNAPPY:使用snappy进行压缩，合理的高速的压缩。
· TOKUDB_UNCOMPRESSED:这个设置关闭了压缩，并且表不会被压缩。
3.6 修改表的压缩
修改表的压缩语法如下：
ALTER TABLE table
ROW_FORMAT=row_format;
注意：
修改表偶的压缩至会影响性写入的数据。修改表压缩之后可以通过OPTIMZE TABLE把所有的block全部写一遍。
3.7 无io读复制
TokuDB slave可以配置，让来自master修改可以最小化。通过记录fractal tree索引：
· Insert/update/delete操作可以控制取消read-modify-write的行为，然后注入消息到合适的fractal tree。
· Update/delete操作可以配置取消需要io的一致性检查。
为了使用使用无io读复制，服务需要配置：
· 在replication master：
o 设置为binlog行模式:BINLOG_FORMAT=ROW
· 在replication slave:
o Slave必须为只读：read_only=1
o 取消一致性检查：tokudb_rpl_unique_checks=0
o 关闭查找(read-modify-write) ：tokudb_rpl_lookup_rows=0
可以在一个或者多个slave上配置。只要master使用了基于行的复制，优化在tokudb slave就可用。也就是说如果master使用innodb或者myisam表也是可用的。
3.8 事务和ACID兼容恢复
默认，Tokudb检查所有检查点之间的打开的表和日志的修改，所以在系统崩溃的，Tokudb会恢复所有的表大ACID兼容状态。所有的提交事务都会被反应在表上，并且没有提交的事务都会被回滚。
默认检查点60秒执行一次，如果检查点需要更多的执行，那么下一个检查点会马上执行。这个和日志文件截断的频率有关。用户可以使用flush logs命令执行检查点。当数据库关闭会执行检查点并且取消所有的感慨事务。日志在重启的时候被截断。
3.9 管理Log大小
TokuDB保证日志文件能够会到最后一次检查点。当日志文件到达100MB，就会启动一个新的文件。不管是否有检查点，所有的日志文件比checkpoint老的都会被丢弃。如果检查点时间被设置了很大的值，log的截断频率会减少。默认这个值为60s。
TokuDB为每个打开的事务保存了回滚日志，每个log的文件大小和事务的任务和被压缩保存到磁盘的大小有关。回滚日志在相关事务完成后会被截断。
3.10 恢复
恢复是自动的，TokuDB使用日志文件，和回滚日志来恢复。恢复的时间和和日志文件的大小和未压缩回滚日志大小有关。因此如果没有长时间运行的事务，那么恢复过程是很快的。
3.11 关闭写缓存
但是用任何事务安全的数据库，都假设在你了解硬件的写缓存的基础上。TokuDB提供事务安全的存储引擎。如果写入磁盘的行文，操作系统或者硬件没有真正的写入到磁盘，那么crash之后会损坏。
这个时候需要关闭写缓存，在ATA/SATA上使用以下命令：
$ hdparm -W0 /dev/hda
在某些情况下可以使用写缓存：
· 写缓存可以在xfs上，并且保证电池工作正常的情况下使用。如果在/var/log /messages上出现以下信息就不能使用写缓存：
o Disabling barriers, not supported with external log device
o Disabling barriers, not supported by the underlying device
o Disabling barriers, trial barrier write failed
以下情况就必须关闭写缓存：
· 如果你使用了ext3文件系统
· 如果使用了LVM
· 如果你使用了软的RAID
· 如果使用了RAID有battery-backed-up memory
3.12 进度跟踪
TokuDB有一个系统来跟踪长运行语句：
· Bluk Load:当使用load data infile导入大量数据，使用show processlist命令可以查看到进度分为2部分，已不是提示为：Inserted about 1000000 rows。另外一部分是百分比，提示为Loading of data about 45% done。
· 增加索引，当使用alter table或者create index命令创建索引，show processlist显示进度，会提示已经处理的行数。通过这个纤细来验证进度。和bulk load类似，第一阶段显示行处理进度，第二阶段显示百分比。
· 提交和取消，当提交或者取消一个事务，使用show processlist，会评估事务操作处理。
3.13 迁移到TokuDB
为了吧表转化到TokuDB引擎，可以使用alter table engine来修改，如果你想要从文件中导入数据，那么使用load data infile，不要使用mysqldump，因为有点慢。
4 TokuDB后台 ANALYZE TABLE
TokuDB有一个后台线程根据修改的评估来自动分析表。
4.1 后台作业
后台作业调度是短暂的，如果在关服务的时候有后台作业运行，那么会被停止。当服务重启已经运行的都会被忽略，需要重新来，如果手动调用ANALYZE TABLE和后台作业冲突，那么后台作业会被取消，可以通过表TOKUDB_BACKGROUND_JOB_STATUS查看后台作业是否运行。
新的tokudb_analyze_in_background变量可以用来实现控制时候ANALYZE TABLE是后台运行还是在前台。tokudb_analyze_mode用来控制ANALYZE TABLE的行为。
tokudb_analyze_mode变量用来实现对ANALYZE TABLE的控制：
TOKUDB_ANALYZE_CANCEL:取消在特定表上任何运行的或者应调用的作业。
TOKUDB_ANALYZE_STANDARD:使用已经存在分析算法。
TOKUDB_ANALYZE_RECOUNT_ROWS:重新计算表上的逻辑行并且更新当前的计数。
TOKUDB_ANALYZE_RECOUNT_ROWS 是新的机制，用来执行逻辑重算所有表中的行并且保存，作为表的评估值。这个模式增加是为了从老版本升级的TokuDB问题，老的TokuDB只支持物理行计数，并且没有一个正确的逻辑行计数。新创建的表或者分区开始以逻辑行，并且不需要被重新计算除非一些边界条件导致逻辑计数变得不准确。这个分析模式不会影响基数计数。会根据tokudb_analyze_in_background和tokudb_analyze_throttle。job运行后在设置变量不会影响当前job的运行。
取消任何后台线程，可以设置tokudb_analyze_mode=TOKUDBANALYZE_CANCEL并且在表上运行ANALYZE TABLE。
4.2 自动分析
为了实现后台的分析和收集计数统计每个表上都维护了一个增量值，这个值并不是保存的，当服务重启就会被设置为0.这个记录了所有的写操作。当这个值超过了tokudb_auto_analyze设置的值，那么根据当前会话的设置会执行一个分析。其他对于这个表的分区就会停止，除非这个分析完成。当分析完成，值被设置为0，重新计算。
任何分析完成，状态值都会被汇报到服务。半时反转分析，也被实现，也就是说如果超过一半的tokudb_analyze_time时间过去，但是还没有分析到数据量的一半，那么分析会重启，从最后一条数据开始往上分析，并且把分析结构累加到之前的结果上。
对于小表，自动分析可能每次修改都会执行。出发更是如下如果(table_delta >= ((table_rows *tokudb_auto_analyze) / 100))那么就开始运行ANALYZE TABLE。如果用户手动调用ANALYZE TABLE并且tokudb_auto_analyze被启动了并且没有冲突的后台作业，用户运行的ANALYZE TABLE会和增量值超过了上线一样，完成后会吧增量设置为0.
4.3 系统变量
tokudb_analyze_in_background:如果设置为on，那么任何analyze table都会在后台运行。
tokudb_analyze_mode:
TOKUDB_ANALYZE_CANCEL:取消在特定表上任何运行的或者应调用的作业。
TOKUDB_ANALYZE_STANDARD:使用已经存在分析算法。
TOKUDB_ANALYZE_RECOUNT_ROWS:重新计算表上的逻辑行并且更新当前的计数。
tokudb_analyze_throttle：表示当analyze table的时候最大每秒访问的key
tokudb_analyze_time：会话变量控制分析操作花费的事件。
tokudb_auto_analyze:会话变量控制超过自动分析的比率，写入操作到了这个比率就会更新。
tokudb_cardinality_scale_percent：弱化或者强化索引或者表的基数特性，比如innodb写死50%，在400行数据，40个唯一值，公式如下：(200/40 *tokudb_cardinality_scale) / 100
4.4 information_schema相关表
INFORMATION_SCHEMA.TOKUDB_BACKGROUND_JOB_STATUS
5 TokuDB变量
具体看：
https://www.percona.com/doc/percona-server/5.7/tokudb/tokudb_variables.html
6 TokuDB Troubleshooting
6.1 得知问题
复制和binary log:
TokuDB支持binary log和复制，但是有个限制TokuDB，就是auto-increment功能的锁机制没有实现，所以并发插入语句可能会导致不确定的，那么在slave上运行的时候会导致和master不匹配，只有在基于语句复制上才会发生。
在没有索引或者索引是主键子集的表上使用REPLACE INTO或者INSERT IGNORE，tokudb_pk_insert_mode控制行是否被复制。
Uninformative error message
LOAD INFILE命令可能会导致错误，ERROR 1030 (HY000): Got error 1 from storage engine.消息也会说是因为磁盘空间不足导致临时文件无法创建。
Transparent Huge Pages
如果启动了transparent huge page，Tokudb不会启动。使用以下命令来禁用：
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
XA behavior vs. InnoDB
InnoDB会强制死锁牺牲，但是Tokudb不会。
6.2 TukoDB锁
TokuDB使用key range lock来实现串行事务，在事务过程中获取，在事务结束时释放锁。
TokuDB把这些数据结构存放在锁树中。锁树存放了每个事务的range锁。另外锁树也保存了因为冲突没有被获得的锁。当事务退出，那么这些等待是锁也会被退出。如果pengding的锁没有被授予，那么锁超时后也会退出。
6.2.1 TOKUDB_TRX表
TOKUDB_TRX在INFORMATION_SCHEMA中，可以用一下方式和mysql客户端关联：
SELECT * FROM INFORMATION_SCHEMA.TOKUDB_TRX,
INFORMATION_SCHEMA.PROCESSLIST
WHERE trx_mysql_thread_id = id;
6.2.2 TOKUDB_LOCKS表
Tokudb_locks表在information_schema中包含了授权了的TokuDB的事务中的锁。使用以下语句和客户端关联：
SELECT id FROM INFORMATION_SCHEMA.TOKUDB_LOCKS,
INFORMATION_SCHEMA.PROCESSLIST
WHERE locks_mysql_thread_id = id;
6.2.3 TOKUDB_LOCK_WAITS表
Tokudb_lock_waits表也在information_schema中：
SELECT * FROM INFORMATION_SCHEMA.TOKUDB_LOCK_WAITS;
6.3 引擎状态
具体看：
https://www.percona.com/doc/percona-server/5.7/tokudb/tokudb_troubleshooting.html#engine-status
6.4 全局状态变量
具体看：
https://www.percona.com/doc/percona-server/5.7/tokudb/tokudb_troubleshooting.html#global-status
7 Percona TokuBackup
Percona tokubackup是一个开源的备份tokudb的一个热备工具。在备份期间不会锁定数据库。Tokubackup会获取系统写入文件的调用，并复制到备份目录中。
7.1 从binary安装
TokuBackup包含在percona server 5.7.10和之后的版本，安装可以使用ps_tokudb_admin脚本。
安装TokuBackup：
1. 运行ps_tokudb_admin –enable-backup增加preload-hotbackup选项到[mysqld-safe]下的my.cnf中。
2. 重启mysql服务
3. 运行ps_tokudb_admin –enable-backup安装tokubackup插件。
7.2 备份
备份的目录必须存在，可以写为空，并且属于mysql启动用户。一旦目录被创建备份可以使用以下命令备份：
mysql> set tokudb_backup_dir='/path_to_empty_directory';
7.3 还原
备份工具没有还原数据库的功能，要使用rsync或者cp来还原文件。检查还原的文件和对应的关系和权限。比如使用rsync来还原备份：
$ rsync -avrP /data/backup/ /var/lib/mysql/
修改所有者
$ chown -R mysql:mysql /var/lib/mysql
如果修改了某人tokudb数据目录或者Tokudb日志目录，那么需要独立的去设置。
$ rsync -avrP /data/backup/mysql_data_dir/ /var/lib/mysql/
$ rsync -avrP /data/backup/tokudb_data_dir/ /path/to/original/tokudb_data_dir/
$ rsync -avrP /data/backup/tokudb_log_dir/ /path/to/original/tokudb_log_dir/
$ chown -R mysql:mysql /var/lib/mysql
$ chown -R mysql:mysql /path/to/original/tokudb_data_dir
$ chown -R mysql:mysql /path/to/original/tokudb_log_dir
7.4 推荐配置
7.4.1 监控进度
TokuBackup更新processlist的状态，显示备份的进度，可以使用show processlist查看。
7.4.2 排除源文件
可以通过正则表达式排除文件或者目录，设置在tokudb_backup_exclude会话变量中。如果源文件名负荷这个正则表达式，那么就会被排除。比如lost+found目录：
mysql> SET tokudb_backup_exclude='/lost\\+found($|/)';
7.4.3 备份率阀值
可以指定备份的阀值，tokudb_backup_throttle会话级别变量。这个变量表示每秒字节传输率。
7.4.4 限制备份目标
你可以限制本地目标目录，tokudb_backup_allowed_prefix系统变量。默认是null，备份没有限制目标目录。参数是只读的只能通过my.cnf配置。
7.4.5 错误报告
Tokubackup使用2个变量来获取错误信息。Tokudb_backup_last_error, tokudb_backup_laster_error_string。当tokubackup发生一个错误，变量就会显示显影的错误代码和错误信息。
mysql> SET tokudb_backup_dir='/tmp/backupdir';
ERROR 1231 (42000): Variable 'tokudb_backup_dir' can't be set to the value of '/tmp/backupdir'
mysql> SELECT @@tokudb_backup_last_error;
+----------------------------+
| @@tokudb_backup_last_error |
+----------------------------+
| 17 |
+----------------------------+
mysql> SELECT @@tokudb_backup_last_error_string;
+---------------------------------------------------+
| @@tokudb_backup_last_error_string |
+---------------------------------------------------+
| tokudb backup couldn't create needed directories. |
+---------------------------------------------------+
7.4.6 限制和已知的问题
· 你必须关闭innodb异步io如果使用tukobackup备份innodb表。否则就会出现一致性错误。innodb_use_native_aio=0
· 如果需要还原到指定点，需要手动获取binary log position。
· 事务存储引擎会在备份还原后，第一次启动会进行恢复。
· 表使用非事务引擎在备份的时候不会锁定。所以最好在备份的时候避免表操作。
· 备份的时候目标目录必须存在，并且为空
· TokuBackup会一直备份datadir目录，选择性的备份tokudb_data_dir和tokudb_log_dir,和binary log目录。如果不在datadir中那么需要独立备份。
· 不支持其他目录结构，innodb，myisam和其他存储引擎必须在datadir下面。
· Buzhichi symbolic links
· 不备份配置文件
· 不备份datadir 外的表空间。
· 当备份的时候在执行optimize table或者alter table tablespace，那么就无法恢复备份。
· 不支持增量备份。
8 FAQ
具体看：
https://www.percona.com/doc/percona-server/5.7/tokudb/tokudb_faq.html
