迁移时源库为MySQL的注意事项及限制

重要

本文中含有需要您注意的重要提示信息,忽略该信息可能对您的业务造成影响,请务必仔细阅读。

如果迁移的源数据库类型为MySQL,如自建MySQL、RDS MySQL,您需要在配置具体的迁移任务前,参考本文的注意事项及限制,以保障数据迁移任务的正常运行。

源库为MySQL的迁移方案概览

根据如下迁移方案,查看迁移任务的注意事项及限制:

MySQL间的迁移

如果迁移的目标数据库类型为MySQL,如RDS MySQL、自建MySQL,具体注意事项及限制如下:

类型

说明

源库限制

  • 带宽要求:源库所属的服务器需具备足够出口带宽,否则将影响数据迁移速率。

  • 待迁移的表需具备主键或唯一约束,且字段具有唯一性,否则可能会导致目标数据库中出现重复数据。

  • 如迁移对象为表级别,且需进行编辑(如表列名映射),则单次迁移任务仅支持迁移至多1000张表。当超出数量限制,任务提交后会显示请求报错,此时建议您拆分待迁移的表,分批配置多个任务,或者配置整库的迁移任务。

  • 如需进行增量迁移,Binlog日志:

    • 需开启,并且binlog_format为row、binlog_row_image为full。否则预检查阶段提示报错,且无法成功启动数据迁移任务。

      重要

      如源实例自建MySQL是双主集群(两者互为主从),为保障DTS能获取全部的Binlog日志,则您需开启参数log_slave_updates。

    • DTS要求源数据库的本地Binlog日志至少保留7天以上,否则DTS可能因无法获取Binlog而导致任务失败,极端情况下甚至可能会导致数据不一致或丢失。由于您所设置的Binlog日志保存时间低于DTS要求的时间进而导致的问题,不在DTS的SLA保障范围内。

  • 源库的操作限制:

    • 在库表结构迁移和全量迁移阶段,请勿执行库或表结构变更的DDL操作,否则数据迁移任务会失败。

    • 若仅执行全量数据迁移,请勿向源实例中写入新的数据,否则会导致源和目标数据不一致。为实时保持数据一致性,建议选择结构迁移、全量数据迁移和增量数据迁移。

  • 在迁移实例运行期间,不记录Binlog的变更操作所产生的数据(例如通过物理备份功能恢复、级联操作等产生的数据),不会被迁移到目标库。

    说明

    若有该情况,您可以在业务允许的前提下,重新迁移全量数据。

  • 若源库为8.0.23及以后版本的MySQL数据库,且待迁移的数据中包含不可见的隐藏列,则可能会因为无法获取该列的数据而导致数据丢失。

    说明
    • 您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令,将该隐藏列设置为可见。更多信息,请参见Invisible Columns

    • 无主键的表会自动生成不可见的隐藏主键,您也需要将该隐藏主键设置为可见。更多信息,请参见Generated Invisible Primary Keys

