br 备份恢复报错，遇到column too manys的错误

🪐 TiDB 技术问题 备份&数据迁移
1

【 TiDB 版本】TIDB 5.4

【遇到的问题：问题现象及影响】

TiDB备份的数据库实例存在一张宽表，字段数量大于1017个，在执行restore 之前，已经对TiDB的table-column-count-limit进行了调整，调整至4096，执行br restore 还是遇到了column too manys的错误。

这张宽表在目标数据库的table-column-count-limit 调整到4096，手动去创建是没有问题的，所以BR备份还需要有什么参数需要设置么？

【附件：截图/日志/监控】
错误日志如下：
I0220 06:32:24.743893 8 restore.go:90] [2023/02/20 06:32:24.743 +00:00] [ERROR] [main.go:58] [“br failed”] [error=“[ddl:1117]Too many columns”] [errorVerbose=“[ddl:1117]Too many columns\ngithub.com/pingcap/errors.AddStack\n\t/nfs/cache/mod/github.com/pingcap/errors@v0.11.5-0.20211224045212-9687c2b0f87c/errors.go:174\ngithub.com/pingcap/errors.Trace\n\t/nfs/cache/mod/github.com/pingcap/errors@v0.11.5-0.20211224045212-9687c2b0f87c/juju_adaptor.go:15\ngithub.com/pingcap/tidb/ddl.checkTableInfoValidExtra\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/br/ddl/ddl_api.go:1711\ngithub.com/pingcap/tidb/ddl.(*ddl).CreateTableWithInfo\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/br/ddl/ddl_api.go:2077\ngithub.com/pingcap/tidb/br/pkg/gluetidb.(*tidbSession).CreateTable\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/br/br/pkg/gluetidb/glue.go:146\ngithub.com/pingcap/tidb/br/pkg/restore.(*DB).CreateTable\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/br/br/pkg/restore/db.go:129\ngithub.com/pingcap/tidb/br/pkg/restore.(*Client).createTable\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/br/br/pkg/restore/client.go:415\ngithub.com/pingcap/tidb/br/pkg/restore.(*Client).GoCreateTables.func1\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/br/br/pkg/restore/client.go:468\ngithub.com/pingcap/tidb/br/pkg/restore.(*Client).createTablesWithDBPool.func1\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/br/br/pkg/restore/client.go:523\ngithub.com/pingcap/tidb/br/pkg/utils.(*WorkerPool).ApplyWithIDInErrorGroup.func1\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/br/br/pkg/utils/worker.go:82\ngolang.org/x/sync/errgroup.(*Group).Go.func1\n\t/nfs/cache/mod/golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c/errgroup/errgroup.go:57\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1371”] [stack=“main.main\n\t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/br/br/cmd/br/main.go:58\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:225”]

2

估计是br版本的问题，建议升级br版本

3

如果是版本问题，能贴一下TiDB该问题的issues么

4

感觉非预期，看起来数据库限制调整了，但是 br 有自己的限制检查 :thinking:

5

哪里有调整呀，看了一下源码，在执行ddl操作之前，load了目标端的config，也没有修改相关的参数

6

我也没找到 推荐你去反馈区反馈下，看看是不是当前产品确实有这部分问题。

如果有，但是没有绕过方案的话只能等产品来做了。:thinking:

7

看起来 table-column-count-limit 这个参数是 tidb-server 本地的配置（而非 GLOBAL VARIABLE 一类的），同时这个检查看起来并不是在 DDL owner 上做的（看堆栈是 BR 的）。
BR 进程内嵌了一个 tidb-server 来执行 DDL 相关操作，但是目前这个 server 的配置并不会和其他 server 同步（而且大概也没啥好办法同步，我猜的），所以在其他 TiDB 节点上增加 table-column-count-limit 并不能解决这个问题。
作为 workaround，可以考虑一下提前将你需要的表通过修改过 table-column-count-limit 的 TiDB 节点建好，这样 BR 就不会尝试建这张表，应该也就不会报错了。

8

另一个可能的 workaround 是在修改过 table-column-count-limit 的 TiDB 节点上使用 RESTORE SQL 恢复。