Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
29b8e85
i18n(ja): fix mistranslations and scrambled sentences in backup-and-r…
yahonda Sep 16, 2026
68f8f7d
i18n(ja): fix ts/task mistranslation and other real defects in 3 br f…
yahonda Sep 16, 2026
875524d
i18n(ja): fix dropped verb and unbalanced parenthesis in br-pitr-guid…
yahonda Sep 16, 2026
bac9aa1
i18n(ja): fix dropped clause, broken conjugation, and trapped particl…
yahonda Sep 16, 2026
6ebf4b0
i18n(ja): fix wrong particle, trapped particle, and typo in br-use-ov…
yahonda Sep 16, 2026
3797589
i18n(ja): fix dropped particles and missing backtick in use-br-comman…
yahonda Sep 16, 2026
0a52ac3
i18n(ja): unify 警告項目/アラート項目 terminology in br-monitoring-and-alert.md
yahonda Sep 16, 2026
43be855
i18n(ja): fix bold scope shift and scrambled permission list in backu…
yahonda Sep 16, 2026
e38c3b9
i18n(ja): fix dropped copula, particle, and scrambled formula in br-b…
yahonda Sep 16, 2026
586bde0
i18n(ja): fix missing backtick and 8 dropped particles in br-checkpoi…
yahonda Sep 16, 2026
7fabc39
i18n(ja): fix duplicated word, dropped word, and dropped particles in…
yahonda Sep 16, 2026
fd24172
i18n(ja): use the corpus-wide 目標復旧時点/目標復旧時間 term for RPO/RTO
yahonda Sep 16, 2026
ba7a9bd
i18n(ja): unify GiB/h to GiB/時間 for consistency with sibling rate units
yahonda Sep 16, 2026
41e364c
i18n(ja): quote the summary frontmatter value in use-br-command-line-…
yahonda Sep 16, 2026
dbd2605
i18n(ja): unify パラメーター to パラメータ in use-br-command-line-tool.md
yahonda Sep 16, 2026
030f019
i18n(ja): remove spurious spaces between katakana compounds in use-br…
yahonda Sep 16, 2026
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions br/backup-and-restore-overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ BRは以下の要件を満たしています。

## 使用する前に {#before-you-use}

