RDS 故障转移需要多少秒完成 - Multi-AZ 切换机制与 DNS 传播的内幕
将 RDS Multi-AZ 故障转移耗时 60-120 秒的过程分解为故障检测、DNS 记录更新和连接重建各阶段，解析缩短故障转移时间的实用技巧。
Multi-AZ 基本结构 - 主实例与备用实例
RDS Multi-AZ 部署中，主实例和备用实例放置在不同 AZ。主实例的写入通过同步复制复制到备用实例。同步复制是指主实例在提交事务前确认数据已传输到备用实例的方式。这确保了故障转移时不会发生数据丢失。备用实例不接受读取流量，专门用于故障转移。这与 Aurora 的只读副本（可处理读取流量）不同。Multi-AZ 的备用实例始终与主实例保持相同数据状态，是故障转移时的即时替代。
故障转移的 3 个阶段
RDS 故障转移由 3 个阶段构成。第 1 阶段是故障检测。RDS 监控系统检测到主实例故障需要数秒到数十秒。检测时间因故障类型而异，实例崩溃可在数秒内检测到，而网络部分故障（丢包率增加）则需要更长时间。第 2 阶段是 DNS 记录更新。检测到故障后，RDS 将数据库端点的 DNS 记录从主实例 IP 更新为备用实例 IP。Route 53 的 DNS TTL 设为 5 秒，但客户端的 DNS 缓存可能导致旧 IP 持续使用。第 3 阶段是连接重建。应用需要检测连接断开并重新建立到新主实例的连接。
60-120 秒的时间分解
AWS 官方文档称 RDS Multi-AZ 故障转移时间「通常为 60-120 秒」。分解这一时间：故障检测 5-30 秒，备用实例提升处理 10-30 秒，DNS 记录更新与传播 5-30 秒，应用连接重建 5-30 秒。时间有波动的原因是取决于故障类型和数据库状态。未提交事务的回滚、大量脏页的刷新等都会延长备用实例的提升时间。数据库规模越大、活跃事务越多，故障转移时间越长。
缩短故障转移时间的技巧
有几个实用技巧可最小化故障转移影响。第一，遵守 DNS 缓存 TTL。Java JVM 默认无限期缓存 DNS（networkaddress.cache.ttl=-1）。此设置下故障转移后仍会连接旧 IP。将 JVM DNS 缓存 TTL 设短（如 5 秒）可加速切换。第二，使用 RDS Proxy。Proxy 在故障转移时自动将连接路由到新主实例，应用无需重新建立连接，可将故障转移影响缩短到数秒。第三，减小数据库实例大小。实例越小，备用实例提升越快。第四，减少长事务。长时间运行的事务在故障转移时需要回滚，延长恢复时间。
故障转移测试 - 避免在生产环境中措手不及
故障转移不应在生产环境中首次经历。RDS 提供手动触发故障转移的功能。在控制台的「重启」选项中勾选「通过故障转移重启」，或通过 CLI 执行 reboot-db-instance --force-failover。故障转移测试应确认 4 项内容：第一，应用是否正确检测到连接断开并自动重连；第二，DNS 切换后应用是否连接到新主实例；第三，故障转移期间的错误率和响应时间变化；第四，监控告警是否正确触发。建议每季度执行一次故障转移测试，确认应用的恢复行为。测试应在业务低峰期进行，并提前通知相关方。Aurora 的故障转移通常在 30 秒以内完成，比标准 RDS 快得多，这是 Aurora 的架构优势之一。