From 93fa8278477052ef9d3a878adc4384645c0b92b8 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Fri, 4 Sep 2020 13:16:39 +0800 Subject: [PATCH 1/4] cherry pick #3833 to release-3.1 Signed-off-by: ti-srebot --- br/backup-and-restore-tool.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/br/backup-and-restore-tool.md b/br/backup-and-restore-tool.md index 35aebc686c986..e590b6a63e6c8 100644 --- a/br/backup-and-restore-tool.md +++ b/br/backup-and-restore-tool.md @@ -11,9 +11,18 @@ aliases: ['/docs/v3.1/br/backup-and-restore-tool/','/docs/v3.1/reference/tools/b ## Usage restrictions - BR only supports TiDB v3.1 and later versions. -- Currently, TiDB does not support backing up and restoring partitioned tables. -- Currently, you can perform restoration only on new clusters. +- BR supports restore on clusters of different topologies. However, the online applications will be greatly impacted during the restore operation. It is recommended that you perform restore during the off-peak hours or use `rate-limit` to limit the rate. - It is recommended that you execute multiple backup operations serially. Otherwise, different backup operations might interfere with each other. +<<<<<<< HEAD +======= +- When BR restores data to the upstream cluster of TiCDC/Drainer, TiCDC/Drainer cannot replicate the restored data to the downstream. +- BR supports operations only between clusters with the same [`new_collations_enabled_on_first_bootstrap`](/character-set-and-collation.md#collation-support-framework) value because BR only backs up KV data. If the cluster to be backed up and the cluster to be restored use different collations, the data validation fails. Therefore, before restoring a cluster, make sure that the switch value from the query result of the `select VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME='new_collation_enabled';` statement is consistent with that during the backup process. + + - For v3.1 clusters, the new collation framework is not supported, so you can see it as disabled. + - For v4.0 clusters, check whether the new collation is enabled by executing `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME='new_collation_enabled';`. + + For example, assume that data is backed up from a v3.1 cluster and will be restored to a v4.0 cluster. The `new_collation_enabled` value of the v4.0 cluster is `true`, which means that the new collation is enabled in the cluster to be restored when this cluster is created. If you perform the restore in this situation, an error might occur. +>>>>>>> df470a4... Update BR restrictions (#3833) ## Recommended deployment configuration From e97feff18869efb734c9fb16572f2ddd654dc5a2 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Fri, 4 Sep 2020 13:20:30 +0800 Subject: [PATCH 2/4] Apply suggestions from code review --- br/backup-and-restore-tool.md | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/br/backup-and-restore-tool.md b/br/backup-and-restore-tool.md index e590b6a63e6c8..e40d2d95dd3db 100644 --- a/br/backup-and-restore-tool.md +++ b/br/backup-and-restore-tool.md @@ -11,18 +11,9 @@ aliases: ['/docs/v3.1/br/backup-and-restore-tool/','/docs/v3.1/reference/tools/b ## Usage restrictions - BR only supports TiDB v3.1 and later versions. -- BR supports restore on clusters of different topologies. However, the online applications will be greatly impacted during the restore operation. It is recommended that you perform restore during the off-peak hours or use `rate-limit` to limit the rate. +- Currently, you can perform restoration only on new clusters. - It is recommended that you execute multiple backup operations serially. Otherwise, different backup operations might interfere with each other. -<<<<<<< HEAD -======= -- When BR restores data to the upstream cluster of TiCDC/Drainer, TiCDC/Drainer cannot replicate the restored data to the downstream. -- BR supports operations only between clusters with the same [`new_collations_enabled_on_first_bootstrap`](/character-set-and-collation.md#collation-support-framework) value because BR only backs up KV data. If the cluster to be backed up and the cluster to be restored use different collations, the data validation fails. Therefore, before restoring a cluster, make sure that the switch value from the query result of the `select VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME='new_collation_enabled';` statement is consistent with that during the backup process. - - - For v3.1 clusters, the new collation framework is not supported, so you can see it as disabled. - - For v4.0 clusters, check whether the new collation is enabled by executing `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME='new_collation_enabled';`. - - For example, assume that data is backed up from a v3.1 cluster and will be restored to a v4.0 cluster. The `new_collation_enabled` value of the v4.0 cluster is `true`, which means that the new collation is enabled in the cluster to be restored when this cluster is created. If you perform the restore in this situation, an error might occur. ->>>>>>> df470a4... Update BR restrictions (#3833) +- When BR restores data to the upstream cluster of Drainer, Drainer cannot replicate the restored data to the downstream. ## Recommended deployment configuration From 006350f085433277afd5cb6f5bcdf69025e91c3e Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Fri, 4 Sep 2020 15:19:21 +0800 Subject: [PATCH 3/4] Update br/backup-and-restore-tool.md --- br/backup-and-restore-tool.md | 1 + 1 file changed, 1 insertion(+) diff --git a/br/backup-and-restore-tool.md b/br/backup-and-restore-tool.md index e40d2d95dd3db..580c3ae66f10c 100644 --- a/br/backup-and-restore-tool.md +++ b/br/backup-and-restore-tool.md @@ -15,6 +15,7 @@ aliases: ['/docs/v3.1/br/backup-and-restore-tool/','/docs/v3.1/reference/tools/b - It is recommended that you execute multiple backup operations serially. Otherwise, different backup operations might interfere with each other. - When BR restores data to the upstream cluster of Drainer, Drainer cannot replicate the restored data to the downstream. + ## Recommended deployment configuration - It is recommended that you deploy BR on the PD node. From 4a4f8f7a39f7f8bf4ef80ee00b290f9431905d02 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Fri, 4 Sep 2020 15:19:42 +0800 Subject: [PATCH 4/4] Update backup-and-restore-tool.md --- br/backup-and-restore-tool.md | 1 - 1 file changed, 1 deletion(-) diff --git a/br/backup-and-restore-tool.md b/br/backup-and-restore-tool.md index 580c3ae66f10c..e40d2d95dd3db 100644 --- a/br/backup-and-restore-tool.md +++ b/br/backup-and-restore-tool.md @@ -15,7 +15,6 @@ aliases: ['/docs/v3.1/br/backup-and-restore-tool/','/docs/v3.1/reference/tools/b - It is recommended that you execute multiple backup operations serially. Otherwise, different backup operations might interfere with each other. - When BR restores data to the upstream cluster of Drainer, Drainer cannot replicate the restored data to the downstream. - ## Recommended deployment configuration - It is recommended that you deploy BR on the PD node.