将MySQL 5.5迁移到AWS

【以下的问题经过翻译处理】 一个客户在自己的本地运行了约60个MySQL数据库（大多数是5.5版本，其余是5.6），并且使用GCP作为DR /备份站点（他们不在自己的数据中心进行本地备份）。他们的数据库大小不一，最大可达3 TB。他们通过在本地使用Percona XtraBackup备份数据库文件，在云端复制备份文件并从备份文件中导入到云端数据库来同步DR站点的数据。然后，他们使用基于语句的复制（SBR）来持续更新DR站点。在需要从备份中恢复数据库或DR后需要进行故障转移时，同样的机制也用于将数据迁移到他们的数据中心。为了执行备份，他们只需在云端以不同的间隔创建卷快照（首日每小时，首周每日，首月每周，然后每6个月一次）。

他们想要将DR /备份站点迁移到AWS。他们可以使用类似的方法并在EC2上使用MySQL，但是这对他们没有太多好处，因此他们只愿意在能够使用托管服务（Aurora MySQL，RDS MySQL）的情况下进行迁移。我需要提出一个解决方案，以满足他们的要求：

• 由于文件格式和从转储文件种子数据库需要的时间，使用Percona XtraBackup而不是mysqldump
• 连续复制（以实现接近零RPO），使用基于语句的复制
• 在需要时能够快速移回到本地
• 使用托管服务

如果我理解正确，他们可以使用Aurora来使用相同的机制5.6。他们可以从XtraBackup文件导入到Aurora集群中，然后可以从本地到AWS设置SBR。但是这个解决方案不能解决另一个方向。他们无法使用 XtraBackup 备份 Aurora（或 RDS）。这意味着他们要么需要使用mysqldump，他们不想使用它，因为他们声称这需要太长时间。作为替代方案，他们可以创建 MySQL 实例作为 Aurora 的副本，然后使用它来创建备份。

问题1：还有其他选择可以实现他们需要的东西吗？

问题 2：在 EC2 上从大型数据库创建 Aurora 副本需要多长时间？

问题 3：能否使用同样的机制从 本地数据中心 上的 5.5 迁移到 Aurora 5.6？（反之亦然）

问题 4：假设第 3 季度的答案是肯定的，那么 5.6 的向后兼容性如何？使用 5.5 的应用程序是否适用于 5.6，还是需要重写？

假设从 5.5 复制到 5.6 时存在问题，他们需要在 AWS 上使用 RDS MySQL 5.5。我的理解是 5.5 不支持导入 XtraBackup 文件。