Cases33 cases

28 to 32 of 33

1. IL-0296 Transloadit's us-east Redis cluster lost queued jobs and heartbeats, raising WORKER_JOB_ERROR errors for 81 customers

   Transloadit2016

   Symptoms

   Reports came in of more WORKER_JOB_ERROR errors, which tell Transloadit there is a communication problem between its Uploaders, the machines that receive files and orchestrate Assemblies, and its Drones, the machines that run encoding tasks. Many Assemblies became much slower because retries with exponential back-off kicked in, and a few could not be replayed.

   High error rateHigh latencyLoad imbalance

   Trigger

   A steep increase in HLS traffic, together with more Drones online processing the same volume faster, which put more load on the central Redis nodes.

   Root cause

   Capacity exhaustion

   Component

   In-memory cacheDatabase replication

   Contributing factor

   Monitoring blind spotUnverified assumptionHarmful manual action

   Detection

   Reports of an increased number of WORKER_JOB_ERROR errors.

   Remediation

   • Re-added lost messages and relaxed heartbeat monitoring as a stopgap
   • Upgraded Redis to the latest stable version
   • Doubled the Redis cluster to six nodes and then added three more, which made it worse
   • Brought the number of read replicas down to one, which cut traffic and failure rates
   • Capped how far Drones scale up in each region

   Action items

   • Add logging and alarms for approaching saturation
   • Find ways to decentralise the traffic between the Redis nodes and the Drones and Uploaders
   • Add sharding per Uploader on top of the sharding per region

   Lessons

   To handle more traffic Transloadit had to use fewer Redis nodes, not more: each added replica multiplied the replication traffic from the single leader that takes every write, so scaling up the number of nodes was the wrong call. Bandwidth had not been among the monitored Redis metrics.

   View case
2. IL-0319 Dropping databases on the MySQL replica mysql2 also dropped them on mysql1, as the pair actually ran master-master

   Oregon State University Open Source Lab2015

   Symptoms

   On July 30th, a few minutes after the OSU Open Source Lab started reloading the MySQL server mysql2 to fix its replication errors, the team saw that databases were being dropped on mysql1 as well. The script was stopped, and the MySQL service behind mysql1-vip stayed down through a long restore.

   Data lossService outageReplication lag

   Trigger

   On July 30th at 4:00PM PDT the team stopped slave replication on mysql2 and began dropping its databases one at a time to reload it and fix replication errors.

   Root cause

   Operator error

   Component

   DatabaseDatabase replicationDatabase backups and snapshots

   Contributing factor

   Unverified assumptionUntested backup

   Detection

   The team watching the reload noticed after a few minutes that mysql1 was also dropping databases; the delays between drops in the script gave them that time.

   Remediation

   • Stopped the script that was dropping databases
   • Restored the databases from the mysql-zrm backups
   • Pulled each database that failed to restore out of the 200GB backup file and restored it separately
   • Recovered most data with the binary logs from the 17th through the 30th

   Action items

   • Evaluate better replication strategies, including row-based replication
   • Store binlogs as a backup on a separate server
   • Take backups with Percona XtraBackup for much faster full restores
   • Use mydumper instead of mysql-zrm for faster logical backups
   • Improve documentation and training for complex systems
   • Test full restores regularly on a spare server as part of the backup process
   • Gather more accurate time estimates for the restore process
   • Audit the hosted databases regularly, since test and very large databases delayed the restore
   • Migrate to a bigger, more powerful MySQL cluster
   • Set a policy and tools to keep the community informed of outages, maintenance and resource use, with dashboards
   • Define and monitor capacity limits for core services
   • Implement redundancy and restore practices for core services, including staff drills
   • Migrate more core services to Chef
   • Review documentation, policies and performance metrics periodically
   • Find better ways to draw on community expertise
   • Raise funds to replace the oldest infrastructure and reduce technical debt

   Lessons

   The lab had stretched its resources to host as many projects as possible, and that came with tradeoffs such as heavily compressed backups to save disk and less redundancy than wanted; the heavy compression made this restore CPU-bound. The lab concluded that it needs to change how it plans, monitors and manages resources, and that the length of the outage and the lack of progress reports were not acceptable.

   View case
