重要
你正在查看 TiDB Operator 工具的较旧主版本 (TiDB Operator v1.5) 的文档。TiDB Operator release-1.6 是 TiDB Operator 的最新稳定主版本，如无特殊需求，建议使用该版本。点击此处查看 TiDB Operator release-1.6 文档。
基于 EBS 卷快照备份恢复的性能介绍
本文介绍 EBS 备份恢复的性能、性能的影响因素以及性能测试结果。以下性能指标基于 AWS region us-west-2。
备份性能
本节介绍影响备份的性能、影响因素以及性能测试结果。
备份耗时
EBS 卷快照备份阶段包含创建备份任务、停止调度、停止 GC、获取备份时间 backupts 以及卷快照。详细信息，参考基于 EBS 卷快照的备份恢复功能架构。其中，耗时最多的阶段是创建卷快照。备份过程中卷的快照并行创建，一个备份完成时间取决于用时最长卷的快照创建完成时间。
备份耗时占比
| 备份阶段 | 备份耗时 | 备份总占比 | 备注 |
|---|
| 创建卷快照 | 16 分钟 (50 GB) | 99% | AWS EBS 卷快照创建完成的时间 |
| 其他 | 1 秒 | 1% | 包含停止调度、停止 GC 及获取备份时间 backupts 的时间 |
备份性能数据
卷备份过程是完全并发进行的，因此整个备份的时间取决于耗时最久数据卷快照创建时间，与集群规模无关。该环节由 AWS EBS 服务来完成，当前 AWS 没有提供卷快照完成量化指标。根据测试，在 TiDB-Operator 推荐机型配置下，使用存储卷类型 GP3，配置 400 MiB/s 与 7000 IOPS，整个备份过程耗时大致如下：
| 卷数据 | 卷总容量 | 卷配置 | 大概备份时间 |
|---|
| 50 GB | 500 GB | 7000IOPS/400 MiB/s | 20 分钟 |
| 100 GB | 500 GB | 7000IOPS/400 MiB/s | 50 分钟 |
| 200 GB | 500 GB | 7000IOPS/400 MiB/s | 100 分钟 |
| 500 GB | 1024 GB | 7000IOPS/400 MiB/s | 150 分钟 |
| 1024 GB | 3500 GB | 7000IOPS/400 MiB/s | 350 分钟 |
注意
上述性能数据是全量数据备份，即第一次备份。
因为 AWS 卷快照是以卷为单位，除第一个卷快照是全量，后续卷快照都是以增量的形式进行。每日备份一般情况下可以在 1 小时完成，如遇特殊情况，可缩短备份频率，如 12 小时或者 8 小时备份一次。
备份影响
使用 GP3 卷进行备份时，经过测试集群影响小于 3%。如下图所示，10:25 分之后发起备份。
恢复性能
本节介绍恢复的性能、影响因素以及性能测试结果。恢复性能是可扩展的，整体恢复时间取决于恢复最慢的 TiKV 节点，与集群规模没有特别大的关系。
恢复耗时
EBS 卷快照恢复阶段包含以下阶段，详细信息，参考基于 EBS 卷快照的备份恢复功能架构。
创建集群
TiDB Operator 创建 recoveryMode 的待恢复集群，启动所有 PD 节点。
卷恢复
TiDB Operator 创建 BR 卷恢复子任务，BR 从卷快照中恢复出 TiKV 启动需要的数据卷。
启动 TiKV
TiDB Operator 挂载 TiKV 卷，启动 TiKV。
数据恢复
TiDB Operator 创建 TiKV 卷数据恢复子任务，BR 把所有 TiKV 数据卷恢复到一致性状态。
启动 TiDB
启动 TiDB，恢复完成。
恢复耗时占比
| 恢复阶段 | 恢复大致耗时 | 恢复总占比 | 备注 |
|---|
| 创建集群 | 30 秒 | 2% | 包含下载 docker image 和启动 PD 的时间 |
| 卷恢复 | 20 秒 | 1% | 包含启动 BR pod 和卷恢复的时间 |
| 启动 TiKV | 10～16 分钟 | 42% | 包含 TiKV 启动时，启动 RocksDB 及读取所有 Region 元信息的时间 |
| 数据恢复阶段 | 2～20 分钟 | 52% | 包含恢复 raft 共识层数据以及删除 MVCC 数据的时间 |
| 启动 TiDB | 1 分钟 | 3% | 包含下载 docker image 和启动 TiDB 的时间 |
注意
因为卷快照具有崩溃一致性 (Crash Consistency) 的特点，EBS 卷快照恢复时，启动 TiKV 和恢复数据需要初始化数据，即从 Amazon S3 下载数据。经测试，该阶段耗时在 30 分钟以内，如使用高性能盘恢复来提升 IOPS 和带宽，额外耗时可缩短到 5 分钟内。使用高性能盘恢复请参考恢复时间太长（大于 2 小时）。
恢复性能数据
卷快照恢复的时间主要取决于启动 TiKV 和恢复数据的时间，启动 TiKV 和恢复数据都需要读取卷数据。通过快照恢复的卷，其中的数据会延迟加载，即刚刚恢复完成后，不能立刻达到最佳性能。这是因为，数据只有从 Amazon S3 下载完成并写入到恢复的卷之后，后续才能访问。
该延迟加载操作需要一些时间才能完成，并且可能会导致首次访问每个块时的 I/O 操作延迟大大提高。受 EBS 卷快照恢复卷延迟加载的影响，TiKV 启动和数据恢复这两个阶段耗时最长。根据测试，在 TiDB Operator 推荐 EC2 机型配置下使用 GP3 如下配置，整个恢复时间大致如下：
| 卷数据 | 卷总容量 | 卷配置 | 恢复大致耗时 |
|---|
| 50 GB | 500 GB | 7000IOPS/400 MiB/s | 16 分钟 |
| 100 GB | 500 GB | 7000IOPS/400 MiB/s | 18 分钟 |
| 200 GB | 500 GB | 7000IOPS/400 MiB/s | 21 分钟 |
| 500 GB | 1024 GB | 7000IOPS/400 MiB/s | 25 分钟 |
| 1024 GB | 3500 GB | 7000IOPS/400 MiB/s | 34 分钟 |
注意
数据恢复性能曲线并非完全线性单调递增，这是因为，卷数据是 TiKV 实际使用的用户数据，而启动 TiKV 和恢复数据时，可能需要加载和扫描不同的卷数据块，另外，AWS 卷数据块下载网络速度等因素对恢复性能也会产生影响。
