利用JuiceFS使MySQL 备份验证性能提升 10 倍

利用JuiceFS使MySQL 备份验证性能提升 10 倍,第1张

利用JuiceFS使MySQL 备份验证性能提升 10 倍 目录
  • 数据准备
  • 使用默认参数
  • 增大XtraBackup的内存缓冲区
  • 增大XtraBackup读线程数
  • JuiceFS启用异步写
  • 增大JuiceFS的磁盘缓存
  • 增大数据库数据量
  • 总结

前言:

JuiceFS 非常适合用来做 MySQL 物理备份,具体使用参考官方文档。在测试时,备份验证的数据准备(xtrabackup --prepare)过程非常慢。我们借助 JuiceFS 提供的性能分析工具做了分析,快速发现性能瓶颈,通过不断调整 XtraBackup 的参数和 JuiceFS 的挂载参数,在一个小时内将时间缩短到原先的 1/10。本文将我们性能分析和优化的过程记录分享下来,给大家分析和优化 IO 性能提供参考。

数据准备

我们通过 SysBench 工具生成一个大小 11GiB 左右的单表数据库,数据库表的 partition 设置成 10。为了模拟一个正常的数据库读写场景,通过 SysBench 以秒 50 个请求的压力访问数据库,在该压力下数据库对数据盘造成的写数据在 8~10MiB/s 范围内。通过下列命令将数据库备份到 JuiceFS 上。

# xtrabackup --backup --target-dir=/jfs/base/

为了保证每次数据准备操作的数据完全一样,使用 JuiceFS 的快照(snapshot)功能基于 /jfs/base 目录生成快照 /jfs/base_snapshot/。每一次操作前都会将前一次数据准备操作过的数据删掉重新生成一个新的快照。

使用默认参数
# ./juicefs mount volume-demoz /jfs

#  time xtrabackup --prepare --apply-log-only --target-dir=/jfs/base_snapshot

执行总耗时62秒。

JuiceFS支持导出操作日志 oplog,并能对 oplog 进行可视化展示。在执行 xtrabackup --prepare操作之前我们新开一个终端连接到该服务器,在命令行输入

# cat /jfs/.oplog > oplog.txt

开始搜集 oplog 日志,然后执行 xtrabackup --prepare 操作,操作结束后将 oplog.txt 下载到本地,上传到 JuiceFS 提供的 oplog 分析页面:https://juicefs.com/oplog/。

我们将 oplog 进行可视化展示

这里先大致介绍下这个图中各种元素含义。我们的一条 oplog 中包含了时间戳,线程 ID,文件系统操作函数(read, write, fsync, flush 等),操作持续的时间等。左侧数字表示线程 ID,横轴表示时间,不同类型操作用不同颜色标记。

我们把局部图像放大,不同颜色代表不同类型的操作就一目了然。

排除掉与本次操作无关的几个线程。在数据准备过程中有 4 个线程负责读,5 个线程负责写数据,读写在时间上都是重叠的。

增大 XtraBackup 的内存缓冲区

参考 XtraBackup 官方文档,数据准备是使用内嵌的 InnoDB 在备份数据集上执行故障修复(crash recovery)的过程。

使用 --use-memory 选项增大内嵌 InnoDB 的内存缓冲区大小,默认 100MB,我们增大到 4GB。

# time xtrabackup --prepare --use-memory=4G --apply-log-only --target-dir=/jfs/base_snapshot

执行时间降到了33秒。

可以看到读写不重叠了 ,将数据读到内存处理完成后写入文件系统。

增大 XtraBackup 读线程数

通过增大缓冲区将时间缩短了一半,整个读的过程耗时依然比较明显。我们看到每个读线程基本都是跑满的状态,我们尝试增加更多的读线程。

# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=16 --innodb-read-io-threads=16 --apply-log-only --target-dir=/jfs/base_snapshot

行时间降到了23秒。

读线程已经增加到了 16 个(默认 4 个),读操作降到 7 秒左右。

JuiceFS 启用异步写

