-TiUPを使用して v8.5.4 以降の新しい TiDB クラスタをデプロイする場合、新しいアーキテクチャで TiCDC ノードも同時にデプロイできます。そのためには、 TiUP がTiDB クラスタの起動に使用する構成ファイルに TiCDC 関連のセクションを追加し、 `newarch: true`を設定するだけです。以下に例を示します。
+TiUPを使用して v8.5.4 以降の新しい TiDB クラスタをデプロイする場合、新しいアーキテクチャで TiCDC ノードも同時にデプロイできます。そのためには、 TiUP がTiDB クラスタの起動に使用する設定ファイルに TiCDC 関連のセクションを追加し、 `newarch: true`を設定するだけです。以下に例を示します。
```yaml
cdc_servers:
@@ -139,7 +139,7 @@ TiCDC デプロイメントの詳細については、 [TiUPを使用してTiCDC
-TiDB Operator を使用して v8.5.4 以降の新しい TiDB クラスタをデプロイする場合、新しいアーキテクチャで TiCDC ノードを同時にデプロイすることもできます。そのためには、クラスタ構成ファイルに TiCDC 関連のセクションを追加し、 `newarch = true`を設定するだけです。以下に例を示します。
+TiDB Operator を使用して v8.5.4 以降の新しい TiDB クラスタをデプロイする場合、新しいアーキテクチャで TiCDC ノードを同時にデプロイすることもできます。そのためには、クラスタ設定ファイルに TiCDC 関連のセクションを追加し、 `newarch = true`を設定するだけです。以下に例を示します。
```yaml
spec:
@@ -212,7 +212,7 @@ TiUPを使用して新しいアーキテクチャにTiCDCノードをデプロ
TiDB Operatorを使用して既存のTiDBクラスタに新しいアーキテクチャでTiCDCノードをデプロイするには、次の手順を実行します。
-- TiDB クラスターに TiCDCコンポーネントが含まれていない場合は、 [既存のTiDBクラスタにTiCDCを追加する](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-ticdc/#add-ticdc-to-an-existing-tidb-cluster)を参照して、新しい TiCDC ノードを追加します。その際、クラスター構成ファイルで TiCDC イメージのバージョンを新しいアーキテクチャのバージョンとして指定します。利用可能なバージョンについては、 [TiCDCが新アーキテクチャ向けにリリース](https://github.com/pingcap/ticdc/releases)を参照してください。
+- TiDB クラスターに TiCDCコンポーネントが含まれていない場合は、 [既存のTiDBクラスタにTiCDCを追加する](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-ticdc/#add-ticdc-to-an-existing-tidb-cluster)を参照して、新しい TiCDC ノードを追加します。その際、クラスター設定ファイルで TiCDC イメージのバージョンを新しいアーキテクチャのバージョンとして指定します。利用可能なバージョンについては、 [TiCDCが新アーキテクチャ向けにリリース](https://github.com/pingcap/ticdc/releases)を参照してください。
例えば：
@@ -239,7 +239,7 @@ TiDB Operatorを使用して既存のTiDBクラスタに新しいアーキテク
/cdc cli changefeed pause --server=http://127.0.0.1:8301 --changefeed-id
```
- 2. クラスタ構成ファイル内のTiCDCイメージバージョンを新しいアーキテクチャバージョンに更新してください。
+ 2. クラスタ設定ファイル内のTiCDCイメージバージョンを新しいアーキテクチャバージョンに更新してください。
```shell
kubectl edit tc ${cluster_name} -n ${namespace}
diff --git a/ticdc/ticdc-bidirectional-replication.md b/ticdc/ticdc-bidirectional-replication.md
index 7b61b24f57225..6c1ee7a44f67d 100644
--- a/ticdc/ticdc-bidirectional-replication.md
+++ b/ticdc/ticdc-bidirectional-replication.md
@@ -25,7 +25,7 @@ TiCDCは、指定されたタイムスタンプ以降に発生した増分デー
2. changefeed を作成する際、上流クラスターの changefeed の`--start-ts`を対応する`tso`に設定します。つまり、上流クラスターが TiDB 1 の場合は`--start-ts=1` 、下流クラスターが TiDB 2 の場合は`--start-ts=2`を設定します。
-4. `--config`パラメータで指定された構成ファイルに、次の構成を追加します。
+4. `--config`パラメータで指定された設定ファイルに、次の設定を追加します。
```toml
# Whether to enable the bidirectional replication mode
diff --git a/ticdc/ticdc-changefeed-config.md b/ticdc/ticdc-changefeed-config.md
index 62250045689d1..74daa86bdf1cc 100644
--- a/ticdc/ticdc-changefeed-config.md
+++ b/ticdc/ticdc-changefeed-config.md
@@ -3,7 +3,7 @@ title: CLI and Configuration Parameters of TiCDC Changefeeds
summary: TiCDCチェンジフィードのCLIの定義と設定パラメータについて学びましょう。
---
-# TiCDC ChangefeedsのCLIとコンフィグレーションパラメータ {#cli-and-configuration-parameters-of-ticdc-changefeeds}
+# TiCDC ChangefeedsのCLIと設定パラメータ {#cli-and-configuration-parameters-of-ticdc-changefeeds}
## 変更フィードCLIパラメータ {#changefeed-cli-parameters}
@@ -46,7 +46,7 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl
### `case-sensitive` {#case-sensitive}
-- 構成ファイル内のデータベース名とテーブルが大文字と小文字を区別するかどうかを指定します。v6.5.6、v7.1.3、v7.5.0 以降、デフォルト値は`true`から`false`に変更されます。
+- 設定ファイル内のデータベース名とテーブルが大文字と小文字を区別するかどうかを指定します。v6.5.6、v7.1.3、v7.5.0 以降、デフォルト値は`true`から`false`に変更されます。
- この設定項目は、フィルターとシンクに関連する設定に影響します。
- デフォルト値: `false`
diff --git a/ticdc/ticdc-classic-architecture.md b/ticdc/ticdc-classic-architecture.md
index de2bcfb2ecbcc..d30cf67b062f2 100644
--- a/ticdc/ticdc-classic-architecture.md
+++ b/ticdc/ticdc-classic-architecture.md
@@ -59,7 +59,7 @@ dispatchers = [
]
```
-前述の`cdc cli changefeed create`コマンドのパラメータの詳細については、 [TiCDC Changefeedコンフィグレーションパラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。
+前述の`cdc cli changefeed create`コマンドのパラメータの詳細については、 [TiCDC Changefeed設定パラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。
上記のコマンド`cdc cli changefeed create`は、 `test1.tab1` 、 `test1.tab2` 、 `test3.tab3` 、 `test4.tab4` Kafkaクラスターに複製する changefeed タスクを作成します。TiCDCがこのコマンドを受信した後の処理フローは以下のとおりです。
diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md
index 9d081844fd5d4..db3b677fa4aa1 100644
--- a/ticdc/ticdc-ddl.md
+++ b/ticdc/ticdc-ddl.md
@@ -78,7 +78,7 @@ TiCDC は通常 DDL文を順番にレプリケートしますが、ダウンス
DDL文で単一のテーブル名を変更する場合、TiCDCは古いテーブル名がフィルタールールに一致する場合にのみ、そのDDL文を複製します。以下に例を示します。
-changefeed の構成ファイルが次のようになっていると仮定します。
+changefeed の設定ファイルが次のようになっていると仮定します。
```toml
[filter]
@@ -101,7 +101,7 @@ DDL文で複数のテーブルの名前を変更する場合、TiCDC は、**古
また、TiCDCはテーブル名を入れ替える`RENAME TABLE` DDLをサポートしていません。以下に例を示します。
-changefeed の構成ファイルが次のようになっていると仮定します。
+changefeed の設定ファイルが次のようになっていると仮定します。
```toml
[filter]
@@ -125,7 +125,7 @@ TiCDC はこのタイプの DDL を次のように処理します。
フィルタリングされたDDL文がテーブルの作成または削除を伴う場合、TiCDCはDML文のレプリケーション動作に影響を与えることなく、DDL文のみをフィルタリングします。以下に例を示します。
-changefeed の構成ファイルが次のようになっていると仮定します。
+changefeed の設定ファイルが次のようになっていると仮定します。
```toml
[filter]
diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md
index 70d5bf6756bf5..c793e148d05e2 100644
--- a/ticdc/ticdc-faq.md
+++ b/ticdc/ticdc-faq.md
@@ -193,7 +193,7 @@ TiCDC がサービス GC セーフポイントに設定するデフォルトの
| | 上流タイムゾーン | TiCDCタイムゾーン | 下流タイムゾーン |
| :----------: | :-------------------------------------------------------------------------: | :----------------------------------------------------------------------------------: | :------------------------------------------------------------------------------: |
-| コンフィグレーション方法 | [タイムゾーンのサポート](/configure-time-zone.md)参照 | TiCDCサーバーを起動するときに`--tz`パラメータを使用して設定されます | `sink-uri`の`time-zone`パラメータを使用して設定します。このパラメータは、シンクが`mysql`または`tidb`の場合のみ有効です。 |
+| 設定方法 | [タイムゾーンのサポート](/configure-time-zone.md)参照 | TiCDCサーバーを起動するときに`--tz`パラメータを使用して設定されます | `sink-uri`の`time-zone`パラメータを使用して設定します。このパラメータは、シンクが`mysql`または`tidb`の場合のみ有効です。 |
| 説明 | アップストリーム TiDB のタイムゾーン。タイムスタンプ タイプの DML 操作と、タイムスタンプ タイプの列に関連する DDL 操作に影響します。 | TiCDC は、アップストリーム TiDB のタイムゾーンが TiCDC のタイムゾーン構成と同じであると想定し、タイムスタンプ列に対して関連する操作を実行します。 | ダウンストリーム`mysql`および`tidb`シンクは、接続セッションのタイムゾーン設定に従って、DML および DDL 操作のタイムスタンプを処理します。 |
> **Note:**
@@ -208,7 +208,7 @@ TiCDC がサービス GC セーフポイントに設定するデフォルトの
> - `--tz`利用できない場合、TiCDC は`TZ`環境変数を使用してタイムゾーン セットを読み取ろうとします。
> - `TZ`環境変数が使用できない場合、TiCDC はマシンのデフォルトのタイムゾーンを使用します。
-## `--config`で構成ファイルを指定せずにレプリケーションタスクを作成した場合、TiCDC のデフォルトの動作はどうなりますか? {#what-is-the-default-behavior-of-ticdc-if-i-create-a-replication-task-without-specifying-the-configuration-file-in---config}
+## `--config`で設定ファイルを指定せずにレプリケーションタスクを作成した場合、TiCDC のデフォルトの動作はどうなりますか? {#what-is-the-default-behavior-of-ticdc-if-i-create-a-replication-task-without-specifying-the-configuration-file-in---config}
`-config`パラメータを指定せずに`cdc cli changefeed create`コマンドを使用すると、TiCDC は次のデフォルト動作でレプリケーションタスクを作成します。
@@ -385,7 +385,7 @@ TiDB Lightning物理インポートモードを使用してインポートされ
cdc cli changefeed create -c "upstream-to-downstream-some-tables" --start-ts=431434047157698561 --sink-uri="mysql://root@127.0.0.1:4000?time-zone="
```
-TiDB Lightning物理インポートモードによってインポートされたテーブルが、どの変更フィードによっても監視されるテーブルと重複しない場合は、TiDB Lightning構成ファイルで[`check-requirements`](/tidb-lightning/tidb-lightning-configuration.md#check-requirements)を`false`に設定して、データのインポートを強制できます。
+TiDB Lightning物理インポートモードによってインポートされたテーブルが、どの変更フィードによっても監視されるテーブルと重複しない場合は、TiDB Lightning設定ファイルで[`check-requirements`](/tidb-lightning/tidb-lightning-configuration.md#check-requirements)を`false`に設定して、データのインポートを強制できます。
## BRと TiCDC 間の互換性の制限は何ですか? {#what-are-the-compatibility-limitations-between-br-and-ticdc}
@@ -421,7 +421,7 @@ TiCDC v6.5.2より前のバージョンでは、TiCDCをダウンストリーム
## 単一テーブルのレプリケーションは単一のTiCDCノードでのみ実行できます。複数のTiCDCノードを使用して複数テーブルのデータをレプリケーションすることは可能ですか？ {#replication-of-a-single-table-can-only-be-run-on-a-single-ticdc-node-will-it-be-possible-to-use-multiple-ticdc-nodes-to-replicate-data-of-multiple-tables}
-v7.1.0以降、TiCDCはMQシンクをサポートし、TiKVリージョンの粒度でデータ変更ログを複製します。これによりスケーラブルな処理能力が実現され、TiCDCは単一のテーブルを多数のリージョンに複製できます。この機能を有効にするには、 [TiCDC チェンジフィード構成ファイル](/ticdc/ticdc-changefeed-config.md)で以下のパラメータを設定します。
+v7.1.0以降、TiCDCはMQシンクをサポートし、TiKVリージョンの粒度でデータ変更ログを複製します。これによりスケーラブルな処理能力が実現され、TiCDCは単一のテーブルを多数のリージョンに複製できます。この機能を有効にするには、 [TiCDC チェンジフィード設定ファイル](/ticdc/ticdc-changefeed-config.md)で以下のパラメータを設定します。
```toml
[scheduler]
diff --git a/ticdc/ticdc-integrity-check.md b/ticdc/ticdc-integrity-check.md
index c910e685ba47a..cb2c3f5a13901 100644
--- a/ticdc/ticdc-integrity-check.md
+++ b/ticdc/ticdc-integrity-check.md
@@ -43,7 +43,7 @@ TiCDCはデフォルトでデータ整合性検証を無効にしています。
TiCDC disables data integrity validation by default. To disable this feature after enabling it, perform the following steps:
-1. [Update task configuration](/ticdc/ticdc-manage-changefeed.md#update-task-configuration)で説明した`Pause Task -> Modify Configuration -> Resume Task`プロセスに従い、changefeed の`--config`パラメータで指定された構成ファイル内の`[integrity]`構成をすべて削除します。
+1. [Update task configuration](/ticdc/ticdc-manage-changefeed.md#update-task-configuration)で説明した`Pause Task -> Modify Configuration -> Resume Task`プロセスに従い、changefeed の`--config`パラメータで指定された設定ファイル内の`[integrity]`構成をすべて削除します。
```toml
[integrity]
diff --git a/ticdc/ticdc-manage-changefeed.md b/ticdc/ticdc-manage-changefeed.md
index 7bcb7c7a5b404..dd5d5c0481ec6 100644
--- a/ticdc/ticdc-manage-changefeed.md
+++ b/ticdc/ticdc-manage-changefeed.md
@@ -202,7 +202,7 @@ cdc cli changefeed resume -c test-cf --server=http://10.0.10.25:8300
現在、次の設定項目を変更できます。
- チェンジフィードの`sink-uri` 。
-- changefeed 構成ファイルとファイル内のすべての設定項目。
+- changefeed 設定ファイルとファイル内のすべての設定項目。
- チェンジフィードの`target-ts` 。
## レプリケーションサブタスクの処理単位を管理する（ `processor` ） {#manage-processing-units-of-replication-sub-tasks-processor}
diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md
index d5d6219405fa3..5e05806c9fd22 100644
--- a/ticdc/ticdc-open-api-v2.md
+++ b/ticdc/ticdc-open-api-v2.md
@@ -235,7 +235,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health
| パラメータ名 | 説明 |
| :--------------- | :----------------------------------------------------------------------------------------------------- |
| `changefeed_id` | `STRING`型。レプリケーションタスクのID。（オプション） |
-| `replica_config` | レプリケーションタスクのコンフィグレーションパラメータ。(オプション) |
+| `replica_config` | レプリケーションタスクの設定パラメータ。(オプション) |
| **`sink_uri`** | `STRING`型。レプリケーションタスクのダウンストリームアドレス。（**必須**） |
| `start_ts` | `UINT64`型。変更フィードの開始TSOを指定します。TiCDCクラスターは、このTSOからデータのプルを開始します。デフォルト値は現在時刻です。（オプション） |
| `target_ts` | `UINT64`型。変更フィードのターゲットTSOを指定します。TiCDCクラスターは、このTSOに到達するとデータのプルを停止します。デフォルト値は空で、TiCDCは自動的に停止しません。(オプション) |
diff --git a/ticdc/ticdc-server-config.md b/ticdc/ticdc-server-config.md
index 07823e40ef4b1..128b39d77ef30 100644
--- a/ticdc/ticdc-server-config.md
+++ b/ticdc/ticdc-server-config.md
@@ -5,7 +5,7 @@ summary: TiCDC で使用される CLI と設定パラメータについて学習
# TiCDC サーバー構成 {#ticdc-server-configurations}
-このドキュメントでは、TiCDC で使用される CLI および構成ファイルのパラメータについて説明します。
+このドキュメントでは、TiCDC で使用される CLI および設定ファイルのパラメータについて説明します。
## `cdc server` CLIパラメータ {#cdc-server-cli-parameters}
@@ -26,7 +26,7 @@ summary: TiCDC で使用される CLI と設定パラメータについて学習
- `tz` : TiCDC サービスが使用するタイムゾーン。TiCDC は、 `TIMESTAMP`などの時間データ型を内部的に変換するとき、またはデータをダウンストリームに複製するときに、このタイムゾーンを使用します。デフォルトは、プロセスが実行されるローカルタイムゾーンです。`sink-uri`の`time-zone`パラメータは、 `mysql`と`tidb`シンクにのみ有効で、ダウンストリーム接続セッションのタイムゾーンを設定するために使用されることに注意してください。`tz`パラメータと`time-zone`パラメータの両方を指定する場合は、両方のパラメータで同じタイムゾーンを使用するようにしてください。これは、TiCDC プロセスは内部的に`tz`で指定されたタイムゾーンを使用するのに対し、MySQL シンクと TiDB シンクはダウンストリーム操作の実行時に`time-zone`で指定されたタイムゾーンを使用するためです。
- `cluster-id` : (オプション) TiCDC クラスターの ID。デフォルト値は`default`です。 `cluster-id`は TiCDC クラスターの一意の識別子です。同じ`cluster-id`を持つ TiCDC ノードは同じクラスターに属します。 `cluster-id`の長さは最大 128 文字です。 `cluster-id` `^[a-zA-Z0-9]+(-[a-zA-Z0-9]+)*$`のパターンに従う必要があり、 `owner` 、 `capture` 、 `task` 、 `changefeed` 、 `job` 、 `meta`のいずれかにすることはできません。
-## `cdc server`構成ファイルのパラメータ {#cdc-server-configuration-file-parameters}
+## `cdc server`設定ファイルのパラメータ {#cdc-server-configuration-file-parameters}
以下は、コマンド`cdc server`の`config`オプションで指定される設定ファイルについて説明します。デフォルトの設定ファイルは[`pkg/cmd/util/ticdc.toml`](https://github.com/pingcap/tiflow/blob/master/pkg/cmd/util/ticdc.toml)にあります。
diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md
index 22fca46fad0a5..382989b4e4e17 100644
--- a/ticdc/ticdc-sink-to-kafka.md
+++ b/ticdc/ticdc-sink-to-kafka.md
@@ -29,7 +29,7 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na
- `--sink-uri` : レプリケーションタスクのダウンストリームアドレス。詳細は[`kafka`でシンクURIを設定する](#configure-sink-uri-for-kafka)を参照してください。
- `--start-ts` : チェンジフィードの開始TSOを指定します。このTSOから、TiCDCクラスターはデータのプルを開始します。デフォルト値は現在時刻です。
- `--target-ts` : チェンジフィードの終了TSOを指定します。このTSOまで、TiCDCクラスターはデータのプルを停止します。デフォルト値は空で、TiCDCはデータのプルを自動的に停止しません。
-- `--config` : changefeed設定ファイルを指定します。詳細は[TiCDC Changefeedコンフィグレーションパラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。
+- `--config` : changefeed設定ファイルを指定します。詳細は[TiCDC Changefeed設定パラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。
## サポートされているKafkaのバージョン {#supported-kafka-versions}
diff --git a/ticdc/ticdc-sink-to-mysql.md b/ticdc/ticdc-sink-to-mysql.md
index a119da87d544d..7ea84d99e0ef2 100644
--- a/ticdc/ticdc-sink-to-mysql.md
+++ b/ticdc/ticdc-sink-to-mysql.md
@@ -29,7 +29,7 @@ Info: {"sink-uri":"mysql://root:123456@127.0.0.1:3306/","opts":{},"create-time":
- `--sink-uri` : レプリケーションタスクのダウンストリームアドレス。詳細については、[シンクURIを`mysql` / `tidb`で設定します](#configure-sink-uri-for-mysql-or-tidb)を参照してください。
- `--start-ts` : 変更フィードの開始TSOを指定します。TiCDCクラスタはこのTSOからデータの取得を開始します。デフォルト値は現在時刻です。
- `--target-ts` : 変更フィードの終了TSOを指定します。このTSOに達すると、TiCDCクラスタはデータのプルを停止します。デフォルト値は空で、これはTiCDCが自動的にデータのプルを停止しないことを意味します。
-- `--config` : チェンジフィード構成ファイルを指定します。詳細については、 [TiCDC Changefeedコンフィグレーションパラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。
+- `--config` : チェンジフィード設定ファイルを指定します。詳細については、 [TiCDC Changefeed設定パラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。
> **Note:**
>
diff --git a/ticdc/ticdc-sink-to-pulsar.md b/ticdc/ticdc-sink-to-pulsar.md
index 70781d6376ed2..ab3cd942d8885 100644
--- a/ticdc/ticdc-sink-to-pulsar.md
+++ b/ticdc/ticdc-sink-to-pulsar.md
@@ -47,13 +47,13 @@ Sink URI を使用して TiCDC ターゲット システムの接続情報を指
[scheme]://[userinfo@][host]:[port][/path]?[query_parameters]
```
-コンフィグレーション例1:
+設定例1:
```shell
--sink-uri="pulsar://127.0.0.1:6650/persistent://abc/def/yktest?protocol=canal-json"
```
-コンフィグレーション例2:
+設定例2:
```shell
--sink-uri="pulsar://127.0.0.1:6650/yktest?protocol=canal-json"
@@ -66,7 +66,7 @@ URI で設定可能なパラメータは次のとおりです。
| `pulsar` | 下流Pulsarのスキーム。値は`pulsar` 、 `pulsar+ssl` 、 `pulsar+http` 、 `pulsar+https`のいずれかで、v8.2.0以降では`pulsar+http`と`pulsar+https`がサポートされています。 |
| `127.0.0.1` | ダウンストリーム Pulsar がサービスを提供する IP アドレス。 |
| `6650` | 下流 Pulsar の接続ポート。 |
-| `persistent://abc/def/yktest` | 前の構成例 1 に示されているように、このパラメータは Pulsar のテナント、名前空間、トピックを指定するために使用されます。 |
+| `persistent://abc/def/yktest` | 前の設定例1に示されているように、このパラメータは Pulsar のテナント、名前空間、トピックを指定するために使用されます。 |
| `yktest` | 上記の設定例 2 に示すように、指定したいトピックがPulsarのデフォルトテナント`public`のデフォルト名前空間`default`にある場合、トピック名のみ（例： `yktest` ）でURIを設定できます。これは、トピックを`persistent://public/default/yktest`と指定するのと同じです。 |
### Changefeed 設定パラメータ {#changefeed-config-parameters}
@@ -151,7 +151,7 @@ TiCDCはv7.5.1およびv8.0.0以降、PulsarのTLS暗号化通信をサポート
--sink-uri="pulsar+ssl://127.0.0.1:6651/persistent://public/default/yktest?protocol=canal-json"
```
-コンフィグレーション：
+設定：
```toml
[sink.pulsar-config]
@@ -252,7 +252,7 @@ tls-key-file-path="/data/pulsar/tls-key-file"
### Matcherのマッチングルール {#matching-rules-for-matcher}
-次のサンプル構成ファイルの`dispatchers`設定項目を例に挙げます。
+次のサンプル設定ファイルの`dispatchers`設定項目を例に挙げます。
```toml
[sink]
diff --git a/ticdc/ticdc-upstream-downstream-check.md b/ticdc/ticdc-upstream-downstream-check.md
index 27628276dd2d8..72edf9466c9cb 100644
--- a/ticdc/ticdc-upstream-downstream-check.md
+++ b/ticdc/ticdc-upstream-downstream-check.md
@@ -94,7 +94,7 @@ select * from tidb_cdc.syncpoint_v1;
## 注記 {#notes}
-- チェンジフィードを作成する前に、changefeed設定項目`enable-sync-point`の値が`true`に設定されていることを確認してください。この設定によってのみ、同期ポイントが有効になり、 `ts-map`がダウンストリームに保存されます。設定項目`sync-point-interval`のデフォルト形式は`"h m s"` （例えば`"1h30m30s"`で、最小値は`"30s"`です。完全な構成情報については、 [TiCDC タスク構成ファイル](/ticdc/ticdc-changefeed-config.md)を参照してください。
+- チェンジフィードを作成する前に、changefeed設定項目`enable-sync-point`の値が`true`に設定されていることを確認してください。この設定によってのみ、同期ポイントが有効になり、 `ts-map`がダウンストリームに保存されます。設定項目`sync-point-interval`のデフォルト形式は`"h m s"` （例えば`"1h30m30s"`で、最小値は`"30s"`です。完全な構成情報については、 [TiCDC タスク設定ファイル](/ticdc/ticdc-changefeed-config.md)を参照してください。
- Syncpointを使用してデータ検証を実行する場合、TiKVのガベージコレクション（GC）時間を変更する必要があります。これは、データチェック中にスナップショットに対応する履歴データがGCによって収集されないようにするためです。GC時間を1時間に変更し、チェック後に設定を復元することをお勧めします。
- 上記の例では`Datasource config`の部分のみを示しています。完全な設定については[sync-diff-inspector ユーザーガイド](/sync-diff-inspector/sync-diff-inspector-overview.md)を参照してください。
- v6.4.0 以降では、 `SYSTEM_VARIABLES_ADMIN`または`SUPER`権限を持つ changefeed のみが TiCDC Syncpoint 機能を使用できます。
diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md
index 28200970644d5..81ec48b2c34a3 100644
--- a/ticdc/troubleshoot-ticdc.md
+++ b/ticdc/troubleshoot-ticdc.md
@@ -45,9 +45,9 @@ cdc cli changefeed query --server=http://127.0.0.1:8300 --changefeed-id 28c43ffc
- このシナリオでは、TiCDCはタスク情報を保存します。TiCDCはPDにサービスGCセーフポイントを設定しているため、タスクチェックポイント以降のデータは有効期間`gc-ttl`内にTiKV GCによってクリーンアップされません。
- 取り扱い手順:
1. `cdc cli changefeed query`コマンドを使用してレプリケーションタスクのステータス情報を照会し、 `checkpoint-ts`の値を記録します。
- 2. 新しいタスク構成ファイルを使用して`ignore-txn-start-ts`パラメータを追加し、指定された`start-ts`に対応するトランザクションをスキップします。
+ 2. 新しいタスク設定ファイルを使用して`ignore-txn-start-ts`パラメータを追加し、指定された`start-ts`に対応するトランザクションをスキップします。
3. `cdc cli changefeed pause -c `を実行してレプリケーションタスクを一時停止します。
- 4. `cdc cli changefeed update -c --config `を実行して新しいタスク構成ファイルを指定します。
+ 4. `cdc cli changefeed update -c --config `を実行して新しいタスク設定ファイルを指定します。
5. `cdc cli changefeed resume -c `を実行してレプリケーションタスクを再開します。
### タスク中断後に TiCDC を再起動した後で発生する OOM を処理するにはどうすればよいですか? {#what-should-i-do-to-handle-the-oom-that-occurs-after-ticdc-is-restarted-after-a-task-interruption}
@@ -76,7 +76,7 @@ Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skippin
`mysql`と`tidb`シンクを使用する場合は、タイムゾーンを明示的に指定することをお勧めします（例： `time-zone="Asia/Shanghai"` 。また、TiCDCサーバー構成で指定する`tz`とシンクURIで指定する`time-zone`が、下流データベースのタイムゾーン設定と一致していることを確認してください。これにより、タイムゾーンの不一致によるデータの不整合を防ぐことができます。
-## TiCDC のアップグレードによって発生した構成ファイルの非互換性の問題をどのように処理すればよいですか? {#how-do-i-handle-the-incompatibility-issue-of-configuration-files-caused-by-ticdc-upgrade}
+## TiCDC のアップグレードによって発生した設定ファイルの非互換性の問題をどのように処理すればよいですか? {#how-do-i-handle-the-incompatibility-issue-of-configuration-files-caused-by-ticdc-upgrade}
[互換性に関する注意事項](/ticdc/ticdc-compatibility.md)を参照してください。
diff --git a/tidb-cloud/csv-config-for-import-data.md b/tidb-cloud/csv-config-for-import-data.md
index f44e6de5a17a4..40abbe805d81a 100644
--- a/tidb-cloud/csv-config-for-import-data.md
+++ b/tidb-cloud/csv-config-for-import-data.md
@@ -7,7 +7,7 @@ summary: TiDB Cloudのインポートデータサービスで CSV 構成を使
このドキュメントでは、 TiDB Cloudの Import Data サービスの CSV 構成について説明します。
-以下は、 TiDB Cloudのデータインポートサービスを使用してCSVファイルをインポートする際のCSVコンフィグレーションウィンドウです。詳細については、 [クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)を参照してください。
+以下は、 TiDB Cloudのデータインポートサービスを使用してCSVファイルをインポートする際のCSV構成ウィンドウです。詳細については、 [クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)を参照してください。
diff --git a/tidb-cloud/data-service-app-config-files.md b/tidb-cloud/data-service-app-config-files.md
index 2107ac63e6c46..dd857fde13c49 100644
--- a/tidb-cloud/data-service-app-config-files.md
+++ b/tidb-cloud/data-service-app-config-files.md
@@ -1,13 +1,13 @@
---
title: Data App Configuration Files
-summary: このドキュメントでは、TiDB Cloudのデータアプリの構成ファイルについて説明します。
+summary: このドキュメントでは、TiDB Cloudのデータアプリの設定ファイルについて説明します。
---
-# データアプリコンフィグレーションファイル {#data-app-configuration-files}
+# データアプリ設定ファイル {#data-app-configuration-files}
-このドキュメントでは、TiDB Cloudの[データアプリ](/tidb-cloud/tidb-cloud-glossary.md#data-app)の構成ファイルについて説明します。
+このドキュメントでは、TiDB Cloudの[データアプリ](/tidb-cloud/tidb-cloud-glossary.md#data-app)の設定ファイルについて説明します。
-データ[データアプリをGitHubに接続しました](/tidb-cloud/data-service-manage-github-connection.md)た場合は、次のように GitHub の指定したディレクトリでデータアプリの構成ファイルを見つけることができます。
+[データアプリをGitHubに接続した](/tidb-cloud/data-service-manage-github-connection.md)場合は、次のように GitHub の指定したディレクトリでデータアプリの設定ファイルを見つけることができます。
```
├──
diff --git a/tidb-cloud/data-service-concepts.md b/tidb-cloud/data-service-concepts.md
index 3cb5817bc0259..cc19bdc967287 100644
--- a/tidb-cloud/data-service-concepts.md
+++ b/tidb-cloud/data-service-concepts.md
@@ -37,11 +37,11 @@ TiDB Cloudの Chat2Query API は、AI が指示を与えることで SQL 文を
詳細については[データアプリをサードパーティツールと統合する](/tidb-cloud/data-service-integrations.md)を参照してください。
-## コードとしてのコンフィグレーション {#configuration-as-code}
+## コードとしての設定 {#configuration-as-code}
-TiDB Cloud は、 JSON 構文を使用してデータアプリの構成全体をコードとして表現する、 コンフィグレーション as Code (CaC) アプローチを提供します。
+TiDB Cloud は、 JSON 構文を使用してデータアプリの設定全体をコードとして表現する、 設定 as Code (CaC) アプローチを提供します。
-データアプリを GitHub に接続することで、 TiDB Cloud はCaC アプローチを使用して、データアプリの構成を[設定ファイル](/tidb-cloud/data-service-app-config-files.md)として優先 GitHub リポジトリおよびブランチにプッシュできます。
+データアプリを GitHub に接続することで、 TiDB Cloud はCaC アプローチを使用して、データアプリの設定を[設定ファイル](/tidb-cloud/data-service-app-config-files.md)として優先 GitHub リポジトリおよびブランチにプッシュできます。
GitHub接続で自動同期とデプロイが有効になっている場合は、GitHub上の設定ファイルを更新することでデータアプリを変更することもできます。設定ファイルの変更をGitHubにプッシュすると、新しい設定がTiDB Cloudに自動的にデプロイされます。
diff --git a/tidb-cloud/data-service-get-started.md b/tidb-cloud/data-service-get-started.md
index ecf08fc141019..debc2d258cca2 100644
--- a/tidb-cloud/data-service-get-started.md
+++ b/tidb-cloud/data-service-get-started.md
@@ -76,7 +76,7 @@ Data Serviceの利用を開始するには、独自のデータアプリを作
> **Note:**
>
> - ディレクトリ名はスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata`のようになります。指定したディレクトリが対象のリポジトリとブランチに存在しない場合は、自動的に作成されます。
- > - リポジトリ、ブランチ、ディレクトリの組み合わせによって構成ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで構成されたエンドポイントによって、指定したパス内のファイルが上書きされます。
+ > - リポジトリ、ブランチ、ディレクトリの組み合わせによって設定ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで構成されたエンドポイントによって、指定したパス内のファイルが上書きされます。
5. **Create Data App**をクリックします。 [**Data Service**](https://tidbcloud.com/project/data-service)の詳細ページが表示されます。
diff --git a/tidb-cloud/data-service-manage-data-app.md b/tidb-cloud/data-service-manage-data-app.md
index 0197a8912cff0..6a0133ae291d0 100644
--- a/tidb-cloud/data-service-manage-data-app.md
+++ b/tidb-cloud/data-service-manage-data-app.md
@@ -29,19 +29,19 @@ Data Service（プレビュー版）のデータアプリは、特定のアプ
1. **Install on GitHub**をクリックし、画面の指示に従って、 **TiDB Cloud Data Service**をアプリケーションとしてターゲット リポジトリにインストールします。
2. **Authorize**をクリックして、GitHub 上のアプリケーションへのアクセスを承認します。
- 3. データアプリの構成ファイルを保存するターゲット リポジトリ、ブランチ、ディレクトリを指定します。
+ 3. データアプリの設定ファイルを保存するターゲット リポジトリ、ブランチ、ディレクトリを指定します。
> **Note:**
>
> - ディレクトリはスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata` 。指定したディレクトリがターゲットリポジトリとブランチに存在しない場合は、自動的に作成されます。
> - リポジトリ、ブランチ、ディレクトリの組み合わせは、設定ファイルのパスを識別します。このパスはデータアプリ間で一意である必要があります。指定したパスが既に別のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、 TiDB Cloudコンソールで現在のデータアプリ用に設定されたエンドポイントによって、指定したパス内のファイルが上書きされます。
- > - 指定したパスに別のデータアプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータアプリにインポートする場合は、 [既存のデータアプリの構成をインポートする](/tidb-cloud/data-service-manage-github-connection.md#import-configurations-of-an-existing-data-app)を参照してください。
+ > - 指定したパスに別のデータアプリからコピーされた設定ファイルが含まれており、これらのファイルを現在のデータアプリにインポートする場合は、 [既存のデータアプリの設定をインポートする](/tidb-cloud/data-service-manage-github-connection.md#import-configurations-of-an-existing-data-app)を参照してください。
4. **Create Data App**をクリックします。
新しく作成されたデータアプリがリストの一番上に追加されます。新しいデータアプリにはデフォルトで「 `untitled endpoint`が作成されます。
-5. データアプリをGitHubに接続するように設定している場合は、指定したGitHubディレクトリを確認してください`tidb-cloud-data-service`までに[データアプリの構成ファイル](/tidb-cloud/data-service-app-config-files.md)ディレクトリにコミットされていることがわかります。これは、データアプリがGitHubに正常に接続されていることを意味します。
+5. データアプリをGitHubに接続するように設定している場合は、指定したGitHubディレクトリを確認してください`tidb-cloud-data-service`までに[データアプリの設定ファイル](/tidb-cloud/data-service-app-config-files.md)ディレクトリにコミットされていることがわかります。これは、データアプリがGitHubに正常に接続されていることを意味します。
新しいデータアプリでは、**Auto Sync & Deployment**、および**Review Draft**がデフォルトで有効になっているため、 TiDB Cloudコンソールと GitHub 間でデータアプリの変更を簡単に同期し、デプロイ前に変更を確認できます。GitHub との統合の詳細については、 [データアプリの変更を GitHub で自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)ご覧ください。
diff --git a/tidb-cloud/data-service-manage-github-connection.md b/tidb-cloud/data-service-manage-github-connection.md
index 3dcbe963eaf52..e46d9b08ed8d6 100644
--- a/tidb-cloud/data-service-manage-github-connection.md
+++ b/tidb-cloud/data-service-manage-github-connection.md
@@ -5,7 +5,7 @@ summary: GitHubを使ってデータアプリを自動的にデプロイする
# GitHub を使用してデータアプリを自動的にデプロイ {#deploy-data-app-automatically-with-github}
-TiDB Cloudは、 JSON構文を使用してデータアプリの構成全体をコードとして表現する、コンフィグレーションコード（CaC）アプローチを提供します。
+TiDB Cloudは、 JSON構文を使用してデータアプリの設定全体をコードとして表現する、設定コード（CaC）アプローチを提供します。
データアプリをGitHubに接続することで、 TiDB CloudはCaC方式を使用し、データアプリの設定を[設定ファイル](/tidb-cloud/data-service-app-config-files.md)として、指定したGitHubリポジトリとブランチにプッシュできます。
@@ -22,7 +22,7 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git
> **Note:**
>
-> GitHub リポジトリは、データアプリを接続した後、データアプリ[データアプリの設定ファイル](/tidb-cloud/data-service-app-config-files.md)を保存するために使用されます。構成ファイル内の情報 ( TiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスターの ID、エンドポイント URL など) が機密である場合は、パブリック リポジトリではなくプライベートリポジトリを必ず使用してください。
+> GitHub リポジトリは、データアプリを接続した後、データアプリ[データアプリの設定ファイル](/tidb-cloud/data-service-app-config-files.md)を保存するために使用されます。設定ファイル内の情報 ( TiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスターの ID、エンドポイント URL など) が機密である場合は、パブリック リポジトリではなくプライベートリポジトリを必ず使用してください。
## ステップ1：データアプリをGitHubに接続する {#step-1-connect-your-data-app-to-github}
@@ -47,8 +47,8 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git
> **Note:**
>
> - ディレクトリ名はスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata`のようになります。指定したディレクトリが対象のリポジトリとブランチに存在しない場合は、自動的に作成されます。
- > - リポジトリ、ブランチ、ディレクトリの組み合わせによって構成ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで構成されたエンドポイントによって、指定したパス内のファイルが上書きされます。
- > - 指定したパスに別のデータアプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータアプリにインポートする場合は、[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)を参照してください。
+ > - リポジトリ、ブランチ、ディレクトリの組み合わせによって設定ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで設定されたエンドポイントによって、指定したパス内のファイルが上書きされます。
+ > - 指定したパスに別のデータアプリからコピーされた設定ファイルが含まれており、これらのファイルを現在のデータアプリにインポートする場合は、[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)を参照してください。
4. TiDB CloudコンソールまたはGitHubで行われたデータアプリの変更を相互に同期させるには、 **Configure Auto Sync & Deployment**を有効にします。
@@ -59,7 +59,7 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git
## ステップ2. データアプリの設定をGitHubと同期する {#step-2-synchronize-data-app-configurations-with-github}
-データアプリ[データアプリを作成する](/tidb-cloud/data-service-manage-data-app.md)ときに GitHub 接続が有効になっている場合、 TiDB Cloud はアプリの作成直後にこのデータアプリの構成ファイルを GitHub にプッシュします。
+データアプリ[データアプリを作成する](/tidb-cloud/data-service-manage-data-app.md)ときに GitHub 接続が有効になっている場合、 TiDB Cloud はアプリの作成直後にこのデータアプリの設定ファイルを GitHub にプッシュします。
アプリ作成後にGitHub接続が有効になっている場合は、データアプリの設定をGitHubと同期するためにデプロイ操作を実行する必要があります。たとえば、 **[Deployments]**タブをクリックし、このデータアプリのデプロイを再デプロイすることができます。
@@ -125,7 +125,7 @@ TiDB Cloudコンソールでデータアプリのエンドポイント[データ
2. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページで、GitHub に接続せずに[新しいデータアプリを作成する](/tidb-cloud/data-service-manage-data-app.md#create-a-data-app)。
-3. **Auto Sync & Deployment**を有効にして、[新しいデータアプリをGitHubに接続します](#step-1-connect-your-data-app-to-github)。新しいデータアプリのターゲット リポジトリ、ブランチ、ディレクトリを指定するときは、コピーした構成ファイルを含む新しいパスを使用します。
+3. **Auto Sync & Deployment**を有効にして、[新しいデータアプリをGitHubに接続します](#step-1-connect-your-data-app-to-github)。新しいデータアプリのターゲット リポジトリ、ブランチ、ディレクトリを指定するときは、コピーした設定ファイルを含む新しいパスを使用します。
4. 新しいデータアプリのIDと名前を取得します。左側のペインで新しいデータアプリの名前をクリックすると、右側のペインの**Data App Properties**領域にアプリのIDと名前が表示されます。
@@ -152,8 +152,8 @@ TiDB Cloudコンソールでデータアプリのエンドポイント[データ
> **Note:**
>
> - ディレクトリ名はスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata`のようになります。指定したディレクトリが対象のリポジトリとブランチに存在しない場合は、自動的に作成されます。
- > - リポジトリ、ブランチ、ディレクトリの組み合わせによって構成ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで構成されたエンドポイントによって、指定したパス内のファイルが上書きされます。
- > - 指定したパスに別のデータアプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータアプリにインポートする場合は、[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)を参照してください。
+ > - リポジトリ、ブランチ、ディレクトリの組み合わせによって設定ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで設定されたエンドポイントによって、指定したパス内のファイルが上書きされます。
+ > - 指定したパスに別のデータアプリからコピーされた設定ファイルが含まれており、これらのファイルを現在のデータアプリにインポートする場合は、[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)を参照してください。
5. TiDB CloudコンソールまたはGitHubで行われたデータアプリの変更を相互に同期させるには、 **Configure Auto Sync & Deployment**を有効にします。
diff --git a/tidb-cloud/integrate-tidbcloud-with-dbt.md b/tidb-cloud/integrate-tidbcloud-with-dbt.md
index 75f11e14e19c0..97ebe3c738b1b 100644
--- a/tidb-cloud/integrate-tidbcloud-with-dbt.md
+++ b/tidb-cloud/integrate-tidbcloud-with-dbt.md
@@ -57,7 +57,7 @@ cd jaffle_shop
このディレクトリ内:
-- `dbt_project.yml`は dbt プロジェクト構成ファイルであり、プロジェクト名とデータベース構成ファイルの情報が含まれています。
+- `dbt_project.yml`は dbt プロジェクト設定ファイルであり、プロジェクト名とデータベース設定ファイルの情報が含まれています。
- `models`ディレクトリには、プロジェクトの SQL モデルとテーブルスキーマが含まれています。このセクションはデータ アナリストが作成します。モデルの詳細については、 [SQLモデル](https://docs.getdbt.com/docs/build/sql-models)を参照してください。
diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md
index 52085919fff8b..217e1e2584334 100644
--- a/tidb-cloud/migrate-from-mysql-using-data-migration.md
+++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md
@@ -195,7 +195,7 @@ TiDB Cloud Premium の場合、データ移行機能は次の MySQL 互換ソー
DM を使用して、ソースの MySQL 互換データベースからターゲットのTiDB Cloud Dedicatedクラスター TiDB Cloud Essentialインスタンス TiDB Cloud Premiumインスタンス に増分変更を継続的にレプリケートするには、ソースデータベースでバイナリログを有効にするために次の構成が必要です。
-| コンフィグレーション | 必要値 | なぜ |
+| 設定 | 必須値 | 理由 |
| :------------------------------- | :------------------------------- | :---------------------------------------- |
| `log_bin` | `ON` | DMがTiDBへの変更を複製するために使用するバイナリログを有効にします。 |
| `binlog_format` | `ROW` | すべてのデータ変更を正確に記録します（他の形式では例外的なケースを見落とします）。 |
diff --git a/tidb-cloud/migrate-from-op-tidb.md b/tidb-cloud/migrate-from-op-tidb.md
index cd9be228d6da3..2d703edef0857 100644
--- a/tidb-cloud/migrate-from-op-tidb.md
+++ b/tidb-cloud/migrate-from-op-tidb.md
@@ -319,7 +319,7 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート
- `--start-ts` : 変更フィードの開始TSOを指定します。TiCDCクラスタはこのTSOからデータの取得を開始します。デフォルト値は現在時刻です。
- 詳細については、 [TiCDC ChangefeedsのCLIとコンフィグレーションパラメータ](https://docs.pingcap.com/tidb/dev/ticdc-changefeed-config)を参照してください。
+ 詳細については、 [TiCDC ChangefeedsのCLIと設定パラメータ](https://docs.pingcap.com/tidb/dev/ticdc-changefeed-config)を参照してください。
5. アップストリームクラスタでGCメカニズムを再度有効にします。増分レプリケーションでエラーや遅延が検出されない場合は、GCメカニズムを有効にして、アップストリームクラスタのガベージコレクションを再開します。
diff --git a/tidb-cloud/migrate-sql-shards.md b/tidb-cloud/migrate-sql-shards.md
index b079e667c473e..ebad53aa20eaf 100644
--- a/tidb-cloud/migrate-sql-shards.md
+++ b/tidb-cloud/migrate-sql-shards.md
@@ -363,7 +363,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次
Finished dump at: 2022-05-25 10:20:32
```
-4. タスク構成ファイル`test-task1`を編集して、各データソースの増分レプリケーションモードとレプリケーション開始点を設定します。
+4. タスク設定ファイル`test-task1`を編集して、各データソースの増分レプリケーションモードとレプリケーション開始点を設定します。
```yaml
## ********* Task Configuration *********
diff --git a/tidb-cloud/optimize-resource-allocation.md b/tidb-cloud/optimize-resource-allocation.md
index 2e41dcbbca5ff..7408772aae8c1 100644
--- a/tidb-cloud/optimize-resource-allocation.md
+++ b/tidb-cloud/optimize-resource-allocation.md
@@ -33,6 +33,6 @@ TiDB Cloud Dedicatedは、 [リソース管理](/tidb-resource-control-ru-groups
| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| 分離レベル | TiKVまたはTiFlash論理レイヤー | TiDBノード物理レイヤー |
| フロー制御 | リソースグループに設定されたクォータに基づいて、ユーザーの読み取りおよび書き込みリクエストのフローを制御します。 | サポートされていません。 |
-| コンフィグレーション方法 | SQL文を使用して構成 | TiDB Cloudコンソールから設定 |
+| 設定方法 | SQL文を使用して設定 | TiDB Cloudコンソールから設定 |
| ワークロードの区別 | 次のレベルでのバインディング リソースをサポートします。
| ----------------- | ------------------------- | --- | ------------------------------------ |
| -D, --debug | デバッグ モードを有効にします。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
| --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 |
-| -P, --profile 文字列 | 構成ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
+| -P, --profile 文字列 | 設定ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
## フィードバック {#feedback}
diff --git a/tidb-cloud/ticloud-serverless-audit-log-config-update.md b/tidb-cloud/ticloud-serverless-audit-log-config-update.md
index 2b0c1fdaee7c9..019fecdf2bc15 100644
--- a/tidb-cloud/ticloud-serverless-audit-log-config-update.md
+++ b/tidb-cloud/ticloud-serverless-audit-log-config-update.md
@@ -72,7 +72,7 @@ ticloud serverless audit-log config update -c --enabled=false
| ----------------- | ------------------------- | --- | ------------------------------------ |
| -D, --debug | デバッグ モードを有効にします。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
| --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 |
-| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
+| -P, --profile string | 設定ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
## フィードバック {#feedback}
diff --git a/tidb-cloud/ticloud-serverless-audit-log-download.md b/tidb-cloud/ticloud-serverless-audit-log-download.md
index 2c303fbd3b488..8cbd0390b1c10 100644
--- a/tidb-cloud/ticloud-serverless-audit-log-download.md
+++ b/tidb-cloud/ticloud-serverless-audit-log-download.md
@@ -43,7 +43,7 @@ ticloud serverless audit-log download -c --start-date
| ----------------- | ------------------------- | --- | ------------------------------------ |
| -D, --debug | デバッグ モードを有効にします。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
| --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 |
-| -P, --profile 文字列 | 構成ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
+| -P, --profile 文字列 | 設定ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
## フィードバック {#feedback}
diff --git a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md
index 35237876272ca..a175f66ba9f39 100644
--- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md
+++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md
@@ -46,7 +46,7 @@ ticloud serverless audit-log filter-rule create --cluster-id --disp
| ----------------- | ------------------------- | --- | ------------------------------------ |
| -D, --debug | デバッグ モードを有効にします。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
| --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 |
-| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
+| -P, --profile string | 設定ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
## フィードバック {#feedback}
diff --git a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-delete.md b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-delete.md
index 0457d09221238..e113e1ea0ce56 100644
--- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-delete.md
+++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-delete.md
@@ -40,7 +40,7 @@ ticloud serverless audit-log filter-rule delete --cluster-id --filt
| ----------------- | ------------------------- | --- | ------------------------------------ |
| -D, --debug | デバッグ モードを有効にします。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
| --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 |
-| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
+| -P, --profile string | 設定ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
## フィードバック {#feedback}
diff --git a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-describe.md b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-describe.md
index 7a8138a7d0ba5..fb1832befa6f3 100644
--- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-describe.md
+++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-describe.md
@@ -39,7 +39,7 @@ ticloud serverless audit-log filter-rule describe --cluster-id --fi
| ----------------- | ------------------------- | --- | ------------------------------------ |
| -D, --debug | デバッグ モードを有効にします。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
| --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 |
-| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
+| -P, --profile string | 設定ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
## フィードバック {#feedback}
diff --git a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-list.md b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-list.md
index bd1eb355135f5..8fa259c05746a 100644
--- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-list.md
+++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-list.md
@@ -45,7 +45,7 @@ ticloud serverless audit-log filter-rule list -c -o json
| ----------------- | ------------------------- | --- | ------------------------------------ |
| -D, --debug | デバッグ モードを有効にします。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
| --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 |
-| -P, --profile 文字列 | 構成ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
+| -P, --profile 文字列 | 設定ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
## フィードバック {#feedback}
diff --git a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-template.md b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-template.md
index 8932d65644525..3258f766663d8 100644
--- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-template.md
+++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-template.md
@@ -38,7 +38,7 @@ ticloud serverless audit-log filter-rule template --cluster-id
| ----------------- | ------------------------- | --- | ------------------------------------ |
| -D, --debug | デバッグ モードを有効にします。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
| --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 |
-| -P, --profile 文字列 | 構成ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
+| -P, --profile 文字列 | 設定ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
## フィードバック {#feedback}
diff --git a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-update.md b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-update.md
index fc5ebcbbd2a0e..230fc377c7f53 100644
--- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-update.md
+++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-update.md
@@ -54,7 +54,7 @@ ticloud serverless audit-log filter-rule update --cluster-id --filt
| ----------------- | ------------------------- | --- | ------------------------------------ |
| -D, --debug | デバッグ モードを有効にします。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
| --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 |
-| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
+| -P, --profile string | 設定ファイルから使用するプロファイルを指定します。 | いいえ | 対話モードと非対話モードの両方で動作します。 |
## フィードバック {#feedback}
diff --git a/tidb-cloud/tidb-cloud-connect-aws-dms.md b/tidb-cloud/tidb-cloud-connect-aws-dms.md
index 1cc38ca339089..ca68fc96cecb1 100644
--- a/tidb-cloud/tidb-cloud-connect-aws-dms.md
+++ b/tidb-cloud/tidb-cloud-connect-aws-dms.md
@@ -37,7 +37,7 @@ TiDB Cloud Starter またはTiDB Cloud Essential の場合、クライアント
- [パブリックエンドポイント経由でTiDB Cloud Starter または Essential クラスターに接続する](/tidb-cloud/connect-via-standard-connection-serverless.md)場合、次のいずれかを実行して、DMS レプリケーションインスタンスがインターネットにアクセスできることを確認します。
- - レプリケーションインスタンスをパブリックサブネットにデプロイし、 **Public accessible**を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)を参照してください。
+ - レプリケーションインスタンスをパブリックサブネットにデプロイし、 **Public accessible**を有効にします。詳細については、 [インターネットアクセスの設定](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)を参照してください。
- レプリケーションインスタンスをプライベートサブネットにデプロイし、プライベートサブネット内のトラフィックをパブリックサブネットにルーティングします。この場合、少なくとも3つのサブネット（プライベートサブネット2つとパブリックサブネット1つ）が必要です。2つのプライベートサブネットは、レプリケーションインスタンスが存在するサブネットグループを形成します。次に、パブリックサブネットにNATゲートウェイを作成し、2つのプライベートサブネットのトラフィックをNATゲートウェイにルーティングする必要があります。詳細については、 [プライベートサブネットからインターネットにアクセスする](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html#public-nat-internet-access)を参照してください。
@@ -52,7 +52,7 @@ TiDB Cloud Starter またはTiDB Cloud Essential の場合、クライアント
- [パブリックエンドポイント経由でTiDB Cloud Starter または Essential クラスターに接続する](/tidb-cloud/connect-via-standard-connection-serverless.md)場合、次のいずれかを実行して、DMS レプリケーションインスタンスがインターネットにアクセスできることを確認します。
- - レプリケーションインスタンスをパブリックサブネットにデプロイし、 **Public accessible**を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)を参照してください。
+ - レプリケーションインスタンスをパブリックサブネットにデプロイし、 **Public accessible**を有効にします。詳細については、 [インターネットアクセスの設定](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)を参照してください。
- レプリケーションインスタンスをプライベートサブネットにデプロイし、プライベートサブネット内のトラフィックをパブリックサブネットにルーティングします。この場合、少なくとも3つのサブネット（プライベートサブネット2つとパブリックサブネット1つ）が必要です。2つのプライベートサブネットは、レプリケーションインスタンスが存在するサブネットグループを形成します。次に、パブリックサブネットにNATゲートウェイを作成し、2つのプライベートサブネットのトラフィックをNATゲートウェイにルーティングする必要があります。詳細については、 [プライベートサブネットからインターネットにアクセスする](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html#public-nat-internet-access)を参照してください。
@@ -68,7 +68,7 @@ TiDB Cloud Dedicated の場合、クライアントはパブリックエンド
- [パブリックエンドポイント経由でTiDB Cloud Dedicated クラスターに接続する](/tidb-cloud/connect-via-standard-connection.md)については、DMS レプリケーションインスタンスがインターネットにアクセスできることを確認するために、次のいずれかを実行します。さらに、レプリケーションインスタンスまたは NAT ゲートウェイのパブリック IP アドレスをクラスターの[IPアクセスリスト](/tidb-cloud/configure-ip-access-list.md)に追加する必要があります。
- - レプリケーションインスタンスをパブリックサブネットにデプロイし、 **Public accessible**を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)を参照してください。
+ - レプリケーションインスタンスをパブリックサブネットにデプロイし、 **Public accessible**を有効にします。詳細については、 [インターネットアクセスの設定](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)を参照してください。
- レプリケーションインスタンスをプライベートサブネットにデプロイし、プライベートサブネット内のトラフィックをパブリックサブネットにルーティングします。この場合、少なくとも3つのサブネット（プライベートサブネット2つとパブリックサブネット1つ）が必要です。2つのプライベートサブネットは、レプリケーションインスタンスが存在するサブネットグループを形成します。次に、パブリックサブネットにNATゲートウェイを作成し、2つのプライベートサブネットのトラフィックをNATゲートウェイにルーティングする必要があります。詳細については、 [プライベートサブネットからインターネットにアクセスする](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html#public-nat-internet-access)を参照してください。
diff --git a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md
index 29d20787d9a1e..0af28306641f4 100644
--- a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md
+++ b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md
@@ -16,14 +16,14 @@ summary: データ移行時に発生する事前チェックエラー、移行
### エラーメッセージ: mysql server_id が 0 より大きいかどうかを確認してください {#error-message-check-whether-mysql-server-id-has-been-greater-than-0}
- Amazon Aurora MySQL または Amazon RDS: `server_id`はデフォルトで設定されています。設定する必要はありません。フルデータ移行と増分データ移行の両方をサポートするには、Amazon Aurora MySQL ライターインスタンスを使用していることを確認してください。
-- MySQL: MySQL 用に`server_id`を構成するには、 [レプリケーションソースコンフィグレーションの設定](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html)を参照してください。
+- MySQL: MySQL 用に`server_id`を構成するには、 [レプリケーションソースの設定](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html)を参照してください。
### エラーメッセージ: mysql binlogが有効になっているか確認してください {#error-message-check-whether-mysql-binlog-is-enabled}
- Amazon Aurora MySQL: [Amazon Aurora MySQL互換クラスターでバイナリログを有効にするにはどうすればよいですか？](https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/?nc1=h_ls)を参照してください。完全データ移行と増分データ移行の両方をサポートするには、Amazon Aurora MySQL ライター インスタンスを使用していることを確認してください。
- Amazon RDS: [MySQLバイナリログの設定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html)を参照してください。
- Google Cloud SQL for MySQL: Google は、MySQL マスター データベースのポイントインタイムリカバリを通じてバイナリ ロギングを可能にします。 [特定時点へのリカバリを有効にする](https://cloud.google.com/sql/docs/mysql/backup-recovery/pitr#enablingpitr)を参照してください。
-- MySQL: [レプリケーションソースコンフィグレーションの設定](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html)を参照してください。
+- MySQL: [レプリケーションソースの設定](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html)を参照してください。
### エラーメッセージ: mysql binlog_format が ROW かどうか確認してください {#error-message-check-whether-mysql-binlog-format-is-row}
diff --git a/tidb-cloud/tidb-cloud-performance-reference.md b/tidb-cloud/tidb-cloud-performance-reference.md
index 63666a44e654a..6542b54699da7 100644
--- a/tidb-cloud/tidb-cloud-performance-reference.md
+++ b/tidb-cloud/tidb-cloud-performance-reference.md
@@ -11,7 +11,7 @@ summary: TiDB Cloud のパフォーマンス テスト結果を確認します
>
> テストは TiDB v6.1.1 で実行され、テスト結果は P95 トランザクションレイテンシーが 105 ミリ秒未満という条件に基づいています。
-以下は Sysbench 構成ファイルの例です。
+以下は Sysbench 設定ファイルの例です。
```txt
mysql-host={TIDB_HOST}
diff --git a/tidb-cloud/v8.5-performance-highlights.md b/tidb-cloud/v8.5-performance-highlights.md
index 340bef41cfac4..64e8a990e548c 100644
--- a/tidb-cloud/v8.5-performance-highlights.md
+++ b/tidb-cloud/v8.5-performance-highlights.md
@@ -57,7 +57,7 @@ MVCC バージョンが蓄積されると、リクエストされたデータと
クエリのレイテンシーは50% 減少し、スループットは 100% 増加します。
-| コンフィグレーション | 期間（秒） | スレッド | TPS | QPS | 平均レイテンシー（ミリ秒） | P95レイテンシー(ミリ秒) |
+| 設定 | 期間（秒） | スレッド | TPS | QPS | 平均レイテンシー（ミリ秒） | P95レイテンシー(ミリ秒) |
| ---------- | ----- | ---- | ----- | ------ | ------------- | -------------- |
| IMEを無効にする | 3600 | 10 | 123.8 | 1498.3 | 80.76 | 207.82 |
| IMEを有効にする | 3600 | 10 | 238.2 | 2881.5 | 41.99 | 78.60 |
diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md
index 7fb5b7dfcb29d..c1ec1e74edab1 100644
--- a/tidb-configuration-file.md
+++ b/tidb-configuration-file.md
@@ -7,9 +7,9 @@ summary: コマンドラインオプションに関係しない、TiDB設定フ
-# TiDBコンフィグレーションファイル {#tidb-configuration-file}
+# TiDB設定ファイル {#tidb-configuration-file}
-TiDB 構成ファイルは、コマンドラインパラメーターよりも多くのオプションをサポートしています。デフォルトの構成ファイル[`config.toml.example`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/config/config.toml.example)をダウンロードし、その名前を`config.toml`に変更できます。本書では[コマンドラインオプション](/command-line-flags-for-tidb-configuration.md)に関係のないオプションのみを説明します。
+TiDB 設定ファイルは、コマンドラインパラメーターよりも多くのオプションをサポートしています。デフォルトの設定ファイル[`config.toml.example`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/config/config.toml.example)をダウンロードし、その名前を`config.toml`に変更できます。本書では[コマンドラインオプション](/command-line-flags-for-tidb-configuration.md)に関係のないオプションのみを説明します。
> **Tip:**
>
@@ -90,7 +90,7 @@ TiDB 構成ファイルは、コマンドラインパラメーターよりも多
- `compatible-kill-query`は、[`enable-global-kill`](#enable-global-kill-new-in-v610)が`false`に設定されている場合にのみ有効になります。
- [`enable-global-kill`](#enable-global-kill-new-in-v610)が`false`の場合、 `compatible-kill-query`は、クエリを強制終了する際に`TIDB`キーワードを追加する必要があるかどうかを制御します。
- `compatible-kill-query`が`false`の場合、TiDB での`KILL xxx`の動作は MySQL とは異なります。TiDB でクエリを強制終了するには、 `TIDB`のように`KILL TIDB xxx`キーワードを追加する必要があります。
- - `compatible-kill-query`が`true`の場合、TiDB でクエリを強制終了するには、 `TIDB`キーワードを追加する必要はありません。クライアントが**常に同じ TiDB インスタンスに接続されることが確実でない限り**、構成ファイルで`compatible-kill-query`を`true`に設定することは強くお勧めしません。これは、デフォルトの MySQL クライアントでControl + Cを押すと`KILL`が実行される新しい接続が開かれるためです。クライアントと TiDB クラスタの間にプロキシがある場合、新しい接続は別の TiDB インスタンスにルーティングされる可能性があり、誤って別のセッションが強制終了される可能性があります。
+ - `compatible-kill-query`が`true`の場合、TiDB でクエリを強制終了するには、 `TIDB`キーワードを追加する必要はありません。クライアントが**常に同じ TiDB インスタンスに接続されることが確実でない限り**、設定ファイルで`compatible-kill-query`を`true`に設定することは強くお勧めしません。これは、デフォルトの MySQL クライアントでControl + Cを押すと`KILL`が実行される新しい接続が開かれるためです。クライアントと TiDB クラスタの間にプロキシがある場合、新しい接続は別の TiDB インスタンスにルーティングされる可能性があり、誤って別のセッションが強制終了される可能性があります。
- [`enable-global-kill`](#enable-global-kill-new-in-v610)が`true`の場合、 `KILL xxx`と`KILL TIDB xxx`は同じ効果を持ちます。
- `KILL`文の詳細については、[KILL [TIDB]](/sql-statements/sql-statement-kill.md)を参照してください。
@@ -274,7 +274,7 @@ TiDB 構成ファイルは、コマンドラインパラメーターよりも多
## log {#log}
-ログに関連するコンフィグレーション項目。
+ログに関連する設定項目。
### `level` {#level}
@@ -353,7 +353,7 @@ TiDB 構成ファイルは、コマンドラインパラメーターよりも多
### log.file {#logfile}
-ログファイルに関連するコンフィグレーション項目。
+ログファイルに関連する設定項目。
#### `filename` {#filename}
@@ -389,7 +389,7 @@ TiDB 構成ファイルは、コマンドラインパラメーターよりも多
## security {#security}
-セキュリティに関連するコンフィグレーション項目。
+セキュリティに関連する設定項目。
### `enable-sem` {#enable-sem}
@@ -489,7 +489,7 @@ TiDB 構成ファイルは、コマンドラインパラメーターよりも多
## performance {#performance}
-パフォーマンスに関連するコンフィグレーション項目。
+パフォーマンスに関連する設定項目。
### `max-procs` {#max-procs}
@@ -646,7 +646,7 @@ TiDB 構成ファイルは、コマンドラインパラメーターよりも多
## opentracing {#opentracing}
-OpenTracingに関連するコンフィグレーション項目。
+OpenTracingに関連する設定項目。
### `enable` {#enable}
@@ -660,7 +660,7 @@ OpenTracingに関連するコンフィグレーション項目。
### opentracing.sampler {#opentracingsampler}
-opentracing.sampler に関連するコンフィグレーション項目。
+opentracing.sampler に関連する設定項目。
#### `type` {#type}
@@ -694,7 +694,7 @@ opentracing.sampler に関連するコンフィグレーション項目。
### opentracing.reporter {#opentracingreporter}
-opentracing.reporter に関連するコンフィグレーション項目。
+opentracing.reporter に関連する設定項目。
#### `queue-size` {#queue-size}
@@ -825,7 +825,7 @@ opentracing.reporter に関連するコンフィグレーション項目。
## txn-local-latches {#txn-local-latches}
-トランザクションラッチに関連するコンフィグレーション項目。これらの設定項目は将来的に非推奨となる可能性があります。使用は推奨されません。
+トランザクションラッチに関連する設定項目。これらの設定項目は将来的に非推奨となる可能性があります。使用は推奨されません。
### `enabled` {#enabled}
@@ -839,7 +839,7 @@ opentracing.reporter に関連するコンフィグレーション項目。
## status {#status}
-TiDBサービスの状態に関するコンフィグレーション。
+TiDBサービスの状態に関する設定。
### `report-status` {#report-status}
@@ -893,7 +893,7 @@ TiDBサービスの状態に関するコンフィグレーション。
## isolation-read {#isolation-read}
-読み取り分離に関連するコンフィグレーション項目。
+読み取り分離に関連する設定項目。
### `engines` {#engines}
@@ -1041,7 +1041,7 @@ TiDBサービスの状態に関するコンフィグレーション。
## proxy-protocol {#proxy-protocol}
-PROXYプロトコルに関連するコンフィグレーション項目。
+PROXYプロトコルに関連する設定項目。
### `networks` {#networks}
diff --git a/tidb-lightning/data-import-best-practices.md b/tidb-lightning/data-import-best-practices.md
index 2a15dca4d7dc0..5404587cfc3d3 100644
--- a/tidb-lightning/data-import-best-practices.md
+++ b/tidb-lightning/data-import-best-practices.md
@@ -46,7 +46,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni
- TiDBクラスタにインポートされたデータは圧縮形式で保存されます。圧縮率は事前に計算できません。圧縮率は、データが実際にTiKVクラスタにインポートされた後にのみ判定できます。
- ベストプラクティスとして、最初にデータの小さな部分 (たとえば、10%) をインポートしてクラスターの対応する圧縮率を取得し、それを使用してデータインポート全体の圧縮率を推定することができます。
-- コンフィグレーションパラメータ
+- 設定パラメータ
- `region-concurrency` : TiDB Lightning のメイン論理処理の同時実行性。
- `send-kv-pairs` : 1回のリクエストでTiDB Lightningから TiKV に送信されるキーと値のペアの数。
diff --git a/tidb-lightning/import-into-vs-tidb-lightning.md b/tidb-lightning/import-into-vs-tidb-lightning.md
index a6f58facb8dae..3b4dcec12c728 100644
--- a/tidb-lightning/import-into-vs-tidb-lightning.md
+++ b/tidb-lightning/import-into-vs-tidb-lightning.md
@@ -47,7 +47,7 @@ You can directly write SQL statements to submit import tasks, which are easy to
#### TiDB Lightning {#tidb-lightning}
-対照的に、 TiDB Lightning[タスク設定ファイル](/tidb-lightning/tidb-lightning-configuration.md)を記述する必要があります。これらの構成ファイルは複雑であり、サードパーティが簡単に呼び出すことはできません。
+対照的に、 TiDB Lightning[タスク設定ファイル](/tidb-lightning/tidb-lightning-configuration.md)を記述する必要があります。これらの設定ファイルは複雑であり、サードパーティが簡単に呼び出すことはできません。
### タスクのスケジュール {#task-scheduling}
diff --git a/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md b/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md
index ddeff12f3f7e5..36b0a29abdc0d 100644
--- a/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md
+++ b/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md
@@ -33,7 +33,7 @@ TiDB Lightning論理インポートモードがアプリケーションのパフ
### ログバックアップで使用される {#used-with-log-backup}
-このシナリオでは、 [PITR](/br/br-log-architecture.md#process-of-pitr)が有効になっている場合、 TiDB Lightning の起動後に互換性チェックでエラーが報告されます。これらのテーブルのバックアップが不要であることが確実な場合は、 [TiDB Lightning構成ファイル](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)の`Lightning.check-requirements`パラメータを`false`に変更してインポートタスクを再開できます。
+このシナリオでは、 [PITR](/br/br-log-architecture.md#process-of-pitr)が有効になっている場合、 TiDB Lightning の起動後に互換性チェックでエラーが報告されます。これらのテーブルのバックアップが不要であることが確実な場合は、 [TiDB Lightning設定ファイル](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)の`Lightning.check-requirements`パラメータを`false`に変更してインポートタスクを再開できます。
TiDB Lightning物理インポートモードでインポートされたデータは、ログバックアップではバックアップできません。テーブルをバックアップする必要がある場合は、 [テーブルをバックアップする](/br/br-snapshot-manual.md#back-up-a-table)で説明されているように、インポート後にテーブルレベルのスナップショットバックアップを実行することをお勧めします。
@@ -45,11 +45,11 @@ TiCDC を物理インポートモードで使用することは、短期的に
- シナリオ 1: テーブルを TiCDC によってダウンストリームに複製する必要はありません。
- このシナリオでは、TiCDC の changefeed が有効になっている場合、 TiDB Lightning の起動後に互換性チェックでエラーが報告されます。これらのテーブルにバックアップや[ログバックアップ](/br/br-pitr-guide.md)が必要ないことが確実な場合は、 [TiDB Lightning構成ファイル](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)の`Lightning.check-requirements`パラメータを`false`に変更してインポートタスクを再開できます。
+ このシナリオでは、TiCDC の changefeed が有効になっている場合、 TiDB Lightning の起動後に互換性チェックでエラーが報告されます。これらのテーブルにバックアップや[ログバックアップ](/br/br-pitr-guide.md)が必要ないことが確実な場合は、 [TiDB Lightning設定ファイル](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)の`Lightning.check-requirements`パラメータを`false`に変更してインポートタスクを再開できます。
- シナリオ 2: テーブルを TiCDC によってダウンストリームに複製する必要があります。
- このシナリオでは、TiCDC の changefeed が有効になっている場合、 TiDB Lightning の起動後に互換性チェックでエラーが報告されます。上流 TiDB クラスターの[TiDB Lightning構成ファイル](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)のパラメータ`Lightning.check-requirements`を`false`に変更し、インポートタスクを再起動する必要があります。
+ このシナリオでは、TiCDC の changefeed が有効になっている場合、 TiDB Lightning の起動後に互換性チェックでエラーが報告されます。上流 TiDB クラスターの[TiDB Lightning設定ファイル](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)のパラメータ`Lightning.check-requirements`を`false`に変更し、インポートタスクを再起動する必要があります。
上流TiDBクラスタのインポートタスクが完了したら、 TiDB Lightningを使用して、同じデータを下流TiDBクラスタにインポートします。下流にRedshiftやSnowflakeなどのデータベースがある場合は、クラウドストレージサービスからCSV、SQL、またはParquetファイルを読み取り、データベースに書き込むように設定できます。
diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md
index 9be7b0b92b966..413292d75abb8 100644
--- a/tidb-lightning/tidb-lightning-configuration.md
+++ b/tidb-lightning/tidb-lightning-configuration.md
@@ -3,7 +3,7 @@ title: TiDB Lightning Configuration
summary: TiDB Lightningの CLI の使用方法とサンプル構成について学習します。
---
-# TiDB Lightningコンフィグレーション {#tidb-lightning-configuration}
+# TiDB Lightning設定 {#tidb-lightning-configuration}
このドキュメントでは、グローバル設定とタスク設定のサンプルを提供し、コマンドラインパラメータの使用方法を説明します。サンプル設定ファイルは[`lightning/tidb-lightning.toml`](https://github.com/pingcap/tidb/blob/master/lightning/tidb-lightning.toml)にあります。
@@ -513,7 +513,7 @@ CSV ファイルの解析方法を構成します。
#### `host` {#host}
-- クラスターからの任意の TiDBサーバーのコンフィグレーション。
+- クラスターからの任意の TiDBサーバーの設定。
diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md
index 7392b2cc46ed5..00afb9dee28c9 100644
--- a/tidb-lightning/tidb-lightning-data-source.md
+++ b/tidb-lightning/tidb-lightning-data-source.md
@@ -106,7 +106,7 @@ CSVファイルはスキーマレスです。CSVファイルをTiDBにインポ
- DDL文を含む`${db_name}.${table_name}-schema.sql`および`${db_name}-schema-create.sql`名前のファイルを作成します。
- TiDB にテーブルスキーマを手動で作成します。
-### コンフィグレーション {#configuration}
+### 設定 {#configuration}
CSV形式は、 `tidb-lightning.toml`ファイルの`[mydumper.csv]`セクションで設定できます。ほとんどの設定には、MySQLの[`LOAD DATA`](https://dev.mysql.com/doc/refman/8.0/en/load-data.html)ステートメントに対応するオプションがあります。
diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md
index 147a7dde34531..c4c49ba4a180f 100644
--- a/tidb-lightning/tidb-lightning-distributed-import.md
+++ b/tidb-lightning/tidb-lightning-distributed-import.md
@@ -82,7 +82,7 @@ Dumpling を使用してデータをエクスポートする方法の詳細に
### ステップ2: TiDB Lightningデータソースを構成する {#step-2-configure-tidb-lightning-data-sources}
-構成ファイル`tidb-lightning.toml`を作成し、次のコンテンツを追加します。
+設定ファイル`tidb-lightning.toml`を作成し、次のコンテンツを追加します。
```
[lightning]
diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md
index a8fc59cc8bd85..cecef74e46ddd 100644
--- a/tidb-lightning/tidb-lightning-faq.md
+++ b/tidb-lightning/tidb-lightning-faq.md
@@ -207,7 +207,7 @@ TiDB LightningでSQLの配置ルールを使用するには、データをター
この設定ファイルでは、元のダンプで使用されたスキーマ名とは異なるスキーマ名を使用するため、 `schema = 'test2'`を設定します。ファイル名はテーブル名を決定するために使用されます。
-3. この構成ファイルを使用してインポートを実行します。
+3. この設定ファイルを使用してインポートを実行します。
```
tiup tidb-lightning -config /tmp/tidb-lightning.toml
diff --git a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md
index df8058788c576..4f64c6bfc4322 100644
--- a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md
+++ b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md
@@ -43,7 +43,7 @@ password = ""
log-level = "error"
```
-完全な設定ファイルについては、 [TiDB Lightning のコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。
+完全な設定ファイルについては、 [TiDB Lightning の設定](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。
## 競合検出 {#conflict-detection}
diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md
index 31bd6d68ba88e..5e3515e683bdb 100644
--- a/tidb-performance-tuning-config.md
+++ b/tidb-performance-tuning-config.md
@@ -116,7 +116,7 @@ level0-slowdown-writes-trigger = 20
soft-pending-compaction-bytes-limit = "192GiB"
```
-| コンフィグレーションアイテム | 説明 | 注記 |
+| 設定項目 | 説明 | 注記 |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [`concurrent-send-snap-limit`](/tikv-configuration-file.md#concurrent-send-snap-limit) [`concurrent-recv-snap-limit`](/tikv-configuration-file.md#concurrent-recv-snap-limit) [`snap-io-max-bytes-per-sec`](/tikv-configuration-file.md#snap-io-max-bytes-per-sec) | TiKVのスケーリング操作中に、同時スナップショット転送量とI/O帯域幅の制限を設定します。制限値を高く設定すると、データ移行が高速化され、スケーリング時間が短縮されます。 | これらの制限を調整すると、スケーリング速度とオンライントランザクションパフォーマンスのトレードオフに影響します。 |
| [`rocksdb.max-manifest-file-size`](/tikv-configuration-file.md#max-manifest-file-size) | RocksDB マニフェストファイルの最大サイズを設定します。このファイルには、SST ファイルとデータベースの状態変更に関するメタデータが記録されます。このサイズを大きくすると、マニフェストファイルの書き換え頻度が減り、フォアグラウンド書き込みパフォーマンスへの影響を最小限に抑えることができます。 | デフォルト値は`128MiB`です。SSTファイルが多数存在する環境（例えば、数十万個）では、マニフェストファイルの書き換えが頻繁に行われると、書き込みパフォーマンスが低下する可能性があります。このパラメータを`256MiB`以上の値に調整することで、最適なパフォーマンスを維持できます。 |
@@ -156,7 +156,7 @@ TiFlash-learner 設定ファイルに以下の設定項目を追加してくだ
snap-io-max-bytes-per-sec = "300MiB"
```
-| コンフィグレーションアイテム | 説明 | 注記 |
+| 設定項目 | 説明 | 注記 |
| ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| [`snap-io-max-bytes-per-sec`](/tikv-configuration-file.md#snap-io-max-bytes-per-sec) | TiKVからTiFlashへのデータレプリケーションにおける、最大許容ディスク帯域幅を制御します。制限値を高く設定すると、初期データロードとキャッチアップレプリケーションが高速化されます。 | 帯域幅の消費量が増加すると、オンライントランザクションのパフォーマンスに影響が出る可能性があります。レプリケーション速度とシステム安定性のバランスを取ることが重要です。 |
@@ -479,7 +479,7 @@ TiDBは集計処理をTiKVにプッシュダウンすることで、データ転
- 固有の識別子またはタイムスタンプ。
- 例：ユーザーID、トランザクションID。
-#### コンフィグレーション {#configuration}
+#### 設定 {#configuration}
セッションレベルまたはグローバルレベルでプッシュダウン最適化を有効にする：
diff --git a/tidb-upgrade-migration-guide.md b/tidb-upgrade-migration-guide.md
index f102aa79fe6cc..c9d56213cc173 100644
--- a/tidb-upgrade-migration-guide.md
+++ b/tidb-upgrade-migration-guide.md
@@ -74,7 +74,7 @@ SET GLOBAL tidb_gc_life_time=60h;
- バックアップ速度: 8つのスレッドで TiKV ノードごとに 1 TiB のデータのバックアップに約1時間かかります。
- 復元速度: TiKV ノードごとに 1 TiB のデータの復元には約20分かかります。
-- **コンフィグレーションの整合性**：古いクラスタと新しいクラスタの構成が[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)であることを確認してください。同一でない場合、 BRの復元は失敗します。
+- **設定の整合性**：古いクラスタと新しいクラスタで、[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)の設定値が同一であることを確認してください。同一でない場合、BRの復元は失敗します。
- **システムテーブルの復元**: BR復元中に`--with-sys-table`オプションを使用して、システムテーブルデータを復元します。
@@ -184,7 +184,7 @@ tiup cluster start # Start the cluster
この移行手順では、 BR `--with-sys-table`オプションを使用して一部のシステムテーブルデータを復元します。対象範囲に含まれないテーブルについては、手動で復元する必要があります。確認および補足すべき一般的な項目は次のとおりです。
- ユーザー権限： `mysql.user`テーブルを比較します。
-- コンフィグレーション設定: 設定項目とシステム変数が一貫していることを確認します。
+- 設定: 設定項目とシステム変数が一貫していることを確認します。
- AUTO_INCREMENT列: 新しいクラスター内のAUTO_INCREMENT ID キャッシュをクリアします。
- 統計: 統計を手動で収集するか、新しいクラスターで自動収集を有効にします。
diff --git a/tiflash-deployment-topology.md b/tiflash-deployment-topology.md
index ff902a942f618..3a4b2e9c1ea39 100644
--- a/tiflash-deployment-topology.md
+++ b/tiflash-deployment-topology.md
@@ -28,13 +28,13 @@ TiFlashは列指向型ストレージエンジンであり、徐々に標準的
- [TiFlashトポロジのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiflash.yaml)
- [TiFlashトポロジの複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-tiflash.yaml)
-上記の TiDB クラスター トポロジファイルの設定項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。
+上記の TiDB クラスター トポロジファイルの設定項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジ設定ファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。
### 主なパラメータ {#key-parameters}
- PD の[配置ルール](/configure-placement-rules.md)機能を有効にするには、構成テンプレートの`replication.enable-placement-rules`の値を`true`に設定します。
- `tiflash_servers`のインスタンスレベル`"-host"`構成では、ドメイン名ではなく IP のみがサポートされます。
-- TiFlashパラメータの詳細な説明については、 [TiFlashコンフィグレーション](/tiflash/tiflash-configuration.md)を参照してください。
+- TiFlashパラメータの詳細な説明については、 [TiFlash設定](/tiflash/tiflash-configuration.md)を参照してください。
> **Note:**
>
diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md
index 1cf429cdd7928..c50a90720e087 100644
--- a/tiflash/create-tiflash-replicas.md
+++ b/tiflash/create-tiflash-replicas.md
@@ -208,7 +208,7 @@ TiDB クラスターは、次のいずれかの操作を実行すると、 TiFla
レプリカを構成する際に、災害復旧のためにTiFlashレプリカを複数のデータセンターに分散する必要がある場合は、次の手順に従って使用可能なゾーンを構成できます。
-1. クラスター構成ファイルでTiFlashノードのラベルを指定します。
+1. クラスター設定ファイルでTiFlashノードのラベルを指定します。
```
tiflash_servers:
diff --git a/tiflash/tiflash-command-line-flags.md b/tiflash/tiflash-command-line-flags.md
index 32ad93721b6fb..92d22c46116bb 100644
--- a/tiflash/tiflash-command-line-flags.md
+++ b/tiflash/tiflash-command-line-flags.md
@@ -9,7 +9,7 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま
## `server --config-file` {#server---config-file}
-- TiFlash構成ファイルのパスを指定します
+- TiFlash設定ファイルのパスを指定します
- デフォルト： ""
- 設定ファイルを指定する必要があります。詳細な設定項目については[TiFlash設定パラメータ](/tiflash/tiflash-configuration.md)を参照してください。
@@ -25,7 +25,7 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま
- 小さなファイルのマージが有効になっているバージョン v7.3.0 以上 (つまり、 `storage.format_version` >= 5) のTiFlash をバージョン v7.3.0 未満にダウングレードする必要がある場合は、このツールを使用して DTFile のデータ形式をダウングレードできます。
- パラメータ:
- - `--imitative` : DTFile の暗号化機能を使用しない場合は、このフラグを使用して構成ファイルの使用と PD への接続を回避できます。
+ - `--imitative` : DTFile の暗号化機能を使用しない場合は、このフラグを使用して設定ファイルの使用と PD への接続を回避できます。
- `--version` : DTFileのターゲットバージョン。値のオプションは`1` 、 `2` （デフォルト）、 `3`です。 `1`は古いバージョン、 `2`は新しいチェックサムに対応するバージョン、 `3`は小さなファイルのマージをサポートするバージョンです。
- `--algorithm` : データ検証に使用するハッシュアルゴリズム。値の選択肢は`xxh3` （デフォルト）、 `city128` 、 `crc32` 、 `crc64` 、 `none`です。このパラメータは`version`が`2`の場合にのみ有効です。
- `--frame` : 検証フレームのサイズ。デフォルト値は`1048576`です。このパラメータは`version`が`2`の場合にのみ有効です。
diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md
index e50f330ec3eef..e599dc30cda2e 100644
--- a/tiflash/tiflash-configuration.md
+++ b/tiflash/tiflash-configuration.md
@@ -284,7 +284,7 @@ I/O トラフィック制限設定を構成します。
##### `config` {#config}
-- プロキシの構成ファイルパス。
+- プロキシの設定ファイルパス。
diff --git a/tiflash/tiflash-disaggregated-and-s3.md b/tiflash/tiflash-disaggregated-and-s3.md
index eb67a2b5d6cdc..d2f107ae8e639 100644
--- a/tiflash/tiflash-disaggregated-and-s3.md
+++ b/tiflash/tiflash-disaggregated-and-s3.md
@@ -73,7 +73,7 @@ TiFlashの分散型ストレージおよびコンピューティングアーキ
デフォルトでは、 TiUPはTiFlash を結合ストレージおよびコンピューティングアーキテクチャにデプロイします。分離ストレージおよびコンピューティングアーキテクチャにTiFlashをデプロイする必要がある場合は、以下の手順に従って手動で設定してください。
-1. 次の構成を持つ、 `scale-out.topo.yaml`などのTiFlashトポロジ構成ファイルを準備します。
+1. 次の構成を持つ、 `scale-out.topo.yaml`などのTiFlashトポロジ設定ファイルを準備します。
```yaml
tiflash_servers:
@@ -149,13 +149,13 @@ TiFlashの分散型ストレージおよびコンピューティングアーキ
3. 分散ストレージおよびコンピューティングアーキテクチャを使用してTiFlash をクエリするように TiDB 構成を変更します。
- 1. TiDB 構成ファイルを編集モードで開きます。
+ 1. TiDB 設定ファイルを編集モードで開きます。
```shell
tiup cluster edit-config mycluster
```
- 2. TiDB 構成ファイルに次の設定項目を追加します。
+ 2. TiDB 設定ファイルに次の設定項目を追加します。
```shell
server_configs:
diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md
index ad3d66f06e97a..fc94b5e70acae 100644
--- a/tikv-configuration-file.md
+++ b/tikv-configuration-file.md
@@ -3,7 +3,7 @@ title: TiKV Configuration File
summary: TiKVの設定ファイルについて学びましょう。
---
-# TiKVコンフィグレーションファイル {#tikv-configuration-file}
+# TiKV設定ファイル {#tikv-configuration-file}
@@ -52,7 +52,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多
## log New in v5.4.0 {#log-new-in-v540}
-- ログに関連するコンフィグレーション項目。
+- ログに関連する設定項目。
- バージョン 5.4.0 以降、TiKV と TiDB のログ設定項目を統一するため、TiKV は以前の設定項目`log-rotation-timespan`を非推奨とし、 `log-level` 、 `log-format` 、 `log-file` 、 `log-rotation-size`を以下の項目に変更します。古い設定項目のみを設定し、その値をデフォルト値以外に設定した場合、古い項目は新しい項目と互換性があります。古い設定項目と新しい設定項目の両方を設定した場合、新しい項目が有効になります。
@@ -76,7 +76,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多
## log.file v5.4.0で追加 {#logfile-new-in-v540}
-- ログファイルに関連するコンフィグレーション項目。
+- ログファイルに関連する設定項目。
### `filename` v5.4.0 で追加 {#filename-new-in-v540}
@@ -106,7 +106,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多
## server {#server}
-- サーバーに関連するコンフィグレーション項目。
+- サーバーに関連する設定項目。
### `addr` {#addr}
@@ -311,7 +311,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多
## readpool.unified {#readpoolunified}
-読み取りリクエストを処理するシングルスレッドプールに関連するコンフィグレーション項目。このスレッドプールは、バージョン4.0以降、従来のストレージスレッドプールとコプロセッサスレッドプールに取って代わるものです。
+読み取りリクエストを処理するシングルスレッドプールに関連する設定項目。このスレッドプールは、バージョン4.0以降、従来のストレージスレッドプールとコプロセッサスレッドプールに取って代わるものです。
### `min-thread-count` {#min-thread-count}
@@ -365,7 +365,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多
## readpool.storage {#readpoolstorage}
-ストレージスレッドプールに関連するコンフィグレーション項目。
+ストレージスレッドプールに関連する設定項目。
### `use-unified-pool` {#use-unified-pool-1}
@@ -419,7 +419,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多
## `readpool.coprocessor` {#readpoolcoprocessor}
-コプロセッサースレッドプールに関連するコンフィグレーション項目。
+コプロセッサースレッドプールに関連する設定項目。
### `use-unified-pool` {#use-unified-pool}
@@ -473,7 +473,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多
## storage {#storage}
-ストレージに関連するコンフィグレーション項目。
+ストレージに関連する設定項目。
### `data-dir` {#data-dir}
@@ -573,7 +573,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多
## storage.block-cache {#storageblock-cache}
-複数の RocksDBカラムファミリー (CF) 間でブロックキャッシュを共有することに関連するコンフィグレーション項目。
+複数の RocksDBカラムファミリー (CF) 間でブロックキャッシュを共有することに関連する設定項目。
### `capacity` {#capacity-1}
@@ -593,7 +593,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多
## storage.flow-control {#storageflow-control}
-TiKVにおけるフロー制御メカニズムに関連するコンフィグレーション項目。このメカニズムはRocksDBの書き込み停止メカニズムに代わるもので、スケジューラレイヤーでのフローを制御することで、 RaftstoreやApplyスレッドの停止によって引き起こされる二次的な障害を回避します。
+TiKVにおけるフロー制御メカニズムに関連する設定項目。このメカニズムはRocksDBの書き込み停止メカニズムに代わるもので、スケジューラレイヤーでのフローを制御することで、 RaftstoreやApplyスレッドの停止によって引き起こされる二次的な障害を回避します。
### `enable` {#enable-1}
@@ -632,7 +632,7 @@ TiKVにおけるフロー制御メカニズムに関連するコンフィグレ
## storage.io-rate-limit {#storageio-rate-limit}
-I/Oレートリミッターに関連するコンフィグレーション項目。
+I/Oレートリミッターに関連する設定項目。
### `max-bytes-per-sec` {#max-bytes-per-sec}
@@ -706,7 +706,7 @@ I/Oレートリミッターに関連するコンフィグレーション項目
## raftstore {#raftstore}
-Raftstoreに関連するコンフィグレーション項目。
+Raftstoreに関連する設定項目。
### `prevote` {#prevote}
@@ -1230,7 +1230,7 @@ Raftstoreに関連するコンフィグレーション項目。
## coprocessor {#coprocessor}
-コプロセッサーに関連するコンフィグレーション項目。
+コプロセッサーに関連する設定項目。
### `split-region-on-table` {#split-region-on-table}
@@ -1301,7 +1301,7 @@ Raftstoreに関連するコンフィグレーション項目。
## rocksdb {#rocksdb}
-RocksDBに関連するコンフィグレーション項目
+RocksDBに関連する設定項目
### `max-background-jobs` {#max-background-jobs-1}
@@ -1538,7 +1538,7 @@ RocksDBに関連するコンフィグレーション項目
## rocksdb.titan {#rocksdbtitan}
-Titanに関連するコンフィグレーション項目。
+Titanに関連する設定項目。
### `enabled` {#enabled}
@@ -1569,7 +1569,7 @@ Titanに関連するコンフィグレーション項目。
## rocksdb.defaultcf | rocksdb.writecf | rocksdb.lockcf | rocksdb.raftcf {#rocksdbdefaultcf--rocksdbwritecf--rocksdblockcf--rocksdbraftcf}
-`rocksdb.defaultcf` 、 `rocksdb.writecf` 、および`rocksdb.lockcf`に関連するコンフィグレーション項目。
+`rocksdb.defaultcf` 、 `rocksdb.writecf` 、および`rocksdb.lockcf`に関連する設定項目。
### `block-size` {#block-size}
@@ -1841,7 +1841,7 @@ Titanに関連するコンフィグレーション項目。
>
> Titan は`rocksdb.defaultcf`でのみ有効にできます。 `rocksdb.writecf`では Titan の有効化はサポートされていません。
-`rocksdb.defaultcf.titan`に関連するコンフィグレーション項目。
+`rocksdb.defaultcf.titan`に関連する設定項目。
### `min-blob-size` {#min-blob-size}
@@ -1946,7 +1946,7 @@ Titanに関連するコンフィグレーション項目。
## raftdb {#raftdb}
-`raftdb`に関連するコンフィグレーション項目
+`raftdb`に関連する設定項目
### `max-background-jobs` {#max-background-jobs}
@@ -2101,7 +2101,7 @@ Titanに関連するコンフィグレーション項目。
## Raft Engine {#raft-engine}
-Raft Engineに関連するコンフィグレーション項目。
+Raft Engineに関連する設定項目。
> **Note:**
>
@@ -2228,7 +2228,7 @@ Raft Engineに関連するコンフィグレーション項目。
## 安全 {#security}
-セキュリティに関連するコンフィグレーション項目。
+セキュリティに関連する設定項目。
### `ca-path` {#ca-path}
@@ -2261,7 +2261,7 @@ Raft Engineに関連するコンフィグレーション項目。
## セキュリティ暗号化 {#securityencryption}
-[保存時の暗号化](/encryption-at-rest.md)(TDE)に関するコンフィグレーション項目。
+[保存時の暗号化](/encryption-at-rest.md)(TDE)に関する設定項目。
### `data-encryption-method` {#data-encryption-method}
@@ -2278,7 +2278,7 @@ Raft Engineに関連するコンフィグレーション項目。
### `enable-file-dictionary-log` {#enable-file-dictionary-log}
- TiKVが暗号化メタデータを管理する際に、I/Oとミューテックスの競合を軽減するための最適化を有効にします。
-- この設定パラメーターが (デフォルトで) 有効になっている場合に発生する可能性のある互換性の問題を回避するには、詳細については[保存時の暗号化- TiKVバージョン間の互換性](/encryption-at-rest.md#compatibility-between-tikv-versions)を参照してください。
+- この設定パラメータがデフォルトで有効になっている場合に発生する可能性のある互換性の問題を回避する方法については、[保存時の暗号化- TiKVバージョン間の互換性](/encryption-at-rest.md#compatibility-between-tikv-versions)を参照してください。
- デフォルト値: `true`
### `master-key` {#master-key}
@@ -2291,7 +2291,7 @@ Raft Engineに関連するコンフィグレーション項目。
## インポート {#import}
-TiDB LightningのインポートおよびBR復元に関連するコンフィグレーション項目。
+TiDB LightningのインポートおよびBR復元に関連する設定項目。
### `num-threads` {#num-threads-1}
@@ -2405,7 +2405,7 @@ TiKVの自動圧縮の動作を設定します。
## バックアップ {#backup}
-BRバックアップに関連するコンフィグレーション項目。
+BRバックアップに関連する設定項目。
### `num-threads` {#num-threads}
@@ -2463,7 +2463,7 @@ BRバックアップに関連するコンフィグレーション項目。
## ログバックアップ {#log-backup}
-ログバックアップに関連するコンフィグレーション項目。
+ログバックアップに関連する設定項目。
### v6.2.0で`enable` {#enable-new-in-v620}
@@ -2513,7 +2513,7 @@ BRバックアップに関連するコンフィグレーション項目。
## CDC {#cdc}
-TiCDCに関連するコンフィグレーション項目。
+TiCDCに関連する設定項目。
### `min-ts-interval` {#min-ts-interval}
@@ -2558,7 +2558,7 @@ TiCDCに関連するコンフィグレーション項目。
## resolved-ts {#resolved-ts}
-ステイル読み取りリクエストを処理するために、Resolved TSを維持することに関連するコンフィグレーション項目。
+ステイル読み取りリクエストを処理するために、Resolved TSを維持することに関連する設定項目。
### `enable` {#enable}
@@ -2615,7 +2615,7 @@ TiCDCに関連するコンフィグレーション項目。
## クォータ {#quota}
-クォータリミッターに関連するコンフィグレーション項目。
+クォータリミッターに関連する設定項目。
### `max-delay-duration` v6.0.0で追加 {#max-delay-duration-new-in-v600}
@@ -2625,7 +2625,7 @@ TiCDCに関連するコンフィグレーション項目。
### フォアグラウンドクォータリミッター {#foreground-quota-limiter}
-フォアグラウンドのクォータリミッターに関連するコンフィグレーション項目。
+フォアグラウンドのクォータリミッターに関連する設定項目。
TiKV がデプロイされているマシンにリソースが限られている場合、たとえば、CPU が 4V、メモリが16GB しかないとします。このような状況では、TiKV のフォアグラウンドが読み書きリクエストを過剰に処理し、バックグラウンドで使用される CPU リソースがこれらのリクエストの処理に占有され、TiKV のパフォーマンスの安定性に影響する可能性があります。この状況を回避するには、フォアグラウンドのクォータ関連の設定項目を使用して、フォアグラウンドで使用される CPU リソースを制限できます。リクエストがクォータ リミッターをトリガーすると、リクエストは TiKV が CPU リソースを解放するまでしばらく待機させられます。正確な待機時間はリクエストの数によって異なり、最大待機時間は[`max-delay-duration`](#max-delay-duration-new-in-v600)の値を超えません。
@@ -2650,7 +2650,7 @@ TiKV がデプロイされているマシンにリソースが限られている
### バックグラウンドクォータリミッター {#background-quota-limiter}
-バックグラウンドクォータリミッターに関連するコンフィグレーション項目。
+バックグラウンドクォータリミッターに関連する設定項目。
TiKV がデプロイされているマシンにリソースが限られている場合、たとえば CPU が 4V、メモリが16GB しかない場合を考えてみましょう。このような状況では、TiKV のバックグラウンドで計算や読み書きリクエストが多すぎると、フォアグラウンドで使用される CPU リソースがこれらのリクエストの処理に占有され、TiKV のパフォーマンスの安定性に影響します。この状況を回避するには、バックグラウンドのクォータ関連の設定項目を使用して、バックグラウンドで使用される CPU リソースを制限できます。リクエストがクォータ リミッターをトリガーすると、TiKV が CPU リソースを解放するまで、リクエストはしばらく待機させられます。正確な待機時間はリクエストの数によって異なり、最大待機時間は[`max-delay-duration`](#max-delay-duration-new-in-v600)の値を超えません。
@@ -2682,7 +2682,7 @@ TiKV がデプロイされているマシンにリソースが限られている
## causal-ts v6.1.0の新機能 {#causal-ts-new-in-v610}
-TiKV API V2 が有効になっている場合にタイムスタンプを取得することに関連するコンフィグレーション項目 ( `storage.api-version = 2` )。
+TiKV API V2 が有効になっている場合にタイムスタンプを取得することに関連する設定項目 ( `storage.api-version = 2` )。
書き込みレイテンシーを低減するため、TiKVは定期的にタイムスタンプのバッチをローカルに取得してキャッシュします。キャッシュされたタイムスタンプは、PDへの頻繁なアクセスを回避し、TSOサービスの一時的な障害を許容するのに役立ちます。
@@ -2737,7 +2737,7 @@ TiKV API V2 が有効になっている場合にタイムスタンプを取得
## resource-control {#resource-control}
-TiKVストレージレイヤーのリソース制御に関連するコンフィグレーション項目。
+TiKVストレージレイヤーのリソース制御に関連する設定項目。
### `enabled` （v6.6.0で新規追加） {#enabled-new-in-v660}
@@ -2819,7 +2819,7 @@ TiKVストレージレイヤーのリソース制御に関連するコンフィ
## スプリット {#split}
-[ロードベース分割](/configure-load-base-split.md)に関するコンフィグレーション項目。
+[ロードベース分割](/configure-load-base-split.md)に関する設定項目。
### `byte-threshold` v5.0 で追加 {#byte-threshold-new-in-v50}
diff --git a/tikv-control.md b/tikv-control.md
index 72c71ef88e0e6..478d983353fc3 100644
--- a/tikv-control.md
+++ b/tikv-control.md
@@ -110,7 +110,7 @@ SUBCOMMANDS:
- ローカルモード:
- ローカル TiKV データディレクトリ パスを指定するには、 `--data-dir`オプションを使用します。
- - ローカル TiKV 構成ファイルパスを指定するには、 `--config`オプションを使用します。
+ - ローカル TiKV 設定ファイルパスを指定するには、 `--config`オプションを使用します。
このモードでは、実行中の TiKV インスタンスを停止する必要があります。
@@ -549,7 +549,7 @@ tikv-ctl ldb --hex manifest_dump --path=/tmp/db/MANIFEST-000001
暗号化メタデータをダンプするには、サブコマンド`encryption-meta`を使用します。このサブコマンドは、データファイルの暗号化情報と、使用されているデータ暗号化キーのリストという2種類のメタデータをダンプできます。
-データファイルの暗号化情報をダンプするには、サブコマンド`encryption-meta dump-file`を使用します。TiKV デプロイメントに`data-dir`を指定するには、TiKV 構成ファイルを作成する必要があります。
+データファイルの暗号化情報をダンプするには、サブコマンド`encryption-meta dump-file`を使用します。TiKV デプロイメントに`data-dir`を指定するには、TiKV 設定ファイルを作成する必要があります。
```
# conf.toml
diff --git a/tiproxy/tiproxy-command-line-flags.md b/tiproxy/tiproxy-command-line-flags.md
index 9aeff80a61f62..b77ced6b04e55 100644
--- a/tiproxy/tiproxy-command-line-flags.md
+++ b/tiproxy/tiproxy-command-line-flags.md
@@ -20,7 +20,7 @@ summary: TiProxy のコマンドライン起動フラグについて学習しま
### `--config` {#config}
-- TiProxy 構成ファイルのパスを指定します。
+- TiProxy 設定ファイルのパスを指定します。
- タイプ: `string`
- デフォルト: `""`
- 設定ファイルを指定する必要があります。詳細な設定項目については、 [TiProxy を設定する](/tiproxy/tiproxy-configuration.md)を参照してください。設定ファイルが変更されると、TiProxyは自動的に設定を再読み込みするため、設定ファイルを直接変更しないでください。[`tiup cluster edit-config`](/tiup/tiup-component-cluster-edit-config.md)または[`kubectl edit tc`](https://docs.pingcap.com/tidb-in-kubernetes/stable/modify-tidb-configuration)を実行して設定を変更することをお勧めします。
diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md
index 561bbf602951d..3424a73518774 100644
--- a/tiproxy/tiproxy-configuration.md
+++ b/tiproxy/tiproxy-configuration.md
@@ -3,7 +3,7 @@ title: TiProxy Configuration File
summary: TiProxy を構成する方法を学びます。
---
-# TiProxyコンフィグレーションファイル {#tiproxy-configuration-file}
+# TiProxy設定ファイル {#tiproxy-configuration-file}
このドキュメントでは、 TiProxyの導入と使用に関連する設定パラメータについて説明します。TiUP導入トポロジの設定については、 [tiproxy-servers の設定](/tiup/tiup-cluster-topology-reference.md#tiproxy_servers)を参照してください。
@@ -39,7 +39,7 @@ skip-ca = true
### プロキシ {#proxy}
-SQL ポートのコンフィグレーション。
+SQL ポートの設定。
#### `addr` {#addr}
diff --git a/tiproxy/tiproxy-deployment-topology.md b/tiproxy/tiproxy-deployment-topology.md
index d02a4a3342e1f..c3e7461025ddb 100644
--- a/tiproxy/tiproxy-deployment-topology.md
+++ b/tiproxy/tiproxy-deployment-topology.md
@@ -33,12 +33,12 @@ TiProxy は TiDB の L7 プロキシサーバーであり、接続のバラン
TiProxy のテンプレートの詳細については、 [TiProxyトポロジのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiproxy.yaml)を参照してください。
-前述の TiDB クラスタトポロジファイル内の設定項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。
+前述の TiDB クラスタトポロジファイル内の設定項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジ設定ファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。
### 主なパラメータ {#key-parameters}
- `tiproxy_servers`のインスタンスレベル`"-host"`構成では、ドメイン名ではなく IP のみがサポートされます。
-- TiProxyパラメータの詳細な説明については、 [TiProxy のコンフィグレーション](/tiproxy/tiproxy-configuration.md)を参照してください。
+- TiProxyパラメータの詳細な説明については、 [TiProxy の設定](/tiproxy/tiproxy-configuration.md)を参照してください。
> **Note:**
>
diff --git a/tiproxy/tiproxy-overview.md b/tiproxy/tiproxy-overview.md
index 800a15ee47cef..339df8179882d 100644
--- a/tiproxy/tiproxy-overview.md
+++ b/tiproxy/tiproxy-overview.md
@@ -131,11 +131,11 @@ TiProxyが適しているシナリオではTiProxyを使用し、アプリケー
- ワークロードの種類と最大 QPS に基づいて、TiProxy インスタンスのモデルと数を選択します。詳細については、 [TiProxyのパフォーマンステストレポート](/tiproxy/tiproxy-performance-test.md)を参照してください。
- TiProxyインスタンスは通常TiDBサーバーインスタンスよりも少ないため、TiProxyのネットワーク帯域幅がボトルネックになりやすくなります。たとえば、AWSでは、同じシリーズのEC2インスタンスのベースラインネットワーク帯域幅はCPUコア数に比例しません。ネットワーク帯域幅がボトルネックになった場合は、TiProxyインスタンスをより多くの小さなインスタンスに分割してQPSを向上させることができます。詳細については、 [ネットワーク仕様](https://docs.aws.amazon.com/ec2/latest/instancetypes/co.html#co_network)を参照してください。
- - トポロジ構成ファイルでTiProxyのバージョンを指定することをお勧めします。これにより、TiDBクラスタをアップグレードするためにコマンド[`tiup cluster upgrade`](/tiup/tiup-component-cluster-upgrade.md)を実行した際にTiProxyが自動的にアップグレードされるのを防ぎ、TiProxyのアップグレードによってクライアント接続が切断されるのを防止できます。
+ - トポロジ設定ファイルでTiProxyのバージョンを指定することをお勧めします。これにより、TiDBクラスタをアップグレードするためにコマンド[`tiup cluster upgrade`](/tiup/tiup-component-cluster-upgrade.md)を実行した際にTiProxyが自動的にアップグレードされるのを防ぎ、TiProxyのアップグレードによってクライアント接続が切断されるのを防止できます。
TiProxy のテンプレートの詳細については、 [TiProxyトポロジーのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiproxy.yaml)を参照してください。
- TiDBクラスタトポロジファイル内の設定項目の詳細については、 [TiUPを使用したTiDBデプロイメントのトポロジーコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。
+ TiDBクラスタトポロジファイル内の設定項目の詳細については、 [TiUPを使用したTiDBデプロイメントのトポロジー設定ファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。
設定例は以下のとおりです。
diff --git a/tiproxy/tiproxy-performance-test.md b/tiproxy/tiproxy-performance-test.md
index 123f3011a1035..c7026f849f7f6 100644
--- a/tiproxy/tiproxy-performance-test.md
+++ b/tiproxy/tiproxy-performance-test.md
@@ -40,7 +40,7 @@ summary: TiProxy のパフォーマンスと HAProxy との比較について学
| TiKV | バージョン8.0.0 |
| Sysbench | 1.0.17 |
-### コンフィグレーション {#configuration}
+### 設定 {#configuration}
#### TiProxy の設定 {#tiproxy-configuration}
diff --git a/tiup/customized-montior-in-tiup-environment.md b/tiup/customized-montior-in-tiup-environment.md
index 535c1ddd2a76a..540a054fbd146 100644
--- a/tiup/customized-montior-in-tiup-environment.md
+++ b/tiup/customized-montior-in-tiup-environment.md
@@ -11,21 +11,21 @@ TiUPを使用して TiDB クラスターをデプロイすると、 TiUP はProm
> **Note:**
>
-> - 監視サーバーの構成ファイルを直接変更しないでください。これらの変更は、デプロイメント、スケールアウト、スケールイン、リロードなどの後続のTiUP操作によって上書きされるためです。
+> - 監視サーバーの設定ファイルを直接変更しないでください。これらの変更は、デプロイメント、スケールアウト、スケールイン、リロードなどの後続のTiUP操作によって上書きされるためです。
>
-> - 監視サーバーがTiUPによってデプロイおよび管理されていない場合は、このドキュメントを参照する代わりに、監視サーバーの構成ファイルを直接変更できます。
+> - 監視サーバーがTiUPによってデプロイおよび管理されていない場合は、このドキュメントを参照する代わりに、監視サーバーの設定ファイルを直接変更できます。
>
> - この機能はTiUP v1.9.0以降でサポートされています。そのため、この機能を使用する前にTiUPのバージョンをご確認ください。
## Prometheusの設定をカスタマイズする {#customize-prometheus-configurations}
-現在、 TiUP はPrometheus ルールとスクレイプ構成ファイルのカスタマイズをサポートしています。
+現在、 TiUP はPrometheus ルールとスクレイプ設定ファイルのカスタマイズをサポートしています。
### Prometheusルール設定をカスタマイズする {#customize-prometheus-rule-configuration}
-1. ルール構成ファイルをカスタマイズし、 TiUP が配置されているマシンのディレクトリの下に配置します。
+1. ルール設定ファイルをカスタマイズし、 TiUP が配置されているマシンのディレクトリの下に配置します。
-2. topology.yaml ファイルで、カスタマイズされたルール構成ファイルのディレクトリに`rule_dir`を設定します。
+2. topology.yaml ファイルで、カスタマイズされたルール設定ファイルのディレクトリに`rule_dir`を設定します。
以下は、topology.yaml ファイル内の monitored_servers の構成例です。
@@ -70,7 +70,7 @@ TiUPを使用して TiDB クラスターをデプロイすると、 TiUP はProm
action: drop
```
-上記の構成が完了したら、TiDB クラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUP は`additional_scrape_conf`フィールドの内容を Prometheus 構成ファイルの対応するパラメーターに追加します。
+上記の構成が完了したら、TiDB クラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUP は`additional_scrape_conf`フィールドの内容を Prometheus 設定ファイルの対応するパラメーターに追加します。
### Prometheus external labels をカスタマイズする {#customize-prometheus-external-labels}
@@ -102,9 +102,9 @@ TiUP v1.17.0 以降では、トポロジーファイルで Prometheus グロー
### Grafanaダッシュボードをカスタマイズする {#customize-grafana-dashboard}
-1. Grafana ダッシュボードの構成ファイルをカスタマイズし、 TiUPが配置されているマシンのディレクトリの下に配置します。
+1. Grafana ダッシュボードの設定ファイルをカスタマイズし、 TiUPが配置されているマシンのディレクトリの下に配置します。
-2. topology.yaml ファイルで、カスタマイズされたダッシュボード構成ファイルのディレクトリに`dashboard_dir`を設定します。
+2. topology.yaml ファイルで、カスタマイズされたダッシュボード設定ファイルのディレクトリに`dashboard_dir`を設定します。
以下は、topology.yaml ファイル内の grafana_servers の構成例です。
@@ -140,7 +140,7 @@ TiUP v1.17.0 以降では、トポロジーファイルで Prometheus グロー
smtp.skip_verify: true
```
-上記の構成が完了したら、TiDB クラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUP は`config`フィールドの内容を Grafana 構成ファイル`grafana.ini`に追加します。
+上記の構成が完了したら、TiDB クラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUP は`config`フィールドの内容を Grafana 設定ファイル`grafana.ini`に追加します。
## Alertmanager の設定をカスタマイズする {#customize-alertmanager-configurations}
diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md
index ef9fe555b0553..48107780cbf98 100644
--- a/tiup/tiup-cluster-no-sudo-mode.md
+++ b/tiup/tiup-cluster-no-sudo-mode.md
@@ -160,7 +160,7 @@ Node Check Result Message
no-sudoモードでは、 `tidb`ユーザーにはsudo権限がありません。そのため、 `tiup cluster check topology.yaml --apply --user tidb`を実行しても失敗したチェック項目を自動的に修正することはできません。対象マシンで`root`ユーザーを使用して手動で修正する必要があります。
-詳細については、 [TiDB環境とシステムコンフィグレーションのチェック](/check-before-deployment.md)を参照してください。ドキュメントの手順[SSH相互信頼とパスワードなしのsudoを手動で設定する](/check-before-deployment.md#manually-configure-the-ssh-mutual-trust-and-sudo-without-password)をスキップする必要があることに注意してください。
+詳細については、 [TiDB環境とシステム設定のチェック](/check-before-deployment.md)を参照してください。ドキュメントの手順[SSH相互信頼とパスワードなしのsudoを手動で設定する](/check-before-deployment.md#manually-configure-the-ssh-mutual-trust-and-sudo-without-password)をスキップする必要があることに注意してください。
## クラスターのデプロイと管理 {#deploy-and-manage-the-cluster}
diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md
index 9fee88c3443ba..b39c1c258db4d 100644
--- a/tiup/tiup-cluster-topology-reference.md
+++ b/tiup/tiup-cluster-topology-reference.md
@@ -3,7 +3,7 @@ title: Topology Configuration File for TiDB Deployment Using TiUP
summary: TiUPは、トポロジファイルを使用してTiDBのクラスタートポロジをデプロイまたは変更します。また、Prometheus、Grafana、Alertmanagerなどの監視サーバーもデプロイします。トポロジファイルには、グローバル設定、監視サービス、コンポーネントバージョンなどのセクションが含まれています。各セクションでは、対応するサービスがデプロイされるマシンとその設定を指定します。
---
-# TiUPを使用した TiDB デプロイメントのトポロジコンフィグレーションファイル {#topology-configuration-file-for-tidb-deployment-using-tiup}
+# TiUPを使用した TiDB デプロイメントのトポロジ設定ファイル {#topology-configuration-file-for-tidb-deployment-using-tiup}
TiUPを使用して TiDB をデプロイまたは拡張するには、クラスター トポロジを記述するトポロジファイル ( [サンプル](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml) ) を提供する必要があります。
@@ -13,10 +13,10 @@ TiUPを使用して TiDB クラスターをデプロイすると、Prometheus、
## ファイル構造 {#file-structure}
-TiUPを使用した TiDB デプロイメントのトポロジ構成ファイルには、次のセクションが含まれる場合があります。
+TiUPを使用した TiDB デプロイメントのトポロジ設定ファイルには、次のセクションが含まれる場合があります。
- [グローバル](#global) : クラスターのグローバル設定。一部の設定項目はデフォルト値を使用しますが、インスタンスごとに個別に設定できます。
-- [監視](#monitored) : 監視サービス（blackbox_exporterと`node_exporter`のコンフィグレーション。各マシンに`node_exporter`と`blackbox_exporter`がデプロイされています。
+- [監視](#monitored) : 監視サービス（blackbox_exporterと`node_exporter`の設定。各マシンに`node_exporter`と`blackbox_exporter`がデプロイされています。
- [サーバー構成](#server_configs) : コンポーネントのグローバル設定。各コンポーネントを個別に設定できます。インスタンスに同じ名前の設定項目がある場合は、インスタンスの設定項目が有効になります。
- [コンポーネントバージョン](#component_versions) : コンポーネントバージョン。コンポーネントがクラスタバージョンを使用しない場合に設定します。このセクションはtiup-cluster v1.14.0で導入されました。
- [pd_servers](#pd_servers) : PDインスタンスの構成。この構成では、PDコンポーネントがデプロイされるマシンを指定します。
@@ -131,7 +131,7 @@ monitored:
`server_configs`は、サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。`global`と同様に、このセクションの設定は、インスタンス内の同名の設定によって上書きできます。`server_configs`は主に以下のフィールドが含まれます。
-- `tidb` : TiDBサービス関連の設定。詳細な設定については[TiDB構成ファイル](/tidb-configuration-file.md)を参照してください。
+- `tidb` : TiDBサービス関連の設定。詳細な設定については[TiDB設定ファイル](/tidb-configuration-file.md)を参照してください。
- `tikv` : TiKVサービス関連の設定。詳細な設定については[TiKV設定ファイル](/tikv-configuration-file.md)を参照してください。
@@ -145,7 +145,7 @@ monitored:
- `cdc` : TiCDCサービス関連の設定。詳細な設定については[TiCDCをデプロイ](/ticdc/deploy-ticdc.md)を参照してください。
-- `tso` : `tso`マイクロサービス関連の設定。完全な設定については[TSO構成ファイル](/tso-configuration-file.md)を参照してください。
+- `tso` : `tso`マイクロサービス関連の設定。完全な設定については[TSO設定ファイル](/tso-configuration-file.md)を参照してください。
- `scheduling` : `scheduling`マイクロサービス関連の設定。完全な設定については[スケジュール設定ファイル](/scheduling-configuration-file.md)を参照してください。
@@ -494,7 +494,7 @@ tiproxy_servers:
- `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)を使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。
-- `config` : TiKV-CDC が使用する構成ファイルのアドレス (オプション)。
+- `config` : TiKV-CDC が使用する設定ファイルのアドレス (オプション)。
- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。
diff --git a/tiup/tiup-command-telemetry.md b/tiup/tiup-command-telemetry.md
index 6b8e3527edee2..98d06d8061ac4 100644
--- a/tiup/tiup-command-telemetry.md
+++ b/tiup/tiup-command-telemetry.md
@@ -17,7 +17,7 @@ TiUPテレメトリが有効になっている場合、 TiUPコマンドの実
- クラスターの正確な名前
- クラスタートポロジー
-- クラスタ構成ファイル
+- クラスタ設定ファイル
TiUP は`tiup telemetry`コマンドを使用してテレメトリを制御します。
diff --git a/tiup/tiup-component-cluster-deploy.md b/tiup/tiup-component-cluster-deploy.md
index 79361e9fb2128..70c3cf231e6ca 100644
--- a/tiup/tiup-component-cluster-deploy.md
+++ b/tiup/tiup-component-cluster-deploy.md
@@ -39,7 +39,7 @@ tiup cluster deploy [flags]
### --ignore-config-check {#ignore-config-check}
-- このオプションは、構成チェックをスキップするために使用されます。コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `を使用してTiDB、TiKV、およびPDコンポーネントの構成がチェックされます。``は、デプロイされたバイナリファイルのパスです。``は、ユーザー設定に基づいて生成された構成ファイルです。
+- このオプションは、構成チェックをスキップするために使用されます。コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `を使用してTiDB、TiKV、およびPDコンポーネントの構成がチェックされます。``は、デプロイされたバイナリファイルのパスです。``は、ユーザー設定に基づいて生成された設定ファイルです。
- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。
- デフォルト: false
diff --git a/tiup/tiup-component-cluster-import.md b/tiup/tiup-component-cluster-import.md
index 03240ce101e52..d7e99fa061a69 100644
--- a/tiup/tiup-component-cluster-import.md
+++ b/tiup/tiup-component-cluster-import.md
@@ -17,7 +17,7 @@ TiDB v4.0より前のバージョンでは、TiDBクラスターは主にTiDB An
> - Sparkが有効になっているクラスター
> - TiDB Lightning/TiKVインポーターが有効になっているクラスター
> - 監視メトリックを収集するために古いモード`push`をまだ使用しているクラスター (デフォルト モード`pull`を変更しない場合は、 `import`コマンドの使用がサポートされます)
-> - デフォルト以外のポート（ `group_vars`ディレクトリに設定されているポートは互換性がある）が`node_exporter_port` / `blackbox_exporter_port`を使用して`inventory.ini`構成ファイルで個別に設定されているクラスタ
+> - デフォルト以外のポート（ `group_vars`ディレクトリに設定されているポートは互換性がある）が`node_exporter_port` / `blackbox_exporter_port`を使用して`inventory.ini`設定ファイルで個別に設定されているクラスタ
> - TiDB Ansibleを使用してデプロイしたクラスター内の一部のノードに監視コンポーネントがデプロイされていない場合は、まずTiDB Ansibleを使用して`inventory.ini`ファイルの`monitored_servers`セクションに対応するノード情報を追加し、その後`deploy.yaml`プレイブックを使用して監視コンポーネントを完全にデプロイする必要があります。そうしないと、クラスターをTiUPにインポートした後にメンテナンス操作を実行すると、監視コンポーネントの不足によりエラーが発生する可能性があります。
## 構文 {#syntax}
@@ -36,7 +36,7 @@ tiup cluster import [flags]
### --ansible-config {#ansible-config}
-- Ansible 構成ファイルのパスを指定します。
+- Ansible 設定ファイルのパスを指定します。
- データ型: `STRING`
- このオプションはデフォルトで有効になっており、 `. /ansible.cfg` (デフォルト値) が渡されます。
diff --git a/tiup/tiup-component-cluster-patch.md b/tiup/tiup-component-cluster-patch.md
index 16ec1f08526a0..e2565e94a24c0 100644
--- a/tiup/tiup-component-cluster-patch.md
+++ b/tiup/tiup-component-cluster-patch.md
@@ -57,7 +57,7 @@ tiup cluster patch [flags]
find .
```
-6. バイナリファイルまたは構成ファイルを一時ディレクトリ内の対応する場所にコピーします。
+6. バイナリファイルまたは設定ファイルを一時ディレクトリ内の対応する場所にコピーします。
7. すべてのファイルを一時ディレクトリにパックします。
diff --git a/tiup/tiup-component-cluster-upgrade.md b/tiup/tiup-component-cluster-upgrade.md
index 73ac4c7cbf40e..9f3444156d666 100644
--- a/tiup/tiup-component-cluster-upgrade.md
+++ b/tiup/tiup-component-cluster-upgrade.md
@@ -40,7 +40,7 @@ tiup cluster upgrade [flags]
### --ignore-config-check {#--ignore-config-check}
-- バイナリの更新後、 ` --config-check `を使用して TiDB、TiKV、PD コンポーネントの構成チェックが実行されます。``は、新しくデプロイされたバイナリへのパスであり、 ``は、ユーザー設定に基づいて生成された構成ファイルです。このチェックをスキップするには、 `--ignore-config-check`オプションを使用します。
+- バイナリの更新後、 ` --config-check `を使用して TiDB、TiKV、PD コンポーネントの構成チェックが実行されます。``は、新しくデプロイされたバイナリへのパスであり、 ``は、ユーザー設定に基づいて生成された設定ファイルです。このチェックをスキップするには、 `--ignore-config-check`オプションを使用します。
- データ型: `BOOLEAN`
- デフォルト: false
diff --git a/tiup/tiup-component-dm-patch.md b/tiup/tiup-component-dm-patch.md
index 278a4a38a8338..2d045bcca1970 100644
--- a/tiup/tiup-component-dm-patch.md
+++ b/tiup/tiup-component-dm-patch.md
@@ -31,7 +31,7 @@ tiup dm patch [flags]
- `mkdir -p /tmp/package && cd /tmp/package`を実行して、ファイルをパックするための一時ディレクトリを作成します。
- `tar xf /tmp/${component}-${version}-${os}-${arch}.tar.gz`を実行して元のバイナリパッケージを解凍します。
- `find .`を実行して、一時パッケージ ディレクトリ内のファイル構造を表示します。
-- バイナリファイルまたは構成ファイルを一時ディレクトリ内の対応する場所にコピーします。
+- バイナリファイルまたは設定ファイルを一時ディレクトリ内の対応する場所にコピーします。
- `tar czf /tmp/${component}-hotfix-${os}-${arch}.tar.gz *`を実行して、一時ディレクトリにファイルをパックします。
- 最後に、 `tiup dm patch`コマンドの``の値として`/tmp/${component}-hotfix-${os}-${arch}.tar.gz`を使用できます。
diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md
index 48b7fe962941d..b7af834a089b6 100644
--- a/tiup/tiup-dm-topology-reference.md
+++ b/tiup/tiup-dm-topology-reference.md
@@ -3,7 +3,7 @@ title: Topology Configuration File for DM Cluster Deployment Using TiUP
summary: TiUPを使用して TiDB Data Migration (DM) クラスターをデプロイまたは拡張するには、クラスターのグローバル設定、サーバー設定、マスターサーバー、ワーカーサーバー、モニタリングサーバー、Grafana サーバー、および Alertmanager サーバーを記述するトポロジファイルが必要です。各セクションには、設定用の特定のフィールドが含まれています。トポロジファイルの構造は、global、server_configs、master_servers、worker_servers、monitoring_servers、grafana_servers、およびalertmanager_servers で構成されます。各セクションには、デプロイと設定のための独自の設定可能なフィールドセットがあります。
---
-# TiUPを使用した DMクラスタデプロイのトポロジコンフィグレーションファイル {#topology-configuration-file-for-dm-cluster-deployment-using-tiup}
+# TiUPを使用した DMクラスタデプロイのトポロジ設定ファイル {#topology-configuration-file-for-dm-cluster-deployment-using-tiup}
TiDB Data Migration (DM)クラスターをデプロイまたは拡張するには、クラスタートポロジを記述するトポロジファイル（ [サンプル](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml) ）を提供する必要があります。
@@ -11,7 +11,7 @@ TiDB Data Migration (DM)クラスターをデプロイまたは拡張するに
## ファイル構造 {#file-structure}
-TiUPを使用した DM クラスターのデプロイメントのトポロジ構成ファイルには、次のセクションが含まれる場合があります。
+TiUPを使用した DM クラスターのデプロイメントのトポロジ設定ファイルには、次のセクションが含まれる場合があります。
- [グローバル](#global) : クラスターのグローバル設定。一部の設定項目はクラスターのデフォルト値を使用しますが、インスタンスごとに個別に設定できます。
- [サーバー構成](#server_configs) : コンポーネントのグローバル設定。各コンポーネントを個別に設定できます。インスタンスに同じキーの設定項目がある場合、そのインスタンスの設定項目が有効になります。
@@ -65,8 +65,8 @@ global:
`server_configs`は、サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。`global`セクションと同様に、 `server_configs`セクションの設定は、インスタンス内の同じキーを持つ設定によって上書きできます。`server_configs`には主に以下のフィールドが含まれます。
-- `master` : DM-masterサービスに関連する設定。サポートされているすべての設定項目については、 [DM-masterコンフィグレーションファイル](/dm/dm-master-configuration-file.md)を参照してください。
-- `worker` : DM-workerサービスに関連する構成。サポートされているすべての設定項目については、 [DM-workerコンフィグレーションファイル](/dm/dm-worker-configuration-file.md)を参照してください。
+- `master` : DM-masterサービスに関連する設定。サポートされているすべての設定項目については、 [DM-master設定ファイル](/dm/dm-master-configuration-file.md)を参照してください。
+- `worker` : DM-workerサービスに関連する構成。サポートされているすべての設定項目については、 [DM-worker設定ファイル](/dm/dm-worker-configuration-file.md)を参照してください。
`server_configs`構成の例は次のとおりです。
@@ -98,7 +98,7 @@ server_configs:
- `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`os`値です。
- `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`arch`値になります。
- `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。
-- `v1_source_path` : v1.0.x からアップグレードする場合、このフィールドに V1 ソースの構成ファイルが配置されているディレクトリを指定できます。
+- `v1_source_path` : v1.0.x からアップグレードする場合、このフィールドに V1 ソースの設定ファイルが配置されているディレクトリを指定できます。
`master_servers`セクションでは、デプロイメントが完了した後は、次のフィールドを変更することはできません。
diff --git a/tso-configuration-file.md b/tso-configuration-file.md
index 407c724bfee18..aeeeb38efe6a7 100644
--- a/tso-configuration-file.md
+++ b/tso-configuration-file.md
@@ -1,9 +1,9 @@
---
title: TSO Configuration File
-summary: TSO 構成ファイルには、ノード名、データ パス、ノード URL などの複数の設定項目が含まれています。
+summary: TSO 設定ファイルには、ノード名、データ パス、ノード URL などの複数の設定項目が含まれています。
---
-# TSOコンフィグレーションファイル {#tso-configuration-file}
+# TSO設定ファイル {#tso-configuration-file}
@@ -58,7 +58,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために
## security {#security}
-セキュリティ関連のコンフィグレーション項目
+セキュリティ関連の設定項目
### `cacert-path` {#cacert-path}
@@ -83,7 +83,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために
## log {#log}
-ログに関するコンフィグレーション項目。
+ログに関する設定項目。
### `level` {#level}
@@ -104,7 +104,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために
## log.file {#log-file}
-ログファイルに関連するコンフィグレーション項目
+ログファイルに関連する設定項目
### `max-size` {#max-size}
@@ -127,7 +127,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために
## metric {#metric}
-監視に関連するコンフィグレーション項目
+監視に関連する設定項目
### `interval` {#interval}
diff --git a/two-data-centers-in-one-city-deployment.md b/two-data-centers-in-one-city-deployment.md
index fc15bac59398d..e09a926331e32 100644
--- a/two-data-centers-in-one-city-deployment.md
+++ b/two-data-centers-in-one-city-deployment.md
@@ -32,7 +32,7 @@ TiDBは通常、高可用性と災害復旧機能を確保するために、マ
- **async** : 非同期レプリケーションモード。このモードでは、ディザスタリカバリAZはプライマリAZと完全には同期されません。RaftアルゴリズムはRaftプロトコルに従ってログを複製します。
- **sync-recover** : 同期リカバリモード。このモードでは、ディザスタリカバリAZはプライマリAZと完全には同期されていません。Raftは徐々にラベルレプリケーションモードに切り替え、ラベル情報をPDに報告します。
-## コンフィグレーション {#configuration}
+## 設定 {#configuration}
### 例 {#example}
@@ -204,7 +204,7 @@ cat default.json
レプリケーションモードはPDによって制御されます。PD設定ファイルでレプリケーションモードを設定するには、以下のいずれかの方法を使用します。
-- 方法 1: PD 構成ファイルを構成し、クラスターをデプロイします。
+- 方法 1: PD 設定ファイルを構成し、クラスターをデプロイします。
```toml
[replication-mode]
diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md
index ca15de8820e26..758ebc212f528 100644
--- a/upgrade-tidb-using-tiup.md
+++ b/upgrade-tidb-using-tiup.md
@@ -132,7 +132,7 @@ tiup update cluster
これでオフラインミラーのアップグレードは正常に完了しました。上書き後にTiUP操作中にエラーが発生した場合は、 `manifest`が更新されていない可能性があります。TiUPを再度実行する前に、 `rm -rf ~/.tiup/manifests/*`を試してみてください。
-### ステップ3： TiUPトポロジー構成ファイルを編集する {#step-3-edit-tiup-topology-configuration-file}
+### ステップ3： TiUPトポロジー設定ファイルを編集する {#step-3-edit-tiup-topology-configuration-file}
> **Note:**
>
diff --git a/user-account-management.md b/user-account-management.md
index 664e016e958a3..17fad9223f288 100644
--- a/user-account-management.md
+++ b/user-account-management.md
@@ -174,7 +174,7 @@ TiDBはパスワードを[`mysql.user`](/mysql-schema/mysql-schema-user.md)シ
1. 設定ファイルを変更します。
1. tidb-server インスタンスの 1つが配置されているマシンにログインします。
- 2. TiDB ノードのデプロイメントディレクトリの下の`conf`ディレクトリに入り、 `tidb.toml`構成ファイルを見つけます。
+ 2. TiDB ノードのデプロイメントディレクトリの下の`conf`ディレクトリに入り、 `tidb.toml`設定ファイルを見つけます。
3. 設定ファイルの[`security`](/tidb-configuration-file.md#security)セクションに設定項目[`skip-grant-table`](/tidb-configuration-file.md)を追加します。`security`がない場合は、 `tidb.toml`設定ファイルの末尾に次の2行を追加します。
```
@@ -211,7 +211,7 @@ TiDBはパスワードを[`mysql.user`](/mysql-schema/mysql-schema-user.md)シ
mysql -h 127.0.0.1 -P 4000 -u root
```
-4. `run_tidb.sh`スクリプトの実行を停止し、手順 1 で TiDB 構成ファイルに追加された内容を削除し、tidb-server が自動的に起動するのを待ちます。
+4. `run_tidb.sh`スクリプトの実行を停止し、手順 1 で TiDB 設定ファイルに追加された内容を削除し、tidb-server が自動的に起動するのを待ちます。
## `FLUSH PRIVILEGES` {#flush-privileges}
diff --git a/tidb-cloud/data-service-app-config-files.md b/tidb-cloud/data-service-app-config-files.md
index 2107ac63e6c46..dd857fde13c49 100644
--- a/tidb-cloud/data-service-app-config-files.md
+++ b/tidb-cloud/data-service-app-config-files.md
@@ -1,13 +1,13 @@
---
title: Data App Configuration Files
-summary: このドキュメントでは、TiDB Cloudのデータアプリの構成ファイルについて説明します。
+summary: このドキュメントでは、TiDB Cloudのデータアプリの設定ファイルについて説明します。
---
-# データアプリコンフィグレーションファイル {#data-app-configuration-files}
+# データアプリ設定ファイル {#data-app-configuration-files}
-このドキュメントでは、TiDB Cloudの[データアプリ](/tidb-cloud/tidb-cloud-glossary.md#data-app)の構成ファイルについて説明します。
+このドキュメントでは、TiDB Cloudの[データアプリ](/tidb-cloud/tidb-cloud-glossary.md#data-app)の設定ファイルについて説明します。
-データ[データアプリをGitHubに接続しました](/tidb-cloud/data-service-manage-github-connection.md)た場合は、次のように GitHub の指定したディレクトリでデータアプリの構成ファイルを見つけることができます。
+[データアプリをGitHubに接続した](/tidb-cloud/data-service-manage-github-connection.md)場合は、次のように GitHub の指定したディレクトリでデータアプリの設定ファイルを見つけることができます。
```
├── - ユーザーレベル。
- セッションレベル (セッションごとにリソースグループを設定します)。
- ステートメントレベル (ステートメントごとにリソースグループを設定します)。