使用 AWS DMS 将源 RDS MySQL 数据库迁移到目标 RDS MySQL 数据库时，应遵循哪些最佳实践？

简短描述

使用 AWS DMS，您可以将数据从源数据存储迁移到目标数据存储。这两个数据存储称为端点。您可以在使用相同数据库引擎的源端点和目标端点之间进行迁移，例如从一个 MySQL 数据库迁移到另一个 MySQL 数据库。

尽管 AWS DMS 创建目标架构对象，但它只创建从源有效迁移数据所需的最小量对象。因此，AWS DMS 会创建表、主键，以及在某些情况下创建唯一索引，但不会创建二级索引、非主键约束和数据默认值等对象。有关 AWS DMS 迁移的内容的更多信息，请参阅 AWS DMS 的简要视图。

迁移前在目标数据库上预先创建表

要保留默认数据定义，请于迁移之前在目标数据库上预先创建表。根据要执行的迁移类型，使用以下方法之一：

• 对于如 MySQL 到 MySQL 这样的同构迁移，请使用本机数据库引擎实用程序（如 mysqldump）导出表定义。然后，将这些表定义导入目标，而不包含数据。创建表定义后，使用将目标表准备模式设置为 TRUNCATE_BEFORE_LOAD 的 AWS DMS 任务来加载数据。
• 对于跨不同数据库引擎的迁移，请使用 AWS Schema Conversion Tool (AWS SCT)。您也可以将此方法用于同构数据库。AWS SCT 连接到源数据库和目标数据库，然后将现有数据库架构从一个数据库引擎转换为另一个数据库引擎。您可以使用 AWS SCT 在目标数据库上预先创建保留默认数据定义的表。然后，使用将目标表准备模式设置为 TRUNCATE_BEFORE_LOAD 的 AWS DMS 任务来加载数据。有关更多信息，请参阅使用 AWS SCT 转换架构。

解决方案

遵循 MySQL 到 MySQL AWS DMS 迁移的最佳实践

将数据从 MySQL 源数据库迁移到 MySQL 目标数据库时，请使用这些最佳实践。

• 迁移期间关闭目标数据库上的备份和特定于数据库的日志（例如二进制、常规和审计）。如果需要，可以再次打开这些日志以解决问题。
• 迁移期间关闭目标数据库上的触发器、其他 cron 作业和事件计划程序。
• 执行 AWS DMS 迁移时，请避免在目标 Amazon RDS 数据库上使用多可用区。
• 执行迁移时，请避免将任何其他外部客户端流量应用到目标数据库。
• 为您的 AWS DMS 复制实例、源数据库和目标数据库预置所需的 CPU、内存、存储和 IOPS，以避免迁移期间出现资源争用。
• 在开始迁移之前，以使用 AWS DMS 变更数据捕获 (CDC) 的先决条件配置源数据库。
• 使用优化的 LOB 设置，例如有限 LOB 和内联 LOB 进行迁移。
• 如果源数据库包含许多工作负载繁重的表，请将这些表拆分为多个任务。根据表在源数据库中的大小、应用程序流量模式以及是否存在 LOB 列来拆分表。如果表有许多 LOB（TEXT 或 JSON）列，且源上的写入流量很高，则为该表创建单独的任务。事务一致性在任务中得到维护，因此重点是单独任务中的表不参与常见事务。
• 对大量源表使用并行满负载机制以缩短迁移时间。有关更多信息，请参阅对选定的表、视图和集合使用并行负载。
• 在满负载迁移期间关闭目标表上的外键约束。
• 在开始复制的 CDC 阶段之前，在目标数据库上添加二级索引。
• Amazon RDS 主用户没有默认架构表的删除和重新创建权限。因此，请避免使用 AWS DMS 从源迁移默认数据库或架构表。
• 请查看有关使用 AWS DMS 将数据从 MySQL 迁移到 MySQL 的文档，了解 AWS DMS 可以成功迁移哪些类型数据的信息。
• 在使用批量应用 CDC 方法之前，使用默认的事务 CDC 应用测试您的工作负载。有关更多信息，请参阅如何使用 DMS 批量应用功能来提高 CDC 复制性能？
• 在开始生产迁移之前，请在任何其他 QA/DEV 数据库环境中使用相同的生产数据测试迁移。进行生产迁移时，请确保使用相同的 AWS DMS 配置。

有关更多信息，请参阅提高 AWS DMS 迁移的性能。

对源数据库和目标数据库使用建议的配置和方法

1.在目标 MySQL/PostgreSQL 数据库上手动预先创建表 DDL。然后，创建将目标准备模式设置为 DO_DOTHING”/“TRUNCATE” 的 AWS DMS 任务，以便仅迁移数据。

运行以下命令以创建不包含源 MySQL 数据库数据的转储：

mysqldump -h yourhostnameorIP -u root -p --no-data --skip-triggers --single-transaction --dbname > schema.sql

此命令从源中转储 DDL 结构，不包含任何数据。

接下来，运行以下命令以恢复目标上的 DDL 结构：

mysql -u user -p -h yourhostnameorIP  database_name < schema.sql

或者，您可以允许 AWS DMS 使用 DROP AND CREATE 目标准备模式在目标上创建表。然后，在恢复 CDC 阶段的任务之前，跳到步骤 3 更改表并添加缺失的对象（如二级索引）。

**注意：**默认情况下，AWS DMS 仅使用主键或唯一键在目标上创建表。它不会将任何其他对象迁移到目标 MySQL 数据库。

