Incident Library

IL-0443 Repro · 2019-11-11databaseaws

Aurora MySQL reader 가 이유 없이 재시작한 뒤 writer 의 insert latency 가 7배쯤 오르고 replication lag 가 하루 넘게 이어졌다

Repro 는 Aurora MySQL 을 쓴다. 2019년 11월 reader 가 이유를 알 수 없이 재시작하고, 그 뒤 writer 의 insert latency 가 7배쯤 오르고 replication lag 가 커진 상태가 하루 넘게 이어지는 일이 두 번 있었다. 그동안 SDK 가 모은 데이터를 처리하는 애플리케이션이 지연됐고, 팀은 writer 성능이 돌아오기를 지켜보기만 했다.

AWS 지원팀이 내부 정보로 조사해 보니 reader 가 재시작하기 전까지 롤백 세그먼트 영역이 계속 늘었고, reader 가 재시작한 뒤에 해제가 시작됐다. 롤백 세그먼트는 레코드가 바뀔 때 롤백이나 다른 트랜잭션의 옛 데이터 읽기에 대비해 옛 정보를 남겨 두는 영역이다. 이 영역은 reader 의 트랜잭션이 길어져도 계속 늘 수 있다. 롤백 세그먼트는 11월 5일 10:16 JST 쯤부터 커졌고, reader 가 재시작한 11월 11일 19:20 JST 쯤 해제가 시작되어 11월 13일 14:31 JST 쯤 끝났다. AWS 지원팀은 커진 롤백 세그먼트를 해제하는 데 드는 I/O 가 커밋 레이턴시를 올린 것으로 봤고, 11월 5일 재시작 때도 같은 흐름이었다고 했다. 롤백 세그먼트는 DB 인스턴스가 아니라 클러스터 전체가 함께 쓴다. 그래서 인스턴스를 지우거나 더해도 해제를 앞당길 수 없었고, 미리 막는 것 말고는 할 수 있는 일이 없었다.

팀은 Datadog 의 mysql.innodb.history_list_length 로 롤백 세그먼트를 감시하는 모니터를 더했고, reader 가 재시작할 만큼 오래 도는 쿼리를 찾는 대로 kill 하게 했다. 그 뒤로는 같은 일을 미리 막을 수 있었다. 모니터를 둔 지 2년쯤 지나 알림이 거의 매주 울리자, 팀은 사내에 알린 뒤 max_execution_time 을 설정했다.

심각도
–
영향 범위
Writer performance of the Aurora MySQL cluster for a day or more after each reader restart; the applications processing data collected by the Repro SDK were delayed
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

Aurora MySQL 의 reader 가 이유를 알 수 없이 재시작했다. 그 직후부터 writer 의 insert latency 가 7배쯤 오르는 등 writer 성능이 크게 떨어진 상태가 오래 이어졌다. 같은 일이 2019년 11월 두 주 사이에 두 번 일어났다.

writer 성능이 떨어진 동안 SDK 가 모은 데이터를 처리하는 애플리케이션이 지연됐다.

지표에는 매번 같은 모습이 나타났다. reader 가 재시작했고, 재시작 전에 freeable memory 가 빠르게 줄었다. mutex spin waits 는 크게 줄고 Rw-excl spin rounds 와 RW-excl spin waits 는 2배쯤 늘었다. commit latency 를 비롯한 latency 와 replication lag 가 오르고 volume read iops 가 늘었다. writer 지표는 reader 재시작 시점에 갑자기 바뀐 뒤 그 상태로 하루 넘게 이어졌고, 하루이틀 지나면 원래대로 돌아왔다.

팀은 가설을 하나 세웠다. reader 가 재시작해 buffer pool 이 비면서 DB 인스턴스와 클러스터 스토리지 사이의 네트워크 통신과 클러스터 스토리지의 IOPS 가 늘었고, 그것이 writer 에도 영향을 줬다는 가설이었다. 팀은 이 가설을 가지고 AWS 지원팀에 문의했다.

증상 지연 시간 증가복제 지연처리량 저하

원인

원인 용량 한계

구성 요소 데이터베이스데이터베이스 복제
기여 요인 모니터링 사각지대
촉발
reader 에서 오래 도는 쿼리 때문에 롤백 세그먼트가 계속 커진 끝에 reader 가 재시작했다. 글쓴이는 그 쿼리가 Redash 에서 reader 로 보낸 것이었다고 기억한다.

감지

–

조치

후속 조치

교훈

롤백 세그먼트가 커지지 않도록 트랜잭션을 작게 해야 한다. 롤백 세그먼트는 클러스터 전체가 함께 쓰므로, 한번 커지면 인스턴스를 바꿔도 해제가 끝나기를 기다리는 수밖에 없다. 롤백 세그먼트 길이는 show engine innodb status 의 "History list length" 값으로 볼 수 있다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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