Mysql企业备份发展及实践

shoug.info 上海Oracle用户组
MySQL企业备份发展及实践
汪伟华

个人介绍
• 8年Oracle相关开发及数据库运维经验
(Oracle DB, MySQL, Oracle Apps)
• MySQL OCP
• dbDao MySQL讲师
• E-mail：biot.wang@parnassusdata.com

RDBMS -
会员数据、商品数据等等，特别是Mission Critical
的数据储存
曾经旧有的数据库环境。购买数据等等Critical
的数据被储存
关键任务数据，广泛用于内部服务

数据库架构的变化
随着时代演进，所使用的架构也在不断发生改变
– VCS 结构(Active-Standby on SAN)
 VCS ＋ Replication
 VCS ＋ Sharding
– IA Server + SSD
– Private Cloud

架构：VCS
• 缺点：
– 发生事故，火情容易蔓延
– 一旦某个数据库参数修改，
其他数据库需要进行影响确认
– 从开发到生产，不同环境需检
查确认，不同环境所用设备有
性能区别，且可调剂的余地小

架构：VCS + Replication
• Master-Slave Replication

架构：VCS + Sharding

架构：IA+SSD
• 压倒性的性能要求对DB架构产生了进一步的要求

架构：IA+SSD备份级联
• 3小时的工作，10分钟完成

其它困扰的问题
• 服务器配置可用性及内存，磁盘的未来的规划测算
• 性能及效率等使用率的测算
• 不断增长的节点带来的管理复杂化

架构：私有云IaaS
• 优点：
– 高速网络
– 多种存储
– 可管理性
– 在VM中建立MySQL
– 系统构筑简单
– HA切换速度快

Private Cloud的急速成长
• 管理的数据库数量成指数增长
– 现在团队中DBA共5人
– 每人负责的服务器仅仅算正式负责就有近600台
– 以每个月30台左右的节奏搭建数据库服务器

DC迁移项目
• 其中250个以上数据库花了9个月向Private Cloud搬迁
– 主要是在对已存在的DB中复制到新数据后，进行切换
• 使用Backup进行Restore的方法
– 从归档开始的restore
 花费时间
– 某些失败例子
 复制原服务器中，没有binlog
 由于binlog传送，降低网速
• 在新DC中建的服务器伴随着全球化
– 统一使用UTF8
 因此有些数据库不能使用复制方式

向Private Cloud迁移
• 使用基于命令行的迁移工具
– thread dump → import并行执行 → Change Master

MySQL数据库的企业运维Backup/Restore
• 时间点恢复（Point in time recovery）
– 每年约一次，进行实际故障操作训练
• 利用Replication设置，进行数据库的迁移恢复
• 定期检查
– 定期维护
 DBA 操作任务时间估计，并需要做操作确认
– 从应用工程师开始对历史数据的复查要求
 昨天发生错误，需要确认数据
– 使用生产数据进行应用测试
 整体测试
 负荷测试

主要备份方法

使用SAN Snapshot备份
DB Server1
D
B
DB Volume
Active
Backup NFS
NA
S
Compress
Backup Server
1. Mirror Volume 挂载到 Backup Server
2. DB Lock
mysql>FLUSH TABLE WITH READ LOCK
3. 对Active 进行Mirror 同步到最新
4. Active 和Mirror分离
5. DB Unlock
mysql>UNLOCK TABLES
6. 对Mirror Volume进行备份
7. 挂载Backup NFS
8. 创建备份区，将备份存放为tar归档
9. Mirror Volume卸载
DB Server2
D
B
DB Volume
Mirror

