把MySQL迁移到达梦如果只是迁移一批静态数据可以停机后导出再导入。但在生产环境中MySQL通常还在持续产生订单、用户、库存等业务数据几百GB甚至更大的数据库也很难在短时间内完成迁移。更稳妥的方法是先迁移表结构和历史数据再通过MySQL Binlog持续同步INSERT、UPDATE、DELETE等增量变更。等达梦中的数据追平MySQL并通过校验后只需要在最后切换阶段暂停写入一小段时间。这套方案可以概括为迁移评估 → 结构迁移 → 全量初始化 → Binlog增量同步 → 数据校验 → 应用切换本文以CloudCanal为例介绍MySQL迁移到达梦的准备工作、配置过程、常见兼容性问题和低停机切换步骤。如果已经完成前期评估只想看工具配置可以直接跳到“使用CloudCanal迁移MySQL到达梦”一节。MySQL迁移到达梦具体要迁移什么一次完整的数据库迁移通常包含四部分。1. 表结构包括表、字段、主键、索引、默认值和字段注释等。MySQL和达梦的SQL语法、字段类型及数据库对象并不完全相同不能简单地把MySQL的SHOW CREATE TABLE结果直接拿到达梦执行。2. 历史数据也就是迁移开始前已经存在于MySQL中的数据。这部分通常通过全量扫描读取再分批写入达梦。3. 增量数据全量迁移可能需要运行数小时甚至数天。在此期间MySQL仍然会产生新的INSERT、UPDATE和DELETE操作。这些变化需要通过Binlog捕获并继续写入达梦否则全量迁移结束时两边的数据仍然不一致。4. 应用兼容性应用中的SQL、数据库驱动、分页语法、函数、存储过程和大小写规则也可能需要修改。数据迁移工具可以帮助迁移表结构和数据但不能默认解决所有应用兼容问题。尤其是存储过程、触发器、复杂函数和MySQL特有SQL需要单独梳理和测试。迁移前先检查MySQL正式创建迁移任务前先确认MySQL的版本、数据规模、Binlog配置、表结构和账号权限。检查MySQL版本和字符集SELECTVERSION();SHOWVARIABLESLIKEcharacter_set_server;SHOWVARIABLESLIKEcollation_server;这条链路支持的MySQL字符集包括utf8、utf8mb4和latin1。如果源库使用其他字符集不能直接假设兼容应先用包含中文、特殊符号和Emoji的数据进行测试。统计库表和数据规模SELECTtable_schema,COUNT(*)AStable_count,ROUND(SUM(data_lengthindex_length)/1024/1024/1024,2)AStotal_size_gbFROMinformation_schema.tablesWHEREtable_schemaNOTIN(information_schema,mysql,performance_schema,sys)GROUPBYtable_schemaORDERBYtotal_size_gbDESC;继续找出数据量较大的表SELECTtable_schema,table_name,table_rows,ROUND((data_lengthindex_length)/1024/1024,2)AStotal_size_mbFROMinformation_schema.tablesWHEREtable_schemayour_databaseORDERBYdata_lengthindex_lengthDESCLIMIT20;这些数据可以用来估算迁移时间也方便把超大表拆成单独任务避免少数大表拖慢整个迁移过程。需要注意InnoDB的table_rows通常是估算值不能作为最终数据校验结果。找出没有主键的表SELECTt.table_schema,t.table_nameFROMinformation_schema.tablestLEFTJOINinformation_schema.table_constraints cONt.table_schemac.table_schemaANDt.table_namec.table_nameANDc.constraint_typePRIMARY KEYWHEREt.table_schemayour_databaseANDt.table_typeBASE TABLEANDc.constraint_nameISNULL;无主键表是增量同步中需要重点处理的对象。CloudCanal的MySQL到达梦链路支持常见DML同步。其中无主键表的UPDATE和DELETE默认不同步需要在创建任务时手动勾选相关选项。即使工具允许同步也建议先评估无主键表的数据量和更新频率。因为缺少唯一标识时目标端定位记录的成本和不确定性都会增加。能够补充合理主键的表最好在正式迁移前完成整改。检查特殊字段和零值时间SELECTtable_schema,table_name,column_name,data_type,column_typeFROMinformation_schema.columnsWHEREtable_schemayour_databaseANDdata_typeIN(tinyint,bit,enum,set,json,blob,mediumblob,longblob,text,mediumtext,longtext,datetime,timestamp)ORDERBYtable_name,ordinal_position;重点检查以下内容TINYINT(1)是否被应用当作布尔值ENUM和SET如何映射JSON字段迁移后是否仍需要JSON查询能力BLOB、TEXT和其他大字段的数据量DATETIME、TIMESTAMP是否涉及不同时区是否存在0000-00-00或0000-00-00 00:00:00等零值时间。MySQL历史系统中比较容易出现零值时间但目标数据库未必能直接接受。CloudCanal的MySQL到达梦链路提供零值时间处理可以在迁移时将其转换为指定值避免目标端写入失败。不过转换规则不能随便设置。零值究竟代表“未知”“未初始化”还是历史脏数据应由业务方确认后再决定转换成NULL、特定日期或其他值。为增量同步准备MySQL BinlogCloudCanal通过MySQL Binlog读取增量变更。使用MySQL到达梦链路时MySQL需要开启Binlog并使用ROW格式和完整行镜像。可以先检查当前配置SHOWVARIABLESLIKElog_bin;SHOWVARIABLESLIKEbinlog_format;SHOWVARIABLESLIKEbinlog_row_image;SHOWVARIABLESLIKEserver_id;期望看到类似结果log_bin ON binlog_format ROW binlog_row_image FULL如果未开启可以在MySQL配置文件中设置[mysqld] server-id1 log-binmysql-bin binlog-formatROW binlog-row-imageFULL修改配置后需要按照当前数据库环境的运维规范重启MySQL并重新检查参数是否生效。ROW格式记录每一行的实际变化更适合CDC读取。binlog_row_imageFULL表示UPDATE前后记录完整列值。MySQL官方文档说明FULL会记录行的完整前像和后像CloudCanal的MySQL到达梦链路也要求使用这一配置。参考MySQL Binlog官方说明、CloudCanal MySQL到达梦链路Binlog保留时间不能太短全量迁移期间产生的增量数据依赖Binlog。如果全量迁移还没完成对应的旧Binlog已经被MySQL清理任务就可能无法继续从原位点读取。因此Binlog保留时间至少要覆盖预计全量迁移时间异常处理时间安全余量例如预计全量迁移需要两天不应只保留一天的Binlog。最好先通过测试得到实际迁移速度再确定保留策略。迁移期间还要监控Binlog磁盘占用不能只延长保留时间却不检查磁盘空间。MySQL与达梦的结构差异怎么处理下面是一张常见的MySQL订单表CREATETABLEorders(idBIGINTNOTNULLAUTO_INCREMENT,order_noVARCHAR(64)NOTNULL,user_idBIGINTNOTNULL,amountDECIMAL(18,2)NOTNULLDEFAULT0,statusTINYINTNOTNULLDEFAULT0,extra_info JSON,remarkTEXT,created_atDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP,updated_atTIMESTAMPNOTNULLDEFAULTCURRENT_TIMESTAMPONUPDATECURRENT_TIMESTAMP,PRIMARYKEY(id),UNIQUEKEYuk_order_no(order_no))ENGINEInnoDBDEFAULTCHARSETutf8mb4COMMENT订单表;迁移到达梦时至少需要检查以下内容。自增主键MySQL使用AUTO_INCREMENT实现自增。迁移到达梦时需要根据目标表创建结果确认自增列或序列的处理方式。除了表结构本身还要检查历史数据写入后自增值是否已经推进到正确位置。否则应用切换后插入新记录可能与已有主键发生冲突。验证时不能只测试历史数据查询还要在达梦端新增一条记录确认新生成的主键大于当前最大值。TINYINT(1)和布尔值MySQL项目经常使用TINYINT(1)保存0和1。迁移前需要确认它在业务上究竟是普通数值还是布尔状态。不要仅根据字段类型批量转换。相同的TINYINT字段可能分别代表启用或禁用状态删除标记业务枚举小范围计数值。迁移后的目标字段类型应结合实际取值范围和应用代码判断。DATETIME、TIMESTAMP和时区MySQL中的DATETIME通常不包含时区转换语义TIMESTAMP则会受到会话时区影响。迁移时应确认SELECTglobal.time_zone,session.time_zone;同时核对CloudCanal任务中的源端时区设置以及达梦端写入后的实际值。跨时区部署时不能只比较页面显示时间最好直接查询源端和目标端的原始字段值。零值时间如果历史表存在以下数据0000-00-00 0000-00-00 00:00:00应在正式迁移前统计数量SELECTCOUNT(*)FROMyour_tableWHEREyour_datetime_column0000-00-00 00:00:00;然后与业务方确定转换规则。直接转换为当前时间会改变数据含义通常并不合适。JSON、ENUM和SET这些字段不能只检查“能否写入”还要检查迁移后的应用如何查询。例如MySQL应用可能使用JSON_EXTRACT(extra_info,$.source)即使JSON内容已经迁移到达梦原来的查询函数也未必可以直接使用。此类字段需要同时完成数据迁移测试和应用SQL适配。ON UPDATE CURRENT_TIMESTAMPMySQL可以通过updated_atTIMESTAMPDEFAULTCURRENT_TIMESTAMPONUPDATECURRENT_TIMESTAMP在更新记录时自动刷新时间。迁移到达梦后应确认目标表是否需要通过默认值、触发器或应用逻辑实现相同行为。仅把现有时间数据迁过去并不代表后续UPDATE还能自动更新时间。表名和字段名大小写MySQL表名是否区分大小写会受到操作系统和lower_case_table_names配置影响达梦的对象名处理规则又与MySQL不同。迁移前可以检查SHOWVARIABLESLIKElower_case_table_names;CloudCanal支持目标表名与源端保持一致、统一转大写、统一转小写或以_数字后缀截取。选择映射规则时要同时检查应用SQL是否固定使用小写表名ORM是否自动添加双引号达梦中的用户和Schema现有SQL是否混用了大小写。表名映射一旦确定应该在测试环境中用真实应用验证不要等正式切换后再处理大小写错误。使用CloudCanal迁移MySQL到达梦CloudCanal的MySQL到达梦链路支持结构迁移全量数据迁移INSERT、UPDATE、DELETE增量同步数据校验和订正修改订阅重置位点表名映射部分DDL同步数据过滤、自定义代码和虚拟列等处理能力。开始实操前先准备一个可用的CloudCanal环境。如果希望快速注册体验可以直接使用CloudCanal SaaS版本如果需要把同步链路部署在自有环境中可以参考Docker一键安装文档完成私有化部署。已经有CloudCanal控制台的读者可以直接进入下面的迁移配置步骤。以下是低停机迁移的基本操作流程。第一步添加MySQL数据源进入CloudCanal控制台选择“数据源管理 新增数据源”添加MySQL。配置时需要确认CloudCanal节点可以连接MySQL同步账号至少具备迁移表的SELECT权限以及增量同步所需的REPLICATION SLAVE和REPLICATION CLIENT权限Binlog已经开启binlog_format为ROWbinlog_row_image为FULL数据库时区配置正确Binlog保留时间覆盖迁移周期。不要直接使用MySQL的root账号完成生产迁移。应按照实际任务功能授予同步账号所需的最小权限。第二步添加达梦数据源继续添加达梦目标端填写网络地址、端口、账号和密码等连接信息。达梦账号需要具备目标表的查询和INSERT、UPDATE、DELETE权限如果同时启用结构迁移或DDL同步还需要CREATE TABLE、CREATE INDEX、COMMENT ON TABLE/COLUMN和ALTER TABLE等相应权限。还要确认CloudCanal迁移同步节点能够访问达梦的实际服务端口。不要只在本地客户端测试连通性因为真正执行迁移的是CloudCanal工作节点。第三步创建“增量同步全量初始化”任务进入“同步任务 创建任务”按向导创建任务源端选择MySQL目标端选择达梦任务类型选择增量同步并勾选全量初始化选择需要迁移的表并核对目标表名核对迁移字段、字段映射、目标字段类型和NULL属性在最终确认页检查全量、增量、结构迁移、DDL同步、数据校验、任务规格和表映射确认无误后创建任务。这种配置会在同一条任务中完成表结构准备、历史数据初始化和后续增量同步而不是先单独完成一次全量迁移再临时创建增量任务。迁移流程可以理解为MySQL中的历史数据通过全量迁移写入达梦迁移期间产生的INSERT、UPDATE和DELETE则通过Binlog持续同步。全量完成后任务继续消费积压的增量变更直到达梦追平MySQL。第四步启动任务并观察全量迁移任务启动后重点观察全量迁移进度每张表的迁移状态扫描和写入速度失败记录MySQL CPU、I/O和连接数达梦写入负载Binlog增量积压量同步延迟变化。如果一张超大表占用了大部分迁移时间可以考虑把大表与普通表拆分管理。提高并行度前应同时观察源库和目标库负载不能只追求任务页面上的速度。第五步观察增量同步全量完成后任务会继续将MySQL中的变更写入达梦。可以在MySQL测试表中分别执行INSERTINTOmigration_test(id,name)VALUES(10001,insert_test);UPDATEmigration_testSETnameupdate_testWHEREid10001;DELETEFROMmigration_testWHEREid10001;然后检查达梦中的结果确认INSERT、UPDATE和DELETE均能正常同步。生产验证不应直接修改核心业务表可以使用专门的测试表或者选择经过业务方确认的测试记录。DDL同步支持到什么程度MySQL到达梦迁移期间开发团队可能仍在修改表结构因此需要提前确认DDL同步范围。在MySQL到达梦链路中CloudCanal支持的DDL包括ALTER TABLE ADD COLUMNALTER TABLE MODIFY COLUMNALTER TABLE RENAME COLUMNALTER TABLE DROP COLUMNRENAME TABLECREATE TABLE其中创建表适用于全库同步场景这不等于所有MySQL DDL都能自动转换。以下操作在迁移窗口内应谨慎执行修改主键或唯一索引调整复杂分区修改字符集或排序规则变更ENUM、SET或特殊数据类型执行Online DDL工具生成的临时表切换创建或修改触发器、函数和存储过程。如果迁移期间必须发布数据库变更应建立变更登记机制提前在测试链路验证而不是默认所有DDL都会被自动同步。如何验证迁移后的数据只比较源端和目标端的总行数是不够的。例如两张表都包含100万行但其中一行的金额、状态或时间字段不同行数检查仍然会显示一致。建议至少进行三层验证。第一层对象和行数检查检查目标表是否全部创建主键和必要索引是否存在每张表的行数是否大致一致是否存在迁移失败或被跳过的表。这一步适合快速发现整表缺失但不能作为最终验收。第二层逐字段数据校验CloudCanal支持从MySQL和达梦分别读取数据进行逐字段比较也可以根据校验结果订正差异数据并支持定时校验。如果在创建迁移任务时已经选择数据校验可以在全量迁移完成、增量延迟追平后查看校验阶段的执行结果如果创建任务时没有开启也可以在同步任务详情页通过“功能列表 创建相似任务”选择“数据校验”或“数据校验和订正”单独发起一次校验任务。需要周期性复核时再配置定时校验。校验结果应结合diff_1st.log、diff.log等日志文件查看。前者更适合观察初次扫描发现的差异后者用于确认最终校验结果。具体操作可以参考数据校验与订正文档。应重点校验核心业务表大表高频更新表包含金额和状态的表包含JSON、BLOB、TEXT的表包含零值时间或特殊字符的表迁移期间发生过错误和重试的表。发现差异后不要立即批量覆盖。应先判断是增量尚未追平、字段转换规则不一致还是目标端被其他程序修改。第三层业务结果校验数据库字段一致之外还要验证实际业务结果例如-- 订单总量SELECTCOUNT(*)FROMorders;-- 各状态订单数量SELECTstatus,COUNT(*)FROMordersGROUPBYstatus;-- 指定日期范围的订单金额SELECTSUM(amount)FROMordersWHEREcreated_at2026-01-01 00:00:00ANDcreated_at2026-02-01 00:00:00;类似查询应分别在MySQL和达梦执行并比较结果。此外还要测试应用的新增、修改、删除、分页查询、批量操作、事务回滚和报表统计。数据迁移成功不代表应用SQL一定兼容。如何完成低停机切换当全量迁移完成、增量同步稳定并通过数据校验后可以进入正式切换阶段。建议按照以下顺序操作确认所有全量任务完成确认没有持续失败的记录确认Binlog同步延迟处于可接受范围对关键业务表执行一次完整校验通知业务进入短暂停写窗口停止定时任务、消息消费者和其他后台写入等待最后一批Binlog事件同步到达梦再次校验关键表及业务指标修改应用数据库连接在达梦上验证新增、更新、删除和查询观察应用错误日志、连接池和数据库负载确认稳定后结束切换窗口。旧MySQL不要在切换后立即下线。应按照项目要求保留一段观察期并限制非必要写入便于问题排查和回退。如果应用已经开始向达梦写入回退就不再只是把连接改回MySQL。还需要考虑切换后在达梦产生的数据如何返回MySQL。因此回退方案必须在正式切换前设计而不是发生故障后再临时讨论。常见问题与排查方法1. 全量迁移还没完成Binlog已经被清理原因通常是Binlog保留时间小于全量迁移时间。处理方法是重新确定一致性起点必要时重新执行全量初始化。迁移前应先测试迁移速度并为Binlog保留时间留出足够余量。2. 无主键表只能同步INSERTCloudCanal对无主键表的处理规则是UPDATE和DELETE需要手动勾选。正式迁移前应列出所有无主键表优先补充主键不能补充时再单独验证更新和删除效果。3. 日期字段写入失败常见原因包括MySQL零值时间、字段精度不同或源端和目标端时区不一致。先查询具体失败记录再判断应该进行零值转换、调整目标字段还是修改任务时区。不要直接把所有异常时间替换成当前时间。4. 达梦中出现主键冲突CloudCanal提供IGNORE和REPLACE两种增量冲突策略IGNORE遇到主键冲突时忽略本次写入REPLACE遇到冲突时整行替换目标记录。默认忽略虽然可以让任务继续运行但可能掩盖数据差异。选择策略前要先确认冲突来源例如目标端是否提前写入数据、全量和增量是否重复或者自增主键是否处理错误。5. 全量完成后增量延迟持续增加可以依次检查MySQL是否存在大事务或长事务Binlog解析速度是否成为瓶颈CloudCanal工作节点CPU和内存是否充足网络是否稳定达梦写入是否变慢目标表索引是否过多是否存在频繁重试的异常数据任务并发和批量写入参数是否合适。CloudCanal提供Binlog解析并发、解析缓冲区、单事务最大数据条数和增量流量限制等参数。生产环境中不要一次性大幅调高应结合监控逐步调整。6. 表名正确但应用查询时提示对象不存在通常与大小写、引号、目标Schema或应用默认Schema有关。检查CloudCanal的表名映射方式、达梦中的实际对象名以及ORM是否自动添加双引号。此类问题应在应用测试阶段解决不属于数据缺失。总结MySQL迁移到达梦不能只做一次全量导入。对于持续写入的生产系统更稳妥的方式是先迁移表结构和历史数据再通过Binlog同步增量变更完成数据校验后在短暂停写窗口内切换业务。CloudCanal支持MySQL到达梦的结构迁移、全量迁移、增量同步、数据校验和订正。正式迁移前建议先通过PoC验证数据库版本、特殊字段、同步性能和应用兼容性。如在链路配置过程中有任何问题可以联系CloudCanal技术团队。