Cases3 cases

1 to 3 of 3

1. IL-0462 Some MySQL pods on Shopify's GKE clusters took up to 30 minutes to start, slowing instance replacement

   Shopify2021

   Symptoms

   In 2021 Shopify's KateSQL, a database-as-a-service platform that runs several hundred production MySQL instances on GKE, found that some MySQL pods started and shut down much more slowly than similar pods with the same data set. Instance replacement, the procedure that creates a new MySQL replica pod and stops the old one, showed pod creation times ranging from 10 to 30 minutes, which held up maintenance such as configuration changes and upgrades.

   Slow pod startup or shutdownHigh latency

   Root cause

   Software defect

   Component

   Linux kernelNode operating system imageDatabase

   Contributing factor

   Unpatched known bug

   Detection

   KateSQL's instance replacement operations showed inconsistent MySQL pod creation times, and the team then measured the mysql-init container and MySQL startup times across pods.

   Remediation

   • Cordoned older nodes, moved MySQL pods to new nodes through instance replacement and drained the old nodes
   • Forced the kubepods memory cgroup to empty its dead cgroups on an affected node to test the fix
   • Created new GKE 1.18 clusters and started creating MySQL pods on them

   Lessons

   The investigation was one of the longest the Database Platform group had carried out, because of the nature of the problem, how hard it was to reproduce and the lack of an established method to follow; once the cause was known, there were several ways to fix it.

   View case
2. 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
3. IL-0454 Baemin billing servers could not open new MariaDB connections at the start of a card-discount event

   Woowa Brothers2016

   Symptoms

   At 18:00, when a card-company event giving 3,000 won off to the first 1,000 customers started, the Pinpoint graph of the Baemin billing system turned red shortly afterwards: 140 of 14,000 requests failed in about one minute. Most errors looked like requests from the billing system that the payment gateway (PG) did not receive because of a network problem, but other errors pointed at the billing system itself.

   High error rateIntermittent connection failures

   Trigger

   A card-company discount event for the first 1,000 customers started at 18:00 and sent about 14,000 requests to the billing system in about one minute.

   Root cause

   Software defect

   Component

   DatabaseClient-side DNS resolver and cache

   Contributing factor

   Unpatched known bug

   Detection

   The team was watching NewRelic and Pinpoint during the 18:00 event, and the Pinpoint graph turned red shortly after the event began.

   Remediation

   • Changed the Gradle settings to use mariadb-connector-j 1.5.5 instead of 1.4.6

   Lessons

   A new DB connection failed because the driver did a DNS lookup of the local host name that took about 6 seconds, longer than the server's 5-second connect_timeout. Other ways to avoid it are to use localhost as the host name or to register the IP address and host name in /etc/hosts so the address is returned first. Above all, the author recommends keeping libraries on recent versions.

   View case

By root cause1