{"id":"IL-0309","org":"Preset","date":"2026-04-13","docs":[],"title":{"en":"Preset's RDS PostgreSQL 14.7 to 17.9 upgrade in US East 1 ran out of storage and took Superset down for six hours","ko":"RDS PostgreSQL 메이저 버전 업그레이드가 점검 시간을 훨씬 넘겨 실패하면서 us2a 배포가 약 6시간 멈췄다"},"domain":["database","aws"],"impact":{"scope":"Superset was unavailable for about 6 hours for all customers on the us2a production deployment; no data was lost or corrupted","users":"All customers on the us2a production deployment","region":"US East 1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Preset learned that RDS takes a full, non-incremental snapshot before a major version upgrade, so the duration of the daily incremental snapshots and of the upgrades in other regions said nothing about how long the pre-upgrade snapshot would take on this instance. The S3 snapshot throughput limit of about 30–45MB/s only becomes visible during such full snapshots, which are rare in normal operation.","ko":"RDS 는 메이저 버전 업그레이드 전에 기존 스냅샷과 상관없이 전체 스냅샷을 찍는다. 같은 인스턴스의 증분 스냅샷 시간이나 다른 환경의 업그레이드 시간으로는 이 스냅샷이 얼마나 걸릴지 알 수 없었고, 약 30~45MB/s 인 S3 스냅샷 처리량 상한은 드문 전체 스냅샷에서만 드러났다. 그래서 Preset 은 다음 메이저 버전 업그레이드 전에 운영 규모의 데이터로 저장 공간과 소요 시간을 먼저 확인한다."},"related":[],"sources":[{"url":"https://status.preset.io/incidents/01KP34GXYRB4A4RHNH1Y43KSWM/write-up","kind":"official-status","archived":null}],"summary":{"en":"Preset planned to upgrade every RDS PostgreSQL instance in production US East 1 from 14.7 to 17.9. The API Gateway and Examples instances finished by 04:18 EDT, but the primary database instance went through 38 minutes of pre-upgrade checks and then a pre-upgrade snapshot that ran for about 4.5 hours. Before a major version upgrade, RDS takes a full, non-incremental snapshot regardless of any snapshots that already exist, while the daily automated snapshots of this instance are incremental, which is why they had always been quick. Preset states that S3 snapshot throughput is an AWS-side limit of about 30–45MB/s regardless of the EBS volume's provisioned throughput, so a full snapshot of 440GB at about 40MB/s takes at least about 3 hours, and that this limit only shows during full snapshots, which are rare in normal operation.\n\nThe volume was 500GB, with about 440GB used and about 64GB free at the start. During the long snapshot the remaining ~60GB of free storage was taken by the snapshot's temporary files and metadata, by pg_upgrade working files and output logs, and by WAL that accumulated while the snapshot ran. When free storage reached zero, the upgrade failed at 09:37 EDT. The pre-upgrade snapshot completed at 10:10, and AWS rolled the instance back automatically to its pre-upgrade state on PostgreSQL 14.15 without restoring from a snapshot. The instance restarted at 10:13 in a consistent state with no data loss and no manual intervention, and a post-rollback snapshot ran automatically until 11:29.","ko":"04:12 EDT 에 Preset 은 US East 1 운영 리전의 RDS 인스턴스를 PostgreSQL 14.7 에서 17.9 로 올리는 업그레이드를 시작했다. 주 데이터베이스 인스턴스는 38분 동안 사전 검사를 마친 뒤 04:51 에 내려가 스냅샷을 찍기 시작했다. 이 인스턴스의 볼륨은 500GB 였고 약 440GB 를 쓰고 있어 여유 공간은 약 64GB 였다. 스냅샷이 약 4.5시간 이어지는 동안 전체 스냅샷의 임시 파일과 메타데이터, pg_upgrade 작업 파일과 출력 로그, 길어진 스냅샷 동안 쌓인 WAL 이 남은 약 60GB 를 다 썼다. 여유 공간이 0이 되자 09:37 에 업그레이드가 실패했다.\n\n스냅샷이 오래 걸린 이유는 RDS 가 메이저 버전 업그레이드 전에는 기존 스냅샷이 있어도 증분이 아닌 전체 스냅샷을 찍기 때문이었다. 이 인스턴스의 일일 자동 스냅샷은 증분이라 10~15분에 끝났고, 다른 리전의 업그레이드도 비슷한 시간에 스냅샷을 마쳤다. S3 스냅샷 처리량은 AWS 쪽 제약 때문에 EBS 볼륨에 프로비저닝한 처리량과 상관없이 약 30~45MB/s 를 넘지 못한다. 440GB 를 약 40MB/s 로 찍으면 전체 스냅샷에 최소 약 3시간이 걸린다. 그러나 이 상한은 평소에 드물게 찍는 전체 스냅샷에서만 드러났다. Preset 은 운영 이력과 AWS 문서 어디에도 이 인스턴스의 업그레이드 전 스냅샷이 약 4.5시간 걸린다는 분명한 단서가 없었다고 했다.\n\n업그레이드가 실패하자 AWS 가 인스턴스를 업그레이드 전 상태로 자동으로 되돌렸다. 업그레이드 전 스냅샷은 10:10 EDT 에 끝났고, 인스턴스는 10:13 EDT 에 PostgreSQL 14.15 로 다시 올라와 서비스가 돌아왔다. 스냅샷에서 복원하지 않고 원래 데이터베이스 엔진을 되살렸기 때문에 데이터 손실이나 손상은 없었고, 수동 개입도 필요 없었다. 롤백 뒤 스냅샷은 자동으로 찍혀 11:29 EDT 에 끝났다. us2a 배포의 고객은 약 6시간 동안 Superset 을 쓰지 못했다."},"trigger":{"en":"A planned major version upgrade of all RDS instances in production US East 1 from PostgreSQL 14.7 to 17.9, started with a ModifyDBInstance API call at 04:12 EDT.","ko":"Preset 이 US East 1 운영 리전의 모든 RDS 인스턴스에서 PostgreSQL 을 14.7 에서 17.9 로 올리는 계획된 메이저 버전 업그레이드를 시작했다. RDS 가 업그레이드 전에 찍는 전체 스냅샷이 약 4.5시간 이어지면서 주 데이터베이스 인스턴스의 남은 저장 공간을 다 썼다."},"severity":"unknown","symptoms":["service-unavailable","upgrade-stuck"],"timeline":{"detected_after":null,"resolved_after":"6h"},"date_kind":"incident","detection":{"en":"The planned upgrade was being watched as it ran: the snapshot's I/O was observed at 05:28 EDT, the incident was posted on the status page at 06:00 EDT and an AWS support ticket was opened at 07:26 EDT.","ko":"Preset 은 계획된 업그레이드를 지켜보던 중 05:28 EDT 에 스냅샷의 I/O 급증을 보았다. 06:00 에 상태 페이지에 사고를 올렸고, 07:26 에 AWS 지원 티켓을 열었다."},"components":["database","database-backup"],"root_cause":"capacity","remediation":[{"text":{"en":"AWS rolled the failed upgrade back automatically, and the instance restarted on PostgreSQL 14.15 at 10:13 EDT","ko":"업그레이드가 실패한 뒤 AWS 가 인스턴스를 업그레이드 전 상태로 자동으로 되돌렸고, 인스턴스가 10:13 EDT 에 PostgreSQL 14.15 로 다시 올라와 서비스가 돌아왔다. 수동 개입은 없었다."}}],"action_items":[{"text":{"en":"Rehearse the upgrade against a full production-scale dataset to check storage and timing estimates before any future major version upgrade","ko":"다음 메이저 버전 업그레이드를 시도하기 전에 운영 규모의 전체 데이터로 업그레이드 과정을 미리 해 보고 저장 공간과 소요 시간 추정이 맞는지 확인한다."}}],"contributing":["staging-not-representative","assumption-unverified","limit-unknown","limited-debug-access"],"recurrence_of":null,"symptoms_text":{"en":"A planned major version upgrade of Preset's production RDS PostgreSQL instances in US East 1, from 14.7 to 17.9, ran far past its maintenance window, and all customers on the us2a deployment could not reach Superset. After more than five hours the upgrade failed with \"Postgres cluster is in a state where pg_upgrade cannot be completed successfully.\"\n\nThe upgrade began with a ModifyDBInstance API call at 04:12 EDT. The pre-upgrade compatibility checks on the primary instance took 38 minutes, and at 04:51 the instance shut down and a snapshot started. At 05:28 the snapshot showed sequential reads at about 45MB/s with writes near zero. At 08:00 I/O throughput rose to about 55MB/s and CPU jumped to about 70%, which looked like a change of phase, and at 09:22 reads fell to near zero while writes rose to 130MB/s, which looked like the instance recovering. At 09:37 RDS reported the upgrade as failed.\n\nNothing before the window pointed to a long snapshot. The same upgrade had finished in under 15 minutes on sandbox, staging and several other production regions, and the daily automated snapshots of this instance always took 10–15 minutes. An AWS support ticket opened at 07:26 got the reply at 08:36 that the upgrade was progressing normally, that no intervention was possible and that there was no ETA.","ko":"US East 1 운영 리전의 RDS PostgreSQL 을 14.7 에서 17.9 로 올리는 계획된 업그레이드가 점검 시간이 지나도 끝나지 않았다. 그동안 us2a 배포의 모든 고객이 Superset 에 접속하지 못했다.\n\n04:12 EDT 에 ModifyDBInstance 호출로 업그레이드를 시작했다. API Gateway 와 Examples 인스턴스는 04:18 에 업그레이드를 마쳤지만, 주 데이터베이스 인스턴스는 사전 호환성 검사에만 38분이 걸렸다. 04:51 에 인스턴스가 내려가고 스냅샷이 시작됐다.\n\n스냅샷은 몇 시간 동안 이어졌다. 05:28 에는 순차 읽기가 약 45MB/s 였고 쓰기는 거의 0이었다. 08:00 에는 I/O 처리량이 약 55MB/s 로 오르고 CPU 가 약 70% 로 뛰어 단계가 바뀌는 것처럼 보였다. 09:22 에는 읽기가 거의 0으로 떨어지고 쓰기가 130MB/s 로 치솟아 인스턴스가 회복하는 것처럼 보였다.\n\n09:37 에 업그레이드가 \"Postgres cluster is in a state where pg_upgrade cannot be completed successfully.\" 오류로 실패했다. 500GB 볼륨에서 시작 때 약 64GB 남아 있던 여유 공간이 0이 된 뒤였다.\n\n스냅샷이 약 2.5시간째 진행 중이던 07:26 에 AWS 지원 티켓을 열었다. 08:36 에 AWS 는 업그레이드가 정상으로 진행 중이고, 개입할 방법이 없으며, 예상 완료 시각도 알 수 없다고 답했다.\n\n이 업그레이드는 샌드박스, 스테이징, 여러 운영 리전에서 15분 안에 끝났다. 같은 인스턴스의 일일 자동 스냅샷도 늘 10~15분에 끝났기 때문에, 업그레이드 전 스냅샷이 약 5시간 걸리리라고 볼 근거가 없었다."},"updated_at":"2026-11-14T12:33:56.309246Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0309","org_slug":"preset"}