DTS不支持从腾讯云CDB MySQL反向迁回自建集群，因其服务设计仅支持“上云”和“同构迁移”路径，CDB作为托管服务，binlog权限、账号策略及系统库机制均面向向外导出优化，未开放对下游自建库的增量写入控制能力。
不能直接用 DTS 反向迁移。腾讯云 CDB MySQL 作为源库时，DTS 支持迁出；但作为目标库时，不支持接收来自自建集群的反向同步任务——这是服务设计限制，不是配置问题。
为什么 DTS 不支持从 CDB 迁回自建集群？
DTS 官方只提供「上云」和「同构迁移」路径：CDB → CDB、自建 MySQL → CDB、第三方云 MySQL → CDB。CDB 是托管服务，其 binlog 权限、账号策略、系统库（如 __tencentdb__）写入机制均面向「向外导出」优化，不开放对下游自建库的增量写入控制能力。
常见误操作是试图在 DTS 控制台新建「自建 MySQL → CDB」任务后，把方向反过来填——界面可能不报错，但任务会卡在「等待源库连接」或「校验失败」，因为 CDB 不允许非腾讯云侧进程主动拉取其 binlog 并反向应用。
- 源库必须能被 DTS 实例直连，且开放
REPLICATION CLIENT和REPLICATION SLAVE权限；CDB 默认禁止外网拉取 binlog，即使开外网访问，也不等同于开放复制协议握手 - DTS 增量同步依赖 MySQL 复制协议（COM_BINLOG_DUMP），而 CDB 对该协议的响应仅限于其内部 slave 节点，不对外暴露
-
SHOW MASTER STATUS在 CDB 上可查，但mysqlbinlog --read-from-remote-server会拒绝连接，错误类似Access denied; you need (at least one of) the SUPER or BINLOG_ADMIN privilege(s)，实际是权限模型隔离
可行替代方案：基于 binlog 的自建同步链路
绕过 DTS，用开源工具构建可控的 binlog 拉取 + 解析 + 写入流程。核心是让自建集群扮演「slave」角色，从 CDB 主实例拉取并重放变更。
前提条件：
- CDB 实例已开启
log_bin=ON、binlog_format=ROW、binlog_row_image=FULL（控制台「参数设置」里确认，不支持修改需提工单） - CDB 创建专用账号，授予：
REPLICATION CLIENT、REPLICATION SLAVE、SELECT（全库） - 自建集群中至少一个节点能直连 CDB 实例内网地址（推荐通过 CVM 中转，避免公网暴露）
推荐工具组合：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
maxwell：轻量、稳定、输出 JSON 到 Kafka/Redis/Stdout，适合做中间解析层；不直接写目标库，需配合消费者程序 -
canal+canal-adapter：阿里系成熟方案，canal-adapter支持直连 MySQL 目标写入，但注意适配 CDB 的认证方式（CDB 默认用 caching_sha2_password，自建 MySQL 8.0+ 需启用对应插件） - 手动
mysqlbinlog+ 脚本解析：仅建议小流量、短周期场景；mysqlbinlog -h xxx.cdb.tencentcloud.com -u user -p --raw --read-from-remote-server --stop-never可持续拉流，但需自行处理 position 管理、DDL 过滤、冲突规避
字符集与 DDL 兼容性必须人工核对
CDB 默认使用 utf8mb4，但部分老实例可能残留 utf8 或 latin1。自建集群若未统一，会导致同步中断或数据错乱。
执行前必须检查：
- 源库全局变量：
SHOW VARIABLES LIKE 'character_set%'、SHOW VARIABLES LIKE 'collation%' - 每张表实际字符集：
SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' - CDB 的
lower_case_table_names默认为 1（Linux 下忽略大小写），自建集群若设为 0，建表语句会因大小写不匹配失败 - CDB 不支持
CREATE TABLE ... ENGINE=MyISAM，若自建集群启用了 MyISAM 引擎，需提前替换为 InnoDB
DDL 同步尤其危险：ALTER TABLE 在 CDB 上成功，不代表能在自建集群上重放——例如 CDB 支持在线加列（ALGORITHM=INSTANT），而旧版 MySQL 不支持，会卡住整个同步链路。
双写兜底比纯同步更可控
如果业务能接受短期改造，强烈建议放弃「纯同步」幻想，走「CDB 与自建集群双写 + 渐进切流」路线。这是生产环境最稳妥的选择。
关键动作：
- 在应用 DAO 层增加开关，支持三种状态：
write_only_cdb、write_only_selfhosted、write_both（先写 CDB，再写自建集群，CDB 成功才提交） - 读流量先 100% 走 CDB，待双写稳定运行 3–5 天、数据一致性校验（如
pt-table-checksum）无差异后，再逐步切读流量 - 同步程序仅作为「兜底补偿」存在：当双写因网络抖动失败时，用它补漏；不作为主同步通道
- 所有写操作必须带时间戳字段（如
updated_at），用于后续比对程序识别最新版本，避免覆盖写导致数据倒退
真正难的不是把数据搬过去，而是让新集群在没有 CDB 任何协助的前提下，独立扛住全部读写压力——这需要真实流量验证，而不是靠同步日志是否“没报错”来判断。
