MySQL · TokuDB · 让Hot Backup更完美
最后更新于:2022-04-01 10:37:18
## 前言
很久很久以前,内核君发表了一篇[HA方案·TokuDB热备](http://mysql.taobao.org/index.php?title=MySQL%E5%86%85%E6%A0%B8%E6%9C%88%E6%8A%A5_2014.09#TokuDB.C2.B7_HA.E6.96.B9.E6.A1.88.C2.B7TokuDB.E7.83.AD.E5.A4.87)的文章,方法很简单:
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数据库文件的请[轻戳这里](http://mysql.taobao.org/monthly/2015/09/10/)),当分区表非常多的时候,打开的文件句柄数会非常多,受限于`open_files_limit`配置,TokuDB底层会触发句柄关闭机制,对当前文件进行checkpoint操作(新数据被刷到磁盘且生效)再做close,这样即使拿到checkpoint锁后,还是有数据被写入,就引发了以上问题。
为了解决这个问题,我们在热备的过程中引入一个状态:in_backup = true,防止文件关闭做checkpoint操作,具体的patch见[这里](https://github.com/percona/PerconaFT/pull/331/files)。
这样TokuDB的热备就比较完美了,整个热备过程中,所有的数据文件均处于一个“一致性”状态,所有的操作都在redo-log里,不再污染数据文件。