BR 恢复报错

这里介绍不了我 · 2025 年8 月 12 日 13:14

上下游集群版本一致都是 7.5.5 ，利用 BR 恢复集群报错：Error: [ddl:1115]Unknown character set: ‘utf8mb4’

TiDBer_sheldon · 2025 年8 月 13 日 00:45

Error: [ddl:1115]Unknown character set: ‘utf8mb4’ 问题应该是一个有关字符集兼容性问题。
可以在非生产环境，尝试：修改 TiDB 配置参数，设置默认字符集为 utf8。看看能不能解决

Kongdom · 2025 年8 月 13 日 01:05

上下游字符集一致么？
会不会是一个启用了新的，一个没启用新的？

这里介绍不了我 · 2025 年8 月 13 日 01:20

这个改过了，上下游都一致的，不然BR恢复直接会报这个参数不一致的错误

Kongdom · 2025 年8 月 13 日 01:23

是重新部署的集群么？这个参数只有在部署集群的时候才生效，后面再改是没效果的。

这里介绍不了我 · 2025 年8 月 13 日 01:24

是新部署的你不改成一致的 br 都导不进去的

db_user · 2025 年8 月 13 日 02:10

show variables like ‘%character%’;show variables like ‘%collation%’;上下游执行下这两个，看下结果

这里介绍不了我 · 2025 年8 月 13 日 02:21

主：

从：

TiDBer_xTvoCh2f · 2025 年8 月 13 日 02:27

手动执行一个测试下

db_user · 2025 年8 月 13 日 02:33

可以发下执行的命令和报错的日志么

这里介绍不了我 · 2025 年8 月 13 日 02:36

br restore full --pd xxx2379
–storage xxx
–s3.endpoint xxx
–s3.region ‘us-east-1’
–send-credentials-to-tikv=true
–log-file xxx
–checksum=false

db_user · 2025 年8 月 13 日 02:55

有个类似的issuse,但是显示已经合并并发布了，按理说不会有这个问题，你这个备份是什么时候备份的，备份的命令是什么，备份到现在这段时间字符集之类的有没有改过

Kongdom · 2025 年8 月 13 日 03:01

备份的集群是不是老版本升级上来的？

这里介绍不了我 · 2025 年8 月 13 日 03:06

昨天备份的，备份期间没有改过

这里介绍不了我 · 2025 年8 月 13 日 03:07

是的，备份的是个测试环境的集群，从老版本升级上来的

Kongdom · 2025 年8 月 13 日 03:19

br也是7.5.5吧？如果能拿到执行的ddl就好了，就能定位到是哪个表哪个语句了。

这里介绍不了我 · 2025 年8 月 13 日 03:37

是的关键看不到我打算拿 dumpling 等下试试

Kongdom · 2025 年8 月 13 日 03:56

嗯，试试吧，虽然也有类似问题，但是报错的字符集不是utf8mb4

这里介绍不了我 · 2025 年8 月 14 日 07:23

结帖，后面物理备份写脚本，按库恢复，确实发现有一个库恢复报错：Error: [ddl:1115]Unknown character set: ‘utf8mb4’ ，该库后面直接采取逻辑备份了，之后就可以正常cdc同步了

Kongdom · 2025 年8 月 14 日 07:28

会不会是库默认字符集是utf8，表字符集是utf8，然后字段的字符集设置为utf8mb4?
突然想到，会不会跟sql_mode有关，之前一遇到严格控制，就往这边想。