利用分片加速备份

引言

扩展数据库带来了许多挑战，其中之一就是备份。当你的数据库较小时，备份可以快速且频繁地完成。然而，随着数据库增长到以 TB 为单位的规模，备份变得越来越棘手。单次备份可能需要数小时甚至数天，具体时间取决于硬件和网络条件。在 PlanetScale，我们通过分片技术使备份大规模数据库变得既简单又快速。
使用 PlanetScale 数据库时，通常无需过多考虑备份和恢复过程的细节，因为我们为你处理了所有复杂部分。然而，我们知道许多人对我们备份过程的“幕后细节”感兴趣，以及分片如何显著加快备份时间。在本文中，我们将深入探讨这一主题。

PlanetScale 的备份机制

所有 PlanetScale 数据库都由 Vitess 驱动，Vitess 作为代理、分片和协调层，位于你的应用程序与 MySQL 实例之间。默认情况下，一个未分片的 Scaler Pro 数据库架构如下：
![未分片的架构示意图](架构示意图)
默认架构中，所有查询流量都由主 MySQL 实例处理。副本主要用于高可用性，同时也可用于处理读取查询（如果有需要）。
默认配置是每 12 小时进行一次备份。当然备份时间是可配置的，你也可以手动触发数据库备份。备份可以通过 PlanetScale 应用中的备份页面查看和调度：
![PlanetScale 备份历史](备份历史截图)
PlanetScale 的内部 API 会定期检查是否存在待处理的计划备份，并在必要时启动备份任务。
如果你正在管理自己的独立 Vitess 集群，可以配置备份引擎和存储服务来满足特定需求。在 PlanetScale 内部，我们使用内置备份引擎来完成任务，因为它非常适合我们的备份程序。备份文件会存储在 Amazon S3 或 Google GCS 中，具体取决于数据库集群所在的云环境。

PlanetScale 平台上备份的工作流程

对于每次备份，以下步骤会在 PlanetScale 平台上执行：

内部 API 发起备份请求，包括备份生产分支和所有开发分支的数据。
该请求被转发给 PlanetScale 的 Singularity 服务，这是我们用于管理基础设施的内部服务。Singularity 会在主库和副本所在的同一集群中启动一台新的计算实例，用于执行 VTBackup。
如果存在之前的备份（通常情况都是如此），那么该备份会恢复到专用 VTBackup 实例中。备份文件从 Amazon S3 或 Google GCS 解密并获取。
完成恢复后，VTBackup 启动一个新的 MySQL 实例，该实例基于刚从 S3/GCS 取回的备份运行。
VTBackup 指示新的 MySQL 实例连接到主 VTGate，并请求一个时间点检查。这会将自上次备份到当前检查点之间的所有更改复制过来（通常仅占总数据库大小的一小部分）。
MySQL 实例完成数据同步后便停止运行。
启动正常的 Vitess 备份工作流，将新的完整备份存储到 Amazon S3 或 Google GCS 中。

对于分片数据库，第 2 至第 7 步可以并行完成。这种并行化允许即使对于极大规模数据库，备份也能快速完成。接下来我们将通过实际案例探讨这一过程。

选择主库 vs 副本进行数据同步

在第 5 步，我们选择从主库获取最新更改，而不是从副本获取。为什么？
从主库获取数据可以保证信息是最最新的。从副本获取数据则避免给主服务器增加额外的计算、I/O 和带宽负担。
![从主库 vs 副本复制](复制架构图)
然而，在我们的场景中，主库已经正在为其他两个节点进行复制。此外，除首次备份外，主库无需向备份服务器发送整个数据库内容，只需发送自上次备份以来的更改数据（通常只有之前 12 或 24 小时的数据变化）。因此，从性能角度来看，从主库提供数据通常是可接受的。如果性能影响变得显著，可以将备份调度在流量较低的时段进行。

未分片数据库的备份

让我们观察一个未分片数据库的备份情况。这个数据库为 161 GB，在未分片环境下运行，并拥有一个主库和两个副本。每个主库和副本都配置了 8 个 vCPU 和 32 GB 内存。以下是数据库最近的一次备份截图：
![未分片备份时间截图](备份截图)
备份耗时 30 分钟 40 秒。回顾备份的主要流程：

从存储取回旧备份；
数据同步；
将新备份发送到存储。

我们可以通过以下公式估算平均网络吞吐量：

(previous_backup_size + new_backup_size) / duration

根据计算，此备份的平均网络吞吐量为 176 MB/s。对于此大小的数据库来说，这是一个合理的传输速度。

分片数据库的备份

现在来看看一个更大的 20 TB 分片数据库的备份情况。这个数据库为之前 161 GB 数据库的 124 倍大小。基于上述计算公式，我们可能预测备份时间为 63 小时。如此长时间显然是不能接受的原因之一包括：

较长时间窗口可能发生问题（例如网络条件恶化）。
如果我们需按照每 12 小时备份一次的策略，备份必须重叠或推迟。

以下是 PlanetScale 平台上一个真实运行的 20 TB 数据库的备份截图：
![分片备份时间截图](备份截图)
而实际耗时仅为 1 小时 39 分钟 4 秒。这得益于分片技术。
该数据库运行在 32 个分片上，每个分片的资源配置与之前的 161 GB 数据库类似。分片架构下，数据分布在多个实例中。如果分布均匀，那么每个分片约包含 625 GB 的数据，每个分片可以并行备份。
利用公式计算，这次备份的整体吞吐量大约为 **6.7 GB/s**，而单个分片的传输速度约为 **210 MB/s**。通过并行化，我们能迅速完成备份任务。