View a markdown version of this page

使用 MySQL-compatible 数据库作为源 AWS DMS - AWS Database Migration Service
MySQL 向 MySQL 迁移将 MySQL 作为源将自管理 MySQL 作为源使用 AWS托管的 MySQL 作为源Aurora MySQL 8.4 源代码将 MySQL 作为源时的限制支持 XA 事务端点设置MySQL 的源数据类型

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

使用 MySQL-compatible 数据库作为源 AWS DMS

您可以使用数据库迁移服务从任何 MySQL-compatible 数据库（MySQL、MariaDB 或 Amazon Aurora MySQL AWS ）迁移数据。

有关 AWS DMS 支持作为源的 MySQL 版本的信息，请参阅的来源 AWS DMS。

您可以使用 SSL 来加密 MySQL-compatible 终端节点和复制实例之间的连接。有关在 MySQL-compatible终端节点上使用 SSL 的更多信息，请参阅将 SSL 与 AWS Database Migration Service。

在以下各节中，术语“自管理”适用于在本地安装或在 Amazon EC2 上安装的任何数据库。术语“AWS托管”适用于 Amazon RDS、Amazon Aurora 或 Amazon S3 上的任何数据库。

有关使用 MySQL-compatible 数据库和的更多详细信息 AWS DMS，请参阅以下各节。

注意

配置 AWS Database Migration Service (AWS DMS) 映射规则时，请务必避免对数据库或架构名称使用通配符 (%)。相反，您必须仅明确指定需要进行迁移的用户创建数据库。使用通配符包括迁移过程中的所有数据库，包括目标实例上不需要的系统数据库。由于 MySQL Amazon RDS 主用户缺乏将数据导入目标系统数据库的必要权限，因此尝试迁移这些系统数据库会失败。

使用从 MySQL 迁移到 MySQL AWS DMS

对于异构迁移，从MySQL以外的数据库引擎迁移到MySQL数据库，几乎 AWS DMS 总是最好的迁移工具。但是，对于同构迁移，即从 MySQL 数据库迁移到 MySQL 数据库，我们建议您使用同构数据迁移项目。与 AWS DMS相比，同构数据迁移使用原生数据库工具来提供更好的数据迁移性能和准确性。

使用任何 MySQL-compatible 数据库作为源 AWS DMS

在开始使用 MySQL 数据库作为源之前 AWS DMS，请确保满足以下先决条件。这些先决条件适用于自行管理或由管理的 AWS来源。

您必须拥有一个 AWS DMS 具有复制管理员角色的帐户。该角色需要以下权限：

  • REPLICATION CLIENT – 仅 CDC 任务需要此权限。换而言之，full-load-only 任务不需要此权限。

    注意

    对于 MariaDB 版本 10.5.2+，你可以使用 BINLOG MONITOR，它是复制客户端的替代品。

  • REPLICATION SLAVE – 仅 CDC 任务需要此权限。换而言之，full-load-only 任务不需要此权限。

  • SUPER - 仅 MySQL 5.6.6 之前的版本需要此权限。

AWS DMS 用户还必须对指定用于复制的源表具有 SELECT 权限。

如果您使用 MySQL-specific 预迁移评估，请授予以下权限：

grant select on mysql.user to <dms_user>;
grant select on mysql.db to <dms_user>;
grant select on mysql.tables_priv to <dms_user>;
grant select on mysql.role_edges to <dms_user>  #only for MySQL version 8.0.11 and higher
grant select on performance_schema.replication_connection_status to <dms_user>;  #Required for primary instance validation - MySQL version 5.7 and higher only

如果您使用的是 RDS 源并计划运行 MySQL-specific 迁移前评估，请添加以下权限：

grant select on mysql.rds_configuration to <dms_user>;  #Required for binary log retention check

如果参数 BatchEnable 为 true，则需要授予：

grant create temporary tables on `<schema>`.* to <dms_user>;

使用自建 MySQL-compatible 数据库作为源 AWS DMS

您可以使用以下自建 MySQL-compatible 数据库作为源： AWS DMS

  • MySQL Community Edition

  • MySQL Standard Edition

  • MySQL Enterprise Edition

  • MySQL Cluster Carrier Grade Edition

  • MariaDB Community Edition

  • MariaDB Enterprise Edition

  • MariaDB Column Store

