How to Forcefully Recover Two Clusters with Inconsistent new_collations_enabled_on_first_bootstrap Using BR

Translated
1

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: BR如何强制恢复new_collations_enabled_on_first_bootstrap不一致的两个集群

| username: wfxxh

[Test Environment for TiDB]
[TiDB Version] The upstream cluster was upgraded from v5.4.3 to v6.5.3, and the downstream was directly installed with v6.5.3.
[Encountered Problem: Phenomenon and Impact]
The upstream cluster was exported via BR, and the downstream could not be restored.

image
image1908×256 24.6 KB

2
| username: tidb菜鸟一只 | Original post link

Rebuild the downstream cluster and set this parameter to false?

3
| username: 啦啦啦啦啦 | Original post link

No, it won’t work. If it’s different, it can’t be restored or changed.

4
| username: WalterWj | Original post link

Cluster rebuild This parameter needs to be modified at the first startup to take effect.

5
| username: wfxxh | Original post link

Is there no way to force a restore?
Our main cluster is directly installed with v6.5.3, and the data was restored from the backup cluster (upgraded from v5.4.3 to v6.5.3) using TiDB Lightning.
We are now testing BR data from the backup cluster to the cold backup cluster (directly installed with v6.5.3), so we cannot modify new_collations_enabled_on_first_bootstrap.

6
| username: tidb菜鸟一只 | Original post link

It cannot be forcibly restored. If new_collations_enabled_on_first_bootstrap is different, the collation rules on both sides may be supported on one side and not on the other.

7
| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.