使用数据迁移将 MySQL 兼容数据库迁移到 TiDB Cloud

本文档将指导你如何使用 TiDB Cloud 控制台中的数据迁移功能，将你的 MySQL 数据库（包括 Amazon Aurora MySQL、Amazon RDS、Azure Database for MySQL - Flexible Server、Google Cloud SQL for MySQL 或自建 MySQL 实例）迁移到 TiDB Cloud Dedicated。

该功能支持将现有 MySQL 数据迁移并持续复制 MySQL 兼容源数据库的实时变更（binlog）到 TiDB Cloud，无论源库和目标库是否在同一区域，都能保证数据一致性。该流程无需单独的导出和加载操作，极大减少了停机时间，并简化了从 MySQL 向更具扩展性的 TiDB Cloud 平台的迁移过程。

如果你只想将 MySQL 兼容数据库的实时 binlog 变更同步到 TiDB Cloud，请参见 使用数据迁移将 MySQL 兼容数据库的增量数据迁移到 TiDB Cloud。

限制

可用性

• 目前，数据迁移功能不支持 TiDB Cloud Starter。

• 如果你在 TiDB Cloud 控制台的 TiDB Cloud Dedicated 集群中未看到 数据迁移入口，说明该功能在你的区域暂不可用。如需支持，请联系 TiDB Cloud Support。

• Amazon Aurora MySQL writer 实例支持现有数据和增量数据迁移。Amazon Aurora MySQL reader 实例仅支持现有数据迁移，不支持增量数据迁移。

最大迁移任务数

每个组织在 TiDB Cloud Dedicated 集群上最多可创建 200 个迁移任务。如需更多迁移任务，请 提交支持工单。

被过滤和已删除的数据库

• 系统数据库会被自动过滤，即使你选择迁移所有数据库，也不会迁移到 TiDB Cloud。也就是说，mysql、information_schema、performance_schema 和 sys 这几个数据库不会通过该功能迁移。

• 当你删除 TiDB Cloud 集群时，该集群下的所有迁移任务会被自动删除且无法恢复。

现有数据迁移的限制

• 在现有数据迁移过程中，如果目标数据库已存在待迁移的表且存在主键冲突，冲突的行会被替换。

• 对于 TiDB Cloud Dedicated，如果你的数据集小于 1 TiB，建议使用逻辑模式（默认）。如果数据集大于 1 TiB，或希望更快迁移现有数据，可以使用物理模式。详情参见 迁移现有数据和增量数据。

增量数据迁移的限制

• 在增量数据迁移过程中，如果目标数据库已存在待迁移表且有主键冲突，会报错并中断迁移。此时需确认 MySQL 源数据的准确性。如果数据无误，点击迁移任务的 重启 按钮，迁移任务会用 MySQL 源数据替换目标集群中的冲突记录。

• 在增量数据迁移（将实时变更迁移到集群）过程中，如果迁移任务从异常中恢复，可能会开启 60 秒的安全模式。在安全模式下，INSERT 语句会以 REPLACE 方式迁移，UPDATE 语句会以 DELETE 和 REPLACE 方式迁移，然后将这些事务迁移到目标 TiDB Cloud 集群，以确保异常期间的数据能顺利迁移到目标集群。在此场景下，如果 MySQL 源表没有主键或非空唯一索引，目标 TiDB Cloud 集群中可能会出现重复数据，因为数据可能被多次插入。

• 在以下场景中，如果迁移任务耗时超过 24 小时，请勿清理源数据库的 binary log，以便数据迁移能获取连续的 binary log 进行增量数据迁移：

  • 现有数据迁移过程中。
  • 现有数据迁移完成后，首次启动增量数据迁移时，延时不为 0 ms。

前置条件

在迁移前，请检查你的数据源是否受支持，确保 MySQL 兼容数据库已开启 binary log，网络连通性正常，并为源数据库和目标 TiDB Cloud 集群数据库授予所需权限。

确认数据源及版本受支持

对于 TiDB Cloud Dedicated，数据迁移功能支持以下数据源及版本：

在源 MySQL 兼容数据库中开启 binary log 以支持复制

要通过 DM 持续复制源 MySQL 兼容数据库的增量变更到 TiDB Cloud 目标集群，需要在源数据库中进行如下配置以开启 binary log：

检查当前配置并配置源 MySQL 实例

要检查当前配置，连接到源 MySQL 实例并执行以下语句：

SHOW VARIABLES WHERE Variable_name IN
('log_bin','server_id','binlog_format','binlog_row_image',
'binlog_expire_logs_seconds','expire_logs_days');

