DB & AWS Knowledge
RDS MySQL/MariaDB, Aurora MySQL Cluster 의 signal crash 본문
RDS MySQL/MariaDB, Aurora MySQL Cluster 의 signal crash
`O` 2024. 1. 11. 03:11이 페이지에서는 RDS MySQL/MariaDB, Aurora MySQL Cluster 에서 발생하는 signal crash 에 대하여 다룬다.
이 페이지는 아래의 이전 게시글과 연관이 있다. 이 글을 읽기 전, 아래의 게시글을 먼저 읽는 것을 권장한다.
2024.01.11 - [MySQL/기타 지식] - MySQL, MariaDB 의 signal crash
MySQL, MariaDB signal crash 와의 연관성
RDS MySQL, Aurora MySQL 또한 오픈소스 DB 인 MySQL, MariaDB 를 응용하여 만든 서비스이기 때문에 기본적인 처리 logic 및 리소스 접근 logic 은 MySQL, MariaDB 를 따른다. 그러나 100% 동일한 logic 은 아니기에 MySQL, MariaDB 에서 발생하는 signal crash 에 덧붙여 RDS MySQL, Aurora MySQL 추가적인 signal crash 가 발생 할 수 있다.
RDS MySQL, Aurora MySQL Cluster signal crash 에 대한 조치
이렇게 AWS 측에서 만든 stack bug 로 인하여 발생하는 crash 들은 AWS 측에서 지속적으로 상위 버전을 내 놓으면서 개선을 하게 된다. 다만, 이전 게시글에서도 기재했지만, 사용자 입장에서 이러한 crash 분석은 쉬운 작업이 아닌데 이러한 crash 가 MySQL, MariaDB engine 자체의 bug 로 인하여 발생 한 건지 RDS, Aurora Cluster 특정 버전의 bug 로 인한 crash 인지 판별이 어렵다.
그래서 이에 대해서 지원을 받는 좋은 방법은 AWS Support 를 이용하거나 자신이 소속된 회사에서 enterprise support plan 을 사용한다면, 이를 지원 해 주는 AWS TAM 등을 통하여 원인 분석 지원을 받는 것이다. 일반적으로 TAM support 는 TAM 님들께서 직접 Support 측에 지원을 요청하거나 서비스 개발팀에 공식 지원 요청을 함으로써 이루어진다.
일반적으로 두 방법을 통하여 MySQL, MariaDB engine 및 RDS MySQL/MariaDB, Aurora MySQL Cluster bug 를 둘다 분석 받을 수 있으며 이에 따른 조치 권장안을 받을 수 있다. 다만, 이에 대해서는 각 사용자 별로 개별 bug fix 를 받을 수는 없고 bug 가 개선된 상위 버전을 사용하도록 안내하는 것이 AWS 측 권장안이다. 혹은 쿼리자체를 수정하여 개선을 할 수 있다는 조치안을 안내받을 수 있는데 이 때는 그냥 업그레이드를 하는 것이 효율적일지, 쿼리를 수정하는 것이 더 효율적일지를 판별하여 선택하면 된다.
'AWS 및 클라우드 지식 > AWS RDS, Aurora 및 관련 지식' 카테고리의 다른 글
RDS, Aurora Cluster 의 Master user 의 의의 및 특징 (MySQL 기준) (0) | 2024.01.15 |
---|---|
Aurora MySQL Cluster 에서 수정 할 수 없는 파라미터들 (0) | 2024.01.13 |
Aurora MySQL Cluster 의 innodb_flush_log_at_trx_commit 파라미터 (0) | 2024.01.10 |
Aurora Cluster 의 읽기 가용성 재부팅 (read availability) (0) | 2024.01.10 |
RDS, Aurora Cluster 의 Reserved Instance (RI) 개념 (0) | 2024.01.08 |