其他限制

  • 建议源和目标库的MySQL版本保持一致,以保障兼容性。

  • 若目标库为8.0.23及以后版本的MySQL数据库,且接收数据的列中包含不可见的隐藏列,则可能会因为无法找到写入数据的目标列,导致DTS实例运行失败或数据丢失。

    说明
    • 您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令,将该隐藏列设置为可见。更多信息,请参见Invisible Columns

    • 无主键的表会自动生成不可见的隐藏主键,您也需要将该隐藏主键设置为可见。更多信息,请参见Generated Invisible Primary Keys

  • 若您迁移数据时未使用DTS提供的库表结构迁移,则需要自行确保字段的兼容性,否则可能会导致实例失败或数据丢失。例如,当源表的字段为text类型,而接收数据的目标字段的类型为varchar(255)时,若源表中存在大字段,则可能会导致数据截断。

  • 若待迁移的数据中包含需要四字节存储的内容(例如生僻字、表情等信息),则目标端接收数据的数据库和表必须使用utf8mb4字符集。

    说明

    若您使用DTS迁移库表结构,则需将目标库中实例级别的参数character_set_server设置为utf8mb4。

  • 执行数据迁移前需评估源库和目标库的性能,同时建议业务低峰期执行数据迁移。否则全量数据迁移时DTS占用源和目标库一定读写资源,可能会导致数据库的负载上升。

  • 由于全量数据迁移会并发执行INSERT操作,导致目标数据库的表产生碎片,因此全量迁移完成后目标数据库的表存储空间会比源实例的表存储空间大。

  • 请确认DTS对数据类型为FLOAT或DOUBLE的列的迁移精度是否符合业务预期。DTS会通过ROUND(COLUMN,PRECISION)来读取这两类列的值。如果没有明确定义其精度,DTS对FLOAT的迁移精度为38位,对DOUBLE的迁移精度为308位。

  • DTS会尝试恢复七天之内迁移失败任务。因此业务切换至目标实例前,请务必结束或释放该任务,或者将DTS访问目标实例账号的写权限用revoke命令回收掉。避免该任务被自动恢复后,源端数据覆盖目标实例的数据。

  • 若目标库的DDL写入失败,DTS任务会继续运行,您需要在任务日志中查看执行失败的DDL。查看任务日志的方法,请参见查询任务日志

  • 若您将列名仅大小写不同的字段写入到目标MySQL数据库的同一个表中,可能会因为MySQL数据库列名大小写不敏感,导致迁移结果不符合预期。

  • 在数据迁移完成后,建议使用analyze table <表名>命令以确认数据均已写入目标表。例如,在MySQL触发HA切换机制后,可能会导致数据只写到了内存,从而造成数据丢失。

  • 若RDS MySQL实例已开通全密态(EncDB)功能,则不支持全量数据迁移。

  • 若您需要迁移源库中的账号,则还需满足相应的前提条件,并了解相关注意事项。更多信息,请参见迁移数据库账号

  • 若实例运行失败,DTS技术支持人员将在8小时内尝试恢复该实例。在恢复失败实例的过程中,可能会对该实例进行重启、调整参数等操作。

    说明

    在调整参数时,仅会修改实例的参数,不会对数据库中的参数进行修改。可能修改的参数,包括但不限于修改实例参数中的参数。

特殊情况

  • 当源库为自建MySQL时:

    • 迁移时源库进行主备切换,会导致迁移任务失败。

    • 由于DTS的延迟时间是根据迁移到目标库最后一条数据的时间戳和当前时间戳对比得出,源库长时间未执行DML操作可能导致延迟信息不准确。如果任务显示的延迟时间过大,您可以在源库执行一个DML操作来更新延迟信息。

      说明

      如果迁移对象选择为整库,您还可以创建心跳表,心跳表每秒定期更新或者写入数据。

    • DTS会在源库定时执CREATE DATABASE IF NOT EXISTS `test`命令以推进Binlog位点。

  • 当源库为RDS MySQL时:

    • 若您需要迁移增量数据,则不记录事务日志的RDS MySQL实例(如RDS MySQL 5.6版本的只读实例)不支持作为源库。

    • DTS会在源库定时执CREATE DATABASE IF NOT EXISTS `test`命令以推进Binlog位点。

  • 当目标库为RDS MySQL时:

    DTS会自动在RDS MySQL中创建数据库,如果待迁移的数据库名称不符合RDS MySQL的定义规范,您需要在配置迁移任务之前在RDS MySQL中创建数据库。相关操作,请参见管理数据库

MySQL迁移至PolarDB MySQL版

如果迁移的目标库为PolarDB MySQL版,具体注意事项及限制如下:

类型

说明

