腾讯云CDB MySQL如何不停机迁移至自建MySQL集群？-mysql教程-PHP中文网

DTS不支持从腾讯云CDB MySQL反向迁回自建集群，因其服务设计仅支持“上云”和“同构迁移”路径，CDB作为托管服务，binlog权限、账号策略及系统库机制均面向向外导出优化，未开放对下游自建库的增量写入控制能力。

腾讯云cdb mysql如何不停机迁移至自建mysql集群？

不能直接用 DTS 反向迁移。腾讯云 CDB MySQL 作为源库时，DTS 支持迁出；但作为目标库时，不支持接收来自自建集群的反向同步任务——这是服务设计限制，不是配置问题。

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)，实际是权限模型隔离

绕过 DTS，用开源工具构建可控的 binlog 拉取 + 解析 + 写入流程。核心是让自建集群扮演「slave」角色，从 CDB 主实例拉取并重放变更。

前提条件：

CDB 实例已开启 log_bin=ON、binlog_format=ROW、binlog_row_image=FULL（控制台「参数设置」里确认，不支持修改需提工单）
CDB 创建专用账号，授予：REPLICATION CLIENT、REPLICATION SLAVE、SELECT（全库）
自建集群中至少一个节点能直连 CDB 实例内网地址（推荐通过 CVM 中转，避免公网暴露）

推荐工具组合：

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 过滤、冲突规避

CDB 默认使用 utf8mb4，但部分老实例可能残留 utf8 或 latin1。自建集群若未统一，会导致同步中断或数据错乱。

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

执行前必须检查：

源库全局变量：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 任何协助的前提下，独立扛住全部读写压力——这需要真实流量验证，而不是靠同步日志是否“没报错”来判断。