【 TiDB 版本】v6.5.2
前提：
旧集群是从v5.1.4升级到v6.5.2,新集群直接部署的v6.5.2
通过RESTORE DATABASE恢复数据的时候，报错：
mysql> RESTORE DATABASE * FROM ‘local:///disk1/tidb_backup’;
ERROR 8125 (HY000): Restore failed: the config ‘new_collations_enabled_on_first_bootstrap’ not match, upstream:False, downstream: True: [BR:Common:ErrUnknown]internal error
查看文档，说是因为从v5.1.4升级到v6.5.2的集群mysql.tidb中的new_collation_enabled的配置不一样。
这种情况，改怎么进行备份恢复呢？
导出备份
mysqldump backup.sql
mysql < backup.sql
dumpling导出
和lightling导入
6.0之前的版本确实都是默认false的，但此功能从4.0就有了
TiDB 6.0 引入了新的 Collation 规则，并将默认启用新 Collation 框架。新 Collation 规则已在 TiDB 4.0 引入，但一直都是默认关闭项，只有集群初始化时才能变更。可通过系统表看到该变量值的设定。
select * from mysql.tidb where variable_name = 'new_collation_enabled';
使用 BR 进行数据备份、恢复时，也需要注意 Collation 的设置，保证备份前、恢复后的集群设置相同，防止出现因配置项new_collations_enabled_on_first_bootstrap 设定不同而报错
不知道能不能变更参数值通过重启生效？要不你试试能生效不？
service_configs:
tidb:
new_collations_enabled_on_first_bootstrap: true
无法通过重启生效
老版本只有逻辑备份跟逻辑导出一种办法
使用dumpling和lightling导出和导入，是不是也需要忽略掉mysql库？
默认情况下，Dumpling 会导出排除系统数据库（包括 mysql 、sys 、INFORMATION_SCHEMA 、PERFORMANCE_SCHEMA 、METRICS_SCHEMA 和 INSPECTION_SCHEMA ）外所有其他数据库
默认忽略
有一种方法，新集群先搭建低版本的，然后升级下。这样是不是就解决了参数不同的这个问题
用逻辑备份和 lightning local 还原。
dumpling导出
lightling导入
新集群重新初始化一下，new_collation_enabled设置为false
v4.0 新增了配置开关 new_collations_enabled_on_first_bootstrap ，从语义上支持了排序规则，只能在集群初次初始化时决定是否启用新排序规则框架。从 v6.0.0开始默认值由 false 改为 true，兼容MySQL大小写不敏感比较等情况。对已初始化完成的集群，可以通过 mysql.tidb 表中的 new_collation_enabled 变量确认，详情请看 字符集和排序规则
RESTORE 是用于执行分布式恢复，把 BACKUP 语句生成的备份文件恢复到 TiDB 集群中。其使用的引擎与 BR 相同，也就是说是物理备份和恢复操作。
所以，要解决你这个问题，有两个方案：
- 方案1:：调整新集群使用的排序规则框架，使得和上游旧集群保持一致。
- 这个操作需要销毁和重建新集群。
- 方案2：不使用物理备份，使用逻辑备份和恢复。
- dumpling+lightning工具可以帮你实现数据导入导出。
2 个赞
我们这边刚遇到的，新集群重装为版本v5.1.4，然后升级到v6.5.2，最后再还原，这样应该就可以了。
1 个赞
dumpling导出
和lightling导入
哈哈，咱们一样的版本
那你这个5.1.4升级到6.5.2之后这个排序规则参数变了吗？
参数值变了，自动由false变成了true，但是没有生效，执行的还是false，因为这个配置在初始化的时候才生效。
2 个赞