{"id":"IL-0371","org":"Render","date":"2023-04-21","docs":[],"title":{"en":"Half of new connections to Render Postgres databases with point-in-time recovery failed while their backup jobs ran","ko":"PITR 을 켠 Render Postgres 데이터베이스에서 백업이 도는 동안 새 연결의 절반이 실패했다"},"domain":["database","networking"],"impact":{"scope":"New connections to PITR-enabled Render Postgres databases while a PITR backup job was running; existing connections were unaffected","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.render.com/incidents/lvz7ycrpb5nx","kind":"official-status","archived":"https://web.archive.org/web/20240422184826/https://status.render.com/incidents/lvz7ycrpb5nx"}],"summary":{"en":"Render Postgres databases are reached through a stable internal service name such as dpg-123abc, which the cluster keeps pointed at the database's current IP address. The daily PITR backup job, which keeps an accurate restore point for each database, was given networking labels similar to the database's own, so the routing layer added the backup job's IP address to the database's service name as a second target. The backup job ran no database, so new connections routed to it failed, which made half of new connections fail while a backup was running. Render first disabled backups on the affected databases. When backups were turned back on, the scheduler for asynchronous jobs immediately ran a backup that it counted as a recently missed run, which caused downtime during business hours. Render changed the backup job's network labels so the routing layer no longer treats it as a database endpoint, and the incident was marked resolved on 27 April 2023.","ko":"Render Postgres 데이터베이스에는 dpg-123abc 같은 고정 내부 서비스 이름으로 연결한다. 이 서비스 이름은 클러스터가 관리하고, 데이터베이스의 IP 주소가 바뀌면 라우팅 설정에 반영한다. 2023년 4월 21일 Render 는 Point-in-time Recovery 기능을 조건이 맞는 새 데이터베이스에 내놨다. PITR 은 복원 요청이 오면 정확한 복원 지점을 쓸 수 있도록 매일 데이터베이스를 백업하는데, 이 백업 작업이 데이터베이스와 비슷한 네트워크 레이블로 설정되어 있었다. 라우팅 계층은 이 설정을 보고 백업 작업의 IP 주소를 데이터베이스 서비스 이름의 연결 대상으로 더했다. 백업 작업에서는 데이터베이스가 돌지 않으므로 그 IP 로 간 새 연결은 실패했다. 그래서 백업이 도는 동안 새 연결의 50%가 실패했다.\n\nRender 는 영향받은 데이터베이스의 백업을 트래픽이 적은 시간에 예약할 수 있을 때까지 껐다. 그런데 비동기 작업 스케줄러는 최근 놓친 실행이 있으면 예약 시간대 밖에서도 곧바로 작업을 시작했다. 그래서 백업을 다시 켜고 예약하자 백업이 바로 돌았고, 업무 시간에 장애가 다시 났다. 처음 보는 문제여서 엔지니어들은 메모리 동작의 변화를 쫓다가 원인을 찾는 데 시간이 걸렸다. 백업 작업의 네트워크 레이블 설정을 고쳐 라우팅 계층이 백업 작업을 연결 대상으로 잡지 않게 했고, 4월 27일에 장애를 해결로 표시했다."},"trigger":{"en":"Point-in-time Recovery was released to eligible new databases on 21 April 2023, and its backup job carried an incorrect networking configuration.","ko":"Render 는 2023년 4월 21일 Point-in-time Recovery 기능을 조건이 맞는 새 데이터베이스에 내놨다. 이 기능의 백업 작업은 데이터베이스와 비슷한 네트워크 레이블로 설정되어 있었다."},"severity":"unknown","symptoms":["intermittent-connection-failures","requests-misrouted"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":null,"components":["database","database-backup","service-discovery"],"root_cause":"deploy-rollout","remediation":[{"text":{"en":"Disabled backups for affected databases until they could be scheduled in low-traffic hours","ko":"영향받은 데이터베이스의 백업을 트래픽이 적은 시간에 예약할 수 있을 때까지 껐다."}},{"text":{"en":"Changed the backup job's network labels so the routing layer no longer picks it up as a database","ko":"백업 작업의 네트워크 레이블 설정을 고쳐, 라우팅 계층이 백업 작업을 연결 대상 서비스로 잡지 않게 했다."}}],"action_items":[{"text":{"en":"Tighten the process for sharing incident updates so problems are not declared resolved too early","ko":"장애 업데이트를 공유하는 절차를 엄격하게 바꿔, 문제가 실제로 끝나기 전에 해결됐다고 알리지 않게 한다."}},{"text":{"en":"Use more specific network labels for the database routing layer so ineligible IPs are never added","ko":"데이터베이스 라우팅 계층에 더 구체적인 네트워크 레이블 설정을 둬, 연결 대상이 아닌 IP 가 서비스 설정에 들어가지 않게 한다."}},{"text":{"en":"Run a skipped asynchronous job in the next scheduled window instead of immediately","ko":"비동기 작업을 건너뛰었을 때 곧바로 실행하지 않고 다음 예약 시간대로 다시 예약한다."}},{"text":{"en":"Use open source benchmarking software to reproduce issues customers notice","ko":"오픈소스 벤치마크 도구로 시스템을 측정하고, 고객이 알아챈 문제를 재현한다."}}],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"After Point-in-time Recovery (PITR) was released to eligible new Render Postgres databases on 21 April 2023, 50% of new connections to PITR-enabled databases failed while a PITR backup job was running. A backup takes 15 to 45 minutes depending on database size, and existing connections, such as those held through connection pooling, kept working.\n\nRender engineers had not seen this kind of failure before. The engineers noticed a change in memory behaviour, specifically the active page cache, and tried to reproduce it, but that attempt left out the fact that new connections were failing, so finding the root cause took time.\n\nBackups were then disabled for affected databases until they could be scheduled in low-traffic hours. When a backup was enabled and rescheduled, the job ran at once because a recent run had been missed, and this caused another outage during business hours. Some early status updates said the problem was resolved before it was, and some users saw the failures come back.","ko":"특정 시점 복구 기능인 PITR 을 켠 Render Postgres 데이터베이스에 새 연결을 맺으면, PITR 백업 작업이 도는 동안 50% 확률로 실패했다. 커넥션 풀링처럼 이미 맺어 둔 연결은 영향이 없었다.\n\n실패는 백업이 도는 동안에만 났고, 백업은 데이터베이스 크기에 따라 15분에서 45분 걸렸다. 영향받은 데이터베이스의 백업을 트래픽이 적은 시간에 예약하려고 다시 켜자, 놓친 실행이 있다는 이유로 백업 작업이 곧바로 시작돼 업무 시간에 다시 장애가 났다. 초기 공지 일부가 문제가 실제로 끝나기 전에 해결됐다고 알려, 일부 사용자는 문제를 되풀이해 겪었다.\n\n처음 보는 문제여서 근본 원인을 찾는 데 시간이 걸렸다. 엔지니어들은 메모리 동작, 특히 active page cache 의 변화를 보고 그 동작을 재현하려 했다. 그러다 새 연결이 실패한다는 장애의 다른 면을 따져 보지 않았다는 것을 알게 됐다."},"updated_at":"2026-11-14T12:34:02.355399Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0371","org_slug":"render"}