Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi Martin, I would say self explanatory of DRBD users' guide ( http://www.drbd.org/users-guide-emb/re-drbdconf.html) and example drbd.conf file states: startup This section is used to fine tune DRBD's properties. Please refer to drbdsetup(8) for a detailed description of this section's parameters. Optional parameters: wfc-timeout, degr-wfc-timeout, wait-after-sb and become-primary-on. The thing that people usually realised too late is that default setting for wait-for-connection setting is 0 which means wait for peer connection forever or manual intervention. Such setting will block your boot up process in case DRBD service is started at boot up time. Re 2A) No, if you set reasonable wait for connection timeout interval. The same is true for your cluster manager here. Only node that has UpToDate data set can become Primary - it depends on how much changes with which speed have to be synced into B until it will become consistent and be able to be promoted into Primary role. Re 2B) The same as 2A, however DRBD will most likely detect split brain after devices get connected as there were changes on both nodes since disconnection. You are right, DOPD only works if there is at least one cluster manager communication path left when DRBD communication is interrupted. So when one node goes down immediately, there is no way to set its data as outdated. With regards. 2009/2/13 Martin Fick <mogulguy at yahoo.com> > I have a question about DRBD that has been bugging me for a while, perhaps > someone can help me? :) > > I am concerned about the "cluster boot" phase of drbd. What I mean is, I > am concerned about how to deal with both nodes in a cluster going down (not > necc. synchronously) and what happens after one or both of them comes back > up. > > It seems like most heartbeat/drbd combinations expect both nodes to come up > or they will (should?) not proceed to allow a node to become primary, is > this correct? > > In other words, suppose: > > 1) node A is primary and node B goes down. Node A stays primary and > continues to process writes. Eventually, node A then also goes down. > > > 2A) node A comes backup while B is still down. Node A will wait until it > communicates with node B and will not get promoted. When node B comes up, > either node may become primary. Is this correct? > > > 2B) node B comes backup while A is still down. Node B will wai until it > communicates with node A and will not get promoted. When node A comes up, > either node may become primary. Is this correct? > > > dopd seems like a neat feature to outdate a peer when communication is > lost, but it will not come into play in these situations, will it? > > Thanks, > > > -Martin > > > > > > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20090213/f44932bd/attachment.htm>