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.

Check Safety

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

Determine the process status of each unreachable service.

If all of the reachable services are not running, and have no disk persistence state, it is safe to force a quorum.
If any services are actually running but unreachable, or are not running but have disk persistence state, 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.