Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, We have been using DRBD V8 and are in the process of moving to V9. To be exact: "version: 9.0.1-1 (api:2/proto:86-111) GIT-hash: 86e443973082570aeb651848db89e0c7b995c306 build by abuild)" One difference that we see is that if configured with "allow-two-primaries no" and when there is a network disconnect that ends up in two [disconnected] primaries neither of them will go into "StandAlone" connection state when the network is reconnected. Instead both nodes stay in state "Connecting" and refuses to connect with the error: "Multiple primaries not allowed by config" Due to this, the disk state is never compared and no split brain logic is triggered. Is this a bug or a feature with V9 ? If this is expected behaviour, what is the new way of detecting that we have two primaries ? One [hackish] workaround is to dynamically temporarily allow two primaries while in state "Connecting" but that does not feel right. /Per The V9 documentation has this in it: "DRBD detects split brain at the time connectivity becomes available again and the peer nodes exchange the initial DRBD protocol handshake. If DRBD detects that both nodes are (or were at some point, while disconnected) in the primary role, it immediately tears down the replication connection. The tell-tale sign of this is a message like the following appearing in the system log: Split-Brain detected, dropping connection! After split brain has been detected, one node will always have the resource in a StandAlone connection state. The other might either also be in the StandAlone state (if both nodes detected the split brain simultaneously), or in WFConnection (if the peer tore down the connection before the other node had a chance to detect split brain)." -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20170102/00c28e84/attachment.htm>