我并不担心脑裂，因为两台服务器之间的连接很牢固（而且我没有第三台机器）
我希望有一些具有自动故障转移功能的 MariaDB 复制，这样即使一个数据库死机，它也能继续工作。我见过 MaxScale，但由于我只有两台机器，它必须与其中一台服务器在同一台机器上运行，如果该服务器死机，那么什么都行不通。据我所知，MariaDB Galera 集群将拒绝允许我仅在两台机器上运行并具有自动故障转移功能（需要仲裁）。但是，我可能能够在另一台机器上运行仲裁器，甚至在其上运行另一个数据库，但速度会很慢。
此外，后端是 PHP - 我愿意更改 mysqli 设置等，但我不知道是否或者必须在那里更改什么。
编辑：我愿意放弃自动故障转移，但我想要的行为如下：
如果我连接到服务器 A，它会连接到数据库 A（主服务器）并正常读取/写入。
如果我连接到服务器 B，它会连接到数据库 B（只读从属服务器）并可以正常读取。如果需要写入，它可以写入，但会将数据推送到数据库 A。
可以在两台服务器上使用 MaxScale 或者类似的东西吗？
答案1
您有两个节点。不要使用任何类型的主-主模式，因为两个节点极易发生脑裂（几乎可以肯定最终会发生）。
这种有状态的应用程序不能很好地处理双节点集群部署——需要操作员干预或 CRM 才能在发生故障时确保集群的稳健性——这也是它首先进行集群的原因。
您有一个双节点集群。您绝对应该担心裂脑，因为这种架构很容易出现裂脑情况。仅仅因为节点间网络链接今天是稳固的并不意味着它会一直如此，这是双节点集群中最大的风险因素之一。除非击剑或者法定人数在节点之间建立隔离。这是双节点集群中最重要的考虑因素之一，因为隔离可将裂脑情况的发生概率从高降低到接近零。
我建议使用 Pacemaker/Corosync 来处理这个问题。这是一个复杂的堆栈，但提供了在两个节点中产生生产级集群所需的机制。我还建议一次只使用一个主实例，而不是多主实例，即使在这种集群管理器的强制执行下也是如此。
有一个很好的 HA MariaDB 指南可以作为起点。它不涵盖隔离的使用。如果您无法完成隔离，Corosync 还可以使用运行投票守护进程的小型仲裁节点为整体实现提供仲裁，而无需应用程序开销成本（请参阅有关 Corosync qdevice 的信息）。
它位于订阅墙后面，但它是关于配置主动-被动 MySQL 集群的端到端指南，一次在一个节点上运行并在节点之间复制块存储
Pacemaker 高级资源类型涵盖了关于如何优雅地协调故障转移的大部分问题，能够将资源分组为线性依赖链，以及表达跨节点运行多个应用程序实例的多状态领导者选举语义。您可以在这里找到。
Bundle 是一种通过 Docker 和 RKT 等容器运行时在 Pacemaker 中实现应用程序隔离的方法。这开辟了另一种隔离途径，因为这些 Bundle 在集群中显示为 Pacemaker 节点本身 - 因此它们可以独立于其他应用程序由集群“隔离”。您可以在这里找到。
答案2
我运行了各种数据库（Mongo、Elasticsearch、SQL Server 等），秉承着同样的理念：“我不关心问题，我只能运行两个节点。”
这是一个充满痛苦的世界。
如果你运行主从模式，那就好了。但会有麻烦。
经过多年的纠结，以及由于我坚持只使用两个节点而导致的各种 devops 难题（我坚持这样做是因为我们的数据库非常大，而第三个节点的成本非常高），我终于开始运行三个节点。
然后一切都变好了。
我从多年的舞蹈生涯中得到的教训是：有两种选择：
- 具有热备用的单节点（例如主从）
- 三个节点
根据我的经验，我永远不会再运行两个节点主动-主动（除非有一个神奇的东西可以完全防止脑裂，我已经看到过，而且非常丑陋）。
经过五年在各种堆栈上运行多个 0.5-1.5TB 数据库的经验。
答案3
一个选项是使用 keepalived 运行异步主主复制，以通过浮动 IP 进行故障转移。这不是很好，但它可以覆盖服务器彻底故障的情况。
您是否有 ILO 或其他方式让一台机器强制关闭另一台机器（STONITH）？这确实是防止部分故障所必需的，例如，一台机器崩溃但没有完全崩溃，因此它仍然能够响应心跳包，但除此之外无法正常工作。这可能导致故障转移在应该发生时不会发生。