使用 Amazon Aurora Global Database 实现多区域架构 - DR 与全球读取的设计
通过存储层的物理复制实现不足 1 秒的 RPO。介绍计划内 / 计划外故障转移的步骤，以及利用 Write Forwarding 实现全球读取的方法。
Global Database 的工作原理
Aurora Global Database 是将主区域的数据复制到辅助区域的功能，辅助区域最多可设置 10 个。普通的跨区域只读副本使用基于 binlog 的逻辑复制，而 Global Database 使用存储层的物理复制。因此，复制延迟通常控制在不足 1 秒，对主实例性能的影响也很小。MySQL 兼容版和 PostgreSQL 兼容版均可使用，需要 db.r6g.large 以上的实例类。
DR 设计与故障转移
按计划进行区域切换的 switchover（以前称为 managed planned failover）用于维护或区域迁移时，在不丢失数据的情况下将辅助区域提升为主区域。由于先停止主区域的写入、等待复制完成后再切换，因此不会丢失数据。主区域发生故障时使用的故障转移通常在 1 分钟以内完成。可能会丢失相当于复制延迟的数据，但 RPO 通常不足 1 秒。如果应用程序连接到 Aurora Global Database 的写入终端节点，那么在切换或故障转移之后，该终端节点会指向当时的主区域。将 Route 53 的运行状况检查与故障转移路由结合使用，可以通过 DNS 自动切换连接目标。
全球读取的应用
辅助区域的只读副本可以处理读取查询，为分布在全球的用户提供低延迟的读取。将东京区域设为主区域、弗吉尼亚区域设为辅助区域后，美国的用户从弗吉尼亚的只读副本读取，日本的用户从东京的主区域读取。由于写入只由主区域处理，离主区域较远的用户的写入会花费与距离相应的时间。启用写入转发（Write Forwarding）后，辅助区域一侧会将写入请求发送到主区域，因此可以减少应用程序一侧按区域分配请求的处理。
Global Database 的费用
Global Database 的额外费用产生于复制数据的写入 I/O。辅助区域的复制 I/O 每 100 万次请求约 0.20 美元（截至 2026 年 8 月）。辅助区域的实例和存储费用与普通 Aurora 相同，只读副本的实例类不必与主实例相同，可以根据读取负载选择较小的实例。如果仅用于 DR 而不使用只读副本，可以用最小实例待机，在故障转移时再纵向扩展，从而控制成本。Global Database 的复制不收取区域间数据传输费用。
RPO / RTO 与切换的实际
在灾难恢复中，能容忍多少数据丢失（RPO）以及需要多快恢复（RTO）是重要的指标。Aurora Global Database 通过专用的基础设施将主区域的变更复制到其他区域，因此能将区域故障时丢失的数据控制在较小范围内。它同时支持计划内的区域切换和紧急情况下的提升，可以在短时间内将辅助区域提升为可写入的主区域。事先准备好切换步骤并定期演练，就能提前确认恢复所需的时间。
用例与设计上的考虑
Aurora Global Database 是面向在世界各地都有用户的应用程序的功能。让用户从各区域的辅助数据库读取，就能从离用户较近的位置以低延迟返回数据。另一方面，由于写入集中在主区域，设计时考虑到来自远程地区的写入会产生延迟。此外，由于区域间的复制存在少许延迟，以在辅助区域读取的数据可能会短暂地是旧数据为前提。需要最新数据的处理发往主区域，其他读取则分配到各区域的辅助数据库。
总结
Aurora Global Database 是在存储层将数据复制到多个区域的功能，可用于从区域故障中恢复以及在离用户较近的区域进行读取。切换用于在不丢失数据的情况下切换区域，故障转移用于从主区域的故障中恢复。它可用于将写入集中在 1 个区域、将读取分散到各区域的应用程序的数据层。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。