TokuDB · 让Hot Backup更完美

很久很久以前，内核君发表了一篇HA方案·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;

这些步骤可以很方便的嵌入到Percona XtraBackup中，与InnoDB一起工作，目前看是一个比较简单可行的方案。

问题来了。
当某个实例的数据量达到TB级，你会发现备库(基于备份)重搭后，启动会灰常灰常慢，因为他们都在recover redo-log，为什么呢？

 1) SET TOKUDB_CHECKPOINT_LOCK=ON;
 2) 开始拷贝TokuDB的数据文件(不包含日志文件)
     -- 由于拷贝TB级的数据非常耗时，redo log持续增加甚至上万个

当TokuDB启动后，扫描和recover这几万个redo log将是灾难性的。

解决这个问题比较简单，我们稍微调整下热备的顺序即可：

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

这样在拷贝TokuDB数据文件的时候，就跟redo-log没半毛钱关系了，而且拷贝的redo-log数也大大减少！

本以为这样就可以早点下班回家，但问题还是来。

某实例有几十万个TokuDB文件(分区表文件)，使用热备的数据备库重搭后，复制过程中偶尔会出现"Duplicate entry ... for key 'PRIMARY'"错误。

引起这个错误的原因比较深，触发自TokuDB内部机制。

TokuDB每个分区表有数个文件组成（想了解TokuDB数据库文件的请轻戳这里），当分区表非常多的时候，打开的文件句柄数会非常多，受限于open_files_limit配置，TokuDB底层会触发句柄关闭机制，对当前文件进行checkpoint操作(新数据被刷到磁盘且生效)再做close，这样即使拿到checkpoint锁后，还是有数据被写入，就引发了以上问题。

为了解决这个问题，我们在热备的过程中引入一个状态：in_backup = true，防止文件关闭做checkpoint操作，具体的patch见这里:
https://github.com/percona/PerconaFT/pull/331/files

这样TokuDB的热备就比较完美了，整个热备过程中，所有的数据文件均处于一个“一致性”状态，所有的操作都在redo-log里，不再污染数据文件。