ARTICLE · 1302847
MySQL 到 Kingbase 实时同步教程:Docker 安装、CDC 配置与增删改验证
MySQL 的数据搬到金仓以后，源库又改了一条记录，目标怎样跟着更新？源库删除的数据又如何从目标移除？本文围绕这两个实际问题，配置一条能持续传递变化的同步任务。
这里使用 DataMover，一款通过 Web 界面配置数据迁移、同步与集成的平台。本文用它连接两端数据库、选择表、设置字段映射，并持续处理 MySQL 的变更；不需要为本例编写同步程序。
本文会从环境检查开始，创建一条 MySQL → 人大金仓 Kingbase 的实时任务，先同步源表已有数据，再实际修改源端记录，检查目标能否跟着新增、更新和删除，最后验证正常停止后的继续同步。示例使用一张小表，便于把每次变化看清楚。
先分清：定时查新数据，还是持续接收数据变化
如果源表只追加记录，按自增 ID 定时查询可能已经够用。如果旧记录也会修改，就要确认更新时间字段是否被每个写入入口可靠维护。而一条记录被物理删除后，它已不在源表中，继续查询更大的 ID 通常发现不了这次删除。
CDC 是变更数据捕获。在本例中，同步任务读取 MySQL 的 binlog，也就是数据库记录数据变化的日志，从中获取新增、修改和删除，再将这些变化写入 Kingbase。它不要求业务表额外维护一个增量查询字段，但要求 MySQL 提供可读取的日志。
这条任务分为两个阶段：首次快照负责同步已有数据，后续持续监听负责同步新变化。 完成快照后不能立即关掉任务，否则后续变更就不会继续传递。这也解释了为什么本文选择“实时任务”，而不是给普通查询配置每分钟运行一次。
准备 DataMover 和两端数据库
本例使用社区免费版即可复现这条单表链路。可以从官网 https://datamover.cn/ 下载安装包；如果采用 Docker，在 Linux / macOS 准备好 Docker Engine 与 Docker Compose 后，可使用一键安装命令：
bash -c "$(curl -fsSL https://down.datamover.cn/install.sh)"进入部署目录，用下面的命令检查容器状态和日志：
docker compose psdocker compose logs -f
管理入口通常为 http://服务器IP:8000，以安装输出和实际端口配置为准。容器里的 localhost 指向容器自身，填写数据库连接时应使用执行节点可访问的地址。
在 DataMover 的“数据源”管理中准备 MySQL 和 Kingbase 连接，填写实际地址、端口、数据库及账号信息，分别测试连接。数据库地址必须能从执行节点访问，不能只确认自己的电脑可以连接。
本文复用已有测试实例。源表为 MySQL 的 sys_dict_type，是该实例中可以通过字典管理页面维护的测试表，原有 12 行；目标使用独立的 public.dm_cdc_dict_type_20261102。你可以换成自己的专用测试表，关键是有明确主键，且允许新增、修改、删除测试数据。不要在生产字典或已有业务目标表上照做。
两端的要求不同：MySQL 是读取日志的源端，Kingbase 是写入目标。Kingbase 账号需要对应 schema 的写入权限，使用自动建表时还需建表权限；这里不需要按“Kingbase 作为 CDC 源端”的方式设置逻辑复制。
启动前，确认 MySQL 的 binlog 和账号权限
数据源连接成功，说明普通连接和查询基本可用，但不代表账号已经能读取变更日志。建议在创建任务前完成下面的检查。
配置前也可以对照“CDC 实时同步必读”的 MySQL 章节检查，页面路径为 https://datamover.cn/doc/guide/CDC实时同步必读.html。下面直接说明本例需要核对的项目，不依赖打开文档才能继续操作。
确认连接的是哪套数据库、哪个账户
使用与 DataMover 源端相同的连接信息，在数据库客户端执行：
SELECT VERSION() AS mysql_version,@@hostname AS mysql_host,@@port AS mysql_port,DATABASE() AS current_database;SELECT USER() AS connection_identity,CURRENT_USER() AS matched_account;SHOW GRANTS FOR CURRENT_USER();
先核对返回的版本、实例和数据库。CURRENT_USER() 表示 MySQL 实际用于权限判断的账户，管理员配置权限时要匹配它的 Host 部分。不要因为另一条同名账号有复制权限，就认为当前连接也具备这些权限。
当前参考文档说明使用 Debezium 1.9.8。数据库版本不同，尤其是较新 MySQL 或兼容 MySQL 协议的产品，应另外确认连接器兼容性。
检查运行中的日志参数
SHOW GLOBAL VARIABLES LIKE 'log_bin';SHOW GLOBAL VARIABLES LIKE 'binlog_format';SHOW GLOBAL VARIABLES LIKE 'binlog_row_image';SHOW GLOBAL VARIABLES LIKE 'server_id';
看返回结果中的 Value，本例需要满足：
log_bin | ON | |
binlog_format | ROW | |
binlog_row_image | FULL | |
server_id |
如果不满足要求，应由管理员结合数据库版本修改配置，并重新检查实际生效值。例如自建 MySQL 的配置片段可以写成：
[mysqld]server-id=101log-bin=mysql-binbinlog_format=ROWbinlog_row_image=FULL
101 只是示例，应换成当前复制拓扑中未使用的值。开启 binlog 通常涉及服务启动配置和重启；容器部署要确认挂载和持久化，云数据库通过参数组等管理入口调整。部分参数也有会话设置，修改全局值后，还要确认已有业务连接使用的配置，不能只看新开的管理连接。
普通查询权限不等于复制权限
账号除所选表读取权限外，还需核对 REPLICATION CLIENT、REPLICATION SLAVE，以及首次快照在对应版本和锁定方式下需要的 RELOAD、SHOW DATABASES 等权限。由管理员结合实际范围设置。
本次第一次启动就卡在这里。任务尚未采集到数据，从任务页面下载日志，看到：
Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation错误发生在查询快照对应的 binlog 位点时。管理员补齐实际匹配账号的权限、确认日志配置后，正常停止并重新启动原任务，后续才成功。不要只反复点击连接测试，也不必为了消除提示直接授予 SUPER。
在支持该命令的 MySQL 5.7 / 8.0 上，可以用 SHOW MASTER STATUS; 检查能否读到 binlog 的文件和位置。其他版本按对应命令检查，并确认连接器支持。上面的 SQL、配置和安装命令是复现参考；本次源库配置由管理员处理，本文实测的是已有实例中的任务操作与数据变化。
创建实时任务：先让它同步已有数据
进入“任务管理 → 新建任务”，填写便于识别的名称，类型选择“实时任务”，源端选择已准备的 MySQL，目的端选择 Kingbase。
“是否执行快照”选“是”。因为目标表还没有这张源表的数据，需要先做一次存量初始化；只监听之后的新变化，并不能自动补上此前已有的记录。
点击“下一步”，在源端区域点击“选择数据集”添加表，再点击左侧表名查看字段映射。添加表之后，先检查目标表名和 schema。本例使用独立名称，避免把第一次快照写到已有业务表中。
检查映射：主键和时间字段各有作用
本例保留 dict_id 为主键。它用于识别同一条记录，后面会用这个编号核对更新是否落到原行、删除是否移除了对应行。换成自己的表时，应保留对应的实际业务主键。
自动映射也要检查。本次 create_time、update_time 被生成为 VARCHAR，在目的端映射中改为 TIMESTAMP，长度改为 0，然后保存配置。
把时间存成字符串，表面上也可能看到日期，但后续排序、时间运算及精度语义可能与预期不同。因此不能只核对字段名称；换成业务表后，还应检查时间精度、字符长度和金额精度。
完成创建后，打开任务详情中的“CDC策略配置”。本次选择如下：
initial | ||
1 | ||
offset JSON |
确认目标表可以清空，再使用图中的清空选项。 有历史业务数据的目标表应先确定初始化方案。CDC 持续读取日志，不需要再把 dict_id 或更新时间选成增量字段，也不用设置每分钟轮询。
启动任务，先确认存量确实到了目标
在任务详情点击“全部启动”，选择在线执行器，确认启动。快照完成后，本次统计显示采集成功 12 行、输出成功 12 行，失败均为 0。
再点击详情中的目标表名，打开 Kingbase 数据预览，确认能看到源表原有编号 1–12 的记录。这里既要看统计，也要实际看目标内容。
保持实时任务运行，接着验证新变化。快照阶段完成，并不意味着后续日志监听可以停止；结合页面的调度状态确认任务仍在运行。
在源端改一条记录，观察 Kingbase 怎么变化
本次源表对应“系统管理 → 字典管理”，所以通过该测试业务页面新增、修改和删除记录。你使用其他表时，应通过对应测试页面或数据库客户端产生变化，不要求你的表也有字典管理入口。
每次源端操作后，关闭旧的目标预览，再点击目标表名重新打开，确保查看的是最新结果。
新增：让目标出现一条可识别的记录
在源端新建名称为“CDC变更演示_20261102”的字典类型，类型为 dm_cdc_demo_20261102，备注标记为测试用途。保存后，本次源库生成编号 13；你的实例编号可能不同，以实际生成值为准。
重新打开目标预览，找到相同编号，核对名称、类型和备注。本次编号 13 出现在 Kingbase，目标由 12 行变成 13 行，说明新增事件已写入。
更新：编号不变，内容应该在原行更新
保持编号 13 不变，在源端修改名称为“CDC变更演示_已修改_20261102”，同时修改备注，再查看目标。
本次目标编号 13 的名称、备注和更新时间随之改变，仍然是 13 行。这个检查比只看成功计数更具体：它说明更新到了同一条目标记录，没有再插入一个重复行。
删除：只删除测试记录，再看目标是否消失
在源端确认选中的只有刚创建的编号 13，执行删除，再重新查看目标。此次编号 13 消失，原有 1–12 保留，目标恢复为 12 行。
到这里，新增、更新、物理删除都各走过一次。第一轮累计采集、输出各 15 行，是因为统计包含 12 行快照与 3 次变更事件。它不是目标当前行数，目标最后只有 12 行并不矛盾。
正常停止后，还能接着同步吗
任务运行后会保存 offset，可以把它理解为读到哪段日志的进度。需要暂停再继续时，应保留原任务及其进度，正常点击“全部停止”，不要把“重置”当成同一个操作。
本次正常停止后，在源端新增第二条独立记录，类型为 dm_cdc_resume_20261102，编号为 14。此时目标仍是 12 行，没有这条记录，符合任务已停止的状态。
保持原配置再次启动。这一轮采集、输出各成功 1 行，失败均为 0，目标出现编号 14，原有 12 行也仍然保留。
这次验证了正常停止后的继续消费。它的前提是 MySQL 还保留着需要读取的 binlog；如果原日志已经清理，只保存 offset 也无法找回那段变化。部署时应让日志保留时间覆盖可能的停止和追赶窗口，并评估磁盘容量。
实验最后删除编号 14，确认删除同步到目标，两端预览恢复原有 12 行，然后正常停止任务。独立目标表、映射和运行记录保留，便于复查。
从这张小表走向自己的业务表
这条验证路径已经走通：存量初始化后，源端新增、修改、删除都能在目标找到对应结果，正常停止期间新增的数据也在重启后补上。依据来自源端业务页面、目标预览和任务统计；这不是独立的全表逐字段校验，也未覆盖 DDL、并发压力或异常退出。
换成实际业务表时，先检查主键、时间与数值精度，再用可识别的测试记录重复上述动作。把类型、更新和删除语义确认清楚后，再扩大表数与数据量，结果会更容易判断。
