GitHub Enterprise Server Rebuilds Search Architecture with Elasticsearch CCR

GitHub has resolved a long-standing search infrastructure problem in Enterprise Server's high-availability (HA) deployments. The previous architecture clustered primary and replica servers together on a single Elasticsearch cluster, which could deadlock during maintenance: if a replica went down, Elasticsearch couldn't become healthy until that node rejoined, sometimes leaving the entire installation locked. Engineers spent years mitigating this with health checks, drift correction, and even an attempted mirroring system, but distributed database replication proved too fragile for lasting consistency.

The fix leverages Elasticsearch's Cross Cluster Replication (CCR) feature. Under the new design, each Enterprise Server node runs as an independent single-node Elasticsearch cluster, and data is only replicated after it's durably persisted to Lucene segments—eliminating scenarios where critical data ends up stranded on read-only replicas. Since CCR's auto-follow API only covers newly created indexes, GitHub built a bootstrap process to manually attach followers to existing long-lived indexes before enabling auto-follow, along with custom workflows for failover, index deletion, and upgrades that Elasticsearch doesn't handle natively.

The new HA mode debuts as opt-in starting with release 3.19.1; administrators must contact GitHub support for a license and set the `ghe-config app.elasticsearch.ccr true` flag before upgrading. GitHub plans to make CCR the default over the next two years while gathering feedback. For engineers managing Enterprise Server, the practical payoff is that maintenance and upgrades on HA clusters no longer risk corrupting or locking search indexes.