源库限制

  • 带宽要求:源库所属的服务器需具备足够出口带宽,否则将影响数据迁移速率。

  • 待迁移的表需具备主键或唯一约束,且字段具有唯一性,否则可能会导致目标数据库中出现重复数据。

  • 如迁移对象为表级别,且需进行编辑(如表列名映射),则单次迁移任务仅支持迁移至多1000张表。当超出数量限制,任务提交后会显示请求报错,此时建议您拆分待迁移的表,分批配置多个任务,或者配置整库的迁移任务。

  • 如需进行增量迁移,Binlog日志:

    • 需开启,并且binlog_format为row、binlog_row_image为full。否则预检查阶段提示报错,且无法成功启动数据迁移任务。

      重要

      如源实例自建MySQL是双主集群(两者互为主从),为保障DTS能获取全部的Binlog日志,则您需开启参数log_slave_updates。

    • DTS要求源数据库的本地Binlog日志至少保留7天以上,否则DTS可能因无法获取Binlog而导致任务失败,极端情况下甚至可能会导致数据不一致或丢失。由于您所设置的Binlog日志保存时间低于DTS要求的时间进而导致的问题,不在DTS的SLA保障范围内。

  • 源库的操作限制:

    • 在库表结构迁移和全量迁移阶段,请勿执行库或表结构变更的DDL操作,否则数据迁移任务会失败。

    • 若仅执行全量数据迁移,请勿向源实例中写入新的数据,否则会导致源和目标数据不一致。为实时保持数据一致性,建议选择结构迁移、全量数据迁移和增量数据迁移。

  • 在迁移实例运行期间,不记录Binlog的变更操作所产生的数据(例如通过物理备份功能恢复、级联操作等产生的数据),不会被迁移到目标库。

    说明

    若有该情况,您可以在业务允许的前提下,重新迁移全量数据。

  • 若源库为8.0.23及以后版本的MySQL数据库,且待迁移的数据中包含不可见的隐藏列,则可能会因为无法获取该列的数据而导致数据丢失。

    说明
    • 您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令,将该隐藏列设置为可见。更多信息,请参见Invisible Columns

    • 无主键的表会自动生成不可见的隐藏主键,您也需要将该隐藏主键设置为可见。更多信息,请参见Generated Invisible Primary Keys

其他限制

  • 建议源和目标库的MySQL版本保持一致,以保障兼容性。

  • 执行数据迁移前需评估源库和目标库的性能,同时建议业务低峰期执行数据迁移。否则全量数据迁移时DTS占用源和目标库一定读写资源,可能会导致数据库的负载上升。

  • 由于全量数据迁移会并发执行INSERT操作,导致目标数据库的表产生碎片,因此全量迁移完成后目标数据库的表存储空间会比源实例的表存储空间大。

  • 若待迁移的数据中包含需要四字节存储的内容(例如生僻字、表情等信息),则目标端接收数据的数据库和表必须使用utf8mb4字符集。

    说明

    若您使用DTS迁移库表结构,则需将目标库中实例级别的参数character_set_server设置为utf8mb4。

  • 请确认DTS对数据类型为FLOAT或DOUBLE的列的迁移精度是否符合业务预期。DTS会通过ROUND(COLUMN,PRECISION)来读取这两类列的值。如果没有明确定义其精度,DTS对FLOAT的迁移精度为38位,对DOUBLE的迁移精度为308位。

  • DTS会尝试恢复七天之内迁移失败任务。因此业务切换至目标实例前,请务必结束或释放该任务,或者将DTS访问目标实例账号的写权限用revoke命令回收掉。避免该任务被自动恢复后,源端数据覆盖目标实例的数据。

  • 不支持将datetime类型的数据转为varchar。

  • 若目标库的DDL写入失败,DTS任务会继续运行,您需要在任务日志中查看执行失败的DDL。查看任务日志的方法,请参见查询任务日志

  • 若RDS MySQL实例已开通全密态(EncDB)功能,则不支持全量数据迁移。

  • 若您需要迁移源库中的账号,则还需满足相应的前提条件,并了解相关注意事项。更多信息,请参见迁移数据库账号

  • 若实例运行失败,DTS技术支持人员将在8小时内尝试恢复该实例。在恢复失败实例的过程中,可能会对该实例进行重启、调整参数等操作。

    说明

    在调整参数时,仅会修改实例的参数,不会对数据库中的参数进行修改。可能修改的参数,包括但不限于修改实例参数中的参数。

特殊情况

  • 当源库为自建MySQL时:

    • 迁移时源库进行主备切换,会导致迁移任务失败。

    • 由于DTS的延迟时间是根据迁移到目标库最后一条数据的时间戳和当前时间戳对比得出,源库长时间未执行DML操作可能导致延迟信息不准确。如果任务显示的延迟时间过大,您可以在源库执行一个DML操作来更新延迟信息。

      说明

      如果迁移对象选择为整库,您还可以创建心跳表,心跳表每秒定期更新或者写入数据。

    • DTS会在源库定时执CREATE DATABASE IF NOT EXISTS `test`命令以推进Binlog位点。

  • 当源库为RDS MySQL时:

    • 若您需要迁移增量数据,则不记录事务日志的RDS MySQL实例(如RDS MySQL 5.6版本的只读实例)不支持作为源库。

    • DTS会在源库定时执CREATE DATABASE IF NOT EXISTS `test`命令以推进Binlog位点。

  • 当目标库为PolarDB MySQL版时:

    • DTS会自动在PolarDB MySQL版中创建数据库,如果待迁移的数据库名称不符合PolarDB MySQL版的定义规范,您需要在配置迁移任务之前在PolarDB MySQL版中创建数据库。相关操作,请参见管理数据库

    • 暂不支持调整全量迁移速率。