上一步我们极大的优化了读操作时间,现在写过程消耗的时间就比较明显了。通过分析 oplog,发现写操作中 fsync 是不能并行的,因此增大写线程数并不能提升写的效率,在实际操作过程中我们也通过增大写线程数验证了这一点,这里就不赘述了。分析 oplog 对同一个文件(相同文件描述符)的写操作的参数(偏移,写数据大小),发现有大量的随机写操作,我们可以在挂载 JuiceFS 时启用 --writeback 选项,写数据时先写本地盘,再异步写到对象存储。

# ./juicefs mount --writeback volume-demoz /jfs
# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=16 --innodb-read-io-threads=16 --apply-log-only --target-dir=/jfs/base_snapshot

时间降到了 11.8 秒。

写过程已经降到 1.5 秒左右。

我们看到读线程读操作依然比较密集,我们尝试持续增加读线程数,InnoDB 读线程数最大为 64,我们直接调成 64。

# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=64 --innodb-read-io-threads=64 --apply-log-only --target-dir=/jfs/base_snapshot

执行时间 11.2 秒,相比之前基本没变化。

我们看到,读线程读操作已经比较稀疏了,应该是线程读的数据之间有依赖关系,导致不能完全并行化,已经不能通过提升线程数压缩读过程的时间了。

增大 JuiceFS 的磁盘缓存

在上一步中,我们通过提升读线程数来提升读过程的效率已经到顶了,只能通过降低读数据的延迟来减少读过程时间。

JuiceFS 在读操作处理上提供了预读和缓存加速能力,我们接下来尝试通过增大 JuiceFS 的本地缓存来降低读操作的延迟。

将 JuiceFS 的本地缓存由高效云盘换成 SSD 云盘,并将缓存大小由 1G 改成 10G。

# ./juicefs mount --writeback volume-demoz --cache-size=10000 --cache-dir=/data/jfsCache /jfs

# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=64 --innodb-read-io-threads=64 --apply-log-only --target-dir=/jfs/base_snapshot

执行时间降到了 6.9 秒。

通过提升缓存性能和增大缓存空间进一步减少了读操作耗时。

到此我们总结一下,我们通过分析 oplog,不断寻找可以优化的点,将整个数据准备过程一步步从 62 秒降到 6.9 秒,效果通过下图更直观的展示。

增大数据库数据量

以上的操作都是针对 11G 这样一个比较小的数据集不断调整参数进行优化得到一个很好的结果。作为对比,我们以同样的方式生成一个 115G 左右的 partition 为10的单表数据库。在 SysBench 持续每秒 50 个请求情况下,执行备份操作。

# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=64 --innodb-read-io-threads=64 --apply-log-only --target-dir=/jfs/base_snapshot

这个过程耗时 74 秒。

我们看到,读和写还是分开的。

在数据量增大10倍左右,相应的准备时间也增大到10倍。这是因为备份(xtrabackup --backup)过程所需的时间扩大到 10 倍,在 SysBench 对数据库压力不变的情况下,备份过程中产生的 xtrabackup_logfile 也是原先的 10 倍。数据准备是要把 xtrabackup_logfile 中的所有数据更新合并到数据文件中,可见即使数据规模增大了 10 倍,但更新单条日志的时间基本不变。从上图也可以验证这一点,数据规模增大后,准备过程仍然是分成了读数据和写数据这两个明显的过程,说明设定的 4GB 的缓冲区大小仍然是够用的,整个过程仍然可以在内存中完成然后更新到文件系统。

总结

我们使用 SysBench 这个相对简单的工具构造初始数据,持续给数据库一定数据更新的压力模拟数据备份时数据库运行场景。使用 JuiceFS 的 oplog 来观察 XtraBackup 在数据准备过程中访问备份数据的读写特点,调整 XtraBackup 和 JuiceFS 的参数来不断优化数据准备过程的效率。

在实际生产场景中,情况比我们 SysBench 模拟要复杂得多,我们上面的线性关系不一定严格成立,但是我们通过分析 oplog 快速发现可以优化的点,进而不断调整 XtraBackup 和 JuiceFS 的缓存和并发的思路是通用的。

