{"id":"IL-0431","org":"Hatena","date":"2017-08-07","docs":[],"title":{"en":"During Mackerel's move to AWS, PostgreSQL failed over to a replica that had stopped replicating, losing an hour of data","ko":"AWS 로 옮기는 점검 중 PostgreSQL 이 의도하지 않게 장애 조치되어 한 시간 동안 갱신된 데이터가 사라졌다"},"domain":["database","aws"],"impact":{"scope":"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","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"A setting needed only for a rare layout, such as a grandchild replica during a migration, was applied by hand through a script option and was forgotten. Because recovery_target_timeline = 'latest' is harmless on ordinary standbys too, Hatena now sets it by default whenever a replica is created. The staging rehearsal used the same layout and steps but had the setting right, so it could not catch the mistake. Hatena notes that a similar layout may be used again for a future PostgreSQL upgrade or a move to another region.","ko":"Hatena 는 이 문제가 평소 운영에서는 일어나지 않지만, PostgreSQL 버전을 올리거나 다른 리전으로 옮길 때 같은 구성을 다시 쓸 수 있다고 보았다. recovery_target_timeline = 'latest' 는 평소 스탠바이 서버에 두어도 문제가 없으므로, 사람이 빠뜨릴 여지를 없애려고 슬레이브를 만들 때 기본으로 넣도록 운영을 바꿨다. 이 설정을 쓰려는 사람은 자기 구성에서 문제가 없는지 먼저 확인하라고 덧붙였다."},"related":[],"sources":[{"url":"https://mackerel.io/ja/blog/entry/2017/08/15/113803","kind":"blog","archived":"https://web.archive.org/web/20260514105708/https://mackerel.io/ja/blog/entry/2017/08/15/113803"}],"summary":{"en":"Hatena moved Mackerel from an on-premises data center to AWS in a maintenance window that began at 14:30 JST on 7 August 2017. The PostgreSQL 9.3 servers used standard streaming replication in a chain: db001 replicated from db000, and db002 replicated from db001, making it a grandchild of db000. The database servers ran on c4.8xlarge EC2 instances with gp2 EBS volumes (EBS-optimised), Linux 3.16 and Debian 8. The migration cut connections to db000, promoted db001 to primary and pointed the application at db001. When db001 was promoted, replication from db001 to db002 stopped.\n\nPostgreSQL increments the timeline ID on promotion, and with the 9.3 defaults a replica refuses WAL carrying the new timeline ID and stops replicating, unless recovery.conf sets recovery_target_timeline = 'latest'. In normal Mackerel operation that setting was not needed, so it was set only when needed through an option of the in-house replica creation script, and that option was forgotten for db002. A migration test in staging, with the same cluster layout and the same steps as production, had the setting right on the grandchild replica, so replication did not stop there and the problem was not found.\n\nAt 15:30 db001 lost network connectivity for reasons never established; Hatena considered saturation of the Linux network stack or disk I/O stack from overload, or a problem on the EC2 hypervisor side. The failover went to db002, which then took updates on top of data that lacked everything since db001's promotion. Manual repair from the tables left on db001 was abandoned because much data had already changed and keeping the tables consistent was judged too hard. Point-in-time recovery from the pre-maintenance base backup, the WAL on db001 and the archived WAL was also abandoned, because recovery can follow only one of timeline 16 (db001) or timeline 17 (db002), not both. Hatena also judged that even a consistent database would not look consistent to customers who had already re-created the lost data. Right after the failover a new replica db003 was built from db002, db001 was kept for investigation, and the maintenance was completed after watching db002 for some time.","ko":"2017년 8월 7일 Hatena 는 Mackerel 을 온프레미스 데이터 센터에서 AWS 로 옮기는 점검을 했다. 데이터베이스는 PostgreSQL 9.3 의 스트리밍 복제로 db000 아래에 db001 을, db001 아래에 db002 를 두는 구성이었다. 작업은 db000 접속을 막고 db001 을 마스터로 승격한 뒤 접속 대상을 db001 로 바꾸는 순서였다. db001 이 승격되면서 db001 에서 db002 로 가는 복제가 멈췄다.\n\nPostgreSQL 은 마스터로 승격할 때 타임라인 ID 를 하나 올린다. PostgreSQL 9.3 의 기본 설정에서는 슬레이브가 새 타임라인 ID 를 가진 WAL 을 받아들이지 않아 복제가 멈춘다. recovery.conf 에 recovery_target_timeline = 'latest' 를 두면 슬레이브가 새 타임라인을 따라간다. Mackerel 팀은 평소 운영에는 이 설정이 필요 없어서 자체 레플리카 생성 스크립트의 옵션으로 필요할 때만 넣었고, 이번에는 그 옵션을 빠뜨렸다. staging 환경에서 같은 구성과 같은 절차로 마이그레이션 시험을 했지만, 그때는 이 설정을 올바르게 넣었기 때문에 문제가 드러나지 않았다.\n\n15시 30분쯤 c4.8xlarge 인스턴스에서 돌던 db001 과 네트워크 통신이 끊겼고, 데이터베이스가 복제가 멈춘 db002 로 장애 조치되었다. 통신이 끊긴 원인은 끝내 밝히지 못했다. 그 결과 14시 30분부터 15시 30분까지 갱신된 데이터가 db002 에 없는 채로 서비스가 이어졌다. 팀은 db001 에 남은 테이블 데이터로 손으로 복구하는 방법과 PITR 로 복구하는 방법을 검토했다. 손으로 복구하면 테이블 사이 정합성을 지키기 어려웠고, PITR 은 갈라진 타임라인 16 과 17 가운데 하나만 복구할 수 있어서 복구를 포기했다. 장애 조치 직후 db002 를 마스터로 하고 새 슬레이브 db003 을 만들어 이중화했고, 일정 시간 지켜본 뒤 마이그레이션 점검을 마쳤다."},"trigger":{"en":"One hour after the application was switched to the newly promoted primary db001, db001 lost network connectivity and the database failed over to the standby db002.","ko":"새 마스터인 db001 로 접속을 바꾸고 한 시간 뒤 db001 과 네트워크 통신이 끊겼고, 복제가 멈춰 있던 스탠바이 서버 db002 로 의도하지 않은 장애 조치가 일어났다."},"severity":"unknown","symptoms":["data-loss","replication-lag","network-unreachable"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"The team found the missing data while checking how the application behaved after the migration work.","ko":"마이그레이션 작업 뒤 애플리케이션 동작을 확인하던 중 특정 시간대의 데이터가 사라진 것을 발견했다."},"components":["database","database-replication","failover-manager"],"root_cause":"human-operation","remediation":[{"text":{"en":"Tried to restore the lost updates by hand from the table data left on db001 and gave up","ko":"db001 에 남은 테이블 데이터로 손으로 복구할 수 있는지 검토했지만, 이미 많은 데이터가 갱신되어 테이블 사이 정합성을 지키며 db002 에 반영하기 어렵다고 보고 포기했다."}},{"text":{"en":"Tried point-in-time recovery from the base backup and WAL and gave up","ko":"점검 전 베이스 백업, db001 에 남은 WAL, 백업 서버로 보내 둔 WAL 아카이브로 PostgreSQL 의 PITR 복구를 시도했지만, 갈라진 두 타임라인을 이어서 복구할 수 없어 포기했다."}},{"text":{"en":"Built a new replica db003 with db002 as primary to restore redundancy","ko":"장애 조치 직후 db002 를 마스터로 하고 새 슬레이브 서버 db003 을 만들어 db002 와 db003 으로 이중화했다."}},{"text":{"en":"Kept db001 in maintenance state for investigation","ko":"장애가 난 db001 은 조사용으로 점검 상태에 남겨 두었다."}},{"text":{"en":"Watched db002 for some time to confirm the problem did not recur, then completed the migration","ko":"db002 에서 db001 과 같은 문제가 나지 않는지 일정 시간 지켜본 뒤 마이그레이션 점검을 마쳤다."}}],"action_items":[{"text":{"en":"Change the PostgreSQL replica creation script to set recovery_target_timeline = 'latest' in recovery.conf by default","ko":"PostgreSQL 레플리카 생성 스크립트가 recovery.conf 에 recovery_target_timeline = 'latest' 를 기본으로 넣도록 바꾼다."}},{"text":{"en":"Add a check to a server configuration test tool such as Serverspec that recovery.conf contains recovery_target_timeline = 'latest'","ko":"Serverspec 같은 서버 구성 관리 테스트 도구에 recovery.conf 안에 recovery_target_timeline = 'latest' 문자열이 있는지 확인하는 항목을 더한다."}}],"contributing":["overlapping-failures","default-config-unchanged","staging-not-representative","automation-amplified"],"recurrence_of":null,"symptoms_text":{"en":"On 7 August 2017, while checking the application after the maintenance that moved Mackerel from an on-premises data center to AWS, the team found that data updated during a specific time window was missing. Everything written to the PostgreSQL database between 14:30 and 15:30 JST was gone.\n\nAt 15:30, one hour after connections had been switched to the new primary db001, db001 lost network connectivity and the database failed over, without anyone intending it, to the standby db002. db002 had silently stopped replicating when db001 was promoted, so it held the data as of the start of the maintenance, and update queries then ran on db002.\n\nThe cause of the network loss was not found. Mackerel's own CPU graph showed that contact with the inside of the instance was lost around 15:30 with no change in load just before, and the same held for the other metrics. CloudWatch showed CPUUtilization rising from about 15:20 and staying at 100%, and StatusCheckFailed at 1 after the network loss. After a restart, syslog, dmesg and the PostgreSQL server process logs showed nothing related, and an AWS support ticket covering the EC2 instance, its EBS volume and ENI and the network infrastructure found no record of a problem.","ko":"Mackerel 을 온프레미스 데이터 센터에서 AWS 로 옮긴 뒤 애플리케이션 동작을 확인하다가, 특정 시간대의 데이터가 사라진 것을 발견했다. 2017년 8월 7일 14시 30분부터 15시 30분 사이에 PostgreSQL 서버에서 갱신된 데이터가 없었다.\n\n15시 30분쯤 새 마스터였던 db001 과 네트워크 통신이 끊겼고, 데이터베이스가 스탠바이 서버인 db002 로 장애 조치되었다. db002 는 db001 이 마스터로 승격된 뒤부터 복제가 멈춰 있었으므로, 그동안의 갱신이 반영되지 않은 상태에서 갱신 쿼리를 받았다.\n\nMackerel 의 CPU % 그래프를 보면 15시 30분쯤 인스턴스 내부와 통신이 끊겼고, 그 직전까지 부하 추세에 변화가 없었다. 다른 메트릭도 마찬가지였다. Amazon CloudWatch 에서는 15시 20분쯤부터 CPUUtilization 이 오르다가 100% 에 머물렀고, 네트워크 단절 뒤 StatusCheckFailed 가 1 이었다.\n\n팀은 통신이 끊긴 원인으로 과부하에 따른 Linux 커널 네트워크 스택이나 디스크 I/O 스택의 포화, 또는 EC2 하이퍼바이저 쪽 문제를 의심했다. 인스턴스를 재시작하고 syslog, dmesg, PostgreSQL 서버 프로세스 로그를 봤지만 관련된 로그를 찾지 못했다. AWS 지원 티켓에서도 EC2 인스턴스, EBS 볼륨, ENI, 네트워크 인프라에서 문제 기록을 찾지 못했다는 답을 받았다."},"updated_at":"2026-11-14T12:34:08.109723Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0431","org_slug":"hatena"}