选择复制实例的最佳大小 - Amazon Database Migration Service
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

选择复制实例的最佳大小

如何选择合适的复制实例取决于与您的使用案例相关的多种因素。为帮助您了解如何使用复制实例资源,请参阅以下讨论。其中涵盖了完全加载 + CDC 任务的常见场景。

在完整的加载任务中,Amazon DMS 逐个加载表。默认情况下,一次加载八个表。Amazon DMS 在完整加载任务期间捕获对源的持续更改,因此以后可在目标终端节点上应用更改。更改缓存在内存中;如果可用内存用完,则将更改缓存到磁盘上。表的完全加载任务完成后,Amazon DMS 立即将缓存的更改应用到目标表。

在应用表的所有未完成的缓存更改后,目标终端节点将处于事务一致状态。此时,目标与源终端节点就最后的缓存更改而言同步。然后,Amazon DMS 开始在源和目标之间进行持续复制。为此,Amazon DMS从源事务日志获取更改操作,并按照事务一致的方式将其应用到目标。(此过程假定未选择批量优化应用)。Amazon DMS如果可能,则会通过复制实例上的内存流式传输持续更改。否则,Amazon DMS 会将更改写入到复制实例上的磁盘,直至可在目标上应用。

您对复制实例如何应对更改处理以及在该流程中如何使用内存有一定的控制能力。有关如何优化更改处理的更多信息,请参阅更改处理优化设置

从上面的说明中,您可以看到可用内存总量是一个关键考虑事项。如果复制实例具有足够的内存,使 Amazon DMS 可以流式处理缓存的更改和持续更改,而无需写入磁盘中,则会大幅提升迁移性能。类似地,为复制实例配置足够的磁盘空间来容纳更改缓存和日志存储也可提高性能。可能的最大 IOPS 取决于选定的磁盘大小。

选择复制实例类和可用磁盘存储时,需要考虑以下因素:

  • 表大小 – 大型表加载所需的时间较长,因此这些表上的事务必须缓存到表加载之后。表加载之后将立即应用这些缓存的事务,不再保存在磁盘上。

  • 数据操控语言 (DML) 活动 – 忙碌的数据库会生成更多事务。这些事务必须缓存直至表加载。在加载表之后,单独表的事务将在所有表加载之后应用。

  • 事务大小 – 长时间运行的事务会生成大量的更改。如果 Amazon DMS 在事务模式中应用更改,则必须有足够的内存可用于流式处理事务中的所有更改,以实现最佳性能。

  • 迁移的总大小 – 大型迁移用时较长,并且相应地生成大量的日志文件。

  • 任务数 – 任务越多,所需的缓存也越多,生成的日志文件也越多。

  • 大型对象 – 具有 LOB 的表需要更长时间来加载。

一些经验证据表明,在AmazonDMS. 默认存储配置通常便已足够。

但是,运行多个任务的复制实例可能需要更多磁盘空间。此外,如果您的数据库包括大型活动表,在完全加载任务期间,您需要考虑为缓存到磁盘的事务增加磁盘空间。例如,假设您的加载用时 24 小时,每小时会生成 2 GB 的事务。在这种情况下,您可能要确保有 48 GB 的空间来容纳缓存的事务。此外,向复制实例分配的存储空间越多,获得的 IOPS 就越高。

前面的准则并未涵盖所有可能的场景。在确定复制实例的大小时,考虑特定使用案例的具体细节至关重要。开始运行迁移之后,请监控 CPU、可释放内存、空闲存储以及复制实例的 IOPS。根据您收集的数据,您可以视根据增加或减小复制实例的大小。