diff --git a/br/backup-and-restore-design.md b/br/backup-and-restore-design.md index 4c3a48aa625f..2bf7d685d97b 100644 --- a/br/backup-and-restore-design.md +++ b/br/backup-and-restore-design.md @@ -5,7 +5,7 @@ summary: 了解 TiDB 的备份与恢复功能的架构设计。 # TiDB 备份与恢复功能架构概述 -正如 [TiDB 备份与恢复概述](/br/backup-and-restore-overview.md)所介绍，TiDB 备份恢复功能包含了多种不同类型的集群数据对象的备份与恢复实现。这些功能都以 BR 和 TiDB Operator 为使用入口，创建相应的任务从 TiKV 节点上备份数据，或者恢复数据到 TiKV 节点。 +正如 [TiDB 备份与恢复概述](/br/backup-and-restore-overview.md)所介绍，TiDB 备份恢复功能包含了多种不同类型的集群数据对象的备份与恢复实现。这些功能都以 Backup & Restore (BR) 和 TiDB Operator 为使用入口，创建相应的任务从 TiKV 节点上备份数据，或者恢复数据到 TiKV 节点。 关于各种备份恢复功能的实现架构，请参考以下链接： diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index f0c4bdfcfdd1..bc340dc98e9c 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -6,7 +6,7 @@ aliases: ['/docs-cn/dev/br/backup-and-restore-tool/','/docs-cn/dev/reference/too # TiDB 备份与恢复概述 -基于 Raft 协议和合理的部署拓扑规划，TiDB 实现了集群的高可用，当集群中少数节点挂掉时，集群依然能对外提供服务。在此基础上，为了更进一步保证用户数据的安全，TiDB 还提供了集群的备份与恢复功能，作为数据安全的最后一道防线，使得集群能够免于严重的自然灾害，提供业务误操作“复原”的能力。 +基于 Raft 协议和合理的部署拓扑规划，TiDB 实现了集群的高可用，当集群中少数节点挂掉时，集群依然能对外提供服务。在此基础上，为了更进一步保证用户数据的安全，TiDB 还提供了集群的备份与恢复 (Backup & Restore, BR) 功能，作为数据安全的最后一道防线，使得集群能够免于严重的自然灾害，提供业务误操作“复原”的能力。 TiDB 备份恢复功能可以用于满足以下业务的需求： @@ -61,7 +61,7 @@ TiDB 备份恢复功能可以用于满足以下业务的需求： - 恢复到集群的历史任意时间点 (PITR) - - 通过 `br restore point` 功能。你可以指定要恢复的时间点，恢复时间点之前最近的快照数据备份，以及日志备份数据。br 会自动判断和读取恢复需要的数据，然后将这些数据依次恢复到指定的集群。 + - 通过 `br restore point` 功能。你可以指定要恢复的时间点，恢复时间点之前最近的快照数据备份，以及日志备份数据。BR 会自动判断和读取恢复需要的数据，然后将这些数据依次恢复到指定的集群。 #### 恢复的性能 @@ -102,17 +102,17 @@ TiDB 支持将数据备份到 Amazon S3、Google Cloud Storage (GCS)、Azure Blo ### 兼容性 -在使用 BR 之前，需要先了解 BR 与其他功能的兼容性以及使用限制。 +在使用备份恢复功能之前，需要先了解 BR 工具与其他功能的兼容性以及使用限制。 #### 与其他功能的兼容性 -某些功能在开启或关闭状态下，会导致 BR 功能使用出错。因此需要保证恢复集群的这些配置，与备份集群备份时的配置相同。 +某些功能在开启或关闭状态下，会导致备份恢复功能使用出错。因此需要保证恢复集群的这些配置，与备份集群备份时的配置相同。 | 功能 | 相关 issue | 解决方式 | | ---- | ---- | ----- | |GBK charset|| BR 在 v5.4.0 之前不支持恢复 `charset=GBK` 的表。并且，任何版本的 BR 都不支持恢复 `charset=GBK` 的表到 v5.4.0 之前的 TiDB 集群。| | 聚簇索引 | [#565](https://github.com/pingcap/br/issues/565) | 确保恢复时集群的 `tidb_enable_clustered_index` 全局变量和备份时一致，否则会导致数据不一致的问题，例如 `default not found` 和数据索引不一致。 | -| New collation | [#352](https://github.com/pingcap/br/issues/352) | 确保恢复时集群的 `new_collations_enabled_on_first_bootstrap` 变量值和备份时的一致，否则会导致数据索引不一致和 checksum 通不过。更多信息，请参考 [FAQ - BR 为什么会报 `new_collations_enabled_on_first_bootstrap` 不匹配？](/faq/backup-and-restore-faq.md#br-为什么会报-new_collations_enabled_on_first_bootstrap-不匹配)。 | +| New collation | [#352](https://github.com/pingcap/br/issues/352) | 确保恢复时集群的 `new_collations_enabled_on_first_bootstrap` 变量值和备份时的一致，否则会导致数据索引不一致和 checksum 通不过。更多信息，请参考 [FAQ - BR 为什么会报 `new_collations_enabled_on_first_bootstrap` 不匹配？](/faq/backup-and-restore-faq.md#恢复时为什么会报-new_collations_enabled_on_first_bootstrap-不匹配)。 | | 全局临时表 | | 确保使用 BR v5.3.0 及以上版本进行备份和恢复，否则会导致全局临时表的表定义错误。 | | TiDB Lightning Physical Import| |上游数据库使用 TiDB Lightning Physical 方式导入的数据，无法作为数据日志备份下来。推荐在数据导入后执行一次全量备份，细节参考[上游数据库使用 TiDB Lightning Physical 方式导入数据的恢复](/faq/backup-and-restore-faq.md#上游数据库使用-tidb-lightning-physical-方式导入数据时为什么无法使用日志备份功能)。| diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md index 6f130e84bfcf..8cab60b4c4df 100644 --- a/br/backup-and-restore-storages.md +++ b/br/backup-and-restore-storages.md @@ -88,14 +88,14 @@ TiDB 支持 Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 和 NFS ```shell ./br backup full --pd "${PD_IP}:2379" \ ---storage 'gcs://external/backup-20220915?credentials-file=${credentials-file-path}' +--storage "gcs://external/backup-20220915?credentials-file=${credentials_file_path}" ``` **从 GCS 恢复快照备份数据** ```shell ./br restore full --pd "${PD_IP}:2379" \ ---storage 'gcs://external/backup-20220915?credentials-file=${credentials-file-path}' +--storage "gcs://external/backup-20220915?credentials-file=${credentials_file_path}" ``` @@ -105,14 +105,14 @@ TiDB 支持 Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 和 NFS ```shell ./br backup full -u "${PD_IP}:2379" \ ---storage "azure://external/backup-20220915?account-name=${account name}&account-key=${account key}" +--storage "azure://external/backup-20220915?account-name=${account_name}&account-key=${account_key}" ``` **从 Azure Blob Storage 恢复快照备份数据中 `test` 数据库** ```shell ./br restore db --db test -u "${PD_IP}:2379" \ ---storage "azure://external/backup-20220915account-name=${account name}&account-key=${account key}" +--storage "azure://external/backup-20220915account-name=${account_name}&account-key=${account_key}" ``` @@ -125,10 +125,10 @@ TiDB 支持 Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 和 NFS
-在备份之前，需要为 BR 访问 Amazon S3 中的备份目录设置相应的访问权限： +在备份之前，需要为 br 命令行工具访问 Amazon S3 中的备份目录设置相应的访问权限： -- 备份时 TiKV 和 BR 需要的访问备份数据目录的最小权限：`s3:ListBucket`、`s3:PutObject` 和 `s3:AbortMultipartUpload`。 -- 恢复时 TiKV 和 BR 需要的访问备份数据目录的最小权限：`s3:ListBucket` 和 `s3:GetObject`。 +- 备份时 TiKV 和 br 命令行工具需要的访问备份数据目录的最小权限：`s3:ListBucket`、`s3:PutObject` 和 `s3:AbortMultipartUpload`。 +- 恢复时 TiKV 和 br 命令行工具需要的访问备份数据目录的最小权限：`s3:ListBucket` 和 `s3:GetObject`。 如果你还没有创建备份数据保存目录，可以参考 [创建存储桶](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/user-guide/create-bucket.html)在指定的区域中创建一个 S3 存储桶。如果需要使用文件夹，可以参考 [使用文件夹在 Amazon S3 控制台中组织对象](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/user-guide/create-folder.html)在存储桶中创建一个文件夹。 @@ -138,14 +138,14 @@ TiDB 支持 Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 和 NFS 如果指定访问密钥和秘密访问密钥，将按照指定的访问密钥和秘密访问密钥进行鉴权。除了在 URL 中指定密钥外，还支持以下方式： - - BR 读取 `$AWS_ACCESS_KEY_ID` 和 `$AWS_SECRET_ACCESS_KEY` 环境变量 - - BR 读取 `$AWS_ACCESS_KEY` 和 `$AWS_SECRET_KEY` 环境变量 - - BR 读取共享凭证文件，路径由 `$AWS_SHARED_CREDENTIALS_FILE` 环境变量指定 - - BR 读取共享凭证文件，路径为 `~/.aws/credentials` + - br 命令行工具读取 `$AWS_ACCESS_KEY_ID` 和 `$AWS_SECRET_ACCESS_KEY` 环境变量 + - br 命令行工具读取 `$AWS_ACCESS_KEY` 和 `$AWS_SECRET_KEY` 环境变量 + - br 命令行工具读取共享凭证文件，路径由 `$AWS_SHARED_CREDENTIALS_FILE` 环境变量指定 + - br 命令行工具读取共享凭证文件，路径为 `~/.aws/credentials` - 方式二：基于 IAM Role 进行访问 - 为运行 TiKV 和 BR 的 EC2 实例关联一个配置了访问 S3 访问权限的 IAM role。正确设置后，BR 可以直接访问对应的 S3 中的备份目录，而不需要额外的设置。 + 为运行 TiKV 和 br 命令行工具的 EC2 实例关联一个配置了访问 S3 访问权限的 IAM role。正确设置后，br 命令行工具可以直接访问对应的 S3 中的备份目录，而不需要额外的设置。 ```shell br backup full --pd "${PD_IP}:2379" \ @@ -157,8 +157,8 @@ TiDB 支持 Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 和 NFS 配置访问 GCS 的账户可以通过指定访问密钥的方式。如果指定了 `credentials-file` 参数，将按照指定的 `credentials-file` 进行鉴权。除了在 URL 中指定密钥文件外，还支持以下方式： -- BR 读取位于 `$GOOGLE_APPLICATION_CREDENTIALS` 环境变量所指定路径的文件内容 -- BR 读取位于 `~/.config/gcloud/application_default_credentials.json` 的文件内容 +- br 命令行工具读取位于 `$GOOGLE_APPLICATION_CREDENTIALS` 环境变量所指定路径的文件内容 +- br 命令行工具读取位于 `~/.config/gcloud/application_default_credentials.json` 的文件内容 - 在 GCE 或 GAE 中运行时，从元数据服务器中获取的凭证
@@ -166,11 +166,11 @@ TiDB 支持 Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 和 NFS - 方式一：指定访问密钥 - 在 URL 配置 `account-name` 和 `account-key`，则使用该参数指定的密钥。除了在 URL 中指定密钥文件外，还支持 BR 读取 `$AZURE_STORAGE_KEY` 的方式。 + 在 URL 配置 `account-name` 和 `account-key`，则使用该参数指定的密钥。除了在 URL 中指定密钥文件外，还支持 br 命令行工具读取 `$AZURE_STORAGE_KEY` 的方式。 - 方式二：使用 Azure AD 备份恢复 - 在 BR 运行环境配置环境变量 `$AZURE_CLIENT_ID`、`$AZURE_TENANT_ID` 和 `$AZURE_CLIENT_SECRET`。 + 在 br 命令行工具运行环境配置环境变量 `$AZURE_CLIENT_ID`、`$AZURE_TENANT_ID` 和 `$AZURE_CLIENT_SECRET`。 - 当集群使用 TiUP 启动时，TiKV 会使用 systemd 服务。以下示例介绍如何为 TiKV 配置上述三个环境变量： @@ -200,7 +200,7 @@ TiDB 支持 Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 和 NFS systemctl restart tikv-24000 ``` - - 为命令行启动的 TiKV 和 BR 配置 Azure AD 的信息，只需要确定运行环境中存在 `$AZURE_CLIENT_ID`、`$AZURE_TENANT_ID` 和 `$AZURE_CLIENT_SECRET`。通过运行下列命令行，可以确认 BR 和 TiKV 运行环境中是否存在这三个环境变量： + - 为命令行启动的 TiKV 和 br 命令行工具配置 Azure AD 的信息，只需要确定运行环境中存在 `$AZURE_CLIENT_ID`、`$AZURE_TENANT_ID` 和 `$AZURE_CLIENT_SECRET`。通过运行下列命令行，可以确认 br 命令行工具和 TiKV 运行环境中是否存在这三个环境变量： ```shell echo $AZURE_CLIENT_ID @@ -208,11 +208,11 @@ TiDB 支持 Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 和 NFS echo $AZURE_CLIENT_SECRET ``` - - 使用 BR 将数据备份至 Azure Blob Storage： + - 使用 br 命令行工具将数据备份至 Azure Blob Storage： ```shell ./br backup full -u "${PD_IP}:2379" \ - --storage "azure://external/backup-20220915?account-name=${account name}" + --storage "azure://external/backup-20220915?account-name=${account_name}" ``` @@ -222,8 +222,8 @@ TiDB 支持 Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 和 NFS ### Amazon S3 存储服务端加密备份数据 -BR 支持对备份到 Amazon S3 的数据进行 S3 服务端加密 (SSE)。BR S3 服务端加密也支持使用用户自行创建的 AWS KMS 密钥，详细信息请参考 [BR S3 服务端加密](/encryption-at-rest.md#br-s3-服务端加密)。 +TiDB 备份恢复功能支持对备份到 Amazon S3 的数据进行 S3 服务端加密 (SSE)。S3 服务端加密也支持使用用户自行创建的 AWS KMS 密钥，详细信息请参考 [BR S3 服务端加密](/encryption-at-rest.md#br-s3-服务端加密)。 ## 存储服务其他功能支持 - 从 v6.3.0 起，BR 支持 AWS S3 Object Lock 功能。你可以在 AWS 中开启 [S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) 功能来防止备份数据写入后被修改或者删除。 +TiDB 备份恢复功能从 v6.3.0 支持 AWS S3 Object Lock 功能。你可以在 AWS 中开启 [S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) 功能来防止备份数据写入后被修改或者删除。 diff --git a/br/backup-and-restore-use-cases.md b/br/backup-and-restore-use-cases.md index d0965a2a0b2e..78b222c4fcb3 100644 --- a/br/backup-and-restore-use-cases.md +++ b/br/backup-and-restore-use-cases.md @@ -15,9 +15,9 @@ aliases: ['/docs-cn/dev/br/backup-and-restore-use-cases/','/docs-cn/dev/referenc 通过 TiDB 提供的 PITR 功能，你可以满足业务团队的需求。 -## 部署 TiDB 集群和 BR +## 部署 TiDB 集群和 br 命令行工具 -使用 PITR 功能，需要部署 v6.2.0 或以上版本的 TiDB 集群，并且更新 BR 到与 TiDB 集群相同的版本，本文假设使用的是 v6.4.0 版本。 +使用 PITR 功能，需要部署 v6.2.0 或以上版本的 TiDB 集群，并且更新 br 命令行工具到与 TiDB 集群相同的版本，本文假设使用的是 v6.4.0 版本。 下表介绍了在 TiDB 集群中使用日志备份功能的推荐配置。 @@ -26,20 +26,20 @@ aliases: ['/docs-cn/dev/br/backup-and-restore-use-cases/','/docs-cn/dev/referenc | TiDB | 8 核+ | 16 GB+ | SAS | c5.2xlarge | 2 | | PD | 8 核+ | 16 GB+ | SSD | c5.2xlarge | 3 | | TiKV | 8 核+ | 32 GB+ | SSD | m5.2xlarge | 3 | -| BR | 8 核+ | 16 GB+ | SAS | c5.2xlarge | 1 | +| br cli | 8 核+ | 16 GB+ | SAS | c5.2xlarge | 1 | | 监控 | 8 核+ | 16 GB+ | SAS | c5.2xlarge | 1 | > **注意：** > -> - BR 执行备份恢复功能需要访问 PD 和 TiKV，请确保 BR 与所有 PD 和 TiKV 连接正常。 -> - BR 与 PD 所在服务器时区需要相同。 +> - br 命令行工具执行备份恢复功能需要访问 PD 和 TiKV，请确保 br 命令行工具与所有 PD 和 TiKV 连接正常。 +> - br 命令行工具与 PD 所在服务器时区需要相同。 使用 TiUP 部署或升级 TiDB 集群： - 如果没有部署 TiDB 集群，请[部署 TiDB 集群](/production-deployment-using-tiup.md)。 - 如果已经部署的 TiDB 集群版本低于 v6.2.0，请[升级 TiDB 集群](/upgrade-tidb-using-tiup.md)。 -使用 TiUP 安装或升级 BR： +使用 TiUP 安装或升级 br 命令行工具： - 安装： @@ -68,10 +68,10 @@ aliases: ['/docs-cn/dev/br/backup-and-restore-use-cases/','/docs-cn/dev/referenc 1. 创建 bucket。你也可以选择已有的 S3 bucket 来保存备份数据。如果没有可用的 bucket，可以参照 [AWS 官方文档](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/user-guide/create-bucket.html)创建一个 S3 Bucket。本文使用的 bucket 名为 `tidb-pitr-bucket`。 2. 创建备份数据总目录。在上一步创建的 bucket（例如 `tidb-pitr-bucket`）下创建目录 `backup-data`，参考 [AWS 官方文档](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/user-guide/create-folder.html)。 -2. 配置 BR 和 TiKV 访问 S3 中的备份目录的权限。本文推荐使用最安全的 IAM 访问方式，配置过程可以参考[控制存储桶访问](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/userguide/walkthrough1.html)。权限要求如下： +2. 配置 br 命令行工具和 TiKV 访问 S3 中的备份目录的权限。本文推荐使用最安全的 IAM 访问方式，配置过程可以参考[控制存储桶访问](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/userguide/walkthrough1.html)。权限要求如下： - - 备份集群的 TiKV 和 BR 需要的 `s3://tidb-pitr-bucket/backup-data` 权限：`s3:ListBucket`、`s3:PutObject` 和 `s3:AbortMultipartUpload`。 - - 恢复集群的 TiKV 和 BR 需要 `s3://tidb-pitr-bucket/backup-data` 的最小权限：`s3:ListBucket` 和 `s3:GetObject`。 + - 备份集群的 TiKV 和 br 命令行工具需要的 `s3://tidb-pitr-bucket/backup-data` 权限：`s3:ListBucket`、`s3:PutObject` 和 `s3:AbortMultipartUpload`。 + - 恢复集群的 TiKV 和 br 命令行工具需要 `s3://tidb-pitr-bucket/backup-data` 的最小权限：`s3:ListBucket` 和 `s3:GetObject`。 3. 规划备份数据保存的目录结构，以及快照（全量）备份和日志备份的目录。 diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md index 4b8f75edcadf..1dbdabebce7a 100644 --- a/br/br-auto-tune.md +++ b/br/br-auto-tune.md @@ -1,17 +1,17 @@ --- -title: BR 自动调节 -summary: 了解 BR 自动调节功能，在集群资源占用率较高的情况下，BR 会自动限制备份使用的资源以求减少对集群的影响。 +title: 备份自动调节 +summary: 了解 TiDB 的自动调节备份功能，在集群资源占用率较高的情况下，BR 会自动限制备份使用的资源以求减少对集群的影响。 --- -# BR 自动调节 从 v5.4 版本开始引入 +# 备份自动调节 从 v5.4 版本开始引入 -在 TiDB v5.4.0 之前，默认情况下，使用 BR 工具进行备份任务时使用的线程数量占总逻辑 CPU 数量的 75%。在没有限速的前提下，备份会消耗大量的集群资源，这会对在线集群的性能造成相当大的影响。虽然你可以通过调节线程池的大小的方式来减少备份对集群性能的影响，但观察负载、手动调节线程池大小也是一件繁琐的事情。 +在 TiDB v5.4.0 之前，默认情况下，使用 BR 进行备份任务时使用的线程数量占总逻辑 CPU 数量的 75%。在没有限速的前提下，备份会消耗大量的集群资源，这会对在线集群的性能造成相当大的影响。虽然你可以通过调节线程池的大小的方式来减少备份对集群性能的影响，但观察负载、手动调节线程池大小也是一件繁琐的事情。 -为了减少备份任务对在线集群的影响，从 TiDB v5.4.0 起，BR 引入了自动调节功能，此功能默认开启。在集群资源占用率较高的情况下，BR 可以通过该功能自动限制备份使用的资源，从而减少对集群的影响。 +为了减少备份任务对在线集群的影响，从 TiDB v5.4.0 起，引入了自动调节功能，此功能默认开启。在集群资源占用率较高的情况下，备份功能可以通过该功能自动限制备份使用的资源，从而减少对集群的影响。 ## 使用场景 -如果你希望减少 BR 备份对集群的影响，那么，你可以开启自动调节功能。开启该功能后，BR 会在不过度影响集群的前提下，以最快的速度进行备份。 +如果你希望减少备份对集群的影响，那么，你可以开启自动调节功能。开启该功能后，备份功能会在不过度影响集群的前提下，以最快的速度进行数据备份。 或者，你也可以使用 TiKV 配置项 [`backup.num-threads`](/tikv-configuration-file.md#num-threads-1) 或参数 `--ratelimit` 进行备份限速。 @@ -23,9 +23,9 @@ summary: 了解 BR 自动调节功能，在集群资源占用率较高的情况 > > v5.3.x 版本的集群，在升级到 v5.4.0 及以上版本后，自动调节功能默认关闭，需手动开启。 -如需开启 BR 自动调节功能，可以通过把 TiKV 配置项 [`backup.enable-auto-tune`](/tikv-configuration-file.md#enable-auto-tune-从-v54-版本开始引入) 设置为 `true` 的方式来完成。 +如需开启备份自动调节功能，可以通过把 TiKV 配置项 [`backup.enable-auto-tune`](/tikv-configuration-file.md#enable-auto-tune-从-v54-版本开始引入) 设置为 `true` 的方式来完成。 -TiKV 支持[动态配置](/tikv-control.md#动态修改-tikv-的配置)自动调节功能，因此，在开启或关闭该功能时，无需重启集群。你可以运行以下命令动态启动或停止 BR 自动调节功能： +TiKV 支持[动态配置](/tikv-control.md#动态修改-tikv-的配置)自动调节功能，因此，在开启或关闭该功能时，无需重启集群。你可以运行以下命令动态启动或停止备份自动调节功能： ```shell tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v @@ -39,7 +39,7 @@ tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v 该功能的已知问题及其解决方案如下： -- 问题 1：对于**以写负载为主的集群**，自动调节可能会让工作负载和备份进入一种“正反馈循环”：备份会占用较多资源，导致工作负载使用的资源变少。此时，自动调节会误以为资源使用率下降，从而让 BR 运行得更加激进。在这种情况下，自动调节实际上失效。 +- 问题 1：对于**以写负载为主的集群**，自动调节可能会让工作负载和备份进入一种“正反馈循环”：备份会占用较多资源，导致工作负载使用的资源变少。此时，自动调节会误以为资源使用率下降，从而让备份运行得更加激进。在这种情况下，自动调节实际上失效。 - 解决方法：手动调节 `backup.num-threads`，限制处理备份的工作线程数量。具体原理如下： 目前，备份过程会涉及大量的 SST 解码、编码、压缩、解压，而此过程会需要消耗大量的 CPU 资源。另外，以往的测试证明，备份过程中，用于备份的线程池的 CPU 利用率接近 100%。也就是说，备份任务会占用大量 CPU 资源。通过调整备份任务使用的线程数量，TiKV 可以控制备份任务使用的 CPU 核心数，从而减少其任务对集群性能的影响。 @@ -51,7 +51,7 @@ tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v ## 实现原理 -自动调节会通过调节 BR 备份时使用的工作线程池的大小，保证集群的 CPU 总体使用率不超过某个特定的值。 +自动调节会通过调节备份时使用的工作线程池的大小，保证集群的 CPU 总体使用率不超过某个特定的值。 这个特性还有两个配置项未在 TiKV 文档中列出，仅在内部调试使用，正常备份时**无需**配置这两个参数。 diff --git a/br/br-batch-create-table.md b/br/br-batch-create-table.md index 414bae20b6c0..1a730ea6ea5c 100644 --- a/br/br-batch-create-table.md +++ b/br/br-batch-create-table.md @@ -1,6 +1,6 @@ --- title: 批量建表 -summary: 了解如何使用批量建表功能。在恢复备份数据时，BR 可以通过批量建表功能加快数据的恢复速度。 +summary: 了解如何使用批量建表功能。在恢复备份数据时，可以通过批量建表功能加快数据的恢复速度。 --- # 批量建表 @@ -11,8 +11,8 @@ summary: 了解如何使用批量建表功能。在恢复备份数据时，BR > **注意：** > -> - 为使用 BR 建表功能，TiDB 和 BR 都必须为 v6.0.0 或以上版本。如果 TiDB 或 BR 的任意一方的版本低于 v6.0.0，BR 会采用原来的串行建表方案。 -> - 如果你在使用 TiUP 等集群管理工具，而且你使用的 TiDB 和 BR 是 v6.0.0 或以上版本，或是从 v6.0.0 以下版本升级至该版本，此时，BR 会默认开启批量建表功能，你不需要额外进行相关配置。 +> - 为使用批量建表功能，TiDB 和 br 命令行工具都必须为 v6.0.0 或以上版本。如果 TiDB 或 br 命令行工具的任意一方的版本低于 v6.0.0，br 命令行工具会采用原来的串行建表方案。 +> - 如果你在使用 TiUP 等集群管理工具，而且你使用的 TiDB 和 br 命令行工具是 v6.0.0 或以上版本，或是从 v6.0.0 以下版本升级至该版本，此时，br 工具会默认开启批量建表功能，你不需要额外进行相关配置。 ## 使用场景 @@ -22,7 +22,7 @@ summary: 了解如何使用批量建表功能。在恢复备份数据时，BR ## 使用方法 -BR 默认开启了批量建表功能，在 v6.0.0 或以上版本中默认设置了 `--ddl-batch-size=128`（即 BR 以 128 张表为一批，并发创建多批表），以加快恢复时的建表速度。因此，你不需要额外配置该参数。 +Backup & Restore (BR) 默认开启批量建表功能，在 v6.0.0 或以上版本中默认设置了 `--ddl-batch-size=128`（以 128 张表为一批，并发创建多批表），以加快恢复时的建表速度。因此，你不需要额外配置该参数。 如果需要关闭此功能，你可以参考以下命令将 `--ddl-batch-size` 的值设置为 `0`： @@ -38,7 +38,7 @@ br restore full \ - v6.0.0 前的串行建表方案： - 使用 BR 执行数据恢复任务时，BR 会先在目标 TiDB 集群上创建库和表，然后再把已备份的数据恢复到表中。建表时，BR 会调用 TiDB 内部 API 后开始创建表，其运作方式类似 BR 在执行 SQL `Create Table` 语句。建表任务由 TiDB DDL owner 依次串行执行。DDL owner 每创建一张表会引起一次 DDL schema 版本的变更，而每次的 schema 版本的变更都需要同步到其他 TiDB DDL worker（含 BR）。因此，当需要创建的表的数量比较多时，串行建表方案会导致建表时间过长。 + 执行数据恢复任务时，BR 会先在目标 TiDB 集群上创建库和表，然后再把已备份的数据恢复到表中。建表时，BR 会调用 TiDB 内部 API 后开始创建表，其运作方式类似 BR 执行 SQL `Create Table` 语句。建表任务由 TiDB DDL owner 依次串行执行。DDL owner 每创建一张表会引起一次 DDL schema 版本的变更，而每次的 schema 版本的变更都需要同步到其他 TiDB DDL worker（含 BR）。因此，当需要创建的表的数量比较多时，串行建表方案会导致建表时间过长。 - v6.0.0 起的批量建表方案： diff --git a/br/br-incremental-guide.md b/br/br-incremental-guide.md index 7ba24a082948..9008421f617a 100644 --- a/br/br-incremental-guide.md +++ b/br/br-incremental-guide.md @@ -13,7 +13,7 @@ TiDB 集群增量数据包含在某个时间段的起始和结束两个快照的 ## 对集群进行增量备份 -使用 `br backup` 进行增量备份只需要指定**上一次的备份时间戳** `--lastbackupts`，BR 会判定需要备份 `lastbackupts` 和当前时间之间增量数据。使用 `validate` 指令获取上一次备份的时间戳，示例如下： +使用 `br backup` 进行增量备份只需要指定**上一次的备份时间戳** `--lastbackupts`，br 命令行工具会判定需要备份 `lastbackupts` 和当前时间之间增量数据。使用 `validate` 指令获取上一次备份的时间戳，示例如下： ```shell LAST_BACKUP_TS=`tiup br validate decode --field="end-version" --storage "s3://backup-101/snapshot-202209081330?access_key=${access_key}&secret_access_key=${secret_access_key}"| tail -n1` diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md index cb46b228fb66..a5edf80220a2 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -1,12 +1,12 @@ --- -title: BR 监控告警 -summary: BR 监控告警介绍。 +title: 备份恢复监控告警 +summary: 了解备份恢复的监控告警。 aliases: ['/zh/tidb/dev/pitr-monitoring-and-alert/'] --- -# BR 监控告警 +# 备份恢复监控告警 -本文介绍 BR 的监控和告警，包括如何部署监控、监控指标及常用告警项。 +本文介绍备份恢复的监控和告警，包括如何部署监控、监控指标及常用告警项。 ## 日志备份监控 diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md index 7644534a5d30..1a4e2ec36a3f 100644 --- a/br/br-pitr-guide.md +++ b/br/br-pitr-guide.md @@ -8,7 +8,7 @@ aliases: ['/zh/tidb/dev/pitr-usage/'] 全量备份包含集群某个时间点的全量数据，但是不包含其他时间点的更新数据，而 TiDB 日志备份能够将业务写入 TiDB 的数据记录及时备份到指定存储中。如果你需要灵活的选择恢复的时间点，即实现 Point-in-time recovery (PITR)，可以开启[日志备份](#开启日志备份)，并[定期执行快照（全量）备份](#定期执行全量备份)。 -使用 BR 备份与恢复数据前，请先[安装 BR](/br/br-use-overview.md#部署和使用-br) 。 +使用 br 命令行工具备份与恢复数据前，请先[安装 br 命令行工具](/br/br-use-overview.md#部署和使用-br) 。 ## 对集群进行备份 @@ -52,7 +52,7 @@ tiup br backup full --pd "${PD_IP}:2379" \ ## 进行 PITR -如果你想恢复到备份保留期内的任意时间点，可以使用 `br restore point` 命令。执行该命令时，你需要指定**要恢复的时间点**、**恢复时间点之前最近的快照备份**以及**日志备份数据**。BR 会自动判断和读取恢复需要的数据，然后将这些数据依次恢复到指定的集群。 +如果你想恢复到备份保留期内的任意时间点，可以使用 `br restore point` 命令。执行该命令时，你需要指定**要恢复的时间点**、**恢复时间点之前最近的快照备份**以及**日志备份数据**。br 命令行工具会自动判断和读取恢复需要的数据，然后将这些数据依次恢复到指定的集群。 ```shell br restore point --pd "${PD_IP}:2379" \ @@ -61,7 +61,7 @@ br restore point --pd "${PD_IP}:2379" \ --restored-ts '2022-05-15 18:00:00+0800' ``` -恢复期间，可通过终端中的进度条查看进度，如下。恢复分为两个阶段：全量恢复 (Full Restore) 和日志恢复（Restore Meta Files 和 Restore KV Files）。每个阶段完成恢复后，BR 都会输出恢复耗时和恢复数据大小等信息。 +恢复期间，可通过终端中的进度条查看进度，如下。恢复分为两个阶段：全量恢复 (Full Restore) 和日志恢复（Restore Meta Files 和 Restore KV Files）。每个阶段完成恢复后，br 命令行工具都会输出恢复耗时和恢复数据大小等信息。 ```shell Full Restore <--------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00% @@ -103,7 +103,7 @@ Restore KV Files <-------------------------------------------------------------- ### 能力指标 - PITR 恢复速度，平均到单台 TiKV 节点：全量恢复为 280 GB/h ，日志恢复为 30 GB/h -- 使用 BR 清理过期的日志备份数据速度为 600 GB/h +- 使用 `br log truncate` 清理过期的日志备份数据速度为 600 GB/h > **注意：** > diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index 564cd00ecf89..5df41562c09e 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -77,7 +77,7 @@ Global Flags: - `--start-ts`：指定开始备份日志的起始时间点。如果未指定，备份程序选取当前时间作为 `start-ts`。 - `task-name`：指定日志备份任务名。该名称也用于查询备份状态、暂停、重启和恢复备份任务等操作。 - `ca`、`cert`、`key`：指定使用 mTLS 加密方式与 TiKV 和 PD 进行通讯。 -- `--pd`：指定备份集群的 PD 访问地址。BR 需要访问 PD，发起日志备份任务。 +- `--pd`：指定备份集群的 PD 访问地址。br 命令行工具需要访问 PD，发起日志备份任务。 - `--storage`：指定备份存储地址。日志备份支持以 Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 为备份存储，以上命令以 S3 为示例。详细参考[备份存储 URL 格式](/br/backup-and-restore-storages.md#url-格式)。 使用示例： diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md index 0c75a969f97b..393b6ce7b68c 100644 --- a/br/br-snapshot-guide.md +++ b/br/br-snapshot-guide.md @@ -1,12 +1,12 @@ --- title: TiDB 快照备份与恢复使用指南 -summary: 了解如何使用 BR 进行 TiDB 快照备份与恢复。 +summary: 了解如何使用 br 命令行工具进行 TiDB 快照备份与恢复。 aliases: ['/zh/tidb/dev/br-usage-backup/','/zh/tidb/dev/br-usage-restore/','/zh/tidb/dev/br-usage-restore-for-maintain/', '/zh/tidb/dev/br-usage-backup-for-maintain/'] --- # TiDB 快照备份与恢复使用指南 -本文介绍如何使用 BR 进行 TiDB 快照备份和恢复。使用前，请先[安装 BR](/br/br-use-overview.md#部署和使用-br) 。 +本文介绍如何使用 br 命令行工具进行 TiDB 快照备份和恢复。使用前，请先[安装 br 命令行工具](/br/br-use-overview.md#部署和使用-br) 。 快照备份是集群全量备份的一种实现。它基于 TiDB 的[多版本并发控制 (MVCC)](/tidb-storage.md#mvcc) 实现，将指定快照包含的所有数据备份到目标存储中。备份下来的数据大小约等于集群（压缩后的）单副本数据大小。备份完成之后，你可以在一个空集群或不存在数据冲突（相同 schema 或 table）的集群执行快照备份恢复，将集群恢复到快照备份时的数据状态，同时恢复功能会依据集群副本设置恢复出多副本。 @@ -75,7 +75,7 @@ Full Restore <------------------------------------------------------------------ ### 恢复备份数据中指定库表的数据 -BR 支持只恢复备份数据中指定库、表的部分数据，该功能用于在恢复过程中过滤不需要的数据。 +br 命令行工具支持只恢复备份数据中指定库、表的部分数据，该功能用于在恢复过程中过滤不需要的数据。 **恢复单个数据库的数据** @@ -114,9 +114,9 @@ tiup br restore full --pd "${PD_IP}:2379" \ ### 恢复 `mysql` 数据库下的表 -自 BR v5.1.0 开始，快照备份会备份 **mysql schema 下的系统表数据**，而不会默认恢复这些数据。自 BR v6.2.0 开始，在设置 `--with-sys-table` 下，恢复数据时将同时恢复**部分系统表相关数据**。 +自 `br` v5.1.0 开始，快照备份会备份 **mysql schema 下的系统表数据**，而不会默认恢复这些数据。自 `br` v6.2.0 开始，在设置 `--with-sys-table` 下，恢复数据时将同时恢复**部分系统表相关数据**。 -**BR 可恢复的部分系统表**： +**可恢复的部分系统表**： ``` +----------------------------------+ @@ -131,7 +131,7 @@ tiup br restore full --pd "${PD_IP}:2379" \ +----------------------------------+ ``` -**BR 不能恢复以下系统表**： +**不能恢复以下系统表**： - 统计信息表 (`mysql.stat_*`) - 系统变量表 (`mysql.tidb`、`mysql.global_variables`) @@ -153,15 +153,15 @@ TiDB 备份功能对集群性能（事务延迟和 QPS）有一定的影响， 为了更加具体说明备份对集群的影响，下面列举了多次快照备份测试结论来说明影响的范围： -- （使用 5.3 及之前版本）BR 在默认配置下，单 TiKV 存储节点上备份线程数量是节点 CPU 总数量的 75% 时，QPS 会下降到备份之前的 35% 左右。 -- （使用 5.4 及以后版本）当 BR 在单 TiKV 存储节点上备份的线程数量不大于 `8`、集群总 CPU 利用率不超过 80% 时，BR 备份任务对集群（无论读写负载）影响最大在 20% 左右。 -- （使用 5.4 及以后版本）当 BR 在单 TiKV 存储节点上备份的线程数量不大于 `8`、集群总 CPU 利用率不超过 75% 时，BR 备份任务对集群（无论读写负载）影响最大在 10% 左右。 -- （使用 5.4 及以后版本）当 BR 在单 TiKV 存储节点上备份的线程数量不大于 `8`、集群总 CPU 利用率不超过 60% 时，BR 备份任务对集群（无论读写负载）几乎没有影响。 +- （使用 5.3 及之前版本）在默认配置下，单 TiKV 存储节点上备份线程数量是节点 CPU 总数量的 75% 时，QPS 会下降到备份之前的 35% 左右。 +- （使用 5.4 及以后版本）单 TiKV 存储节点上备份的线程数量不大于 `8`、集群总 CPU 利用率不超过 80% 时，备份任务对集群（无论读写负载）影响最大在 20% 左右。 +- （使用 5.4 及以后版本）单 TiKV 存储节点上备份的线程数量不大于 `8`、集群总 CPU 利用率不超过 75% 时，备份任务对集群（无论读写负载）影响最大在 10% 左右。 +- （使用 5.4 及以后版本）单 TiKV 存储节点上备份的线程数量不大于 `8`、集群总 CPU 利用率不超过 60% 时，备份任务对集群（无论读写负载）几乎没有影响。 -你可以通过如下方案手动控制 BR 备份对集群性能带来的影响。但是，这两种方案在减少 BR 备份对集群的影响的同时，也会降低备份任务的速度。 +你可以通过如下方案手动控制备份对集群性能带来的影响。但是，这两种方案在减少备份对集群的影响的同时，也会降低备份任务的速度。 - 使用 `--ratelimit` 参数对备份任务进行限速。请注意，这个参数限制的是**把备份文件存储到外部存储**的速度。计算备份文件的大小时，请以备份日志中的 `backup data size(after compressed)` 为准。 -- 调节 TiKV 配置项 [`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)，限制备份任务使用的工作线程数量。内部测试数据表明，当 BR 备份的线程数量不大于 `8`、集群总 CPU 利用率不超过 60% 时，BR 备份任务对集群（无论读写负载）几乎没有影响。 +- 调节 TiKV 配置项 [`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)，限制备份任务使用的工作线程数量。内部测试数据表明，当备份的线程数量不大于 `8`、集群总 CPU 利用率不超过 60% 时，备份任务对集群（无论读写负载）几乎没有影响。 通过限制备份的线程数量可以降低备份对集群性能的影响，但是这会影响到备份的性能，以上的多次备份测试结果显示，单 TiKV 存储节点上备份速度和备份线程数量呈正比。在线程数量较少的时候，备份速度约为 20 MiB/线程数。例如，单 TiKV 节点 5 个备份线程可达到 100 MiB/s 的备份速度。 diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md index c5d34bbc5c33..155fc90a4fc8 100644 --- a/br/br-snapshot-manual.md +++ b/br/br-snapshot-manual.md @@ -38,9 +38,9 @@ br backup full \ 以上命令中： -- `--backupts`：快照对应的物理时间点。如果该快照的数据已经被 GC，那么 `br backup` 命令会报错退出；如果没有指定该参数，BR 会选取备份开始的时间点所对应的快照。 +- `--backupts`：快照对应的物理时间点。如果该快照的数据已经被 GC，那么 `br backup` 命令会报错退出；如果没有指定该参数，br 命令行工具会选取备份开始的时间点所对应的快照。 - `--ratelimit`：**每个 TiKV** 执行备份任务的速度上限（单位 MiB/s）。 -- `--log-file`：BR log 写入的目标文件。 +- `--log-file`：备份日志写入的目标文件。 备份期间终端会显示进度条，效果如下。当进度条达到 100% 时，表示备份完成。 @@ -50,7 +50,7 @@ Full Backup <---------/................................................> 17.12%. ## 备份 TiDB 集群指定库表的数据 -BR 支持只备份集群快照和增量数据中指定库或表的局部数据。在快照备份和增量数据备份的基础上，该功能可过滤掉不需要的数据，只备份关键业务的数据。 +br 工具支持只备份集群快照和增量数据中指定库或表的局部数据。在快照备份和增量数据备份的基础上，该功能可过滤掉不需要的数据，只备份关键业务的数据。 ### 备份单个数据库的数据 @@ -108,7 +108,7 @@ br backup full \ > > 当前该功能为实验特性，不建议在生产环境中使用。 -BR 支持在备份端，或备份到 Amazon S3 的时候在[存储服务端进行备份数据加密](/br/backup-and-restore-storages.md#amazon-s3-存储服务端加密备份数据)，你可以根据自己情况选择其中一种使用。 +br 命令行工具支持在备份端，或备份到 Amazon S3 的时候在[存储服务端进行备份数据加密](/br/backup-and-restore-storages.md#amazon-s3-存储服务端加密备份数据)，你可以根据自己情况选择其中一种使用。 自 TiDB v5.3.0 起，你可配置下列参数在备份过程中实现数据加密： @@ -146,9 +146,9 @@ br restore full \ 以上命令中， - `--ratelimit`：**每个 TiKV** 执行恢复任务的速度上限（单位 MiB/s） -- `--log-file`：BR log 写入的目标文件 +- `--log-file`：备份日志写入的目标文件 -恢复期间终端会显示进度条，效果如下。当进度条达到 100% 时，表示恢复完成。在完成恢复后，BR 为了确保数据安全性，还会校验恢复数据。 +恢复期间终端会显示进度条，效果如下。当进度条达到 100% 时，表示恢复完成。在完成恢复后，br 工具为了确保数据安全性，还会校验恢复数据。 ```shell Full Restore <---------/...............................................> 17.12%. @@ -156,7 +156,7 @@ Full Restore <---------/...............................................> 17.12%. ## 恢复备份数据中指定库表的数据 -BR 支持只恢复备份数据中指定库/表的局部数据。该功能在恢复过程中过滤掉不需要的数据，可以用于往 TiDB 集群上恢复指定库/表的数据。 +br 命令行工具支持只恢复备份数据中指定库/表的局部数据。该功能在恢复过程中过滤掉不需要的数据，可以用于往 TiDB 集群上恢复指定库/表的数据。 ### 恢复单个数据库的数据 diff --git a/br/br-use-overview.md b/br/br-use-overview.md index 027ca8b9cfed..eb524cf9ca75 100644 --- a/br/br-use-overview.md +++ b/br/br-use-overview.md @@ -1,6 +1,6 @@ --- title: TiDB 备份与恢复功能使用概述 -summary: 了解如何部署和使用 BR 进行 TiDB 集群的备份与恢复。 +summary: 了解如何部署和使用 TiDB 集群的备份与恢复。 aliases: ['/zh/tidb/dev/br-deployment/'] --- @@ -32,16 +32,16 @@ BR 只提供备份和恢复的基础功能，尚不支持备份管理的功能 **选择备份存储** -Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 是 BR 推荐的存储系统选择，使用这些系统，你无需担心备份容量、备份带宽规划等。 +Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 是推荐的存储系统选择，使用这些系统，你无需担心备份容量、备份带宽规划等。 如果 TiDB 集群部署在自建机房中，则推荐以下方式： * 搭建 [MinIO](https://docs.min.io/docs/minio-quickstart-guide.html) 作为备份存储系统，使用 S3 协议将数据备份到 MinIO 中。 -* 挂载 NFS（如 NAS）盘到 BR 和所有的 TiKV 实例，使用 POSIX file system 接口将备份数据写入对应的 NFS 目录中。 +* 挂载 NFS（如 NAS）盘到 br 工具和所有的 TiKV 实例，使用 POSIX file system 接口将备份数据写入对应的 NFS 目录中。 > **注意：** > -> 如果没有挂载 NFS 到 BR 或 TiKV 节点，或者使用了支持 S3、GCS 或 Azure Blob Storage 协议的远端存储，那么 BR 备份的数据会在各个 TiKV 节点生成。**注意这不是推荐的 BR 使用方式**，因为备份数据会分散在各个节点的本地文件系统中，聚集这些备份数据可能会造成数据冗余和运维上的麻烦，而且在不聚集这些数据便直接恢复的时候会遇到 `SST file not found` 报错。 +> 如果没有挂载 NFS 到 br 工具或 TiKV 节点，或者使用了支持 S3、GCS 或 Azure Blob Storage 协议的远端存储，那么 br 工具备份的数据会在各个 TiKV 节点生成。**注意这不是推荐的 br 工具使用方式**，因为备份数据会分散在各个节点的本地文件系统中，聚集这些备份数据可能会造成数据冗余和运维上的麻烦，而且在不聚集这些数据便直接恢复的时候会遇到 `SST file not found` 报错。 **组织备份数据目录** @@ -68,7 +68,7 @@ Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 是 BR 推荐的存 - BR、TiKV 节点和备份存储系统需要提供大于备份速度的的网络带宽。当集群特别大的时候，备份和恢复速度上限受限于备份网络的带宽。 - 备份存储系统还需要提供足够的写入/读取性能 (IOPS)，否则它有可能成为备份恢复时的性能瓶颈。 - TiKV 节点需要为备份准备至少额外的两个 CPU core 和高性能的磁盘，否则备份将对集群上运行的业务产生影响。 -- 推荐 BR 运行在 8 核+/16 GB+ 的节点上。 +- 推荐 br 工具运行在 8 核+/16 GB+ 的节点上。 目前支持以下几种方式来使用 BR。 @@ -76,7 +76,7 @@ Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 是 BR 推荐的存 TiDB 支持使用 br 工具进行备份恢复。 -* 安装方法可以使用[使用 TiUP 在线安装](/migration-tools.md#使用-tiup-快速安装)：`tiup install br`。 +* 安装方法可以[使用 TiUP 在线安装](/migration-tools.md#使用-tiup-快速安装)：`tiup install br`。 * 了解如何使用 `br` 命令行工具进行备份与恢复，请参阅： * [TiDB 快照备份与恢复功能使用](/br/br-snapshot-guide.md) diff --git a/br/external-storage.md b/br/external-storage.md index 6cf52dafa74d..5e2b25b3cbb0 100644 --- a/br/external-storage.md +++ b/br/external-storage.md @@ -5,7 +5,7 @@ summary: 了解 BR、TiDB Lightning 和 Dumpling 中所用外部存储服务的 # 外部存储 -Backup & Restore (BR)、TiDB Lightning 和 Dumpling 都支持在本地文件系统和 Amazon S3 上读写数据；另外 BR 还支持 Google Cloud Storage、Azure Blob Storage (Azblob)。通过传入不同 URL scheme 到 BR 的 `--storage` (`-s`) 参数、TiDB Lightning 的 `-d` 参数及 Dumpling 中的 `--output` (`-o`) 参数，可以区分不同的存储方式。 +Backup & Restore (BR)、TiDB Lightning 和 Dumpling 都支持在本地文件系统和 Amazon S3 上读写数据；另外 BR 还支持 Google Cloud Storage、Azure Blob Storage (Azblob)。通过传入不同 URL scheme 到 br 工具 的 `--storage` (`-s`) 参数、TiDB Lightning 的 `-d` 参数及 Dumpling 中的 `--output` (`-o`) 参数，可以区分不同的存储方式。 ## Scheme @@ -51,14 +51,14 @@ S3、 GCS 和 Azblob 等云存储有时需要额外的连接配置，你可以 -d 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role' ``` -* 用 BR 备份到 GCS： +* 用 br 命令行工具备份到 GCS： ```bash ./br backup full -u 127.0.0.1:2379 \ --storage 'gcs://bucket-name/prefix' ``` -* 用 BR 备份到 Azblob： +* 用 br 命令行工具备份到 Azblob： ```bash ./br backup full -u 127.0.0.1:2379 \ @@ -129,7 +129,7 @@ S3、 GCS 和 Azblob 等云存储有时需要额外的连接配置，你可以 ## 命令行参数 -除了使用 URL 参数，BR 和 Dumpling 工具也支持从命令行指定这些配置，例如： +除了使用 URL 参数，br 命令行工具和 Dumpling 工具也支持从命令行指定这些配置，例如： ```bash ./dumpling -u root -h 127.0.0.1 -P 3306 -B mydb -F 256MiB \ @@ -171,7 +171,7 @@ S3、 GCS 和 Azblob 等云存储有时需要额外的连接配置，你可以 -r 200000 -F 256MiB ``` -* 使用 BR 将数据备份至 OSS 存储： +* 使用 br 命令行工具将数据备份至 OSS 存储： ```bash ./br backup full --pd "127.0.0.1:2379" \ diff --git a/br/rawkv-backup-and-restore.md b/br/rawkv-backup-and-restore.md index b548bf989232..61c1b025e479 100644 --- a/br/rawkv-backup-and-restore.md +++ b/br/rawkv-backup-and-restore.md @@ -1,6 +1,6 @@ --- title: 备份与恢复 RawKV 数据 -summary: 了解如何使用 BR 备份和恢复 RawKV 数据。 +summary: 了解如何使用 br 命令行工具备份和恢复 RawKV 数据。 --- # 备份与恢复 RawKV 数据 @@ -13,7 +13,7 @@ TiKV 有时可以独立于 TiDB，与 PD 构成 KV 数据库，此时的产品 ## 备份 RawKV -在某些使用场景下，TiKV 可能会独立于 TiDB 运行。考虑到这点，BR 提供跳过 TiDB 层直接备份 TiKV 数据的功能： +在某些使用场景下，TiKV 可能会独立于 TiDB 运行。考虑到这点，br 命令行工具提供跳过 TiDB 层直接备份 TiKV 数据的功能： ```shell br backup raw --pd $PD_ADDR \ @@ -42,7 +42,7 @@ br backup raw --pd $PD_ADDR \ > > - 使用共享存储可以避免这些情况。例如，在本地路径上安装 NFS，或使用 S3。利用这些网络存储，各个节点都可以自动读取每个 SST 文件，此时上述注意事项不再适用。 > -> - 同时，请注意同一时间对同一个集群只能运行一个恢复任务，否则可能会出现非预期的行为，详见[可以同时使用多个 BR 进程对单个集群进行恢复吗](/faq/backup-and-restore-faq.md#可以同时使用多个-br-进程对单个集群进行恢复吗)。 +> - 同时，请注意同一时间对同一个集群只能运行一个恢复任务，否则可能会出现非预期的行为，详见[可以同时使用多个 br 工具进程对单个集群进行恢复吗](/faq/backup-and-restore-faq.md#可以同时启动多个恢复任务对单个集群进行恢复吗)。 ## 恢复 RawKV diff --git a/br/use-br-command-line-tool.md b/br/use-br-command-line-tool.md index dec6ca272d9e..077d9aa0b7d5 100644 --- a/br/use-br-command-line-tool.md +++ b/br/use-br-command-line-tool.md @@ -42,7 +42,7 @@ br backup full --pd "${PD_IP}:2379" \ ### 常用选项 * `--pd`：PD 访问地址选项，例如 `"${PD_IP}:2379"`。 -* `-s` 或 `--storage`：备份数据的存储地址选项。BR 支持以 Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 及 NFS 为备份存储。详细参考[备份存储 URL 配置](/br/backup-and-restore-storages.md#url-格式)。 +* `-s` 或 `--storage`：备份数据的存储地址选项。TiDB 备份恢复支持以 Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 及 NFS 为备份存储。详细参考[备份存储 URL 配置](/br/backup-and-restore-storages.md#url-格式)。 * `--ca`：指定 PEM 格式的受信任 CA 的证书文件路径。 * `--cert`：指定 PEM 格式的 SSL 证书文件路径。 * `--key`：指定 PEM 格式的 SSL 证书密钥文件路径。 diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md index d4dac9d55f2a..6fad858f6bfc 100644 --- a/faq/backup-and-restore-faq.md +++ b/faq/backup-and-restore-faq.md @@ -1,12 +1,12 @@ --- title: 备份与恢复常见问题 -summary: BR 相关的常见问题以及解决方法。 +summary: 了解备份恢复相关的常见问题以及解决方法。 aliases: ['/docs-cn/dev/br/backup-and-restore-faq/','/zh/tidb/dev/pitr-troubleshoot/','/zh/tidb/dev/pitr-known-issues/'] --- # 备份与恢复常见问题 -本文列出了在使用 Backup & Restore (BR) 时，可能会遇到的问题及相应的解决方法。 +本文列出了在使用 Backup & Restore (BR) 完成备份与恢复任务时，可能会遇到的问题及相应的解决方法。 如果遇到未包含在此文档且无法解决的问题，可以在 [AskTUG](https://asktug.com/) 社区中提问。 @@ -23,13 +23,13 @@ TiKV 支持[动态配置](/tikv-control.md#动态修改-tikv-的配置)自动调 如需了解通过 `tikv-ctl` 在线修改自动调节功能的命令行，请参阅[自动调节功能的使用方法](/br/br-auto-tune.md#使用方法)。 -另外，自动调节功能减少了进行备份任务时默认使用的工作线程数量（详见 [`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)）。因此，你通过 Grafana 监控面板看到的备份速度、CPU 使用率、I/O 资源利用率都会小于 v5.4 之前的版本。在 v5.4.0 之前的版本中，`backup.num-threads` 的默认值为 CPU * 0.75，即处理备份任务的工作线程数量占了 75% 的逻辑 CPU，最大值为 `32`；在 v5.4.0 及之后的版本中，该配置项的默认值为 CPU * 0.5，最大值为 `8`。 +另外，自动调节功能减少了进行备份任务时默认使用的工作线程数量（详见 [`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)）。因此，你通过 Grafana 监控面板看到的备份速度、CPU 使用率、I/O 资源利用率都会小于 v5.4 之前的版本。在 v5.4.0 之前的版本中，`backup.num-threads` 的默认值为 `CPU * 0.75`，即处理备份任务的工作线程数量占了 75% 的逻辑 CPU，最大值为 `32`；在 v5.4.0 及之后的版本中，该配置项的默认值为 `CPU * 0.5`，最大值为 `8`。 在离线备份场景中，你也可以使用 `tikv-ctl` 把 `backup.num-threads` 修改为更大的数字，从而提升备份任务的速度。 ## PITR 问题 -### BR 进程在执行 `br log truncate` 命令时为什么会出现 OOM 问题？ +### `br` 进程在执行 `br log truncate` 命令时为什么会出现 OOM 问题？ Issue 链接：[#36648](https://github.com/pingcap/tidb/issues/36648) @@ -68,7 +68,7 @@ Issue 链接：[#37207](https://github.com/pingcap/tidb/issues/37207) 该场景发生在全量数据导入时开启了日志备份，并使用 PITR 恢复全量导入时间段的日志。经过测试发现，当存在长时间（24 小时）大量热点写入，且平均单台 TiKV 节点写入 OPS > 50k/s（可以通过 Grafana 中 **TiKV-Details** -> **Backup Log** -> **Handle Event Rate** 确认该数值），那么有几率会遇到这个情况。 -- 当前版本中建议在集群初始化后，进行一次有效快照备份，并且以此作为基础进行 PITR 恢复。 +当前版本中建议在集群初始化后，进行一次有效快照备份，并且以此作为基础进行 PITR 恢复。 ### 在使用 `br restore point` 命令恢复下游集群后， TiFlash 引擎数据没有恢复？ @@ -133,12 +133,12 @@ Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepo ### 为什么 BR 恢复的数据无法同步到 TiCDC / Drainer 的上游集群？ -- **BR 恢复的数据无法被同步到下游**，因为 BR 直接导入 SST 文件，而下游集群目前没有办法获得上游的 SST 文件。 -- 在 4.0.3 版本之前，BR 恢复时产生的 DDL jobs 还可能会让 TiCDC / Drainer 执行异常的 DDL。所以，如果一定要在 TiCDC / Drainer 的上游集群执行恢复，请将 BR 恢复的所有表加入 TiCDC / Drainer 的阻止名单。 +- **BR 恢复的数据无法被同步到下游**，因为恢复时 BR 直接导入 SST 文件，而下游集群目前没有办法获得上游的 SST 文件。 +- 在 4.0.3 版本之前，恢复时产生的 DDL jobs 还可能会让 TiCDC / Drainer 执行异常的 DDL。所以，如果一定要在 TiCDC / Drainer 的上游集群执行恢复，请将 BR 恢复的所有表加入 TiCDC / Drainer 的阻止名单。 TiCDC 可以通过配置项中的 [`filter.rules`](https://github.com/pingcap/tiflow/blob/7c3c2336f98153326912f3cf6ea2fbb7bcc4a20c/cmd/changefeed.toml#L16) 项完成，Drainer 则可以通过 [`syncer.ignore-table`](/tidb-binlog/tidb-binlog-configuration-file.md#ignore-table) 完成。 -### BR 为什么会报 `new_collations_enabled_on_first_bootstrap` 不匹配？ +### 恢复时为什么会报 `new_collations_enabled_on_first_bootstrap` 不匹配？ 从 TiDB v6.0.0 版本开始，[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap) 配置项的默认值由 `false` 改为 `true`。BR 会备份上游集群的 `new_collations_enabled_on_first_bootstrap` 配置项。当上下游集群的此项配置相同时，BR 才会将上游集群的备份数据安全地恢复到下游集群中。若上下游的该配置不相同，BR 会拒绝恢复，并报此配置项不匹配的错误。 @@ -149,11 +149,11 @@ TiCDC 可以通过配置项中的 [`filter.rules`](https://github.com/pingcap/ti ### 恢复 Placement Rule 到集群时为什么会报错？ -BR 在 v6.0.0 之前不支持[放置规则](/placement-rules-in-sql.md)。BR v6.0.0 及以上版本开始支持并提供了命令行选项 `--with-tidb-placement-mode=strict/ignore` 来控制放置规则的导入模式。默认值为 `strict`，代表导入并检查放置规则，当`--with-tidb-placement-mode` 设置为 `ignore` 时，BR 会忽略所有的放置规则。 +BR 在 v6.0.0 之前不支持[放置规则](/placement-rules-in-sql.md)，在 v6.0.0 及以上版本开始支持并提供了命令行选项 `--with-tidb-placement-mode=strict/ignore` 来控制放置规则的导入模式。默认值为 `strict`，代表导入并检查放置规则，当`--with-tidb-placement-mode` 设置为 `ignore` 时，BR 会忽略所有的放置规则。 ## 进行数据恢复的问题 -### BR 遇到错误信息 `Io(Os...)`，该如何处理？ +### 使用 BR 时遇到错误信息 `Io(Os...)`，该如何处理？ 这类问题几乎都是 TiKV 在写盘的时候遇到的系统调用错误。例如遇到 `Io(Os { code: 13, kind: PermissionDenied...})` 或者 `Io(Os { code: 2, kind: NotFound...})`。 @@ -161,43 +161,43 @@ BR 在 v6.0.0 之前不支持[放置规则](/placement-rules-in-sql.md)。BR v6. 目前已知备份到 samba 搭建的网盘时可能会遇到 `Code: 22(invalid argument)` 错误。 -### BR 遇到错误信息 `rpc error: code = Unavailable desc =...`，该如何处理？ +### 恢复时遇到错误信息 `rpc error: code = Unavailable desc =...`，该如何处理？ -该问题一般是因为使用 BR 恢复数据的时候，恢复集群的性能不足导致的。可以从恢复集群的监控或者 TiKV 日志来辅助确认。 +该问题一般是因为恢复数据的时候，恢复集群的性能不足导致的。可以从恢复集群的监控或者 TiKV 日志来辅助确认。 要解决这类问题，可以尝试扩大集群资源，以及调小恢复时的并发度 (concurrency)，打开限速 (ratelimit) 设置。 -### 使用 BR 恢复备份数据时，BR 会报错 `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-batch-create-table.md#使用方法) 的值大于 `1` 的情况下，使用 BR 恢复数据时，TiDB 会把执行创建表任务的 DDL job 队列写到 TiKV 上。由于 TiDB 能够一次性发送的 job message 的最大值默认为 `6 MB`（**不建议**修改此值，具体内容，参考 [txn-entry-size-limit](/tidb-configuration-file.md#txn-entry-size-limit-从-v50-版本开始引入) 和 [raft-entry-max-size](/tikv-configuration-file.md#raft-entry-max-size)），TiDB 单次发送的所有表的 schema 大小总和也不应该超过 6 MB。因此，如果你设置的 `--ddl-batch-size` 的值过大，TiDB 单次发送的批量表的 schema 大小就会超出规定值，从而导致 BR 报 `entry too large, the max entry size is 6291456, the size of data is 7690800` 错误。 -### 使用 local storage 的时候，BR 备份的文件会存在哪里？ +### 使用 local storage 的时候，备份的文件会存在哪里？ > **注意：** > -> - 如果没有挂载 NFS 到 BR 或 TiKV 节点，或者使用了支持 S3、GCS 或 Azure Blob Storage 协议的远端存储，那么 BR 备份的数据会在各个 TiKV 节点生成。**注意这不是推荐的 BR 使用方式** ，因为备份数据会分散在各个节点的本地文件系统中，聚集这些备份数据可能会造成数据冗余和运维上的麻烦，而且在不聚集这些数据便直接恢复的时候会遇到 `SST file not found` 报错。 +> 如果没有挂载 NFS 到 br 工具或 TiKV 节点，或者使用了支持 S3、GCS 或 Azure Blob Storage 协议的远端存储，那么 br 工具备份的数据会在各个 TiKV 节点生成。**注意这不是推荐的备份和恢复使用方式** ，因为备份数据会分散在各个节点的本地文件系统中，聚集这些备份数据可能会造成数据冗余和运维上的麻烦，而且在不聚集这些数据便直接恢复的时候会遇到 `SST file not found` 报错。 -在使用 local storage 的时候，会在运行 BR 的节点生成 `backupmeta`，在各个 Region 的 Leader 节点生成备份文件。 +在使用 local storage 的时候，会在运行 br 命令行工具的节点生成 `backupmeta`，在各个 Region 的 Leader 所在 TiKV 节点生成备份文件。 ### 恢复的时候，报错 `could not read local://...:download sst failed`，该如何处理？ 在恢复的时候，每个节点都必须能够访问到**所有**的备份文件 (SST files)。默认情况下，假如使用 local storage，备份文件会分散在各个节点中，此时是无法直接恢复的，必须将每个 TiKV 节点的备份文件拷贝到其它所有 TiKV 节点才能恢复。 所以**建议使用 S3/GCS/Azure Blob Storage/NFS 作为备份存储**。 -### BR 遇到 Permission denied 或者 No such file or directory 错误，即使用 root 运行 BR 也无法解决，该如何处理？ +### 遇到 Permission denied 或者 No such file or directory 错误，即使用 root 运行 br 命令行工具也无法解决，该如何处理？ 需要确认 TiKV 是否有访问备份目录的权限。如果是备份，确认是否有写权限；如果是恢复，确认是否有读权限。 -在进行备份操作时，如果使用本地磁盘或 NFS 作为存储介质，请确保执行 BR 的用户和启动 TiKV 的用户相同（如果 BR 和 TiKV 位于不同的机器，则需要用户的 UID 相同），否则备份可能会出现该问题。。 +在进行备份操作时，如果使用本地磁盘或 NFS 作为存储介质，请确保执行 br 命令行工具的用户和启动 TiKV 的用户相同（如果 br 工具和 TiKV 位于不同的机器，则需要用户的 UID 相同），否则备份可能会出现该问题。 -使用 root 运行 BR 仍旧有可能会因为磁盘权限而失败，因为备份文件 (SST) 的保存是由 TiKV 执行的。 +使用 root 运行 br 命令行工具仍旧有可能会因为磁盘权限而失败，因为备份文件 (SST) 的保存是由 TiKV 执行的。 > **注意：** > > 在恢复的时候也可能遇到同样的问题。 > -> 使用 BR 进行数据的恢复时，检验读权限的时机是在第一次读取 SST 文件时，考虑到执行 DDL 的耗时，这个时刻可能会离开始运行 BR 的时间很远。这样可能会出现等了很长时间之后遇到 Permission denied 错误失败的情况。 +> 使用 br 命令行工具进行数据的恢复时，检验读权限的时机是在第一次读取 SST 文件时，考虑到执行 DDL 的耗时，这个时刻可能会离开始运行 br 命令行工具的时间很远。这样可能会出现等了很长时间之后遇到 Permission denied 错误失败的情况。 > > 因此，最好在恢复前提前检查权限。 @@ -272,7 +272,7 @@ BR 在 v6.0.0 之前不支持[放置规则](/placement-rules-in-sql.md)。BR v6. ### 恢复集群的时候，在 MySQL 下的业务表为什么没有恢复？ -自 BR v5.1.0 开始，全量备份会备份 **mysql schema 下的表**。BR v6.2.0 以前的版本，在默认设置不会恢复 **mysql schema 下的表**。 +自 `br` v5.1.0 开始，全量备份会备份 **mysql schema 下的表**。`br` v6.2.0 以前的版本，在默认设置不会恢复 **mysql schema 下的表**。 如果需要恢复 `mysql` 下的用户创建的表（非系统表），可以通过 [table filter](/table-filter.md#表库过滤语法) 来显式地包含目标表。以下示例中命令会在执行正常的恢复的同时恢复 `mysql.usertable`。 @@ -314,21 +314,21 @@ br restore full -f 'mysql.usertable' -s $external_storage_url --with-sys-table 这个情况多数是因为备份时集群的数据压缩比率和恢复时的默认值不一致导致的，只要恢复的 checksum 阶段顺利通过，可以忽略这个问题，不影响正常使用。 -### BR 恢复存档后是否需要对表执行 `ANALYZE` 以更新 TiDB 在表和索引上留下的统计信息？ +### 使用 BR 恢复数据后是否需要对表执行 `ANALYZE` 以更新 TiDB 在表和索引上留下的统计信息？ BR 不会备份统计信息（v4.0.9 除外）。所以在恢复存档后需要手动执行 `ANALYZE TABLE` 或等待 TiDB 自动进行 `ANALYZE`。 -BR v4.0.9 备份统计信息使 BR 消耗过多内存，为保证备份过程正常，从 v4.0.10 开始默认关闭备份统计信息的功能。 +BR v4.0.9 备份统计信息使 br 工具消耗过多内存，为保证备份过程正常，从 v4.0.10 开始默认关闭备份统计信息的功能。 如果不对表执行 `ANALYZE`，TiDB 会因统计信息不准确而选不中最优化的执行计划。如果查询性能不是重点关注项，可以忽略 `ANALYZE`。 -### 可以同时使用多个 BR 进程对单个集群进行恢复吗？ +### 可以同时启动多个恢复任务对单个集群进行恢复吗？ -**强烈不建议**在单个集群中同时使用多个 BR 进程进行恢复，原因如下： +**强烈不建议**在单个集群中同时启动多个恢复任务进行数据恢复，原因如下： -- BR 在恢复数据时，会修改 PD 的一些全局配置。如果同时使用多个 BR 进程进行恢复，这些配置可能会被错误地覆写，导致集群状态异常。 +- BR 在恢复数据时，会修改 PD 的一些全局配置。如果同时使用多个 BR 命令进行恢复，这些配置可能会被错误地覆写，导致集群状态异常。 - 因为 BR 在恢复数据的时候会占用大量集群资源，事实上并行恢复能获得的速度提升也非常有限。 -- 多个 BR 并行恢复的场景没有经过测试，无法保证成功。 +- 多个恢复任务同时进行的场景没有经过测试，无法保证成功。 ### BR 会备份表的 `SHARD_ROW_ID_BITS` 和 `PRE_SPLIT_REGIONS` 信息吗？恢复出来的表会有多个 Region 吗？ diff --git a/glossary.md b/glossary.md index f832f3d9d842..52f6cb6fdee5 100644 --- a/glossary.md +++ b/glossary.md @@ -19,6 +19,15 @@ ACID 是指数据库管理系统在写入或更新资料的过程中，为保证 ## B +### BR + +[TiDB 备份恢复功能](/br/backup-and-restore-overview.md)用户文档中的名词 **BR** 根据上下文不同有不同的解释，比较常见的指代用法： + +* TiDB 备份恢复功能，包含 br CLI、TiDB Operator、TiDB Cloud 提供的备份和恢复功能集合。 +* 架构中的 BR 功能组件。 + +名词 **br** 一般用来指代 br CLI 工具。 + ### Batch Create Table 批量建表 (Batch Create Table) 是在 TiDB v6.0.0 中引入的新功能，此功能默认开启。当需要恢复的数据中带有大量的表（约 50000 张）时，批量建表功能显著提升数据恢复的速度。详情参见 [批量建表](/br/br-batch-create-table.md)。 diff --git a/information-schema/information-schema-deadlocks.md b/information-schema/information-schema-deadlocks.md index 2a211b3b687e..c3458e5da157 100644 --- a/information-schema/information-schema-deadlocks.md +++ b/information-schema/information-schema-deadlocks.md @@ -41,7 +41,7 @@ DESC deadlocks; * `CURRENT_SQL_DIGEST`：试图上锁的事务中当前正在执行的 SQL 语句的 Digest。 * `CURRENT_SQL_DIGEST_TEXT`：试图上锁的事务中当前正在执行的 SQL 语句的归一化形式。 * `KEY`：该事务试图上锁、但是被阻塞的 key，以十六进制编码的形式显示。 -* `KEY_INFO`：对 `KEY` 进行解读得出的一些详细信息，详见 [KEY_INFO](#key_info)。。 +* `KEY_INFO`：对 `KEY` 进行解读得出的一些详细信息，详见 [KEY_INFO](#key_info)。 * `TRX_HOLDING_LOCK`：该 key 上当前持锁并导致阻塞的事务 ID，即事务的 `start_ts`。 要调整 `DEADLOCKS` 表中可以容纳的死锁事件数量，可通过 TiDB 配置文件中的 [`pessimistic-txn.deadlock-history-capacity`](/tidb-configuration-file.md#deadlock-history-capacity) 配置项进行调整，默认容纳最近 10 次死锁错误的信息。