MySQL迁移至PolarDB-X 2.0

具体注意事项及限制如下:

类型

说明

源库限制

  • 带宽要求:源库所属的服务器需具备足够出口带宽,否则将影响数据迁移速率。

  • 待迁移的表需具备主键或唯一约束,且字段具有唯一性,否则可能会导致目标数据库中出现重复数据。

  • 如迁移对象为表级别,且需进行编辑(如表列名映射),则单次迁移任务仅支持迁移至多1000张表。当超出数量限制,任务提交后会显示请求报错,此时建议您拆分待迁移的表,分批配置多个任务,或者配置整库的迁移任务。

  • 如需进行增量迁移,Binlog日志:

    • 需开启,并且binlog_format为row、binlog_row_image为full。否则预检查阶段提示报错,且无法成功启动数据迁移任务。

      重要

      如源实例自建MySQL是双主集群(两者互为主从),为保障DTS能获取全部的Binlog日志,则您需开启参数log_slave_updates。

    • DTS要求源数据库的本地Binlog日志至少保留7天以上,否则DTS可能因无法获取Binlog而导致任务失败,极端情况下甚至可能会导致数据不一致或丢失。由于您所设置的Binlog日志保存时间低于DTS要求的时间进而导致的问题,不在DTS的SLA保障范围内。

  • 源库的操作限制:

    • 在全量迁移阶段,请勿执行库或表结构变更的DDL操作,否则数据迁移任务会失败。

    • 如仅执行全量数据迁移,请勿向源实例中写入新的数据,否则会导致源和目标数据不一致。为实时保持数据一致性,建议选择全量数据迁移和增量数据迁移。

  • 在迁移实例运行期间,不记录Binlog的变更操作所产生的数据(例如通过物理备份功能恢复、级联操作等产生的数据),不会被迁移到目标库。

    说明

    若有该情况,您可以在业务允许的前提下,重新迁移全量数据。

  • 若源库为8.0.23及以后版本的MySQL数据库,且待迁移的数据中包含不可见的隐藏列,则可能会因为无法获取该列的数据而导致数据丢失。

    说明
    • 您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令,将该隐藏列设置为可见。更多信息,请参见Invisible Columns

    • 无主键的表会自动生成不可见的隐藏主键,您也需要将该隐藏主键设置为可见。更多信息,请参见Generated Invisible Primary Keys

其他限制

  • 执行数据迁移前需评估源库和目标库的性能,同时建议业务低峰期执行数据迁移。否则全量数据迁移时DTS占用源和目标库一定读写资源,可能会导致数据库的负载上升。

  • 由于全量数据迁移会并发执行INSERT操作,导致目标数据库的表产生碎片,因此全量迁移完成后目标数据库的表存储空间会比源实例的表存储空间大。

  • 请确认DTS对数据类型为FLOAT或DOUBLE的列的迁移精度是否符合业务预期。DTS会通过ROUND(COLUMN,PRECISION)来读取这两类列的值。如果没有明确定义其精度,DTS对FLOAT的迁移精度为38位,对DOUBLE的迁移精度为308位。

  • DTS会尝试恢复七天之内迁移失败任务。因此业务切换至目标实例前,请务必结束或释放该任务,或者将DTS访问目标实例账号的写权限用revoke命令回收掉。避免该任务被自动恢复后,源端数据覆盖目标实例的数据。

  • 若RDS MySQL实例已开通全密态(EncDB)功能,则不支持全量数据迁移。

  • 若实例运行失败,DTS技术支持人员将在8小时内尝试恢复该实例。在恢复失败实例的过程中,可能会对该实例进行重启、调整参数等操作。

    说明

    在调整参数时,仅会修改实例的参数,不会对数据库中的参数进行修改。可能修改的参数,包括但不限于修改实例参数中的参数。

