我正在尝试看看以下计划是否可行。这里的目标是能够实现 HA（正常运行时间），而不一定是为了负载——在一台 MySQL 5.5 服务器（使用 innodb）上写入没问题，但当数据库关闭时实际上不可能。
目前，我有一个主从复制设置，除了没有自动升级（显然），它运行良好。我计划做的是设置主主复制，以便使用 Amazon Route 53 DNS 故障转移（健康检查）进行这种“自动升级”。我试图避免的是不必使用自动递增技巧，因为“商务人士”已经习惯了将自动递增的 PK 作为连续数字（是的，我知道这很糟糕，但数据来自 2004 年）。
因此，设置主主复制，不带自动增量冲突预防位。主主是 db1.domain.com，辅主是 db2.domain.com
在 Amazon Route 53 中，为 db.domain.com 设置 DNS 故障转移记录 -> 主故障转移为 db1.domain.com -> 在 IP 地址端口 3306 上进行 TCP 健康检查 -> 次要故障转移为 db2.domain.com -> 在 IP 地址端口 3306 上进行 TCP 健康检查
大多数情况下（99%），除非 tcp://db1.domain.com:3306 失效，否则 DNS 命中 db.domain.com 时将提供 db1.domain.com。事实上，希望这是 100%。这可能带来的负面影响是丢失主键（冲突），我认为丢失一个订单是可以接受的。我们是一家数据量较小的 B2B 企业，如果发生这种情况（例如订单消失），只需致电我们的客户即可。
这听起来是个好计划吗？
然后我还将在 db1.domain.com 上运行另一个从属复制，作为从属 db1.domain.com 的“主”——不确定为什么，也许是为了大量 SELECT？
答案1
对数据库进行 DNS 故障转移其实并不那么简单。原因有很多，但以下是可能导致问题的几个原因。
许多应用程序使用连接池库，因此它们可能会创建与数据库的持久连接，因此假设 DNS 故障转移实际上可能会导致所有应用程序流量（读取和写入）转到新服务器，并防止写入可能发生在两者上并导致主键冲突的情况。
现在，如果主数据库真的宕机了，上述情况可能就不成问题了，因为这将终止所有现有的 SQL 连接，从而缓解任何双重写入问题。当高负载下 MySQL 服务器开始拒绝新连接时，就会出现问题。DNS 故障转移将触发，现有连接仍保留在当前服务器上，并创建到故障转移目标的新连接。现在你有麻烦了！
复制滞后和多主复制可以为这个等式增加另一个切线。在进行安全故障转移时，您确实不希望落后主服务器太多；因此可能发生的问题不胜枚举，无法在此列出。
看看 ScaleArc 这样的解决方案。它具有状态感知能力，能够理解复制滞后等问题，并提供一些简洁的 HA 选项，以及许多其他功能，如缓存、分析等。
答案2
尽量避免的是不要使用自动递增技巧
克服它。
因此推测您也没有任何交易，并且对架构更新的停机时间感到满意。
如果您的“业务人员”希望自动生成的 ID 是连续的，那么请问他们如何在没有这个的情况下实现安全的高可用性系统。这是完全可能的，但它非常非常慢，并且无法处理主主复制修复的所有其他坏事。
您会注意到，Amazon 文档仅讨论使用其故障转移服务来处理 Web 服务器 - 这是有原因的（而且可以说它甚至不是 Web 服务器的好策略）。在某些情况下，在客户端实现高可用性是一个好主意（这些依赖于循环寻址 - 而不是故障转移）。
我认为我可以接受损失一个订单
即使 TTL 为 0s，您也可以合理地预期传播需要大约 2 小时。您提供了有关软件堆栈及其位置的大量详细信息。如果在 AWS 内部运行 PHP/非持久性，您将获得更快的恢复速度，但如果使用持久连接（例如 Java），则可能会出现非常长时间的中断。
答案3
这听起来是个可行的计划。我不会使用 DNS 来解决故障。我会使用 LinuxHA 或 ucarp 之类的东西来管理浮动 IP，这将决定您的写入器数据库。如果您有多个客户端使用这些数据库，则尤其如此。