如有必要，请将源 MySQL 实例的配置修改为要求的值。

确保网络连通性

在创建迁移任务前，你需要规划并设置源 MySQL 实例、TiDB Cloud 数据迁移（DM）服务与目标 TiDB Cloud 集群之间的网络连通性。

对于 TiDB Cloud Dedicated，可用的连接方式如下：

请选择最适合你的云厂商、网络拓扑和安全需求的连接方式，并按照相应方式的设置说明进行配置。

端到端 TLS/SSL 加密

无论采用哪种连接方式，强烈建议使用 TLS/SSL 实现端到端加密。即使使用 private endpoint 或 VPC peering保障了网络路径安全，TLS/SSL 仍能保护数据本身并满足合规要求。

公网 endpoint 或 IP 地址

使用公网 endpoint 时，你可以在现在和后续 DM 任务创建过程中验证网络连通性和访问权限。TiDB Cloud 会在该阶段提供具体的出口 IP 地址及相关操作提示。

1. 确认并记录源 MySQL 实例的 endpoint 主机名（FQDN）或公网 IP 地址。

2. 确保你有权限修改数据库的防火墙或安全组规则。可参考各云厂商文档：

   • Amazon Aurora MySQL 或 Amazon RDS MySQL: Controlling access with security groups。
   • Azure Database for MySQL - Flexible Server: Public Network Access
   • Google Cloud SQL for MySQL: Authorized Networks。

3. 可选：使用具备公网访问权限的机器，结合传输加密证书，验证源数据库连通性：

   mysql -h <public-host> -P <port> -u <user> -p --ssl-ca=<path-to-provider-ca.pem> -e "SELECT version();"
   

4. 后续在数据迁移任务设置过程中，TiDB Cloud 会提供出口 IP 段。届时需将该 IP 段加入数据库的防火墙或安全组规则，操作方法同上。

Private link 或 private endpoint

如需使用云厂商原生 private link 或 private endpoint，请为你的源 MySQL 实例（RDS、Aurora 或 Azure Database for MySQL）创建 private endpoint。

VPC peering

如需使用 AWS VPC peering 或 Google Cloud VPC network peering，请参见以下配置说明。

授予迁移所需权限

在开始迁移前，你需要在源数据库和目标数据库分别设置合适的数据库用户，并授予所需权限。这些权限用于让 TiDB Cloud DM 读取 MySQL 数据、复制变更并安全写入 TiDB Cloud 集群。由于迁移涉及现有数据的全量导出和增量变更的 binlog 复制，迁移用户需要超出只读权限的特定权限。

为源 MySQL 数据库的迁移用户授权

测试环境可直接使用源 MySQL 数据库的管理员用户（如 root）。

生产环境建议为数据导出和复制专门创建用户，并仅授予必要权限：

例如，你可以在源 MySQL 实例中执行如下 GRANT 语句：

GRANT SELECT, RELOAD, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dm_source_user'@'%';

为目标 TiDB Cloud 集群授权

测试环境可直接使用 TiDB Cloud 集群的 root 账户。

生产环境建议为目标 TiDB Cloud 集群专门创建复制用户，并仅授予必要权限：

例如，你可以在目标 TiDB Cloud 集群中执行如下 GRANT 语句：

GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX ON *.* TO 'dm_target_user'@'%';

第 1 步：进入数据迁移页面

1. 登录 TiDB Cloud 控制台，进入项目的 Clusters 页面。

   提示：

   你可以通过左上角的下拉框切换组织、项目和集群。

2. 点击目标集群名称进入概览页，然后点击左侧导航栏的 Data > Data Migration。

3. 在 Data Migration 页面，点击右上角的 Create Migration Job。此时会进入 Create Migration Job 页面。

第 2 步：配置源和目标连接

在 Create Migration Job 页面，配置源和目标连接信息。

1. 输入任务名称，需以字母开头且少于 60 个字符。可包含字母（A-Z, a-z）、数字（0-9）、下划线（_）和连字符（-）。

