사례2건

2건 중 1~2번째

1. IL-0444 Aurora MySQL 에서 ALTER TABLE 을 실행할 때마다 그 테이블을 reader 로 읽던 커넥션이 끊겨 애플리케이션 오류가 쏟아졌다

   Repro2024

   증상

   ALTER TABLE 을 실행하면 그 직후 MySQL 클라이언트의 커넥션이 끊겨 오류가 대량으로 나는 일이 있었다.

   연결 리셋오류율 상승

   촉발

   Aurora MySQL 5.7 로 올린 뒤, reader 가 있는 클러스터의 테이블에 ALTER TABLE 을 실행했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   데이터베이스

   기여 요인

   스테이징 불일치

   조치

   • 애플리케이션이 커넥션 오류를 받으면 한 번만 재시도하게 했다. Rails 애플리케이션에는 트랜잭션 밖의 reader 쿼리가 "Lost connection to MySQL server" 로 실패하면 다시 연결해 한 번 더 실행하는 몽키 패치를 적용했다.

   사례 보기
2. IL-0443 Aurora MySQL reader 가 이유 없이 재시작한 뒤 writer 의 insert latency 가 7배쯤 오르고 replication lag 가 하루 넘게 이어졌다

   Repro2019

   증상

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

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

   촉발

   reader 에서 오래 도는 쿼리 때문에 롤백 세그먼트가 계속 커진 끝에 reader 가 재시작했다. 글쓴이는 그 쿼리가 Redash 에서 reader 로 보낸 것이었다고 기억한다.

   원인

   용량 한계

   구성 요소

   데이터베이스데이터베이스 복제

   기여 요인

   모니터링 사각지대

   조치

   • 팀은 writer 성능이 원래대로 돌아올 때까지 지켜보기만 했다.

   후속 조치

   • 롤백 세그먼트 길이를 Datadog 의 mysql.innodb.history_list_length 로 감시하는 모니터를 더했다.
   • reader 가 재시작할 만큼 오래 도는 쿼리를 찾으면 바로 kill 하게 했다.
   • 모니터 알림이 거의 매주 울리게 되자 사내에 알린 뒤 max_execution_time 을 설정해, 일정 시간이 지난 쿼리를 강제로 끝내게 했다.

   교훈

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

   사례 보기

원인별2