Cases8 cases

7 to 8 of 8

1. IL-0387 Mailgun MongoDB secondaries were overloaded by rising connections, and a rollback then moved reads onto the primary too

   Mailgun2017

   Symptoms

   On 12 January 2017 at 14:09 UTC, Mailgun engineers began responding to alerts for the click and open tracking services and the primary MongoDB clusters in one production region. Within ten minutes the engineers found that the MongoDB secondary servers, which serve most reads, were under heavy load and slow to answer, which also caused the tracking errors. The status page reported intermittent timeouts on the Control Panel, API, SMTP and tracking links.

   Database overloadIntermittent timeoutsHigh error rate

   Trigger

   A gradual increase in connections to the MongoDB secondary servers, which coincided with several MongoDB configuration changes made the day before. A rollback of those changes then also introduced, by mistake, a change that moved the API and SMTP services from the secondaries to the primary.

   Root cause

   unknown

   Component

   Database

   Contributing factor

   Harmful manual actionSingle point of failure

   Detection

   Alerts for the click and open tracking services and the primary MongoDB clusters at 14:09 UTC.

   Remediation

   • Rolled back the previous day's MongoDB configuration changes through several pull requests from 15:15 UTC
   • Resized the MongoDB servers to handle more connections
   • Deployed connection limits at the MongoDB server level
   • Limited the number of connections the services could open to the MongoDB primary
   • Redeployed the configuration that makes services prefer secondary servers for reads

   Action items

   • Run the tracking infrastructure across two independent regions
   • Limit the number of connections every service can open to the database
   • Permanently increase the size of the primary Mongo cluster and roll the change out to the other data centers
   • Let click redirection keep working when downstream services fail

   View case
2. IL-0274 GitHub's code search Elasticsearch cluster hit near-100% CPU and rapid master elections; a restart found lost shards

   GitHub2013

   Symptoms

   On Thursday 24 January 2013 GitHub's exception tracking and monitoring systems detected a large spike in exceptions. Most of them were timeouts in code search queries and in the background jobs that update the code search indexes with data from new pushes, and the outage of the newly launched Code Search lasted into Friday 25 January.

   Intermittent timeoutsSustained high node CPUSplit brainData loss

   Trigger

   On 17 January GitHub upgraded the code search cluster from Elasticsearch 0.19.9 to 0.20.2 before launching Code Search publicly; the outage began on 24 January, after the public launch.

   Root cause

   Software defect

   Component

   Elasticsearch or OpenSearchLanguage runtime settings

   Contributing factor

   Unreviewed defaultsDeferred upgradesUntested changeIgnored early signalHarmful manual action

   Detection

   GitHub's exception tracking and monitoring systems detected a large spike in exceptions, mostly timeouts from code search queries and from the indexing background jobs.

   Remediation

   • Stopped the whole cluster and brought it back in maintenance mode, with shard allocation and rebalancing disabled
   • Brought in engineers from elasticsearch, the company, to review the cluster and its unallocatable shards
   • Upgraded Java and Elasticsearch and applied the recommended configuration through a Puppet topic branch and environment

   Action items

   • Provision a staging environment for the code search cluster to test infrastructure changes
   • Have the elasticsearch team audit the code search cluster configuration again in future

   Lessons

   The Elasticsearch upgrade was not tested enough on GitHub's infrastructure before it reached the code search cluster, partly because the cluster had no proper staging environment. For large clusters the elasticsearch team recommended equal minimum and maximum JVM heap through ES_HEAP_SIZE, at 50% of system RAM, starting recovery immediately instead of after recover_after_time, and configuring minimum_master_nodes so that paused nodes do not form their own clusters.

   View case

By root cause5