{"id":"IL-0444","org":"Repro","date":"2024-10-23","docs":[],"title":{"en":"Reader connections to Repro's Aurora MySQL cluster were cut with Lost connection errors every time ALTER TABLE ran","ko":"Aurora MySQL 에서 ALTER TABLE 을 실행할 때마다 그 테이블을 reader 로 읽던 커넥션이 끊겨 애플리케이션 오류가 쏟아졌다"},"domain":["database","aws"],"impact":{"scope":"Application processes that read a table through an Aurora reader while ALTER TABLE ran on it got connection errors","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://tech.repro.io/entry/2024/10/23/085610","kind":"blog","archived":"https://web.archive.org/web/20260805141333/https://tech.repro.io/entry/2024/10/23/085610"}],"summary":{"en":"Every schema change on Repro's Aurora MySQL cluster caused application errors from the time the cluster was on Aurora MySQL 5.7: an ALTER TABLE on the writer cut the reader connections that were reading the altered table, and the clients saw `Lost connection to MySQL server during query`. The development cluster had no reader, so the failure could not be reproduced until one was added. AWS Support explained that this is documented behaviour: DDL on the primary interrupts Aurora Replica connections that are using the changed object.\n\nRepro made the applications retry once after a connection error. For the Rails applications, a monkey patch module ActiveRecord::RetryOnLostConnection prepended to ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter catches ActiveRecord::StatementInvalid whose message includes \"Lost connection to MySQL server\", logs a warning, reconnects and retries the query one time. It does not retry inside an open transaction, because a retry in a new reader session could return a different result than the earlier reads of the same transaction, and it does not retry on the writer connection. The patch has since been refined by other engineers.\n\nRepro also mentions a separate problem with the same trigger: during an ALTER TABLE, a reader can briefly fail to see the altered table and return \"Error 1146: Table '...' doesn't exist\". That one is a bug, fixed in Aurora MySQL 3.05.0.","ko":"Repro 는 Aurora MySQL 을 쓴다. Aurora MySQL 5.7 로 올린 뒤 운영 환경에서 ALTER TABLE 을 실행할 때마다, 대상 테이블을 reader 로 읽던 MySQL 클라이언트의 커넥션이 끊겨 Lost connection to MySQL server during query 오류가 대량으로 났다. 2021년 1월 8일까지 세 번 연속 일어났다. reader 가 없는 개발 환경에서는 재현되지 않았고, 개발 클러스터에 reader 를 더하자 재현됐다.\n\nAWS 지원팀은 이것이 버그가 아니라 Aurora 가 원래 그렇게 동작하는 것이라고 알려 줬다. Aurora 문서에 따르면 primary 인스턴스에서 실행한 DDL 문은 Aurora Replica 의 데이터베이스 커넥션을 끊을 수 있다. Aurora Replica 의 커넥션이 쓰고 있는 테이블 같은 객체를 primary 인스턴스가 DDL 문으로 바꾸면 그 커넥션이 끊긴다. 팀은 애플리케이션이 커넥션 오류를 받으면 한 번만 재시도하게 했다. Rails 애플리케이션에는 ActiveRecord 의 execute 에 몽키 패치를 적용했다. 트랜잭션 밖의 reader 쿼리가 \"Lost connection to MySQL server\" 로 실패하면 reconnect! 로 다시 연결한 뒤 한 번 더 실행한다. 트랜잭션 안의 쿼리는 다시 실행하면 결과가 바뀔 수 있어 재시도하지 않는다.\n\n글은 비슷한 버그도 하나 소개했다. ALTER TABLE 을 실행하면 reader 에서 대상 테이블이 잠시 보이지 않아 \"Error 1146: Table '...' doesn't exist\" 오류가 나는 버그다. 이 버그는 Aurora MySQL 3.05.0 에서 고쳐졌다."},"trigger":{"en":"Running ALTER TABLE on the Aurora MySQL writer while readers were running queries that used the same table.","ko":"Aurora MySQL 5.7 로 올린 뒤, reader 가 있는 클러스터의 테이블에 ALTER TABLE 을 실행했다."},"severity":"unknown","symptoms":["connection-resets","high-error-rate"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":null,"components":["database"],"root_cause":"upgrade-breaking-change","remediation":[{"text":{"en":"Made the applications retry once after a connection error, with a monkey patch in the Rails applications","ko":"애플리케이션이 커넥션 오류를 받으면 한 번만 재시도하게 했다. Rails 애플리케이션에는 트랜잭션 밖의 reader 쿼리가 \"Lost connection to MySQL server\" 로 실패하면 다시 연결해 한 번 더 실행하는 몽키 패치를 적용했다."}}],"action_items":[],"contributing":["staging-not-representative"],"recurrence_of":null,"symptoms_text":{"en":"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.\n\nThe failure did not reproduce in the development environment, because the development Aurora MySQL cluster had no reader. After a reader was added there, it reproduced: right after an ALTER TABLE ran on a cluster with a reader, MySQL client connections that were sending SQL referring to the altered table to the reader were closed, with a FIN coming back.\n\nThe team first thought this was a bug and sent the reproduction steps to AWS Support. AWS Support pointed to documented Aurora behaviour: DDL statements run on the primary instance can interrupt connections on the Aurora Replicas, and a replica connection that is actively using a table is interrupted when that table is changed by DDL on the primary.","ko":"ALTER TABLE 을 실행하면 그 직후 MySQL 클라이언트의 커넥션이 끊겨 오류가 대량으로 나는 일이 있었다.\n\nAurora MySQL 5.7 로 올린 뒤부터 운영 환경에서 1초도 안 걸리는 ALTER TABLE 을 실행하면, 그 테이블을 읽는 작업이 Lost connection to MySQL server during query 오류로 실패했다. 2021년 1월 8일까지 이런 일이 세 번 연속 일어났다.\n\n개발 환경에서 시험해도 재현되지 않았다. 개발 환경의 Aurora MySQL 클러스터에는 reader 가 없었고, reader 를 더하자 재현됐다. reader 가 있는 클러스터에서 ALTER TABLE 을 실행하면, 그 직후 대상 테이블을 읽는 SQL 을 reader 에 보내던 MySQL 클라이언트의 커넥션이 FIN 을 받고 끊겼다.\n\n팀은 이것을 버그로 보고 재현 순서를 정리해 AWS 지원팀에 문의했다."},"updated_at":"2026-11-14T12:34:09.348714Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0444","org_slug":"repro"}