{"id":"IL-0531","org":"Microsoft Azure","date":"2024-04-19","docs":["https://learn.microsoft.com/azure/databricks/administration-guide/disaster-recovery","https://learn.microsoft.com/azure/postgresql/flexible-server/overview"],"title":{"en":"Azure Database for MySQL Single Server and MariaDB in West US rejected every new connection for a batch of servers","ko":"West US 의 Azure Database for MySQL Single Server 와 MariaDB 일부 서버로 가는 새 연결이 모두 거부됐다"},"domain":["azure","database","networking"],"impact":{"scope":"All new connections to a subset of Azure Database for MySQL - Single Server and Azure Database for MariaDB servers failed; Azure Databricks workspace logins, authentication, cluster operations, jobs, UI and Databricks SQL queries, SQL Serverless Warehouses and UC APIs failed or timed out","users":"A subset of Azure Database for MySQL - Single Server and Azure Database for MariaDB customers, and Azure Databricks customers","region":"West US; Azure Databricks in West US, West US 2 and South Central US"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://azure.status.microsoft/en-us/status/history/?trackingId=QS3K-BPZ","kind":"official-status","archived":null}],"summary":{"en":"All connections to Azure Database for MySQL - Single Server and Azure Database for MariaDB go through a gateway that routes each incoming connection to its server. The gateway runs on a group of stateless compute nodes behind one IP address. The hardware of the gateway is refreshed from time to time: a new ring of gateway nodes with a different IP address is built first, customers are told by email and in the Azure portal to allow the new gateway IP in their outbound rules, and once the new ring works, the DNS for existing servers is updated so that new client connections go to the new ring and the old hardware can be decommissioned.\n\nOn 19 April 2024 this move was scheduled for existing servers in West US. At 04:26 UTC the DNS update was made for a batch of MySQL and MariaDB servers, but because of a procedural error the new connections went to a newly built gateway ring whose configuration was incomplete. That ring was not ready to accept connections, logins failed at the gateway, and the gateway rejected every new incoming connection to those servers. The ring also had no telemetry or monitoring configured yet, so the failure was not detected from service telemetry until Azure Databricks reported unreachable databases at 04:46 UTC. The MySQL on-call engineers found the databases healthy at 05:14 UTC, the networking team joined at 05:44 UTC, and at 06:46 UTC the issue was correlated with the gateway move and the rollback began. The incident was mitigated at 07:30 UTC, when the change had been fully rolled back and, after validation, all connections had moved back to the previous working gateway ring. Azure Databricks, which depends on the database service, had failed logins, jobs and queries in West US, West US 2 and South Central US during the same period.","ko":"Azure Database for MySQL - Single Server 와 Azure Database for MariaDB 로 가는 모든 연결은 들어오는 연결을 각 서버로 보내는 게이트웨이를 거친다. 게이트웨이는 IP 주소 하나 뒤에 있는 상태 없는 컴퓨트 노드 묶음이다. 게이트웨이 하드웨어를 교체할 때는 IP 주소가 다른 새 게이트웨이 링을 먼저 만들고, 새 링이 완전히 동작하면 DNS 를 바꿔 기존 서버의 새 연결을 새 링으로 보낸다.\n\n2024-04-19 West US 리전에서 기존 서버의 트래픽을 새 게이트웨이 링으로 옮기는 계획된 유지보수가 있었다. 04:26 UTC 에 MySQL 과 MariaDB 서버 한 묶음의 DNS 를 바꿨다. 절차상의 실수로 새 연결이 새 게이트웨이 링으로 갔는데, 이 링은 설정이 덜 끝나 아직 연결을 받을 준비가 되지 않았다. 이 링에서 로그인 요청이 실패해 게이트웨이가 이 서버들로 가는 새 연결을 모두 거부했다. 새 링에는 텔레메트리와 모니터링도 아직 설정되지 않아 서비스 텔레메트리로는 실패를 잡지 못했다. 이 데이터베이스에 기대는 Azure Databricks 는 West US, West US 2, South Central US 에서 로그인, 인증, 클러스터 작업, 잡, 쿼리가 실패했다.\n\n04:46 UTC 에 Azure Databricks 가 MySQL 팀에 여러 데이터베이스에 닿을 수 없다고 알렸다. MySQL 당번 엔지니어들은 05:14 UTC 에 데이터베이스는 정상이지만 연결이 맺어지지 않는다는 것을 확인했고, 05:44 UTC 에 네트워크 팀이 합류했다. 엔지니어들은 06:46 UTC 에 문제를 새 게이트웨이 링으로 트래픽을 옮긴 작업과 연결 지었고 롤백을 시작했다. 07:30 UTC 에 변경이 완전히 롤백됐다. 검증을 거쳐 모든 연결이 정상 동작하던 이전 게이트웨이 링으로 돌아가면서 장애가 완화됐다."},"trigger":{"en":"At 04:26 UTC, during planned maintenance in West US, the DNS update that moves new incoming connections for a batch of MySQL and MariaDB servers to a new gateway ring was made, and a procedural error pointed it at a newly built gateway ring whose configuration was incomplete.","ko":"계획된 게이트웨이 하드웨어 교체 작업에서 2024-04-19 04:26 UTC 에 Azure Database for MySQL 과 MariaDB 서버 한 묶음의 DNS 를 바꿨다. 절차상의 실수로 새 연결이 설정이 덜 끝난 새 게이트웨이 링으로 보내졌다."},"severity":"unknown","symptoms":["service-unavailable","intermittent-timeouts"],"timeline":{"detected_after":"20m","resolved_after":"3h 4m"},"date_kind":"incident","detection":{"en":"Service telemetry did not detect the failure because the new gateway ring had no telemetry or monitoring configured yet. At 04:46 UTC Azure Databricks reported to the MySQL team that multiple databases were unreachable.","ko":"새 게이트웨이 링에 텔레메트리와 모니터링이 없어 서비스 텔레메트리는 실패를 잡지 못했다. MySQL 팀은 04:46 UTC 에 Azure Databricks 가 여러 데이터베이스에 닿을 수 없다고 알려 와서 장애를 알았다."},"components":["database","dns-server"],"root_cause":"human-operation","remediation":[{"text":{"en":"Rolled back the DNS change and moved all connections back to the previous working gateway ring after validation","ko":"07:30 UTC 에 변경을 완전히 롤백했고, 검증을 거쳐 모든 연결을 정상 동작하던 이전 게이트웨이 링으로 되돌렸다."}}],"action_items":[{"text":{"en":"Add checks, testing and sign-off procedures before switching production gateway rings","ko":"MySQL 엔지니어링 팀은 운영 게이트웨이 링을 전환하기 전에 점검, 테스트, 승인 절차를 더한다. 2024년 5월에 마칠 예정이다."}},{"text":{"en":"Add Azure Databricks alerts that detect multiple databases becoming unavailable within a short time","ko":"Azure Databricks 엔지니어링 팀은 짧은 시간 안에 여러 데이터베이스를 쓸 수 없게 되는 상황을 잡는 알림을 만든다. 2024년 5월에 마칠 예정이다."}}],"contributing":["monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"From 04:26 UTC on 19 April 2024, every new connection to a subset of Azure Database for MySQL - Single Server and Azure Database for MariaDB servers in West US failed, and retries did not help. The first report came at 04:46 UTC from Azure Databricks, which told the MySQL team that multiple databases were unreachable.\n\nAzure Databricks depends on the affected database service, so Databricks customers in West US, West US 2 and South Central US saw workspace login and authentication requests fail or time out. Cluster CRUD requests and jobs that needed a cluster to start, resize or terminate did not run, jobs submitted through APIs or schedulers did not run, UI and Databricks SQL queries timed out, Databricks SQL Serverless Warehouses failed to launch and UC APIs could not be reached. The errors cited \"Authentication is temporarily unavailable\" or \"TEMPORARILY_UNAVAILABLE\".\n\nAt 05:14 UTC the MySQL on-call engineers found that the databases themselves were healthy but no connections were reaching them. The networking team joined at 05:44 UTC. Service telemetry showed nothing, because the gateway ring that received the connections was not fully configured and had no telemetry or monitoring yet. At 06:46 UTC the failures were linked to the move of traffic to a new gateway ring.","ko":"West US 리전에서 Azure Database for MySQL - Single Server 와 Azure Database for MariaDB 의 일부 고객은 데이터베이스로 가는 연결이 모두 실패했고, 재시도해도 성공하지 못했다. 데이터베이스 자체는 정상이었지만 연결이 하나도 맺어지지 않았다.\n\n이 데이터베이스에 기대는 Azure Databricks 는 West US, West US 2, South Central US 에서 함께 실패했다. 워크스페이스 로그인과 인증 요청이 실패하거나 타임아웃이 났다. 클러스터 CRUD 요청과 클러스터 시작, 크기 조정, 종료에 기대는 작업이 실행되지 않았다. API 나 스케줄러로 제출한 작업도 실행되지 않았다. UI 와 Databricks SQL 쿼리는 타임아웃이 났다. Databricks SQL Serverless Warehouses 를 띄우지 못했고 UC API 에 접근하지 못했다. 고객은 \"Authentication is temporarily unavailable\" 또는 \"TEMPORARILY_UNAVAILABLE\" 오류를 보았다.\n\n새 게이트웨이 링은 준비가 덜 끝난 상태여서 텔레메트리와 모니터링도 아직 설정되지 않았다. 그래서 서비스 텔레메트리에는 실패가 보이지 않았고, 내부 팀이 데이터베이스에 닿을 수 없다고 알려 올 때까지 문제가 드러나지 않았다.\n\nMySQL 당번 엔지니어들은 05:14 UTC 에 데이터베이스는 정상인데 연결이 맺어지지 않는다는 것까지 확인했고, 05:44 UTC 에 네트워크 팀을 조사에 불렀다. 문제를 새 게이트웨이 링으로 트래픽을 옮기려던 작업과 연결한 것은 06:46 UTC 였다."},"updated_at":"2026-11-14T12:34:17.427182Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0531","org_slug":"microsoft-azure"}