从删库到不跑路
—之备份平台
01 从删库跑路开始说起
l 2017年2月,著名的代码资源托管网站 Gitlab.com 的一位工程师在维护数据时不慎删除约 300GB 的数据, 五重备份机制失效后在 YouTube 直播抢救。
l 2018年9月,顺丰科技数据中心的一位高级工程师误删生产数据库,导致某项服务无法使用并持续 590 分钟。
删库总是个沉重的话题, 发生原因也总是出奇一致,回溯删库原因一般可从以下三点出发:
a、变更流程中是否有有效的审批授权?
b、是否进行了合理而充分的测试?
c、是否遵循了不相容职责分离的原则?
怎么删库不跑路,备份及验证备份有效性很重要!
本篇主要讲数据库备份平台在三七互娱是如何做的。
02 备份系统的进化之路
l 早期备份其实就是crontab + shell脚本,备份失败发个邮件,简单粗暴,在实例数不多(100内)的情况下也能很好工作。
l 随着数据库实例越来越多, 这种模式逐渐暴露其弊端:
a、备份计划不够灵活,什么时候备份、备份频率定制比较困难
b、每上线一个IDC就需要部署一套crontab + shell, 管理困难
c、由于缺少集中平台管理界面,上市公司IT内审审计师过来总不能提供程序运行日志证明备份流程是执行到位的,企业信息系统安全难以自证
l 经过内部多次迭代,当前备份平台如下图:
l 备份计划配置界面如下, 同时我们实现了备份校验功能用于检查备份是否可用。目前备份统一使用 xtrabackup Streaming backups(全量流备份)。
l 至于增量备份请结合自己的业务评估是否需要引入,xtrabackup Incremental backups(增量备份) 方案实施比较复杂收益较低, 需要做 Point-in-time recovery support(基于时间点恢复) 可以结合binlog进行恢复。
03 备份系统整体架构
l 我们的业务特点是 IDC 跟云厂商(腾讯云、阿里云、AWS均有自建实例)共存,同时 时区 跨幅大,国内、东南亚、欧美均有业务
l 因上市公司审计要求,备份使用xtrabackup加密然后压缩存储,并且保留多个近期版本, 甚至需要永久保留所有备份版本,单地区备份所需空间超过100TB+, 为了解决备份空间问题, 我们在IDC搭建了HDFS文件系统、同时对接了AWS S3服务、阿里云OSS服务、腾讯云CAS服务
l 备份架构图如下:
3.1 备份下发流程
我们引入分布式任务队列Celery, Celery本质为生产者消费者模型, 用于解决 并发备份、动态扩容、异常回调等问题。
Celery Broker使用的RabbitMQ队列,Broker早期使用Redis会导致备份任务假死,踩了比较多的坑,改为RabbitMQ后很稳定。
/下发流程图如下:
3.2 备份Rotate流程
备份版本需要定期Rotate(即备份清理规则), 同时删除备份/备份路径变更需要通知OPS平台保证备份版本的状态是 "失效" 的, 这对后面实现 自动化的备份恢复校验 极其重要。
/Rotate流程图如下:
3.3自动化的备份恢复校验
通常备份有了, 但备份的有效性容易被忽视, 现实是Gitlab的五重备份也可能失效,于是乎我们又做了备份的定时恢复用于确保备份是有效的
从下图我们也能发现,全量恢复一个大实例有时候需要很长的时间,这里留个彩蛋,下篇我们会介绍更快的一种数据恢复方法。
04 小结
l 本篇介绍了数据库备份平台在三七互娱从工具到平台的迭代, 实际整个过程遇到很多问题也都一一解决,如备份流量超过千兆网卡承载时我们做了并发控制及错峰、备份容量遇到瓶颈时我们引入了分布式存储系统、应对MySQL数据库版本升级我们做了多版本支持, 同时备份平台也接入了更多组件的备份,如Redis/TTserver等NoSQL组件。
l 在备份平台的投入大部分情况下都看不到收益, 但为了应对那极小的删库概率,做好备份才能安枕无忧。敬畏生产,敬畏墨菲。
—The End—
以下技术文章,你可能也感兴趣:
排版:川芮