IL-0380 InfluxData · 2026-02-09databaseaws

AWS us-east-1 의 InfluxDB Cloud 클러스터에서 압축 중에 일부 데이터가 빠져 쿼리에 나오지 않았다

InfluxDB Cloud 2 의 데이터는 64개 파티션으로 나뉘고, 압축하지 않은 데이터는 쿼리가 느리므로 파티션마다 정기적으로 압축한다. 1월에 InfluxData 는 prod101-us-east-1 의 파티션 47 이 더는 제대로 압축되지 않는다는 것을 찾았다. 일부만 압축된 파일이 쌓여 성능에 영향을 주기 시작했다. 엔지니어링 팀은 org id 접두사를 기준으로 파티션 데이터를 나눠 여러 압축 작업을 동시에 돌리는 최적화를 만들었다. 이 변경은 표준 릴리스 절차대로 엔지니어 두 명이 더 리뷰했다. 그러나 이 최적화에는 버그가 있었다. 어떤 조건에서는 압축기가 원본 TSM 데이터 파일 일부를 읽다가 실패했는데, 압축기는 이 실패를 제대로 처리하지 않고 그 TSM 파일을 조용히 건너뛰었다. 그리고 나머지 데이터만 압축한 뒤 원본 파일을 압축한 파일로 바꿨다. 이 문제는 코드 리뷰와 내부 테스트에서 걸리지 않았고, 2월 9일 변경을 prod101-us-east-1 에 적용한 뒤에야 드러났다.

2월 9일 첫 티켓이 들어와 조사를 시작했고, 2월 10일 티켓이 더 들어와 근본 원인을 찾았다. 팀은 같은 날 압축 변경을 롤백하고 복원을 시작했다. Cloud 2 는 백업을 두 가지 둔다. 클러스터마다 주간 TSM 스냅숏을 찍고, 들어오는 쓰기는 모두 Kafka 로그에 스냅숏으로 기록한다. 두 백업이 함께 클러스터에 쓴 데이터의 완전한 기록이 되므로 데이터를 영영 잃지는 않았다. 고객이 실시간 작업에 클러스터를 쓰므로 클러스터를 켠 채로 조금씩 복원했다. 고객 운영에 가장 중요한 최근 데이터를 Kafka 로그에서 먼저 되살린 뒤 과거 데이터를 TSM 스냅숏에서 복원했다. 2월 12일 일부 시험 고객의 최근 데이터 복원을 마치고 모든 고객으로 넓혔고, 2월 17일 과거 데이터 복원을 효율적으로 고쳤다. 2월 23일 모든 고객의 2월 2일부터 9일까지 데이터 복원을 마치고 2월 2일 이전 데이터 복원을 다시 시작했다. 3월 8일 유료 고객 전부의 과거 데이터 복원을 마쳤고, 3월 10일 장애를 해결로 닫았다. 복원하는 동안 일부 고객은 TTBR 이 높아지고 쿼리가 느려졌다.

심각도: –
영향 범위: Data in partitions compacted while the faulty code ran on prod101-us-east-1 was missing from queries until restored from backup; elevated TTBR and slower queries during the restore; no permanent data loss
영향 사용자: –
지역: AWS us-east-1
감지까지: –
복구까지: –