特殊情况

  • 当源库为自建MySQL时:

    • 迁移时源库进行主备切换,会导致迁移任务失败。

    • 由于DTS的延迟时间是根据迁移到目标库最后一条数据的时间戳和当前时间戳对比得出,源库长时间未执行DML操作可能导致延迟信息不准确。如果任务显示的延迟时间过大,您可以在源库执行一个DML操作来更新延迟信息。

      说明

      如果迁移对象选择为整库,您还可以创建心跳表,心跳表每秒定期更新或者写入数据。

    • DTS会在源库定时执CREATE DATABASE IF NOT EXISTS `test`命令以推进Binlog位点。

  • 当源库为RDS MySQL时:

    • 若您需要迁移增量数据,则不记录事务日志的RDS MySQL实例(如RDS MySQL 5.6版本的只读实例)不支持作为源库。

    • DTS会在源库定时执CREATE DATABASE IF NOT EXISTS `test`命令以推进Binlog位点。

MySQL迁移至云原生数据仓库AnalyticDB MySQL版 3.0

具体注意事项及限制如下:

类型

说明

源库限制

  • 带宽要求:源库所属的服务器需具备足够出口带宽,否则将影响数据迁移速率。

  • 待迁移的表需具备主键或唯一约束,且字段具有唯一性,否则可能会导致目标数据库中出现重复数据。

  • 如迁移对象为表级别,且需进行编辑(如表列名映射),则单次迁移任务仅支持迁移至多1000张表。当超出数量限制,任务提交后会显示请求报错,此时建议您拆分待迁移的表,分批配置多个任务,或者配置整库的迁移任务。

  • 如需进行增量迁移,Binlog日志:

    • 需开启,并且binlog_format为row、binlog_row_image为full。否则预检查阶段提示报错,且无法成功启动数据迁移任务。

      重要

      如源实例自建MySQL是双主集群(两者互为主从),为保障DTS能获取全部的Binlog日志,则您需开启参数log_slave_updates。

    • DTS要求源数据库的本地Binlog日志至少保留7天以上,否则DTS可能因无法获取Binlog而导致任务失败,极端情况下甚至可能会导致数据不一致或丢失。由于您所设置的Binlog日志保存时间低于DTS要求的时间进而导致的问题,不在DTS的SLA保障范围内。

  • 源库的操作限制:

    • 在库表结构迁移和全量迁移阶段,请勿执行库或表结构变更的DDL操作,否则数据迁移任务会失败。

    • 迁移期间,请勿执行添加注释的DDL操作(如ALTER TABLE table_name COMMENT='表的注释';),否则数据迁移任务会失败。

    • 若仅执行全量数据迁移,请勿向源实例中写入新的数据,否则会导致源和目标数据不一致。为实时保持数据一致性,建议选择结构迁移、全量数据迁移和增量数据迁移。

  • 在迁移实例运行期间,不记录Binlog的变更操作所产生的数据(例如通过物理备份功能恢复、级联操作等产生的数据),不会被迁移到目标库。

    说明

    若有该情况,您可以在业务允许的前提下,重新迁移全量数据。

  • 若源库为8.0.23及以后版本的MySQL数据库,且待迁移的数据中包含不可见的隐藏列,则可能会因为无法获取该列的数据而导致数据丢失。

    说明
    • 您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令,将该隐藏列设置为可见。更多信息,请参见Invisible Columns

    • 无主键的表会自动生成不可见的隐藏主键,您也需要将该隐藏主键设置为可见。更多信息,请参见Generated Invisible Primary Keys

