我试图看看下面的计划是否可行。 这里的目标是能够做HA（正常运行时间），而不一定是加载 – 在一个MySQL 5.5服务器（使用innodb）上写入很好，但在数据库closures时不可能。
目前，我有一个主从复制设置工作正常，除了没有自动升级（显然）。 我打算做的是设置主 – 主复制，以便使用Amazon Route 53 DNS故障转移（运行状况检查）执行此“自动升级”。 我试图避免的是不必做自动增量的伎俩，因为“业务伙伴”习惯了自动递增的PK作为连续的数字（是的，我知道这是不好的，但数据是从2004年）。
因此，在没有自动增加防冲突位的情况下设置主 – 主复制。 主要主数据库是db1.domain.com，辅助主数据库是db2.domain.com
在Amazon Route 53中，为db.domain.com设置DNS故障切换logging – >主故障切换为db1.domain.com – >在IP地址端口3306上使用TCP健康检查 – >辅助故障切换为db2.domain.com – > IP地址端口3306上的TCP健康检查
大多数情况下（99％），除非tcp：//db1.domain.com：3306已经死了，db1.domain.com将在DNS命中db.domain.com上。 事实上，希望这是100％。 这可能的缺点是失去了主键（碰撞），我认为我可以失去一个订单。 我们是一个低数据量的B2B业务，如果发生这种情况，就可以打电话给我们的客户（像一个订单消失）。
这听起来像一个好的计划？
然后，我也将在db1.domain.com上运行另一个从属复制作为“主”到一个slave-db1.domain.com – 不知道为什么，也许是沉重的SELECT？
为数据库执行DNS故障转移并不那么简单。 有很多原因，但是这里有一些可能会导致问题的原因。
许多应用程序使用连接池库，因此它们可能会创build到数据库的持久连接，所以假设DNS故障转移实际上可能会导致所有应用程序通信（读取和写入）转到新的服务器，并防止写入的情况发生发生在两者之间并导致主键冲突。
现在，如果主数据库真正closures，上面描述的情况可能不会成为问题，因为这会杀死所有存在的SQL连接，从而导致任何双重写入问题得到缓解。 在高负载下会发生问题，MySQL服务器开始拒绝新的连接。 DNS故障转移将触发，现有连接保留在当前服务器上，并且新连接将创build到故障转移目标。 现在你麻烦了！
复制延迟和多主复制可以为此方程添加另一个切线。 在进行安全故障转移时，您并不是真的想要远离主服务器; 由此可能发生的问题太多了，无法列在这里。
看一下像ScaleArc这样的解决scheme。 这是国家意识和理解像复制滞后的东西，并提供一些整洁的高可用性选项，以及许多其他function，如caching，分析等。
这听起来像是一个可行的计划。 我不会使用DNS的失败。 我会使用像LinuxHA或ucarp来pipe理一个浮动IP，这将确定您的作家数据库。 如果您有多个使用这些数据库的客户端，则情况尤其如此。
试图避免的是不必做自动增量技巧
克服它。
所以大概你也没有事务，并且对模式更新的停机时间感到满意。
如果你的“业务伙伴”希望自动生成的ID是连续的，那就问他们如何在没有这个的情况下实现一个安全的高可用性系统系统。 这是很有可能的，但是非常慢，并且不能处理主 – 主复制修复的所有其他不好的事情。
你会注意到，亚马逊文档只谈论使用他们的故障转移服务来处理networking服务器 – 这是有原因的（可以说，它甚至不是一个好的networking服务器策略）。 在客户端实现高可用性是一个好主意（这些依赖于循环寻址 – 而不是故障切换）。
我认为我可以输掉一个命令
即使采用0s TTL，您也可以合理预计传播需要大约2个小时。 您已经详细了解了您的软件堆栈以及它所在的位置。 使用AWS内部的PHP /非持久性运行，您将获得更快的恢复，但通过持续连接（例如Java），则可能会有很长的中断时间。