我有以下设置，Linux 堆栈，前端运行 nginx 代理和静态资产，后端在主-主复制中运行 Ruby on Rails 和 MySQL：
- 主要站点：
front-end.a，back-end.a - 辅助站点：
front-end.b，back-end.b - 位于共享网络上的路由器可以路由到主站点和辅助站点
主站点在大多数时间处理请求。辅助站点是冗余的。back-end.b处于主-主复制状态，back-end.a但为只读状态。
当主站点发生故障时，请求需要重定向到辅助站点。这将显示服务不可用的 503 页面，直到手动干预确保主站点不会恢复，并按下大开关使辅助站点处于活动状态并可读写。
然后，可以以受控方式恢复主站点，成为back-end.a的只读复制从属back-end.b。当主站点上的所有东西再次准备就绪时，front-end.b将开始提供不可用的服务，back-end.b将切换到只读，请求需要再次重定向到主站点，最后主站点需要变为读写。
优先事项：
- 网站不得完全瘫痪或无法访问
- 切换到实时工作站点必须相当快
- 防止数据丢失/不一致比绝对可靠性更重要
现在，当前正在使用的方法是 Linux-HA / Heartbeat / Pacemaker，使用front-end.a和之间共享的虚拟 IP，front-end.b并将位置偏好设置为front-end.a。
如果主站点消失，这种方法可以很好地完成 IP 故障转移。但是，此后的手动控制水平相当欠缺。
例如，在主站点发生故障并且需要启动辅助站点后，我们需要确保主站点在恢复时不会尝试窃取 IP 地址。但是，Linux-HA 似乎不能很好地支持这一点。crm resource move是移动资源的记录命令（它通过添加无限权重位置规则来工作），但如果资源已经发生故障转移，则此命令将失败，提示资源已被移动。添加明确的更高权重位置偏好似乎不能可靠地工作。到目前为止，最可靠的做法是删除现有的位置规则并将其替换为优先使用辅助站点的新规则。这感觉就像我们在与工具作斗争并试图让它做一些它没有设计要做的事情。
Linux-HA 还存在其他怪异之处。集群在启动时经常陷入裂脑状态 - 两个节点都在发送心跳数据包（通过数据包嗅探验证），两个节点都可以 ping 通对方，但两个节点上的 crm_mon 都报告对方节点处于离线状态。心跳服务需要在其中一个节点上重新启动才能使其工作 - 有时需要 SIGKILL 而不是 SIGTERM 来关闭它。此外，crm_mon 显示在 或 上的配置发生更改时，CIB（集群数据库）几乎会立即复制front-end.a，front-end.b但 Pacemaker 需要一些时间才能真正移动 IP 资源 - 移动可能需要几分钟，这可能会危及我们的 SLA。
因此，我开始考虑其他更侧重于虚拟 IP 和 IP 故障转移而不是一般集群资源的选项。我看到的另外两个选项是乌卡普和保持活跃。
但是，考虑到我花在设置心跳等以及尝试使其工作上的时间，我希望得到有关此设置的最佳方法的反馈。
答案1
我已经有一段时间没有看过 Pacemaker 了，但有一些配置选项应该会有所帮助。您可以明确配置它以不自动恢复到主节点。这将有助于解决您的部分问题。快速搜索显示“on-fail=standby”可能是您想要的，但我认为还有其他设置可以做同样的事情。您在这里想要的术语是“资源粘性”。
此外，如果只有两个节点，您很容易遇到两个节点都在线，但认为另一个节点已关闭的情况。这很容易导致数据损坏。您没有提到已配置它，但这就是 STONITH 的用途。如果没有它，运行 Pacemaker 是非常危险的，特别是如果数据完整性对您很重要的话。