{"id":"IL-0291","org":"GitLab","date":"2023-01-05","docs":["https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/17063","https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/17075","https://gitlab.com/gitlab-org/gitlab/-/issues/387176","https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/9431","https://gitlab.com/gitlab-com/runbooks/-/merge_requests/2040"],"title":{"en":"GitLab.com's redis-sidekiq Sentinel could not elect a primary after a GCP host error, so Sidekiq was down for 30 minutes","ko":"GitLab.com 의 redis-sidekiq Sentinel 이 쿼럼을 만들지 못해 Sidekiq 이 30분 동안 멈추고 500 오류가 늘었다"},"domain":["database","gcp"],"impact":{"scope":"All services using Sidekiq jobs on GitLab.com fully down for 30 minutes, with knock-on errors in Web and API requests and SAML login; about 4,000 merge requests unusable for several hours","users":"External customers; best estimate 16,621, possibly much more","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"An alert on a down Sentinel node would have kept enough nodes up to form a quorum when failover was needed, and could have avoided the incident entirely. Removing a noisy alert earlier may have let the down node go unnoticed.","ko":"꺼진 Sentinel 노드를 알림으로 잡았다면 장애 조치에 필요한 쿼럼을 만들 노드 수를 미리 확보해 이 장애를 아예 막을 수 있었다. 너무 시끄럽다는 이유로 알림을 지운 것이 꺼진 노드를 쿼럼 문제 전에 잡을 기회를 줄였을 수 있다. 복구가 몇 시간 길게 이어진 것은 머지 리퀘스트가 Redis Sidekiq 장애에서 스스로 회복하지 못했기 때문이다."},"related":[],"sources":[{"url":"https://gitlab.com/gitlab-com/gl-infra/production/-/issues/8203","kind":"github","archived":null}],"summary":{"en":"In GitLab.com's redis-sidekiq Redis, managed by Redis Sentinel, the node redis-sidekiq-01-db-gprd had been down for more than 30 days, so the cluster had been running with a quorum of 2. An alert that would have shown a down node had been added in the runbooks and later removed for being too noisy. When the primary, redis-sidekiq-03-db-gprd, failed on a GCP host error and its VM was reset and moved to another node, no quorum was possible. The services on the nodes do not start automatically on boot, so the cluster was left with one replica stuck on a quorum conflict.\n\nOnce responders saw there were not enough machines to elect a primary, they restarted the failed node. Redis was out for about 30 minutes. The best estimate of affected customers is 16,621, and the review says the real number may have been much larger. About 4,000 merge requests stayed unusable for several hours, which made up the long tail of the recovery.","ko":"GitLab.com 의 redis-sidekiq 에서 redis-sidekiq-01-db-gprd 노드가 30일 넘게 꺼져 있었고, 그동안 클러스터는 쿼럼 2로 돌고 있었다. 그러다 primary 인 redis-sidekiq-03-db-gprd 가 GCP 호스트 오류로 실패해 VM 이 리셋되고 다른 노드로 옮겨졌다. primary 를 잃자 쿼럼을 만들 수 없었다. 서비스가 부팅할 때 자동으로 시작되지 않게 돼 있어서, 쿼럼 충돌에 걸린 replica 하나만 남았다. Sidekiq 작업을 쓰는 모든 서비스가 30분 동안 멈췄고 Web 과 API 요청, SAML 로그인까지 영향을 받았다. 엔지니어는 primary 를 뽑을 노드가 모자란다는 것을 확인한 뒤 실패한 노드를 재시작해 복구했다. 머지 리퀘스트는 Redis Sidekiq 장애에서 스스로 회복하지 못해, 장애 중에 만들어진 약 4,000개가 몇 시간 동안 쓸 수 없는 상태로 남았다. 영향받은 고객은 16,621명으로 추정했지만 실제로는 훨씬 많았을 수 있다. 꺼진 노드를 잡을 알림이 runbooks 머지 리퀘스트 2040 으로 추가된 적이 있었지만 너무 시끄러워 쓸모가 없다는 이유로 지워졌다. 같은 근본 원인으로 난 이전 사건이 reliability 이슈 9431 이다."},"trigger":{"en":"The VM of the primary node, redis-sidekiq-03-db-gprd, failed on a GCP host error and was reset and moved to another node.","ko":"primary 였던 redis-sidekiq-03-db-gprd 가 GCP 호스트 오류로 실패했고, 이 VM 은 리셋되어 다른 노드로 옮겨졌다."},"severity":"unknown","symptoms":["failover-failed","high-error-rate"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Several alerts in the #production channel, first Redis client errors and then error SLO violations on several services, such as the Webservice and API load balancer and Puma.","ko":"#production 채널에 여러 알림이 왔다. Redis 클라이언트 오류 알림부터 시작해 Webservice & API LoadBalancer 와 Puma 를 포함한 여러 서비스의 Error SLO 위반 알림으로 번졌다."},"components":["cache","failover-manager"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"Restarted the failed Redis node so Sentinel had enough nodes to elect a primary","ko":"primary 를 뽑을 만큼 노드가 없다는 것을 확인한 뒤 실패한 노드를 재시작했다."}}],"action_items":[{"text":{"en":"Alert when the Sentinel service is down","ko":"Sentinel 서비스가 꺼지면 알림을 보낸다."}},{"text":{"en":"Make merge requests robust to Redis Sidekiq outages","ko":"머지 리퀘스트가 Redis Sidekiq 장애 뒤에 스스로 회복하도록 고친다."}}],"contributing":["single-point-of-failure","monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"GitLab.com showed widespread, erratic behaviour and more 500 errors for about 30 minutes while its redis-sidekiq Redis was down. Alerts in the #production channel began with Redis client errors and spread to error SLO violations on several services, such as the Webservice and API load balancer and Puma.\n\nEvery service that uses Sidekiq jobs was fully down for those 30 minutes, with knock-on effects on Web and API requests; among other things, users could not log in with SAML. For about 4,000 merge requests created during the outage, diffs, pipeline status and merging stayed unavailable for several hours afterwards, because merge requests could not recover by themselves from a Redis Sidekiq outage.","ko":"#production 채널에 Redis 클라이언트 오류 알림이 먼저 오고, 이어서 여러 서비스의 Error SLO 위반 알림이 잇따랐다. Sidekiq 작업을 쓰는 모든 서비스가 30분 동안 완전히 멈췄고 Web 과 API 요청에서도 500 오류가 늘었다.\n\nError SLO 위반은 Webservice & API LoadBalancer 와 Puma 에서 났다. 장애 30분 동안 사용자는 SAML 로그인이 안 되는 것을 포함해 곳곳에서 들쭉날쭉한 동작을 겪었다.\n\nRedis 가 돌아온 뒤에도 장애 시간 중에 만들어진 머지 리퀘스트 약 4,000개는 몇 시간 동안 diff 와 파이프라인 상태를 볼 수 없었고 머지할 수도 없었다.\n\n조사해 보니 primary 를 뽑을 만큼 노드가 남아 있지 않았고, 남은 replica 하나가 쿼럼 충돌에 걸린 채 멈춰 있었다."},"updated_at":"2026-11-14T12:33:54.588946Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0291","org_slug":"gitlab"}