{"id":"IL-0302","org":"GitHub","date":"2022-03-16","docs":[],"title":{"en":"Peak load on GitHub's mysql1 MySQL cluster maxed out its database proxy's connections and stopped writes in March 2022","ko":"GitHub 의 공용 MySQL 클러스터 mysql1 이 최대 부하 시간대에 연결이 바닥나 쓰기 작업이 네 번 멈췄다"},"domain":["database"],"impact":{"scope":"Write operations on GitHub, including git operations, webhooks, pull requests, API requests, issues, GitHub Packages, GitHub Codespaces, GitHub Actions and GitHub Pages, on March 16, 17, 22 and 23, 2022","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://github.blog/news-insights/company-news/an-update-on-recent-service-disruptions/","kind":"blog","archived":"https://web.archive.org/web/20261022120845/https://github.blog/news-insights/company-news/an-update-on-recent-service-disruptions/"}],"summary":{"en":"GitHub's mysql1 MySQL cluster is shared by multiple services and has a single primary for writes and replicas for reads. On March 16, 2022, peak-hour load and poorly performing queries pushed the database proxy in front of it to its maximum number of connections, and all write operations on GitHub failed for 5 hours and 36 minutes, until the team failed over to a healthy replica. GitHub then started investigating traffic patterns and query performance at peak load.\n\nOn March 17 the same peak load came back before the query problems were found. The team failed over in advance, but the failover caused a new load pattern and connectivity problems on the new primary, and applications could not connect to mysql1 while the team reset the connections. During this incident the team identified the load pattern and then added an index that fixed the main performance problem. On March 22, while memory profiling was enabled on the database proxy to study peak load, client connections to mysql1 started to fail and another primary failover was needed. On March 23 the same load characteristics returned; the team failed over again and throttled webhook traffic to reduce load. GitHub described the common theme as resource contention in mysql1 during peak load, in a main database it has been partitioning and adding clusters around for several years.","ko":"2022년 3월 몇 주 동안 GitHub 은 mysql1 클러스터의 자원 경합 때문에 여러 번 장애를 겪었다. mysql1 은 여러 서비스가 함께 쓰고 읽기와 쓰기 트래픽이 모두 많은 MySQL 클러스터였고, 하나의 주 노드가 쓰기를 받고 나머지 복제본 노드가 읽기를 맡는 구성이었다. 3월 16일 14:09 UTC 에 최대 부하 시간대의 부하가 늘면서 데이터베이스 프록시가 최대 연결 수에 닿았고, git 작업과 웹훅과 풀 리퀘스트를 비롯한 모든 쓰기 작업이 5시간 36분 동안 멈췄다. GitHub 은 최대 부하와 특정 상황의 나쁜 쿼리 성능이 겹친 것으로 보았고, 정상인 복제본으로 페일오버해 복구했다.\n\n3월 17일 13:46 UTC 에 같은 최대 부하 패턴이 다시 왔다. GitHub 은 문제가 커지기 전에 미리 페일오버했다. 그런데 이 페일오버가 새 부하 패턴을 만들어 새 주 노드에 연결 문제가 생겼고, 연결을 재설정하는 동안 애플리케이션이 mysql1 에 연결하지 못했다. 이 장애는 2시간 28분 이어졌고, GitHub 은 이때 부하 패턴을 찾아 인덱스를 추가해 주된 성능 문제를 고쳤다. 3월 22일 15:53 UTC 에는 성능을 더 분석하려고 데이터베이스 프록시에 메모리 프로파일링을 켰다. 같은 때에 클라이언트 연결이 실패하기 시작했고, 다시 주 노드를 페일오버해 복구했다. 이 장애는 2시간 53분 이어졌다. 3월 23일 14:49 UTC 에도 같은 부하 특성이 다시 나타났다. 이번에도 페일오버로 복구했고, 장애는 2시간 51분 이어졌다. 이날 GitHub 은 부하를 줄이려고 웹훅 트래픽을 제한했다."},"trigger":{"en":"Increased load on mysql1 during peak hours, combined with poor query performance in specific circumstances, pushed the database proxy to its maximum number of connections.","ko":"최대 부하 시간대에 공용 MySQL 클러스터 mysql1 의 부하가 늘어 데이터베이스 프록시가 최대 연결 수에 닿았다."},"severity":"unknown","symptoms":["writes-rejected","database-overloaded","high-error-rate","failover-failed"],"timeline":{"detected_after":null,"resolved_after":"5h 36m"},"date_kind":"incident","detection":null,"components":["database","database-proxy"],"root_cause":"capacity","remediation":[{"text":{"en":"Failed over mysql1 to a healthy replica on March 16","ko":"정상인 복제본으로 페일오버해 3월 16일 장애에서 복구했다."}},{"text":{"en":"Reset the application connections to the new primary on March 17","ko":"3월 17일 미리 한 페일오버 뒤 새 주 노드에 생긴 연결 문제를 풀려고 연결을 재설정했다."}},{"text":{"en":"Added an index that fixed the main query performance problem","ko":"3월 17일 장애 중에 부하 패턴을 찾아 인덱스를 추가해 주된 성능 문제를 고쳤다."}},{"text":{"en":"Performed a primary failover on March 22","ko":"3월 22일 클라이언트 연결이 실패하자 다시 주 노드를 페일오버해 복구했다."}},{"text":{"en":"Performed a primary failover on March 23","ko":"3월 23일 같은 부하 특성으로 클라이언트 연결이 실패하자 다시 주 노드를 페일오버해 복구했다."}},{"text":{"en":"Throttled webhook traffic to reduce load","ko":"3월 23일 부하를 줄이려고 웹훅 트래픽을 제한했다."}}],"action_items":[{"text":{"en":"Keep throttling webhook traffic at peak load times","ko":"다른 대책을 더 찾는 동안 최대 부하 시간대에 웹훅 트래픽 제한을 계속 써서 같은 장애가 다시 나지 않게 한다."}},{"text":{"en":"Audit the load patterns of mysql1 during peak hours and make performance fixes based on the audits","ko":"최대 부하 시간대의 mysql1 부하 패턴을 점검하고, 그 결과에 따라 성능 수정을 차례로 한다."}},{"text":{"en":"Move traffic to other databases to reduce load and speed up failover","ko":"부하를 줄이고 페일오버 시간을 줄이려고 mysql1 의 트래픽을 다른 데이터베이스로 옮긴다."}},{"text":{"en":"Review change management, particularly monitoring and changes during high load in production","ko":"변경 관리 절차를 검토한다. 특히 운영 환경에 부하가 높을 때의 모니터링과 변경을 살핀다."}},{"text":{"en":"Shard the databases and scale up hardware","ko":"플랫폼 성장에 맞춰 데이터베이스 샤딩과 하드웨어 확장을 비롯한 인프라 확장을 이어 간다."}}],"contributing":["inefficient-query","change-in-peak-hours","manual-action-worsened","blast-radius-too-wide"],"recurrence_of":null,"symptoms_text":{"en":"On March 16, 2022 at 14:09 UTC, write operations across GitHub stopped working, including git operations, webhooks, pull requests, API requests, issues, GitHub Packages, GitHub Codespaces, GitHub Actions and GitHub Pages. Under peak-hour load, the database proxy in front of the shared mysql1 MySQL database had reached its maximum number of connections.\n\nmysql1 is shared by multiple services and carries heavy read and write traffic. The cluster has a single primary that takes writes and replicas that serve reads. The incident appeared to be related to peak load combined with poor query performance in specific sets of circumstances.\n\nThe same pattern returned on four days. The March 16 incident lasted 5 hours and 36 minutes. On March 17 at 13:46 UTC, under the same peak load, the team failed over before the problem grew, but the failover caused a new load pattern and applications could not connect to the new primary, for 2 hours and 28 minutes. On March 22 at 15:53 UTC, client connections to mysql1 started to fail at the same time as memory profiling was enabled on the database proxy, for 2 hours and 53 minutes. On March 23 at 14:49 UTC, client connections failed again, for 2 hours and 51 minutes.","ko":"2022년 3월 16일 14:09 UTC, 최대 부하 시간대에 mysql1 데이터베이스의 부하가 늘면서 데이터베이스 프록시가 최대 연결 수에 닿았다. GitHub 의 모든 쓰기 작업이 동작하지 않았다.\n\n멈춘 쓰기 작업에는 git 작업, 웹훅, 풀 리퀘스트, API 요청, 이슈, GitHub Packages, GitHub Codespaces, GitHub Actions, GitHub Pages 가 들어 있었다. mysql1 은 여러 서비스가 함께 쓰고 읽기와 쓰기 트래픽이 모두 많은 데이터베이스였다.\n\n같은 모습이 3월 17일 13:46 UTC, 3월 22일 15:53 UTC, 3월 23일 14:49 UTC 에 다시 나타났다. 3월 17일에는 같은 최대 부하 패턴이 다시 오자 GitHub 이 문제가 커지기 전에 미리 페일오버했다. 그런데 이 페일오버가 새 부하 패턴을 만들어 새 주 노드에 연결 문제가 생겼고, 애플리케이션은 다시 mysql1 에 연결하지 못했다. 3월 22일과 23일에는 mysql1 로 가는 클라이언트 연결이 실패했다.\n\nGitHub 은 처음에 이 장애가 최대 부하에 특정 상황의 나쁜 쿼리 성능이 겹친 결과라고 보았다. 그래서 최대 부하 때의 트래픽 패턴과 쿼리 성능을 조사했지만, 3월 17일의 최대 부하 전까지 쿼리 성능 문제를 짚어 내 고치지 못했다. 3월 22일에는 최대 부하 때의 성능 특성을 자세히 보려고 데이터베이스 프록시에 메모리 프로파일링을 켰고, 같은 때에 클라이언트 연결이 실패하기 시작했다."},"updated_at":"2026-11-14T12:33:55.595592Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0302","org_slug":"github"}