要使用 CDC，请确保启用二进制日志记录。要启用二进制日志记录，则必须在 MySQL 的 my.ini (Windows) 或 my.cnf (UNIX) 文件中配置以下参数。

参数

值

server_id

将该参数设置为 1 或更大的值。

log-bin

设置二进制日志文件的路径，例如 log-bin=E:\MySql_Logs\BinLog。请勿包含文件扩展名。

binlog_format

将该参数设置为 ROW。我们建议在复制期间使用此设置，因为在某些情况下，如果 binlog_format 设置为 STATEMENT，那么在将数据复制到目标时可能会导致不一致。如果 binlog_format 设置为 MIXED，数据库引擎还会向目标写入类似的不一致数据，因为数据库引擎会自动切换到基于 STATEMENT 的日志记录，这可能导致在目标数据库上写入不一致的数据。

expire_logs_days

或者

binlog_expire_logs_seconds

expire_logs_days 参数自 MySQL 8.0 起已被弃用，在 MySQL 8.4 中已删除。有关更多信息，请参阅服务器和状态变量以及自 8.0 起在 MySQL 8.4 中添加、弃用或删除的选项。

在 MySQL 5.x 中使用该expire_logs_days参数。我们建议您将此参数设置为1或更大，请参阅二进制日志记录选项和变量。

在 MySQL 8.0 及更高版本中使用该binlog_expire_logs_seconds参数。我们建议您将此参数的值设置为86400秒（1 天）或更大。请参阅二进制日志记录选项和变量。

binlog_checksum

对于 DMS 版本 3.4.7 或之前的版本，请将此参数设置为 NONE。

binlog_row_image

将该参数设置为 FULL。

log_slave_updates

如果您使用 MySQL 或 MariaDB 只读副本作为源，请将此参数设置为 TRUE。

如果您使用 MySQL 或 MariaDB 只读副本作为 DMS 迁移任务的源，并使用迁移现有数据并复制持续更改模式，则可能会丢失数据。在以下情况下，无论是在完全加载期间还是 CDC 期间，DMS 都不会写入事务：

  • 在 DMS 任务开始之前，事务已提交到主实例。

  • 由于主实例和副本之间存在延迟，直到 DMS 任务开始后，事务才提交到副本。

主实例和副本之间的延迟时间越长，数据丢失的可能性就越大。

如果您的源使用了 NDB（集群式）数据库引擎，则必须配置以下参数以对使用该存储引擎的表启用 CDC。请在 MySQL 的 my.ini (Windows) 或 my.cnf (UNIX) 文件中添加这些更改。

参数

值

ndb_log_bin

将该参数设置为 ON。此值确保在集群表中进行的更改保存到二进制日志。

ndb_log_update_as_write

将该参数设置为 OFF。此值可以防止将 UPDATE 语句作为 INSERT 语句写入二进制日志。

ndb_log_updated_only

将该参数设置为 OFF。此值可确保二进制日志包含整个行而不仅仅是更改的列。

使用 AWS-托管 MySQL-compatible 数据库作为源 AWS DMS

您可以使用以下 AWS托管的 MySQL-compatible 数据库作为源： AWS DMS

  • MySQL Community Edition

  • MariaDB Community Edition

  • 亚马逊 Aurora MySQL-Compatible 版

