json格式 通过dm同步过来到tidb 字段的某些值变为了 base64:type253

🪐 TiDB 技术问题
1

【TiDB 使用环境】生产环境 /测试/ Poc
【TiDB 版本】7.5.6 dm版本 2.0
tidb的数据 需要解码才能看到（在mysql是没有问题的正常显示json格式），会是什么情况导致

image
image646×331 89.1 KB

【操作系统】
【部署方式】云上部署（什么云）/机器部署（什么机器配置、什么硬盘）
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】

2

我们把mysql同步到doris，数据类型也会发生变化，因为mysql的某些数据类型，doris不支持。。你的这种情况应该也是正常的。。
最多代码适配一下。

3

dm 版本可以单独升级到最新版本：v8.5.3

4

CREATE TABLE user_bind (
id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
game_id int(11) unsigned NOT NULL,
user_id bigint(20) NOT NULL,
mobile_num varchar(50) NOT NULL,
ext_info json NOT NULL,
create_time datetime NOT NULL,
update_time datetime NOT NULL COMMENT ‘’,
db_updated datetime DEFAULT NULL COMMENT ‘表更新时间’,
PRIMARY KEY (id),
UNIQUE KEY uniq (game_id,user_id),
UNIQUE KEY idx_user_game (user_id,game_id),
KEY game_mobile (game_id,mobile_num)
) ENGINE=InnoDB AUTO_INCREMENT=594408952 DEFAULT CHARSET=utf8mb4

mysql数据（部分）

image
image931×239 73.9 KB

通过dm同步到tidb数据 部分转为base64 部分没有转（tidb）

image
image1189×239 97.7 KB

5 
CREATE TABLE `user_bind` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `game_id` int(11) unsigned NOT NULL COMMENT '游戏ID',
  `user_id` bigint(20) NOT NULL COMMENT '用户ID',
  `mobile_num` varchar(50) NOT NULL COMMENT '手机号',
  `ext_info` json NOT NULL COMMENT '扩展信息',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  `update_time` datetime NOT NULL COMMENT '更新时间',
  `db_updated` datetime DEFAULT NULL COMMENT '表更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniq` (`game_id`, `user_id`),
  UNIQUE KEY `idx_user_game` (`user_id`, `game_id`),
  KEY `game_mobile` (`game_id`, `mobile_num`)
) ENGINE=InnoDB
  AUTO_INCREMENT=594408952
  DEFAULT CHARSET=utf8mb4
  COMMENT='用户绑定表';
  
INSERT INTO user_bind (
  id, game_id, user_id, mobile_num, ext_info, create_time, update_time, db_updated
) VALUES
(594408330, 303, 1608943207, 'u8zUTaAlUXfpKQGtq4pfSsg==', '{"rl_status": 1, "login_time": "2025-09-02 21:58:40"}', '2025-09-02 21:58:40', '2025-09-02 21:58:40', NULL),
(594408329, 303, 1474386930, 'tD9wy9VhUoC0fMn5rTBLA==', '{"rl_status": 1, "login_time": "2025-09-02 21:58:40"}', '2025-09-02 21:58:40', '2025-09-02 21:58:40', NULL),
(594408328, 323, 1608943206, 'mIKL9g4HgPuta6TMAXtxhAM==', '{"rl_status": 1, "login_time": "2025-09-02 21:58:40"}', '2025-09-02 21:58:40', '2025-09-02 21:58:40', NULL),
(594408327, 323, 1608943205, 'V5+JtHvkCqh+q4IDmtCz9QA==', '{"login_time": "2025-09-02 21:58:40"}', '2025-09-02 21:58:40', '2025-09-02 21:58:40', NULL),
(594408326, 475, 1619498046, 'IrS9Yb6XbGUVexZMzqV4wA==', '{}', '2025-09-02 21:58:40', '2025-09-02 21:58:40', NULL),
(594408325, 475, 1619498047, 'MgMphAAG/ZdZepmcCKUv8hQ==', '{"login_time": "2025-09-02 21:58:39"}', '2025-09-02 21:58:39', '2025-09-02 21:58:39', NULL),
(594408324, 425, 1619498043, '1gn7mwk7cn8zplMneIlQWo==', '{"rl_status": 1, "login_time": "2025-09-02 21:58:39"}', '2025-09-02 21:58:39', '2025-09-02 21:58:39', NULL),
(594408323, 425, 1, 'nGmrS4PVWfvFe+UNrFMBNw==', '{"rl_status": 1, "login_time": "2025-09-02 21:58:39"}', '2025-09-02 21:58:39', '2025-09-02 21:58:39', NULL),
(594408322, 1, 1544000657, '+tmx9y/JPTtu4ByLBjpo7w==', '{"rl_status": 1, "login_time": "2025-09-02 21:58:39"}', '2025-09-02 21:58:39', '2025-09-02 21:58:39', NULL),
(594408321, 1, 1608939379, '7l8t+HYNPwdsy5j4KiknAw==', '{"rl_status": 1}', '2025-09-02 21:58:39', '2025-09-02 21:58:39', NULL);

