Network & Infrastructure / High Availability & Recovery Design
Split-brain recovery when both sides claim ownership
After a network partition, two isolated service instances appear active. Reconnecting them blindly can expose shared data or clients to conflicting state and uncertain ownership.
Environment and inputs: Routed and clustered services; define failure ownership, fencing and application recovery requirements before testing. Diagnostic/design example; not tested on production equipment.
Collect the evidence
Preserve each side's membership, resource ownership, fencing evidence and application state. Establish which side, if either, has the authoritative committed history according to the supported recovery model.
Explain the result
Split brain is an ownership and consistency problem, not merely a connectivity outage. Restoring the network does not automatically reconcile conflicting writes or make either side safe to discard.
Plan the fix
Follow the platform's documented conflict recovery process with the application and data owners. Establish exclusion before selecting or reconciling state, avoiding improvised deletion of the apparently older copy.
Check the result and rollback
Validate one authoritative owner, data consistency and prevention of recurrence before restoring automation. Halt if the available evidence cannot establish a supported reconciliation path.