From ffb4f0e4d0a827f33606c7a122379137b2a85652 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 27 Aug 2026 10:12:57 +0900 Subject: [PATCH 1/5] =?UTF-8?q?i18n(ja):=20fix=20dropped=20=E3=81=8C=20par?= =?UTF-8?q?ticle=20before=20predicates=20(batch=200)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ai/reference/vector-search-index.md | 2 +- auto-random.md | 2 +- best-practices/three-dc-local-read.md | 2 +- character-set-gbk.md | 2 +- dashboard/dashboard-resource-manager.md | 2 +- dm/dm-error-handling.md | 2 +- migrate-from-tidb-to-tidb.md | 2 +- pipelined-dml.md | 2 +- releases/release-2.0.3.md | 2 +- releases/release-2.1.18.md | 2 +- releases/release-3.0.4.md | 2 +- releases/release-3.0.6.md | 2 +- releases/release-4.0.0-rc.1.md | 2 +- releases/release-5.0.0-rc.md | 2 +- releases/release-5.0.6.md | 2 +- releases/release-6.5.0.md | 6 +++--- releases/release-6.5.4.md | 4 ++-- releases/release-7.1.2.md | 2 +- releases/release-7.5.4.md | 4 ++-- releases/release-8.5.5.md | 2 +- sql-statements/sql-statement-show-collation.md | 2 +- temporary-tables.md | 2 +- ticdc/ticdc-sink-to-kafka.md | 2 +- tidb-cloud/migrate-from-mysql-using-data-migration.md | 2 +- tiup/tiup-cluster-no-sudo-mode.md | 2 +- 25 files changed, 29 insertions(+), 29 deletions(-) diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md index 1ff68b3308ced..28dd7fa6c0703 100644 --- a/ai/reference/vector-search-index.md +++ b/ai/reference/vector-search-index.md @@ -27,7 +27,7 @@ aliases: ['/ja/tidb/stable/vector-search-index/','/ja/tidbcloud/vector-search-in - ベクトル検索インデックスが設定された列を直接削除することはサポートされていません。このような列を削除するには、まずその列のベクトル検索インデックスを削除し、次に列自体を削除します。 - ベクトルインデックスを持つ列の型の変更はサポートされていません。 - ベクトル検索インデックスを[見えない](/sql-statements/sql-statement-alter-index.md)に設定することはサポートされていません。 -- [保存時の暗号化](/encryption-at-rest.md)有効になっているTiFlashノード上でベクトル検索インデックスを構築することはサポートされていません。 +- [保存時の暗号化](/encryption-at-rest.md)が有効になっているTiFlashノード上でベクトル検索インデックスを構築することはサポートされていません。 ## HNSWベクトルインデックスを作成する {#create-the-hnsw-vector-index} diff --git a/auto-random.md b/auto-random.md index 44879cfeaf050..e986d39d25ef8 100644 --- a/auto-random.md +++ b/auto-random.md @@ -205,7 +205,7 @@ ALTER TABLE t FORCE AUTO_RANDOM_BASE = 1000; `AUTO_RANDOM`を使用する場合は、次の制限に注意してください。 - 明示的に値を挿入するには、システム変数`@@allow_auto_random_explicit_insert`の値を`1` （デフォルトは`0` ）に設定する必要があります。データを挿入する際に、属性`AUTO_RANDOM`持つ列に明示的に値を指定することは推奨さ**れません**。そうしないと、このテーブルに自動的に割り当てられる数値が事前に使い果たされてしまう可能性があります。 -- この属性は、主キー列に**のみ**`BIGINT`型で指定してください。それ以外の場合はエラーが発生します。また、主キーの属性が`NONCLUSTERED`の場合、整数型の主キーであっても`AUTO_RANDOM`サポートされません`CLUSTERED`型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 +- この属性は、主キー列に**のみ**`BIGINT`型で指定してください。それ以外の場合はエラーが発生します。また、主キーの属性が`NONCLUSTERED`の場合、整数型の主キーであっても`AUTO_RANDOM`がサポートされません`CLUSTERED`型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 - `ALTER TABLE`を使用して`AUTO_RANDOM`属性を変更することはできません (この属性の追加や削除を含む)。 - 最大値が列タイプの最大値に近い場合は、 `ALTER TABLE`を使用して`AUTO_INCREMENT`から`AUTO_RANDOM`に変更することはできません。 - `AUTO_RANDOM`属性で指定された主キー列の列タイプを変更することはできません。 diff --git a/best-practices/three-dc-local-read.md b/best-practices/three-dc-local-read.md index 60ff06e6c6f26..004d088dd49fa 100644 --- a/best-practices/three-dc-local-read.md +++ b/best-practices/three-dc-local-read.md @@ -14,7 +14,7 @@ aliases: ['/ja/tidb/stable/three-dc-local-read/'] 3 つのデータセンターの展開方法については、 [1つの地域展開における複数のデータセンター](/multi-data-centers-in-one-city-deployment.md)を参照してください。 -TiKVノードとTiDBノードの両方に構成項目`labels`設定されている場合、同じデータセンター内のTiKVノードとTiDBノードのラベル`zone`の値は同一である必要があります。例えば、TiKVノードとTiDBノードの両方がデータセンター`dc-1`にある場合、2つのノードに以下のラベルを設定する必要があります。 +TiKVノードとTiDBノードの両方に構成項目`labels`が設定されている場合、同じデータセンター内のTiKVノードとTiDBノードのラベル`zone`の値は同一である必要があります。例えば、TiKVノードとTiDBノードの両方がデータセンター`dc-1`にある場合、2つのノードに以下のラベルを設定する必要があります。 ``` [labels] diff --git a/character-set-gbk.md b/character-set-gbk.md index 088ff3c6ff9d5..c65b387b62872 100644 --- a/character-set-gbk.md +++ b/character-set-gbk.md @@ -7,7 +7,7 @@ summary: このドキュメントでは、GBK 文字セットの TiDB サポー TiDBはv5.4.0以降、GBK文字セットをサポートしています。このドキュメントでは、TiDBのGBK文字セットのサポートと互換性に関する情報を提供します。 -TiDB v6.0.0以降、デフォルトで[照合のための新しいフレームワーク](/character-set-and-collation.md#new-framework-for-collations)有効になります。TiDB GBK文字セットのデフォルトの照合照合順序は`gbk_chinese_ci`で、これはMySQLと一致しています。 +TiDB v6.0.0以降、デフォルトで[照合のための新しいフレームワーク](/character-set-and-collation.md#new-framework-for-collations)が有効になります。TiDB GBK文字セットのデフォルトの照合照合順序は`gbk_chinese_ci`で、これはMySQLと一致しています。 ```sql SHOW CHARACTER SET WHERE CHARSET = 'gbk'; diff --git a/dashboard/dashboard-resource-manager.md b/dashboard/dashboard-resource-manager.md index d1de53e166d4b..8679fe95e8db6 100644 --- a/dashboard/dashboard-resource-manager.md +++ b/dashboard/dashboard-resource-manager.md @@ -57,7 +57,7 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ - 時間ウィンドウの範囲が 10分から 24時間の範囲外の場合、次のエラーが表示されます`ERROR 1105 (HY000): the duration of calibration is too short, which could lead to inaccurate output. Please make the duration between 10m0s and 24h0m0s` 。 - - [実際の作業負荷に基づく容量推定](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload)機能の監視メトリックには、 `tikv_cpu_quota` 、 `tidb_server_maxprocs` 、 `resource_manager_resource_unit` 、 `process_cpu_usage`含まれます。CPUクォータ監視データが空の場合、対応する監視メトリック名（例： `Error 1105 (HY000): There is no CPU quota metrics, metrics 'tikv_cpu_quota' is empty` ）にエラーが発生します。 + - [実際の作業負荷に基づく容量推定](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload)機能の監視メトリックには、 `tikv_cpu_quota` 、 `tidb_server_maxprocs` 、 `resource_manager_resource_unit` 、 `process_cpu_usage`が含まれます。CPUクォータ監視データが空の場合、対応する監視メトリック名（例： `Error 1105 (HY000): There is no CPU quota metrics, metrics 'tikv_cpu_quota' is empty` ）にエラーが発生します。 - 時間枠内のワークロードが低すぎる場合、または`resource_manager_resource_unit`と`process_cpu_usage`監視データが欠落している場合は、エラーが報告されます`Error 1105 (HY000): The workload in selected time window is too low, with which TiDB is unable to reach a capacity estimation; please select another time window with higher workload, or calibrate resource by hardware instead`また、TiKVはmacOSのCPU使用率を監視しないため、実際のワークロードに基づく容量推定をサポートしておらず、このエラーも報告されます。 diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md index c9452a005d877..cebfad18e61af 100644 --- a/dm/dm-error-handling.md +++ b/dm/dm-error-handling.md @@ -172,7 +172,7 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ 6. `query-status`を使用して移行タスクのステータスを確認する。元のエラーの原因となったリレーログファイルの移行が完了したら、 `safe-mode`元の値に戻して移行タスクを再開できます。 -### タスクをクエリするかログを確認すると、 `Access denied for user 'root'@'172.31.43.27' (using password: YES)`表示されます。 {#access-denied-for-user-root172314327-using-password-yes-shows-when-you-query-the-task-or-check-the-log} +### タスクをクエリするかログを確認すると、 `Access denied for user 'root'@'172.31.43.27' (using password: YES)`が表示されます。 {#access-denied-for-user-root172314327-using-password-yes-shows-when-you-query-the-task-or-check-the-log} すべてのDM設定ファイルにおけるデータベース関連のパスワードについては、 `dmctl`で暗号化したパスワードを使用することをお勧めします。データベースパスワードが空の場合は、暗号化する必要はありません。プレーンテキストパスワードの暗号化方法については、 [dmctlを使用してデータベースパスワードを暗号化する](/dm/dm-manage-source.md#encrypt-the-database-password)を参照してください。 diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index a43f57f86b1c7..2e83065799f78 100644 --- a/migrate-from-tidb-to-tidb.md +++ b/migrate-from-tidb-to-tidb.md @@ -138,7 +138,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー > **Note:** > - > TiCDC `gc-ttl`デフォルトで24時間です。バックアップと復元に時間がかかる場合、デフォルトの`gc-ttl`不十分で、その後の[増分レプリケーションタスク](#step-3-migrate-incremental-data)失敗する可能性があります。このような状況を回避するには、TiCDCサーバーを起動する際に、特定のニーズに合わせて`gc-ttl`値を調整してください。詳細については、 [TiCDCにおける`gc-ttl`とは](/ticdc/ticdc-faq.md#what-is-gc-ttl-in-ticdc)を参照してください。 + > TiCDC `gc-ttl`デフォルトで24時間です。バックアップと復元に時間がかかる場合、デフォルトの`gc-ttl`不十分で、その後の[増分レプリケーションタスク](#step-3-migrate-incremental-data)が失敗する可能性があります。このような状況を回避するには、TiCDCサーバーを起動する際に、特定のニーズに合わせて`gc-ttl`値を調整してください。詳細については、 [TiCDCにおける`gc-ttl`とは](/ticdc/ticdc-faq.md#what-is-gc-ttl-in-ticdc)を参照してください。 2. データをバックアップします。 diff --git a/pipelined-dml.md b/pipelined-dml.md index 7144df31a9b69..917d1cc8999a5 100644 --- a/pipelined-dml.md +++ b/pipelined-dml.md @@ -43,7 +43,7 @@ summary: パイプラインDMLのユースケース、メソッド、制限事 - サポートされるステートメントは[自動コミット](/transaction-overview.md#autocommit)だけです。 - `INSERT` 、 `UPDATE` 、 `REPLACE` 、 `DELETE`のみがサポートされます。 - ターゲットテーブルには[一時テーブル](/temporary-tables.md)または[キャッシュされたテーブル](/cached-tables.md)含めることはできません。 - - [外部キー制約](/foreign-key.md)有効になっている場合（ `foreign_key_checks = ON` ）、ターゲットテーブルに外部キー関係を含めることはできません。 + - [外部キー制約](/foreign-key.md)が有効になっている場合（ `foreign_key_checks = ON` ）、ターゲットテーブルに外部キー関係を含めることはできません。 - `INSERT IGNORE ... ON DUPLICATE KEY UPDATE`ステートメントを実行すると、競合する更新によって`Duplicate entry`エラーが発生する可能性があります。 ## 使用法 {#usage} diff --git a/releases/release-2.0.3.md b/releases/release-2.0.3.md index c50c5eaeeec11..b4c29341c0ea1 100644 --- a/releases/release-2.0.3.md +++ b/releases/release-2.0.3.md @@ -23,7 +23,7 @@ summary: TiDB 2.0.3は、システムの互換性と安定性の向上を伴い - 特定の式パラメータで`MAX` `MIN`panic問題を修正 - 特殊な条件で結果`JOIN`がnullになる問題を修正 - 範囲の構築とクエリ時の`IN`式の問題を修正 -- `Prepare`を使用してクエリを実行し、 `Plan Cache`有効になっている場合の範囲計算の問題を修正しました +- `Prepare`を使用してクエリを実行し、 `Plan Cache`が有効になっている場合の範囲計算の問題を修正しました - 異常な状況でスキーマ情報が頻繁に読み込まれる問題を修正 ## PD {#pd} diff --git a/releases/release-2.1.18.md b/releases/release-2.1.18.md index b527d037d1fe8..19bb73479fa20 100644 --- a/releases/release-2.1.18.md +++ b/releases/release-2.1.18.md @@ -40,7 +40,7 @@ TiDB Ansible バージョン: 2.1.18 - プラン実行中にリセットされないようにSQLクエリの開始時刻を`SessionVars`に記録する[＃12676](https://github.com/pingcap/tidb/pull/12676) - `ORDER BY` `GROUP BY` `?` ホルダーをサポート`LIMIT OFFSET` [＃12514](https://github.com/pingcap/tidb/pull/12514) - 最後のステートメントが`COMMIT` ときに前のステートメントを出力するために、スロークエリログに`Prev_stmt`フィールドを追加します。 [＃12724](https://github.com/pingcap/tidb/pull/12724) - - 明示的にコミットされたトランザクションで`COMMIT`失敗した場合、 `COMMIT`の前の最後のステートメントをログに記録します。 [＃12747](https://github.com/pingcap/tidb/pull/12747) + - 明示的にコミットされたトランザクションで`COMMIT`が失敗した場合、 `COMMIT`の前の最後のステートメントをログに記録します。 [＃12747](https://github.com/pingcap/tidb/pull/12747) - TiDBサーバーがSQL文を実行する際に、前の文の保存方法を最適化してパフォーマンスを向上します[＃12751](https://github.com/pingcap/tidb/pull/12751) - `skip-grant-table=true`構成の`FLUSH PRIVILEGES`ステートメントによって引き起こされるpanic問題を修正 [＃12816](https://github.com/pingcap/tidb/pull/12816) - 短時間に多数の書き込み要求があった場合にパフォーマンスのボトルネックを回避するために、AutoID を適用するデフォルトの最小ステップを`1000`から`30000`に増やします[＃12891](https://github.com/pingcap/tidb/pull/12891) diff --git a/releases/release-3.0.4.md b/releases/release-3.0.4.md index 1ad6c5af79419..7b43eb71f3e52 100644 --- a/releases/release-3.0.4.md +++ b/releases/release-3.0.4.md @@ -44,7 +44,7 @@ TiDB Ansible バージョン: 3.0.4 - SQLオプティマイザー - フィードバックで分割すると無効なクエリ範囲が生成される可能性がある問題を修正しました [＃12170](https://github.com/pingcap/tidb/pull/12170) - 結果に無効なキーが含まれている場合はエラーを返すのではなく、 `SHOW STATS_BUCKETS`のステートメントの返されたエラーを16進数で表示します。 [＃12094](https://github.com/pingcap/tidb/pull/12094) - - クエリに`SLEEP`関数（たとえば`select 1 from (select sleep(1)) t;)` ）が含まれている場合、列プルーニングによってクエリ中に無効な`sleep(1)`発生する問題を修正しました。 [＃11953](https://github.com/pingcap/tidb/pull/11953) + - クエリに`SLEEP`関数（たとえば`select 1 from (select sleep(1)) t;)` ）が含まれている場合、列プルーニングによってクエリ中に無効な`sleep(1)`が発生する問題を修正しました。 [＃11953](https://github.com/pingcap/tidb/pull/11953) - クエリがテーブルデータではなく列数のみに関係する場合は、インデックススキャンを使用してIOを削減します[＃12112](https://github.com/pingcap/tidb/pull/12112) - MySQL との互換性を保つために、 `use index()`でインデックスが指定されていない場合はインデックスを使用しない [＃12100](https://github.com/pingcap/tidb/pull/12100) - `CMSketch`統計の`TopN`レコードの数を厳密に制限して、ステートメント数が TiDB のトランザクションのサイズ制限を超えたために`ANALYZE`ステートメントが失敗する問題を修正します。 [＃11914](https://github.com/pingcap/tidb/pull/11914) diff --git a/releases/release-3.0.6.md b/releases/release-3.0.6.md index 7d82a778d615d..b411fb1d046eb 100644 --- a/releases/release-3.0.6.md +++ b/releases/release-3.0.6.md @@ -30,7 +30,7 @@ TiDB Ansible バージョン: 3.0.6 - 空のテーブルで`FAST ANALYZE`を実行したときに発生するpanic問題を修正 [＃13343](https://github.com/pingcap/tidb/pull/13343) - 複数列のインデックスを含む空のテーブルで`FAST ANALYZE`を実行するとpanic問題を修正[＃13394](https://github.com/pingcap/tidb/pull/13394) - `WHERE`句に一意キー等号条件が含まれている場合に推定行数が 1 より大きくなる問題を修正しました [＃13382](https://github.com/pingcap/tidb/pull/13382) - - TiDB で`Streaming`有効になっている場合に返されるデータが重複する可能性がある問題を修正しました [＃13254](https://github.com/pingcap/tidb/pull/13254) + - TiDB で`Streaming`が有効になっている場合に返されるデータが重複する可能性がある問題を修正しました [＃13254](https://github.com/pingcap/tidb/pull/13254) - 推定精度を向上させるために、count-minスケッチから上位N個の値を抽出します[＃13429](https://github.com/pingcap/tidb/pull/13429) - サーバ - gRPC ダイヤルがタイムアウトすると、TiKV に送信されたリクエストがすぐに失敗するようにします[＃12926](https://github.com/pingcap/tidb/pull/12926) diff --git a/releases/release-4.0.0-rc.1.md b/releases/release-4.0.0-rc.1.md index 913cc1182bb06..31fe9a4a70e32 100644 --- a/releases/release-4.0.0-rc.1.md +++ b/releases/release-4.0.0-rc.1.md @@ -53,7 +53,7 @@ TiDB バージョン: 4.0.0-rc.1 - Backup & Restore (BR) - チェックサムが無効になっている場合でもチェックサムが実行される問題を修正[＃223](https://github.com/pingcap/br/pull/223) - - TiDB で`auto-random`または`alter-pk`有効になっている場合に増分レプリケーションが失敗する問題を修正 [＃231](https://github.com/pingcap/br/pull/231) [＃230](https://github.com/pingcap/br/pull/230) + - TiDB で`auto-random`または`alter-pk`が有効になっている場合に増分レプリケーションが失敗する問題を修正 [＃231](https://github.com/pingcap/br/pull/231) [＃230](https://github.com/pingcap/br/pull/230) ## 新機能 {#new-features} diff --git a/releases/release-5.0.0-rc.md b/releases/release-5.0.0-rc.md index 027cda150042e..52b0523860ee9 100644 --- a/releases/release-5.0.0-rc.md +++ b/releases/release-5.0.0-rc.md @@ -99,7 +99,7 @@ TiDB では、ID 情報やクレジットカード番号などの機密情報の 以前は非同期コミット機能がなかったため、書き込まれたステートメントは2フェーズトランザクションのコミットが完了した後にのみクライアントに返されていました。今回の非同期コミット機能では、2フェーズコミットの第1フェーズが完了した後に結果をクライアントに返すようになりました。第2フェーズはバックグラウンドで非同期的に実行されるため、トランザクションコミットのレイテンシーが短縮されます。 -ただし、非同期コミットが有効になっている場合、トランザクションの外部一貫性は`tidb_guarantee_external_consistency = ON`設定されている場合**のみ**保証されます。非同期コミットを有効にすると、パフォーマンスが低下する可能性があります。 +ただし、非同期コミットが有効になっている場合、トランザクションの外部一貫性は`tidb_guarantee_external_consistency = ON`が設定されている場合**のみ**保証されます。非同期コミットを有効にすると、パフォーマンスが低下する可能性があります。 ユーザーは、グローバル変数`tidb_enable_async_commit = ON`設定することでこの機能を有効にできます。 diff --git a/releases/release-5.0.6.md b/releases/release-5.0.6.md index 20076ecf8b91b..5abf632a97745 100644 --- a/releases/release-5.0.6.md +++ b/releases/release-5.0.6.md @@ -138,7 +138,7 @@ TiDB バージョン: 5.0.6 - TiCDC - - `force-replicate`有効になっているときに、有効なインデックスのない一部のパーティションテーブルが無視される可能性がある問題を修正[＃2834](https://github.com/pingcap/tiflow/issues/2834) + - `force-replicate`が有効になっているときに、有効なインデックスのない一部のパーティションテーブルが無視される可能性がある問題を修正[＃2834](https://github.com/pingcap/tiflow/issues/2834) - `cdc cli`予期しないパラメータを受け取ったときにユーザパラメータを黙って切り捨て、ユーザ入力パラメータが失われる問題を修正[＃2303](https://github.com/pingcap/tiflow/issues/2303) - Kafka メッセージの書き込み中にエラーが発生すると、TiCDC 同期タスクが一時停止する可能性がある問題を修正しました[＃2978](https://github.com/pingcap/tiflow/issues/2978) - 一部のタイプの列を Open Protocol 形式にエンコードするときに発生する可能性のあるpanic問題を修正しました。 [＃2758](https://github.com/pingcap/tiflow/issues/2758) diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index d1a3780c60ffb..375069b4ded77 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -195,7 +195,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では TiDBはv6.4.0以降、実験的機能としてグローバルメモリ制御を導入しました。v6.5.0ではGAとなり、メインメモリの消費量を追跡できるようになりました。グローバルメモリの消費量が[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)で定義されたしきい値に達すると、TiDBはGCまたはSQL操作のキャンセルによってメモリ使用量を制限し、安定性を確保しようとします。 - セッション中のトランザクションによって消費されるメモリ（最大値は以前は設定項目[`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit)によって設定されていました）が、メモリ管理モジュールによって追跡されるようになりました。単一セッションのメモリ消費量がシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)で定義されたしきい値に達すると、システム変数[`tidb_mem_oom_action`](/system-variables.md#tidb_mem_oom_action-new-in-v610)で定義された動作がトリガーされます（デフォルトは`CANCEL` 、つまり操作のキャンセルです）。前方互換性を確保するため、デフォルト以外の値として[`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit)設定されている場合でも、TiDB はトランザクションが`txn-total-size-limit`で設定されたメモリを使用できるようにします。 + セッション中のトランザクションによって消費されるメモリ（最大値は以前は設定項目[`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit)によって設定されていました）が、メモリ管理モジュールによって追跡されるようになりました。単一セッションのメモリ消費量がシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)で定義されたしきい値に達すると、システム変数[`tidb_mem_oom_action`](/system-variables.md#tidb_mem_oom_action-new-in-v610)で定義された動作がトリガーされます（デフォルトは`CANCEL` 、つまり操作のキャンセルです）。前方互換性を確保するため、デフォルト以外の値として[`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit)が設定されている場合でも、TiDB はトランザクションが`txn-total-size-limit`で設定されたメモリを使用できるようにします。 TiDB v6.5.0以降をご利用の場合は、 [`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit)を削除し、トランザクションのメモリ使用量に別途制限を設けないことを推奨します。代わりに、システム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)と[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)を使用してグローバルメモリを管理することで、メモリ使用効率を向上させることができます。 @@ -337,10 +337,10 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では | [`tidb_ttl_job_schedule_window_end_time`](/system-variables.md#tidb_ttl_job_schedule_window_end_time-new-in-v650) | 新しく追加された | この変数は、バックグラウンドで実行されるTTLジョブのスケジュールウィンドウの終了時刻を制御するために使用されます。この変数の値を変更する際は、ウィンドウが小さいと期限切れデータのクリーンアップが失敗する可能性があるので注意してください。 | | [`tidb_ttl_scan_batch_size`](/system-variables.md#tidb_ttl_scan_batch_size-new-in-v650) | 新しく追加された | この変数は、TTL ジョブで期限切れのデータをスキャンするために使用される`SELECT`ステートメントごとに`LIMIT`値を設定するために使用されます。 | | [`tidb_ttl_scan_worker_count`](/system-variables.md#tidb_ttl_scan_worker_count-new-in-v650) | 新しく追加された | この変数は、各 TiDB ノード上の TTL スキャン ジョブの最大同時実行数を設定するために使用されます。 | -| [`validate_password.check_user_name`](/system-variables.md#validate_passwordcheck_user_name-new-in-v650) | 新しく追加された | パスワード複雑度チェックにおけるチェック項目。パスワードがユーザー名と一致するかどうかをチェックします。この変数は、 [`validate_password.enable`](/system-variables.md#validate_passwordenable-new-in-v650)有効になっている場合にのみ有効になります。デフォルト値は`ON`です。 | +| [`validate_password.check_user_name`](/system-variables.md#validate_passwordcheck_user_name-new-in-v650) | 新しく追加された | パスワード複雑度チェックにおけるチェック項目。パスワードがユーザー名と一致するかどうかをチェックします。この変数は、 [`validate_password.enable`](/system-variables.md#validate_passwordenable-new-in-v650)が有効になっている場合にのみ有効になります。デフォルト値は`ON`です。 | | [`validate_password.dictionary`](/system-variables.md#validate_passworddictionary-new-in-v650) | 新しく追加された | パスワード複雑度チェックにおけるチェック項目です。パスワードが辞書内の単語と一致するかどうかをチェックします。この変数は、 [`validate_password.enable`](/system-variables.md#validate_passwordenable-new-in-v650)が有効で、 [`validate_password.policy`](/system-variables.md#validate_passwordpolicy-new-in-v650) `2` （STRONG）に設定されている場合にのみ有効になります。デフォルト値は`""`です。 | | [`validate_password.enable`](/system-variables.md#validate_passwordenable-new-in-v650) | 新しく追加された | この変数は、パスワードの複雑さのチェックを実行するかどうかを制御します。この変数を`ON`に設定すると、TiDBはパスワード設定時にパスワードの複雑さのチェックを実行します。デフォルト値は`OFF`です。 | -| [`validate_password.length`](/system-variables.md#validate_passwordlength-new-in-v650) | 新しく追加された | パスワードの複雑さチェックにおけるチェック項目です。パスワードの長さが十分かどうかをチェックします。デフォルトでは、パスワードの最小長は`8`です。この変数は、 [`validate_password.enable`](/system-variables.md#validate_passwordenable-new-in-v650)有効になっている場合にのみ有効になります。 | +| [`validate_password.length`](/system-variables.md#validate_passwordlength-new-in-v650) | 新しく追加された | パスワードの複雑さチェックにおけるチェック項目です。パスワードの長さが十分かどうかをチェックします。デフォルトでは、パスワードの最小長は`8`です。この変数は、 [`validate_password.enable`](/system-variables.md#validate_passwordenable-new-in-v650)が有効になっている場合にのみ有効になります。 | | [`validate_password.mixed_case_count`](/system-variables.md#validate_passwordmixed_case_count-new-in-v650) | 新しく追加された | パスワード複雑度チェックにおけるチェック項目です。パスワードに十分な大文字と小文字が含まれているかどうかをチェックします。この変数は、 [`validate_password.enable`](/system-variables.md#validate_passwordenable-new-in-v650)が有効で、 [`validate_password.policy`](/system-variables.md#validate_passwordpolicy-new-in-v650) `1` （中）以上に設定されている場合にのみ有効になります。デフォルト値は`1`です。 | | [`validate_password.number_count`](/system-variables.md#validate_passwordnumber_count-new-in-v650) | 新しく追加された | パスワード複雑度チェックにおけるチェック項目。パスワードに十分な数の数字が含まれているかどうかをチェックします。この変数は、 [`validate_password.enable`](/system-variables.md#password_reuse_interval-new-in-v650)が有効で、 [`validate_password.policy`](/system-variables.md#validate_passwordpolicy-new-in-v650) `1` (MEDIUM) 以上に設定されている場合にのみ有効になります。デフォルト値は`1`です。 | | [`validate_password.policy`](/system-variables.md#validate_passwordpolicy-new-in-v650) | 新しく追加された | この変数は、パスワードの複雑さチェックのポリシーを制御します。値は`0` 、 `1` 、または`2` （それぞれLOW、MEDIUM、STRONGに対応）です。この変数は、 [`validate_password.enable`](/system-variables.md#password_reuse_interval-new-in-v650)が有効な場合にのみ有効になります。デフォルト値は`1`です。 | diff --git a/releases/release-6.5.4.md b/releases/release-6.5.4.md index be179e46e1954..f02827dfe0eca 100644 --- a/releases/release-6.5.4.md +++ b/releases/release-6.5.4.md @@ -92,8 +92,8 @@ TiDB バージョン: 6.5.4 - バッチコプロセッサの再試行によって誤ったリージョン情報が生成される可能性があり、クエリが失敗する問題を修正しました[＃44622](https://github.com/pingcap/tidb/issues/44622) @[windtalker](https://github.com/windtalker) - `indexMerge`のクエリが強制終了されたときに発生するハングアップの問題を修正しました [＃45279](https://github.com/pingcap/tidb/issues/45279) @[xzhangxian1008](https://github.com/xzhangxian1008) - システムテーブル`INFORMATION_SCHEMA.TIKV_REGION_STATUS`をクエリすると、場合によっては誤った結果が返される問題を修正しました[＃45531](https://github.com/pingcap/tidb/issues/45531) @[Defined2014](https://github.com/Defined2014) - - `tidb_enable_parallel_apply`有効になっている場合、MPP モードでのクエリ結果が正しくない問題を修正[＃45299](https://github.com/pingcap/tidb/issues/45299) @[windtalker](https://github.com/windtalker) - - `tidb_opt_agg_push_down`有効になっている場合にクエリが誤った結果を返す可能性がある問題を修正[＃44795](https://github.com/pingcap/tidb/issues/44795) @[AilinKid](https://github.com/AilinKid) + - `tidb_enable_parallel_apply`が有効になっている場合、MPP モードでのクエリ結果が正しくない問題を修正[＃45299](https://github.com/pingcap/tidb/issues/45299) @[windtalker](https://github.com/windtalker) + - `tidb_opt_agg_push_down`が有効になっている場合にクエリが誤った結果を返す可能性がある問題を修正[＃44795](https://github.com/pingcap/tidb/issues/44795) @[AilinKid](https://github.com/AilinKid) - 仮想列によって発生する適切な物理プランが見つからない問題を修正しました [＃41014](https://github.com/pingcap/tidb/issues/41014) @[AilinKid](https://github.com/AilinKid) - 空の`processInfo` によって引き起こされるpanic問題を修正 [＃43829](https://github.com/pingcap/tidb/issues/43829) @[zimulala](https://github.com/zimulala) - 文中の`n`負の数の場合に文`SELECT CAST(n AS CHAR)`のクエリ結果が正しくない問題を修正しました [＃44786](https://github.com/pingcap/tidb/issues/44786) @[xhebox](https://github.com/xhebox) diff --git a/releases/release-7.1.2.md b/releases/release-7.1.2.md index d9a0f901e9fc9..8b57b008a3f06 100644 --- a/releases/release-7.1.2.md +++ b/releases/release-7.1.2.md @@ -86,7 +86,7 @@ TiDB バージョン: 7.1.2 - パーティション交換中にパーティション定義に準拠していないデータを検出できない問題を修正 [＃46492](https://github.com/pingcap/tidb/issues/46492) @[mjonss](https://github.com/mjonss) - `MERGE_JOIN`の結果が間違っている問題を修正[＃46580](https://github.com/pingcap/tidb/issues/46580) @[qw4990](https://github.com/qw4990) - 符号なし型と`Duration`型定数を比較したときに発生する誤った結果を修正しました [＃45410](https://github.com/pingcap/tidb/issues/45410) @[wshwsh12](https://github.com/wshwsh12) - - `AUTO_ID_CACHE=1` に設定されている場合に`Duplicate entry`発生する可能性がある問題を修正しました [＃46444](https://github.com/pingcap/tidb/issues/46444) @[tiancaiamao](https://github.com/tiancaiamao) + - `AUTO_ID_CACHE=1` に設定されている場合に`Duplicate entry`が発生する可能性がある問題を修正しました [＃46444](https://github.com/pingcap/tidb/issues/46444) @[tiancaiamao](https://github.com/tiancaiamao) - TTLが実行されているときのメモリリークの問題を修正しました [＃45510](https://github.com/pingcap/tidb/issues/45510) @[lcwangchao](https://github.com/lcwangchao) - 接続を切断すると go コルーチン リークが発生する可能性がある問題を修正[＃46034](https://github.com/pingcap/tidb/issues/46034) @[pingyu](https://github.com/pingyu) - インデックス結合のエラーによりクエリが停止する可能性がある問題を修正[＃45716](https://github.com/pingcap/tidb/issues/45716) @[wshwsh12](https://github.com/wshwsh12) diff --git a/releases/release-7.5.4.md b/releases/release-7.5.4.md index d16fb9d344ca0..0f36040753651 100644 --- a/releases/release-7.5.4.md +++ b/releases/release-7.5.4.md @@ -49,7 +49,7 @@ TiDB バージョン: 7.5.4 - TiDB - - データベースに多くのテーブルが存在する場合に`FLASHBACK DATABASE`失敗する問題を修正[＃54415](https://github.com/pingcap/tidb/issues/54415) @[lance6716](https://github.com/lance6716) + - データベースに多くのテーブルが存在する場合に`FLASHBACK DATABASE`が失敗する問題を修正[＃54415](https://github.com/pingcap/tidb/issues/54415) @[lance6716](https://github.com/lance6716) - 厳密に自己増分ではないRANGEパーティションテーブルが作成できる問題を修正 [＃54829](https://github.com/pingcap/tidb/issues/54829) @[Defined2014](https://github.com/Defined2014) - `UNION`を含むクエリステートメントが誤った結果を返す可能性がある問題を修正しました [＃52985](https://github.com/pingcap/tidb/issues/52985) @[XuHuaiyu](https://github.com/XuHuaiyu) - SQLが異常中断されたときに`INDEX_HASH_JOIN`正常に終了できない問題を修正[＃54688](https://github.com/pingcap/tidb/issues/54688) @[wshwsh12](https://github.com/wshwsh12) @@ -68,7 +68,7 @@ TiDB バージョン: 7.5.4 - `StreamAggExec`分の`groupOffset`空の場合に TiDB がpanicを起こす可能性がある問題を修正しました [＃53867](https://github.com/pingcap/tidb/issues/53867) @[xzhangxian1008](https://github.com/xzhangxian1008) - copタスク構築中にTiDBクエリをキャンセルできない問題を修正[＃55957](https://github.com/pingcap/tidb/issues/55957) @[yibin87](https://github.com/yibin87) - 整数型の列に小さい表示幅が指定された場合、 `out of range`エラーが発生する可能性がある問題を修正しました。 [＃55837](https://github.com/pingcap/tidb/issues/55837) @[windtalker](https://github.com/windtalker) - - 一意インデックスを追加するときに`duplicate entry`発生する可能性がある問題を修正 [＃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) - `IMPORT INTO`文を使用して一時テーブルをインポートするときに TiDB がパニックになる問題を修正しました [＃55970](https://github.com/pingcap/tidb/issues/55970) @[D3Hunter](https://github.com/D3Hunter) - インデックス追加中の再試行によって発生するデータインデックスの不整合の問題を修正しました [＃55808](https://github.com/pingcap/tidb/issues/55808) @[lance6716](https://github.com/lance6716) diff --git a/releases/release-8.5.5.md b/releases/release-8.5.5.md index 387147522859a..35fc385ed30d7 100644 --- a/releases/release-8.5.5.md +++ b/releases/release-8.5.5.md @@ -95,7 +95,7 @@ TiDBバージョン：8.5.5 - 分散ジョブ`ADD INDEX`の同時実行性とスループットを動的に変更するサポート [#64947](https://github.com/pingcap/tidb/issues/64947) @[joechenrh](https://github.com/joechenrh) - TiDB バージョン v8.5.5 より前のバージョンでは、分散実行フレームワーク (DXF) [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)有効になっている場合、実行中の`THREAD`ジョブの`BATCH_SIZE` 、 `MAX_WRITE_SPEED` 、または`ADD INDEX`パラメータの変更はサポートされていません。これらのパラメータを変更するには、実行中の`ADD INDEX`ジョブをキャンセルし、パラメータを再構成してからジョブを再送信する必要がありますが、これは非効率的です。 + TiDB バージョン v8.5.5 より前のバージョンでは、分散実行フレームワーク (DXF) [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)が有効になっている場合、実行中の`THREAD`ジョブの`BATCH_SIZE` 、 `MAX_WRITE_SPEED` 、または`ADD INDEX`パラメータの変更はサポートされていません。これらのパラメータを変更するには、実行中の`ADD INDEX`ジョブをキャンセルし、パラメータを再構成してからジョブを再送信する必要がありますが、これは非効率的です。 バージョン8.5.5以降では、 `ADMIN ALTER DDL JOBS`ステートメントを使用して、実行中の分散`ADD INDEX`ジョブのこれらのパラメータを、ジョブを中断することなく、現在のワークロードとパフォーマンス要件に基づいて動的に調整できます。 diff --git a/sql-statements/sql-statement-show-collation.md b/sql-statements/sql-statement-show-collation.md index 6ff3a5be9f3f7..23c0e9de8af9c 100644 --- a/sql-statements/sql-statement-show-collation.md +++ b/sql-statements/sql-statement-show-collation.md @@ -9,7 +9,7 @@ summary: TiDB データベースの SHOW COLLATION の使用法の概要。 > **Note:** > -> [「新しい照合順序フレームワーク」](/character-set-and-collation.md#new-framework-for-collations)有効になっている場合、 `SHOW COLLATION`の結果は異なります。新しい照合順序フレームワークの詳細については、 [文字セットと照合順序](/character-set-and-collation.md)を参照してください。 +> [「新しい照合順序フレームワーク」](/character-set-and-collation.md#new-framework-for-collations)が有効になっている場合、 `SHOW COLLATION`の結果は異なります。新しい照合順序フレームワークの詳細については、 [文字セットと照合順序](/character-set-and-collation.md)を参照してください。 ## 概要 {#synopsis} diff --git a/temporary-tables.md b/temporary-tables.md index 2444d3f4cbbb5..67a0c69f2f911 100644 --- a/temporary-tables.md +++ b/temporary-tables.md @@ -138,7 +138,7 @@ TiDB ローカル一時テーブルの次の機能と制限は、MySQL 一時テ - ローカル一時テーブルを作成または削除すると、現在のトランザクションは自動的にコミットされません。 - ローカル一時テーブルが配置されているスキーマを削除した後も、一時テーブルは削除されず、引き続き読み取りおよび書き込み可能です。 -- ローカル一時テーブルの作成には権限`CREATE TEMPORARY TABLES`必要です。それ以降のテーブルに対する操作には権限は必要ありません。 +- ローカル一時テーブルの作成には権限`CREATE TEMPORARY TABLES`が必要です。それ以降のテーブルに対する操作には権限は必要ありません。 - ローカル一時テーブルは外部キーとパーティション化されたテーブルをサポートしません。 - ローカル一時テーブルに基づくビューの作成はサポートされていません。 - `SHOW [FULL] TABLES`の場合、ローカル一時テーブルは表示されません。 diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index 15f285fa516e3..9923e2679f315 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -407,7 +407,7 @@ Kafkaトピックは、受信できるメッセージのサイズに制限を設 large-message-handle-compression = "none" ``` -`large-message-handle-compression`有効になっている場合、コンシューマーが受信するメッセージは特定の圧縮プロトコルを使用してエンコードされ、コンシューマー アプリケーションは指定された圧縮プロトコルを使用してデータをデコードする必要があります。 +`large-message-handle-compression`が有効になっている場合、コンシューマーが受信するメッセージは特定の圧縮プロトコルを使用してエンコードされ、コンシューマー アプリケーションは指定された圧縮プロトコルを使用してデータをデコードする必要があります。 この機能は、Kafka プロデューサーの圧縮機能とは異なります。 diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md index c95b8aa595c09..b80eaf1fb5139 100644 --- a/tidb-cloud/migrate-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md @@ -742,7 +742,7 @@ GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX, CREATE VIEW ON - MySQLサーバーがクライアント証明書認証用に構成されている場合は、**Client Certificate**と**Client private key**をアップロードしてください。 - このオプションでは、 TiDB Cloudは認証のためにMySQLサーバーに証明書を提示しますが、 TiDB Cloudサーバーの証明書を検証しません。 - - このオプションは通常、MySQLサーバーが`REQUIRE SUBJECT '...'`や`REQUIRE ISSUER '...'`などのオプションで構成されているが、 `REQUIRE X509`含まれていない場合に使用され、クライアント証明書の完全な CA 検証を行わずに、クライアント証明書の特定の属性をチェックできるようにします。 + - このオプションは通常、MySQLサーバーが`REQUIRE SUBJECT '...'`や`REQUIRE ISSUER '...'`などのオプションで構成されているが、 `REQUIRE X509`が含まれていない場合に使用され、クライアント証明書の完全な CA 検証を行わずに、クライアント証明書の特定の属性をチェックできるようにします。 - このオプションは、MySQLサーバーが自己署名証明書またはカスタムPKI環境でクライアント証明書を受け入れる場合によく使用されます。ただし、この構成は中間者攻撃に対して脆弱であるため、他のネットワークレベルの制御によってサーバーの信頼性が保証されない限り、本番環境での本番は推奨されません。 - オプション3：相互TLS（mTLS） - 最高レベルのセキュリティ diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md index 68454da745e80..2bbaa653b1d9d 100644 --- a/tiup/tiup-cluster-no-sudo-mode.md +++ b/tiup/tiup-cluster-no-sudo-mode.md @@ -202,7 +202,7 @@ tiup cluster upgrade mycluster v8.2.0 ### <> の起動時に`Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.`エラーが発生します。 {#the-trying-to-run-as-user-instance-but-xdg-runtime-dir-is-not-set-error-occurs-when-starting-x3c-user-service} -この問題は、 `/etc/pam.d/system-auth.ued`ファイルに`pam_systemd.so`存在しないために発生する可能性があります。 +この問題は、 `/etc/pam.d/system-auth.ued`ファイルに`pam_systemd.so`が存在しないために発生する可能性があります。 この問題を解決するには、次のコマンドを使用して、 `/etc/pam.d/system-auth.ued`ファイルに`pam_systemd.so`モジュールが含まれているかどうかを確認します。含まれていない場合は、ファイルの末尾に`session optional pam_systemd.so`追加します。 From ea050b463ff5a1bc3957d51533c1f45274c52659 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 27 Aug 2026 10:13:18 +0900 Subject: [PATCH 2/5] =?UTF-8?q?i18n(ja):=20fix=20dropped=20=E3=81=8C=20par?= =?UTF-8?q?ticle=20before=20predicates=20(batch=202)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- br/br-monitoring-and-alert.md | 2 +- develop/dev-guide-connection-parameters.md | 2 +- global-indexes.md | 2 +- releases/release-2.1.10.md | 2 +- releases/release-2.1.19.md | 2 +- releases/release-5.1.4.md | 2 +- releases/release-5.3.0.md | 2 +- releases/release-5.4.0.md | 2 +- releases/release-6.1.7.md | 2 +- releases/release-6.5.6.md | 4 ++-- releases/release-7.1.4.md | 2 +- releases/release-7.1.6.md | 2 +- releases/release-7.4.0.md | 4 ++-- shard-row-id-bits.md | 2 +- sql-statements/sql-statement-load-data.md | 4 ++-- sql-statements/sql-statement-savepoint.md | 2 +- sync-diff-inspector/route-diff.md | 2 +- tidb-cloud/monitor-datadog-integration.md | 2 +- tidb-resource-control-ru-groups.md | 2 +- tiflash/tiflash-configuration.md | 2 +- tiproxy/troubleshoot-tiproxy.md | 2 +- tiup/tiup-cluster-topology-reference.md | 4 ++-- tune-region-performance.md | 2 +- 23 files changed, 27 insertions(+), 27 deletions(-) diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md index b78933f0d109e..a0236d230eadb 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -33,7 +33,7 @@ summary: このドキュメントでは、ログバックアップの監視、 | **tikv_log_backup_initial_scan_reason** | カウンタ | 初期スキャンがトリガーされた理由の統計。主な理由は、リーダーの交代またはリージョンバージョンの変更です。
`reason :: {"leader-changed", "region-changed", "retry"}` | | **tikv_log_backup_event_handle_duration_sec** | ヒストグラム | KVイベントの処理時間`tikv_log_backup_on_event_duration_seconds`と比較すると、この指標には内部変換の期間も含まれます。
`stage :: {"to_stream_event", "save_to_temp_file"}` | | **tikv_log_backup_handle_kv_batch** | ヒストグラム | Raftstoreによって送信された KV ペア バッチのサイズのリージョンレベルの統計。 | -| **tikv_log_backup_initial_scan_disk_read** | カウンタ | 初期スキャン中にディスクから読み取られたデータのサイズ。Linuxでは、この情報はprocfsから取得され、ブロックデバイスから実際に読み取られたデータのサイズです。このメトリックには、設定項目`initial-scan-rate-limit`適用されます。 | +| **tikv_log_backup_initial_scan_disk_read** | カウンタ | 初期スキャン中にディスクから読み取られたデータのサイズ。Linuxでは、この情報はprocfsから取得され、ブロックデバイスから実際に読み取られたデータのサイズです。このメトリックには、設定項目`initial-scan-rate-limit`が適用されます。 | | **tikv_log_backup_incremental_scan_bytes** | ヒストグラム | 初期スキャン中に実際に生成されたKVペアのサイズ。圧縮とリードアンプリフィケーションのため、この値は`tikv_log_backup_initial_scan_disk_read`と異なる場合があります。 | | **tikv_log_backup_skip_kv_count** | カウンタ | バックアップに役立たないため、ログバックアップ中にスキップされるRaftイベントの数。 | | **tikv_log_backup_errors** | カウンタ | ログバックアップ中に再試行または無視できるエラー。
`type :: ErrorType` | diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index 71eaf0ae2acba..d2468dc9f942d 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -225,7 +225,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 次のような場合は、この設定が小さすぎるかどうかを確認する必要があります。 - TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 - - そして、 `cachePrepStmts=true`設定されているが、 `COM_STMT_PREPARE`は依然として`COM_STMT_EXECUTE`とほぼ等しく、 `COM_STMT_CLOSE`存在することがわかった。 + - そして、 `cachePrepStmts=true`が設定されているが、 `COM_STMT_PREPARE`は依然として`COM_STMT_EXECUTE`とほぼ等しく、 `COM_STMT_CLOSE`が存在することがわかった。 - **prepStmtCacheSize** diff --git a/global-indexes.md b/global-indexes.md index ed441ea7ade1b..36f7eabbb3d6b 100644 --- a/global-indexes.md +++ b/global-indexes.md @@ -219,7 +219,7 @@ CREATE TABLE `sbtest` ( ### エンコード方法 {#encoding-method} -TiDBでは、インデックスエントリはキーと値のペアとしてエンコードされます。パーティションテーブルの場合、各パーティションはTiKVレイヤーで独立した物理テーブルとして扱われ、それぞれに`partitionID`設定されます。したがって、パーティションテーブルにおけるインデックスエントリのエンコードは次のようになります。 +TiDBでは、インデックスエントリはキーと値のペアとしてエンコードされます。パーティションテーブルの場合、各パーティションはTiKVレイヤーで独立した物理テーブルとして扱われ、それぞれに`partitionID`が設定されます。したがって、パーティションテーブルにおけるインデックスエントリのエンコードは次のようになります。 ``` Unique key diff --git a/releases/release-2.1.10.md b/releases/release-2.1.10.md index c59705f6f755e..ed9c9d6b1504a 100644 --- a/releases/release-2.1.10.md +++ b/releases/release-2.1.10.md @@ -31,7 +31,7 @@ TiDB Ansible バージョン: 2.1.10 - `PERIOD_ADD` のパラメータの有効性を確認する [＃10430](https://github.com/pingcap/tidb/pull/10430) - TiDBの無効な`YEAR`文字列の動作がMySQL と互換性がない問題を修正しました。 [＃10493](https://github.com/pingcap/tidb/pull/10493) - `ALTER DATABASE`構文サポートする [＃10503](https://github.com/pingcap/tidb/pull/10503) -- スロークエリステートメントに`;`存在しない場合に`SLOW_QUERY`メモリエンジンがエラーを報告する問題を修正しました [＃10536](https://github.com/pingcap/tidb/pull/10536) +- スロークエリステートメントに`;`が存在しない場合に`SLOW_QUERY`メモリエンジンがエラーを報告する問題を修正しました [＃10536](https://github.com/pingcap/tidb/pull/10536) - パーティションテーブルでの`Add index`がキャンセルできないことがある問題を修正[＃10533](https://github.com/pingcap/tidb/pull/10533) - OOM panic回復できないケースがある問題を修正[＃10545](https://github.com/pingcap/tidb/pull/10545) - テーブルメタデータを書き換えるDDL操作のセキュリティを強化する[＃10547](https://github.com/pingcap/tidb/pull/10547) diff --git a/releases/release-2.1.19.md b/releases/release-2.1.19.md index ba9a6909f379f..0897cd641962b 100644 --- a/releases/release-2.1.19.md +++ b/releases/release-2.1.19.md @@ -41,7 +41,7 @@ TiDB Ansible バージョン: 2.1.19 - パーティションテーブルで`ADMIN CHECK TABLE`実行をサポート [＃13143](https://github.com/pingcap/tidb/pull/13143) - 列属性として`ON UPDATE CURRENT_TIMESTAMP`を使用し、浮動小数点精度を指定した場合、 `SHOW CREATE TABLE`などのステートメントの精度が不完全になる問題を修正しました[＃12462](https://github.com/pingcap/tidb/pull/12462) - 列削除、修正、または変更するときに外部キーがチェックされないため、 `SELECT * FROM information_schema.KEY_COLUMN_USAGE`文の実行時にpanicが発生する問題を修正しました。 [＃14162](https://github.com/pingcap/tidb/pull/14162) - - TiDB で`Streaming`有効になっている場合に返されるデータが重複する可能性がある問題を修正しました [＃13255](https://github.com/pingcap/tidb/pull/13255) + - TiDB で`Streaming`が有効になっている場合に返されるデータが重複する可能性がある問題を修正しました [＃13255](https://github.com/pingcap/tidb/pull/13255) - 夏時間による`Invalid time format`エラーを修正 [＃13624](https://github.com/pingcap/tidb/pull/13624) - 整数を符号なし浮動小数点型または小数型に変換すると精度が失われ、データが正しくなくなる問題を修正[＃13756](https://github.com/pingcap/tidb/pull/13756) - `Quote`関数が`NULL`値処理するときに誤ったタイプの値が返される問題を修正しました [＃13681](https://github.com/pingcap/tidb/pull/13681) diff --git a/releases/release-5.1.4.md b/releases/release-5.1.4.md index e71e7052e49ef..8cccb1d9a5d29 100644 --- a/releases/release-5.1.4.md +++ b/releases/release-5.1.4.md @@ -138,7 +138,7 @@ TiDB バージョン: 5.1.4 - TiCDC - - `batch-replace-enable`無効になっている場合、MySQLシンクが重複した`replace` SQL文を生成するバグを修正[＃4501](https://github.com/pingcap/tiflow/issues/4501) + - `batch-replace-enable`が無効になっている場合、MySQLシンクが重複した`replace` SQL文を生成するバグを修正[＃4501](https://github.com/pingcap/tiflow/issues/4501) - `cached region`監視メトリックがマイナスになる問題を修正 [＃4300](https://github.com/pingcap/tiflow/issues/4300) - `min.insync.replicas` `replication-factor`より小さい場合にレプリケーションを実行できない問題を修正しました[＃3994](https://github.com/pingcap/tiflow/issues/3994) - レプリケーションタスクが削除されたときに発生する可能性のあるpanic問題を修正しました[＃3128](https://github.com/pingcap/tiflow/issues/3128) diff --git a/releases/release-5.3.0.md b/releases/release-5.3.0.md index 3a6b2526f2665..d5f37f5f342f3 100644 --- a/releases/release-5.3.0.md +++ b/releases/release-5.3.0.md @@ -421,7 +421,7 @@ TiCDC v5.3.0以降、TiDBクラスター間の循環レプリケーション機 - 下流の TiDB/MySQL の可用性を検証する際の不要な CPU 消費を修正[＃3073](https://github.com/pingcap/tiflow/issues/3073) - TiCDCによって生成されるKafkaメッセージの量が`max-message-size` に制限されない問題を修正 [＃2962](https://github.com/pingcap/tiflow/issues/2962) - Kafka メッセージの書き込み中にエラーが発生すると、TiCDC 同期タスクが一時停止する可能性がある問題を修正しました[＃2978](https://github.com/pingcap/tiflow/issues/2978) - - `force-replicate`有効になっているときに、有効なインデックスのない一部のパーティションテーブルが無視される可能性がある問題を修正[＃2834](https://github.com/pingcap/tiflow/issues/2834) + - `force-replicate`が有効になっているときに、有効なインデックスのない一部のパーティションテーブルが無視される可能性がある問題を修正[＃2834](https://github.com/pingcap/tiflow/issues/2834) - 株価データのスキャンに時間がかかりすぎると、TiKV が GC を実行するため株価データのスキャンが失敗する可能性がある問題を修正しました[＃2470](https://github.com/pingcap/tiflow/issues/2470) - 一部のタイプの列を Open Protocol 形式にエンコードするときに発生する可能性のあるpanic問題を修正しました。 [＃2758](https://github.com/pingcap/tiflow/issues/2758) - 一部のタイプの列をAvro形式にエンコードする際に発生する可能性のあるpanic問題を修正しました [＃2648](https://github.com/pingcap/tiflow/issues/2648) diff --git a/releases/release-5.4.0.md b/releases/release-5.4.0.md index 7854c01feeaf9..adc12ee1e8e88 100644 --- a/releases/release-5.4.0.md +++ b/releases/release-5.4.0.md @@ -41,7 +41,7 @@ TiDB バージョン: 5.4.0 | TiDB | [`stats-load-queue-size`](/tidb-configuration-file.md#stats-load-queue-size-new-in-v540) | 新しく追加された | TiDBの同期ロード統計機能がキャッシュできる列リクエストの最大数を制御します。デフォルト値は`1000`です。 | | TiKV | [`snap-generator-pool-size`](/tikv-configuration-file.md#snap-generator-pool-size-new-in-v540) | 新しく追加された | `snap-generator`スレッドプールのサイズ。デフォルト値は`2`です。 | | TiKV | `log.file.max-size` 、 `log.file.max-days` 、 `log.file.max-backups` | 新しく追加された | 詳細については、 [TiKVコンフィグレーションファイル - `log.file`](/tikv-configuration-file.md#logfile-new-in-v540)を参照してください。 | -| TiKV | `raft-engine` | 新しく追加された | `enable` 、 `dir` 、 `batch-compression-threshold` 、 `bytes-per-sync` 、 `target-file-size` 、 `purge-threshold` 、 `recovery-mode` 、 `recovery-read-block-size` 、 `recovery-read-block-size` 、および`recovery-threads`含まれます。詳細は、 [TiKVコンフィグレーションファイル - `raft-engine`](/tikv-configuration-file.md#raft-engine)を参照してください。 | +| TiKV | `raft-engine` | 新しく追加された | `enable` 、 `dir` 、 `batch-compression-threshold` 、 `bytes-per-sync` 、 `target-file-size` 、 `purge-threshold` 、 `recovery-mode` 、 `recovery-read-block-size` 、 `recovery-read-block-size` 、および`recovery-threads`が含まれます。詳細は、 [TiKVコンフィグレーションファイル - `raft-engine`](/tikv-configuration-file.md#raft-engine)を参照してください。 | | TiKV | [`backup.enable-auto-tune`](/tikv-configuration-file.md#enable-auto-tune-new-in-v540) | 新しく追加された | v5.3.0 では、デフォルト値は`false`です。v5.4.0 以降では、デフォルト値は`true`に変更されました。このパラメータは、クラスタのリソース使用率が高い場合に、バックアップタスクで使用されるリソースを制限してクラスタへの影響を軽減するかどうかを制御します。デフォルト設定では、バックアップタスクの速度が低下する可能性があります。 | | TiKV | `log-level` 、 `log-format` 、 `log-file` 、 `log-rotation-size` | 変更 | TiKV ログ パラメータの名前は、TiDB ログ パラメータと互換性のある名前`log.level` 、 `log.format` 、 `log.file.filename` 、および`log.enable-timestamp` 。古いパラメータのみを設定し、その値をデフォルト値以外に設定した場合、古いパラメータは新しいパラメータと互換性があります。古いパラメータと新しいパラメータの両方を設定した場合、新しいパラメータが有効になります。詳細については、[TiKVコンフィグレーションファイル - ログ](/tikv-configuration-file.md#log-new-in-v540)を参照してください。 | | TiKV | `log-rotation-timespan` | 削除済み | ログファイルのローテーション間隔。この間隔が経過すると、ログファイルがローテーションされます。これは、現在のログファイルのファイル名にタイムスタンプが追加され、新しいログファイルが作成されることを意味します。 | diff --git a/releases/release-6.1.7.md b/releases/release-6.1.7.md index 414e72ba4d58b..c87e50c376113 100644 --- a/releases/release-6.1.7.md +++ b/releases/release-6.1.7.md @@ -42,7 +42,7 @@ TiDB バージョン: 6.1.7 - リージョン分割中にパーティションテーブルをクエリするとエラーが発生する可能性がある問題を修正しました。 [＃43144](https://github.com/pingcap/tidb/issues/43144) @[lcwangchao](https://github.com/lcwangchao) - 統計情報読み取り中に不要なメモリが使用される問題を修正 [＃42052](https://github.com/pingcap/tidb/issues/42052) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) - 多数の空のパーティションテーブルを作成した後に過剰なメモリ使用が発生する問題を修正しました [＃44308](https://github.com/pingcap/tidb/issues/44308) @[hawkingrei](https://github.com/hawkingrei) - - `tidb_opt_agg_push_down`有効になっている場合にクエリが誤った結果を返す可能性がある問題を修正[＃44795](https://github.com/pingcap/tidb/issues/44795) @[AilinKid](https://github.com/AilinKid) + - `tidb_opt_agg_push_down`が有効になっている場合にクエリが誤った結果を返す可能性がある問題を修正[＃44795](https://github.com/pingcap/tidb/issues/44795) @[AilinKid](https://github.com/AilinKid) - 共通テーブル式の結合結果が間違っている可能性がある問題を修正[＃38170](https://github.com/pingcap/tidb/issues/38170) @[wjhuang2016](https://github.com/wjhuang2016) - GC がロックを解決するときに、まれに悲観的トランザクションの残余悲観的ロックがデータの正確性に影響を与える可能性がある問題を修正しました。 [＃43243](https://github.com/pingcap/tidb/issues/43243) @[MyonKeminta](https://github.com/MyonKeminta) - キャッシュテーブルに新しい列が追加された後、列のデフォルト値ではなく値が`NULL`なる問題を修正しました。 [＃42928](https://github.com/pingcap/tidb/issues/42928) @[lqs](https://github.com/lqs) diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index b41db21f858dc..2b7234de0bb0f 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -59,7 +59,7 @@ TiDB バージョン: 6.5.6 - TiDB - HashJoin演算子がプローブを実行するときにチャンクを再利用できない問題を修正しました [＃48082](https://github.com/pingcap/tidb/issues/48082) @[wshwsh12](https://github.com/wshwsh12) - - `AUTO_ID_CACHE=1` に設定されている場合に`Duplicate entry`発生する可能性がある問題を修正しました [＃46444](https://github.com/pingcap/tidb/issues/46444) @[tiancaiamao](https://github.com/tiancaiamao) + - `AUTO_ID_CACHE=1` に設定されている場合に`Duplicate entry`が発生する可能性がある問題を修正しました [＃46444](https://github.com/pingcap/tidb/issues/46444) @[tiancaiamao](https://github.com/tiancaiamao) - 2つのサブクエリを結合するときに`TIDB_INLJ`ヒントが有効にならない問題を修正しました [＃46160](https://github.com/pingcap/tidb/issues/46160) @[qw4990](https://github.com/qw4990) - TiDB の再起動後に DDL 操作が停止する可能性がある問題を修正[＃46751](https://github.com/pingcap/tidb/issues/46751) @[wjhuang2016](https://github.com/wjhuang2016) - 不正なMDL処理によりDDL操作が永続的にブロックされる可能性がある問題を修正 [＃46920](https://github.com/pingcap/tidb/issues/46920) @[wjhuang2016](https://github.com/wjhuang2016) @@ -79,7 +79,7 @@ TiDB バージョン: 6.5.6 - `N` in `LIMIT N` という大きすぎる数値による誤ったコスト見積りを修正 [＃43285](https://github.com/pingcap/tidb/issues/43285) @[qw4990](https://github.com/qw4990) - 統計 TopN 構造を構築するときに発生する可能性のあるpanic問題を修正しました。 [＃35948](https://github.com/pingcap/tidb/issues/35948) @[Rustin170506](https://github.com/Rustin170506) - MPPで計算された`COUNT(INT)`の結果が正しくない可能性がある問題を修正[＃48643](https://github.com/pingcap/tidb/issues/48643) @[AilinKid](https://github.com/AilinKid) - - `tidb_enable_ordered_result_mode`有効になっているときにpanicが発生する可能性がある問題を修正[＃45044](https://github.com/pingcap/tidb/issues/45044) @[qw4990](https://github.com/qw4990) + - `tidb_enable_ordered_result_mode`が有効になっているときにpanicが発生する可能性がある問題を修正[＃45044](https://github.com/pingcap/tidb/issues/45044) @[qw4990](https://github.com/qw4990) - ウィンドウ関数によって導入されたソートを削減するために、オプティマイザが誤って IndexFullScan を選択する問題を修正しました。 [＃46177](https://github.com/pingcap/tidb/issues/46177) @[qw4990](https://github.com/qw4990) - 述語が共通テーブル式にプッシュダウンされたときに結果が不正確になる可能性がある問題を修正しました [＃47881](https://github.com/pingcap/tidb/issues/47881) @[winoros](https://github.com/winoros) - DUALテーブルを最初のサブノードとして`UNION ALL`を実行するとエラーが発生する可能性がある問題を修正しました。 [＃48755](https://github.com/pingcap/tidb/issues/48755) @[winoros](https://github.com/winoros) diff --git a/releases/release-7.1.4.md b/releases/release-7.1.4.md index 632ca8585168f..ed1f3f69d40b1 100644 --- a/releases/release-7.1.4.md +++ b/releases/release-7.1.4.md @@ -126,7 +126,7 @@ TiDBバージョン: 7.1.4 - リソースグループ クライアントでスロットが完全に削除されず、割り当てられたトークンの数が指定された値より少なくなる問題を修正しました。 [＃7346](https://github.com/tikv/pd/issues/7346) @[guo-shaoge](https://github.com/guo-shaoge) - 一部のTSOログでエラー原因が出力されない問題を修正しました [＃7496](https://github.com/tikv/pd/issues/7496) @[CabinfeverB](https://github.com/CabinfeverB) - - `BURSTABLE`有効になっているときにデフォルトのリソースグループに不要なトークンが蓄積される問題を修正[＃7206](https://github.com/tikv/pd/issues/7206) @[CabinfeverB](https://github.com/CabinfeverB) + - `BURSTABLE`が有効になっているときにデフォルトのリソースグループに不要なトークンが蓄積される問題を修正[＃7206](https://github.com/tikv/pd/issues/7206) @[CabinfeverB](https://github.com/CabinfeverB) - `evict-leader-scheduler`インターフェースが呼び出されたときに出力がない問題を修正しました [＃7672](https://github.com/tikv/pd/issues/7672) @[CabinfeverB](https://github.com/CabinfeverB) - `watch etcd`正しくオフになっていない場合に発生するメモリリークの問題を修正[＃7807](https://github.com/tikv/pd/issues/7807) @[rleungx](https://github.com/rleungx) - `MergeLabels`関数が呼び出されたときにデータ競合が発生する問題を修正しました [＃7535](https://github.com/tikv/pd/issues/7535) @[lhy1024](https://github.com/lhy1024) diff --git a/releases/release-7.1.6.md b/releases/release-7.1.6.md index e09042d1ac0ee..2f11d5d4b2f64 100644 --- a/releases/release-7.1.6.md +++ b/releases/release-7.1.6.md @@ -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番目の引数が負の場合に`TIMESTAMPADD()`関数が無限ループに入る問題を修正しました。 [＃54908](https://github.com/pingcap/tidb/issues/54908) @[xzhangxian1008](https://github.com/xzhangxian1008) - `tidb_mem_quota_analyze`が有効になっていて、統計の更新に使用されるメモリがの制限を超えると、TiDB がクラッシュする可能性がある問題を修正しました。 [＃52601](https://github.com/pingcap/tidb/issues/52601) @[hawkingrei](https://github.com/hawkingrei) - - 一意インデックスを追加するときに`duplicate entry`発生する可能性がある問題を修正 [＃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) - 情報スキーマキャッシュミスにより、古い読み取りのクエリレイテンシーが増加する問題を修正しました。 [＃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 2c8ff30143943..73b15031ef2db 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -353,7 +353,7 @@ TiDB バージョン: 7.4.0 - `tidb_enforce_mpp`システム変数が正しく復元できない問題を修正[＃46214](https://github.com/pingcap/tidb/issues/46214) @[djshow832](https://github.com/djshow832) - `LIKE`述語の`_`が誤って処理される問題を修正[＃46287](https://github.com/pingcap/tidb/issues/46287) [＃46618](https://github.com/pingcap/tidb/issues/46618) @[Defined2014](https://github.com/Defined2014) - TiDBがスキーマを取得できなかった場合に`schemaTs`が0に設定される問題を修正しました [＃46325](https://github.com/pingcap/tidb/issues/46325) @[hihihuhu](https://github.com/hihihuhu) - - `AUTO_ID_CACHE=1` に設定されている場合に`Duplicate entry`発生する可能性がある問題を修正しました [＃46444](https://github.com/pingcap/tidb/issues/46444) @[tiancaiamao](https://github.com/tiancaiamao) + - `AUTO_ID_CACHE=1` に設定されている場合に`Duplicate entry`が発生する可能性がある問題を修正しました [＃46444](https://github.com/pingcap/tidb/issues/46444) @[tiancaiamao](https://github.com/tiancaiamao) - `AUTO_ID_CACHE=1` に設定されている場合に、panic後に TiDB がゆっくりと回復する問題を修正しました。 [＃46454](https://github.com/pingcap/tidb/issues/46454) @[tiancaiamao](https://github.com/tiancaiamao) - `AUTO_ID_CACHE=1` に設定されている場合に`next_row_id` in `SHOW CREATE TABLE`が間違っている問題を修正しました [＃46545](https://github.com/pingcap/tidb/issues/46545) @[tiancaiamao](https://github.com/tiancaiamao) - サブクエリで CTE を使用すると解析中に発生するpanic問題を修正しました [＃45838](https://github.com/pingcap/tidb/issues/45838) @[djshow832](https://github.com/djshow832) @@ -387,7 +387,7 @@ TiDB バージョン: 7.4.0 - `sync_recovery`から`sync` に切り替えた後に QPS が 0 に低下する問題を修正しました [＃15366](https://github.com/tikv/tikv/issues/15366) @[nolouch](https://github.com/nolouch) - オンラインアンセーフリカバリがタイムアウトで中止されない問題を修正 [＃15346](https://github.com/tikv/tikv/issues/15346) @[Connor1996](https://github.com/Connor1996) - CpuRecord によって発生する潜在的なメモリリークの問題を修正しました [＃15304](https://github.com/tikv/tikv/issues/15304) @[overvenus](https://github.com/overvenus) - - バックアップクラスタがダウンし、プライマリクラスタがクエリされたときに`"Error 9002: TiKV server timeout"`発生する問題を修正しました [＃12914](https://github.com/tikv/tikv/issues/12914) @[Connor1996](https://github.com/Connor1996) + - バックアップクラスタがダウンし、プライマリクラスタがクエリされたときに`"Error 9002: TiKV server timeout"`が発生する問題を修正しました [＃12914](https://github.com/tikv/tikv/issues/12914) @[Connor1996](https://github.com/Connor1996) - プライマリクラスタが回復した後に TiKV が再起動するとバックアップ TiKV が停止する問題を修正しました [＃12320](https://github.com/tikv/tikv/issues/12320) @[disksing](https://github.com/disksing) - PD diff --git a/shard-row-id-bits.md b/shard-row-id-bits.md index 633aa8292ad79..cf9087edd5836 100644 --- a/shard-row-id-bits.md +++ b/shard-row-id-bits.md @@ -28,7 +28,7 @@ summary: SHARD_ROW_ID_BITS属性について学びましょう。 > **Warning:** > -> `_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)を参照してください。 > **Note:** > diff --git a/sql-statements/sql-statement-load-data.md b/sql-statements/sql-statement-load-data.md index 8246157113aa1..b539990a69135 100644 --- a/sql-statements/sql-statement-load-data.md +++ b/sql-statements/sql-statement-load-data.md @@ -190,7 +190,7 @@ IGNORE 1 LINES; > - TiDB v4.0.0 より前のバージョンでは、20000 行ごとに`LOAD DATA`コミットが実行され、これは構成できません。 > - TiDB v4.0.0 から v6.6.0 までのバージョンでは、TiDB はデフォルトですべての行を 1つのトランザクションでコミットします。ただし、 `LOAD DATA`ステートメントで一定数の行をコミットする必要がある場合は、必要な行数を[`tidb_dml_batch_size`](/system-variables.md#tidb_dml_batch_size)に設定できます。 > - TiDB v7.0.0 以降では、 `tidb_dml_batch_size` `LOAD DATA`には影響しなくなり、TiDB は 1つのトランザクションですべての行をコミットします。 -> - TiDB v4.0.0 以前のバージョンからアップグレードすると、 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058`発生する場合があります。このエラーを解決するには、 `tidb.toml`ファイルの[`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit)値を増やすことをお勧めします。 +> - TiDB v4.0.0 以前のバージョンからアップグレードすると、 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058`が発生する場合があります。このエラーを解決するには、 `tidb.toml`ファイルの[`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit)値を増やすことをお勧めします。 > - TiDB v7.6.0 より前のバージョンでは、トランザクションでコミットされる行数に関係なく、明示的なトランザクションの[`ROLLBACK`](/sql-statements/sql-statement-rollback.md)ステートメントによって`LOAD DATA`ロールバックされることはありません。 > - TiDB v7.6.0 より前のバージョンでは、TiDB トランザクションモードの構成に関係なく、 `LOAD DATA`ステートメントは常に楽観的トランザクションモードで実行されます。 > - v7.6.0 以降、TiDB は他の DML ステートメントと同じ方法で`LOAD DATA` in トランザクションを処理します。 @@ -207,7 +207,7 @@ IGNORE 1 LINES; > - TiDB v4.0.0 より前のバージョンでは、20000 行ごとに`LOAD DATA`コミットが実行され、これは構成できません。 > - TiDB v4.0.0 から v6.6.0 までのバージョンでは、TiDB はデフォルトですべての行を 1つのトランザクションでコミットします。ただし、 `LOAD DATA`ステートメントで一定数の行をコミットする必要がある場合は、必要な行数を[`tidb_dml_batch_size`](/system-variables.md#tidb_dml_batch_size)に設定できます。 > - v7.0.0 以降、 `tidb_dml_batch_size` `LOAD DATA`には影響しなくなり、 TiDB は 1つのトランザクションですべての行をコミットします。 -> - TiDB v4.0.0以前のバージョンからアップグレードすると、 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058`発生する場合があります。このエラーを解決するには、 [TiDB Cloudサポート](https://docs.pingcap.com/tidbcloud/tidb-cloud-support)連絡して[`txn-total-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-total-size-limit)値を増やすことができます。 +> - TiDB v4.0.0以前のバージョンからアップグレードすると、 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058`が発生する場合があります。このエラーを解決するには、 [TiDB Cloudサポート](https://docs.pingcap.com/tidbcloud/tidb-cloud-support)連絡して[`txn-total-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-total-size-limit)値を増やすことができます。 > - TiDB v7.6.0 より前のバージョンでは、トランザクションでコミットされる行数に関係なく、明示的なトランザクションの[`ROLLBACK`](/sql-statements/sql-statement-rollback.md)ステートメントによって`LOAD DATA`ロールバックされることはありません。 > - TiDB v7.6.0 より前のバージョンでは、TiDB トランザクションモードの構成に関係なく、 `LOAD DATA`ステートメントは常に楽観的トランザクションモードで実行されます。 > - v7.6.0 以降、TiDB は他の DML ステートメントと同じ方法で`LOAD DATA` in トランザクションを処理します。 diff --git a/sql-statements/sql-statement-savepoint.md b/sql-statements/sql-statement-savepoint.md index b9c86edcfa79d..fb6edc2ec2afe 100644 --- a/sql-statements/sql-statement-savepoint.md +++ b/sql-statements/sql-statement-savepoint.md @@ -15,7 +15,7 @@ RELEASE SAVEPOINT identifier > **Warning:** > -> [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630)無効になっている場合、悲観的トランザクションで`SAVEPOINT`を使用することはできません。 +> [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630)が無効になっている場合、悲観的トランザクションで`SAVEPOINT`を使用することはできません。 - `SAVEPOINT` 、現在のトランザクションに指定された名前のセーブポイントを設定するために使用されます。同じ名前のセーブポイントが既に存在する場合、それは削除され、同じ名前の新しいセーブポイントが設定されます。 diff --git a/sync-diff-inspector/route-diff.md b/sync-diff-inspector/route-diff.md index 98e0400a5768d..9662e848865db 100644 --- a/sync-diff-inspector/route-diff.md +++ b/sync-diff-inspector/route-diff.md @@ -78,7 +78,7 @@ target-table = "t_2" # The name of the target table - アップストリームにスキーマ`schema`があり、ルールがスキーマに一致する場合、sync-diff-inspector は何も行いません。 - アップストリームにスキーマ`schema`が存在するものの、それに一致するルールがない場合、sync-diff-inspector はテーブルルーターに新しいルール`schema -> _no__exists__db_`追加します。その後、sync-diff-inspector はテーブル`schema`をテーブル`_no__exists__db_`として扱います。 -- ルールに`target-schema.target-table`存在しない場合は、テーブル ルーターが大文字と小文字を区別しないため、sync-diff-inspector は`target-schema.target-table`から`target-schema.target-table`に一致するルールを追加して大文字と小文字を区別しないようにします。 +- ルールに`target-schema.target-table`が存在しない場合は、テーブル ルーターが大文字と小文字を区別しないため、sync-diff-inspector は`target-schema.target-table`から`target-schema.target-table`に一致するルールを追加して大文字と小文字を区別しないようにします。 ### 例 {#examples} diff --git a/tidb-cloud/monitor-datadog-integration.md b/tidb-cloud/monitor-datadog-integration.md index 30723b203bca3..efb11704b1e38 100644 --- a/tidb-cloud/monitor-datadog-integration.md +++ b/tidb-cloud/monitor-datadog-integration.md @@ -24,7 +24,7 @@ TiDB Cloudは、2022年3月4日よりプロジェクトレベルのDatadog統合 ## 前提条件 {#prerequisites} -- TiDB CloudをDatadogと連携させるには、Datadogアカウントと[Datadog APIキー](https://app.datadoghq.com/organization-settings/api-keys)必要です。Datadogアカウントを初めて作成すると、DatadogからAPIキーが発行されます。 +- TiDB CloudをDatadogと連携させるには、Datadogアカウントと[Datadog APIキー](https://app.datadoghq.com/organization-settings/api-keys)が必要です。Datadogアカウントを初めて作成すると、DatadogからAPIキーが発行されます。 Datadogアカウントをお持ちでない場合は、 [https://app.datadoghq.com/signup](https://app.datadoghq.com/signup)でサインアップしてください。 diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index 22e13176b0ca8..1886114399cb4 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -107,7 +107,7 @@ TiDB v7.0.0以降、 `tidb_enable_resource_control`と`resource-control.enabled` -バージョン7.4.0以降、 TiFlash構成項目`enable_resource_control`はデフォルトで有効になっています。これは`tidb_enable_resource_control`と連携してTiFlash制御機能を制御します。TiFlashリソース制御は、 `enable_resource_control`と`tidb_enable_resource_control`の両方が有効になっている場合にのみ、フロー制御と優先度スケジューリングを実行します。さらに、 `enable_resource_control`有効になっている場合、 TiFlashは[パイプライン実行モデル](http://docs.pingcap.com/tidb/dev/tiflash-pipeline-model)を使用します。 +バージョン7.4.0以降、 TiFlash構成項目`enable_resource_control`はデフォルトで有効になっています。これは`tidb_enable_resource_control`と連携してTiFlash制御機能を制御します。TiFlashリソース制御は、 `enable_resource_control`と`tidb_enable_resource_control`の両方が有効になっている場合にのみ、フロー制御と優先度スケジューリングを実行します。さらに、 `enable_resource_control`が有効になっている場合、 TiFlashは[パイプライン実行モデル](http://docs.pingcap.com/tidb/dev/tiflash-pipeline-model)を使用します。 diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 5999f0131c881..07dcf4eafb9ed 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -473,7 +473,7 @@ I/O トラフィック制限設定を構成します。 ##### `ca_path` {#ca_path} -- 信頼できるSSL CAのリストを含むファイルのパス。設定する場合は、 [`cert_path`](#cert_path)と[`key_path`](#key_path)必要です。 +- 信頼できるSSL CAのリストを含むファイルのパス。設定する場合は、 [`cert_path`](#cert_path)と[`key_path`](#key_path)が必要です。 diff --git a/tiproxy/troubleshoot-tiproxy.md b/tiproxy/troubleshoot-tiproxy.md index 6ca4effb7836b..2fe3bda505928 100644 --- a/tiproxy/troubleshoot-tiproxy.md +++ b/tiproxy/troubleshoot-tiproxy.md @@ -17,7 +17,7 @@ summary: TiProxy の一般的な問題、原因、および解決策について 4. クライアントが`Verify TiDB capability failed, please upgrade TiDB`報告する場合は、TiDBサーバーのバージョンが v6.5.0 以降であるかどうかを確認します。 5. クライアントが`TiProxy fails to connect to TiDB, please make sure TiDB is available`報告した場合は、 TiProxy ノードが TiDBサーバーに接続できるかどうかを確認します。 6. クライアントが`Require TLS enabled on TiDB when require-backend-tls=true`報告する場合は、TiDB が TLS 証明書で正しく構成されているかどうかを確認します。 -7. クライアントが`TiProxy fails to connect to TiDB, please make sure TiDB proxy-protocol is set correctly`報告した場合は、 TiProxy で[`proxy.proxy-protocol`](/tiproxy/tiproxy-configuration.md#proxy-protocol)有効になっているかどうか、 TiDBサーバーで[`proxy-protocol`](/tidb-configuration-file.md#proxy-protocol)有効になっていないかどうかを確認します。 +7. クライアントが`TiProxy fails to connect to TiDB, please make sure TiDB proxy-protocol is set correctly`報告した場合は、 TiProxy で[`proxy.proxy-protocol`](/tiproxy/tiproxy-configuration.md#proxy-protocol)が有効になっているかどうか、 TiDBサーバーで[`proxy-protocol`](/tidb-configuration-file.md#proxy-protocol)が有効になっていないかどうかを確認します。 8. TiProxy が[`max-connections`](/tiproxy/tiproxy-configuration.md#max-connections)に設定されており、TiProxy 上の接続数が最大接続制限を超えているかどうかを確認します。 9. TiProxy ログでエラーメッセージを確認してください。 diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index 52b0070ee3fe2..8d74195ac8fa1 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -46,7 +46,7 @@ TiUPを使用した TiDB デプロイメントのトポロジ構成ファイル - `enable_tls` : クラスタでTLSを有効にするかどうかを指定します。TLSを有効にすると、生成されたTLS証明書はコンポーネント間またはクライアントとコンポーネント間の接続に使用する必要があります。デフォルト値は`false`です。 -- `listen_host` : デフォルトのリスニングIPアドレスを指定します。空の場合、各インスタンスは、 `host`フィールドに`:`含まれているかどうかに基づいて、自動的に`::`または`0.0.0.0`に設​​定します。このフィールドはtiup-cluster v1.14.0で導入されました。 +- `listen_host` : デフォルトのリスニングIPアドレスを指定します。空の場合、各インスタンスは、 `host`フィールドに`:`が含まれているかどうかに基づいて、自動的に`::`または`0.0.0.0`に設​​定します。このフィールドはtiup-cluster v1.14.0で導入されました。 - `deploy_dir` : 各コンポーネントの配置ディレクトリ。デフォルト値は`"deployed"`です。適用ルールは以下のとおりです。 @@ -174,7 +174,7 @@ server_configs: `component_versions`は、特定のコンポーネントのバージョン番号を指定するために使用されます。 - `component_versions`が設定されていない場合、各コンポーネントはTiDB クラスターと同じバージョン番号 (PD や TiKV など) を使用するか、最新バージョン (Alertmanager など) を使用します。 -- `component_versions`設定されている場合、対応するコンポーネントは指定されたバージョンを使用し、このバージョンは後続のクラスターのスケーリングおよびアップグレード操作で使用されます。 +- `component_versions`が設定されている場合、対応するコンポーネントは指定されたバージョンを使用し、このバージョンは後続のクラスターのスケーリングおよびアップグレード操作で使用されます。 特定のバージョンのコンポーネントを使用する必要がある場合にのみ構成するようにしてください。 diff --git a/tune-region-performance.md b/tune-region-performance.md index daac54f085909..cdd0ece62f785 100644 --- a/tune-region-performance.md +++ b/tune-region-performance.md @@ -11,7 +11,7 @@ summary: リージョンサイズを調整してリージョンのパフォー TiKVは自動的に[最下層のデータを分割する](/best-practices/tidb-best-practices.md#data-sharding)データをキー範囲に基づいて複数のリージョンに分割します。リージョンのサイズがしきい値を超えると、TiKVはそれを2つ以上のリージョンに分割します。 -大規模なデータセットが関係するシナリオでは、リージョンサイズが比較的小さい場合、TiKV のリージョンが多すぎる可能性があり、リソースの消費量が増加し、 [パフォーマンスの回帰](/best-practices/massive-regions-best-practices.md#performance-problem)発生します。 +大規模なデータセットが関係するシナリオでは、リージョンサイズが比較的小さい場合、TiKV のリージョンが多すぎる可能性があり、リソースの消費量が増加し、 [パフォーマンスの回帰](/best-practices/massive-regions-best-practices.md#performance-problem)が発生します。 > **Note:** > From 00bce58fde3ea31e87e0aac1caf6a282d58988f5 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 27 Aug 2026 10:14:33 +0900 Subject: [PATCH 3/5] =?UTF-8?q?i18n(ja):=20fix=20dropped=20=E3=81=8C=20par?= =?UTF-8?q?ticle=20before=20predicates=20(batch=203)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- br/br-auto-tune.md | 2 +- check-before-deployment.md | 2 +- develop/dev-guide-sample-application-python-sqlalchemy.md | 2 +- functions-and-operators/tidb-functions.md | 2 +- releases/release-2.1.2.md | 2 +- releases/release-3.0-ga.md | 2 +- releases/release-4.0.0-beta.1.md | 2 +- releases/release-4.0.0-beta.2.md | 2 +- releases/release-5.2.2.md | 2 +- releases/release-5.3.1.md | 6 +++--- releases/release-5.4.1.md | 6 +++--- releases/release-6.1.0.md | 2 +- releases/release-7.1.1.md | 4 ++-- releases/release-7.5.1.md | 2 +- releases/release-7.5.5.md | 2 +- schedule-replicas-by-topology-labels.md | 2 +- sql-statements/sql-statement-explain.md | 4 ++-- sql-statements/sql-statement-modify-column.md | 2 +- tidb-external-ts.md | 2 +- tiflash/use-tiflash-mpp-mode.md | 2 +- tikv-control.md | 2 +- troubleshoot-cpu-issues.md | 2 +- 22 files changed, 28 insertions(+), 28 deletions(-) diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md index 2bafe8ebdabda..fe49230465a26 100644 --- a/br/br-auto-tune.md +++ b/br/br-auto-tune.md @@ -13,7 +13,7 @@ TiDB v5.4.0より前のバージョンでは、バックアップ＆リストア バックアップタスクがクラスタに与える影響を軽減したい場合は、自動チューニング機能を有効にできます。この機能を有効にすると、TiDBはクラスタに過度の影響を与えることなく、可能な限り高速にバックアップタスクを実行します。 -あるいは、TiKV設定項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)またはパラメータ`--ratelimit`を使用してバックアップ速度を制限することもできます。 `--ratelimit`設定されている場合、タスクが多すぎて速度制限を超えてしまうのを防ぐため、br のパラメータ`concurrency`自動的に`1`に調整されます。 +あるいは、TiKV設定項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)またはパラメータ`--ratelimit`を使用してバックアップ速度を制限することもできます。 `--ratelimit`が設定されている場合、タスクが多すぎて速度制限を超えてしまうのを防ぐため、br のパラメータ`concurrency`自動的に`1`に調整されます。 ## オートチューンを使用する {#use-auto-tune} diff --git a/check-before-deployment.md b/check-before-deployment.md index d94a31d234787..8cc29f554dd2a 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -153,7 +153,7 @@ TiDBの一部の操作では、サーバーへの一時ファイルの書き込 > **Note:** > - > ディレクトリが存在しない場合は、TiDB は起動時に自動的に作成します。ディレクトリの作成に失敗した場合、または TiDB がそのディレクトリに対する読み取りおよび書き込み権限を持っていない場合、実行時に[`Fast Online DDL`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)無効になります。 + > ディレクトリが存在しない場合は、TiDB は起動時に自動的に作成します。ディレクトリの作成に失敗した場合、または TiDB がそのディレクトリに対する読み取りおよび書き込み権限を持っていない場合、実行時に[`Fast Online DDL`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)が無効になります。 ## 対象マシンのファイアウォールサービスを確認する {#check-the-firewall-service-of-target-machines} diff --git a/develop/dev-guide-sample-application-python-sqlalchemy.md b/develop/dev-guide-sample-application-python-sqlalchemy.md index 85d5934d9b41f..5df7fd8b0ebbe 100644 --- a/develop/dev-guide-sample-application-python-sqlalchemy.md +++ b/develop/dev-guide-sample-application-python-sqlalchemy.md @@ -67,7 +67,7 @@ SQLAlchemyは、複数のデータベースを扱うORMライブラリです。 > **Note:** > -> 現在、 TiDB Cloud Starterインスタンスには制限があります。5分間アクティブな接続がない場合、インスタンスはシャットダウンし、すべての接続が閉じられます。そのため、 TiDB Cloud Starterインスタンスで SQLAlchemy を使用する場合、プールされた接続で`OperationalError`のような`Lost connection to MySQL server during query`や`MySQL Connection not available`発生する可能性があります。このエラーを回避するには、 `pool_recycle`パラメータを`300`に設定してください。詳細については、SQLAlchemy ドキュメントの[接続切れへの対処](https://docs.sqlalchemy.org/en/20/core/pooling.html#dealing-with-disconnects)を参照してください。 +> 現在、 TiDB Cloud Starterインスタンスには制限があります。5分間アクティブな接続がない場合、インスタンスはシャットダウンし、すべての接続が閉じられます。そのため、 TiDB Cloud Starterインスタンスで SQLAlchemy を使用する場合、プールされた接続で`OperationalError`のような`Lost connection to MySQL server during query`や`MySQL Connection not available`が発生する可能性があります。このエラーを回避するには、 `pool_recycle`パラメータを`300`に設定してください。詳細については、SQLAlchemy ドキュメントの[接続切れへの対処](https://docs.sqlalchemy.org/en/20/core/pooling.html#dealing-with-disconnects)を参照してください。 1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index cc309705c21fd..d342cb9085694 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -272,7 +272,7 @@ ORDER BY 4 rows in set (0.031 sec) ``` -`TIDB_DECODE_KEY`成功した場合は有効な JSON を返し、デコードに失敗した場合は引数の値を返します。 +`TIDB_DECODE_KEY`が成功した場合は有効な JSON を返し、デコードに失敗した場合は引数の値を返します。 ## TIDB_DECODE_PLAN {#tidb_decode_plan} diff --git a/releases/release-2.1.2.md b/releases/release-2.1.2.md index 9a8c7f8e0fd18..fd1e642c358c4 100644 --- a/releases/release-2.1.2.md +++ b/releases/release-2.1.2.md @@ -32,7 +32,7 @@ summary: TiDB 2.1.2およびTiDB Ansible 2.1.2は、2018年12月22日にリリ - TiDB Lightning - Lightning でサポートされる最小のクラスタバージョンを TiDB 2.1.0 にする - Lightning で解析された`JSON`データを含むファイルのコンテンツエラーを修正しました [＃144](https://github.com/pingcap/tidb-tools/issues/144) - - チェックポイントを使用してLightningを再起動した後に`Too many open engines`発生する問題を修正しました + - チェックポイントを使用してLightningを再起動した後に`Too many open engines`が発生する問題を修正しました - TiDB Binlog - Drainer がKafka にデータを書き込む際のボトルネックを解消 - TiDB Binlogの Kafka バージョンをサポート diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index bc9a493365437..379dd54c0fa72 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -18,7 +18,7 @@ TiDB Ansible バージョン: 3.0.0 - 安定性。TiDB 3.0 は、最大 150 以上のノードと 300 TB 以上のストレージを備えた大規模クラスターで長期的な安定性を実証しています。 - 使いやすさ。TiDB 3.0 では、標準化されたスロークエリログ、十分に開発されたログファイル仕様、ユーザーの操作コストを削減する`EXPLAIN ANALYZE`や SQL トレースなどの新機能など、使いやすさが多面的に向上しています。 - パフォーマンス。TiDB 3.0のパフォーマンスは、TPC-CベンチマークではTiDB 2.1の4.5倍、Sysbenchベンチマークでは1.5倍以上です。Viewsのサポートにより、TPC-H 50G Q15は正常に動作できるようになりました。 -- 新しい機能には、ウィンドウ関数、ビュー (**Experimental**)、パーティションテーブル、プラグインフレームワーク、悲観的ロック (**Experimental**)、および`SQL Plan Management`含まれます。 +- 新しい機能には、ウィンドウ関数、ビュー (**Experimental**)、パーティションテーブル、プラグインフレームワーク、悲観的ロック (**Experimental**)、および`SQL Plan Management`が含まれます。 ## TiDB {#tidb} diff --git a/releases/release-4.0.0-beta.1.md b/releases/release-4.0.0-beta.1.md index 2871a7a0ef17e..8c6a91a7515dd 100644 --- a/releases/release-4.0.0-beta.1.md +++ b/releases/release-4.0.0-beta.1.md @@ -80,7 +80,7 @@ TiDB Ansible バージョン: 4.0.0-beta.1 - TiDB - 64文字を超える列名で`view`を作成するとエラーが報告される問題を修正しました[＃14850](https://github.com/pingcap/tidb/pull/14850) - `create or replace view`文が正しく処理されていないため、 `information_schema.views`に重複データが存在する問題を修正[＃14832](https://github.com/pingcap/tidb/pull/14832) - - `plan cache`有効になっている場合の`BatchPointGet`の誤った結果を修正[＃14855](https://github.com/pingcap/tidb/pull/14855) + - `plan cache`が有効になっている場合の`BatchPointGet`の誤った結果を修正[＃14855](https://github.com/pingcap/tidb/pull/14855) - タイムゾーンを変更した後にデータが間違ったパーティションテーブルに挿入される問題を修正[＃14370](https://github.com/pingcap/tidb/pull/14370) - 外部結合の簡素化中に`IsTrue`関数の無効な名前を使用して式を再構築するときに発生するpanicを修正しました [＃14515](https://github.com/pingcap/tidb/pull/14515) - `show binding`文不正な権限チェックを修正 [＃14443](https://github.com/pingcap/tidb/pull/14443) diff --git a/releases/release-4.0.0-beta.2.md b/releases/release-4.0.0-beta.2.md index 62e6ba87c4388..cf9e2b3213eb9 100644 --- a/releases/release-4.0.0-beta.2.md +++ b/releases/release-4.0.0-beta.2.md @@ -15,7 +15,7 @@ TiDB Ansible バージョン: 4.0.0-beta.2 - ツール - TiDB Binlog - - Drainer で`disable-dispatch`と`disable-causality`設定されている場合、システムがエラーを返して終了する問題を修正しました [＃915](https://github.com/pingcap/tidb-binlog/pull/915) + - Drainer で`disable-dispatch`と`disable-causality`が設定されている場合、システムがエラーを返して終了する問題を修正しました [＃915](https://github.com/pingcap/tidb-binlog/pull/915) ## 新機能 {#new-features} diff --git a/releases/release-5.2.2.md b/releases/release-5.2.2.md index ce5e1bb43fa15..cc3eb206bade0 100644 --- a/releases/release-5.2.2.md +++ b/releases/release-5.2.2.md @@ -109,7 +109,7 @@ TiDB バージョン: 5.2.2 - 下流の TiDB/MySQL の可用性を検証する際の不要な CPU 消費を修正[＃3073](https://github.com/pingcap/tiflow/issues/3073) - TiCDCによって生成されるKafkaメッセージの量が`max-message-size` に制限されない問題を修正 [＃2962](https://github.com/pingcap/tiflow/issues/2962) - Kafka メッセージの書き込み中にエラーが発生すると TiCDC 同期タスクが一時停止する可能性がある問題を修正[＃2978](https://github.com/pingcap/tiflow/issues/2978) - - `force-replicate`有効になっているときに、有効なインデックスのない一部のパーティションテーブルが無視される可能性がある問題を修正[＃2834](https://github.com/pingcap/tiflow/issues/2834) + - `force-replicate`が有効になっているときに、有効なインデックスのない一部のパーティションテーブルが無視される可能性がある問題を修正[＃2834](https://github.com/pingcap/tiflow/issues/2834) - 株価データのスキャンに時間がかかりすぎると、TiKV が GC を実行するため株価データのスキャンが失敗する可能性がある問題を修正しました[＃2470](https://github.com/pingcap/tiflow/issues/2470) - 一部のタイプの列を Open Protocol 形式にエンコードするときに発生する可能性のあるpanic問題を修正しました。 [＃2758](https://github.com/pingcap/tiflow/issues/2758) - 一部のタイプの列をAvro形式にエンコードする際に発生する可能性のあるpanic問題を修正しました [＃2648](https://github.com/pingcap/tiflow/issues/2648) diff --git a/releases/release-5.3.1.md b/releases/release-5.3.1.md index 66134f2ad7342..f607013bf9f03 100644 --- a/releases/release-5.3.1.md +++ b/releases/release-5.3.1.md @@ -58,7 +58,7 @@ TiDB バージョン: 5.3.1 - TiDBの`date_format`が`'\n'` MySQLと互換性のない方法で処理する問題を修正[＃32232](https://github.com/pingcap/tidb/issues/32232) - `alter column set default`テーブルスキーマを誤って更新する問題を修正 [＃31074](https://github.com/pingcap/tidb/issues/31074) - - `tidb_restricted_read_only`有効になっているときに`tidb_super_read_only`自動的に有効にならないバグを修正[＃31745](https://github.com/pingcap/tidb/issues/31745) + - `tidb_restricted_read_only`が有効になっているときに`tidb_super_read_only`自動的に有効にならないバグを修正[＃31745](https://github.com/pingcap/tidb/issues/31745) - 照合順序`greatest`または`least`関数が間違った結果を返す問題を修正しました[＃31789](https://github.com/pingcap/tidb/issues/31789) - クエリ実行時に MPP タスクリストが空になるエラーを修正 [＃31636](https://github.com/pingcap/tidb/issues/31636) - innerWorker panicによって発生するインデックス結合の誤った結果を修正しました [＃31494](https://github.com/pingcap/tidb/issues/31494) @@ -99,7 +99,7 @@ TiDB バージョン: 5.3.1 - TiFlash - 入力引数`arg` `decimal(x,y)`範囲を超えた場合に`cast(arg as decimal(x,y))`間違った結果を返す問題を修正しました - - `max_memory_usage`と`max_memory_usage_for_all_queries`有効になっているときに発生するTiFlashクラッシュの問題を修正 + - `max_memory_usage`と`max_memory_usage_for_all_queries`が有効になっているときに発生するTiFlashクラッシュの問題を修正 - `cast(string as real)`間違った結果を返す問題を修正 - `cast(string as decimal)`間違った結果を返す問題を修正 - 主キー列をより大きな int データ型に変更した後に発生する可能性のあるデータの不整合を修正します。 @@ -129,7 +129,7 @@ TiDB バージョン: 5.3.1 - クラスター内に異なるバージョンの TiCDC ノードがある場合に HTTP API が動作しない問題を修正[＃3483](https://github.com/pingcap/tiflow/issues/3483) - S3ストレージがTiCDC Redo Log で構成されている場合に TiCDC が異常終了する問題を修正しました [＃3523](https://github.com/pingcap/tiflow/issues/3523) - デフォルト値を複製できない問題を修正[＃3793](https://github.com/pingcap/tiflow/issues/3793) - - `batch-replace-enable`無効になっている場合、MySQLシンクが重複した`replace` SQL文を生成するバグを修正[＃4501](https://github.com/pingcap/tiflow/issues/4501) + - `batch-replace-enable`が無効になっている場合、MySQLシンクが重複した`replace` SQL文を生成するバグを修正[＃4501](https://github.com/pingcap/tiflow/issues/4501) - ステータス照会するときにのみ同期メトリックが更新される問題を修正しました [＃4281](https://github.com/pingcap/tiflow/issues/4281) - `mq sink write row`監視データがない問題を修正[＃3431](https://github.com/pingcap/tiflow/issues/3431) - `min.insync.replicas` `replication-factor`より小さい場合にレプリケーションを実行できない問題を修正しました[＃3994](https://github.com/pingcap/tiflow/issues/3994) diff --git a/releases/release-5.4.1.md b/releases/release-5.4.1.md index 23d3779b5ce01..db39196fc87b0 100644 --- a/releases/release-5.4.1.md +++ b/releases/release-5.4.1.md @@ -58,7 +58,7 @@ TiDB v5.4.1では、製品設計上の互換性に関する変更は行われて - クエリがエラーを報告したときに CTE がブロックされる可能性があるバグを修正[＃31302](https://github.com/pingcap/tidb/issues/31302) - 列挙値の Nulleq 関数の誤った範囲計算結果を修正しました [＃32428](https://github.com/pingcap/tidb/issues/32428) - ChunkRPC を使用してデータをエクスポートする際の TiDB OOM を修正 [＃30880](https://github.com/pingcap/tidb/issues/30880) [＃31981](https://github.com/pingcap/tidb/issues/31981) - - `tidb_restricted_read_only`有効になっているときに`tidb_super_read_only`自動的に有効にならないバグを修正[＃31745](https://github.com/pingcap/tidb/issues/31745) + - `tidb_restricted_read_only`が有効になっているときに`tidb_super_read_only`自動的に有効にならないバグを修正[＃31745](https://github.com/pingcap/tidb/issues/31745) - 照合順序`greatest`または`least`関数が間違った結果を返す問題を修正しました[＃31789](https://github.com/pingcap/tidb/issues/31789) - データがエスケープ文字で壊れている場合のロードデータpanicを修正 [＃31589](https://github.com/pingcap/tidb/issues/31589) - インデックスルックアップ結合を使用してクエリを実行するときに発生する`invalid transaction`エラーを修正します [＃30468](https://github.com/pingcap/tidb/issues/30468) @@ -66,7 +66,7 @@ TiDB v5.4.1では、製品設計上の互換性に関する変更は行われて - TiDBが重複したタスクをTiFlash にディスパッチする可能性があるバグを修正しました [＃32814](https://github.com/pingcap/tidb/issues/32814) - v4.0 からアップグレードされたクラスターで`all`権限の付与が失敗する可能性がある問題を修正しました [＃33588](https://github.com/pingcap/tidb/issues/33588) - MySQLバイナリプロトコルでテーブルスキーマを変更した後にプリペアドステートメントを実行するときに発生するセッションpanicを修正しました [＃33509](https://github.com/pingcap/tidb/issues/33509) - - `tidb_enable_vectorized_expression`有効になっている`compress()`式を持つ SQL 文を実行すると失敗する問題を修正しました[＃33397](https://github.com/pingcap/tidb/issues/33397) + - `tidb_enable_vectorized_expression`が有効になっている`compress()`式を持つ SQL 文を実行すると失敗する問題を修正しました[＃33397](https://github.com/pingcap/tidb/issues/33397) - `reArrangeFallback`機能によるCPU使用率の高騰の問題を修正 [＃30353](https://github.com/pingcap/tidb/issues/30353) - 新しいパーティションが追加されたときにテーブル属性がインデックスされない問題と、パーティションが変更されたときにテーブル範囲情報が更新されない問題を修正しました[＃33929](https://github.com/pingcap/tidb/issues/33929) - 初期化中のテーブルの`TopN`情報が正しくソートされないバグを修正しました[＃34216](https://github.com/pingcap/tidb/issues/34216) @@ -148,7 +148,7 @@ TiDB v5.4.1では、製品設計上の互換性に関する変更は行われて - 一部のケースでシーケンスが誤って複製されるバグを修正[＃4552](https://github.com/pingcap/tiflow/issues/4552) - `Canal-JSON` `string` を誤って処理した場合に発生する可能性のある TiCDC panic問題を修正しました [＃4635](https://github.com/pingcap/tiflow/issues/4635) - PDリーダーが強制終了した際にTiCDCノードが異常終了するバグを修正[＃4248](https://github.com/pingcap/tiflow/issues/4248) - - MySQLシンクが`batch-replace-enable`無効になっているときに重複した`replace` SQL文を生成するバグを修正[＃4501](https://github.com/pingcap/tiflow/issues/4501) + - MySQLシンクが`batch-replace-enable`が無効になっているときに重複した`replace` SQL文を生成するバグを修正[＃4501](https://github.com/pingcap/tiflow/issues/4501) - `rename tables` DDL によって発生した DML 構造エラーを修正 [＃5059](https://github.com/pingcap/tiflow/issues/5059) - 所有者が変更され、新しいスケジューラが有効になっている場合（デフォルトでは無効）に、まれにレプリケーションが停止する可能性がある問題を修正しました[＃4963](https://github.com/pingcap/tiflow/issues/4963) - 新しいスケジューラが有効になっているときにエラー ErrProcessorDuplicateOperations が報告される問題を修正しました (デフォルトでは無効) [＃4769](https://github.com/pingcap/tiflow/issues/4769) diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md index 05b019cce2a41..9ab92c895ccc3 100644 --- a/releases/release-6.1.0.md +++ b/releases/release-6.1.0.md @@ -319,7 +319,7 @@ TiDB バージョン: 6.1.0 - ダッシュボード ページはDM WebUIから削除されます。 -- `dispatchers.topic`と`dispatchers.partition`有効になっている場合、TiCDC を v6.1.0 より前のバージョンにダウングレードすることはできません。 +- `dispatchers.topic`と`dispatchers.partition`が有効になっている場合、TiCDC を v6.1.0 より前のバージョンにダウングレードすることはできません。 - Avro プロトコルを使用するTiCDC Changefeed は、v6.1.0 より前のバージョンにダウングレードできません。 diff --git a/releases/release-7.1.1.md b/releases/release-7.1.1.md index 73bf70839b5d6..7595407c7d36f 100644 --- a/releases/release-7.1.1.md +++ b/releases/release-7.1.1.md @@ -61,7 +61,7 @@ TiDB バージョン: 7.1.1 - メモリトラッカーの潜在的なメモリリーク問題を修正 [＃44612](https://github.com/pingcap/tidb/issues/44612) @[wshwsh12](https://github.com/wshwsh12) - バッチコプロセッサの再試行によって誤ったリージョン情報が生成される可能性があり、クエリが失敗する問題を修正しました[＃44622](https://github.com/pingcap/tidb/issues/44622) @[windtalker](https://github.com/windtalker) - インデックススキャンにおける潜在的なデータ競合問題を修正 [＃45126](https://github.com/pingcap/tidb/issues/45126) @[wshwsh12](https://github.com/wshwsh12) - - `tidb_enable_parallel_apply`有効になっている場合、MPP モードでのクエリ結果が正しくない問題を修正[＃45299](https://github.com/pingcap/tidb/issues/45299) @[windtalker](https://github.com/windtalker) + - `tidb_enable_parallel_apply`が有効になっている場合、MPP モードでのクエリ結果が正しくない問題を修正[＃45299](https://github.com/pingcap/tidb/issues/45299) @[windtalker](https://github.com/windtalker) - `indexMerge`のクエリが強制終了されたときに発生するハングアップの問題を修正しました [＃45279](https://github.com/pingcap/tidb/issues/45279) @[xzhangxian1008](https://github.com/xzhangxian1008) - 統計情報におけるSQL実行詳細のメモリ消費量が多すぎると、極端なケースでTiDB OOMが発生する問題を修正[＃44047](https://github.com/pingcap/tidb/issues/44047) @[wshwsh12](https://github.com/wshwsh12) - `FormatSQL()`メソッドが入力の非常に長い SQL 文を適切に切り捨てることができない問題を修正しました。 [＃44542](https://github.com/pingcap/tidb/issues/44542) @[hawkingrei](https://github.com/hawkingrei) @@ -94,7 +94,7 @@ TiDB バージョン: 7.1.1 - `PREPARE stmt FROM "ANALYZE TABLE xxx"` `tidb_mem_quota_query` で殺される可能性がある問題を修正 [＃44320](https://github.com/pingcap/tidb/issues/44320) @[chrysan](https://github.com/chrysan) - 空の`processInfo` によって引き起こされるpanic問題を修正 [＃43829](https://github.com/pingcap/tidb/issues/43829) @[zimulala](https://github.com/zimulala) - `ON UPDATE`文が主キーを正しく更新しない場合にデータとインデックスが不整合になる問題を修正しました [＃44565](https://github.com/pingcap/tidb/issues/44565) @[zyguan](https://github.com/zyguan) - - `tidb_opt_agg_push_down`有効になっている場合にクエリが誤った結果を返す可能性がある問題を修正[＃44795](https://github.com/pingcap/tidb/issues/44795) @[AilinKid](https://github.com/AilinKid) + - `tidb_opt_agg_push_down`が有効になっている場合にクエリが誤った結果を返す可能性がある問題を修正[＃44795](https://github.com/pingcap/tidb/issues/44795) @[AilinKid](https://github.com/AilinKid) - CTEと相関サブクエリを同時に使用すると、クエリ結果が不正確になったり、panicが発生する可能性がある問題を修正[＃44649](https://github.com/pingcap/tidb/issues/44649) [＃38170](https://github.com/pingcap/tidb/issues/38170) [＃44774](https://github.com/pingcap/tidb/issues/44774) @[winoros](https://github.com/winoros) @[guo-shaoge](https://github.com/guo-shaoge) - ロールバック状態でDDLタスクをキャンセルすると、関連するメタデータにエラーが発生する問題を修正しました [＃44143](https://github.com/pingcap/tidb/issues/44143) @[wjhuang2016](https://github.com/wjhuang2016) - `UPDATE`文を実行すると外部キー制約のチェックによりエラーが発生する問題を修正しました [＃44848](https://github.com/pingcap/tidb/issues/44848) @[crazycs520](https://github.com/crazycs520) diff --git a/releases/release-7.5.1.md b/releases/release-7.5.1.md index 9e2af860af3a0..e202c68c41cca 100644 --- a/releases/release-7.5.1.md +++ b/releases/release-7.5.1.md @@ -42,7 +42,7 @@ TiDB バージョン: 7.5.1 - いくつかの型変換を処理する際の TiDB 実装を最適化し、関連する問題を修正しました[＃47945](https://github.com/pingcap/tidb/issues/47945) [＃47864](https://github.com/pingcap/tidb/issues/47864) [＃47829](https://github.com/pingcap/tidb/issues/47829) [＃47816](https://github.com/pingcap/tidb/issues/47816) @[YangKeao](https://github.com/YangKeao) @[lcwangchao](https://github.com/lcwangchao) - - 非バイナリ照合順序が設定され、クエリに`LIKE`含まれている場合、オプティマイザは実行効率を向上させるために`IndexRangeScan`を生成します[＃48181](https://github.com/pingcap/tidb/issues/48181) [＃49138](https://github.com/pingcap/tidb/issues/49138) @[time-and-fate](https://github.com/time-and-fate) + - 非バイナリ照合順序が設定され、クエリに`LIKE`が含まれている場合、オプティマイザは実行効率を向上させるために`IndexRangeScan`を生成します[＃48181](https://github.com/pingcap/tidb/issues/48181) [＃49138](https://github.com/pingcap/tidb/issues/49138) @[time-and-fate](https://github.com/time-and-fate) - 特定のシナリオで`OUTER JOIN`を`INNER JOIN`に変換する能力を強化する[＃49616](https://github.com/pingcap/tidb/issues/49616) @[qw4990](https://github.com/qw4990) diff --git a/releases/release-7.5.5.md b/releases/release-7.5.5.md index 8519f2dc51966..2daed7dbfb707 100644 --- a/releases/release-7.5.5.md +++ b/releases/release-7.5.5.md @@ -80,7 +80,7 @@ TiDB バージョン: 7.5.5 - 分散実行フレームワーク (DXF) に関連するシステムテーブルをクエリすると、アップグレードが失敗する可能性がある問題を修正しました[＃49263](https://github.com/pingcap/tidb/issues/49263) @[D3Hunter](https://github.com/D3Hunter) - DDL内部トランザクションエラー`GC life time is shorter than transaction duration`によりインデックス追加が失敗する問題を修正[＃57043](https://github.com/pingcap/tidb/issues/57043) @[tangenta](https://github.com/tangenta) - `EXCHANGE PARTITION`を実行して無効な行に遭遇すると、InfoSchema が完全にロードされ、エラー`failed to load schema diff`が報告される問題を修正しました。 [＃56685](https://github.com/pingcap/tidb/issues/56685) @[D3Hunter](https://github.com/D3Hunter) - - `tidb_ddl_enable_fast_reorg`と`new_collations_enabled_on_first_bootstrap`有効になっているときに照合順序が正しく処理されず、データインデックスが不一致になる問題を修正しました。 [＃58036](https://github.com/pingcap/tidb/issues/58036) @[djshow832](https://github.com/djshow832) + - `tidb_ddl_enable_fast_reorg`と`new_collations_enabled_on_first_bootstrap`が有効になっているときに照合順序が正しく処理されず、データインデックスが不一致になる問題を修正しました。 [＃58036](https://github.com/pingcap/tidb/issues/58036) @[djshow832](https://github.com/djshow832) - プランキャッシュがインデックスを追加するときに間違ったスキーマを使用するため、データインデックスが不整合になる問題を修正しました。 [＃56733](https://github.com/pingcap/tidb/issues/56733) @[wjhuang2016](https://github.com/wjhuang2016) - アップグレード中に`ALTER TABLE TIFLASH REPLICA`を実行するとTiDBノードがクラッシュする問題を修正[＃57863](https://github.com/pingcap/tidb/issues/57863) @[tangenta](https://github.com/tangenta) - クエリ`INFORMATION_SCHEMA.columns`のパフォーマンスが低下する問題を修正 [＃58184](https://github.com/pingcap/tidb/issues/58184) @[lance6716](https://github.com/lance6716) diff --git a/schedule-replicas-by-topology-labels.md b/schedule-replicas-by-topology-labels.md index 11d70bf894542..3610877b11244 100644 --- a/schedule-replicas-by-topology-labels.md +++ b/schedule-replicas-by-topology-labels.md @@ -198,7 +198,7 @@ host = "" #### (オプション) TiDBの`labels`を構成する {#optional-configure-labels-for-tidb} -[Followerが読んだ](/follower-read.md)有効になっている場合、TiDB が同じリージョンからのデータを優先的に読み取るようにするには、TiDB ノードに対して`labels`設定する必要があります。 +[Followerが読んだ](/follower-read.md)が有効になっている場合、TiDB が同じリージョンからのデータを優先的に読み取るようにするには、TiDB ノードに対して`labels`設定する必要があります。 構成ファイルを使用して、TiDB に`labels`設定できます。 diff --git a/sql-statements/sql-statement-explain.md b/sql-statements/sql-statement-explain.md index fb2041398227b..23fbe5ff6cab3 100644 --- a/sql-statements/sql-statement-explain.md +++ b/sql-statements/sql-statement-explain.md @@ -52,8 +52,8 @@ ExplainableStmt ::= | id | オペレータIDは、実行計画全体におけるオペレータの一意の識別子です。TiDB 2.1では、このIDはオペレータのツリー構造を表すようにフォーマットされています。データは子ノードから親ノードへと流れます。オペレータごとに親ノードは1つだけです。 | | estRows | 演算子が出力すると予想される行数。この数は、統計情報と演算子のロジックに基づいて推定されます。`estRows`は、TiDB 4.0 の以前のバージョンでは`count`と呼ばれていました。 | | タスク | オペレータが属するタスクの種類。現在、実行計画は tidb-server 上で実行される**ルート**タスクと、 TiKV またはTiFlash上で並列実行される**cop**タスクの2つのタスクに分かれています。タスクレベルでの実行計画のトポロジは、ルートタスクの後に多数の cop タスクが続くというものです。ルートタスクは cop タスクの出力を入力として使用します。cop タスクとは、TiDB が TiKV またはTiFlashにプッシュダウンするタスクを指します。各 cop タスクは TiKV クラスターまたはTiFlashクラスターに分散され、複数のプロセスによって実行されます。 | -| アクセスオブジェクト | オペレータがアクセスするデータ項目情報。この情報には、 `table` 、および`index` （存在する場合） `partition`含まれます。この情報は、データに直接アクセスするオペレータのみが使用できます。 | -| オペレーター情報 | 演算子に関するその他の情報。演算子ごとに`operator info`異なります。以下の例を参照してください。 | +| アクセスオブジェクト | オペレータがアクセスするデータ項目情報。この情報には、 `table` 、および`index` （存在する場合） `partition`が含まれます。この情報は、データに直接アクセスするオペレータのみが使用できます。 | +| オペレーター情報 | 演算子に関するその他の情報。演算子ごとに`operator info`が異なります。以下の例を参照してください。 | ## 例 {#examples} diff --git a/sql-statements/sql-statement-modify-column.md b/sql-statements/sql-statement-modify-column.md index 1fb0ab6b82e56..f32240f6649b9 100644 --- a/sql-statements/sql-statement-modify-column.md +++ b/sql-statements/sql-statement-modify-column.md @@ -161,7 +161,7 @@ CREATE TABLE `t1` ( > ERROR 1406 (22001): Data Too Long, field len 4, data len 5 > ``` > -> - 非同期コミット機能との互換性のため、 [メタデータロック](/metadata-lock.md)無効になっている場合、DDL ステートメントは、Reorg-Data への処理を開始する前に一定期間 (約 2.5秒) 待機します。 +> - 非同期コミット機能との互換性のため、 [メタデータロック](/metadata-lock.md)が無効になっている場合、DDL ステートメントは、Reorg-Data への処理を開始する前に一定期間 (約 2.5秒) 待機します。 > > ``` > Query OK, 0 rows affected (2.52 sec) diff --git a/tidb-external-ts.md b/tidb-external-ts.md index 108c18001cad9..b8219cf4083d3 100644 --- a/tidb-external-ts.md +++ b/tidb-external-ts.md @@ -110,4 +110,4 @@ summary: tidb_external_ts` 変数を使用して履歴データを読み取る 3 rows in set (0.00 sec) ``` - 新しい行が挿入される前にタイムスタンプに`tidb_external_ts`設定されるため、 `tidb_enable_external_ts_read`有効になった後は新しく挿入された行は返されません。 + 新しい行が挿入される前にタイムスタンプに`tidb_external_ts`が設定されるため、 `tidb_enable_external_ts_read`有効になった後は新しく挿入された行は返されません。 diff --git a/tiflash/use-tiflash-mpp-mode.md b/tiflash/use-tiflash-mpp-mode.md index ab668fc94171d..a4b4324d20804 100644 --- a/tiflash/use-tiflash-mpp-mode.md +++ b/tiflash/use-tiflash-mpp-mode.md @@ -111,7 +111,7 @@ TiFlash は、ブロードキャスト ハッシュ結合を使用するかど - [`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50) : 値の単位はバイトです。テーブルサイズ（バイト単位）が変数の値より小さい場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 - [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50) : 値の単位は行です。結合操作のオブジェクトがサブクエリに属する場合、オプティマイザはサブクエリの結果セットのサイズを推定できないため、結果セットの行数によってサイズが決定されます。サブクエリの推定行数がこの変数の値より少ない場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 -- [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-new-in-v710) : ネットワーク転送のオーバーヘッドが最小となるアルゴリズムを使用するかどうかを制御します。この変数を有効にすると、TiDBはネットワークで交換されるデータのサイズをそれぞれ`Broadcast Hash Join`と`Shuffled Hash Join`で推定し、サイズが小さい方を選択します。この変数を有効にすると、 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50)と[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50)無効になります。 +- [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-new-in-v710) : ネットワーク転送のオーバーヘッドが最小となるアルゴリズムを使用するかどうかを制御します。この変数を有効にすると、TiDBはネットワークで交換されるデータのサイズをそれぞれ`Broadcast Hash Join`と`Shuffled Hash Join`で推定し、サイズが小さい方を選択します。この変数を有効にすると、 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50)と[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50)が無効になります。 ## MPP モードでパーティションテーブルにアクセスする {#access-partitioned-tables-in-the-mpp-mode} diff --git a/tikv-control.md b/tikv-control.md index 6a46e95694327..d0d605d8ae9d1 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -299,7 +299,7 @@ middle_key_by_approximate_size: - `--from`と`--to`オプションを使用して、エスケープされた生のキーの形式で圧縮範囲を指定します。指定しない場合は、範囲全体が圧縮されます。 -- 特定のリージョンの範囲を圧縮するには、オプション`--region`を使用します。設定されている場合、 `--from`と`--to`無視されます。 +- 特定のリージョンの範囲を圧縮するには、オプション`--region`を使用します。設定されている場合、 `--from`と`--to`が無視されます。 - カラムファミリー名を指定するには、 `-c`オプションを使用します。デフォルト値は`default`です。オプションの値は`default` 、 `lock` 、 `write`です。 diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index 5d9e0f654ce25..0aff1f59281e2 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -17,7 +17,7 @@ summary: 読み取りおよび書き込みのレイテンシーが長くなる - スローログにクエリ実行計画が出力されている場合は、プランを直接確認できます。`select tidb_decode_plan('xxx...')`ステートメントを実行すると、詳細な実行計画を解析できます。 - モニター内のスキャンされたキーの数が異常に増加し、スローログでは`Scan Keys`の数が多くなります。 -- TiDBにおけるSQL実行時間は、MySQLなどの他のデータベースと比べて大きく異なります。他のデータベースの実行計画と比較することで、例えば`Join Order`異なるかどうかなどを確認できます。 +- TiDBにおけるSQL実行時間は、MySQLなどの他のデータベースと比べて大きく異なります。他のデータベースの実行計画と比較することで、例えば`Join Order`が異なるかどうかなどを確認できます。 #### 考えられる理由 {#possible-reason} From 91348f845bbf1c82a072e9e05a785fd2f1f753c8 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 27 Aug 2026 10:15:01 +0900 Subject: [PATCH 4/5] =?UTF-8?q?i18n(ja):=20fix=20dropped=20=E3=81=8C=20par?= =?UTF-8?q?ticle=20before=20predicates=20(batch=201)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- benchmark/benchmark-tidb-using-sysbench.md | 4 ++-- best-practices/multi-column-index-best-practices.md | 2 +- dashboard/dashboard-profiling.md | 2 +- dm/table-selector.md | 2 +- functions-and-operators/string-functions.md | 2 +- metrics-schema.md | 2 +- password-management.md | 2 +- releases/release-3.0.2.md | 2 +- releases/release-4.0.16.md | 2 +- releases/release-4.0.7.md | 2 +- releases/release-5.4.2.md | 2 +- releases/release-6.0.0-dmr.md | 2 +- releases/release-6.1.1.md | 2 +- releases/release-6.3.0.md | 4 ++-- releases/release-6.5.12.md | 2 +- releases/release-7.1.0.md | 2 +- releases/release-7.1.3.md | 4 ++-- releases/release-8.0.0.md | 2 +- sql-statements/sql-statement-admin-checksum-table.md | 2 +- ticdc/ticdc-avro-protocol.md | 2 +- ticdc/ticdc-faq.md | 6 +++--- tidb-cloud/csv-config-for-import-data.md | 2 +- tiproxy/tiproxy-traffic-replay.md | 2 +- troubleshoot-data-inconsistency-errors.md | 2 +- 24 files changed, 29 insertions(+), 29 deletions(-) diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 23e4219b96854..fee13668135cc 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -23,7 +23,7 @@ server_configs: > **Note:** > -> Sysbenchのバージョンによっては、デフォルト値の`db-ps-mode`異なる場合があります。コマンドで明示的に指定することをお勧めします。 +> Sysbenchのバージョンによっては、デフォルト値の`db-ps-mode`が異なる場合があります。コマンドで明示的に指定することをお勧めします。 ### TiKV構成 {#tikv-configuration} @@ -158,7 +158,7 @@ sysbench --config-file=config oltp_read_only --tables=32 --table-size=10000000 - この問題は多くの場合、プロキシの使用に関係しています。単一のTiDBサーバーに負荷をかけ、それぞれの結果を合計し、プロキシを使用した結果と比較することができます。 -HAproxyを例に挙げましょう。パラメータ`nbproc`を指定すると、起動できるプロセスの最大数を増やすことができます。HAproxyの最新バージョンでは、 `nbthread`と`cpu-map`サポートされています。これらはすべて、プロキシの使用によるパフォーマンスへの悪影響を軽減します。 +HAproxyを例に挙げましょう。パラメータ`nbproc`を指定すると、起動できるプロセスの最大数を増やすことができます。HAproxyの最新バージョンでは、 `nbthread`と`cpu-map`がサポートされています。これらはすべて、プロキシの使用によるパフォーマンスへの悪影響を軽減します。 ### 同時実行性が高いのに、TiKV の CPU 使用率が低いのはなぜですか? {#under-high-concurrency-why-is-the-cpu-utilization-rate-of-tikv-still-low} diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index c4ae62d3da920..3638bf93978b5 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -160,7 +160,7 @@ EXPLAIN FORMAT = "brief" ### 例2: 重複しない範囲 {#example-2-non-overlapping-ranges} -別のシナリオとして、サンフランシスコまたはサンディエゴで手頃な価格のシングルベッドルーム物件を検索するクエリを想像してみてください。ここでは、条件`OR`異なる都市の2つの異なる範囲を指定しています。 +別のシナリオとして、サンフランシスコまたはサンディエゴで手頃な価格のシングルベッドルーム物件を検索するクエリを想像してみてください。ここでは、条件`OR`が異なる都市の2つの異なる範囲を指定しています。 - サンフランシスコの物件、1ベッドルーム、価格`$1,500` ～ `$2,500` - サンディエゴの物件、1ベッドルーム、価格`$1,000` ～ `$1,500` diff --git a/dashboard/dashboard-profiling.md b/dashboard/dashboard-profiling.md index 7e7c7abce8c5a..374bb5e436341 100644 --- a/dashboard/dashboard-profiling.md +++ b/dashboard/dashboard-profiling.md @@ -49,7 +49,7 @@ summary: 手動プロファイリングを使用すると、TiDB、TiKV、PD、 プロファイリングを開始する前に、プロファイリング期間を変更できます。この期間はプロファイリングに必要な時間によって決まり、デフォルトでは30秒です。30秒の期間は完了まで30秒かかります。 -[継続的なプロファイリング](/dashboard/continuous-profiling.md)有効になっているクラスターでは、手動プロファイリングを開始できません。現時点でのパフォーマンスデータを表示するには、 [継続的なプロファイリングページ](/dashboard/continuous-profiling.md#access-the-page)で最新のプロファイリング結果をクリックしてください。 +[継続的なプロファイリング](/dashboard/continuous-profiling.md)が有効になっているクラスターでは、手動プロファイリングを開始できません。現時点でのパフォーマンスデータを表示するには、 [継続的なプロファイリングページ](/dashboard/continuous-profiling.md#access-the-page)で最新のプロファイリング結果をクリックしてください。 ## プロファイリングステータスを表示する {#view-profiling-status} diff --git a/dm/table-selector.md b/dm/table-selector.md index f090900cc2fd8..10ab89a660ba3 100644 --- a/dm/table-selector.md +++ b/dm/table-selector.md @@ -14,7 +14,7 @@ summary: データ移行のテーブルルーティング、 binlogイベント - アスタリスク文字（ `*` 、「スター」とも呼ばれる） - `*` 0文字以上の文字に一致します。例えば、 `doc*` `doc`と`document`に一致しますが、 `dodo`は一致しません。 - - `*`単語の末尾にのみ配置できます。例えば、 `doc*`サポートされていますが、 `do*c`サポートされていません。 + - `*`単語の末尾にのみ配置できます。例えば、 `doc*`がサポートされていますが、 `do*c`はサポートされていません。 - 疑問符（ `?` ） diff --git a/functions-and-operators/string-functions.md b/functions-and-operators/string-functions.md index 69dc666e5a843..5e848622445db 100644 --- a/functions-and-operators/string-functions.md +++ b/functions-and-operators/string-functions.md @@ -2354,7 +2354,7 @@ TiDB と MySQL 間の`match_type`の値オプションは次のとおりです - TiDB の値オプションは`"c"` 、 `"i"` 、 `"m"` 、 `"s"`であり、MySQL の値オプションは`"c"` 、 `"i"` 、 `"m"` 、 `"n"` 、 `"u"`です。 -- TiDBの`"s"`はMySQLの`"n"`に相当します。TiDBで`"s"`設定されている場合、 `.`は行末文字（ `\n` ）にも一致します。 +- TiDBの`"s"`はMySQLの`"n"`に相当します。TiDBで`"s"`が設定されている場合、 `.`は行末文字（ `\n` ）にも一致します。 たとえば、MySQL の`SELECT REGEXP_LIKE(a, b, "n") FROM t1` TiDB の`SELECT REGEXP_LIKE(a, b, "s") FROM t1`と同じです。 diff --git a/metrics-schema.md b/metrics-schema.md index a14dd31fecd39..7196119dff762 100644 --- a/metrics-schema.md +++ b/metrics-schema.md @@ -184,7 +184,7 @@ DESC SELECT * FROM metrics_schema.tidb_query_duration WHERE value is not null AN +------------------+----------+------+---------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ ``` -上記の結果から、実行計画には`PromQL` 、 `start_time` 、 `end_time` 、 `step`含まれていることがわかります。実行プロセス中、TiDBはPrometheusの`query_range` HTTP APIを呼び出して監視データを照会します。 +上記の結果から、実行計画には`PromQL` 、 `start_time` 、 `end_time` 、 `step`が含まれていることがわかります。実行プロセス中、TiDBはPrometheusの`query_range` HTTP APIを呼び出して監視データを照会します。 [ `2020-03-25 23:40:00` , `2020-03-25 23:42:00` ] の範囲では、各ラベルに3つの時間値しかないことに気づくかもしれません。実行計画では、 `step`の値は1分であり、これらの値の間隔は1分であることを意味します。`step`は次の2つのセッション変数によって決定されます。 diff --git a/password-management.md b/password-management.md index aef51df48ee89..59158a5075640 100644 --- a/password-management.md +++ b/password-management.md @@ -276,7 +276,7 @@ disconnect-on-expired-password = true - `disconnect-on-expired-password` `true` (デフォルト) に設定すると、パスワードの有効期限が切れるとサーバーはクライアントとの接続を切断します。 - `disconnect-on-expired-password` `false`に設定すると、サーバーは「サンドボックスモード」を有効にし、ユーザーがサーバーに接続できるようにします。ただし、ユーザーはパスワードのリセットのみ可能です。パスワードをリセットすると、ユーザーはSQL文を通常どおり実行できるようになります。 -`disconnect-on-expired-password`有効になっている場合、アカウントのパスワードが期限切れになると、TiDB はそのアカウントからの接続を拒否します。このような場合、以下の方法でパスワードを変更できます。 +`disconnect-on-expired-password`が有効になっている場合、アカウントのパスワードが期限切れになると、TiDB はそのアカウントからの接続を拒否します。このような場合、以下の方法でパスワードを変更できます。 - 通常のアカウントのパスワードの有効期限が切れた場合、管理者は SQL ステートメントを使用してアカウントのパスワードを変更できます。 - 管理者アカウントのパスワードの有効期限が切れた場合、別の管理者が SQL ステートメントを使用してアカウントのパスワードを変更できます。 diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index 236e784f5e074..8ab1313f5df7c 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -26,7 +26,7 @@ TiDB Ansible バージョン: 3.0.2 - オプティマイザーが時間等条件正しく推定しない問題を修正 [＃11512](https://github.com/pingcap/tidb/pull/11512) - フィードバック情報に基づいてトップN統計を更新することをサポート[＃11507](https://github.com/pingcap/tidb/pull/11507) - SQL実行エンジン - - 関数`INSERT`パラメータに`NULL`含まれている場合、戻り値が`NULL`ならない問題を修正しました。 [＃11248](https://github.com/pingcap/tidb/pull/11248) + - 関数`INSERT`パラメータに`NULL`が含まれている場合、戻り値が`NULL`ならない問題を修正しました。 [＃11248](https://github.com/pingcap/tidb/pull/11248) - パーティションテーブルを`ADMIN CHECKSUM`操作でチェックすると計算結果が間違っている可能性がある問題を修正しました [＃11266](https://github.com/pingcap/tidb/pull/11266) - INDEX JOIN がプレフィックスインデックスを使用すると結果が間違ってしまう可能性がある問題を修正しました [＃11246](https://github.com/pingcap/tidb/pull/11246) - `DATE_ADD`関数がマイクロ秒を含む日付数値の減算を行う際に分数の配置が誤っているために結果が間違っている可能性がある問題を修正しました[＃11288](https://github.com/pingcap/tidb/pull/11288) diff --git a/releases/release-4.0.16.md b/releases/release-4.0.16.md index 5e7ff5a7b1ca8..8da77e9dcadab 100644 --- a/releases/release-4.0.16.md +++ b/releases/release-4.0.16.md @@ -106,7 +106,7 @@ TiDBバージョン: 4.0.16 - TiCDCによって生成されるKafkaメッセージの量が`max-message-size` に制限されない問題を修正 [＃2962](https://github.com/pingcap/tiflow/issues/2962) - `tikv_cdc_min_resolved_ts_no_change_for_1m`チェンジフィードがないときに警告が続く問題を修正[＃11017](https://github.com/tikv/tikv/issues/11017) - Kafka メッセージの書き込み中にエラーが発生すると、TiCDC 同期タスクが一時停止する可能性がある問題を修正しました[＃2978](https://github.com/pingcap/tiflow/issues/2978) - - `force-replicate`有効になっているときに、有効なインデックスのない一部のパーティションテーブルが無視される可能性がある問題を修正[＃2834](https://github.com/pingcap/tiflow/issues/2834) + - `force-replicate`が有効になっているときに、有効なインデックスのない一部のパーティションテーブルが無視される可能性がある問題を修正[＃2834](https://github.com/pingcap/tiflow/issues/2834) - 新しい変更フィードを作成するときに発生するメモリリークの問題を修正しました [＃2389](https://github.com/pingcap/tiflow/issues/2389) - シンクコンポーネントの前進によりデータの不整合が発生する可能性がある問題を修正しました[＃3503](https://github.com/pingcap/tiflow/issues/3503) - 株価データのスキャンに時間がかかりすぎると、TiKV が GC を実行するため株価データのスキャンが失敗する可能性がある問題を修正しました[＃2470](https://github.com/pingcap/tiflow/issues/2470) diff --git a/releases/release-4.0.7.md b/releases/release-4.0.7.md index 515354c1a5583..563b5a0369ae9 100644 --- a/releases/release-4.0.7.md +++ b/releases/release-4.0.7.md @@ -84,7 +84,7 @@ TiDB バージョン: 4.0.7 - PD - - `balance-region`有効になっているときに、一部のリージョンにLeaderがいない場合、PD がpanicする可能性があるバグを修正しました[＃2994](https://github.com/pingcap/pd/pull/2994) + - `balance-region`が有効になっているときに、一部のリージョンにLeaderがいない場合、PD がpanicする可能性があるバグを修正しました[＃2994](https://github.com/pingcap/pd/pull/2994) - リージョンマージ後のリージョンサイズとリージョンキーの統計的偏差を修正 [＃2985](https://github.com/pingcap/pd/pull/2985) - ホットスポット統計の誤りを修正[＃2991](https://github.com/pingcap/pd/pull/2991) - `redirectSchedulerDelete` に`nil`チェックインがない問題を修正 [＃2974](https://github.com/pingcap/pd/pull/2974) diff --git a/releases/release-5.4.2.md b/releases/release-5.4.2.md index ba5b7cc7b4414..f4a0b17f7f895 100644 --- a/releases/release-5.4.2.md +++ b/releases/release-5.4.2.md @@ -42,7 +42,7 @@ TiDB バージョン: 5.4.2 - バイナリプロトコル で間違った TableDual プランがキャッシュされる問題を修正 [＃34678](https://github.com/pingcap/tidb/issues/34678) [＃34690](https://github.com/pingcap/tidb/issues/34690) - EqualAll ケースでTiFlash `firstrow`集計関数の誤って推論された null フラグの問題を修正しました [＃34584](https://github.com/pingcap/tidb/issues/34584) - プランナーがTiFlash に対して間違った 2 フェーズ集計プランを生成する問題を修正しました [＃34682](https://github.com/pingcap/tidb/issues/34682) - - `tidb_opt_agg_push_down`と`tidb_enforce_mpp`有効になっているときに発生するプランナーの誤った動作を修正[＃34465](https://github.com/pingcap/tidb/issues/34465) + - `tidb_opt_agg_push_down`と`tidb_enforce_mpp`が有効になっているときに発生するプランナーの誤った動作を修正[＃34465](https://github.com/pingcap/tidb/issues/34465) - プランキャッシュが削除されたときに使用される間違ったメモリ使用量の値を修正しました[＃34613](https://github.com/pingcap/tidb/issues/34613) - `LOAD DATA`文で列リストが機能しない問題を修正 [＃35198](https://github.com/pingcap/tidb/issues/35198) - 悲観的トランザクションで`WriteConflict`エラーを報告しないようにする [＃11612](https://github.com/tikv/tikv/issues/11612) diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md index f33e37aee3bbb..b36462a5e731c 100644 --- a/releases/release-6.0.0-dmr.md +++ b/releases/release-6.0.0-dmr.md @@ -518,7 +518,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - TiCDC - - `batch-replace-enable`無効になっているときに MySQL シンクが重複した`replace` SQL 文を生成するバグを修正[＃4501](https://github.com/pingcap/tiflow/issues/4501) + - `batch-replace-enable`が無効になっているときに MySQL シンクが重複した`replace` SQL 文を生成するバグを修正[＃4501](https://github.com/pingcap/tiflow/issues/4501) - PDリーダーが強制終了した際にTiCDCノードが異常終了するバグを修正[＃4248](https://github.com/pingcap/tiflow/issues/4248) - 一部のMySQLバージョンのエラー`Unknown system variable 'transaction_isolation'`を修正 [＃4504](https://github.com/pingcap/tiflow/issues/4504) - `Canal-JSON` `string` を誤って処理した場合に発生する可能性のある TiCDC panic問題を修正しました [＃4635](https://github.com/pingcap/tiflow/issues/4635) diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md index f17b9814db676..4f1e6798f1312 100644 --- a/releases/release-6.1.1.md +++ b/releases/release-6.1.1.md @@ -117,7 +117,7 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - PD - クラスタノードのラベル構成が無効な場合にオンラインの進行状況が不正確になる問題を修正[＃5234](https://github.com/tikv/pd/issues/5234) @[rleungx](https://github.com/rleungx) - - `enable-forwarding`有効になっているときに gRPC がエラーを不適切に処理する問題によって発生する PD パニックを修正[＃5373](https://github.com/tikv/pd/issues/5373) @[bufferflies](https://github.com/bufferflies) + - `enable-forwarding`が有効になっているときに gRPC がエラーを不適切に処理する問題によって発生する PD パニックを修正[＃5373](https://github.com/tikv/pd/issues/5373) @[bufferflies](https://github.com/bufferflies) - `/regions/replicated`間違ったステータスを返す可能性がある問題を修正しました [＃5095](https://github.com/tikv/pd/issues/5095) @[rleungx](https://github.com/rleungx) - TiFlash diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 9e7068a7e2b60..edcc8f9cae5cf 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -215,7 +215,7 @@ TiDBバージョン: 6.3.0-DMR | [`sql_require_primary_key`](/system-variables.md#sql_require_primary_key-new-in-v630) | 新しく追加された | テーブルに主キーが必要であるという要件を強制するかどうかを制御します。この変数を有効にすると、主キーのないテーブルを作成または変更しようとするとエラーが発生します。 | | [`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630) | 新しく追加された | [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)が`closest-adaptive`に設定されている場合、TiDBサーバーが読み取り要求を TiDBサーバーと同じリージョンのレプリカに送信することを優先するしきい値を制御します。 | | [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630) | 新しく追加された | TiDB が悲観的トランザクションで[固有の制約](/constraints.md#pessimistic-transactions)いつチェックするかを制御します。 | -| [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630) | 新しく追加された | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)有効になっている場合にのみ有効になります。インデックス作成時のバックフィル処理中にローカルストレージを使用する際の制限を設定します。 | +| [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630) | 新しく追加された | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)が有効になっている場合にのみ有効になります。インデックス作成時のバックフィル処理中にローカルストレージを使用する際の制限を設定します。 | | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) | 新しく追加された | インデックス作成時のバックフィル速度を向上させるために、 `ADD INDEX`および`CREATE INDEX` DDL 操作の高速化を有効にするかどうかを制御します。 | | [`tidb_ddl_flashback_concurrency`](/system-variables.md#tidb_ddl_flashback_concurrency-new-in-v630) | 新しく追加された | `flashback cluster`の同時実行を制御します。この変数で制御される機能は、TiDB v6.3.0 では完全には動作しません。デフォルト値を変更しないでください。 | | [`tidb_enable_exchange_partition`](/system-variables.md#tidb_enable_exchange_partition) | 非推奨 | [`exchange partitions with tables`](/partitioned-table.md#partition-management)機能を有効にするかどうかを制御します。デフォルト値は`ON`です。つまり、 `exchange partitions with tables`がデフォルトで有効になっています。 | @@ -235,7 +235,7 @@ TiDBバージョン: 6.3.0-DMR | [`tidb_partition_prune_mode`](/system-variables.md#tidb_partition_prune_mode-new-in-v51) | 変更 | 動的剪定を有効にするかどうかを指定します。v6.3.0 以降、デフォルト値は`dynamic`に変更されます。 | | [`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600) | 変更 | タイムスタンプの取得を最適化するために使用され、読み取りコミット分離レベルのシナリオ（読み取りと書き込みの競合がまれなシナリオ）に適しています。この機能は特定のサービスワークロード向けに設計されており、他のシナリオではパフォーマンスが低下する可能性があります。そのため、v6.3.0以降、この変数の適用範囲が`GLOBAL \| SESSION`から`INSTANCE`に変更されました。つまり、特定のTiDBインスタンスに対してこの機能を有効にできます。 | | [`tidb_rc_write_check_ts`](/system-variables.md#tidb_rc_write_check_ts-new-in-v630) | 新しく追加された | タイムスタンプの取得を最適化するために使用され、悲観的トランザクションのRC分離レベルにおいてポイントライト競合が少ないシナリオに適しています。この変数を有効にすると、ポイントライトステートメントの実行中にグローバルタイムスタンプを取得する際に発生するレイテンシーとオーバーヘッドを回避できます。 | -| [`tiflash_fastscan`](/system-variables.md#tiflash_fastscan-new-in-v630) | 新しく追加された | FastScanを有効にするかどうかを制御します。FastScan[ファストスキャン](/tiflash/use-fastscan.md)有効になっている場合（ `ON`に設定）、 TiFlashはより効率的なクエリパフォーマンスを提供しますが、クエリ結果の正確性やデータの一貫性は保証されません。 | +| [`tiflash_fastscan`](/system-variables.md#tiflash_fastscan-new-in-v630) | 新しく追加された | FastScanを有効にするかどうかを制御します。FastScan[ファストスキャン](/tiflash/use-fastscan.md)が有効になっている場合（ `ON`に設定）、 TiFlashはより効率的なクエリパフォーマンスを提供しますが、クエリ結果の正確性やデータの一貫性は保証されません。 | ### コンフィグレーションファイルパラメータ {#configuration-file-parameters} diff --git a/releases/release-6.5.12.md b/releases/release-6.5.12.md index a783c26e0d9d6..9ad6c65c0ddc9 100644 --- a/releases/release-6.5.12.md +++ b/releases/release-6.5.12.md @@ -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) - - 一意インデックスを追加するときに`duplicate entry`発生する可能性がある問題を修正 [＃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) - 特定の型変換エラーでエラーメッセージが正しく表示されない問題を修正 [＃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-7.1.0.md b/releases/release-7.1.0.md index 4a24396be239a..e95af6eaecd8c 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -275,7 +275,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | [`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) | 新しく追加された | この変数は、オプティマイザをより細かく制御し、オプティマイザの動作の変更によって引き起こされるアップグレード後のパフォーマンスの低下を防ぐのに役立ちます。 | | [`tidb_plan_cache_invalidation_on_fresh_stats`](/system-variables.md#tidb_plan_cache_invalidation_on_fresh_stats-new-in-v710) | 新しく追加された | 関連テーブルの統計が更新されたときにプランキャッシュを自動的に無効にするかどうかを制御します。 | | [`tidb_plan_cache_max_plan_size`](/system-variables.md#tidb_plan_cache_max_plan_size-new-in-v710) | 新しく追加された | プリペアドプランキャッシュまたは非プリペアドプランキャッシュにキャッシュできるプランの最大サイズを制御します。 | -| [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-new-in-v710) | 新しく追加された | ネットワーク転送のオーバーヘッドが最小となるアルゴリズムを使用するかどうかを制御します。この変数を有効にすると、TiDBはネットワークで交換されるデータのサイズをそれぞれ`Broadcast Hash Join`と`Shuffled Hash Join`で推定し、サイズが小さい方を選択します。この変数を有効にすると、 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50)と[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50)無効になります。 | +| [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-new-in-v710) | 新しく追加された | ネットワーク転送のオーバーヘッドが最小となるアルゴリズムを使用するかどうかを制御します。この変数を有効にすると、TiDBはネットワークで交換されるデータのサイズをそれぞれ`Broadcast Hash Join`と`Shuffled Hash Join`で推定し、サイズが小さい方を選択します。この変数を有効にすると、 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50)と[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50)が無効になります。 | | [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710) | 新しく追加された | キャッシュできるプランの最大数を制御します。プリペアドプランキャッシュと非プリペアドプランキャッシュは同じキャッシュを共有します。 | ### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} diff --git a/releases/release-7.1.3.md b/releases/release-7.1.3.md index 306c0661379e8..a31b1b70f200b 100644 --- a/releases/release-7.1.3.md +++ b/releases/release-7.1.3.md @@ -65,7 +65,7 @@ TiDB バージョン: 7.1.3 - 同じクエリプランで、場合によってはの異なる`PLAN_DIGEST`値が発生する問題を修正しました [＃47634](https://github.com/pingcap/tidb/issues/47634) @[King-Dylan](https://github.com/King-Dylan) - `GenJSONTableFromStats`大量のメモリを消費すると強制終了できない問題を修正[＃47779](https://github.com/pingcap/tidb/issues/47779) @[hawkingrei](https://github.com/hawkingrei) - 述語が共通テーブル式にプッシュダウンされたときに結果が不正確になる可能性がある問題を修正しました [＃47881](https://github.com/pingcap/tidb/issues/47881) @[winoros](https://github.com/winoros) - - `AUTO_ID_CACHE=1` に設定されている場合に`Duplicate entry`発生する可能性がある問題を修正しました [＃46444](https://github.com/pingcap/tidb/issues/46444) @[tiancaiamao](https://github.com/tiancaiamao) + - `AUTO_ID_CACHE=1` に設定されている場合に`Duplicate entry`が発生する可能性がある問題を修正しました [＃46444](https://github.com/pingcap/tidb/issues/46444) @[tiancaiamao](https://github.com/tiancaiamao) - 監査ログ用のEnterpriseプラグインを使用すると、TiDBサーバーが大量のリソースを消費する可能性がある問題を修正[＃49273](https://github.com/pingcap/tidb/issues/49273) @[lcwangchao](https://github.com/lcwangchao) - 正常なシャットダウン中に TiDBサーバーがpanicする可能性がある問題を修正[＃36793](https://github.com/pingcap/tidb/issues/36793) @[bb7133](https://github.com/bb7133) - テーブルがと多数ある場合に、テーブルが`AUTO_ID_CACHE=1`の場合に gRPC クライアント リークが発生する可能性がある問題を修正しました。 [＃48869](https://github.com/pingcap/tidb/issues/48869) @[tiancaiamao](https://github.com/tiancaiamao) @@ -76,7 +76,7 @@ TiDB バージョン: 7.1.3 - DUALテーブルを最初のサブノードとして`UNION ALL`を実行するとエラーが発生する可能性がある問題を修正しました。 [＃48755](https://github.com/pingcap/tidb/issues/48755) @[winoros](https://github.com/winoros) - DDL `jobID`が 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @[jiyfhust](https://github.com/jiyfhust) - `TABLESAMPLE` によって返されるソートされていない行データの問題を修正しました [＃48253](https://github.com/pingcap/tidb/issues/48253) @[tangenta](https://github.com/tangenta) - - `tidb_enable_ordered_result_mode`有効になっているときにpanicが発生する可能性がある問題を修正[＃45044](https://github.com/pingcap/tidb/issues/45044) @[qw4990](https://github.com/qw4990) + - `tidb_enable_ordered_result_mode`が有効になっているときにpanicが発生する可能性がある問題を修正[＃45044](https://github.com/pingcap/tidb/issues/45044) @[qw4990](https://github.com/qw4990) - ウィンドウ関数によって導入されたソートを削減するために、オプティマイザが誤って IndexFullScan を選択する問題を修正しました。 [＃46177](https://github.com/pingcap/tidb/issues/46177) @[qw4990](https://github.com/qw4990) - TiDBスキーマキャッシュからスキーマ差分コミットバージョンを読み取るときにMVCCインターフェースでロックを処理しない問題を修正しました [＃48281](https://github.com/pingcap/tidb/issues/48281) @[cfzjywxk](https://github.com/cfzjywxk) - `INDEX_LOOKUP_HASH_JOIN` でのメモリ使用量の見積もりが間違っている問題を修正 [＃47788](https://github.com/pingcap/tidb/issues/47788) @[SeaRise](https://github.com/SeaRise) diff --git a/releases/release-8.0.0.md b/releases/release-8.0.0.md index 0f0aab7728c77..a0ca6998c4f04 100644 --- a/releases/release-8.0.0.md +++ b/releases/release-8.0.0.md @@ -517,7 +517,7 @@ TiDB バージョン: 8.0.0 - 一部の極端なケースでフルバックアップがピアを見つけられなかった際にTiKVがパニックを起こす問題を修正 [#16394](https://github.com/tikv/tikv/issues/16394) @[Leavrth](https://github.com/Leavrth) - 同じノード上の TiKV IP アドレスを変更した後にログのバックアップが停止する問題を修正 [#50445](https://github.com/pingcap/tidb/issues/50445) @[3pointer](https://github.com/3pointer) - S3からファイルコンテンツを読み取る際にエラーが発生した場合にBRが再試行できない問題を修正 [#49942](https://github.com/pingcap/tidb/issues/49942) @[Leavrth](https://github.com/Leavrth) - - データ復元失敗後にチェックポイントから再開するとエラー`the target cluster is not fresh`発生する問題を修正 [#50232](https://github.com/pingcap/tidb/issues/50232) @[Leavrth](https://github.com/Leavrth) + - データ復元失敗後にチェックポイントから再開するとエラー`the target cluster is not fresh`が発生する問題を修正 [#50232](https://github.com/pingcap/tidb/issues/50232) @[Leavrth](https://github.com/Leavrth) - ログバックアップタスクを停止すると TiDB がクラッシュする問題を修正 [#50839](https://github.com/pingcap/tidb/issues/50839) @[YuJuncen](https://github.com/YuJuncen) - TiKVノードにリーダーがいないためにデータ復元が遅くなる問題を修正 [#50566](https://github.com/pingcap/tidb/issues/50566) @[Leavrth](https://github.com/Leavrth) - `--filter`オプションを指定した後でも完全復元ではターゲットクラスターが空である必要がある問題を修正 [#51009](https://github.com/pingcap/tidb/issues/51009) @[3pointer](https://github.com/3pointer) diff --git a/sql-statements/sql-statement-admin-checksum-table.md b/sql-statements/sql-statement-admin-checksum-table.md index 241698b32cf39..2b8fbbf85bb86 100644 --- a/sql-statements/sql-statement-admin-checksum-table.md +++ b/sql-statements/sql-statement-admin-checksum-table.md @@ -20,7 +20,7 @@ category: reference [チェックサム](https://docs.pingcap.com/tidb/stable/tidb-lightning-glossary#checksum)テーブルのデータと`table_id`などのプロパティに基づいて計算されます。つまり、同じデータを持ちながらも`table_id`値が異なる 2つのテーブルでは、チェックサムは異なります。 -[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE `実行されます。 +[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE
`が実行されます。 diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md index de890bc2f8d23..ed63172e8ada5 100644 --- a/ticdc/ticdc-avro-protocol.md +++ b/ticdc/ticdc-avro-protocol.md @@ -131,7 +131,7 @@ dispatchers = [ } ``` -`enable-tidb-extension`無効になっている値のデータ形式と比較すると、 `_tidb_op` 、 `_tidb_commit_ts` 、 `_tidb_commit_physical_time` 3つの新しいフィールドが追加されます。 +`enable-tidb-extension`が無効になっている値のデータ形式と比較すると、 `_tidb_op` 、 `_tidb_commit_ts` 、 `_tidb_commit_physical_time` 3つの新しいフィールドが追加されます。 ### カラムデータ形式 {#column-data-format} diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 2cfb8913dc02c..f231290598624 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -114,7 +114,7 @@ cdc cli changefeed list --server=http://127.0.0.1:8300 - **方法 2** : ダウンストリーム TiDB から Syncpoint をクエリします。 - ダウンストリームが TiDB クラスターであり、 [TiCDC 同期ポイント機能](/ticdc/ticdc-upstream-downstream-check.md)有効になっている場合は、ダウンストリーム TiDB の Syncpoint を照会することでレプリケーションの進行状況を取得できます。 + ダウンストリームが TiDB クラスターであり、 [TiCDC 同期ポイント機能](/ticdc/ticdc-upstream-downstream-check.md)が有効になっている場合は、ダウンストリーム TiDB の Syncpoint を照会することでレプリケーションの進行状況を取得できます。 > **Note:** > @@ -468,7 +468,7 @@ TiDBにはトランザクションタイムアウト機構があります。ト > **Note:** > -> 保存生成列をKafkaまたはストレージサービスにレプリケーションし、その後MySQLに書き戻すと、 `Error 3105 (HY000): The value specified for generated column 'xx' in table 'xxx' is not allowed`発生する可能性があります。このエラーを回避するには、レプリケーションに[オープンプロトコル](/ticdc/ticdc-open-protocol.md#ticdc-open-protocol)を使用します。このプロトコルの出力には[列のビットフラグ](/ticdc/ticdc-open-protocol.md#bit-flags-of-columns)含まれており、列が生成列かどうかを区別できます。 +> 保存生成列をKafkaまたはストレージサービスにレプリケーションし、その後MySQLに書き戻すと、 `Error 3105 (HY000): The value specified for generated column 'xx' in table 'xxx' is not allowed`が発生する可能性があります。このエラーを回避するには、レプリケーションに[オープンプロトコル](/ticdc/ticdc-open-protocol.md#ticdc-open-protocol)を使用します。このプロトコルの出力には[列のビットフラグ](/ticdc/ticdc-open-protocol.md#bit-flags-of-columns)含まれており、列が生成列かどうかを区別できます。 ## 頻繁に発生する`CDC:ErrMySQLDuplicateEntryCDC`エラーを解決するにはどうすればよいですか? {#how-do-i-resolve-frequent-cdcerrmysqlduplicateentrycdc-errors} @@ -504,7 +504,7 @@ UPDATE data_table SET value = 'v3' WHERE id = 1; UPDATE data_table SET value = 'v1' WHERE id = 2; ``` -2 番目の`UPDATE`ステートメントを実行するときにダウンストリームテーブルにまだ`v1`含まれている場合、 `value`列の一意キー制約に違反し、 `CDC:ErrMySQLDuplicateEntryCDC`エラーが発生します。 +2 番目の`UPDATE`ステートメントを実行するときにダウンストリームテーブルにまだ`v1`が含まれている場合、 `value`列の一意キー制約に違反し、 `CDC:ErrMySQLDuplicateEntryCDC`エラーが発生します。 `CDC:ErrMySQLDuplicateEntryCDC`エラーが頻繁に発生する場合は、 [`sink-uri`](/ticdc/ticdc-sink-to-mysql.md#configure-sink-uri-for-mysql-or-tidb)構成で`safe-mode=true`パラメータを設定することで TiCDC セーフモードを有効にすることができます。 diff --git a/tidb-cloud/csv-config-for-import-data.md b/tidb-cloud/csv-config-for-import-data.md index 6f34aef20d5f7..2069f100d9966 100644 --- a/tidb-cloud/csv-config-for-import-data.md +++ b/tidb-cloud/csv-config-for-import-data.md @@ -28,7 +28,7 @@ summary: TiDB Cloudのインポートデータサービスで CSV 構成を使 - 共通の値: - - `'"'`フィールドを二重引用符で囲みます。上のスクリーンショットに示すように、 `"Michael","male"` 2つのフィールドを表します。2つのフィールドの間には必ず`,`必要です。データが`"Michael""male"` （ `,`なし）の場合、インポートタスクは解析に失敗します。データが`"Michael,male"` （二重引用符が1つだけ）の場合、1つのフィールドとして解析されます。 + - `'"'`フィールドを二重引用符で囲みます。上のスクリーンショットに示すように、 `"Michael","male"` 2つのフィールドを表します。2つのフィールドの間には必ず`,`が必要です。データが`"Michael""male"` （ `,`なし）の場合、インポートタスクは解析に失敗します。データが`"Michael,male"` （二重引用符が1つだけ）の場合、1つのフィールドとして解析されます。 - `''`引用を無効にします。 - デフォルト: `"` diff --git a/tiproxy/tiproxy-traffic-replay.md b/tiproxy/tiproxy-traffic-replay.md index ed7652ad63ec3..51af4d008faf4 100644 --- a/tiproxy/tiproxy-traffic-replay.md +++ b/tiproxy/tiproxy-traffic-replay.md @@ -186,7 +186,7 @@ tiproxyctl traffic cancel --host 10.0.1.10 --port 3080 - TiProxyは、TiProxyによってキャプチャされたトラフィックファイルの再生のみをサポートしており、他のファイル形式はサポートしていません。そのため、まずはTiProxyを使用して本番クラスタからトラフィックをキャプチャしてください。 - TiProxyトラフィックの再生はSQLタイプのフィルタリングをサポートしておらず、DMLおよびDDL文が再生されます。そのため、再度再生する前に、クラスターデータを再生前の状態に復元する必要があります。 -- TiProxy トラフィック再生では、トラフィックの再生に同じユーザー名が使用されるため、テスト[リソース管理](/tidb-resource-control-ru-groups.md)と[権限管理](/privilege-management.md)サポートされません。 +- TiProxy トラフィック再生では、トラフィックの再生に同じユーザー名が使用されるため、テスト[リソース管理](/tidb-resource-control-ru-groups.md)と[権限管理](/privilege-management.md)がサポートされません。 - TiProxy は[`LOAD DATA`](/sql-statements/sql-statement-load-data.md)ステートメントの再生をサポートしていません。 ## その他のリソース {#more-resources} diff --git a/troubleshoot-data-inconsistency-errors.md b/troubleshoot-data-inconsistency-errors.md index 8059682b1f478..3a74bff7702ad 100644 --- a/troubleshoot-data-inconsistency-errors.md +++ b/troubleshoot-data-inconsistency-errors.md @@ -55,7 +55,7 @@ TiDBは、トランザクションまたは[`ADMIN CHECK [TABLE|INDEX]`](/sql-st `ERROR 8141 (HY000): assertion failed: key: 7480000000000000405f72013300000000000000f8, assertion: NotExist, start_ts: 430590532931813377, existing start ts: 430590532931551233, existing commit ts: 430590532931551234` -このエラーは、トランザクションのコミット時にアサーションが失敗したことを示しています。データとインデックスが整合していると仮定すると、TiDBはキー`7480000000000000405f720133000000000000000000f8`存在しないとアサートしました。トランザクションのコミット時に、TiDBはトランザクションによって`start ts` `430590532931551233`で書き込まれたキーが存在することを検出しました。TiDBはこのキーのマルチバージョン同時実行制御（MVCC）履歴をログに出力します。 +このエラーは、トランザクションのコミット時にアサーションが失敗したことを示しています。データとインデックスが整合していると仮定すると、TiDBはキー`7480000000000000405f720133000000000000000000f8`が存在しないとアサートしました。トランザクションのコミット時に、TiDBはトランザクションによって`start ts` `430590532931551233`で書き込まれたキーが存在することを検出しました。TiDBはこのキーのマルチバージョン同時実行制御（MVCC）履歴をログに出力します。 ### 管理者チェックで報告されたエラー {#errors-reported-in-admin-check} From 863d17ac22d05578ed3d808cd01879ac72d85117 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Fri, 28 Aug 2026 17:48:17 +0900 Subject: [PATCH 5/5] i18n(ja): fix additional CodeRabbit-flagged grammar issues MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fix 12 remaining grammar defects flagged by CodeRabbit on PR #23624: missing sentence boundary (auto-random.md), OR condition word order (multi-column-index-best-practices.md), missing は/が/の/に particles (br-auto-tune.md, migrate-from-tidb-to-tidb.md, release-3.0.2.md, release-5.3.1.md, release-5.4.1.md, sql-statement-load-data.md, ticdc-avro-protocol.md, ticdc-faq.md, csv-config-for-import-data.md), mistranslated "Follower Read" feature name as a full sentence (schedule-replicas-by-topology-labels.md), and a garbled list separator in an EXPLAIN table row (sql-statement-explain.md). All verified against the English source before applying. --- auto-random.md | 2 +- best-practices/multi-column-index-best-practices.md | 2 +- br/br-auto-tune.md | 2 +- migrate-from-tidb-to-tidb.md | 2 +- releases/release-3.0.2.md | 2 +- releases/release-5.3.1.md | 2 +- releases/release-5.4.1.md | 2 +- schedule-replicas-by-topology-labels.md | 2 +- sql-statements/sql-statement-explain.md | 2 +- sql-statements/sql-statement-load-data.md | 2 +- ticdc/ticdc-avro-protocol.md | 2 +- ticdc/ticdc-faq.md | 2 +- tidb-cloud/csv-config-for-import-data.md | 2 +- 13 files changed, 13 insertions(+), 13 deletions(-) diff --git a/auto-random.md b/auto-random.md index fac4007c008d4..da60ee148c535 100644 --- a/auto-random.md +++ b/auto-random.md @@ -205,7 +205,7 @@ ALTER TABLE t FORCE AUTO_RANDOM_BASE = 1000; `AUTO_RANDOM`を使用する場合は、次の制限に注意してください。 - 明示的に値を挿入するには、システム変数`@@allow_auto_random_explicit_insert`の値を`1` （デフォルトは`0` ）に設定する必要があります。データを挿入する際に、属性`AUTO_RANDOM`持つ列に明示的に値を指定することは推奨さ**れません**。そうしないと、このテーブルに自動的に割り当てられる数値が事前に使い果たされてしまう可能性があります。 -- この属性は、主キー列に**のみ**`BIGINT`型で指定してください。それ以外の場合はエラーが発生します。また、主キーの属性が`NONCLUSTERED`の場合、整数型の主キーであっても`AUTO_RANDOM`がサポートされません`CLUSTERED`型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 +- この属性は、主キー列に**のみ**`BIGINT`型で指定してください。それ以外の場合はエラーが発生します。また、主キーの属性が`NONCLUSTERED`の場合、整数型の主キーであっても`AUTO_RANDOM`がサポートされません。`CLUSTERED`型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 - `ALTER TABLE`を使用して`AUTO_RANDOM`属性を変更することはできません (この属性の追加や削除を含む)。 - 最大値が列タイプの最大値に近い場合は、 `ALTER TABLE`を使用して`AUTO_INCREMENT`から`AUTO_RANDOM`に変更することはできません。 - `AUTO_RANDOM`属性で指定された主キー列の列タイプを変更することはできません。 diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index b52412646df9f..6e45c0f3d287f 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -160,7 +160,7 @@ EXPLAIN FORMAT = "brief" ### 例2: 重複しない範囲 {#example-2-non-overlapping-ranges} -別のシナリオとして、サンフランシスコまたはサンディエゴで手頃な価格のシングルベッドルーム物件を検索するクエリを想像してみてください。ここでは、条件`OR`が異なる都市の2つの異なる範囲を指定しています。 +別のシナリオとして、サンフランシスコまたはサンディエゴで手頃な価格のシングルベッドルーム物件を検索するクエリを想像してみてください。ここでは、`OR`条件が異なる都市の2つの異なる範囲を指定しています。 - サンフランシスコの物件、1ベッドルーム、価格`$1,500` ～ `$2,500` - サンディエゴの物件、1ベッドルーム、価格`$1,000` ～ `$1,500` diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md index fe49230465a26..dabffbd4ea829 100644 --- a/br/br-auto-tune.md +++ b/br/br-auto-tune.md @@ -13,7 +13,7 @@ TiDB v5.4.0より前のバージョンでは、バックアップ＆リストア バックアップタスクがクラスタに与える影響を軽減したい場合は、自動チューニング機能を有効にできます。この機能を有効にすると、TiDBはクラスタに過度の影響を与えることなく、可能な限り高速にバックアップタスクを実行します。 -あるいは、TiKV設定項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)またはパラメータ`--ratelimit`を使用してバックアップ速度を制限することもできます。 `--ratelimit`が設定されている場合、タスクが多すぎて速度制限を超えてしまうのを防ぐため、br のパラメータ`concurrency`自動的に`1`に調整されます。 +あるいは、TiKV設定項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)またはパラメータ`--ratelimit`を使用してバックアップ速度を制限することもできます。 `--ratelimit`が設定されている場合、タスクが多すぎて速度制限を超えてしまうのを防ぐため、br のパラメータ`concurrency`は自動的に`1`に調整されます。 ## オートチューンを使用する {#use-auto-tune} diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index 2e83065799f78..3f5d34676319e 100644 --- a/migrate-from-tidb-to-tidb.md +++ b/migrate-from-tidb-to-tidb.md @@ -138,7 +138,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー > **Note:** > - > TiCDC `gc-ttl`デフォルトで24時間です。バックアップと復元に時間がかかる場合、デフォルトの`gc-ttl`不十分で、その後の[増分レプリケーションタスク](#step-3-migrate-incremental-data)が失敗する可能性があります。このような状況を回避するには、TiCDCサーバーを起動する際に、特定のニーズに合わせて`gc-ttl`値を調整してください。詳細については、 [TiCDCにおける`gc-ttl`とは](/ticdc/ticdc-faq.md#what-is-gc-ttl-in-ticdc)を参照してください。 + > TiCDCの`gc-ttl`はデフォルトで24時間です。バックアップと復元に時間がかかる場合、デフォルトの`gc-ttl`では不十分で、その後の[増分レプリケーションタスク](#step-3-migrate-incremental-data)が失敗する可能性があります。このような状況を回避するには、TiCDCサーバーを起動する際に、特定のニーズに合わせて`gc-ttl`の値を調整してください。詳細については、 [TiCDCにおける`gc-ttl`とは](/ticdc/ticdc-faq.md#what-is-gc-ttl-in-ticdc)を参照してください。 2. データをバックアップします。 diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index 361fcf98114c8..e298d7e7cd238 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -26,7 +26,7 @@ TiDB Ansible バージョン: 3.0.2 - オプティマイザが時間等条件正しく推定しない問題を修正 [＃11512](https://github.com/pingcap/tidb/pull/11512) - フィードバック情報に基づいてトップN統計を更新することをサポート[＃11507](https://github.com/pingcap/tidb/pull/11507) - SQL実行エンジン - - 関数`INSERT`パラメータに`NULL`が含まれている場合、戻り値が`NULL`ならない問題を修正しました。 [＃11248](https://github.com/pingcap/tidb/pull/11248) + - 関数`INSERT`のパラメータに`NULL`が含まれている場合、戻り値が`NULL`にならない問題を修正しました。 [＃11248](https://github.com/pingcap/tidb/pull/11248) - パーティションテーブルを`ADMIN CHECKSUM`操作でチェックすると計算結果が間違っている可能性がある問題を修正しました [＃11266](https://github.com/pingcap/tidb/pull/11266) - INDEX JOIN がプレフィックスインデックスを使用すると結果が間違ってしまう可能性がある問題を修正しました [＃11246](https://github.com/pingcap/tidb/pull/11246) - `DATE_ADD`関数がマイクロ秒を含む日付数値の減算を行う際に分数の配置が誤っているために結果が間違っている可能性がある問題を修正しました[＃11288](https://github.com/pingcap/tidb/pull/11288) diff --git a/releases/release-5.3.1.md b/releases/release-5.3.1.md index f607013bf9f03..7ecf08cac12e6 100644 --- a/releases/release-5.3.1.md +++ b/releases/release-5.3.1.md @@ -58,7 +58,7 @@ TiDB バージョン: 5.3.1 - TiDBの`date_format`が`'\n'` MySQLと互換性のない方法で処理する問題を修正[＃32232](https://github.com/pingcap/tidb/issues/32232) - `alter column set default`テーブルスキーマを誤って更新する問題を修正 [＃31074](https://github.com/pingcap/tidb/issues/31074) - - `tidb_restricted_read_only`が有効になっているときに`tidb_super_read_only`自動的に有効にならないバグを修正[＃31745](https://github.com/pingcap/tidb/issues/31745) + - `tidb_restricted_read_only`が有効になっているときに`tidb_super_read_only`が自動的に有効にならないバグを修正[＃31745](https://github.com/pingcap/tidb/issues/31745) - 照合順序`greatest`または`least`関数が間違った結果を返す問題を修正しました[＃31789](https://github.com/pingcap/tidb/issues/31789) - クエリ実行時に MPP タスクリストが空になるエラーを修正 [＃31636](https://github.com/pingcap/tidb/issues/31636) - innerWorker panicによって発生するインデックス結合の誤った結果を修正しました [＃31494](https://github.com/pingcap/tidb/issues/31494) diff --git a/releases/release-5.4.1.md b/releases/release-5.4.1.md index db39196fc87b0..ed9bf40ff5d62 100644 --- a/releases/release-5.4.1.md +++ b/releases/release-5.4.1.md @@ -58,7 +58,7 @@ TiDB v5.4.1では、製品設計上の互換性に関する変更は行われて - クエリがエラーを報告したときに CTE がブロックされる可能性があるバグを修正[＃31302](https://github.com/pingcap/tidb/issues/31302) - 列挙値の Nulleq 関数の誤った範囲計算結果を修正しました [＃32428](https://github.com/pingcap/tidb/issues/32428) - ChunkRPC を使用してデータをエクスポートする際の TiDB OOM を修正 [＃30880](https://github.com/pingcap/tidb/issues/30880) [＃31981](https://github.com/pingcap/tidb/issues/31981) - - `tidb_restricted_read_only`が有効になっているときに`tidb_super_read_only`自動的に有効にならないバグを修正[＃31745](https://github.com/pingcap/tidb/issues/31745) + - `tidb_restricted_read_only`が有効になっているときに`tidb_super_read_only`が自動的に有効にならないバグを修正[＃31745](https://github.com/pingcap/tidb/issues/31745) - 照合順序`greatest`または`least`関数が間違った結果を返す問題を修正しました[＃31789](https://github.com/pingcap/tidb/issues/31789) - データがエスケープ文字で壊れている場合のロードデータpanicを修正 [＃31589](https://github.com/pingcap/tidb/issues/31589) - インデックスルックアップ結合を使用してクエリを実行するときに発生する`invalid transaction`エラーを修正します [＃30468](https://github.com/pingcap/tidb/issues/30468) diff --git a/schedule-replicas-by-topology-labels.md b/schedule-replicas-by-topology-labels.md index 685530981b44a..79de7bf4194f6 100644 --- a/schedule-replicas-by-topology-labels.md +++ b/schedule-replicas-by-topology-labels.md @@ -198,7 +198,7 @@ host = "" #### (オプション) TiDBの`labels`を構成する {#optional-configure-labels-for-tidb} -[Followerが読んだ](/follower-read.md)が有効になっている場合、TiDB が同じリージョンからのデータを優先的に読み取るようにするには、TiDB ノードに対して`labels`を設定する必要があります。 +[Follower Read](/follower-read.md)が有効になっている場合、TiDB が同じリージョンからのデータを優先的に読み取るようにするには、TiDB ノードに対して`labels`を設定する必要があります。 構成ファイルを使用して、TiDB に`labels`を設定できます。 diff --git a/sql-statements/sql-statement-explain.md b/sql-statements/sql-statement-explain.md index 23fbe5ff6cab3..a257682e8eca1 100644 --- a/sql-statements/sql-statement-explain.md +++ b/sql-statements/sql-statement-explain.md @@ -52,7 +52,7 @@ ExplainableStmt ::= | id | オペレータIDは、実行計画全体におけるオペレータの一意の識別子です。TiDB 2.1では、このIDはオペレータのツリー構造を表すようにフォーマットされています。データは子ノードから親ノードへと流れます。オペレータごとに親ノードは1つだけです。 | | estRows | 演算子が出力すると予想される行数。この数は、統計情報と演算子のロジックに基づいて推定されます。`estRows`は、TiDB 4.0 の以前のバージョンでは`count`と呼ばれていました。 | | タスク | オペレータが属するタスクの種類。現在、実行計画は tidb-server 上で実行される**ルート**タスクと、 TiKV またはTiFlash上で並列実行される**cop**タスクの2つのタスクに分かれています。タスクレベルでの実行計画のトポロジは、ルートタスクの後に多数の cop タスクが続くというものです。ルートタスクは cop タスクの出力を入力として使用します。cop タスクとは、TiDB が TiKV またはTiFlashにプッシュダウンするタスクを指します。各 cop タスクは TiKV クラスターまたはTiFlashクラスターに分散され、複数のプロセスによって実行されます。 | -| アクセスオブジェクト | オペレータがアクセスするデータ項目情報。この情報には、 `table` 、および`index` （存在する場合） `partition`が含まれます。この情報は、データに直接アクセスするオペレータのみが使用できます。 | +| アクセスオブジェクト | オペレータがアクセスするデータ項目情報。この情報には、`table`、`index`（存在する場合）、`partition`が含まれます。この情報は、データに直接アクセスするオペレータのみが使用できます。 | | オペレーター情報 | 演算子に関するその他の情報。演算子ごとに`operator info`が異なります。以下の例を参照してください。 | ## 例 {#examples} diff --git a/sql-statements/sql-statement-load-data.md b/sql-statements/sql-statement-load-data.md index 4ec14364e1ca3..43639b800376c 100644 --- a/sql-statements/sql-statement-load-data.md +++ b/sql-statements/sql-statement-load-data.md @@ -207,7 +207,7 @@ IGNORE 1 LINES; > - TiDB v4.0.0 より前のバージョンでは、20000 行ごとに`LOAD DATA`コミットが実行され、これは構成できません。 > - TiDB v4.0.0 から v6.6.0 までのバージョンでは、TiDB はデフォルトですべての行を 1つのトランザクションでコミットします。ただし、 `LOAD DATA`ステートメントで一定数の行をコミットする必要がある場合は、必要な行数を[`tidb_dml_batch_size`](/system-variables.md#tidb_dml_batch_size)に設定できます。 > - v7.0.0 以降、 `tidb_dml_batch_size` `LOAD DATA`には影響しなくなり、 TiDB は 1つのトランザクションですべての行をコミットします。 -> - TiDB v4.0.0以前のバージョンからアップグレードすると、 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058`が発生する場合があります。このエラーを解決するには、 [TiDB Cloudサポート](https://docs.pingcap.com/tidbcloud/tidb-cloud-support)連絡して[`txn-total-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-total-size-limit)値を増やすことができます。 +> - TiDB v4.0.0以前のバージョンからアップグレードすると、 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058`が発生する場合があります。このエラーを解決するには、 [TiDB Cloudサポート](https://docs.pingcap.com/tidbcloud/tidb-cloud-support)に連絡して[`txn-total-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-total-size-limit)の値を増やすことができます。 > - TiDB v7.6.0 より前のバージョンでは、トランザクションでコミットされる行数に関係なく、明示的なトランザクションの[`ROLLBACK`](/sql-statements/sql-statement-rollback.md)ステートメントによって`LOAD DATA`ロールバックされることはありません。 > - TiDB v7.6.0 より前のバージョンでは、TiDB トランザクションモードの構成に関係なく、 `LOAD DATA`ステートメントは常に楽観的トランザクションモードで実行されます。 > - v7.6.0 以降、TiDB は他の DML ステートメントと同じ方法で`LOAD DATA` in トランザクションを処理します。 diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md index c037f95eb01b8..e690300a5fe87 100644 --- a/ticdc/ticdc-avro-protocol.md +++ b/ticdc/ticdc-avro-protocol.md @@ -131,7 +131,7 @@ dispatchers = [ } ``` -`enable-tidb-extension`が無効になっている値のデータ形式と比較すると、 `_tidb_op` 、 `_tidb_commit_ts` 、 `_tidb_commit_physical_time` 3つの新しいフィールドが追加されます。 +`enable-tidb-extension`が無効になっている値のデータ形式と比較すると、 `_tidb_op` 、 `_tidb_commit_ts` 、 `_tidb_commit_physical_time`の3つの新しいフィールドが追加されます。 ### カラムデータ形式 {#column-data-format} diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 5c826845a2e8e..a4cd5e1ecd430 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -468,7 +468,7 @@ TiDBにはトランザクションタイムアウト機構があります。ト > **Note:** > -> 保存生成列をKafkaまたはストレージサービスにレプリケーションし、その後MySQLに書き戻すと、 `Error 3105 (HY000): The value specified for generated column 'xx' in table 'xxx' is not allowed`が発生する可能性があります。このエラーを回避するには、レプリケーションに[オープンプロトコル](/ticdc/ticdc-open-protocol.md#ticdc-open-protocol)を使用します。このプロトコルの出力には[列のビットフラグ](/ticdc/ticdc-open-protocol.md#bit-flags-of-columns)含まれており、列が生成列かどうかを区別できます。 +> 保存生成列をKafkaまたはストレージサービスにレプリケーションし、その後MySQLに書き戻すと、 `Error 3105 (HY000): The value specified for generated column 'xx' in table 'xxx' is not allowed`が発生する可能性があります。このエラーを回避するには、レプリケーションに[オープンプロトコル](/ticdc/ticdc-open-protocol.md#ticdc-open-protocol)を使用します。このプロトコルの出力には[列のビットフラグ](/ticdc/ticdc-open-protocol.md#bit-flags-of-columns)が含まれており、列が生成列かどうかを区別できます。 ## 頻繁に発生する`CDC:ErrMySQLDuplicateEntryCDC`エラーを解決するにはどうすればよいですか? {#how-do-i-resolve-frequent-cdcerrmysqlduplicateentrycdc-errors} diff --git a/tidb-cloud/csv-config-for-import-data.md b/tidb-cloud/csv-config-for-import-data.md index e30e3d976568f..30cd97452f125 100644 --- a/tidb-cloud/csv-config-for-import-data.md +++ b/tidb-cloud/csv-config-for-import-data.md @@ -28,7 +28,7 @@ summary: TiDB Cloudのインポートデータサービスで CSV 構成を使 - 共通の値: - - `'"'`フィールドを二重引用符で囲みます。上のスクリーンショットに示すように、 `"Michael","male"` 2つのフィールドを表します。2つのフィールドの間には必ず`,`が必要です。データが`"Michael""male"` （ `,`なし）の場合、インポートタスクは解析に失敗します。データが`"Michael,male"` （二重引用符が1つだけ）の場合、1つのフィールドとして解析されます。 + - `'"'`はフィールドを二重引用符で囲みます。上のスクリーンショットに示すように、 `"Michael","male"`は2つのフィールドを表します。2つのフィールドの間には必ず`,`が必要です。データが`"Michael""male"` （ `,`なし）の場合、インポートタスクは解析に失敗します。データが`"Michael,male"` （二重引用符が1つだけ）の場合、1つのフィールドとして解析されます。 - `''`引用を無効にします。 - デフォルト: `"`