Aurora MySQL Cluster 에서 DDL 수행시, reader 쿼리의 자동종료 현상

이 페이지에서는 Aurora MySQL Cluster 에서 DDL 을 수행 시, reader 쿼리가 자동 종료되는 현상 및 이에 대한 관련 사항들을 다룬다.

 

이 내용은 아래의 tech blog 를 참조한다.

 

[1] https://www.percona.com/blog/impact-of-ddl-operations-on-aurora-mysql-readers/

 

또한 이 내용은 아래의 게시글과 연관되어 있다.

 

[2] 2022.04.22 - [AWS 및 클라우드 지식/AWS RDS, Aurora 및 관련 지식] - RDS 및 Aurora Cluster 개요

 

[3] 2021.03.05 - [MySQL/아키텍처 및 내부 구조] - Lock 종류 (InnoDB 기준)

 

 

Aurora Cluster 의 구조적 특성

 

 Aurora Cluster 는 일반적인 on-premise 구조와 달리 공유 스토리지를 중심으로 writer, reader 인스턴스들이 이를 사용하는 구조다. 그러다 보니 공유 스토리지내에서 여러 데이터 기입, 변경 작업을 수행 시, 데이터 정합성 및 여러 사유로 인하여 단순 MySQL Engine Logic 이외에 Aurora Cluster 자체의 추가 내부 Logic 이 있다.

(물론 이 Logic 은 AWS 서비스와 직결되는 기밀이기에 Support 등으로 AWS 측에 문의 해도 자세히 알 수 없다.)

 

그러다 보니 일반적으로 운영하던 MySQL 에서는 볼 수 없었던 현상이 여러개가 있는데 이 중 대표적인 사례가 이 게시글에서 공유되는 사항이다.

 

 

Writer 에서 DDL 수행시 Reader 쿼리의 자동 종료현상

 

위의 구조적인 특성으로 인해 [1] 의 percona 게시글에 따라 reader 쿼리는 자동종료되는 현상이 발생한다. 

해당 내용이 발생하는 이유는 lock 과 Aurora Cluster 의 구조적인 특성과 맞물려 있기 때문이다.

 

InooDB 를 기본 storage engine 으로 사용하는 MySQL 에서는 DDL 등으로 DB 데이터 구조를 바꾸기 위해서metadata lock 을 걸어 구조가 변경되는 동안 다른 데이터 변경이 동시에 발생하여 데이터 정합성이 깨질 수 있는 것을 막는다. 

 

그러나, 다른 세션에서 구조변경이 필요한 데이터에 대해 조회 및 변경 등이 먼저 발생하면 일반적인 MySQL 엔진에서는 이를 취소하고 metadata lock 을 걸 수 없다. 이로 인해 발생하는 Waiting for metadata lock 이슈도 이와 관련되어 있다.

 

Aurora Cluster 는 공유 스토리지를 사용하기 때문에 이러한 이슈가 발생하면 writer 및 모든 reader 인스턴스에 악영향을 미칠 수 있다. 그래서 일반적으로 Aurora MySQL Cluster 는 세션이 끊기는 이슈를 감안 하더라도 이 logic 을 사용하는 것이라 추측된다.

 

AWS 에서 나중에 더 좋은 logic 을 개발하여 두 작업을 보존 할 수 있는 방안을 마련 할 수도 있다.

다만, 현재는 이에 대해서는 특별한 우회 방안이 없기에 가능한 DDL 을 수행 할 때는 서비스 사용자가 적은 시간대에 수행 할 것을 권장한다.