使用 AWS托管 MySQL-compatible 数据库作为源时 AWS DMS，请确保您满足以下使用 CDC 的先决条件：

  • 要为 RDS for MySQL 和 RDS for MariaDB 启用二进制日志，请在实例级别启用自动备份。要为 Aurora MySQL 集群启用二进制日志，请更改参数组中的变量 binlog_format。

    有关设置自动备份的更多信息，请参阅《Amazon RDS 用户指南》中的使用自动备份。

    有关为 Amazon RDS for MySQL 数据库设置二进制日志记录的更多信息，请参阅《Amazon RDS 用户指南》中的设置二进制日志记录格式。

    有关为 Aurora MySQL 集群设置二进制日志记录的更多信息，请参阅如何为 Amazon Aurora MySQL 集群开启二进制日志记录？。

  • 如果您计划使用 CDC，请启用二进制日志记录。有关为 Amazon RDS for MySQL 数据库设置二进制日志记录的更多信息，请参阅《Amazon RDS 用户指南》中的设置二进制日志记录格式。

  • 确保二进制日志可供使用 AWS DMS。由于 AWS托管的 MySQL-compatible 数据库会尽快清除二进制日志，因此您应该延长日志的可用时间。例如，要将日志保留时间延长至 24 小时，请运行以下命令。

    
 call mysql.rds_set_configuration('binlog retention hours', 24);

  • 将 binlog_format 参数设置为 "ROW"。

    注意

    在 MySQL 或 MariaDB 上，binlog_format 是一个动态参数，因此您不必重新启动即可使新值生效。但是，新值仅适用于新会话。如果您出于复制目的将 binlog_format 切换为 ROW，则如果这些会话在您更改值之前已启动，则数据库仍可以使用 MIXED 格式创建后续的二进制日志。这可能会 AWS DMS 阻止正确捕获源数据库上的所有更改。更改 MariaDB 或 MySQL 数据库的 binlog_format 设置时，请务必重新启动数据库以关闭所有现有会话，或者重新启动任何执行 DML（Data Manipulation Language，数据操作语言）操作的应用程序。将binlog_format参数更改为后强制数据库重新启动所有会话ROW将确保您的数据库使用正确的格式写入所有后续的源数据库更改，以便 AWS DMS 可以正确捕获这些更改。

  • 将 binlog_row_image 参数设置为 "Full"。

  • 对于 DMS 版本 3.4.7 或之前的版本，请将 binlog_checksum 参数设置为 "NONE"。有关在 Amazon RDS MySQL 中设置参数的更多信息，请参阅《Amazon RDS 用户指南》中的使用自动备份。

  • 如果您使用 Amazon RDS MySQL 或 Amazon RDS MariaDB 只读副本作为源，请在只读副本上启用备份，并确保 log_slave_updates 参数设置为 TRUE。

有关 Aurora MySQL 8.4 安全变更的更多信息，请参阅亚马逊 Aurora MySQL 的安全性以及亚马逊 Aurora 和 Secrets Manager 的密码管理。

Aurora MySQL 8.4 源代码的注意事项

Aurora MySQL 8.4 引入了可能会影响 AWS DMS 源端点连接的安全更改。在将 Aurora MySQL 源代码升级到版本 8.4 之前，请查看以下内容。

TLS 强制执行

Aurora MySQL 8.4 ON 默认设置require_secure_transport为，这意味着所有连接都必须使用 TLS。如果您的 AWS DMS 源终端节点连接到 Aurora MySQL 8.4，并且 SSL 模式设置为无，则连接将被拒绝。如果您的终端节点 SSL 模式设置为无，您将收到以下错误：MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON。将端点 SSL 模式设置为 verify-ca 或 verify-ful l。两种模式都需要 CA 证书。或者，OFF在 Aurora 集群参数组中设置require_secure_transport为以允许未加密的连接。

注意

Aurora MySQL 8.4 仅支持 TLS 1.2 的 GCM 密码套件。所有 CBC-mode 密码均已删除。 AWS DMS 对 MySQL 和 Aurora MySQL 终端节点使用 TLS 1.2，并将自动协商支持的 GCM 密码。如果您有自定义密码配置，请确认它们包含以下支持的密码之一： ECDHE-RSA-AES128-GCM-SHA256、、 ECDHE-RSA-AES256-GCM-SHA384或。 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384

注意

AWS DMS 不支持 MySQL 终端节点的 TLS 1.3。这不会影响与 Aurora MySQL 8.4 的连接，因为 Aurora MySQL 8.4 继续支持 TLS 1.2。

身份验证（适用于 MySQL 的 Aurora MySQL 和 RDS 8.4）

Aurora MySQL 8.4 将default_authentication_plugin参数替换为authentication_policy，默认为*:caching_sha2_password。升级后，现有数据库用户会保留其当前的身份验证插件。如果您在升级后创建新的 AWS DMS 终端节点用户，则除非您在集群参数组*:mysql_native_password中authentication_policy将其设置为，否则他们将caching_sha2_password默认使用。

主用户密码重置

升级到 Aurora MySQL 8.4 后，通过 AWS 管理控制台、CLI 或 Secrets Manager 轮换重置主用户密码会将主用户的身份验证插件设置为authentication_policy参数定义的默认值。如果设置authentication_policy为其默认值 (*:caching_sha2_password)，则在下次重置密码caching_sha2_password时，主用户的身份验证插件mysql_native_password将从变为。

