我的问题有两部分：
关于第(1)部分：如果我理解正确的话，所有实例修改都是在备用数据库上进行的，然后AWS通过在主数据库更新时将CNAME翻转到备用数据库来进行故障转移，所以如果我要进行任何类型的操作实例修改并选择“立即应用”，它应该会导致故障转移，对吗？
关于第 (2) 部分：我正在专门寻找一种监视 Oracle RDS 实例的故障转移的方法，无论是通过 lambda 函数、bash 脚本还是其他方式。据我所知，即使我通过安全组允许所有 ICMP 流量，也不可能将 ping 与 RDS 结合使用。我可以使用 telnet 或 SQL 客户端毫无问题地进行连接。不过，我想要的是某种方法，在故障转移期间定期对数据库进行 ping 操作，以查看与连接字符串关联的 IP 何时切换以及需要多长时间。有什么建议吗？
要模拟故障转移，只需在重新启动时“重新启动并进行故障转移”，而不是同时重新启动两者。来自链接的文档：
当您想要模拟故障时，通过故障转移重新启动非常有用 用于测试的数据库实例，或将操作恢复到原始可用区 发生故障转移后。
编写一个脚本，定期与 SQL 客户端连接并对您喜欢的表执行快速选择。您可以使用它来测量故障转移期间的真实停机时间；我们有一个与此非常相似的工具，在将测试 RDS 应用于生产 RDS 之前，我们在获取测试 RDS 修改的估计时使用该工具。我们的工具只是将时间戳写入控制台以及每隔几秒是否失败/成功。该工具将在重新启动之前写入成功，在重新启动期间写入失败，并在切换完成后再次写入成功。
修改 Amazon RDS 数据库实例并使用立即应用参数
date; while true; date; do nc -vz DBNAME.REGION.rds.amazonaws.com PORT; sleep 1; done
注：以上是针对
netcat-openbsd。如果使用
netcat-traditional，您需要修改它。
这会每秒轮询数据库以查看是否仍然可以连接。通常，当我运行此命令然后通过故障转移启动重新启动时，连接会在故障转移期间简单地悬空，然后在故障转移完成并恢复连接时显示超时错误，大概是因为故障转移通常比重新启动花费的时间更长。如果重新启动的时间恰好比故障转移花费的时间长，则在重新启动完成后，连接可能会在一段时间内被拒绝。无论如何，使用此方法，我能够获得 2:08 的一致故障转移时间。
然而，与我最初的想法不同，大多数实例修改根本不涉及故障转移。我已经测试了调整实例大小以及更改选项组和参数组，并且没有遇到任何停机时间。
更改数据库引擎确实会导致故障转移。
您可以使用 AWS 故障注入服务 (FIS) 在 RDS 上模拟可用区故障转移。多个预定义场景可用。您还可以通过同时执行多个操作来创建自己的灾难测试。