diff --git a/accelerated-table-creation.md b/accelerated-table-creation.md index fb8e219ff2cad..02f7f225081d0 100644 --- a/accelerated-table-creation.md +++ b/accelerated-table-creation.md @@ -19,7 +19,7 @@ TiDB v7.6.0 では、テーブル作成の高速化をサポートするシス テーブル作成時のパフォーマンス最適化は、 [`CREATE TABLE`](/sql-statements/sql-statement-create-table.md)文でのみ使用可能になりました。ただし、この文には外部キー制約を含めてはなりません。 -## テーブル作成を高速化するには、 `tidb_enable_fast_create_table`使用してください。 {#use-tidb-enable-fast-create-table-to-accelerate-table-creation} +## テーブル作成を高速化するには、 `tidb_enable_fast_create_table`を使用してください。 {#use-tidb-enable-fast-create-table-to-accelerate-table-creation} システム変数[`tidb_enable_fast_create_table`](/system-variables.md#tidb_enable_fast_create_table-new-in-v800)の値を指定することで、テーブル作成時のパフォーマンス最適化を有効または無効にすることができます。 diff --git a/ai/guides/auto-embedding.md b/ai/guides/auto-embedding.md index 9467186dbb4bb..573c7487e86e4 100644 --- a/ai/guides/auto-embedding.md +++ b/ai/guides/auto-embedding.md @@ -31,7 +31,7 @@ embed_func = EmbeddingFunction( テーブル スキーマにベクトル フィールドを作成するには、 `embed_func.VectorField()`を使用します。 -自動埋め込みを有効にするには、埋め込みたいフィールドに`source_field`設定します。 +自動埋め込みを有効にするには、埋め込みたいフィールドに`source_field`を設定します。 ```python hl_lines="7" from pytidb.schema import TableModel, Field diff --git a/ai/guides/vector-search.md b/ai/guides/vector-search.md index 8e455c6ce4130..097a6d13ea6af 100644 --- a/ai/guides/vector-search.md +++ b/ai/guides/vector-search.md @@ -372,7 +372,7 @@ LIMIT 10;
-事前フィルタリングを有効にするには、 `.filter()`方法で`prefilter=True`設定します。 +事前フィルタリングを有効にするには、 `.filter()`方法で`prefilter=True`を設定します。 **例: 事前フィルタリングによるベクトル検索** diff --git a/alert-rules.md b/alert-rules.md index 600d800468fc1..031b1aee49f76 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -659,7 +659,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 解決： 1. `warn`や`error`などの上位レベルのログの使用を検討してください。 - 2. `[raftstore]`構成の下に`raft-base-tick-interval = "2s"`追加します。 + 2. `[raftstore]`構成の下に`raft-base-tick-interval = "2s"`を追加します。 #### `TiKV_scheduler_context_total` {#tikv_scheduler_context_total} diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index 30eecf949e8c0..31f57fc6ac478 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -38,7 +38,7 @@ TiDBはオンラインDDLをサポートしています。つまり、データ TiDB DDLモジュールは、DDLオーナー（またはオーナー）の役割を導入します。これは、TiDBクラスタ内のすべてのDDL文を実行するプロキシとして機能します。現在の実装では、クラスタ全体から一度にオーナーとして選出できるTiDBノードは1つだけです。TiDBノードがオーナーとして選出されると、そのTiDBノードで起動されたワーカーがクラスタ内のDDLタスクを処理できるようになります。 -TiDBは、etcdの選出メカニズムを用いて、複数のTiDBノードからオーナーをホストするノードを選出します。デフォルトでは、各TiDBノードがオーナーとして選出される可能性があります（選出へのノードの参加を管理するには、 `run-ddl`設定します）。選出されたオーナーノードには任期があり、更新することで積極的に任期を維持します。オーナーノードがダウンした場合、etcdを介して別のノードが新しいオーナーとして選出され、クラスター内でDDLタスクの実行を継続できます。 +TiDBは、etcdの選出メカニズムを用いて、複数のTiDBノードからオーナーをホストするノードを選出します。デフォルトでは、各TiDBノードがオーナーとして選出される可能性があります（選出へのノードの参加を管理するには、 `run-ddl`を設定します）。選出されたオーナーノードには任期があり、更新することで積極的に任期を維持します。オーナーノードがダウンした場合、etcdを介して別のノードが新しいオーナーとして選出され、クラスター内でDDLタスクの実行を継続できます。 DDL 所有者の簡単な説明は次のとおりです。 diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index fe46f5e4ca2e9..298da4875cde2 100644 --- a/best-practices/index-management-best-practices.md +++ b/best-practices/index-management-best-practices.md @@ -100,7 +100,7 @@ DESC TIDB_INDEX_USAGE; - 非効率的なインデックス: - `PERCENTAGE_ACCESS_100`値が大きい場合は完全なインデックス スキャンが実行されることを意味し、インデックスが非効率的である可能性があります。 - - `ROWS_ACCESS_TOTAL`と`QUERY_TOTAL`比較して、インデックスが使用量に比べてスキャンする行数が多すぎるかどうかを判断します。 + - `ROWS_ACCESS_TOTAL`と`QUERY_TOTAL`を比較して、インデックスが使用量に比べてスキャンする行数が多すぎるかどうかを判断します。 `TIDB_INDEX_USAGE`システム テーブルを使用すると、インデックスのパフォーマンスに関する詳細な情報を取得できるため、不要なインデックスを削除し、クエリ実行を最適化することが容易になります。 diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 77229547f3558..0496c97ebd5ae 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -50,7 +50,7 @@ EXPLAIN FORMAT = "brief" SELECT * FROM listings WHERE price < 2000; +-----------------------------+---------+----------------------------------------------+---------------------------+ ``` -このフィルターはパフォーマンスを向上させますが、それでも大量の行が返される可能性があります。これは、より具体的な物件を探しているユーザーには理想的ではありません。都市、寝室数、最高価格などのフィルターを追加すると、結果が大幅に絞り込まれます。例えば、サンフランシスコで`$2,000`ベッドルーム以下の物件を検索するクエリの方が有用ですが、返される行数は数十行程度になる可能性が高いでしょう。 +このフィルターはパフォーマンスを向上させますが、それでも大量の行が返される可能性があります。これは、より具体的な物件を探しているユーザーには理想的ではありません。都市、寝室数、最高価格などのフィルターを追加すると、結果が大幅に絞り込まれます。例えば、San Franciscoでベッドルームが2つあり、価格が`$2,000`未満の物件を検索するクエリの方が有用ですが、返される行数は数十行程度になる可能性が高いでしょう。 このクエリを最適化するには、次のように`city` 、 `bedrooms` 、 `price`に複数列のインデックスを作成します。 @@ -68,24 +68,24 @@ SQLの複数列インデックスは辞書式順序で並べられます。`(cit 次の表は、複数列のインデックスによって検索結果がどのように絞り込まれるかを示すサンプル データセットを示しています。 -| 市 | 寝室 | 価格 | -| -------- | -- | ---- | -| サンディエゴ | 1 | 1000 | -| サンディエゴ | 1 | 1500 | -| サンディエゴ | 2 | 1000 | -| サンディエゴ | 2 | 2500 | -| サンディエゴ | 3 | 1000 | -| サンディエゴ | 3 | 2500 | -| サンフランシスコ | 1 | 1000 | -| サンフランシスコ | 1 | 1500 | -| サンフランシスコ | 2 | 1000 | -| サンフランシスコ | 2 | 1500 | -| サンフランシスコ | 3 | 2500 | -| サンフランシスコ | 3 | 3000 | +| City | Bedrooms | Price | +| ------------- | -------- | ----- | +| San Diego | 1 | 1000 | +| San Diego | 1 | 1500 | +| San Diego | 2 | 1000 | +| San Diego | 2 | 2500 | +| San Diego | 3 | 1000 | +| San Diego | 3 | 2500 | +| San Francisco | 1 | 1000 | +| San Francisco | 1 | 1500 | +| San Francisco | 2 | 1000 | +| San Francisco | 2 | 1500 | +| San Francisco | 3 | 2500 | +| San Francisco | 3 | 3000 | ## 最適化されたクエリと結果 {#optimized-queries-and-results} -マルチカラムインデックスを使用すると、TiDB はスキャン範囲を効率的に絞り込み、サンフランシスコでベッドルームが 2 つあり、価格が 2,000 ドル未満の物件を検索できます。 +マルチカラムインデックスを使用すると、TiDB はスキャン範囲を効率的に絞り込み、San Franciscoでベッドルームが 2 つあり、価格が 2,000 ドル未満の物件を検索できます。 ```sql -- Query 2: Find two-bedroom listings in San Francisco under $2,000 @@ -106,10 +106,10 @@ EXPLAIN FORMAT = "brief" このクエリは、サンプル データから次のフィルター処理された結果を返します。 -| 市 | 寝室 | 価格 | -| -------- | -- | ---- | -| サンフランシスコ | 2 | 1000 | -| サンフランシスコ | 2 | 1500 | +| City | Bedrooms | Price | +| ------------- | -------- | ----- | +| San Francisco | 2 | 1000 | +| San Francisco | 2 | 1500 | 複数列のインデックスを使用することで、TiDB は不要な行スキャンを回避し、クエリ パフォーマンスを大幅に向上させます。 @@ -133,7 +133,7 @@ TiDBオプティマイザには、強力な範囲導出コンポーネントが ### 例1: 重複する範囲 {#example-1-overlapping-ranges} -ニューヨークで、価格が 2 つの重複する範囲のいずれかに該当する 2 ベッドルームの物件を検索するクエリを考えてみましょう。 +New Yorkで、価格が 2 つの重複する範囲のいずれかに該当する 2 ベッドルームの物件を検索するクエリを考えてみましょう。 - 価格は`$1,000` ～ `$2,000` - 価格は`$1,500` ～ `$2,500` @@ -160,10 +160,10 @@ EXPLAIN FORMAT = "brief" ### 例2: 重複しない範囲 {#example-2-non-overlapping-ranges} -別のシナリオとして、サンフランシスコまたはサンディエゴで手頃な価格のシングルベッドルーム物件を検索するクエリを想像してみてください。ここでは、条件`OR`異なる都市の2つの異なる範囲を指定しています。 +別のシナリオとして、San FranciscoまたはSan Diegoで手頃な価格のシングルベッドルーム物件を検索するクエリを想像してみてください。ここでは、条件`OR`異なる都市の2つの異なる範囲を指定しています。 -- サンフランシスコの物件、1ベッドルーム、価格`$1,500` ～ `$2,500` -- サンディエゴの物件、1ベッドルーム、価格`$1,000` ～ `$1,500` +- San Franciscoの物件、1ベッドルーム、価格`$1,500` ～ `$2,500` +- San Diegoの物件、1ベッドルーム、価格`$1,000` ～ `$1,500` インデックス範囲は重複しないため、実行計画では個別のままとなり、各都市には独自のインデックス範囲が設定されます。 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 3a5fef18ac756..c4b49bbf34a50 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -214,7 +214,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー - オペレータが正常に生成されていても、スケジュール処理が遅い場合は、次のことが考えられます。 - スケジューリング速度は、負荷分散を目的としてデフォルトで制限されています。`leader-schedule-limit`または`region-schedule-limit`を大きくしても、通常のサービスに大きな影響はありません。また、 `max-pending-peer-count`および`max-snapshot-count`で指定された制限を適切に緩和することもできます。 - - 他のスケジューリングタスクが同時に実行されているため、バランシングの速度が低下しています。この場合、バランシングが他のスケジューリングタスクよりも優先される可能性がある場合は、他のタスクを停止するか、速度を制限することができます。例えば、バランシングの実行中に一部のノードをオフラインにすると、両方の操作でクォータ`region-schedule-limit`が消費されます。このような場合、スケジューラの速度を制限してノードを削除するか、 `enable-replace-offline-replica = false`設定して一時的に無効にすることができます。 + - 他のスケジューリングタスクが同時に実行されているため、バランシングの速度が低下しています。この場合、バランシングが他のスケジューリングタスクよりも優先される可能性がある場合は、他のタスクを停止するか、速度を制限することができます。例えば、バランシングの実行中に一部のノードをオフラインにすると、両方の操作でクォータ`region-schedule-limit`が消費されます。このような場合、スケジューラの速度を制限してノードを削除するか、 `enable-replace-offline-replica = false`を設定して一時的に無効にすることができます。 - スケジューリングプロセスが遅すぎます。原因を確認するには`RemovePeer` **Operator ステップの所要時間**メトリックを確認してください。通常、スナップショットの送受信を伴わないステップ（ `TransferLeader` `PromoteLearner` ）は数ミリ秒で完了するはずですが、スナップショットを伴うステップ（ `AddLearner` `AddPeer` ）は数十秒で完了すると予想されます。所要時間が明らかに長すぎる場合は、TiKV の負荷が高いか、ネットワークのボトルネックが発生している可能性があります。具体的な分析が必要です。 - PDは対応するバランシングスケジューラを生成できません。考えられる原因は次のとおりです。 diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index 6da8e35ae5584..c96f1d17a71b1 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -81,7 +81,7 @@ TiDB は、SQL 構造を Key-Value 構造に自動的にマッピングします ### セカンダリインデックス {#secondary-index} -TiDB は、[グローバルインデックス](/global-indexes.md)インデックスでもある完全なセカンダリインデックスをサポートしています。多くのクエリはインデックスによって最適化できます。したがって、アプリケーションではセカンダリ インデックスを有効に活用することが重要です。 +TiDB は、[グローバルインデックス](/global-indexes.md)でもある完全なセカンダリインデックスをサポートしています。多くのクエリはインデックスによって最適化できます。したがって、アプリケーションではセカンダリ インデックスを有効に活用することが重要です。 MySQLで培った多くの経験は、TiDBにも応用できます。ただし、TiDBには独自の機能があることに留意してください。以下は、TiDBでセカンダリインデックスを使用する際の注意点です。 diff --git a/br/br-incremental-guide.md b/br/br-incremental-guide.md index 2c0595c6f67d4..753c286818f15 100644 --- a/br/br-incremental-guide.md +++ b/br/br-incremental-guide.md @@ -21,7 +21,7 @@ TiDBクラスターの増分データは、期間の開始スナップショッ - デフォルト値`true`ままにしておくと、増分リストアを開始する前に、再生が必要なDDLが厳密にチェックされます。このモードでは、 `ADD INDEX` 、 `MODIFY COLUMN` 、 `REORG PARTITION`まだサポートされていません。増分バックアップとログバックアップを併用する場合は、増分バックアッププロセス中に、前述のDDLが存在しないことを確認してください。そうでない場合、これら3つのDDLを正しく再生できません。 -- リカバリプロセス全体でログ バックアップなしで増分復元を使用する場合は、 `--allow-pitr-from-incremental`から`false`設定して増分リカバリ フェーズでのチェックをスキップできます。 +- リカバリプロセス全体でログ バックアップなしで増分復元を使用する場合は、 `--allow-pitr-from-incremental`を`false`に設定して増分リカバリ フェーズでのチェックをスキップできます。 ## 増分データをバックアップする {#back-up-incremental-data} diff --git a/check-before-deployment.md b/check-before-deployment.md index c5b46cb4c860a..dad3b62ff79ca 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -734,7 +734,7 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t passwd tidb ``` -2. パスワードなしで sudo を設定するには、次のコマンドを実行し、ファイルの末尾に`tidb ALL=(ALL) NOPASSWD: ALL`追加します。 +2. パスワードなしで sudo を設定するには、次のコマンドを実行し、ファイルの末尾に`tidb ALL=(ALL) NOPASSWD: ALL`を追加します。 ```bash visudo diff --git a/clinic/clinic-user-guide-for-tiup.md b/clinic/clinic-user-guide-for-tiup.md index c8b4c16044465..c27178ea47868 100644 --- a/clinic/clinic-user-guide-for-tiup.md +++ b/clinic/clinic-user-guide-for-tiup.md @@ -85,19 +85,19 @@ PingCAP Clinicを使用する前に、Diag（ PingCAP Clinicが提供するデ tiup diag config clinic.token ${token-value} ``` -3. Diag に`region`設定します。 +3. Diag に`region`を設定します。 - `region` 、データの圧縮に使用する暗号化証明書と、データのアップロード時に使用する対象サービスを決定します。例: + `region`は、データの圧縮に使用する暗号化証明書と、データのアップロード時に使用する対象サービスを決定します。例: > **Note:** > - > - Diag v0.9.0 以降のバージョンでは設定`region`サポートされます。 - > - Diag v0.9.0より前のバージョンでは、データはデフォルトで中国リージョンのClinic Serverにアップロードされます。これらのバージョンで`region`設定するには、 `tiup update diag`コマンドを実行してDiagを最新バージョンにアップグレードし、その後Diagで`region`設定してください。 + > - Diag v0.9.0 以降のバージョンでは`region`の設定がサポートされます。 + > - Diag v0.9.0より前のバージョンでは、データはデフォルトで中国リージョンのClinic Serverにアップロードされます。これらのバージョンで`region`を設定するには、 `tiup update diag`コマンドを実行してDiagを最新バージョンにアップグレードし、その後Diagで`region`を設定してください。
- 国際ユーザー向けに Clinic Server を使用する場合は、次のコマンドを使用して`region`を`US`設定します。 + 国際ユーザー向けに Clinic Server を使用する場合は、次のコマンドを使用して`region`を`US`に設定します。 ```bash tiup diag config clinic.region US @@ -106,7 +106,7 @@ PingCAP Clinicを使用する前に、Diag（ PingCAP Clinicが提供するデ
- 中国本土のユーザー向けに Clinic Server を使用する場合は、次のコマンドを使用して`region`を`CN`設定します。 + 中国本土のユーザー向けに Clinic Server を使用する場合は、次のコマンドを使用して`region`を`CN`に設定します。 ```bash tiup diag config clinic.region CN @@ -199,7 +199,7 @@ Diag を使用すると、 TiUPを使用して展開された TiDB クラスタ Do you want to continue? [y/N]: (default=N) ``` -2. データの収集を開始することを確認するには、 `Y`入力します。 +2. データの収集を開始することを確認するには、 `Y`を入力します。 データの収集には一定の時間がかかります。収集するデータの量によって時間は異なります。例えば、テスト環境では1GBのデータの収集に約10分かかります。 diff --git a/clinic/quick-start-with-clinic.md b/clinic/quick-start-with-clinic.md index 8006415bbe41c..49b5a9c8786e3 100644 --- a/clinic/quick-start-with-clinic.md +++ b/clinic/quick-start-with-clinic.md @@ -58,7 +58,7 @@ PingCAP Clinicを使用する前に、Diag をインストールし、データ > - データセキュリティのため、TiDBはトークン作成時にのみトークン情報を表示します。トークン情報を紛失した場合は、古いトークンを削除して新しいトークンを作成できます。 > - トークンはデータのアップロードにのみ使用されます。 -5. Diag にトークンと`region`設定します。 +5. Diag にトークンと`region`を設定します。 - `clinic.token`設定するには、次のコマンドを実行します。 @@ -66,19 +66,19 @@ PingCAP Clinicを使用する前に、Diag をインストールし、データ tiup diag config clinic.token ${token-value} ``` - - `clinic.region`設定するには、次のコマンドを実行します。 + - `clinic.region`を設定するには、次のコマンドを実行します。 - `region` 、データの圧縮に使用する暗号化証明書と、データのアップロード時に使用する対象サービスを決定します。例: + `region`は、データの圧縮に使用する暗号化証明書と、データのアップロード時に使用する対象サービスを決定します。例: > **Note:** > - > - Diag v0.9.0 以降のバージョンでは設定`region`サポートされます。 - > - Diag v0.9.0より前のバージョンでは、データはデフォルトで中国リージョンのClinic Serverにアップロードされます。これらのバージョンで`region`設定するには、 `tiup update diag`コマンドを実行してDiagを最新バージョンにアップグレードし、その後Diagで`region`設定してください。 + > - Diag v0.9.0 以降のバージョンでは`region`の設定がサポートされます。 + > - Diag v0.9.0より前のバージョンでは、データはデフォルトで中国リージョンのClinic Serverにアップロードされます。これらのバージョンで`region`を設定するには、 `tiup update diag`コマンドを実行してDiagを最新バージョンにアップグレードし、その後Diagで`region`を設定してください。
- 国際ユーザー向けに Clinic Server を使用する場合は、次のコマンドを使用して`region`を`US`設定します。 + 国際ユーザー向けに Clinic Server を使用する場合は、次のコマンドを使用して`region`を`US`に設定します。 ```bash tiup diag config clinic.region US @@ -87,7 +87,7 @@ PingCAP Clinicを使用する前に、Diag をインストールし、データ
- 中国本土のユーザー向けに Clinic Server を使用する場合は、次のコマンドを使用して`region`を`CN`設定します。 + 中国本土のユーザー向けに Clinic Server を使用する場合は、次のコマンドを使用して`region`を`CN`に設定します。 ```bash tiup diag config clinic.region CN diff --git a/cost-model.md b/cost-model.md index cd357b8e459ec..c5b6a1c4373bc 100644 --- a/cost-model.md +++ b/cost-model.md @@ -34,7 +34,7 @@ mysql> SHOW CREATE TABLE t; - インデックス`b`のコスト = 行数`b < 100` * インデックス`b`の長さ = 20 * 8 = 160 - インデックス`c`のコスト = 行数`c < 100` * インデックス`c`の長さ = 500 * 8 = 4000 -インデックス`b`のコストが低いため、TiDB はインデックスとして`b`選択します。 +インデックス`b`のコストが低いため、TiDB はインデックスとして`b`を選択します。 上記の例は簡略化されており、基本原理を説明するためにのみ使用されています。実際のSQL実行では、TiDBのコストモデルはより複雑になります。 diff --git a/dashboard/dashboard-session-sso.md b/dashboard/dashboard-session-sso.md index 4f940a2104a0d..b084f0c022444 100644 --- a/dashboard/dashboard-session-sso.md +++ b/dashboard/dashboard-session-sso.md @@ -198,7 +198,7 @@ Oktaと同様に、 [オーソ0](https://auth0.com/)もOIDC SSOアイデンテ 1. Auth0 の**[設定]**タブの**基本情報**にある**クライアント ID**を、TiDB Dashboardの**OIDC クライアント ID**に入力します。 -2. **OIDC検出URL**に、**ドメイン**フィールドの値の先頭に`https://` 、末尾に`/`入力します（例： `https://example.us.auth0.com/` ）。認証を完了し、設定を保存します。 +2. **OIDC検出URL**に、**ドメイン**フィールドの値の先頭に`https://` 、末尾に`/`を入力します（例： `https://example.us.auth0.com/` ）。認証を完了し、設定を保存します。 ![Settings](/media/dashboard/dashboard-session-sso-auth0-settings-3.png) @@ -236,7 +236,7 @@ Oktaと同様に、 [オーソ0](https://auth0.com/)もOIDC SSOアイデンテ 1. 前の手順で保存した**クライアント ID**を TiDB Dashboardの**OIDC クライアント ID**に入力します。 -2. **OIDC検出URL**に、**ドメイン**フィールドの値の先頭に`https://` 、末尾に`/`入力します（例： `https://casdoor.example.com/` ）。認証を完了し、設定を保存します。 +2. **OIDC検出URL**に、**ドメイン**フィールドの値の先頭に`https://` 、末尾に`/`を入力します（例： `https://casdoor.example.com/` ）。認証を完了し、設定を保存します。 ![Settings](/media/dashboard/dashboard-session-sso-casdoor-settings-3.png) diff --git a/develop/dev-guide-schema-design-overview.md b/develop/dev-guide-schema-design-overview.md index eb2e814dbfdc4..95d393f9e2b4d 100644 --- a/develop/dev-guide-schema-design-overview.md +++ b/develop/dev-guide-schema-design-overview.md @@ -44,7 +44,7 @@ TiDBには`test`という名前のデフォルトデータベースが付属し > TiDBでは、**主キー**のデフォルト定義は[InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html) （MySQLの一般的なストレージエンジン）とは異なります。 > > - InnoDBでは、**主キー**の定義は一意であり、nullではなく、**クラスター化されたインデックス**です。 -> - TiDB では、**プライマリ キー**の定義は一意であり、NULL ではありません。ただし、プライマリ キーが**クラスター化インデックス**であるとは限りません。プライマリ キーがクラスター化インデックスであるかどうかを指定するには、 `CLUSTERED`ステートメントの`NONCLUSTERED`の後に、予約されていないキーワード`PRIMARY KEY`または`CREATE TABLE`追加します。ステートメントでこれらのキーワードが明示的に指定されていない場合、デフォルトの動作はシステム変数`@@global.tidb_enable_clustered_index`によって制御されます。詳細については、[クラスター化インデックス](/clustered-indexes.md)を参照してください。 +> - TiDB では、**プライマリ キー**の定義は一意であり、NULL ではありません。ただし、プライマリ キーが**クラスター化インデックス**であるとは限りません。プライマリ キーがクラスター化インデックスであるかどうかを指定するには、`CREATE TABLE`ステートメントの`PRIMARY KEY`の後に、予約されていないキーワード`CLUSTERED`または`NONCLUSTERED`を追加します。ステートメントでこれらのキーワードが明示的に指定されていない場合、デフォルトの動作はシステム変数`@@global.tidb_enable_clustered_index`によって制御されます。詳細については、[クラスター化インデックス](/clustered-indexes.md)を参照してください。 #### 専門索引 {#specialized-indexes} diff --git a/dm/dm-online-ddl-tool-support.md b/dm/dm-online-ddl-tool-support.md index ea74b9040869f..b309acedbed84 100644 --- a/dm/dm-online-ddl-tool-support.md +++ b/dm/dm-online-ddl-tool-support.md @@ -23,7 +23,7 @@ MySQLエコシステムでは、gh-ostやpt-oscなどのツールが広く使用 v2.0.5 以降のバージョンでは、 `task`構成ファイル内の`online-ddl`構成項目を使用する必要があります。 -- アップストリーム MySQL/MariaDB (同時に) が gh-ost または pt-osc ツールを使用する場合は、タスク構成ファイルで`online-ddl`から`true`設定します。 +- アップストリーム MySQL/MariaDB (同時に) が gh-ost または pt-osc ツールを使用する場合は、タスク構成ファイルで`online-ddl`に`true`を設定します。 ```yml online-ddl: true diff --git a/dr-multi-replica.md b/dr-multi-replica.md index 12b641e5120f8..538fa3302729a 100644 --- a/dr-multi-replica.md +++ b/dr-multi-replica.md @@ -90,7 +90,7 @@ summary: 単一クラスターのマルチレプリカ災害復旧ソリュー 上記の構成では、次のオプションを使用して、リージョン間 DR を最適化します。 - `server.grpc-compression-type: gzip`設定すると、TiKV での gRPC メッセージ圧縮が有効になり、ネットワーク トラフィックが削減されます。 - - `raftstore.raft-min-election-timeout-ticks`と`raftstore.raft-max-election-timeout-ticks`設定して、リージョン 3 が選挙に参加するまでの時間を延長し、このリージョン内のレプリカがリーダーとして投票されるのを防ぎます。 + - `raftstore.raft-min-election-timeout-ticks`と`raftstore.raft-max-election-timeout-ticks`を設定して、リージョン 3 が選挙に参加するまでの時間を延長し、このリージョン内のレプリカがリーダーとして投票されるのを防ぎます。 2. 上記の構成ファイルを使用してクラスターを作成します。 diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index ef77f6a464117..fd1734df01582 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -381,7 +381,7 @@ TiDBのプライマリクラスタとセカンダリクラスタを再構築す 変更フィードを作成する際に、変更フィード設定ファイルで同期ポイント機能を有効にします。すると、変更フィードは定期的に（ `sync-point-interval`タイミングで）、セカンダリクラスタ上で`SET GLOBAL tidb_external_ts = @@tidb_current_ts`を実行することにより、セカンダリクラスタに複製された一貫性のあるスナップショットポイントを設定します。 -セカンダリクラスタからデータを照会するには、ビジネスアプリケーションで`SET GLOBAL|SESSION tidb_enable_external_ts_read = ON;`設定します。そうすることで、プライマリクラスタとトランザクション的に整合性のあるデータを取得できます。 +セカンダリクラスタからデータを照会するには、ビジネスアプリケーションで`SET GLOBAL|SESSION tidb_enable_external_ts_read = ON;`を設定します。そうすることで、プライマリクラスタとトランザクション的に整合性のあるデータを取得できます。 ```toml # Starting from v6.4.0, only the changefeed with the SYSTEM_VARIABLES_ADMIN or SUPER privilege can use the TiCDC Syncpoint feature. diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md index 18ab17fb5982c..5befb225fec34 100644 --- a/faq/backup-and-restore-faq.md +++ b/faq/backup-and-restore-faq.md @@ -267,7 +267,7 @@ br restore full -f '*.*' -f '!mysql.*' -f 'mysql.usertable' -s $external_storage br restore full -f 'mysql.usertable' -s $external_storage_url --with-sys-table ``` -[テーブルフィルター](/table-filter.md#syntax)設定しても、 **BR は次のシステム テーブルを復元しないこと**に注意してください。 +[テーブルフィルター](/table-filter.md#syntax)を設定しても、 **BR は次のシステム テーブルを復元しないこと**に注意してください。 - 統計表（ `mysql.stat_*` ）。ただし、統計は復元可能です。[統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)を参照してください。 - システム変数テーブル（ `mysql.tidb` `mysql.global_variables` diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 8bad1875b9a57..267d3fbc2d6e7 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -59,7 +59,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ ### TiDB クラスターを初めてデプロイしたときに TiKV の`label`が構成されていなかった場合、 `label`構成を追加するにはどうすればよいですか? {#how-to-add-the-label-configuration-if-label-of-tikv-was-not-configured-when-i-deployed-the-tidb-cluster-for-the-first-time} -TiDB `label`の設定は、クラスタのデプロイメントアーキテクチャに関連しています。これは重要であり、PDがグローバル管理とスケジューリングを実行するための基盤となります。以前のクラスタのデプロイメント時に`label`設定していない場合は、PD管理ツール`pd-ctl`を使用して`location-labels`情報を手動で追加し、デプロイメント構造を調整する必要があります（例： `config set location-labels "zone,rack,host"` ）。（実際の`label`レベル名に基づいて設定する必要があります）。 +TiDB `label`の設定は、クラスタのデプロイメントアーキテクチャに関連しています。これは重要であり、PDがグローバル管理とスケジューリングを実行するための基盤となります。以前のクラスタのデプロイメント時に`label`を設定していない場合は、PD管理ツール`pd-ctl`を使用して`location-labels`情報を手動で追加し、デプロイメント構造を調整する必要があります（例： `config set location-labels "zone,rack,host"` ）。（実際の`label`レベル名に基づいて設定する必要があります）。 `pd-ctl`の使い方については[PD Controlユーザー ガイド](/pd-control.md)を参照してください。 diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md index 60d3bf97de486..4415db59fb221 100644 --- a/faq/migration-tidb-faq.md +++ b/faq/migration-tidb-faq.md @@ -67,7 +67,7 @@ iperf Done. ### 誤ってMySQLユーザーテーブルをTiDBにインポートしてしまった場合、またはパスワードを忘れてログインできない場合は、どのように対処すればよいですか? {#if-i-accidentally-import-the-mysql-user-table-into-tidb-or-forget-the-password-and-cannot-log-in-how-to-deal-with-it} -TiDBサービスを再起動し、設定ファイルにパラメータ`-skip-grant-table=true`追加します。パスワードなしでクラスターにログインし、ユーザーを再作成するか、テーブル`mysql.user`を再作成してください。具体的なテーブルスキーマについては、公式ドキュメントを参照してください。 +TiDBサービスを再起動し、設定ファイルにパラメータ`-skip-grant-table=true`を追加します。パスワードなしでクラスターにログインし、ユーザーを再作成するか、テーブル`mysql.user`を再作成してください。具体的なテーブルスキーマについては、公式ドキュメントを参照してください。 ### TiDB のデータをエクスポートするにはどうすればいいですか? {#how-to-export-the-data-in-tidb} @@ -142,7 +142,7 @@ Sqoopでは、 `--batch`各バッチで100個の`statement`文をコミットす 基盤となるストレージエンジンの制限により、TiDB の各キーと値のエントリ（1行）は 6MB 以下にする必要があります。[`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)設定値は最大 120MB まで調整できます。 -分散トランザクションは2相コミットを必要とし、最下層でRaftレプリケーションを実行します。トランザクションが非常に大きい場合、コミットプロセスは非常に遅くなり、書き込み競合が発生する可能性が高くなります。さらに、失敗したトランザクションのロールバックは、不要なパフォーマンスの低下につながります。これらの問題を回避するため、デフォルトでは、トランザクション内のキーと値のエントリの合計サイズを100MB以下に制限しています。より大きなトランザクションが必要な場合は、TiDB設定ファイルの値`txn-total-size-limit`変更してください。この設定項目の最大値は10GBです。実際の制限は、マシンの物理メモリにも影響されます。 +分散トランザクションは2相コミットを必要とし、最下層でRaftレプリケーションを実行します。トランザクションが非常に大きい場合、コミットプロセスは非常に遅くなり、書き込み競合が発生する可能性が高くなります。さらに、失敗したトランザクションのロールバックは、不要なパフォーマンスの低下につながります。これらの問題を回避するため、デフォルトでは、トランザクション内のキーと値のエントリの合計サイズを100MB以下に制限しています。より大きなトランザクションが必要な場合は、TiDB設定ファイルの値`txn-total-size-limit`を変更してください。この設定項目の最大値は10GBです。実際の制限は、マシンの物理メモリにも影響されます。 Google Cloud Spanner には[同様の制限](https://cloud.google.com/spanner/docs/limits)あります。 diff --git a/faq/upgrade-faq.md b/faq/upgrade-faq.md index 934a567157d74..34d7947358c05 100644 --- a/faq/upgrade-faq.md +++ b/faq/upgrade-faq.md @@ -37,7 +37,7 @@ TiDBサービスにローリングアップデートを適用すると、実行 ### TiDBのアップグレード後にJDBC接続の照合順序が変更される {#the-collation-in-jdbc-connections-changes-after-upgrading-tidb} -以前のバージョンからv7.4以降にアップグレードする際、JDBC URLで`connectionCollation`が設定されておらず、かつ`characterEncoding`が設定されていないか`UTF-8`に設定されている場合、アップグレード後にJDBC接続のデフォルトの照合順序が`utf8mb4_bin`から`utf8mb4_0900_ai_ci`に変更される可能性があります。照合順序を`utf8mb4_bin`に維持する必要がある場合は、JDBC URLで`connectionCollation=utf8mb4_bin`設定してください。 +以前のバージョンからv7.4以降にアップグレードする際、JDBC URLで`connectionCollation`が設定されておらず、かつ`characterEncoding`が設定されていないか`UTF-8`に設定されている場合、アップグレード後にJDBC接続のデフォルトの照合順序が`utf8mb4_bin`から`utf8mb4_0900_ai_ci`に変更される可能性があります。照合順序を`utf8mb4_bin`に維持する必要がある場合は、JDBC URLで`connectionCollation=utf8mb4_bin`を設定してください。 詳細については[JDBC接続で使用される照合順序](/faq/sql-faq.md#collation-used-in-jdbc-connections)を参照してください。 @@ -283,7 +283,7 @@ TiDB v2.1.1以前のバージョンでは、文字セットがUTF-8の場合、 具体的には、変数`tidb_skip_utf8_check`を使用すると、データのUTF-8およびUTF8MB4の有効性チェックをスキップできます。ただし、チェックをスキップしても、MySQL側ではチェックが実行されるため、TiDBからMySQLへのデータのレプリケーションに失敗する可能性があります。 - UTF-8チェックのみをスキップしたい場合は、 `tidb_check_mb4_value_in_utf8`設定できます。この変数はv2.1.3で`config.toml`ファイルに追加され、設定ファイルの`check-mb4-value-in-utf8`変更してクラスターを再起動することで有効になります。 + UTF-8チェックのみをスキップしたい場合は、`tidb_check_mb4_value_in_utf8`を設定できます。この変数はv2.1.3で`config.toml`ファイルに追加され、設定ファイルの`check-mb4-value-in-utf8`を変更してクラスターを再起動することで有効になります。 v2.1.5 以降では、HTTP API とセッション変数を通じて`tidb_check_mb4_value_in_utf8`設定できます。 diff --git a/hybrid-deployment-topology.md b/hybrid-deployment-topology.md index f9c8c1c3a43a8..6d281d6d142c8 100644 --- a/hybrid-deployment-topology.md +++ b/hybrid-deployment-topology.md @@ -17,7 +17,7 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて | :------------- | :--- | :-------------------------- | :----------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | 6 | 32 VCore 64GB | 10.0.1.1
10.0.1.2
10.0.1.3 | CPUコアをバインドするためにNUMAを構成する | | PD | 3 | 16 VCore 32 GB | 10.0.1.4
10.0.1.5
10.0.1.6 | `location_labels`パラメータを設定する | -| TiKV | 6 | 32 VCore 64GB | 10.0.1.7
10.0.1.8
10.0.1.9 |
  • インスタンス レベルのポートと status_port を分離します。
    2. グローバルパラメータ`readpool` `storage`設定します`raftstore`
    3. インスタンス レベルのホストのラベルを構成します。
    4. CPUコアをバインドするためのNUMAを構成する
    • | +| TiKV | 6 | 32 VCore 64GB | 10.0.1.7
    10.0.1.8
    10.0.1.9 |
  • 1. インスタンス レベルのポートと status_port を分離します。
    2. グローバルパラメータ `readpool`、`storage`、`raftstore`を設定します。
    3. インスタンス レベルのホストのラベルを構成します。
    4. CPUコアをバインドするためのNUMAを構成する
    • | | モニタリングとGrafana | 1 | 4 VCore 8GB * 1 500GB (SSD) | 10.0.1.10 | デフォルト設定 | > **Note:** @@ -39,7 +39,7 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて - `readpool`スレッドプールに自己適応するように設定します。`readpool.unified.max-thread-count`パラメータを設定することで、 `readpool.storage`と`readpool.coprocessor`が統合スレッドプールを共有し、それぞれ自己適応スイッチを設定できます。 - - `readpool.storage`と`readpool.coprocessor`有効にする: + - `readpool.storage`と`readpool.coprocessor`を有効にする: ```yaml readpool.storage.use-unified-pool: true diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index fffe2522ad80e..acf14bdce3db8 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -68,7 +68,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `1000` - 可能な値: `[0, 2147483647]` -- この変数は、オプティマイザがアクセスパスを選択する際のヒューリスティック戦略の閾値を設定します。あるアクセスパスの推定行数（例えば`Index_A` ）が他のアクセスパスの推定行数（デフォルトでは`1000`倍）よりも大幅に少ない場合、オプティマイザはコスト比較をスキップし、直接`Index_A`選択します。 +- この変数は、オプティマイザがアクセスパスを選択する際のヒューリスティック戦略の閾値を設定します。あるアクセスパスの推定行数（例えば`Index_A` ）が他のアクセスパスの推定行数（デフォルトでは`1000`倍）よりも大幅に少ない場合、オプティマイザはコスト比較をスキップし、直接`Index_A`を選択します。 - `0` 、このヒューリスティック戦略を無効にすることを意味します。 ### `45798`バージョン7.5.0の新機能 {#45798-new-in-v750} diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md index f35abde48ac73..5fe09bc900a68 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -546,8 +546,8 @@ v5.4.0 では、gPRC モジュールが最適化され、 Raftログのレプリ スレッド`Store`の場合、 `Commit Log Duration`は`Apply Log Duration`よりも明らかに高い値です。一方、 `Append Log Duration`は`Apply Log Duration`よりも大幅に高い値であり、スレッド`Store`はCPUとI/Oの両方でボトルネックが発生している可能性があることを示しています。`Commit Log Duration`と`Append Log Duration`を削減する方法としては、以下のものが考えられます。 - TiKV CPU リソースが十分な場合は、 `raftstore.store-pool-size`の値を増やして`Store`スレッドを追加することを検討してください。 -- TiDBがv5.4.0以降の場合は、 `raft-engine.enable: true`設定して[`Raft Engine`](/tikv-configuration-file.md#raft-engine)有効にすることを検討してください。RaftRaft Engineは軽量な実行パスを備えています。これにより、I/O書き込みの削減と、一部のシナリオにおける書き込みのロングテールレイテンシーの削減に役立ちます。 -- TiKV CPU リソースが十分で、TiDB が v5.3.0 以降の場合は、 `raftstore.store-io-pool-size: 1`設定して[`StoreWriter`](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)有効にすることを検討してください。 +- TiDBがv5.4.0以降の場合は、 `raft-engine.enable: true`を設定して[`Raft Engine`](/tikv-configuration-file.md#raft-engine)を有効にすることを検討してください。Raft Engineは軽量な実行パスを備えています。これにより、I/O書き込みの削減と、一部のシナリオにおける書き込みのロングテールレイテンシーの削減に役立ちます。 +- TiKV CPU リソースが十分で、TiDB が v5.3.0 以降の場合は、 `raftstore.store-io-pool-size: 1`を設定して[`StoreWriter`](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)有効にすることを検討してください。 ## TiDB のバージョンが v6.1.0 より前の場合、パフォーマンス概要ダッシュボードを使用するにはどうすればよいですか? {#if-my-tidb-version-is-earlier-than-v6-1-0-what-should-i-do-to-use-the-performance-overview-dashboard} diff --git a/releases/release-2.1-beta.md b/releases/release-2.1-beta.md index 4b58fb00ab445..d74de61a8f2d0 100644 --- a/releases/release-2.1-beta.md +++ b/releases/release-2.1-beta.md @@ -36,7 +36,7 @@ summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイ - DML - `INSERT INTO SELECT`文目のメモリ使用量を減らす - `PlanCache`のパフォーマンス問題を修正 - - トランザクションの自動再試行回数を制御するためのシステム変数`tidb_retry_limit`追加します + - トランザクションの自動再試行回数を制御するためのシステム変数`tidb_retry_limit`を追加します - トランザクションが自動的に試行されるかどうかを制御する`tidb_disable_txn_auto_retry`システム変数を追加します。 - `time`タイプの書き込まれたデータの精度の問題を修正 - 競合トランザクションのパフォーマンスを最適化するために、ローカルで競合したトランザクションのキューをサポートします。 diff --git a/releases/release-2.1-ga.md b/releases/release-2.1-ga.md index 8301d469537e2..671a2fd193c3d 100644 --- a/releases/release-2.1-ga.md +++ b/releases/release-2.1-ga.md @@ -169,13 +169,13 @@ summary: TiDB 2.1 GA は 2018 年 11 月 30 日にリリースされ、安定性 - APIと操作ツール - - `TiDB reverse scan`機能をサポートするには[`GetPrevRegion`インターフェース](https://github.com/pingcap/kvproto/blob/8e3f33ac49297d7c93b61a955531191084a2f685/proto/pdpb.proto#L40)追加します + - `TiDB reverse scan`機能をサポートするには[`GetPrevRegion`インターフェース](https://github.com/pingcap/kvproto/blob/8e3f33ac49297d7c93b61a955531191084a2f685/proto/pdpb.proto#L40)を追加します - - [`BatchSplitRegion`インターフェース](https://github.com/pingcap/kvproto/blob/8e3f33ac49297d7c93b61a955531191084a2f685/proto/pdpb.proto#L54)追加すると TiKVリージョン分割が高速化されます + - [`BatchSplitRegion`インターフェース](https://github.com/pingcap/kvproto/blob/8e3f33ac49297d7c93b61a955531191084a2f685/proto/pdpb.proto#L54)を追加すると TiKVリージョン分割が高速化されます - - TiDBで分散GCをサポートするには[`GCSafePoint`インターフェース](https://github.com/pingcap/kvproto/blob/8e3f33ac49297d7c93b61a955531191084a2f685/proto/pdpb.proto#L64-L66)追加します + - TiDBで分散GCをサポートするには[`GCSafePoint`インターフェース](https://github.com/pingcap/kvproto/blob/8e3f33ac49297d7c93b61a955531191084a2f685/proto/pdpb.proto#L64-L66)を追加します - - TiDBで分散GCをサポートするには、 [`GetAllStores`インターフェース](https://github.com/pingcap/kvproto/blob/8e3f33ac49297d7c93b61a955531191084a2f685/proto/pdpb.proto#L32)追加します。 + - TiDBで分散GCをサポートするには、 [`GetAllStores`インターフェース](https://github.com/pingcap/kvproto/blob/8e3f33ac49297d7c93b61a955531191084a2f685/proto/pdpb.proto#L32)を追加します。 diff --git a/releases/release-2.1-rc.3.md b/releases/release-2.1-rc.3.md index ea127562f9e2c..284bbf393e551 100644 --- a/releases/release-2.1-rc.3.md +++ b/releases/release-2.1-rc.3.md @@ -22,7 +22,7 @@ summary: TiDB 2.1 RC3は2018年9月29日にリリースされ、安定性、互 - ポイントクエリですべての NULL 値が取得される列によって発生する「インデックス範囲外」panicを修正[＃7790](https://github.com/pingcap/tidb/pull/7790) - サーバ - 設定ファイル内のメモリクォータが有効にならない問題を修正[＃7729](https://github.com/pingcap/tidb/pull/7729) - - 各ステートメント実行優先度を設定するためのシステム変数`tidb_force_priority`追加します。 [＃7694](https://github.com/pingcap/tidb/pull/7694) + - 各ステートメントの実行優先度を設定するためのシステム変数`tidb_force_priority`を追加します。 [＃7694](https://github.com/pingcap/tidb/pull/7694) - `admin show slow`文を使用してスロークエリログを取得することをサポートします [＃7785](https://github.com/pingcap/tidb/pull/7785) - 互換性 - `information_schema.schemata` で`charset/collation`の結果が正しくない問題を修正 [＃7751](https://github.com/pingcap/tidb/pull/7751) diff --git a/releases/release-2.1.15.md b/releases/release-2.1.15.md index 8ce98e212f431..45a41b632c3c3 100644 --- a/releases/release-2.1.15.md +++ b/releases/release-2.1.15.md @@ -49,4 +49,4 @@ TiDB Lightning ## TiDB Ansible {#tidb-ansible} -- TiDB Dashboardに監視項目`parse duration`と`compile duration`追加して、SQL文の解析とコンパイルの実行にかかる時間を監視します[＃815](https://github.com/pingcap/tidb-ansible/pull/815) +- TiDB Dashboardに監視項目`parse duration`と`compile duration`を追加して、SQL文の解析とコンパイルの実行にかかる時間を監視します[＃815](https://github.com/pingcap/tidb-ansible/pull/815) diff --git a/releases/release-3.0-beta.md b/releases/release-3.0-beta.md index d959c41075369..25a49af7f35e5 100644 --- a/releases/release-3.0-beta.md +++ b/releases/release-3.0-beta.md @@ -17,7 +17,7 @@ summary: 2019年1月19日にリリースされたTiDB 3.0ベータ版は、安 - SQLオプティマイザー - `AggregationElimination` の最適化ルールを再サポート [＃7676](https://github.com/pingcap/tidb/pull/7676) - `NOT EXISTS`サブクエリを最適化し、Anti Semi Join に変換する [＃7842](https://github.com/pingcap/tidb/pull/7842) - - 新しいCascadesオプティマイザーをサポートするために、変数`tidb_enable_cascades_planner`追加します。現在、Cascadesオプティマイザーはまだ完全に実装されておらず、デフォルトではオフになっています[＃7879](https://github.com/pingcap/tidb/pull/7879) + - 新しいCascadesオプティマイザーをサポートするために、変数`tidb_enable_cascades_planner`を追加します。現在、Cascadesオプティマイザーはまだ完全に実装されておらず、デフォルトではオフになっています[＃7879](https://github.com/pingcap/tidb/pull/7879) - トランザクションのインデックス結合の使用をサポート [＃7877](https://github.com/pingcap/tidb/pull/7877) - 外部結合の定数伝播を最適化し、結合結果の外部テーブルに関連するフィルタリング条件を外部結合を介して外部テーブルにプッシュダウンできるようにすることで、外部結合の無駄な計算を減らし、実行パフォーマンスを向上させます[＃7794](https://github.com/pingcap/tidb/pull/7794) - 投影除去の最適化ルールを集計除去の後の位置に調整し、冗長な`Project`演算子回避する [＃7909](https://github.com/pingcap/tidb/pull/7909) diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index 6058781e78d1b..96f7e351d3e14 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -105,7 +105,7 @@ TiDB Ansible バージョン: 3.0.0 - システム初期化プロセスを最適化し、DDL所有者のみが初期化を実行できるようにします。これにより、初期化やアップグレードの起動時間が短縮されます。 - `kill query`の実行ロジックを最適化してパフォーマンスを向上させ、リソースが適切に解放されるようにします。 - 設定ファイルの有効性をチェックするための起動オプション`config-check`を追加します - - 内部エラー再試行のバックオフ時間を制御するシステム変数`tidb_back_off_weight`追加します + - 内部エラー再試行のバックオフ時間を制御するシステム変数`tidb_back_off_weight`を追加します - `wait_timeout`と`interactive_timeout`システム変数を追加して、許可されるアイドル接続の最大数を制御しましょう。 - 接続確立時間を短縮するために、TiKV の接続プールを追加します。 - 互換性 @@ -127,9 +127,9 @@ TiDB Ansible バージョン: 3.0.0 - `GetStores` APIのパフォーマンスを最適化 - 構成 - 構成チェックロジックを最適化して構成項目のエラーを回避する - - リージョンの結合方向を制御するには`enable-two-way-merge`追加します - - ホットリージョンのスケジュールレートを制御するには`hot-region-schedule-limit`追加します - - 複数のしきい値を連続して超える場合は、ホットスポットを識別するために`hot-region-cache-hits-threshold`追加します。 + - リージョンの結合方向を制御するには`enable-two-way-merge`を追加します + - ホットリージョンのスケジュールレートを制御するには`hot-region-schedule-limit`を追加します + - 複数のしきい値を連続して超える場合は、ホットスポットを識別するために`hot-region-cache-hits-threshold`を追加します。 - 1 分あたりに許可されるバランスリージョンオペレータの最大数を制御するための`store-balance-rate`構成項目を追加します。 - スケジューラの最適化 - 各ストアのオペレーターの速度を個別に制御するためのストア制限メカニズムを追加します。 diff --git a/releases/release-3.0.0-beta.1.md b/releases/release-3.0.0-beta.1.md index 23db5847f6e21..616ff8be9243b 100644 --- a/releases/release-3.0.0-beta.1.md +++ b/releases/release-3.0.0-beta.1.md @@ -64,7 +64,7 @@ TiDB Ansible バージョン: 3.0.0-beta.1 - `INFORMATION_SCHEMA.SLOW_QUERY`メモリテーブルを使用してスローログのクエリをサポート [＃9290](https://github.com/pingcap/tidb/pull/9290) - TiDBに表示されるMySQLのバージョンを5.7.10から5.7.25に変更する[＃9553](https://github.com/pingcap/tidb/pull/9553) - [ログ形式](https://github.com/tikv/rfcs/blob/master/text/0018-unified-log-format.md)統合してツールによる収集と分析を容易にする - - 統計に基づいて実際のデータ量と推定データ量の差を記録するための監視項目`high_error_rate_feedback_total`追加します。 [＃9209](https://github.com/pingcap/tidb/pull/9209) + - 統計に基づいて実際のデータ量と推定データ量の差を記録するための監視項目`high_error_rate_feedback_total`を追加します。 [＃9209](https://github.com/pingcap/tidb/pull/9209) - データベースディメンションにQPS監視項目を追加します。これは、構成項目を使用して有効にできます。 [＃9151](https://github.com/pingcap/tidb/pull/9151) - DDL - DDLタスクの再試行回数を制限するために、 `ddl_error_count_limit`グローバル変数（デフォルトでは「512」）を追加します（この回数が制限を超えると、DDLタスクはキャンセルされます） [＃9295](https://github.com/pingcap/tidb/pull/9295) diff --git a/releases/release-3.0.0-rc.1.md b/releases/release-3.0.0-rc.1.md index 5fee973c4d8ad..2dcb5ce889df9 100644 --- a/releases/release-3.0.0-rc.1.md +++ b/releases/release-3.0.0-rc.1.md @@ -36,7 +36,7 @@ TiDB Ansible バージョン: 3.0.0-rc.1 - サーバ - TiDB の起動時にのみ DDL 所有者にブートストラップの実行を許可する[＃10029](https://github.com/pingcap/tidb/pull/10029) - - トランザクション分離レベルをSERIALIZABLE に設定するときにTiDBがエラーを報告しないようにするために、変数`tidb_skip_isolation_level_check`追加します。 [＃10065](https://github.com/pingcap/tidb/pull/10065) + - トランザクション分離レベルをSERIALIZABLE に設定するときにTiDBがエラーを報告しないようにするために、変数`tidb_skip_isolation_level_check`を追加します。 [＃10065](https://github.com/pingcap/tidb/pull/10065) - 暗黙的なコミット時間とSQL実行時間をスローログにマージする [＃10294](https://github.com/pingcap/tidb/pull/10294) - SQL ロールのサポート (RBAC権限管理) - サポート`SHOW GRANT` [＃10016](https://github.com/pingcap/tidb/pull/10016) @@ -128,7 +128,7 @@ TiDB Ansible バージョン: 3.0.0-rc.1 - sync-diff-inspector - チェックポイントをサポートし、検証ステータスを記録し、再起動後に最後に保存したポイントから検証を続行します[＃224](https://github.com/pingcap/tidb-tools/pull/224) - - チェックサム計算してデータの整合性をチェックするための構成項目`only-use-checksum`追加します [＃215](https://github.com/pingcap/tidb-tools/pull/215) + - チェックサムを計算してデータの整合性をチェックするための構成項目`only-use-checksum`を追加します [＃215](https://github.com/pingcap/tidb-tools/pull/215) ## TiDB Ansible {#tidb-ansible} @@ -144,4 +144,4 @@ TiDB Ansible バージョン: 3.0.0-rc.1 - `table-regions.py`スクリプトを最適化して、表のリーダー分布を表示する [＃739](https://github.com/pingcap/tidb-ansible/pull/739) - Drainer の設定ファイルを更新します [＃745](https://github.com/pingcap/tidb-ansible/pull/745) - SQL カテゴリ別にレイテンシを表示する新しいパネルで TiDB モニタリングを最適化[＃747](https://github.com/pingcap/tidb-ansible/pull/747) -- Lightning設定ファイルを更新し、 `tidb_lightning_ctl`スクリプト[#1e946f8](https://github.com/pingcap/tidb-ansible/commit/1e946f89908e8fd6ef84128c6da3064ddfccf6a8)追加します。 +- Lightning設定ファイルを更新し、 `tidb_lightning_ctl`スクリプト[#1e946f8](https://github.com/pingcap/tidb-ansible/commit/1e946f89908e8fd6ef84128c6da3064ddfccf6a8)を追加します。 diff --git a/releases/release-3.0.1.md b/releases/release-3.0.1.md index fe35d4eef17a5..c672440a07331 100644 --- a/releases/release-3.0.1.md +++ b/releases/release-3.0.1.md @@ -55,7 +55,7 @@ TiDB Ansible バージョン: 3.0.1 - プロセス終了時にメモリリソースが誤って消去されることで発生するコアダンプの問題を修正[＃5053](https://github.com/tikv/tikv/pull/5053) - Titanエンジンに関連するすべての監視メトリック追加します [＃4772](https://github.com/tikv/tikv/pull/4772) [＃4836](https://github.com/tikv/tikv/pull/4836) - ファイルハンドルの統計が不正確であるためにファイルハンドルが利用できないという問題を回避するために、開いているファイルハンドルの数をカウントするときに Titan の開いているファイルハンドルの数を追加します[＃5026](https://github.com/tikv/tikv/pull/5026) -- 特定のCF でTitanエンジンを有効にするかどうかを決定するには`blob_run_mode`設定します。 [＃4991](https://github.com/tikv/tikv/pull/4991) +- 特定のCF でTitanエンジンを有効にするかどうかを決定するには`blob_run_mode`を設定します。 [＃4991](https://github.com/tikv/tikv/pull/4991) - 読み取り操作で悲観的トランザクションのコミット情報を取得できない問題を修正[＃5067](https://github.com/tikv/tikv/pull/5067) - Titanエンジンの実行モードを制御するための`blob-run-mode`構成パラメータを追加します。その値は`normal`、`fallback`、または`read-only`になります [＃4865](https://github.com/tikv/tikv/pull/4865) - デッドロック検出のパフォーマンスを向上[＃5089](https://github.com/tikv/tikv/pull/5089) diff --git a/releases/release-3.0.3.md b/releases/release-3.0.3.md index 18bc9c5b4f28e..9bad4f4fdd2c9 100644 --- a/releases/release-3.0.3.md +++ b/releases/release-3.0.3.md @@ -55,7 +55,7 @@ TiDB Ansible バージョン: 3.0.3 - リージョンマージ中に発生する可能性のある TiKV パニックを修正[＃5291](https://github.com/tikv/tikv/pull/5291) - デッドロック検出器リーダー変更チェックを高速化 [＃5317](https://github.com/tikv/tikv/pull/5317) - `grpc env`を使用してデッドロッククライアントを作成するサポート [＃5346](https://github.com/tikv/tikv/pull/5346) -- 構成が正しいかどうかを確認するには`config-check`追加します[＃5349](https://github.com/tikv/tikv/pull/5349) +- 構成が正しいかどうかを確認するには`config-check`を追加します[＃5349](https://github.com/tikv/tikv/pull/5349) - リーダーがない場合にReadIndexが何も返さない問題を修正 [＃5351](https://github.com/tikv/tikv/pull/5351) ## PD {#pd} diff --git a/releases/release-3.0.4.md b/releases/release-3.0.4.md index 5ef94b642648e..7f88772950f0e 100644 --- a/releases/release-3.0.4.md +++ b/releases/release-3.0.4.md @@ -18,7 +18,7 @@ TiDB Ansible バージョン: 3.0.4 - 改善点 - TiKV でバッチリージョン分割コマンドと空分割コマンドをサポートし、分割パフォーマンスを向上 - TiKV で RocksDB の二重リンクリストをサポートし、逆スキャンのパフォーマンスを向上 - - クラスタの状態をより適切に診断するために、TiDB Ansibleに2つのperfツール`iosnoop`と`funcslower`追加します。 + - クラスタの状態をより適切に診断するために、TiDB Ansibleに2つのperfツール`iosnoop`と`funcslower`を追加します。 - 冗長なフィールドを削除して、TiDB のスロークエリログの出力を最適化します。 - 動作の変更 - デフォルト値の`txn-local-latches.enable`を`false`に更新して、TiDB のローカルトランザクションの競合をチェックするデフォルトの動作を無効にします。 @@ -111,7 +111,7 @@ TiDB Ansible バージョン: 3.0.4 ## ツール {#tools} - TiDB Binlog - - Reparoの設定項目`worker-count`と`txn-batch`追加して回復速度制御します [＃746](https://github.com/pingcap/tidb-binlog/pull/746) + - Reparoの設定項目`worker-count`と`txn-batch`を追加して回復速度を制御します [＃746](https://github.com/pingcap/tidb-binlog/pull/746) - Drainerのメモリ使用量を最適化し、同時実行の効率を高めます[＃737](https://github.com/pingcap/tidb-binlog/pull/737) - TiDB Lightning - チェックポイントからデータを再インポートするとTiDB Lightning がpanicを起こす可能性がある問題を修正[＃237](https://github.com/pingcap/tidb-lightning/pull/237) @@ -122,7 +122,7 @@ TiDB Ansible バージョン: 3.0.4 - TiSparkをv2.2.0 にアップグレード [＃926](https://github.com/pingcap/tidb-ansible/pull/926) - TiDB構成項目`pessimistic_txn`のデフォルト値を`true` に更新します。 [＃933](https://github.com/pingcap/tidb-ansible/pull/933) - `node_exporter` にシステムレベルの監視メトリックを追加します [＃938](https://github.com/pingcap/tidb-ansible/pull/938) -- クラスタの状態をより適切に診断するために、TiDB Ansibleに2つのperfツール`iosnoop`と`funcslower`追加します[＃946](https://github.com/pingcap/tidb-ansible/pull/946) +- クラスタの状態をより適切に診断するために、TiDB Ansibleに2つのperfツール`iosnoop`と`funcslower`を追加します[＃946](https://github.com/pingcap/tidb-ansible/pull/946) - パスワードの有効期限が切れた場合などに発生する長い待機時間に対処するために、rawモジュールをシェルモジュールに置き換えます[＃949](https://github.com/pingcap/tidb-ansible/pull/949) - TiDB構成項目`txn_local_latches`のデフォルト値を`false`に更新します - Grafanaダッシュボードの監視メトリックとアラートルールを最適化する[＃962](https://github.com/pingcap/tidb-ansible/pull/962) [＃963](https://github.com/pingcap/tidb-ansible/pull/963) [＃969](https://github.com/pingcap/tidb-ansible/pull/963) diff --git a/releases/release-4.0.12.md b/releases/release-4.0.12.md index b263a4f5db64b..75300316b1e15 100644 --- a/releases/release-4.0.12.md +++ b/releases/release-4.0.12.md @@ -25,7 +25,7 @@ TiDB バージョン: 4.0.12 - DDLパッケージコードの一部を`Execute` `ExecRestricted`安全なAPIに移行する（1） [＃22929](https://github.com/pingcap/tidb/pull/22929) - `optimization-time`と`wait-TS-time`スローログに加える [＃22918](https://github.com/pingcap/tidb/pull/22918) - `infoschema.partitions`テーブルから`partition_id`クエリをサポート [＃22489](https://github.com/pingcap/tidb/pull/22489) - - SQL文の実行計画がバインディングヒントと一致しているかどうかをユーザーが知ることができるように`last_plan_from_binding`追加します。 [＃21430](https://github.com/pingcap/tidb/pull/21430) + - SQL文の実行計画がバインディングヒントと一致しているかどうかをユーザーが知ることができるように`last_plan_from_binding`を追加します。 [＃21430](https://github.com/pingcap/tidb/pull/21430) - `pre-split`オプションなしで切り捨てられたテーブルを散布する [＃22872](https://github.com/pingcap/tidb/pull/22872) - `str_to_date`式に 3 つの書式指定子を追加します [＃22812](https://github.com/pingcap/tidb/pull/22812) - メトリクスモニターで`PREPARE`実行失敗を`Failed Query OPM`として記録する [＃22672](https://github.com/pingcap/tidb/pull/22672) diff --git a/releases/release-4.0.2.md b/releases/release-4.0.2.md index 8586d10c4cd2e..5fc3a88b7dc16 100644 --- a/releases/release-4.0.2.md +++ b/releases/release-4.0.2.md @@ -42,7 +42,7 @@ TiDB バージョン: 4.0.2 - `MYSQL.BIND_INFO`表に`SOURCE`列を追加して、バインディングの作成方法を示します[＃17587](https://github.com/pingcap/tidb/pull/17587) - SQL文のプランキャッシュの使用状況を示すために、 `PERFORMANCE_SCHEMA.EVENTS_STATEMENTS_SUMMARY_BY_DIGEST`表に`PLAN_IN_CACHE`と`PLAN_CACHE_HITS`列を追加します。 [＃17493](https://github.com/pingcap/tidb/pull/17493) - `enable-collect-execution-info`構成項目と`tidb_enable_collect_execution_info`セッション変数を追加して、各演算子の実行情報を収集し、その情報をスロークエリログ に記録するかどうかを制御します。 [＃18072](https://github.com/pingcap/tidb/pull/18072) [＃18073](https://github.com/pingcap/tidb/pull/18073) - - スロークエリログでクエリの感度を下げるかどうかを制御するグローバル変数`tidb_slow_log_masking`追加します。 [＃17694](https://github.com/pingcap/tidb/pull/17694) + - スロークエリログでクエリの感度を下げるかどうかを制御するグローバル変数`tidb_slow_log_masking`を追加します。 [＃17694](https://github.com/pingcap/tidb/pull/17694) - `storage.block-cache.capacity` TiKV構成項目[＃17671](https://github.com/pingcap/tidb/pull/17671) `INFORMATION_SCHEMA.INSPECTION_RESULT`テーブルに診断ルールを追加します。 - データのバックアップと復元を行うSQL文`BACKUP`と`RESTORE`を追加する[＃15274](https://github.com/pingcap/tidb/pull/15274) diff --git a/releases/release-4.0.3.md b/releases/release-4.0.3.md index 9cb2c69352176..a9c71fadb7aac 100644 --- a/releases/release-4.0.3.md +++ b/releases/release-4.0.3.md @@ -54,7 +54,7 @@ TiDB バージョン: 4.0.3 - システムテーブル`tiflash_tables`と`tiflash_segments`を追加する[＃18536](https://github.com/pingcap/tidb/pull/18536) - `AUTO RANDOM`実験的機能から一般公開となり、リリースされました。改善点と互換性の変更点は以下の通りです。 - 設定ファイル内の`experimental.allow-auto-random`非推奨です。この項目の設定に関わらず、列の`AUTO RANDOM`機能はいつでも定義できます[＃18613](https://github.com/pingcap/tidb/pull/18613) [＃18623](https://github.com/pingcap/tidb/pull/18623) - - `AUTO RANDOM`列への明示的な書き込みを制御するために、セッション変数`tidb_allow_auto_random_explicit_insert`追加します。デフォルト値は`false`です。これは、列への明示的な書き込みによって発生する予期し`AUTO_RANDOM_BASE`更新を回避するためです[＃18508](https://github.com/pingcap/tidb/pull/18508) + - `AUTO RANDOM`列への明示的な書き込みを制御するために、セッション変数`tidb_allow_auto_random_explicit_insert`を追加します。デフォルト値は`false`です。これは、列への明示的な書き込みによって発生する予期しない`AUTO_RANDOM_BASE`の更新を回避するためです[＃18508](https://github.com/pingcap/tidb/pull/18508) - `BIGINT`列と`UNSIGNED BIGINT`列にのみ`AUTO_RANDOM`を定義できるようにし、シャードビットの最大数を`15`に制限することで、割り当て可能なスペースが急速に消費されるのを回避します[＃18538](https://github.com/pingcap/tidb/pull/18538) - `BIGINT`列に`AUTO_RANDOM`属性を定義し、主キーに負の値を挿入するときに`AUTO_RANDOM_BASE`更新をトリガーしないでください。 [＃17987](https://github.com/pingcap/tidb/pull/17987) - `UNSIGNED BIGINT`列に`AUTO_RANDOM`属性を定義するときに、IDの割り当てに整数の最上位ビットを使用します。これにより、割り当て可能なスペースが増えます。 [＃18404](https://github.com/pingcap/tidb/pull/18404) diff --git a/releases/release-5.0.0-rc.md b/releases/release-5.0.0-rc.md index ac2f66da9854f..f014fd92246f4 100644 --- a/releases/release-5.0.0-rc.md +++ b/releases/release-5.0.0-rc.md @@ -85,7 +85,7 @@ TiDB では、ID 情報やクレジットカード番号などの機密情報の - TiDB 側では、tidb-server で SQL ステートメントを使用して`tidb_redact_log=1`変数を設定します。 - TiKV 側では、tikv-server で`security.redact-info-log = true`構成を設定します。 - PD側ではpd-serverに`security.redact-info-log = true`設定をします[＃2852](https://github.com/tikv/pd/issues/2852) [＃3011](https://github.com/tikv/pd/pull/3011) -- TiFlash側では、tiflash-server に`security.redact_info_log = true`設定を設定し、tiflash-learner に`security.redact-info-log = true`設定します。 +- TiFlash側では、tiflash-server に`security.redact_info_log = true`を設定し、tiflash-learner に`security.redact-info-log = true`を設定します。 [ユーザードキュメント](/log-redaction.md) @@ -123,7 +123,7 @@ TiDB では、ID 情報やクレジットカード番号などの機密情報の TiDBのスケジューリングプロセスは、I/O、ネットワーク、CPU、メモリなどのリソースを占有します。TiDBがスケジュールされたタスクを制御しない場合、リソースのプリエンプションによりQPSと遅延がパフォーマンスジッターを引き起こす可能性があります。以下の最適化を行った後、72時間テストにおいて、Sysbench TPSジッターの標準偏差は11.09%から3.36%に減少しました。 - ノード容量の変動（常にウォーターライン付近）やPDの`store-limit`設定値が大きすぎることによって引き起こされる冗長なスケジューリングの問題を軽減します。これは、 `region-score-formula-version = v2`設定項目で有効化できる新しいスケジューリング計算式を導入することで実現します[＃3269](https://github.com/tikv/pd/pull/3269) -- `enable-cross-table-merge = true`変更して、空のリージョンの数を減らし、リージョン間のマージ機能を有効にします[＃3129](https://github.com/tikv/pd/pull/3129) +- `enable-cross-table-merge = true`を変更して、空のリージョンの数を減らし、リージョン間のマージ機能を有効にします[＃3129](https://github.com/tikv/pd/pull/3129) - TiKVバックグラウンドでのデータ圧縮は、多くのI/Oリソースを消費します。システムは、バックグラウンドタスクとフォアグラウンドの読み取り・書き込み間のI/Oリソースの競合をバランスさせるために、圧縮率を自動的に調整します。この機能を`rate-limiter-auto-tuned`設定項目で有効にすると、遅延ジッターが大幅に減少します[＃18011](https://github.com/pingcap/tidb/issues/18011) - TiKVがガベージコレクション（GC）とデータ圧縮を実行する際、パーティションはCPUとI/Oリソースを占有します。これらの2つのタスクの実行中は、データが重複する状態になります。I/O使用量を削減するため、GC圧縮フィルタ機能はこれらの2つのタスクを1つに統合し、同じタスク内で実行します。この機能はまだ実験的であり、 `gc.enable-compaction-filter = true` . から有効化できます。 [＃18009](https://github.com/pingcap/tidb/issues/18009) - TiFlash がデータを圧縮またはソートすると、大量の I/O リソースが消費されます。システムは、圧縮とデータソートによる I/O リソースの使用を制限することで、リソースの競合を軽減します。この機能はまだ実験的であり、 `bg_task_io_rate_limit`で有効化できます。 diff --git a/releases/release-5.0.6.md b/releases/release-5.0.6.md index 35bbf6eb77084..313157613c5d6 100644 --- a/releases/release-5.0.6.md +++ b/releases/release-5.0.6.md @@ -46,7 +46,7 @@ TiDB バージョン: 5.0.6 - 頻繁な etcd 書き込みが PD サービスに影響を与えないように、EtcdWorker にティック頻度制限を追加します[＃3112](https://github.com/pingcap/ticdc/issues/3112) - Kafkaシンクの`config.Metadata.Timeout`デフォルト設定を追加する [＃3352](https://github.com/pingcap/tiflow/issues/3352) - デフォルト値の`max-message-bytes`を`10M`に設定すると、Kafkaメッセージが送信されない可能性が減ります。 [＃3081](https://github.com/pingcap/tiflow/issues/3081) - - `no owner alert` 含む`mounter row` Prometheusとの監視メトリックとアラート`table sink total row`追加します`buffer sink total row` [＃1606](https://github.com/pingcap/tiflow/issues/1606) [＃4054](https://github.com/pingcap/tiflow/issues/4054) + - `no owner alert`、`mounter row`、`table sink total row`、`buffer sink total row`を含む Prometheus と Grafana の監視メトリックとアラートを追加します。 [＃1606](https://github.com/pingcap/tiflow/issues/1606) [＃4054](https://github.com/pingcap/tiflow/issues/4054) - Backup & Restore (BR) diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 35f7ddff86d92..bb86f66a66bcf 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -87,7 +87,7 @@ TiDBバージョン: 6.3.0-DMR - TiFlash がFastScan の使い方を変更 (実験的) [#5252](https://github.com/pingcap/tiflash/issues/5252) @[hongyunyan](https://github.com/hongyunyan) - バージョン6.2.0では、 TiFlashにFastScan機能が導入されました。これにより、期待通りのパフォーマンス向上が実現しましたが、使用上の柔軟性に欠けていました。そのため、バージョン6.3.0では、 TiFlashは[FastScanの使い方](/tiflash/use-fastscan.md)変更します。 FastScanを有効または無効にするための`ALTER TABLE ... SET TIFLASH MODE ...`構文は非推奨となりました。代わりに、システム変数[`tiflash_fastscan`](/system-variables.md#tiflash_fastscan-new-in-v630)を使用して、FastScanを有効にするかどうかを簡単に制御できます。 + バージョン6.2.0では、 TiFlashにFastScan機能が導入されました。これにより、期待通りのパフォーマンス向上が実現しましたが、使用上の柔軟性に欠けていました。そのため、バージョン6.3.0では、 TiFlashは[FastScanの使い方](/tiflash/use-fastscan.md)を変更します。 FastScanを有効または無効にするための`ALTER TABLE ... SET TIFLASH MODE ...`構文は非推奨となりました。代わりに、システム変数[`tiflash_fastscan`](/system-variables.md#tiflash_fastscan-new-in-v630)を使用して、FastScanを有効にするかどうかを簡単に制御できます。 バージョン 6.2.0 からバージョン 6.3.0 にアップグレードすると、バージョン 6.2.0 のすべての FastScan 設定が無効になりますが、データの通常の読み取りには影響しません。変数`tiflash_fastscan`を設定する必要があります。バージョン 6.2.0 またはそれ以前のバージョンからバージョン 6.3.0 にアップグレードすると、データの一貫性を維持するために、すべてのセッションで FastScan 機能がデフォルトで有効になりません。 diff --git a/releases/release-6.5.9.md b/releases/release-6.5.9.md index 4c778859f7154..af15cdc1f4649 100644 --- a/releases/release-6.5.9.md +++ b/releases/release-6.5.9.md @@ -13,7 +13,7 @@ TiDB バージョン: 6.5.9 ## 互換性の変更 {#compatibility-changes} -- RocksDB の TiKV 構成項目[`track-and-verify-wals-in-manifest`](https://docs.pingcap.com/tidb/v6.5/tikv-configuration-file#track-and-verify-wals-in-manifest-new-in-v659)追加します。これは、Write Ahead Log (WAL) の破損の可能性を調査するのに役立ちます。 [＃16549](https://github.com/tikv/tikv/issues/16549) @[v01dstar](https://github.com/v01dstar) +- RocksDB の TiKV 構成項目[`track-and-verify-wals-in-manifest`](https://docs.pingcap.com/tidb/v6.5/tikv-configuration-file#track-and-verify-wals-in-manifest-new-in-v659)を追加します。これは、Write Ahead Log (WAL) の破損の可能性を調査するのに役立ちます。 [＃16549](https://github.com/tikv/tikv/issues/16549) @[v01dstar](https://github.com/v01dstar) - DR自動同期は[`wait-recover-timeout`](https://docs.pingcap.com/tidb/v6.5/two-data-centers-in-one-city-deployment#enable-the-dr-auto-sync-mode)設定をサポートしており、ネットワークが回復した後、 `sync-recover`状態に戻るまでの待機時間を制御できます[＃6295](https://github.com/tikv/pd/issues/6295) @[disksing](https://github.com/disksing) ## 改善点 {#improvements} diff --git a/releases/release-7.1.5.md b/releases/release-7.1.5.md index ea69be33cb887..5d24406143fa0 100644 --- a/releases/release-7.1.5.md +++ b/releases/release-7.1.5.md @@ -13,7 +13,7 @@ TiDB バージョン: 7.1.5 ## 互換性の変更 {#compatibility-changes} -- RocksDB の TiKV 構成項目[`track-and-verify-wals-in-manifest`](https://docs.pingcap.com/tidb/v7.1/tikv-configuration-file#track-and-verify-wals-in-manifest-new-in-v659-and-v715)追加します。これは、Write Ahead Log (WAL) の破損の可能性を調査するのに役立ちます。 [＃16549](https://github.com/tikv/tikv/issues/16549) @[v01dstar](https://github.com/v01dstar) +- RocksDB の TiKV 構成項目[`track-and-verify-wals-in-manifest`](https://docs.pingcap.com/tidb/v7.1/tikv-configuration-file#track-and-verify-wals-in-manifest-new-in-v659-and-v715)を追加します。これは、Write Ahead Log (WAL) の破損の可能性を調査するのに役立ちます。 [＃16549](https://github.com/tikv/tikv/issues/16549) @[v01dstar](https://github.com/v01dstar) ## 改善点 {#improvements} diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index 7e08fb43b0a4a..43edc88ce69b7 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -103,7 +103,7 @@ TiDB バージョン: 7.4.0 TiDB v7.1.0では、リソース制御機能が一般提供され、TiDBとTiKVのリソース管理機能を提供します。v7.4.0では、 TiFlashがリソース制御機能をサポートし、TiDB全体のリソース管理機能が向上しました。TiFlashのリソースTiFlashは既存のTiDBリソース制御機能と完全に互換性があり、既存のリソースグループはTiDB、TiKV、 TiFlashのリソースを同時に管理します。 - TiFlashリソース制御機能を有効にするかどうかを制御するには、 TiFlashパラメータ`enable_resource_control`設定します。この機能を有効にすると、 TiFlashはTiDBのリソースグループ設定に基づいてリソースのスケジュールと管理を実行し、全体的なリソースの適切な割り当てと使用を保証します。 + TiFlashリソース制御機能を有効にするかどうかを制御するには、 TiFlashパラメータ`enable_resource_control`を設定します。この機能を有効にすると、 TiFlashはTiDBのリソースグループ設定に基づいてリソースのスケジュールと管理を実行し、全体的なリソースの適切な割り当てと使用を保証します。 詳細については[ドキュメント](/tidb-resource-control-ru-groups.md)を参照してください。 diff --git a/releases/release-7.5.2.md b/releases/release-7.5.2.md index 6f868a1911ce9..eb7e971c64462 100644 --- a/releases/release-7.5.2.md +++ b/releases/release-7.5.2.md @@ -13,7 +13,7 @@ TiDB バージョン: 7.5.2 ## 互換性の変更 {#compatibility-changes} -- RocksDB の TiKV 構成項目[`track-and-verify-wals-in-manifest`](https://docs.pingcap.com/tidb/v7.5/tikv-configuration-file#track-and-verify-wals-in-manifest-new-in-v659-v715-and-v752)追加します。これは、Write Ahead Log (WAL) の破損の可能性を調査するのに役立ちます。 [＃16549](https://github.com/tikv/tikv/issues/16549) @[v01dstar](https://github.com/v01dstar) +- RocksDB の TiKV 構成項目[`track-and-verify-wals-in-manifest`](https://docs.pingcap.com/tidb/v7.5/tikv-configuration-file#track-and-verify-wals-in-manifest-new-in-v659-v715-and-v752)を追加します。これは、Write Ahead Log (WAL) の破損の可能性を調査するのに役立ちます。 [＃16549](https://github.com/tikv/tikv/issues/16549) @[v01dstar](https://github.com/v01dstar) - TiDB Lightning `strict-format`または`SPLIT_FILE`を使用して CSV ファイルをインポートする場合は、行末文字を設定する必要があります[＃37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) - TiCDCオープンプロトコルの`sink.open.output-old-value`設定項目を追加して、更新前の値を下流に出力するかどうかを制御します。 [＃10916](https://github.com/pingcap/tiflow/issues/10916) @[sdojjy](https://github.com/sdojjy) - 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`目のイベントで主キーまたは非NULLの一意インデックス値が変更されると、TiCDCはこのイベントを`DELETE`目と`INSERT`目のイベントに分割していました。v7.5.2以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS` TiCDC `thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`目のイベントを`DELETE` `INSERT`と13件目のイベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`目のイベントの順序が誤っている可能性があり、分割された`DELETE`と`INSERT`目のイベントの順序が誤っている可能性があるため、ダウンストリームデータの不整合が発生する問題に対処しています。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v7.5/ticdc-split-update-behavior#split-update-events-for-mysql-sinks) してください@[lidezhu](https://github.com/lidezhu) [＃10918](https://github.com/pingcap/tiflow/issues/10918) diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md index eae103493a0b0..efc9af4cd9e3c 100644 --- a/scale-tidb-using-tiup.md +++ b/scale-tidb-using-tiup.md @@ -406,7 +406,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する 2. pd-ctl でTiFlashノードを削除します。 - - pd-ctl に`store delete `入力します ( ``前の手順で見つかったTiFlashノードのストア ID です)。 + - pd-ctl に`store delete `を入力します (``は前の手順で見つかったTiFlashノードのストア ID です)。 - TiUPデプロイメントを使用する場合は、 `pd-ctl` `tiup ctl:v pd`に置き換えます。 diff --git a/security-compatibility-with-mysql.md b/security-compatibility-with-mysql.md index faf375251f4c2..90dc24111ab4f 100644 --- a/security-compatibility-with-mysql.md +++ b/security-compatibility-with-mysql.md @@ -193,7 +193,7 @@ Here is an example for Header: #### 使用法 {#usage} -TiDB Self-Managed ユーザーの認証方法として`tidb_auth_token`設定して使用するには、次の手順を実行します。 +TiDB Self-Managed ユーザーの認証方法として`tidb_auth_token`を設定して使用するには、次の手順を実行します。 1. Configure [`auth-token-jwks`](/tidb-configuration-file.md#auth-token-jwks-new-in-v640) and [`auth-token-refresh-interval`](/tidb-configuration-file.md#auth-token-refresh-interval-new-in-v640) in the TiDB configuration file. diff --git a/sql-statements/sql-statement-alter-table-compact.md b/sql-statements/sql-statement-alter-table-compact.md index 0574e7a2cb3c5..2d91e745e8290 100644 --- a/sql-statements/sql-statement-alter-table-compact.md +++ b/sql-statements/sql-statement-alter-table-compact.md @@ -83,7 +83,7 @@ ALTER TABLE employees COMPACT PARTITION pNorth, pEast TIFLASH REPLICA; -リソース使用率を高めながらテーブルレベルの同時実行性を高めるには、 TiFlash構成[`manual_compact_pool_size`](/tiflash/tiflash-configuration.md)変更します。例えば、 `manual_compact_pool_size` 2に設定すると、2つのテーブルのコンパクションを同時に処理できます。 +リソース使用率を高めながらテーブルレベルの同時実行性を高めるには、 TiFlash構成[`manual_compact_pool_size`](/tiflash/tiflash-configuration.md)を変更します。例えば、 `manual_compact_pool_size`を2に設定すると、2つのテーブルのコンパクションを同時に処理できます。 diff --git a/sql-statements/sql-statement-savepoint.md b/sql-statements/sql-statement-savepoint.md index 7b02f6428e372..f645100ecc594 100644 --- a/sql-statements/sql-statement-savepoint.md +++ b/sql-statements/sql-statement-savepoint.md @@ -70,7 +70,7 @@ BEGIN; Query OK, 0 rows affected (0.00 sec) ``` -テーブルにデータを挿入し、セーブポイント`sp1`設定します。 +テーブルにデータを挿入し、セーブポイント`sp1`を設定します。 ```sql INSERT INTO t1 VALUES (1); @@ -88,7 +88,7 @@ SAVEPOINT sp1; Query OK, 0 rows affected (0.01 sec) ``` -テーブルに再度データを挿入し、セーブポイント`sp2`設定します。 +テーブルに再度データを挿入し、セーブポイント`sp2`を設定します。 ```sql INSERT INTO t1 VALUES (2); diff --git a/storage-engine/titan-configuration.md b/storage-engine/titan-configuration.md index 09b62de5d8413..da8657feed4a3 100644 --- a/storage-engine/titan-configuration.md +++ b/storage-engine/titan-configuration.md @@ -132,7 +132,7 @@ level-merge = false ## Titanを無効にする {#disable-titan} -Titanを無効にするには、オプション`rocksdb.defaultcf.titan.blob-run-mode`設定します。オプション`blob-run-mode`のオプション値は次のとおりです。 +Titanを無効にするには、オプション`rocksdb.defaultcf.titan.blob-run-mode`を設定します。オプション`blob-run-mode`のオプション値は次のとおりです。 - オプションを`normal`に設定すると、Titan は読み取りおよび書き込み操作を通常どおり実行します。 - オプションを`read-only`に設定すると、値のサイズに関係なく、新しく書き込まれたすべての値が RocksDB に書き込まれます。 diff --git a/sync-diff-inspector/route-diff.md b/sync-diff-inspector/route-diff.md index b965b10d7d123..f5311012e8d29 100644 --- a/sync-diff-inspector/route-diff.md +++ b/sync-diff-inspector/route-diff.md @@ -76,7 +76,7 @@ target-table = "t_2" # The name of the target table - アップストリームにスキーマ`schema`がない場合、sync-diff-inspector は何も行いません。 - アップストリームにスキーマ`schema`があり、ルールがスキーマに一致する場合、sync-diff-inspector は何も行いません。 - - アップストリームにスキーマ`schema`が存在するものの、それに一致するルールがない場合、sync-diff-inspector はテーブルルーターに新しいルール`schema -> _no__exists__db_`追加します。その後、sync-diff-inspector はテーブル`schema`をテーブル`_no__exists__db_`として扱います。 + - アップストリームにスキーマ`schema`が存在するものの、それに一致するルールがない場合、sync-diff-inspector はテーブルルーターに新しいルール`schema -> _no__exists__db_`を追加します。その後、sync-diff-inspector はテーブル`schema`をテーブル`_no__exists__db_`として扱います。 - ルールに`target-schema.target-table`存在しない場合は、テーブル ルーターが大文字と小文字を区別しないため、sync-diff-inspector は`target-schema.target-table`から`target-schema.target-table`に一致するルールを追加して大文字と小文字を区別しないようにします。 diff --git a/ticdc/deploy-ticdc.md b/ticdc/deploy-ticdc.md index cba977e3437af..fd5e3c6cf33a5 100644 --- a/ticdc/deploy-ticdc.md +++ b/ticdc/deploy-ticdc.md @@ -114,7 +114,7 @@ TiCDCクラスタをアップグレードする際には、以下の点に注意 tiup cluster edit-config ``` -2. viエディタで`cdc` [`server-configs`](/tiup/tiup-cluster-topology-reference.md#server_configs)変更します。 +2. viエディタで`cdc` [`server-configs`](/tiup/tiup-cluster-topology-reference.md#server_configs)を変更します。 ```shell server_configs: diff --git a/ticdc/integrate-confluent-using-ticdc.md b/ticdc/integrate-confluent-using-ticdc.md index 4ea9153cd5f58..c15fb83369aa6 100644 --- a/ticdc/integrate-confluent-using-ticdc.md +++ b/ticdc/integrate-confluent-using-ticdc.md @@ -177,7 +177,7 @@ Snowflakeはクラウドネイティブなデータウェアハウスです。Co ![Configuration](/media/integrate/configuration.png) -5. **コンフィグレーション**ページで、**入力Kafkaレコード値の形式**と**入力Kafkaレコードキーの形式**の両方に`AVRO`選択します。次に、 **続行**をクリックします。コネクタが作成され、ステータスが**実行中**になるまでお待ちください。これには数分かかる場合があります。 +5. **コンフィグレーション**ページで、**入力Kafkaレコード値の形式**と**入力Kafkaレコードキーの形式**の両方に`AVRO`を選択します。次に、 **続行**をクリックします。コネクタが作成され、ステータスが**実行中**になるまでお待ちください。これには数分かかる場合があります。 ![Data preview](/media/integrate/data-preview.png) diff --git a/ticdc/ticdc-bidirectional-replication.md b/ticdc/ticdc-bidirectional-replication.md index 2df52393ef412..fb12e8c752099 100644 --- a/ticdc/ticdc-bidirectional-replication.md +++ b/ticdc/ticdc-bidirectional-replication.md @@ -163,9 +163,9 @@ BDRロールが設定されていない場合、任意のDDLを実行できま - 通常、レプリケートされたテーブルでのデータ競合を避けるため、 [`AUTO_INCREMENT`](/auto-increment.md)または[`AUTO_RANDOM`](/auto-random.md)を使用しないでください。`AUTO_INCREMENT`または`AUTO_RANDOM`を使用する必要がある場合は、異なるクラスタに異なる主キーを割り当てることができるように、異なるクラスタに異なる`auto_increment_increment`と`auto_increment_offset`を設定できます。例えば、双方向レプリケーションに3つのTiDBクラスタ（A、B、C）がある場合、次のように設定します。 - - クラスタAでは、 `auto_increment_increment=3`と`auto_increment_offset=2000`設定します - - クラスタBでは、 `auto_increment_increment=3`と`auto_increment_offset=2001`設定します - - クラスタCでは、 `auto_increment_increment=3`と`auto_increment_offset=2002`設定します + - クラスタAでは、 `auto_increment_increment=3`と`auto_increment_offset=2000`を設定します + - クラスタBでは、 `auto_increment_increment=3`と`auto_increment_offset=2001`を設定します + - クラスタCでは、 `auto_increment_increment=3`と`auto_increment_offset=2002`を設定します これにより、A、B、Cは暗黙的に割り当てられた`AUTO_INCREMENT`と`AUTO_RANDOM`で互いに競合することがなくなります。BDRモードでクラスターを追加する必要がある場合は、関連アプリケーションのデータ書き込みを一時的に停止し、すべてのクラスターの`auto_increment_increment`と`auto_increment_offset`に適切な値を設定してから、関連アプリケーションのデータ書き込みを再開する必要があります。 diff --git a/ticdc/ticdc-client-authentication.md b/ticdc/ticdc-client-authentication.md index a74c796031000..92d48680108ec 100644 --- a/ticdc/ticdc-client-authentication.md +++ b/ticdc/ticdc-client-authentication.md @@ -33,7 +33,7 @@ v8.1.0 以降、TiCDC は Mutual Transport Layer Security (mTLS) または TiDB [TiCDC コマンドラインツール](/ticdc/ticdc-manage-changefeed.md)を使用する場合、以下の方法でクライアント証明書を指定できます。TiCDC は以下の順序でクライアント証明書の読み取りを試みます。 - 1. コマンドラインパラメータ`--cert`と`--key`使用して、証明書と秘密鍵を指定します。サーバーが自己署名証明書を使用している場合は、パラメータ`--ca`を使用して信頼できる CA 証明書も指定する必要があります。 + 1. コマンドラインパラメータ`--cert`と`--key`を使用して、証明書と秘密鍵を指定します。サーバーが自己署名証明書を使用している場合は、パラメータ`--ca`を使用して信頼できる CA 証明書も指定する必要があります。 ```bash cdc cli changefeed list --cert client.crt --key client.key --ca ca.crt @@ -70,7 +70,7 @@ v8.1.0 以降、TiCDC は Mutual Transport Layer Security (mTLS) または TiDB CREATE USER 'test'@'ticdc_ip_address' IDENTIFIED BY 'password'; ``` -2. TiCDCサーバーで、ユーザー名とパスワードの認証を有効にするために`security.client-user-required`と`security.client-allowed-user`設定します。 +2. TiCDCサーバーで、ユーザー名とパスワードの認証を有効にするために`security.client-user-required`と`security.client-allowed-user`を設定します。 ```toml [security] diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 17804df15a947..e48e64925c354 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -353,7 +353,7 @@ mysql root@127.0.0.1:test> show create table test; 結果から、レプリケーション前後のテーブルスキーマが不整合になっていることがわかります。これは、TiDBの`explicit_defaults_for_timestamp`のデフォルト値がMySQLと異なるためです。詳細は[MySQLとの互換性](/mysql-compatibility.md#default-differences)をご覧ください。 -v5.0.1 または v4.0.13 以降、MySQL へのレプリケーションごとに、TiCDC は上流と下流の間で時刻型の一貫性を保つために、自動的に`explicit_defaults_for_timestamp = ON`設定します。v5.0.1 または v4.0.13 より前のバージョンでは、TiCDC を使用して時刻型データをレプリケーションする際に、不一致な`explicit_defaults_for_timestamp`値によって発生する互換性の問題にご注意ください。 +v5.0.1 以降または v4.0.13 以降では、MySQL へのレプリケーションごとに、TiCDC は上流と下流の間で時刻型の一貫性を保つために、自動的に`explicit_defaults_for_timestamp = ON`を設定します。v5.0.1 より前または v4.0.13 より前のバージョンでは、TiCDC を使用して時刻型データをレプリケーションする際に、不一致な`explicit_defaults_for_timestamp`値によって発生する互換性の問題にご注意ください。 ## TiCDC レプリケーション タスクを作成するときに`safe-mode` `true`に設定すると、アップストリームからの`INSERT` / `UPDATE`ステートメントがダウンストリームにレプリケートされた後に`REPLACE INTO`になるのはなぜですか? {#why-do-insertupdate-statements-from-the-upstream-become-replace-into-after-being-replicated-to-the-downstream-if-i-set-safe-mode-to-true-when-i-create-a-ticdc-replication-task} @@ -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} diff --git a/ticdc/ticdc-open-protocol.md b/ticdc/ticdc-open-protocol.md index 0c7f43c7babf8..155634dcff704 100644 --- a/ticdc/ticdc-open-protocol.md +++ b/ticdc/ticdc-open-protocol.md @@ -375,4 +375,4 @@ COMMIT; > **Note:** > > - `BinaryFlag`は、列の型が BLOB/ TEXT （TINYBLOB/TINYTEXT、BINARY/CHAR を含む）の場合にのみ意味を持ちます。上流の列が BLOB 型の場合、 `BinaryFlag`の値は`1`に設定されます。上流の列がTEXT型の場合、 `BinaryFlag`の値は`0`に設定されます。 -> - TiCDCは、上流からテーブルを複製するために、ハンドルインデックスとして[有効なインデックス](/ticdc/ticdc-overview.md#best-practices)選択します。ハンドルインデックス列の`HandleKeyFlag`の値は`1`に設定されます。 +> - TiCDCは、上流からテーブルを複製するために、ハンドルインデックスとして[有効なインデックス](/ticdc/ticdc-overview.md#best-practices)を選択します。ハンドルインデックス列の`HandleKeyFlag`の値は`1`に設定されます。 diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index 9f1bf88b81adc..b85cdf03bb497 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -127,7 +127,7 @@ cdc cli changefeed resume -c test-cf --server=http://127.0.0.1:8300 この問題のあるDDL文をスキップするには、 `ignore-txn-start-ts`パラメータを設定して、指定された`start-ts`に対応するトランザクションをスキップします。例: 1. TiCDC ログで`apply job`フィールドを検索し、時間がかかっている`start-ts`の DDL を特定します。 -2. changefeed の設定を変更します。設定項目`ignore-txn-start-ts`に上記の`start-ts`追加します。 +2. changefeed の設定を変更します。設定項目`ignore-txn-start-ts`に上記の`start-ts`を追加します。 3. 中断された変更フィードを再開します。 > **Note:** diff --git a/tidb-cloud/monitor-new-relic-integration.md b/tidb-cloud/monitor-new-relic-integration.md index a66aaec3b8283..fcbc9ab0f571b 100644 --- a/tidb-cloud/monitor-new-relic-integration.md +++ b/tidb-cloud/monitor-new-relic-integration.md @@ -123,7 +123,7 @@ TiDB Cloudは、2023年4月11日よりプロジェクトレベルのNew Relic統
    1. [New Relic](https://one.newrelic.com/)にログインします。 -2. **Add Data**をクリックし、 `TiDB Cloud`を検索して、 **TiDB Cloud Monitoring**ページに移動します。または、 [リンク](https://one.newrelic.com/marketplace?state=79bf274b-0c01-7960-c85c-3046ca96568e)クリックして直接ページにアクセスすることもできます。 +2. **Add Data**をクリックし、 `TiDB Cloud`を検索して、 **TiDB Cloud Monitoring**ページに移動します。または、 [リンク](https://one.newrelic.com/marketplace?state=79bf274b-0c01-7960-c85c-3046ca96568e)をクリックして直接ページにアクセスすることもできます。 3. アカウントIDを選択し、New Relicでダッシュボードを作成してください。
    diff --git a/tidb-cloud/scale-tidb-cluster.md b/tidb-cloud/scale-tidb-cluster.md index b75f48a358264..cdd3448d61e7c 100644 --- a/tidb-cloud/scale-tidb-cluster.md +++ b/tidb-cloud/scale-tidb-cluster.md @@ -20,7 +20,7 @@ TiDB クラスターのサイズを決定する方法については、 [TiDBの > **Note:** > -> TiDBまたはTiKVのvCPUとRAMサイズが**4 vCPU、16 GiB**に設定されている場合、以下の制限事項にご注意ください。これらの制限を回避するには、まず[vCPUとRAMを増やす](#change-vcpu-and-ram)設定してください。 +> TiDBまたはTiKVのvCPUとRAMサイズが**4 vCPU、16 GiB**に設定されている場合、以下の制限事項にご注意ください。これらの制限を回避するには、まず[vCPUとRAMを増やす](#change-vcpu-and-ram)必要があります。 > > - TiDB のノード数は 1 または 2 にのみ設定でき、TiKV のノード数は 3 に固定されています。 > - 4 vCPU TiDB は 4 vCPU TiKV でのみ使用でき、4 vCPU TiKV は 4 vCPU TiDB でのみ使用できます。 diff --git a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md index c884062364665..74033d569eda7 100644 --- a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md +++ b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md @@ -135,7 +135,7 @@ SASL/SCRAM の代わりに、 IAM認証を使用して MSK クラスターと同 次のクラスター構成プロパティを更新します。 - セット`auto.create.topics.enable=true` 。 -- `allow.everyone.if.no.acl.found=false`追加します (SASL/SCRAM に必要)。 +- `allow.everyone.if.no.acl.found=false`を追加します (SASL/SCRAM に必要)。 - その他のプロパティは変更せず、必要に応じて調整します。 変更を適用し、クラスターのステータスが**Updating**から**Active**に変わるまで待ちます。 diff --git a/tidb-cloud/set-up-private-endpoint-connections.md b/tidb-cloud/set-up-private-endpoint-connections.md index 2aefba577a072..696f650b8c2ca 100644 --- a/tidb-cloud/set-up-private-endpoint-connections.md +++ b/tidb-cloud/set-up-private-endpoint-connections.md @@ -109,7 +109,7 @@ AWS マネジメントコンソールを使用して VPC インターフェイ 3. **Endpoint settings**領域で、必要に応じて名前タグを入力し、 **Endpoint services that use NLBs and GWLBs**オプションを選択します。 -4. **Service settings**領域に、生成されたコマンド（ `--service-name ${your_endpoint_service_name}` ）のサービス名`${your_endpoint_service_name}`入力します。 +4. **Service settings**領域に、生成されたコマンド（ `--service-name ${your_endpoint_service_name}` ）のサービス名`${your_endpoint_service_name}`を入力します。 5. **Verify service**をクリックします。 diff --git a/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md b/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md index 5a5528d34e2d6..d61fe7cab1e99 100644 --- a/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md +++ b/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md @@ -502,7 +502,7 @@ b3.abc.eastus.azure.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. 1. [Azureポータル](https://portal.azure.com/)にログインし、 [プライベートリンクサービス](https://portal.azure.com/#view/Microsoft_Azure_Network/PrivateLinkCenterBlade/~/privatelinkservices)ページに移動して、 **+ Create**をクリックし、Kafka ロードバランサーのプライベートリンク サービスを作成します。 -2. **[基本]**タブで、 **[サブスクリプ**ション]、 **Resource group** 、 **[リージョン]**を選択し、[**名前]**フィールドに`kafka-pls`入力して、 **[次へ: 送信設定 >]**をクリックします。 +2. **[基本]**タブで、 **[サブスクリプション]**、 **Resource group** 、 **[リージョン]**を選択し、 **[名前]**フィールドに`kafka-pls`を入力して、 **[次へ: 送信設定 >]**をクリックします。 3. **Outbound settings**タブで、次のようにパラメータを入力し、 **Next : Access security >**をクリックします。 diff --git a/tidb-cloud/terraform-use-cluster-resource.md b/tidb-cloud/terraform-use-cluster-resource.md index 9e8e0f15e4c3f..03280326a0a17 100644 --- a/tidb-cloud/terraform-use-cluster-resource.md +++ b/tidb-cloud/terraform-use-cluster-resource.md @@ -611,7 +611,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の } } -2. `terraform apply`コマンドを実行し、確認のために`yes`入力します。 +2. `terraform apply`コマンドを実行し、確認のために`yes`を入力します。 $ terraform apply @@ -666,8 +666,8 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の ステータスが`AVAILABLE`のときにクラスターを一時停止し、ステータスが`PAUSED`のときにクラスターを再開できます。 -- クラスターを一時停止するには`paused = true`設定します。 -- クラスターを再開するには`paused = false`設定します。 +- クラスターを一時停止するには`paused = true`を設定します。 +- クラスターを再開するには`paused = false`を設定します。 1. [クラスターを作成する](#create-a-cluster-using-the-cluster-resource)を実行するときに使用する`cluster.tf`ファイルで、 `config`構成に`pause = true`を追加します。 @@ -678,7 +678,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の ... } -2. `terraform apply`コマンドを実行し、チェック後に`yes`入力します。 +2. `terraform apply`コマンドを実行し、チェック後に`yes`を入力します。 $ terraform apply @@ -753,7 +753,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の status = "PAUSED" } -4. クラスターを再開する必要がある場合は、 `paused = false`設定します。 +4. クラスターを再開する必要がある場合は、 `paused = false`を設定します。 config = { paused = false diff --git a/tidb-cloud/terraform-use-dedicated-cluster-resource.md b/tidb-cloud/terraform-use-dedicated-cluster-resource.md index cbb2a3ccba070..728eb4303511e 100644 --- a/tidb-cloud/terraform-use-dedicated-cluster-resource.md +++ b/tidb-cloud/terraform-use-dedicated-cluster-resource.md @@ -385,7 +385,7 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 - クラスターにTiFlashコンポーネントを追加します。 - クラスターをスケーリングします。 - クラスターを一時停止または再開します。 -- クラスターに[TiDBノードグループ](/tidb-cloud/tidb-node-group-overview.md)追加します。 +- クラスターに[TiDBノードグループ](/tidb-cloud/tidb-node-group-overview.md)を追加します。 - クラスターの TiDB ノード グループを更新します。 - クラスターの TiDB ノード グループを削除します。 @@ -579,7 +579,7 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 storage_size_gi = 200 } -2. `terraform apply`コマンドを実行し、確認のために`yes`入力します。 +2. `terraform apply`コマンドを実行し、確認のために`yes`を入力します。 tidbcloud_dedicated_cluster.example_cluster: Refreshing state... @@ -659,14 +659,14 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 クラスターの状態が`ACTIVE`のときは一時停止し、状態が`PAUSED`のときは再開できます。 -- クラスターを一時停止するには`paused = true`設定します。 -- クラスターを再開するには`paused = false`設定します。 +- クラスターを一時停止するには`paused = true`を設定します。 +- クラスターを再開するには`paused = false`を設定します。 1. [クラスターを作成する](#create-a-tidb-cloud-dedicated-cluster)を実行するときに使用する`cluster.tf`ファイルで、構成に`pause = true`を追加します。 paused = true -2. `terraform apply`コマンドを実行し、プランを確認した後、 `yes`入力します。 +2. `terraform apply`コマンドを実行し、プランを確認した後、 `yes`を入力します。 ```shell $ terraform apply @@ -803,11 +803,11 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 version = "v7.5.6" } -4. クラスターを再開する必要がある場合は、 `paused = false`設定します。 +4. クラスターを再開する必要がある場合は、 `paused = false`を設定します。 paused = false -5. `terraform apply`コマンドを実行し、確認のために`yes`入力します。しばらく待つと、状態が最終的に`ACTIVE`に変更されます。 +5. `terraform apply`コマンドを実行し、確認のために`yes`を入力します。しばらく待つと、状態が最終的に`ACTIVE`に変更されます。 ### クラスターに TiDB ノード グループを追加する {#add-a-tidb-node-group-to-the-cluster} @@ -823,7 +823,7 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 display_name = "test-node-group" } -2. `terraform apply`コマンドを実行し、確認のために`yes`入力します。 +2. `terraform apply`コマンドを実行し、確認のために`yes`を入力します。 ```shell $ terraform apply @@ -908,7 +908,7 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 display_name = "test-node-group" } -2. `terraform apply`コマンドを実行し、確認のために`yes`入力します。 +2. `terraform apply`コマンドを実行し、確認のために`yes`を入力します。 ```shell $ terraform apply diff --git a/tidb-cloud/terraform-use-import-resource.md b/tidb-cloud/terraform-use-import-resource.md index 1a0f8b37fc6d0..ab8dc42e465ec 100644 --- a/tidb-cloud/terraform-use-import-resource.md +++ b/tidb-cloud/terraform-use-import-resource.md @@ -68,7 +68,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク ファイル内のリソース値（プロジェクトID、クラスタID、CSVパスなど）をご自身のものに置き換えてください。 `csv_format`の詳細は [設定ページ](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/import#nested-schema-for-csv_format)に記載されています。 -3. `terraform apply`コマンドを実行してインポート タスクを作成し、 `yes`入力して作成を確認し、インポートを開始します。 +3. `terraform apply`コマンドを実行してインポート タスクを作成し、 `yes`を入力して作成を確認し、インポートを開始します。 $ terraform apply ... @@ -214,7 +214,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク source_url = "your_url" } -2. `terraform apply`コマンドを実行してインポート タスクを作成し、 `yes`入力して作成を確認し、インポートを開始します。 +2. `terraform apply`コマンドを実行してインポート タスクを作成し、 `yes`を入力して作成を確認し、インポートを開始します。 $ terraform apply ... diff --git a/tidb-cloud/terraform-use-restore-resource.md b/tidb-cloud/terraform-use-restore-resource.md index 70e7289a76efb..d3267601e4ee0 100644 --- a/tidb-cloud/terraform-use-restore-resource.md +++ b/tidb-cloud/terraform-use-restore-resource.md @@ -70,7 +70,7 @@ summary: tidbcloud_restore` リソースを使用して復元タスクを作成 } ``` -3. `terraform apply`コマンドを実行し、確認のために`yes`入力します。 +3. `terraform apply`コマンドを実行し、確認のために`yes`を入力します。 ``` $ terraform apply diff --git a/tidb-cloud/ticloud-serverless-spending-limit.md b/tidb-cloud/ticloud-serverless-spending-limit.md index 5b05be91d91ee..967ae2ef56f2c 100644 --- a/tidb-cloud/ticloud-serverless-spending-limit.md +++ b/tidb-cloud/ticloud-serverless-spending-limit.md @@ -5,7 +5,7 @@ summary: ticloud serverless spending-limit` のリファレンス。 # ticloud serverless spending-limit {#ticloud-serverless-spending-limit} -TiDB Cloud Serverless クラスターの月間最大数[支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)設定します。 +TiDB Cloud Serverless クラスターの月間最大数[支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)を設定します。 ```shell ticloud serverless spending-limit [flags] diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index 7a8e974c3b5eb..426ab9bdc6d30 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -78,7 +78,7 @@ SET GLOBAL tidb_opt_fix_control = '44262:ON,44389:ON,44823:10000,44830:ON,44855: - [`44389:ON`](/optimizer-fix-controls.md#44389-new-in-v653-and-v720) : `c = 10 and (a = 'xx' or (a = 'kk' and b = 1))`のようなフィルターの場合、 `IndexRangeScan`のより包括的なスキャン範囲を作成します。 - [`44823:10000`](/optimizer-fix-controls.md#44823-new-in-v730) ：メモリを節約するため、プランキャッシュは、この変数で指定された数を超えるパラメータを持つクエリをキャッシュしません。長いインリストを持つクエリでもプランキャッシュを使用できるようにするには、プランキャッシュのパラメータ制限を`200`から`10000`に増やしてください。 - [`44830:ON`](/optimizer-fix-controls.md#44830-new-in-v657-and-v730) : プランキャッシュは、物理最適化中に生成された`PointGet`演算子を含む実行計画をキャッシュすることを許可します。 -- [`44855:ON`](/optimizer-fix-controls.md#44855-new-in-v654-and-v730) : `IndexJoin`演算子の`Probe`側に`Selection`演算子が含まれている場合、オプティマイザは`IndexJoin`選択します。 +- [`44855:ON`](/optimizer-fix-controls.md#44855-new-in-v654-and-v730) : `IndexJoin`演算子の`Probe`側に`Selection`演算子が含まれている場合、オプティマイザは`IndexJoin`を選択します。 - [`52869:ON`](/optimizer-fix-controls.md#52869-new-in-v810) : オプティマイザがクエリ プランに対して (フル テーブル スキャン以外の) 単一のインデックス スキャン メソッドを選択できる場合、オプティマイザは自動的にインデックス マージを選択します。 ### TiKV構成 {#tikv-configurations} diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 2353338e9a656..998abb63f39a9 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -586,7 +586,7 @@ v4.0.9以降のバージョンのTiDBクラスターでは、 TiFlashはスト TiFlashノード上に類似したI/Oメトリックを持つ複数のディスクがある場合は、リスト`storage.main.dir`で対応するディレクトリを指定し、リスト`storage.latest.dir`空のままにすることをお勧めします。TiFlashはI/O負荷とデータをすべてのディレクトリに分散します。 -TiFlashノード上にI/Oメトリックが異なる複数のディスクがある場合は、 `storage.latest.dir`リストにメトリックの高いディレクトリを指定し、 `storage.main.dir`リストにメトリックの低いディレクトリを指定することをお勧めします。例えば、NVMe-SSDが1台とSATA-SSDが2台の場合、 `storage.latest.dir`を`["/nvme_ssd_a/data/tiflash"]`を`storage.main.dir` `["/sata_ssd_b/data/tiflash", "/sata_ssd_c/data/tiflash"]`設定します。TiFlashは、これらの2つのディレクトリリストにそれぞれI/O負荷とデータを分散します。この場合、 `storage.latest.dir`という容量は、計画容量全体の10%として計画する必要があることに注意してください。 +TiFlashノード上にI/Oメトリックが異なる複数のディスクがある場合は、 `storage.latest.dir`リストにメトリックの高いディレクトリを指定し、 `storage.main.dir`リストにメトリックの低いディレクトリを指定することをお勧めします。例えば、NVMe-SSDが1台とSATA-SSDが2台の場合、 `storage.latest.dir`を`["/nvme_ssd_a/data/tiflash"]`に、 `storage.main.dir`を`["/sata_ssd_b/data/tiflash", "/sata_ssd_c/data/tiflash"]`に設定します。TiFlashは、これらの2つのディレクトリリストにそれぞれI/O負荷とデータを分散します。この場合、 `storage.latest.dir`に割り当てる容量は、計画容量全体の10%として計画する必要があることに注意してください。 > **Warning:** > diff --git a/tiflash/tiflash-disaggregated-and-s3.md b/tiflash/tiflash-disaggregated-and-s3.md index 833eda0156cfd..9356fc862228a 100644 --- a/tiflash/tiflash-disaggregated-and-s3.md +++ b/tiflash/tiflash-disaggregated-and-s3.md @@ -128,7 +128,7 @@ TiFlashの分散型ストレージおよびコンピューティングアーキ - 上記の`ACCESS_KEY_ID`と`SECRET_ACCESS_KEY`設定ファイルに直接記述されていることに注意してください。環境変数を使用して個別に設定することもできます。両方の方法で設定した場合、環境変数が優先されます。 - 環境変数を使用して`ACCESS_KEY_ID`と`SECRET_ACCESS_KEY`構成するには、 TiFlashを開始するユーザー環境 (通常は`tidb` ) に切り替え、 `~/.bash_profile`変更して次の構成を追加します。 + 環境変数を使用して`ACCESS_KEY_ID`と`SECRET_ACCESS_KEY`を構成するには、 TiFlashプロセスがデプロイされているすべてのマシンで、TiFlashを開始するユーザー環境 (通常は`tidb` ) に切り替え、 `~/.bash_profile`を変更して次の構成を追加します。 ```shell export S3_ACCESS_KEY_ID={ACCESS_KEY_ID} diff --git a/tikv-control.md b/tikv-control.md index a4d799da6fb61..ad3e7ed38301f 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -408,7 +408,7 @@ tikv-ctl --host ip:port modify-tikv-config -n storage.block-cache.capacity -v 10 success -`shared block cache`が無効の場合は、 `write` CF に`block cache size`設定します。 +`shared block cache`が無効の場合は、 `write` CF に`block cache size`を設定します。 ```shell tikv-ctl --host ip:port modify-tikv-config -n rocksdb.writecf.block-cache-size -v 256MB diff --git a/tiproxy/tiproxy-load-balance.md b/tiproxy/tiproxy-load-balance.md index 163f57e675598..9f3cb210ba834 100644 --- a/tiproxy/tiproxy-load-balance.md +++ b/tiproxy/tiproxy-load-balance.md @@ -40,7 +40,7 @@ TiProxy は、SQL ポートとステータス ポートを使用して、TiDBサ 1. TiProxy で[`balance.label-name`](/tiproxy/tiproxy-configuration.md#label-name)を`"app"`に設定すると、TiDB サーバーはラベル名`"app"`によって照合され、接続は一致するラベル値を持つ TiDB サーバーにルーティングされます。 2. 少なくとも 2 つの TiProxy インスタンスをデプロイ。トランザクション ワークロードに使用する TiProxy インスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "Order"}`に設定し、BI ワークロードに使用するインスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "BI"}`に設定します。 3. オプション：高可用性を実現するには、少なくとも4つのTiProxyインスタンスを導入し、ワークロードごとに異なる仮想IPアドレスを設定します。例えば、トランザクションワークロード用のTiProxyインスタンス2つを仮想IP `10.0.1.10/24`に設定し、BIワークロード用のインスタンス2つを仮想IP `10.0.1.20/24`に設定します。この機能を使用するには、TiProxy v1.3.1以降が必要です。 -4. TiDB インスタンスを 2 つのグループに分割し、それぞれ[`labels`](/tidb-configuration-file.md#labels)設定します。一方のグループに`"app": "Order"`ラベルを追加し、もう一方のグループに`"app": "BI"`ラベルを追加します。 +4. TiDB インスタンスを 2 つのグループに分割し、それぞれ[`labels`](/tidb-configuration-file.md#labels)を設定します。一方のグループに`"app": "Order"`ラベルを追加し、もう一方のグループに`"app": "BI"`ラベルを追加します。 5. オプション:ストレージレイヤーの分離の場合は、 [配置ルール](/configure-placement-rules.md)または[リソース管理](/tidb-resource-control-ru-groups.md)構成します。 6. 仮想IPが設定されている場合、トランザクションクライアントとBIクライアントはそれぞれ2つの仮想IPアドレスに接続します。仮想IPが設定されていない場合、トランザクションクライアントとBIクライアントはそれぞれ2つのTiProxyアドレスに接続します。 diff --git a/tiup/customized-montior-in-tiup-environment.md b/tiup/customized-montior-in-tiup-environment.md index 6bfed9f77e14c..dac4a99eb510a 100644 --- a/tiup/customized-montior-in-tiup-environment.md +++ b/tiup/customized-montior-in-tiup-environment.md @@ -25,7 +25,7 @@ TiUPを使用して TiDB クラスターをデプロイすると、 TiUP はProm 1. ルール構成ファイルをカスタマイズし、 TiUP が配置されているマシンのディレクトリの下に配置します。 -2. topology.yaml ファイルで、カスタマイズされたルール構成ファイルのディレクトリに`rule_dir`設定します。 +2. topology.yaml ファイルで、カスタマイズされたルール構成ファイルのディレクトリに`rule_dir`を設定します。 以下は、topology.yaml ファイル内の monitored_servers の構成例です。 @@ -100,7 +100,7 @@ TiUP v1.17.0 以降では、トポロジーファイルで Prometheus グロー 1. Grafana ダッシュボードの構成ファイルをカスタマイズし、 TiUPが配置されているマシンのディレクトリの下に配置します。 -2. topology.yaml ファイルで、カスタマイズされたダッシュボード構成ファイルのディレクトリに`dashboard_dir`設定します。 +2. topology.yaml ファイルで、カスタマイズされたダッシュボード構成ファイルのディレクトリに`dashboard_dir`を設定します。 以下は、topology.yaml ファイル内の grafana_servers の構成例です。 @@ -138,7 +138,7 @@ TiUP v1.17.0 以降では、トポロジーファイルで Prometheus グロー 現在、 TiUP はAlertmanager のリスニング アドレスのカスタマイズをサポートしています。 -TiUPによってデプロイされた Alertmanager は、デフォルトで`alertmanager_servers.host`をリッスンします。プロキシを使用している場合は Alertmanager にアクセスできません。この問題に対処するには、クラスター設定ファイル topology.yaml に`listen_host`追加してリッスンアドレスを指定します。推奨値は 0.0.0.0 です。 +TiUPによってデプロイされた Alertmanager は、デフォルトで`alertmanager_servers.host`をリッスンします。プロキシを使用している場合は Alertmanager にアクセスできません。この問題に対処するには、クラスター設定ファイル topology.yaml に`listen_host`を追加してリッスンアドレスを指定します。推奨値は 0.0.0.0 です。 次の例では、 `listen_host`フィールドを 0.0.0.0 に設定します。 diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md index b443941baa0b7..97de5b7164283 100644 --- a/tiup/tiup-cluster-no-sudo-mode.md +++ b/tiup/tiup-cluster-no-sudo-mode.md @@ -204,7 +204,7 @@ tiup cluster upgrade mycluster v8.2.0 この問題は、 `/etc/pam.d/system-auth.ued`ファイルに`pam_systemd.so`存在しないために発生する可能性があります。 -この問題を解決するには、次のコマンドを使用して、 `/etc/pam.d/system-auth.ued`ファイルに`pam_systemd.so`モジュールが含まれているかどうかを確認します。含まれていない場合は、ファイルの末尾に`session optional pam_systemd.so`追加します。 +この問題を解決するには、次のコマンドを使用して、 `/etc/pam.d/system-auth.ued`ファイルに`pam_systemd.so`モジュールが含まれているかどうかを確認します。含まれていない場合は、ファイルの末尾に`session optional pam_systemd.so`を追加します。 ```shell grep 'pam_systemd.so' /etc/pam.d/system-auth.ued || echo 'session optional pam_systemd.so' >> /etc/pam.d/system-auth.ued diff --git a/transaction-overview.md b/transaction-overview.md index 1e2aba4660687..235041fa052e4 100644 --- a/transaction-overview.md +++ b/transaction-overview.md @@ -309,7 +309,7 @@ TiDBはデフォルトで線形一貫性を保証します。線形一貫性の | | UPDATE t SET v = 2 WHERE id = 1 | | | COMMIT | -上記の例では、トランザクション1がレコード`id = 1`をロックし、トランザクション2がレコード`id = 1`変更します。したがって、トランザクション1とトランザクション2には潜在的な因果関係があります。因果一貫性が有効になっている場合でも、トランザクション2がトランザクション1のコミット後にコミットされる限り、論理的にはトランザクション2はトランザクション1の後に発生する必要があります。したがって、トランザクション1によるレコード`id = 2`の変更を読み取らずに、トランザクション2によるレコード`id = 1`の変更を読み取るトランザクションは不可能です。 +上記の例では、トランザクション1がレコード`id = 1`をロックし、トランザクション2がレコード`id = 1`を変更します。したがって、トランザクション1とトランザクション2には潜在的な因果関係があります。因果一貫性が有効になっている場合でも、トランザクション2がトランザクション1のコミット後にコミットされる限り、論理的にはトランザクション2はトランザクション1の後に発生する必要があります。したがって、トランザクション1によるレコード`id = 2`の変更を読み取らずに、トランザクション2によるレコード`id = 1`の変更を読み取るトランザクションは不可能です。 ### 因果関係のないトランザクションは、一貫した論理順序と物理的なコミット順序を保証しません。 {#transactions-with-no-causal-relationship-do-not-guarantee-consistent-logical-order-and-physical-commit-order} diff --git a/troubleshoot-data-inconsistency-errors.md b/troubleshoot-data-inconsistency-errors.md index ffe911f23cf67..4bb51209f7bb8 100644 --- a/troubleshoot-data-inconsistency-errors.md +++ b/troubleshoot-data-inconsistency-errors.md @@ -104,8 +104,8 @@ TiDBは、トランザクションまたは[`ADMIN CHECK [TABLE|INDEX]`](/sql-st トランザクション実行時に報告される次のエラーについては、対応するチェックをバイパスできます。 -- エラー 8138、8139、および 8140 のチェックをバイパスするには、 `set @@tidb_enable_mutation_checker=0`設定します。 -- エラー 8141 のチェックをバイパスするには、 `set @@tidb_txn_assertion_level=OFF`設定します。 +- エラー 8138、8139、および 8140 のチェックをバイパスするには、 `set @@tidb_enable_mutation_checker=0`を設定します。 +- エラー 8141 のチェックをバイパスするには、 `set @@tidb_txn_assertion_level=OFF`を設定します。 > **Note:** >