{"id":"IL-0321","org":"GitLab","date":"2021-01-16","docs":["https://gitlab.com/gitlab-com/gl-infra/production/-/issues/2648","https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/12355","https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/12363","https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/12518"],"title":{"en":"GCP snapshots on all Patroni nodes stalled GitLab.com's primary PostgreSQL disk, Patroni failed over and 5xx spiked","ko":"GitLab.com 의 Patroni 주 데이터베이스 노드가 멈춰 장애 조치가 일어났고 쓰기 요청에서 5xx 오류가 튀었다"},"domain":["database","gcp"],"impact":{"scope":"Some GitLab.com requests that needed database writes returned 5xx errors for about 4-5 minutes: about 0.133% of Rails requests and about 2.86% of Workhorse requests","users":"All active users during the incident","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Do not take a GCP snapshot of a running PostgreSQL leader. Technical reviewers have to review every change or addition to a change request's description before a manager or director approves it. The Datastores team should explain in detail how backups and snapshots work on the production database. No action belonging to a change should start before the change's scheduled start.","ko":"실행 중인 PG 리더 노드에서 GCP 스냅샷을 뜨지 않는다. 변경 요청 이슈 본문이 바뀌거나 내용이 더해지면, 기술 검토자는 관리자나 디렉터가 승인하기 전에 그 내용을 하나하나 검토한다. Datastores 팀은 운영 데이터베이스의 백업과 스냅샷이 어떻게 동작하는지 자세히 공유한다. 변경과 관련된 작업은 일정 초대에 잡힌 변경 시작 시각이 된 뒤에 시작한다."},"related":[],"sources":[{"url":"https://gitlab.com/gitlab-com/gl-infra/production/-/issues/3338","kind":"github","archived":null}],"summary":{"en":"As a safety measure before a filesystem change (production#2648), snapshots were started on the PostgreSQL data volumes of all Patroni database servers at once. The engineer planning the change believed snapshotting through the GCP API ran in the background without affecting the running nodes, and did not know that GCP persistent disks are network-attached and use network bandwidth shared with the VM instance. The snapshot caused a large spike in IO latency on the primary's data disk, presumably by taking all the network bandwidth available to its persistent disks, and disk access stalled. With that IO latency, and a loss of network connectivity to Consul at the same moment, Patroni failed the primary over from patroni-06 to patroni-03 within about a minute, and requests across the fleet that needed the database returned errors for about four to five minutes.\n\nThe team had seen similar cases before in which snapshots led to Patroni failovers. Corrective actions were to update the Patroni and PostgreSQL runbooks with GCP snapshot best practices, add a checklist for change management reviewers and approvers, and talk with Google about IO sensitivities.","ko":"2021-01-16 GitLab 인프라 팀은 production#2648 변경을 진행하면서, 관련 파일시스템 변경에 앞선 안전 조치로 23:36 UTC 에 모든 Patroni 데이터베이스 노드에서 GCP 디스크 스냅샷을 동시에 시작했다. 팀은 스냅샷이 GCP API 로 뒤에서 처리돼 실행 중인 노드에 영향을 주지 않는다고 잘못 알고 있었다.\n\nPostgres 데이터 볼륨의 스냅샷은 IO 지연을 크게 끌어올렸다. 팀은 스냅샷이 네트워크로 연결된 영구 디스크에 쓸 수 있는 네트워크 대역폭을 다 써 버렸기 때문으로 추정했다. 영구 디스크는 VM 인스턴스에 할당된 네트워크 대역폭을 나눠 쓴다. 변경을 계획한 엔지니어는 이 구조를 몰랐고, 그 때문에 하트비트와 헬스 체크를 놓칠 수 있다는 점도 몰랐다. 주 노드의 디스크 접근이 멈췄고, 같은 때 그 노드는 consul 과의 네트워크 연결도 잃었다. 둘 중 하나 또는 둘 다가 장애 조치를 일으켰다. 23:40 에 Patroni 가 patroni-06 의 락을 무효로 하고 장애 조치를 시작했고 23:41 에 patroni-03 이 새 주 노드가 됐다.\n\n23:38 부터 23:42 사이에 데이터베이스 쓰기가 필요한 요청 일부가 5xx 오류를 받았고, 23:42 에 오류율이 내려갔다. 팀은 예상보다 심한 성능 저하를 보고 세 존 가운데 두 존의 스냅샷을 취소했다. 장애 조치가 일어난 것은 나중에 변경 계획의 다음 단계를 진행하면서 알았다. 23:56 에 Slack 에서 장애를 선언했다. 전에도 스냅샷 때문에 Patroni 장애 조치가 난 비슷한 일이 있었다."},"trigger":{"en":"During the change production#2648, at 23:36 UTC an engineer started GCP disk snapshots on all Patroni nodes at the same time, as a safety step before a change to the filesystem, believing the snapshot was a transparent background operation through the GCP API.","ko":"production#2648 변경을 진행하던 엔지니어가 23:36 UTC 에 모든 Patroni 노드에서 GCP 디스크 스냅샷을 동시에 시작했다. 이 스냅샷은 관련 파일시스템 변경에 앞선 안전 조치였다. 엔지니어는 스냅샷이 GCP API 로 뒤에서 처리돼 실행 중인 노드에 영향을 주지 않는다고 잘못 알고 있었다."},"severity":"unknown","symptoms":["high-error-rate"],"timeline":{"detected_after":"1m","resolved_after":"4m"},"date_kind":"incident","detection":{"en":"A flood of alerts about downstream impact; multiple service disruption alerts arrived at 23:39 UTC, a minute after the error spikes began. The incident was declared in Slack at 23:56.","ko":"다운스트림 서비스의 영향을 알리는 알림이 한꺼번에 쏟아지면서 알아챘다. 23:38 UTC 에 오류 급증이 보였고 23:39 에 서비스 중단 알림이 여러 개 들어왔다. 감지까지 1~2분이 걸렸다."},"components":["database","failover-manager","block-storage"],"root_cause":"capacity","remediation":[{"text":{"en":"Patroni invalidated patroni-06's lock and promoted patroni-03 as the new primary","ko":"23:40 UTC 에 Patroni 가 patroni-06 의 락을 무효로 하고 장애 조치를 시작했고, 23:41 에 patroni-03 이 새 주 노드가 됐다."}},{"text":{"en":"Cancelled the snapshot requests in two of the three zones","ko":"예상보다 심한 성능 저하를 보고 세 존 가운데 두 존의 스냅샷을 취소했다."}}],"action_items":[{"text":{"en":"Update the Patroni and PostgreSQL runbooks to clarify GCP snapshot best practices","ko":"Patroni 와 Postgres 런북에 GCP 스냅샷의 모범 사례를 분명히 적는다."}},{"text":{"en":"Add a checklist for change management reviewers and approvers to the runbooks, referenced in the handbook","ko":"변경 관리 검토자와 승인자가 쓸 점검 목록을 런북에 넣고 핸드북에서 가리킨다."}},{"text":{"en":"Schedule a call with Google about IO sensitivities","ko":"IO 민감도 문제를 더 논의하려고 Google 과 통화 일정을 잡는다."}}],"contributing":["assumption-unverified","no-staged-rollout"],"recurrence_of":null,"symptoms_text":{"en":"At 23:38 UTC on 2021-01-16 GitLab.com error rates spiked, and a minute later multiple alerts for service disruption arrived, two minutes after GCP disk snapshots had been started on all Patroni database nodes. Some requests that needed database writes returned 5xx errors for about four to five minutes, while page refreshes checked during the incident responded normally.\n\nRails logged approximately 2,000 5xx errors in a spike between about 23:38:30 and 23:42:00, out of 1,521,180 requests, an error rate of about 0.133%. Workhorse returned 13,757 errors out of 481,335 requests, about 2.86%. Over the hour from 23:00 to 00:00 UTC the incident used .78 availability points.\n\nOn the primary, patroni-06, the data disk saw excessive IO latency and the node lost network connectivity to Consul at the same time. At 23:40 Patroni invalidated the lock held by patroni-06 and began a failover, at 23:41 patroni-03 became the new primary, and at 23:42 the error rates dropped back.\n\nThe responders saw more degradation than they had expected and cancelled the snapshots in two of the three zones, but did not realise during the incident that the primary had actually failed over. They noticed the failover only later, when they moved on to the next steps of the change plan. Metrics and logs examined afterwards confirmed the link between the snapshot and the failover, although the metric data looked somewhat contradictory.","ko":"2021-01-16 23:38 UTC 부터 GitLab.com 의 오류가 급증했고 23:39 에 서비스 중단 알림이 여러 개 들어왔다. 데이터베이스 쓰기가 필요한 요청 일부가 5xx 오류를 받았다.\n\n오류는 약 4~5분 이어졌다. Rails 에서는 23:38:30 과 23:42:00 사이에 약 2,000건의 5xx 오류가 났고, 기록된 요청 1,521,180건에 견주면 약 0.133% 였다. Workhorse 에서는 481,335건 가운데 13,757건으로 약 2.86% 였다. 장애 중에 확인 삼아 새로 고친 페이지는 정상으로 떴다.\n\n23:40 에 Patroni 가 patroni-06 의 락을 무효로 하고 장애 조치를 시작했고, 23:41 에 patroni-03 이 새 주 노드가 됐다. 23:42 에 오류율이 내려갔다.\n\n팀은 마지막으로 한 작업인 스냅샷이 원인이라는 것을 곧바로 알았다. 예상보다 심한 성능 저하를 보고 세 존 가운데 두 존의 스냅샷을 취소했다. 하지만 장애 조치까지 일어났다는 것은 장애 중에 알아채지 못했고, 변경 계획의 다음 단계를 진행하면서 나중에 알았다."},"updated_at":"2026-11-14T12:33:57.438021Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0321","org_slug":"gitlab"}