共计 1501 个字符,预计需要花费 4 分钟才能阅读完成。
概述
XtraBackup 是一款对于 MySQL 物理备份必不可少的工具,然而有时候在备份数据量级较大的数据库时,如果未做优化的话,还是有点慢,当然绝对于逻辑备份,未然是很快了,那到底还能不能再快一点呢,又是什么参数在影响着 XtrBackup 的备份速度呢?带着这个疑难咱们往下看。
首先咱们须要先理解 XtraBackup 的备份原理,话不多说间接看图。
如图所示:
1. 当 innobackupex 命令开始备份的时候,首先会启动 xtrabackup 过程,xtrabackup 又分为两个线程,一个用于拷贝 ibd 文件,一个用于拷贝 redo 文件,redo 的拷贝线程只有一个,在 ibd 的拷贝线程启动前启动,在 ibd 的拷贝线程完结后完结。
2.xtrabackup 拷贝实现 idb 后,告诉 innobackupex(通过创立文件),同时本人进入期待(redo 线程依然持续拷贝)
3.innobackupex 收到 xtrabackup 告诉后,执行 FLUSH TABLES WITH READ LOCK (FTWRL),获得一致性地位点,而后开始备份非 InnoDB 文件(包含 frm、MYD、MYI、CSV、opt、par 等)。拷贝非 InnoDB 文件过程中,因为数据库处于全局只读状态,非 InnoDB 表(次要 是 MyISAM)如果比拟多的话整库只读工夫就会比拟长。
4. 当 innobackupex 拷贝完所有非 InnoDB 表文件后,告诉 xtrabackup(通过删文件),同时本人进入期待(期待另一个文件被创立);
5.xtrabackup 收到 innobackupex 备份完非 InnoDB 告诉后,就进行 redo 拷贝线程,而后告诉 innobackupex,redo log 拷贝实现(通过创立文件);
6.innobackupex 收到 redo 备份实现告诉后,就开始解锁,执行 UNLOCK TABLES;
7. 最初 innobackupex 和 xtrabackup 过程各自实现收尾工作,如资源的开释、写备份元数据信息等,innobackupex 期待 xtrabackup 子过程完结后退出
参数介绍
可能让咱们减速备份的参数其实严格来说有以下两个:
- –parallel
2.–compress-threads
先来说第一个参数 –parallel,先看下官网解释:
也就是说,这个参数的作用是,在 XtraBackup 备份开始拷贝 ibd 文件的时候能够并行拷贝的线程数量,默认的话是单线程拷贝的,如果 ibd 文件较多的话只能拷贝完一个再持续下一个,有一点须要留神如果表存储在一个 ibd 文件中,那么他将不会起到任何作用。
再看 –compress-threads 官网给出的解释:
简略来说就是针对 InnoDB 数据文件进行压缩的线程数,在指定这个参数的时候无需加上 –compress 也能够实现压缩。
测试
备份命令:
[root@TEST/data]# innobackupex --host=127.0.0.1 --user=root --password=123456 --port=3306 --parallel=4 --compress-threads=4 --stream=xbstream --tmpdir=/backup/tmp --no-version-check /backup >/backup/20210125/20210125`date +%H%M`
硬件 | 数据量 | 参数 | 所用工夫 |
---|---|---|---|
8C/8G | 100G | null | 20 分钟 |
8C/8G | 100G | –compress-threads=4 | 15 分钟 |
8C/8G | 100G | –parallel=4 | 12 分钟 |
8C/8G | 100G | –parallel=4;–compress-threads=4 | 8 分钟 |