Cases4 cases

1 to 4 of 4

1. IL-0544 Wasabi's database cache stopped responding when its queueing service filled up, and S3 failed in all regions

   Wasabi2024

   Symptoms

   From 10:32 UTC on 6 August 2024, Wasabi's S3 service and user services failed in every region: users had trouble logging into the Web Console and requests to Wasabi regions returned errors.

   Service outageFailover failureIntermittent timeouts

   Trigger

   At 10:32 UTC on 6 August, Wasabi's queueing service reached full capacity, and that made the database cache unresponsive.

   Root cause

   Capacity exhaustion

   Component

   Message brokerIn-memory cacheDatabase

   Contributing factor

   –

   Remediation

   • Restarted the primary database to clear stale connections and cleared the queueing service's queue at the same time, which did not fully restore the database
   • Promoted the secondary database instance to primary, after which S3 was fully operational at 11:20 UTC
   • Restarted the database again between 13:17 and 13:23 UTC to fully incorporate the queueing service library
   • Promoted the original primary database back to production on 7 August, which stopped the user service timeouts
   • Recreated and redeployed the automation cluster that the automation service could not see, which fully restored S3

   View case
2. IL-0291 GitLab.com's redis-sidekiq Sentinel could not elect a primary after a GCP host error, so Sidekiq was down for 30 minutes

   GitLab2023

   Symptoms

   GitLab.com showed widespread, erratic behaviour and more 500 errors for about 30 minutes while its redis-sidekiq Redis was down. Alerts in the #production channel began with Redis client errors and spread to error SLO violations on several services, such as the Webservice and API load balancer and Puma.

   Failover failureHigh error rate

   Trigger

   The VM of the primary node, redis-sidekiq-03-db-gprd, failed on a GCP host error and was reset and moved to another node.

   Root cause

   Cloud provider outage

   Component

   In-memory cacheDatabase failover manager

   Contributing factor

   Single point of failureMonitoring blind spot

   Detection

   Several alerts in the #production channel, first Redis client errors and then error SLO violations on several services, such as the Webservice and API load balancer and Puma.

   Remediation

   • Restarted the failed Redis node so Sentinel had enough nodes to elect a primary

   Action items

   • Alert when the Sentinel service is down
   • Make merge requests robust to Redis Sidekiq outages

   Lessons

   An alert on a down Sentinel node would have kept enough nodes up to form a quorum when failover was needed, and could have avoided the incident entirely. Removing a noisy alert earlier may have let the down node go unnoticed.

   View case
3. IL-0388 A Google Cloud live migration took a Discord Redis primary offline, and the failover broke API instances and then guilds

   Discord2017

   Symptoms

   At about 14:01 PDT on 13 October 2017, Discord engineers were alerted to anomalies by real-time metrics and monitoring. A Redis instance that was the primary of a highly available cluster used by the API services had dropped offline after Google Cloud Platform migrated it automatically, and some API instances did not handle the failover to the secondary node correctly.

   Failover failureHigh latencyService outage

   Trigger

   Google Cloud Platform automatically migrated the Redis instance that was the primary of a highly available cluster used by the API services, and the node incorrectly dropped offline.

   Root cause

   Software defect

   Component

   In-memory cacheDatabaseCDN and edge network

   Contributing factor

   Unpatched known bugOverlapping failuresMonitoring blind spot

   Detection

   Real-time metrics and monitoring alerted engineers at 14:01 PDT. The second phase was seen at 15:41 as another anomaly in monitoring, and end user reports of servers appearing offline were escalated at 15:42.

   Remediation

   • Ran a rolling restart of all API instances to clear the Redis connection issues
   • Corrected the misconfigured edge caching rule for the expensive API route
   • Disabled the problem API endpoint on the edge network
   • Recovered the Cassandra cluster
   • Ran a second rolling restart of all API instances for the latency left by the Cassandra issues
   • Removed the misbehaving guilds node from the service hashring
   • Forcefully restarted the misbehaving guilds node
   • Restarted the whole service, forcing all users to reconnect
   • Blocked traffic that relied on the failing push component to reduce its load
   • Corrected the API setting that lets users reconnect quickly and safely

   Action items

   • Fix the known issues with Redis failover within the coming weeks
   • Change the cached route so this type of error does not degrade other services
   • Monitor the signals that would have warned of the cascading failure
   • Improve the reliability and failure handling of the affected services
   • Roll out an update of the library with the suspected flaws

   View case
4. IL-0278 A weekly update put a Redis Cloud management process into an infinite loop, and most nodes of a GCP cluster failed

   Redis2016

   Symptoms

   On 8 February 2016 at 17:45 UTC, four nodes of the Redis Cloud cluster us-central1-1-1.gce.garantiadata.com on Google Cloud Platform stopped responding, four minutes after a first node had failed. The databases whose endpoints end in us-central1-1-1.gce.garantiadata.com went down.

   Service outageFailover failure

   Trigger

   The weekly upgrade of Redis Cloud's non-critical cluster components reached its first Google Cloud Platform cluster, us-central1-1-1.gce.garantiadata.com, at 17:30 UTC.

   Root cause

   Faulty deployment

   Component

   In-memory cacheDatabase failover managerAuthoritative DNS servers and records

   Contributing factor

   Overlapping failures

   Remediation

   • Shut down and terminated all nodes of the cluster
   • Deleted all of the cluster's endpoints from its DNS zone, removing by hand the entries left by throttled deletes
   • Provisioned new cluster nodes from scratch without the weekly update
   • Reconnected the original nodes' storage to the new nodes so persistence-enabled databases could be recovered
   • Bootstrapped and launched the databases, recovering the ones with persistence from storage

   Action items

   • Suspend all automatic weekly upgrades until a procedure that prevents this kind of outage is in place
   • Revalidate the QA processes for DevOps code deployments
   • Improve the tooling so it handles throttling of DNS requests

   View case

By root cause4