On 2008-02-21T15:08:52, Doug Lochart <[EMAIL PROTECTED]> wrote:
> > > after the negotiating phase. Alert someone about this incident.
> > > pri-lost "echo pri-lost. Have a look at the log files. | mail -s
> > > 'DRBD Alert' [EMAIL PROTECTED]";
> > >
> > > This just tells me that this node was primary and now is in secondary.
> > > Before it becomes primary again it needs to be the target
> > > of a sync. Here I simply send an email notifying me that this happened.
> > >
> > > What I do not understand is how does the sync materialize? I assume
> > > that this is always manual task?
> >
> > It happens automatically, and it means the primary gets data
> > overwritten, which is rather bound to upset the applications/fs on top.
>
> Forgive me if I am misinterpreting your comment but you do not sound
> happy that it happens automatically. I don't want a corrupt fs
> either. So what _should_ I do ? I am getting really confused. On one
> hand it looks like many things are automated with heartbeat and drbd
> but then it seems like automation is causing more problems.
The above scenario should _never_ happen on a cluster with fencing
working. It can only occur if both sides where primary, if I'm not
mistaken.
> When a primary node goes down _hard_ and a secondary takes over there
> is no telling what the state of the shared resource is in between both
> nodes. Assuming the secondary is OK it will be come primary but the
> old primary has a drbd partition in an unknown state. When it comes
> back online then what does one do?
It becomes secondary first and resyncs, which is fine. Because it has a
connection to the node with good data, it can even be promoted to
primary safely, though the cluster prefers to run the primary on the
SyncSource.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
