💡
原文中文，约5900字，阅读约需14分钟。
📝
内容提要
本文讨论了从Amazon Aurora MySQL兼容版v2升级到v3时导致升级时间过长和升级失败的常见原因，包括已准备的XA事务、大量的表、大量的撤消记录、正在进行的写入事务和长时间运行或未提交的空闲事务。建议在升级前解决这些问题，并监控关键的Amazon CloudWatch指标。作者是AWS Support的高级工程师，专注于Amazon RDS和Amazon Aurora。
🎯
关键要点
- 从 Amazon Aurora MySQL 兼容版 v2 升级到 v3 时，常见的升级失败原因包括已准备的 XA 事务、大量表、大量撤消记录、正在进行的写入事务和长时间运行或未提交的空闲事务。
- 如果检测到已准备状态的 XA 事务，Amazon Aurora MySQL 会取消升级，需在升级前提交或回滚这些事务。
- 集群中表的数量过多会延长预检查和引擎版本升级的时间，建议在升级前删除不使用的表。
- 大量撤消记录会导致升级时需要较长时间进行清除，建议在升级前缩短历史列表长度。
- 正在进行的写入事务可能导致回滚时间延长，需在升级前检查未提交的总行数并处理大型事务。
- 长时间运行或未提交的空闲事务可能导致表锁定，需在升级前终止这些事务。
- 建议在所有数据定义语言（DDL）语句完成后再执行升级，以避免数据字典不一致问题。
- 随着 Aurora MySQL 版本 2 于 2024 年 10 月 31 日终止生命周期，建议尽早升级到 Aurora MySQL v3。
❓
延伸问答
从 Amazon Aurora MySQL v2 升级到 v3 时，常见的失败原因有哪些？
常见的失败原因包括已准备的 XA 事务、大量表、大量撤消记录、正在进行的写入事务和长时间运行或未提交的空闲事务。
如何处理已准备的 XA 事务以避免升级失败？
在升级之前，必须提交或回滚已准备的 XA 事务，以避免升级被取消。
为什么大量表会影响 Aurora MySQL 的升级时间？
大量表会延长预检查和引擎版本升级的时间，因为需要处理和迁移大量的元数据文件。
如何减少升级时的撤消记录数量？
建议在升级前缩短历史列表长度，确保历史列表长度不超过10万条。
在升级前如何检查未提交的写入事务？
可以运行查询 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_ROWS_MODIFIED DESC; 来检查未提交的总行数。
长时间运行的空闲事务会对升级造成什么影响？
长时间运行或未提交的空闲事务可能导致表锁定，从而使升级预检查无法完成，导致升级时间延长。
➡️