使用mylvmbackup备份
DB Server
D
B
OS Volume DB Volume Backup Volume Backup NFS
NA
S
Compress File
1. DB锁定
2. 获取backup当时的位置
mysql>SHOW SLAVE STATUS
mysql>SHOW MASTER STATUS
3. 进行snap shot
lvcreate -s -l 100%FREE --name=#{db_backup} #{Volname}
4. 释放DB锁定
mysql>UNLOCK TABLES
5. 安装snap shot区域
6. 对backup区域进行tar归档
7. 卸载snap shot 区域
8. 确认snapshot 区域的使用大小
lvdisplay #{LVName}
9．移除snapshot 区域
lvremove -f #{LVName}

SAN Snapshot/mylvmbackup恢复
Backup NFS
NA
S DB Server
D
B
Local disk 有空闲时
1. 挂载Backup NFS
2. 将tar 归档文件拷贝到本地
3. tar 归档文件的展开
Local disk 没有空闲时
1. 挂载Backup NFS
2. 将tar 归档文件在NAS上展开
Compress
File
DB
恢复的位置可以是共有环境或NFS
• tar 展开非常花费时间
• 特别是在定期维护之前时，会发生资源竞争
• 不仅占用磁盘，也包含内存使用
• 性能与真正运行环境相比要显著低下
20

Vmware Snapshot备份
1. 获取DB锁
2. 取得backup时位置
mysql>SHOW SLAVE STATUS
mysql>SHOW MASTER STATUS
3. 进行Vmware snapshot
4. 释放DB锁定
mysql>UNLOCK TABLES
5. 制成Backup文件
在VMWare使用环境中进行的软备份
• 进行全量/增量备份、不断去除过时的备份
• 可作为一种主流备份方式
• 备份时对生产环境的影响只有在取得snapshot时的几秒
VirtualAP
P
Vmware Management
Server
Backup NFS

Vmware Snapshot恢复
DB
基于Windows GUI 的操作
• 选择想要恢复的某个日期的对象
• 虚拟机中的设定获得全面继承
• 同时相应的网络设定等OS操作也一并恢复
DB
Traget DB Server
DB
Restored DB Server

Restore的改善
• Backup Restore 的过去及现在的比较
– SAN Snapshot / mylvmbackup
 Restore 针对的是共有环境或NFS
– tar 非常耗费时间
– 特别是到了定期维护之前，就会发生资源竞争
– 性能与实际运行环境相比，显著低下
– Vmware Snapshot
 Restore 针对的是 Private Cloud 环境
– 根据用途区分性能环境
– 实验负荷环境 => 与实际运行在同样的存储(FC/SSD)
– 用于数据确认 => 使用不追求性能的便宜储存
– 恢复中会稍微花点时间
– 展开的位置由存储决定
– SSD的话30分、FC的话约2小时

下一个备份平台的探索
• Vmware 的备份问题
– License费用
 日益增多的DB服务器造成成本的持续上升
• VMware 依赖
– 使用平台与时代演进同时发生改变
 VCS → IA + SSD → VMware → 下一个平台!
• 运用管理
– 随着服务器台数变多，GUI处理也会变多
• 恢复操作的危险性
– 会覆盖现存的正在运行的服务器中的备份
– 会把现有的IP地址直接应用到其他服务器中，导致某些危险的操作
 需要对VM以及网络有最低限度的理解。

新备份系统的讨论
• 必要条件
– 能作为平台提供
 数百台服务器的备份管理
 即便是应用工程师
– 【无论何时】，【操作简便】，可以进行恢复服务
– 可以进行中央管理
 Backup Script 在 DB服务器中本来就有
– 安装简便
– 可使用Job来控制多种应用
 可以进行历史管理
 计划作业排程添加/变更简单
• 候补工具
– Xtrabackup
– MySQL Enterprise Backup

构成图

Xtrabackup VS MySQL Enterprise Backup
• 验证方法
– 利用tpcc的基准测试进行验证
 观察各式各样的并行交易结果
 每执行三次就取一次中间值

