Amazon Aurora MySQL 버전 2(MySQL 5.7 호환)에서 버전 3(MySQL 8.0 호환)으로 업그레이드 체크리스트, 1부

이 글은 AWS Database Delivery Blog에 게시된 Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 1 by Huy Nguyen and Leevon Abuan 을 한국어 번역 및 편집하였습니다.

Amazon Aurora MySQL 호환 버전 2(MySQL 5.7 호환)는 2024년 10월 31일에 표준 지원이 종료될 예정입니다. Amazon Aurora MySQL 버전 2의 표준 지원 종료 일정은 공개 문서에서 확인하실 수 있습니다. 2024년 10월 31일 이전에 최대한 빠른 시일 내에 데이터베이스를 Amazon Aurora MySQL 3 이상의 기본 마이너 버전으로 업그레이드하는 것이 좋습니다. Amazon Aurora MySQL 버전 3(MySQL 8.0 호환성 포함)은 커뮤니티버전 개선사항, Amazon Aurora Serverless V2, Amazon Aurora Zero-ETL, Amazon Aurora I/O 최적화, 향상된 바이너리 로그(binlog) 및 AWS Graviton3 지원 과 같은 내역들을 제공합니다.

업그레이드 작업을 수행하려면 업그레이드가 진행되는 동안 애플리케이션에 대한 가동 중지 시간이 필요합니다. Amazon Aurora MySQL은 전체 클러스터의 엔진 버전을 업그레이드합니다. 따라서 업그레이드는 쓰기 및 읽기 DB 인스턴스에서 함께 수행됩니다. 업그레이드 기간은 테이블 및 인덱스 수를 포함한 스키마 속성, 데이터베이스 메타데이터 크기, 클러스터 사용량 등 여러 요소에 따라 달라집니다. 데이터베이스 클론으로 업그레이드를 테스트하여 업그레이드하는 데 걸리는 시간을 확인할 수 있습니다. 테스트 환경을 만들면 추가 비용이 발생합니다.

업그레이드는 in-place 업그레이드, 스냅샷 및 복원을 통해 수행되거나 업그레이드 중 애플리케이션 가동 중지 시간을 최소화하기 위해 선호되는 방법인 Amazon RDS 블루/그린 배포를 사용하여 수행할 수 있습니다. 주요 버전 간 업그레이드에는 업그레이드 전후에 대해 광범위하고 신중한 계획과 테스트가 필요합니다. 이 게시물에서는 업그레이드 및 업그레이드 사전 확인 실패의 가장 일반적인 원인에 대해 설명합니다. 업그레이드를 수행하기 전에 이러한 문제를 해결해야 합니다.

업그레이드 사전 확인

업그레이드 사전 확인은 Amazon Aurora MySQL이 여러 단계의 프로세스로 메이저 버전 업그레이드를 수행할 때의 첫 번째 단계입니다. MySQL 8.0은 여러 가지 향상된 기능을 제공하지만 MySQL 5.7과의 일부 호환되지 않는 부분에 유의하는 것이 중요합니다. 이로 인해 Amazon Aurora MySQL 버전 2에서 버전 3으로 업그레이드하는 동안 잠재적인 문제가 발생할 수 있습니다. 업그레이드를 시작하면 Amazon Aurora MySQL은 자동으로 사전 확인을 실행하여 이러한 비호환성을 감지합니다. in-place 에서는 업그레이드를 위해 DB 인스턴스가 종료되기 전에 사전 확인이 실행됩니다. 즉, 실행 시 가동 중지 시간이 발생하지 않습니다. 사전 확인에서 비호환성이 발견되면 Aurora는 DB 인스턴스가 종료되기 전에 자동으로 업그레이드를 취소합니다. 스냅샷 복원 및 Amazon RDS 블루/그린 배포 방법에서 Amazon Aurora MySQL 버전 3으로의 업그레이드 프로세스가 실패하면 쓰기 인스턴스를 생성하고 업그레이드하는 동안 문제가 감지됩니다. Aurora는 원본 5.7 호환 쓰기 인스턴스를 유지합니다. 이렇게 하면 업그레이드를 수행하기 전에 Amazon Aurora MySQL이 실행하는 사전 확인에서 로그를 검사할 수 있습니다. Aurora는 로그 파일 upgrade-prechecks.log에 각 비호환성에 대한 자세한 정보를 기록합니다. download-db-log-file-portion CLI 명령을 사용하여 이 파일을 다운로드할 수 있습니다.

