{"id":"IL-0217","org":"Honeycomb","date":"2023-07-25","docs":[],"title":{"en":"Honeycomb's main MySQL database locked up under cache-miss reads and ran out of connections, a 68-minute total outage","ko":"스키마 캐시가 데워지지 않아 주 MySQL 데이터베이스가 내부 교착에 빠지고 Honeycomb 전체가 68분 동안 멈췄다"},"domain":["database","aws"],"impact":{"scope":"Total Honeycomb outage of all user-facing components from 1:40 p.m. to 2:48 p.m. UTC: no data could be ingested, processed or accessed, alerting and querying were affected, and data not buffered by senders was lost","users":"all Honeycomb users","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Locally good decisions combined into the outage: the query engine wrote the timestamps because it already saw all the data, the shared cache helped scale ingest and untangle the main database, the cluster switch was done to avoid a bug, frequent deploys hid the feature flag bug, pausing deploys during the investigation kept hosts from restarting, and past near-misses made the team expect a slow failover. Feature flags, frequent deploys, pausing deploys during incidents and learning from near-misses all contributed, although they are among the practices Honeycomb trusts most. For a rare lockup of this kind a database failover is the fastest recovery. Several recent Honeycomb incidents started from trying to avoid a subtle bug.","ko":"Honeycomb 은 기능 플래그, 잦은 배포, 장애 중 배포 중단, 지난 아차 사고에서 배운 것처럼 시스템을 안전하게 만드는 가장 믿는 관행들이 함께 이번 장애의 원인이 됐다고 봤다. 저마다 합리적인 결정들이 간접 의존 관계를 따라 예상하지 못하게 얽혔고, 환경 한쪽의 문제가 다른 쪽 서비스를 망가뜨렸다.\n\n최근 여러 장애와 아차 사고에서 미묘한 버그를 피하려던 조치가 더 큰 예상 밖 장애로 이어진 일이 자주 있었다. 이런 드문 데이터베이스 잠김에는 페일오버가 가장 빠른 복구 방법이라는 것도 배웠다."},"related":[],"sources":[{"url":"https://www.honeycomb.io/blog/incident-review-what-comes-up-must-first-go-down","kind":"blog","archived":"https://web.archive.org/web/20260519131949/https://www.honeycomb.io/blog/incident-review-what-comes-up-must-first-go-down"}],"summary":{"en":"Honeycomb runs several MySQL databases on RDS. A main database holds user accounts, permissions and data schemas; it holds no customer events, which Retriever stores, but the whole system needs it. A shared schema cache protects this database, and ingest traffic keeps that cache warm through last-written timestamps that Retriever writes to the database. When the shared cache is missing, services can run on their own local memory caches for a good while, as long as the database stays up. The switch to the other Retriever cluster on 24 July stopped these timestamp writes because of a feature flag bug: a host told to stop writing never retried, even when the flag was switched back, and only a full reboot fixed it. Frequent deploys that restarted hosts had hidden this flaw, and deployments had been paused during the investigation.\n\nOn 25 July the feature flag flip stopped the remaining writes, cache misses sent a surge of reads to the main database, and a deadlock in MySQL's internals, which Honeycomb thinks is non-deterministic and more likely under load, locked its threads until it ran out of connections. From 1:40 p.m. UTC every user-facing component of Honeycomb was down. Responders set up circuit breakers that denied all Shepherd traffic with a 5xx error to protect the database. The database host was hard locked, so they failed over to a replica, which brought the database and the services that depend on it back. They restarted all Retriever hosts, then marked the last-written timestamp of every schema that had seen traffic in the last day as \"now\", so the schema store reloaded the whole cache; this left incorrect values in the parts of the UI that show how fresh data is. They removed the circuit breaker, restarted query hosts that failed internal checks after the database faults, and Honeycomb was healthy again at 2:48 p.m. UTC.\n\nNo new data could be ingested during the outage, and data that users or customers had not buffered for replay was lost for good; the gap stays visible for as long as the data is kept.","ko":"Honeycomb 은 RDS 위에 여러 MySQL 데이터베이스를 두며, 그중 주 데이터베이스에 사용자 계정, 권한, 데이터 스키마가 있다. 스키마 캐시가 이 데이터베이스를 보호하고, 캐시는 저장소와 쿼리 엔진인 Retriever 가 데이터셋마다 마지막으로 데이터를 받은 시각을 기록해야 데워진다. 2023년 7월 24일 밤 미묘한 버그를 피하려고 Retriever 클러스터를 바꿨는데, 이 전환은 여러 번 해 본 안전한 작업이었다. 몇 시간 뒤 수집 서비스 Shepherd 의 SLO 에러 버짓이 천천히 소진됐고, 아침에 엔지니어들은 전환 뒤 Retriever 의 타임스탬프 기록이 끊겨 수집 캐시가 망가진 것을 찾았다.\n\n팀은 기능 플래그로 쓰기만 다른 클러스터로 되돌렸지만 고쳐지지 않았다. 플래그 구현의 버그 때문에 멈추라는 지시를 받은 호스트는 플래그를 되돌려도 다시 시도하지 않았고 재부팅해야만 쓰기가 옮겨 갔다. 이 결함은 늘 있었지만 잦은 배포가 호스트를 재시작하며 가렸다. 조사를 방해하지 않으려고 배포를 멈췄으므로 이번에는 재시작이 우연히 플래그를 되살리는 일도 없었다. 이번 플래그 전환이 시스템을 버티게 하던 남은 쓰기마저 멈췄다. 캐시가 거의 멈추자 주 데이터베이스의 읽기가 치솟았고, 평범한 쓰기 몇 건이 MySQL 내부의 드문 경쟁 상태를 건드려 교착이 생긴 것으로 보였다. Retriever 클러스터를 재시작하는 명령이 준비되기 직전에 데이터베이스가 멈추고 연결이 바닥나 7월 25일 1:40 p.m. UTC 에 전체 시스템이 멈췄다.\n\n팀은 캐시 없이 수집을 다시 올리면 또 무너진다는 것을 알았으므로 데이터베이스부터 살리기로 했다. 서킷 브레이커로 모든 Shepherd 트래픽을 5xx 오류로 거부했고, 완전히 잠긴 데이터베이스 호스트 대신 복제본으로 페일오버했다. 지난 일 때문에 페일오버가 오래 성능을 떨어뜨릴 것이라고 믿어 이 결정이 늦어졌다. 지난 하루 동안 트래픽이 있던 모든 스키마의 마지막 쓰기 시각을 지금으로 바꿔 캐시를 통째로 다시 읽게 했다. 이 때문에 데이터가 얼마나 최신인지 보여 주는 화면 일부에 틀린 값이 들어갔다. 서킷 브레이커를 풀어 수집을 되살렸고, 데이터베이스 오류로 내부 점검에 실패한 호스트를 다시 재시작해 쿼리 용량을 되찾았다. 2:48 p.m. UTC 까지의 장애 동안 새 데이터는 수집되지 않았고, 사용자가 따로 버퍼링하지 않은 데이터는 영영 사라졌다."},"trigger":{"en":"Late on 24 July Honeycomb switched between two Retriever clusters to avoid a subtle bug, and the new cluster stopped writing the last-written timestamps the schema cache depends on. On the morning of 25 July a feature flag flip meant to move those writes back stopped the remaining writes entirely.","ko":"7월 24일 밤 미묘한 버그를 피하려고 Retriever 클러스터 두 개 사이를 전환했다. 전환 뒤 Retriever 가 마지막 쓰기 시각 기록을 데이터베이스에 쓰지 않았고, 그 뒤 쓰기만 되돌리려고 기능 플래그를 바꾸자 남은 쓰기마저 완전히 멈췄다."},"severity":"unknown","symptoms":["high-latency","database-overloaded","lock-contention","service-unavailable"],"timeline":{"detected_after":null,"resolved_after":"1h 8m"},"date_kind":"incident","detection":{"en":"Hours after the cluster switch, the internal SLO for the ingest service Shepherd started burning slowly. Engineers left it for the morning, when a chart showed that Retriever's database calls updating the last-written records had stopped.","ko":"Shepherd 의 내부 SLO 에러 버짓이 천천히 소진되는 것을 엔지니어들이 봤지만 작은 문제로 판단해 아침으로 미뤘다. 아침에 Retriever 의 데이터베이스 호출이 끊긴 차트를 찾아 성능 문제의 원인을 알았다."},"components":["database","cache"],"root_cause":"software-bug","remediation":[{"text":{"en":"Flipped only the writes back to the other Retriever cluster with a feature flag, which did not fix the problem","ko":"클러스터의 쓰기에 문제가 있다고 보고 자주 쓰던 기능 플래그를 바꿔 쓰기만 다른 클러스터로 되돌렸지만 고쳐지지 않았다."}},{"text":{"en":"Set up circuit breakers that denied all Shepherd traffic with a 5xx error to protect the database","ko":"데이터베이스를 보호하려고 서킷 브레이커를 걸어 모든 Shepherd 트래픽을 5xx 오류로 거부했다."}},{"text":{"en":"Failed the hard-locked database over to a replica","ko":"데이터베이스 호스트가 완전히 잠겨 살릴 수 없자 복제본으로 페일오버했고, 데이터베이스와 그에 기대는 서비스들이 돌아왔다."}},{"text":{"en":"Restarted all Retriever hosts so they could provide data for the cache","ko":"데이터베이스가 살아난 뒤 캐시에 데이터를 채우려고 Retriever 호스트를 모두 재시작했다."}},{"text":{"en":"Set the last-written timestamp of every schema with traffic in the last day to now, so the schema store reloaded the cache","ko":"지난 하루 동안 트래픽이 있던 모든 스키마의 마지막 쓰기 시각을 지금으로 손으로 바꿔 스키마 저장소가 캐시를 모두 다시 읽게 했다."}},{"text":{"en":"Removed the circuit breaker and restarted the query hosts that failed internal checks","ko":"서킷 브레이커를 풀어 수집을 완전히 되살렸고, 데이터베이스 오류로 내부 점검에 실패한 호스트를 다시 재시작해 쿼리 용량을 되찾았다."}}],"action_items":[{"text":{"en":"Finish the Retriever cluster migration and remove all code that could disable writes behind the cache","ko":"클러스터 이전을 마쳤고, 캐시 뒤의 쓰기를 끌 수 있는 코드를 모두 지웠다."}},{"text":{"en":"Explore ways to strengthen the cache further","ko":"캐시를 더 튼튼하게 하는 방법을 찾는다."}},{"text":{"en":"Lower the contention put on the database during update storms from new schemas","ko":"새 스키마로 갱신이 몰릴 때 데이터베이스에 거는 경합을 줄이는 방법을 찾는다."}},{"text":{"en":"Stabilise the performance costs of some operations in the system","ko":"시스템 안 일부 작업의 성능 비용이 들쭉날쭉하지 않게 한다."}},{"text":{"en":"Study instrumentation and experimentation that detect and handle such edge cases better","ko":"이런 드문 경우를 더 잘 찾고 다루기 위한 계측과 실험 방법을 검토한다."}}],"contributing":["warm-cache-dependency","early-signal-ignored","manual-action-worsened","assumption-unverified"],"recurrence_of":null,"symptoms_text":{"en":"Hours after a routine switch between two clusters of Retriever, Honeycomb's storage and query engine, late on 24 July 2023, the internal SLO for Shepherd, the ingest service, began to burn slowly. The performance was only marginally slow and inconsistent, with no good explanation, so engineers treated it as minor and left it for the morning.\n\nIn the morning a chart showed that Retriever's database calls had suddenly stopped. These calls update the records of the last time data arrived for each field or dataset, and the caching mechanism uses those records to decide which dataset schemas to refresh and keep warm for ingest. Without them the ingest cache was undermined. Assuming the new cluster's writes were broken, engineers flipped only the writes back to the other cluster with a feature flag they had used often, but this did not help: because of a bug, a host told to stop writing never tried again, even after the flag was switched back, and only a full reboot moved its writes, so the flip stopped the last writes that were still keeping the system alive.\n\nAt 1:40 p.m. UTC on 25 July, just before a command to restart the query engine cluster was ready, the main MySQL database on RDS seized up. With the cache mostly not working, reads on the database had shot up and overloaded it, and a few ordinary writes then seemed to trigger a rare race condition in MySQL's internals that locked thread after thread until operations piled up. The database ran out of connections, services that could not get the data they needed died, and every user-facing component of Honeycomb went down, with no data processed or accessed.\n\nThe database host was hard locked: any interaction with a stuck thread waited on the same lock, so it could not be saved in place. Bringing ingest back without a warm cache would have overloaded the database or saturated its connections again. Earlier read-replica failovers had performed poorly, so the team expected a failover of the primary to be costly.","ko":"2023년 7월 24일 밤 저장소와 쿼리 엔진인 Retriever 의 클러스터를 바꾼 지 몇 시간 뒤 수집 서비스 Shepherd 의 내부 SLO 에러 버짓이 천천히 소진되기 시작했다. 엔지니어들은 소진이 느리고 들쭉날쭉하며 뚜렷한 설명이 없어서 아침에 조사해도 되는 작은 문제라고 판단했다.\n\n아침에 엔지니어들은 한 차트에서 이상을 찾았다. Retriever 가 필드나 데이터셋에 마지막으로 데이터가 들어온 시각을 기록하는 데이터베이스 호출이 클러스터 전환 뒤 갑자기 끊겨 있었다. 캐시는 이 기록으로 어떤 데이터셋 스키마를 새로 읽어 데워 둘지 정했으므로, 기록이 끊기자 수집 캐시가 제대로 돌지 않았다.\n\n팀은 클러스터의 쓰기에 문제가 있다고 보고 기능 플래그로 쓰기만 다른 클러스터로 되돌렸지만 고쳐지지 않았다. 플래그를 바꾸면 멈추라는 지시를 받은 호스트는 플래그를 되돌려도 다시 시도하지 않았고, 전체 재부팅을 해야 쓰기가 옮겨 갔다.\n\n캐시가 거의 멈추자 주 데이터베이스의 읽기가 치솟아 과부하가 걸렸다. 이어 평범한 쓰기 몇 건이 MySQL 내부의 드문 경쟁 상태를 건드린 것으로 보였고, 데이터베이스 스레드가 하나씩 잠기며 작업이 쌓였다.\n\nRetriever 클러스터를 재시작하는 명령이 준비되기 직전에 데이터베이스가 멈추고 연결이 바닥났다. 서비스들은 필요한 정보를 얻지 못해 죽었고, 7월 25일 1:40 p.m. UTC 부터 2:48 p.m. UTC 까지 사용자용 구성 요소 전부에서 데이터를 처리하거나 볼 수 없었다. 데이터베이스 호스트는 완전히 잠겨 살릴 수 없었다. 잠긴 스레드에 닿는 작업은 모두 같은 잠금을 기다리며 멈췄다.\n\n데워진 캐시 없이 수집을 다시 올리면 과부하나 데이터베이스 연결 포화로 다시 무너질 상황이었다. 예전에 읽기 복제본을 페일오버했을 때 성능이 좋지 않았으므로 팀은 주 데이터베이스의 페일오버도 비용이 클 것으로 봤다."},"updated_at":"2026-11-14T05:53:42.795569Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0217","org_slug":"honeycomb"}