2.在满负载期间，AWS DMS 不会识别外键关系表。它随机加载数据，因此，如果目标数据库启用了外键检查，则表加载可能会失败。在目标 MySQL 端点上使用此额外连接属性 (ECA) 关闭 AWS DMS 会话的外键检查。

initstmt=SET FOREIGN_KEY_CHECKS=0;

有关更多信息，请参阅使用兼容 MySQL 的数据库作为 AWS DMS 目标时的额外连接属性。

3.在 JSON 设置中，将应用缓存更改前停止任务设置为 true，并在应用缓存更改后将停止任务设置为 true。

"FullLoadSettings": {
    "TargetTablePrepMode": "TRUNCATE_BEFORE_LOAD"
    "CreatePkAfterFullLoad": false,
    "TransactionConsistencyTimeout": 600,
    "MaxFullLoadSubTasks": 8,
    "StopTaskCachedChangesNotApplied": true,   <--- set this to true
    "StopTaskCachedChangesApplied": true,    <--- set this to true
    "CommitRate": 50000,
}

满负载完成后和应用缓存的更改之前，任务将停止。任务停止时，在目标上创建主键索引和二级索引。

接下来，继续执行该任务，因为该任务在应用缓存的更改后会再次停止。然后，使用 AWS DMS 验证输出或手动验证验证迁移的数据，然后再次恢复 CDC 复制阶段的任务。通过完成此步骤，您可以确定任何问题并在恢复 CDC 复制之前解决这些问题。

4.    在“任务满负载”设置中，调整 commitRate 设置以加快从源中提取数据的速率。默认值为 10000，因此在从源表迁移大量数据时请调整此设置。

CommitRate=50000

注意：将 commitRate 更改为更高的值可能会影响性能，因此请确保监控复制实例并具有足够的内存。

5.    在目标端点上添加此 ECA，以指定用于将数据传输到目标 MySQL 的任何 .csv 文件的最大大小（以 KB 为单位）。默认值为 32,768 KB (32 MB)，有效值范围为 1–1,048,576 KB（最大 1.1 GB）。

maxFileSize=250000;

注意：当您使用目标实例（如 MySQL、Aurora 或 MariaDB）进行满负载时，请使用此选项允许 AWS DMS 在后台创建 .csv 文件，以便将数据加载到目标实例中。请使用介于 32 MB 和 1 GB 之间的值。但是，也要考虑目标实例可以处理多少量。如果您有多个任务正在加载 1 GB 的 .csv 文件，这可能会导致目标实例的开销。确保在目标位置有具备高计算能力的实例。

6.    使用有限 LOB 或内联 LOB 设置以获得更理想的性能。

**有限 LOB 模式：**使用有限 LOB 模式时，您可以指定 LOB 列数据的最大大小。这样将允许 AWS DMS 预分配资源，然后批量应用 LOB。如果 LOB 列的大小超过您在任务中指定的大小，则 AWS DMS 将会截断数据。然后发送警告到 AWS DMS 日志文件。使用有限 LOB 模式可以提高性能—然而，在运行任务之前，您必须确定源上数据的最大 LOB 大小。然后，指定最大 LOB 大小参数。最佳实践是确保您向复制实例分配了足够的内存以处理该任务。

**内联 LOB 模式：**使用内联 LOB 模式时，您可以通过复制小 LOB 和大 LOB 来迁移 LOB，而不会截断数据或降低任务的速度。首先指定 InlineLobMaxSize 参数的值。仅在“全 LOB 模式”设置为 true 时才可以指定此参数的值。AWS DMS 任务会内联传输小 LOB，这种方式更为高效。然后 AWS DMS 会查询源表，以迁移超过全 LOB 模式中指定大小的 LOB。但请注意，内联 LOB 模式仅在满负载阶段工作。

注意：在为任务指定任务设置时，您必须设置 InlineLobMaxSize。

运行这些查询以检查 LOB 大小，然后填充最大 LOB 大小。

列出具有 LOB 列的表：

select tab.table_name,
count(*) as columns
from information_schema.tables as tab
inner join information_schema.columns as col
on col.table_schema = tab.table_schema
and col.table_name = tab.table_name
and col.data_type in ('blob', 'mediumblob', 'longblob',
'text', 'mediumtext', 'longtext')
where tab.table_schema = 'your database name'.  <---- enter database name here
and tab.table_type = 'BASE TABLE'
group by tab.table_name
order by tab.table_name;

检查 LOB 列的大小：

Select (max(length (<COL_NAME>))/(1024)) as “size in KB” from <TABLE_NAME>;

检查所有表的 LOB 列大小，然后以“最大 LOB 大小 (K)”填充最大大小。

使用值大于 63 KB 的“最大 LOB 大小 (K)”选项会影响配置为在限制 LOB 模式下运行的满负载的性能。在满负载期间，AWS DMS 通过将“最大 LOB 大小 (K)”值乘以提交速率来分配内存。然后，将乘积乘以 LOB 列的数量。

当 AWS DMS 无法预先分配该内存时，AWS DMS 将开始消耗交换内存。这会影响满负载的性能。因此，如果您在使用有限 LOB 模式时遇到性能问题，请降低提交率，直到达到可接受的性能水平。或者，在首先检查表的 LOB 分布后，考虑对受支持的端点使用内联 LOB 模式。

有关更多信息，请参阅在 AWS DMS 任务中为源数据库设置 LOB 支持。

---

相关信息

使用 AWS DMS 从 MySQL 迁移到 Amazon RDS

数据库迁移分步演练