在我德国的供应商发生大规模数据问题后，我现在被迫处理故障转移情况。但有几个问题我找不到真正的答案。所以我希望有人能在这里帮助我。
我目前有 server1 在独立的 docker 容器中运行两个 MySQL 数据库。现在应该将它们复制到第二台服务器上。如果 server1 发生故障，我可以通过 ClusterIP 相对快速地切换到 server2。
以防万一，了解这一点很重要：使用数据库的软件是一个体育比赛管理系统，它对数据库执行大量的写入操作（未经测试，但总共没有写入而不是读取操作）。
我现在的问题是：
- 哪种复制方法最为合适？
- 据我了解，MASTER <-> MASTER 最合适。但我在这里也反复读到，可能会出现问题。
- 使用 MASTER <-> SLAVE 时，会出现一个问题，即从属设备只能读取。如果主设备发生故障，会发生什么情况？从属设备是否会自动成为主设备并可以写入？
- 或者集群是最佳解决方案？目前我只有一个活动节点。未来可以添加美国的另一个数据库节点。但目前它不存在。
我非常感谢任何帮助，因为我需要一个快速的解决方案，而且这个一般性主题似乎非常庞大而且不那么容易。
答案1
您提出了两个问题。
MySQL 拓扑按顺序（从 OK 到 Best）
- 主服务器 -> 副本服务器——可以实现“故障转移”，但需要手动操作，因此需要时间。
- 主服务器 <=> 主服务器——设置起来仅稍微复杂一些，同时提供对另一台服务器的“即时”使用。
- 至少包含 3 个服务器的集群。这进一步实现了故障转移的自动化。请参阅“InnoDB CLuster”（MySQL 8）或“Galera”（包含在 MariaDB 中）。
地理位置——请注意，即使是数据中心也可能出现故障。例如，佛罗里达州有多少地方会因为一场飓风而下线？
请注意“裂脑”场景。在这种情况下，您只有两台服务器，并且两台服务器都运行良好，但网络瘫痪了。它们无法分辨，您也无法判断情况如何。如果每台服务器都认为自己是唯一活着的服务器并继续进行写入，那么您最终会陷入混乱。因此，您必须假设整个系统都瘫痪了。
底线——您至少需要 3 台物理上分开的服务器。
代理人
仍然存在问题客户知道数据库系统的哪个部分处于活动状态（用于读取和/或写入）。当只有“读取”很重要时，许多具有任意数量副本的拓扑就足够了——并提供“无限”扩展。“写入”才是真正的挑战所在。
有几种第三方产品可以很好地发现一台服务器宕机，并“采取正确的措施”将服务器重新路由到其他服务器。研究一下它们。
编码
当发生故障时，您的代码可能会出现某种错误。您必须检查错误，有些错误无法自行修复。而且大多数网络错误需要一段时间才能被注意到。