其他限制

  • 暂不支持迁移前缀索引,如果源库存在前缀索引可能导致数据迁移失败。

  • 由于云原生数据仓库AnalyticDB MySQL版 3.0本身的使用限制,当云原生数据仓库AnalyticDB MySQL版 3.0中的节点磁盘空间使用量超过80%,会导致DTS任务异常,产生延迟。请提前根据待迁移的对象预估所需空间,确保目标集群具备充足的存储空间。

  • 若DTS任务运行时目标AnalyticDB MySQL版 3.0集群处于备份中的状态,则会导致任务失败。

  • 执行数据迁移前需评估源库和目标库的性能,同时建议业务低峰期执行数据迁移。否则全量数据迁移时DTS占用源和目标库一定读写资源,可能会导致数据库的负载上升。

  • 由于全量数据迁移会并发执行INSERT操作,导致目标数据库的表产生碎片,因此全量迁移完成后目标数据库的表存储空间会比源实例的表存储空间大。

  • 请确认DTS对数据类型为FLOAT或DOUBLE的列的迁移精度是否符合业务预期。DTS会通过ROUND(COLUMN,PRECISION)来读取这两类列的值。如果没有明确定义其精度,DTS对FLOAT的迁移精度为38位,对DOUBLE的迁移精度为308位。

  • DTS会尝试恢复七天之内迁移失败任务。因此业务切换至目标实例前,请务必结束或释放该任务,或者将DTS访问目标实例账号的写权限用revoke命令回收掉。避免该任务被自动恢复后,源端数据覆盖目标实例的数据。

  • 若目标库的DDL写入失败,DTS任务会继续运行,您需要在任务日志中查看执行失败的DDL。查看任务日志的方法,请参见查询任务日志

  • 若RDS MySQL实例已开通全密态(EncDB)功能,则不支持全量数据迁移。

  • 若实例运行失败,DTS技术支持人员将在8小时内尝试恢复该实例。在恢复失败实例的过程中,可能会对该实例进行重启、调整参数等操作。

    说明

    在调整参数时,仅会修改实例的参数,不会对数据库中的参数进行修改。可能修改的参数,包括但不限于修改实例参数中的参数。

特殊情况

  • 当源库为自建MySQL时:

    • 迁移时源库进行主备切换,会导致迁移任务失败。

    • 由于DTS的延迟时间是根据迁移到目标库最后一条数据的时间戳和当前时间戳对比得出,源库长时间未执行DML操作可能导致延迟信息不准确。如果任务显示的延迟时间过大,您可以在源库执行一个DML操作来更新延迟信息。

      说明

      如果迁移对象选择为整库,您还可以创建心跳表,心跳表每秒定期更新或者写入数据。

    • DTS会在源库定时执CREATE DATABASE IF NOT EXISTS `test`命令以推进Binlog位点。

  • 当源库为RDS MySQL时:

    • 若您需要迁移增量数据,则不记录事务日志的RDS MySQL实例(如RDS MySQL 5.6版本的只读实例)不支持作为源库。

    • DTS会在源库定时执CREATE DATABASE IF NOT EXISTS `test`命令以推进Binlog位点。

MySQL迁移至自建Kafka

具体注意事项及限制如下:

类型

说明

源库限制

  • 带宽要求:源库所属的服务器需具备足够出口带宽,否则将影响数据迁移速率。

  • 待迁移的表需具备主键或唯一约束,且字段具有唯一性,否则可能会导致目标数据库中出现重复数据。

  • 如迁移对象为表级别,且需进行编辑(如表列名映射),则单次迁移任务仅支持迁移至多1000张表。当超出数量限制,任务提交后会显示请求报错,此时建议您拆分待迁移的表,分批配置多个任务,或者配置整库的迁移任务。

  • 如需进行增量迁移,Binlog日志:

    • 在云数据库RDS控制台参数设置界面开启Binglog,开启方法请参见设置实例参数。并且binlog_format为row、binlog_row_image为full。否则预检查阶段提示报错,且无法成功启动数据迁移任务。

      重要

      如源实例自建MySQL是双主集群(两者互为主从),为保障DTS能获取全部的Binlog日志,则您需开启参数log_slave_updates,具体操作请参见为自建MySQL创建账号并设置binlog

    • DTS要求源数据库的本地Binlog日志至少保留7天以上,否则DTS可能因无法获取Binlog而导致任务失败,极端情况下甚至可能会导致数据不一致或丢失。由于您所设置的Binlog日志保存时间低于DTS要求的时间进而导致的问题,不在DTS的SLA保障范围内。如源为RDS MySQL,具体操作请参见管理本地日志(Binlog)

  • 源库的操作限制:

    • 在库表结构迁移和全量迁移阶段,请勿执行库或表结构变更的DDL操作,否则数据迁移任务会失败。

    • 如仅执行全量数据迁移,请勿向源实例中写入新的数据,否则会导致源和目标数据不一致。为实时保持数据一致性,建议选择结构迁移、全量数据迁移和增量数据迁移。

  • 在迁移实例运行期间,不记录Binlog的变更操作所产生的数据(例如通过物理备份功能恢复、级联操作等产生的数据),不会被迁移到目标库。

    说明

    若有该情况,您可以在业务允许的前提下,重新迁移全量数据。

  • 若源库为8.0.23及以后版本的MySQL数据库,且待迁移的数据中包含不可见的隐藏列,则可能会因为无法获取该列的数据而导致数据丢失。

    说明
    • 您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令,将该隐藏列设置为可见。更多信息,请参见Invisible Columns

    • 无主键的表会自动生成不可见的隐藏主键,您也需要将该隐藏主键设置为可见。更多信息,请参见Generated Invisible Primary Keys