2. 填写源连接信息。

   • Data source：数据源类型。

   • Connectivity method：根据安全需求和云厂商选择数据源连接方式：

     • Public IP：适用于所有云厂商（推荐用于测试和概念验证迁移）。
     • Private Link：仅适用于 AWS 和 Azure（推荐生产环境需要私有连接的场景）。
     • VPC Peering：仅适用于 AWS 和 Google Cloud（推荐生产环境需要低延时、同区域内网连接且 VPC/VNet CIDR 不重叠的场景）。

   • 根据所选 Connectivity method，进行如下操作：

     • 选择 Public IP 或 VPC Peering 时，在 Hostname or IP address 字段填写数据源的主机名或 IP 地址。
     • 选择 Private Link 时，填写以下信息：
       • Endpoint Service Name（数据源为 AWS 时可用）：填写为 RDS 或 Aurora 实例创建的 VPC endpoint service 名称（格式：com.amazonaws.vpce-svc-xxxxxxxxxxxxxxxxx）。
       • Private Endpoint Resource ID（数据源为 Azure 时可用）：填写 MySQL Flexible Server 实例的 resource ID（格式：/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DBforMySQL/flexibleServers/<server>）。

   • Port：数据源端口。

   • User Name：数据源用户名。

   • Password：用户名对应的密码。

   • SSL/TLS：启用 SSL/TLS 以实现端到端数据加密（强烈推荐所有迁移任务开启）。根据 MySQL 服务器的 SSL 配置上传相应证书。

     SSL/TLS 配置选项：

     • 选项 1：仅服务器认证

       • 如果 MySQL 服务器仅配置服务器认证，只需上传 CA Certificate。
       • 此时，MySQL 服务器会出示证书证明身份，TiDB Cloud 会用 CA 验证服务器证书。
       • CA 证书可防止中间人攻击，且当 MySQL 服务器以 require_secure_transport = ON 启动时为必需。

     • 选项 2：客户端证书认证

       • 如果 MySQL 服务器配置了客户端证书认证，需上传 Client Certificate 和 Client private key。
       • 此时，TiDB Cloud 会向 MySQL 服务器出示证书，但不会验证 MySQL 服务器的证书。
       • 该选项通常用于 MySQL 服务器配置了 REQUIRE SUBJECT '...' 或 REQUIRE ISSUER '...'，但未配置 REQUIRE X509，允许仅校验客户端证书的特定属性而无需完整 CA 验证。
       • 该配置常用于自签名或自建 PKI 环境下的客户端证书认证。注意此配置易受中间人攻击，不推荐在生产环境使用，除非有其他网络级别的安全保障。

     • 选项 3：双向 TLS（mTLS）- 最高安全级别

       • 如果 MySQL 服务器配置了双向 TLS（mTLS）认证，需上传 CA Certificate、Client Certificate 和 Client private key。
       • 此时，MySQL 服务器通过客户端证书验证 TiDB Cloud 身份，TiDB Cloud 通过 CA 证书验证 MySQL 服务器身份。
       • 当 MySQL 服务器为迁移用户配置了 REQUIRE X509 或 REQUIRE SSL 时，必须使用此选项。
       • 该选项适用于 MySQL 服务器要求客户端证书认证的场景。
       • 证书可通过以下方式获取：
         • 从云厂商下载（见 TLS 证书链接）。
         • 使用组织内部 CA 证书。
         • 自签名证书（仅限开发/测试环境）。

3. 填写目标连接信息。

   • User Name：输入 TiDB Cloud 目标集群的用户名。
   • Password：输入 TiDB Cloud 用户名的密码。

4. 点击 Validate Connection and Next 验证所填信息。

5. 根据提示信息进行操作：

   • 如果使用 Public IP 或 VPC Peering 作为连接方式，需要将数据迁移服务的 IP 地址加入源数据库和防火墙（如有）的 IP 访问列表。
   • 如果使用 Private Link 作为连接方式，会提示你接受 endpoint 请求：
     • AWS：进入 AWS VPC 控制台，点击 Endpoint services，接受来自 TiDB Cloud 的 endpoint 请求。
     • Azure：进入 Azure 门户，搜索你的 MySQL Flexible Server 名称，点击左侧导航栏的 Setting > Networking，在右侧 Private endpoint 区域批准 TiDB Cloud 的待处理连接请求。

第 3 步：选择迁移任务类型

在 Choose migration job type 步骤，你可以选择迁移现有数据和增量数据、仅迁移现有数据，或仅迁移增量数据。

迁移现有数据和增量数据

如需一次性将数据迁移到 TiDB Cloud，选择 Existing data migration 和 Incremental data migration，以保证源库和目标库数据一致性。

你可以使用 物理模式 或 逻辑模式 迁移 现有数据 和 增量数据。

• 默认模式为 逻辑模式。该模式将 MySQL 源数据库数据导出为 SQL 语句并在 TiDB 上执行。此模式下，目标表可为空表或非空表，但性能低于物理模式。

