Ken Gaillot wrote:
On Thu, 2017-11-30 at 11:58 +, Adam Spiers wrote:
Ken Gaillot wrote:
On Wed, 2017-11-29 at 14:22 +, Adam Spiers wrote:
[snipped]
Let's suppose further that the cluster configuration is such
that no stateful resources
On Fri, 2017-12-01 at 16:21 -0600, Ken Gaillot wrote:
> On Thu, 2017-11-30 at 11:58 +, Adam Spiers wrote:
> > Ken Gaillot wrote:
> > > On Wed, 2017-11-29 at 14:22 +, Adam Spiers wrote:
> > > > Hi all,
> > > >
> > > > A colleague has been valiantly trying to help me
On Thu, 2017-11-30 at 11:58 +, Adam Spiers wrote:
> Ken Gaillot wrote:
> > On Wed, 2017-11-29 at 14:22 +, Adam Spiers wrote:
> > > Hi all,
> > >
> > > A colleague has been valiantly trying to help me belatedly learn
> > > about
> > > the intricacies of startup
Ken Gaillot wrote:
On Wed, 2017-11-29 at 14:22 +, Adam Spiers wrote:
Hi all,
A colleague has been valiantly trying to help me belatedly learn
about
the intricacies of startup fencing, but I'm still not fully
understanding some of the finer points of the behaviour.
On Thu, Nov 30, 2017 at 1:39 PM, Gao,Yan wrote:
> On 11/30/2017 09:14 AM, Andrei Borzenkov wrote:
>>
>> On Wed, Nov 29, 2017 at 6:54 PM, Ken Gaillot wrote:
>>>
>>>
>>> The same scenario is why a single node can't have quorum at start-up in
>>> a cluster with
On 11/30/2017 09:14 AM, Andrei Borzenkov wrote:
On Wed, Nov 29, 2017 at 6:54 PM, Ken Gaillot wrote:
The same scenario is why a single node can't have quorum at start-up in
a cluster with "two_node" set. Both nodes have to see each other at
least once before they can
On Wed, Nov 29, 2017 at 6:54 PM, Ken Gaillot wrote:
>
> The same scenario is why a single node can't have quorum at start-up in
> a cluster with "two_node" set. Both nodes have to see each other at
> least once before they can assume it's safe to do anything.
>
Unless we set
On 11/29/2017 09:09 PM, Kristoffer Grönlund wrote:
> Adam Spiers writes:
>
>> OK, so reading between the lines, if we don't want our cluster's
>> latest config changes accidentally discarded during a complete cluster
>> reboot, we should ensure that the last man standing is also
Adam Spiers writes:
>
> OK, so reading between the lines, if we don't want our cluster's
> latest config changes accidentally discarded during a complete cluster
> reboot, we should ensure that the last man standing is also the first
> one booted up - right?
That would make
Kristoffer Gronlund wrote:
Adam Spiers writes:
Kristoffer Gronlund wrote:
Adam Spiers writes:
- The whole cluster is shut down cleanly.
- The whole cluster is then started up again. (Side question: what
Klaus Wenninger wrote:
On 11/29/2017 04:23 PM, Kristoffer Grönlund wrote:
Adam Spiers writes:
- The whole cluster is shut down cleanly.
- The whole cluster is then started up again. (Side question: what
happens if the last node to shut down is not
Kristoffer Gronlund wrote:
Adam Spiers writes:
- The whole cluster is shut down cleanly.
- The whole cluster is then started up again. (Side question: what
happens if the last node to shut down is not the first to start up?
How will the cluster
On 11/29/2017 04:54 PM, Ken Gaillot wrote:
On Wed, 2017-11-29 at 14:22 +, Adam Spiers wrote:
The same questions apply if this troublesome node was actually a
remote node running pacemaker_remoted, rather than the 5th node in
the
cluster.
Remote nodes don't join at the crmd level as
On Wed, 2017-11-29 at 14:22 +, Adam Spiers wrote:
> Hi all,
>
> A colleague has been valiantly trying to help me belatedly learn
> about
> the intricacies of startup fencing, but I'm still not fully
> understanding some of the finer points of the behaviour.
>
> The documentation on the
On 11/29/2017 04:23 PM, Kristoffer Grönlund wrote:
> Adam Spiers writes:
>
>> - The whole cluster is shut down cleanly.
>>
>> - The whole cluster is then started up again. (Side question: what
>> happens if the last node to shut down is not the first to start up?
>> How
Adam Spiers writes:
> - The whole cluster is shut down cleanly.
>
> - The whole cluster is then started up again. (Side question: what
> happens if the last node to shut down is not the first to start up?
> How will the cluster ensure it has the most recent version of the
16 matches
Mail list logo