从最近的mysql故障谈海量数据库的备份系统设计

前言

最近炉石传说，gitlab数据库故障在业界传得沸沸扬扬，造成了无法挽回的数据丢失。对于越是大规模的数据库系统, 如何设计一个可靠的备份系统越是至关重要。本文主要以UCloud云数据库产品UDB的备份系统为例，阐述下在海量数据库情况下，备份系统该如何设计，如何确保备份的安全性，如何避免数据库从删库到跑路的窘境。

大型备份系统设计

大型备份系统设计考虑因素

如果一个DBA只需要维护一套数据库，那么备份和恢复无疑是较为简单的，通常只需要知道怎么使用备份工具进行备份和还原就搞定了。而在大公司中，数据库实例数量往往都是成百上千个，公有云服务商甚至需要维护着十万级别的实例数量，简单粗糙的备份系统就显得有些low了，设计一个完善的备份系统尤其关键。一个大体量的备份系统需要考虑好这几个方面:

l  如何根据业务类型选择备份方式，逻辑备份or物理备份?

l  如何灵活地设置备份策略，比如备份周期选择，是否在从库备份，备份上传到何处

l  如何确认备份是否成功，哪一步骤出了问题

l  如何确认成功的备份实际可有效还原

l  需要恢复时，如何做到一键恢复到指定时间点

备份系统设计架构

下面以UCloud UDB为例，讲述备份系统的一般设计架构，来解决上述问题和需求。

UDB备份系统架构设计如下图所示：

其中Access模块是业务接入模块。它处理所有来自API或控制台的备份相关请求，并将请求转发到对应的实际物理机去执行备份或者恢复操作；备份机集群实际