数据库备份瓶颈及Hdfs方案考虑 最终版
?
4 likes?1,001 views
传统数据库备份的瓶颈分析：CPU、压缩、IO，并引入并行压缩(之前老大江枫介绍过，这次也引入进来); hdfs备份的引入，数据全部备份到HDFS上。
![并行压缩使用CPU评估
? 备份时间分布
速度(MB/s)
9
8 8.54
7 8.08
6 6
5
4 速度(MB/s)
3 3.28
2
1 1.21 1.03
0
‐p?0?‐f?0?‐l?6m ‐p?1?‐f?0?‐l?6m ‐p?1?‐f?0?‐l?20m ‐p?1?‐f?1? ‐p?1?‐n?6?‐f?1? ‐p?1?‐n?8?‐f?1
备注：
第一区间说明：在限速是6m的情况下，平行压缩与单核压缩无异，瓶颈在DISK；
第二区间说明：在限速从6m >20m >全速(4核约36M=6 6)??[压缩比确实约为1/6]
第二区间说明：在限速从6m‐>20m‐>全速(4核约36M=6*6) [压缩比确实约为1/6]
第三区间说明：在全速开放后，随着CPU核数从4‐>6,?6‐>8，增量分别为2和0.5;
说明速度增量未随CPU增加线性增加，瓶颈在CPU调度(IDLE为0)。](https://image.slidesharecdn.com/hdfs-111106231859-phpapp02/85/Hdfs-8-320.jpg)
![脚本的使用方式
xtrabackup_hdfs.sh?
b k hdf h
[
[‐f?1/0]?[‐l?6m]?[‐p?0/1]?[‐n?CPUNUM]
][ ][ p ][ ]
限速：
限速 f 0 l 速度
‐f?0?‐l?速度
全速： ‐f?1?忽略速度
并行压缩：‐p?1?‐n?CPU数量
(不指定默认CPU核数的 )
(不指定默认CPU核数的一)
gzip压缩： ‐p?0?忽略CPU数量](https://image.slidesharecdn.com/hdfs-111106231859-phpapp02/85/Hdfs-11-320.jpg)
![推荐配置
? 全速备份 (不提供服务的备库 空间大)
全速备份： (不提供服务的备库、空间大)
– bash?xtrabackup_hdfs.sh?‐f?1?‐p?1?[‐n?8]
? 限速备份：(提供服务的备库)
– bash?xtrabackup_hdfs.sh?‐f?0?‐l?6/10m?‐p?1????
/
– bash?xtrabackup_hdfs.sh?‐f?0?‐l?20m?‐p?1??(若提供dump)
? 单核压缩：(现有方式)
– bash xtrabackup hdfs sh f 0 l 6m p 0
bash?xtrabackup_hdfs.sh?‐f?0?‐l?6m?‐p?0
– bash?xtrabackup_hdfs.sh?‐f?1?‐p?0?(效率不高，瓶颈在gz)](https://image.slidesharecdn.com/hdfs-111106231859-phpapp02/85/Hdfs-12-320.jpg)
![限速压缩后引入的问题
? 限速6M/10M之后
/usr/bin/innobackupex‐1.5.1??‐‐stream=tar $DIR?|?./pv ‐q?
‐L6m[1]| gzip(pbzip2 –p$CPUNUM ) [2] > HDFS
[ ]|?gzip(pbzip2? p$CPUNUM [ ] >?HDFS
? 问题：
– [1]导致6m的传输
– [2]压缩之后每秒钟大概1m(假设压缩比为1/6)；
[ ]
– HDFS默认配置是64M之后开始写入HDFS；
– 所以，有可能在64/1=64秒时间之内client和HDFS无
所以，有可能在64/1 64秒时间之内client和HDFS无
交互；而默认6秒钟的timeout设置。
public?static?int READ_TIMEOUT?=?60?*?1000; //其实是超过了这个值(dfs.socket.timeout)
public?static?int READ_TIMEOUT_EXTENSION?=?3?*?1000;
备注：错误java.net.SocketTimeoutException:?63000?millis timeout?while?waiting?for?channel?
to?be?ready?for?read.?](https://image.slidesharecdn.com/hdfs-111106231859-phpapp02/85/Hdfs-13-320.jpg)
![升级步骤
? 升级组件
写入j 程序
– HDFS写入java程序
– pbzip2并行压缩程序
? 升级步骤
1.?sudo yum?install?‐b?test?hdfs***?
[2.]?sudo yum?install? b?test?pbzip2
[2 ] sudo yum install ‐b test pbzip2
备注： 1自动会安装2](https://image.slidesharecdn.com/hdfs-111106231859-phpapp02/85/Hdfs-17-320.jpg)
数据库备份瓶颈及Hdfs方案考虑 最终版
- 1. 数据库备份瓶颈及HDFS方案考虑 数据库备份瓶颈及 S方案考虑 瓶颈 备份策略 并行 缩引 ——瓶颈、备份策略、并行压缩引入 穆公 2011.10.09
- 2. 大纲 ? 已有的备份策略及主要问题 有的备份策略 主要问题 ? 问题分析 ? 备份恢复及快速恢复 ? HDFS的备份、调度使用介绍 ? 总结
- 3. 备份方法 ? M ld Mysqldump – 逻辑备份，导出成SQL文件;?单线程进行 – ‐Q?Quote?table?and?column?names?with?backticks (`). – ‐‐single‐transaction?(除DDL外 备份的是 个完整镜像 除 外 备份的是一个完整镜像) – ‐‐master‐data?(开启‐‐lock‐all‐tables，除非使用上面的ST) – ‐‐lock‐all‐tables(dump过程中全锁，自动关闭ST和lock‐tables) – ‐‐lock‐tables(锁定当前导出的数据表,而不是锁定全部库下的表。) ? Mydumper – 多表并行备份 ? Xtrabackup ——目前版本1.6.0(主要的恢复方式) – 物理备份 – 单线程进行 – /usr/bin/innobackupex‐1.5.1??‐‐stream=tar $DIR?|?./pv ‐q?‐L6m|? gzip(pbzip2?–p$CPUNUM )?>?HDFS URL1:??http://bugs.mysql.com/bug.php?id=35157 (5.1.25之后版本解决)
- 4. 已有的备份策略及问题 ? 定时备份 – Crontab备份 – 部署维护麻烦 ? 全部限速备份 部限 备份 – 原因1：NAS问题 – 原因2：备份时对业务读库影响非常大 ? 备份介质：NAS – NAS不稳定导致机器hung死情况时有发生 – NAS备份也有瓶颈
- 5. 问题分析 ? 备份时间分布 – 备份时间测试 源文件50G 备份后8G 项目 备份时间(分) 写入速度(MB/s) backup?+?tar?+?gz?>?HDFS 38?(37) 3.52 backup?+?tar?+?gz >/dev/null * HDFS的时间大 34 概是4分钟 backup?+?tar?&>/dev/null backup + tar &>/dev/null * gz压缩的时间 5 (6) 占了85% backup?+?tar?+?gz >?DISK 3.52 写入HDFS和 38 DISK速度 样 DISK速度一样 – 说明：备份瓶颈在压缩上；写入HDFS和写入本 地DISK速度一样. 地DISK速度一样 – backup+tar:gzip:HDFS 约 1:6:1?(5:29:4)
- 6. 问题分析——压缩的改进 问题分析 压缩的改进 不同压缩方式的备份时间对比 ? 备份时间对比 40 35 30 压缩时间缩短 25 20 至少一半 15 备份时间(分)? 10 5 0 backup?+?tar?+?gz?>? backup?+?tar?+? backup?+?tar?+?gz? backup?+?tar?+? HDFS? pbzip2?>?HDFS? >/dev/null? pbzip2?>/dev/null? 项目(snsdc数据备份 50G) 备份时间(分) 写入速度(MB/s) 节约时间分钟 不限速 (原来29分钟) backup?+?tar?+?gz >?HDFS p g 38?(37) ( ) 3.52 backup?+?tar?+?pbzip2?>?HDFS 20 节约17分钟 backup?+?tar?+?gz >/dev/null 34 * backup?+?tar?+?pbzip2?>/dev/null 18 节约16分钟
- 7. 问题分析——压缩的改进(2) 问题分析 压缩的改进(2) ? 备份时间分布 项目 耗时(分钟) 速度 对比 备注 -p 0 -f 0 -l 6m 270 1.21MB/s 现有方式 Gzip 限速 瓶颈不在压 -p 1 -f 0 -l 6m 258 p 1.03MB/s . / Pbzip限速 缩在读Disk 缩在读Di k -p 1 -f 0 -l 20m 81 3.28MB/s 速度是3倍 Pbzip2?限速 20m Pbzip2?全速 4核 -p 1 -f 1 45 6.00MB/s 提升5倍 默认占一半CPU -p 1 -n 6 -f 1 33 8.08MB/s 提升7倍 Pbzip2?全速 6核 备注： ‐f?表示是否全速(‐f?0表示限速，为1忽略‐l参数)； ‐l限速多少兆； ‐p是否启用并行压缩(‐p 1表示并行压缩，为0忽略‐n参数；‐n用几个CPU核) p是否启用并行压缩( p?1表示并行压缩，为0忽略 n参数； n用几个CPU核)
- 8. 并行压缩使用CPU评估 ? 备份时间分布 速度(MB/s) 9 8 8.54 7 8.08 6 6 5 4 速度(MB/s) 3 3.28 2 1 1.21 1.03 0 ‐p?0?‐f?0?‐l?6m ‐p?1?‐f?0?‐l?6m ‐p?1?‐f?0?‐l?20m ‐p?1?‐f?1? ‐p?1?‐n?6?‐f?1? ‐p?1?‐n?8?‐f?1 备注： 第一区间说明：在限速是6m的情况下，平行压缩与单核压缩无异，瓶颈在DISK； 第二区间说明：在限速从6m >20m >全速(4核约36M=6 6)??[压缩比确实约为1/6] 第二区间说明：在限速从6m‐>20m‐>全速(4核约36M=6*6) [压缩比确实约为1/6] 第三区间说明：在全速开放后，随着CPU核数从4‐>6,?6‐>8，增量分别为2和0.5; 说明速度增量未随CPU增加线性增加，瓶颈在CPU调度(IDLE为0)。
- 9. 并行压缩使用CPU评估(2) ? 备份时间分布 速度(MB/s) 9 8 8.54 7 8.08 6 6 5 4 速度(MB/s) 3 3.28 2 1 1.21 1.03 0 ‐p?0?‐f?0?‐l?6m ‐p?1?‐f?0?‐l?6m ‐p?1?‐f?0?‐l?20m ‐p?1?‐f?1? ‐p?1?‐n?6?‐f?1? ‐p?1?‐n?8?‐f?1 备注： 1. 引入并行压缩、不限速后，速度约提升7倍左右； 2 并行压缩的核使用达到8核之后，系统非常繁忙。8核IDLE几乎均为0， 2. 故默认采用一半的核。 (8核只在紧急备份和恢复时使用)
- 10. 并行压缩使用CPU评估(3) ? 大数据库 大数据库(500G以上)对备份提升的验证 以上 对备份提升的验 项目 耗时(分钟) 速度 对比 备注 -p 0 -f 0 -l 6m 1310 1.42MB/s 现有方式 Gzip 限速 -p 0 -f 1 602 2.91MB/s 瓶颈压缩 Gzip限速 Pb i 2 全速 10核 Pbzip2?全速 -p 1 -n 10 -f 1 179 10.39MB/s 平行压缩 默认占8核 -p 1 -n 16 -f 1 155 11.94MB/s 全部核都用 Pbzip2?全速1 6核 备注： 再次说明，引入并行压缩明显提高了整体的性能；但是不能占用全部CPU； 提升月7倍左右。
- 11. 脚本的使用方式 xtrabackup_hdfs.sh? b k hdf h [ [‐f?1/0]?[‐l?6m]?[‐p?0/1]?[‐n?CPUNUM] ][ ][ p ][ ] 限速： 限速 f 0 l 速度 ‐f?0?‐l?速度 全速： ‐f?1?忽略速度 并行压缩：‐p?1?‐n?CPU数量 (不指定默认CPU核数的 ) (不指定默认CPU核数的一) gzip压缩： ‐p?0?忽略CPU数量
- 12. 推荐配置 ? 全速备份 (不提供服务的备库 空间大) 全速备份： (不提供服务的备库、空间大) – bash?xtrabackup_hdfs.sh?‐f?1?‐p?1?[‐n?8] ? 限速备份：(提供服务的备库) – bash?xtrabackup_hdfs.sh?‐f?0?‐l?6/10m?‐p?1???? / – bash?xtrabackup_hdfs.sh?‐f?0?‐l?20m?‐p?1??(若提供dump) ? 单核压缩：(现有方式) – bash xtrabackup hdfs sh f 0 l 6m p 0 bash?xtrabackup_hdfs.sh?‐f?0?‐l?6m?‐p?0 – bash?xtrabackup_hdfs.sh?‐f?1?‐p?0?(效率不高，瓶颈在gz)
- 13. 限速压缩后引入的问题 ? 限速6M/10M之后 /usr/bin/innobackupex‐1.5.1??‐‐stream=tar $DIR?|?./pv ‐q? ‐L6m[1]| gzip(pbzip2 –p$CPUNUM ) [2] > HDFS [ ]|?gzip(pbzip2? p$CPUNUM [ ] >?HDFS ? 问题： – [1]导致6m的传输 – [2]压缩之后每秒钟大概1m(假设压缩比为1/6)； [ ] – HDFS默认配置是64M之后开始写入HDFS； – 所以，有可能在64/1=64秒时间之内client和HDFS无 所以，有可能在64/1 64秒时间之内client和HDFS无 交互；而默认6秒钟的timeout设置。 public?static?int READ_TIMEOUT?=?60?*?1000; //其实是超过了这个值(dfs.socket.timeout) public?static?int READ_TIMEOUT_EXTENSION?=?3?*?1000; 备注：错误java.net.SocketTimeoutException:?63000?millis timeout?while?waiting?for?channel? to?be?ready?for?read.?
- 14. 备份恢复及快速恢复 ? 备份恢复 备份恢复： 脚本恢复 – 1.?脚本恢复 ? 要求mysql提前安装完毕(/u01/mysql) ? mysql restore hdfs.sh ‐h $host mysql_restore_hdfs.sh? h?$host – 2.?页面恢复(重做备库需求) ? Mysql的自动安装 ? 页面选择恢复(页面doing中、结合星际之门进行)
- 16. 基本的代码思路 ? 备份脚本 备份脚本： $innobackupex ‐‐user=root?‐‐tmpdir=$TMPDIR?‐‐ stream=tar?$TMPDIR?‐‐slave‐info? 2>$innobackupexLog |?$COMPRESS(压缩方法， 可以是gzip/pbzip2等其他)?|?java?hdfsbak/HdfsApi 可以是 i / b i 2等其他) | j hdf b k/Hdf A i write?/$DBHOST/$DATE2?${BAKFILE} ? J 类主要思路 Java类主要思路: – 类似于hadoop fs –cat/put命令的源代码，将数 据上传至HDFS；管理流的接受，并将数据写入 据上传至 管理流的接受 并将数据写入 hdfs。
- 17. 升级步骤 ? 升级组件 写入j 程序 – HDFS写入java程序 – pbzip2并行压缩程序 ? 升级步骤 1.?sudo yum?install?‐b?test?hdfs***? [2.]?sudo yum?install? b?test?pbzip2 [2 ] sudo yum install ‐b test pbzip2 备注： 1自动会安装2
- 18. 谢谢词