本文共 1634 字，大约阅读时间需要 5 分钟。
TiDB + BR：高效的分布式数据库备份与恢复解决方案
在数据安全和业务连续性方面，数据库的备份与恢复是基础设施的重要组成部分。作为一款分布式数据库，TiDB 在面对超大规模数据集群时，备份与恢复的效率尤为关键。经过测试，TiDB 集群的10T数据备份恢复速度可达GB/s级别，这得益于我们研发的高效备份恢复工具BR（Backup and Restore That Scales）。
如果你的业务产生海量数据，并对数据安全与备份恢复效率有极高要求，那么TiDB + BR将是你的不二之选。这将帮助你避免“删库跑路”等突发事件，并确保快速恢复，保障业务的稳定运行。
一个10T集群的测试
让我们通过实际数据展示BR的强大能力！我们使用BR备份了一个10T数据量的超大集群：
- 备份速度：548MB/s × TiKV节点数
- 恢复速度：150MB/s × TiKV节点数
为了更直观地展示备份恢复的过程，我们为大家呈现了真实的备份恢复截图：
备份过程
图片说明：
- 绿色线为整体备份速度，其他线条为各TiKV节点的备份速度。
- 11:15和11:28期间备份索引数据，速度有所下降，这是由于索引数据内容较短导致。
恢复过程
图片说明：
- 绿色线为整体恢复速度，其他线条为各TiKV节点的恢复速度。
- 恢复期间出现的波动是由于将恢复任务分拆为多个小任务并串行执行（潜在优化空间）。
- 1:00和1:15期间恢复速度下降，同样由于索引内容较短。
分布式数据库备份恢复的难点
备份恢复一直是超大TiDB集群的难题：TiDB存储层的分布式架构缺乏一致的物理快照概念。
尽管TiDB兼容MySQL协议，我们曾尝试使用mydumper/myloader作为备份恢复工具，但在面对超大规模TiDB集群时，这些工具表现不佳，无法充分利用集群资源，且存在TiDB可能发生OOM的风险。
我们曾开发过类似myloader的工具loader，测试显示恢复1TB数据需要19小时，这一速度难以满足高效恢复的需求，主要原因在于恢复流程依赖SQL，增加了不必要的计算，导致资源利用率低下。
总之，mydumper和loader虽能使用，但未能完美契合TiDB的需求。因此，我们决定开发BR工具。
BR设计与实现
BR的核心优势在于支持水平扩展：
- BR直接从TiKV存储层入手，采用类似Coprocessor的方式下推备份与恢复任务。例如，一个备份任务可能跨越多个Region，BR只需向每个TiKV发送请求，各节点自行处理数据备份。
- BR将CPU和IO负载均匀分散到各TiKV节点，轻松处理上百个节点的TiDB集群。
强一致性
BR支持TiDB提供的Snapshot Isolation一致性：
- 数据分布在多个TiKV节点，BR仅需获取TiDB事务的Timestamp，向所有TiKV节点发送该Timestamp，备份的数据即可满足一致性要求。
- 这里的数据不仅包含用户数据，还包括TiDB的元数据（如表结构），确保备份与恢复一致性。
体验BR
如果你正在使用TiDB集群，数据量达到TB级别，且急需快速备份恢复，不妨尝试BR工具。我们已发布了相关文档，供开发者参考：
- BR使用手册
- BR备份与恢复场景示例
BR目前处于Beta阶段，欢迎在使用过程中发现问题反馈至：
更多令人期待的新功能
BR正在不断开发完善中，近期的活动中，TiDB社区贡献了许多新功能：
- 支持RawKV TiKV集群：感谢一点资讯的社区小伙伴xinhua5的贡献。
- 增量备份：解决了全量备份存储空间占用大问题，也支持快速恢复。
- 云存储支持：现已支持AWS S3，计划推出Google Cloud Storage支持。
- 在线恢复：将支持在线恢复，特别适合OLAP场景的数据导入需求。
以上新功能仍在开发中，欢迎社区贡献新点子！我们将优先考虑用户需求，欢迎参与AskTUG的“备份恢复功能优先级投票”（投票开放一周），根据用户呼声调整开发优先级。
发表评论
最新留言
关于作者
