Documented incidentIncident 2018-10-21GitHubEngineering postmortem

43-second network partition triggers database failover and unreplicated writes (GitHub, 2018)

Network maintenance caused a 43-second loss of connectivity between GitHub's US East Coast hub and its primary data center, which led to 24 hours and 11 minutes of degraded service.

What happened

  • Orchestrator failed MySQL primaries over to the West Coast while the East Coast still held writes that had not replicated, leaving data inconsistent and preventing a safe failback.October 21 post-incident analysis
  • Recovery involved restoring from backups, resynchronising replicas and manually reconciling about 954 unreplicated writes per affected cluster.October 21 post-incident analysis

The failure pattern

Watch the pattern: Partial success leaves systems out of sync

Safeguards that address it

CollectSEA's engineering analysis of what would have prevented or contained this failure.

  • Make automatic failover aware of replication stateDo not promote a replica in another region unless it has the writes the old primary acknowledged, or fence the old primary first.
  • Plan for split-brain reconciliationKeep tooling and runbooks for detecting and reconciling divergent writes after a partition.

Related standards

CollectSEA's mapping through this incident's failure pattern; not an official determination by the standards bodies.

Building something similar?

Describe your design and see every precedent that applies, with safeguards you can hand to your coding agent.

Analyze your design