2

我想设置一个完整的服务器（apache，mysql 5.7）作为生产服务器的后备。使用 rsync 和 cronjob 的文件级同步已经完成。

mysql-replication 目前是问题所在。更准确地说：选择正确的复制方法。

到目前为止，多主组复制似乎是最合适的方法。如果生产停机时间较长，可以通过 DNS 更改快速切换到备用服务器。无需调整即可立即对数据库进行写访问。

到目前为止一切顺利：但是，如果后备服务器出现故障，它将处于无法访问状态，并且生产服务器切换为只读，因为它的组不再具有配额。这当然是不行的。我认为使用不同的副本变量可能是可能的：如果后备服务器在一段时间内（约 5 分钟）处于无法访问状态，则生产服务器应停止 group_replication 并启动新的 group_replication。这必须自动发生以保持只读时间相对较低。当 fallback-server 重新上线时，应该手动将其添加到新启动的组中。但是，如果我正确阅读了各种论坛帖子和文档，那是不可能的。无论如何，运行只有两个节点的 Group_Replication 是错误的决定。

https://forums.mysql.com/read.php?177,657333,657343#msg-657343

主从复制是唯一可以考虑用于这种后备系统的复制吗？https://dev.mysql.com/doc/refman/5.7/en/replication-solutions-switch.html

或者，如果您能够对配额问题做出适当的反应，Group_Replication 是否提供了可能性？到目前为止我忽略的可能性。

致以真诚的感谢和诚挚的问候

4

2 回答 2

1

简短回答： 您必须有 [至少] 3 个节点。

长答案：

只有两个节点的裂脑：

  • 仅写入幸存节点，但前提是您可以断定它是唯一幸存的节点，否则......
  • 网络死了，两个主节点都在接受写入。这对他们彼此不同意。你可能没有干净的方法来修复这个烂摊子。
  • 使用幸存的节点进入只读模式。（唯一安全和理智的方法。）

问题是自动化系统无法区分失效的主节点和失效的网络。

所以......您必须有3 个节点才能安全地避免“脑裂”并有很大的机会进行自动故障转移。这也意味着没有两个节点应该在同一个龙卷风路径、洪水范围、火山路径、地震断层等。

您选择了 Group Replication (InnoDB Cluster)。这是 MySQL 提供的出色产品。带有 MariaDB 的 Galera 是一个同样出色的产品——细节上有很多差异，但归结为需要 3 个，最好是分散的节点。

由于 TTL，DNS 更改需要一些时间。代理服务器可能会对此有所帮助。

Galera 可以在“Primary + Replicas”模式下运行，但它也允许您在所有节点都被读写的情况下运行。这导致客户端停止写入一个节点并开始写入另一个节点所需的一组步骤略有不同。有“代理”可以帮助解决这些问题。

故障回复

您是否尝试始终使用某个主节点，除非它关闭？或者您可以接受让任何节点成为“当前”主节点吗？

我认为“回退”只是一种“故障转移”，可以追溯到原始主节点。这意味着第二次中断（可能更短暂）。但是，我了解地理因素。您可能希望您的主要主节点“靠近”您的大多数客户。

于 2022-02-23T19:50:07.323 回答
1

我推荐使用带有 HAProxy 的 Galera MySQL 集群作为负载均衡器和自动故障转移解决方案。我们已经在生产中使用了很长时间，从来没有遇到过严重的问题。要考虑的最重要的事情是监视节点之间的复制同步状态。另外，请确保您的存储引擎是 InnoDB，因为 Galera 不适用于 MyISAM。

检查此链接以了解如何设置： https ://medium.com/platformer-blog/highly-available-mysql-with-galera-and-haproxy-e9b55b839fe0

但在这种情况下，主要问题不是故障转移机制，因为有很多开箱即用的解决方案，而是您必须检查您的读/写比率和事务服务，并确保复制延迟不会影响它们。有时具有主从复制的垂直可扩展解决方案更适合交易敏感的金融系统，这实际上取决于您提供的服务。

于 2022-02-26T08:39:04.060 回答