Aurora MySQL Serverless V1转V2迁移失败：过程中版本回滚

可能原因及解决步骤 #

1. 源快照兼容性不足 #

• 先确认源V1实例的Aurora MySQL版本：如果源版本低于2.11.0，直接恢复到3.x会触发自动回退。先把源V1实例升级到Aurora MySQL 2的最新兼容版本（比如2.12.5），再重新生成快照，用新快照进行恢复操作。
• 用CLI检查快照引擎版本：

  aws rds describe-db-snapshots --db-snapshot-identifier your-snapshot-id
  

  确认输出中的EngineVersion是可升级到3.x的2.x版本。

2. 恢复时参数配置遗漏 #

• 恢复快照必须手动指定3.x引擎版本：
  • GUI操作：在恢复流程的「数据库引擎选项」中，手动选中Aurora MySQL 3.x（比如3.02.0），不要使用默认继承快照版本的选项。
  • CLI操作：命令中必须包含--engine-version 3.02.0和--engine aurora-mysql参数，且--engine-mode设为provisioned（Serverless V2需要先从provisioned集群转换），示例：

    aws rds restore-db-cluster-from-snapshot --db-cluster-identifier your-new-cluster --snapshot-identifier your-snapshot-id --engine aurora-mysql --engine-version 3.02.0 --engine-mode provisioned
    

3. 实例类选择错误 #

• 避免选择旧款实例类：Aurora MySQL 3.x不支持t2、t3.small等旧实例类，必须选兼容的实例类（如db.t4g.small、db.r6g.large），否则会强制回退到2.x版本。
• 先验证集群版本再转Serverless V2：
  1. 用CLI确认集群引擎版本为3.x：

     aws rds describe-db-clusters --db-cluster-identifier your-new-cluster
     

  2. 执行转换命令：

     aws rds modify-db-cluster --db-cluster-identifier your-new-cluster --engine-mode serverless --scaling-configuration MinCapacity=1,MaxCapacity=64
     

4. 区域或权限限制 #

• 确认目标区域支持Aurora MySQL 3.x + Serverless V2：部分旧区域暂未完全支持该组合，切换到us-east-1、eu-west-1等成熟区域尝试。
• 检查IAM权限：确保操作账号拥有rds:RestoreDBClusterFromSnapshot、rds:ModifyDBCluster等完整权限，权限不足可能导致配置未生效，出现版本回退的假象。

内容的提问来源于stack exchange，提问作者blhylton