프로덕션 데이터베이스를 업그레이드하기 전에 프로덕션 데이터베이스의 클론을 생성하고 클론 된 클러스터의 in-place 업그레이드를 수행하여 클러스터에 비호환성 문제가 있는지 확인하는 것이 가장 좋습니다. upgrade-prechecks.log의 detectedProblems (감지된 문제) 필드에 Error 오류 수준 값이 있는 항목이 포함되어 있으면 해당 문제를 해결할 때까지 업그레이드가 성공할 수 없음을 의미합니다. 오류를 요약하고 관련 개체 및 설명 필드를 표시하려면 upgrade-prechecks.log 파일의 내용에 대해 grep -A 2 '"level": "Error"' 명령을 실행할 수 있습니다. 그러면 각 오류 줄과 그 뒤의 두 줄이 표시됩니다. 여기에는 해당 데이터베이스 개체의 이름과 문제 해결 방법에 대한 지침이 포함되어 있습니다. 다음은 예입니다.

grep -A 2 '"level": "Error"' upgrade-prechecks.log
"level": "Error",
"dbObject": "test.testtable1",
"description": "Table test.testtable1 contains one or more capital letters in name while lower_case_table_names = 1"
"level": "Error",
"dbObject": "test.testtable2",
"description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"

upgrade-prechecks.log 파일의 끝 부분에는 각 유형의 경미하거나 심각한 문제가 발생한 검사 횟수가 요약되어 있습니다. Non-zero (0이 아닌) errorCount는 업그레이드가 실패함을 나타냅니다. warningCount는 업그레이드 프로세스에 직접적인 영향을 미치지 않지만 업그레이드 후 발생할 수 있는 문제를 방지하려면 가능할 때마다 이를 수정하는 것이 좋습니다.

{
"errorCount": 2, 
"warningCount": 58, 
"noticeCount": 0, 
"Summary": "2 errors were found. Please correct these issues before upgrading to avoid compatibility issues."
}

다음 섹션에서는 업그레이드 사전 확인 실패의 가장 일반적인 원인을 보여줍니다.

클러스터의 사용자 스키마에 일관되지 않은 데이터 딕셔너리 또는 중간 테이블이 있습니다.

데이터 딕셔너리는 테이블, 인덱스 등의 개체를 추적하는 메타데이터 모음입니다. MySQL 8 및 Amazon Aurora MySQL 버전 3은 원자성 데이터 정의 언어(DDL) 문을 지원하지만 MySQL 5.7 및 Amazon Aurora MySQL 버전 2는 지원하지 않습니다. 따라서 MySQL 5.7 및 Amazon Aurora MySQL 버전 2에서 DDL이 갑자기 중단되면 테이블이 일관되지 않은 데이터 딕셔너리로 이어질 수 있습니다. 이 문제는 MySQL 디자인으로 인해 발생하며 Amazon Aurora MySQL 또는 MySQL용 Amazon Relational Database(Amazon RDS)로 인해 발생하는 것이 아닙니다. 일관되지 않은 데이터 딕셔너리 문제가 있는 테이블의 경우 upgrade-prechecks.log에 다음 오류가 표시됩니다.

