diff --git a/br/backup-and-restore-faq.md b/br/backup-and-restore-faq.md index 7d7a7684e132..dea6732dd03d 100644 --- a/br/backup-and-restore-faq.md +++ b/br/backup-and-restore-faq.md @@ -56,3 +56,11 @@ summary: BR 相关的常见问题以及解决方法。 备份的时候仅仅在每个 Region 的 Leader 处生成该 Region 的备份文件。因此备份的大小等于数据大小，不会有多余的副本数据。所以最终的总大小大约是 TiKV 数据总量除以副本数。 但是假如想要从本地恢复数据，因为每个 TiKV 都必须要能访问到所有备份文件，在最终恢复的时候会有等同于恢复时 TiKV 节点数量的副本。 + +## BR 恢复到 TiCDC / Drainer 的上游集群时，要注意些什么？ + ++ **BR 恢复的数据无法被同步到下游**，因为 BR 直接导入 SST 文件，而下游集群目前没有办法获得上游的 SST 文件。 + ++ 无法被同步到下游的恢复数据可能导致 TiCDC / Drainer 在执行 DDL 的时候发生异常。所以，如果一定要在 TiCDC / Drainer 的上游集群执行恢复，请将 BR 恢复的所有表加入 TiCDC / Drainer 的阻止名单。 + +TiCDC 可以通过配置项中的 [`filter.rules`](https://github.com/pingcap/ticdc/blob/7c3c2336f98153326912f3cf6ea2fbb7bcc4a20c/cmd/changefeed.toml#L16) 项完成，Drainer 则可以通过 [`syncer.ignore-table`](/tidb-binlog/tidb-binlog-configuration-file.md#ignore-table) 完成。 diff --git a/br/backup-and-restore-tool.md b/br/backup-and-restore-tool.md index da907d0263e3..2ce6baca8985 100644 --- a/br/backup-and-restore-tool.md +++ b/br/backup-and-restore-tool.md @@ -13,6 +13,16 @@ aliases: ['/docs-cn/v3.1/reference/tools/br/br/','/docs-cn/v3.1/how-to/maintain/ - BR 只支持 TiDB v3.1 及以上版本。 - 目前只支持在全新的集群上执行恢复操作。 - BR 备份最好串行执行，否则不同备份任务之间会相互影响。 +<<<<<<< HEAD +======= +- BR 恢复到 TiCDC / Drainer 的上游集群时，恢复数据无法由 TiCDC / Drainer 同步到下游。 +- BR 只支持在 `new_collations_enabled_on_first_bootstrap` [开关值](/character-set-and-collation.md#排序规则支持)相同的集群之间进行操作。这是因为 BR 仅备份 KV 数据。如果备份集群和恢复集群采用不同的排序规则，数据校验会不通过。所以恢复集群时，你需要确保 `select VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME='new_collation_enabled';` 语句的开关值查询结果与备份时的查询结果相一致，才可以进行恢复。 + + - 对于 v3.1 集群，TiDB 尚未支持 new collation，因此可以认为 new collation 未打开 + - 对于 v4.0 集群，请通过 `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME='new_collation_enabled';` 查看 new collation 是否打开。 + + 例如，数据备份在 v3.1 集群。如果恢复到 v4.0 集群中，查询恢复集群的 `new_collation_enabled` 的值为 `true`，则说明创建恢复集群时打开了 new collation 支持的开关。此时恢复数据，可能会出错。 +>>>>>>> f839d57... br: add use constraint with CDC and drainer (#3750) ## 推荐部署配置