• 对于大数据集，推荐使用 物理模式。该模式将 MySQL 源数据库数据导出并编码为 KV 对，直接写入 TiKV，以获得更高性能。此模式要求迁移前目标表为空。以 16 RCU（Replication Capacity Units）规格为例，性能约为逻辑模式的 2.5 倍。其他规格性能较逻辑模式提升 20%~50%。性能数据仅供参考，实际表现可能因场景不同而异。

物理模式会尽可能快地导出 MySQL 源数据，不同规格对 MySQL 源数据库的 QPS 和 TPS 有不同影响。下表展示了各规格的性能回退情况。

仅迁移现有数据

如只需将源数据库的现有数据迁移到 TiDB Cloud，选择 Existing data migration。

你可以使用物理模式或逻辑模式迁移现有数据。详情参见 迁移现有数据和增量数据。

仅迁移增量数据

如只需将源数据库的增量数据迁移到 TiDB Cloud，选择 Incremental data migration。此时，迁移任务不会迁移源数据库的现有数据，仅迁移任务明确指定的源数据库实时变更。

关于增量数据迁移的详细操作，请参见 使用数据迁移将 MySQL 兼容数据库的增量数据迁移到 TiDB Cloud。

第 4 步：选择要迁移的对象

1. 在 Choose Objects to Migrate 页面，选择要迁移的对象。你可以点击 All 选择全部对象，或点击 Customize，再勾选对象名称旁的复选框选择对象。

   • 点击 All 时，迁移任务会将整个源数据库实例的现有数据迁移到 TiDB Cloud，并在全量迁移后同步实时变更（前提是上一步已勾选 Existing data migration 和 Incremental data migration）。
   • 点击 Customize 并选择部分数据库时，迁移任务会将所选数据库的现有数据和实时变更迁移到 TiDB Cloud（前提是上一步已勾选 Existing data migration 和 Incremental data migration）。
   • 点击 Customize 并选择某数据库下的部分表时，迁移任务只会迁移所选表的现有数据和实时变更。后续在同一数据库中新建的表不会被迁移。

2. 点击 Next。

第 5 步：前置检查

在 Precheck 页面，你可以查看前置检查结果。如检查失败，请根据 Failed 或 Warning 详情解决问题，然后点击 Check again 重新检查。

如仅有部分检查项为警告，你可评估风险后选择是否忽略警告。若全部警告被忽略，迁移任务会自动进入下一步。

关于错误及解决方法，参见 前置检查错误及解决方案。

关于前置检查项说明，参见 Migration Task Precheck。

如所有检查项均为 Pass，点击 Next。

第 6 步：选择规格并启动迁移

在 Choose a Spec and Start Migration 页面，根据你的性能需求选择合适的迁移规格。关于规格详情，参见 数据迁移规格。

选择规格后，点击 Create Job and Start 启动迁移。

第 7 步：查看迁移进度

迁移任务创建后，你可以在 Migration Job Details 页面查看迁移进度。进度会显示在 Stage and Status 区域。

你可以在任务运行期间暂停或删除迁移任务。

如迁移任务失败，解决问题后可恢复任务。

任何状态下均可删除迁移任务。

如迁移过程中遇到问题，请参见 迁移错误及解决方案。

扩展迁移任务规格

TiDB Cloud Dedicated 支持根据不同场景的性能和成本需求，动态扩展或缩减迁移任务规格。

不同迁移规格对应不同性能。你在不同阶段可能有不同的性能需求。例如，在现有数据迁移阶段，你希望尽可能快，可选择大规格（如 8 RCU）；现有数据迁移完成后，增量迁移对性能要求不高，可将规格从 8 RCU 缩减为 2 RCU 以节省成本。

扩展迁移任务规格时需注意：

• 扩展操作大约需要 5~10 分钟。
• 如扩展失败，任务规格会保持扩展前的状态。

限制

• 仅当迁移任务处于 Running 或 Paused 状态时可扩展规格。
• 现有数据导出阶段不支持扩展迁移任务规格。
• 扩展迁移任务规格会重启任务。如果任务的源表没有主键，可能会插入重复数据。
• 扩展期间，请勿清理源数据库的 binary log 或临时增加 MySQL 源数据库的 expire_logs_days，否则任务可能因无法获取连续 binary log 位置而失败。

扩展操作流程

1. 登录 TiDB Cloud 控制台，进入项目的 Clusters 页面。

2. 点击目标集群名称进入概览页，然后点击左侧导航栏的 Data > Data Migration。

3. 在 Data Migration 页面，找到要扩展的迁移任务，在 Action 列点击 ... > Scale Up/Down。

4. 在 Scale Up/Down 窗口选择你要使用的新规格，然后点击 Submit。你可以在窗口底部查看新规格的价格。