其他限制

  • 已完成Kafka集群的搭建,且Kafka的版本为0.10.1.0~2.0版本。

  • 迁移对象仅支持数据表。

  • 执行数据迁移前需评估源库和目标库的性能,同时建议业务低峰期执行数据迁移。否则全量数据迁移时DTS占用源和目标库一定读写资源,可能会导致数据库的负载上升。

  • 由于全量数据迁移会并发执行INSERT操作,导致目标数据库的表产生碎片,因此全量迁移完成后目标数据库的表存储空间会比源实例的表存储空间大。

  • 请确认DTS对数据类型为FLOAT或DOUBLE的列的迁移精度是否符合业务预期。DTS会通过ROUND(COLUMN,PRECISION)来读取这两类列的值。如果没有明确定义其精度,DTS对FLOAT的迁移精度为38位,对DOUBLE的迁移精度为308位。

  • DTS会尝试恢复七天之内迁移失败任务。因此业务切换至目标实例前,请务必结束或释放该任务,或者将DTS访问目标实例账号的写权限用revoke命令回收掉。避免该任务被自动恢复后,源端数据覆盖目标实例的数据。

  • 不允许目标库有除DTS以外的数据写入,否则会导致源和目标库数据不一致。

  • 在迁移期间,若目标Kafka发生了扩容或缩容,您需要重启实例。

  • 若RDS MySQL实例已开通全密态(EncDB)功能,则不支持全量数据迁移。

  • 若实例运行失败,DTS技术支持人员将在8小时内尝试恢复该实例。在恢复失败实例的过程中,可能会对该实例进行重启、调整参数等操作。

    说明

    在调整参数时,仅会修改实例的参数,不会对数据库中的参数进行修改。可能修改的参数,包括但不限于修改实例参数中的参数。

特殊情况

  • 当源库为自建MySQL时:

    • 迁移时源库进行主备切换,会导致迁移任务失败。

    • 由于DTS的延迟时间是根据迁移到目标库最后一条数据的时间戳和当前时间戳对比得出,源库长时间未执行DML操作可能导致延迟信息不准确。如果任务显示的延迟时间过大,您可以在源库执行一个DML操作来更新延迟信息。

      说明

      如果迁移对象选择为整库,您还可以创建心跳表,心跳表每秒定期更新或者写入数据。

    • DTS会在源库定时执CREATE DATABASE IF NOT EXISTS `test`命令以推进Binlog位点。

  • 当源库为RDS MySQL时:

    • 若您需要迁移增量数据,则不记录事务日志的RDS MySQL实例(如RDS MySQL 5.6版本的只读实例)不支持作为源库。

    • DTS会在源库定时执CREATE DATABASE IF NOT EXISTS `test`命令以推进Binlog位点。

MySQL迁移至DataHub

具体注意事项及限制如下:

类型

说明

