数据库备份瓶颈及 S方案考虑数据库备份瓶颈及HDFS方案考虑

瓶颈 备份策略 并行 缩引——瓶颈、备份策略、并行压缩引入

穆公

2011.10.09

大纲大纲

有的备份策略 主要问题• 已有的备份策略及主要问题

• 问题分析问题分析

• 备份恢复及快速恢复

• HDFS的备份、调度使用介绍

• 总结总结

备份方法备份方法

• 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之后版本解决)

已有的备份策略及问题已有的备份策略及问题

定时备份• 定时备份– Crontab备份– 部署维护麻烦部署维护麻烦

• 全部限速备份部限 备份– 原因1：NAS问题– 原因2：备份时对业务读库影响非常大

• 备份介质：NASNAS不稳定导致机器hung死情况时有发生– NAS不稳定导致机器hung死情况时有发生

– NAS备份也有瓶颈

问题分析问题分析

备份时间分布• 备份时间分布– 备份时间测试源文件50G备份后8G

项目 备份时间(分) 写入速度(MB/s)

backup + tar + gz > HDFS 38 (37) 3.52

backup + tar + gz >/dev/null34

* HDFS的时间大概是4分钟

backup + tar &>/dev/null * gz压缩的时间backup + tar &>/dev/null5 (6) gz压缩的时间

占了85%

backup + tar + gz > DISK38

3.52 写入HDFS和DISK速度 样

– 说明：备份瓶颈在压缩上；写入HDFS和写入本地DISK速度一样

DISK速度一样

地DISK速度一样.– backup+tar:gzip:HDFS 约 1:6:1 (5:29:4)

问题分析 压缩的改进问题分析——压缩的改进

备份时间对比不同压缩方式的备份时间对比

• 备份时间对比

压缩时间缩短 25

30

35

40

压缩时间缩短

至少一半

5

10

15

20备份时间(分) 

0

5

backup + tar + gz > HDFS 

backup + tar + pbzip2 > HDFS 

backup + tar + gz >/dev/null 

backup + tar + pbzip2 >/dev/null 

项目(snsdc数据备份 50G)不限速

备份时间(分) 写入速度(MB/s) 节约时间分钟(原来29分钟)

backup + tar + gz > HDFS 38 (37) 3.52p g ( )

backup + tar + pbzip2 > HDFS 20 节约17分钟

backup + tar + gz >/dev/null 34 *

backup + tar + pbzip2 >/dev/null 18 节约16分钟

问题分析 压缩的改进(2)问题分析——压缩的改进(2)

备份时间分布• 备份时间分布

项目 耗时(分钟) 速度 对比 备注项目 耗时(分钟) 速度 对比 备注

-p 0 -f 0 -l 6m 270 1.21MB/s 现有方式 Gzip限速

-p 1 -f 0 -l 6m 258 1.03MB/s瓶颈不在压缩在读Di k Pbzip限速p . /缩在读Disk Pbzip限速

-p 1 -f 0 -l 20m 81 3.28MB/s 速度是3倍 Pbzip2 限速 20m

-p 1 -f 1 45 6.00MB/s 提升5倍 Pbzip2 全速 4核默认占一半CPU默认占一半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核)

并行压缩使用CPU评估并行压缩使用CPU评估

备份时间分布• 备份时间分布

速度(MB/s)

68.08

8.54

6

7

8

9

速度(MB/s)

3.28

6

2

3

4

5

6

速度(MB/s)

1.21 1.030

1

2

‐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)。

并行压缩使用CPU评估(2)并行压缩使用CPU评估(2)

备份时间分布• 备份时间分布

速度(MB/s)

68.08

8.54

6

7

8

9

速度(MB/s)

3.28

6

2

3

4

5

6

速度(MB/s)

1.21 1.030

1

2

‐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核之后，系统非常繁忙。8核IDLE几乎均为0，

故默认采用一半的核。 (8核只在紧急备份和恢复时使用)

并行压缩使用CPU评估(3)并行压缩使用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核-p 1 -n 10 -f 1 179 10.39MB/s 平行压缩

Pbzip2 全速 10核默认占8核

-p 1 -n 16 -f 1 155 11.94MB/s 全部核都用 Pbzip2 全速1 6核

备注：再次说明，引入并行压缩明显提高了整体的性能；但是不能占用全部CPU；提升月7倍左右。提升月7倍左右。

脚本的使用方式脚本的使用方式

b k hdf hxtrabackup_hdfs.sh [‐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数量

推荐配置推荐配置

全速备份 (不提供服务的备库 空间大)• 全速备份： (不提供服务的备库、空间大)– 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)

限速压缩后引入的问题限速压缩后引入的问题

限速6M/10M之后• 限速6M/10M之后/usr/bin/innobackupex‐1.5.1  ‐‐stream=tar $DIR | ./pv ‐q ‐L6m[1]| gzip(pbzip2 –p$CPUNUM ) [2] > HDFS‐L6m[ ]| gzip(pbzip2  p$CPUNUM ) [ ] > HDFS

• 问题：• 问题：– [1]导致6m的传输– [2]压缩之后每秒钟大概1m(假设压缩比为1/6)；[ ]压缩之后每秒钟大概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. 

备份恢复及快速恢复备份恢复及快速恢复

备份恢复• 备份恢复：

– 1. 脚本恢复脚本恢复

• 要求mysql提前安装完毕(/u01/mysql)• mysql restore hdfs.sh ‐h $hostmysql_restore_hdfs.sh  h $host

– 2. 页面恢复(重做备库需求)• Mysql的自动安装• Mysql的自动安装

• 页面选择恢复(页面doing中、结合星际之门进行)

HDFS的备份 调度使用介绍HDFS的备份、调度使用介绍

基本的代码思路基本的代码思路

备份脚本• 备份脚本：$innobackupex ‐‐user=root ‐‐tmpdir=$TMPDIR ‐‐stream=tar $TMPDIR ‐‐slave‐info 2>$innobackupexLog | $COMPRESS(压缩方法，可以是 i / b i 2等其他) | j hdf b k/Hdf A i可以是gzip/pbzip2等其他) | java hdfsbak/HdfsApiwrite /$DBHOST/$DATE2 ${BAKFILE}

J 类主要思路• Java类主要思路:– 类似于hadoop fs –cat/put命令的源代码，将数据上传至 管理流的接受 并将数据写入据上传至HDFS；管理流的接受，并将数据写入hdfs。

升级步骤升级步骤

升级组件• 升级组件

– HDFS写入java程序写入j 程序

– pbzip2并行压缩程序

• 升级步骤

1. sudo yum install ‐b test hdfs*** [2 ] sudo yum install ‐b test pbzip2[2.] sudo yum install  b test pbzip2备注： 1自动会安装2

谢谢~