{"id":"IL-0489","org":"Magic Pages","date":"2025-01-15","docs":[],"title":{"en":"Rejoining a failed node of Magic Pages' three-node MySQL cluster broke its metadata and took customer websites down","ko":"Kubernetes 위 3노드 MySQL 클러스터에 노드를 다시 붙이다 메타데이터가 깨져 Magic Pages 고객 사이트가 내려갔다"},"domain":["database","kubernetes"],"impact":{"scope":"Magic Pages customer websites, which depend on the MySQL cluster, from about 09:55 to 11:36 CET","users":"Magic Pages customers","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"The cluster survived the first node failure as designed and lost no data, but its metadata turned out to be a single point of failure. Better monitoring of PVC health could help prevent similar issues, the 45-minute recovery leaves room for improvement, and the status page has to detect failing customer sites reliably.","ko":"고가용성 구성 덕분에 데이터는 잃지 않았고 첫 노드 장애도 클러스터가 문제없이 넘겼다. 하지만 중복 구성인데도 클러스터 메타데이터가 단일 장애 지점이었다. PVC 상태를 더 잘 모니터링했다면 비슷한 문제를 막을 수 있었고, 45분 걸린 복구는 더 줄일 여지가 있다. 상태 페이지는 고객 사이트 실패를 감지하도록 설정했는데도 이 장애를 바로 알아채지 못했다."},"related":[],"sources":[{"url":"https://www.magicpages.co/blog/post-mortem-on-15-january-2025-outage/","kind":"blog","archived":"https://web.archive.org/web/20251204235507/https://www.magicpages.co/blog/post-mortem-on-15-january-2025-outage/"}],"summary":{"en":"Magic Pages runs a three-node high-availability MySQL cluster on Kubernetes, with MySQL Router directing traffic to the database nodes. After one node failed, rejoining it failed with missing-metadata errors, and scaling down to one node to rebuild the metadata spread the errors to the second node. Investigation found that the Kubernetes Persistent Volume Claims appeared to exist but could not provision new volumes for the database nodes that had to be rebuilt.\n\nRecovery took three steps. A restart of the storage server, which took a few seconds, fixed the PVC provisioning. The MySQL nodes then needed about 45 minutes to restore and sync with each other, which the rebuild of the cluster metadata required. Finally the corrupted metadata was cleaned up and MySQL Router was redeployed. No data was lost. The post names the cluster metadata as a single point of failure despite the redundant setup.","ko":"Magic Pages는 노드 세 대로 된 고가용성 MySQL 데이터베이스 클러스터를 쓴다. 2025-01-15 노드 하나가 내려갔고, 나머지 두 노드가 설계대로 서비스를 이어 갔다. 문제는 창업자가 세 번째 노드를 다시 붙이려 할 때 시작됐다. 데이터베이스 서버가 메타데이터가 없다는 모호한 오류를 냈고, 메타데이터를 다시 만들려고 노드 하나로 줄이자 두 번째 노드에서도 비슷한 오류가 났다.\n\n원인은 Kubernetes의 PVC였다. PVC는 있는 것처럼 보였지만 다시 만들어야 하는 데이터베이스 노드에 새 볼륨을 프로비저닝하지 못했다. 스토리지 서버를 재시작하자 몇 초 만에 PVC 프로비저닝 문제가 풀렸다. 클러스터 메타데이터를 다시 만들려면 MySQL 노드들이 복원되고 서로 동기화돼야 해서 약 45분이 걸렸다. 마지막으로 깨진 메타데이터를 정리하고 MySQL Router를 다시 배포하자 장애가 끝났다. 장애는 09:55 CET 무렵부터 11:36 CET까지 고객 웹사이트에 영향을 줬다. 데이터는 잃지 않았다."},"trigger":{"en":"One of the three nodes of the MySQL cluster went down, and reconnecting it failed with errors about missing metadata information.","ko":"그날 앞서 MySQL 클러스터의 세 노드 중 하나가 내려갔고, 창업자가 그 노드를 클러스터에 다시 붙이려 했다."},"severity":"unknown","symptoms":["service-unavailable"],"timeline":{"detected_after":null,"resolved_after":"1h 41m"},"date_kind":"incident","detection":null,"components":["database","persistent-volume"],"root_cause":"dependency-failure","remediation":[{"text":{"en":"Restarted the storage server to fix PVC provisioning","ko":"PVC 프로비저닝 문제를 풀려고 스토리지 서버를 재시작했다. 재시작은 몇 초 만에 끝났다."}},{"text":{"en":"Let the MySQL nodes restore and sync with each other for about 45 minutes to rebuild the cluster metadata","ko":"스토리지가 돌아온 뒤 클러스터 메타데이터를 다시 만들 수 있도록 MySQL 노드들이 복원되고 서로 동기화되기를 약 45분 기다렸다."}},{"text":{"en":"Cleaned up the corrupted cluster metadata","ko":"깨진 클러스터 메타데이터를 정리했다."}},{"text":{"en":"Redeployed MySQL Router","ko":"데이터베이스 노드로 트래픽을 보내는 MySQL Router를 다시 배포했다."}}],"action_items":[{"text":{"en":"Monitor the health of the storage system more closely","ko":"스토리지 시스템의 상태 모니터링을 강화한다."}},{"text":{"en":"Improve the failover procedures for MySQL Router","ko":"MySQL Router의 장애 조치 절차를 개선한다."}},{"text":{"en":"Investigate and fix the status page so it shows reliable information","ko":"상태 페이지가 믿을 만한 정보를 보이도록 문제를 조사하고 고친다."}}],"contributing":["manual-action-worsened","single-point-of-failure","monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"On 15 January 2025, from about 09:55 to 11:36 CET, a database outage at Magic Pages took down customer websites. It began when the founder tried to reconnect a failed third node to the high-availability MySQL cluster and the database server reported ambiguous errors about missing metadata information.\n\nEarlier that day one of the three MySQL nodes had gone down, and the other two had kept serving without interruption. Because errors about missing metadata usually point to cluster configuration problems, the first attempt was to scale the cluster down to a single node and rebuild the metadata. That produced similar errors on the second node. Magic Pages' status page, which is set up to detect failing customer websites, did not notice the outage straight away.","ko":"2025-01-15 09:55 CET 무렵부터 11:36 CET까지 데이터베이스 장애로 Magic Pages의 고객 웹사이트가 영향을 받았다. 노드 세 대로 된 MySQL 클러스터에서 내려간 노드를 다시 붙이려 하자 데이터베이스 서버가 메타데이터 정보가 없다는 모호한 오류를 냈다.\n\n처음에는 클러스터 구성 문제로 보고, 메타데이터를 다시 만들려고 노드 하나로 줄였다. 그러자 두 번째 노드에서도 비슷한 오류가 났다.\n\nKubernetes의 Persistent Volume Claim, 줄여서 PVC는 있는 것처럼 보였지만 다시 만들어야 하는 데이터베이스 노드에 새 볼륨을 제대로 프로비저닝하지 못하고 있었다.\n\nMagic Pages의 상태 페이지는 고객 웹사이트가 실패하면 알아채도록 설정돼 있었지만 이 장애를 바로 잡아내지 못했다."},"updated_at":"2026-11-14T12:34:13.432786Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0489","org_slug":"magic-pages"}