From 4a6bfaf55b968f453d94cc9a37627af6f735923b Mon Sep 17 00:00:00 2001 From: Jianjun Liao Date: Fri, 30 Jan 2026 15:05:47 +0800 Subject: [PATCH 01/10] sys collation check Signed-off-by: Jianjun Liao --- br/backup-and-restore-overview.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index 00305ee8e8e41..630a64353e0ff 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -146,6 +146,8 @@ This section introduces the BR compatibility information for all [Long-Term Supp > **Note:** > > Known issue: Starting from version v7.2.0, some system table fields in newly created clusters are case-insensitive. However, for clusters that are **upgraded online** from versions earlier than v7.2.0 to v7.2.0 or later, the corresponding system table fields remain case-sensitive. Backup and restore operations involving system tables between these two types of clusters might fail. For more details, see [Issue #43717](https://github.com/pingcap/tidb/issues/43717). +> +> Starting from version 8.5.5, if the system table data of the source cluster version does not have case-sensitivity conflicts (for example, simultaneous records of test.t1 and test.T1), you can specify the BR parameter --sys-check-collation during restoration. BR will then check the compatibility of the data across different collations. If compatible, backups from older versions can be successfully restored; otherwise, BR will return an error. The following table lists the compatibility matrix for full backups. Note that all information in the table applies to newly created clusters. For clusters upgraded from a version earlier than v7.2.0 to v7.2.0 or later, their behavior is consistent with that of backups from v7.1.0. From 002fbb7c9041caed7b8d96cecb6b6c44b380f550 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Thu, 5 Feb 2026 21:38:50 +0800 Subject: [PATCH 02/10] Update br/backup-and-restore-overview.md --- br/backup-and-restore-overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index 630a64353e0ff..36c4b58c0ccf1 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -145,9 +145,9 @@ This section introduces the BR compatibility information for all [Long-Term Supp > **Note:** > -> Known issue: Starting from version v7.2.0, some system table fields in newly created clusters are case-insensitive. However, for clusters that are **upgraded online** from versions earlier than v7.2.0 to v7.2.0 or later, the corresponding system table fields remain case-sensitive. Backup and restore operations involving system tables between these two types of clusters might fail. For more details, see [Issue #43717](https://github.com/pingcap/tidb/issues/43717). +> - Known issue: Starting from version v7.2.0, some system table fields in newly created clusters are case-insensitive. However, for clusters that are **upgraded online** from versions earlier than v7.2.0 to v7.2.0 or later, the corresponding system table fields remain case-sensitive. Backup and restore operations involving system tables between these two types of clusters might fail. For more details, see [Issue #43717](https://github.com/pingcap/tidb/issues/43717). > -> Starting from version 8.5.5, if the system table data of the source cluster version does not have case-sensitivity conflicts (for example, simultaneous records of test.t1 and test.T1), you can specify the BR parameter --sys-check-collation during restoration. BR will then check the compatibility of the data across different collations. If compatible, backups from older versions can be successfully restored; otherwise, BR will return an error. +> - Starting from v8.5.5, if the system tables in the cluster do not contain case-conflicting records (for example, both `test.t1` and `test.T1`), you can specify the BR parameter` --sys-check-collation` during restore. BR checks whether the system table data is compatible across different collations. If it is compatible, BR can successfully restore backups from earlier versions; otherwise, BR reports an error and stops the restore. The following table lists the compatibility matrix for full backups. Note that all information in the table applies to newly created clusters. For clusters upgraded from a version earlier than v7.2.0 to v7.2.0 or later, their behavior is consistent with that of backups from v7.1.0. From a7bf969e85257dc48cefb2bb7b1617cbdc767ca3 Mon Sep 17 00:00:00 2001 From: Jianjun Liao Date: Mon, 9 Feb 2026 11:34:24 +0800 Subject: [PATCH 03/10] commit some suggestions Signed-off-by: Jianjun Liao --- br/backup-and-restore-overview.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index 36c4b58c0ccf1..6e598d1c2e9c2 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -147,7 +147,15 @@ This section introduces the BR compatibility information for all [Long-Term Supp > > - Known issue: Starting from version v7.2.0, some system table fields in newly created clusters are case-insensitive. However, for clusters that are **upgraded online** from versions earlier than v7.2.0 to v7.2.0 or later, the corresponding system table fields remain case-sensitive. Backup and restore operations involving system tables between these two types of clusters might fail. For more details, see [Issue #43717](https://github.com/pingcap/tidb/issues/43717). > -> - Starting from v8.5.5, if the system tables in the cluster do not contain case-conflicting records (for example, both `test.t1` and `test.T1`), you can specify the BR parameter` --sys-check-collation` during restore. BR checks whether the system table data is compatible across different collations. If it is compatible, BR can successfully restore backups from earlier versions; otherwise, BR reports an error and stops the restore. +> - Starting from v8.5.5, if the system tables in the cluster do not contain case-conflicting records (for example, both `test.t1` and `test.T1`), you can specify the BR parameter` --sys-check-collation` during restore. BR checks whether the system table data is compatible across different collations. If it is compatible, BR can successfully restore backups from earlier versions; otherwise, BR reports an error and stops the restore. If the upstream cluster still exists before the restore, you can manually execute the following three sets of SQL statements in the upstream cluster to verify data compatibility across different collations by confirming that the COUNT results are consistent: +> - SQL 1：SELECT COUNT(1) FROM mysql.db; +> - SQL 1：SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User FROM mysql.db GROUP BY Host, DB COLLATE utf8mb4_general_ci, User) as a; +> +> - SQL 2：SELECT COUNT(1) FROM mysql.tables_priv; +> - SQL 2：SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci FROM mysql.tables_priv GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci) as a; +> +> - SQL 3：SELECT COUNT(1) FROM mysql.columns_priv; +> - SQL 3：SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci, Column_name COLLATE utf8mb4_general_ci FROM mysql.columns_priv GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci, Column_name COLLATE utf8mb4_general_ci) as a; The following table lists the compatibility matrix for full backups. Note that all information in the table applies to newly created clusters. For clusters upgraded from a version earlier than v7.2.0 to v7.2.0 or later, their behavior is consistent with that of backups from v7.1.0. From a6dd46435e3be9a6fafae4e8f09aafca9fc4e812 Mon Sep 17 00:00:00 2001 From: houfaxin Date: Mon, 9 Feb 2026 12:09:04 +0800 Subject: [PATCH 04/10] Update backup-and-restore-overview.md --- br/backup-and-restore-overview.md | 35 +++++++++++++++++++++---------- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index 6e598d1c2e9c2..5972f0ce096b3 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -145,17 +145,30 @@ This section introduces the BR compatibility information for all [Long-Term Supp > **Note:** > -> - Known issue: Starting from version v7.2.0, some system table fields in newly created clusters are case-insensitive. However, for clusters that are **upgraded online** from versions earlier than v7.2.0 to v7.2.0 or later, the corresponding system table fields remain case-sensitive. Backup and restore operations involving system tables between these two types of clusters might fail. For more details, see [Issue #43717](https://github.com/pingcap/tidb/issues/43717). -> -> - Starting from v8.5.5, if the system tables in the cluster do not contain case-conflicting records (for example, both `test.t1` and `test.T1`), you can specify the BR parameter` --sys-check-collation` during restore. BR checks whether the system table data is compatible across different collations. If it is compatible, BR can successfully restore backups from earlier versions; otherwise, BR reports an error and stops the restore. If the upstream cluster still exists before the restore, you can manually execute the following three sets of SQL statements in the upstream cluster to verify data compatibility across different collations by confirming that the COUNT results are consistent: -> - SQL 1：SELECT COUNT(1) FROM mysql.db; -> - SQL 1：SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User FROM mysql.db GROUP BY Host, DB COLLATE utf8mb4_general_ci, User) as a; -> -> - SQL 2：SELECT COUNT(1) FROM mysql.tables_priv; -> - SQL 2：SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci FROM mysql.tables_priv GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci) as a; -> -> - SQL 3：SELECT COUNT(1) FROM mysql.columns_priv; -> - SQL 3：SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci, Column_name COLLATE utf8mb4_general_ci FROM mysql.columns_priv GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci, Column_name COLLATE utf8mb4_general_ci) as a; +> Known issue: Starting from version v7.2.0, some system table fields in newly created clusters are case-insensitive. However, for clusters that are **upgraded online** from versions earlier than v7.2.0 to v7.2.0 or later, the corresponding system table fields remain case-sensitive. Backup and restore operations involving system tables between these two types of clusters might fail. For more details, see [Issue #43717](https://github.com/pingcap/tidb/issues/43717). + +Starting from v8.5.5, if the system tables in the cluster do not contain case-conflicting records (for example, both `test.t1` and `test.T1`), you can specify the BR parameter` --sys-check-collation` during restore. BR checks whether the system table data is compatible across different collations. If it is compatible, BR can successfully restore backups from earlier versions; otherwise, BR reports an error and stops the restore. If the upstream cluster still exists before the restore, you can manually execute the following three sets of SQL statements in the upstream cluster to verify data compatibility across different collations by confirming that the COUNT results are consistent: + +SQL set 1: + +```sql +SELECT COUNT(1) FROM mysql.db; +SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User FROM mysql.db GROUP BY Host, DB COLLATE utf8mb4_general_ci, User) as a; +``` + +SQL set 2: + +```sql +SELECT COUNT(1) FROM mysql.tables_priv; +SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci FROM mysql.tables_priv GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci) as a; +``` + +SQL set 3: + +```sql +SELECT COUNT(1) FROM mysql.columns_priv; +SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci, Column_name COLLATE utf8mb4_general_ci FROM mysql.columns_priv GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci, Column_name COLLATE utf8mb4_general_ci) as a; +``` The following table lists the compatibility matrix for full backups. Note that all information in the table applies to newly created clusters. For clusters upgraded from a version earlier than v7.2.0 to v7.2.0 or later, their behavior is consistent with that of backups from v7.1.0. From 9059f6435b2c1419f25970a345421199426f7f45 Mon Sep 17 00:00:00 2001 From: houfaxin Date: Mon, 9 Feb 2026 13:32:25 +0800 Subject: [PATCH 05/10] Update backup-and-restore-overview.md --- br/backup-and-restore-overview.md | 46 ++++++++++++++++++++++++++----- 1 file changed, 39 insertions(+), 7 deletions(-) diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index 5972f0ce096b3..5438482bb5676 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -147,29 +147,61 @@ This section introduces the BR compatibility information for all [Long-Term Supp > > Known issue: Starting from version v7.2.0, some system table fields in newly created clusters are case-insensitive. However, for clusters that are **upgraded online** from versions earlier than v7.2.0 to v7.2.0 or later, the corresponding system table fields remain case-sensitive. Backup and restore operations involving system tables between these two types of clusters might fail. For more details, see [Issue #43717](https://github.com/pingcap/tidb/issues/43717). -Starting from v8.5.5, if the system tables in the cluster do not contain case-conflicting records (for example, both `test.t1` and `test.T1`), you can specify the BR parameter` --sys-check-collation` during restore. BR checks whether the system table data is compatible across different collations. If it is compatible, BR can successfully restore backups from earlier versions; otherwise, BR reports an error and stops the restore. If the upstream cluster still exists before the restore, you can manually execute the following three sets of SQL statements in the upstream cluster to verify data compatibility across different collations by confirming that the COUNT results are consistent: +
+Verify whether the system table data remains compatible under the target cluster's collation -SQL set 1: +Starting from v8.5.5, BR supports checking collation compatibility when restoring system tables by using the `--sys-check-collation` parameter. During restore, BR verifies whether the system table data remains compatible under the target cluster's collation. + +- If the data is compatible with the target collation, BR can successfully restore backups from earlier versions. +- If conflicts are detected (for example, both `test.t1` and `test.T1` exist), BR reports an error and terminates the restore. + +If the upstream cluster is still available before the restore, you can run the following SQL statements on the upstream cluster to perform a precheck on the system tables. By comparing the original row count with the row count after grouping under the target collation, you can determine whether conflicts would occur under the target collation. + +Replace `utf8mb4_general_ci` in the following SQL statements with the default collation of the target cluster. + +Group 1 ```sql SELECT COUNT(1) FROM mysql.db; -SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User FROM mysql.db GROUP BY Host, DB COLLATE utf8mb4_general_ci, User) as a; +SELECT COUNT(1) FROM ( + SELECT Host, DB COLLATE utf8mb4_general_ci, User + FROM mysql.db + GROUP BY Host, DB COLLATE utf8mb4_general_ci, User +) AS a; ``` -SQL set 2: +Group 2 ```sql SELECT COUNT(1) FROM mysql.tables_priv; -SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci FROM mysql.tables_priv GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci) as a; +SELECT COUNT(1) FROM ( + SELECT Host, DB COLLATE utf8mb4_general_ci, User, + Table_name COLLATE utf8mb4_general_ci + FROM mysql.tables_priv + GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, + Table_name COLLATE utf8mb4_general_ci +) AS a; ``` -SQL set 3: +Group 3 ```sql SELECT COUNT(1) FROM mysql.columns_priv; -SELECT COUNT(1) FROM (SELECT Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci, Column_name COLLATE utf8mb4_general_ci FROM mysql.columns_priv GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, Table_name COLLATE utf8mb4_general_ci, Column_name COLLATE utf8mb4_general_ci) as a; +SELECT COUNT(1) FROM ( + SELECT Host, DB COLLATE utf8mb4_general_ci, User, + Table_name COLLATE utf8mb4_general_ci, + Column_name COLLATE utf8mb4_general_ci + FROM mysql.columns_priv + GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, + Table_name COLLATE utf8mb4_general_ci, + Column_name COLLATE utf8mb4_general_ci +) AS a; ``` +If the two `COUNT` results are equal, no case-insensitive conflicts will occur under the target collation. + +
+ The following table lists the compatibility matrix for full backups. Note that all information in the table applies to newly created clusters. For clusters upgraded from a version earlier than v7.2.0 to v7.2.0 or later, their behavior is consistent with that of backups from v7.1.0. | Backup version | Compatible restore versions | Incompatible restore versions | From 1bd87aac756ed26139c4ae62e6df0af62980c337 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Wed, 11 Feb 2026 12:11:57 +0800 Subject: [PATCH 06/10] Update br/backup-and-restore-overview.md --- br/backup-and-restore-overview.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index 5438482bb5676..a6e2b57c1a94d 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -157,8 +157,6 @@ Starting from v8.5.5, BR supports checking collation compatibility when restorin If the upstream cluster is still available before the restore, you can run the following SQL statements on the upstream cluster to perform a precheck on the system tables. By comparing the original row count with the row count after grouping under the target collation, you can determine whether conflicts would occur under the target collation. -Replace `utf8mb4_general_ci` in the following SQL statements with the default collation of the target cluster. - Group 1 ```sql From abb1709ce508b4cb624866afab22e645b34a70b6 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Wed, 11 Feb 2026 15:44:48 +0800 Subject: [PATCH 07/10] Apply suggestions from code review --- br/backup-and-restore-overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index a6e2b57c1a94d..0aba3d0ae1320 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -148,9 +148,9 @@ This section introduces the BR compatibility information for all [Long-Term Supp > Known issue: Starting from version v7.2.0, some system table fields in newly created clusters are case-insensitive. However, for clusters that are **upgraded online** from versions earlier than v7.2.0 to v7.2.0 or later, the corresponding system table fields remain case-sensitive. Backup and restore operations involving system tables between these two types of clusters might fail. For more details, see [Issue #43717](https://github.com/pingcap/tidb/issues/43717).
-Verify whether the system table data remains compatible under the target cluster's collation +Check whether case conflicts exist under the target cluster collation -Starting from v8.5.5, BR supports checking collation compatibility when restoring system tables by using the `--sys-check-collation` parameter. During restore, BR verifies whether the system table data remains compatible under the target cluster's collation. +Starting from v8.5.5, BR supports checking collation compatibility when restoring system tables by using the `--sys-check-collation` parameter. During restore, BR checkes whether case conflicts exist under the target cluster collation. - If the data is compatible with the target collation, BR can successfully restore backups from earlier versions. - If conflicts are detected (for example, both `test.t1` and `test.T1` exist), BR reports an error and terminates the restore. From a6faac969f4d2a237113f558ca6d02f1b1b35ecc Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Fri, 13 Feb 2026 09:17:49 +0800 Subject: [PATCH 08/10] Update br/backup-and-restore-overview.md --- br/backup-and-restore-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index 0aba3d0ae1320..fee40ff75211e 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -145,7 +145,7 @@ This section introduces the BR compatibility information for all [Long-Term Supp > **Note:** > -> Known issue: Starting from version v7.2.0, some system table fields in newly created clusters are case-insensitive. However, for clusters that are **upgraded online** from versions earlier than v7.2.0 to v7.2.0 or later, the corresponding system table fields remain case-sensitive. Backup and restore operations involving system tables between these two types of clusters might fail. For more details, see [Issue #43717](https://github.com/pingcap/tidb/issues/43717). +> Known issue: Starting from v7.2.0, some system table fields in newly created clusters are case-insensitive. However, for clusters that are **upgraded online** from versions earlier than v7.2.0 to v7.2.0 or later, the corresponding system table fields remain case-sensitive. Backup and restore operations involving system tables between these two types of clusters might fail. For more details, see [Issue #43717](https://github.com/pingcap/tidb/issues/43717).
Check whether case conflicts exist under the target cluster collation From 1703f8a219a7aa42570ff29f8c4628f5e653d73d Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Fri, 13 Feb 2026 14:01:48 +0800 Subject: [PATCH 09/10] Update br/backup-and-restore-overview.md --- br/backup-and-restore-overview.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index fee40ff75211e..f3cd3047af600 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -150,10 +150,7 @@ This section introduces the BR compatibility information for all [Long-Term Supp
Check whether case conflicts exist under the target cluster collation -Starting from v8.5.5, BR supports checking collation compatibility when restoring system tables by using the `--sys-check-collation` parameter. During restore, BR checkes whether case conflicts exist under the target cluster collation. - -- If the data is compatible with the target collation, BR can successfully restore backups from earlier versions. -- If conflicts are detected (for example, both `test.t1` and `test.T1` exist), BR reports an error and terminates the restore. +Starting from v8.5.5, BR supports checking collation compatibility when restoring system tables by using the `--sys-check-collation` parameter. During restore, BR checkes whether case conflicts exist under the target cluster collation. If the data is compatible with the target collation, BR can successfully restore backups from earlier versions. Otherwise, BR reports an error and terminates the restore. If the upstream cluster is still available before the restore, you can run the following SQL statements on the upstream cluster to perform a precheck on the system tables. By comparing the original row count with the row count after grouping under the target collation, you can determine whether conflicts would occur under the target collation. From 796315365462bb7b07a334edddce0e8c468b376f Mon Sep 17 00:00:00 2001 From: houfaxin Date: Fri, 13 Feb 2026 14:07:22 +0800 Subject: [PATCH 10/10] Update backup-and-restore-overview.md --- br/backup-and-restore-overview.md | 53 ++----------------------------- 1 file changed, 2 insertions(+), 51 deletions(-) diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index f3cd3047af600..828cd1fac13ec 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -145,57 +145,8 @@ This section introduces the BR compatibility information for all [Long-Term Supp > **Note:** > -> Known issue: Starting from v7.2.0, some system table fields in newly created clusters are case-insensitive. However, for clusters that are **upgraded online** from versions earlier than v7.2.0 to v7.2.0 or later, the corresponding system table fields remain case-sensitive. Backup and restore operations involving system tables between these two types of clusters might fail. For more details, see [Issue #43717](https://github.com/pingcap/tidb/issues/43717). - -
-Check whether case conflicts exist under the target cluster collation - -Starting from v8.5.5, BR supports checking collation compatibility when restoring system tables by using the `--sys-check-collation` parameter. During restore, BR checkes whether case conflicts exist under the target cluster collation. If the data is compatible with the target collation, BR can successfully restore backups from earlier versions. Otherwise, BR reports an error and terminates the restore. - -If the upstream cluster is still available before the restore, you can run the following SQL statements on the upstream cluster to perform a precheck on the system tables. By comparing the original row count with the row count after grouping under the target collation, you can determine whether conflicts would occur under the target collation. - -Group 1 - -```sql -SELECT COUNT(1) FROM mysql.db; -SELECT COUNT(1) FROM ( - SELECT Host, DB COLLATE utf8mb4_general_ci, User - FROM mysql.db - GROUP BY Host, DB COLLATE utf8mb4_general_ci, User -) AS a; -``` - -Group 2 - -```sql -SELECT COUNT(1) FROM mysql.tables_priv; -SELECT COUNT(1) FROM ( - SELECT Host, DB COLLATE utf8mb4_general_ci, User, - Table_name COLLATE utf8mb4_general_ci - FROM mysql.tables_priv - GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, - Table_name COLLATE utf8mb4_general_ci -) AS a; -``` - -Group 3 - -```sql -SELECT COUNT(1) FROM mysql.columns_priv; -SELECT COUNT(1) FROM ( - SELECT Host, DB COLLATE utf8mb4_general_ci, User, - Table_name COLLATE utf8mb4_general_ci, - Column_name COLLATE utf8mb4_general_ci - FROM mysql.columns_priv - GROUP BY Host, DB COLLATE utf8mb4_general_ci, User, - Table_name COLLATE utf8mb4_general_ci, - Column_name COLLATE utf8mb4_general_ci -) AS a; -``` - -If the two `COUNT` results are equal, no case-insensitive conflicts will occur under the target collation. - -
+> - Known issue: Starting from v7.2.0, some system table fields in newly created clusters are case-insensitive. However, for clusters that are **upgraded online** from versions earlier than v7.2.0 to v7.2.0 or later, the corresponding system table fields remain case-sensitive. Backup and restore operations involving system tables between these two types of clusters might fail. For more details, see [Issue #43717](https://github.com/pingcap/tidb/issues/43717). +> - Starting from v8.5.5, BR supports checking collation compatibility when restoring system tables by using the `--sys-check-collation` parameter. During restore, BR checkes whether case conflicts exist under the target cluster collation. If the data is compatible with the target collation, BR can successfully restore backups from earlier versions. Otherwise, BR reports an error and terminates the restore. The following table lists the compatibility matrix for full backups. Note that all information in the table applies to newly created clusters. For clusters upgraded from a version earlier than v7.2.0 to v7.2.0 or later, their behavior is consistent with that of backups from v7.1.0.