On Mon, 2014-10-13 at 12:51 +1100, Andrew Beekhof wrote:
>
> Even the same address can be a problem. That brief window where things were
> getting renewed can screw up corosync.
But as I proved, there was no renewal at all during the period of this
entire pacemaker run, so the use of DHCP here i
On 11 Oct 2014, at 1:35 am, Brian J. Murrell (brian)
wrote:
> On Wed, 2014-10-08 at 12:39 +1100, Andrew Beekhof wrote:
>> On 8 Oct 2014, at 2:09 am, Brian J. Murrell (brian)
>> wrote:
>>
>>> Given a 2 node pacemaker-1.1.10-14.el6_5.3 cluster with nodes "node5"
>>> and "node6" I saw an "unkno
On Wed, 2014-10-08 at 12:39 +1100, Andrew Beekhof wrote:
> On 8 Oct 2014, at 2:09 am, Brian J. Murrell (brian)
> wrote:
>
> > Given a 2 node pacemaker-1.1.10-14.el6_5.3 cluster with nodes "node5"
> > and "node6" I saw an "unknown" third node being added to the cluster,
> > but only on node5:
>
On 8 Oct 2014, at 2:09 am, Brian J. Murrell (brian)
wrote:
> Given a 2 node pacemaker-1.1.10-14.el6_5.3 cluster with nodes "node5"
> and "node6" I saw an "unknown" third node being added to the cluster,
> but only on node5:
Is either node using dhcp?
I would guess node6 got a new IP address (o
Given a 2 node pacemaker-1.1.10-14.el6_5.3 cluster with nodes "node5"
and "node6" I saw an "unknown" third node being added to the cluster,
but only on node5:
Sep 18 22:52:16 node5 corosync[17321]: [pcmk ] notice: pcmk_peer_update:
Transitional membership event on ring 12: memb=2, new=0, lost=