diff --git a/br/backup-and-restore-use-cases.md b/br/backup-and-restore-use-cases.md index 7ebca26fbaaf..2db07bef0a7e 100644 --- a/br/backup-and-restore-use-cases.md +++ b/br/backup-and-restore-use-cases.md @@ -346,17 +346,6 @@ bin/br restore table --db batchmark --table order_line -s local:///br_data/ --pd * 恢复吞吐:`avg speed(MB/s)` 从 `367.42` 提升到 `796.47` * 单个 TiKV 实例的吞吐:`avg speed(MB/s)`/`tikv_count` 从 `91.8` 提升到 `199.1` * 单个 TiKV 实例的平均恢复速度:`total size(MB)`/(`split time` + `restore time`)/`tikv_count` 从 `87.4` 提升到 `162.3` -#### 性能调优 - -在 restore 数据中存在大量的表,可以尝试增加参数 `--ddl-batch-size=128` 该参数在restore阶段并发的批量创建表(默认为 `0` 表示不批量创建表),示例如下: - -{{< copyable "shell-regular" >}} - -```shell -bin/br restore table --db batchmark --table order_line -s local:///br_data/ --pd 172.16.5.198:2379 --log-file restore-concurrency.log --concurrency 1024 --ddl-batch-size=128 -``` -* 此参数在数据恢复时,可以加速建表速度,测试显示6万张表恢复建表时间仅需几分钟 - ### 将单表数据备份到本地磁盘(推荐测试环境试用) 使用 `br backup 命令`,将单表数据 `--db batchmark --table order_line` 备份到指定的本地磁盘路径 `local:///home/tidb/backup_local` 下。 diff --git a/br/br-batch-create-table.md b/br/br-batch-create-table.md index 956432ea556e..a7f648b065c2 100644 --- a/br/br-batch-create-table.md +++ b/br/br-batch-create-table.md @@ -6,19 +6,23 @@ summary: 了解 BR 数据恢复批量建表功能,在集群 restore 的情况 # BR 批量建表 从 v6.0 版本开始引入 在 TiDB v6.0.0 之前,使用 BR 工具进行恢复任务时会使用的 TiDB 接口先做建库建表操作,而后进行数据恢复。在建表过程中,BR 调用 TiDB 接口,类似于 SQL 的 create table。对于恢复中大量的建表, 每个 SQL Create Table 由 TiDB ddl owner 依次串行执行。 -这导致表比较多的场景中,建表时间过长。 -为了减少恢复任务建表时间过长,从 TiDB v6.0.0 起,BR 引入了恢复批量建表功能,此功能会默认开启。BR 可以通过该功能加速建表,从而减少数据恢复的时间。 - +这导致表比较多的场景中,建表时间过长。为了减少恢复任务建表时间过长,从 TiDB v6.0.0 起,BR 引入了恢复批量建表功能,此功能会默认开启。BR 可以通过该功能加速建表,从而减少数据恢复的时间。 ## 使用场景 该功能默认打开,在表数量较多的时候,数据恢复效果较为明显。 ## 使用方法 -数据恢复批量建表功能默认打开,并默认设置 --ddl-batch-size=128 来恢复数据,无需额外配置。 +数据恢复批量建表功能默认打开,并默认设置 `--ddl-batch-size=128` 来恢复数据,无需额外配置。该参数在 restore 阶段并发的批量创建表。如需要关闭此功能,只需要设置 `--ddl-batch-size=0`, BR 会以老的方式来串行建表。 + +在 restore 数据中存在大量的表,可以尝试增加并发参数 `--concurrency=1024` 与 `--ddl-batch-size=256` 一起使用,示例如下: -如需要关闭此功能,只需要设置 --ddl-batch-size=0, BR 会以老的方式来串行建表。 +{{< copyable "shell-regular" >}} +```shell +bin/br restore table --db batchmark --table order_line -s local:///br_data/ --pd 172.16.5.198:2379 --log-file restore-concurrency.log --concurrency 1024 --ddl-batch-size=256 +``` +* 此参数在数据恢复时,可以加速建表速度,测试显示6万张表恢复建表时间仅需5分钟 ## 使用限制 @@ -26,21 +30,17 @@ summary: 了解 BR 数据恢复批量建表功能,在集群 restore 的情况 该功能的已知问题及其解决方案如下: -- BR 恢复存档时报错 `entry too large, the max entry size is 6291456, the size of data is 7690800`,该如何处理? -可以尝试降低并发大小,如设置 `--ddl-batch-size=128` 或者更小的值。 -当你已经设置了 `--ddl-batch-size` 参数值后,在使用 BR 恢复数据时,BR 会先调用内部接口 `BatchCreateTableWithInfo`,然后使用内部 DDL job `ActionCreateTables`,最后根据已设置的 `--ddl-batch-size` 的值来在 TiDB 建表。 -当 TiDB 执行这个 DDL job 时,TiDB 会把 job 队列写到 TiKV 上。由于 TiDB 能够一次性发送的 job message 默认的最大值为 6 MB(**不建议**修改此值),因此,单次发送的所有表的 schema 总和不可以超过 6 MB,否则,会报 `entry too large, the max entry size is 6291456, the size of data is 7690800` 错误。 +- BR 恢复存档时报错 `entry too large, the max entry size is 6291456, the size of data is 7690800`。 +可以尝试降低并发大小,如设置 `--ddl-batch-size=128` 或者更小的值。当你已经设置了 `--ddl-batch-size` 参数值后,在使用 BR 恢复数据时,BR 会先调用内部接口 `BatchCreateTableWithInfo`,然后使用内部 DDL job `ActionCreateTables`,最后根据已设置的 `--ddl-batch-size` 的值来在 TiDB 建表。当 TiDB 执行这个 DDL job 时,TiDB 会把 job 队列写到 TiKV 上。由于 TiDB 能够一次性发送的 job message 默认的最大值为 6 MB(**不建议**修改此值),因此,单次发送的所有表的 schema 总和不可以超过 6 MB,否则,会报 `entry too large, the max entry size is 6291456, the size of data is 7690800` 错误。 如需了解有关单个写入请求的数据量的具体限制,请参阅 TiDB 配置项 [txn-entry-size-limit](/tidb-configuration-file.md#txn-entry-size-limit-span-classversion-mark从-v50-版本开始引入span) 和 TiKV 配置项 [raft-entry-max-size](/tikv-configuration-file.md#raft-entry-max-size)。 - ## 实现原理 -在 v6.0.0 以前,BR使用老的建表方法,老的建表方法是类似于 SQL 层 create table, 每张表会引起一次 schema version 的变更, 每次 schema 变更需要 需要同步到其他 BR 和其他的 TiDB. -在 v6.0.0 及以后,数据恢复批量建表会按批来建表,每次建一批表且 TiDB schema version 变更一次。此方法极大的提高了建表速度。 - +在 v6.0.0 以前,BR使用老的建表方法,老的建表方法是类似于 SQL 层 create table, 每张表会引起一次 schema version 的变更, 每次 schema 变更需要 需要同步到其他 BR 和其他的 TiDB.在 v6.0.0 及以后,数据恢复批量建表会按批来建表,每次建一批表且 TiDB schema version 变更一次。此方法极大的提高了建表速度。 -以下集群配置测试结果 +### 以下集群配置测试结果 集群配置:15 个 TiKV 配备 16 个 CPU 80G 内存, 3个 TiDB, 3个 PD. -数据规模:16.16 TB 压缩后的数据 +数据规模:16.16TB 压缩后的数据 +TiKV [import.num-threads](/tikv-configuration-file.md#num-threads) 设置为 16 v6.0.0 测试结果 ‘[2022/03/12 22:37:49.060 +08:00] [INFO] [collector.go:67] ["Full restore success summary"] [total-ranges=751760] [ranges-succeed=751760] [ranges-failed=0] [split-region=1h33m18.078448449s] [restore-ranges=542693] [total-take=1h41m35.471476438s] [restore-data-size(after-compressed)=8.337TB] [Size=8336694965072] [BackupTS=431773933856882690] [total-kv=148015861383] [total-kv-size=16.16TB] [average-speed=2.661GB/s]’