测试使用的基本命令
测试场景命令
仅做全备份 Xtra innobackupex --defaults-file=${my.cnf Path} --user=${USER} --
password=${PASSWORD} ${Backup Path}
EB mysqlbackup --defaults-file=${my.cnf Path} --user=${USER} --
password=${PASSWORD} --backup-dir=${Backup Path} backup
全备 + 压缩 Xtra innobackupex --defaults-file=${my.cnf Path} --user=${USER} --
password=${PASSWORD} --compress ${Backup Path}
password=${PASSWORD} --compress --backup-dir=${Backup Path} backup
全备 + 压缩
+ 2个处理线程
Xtra innobackupex --defaults-file=${my.cnf Path} --user=${USER} --
password=${PASSWORD} --compress --parallel=2 ${Backup Path}
password=${PASSWORD} --compress --process-threads=2 --backup- dir=${Backup
Path} backup

结果

运行时间比较
• Enterprise Backup领先
– 无论在哪个模式中，EB都是更快完成
– 使用压缩可以使其更快完成！

备份大小
• 几乎相同

获取锁所需时间
• 几乎相同
– FLUSH TABLES WITH READ LOCK
– 支持事务的DB在不同的查询时机所需时间会有不同
– 对于MyISAM DB的锁定则需要一些时间

平均负载
• Enterprise Backup的负载也
在误差的范围内
– 无论哪个模式EB都比XB的
load要更低
• 使用Compress压缩负载更低

tpmC
• Xtrabackup 的压倒性胜利！？
– XB vs EB → 2.87倍
– Compress → 1.48倍

EB 的默认值
• 在EB中，process-threads的默认值是6
– 什么也不考虑的话，process-threads 就会被设定成6
http://dev.mysql.com/doc/mysql-enterprise-backup/3.11/en/backup-capacity-options.html
• Xtrabackup与EB的差距缩小了

比较总结
Xtrabackup Enterprise Backup
运行时间 △ ○
平均负载 △ ○
锁定时间大致相同
tpmC ○ △
备份大小大致相同
成本 ◎ ○
• 选择采用 Xtrabackup
– 从【无论在哪个备份平台】这个观点看，两者都能做到同样的事
– 备份对DB的性能影响很小
– 不需要去在意许可证

备份和恢复系统

innobackupex
命令项的使用判断
• 前提
– 对于有各种各样大小，具有
进行不同事务的DB
 使用通用命令，不特别
设置
 不能进行自动判断
 必须使用Compress项
• 命令项
– vCPU/2 最有效率的
– Compress Thread 数固定

恢复
• 解压缩（decompress）
– 备份时因为做了Compress所以需要这一步
– 是否对备份文件进行 tar.gz
 如果要做，什么时候做？
 做了tar.gz 的话为了进行增量备份，就不得不展开tar
 一周以后？
– 是使用copy-back 还是move-back?
• 恢复位置的服务器基本上都停止服务
– 尽最大可能使用内存以及 CPU
 Memory => mem * 0.75
 Parallel

恢复中必要的磁盘大小
Compressed Directory
Size
Decompressed Directory
size
Max Usage Size
23GB 69GB 78GB
• 必要的磁盘大小
– 考虑到最大的表，然会对磁盘进行规划
– 决定在哪里展开备份文件
 NFS 或本地

开发趋势…
• 恢复操作简易性
– 因为Vmware，比起进行恢复，安全性更高
– 在哪里都可以展开Service
 应用工程师也能进行 Restore
– 需要重新准备好Server
• 备份对正式运行中的应用的影响
– Vmware取得Snapshot只需要几秒
– Xtrabackup一直在进行备份处理
• 成本考虑
– 不超过Vmware 的成本，需要降低使用成本

S H O U G
Let’s Leverage Oracle Together
Using, Learning & Sharing

Mysql企业备份发展及实践

Mysql企业备份发展及实践

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Mysql企业备份发展及实践

Similar to Mysql企业备份发展及实践 (20)

More from maclean liu

More from maclean liu (20)

Mysql企业备份发展及实践