# Aurora MySQL 현재 위치 업그레이드를 위한 문제 해결
다음 팁을 사용하면 Aurora MySQL 인플레이스 업그레이드와 관련된 문제를 해결하는 데 도움이 됩니다. 이러한 팁은 Aurora Serverless DB 클러스터에는 적용되지 않습니다.
| 현재 위치 업그레이드가 취소되거나 느린 이유 | Effect | 유지 관리 기간 내에 현재 위치 업그레이드를 완료할 수 있는 솔루션 |
| --- | --- | --- |
| 관련 Aurora 크로스 리전 복제본이 아직 패치되지 않음 | Aurora는 업그레이드를 취소합니다. | Aurora 크로스 리전 복제본을 업그레이드하고 다시 시도합니다. |
| 클러스터에 준비된 상태의 XA 트랜잭션이 있습니다. | Aurora는 업그레이드를 취소합니다. | 준비된 모든 XA 트랜잭션을 커밋하거나 롤백합니다. |
| 클러스터가 데이터 정의 언어(DDL)문을 처리하고 있습니다. | Aurora는 업그레이드를 취소합니다. | 모든 DDL문이 완료된 후 대기하고 업그레이드를 수행하기를 고려하십시오. |
| 클러스터에 많은 행에 대해 커밋되지 않은 변경 사항이 있습니다. | 업그레이드에 시간이 오래 걸릴 수 있습니다. | 업그레이드 프로세스는 커밋되지 않은 변경 사항을 롤백합니다. 이 조건에 대한 표시기는 `TRX_ROWS_MODIFIED` 테이블 내 `INFORMATION_SCHEMA.INNODB_TRX`의 값입니다. 모든 대규모 트랜잭션이 커밋되거나 롤백된 후에만 업그레이드를 수행하는 것이 좋습니다. |
| 클러스터에 실행 취소 레코드 수가 많음 | 업그레이드에 시간이 오래 걸릴 수 있습니다. | 커밋되지 않은 트랜잭션이 대량의 행에 영향을 미치지 않더라도 대량의 데이터가 포함될 수 있습니다. 예를 들어 대형 BLOB를 삽입할 수 있습니다. Aurora는 이러한 종류의 트랜잭션 활동에 대한 이벤트를 자동으로 감지하거나 생성하지 않습니다. 이 조건에 대한 지표는 HLL(기록 목록 길이)입니다. 업그레이드 프로세스는 커밋되지 않은 변경 사항을 롤백합니다. `SHOW ENGINE INNODB STATUS` SQL 명령의 출력에서 HLL을 확인하거나 다음 SQL 쿼리를 사용하여 직접 확인할 수 있습니다. SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
또한 Amazon CloudWatch를 사용하여 `RollbackSegmentHistoryListLength` 지표를 모니터링할 수도 있습니다. HLL의 길이가 더 줄어든 후에 한하여 업그레이드 수행을 고려하세요. |
| 클러스터가 큰 이진 로그 트랜잭션을 커밋하는 중입니다. | 업그레이드에 시간이 오래 걸릴 수 있습니다. | 업그레이드 프로세스는 이진 로그 변경 내용이 적용될 때까지 기다립니다. 이 기간 동안 더 많은 트랜잭션 또는 DDL문이 시작될 수 있으므로 업그레이드 프로세스가 느려질 수 있습니다. 클러스터가 이진 로그 복제 변경 내용을 생성하느라 바쁜 경우가 아니면 업그레이드 프로세스를 예약합니다. Aurora는 이 조건에 대한 이벤트를 자동으로 감지하거나 생성하지 않습니다. |
| 파일 제거 또는 손상으로 인한 스키마 불일치 | Aurora는 업그레이드를 취소합니다. | 임시 테이블의 기본 스토리지 엔진을 MyISAM에서 InnoDB로 변경합니다. 다음 단계를 수행합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html) |
| 마스터 사용자 삭제됨 | Aurora는 업그레이드를 취소합니다. | 마스터 사용자는 삭제하지 마세요. 하지만 어떤 이유로든 마스터 사용자를 삭제해야 하는 경우 다음 SQL 명령을 사용하여 복원하세요. CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES,
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT,
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;
|
업그레이드 사전 검사 실패를 유발하는 문제 해결에 대한 자세한 내용은 다음 블로그를 참조하세요.
+ [Amazon Aurora MySQL 버전 2(MySQL 5.7 호환성 지원)에서 버전 3(MySQL 8.0 호환성 지원)으로 업그레이드할 때 필요한 체크리스트, 1부](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-1/)
+ [Amazon Aurora MySQL 버전 2(MySQL 5.7 호환성 지원)에서 버전 3(MySQL 8.0 호환성 지원)으로 업그레이드할 때 필요한 체크리스트, 2부](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-2/)
다음 단계를 사용하여 위 테이블의 일부 조건에 대해 직접 검사를 수행할 수 있습니다. 이렇게 하면 데이터베이스가 업그레이드가 성공적으로 신속하게 완료될 수 있는 상태임을 알고 있을 때 업그레이드를 예약할 수 있습니다.
+ `XA RECOVER`문을 실행하여 열린 XA 트랜잭션을 확인할 수 있습니다. 그런 다음 업그레이드를 시작하기 전에 XA 트랜잭션을 커밋하거나 롤백할 수 있습니다.
+ `SHOW PROCESSLIST`문을 실행하고 출력에서 `CREATE`, `DROP`, `ALTER`, `RENAME` 및 `TRUNCATE` 문을 찾아 DDL 문을 확인할 수 있습니다. 업그레이드를 시작하기 전에 모든 DDL 문이 완료될 수 있습니다.
+ `INFORMATION_SCHEMA.INNODB_TRX` 테이블을 쿼리하여 수행되지 않은 행의 총 수를 확인할 수 있습니다. 테이블은 각 트랜잭션에 대한 하나의 행을 포함합니다. `TRX_ROWS_MODIFIED` 열은 트랜잭션에 의해 수정되거나 삽입된 행 수를 포함합니다.
+ `SHOW ENGINE INNODB STATUS SQL`문을 실행하고 출력에서 `History list length`를 찾아 InnoDB 히스토리 목록의 길이를 확인할 수 있습니다. 다음 쿼리를 실행하여 값을 직접 확인할 수도 있습니다.
```
SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
```
기록 목록의 길이는 다중 버전 동시성 제어 (MVCC)를 구현하기 위해 데이터베이스에 저장된 실행 취소 정보의 양에 해당합니다.