Before Forcing a Quorum

When a persistence cluster contains enough reachable persistence services, but not enough non-empty services 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 service.
  • If none of the unreachable services are running, it is safe to force a quorum.
  • If any services are actually running but unreachable, then it is not safe to force a quorum. Those services 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 service history state to determine whether it is safe to force a quorum. History state information that appears in the monitoring interface and in persistence service log output is not accurate enough for this purpose.

Example: Persistence Services, Forcing a Quorum

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

Persistence Services: Forcing a Quorum

The two reachable services 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" in Quorum Behaviors