3. IL-0590 F5 load balancers cached a path MTU of 296 after Rackspace reboots, and Mailgun connections failed intermittently

   Mailgun2014

   Symptoms

   On Saturday, September 27, 2014 at 6:50 p.m. UTC, Mailgun saw that all its database replicas and the internal traffic between its environments in all regions were broken and reporting timeouts. Once Rackspace began rebooting cloud instances in its Chicago data center (ORD), Mailgun customers had intermittent connection failures.

   Intermittent connection failuresIntermittent timeoutsPacket loss

   Trigger

   Rackspace, Mailgun's parent company and hosting provider, rebooted cloud instances in its Chicago data center (ORD), and the cloud maintenance triggered an error condition on Mailgun's F5 load balancers.

   Root cause

   DNS or network fault

   Component

   Cloud load balancerDatabase replication

   Contributing factor

   –

   Detection

   Mailgun noticed at 6:50 p.m. UTC on September 27 that all database replicas and the internal traffic between its environments were broken and reporting timeouts.

   Remediation

   • The Rackspace networking team cleared the cached path MTU on Mailgun's F5s and on some Rackspace dedicated customers' F5s
   • Set up a new virtual IP for Mailgun services
   • Changed Mailgun's DNS settings, which forced the remote F5s to clear their caches

   Action items

   • Finish the root cause analysis of the F5 path MTU problem with Rackspace
   • Make sure maintenance of Mailgun's cloud infrastructure has no impact on Mailgun customers

   View case
4. IL-0215 Twilio's billing Redis master lost all balances and went read-only, and auto-recharge charged customer cards repeatedly

   Twilio2013

   Symptoms

   At 2:39 AM PDT (9:39 UTC) on 18 July 2013, services that relied on the redis-master of Twilio's billing system began to fail because the load on its host had become extreme. At 2:42 AM PDT monitoring alerted the on-call engineers to a failure in the Redis cluster.

   Database overloadData lossWrites rejected

   Trigger

   At 1:35 AM PDT on 18 July a loss of network connectivity disconnected all billing redis-slaves from the redis-master at once, and all of them requested a full synchronization at the same time. On-call engineers then restarted the overloaded redis-master.

   Root cause

   Configuration change

   Component

   In-memory cacheDatabase replication

   Contributing factor

   Retry stormHarmful manual actionUnsafe failure behaviour

   Detection

   At 2:42 AM PDT monitoring alerted the on-call engineers to a failure in the Redis cluster. At 3:28 AM PDT the billing system monitoring reported the anomalous charges, and at 12:36 PM PDT monitoring detected the recurrence.

   Remediation

   • Restarted the redis-master to relieve the high load, which loaded a wrong configuration
   • Took the billing system offline to stop further credit card charges
   • Restored service to all suspended accounts
   • Restored the lost account balances from the independent double-bookkeeping record in the relational datastore
   • Took billing offline again after the recurrence and reactivated the newly suspended accounts
   • Refunded all erroneous credit card charges
   • Gave all affected accounts a credit of 10% of their last 30 days of spend
   • Replaced the original Redis cluster and corrected the redis-master configuration
   • Activated the billing system progressively for groups of customer accounts

   Action items

   • Disable Redis restarts on the redis-master and recover the master by pivoting a slave instead
   • Add fail-safes so the billing system neither suspends accounts nor charges cards when balances are missing or cannot be written
   • Validate the billing system against the double-bookkeeping databases in real time

   Lessons

   Losing the in-flight balances and the ability to write balances at the same time exposed a flaw in the auto-recharge system: it failed in a dangerous way, charging cards and suspending accounts instead of stopping.

   View case
5. IL-0589 Every Kickstarter MySQL replica on Amazon RDS stopped replicating on a duplicate-key error in the backings table

   Kickstarter2013

   Symptoms

   On Thursday, March 7th, all of Kickstarter's MySQL replicas on Amazon RDS stopped applying updates, not just one replica that could be replaced. Most of Kickstarter's traffic is served from these replicas, so the site ran on stale copies of the database.

   Replication lag

   Trigger

   A later unsafe query on the backings table made MySQL switch to row-based replication for that query, and replaying the full row on the replicas collided with sequence values that already differed from the primary.

   Root cause

   Software defect

   Component

   DatabaseDatabase replication

   Contributing factor

   –

   Detection

   The team saw that the replicas had stopped updating, and SHOW SLAVE STATUS showed the duplicate-key replication error.

   Lessons

   Databases are intricate. In the Rails community they are sometimes treated as simple data stores hidden behind ActiveRecord and ActiveRelation, and Kickstarter's engineers concluded that it pays to learn how the database carries out what it is asked to do.

   View case

By root cause11