{
"id": "schemaInconsistencyCheck",
"title": "Schema inconsistencies resulting from file removal or corruption",
"status": "OK",
"description": "Error: Following tables show signs that either table datadir directory or frm file was removed/corrupted. Please check server logs, examine datadir to detect the issue and fix it before upgrade",
"detectedProblems": [
{"level": "Error",
"dbObject": "test.inconsistent_dd_table",
"description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"
}

업그레이드 중에 이 문제가 나타날 때 다음 옵션 중 하나가 적합하다면 먼저 시도해 보는 것이 좋습니다.

논리적 덤프를 수행한 후 새 클러스터로 복원한 다음 새 클러스터를 Aurora MySQL v3으로 업그레이드합니다. 이 전략에서는 문제가 있는 테이블이 새 클러스터로 이동되지 않으므로 문제가 발생한 테이블은 더 이상 필요하지 않다고 가정합니다. 다중 병렬 스레드에는 mysqldump 또는 mydumper 및 myloader를 사용할 수 있습니다.
binlog 복제본 클러스터가 있는 경우 동일한 문제가 없는지 다시 확인한 후 복제 지연이 없으면 독립형 클러스터로 승격할 수 있습니다.
문제를 일으키는 DDL/DCL이 실행된 시간을 알고 있는 경우 원래 DCL 또는 DDL이 시작되기 전의 시간으로 특정 시점 복구(PiTR)를 수행합니다. 데이터 손실을 최소화하려면 델타를 복원된 클러스터로 마이그레이션하세요.

이러한 옵션 중 어느 것도 효과가 없으면 AWS Support에 문의하십시오. 데이터 딕셔너리 불일치 수정은 최선의 노력으로 수행됩니다. 딕셔너리가 복구할 수 없는 상태인 경우도 있습니다.

클러스터에 분리된 FULLTEXT 인덱스가 포함된 테이블이 있습니다.

FULLTEXT 인덱스를 생성한 다음 인덱스를 삭제하면 업그레이드 사전 확인이 실패하고 업그레이드가 롤백되는 일부 메타데이터가 남을 수 있습니다. 고아(orphaned) 인덱스를 매달린(dangling) FULLTEXT 인덱스라고 합니다. 매달린 FULLTEXT 인덱스를 포함하는 문제가 있는 테이블에 대한 정보는 upgrade-prechecks.log 파일에 인쇄됩니다.

{
"id": "getDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.",
"detectedProblems": [
{"level": "Error",
"dbObject": "sandbox.dangling_fulltext_index_table",
"description": "Table sandbox.dangling_fulltext_index_table contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
}

매달린 FULLTEXT 문제를 해결하려면 Aurora MySQL v2 클러스터의 테이블에서 OPTIMIZE TABLE 명령을 실행하세요. 예를 들어 다음과 같은 명령어를 실행하실 수 있습니다. OPTIMIZE TABLE sandbox.dangling_fulltext_index_table;

클러스터에 예약된 키워드가 있는 개체가 있습니다.

MySQL 8.0에는 이전에 예약되지 않았던 예약어가 도입되었습니다. 업그레이드 사전 검사기는 데이터베이스 개체 이름과 해당 정의 및 본문에서 예약된 키워드의 사용을 평가합니다. 저장 프로시저, 함수, 이벤트 및 트리거와 같은 데이터베이스 개체에서 사용되는 예약된 키워드를 감지하면 업그레이드가 실패하고 upgrade-prechecks.log 파일에 오류가 인쇄됩니다.

{
"id": "routinesSyntaxCheck",
"title": "MySQL 8.0 syntax check for routine-like objects",
"status": "OK",
"description": "The following objects did not pass a syntax check with the latest MySQL 8.0 grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
"documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
"detectedProblems": [
{"level": "Error",
"dbObject": "test.EXCEPT",
"description": "at line 12,8: unexpected token '.'"
}

문제를 해결하려면 업그레이드하기 전에 이러한 개체 정의를 업데이트하고 해당 참조를 ‘인용’해야 합니다. 또는 이름을 다른 이름으로 변경할 수 있으며, 이 경우 애플리케이션 변경이 필요할 수 있습니다.

클러스터에 열 정의에 잘못된 문자가 포함된 테이블이 있습니다.

Amazon Aurora MySQL DB 클러스터를 업그레이드하려고 하면 테이블의 열 설명 정의에 잘못된 문자가 있기 때문에 업그레이드가 실패할 수 있습니다. 오류 로그에 다음 오류가 표시될 수 있습니다.

2023-09-19T03:11:27.361837Z 2 [ERROR] [MY-013140] [Server] Comment for table 'test.problematic_tables' contains an invalid utf8mb3 character string: '\x8E\xE8\x94'.

엔진 오류 로그를 검사하여 문제가 있는 모든 테이블을 식별한 다음 해당 테이블에 대해 SHOW CREATE TABLE <table_name> 명령을 실행하고 SHOW WARNINGS를 사용하여 경고를 확인하여 세부 정보를 확인하는 것이 좋습니다. 업그레이드를 재시도하기 전에 열의 설명 정의를 업데이트해야 합니다.

업그레이드 실패를 일으키는 기타 일반적인 문제에 대한 자세한 내용은 MySQL 8.0의 변경 사항을 참조하세요.

결론

이 글에서는 업그레이드 사전 확인 프로세스와 업그레이드 및 업그레이드 사전 확인이 실패하게 만드는 일반적인 문제와 이러한 문제를 해결하는 방법에 대해 논의했습니다. 2부에서는 Amazon Aurora MySQL 2에서 Amazon Aurora MySQL 3으로의 업그레이드가 지연되거나 실패하는 일반적인 원인에 대해 설명합니다.

AWS 기술 블로그