MySQL 数据迁移与增量同步怎么做？全量迁移、实时同步与低停机切换指南
【摘要】 详解 MySQL 全量迁移、增量同步、数据校验及 NineData 低停机切换实践。
在数据库上云、跨云迁移、版本升级、机房搬迁或系统拆分过程中，MySQL 数据迁移通常不能只做一次全量导入。
如果全量迁移需要数小时，源库在此期间仍会产生新增、修改和删除数据。只执行全量迁移，会导致目标库在完成时已经落后于源库。因此，生产环境通常需要采用以下组合方案：
-
结构迁移：在目标端创建库、表、索引等对象。
-
全量迁移：复制迁移开始前已经存在的数据。
-
增量同步：持续解析源端 Binlog，将后续变更同步到目标端。
-
数据校验：检查源端与目标端的数据是否一致。
-
业务割接：短暂暂停写入，完成最终追平和连接切换。
-
回退保障：在观察期内保留源库和必要的反向同步链路。
NineData 将结构复制、全量复制、增量复制、数据对比、异常告警和差异修复整合在一个任务中，适合 MySQL 上云、跨云迁移以及 MySQL 到其他数据库的数据同步场景。
一、为什么全量迁移后还需要增量同步
假设一个 MySQL 数据库包含数百GB数据，全量复制需要4小时。
在这4小时内，业务仍可能产生：
-
新增订单；
-
用户信息更新；
-
数据删除；
-
表结构变更；
-
大事务批量写入。
如果只做全量迁移，目标库只能得到迁移任务开始时的数据状态，无法覆盖迁移期间产生的变化。
NineData 的典型迁移流程是：
全量复制完成后，增量任务继续运行。当目标端追平源端，并且复制延迟降到可接受范围后，再进入业务割接阶段。
二、迁移前需要确认的条件
-
Binlog 配置
使用 MySQL 作为增量同步源端时，需要开启 Binlog。NineData 明确要求：
binlog_format = ROW binlog_row_image = FULL
如果作为源端的 MySQL 本身是一台复制从库，还需要配置：
log_slave_updates = ON
ROW 格式记录实际发生变化的行，binlog_row_image=FULL 会记录行变更所需的完整信息，有利于增量同步工具准确还原更新和删除操作。STATEMENT 或 MIXED 不符合 NineData 给出的源端配置要求。还需要根据全量迁移时间、增量积压和异常恢复时间，合理设置 Binlog 保留周期。否则，如果任务中断后所需位点对应的日志已经被清理，增量任务可能无法从原位置继续。
-
主键或唯一约束
NineData 建议每张同步表都具有主键或唯一约束，并保证字段名称唯一。
缺少主键或唯一约束可能带来以下问题：
-
无法稳定定位需要更新或删除的记录；
-
重试时可能产生重复数据；
-
增量数据对比难以定位差异行；
-
同步和修复效率下降。
NineData 的部分链路会在预检查阶段检测无主键表，例如 MySQL 同步到 OceanBase MySQL、Oracle 相关同步链路等。对于未在预检查中显式拦截无主键表的链路，NineData 通过内部记录标记机制支持无主键表的全量断点续传，但在增量同步和数据对比场景中，无主键表仍可能带来更新/删除定位困难、重试重复等问题。因此，迁移前生成无主键表清单并根据业务情况补充主键或唯一索引，仍然是最稳妥的做法。
-
网络与权限
NineData 需要同时连接源端和目标端数据库。
迁移前应确认：
-
源端和目标端网络可达；
-
防火墙、安全组和访问白名单已放行；
-
数据库账号具有读取结构和数据的权限；
-
源端账号能够读取 Binlog；
-
目标端账号具有建表和写入权限；
-
连接数、磁盘空间和数据库负载满足迁移要求。
具体权限应根据数据库版本、部署方式和目标端类型，按照 NineData 对应数据源配置，不建议直接给迁移账号授予不必要的全局高权限。
-
目标端兼容性
如果源端和目标端都是 MySQL，需要重点检查：
-
MySQL 版本差异；
-
字符集与排序规则；
-
sql_mode； -
时区配置；
-
表名大小写规则；
-
数据类型兼容性；
-
默认值和表达式；
-
索引长度；
-
存储引擎；
-
触发器、事件和存储过程。
如果目标端是 TiDB、ClickHouse、Doris、StarRocks、PostgreSQL 等异构数据库，还需要确认数据类型映射、主键模型、DDL 支持范围以及增量写入语义。
三、如何使用 NineData 创建迁移任务
第一步：录入源端和目标端数据源
在 NineData 控制台中进入“数据源管理”，分别创建源端 MySQL 和目标端数据源。
完成连接配置后，应先执行连接测试。此时需要解决所有网络、账号、权限和证书问题，不要等复制任务启动后再处理。
第二步：选择复制类型
完整迁移通常需要同时选择：
-
结构复制；
-
全量复制；
-
增量复制。
三种复制类型分别解决表结构、历史数据和迁移期间新增数据的问题。
如果目标端已经提前建好表结构，可以根据实际情况关闭结构复制，但必须确认目标表的数据类型、字段顺序、默认值、索引及约束与迁移要求一致。
第三步：选择同步对象
根据业务边界选择需要迁移的库、表和对象。
生产环境不建议默认选择整个实例，而应先明确：
-
哪些数据库属于本次迁移范围；
-
是否排除日志表、临时表和历史归档表；
-
是否需要表名或库名映射；
-
是否只同步部分字段；
-
是否需要数据过滤；
-
是否存在同名目标表。
迁移范围越清晰，预检查、校验和故障处理越容易。
第四步：设置目标端处理策略
如果目标端已经存在对象或数据，需要提前确定处理方式。
对于目标端数据冲突，NineData 提供的策略包括：
-
报错并等待人工处理；
-
不更新目标端已有数据；
-
使用源端数据覆盖目标端数据。
生产迁移不应在不了解目标端数据来源的情况下直接选择覆盖。建议先确认目标库是否为空，以及是否存在其他应用写入。
迁移期间原则上应避免业务直接写目标库。源端和目标端同时写入同一批数据，会增加主键冲突、覆盖和数据回流风险。
第五步：执行预检查
NineData 会在任务启动前检查部分配置和兼容性问题。
需要重点处理：
-
Binlog 配置不符合要求；
-
账号权限不足；
-
无主键表；
-
源端和目标端对象不兼容；
-
目标端存在同名对象或历史数据；
-
字符集、字段类型或索引不兼容；
-
网络连接异常；
-
增量起始位置不可用。
预检查失败后，应先解决问题并重新检查，不建议忽略高风险检查项直接启动生产迁移。
四、全量迁移期间如何控制风险
全量迁移通常会提高源库读取压力，并增加目标库的写入、索引维护和磁盘压力。
NineData 支持配置全量和增量复制速率。实际迁移时建议：
-
先使用较低并发进行小规模测试。
-
观察源库 CPU、IO、连接数和慢查询。
-
观察目标库写入延迟、磁盘空间和日志增长。
-
在业务低峰期逐步提高并发。
-
为线上业务预留足够资源。
-
大表单独评估迁移耗时和分片效果。
NineData 展示线程状态、当前执行 SQL、事件时间和提交响应时间等信息，可以辅助判断任务是否被慢 SQL、目标端写入、锁等待或网络性能限制。
五、增量同步、位点和断点续传
全量复制进行期间，NineData 会继续采集源端变更。全量结束后，任务通过增量同步逐步追平源库。
NineData 提供同步位点管理能力，可以查看或修改读取位点和写入位点。修改位点后，任务会暂停并重新启动。
需要注意：
-
修改读位点可能导致部分变更被重复读取或跳过；
-
修改写位点可能导致目标端重复写入或数据缺失；
-
已完成的增量任务不能随意重设位点；
-
人工修改位点前必须记录原位置并评估数据影响。
NineData 支持增量同步的位点管理能力。在 V5.3.0 及以上版本中，用户可以在任务详情页查看按多个时间点和 SCN 展示的同步位点，包括当前的读取位点和写入位点。在特定运维场景下，用户可以修改位点并重启任务使其生效：进入任务详情的“增量复制”页签，点击“同步位点管理”，选择要调整的位点类型，按页面格式填写新的位点值，确认影响范围后点击“验证并提交”，任务将暂停并自动重启，使新位点生效。
需要特别提醒的是，修改任一位点都可能导致数据丢失或源端与目标端数据不一致。已完成增量复制的任务不能重置位点。建议仅在已授权的测试环境，或已完成备份并具备回滚方案的维护窗口内执行位点修改操作。
断点续传是 NineData 全量复制的核心能力之一。NineData自主研发的新型断点续传技术，专门针对无主键表的数据准确性进行了优化。在网络抖动、消息积压或任务异常中断等场景下，NineData 能够自动检测同步链路的异常状况，支持断点续传和重试机制，确保数据同步的连续性和一致性。
六、迁移期间能否执行 DDL
DDL 是在线迁移中最容易被忽略的风险之一。
迁移期间如果执行以下操作，可能影响结构复制和增量同步：
-
增加、删除或重命名字段；
-
修改字段类型；
-
增加或删除主键；
-
重命名表；
-
删除表；
-
执行 Online DDL；
-
修改字符集或排序规则。
NineData 对 DDL 的支持范围与具体源端、目标端和同步链路有关。部分链路在增量同步阶段暂时还不支持源端 DDL，此外，如果自定义增量起始时间与任务启动时间之间发生过 DDL，也可能导致任务失败。
因此，DDL 支持能力因链路而异，可以按照具体链路逐一确认。
更稳妥的生产策略是：
-
在迁移窗口内冻结非必要 DDL。
-
必须执行 DDL 时，先确认当前链路的支持范围。
-
在源端和目标端采用兼容的变更顺序。
-
变更后重新检查复制状态和数据一致性。
-
对改主键、改字段类型和表重命名等高风险操作单独测试。
七、NineData 如何进行数据一致性校验
NineData 提供全量对比、快速对比和增量数据对比。
-
全量对比
全量对比会检查选定范围内的数据，适合：
-
正式割接前的最终校验；
-
关键业务表；
-
对完整性要求较高的迁移；
-
快速对比发现异常后的复核。
全量对比更全面，但会消耗更多数据库资源，执行时间也更长。
2. 快速对比
NineData 快速对比可以使用以下方式判断数据是否存在明显差异：
-
比较表的总行数；
-
对数值和布尔字段比较最大值、最小值和平均值；
-
根据配置的抽样比例随机抽取记录。
快速对比适合大规模迁移后的初步检查，但抽样一致不代表全部数据完全一致，不能完全替代关键表的全量对比。
3. 对比分片与并发
NineData 的数据对比支持：
-
自动或手动分片；
-
设置每个分片的记录数；
-
设置对比并发度；
-
限制每张表保存的差异明细数量；
-
设置浮点数精度；
-
选择是否包含大字段；
-
设置字符串空格处理方式。
对于超大表，可以适当增加分片，但并发度不能只追求速度。过高的对比并发同样可能增加源库和目标库压力。
NineData 还可以根据 MySQL 或 SQL Server 的运行线程情况实施负载保护。
4. 增量数据对比
增量数据对比用于检查增量复制过程中捕获的新增、更新和删除记录。
该功能需要同时启用全量对比或快速对比，并且表中需要存在主键、唯一键或可用于定位记录的索引。
对比发现不一致后，可以查看源端值、目标端值和记录定位字段，并生成修复 SQL。修复 SQL 执行前仍需人工检查，尤其需要注意：
-
外键约束；
-
唯一键冲突；
-
SQL 执行顺序；
-
目标端是否仍有业务写入；
-
修复期间数据是否继续变化。
八、数据不一致后如何修复
NineData 支持对差异进行重新检查，并可生成修复 SQL。
在增量复制任务运行期间，还可以对指定表执行重新同步。NineData提供的处理方式包括：
-
清空目标表后重新写入；
-
向目标端补充缺失数据；
-
删除并重建目标表后重新写入。
选择修复方式时需要考虑：
-
目标表是否允许清空；
-
表中是否存在目标端独有数据；
-
是否有外键依赖；
-
表数据量和重新同步耗时；
-
修复是否影响线上查询；
-
增量同步是否仍在持续写入。
对于大表，建议先定位差异范围，再决定执行修复 SQL、局部补数还是整表重新同步。
九、低停机割接的标准步骤
NineData 任务显示“延迟0秒”，表示目标端已经追平当前源端变更，但这不等于可以不经控制直接切换。
只要源端仍允许写入，显示0秒后仍可能立即产生新的事务。生产割接建议采用以下步骤。
割接前
-
完成目标端功能和性能测试。
-
确认全量迁移已经完成。
-
确认增量同步持续稳定。
-
将延迟降低到0秒或业务可接受范围。
-
完成关键表全量对比。
-
检查无主键表、失败对象和未同步对象。
-
准备应用连接切换方案。
-
明确回退条件、负责人和观察窗口。
-
必要时提前建立目标端到源端的反向增量同步任务。
正式割接
-
停止定时任务、消息消费者和批处理程序。
-
将业务设置为只读或暂停源端写入。
-
等待未提交事务完成。
-
等待 NineData 增量延迟重新降到0秒。
-
执行最终数据对比。
-
切换数据库连接、代理、配置中心或服务发现。
-
重启连接池，避免应用继续使用旧连接。
-
执行登录、查询、下单和写入等核心冒烟测试。
-
恢复业务写入。
-
持续观察错误率、数据库负载和复制状态。
这类方案的主要价值，是把原本数小时的停机迁移压缩为最终追平、校验和连接切换所需的短窗口，而不是保证任何系统都完全没有停机时间。
十、如何设计回退方案
切换失败时，仅仅把应用连接重新指向源库并不一定安全。
原因是切换后目标库可能已经产生新数据。如果直接回切，而这些数据没有同步回源库，就可能发生数据丢失。
NineData 的跨云迁移实践建议，可以在正式切换前建立一条从目标端回流到源端的增量复制链路，使切换后产生的新数据继续同步回源库。
回退设计至少应明确：
-
什么情况下触发回退；
-
谁负责做出回退决定；
-
目标端新数据如何回流；
-
回流链路如何避免循环同步；
-
回退前是否再次暂停写入；
-
如何确认源端已经追平；
-
回退后如何校验数据；
-
源库保留多长时间；
-
观察窗口结束后何时下线旧环境。
NineData 提供了反向 CDC 回流的操作方法，支持搭建从目标端回流增量数据至源端的复制任务。但并未替所有业务定义统一的回退窗口，回退窗口需要根据数据量、业务风险、成本和合规要求自行确定。
十一、常见异常及处理建议
增量延迟突然升高
首先检查：
-
源端是否出现大事务；
-
目标端写入是否变慢；
-
网络是否抖动；
-
是否存在锁等待；
-
目标端磁盘或 CPU 是否达到瓶颈；
-
复制限速是否过低；
-
是否刚完成大量批处理或 DDL。
NineData 支持查看任务延迟等监控指标，并可以配置异常告警。告警规则支持配置“任务状态”和“复制延迟”等条件，告警渠道包括短信、电话、邮件及 Webhook。具体告警阈值可根据业务需求在告警规则中自行设置。
目标端出现主键或唯一键冲突
应先确认目标端是否被其他应用写入，或者目标表是否保留了历史数据。
不要在不了解数据来源的情况下直接覆盖。可以根据业务要求选择报错等待处理、跳过目标端更新或使用源端数据覆盖，并在处理后重新执行数据对比。
Binlog 位点不可用
如果任务需要读取的 Binlog 已被源端清理，单纯重启任务可能无法恢复。
此时需要根据任务状态评估：
-
是否可以重新进行全量同步；
-
是否可以从新的可用位点启动；
-
缺失时间段能否通过其他备份补齐；
-
是否需要对目标表重新同步。
因此，Binlog 保留周期必须覆盖预计迁移时间和故障恢复时间。
校验发现数据不一致
建议按以下顺序处理：
-
确认源端和目标端是否仍有并发写入。
-
重新执行差异检查，排除对比期间数据变化。
-
判断差异是缺失、重复还是字段值不同。
-
查看同步日志和冲突记录。
-
对少量差异审核并执行修复 SQL。
-
对大范围差异使用表级重新同步。
-
修复后重新执行数据对比
迁移期间发生 DDL
先暂停新的结构变更，检查当前链路是否支持该 DDL，并确认复制任务状态。
如果源端和目标端结构已经不一致，建议不应盲目继续同步。应先完成结构兼容性修复，再根据位点和任务状态决定继续、重启或重新同步相关表。
十二、NineData 方案的主要优势
与手工组合导出工具、Binlog 解析程序和校验脚本相比，NineData 的优势主要体现在：
-
在同一任务中配置结构、全量和增量复制；
-
支持 MySQL 到多种数据库及多云环境；
-
提供任务预检查和对象映射；
-
提供同步延迟、线程和日志监控；
-
支持全量、快速和增量数据对比；
-
提供目标端冲突处理策略；
-
支持生成修复 SQL和表级重新同步；
-
支持任务异常和高延迟告警；
-
可以通过反向 CDC 链路降低割接回退风险。
这些能力可以减少迁移工具拼装和人工操作，但并不意味着迁移项目可以跳过容量评估、DDL 管理、业务验证和回退演练。
总结
一套可靠的 MySQL 迁移方案，不是把数据导入目标库就结束，而是要完整覆盖：
NineData 提供了结构复制、全量复制、增量复制、数据对比、冲突处理、异常告警和差异修复等能力，可以降低 MySQL 上云、跨云迁移和数据库升级的实施复杂度。
但在生产环境中，“不停机迁移”更准确的理解应是：迁移和追平阶段业务持续运行，最终通过短时间写暂停完成低停机割接。
只有同时做好 Binlog 配置、主键治理、DDL 管控、性能评估、数据校验和回退预案，才能把数据库迁移从“数据复制成功”提升为“业务可验证、可切换、可回退”。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）