Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Thanks for the reply. I haven't had this happen on its own. I was just testing by pulling the network cable to see if everything would failover and noticed it when the other server came back up. Also to manually resync them I just issue the command drbdadm invalidate "r0" or whatever your resource is. Is this the wrong way to do it? Lars Ellenberg wrote: > On Thu, Aug 09, 2007 at 09:39:51AM +0200, Pierguido wrote: > >> James Wilson wrote: >> >>> Hey All, >>> >>> I am running DRBD 8.0.3 in primary/primary mode. I tested my cluster >>> this morning by pulling the plug on one of the DRBD servers everything >>> worked out fine but when the server comes back up it doesn't resync and >>> is in secondary state for some devices and unknown for others. How can I >>> have the devices sync up and then become primary/primary again? Thanks >>> for any advice. >>> >> I have the same problem...i tried some things but nothing worked out. >> Is there a sequence of command to do in these cases? >> Thanks >> > > you could configure some "auto-recovery strategies", see after-sb-#pri > settings in drbd.conf. > > to get them reconnected and resynchronized manually, > you'd have to typically > chose one side to do > umount > drbdadm -- --discard-my-data connect XY > and maybe on the other side do normal > drbdadm connect XY > > we are going to make this less annoying than it is now by introducing a > write_quorum and IO-freeze on disconnect, then we can timeout for a > possible imminent reconnect (network hiccup only), and after that > timeout arbitrate (triggered by the cluster manager) which side may > continue, and which has to be fenced (or let it self-fence...). > > but for the time being, yes, I know, two-primaries is still "inconvenient" > when you have a flaky network. > >