源库限制

  • 带宽要求:源库所属的服务器需具备足够出口带宽,否则将影响数据迁移速率。

  • 待迁移的表需具备主键或唯一约束,且字段具有唯一性,否则可能会导致目标数据库中出现重复数据。

  • 如迁移对象为表级别,且需进行编辑(如表列名映射),则单次迁移任务仅支持迁移至多1000张表。当超出数量限制,任务提交后会显示请求报错,此时建议您拆分待迁移的表,分批配置多个任务,或者配置整库的迁移任务。

  • 如需进行增量迁移,Binlog日志:

    • 在云数据库RDS控制台参数设置界面开启Binglog,开启方法请参见设置实例参数。并且binlog_format为row、binlog_row_image为full。否则预检查阶段提示报错,且无法成功启动数据迁移任务。

      重要

      如源实例自建MySQL是双主集群(两者互为主从),为保障DTS能获取全部的Binlog日志,则您需开启参数log_slave_updates,具体操作请参见为自建MySQL创建账号并设置binlog

    • DTS要求源数据库的本地Binlog日志至少保留7天以上,否则DTS可能因无法获取Binlog而导致任务失败,极端情况下甚至可能会导致数据不一致或丢失。由于您所设置的Binlog日志保存时间低于DTS要求的时间进而导致的问题,不在DTS的SLA保障范围内。如源为RDS MySQL,具体操作请参见管理本地日志(Binlog)

  • 源库的操作限制:在库表结构迁移阶段,请勿执行库或表结构变更的DDL操作,否则数据迁移任务会失败。

  • 在迁移实例运行期间,不记录Binlog的变更操作所产生的数据(例如通过物理备份功能恢复、级联操作等产生的数据),不会被迁移到目标库。

    说明

    若有该情况,您可以在业务允许的前提下,重新迁移全量数据。

  • 若源库为8.0.23及以后版本的MySQL数据库,且待迁移的数据中包含不可见的隐藏列,则可能会因为无法获取该列的数据而导致数据丢失。

    说明
    • 您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令,将该隐藏列设置为可见。更多信息,请参见Invisible Columns

    • 无主键的表会自动生成不可见的隐藏主键,您也需要将该隐藏主键设置为可见。更多信息,请参见Generated Invisible Primary Keys

其他限制

  • 仅支持表级迁移。

  • 目标DataHub中单个String字段的长度最大支持2 MB。

  • 请勿对源库的迁移对象使用pt-online-schema-change等类似工具执行在线DDL变更,否则会导致迁移失败。

  • 您可以使用数据管理DMS(Data Management)来执行在线DDL变更,请参见不锁表结构变更

    警告

    如果有除DTS外的数据写入目标库,请勿使用DMS执行在线DDL变更,否则可能引起目标库数据丢失。

  • 请确认DTS对数据类型为FLOAT或DOUBLE的列的迁移精度是否符合业务预期。DTS会通过ROUND(COLUMN,PRECISION)来读取这两类列的值。如果没有明确定义其精度,DTS对FLOAT的迁移精度为38位,对DOUBLE的迁移精度为308位。

  • DTS会尝试恢复七天之内迁移失败任务。因此业务切换至目标实例前,请务必结束或释放该任务,或者将DTS访问目标实例账号的写权限用revoke命令回收掉。避免该任务被自动恢复后,源端数据覆盖目标实例的数据。

  • 若RDS MySQL实例已开通全密态(EncDB)功能,则不支持全量数据迁移。

  • 若实例运行失败,DTS技术支持人员将在8小时内尝试恢复该实例。在恢复失败实例的过程中,可能会对该实例进行重启、调整参数等操作。

    说明

    在调整参数时,仅会修改实例的参数,不会对数据库中的参数进行修改。可能修改的参数,包括但不限于修改实例参数中的参数。

特殊情况

  • 当源库为自建MySQL时:

    • 迁移时源库进行主备切换,会导致迁移任务失败。

    • 由于DTS的延迟时间是根据迁移到目标库最后一条数据的时间戳和当前时间戳对比得出,源库长时间未执行DML操作可能导致延迟信息不准确。如果任务显示的延迟时间过大,您可以在源库执行一个DML操作来更新延迟信息。

      说明

      如果迁移对象选择为整库,您还可以创建心跳表,心跳表每秒定期更新或者写入数据。

    • DTS会在源库定时执CREATE DATABASE IF NOT EXISTS `test`命令以推进Binlog位点。

  • 当源库为RDS MySQL时:

    • 若您需要迁移增量数据,则不记录事务日志的RDS MySQL实例(如RDS MySQL 5.6版本的只读实例)不支持作为源库。

    • DTS会在源库定时执CREATE DATABASE IF NOT EXISTS `test`命令以推进Binlog位点。