整个调参过程耗时 1 小时左右,oplog 分析工具在这个过程中发挥了很大的作用,帮助我们快速定位系统性能瓶颈,从而针对性地调整参数做优化,也希望这个 oplog 分析功能也能帮助大家快速定位和分析遇到的性能问题。

到此这篇关于利用JuiceFS使MySQL 备份验证性能提升 10 倍的文章就介绍到这了,更多相关 MySQL 性能提升 内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

欢迎分享,转载请注明来源:内存溢出

原文地址:https://outofmemory.cn/sjk/2997228.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2022-09-26
下一篇2022-09-26

随机推荐

  • 考试前喝咖啡有作用吗

    可能会起反作用,最好不要考前喝咖啡。许多考生和家长都认为,咖啡的提神作用会为考前冲刺和临场发挥打上一针兴奋剂。然而营养学专家提醒,“咖啡提神”这种做法不但靠不住,还可能出现反作

    2022-12-06
    000
  • 百闻不如一见什么意思

    “百闻不如一见”出自《汉书·赵充国传》:“百闻不如一见;兵难隃度;臣愿驰至金城;图上方略。”这个谚语的意思是听到一百次,也不如亲眼见到一次,强调凡事要经过调查研究才能下结论。《百闻不如一见》的故事内容

    2022-12-06
    000
  • 中毒色口红色号是什么意思

    中毒色,是指一系列口红颜色,顾名思义就是嘴唇发黑,看起来像中毒一样,很多大牌明星都对这个唇色喜爱有加,中毒色口红系列有枣红色,暗黑姨妈色,顾里色等新颜色。很多人都还在豆沙色,西柚色,斩男色徘徊,这些传

    2022-12-06
    000
  • 拉拉人是指什么?不要单纯地以为拉拉人就是拉拉

    拉拉人,日本手游《LoveL‌‌‌‌‌ive》的粉丝叫ller,也称拉拉人。首先声明,拉拉人和拉拉完全不是一回事。与之相关的词汇还有邦邦人。邦邦人的叫法来源于百度bangdream贴吧。bangdre

    2022-12-06
    000
  • 网络流行语小猪佩奇不差钱是什么意思

    小猪佩奇不差钱,网络流行词。小猪佩奇是英国的学前动画片,在英国人眼中是中产阶级的代表,这部动画片讲述的也是关于英国中产阶级的生活理念和消费观。近些年,小猪佩奇对于英国消费市场的影响也是显而易见的。普通

    2022-12-06
    000
  • 热狗人是什么意思

    热狗人,即漫画《刃牙》的快乐粉丝,有的是真粉丝,有的只是跟风玩梗的网友。‌‌‌‌‌‌热狗人,该梗是刃牙玩了港漫海虎之后“呵呵呵,我要吃热狗呀”那里来的。热狗人是漫画《海虎2》的梗(基佬凌辱白次男时说:

    2022-12-06
    000
  • 朱元璋为什么传位给孙子

    朱元璋将皇位传给孙子朱允炆而不是儿子,主要有三方面的原因,一是朱允炆天资聪颖,得朝臣推荐;二是朱允炆是太子朱标的长子,嫡长子死后由长孙继承皇位这在当时也是传统;三是因为朱元璋不想要儿子们因为皇位产生

    2022-12-06
    000
  • 李师师他是谁

    李师师是北宋汴京的名妓,当时的皇帝宋徽宗很喜欢她,著名词人周邦彦也很欣赏她,李师师出身风尘之地,传说她既倾国倾城,又惊才艳艳,所以被达官显贵、风流才子们竞相追求,汴京上下,几乎没有不知道她的。 李师

    2022-12-06
    000
  • 三国猛将吕布的死因

    公元198年,吕布反叛朝廷与袁术结盟,击败了驻守沛城的刘备。曹操派夏侯惇救援刘备失败后,亲自领兵攻打吕布,把他围在下邳城中。吕布率兵突围,被曹军击退,只能守城不出。曹军在城下安营扎寨,将吕军困于

    2022-12-06
    000

发表评论

登录后才能评论

评论列表(0条)

    保存