Amazon Aurora MySQL 版本 2（兼容 MySQL 5.7）升级到版本 3（兼容 MySQL 8.0）检查清单，第 2 部分
内容提要
本文讨论了从Amazon Aurora MySQL兼容版v2升级到v3时导致升级时间过长和升级失败的常见原因，包括已准备的XA事务、大量的表、大量的撤消记录、正在进行的写入事务和长时间运行或未提交的空闲事务。建议在升级前解决这些问题，并监控关键的Amazon CloudWatch指标。作者是AWS Support的高级工程师，专注于Amazon RDS和Amazon Aurora。
延伸解读
XA 事务：升级的硬性阻断点
文章指出，Aurora MySQL 在升级时若检测到已准备的 XA 事务，会直接取消升级，且失效转移或重启数据库均无法移除。这意味着升级前必须主动搜索并提交或回滚这些事务。读者需注意，XA 事务可能由应用异常中断产生，仅靠常规监控不易发现，建议在升级窗口前专门执行 XA RECOVER 检查，避免因遗漏导致升级失败。
表数量与撤消记录：影响升级时长的关键因素
大量表会延长预检查和引擎升级时间，因为 MySQL 8.0 数据字典改为集中存储，需迁移大量元数据；大量撤消记录则导致干净关闭时清除时间增加。文章建议删除无用表、缩短历史列表长度（通常不超过 10 万条），并监控 CloudWatch 指标如 CPUUtilization、FreeableMemory 等。这些措施能减少资源争用，但需权衡对生产负载的影响。
长事务与 DDL：升级前的必要清理
长时间运行或未提交的空闲事务可能锁定表，使预检查卡在 Waiting for table flush 或 Waiting for table metadata lock 状态。文章建议用 information_schema.innodb_trx 和 processlist 找出阻塞事务并终止。同时，所有 DDL 语句必须完成后再升级，否则 Aurora 会取消升级，且中断 DDL 可能导致数据字典不一致。读者应在升级前安排专门时间处理这些事务。
Q&A
从 Amazon Aurora MySQL v2 升级到 v3 时，常见的失败原因有哪些？
常见的失败原因包括已准备的 XA 事务、大量表、大量撤消记录、正在进行的写入事务和长时间运行或未提交的空闲事务。
如何处理已准备的 XA 事务以避免升级失败？
在升级之前，必须提交或回滚已准备的 XA 事务，以避免升级被取消。
为什么大量表会影响 Aurora MySQL 的升级时间？
大量表会延长预检查和引擎版本升级的时间，因为需要处理和迁移大量的元数据文件。
如何减少升级时的撤消记录数量？
建议在升级前缩短历史列表长度，确保历史列表长度不超过10万条。
在升级前如何检查未提交的写入事务？
可以运行查询 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_ROWS_MODIFIED DESC; 来检查未提交的总行数。
长时间运行的空闲事务会对升级造成什么影响？
长时间运行或未提交的空闲事务可能导致表锁定，从而使升级预检查无法完成，导致升级时间延长。