このセクションでは、TiDB のバックアップとリストアを使用するための前提条件について説明します。これには、制限事項、使用上のヒント、互換性の問題が含まれます。BR ツールと他の機能またはバージョンとの[互換性](#compatibility)性の詳細については、 を参照してください。
このセクションでは、TiDB のバックアップとリストアを使用するための前提条件について説明します。これには、制限事項、使用上のヒント、互換性の問題が含まれます。BR ツールと他の機能またはバージョンとの互換性の詳細については、 [互換性](#compatibility)を参照してください。

### 制限 {#restrictions}

Expand Down Expand Up @@ -76,7 +76,7 @@ TiDB BRは以下の機能を提供します。
#### バックアップのパフォーマンスとTiDBクラスタへの影響 {#backup-performance-and-impact-on-tidb-clusters}

- クラスタのCPUとI/Oリソースが十分な場合、スナップショットバックアップがTiDBクラスタに与える影響は限定的で、通常は20%未満に抑えられます。TiDBクラスタを適切に構成することで、この影響をさらに10%以下にまで最小限に抑えることができます。CPUとI/Oリソースが不足している場合は、TiKV設定項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整して、バックアップタスクで使用されるワーカースレッド数を変更し、バックアップタスクがTiDBクラスタに与える影響を軽減できます。TiKVノードのバックアップ速度はスケーラブルで、50MB/秒から100MB/秒の範囲です。詳細については、 [バックアップのパフォーマンスと影響](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-backup)を参照してください。
- ログバックアップタスクのみの場合、クラスタへの影響は約5%です。ログバックアップは、3~5分ごとに最後の更新後に生成されたすべての変更をバックアップストレージにフラッシュするため、**最短5分のリカバリポイント目標(RPO)を実現できます**。
- ログバックアップタスクのみの場合、クラスタへの影響は約5%です。ログバックアップは、3~5分ごとに最後の更新後に生成されたすべての変更をバックアップストレージにフラッシュするため、**最短5分のRPO(目標復旧時点)を実現できます**。

### バックアップデータを復元する {#restore-backup-data}

Expand All @@ -88,12 +88,12 @@ TiDB BRは以下の機能を提供します。

- 任意の時点へのデータ復元(PITR)

- `br restore point`コマンドを実行すると、リカバリ時点より前の最新のスナップショットバックアップデータを復元し、指定した時点までのバックアップデータをログに記録できます。BRは復元範囲を自動的に判断し、バックアップデータにアクセスして、ターゲットクラスタにデータを復元します。
- `br restore point`コマンドを実行すると、リカバリ時点より前の最新のスナップショットバックアップデータと、指定した時点までのログバックアップデータを復元できます。BRは復元範囲を自動的に判断し、バックアップデータにアクセスして、ターゲットクラスタにデータを復元します。

#### TiDBクラスターのパフォーマンスと影響を回復する {#restore-performance-and-impact-on-tidb-clusters}
#### 復元のパフォーマンスとTiDBクラスターへの影響 {#restore-performance-and-impact-on-tidb-clusters}

- データの復元はスケーラブルな速度で実行されます。通常、速度は TiKV ノードあたり 1 GiB/秒です。詳細については、 [パフォーマンスとインパクトを回復](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-restore)をご覧ください。
- 各 TiKV ノードでは、PITR は 30 GiB/h でログデータを復元できます。詳細については、 [PITRのパフォーマンスと影響](/br/br-pitr-guide.md#performance-capabilities-of-pitr)ご覧ください
- データの復元はスケーラブルな速度で実行されます。通常、速度は TiKV ノードあたり 1 GiB/秒です。詳細については、 [復元のパフォーマンスと影響](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-restore)をご覧ください。
- 各 TiKV ノードでは、PITR は 30 GiB/時間でログデータを復元できます。詳細については、 [PITRのパフォーマンスと影響](/br/br-pitr-guide.md#performance-capabilities-of-pitr)をご覧ください

## バックアップストレージ {#backup-storage}

Expand All @@ -116,7 +116,7 @@ TiDBの一部の機能が有効化または無効化されている場合、バ
| グローバル一時テーブル | | データのバックアップと復元には、 BRのバージョン5.3.0以降を使用していることを確認してください。そうでない場合、バックアップ対象のグローバル一時テーブルの定義でエラーが発生します。 |
| TiDB Lightning物理インポート | | アップストリームデータベースがTiDB Lightningの物理インポートモードを使用している場合、ログバックアップでデータをバックアップできません。データのインポート後に完全バックアップを実行することをお勧めします。詳細については、 [上流データベースがTiDB Lightningを使用して物理インポートモードでデータをインポートすると、ログバックアップ機能が利用できなくなります。なぜでしょうか?](/faq/backup-and-restore-faq.md#when-the-upstream-database-imports-data-using-tidb-lightning-in-the-physical-import-mode-the-log-backup-feature-becomes-unavailable-why)を参照してください。 |
| TiCDC | | BR v8.2.0 以降: リストア対象のクラスターにチェンジフィードがあり、チェンジフィードの[CheckpointTS](/ticdc/ticdc-classic-architecture.md#checkpointts)が BackupTS より前の場合、 BR はリストアを実行しません。 BRバージョン v8.2.0 より前: リストア対象のクラスターにアクティブな TiCDC チェンジフィードがある場合、 BR はリストアを実行しません。 |
| ベクトル検索 | | データのバックアップと復元には、 BR v8.4.0 以降のバージョンを使用していることを確認してください。テーブルを で復元することは [ベクトルデータ型](/ai/reference/vector-search-data-types.md)v8.4.0 より前の TiDB クラスタではサポートされていません。 |
| ベクトル検索 | | データのバックアップと復元には、 BR v8.4.0 以降のバージョンを使用していることを確認してください。 [ベクトルデータ型](/ai/reference/vector-search-data-types.md)を持つテーブルを v8.4.0 より前の TiDB クラスタに復元することはサポートされていません。 |

### バージョン互換性 {#version-compatibility}

Expand Down
6 changes: 3 additions & 3 deletions br/backup-and-restore-storages.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ summary: TiDBは、Amazon S3、Google Cloud Storage、Azure Blob Storage、NFS

# バックアップストレージ {#backup-storages}

TiDBは、Amazon S3、Google Cloud Storage(GCS)、Azure Blob Storage、NFSへのバックアップデータの保存をサポートしています。具体的には、 `br`コマンドの`--storage`または`-s`のパラメータでバックアップストレージのURIを指定できます。このドキュメントでは、 [URI形式](#uri-format)[認証](#authentication)の外部ストレージサービスと、 [サーバー側の暗号化](#server-side-encryption)の外部ストレージサービスを紹介します
TiDBは、Amazon S3、Google Cloud Storage(GCS)、Azure Blob Storage、NFSへのバックアップデータの保存をサポートしています。具体的には、 `br`コマンドの`--storage`または`-s`のパラメータでバックアップストレージのURIを指定できます。このドキュメントでは、さまざまな外部ストレージサービスの[URI形式](#uri-format)[認証](#authentication)、および[サーバー側の暗号化](#server-side-encryption)について紹介します

## TiKVに資格情報を送信する {#send-credentials-to-tikv}

Expand Down Expand Up @@ -106,7 +106,7 @@ tiup br restore db --db test -u "${PD_IP}:2379" \

バックアップの前に、S3 上のバックアップディレクトリにアクセスするための次の権限を設定します。

- バックアップ中に`s3:DeleteObject`およびバックアップ & リストア ( BR ) `s3:AbortMultipartUpload`バックアップディレクトリ`s3:GetObject`アクセスするための最小権限: `s3:ListBucket` 、および`s3:PutObject`
- バックアップ中に TiKV とバックアップ&リストア(BR)がバックアップディレクトリにアクセスするための最小権限: `s3:ListBucket`、 `s3:GetObject` `s3:DeleteObject`、 `s3:PutObject`、および`s3:AbortMultipartUpload`
- 復元中に TiKV とBRがバックアップディレクトリにアクセスするための最小権限: `s3:ListBucket`と`s3:GetObject` 。

バックアップディレクトリをまだ作成していない場合は、 [バケットを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)を参照して指定のリージョンに S3 バケットを作成してください。必要に応じて、 [フォルダを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-folders.html)を参照してバケット内にフォルダを作成することもできます。
Expand Down Expand Up @@ -185,7 +185,7 @@ TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部スト

> **Note:**
>
> この方法を使用する場合は、手順 3 で TiKV を再起動する必要があります。クラスターを再起動できない場合は、 **方法 1: バックアップと復元のアクセスキーを指定する**を使用します。
> この方法を使用する場合は、手順 3 で TiKV を再起動する必要があります。クラスターを再起動できない場合は、バックアップと復元に**方法 1: アクセスキーを指定する**を使用します。
1. このノードの TiKV ポートが`24000` 、つまり systemd サービスの名前が`tikv-24000`であるとします。

```shell
Expand Down
12 changes: 6 additions & 6 deletions br/backup-and-restore-use-cases.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,18 +5,18 @@ summary: TiDBは、タイムリーなデータリカバリやビジネス監査

# TiDB バックアップと復元のユースケース {#tidb-backup-and-restore-use-cases}

[TiDB スナップショットのバックアップと復元ガイド](/br/br-snapshot-guide.md)と[TiDB ログバックアップと PITR ガイド](/br/br-pitr-guide.md) 、TiDBが提供するバックアップとリストアのソリューション、すなわちスナップショット(フル)バックアップとリストア、ログバックアップ、そしてポイントインタイムリカバリ(PITR)について紹介します。このドキュメントは、特定のユースケースにおいてTiDBのバックアップとリストアのソリューションを迅速に導入するのに役立ちます。
[TiDB スナップショットのバックアップと復元ガイド](/br/br-snapshot-guide.md)と[TiDB ログバックアップと PITR ガイド](/br/br-pitr-guide.md)、TiDBが提供するバックアップとリストアのソリューション、すなわちスナップショット(フル)バックアップとリストア、ログバックアップ、そしてポイントインタイムリカバリ(PITR)について紹介します。このドキュメントは、特定のユースケースにおいてTiDBのバックアップとリストアのソリューションを迅速に導入するのに役立ちます。

AWS に TiDB本番クラスターをデプロイし、ビジネスチームが次の要件をリクエストしているとします。

- データの変更はタイムリーにバックアップしてください。データベースに災害が発生した場合でも、最小限のデータ損失(許容できるのは数分間のデータ損失のみ)でアプリケーションを迅速に復旧できます。
- 毎月、特定の時間に業務監査を実施します。監査依頼を受けた場合、リクエストに応じて過去1ヶ月間の特定の時点のデータにクエリを実行するためのデータベースを提供する必要があります。
- 毎月、特定の時間を定めずに業務監査を実施します。監査依頼を受けた場合、リクエストに応じて過去1ヶ月間の特定の時点のデータにクエリを実行するためのデータベースを提供する必要があります。

PITR を使用すると、前述の要件を満たすことができます。

## TiDBクラスタとBRをデプロイ {#deploy-the-tidb-cluster-and-br}

PITRを使用するには、TiDBクラスタ(v6.2.0以上)をデプロイし、 BRをTiDBクラスタと同じバージョンにアップデートする必要があります。このドキュメントでは、例としてv8.5.5を使用しています
PITRを使用するには、TiDBクラスタ(v6.2.0以上)をデプロイし、 BRをTiDBクラスタと同じバージョンにアップデートする必要があります。このドキュメントでは、例としてv{{{ .tidb-version }}}を使用しています

次の表は、TiDB クラスターで PITR を使用するために推奨されるハードウェアリソースを示しています。

Expand All @@ -43,13 +43,13 @@ TiUPを使用してBRをインストールまたはアップグレードしま
- インストール:

```shell
tiup install br:v8.5.5
tiup install br:v{{{ .tidb-version }}}
```

- アップグレード:

```shell
tiup update br:v8.5.5
tiup update br:v{{{ .tidb-version }}}
```

## バックアップストレージ(Amazon S3)を構成する {#configure-backup-storage-amazon-s3}
Expand All @@ -69,7 +69,7 @@ TiUPを使用してBRをインストールまたはアップグレードしま

2. BRとTiKVがS3ディレクトリにアクセスするための権限を設定します。S3バケットにアクセスする最も安全な方法であるIAMメソッドを使用して権限を付与することをお勧めします。詳細な手順については、 [AWS ドキュメント: ユーザーポリシーによるバケットへのアクセスの制御](https://docs.aws.amazon.com/AmazonS3/latest/userguide/walkthrough1.html)を参照してください。必要な権限は次のとおりです。

- バックアップ クラスター内の TiKV とBRには`s3:GetObject` `s3://tidb-pitr-bucket/backup-data`ディレクトリ`s3:DeleteObject` `s3:ListBucket` 、および`s3:PutObject` `s3:AbortMultipartUpload`権限が必要です。
- バックアップクラスター内のTiKVとBRには、 `s3://tidb-pitr-bucket/backup-data`ディレクトリの`s3:ListBucket`、 `s3:GetObject`、 `s3:DeleteObject`、 `s3:PutObject`、および`s3:AbortMultipartUpload`権限が必要です。

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Use the bucket resource for s3:ListBucket.

s3:ListBucket is a bucket-level action. Restrict backup-data/ with the s3:prefix condition. The other actions require object resources. An object-scoped s3:ListBucket statement can leave backup or restore access denied. Apply the same distinction to the restore-cluster line.

Apply this replacement
-    - バックアップクラスター内のTiKVとBRには、 `s3://tidb-pitr-bucket/backup-data`ディレクトリの`s3:ListBucket`、 `s3:GetObject`、 `s3:DeleteObject`、 `s3:PutObject`、および`s3:AbortMultipartUpload`権限が必要です。
-    - 復元クラスター内の TiKV とBRには、 `s3://tidb-pitr-bucket/backup-data`ディレクトリの`s3:ListBucket`と`s3:GetObject`権限が必要です。
+    - バックアップクラスター内の TiKV と BR には、`tidb-pitr-bucket` バケットに対して `s3:prefix` 条件で `backup-data/` プレフィックスに制限した `s3:ListBucket` 権限と、`s3://tidb-pitr-bucket/backup-data/` 配下のオブジェクトに対する `s3:GetObject`、`s3:DeleteObject`、`s3:PutObject`、および `s3:AbortMultipartUpload` 権限が必要です。
+    - 復元クラスター内の TiKV と BR には、`tidb-pitr-bucket` バケットに対して `s3:prefix` 条件で `backup-data/` プレフィックスに制限した `s3:ListBucket` 権限と、`s3://tidb-pitr-bucket/backup-data/` 配下のオブジェクトに対する `s3:GetObject` 権限が必要です。

- 復元クラスター内の TiKV とBRには、 `s3://tidb-pitr-bucket/backup-data`ディレクトリの`s3:ListBucket`と`s3:GetObject`権限が必要です。

3. スナップショット (完全) バックアップやログバックアップなどのバックアップデータを保存するディレクトリ構造を計画します。
Expand Down
6 changes: 3 additions & 3 deletions br/br-batch-create-table.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,11 +18,11 @@ summary: TiDB v6.0.0では、データ復元時のテーブル作成プロセス

膨大な数のテーブル (たとえば 50,000 テーブル) を含むデータを復元する必要がある場合は、バッチ テーブル作成機能を使用して復元プロセスを高速化できます。

詳しい効果については[バッチテーブル作成機能のテスト](#feature-test)ご覧ください
詳しい効果については[バッチテーブル作成機能のテスト](#feature-test)をご覧ください

## バッチテーブル作成を使用する {#use-batch-create-table}

BRはデフォルトでバッチテーブル作成機能を有効にします。v6.0.0以降では、復元プロセスを高速化するために、デフォルト設定は`--ddl-batch-size=128` 。そのため、このパラメータを設定する必要はありません。`--ddl-batch-size=128`は、バッチでテーブルを作成し、各バッチで128個のテーブルを作成することを意味します。
BRはデフォルトでバッチテーブル作成機能を有効にします。v6.0.0以降では、復元プロセスを高速化するために、デフォルト設定は`--ddl-batch-size=128`です。そのため、このパラメータを設定する必要はありません。`--ddl-batch-size=128`は、バッチでテーブルを作成し、各バッチで128個のテーブルを作成することを意味します。

この機能を無効にするには、 `--ddl-batch-size`を`1`に設定します。以下のコマンド例をご覧ください。

Expand Down Expand Up @@ -62,4 +62,4 @@ tiup br restore full \
'[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]'
```

テスト結果から、1つの TiKV インスタンスを復元する平均速度は 181.65 MB/秒 ( `average-speed`に相当) であること`tikv_count`わかります
テスト結果から、1つの TiKV インスタンスを復元する平均速度は 181.65 MB/秒`average-speed`/`tikv_count`に相当)であることがわかります

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

🔎 Supported by static analysis

🏁 Script executed:

#!/bin/bash
set -e
printf '%s\n' '--- target context ---'
cat -n br/br-batch-create-table.md | sed -n '45,75p'
printf '%s\n' '--- average-speed references ---'
rg -n -i --glob '*.md' --glob '*.yaml' --glob '*.yml' --glob '*.json' 'average-speed|2\.661GB/s|181\.65|tikv_count' . | head -200

Repository: pingcap/docs

Length of output: 4173


🤖 get_repo_knowledge executed:

get_repo_knowledge pingcap/docs /tmp/coderabbit-repo-knowledge/pingcap-docs-9c73f70c/conventions

Length of output: 1294


🌐 Web query:

TiDB BR collector.go average-speed humanize 2.661GB/s unit implementation

💡 Result:

<search_synthesis>
In TiDB&#39;s Backup & Restore (BR) tool, the average-speed reported in logs is calculated in the collector.go file [1][2]. The implementation computes the speed by dividing the total data size (TotalBytes) by the total duration of the operation (totalDureTime), and then formats the result using a humanize utility [1][2]. The relevant code snippet typically looks like this: zap.String("average-speed", units.HumanSize(float64(data)/totalDureTime.Seconds)+"/s") This implementation uses the HumanSize function from a Go units package (often github.com/dustin/go-humanize or a similar internal utility) to convert the calculated float64 value (bytes per second) into a human-readable format such as "2.661GB/s" [1][2]. The value 2.661GB/s is a representation of the throughput derived from the total transferred bytes divided by the elapsed time [1][2]. Historical issues, such as GitHub issue pingcap/br#1405, have addressed accuracy concerns regarding how this average speed is computed, ensuring that the total time taken includes all relevant phases of the backup or restore process (such as checksumming) rather than just the core data transfer time [3][4].
</search_synthesis>

<source_evidence>

<title>tidb collector 源码 - seaxiang</title> https://seaxiang.com/blog/55ced6c4ee23491881c5e94100d61b65 tidb collector 源码 - seaxiang # tidb collector 源码 2022-09-19 浏览 (644) ## tidb collector 代码 文件路径:/br/pkg/summary/collector.go ``` / Copyright 2020 PingCAP, Inc. Licensed under Apache-2.0. package summary import ( "context" "strings" "sync" "time" "github.com/docker/go-units" berror "github.com/pingcap/errors" "github.com/pingcap/log" "go.uber.org/zap" ) const ( / BackupUnit tells summary in backup BackupUnit = "backup" / RestoreUnit tells summary in restore RestoreUnit = "restore" / TotalKV is a field we collect during backup/restore TotalKV = "total kv" / TotalBytes is a field we collect during backup/restore TotalBytes = "total bytes" / BackupDataSize is a field we collect after backup finish BackupDataSize = "backup data size(after compressed)" / RestoreDataSize is a field we collection after restore finish RestoreDataSize = "restore data size(after compressed)" ) / LogCollector collects infos into summary log. type LogCollector interface { SetUnit(unit string) CollectSuccessUnit(name string, unitCount int, arg interface{}) CollectFailureUnit(name string, reason error) CollectDuration(name string, t time.Duration) CollectInt(name string, t int) CollectUInt(name string, t uint64) SetSuccessStatus(success bool) Summary(name string) Log(msg string, fields ...zap.Field) } type logFunc func(msg string, fields ...zap.Field) var collector = NewLogCollector(log.Info) / InitCollector initilize global collector instance. func InitCollector( / revive:disable-line:flag-parameter hasLogFile bool, ) { logF := log.L().Info if hasLogFile { conf := new(log.Config) / Always duplicate summary to stdout. logger, _, err := log.InitLogger(conf) if err == nil { logF = func(msg string, fields ...zap.Field) { logger.Info(msg, fields...) log.Info(msg, fields...) } } } collector = NewLogCollector(logF) } type logCollector struct { mu sync.Mutex unit string successUnitCount int failureUnitCount int successCosts map[string]time.Duration successData map[string]uint64 failureReasons map[string]error durations map[string]time.Duration ints map[string]int uints map[string]uint64 successStatus bool startTime time.Time log logFunc } / NewLogCollector returns a new LogCollector. func NewLogCollector(logf logFunc) LogCollector { return &logCollector{ successUnitCount: 0, failureUnitCount: 0, successCosts: make(map[string]time.Duration), successData: make(map[string]uint64), failureReasons: make(map[string]error), durations: make(map[string]time.Duration), ints: make(map[string]int), uints: make(map[string]uint64), log: logf, startTime: time.Now(), } } func (tc *logCollector) SetUnit(unit string) { tc.mu.Lock() defer tc.mu.Unlock() tc.unit = unit } func (tc *logCollector) CollectSuccessUnit(name string, unitCount int, arg interface{}) { tc.mu.Lock() defer tc.mu.Unlock() switch v := arg.(type) { case time.Duration: tc.successUnitCount += unitCount tc.successCosts[name] += v case uint64: tc.successData[name] += v } } func (tc *logCollector) CollectFailureUnit(name string, reason error) { tc.mu.Lock() defer tc.mu.Unlock() if _, ok := tc.failureReasons[name]; !ok { tc.failureReasons[name] = reason tc.failureUnitCount++ } } func (tc *logCollector) CollectDuration(name string, t time.Duration) { tc.mu.Lock() defer tc.mu.Unlock() tc.durations[name] += t } func (tc *logCollector) CollectInt(name string, t int) { tc.mu.Lock() defer tc.mu.Unlock() tc.ints[name] += t } func (tc *logCollector) CollectUInt(name string, t uint64) { tc.mu.Lock() defer tc.mu.Unlock() tc.uints[name] += t } func (tc *logCollector) SetSuccessStatus(success bool) { tc.mu.Lock() defer tc.mu.Unlock() tc.successStatus = success } func logKeyFor(key string) string { return strings.ReplaceAll(key, " ", "-") } func (tc *logCollector) Summary(name string) { tc.mu.Lock() defer func() { tc.durations = make(map[string]time.Duration) tc.…[truncated] <title>tidb collector 源码 - seaxiang</title> https://m.seaxiang.com/blog/55ced6c4ee23491881c5e94100d61b65 tidb collector 源码 - seaxiang # tidb collector 源码 2022-09-19 浏览 (644) ## tidb collector 代码 文件路径:/br/pkg/summary/collector.go ``` / Copyright 2020 PingCAP, Inc. Licensed under Apache-2.0. package summary import ( "context" "strings" "sync" "time" "github.com/docker/go-units" berror "github.com/pingcap/errors" "github.com/pingcap/log" "go.uber.org/zap" ) const ( / BackupUnit tells summary in backup BackupUnit = "backup" / RestoreUnit tells summary in restore RestoreUnit = "restore" / TotalKV is a field we collect during backup/restore TotalKV = "total kv" / TotalBytes is a field we collect during backup/restore TotalBytes = "total bytes" / BackupDataSize is a field we collect after backup finish BackupDataSize = "backup data size(after compressed)" / RestoreDataSize is a field we collection after restore finish RestoreDataSize = "restore data size(after compressed)" ) / LogCollector collects infos into summary log. type LogCollector interface { SetUnit(unit string) CollectSuccessUnit(name string, unitCount int, arg interface{}) CollectFailureUnit(name string, reason error) CollectDuration(name string, t time.Duration) CollectInt(name string, t int) CollectUInt(name string, t uint64) SetSuccessStatus(success bool) Summary(name string) Log(msg string, fields ...zap.Field) } type logFunc func(msg string, fields ...zap.Field) var collector = NewLogCollector(log.Info) / InitCollector initilize global collector instance. func InitCollector( / revive:disable-line:flag-parameter hasLogFile bool, ) { logF := log.L().Info if hasLogFile { conf := new(log.Config) / Always duplicate summary to stdout. logger, _, err := log.InitLogger(conf) if err == nil { logF = func(msg string, fields ...zap.Field) { logger.Info(msg, fields...) log.Info(msg, fields...) } } } collector = NewLogCollector(logF) } type logCollector struct { mu sync.Mutex unit string successUnitCount int failureUnitCount int successCosts map[string]time.Duration successData map[string]uint64 failureReasons map[string]error durations map[string]time.Duration ints map[string]int uints map[string]uint64 successStatus bool startTime time.Time log logFunc } / NewLogCollector returns a new LogCollector. func NewLogCollector(logf logFunc) LogCollector { return &logCollector{ successUnitCount: 0, failureUnitCount: 0, successCosts: make(map[string]time.Duration), successData: make(map[string]uint64), failureReasons: make(map[string]error), durations: make(map[string]time.Duration), ints: make(map[string]int), uints: make(map[string]uint64), log: logf, startTime: time.Now(), } } func (tc *logCollector) SetUnit(unit string) { tc.mu.Lock() defer tc.mu.Unlock() tc.unit = unit } func (tc *logCollector) CollectSuccessUnit(name string, unitCount int, arg interface{}) { tc.mu.Lock() defer tc.mu.Unlock() switch v := arg.(type) { case time.Duration: tc.successUnitCount += unitCount tc.successCosts[name] += v case uint64: tc.successData[name] += v } } func (tc *logCollector) CollectFailureUnit(name string, reason error) { tc.mu.Lock() defer tc.mu.Unlock() if _, ok := tc.failureReasons[name]; !ok { tc.failureReasons[name] = reason tc.failureUnitCount++ } } func (tc *logCollector) CollectDuration(name string, t time.Duration) { tc.mu.Lock() defer tc.mu.Unlock() tc.durations[name] += t } func (tc *logCollector) CollectInt(name string, t int) { tc.mu.Lock() defer tc.mu.Unlock() tc.ints[name] += t } func (tc *logCollector) CollectUInt(name string, t uint64) { tc.mu.Lock() defer tc.mu.Unlock() tc.uints[name] += t } func (tc *logCollector) SetSuccessStatus(success bool) { tc.mu.Lock() defer tc.mu.Unlock() tc.successStatus = success } func logKeyFor(key string) string { return strings.ReplaceAll(key, " ", "-") } func (tc *logCollector) Summary(name string) { tc.mu.Lock() defer func() { tc.durations = make(map[string]time.Duration) tc.…[truncated] <title>restore: the average speed isn&`#39`;t accurate · Issue `#1405` · pingcap/br</title> GitHub issue 1405 in pingcap/br (link omitted to avoid creating a cross-reference) # Issue: pingcap/br `#1405` - Repository: pingcap/br | A command-line tool for distributed backup and restoration of the TiDB cluster data | 127 stars | Go ## restore: the average speed isn&`#39`;t accurate - Author: [`@YuJuncen`](https://github.com/YuJuncen) - Association: COLLABORATOR - State: closed (completed) - Locked: true - Labels: type/bug, severity/major, component/backup, component/restore - Created: 2021-08-03T09:11:00Z - Updated: 2021-10-27T09:54:15Z - Closed: 2021-10-27T09:54:15Z - Closed by: [`@YuJuncen`](https://github.com/YuJuncen) Please answer these questions before submitting your issue. Thanks! 1. What did you do? Simply run a restore, and it succeed. [Image: image | https://user-images.githubusercontent.com/36239017/127989634-310f8c64-cb22-4b4a-856a-7375054b3e00.png] 1. What did you expect to see? The rate should be computed by `totalKVSize / realTimeTake` (according to the log, it should be about `680 MB/s`). 1. What did you see instead? `[average-speed=2.424MB/s] ` 1. What version of BR and TiDB/TiKV/PD are you using? ``` cluster : v5.1.0 BR : master ``` --- ### Timeline **YuJuncen** added label `type/bug`; added label `component/backup`; added label `component/restore` · Aug 3, 2021 at 9:11am **fubinzh** added label `severity/major` · Aug 3, 2021 at 9:56am **joccau** mentioned this in PR [`#1408`: Fix speed compute](https://github.com/pingcap/br/pull/1408) · Aug 4, 2021 at 2:22am **ti-chi-bot** mentioned this in PR [`#1410`: Fix speed compute (`#1408`)](https://github.com/pingcap/br/pull/1410) · Aug 4, 2021 at 8:57am **ti-chi-bot** mentioned this in PR [`#1411`: Fix speed compute (`#1408`)](https://github.com/pingcap/br/pull/1411); mentioned this in PR [`#1412`: Fix speed compute (`#1408`)](https://github.com/pingcap/br/pull/1412) · Aug 4, 2021 at 8:59am **`@YuJuncen`** commented · Oct 27, 2021 at 9:54am · Author > should be fixed by `#1408` :) **YuJuncen** closed this · Oct 27, 2021 at 9:54am <title>summary: add real time cost to log collector (`#480`) · Issue `#486` · pingcap/br</title> GitHub issue 486 in pingcap/br (link omitted to avoid creating a cross-reference) # Issue: pingcap/br `#486` - Repository: pingcap/br | A command-line tool for distributed backup and restoration of the TiDB cluster data | 127 stars | Go ## summary: add real time cost to log collector (`#480`) - Author: [`@ti-srebot`](https://github.com/ti-srebot) - Association: CONTRIBUTOR - State: closed - Locked: true - Labels: status/LGT2 - Created: 2020-09-02T05:49:08Z - Updated: 2020-09-03T07:17:52Z - Closed: 2020-09-03T07:17:52Z - Closed by: [`@ti-srebot`](https://github.com/ti-srebot) cherry-pick `#480` to release-4.0 --- Signed-off-by: Hillium <maruruku@stu.csust.edu.cn> ### What problem does this PR solve? implement `#478` ### What is changed and how it works? We make serval changes to make the log of time cost correct: 1. collect kv and size each time of importing. https://github.com/pingcap/br/blob/d9d6207c0aa7bad470093683427338053435e1ba/pkg/restore/import.go#L328-L331 1. a log of real time cost is added to the summary. 2. collect the success unit when checksumming, so the total cost field would be (the time of restoring + the time of checksumming) instead of just the time of restoring. ### Check List Tests [Image: image | https://user-images.githubusercontent.com/36239017/91679842-f7da3900-eb7b-11ea-987d-e6e4c066a616.png] - Manual test (add detailed scripts or steps below) ### Release Note - Add real time cost to log. --- ### Timeline **Hillium** pushed commit `bc29f55`: summary: add real time cost to log collector; pushed commit `06f36c1`: summary: rename TiKV service time to $name time; pushed commit `06cd25a`: restore: fix a typo · Sep 2, 2020 at 5:49am **ti-srebot** mentioned this in PR [`#480`: summary: add real time cost to log collector](https://github.com/pingcap/br/pull/480); added label `cherry-pick`; requested review from [`@3pointer`](https://github.com/3pointer); requested review from [`@kennytm`](https://github.com/kennytm); requested review from [`@overvenus`](https://github.com/overvenus) · Sep 2, 2020 at 5:49am **`@3pointer`** commented · Sep 2, 2020 at 8:52am > **Review (approved):** > LGTM **ti-srebot** added label `status/LGT1` · Sep 2, 2020 at 8:52am **overvenus** reviewed: approved · Sep 3, 2020 at 4:50am **ti-srebot** removed label `status/LGT1`; added label `status/LGT2` · Sep 3, 2020 at 4:50am **`@kennytm`** commented · Sep 3, 2020 at 7:10am > /merge **ti-srebot** added label `CanMerge` · Sep 3, 2020 at 7:10am **`@ti-srebot`** commented · Sep 3, 2020 at 7:10am · Author > /run-all-tests **ti-srebot** merged this pull request; closed this · Sep 3, 2020 at 7:17am <title>Duplicate attributes in BR json log for pitr · Issue `#53645` · pingcap/tidb</title> GitHub issue 53645 in pingcap/tidb (link omitted to avoid creating a cross-reference) # Issue: pingcap/tidb `#53645` - Repository: pingcap/tidb | TiDB - the open-source, cloud-native, distributed SQL database designed for modern applications. | 40K stars | Go ## Duplicate attributes in BR json log for pitr - Author: [`@dveeden`](https://github.com/dveeden) - Association: CONTRIBUTOR - State: closed (completed) - Labels: type/bug, severity/minor, component/br - Created: 2024-05-29T06:57:29Z - Updated: 2024-05-31T08:28:25Z - Closed: 2024-05-31T08:28:25Z - Closed by: [`@ti-chi-bot`[bot]](https://github.com/ti-chi-bot[bot]) ## Bug Report The `"restore log success summary"` looks like this in the output of `br`: ``` [2024/05/29 08:40:10.537 +02:00] [INFO] [collector.go:77] ["restore log success summary"] [total-take=3.607614879s] [restore-from=450091587356590086] [restore-to=450091627315200000] [restore-from="2024-05-29 08:12:27.57 +0200"] [restore-to="2024-05-29 08:15:00 +0200"] [total-kv-count=2] [skipped-kv-count-by-checkpoint=0] [total-size=191B] [skipped-size-by-checkpoint=0B] [average-speed=52.94B/s] ``` And when using `--log-format json` this looks like this: ```json {"level":"INFO","time":"2024/05/29 08:43:01.784 +02:00","caller":"collector.go:78","message":"restore log success summary","total-take":"3.595453335s","restore-from":450091587356590086,"restore-to":450091627315200000,"restore-from":"2024-05-29 08:12:27.57 +0200","restore-to":"2024-05-29 08:15:00 +0200","total-kv-count":2,"skipped-kv-count-by-checkpoint":0,"total-size":"191B","skipped-size-by-checkpoint":"0B","average-speed":"53.12B/s"} ``` When using `jq` to do display/filtering/etc it looks like this: ```json { "level": "INFO", "time": "2024/05/29 08:43:01.784 +02:00", "caller": "collector.go:78", "message": "restore log success summary", "total-take": "3.595453335s", "restore-from": "2024-05-29 08:12:27.57 +0200", "restore-to": "2024-05-29 08:15:00 +0200", "total-kv-count": 2, "skipped-kv-count-by-checkpoint": 0, "total-size": "191B", "skipped-size-by-checkpoint": "0B", "average-speed": "53.12B/s" } ``` The problem here is that there are duplicate keys in this output for `restore-to` and `restore-from`. Once with the TS and once with the human readable timestamp. Suggestion: Rename one of these for each group to avoid duplicate attributes. --- ### Timeline **dveeden** added label `type/bug`; added label `component/br` · May 29, 2024 at 6:57am **dveeden** mentioned this in PR [`#53649`: br: Enhance stream restore logs](https://github.com/pingcap/tidb/pull/53649) · May 29, 2024 at 7:08am **dveeden** added label `severity/minor` · May 29, 2024 at 7:09am **ti-chi-bot[bot]** closed this; closed this · May 31, 2024 at 8:28am

Citations:


🌐 Web query:

site:github.com/pingcap/br v6.0.0 pkg/summary/collector.go github.com/docker/go-units HumanSize average-speed

💡 Result:

<search_synthesis>
I can’t directly answer “v6.0.0 pkg/summary/collector.go github.com/docker/go-units HumanSize average-speed” as a single coherent statement without knowing which specific repository/version “v6.0.0” refers to and what you want (e.g., the exact code snippet for average-speed logging, or how HumanSize formats it). What I can say from the sources I found is that “average-speed” in a Go collector for backup/restore is computed from total size divided by a measured “real time” duration, and there were known bugs where the computed average speed was incorrect. For example, an issue describes that the expected rate should be computed by totalKVSize / realTimeTake, but the logs showed an incorrect average-speed value (2.424MB/s instead of ~680MB/s) [1]. Another issue describes “Full restore success summary” logging an “average-speed=584.5kB/s” field in collector.go output [2]. Additionally, in that same codebase, the PRs clarify summary field semantics: the restore summary’s “size” corresponds to “restore data size(after decompressed)”, and “data-size” was renamed to “total-kv-size” [3]. A separate PR (“summary: add real time cost to log collector”) indicates the collector was updated to include real time cost [4]. If you tell me: 1) which exact GitHub repo/tag “v6.0.0” is from, 2) whether you want the formula used for average-speed in pkg/summary/collector.go, 3) whether you want how docker/go-units HumanSize is applied to that value, …I can re-run targeted searches to locate the exact collector.go implementation for that version and provide a precise, code-referenced answer.
</search_synthesis>

<source_evidence>

<title>restore: the average speed isn&`#39`;t accurate · Issue `#1405` · pingcap/br</title> GitHub issue 1405 in pingcap/br (link omitted to avoid creating a cross-reference) # Issue: pingcap/br `#1405` - Repository: pingcap/br | A command-line tool for distributed backup and restoration of the TiDB cluster data | 127 stars | Go ## restore: the average speed isn&`#39`;t accurate - Author: [`@YuJuncen`](https://github.com/YuJuncen) - Association: COLLABORATOR - State: closed (completed) - Locked: true - Labels: type/bug, severity/major, component/backup, component/restore - Created: 2021-08-03T09:11:00Z - Updated: 2021-10-27T09:54:15Z - Closed: 2021-10-27T09:54:15Z - Closed by: [`@YuJuncen`](https://github.com/YuJuncen) Please answer these questions before submitting your issue. Thanks! 1. What did you do? Simply run a restore, and it succeed. [Image: image | https://user-images.githubusercontent.com/36239017/127989634-310f8c64-cb22-4b4a-856a-7375054b3e00.png] 1. What did you expect to see? The rate should be computed by `totalKVSize / realTimeTake` (according to the log, it should be about `680 MB/s`). 1. What did you see instead? `[average-speed=2.424MB/s] ` 1. What version of BR and TiDB/TiKV/PD are you using? ``` cluster : v5.1.0 BR : master ``` --- ### Timeline **YuJuncen** added label `type/bug`; added label `component/backup`; added label `component/restore` · Aug 3, 2021 at 9:11am **fubinzh** added label `severity/major` · Aug 3, 2021 at 9:56am **joccau** mentioned this in PR [`#1408`: Fix speed compute](https://github.com/pingcap/br/pull/1408) · Aug 4, 2021 at 2:22am **ti-chi-bot** mentioned this in PR [`#1410`: Fix speed compute (`#1408`)](https://github.com/pingcap/br/pull/1410) · Aug 4, 2021 at 8:57am **ti-chi-bot** mentioned this in PR [`#1411`: Fix speed compute (`#1408`)](https://github.com/pingcap/br/pull/1411); mentioned this in PR [`#1412`: Fix speed compute (`#1408`)](https://github.com/pingcap/br/pull/1412) · Aug 4, 2021 at 8:59am **`@YuJuncen`** commented · Oct 27, 2021 at 9:54am · Author > should be fixed by `#1408` :) **YuJuncen** closed this · Oct 27, 2021 at 9:54am <title>br restore statistics not correct if restore with -f parameters · Issue `#1270` · pingcap/br</title> GitHub issue 1270 in pingcap/br (link omitted to avoid creating a cross-reference) [2021/06/23 01:56:29.793 -04:00] [INFO] [collector.go:66] ["Full restore success summary"] [total-ranges=44] [ranges-succeed=44] [ranges-failed=0] [split-region=601.358689ms] [restore-checksum=43.793886ms] [restore-ranges=19] [total-take=6.156156669s] ["restore data size(after decompressed)"=7.426GB] [total-kv=3345] [total-kv-size=287kB] [average-speed=584.5kB/s] ... 2.log ... Full restore <---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|> 100.00%[2021/06/23 01:56:29.111 -04:00] [WARN] [systable_restore.go:94] ["error during merging temporary tables into system tables"] [error="[BR:Restore:ErrUnsupportedSysTable]restoring stats via `mysql` schema isn&`#39`;t support yet: the table ID is out-of-date and may corrupt existing statistics"] [table=stats_meta] ... [2021/06/23 01:56:29.793 -04:00] [INFO] [collector.go:66] ["Full restore success summary"] [total-ranges=44] [ranges-succeed=44] [ranges-failed=0] [split-region=601.358689ms] [restore-checksum=43.793886ms] [restore-ranges=19] [total-take=6.156156669s] ["restore data size(after decompressed)"=7.426GB] [total-kv=3345] [total-kv-size=287kB] [average-speed=584.5kB/s] ... > For problem 1, the `restore data size` field is read from backup meta file, so this statistics is not correct, we will fix it soon. As for problem 2, can you provide more info, like before the backup you having two tables, and after the restore, you only get one table restored? ... > For problem 2, I mean the restore data size is not correct if I only restore one table from the backup (which contains 2 tables). > It is not restore failure or data loss, only stats issue. Sorry for confusion. ... > `@fubinzh` We will fix the restore data size problem soon ... ZipFast** mentioned this in PR ... , 2 <title>err_msg: clarify some ambiguous error message (`#1076`) · Pull Request `#1132` · pingcap/br</title> GitHub pull request 1132 in pingcap/br (link omitted to avoid creating a cross-reference) Clarify the summary info including: ... - `data-size => total kv size` - `size => backup data size(after compressed)` ... 1. Adjust the backup and restore summary: ... - the `data-size` field has been changed to `total-kv-size` - the `size` field in backup summary has been changed to `backup data size(after compressed)` - the `size` field in restore summary has been changed to `restore data size(after decompressed)` ... [20 ... 37:28.517 +08:00] ... push.go:147] ["backup occur unknown error"] [error="Io(Os { code: 13, kind: PermissionDenied...})"] [stack=" ... .com/pingcap/br/pkg ... backup.(*pushDown ... pushBackup\n\ ... pingcap/br ... pkg/backup ... Client).Backup ... 2.1\n\ ... /home/ ... j/log_improve/br/pkg/backup/client. ... 76\ ... /pingcap ... br/pkg/utils ... WorkerPool).ApplyOnError ... /home/ ... j/log_improve/br/pkg/utils/worker.go:63\ngolang.org/x/sync/errgroup.(*Group).Go.func1\n\t/root/go/pkg/mod/golang.org/x/sync@v0.0.0-20201020160332-67f06af15bc9/errgroup/errgroup.go:57"] ... ``` [2021/05/19 15:43:43.305 +08:00] [ERROR] [push.go:175] [error="[BR:KV:ErrKVStorage]tikv storage occur I/O error: I/O permission denied error occurs on TiKV Node(store id: 1; Address: 127.0.0.1:20162)"] ["work around"="please ensure tikv has permission to read from & write to the storage."] [stack="github.com/pingcap/br/pkg/backup.(*pushDown).pushBackup\n\t/home/zwj/log_improve/br/pkg/backup/push.go:175\ngithub.com/pingcap/br/pkg/backup.(*Client).BackupRange\n\t/home/zwj/log_improve/br/pkg/backup/client.go:540\ngithub.com/pingcap/br/pkg/backup.(*Client).BackupRanges.func2.1\n\t/home/zwj/log_improve/br/pkg/backup/client.go:476\ngithub.com/pingcap/br/pkg/utils.(*WorkerPool).ApplyOnErrorGroup.func1\n\t/home/zwj/log_improve/br/pkg/utils/worker.go:63\ngolang.org/x/sync/errgroup.(*Group).Go.func1\n\t/root/go/pkg/mod/golang.org/x/sync@v0.0.0-20201020160332-67f06af15bc9/errgroup/errgroup.go:57"] ... 1. Summary message have improve, data-size => total-kv-size and size => backup data size(after compressed) [Image: image | https://user-images.githubusercontent.com/23160968/118622459-ec0dd000-b7f9-11eb-952d-e90c47879624.png] <title>summary: add real time cost to log collector (`#480`)</title> GitHub pull request 486 in pingcap/br (link omitted to avoid creating a cross-reference) # summary: add real time cost to log collector (`#480`) - State: merged - Author: ti-srebot - Created: 2020-09-02T05:49:08Z - Updated: 2020-09-03T07:17:52Z - Repository: pingcap/br - Number: `#486` - +7 -3 in 3 files - Merged: 2020-09-03T07:17:52Z - Merge commit: 89879c7bf40d70fe9383a9b9d4f9205a7fdb8496 - Reviewers: kennytm ## Labels - status/LGT2 --- cherry-pick `#480` to release-4.0 --- Signed-off-by: Hillium <maruruku@stu.csust.edu.cn> <title>collector: remove cputime (`#970`)</title> GitHub pull request 1009 in pingcap/br (link omitted to avoid creating a cross-reference) # collector: remove cputime (`#970`) - State: merged - Author: ti-srebot - Created: 2021-04-14T08:18:32Z - Updated: 2021-04-15T09:43:55Z - Repository: pingcap/br - Number: `#1009` - +35 -35 in 4 files - Merged: 2021-04-15T09:43:55Z - Merge commit: 6ec2592e02d7587b65d48bd11ccb3ccc28e6dd11 - Reviewers: kennytm, 3pointer ## Labels - status/LGT2 - status/can-merge - component/backup - component/restore - type/5.0-cherry-pick - size/M - cherry-pick-approved --- cherry-pick `#970` to release-5.0 You can switch your code base to this Pull Request by using [git-extras](https://github.com/tj/git-extras): ```bash # In br repo: git pr https://github.com/pingcap/br/pull/1009 ``` After apply modifications, you can push your change to this PR via: ```bash git push git@github.com:ti-srebot/br.git pr/1009:release-5.0-aa5729a5a16f ``` ---

Citations:

  • 1: GitHub issue 1405 in pingcap/br (link omitted to avoid creating a cross-reference)
  • 2: GitHub issue 1270 in pingcap/br (link omitted to avoid creating a cross-reference)
  • 3: GitHub pull request 1132 in pingcap/br (link omitted to avoid creating a cross-reference)
  • 4: GitHub pull request 486 in pingcap/br (link omitted to avoid creating a cross-reference)

Use the decimal per-instance speed.

BR formats average-speed with decimal prefixes, so 2.661GB/s ÷ 15 is approximately 177.4 MB/s. 181.65 is not supported by the logged value, and changing the unit to MiB/s would not correct the calculation.

Suggested replacement
Suggested change
テスト結果から、1つの TiKV インスタンスを復元する平均速度は 181.65 MB/秒( `average-speed`/`tikv_count`に相当)であることがわかります。
テスト結果から、1つの TiKV インスタンスを復元する平均速度は約 177.4 MB/秒( `average-speed`/`tikv_count`に相当)であることがわかります。

Source: Path instructions

Loading
Loading