PlanetScale vs Amazon Aurora 复制机制
Amazon Aurora 是 Amazon 为简化扩展 RDS 数据库的流程而推出的解决方案，它支持通过实现只读副本来分担主读写节点的一部分工作负载。而 PlanetScale 也允许用户执行类似操作，但 Amazon 数据库的复制策略与传统的 MySQL 复制机制存在显著不同。
在本文中，我们将介绍 PlanetScale 的复制机制与 Aurora 的实现方式，同时涵盖两者之间的一些相似点和差异。
MySQL 复制如何工作？
在对比 PlanetScale 和 Aurora 的复制策略之前，有必要了解一下 MySQL 的基本复制原理。
MySQL 的复制机制是指将数据从一个 MySQL 服务器复制到另一个服务器。由多个服务器组成的复制环境通常被称为集群。在大多数集群中，其中一个服务器充当读写服务器，称为“源”（source）。集群中的其他服务器称为副本（replicas），这些副本通常用于只读任务，例如备份或分析处理等。
每个源服务器会将其处理的所有事务记录到一个文件中，该文件被称为二进制日志（binary log，简称 binlog）。
当数据写入源服务器的 binlog 时，每个副本会有一个进程读取这些日志条目，并将它们回放（replay）。回放完成后，每个副本会逐渐被更新至源服务器的状态，从而拥有与源服务器相同的数据。根据具体的复制模式，数据从源到副本的更新时常会有一定延迟，我们称之为“复制延迟”（replication lag）。
PlanetScale 数据库集群遵循传统的复制模式，这意味着每个 MySQL 节点都保存了它正常运行所需的数据副本。
MySQL 复制示意图
| 步骤 | 描述 |
| 1 | 需要写入数据的客户端连接到源 MySQL 服务器。 |
| 2 | 需要执行只读任务的客户端可连接到其中一个副本服务器。 |
| 3 | 当数据写入源服务器时，事务会被转发至副本服务器，副本会在本地应用这些事务。在半同步模式下，可以配置源服务器等待一个或多个副本的确认数据已写入后再响应客户端，以确保数据持久性。 |
想了解更多？我们还有一篇深入探讨 MySQL 复制的文章：
注： 更详细的内容参考我们的文章《What is MySQL replication and when should you use it?》。
Aurora 复制如何工作？
虽然 Aurora 使用二进制日志来实现外部复制，但 AWS 构建了一个封闭而专有的复制系统，用于 Aurora 集群内的复制，这与传统的 MySQL 复制配置有很大不同。
Aurora 不直接将重做日志（redo log entries）存放到挂载的存储卷中，而是将这些日志条目转发至与源计算节点位于同一可用区的专用 Aurora 存储设备。数据在存储设备上以 10 GiB 的段（segments）存储，并分布在目标区域的三个不同可用区中。在应用程序接收到计算节点的响应之前，Aurora 会确保至少六个存储段中的四个已成功复制以保证数据的持久性，即使某个数据中心发生故障。
由于数据在存储层面进行复制，只读计算节点可以随时在包含这些数据的可用区启动并读取节点数据。
对于已经被加载到内存中的页面，源节点会直接通知任何只读节点更新数据，这让只读节点能够及时调整，从而减少读取过时数据的风险，不过仍需要考虑复制延迟问题。
Aurora 复制示意图
| 步骤 | 描述 |
| 1 | 需要写入数据的客户端连接到读写计算节点。 |
| 2 | 需要执行只读任务的客户端连接到只读计算节点。 |
| 3 | 读写节点读取存储段并写入新数据。在写入操作完成后，读写节点会确保至少四个存储段成功确认写入，再响应客户端请求。 |
| 4 | 读写节点会通知只读节点数据发生变更，以便只读节点更新内存中的页面。 |
| 5 | 只读节点通过只读连接访问存储数据段。 |
| 6 | 存储段之间会相互复制数据。 |
PlanetScale 和 Aurora 复制的相似之处
1. 自动节点故障切换
每当在 PlanetScale 中创建新的数据库时，无论选择哪个订阅计划，我们都会自动启动一个 MySQL 集群，其中包括一个源节点和至少一个副本节点以支持生产环境数据库分支。这些节点是 Kubernetes 集群的一部分，用于确保数据库始终在线并健康运行。如果某个副本节点因某些原因离线，会自动创建一个新的副本节点。如果源节点离线，副本节点会被选举为新的源节点，并创建一个新的副本节点替换原来的。
Aurora 的处理方式与此类似，它也会自动替换崩溃或离线的节点。
2. 查询代理
PlanetScale 和 Aurora 均提供专门的查询代理服务，用以自动重定向访问节点的流量。这样能最大限度地减少客户端因节点故障而导致的停机时间，提高服务的透明性。
3. 存储自动扩容
Aurora 的存储设备会根据需要自动分配新的存储段。类似的，PlanetScale 通过监控数据库底层存储的容量来决定是否需要扩展存储卷或添加新的卷。两种平台都提供了防止数据库空间耗尽的解决方案。
4. 跨区域复制
在不同区域部署副本节点可以帮助加速该区域用户的数据访问。两种平台均支持创建只读区域（Aurora 中称为 Global Database）。创建只读区域时，副本节点会被部署到你选择的区域中，并配置异步复制机制，将主区域（生产数据库所在区域）与目标区域同步。
5. 在你的 AWS 账户中运行
尽管不完全与复制相关，但两种平台都允许你在自己的 AWS 账户中运行。PlanetScale 的企业版支持在你的账户中运行 PlanetScale 堆栈，同时支持使用他们提供的优雅用户界面。
PlanetScale 的优势
1. 基于成熟的开源软件
PlanetScale 基于 MySQL 兼容且水平扩展能力强的开源项目 Vitess 构建。Vitess 诞生于 2010 年，由 YouTube 的工程团队开发，用于解决当时因快速增长产生的扩展问题。这比 AWS Aurora 的推出早了四年，如今被一些全球知名公司使用，比如 Slack、GitHub 和 Pinterest。
由于它是开源的，你可以自行安装和测试它。关于 Vitess 的更多信息，可以访问官网的文档门户或浏览 PlanetScale 的博客来了解其使用方式。
2. 版本升级
由于我们使用传统的 MySQL 复制机制，支持滚动升级 MySQL 版本，而不会导致数据库的停机。这与 Aurora 的升级方式形成对比，Aurora 的升级过程需要通过维护时间窗口执行，这可能会导致数据库短暂停机。
3. 分片（Sharding）
分片是一种将大型数据集分割到多个 MySQL 服务器或集群上的技术，旨在均衡负载，从而以更低的成本获取更高的数据吞吐量。目前，Amazon Aurora 并不支持针对 MySQL 工作负载的分片功能，因此在遇到性能瓶颈时，你可能需要通过增加计算节点的成本来解决。
此外，PlanetScale 的查询代理服务 VTGate 专门为分片设计，能够智能地将查询路由到正确的 MySQL 服务器（或分片），即使查询需要同时访问多个分片上的数据。
4. 自动验证备份
备份对灾难恢复策略来说至关重要，因此我们非常重视备份机制。尽管 PlanetScale 和 Aurora 均支持自动备份，但 PlanetScale 的备份会在每次创建新的备份时自动验证。
与每次备份时创建新的数据库快照不同，我们会将最近一次数据库备份恢复到集群中的一台专用 MySQL 节点。完成恢复之后，我们使用 MySQL 的内置复制功能将最新的更改同步到这一节点，再创建新的备份。如果备份验证失败，会触发创建新的备份以替代无效备份。
通过这样的流程，你可以放心，PlanetScale 平台上的备份都是经过验证的，并始终可用用于恢复。
关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台
除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接
本文链接：http://folen.top/2025/09/13/planetscale-vs-amazon-aurora-2/
