{"id":"IL-0295","org":"Pusher","date":"2022-04-11","docs":[],"title":{"en":"Pusher's Channels publish API on the mt1 cluster was largely unavailable for 11 minutes while a Redis master failed over","ko":"Pusher Channels mt1 클러스터의 메시지 발행 API 가 Redis 장애 조치 도중 11분 동안 거의 멈췄다"},"domain":["database"],"impact":{"scope":"Publishing to Channels on the mt1 cluster largely unavailable; messages delayed or lost","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.pusher.com/incidents/scvz124sfw8f","kind":"official-status","archived":"https://web.archive.org/web/20221208170628/https://status.pusher.com/incidents/scvz124sfw8f"}],"summary":{"en":"Pusher runs Redis in groups of one master and two replicas, and since the beginning of November 2021 had been moving all groups to a new version of its Redis group module. Every node of the new groups runs a script at node termination that checks whether the node is a Redis master and, if it is, starts a failover to one of the replicas. To help the clusters cope with more traffic, Pusher increased the replication buffer size in the Redis configuration of every group, which needed each Redis node to be restarted; this had already been done on test clusters and on one smaller production cluster.\n\nAt 08:47 UTC an engineer began replacing nodes in the mt1 cluster and restarted both replica nodes of one Redis group, one at a time, without problems. At 10:42 the engineer did the same for the master. The failover started, but the Redis process was terminated before it completed. The shutdown script assumed that once the failover command had run successfully, the node could be terminated; on most clusters failover finishes before the Redis process is killed, but on a heavily loaded cluster such as mt1 the node terminated during failover and left the group in an inconsistent state that takes longer to recover from than no failover at all. After a period in which the old and new masters contended for leadership, the group recovered at 10:53 and the new master handled all messages.","ko":"Pusher 는 2021년 11월부터 Redis 그룹을 새 버전의 모듈로 옮기고 있었다. 그룹 하나는 마스터 하나와 replica 둘로 이루어진다. 노드가 종료될 때 도는 스크립트는 그 노드가 마스터인지 보고, 마스터면 replica 하나로 장애 조치를 실행한다. 늘어나는 트래픽에 대비해 Redis 설정의 복제 버퍼를 키웠고, 이를 반영하려면 Redis 노드를 모두 재시작해야 했다. 이 작업은 테스트 클러스터와 작은 운영 클러스터 하나에서 문제없이 끝난 적이 있었다. 2022-04-11 08:47 UTC 에 엔지니어가 mt1 클러스터에서 노드 교체를 시작해 한 Redis 그룹의 replica 두 대를 하나씩 재시작했다. 10:42 에 마스터 노드에서 같은 작업을 하자 장애 조치는 시작됐지만 끝나기 전에 Redis 프로세스가 종료됐다. 종료 스크립트는 장애 조치 명령이 성공하면 노드를 꺼도 된다고 가정했다. 보통은 장애 조치가 충분히 빨라 맞는 가정이었지만, mt1 처럼 부하가 가장 큰 클러스터에서는 장애 조치 도중에 노드가 꺼졌다. 그룹은 일관되지 않은 상태가 됐고, 이 상태에서 회복하는 데는 장애 조치를 아예 시작하지 않았을 때보다 오래 걸렸다. 옛 마스터와 새 마스터가 리더 자리를 다투다 10:53 에 새 마스터가 자리를 잡았다. 그 11분 동안 메시지 발행은 거의 실패했고, 일부 메시지가 사라졌을 수 있다."},"trigger":{"en":"An engineer restarted the master node of an mt1 Redis group to apply a larger replication buffer, after restarting both replicas of that group.","ko":"엔지니어는 Redis 설정의 복제 버퍼를 키운 것을 반영하려고 mt1 클러스터의 노드를 하나씩 교체하다가, 10:42 UTC 에 마스터 노드를 재시작했다. 장애 조치는 시작됐지만 끝나기 전에 Redis 프로세스가 종료됐다."},"severity":"unknown","symptoms":["service-unavailable","high-latency","split-brain"],"timeline":{"detected_after":null,"resolved_after":"11m"},"date_kind":"incident","detection":{"en":"Pusher saw error rates rise for requests to the MT1 API from about 10:44 UTC.","ko":"Pusher 는 10:44 UTC 무렵부터 MT1 API 요청의 오류율이 오른 것을 확인하고 상태 페이지에 알렸다."},"components":["cache","failover-manager"],"root_cause":"software-bug","remediation":[],"action_items":[{"text":{"en":"Fix the Redis shutdown script to check that failover has completed and the node is no longer a master before terminating","ko":"Redis 종료 스크립트가 노드를 끄기 전에 장애 조치가 끝났고 그 노드가 더는 마스터가 아닌지 확인하도록 고친다."}}],"contributing":["assumption-unverified","staging-not-representative"],"recurrence_of":null,"symptoms_text":{"en":"At 10:42 UTC on 11 April 2022, the API for publishing messages to Pusher Channels on the mt1 cluster became largely unavailable, and from about 10:44 requests to the MT1 API returned more errors.\n\nUntil 10:53, users could fail to publish messages, receive messages late with more than 900ms end-to-end latency, or not receive messages at all, and some messages may have been lost. During this time the old and the new master of one Redis group were both contending for leadership.","ko":"2022-04-11 10:42 UTC 부터 mt1 클러스터에서 Channels 메시지 발행 API 를 11분 동안 거의 쓸 수 없었다. 상태 페이지는 10:44 무렵부터 10:53 무렵까지 MT1 API 요청의 오류율이 올랐다고 알렸다.\n\n사용자는 메시지 발행이 실패하거나, 메시지가 종단 간 지연 900ms 를 넘겨 늦게 도착하거나, 메시지가 전달되지 않고 사라지는 일을 겪었을 수 있다.\n\n장애 동안 Redis 그룹 안에서 옛 마스터와 새 마스터가 리더 자리를 두고 다퉜다. 10:53 에 그룹이 회복해 새 마스터가 모든 메시지를 처리했다."},"updated_at":"2026-11-14T12:33:55.005858Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0295","org_slug":"pusher"}