diff --git a/TOC.md b/TOC.md index 302ced2a3d047..61baef5696be9 100644 --- a/TOC.md +++ b/TOC.md @@ -310,7 +310,7 @@ - [`tidb_snapshot`システム変数を使用する](/read-historical-data.md) - [配置ルールを使用する](/configure-placement-rules.md) - [ロードベース分割を使用する](/configure-load-base-split.md) - - [店舗利用制限](/configure-store-limit.md) + - [ストア利用制限](/configure-store-limit.md) - [バッチ処理](/batch-processing.md) - PDマイクロサービスを使用する - [PDマイクロサービスの概要](/pd-microservices.md) diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md index 30991f648821f..d6c30ea601de9 100644 --- a/ai/reference/vector-search-index.md +++ b/ai/reference/vector-search-index.md @@ -20,7 +20,7 @@ aliases: ['/ja/tidb/stable/vector-search-index/','/ja/tidbcloud/vector-search-in ## 制限 {#restrictions} - 事前にTiFlashノードをクラスターにデプロイする必要があります。 -- ベクトル検索インデックスは、主キーまたは一意のインデックスとして使用することはできません。 +- ベクトル検索インデックスは、主キーまたは一意インデックスとして使用することはできません。 - ベクトル検索インデックスは単一のベクトル列にのみ作成でき、他の列 (整数や文字列など) と組み合わせて複合インデックスを形成することはできません。 - ベクトル検索インデックスの作成および使用時には、距離関数を指定する必要があります。現在、コサイン距離`VEC_COSINE_DISTANCE()`とL2距離`VEC_L2_DISTANCE()`の関数のみがサポートされています。 - 同じ列に対して、同じ距離関数を使用して複数のベクトル検索インデックスを作成することはサポートされていません。 diff --git a/auto-increment.md b/auto-increment.md index a5cd53c5ad7ff..c2f2bcbd6f53f 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -114,7 +114,7 @@ INSERT INTO t (c) VALUES (1) 1. クライアントはインスタンス`B`にステートメント`INSERT INTO t VALUES (2, 1)`を挿入し、 `id`を`2`に設定します。ステートメントは正常に実行されます。 -2. クライアントはインスタンス`A`にステートメント`INSERT INTO t (c) (1)`送信します。このステートメントでは`id`の値が指定されていないため、ID は`A`に割り当てられます。現在、 `A` `[1, 30000]`のIDをキャッシュしているため、自動インクリメントIDの値として`2`割り当て、ローカルカウンタを`1`増加させる可能性があります。このとき、ID `2`のデータが既にデータベースに存在するため、 `Duplicated Error`エラーが返されます。 +2. クライアントはインスタンス`A`にステートメント`INSERT INTO t (c) (1)`を送信します。このステートメントでは`id`の値が指定されていないため、ID は`A`に割り当てられます。現在、 `A` `[1, 30000]`のIDをキャッシュしているため、AUTO_INCREMENT IDの値として`2`を割り当て、ローカルカウンタを`1`増加させる可能性があります。このとき、ID `2`のデータが既にデータベースに存在するため、 `Duplicated Error`エラーが返されます。 ### 単調性 {#monotonicity} diff --git a/auto-random.md b/auto-random.md index c56ef10ec5b6a..e8184c3dceb66 100644 --- a/auto-random.md +++ b/auto-random.md @@ -107,13 +107,13 @@ TiDB によって自動的に割り当てられる`AUTO_RANDOM(S, R)`列の値 符号付きビットを持つ`AUTO_RANDOM`値の構造は次のとおりです。 -| 符号付きビット | 予約ビット | 破片の断片 | 自動インクリメントビット | +| 符号付きビット | 予約ビット | シャードビット | AUTO_INCREMENTビット | | ------- | --------- | ------ | ------------ | | 1ビット | `64-R`ビット | `S`ビット | `R-1-S`ビット | 符号付きビットのない`AUTO_RANDOM`値の構造は次のとおりです。 -| 予約ビット | 破片の断片 | 自動インクリメントビット | +| 予約ビット | シャードビット | AUTO_INCREMENTビット | | --------- | ------ | ------------ | | `64-R`ビット | `S`ビット | `R-S`ビット | @@ -121,15 +121,15 @@ TiDB によって自動的に割り当てられる`AUTO_RANDOM(S, R)`列の値 - 符号ビットの長さは、属性`UNSIGNED`有無によって決まります。属性`UNSIGNED`がある場合、長さは`0`です。そうでない場合、長さは`1`です。 - 予約ビットの長さは`64-R`です。予約ビットは常に`0`です。 - シャードビットの内容は、現在のトランザクションの開始時刻のハッシュ値を計算することで得られます。異なるシャードビット長（10など）を使用する場合は、テーブル作成時に`AUTO_RANDOM(10)`指定します。 -- 自動インクリメントビットの値はストレージエンジンに格納され、順次割り当てられます。新しい値が割り当てられるたびに、値は1ずつ増加します。自動インクリメントビットは、 `AUTO_RANDOM`の値がグローバルに一意であることを保証します。自動インクリメントビットが使い果たされると、値が再び割り当てられる際にエラー`Failed to read auto-increment value from storage engine`が報告されます。 -- 値の範囲：最終的に生成される値の最大ビット数 = シャードビット数 + 自動インクリメントビット数。符号付き列の範囲は`[-(2^(R-1))+1, (2^(R-1))-1]` 、符号なし列の範囲は`[0, (2^R)-1]`です。 +- AUTO_INCREMENTビットの値はストレージエンジンに格納され、順次割り当てられます。新しい値が割り当てられるたびに、値は1ずつ増加します。AUTO_INCREMENTビットは、 `AUTO_RANDOM`の値がグローバルに一意であることを保証します。AUTO_INCREMENTビットが使い果たされると、値が再び割り当てられる際にエラー`Failed to read auto-increment value from storage engine`が報告されます。 +- 値の範囲：最終的に生成される値の最大ビット数 = シャードビット数 + AUTO_INCREMENTビット数。符号付き列の範囲は`[-(2^(R-1))+1, (2^(R-1))-1]` 、符号なし列の範囲は`[0, (2^R)-1]`です。 - `AUTO_RANDOM` `PRE_SPLIT_REGIONS`と組み合わせて使用できます。テーブルが正常に作成されると、 `PRE_SPLIT_REGIONS`テーブル内のデータを`2^(PRE_SPLIT_REGIONS)`で指定された数のリージョンに事前に分割します。 > **注記：** > > シャードビットの選択（ `S` ）： > -> - 利用可能なビット数は合計64ビットであるため、シャードビット長は自動インクリメントビット長に影響します。つまり、シャードビット長が増加すると自動インクリメントビット長は減少し、逆もまた同様です。したがって、割り当てられた値のランダム性と利用可能なスペースのバランスをとる必要があります。 +> - 利用可能なビット数は合計64ビットであるため、シャードビット長はAUTO_INCREMENTビット長に影響します。つまり、シャードビット長が増加するとAUTO_INCREMENTビット長は減少し、逆もまた同様です。したがって、割り当てられた値のランダム性と利用可能なスペースのバランスをとる必要があります。 > - ベストプラクティスは、シャードビットを`log(2, x)`に設定することです。ここで、 `x`現在のストレージエンジンの数です。例えば、TiDB クラスターに TiKV ノードが 16 個ある場合、シャードビットを`log(2, 16)` （つまり`4`に設定できます。すべてのリージョンが各 TiKV ノードに均等にスケジュールされると、一括書き込みの負荷が複数の TiKV ノードに均等に分散され、リソース使用率を最大化できます。 > > 範囲の選択（ `R` ）： @@ -161,7 +161,7 @@ SHOW WARNINGS; ## IDの暗黙的な割り当てルール {#implicit-allocation-rules-of-ids} -TiDBは、 `AUTO_INCREMENT`列と同様に、 `AUTO_RANDOM`列にも暗黙的に値を割り当てます。これらの値は、セッションレベルのシステム変数[`auto_increment_increment`](/system-variables.md#auto_increment_increment)と[`auto_increment_offset`](/system-variables.md#auto_increment_offset)によって制御されます。暗黙的に割り当てられた値の自動インクリメントビット（ID）は、式`(ID - auto_increment_offset) % auto_increment_increment == 0`に従います。 +TiDBは、 `AUTO_INCREMENT`列と同様に、 `AUTO_RANDOM`列にも暗黙的に値を割り当てます。これらの値は、セッションレベルのシステム変数[`auto_increment_increment`](/system-variables.md#auto_increment_increment)と[`auto_increment_offset`](/system-variables.md#auto_increment_offset)によって制御されます。暗黙的に割り当てられた値のAUTO_INCREMENTビット（ID）は、式`(ID - auto_increment_offset) % auto_increment_increment == 0`に従います。 ## 自動増分IDキャッシュをクリアする {#clear-the-auto-increment-id-cache} @@ -197,7 +197,7 @@ ALTER TABLE t FORCE AUTO_RANDOM_BASE = 1000; > > `FORCE`使用する場合は、ゼロ以外の正の整数を指定する必要があります。 -どちらのコマンドも、すべてのTiDBノードにおける後続の`AUTO_RANDOM`値生成で使用される自動インクリメントビットの開始点を変更します。すでに割り当てられているIDには影響しません。 +どちらのコマンドも、すべてのTiDBノードにおける後続の`AUTO_RANDOM`値生成で使用されるAUTO_INCREMENTビットの開始点を変更します。すでに割り当てられているIDには影響しません。 ## 制限 {#restrictions} diff --git a/basic-features.md b/basic-features.md index 364cc238e9783..7971905636cc3 100644 --- a/basic-features.md +++ b/basic-features.md @@ -65,12 +65,12 @@ summary: TiDBの機能概要について学びましょう。 | [見えないインデックス](/sql-statements/sql-statement-create-index.md#invisible-index) | Y | Y | Y | Y | Y | Y | Y | | [複合`PRIMARY KEY`](/constraints.md) | Y | Y | Y | Y | Y | Y | Y | | [`CHECK`制約](/constraints.md#check) | Y | Y | Y | N | N | N | N | -| [一意のインデックス](/constraints.md) | Y | Y | Y | Y | Y | Y | Y | -| [整数型の`PRIMARY KEY`に対するクラスタ化インデックス](/clustered-indexes.md) | Y | Y | Y | Y | Y | Y | Y | -| [複合キーまたは非整数キーに対するクラスタ化インデックス](/clustered-indexes.md) | Y | Y | Y | Y | Y | Y | Y | +| [一意インデックス](/constraints.md) | Y | Y | Y | Y | Y | Y | Y | +| [整数型の`PRIMARY KEY`に対するクラスター化インデックス](/clustered-indexes.md) | Y | Y | Y | Y | Y | Y | Y | +| [複合キーまたは非整数キーに対するクラスター化インデックス](/clustered-indexes.md) | Y | Y | Y | Y | Y | Y | Y | | [多値インデックス](/sql-statements/sql-statement-create-index.md#multi-valued-indexes) | Y | Y | Y | Y | N | N | N | | [外部キー](/foreign-key.md) | Y | E | E | E | N | N | N | -| [TiFlashの遅延実現](/tiflash/tiflash-late-materialization.md) | Y | Y | Y | Y | N | N | N | +| [TiFlashの遅延マテリアライゼーション](/tiflash/tiflash-late-materialization.md) | Y | Y | Y | Y | N | N | N | | [グローバルインデックス](/global-indexes.md) | Y | N | N | N | N | N | N | | [ベクトルインデックス](/ai/reference/vector-search-index.md) | E | N | N | N | N | N | N | @@ -145,7 +145,7 @@ summary: TiDBの機能概要について学びましょう。 | [ビュー](/views.md) | Y | Y | Y | Y | Y | Y | Y | | [シーケンス](/sql-statements/sql-statement-create-sequence.md) | Y | Y | Y | Y | Y | Y | Y | | [自動インクリメント](/auto-increment.md) | Y | Y | Y | Y | Y[^4] | Y | Y | -| [自動ランダム](/auto-random.md) | Y | Y | Y | Y | Y | Y | Y | +| [AUTO_RANDOM](/auto-random.md) | Y | Y | Y | Y | Y | Y | Y | | [TTL（Time to Live：生きる時間）](/time-to-live.md) | Y | Y | Y | Y | E | N | N | | [DDLアルゴリズムのアサーション](/sql-statements/sql-statement-alter-table.md) | Y | Y | Y | Y | Y | Y | Y | | マルチスキーマの変更：列の追加 | Y | Y | Y | Y | Y | E | E | diff --git a/basic-sql-operations.md b/basic-sql-operations.md index e73cbf275c80c..08e4f82996f71 100644 --- a/basic-sql-operations.md +++ b/basic-sql-operations.md @@ -115,7 +115,7 @@ CREATE INDEX person_id ON person (id); ALTER TABLE person ADD INDEX person_id (id); ``` -値が一意である列に対して一意のインデックスを作成するには、 `CREATE UNIQUE INDEX`ステートメントを使用します。 +値が一意である列に対して一意インデックスを作成するには、 `CREATE UNIQUE INDEX`ステートメントを使用します。 ```sql CREATE UNIQUE INDEX person_unique_id ON person (id); diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 8f64ad1801525..4ceb0ff28f373 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -8,14 +8,14 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ このドキュメントでは、PDスケジューリングの原則と戦略を、一般的なシナリオを通して詳細に解説し、アプリケーション開発の効率化を図ります。このドキュメントは、TiDB、TiKV、PDの基本的な知識と、以下のコアコンセプトを理解していることを前提としています。 -- [リーダー/フォロワー/学習者](/glossary.md#leaderfollowerlearner) +- [リーダー/フォロワー/ラーナー](/glossary.md#leaderfollowerlearner) - [オペレーター](/glossary.md#operator) - [演算子ステップ](/glossary.md#operator-step) - [保留中/ダウン](/glossary.md#pendingdown) -- [地域/ピア/Raftグループ](/glossary.md#regionpeerraft-group) -- [地域分割](/glossary.md#region-split) +- [リージョン/ピア/Raftグループ](/glossary.md#regionpeerraft-group) +- [リージョン分割](/glossary.md#region-split) - [スケジューラ](/glossary.md#scheduler) -- [店](/glossary.md#store) +- [ストア](/glossary.md#store) > **注記：** > @@ -65,8 +65,8 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ `balance-leader`と`balance-region`は同様のスケジュール プロセスを共有します。 -1. リソースの可用性に応じて店舗を評価します。 -2. `balance-leader`または`balance-region` 、高スコアの店舗から低スコアの店舗へ、リーダーまたは同僚を継続的に異動させます。 +1. リソースの可用性に応じてストアを評価します。 +2. `balance-leader`または`balance-region` 、高スコアのストアから低スコアのストアへ、リーダーまたはピアを継続的に異動させます。 しかし、評価方法は異なります。1 `balance-leader`ストア内のリーダーに対応するすべてのリージョンサイズの合計を使用しますが、 `balance-region`の方法は比較的複雑です。各ノードの具体的なストレージ容量に応じて、 `balance-region`の評価方法は以下のようになります。 @@ -129,9 +129,9 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ **Grafana PD/統計- バランス**ページには、次のような負荷分散に関するメトリックが表示されます。 -- 店舗リーダー/地域スコア: 各店舗のスコア -- 店舗リーダー/地域数: 各店舗のリーダー/地域の数 -- 利用可能な店舗: 各店舗で利用可能なstorage +- ストアリーダー/リージョンスコア: 各ストアのスコア +- ストアリーダー/リージョン数: 各ストアのリーダー/リージョンの数 +- 利用可能なストア: 各ストアで利用可能なストレージ pd-ctl のストア コマンドを使用して、各ストアの残高ステータスを照会できます。 @@ -146,7 +146,7 @@ pd-ctl のストア コマンドを使用して、各ストアの残高ステー - `hot read` : ホット読み取りリージョンを照会する - `hot write` : ホット書き込みリージョンを照会する -- `hot store` : 店舗別にホットリージョンの分布を照会する +- `hot store` : ストア別にホットリージョンの分布を照会する - `region topread [limit]` : 読み取りトラフィックが最も多いリージョンを照会します - `region topwrite [limit]` : 書き込みトラフィックが最も多いリージョンを照会します @@ -196,17 +196,17 @@ pd-ctl の`config show`コマンドを使用してスケジュール設定を確 このセクションでは、いくつかの一般的なシナリオを通じて PD スケジューリング戦略のベスト プラクティスについて説明します。 -### リーダー/地域が均等に分布していない {#leaders-regions-are-not-evenly-distributed} +### リーダー/リージョンが均等に分布していない {#leaders-regions-are-not-evenly-distributed} PDの評価メカニズムでは、異なるストアのリーダー数とリージョン数だけでは負荷分散状況を完全に反映できないと判断されます。そのため、TiKVの実際の負荷やストレージ使用量から、負荷の不均衡が発生しているかどうかを確認する必要があります。 -リーダー/地域が均等に分散されていないことを確認したら、さまざまなストアの評価を確認する必要があります。 +リーダー/リージョンが均等に分散されていないことを確認したら、さまざまなストアの評価を確認する必要があります。 -各店舗のスコアが近い場合、PDはリーダー／地域が均等に分布していると誤って認識していることを意味します。考えられる理由は以下の通りです。 +各ストアのスコアが近い場合、PDはリーダー／リージョンが均等に分布していると誤って認識していることを意味します。考えられる理由は以下の通りです。 - 負荷の不均衡を引き起こすホットリージョンがあります。この場合、 [ホットリージョンのスケジュール](#hot-regions-are-not-evenly-distributed)に基づいてさらに分析する必要があります。 -- 空きリージョンや小さなリージョンが多数存在するため、ストア間でリーダーの数に大きな差が生じ、 Raftストアへの負荷が高くなります。このような状況では、 [地域の統合](#region-merge-is-slow)スケジューリングが適しています。 -- ハードウェアおよびソフトウェア環境は店舗によって異なります。リーダー/リージョンの配分を制御するには、 [負荷分散](#load-balancing)参考にして`leader-weight`と`region-weight`の値を調整してください。 +- 空きリージョンや小さなリージョンが多数存在するため、ストア間でリーダーの数に大きな差が生じ、 Raftストアへの負荷が高くなります。このような状況では、 [リージョンの統合](#region-merge-is-slow)スケジューリングが適しています。 +- ハードウェアおよびソフトウェア環境はストアによって異なります。リーダー/リージョンの配分を制御するには、 [負荷分散](#load-balancing)参考にして`leader-weight`と`region-weight`の値を調整してください。 - その他の不明な理由。ただし、 `leader-weight`と`region-weight`の値を調整することで、リーダー/リージョンの配分を制御することができます。 異なるストア間で評価に大きな差がある場合は、オペレータ関連の指標、特にオペレータの生成と実行に焦点を当てて調査する必要があります。主な状況としては、以下の2つが挙げられます。 @@ -223,14 +223,14 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー - その他の制約。例えば、システム内の制約`evict-leader-scheduler`により、リーダーが対応するストアに移行できない、あるいはラベルプロパティが設定されているため、一部のストアがリーダーを拒否するといった状況です。 - クラスタトポロジによる制約。例えば、3つのデータセンターにまたがる3つのレプリカを持つクラスタでは、レプリカ分離のため、各リージョンの3つのレプリカが異なるデータセンターに分散されます。これらのデータセンター間でストア数が異なる場合、スケジューリングは各データセンター内ではバランスの取れた状態になりますが、グローバルではバランスが取れません。 -### ノードをオフラインにするのは遅い {#taking-nodes-offline-is-slow} +### ノードをオフラインにするのが遅い {#taking-nodes-offline-is-slow} このシナリオでは、関連するメトリックを通じて演算子の生成と実行を調べる必要があります。 オペレーターは正常に生成されたが、スケジュール プロセスが遅い場合は、次の理由が考えられます。 - スケジューリング速度はデフォルトで制限されています。1 または`leader-schedule-limit` `replica-schedule-limit`値を大きく調整できます。同様に、 `max-pending-peer-count`と`max-snapshot-count`の制限を緩和することも検討できます。 -- 他のスケジューリングタスクが同時に実行され、システム内のリソースを奪い合っています。解決策は[リーダー/地域が均等に分布していない](#leadersregions-are-not-evenly-distributed)を参照してください。 +- 他のスケジューリングタスクが同時に実行され、システム内のリソースを奪い合っています。解決策は[リーダー/リージョンが均等に分布していない](#leaders-regions-are-not-evenly-distributed)を参照してください。 - 単一ノードをオフラインにすると、処理対象となるリージョンリーダー（レプリカ3台構成では約1/3）が削除対象のノードに分散されます。そのため、処理速度はこの単一ノードによるスナップショット生成速度によって制限されます。「 `evict-leader-scheduler`を手動で追加することで、リージョンリーダーの移行速度を上げることができます。 対応する演算子の生成に失敗した場合、考えられる理由は次のとおりです。 @@ -238,11 +238,11 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー - オペレータが停止しているか、 `replica-schedule-limit` "0" に設定されます。 - リージョン移行に適したノードが存在しません。例えば、同じラベルの置き換えノードの利用可能な容量が20%未満の場合、PDはそのノードのstorage不足を回避するためにスケジューリングを停止します。このような場合は、ノードを追加するか、データを削除してスペースを解放する必要があります。 -### ノードをオンラインにするのは遅い {#bringing-nodes-online-is-slow} +### ノードをオンラインにするのが遅い {#bringing-nodes-online-is-slow} -現在、ノードのオンライン化はバランスリージョンメカニズムを通じてスケジュールされています。トラブルシューティングについては[リーダー/地域が均等に分布していない](#leadersregions-are-not-evenly-distributed)を参照してください。 +現在、ノードのオンライン化はバランスリージョンメカニズムを通じてスケジュールされています。トラブルシューティングについては[リーダー/リージョンが均等に分布していない](#leaders-regions-are-not-evenly-distributed)を参照してください。 -### 暑い地域は均等に分布していない {#hot-regions-are-not-evenly-distributed} +### ホットリージョンが均等に分布していない {#hot-regions-are-not-evenly-distributed} ホット リージョンのスケジュールの問題は、通常、次のカテゴリに分類されます。 diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md index e5e6cf2983b54..d44bb2d93fdf4 100644 --- a/best-practices/tidb-partitioned-tables-best-practices.md +++ b/best-practices/tidb-partitioned-tables-best-practices.md @@ -348,7 +348,7 @@ ALTER TABLE A DROP PARTITION A_2024363; ## ホットスポットの問題を軽減する {#mitigate-hotspot-issues} -TiDB では、読み取りまたは書き込みトラフィックが[地域](/tidb-storage.md#region)に不均等に分散されている場合にホットスポットが発生します。ホットスポットは、次のような場合によく発生します。 +TiDB では、読み取りまたは書き込みトラフィックが[リージョン](/tidb-storage.md#region)に不均等に分散されている場合にホットスポットが発生します。ホットスポットは、次のような場合によく発生します。 - 単調に増加する主キー ( `AUTO_INCREMENT`主キーと`AUTO_ID_CACHE=1`など)。 - デフォルト値が`CURRENT_TIMESTAMP`である datetime 列のセカンダリ インデックス。 @@ -359,7 +359,7 @@ TiDBは新しい行とインデックスエントリを「右端」のリージ - 読み取りおよび書き込みのレイテンシーが増加し、全体的なスループットが低下します。 - TiKV ノードを追加しても、ボトルネックが単一のリージョンに残るため、パフォーマンスはほとんど向上しません。 -これらの問題を軽減するには、パーティションテーブルを使用できます。プライマリキーにハッシュまたはキーによるパーティション分割を適用することで、TiDB は挿入操作を複数のパーティションとリージョンに分散し、単一のリージョンにおけるホットスポットの競合を軽減します。 +これらの問題を軽減するには、パーティションテーブルを使用できます。主キーにハッシュまたはキーによるパーティション分割を適用することで、TiDB は挿入操作を複数のパーティションとリージョンに分散し、単一のリージョンにおけるホットスポットの競合を軽減します。 > **注記：** > @@ -464,11 +464,11 @@ TiDBでは、新しく作成されたパーティションは、最初は1つの | テーブルタイプ | リージョンの事前分割 | 読み取りパフォーマンス | 書き込みスケーラビリティ | パーティションごとのデータクリーンアップ | | -------------------- | ---------- | ------------ | ------------ | -------------------- | -| 非クラスタ化パーティションテーブル | 自動 | 下位（追加の検索が必要） | 高い | サポートされている | +| 非クラスター化パーティションテーブル | 自動 | 下位（追加の検索が必要） | 高い | サポートされている | | クラスター化されたパーティションテーブル | マニュアル | 高（検索回数が少ない） | 高（手動管理あり） | サポートされている | -| クラスタ化された非パーティションテーブル | 該当なし | 高い | 安定した | サポートされていません | +| クラスター化された非パーティションテーブル | 該当なし | 高い | 安定した | サポートされていません | -### 非クラスタ化パーティションテーブルのソリューション {#solutions-for-non-clustered-partitioned-tables} +### 非クラスター化パーティションテーブルのソリューション {#solutions-for-non-clustered-partitioned-tables} #### 利点 {#advantages} @@ -593,9 +593,9 @@ SHOW TABLE employees PARTITION (p4) regions; #### ベストプラクティス {#best-practices} -新しい範囲パーティションによって発生するホットスポットの問題を軽減するには、 [非クラスタ化パーティションテーブルのベストプラクティス](#best-practices)手順に従います。 +新しい範囲パーティションによって発生するホットスポットの問題を軽減するには、 [非クラスター化パーティションテーブルのベストプラクティス](#best-practices)手順に従います。 -### クラスタ化された非パーティションテーブルのソリューション {#solutions-for-clustered-non-partitioned-tables} +### クラスター化された非パーティションテーブルのソリューション {#solutions-for-clustered-non-partitioned-tables} #### 利点 {#advantages} diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md index 9e370d8217409..f4f31a53d7978 100644 --- a/br/br-pitr-guide.md +++ b/br/br-pitr-guide.md @@ -154,7 +154,7 @@ PITRを実行するには、復元ポイントより前のフルバックアッ - TiKVノード数（8コア、16GBメモリ）: 21 - TiKV構成項目`import.num-threads` ：8 - BRコマンドオプション`pitr-concurrency` ：128 -- 地域数: 183,000 +- リージョン数: 183,000 - クラスターに作成された新しいログデータ: 10 GB/時間 - 書き込み（挿入/更新/削除）QPS: 10,000 diff --git a/clustered-indexes.md b/clustered-indexes.md index 7add87bde4d8e..fa561a845a2ef 100644 --- a/clustered-indexes.md +++ b/clustered-indexes.md @@ -1,36 +1,36 @@ --- title: Clustered Indexes -summary: クラスタ化インデックスの概念、ユーザーシナリオ、使用方法、制限事項、および互換性について学びます。 +summary: クラスター化インデックスの概念、ユーザーシナリオ、使用方法、制限事項、および互換性について学びます。 --- # クラスター化インデックス {#clustered-indexes} -TiDBはバージョン5.0以降、クラスタ化インデックス機能をサポートしています。この機能は、主キーを含むテーブルへのデータの格納方法を制御します。これにより、TiDBは特定のクエリのパフォーマンスを向上させるような方法でテーブルを整理することができます。 +TiDBはバージョン5.0以降、クラスター化インデックス機能をサポートしています。この機能は、主キーを含むテーブルへのデータの格納方法を制御します。これにより、TiDBは特定のクエリのパフォーマンスを向上させるような方法でテーブルを整理することができます。 -この文脈における*「クラスタ化」*という用語は*、データの格納方法の構成を*指し、*連携して動作するデータベースサーバーのグループを*指すものではありません。一部のデータベース管理システムでは、クラスタ化されたインデックステーブルを*インデックス構成テーブル*（IOT）と呼んでいます。 +この文脈における*「クラスター化」*という用語は*、データの格納方法の構成を*指し、*連携して動作するデータベースサーバーのグループを*指すものではありません。一部のデータベース管理システムでは、クラスター化されたインデックステーブルを*インデックス構成テーブル*（IOT）と呼んでいます。 現在、TiDBの主キーを含むテーブルは、以下の2つのカテゴリに分類されます。 -- `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部の[`_tidb_rowid`](/tidb-rowid.md)値で構成されます。主キーは基本的に一意のインデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2 つのキーと値のペアが必要です。それらは次のとおりです。 +- `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部の[`_tidb_rowid`](/tidb-rowid.md)値で構成されます。主キーは基本的に一意インデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2 つのキーと値のペアが必要です。それらは次のとおりです。 - `_tidb_rowid` （キー） - 行データ（値） - 主キーデータ（キー） - `_tidb_rowid` （値） -- `CLUSTERED` : テーブルの主キーはクラスタ化インデックスです。クラスタ化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスタ化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 +- `CLUSTERED` : テーブルの主キーはクラスター化インデックスです。クラスター化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスター化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 - 主キーデータ（キー） - 行データ（値） > **注記：** > -> TiDB は、テーブルの`PRIMARY KEY`によるクラスタリングのみをサポートしています。クラスタ化インデックスが有効になっている場合、 *{* `PRIMARY KEY`と*クラスタ化インデックス*という用語は同じ意味で使用されることがあります。 `PRIMARY KEY`は制約 (論理プロパティ) を指し、クラスタ化インデックスはデータの格納方法の物理的な実装を表します。 +> TiDB は、テーブルの`PRIMARY KEY`によるクラスタリングのみをサポートしています。クラスター化インデックスが有効になっている場合、 *{* `PRIMARY KEY`と*クラスター化インデックス*という用語は同じ意味で使用されることがあります。 `PRIMARY KEY`は制約 (論理プロパティ) を指し、クラスター化インデックスはデータの格納方法の物理的な実装を表します。 ## ユーザーシナリオ {#user-scenarios} クラスター化インデックスを持たないテーブルと比較して、クラスター化インデックスを持つテーブルは、以下のシナリオにおいて、より優れたパフォーマンスとスループットのメリットを提供します。 -- データが挿入される際、クラスタ化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 -- 同等の条件を持つクエリが主キーのみに関係する場合、クラスタ化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 -- 範囲条件を含むクエリが主キーのみに関係する場合、クラスタ化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 -- 同等条件または範囲条件を含むクエリが主キーのプレフィックスのみに関係する場合、クラスタ化インデックスはネットワークからのインデックスデータの複数回の読み取りを削減します。 +- データが挿入される際、クラスター化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 +- 同等の条件を持つクエリが主キーのみに関係する場合、クラスター化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 +- 範囲条件を含むクエリが主キーのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 +- 同等条件または範囲条件を含むクエリが主キーのプレフィックスのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの複数回の読み取りを削減します。 -一方、クラスタ化インデックスを持つテーブルにはいくつかの欠点があります。以下をご覧ください。 +一方、クラスター化インデックスを持つテーブルにはいくつかの欠点があります。以下をご覧ください。 - 値が近い多数の主キーを挿入する場合、書き込みホットスポットの問題が発生する可能性があります。 - 主キーのデータ型が64ビットより大きい場合、特にセカンダリインデックスが複数存在する場合は、テーブルデータがより多くのストレージ容量を消費します。 @@ -39,7 +39,7 @@ TiDBはバージョン5.0以降、クラスタ化インデックス機能をサ ### クラスター化インデックスを持つテーブルを作成する {#create-a-table-with-clustered-indexes} -TiDB v5.0以降では、 `CLUSTERED`の`NONCLUSTERED`の後に、予約語ではないキーワード`PRIMARY KEY`または`CREATE TABLE`を追加することで、テーブルの主キーがクラスタ化インデックスであるかどうかを指定できます。例： +TiDB v5.0以降では、 `CLUSTERED`の`NONCLUSTERED`の後に、予約語ではないキーワード`PRIMARY KEY`または`CREATE TABLE`を追加することで、テーブルの主キーがクラスター化インデックスであるかどうかを指定できます。例： ```sql CREATE TABLE t (a BIGINT PRIMARY KEY CLUSTERED, b VARCHAR(255)); @@ -63,15 +63,15 @@ CREATE TABLE t (a BIGINT, b VARCHAR(255), PRIMARY KEY(a, b) /*T![clustered_index キーワード`CLUSTERED` / `NONCLUSTERED`明示的に指定しないステートメントの場合、デフォルトの動作はシステム変数[`@@global.tidb_enable_clustered_index`](/system-variables.md#tidb_enable_clustered_index-new-in-v50)によって制御されます。この変数でサポートされている値は次のとおりです。 -- `OFF`は、プライマリキーがデフォルトで非クラスター化インデックスとして作成されることを示します。 -- `ON`は、プライマリキーがデフォルトでクラスタ化インデックスとして作成されることを示します。 -- `INT_ONLY`は、動作が構成項目`alter-primary-key`によって制御されることを示します。 `alter-primary-key`が`true`に設定されている場合、プライマリ キーはデフォルトで非クラスタ化インデックスとして作成されます。 `false`に設定されている場合、整数列で構成されるプライマリ キーのみがクラスタ化インデックスとして作成されます。 +- `OFF`は、主キーがデフォルトで非クラスター化インデックスとして作成されることを示します。 +- `ON`は、主キーがデフォルトでクラスター化インデックスとして作成されることを示します。 +- `INT_ONLY`は、動作が構成項目`alter-primary-key`によって制御されることを示します。 `alter-primary-key`が`true`に設定されている場合、プライマリ キーはデフォルトで非クラスター化インデックスとして作成されます。 `false`に設定されている場合、整数列で構成されるプライマリ キーのみがクラスター化インデックスとして作成されます。 `@@global.tidb_enable_clustered_index`のデフォルト値は`ON`です。 ### クラスター化インデックスの追加または削除 {#add-or-drop-clustered-indexes} -TiDB は、テーブル作成後にクラスタ化インデックスを追加または削除することをサポートしていません。また、クラスタ化インデックスと非クラスタ化インデックス間の相互変換もサポートしていません。例: +TiDB は、テーブル作成後にクラスター化インデックスを追加または削除することをサポートしていません。また、クラスター化インデックスと非クラスター化インデックス間の相互変換もサポートしていません。例: ```sql ALTER TABLE t ADD PRIMARY KEY(b, a) CLUSTERED; -- Currently not supported. @@ -90,9 +90,9 @@ ALTER TABLE t DROP PRIMARY KEY; ALTER TABLE t DROP INDEX `PRIMARY`; ``` -### 主キーがクラスタ化インデックスであるかどうかを確認してください。 {#check-whether-the-primary-key-is-a-clustered-index} +### 主キーがクラスター化インデックスであるかどうかを確認してください。 {#check-whether-the-primary-key-is-a-clustered-index} -テーブルの主キーがクラスタ化インデックスであるかどうかは、以下のいずれかの方法で確認できます。 +テーブルの主キーがクラスター化インデックスであるかどうかは、以下のいずれかの方法で確認できます。 - コマンド`SHOW CREATE TABLE`を実行します。 - コマンド`SHOW INDEX FROM`を実行します。 @@ -140,15 +140,15 @@ mysql> SELECT TIDB_PK_TYPE FROM information_schema.tables WHERE table_schema = ' ## 制限事項 {#limitations} -現在、クラスタ化インデックス機能にはいくつかの異なる制限があります。以下を参照してください。 +現在、クラスター化インデックス機能にはいくつかの異なる制限があります。以下を参照してください。 - サポート対象外であり、サポートプランにも含まれていない状況： - クラスター化インデックスと属性[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)を併用することはサポートされていません。また、属性[`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions) [`AUTO_RANDOM`](/auto-random.md)ではないクラスター化インデックスを持つテーブルには適用されません。 - - クラスタ化インデックスを持つテーブルのダウングレードはサポートされていません。そのようなテーブルをダウングレードする必要がある場合は、代わりに論理バックアップツールを使用してデータを移行してください。 + - クラスター化インデックスを持つテーブルのダウングレードはサポートされていません。そのようなテーブルをダウングレードする必要がある場合は、代わりに論理バックアップツールを使用してデータを移行してください。 - まだサポートされていないが、サポート計画に含まれている状況： - - `ALTER TABLE`ステートメントを使用したクラスタ化インデックスの追加、削除、および変更はサポートされていません。 + - `ALTER TABLE`ステートメントを使用したクラスター化インデックスの追加、削除、および変更はサポートされていません。 -クラスタ化インデックスを属性`SHARD_ROW_ID_BITS`と一緒に使用すると、TiDB は次のエラーを報告します。 +クラスター化インデックスを属性`SHARD_ROW_ID_BITS`と一緒に使用すると、TiDB は次のエラーを報告します。 ```sql mysql> CREATE TABLE t (a VARCHAR(255) PRIMARY KEY CLUSTERED) SHARD_ROW_ID_BITS = 3; @@ -159,9 +159,9 @@ ERROR 8200 (HY000): Unsupported shard_row_id_bits for table with primary key as ### 以前のバージョンおよび後のバージョンのTiDBとの互換性 {#compatibility-with-earlier-and-later-tidb-versions} -TiDBは、クラスタ化インデックスを持つテーブルのアップグレードはサポートしていますが、ダウングレードはサポートしていません。つまり、新しいバージョンのTiDBにあるクラスタ化インデックスを持つテーブルのデータは、古いバージョンでは利用できません。 +TiDBは、クラスター化インデックスを持つテーブルのアップグレードはサポートしていますが、ダウングレードはサポートしていません。つまり、新しいバージョンのTiDBにあるクラスター化インデックスを持つテーブルのデータは、古いバージョンでは利用できません。 -クラスタ化インデックス機能は、TiDB v3.0およびv4.0で部分的にサポートされています。以下の要件がすべて満たされている場合、デフォルトで有効になります。 +クラスター化インデックス機能は、TiDB v3.0およびv4.0で部分的にサポートされています。以下の要件がすべて満たされている場合、デフォルトで有効になります。 - テーブルには`PRIMARY KEY`が含まれています。 - `PRIMARY KEY`は 1 つの列のみで構成されています。 @@ -175,7 +175,7 @@ TiDB固有のコメント構文では、キーワード`CLUSTERED`と`NONCLUSTER ### TiDB移行ツールとの互換性 {#compatibility-with-tidb-migration-tools} -クラスタ化インデックス機能は、v5.0以降のバージョンにおいて、以下の移行ツールとのみ互換性があります。 +クラスター化インデックス機能は、v5.0以降のバージョンにおいて、以下の移行ツールとのみ互換性があります。 - バックアップおよび復元ツール： BR、 Dumpling、 TiDB Lightning。 - データ移行およびレプリケーションツール：DMとTiCDC。 @@ -184,7 +184,7 @@ TiDB固有のコメント構文では、キーワード`CLUSTERED`と`NONCLUSTER ### 他のTiDB機能との互換性 {#compatibility-with-other-tidb-features} -結合主キーまたは単一の非整数主キーを持つテーブルの場合、主キーを非クラスタ化インデックスからクラスタ化インデックスに変更すると、行データのキーも変更されます。そのため、TiDB バージョン 5.0 より前のバージョンで実行可能だった`SPLIT TABLE BY/BETWEEN`ステートメントは、TiDB バージョン 5.0 以降では動作しなくなります。 `SPLIT TABLE BY/BETWEEN`を使用してクラスタ化インデックスを持つテーブルを分割する場合は、整数値を指定する代わりに、主キー列の値を指定する必要があります。次の例を参照してください。 +結合主キーまたは単一の非整数主キーを持つテーブルの場合、主キーを非クラスター化インデックスからクラスター化インデックスに変更すると、行データのキーも変更されます。そのため、TiDB バージョン 5.0 より前のバージョンで実行可能だった`SPLIT TABLE BY/BETWEEN`ステートメントは、TiDB バージョン 5.0 以降では動作しなくなります。 `SPLIT TABLE BY/BETWEEN`を使用してクラスター化インデックスを持つテーブルを分割する場合は、整数値を指定する代わりに、主キー列の値を指定する必要があります。次の例を参照してください。 ```sql mysql> create table t (a int, b varchar(255), primary key(a, b) clustered); @@ -209,7 +209,7 @@ mysql> split table t by (0, ''), (50000, ''), (100000, ''); 1 row in set (0.01 sec) ``` -[`AUTO_RANDOM`](/auto-random.md)属性は、クラスタ化インデックスでのみ使用できます。それ以外の場合、TiDBは次のエラーを返します。 +[`AUTO_RANDOM`](/auto-random.md)属性は、クラスター化インデックスでのみ使用できます。それ以外の場合、TiDBは次のエラーを返します。 ```sql mysql> create table t (a bigint primary key nonclustered auto_random); diff --git a/command-line-flags-for-tikv-configuration.md b/command-line-flags-for-tikv-configuration.md index 8f4e812096a65..ce17db04b204d 100644 --- a/command-line-flags-for-tikv-configuration.md +++ b/command-line-flags-for-tikv-configuration.md @@ -45,7 +45,7 @@ TiKV は、コマンドラインパラメータに対していくつかの読み ## --capacity {#code-capacity-code} -- 店舗収容人数 +- ストアキャパシティ - デフォルト: `0` (無制限) - PDはこのフラグを使用して、TiKVサーバーのバランス調整方法を決定します。（ヒント：1073741824の代わりに10GBを使用することもできます） diff --git a/configure-store-limit.md b/configure-store-limit.md index 10eb94546a373..117c443b9c449 100644 --- a/configure-store-limit.md +++ b/configure-store-limit.md @@ -3,7 +3,7 @@ title: Store Limit summary: ストア制限の機能について学びます。 --- -# 店舗制限 {#store-limit} +# ストア制限 {#store-limit} ストア制限はPDの機能です。様々なシナリオにおいてパフォーマンスを向上させるために、スケジューリング速度をより細かく制御できるように設計されています。 @@ -15,11 +15,11 @@ PDはオペレータ単位でスケジューリングを実行します。オペ 上記の例では、 `replace-down-replica`演算子には次の特定の演算が含まれています。 -1. ID `20` ～ `store 3`の学習者ピアを追加します。 -2. ID `20` on `store 3`の学習者ピアを投票者に昇格します。 +1. ID `20` ～ `store 3`のラーナーピアを追加します。 +2. ID `20` on `store 3`のラーナーピアを投票者に昇格します。 3. `store 2`のピアを削除します。 -ストア制限は、ストアIDとトークンバケットのマッピングをメモリ内に保持することで、ストアレベルの速度制限を実現します。ここでの異なる操作は、それぞれ異なるトークンバケットに対応しています。現在、ストア制限は、学習者/ピアの追加とピアの削除という2つの操作の速度制限のみをサポートしています。つまり、各ストアには2種類のトークンバケットがあります。 +ストア制限は、ストアIDとトークンバケットのマッピングをメモリ内に保持することで、ストアレベルの速度制限を実現します。ここでの異なる操作は、それぞれ異なるトークンバケットに対応しています。現在、ストア制限は、ラーナー/ピアの追加とピアの削除という2つの操作の速度制限のみをサポートしています。つまり、各ストアには2種類のトークンバケットがあります。 オペレータが生成されるたびに、そのオペレータはトークンバケットにその操作に必要なトークンが十分にあるかどうかを確認します。十分なトークンがある場合、オペレータはスケジューリングキューに追加され、対応するトークンがトークンバケットから取得されます。十分なトークンがない場合、オペレータは破棄されます。トークンバケットは一定の速度でトークンを補充するため、速度制限はこのように達成されます。 @@ -41,7 +41,7 @@ tiup ctl:v pd store limit add-peer // Shows the tiup ctl:v pd store limit remove-peer // Shows the speed limit of deleting peers in all stores. ``` -### 全店舗の制限を設定する {#set-limit-for-all-stores} +### 全ストアの制限を設定する {#set-limit-for-all-stores} すべてのストアの速度制限を設定するには、次のコマンドを実行します。 @@ -58,7 +58,7 @@ tiup ctl:v pd store limit all engine tikv 5 remove-peer // A tiup ctl:v pd store limit all engine tiflash 5 remove-peer // All TiFlash stores can at most remove 5 peers per minute. ``` -### 単一店舗の制限を設定する {#set-limit-for-a-single-store} +### 単一ストアの制限を設定する {#set-limit-for-a-single-store} 単一のストアに対して速度制限を設定するには、次のコマンドを実行します。 @@ -68,7 +68,7 @@ tiup ctl:v pd store limit 1 5 add-peer // store 1 ca tiup ctl:v pd store limit 1 5 remove-peer // store 1 can at most delete 5 peers per minute. ``` -### 店舗制限の原則 v2 {#principles-of-store-limit-v2} +### ストア制限の原則 v2 {#principles-of-store-limit-v2} [`store-limit-version`](/pd-configuration-file.md#store-limit-version-new-in-v710) `v2`に設定すると、ストア制限 v2 が有効になります。v2 モードでは、オペレーターの制限は TiKV スナップショットの性能に基づいて動的に調整されます。TiKV の保留中のタスクが少なくなると、PD はスケジュールするタスクを増やします。そうでない場合は、PD はノードのスケジュールするタスクを減らします。したがって、スケジュール処理を高速化するために手動で`store limit`設定する必要はありません。 diff --git a/constraints.md b/constraints.md index 3986a99817e0d..6905abc4cbca0 100644 --- a/constraints.md +++ b/constraints.md @@ -40,7 +40,7 @@ INSERT INTO users (id,age,last_login) VALUES (NULL,123,NULL); Query OK, 1 row affected (0.03 sec) - 最初の`INSERT`文は、 `AUTO_INCREMENT`列目に`NULL`割り当てることができるため成功します。TiDBはシーケンス番号を自動的に生成します。 -- 2 番目の`INSERT`ステートメントは、 `age`列目が`NOT NULL`として定義されているため失敗します。 +- 2 番目の`INSERT`ステートメントは、 `age`列が`NOT NULL`として定義されているため失敗します。 - 3番目の`INSERT`文は、 `last_login`列目が明示的に`NOT NULL`として定義されていないため成功します。NULL値はデフォルトで許可されています。 ## チェック {#check} @@ -131,9 +131,9 @@ ALTER TABLE t ALTER CONSTRAINT c1 NOT ENFORCED; - 列（例： `ALTER TABLE t ADD COLUMN a CHECK(a > 0)` ）の追加時に`CHECK`制約を追加することはサポートされていません。この場合、列のみが正常に追加され、TiDBは`CHECK`制約を無視し、エラーを報告しません。 - `ALTER TABLE t CHANGE a b int CHECK(b > 0)`使用して`CHECK`制約を追加することはサポートされていません。この文を実行すると、TiDBはエラーを報告します。 -## ユニークキー {#unique-key} +## 一意キー {#unique-key} -一意制約とは、一意のインデックスと主キー列内のすべての非 NULL 値が一意であることを意味します。 +一意制約とは、一意インデックスと主キー列内のすべての非 NULL 値が一意であることを意味します。 ### 楽観的トランザクション {#optimistic-transactions} @@ -212,7 +212,7 @@ INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill'); ### 悲観的トランザクション {#pessimistic-transactions} -悲観的トランザクションでは、一意のインデックスの挿入または更新を必要とする SQL ステートメントが実行されると、TiDB はデフォルトで`UNIQUE`制約をチェックします。 +悲観的トランザクションでは、一意インデックスの挿入または更新を必要とする SQL ステートメントが実行されると、TiDB はデフォルトで`UNIQUE`制約をチェックします。 ```sql DROP TABLE IF EXISTS users; @@ -304,7 +304,7 @@ INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill'); > > `8147`エラーが発生すると、TiDB は現在のトランザクションをロールバックします。 - 次の例のように、 `INSERT`のステートメントの実行時にTiDBはロックをスキップします。その後、 `DELETE`ステートメントの実行時にTiDBはユニークインデックスをロックし、ユニーク制約をチェックします。そのため、 `DELETE`ステートメントでエラーが報告されます。 + 次の例のように、 `INSERT`のステートメントの実行時にTiDBはロックをスキップします。その後、 `DELETE`ステートメントの実行時にTiDBは一意インデックスをロックし、ユニーク制約をチェックします。そのため、 `DELETE`ステートメントでエラーが報告されます。 ```sql SET tidb_constraint_check_in_place_pessimistic = OFF; diff --git a/dashboard/dashboard-key-visualizer.md b/dashboard/dashboard-key-visualizer.md index ddcaaa0530799..a46ff43587d32 100644 --- a/dashboard/dashboard-key-visualizer.md +++ b/dashboard/dashboard-key-visualizer.md @@ -1,6 +1,6 @@ --- title: Key Visualizer Page -summary: TiDBダッシュボードのKey Visualizerページでは、TiDBクラスタ内のトラフィックのホットスポットを分析およびトラブルシューティングできます。トラフィックの変化を時間経過とともに視覚的に表示し、特定の期間または地域範囲を拡大表示できます。また、明るさの調整、指標の選択、ヒートマップの更新などの設定も行えます。一般的なヒートマップの種類を特定し、ホットスポットの問題に対処するためのソリューションを提供します。 +summary: TiDBダッシュボードのKey Visualizerページでは、TiDBクラスタ内のトラフィックのホットスポットを分析およびトラブルシューティングできます。トラフィックの変化を時間経過とともに視覚的に表示し、特定の期間またはリージョン範囲を拡大表示できます。また、明るさの調整、指標の選択、ヒートマップの更新などの設定も行えます。一般的なヒートマップの種類を特定し、ホットスポットの問題に対処するためのソリューションを提供します。 --- # キービジュアライザーページ {#key-visualizer-page} @@ -170,7 +170,7 @@ Key Visualizer を開くと、デフォルトで過去 6 時間のデータベ 上のヒートマップには明るい線が見られます。これは、データの読み取りまたは書き込みがシーケンシャルであることを意味します。シーケンシャルなデータの読み取りまたは書き込みの典型的なシナリオは、データのインポートやテーブルとインデックスのスキャンです。例えば、自動インクリメントIDを持つテーブルにデータを継続的に書き込む場合などです。 -明るいエリアにあるリージョンは、読み取りおよび書き込みトラフィックのホットスポットであり、多くの場合、クラスター全体のパフォーマンスのボトルネックとなります。このような状況では、アプリケーションのプライマリキーを再調整する必要があるかもしれません。これにより、リージョンを可能な限り分散させ、負荷を複数のリージョンに分散させることができます。また、アプリケーションタスクを低ピーク時にスケジュールすることもできます。 +明るいエリアにあるリージョンは、読み取りおよび書き込みトラフィックのホットスポットであり、多くの場合、クラスター全体のパフォーマンスのボトルネックとなります。このような状況では、アプリケーションの主キーを再調整する必要があるかもしれません。これにより、リージョンを可能な限り分散させ、負荷を複数のリージョンに分散させることができます。また、アプリケーションタスクを低ピーク時にスケジュールすることもできます。 > **注記：** > diff --git a/data-type-json.md b/data-type-json.md index 8b2c07859f3c1..aa638502e2fff 100644 --- a/data-type-json.md +++ b/data-type-json.md @@ -10,7 +10,7 @@ TiDBは、半構造化データの保存に便利な`JSON` （JavaScript Object - シリアル化にはバイナリ形式を使用します。内部形式により、 `JSON`ドキュメント要素への高速な読み取りアクセスが可能になります。 - `JSON`列に保存されたJSONドキュメントを自動検証します。有効なドキュメントのみを保存できます。 -`JSON`列は、他のバイナリ タイプの列と同様に直接インデックス付けされませんが、生成された列の形式で`JSON`ドキュメント内のフィールドをインデックス付けできます。 +`JSON`列は、他のバイナリ型の列と同様に直接インデックス付けされませんが、生成された列の形式で`JSON`ドキュメント内のフィールドをインデックス付けできます。 ```sql CREATE TABLE city ( diff --git a/develop/dev-guide-create-table.md b/develop/dev-guide-create-table.md index ddf172233f09f..5a9770d08f350 100644 --- a/develop/dev-guide-create-table.md +++ b/develop/dev-guide-create-table.md @@ -101,11 +101,11 @@ CREATE TABLE `bookshop`.`books` ( > **注記：** > -> TiDBにおける**プライマリキー**のデフォルト定義は、 [InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html) （MySQLの一般的なストレージエンジン）における定義とは異なります。 +> TiDBにおける**主キー**のデフォルト定義は、 [InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html) （MySQLの一般的なストレージエンジン）における定義とは異なります。 > -> - **InnoDB**では、**プライマリキー**は一意であり、nullではなく、**インデックスはクラスタ化されています**。 +> - **InnoDB**では、**主キー**は一意であり、nullではなく、**インデックスはクラスター化されています**。 > -> - TiDBでは、**プライマリキー**は一意であり、NULLであってはなりません。ただし、プライマリキーが**クラスタ化インデックス**であることは保証されていません。代わりに、別のキーワードセット`CLUSTERED` / `NONCLUSTERED`によって、**プライマリキーが****クラスタ化インデックス**であるかどうかが制御されます。キーワードが指定されていない場合は、システム変数`@@global.tidb_enable_clustered_index`によって制御されます（化を参照[クラスター化インデックス](https://docs.pingcap.com/tidb/stable/clustered-indexes)。 +> - TiDBでは、**主キー**は一意であり、NULLであってはなりません。ただし、主キーが**クラスター化インデックス**であることは保証されていません。代わりに、別のキーワードセット`CLUSTERED` / `NONCLUSTERED`によって、**主キーが****クラスター化インデックス**であるかどうかが制御されます。キーワードが指定されていない場合は、システム変数`@@global.tidb_enable_clustered_index`によって制御されます（[クラスター化インデックス](https://docs.pingcap.com/tidb/stable/clustered-indexes)に記載のとおり）。 **主キー**は`CREATE TABLE`ステートメントで定義されます。[主キー制約](/constraints.md#primary-key)制約付き列すべてに NULL 以外の値のみが含まれることを要求します。 @@ -130,21 +130,21 @@ CREATE TABLE `bookshop`.`users` ( TiDB は v5.0 以降、[クラスター化インデックス](/clustered-indexes.md)機能をサポートしています。この機能は、主キーを含むテーブルにデータを格納する方法を制御します。これにより、特定のクエリのパフォーマンスを向上できる方法でテーブルを編成する機能が TiDB に提供されます。 -この文脈における「クラスタ化」という用語は、データの格納方法の構成を指し、連携して動作するデータベースサーバーのグループを指すものではありません。一部のデータベース管理システムでは、クラスタ化されたインデックステーブルをインデックス構成テーブル（IOT）と呼んでいます。 +この文脈における「クラスター化」という用語は、データの格納方法の構成を指し、連携して動作するデータベースサーバーのグループを指すものではありません。一部のデータベース管理システムでは、クラスター化されたインデックステーブルをインデックス構成テーブル（IOT）と呼んでいます。 現在、TiDBの***主キーを含む***テーブルは、以下の2つのカテゴリに分類されます。 -- `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部`_tidb_rowid`で構成されます。主キーは基本的に一意のインデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2 つのキーと値のペアが必要です。それらは次のとおりです。 +- `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部`_tidb_rowid`で構成されます。主キーは基本的に一意インデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2 つのキーと値のペアが必要です。それらは次のとおりです。 - `_tidb_rowid` （キー） - 行データ（値） - 主キーデータ（キー） - `_tidb_rowid` （値） -- `CLUSTERED` : テーブルの主キーはクラスタ化インデックスです。クラスタ化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスタ化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 +- `CLUSTERED` : テーブルの主キーはクラスター化インデックスです。クラスター化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスター化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 - 主キーデータ（キー） - 行データ（値） -[プライマリキーを選択](#select-primary-key)で説明されているように、**クラスター化インデックス**は TiDB でキーワード`CLUSTERED`および`NONCLUSTERED`を使用して制御されます。 +[主キーを選択](#select-primary-key)で説明されているように、**クラスター化インデックス**は TiDB でキーワード`CLUSTERED`および`NONCLUSTERED`を使用して制御されます。 > **注記：** > -> TiDB は、テーブルの`PRIMARY KEY`によるクラスタリングのみをサポートしています。クラスタ化インデックスが有効になっている場合、 *{* `PRIMARY KEY`と*クラスタ化インデックス*という用語は同じ意味で使用されることがあります。 `PRIMARY KEY`は制約 (論理プロパティ) を指し、クラスタ化インデックスはデータの格納方法の物理的な実装を表します。 +> TiDB は、テーブルの`PRIMARY KEY`によるクラスタリングのみをサポートしています。クラスター化インデックスが有効になっている場合、 *{* `PRIMARY KEY`と*クラスター化インデックス*という用語は同じ意味で使用されることがあります。 `PRIMARY KEY`は制約 (論理プロパティ) を指し、クラスター化インデックスはデータの格納方法の物理的な実装を表します。 [クラスター化インデックスを選択するためのガイドライン](#guidelines-to-follow-when-selecting-clustered-index)ためのガイドラインに従って、次の例では、 `books`と`users` } の間の関連付けを持つテーブルを作成します。これは、 `ratings` `book`を表します。 `users` .この例では、テーブルを作成し、 `book_id`と`user_id`を使用して複合主キーを構築し、その**主キー**に**クラスター化インデックス**を作成します。 @@ -160,7 +160,7 @@ CREATE TABLE `bookshop`.`ratings` ( ## 列制約を追加する {#add-column-constraints} -[主キー制約](#select-primary-key)に加えて、TiDB は[NULL不可](/constraints.md#not-null)制約、[ユニークキー](/constraints.md#unique-key)制約、および`DEFAULT`などの他の**列制約**もサポートします。完全な制約については、 [TiDBの制約](/constraints.md)ドキュメントを参照してください。 +[主キー制約](#select-primary-key)に加えて、TiDB は[NULL不可](/constraints.md#not-null)制約、[一意キー](/constraints.md#unique-key)制約、および`DEFAULT`などの他の**列制約**もサポートします。完全な制約については、 [TiDBの制約](/constraints.md)ドキュメントを参照してください。 ### デフォルト値を設定する {#set-default-value} @@ -340,7 +340,7 @@ SHOW TABLES IN `bookshop`; - 列のサポート[データ型](/data-type-overview.md)を確認し、データ型の制約に従ってデータを整理してください。列に格納するデータに適した型を選択してください。 - 主キーの選択に関する[従うべきガイドライン](#guidelines-to-follow-when-selecting-primary-key)を確認し、主キー列を使用するかどうかを決定します。 -- クラスタ化インデックスを選択するための[従うべきガイドライン](#guidelines-to-follow-when-selecting-clustered-index)ガイドラインを確認し、**クラスタ化インデックス**を指定するかどうかを決定してください。 +- クラスター化インデックスを選択するための[従うべきガイドライン](#guidelines-to-follow-when-selecting-clustered-index)ガイドラインを確認し、**クラスター化インデックス**を指定するかどうかを決定してください。 - [列制約を追加する](#add-column-constraints)チェックし、列に制約を追加するかどうかを決定します。 - 意味のある列名を使用してください。会社または組織のテーブル命名規則に従うことをお勧めします。会社または組織に対応する命名規則がない場合は、 [列名の命名規則](/develop/dev-guide-object-naming-guidelines.md#column-naming-convention)を参照してください。 @@ -359,10 +359,10 @@ SHOW TABLES IN `bookshop`; - **クラスター化インデックス**を構築するには、 [主キーの選択に関するガイドライン](#guidelines-to-follow-when-selecting-primary-key)に従ってください。 - クラスター化インデックスを持たないテーブルと比較して、クラスター化インデックスを持つテーブルは、以下のシナリオにおいて、より優れたパフォーマンスとスループットのメリットを提供します。 - - データが挿入される際、クラスタ化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 - - 同等の条件を持つクエリが主キーのみに関係する場合、クラスタ化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 - - 範囲条件を含むクエリが主キーのみに関係する場合、クラスタ化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 - - 同等条件または範囲条件を含むクエリが主キーのプレフィックスのみに関係する場合、クラスタ化インデックスはネットワークからのインデックスデータの複数回の読み取りを削減します。 + - データが挿入される際、クラスター化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 + - 同等の条件を持つクエリが主キーのみに関係する場合、クラスター化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 + - 範囲条件を含むクエリが主キーのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 + - 同等条件または範囲条件を含むクエリが主キーのプレフィックスのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの複数回の読み取りを削減します。 - 一方、クラスター化インデックスを持つテーブルには、次のような問題が発生する可能性があります。 - 近い値を持つ主キーを多数挿入すると、書き込みホットスポットの問題が発生する可能性があります。 [主キーを選択する際に従うべきガイドライン](#guidelines-to-follow-when-selecting-primary-key)てください。 diff --git a/develop/dev-guide-object-naming-guidelines.md b/develop/dev-guide-object-naming-guidelines.md index 7fa45646cc8dd..5a302885119e7 100644 --- a/develop/dev-guide-object-naming-guidelines.md +++ b/develop/dev-guide-object-naming-guidelines.md @@ -42,7 +42,7 @@ aliases: ['/ja/tidb/stable/dev-guide-object-naming-guidelines/','/ja/tidbcloud/d ## インデックスの命名規則 {#index-naming-convention} - 主キーインデックス: `pk_{table_name_abbreviation}_{field_name_abbreviation}` -- ユニークインデックス: `uk_{table_name_abbreviation}_{field_name_abbreviation}` +- 一意インデックス: `uk_{table_name_abbreviation}_{field_name_abbreviation}` - 共通インデックス: `idx_{table_name_abbreviation}_{field_name_abbreviation}` - 複数の単語を含むカラム名: 意味のある略語を使用してください diff --git a/develop/dev-guide-paginate-results.md b/develop/dev-guide-paginate-results.md index 7507ff971935b..b6956c2d29059 100644 --- a/develop/dev-guide-paginate-results.md +++ b/develop/dev-guide-paginate-results.md @@ -71,7 +71,7 @@ public List getLatestBooksPage(Long pageNumber, Long pageSize) throws SQLE ## 単一フィールドの主キーテーブルのページングバッチ {#paging-batches-for-single-field-primary-key-tables} -通常、主キーまたは一意のインデックスを使用して結果をソートし、 `LIMIT`句の`offset`キーワードを使用して指定した行数でページを分割するページネーションSQL文を記述できます。その後、ページは独立したトランザクションにラップされ、柔軟なページング更新を実現します。ただし、欠点も明らかです。主キーまたは一意のインデックスをソートする必要があるため、オフセットが大きいほど、特にデータ量が多い場合は、より多くのコンピューティングリソースを消費します。 +通常、主キーまたは一意インデックスを使用して結果をソートし、 `LIMIT`句の`offset`キーワードを使用して指定した行数でページを分割するページネーションSQL文を記述できます。その後、ページは独立したトランザクションにラップされ、柔軟なページング更新を実現します。ただし、欠点も明らかです。主キーまたは一意インデックスをソートする必要があるため、オフセットが大きいほど、特にデータ量が多い場合は、より多くのコンピューティングリソースを消費します。 以下に、より効率的なページング バッチ処理方法を紹介します。 diff --git a/develop/dev-guide-schema-design-overview.md b/develop/dev-guide-schema-design-overview.md index 1a830f9df6736..7f36ee09a4ae4 100644 --- a/develop/dev-guide-schema-design-overview.md +++ b/develop/dev-guide-schema-design-overview.md @@ -41,10 +41,10 @@ TiDBには`test`という名前のデフォルトデータベースが付属し > **注記：** > -> TiDBでは、**プライマリキー**のデフォルト定義は[InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html) （MySQLの一般的なストレージエンジン）とは異なります。 +> 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)参照してください。 +> - InnoDBでは、**主キー**の定義は一意であり、nullではなく、**クラスター化されたインデックス**です。 +> - TiDB では、**プライマリ キー**の定義は一意であり、NULL ではありません。ただし、プライマリ キーが**クラスター化インデックス**であるとは限りません。プライマリ キーがクラスター化インデックスであるかどうかを指定するには、 `CLUSTERED`ステートメントの`NONCLUSTERED`の後に、予約されていないキーワード`PRIMARY KEY`または`CREATE TABLE`追加します。ステートメントでこれらのキーワードが明示的に指定されていない場合、デフォルトの動作はシステム変数`@@global.tidb_enable_clustered_index`によって制御されます。詳細については、[クラスター化インデックス](/clustered-indexes.md)参照してください。 #### 専門索引 {#specialized-indexes} diff --git a/develop/dev-guide-vector-search.md b/develop/dev-guide-vector-search.md index bd7aa5dd7986a..6dd304962e9b9 100644 --- a/develop/dev-guide-vector-search.md +++ b/develop/dev-guide-vector-search.md @@ -49,7 +49,7 @@ RAG シナリオでの検索品質を向上させるには、ベクトル検索 ベクトル検索を実装する前に、次の制限事項に注意してください。 - ベクトルあたり最大16383次元 -- ベクトル列は主キー、一意のインデックス、パーティション キーとして使用することはできません。 +- ベクトル列は主キー、一意インデックス、パーティション キーとして使用することはできません。 - ベクトルと他のデータ型間の直接キャストは行いません（文字列を中間として使用します） 完全なリストについては、 [ベクトル検索の制限](/ai/reference/vector-search-limitations.md)参照してください。 diff --git a/dm/dm-glossary.md b/dm/dm-glossary.md index ddfc3b99136aa..6dc4f177af5af 100644 --- a/dm/dm-glossary.md +++ b/dm/dm-glossary.md @@ -94,7 +94,7 @@ TiDB データ移行ツールを使用して、上流データベースの**増 ### セーフモード {#safe-mode} -セーフモードは、テーブルスキーマに主キーまたは一意のインデックスが存在する場合に、DML文を複数回インポートできるモードです。このモードでは、上流の文の一部は、書き換えられた後にのみ下流に移行されます。1 `INSERT`文は`REPLACE`に書き換えられ、 `UPDATE`文は`DELETE`と`REPLACE`に書き換えられます。 +セーフモードは、テーブルスキーマに主キーまたは一意インデックスが存在する場合に、DML文を複数回インポートできるモードです。このモードでは、上流の文の一部は、書き換えられた後にのみ下流に移行されます。1 `INSERT`文は`REPLACE`に書き換えられ、 `UPDATE`文は`DELETE`と`REPLACE`に書き換えられます。 このモードは、次のいずれかの状況で有効になります。 diff --git a/dm/dm-precheck.md b/dm/dm-precheck.md index d549a21e7777b..4b184253c1ee6 100644 --- a/dm/dm-precheck.md +++ b/dm/dm-precheck.md @@ -80,7 +80,7 @@ tiup dmctl check-task ./task.yaml - カラムの順序 - カラムタイプ - 主キー - - 一意のインデックス + - 一意インデックス - 楽観的モードでは、すべてのシャードテーブルのスキーマが[楽観的相性](https://github.com/pingcap/tiflow/blob/release-8.5/dm/docs/RFCS/20191209_optimistic_ddl.md#modifying-column-types)を満たしているかどうかを確認します。 diff --git a/dm/dm-safe-mode.md b/dm/dm-safe-mode.md index 0d4a06ac7ff0d..86d8b63888e97 100644 --- a/dm/dm-safe-mode.md +++ b/dm/dm-safe-mode.md @@ -143,7 +143,7 @@ REPLACE INTO dummydb.dummytbl (id, int_value, ...) VALUES (123, 888999, ...); - 安全上の理由から、レプリケーションプロセス全体を通してセーフモードを有効にする場合は、以下の点に注意してください。 - **セーフモードでの増分レプリケーションは、余分なオーバーヘッドを消費します。** `DELETE` + `REPLACE`操作が頻繁に行われると、主キーまたは一意インデックスが頻繁に変更されるため、 `UPDATE`ステートメントのみを実行する場合よりもパフォーマンスのオーバーヘッドが大きくなります。 -- **セーフモードでは、同じプライマリキーを持つレコードの置換が強制されるため、ダウンストリームでデータ損失が発生する可能性があります。**アップストリームからダウンストリームへシャードをマージおよび移行する際に、設定が誤っていると、多数のプライマリキーまたはユニークキーの競合が発生する可能性があります。このような状況でセーフモードが有効になっている場合、ダウンストリームでは例外が表示されないまま大量のデータが失われ、深刻なデータ不整合が発生する可能性があります。 +- **セーフモードでは、同じ主キーを持つレコードの置換が強制されるため、ダウンストリームでデータ損失が発生する可能性があります。**アップストリームからダウンストリームへシャードをマージおよび移行する際に、設定が誤っていると、多数の主キーまたは一意キーの競合が発生する可能性があります。このような状況でセーフモードが有効になっている場合、ダウンストリームでは例外が表示されないまま大量のデータが失われ、深刻なデータ不整合が発生する可能性があります。 - **セーフモードは、競合を検出するために主キーまたは一意インデックスに依存します。**ダウンストリームテーブルに主キーまたは一意インデックスがない場合、DM は`REPLACE`を使用してレコードを置換および挿入できません。この場合、セーフモードが有効になっていて、DM が`INSERT`ステートメントを`REPLACE`に書き換えたとしても、重複レコードがダウンストリームに挿入されます。 要約すると、上流のデータベースに重複した主キーを持つデータが存在し、アプリケーションが重複レコードの損失とパフォーマンスのオーバーヘッドを許容できる場合、セーフモードを有効にしてデータの重複を無視することができます。 diff --git a/dm/dm-tune-configuration.md b/dm/dm-tune-configuration.md index 3f795f71a494c..d54905ede7989 100644 --- a/dm/dm-tune-configuration.md +++ b/dm/dm-tune-configuration.md @@ -13,7 +13,7 @@ summary: データ移行タスクの構成を最適化して、データ移行 ### rows {#code-rows-code} -`rows`オプションを設定すると、マルチスレッドを使用して単一テーブルから同時にデータをエクスポートできます。3 `rows`値は、エクスポートされる各チャンクに含まれる行の最大数です。このオプションを有効にすると、MySQL 単一テーブルのデータを同時にエクスポートする際に、DM は分割ベンチマークとして列を選択します。この列は、主キー列、一意のインデックス列、通常のインデックス列（優先度の高いものから`BIGINT`ものの順）のいずれかになります。この列`MEDIUMINT`整数型（例： `INT` ）であることを確認してください。 +`rows`オプションを設定すると、マルチスレッドを使用して単一テーブルから同時にデータをエクスポートできます。3 `rows`値は、エクスポートされる各チャンクに含まれる行の最大数です。このオプションを有効にすると、MySQL 単一テーブルのデータを同時にエクスポートする際に、DM は分割ベンチマークとして列を選択します。この列は、主キー列、一意インデックス列、通常のインデックス列（優先度の高いものから`BIGINT`ものの順）のいずれかになります。この列`MEDIUMINT`整数型（例： `INT` ）であることを確認してください。 `rows`の値は 10000 まで設定できます。この値は、テーブルの総行数とデータベースのパフォーマンスに応じて変更できます。また、同時実行スレッド数を制御するには`threads`設定する必要があります。デフォルトでは`threads`の値は 4 です。この値は必要に応じて調整できます。 diff --git a/dm/shard-merge-best-practices.md b/dm/shard-merge-best-practices.md index 6340310e55c18..c00216af10616 100644 --- a/dm/shard-merge-best-practices.md +++ b/dm/shard-merge-best-practices.md @@ -26,13 +26,13 @@ summary: シャードマージのシナリオにおけるデータ移行のベ - シャーディング DDL ロックの自動解放の失敗が[異常なシナリオを列挙した](/dm/manually-handling-sharding-ddl-locks.md#supported-scenarios)の 1 つである場合は、対応する手動ソリューションに従ってシナリオを処理します。 - サポートされていないシナリオの場合は、データ移行タスク全体をやり直します。まず、ダウンストリーム データベースのデータと移行タスクに関連付けられた`dm_meta`情報を空にし、次に、完全および増分データ レプリケーションを再実行します。 -## 複数のシャードテーブル間の主キーまたは一意のインデックス間の競合を処理する {#handle-conflicts-between-primary-keys-or-unique-indexes-across-multiple-sharded-tables} +## 複数のシャードテーブル間の主キーまたは一意インデックス間の競合を処理する {#handle-conflicts-between-primary-keys-or-unique-indexes-across-multiple-sharded-tables} -複数のシャードテーブルのデータにより、主キーまたは一意のインデックス間で競合が発生する可能性があります。シャードテーブルのシャーディングロジックに基づいて、それぞれの主キーまたは一意のインデックスを確認する必要があります。以下は、主キーまたは一意のインデックスに関連する3つのケースです。 +複数のシャードテーブルのデータにより、主キーまたは一意インデックス間で競合が発生する可能性があります。シャードテーブルのシャーディングロジックに基づいて、それぞれの主キーまたは一意インデックスを確認する必要があります。以下は、主キーまたは一意インデックスに関連する3つのケースです。 - シャード キー: 通常、同じシャード キーは 1 つのシャード テーブルにのみ存在するため、シャード キーでデータの競合は発生しません。 - 自動インクリメント主キー：各シャードテーブルの自動インクリメント主キーは個別にカウントされるため、範囲が重複する可能性があります。この場合、次のセクション[自動増分主キーの競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-of-auto-increment-primary-key)を参照して解決してください。 -- その他の主キーまたは一意のインデックスについては、ビジネスロジックに基づいて分析する必要があります。データの競合が発生した場合は、次のセクション[自動増分主キーの競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-of-auto-increment-primary-key)を参照して解決してください。 +- その他の主キーまたは一意インデックスについては、ビジネスロジックに基づいて分析する必要があります。データの競合が発生した場合は、次のセクション[自動増分主キーの競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-of-auto-increment-primary-key)を参照して解決してください。 ## 自動増分主キーの競合を処理する {#handle-conflicts-of-auto-increment-primary-key} diff --git a/dynamic-config.md b/dynamic-config.md index fac4974e4c265..68a786f86057e 100644 --- a/dynamic-config.md +++ b/dynamic-config.md @@ -126,7 +126,7 @@ show warnings; | `raftstore.split-region-check-tick-interval` | リージョン分割が必要かどうかを確認する時間間隔 | | `raftstore.region-split-check-diff` | リージョン分割前にリージョンデータが超過できる最大値 | | `raftstore.pd-heartbeat-tick-interval` | PDへのリージョンのハートビートがトリガーされる時間間隔 | -| `raftstore.pd-store-heartbeat-tick-interval` | 店舗のPDへのハートビートがトリガーされる時間間隔 | +| `raftstore.pd-store-heartbeat-tick-interval` | ストアのPDへのハートビートがトリガーされる時間間隔 | | `raftstore.snap-mgr-gc-tick-interval` | 期限切れのスナップショットファイルのリサイクルがトリガーされる時間間隔 | | `raftstore.snap-gc-timeout` | スナップショットファイルが保存される最長時間 | | `raftstore.lock-cf-compact-interval` | TiKVがロックカラムファミリーの手動圧縮をトリガーする時間間隔 | @@ -229,7 +229,7 @@ show warnings; | `split.byte-threshold` | リージョンで`load-base-split`実行するためのしきい値。リージョンの読み取りリクエストのトラフィックが10秒間連続して`byte-threshold`を超える場合、このリージョンは分割されます。 | | `split.region-cpu-overload-threshold-ratio` | リージョンで`load-base-split`実行するためのしきい値。リージョンの統合読み取りプールのCPU使用率が10秒連続で`region-cpu-overload-threshold-ratio`を超えた場合、このリージョンは分割されます。(v6.2.0以降でサポート) | | `split.split-balance-score` | `load-base-split`というパラメータは、2つの分割されたリージョンの負荷が可能な限り均等になるようにします。値が小さいほど、負荷は均等になります。ただし、値が小さすぎると分割が失敗する可能性があります。 | -| `split.split-contained-score` | パラメータは`load-base-split`です。値が小さいほど、リージョン分割後の地域間訪問数が少なくなります。 | +| `split.split-contained-score` | パラメータは`load-base-split`です。値が小さいほど、リージョン分割後のリージョン間アクセス数が少なくなります。 | | `cdc.min-ts-interval` | 解決されたTSが転送される時間間隔 | | `cdc.old-value-cache-memory-quota` | TiCDC 古い値のエントリが占有するメモリの上限 | | `cdc.sink-memory-quota` | TiCDCデータ変更イベントが占有するメモリの上限 | @@ -275,15 +275,15 @@ Query OK, 0 rows affected (0.01 sec) | `schedule.max-pending-peer-count` | 単一ストア内の保留中のピアの最大数を決定します | | `schedule.max-store-down-time` | PDが切断されたストアを回復できないと判断するまでのダウンタイム | | `schedule.max-store-preparing-time` | ストアがオンラインになるまでの最大待ち時間を制御します | -| `schedule.leader-schedule-policy` | Leaderのスケジュールポリシーを決定する | -| `schedule.leader-schedule-limit` | 同時に実行されるLeaderスケジュールタスクの数 | +| `schedule.leader-schedule-policy` | リーダーのスケジュールポリシーを決定する | +| `schedule.leader-schedule-limit` | 同時に実行されるリーダースケジュールタスクの数 | | `schedule.region-schedule-limit` | 同時に実行されるリージョンスケジュールタスクの数 | | `schedule.replica-schedule-limit` | 同時に実行されるレプリカスケジュールタスクの数 | | `schedule.merge-schedule-limit` | 同時に実行される`Region Merge`スケジュールタスクの数 | | `schedule.hot-region-schedule-limit` | 同時に実行されるホットリージョンスケジューリングタスクの数 | | `schedule.hot-region-cache-hits-threshold` | リージョンがホットスポットとみなされる閾値を決定します | -| `schedule.high-space-ratio` | 店舗の収容能力が十分である閾値比率 | -| `schedule.low-space-ratio` | 店舗の収容能力が不足する閾値比率 | +| `schedule.high-space-ratio` | ストアの収容能力が十分である閾値比率 | +| `schedule.low-space-ratio` | ストアの収容能力が不足する閾値比率 | | `schedule.tolerant-size-ratio` | `balance`バッファサイズを制御します | | `schedule.enable-remove-down-replica` | `DownReplica`自動的に削除する機能を有効にするかどうかを決定します | | `schedule.enable-replace-offline-replica` | `OfflineReplica`を移行する機能を有効にするかどうかを決定します | @@ -301,7 +301,7 @@ Query OK, 0 rows affected (0.01 sec) | `schedule.hot-regions-write-interval` | PDがホットリージョン情報を保存する時間間隔 | | `schedule.hot-regions-reserved-days` | ホットリージョン情報が保持される日数を指定します | | `schedule.max-movable-hot-peer-size` | ホットリージョンスケジュールにスケジュールできる最大リージョンサイズを制御します。 | -| `schedule.store-limit-version` | [店舗制限](/configure-store-limit.md)のバージョンを制御します | +| `schedule.store-limit-version` | [ストア制限](/configure-store-limit.md)のバージョンを制御します | | `schedule.patrol-region-worker-count` | リージョンのヘルス状態を検査するときにチェッカーによって作成される同時オペレータの数を制御します | | `replication.max-replicas` | レプリカの最大数を設定します | | `replication.location-labels` | TiKVクラスタのトポロジ情報 | @@ -372,7 +372,7 @@ select @@tidb_slow_log_threshold; | `instance.tidb_force_priority` | `tidb_force_priority` | この TiDB インスタンスから送信されるステートメントの優先順位を指定します | | `instance.max_connections` | `max_connections` | この TiDB インスタンスに許可される同時接続の最大数を指定します | | `instance.tidb_enable_ddl` | `tidb_enable_ddl` | この TiDB インスタンスが DDL 所有者になれるかどうかを制御します | -| `pessimistic-txn.constraint-check-in-place-pessimistic` | `tidb_constraint_check_in_place_pessimistic` | ユニークインデックスのユニーク制約チェックを、このインデックスが次にロックを必要とするときまで延期するか、トランザクションがコミットされるときまで延期するかを制御します。 | +| `pessimistic-txn.constraint-check-in-place-pessimistic` | `tidb_constraint_check_in_place_pessimistic` | 一意インデックスのユニーク制約チェックを、このインデックスが次にロックを必要とするときまで延期するか、トランザクションがコミットされるときまで延期するかを制御します。 | ### TiFlash構成を動的に変更する {#modify-tiflash-configuration-dynamically} diff --git a/encryption-at-rest.md b/encryption-at-rest.md index 2b914f1a04c2d..4852e1f1f61fc 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -125,7 +125,7 @@ AWS KMS を使用してマスターキーを指定するには、TiKV 設定フ `key-id` KMS CMK のキー ID を指定します。3 `region` KMS CMK の AWS リージョン名です。5 はオプションであり、AWS 以外のベンダーの AWS KMS 互換サービスを使用している場合や、 `endpoint` [KMS の VPC エンドポイント](https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html)使用する必要がある場合を除き、通常は指定する必要はありません。 -AWSでも[マルチリージョンキー](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)使用できます。この場合、特定のリージョンにプライマリキーを設定し、必要なリージョンにレプリカキーを追加する必要があります。 +AWSでも[マルチリージョンキー](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)を使用できます。この場合、特定のリージョンに主キーを設定し、必要なリージョンにレプリカキーを追加する必要があります。
diff --git a/error-codes.md b/error-codes.md index 340294dbc6e32..2a60b7a016eb5 100644 --- a/error-codes.md +++ b/error-codes.md @@ -179,9 +179,9 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8059 - 自動ランダムIDが不足しているため、割り当てることができません。現在、このようなエラーから回復する方法はありません。自動ランダム機能を使用する場合は、割り当て数を最大限にするためにbigintを使用することをお勧めします。また、自動ランダム列に手動で値を割り当てることは避けてください。 + AUTO_RANDOM IDが不足しているため、割り当てることができません。現在、このようなエラーから回復する方法はありません。AUTO_RANDOM機能を使用する場合は、割り当て数を最大限にするためにbigintを使用することをお勧めします。また、AUTO_RANDOM列に手動で値を割り当てることは避けてください。 - 参考として[自動ランダム](/auto-random.md)参照してください。 + 参考として[AUTO_RANDOM](/auto-random.md)参照してください。 - エラー番号: 8060 @@ -591,7 +591,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 エラーメッセージは`ERROR 9007 (HY000): Write conflict`で始まります。 - エラーメッセージに`reason=LazyUniquenessCheck`が含まれている場合、トランザクションが悲観的であり、 `@@tidb_constraint_check_in_place_pessimistic=OFF`設定されており、アプリケーションの一意のインデックスで書き込み競合が発生していることを意味します。この場合、悲観的トランザクションの正常な実行は保証されません。アプリケーションからトランザクションを再試行するか、変数を`ON`に設定してエラーを回避してください。 + エラーメッセージに`reason=LazyUniquenessCheck`が含まれている場合、トランザクションが悲観的であり、 `@@tidb_constraint_check_in_place_pessimistic=OFF`設定されており、アプリケーションの一意インデックスで書き込み競合が発生していることを意味します。この場合、悲観的トランザクションの正常な実行は保証されません。アプリケーションからトランザクションを再試行するか、変数を`ON`に設定してエラーを回避してください。 - エラー番号: 9008 diff --git a/explain-walkthrough.md b/explain-walkthrough.md index ac8f623ac5878..eba771a15f7a5 100644 --- a/explain-walkthrough.md +++ b/explain-walkthrough.md @@ -46,7 +46,7 @@ EXPLAIN SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00 > **注記：** > -> テーブルに含まれる地域の一般的なビューを表示するには、 [`SHOW TABLE REGIONS`](/sql-statements/sql-statement-show-table-regions.md)実行します。 +> テーブルに含まれるリージョンの概要を表示するには、 [`SHOW TABLE REGIONS`](/sql-statements/sql-statement-show-table-regions.md)実行します。 ## 現在のパフォーマンスを評価する {#assess-the-current-performance} diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index 651f817e8dfa8..ca946e4c765c7 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -486,7 +486,7 @@ SELECT *, TIDB_ROW_CHECKSUM() FROM t WHERE id = 1; - `ORDER BY`節では使用できません。 - `ON`節では使用できません。 - `WHERE`サブクエリでは使用できません。 - - 整数フィールドのみの一意のインデックスを分散させるために使用できます。 + - 整数フィールドのみの一意インデックスを分散させるために使用できます。 - 複合インデックスでは効果がない可能性があります。 - FastPlan プロセスを実行できないため、オプティマイザーのパフォーマンスに影響します。 - 実行プラン キャッシュの準備には使用できません。 diff --git a/garbage-collection-overview.md b/garbage-collection-overview.md index 1dd2c093c023f..457987e80219e 100644 --- a/garbage-collection-overview.md +++ b/garbage-collection-overview.md @@ -23,7 +23,7 @@ TiDBでは、GCが定期的に実行されます。GCごとに、TiDBはまず ### ロックを解決する {#resolve-locks} -TiDBトランザクションモデルは[GoogleのPercolator](https://ai.google/research/pubs/pub36726)に基づいて実装されています。これは主に2フェーズコミットプロトコルであり、実用的な最適化がいくつか施されています。第1フェーズが終了すると、関連するすべてのキーがロックされます。これらのロックのうち、1つはプライマリロックで、残りはプライマリロックへのポインタを含むセカンダリロックです。第2フェーズでは、プライマリロックを持つキーに書き込みレコードが取得され、そのロックが解除されます。書き込みレコードは、このキーの履歴またはトランザクションロールバックレコードにおける書き込みまたは削除操作を示します。プライマリロックを置き換える書き込みレコードの種類は、対応するトランザクションが正常にコミットされたかどうかを示します。その後、すべてのセカンダリロックが順次置き換えられます。障害などの何らかの理由でこれらのセカンダリロックが保持され、置き換えられない場合でも、セカンダリロックの情報に基づいてプライマリキーを見つけ、プライマリキーがコミットされたかどうかに基づいてトランザクション全体がコミットされたかどうかを判断できます。ただし、GCによってプライマリキー情報がクリアされ、このトランザクションにコミットされていないセカンダリロックがある場合、これらのロックがコミット可能かどうかを知ることはできません。その結果、データの整合性は保証されません。 +TiDBトランザクションモデルは[GoogleのPercolator](https://ai.google/research/pubs/pub36726)に基づいて実装されています。これは主に2フェーズコミットプロトコルであり、実用的な最適化がいくつか施されています。第1フェーズが終了すると、関連するすべてのキーがロックされます。これらのロックのうち、1つはプライマリロックで、残りはプライマリロックへのポインタを含むセカンダリロックです。第2フェーズでは、プライマリロックを持つキーに書き込みレコードが取得され、そのロックが解除されます。書き込みレコードは、このキーの履歴またはトランザクションロールバックレコードにおける書き込みまたは削除操作を示します。プライマリロックを置き換える書き込みレコードの種類は、対応するトランザクションが正常にコミットされたかどうかを示します。その後、すべてのセカンダリロックが順次置き換えられます。障害などの何らかの理由でこれらのセカンダリロックが保持され、置き換えられない場合でも、セカンダリロックの情報に基づいて主キーを見つけ、主キーがコミットされたかどうかに基づいてトランザクション全体がコミットされたかどうかを判断できます。ただし、GCによって主キー情報がクリアされ、このトランザクションにコミットされていないセカンダリロックがある場合、これらのロックがコミット可能かどうかを知ることはできません。その結果、データの整合性は保証されません。 「ロックの解決」ステップは、セーフポイントの前のロックをクリアします。つまり、ロックの主キーがコミットされている場合は、このロックもコミットする必要があります。そうでない場合は、ロールバックする必要があります。主キーがまだロックされている場合（コミットもロールバックもされていない場合）、このトランザクションはタイムアウトと見なされ、ロールバックされます。 diff --git a/global-indexes.md b/global-indexes.md index 7440d119f4b5d..58e4ac444ef17 100644 --- a/global-indexes.md +++ b/global-indexes.md @@ -27,7 +27,7 @@ summary: TiDB グローバル インデックスの使用例、利点、使用 データ移行やアプリケーションの変更時に、グローバルインデックスを使用することで、追加の調整作業を大幅に削減できます。グローバルインデックスがない場合、パーティションスキームを変更したり、インデックスの制限を回避するためにSQLクエリを書き直したりする必要があるかもしれません。グローバルインデックスを使用すれば、こうした変更を回避でき、開発コストと保守コストの両方を削減できます。 -例えば、OracleデータベースからTiDBにテーブルを移行する場合、Oracleはグローバルインデックスをサポートしているため、パーティション列を含まない一意のインデックスが使用されることがあります。TiDBがグローバルインデックスを導入する前は、TiDBのパーティションルールに準拠するようにテーブルスキーマを変更する必要がありました。現在、TiDBはグローバルインデックスをサポートしています。データを移行する際には、これらのインデックスをグローバルとして定義するだけで済み、スキーマの動作をOracleと一貫性のあるものにすることができ、移行コストを大幅に削減できます。 +例えば、OracleデータベースからTiDBにテーブルを移行する場合、Oracleはグローバルインデックスをサポートしているため、パーティション列を含まない一意インデックスが使用されることがあります。TiDBがグローバルインデックスを導入する前は、TiDBのパーティションルールに準拠するようにテーブルスキーマを変更する必要がありました。現在、TiDBはグローバルインデックスをサポートしています。データを移行する際には、これらのインデックスをグローバルとして定義するだけで済み、スキーマの動作をOracleと一貫性のあるものにすることができ、移行コストを大幅に削減できます。 ## グローバルインデックスの制限 {#limitations-of-global-indexes} @@ -122,7 +122,7 @@ PARTITION BY HASH(col3) PARTITIONS 4; ``` -前の例では、一意のインデックス`uidx12`と一意でないインデックス`idx1`はグローバル インデックスになりますが、 `uidx3`通常の一意のインデックスのままです。 +前の例では、一意インデックス`uidx12`と一意でないインデックス`idx1`はグローバル インデックスになりますが、 `uidx3`通常の一意インデックスのままです。 クラスター化インデックスはグローバルインデックスにはなり得ないことに注意してください。例: @@ -179,7 +179,7 @@ SELECT * FROM information_schema.tidb_indexes WHERE table_name='t1'; 通常のテーブルをパーティション分割する場合、またはパーティションテーブルを再パーティションする場合、必要に応じてインデックスをグローバル インデックスまたはローカル インデックスに更新できます。 -例えば、次のSQL文は、列`col1`に基づいて表`t1`再パーティション化し、グローバルインデックス`uidx12`と`idx1`ローカルインデックスに更新し、ローカルインデックス`uidx3`グローバルインデックスに更新します。列`uidx3`は列`col3`の一意のインデックスです。すべてのパーティションにわたって列`col3`の一意性を確保するには、列`uidx3`グローバルインデックスにする必要があります。列`uidx12`と`idx1`は列`col1`のインデックスであり、グローバルインデックスまたはローカルインデックスのどちらでも構いません。 +例えば、次のSQL文は、列`col1`に基づいて表`t1`再パーティション化し、グローバルインデックス`uidx12`と`idx1`ローカルインデックスに更新し、ローカルインデックス`uidx3`グローバルインデックスに更新します。列`uidx3`は列`col3`の一意インデックスです。すべてのパーティションにわたって列`col3`の一意性を確保するには、列`uidx3`グローバルインデックスにする必要があります。列`uidx12`と`idx1`は列`col1`のインデックスであり、グローバルインデックスまたはローカルインデックスのどちらでも構いません。 ```sql ALTER TABLE t1 PARTITION BY HASH (col1) PARTITIONS 3 UPDATE INDEXES (uidx12 LOCAL, uidx3 GLOBAL, idx1 LOCAL); @@ -295,7 +295,7 @@ WHERE k IN (xx, xx, xx) | テーブルタイプ | 同時実行1 | 同時実行数 32 | 同時実行数 64 | 平均RU | | ----------------------------------------------- | ----- | -------- | -------- | ------ | -| クラスタ化された非パーティションテーブル | 225 | 19,999 | 30,293 | 7.92 | +| クラスター化された非パーティションテーブル | 225 | 19,999 | 30,293 | 7.92 | | PK でパーティション化されたクラスター化テーブル範囲 | 68 | 480 | 511 | 114.87 | | PK によって範囲分割されたクラスター化テーブル、 `k` `c`グローバル インデックスあり | 207 | 17,798 | 27,707 | 11.73 | @@ -303,8 +303,8 @@ WHERE k IN (xx, xx, xx) | テーブルタイプ | 同時実行1 | 同時実行数 32 | 同時実行数 64 | 平均RU | | ------------------------------------------- | ----- | -------- | -------- | ------ | -| クラスタ化された非パーティションテーブル | 166 | 20,361 | 28,922 | 7.86 | -| PK で分割されたクラスタ化テーブルハッシュ | 60 | 244 | 283 | 119.73 | -| PKでハッシュ分割されたクラスタ化テーブル、 `k` `c`グローバルインデックスあり | 156 | 18,233 | 15,581 | 10.77 | +| クラスター化された非パーティションテーブル | 166 | 20,361 | 28,922 | 7.86 | +| PK で分割されたクラスター化テーブルハッシュ | 60 | 244 | 283 | 119.73 | +| PKでハッシュ分割されたクラスター化テーブル、 `k` `c`グローバルインデックスあり | 156 | 18,233 | 15,581 | 10.77 | 前述のテストでは、高同時実行環境において、グローバルインデックスによってパーティションテーブルのクエリパフォーマンスが大幅に向上し、最大50倍のパフォーマンス向上が実現できることが実証されています。さらに、グローバルインデックスはリクエストユニット（RU）の消費量を大幅に削減します。パーティション数が増えるにつれて、パフォーマンスのメリットはさらに顕著になります。 diff --git a/glossary.md b/glossary.md index 10f9438b6406b..8fbd2c5c5acd0 100644 --- a/glossary.md +++ b/glossary.md @@ -21,7 +21,7 @@ summary: TiDBに関する用語集。 ACIDとは、トランザクションの4つの主要な特性、すなわち原子性、一貫性、分離性、および永続性を指します。これらの特性はそれぞれ以下で説明します。 -- **原子性**とは、操作による変更がすべて実行されるか、あるいは全く実行されないかのどちらかであることを意味します。TiDBは、トランザクションの原子性を実現するために、プライマリキーを格納する[リージョン](#regionpeerraft-group)の要素の原子性を保証します。 +- **原子性**とは、操作による変更がすべて実行されるか、あるいは全く実行されないかのどちらかであることを意味します。TiDBは、トランザクションの原子性を実現するために、主キーを格納する[リージョン](#regionpeerraft-group)の要素の原子性を保証します。 - **一貫性と**は、トランザクションによってデータベースが常に一貫性のある状態から別の一貫性のある状態へと移行することを意味します。TiDBでは、メモリにデータを書き込む前にデータの一貫性が確保されます。 @@ -274,7 +274,7 @@ Placement Driver(PD) は、メタデータの保存、トランザクション ### ポイント獲得 {#point-get} -ポイント取得とは、一意のインデックスまたは主インデックスによってデータの単一行を読み取ることを意味し、返される結果セットは最大で1行です。 +ポイント取得とは、一意インデックスまたは主インデックスによってデータの単一行を読み取ることを意味し、返される結果セットは最大で1行です。 ### 特定時点復旧（PITR） {#point-in-time-recovery-pitr} diff --git a/grafana-overview-dashboard.md b/grafana-overview-dashboard.md index 06099a0615928..b2c42ee3a31f6 100644 --- a/grafana-overview-dashboard.md +++ b/grafana-overview-dashboard.md @@ -21,14 +21,14 @@ Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、 | PD | PDの役割 | 現在のPDの役割。 | | | PD | ストレージ容量 | TiDB クラスターの合計ストレージ容量。 | | | PD | 現在のストレージサイズ | TiKV レプリカによって占有されるスペースを含む、TiDB クラスターの占有ストレージ容量。 | | -| PD | 通常の店舗 | 正常状態にあるノードの数。 | | -| PD | 異常な店舗 | 異常状態にあるノードの数。 | 0 | -| PD | 地域数 | 現在のクラスター内のリージョンの合計数。リージョンの数はレプリカの数とは関係ありません。 | | +| PD | 通常のストア | 正常状態にあるノードの数。 | | +| PD | 異常なストア | 異常状態にあるノードの数。 | 0 | +| PD | リージョン数 | 現在のクラスター内のリージョンの合計数。リージョンの数はレプリカの数とは関係ありません。 | | | PD | 99% 完了コマンド実行時間秒数 | pd-server 要求を完了するまでの 99 パーセンタイル期間。 | 5ミリ秒未満 | | PD | 処理リクエストの所要時間（秒） | PD 要求のネットワーク期間。 | | | PD | リージョンの健康 | 各リージョンの状態。 | 通常、保留中のピアの数は 100 未満であり、不足しているピアの数は必ずしも`0`を超えるとは限りません。 | | PD | ホットライトリージョンのリーダー分布 | 各 TiKV インスタンスの書き込みホットスポットであるリーダーの合計数。 | | -| PD | ホットリード地域のリーダー分布 | 各 TiKV インスタンス上の読み取りホットスポットであるリーダーの合計数。 | | +| PD | ホットリードリージョンのリーダー分布 | 各 TiKV インスタンス上の読み取りホットスポットであるリーダーの合計数。 | | | PD | リージョンのハートビートレポート | インスタンスごとに PD に報告されたハートビートの数。 | | | PD | 99%リージョンハートビートレイテンシー | TiKV インスタンスごとのハートビートレイテンシー(P99)。 | | | TiDB | ステートメントOPS | 1 秒あたりに実行される異なるタイプの SQL ステートメントの数。1 、 `SELECT` 、 `UPDATE`など`INSERT`ステートメントのタイプに応じてカウントされます。 | | @@ -47,12 +47,12 @@ Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、 | TiDB | ロック解決OPS | ロックを解決したTiDB操作の数。TiDBの読み取りまたは書き込み要求がロックに遭遇すると、TiDBはロックを解決しようとします。 | | | TiDB | KV バックオフ OPS | TiKV によって返されたエラーの数。 | | | TiKV | リーダー | 各 TiKV ノード上のリーダーの数。 | | -| TiKV | 地域 | 各 TiKV ノード上のリージョンの数。 | | +| TiKV | リージョン | 各 TiKV ノード上のリージョンの数。 | | | TiKV | CPU | 各 TiKV ノード上の CPU 使用率。 | | | TiKV | メモリ | 各 TiKV ノードのメモリ使用量。 | | -| TiKV | 店舗規模 | 各 TiKV インスタンスによって使用されるストレージスペースのサイズ。 | | +| TiKV | ストアサイズ | 各 TiKV インスタンスによって使用されるストレージスペースのサイズ。 | | | TiKV | cfサイズ | 各カラムファミリー(略して CF) のサイズ。 | | -| TiKV | チャンネルがいっぱい | 各 TiKV インスタンスでの「チャネルがいっぱい」エラーの数。 | 0 | +| TiKV | チャネルフル | 各 TiKV インスタンスでの「チャネルフル」エラーの数。 | 0 | | TiKV | サーバーレポートの失敗 | 各 TiKV インスタンスによって報告されたエラー メッセージの数。 | 0 | | TiKV | スケジューラ保留コマンド | 各 TiKV インスタンス上の保留中のコマンドの数。 | | | TiKV | コプロセッサ実行者数 | TiKVが1秒あたりに受信したコプロセッサ操作の数。コプロセッサの種類ごとに個別にカウントされます。 | | diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md index 234766d6d2c07..9a0b0728c231b 100644 --- a/grafana-pd-dashboard.md +++ b/grafana-pd-dashboard.md @@ -31,7 +31,7 @@ PD ダッシュボード メトリック項目の説明は次のとおりです - クラスタID: クラスターの一意の識別子 - 現在のTSO: 現在割り当てられているTSOの物理部分 - 現在のID割り当て: 新しいストア/ピアに割り当てられる最大ID -- リージョンラベル分離レベル: 異なるラベルレベルの地域数 +- リージョンラベル分離レベル: 異なるラベルレベルのリージョン数 - ラベルの配布: クラスタ内のラベルの配布状態 - ストア制限: ストアでのスケジュールのフロー制御制限 @@ -103,9 +103,9 @@ PD ダッシュボード メトリック項目の説明は次のとおりです - レプリカチェッカー:レプリカチェッカーのステータス - ルールチェッカー: ルールチェッカーのステータス - リージョンマージチェッカー: マージチェッカーのステータス -- フィルターターゲット: 店舗がスケジュールターゲットとして選択されたが、フィルターを通過できなかった試行回数 -- フィルターソース: 店舗がスケジュールソースとして選択されたが、フィルターを通過できなかった試行回数 -- バランス方向: 店舗がスケジュールの対象またはソースとして選択された回数 +- フィルターターゲット: ストアがスケジュールターゲットとして選択されたが、フィルターを通過できなかった試行回数 +- フィルターソース: ストアがスケジュールソースとして選択されたが、フィルターを通過できなかった試行回数 +- バランス方向: ストアがスケジュールの対象またはソースとして選択された回数 ![PD Dashboard - Scheduler metrics](/media/pd-dashboard-scheduler-v4.png) diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 92c3818df3c82..0f0976aebcb25 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -113,7 +113,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す 以下のメトリックは、TiKV に送信されたリクエストに関連します。再試行リクエストは複数回カウントされます。 - KVリクエストOPS: TiKVに従って表示されるKVリクエストの実行時間 -- KVリクエスト期間 99（店舗別）: TiKVに従って表示されるKVリクエストの実行時間 +- KVリクエスト期間 99（ストア別）: TiKVに従って表示されるKVリクエストの実行時間 - KVリクエスト期間 99 (タイプ別): リクエストタイプに応じて表示される KV リクエストの実行時間 - ステイル読み取りヒット/ミスオペレーション - **ヒット**: 古い読み取りを正常に実行した 1 秒あたりのリクエスト数 diff --git a/grafana-tikv-dashboard.md b/grafana-tikv-dashboard.md index 1e77860988a28..401923f994ad1 100644 --- a/grafana-tikv-dashboard.md +++ b/grafana-tikv-dashboard.md @@ -421,13 +421,13 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - リージョンキャッシュヒット率：リージョンキャッシュのヒット率 - リージョンキャッシュミス理由：リージョンキャッシュからデータが取得されない理由 - メモリ使用量：インメモリエンジンのメモリ使用量 -- リージョン数：異なる種類の地域の数 +- リージョン数：異なる種類のリージョンの数 - GCフィルタ：ガベージコレクション（GC）中のフィルタリングプロセスに関する情報 - リージョンGCの所要時間：リージョンGCに要した時間 - リージョン読み込み時間：リージョンの読み込みにかかる時間 - リージョンロード数：1秒あたりにロードされるリージョンの数 -- リージョン退去期間：地域を退去させるのにかかる時間 -- リージョン退去数：1秒あたりに退去させられた地域の数 +- リージョンエビクション期間：リージョンをエビクションするのにかかる時間 +- リージョンエビクション数：1秒あたりにエビクションされたリージョンの数 - 書き込み時間：リージョンキャッシュエンジンでの書き込み操作にかかる時間 - サーバーごとのインメモリエンジン書き込み時間（99%）：インメモリエンジンにおけるTiKVサーバーごとの書き込み時間の99パーセンタイル値 - 書き込み準備時間：インメモリエンジンで書き込み操作を準備するのに要する時間 diff --git a/information-schema/information-schema-columns.md b/information-schema/information-schema-columns.md index 0197a862c36c5..8c3bdc14db03d 100644 --- a/information-schema/information-schema-columns.md +++ b/information-schema/information-schema-columns.md @@ -99,7 +99,7 @@ CHARACTER_MAXIMUM_LENGTH: NULL - `COLUMN_KEY` : この列がインデックスされているかどうか。このフィールドには次の値が含まれます。 - 空: この列にはインデックスが付いていません。または、この列にはインデックスが付いていて、複数列の一意でないインデックスの 2 番目の列です。 - `PRI` : この列は主キーまたは複数の主キーの 1 つです。 - - `UNI` : この列は、一意のインデックスの最初の列です。 + - `UNI` : この列は、一意インデックスの最初の列です。 - `MUL` : 列は、特定の値が複数回出現することを許可される、一意でないインデックスの最初の列です。 - `EXTRA` : 指定された列の追加情報。 - `PRIVILEGES` : 現在のユーザーがこの列に対して持つ権限。現在、この値はTiDBで固定されており、常に`select,insert,update,references`です。 diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index 3c28028271479..f9a8789a4141a 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -276,10 +276,10 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo | TiKV | フィルターブロックキャッシュヒット | tikv_block_filter_cache_hit | 0.95 | TiKV のフィルターブロックキャッシュのヒット率。 | | TiKV | データブロックキャッシュヒット | tikv_block_data_cache_hit | 0.80 | TiKV のデータブロックキャッシュのヒット率。 | | TiKV | リーダースコアバランス | pd_scheduler_store_status | < 0.05 | 各TiKVインスタンスのリーダースコアが均衡しているかどうかを確認します。インスタンス間の期待される差は5%未満です。 | -| TiKV | 地域スコアバランス | pd_scheduler_store_status | < 0.05 | 各TiKVインスタンスのリージョンスコアが均衡しているかどうかを確認します。インスタンス間の期待される差は5%未満です。 | -| TiKV | ストア利用可能残高 | pd_scheduler_store_status | < 0.2 | 各TiKVインスタンスの利用可能なストレージのバランスを確認します。インスタンス間の差は20%未満であることが想定されています。 | +| TiKV | リージョンスコアバランス | pd_scheduler_store_status | < 0.05 | 各TiKVインスタンスのリージョンスコアが均衡しているかどうかを確認します。インスタンス間の期待される差は5%未満です。 | +| TiKV | ストア利用可能バランス | pd_scheduler_store_status | < 0.2 | 各TiKVインスタンスの利用可能なストレージのバランスを確認します。インスタンス間の差は20%未満であることが想定されています。 | | TiKV | リージョン数 | pd_scheduler_store_status | 20000未満 | 各 TiKV インスタンスのリージョン数を確認します。1 つのインスタンスあたりのリージョン数は 20,000 未満と想定されています。 | -| PD | 地域の健康 | pd_region_health | 100未満 | クラスター内でスケジュール処理中のリージョンの数を検出します。想定される数は合計で100未満です。 | +| PD | リージョンの健康 | pd_region_health | 100未満 | クラスター内でスケジュール処理中のリージョンの数を検出します。想定される数は合計で100未満です。 | さらに、このルールは、TiKV インスタンス内の次のスレッドの CPU 使用率が高すぎるかどうかもチェックします。 diff --git a/information-schema/information-schema-tables.md b/information-schema/information-schema-tables.md index bc5cfa276d6c3..6565249014c48 100644 --- a/information-schema/information-schema-tables.md +++ b/information-schema/information-schema-tables.md @@ -110,7 +110,7 @@ SHOW TABLES - `MAX_DATA_LENGTH` : 最大データ長。現在の値は`0` 、データ長に上限がないことを意味します。 - `INDEX_LENGTH` : インデックスの長さ`INDEX_LENGTH` = `TABLE_ROWS` * インデックスタプル内の列の長さの合計。TiKVのレプリカは考慮されません。 - `DATA_FREE` : データフラグメント。現在の値は`0`です。 -- `AUTO_INCREMENT` : 自動インクリメント主キーの現在のステップ。 +- `AUTO_INCREMENT` : 現在のAUTO_INCREMENT主キーの値。 - `CREATE_TIME` : テーブルが作成された時刻。 - `UPDATE_TIME` : テーブルが更新される時刻。 - `CHECK_TIME` : テーブルがチェックされる時刻。 diff --git a/information-schema/information-schema-tidb-hot-regions-history.md b/information-schema/information-schema-tidb-hot-regions-history.md index de655d861fc4f..3b77465016509 100644 --- a/information-schema/information-schema-tidb-hot-regions-history.md +++ b/information-schema/information-schema-tidb-hot-regions-history.md @@ -61,10 +61,10 @@ DESC tidb_hot_regions_history; - INDEX_NAME: ホットリージョンが存在するインデックスの名前。 - INDEX_ID: ホットリージョンが存在するインデックスのID。 - REGION_ID: ホットリージョンのID。 -- STORE_ID: ホットリージョンが存在する店舗のID。 +- STORE_ID: ホットリージョンが存在するストアのID。 - PEER_ID: ホットリージョンに対応するピアのID。 -- IS_LEARNER: PEERが学習者であるかどうか。 -- IS_LEADER: PEERがLEADERであるかどうか。 +- IS_LEARNER: ピアがラーナーであるかどうか。 +- IS_LEADER: ピアがリーダーであるかどうか。 - タイプ: ホットリージョンのタイプ。 - HOT_DEGREE: ホットリージョンの高温度。 - FLOW_BYTES:リージョン内で書き込まれたバイト数と読み取られたバイト数。 @@ -77,7 +77,7 @@ DESC tidb_hot_regions_history; ## 一般的なユーザーシナリオ {#common-user-scenarios} -- 特定の期間内のホットな地域を検索します。 `update_time`実際の時間に置き換えてください。 +- 特定の期間内のホットリージョンを検索します。 `update_time`実際の時間に置き換えてください。 ```sql SELECT * FROM INFORMATION_SCHEMA.TIDB_HOT_REGIONS_HISTORY WHERE update_time >'2021-08-18 21:40:00' and update_time <'2021-09-19 00:00:00'; diff --git a/information-schema/information-schema-tikv-store-status.md b/information-schema/information-schema-tikv-store-status.md index 27180d357904a..5a8e96b7ac8d7 100644 --- a/information-schema/information-schema-tikv-store-status.md +++ b/information-schema/information-schema-tikv-store-status.md @@ -48,7 +48,7 @@ DESC TIKV_STORE_STATUS; `TIKV_STORE_STATUS`テーブルの列の説明は以下のとおりです。 - `STORE_ID` : ストアのID。 -- `ADDRESS` : 店舗の住所。 +- `ADDRESS` : ストアのアドレス。 - `STORE_STATE` : ストア状態の識別子。これは`STORE_STATE_NAME`に対応します。 - `STORE_STATE_NAME` : ストア状態の名前。名前は`Up` 、 `Offline` 、または`Tombstone` 。 - `LABEL` : ストアのラベルセット。 diff --git a/migrate-large-mysql-shards-to-tidb.md b/migrate-large-mysql-shards-to-tidb.md index 9d96ba6ed0e71..f4f581b0353b1 100644 --- a/migrate-large-mysql-shards-to-tidb.md +++ b/migrate-large-mysql-shards-to-tidb.md @@ -37,7 +37,7 @@ MySQL シャードのデータ サイズが 1 TiB 未満の場合は、[小規 ### シャーディングされたテーブルの競合をチェックする {#check-conflicts-for-sharded-tables} -移行に異なるシャードテーブルのデータのマージが含まれる場合、マージ中に主キーまたは一意のインデックスの競合が発生する可能性があります。したがって、移行前に、ビジネスの観点から現在のシャーディング スキームを詳しく調べ、競合を回避する方法を見つける必要があります。詳細については、 [複数のシャーディングされたテーブル間で主キーまたは一意インデックス間の競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-between-primary-keys-or-unique-indexes-across-multiple-sharded-tables)参照してください。以下に簡単に説明します。 +移行に異なるシャードテーブルのデータのマージが含まれる場合、マージ中に主キーまたは一意インデックスの競合が発生する可能性があります。したがって、移行前に、ビジネスの観点から現在のシャーディング スキームを詳しく調べ、競合を回避する方法を見つける必要があります。詳細については、 [複数のシャーディングされたテーブル間で主キーまたは一意インデックス間の競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-between-primary-keys-or-unique-indexes-across-multiple-sharded-tables)参照してください。以下に簡単に説明します。 表1～4は以下の表構造と同じであると仮定します。 diff --git a/migrate-small-mysql-shards-to-tidb.md b/migrate-small-mysql-shards-to-tidb.md index 9ed44324e2afb..9b50ce1b8ea57 100644 --- a/migrate-small-mysql-shards-to-tidb.md +++ b/migrate-small-mysql-shards-to-tidb.md @@ -33,7 +33,7 @@ summary: シャードの小さなデータセットを MySQL から TiDB に移 ### シャードテーブルの競合をチェックする {#check-conflicts-for-the-sharded-tables} -移行に異なるシャーディングされたテーブルからのデータのマージが含まれる場合、マージ中に主キーまたは一意のインデックスの競合が発生する可能性があります。そのため、移行前に、現在のシャーディングスキームをビジネスの観点から詳細に検討し、競合を回避する方法を見つける必要があります。詳細については、 [複数のシャードテーブル間の主キーまたは一意のインデックス間の競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-between-primary-keys-or-unique-indexes-across-multiple-sharded-tables)参照してください。以下に簡単に説明します。 +移行に異なるシャーディングされたテーブルからのデータのマージが含まれる場合、マージ中に主キーまたは一意インデックスの競合が発生する可能性があります。そのため、移行前に、現在のシャーディングスキームをビジネスの観点から詳細に検討し、競合を回避する方法を見つける必要があります。詳細については、 [複数のシャードテーブル間の主キーまたは一意インデックス間の競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-between-primary-keys-or-unique-indexes-across-multiple-sharded-tables)参照してください。以下に簡単に説明します。 この例では、 `sale_01`と`sale_02`次の同じテーブル構造を持ちます。 @@ -48,7 +48,7 @@ CREATE TABLE `sale_01` ( ) ENGINE=InnoDB DEFAULT CHARSET=latin1 ``` -`id`列目は主キー、 `sid`列目はシャーディングキーです。5列目`id`自動増分であり、複数のシャーディングテーブル範囲が重複するとデータ競合が発生します。7列`sid`インデックスのグローバル一意性を保証するため、 [自動増分主キーの主キー属性を削除します](/dm/shard-merge-best-practices.md#remove-the-primary-key-attribute-from-the-column)目の手順に従って`id`列目をバイパスできます。 +`id`列は主キー、 `sid`列はシャーディングキーです。`id`列は自動増分であり、複数のシャーディングテーブル範囲が重複するとデータ競合が発生します。`sid`はインデックスのグローバル一意性を保証するため、 [AUTO_INCREMENT主キーの主キー属性を削除します](/dm/shard-merge-best-practices.md#remove-the-primary-key-attribute-from-the-column)の手順に従って`id`列をバイパスできます。 ```sql CREATE TABLE `sale` ( diff --git a/online-unsafe-recovery.md b/online-unsafe-recovery.md index 39ac7afe1e63c..73630e3fd6af1 100644 --- a/online-unsafe-recovery.md +++ b/online-unsafe-recovery.md @@ -158,7 +158,7 @@ SELECT TABLE_SCHEMA, TABLE_NAME, TIDB_TABLE_ID FROM INFORMATION_SCHEMA.TABLES WH > **注記：** > > - 回復操作により、一部の投票失敗者が学習失敗者になりました。そのため、PDスケジュールではこれらの学習失敗者を削除するのに時間がかかります。 -> - 新しい店舗を随時追加することをお勧めします。 +> - 新しいストアを随時追加することをお勧めします。 タスク実行中にエラーが発生した場合、出力の最後のステージに`"Unsafe recovery failed"`とエラーメッセージが表示されます。例： diff --git a/optimistic-transaction.md b/optimistic-transaction.md index 8ee4c5e75388d..902405600a5b8 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -85,12 +85,12 @@ sequenceDiagram 5. TiDBは2PC方式を採用し、トランザクションの原子性を保証すると同時に、データをストア内に永続化します。 - 1. TiDBは、書き込むデータからプライマリキーを選択します。 + 1. TiDBは、書き込むデータから主キーを選択します。 2. TiDBはPDからリージョン分布情報を受け取り、それに応じてすべてのキーをリージョンごとにグループ化します。 3. TiDBは、関係するすべてのTiKVノードに書き込み前リクエストを送信します。その後、TiKVは競合や期限切れのバージョンがないかを確認します。有効なデータはロックされます。 4. TiDBはプリライトフェーズで全ての応答を受信し、プリライトは成功しました。 5. TiDB は PD からコミット バージョン番号を受け取り、それを`commit_ts`とマークします。 - 6. TiDBは、プライマリキーが格納されているTiKVノードへの2回目のコミットを開始します。TiKVはデータをチェックし、書き込み前フェーズで残されたロックを解除します。 + 6. TiDBは、主キーが格納されているTiKVノードへの2回目のコミットを開始します。TiKVはデータをチェックし、書き込み前フェーズで残されたロックを解除します。 7. TiDBは、第2フェーズが正常に完了したことを報告するメッセージを受信する。 6. TiDBは、トランザクションが正常にコミットされたことをクライアントに通知するメッセージを返します。 diff --git a/partitioned-table.md b/partitioned-table.md index e73837cb9ae74..1833a398f3fa7 100644 --- a/partitioned-table.md +++ b/partitioned-table.md @@ -634,7 +634,7 @@ PARTITION BY KEY(fname, store_id) PARTITIONS 4; ``` -MySQLと同様に、TiDBは`PARTITION BY KEY`で指定された空のパーティション列リストを使用して、キーパーティションテーブルを作成することをサポートしています。たとえば、次のステートメントは、プライマリキー`id`パーティションキーとして使用してパーティションテーブルを作成します。 +MySQLと同様に、TiDBは`PARTITION BY KEY`で指定された空のパーティション列リストを使用して、キーパーティションテーブルを作成することをサポートしています。たとえば、次のステートメントは、主キー`id`パーティションキーとして使用してパーティションテーブルを作成します。 ```sql CREATE TABLE employees ( @@ -1354,7 +1354,7 @@ SELECT store_id, COUNT(department_id) AS c - パーティションテーブルでの[外部キー](/foreign-key.md)の作成はサポートされていません。 - [`ORDER_INDEX(t1_name, idx1_name [, idx2_name ...])`](/optimizer-hints.md#order_indext1_name-idx1_name--idx2_name-)ヒントは、パーティション化されたテーブルとその関連インデックスには機能しません。パーティション化されたテーブルのインデックスは順番に読み取ることができないためです。 -### パーティショニングキー、プライマリキー、ユニークキー {#partitioning-keys-primary-keys-and-unique-keys} +### パーティショニングキー、主キー、一意キー {#partitioning-keys-primary-keys-and-unique-keys} このセクションでは、パーティショニングキーと主キーおよび一意キーの関係について説明します。この関係を規定するルールは次のとおりです。主キーは定義上一意キーでもあるため、主キーを含むパーティションテーブル上のすべての一意キーは、テーブルのパーティショニング式内のすべての列を使用する必要があります。 @@ -1530,7 +1530,7 @@ CREATE TABLE t_no_pk (c1 INT, c2 INT) Query OK, 0 rows affected (0.12 sec) -`ALTER TABLE`ステートメントを使用すると、一意でないインデックスを追加できます。ただし、一意のインデックスを追加する場合は、 `c1`列を一意のインデックスに含める必要があります。 +`ALTER TABLE`ステートメントを使用すると、一意でないインデックスを追加できます。ただし、一意インデックスを追加する場合は、 `c1`列を一意インデックスに含める必要があります。 パーティションテーブルを使用する場合、プレフィックスインデックスを一意属性として指定することはできません。 diff --git a/pd-configuration-file.md b/pd-configuration-file.md index 2be2b1effc5e2..f2c52dcba7532 100644 --- a/pd-configuration-file.md +++ b/pd-configuration-file.md @@ -74,7 +74,7 @@ PD設定ファイルは、コマンドラインパラメータよりも多くの ### lease {#code-lease-code} -- PDLeaderキーリースのタイムアウト。タイムアウト後、システムはLeaderを再選出します。 +- PDリーダーキーリースのタイムアウト。タイムアウト後、システムはリーダーを再選出します。 - デフォルト値: v8.5.2 以降では、デフォルト値は`5`です。v8.5.2 より前では、デフォルト値は`3`です。 - 単位: 秒 @@ -344,7 +344,7 @@ pd-server関連のコンフィグレーション項目 ### leader-schedule-limit {#code-leader-schedule-limit-code} -- 同時に実行されるLeaderスケジュールタスクの数 +- 同時に実行されるリーダースケジュールタスクの数 - デフォルト値: `4` ### region-schedule-limit {#code-region-schedule-limit-code} @@ -419,11 +419,11 @@ pd-server関連のコンフィグレーション項目 ### store-limit-version v7.1.0 の新機能 {#code-store-limit-version-code-span-class-version-mark-new-in-v7-1-0-span} -- 店舗制限の計算式のバージョンを制御します +- ストア制限の計算式のバージョンを制御します - デフォルト値: `v1` - 値のオプション: - `v1` : v1 モードでは、 `store limit`を手動で変更して、単一の TiKV のスケジュール速度を制限できます。 - - `v2` : v2モードでは、PDがTiKVスナップショットの機能に基づいて動的に調整するため、 `store limit`値を手動で設定する必要はありません。詳細については、 [店舗制限の原則 v2](/configure-store-limit.md#principles-of-store-limit-v2)を参照してください。 + - `v2` : v2モードでは、PDがTiKVスナップショットの機能に基づいて動的に調整するため、 `store limit`値を手動で設定する必要はありません。詳細については、 [ストア制限の原則 v2](/configure-store-limit.md#principles-of-store-limit-v2)を参照してください。 ### enable-joint-consensus 5.0の新機能 {#code-enable-joint-consensus-code-span-class-version-mark-new-in-v5-0-span} @@ -496,12 +496,12 @@ pd-server関連のコンフィグレーション項目 ### key （非推奨） {#code-key-code-deprecated} -- Leaderを拒否した店舗のラベルキー +- リーダーを拒否したストアのラベルキー - デフォルト値: `""` ### value （非推奨） {#code-value-code-deprecated} -- Leaderを拒否した店舗のラベル値 +- リーダーを拒否したストアのラベル値 - デフォルト値: `""` ## dashboard {#code-dashboard-code} diff --git a/pd-control.md b/pd-control.md index 01c5ed147c1d6..3f6665f0f8c23 100644 --- a/pd-control.md +++ b/pd-control.md @@ -289,7 +289,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - `hot-region-cache-hits-threshold` 、ホットリージョンを識別するために必要な分数を設定するために使用されます。PD は、リージョンがこの分数を超えてホットスポット状態になった後にのみ、ホットスポット スケジューリングに参加できます。 -- `tolerant-size-ratio`バランスバッファ領域のサイズを制御します。2つの店舗のリーダーまたはリージョン間のスコア差が、指定されたリージョンサイズの倍数未満の場合、PDはバランスが取れているとみなします。 +- `tolerant-size-ratio`バランスバッファ領域のサイズを制御します。2つのストアのリーダーまたはリージョン間のスコア差が、指定されたリージョンサイズの倍数未満の場合、PDはバランスが取れているとみなします。 ```bash config set tolerant-size-ratio 20 // Set the size of the buffer area to about 20 times of the average Region Size @@ -335,7 +335,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - `store-limit-mode`はストア速度を制限するモードを制御するために使用されます。オプションのモードは`auto`と`manual`です。6 `auto`では、ストアは負荷に応じて自動的にバランス調整されます（非推奨）。 -- `store-limit-version`ストア制限の計算式のバージョンを制御します。v1 モードでは、 `store limit`を手動で変更することで、単一の TiKV のスケジュール速度を制限できます。v2 モードでは、PD が TiKV スナップショットの機能に基づいて 4 の値を動的に調整するため、 `store limit`値を手動で設定する必要はありません。詳細については、 [店舗制限の原則 v2](/configure-store-limit.md#principles-of-store-limit-v2)を参照してください。 +- `store-limit-version`ストア制限の計算式のバージョンを制御します。v1 モードでは、 `store limit`を手動で変更することで、単一の TiKV のスケジュール速度を制限できます。v2 モードでは、PD が TiKV スナップショットの機能に基づいて 4 の値を動的に調整するため、 `store limit`値を手動で設定する必要はありません。詳細については、 [ストア制限の原則 v2](/configure-store-limit.md#principles-of-store-limit-v2)を参照してください。 ```bash config set store-limit-version v2 // using store limit v2 @@ -392,7 +392,7 @@ config set service-middleware audit enable-audit false `service-middleware grpc-rate-limit`次の gRPC API リクエストの最大レートと同時実行性を制御します。 - `GetRegion` : 指定されたリージョンに関する情報を取得する -- `GetStore` : 指定された店舗の情報を取得する +- `GetStore` : 指定されたストアの情報を取得する - `GetMembers` : PDクラスタメンバーに関する情報を取得する gRPC API リクエストの最大レート（ `GetRegion` API リクエストなど）を制御するには、次のコマンドを実行します。 @@ -445,7 +445,7 @@ config set service-middleware grpc-rate-limit GetRegion concurrency 0 `service-middleware rate-limit` 、次の HTTP API 要求の最大レートと同時実行性を制御します。 - `GetRegion` : 指定されたリージョンに関する情報を取得する -- `GetStore` : 指定された店舗の情報を取得する +- `GetStore` : 指定されたストアの情報を取得する `GetRegion` API リクエストなどの HTTP API リクエストの最大レートを制御するには、次のコマンドを実行します。 @@ -1256,7 +1256,7 @@ store remove-tombstone > - ストアのラベルはマージ戦略によって更新されます。TiKVプロセスが再起動されると、その設定ファイル内のストアラベルはPDに保存されているストアラベルとマージされ、マージされた結果が保持されます。マージプロセス中に、PD側とTiKV設定ファイルの間で重複するストアラベルが存在する場合、TiKVストアラベル設定によってPDラベルが上書きされます。例えば、ストア1のストアラベルが`"zone=cn"` ～ `store label 1 zone=cn`に設定されているのに、TiKV設定ファイルに`zone = "us"`設定されている場合、TiKVの再起動後に`"zone"`が`"us"`に更新されます。 > - TiUPを使用してストアのラベルを管理するには、クラスターを再起動する前に、 `store label --force`コマンドを実行して PD に保存されているラベルを空にします。 -#### 店舗の重量を設定する {#configure-store-weight} +#### ストアのウェイトを設定する {#configure-store-weight} ID が 1 のストアのリーダー ウェイトを`5`に、リージョンウェイトを`10`に設定するには、次のコマンドを実行します。 @@ -1264,9 +1264,9 @@ ID が 1 のストアのリーダー ウェイトを`5`に、リージョンウ store weight 1 5 10 ``` -#### 店舗スケジュールの速度を設定する {#configure-store-scheduling-speed} +#### ストアスケジュールの速度を設定する {#configure-store-scheduling-speed} -`store limit`使って店舗のスケジュール速度を設定できます。 `store limit`の原理と使用方法の詳細については、 [`store limit`](/configure-store-limit.md)参照してください。 +`store limit`使ってストアのスケジュール速度を設定できます。 `store limit`の原理と使用方法の詳細については、 [`store limit`](/configure-store-limit.md)参照してください。 ```bash >> store limit // Show the speed limit of adding-peer operations and the limit of removing-peer operations per minute in all stores @@ -1421,7 +1421,7 @@ store --jq='.stores[].store | select(.labels | length>0 and contains([{"key":"en ... ``` -### データを復元するときに関連する地域を探す {#look-for-relevant-regions-when-restoring-data} +### データを復元するときに関連するリージョンを探す {#look-for-relevant-regions-when-restoring-data} たとえば、ダウンタイム時に`[store1, store30, store31]`利用できない場合、ダウンしているレプリカが通常のレプリカよりも多いすべてのリージョンを見つけることができます。 diff --git a/releases/release-1.0-ga.md b/releases/release-1.0-ga.md index 87a33bf7b48c8..4f1a2f548197f 100644 --- a/releases/release-1.0-ga.md +++ b/releases/release-1.0-ga.md @@ -22,7 +22,7 @@ summary: TiDB 1.0は、MySQLとの互換性、SQLの最適化、安定性、そ ## PD {#pd} - 読み取りフローベースのバランス調整をサポート -- ストアの重量と重量ベースのバランス設定をサポート +- ストアのウェイトとウェイトベースのバランス設定をサポート ## TiKV {#tikv} diff --git a/releases/release-1.1-alpha.md b/releases/release-1.1-alpha.md index 22c86cd7e2cf4..85fd6ec6d976c 100644 --- a/releases/release-1.1-alpha.md +++ b/releases/release-1.1-alpha.md @@ -15,7 +15,7 @@ summary: 2018年1月19日にリリースされたTiDB 1.1 Alphaでは、MySQLと - よりコンパクトな構造を使用して、統計情報のメモリ使用量を削減します - tidb-server の起動時に統計情報の読み込みを高速化 - より正確なクエリコスト評価を提供する - - `Count-Min Sketch`使用すると、ユニークインデックスを使用したクエリのコストをより正確に見積もることができます。 + - `Count-Min Sketch`使用すると、一意インデックスを使用したクエリのコストをより正確に見積もることができます。 - インデックスを最大限に活用するために、より複雑な条件をサポートします - SQLエグゼキューター - Chunkアーキテクチャを使用してすべてのエグゼキュータ演算子をリファクタリングし、分析ステートメントの実行パフォーマンスを向上させ、メモリ使用量を削減します。 @@ -42,7 +42,7 @@ summary: 2018年1月19日にリリースされたTiDB 1.1 Alphaでは、MySQLと - Raftスナップショットを最適化し、I/Oオーバーヘッドを削減する - TLSをサポート - RocksDB 構成を最適化してパフォーマンスを向上させる -- コプロセッサーのユニークインデックスの最適化`count (*)`とクエリパフォーマンス +- コプロセッサーの一意インデックスの最適化`count (*)`とクエリパフォーマンス - フェイルポイントと安定性テストケースを追加する - PDとTiKV間の再接続問題を解決する - データ復旧ツール`tikv-ctl`の機能を強化する diff --git a/releases/release-2.0-ga.md b/releases/release-2.0-ga.md index ccdc7c079e106..1919615ba76d8 100644 --- a/releases/release-2.0-ga.md +++ b/releases/release-2.0-ga.md @@ -80,7 +80,7 @@ summary: 2018年4月27日にリリースされたTiDB 2.0 GAでは、MySQLとの - `Drop Region`デバッグインターフェースを追加する - 各PDのヘルスステータスを列挙するためのインターフェースを追加します - 統計 - - 異常な地域に関する統計情報を追加する + - 異常なリージョンに関する統計情報を追加する - リージョン分離レベルに関する統計情報を追加する - スケジュール関連の指標を追加する - パフォーマンス @@ -119,7 +119,7 @@ summary: 2018年4月27日にリリースされたTiDB 2.0 GAでは、MySQLとの - PDリーダーが切り替わったときにgRPC呼び出しが返されない問題を修正しました - スナップショットによってノードがオフラインになる速度が遅くなる問題を修正しました - レプリカの移行によって消費される一時スペースの使用を制限する - - 長期間にわたりリーダーを選出できない地域を報告する + - 長期間にわたりリーダーを選出できないリージョンを報告する - 圧縮イベントに応じてリージョンサイズ情報を随時更新します - リクエストのタイムアウトを回避するためにスキャンロックのサイズを制限する - OOMを回避するためにスナップショットを受信するときにメモリ使用量を制限する diff --git a/releases/release-2.0-rc.3.md b/releases/release-2.0-rc.3.md index d7a42fe686956..7b59526f90955 100644 --- a/releases/release-2.0-rc.3.md +++ b/releases/release-2.0-rc.3.md @@ -33,7 +33,7 @@ summary: 2018年3月23日にリリースされたTiDB 2.0 RC3では、MySQLと - レプリカの追加中に保留中のピアが多数あるノードを無視して、レプリカの復元やノードのオフライン化の速度を向上させます。 - 多数の空きリージョンによって頻繁に発生するスケジュールの問題を修正しました - 異なるラベル内でリソースが不均衡なシナリオにおけるリーダーバランスのスケジューリング速度を最適化します -- 異常な地域に関する統計情報を追加する +- 異常なリージョンに関する統計情報を追加する ## TiKV {#tikv} @@ -51,7 +51,7 @@ summary: 2018年3月23日にリリースされたTiDB 2.0 RC3では、MySQLと - コプロセッサーでのストリーミング集約をサポート - リージョンハートビートで時間情報を伝達する - スナップショットファイルのスペース使用量を制限して、ディスク容量の消費を抑制します。 -- 長期間にわたりリーダーを選出できない地域を記録し報告する + - 長期間にわたりリーダーを選出できないリージョンを記録し報告する - サーバー起動時のガベージクリーンアップを高速化 - 圧縮イベントに応じて対応するリージョンのサイズ情報を更新します - リクエストのタイムアウトを回避するためにサイズを`scan lock`に制限します diff --git a/releases/release-2.0-rc.4.md b/releases/release-2.0-rc.4.md index 11efe9540945c..d64eb691a8868 100644 --- a/releases/release-2.0-rc.4.md +++ b/releases/release-2.0-rc.4.md @@ -13,7 +13,7 @@ summary: 2018年3月30日にリリースされたTiDB 2.0 RC4では、MySQLと - `Expression` in `UnionScan`がクローンされない問題を修正 - `SET TRANSACTION`構文をサポートする - `copIterator`の潜在的な goroutine リーク問題を修正 -- `admin check table` null を含む一意のインデックスを誤って判断する問題を修正 +- `admin check table` null を含む一意インデックスを誤って判断する問題を修正 - 浮動小数点数を科学的記数法で表示することをサポートします - バイナリリテラル計算中の型推論の問題を修正 - `CREATE VIEW`文の解析の問題を修正 diff --git a/releases/release-2.0.3.md b/releases/release-2.0.3.md index 31a465cebb719..ff2205126845e 100644 --- a/releases/release-2.0.3.md +++ b/releases/release-2.0.3.md @@ -1,6 +1,6 @@ --- title: TiDB 2.0.3 Release Notes -summary: TiDB 2.0.3は、システムの互換性と安定性の向上を伴い、2018年6月1日にリリースされました。TiDB、PD、TiKVの様々な修正と最適化が含まれています。主な変更点としては、オンラインでのログレベルの変更のサポート、ユニークインデックスと「ON DUPLICATE KEY UPDATE」に関する問題の修正、特定の状況におけるpanic問題の解決などが挙げられます。 +summary: TiDB 2.0.3は、システムの互換性と安定性の向上を伴い、2018年6月1日にリリースされました。TiDB、PD、TiKVの様々な修正と最適化が含まれています。主な変更点としては、オンラインでのログレベルの変更のサポート、一意インデックスと「ON DUPLICATE KEY UPDATE」に関する問題の修正、特定の状況におけるpanic問題の解決などが挙げられます。 --- # TiDB 2.0.3 リリースノート {#tidb-2-0-3-release-notes} @@ -15,8 +15,8 @@ summary: TiDB 2.0.3は、システムの互換性と安定性の向上を伴い - `BETWEEN`式でクエリ条件のコスト推定を最適化する - `SHOW CREATE TABLE`結果に`FOREIGN KEY`情報を表示しない - `LIMIT`句のクエリのコスト見積りを最適化する -- `YEAR`型をユニークインデックスとして使用する問題を修正 -- ユニークインデックスのない条件の`ON DUPLICATE KEY UPDATE`に関する問題を修正 +- `YEAR`型を一意インデックスとして使用する問題を修正 +- 一意インデックスのない条件の`ON DUPLICATE KEY UPDATE`に関する問題を修正 - `CEIL`機能の互換性の問題を修正 - `DECIMAL`型における`DIV`の計算の精度の問題を修正 - `ADMIN CHECK TABLE`の誤報を修正 diff --git a/releases/release-2.0.5.md b/releases/release-2.0.5.md index 8d2a452bc1098..f26f08cf9dd7f 100644 --- a/releases/release-2.0.5.md +++ b/releases/release-2.0.5.md @@ -13,7 +13,7 @@ summary: TiDB 2.0.5は2018年7月6日にリリースされ、システムの互 - トランザクション[＃6877](https://github.com/pingcap/tidb/pull/6877)自動再試行を無効にするために使用される`tidb_disable_txn_auto_retry`システム変数を追加します - 改善点 - `Selection`のコスト計算を最適化して、結果をより正確にする[＃6989](https://github.com/pingcap/tidb/pull/6989) - - クエリパス[＃6966](https://github.com/pingcap/tidb/pull/6966)として、一意のインデックスまたは主キーに完全に一致するクエリ条件を直接選択します。 + - クエリパス[＃6966](https://github.com/pingcap/tidb/pull/6966)として、一意インデックスまたは主キーに完全に一致するクエリ条件を直接選択します。 - サービス[＃6964](https://github.com/pingcap/tidb/pull/6964)起動に失敗した場合に必要なクリーンアップを実行する - `Load Data`文[＃6962](https://github.com/pingcap/tidb/pull/6962)で`\N` NULL として処理する - CBO [＃6953](https://github.com/pingcap/tidb/pull/6953)のコード構造を最適化する diff --git a/releases/release-2.0.6.md b/releases/release-2.0.6.md index b12820392e359..70a6e1e20c655 100644 --- a/releases/release-2.0.6.md +++ b/releases/release-2.0.6.md @@ -26,7 +26,7 @@ summary: TiDB 2.0.6は、システムの互換性と安定性の向上を伴い - 一部のシナリオでプレフィックスインデックスが間違った結果を返す問題を修正[＃7126](https://github.com/pingcap/tidb/pull/7126) - 一部のシナリオで古い統計情報によって引き起こされるpanicの問題を修正[＃7155](https://github.com/pingcap/tidb/pull/7155) - いくつかのシナリオで`ADD INDEX`操作後にインデックスデータの1つが失われる問題を修正しました[＃7156](https://github.com/pingcap/tidb/pull/7156) - - 一部のシナリオでユニークインデックスを使用して`NULL`値をクエリしたときに間違った結果が返される問題を修正しました[＃7172](https://github.com/pingcap/tidb/pull/7172) + - 一部のシナリオで一意インデックスを使用して`NULL`値をクエリしたときに間違った結果が返される問題を修正しました[＃7172](https://github.com/pingcap/tidb/pull/7172) - いくつかのシナリオにおける`DECIMAL`乗算結果のコードの乱雑な問題を修正[＃7212](https://github.com/pingcap/tidb/pull/7212) - いくつかのシナリオで`DECIMAL`剰余演算の誤った結果の問題を修正[＃7245](https://github.com/pingcap/tidb/pull/7245) - トランザクション内の`UPDATE`ステートメントが`DELETE`いくつかの特殊なステートメントシーケンスで間違った結果を返す問題を修正しました[＃7219](https://github.com/pingcap/tidb/pull/7219) diff --git a/releases/release-2.0.7.md b/releases/release-2.0.7.md index 33f3c7d07a743..0ad1168b6515d 100644 --- a/releases/release-2.0.7.md +++ b/releases/release-2.0.7.md @@ -15,7 +15,7 @@ summary: TiDB 2.0.7は2018年9月7日にリリースされ、システムの互 - SQL文の実行に関する詳細を収集し、その情報を`SLOW QUERY`ログ[＃7364](https://github.com/pingcap/tidb/pull/7364)に出力します。 - `SHOW CREATE TABLE` [＃7388](https://github.com/pingcap/tidb/pull/7388)のパーティション情報をドロップします - `ANALYZE`文を RC 分離レベルと低優先度[＃7500](https://github.com/pingcap/tidb/pull/7500)に設定して実行効率を改善します。 - - ユニークインデックスの追加を高速化[＃7562](https://github.com/pingcap/tidb/pull/7562) + - 一意インデックスの追加を高速化[＃7562](https://github.com/pingcap/tidb/pull/7562) - DDL同時実行を制御するオプションを追加[＃7563](https://github.com/pingcap/tidb/pull/7563) - バグ修正 - 主キーが整数[＃7298](https://github.com/pingcap/tidb/pull/7298)であるテーブルでは`USE INDEX(PRIMARY)`使用できない問題を修正 diff --git a/releases/release-2.1-ga.md b/releases/release-2.1-ga.md index 82ea40ff68d6f..c0bfb4db5583c 100644 --- a/releases/release-2.1-ga.md +++ b/releases/release-2.1-ga.md @@ -184,7 +184,7 @@ summary: TiDB 2.1 GA は 2018 年 11 月 30 日にリリースされ、安定性 - [`jq`を呼び出してJSON出力をフォーマットする](/pd-control.md#jq-formatted-json-output-usage) - - [指定された店舗のリージョン情報を確認する](/pd-control.md#region-store-store_id) + - [指定されたストアのリージョン情報を確認する](/pd-control.md#region-store-store_id) - [バージョン別にソートされた上位Nリージョンリストを確認する](/pd-control.md#region-topconfver-limit) diff --git a/releases/release-2.1-rc.1.md b/releases/release-2.1-rc.1.md index 784cf180da7be..0d6d417b61023 100644 --- a/releases/release-2.1-rc.1.md +++ b/releases/release-2.1-rc.1.md @@ -16,7 +16,7 @@ summary: TiDB 2.1 RC1は2018年8月24日にリリースされ、安定性、SQL - `PREPARE`以外のステートメント[＃7040](https://github.com/pingcap/tidb/pull/7040)のプランキャッシュを削除します - `INSERT`文が解析されず、場合によっては正しく実行されない問題を修正[＃7068](https://github.com/pingcap/tidb/pull/7068) - `IndexJoin`結果が場合によっては正しくない問題を修正[＃7150](https://github.com/pingcap/tidb/pull/7150) - - [＃7163](https://github.com/pingcap/tidb/pull/7163)場合によってはユニークインデックスを使用して`NULL`値が見つからない問題を修正 + - [＃7163](https://github.com/pingcap/tidb/pull/7163)場合によっては一意インデックスを使用して`NULL`値が見つからない問題を修正 - UTF-8 [＃7194](https://github.com/pingcap/tidb/pull/7194)のプレフィックスインデックスの範囲計算の問題を修正 - 場合によっては`Project`演算子を削除することによって結果が正しくなくなる問題を修正しました[＃7257](https://github.com/pingcap/tidb/pull/7257) - 主キーが整数[＃7316](https://github.com/pingcap/tidb/pull/7316)場合に`USE INDEX(PRIMARY)`使用できない問題を修正 diff --git a/releases/release-2.1-rc.2.md b/releases/release-2.1-rc.2.md index f587fe84a876a..1de0a9eb62475 100644 --- a/releases/release-2.1-rc.2.md +++ b/releases/release-2.1-rc.2.md @@ -115,5 +115,5 @@ summary: TiDB 2.1 RC2は2018年9月14日にリリースされ、安定性、SQL - 重要なRaftメッセージのコミットメッセージをブロードキャストして、不要な遅延を回避する[＃3592](https://github.com/tikv/tikv/pull/3592) - バグ修正 - 新しく分割されたリージョン[＃3557](https://github.com/tikv/tikv/pull/3557)の`PreVote`メッセージを破棄することによって発生するリーダー選出の問題を修正しました。 - - 地域[＃3573](https://github.com/tikv/tikv/pull/3573)を統合した後のフォロワー関連の統計を修正 + - リージョン[＃3573](https://github.com/tikv/tikv/pull/3573)を統合した後のフォロワー関連の統計を修正 - ローカルリーダーが古いリージョン情報を使用する問題を修正[＃3565](https://github.com/tikv/tikv/pull/3565) diff --git a/releases/release-2.1-rc.3.md b/releases/release-2.1-rc.3.md index ffc5ba338a4c9..eef82c4ed01d9 100644 --- a/releases/release-2.1-rc.3.md +++ b/releases/release-2.1-rc.3.md @@ -33,7 +33,7 @@ summary: TiDB 2.1 RC3は2018年9月29日にリリースされ、安定性、互 - `JSON_LENGTH`組み込み関数[＃7739](https://github.com/pingcap/tidb/pull/7739)サポート - 符号なし整数型を小数型[＃7792](https://github.com/pingcap/tidb/pull/7792)にキャストする際の誤った結果の問題を修正 - DML - - ユニークキー[＃7675](https://github.com/pingcap/tidb/pull/7675)を更新する際に`INSERT … ON DUPLICATE KEY UPDATE`文の結果が正しくない問題を修正 + - 一意キー[＃7675](https://github.com/pingcap/tidb/pull/7675)を更新する際に`INSERT … ON DUPLICATE KEY UPDATE`文の結果が正しくない問題を修正 - DDL - タイムスタンプ型[＃7724](https://github.com/pingcap/tidb/pull/7724)の新しい列に新しいインデックスを作成するときに、インデックス値がタイムゾーン間で変換されない問題を修正しました。 - 列挙型[＃7767](https://github.com/pingcap/tidb/pull/7767)に新しい値を追加することをサポート diff --git a/releases/release-2.1.17.md b/releases/release-2.1.17.md index 4f9f6e6a4ba75..5ec7cb4d72253 100644 --- a/releases/release-2.1.17.md +++ b/releases/release-2.1.17.md @@ -38,8 +38,8 @@ TiDB Ansible バージョン: 2.1.17 - `SELECT` / `EXPLAIN`文[＃11892](https://github.com/pingcap/tidb/pull/11892)を実行するときに一部の文字列が`INT`型に変換されることで発生する MySQL の非互換性の問題を修正するために`ConvertStrToIntStrict`関数を追加します - `EXPLAIN ... FOR CONNECTION`使用されているときに`stmtCtx`の設定が間違っているために`Explain`結果が正しくない可能性がある問題を修正しました[＃11978](https://github.com/pingcap/tidb/pull/11978) - `unaryMinus`関数によって返される結果が MySQL と互換性がない問題を修正しました。これは、整数結果が[＃11990](https://github.com/pingcap/tidb/pull/11990)オーバーフローしたときに非小数点結果になるためです。 - - `LOAD DATA`文の実行時にカウント順序が原因で`last_insert_id()`間違っている可能性がある問題を修正しました[＃11994](https://github.com/pingcap/tidb/pull/11994) - - ユーザーが自動インクリメント列データを明示的・暗黙的に混合して書き込む場合に`last_insert_id()`間違っている可能性がある問題を修正[＃12001](https://github.com/pingcap/tidb/pull/12001) + - `LOAD DATA`文の実行時にカウント順序が原因で`last_insert_id()`が間違っている可能性がある問題を修正しました[＃11994](https://github.com/pingcap/tidb/pull/11994) + - ユーザーが自動インクリメント列データを明示的・暗黙的に混合して書き込む場合に`last_insert_id()`が間違っている可能性がある問題を修正[＃12001](https://github.com/pingcap/tidb/pull/12001) - 関数`JSON_UNQUOTE`引用符の過剰使用に関するバグを修正しました。二重引用符で囲まれた値 ( `"` ) のみ引用符で囲まないようにします。例えば、「 `SELECT JSON_UNQUOTE("\\\\")` 」の結果は「 `\\` 」（変更なし）になります[＃12096](https://github.com/pingcap/tidb/pull/12096) - サーバ - TiDBトランザクション[＃11878](https://github.com/pingcap/tidb/pull/11878)再試行する際、最後の再試行時刻から最初の実行時刻までの変更`start ts`スロークエリログに記録される diff --git a/releases/release-2.1.18.md b/releases/release-2.1.18.md index 5c750f1781de7..47c9545111582 100644 --- a/releases/release-2.1.18.md +++ b/releases/release-2.1.18.md @@ -49,7 +49,7 @@ TiDB Ansible バージョン: 2.1.18 - 書き込み競合のエラーメッセージにエラーコードを追加して、原因を素早く特定します[＃12878](https://github.com/pingcap/tidb/pull/12878) - DDL - デフォルトでは、列の`AUTO INCREMENT`の属性の削除は許可されません。この属性を削除する必要がある場合は、 `tidb_allow_remove_auto_inc`の変数の値を変更してください。詳細は[システム変数](/system-variables.md#tidb_allow_remove_auto_inc-new-in-v2118-and-v304)参照してください[＃12146](https://github.com/pingcap/tidb/pull/12146) - - `Create Table`文[＃12469](https://github.com/pingcap/tidb/pull/12469)で一意のインデックスを作成するときに複数の`unique`をサポートする + - `Create Table`文[＃12469](https://github.com/pingcap/tidb/pull/12469)で一意インデックスを作成するときに複数の`unique`をサポートする - `CREATE TABLE`ステートメントの外部キー制約にスキーマがない場合、 `No Database selected`エラー[＃12678](https://github.com/pingcap/tidb/pull/12678)を返す代わりに、作成されたテーブルのスキーマを使用するという互換性の問題を修正しました。 - `ADMIN CANCEL DDL JOBS` [＃12681](https://github.com/pingcap/tidb/pull/12681)実行時に`invalid list index`エラーが報告される問題を修正 - モニター diff --git a/releases/release-2.1.3.md b/releases/release-2.1.3.md index 854a563cb0705..53efa1b6e2ffa 100644 --- a/releases/release-2.1.3.md +++ b/releases/release-2.1.3.md @@ -54,4 +54,4 @@ summary: TiDB 2.1.3 および TiDB Ansible 2.1.3 がリリースされ、シス - TiDBBinlog - TiDBの起動または再起動中に発生する`no available pump`問題を修正[＃157](https://github.com/pingcap/tidb-tools/pull/158) - Pumpクライアントログ[＃165](https://github.com/pingcap/tidb-tools/pull/165)の出力を有効にする - - テーブルにユニークキーのみがあり、主キーがない場合に、ユニークキーに NULL 値が含まれることで発生するデータの不整合の問題を修正しました。 + - テーブルに一意キーのみがあり、主キーがない場合に、一意キーに NULL 値が含まれることで発生するデータの不整合の問題を修正しました。 diff --git a/releases/release-2.1.8.md b/releases/release-2.1.8.md index f61b2d42548e3..824a7818900a4 100644 --- a/releases/release-2.1.8.md +++ b/releases/release-2.1.8.md @@ -23,7 +23,7 @@ TiDB Ansible バージョン: 2.1.8 - [＃9963](https://github.com/pingcap/tidb/pull/9963) - [＃9966](https://github.com/pingcap/tidb/pull/9966) - 互換性を向上させるために、 `STR_TO_DATE`機能の`%H`フォーマットをサポートする[＃9964](https://github.com/pingcap/tidb/pull/9964) -- `GROUP_CONCAT`関数が一意のインデックス[＃9969](https://github.com/pingcap/tidb/pull/9969)でグループ化されたときに結果が間違っている問題を修正しました +- `GROUP_CONCAT`関数が一意インデックス[＃9969](https://github.com/pingcap/tidb/pull/9969)でグループ化されたときに結果が間違っている問題を修正しました - オプティマイザヒントに一致しないテーブル名が含まれている場合に警告を返す[＃9970](https://github.com/pingcap/tidb/pull/9970) - ログ形式を統一し、分析ツールを使用してログを収集しやすくする統合ログ形式 - NULL値が多すぎると統計推定が不正確になる問題を修正[＃9979](https://github.com/pingcap/tidb/pull/9979) diff --git a/releases/release-3.0-beta.md b/releases/release-3.0-beta.md index d29076c09961d..c7d3443eebf33 100644 --- a/releases/release-3.0-beta.md +++ b/releases/release-3.0-beta.md @@ -42,7 +42,7 @@ summary: 2019年1月19日にリリースされたTiDB 3.0ベータ版は、安 - 多数の列を持つ幅の広いテーブルの書き込みパフォーマンスを最適化します[＃7935](https://github.com/pingcap/tidb/pull/7935) - サポート`admin show next_row_id` [＃8242](https://github.com/pingcap/tidb/pull/8242) - 実行エンジン[＃8480](https://github.com/pingcap/tidb/pull/8480)で使用される初期Chunkのサイズを制御するための`tidb_init_chunk_size`変数を追加します。 - - `shard_row_id_bits`を改善し、自動増分ID [＃8936](https://github.com/pingcap/tidb/pull/8936)クロスチェックする + - `shard_row_id_bits`を改善し、自動増分ID [＃8936](https://github.com/pingcap/tidb/pull/8936)をクロスチェックする - `Prepare`ステートメント - 異なるユーザー変数が入力されたときにクエリプランが正しいことを保証するために、サブクエリを含む`Prepare`ステートメントをクエリプランキャッシュに追加することを禁止します[＃8064](https://github.com/pingcap/tidb/pull/8064) - クエリプランキャッシュを最適化して、ステートメントに非決定的な関数が含まれている場合にプランがキャッシュされることを保証します[＃8105](https://github.com/pingcap/tidb/pull/8105) diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index ef8380e6b773c..bcf964ed747ee 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -132,7 +132,7 @@ TiDB Ansible バージョン: 3.0.0 - 複数のしきい値を連続して超える場合は、ホットスポットを識別するために`hot-region-cache-hits-threshold`追加します。 - 1 分あたりに許可されるバランスリージョンオペレータの最大数を制御するための`store-balance-rate`構成項目を追加します。 - スケジューラの最適化 - - 各店舗のオペレーターの速度を個別に制御するための店舗制限メカニズムを追加します。 + - 各ストアのオペレーターの速度を個別に制御するためのストア制限メカニズムを追加します。 - 異なるスケジューラ間のリソース競合を最適化するために`waitingOperator`キューをサポートします。 - スケジューリングレート制限をサポートし、TiKVにスケジューリング操作を積極的に送信します。これにより、単一ノード上で同時に実行されるスケジューリングタスクの数を制限することで、スケジューリングレートが向上します。 - 制限機構に制約されないよう`Region Scatter`スケジュールを最適化する diff --git a/releases/release-3.0.0-beta.1.md b/releases/release-3.0.0-beta.1.md index bf2c5bb931d99..341f3299f9cc3 100644 --- a/releases/release-3.0.0-beta.1.md +++ b/releases/release-3.0.0-beta.1.md @@ -76,10 +76,10 @@ TiDB Ansible バージョン: 3.0.0-beta.1 - [ログ形式](https://github.com/tikv/rfcs/blob/master/text/0018-unified-log-format.md)統合してツールによる収集と分析を容易にする - シミュレーター - - 異なる店舗で異なるハートビート間隔をサポート[＃1418](https://github.com/pingcap/pd/pull/1418) + - 異なるストアで異なるハートビート間隔をサポート[＃1418](https://github.com/pingcap/pd/pull/1418) - データのインポートに関するケースを追加[＃1263](https://github.com/pingcap/pd/pull/1263) - ホットスポットのスケジュールを設定可能にする[＃1412](https://github.com/pingcap/pd/pull/1412) -- 以前の店舗ID [＃1429](https://github.com/pingcap/pd/pull/1429)を置き換えるために、ディメンション監視項目として店舗住所を追加します。 +- 以前のストアID [＃1429](https://github.com/pingcap/pd/pull/1429)を置き換えるために、ディメンション監視項目としてストアアドレスを追加します。 - `GetStores`オーバーヘッドを最適化して、リージョン検査サイクル[＃1410](https://github.com/pingcap/pd/pull/1410)高速化します。 - トゥームストーンストア[＃1472](https://github.com/pingcap/pd/pull/1472)を削除するためのインターフェースを追加する diff --git a/releases/release-3.0.0-rc.1.md b/releases/release-3.0.0-rc.1.md index 20094516e706b..dd724b3fa0b6c 100644 --- a/releases/release-3.0.0-rc.1.md +++ b/releases/release-3.0.0-rc.1.md @@ -72,7 +72,7 @@ TiDB Ansible バージョン: 3.0.0-rc.1 - `MergeRegion`オペレータ[＃1495](https://github.com/pingcap/pd/pull/1495)の短すぎるタイムアウト問題を修正 - ホットリージョンのスケジュールに高い優先度を与えるサポート[＃1492](https://github.com/pingcap/pd/pull/1492) - PDサーバー側[＃1502](https://github.com/pingcap/pd/pull/1502)でTSOリクエストの処理時間を記録するためのメトリックを追加します -- 対応する店舗IDと住所を店舗[＃1506](https://github.com/pingcap/pd/pull/1506)に関連する指標に追加します。 +- 対応するストアIDとアドレスをストア関連の指標[＃1506](https://github.com/pingcap/pd/pull/1506)に追加します。 - `GetOperator`サービス[＃1477](https://github.com/pingcap/pd/pull/1477)サポートする - ストアが見つからないため、ハートビートストリームでエラーを送信できない問題を修正しました[＃1521](https://github.com/pingcap/pd/pull/1521) diff --git a/releases/release-3.0.0-rc.2.md b/releases/release-3.0.0-rc.2.md index 2a3a63f12a83b..8bd6e683713e0 100644 --- a/releases/release-3.0.0-rc.2.md +++ b/releases/release-3.0.0-rc.2.md @@ -27,7 +27,7 @@ TiDB Ansible バージョン: 3.0.0-rc.2 - ヒストグラム[＃10573](https://github.com/pingcap/tidb/pull/10573)の`dump`相関`load`サポート - 実行エンジン - - `batchChecker` [＃10370](https://github.com/pingcap/tidb/pull/10370)で重複行をフェッチするときに、一意のインデックスを持つ仮想列を適切に処理します。 + - `batchChecker` [＃10370](https://github.com/pingcap/tidb/pull/10370)で重複行をフェッチするときに、一意インデックスを持つ仮想列を適切に処理します。 - `CHAR`列[＃10124](https://github.com/pingcap/tidb/pull/10124)スキャン範囲計算の問題を修正 - `PointGet`負の数を誤って処理する問題を修正[＃10113](https://github.com/pingcap/tidb/pull/10113) - 同じ名前の関数を`Window`マージして実行効率を向上させる[＃9866](https://github.com/pingcap/tidb/pull/9866) @@ -64,7 +64,7 @@ TiDB Ansible バージョン: 3.0.0-rc.2 - リーダーの優先順位が有効にならない問題を修正[＃1533](https://github.com/pingcap/pd/pull/1533) - `ScanRegions` [＃1535](https://github.com/pingcap/pd/pull/1535)の gRPC インターフェースを追加する - プッシュ演算子をアクティブにする[＃1536](https://github.com/pingcap/pd/pull/1536) -- 各店舗ごとにオペレーターの速度を個別に制御するための店舗制限機構を追加[＃1474](https://github.com/pingcap/pd/pull/1474) +- 各ストアごとにオペレーターの速度を個別に制御するためのストア制限機構を追加[＃1474](https://github.com/pingcap/pd/pull/1474) - 不一致の`Config`ステータス[＃1476](https://github.com/pingcap/pd/pull/1476)の問題を修正 ## TiKV {#tikv} diff --git a/releases/release-3.0.5.md b/releases/release-3.0.5.md index ec93c4ca7a6eb..fb10e1f8d0fc8 100644 --- a/releases/release-3.0.5.md +++ b/releases/release-3.0.5.md @@ -43,7 +43,7 @@ TiDB Ansible バージョン: 3.0.5 - 一部のKVサービスへの接続が遅いため、TiDBの応答速度が比較的遅くなる問題を修正しました[＃12814](https://github.com/pingcap/tidb/pull/12814) - DDL - `Create Table`操作で Set 列[＃12267](https://github.com/pingcap/tidb/pull/12267) Int 型のデフォルト値が正しく設定されない問題を修正しました。 - - `Create Table`文[＃12463](https://github.com/pingcap/tidb/pull/12463)で一意のインデックスを作成するときに複数の`unique`をサポートする + - `Create Table`文[＃12463](https://github.com/pingcap/tidb/pull/12463)で一意インデックスを作成するときに複数の`unique`をサポートする - `Alter Table` [＃12489](https://github.com/pingcap/tidb/pull/12489)を使用してビット型の列を追加するときに、既存の行にこの列のデフォルト値を設定するとエラーが発生する可能性がある問題を修正しました。 - 範囲パーティションテーブルで日付または日時型の列をパーティションキーとして使用している場合にパーティションを追加できない問題を修正[＃12815](https://github.com/pingcap/tidb/pull/12815) - 日付または日時型の列をパーティション キーとして持つ範囲パーティションテーブルの場合、テーブルの作成時またはパーティションの追加時に、パーティション タイプとパーティション キー タイプの一貫性をチェックする機能をサポート[＃12792](https://github.com/pingcap/tidb/pull/12792) @@ -56,7 +56,7 @@ TiDB Ansible バージョン: 3.0.5 - ストレージ - 悲観的トランザクションの新機能を追加: トランザクションクリーンアップインターフェースは、TTLが期限切れのロックのクリーンアップのみをサポートします[＃5589](https://github.com/tikv/tikv/pull/5589) - - トランザクションのロールバックでプライマリキーが折りたたまれる問題を修正[＃5646](https://github.com/tikv/tikv/pull/5646) , [＃5671](https://github.com/tikv/tikv/pull/5671) + - トランザクションのロールバックで主キーが折りたたまれる問題を修正[＃5646](https://github.com/tikv/tikv/pull/5646) , [＃5671](https://github.com/tikv/tikv/pull/5671) - 悲観的ロック下でポイントクエリが以前のバージョンのデータを返す可能性がある問題を修正[＃5634](https://github.com/tikv/tikv/pull/5634) - Raftstore - Raftstoreのメッセージフラッシュ操作を減らしてパフォーマンスを向上させ、CPU 使用率を削減します[＃5617](https://github.com/tikv/tikv/pull/5617) diff --git a/releases/release-4.0.14.md b/releases/release-4.0.14.md index 30d091733a69e..4933a168d0cce 100644 --- a/releases/release-4.0.14.md +++ b/releases/release-4.0.14.md @@ -119,7 +119,7 @@ TiDB バージョン: 4.0.14 - リージョン分散操作中に発生する可能性のあるPDpanic問題を修正しました[＃3761](https://github.com/pingcap/pd/pull/3761) - 一部の演算子の優先順位が正しく設定されていない問題を修正[＃3703](https://github.com/pingcap/pd/pull/3703) - 存在しないストア[＃3660](https://github.com/tikv/pd/issues/3660)から`evict-leader`スケジューラを削除するときに発生する可能性のある PDpanicの問題を修正しました。 - - 店舗数が多い場合にPDLeaderの再選出が遅くなる問題を修正[＃3697](https://github.com/tikv/pd/issues/3697) + - ストア数が多い場合にPDリーダーの再選出が遅くなる問題を修正[＃3697](https://github.com/tikv/pd/issues/3697) - TiDBダッシュボード diff --git a/releases/release-4.0.16.md b/releases/release-4.0.16.md index a0aa657681ca2..3f24e7edec136 100644 --- a/releases/release-4.0.16.md +++ b/releases/release-4.0.16.md @@ -66,7 +66,7 @@ TiDBバージョン: 4.0.16 - `Decimal`を`String`に変換するときに長さ情報が間違っている問題を修正しました[＃29417](https://github.com/pingcap/tidb/issues/29417) - `NATURAL JOIN`複数のテーブルを結合するために使用したときにクエリ結果に余分な列が残る問題を修正[＃29481](https://github.com/pingcap/tidb/issues/29481) - `IndexScan`プレフィックス インデックス[＃29711](https://github.com/pingcap/tidb/issues/29711)を使用している場合に、 `TopN`が誤って`indexPlan`にプッシュダウンされる問題を修正しました。 - - `DOUBLE`種類の自動インクリメント列でトランザクションを再試行するとデータ破損が発生する問題を修正[＃29892](https://github.com/pingcap/tidb/issues/29892) + - `DOUBLE`型のAUTO_INCREMENT列でトランザクションを再試行するとデータ破損が発生する問題を修正[＃29892](https://github.com/pingcap/tidb/issues/29892) - TiKV diff --git a/releases/release-4.0.3.md b/releases/release-4.0.3.md index 805d335659c02..2a8d52e76d553 100644 --- a/releases/release-4.0.3.md +++ b/releases/release-4.0.3.md @@ -114,7 +114,7 @@ TiDB バージョン: 4.0.3 - 生成された列[＃17907](https://github.com/pingcap/tidb/pull/17907)を含むテーブルで`REPLACE INTO`文が機能するときに報告されるエラーを修正します - `IndexHashJoin`と`IndexMergeJoin`ワーカーがpanicときにOOMエラーを返す[＃18527](https://github.com/pingcap/tidb/pull/18527) - `Index Join`で使用されるインデックスに整数の主キー[＃18565](https://github.com/pingcap/tidb/pull/18565)が含まれている場合、特別なケースで`Index Join`実行によって誤った結果が返される可能性があるバグを修正しました。 - - クラスターで新しい照合順序が有効になっている場合、トランザクションで新しい照合順序を持つ列に更新されたデータが一意のインデックス[＃18703](https://github.com/pingcap/tidb/pull/18703)を通じて読み取れない問題を修正しました。 + - クラスターで新しい照合順序が有効になっている場合、トランザクションで新しい照合順序を持つ列に更新されたデータが一意インデックス[＃18703](https://github.com/pingcap/tidb/pull/18703)を通じて読み取れない問題を修正しました。 - TiKV @@ -128,7 +128,7 @@ TiDB バージョン: 4.0.3 - スケジューラを削除するとデッドロックが発生する可能性がある問題を修正[＃2637](https://github.com/pingcap/pd/pull/2637) - `balance-leader-scheduler`が有効になっているときに配置ルールが考慮されないバグを修正[＃2636](https://github.com/pingcap/pd/pull/2636) - サービス`safepoint`が正しく設定されない場合があり、 BRとDumplingが失敗する可能性がある問題を修正[＃2635](https://github.com/pingcap/pd/pull/2635) - - `hot region scheduler`の対象店舗が誤って選択されている問題を修正[＃2627](https://github.com/pingcap/pd/pull/2627) + - `hot region scheduler`の対象ストアが誤って選択されている問題を修正[＃2627](https://github.com/pingcap/pd/pull/2627) - PDリーダーが切り替えられたときにTSOリクエストに時間がかかりすぎる可能性がある問題を修正[＃2622](https://github.com/pingcap/pd/pull/2622) - リーダー変更後の古いスケジューラの問題を修正[＃2608](https://github.com/pingcap/pd/pull/2608) - 配置ルールが有効になっているときに、リージョンのレプリカを最適な場所に調整できないことがある問題を修正しました[＃2605](https://github.com/pingcap/pd/pull/2605) diff --git a/releases/release-4.0.5.md b/releases/release-4.0.5.md index 4b17c54494a5b..caad7b3d9d4fc 100644 --- a/releases/release-4.0.5.md +++ b/releases/release-4.0.5.md @@ -58,7 +58,7 @@ TiDB バージョン: 4.0.5 - PD - - 特別なエンジン（ TiFlashなど）を備えた店舗での散乱領域のサポート[＃2706](https://github.com/tikv/pd/pull/2706) + - 特別なエンジン（ TiFlashなど）を備えたストアでのリージョン再配置のサポート[＃2706](https://github.com/tikv/pd/pull/2706) - 特定のキー範囲[＃2687](https://github.com/tikv/pd/pull/2687)のリージョンスケジュールを優先するリージョンHTTP API をサポートします。 - リージョン分散[＃2684](https://github.com/tikv/pd/pull/2684)後のリーダー分布の改善 - TSOリクエスト[＃2678](https://github.com/tikv/pd/pull/2678)テストとログを追加する @@ -167,7 +167,7 @@ TiDB バージョン: 4.0.5 - TiCDC - 失敗した`changefeed`削除できない問題を修正[＃782](https://github.com/pingcap/tiflow/pull/782) - - ハンドルインデックス[＃787](https://github.com/pingcap/tiflow/pull/787)として1つの一意のインデックスを選択して無効なイベント`delete`修正します + - ハンドルインデックス[＃787](https://github.com/pingcap/tiflow/pull/787)として1つの一意インデックスを選択して無効なイベント`delete`修正します - GCセーフポイントが停止した`changefeed` [＃797](https://github.com/pingcap/tiflow/pull/797)のチェックポイントを超えて転送されるバグを修正 - ネットワークI/O待機によりタスクの終了がブロックされるバグを修正[＃825](https://github.com/pingcap/tiflow/pull/825) - 不要なデータが誤って下流に複製される可能性があるバグを修正[＃743](https://github.com/pingcap/tiflow/issues/743) diff --git a/releases/release-4.0.6.md b/releases/release-4.0.6.md index e44b4a0b68b4c..2ccbdd093b6fd 100644 --- a/releases/release-4.0.6.md +++ b/releases/release-4.0.6.md @@ -18,7 +18,7 @@ TiDB バージョン: 4.0.6 - TiDBダッシュボード - クエリエディタと実行UIの追加（実験的） [＃713](https://github.com/pingcap-incubator/tidb-dashboard/pull/713) - - 店舗ロケーショントポロジ可視化[＃719](https://github.com/pingcap-incubator/tidb-dashboard/pull/719)サポート + - ストアロケーショントポロジ可視化[＃719](https://github.com/pingcap-incubator/tidb-dashboard/pull/719)サポート - クラスタ構成UIの追加（実験的） [＃733](https://github.com/pingcap-incubator/tidb-dashboard/pull/733) - 現在のセッション[＃741](https://github.com/pingcap-incubator/tidb-dashboard/pull/741)共有をサポート - SQLステートメントリスト[＃746](https://github.com/pingcap-incubator/tidb-dashboard/pull/746)で実行プランの数を表示する機能をサポート @@ -158,7 +158,7 @@ TiDB バージョン: 4.0.6 - PD - ブートストラップ[＃2922](https://github.com/pingcap/pd/pull/2922)中に異なるクラスタが相互に通信するのを防ぐために、 `initial-cluster-token`構成を追加します。 - - モードが`auto` [＃2826](https://github.com/pingcap/pd/pull/2826)ときの店舗制限レートの単位を修正 + - モードが`auto` [＃2826](https://github.com/pingcap/pd/pull/2826)ときのストア制限レートの単位を修正 - 一部のスケジューラがエラーを解決せずに構成を保持する問題を修正[＃2818](https://github.com/tikv/pd/pull/2818) - スケジューラ[＃2871](https://github.com/tikv/pd/pull/2871) [＃2874](https://github.com/tikv/pd/pull/2874)空のHTTPレスポンスを修正 @@ -185,11 +185,11 @@ TiDB バージョン: 4.0.6 - バックアップと復元 (BR) - チェックサム[＃479](https://github.com/pingcap/br/pull/479)中に発生する可能性のあるpanicを修正 - - PDLeader[＃496](https://github.com/pingcap/br/pull/496)の変更後に発生する可能性のあるpanicを修正 + - PDリーダー[＃496](https://github.com/pingcap/br/pull/496)の変更後に発生する可能性のあるpanicを修正 - Dumpling - - バイナリタイプの`NULL`値が正しく処理されない問題を修正しました[＃137](https://github.com/pingcap/dumpling/pull/137) + - バイナリ型の`NULL`値が正しく処理されない問題を修正しました[＃137](https://github.com/pingcap/dumpling/pull/137) - TiDB Lightning diff --git a/releases/release-4.0.9.md b/releases/release-4.0.9.md index b6b1147c5f6ab..cec5ffcae81b3 100644 --- a/releases/release-4.0.9.md +++ b/releases/release-4.0.9.md @@ -111,7 +111,7 @@ TiDB バージョン: 4.0.9 - TiDB Lightning - デフォルトですべてのシステムスキーマを除外する[＃459](https://github.com/pingcap/tidb-lightning/pull/459) - - ローカルバックエンドまたはインポーターバックエンド[＃457](https://github.com/pingcap/tidb-lightning/pull/457)の自動ランダム主キーのデフォルト値の設定をサポート + - ローカルバックエンドまたはインポーターバックエンド[＃457](https://github.com/pingcap/tidb-lightning/pull/457)のAUTO_RANDOM主キーのデフォルト値の設定をサポート - 範囲プロパティを使用して、Local-backend [＃422](https://github.com/pingcap/tidb-lightning/pull/422)で範囲分割をより正確にします。 - `tikv-importer.region-split-size` `mydumper.batch-size`人間が[＃471](https://github.com/pingcap/tidb-lightning/pull/471)形式（「2.5 GiB」など） `mydumper.read-block-size`サポートする`mydumper.max-region-size` @@ -153,7 +153,7 @@ TiDB バージョン: 4.0.9 - `varchar`または`char`の長さ制約を超える末尾のスペースを含む文字列を挿入できないバグを修正しました[＃21282](https://github.com/pingcap/tidb/pull/21282) - `int`と`year`と[＃21283](https://github.com/pingcap/tidb/pull/21283)比較するときに、整数が`[1, 69]`から`[2001, 2069]`または`[70, 99]`から`[1970, 1999]`に変換されないバグを修正しました。 - `Double`型フィールド[＃21272](https://github.com/pingcap/tidb/pull/21272)を計算するときに`sum()`関数の結果がオーバーフローすることによって引き起こされるpanicを修正しました - - `DELETE`ユニークキー[＃20705](https://github.com/pingcap/tidb/pull/20705)にロックを追加できないバグを修正 + - `DELETE`一意キー[＃20705](https://github.com/pingcap/tidb/pull/20705)にロックを追加できないバグを修正 - スナップショットの読み取りがロックキャッシュ[＃21539](https://github.com/pingcap/tidb/pull/21539)にヒットするバグを修正 - 長時間トランザクションで大量のデータを読み込んだ後に発生する可能性のあるメモリリークの問題を修正[＃21129](https://github.com/pingcap/tidb/pull/21129) - サブクエリでテーブルエイリアスを省略すると構文エラーが返される問題を修正しました[＃20367](https://github.com/pingcap/tidb/pull/20367) diff --git a/releases/release-5.0.0.md b/releases/release-5.0.0.md index 517e7a7c2f831..d21a4161820ea 100644 --- a/releases/release-5.0.0.md +++ b/releases/release-5.0.0.md @@ -1,6 +1,6 @@ --- title: What's New in TiDB 5.0 -summary: TiDB 5.0では、MPPアーキテクチャ、クラスタ化インデックス、非同期コミット、および安定性の向上が導入されています。また、互換性の変更、構成パラメータ、および新機能も強化されています。さらに、パフォーマンス、高可用性、ディザスタリカバリ、データ移行、診断、デプロイ、およびメンテナンスが最適化されています。クラスタの使用状況メトリクス用のテレメトリ機能も追加されています。 +summary: TiDB 5.0では、MPPアーキテクチャ、クラスター化インデックス、非同期コミット、および安定性の向上が導入されています。また、互換性の変更、構成パラメータ、および新機能も強化されています。さらに、パフォーマンス、高可用性、ディザスタリカバリ、データ移行、診断、デプロイ、およびメンテナンスが最適化されています。クラスタの使用状況メトリクス用のテレメトリ機能も追加されています。 --- # TiDB 5.0の新機能 {#what-s-new-in-tidb-5-0} @@ -14,7 +14,7 @@ TiDB バージョン: 5.0.0 バージョン5.0における主な新機能または改善点は以下のとおりです。 - TiFlashノードを介して大規模並列処理（MPP）アーキテクチャを導入し、大規模な結合クエリの実行ワークロードをTiFlashノード間で共有します。MPPモードが有効になっている場合、TiDBはコストに基づいて、計算を実行するためにMPPフレームワークを使用するかどうかを決定します。MPPモードでは、結合キーは計算中に`Exchange`操作によって再分配され、計算負荷が各TiFlashノードに分散され、計算が高速化されます。ベンチマークによると、同じクラスタリソースを使用した場合、TiDB 5.0 MPPはGreenplum 6.15.0およびApache Spark 3.1.1と比較して2～3倍高速化され、一部のクエリでは8倍のパフォーマンス向上を実現しています。 -- データベースのパフォーマンスを向上させるために、クラスタ化インデックス機能を導入します。例えば、TPC-C tpmCテストでは、クラスタ化インデックスを有効にしたTiDBのパフォーマンスは39%向上しました。 +- データベースのパフォーマンスを向上させるために、クラスター化インデックス機能を導入します。例えば、TPC-C tpmCテストでは、クラスター化インデックスを有効にしたTiDBのパフォーマンスは39%向上しました。 - 非同期コミット機能を有効にすると、書き込みレイテンシーを削減できます。例えば、64スレッドのSysbenchテストでは、非同期コミットを有効にした場合、インデックス更新の平均レイテンシーは12.04msから7.01msへと41.7%削減されます。 - ジッターを低減します。これは、オプティマイザの安定性を向上させ、システムタスクによるI/O、ネットワーク、CPU、メモリリソースの使用を制限することによって実現されます。例えば、8時間のパフォーマンステストでは、TPC-C tpmCの標準偏差は2%を超えません。 - スケジューリングを改善し、実行計画を可能な限り安定させることで、システムの安定性を向上させる。 @@ -57,7 +57,7 @@ TiDB バージョン: 5.0.0 - `OFF` : クラスター化インデックスは無効になっています。非クラスター化インデックスの追加または削除はサポートされています。 - - `INT_ONLY` : デフォルト値。動作はv5.0以前と同じです。 `alter-primary-key = false`と併せて、INT型のクラスタ化インデックスを有効にするかどうかを制御できます。 + - `INT_ONLY` : デフォルト値。動作はv5.0以前と同じです。 `alter-primary-key = false`と併せて、INT型のクラスター化インデックスを有効にするかどうかを制御できます。 > **注記：** > > 5.0 GA の`INT_ONLY`の`tidb_enable_clustered_index`値は、5.0 RC の`OFF`値と同じ意味です。 `OFF`設定の 5.0 RC クラスターから 5.0 GA にアップグレードすると、 `INT_ONLY`と表示されます。 @@ -127,7 +127,7 @@ List COLUMNS パーティショニングを有効にするには、セッショ この機能はデフォルトでは無効になっています。機能を有効にするには、システム変数`tidb_enable_amend_pessimistic_txn`の値を変更してください。この機能はバージョン 4.0.7 で導入され、バージョン 5.0 で以下の問題が修正されています。 - TiDB Binlog が`Add Column`操作を実行する際に発生する互換性の問題 -- ユニークインデックスとこの機能を併用した場合に発生するデータ不整合の問題 +- 一意インデックスとこの機能を併用した場合に発生するデータ不整合の問題 - 追加されたインデックスとこの機能を併用した場合に発生するデータ不整合の問題 現在、この機能には以下の互換性の問題が残っています。 @@ -183,23 +183,23 @@ TPC-H 100ベンチマークテストにおいて、 TiFlash MPPは従来の分 [ユーザー向けドキュメント](/clustered-indexes.md)、 [#4841](https://github.com/pingcap/tidb/issues/4841) -テーブル構造を設計したり、データベースの動作を分析したりする際に、主キーを持つ一部の列が頻繁にグループ化およびソートされ、これらの列に対するクエリが特定の範囲のデータまたは異なる値を持つ少量のデータを頻繁に返し、対応するデータが読み取りまたは書き込みのホットスポット問題を引き起こさないことがわかった場合は、クラスタ化インデックス機能を使用することをお勧めします。 +テーブル構造を設計したり、データベースの動作を分析したりする際に、主キーを持つ一部の列が頻繁にグループ化およびソートされ、これらの列に対するクエリが特定の範囲のデータまたは異なる値を持つ少量のデータを頻繁に返し、対応するデータが読み取りまたは書き込みのホットスポット問題を引き起こさないことがわかった場合は、クラスター化インデックス機能を使用することをお勧めします。 -クラスタ化インデックスは、テーブルのデータに関連付けられたストレージ構造です。一部のデータベース管理システムでは、クラスタ化インデックステーブルを*インデックス構成テーブル*と呼びます。クラスタ化インデックスを作成する際には、テーブルの1つ以上の列をインデックスのキーとして指定できます。TiDBはこれらのキーを特定の構造に格納するため、キーに関連付けられた行を迅速かつ効率的に検索でき、クエリとデータ書き込みのパフォーマンスが向上します。 +クラスター化インデックスは、テーブルのデータに関連付けられたストレージ構造です。一部のデータベース管理システムでは、クラスター化インデックステーブルを*インデックス構成テーブル*と呼びます。クラスター化インデックスを作成する際には、テーブルの1つ以上の列をインデックスのキーとして指定できます。TiDBはこれらのキーを特定の構造に格納するため、キーに関連付けられた行を迅速かつ効率的に検索でき、クエリとデータ書き込みのパフォーマンスが向上します。 -クラスタ化インデックス機能を有効にすると、TiDB のパフォーマンスは大幅に向上します (例えば、TPC-C tpmC テストでは、クラスタ化インデックスを有効にした TiDB のパフォーマンスは、以下のケースで 39% 向上します)。 +クラスター化インデックス機能を有効にすると、TiDB のパフォーマンスは大幅に向上します (例えば、TPC-C tpmC テストでは、クラスター化インデックスを有効にした TiDB のパフォーマンスは、以下のケースで 39% 向上します)。 -- データが挿入される際、クラスタ化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 -- 同等の条件を持つクエリが主キーのみに関係する場合、クラスタ化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 -- 範囲条件を含むクエリが主キーのみに関係する場合、クラスタ化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 -- 同等条件または範囲条件を含むクエリに主キーのプレフィックスが含まれる場合、クラスタ化インデックスによってネットワークからのインデックスデータの読み取り回数が削減されます。 +- データが挿入される際、クラスター化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 +- 同等の条件を持つクエリが主キーのみに関係する場合、クラスター化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 +- 範囲条件を含むクエリが主キーのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 +- 同等条件または範囲条件を含むクエリに主キーのプレフィックスが含まれる場合、クラスター化インデックスによってネットワークからのインデックスデータの読み取り回数が削減されます。 -各テーブルは、クラスタ化インデックスまたは非クラスタ化インデックスのいずれかを使用してデータをソートおよび格納できます。これら2つのストレージ構造の違いは次のとおりです。 +各テーブルは、クラスター化インデックスまたは非クラスター化インデックスのいずれかを使用してデータをソートおよび格納できます。これら2つのストレージ構造の違いは次のとおりです。 - クラスター化インデックスを作成する際、テーブル内の1つまたは複数の列をインデックスのキー値として指定できます。クラスター化インデックスは、キー値に基づいてテーブルのデータをソートして格納します。各テーブルには、クラスター化インデックスを1つだけ設定できます。テーブルにクラスター化インデックスがある場合、そのテーブルはクラスター化インデックステーブルと呼ばれます。そうでない場合は、非クラスター化インデックステーブルと呼ばれます。 -- 非クラスタ化インデックスを作成すると、テーブル内のデータは順不同構造で格納されます。TiDBは各データ行に一意のROWIDを自動的に割り当てるため、非クラスタ化インデックスのキー値を明示的に指定する必要はありません。クエリ実行時には、ROWIDを使用して対応する行が特定されます。データのクエリまたは挿入時には少なくとも2回のネットワークI/O操作が発生するため、クラスタ化インデックスと比較してパフォーマンスが低下します。 +- 非クラスター化インデックスを作成すると、テーブル内のデータは順不同構造で格納されます。TiDBは各データ行に一意のROWIDを自動的に割り当てるため、非クラスター化インデックスのキー値を明示的に指定する必要はありません。クエリ実行時には、ROWIDを使用して対応する行が特定されます。データのクエリまたは挿入時には少なくとも2回のネットワークI/O操作が発生するため、クラスター化インデックスと比較してパフォーマンスが低下します。 -テーブルデータが変更されると、データベースシステムはクラスタ化インデックスと非クラスタ化インデックスを自動的に維持します。 +テーブルデータが変更されると、データベースシステムはクラスター化インデックスと非クラスター化インデックスを自動的に維持します。 デフォルトでは、すべての主キーは非クラスター化インデックスとして作成されます。主キーをクラスター化インデックスまたは非クラスター化インデックスとして作成するには、次の 2 つの方法のいずれかを使用できます。 @@ -215,29 +215,29 @@ CREATE TABLE `t` (`a` VARCHAR(255), `b` INT, PRIMARY KEY (`a`, `b`) CLUSTERED); CREATE TABLE `t` (`a` VARCHAR(255) PRIMARY KEY CLUSTERED, `b` INT); ``` -テーブルにクラスタ化インデックスがあるかどうかを照会するには`SHOW INDEX FROM tbl-name`というステートメントを実行します。 +テーブルにクラスター化インデックスがあるかどうかを照会するには`SHOW INDEX FROM tbl-name`というステートメントを実行します。 -- クラスタ化インデックス機能を制御するには、システム変数`tidb_enable_clustered_index`を設定します。サポートされている値は、 `ON` 、 `OFF` 、および`INT_ONLY` 。 - - `ON` : すべてのタイプの主キーに対してクラスタ化インデックス機能が有効になっていることを示します。非クラスタ化インデックスの追加と削除がサポートされています。 - - `OFF` : すべてのタイプの主キーに対して、クラスタ化インデックス機能が無効になっていることを示します。非クラスタ化インデックスの追加と削除はサポートされています。 - - `INT_ONLY` : デフォルト値。変数が`INT_ONLY`に設定され、 `alter-primary-key`が`false`に設定されている場合、単一の整数列で構成される主キーは、デフォルトでクラスタ化インデックスとして作成されます。この動作は、TiDB v5.0 およびそれ以前のバージョンと同様です。 +- クラスター化インデックス機能を制御するには、システム変数`tidb_enable_clustered_index`を設定します。サポートされている値は、 `ON` 、 `OFF` 、および`INT_ONLY` 。 + - `ON` : すべてのタイプの主キーに対してクラスター化インデックス機能が有効になっていることを示します。非クラスター化インデックスの追加と削除がサポートされています。 + - `OFF` : すべてのタイプの主キーに対して、クラスター化インデックス機能が無効になっていることを示します。非クラスター化インデックスの追加と削除はサポートされています。 + - `INT_ONLY` : デフォルト値。変数が`INT_ONLY`に設定され、 `alter-primary-key`が`false`に設定されている場合、単一の整数列で構成される主キーは、デフォルトでクラスター化インデックスとして作成されます。この動作は、TiDB v5.0 およびそれ以前のバージョンと同様です。 `CREATE TABLE`ステートメントにキーワード`CLUSTERED | NONCLUSTERED`が含まれている場合、そのステートメントはシステム変数と構成項目の設定を上書きします。 -ステートメントでキーワード`CLUSTERED | NONCLUSTERED`指定して、クラスタ化インデックス機能を使用することをお勧めします。この方法により、TiDB は必要に応じてシステム内のクラスタ化インデックスと非クラスタ化インデックスのすべてのデータ型を同時に使用できるようになり、より柔軟に対応できます。 +ステートメントでキーワード`CLUSTERED | NONCLUSTERED`指定して、クラスター化インデックス機能を使用することをお勧めします。この方法により、TiDB は必要に応じてシステム内のクラスター化インデックスと非クラスター化インデックスのすべてのデータ型を同時に使用できるようになり、より柔軟に対応できます。 `tidb_enable_clustered_index = INT_ONLY`の使用は推奨されません。 `INT_ONLY`は、この機能の互換性を確保するために一時的に使用されており、将来的に廃止される予定です。 -クラスタ化インデックスの制限事項は以下のとおりです。 +クラスター化インデックスの制限事項は以下のとおりです。 -- クラスタ化インデックスと非クラスタ化インデックス間の相互変換はサポートされていません。 +- クラスター化インデックスと非クラスター化インデックス間の相互変換はサポートされていません。 - クラスター化インデックスの削除はサポートされていません。 -- `ALTER TABLE`ステートメントを使用したクラスタ化インデックスの追加、削除、および変更はサポートされていません。 -- クラスタ化インデックスの再編成および再作成はサポートされていません。 -- インデックスの有効化または無効化はサポートされていないため、非表示インデックス機能はクラスタ化インデックスには適用されません。 -- `UNIQUE KEY`をクラスタ化インデックスとして作成することはサポートされていません。 -- TiDB Binlogとクラスタ化インデックス機能を併用することはサポートされていません。TiDB Binlog を有効にすると、TiDB は単一の整数プライマリキーのみをクラスタ化インデックスとして作成することをサポートします。TiDB Binlog は、クラスタ化インデックスを持つ既存のテーブルのデータ変更をダウンストリームにレプリケートしません。 -- クラスタ化インデックス機能を属性`SHARD_ROW_ID_BITS`および`PRE_SPLIT_REGIONS`と併用することはサポートされていません。 +- `ALTER TABLE`ステートメントを使用したクラスター化インデックスの追加、削除、および変更はサポートされていません。 +- クラスター化インデックスの再編成および再作成はサポートされていません。 +- インデックスの有効化または無効化はサポートされていないため、非表示インデックス機能はクラスター化インデックスには適用されません。 +- `UNIQUE KEY`をクラスター化インデックスとして作成することはサポートされていません。 +- TiDB Binlogとクラスター化インデックス機能を併用することはサポートされていません。TiDB Binlog を有効にすると、TiDB は単一の整数主キーのみをクラスター化インデックスとして作成することをサポートします。TiDB Binlog は、クラスター化インデックスを持つ既存のテーブルのデータ変更をダウンストリームにレプリケートしません。 +- クラスター化インデックス機能を属性`SHARD_ROW_ID_BITS`および`PRE_SPLIT_REGIONS`と併用することはサポートされていません。 - クラスターを新しいバージョンにアップグレードした後、ロールバックした場合、ロールバック前にテーブルデータをエクスポートし、ロールバック後にデータをインポートすることで、新しく追加されたテーブルをダウングレードする必要があります。その他のテーブルは影響を受けません。 ### 非同期コミット {#async-commit} diff --git a/releases/release-5.0.1.md b/releases/release-5.0.1.md index c75d426f9ab80..81cb2db8832f4 100644 --- a/releases/release-5.0.1.md +++ b/releases/release-5.0.1.md @@ -42,7 +42,7 @@ TiDB バージョン: 5.0.1 - 列に`NULL`値が含まれている場合に間違ったクエリ結果が表示される問題を修正しました[＃24063](https://github.com/pingcap/tidb/pull/24063) - スキャンに仮想列[＃24058](https://github.com/pingcap/tidb/pull/24058)が含まれている場合、MPP プランの生成を禁止します。 - プランキャッシュ[＃24043](https://github.com/pingcap/tidb/pull/24043)の`PointGet`と`TableDual`の誤った再利用を修正 - - オプティマイザがクラスタ化インデックス[＃24042](https://github.com/pingcap/tidb/pull/24042) `IndexMerge`プランを構築するときに発生するエラーを修正します + - オプティマイザがクラスター化インデックス[＃24042](https://github.com/pingcap/tidb/pull/24042) `IndexMerge`プランを構築するときに発生するエラーを修正します - BIT型エラーの型推論を修正[＃24027](https://github.com/pingcap/tidb/pull/24027) - `PointGet`演算子が存在する場合に一部のオプティマイザヒントが有効にならない問題を修正[＃23685](https://github.com/pingcap/tidb/pull/23685) - エラー[＃24080](https://github.com/pingcap/tidb/pull/24080)によりロールバック時にDDL操作が失敗する可能性がある問題を修正 diff --git a/releases/release-5.0.2.md b/releases/release-5.0.2.md index 97ab0fefa13fd..9cf7cc72c4519 100644 --- a/releases/release-5.0.2.md +++ b/releases/release-5.0.2.md @@ -90,7 +90,7 @@ TiDB バージョン: 5.0.2 - PD - - 店舗数が多い場合にPDLeaderの再選出が遅くなる問題を修正[＃3697](https://github.com/tikv/pd/issues/3697) + - ストア数が多い場合にPDリーダーの再選出が遅くなる問題を修正[＃3697](https://github.com/tikv/pd/issues/3697) - 存在しないストア[＃3660](https://github.com/tikv/pd/issues/3660)からエビクト リーダー スケジューラを削除するときに発生するpanic問題を修正しました - オフラインピアがマージされた後に統計が更新されない問題を修正[＃3611](https://github.com/tikv/pd/issues/3611) diff --git a/releases/release-5.0.4.md b/releases/release-5.0.4.md index 9264828dd4c72..f408d7cb64632 100644 --- a/releases/release-5.0.4.md +++ b/releases/release-5.0.4.md @@ -31,7 +31,7 @@ TiDB バージョン: 5.0.4 - `SQL_MODE` 「NO_ZERO_IN_DATE」の場合に無効なデフォルト日付を使用してもエラーが報告されない問題を修正しました[＃26766](https://github.com/pingcap/tidb/issues/26766) - プレフィックスインデックス[＃26029](https://github.com/pingcap/tidb/issues/26029)のクエリ範囲に関するバグを修正 - `LOAD DATA`文が非 UTF8 データを異常にインポートする可能性がある問題を修正[＃25979](https://github.com/pingcap/tidb/issues/25979) - - `insert ignore on duplicate update`セカンダリインデックスにプライマリキーと同じ列がある場合に間違ったデータが挿入される可能性がある問題を修正[＃25809](https://github.com/pingcap/tidb/issues/25809) + - `insert ignore on duplicate update`セカンダリインデックスに主キーと同じ列がある場合に間違ったデータが挿入される可能性がある問題を修正[＃25809](https://github.com/pingcap/tidb/issues/25809) - パーティションテーブルにクラスター化インデックスがある場合に間違ったデータが挿入される可能性が`insert ignore duplicate update`問題を修正しました[＃25846](https://github.com/pingcap/tidb/issues/25846) - ポイント取得またはバッチポイント取得[＃24562](https://github.com/pingcap/tidb/issues/24562)でキーが`ENUM`型の場合にクエリ結果が間違っている可能性がある問題を修正しました - `BIT`型の値を[＃23479](https://github.com/pingcap/tidb/issues/23479)割ったときに発生する誤った結果を修正しました diff --git a/releases/release-5.0.6.md b/releases/release-5.0.6.md index c09545ed8ef4a..de89f3c6c0038 100644 --- a/releases/release-5.0.6.md +++ b/releases/release-5.0.6.md @@ -166,4 +166,4 @@ TiDB バージョン: 5.0.6 - Dumpling - - 複合主キーまたはユニークキー[＃29386](https://github.com/pingcap/tidb/issues/29386)を持つテーブルをダンプするときにDumplingが非常に遅くなるバグを修正しました + - 複合主キーまたは一意キー[＃29386](https://github.com/pingcap/tidb/issues/29386)を持つテーブルをダンプするときにDumplingが非常に遅くなるバグを修正しました diff --git a/releases/release-5.1.0.md b/releases/release-5.1.0.md index bad8aed9dbd35..daf204dbbda4b 100644 --- a/releases/release-5.1.0.md +++ b/releases/release-5.1.0.md @@ -61,7 +61,7 @@ TiDB バージョン: 5.1.0 - アップグレード前に、TiDB構成の[`feedback-probability`](https://docs-archive.pingcap.com/tidb/v5.1/tidb-configuration-file#feedback-probability)の値を確認してください。値が0でない場合、アップグレード後に「回復可能なゴルーチンでpanicが発生しました」というエラーが発生しますが、このエラーはアップグレード自体には影響しません。 - TiDBのパフォーマンスを向上させるため、TiDBのGoコンパイラバージョンをgo1.13.7からgo1.16.4にアップグレードしてください。TiDB開発者の方は、スムーズなコンパイルを保証するために、Goコンパイラバージョンをアップグレードすることをお勧めします。 -- TiDBローリングアップグレード中は、TiDB Binlogを使用するクラスタでクラスタ化インデックスを持つテーブルを作成しないようにしてください。 +- TiDBローリングアップグレード中は、TiDB Binlogを使用するクラスタでクラスター化インデックスを持つテーブルを作成しないようにしてください。 - TiDB のローリングアップグレード中は`alter table ... modify column`や`alter table ... change column`のようなステートメントを実行しないでください。 - バージョン5.1以降、各テーブルのTiFlashレプリカを作成する際に、システムテーブルのレプリカを設定する機能はサポートされなくなりました。クラスタをアップグレードする前に、関連するシステムテーブルのレプリカをクリアする必要があります。クリアしないと、アップグレードは失敗します。 - TiCDC の`--sort-dir`コマンドの`cdc cli changefeed`パラメータは非推奨です。代わりに、 `--sort-dir`コマンドで`cdc server` } を設定できます。 [#1795](https://github.com/pingcap/tiflow/pull/1795) @@ -294,13 +294,13 @@ TiDBは、実行ステータスと失敗ステータスを含む、TiDBクラス - SSTファイルをバッチ処理で取り込んだ後に、多数のリージョンが空になる問題を修正しました [#964](https://github.com/pingcap/br/issues/964) - ファイル辞書ファイルが破損した後にTiKVが起動できないバグを修正しました [#9886](https://github.com/tikv/tikv/issues/9886) - 古い値の読み取りによって発生する TiCDC の OOM 問題を修正[#9996](https://github.com/tikv/tikv/issues/9996) [#9981](https://github.com/tikv/tikv/issues/9981) - - 照合順序が`latin1_bin`の場合に、クラスタ化された主キー列のセカンダリ インデックスに空の値が含まれる問題を修正します [#24548](https://github.com/pingcap/tidb/issues/24548) + - 照合順序が`latin1_bin`の場合に、クラスター化された主キー列のセカンダリ インデックスに空の値が含まれる問題を修正します [#24548](https://github.com/pingcap/tidb/issues/24548) - TiKVがpanic発生時にコアダンプファイルを生成できるようにする`abort-on-panic`設定を追加します。ユーザーはコアダンプを有効にするために環境を正しく構成する必要があります [#10216](https://github.com/tikv/tikv/pull/10216) - TiKVがビジー状態でない場合に発生する`point get`クエリのパフォーマンス低下問題を修正 [#10046](https://github.com/tikv/tikv/issues/10046) - PD - - 店舗数が多い場合にPDLeaderの再選が遅くなる問題を修正しました [#3697](https://github.com/tikv/pd/issues/3697) + - ストア数が多い場合にPDリーダーの再選が遅くなる問題を修正しました [#3697](https://github.com/tikv/pd/issues/3697) - 存在しないストアから退去リーダースケジューラを削除する際に発生するpanic問題を修正 [#3660](https://github.com/tikv/pd/issues/3660) diff --git a/releases/release-5.1.4.md b/releases/release-5.1.4.md index 103fa1ab7c2b5..eb46945fce245 100644 --- a/releases/release-5.1.4.md +++ b/releases/release-5.1.4.md @@ -95,7 +95,7 @@ TiDB バージョン: 5.1.4 - 設定`resource-metering.enabled`が動作しないバグを修正[＃11235](https://github.com/tikv/tikv/issues/11235) - `resolved_ts` [＃10965](https://github.com/tikv/tikv/issues/10965)で一部のコルーチンがリークする問題を修正 - 書き込みフローが低い場合に「GC が動作できません」という誤った警告が報告される問題を修正[＃9910](https://github.com/tikv/tikv/issues/9910) - - tikv-ctlが正しい地域関連情報を返すことができないバグを修正[＃11393](https://github.com/tikv/tikv/issues/11393) + - tikv-ctlが正しいリージョン関連情報を返すことができないバグを修正[＃11393](https://github.com/tikv/tikv/issues/11393) - TiKVノードがダウンすると解決されたタイムスタンプが[＃11351](https://github.com/tikv/tikv/issues/11351)遅れる問題を修正しました - 極端な状況でリージョンのマージ、ConfChange、スナップショットが同時に発生した場合に発生するpanicの問題を修正しました[＃11475](https://github.com/tikv/tikv/issues/11475) - TiKVが逆テーブルスキャンを実行するときにメモリロックを検出できない問題を修正しました[＃11440](https://github.com/tikv/tikv/issues/11440) diff --git a/releases/release-5.2.4.md b/releases/release-5.2.4.md index bcfb6b5ae5e67..524b82038052a 100644 --- a/releases/release-5.2.4.md +++ b/releases/release-5.2.4.md @@ -91,7 +91,7 @@ TiDBバージョン：5.2.4 - スロークエリログが正常にログを出力できず、メモリを過剰に消費する可能性がある問題を修正しました [#32656](https://github.com/pingcap/tidb/issues/32656) - NATURAL JOINの結果に予期しない列が含まれる可能性がある問題を修正しました [#29481](https://github.com/pingcap/tidb/issues/29481) - `ORDER BY`と`LIMIT`を 1 つのステートメントで一緒に使用すると、プレフィックス列インデックスを使用してデータをクエリする場合に誤った結果が出力される可能性がある問題を修正しました [#29711](https://github.com/pingcap/tidb/issues/29711) - - 楽観的トランザクションの再試行時に、DOUBLE型の自動インクリメント列が変更される可能性がある問題を修正しました [#29892](https://github.com/pingcap/tidb/issues/29892) + - 楽観的トランザクションの再試行時に、DOUBLE型のAUTO_INCREMENT列が変更される可能性がある問題を修正しました [#29892](https://github.com/pingcap/tidb/issues/29892) - STR_TO_DATE関数がマイクロ秒部分の先頭のゼロを正しく処理できない問題を修正しました [#30078](https://github.com/pingcap/tidb/issues/30078) - TiFlashがまだ空の範囲のテーブル読み取りをサポートしていないにもかかわらず、TiDBが空の範囲のテーブルをスキャンする際に誤った結果を取得する問題を修正します。 [#33083](https://github.com/pingcap/tidb/issues/33083) @@ -108,7 +108,7 @@ TiDBバージョン：5.2.4 - 遅延しているリージョンピアでのリージョンマージによって発生する可能性のあるメタデータ破損を修正 [#11526](https://github.com/tikv/tikv/issues/11526) - TiKVの動作停止後に解決済みTSのレイテンシーが増加する問題を修正 [#11351](https://github.com/tikv/tikv/issues/11351) - 極端な状況下でリージョンマージ、ConfChange、スナップショットが同時に発生した際に発生するpanic問題を修正します [#11475](https://github.com/tikv/tikv/issues/11475) - - tikv-ctlが正しい地域関連情報を返せないバグを修正 [#11393](https://github.com/tikv/tikv/issues/11393) + - tikv-ctlが正しいリージョン関連情報を返せないバグを修正 [#11393](https://github.com/tikv/tikv/issues/11393) - 小数除算の結果がゼロの場合に負の符号が発生する問題を修正 [#29586](https://github.com/pingcap/tidb/issues/29586) - 悲観的トランザクションモードでプリライト要求を再試行すると、まれにデータ不整合のリスクが発生する可能性がある問題を修正しました [#11187](https://github.com/tikv/tikv/issues/11187) - 統計スレッドのデータ監視によって引き起こされるメモリリークを修正 [#11195](https://github.com/tikv/tikv/issues/11195) diff --git a/releases/release-5.3.0.md b/releases/release-5.3.0.md index bf082dc0caa03..6632fb94475c9 100644 --- a/releases/release-5.3.0.md +++ b/releases/release-5.3.0.md @@ -162,7 +162,7 @@ v5.3 の主な新機能または改善点は次のとおりです。 ### 安定性 {#stability} -- **一部の店舗が永久的に損傷した後のオンラインの安全でない回復をサポートします（実験的機能）** +- **一部のストアが永久的に損傷した後のオンラインの安全でない回復をサポートします（実験的機能）** オンラインデータアンセーフリカバリを実行するコマンド`pd-ctl unsafe remove-failed-stores`をサポートします。データレプリカの大部分が永続的な損傷（ディスク損傷など）などの問題に遭遇し、それらの問題によってアプリケーションのデータ範囲が読み取りまたは書き込み不能になったとします。このような場合、PDに実装されているオンラインアンセーフリカバリ機能を使用してデータをリカバリし、再び読み取りまたは書き込み可能になります。 diff --git a/releases/release-5.3.1.md b/releases/release-5.3.1.md index 2f4fdd7833032..a58511cf96b53 100644 --- a/releases/release-5.3.1.md +++ b/releases/release-5.3.1.md @@ -85,7 +85,7 @@ TiDB バージョン: 5.3.1 - 極端な状況でリージョンのマージ、ConfChange、スナップショットが同時に発生した場合に発生するpanicの問題を修正しました[＃11475](https://github.com/tikv/tikv/issues/11475) - TiKVが逆テーブルスキャンを実行するときにメモリロックを検出できない問題を修正しました[＃11440](https://github.com/tikv/tikv/issues/11440) - ディスク容量がいっぱいのときにRocksDBのフラッシュまたは圧縮によってpanicが発生する問題を修正しました[＃11224](https://github.com/tikv/tikv/issues/11224) - - tikv-ctlが正しい地域関連情報を返すことができないバグを修正[＃11393](https://github.com/tikv/tikv/issues/11393) + - tikv-ctlが正しいリージョン関連情報を返すことができないバグを修正[＃11393](https://github.com/tikv/tikv/issues/11393) - TiKV メトリクス[＃11299](https://github.com/tikv/tikv/issues/11299)でインスタンスごとの gRPC リクエストの平均レイテンシーが不正確になる問題を修正しました - PD diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 5e931cb3a5bd3..48451fa362f78 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -357,7 +357,7 @@ TiDBバージョン: 6.3.0-DMR - JSON集計関数で単精度浮動小数点数が使用できない問題を修正 [#37287](https://github.com/pingcap/tidb/issues/37287) @[YangKeao](https://github.com/YangKeao) - `UNION`演算子が予期しない空の結果を返す可能性がある問題を修正 [#36903](https://github.com/pingcap/tidb/issues/36903) @[tiancaiamao](https://github.com/tiancaiamao) - `castRealAsTime`式の結果が MySQL と一致しない問題を修正します [#37462](https://github.com/pingcap/tidb/issues/37462) @[mengxin9014](https://github.com/mengxin9014) - - 悲観的DML 操作が非一意のインデックス キーをロックする問題を修正 [#36235](https://github.com/pingcap/tidb/issues/36235) @[ekexium](https://github.com/ekexium) + - 悲観的DML 操作が非一意インデックス キーをロックする問題を修正 [#36235](https://github.com/pingcap/tidb/issues/36235) @[ekexium](https://github.com/ekexium) - `auto-commit`の変更がトランザクションコミットの動作に影響を与える問題を修正 [#36581](https://github.com/pingcap/tidb/issues/36581) @[cfzjywxk](https://github.com/cfzjywxk) - DML実行エンジンを使用した`EXPLAIN ANALYZE`ステートメントがトランザクションコミットが完了する前に結果を返す可能性がある問題を修正しました [#37373](https://github.com/pingcap/tidb/issues/37373) @[cfzjywxk](https://github.com/cfzjywxk) - UPDATE文が場合によっては誤って投影を削除し、 `Can't find column`エラー [#37568](https://github.com/pingcap/tidb/issues/37568)が発生する問題を修正しました。@[AilinKid](https://github.com/AilinKid) diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 22a7dfd5055df..db92c147ce5f0 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -281,7 +281,7 @@ TiDBバージョン: 6.4.0-DMR | [`max_execution_time`](/system-variables.md#max_execution_time) | 修正済み | バージョン6.4.0より前は、この変数はすべての種類のステートメントに適用されていました。バージョン6.4.0以降は、この変数は読み取り専用ステートメントの最大実行時間のみを制御します。 | | [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630) | 修正済み | グローバルスコープを削除し、 [`pessimistic-txn.constraint-check-in-place-pessimistic`](/tidb-configuration-file.md#constraint-check-in-place-pessimistic-new-in-v640)設定項目を使用してデフォルト値を変更できるようにします。この変数は、TiDB が悲観的トランザクション内の一意制約をチェックするタイミングを制御します。 | | [`tidb_ddl_flashback_concurrency`](/system-variables.md#tidb_ddl_flashback_concurrency-new-in-v630) | 修正済み | バージョン6.4.0以降で有効になり、 [`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)の同時実行を制御します。デフォルト値は`64`です。 | -| [`tidb_enable_clustered_index`](/system-variables.md#tidb_enable_clustered_index-new-in-v50) | 修正済み | デフォルト値を`INT_ONLY`から`ON`に変更します。これは、プライマリキーがデフォルトでクラスタ化インデックスとして作成されることを意味します。 | +| [`tidb_enable_clustered_index`](/system-variables.md#tidb_enable_clustered_index-new-in-v50) | 修正済み | デフォルト値を`INT_ONLY`から`ON`に変更します。これは、主キーがデフォルトでクラスター化インデックスとして作成されることを意味します。 | | [`tidb_enable_paging`](/system-variables.md#tidb_enable_paging-new-in-v540) | 修正済み | デフォルト値を`OFF`から`ON`に変更します。これは、コプロセッサ要求を送信するためのページング方式がデフォルトで使用されることを意味します。 | | [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610) | 修正済み | SESSION スコープを追加します。この変数は[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)を有効にするかどうかを制御します。 | | [`tidb_memory_usage_alarm_ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio) | 修正済み | デフォルト値を`0.8`から`0.7`に変更します。この変数は、tidb-server のメモリアラームをトリガーするメモリ使用率を制御します。 | @@ -335,7 +335,7 @@ TiDBバージョン: 6.4.0-DMR - TiDB - 何もしない変数`lc_messages`の変更を許可する [#38231](https://github.com/pingcap/tidb/issues/38231) @[djshow832](https://github.com/djshow832) - - `AUTO_RANDOM`列をクラスタ化複合インデックスの最初の列としてサポートする [#38572](https://github.com/pingcap/tidb/issues/38572) @[tangenta](https://github.com/tangenta) + - `AUTO_RANDOM`列をクラスター化複合インデックスの最初の列としてサポートする [#38572](https://github.com/pingcap/tidb/issues/38572) @[tangenta](https://github.com/tangenta) - 内部トランザクションの再試行では悲観的トランザクションを使用して、再試行の失敗を回避し、時間の消費を削減します [#38136](https://github.com/pingcap/tidb/issues/38136) @[jackysp](https://github.com/jackysp) - TiKV diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index c5f33e07261c8..b26476acf5285 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -219,7 +219,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - 高性能かつグローバルに単調な`AUTO_INCREMENT`列属性 (GA) [＃38442](https://github.com/pingcap/tidb/issues/38442) @ [tiancaiamao](https://github.com/tiancaiamao)をサポート - TiDBはv6.4.0以降、実験的機能としてMySQL互換モード`AUTO_INCREMENT`導入しました。このモードでは、すべてのTiDBインスタンスでIDが単調に増加するようにする、集中型の自動インクリメントID割り当てサービスが導入されます。この機能により、自動インクリメントIDによるクエリ結果のソートが容易になります。v6.5.0では、この機能がGAになります。この機能を使用したテーブルの挿入TPSは20,000を超えると予想されており、この機能は単一のテーブルとクラスタ全体の書き込みスループットを向上させるためのエラスティックスケーリングをサポートしています。MySQL互換モードを使用するには、テーブル作成時に`AUTO_ID_CACHE` `1`設定する必要があります。以下は例です。 + TiDBはv6.4.0以降、実験的機能としてMySQL互換モード`AUTO_INCREMENT`を導入しました。このモードでは、すべてのTiDBインスタンスでIDが単調に増加するようにする、集中型の自動インクリメントID割り当てサービスが導入されます。この機能により、自動インクリメントIDによるクエリ結果のソートが容易になります。v6.5.0では、この機能がGAになります。この機能を使用したテーブルの挿入TPSは20,000を超えると予想されており、この機能は単一のテーブルとクラスタ全体の書き込みスループットを向上させるためのエラスティックスケーリングをサポートしています。MySQL互換モードを使用するには、テーブル作成時に`AUTO_ID_CACHE` `1`を設定する必要があります。以下は例です。 ```sql CREATE TABLE t(a int AUTO_INCREMENT key) AUTO_ID_CACHE 1; @@ -367,7 +367,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では ### その他 {#others} - v6.5.0 以降、 `mysql.user`テーブルに`Password_reuse_history`と`Password_reuse_time` 2 つの新しい列が追加されます。 -- バージョン6.5.0以降、 [インデックス加速](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)機能がデフォルトで有効になっています。この機能は[1つの`ALTER TABLE`文で複数の列またはインデックスを変更する](/sql-statements/sql-statement-alter-table.md)と完全に互換性がありません。インデックスアクセラレーションを使用してユニークインデックスを追加する場合、同じステートメント内で他の列やインデックスを変更しないようにする必要があります。この機能は[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)とも互換性がありません。インデックスアクセラレーション機能を使用する場合は、バックグラウンドでPITRバックアップタスクが実行されていないことを確認する必要があります。そうしないと、予期しない結果が発生する可能性があります。詳細については、 [ドキュメント](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)参照してください。 +- バージョン6.5.0以降、 [インデックス加速](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)機能がデフォルトで有効になっています。この機能は[1つの`ALTER TABLE`文で複数の列またはインデックスを変更する](/sql-statements/sql-statement-alter-table.md)と完全に互換性がありません。インデックスアクセラレーションを使用して一意インデックスを追加する場合、同じステートメント内で他の列やインデックスを変更しないようにする必要があります。この機能は[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)とも互換性がありません。インデックスアクセラレーション機能を使用する場合は、バックグラウンドでPITRバックアップタスクが実行されていないことを確認する必要があります。そうしないと、予期しない結果が発生する可能性があります。詳細については、 [ドキュメント](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)参照してください。 ## 非推奨の機能 {#deprecated-feature} diff --git a/releases/release-6.5.1.md b/releases/release-6.5.1.md index cb8759f4fa718..487b4de1de837 100644 --- a/releases/release-6.5.1.md +++ b/releases/release-6.5.1.md @@ -88,7 +88,7 @@ TiDB バージョン: 6.5.1 - TiDB がキー範囲[＃40158](https://github.com/pingcap/tidb/issues/40158) @ [tiancaiamao](https://github.com/tiancaiamao)を構築するときに`NULL`値を不適切に処理するため、予期しないデータが読み取られる問題を修正しました。 - メモリの再利用により、システム変数の値が誤って変更される可能性がある問題を修正[＃40979](https://github.com/pingcap/tidb/issues/40979) @ [lcwangchao](https://github.com/lcwangchao) - テーブルの主キーに`ENUM`列[＃40456](https://github.com/pingcap/tidb/issues/40456) @ [lcwangchao](https://github.com/lcwangchao)が含まれている場合にTTLタスクが失敗する問題を修正しました - - ユニークインデックス[＃40592](https://github.com/pingcap/tidb/issues/40592) @ [tangenta](https://github.com/tangenta)を追加するときに TiDB がパニックを起こす問題を修正しました + - 一意インデックス[＃40592](https://github.com/pingcap/tidb/issues/40592) @ [tangenta](https://github.com/tangenta)を追加するときに TiDB がパニックを起こす問題を修正しました - 同じテーブルを同時に切り捨てるときに、一部の切り捨て操作が MDL によってブロックされない問題を修正[＃40484](https://github.com/pingcap/tidb/issues/40484) @ [wjhuang2016](https://github.com/wjhuang2016) - 動的トリミングモード[＃40368](https://github.com/pingcap/tidb/issues/40368) @ [Yisaer](https://github.com/Yisaer)でパーティションテーブルにグローバルバインディングが作成された後にTiDBが再起動できない問題を修正しました - 「カーソル読み取り」メソッドを使用してデータを読み取ると、GC [＃39447](https://github.com/pingcap/tidb/issues/39447) @ [zyguan](https://github.com/zyguan)のためにエラーが返される可能性がある問題を修正しました。 @@ -119,7 +119,7 @@ TiDB バージョン: 6.5.1 - 仮想列を持つ TopN 演算子が誤って TiKV またはTiFlash [＃41355](https://github.com/pingcap/tidb/issues/41355) @ [Dousir9](https://github.com/Dousir9)にプッシュダウンすると、誤った結果が返される可能性がある問題を修正しました。 - インデックス[＃40698](https://github.com/pingcap/tidb/issues/40698) [＃40730](https://github.com/pingcap/tidb/issues/40730) [＃41459](https://github.com/pingcap/tidb/issues/41459) [＃40464](https://github.com/pingcap/tidb/issues/40464) [＃40217](https://github.com/pingcap/tidb/issues/40217) @ [tangenta](https://github.com/tangenta)を追加するときにデータの不整合が発生する問題を修正しました - インデックス[＃41515](https://github.com/pingcap/tidb/issues/41515) @ [tangenta](https://github.com/tangenta)を追加するときに`Pessimistic lock not found`エラーが発生する問題を修正しました - - ユニークインデックス[＃41630](https://github.com/pingcap/tidb/issues/41630) @ [tangenta](https://github.com/tangenta)を追加するときに誤って報告される重複キーエラーの問題を修正しました + - 一意インデックス[＃41630](https://github.com/pingcap/tidb/issues/41630) @ [tangenta](https://github.com/tangenta)を追加するときに誤って報告される重複キーエラーの問題を修正しました - TiDB [＃40741](https://github.com/pingcap/tidb/issues/40741) @ [solotzg](https://github.com/solotzg)で`paging`使用するとパフォーマンスが低下する問題を修正 - TiKV diff --git a/releases/release-6.5.10.md b/releases/release-6.5.10.md index e501e4e89674c..50644301a43d9 100644 --- a/releases/release-6.5.10.md +++ b/releases/release-6.5.10.md @@ -13,7 +13,7 @@ TiDB バージョン: 6.5.10 ## 互換性の変更 {#compatibility-changes} -- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`目のイベントで主キーまたは非NULLの一意のインデックス値が変更されると、TiCDCはこのイベントを`DELETE`目と`INSERT`目のイベントに分割していました。v6.5.10以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS`がTiCDC `thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`目のイベントを`DELETE` `INSERT`と13件目のイベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`目のイベントの順序が誤っている可能性があり、分割された`DELETE`と`INSERT`目のイベントの順序が誤っている可能性があるため、ダウンストリームデータの不整合が発生する問題に対処しています。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v6.5/ticdc-split-update-behavior#split-update-events-for-mysql-sinks) [＃10918](https://github.com/pingcap/tiflow/issues/10918)してください[リデジュ](https://github.com/lidezhu) +- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`目のイベントで主キーまたは非NULLの一意インデックス値が変更されると、TiCDCはこのイベントを`DELETE`目と`INSERT`目のイベントに分割していました。v6.5.10以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS`がTiCDC `thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`目のイベントを`DELETE` `INSERT`と13件目のイベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`目のイベントの順序が誤っている可能性があり、分割された`DELETE`と`INSERT`目のイベントの順序が誤っている可能性があるため、ダウンストリームデータの不整合が発生する問題に対処しています。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v6.5/ticdc-split-update-behavior#split-update-events-for-mysql-sinks) [＃10918](https://github.com/pingcap/tiflow/issues/10918)してください[リデジュ](https://github.com/lidezhu) - TiDB Lightning `strict-format`を使用して CSV ファイルをインポートする場合は、行末文字を設定する必要があります[＃37338](https://github.com/pingcap/tidb/issues/37338) @ [lance6716](https://github.com/lance6716) ## 改善点 {#improvements} @@ -69,7 +69,7 @@ TiDB バージョン: 6.5.10 - `tidb_mem_quota_analyze`が有効になっていて、統計の更新に使用されるメモリが[＃52601](https://github.com/pingcap/tidb/issues/52601) @ [hawkingrei](https://github.com/hawkingrei)制限を超えると TiDB がクラッシュする可能性がある問題を修正しました。 - `UPDATE`リスト内のサブクエリによって TiDB がpanic可能性がある問題を修正[＃52687](https://github.com/pingcap/tidb/issues/52687) @ [winoros](https://github.com/winoros) - 述語[＃45783](https://github.com/pingcap/tidb/issues/45783) @ [hawkingrei](https://github.com/hawkingrei)の`Longlong`型のオーバーフローの問題を修正 - - 一意のインデックス[＃52914](https://github.com/pingcap/tidb/issues/52914) @ [wjhuang2016](https://github.com/wjhuang2016)を追加するときに同時 DML 操作によって発生するデータ インデックスの不整合の問題を修正しました。 + - 一意インデックス[＃52914](https://github.com/pingcap/tidb/issues/52914) @ [wjhuang2016](https://github.com/wjhuang2016)を追加するときに同時 DML 操作によって発生するデータ インデックスの不整合の問題を修正しました。 - インデックスデータ[＃47115](https://github.com/pingcap/tidb/issues/47115) @ [zyguan](https://github.com/zyguan)を解析するときに TiDB がpanic可能性がある問題を修正しました - スライスの浅いコピーを使用せずに列プルーニングを行うと、TiDB がpanic可能性がある問題を修正しました[＃52768](https://github.com/pingcap/tidb/issues/52768) @ [winoros](https://github.com/winoros) - 再帰CTE [＃49721](https://github.com/pingcap/tidb/issues/49721) @ [hawkingrei](https://github.com/hawkingrei)でビューの使用が機能しない問題を修正 diff --git a/releases/release-6.5.12.md b/releases/release-6.5.12.md index 14ece4f5ea227..fd9874b6e303b 100644 --- a/releases/release-6.5.12.md +++ b/releases/release-6.5.12.md @@ -62,7 +62,7 @@ TiDBバージョン: 6.5.12 - stale read が読み取り操作のタイムスタンプを厳密に検証しない問題を修正しました。その結果、TSO と実際の物理時間[＃56809](https://github.com/pingcap/tidb/issues/56809) @ [MyonKeminta](https://github.com/MyonKeminta)の間にオフセットが存在する場合に、トランザクションの一貫性にわずかながら影響する可能性が生じます。 - クエリ`INFORMATION_SCHEMA.columns`のパフォーマンスが[ランス6716](https://github.com/lance6716)で[＃58184](https://github.com/pingcap/tidb/issues/58184)低下する問題を修正 - `INSERT ... ON DUPLICATE KEY`文が`mysql_insert_id` [＃55965](https://github.com/pingcap/tidb/issues/55965) @ [tiancaiamao](https://github.com/tiancaiamao)と互換性がない問題を修正 - - クエリ条件`column IS NULL` [＃56116](https://github.com/pingcap/tidb/issues/56116) @ [hawkingrei](https://github.com/hawkingrei)でユニークインデックスにアクセスするときに、オプティマイザが行数を誤って 1 と推定する問題を修正しました。 + - クエリ条件`column IS NULL` [＃56116](https://github.com/pingcap/tidb/issues/56116) @ [hawkingrei](https://github.com/hawkingrei)で一意インデックスにアクセスするときに、オプティマイザが行数を誤って 1 と推定する問題を修正しました。 - `IndexLookUp`演算子のメモリの一部が[＃56440](https://github.com/pingcap/tidb/issues/56440) @ [wshwsh12](https://github.com/wshwsh12)で追跡されない問題を修正 - TiDBの内部コルーチン[＃57798](https://github.com/pingcap/tidb/issues/57798) [＃56053](https://github.com/pingcap/tidb/issues/56053) @ [fishiu](https://github.com/fishiu) @ [tiancaiamao](https://github.com/tiancaiamao)で発生する可能性のあるデータ競合問題を修正しました - クエリに利用可能なインデックスマージ実行プラン[＃56217](https://github.com/pingcap/tidb/issues/56217) @ [AilinKid](https://github.com/AilinKid)がある場合に`read_from_storage`ヒントが有効にならない可能性がある問題を修正しました @@ -70,7 +70,7 @@ TiDBバージョン: 6.5.12 - 異常終了時に`INDEX_HASH_JOIN`アップする可能性がある問題を修正[＃54055](https://github.com/pingcap/tidb/issues/54055) @ [wshwsh12](https://github.com/wshwsh12) - 2人のDDL所有者が同時に存在する可能性がある問題を修正[＃54689](https://github.com/pingcap/tidb/issues/54689) @ [joccau](https://github.com/joccau) - `information_schema.cluster_slow_query`テーブルをクエリするときに、時間フィルターが追加されていない場合、最新のスローログファイルのみがクエリされる問題を修正しました[＃56100](https://github.com/pingcap/tidb/issues/56100) @ [crazycs520](https://github.com/crazycs520) - - ユニークインデックス[＃56161](https://github.com/pingcap/tidb/issues/56161) @ [tangenta](https://github.com/tangenta)を追加するときに`duplicate entry`発生する可能性がある問題を修正 + - 一意インデックス[＃56161](https://github.com/pingcap/tidb/issues/56161) @ [tangenta](https://github.com/tangenta)を追加するときに`duplicate entry`発生する可能性がある問題を修正 - 特定の型変換エラー[＃41730](https://github.com/pingcap/tidb/issues/41730) @ [hawkingrei](https://github.com/hawkingrei)でエラーメッセージが正しく表示されない問題を修正 - `VIEW`で定義されたCTEが誤ってインライン化される問題を修正[＃56582](https://github.com/pingcap/tidb/issues/56582) @ [elsa0520](https://github.com/elsa0520) - `UPDATE`文が`ENUM`型[＃56832](https://github.com/pingcap/tidb/issues/56832) @ [xhebox](https://github.com/xhebox)の値を誤って更新する問題を修正しました diff --git a/releases/release-6.5.3.md b/releases/release-6.5.3.md index 1a95b17efe938..7081f9e36115d 100644 --- a/releases/release-6.5.3.md +++ b/releases/release-6.5.3.md @@ -15,7 +15,7 @@ TiDB バージョン: 6.5.3 ### 行動の変化 {#behavior-changes} -- 更新イベントの処理中に、イベント内の主キーまたはnull以外の一意のインデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割します。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-a-single-update-change)参照してください。 +- 更新イベントの処理中に、イベント内の主キーまたはnull以外の一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割します。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-a-single-update-change)参照してください。 ## 改善点 {#improvements} diff --git a/releases/release-6.5.4.md b/releases/release-6.5.4.md index 46072f90d1738..5b932e14af0b3 100644 --- a/releases/release-6.5.4.md +++ b/releases/release-6.5.4.md @@ -18,7 +18,7 @@ TiDB バージョン: 6.5.4 ### 行動の変化 {#behavior-changes} -- 複数の変更を含むトランザクションにおいて、更新イベントで主キーまたはNULL以外の一意のインデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割し、すべてのイベントが挿入イベントに先行する削除イベントの順序に従うようにします。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-multiple-update-changes)参照してください。 +- 複数の変更を含むトランザクションにおいて、更新イベントで主キーまたはNULL以外の一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割し、すべてのイベントが挿入イベントに先行する削除イベントの順序に従うようにします。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-multiple-update-changes)参照してください。 ## 改善点 {#improvements} diff --git a/releases/release-6.5.9.md b/releases/release-6.5.9.md index b71538d229bc1..ea598eb936c22 100644 --- a/releases/release-6.5.9.md +++ b/releases/release-6.5.9.md @@ -130,7 +130,7 @@ TiDB バージョン: 6.5.9 - TiDB データ移行 (DM) - - アップストリーム主キーがバイナリタイプ[＃10672](https://github.com/pingcap/tiflow/issues/10672) @ [GMHDBJD](https://github.com/GMHDBJD)の場合にデータが失われる問題を修正しました + - アップストリーム主キーがバイナリ型[＃10672](https://github.com/pingcap/tiflow/issues/10672) @ [GMHDBJD](https://github.com/GMHDBJD)の場合にデータが失われる問題を修正しました - TiDB Lightning diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md index d9418c23dc3e0..06f84dc057447 100644 --- a/releases/release-6.6.0.md +++ b/releases/release-6.6.0.md @@ -489,10 +489,10 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - 取り込みモードで一意インデックスを作成すると、データがインデックスと矛盾する可能性がある問題を修正します [#40464](https://github.com/pingcap/tidb/issues/40464) @[tangenta](https://github.com/tangenta) - 同じテーブルを同時に切り捨てる際に、一部の切り捨て操作がMDLによってブロックされない問題を修正しました [#40484](https://github.com/pingcap/tidb/issues/40484) @[wjhuang2016](https://github.com/wjhuang2016) - `SHOW PRIVILEGES`ステートメントが不完全な特権リストを返す問題を修正 [#40591](https://github.com/pingcap/tidb/issues/40591) @[CbcWestwolf](https://github.com/CbcWestwolf) - - 一意のインデックスを追加するときに TiDB がパニックになる問題を修正 [#40592](https://github.com/pingcap/tidb/issues/40592) @[tangenta](https://github.com/tangenta) + - 一意インデックスを追加するときに TiDB がパニックになる問題を修正 [#40592](https://github.com/pingcap/tidb/issues/40592) @[tangenta](https://github.com/tangenta) - `ADMIN RECOVER`ステートメントを実行するとインデックスデータが破損する可能性がある問題を修正しました [#40430](https://github.com/pingcap/tidb/issues/40430) @[xiongjiwei](https://github.com/xiongjiwei) - クエリ対象のテーブルに式インデックスに`CAST`式が含まれている場合にクエリが失敗する可能性がある問題を修正しました [#40130](https://github.com/pingcap/tidb/issues/40130) @[xiongjiwei](https://github.com/xiongjiwei) - - ユニークインデックスが場合によっては重複データを生成する可能性がある問題を修正 [#40217](https://github.com/pingcap/tidb/issues/40217) @[tangenta](https://github.com/tangenta) + - 一意インデックスが場合によっては重複データを生成する可能性がある問題を修正 [#40217](https://github.com/pingcap/tidb/issues/40217) @[tangenta](https://github.com/tangenta) - `Prepare`または`Execute` [#39605](https://github.com/pingcap/tidb/issues/39605) @[djshow832](https://github.com/djshow832) - インデックス追加時にデータ競合が発生する可能性がある問題を修正 [#40879](https://github.com/pingcap/tidb/issues/40879) @[tangenta](https://github.com/tangenta) - 仮想列 [#41014](https://github.com/pingcap/tidb/issues/41014) @[AilinKid](https://github.com/AilinKid)キッドによって引き起こされる`can't find proper physical plan`の問題を修正します diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index 0d3e37a79399c..fc1cc5a8101ff 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -87,7 +87,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone 詳細については、[ドキュメント](/derive-topn-from-window.md)を参照してください。 -- Fast Online DDL によるユニークインデックス作成のサポート [#40730](https://github.com/pingcap/tidb/issues/40730) @[tangenta](https://github.com/tangenta) +- Fast Online DDL による一意インデックス作成のサポート [#40730](https://github.com/pingcap/tidb/issues/40730) @[tangenta](https://github.com/tangenta) TiDB v6.5.0 では、Fast Online DDL による通常のセカンダリ インデックスの作成がサポートされています。TiDB v7.0.0 では、Fast Online DDL によるユニーク インデックスの作成がサポートされています。v6.1.0 と比較して、大規模テーブルへのユニーク インデックスの追加は、パフォーマンスの向上により数倍高速化されることが期待されます。 @@ -233,9 +233,9 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone ### MySQLとの互換性 {#mysql-compatibility} -- TiDBは、自動インクリメント列がインデックスでなければならないという制約を削除します [#40580](https://github.com/pingcap/tidb/issues/40580) @[tiancaiamao](https://github.com/tiancaiamao) +- TiDBは、AUTO_INCREMENT列にインデックスが必要であるという制約を削除します [#40580](https://github.com/pingcap/tidb/issues/40580) @[tiancaiamao](https://github.com/tiancaiamao) - バージョン 7.0.0 より前は、TiDB の動作は MySQL と一貫しており、自動インクリメント列はインデックスまたはインデックスプレフィックスである必要がありました。バージョン 7.0.0 以降、TiDB は自動インクリメント列がインデックスまたはインデックスプレフィックスである必要があるという制約を撤廃しました。これにより、テーブルの主キーをより柔軟に定義し、自動インクリメント列を使用してソートやページネーションをより簡単に実装できるようになりました。また、自動インクリメント列によって引き起こされる書き込みホットスポットの問題も回避され、クラスタ化インデックスを持つテーブルを使用することでクエリのパフォーマンスが向上します。新しいリリースでは、次の構文を使用してテーブルを作成できます。 + バージョン 7.0.0 より前は、TiDB の動作は MySQL と一貫しており、AUTO_INCREMENT列にはインデックスまたはインデックスプレフィックスが必要でした。バージョン 7.0.0 以降、TiDB はAUTO_INCREMENT列にインデックスまたはインデックスプレフィックスが必要であるという制約を撤廃しました。これにより、テーブルの主キーをより柔軟に定義し、AUTO_INCREMENT列を使用してソートやページネーションをより簡単に実装できるようになりました。また、AUTO_INCREMENT列によって引き起こされる書き込みホットスポットの問題も回避され、クラスター化インデックスを持つテーブルを使用することでクエリのパフォーマンスが向上します。新しいリリースでは、次の構文を使用してテーブルを作成できます。 ```sql CREATE TABLE test1 ( @@ -389,7 +389,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - アップグレード後に一部のシステム変数のデフォルト値が変更されない問題を修正 [#41423](https://github.com/pingcap/tidb/issues/41423) @[crazycs520](https://github.com/crazycs520) - インデックス追加に関連するコプロセッサー要求タイプが不明として表示される問題を修正 [#41400](https://github.com/pingcap/tidb/issues/41400) @[tangenta](https://github.com/tangenta) - インデックスを追加する際に「PessimisticLockNotFound」が返される問題を修正 [#41515](https://github.com/pingcap/tidb/issues/41515) @[tangenta](https://github.com/tangenta) - - 一意のインデックスを追加する際に誤って`found duplicate key`を返す問題を修正 [#41630](https://github.com/pingcap/tidb/issues/41630) @[tangenta](https://github.com/tangenta) + - 一意インデックスを追加する際に誤って`found duplicate key`を返す問題を修正 [#41630](https://github.com/pingcap/tidb/issues/41630) @[tangenta](https://github.com/tangenta) - インデックス追加時のpanic問題を修正 [#41880](https://github.com/pingcap/tidb/issues/41880) @[tangenta](https://github.com/tangenta) - TiFlashが実行中に生成された列に対してエラーを報告する問題を修正 [#40663](https://github.com/pingcap/tidb/issues/40663) @[guo-shaoge](https://github.com/guo-shaoge) - TiDBが時間型の場合に統計情報を正しく取得できない可能性がある問題を修正しました [#41938](https://github.com/pingcap/tidb/issues/41938) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index 6a922aaa2f103..a8d2fcbbb5a29 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -404,7 +404,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - 極端なケースで、悲観的トランザクションの最初のステートメントが再試行されるときに、このトランザクションのロックを解決するとトランザクションの正確性に影響する可能性がある問題を修正しました[＃42937](https://github.com/pingcap/tidb/issues/42937) @ [MyonKeminta](https://github.com/MyonKeminta) - GC がロック[＃43243](https://github.com/pingcap/tidb/issues/43243) @ [MyonKeminta](https://github.com/MyonKeminta)を解決するときに、まれに悲観的トランザクションの残余悲観的ロックがデータの正確性に影響を与える可能性がある問題を修正しました。 - `LOCK`から`PUT`への最適化により、特定のクエリ[＃28011](https://github.com/pingcap/tidb/issues/28011) @ [zyguan](https://github.com/zyguan)で重複データが返される問題を修正しました。 - - データが変更された場合、ユニークインデックスのロック動作がデータが変更されていない場合のロック動作と一致しない問題を修正しました[＃36438](https://github.com/pingcap/tidb/issues/36438) @ [zyguan](https://github.com/zyguan) + - データが変更された場合、一意インデックスのロック動作がデータが変更されていない場合のロック動作と一致しない問題を修正しました[＃36438](https://github.com/pingcap/tidb/issues/36438) @ [zyguan](https://github.com/zyguan) - TiKV diff --git a/releases/release-7.1.1.md b/releases/release-7.1.1.md index 291b91f631b7b..e23b93dd684cc 100644 --- a/releases/release-7.1.1.md +++ b/releases/release-7.1.1.md @@ -17,7 +17,7 @@ TiDB バージョン: 7.1.1 ### 行動の変化 {#behavior-changes} -- 更新イベントの処理中に、イベント内の主キーまたはnull以外の一意のインデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割します。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-a-single-update-change)参照してください。 +- 更新イベントの処理中に、イベント内の主キーまたはnull以外の一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割します。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-a-single-update-change)参照してください。 ## 改善点 {#improvements} @@ -135,7 +135,7 @@ TiDB バージョン: 7.1.1 - TiDB データ移行 (DM) - - 移行対象のテーブル内のユニークインデックスに空の列が含まれている場合にDMマスターが異常終了する問題を修正[＃9247](https://github.com/pingcap/tiflow/issues/9247) @ [lance6716](https://github.com/lance6716) + - 移行対象のテーブル内の一意インデックスに空の列が含まれている場合にDMマスターが異常終了する問題を修正[＃9247](https://github.com/pingcap/tiflow/issues/9247) @ [lance6716](https://github.com/lance6716) - TiDB Lightning diff --git a/releases/release-7.1.2.md b/releases/release-7.1.2.md index dd0e6b9351b2e..29259cf3d8d61 100644 --- a/releases/release-7.1.2.md +++ b/releases/release-7.1.2.md @@ -22,7 +22,7 @@ TiDB バージョン: 7.1.2 ### 行動の変化 {#behavior-changes} -- 複数の変更を含むトランザクションにおいて、更新イベントで主キーまたはNULL以外の一意のインデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割し、すべてのイベントが挿入イベントに先行する削除イベントの順序に従うようにします。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-multiple-update-changes)参照してください。 +- 複数の変更を含むトランザクションにおいて、更新イベントで主キーまたはNULL以外の一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割し、すべてのイベントが挿入イベントに先行する削除イベントの順序に従うようにします。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-multiple-update-changes)参照してください。 ## 改善点 {#improvements} @@ -103,7 +103,7 @@ TiDB バージョン: 7.1.2 - MPP実行プランで集計がユニオンを介してプッシュダウンされると、結果が正しくなくなる問題を修正[＃45850](https://github.com/pingcap/tidb/issues/45850) @ [AilinKid](https://github.com/AilinKid) - `AUTO_ID_CACHE=1` [＃46454](https://github.com/pingcap/tidb/issues/46454) @ [tiancaiamao](https://github.com/tiancaiamao)に設定されている場合に、panic後に TiDB がゆっくりと回復する問題を修正しました。 - ソート演算子がスピルプロセス中に TiDB をクラッシュさせる可能性がある問題を修正[＃47538](https://github.com/pingcap/tidb/issues/47538) @ [windtalker](https://github.com/windtalker) - - BRを使用して`AUTO_ID_CACHE=1` [＃46093](https://github.com/pingcap/tidb/issues/46093) @ [tiancaiamao](https://github.com/tiancaiamao)の非クラスタ化インデックステーブルを復元するときに重複する主キーの問題を修正しました。 + - BRを使用して`AUTO_ID_CACHE=1` [＃46093](https://github.com/pingcap/tidb/issues/46093) @ [tiancaiamao](https://github.com/tiancaiamao)の非クラスター化インデックステーブルを復元するときに重複する主キーの問題を修正しました。 - 静的プルーニングモードでパーティションテーブルをクエリし、実行プランに`IndexLookUp` [＃45757](https://github.com/pingcap/tidb/issues/45757) @ [Defined2014](https://github.com/Defined2014)が含まれている場合にクエリがエラーを報告する可能性がある問題を修正しました。 - パーティションテーブルと配置ポリシー[＃45791](https://github.com/pingcap/tidb/issues/45791) @ [mjonss](https://github.com/mjonss)テーブル間でパーティションを交換した後に、パーティションテーブルへのデータの挿入が失敗する可能性がある問題を修正しました。 - タイムゾーン情報が正しくない時間フィールドをエンコードする問題を修正[＃46033](https://github.com/pingcap/tidb/issues/46033) @ [tangenta](https://github.com/tangenta) diff --git a/releases/release-7.1.5.md b/releases/release-7.1.5.md index 16c4ea867ee50..34139ae494b27 100644 --- a/releases/release-7.1.5.md +++ b/releases/release-7.1.5.md @@ -62,8 +62,8 @@ TiDB バージョン: 7.1.5 - TTL 機能により、データ範囲の分割が不正確になり、場合によっては[＃51527](https://github.com/pingcap/tidb/issues/51527) @ [lcwangchao](https://github.com/lcwangchao)でデータ ホットスポットが発生する問題を修正しました。 - TiDBがオフラインになっているTiFlashノードにプローブ要求を送信し続ける問題を修正[＃46602](https://github.com/pingcap/tidb/issues/46602) @ [zyguan](https://github.com/zyguan) - AutoIDLeaderの変更により、 `AUTO_ID_CACHE=1` [＃52600](https://github.com/pingcap/tidb/issues/52600) @ [tiancaiamao](https://github.com/tiancaiamao)の場合に自動増分列の値が減少する可能性がある問題を修正しました。 - - `INSERT IGNORE`実行すると、一意のインデックスとデータ[＃51784](https://github.com/pingcap/tidb/issues/51784) @ [wjhuang2016](https://github.com/wjhuang2016)の間に不整合が発生する可能性がある問題を修正しました。 - - ユニークインデックスを追加するとTiDBがpanic可能性がある問題を修正[＃52312](https://github.com/pingcap/tidb/issues/52312) @ [wjhuang2016](https://github.com/wjhuang2016) + - `INSERT IGNORE`実行すると、一意インデックスとデータ[＃51784](https://github.com/pingcap/tidb/issues/51784) @ [wjhuang2016](https://github.com/wjhuang2016)の間に不整合が発生する可能性がある問題を修正しました。 + - 一意インデックスを追加するとTiDBがpanic可能性がある問題を修正[＃52312](https://github.com/pingcap/tidb/issues/52312) @ [wjhuang2016](https://github.com/wjhuang2016) - 関連するサブクエリがある場合にウィンドウ関数がpanic可能性がある問題を修正[＃42734](https://github.com/pingcap/tidb/issues/42734) @ [Rustin170506](https://github.com/Rustin170506) - `init-stats`プロセスが TiDB をpanicに陥らせ、 `load stats`プロセスが[＃51581](https://github.com/pingcap/tidb/issues/51581) @ [hawkingrei](https://github.com/hawkingrei)で終了する可能性がある問題を修正しました。 - TableDual [＃50614](https://github.com/pingcap/tidb/issues/50614) @ [time-and-fate](https://github.com/time-and-fate)で述語プッシュダウンを無効にすることで発生するパフォーマンス低下の問題を修正しました diff --git a/releases/release-7.1.6.md b/releases/release-7.1.6.md index 6d58ca8b94935..8458b68f0e37c 100644 --- a/releases/release-7.1.6.md +++ b/releases/release-7.1.6.md @@ -14,7 +14,7 @@ TiDB バージョン: 7.1.6 ## 互換性の変更 {#compatibility-changes} - [TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-7.1/docs/tidb_http_api.md)から取得される DDL 履歴タスクのデフォルトの制限を 2048 に設定して、過剰な履歴タスク[＃55711](https://github.com/pingcap/tidb/issues/55711) @ [joccau](https://github.com/joccau)による OOM の問題を防止します。 -- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`目のイベントで主キーまたは非NULLの一意のインデックス値が変更されると、TiCDCはこのイベントを`DELETE`目と`INSERT`目のイベントに分割していました。v7.1.6以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS` TiCDC `thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`件目のイベントを`DELETE`目と`INSERT`件目のイベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`目のイベントの順序が誤っている可能性があり、その結果、分割された`DELETE`と`INSERT`目のイベントの順序が誤っている可能性があることで発生するダウンストリームデータの不整合の問題を解決します。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v7.1/ticdc-split-update-behavior#split-update-events-for-mysql-sinks) [＃10918](https://github.com/pingcap/tiflow/issues/10918)してください[リデジュ](https://github.com/lidezhu) +- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`目のイベントで主キーまたは非NULLの一意インデックス値が変更されると、TiCDCはこのイベントを`DELETE`目と`INSERT`目のイベントに分割していました。v7.1.6以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS` TiCDC `thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`件目のイベントを`DELETE`目と`INSERT`件目のイベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`目のイベントの順序が誤っている可能性があり、その結果、分割された`DELETE`と`INSERT`目のイベントの順序が誤っている可能性があることで発生するダウンストリームデータの不整合の問題を解決します。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v7.1/ticdc-split-update-behavior#split-update-events-for-mysql-sinks) [＃10918](https://github.com/pingcap/tiflow/issues/10918)してください[リデジュ](https://github.com/lidezhu) - TiDB Lightning `strict-format`を使用して CSV ファイルをインポートする場合は、行末文字を設定する必要があります[＃37338](https://github.com/pingcap/tidb/issues/37338) @ [lance6716](https://github.com/lance6716) - TiKV構成項目[`server.grpc-compression-type`](/tikv-configuration-file.md#grpc-compression-type)のスコープを変更します。 @@ -73,7 +73,7 @@ TiDB バージョン: 7.1.6 - TiDB - - 一意のインデックス[＃52914](https://github.com/pingcap/tidb/issues/52914) @ [wjhuang2016](https://github.com/wjhuang2016)を追加するときに同時 DML 操作によって発生するデータ インデックスの不一致の問題を修正しました。 + - 一意インデックス[＃52914](https://github.com/pingcap/tidb/issues/52914) @ [wjhuang2016](https://github.com/wjhuang2016)を追加するときに同時 DML 操作によって発生するデータ インデックスの不一致の問題を修正しました。 - `YEAR`型の列を範囲外の符号なし整数と比較すると誤った結果が発生する問題を修正[＃50235](https://github.com/pingcap/tidb/issues/50235) @ [qw4990](https://github.com/qw4990) - SQLが異常に中断されたときに`INDEX_HASH_JOIN`正常に終了できない問題を修正[＃54688](https://github.com/pingcap/tidb/issues/54688) @ [wshwsh12](https://github.com/wshwsh12) - 分散実行フレームワーク (DXF) を使用してインデックスを追加する際のネットワーク パーティションによって、データ インデックス[＃54897](https://github.com/pingcap/tidb/issues/54897) @ [tangenta](https://github.com/tangenta)の不整合が発生する可能性がある問題を修正しました。 @@ -97,7 +97,7 @@ TiDB バージョン: 7.1.6 - TiDBが接続を閉じるときにログにエラーを報告する場合がある問題を修正[＃53689](https://github.com/pingcap/tidb/issues/53689) @ [jackysp](https://github.com/jackysp) - 場合によっては無効な列タイプ`DECIMAL(0,0)`が作成される可能性がある問題を修正[＃53779](https://github.com/pingcap/tidb/issues/53779) @ [tangenta](https://github.com/tangenta) - ビュー定義[＃54343](https://github.com/pingcap/tidb/issues/54343) @ [lance6716](https://github.com/lance6716)でサブクエリが列定義として使用されている場合、 `information_schema.columns`を使用して列情報を取得すると警告1356が返される問題を修正しました。 - - クエリ条件`column IS NULL` [＃56116](https://github.com/pingcap/tidb/issues/56116) @ [hawkingrei](https://github.com/hawkingrei)でユニークインデックスにアクセスするときに、オプティマイザが行数を誤って 1 と推定する問題を修正しました。 + - クエリ条件`column IS NULL` [＃56116](https://github.com/pingcap/tidb/issues/56116) @ [hawkingrei](https://github.com/hawkingrei)で一意インデックスにアクセスするときに、オプティマイザが行数を誤って 1 と推定する問題を修正しました。 - クラスター化インデックスを述語として使用すると`SELECT INTO OUTFILE`機能しない問題を修正[＃42093](https://github.com/pingcap/tidb/issues/42093) @ [qw4990](https://github.com/qw4990) - オプティマイザーヒント[＃53767](https://github.com/pingcap/tidb/issues/53767) @ [hawkingrei](https://github.com/hawkingrei)使用時に誤った警告情報が表示される問題を修正しました - 同期負荷QPSモニタリングメトリックが正しくない問題を修正[＃53558](https://github.com/pingcap/tidb/issues/53558) @ [hawkingrei](https://github.com/hawkingrei) @@ -138,7 +138,7 @@ TiDB バージョン: 7.1.6 - TiDBの同期的な統計読み込みメカニズムが空の統計の読み込みを無期限に再試行し、 `fail to get stats version for this histogram` log [＃52657](https://github.com/pingcap/tidb/issues/52657) @ [hawkingrei](https://github.com/hawkingrei)を出力問題を修正しました。 - 最初の引数が`month`で、2番目の引数が負の[＃54908](https://github.com/pingcap/tidb/issues/54908) @ [xzhangxian1008](https://github.com/xzhangxian1008)場合に`TIMESTAMPADD()`関数が無限ループに入る問題を修正しました。 - `tidb_mem_quota_analyze`が有効になっていて、統計の更新に使用されるメモリが[＃52601](https://github.com/pingcap/tidb/issues/52601) @ [hawkingrei](https://github.com/hawkingrei)の制限を超えると、TiDB がクラッシュする可能性がある問題を修正しました。 - - ユニークインデックス[＃56161](https://github.com/pingcap/tidb/issues/56161) @ [tangenta](https://github.com/tangenta)を追加するときに`duplicate entry`発生する可能性がある問題を修正 + - 一意インデックス[＃56161](https://github.com/pingcap/tidb/issues/56161) @ [tangenta](https://github.com/tangenta)を追加するときに`duplicate entry`発生する可能性がある問題を修正 - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、古い読み取りのクエリレイテンシーが増加する問題を修正しました。 - GlobalStatsの`Distinct_count`情報が正しくない可能性がある問題を修正しました[＃53752](https://github.com/pingcap/tidb/issues/53752) @ [hawkingrei](https://github.com/hawkingrei) - `SELECT DISTINCT CAST(col AS DECIMAL), CAST(col AS SIGNED) FROM ...`クエリを実行すると誤った結果が返される可能性がある問題を修正[＃53726](https://github.com/pingcap/tidb/issues/53726) @ [hawkingrei](https://github.com/hawkingrei) diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index 88e70e2710737..6e7a3d1ea9736 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -247,7 +247,7 @@ TiDB バージョン: 7.4.0 - MySQL 8.0 との互換性を向上させるために[`information_schema.CHECK_CONSTRAINTS`](/information-schema/information-schema-check-constraints.md)テーブルが追加されました。 -- 複数の変更を含むトランザクションにおいて、更新イベントで主キーまたは非NULLの一意のインデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割し、すべてのイベントが挿入イベントに先行する削除イベントの順序に従うようにします。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-multiple-update-changes)参照してください。 +- 複数の変更を含むトランザクションにおいて、更新イベントで主キーまたは非NULLの一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割し、すべてのイベントが挿入イベントに先行する削除イベントの順序に従うようにします。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-multiple-update-changes)参照してください。 ### システム変数 {#system-variables} diff --git a/releases/release-7.5.2.md b/releases/release-7.5.2.md index 15f07b70748c7..6c9f6f6984328 100644 --- a/releases/release-7.5.2.md +++ b/releases/release-7.5.2.md @@ -16,7 +16,7 @@ TiDB バージョン: 7.5.2 - 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) [＃10918](https://github.com/pingcap/tiflow/issues/10918)してください[リデジュ](https://github.com/lidezhu) +- 以前のバージョンでは、 `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) [＃10918](https://github.com/pingcap/tiflow/issues/10918)してください[リデジュ](https://github.com/lidezhu) ## 改善点 {#improvements} @@ -77,7 +77,7 @@ TiDB バージョン: 7.5.2 - TiDB - - 一意のインデックス[＃52914](https://github.com/pingcap/tidb/issues/52914) @ [wjhuang2016](https://github.com/wjhuang2016)を追加するときに同時 DML 操作によって発生するデータ インデックスの不整合の問題を修正しました。 + - 一意インデックス[＃52914](https://github.com/pingcap/tidb/issues/52914) @ [wjhuang2016](https://github.com/wjhuang2016)を追加するときに同時 DML 操作によって発生するデータ インデックスの不整合の問題を修正しました。 - パーティションテーブル[＃52080](https://github.com/pingcap/tidb/issues/52080) @ [tangenta](https://github.com/tangenta)に複数のスキーマ変更を含むインデックスを追加することで発生するデータインデックスの不整合の問題を修正しました。 - 複数値インデックス[＃51162](https://github.com/pingcap/tidb/issues/51162) @ [ywqzzy](https://github.com/ywqzzy)を追加することによって発生するデータ インデックスの不整合の問題を修正しました - ネットワークの問題によりDDL操作が停止する問題を修正[＃47060](https://github.com/pingcap/tidb/issues/47060) @ [wjhuang2016](https://github.com/wjhuang2016) @@ -104,7 +104,7 @@ TiDB バージョン: 7.5.2 - `ALL`関数に含まれるサブクエリが誤った結果を引き起こす可能性がある問題を修正[＃52755](https://github.com/pingcap/tidb/issues/52755) @ [hawkingrei](https://github.com/hawkingrei) - `VAR_SAMP()`ウィンドウ関数[＃52933](https://github.com/pingcap/tidb/issues/52933) @ [Rustin170506](https://github.com/Rustin170506)として使用できない問題を修正 - スライスの浅いコピーを使用せずに列プルーニングを行うと、TiDB がpanic可能性がある問題を修正しました[＃52768](https://github.com/pingcap/tidb/issues/52768) @ [winoros](https://github.com/winoros) - - ユニークインデックスを追加するとTiDBがpanic可能性がある問題を修正[＃52312](https://github.com/pingcap/tidb/issues/52312) @ [wjhuang2016](https://github.com/wjhuang2016) + - 一意インデックスを追加するとTiDBがpanic可能性がある問題を修正[＃52312](https://github.com/pingcap/tidb/issues/52312) @ [wjhuang2016](https://github.com/wjhuang2016) - 初期化が完了する前に TiDBサーバーが正常とマークされる問題を修正[＃51596](https://github.com/pingcap/tidb/issues/51596) @ [shenqidebaozi](https://github.com/shenqidebaozi) - `IFNULL`関数によって返される型が MySQL [＃51765](https://github.com/pingcap/tidb/issues/51765) @ [YangKeao](https://github.com/YangKeao)と一致しない問題を修正しました - テーブルにクラスター化インデックス[＃51372](https://github.com/pingcap/tidb/issues/51372) @ [guo-shaoge](https://github.com/guo-shaoge)がある場合に並列`Apply`で誤った結果が生成される可能性がある問題を修正しました。 @@ -127,7 +127,7 @@ TiDB バージョン: 7.5.2 - 照合の新しいフレームワークが無効になっているときに、異なる照合を含む式によってクエリがpanicになる可能性がある問題を修正しました[＃52772](https://github.com/pingcap/tidb/issues/52772) @ [wjhuang2016](https://github.com/wjhuang2016) - 複数値インデックスを持つテーブルを含むSQL文を実行すると、 `Can't find a proper physical plan for this query`エラー[＃49438](https://github.com/pingcap/tidb/issues/49438) @ [qw4990](https://github.com/qw4990)が返される可能性がある問題を修正しました。 - TiDBが式[＃43527](https://github.com/pingcap/tidb/issues/43527) @ [Rustin170506](https://github.com/Rustin170506)内のシステム変数の型を正しく変換できない問題を修正 - - `INSERT IGNORE`実行すると、一意のインデックスとデータ[＃51784](https://github.com/pingcap/tidb/issues/51784) @ [wjhuang2016](https://github.com/wjhuang2016)の間に不整合が発生する可能性がある問題を修正しました。 + - `INSERT IGNORE`実行すると、一意インデックスとデータ[＃51784](https://github.com/pingcap/tidb/issues/51784) @ [wjhuang2016](https://github.com/wjhuang2016)の間に不整合が発生する可能性がある問題を修正しました。 - OOMエラー発生後に自動統計収集が停止する問題を修正[＃51993](https://github.com/pingcap/tidb/issues/51993) @ [Rustin170506](https://github.com/Rustin170506) - `tidb_mem_quota_analyze`が有効になっていて、統計の更新に使用されるメモリが[＃52601](https://github.com/pingcap/tidb/issues/52601) @ [hawkingrei](https://github.com/hawkingrei)制限を超えると TiDB がクラッシュする可能性がある問題を修正しました。 - 複数のレベルの`max_execute_time`設定が互いに干渉する問題を修正[＃50914](https://github.com/pingcap/tidb/issues/50914) @ [jiyfhust](https://github.com/jiyfhust) @@ -243,7 +243,7 @@ TiDB バージョン: 7.5.2 - TiDB データ移行 (DM) - `go-mysql` [＃11041](https://github.com/pingcap/tiflow/issues/11041) @ [D3Hunter](https://github.com/D3Hunter)にアップグレードして接続ブロックの問題を修正しました - - アップストリーム主キーがバイナリタイプ[＃10672](https://github.com/pingcap/tiflow/issues/10672) @ [GMHDBJD](https://github.com/GMHDBJD)の場合にデータが失われる問題を修正しました + - アップストリーム主キーがバイナリ型[＃10672](https://github.com/pingcap/tiflow/issues/10672) @ [GMHDBJD](https://github.com/GMHDBJD)の場合にデータが失われる問題を修正しました - TiDB Lightning diff --git a/releases/release-7.5.4.md b/releases/release-7.5.4.md index b4632b0325141..9af5a4b45a37d 100644 --- a/releases/release-7.5.4.md +++ b/releases/release-7.5.4.md @@ -68,7 +68,7 @@ TiDB バージョン: 7.5.4 - `StreamAggExec`分の`groupOffset`空の場合に TiDB が[＃53867](https://github.com/pingcap/tidb/issues/53867) @ [xzhangxian1008](https://github.com/xzhangxian1008)でpanicを起こす可能性がある問題を修正しました - copタスク構築中にTiDBクエリをキャンセルできない問題を修正[＃55957](https://github.com/pingcap/tidb/issues/55957) @ [yibin87](https://github.com/yibin87) - 整数型[＃55837](https://github.com/pingcap/tidb/issues/55837) @ [windtalker](https://github.com/windtalker)の列に小さい表示幅が指定された場合、 `out of range`エラーが発生する可能性がある問題を修正しました。 - - ユニークインデックス[＃56161](https://github.com/pingcap/tidb/issues/56161) @ [tangenta](https://github.com/tangenta)を追加するときに`duplicate entry`発生する可能性がある問題を修正 + - 一意インデックス[＃56161](https://github.com/pingcap/tidb/issues/56161) @ [tangenta](https://github.com/tangenta)を追加するときに`duplicate entry`発生する可能性がある問題を修正 - `IMPORT INTO`文[＃55970](https://github.com/pingcap/tidb/issues/55970) @ [D3Hunter](https://github.com/D3Hunter)を使用して一時テーブルをインポートするときに TiDB がパニックになる問題を修正しました - インデックス追加[＃55808](https://github.com/pingcap/tidb/issues/55808) @ [lance6716](https://github.com/lance6716)中の再試行によって発生するデータ インデックスの不整合の問題を修正しました diff --git a/releases/release-7.5.5.md b/releases/release-7.5.5.md index 0d13e688d7816..d658187a508fb 100644 --- a/releases/release-7.5.5.md +++ b/releases/release-7.5.5.md @@ -91,7 +91,7 @@ TiDB バージョン: 7.5.5 - `tidb_gogc_tuner_max_value`と`tidb_gogc_tuner_min_value`を設定するときに最大値がnullの場合、誤った警告メッセージが表示される問題を修正しました[＃57889](https://github.com/pingcap/tidb/issues/57889) @ [hawkingrei](https://github.com/hawkingrei) - TiDBの内部コルーチン[＃57798](https://github.com/pingcap/tidb/issues/57798) [＃56053](https://github.com/pingcap/tidb/issues/56053) @ [fishiu](https://github.com/fishiu) @ [tiancaiamao](https://github.com/tiancaiamao)で発生する可能性のあるデータ競合問題を修正しました - 潜在的なセキュリティリスクを防ぐためのアップデート`golang-jwt`と`jwt` [＃57135](https://github.com/pingcap/tidb/issues/57135) @ [hawkingrei](https://github.com/hawkingrei) - - `ALTER TABLE`文[＃57510](https://github.com/pingcap/tidb/issues/57510) @ [mjonss](https://github.com/mjonss)を使用して、クラスタ化インデックスを持つテーブルをパーティションテーブルに変換するときに、同時書き込みによってデータが重複する可能性がある問題を修正しました。 + - `ALTER TABLE`文[＃57510](https://github.com/pingcap/tidb/issues/57510) @ [mjonss](https://github.com/mjonss)を使用して、クラスター化インデックスを持つテーブルをパーティションテーブルに変換するときに、同時書き込みによってデータが重複する可能性がある問題を修正しました。 - TiKV diff --git a/releases/release-8.0.0.md b/releases/release-8.0.0.md index 0fb8420a74308..2292e98de7f6b 100644 --- a/releases/release-8.0.0.md +++ b/releases/release-8.0.0.md @@ -449,12 +449,12 @@ TiDB バージョン: 8.0.0 - `tidb_gogc_tuner_threshold`変数が変更された後、 `tidb_server_memory_limit`システム変数が適切に調整されない問題を修正 [#48180](https://github.com/pingcap/tidb/issues/48180) @[hawkingrei](https://github.com/hawkingrei) - クエリに JOIN 操作が含まれる場合に`index out of range`エラーが発生する可能性がある問題を修正 [#42588](https://github.com/pingcap/tidb/issues/42588) @[AilinKid](https://github.com/AilinKid) - 列のデフォルト値が削除されている場合、列のデフォルト値を取得するとエラーが返される問題を修正します[#50043](https://github.com/pingcap/tidb/issues/50043) [#51324](https://github.com/pingcap/tidb/issues/51324) @[crazycs520](https://github.com/crazycs520) - - TiFlash の遅延実体化処理で関連する列が処理されると、間違った結果が返される場合がある問題を修正[#49241](https://github.com/pingcap/tidb/issues/49241) [#51204](https://github.com/pingcap/tidb/issues/51204) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - TiFlash の遅延マテリアライゼーション処理で関連する列が処理されると、間違った結果が返される場合がある問題を修正[#49241](https://github.com/pingcap/tidb/issues/49241) [#51204](https://github.com/pingcap/tidb/issues/51204) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - `LIKE()`関数がバイナリ照合順序入力を処理する際に誤った結果を返す可能性がある問題を修正しました [#50393](https://github.com/pingcap/tidb/issues/50393) @[yibin87](https://github.com/yibin87) - `JSON_LENGTH()`関数が、2 番目のパラメータが`NULL`の場合に誤った結果を返す問題を修正しました [#50931](https://github.com/pingcap/tidb/issues/50931) @[SeaRise](https://github.com/SeaRise) - `CAST(AS DATETIME)`が特定の状況下で時間精度を失う可能性がある問題を修正 [#49555](https://github.com/pingcap/tidb/issues/49555) @[SeaRise](https://github.com/SeaRise) - テーブルにクラスター化インデックスがある場合、並列処理`Apply`が誤った結果を生成する可能性がある問題を修正 [#51372](https://github.com/pingcap/tidb/issues/51372) @[guo-shaoge](https://github.com/guo-shaoge) - - プライマリキーのタイプが`ALTER TABLE ... COMPACT TIFLASH REPLICA` `VARCHAR`が正しく終了しない可能性がある問題を修正 [#51810](https://github.com/pingcap/tidb/issues/51810) @[breezewish](https://github.com/breezewish) + - `ALTER TABLE ... COMPACT TIFLASH REPLICA`が主キーの型が`VARCHAR`の場合に正しく終了しない可能性がある問題を修正 [#51810](https://github.com/pingcap/tidb/issues/51810) @[breezewish](https://github.com/breezewish) - `NULL`ステートメントを使用してパーティション テーブルを交換する際に`DEFAULT NULL`属性の`EXCHANGE PARTITION`値のチェックが正しく行われない問題を修正しました。 [#47167](https://github.com/pingcap/tidb/issues/47167) @[jiyfhust](https://github.com/jiyfhust) - パーティションテーブルの定義が、UTF8以外の文字セットを使用した場合に誤った動作を引き起こす可能性がある問題を修正しました [#49251](https://github.com/pingcap/tidb/issues/49251) @[YangKeao](https://github.com/YangKeao) - 一部のシステム変数について、 `INFORMATION_SCHEMA.VARIABLES_INFO`テーブルに誤ったデフォルト値が表示される問題を修正しました [#49461](https://github.com/pingcap/tidb/issues/49461) @[jiyfhust](https://github.com/jiyfhust) @@ -539,7 +539,7 @@ TiDB バージョン: 8.0.0 - TiDBデータ移行（DM） - - アップストリームのプライマリキーがバイナリタイプの場合にデータが失われる問題を修正 [#10672](https://github.com/pingcap/tiflow/issues/10672) @[GMHDBJD](https://github.com/GMHDBJD) + - アップストリームの主キーがバイナリ型の場合にデータが失われる問題を修正 [#10672](https://github.com/pingcap/tiflow/issues/10672) @[GMHDBJD](https://github.com/GMHDBJD) - TiDB Lightning diff --git a/releases/release-8.1.0.md b/releases/release-8.1.0.md index a63b17a40c8b3..33d33362ccd5e 100644 --- a/releases/release-8.1.0.md +++ b/releases/release-8.1.0.md @@ -96,8 +96,8 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 ### 行動の変化 {#behavior-changes} - 以前のバージョンでは、 TiDB Lightningの`tidb.tls`設定項目は、値`"false"`と`""` 、および値`"preferred"`と`"skip-verify"`同じものとして扱いました。v8.1.0 以降、 TiDB Lightning は`tidb.tls`に対して`"false"` 、 `""` 、 `"skip-verify"` 、 `"preferred"`の動作を区別します。詳細については、 [TiDB Lightning構成](/tidb-lightning/tidb-lightning-configuration.md)参照してください。 -- `AUTO_ID_CACHE=1`のテーブルの場合、TiDB は[集中型自動増分ID割り当てサービス](/auto-increment.md#mysql-compatibility-mode)サポートします。以前のバージョンでは、このサービスのプライマリ TiDB ノードは、TiDB プロセスが終了すると（たとえば、TiDB ノードの再起動中）、自動割り当て ID を可能な限り連続的に保つために`forceRebase`操作を自動的に実行していました。しかし、 `AUTO_ID_CACHE=1`のテーブルが多すぎると、 `forceRebase`実行に非常に時間がかかり、TiDB がすぐに再起動できなくなり、データの書き込みがブロックされてシステムの可用性に影響を及ぼします。この問題を解決するために、v8.1.0 以降、TiDB は`forceRebase`動作を削除しますが、この変更により、フェイルオーバー中に一部の自動割り当て ID が連続しなくなります。 -- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`イベントで主キーまたは null 以外の一意のインデックス値が変更されると、TiCDC はこのイベントを`DELETE`と`INSERT`イベントに分割していました。v8.1.0 では、MySQL シンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS`が TiCDC `thresholdTS` (TiCDC の起動時に PD から取得する現在のタイムスタンプ) より小さい場合、TiCDC は`UPDATE`のイベントを`DELETE`と`INSERT`イベントに分割します。この動作変更により、TiCDC が受信した`UPDATE`のイベントの順序が正しくない可能性があり、その結果、分割された`DELETE`と`INSERT`件のイベントの順序も正しくなくなる可能性がある、下流データの不整合の問題が解決されます。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#split-update-events-for-mysql-sinks)参照してください。 +- `AUTO_ID_CACHE=1`のテーブルの場合、TiDB は[集中型自動増分ID割り当てサービス](/auto-increment.md#mysql-compatibility-mode)をサポートします。以前のバージョンでは、このサービスのプライマリ TiDB ノードは、TiDB プロセスが終了すると（たとえば、TiDB ノードの再起動中）、自動割り当て ID を可能な限り連続的に保つために`forceRebase`操作を自動的に実行していました。しかし、 `AUTO_ID_CACHE=1`のテーブルが多すぎると、 `forceRebase`実行に非常に時間がかかり、TiDB がすぐに再起動できなくなり、データの書き込みがブロックされてシステムの可用性に影響を及ぼします。この問題を解決するために、v8.1.0 以降、TiDB は`forceRebase`動作を削除しますが、この変更により、フェイルオーバー中に一部の自動割り当て ID が連続しなくなります。 +- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`イベントで主キーまたは null 以外の一意インデックス値が変更されると、TiCDC はこのイベントを`DELETE`と`INSERT`イベントに分割していました。v8.1.0 では、MySQL シンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS`が TiCDC `thresholdTS` (TiCDC の起動時に PD から取得する現在のタイムスタンプ) より小さい場合、TiCDC は`UPDATE`のイベントを`DELETE`と`INSERT`イベントに分割します。この動作変更により、TiCDC が受信した`UPDATE`のイベントの順序が正しくない可能性があり、その結果、分割された`DELETE`と`INSERT`件のイベントの順序も正しくなくなる可能性がある、下流データの不整合の問題が解決されます。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#split-update-events-for-mysql-sinks)参照してください。 ### システム変数 {#system-variables} @@ -218,7 +218,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 - `TIDB_HOT_REGIONS`テーブルをクエリすると、誤って`INFORMATION_SCHEMA`テーブル[＃50810](https://github.com/pingcap/tidb/issues/50810) @ [Defined2014](https://github.com/Defined2014)が返される可能性がある問題を修正しました。 - 特定の列の統計情報が完全にロードされていない場合に、 `EXPLAIN`ステートメントの結果に誤った列 ID が表示される可能性がある問題を修正しました[＃52207](https://github.com/pingcap/tidb/issues/52207) @ [time-and-fate](https://github.com/time-and-fate) - `IFNULL`関数によって返される型が MySQL [＃51765](https://github.com/pingcap/tidb/issues/51765) @ [YangKeao](https://github.com/YangKeao)と一致しない問題を修正しました - - ユニークインデックスを追加するとTiDBがpanic可能性がある問題を修正[＃52312](https://github.com/pingcap/tidb/issues/52312) @ [wjhuang2016](https://github.com/wjhuang2016) + - 一意インデックスを追加するとTiDBがpanic可能性がある問題を修正[＃52312](https://github.com/pingcap/tidb/issues/52312) @ [wjhuang2016](https://github.com/wjhuang2016) - TiKV diff --git a/releases/release-8.1.1.md b/releases/release-8.1.1.md index 11c7cab5fbd4b..12c34bd0417fc 100644 --- a/releases/release-8.1.1.md +++ b/releases/release-8.1.1.md @@ -116,7 +116,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - 分散実行フレームワーク (DXF) を使用してインデックスを追加する際のネットワーク パーティションによって、データ インデックス[＃54897](https://github.com/pingcap/tidb/issues/54897) @ [tangenta](https://github.com/tangenta)の不整合が発生する可能性がある問題を修正しました。 - TiDB Lightning物理インポートモードの初期化中にエラーが発生し、リソースリークが発生する可能性がある問題を修正[＃53659](https://github.com/pingcap/tidb/issues/53659) @ [D3Hunter](https://github.com/D3Hunter) - ビュー定義[＃54343](https://github.com/pingcap/tidb/issues/54343) @ [lance6716](https://github.com/lance6716)でサブクエリが列定義として使用されている場合、 `information_schema.columns`を使用して列情報を取得すると警告1356が返される問題を修正しました。 - - インデックスアクセラレーションを使用して一意のインデックスを追加すると、所有者が[＃49233](https://github.com/pingcap/tidb/issues/49233) @ [lance6716](https://github.com/lance6716)に切り替えられたときに`Duplicate entry`エラーが発生する可能性がある問題を修正しました。 + - インデックスアクセラレーションを使用して一意インデックスを追加すると、所有者が[＃49233](https://github.com/pingcap/tidb/issues/49233) @ [lance6716](https://github.com/lance6716)に切り替えられたときに`Duplicate entry`エラーが発生する可能性がある問題を修正しました。 - `global.tidb_cloud_storage_uri` [＃54096](https://github.com/pingcap/tidb/issues/54096) @ [lance6716](https://github.com/lance6716)を設定するときに不明瞭なエラーメッセージが表示される問題を修正しました - 同期負荷QPSモニタリングメトリックが正しくない問題を修正[＃53558](https://github.com/pingcap/tidb/issues/53558) @ [hawkingrei](https://github.com/hawkingrei) - 初期統計を同時に[＃53607](https://github.com/pingcap/tidb/issues/53607) @ [hawkingrei](https://github.com/hawkingrei)でロードするときに一部の統計情報が失われる可能性がある問題を修正しました diff --git a/releases/release-8.1.2.md b/releases/release-8.1.2.md index 8ad8d2683d252..0abe156c02bb8 100644 --- a/releases/release-8.1.2.md +++ b/releases/release-8.1.2.md @@ -80,7 +80,7 @@ TiDB バージョン: 8.1.2 - 共通テーブル式 (CTE) に複数のデータ コンシューマーがあり、1 つのコンシューマーがデータを読み取らずに終了した場合に発生する可能性のある無効なメモリアクセスの問題を修正しました[＃55881](https://github.com/pingcap/tidb/issues/55881) @ [windtalker](https://github.com/windtalker) - TTLタスクをキャンセルした際に、対応するSQLが強制終了されない問題を修正[＃56511](https://github.com/pingcap/tidb/issues/56511) @ [lcwangchao](https://github.com/lcwangchao) - `IMPORT INTO`文[＃55970](https://github.com/pingcap/tidb/issues/55970) @ [D3Hunter](https://github.com/D3Hunter)を使用して一時テーブルをインポートするときに TiDB がパニックになる問題を修正しました - - クエリ条件`column IS NULL` [＃56116](https://github.com/pingcap/tidb/issues/56116) @ [hawkingrei](https://github.com/hawkingrei)でユニークインデックスにアクセスするときに、オプティマイザが行数を誤って 1 と推定する問題を修正しました。 + - クエリ条件`column IS NULL` [＃56116](https://github.com/pingcap/tidb/issues/56116) @ [hawkingrei](https://github.com/hawkingrei)で一意インデックスにアクセスするときに、オプティマイザが行数を誤って 1 と推定する問題を修正しました。 - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、古い読み取りのクエリレイテンシーが増加する問題を修正しました。 - `UPDATE`文が`ENUM`型[＃56832](https://github.com/pingcap/tidb/issues/56832) @ [xhebox](https://github.com/xhebox)の値を誤って更新する問題を修正しました - 外部キー[＃56456](https://github.com/pingcap/tidb/issues/56456) @ [hawkingrei](https://github.com/hawkingrei)を含むテーブル構造をインポートするときに Plan Replayer がエラーを報告する可能性がある問題を修正しました。 diff --git a/releases/release-8.2.0.md b/releases/release-8.2.0.md index 73cf45cbf61fd..6fc31db593d91 100644 --- a/releases/release-8.2.0.md +++ b/releases/release-8.2.0.md @@ -262,7 +262,7 @@ TiDB バージョン: 8.2.0 - 述語における`Longlong`型のオーバーフロー問題を修正 [#45783](https://github.com/pingcap/tidb/issues/45783) @[hawkingrei](https://github.com/hawkingrei) - Window関数内に関連サブクエリがある場合にpanicする可能性がある問題を修正しました [#42734](https://github.com/pingcap/tidb/issues/42734) @[Rustin170506](https://github.com/Rustin170506) - TopN演算子が正しくプッシュダウンされない可能性がある問題を修正しました [#37986](https://github.com/pingcap/tidb/issues/37986) @[qw4990](https://github.com/qw4990) - - クラスタ化インデックスを述語として使用する場合に`SELECT INTO OUTFILE`が機能しない問題を修正 [#42093](https://github.com/pingcap/tidb/issues/42093) @[qw4990](https://github.com/qw4990) + - クラスター化インデックスを述語として使用する場合に`SELECT INTO OUTFILE`が機能しない問題を修正 [#42093](https://github.com/pingcap/tidb/issues/42093) @[qw4990](https://github.com/qw4990) - 情報スキーマキャッシュのミスによって古い読み取りのクエリレイテンシーが増加する問題を修正します [#53428](https://github.com/pingcap/tidb/issues/53428) @[crazycs520](https://github.com/crazycs520) - `YEAR`型の列を範囲外の符号なし整数と比較すると誤った結果が生じる問題を修正しました [#50235](https://github.com/pingcap/tidb/issues/50235) @[qw4990](https://github.com/qw4990) - TiDBを再起動した後に、主キー列統計のヒストグラムとTopNが読み込まれない問題を修正しました [#37548](https://github.com/pingcap/tidb/issues/37548) @[hawkingrei](https://github.com/hawkingrei) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index e277721ec6c8b..40768e13a4836 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -313,7 +313,7 @@ TiDB をアップグレードする前に、オペレーティング システ - `a = 1 AND (a > 1 OR (a = 1 AND b = 2))`から`a = 1 AND b = 2`のようなフィルター条件を簡素化 [#56005](https://github.com/pingcap/tidb/issues/56005) @[ghazalfamilyusa](https://github.com/ghazalfamilyusa) - 最適ではない実行プランのリスクが高いシナリオでは、コストモデルでテーブルスキャンのコストを増やし、オプティマイザがインデックスを優先するようにします [#56012](https://github.com/pingcap/tidb/issues/56012) @[terry1purcell](https://github.com/terry1purcell) - TiDB は 2 つの引数を持つバリアント`MID(str, pos)`をサポートしています [#52420](https://github.com/pingcap/tidb/issues/52420) @[dveeden](https://github.com/dveeden) - - バイナリ以外のプライマリキーを持つテーブルのTTLタスクの分割をサポート [#55660](https://github.com/pingcap/tidb/issues/55660) @[lcwangchao](https://github.com/lcwangchao) + - バイナリ型以外の主キーを持つテーブルのTTLタスクの分割をサポート [#55660](https://github.com/pingcap/tidb/issues/55660) @[lcwangchao](https://github.com/lcwangchao) - システムのメタデータ関連ステートメントのパフォーマンスを最適化する [#50305](https://github.com/pingcap/tidb/issues/50305) @[ywqzzy](https://github.com/ywqzzy) @[tangenta](https://github.com/tangenta)@[joechenrh](https://github.com/joechenrh) @[CbcWestwolf](https://github.com/CbcWestwolf) - 自動分析操作に新しい優先度キューを実装して、分析パフォーマンスを向上させ、キューの再構築コストを削減します [#55906](https://github.com/pingcap/tidb/issues/55906) @[Rustin170506](https://github.com/Rustin170506) - 統計モジュールがDDLイベントを購読できるように、DDL通知機能を導入する [#55722](https://github.com/pingcap/tidb/issues/55722) @[fzzf678](https://github.com/fzzf678) @[lance6716](https://github.com/lance6716) @[Rustin170506](https://github.com/Rustin170506) diff --git a/releases/release-8.5.0.md b/releases/release-8.5.0.md index 3e70ea849190a..9ca3e787a71bd 100644 --- a/releases/release-8.5.0.md +++ b/releases/release-8.5.0.md @@ -272,7 +272,7 @@ TiDB をアップグレードする前に、オペレーティング システ - 複数テーブルの`DELETE`ステートメントに対して、エイリアスを使用した実行プランバインディングを作成できない問題を修正 [#56726](https://github.com/pingcap/tidb/issues/56726) @[hawkingrei](https://github.com/hawkingrei) - オプティマイザが複雑な述語を簡略化する際に文字セットと照合順序を考慮しないため、実行エラーが発生する可能性がある問題を修正しました [#56479](https://github.com/pingcap/tidb/issues/56479) @[dash12653](https://github.com/dash12653) - Grafana の**Stats Healthy Distribution**パネルのデータが正しくない可能性がある問題を修正 [#57176](https://github.com/pingcap/tidb/issues/57176) @[hawkingrei](https://github.com/hawkingrei) - - クラスタ化インデックスを持つテーブルをクエリする際に、ベクトル検索が誤った結果を返す可能性がある問題を修正 [#57627](https://github.com/pingcap/tidb/issues/57627) @[winoros](https://github.com/winoros) + - クラスター化インデックスを持つテーブルをクエリする際に、ベクトル検索が誤った結果を返す可能性がある問題を修正 [#57627](https://github.com/pingcap/tidb/issues/57627) @[winoros](https://github.com/winoros) - TiKV diff --git a/releases/release-8.5.5.md b/releases/release-8.5.5.md index e010e2aaf306e..ae1e7ffd0459a 100644 --- a/releases/release-8.5.5.md +++ b/releases/release-8.5.5.md @@ -258,7 +258,7 @@ TiDBクラスタがv8.5.4で新規にデプロイされている場合（つま - TiFlashレプリカからキャッシュされたテーブルを読み取る際に、ゴルーチンとメモリリークが発生する可能性がある問題を修正しました [#63329](https://github.com/pingcap/tidb/issues/63329) @[xzhangxian1008](https://github.com/xzhangxian1008) - `ALTER TABLE child CHANGE COLUMN`を実行して列を変更した後、外部キーが更新されない問題を修正しました [#59705](https://github.com/pingcap/tidb/issues/59705) @[fzzf678](https://github.com/fzzf678) - 以前の TiDB バージョンから`RENAME TABLE`ジョブ引数が正しくデコードされない問題を修正しました [#64413](https://github.com/pingcap/tidb/issues/64413) @[joechenrh](https://github.com/joechenrh) - - BR復元が失敗した場合に自動インクリメントIDが再ベースされない問題を修正 [#60804](https://github.com/pingcap/tidb/issues/60804) @[joechenrh](https://github.com/joechenrh) + - BR復元が失敗した場合に自動インクリメントIDがリベースされない問題を修正 [#60804](https://github.com/pingcap/tidb/issues/60804) @[joechenrh](https://github.com/joechenrh) - アップグレード中に TiDB ノードがスタックする可能性がある問題を修正 [#64539](https://github.com/pingcap/tidb/issues/64539) @[joechenrh](https://github.com/joechenrh) - インデックスレコードが欠落している場合に管理者チェックでエラーが報告されない問題を修正 [#63698](https://github.com/pingcap/tidb/issues/63698) @[wjhuang2016](https://github.com/wjhuang2016) - `MODIFY COLUMN`を介して照合順序を変更するとデータインデックスの不整合が発生する問題を修正 [#61668](https://github.com/pingcap/tidb/issues/61668) @[tangenta](https://github.com/tangenta) diff --git a/releases/release-rc.2.md b/releases/release-rc.2.md index 1aca06ec532d3..cb8ba0f93e7e0 100644 --- a/releases/release-rc.2.md +++ b/releases/release-rc.2.md @@ -34,7 +34,7 @@ summary: 2017年3月1日にリリースされたTiDB RC2は、MySQLとの互換 ## PD {#pd} - 位置認識レプリカスケジューリングをサポート -- 地域数に基づいて迅速なスケジュールを実施 +- リージョン数に基づいて迅速なスケジュールを実施 - pd-ctl はより多くの機能をサポートします - PDを追加または削除する - キーでリージョン情報を取得する diff --git a/shard-row-id-bits.md b/shard-row-id-bits.md index 71ca570c81758..a172e42953e7f 100644 --- a/shard-row-id-bits.md +++ b/shard-row-id-bits.md @@ -9,7 +9,7 @@ summary: SHARD_ROW_ID_BITS属性について学びましょう。 ## コンセプト {#concept} -クラスタ化されていないプライマリキーまたはプライマリキーのないテーブルの場合、TiDB は自動的に生成された[`_tidb_rowid`](/tidb-rowid.md)暗黙の自動インクリメント行 ID として使用します。多数の`INSERT`操作が実行されると、データは単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 +クラスター化されていない主キーまたは主キーのないテーブルの場合、TiDB は自動的に生成された[`_tidb_rowid`](/tidb-rowid.md)を暗黙のAUTO_INCREMENT行IDとして使用します。多数の`INSERT`操作が実行されると、データは単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 ホットスポットの問題を軽減するには、 `SHARD_ROW_ID_BITS`設定できます。行 ID は分散しており、データは複数の異なるリージョンに書き込まれます。 @@ -19,7 +19,7 @@ summary: SHARD_ROW_ID_BITS属性について学びましょう。 `SHARD_ROW_ID_BITS = S`設定すると、 `_tidb_rowid`の構造は次のようになります。 -| サインビット | 破片の断片 | 自動インクリメントビット | +| サインビット | シャードビット | AUTO_INCREMENTビット | | ------ | ------ | ------------ | | 1ビット | `S`ビット | `63-S`ビット | @@ -28,7 +28,7 @@ summary: SHARD_ROW_ID_BITS属性について学びましょう。 > **警告：** > -> `_tidb_rowid`は TiDB によって暗黙的に割り当てられる内部行 ID です。すべての場合においてグローバルに一意であると想定しないでください。クラスタ化インデックスを使用しないパーティション テーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`異なるパーティションに同じ`_tidb_rowid`値を残す可能性があります。詳細については、 [`_tidb_rowid`](/tidb-rowid.md)参照してください。 +> `_tidb_rowid`は TiDB によって暗黙的に割り当てられる内部行 ID です。すべての場合においてグローバルに一意であると想定しないでください。クラスター化インデックスを使用しないパーティション テーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`異なるパーティションに同じ`_tidb_rowid`値を残す可能性があります。詳細については、 [`_tidb_rowid`](/tidb-rowid.md)参照してください。 > **注記：** > diff --git a/sql-statements/sql-statement-create-table-like.md b/sql-statements/sql-statement-create-table-like.md index b810c9456c6b8..8c6dce75c311e 100644 --- a/sql-statements/sql-statement-create-table-like.md +++ b/sql-statements/sql-statement-create-table-like.md @@ -53,7 +53,7 @@ mysql> SELECT * FROM t2; Empty set (0.00 sec) ``` -## 分割前の地域 {#pre-split-region} +## 分割前のリージョン {#pre-split-region} コピー元のテーブルに`PRE_SPLIT_REGIONS`属性が定義されている場合、 `CREATE TABLE LIKE`文で作成されたテーブルはこの属性を継承し、新しいテーブルのリージョンは分割されます。5の詳細については、 `PRE_SPLIT_REGIONS` [`CREATE TABLE`文](/sql-statements/sql-statement-create-table.md)参照してください。 diff --git a/sql-statements/sql-statement-show-table-regions.md b/sql-statements/sql-statement-show-table-regions.md index c1dea3b501e92..92aaed873c5a4 100644 --- a/sql-statements/sql-statement-show-table-regions.md +++ b/sql-statements/sql-statement-show-table-regions.md @@ -34,7 +34,7 @@ TableName ::= - `START_KEY` :リージョンの開始キー。 - `END_KEY` :リージョンの終了キー。 - `LEADER_ID` :リージョンのLeaderID 。 -- `LEADER_STORE_ID` :リージョンリーダーが所在する店舗 (TiKV) の ID。 +- `LEADER_STORE_ID` :リージョンリーダーが所在するストア (TiKV) の ID。 - `PEERS` : すべてのリージョンレプリカのID。 - `SCATTERING` :リージョンがスケジュールされているかどうか。 `1`は true を意味します。 - `WRITTEN_BYTES` : 1回のハートビートサイクルでリージョンに書き込まれるデータの推定量。単位はバイトです。 diff --git a/sql-statements/sql-statement-split-region.md b/sql-statements/sql-statement-split-region.md index 032093c1df325..c6422515a1615 100644 --- a/sql-statements/sql-statement-split-region.md +++ b/sql-statements/sql-statement-split-region.md @@ -68,8 +68,8 @@ RowValue ::= +--------------------+----------------------+ ``` -- `TOTAL_SPLIT_REGION` : 新たに分割された地域の数。 -- `SCATTER_FINISH_RATIO` : 新しく分割されたリージョンの分散完了率。 `1.0`すべてのリージョンが分散されたことを意味します。 `0.5`は、リージョンの半分のみが分散され、残りは分散中であることを意味します。 +- `TOTAL_SPLIT_REGION` : 新たに分割されたリージョンの数。 +- `SCATTER_FINISH_RATIO` : 新しく分割されたリージョンの再配置完了率。 `1.0`すべてのリージョンが再配置されたことを意味します。 `0.5`は、リージョンの半分のみが再配置され、残りは再配置中であることを意味します。 > **注記：** > diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index 13e0f355c15f4..9cebcb0cb556a 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -807,7 +807,7 @@ TiFlash は次のシナリオで使用します。 - 大規模データ分析： TiFlashは、大規模なデータスキャンを必要とするOLAPワークロードにおいて、より高速なパフォーマンスを提供します。列指向ストレージとMPP実行モードにより、TiKVと比較してクエリ効率が最適化されます。 - 複雑なスキャン、集計、結合: TiFlash は、必要な列のみを読み取ることで、集計や結合の負荷が高いクエリをより効率的に処理します。 - 混合ワークロード: トランザクション (OLTP) ワークロードと分析 (OLAP) ワークロードの両方が同時に実行されるハイブリッド環境では、 TiFlash はトランザクション クエリに対する TiKV のパフォーマンスに影響を与えずに分析クエリを処理します。 -- 任意のフィルタリング要件を持つSaaSアプリケーション：クエリでは、多くの場合、多数の列にまたがるフィルタリングが必要になります。すべての列にインデックスを付けるのは現実的ではなく、特にテナントIDがクエリの主キーの一部に含まれている場合はなおさらです。TiFlashは主キーに基づいてデータをソートおよびクラスタ化するため、このようなワークロードに最適です。TiFlashの[遅い実現](/tiflash/tiflash-late-materialization.md)機能により、効率的なテーブル範囲スキャンが可能になり、複数のインデックスを維持するオーバーヘッドなしでクエリパフォーマンスが向上します。 +- 任意のフィルタリング要件を持つSaaSアプリケーション：クエリでは、多くの場合、多数の列にまたがるフィルタリングが必要になります。すべての列にインデックスを付けるのは現実的ではなく、特にテナントIDがクエリの主キーの一部に含まれている場合はなおさらです。TiFlashは主キーに基づいてデータをソートおよびクラスター化するため、このようなワークロードに最適です。TiFlashの[遅延マテリアライゼーション](/tiflash/tiflash-late-materialization.md)機能により、効率的なテーブル範囲スキャンが可能になり、複数のインデックスを維持するオーバーヘッドなしでクエリパフォーマンスが向上します。 TiFlash を戦略的に使用することで、クエリパフォーマンスが向上し、データ集約型の分析クエリにおける TiDB のリソース使用が最適化されます。以下のセクションでは、 TiFlashのユースケース例を紹介します。 diff --git a/system-variable-reference.md b/system-variable-reference.md index 4813e40266d3a..9de7d629831cb 100644 --- a/system-variable-reference.md +++ b/system-variable-reference.md @@ -14,11 +14,11 @@ summary: すべての TiDB システム変数とドキュメント内の参照 ## 変数参照 {#variable-reference} -### 自動ランダム明示挿入を許可する {#allow-auto-random-explicit-insert} +### AUTO_RANDOM明示挿入を許可する {#allow-auto-random-explicit-insert} 参照先: -- [自動ランダム](/auto-random.md) +- [AUTO_RANDOM](/auto-random.md) - [データの挿入](/develop/dev-guide-insert-data.md) - [セッション変数](/information-schema/information-schema-session-variables.md) - [システム変数](/system-variables.md#allow_auto_random_explicit_insert-new-in-v403) @@ -169,7 +169,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [自動インクリメント](/auto-increment.md) -- [自動ランダム](/auto-random.md) +- [AUTO_RANDOM](/auto-random.md) - [双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md) - [エラーコードとトラブルシューティング](/error-codes.md) - [セッション変数](/information-schema/information-schema-session-variables.md) @@ -184,7 +184,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [自動インクリメント](/auto-increment.md) -- [自動ランダム](/auto-random.md) +- [AUTO_RANDOM](/auto-random.md) - [双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md) - [エラーコードとトラブルシューティング](/error-codes.md) - [セッション変数](/information-schema/information-schema-session-variables.md) @@ -452,7 +452,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [自動ランダム](/auto-random.md) +- [AUTO_RANDOM](/auto-random.md) - [mysql2でTiDBに接続する](/develop/dev-guide-sample-application-ruby-mysql2.md) - [情報機能](/functions-and-operators/information-functions.md) - [ショービルド](/sql-statements/sql-statement-show-builtins.md) @@ -2997,7 +2997,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [システム変数](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700) -- [TiFlash遅延実体化](/tiflash/tiflash-late-materialization.md) +- [TiFlash遅延マテリアライゼーション](/tiflash/tiflash-late-materialization.md) - [TiDB 7.1.0 リリースノート](/releases/release-7.1.0.md) - [TiDB 7.0.0 リリースノート](/releases/release-7.0.0.md) diff --git a/system-variables.md b/system-variables.md index c234391457ddf..ad630fa0f516a 100644 --- a/system-variables.md +++ b/system-variables.md @@ -1665,7 +1665,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **警告：** > -> 現在、この機能は[単一の`ALTER TABLE`ステートメントで複数の列またはインデックスを変更する](/sql-statements/sql-statement-alter-table.md)完全な互換性はありません。インデックス アクセラレーションを使用して一意のインデックスを追加する場合は、同じステートメント内の他の列やインデックスを変更しないようにする必要があります。 +> 現在、この機能は[単一の`ALTER TABLE`ステートメントで複数の列またはインデックスを変更する](/sql-statements/sql-statement-alter-table.md)完全な互換性はありません。インデックス アクセラレーションを使用して一意インデックスを追加する場合は、同じステートメント内の他の列やインデックスを変更しないようにする必要があります。 @@ -2082,10 +2082,10 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - タイプ: 列挙型 - デフォルト値: `ON` - 指定可能な値: `OFF` 、 `ON` 、 `INT_ONLY` -- この変数は、プライマリキー[クラスター化インデックス](/clustered-indexes.md)化 として作成するかどうかを制御するために使用されます。ここで「デフォルト」とは、ステートメントがキーワード`CLUSTERED` / `NONCLUSTERED`を明示的に指定しないことを意味します。サポートされている値は`OFF` 、 `ON` 、および`INT_ONLY`です。 - - `OFF`は、プライマリキーがデフォルトで非クラスター化インデックスとして作成されることを示します。 - - `ON`は、プライマリキーがデフォルトでクラスタ化インデックスとして作成されることを示します。 - - `INT_ONLY`は、動作が構成項目`alter-primary-key`によって制御されることを示します。 `alter-primary-key`が`true`に設定されている場合、すべての主キーはデフォルトで非クラスタ化インデックスとして作成されます。 `false`に設定されている場合、整数列で構成される主キーのみがクラスタ化インデックスとして作成されます。 +- この変数は、主キー[クラスター化インデックス](/clustered-indexes.md)化 として作成するかどうかを制御するために使用されます。ここで「デフォルト」とは、ステートメントがキーワード`CLUSTERED` / `NONCLUSTERED`を明示的に指定しないことを意味します。サポートされている値は`OFF` 、 `ON` 、および`INT_ONLY`です。 + - `OFF`は、主キーがデフォルトで非クラスター化インデックスとして作成されることを示します。 + - `ON`は、主キーがデフォルトでクラスター化インデックスとして作成されることを示します。 + - `INT_ONLY`は、動作が構成項目`alter-primary-key`によって制御されることを示します。 `alter-primary-key`が`true`に設定されている場合、すべての主キーはデフォルトで非クラスター化インデックスとして作成されます。 `false`に設定されている場合、整数列で構成される主キーのみがクラスター化インデックスとして作成されます。 ### tidb_enable_ddl はv6.3.0 で追加されました。 {#tidb-enable-ddl-span-class-version-mark-new-in-v6-3-0-span} @@ -2250,7 +2250,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - タイプ: ブール値 - デフォルト値: `ON` -- この変数は、パーティション テーブルに対して[グローバルインデックス](/global-indexes.md)インデックスの作成をサポートするかどうかを制御します。この変数を有効にすると、TiDB では、インデックス定義で`GLOBAL`指定することで**、パーティション式で使用されているすべての列を含まない**一意のインデックスを作成できます。 +- この変数は、パーティション テーブルに対して[グローバルインデックス](/global-indexes.md)インデックスの作成をサポートするかどうかを制御します。この変数を有効にすると、TiDB では、インデックス定義で`GLOBAL`指定することで**、パーティション式で使用されているすべての列を含まない**一意インデックスを作成できます。 - この変数は v8.4.0 以降非推奨になりました。その値はデフォルト値`ON`に固定されています。つまり、[グローバルインデックス](/global-indexes.md)はデフォルトで有効になっています。 ### tidb_enable_lazy_cursor_fetch v8.3.0で追加 {#tidb-enable-lazy-cursor-fetch-span-class-version-mark-new-in-v8-3-0-span} @@ -4407,7 +4407,7 @@ mysql> desc select count(distinct a) from test.t; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - タイプ: ブール値 - デフォルト値: `ON` -- この変数は、 [TiFlashの遅延実現](/tiflash/tiflash-late-materialization.md)機能を有効にするかどうかを制御するために使用されます。 TiFlash の遅延実体化は[高速スキャンモード](/tiflash/use-fastscan.md)では有効にならないことに注意してください。 +- この変数は、 [TiFlashの遅延マテリアライゼーション](/tiflash/tiflash-late-materialization.md)機能を有効にするかどうかを制御するために使用されます。 TiFlash の遅延マテリアライゼーションは[高速スキャンモード](/tiflash/use-fastscan.md)では有効にならないことに注意してください。 - この変数を`OFF`に設定してTiFlash の遅延マテリアライゼーション機能を無効にした場合、フィルタ条件 ( { `SELECT`句) を含む`WHERE`ステートメントを処理するために、 TiFlash はフィルタリングの前に必要な列のすべてのデータをスキャンします。この変数を`ON`に設定してTiFlash の遅延マテリアライゼーション機能を有効にすると、 TiFlash は、TableScan オペレータにプッシュダウンされたフィルタ条件に関連する列データを最初にスキャンし、条件を満たす行をフィルタリングしてから、これらの行の他の列のデータをスキャンしてさらに計算を行うことができ、これにより、データ処理の IO スキャンと計算を削減できます。 ### tidb_opt_enable_mpp_shared_cte_execution v7.2.0で追加 {#tidb-opt-enable-mpp-shared-cte-execution-span-class-version-mark-new-in-v7-2-0-span} diff --git a/ticdc/ticdc-architecture.md b/ticdc/ticdc-architecture.md index 30ed6580f7f87..09e8255096214 100644 --- a/ticdc/ticdc-architecture.md +++ b/ticdc/ticdc-architecture.md @@ -49,7 +49,7 @@ TiCDCの新しいアーキテクチャは、アーキテクチャをステート - 増分スキャンパフォーマンスのボトルネック: 増分スキャンタスクの完了に過度に時​​間がかかり、レプリケーションのレイテンシーが継続的に増加します。 - 超高トラフィックシナリオ：変更フィードの総トラフィックが700 MiB/秒を超える場合。 -- MySQL シンクで高スループット書き込みを行う単一テーブル: ターゲットテーブルには**、プライマリキーまたは NULL 以外の一意キーが 1 つだけ**あります。 +- MySQL シンクで高スループット書き込みを行う単一テーブル: ターゲットテーブルには**、主キーまたは NULL 以外の一意キーが 1 つだけ**あります。 - 大規模なテーブルレプリケーション：レプリケーション対象のテーブル数が10万を超える場合。 - 頻繁な DDL 操作によるレイテンシー: DDL ステートメントの頻繁な実行は、レプリケーションのレイテンシーを大幅に増加させます。 diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md index 3f85f2da6754e..9a06c61ce89de 100644 --- a/ticdc/ticdc-avro-protocol.md +++ b/ticdc/ticdc-avro-protocol.md @@ -54,7 +54,7 @@ TiCDC は DML イベントを Kafka イベントに変換し、イベントの - `{{Namespace}}`は Avro の名前空間です。 - `{{ColumnValueBlock}}`データの各列の形式を定義します。 -キーの`fields`には、主キー列または一意のインデックス列のみが含まれます。 +キーの`fields`には、主キー列または一意インデックス列のみが含まれます。 ### 値のデータ形式 {#value-data-format} diff --git a/ticdc/ticdc-changefeed-config.md b/ticdc/ticdc-changefeed-config.md index dfe855b9eacbd..5c5c8a982a5c6 100644 --- a/ticdc/ticdc-changefeed-config.md +++ b/ticdc/ticdc-changefeed-config.md @@ -125,7 +125,7 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl ##### ignore-event {#code-ignore-event-code} - `ignore-event = ["insert"]`は`INSERT`イベントを無視します。 -- `ignore-event = ["drop table", "delete"]`は`DROP TABLE` DDL イベントと`DELETE` DML イベントを無視します。 TiDB でクラスタ化インデックス列の値が更新されると、TiCDC は`UPDATE`イベントを`DELETE`イベントと`INSERT`イベントに分割することに注意してください。 TiCDC はこれらのイベントを`UPDATE`イベントとして識別できないため、これらのイベントを正しくフィルタリングできません。 +- `ignore-event = ["drop table", "delete"]`は`DROP TABLE` DDL イベントと`DELETE` DML イベントを無視します。 TiDB でクラスター化インデックス列の値が更新されると、TiCDC は`UPDATE`イベントを`DELETE`イベントと`INSERT`イベントに分割することに注意してください。 TiCDC はこれらのイベントを`UPDATE`イベントとして識別できないため、これらのイベントを正しくフィルタリングできません。 ##### ignore-sql {#code-ignore-sql-code} @@ -473,7 +473,7 @@ REDO ログを使用する場合の変更フィードのレプリケーション #### output-raw-change-event {#code-output-raw-change-event-code} -- 元のデータ変更イベントを出力するかどうかを制御します。詳細については、 [プライマリキーまたはユニークキーの`UPDATE`イベントを分割するかどうかを制御します](/ticdc/ticdc-split-update-behavior.md#control-whether-to-split-primary-or-unique-key-update-events)参照してください。 +- 元のデータ変更イベントを出力するかどうかを制御します。詳細については、 [主キーまたは一意キーの`UPDATE`イベントを分割するかどうかを制御します](/ticdc/ticdc-split-update-behavior.md#control-whether-to-split-primary-or-unique-key-update-events)参照してください。 - デフォルト値: `false` ### sink.kafka-config.glue-schema-registry-config {#sink-kafka-config-glue-schema-registry-config} @@ -585,7 +585,7 @@ token="xxxx" #### output-raw-change-event {#code-output-raw-change-event-code} -- 元のデータ変更イベントを出力するかどうかを制御します。詳細については、 [プライマリキーまたはユニークキーの`UPDATE`イベントを分割するかどうかを制御します](/ticdc/ticdc-split-update-behavior.md#control-whether-to-split-primary-or-unique-key-update-events)参照してください。 +- 元のデータ変更イベントを出力するかどうかを制御します。詳細については、 [主キーまたは一意キーの`UPDATE`イベントを分割するかどうかを制御します](/ticdc/ticdc-split-update-behavior.md#control-whether-to-split-primary-or-unique-key-update-events)参照してください。 - デフォルト値: `false` ### sink.cloud-storage-config {#sink-cloud-storage-config} @@ -624,5 +624,5 @@ token="xxxx" #### output-raw-change-event {#code-output-raw-change-event-code} -- 元のデータ変更イベントを出力するかどうかを制御します。詳細については、 [プライマリキーまたはユニークキーの`UPDATE`イベントを分割するかどうかを制御します](/ticdc/ticdc-split-update-behavior.md#control-whether-to-split-primary-or-unique-key-update-events)参照してください。 +- 元のデータ変更イベントを出力するかどうかを制御します。詳細については、 [主キーまたは一意キーの`UPDATE`イベントを分割するかどうかを制御します](/ticdc/ticdc-split-update-behavior.md#control-whether-to-split-primary-or-unique-key-update-events)参照してください。 - デフォルト値: `false` diff --git a/ticdc/ticdc-debezium.md b/ticdc/ticdc-debezium.md index f67f3ab1c83b8..8667b1d9de429 100644 --- a/ticdc/ticdc-debezium.md +++ b/ticdc/ticdc-debezium.md @@ -53,7 +53,7 @@ TiCDC は、キーと値の両方を Debezium 形式でエンコードして、D } ``` -キーのフィールドには、主キーまたは一意のインデックス列のみが含まれます。各フィールドの説明は以下のとおりです。 +キーのフィールドには、主キーまたは一意インデックス列のみが含まれます。各フィールドの説明は以下のとおりです。 | 分野 | タイプ | 説明 | | :---------------- | :------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------- | diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md index 705ae8cd87644..658fcb6f45be5 100644 --- a/ticdc/ticdc-open-api-v2.md +++ b/ticdc/ticdc-open-api-v2.md @@ -252,7 +252,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | `consistent` | REDOログの設定パラメータ。(オプション) | | `enable_sync_point` | `BOOLEAN`型。2 `sync point`有効にするかどうかを決定します。（オプション） | | `filter` | `filter`の設定パラメータ。(オプション) | -| `force_replicate` | `BOOLEAN`型。デフォルト値は`false`です`true`に設定すると、レプリケーションタスクは一意のインデックスを持たないテーブルを強制的にレプリケートします。（オプション） | +| `force_replicate` | `BOOLEAN`型。デフォルト値は`false`です`true`に設定すると、レプリケーションタスクは一意インデックスを持たないテーブルを強制的にレプリケートします。（オプション） | | `ignore_ineligible_table` | `BOOLEAN`型。デフォルト値は`false`です`true`に設定すると、レプリケーションタスクはレプリケートできないテーブルを無視します。（オプション） | | `memory_quota` | `UINT64`型。レプリケーションタスクのメモリクォータ。（オプション） | | `mounter` | `mounter`の設定パラメータ。(オプション) | diff --git a/ticdc/ticdc-open-api.md b/ticdc/ticdc-open-api.md index c32dfcc54951d..c778a08f937d0 100644 --- a/ticdc/ticdc-open-api.md +++ b/ticdc/ticdc-open-api.md @@ -111,13 +111,13 @@ curl -X GET http://127.0.0.1:8300/api/v1/health #### リクエスト本体のパラメータ {#parameters-for-the-request-body} -| パラメータ名 | 説明 | | :------------------------ | :---------------------- ------------------------------- | | `changefeed_id` | `STRING` type。レプリケーション タスクの ID。(オプション) | | `start_ts` | `UINT64` type。changefeed の開始 TSO を指定します。(オプション) | | `target_ts` | `UINT64` type。changefeed のターゲット TSO を指定します。(オプション) | | **`sink_uri`** | `STRING` type。レプリケーション タスクのダウンストリーム アドレス。(**必須**) | | `force_replicate` | `BOOLEAN` type。一意のインデックスのないテーブルを強制的にレプリケートするかどうかを決定します。(オプション) | | `ignore_ineligible_table` | `BOOLEAN` type。レプリケートできないテーブルを無視するかどうかを決定します。(オプション) | | `filter_rules` | `STRING` type 配列。テーブル スキーマのフィルタリングのルール。(オプション) | | `ignore_txn_start_ts` | `UINT64` type 配列。指定された start_ts のトランザクションを無視します。(オプション) | | `mounter_worker_num` | `INT` type。マウンタのスレッド番号。(オプション) | | `sink_config` | シンクの構成パラメータ。(オプション) | +| パラメータ名 | 説明 | | :------------------------ | :---------------------- ------------------------------- | | `changefeed_id` | `STRING` type。レプリケーション タスクの ID。(オプション) | | `start_ts` | `UINT64` type。changefeed の開始 TSO を指定します。(オプション) | | `target_ts` | `UINT64` type。changefeed のターゲット TSO を指定します。(オプション) | | **`sink_uri`** | `STRING` type。レプリケーション タスクのダウンストリーム アドレス。(**必須**) | | `force_replicate` | `BOOLEAN` type。一意インデックスのないテーブルを強制的にレプリケートするかどうかを決定します。(オプション) | | `ignore_ineligible_table` | `BOOLEAN` type。レプリケートできないテーブルを無視するかどうかを決定します。(オプション) | | `filter_rules` | `STRING` type 配列。テーブル スキーマのフィルタリングのルール。(オプション) | | `ignore_txn_start_ts` | `UINT64` type 配列。指定された start_ts のトランザクションを無視します。(オプション) | | `mounter_worker_num` | `INT` type。マウンタのスレッド番号。(オプション) | | `sink_config` | シンクの構成パラメータ。(オプション) | `changefeed_id` `target_ts`意味と形式は、 [`cdc cli`を使用してレプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)ドキュメントに記載されているものと同じです。 `sink_uri` `start_ts`パラメータの詳細については、こちらのドキュメントを参照してください`sink_uri`で証明書パスを指定する際は、対応する証明書が対応する TiCDCサーバーにアップロードされていることを確認してください。 上記の表のその他のパラメータについては、次のようにさらに詳しく説明します。 -`force_replicate` : このパラメータのデフォルトは`false`です。4 `true`指定すると、TiCDC は一意のインデックスを持たないテーブルを強制的に複製しようとします。 +`force_replicate` : このパラメータのデフォルトは`false`です。4 `true`指定すると、TiCDC は一意インデックスを持たないテーブルを強制的に複製しようとします。 `ignore_ineligible_table` : このパラメータのデフォルトは`false`です。4 `true`指定すると、TiCDC は複製できないテーブルを無視します。 diff --git a/ticdc/ticdc-open-protocol.md b/ticdc/ticdc-open-protocol.md index 426784d28a0a5..3fea9f779c467 100644 --- a/ticdc/ticdc-open-protocol.md +++ b/ticdc/ticdc-open-protocol.md @@ -250,7 +250,7 @@ UPDATE test.t1 SET id = 4, val = 'ee' WHERE id = 2; COMMIT; ``` -- ログ9は、 `Delete`タイプの行変更イベントです。このタイプのイベントには、主キー列または一意のインデックス列のみが含まれます。 +- ログ9は、 `Delete`タイプの行変更イベントです。このタイプのイベントには、主キー列または一意インデックス列のみが含まれます。 - ログ13とログ14は解決済みイベントです。解決済みイベントとは、このパーティションにおいて、解決済みTSよりも小さいイベント（行変更イベントとDDLイベントを含む）が送信されたことを意味します。 @@ -354,15 +354,15 @@ COMMIT; | 1 | 0x01 | バイナリフラグ | 列がバイナリエンコードされた列であるかどうか。 | | 2 | 0x02 | ハンドルキーフラグ | 列がハンドル インデックス列であるかどうか。 | | 3 | 0x04 | 生成された列フラグ | 列が生成された列であるかどうか。 | -| 4 | 0x08 | プライマリキーフラグ | 列が主キー列であるかどうか。 | -| 5 | 0x10 | ユニークキーフラグ | 列が一意のインデックス列であるかどうか。 | +| 4 | 0x08 | 主キーフラグ | 列が主キー列であるかどうか。 | +| 5 | 0x10 | 一意キーフラグ | 列が一意インデックス列であるかどうか。 | | 6 | 0x20 | 複数キーフラグ | 列が複合インデックス列であるかどうか。 | | 7 | 0x40 | NullableFlag | 列が NULL 可能列であるかどうか。 | | 8 | 0x80 | 符号なしフラグ | 列が符号なし列であるかどうか。 | 例： -列フラグの値が`85`の場合、その列は NULL 可能列、一意のインデックス列、生成された列、およびバイナリ エンコード列になります。 +列フラグの値が`85`の場合、その列は NULL 可能列、一意インデックス列、生成された列、およびバイナリ エンコード列になります。 85 == 0b_101_0101 == NullableFlag | UniqueKeyFlag | GeneratedColumnFlag | BinaryFlag diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index a551af71976ea..318bd3e3f844a 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -80,8 +80,8 @@ TiCDCのアーキテクチャを次の図に示す。 一般的に、TiCDC は有効なインデックスを少なくとも 1 つ持つテーブルのみをダウンストリームにレプリケートします。テーブル内のインデックスが以下のいずれかの要件を満たしている場合、そのインデックスは有効です。 -- プライマリキー（ `PRIMARY KEY` ）は有効なインデックスです。 -- 一意のインデックス ( `UNIQUE INDEX` ) は、インデックスのすべての列が明示的に非 null 許容 ( `NOT NULL` ) として定義され、インデックスに仮想生成列 ( `VIRTUAL GENERATED COLUMNS` ) がない場合に有効です。 +- 主キー（ `PRIMARY KEY` ）は有効なインデックスです。 +- 一意インデックス ( `UNIQUE INDEX` ) は、インデックスのすべての列が明示的に非 null 許容 ( `NOT NULL` ) として定義され、インデックスに仮想生成列 ( `VIRTUAL GENERATED COLUMNS` ) がない場合に有効です。 > **注記：** > diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index 64bb6ffa4df74..c125fbc8ab208 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -280,7 +280,7 @@ Topic 式の形式は`[prefix]{schema}[middle][{table}][suffix]`です。 `partition = "xxx"` `index-value`ディスパッチャ`columns`指定するために使用できます。3、5、7、9、11 `default` 5つ`ts`ディスパッチャをサポートします。ディスパッチャのルールは以下のとおり`table` 。 - `default` : デフォルトで`table`ディスパッチャルールを使用します。スキーマ名とテーブル名に基づいてパーティション番号を計算し、テーブルからのデータが必ず同じパーティションに送信されるようにします。その結果、1つのテーブルからのデータは1つのパーティションにのみ存在し、順序付けが保証されます。ただし、このディスパッチャルールは送信スループットを制限し、コンシューマーを追加しても消費速度を向上させることはできません。 -- `index-value` : 主キー、一意のインデックス、または`index`で明示的に指定されたインデックスのいずれかを使用してパーティション番号を計算し、テーブルデータを複数のパーティションに分散します。単一のテーブルのデータは複数のパーティションに送信され、各パーティションのデータは順序付けされます。コンシューマーを追加することで、消費速度を向上させることができます。このディスパッチャは、同じ行への更新が同じパーティションに送信されるようにすることで、その行の順序付けされた処理を保証します。 +- `index-value` : 主キー、一意インデックス、または`index`で明示的に指定されたインデックスのいずれかを使用してパーティション番号を計算し、テーブルデータを複数のパーティションに分散します。単一のテーブルのデータは複数のパーティションに送信され、各パーティションのデータは順序付けされます。コンシューマーを追加することで、消費速度を向上させることができます。このディスパッチャは、同じ行への更新が同じパーティションに送信されるようにすることで、その行の順序付けされた処理を保証します。 - `columns` : 明示的に指定された列の値を使用してパーティション番号を計算し、テーブルデータを複数のパーティションに分散します。単一のテーブルのデータは複数のパーティションに送信され、各パーティションのデータは順序付けされます。コンシューマーを追加することで、消費速度を向上させることができます。このディスパッチャは、同じ行への更新が同じパーティションに送信されるようにすることで、その行の順序付けされた処理を保証します。 - `table` : スキーマ名とテーブル名を使用してパーティション番号を計算します。 - `ts` : 行変更のコミットタイムを用いてパーティション番号を計算し、テーブルデータを複数のパーティションに分散します。単一テーブルのデータは複数のパーティションに送信され、各パーティションのデータは順序付けされます。コンシューマーを追加することで、消費速度を向上させることができます。ただし、データ項目の複数の変更が異なるパーティションに送信され、各コンシューマーのコンシューマー処理の進行状況が異なる場合があり、データの不整合が発生する可能性があります。そのため、コンシューマーは複数のパーティションからのデータを消費する前に、コミットタイムでソートする必要があります。 @@ -297,8 +297,8 @@ dispatchers = [ ] ``` -- `test`データベース内のテーブルは`index-value`ディスパッチャを使用し、主キーまたは一意のインデックスの値を使用してパーティション番号を計算します。主キーが存在する場合は主キーが使用され、存在しない場合は最短の一意のインデックスが使用されます。 -- `test1`テーブル内のテーブルは`index-value`ディスパッチャを使用し、 `index1`という名前のインデックスに含まれるすべての列の値を使用してパーティション番号を計算します。指定されたインデックスが存在しない場合はエラーが報告されます`index`で指定されたインデックスは一意のインデックスである必要があります。 +- `test`データベース内のテーブルは`index-value`ディスパッチャを使用し、主キーまたは一意インデックスの値を使用してパーティション番号を計算します。主キーが存在する場合は主キーが使用され、存在しない場合は最短の一意インデックスが使用されます。 +- `test1`テーブル内のテーブルは`index-value`ディスパッチャを使用し、 `index1`という名前のインデックスに含まれるすべての列の値を使用してパーティション番号を計算します。指定されたインデックスが存在しない場合はエラーが報告されます`index`で指定されたインデックスは一意インデックスである必要があります。 - `test2`データベース内のテーブルは`columns`ディスパッチャを使用し、列`id`と`a`の値を使用してパーティション番号を計算します。いずれかの列が存在しない場合は、エラーが報告されます。 - `test3`データベース内のテーブルは`table`ディスパッチャーを使用します。 - `test4`データベース内のテーブルは、前述のルールのいずれにも一致しないため、 `default`ディスパッチャ、つまり`table`ディスパッチャを使用します。 @@ -375,7 +375,7 @@ region-threshold = 10000 write-key-threshold = 30000 ``` -次の SQL ステートメントを使用して、テーブルに含まれる地域の数を照会できます。 +次の SQL ステートメントを使用して、テーブルに含まれるリージョンの数を照会できます。 ```sql SELECT COUNT(*) FROM INFORMATION_SCHEMA.TIKV_REGION_STATUS WHERE DB_NAME="database1" AND TABLE_NAME="table1" AND IS_INDEX=0; diff --git a/ticdc/ticdc-sink-to-pulsar.md b/ticdc/ticdc-sink-to-pulsar.md index d38e626f5dde1..fc04b6a393198 100644 --- a/ticdc/ticdc-sink-to-pulsar.md +++ b/ticdc/ticdc-sink-to-pulsar.md @@ -327,6 +327,6 @@ dispatchers = [ - `default` : デフォルトでは、イベントはスキーマ名とテーブル名によってディスパッチされます。これは`table`指定した場合と同じです。 - `ts` : 行変更の commitT を使用してハッシュ計算を実行し、イベントをディスパッチします。 -- `index-value` : テーブルの主キーまたは一意のインデックスの値を使用してハッシュ計算を実行し、イベントをディスパッチします。 +- `index-value` : テーブルの主キーまたは一意インデックスの値を使用してハッシュ計算を実行し、イベントをディスパッチします。 - `table` : スキーマ名とテーブル名を使用してハッシュ計算を実行し、イベントをディスパッチします。 - その他の自己定義文字列: 自己定義文字列は Pulsar メッセージのキーとして直接使用され、Pulsar プロデューサーはこのキー値をディスパッチに使用します。 diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index 5b56d642dec73..df2027c5e7b3e 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -76,9 +76,9 @@ UPDATE t SET a = 3 WHERE a = 2; ### 単一のUPDATE変更を含むトランザクション {#transactions-containing-a-single-code-update-code-change} -v6.5.3、v7.1.1、v7.2.0以降、MySQL以外のシンクを使用する場合、単一の更新変更のみを含むトランザクションにおいて、主キーまたはnull以外の一意のインデックス値が`UPDATE`イベントで変更されると、TiCDCはこのイベントを`DELETE`つと`INSERT`イベントに分割します。詳細については、GitHubのissue [＃9086](https://github.com/pingcap/tiflow/issues/9086)ご覧ください。 +v6.5.3、v7.1.1、v7.2.0以降、MySQL以外のシンクを使用する場合、単一の更新変更のみを含むトランザクションにおいて、主キーまたはnull以外の一意インデックス値が`UPDATE`イベントで変更されると、TiCDCはこのイベントを`DELETE`つと`INSERT`イベントに分割します。詳細については、GitHubのissue [＃9086](https://github.com/pingcap/tiflow/issues/9086)ご覧ください。 -この変更は主に、CSVおよびAVROプロトコル使用時にTiCDCがデフォルトで新しい値のみを出力し、古い値は出力しないという問題に対処します。この問題により、主キーまたは非NULLの一意のインデックス値が変更された場合、コンシューマーは新しい値しか受信できず、変更前の値を処理する（例えば、古い値を削除する）ことができなくなります。次のSQLを例に挙げましょう。 +この変更は主に、CSVおよびAVROプロトコル使用時にTiCDCがデフォルトで新しい値のみを出力し、古い値は出力しないという問題に対処します。この問題により、主キーまたは非NULLの一意インデックス値が変更された場合、コンシューマーは新しい値しか受信できず、変更前の値を処理する（例えば、古い値を削除する）ことができなくなります。次のSQLを例に挙げましょう。 ```sql CREATE TABLE t (a INT PRIMARY KEY, b INT); @@ -90,7 +90,7 @@ UPDATE t SET a = 2 WHERE a = 1; ### 複数のUPDATE変更を含むトランザクション {#transactions-containing-multiple-code-update-code-changes} -v6.5.4、v7.1.2、v7.4.0以降、複数の変更を含むトランザクションにおいて、 `UPDATE`イベントで主キーまたはNULL以外の一意のインデックス値が変更された場合、TiCDCはイベントを`DELETE`と`INSERT`イベントに分割し、すべてのイベントが`INSERT`のイベントの前の`DELETE`のイベントのシーケンスに従うようにします。詳細については、GitHubのissue [＃9430](https://github.com/pingcap/tiflow/issues/9430)ご覧ください。 +v6.5.4、v7.1.2、v7.4.0以降、複数の変更を含むトランザクションにおいて、 `UPDATE`イベントで主キーまたはNULL以外の一意インデックス値が変更された場合、TiCDCはイベントを`DELETE`と`INSERT`イベントに分割し、すべてのイベントが`INSERT`のイベントの前の`DELETE`のイベントのシーケンスに従うようにします。詳細については、GitHubのissue [＃9430](https://github.com/pingcap/tiflow/issues/9430)ご覧ください。 この変更は主に、Kafkaシンクまたはその他のシンクからリレーショナルデータベースへのデータ変更の書き込み時、あるいは同様の操作を実行する際にコンシューマーが遭遇する可能性のある、主キーまたは一意キーの競合に関する潜在的な問題に対処します。この問題は、TiCDCが受信した`UPDATE`イベントの順序が誤っている可能性があることに起因します。 @@ -116,7 +116,7 @@ COMMIT; v6.5.10、v7.1.6、v7.5.3、v8.1.1以降、MySQL以外のシンクを使用する場合、TiCDCはGitHub Issue [＃11211](https://github.com/pingcap/tiflow/issues/11211)に記載されているように、 `output-raw-change-event`パラメータを介して主キーまたは一意キーの`UPDATE`イベントを分割するかどうかを制御できるようになりました。このパラメータの具体的な動作は次のとおりです。 -- `output-raw-change-event = false`設定すると、主キーまたは null 以外の一意のインデックス値が`UPDATE`イベントで変更された場合、TiCDC はイベントを`DELETE`と`INSERT`イベントに分割し、すべてのイベントが`INSERT`イベントの前の`DELETE`イベントのシーケンスに従うようにします。 +- `output-raw-change-event = false`設定すると、主キーまたは null 以外の一意インデックス値が`UPDATE`イベントで変更された場合、TiCDC はイベントを`DELETE`と`INSERT`イベントに分割し、すべてのイベントが`INSERT`イベントの前の`DELETE`イベントのシーケンスに従うようにします。 - `output-raw-change-event = true`設定すると、TiCDCは`UPDATE`イベントを分割せず、 [MySQL以外のシンクの主キーまたは一意キーの`UPDATE`イベントを分割する](/ticdc/ticdc-split-update-behavior.md#split-primary-or-unique-key-update-events-for-non-mysql-sinks)で説明した問題への対処はコンシューマー側で行います。そうしないと、データの不整合が発生するリスクがあります。テーブルの主キーがクラスター化インデックスである場合、主キーへの更新はTiDB内で依然として`DELETE`つと`INSERT`イベントに分割されますが、この動作は`output-raw-change-event`パラメータの影響を受けません。 > **注記** diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index 5e07e75d5ccaf..6598a170b48b5 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -136,9 +136,9 @@ TiDBノードを複数デプロイすることで、水平方向に拡張し、 **主な特徴：** -- **地域ベースのデータストレージ** +- **リージョンベースのデータストレージ** - - データは[地域](https://docs.pingcap.com/tidb/dev/glossary#regionpeerraft-group)ごとに分割され、それぞれが特定のキー範囲（左端が閉じ、右端が開いた区間： `StartKey`から`EndKey` ）をカバーします。 + - データは[リージョン](https://docs.pingcap.com/tidb/dev/glossary#regionpeerraft-group)ごとに分割され、それぞれが特定のキー範囲（左端が閉じ、右端が開いた区間： `StartKey`から`EndKey` ）をカバーします。 - 効率的なデータ配信を確保するため、各TiKVノード内には複数のリージョンが共存している。 - **トランザクションサポート** diff --git a/tidb-cloud/built-in-monitoring.md b/tidb-cloud/built-in-monitoring.md index a17c852d26141..23b2708466883 100644 --- a/tidb-cloud/built-in-monitoring.md +++ b/tidb-cloud/built-in-monitoring.md @@ -57,7 +57,7 @@ TiDB Cloudでは、メトリクスデータは7日間保持されます。 | TiKV gRPCの平均持続時間 | {リクエストタイプ} | `kv_get` 、 `kv_prewrite` `kv_commit`でgRPCリクエストを実行するのに要した平均時間。 | | 平均 / P99 PD TSO 待ち時間/RPC 所要時間 | 待機時間平均/99、RPC平均/99 | 待機時間：すべてのTiDBノードにおいてPDがTSOを返すまでの待機時間の平均値、または99パーセンタイル値。
RPC: PDにTSOリクエストを送信してから、すべてのTiDBノードでTSOを受信するまでの平均時間、または99パーセンタイル値。 | | 平均 / P99 ストレージ非同期書き込み時間 | 平均、99 | 非同期書き込みで消費される平均時間、または99パーセンタイル値。平均storage非同期書き込み時間 = 平均ストレージ時間 + 平均適用時間。 | -| 平均 / P99 店舗での保管期間 | 平均、99 | 非同期書き込み時のストレージループで消費される平均時間、または99パーセンタイル値。 | +| 平均 / P99 ストア所要時間 | 平均、99 | 非同期書き込み時のストレージループで消費される平均時間、または99パーセンタイル値。 | | 平均 / P99 適用期間 | 平均、99 | 非同期書き込み中にループを適用する際に要する平均時間、または99パーセンタイル値。 | | 平均 / P99 追記ログの所要時間 | 平均、99 | Raftがログを追加する際に要する平均時間、または99パーセンタイル値。 | | 平均 / P99 コミットログ期間 | 平均、99 | Raftがログをコミットするのに要する平均時間、または99パーセンタイル値。 | diff --git a/tidb-cloud/changefeed-sink-to-apache-kafka.md b/tidb-cloud/changefeed-sink-to-apache-kafka.md index ebb5a34c3fbd1..f65677c84b8a8 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -33,7 +33,7 @@ summary: このドキュメントでは、TiDB Cloudから Apache Kafka へデ - データ形式としてDebeziumを使用する場合は、 TiDB Cloud Dedicatedクラスターのバージョンがv8.1.0以降であることを確認してください。 - Kafkaメッセージのパーティション分散については、以下の点に注意してください。 - - 変更ログをプライマリキーまたはインデックス値に基づいて、指定したインデックス名を持つ Kafka パーティションに分散する場合は、 TiDB Cloud Dedicatedクラスターのバージョンが v7.5.0 以降であることを確認してください。 + - 変更ログを主キーまたはインデックス値に基づいて、指定したインデックス名を持つ Kafka パーティションに分散する場合は、 TiDB Cloud Dedicatedクラスターのバージョンが v7.5.0 以降であることを確認してください。 - 変更ログを列値ごとにKafkaパーティションに分散する場合は、 TiDB Cloud Dedicatedクラスタのバージョンがv7.5.0以降であることを確認してください。 @@ -312,7 +312,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン 8. **パーティション分散**領域では、Kafka メッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB Cloud、次の 4 種類のディスパッチャが提供されています。 - - **プライマリキーまたはインデックス値に基づいて変更ログをKafkaパーティションに分散します。** + - **主キーまたはインデックス値に基づいて変更ログをKafkaパーティションに分散します。** 変更フィードを使用してテーブルの Kafka メッセージを異なるパーティションに送信する場合は、この分散方法を選択してください。行の変更ログの主キーまたはインデックス値によって、変更ログが送信されるパーティションが決まります。この分散方法は、パーティションのバランスを改善し、行レベルの順序性を確保します。 diff --git a/tidb-cloud/database-schema-concepts.md b/tidb-cloud/database-schema-concepts.md index 26b1cb5da39bc..4adf946170bd3 100644 --- a/tidb-cloud/database-schema-concepts.md +++ b/tidb-cloud/database-schema-concepts.md @@ -83,13 +83,13 @@ TiDB は`SPATIAL`タイプを除く、MySQL のすべてのデータタイプを - セカンダリインデックス：主キー以外の列のインデックス -### 一意のインデックス {#unique-indexes} +### 一意インデックス {#unique-indexes} -TiDBのユニークインデックスは、1つ以上の列に一意性を強制し、テーブル内の2つの行がインデックス対象の列に同じ値を持つことができないようにします。この制約により、重複値を防止することでデータの整合性を維持できるため、ユニークインデックスは、メールアドレス、ユーザー名、製品コードなど、本来一意であるべきフィールドに最適です。 +TiDBの一意インデックスは、1つ以上の列に一意性を強制し、テーブル内の2つの行がインデックス対象の列に同じ値を持つことができないようにします。この制約により、重複値を防止することでデータの整合性を維持できるため、一意インデックスは、メールアドレス、ユーザー名、製品コードなど、本来一意であるべきフィールドに最適です。 -### プライマリキーインデックス {#primary-key-index} +### 主キーインデックス {#primary-key-index} -主キーインデックスとは、テーブル内の1つ以上の列に設定される一意のインデックスであり、各行の主要な識別子として機能します。TiDBでは、すべてのテーブルに主キーが必要であり、主キーはユーザーが明示的に定義することも、指定されていない場合はTiDBが暗黙的に定義することもできます。 +主キーインデックスとは、テーブル内の1つ以上の列に設定される一意インデックスであり、各行の主要な識別子として機能します。TiDBでは、すべてのテーブルに主キーが必要であり、主キーはユーザーが明示的に定義することも、指定されていない場合はTiDBが暗黙的に定義することもできます。 ### 複合指数 {#composite-index} @@ -103,7 +103,7 @@ TiDB v8.0.0以降では、 [`tidb_opt_use_invisible_indexes`](/system-variables. ### クラスター化インデックス {#clustered-indexes} -クラスタ化インデックスにおいて、「クラスタ化」という用語は、データの格納方法の構成を指し、連携して動作するデータベースサーバーのグループを指すものではありません。一部のデータベース管理システムでは、クラスタ化インデックスをインデックス構成テーブル（IOT）と呼んでいます。 +クラスター化インデックスにおいて、「クラスター化」という用語は、データの格納方法の構成を指し、連携して動作するデータベースサーバーのグループを指すものではありません。一部のデータベース管理システムでは、クラスター化インデックスをインデックス構成テーブル（IOT）と呼んでいます。 この機能は、主キーを含むテーブルへのデータの格納方法を制御します。これにより、TiDBは特定のクエリのパフォーマンスを向上させるような方法でテーブルを整理できるようになります。 diff --git a/tidb-cloud/essential-changefeed-sink-to-kafka.md b/tidb-cloud/essential-changefeed-sink-to-kafka.md index 09f4593e88ba6..030de2695773e 100644 --- a/tidb-cloud/essential-changefeed-sink-to-kafka.md +++ b/tidb-cloud/essential-changefeed-sink-to-kafka.md @@ -188,7 +188,7 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト 8. **パーティション分散**領域では、Kafkaメッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB Cloudは、次の4種類のディスパッチャを提供しています。 - - **プライマリキーまたはインデックス値に基づいて変更ログをKafkaパーティションに分散します。** + - **主キーまたはインデックス値に基づいて変更ログをKafkaパーティションに分散します。** 変更フィードでテーブルのKafkaメッセージを異なるパーティションに送信する場合は、この分散方法を選択してください。行の変更ログの主キーまたはインデックス値によって、変更ログの送信先パーティションが決まります。主キーを使用する場合は、 **「インデックス名」**フィールドを空のままにしてください。この分散方法は、パーティションのバランスを改善し、行レベルの順序性を確保します。 diff --git a/tidb-cloud/migrate-from-mysql-using-aws-dms.md b/tidb-cloud/migrate-from-mysql-using-aws-dms.md index 4917bdaff0208..939333bb395d4 100644 --- a/tidb-cloud/migrate-from-mysql-using-aws-dms.md +++ b/tidb-cloud/migrate-from-mysql-using-aws-dms.md @@ -29,7 +29,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ ## 制限 {#limitation} - AWS DMS は`DROP TABLE`のレプリケーションをサポートしていません。 -- AWS DMS は、テーブルやプライマリキーの作成など、基本的なスキーマ移行をサポートしています。ただし、AWS DMS はTiDB Cloudにセカンダリインデックス、外部キー、ユーザーアカウントを自動的に作成しません。必要に応じて、セカンダリインデックスを持つテーブルを含め、これらのオブジェクトを TiDB に手動で作成する必要があります。詳細については、 [AWS Database Migration Service の移行計画](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_BestPractices.html#CHAP_SettingUp.MigrationPlanning)参照してください。 +- AWS DMS は、テーブルや主キーの作成など、基本的なスキーマ移行をサポートしています。ただし、AWS DMS はTiDB Cloudにセカンダリインデックス、外部キー、ユーザーアカウントを自動的に作成しません。必要に応じて、セカンダリインデックスを持つテーブルを含め、これらのオブジェクトを TiDB に手動で作成する必要があります。詳細については、 [AWS Database Migration Service の移行計画](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_BestPractices.html#CHAP_SettingUp.MigrationPlanning)参照してください。 ## ステップ1. AWS DMSレプリケーションインスタンスを作成する {#step-1-create-an-aws-dms-replication-instance} diff --git a/tidb-cloud/sql-concepts.md b/tidb-cloud/sql-concepts.md index 0dbb5ffbc40cf..86586557f1155 100644 --- a/tidb-cloud/sql-concepts.md +++ b/tidb-cloud/sql-concepts.md @@ -63,7 +63,7 @@ TiDBは、行IDの生成とデータ配信を最適化するための3つのSQL ### SHARD_ROW_ID_BITS {#shard-row-id-bits} -クラスタ化されていないプライマリキーまたはプライマリキーのないテーブルの場合、TiDB は暗黙的な自動インクリメント行 ID を使用します。 `INSERT`操作が多数実行されると、データが単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 +クラスター化されていない主キーまたは主キーのないテーブルの場合、TiDB は暗黙的な自動インクリメント行 ID を使用します。 `INSERT`操作が多数実行されると、データが単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 ホットスポットの問題を軽減するには、 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)を設定できます。行 ID は分散しており、データは複数の異なるリージョンに書き込まれます。 diff --git a/tidb-cloud/tidb-cloud-poc.md b/tidb-cloud/tidb-cloud-poc.md index a5cf1e8a0ba64..8d078ee638276 100644 --- a/tidb-cloud/tidb-cloud-poc.md +++ b/tidb-cloud/tidb-cloud-poc.md @@ -113,7 +113,7 @@ TiDB CloudはMySQL 8.0との互換性が非常に高くなっています。MySQ - 不要なインデックスを削除します。 - 効果的なパーティショニングのためにパーティショニング ポリシーを計画します。 - タイムスタンプ上のインデックスなど、右側のインデックスの増加によって発生する[ホットスポットの問題](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#identify-hotspot-issues)回避します。 -- [シャード行IDビット](https://docs.pingcap.com/tidb/stable/shard-row-id-bits)と[自動ランダム](https://docs.pingcap.com/tidb/stable/auto-random)を使って[ホットスポットの問題](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#identify-hotspot-issues)回避します。 +- [SHARD_ROW_ID_BITS](https://docs.pingcap.com/tidb/stable/shard-row-id-bits)と[AUTO_RANDOM](https://docs.pingcap.com/tidb/stable/auto-random)を使って[ホットスポットの問題](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#identify-hotspot-issues)回避します。 SQL ステートメントの場合、データ ソースと TiDB の互換性のレベルに応じて調整する必要がある場合があります。 diff --git a/tidb-cloud/v8.5-performance-highlights.md b/tidb-cloud/v8.5-performance-highlights.md index a3129fa8a35d1..6ac47e8d77ae9 100644 --- a/tidb-cloud/v8.5-performance-highlights.md +++ b/tidb-cloud/v8.5-performance-highlights.md @@ -116,7 +116,7 @@ TiDB v8.5.0 では、クラウド ディスク IO ジッターによるパフォ ### テスト環境 {#test-environment} - クラスタトポロジ: TiDB (16 vCPU、32 GiB) * 1 + TiKV (16 vCPU、32 GiB) * 3 -- データセット: 1,000万行（約10GiBのデータ）のYCSB非クラスタ化テーブル。ホットスポットパターンの影響を分離・評価するため、特定のテストでは主キーを部分的に削除しています。 +- データセット: 1,000万行（約10GiBのデータ）のYCSB非クラスター化テーブル。ホットスポットパターンの影響を分離・評価するため、特定のテストでは主キーを部分的に削除しています。 - ワークロード: `INSERT` `UPDATE`含む`DELETE`操作。 ### テスト結果 {#test-results} @@ -153,7 +153,7 @@ TiDB v8.5.0 では、クラウド ディスク IO ジッターによるパフォ ### テスト環境 {#test-environment} -#### 小さな地域の統合 {#merging-small-regions} +#### 小さなリージョンの統合 {#merging-small-regions} - クラスタトポロジ: TiDB (16 vCPU、32 GiB) * 1 + TiKV (16 vCPU、32 GiB) * 3 - データセット: 約 100 万個の小さなテーブル (各テーブルのサイズは 2 MiB 未満) diff --git a/tidb-computing.md b/tidb-computing.md index aba3581d51247..7e07dd5d674d5 100644 --- a/tidb-computing.md +++ b/tidb-computing.md @@ -34,9 +34,9 @@ TiKVが提供する分散ストレージをベースに、TiDBは優れたトラ ### インデックスデータのキー値へのマッピング {#mapping-of-indexed-data-to-key-value} -TiDBは主キーとセカンダリインデックス（一意のインデックスと一意でないインデックスの両方）をサポートしています。テーブルデータのマッピングスキームと同様に、TiDBはテーブルの各インデックスにインデックスID（ `IndexID` ）を割り当てます。 +TiDBは主キーとセカンダリインデックス（一意インデックスと一意でないインデックスの両方）をサポートしています。テーブルデータのマッピングスキームと同様に、TiDBはテーブルの各インデックスにインデックスID（ `IndexID` ）を割り当てます。 -主キーと一意のインデックスの場合、キーと値のペアに基づいて対応する`RowID`すばやく見つける必要があるため、このようなキーと値のペアは次のようにエンコードされます。 +主キーと一意インデックスの場合、キーと値のペアに基づいて対応する`RowID`すばやく見つける必要があるため、このようなキーと値のペアは次のようにエンコードされます。 Key: tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue Value: RowID diff --git a/tidb-lightning/data-import-best-practices.md b/tidb-lightning/data-import-best-practices.md index 7efe76e586224..b4f1f4d47db2b 100644 --- a/tidb-lightning/data-import-best-practices.md +++ b/tidb-lightning/data-import-best-practices.md @@ -34,7 +34,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni - ソースファイル - 単一ファイル内のデータが主キーでソートされているかどうか。ソートされたデータは、最適なインポートパフォーマンスを実現します。 - - 複数のTiDB Lightningインスタンスによってインポートされたソースファイル間に、重複する主キーまたは非NULLの一意のインデックスが存在するかどうか。重複が少ないほど、インポートのパフォーマンスは向上します。 + - 複数のTiDB Lightningインスタンスによってインポートされたソースファイル間に、重複する主キーまたは非NULLの一意インデックスが存在するかどうか。重複が少ないほど、インポートのパフォーマンスは向上します。 - 表の定義 @@ -75,7 +75,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni ## ソースファイルの準備 {#prepare-source-files} - ソースファイルを生成する際は、単一ファイル内で主キーでソートすることをお勧めします。テーブル定義に主キーがない場合は、自動増分主キーを追加できます。この場合、ファイルの内容の順序は関係ありません。 -- ソースファイルを複数のTiDB Lightningインスタンスに割り当てる際は、複数のソースファイル間で重複する主キーやnull以外の一意のインデックスが存在する状況を避けるようにしてください。生成されたファイルがグローバルにソートされている場合は、範囲に基づいて異なるTiDB Lightningインスタンスに分散することで、最適なインポートパフォーマンスを実現できます。 +- ソースファイルを複数のTiDB Lightningインスタンスに割り当てる際は、複数のソースファイル間で重複する主キーやnull以外の一意インデックスが存在する状況を避けるようにしてください。生成されたファイルがグローバルにソートされている場合は、範囲に基づいて異なるTiDB Lightningインスタンスに分散することで、最適なインポートパフォーマンスを実現できます。 - ファイル生成中に各ファイルのサイズが 96 MiB 未満になるように制御します。 - ファイルが非常に大きく、256 MiB を超える場合は、 [`strict-format`](/migrate-from-csv-files-to-tidb.md#step-4-tune-the-import-performance-optional)有効にします。 diff --git a/tidb-lightning/monitor-tidb-lightning.md b/tidb-lightning/monitor-tidb-lightning.md index a7800343ac4cf..058d5c0e97aff 100644 --- a/tidb-lightning/monitor-tidb-lightning.md +++ b/tidb-lightning/monitor-tidb-lightning.md @@ -73,11 +73,11 @@ scrape_configs: | パネル | シリーズ | 説明 | | :----------- | :--------- | :---------------------------------------------------------------------------------------------------------------------------------------------------- | -| 怠惰な労働者 | io | 未使用の数は`io-concurrency` 、通常は設定された値（デフォルトは5）に近いですが、0に近い場合はディスクが遅すぎることを意味します。 | -| 怠惰な労働者 | 密閉型エンジン | 閉じられているがまだクリーンアップされていないエンジンの数。通常はインデックス + テーブル同時実行性（デフォルトは 8）に近い。0 に近い場合は、 TiDB Lightning がTiKV Importer よりも高速であることを意味し、 TiDB Lightning が停止する原因になります。 | -| 怠惰な労働者 | テーブル | 未使用の数は`table-concurrency` 、通常はプロセス終了まで 0 | -| 怠惰な労働者 | 索引 | 未使用の数は`index-concurrency` 、通常はプロセス終了まで 0 | -| Idle workers | 地域 | 未使用の数は`region-concurrency` 、通常はプロセス終了まで 0 | +| アイドルワーカー | io | 未使用の数は`io-concurrency` 、通常は設定された値（デフォルトは5）に近いですが、0に近い場合はディスクが遅すぎることを意味します。 | +| アイドルワーカー | クローズ済みエンジン | 閉じられているがまだクリーンアップされていないエンジンの数。通常はインデックス + テーブル同時実行性（デフォルトは 8）に近い。0 に近い場合は、 TiDB Lightning がTiKV Importer よりも高速であることを意味し、 TiDB Lightning が停止する原因になります。 | +| アイドルワーカー | テーブル | 未使用の数は`table-concurrency` 、通常はプロセス終了まで 0 | +| アイドルワーカー | 索引 | 未使用の数は`index-concurrency` 、通常はプロセス終了まで 0 | +| アイドルワーカー | リージョン | 未使用の数は`region-concurrency` 、通常はプロセス終了まで 0 | | 外部リソース | KVエンコーダ | アクティブなKVエンコーダをカウントします。通常はプロセス終了まで`region-concurrency`と同じです。 | | 外部リソース | インポーターエンジン | 開かれたエンジンファイルの数をカウントします`max-open-engines`設定を超えないようにしてください。 | diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index 64401518edfe5..bf0bfc278dcc1 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -28,12 +28,12 @@ TiDB Lightning を使用すると、次のシナリオでデータを並列に ただし、データを並行して移行する場合は、次の点を考慮する必要があります。 -- 複数のシャードテーブル間の主キーまたは一意のインデックス間の競合を処理する +- 複数のシャードテーブル間の主キーまたは一意インデックス間の競合を処理する - インポートパフォーマンスの最適化 -### 主キーまたは一意のインデックス間の競合を処理する {#handle-conflicts-between-primary-keys-or-unique-indexes} +### 主キーまたは一意インデックス間の競合を処理する {#handle-conflicts-between-primary-keys-or-unique-indexes} -[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)使用してデータを並列インポートする場合は、データソース間およびターゲット TiDB クラスター内のテーブル間で主キーまたは一意のインデックスの競合がないこと、またインポート中にターゲットテーブルにデータの書き込みが行われないことを確認してください。そうでない場合、 TiDB Lightning はインポートされたデータの正確性を保証できず、インポート完了後にターゲットテーブルに不整合なインデックスが含まれることになります。 +[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)使用してデータを並列インポートする場合は、データソース間およびターゲット TiDB クラスター内のテーブル間で主キーまたは一意インデックスの競合がないこと、またインポート中にターゲットテーブルにデータの書き込みが行われないことを確認してください。そうでない場合、 TiDB Lightning はインポートされたデータの正確性を保証できず、インポート完了後にターゲットテーブルに不整合なインデックスが含まれることになります。 ### インポートパフォーマンスの最適化 {#optimize-import-performance} diff --git a/tidb-lightning/tidb-lightning-glossary.md b/tidb-lightning/tidb-lightning-glossary.md index ab6daa0205c35..345ed4437b3ef 100644 --- a/tidb-lightning/tidb-lightning-glossary.md +++ b/tidb-lightning/tidb-lightning-glossary.md @@ -187,7 +187,7 @@ KV ペアを TiKV Importer に送信する前に、 TiDB Lightning自体によ ### 分割 {#splitting} -通常、エンジンは非常に大きい (約 100 GB) ため、単一の[地域](/glossary.md#regionpeerraft-group)として扱うのは TiKV にとって扱いにくいものです。TiKV インポーターは、アップロードする前にエンジンを複数の小さな[SST ファイル](/tidb-lightning/tidb-lightning-glossary.md#sst-file) (TiKV インポーターの`import.region-split-size`設定で構成可能) に分割します。 +通常、エンジンは非常に大きい (約 100 GB) ため、単一の[リージョン](/glossary.md#regionpeerraft-group)として扱うのは TiKV にとって扱いにくいものです。TiKV インポーターは、アップロードする前にエンジンを複数の小さな[SST ファイル](/tidb-lightning/tidb-lightning-glossary.md#sst-file) (TiKV インポーターの`import.region-split-size`設定で構成可能) に分割します。 ### SSTファイル {#sst-file} diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index ac21189794192..3030eada7973b 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -120,7 +120,7 @@ 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`以上の値に調整することで、最適なパフォーマンスを維持できます。 | -| [`rocksdb.titan`](/tikv-configuration-file.md#rocksdbtitan) [`rocksdb.defaultcf.titan`](/tikv-configuration-file.md#rocksdbdefaultcftitan) [`min-blob-size`](/tikv-configuration-file.md#min-blob-size) [`blob-file-compression`](/tikv-configuration-file.md#blob-file-compression) | Titanストレージエンジンを有効にすることで、書き込み増幅を低減し、ディスクI/Oのボトルネックを緩和できます。特に、RocksDBの圧縮処理が書き込みワークロードに追いつかず、圧縮待ちバイトが蓄積される場合に有効です。 | 書き込み増幅が主なボトルネックである場合に有効にします。トレードオフは以下のとおりです。
  • プライマリキー範囲スキャンにおけるパフォーマンスへの影響の可能性。
  • 空間増幅率の向上（最悪の場合、最大2倍）。
  • ブロブキャッシュのための追加メモリ使用量。
| +| [`rocksdb.titan`](/tikv-configuration-file.md#rocksdbtitan) [`rocksdb.defaultcf.titan`](/tikv-configuration-file.md#rocksdbdefaultcftitan) [`min-blob-size`](/tikv-configuration-file.md#min-blob-size) [`blob-file-compression`](/tikv-configuration-file.md#blob-file-compression) | Titanストレージエンジンを有効にすることで、書き込み増幅を低減し、ディスクI/Oのボトルネックを緩和できます。特に、RocksDBの圧縮処理が書き込みワークロードに追いつかず、圧縮待ちバイトが蓄積される場合に有効です。 | 書き込み増幅が主なボトルネックである場合に有効にします。トレードオフは以下のとおりです。
  • 主キー範囲スキャンにおけるパフォーマンスへの影響の可能性。
  • 空間増幅率の向上（最悪の場合、最大2倍）。
  • ブロブキャッシュのための追加メモリ使用量。
| | [`storage.scheduler-pending-write-threshold`](/tikv-configuration-file.md#scheduler-pending-write-threshold) | TiKVスケジューラで書き込みキューの最大サイズを設定します。保留中の書き込みタスクの合計サイズがこのしきい値を超えると、TiKVは新規書き込み要求に対してエラーコード`Server Is Busy`を返します。 | デフォルト値は`100MiB`です。書き込み同時実行数が多い場合や、一時的な書き込みスパイクが発生する場合は、このしきい値を上げる（例えば`512MiB`にする）ことで負荷に対応できます。ただし、書き込みキューが継続的に蓄積され、このしきい値を超える場合は、根本的なパフォーマンスの問題が発生している可能性があり、さらに調査が必要です。 | | [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold) | kvDB L0ファイルの数に基づいて、書き込みフロー制御がトリガーされるタイミングを制御します。しきい値を上げると、書き込み負荷が高い場合の書き込み停止が減少します。 | しきい値を高く設定すると、L0ファイルが多数存在する場合に、より積極的な圧縮処理が行われる可能性があります。 | | [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 書き込みフロー制御を管理するために、保留中の圧縮バイトのしきい値を制御します。ソフトリミットを設定すると、部分的な書き込み拒否が発生します。 | デフォルトのソフトリミットは`192GiB`です。書き込み負荷の高いシナリオでは、圧縮処理が追いつかない場合、保留中の圧縮バイトが蓄積され、フロー制御がトリガーされる可能性があります。リミットを調整することでバッファ領域を増やすことができますが、蓄積が続く場合は、さらなる調査が必要な根本的な問題があることを示しています。 | diff --git a/tidb-rowid.md b/tidb-rowid.md index b37c018861a0e..dc9ae6e2e569f 100644 --- a/tidb-rowid.md +++ b/tidb-rowid.md @@ -5,18 +5,18 @@ summary: _tidb_rowid`とは何か、いつ利用できるのか、そして安 # _tidb_rowid {#code-tidb-rowid-code} -`_tidb_rowid`はTiDBによって自動的に生成される非表示のシステム列です。クラスタ化インデックスを使用しないテーブルの場合、この列はテーブルの内部行IDとして機能します。テーブルスキーマでこの列を宣言または変更することはできませんが、テーブルが内部行IDとして`_tidb_rowid`使用している場合は、SQLで参照できます。 +`_tidb_rowid`はTiDBによって自動的に生成される非表示のシステム列です。クラスター化インデックスを使用しないテーブルの場合、この列はテーブルの内部行IDとして機能します。テーブルスキーマでこの列を宣言または変更することはできませんが、テーブルが内部行IDとして`_tidb_rowid`使用している場合は、SQLで参照できます。 現在の実装では、 `_tidb_rowid`はTiDBによって自動的に管理される追加の`BIGINT NOT NULL`列です。 > **警告：** > -> - `_tidb_rowid`常にグローバルに一意であるとは限らないことに注意してください。クラスタ化インデックスを使用しないパーティションテーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`実行すると、異なるパーティション間で`_tidb_rowid`値が重複する可能性があります。 +> - `_tidb_rowid`常にグローバルに一意であるとは限らないことに注意してください。クラスター化インデックスを使用しないパーティションテーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`実行すると、異なるパーティション間で`_tidb_rowid`値が重複する可能性があります。 > - 安定した一意の識別子が必要な場合は、 `_tidb_rowid`に依存するのではなく、明示的な主キーを定義して使用してください。 ## _tidb_rowidが利用可能な場合 {#when-code-tidb-rowid-code-is-available} -TiDBでは、テーブルが一意の行識別子としてクラスタ化された主キーを使用しない場合、各行を識別するために`_tidb_rowid`使用します。実際には、これは次のタイプのテーブルが`_tidb_rowid`使用することを意味します。 +TiDBでは、テーブルが一意の行識別子としてクラスター化された主キーを使用しない場合、各行を識別するために`_tidb_rowid`使用します。実際には、これは次のタイプのテーブルが`_tidb_rowid`使用することを意味します。 - 主キーのないテーブル - 主キーが明示的に`NONCLUSTERED`と定義されているテーブル @@ -31,14 +31,14 @@ CREATE TABLE t2 (id BIGINT PRIMARY KEY NONCLUSTERED, a INT); CREATE TABLE t3 (id BIGINT PRIMARY KEY CLUSTERED, a INT); ``` -`t1`と`t2`については、これらのテーブルは行識別子としてクラスタ化インデックスを使用していないため、 `_tidb_rowid`に対してクエリを実行できます。 +`t1`と`t2`については、これらのテーブルは行識別子としてクラスター化インデックスを使用していないため、 `_tidb_rowid`に対してクエリを実行できます。 ```sql SELECT _tidb_rowid, a, b FROM t1; SELECT _tidb_rowid, id, a FROM t2; ``` -`t3`の場合、クラスタ化された主キーが既に行識別子になっているため、 `_tidb_rowid`利用できません。 +`t3`の場合、クラスター化された主キーが既に行識別子になっているため、 `_tidb_rowid`利用できません。 ```sql SELECT _tidb_rowid, id, a FROM t3; @@ -123,8 +123,8 @@ SELECT _tidb_rowid, a, b FROM t WHERE _tidb_rowid = 100; - `_tidb_rowid`という名前のユーザー列を作成することはできません。 - 既存のユーザー列の名前を`_tidb_rowid`に変更することはできません。 - `_tidb_rowid`はTiDBの内部列です。ビジネス上の主キーや長期的な識別子として扱わないでください。 -- パーティション化された非クラスタ化テーブルでは、 `_tidb_rowid`値はパーティション間で一意であることが保証されません。3 `EXCHANGE PARTITION`実行した後、異なるパーティションに同じ`_tidb_rowid`値を持つ行が含まれる可能性があります。 -- `_tidb_rowid`存在するかどうかは、テーブルのスキーマによって異なります。クラスタ化インデックスを持つテーブルの場合は、行識別子として主キーを使用してください。 +- パーティション化された非クラスター化テーブルでは、 `_tidb_rowid`値はパーティション間で一意であることが保証されません。3 `EXCHANGE PARTITION`実行した後、異なるパーティションに同じ`_tidb_rowid`値を持つ行が含まれる可能性があります。 +- `_tidb_rowid`存在するかどうかは、テーブルのスキーマによって異なります。クラスター化インデックスを持つテーブルの場合は、行識別子として主キーを使用してください。 ## ホットスポットの問題に対処する {#address-hotspot-issues} diff --git a/tidb-scheduling.md b/tidb-scheduling.md index fea4ce240faad..3d055966a96bf 100644 --- a/tidb-scheduling.md +++ b/tidb-scheduling.md @@ -41,7 +41,7 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン 2. 優れた分散システムには、次のような最適化が必要です。 - - すべてのリージョンリーダーは店舗に均等に分散されます。 + - すべてのリージョンリーダーはストアに均等に分散されます。 - すべての TiKV ピアのストレージ容量がバランスされています。 - ホットスポットはバランスが取れています。 - オンライン サービスの安定性を確保するには、リージョンの負荷分散の速度を制限する必要があります。 @@ -71,10 +71,10 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン - ディスク容量合計 - 使用可能なディスク容量 - - 地域の数 + - リージョンの数 - データの読み取り/書き込み速度 - 送受信されるスナップショットの数（データはスナップショットを通じてレプリカ間で複製される可能性があります） - - 店舗が混雑しているかどうか + - ストアが混雑しているかどうか - ラベル（ [トポロジーの認識](https://docs.pingcap.com/tidb/stable/schedule-replicas-by-topology-labels)参照） PD制御を使用して、TiKVストアのステータス（稼働中、切断、オフライン、ダウン、または廃棄）を確認できます。以下は、すべてのステータスとその関係についての説明です。 @@ -124,19 +124,19 @@ PDは、リージョンリーダーのハートビートから、リージョン これらの要件の鍵となるのは、ピアが同じ「ポジション」を持つことができることです。これは、障害耐性の最小単位です。リージョンのレプリカは、同じユニットに存在してはなりません。そこで、TiKVピアに[ラベル](https://github.com/tikv/tikv/blob/v4.0.0-beta/etc/config-template.toml#L140)設定し、PDに[場所ラベル](https://github.com/pingcap/pd/blob/v4.0.0-beta/conf/config.toml#L100)設定することで、ポジションのマーキングに使用するラベルを指定できます。 -**戦略3: レプリカは店舗間でバランスをとる必要がある** +**戦略3: レプリカはストア間でバランスをとる必要がある** リージョンレプリカのサイズ制限は固定されているため、ストア間でレプリカのバランスを保つことは、データ サイズのバランスを保つのに役立ちます。 -**戦略4：店舗間でリーダーのバランスをとる必要がある** +**戦略4：ストア間でリーダーのバランスをとる必要がある** 読み取りおよび書き込み操作はRaftプロトコルに従ってリーダー上で実行されるため、PD はリーダーを複数のピアではなくクラスター全体に分散する必要があります。 -**戦略5：店舗間でホットスポットのバランスをとる必要がある** +**戦略5：ストア間でホットスポットのバランスをとる必要がある** PD は、ストア ハートビートとリージョンハートビートからホット スポットを検出し、ホット スポットを分散することができます。 -**戦略6: 保管サイズは店舗間でバランスをとる必要がある** +**戦略6: 保管サイズはストア間でバランスをとる必要がある** 起動時に、TiKV ストアはストレージの`capacity`報告します。これは、ストアのスペース制限を示します。PD は、スケジュール設定時にこれを考慮します。 diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md index 95b4c10805f3e..8c53f4366a211 100644 --- a/tiflash/create-tiflash-replicas.md +++ b/tiflash/create-tiflash-replicas.md @@ -21,7 +21,7 @@ ALTER TABLE table_name SET TIFLASH REPLICA count; > **注記：** > -> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)クラスターの場合、 TiFlashレプリカの`count` `2`しか設定できません。7 `1`設定した場合、実行時に自動的に`2`に調整されます。2 より大きい数に設定した場合、レプリカ数に関するエラーが発生します。 +> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)クラスターの場合、 TiFlashレプリカの`count` `2`しか設定できません。7 `1`を設定した場合、実行時に自動的に`2`に調整されます。2 より大きい数に設定した場合、レプリカ数に関するエラーが発生します。 同じテーブルに対して複数のDDL文を実行した場合、最後に実行された文のみが確実に有効になります。次の例では、テーブル`tpch50`に対して2つのDDL文が実行されていますが、2番目の文（レプリカを削除する文）のみが確実に有効になります。 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 2cc6881fa9d4b..8e47ac0affeef 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -925,7 +925,7 @@ Raftstoreに関連するコンフィグレーション項目。 ### pd-store-heartbeat-tick-interval {#code-pd-store-heartbeat-tick-interval-code} -- 店舗からPDへのハートビートがトリガーされる時間間隔。 `0`この機能が無効になっていることを意味します。 +- ストアからPDへのハートビートがトリガーされる時間間隔。 `0`この機能が無効になっていることを意味します。 - デフォルト値: `"10s"` - 最小値: `0` diff --git a/tikv-control.md b/tikv-control.md index bf02dae2b72bc..b9774e07a2c7b 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -139,7 +139,7 @@ AAFF `region`サブコマンドの場合: -- 表示する地域を指定するには、 `-r`オプションを使用してください。複数の地域を指定する場合は、 `,`で区切ります。また、 `--all-regions`オプションを使用してすべての地域を表示することもできます。7 と`-r` `--all-regions`同時に使用できないことに注意してください。 +- 表示するリージョンを指定するには、 `-r`オプションを使用してください。複数のリージョンを指定する場合は、 `,`で区切ります。また、 `--all-regions`オプションを使用してすべてのリージョンを表示することもできます。7 と`-r` `--all-regions`同時に使用できないことに注意してください。 - 印刷するリージョンの数を制限するには、 `--limit`オプションを使用します (デフォルト: `16` )。 - 特定のキー範囲に含まれるリージョンを照会するには、 `--start`および`--end`オプションを使用します (デフォルト: 範囲制限なし、16 進形式)。 diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 459a63e16f334..484bf4622b47a 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -33,7 +33,7 @@ TiDBは各テーブルにTableID、各インデックスにIndexID、各行にRo インデックス データには、一意インデックスと非一意インデックスの 2 種類があります。 -- 一意のインデックスの場合は、上記のコーディング規則に従うことができます。 +- 一意インデックスの場合は、上記のコーディング規則に従うことができます。 - 非一意インデックスの場合、このエンコーディングでは一意キーを構築できません。これは、同じインデックスの`tablePrefix{TableID}_indexPrefixSep{IndexID}`番目は同じですが、複数の行の`ColumnsValue`番目は同じになる可能性があるためです。非一意インデックスのエンコーディング規則は次のとおりです。 Key: tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue_rowID @@ -43,7 +43,7 @@ TiDBは各テーブルにTableID、各インデックスにIndexID、各行にRo TiDBのコーディングルールによれば、同一テーブルのデータはTableIDの先頭で始まる範囲に収められ、RowID値の順序で並べられます。テーブルへの挿入時にRowID値が増加する場合、挿入された行は末尾にのみ追加されます。Regionは一定のサイズに達すると分割されますが、その後も範囲の末尾にのみ追加できます。1 `INSERT`操作は1つのリージョンに対してのみ実行でき、ホットスポットを形成します。 -一般的な自動インクリメント主キーは、順次増加します。主キーが整数型の場合、デフォルトで主キーの値がRowIDとして使用されます。この場合、RowIDは順次増加し、 `INSERT`操作が多数発生すると、テーブルの書き込みホットスポットが発生します。 +一般的なAUTO_INCREMENT主キーは、順次増加します。主キーが整数型の場合、デフォルトで主キーの値がRowIDとして使用されます。この場合、RowIDは順次増加し、 `INSERT`操作が多数発生すると、テーブルの書き込みホットスポットが発生します。 一方、TiDBのRowIDもデフォルトで自動増分されます。主キーが整数型でない場合は、書き込みホットスポットの問題が発生する可能性があります。 @@ -81,7 +81,7 @@ TiDBのコーディングルールによれば、同一テーブルのデータ ## SHARD_ROW_ID_BITSを使用してホットスポットを処理する {#use-code-shard-row-id-bits-code-to-process-hotspots} -非クラスター化主キーまたは主キーのないテーブルの場合、TiDBは暗黙的な自動インクリメントRowIDを使用します。1 `INSERT`操作が多数存在する場合、データは単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 +非クラスター化主キーまたは主キーのないテーブルの場合、TiDBは暗黙的なAUTO_INCREMENT RowIDを使用します。1 `INSERT`操作が多数存在する場合、データは単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)設定すると、行 ID が分散されて複数のリージョンに書き込まれるため、書き込みホットスポットの問題を軽減できます。 @@ -154,7 +154,7 @@ SELECT LAST_INSERT_ID(); 上記の負荷図に示されているように、 `AUTO_INCREMENT`代わりに`AUTO_RANDOM`使用すると、ホットスポットを適切に分散できます。 -詳細については[自動ランダム](/auto-random.md)参照してください。 +詳細については[AUTO_RANDOM](/auto-random.md)参照してください。 ## 小さなテーブルホットスポットの最適化 {#optimization-of-small-table-hotspots}