我正在尝试使用corosync和pacemaker设置一个主动/被动（2个节点）的Linux-HA集群来启动并运行PostgreSQL数据库。 它通过DRBD和一个服务IP工作。 如果node1发生故障，node2应该接pipe。 如果PG在节点2上运行，则失败。 一切正常，除了STONITH的东西。
节点之间是一个专用的HA连接（10.10.10.X），所以我有以下接口configuration：
eth0 eth1 host 10.10.10.251 172.10.10.1 node1 10.10.10.252 172.10.10.2 node2 Stonith已启用，并正在使用ssh代理进行testing以杀死节点。
crm configure property stonith-enabled=true crm configure property stonith-action=poweroff crm configure rsc_defaults resource-stickiness=100 crm configure property no-quorum-policy=ignore crm configure primitive stonith_postgres stonith:external/ssh \ params hostlist="node1 node2" crm configure clone fencing_postgres stonith_postgres
crm_mon -1显示：
============ Last updated: Mon Mar 19 15:21:11 2012 Stack: openais Current DC: node2 - partition with quorum Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b 2 Nodes configured, 2 expected votes 4 Resources configured. ============ Online: [ node2 node1 ] Full list of resources: Master/Slave Set: ms_drbd_postgres Masters: [ node1 ] Slaves: [ node2 ] Resource Group: postgres fs_postgres (ocf::heartbeat:Filesystem): Started node1 virtual_ip_postgres (ocf::heartbeat:IPaddr2): Started node1 postgresql (ocf::heartbeat:pgsql): Started node1 Clone Set: fencing_postgres Started: [ node2 node1 ]
问题是：当我切断eth0接口之间的连接时，它会杀死两个节点 。 我认为这是一个法定人数的问题，因为只有2个节点。 但是我不想为了计算正确的法定人数而添加第三个节点。
有什么想法来解决这个问题吗？
这是一个稍微老一点的问题，但这里提出的问题是基于对集群中故障转移（特别是双节点集群）如何以及何时发生作用的误解。
要点是： 您不能通过禁用两个节点之间的通信来进行故障转移testing。 这样做会导致你正在看到的，与STONITH额外的交叉情景。 如果要testing防护function，则在主动节点上执行一个简单的killall -9 corosync 。 其他方法是crm node fence或stonith_admin -F 。
从你的集群不太完整的描述（其中是crm configure show的输出和cat /etc/corosync/corosync.conf ？），似乎你正在使用10.10.10.xx地址进行消息传递，即Corosync /集群通信。 172.10.10.xx地址是您的常规/服务networking地址，您可以通过其172.10.10.xx地址访问给定的节点，例如使用SSH。 DNS似乎也将node1的节点主机名parsing为172.10.10.1。
你有STONITHconfiguration使用SSH，这本身不是一个好主意，但你可能只是testing。 我没有使用它自己，但我假设SSH STONITH代理login到另一个节点，并发出一个关机命令，如ssh root@node2 "shutdown -h now"或类似的东西。
现在，当切断节点之间的集群通信会发生什么？ 节点不再能够看到每个节点都很好，因为它们之间没有更多的通信。 因此，每个节点都假设它是某个不幸事件的唯一幸存者，并试图成为（或保持）活动节点或主节点。 这是经典和可怕的裂脑情景 。
其中一部分是为了确保另一个明显可能出现故障的节点已经closures，这正是STONITH进来的地方。请记住， 两个节点现在都在玩同一个游戏：试图成为（或保持）在所有集群资源上，以及在头部拍摄其他节点。
你大概可以猜到现在发生了什么。 node1执行ssh root@node2 "shutdown -h now" ， node2执行ssh root@node1 "shutdown -h now" 。 这不使用集群通信networking10.10.10.xx，而是使用服务networking172.10.10.xx。 由于两个节点实际上都是活着的，所以它们在发出命令或接收SSH连接时都没有问题，所以两个节点同时相互射击。 这会杀死两个节点。
如果你不使用STONITH，那么裂脑可能会有更糟糕的后果，特别是在DRBD的情况下，最终可能导致两个节点都成为主节点。 数据损坏很可能发生，必须手动解决裂脑。
我build议阅读http://www.hastexo.com/resources/hints-and-kinks上的资料，这些资料是由那些为我们今天所称的“Linux HA栈”。
TL; DR ：如果您正在切割节点之间的集群通信，以testing您的防护设置， 那么您做错了 。 改为使用killall -9 corosync ， crm node fence或stonith_admin -F 。 切割集群通信只会导致一个裂脑的情况，这可能会导致数据损坏。
尝试阅读Pacemaker文档的Quorum和双节点群集章节。
使用Pacemaker检查HA群集： http : //clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/index.html