With MGS followers (LU-19916) and dynamic MGS NID discovery (LU-19917), a client MGC is connected to exactly one MGS (MGS0 or a follower) at a time. If that MGS goes away, the client has to notice and reconnect to another one before it misses imperative recovery (IR) notifications or config log updates, which is why patch https://review.whamcloud.com/66529 ("LU-19917 mgc: dynamic MGS NIDs discovery") shortens the client MGC ping interval when followers exist.

Instead, a client could keep connections to two different MGS services (e.g. MGS0 and a follower, or two followers) at once, and take config lock revocations and IR notifications from whichever delivers first. Losing one MGS would then not delay updates, and the client would not need to rush to reconnect or ping the MGS more often.

Things to work out:

• how a client MGC holds two imports to different MGS NIDs, and which one it enqueues config/IR locks on (both, with deduplication of the log reads by index/version?);
• how to pick the second MGS so that the load spreads across followers, and avoid two followers on the same node;
• interaction with the "mgc<NID>" server MGC naming and the MGS NID list learned from the IR log;
• whether the extra connection and lock per client is acceptable on large clusters, or should be optional.