In the utility's FGCP cluster, the original primary unit fails and the secondary unit takes over as primary. A few hours later, the original unit is repaired and rejoins the cluster with its higher configured priority restored. The utility wants the cluster to keep the current secondary-turned-primary unit in charge, rather than automatically switching primary roles back the moment the repaired unit returns. What HA setting controls this behavior?

FGCP's override setting determines whether a returning unit with a higher configured device priority preempts the current primary and reclaims the primary role automatically. With override disabled, a repaired unit rejoining the cluster becomes a synchronized standby member without forcing a role change, even though its priority is technically higher than the current primary's — exactly the stable behavior the utility wants, avoiding an unnecessary second failover shortly after the first. With override enabled, the cluster instead preempts based on priority as soon as the higher-priority unit becomes available, the opposite of what's needed here. Heartbeat interface count relates to how many dedicated links carry HA heartbeat traffic for redundancy of the heartbeat mechanism itself; it plays no role in deciding whether a unit preempts another. Device priority alone, without the override setting, doesn't fully determine role assignment on rejoin — priority establishes rank, but override determines whether that rank is actually acted upon. Session pickup determines whether existing sessions survive a failover; it doesn't influence which unit holds the primary role afterward. To confirm the setting is correct, check that override is disabled on both cluster members and observe that the repaired unit does not reclaim primary status upon rejoining.