使用 Amazon Aurora Global Database 实现多区域架构 - DR 与全球读取设计
通过存储层物理复制实现亚秒级 RPO。介绍计划内和非计划故障转移的步骤，以及利用 Write Forwarding 实现全球读取的方法。
Global Database 的工作原理
Aurora Global Database 是将主区域数据复制到最多 5 个辅助区域的功能。与使用基于 binlog 的逻辑复制的普通跨区域只读副本不同，Global Database 使用存储层的物理复制。因此复制延迟通常控制在 1 秒以内，对主节点性能的影响也降至最低。MySQL 兼容和 PostgreSQL 兼容版本均可使用，需要 db.r6g.large 及以上的实例类型。
DR 设计与故障转移
计划内故障转移（Planned Failover）用于维护或区域迁移，以零 RPO 将辅助区域提升为主区域。停止主节点写入，等待复制完成后再切换，因此不会丢失数据。非计划故障转移（Unplanned Failover）用于主区域故障时，通常在 1 分钟内完成。可能会丢失复制延迟量的数据，但 RPO 通常在 1 秒以内。故障转移后需要将应用连接切换到新的主节点。结合 Route 53 的健康检查和故障转移路由，可实现 DNS 级别的自动切换。
全球读取的应用
辅助区域的只读副本可处理读取查询，为全球分布的用户提供低延迟读取。将东京区域设为主区域、弗吉尼亚区域设为辅助区域时，美国用户从弗吉尼亚的只读副本读取，日本用户从东京的主节点读取。写入始终在主区域处理，因此写入密集型工作负载对靠近主区域的用户更有利。启用 Write Forwarding 功能后，发送到辅助区域的写入请求会自动转发到主节点，无需在应用端实现区域路由逻辑。 如需拓展数据库设计知识，也可参考Amazon 上的专业书籍。
Global Database 的定价
Global Database 的额外费用产生于复制数据的写入 I/O。辅助区域的复制 I/O 每 100 万次请求约 0.20 美元。辅助区域的实例和存储费用与普通 Aurora 相同，只读副本的实例类型无需与主节点相同，可根据读取负载选择较小的实例。仅用于 DR 而不使用只读副本时，可用最小实例待机，在故障转移时再扩容以控制成本。区域间数据传输费用不对 Global Database 的复制收费。
总结
Aurora Global Database 以亚秒级 RPO 实现多区域 DR，并降低全球读取工作负载的延迟。计划内故障转移提供零 RPO 的区域切换，非计划故障转移在 1 分钟内完成故障恢复。是全球应用数据层的最佳选择。