基于 EBS 卷快照备份恢复的性能介绍

本文介绍 EBS 备份恢复的性能、性能的影响因素以及性能测试结果。以下性能指标基于 AWS region us-west-2。

备份性能

本节介绍影响备份的性能、影响因素以及性能测试结果。

备份耗时

EBS 卷快照备份阶段包含创建备份任务、停止调度、停止 GC、获取备份时间 backupts 以及卷快照。详细信息，参考基于 EBS 卷快照的备份恢复功能架构。其中，耗时最多的阶段是创建卷快照。备份过程中卷的快照并行创建，一个备份完成时间取决于用时最长卷的快照创建完成时间。

备份耗时占比

备份性能数据

卷备份过程是完全并发进行的，因此整个备份的时间取决于耗时最久数据卷快照创建时间，与集群规模无关。该环节由 AWS EBS 服务来完成，当前 AWS 没有提供卷快照完成量化指标。根据测试，在 TiDB-Operator 推荐机型配置下，使用存储卷类型 GP3，配置 400 MiB/s 与 7000 IOPS，整个备份过程耗时大致如下：

备份影响

使用 GP3 卷进行备份时，经过测试集群影响小于 3%。如下图所示，10:25 分之后发起备份。

恢复性能

本节介绍恢复的性能、影响因素以及性能测试结果。恢复性能是可扩展的，整体恢复时间取决于恢复最慢的 TiKV 节点，与集群规模没有特别大的关系。

恢复耗时

EBS 卷快照恢复阶段包含以下阶段，详细信息，参考基于 EBS 卷快照的备份恢复功能架构。

1. 创建集群

   TiDB Operator 创建 recoveryMode 的待恢复集群，启动所有 PD 节点。

2. 卷恢复

   TiDB Operator 创建 BR 卷恢复子任务，BR 从卷快照中恢复出 TiKV 启动需要的数据卷。

3. 启动 TiKV

   TiDB Operator 挂载 TiKV 卷，启动 TiKV。

4. 数据恢复

   TiDB Operator 创建 TiKV 卷数据恢复子任务，BR 把所有 TiKV 数据卷恢复到一致性状态。

5. 启动 TiDB

   启动 TiDB，恢复完成。

恢复耗时占比

恢复性能数据

卷快照恢复的时间主要取决于启动 TiKV 和恢复数据的时间，启动 TiKV 和恢复数据都需要读取卷数据。通过快照恢复的卷，其中的数据会延迟加载，即刚刚恢复完成后，不能立刻达到最佳性能。这是因为，数据只有从 Amazon S3 下载完成并写入到恢复的卷之后，后续才能访问。

该延迟加载操作需要一些时间才能完成，并且可能会导致首次访问每个块时的 I/O 操作延迟大大提高。受 EBS 卷快照恢复卷延迟加载的影响，TiKV 启动和数据恢复这两个阶段耗时最长。根据测试，在 TiDB Operator 推荐 EC2 机型配置下使用 GP3 如下配置，整个恢复时间大致如下：