Cases2 cases

1 to 2 of 2

1. IL-0444 Reader connections to Repro's Aurora MySQL cluster were cut with Lost connection errors every time ALTER TABLE ran

   Repro2024

   Symptoms

   After Repro moved to Aurora MySQL 5.7, running an ALTER TABLE in production, even one that finished in under a second, made the processes reading that table fail with `Lost connection to MySQL server during query`. MySQL client connections were cut right after the ALTER TABLE ran, and many application errors followed. By 8 January 2021 this had happened three times in a row.

   Connection resetsHigh error rate

   Trigger

   Running ALTER TABLE on the Aurora MySQL writer while readers were running queries that used the same table.

   Root cause

   Breaking change in an upgrade

   Component

   Database

   Contributing factor

   Unrepresentative staging

   Remediation

   • Made the applications retry once after a connection error, with a monkey patch in the Rails applications

   View case
2. IL-0443 A Repro Aurora MySQL reader restarted unexpectedly and writer insert latency rose about sevenfold for a day or more

   Repro2019

   Symptoms

   A reader of Repro's Aurora MySQL cluster restarted for no known reason, and right after that the writer's insert latency rose to about seven times normal and writer performance stayed badly degraded for a long time. This happened more than once, twice within two weeks by 11 November 2019. While the writer was slow, the applications that process data collected by the Repro SDK fell behind, and the team could only watch until the writer recovered.

   High latencyReplication lagThroughput degradation

   Trigger

   Long-running queries on the reader; the author recalls that the cause was a query sent to the reader from Redash.

   Root cause

   Capacity exhaustion

   Component

   DatabaseDatabase replication

   Contributing factor

   Monitoring blind spot

   Remediation

   • Waited for writer performance to return, since the rollback segment release could not be sped up

   Action items

   • Add a monitor on the rollback segment, mysql.innodb.history_list_length in Datadog
   • Kill queries that run long enough to make the reader restart as soon as they are found
   • Set max_execution_time so queries are stopped after a fixed time

   Lessons

   Once the rollback segment has grown large, nothing speeds up its release across the cluster, so the way to avoid the latency is to keep transactions small and stop long-running queries before the rollback segment grows.

   View case

By root cause2