[Pacemaker] [Problem] Fail-over is delayed.(State transition is not calculated.)

Andrew Beekhof andrew at beekhof.net
Wed Feb 19 03:16:17 UTC 2014


I'll follow up on the bug.

On 19 Feb 2014, at 10:55 am, renayama19661014 at ybb.ne.jp wrote:

> Hi David,
> 
> Thank you for comments.
> 
>> You have resource-stickiness=INFINITY, this is what is preventing the failover from occurring. Set resource-stickiness=1 or 0 and the failover should occur.
>> 
> 
> However, the resource moves by a calculation of the next state transition.
> By a calculation of the first trouble, can it not travel the resource?
> 
> In addition, the resource moves when the resource deletes next colocation.
> 
> colocation rsc_colocation-master-3 INFINITY: vip-rep msPostgresql:Master
> 
> There is the problem with handling of colocation of some Pacemaker?
> 
> Best Regards,
> Hideo Yamauchi.
> 
> --- On Wed, 2014/2/19, David Vossel <dvossel at redhat.com> wrote:
> 
>> 
>> ----- Original Message -----
>>> From: renayama19661014 at ybb.ne.jp
>>> To: "PaceMaker-ML" <pacemaker at oss.clusterlabs.org>
>>> Sent: Monday, February 17, 2014 7:06:53 PM
>>> Subject: [Pacemaker] [Problem] Fail-over is delayed.(State transition is not    calculated.)
>>> 
>>> Hi All,
>>> 
>>> I confirmed movement at the time of the trouble in one of Master/Slave in
>>> Pacemaker1.1.11.
>>> 
>>> -------------------------------------
>>> 
>>> Step1) Constitute a cluster.
>>> 
>>> [root at srv01 ~]# crm_mon -1 -Af
>>> Last updated: Tue Feb 18 18:07:24 2014
>>> Last change: Tue Feb 18 18:05:46 2014 via crmd on srv01
>>> Stack: corosync
>>> Current DC: srv01 (3232238180) - partition with quorum
>>> Version: 1.1.10-9d39a6b
>>> 2 Nodes configured
>>> 6 Resources configured
>>> 
>>> 
>>> Online: [ srv01 srv02 ]
>>> 
>>>   vip-master     (ocf::heartbeat:Dummy): Started srv01
>>>   vip-rep        (ocf::heartbeat:Dummy): Started srv01
>>>   Master/Slave Set: msPostgresql [pgsql]
>>>       Masters: [ srv01 ]
>>>       Slaves: [ srv02 ]
>>>   Clone Set: clnPingd [prmPingd]
>>>       Started: [ srv01 srv02 ]
>>> 
>>> Node Attributes:
>>> * Node srv01:
>>>      + default_ping_set                  : 100
>>>      + master-pgsql                      : 10
>>> * Node srv02:
>>>      + default_ping_set                  : 100
>>>      + master-pgsql                      : 5
>>> 
>>> Migration summary:
>>> * Node srv01:
>>> * Node srv02:
>>> 
>>> Step2) Monitor error in vip-master.
>>> 
>>> [root at srv01 ~]# rm -rf /var/run/resource-agents/Dummy-vip-master.state
>>> 
>>> [root at srv01 ~]# crm_mon -1 -Af
>>> Last updated: Tue Feb 18 18:07:58 2014
>>> Last change: Tue Feb 18 18:05:46 2014 via crmd on srv01
>>> Stack: corosync
>>> Current DC: srv01 (3232238180) - partition with quorum
>>> Version: 1.1.10-9d39a6b
>>> 2 Nodes configured
>>> 6 Resources configured
>>> 
>>> 
>>> Online: [ srv01 srv02 ]
>>> 
>>>   Master/Slave Set: msPostgresql [pgsql]
>>>       Masters: [ srv01 ]
>>>       Slaves: [ srv02 ]
>>>   Clone Set: clnPingd [prmPingd]
>>>       Started: [ srv01 srv02 ]
>>> 
>>> Node Attributes:
>>> * Node srv01:
>>>      + default_ping_set                  : 100
>>>      + master-pgsql                      : 10
>>> * Node srv02:
>>>      + default_ping_set                  : 100
>>>      + master-pgsql                      : 5
>>> 
>>> Migration summary:
>>> * Node srv01:
>>>     vip-master: migration-threshold=1 fail-count=1 last-failure='Tue Feb 18
>>>     18:07:50 2014'
>>> * Node srv02:
>>> 
>>> Failed actions:
>>>      vip-master_monitor_10000 on srv01 'not running' (7): call=30,
>>>      status=complete, last-rc-change='Tue Feb 18 18:07:50 2014', queued=0ms,
>>>      exec=0ms
>>> -------------------------------------
>>> 
>>> However, the resource does not fail-over.
>>> 
>>> But, fail-over is calculated when I check cib in crm_simulate at this point
>>> in time.
>>> 
>>> -------------------------------------
>>> [root at srv01 ~]# crm_simulate -L -s
>>> 
>>> Current cluster status:
>>> Online: [ srv01 srv02 ]
>>> 
>>>   vip-master     (ocf::heartbeat:Dummy): Stopped
>>>   vip-rep        (ocf::heartbeat:Dummy): Stopped
>>>   Master/Slave Set: msPostgresql [pgsql]
>>>       Masters: [ srv01 ]
>>>       Slaves: [ srv02 ]
>>>   Clone Set: clnPingd [prmPingd]
>>>       Started: [ srv01 srv02 ]
>>> 
>>> Allocation scores:
>>> clone_color: clnPingd allocation score on srv01: 0
>>> clone_color: clnPingd allocation score on srv02: 0
>>> clone_color: prmPingd:0 allocation score on srv01: INFINITY
>>> clone_color: prmPingd:0 allocation score on srv02: 0
>>> clone_color: prmPingd:1 allocation score on srv01: 0
>>> clone_color: prmPingd:1 allocation score on srv02: INFINITY
>>> native_color: prmPingd:0 allocation score on srv01: INFINITY
>>> native_color: prmPingd:0 allocation score on srv02: 0
>>> native_color: prmPingd:1 allocation score on srv01: -INFINITY
>>> native_color: prmPingd:1 allocation score on srv02: INFINITY
>>> clone_color: msPostgresql allocation score on srv01: 0
>>> clone_color: msPostgresql allocation score on srv02: 0
>>> clone_color: pgsql:0 allocation score on srv01: INFINITY
>>> clone_color: pgsql:0 allocation score on srv02: 0
>>> clone_color: pgsql:1 allocation score on srv01: 0
>>> clone_color: pgsql:1 allocation score on srv02: INFINITY
>>> native_color: pgsql:0 allocation score on srv01: INFINITY
>>> native_color: pgsql:0 allocation score on srv02: 0
>>> native_color: pgsql:1 allocation score on srv01: -INFINITY
>>> native_color: pgsql:1 allocation score on srv02: INFINITY
>>> pgsql:1 promotion score on srv02: 5
>>> pgsql:0 promotion score on srv01: 1
>>> native_color: vip-master allocation score on srv01: -INFINITY
>>> native_color: vip-master allocation score on srv02: INFINITY
>>> native_color: vip-rep allocation score on srv01: -INFINITY
>>> native_color: vip-rep allocation score on srv02: INFINITY
>>> 
>>> Transition Summary:
>>>   * Start   vip-master   (srv02)
>>>   * Start   vip-rep      (srv02)
>>>   * Demote  pgsql:0      (Master -> Slave srv01)
>>>   * Promote pgsql:1      (Slave -> Master srv02)
>>> 
>>> -------------------------------------
>>> 
>>> In addition, fail-over is calculated even if "cluster_recheck_interval" is
>>> carried out.
>>> 
>>> Fail-over is carried out even if I carry out cibadmin -B.
>>> 
>>> -------------------------------------
>>> [root at srv01 ~]# cibadmin -B
>>> 
>>> [root at srv01 ~]# crm_mon -1 -Af
>>> Last updated: Tue Feb 18 18:21:15 2014
>>> Last change: Tue Feb 18 18:21:00 2014 via cibadmin on srv01
>>> Stack: corosync
>>> Current DC: srv01 (3232238180) - partition with quorum
>>> Version: 1.1.10-9d39a6b
>>> 2 Nodes configured
>>> 6 Resources configured
>>> 
>>> 
>>> Online: [ srv01 srv02 ]
>>> 
>>>   vip-master     (ocf::heartbeat:Dummy): Started srv02
>>>   vip-rep        (ocf::heartbeat:Dummy): Started srv02
>>>   Master/Slave Set: msPostgresql [pgsql]
>>>       Masters: [ srv02 ]
>>>       Slaves: [ srv01 ]
>>>   Clone Set: clnPingd [prmPingd]
>>>       Started: [ srv01 srv02 ]
>>> 
>>> Node Attributes:
>>> * Node srv01:
>>>      + default_ping_set                  : 100
>>>      + master-pgsql                      : 5
>>> * Node srv02:
>>>      + default_ping_set                  : 100
>>>      + master-pgsql                      : 10
>>> 
>>> Migration summary:
>>> * Node srv01:
>>>     vip-master: migration-threshold=1 fail-count=1 last-failure='Tue Feb 18
>>>     18:07:50 2014'
>> 
>> You have resource-stickiness=INFINITY, this is what is preventing the failover from occurring. Set resource-stickiness=1 or 0 and the failover should occur.
>> 
>> -- Vossel
>> 
>>> * Node srv02:
>>> 
>>> Failed actions:
>>>      vip-master_monitor_10000 on srv01 'not running' (7): call=30,
>>>      status=complete, last-rc-change='Tue Feb 18 18:07:50 2014', queued=0ms,
>>>      exec=0ms
>>> 
>>> -------------------------------------
>>> 
>>> It is a problem to be behind with practice of fail-over.
>>> I think that the cause that fail-over is late for from error is Pacemaker.
>>> 
>>> I registered these contents and log information with Bugzilla.
>>>   * http://bugs.clusterlabs.org/show_bug.cgi?id=5197
>>> 
>>> Best Regards,
>>> Hideo Yamauchi.
>>> 
>>> 
>>> _______________________________________________
>>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>> 
>>> Project Home: http://www.clusterlabs.org
>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>> Bugs: http://bugs.clusterlabs.org
>>> 
>> 
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20140219/67b0a74f/attachment-0004.sig>


More information about the Pacemaker mailing list