Amazon Aurora RDS（Postgres）多AZ部署复制的同步/异步性及延迟疑问

核心机制澄清：共享存储 vs 节点间复制 #

Amazon Aurora的核心特性是集群卷（Cluster Volume）——这是一个跨AZ同步复制的分布式存储层，至少在3个不同AZ中保存数据副本。所有集群节点（主写入节点、只读副本）都直接挂载这个共享存储，因此：

• 不存在传统RDS中“主节点将数据复制到副本节点”的过程，这就是部分文档提到“无需复制数据至副本节点”的原因——副本不需要单独存储完整数据集，直接从共享存储读取。

只读副本的延迟与复制模式 #

虽然共享存储是跨AZ同步的，但只读副本的数据可见性存在极小延迟，原因是：

1. 主节点执行写入操作时，会先将日志写入集群卷的共享日志层，完成后就向客户端返回写入成功；
2. 只读副本需要从共享日志层读取这些日志，然后在自己的内存缓存中应用（更新本地的查询缓存），这个过程是异步的，不需要等待主节点确认。

• 正常情况下延迟通常小于100毫秒，高写入负载下，日志堆积会导致延迟增加，这与详细文档的描述一致。

关于你的猜测：AZ间同步、副本间异步？ #

这个猜测不准确，原因如下：

• 集群卷本身是跨AZ同步复制的，主节点的写入会实时同步到多个AZ的存储副本中，这是底层存储层面的同步，和节点无关；
• 不管主节点和只读副本是否在同一个AZ，副本的延迟都来自“读取共享日志+本地缓存应用”的异步过程，而非AZ间的复制延迟。即使副本和主节点在同一AZ，这个微小延迟依然存在。

文档“矛盾”的本质 #

两个文档描述的是不同层面的内容，不存在矛盾：

• 前者强调的是存储层架构：副本无需从主节点复制数据，直接共享集群卷；
• 后者强调的是节点数据可见性：副本需要异步读取共享日志更新本地状态，因此存在极小延迟。

内容的提问来源于stack exchange，提问作者Lukáš Křečan