Before Forcing a Quorum

When a cluster contains enough reachable servers, but not enough non-empty servers to form a quorum, an administrator may force a quorum. Read this topic first.

Check Safety

Before forcing a quorum, first verify that it is safe to do so.

Determine the process status of each unreachable server.
  • If none of the unreachable servers are running, it is safe to force a quorum.
  • If any server processes are actually running but unreachable, then it is not safe to force a quorum. Those servers could contain more recent message data than the quorum candidates, and forcing a quorum would forfeit those messages.

    Instead, restore reachability by repairing the network problem. Then the quorum can reform itself without administrator intervention.

Note: Do not rely on server history state to determine whether it is safe to force a quorum. History state information that appears in the monitoring interface and in persistence server log output is not accurate enough for this purpose.

Example: Persistence Servers, Forcing a Quorum

Consider a persistence cluster that defines three servers. Only two servers are reachable. The third server is unreachable.

Persistence Servers: Forcing a Quorum

The two reachable servers cannot form a quorum because s2 is empty (see Quorum Conditions General Rule). If the administrator determines that s1 has actually exited, then it is safe to force a quorum. The administrator can explicitly force a quorum using the force quorum command icon in the cluster row of the persistence clusters status table.

If, on the other hand, s1 is still running, it could hold a more recent history state than s3 (the candidate with the most recent history state). Instead of forcing a quorum, the administrator should endeavor to repair the network problem that partitions s1 from the other candidates.

See Also: Force Quorum