{"id":"IL-0314","org":"Daily","date":"2023-02-07","docs":[],"title":{"en":"Daily's newly upgraded Aurora MySQL database deadlocked on meeting-event queries and its call servers kept restarting","ko":"주말에 업그레이드한 Aurora MySQL 데이터베이스에서 교착이 쌓여 통화 서버가 재시작되고 통화가 다른 서버로 옮겨졌다"},"domain":["database","aws"],"impact":{"scope":"API, Dashboard and Core Call Experience: some users in calls had meeting moves with video and audio dropping for a few seconds, a small number may have failed to join a room during a move, and some REST API requests returned 5xx errors","users":"Some users in Daily calls and some REST API clients","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Daily tests infrastructure changes under production-like workloads, but its synthetic workload did not have the shape that triggers these deadlocks. A deadlock behaviour change in MySQL 5.7 that was already known turned out far more severe in production than either Daily or the AWS Aurora team expected.","ko":"Daily 는 모든 인프라 변경을 운영과 비슷한 부하로 시험하려 하지만, 이번에는 이 교착을 일으킬 만한 형태의 합성 부하로 시험하지 못했다. MySQL 5.7 에서 교착 처리가 더 보수적으로 바뀐 것은 알려진 변경이었어도, 실제로 겪은 교착의 심각도는 Daily 와 AWS Aurora 팀 모두에게 뜻밖이었다."},"related":[],"sources":[{"url":"https://status.daily.co/incidents/4r4b5hhz9w5v","kind":"official-status","archived":"https://web.archive.org/web/20260721044550/https://status.daily.co/incidents/4r4b5hhz9w5v"}],"summary":{"en":"Daily upgraded the database that coordinates activity between its call servers over the weekend before 7 February 2023, and it ran normally on Monday. On Tuesday at 14:47 UTC alerts showed high lock contention, and within four minutes engineers found meeting-event queries from the SFUs stuck in deadlocks. API requests timed out, SFUs restarted, and each SFU shutdown and its replacement by autoscaling caused meeting moves that added more load. Disabling the leftover binlog replication to the old database and restarting the database at 10:13 Eastern helped only partly, because SFUs kept retrying the deadlocking queries. At 10:47, while engineers were writing a script to terminate stuck queries, the database restarted by itself. This restart took slightly longer than the one at 10:13, long enough for the SFUs to discard the stale meeting updates but not long enough to make them restart, and the platform returned to normal. The impact lasted almost exactly one hour, from 14:47 to 15:47 UTC, and the incident was moved to monitoring at 11:01.\n\nDaily later proved that the deadlocks came from a low-level behaviour change in a MySQL point release that the weekend maintenance had brought in with Aurora MySQL 2.11.0. A more conservative approach to deadlocks was a known change in MySQL 5.7, on which Aurora MySQL 2 is based, but the severity surprised both Daily and the AWS Aurora team. As a precaution Daily rate-limited POST /rooms to the same limit as DELETE /rooms/:name, about 2 requests per second or 50 over 30 seconds, and later deployed a platform update after which the 429 rate limit responses stopped. The workaround for the behaviour change was to update an index on one affected table, which Daily planned and tested during the week and applied to the production database with no user impact on the Saturday evening.","ko":"Daily 는 주말에 데이터베이스 서버를 업그레이드했고, 데이터베이스는 월요일까지 정상으로 돌았다. 2023-02-07 9:47 AM 동부 시간, 14:47 UTC 에 평소 부하에서 데이터베이스 성능 문제 알림이 울렸고, 알림은 높은 락 경합을 가리켰다. 9:51 에 엔지니어들은 meeting events 쿼리가 대량으로 교착에 걸린 것을 찾았다. SFU 가 참가자의 입장과 퇴장을 기록하는 쿼리였다. 이 교착으로 webapp API 요청이 타임아웃되며 5xx 를 냈고, SFU 는 데이터베이스에 연결하지 못하자 스스로 종료했다. 오토스케일링이 새 SFU 를 띄우는 동안 meeting move 가 평소보다 많아져 데이터베이스에 부하를 더했다.\n\n10:13 에 팀은 마이그레이션 뒤에도 옛 데이터베이스를 최신으로 맞추려고 켜 둔 MySQL binlog 복제를 끄고 데이터베이스를 재시작했다. 나아지긴 했지만 SFU 가 교착을 일으키던 쿼리를 재시도해 문제가 이어졌다. 팀은 AWS 지원에도 연락했다. 10:47 에 엔지니어들이 멈춘 쿼리를 끊는 스크립트를 만들던 중 데이터베이스가 갑자기 스스로 재시작했다. 이번 재시작은 10:13 의 재시작보다 조금 길었다. 그 덕분에 SFU 는 재시작할 만큼 오래 끊기지 않으면서 오래된 meeting 업데이트를 버릴 수 있었다. 이때 SFU 와 플랫폼이 정상으로 돌아왔고, 11:01 에 모니터링 상태로 넘어갔다. 영향은 14:47 에서 15:47 UTC 까지 거의 정확히 한 시간이었다.\n\nDaily 는 교착이 주말 점검으로 올라간 MySQL 포인트 릴리스의 저수준 동작 변경 때문이라는 것을 증명했다. 그래서 이 동작 변경을 피하려고 영향받은 테이블 하나의 인덱스를 고치기로 했다. 그 주 내내 운영 데이터베이스를 바꿀 계획을 만들어 시험했고, 토요일 저녁에 사용자 영향 없이 작업을 끝냈다. 그 사이 예방 조치로 방을 만드는 REST API 엔드포인트에 요청 제한을 걸었다. MySQL 5.7 에서 교착을 더 보수적으로 다루도록 바뀐 것은 알려진 변경이었다. Aurora MySQL 2 는 MySQL 5.7 을 바탕으로 한다. 그러나 Aurora MySQL 2.11.0 에서 겪은 교착의 심각도는 Daily 에게도 AWS Aurora 팀에게도 뜻밖이었다."},"trigger":{"en":"Database maintenance the weekend before had upgraded the database to a MySQL point release with a low-level behaviour change, and on 7 February, under normal load, that change produced the deadlocks Daily saw on Aurora MySQL 2.11.0.","ko":"Daily 는 주말에 데이터베이스 서버를 업그레이드했고, 이 작업으로 데이터베이스가 MySQL 포인트 릴리스의 저수준 동작 변경이 들어간 버전으로 올라갔다. 월요일까지 정상이던 데이터베이스가 2월 7일 평소 부하에서 대량의 교착을 일으켰다."},"severity":"unknown","symptoms":["lock-contention","high-error-rate","intermittent-timeouts"],"timeline":{"detected_after":"0m","resolved_after":"1h"},"date_kind":"incident","detection":{"en":"Database alerts at 9:47 AM Eastern reported a performance issue with high lock contention on the newly upgraded database.","ko":"9:47 AM 동부 시간에 평소 부하에서 데이터베이스 성능 문제 알림이 울렸고, 알림은 새로 업그레이드한 데이터베이스의 높은 락 경합을 가리켰다."},"components":["database"],"root_cause":"upgrade-breaking-change","remediation":[{"text":{"en":"Disabled MySQL binlog replication to the old database and restarted the database to reduce load","ko":"10:13 에 옛 데이터베이스를 최신으로 맞추던 MySQL binlog 복제를 끄고 데이터베이스를 재시작해 부하를 줄였다. 나아졌지만 SFU 가 교착을 일으키던 쿼리를 재시도해 문제가 이어졌다."}},{"text":{"en":"The database restarted by itself at 10:47 AM, the SFUs dropped the stale meeting updates without restarting, and the platform recovered","ko":"10:47 에 데이터베이스가 갑자기 스스로 재시작했다. 이 재시작 덕분에 SFU 는 재시작하지 않고 오래된 meeting 업데이트를 버릴 수 있었고, 플랫폼이 정상으로 돌아왔다."}},{"text":{"en":"Rate-limited the POST /rooms endpoint to the same limit as DELETE /rooms/:name","ko":"예방 조치로 방을 만드는 REST API 엔드포인트에 요청 제한을 걸었다. POST /rooms 의 한도를 DELETE /rooms/:name 과 같은 초당 약 2회, 30초에 50회로 맞췄다."}},{"text":{"en":"Updated an index on the affected table in production on the Saturday evening to work around the MySQL behaviour change","ko":"MySQL 동작 변경을 피하려고 영향받은 테이블 하나의 인덱스를 고쳤다. 그 주 동안 계획을 만들어 시험했고 토요일 저녁에 사용자 영향 없이 운영 데이터베이스에 적용했다."}}],"action_items":[{"text":{"en":"Work with AWS so the Aurora MySQL 2.11.0 deadlock issue is documented, understood and fixed in a future release","ko":"운영 환경의 Aurora MySQL 2.11.0 에서 본 교착 문제를 문서로 남기고 원인을 밝혀 다음 릴리스에서 고치도록 AWS 와 계속 협력한다."}},{"text":{"en":"Add more API request patterns to the testing workload used for infrastructure changes","ko":"시험 부하에 API 요청 패턴을 더했다."}},{"text":{"en":"Add production monitoring alarms on more fine-grained database metrics","ko":"더 세밀한 데이터베이스 지표를 보는 운영 모니터링 알람을 더했다."}}],"contributing":["staging-not-representative","automation-amplified","retry-storm","delayed-effect-change"],"recurrence_of":null,"symptoms_text":{"en":"At 9:47 AM Eastern (14:47 UTC) on 7 February 2023, Daily's database alerts reported a performance problem under normal operational load: a high level of lock contention on a database that had been upgraded the weekend before and had run normally since Monday. Users could get websocket connection errors when joining calls, and REST API requests could time out or return 5xx errors.\n\nBy 9:51 engineers found a large volume of queries stuck in a deadlock. They were \"meeting events\" from the call servers (SFUs), recording when participants joined or left meetings. The deadlocks made webapp API requests time out and return 5xx errors, and the SFUs dropped their connections and restarted.\n\nThe problem fed on itself. An SFU shuts itself down when it cannot connect to the database, and autoscaling starts a new one to replace it. When an SFU shuts down, the webapp moves its call sessions to another SFU, a \"meeting move\" in which users see everyone else's video drop for a second or two and may need to restart recording or live streaming. With several SFUs shutting down at once, the extra meeting moves loaded the struggling database further.\n\nAt 10:13 the team suspected the MySQL binary log replication that still kept the old database up to date after the weekend migration, disabled it and restarted the database to reduce load. This helped, but many SFUs retried the queries that caused the deadlocks, so the problem persisted, and AWS support was contacted.","ko":"2023-02-07 9:47 AM 동부 시간에 평소 부하에서 데이터베이스 성능 문제 알림이 울렸다. 알림 내용은 주말에 업그레이드한 데이터베이스의 락 경합이 높다는 것이었고, 이 때문에 통화 서버인 SFU 가 문제를 겪었다.\n\n상태 페이지의 첫 공지는 플랫폼 오류율이 높고, 사용자가 통화에 들어갈 때 websocket 연결 오류가 날 수 있다고 알렸다. meeting move 는 진행 중인 통화 세션이 한 통화 서버에서 다른 통화 서버로 옮겨 가는 일이고, 이때 통화 중인 사용자는 다른 사람의 영상과 음성이 몇 초 끊겼다 돌아오는 것을 겪는다. 이번에는 meeting move 가 평소보다 자주 일어났다. meeting move 가 일어나면 녹화나 라이브 스트리밍을 다시 시작해야 할 수도 있었다. REST API 요청은 타임아웃되거나 5xx 오류를 받을 수 있었다.\n\n9:51 에 엔지니어들은 교착에 걸린 대량의 쿼리를 찾았다. SFU 가 참가자의 입장과 퇴장을 기록하는 meeting events 쿼리였다. 이 교착 때문에 webapp API 요청이 타임아웃되며 5xx 를 냈고, 결국 SFU 가 연결을 끊고 재시작했다.\n\nSFU 는 데이터베이스에 연결하지 못하면 스스로 종료하고, 오토스케일링이 새 SFU 를 띄운다. 여러 SFU 가 동시에 내려가고 올라오면서 meeting move 가 평소보다 많아졌고, 이것이 이미 부하가 높던 데이터베이스를 더 압박했다.\n\n10:13 에 팀은 교착의 원인 후보 하나를 찾았다. 지난 주말 마이그레이션 뒤에도 옛 데이터베이스를 최신으로 맞추려고 켜 둔 MySQL binlog 복제였다. 복제를 끄고 데이터베이스를 재시작하자 나아졌지만, 많은 SFU 가 교착을 일으키던 쿼리를 재시도해 문제가 이어졌다. 팀은 조사를 계속하며 AWS 지원에도 연락했다."},"updated_at":"2026-11-14T12:33:56.789138Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0314","org_slug":"daily"}