我正在为主数据库和从属数据库开展一个起搏器项目，以执行基于IP的故障切换。 将有两个IP资源，一个用于主站，另一个用于需要一起移动的从站。 我意识到，我在下面标记的不是一个完整的解决scheme，但要求如下：
这是我的基本configuration：
node $id="75463ec2-702c-427b-965b-b7ffb7814008" db1 node $id="a1f2d612-2d9f-4872-bf24-024f5bece3ce" dbslave2 node $id="d1d42f67-e4f2-4c71-950f-07d94ac01f8d" dbslave1 node $id="f243d865-c1a1-4d52-9100-b0d36a08207c" db2 primitive ip_dbmaster ocf:heartbeat:IPaddr2 \ params ip="10.153.114.100" cidr_netmask="24" primitive ip_dbslave ocf:heartbeat:IPaddr2 \ params ip="10.153.114.101" cidr_netmask="24" location loc-ip-dbmaster-1 ip_dbmaster \ rule $id="loc-ip-dbmaster-1-rule" 200: #uname eq db1 location loc-ip-dbmaster-2 ip_dbmaster \ rule $id="loc-ip-dbmaster-2-rule" 0: #uname eq db2 location loc-ip-dbmaster-3 ip_dbmaster \ rule $id="loc-ip-dbmaster-3-rule" -inf: #uname eq dbslave2 location loc-ip-dbmaster-4 ip_dbmaster \ rule $id="loc-ip-dbmaster-4-rule" -inf: #uname eq dbslave1 location loc-ip-dbslave-1 ip_dbslave \ rule $id="loc-ip-dbslave-1-rule" 200: #uname eq dbslave1 location loc-ip-dbslave-2 ip_dbslave \ rule $id="loc-ip-dbslave-2-rule" 0: #uname eq dbslave2 location loc-ip-dbslave-3 ip_dbslave \ rule $id="loc-ip-dbslave-3-rule" -inf: #uname eq db1 location loc-ip-dbslave-4 ip_dbslave \ rule $id="loc-ip-dbslave-4-rule" -inf: #uname eq db2 property $id="cib-bootstrap-options" \ dc-version="1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd" \ cluster-infrastructure="Heartbeat" \ expected-quorum-votes="2" \ stonith-enabled="false" \ symmetric-cluster="false" 到目前为止，＃1和＃2的工作很好。 ＃3似乎有点类似于托pipe，但我不知道从哪里开始或如何设置依赖。 我看到一个规则引擎，但是我还没有弄明白。 对于4-5，我不知道这是否可以通过起搏器完成，或者我是否必须写一个外部脚本来处理这件事。
我的目标是能够做到这一点：
crm resource move ip_dbmaster db1
并拥有一切。 我会解决的
dbfailover db2
…如果我必须将这些外部代码编码给Pacemaker，或者这是否可以内置。
感谢你的帮助！
首先，让我说，在过去的十年中，我已经build立了不less集群，我从来没有见过像你所描述的依赖关系。 通常人们会设置它，以便所提供的服务不依赖于哪个主机处于活动状态，哪个处于备用状态，并且您不关心哪个主机拥有该资源，只要它在其中一个主机上运行。
唯一可以实现的方式是实现从节点作为由主节点启动的资源，例如通过SSH连接到从节点运行IPaddr2和其他所需资源。 可能使用身份文件和authorized_keys条目进行SSH公钥身份validation，以便主服务器可以在不需要密码的情况下在从服务器上运行命令。
所以这将需要创build一个“slaveIPaddr2”资源脚本，这将只是包装一个命令，如：
HOST=`hostname` exec ssh -i /path/to/ssh-identity dbslave$${HOST#db} /path/to/IPaddr2 "$@"
然后将ip_dbslave资源更改为“slaveIPaddr2”而不是“IPaddr2”作为运行的资源。
至于在迁移之前和之后运行的脚本，这些大多数听起来就像构成资源组的普通多个资源脚本，并使用“组”和“顺序”configuration项目的优先顺序。 例如，创build“master_pre”（你想在master上运行的“before”脚本），“slave_pre”，“master_post”等资源，然后使用“order”来指定它们以适当的顺序运行（master_pre，slave_pre，ip_dbmaster，ip_dbslave，master_post，slave_post）。 在这里，你也可能需要用SSH包装器来包装从属项目，以便像上面提到的那样把它们有效地当作一个主机来处理。
这听起来像是你希望在迁移之前运行“pre”脚本，而不是作为启动资源的一部分？ 除非您被告知，否则Pacemaker不会迁移服务，或者当前运行该服务的节点失败。 在发生故障的节点的情况下，您的服务无论如何都是无用的，所以没有理由检查以避免迁移。 因此，如果您关心在迁移时阻止迁移，那么最好的答案可能是创build一个运行您的预服务检查的“迁移”脚本，并且只有在testing成功时才继续迁移请求。
我不知道在起搏器中testing集群中的其他主机之前做一个迁移的方法，如果这是你想用＃4来实现的，那么它可能必须是一个外部检查， 。
运行除IPaddr2之外的其他资源很容易通过“group”和“order”指令完成。