Incident Library

IL-0431 Hatena · 2017-08-07databaseaws

AWS 로 옮기는 점검 중 PostgreSQL 이 의도하지 않게 장애 조치되어 한 시간 동안 갱신된 데이터가 사라졌다

2017년 8월 7일 Hatena 는 Mackerel 을 온프레미스 데이터 센터에서 AWS 로 옮기는 점검을 했다. 데이터베이스는 PostgreSQL 9.3 의 스트리밍 복제로 db000 아래에 db001 을, db001 아래에 db002 를 두는 구성이었다. 작업은 db000 접속을 막고 db001 을 마스터로 승격한 뒤 접속 대상을 db001 로 바꾸는 순서였다. db001 이 승격되면서 db001 에서 db002 로 가는 복제가 멈췄다.

PostgreSQL 은 마스터로 승격할 때 타임라인 ID 를 하나 올린다. PostgreSQL 9.3 의 기본 설정에서는 슬레이브가 새 타임라인 ID 를 가진 WAL 을 받아들이지 않아 복제가 멈춘다. recovery.conf 에 recovery_target_timeline = 'latest' 를 두면 슬레이브가 새 타임라인을 따라간다. Mackerel 팀은 평소 운영에는 이 설정이 필요 없어서 자체 레플리카 생성 스크립트의 옵션으로 필요할 때만 넣었고, 이번에는 그 옵션을 빠뜨렸다. staging 환경에서 같은 구성과 같은 절차로 마이그레이션 시험을 했지만, 그때는 이 설정을 올바르게 넣었기 때문에 문제가 드러나지 않았다.

15시 30분쯤 c4.8xlarge 인스턴스에서 돌던 db001 과 네트워크 통신이 끊겼고, 데이터베이스가 복제가 멈춘 db002 로 장애 조치되었다. 통신이 끊긴 원인은 끝내 밝히지 못했다. 그 결과 14시 30분부터 15시 30분까지 갱신된 데이터가 db002 에 없는 채로 서비스가 이어졌다. 팀은 db001 에 남은 테이블 데이터로 손으로 복구하는 방법과 PITR 로 복구하는 방법을 검토했다. 손으로 복구하면 테이블 사이 정합성을 지키기 어려웠고, PITR 은 갈라진 타임라인 16 과 17 가운데 하나만 복구할 수 있어서 복구를 포기했다. 장애 조치 직후 db002 를 마스터로 하고 새 슬레이브 db003 을 만들어 이중화했고, 일정 시간 지켜본 뒤 마이그레이션 점검을 마쳤다.

심각도
–
영향 범위
All data updated on the PostgreSQL servers between 14:30 and 15:30 JST on 7 August 2017 was lost; time series data was lost only for metrics newly created in that window and for metrics posted by the AWS and Azure integrations
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

Mackerel 을 온프레미스 데이터 센터에서 AWS 로 옮긴 뒤 애플리케이션 동작을 확인하다가, 특정 시간대의 데이터가 사라진 것을 발견했다. 2017년 8월 7일 14시 30분부터 15시 30분 사이에 PostgreSQL 서버에서 갱신된 데이터가 없었다.

15시 30분쯤 새 마스터였던 db001 과 네트워크 통신이 끊겼고, 데이터베이스가 스탠바이 서버인 db002 로 장애 조치되었다. db002 는 db001 이 마스터로 승격된 뒤부터 복제가 멈춰 있었으므로, 그동안의 갱신이 반영되지 않은 상태에서 갱신 쿼리를 받았다.

Mackerel 의 CPU % 그래프를 보면 15시 30분쯤 인스턴스 내부와 통신이 끊겼고, 그 직전까지 부하 추세에 변화가 없었다. 다른 메트릭도 마찬가지였다. Amazon CloudWatch 에서는 15시 20분쯤부터 CPUUtilization 이 오르다가 100% 에 머물렀고, 네트워크 단절 뒤 StatusCheckFailed 가 1 이었다.

팀은 통신이 끊긴 원인으로 과부하에 따른 Linux 커널 네트워크 스택이나 디스크 I/O 스택의 포화, 또는 EC2 하이퍼바이저 쪽 문제를 의심했다. 인스턴스를 재시작하고 syslog, dmesg, PostgreSQL 서버 프로세스 로그를 봤지만 관련된 로그를 찾지 못했다. AWS 지원 티켓에서도 EC2 인스턴스, EBS 볼륨, ENI, 네트워크 인프라에서 문제 기록을 찾지 못했다는 답을 받았다.

증상 데이터 유실복제 지연네트워크 도달 불가

원인

원인 운영 실수

구성 요소 데이터베이스데이터베이스 복제데이터베이스 장애 조치 관리자
기여 요인 장애 중첩기본 설정 방치스테이징 불일치자동화 증폭
촉발
새 마스터인 db001 로 접속을 바꾸고 한 시간 뒤 db001 과 네트워크 통신이 끊겼고, 복제가 멈춰 있던 스탠바이 서버 db002 로 의도하지 않은 장애 조치가 일어났다.

감지

마이그레이션 작업 뒤 애플리케이션 동작을 확인하던 중 특정 시간대의 데이터가 사라진 것을 발견했다.

조치

후속 조치

교훈

Hatena 는 이 문제가 평소 운영에서는 일어나지 않지만, PostgreSQL 버전을 올리거나 다른 리전으로 옮길 때 같은 구성을 다시 쓸 수 있다고 보았다. recovery_target_timeline = 'latest' 는 평소 스탠바이 서버에 두어도 문제가 없으므로, 사람이 빠뜨릴 여지를 없애려고 슬레이브를 만들 때 기본으로 넣도록 운영을 바꿨다. 이 설정을 쓰려는 사람은 자기 구성에서 문제가 없는지 먼저 확인하라고 덧붙였다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 데이터베이스 복제, 데이터베이스 장애 조치 관리자. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.