如果您的 AWS DMS 源端点使用主用户帐户，请在重置密码后验证连接。要避免更改身份验证插件，请执行以下任一操作：

  • *:mysql_native_password在重置密码之前，在集群参数组中设置为，或者 authentication_policy

  • 使用明确指定的身份验证插件创建专用 AWS DMS 端点用户（推荐）。例如：CREATE USER 'dms_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

使用 MySQL 数据库作为源代码的限制 AWS DMS

使用 MySQL 数据库作为源时，请考虑以下事项：

  • Amazon RDS MySQL 5.5 或更低版本不支持更改数据捕获（CDC）。对于 Amazon RDS MySQL，您必须使用版本 5.6、5.7 或 8.0 才能启用 CDC。自管理 MySQL 5.5 源支持 CDC。

  • 对于 CDC，CREATE TABLE、ADD COLUMN 和 DROP COLUMN 更改列数据类型，并支持 renaming a column。但是，不支持 DROP TABLE、RENAME TABLE 和对其他属性（例如列默认值、列可为 null 值、字符集等）进行更新。

  • 对于源上的分区表，当您将目标表准备模式设置为 “在目标上删除表” 时， AWS DMS 会在 MySQL 目标上创建一个没有任何分区的简单表。要将分区表迁移到目标上的分区表，请预先在目标 MySQL 数据库创建分区表。

  • 关系目标不支持使用ALTER TABLE table_name ADD COLUMN column_name语句将列添加到表的开头 (FIRST) 或中间 (AFTER)。列始终添加到表的末尾。当目标是 Amazon S3 或 Amazon Kinesis Data Streams 时，支持使用 FIRST 或 AFTER 添加列。

  • 当表名称包含大写和小写字符且源引擎托管于包含不区分大小写的文件名的操作系统上时，CDC 不受支持。一个示例是使用 HFS+ 的 Microsoft Windows 或 OS X。

  • 你可以使用 Aurora MySQL-Compatible Edition Serverless v1 进行满载，但不能将其用于 CDC。这是因为您无法为 MySQL 启用先决条件。有关更多信息，请参阅参数组和 Aurora Serverless v1。

    Aurora MySQL-Compatible 版无服务器 v2 支持 CDC。

  • 列上的 AUTO_INCREMENT 属性不会迁移到目标数据库列。

  • 当二进制日志未存储在标准块存储上时，不支持捕获更改。例如，当二进制日志存储在 Amazon S3 中时，CDC 不起作用。

  • AWS DMS 默认使用InnoDB存储引擎创建目标表。如果您需要使用 InnoDB 之外的存储引擎，则必须手动创建该表并使用 Do nothing (不执行任何操作) 模式迁移到该表。

  • 除非您的 DMS 迁移任务模式为 “迁移现有数据 — 仅限满载”， AWS DMS 否则您不能使用 Aurora MySQL 副本作为源。

  • 如果 MySQL-compatible 源在满载期间停止，则 AWS DMS 任务不会因错误而停止。该任务将成功结束，但目标可能与源不同步。如果发生这种情况，请重新启动该任务或重新加载受影响的表。

  • 在列值的一部分上创建的索引不会迁移。例如，索引 CREATE INDEX first_ten_chars ON customer (名称 (10)) 不在目标上创建。

  • 在某些情况下，任务配置为不复制 LOB（任务设置中的 SupportLobs “” 为 false 或者在任务控制台中选择了 “不包含 LOB 列”）。在这些情况下， AWS DMS 不会将任何 MEDIUMBLOB、LONGBLOB、MEDIUMTEXT 和 LONGTEXT 列迁移到目标。

    BLOB、TINYBLOB、TEXT 和 TINYTEXT 列不会受到影响且将迁移到目标。

  • MariaDB 源数据库和目标数据库不支持临时数据表或系统版本控制表。

  • 如果在两个 Amazon RDS Aurora MySQL 集群之间迁移，则 RDS Aurora MySQL 源终端节点必须是 read/write 实例，而不是副本实例。

  • AWS DMS 目前不支持 MariaDB 的视图迁移。

  • AWS DMS 不支持 MySQL 分区表的 DDL 更改。要跳过 CDC 期间因分区 DDL 更改而暂停表的情况，请将 skipTableSuspensionForPartitionDdl 设置为 true。

  • AWS DMS 仅支持 3.5.0 及更高版本中的 XA 事务。以前的版本不支持 XA 事务。 AWS DMS 在 MariaDB 10.6 或更高版本中不支持 XA 事务。有关更多信息，请参阅以下内容。支持 XA 事务

  • AWS DMS 不使用 GTID 进行复制，即使源数据包含 GTID 也是如此。

  • AWS DMS 不支持 Aurora MySQL 增强型二进制日志。

  • AWS DMS 不支持二进制日志事务压缩。

  • AWS DMS 不会在使用 InnoDB 存储引擎的 MySQL 数据库的 “删除级联” 和 “更新时级联” 事件进行传播。对于这些事件，MySQL 不会生成二进制日志事件来反映子表上的级联操作。因此， AWS DMS 无法将相应的更改复制到子表。有关更多信息，请参阅 索引、外键或级联更新内容或删除内容未迁移。

  • AWS DMS 不捕获对计算（VIRTUAL和GENERATED ALWAYS）列的更改。要解决此限制，请执行以下操作之一：

    • Pre-create 目标数据库中的目标表，然后使用DO_NOTHING或TRUNCATE_BEFORE_LOAD满载 AWS DMS 任务设置创建任务。

    • 添加转换规则以从任务范围中移除计算列。有关转换规则的信息，请参阅转换规则和操作。

  • 由于 MySQL 的内部限制， AWS DMS 可以处理大小不超过 4GB 的二进制日志。大于 4GB 的二进制日志可能会导致 DMS 任务失败或其他不可预测的行为。您必须减小事务的大小，以避免二进制日志大于 4GB。

  • AWS DMS 不支持架构、表和列名中的反引号 (`') 或单引号 ()。

  • AWS DMS 不会迁移源数据库中不可见列的数据。要将这些列纳入迁移范围内，请使用 ALTER TABLE 语句使这些列可见。

支持 XA 事务

扩展架构（XA）事务用于将来自多个事务资源的一系列操作，分组为单个可靠的全局事务。XA 事务使用两阶段提交协议。通常，在有未处理的 XA 事务时捕获更改可能会导致数据丢失。如果您的数据库不使用 XA 事务，则可以使用默认值 TRUE 忽略此权限和配置 IgnoreOpenXaTransactionsCheck。要开始从具有 XA 事务的源进行复制，请执行以下操作：

  • 确保终 AWS DMS 端用户具有以下权限：

    grant XA_RECOVER_ADMIN on *.* to 'userName'@'%';

  • 将端点设置 IgnoreOpenXaTransactionsCheck 设置为 false。

注意

AWS DMS 不支持 MariaDB 源数据库 10.6 或更高版本上的 XA 事务。

使用 MySQL 作为来源时的端点设置 AWS DMS

您可以使用端点设置来配置 MySQL 源数据库，这与使用额外连接属性类似。您可以在使用 AWS DMS 控制台创建源端点时指定设置，或者使用中带有 --my-sql-settings '{"EndpointSetting": "value", ...}' JSON 语法的create-endpointAWS CLI命令来指定设置。

下表显示了将 MySQL 用作源时您可以使用的端点设置。

Name 说明

ConnectionTimeout

使用此额外连接属性（ECA）设置 MySQL 实例的端点连接超时时间（以秒为单位）。默认值为 10 秒。ECA 示例：ConnectionTimeout=30。
EventsPollInterval

指定数据库空闲 changes/events时检查二进制日志中是否有新内容的频率。

默认值：5

有效值：1-60

示例：--my-sql-settings '{"EventsPollInterval": 5}'

在示例中，每五秒钟 AWS DMS 检查一次二进制日志中的更改。
ExecuteTimeout

对于 3.4.7 及更高 AWS DMS 版本，设置 MySQL 源端点的客户端语句超时时间，以秒为单位。

默认值：60

示例：--my-sql-settings '{"ExecuteTimeout": 1500}'
ServerTimezone

指定源 MySQL 数据库的时区。

示例：--my-sql-settings '{"ServerTimezone": "US/Pacific"}'
AfterConnectScript

指定要在 AWS DMS 连接到端点后立即运行的脚本。无论 SQL 语句是否成功，迁移任务都会继续运行。

有效值：一个或多个有效的 SQL 语句 (用分号分隔)。

示例：--my-sql-settings '{"AfterConnectScript": "ALTER SESSION SET CURRENT_SCHEMA=system"}'
CleanSourceMetadataOnMismatch

出现不匹配情况时在复制实例上清除并重新创建表元数据信息。例如，对表运行更改 DDL 可能会产生有关在复制实例中缓存的表的不同信息。布尔值。

默认值：false

示例：--my-sql-settings '{"CleanSourceMetadataOnMismatch": false}'
skipTableSuspensionForPartitionDdl

AWS DMS 不支持 MySQL 分区表的 DDL 更改。对于 3.4.6 及更高 AWS DMS 版本，将此设置为在 CDC 期间更改分区 DDL 时会true跳过暂停表。 AWS DMS 忽略与分区表相关的 DDL，并继续处理进一步的二进制日志更改。

默认值：false

示例：--my-sql-settings '{"skipTableSuspensionForPartitionDdl": true}'
IgnoreOpenXaTransactionsCheck

对于 3.5.0 及更高 AWS DMS 版本，指定任务在启动时是否应忽略打开的 XA 事务。如果您的源有 XA 事务，则将此项设置为 false。

默认值：true

示例：--my-sql-settings '{"IgnoreOpenXaTransactionsCheck": false}'

MySQL 的源数据类型

下表显示了使用时支持的 MySQL 数据库源数据类型 AWS DMS 以及 AWS DMS 数据类型的默认映射。

有关如何查看目标中映射的数据类型的信息，请参阅有关所使用的目标终端节点的部分。

有关 AWS DMS 数据类型的更多信息，请参见AWS Database Migration Service 的数据类型。

MySQL 数据类型

AWS DMS 数据类型

INT

INT4

BIGINT

INT8

MEDIUMINT

INT4

TINYINT

INT1

SMALLINT

INT2

UNSIGNED TINYINT

UINT1

UNSIGNED SMALLINT

UINT2

UNSIGNED MEDIUMINT

UINT4

UNSIGNED INT

UINT4

UNSIGNED BIGINT

UINT8

DECIMAL(10)

NUMERIC (10,0)

BINARY

BYTES(1)

BIT

BOOLEAN

BIT(64)

BYTES(8)

BLOB

BYTES(65535)

LONGBLOB

BLOB

MEDIUMBLOB

BLOB

TINYBLOB

BYTES(255)

DATE

DATE

DATETIME

DATETIME

不带括号值的 DATETIME 复制时不包括毫秒。括号值为 1 到 5 的 DATETIME（例如 DATETIME(5)）在复制时包括毫秒。

复制 DATETIME 列时，时间在目标上保持不变。它不会转换为 UTC。

TIME

string

TIMESTAMP

DATETIME

复制 TIMESTAMP 列时，目标上的时间会转换为 UTC。

YEAR

INT2

DOUBLE

REAL8

FLOAT

REAL(DOUBLE)

如果 FLOAT 值不在以下范围内，请使用转换将 FLOAT 映射到 STRING。有关转换的更多信息，请参阅 转换规则和操作。

支持的 FLOAT 范围为 -1.79E+308 到 -2.23、0 和 2. E-308 23 到 1.79E+308 E-308

VARCHAR(45)

WSTRING (45)

VARCHAR(2000)

WSTRING (2000)

VARCHAR(4000)

WSTRING (4000)

VARBINARY (4000)

BYTES (4000)

VARBINARY (2000)

BYTES (2000)

CHAR

WSTRING

TEXT

WSTRING

LONGTEXT

NCLOB

MEDIUMTEXT

NCLOB

TINYTEXT

WSTRING(255)

GEOMETRY

BLOB

POINT

BLOB

LINESTRING

BLOB

POLYGON

BLOB

MULTIPOINT

BLOB

MULTILINESTRING

BLOB

MULTIPOLYGON

BLOB

GEOMETRYCOLLECTION

BLOB

ENUM

WSTRING () length

这length是 ENUM 中最长值的长度。

SET

WSTRING () length

这里length是 SET 中所有值的总长度，包括逗号。

JSON

CLOB
注意

在某些情况下，您可以使用“零”值（即 0000-00-00）来指定 DATETIME 和 TIMESTAMP 数据类型。如果这样做，请确保复制任务中的目标数据库支持 DATETIME 和 TIMESTAMP 数据类型的“零”值。否则，这些值在目标上将被记录为 null。