不使用超级用户权限从 Amazon Aurora MySQL 迁移

如果您使用不允许使用 SUPERUSER 权限的 Amazon Aurora MySQL 源或来源创建并运行迁移作业，则迁移可能需要执行额外的步骤。

创建 Amazon Aurora MySQL 迁移作业

请务必考虑以下要求并调整迁移流程：

  1. MySQL 将来源主机名定义限制为 60 个字符。Amazon Aurora 数据库主机名通常会超过 60 个字符。如果您要迁移的数据库存在这种情况，请配置 DNS 重定向以创建 CNAME 记录，将您的域名与 Amazon Aurora 数据库实例的域名相关联。如需详细了解如何设置 DNS CNAME，请参阅 Cloud DNS 文档或 AWS Route53 文档。

  2. 二进制日志必须存储在标准块存储区中，不能存储在 Amazon S3 中。

  3. 若要创建包含手动转储的持续迁移作业，需要启用 GTID。GTID_MODE 必须为 ON、OFF 或 OFF_PERMISSIVE。不支持 ON_PERMISSIVE 的 GTID_MODE 值。

  4. 如需执行初始完整转储，请停止在源数据库中执行 MySQL Amazon Aurora 写入操作大约 20 秒钟。

  5. Database Migration Service 无法从 MySQL 数据库集群的 Amazon Aurora 只读副本实例迁移数据，因为无法从该实例检索二进制日志文件。如需了解详情，请参阅有关 配置 Aurora MySQL 二进制日志记录的 Amazon 文档。

运行迁移作业

如需执行初始完整转储，请在源数据库中停止 MySQL Amazon Aurora 写入大约 20 秒。您可以使用 查找写入活动的脚本来验证是否已停止对源数据库的所有写入。

迁移作业的状态和子状态会指明何时停止和恢复写入。您可以在 API、控制台或直接在 Cloud Monitoring 中跟踪状态变化：

  1. 状态更改为正在启动 | 等待源数据写入操作停止后，应停止对源数据库执行写入操作。Database Migration Service 会识别写入已停止，并将状态更改为正在运行 | 准备转储。

  2. 状态变为正在运行 | 正在进行完全转储后，您可以放心地恢复向源数据库写入数据。

Database Migration Service 会持续尝试获取初始转储文件大约 20 分钟。如果写入尚未停止，或者在状态更新之前恢复了写入，则该进程会失败并返回一个错误，说明失败的原因。