Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2147630
  • 博文数量: 283
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 2100
  • 用 户 组: 普通用户
  • 注册时间: 2014-03-31 14:30
个人简介

自己慢慢积累。

文章分类

全部博文(283)

分类: Mysql/postgreSQL

2017-07-07 10:30:44

转自:  https://yq.aliyun.com/articles/213?spm=5176.100239.blogcont6376.7.8pBQS9

TokuDB · 让Hot Backup更完美

 2015-12-21 11:15:16 浏览1580 评论1

引擎技术

摘要: 很久很久以前,内核君发表了一篇HA方案·TokuDB热备的文章,方法很简单: 1) SET TOKUDB_CHECKPOINT_LOCK=ON; 2) 开始拷贝TokuDB的数据文件(不包含日志文件) 3) FLUSH TABLES WITH READ LOCK; 4) 记录binlog位置,拷贝最新的binlog和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见这里:

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

用云栖社区APP,舒服~

【云栖快讯】首届阿里巴巴中间件技术峰会,揭秘阿里10年分布式技术沉淀!阿里高可用体系核心缔造者、全链路压测创始人,DRDS与TDDL负责人等大咖出场,干货分享,不可错过!  
阅读(829) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~