AWS Aurora使用集群端点时读写请求被重定向至只读实例的咨询

1. 写入请求被路由到只读实例是否属于预期行为？ #

不属于。Aurora MySQL的集群端点（Cluster Endpoint）核心作用是始终指向当前的主（读写）实例，所有写入请求都应通过该端点发送，正常情况下绝不会路由到只读实例。

出现该异常的常见原因：

• 客户端DNS缓存未刷新：主实例故障切换后，集群端点的DNS记录会更新，但客户端若缓存旧IP，会继续连接已降级为只读的原主实例。
• 连接池配置问题：连接池复用旧连接，或未定期重新解析DNS，导致请求发送到失效实例。
• 端点混淆：误将**读者端点（Reader Endpoint）**当作集群端点使用——读者端点会将请求分发到所有可读实例（包括只读实例，默认也包含主实例），写入请求发往此处会被只读实例拒绝。

2. 是否只能通过明确指定实例来解决问题？ #

不是，有更合理的方案：

• 修正端点使用逻辑：
  • 所有写入请求必须使用集群端点，确保请求始终路由到主实例。
  • 读取请求根据一致性需求选择：
    • 需要强一致性：使用集群端点读取主实例。
    • 可接受一定延迟：使用读者端点，可通过集群参数组设置aurora_reader_endpoint_exclude_main为1，排除主实例，避免读写混合。
• 解决DNS缓存问题：
  • 将客户端DNS缓存TTL调整为较短时间（如60秒），或在客户端/连接池配置中启用定期DNS刷新，确保及时获取集群端点的最新IP。
• 优化连接池配置：
  • 设置连接池的连接超时时间，定期回收旧连接，避免复用指向失效实例的连接。

3. 读取请求获取 stale data 的解决方案 #

出现stale data是因为只读实例的复制存在延迟，可通过以下方式解决：

• 强一致性读取：直接使用集群端点读取主实例，保证获取最新数据。
• 配置读取一致性参数：在会话或全局级别设置aurora_replica_read_consistency为SESSION或GLOBAL，强制只读实例返回已同步到主实例的数据（会增加读取延迟）。
• 监控并规避高延迟实例：通过监控工具追踪只读实例的复制延迟，配置读者端点的路由策略，避免将请求分发到延迟过高的实例。

内容的提问来源于stack exchange，提问作者Ujjwal Mishra