{"id":"IL-0300","org":"37signals","date":"2018-11-09","docs":[],"title":{"en":"Basecamp 3 went read-only for almost five hours when its events table reached the ceiling of 2,147,483,647","ko":"Basecamp 3 의 events 테이블이 데이터베이스 한도에 닿아 서비스가 다섯 시간 가까이 읽기 전용이 되었다"},"domain":["database"],"impact":{"scope":"Basecamp 3 was read-only: existing messages, to-do lists and files could be read, but nothing could be added or changed","users":"Basecamp 3 users","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"The outage was avoidable. The team did not account for how quickly the events table was running out of headroom while it was already working on the problem, and it should have reviewed its own database schema when Rails 5.1 announced the new default in 2017.","ko":"37signals 는 이 장애를 피할 수 있었다고 밝혔다. 장애 전 며칠 동안 events 테이블의 용량을 늘리는 작업을 하면서도 여유가 줄어드는 속도를 제대로 따지지 않았다. 37signals 의 CTO 는 Rails 5.1 이 새 기본값을 발표했을 때 회사의 데이터베이스 스키마를 더 주의 깊게 살폈어야 했다고 썼다. 해결 작업을 시작한 뒤에도 끝까지 챙기며 꼭 필요한 질문을 했어야 했다고 덧붙였다."},"related":[],"sources":[{"url":"https://signalvnoise.com/svn3/postmortem-on-the-read-only-outage-of-basecamp-on-november-9th-2018/","kind":"blog","archived":"https://web.archive.org/web/20260120091637/https://signalvnoise.com/svn3/postmortem-on-the-read-only-outage-of-basecamp-on-november-9th-2018/"}],"summary":{"en":"Basecamp 3 records almost every user activity, such as posting a message, updating a to-do list or applauding a comment, in its events table. On November 9th, 2018 that table reached the ceiling of 2,147,483,647, the database could not write new events, and practically every action in Basecamp 3 stopped. Basecamp 3 stayed in read-only mode from 7:21am to 12:11pm CST, almost five hours. The fix raised the ceiling of the tables from 2,147,483,647 to 9,223,372,036,854,775,807.\n\nThe team had been working on expanding the capacity of the events table in the days before the outage, but had not accounted for how fast the remaining headroom was running out. Ruby on Rails 5.1, released in 2017, had already changed its default for database tables in the same way, raising the ceiling for records from 2,147,483,647 to 9,223,372,036,854,775,807. Basecamp's CTO, who created Rails, wrote that he should have checked Basecamp's own schema when Rails 5.1 announced the new default. It was the worst Basecamp outage in probably ten years, and it took Basecamp 3's uptime record since launch from 99.998% to 99.978%.","ko":"2018년 11월 9일 Basecamp 3 가 CST 기준 오전 7시 21분부터 낮 12시 11분까지 다섯 시간 가까이 읽기 전용 상태였다. 사용자는 기존 메시지, 할 일 목록, 파일을 볼 수 있었지만 아무것도 새로 넣거나 고칠 수 없었다. 근본 원인은 사용량이 아주 많은 events 테이블이 데이터베이스의 한도인 2,147,483,647 에 닿은 것이었다. Basecamp 의 거의 모든 활동이 이 테이블에 기록되므로, 새 이벤트를 쓰지 못하게 되자 거의 모든 동작이 멈췄다.\n\n37signals 는 장애 며칠 전부터 events 테이블의 용량을 늘리는 작업을 하고 있었지만, 남은 여유가 얼마나 빨리 줄고 있는지 제대로 계산하지 못했다. Basecamp 가 쓰는 Ruby on Rails 는 2017년에 나온 5.1 버전에서 데이터베이스 테이블의 기본값을 바꿔, 모든 테이블의 레코드 한도를 2,147,483,647 에서 9,223,372,036,854,775,807 로 올렸다. 37signals 가 이번에 Basecamp 의 테이블에 적용한 근본 해결책도 이와 같은 변경이었다. 이 장애로 Basecamp 3 출시 이후 99.998% 였던 가동률이 99.978% 로 내려갔다. 37signals 는 이 장애가 Basecamp 에서 아마 10년 사이 가장 큰 장애였다고 밝혔다."},"trigger":{"en":"The busy events table, which records almost every activity in Basecamp 3, reached its ceiling of 2,147,483,647, and new events could not be written.","ko":"사용량이 아주 많은 events 테이블이 데이터베이스의 한도인 2,147,483,647 에 닿아, 이 테이블에 새 이벤트를 쓸 수 없게 되었다."},"severity":"unknown","symptoms":["writes-rejected"],"timeline":{"detected_after":null,"resolved_after":"4h 50m"},"date_kind":"incident","detection":null,"components":["database"],"root_cause":"capacity","remediation":[{"text":{"en":"Raised the ceiling of the tables from 2,147,483,647 to 9,223,372,036,854,775,807, the same change as the Rails 5.1 default","ko":"Rails 5.1 이 모든 테이블의 새 기본값으로 바꾼 것과 같은 변경을 Basecamp 의 테이블에 적용해 레코드 한도를 9,223,372,036,854,775,807 로 올렸다."}}],"action_items":[],"contributing":["no-capacity-planning"],"recurrence_of":null,"symptoms_text":{"en":"On November 9th, 2018, from 7:21am to 12:11pm CST, Basecamp 3 was in read-only mode. Users could open existing messages, to-do lists and files, but could not add anything new or change anything that was already there.\n\nThe database could no longer write new rows to the events table, which had reached its ceiling of 2,147,483,647. Basecamp records almost every activity in this table, such as posting a message, updating a to-do list or applauding a comment, so practically every action in Basecamp 3 stopped once new events could not be written.","ko":"Basecamp 3 가 읽기 전용 상태가 되었다. 사용자는 기존 메시지, 할 일 목록, 파일을 볼 수 있었지만 새 내용을 넣을 수 없었고 기존 내용도 고칠 수 없었다.\n\nBasecamp 의 거의 모든 활동은 events 테이블에 기록된다. 메시지를 올리거나 할 일 목록을 고치거나 댓글에 박수를 보내는 일이 모두 이 테이블에 쓰인다. 이 테이블에 새 이벤트를 쓸 수 없게 되자 Basecamp 에서 하려는 거의 모든 동작이 멈췄다.\n\n읽기 전용 상태는 CST 기준 오전 7시 21분에 시작해 낮 12시 11분에 끝났다. 그동안 모든 내용이 그대로 멈춰 있었다."},"updated_at":"2026-11-14T12:33:55.398100Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0300","org_slug":"37signals"}