JSON主从复制失败主因是解析行为不一致，需检查Last_SQL_Error含Invalid JSON text等关键词，验证主从JSON函数结果、sql_mode、COLLATE及binlog_row_value_options是否严格一致。
Last_SQL_Error，只要报错含 Invalid JSON text、NULL member names、Malformed JSON path 或 CHARACTER SET 'binary'，基本就是主从 JSON 解析行为不一致——不是数据错了，是两边“读法”不一样。
怎么快速定位是不是 JSON 复制问题？
执行 SHOW SLAVE STATUS\G，盯住 Last_SQL_Error 字段。出现以下任一关键词，立刻停掉 SQL 线程，别盲目跳过：
-
Invalid JSON text：大概率主库版本 ≥ 8.0.27，从库 sql_mode 不同 -
JSON document may not contain NULL member names：主库插入了{"": "value"}这种键为NULL的对象，但从库（尤其 5.7 或早期 8.0）拒绝解析 -
Malformed JSON path：主库用了$.Status（大小写不敏感路径），但从库是 8.0.26 或更早，只认严格大小写 -
Cannot create a JSON value from a string with CHARACTER SET 'binary'：主库字段定义漏了COLLATE utf8mb4_0900_as_cs，或从库建表时没同步字符集
这类错误不会触发 GTID 冲突，Slave_SQL_Running 直接变 No，Seconds_Behind_Master 冻住不动——说明卡在 SQL 线程的 JSON 解析阶段，不是网络或权限问题。
为什么主从执行同一句 JSON 查询结果不同？
MySQL 5.7 和 8.0.x 小版本之间，JSON_EXTRACT 和 ->> 对空值/缺失路径的返回值不统一。比如：
SELECT JSON_EXTRACT('{"a": null}','$.a') AS ex, '{"a": null}'->>'$.a' AS arrow, '{"b": 1}'->>'$.a' AS missing;
在主库返回 NULL、NULL、NULL；从库可能返回 NULL、''（空字符串）、''。这会导致 UPDATE SET json_col = json_col->>'$.foo' 在从库因类型不匹配失败（比如目标列是 INT，却试图塞入空字符串）。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
验证方法：在主从分别执行上面那条 SELECT，三列结果必须完全一致。不一致就说明存在隐式转换风险，不能直接复制。
关键参数必须主从严格一致
sql_mode 和 collation 差一个配置项，JSON 函数行为就可能翻车：
-
sql_mode必须完全相同：比如主库开了PIPES_AS_CONCAT，从库没开 → 含||的 JSON 构造表达式（如CONCAT('{"k":', val, '}')）在从库被当逻辑或运算，直接报错 -
JSON字段定义必须带COLLATE：主库建表写了meta JSON COLLATE utf8mb4_0900_as_cs，从库就必须一模一样。漏掉COLLATE会导致 emoji 或中文插入时触发Incorrect string value -
binlog_row_value_options要对齐：主库设了PARTIAL_JSON，但从库是 8.0.2 或更早 → 从库不认识新 binlog event 格式，直接中断。此时主库必须设为''（空字符串）禁用 partial update
临时修复和长期规避建议
临时止血可以跳过单条错误（SET GLOBAL sql_slave_skip_counter = 1），但治标不治本。真正要稳，得做这几件事：
- 升级从库到与主库**同小版本**（比如都是 8.0.32），避免解析器差异
- 所有 JSON 字段建表时强制声明
COLLATE utf8mb4_0900_as_cs，别依赖默认 - 主从
sql_mode用SELECT @@sql_mode对比，删掉从库多出的、主库没有的项 - 上线前跑一次 JSON 兼容性校验脚本：对典型 JSON 值（含
null键、嵌套数组、emoji、缺失路径）在主从执行JSON_VALID()和提取操作，比对结果
最易被忽略的一点：哪怕主从版本、参数全一致，如果从库表结构是手工 CREATE 出来的，而不是用 mysqldump --no-create-info 导出再导入，COLLATE 和 sql_mode 依赖很容易漏掉——这种“看起来一样”的表，才是复制中断的隐形炸弹。