我用这个案例写 tidb 8.5.3，看内容是不变的。

(root@127.0.0.1) [test]>select * from user_bind;
+-----------+---------+------------+---------------------------+-------------------------------------------------------+---------------------+---------------------+------------+
| id        | game_id | user_id    | mobile_num                | ext_info                                              | create_time         | update_time         | db_updated |
+-----------+---------+------------+---------------------------+-------------------------------------------------------+---------------------+---------------------+------------+
| 594408321 |       1 | 1608939379 | 7l8t+HYNPwdsy5j4KiknAw==  | {"rl_status": 1}                                      | 2025-09-02 21:58:39 | 2025-09-02 21:58:39 | NULL       |
| 594408322 |       1 | 1544000657 | +tmx9y/JPTtu4ByLBjpo7w==  | {"login_time": "2025-09-02 21:58:39", "rl_status": 1} | 2025-09-02 21:58:39 | 2025-09-02 21:58:39 | NULL       |
| 594408323 |     425 |          1 | nGmrS4PVWfvFe+UNrFMBNw==  | {"login_time": "2025-09-02 21:58:39", "rl_status": 1} | 2025-09-02 21:58:39 | 2025-09-02 21:58:39 | NULL       |
| 594408324 |     425 | 1619498043 | 1gn7mwk7cn8zplMneIlQWo==  | {"login_time": "2025-09-02 21:58:39", "rl_status": 1} | 2025-09-02 21:58:39 | 2025-09-02 21:58:39 | NULL       |
| 594408325 |     475 | 1619498047 | MgMphAAG/ZdZepmcCKUv8hQ== | {"login_time": "2025-09-02 21:58:39"}                 | 2025-09-02 21:58:39 | 2025-09-02 21:58:39 | NULL       |
| 594408326 |     475 | 1619498046 | IrS9Yb6XbGUVexZMzqV4wA==  | {}                                                    | 2025-09-02 21:58:40 | 2025-09-02 21:58:40 | NULL       |
| 594408327 |     323 | 1608943205 | V5+JtHvkCqh+q4IDmtCz9QA== | {"login_time": "2025-09-02 21:58:40"}                 | 2025-09-02 21:58:40 | 2025-09-02 21:58:40 | NULL       |
| 594408328 |     323 | 1608943206 | mIKL9g4HgPuta6TMAXtxhAM== | {"login_time": "2025-09-02 21:58:40", "rl_status": 1} | 2025-09-02 21:58:40 | 2025-09-02 21:58:40 | NULL       |
| 594408329 |     303 | 1474386930 | tD9wy9VhUoC0fMn5rTBLA==   | {"login_time": "2025-09-02 21:58:40", "rl_status": 1} | 2025-09-02 21:58:40 | 2025-09-02 21:58:40 | NULL       |
| 594408330 |     303 | 1608943207 | u8zUTaAlUXfpKQGtq4pfSsg== | {"login_time": "2025-09-02 21:58:40", "rl_status": 1} | 2025-09-02 21:58:40 | 2025-09-02 21:58:40 | NULL       |
+-----------+---------+------------+---------------------------+-------------------------------------------------------+---------------------+---------------------+------------+
10 rows in set (0.00 sec)

我觉得你可以开跟踪日志，看看实际执行的 sql 到底什么样的，先判断下 sql 来源是否一丁是 dm。

MySQL 原生同步有这个问题么？

6

mysql同步没有这个问题，业务反馈这个是归档库，数据只会从mysql过来，不过我们确认日志来源的sql 确认一下

7

升级版本

8

要解决 DM 同步后 TiDB 中 JSON 字段值变为 base64:type253 的问题，需从源数据格式、DM 同步配置、TiDB JSON 类型处理 三方面分析

9

升级dm版本看看,看上去像是数据类型不兼容啊

10

升级工具版本试试

11

在 TiDB 7.5.6 中，从 DM 2.0 同步过来的数据在 KV 层（如通过 RawKV API 或直接查看底层存储）显示为编码后的格式，而不是明文 JSON，这通常是正常现象

12

你的表数据类型定义的是json类型吗?

13

可能真的是数据源的问题，不一定的是通过DM同步的。

14

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。