# Aurora MySQL 就地升级的故障排除
<a name="AuroraMySQL.Upgrading.Troubleshooting"></a>

可以使用以下提示帮助排查 Aurora MySQL 就地升级问题。这些提示不适用于 Aurora Serverless 数据库集群。


| 就地升级被取消或减慢的原因 | 效果 | 允许在维护时段内完成就地升级的解决方案 | 
| --- | --- | --- | 
| 尚未修补关联的 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 查询进行检查： <pre>SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';</pre> 还可以在 Amazon CloudWatch 中监控 `RollbackSegmentHistoryListLength` 指标。 考虑仅在 HLL 较小之后才执行升级。  | 
| 集群正在提交大型二进制日志事务 | 升级可能需要较长时间。 |  升级过程将等到应用二进制日志更改时。在此期间，可能会启动更多事务或 DDL 语句，从而进一步减慢升级过程。 将升级过程安排在集群不忙于生成二进制日志复制更改的时间段。Aurora 不会自动检测或生成此情况的事件。  | 
| 文件删除或损坏导致的模式不一致 | Aurora 取消升级。 |  将临时表的原定设置存储引擎从 MyISAM 更改为 InnoDB。执行以下步骤： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html)  | 
| 已删除主用户 | Aurora 取消升级。 |   不要删除主用户。  但是，如果由于某种原因您碰巧删除了主用户，请使用以下 SQL 命令将其还原： <pre>CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;<br /><br />GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, <br />LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, <br />TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;</pre>  | 

有关对导致升级预检查失败的问题进行故障排除的更多详细信息，请参阅以下博客：
+ [Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 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 version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 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) 而存储的撤消信息量。