在Ubuntu (任何版本)上，心脏起搏器/Cor产c资源清理会导致重新启动。

Question

我在Ubuntu (12.04 / 14.04 / 16.04和18.04)上的一个心脏起搏器/cor产(2个节点)集群中遇到了问题，并且找不到其他人描述这个问题。有两个资源来源: res_ip (虚拟IP)和res_apache (apache2)。这些只是资源的例子。这个问题出现在任何类型的相关/共用资源中。

res_apache与res_ip并置，使apache始终在“活动”服务器上运行，这是通过虚拟ip提供的。在有些情况下，res_ip会失败并重新启动，这会使res_apache重新启动(正如预期的那样)，从而留下故障计数。

问题:试图清理资源res_ip (crm资源清理res_ip)会导致res_apache (依赖于res_ip)重新启动，我不知道为什么。

CentOS上的相同命令不会对any应用程序的操作造成任何中断。该命令只清除故障计数。

附加的node1_corosync.log.extract.txt显示，res_ip被识别为已停止(第951行)，因此依赖的res_apache被重新启动。清理命令是在那个时候运行的(15:18:17)，所以我假设资源是否正在运行的检查是由清除命令启动的。它不应该处于“停止”状态，因此不能重新启动依赖方重新源res_apache。

同样，我需要指出的是，我在所有的Ubuntu版本中都看到了这个问题，但是在CentOS上没有，而且资源的种类也不重要。

有人知道为什么会发生这种情况(而且只发生在Ubuntu中)吗？

日志文件和配置：https://1drv.ms/u/s!Av4S568oLfJmgZtQ6pcE40FOKN8yDg?e=IOHKX8

Answer 1

(你应该邮寄任何软件(你在那里试过吗？)你使用，真的，寻找和提供帮助的第一！)以下摘录自集群邮件列表，答案来自Redhat家伙(尽管我的集群版本各不相同).

当我称之为“pc资源清理Res1”时，这将导致Res2端的服务中断(即停止Res2…)。我未经证实的假设是，起搏器首先通过调用监视器来检测资源(S)的当前状态，然后决定是否要执行任何操作。但是，在读取日志文件时，我会解释说，Res1暂时从cib中删除，然后重新插入。这将导致Res2停止，直到Res1确认状态“启动”为止。

正确，删除资源的操作历史记录是起搏器触发当前状态的重新探测的方式.

在我解释文档时，可以通过使用kind=Optional配置order约束来避免这种行为。但我不知道这是否会导致其他不应有的副作用。(例如停车时倒序)

只有当两个操作都需要在相同的转换中执行时，kind=Optional约束才适用。也就是说，如果单个集群检查发现需要启动Res1和Res2，那么Res1将在Res2之前启动。但是，完全有可能Res2可以在更早的转换中启动，而Res1仍然停止，稍后的转换启动Res1。类似地，当停止时，如果需要停止，Res2将首先停止。

在最初的场景中，如果您的主/从资源只在IP启动后才绑定到IP，那么kind=Optional就不可靠了。但是，如果主/从资源绑定到通配符IP，那么顺序就不重要了--您可以保留共址约束并取消排序。

另一个解决方法似乎是将依赖资源设置为非托管资源，执行清理，然后将其设置为托管资源。

这是我的建议，如果你必须保持强制性订购。

我想知道，如果不需要改变状态，“pcs资源故障计数重置”是否会在不执行任何操作的情况下执行。但是我想要记住的是，我们已经时不时地尝试过了，有时失败的资源在故障计数重置之后还没有启动。(但我不确定，也还没有时间尝试繁殖。)

不，在较新的起搏器版本中，crm_failcount --删除相当于crm_resource --清除。(pcs机调用这些程序来实际执行这项工作)

是否有任何更深层次的洞察力有助于对这一问题的正确理解？

这是目前CIB实施的一个副作用。心脏起搏器的策略引擎通过在CIB中检查资源的操作历史来确定资源的当前状态。清理将删除操作历史记录，从而使当前状态未知，从而迫使重新探测。作为一种副作用，在重新探测完成之前，任何依赖项都不再满足其约束。

理论上可以实现“清理旧故障”选项，该选项将清除资源的故障计数，并仅删除失败操作的操作历史记录项，只要这样做不会更改当前状态确定。但这将是相当复杂的，设置资源非管理是一个简单的解决办法。