On Tue, Jul 31, 2012 at 11:38:28AM +0200, Tobias Brunner wrote:
> Hi list,
> 
> While trying to manually migrate a resource from one node to the other one, 
> nothing happens. I don't have any ideas anymore, so here is some information 
> what I did and how the configuration/logs look like:
> 
> crm status
> ----------
> ============
> Last updated: Tue Jul 31 11:20:24 2012
> Last change: Tue Jul 31 11:17:25 2012 via crm_resource on halab3
> Stack: openais
> Current DC: halab4 - partition with quorum
> Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
> 2 Nodes configured, 2 expected votes
> 5 Resources configured.
> ============
> 
> Online: [ halab3 halab4 ]
> 
>  Resource Group: groupMysql
>      resFsMysql (ocf::heartbeat:Filesystem):    Started halab3
>      resIPMysql (ocf::heartbeat:IPaddr2):       Started halab3
>      resMysql   (ocf::heartbeat:mysql): Started halab3
>  Master/Slave Set: ms-resDRBDMysql [resDRBDMysql]
>      Masters: [ halab3 ]
>      Slaves: [ halab4 ]
> 
> crm configure show
> ------------------
> node halab3
> node halab4
> primitive resDRBDMysql ocf:linbit:drbd \
>         params drbd_resource="mysql" \
>         op start interval="0" timeout="240" \
>         op stop interval="0" timeout="100"
> primitive resFsMysql ocf:heartbeat:Filesystem \
>         params device="/dev/drbd/by-res/mysql" directory="/var/lib/mysql" 
> fstype="ext4" \
>         op start interval="0" timeout="60s" \
>         op stop interval="0" timeout="60s"
> primitive resIPMysql ocf:heartbeat:IPaddr2 \
>         params ip="192.168.1.10" nic="eth0" cidr_netmask="28" \
>         op monitor interval="30s"
> primitive resMysql ocf:heartbeat:mysql \
>         params config="/etc/mysql/my.cnf" datadir="/var/lib/mysql" 
> log="/var/log/mysql.log" pid="/var/run/mysqld/mysqld.pid" 
> socket="/var/run/mysqld/mysqld.sock" 
> additional_parameters="--bind-address=0.0.0.0" \
>         op start interval="0" timeout="120s" \
>         op stop interval="0" timeout="120s" \
>         op monitor interval="60s" timeout="30s"
> group groupMysql resFsMysql resIPMysql resMysql
> ms ms-resDRBDMysql resDRBDMysql \
>         meta master-max="1" master-node-max="1" clone-max="2" 
> clone-node-max="1" notify="true" target-role="Master"
> location location-groupMysql-on-node1 groupMysql inf: halab3

So you have a "mandatory" location constraint saying
        run this thing only on halab3

And then you add ...

> colocation colo-groupMysql-ms-resDRBDMysql inf: groupMysql 
> ms-resDRBDMysql:Master
> order order-groupMysql-after-ms-resDRBDMysql inf: ms-resDRBDMysql:promote 
> groupMysql:start
> property $id="cib-bootstrap-options" \
>         dc-version="1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff" \
>         cluster-infrastructure="openais" \
>         expected-quorum-votes="2" \
>         no-quorum-policy="ignore" \
>         stonith-enabled="false"

,..

> What I did
> ----------
> "crm resource migrate groupMysql halab4"
> 
> What I see in the logs /var/log/corosync.log
> --------------------------------------------
> halab4:
> Jul 31 11:30:14 halab4 cib: [13557]: info: cib_process_request: Operation 
> complete: op cib_delete for section constraints 
> (origin=halab3/crm_resource/3, version=0.17.28): ok (rc=0)
> Jul 31 11:30:14 halab4 cib: [13557]: info: cib:diff: - <cib admin_epoch="0" 
> epoch="17" num_updates="28" />
> Jul 31 11:30:14 halab4 cib: [13557]: info: cib:diff: + <cib epoch="18" 
> num_updates="1" admin_epoch="0" validate-with="pacemaker-1.2" 
> cib-last-written="Tue Jul 31 11:28:04 2012" crm_feature_set="3.0.6" 
> update-origin="halab3" update-client="cibadmin" have-quorum="1" 
> dc-uuid="halab4" >
> Jul 31 11:30:14 halab4 cib: [13557]: info: cib:diff: +   <configuration >
> Jul 31 11:30:14 halab4 cib: [13557]: info: cib:diff: +     <constraints >
> Jul 31 11:30:14 halab4 cib: [13557]: info: cib:diff: +       <rsc_location 
> id="cli-prefer-groupMysql" rsc="groupMysql" __crm_diff_marker__="added:top" >
> Jul 31 11:30:14 halab4 cib: [13557]: info: cib:diff: +         <rule 
> id="cli-prefer-rule-groupMysql" score="INFINITY" boolean-op="and" >
> Jul 31 11:30:14 halab4 cib: [13557]: info: cib:diff: +           <expression 
> id="cli-prefer-expr-groupMysql" attribute="#uname" operation="eq" 
> value="halab4" type="string" />
> Jul 31 11:30:14 halab4 cib: [13557]: info: cib:diff: +         </rule>
> Jul 31 11:30:14 halab4 cib: [13557]: info: cib:diff: +       </rsc_location>
> Jul 31 11:30:14 halab4 cib: [13557]: info: cib:diff: +     </constraints>
> Jul 31 11:30:14 halab4 cib: [13557]: info: cib:diff: +   </configuration>
> Jul 31 11:30:14 halab4 cib: [13557]: info: cib:diff: + </cib>

... yet an other contraint, crm shell syntax equivalent below.

from the crm resource migrate:
        location cli-prefer-groupMysql groupMysql inf: halab4
from your config:
        location location-groupMysql-on-node1 groupMysql inf: halab3

So pacemaker gets to chose which infinity is more infinite.

> What my problem is
> ------------------
> The resource group "groupMysql" should migrate from halab3 to halab4,
> but it doesn't. If I manually stop corosync on halab3, the resource
> group "groupMysql" successfully starts on halab4. I don't understand
> why the manual migration does not work. Does anyone have any ideas?

Remove the inf: halab3, or replace it with some not infinite score.

Or did you actually do that, but did not tell us here?

Depending on what behaviour you actually want,
you may need to specify a resource stickiness as well.

> How can I debug such problems?

Experience helps ;-)

> Thanks for every help!


        Lars


-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to