【 TiDB 使用环境】测试
【 TiDB 版本】v6.5.3
【复现路径】做过哪些操作出现的问题
正常备份到s3
恢复时
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
恢复时报错：
错误码 1069 的具体含义是 “Error 1069: Too many keys specified; max 64 keys allowed”，意味着在创建索引或约束时指定的键数量超过了最大限制。
在 TiDB 中，每个表的索引和约束的键数量总和不能超过 64 个。 
3 个赞
你可以检查一下你的表定义，看看是否有多余或重复的键。另外，你也可以考虑使用复合键（composite key）来代替多个单独的键，以减少键的数量。
这里我觉得应该提个优化，在备份的时候可以提出警告提示信息，不然，备份成功，要是环境没了，恢复又不行，那不是完犊子了
索引数量超出限制了
是的呀，这就很搞人啊。备份成功，结果不让我恢复。我今天是在做灾备演练，因为之前Tidb的br也出过问题，就想着有几个月没有试试备份与恢复了。结果还真出问题了。可是我问了我们的开发，就得要这么多索引，有没有可以从数据库层面解决问题的方法，比如加大索引的数量，可以允许一个表有256个或者512个。现在我要是生产环境需要恢复，我就GG了
有没有可以从数据库层面解决问题的方法，比如加大索引的数量，可以允许一个表有256个或者512个。现在我要是生产环境需要恢复，我就GG了
啊 你表找到了么？看看表结构。。。。
还有，用这个命令确定下修改成功了没：show config where name like ‘%index%’;
哦对了，br 还原表结构应该不是执行的 SQL 文件，而是用 sst 灌入 tikv。所以你改数据库配置没有用，这个报错应该是 br 自己做的校验，我不太确定。
这个得去反馈区反馈下。
1 个赞
看一下你导出br版本跟导入的br版本是否一致？
导入的br版本最好一致，当然导入的br版本可以高于导出的br版本
谢谢你的回答，我已经确定是哪个表出的错，并且单独用这个表在我的新集群直接用sql脚本导入，没有报错，说明在tidb这一层，是没有阻止我建表的，同时也说明我的配置生效了，说明我修改配置成功了，为256，如下图：
为了进一步验证这个问题，我又创建一个新的集群，并将inde-limit设置为64，再执行那个表的导入，果然就报错了，那个表有66个索引。再一次验证了我的配置其实是生效了。就是被br这个工具做了阻拦，我查看了下源码，br这个工具的这个版本，if条件的右值似乎应该拿到的是默认的index-limit也就是64，所以报错也报的64，目前确定这是个bug。
1 个赞
是一致的，集群版本，工具版本都是一致的
大概率就是br的bug，没有正确的读取到我配置的index-linit
bug不至于，再找找原因吧。
bug可以社区反馈bug
好的，我试试。我正好趁这次机会升级一下tidb，我的operator和tidb的版本选哪个比较好，生产用
我将我的库升级到了v7.1.0，然后做了全量备份，然后全量恢复到一个新的集群（dr，也是v7.1.0），还是报这个错，这说明这个问题依旧没有解决呀