From 2e3f0241fd8c983f2a4427cef078d34e3f51b3d4 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 09:55:45 +0900 Subject: [PATCH 1/3] i18n(ja): unify the Japanese term for 'request' (part B) Split from PR #23774 into two halves to stay under CodeRabbit's 150-file review limit (originally 197 files). See PR #23774 for the full context and review history -- both halves together are this same corpus-wide term-unification plus the incidental mistranslation fixes found while reviewing it. Co-Authored-By: Claude Sonnet 5 --- releases/release-6.3.0.md | 8 +- releases/release-6.4.0.md | 10 +- releases/release-6.5.0.md | 6 +- releases/release-6.5.10.md | 2 +- releases/release-6.5.11.md | 2 +- releases/release-6.5.5.md | 2 +- releases/release-6.5.6.md | 2 +- releases/release-6.6.0.md | 8 +- releases/release-7.0.0.md | 6 +- releases/release-7.1.0.md | 4 +- releases/release-7.1.2.md | 6 +- releases/release-7.1.5.md | 2 +- releases/release-7.1.6.md | 8 +- releases/release-7.2.0.md | 4 +- releases/release-7.4.0.md | 2 +- releases/release-7.5.0.md | 4 +- releases/release-7.5.2.md | 2 +- releases/release-7.5.3.md | 2 +- releases/release-7.5.4.md | 4 +- releases/release-7.5.7.md | 2 +- releases/release-7.6.0.md | 4 +- releases/release-8.0.0.md | 2 +- releases/release-8.1.0.md | 2 +- releases/release-8.1.1.md | 2 +- releases/release-8.1.2.md | 4 +- releases/release-8.2.0.md | 2 +- releases/release-8.3.0.md | 2 +- releases/release-8.4.0.md | 8 +- releases/release-8.5.0.md | 2 +- releases/release-8.5.4.md | 2 +- releases/release-8.5.6.md | 8 +- smooth-upgrade-tidb.md | 4 +- .../sql-statement-explain-analyze.md | 4 +- ...statement-lock-tables-and-unlock-tables.md | 2 +- sql-statements/sql-statement-split-region.md | 2 +- stale-read.md | 6 +- statement-summary-tables.md | 2 +- system-variables.md | 34 +-- ticdc/monitor-ticdc.md | 242 +++++++++--------- ticdc/ticdc-architecture.md | 2 +- ticdc/ticdc-faq.md | 2 +- ticdc/ticdc-overview.md | 2 +- ticdc/ticdc-server-config.md | 2 +- ticdc/ticdc-sink-to-kafka.md | 2 +- ticdc/ticdc-split-update-behavior.md | 2 +- tidb-cloud/architecture-concepts.md | 2 +- tidb-cloud/changefeed-sink-to-apache-kafka.md | 8 +- .../changefeed-sink-to-apache-pulsar.md | 2 +- tidb-cloud/data-service-api-key.md | 2 +- tidb-cloud/import-csv-files.md | 4 +- tidb-cloud/import-parquet-files.md | 4 +- tidb-cloud/import-sample-data.md | 4 +- ...migrate-from-mysql-using-data-migration.md | 12 +- ...al-data-from-mysql-using-data-migration.md | 4 +- tidb-cloud/monitor-datadog-integration.md | 2 +- tidb-cloud/monitor-new-relic-integration.md | 2 +- tidb-cloud/optimize-resource-allocation.md | 2 +- tidb-cloud/plan-replayer.md | 2 +- tidb-cloud/releases/release-notes-2023.md | 4 +- .../releases/tidb-cloud-release-notes.md | 2 +- tidb-cloud/serverless-high-availability.md | 2 +- .../serverless-private-link-connection.md | 8 +- tidb-cloud/set-up-sink-private-endpoint.md | 2 +- tidb-cloud/set-up-vpc-peering-connections.md | 2 +- tidb-cloud/tidb-cloud-auditing.md | 2 +- tidb-cloud/tidb-cloud-glossary.md | 2 +- .../tidb-cloud-tune-performance-overview.md | 6 +- tidb-cloud/v8.5-performance-highlights.md | 2 +- tidb-configuration-file.md | 4 +- .../tidb-lightning-configuration.md | 2 +- tidb-performance-tuning-config.md | 14 +- tidb-resource-control-ru-groups.md | 6 +- tidb-troubleshooting-map.md | 10 +- tiflash-performance-tuning-methods.md | 12 +- tiflash/maintain-tiflash.md | 6 +- tiflash/monitor-tiflash.md | 12 +- tiflash/tiflash-configuration.md | 20 +- tiflash/tiflash-mintso-scheduler.md | 4 +- tiflash/tiflash-overview.md | 2 +- tiflash/tiflash-pipeline-model.md | 2 +- tiflash/tiflash-results-materialization.md | 2 +- tikv-configuration-file.md | 48 ++-- tikv-control.md | 2 +- tikv-in-memory-engine.md | 8 +- tiproxy/tiproxy-configuration.md | 2 +- tiproxy/tiproxy-load-balance.md | 10 +- tiup/tiup-command-clean.md | 2 +- tiup/tiup-command-mirror-merge.md | 2 +- tiup/tiup-command-status.md | 2 +- tiup/tiup-component-cluster-stop.md | 2 +- tiup/tiup-component-cluster-tls.md | 2 +- tiup/tiup-component-dm-reload.md | 2 +- tiup/tiup-mirror-reference.md | 12 +- troubleshoot-hot-spot-issues.md | 2 +- troubleshoot-lock-conflicts.md | 16 +- troubleshoot-write-conflicts.md | 2 +- tune-region-performance.md | 6 +- tune-tikv-thread-performance.md | 14 +- 98 files changed, 372 insertions(+), 372 deletions(-) diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index a1a3e43e73181..2dee3801c6856 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -213,7 +213,7 @@ TiDBバージョン: 6.3.0-DMR | --------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [`default_authentication_plugin`](/system-variables.md#default_authentication_plugin) | 変更 | 新しいオプション`tidb_sm3_password`を追加します。この変数を`tidb_sm3_password`に設定すると、暗号化アルゴリズムとして SM3 が使用されます。 | | [`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_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_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) | 新しく追加された | インデックス作成時のバックフィル速度を向上させるために、 `ADD INDEX`および`CREATE INDEX` DDL 操作の高速化を有効にするかどうかを制御します。 | @@ -225,11 +225,11 @@ TiDBバージョン: 6.3.0-DMR | [`tidb_enable_null_aware_anti_join`](/system-variables.md#tidb_enable_null_aware_anti_join-new-in-v630) | 新しく追加された | 特殊な集合演算子`NOT IN`および`!= ALL`を制御します。 | | [`tidb_enable_pseudo_for_outdated_stats`](/system-variables.md#tidb_enable_pseudo_for_outdated_stats-new-in-v530) | 変更 | 統計情報が古くなっている場合に、オプティマイザがテーブルの統計情報を使用する動作を制御します。デフォルト値は`ON`から`OFF`に変更されます。これは、テーブルの統計情報が古くなっている場合でも、オプティマイザが引き続きテーブルの統計情報を使用することを意味します。 | | [`tidb_enable_rate_limit_action`](/system-variables.md#tidb_enable_rate_limit_action) | 変更 | データを読み取るオペレーターの動的メモリ制御機能を有効にするかどうかを制御します。この変数が`ON`に設定されている場合、メモリ使用量は[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)の制御下にない可能性があります。そのため、デフォルト値は`ON`から`OFF`に変更されます。 | -| [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 新しく追加された | SQL書き込みステートメント内の読み取り要求をTiFlashにプッシュダウンするかどうかを制御します。この変数で制御される機能は、TiDB v6.3.0では完全には動作しません。デフォルト値は変更しないでください。 | +| [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 新しく追加された | SQL書き込みステートメント内の読み取りリクエストをTiFlashにプッシュダウンするかどうかを制御します。この変数で制御される機能は、TiDB v6.3.0では完全には動作しません。デフォルト値は変更しないでください。 | | [`tidb_enable_unsafe_substitute`](/system-variables.md#tidb_enable_unsafe_substitute-new-in-v630) | 新しく追加された | 式を生成列に安全でない方法で置き換えるかどうかを制御します。 | | `tidb_general_plan_cache_size` | 新しく追加された | 一般プランキャッシュでキャッシュできる実行計画の最大数を制御します。この変数で制御される機能は、TiDB v6.3.0 では完全には動作しません。デフォルト値を変更しないでください。 | | [`tidb_last_plan_replayer_token`](/system-variables.md#tidb_enable_unsafe_substitute-new-in-v630) | 新しく追加された | 読み取り専用であり、現在のセッションでの最後の`PLAN REPLAYER DUMP`実行の結果を取得するために使用されます。 | -| [tidb_max_paging_size](/system-variables.md#tidb_max_paging_size-new-in-v630) | 新しく追加された | この変数は、コプロセッサのページング要求処理中に最小行数を設定するために使用されます。 | +| [tidb_max_paging_size](/system-variables.md#tidb_max_paging_size-new-in-v630) | 新しく追加された | この変数は、コプロセッサのページングリクエスト処理中に最小行数を設定するために使用されます。 | | [`tidb_opt_force_inline_cte`](/system-variables.md#tidb_opt_force_inline_cte-new-in-v630) | 新しく追加された | セッション全体の共通テーブル式 (CTE) をインライン化するかどうかを制御します。デフォルト値は`OFF`で、これはデフォルトでは CTE のインライン化が強制されないことを意味します。 | | [`tidb_opt_three_stage_distinct_agg`](/system-variables.md#tidb_opt_three_stage_distinct_agg-new-in-v630) | 新しく追加された | `COUNT(DISTINCT)`集計を MPP モードで 3 段階集計に書き換えるかどうかを指定します。デフォルト値は`ON`です。 | | [`tidb_partition_prune_mode`](/system-variables.md#tidb_partition_prune_mode-new-in-v51) | 変更 | 動的剪定を有効にするかどうかを指定します。v6.3.0 以降、デフォルト値は`dynamic`に変更されます。 | @@ -249,7 +249,7 @@ TiDBバージョン: 6.3.0-DMR | TiKV | [`log-backup.enable`](/tikv-configuration-file.md#enable-new-in-v620) | 変更 | バージョン6.3.0以降、デフォルト値が`false`から`true`に変更されました。 | | TiKV | [`log-backup.max-flush-interval`](/tikv-configuration-file.md#max-flush-interval-new-in-v620) | 変更 | バージョン6.3.0以降、デフォルト値が`5min`から`3min`に変更されました。 | | PD | [診断を有効にする](/pd-configuration-file.md#enable-diagnostic-new-in-v630) | 新しく追加された | 診断機能を有効にするかどうかを制御します。デフォルト値は`false`です。 | -| TiFlash | [`dt_enable_read_thread`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 非推奨 | バージョン6.3.0以降、この設定項目は非推奨となりました。デフォルトでは、スレッドプールがストレージエンジンからの読み取り要求を処理するために使用され、無効にすることはできません。 | +| TiFlash | [`dt_enable_read_thread`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 非推奨 | バージョン6.3.0以降、この設定項目は非推奨となりました。デフォルトでは、スレッドプールがストレージエンジンからの読み取りリクエストを処理するために使用され、無効にすることはできません。 | | DM | [`safe-mode-duration`](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced) | 新しく追加された | 自動セーフモードの継続時間を指定します。 | | TiCDC | [`enable-sync-point`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | Syncpoint機能を有効にするかどうかを指定します。 | | TiCDC | [`sync-point-interval`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | Syncpointがアップストリームとダウンストリームのスナップショットを同期させる間隔を指定します。 | diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 1aed2954a9705..269b85ab161cf 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -95,7 +95,7 @@ TiDBバージョン: 6.4.0-DMR - TiDBチャンク再利用メカニズムの強化 [#38606](https://github.com/pingcap/tidb/issues/38606) @[keeplearning20221](https://github.com/keeplearning20221) - 以前のバージョンでは、TiDB は`writechunk`関数内でのみチャンクを再利用していました。TiDB v6.4.0 では、チャンク再利用メカニズムが Executor の演算子に拡張されました。チャンクを再利用することで、TiDB はメモリ解放を頻繁に要求する必要がなくなり、一部のシナリオでは SQL クエリの実行効率が向上します。システム変数[`tidb_enable_reuse_chunk`](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640)を使用して、チャンク オブジェクトを再利用するかどうかを制御できます。この機能はデフォルトで有効になっています。 + 以前のバージョンでは、TiDB は`writechunk`関数内でのみチャンクを再利用していました。TiDB v6.4.0 では、チャンク再利用メカニズムが Executor の演算子に拡張されました。チャンクを再利用することで、TiDB はメモリ解放を頻繁にリクエストする必要がなくなり、一部のシナリオでは SQL クエリの実行効率が向上します。システム変数[`tidb_enable_reuse_chunk`](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640)を使用して、チャンク オブジェクトを再利用するかどうかを制御できます。この機能はデフォルトで有効になっています。 詳細については、 [ユーザー向けドキュメント](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640)を参照してください。 @@ -139,7 +139,7 @@ TiDBバージョン: 6.4.0-DMR - バッチ書き込みリクエストが軽量トランザクション書き込みの応答時間に与える影響を軽減する [#13313](https://github.com/tikv/tikv/issues/13313) @[glorv](https://github.com/glorv) - 一部のシステムのビジネスロジックでは、定期的なバッチ DML タスクが必要ですが、これらのバッチ書き込みタスクを処理すると、オンライントランザクションのレイテンシーが増加します。v6.3.0 では、TiKV はハイブリッドワークロード シナリオでの読み取り要求のスケジューリングを最適化するため、 [`readpool.unified.auto-adjust-pool-size`](/tikv-configuration-file.md#auto-adjust-pool-size-new-in-v630)設定項目を有効にすると、TiKV がすべての読み取り要求に対して UnifyReadPool スレッドプールのサイズを自動的に調整します。v6.4.0 では、TiKV は書き込み要求も動的に識別して優先順位を付け、1回のポーリングで Apply スレッドが 1つの FSM (有限状態機械) に対して書き込むことができる最大バイト数を制御できるため、バッチ書き込み要求がトランザクション書き込みの応答時間に与える影響を軽減できます。 + 一部のシステムのビジネスロジックでは、定期的なバッチ DML タスクが必要ですが、これらのバッチ書き込みタスクを処理すると、オンライントランザクションのレイテンシーが増加します。v6.3.0 では、TiKV はハイブリッドワークロード シナリオでの読み取りリクエストのスケジューリングを最適化するため、 [`readpool.unified.auto-adjust-pool-size`](/tikv-configuration-file.md#auto-adjust-pool-size-new-in-v630)設定項目を有効にすると、TiKV がすべての読み取りリクエストに対して UnifyReadPool スレッドプールのサイズを自動的に調整します。v6.4.0 では、TiKV は書き込みリクエストも動的に識別して優先順位を付け、1回のポーリングで Apply スレッドが 1つの FSM (有限状態機械) に対して書き込むことができる最大バイト数を制御できるため、バッチ書き込みリクエストがトランザクション書き込みの応答時間に与える影響を軽減できます。 ### 使いやすさ {#ease-of-use} @@ -282,7 +282,7 @@ TiDBバージョン: 6.4.0-DMR | [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630) | 変更 | グローバルスコープを削除し、 [`pessimistic-txn.constraint-check-in-place-pessimistic`](/tidb-configuration-file.md#constraint-check-in-place-pessimistic-new-in-v640)設定項目を使用してデフォルト値を変更できるようにします。この変数は、TiDB が悲観的トランザクション内の一意制約をチェックするタイミングを制御します。 | | [`tidb_ddl_flashback_concurrency`](/system-variables.md#tidb_ddl_flashback_concurrency-new-in-v630) | 変更 | バージョン6.4.0以降で有効になり、 [`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)の同時実行を制御します。デフォルト値は`64`です。 | | [`tidb_enable_clustered_index`](/system-variables.md#tidb_enable_clustered_index-new-in-v50) | 変更 | デフォルト値を`INT_ONLY`から`ON`に変更します。これは、主キーがデフォルトでクラスター化インデックスとして作成されることを意味します。 | -| [`tidb_enable_paging`](/system-variables.md#tidb_enable_paging-new-in-v540) | 変更 | デフォルト値を`OFF`から`ON`に変更します。これは、コプロセッサ要求を送信するためのページング方式がデフォルトで使用されることを意味します。 | +| [`tidb_enable_paging`](/system-variables.md#tidb_enable_paging-new-in-v540) | 変更 | デフォルト値を`OFF`から`ON`に変更します。これは、コプロセッサリクエストを送信するためのページング方式がデフォルトで使用されることを意味します。 | | [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610) | 変更 | SESSION スコープを追加します。この変数は[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)を有効にするかどうかを制御します。 | | [`tidb_memory_usage_alarm_ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio) | 変更 | デフォルト値を`0.8`から`0.7`に変更します。この変数は、tidb-server のメモリアラームをトリガーするメモリ使用率を制御します。 | | [`tidb_opt_agg_push_down`](/system-variables.md#tidb_opt_agg_push_down) | 変更 | グローバルスコープを追加します。この変数は、オプティマイザが集計関数をJoin、Projection、およびUnionAllの前にプッシュダウンする最適化操作を実行するかどうかを制御します。 | @@ -293,7 +293,7 @@ TiDBバージョン: 6.4.0-DMR | [`tidb_auto_analyze_partition_batch_size`](/system-variables.md#tidb_auto_analyze_partition_batch_size-new-in-v640) | 新しく追加された | パーティションテーブルを分析するときに TiDB が一度に[自動的に分析します](/statistics.md#automatic-update)できるパーティションの数を指定します (つまり、パーティションテーブルに関する統計を自動的に収集します)。デフォルト値は`1`です。 | | [`tidb_enable_external_ts_read`](/system-variables.md#tidb_enable_external_ts_read-new-in-v640) | 新しく追加された | TiDB が[`tidb_external_ts`](/system-variables.md#tidb_external_ts-new-in-v640)で指定されたタイムスタンプを持つデータを読み取るかどうかを制御します。デフォルト値は`OFF`です。 | | [`tidb_enable_gogc_tuner`](/system-variables.md#tidb_enable_gogc_tuner-new-in-v640) | 新しく追加された | GOGC Tuner を有効にするかどうかを制御します。デフォルト値は`ON`です。 | -| [`tidb_enable_reuse_chunk`](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640) | 新しく追加された | TiDB がチャンク オブジェクトのキャッシュを有効にするかどうかを制御します。デフォルト値は`ON`で、これは TiDB がキャッシュされたチャンク オブジェクトの使用を優先し、要求されたオブジェクトがキャッシュにない場合にのみシステムに要求することを意味します。値が`OFF`の場合、TiDB はシステムから直接チャンク オブジェクトを要求します。 | +| [`tidb_enable_reuse_chunk`](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640) | 新しく追加された | TiDB がチャンク オブジェクトのキャッシュを有効にするかどうかを制御します。デフォルト値は`ON`で、これは TiDB がキャッシュされたチャンク オブジェクトの使用を優先し、リクエストされたオブジェクトがキャッシュにない場合にのみシステムにリクエストすることを意味します。値が`OFF`の場合、TiDB はシステムから直接チャンク オブジェクトをリクエストします。 | | [`tidb_enable_prepared_plan_cache_memory_monitor`](/system-variables.md#tidb_enable_prepared_plan_cache_memory_monitor-new-in-v640) | 新しく追加された | プリペアドプランキャッシュにキャッシュされた実行計画によって消費されたメモリをカウントするかどうかを制御します。デフォルト値は`ON`です。 | | [`tidb_external_ts`](/system-variables.md#tidb_external_ts-new-in-v640) | 新しく追加された | デフォルト値は`0`です。tidb_enable_external_ts_read [`tidb_enable_external_ts_read`](/system-variables.md#tidb_enable_external_ts_read-new-in-v640) `ON`に設定されている場合、TiDB はこの変数で指定されたタイムスタンプを持つデータを読み取ります。 | | [`tidb_gogc_tuner_threshold`](/system-variables.md#tidb_gogc_tuner_threshold-new-in-v640) | 新しく追加された | GOGC のチューニングにおける最大メモリしきい値を指定します。メモリがこのしきい値を超えると、GOGC Tuner は動作を停止します。デフォルト値は`0.6`です。 | @@ -315,7 +315,7 @@ TiDBバージョン: 6.4.0-DMR | TiDB | [`tidb-max-reuse-column`](/tidb-configuration-file.md#tidb-max-reuse-column-new-in-v640) | 新しく追加された | チャンク割り当てのキャッシュされた列オブジェクトの最大数を制御します。デフォルト値は`256`です。 | | TiKV | [`cdc.raw-min-ts-outlier-threshold`](https://docs-archive.pingcap.com/tidb/v6.2/tikv-configuration-file#raw-min-ts-outlier-threshold-new-in-v620) | 非推奨 | この設定項目は無効になりました。 | | TiKV | [`causal-ts.alloc-ahead-buffer`](/tikv-configuration-file.md#alloc-ahead-buffer-new-in-v640) | 新しく追加された | 事前割り当て済みのTSOキャッシュサイズ（期間）。デフォルト値は`3s`です。 | -| TiKV | [`causal-ts.renew-batch-max-size`](/tikv-configuration-file.md#renew-batch-max-size-new-in-v640) | 新しく追加された | タイムスタンプ要求におけるTSOの最大数を制御します。デフォルト値は`8192`です。 | +| TiKV | [`causal-ts.renew-batch-max-size`](/tikv-configuration-file.md#renew-batch-max-size-new-in-v640) | 新しく追加された | タイムスタンプリクエストにおけるTSOの最大数を制御します。デフォルト値は`8192`です。 | | TiKV | [`raftstore.apply-yield-write-size`](/tikv-configuration-file.md#apply-yield-write-size-new-in-v640) | 新しく追加された | Applyスレッドが1回のポーリングで1つのFSM（有限状態機械）に対して書き込める最大バイト数を制御します。デフォルト値は`32KiB`です。これはソフトリミットです。 | | PD | [`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval) | 新しく追加された | バージョン6.4.0以降で有効になり、PDがTSOの物理時刻を更新する間隔を制御します。デフォルト値は`50ms`です。 | | TiFlash | [`data-encryption-method`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 変更 | 新しい値オプション`sm4-ctr`が導入されました。この設定項目が`sm4-ctr`に設定されている場合、データは保存される前に SM4 を使用して暗号化されます。 | diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index 03116d494de85..47d69aabc8077 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -315,7 +315,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では | [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 変更 | 6.5.0以降で有効になります。`INSERT` 、 `DELETE` 、 `UPDATE`を含むSQL文の読み取り操作をTiFlashにプッシュダウンできるかどうかを制御します。デフォルト値は`OFF`です。 | | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) | 変更 | さらにテストを行った後、デフォルト値を`OFF`から`ON`に変更します。つまり、 `ADD INDEX`と`CREATE INDEX`の加速はデフォルトで有効になります。 | | [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) | 変更 | TiDB v6.5.0より前のバージョンでは、この変数はクエリのメモリクォータのしきい値を設定するために使用されます。TiDB v6.5.0以降のバージョンでは、DML文のメモリをより正確に制御するために、この変数はセッションのメモリクォータのしきい値を設定するために使用されます。 | -| [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40) | 変更 | v6.5.0 以降では、 TiDB ノード間の負荷分散を最適化するために、この変数が`closest-adaptive`に設定され、読み取り要求の推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)以上の場合、 `closest-adaptive`構成が有効になる TiDB ノードの数が各アベイラビリティゾーンで制限されます。これは常に、 TiDB ノードが最も少ないアベイラビリティゾーンの TiDB ノードの数と同じになり、その他の TiDB ノードは自動的にリーダーレプリカから読み取ります。 | +| [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40) | 変更 | v6.5.0 以降では、 TiDB ノード間の負荷分散を最適化するために、この変数が`closest-adaptive`に設定され、読み取りリクエストの推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)以上の場合、 `closest-adaptive`構成が有効になる TiDB ノードの数が各アベイラビリティゾーンで制限されます。これは常に、 TiDB ノードが最も少ないアベイラビリティゾーンの TiDB ノードの数と同じになり、その他の TiDB ノードは自動的にリーダーレプリカから読み取ります。 | | [`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640) | 変更 | デフォルト値を`0`から`80%`に変更します。TiDB グローバルメモリ制御が GA になったため、このデフォルト値の変更により、メモリ制御がデフォルトで有効になり、TiDB インスタンスのメモリ制限がデフォルトで合計メモリの 80% に設定されます。 | | [`default_password_lifetime`](/system-variables.md#default_password_lifetime-new-in-v650) | 新しく追加された | パスワードの自動有効期限に関するグローバルポリシーを設定し、ユーザーに定期的なパスワード変更を義務付けます。デフォルト値`0` 、パスワードの有効期限が切れないことを示します。 | | [`disconnect_on_expired_password`](/system-variables.md#disconnect_on_expired_password-new-in-v650) | 新しく追加された | パスワードの有効期限が切れたときにTiDBがクライアント接続を切断するかどうかを示します。この変数は読み取り専用です。 | @@ -384,7 +384,7 @@ v6.5.0 以降では、v4.0.7 で導入された`AMEND TRANSACTION`メカニズ - ディスク容量の枯渇を避けるため、十分なスペースがない場合はRaft Engineへの書き込みを停止します[#13642](https://github.com/tikv/tikv/issues/13642) @[jiayang-zheng](https://github.com/jiayang-zheng) - `json_valid`関数のTiKVへのプッシュダウンをサポート [#13571](https://github.com/tikv/tikv/issues/13571) @[lizhenhuan](https://github.com/lizhenhuan) - - 1回のバックアップ要求で複数の範囲のデータのバックアップをサポート[#13701](https://github.com/tikv/tikv/issues/13701) @[Leavrth](https://github.com/Leavrth) + - 1回のバックアップリクエストで複数の範囲のデータのバックアップをサポート[#13701](https://github.com/tikv/tikv/issues/13701) @[Leavrth](https://github.com/Leavrth) - rusotoライブラリを更新してAWSのアジア太平洋地域（ap-southeast-3）へのデータバックアップをサポート [#13751](https://github.com/tikv/tikv/issues/13751) @[3pointer](https://github.com/3pointer) - 悲観的トランザクション競合を減らす[#13298](https://github.com/tikv/tikv/issues/13298) @[MyonKeminta](https://github.com/MyonKeminta) - 外部ストレージオブジェクトをキャッシュすることでリカバリパフォーマンスを向上 [#13798](https://github.com/tikv/tikv/issues/13798) @[YuJuncen](https://github.com/YuJuncen) @@ -393,7 +393,7 @@ v6.5.0 以降では、v4.0.7 で導入された`AMEND TRANSACTION`メカニズ - クロスビームチャネルに更新することで、送信側での回転の問題を回避します。 [#13815](https://github.com/tikv/tikv/issues/13815) @[sticnarf](https://github.com/sticnarf) - TiKV でのバッチココプロセッサータスク処理をサポート [#13849](https://github.com/tikv/tikv/issues/13849) @[cfzjywxk](https://github.com/cfzjywxk) - TiKVにリージョンを起動するように通知することで、障害回復の待ち時間を短縮します。 [#13648](https://github.com/tikv/tikv/issues/13648) @[LykxSassinator](https://github.com/LykxSassinator) - - コード最適化によりメモリ使用量の要求サイズを削減 [#13827](https://github.com/tikv/tikv/issues/13827) @[BusyJay](https://github.com/BusyJay) + - コード最適化によりメモリ使用量のリクエストサイズを削減 [#13827](https://github.com/tikv/tikv/issues/13827) @[BusyJay](https://github.com/BusyJay) - コードの拡張性を向上させるためにRaft拡張機能を導入する[#13827](https://github.com/tikv/tikv/issues/13827) @[BusyJay](https://github.com/BusyJay) - tikv-ctl を使用して、特定のキー範囲に含まれるリージョンを照会することをサポートします。 [#13760](https://github.com/tikv/tikv/issues/13760) @[HuSharp](https://github.com/HuSharp) - 更新されないが継続的にロックされている行の読み取りと書き込みのパフォーマンスを向上[#13694](https://github.com/tikv/tikv/issues/13694) @[sticnarf](https://github.com/sticnarf) diff --git a/releases/release-6.5.10.md b/releases/release-6.5.10.md index 186a8a4614658..0d8454b382198 100644 --- a/releases/release-6.5.10.md +++ b/releases/release-6.5.10.md @@ -76,7 +76,7 @@ TiDB バージョン: 6.5.10 - `LEADING`ヒントがブロックエイリアスのクエリをサポートしない問題を修正しました [#44645](https://github.com/pingcap/tidb/issues/44645) @[qw4990](https://github.com/qw4990) - 相関サブクエリにおける TopN オペレーターの誤った結果を修正 [#52777](https://github.com/pingcap/tidb/issues/52777) @[yibin87](https://github.com/yibin87) - 列の不安定な一意のIDにより、 `UPDATE`文がエラーを返す可能性がある問題を修正しました。 [#53236](https://github.com/pingcap/tidb/issues/53236) @[winoros](https://github.com/winoros) - - TiDBがオフラインになっているTiFlashノードにプローブ要求を送信し続ける問題を修正[#46602](https://github.com/pingcap/tidb/issues/46602) @[zyguan](https://github.com/zyguan) + - TiDBがオフラインになっているTiFlashノードにプローブリクエストを送信し続ける問題を修正[#46602](https://github.com/pingcap/tidb/issues/46602) @[zyguan](https://github.com/zyguan) - `YEAR`型の列を範囲外の符号なし整数と比較すると誤った結果が発生する問題を修正[#50235](https://github.com/pingcap/tidb/issues/50235) @[qw4990](https://github.com/qw4990) - AutoIDLeaderの変更により、 `AUTO_ID_CACHE=1` の場合にAUTO_INCREMENT列の値が減少する可能性がある問題を修正しました。 [#52600](https://github.com/pingcap/tidb/issues/52600) @[tiancaiamao](https://github.com/tiancaiamao) - BIGINT 以外の符号なし整数が文字列/小数点と比較されたときに誤った結果を生成する可能性がある問題を修正しました [#41736](https://github.com/pingcap/tidb/issues/41736) @[LittleFall](https://github.com/LittleFall) diff --git a/releases/release-6.5.11.md b/releases/release-6.5.11.md index acc26ba9aefb3..f6d963968b6c5 100644 --- a/releases/release-6.5.11.md +++ b/releases/release-6.5.11.md @@ -96,7 +96,7 @@ TiDBバージョン: 6.5.11 - `CAST()`関数を使用して文字列をタイムゾーンまたは無効な文字を含む日付時刻に変換すると、結果が正しくなくなる問題を修正しました[#8754](https://github.com/pingcap/tiflash/issues/8754) @[solotzg](https://github.com/solotzg) - データベースが作成直後に削除されるとTiFlash がpanicする可能性がある問題を修正[#9266](https://github.com/pingcap/tiflash/issues/9266) @[JaySon-Huang](https://github.com/JaySon-Huang) - TiFlashで SSL 証明書の構成を空の文字列に設定すると、誤って TLS が有効になり、 TiFlash が起動しなくなる問題を修正しました[#9235](https://github.com/pingcap/tiflash/issues/9235) @[JaySon-Huang](https://github.com/JaySon-Huang) - - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取り要求タイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取りリクエストタイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - 外部結合を含むクエリの実行中にエラーが発生した場合にTiFlashがクラッシュする可能性がある問題を修正しました。 [#9190](https://github.com/pingcap/tiflash/issues/9190) @[windtalker](https://github.com/windtalker) - データ型を`DECIMAL`に変換すると、一部のコーナーケースで誤ったクエリ結果が発生する可能性がある問題を修正しました[#53892](https://github.com/pingcap/tidb/issues/53892) @[guo-shaoge](https://github.com/guo-shaoge) - クラスタ内で長期間にわたって頻繁に`EXCHANGE PARTITION`と`DROP TABLE`操作を行うと、 TiFlashテーブルメタデータのレプリケーションが遅くなり、クエリパフォーマンスが低下する可能性がある問題を修正しました[#9227](https://github.com/pingcap/tiflash/issues/9227) @[JaySon-Huang](https://github.com/JaySon-Huang) diff --git a/releases/release-6.5.5.md b/releases/release-6.5.5.md index 1788b57f159cb..31a1ff2ac1ddb 100644 --- a/releases/release-6.5.5.md +++ b/releases/release-6.5.5.md @@ -16,7 +16,7 @@ TiDB バージョン: 6.5.5 - TiDB - [`NO_MERGE_JOIN()`](/optimizer-hints.md#no_merge_joint1_name--tl_name-)、[`NO_INDEX_JOIN()`](/optimizer-hints.md#no_index_joint1_name--tl_name-)、[`NO_INDEX_MERGE_JOIN()`](/optimizer-hints.md#no_index_merge_joint1_name--tl_name-)、[`NO_HASH_JOIN()`](/optimizer-hints.md#no_hash_joint1_name--tl_name-)、[`NO_INDEX_HASH_JOIN()`](/optimizer-hints.md#no_index_hash_joint1_name--tl_name-)を含む新しいオプティマイザヒントを追加 [#45520](https://github.com/pingcap/tidb/issues/45520) @[qw4990](https://github.com/qw4990) - - コプロセッサに関連する要求元情報を追加します [#46514](https://github.com/pingcap/tidb/issues/46514) @[you06](https://github.com/you06) + - コプロセッサに関連するリクエスト元情報を追加します [#46514](https://github.com/pingcap/tidb/issues/46514) @[you06](https://github.com/you06) - TiKV diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index b4e3fa79314bd..3d246197e8e08 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -100,7 +100,7 @@ TiDB バージョン: 6.5.6 - ピアを移動するとFollower Readのパフォーマンスが低下する可能性がある問題を修正[#15468](https://github.com/tikv/tikv/issues/15468) @[YuJuncen](https://github.com/YuJuncen) - raftstore-applys が継続的に増加するデータエラーを修正しました [#15371](https://github.com/tikv/tikv/issues/15371) @[Connor1996](https://github.com/Connor1996) - - オンラインワークロードがある場合にTiDB Lightningチェックサムコプロセッサの要求がタイムアウトする問題を修正しました [#15565](https://github.com/tikv/tikv/issues/15565) @[lance6716](https://github.com/lance6716) + - オンラインワークロードがある場合にTiDB Lightningチェックサムコプロセッサのリクエストがタイムアウトする問題を修正しました [#15565](https://github.com/tikv/tikv/issues/15565) @[lance6716](https://github.com/lance6716) - `lz4-sys`のバージョンを 1.9.4 にアップグレードしてセキュリティ問題を修正しました [#15621](https://github.com/tikv/tikv/issues/15621) @[SpadeA-Tang](https://github.com/SpadeA-Tang) - バージョン`tokio`を 6.5 にアップグレードしてセキュリティ問題を修正しました [#15621](https://github.com/tikv/tikv/issues/15621) @[LykxSassinator](https://github.com/LykxSassinator) - `flatbuffer` を削除してセキュリティ問題を修正 [#15621](https://github.com/tikv/tikv/issues/15621) @[tonyxuqqi](https://github.com/tonyxuqqi) diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md index a99f894a19312..cae6585b10595 100644 --- a/releases/release-6.6.0.md +++ b/releases/release-6.6.0.md @@ -17,7 +17,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone バージョン6.6.0-DMRの主な新機能と改善点は以下のとおりです。 -
カテゴリ特徴説明
拡張性とパフォーマンス
TiKVはパーティション化されたRaft KVストレージエンジンをサポートしています（実験的）。 TiKVはパーティション化されたRaft KVストレージエンジンを導入しており、各リージョンは独立したRocksDBインスタンスを使用するため、クラスターのストレージ容量をテラバイトからペタバイトまで容易に拡張でき、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
TiKVはデータ要求のバッチ集計をサポートしていますこの機能強化により、TiKVのバッチ取得操作におけるRPCの総数が大幅に削減されます。データが高度に分散しており、gRPCスレッドプールのリソースが不足している状況では、コプロセッサ要求をバッチ処理することで、パフォーマンスを50%以上向上させることができます。
TiFlashは、 ステイル読み取りと圧縮交換をサポートしています。 TiFlashは、リアルタイム要件に制約がないシナリオにおいてクエリ性能を向上させることができる、古いデータの読み取り機能をサポートしています。また、 TiFlashはデータ圧縮をサポートしており、並列データ交換の効率を向上させ、TPC-H全体のパフォーマンスを10%向上させ、ネットワーク使用量を50%以上削減できます。
信頼性と可用性
リソース制御（実験的）リソースグループに基づいたリソース管理をサポートします。これにより、データベースユーザーを対応するリソースグループにマッピングし、実際のニーズに基づいて各リソースグループの割り当て量を設定します。
履歴SQLバインディングTiDB Dashboard上で、過去の実行計画のバインドと、実行計画の迅速なバインドをサポートします。
SQLの機能
外部キー（実験的）データの一貫性を維持し、データ品質を向上させるために、MySQL互換の外部キー制約をサポートします。
多値インデックス（実験的） MySQL互換の多値インデックスを導入し、JSON型を拡張することで、TiDBのMySQL 8.0との互換性を向上させます。
DB操作と可観測性
DMは物理的なインポートをサポートします（実験的） TiDBデータ移行（DM）は、TiDB Lightningの物理インポートモードを統合することで、フルデータ移行のパフォーマンスを向上させ、最大10倍高速化します。
+
カテゴリ特徴説明
拡張性とパフォーマンス
TiKVはパーティション化されたRaft KVストレージエンジンをサポートしています（実験的）。 TiKVはパーティション化されたRaft KVストレージエンジンを導入しており、各リージョンは独立したRocksDBインスタンスを使用するため、クラスターのストレージ容量をテラバイトからペタバイトまで容易に拡張でき、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
TiKVはデータリクエストのバッチ集計をサポートしていますこの機能強化により、TiKVのバッチ取得操作におけるRPCの総数が大幅に削減されます。データが高度に分散しており、gRPCスレッドプールのリソースが不足している状況では、コプロセッサリクエストをバッチ処理することで、パフォーマンスを50%以上向上させることができます。
TiFlashは、 ステイル読み取りと圧縮交換をサポートしています。 TiFlashは、リアルタイム要件に制約がないシナリオにおいてクエリ性能を向上させることができる、古いデータの読み取り機能をサポートしています。また、 TiFlashはデータ圧縮をサポートしており、並列データ交換の効率を向上させ、TPC-H全体のパフォーマンスを10%向上させ、ネットワーク使用量を50%以上削減できます。
信頼性と可用性
リソース制御（実験的）リソースグループに基づいたリソース管理をサポートします。これにより、データベースユーザーを対応するリソースグループにマッピングし、実際のニーズに基づいて各リソースグループの割り当て量を設定します。
履歴SQLバインディングTiDB Dashboard上で、過去の実行計画のバインドと、実行計画の迅速なバインドをサポートします。
SQLの機能
外部キー（実験的）データの一貫性を維持し、データ品質を向上させるために、MySQL互換の外部キー制約をサポートします。
多値インデックス（実験的） MySQL互換の多値インデックスを導入し、JSON型を拡張することで、TiDBのMySQL 8.0との互換性を向上させます。
DB操作と可観測性
DMは物理的なインポートをサポートします（実験的） TiDBデータ移行（DM）は、TiDB Lightningの物理インポートモードを統合することで、フルデータ移行のパフォーマンスを向上させ、最大10倍高速化します。
## 機能の詳細 {#feature-details} @@ -45,9 +45,9 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone 詳細については、 [ドキュメント](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_pessimistic_txn_aggressive_locking-new-in-v660)を参照してください。 -- バッチ集計データ要求 [#39361](https://github.com/pingcap/tidb/issues/39361) @[cfzjywxk](https://github.com/cfzjywxk) @[you06](https://github.com/you06) +- バッチ集計データリクエスト [#39361](https://github.com/pingcap/tidb/issues/39361) @[cfzjywxk](https://github.com/cfzjywxk) @[you06](https://github.com/you06) - TiDB が TiKV にデータ要求を送信すると、TiDB はデータが存在するリージョンに応じて要求を複数のサブタスクにコンパイルし、各サブタスクは単一のリージョンの要求のみを処理します。アクセスするデータが高度に分散している場合、データのサイズが大きくなくても、多くのサブタスクが生成され、結果として多くの RPC 要求が発生し、余分な時間を消費します。v6.6.0 以降、TiDB は同じ TiKV インスタンスに送信されるデータ要求を部分的にマージする機能をサポートしており、サブタスクの数と RPC 要求のオーバーヘッドを削減します。データの分散度が高く、gRPC スレッドプールのリソースが不足している場合、要求をバッチ処理することでパフォーマンスを 50% 以上向上させることができます。 + TiDB が TiKV にデータリクエストを送信すると、TiDB はデータが存在するリージョンに応じてリクエストを複数のサブタスクにコンパイルし、各サブタスクは単一のリージョンのリクエストのみを処理します。アクセスするデータが高度に分散している場合、データのサイズが大きくなくても、多くのサブタスクが生成され、結果として多くの RPC リクエストが発生し、余分な時間を消費します。v6.6.0 以降、TiDB は同じ TiKV インスタンスに送信されるデータリクエストを部分的にマージする機能をサポートしており、サブタスクの数と RPC リクエストのオーバーヘッドを削減します。データの分散度が高く、gRPC スレッドプールのリソースが不足している場合、リクエストをバッチ処理することでパフォーマンスを 50% 以上向上させることができます。 この機能はデフォルトで有効になっています。システム変数[`tidb_store_batch_size`](/system-variables.md#tidb_store_batch_size)を使用して、リクエストのバッチサイズを設定できます。 @@ -352,7 +352,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone | TiDB | [`tidb_stmt_summary_file_max_days`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_days-new-in-v660) | 新しく追加された | ステートメントサマリーデータの永続化が有効になっている場合、この設定では永続データファイルを保持する最大日数を指定します。 | | TiDB | [`tidb_stmt_summary_file_max_size`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_size-new-in-v660) | 新しく追加された | ステートメントサマリーの永続化が有効になっている場合、この設定では永続データファイルの最大サイズ（MiB単位）を指定します。 | | TiDB | [`tidb_stmt_summary_filename`](/tidb-configuration-file.md#tidb_stmt_summary_filename-new-in-v660) | 新しく追加された | ステートメントサマリーデータの永続化が有効になっている場合、この設定では永続データが書き込まれるファイルを指定します。 | -| TiKV | [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) | 新しく追加された | 対応するリソースグループのリクエストユニット (RU) に基づいて、ユーザーのフォアグラウンド読み取り/書き込み要求のスケジューリングを有効にするかどうか。デフォルト値は`false`で、これは対応するリソースグループの RU に基づくスケジューリングを無効にすることを意味します。 | +| TiKV | [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) | 新しく追加された | 対応するリソースグループのリクエストユニット (RU) に基づいて、ユーザーのフォアグラウンド読み取り/書き込みリクエストのスケジューリングを有効にするかどうか。デフォルト値は`false`で、これは対応するリソースグループの RU に基づくスケジューリングを無効にすることを意味します。 | | TiKV | [`storage.engine`](/tikv-configuration-file.md#engine-new-in-v660) | 新しく追加された | この設定項目は、ストレージエンジンのタイプを指定します。値のオプションは`"raft-kv"`と`"partitioned-raft-kv"`です。この設定項目は、クラスタ作成時にのみ指定でき、一度指定すると変更できません。 | | TiKV | [`rocksdb.write-buffer-flush-oldest-first`](/tikv-configuration-file.md#write-buffer-flush-oldest-first-new-in-v660) | 新しく追加された | この設定項目は、現在の RocksDB の`memtable`のメモリ使用量がしきい値に達したときに使用されるフラッシュ戦略を指定します。 | | TiKV | [`rocksdb.write-buffer-limit`](/tikv-configuration-file.md#write-buffer-limit-new-in-v660) | 新しく追加された | この設定項目は、単一の TiKV 内のすべての RocksDB インスタンス`memtable`が使用する合計メモリの制限を指定します。デフォルト値は、マシン全体のメモリの 25% です。 | diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index a4b8195701c0a..e5e70c2da63d5 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -307,10 +307,10 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone | TiKV | [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) | 変更 | デフォルト値が`false`から`true`に変更されます。 | | TiKV | [`raft-engine.prefill-for-recycle`](/tikv-configuration-file.md#prefill-for-recycle-new-in-v700) | 新しく追加された | Raft Engineのログリサイクル用に空のログファイルを生成するかどうかを制御します。デフォルト値は`false`です。 | | PD | [`degraded-mode-wait-duration`](/pd-configuration-file.md#degraded-mode-wait-duration) | 新しく追加された | [リソース制御](/tidb-resource-control-ru-groups.md)関連する設定項目です。劣化モードをトリガーするまでの待機時間を制御します。デフォルト値は`0s`です。 | -| PD | [`read-base-cost`](/pd-configuration-file.md#read-base-cost) | 新しく追加された | A[リソース制御](/tidb-resource-control-ru-groups.md)関連する設定項目です。読み取り要求から RU への変換の基準係数を制御します。デフォルト値は`0.25`です。 | +| PD | [`read-base-cost`](/pd-configuration-file.md#read-base-cost) | 新しく追加された | A[リソース制御](/tidb-resource-control-ru-groups.md)関連する設定項目です。読み取りリクエストから RU への変換の基準係数を制御します。デフォルト値は`0.25`です。 | | PD | [`read-cost-per-byte`](/pd-configuration-file.md#read-cost-per-byte) | 新しく追加された | A[リソース制御](/tidb-resource-control-ru-groups.md)関連する設定項目です。読み取りフローからRUへの変換の基準係数を制御します。デフォルト値は`1/ (64 * 1024)`です。 | | PD | [`read-cpu-ms-cost`](/pd-configuration-file.md#read-cpu-ms-cost) | 新しく追加された | [リソース制御](/tidb-resource-control-ru-groups.md)関連する設定項目です。CPUからRUへの変換の基準係数を制御します。デフォルト値は`1/3`です。 | -| PD | [`write-base-cost`](/pd-configuration-file.md#write-base-cost) | 新しく追加された | [リソース制御](/tidb-resource-control-ru-groups.md)関連の設定項目です。書き込み要求からRUへの変換の基準係数を制御します。デフォルト値は`1`です。 | +| PD | [`write-base-cost`](/pd-configuration-file.md#write-base-cost) | 新しく追加された | [リソース制御](/tidb-resource-control-ru-groups.md)関連の設定項目です。書き込みリクエストからRUへの変換の基準係数を制御します。デフォルト値は`1`です。 | | PD | [`write-cost-per-byte`](/pd-configuration-file.md#write-cost-per-byte) | 新しく追加された | [リソース制御](/tidb-resource-control-ru-groups.md)関連の設定項目です。書き込みフローからRUへの変換の基準係数を制御します。デフォルト値は`1/1024`です。 | | TiFlash | [`mark_cache_size`](/tiflash/tiflash-configuration.md) | 変更 | TiFlashのデータブロックのメタデータのデフォルトのキャッシュ制限を`5368709120`から`1073741824`に変更して、不要なメモリ使用量を削減します。 | | TiFlash | [`minmax_index_cache_size`](/tiflash/tiflash-configuration.md) | 変更 | TiFlashのデータブロックの最小-最大インデックスのデフォルトのキャッシュ制限を`5368709120`から`1073741824`に変更して、不要なメモリ使用量を削減します。 | @@ -387,7 +387,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - TiDBをv6.5.1からそれ以降のバージョンにアップグレードする際にアップデートが欠落する問題を修正 [#41502](https://github.com/pingcap/tidb/issues/41502) @[chrysan](https://github.com/chrysan) - アップグレード後に一部のシステム変数のデフォルト値が変更されない問題を修正 [#41423](https://github.com/pingcap/tidb/issues/41423) @[crazycs520](https://github.com/crazycs520) - - インデックス追加に関連するコプロセッサー要求タイプが不明として表示される問題を修正 [#41400](https://github.com/pingcap/tidb/issues/41400) @[tangenta](https://github.com/tangenta) + - インデックス追加に関連するコプロセッサーリクエストタイプが不明として表示される問題を修正 [#41400](https://github.com/pingcap/tidb/issues/41400) @[tangenta](https://github.com/tangenta) - インデックスを追加する際に「PessimisticLockNotFound」が返される問題を修正 [#41515](https://github.com/pingcap/tidb/issues/41515) @[tangenta](https://github.com/tangenta) - 一意インデックスを追加する際に誤って`found duplicate key`を返す問題を修正 [#41630](https://github.com/pingcap/tidb/issues/41630) @[tangenta](https://github.com/tangenta) - インデックス追加時のpanic問題を修正 [#41880](https://github.com/pingcap/tidb/issues/41880) @[tangenta](https://github.com/tangenta) diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index cd277e087a845..b6554eb5b3322 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -15,7 +15,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 以前の LTS 6.5.0 と比較して、7.1.0 には、 [6.6.0-DMR](/releases/release-6.6.0.md) 、 [7.0.0-DMR](/releases/release-7.0.0.md)でリリースされた新機能、改善、バグ修正が含まれているだけでなく、次の主要な機能と改善も導入されています。 -
カテゴリ特徴説明
スケーラビリティとパフォーマンスTiFlash は、分散ストレージとコンピューティングアーキテクチャ、および S3 共有ストレージ(実験的、v7.0.0 で導入) をサポートします。 TiFlash は、オプションとしてクラウドネイティブアーキテクチャを導入します。
  • TiFlash のコンピューティングとストレージを分離します。これは、弾力的な HTAP リソース利用のマイルストーンとなります。
  • 低コストで共有ストレージを提供できる S3 ベースのストレージエンジンを導入します。
TiKV はバッチ集約データ要求をサポートします (v6.6.0 で導入)この機能強化により、TiKVバッチゲット操作におけるRPCの総数が大幅に削減されます。データが広範囲に分散し、gRPCスレッドプールのリソースが不足している状況では、コプロセッサリクエストをバッチ処理することでパフォーマンスを50%以上向上させることができます。
負荷ベースのレプリカ読み取り読み取りホットスポットのシナリオでは、TiDBはホットスポットTiKVノードへの読み取り要求をそのレプリカにリダイレクトできます。この機能により、読み取りホットスポットが効率的に分散され、クラスタリソースの利用が最適化されます。負荷ベースのレプリカ読み取りをトリガーするしきい値を制御するには、システム変数tidb_load_based_replica_read_thresholdを調整します。
TiKV はパーティション化されたRaft KVストレージエンジンをサポートします (実験的) TiKVは、新世代のストレージエンジンであるパーティション型Raft KVを導入します。各データリージョンに専用のRocksDBインスタンスを割り当てることで、クラスターのストレージ容量をテラバイトレベルからペタバイトレベルに拡張し、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
信頼性と可用性リソースグループによるリソース制御（GA）リソースグループに基づくリソース管理をサポートします。これにより、同一クラスター内の異なるワークロードにリソースを割り当て、分離することができます。この機能は、マルチアプリケーションクラスターの安定性を大幅に向上させ、マルチテナンシーの基盤を構築します。v7.1.0では、この機能により、実際のワークロードまたはハードウェア構成に基づいてシステム容量を見積もる機能が導入されました。
TiFlash はディスクへの書き込みをサポートします (v7.0.0 で導入) TiFlash は、集計、ソート、ハッシュ結合などのデータ集約型操作における OOM を軽減するために、ディスクへの中間結果のスピルをサポートします。
SQL 多値インデックス（GA） MySQL互換の多値インデックスをサポートし、JSON型を拡張することでMySQL 8.0との互換性を向上させました。この機能により、多値列のメンバーシップチェックの効率が向上します。
行レベルの TTL (v7.0.0 で GA)一定の期間を経過したデータを自動的に期限切れにすることで、データベース サイズの管理をサポートし、パフォーマンスを向上します。
生成列（GA）生成列の値は、列定義内のSQL式によってリアルタイムで計算されます。この機能により、一部のアプリケーションロジックがデータベースレベルにプッシュされ、クエリの効率が向上します。
SecurityLDAP認証TiDB は、 MySQL 8.0と互換性のある LDAP 認証をサポートしています。
監査ログの強化（Enterprise Editionのみ） TiDB Enterprise Editionは、データベース監査機能を強化しました。よりきめ細かなイベントフィルタリング制御、よりユーザーフレンドリーなフィルタ設定、JSON形式の新しいファイル出力形式、監査ログのライフサイクル管理を提供することで、システム監査能力を大幅に向上させます。
+
カテゴリ特徴説明
スケーラビリティとパフォーマンスTiFlash は、分散ストレージとコンピューティングアーキテクチャ、および S3 共有ストレージ(実験的、v7.0.0 で導入) をサポートします。 TiFlash は、オプションとしてクラウドネイティブアーキテクチャを導入します。
  • TiFlash のコンピューティングとストレージを分離します。これは、弾力的な HTAP リソース利用のマイルストーンとなります。
  • 低コストで共有ストレージを提供できる S3 ベースのストレージエンジンを導入します。
TiKV はバッチ集約データリクエストをサポートします (v6.6.0 で導入)この機能強化により、TiKVバッチゲット操作におけるRPCの総数が大幅に削減されます。データが広範囲に分散し、gRPCスレッドプールのリソースが不足している状況では、コプロセッサリクエストをバッチ処理することでパフォーマンスを50%以上向上させることができます。
負荷ベースのレプリカ読み取り読み取りホットスポットのシナリオでは、TiDBはホットスポットTiKVノードへの読み取りリクエストをそのレプリカにリダイレクトできます。この機能により、読み取りホットスポットが効率的に分散され、クラスタリソースの利用が最適化されます。負荷ベースのレプリカ読み取りをトリガーするしきい値を制御するには、システム変数tidb_load_based_replica_read_thresholdを調整します。
TiKV はパーティション化されたRaft KVストレージエンジンをサポートします (実験的) TiKVは、新世代のストレージエンジンであるパーティション型Raft KVを導入します。各データリージョンに専用のRocksDBインスタンスを割り当てることで、クラスターのストレージ容量をテラバイトレベルからペタバイトレベルに拡張し、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
信頼性と可用性リソースグループによるリソース制御（GA）リソースグループに基づくリソース管理をサポートします。これにより、同一クラスター内の異なるワークロードにリソースを割り当て、分離することができます。この機能は、マルチアプリケーションクラスターの安定性を大幅に向上させ、マルチテナンシーの基盤を構築します。v7.1.0では、この機能により、実際のワークロードまたはハードウェア構成に基づいてシステム容量を見積もる機能が導入されました。
TiFlash はディスクへの書き込みをサポートします (v7.0.0 で導入) TiFlash は、集計、ソート、ハッシュ結合などのデータ集約型操作における OOM を軽減するために、ディスクへの中間結果のスピルをサポートします。
SQL 多値インデックス（GA） MySQL互換の多値インデックスをサポートし、JSON型を拡張することでMySQL 8.0との互換性を向上させました。この機能により、多値列のメンバーシップチェックの効率が向上します。
行レベルの TTL (v7.0.0 で GA)一定の期間を経過したデータを自動的に期限切れにすることで、データベース サイズの管理をサポートし、パフォーマンスを向上します。
生成列（GA）生成列の値は、列定義内のSQL式によってリアルタイムで計算されます。この機能により、一部のアプリケーションロジックがデータベースレベルにプッシュされ、クエリの効率が向上します。
SecurityLDAP認証TiDB は、 MySQL 8.0と互換性のある LDAP 認証をサポートしています。
監査ログの強化（Enterprise Editionのみ） TiDB Enterprise Editionは、データベース監査機能を強化しました。よりきめ細かなイベントフィルタリング制御、よりユーザーフレンドリーなフィルタ設定、JSON形式の新しいファイル出力形式、監査ログのライフサイクル管理を提供することで、システム監査能力を大幅に向上させます。
## 機能の詳細 {#feature-details} @@ -49,7 +49,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - 読み取りホットスポットを軽減するために負荷ベースのレプリカ読み取りをサポートする[#14151](https://github.com/tikv/tikv/issues/14151) @[sticnarf](https://github.com/sticnarf) @[you06](https://github.com/you06) - 読み取りホットスポットが発生すると、ホットスポット TiKV ノードは読み取り要求を時間内に処理できず、読み取り要求がキューイングされます。ただし、この時点ですべての TiKV リソースが使い果たされるわけではありません。レイテンシーを短縮するために、TiDB v7.1.0 では負荷ベースのレプリカ読み取り機能が導入されました。この機能により、TiDB はホットスポット TiKV ノードでキューイングすることなく、他の TiKV ノードからデータを読み取ることができます。読み取り要求のキューの長さは、 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700)システム変数を使用して制御できます。リーダーノードの推定キュー時間がこのしきい値を超えると、TiDB はフォロワーノードからのデータの読み取りを優先します。この機能により、読み取りホットスポットが発生すると、読み取りホットスポットを分散させない場合と比較して、読み取りスループットが 70% ～ 200% 向上します。 + 読み取りホットスポットが発生すると、ホットスポット TiKV ノードは読み取りリクエストを時間内に処理できず、読み取りリクエストがキューイングされます。ただし、この時点ですべての TiKV リソースが使い果たされるわけではありません。レイテンシーを短縮するために、TiDB v7.1.0 では負荷ベースのレプリカ読み取り機能が導入されました。この機能により、TiDB はホットスポット TiKV ノードでキューイングすることなく、他の TiKV ノードからデータを読み取ることができます。読み取りリクエストのキューの長さは、 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700)システム変数を使用して制御できます。リーダーノードの推定キュー時間がこのしきい値を超えると、TiDB はフォロワーノードからのデータの読み取りを優先します。この機能により、読み取りホットスポットが発生すると、読み取りホットスポットを分散させない場合と比較して、読み取りスループットが 70% ～ 200% 向上します。 詳細については[ドキュメント](/troubleshoot-hot-spot-issues.md#scatter-read-hotspots)を参照してください。 diff --git a/releases/release-7.1.2.md b/releases/release-7.1.2.md index 2dbc9e699540f..61e5ed5d22af8 100644 --- a/releases/release-7.1.2.md +++ b/releases/release-7.1.2.md @@ -29,7 +29,7 @@ TiDB バージョン: 7.1.2 - TiDB - [`NO_MERGE_JOIN()`](/optimizer-hints.md#no_merge_joint1_name--tl_name-)、[`NO_INDEX_JOIN()`](/optimizer-hints.md#no_index_joint1_name--tl_name-)、[`NO_INDEX_MERGE_JOIN()`](/optimizer-hints.md#no_index_merge_joint1_name--tl_name-)、[`NO_HASH_JOIN()`](/optimizer-hints.md#no_hash_joint1_name--tl_name-)、[`NO_INDEX_HASH_JOIN()`](/optimizer-hints.md#no_index_hash_joint1_name--tl_name-)を含む新しいオプティマイザヒントを追加 [#45520](https://github.com/pingcap/tidb/issues/45520) @[qw4990](https://github.com/qw4990) - - コプロセッサに関連する要求元情報を追加します [#46514](https://github.com/pingcap/tidb/issues/46514) @[you06](https://github.com/you06) + - コプロセッサに関連するリクエスト元情報を追加します [#46514](https://github.com/pingcap/tidb/issues/46514) @[you06](https://github.com/you06) - TiDBノードのアップグレードステータスの開始と終了をマークするために`/upgrade/start`と`upgrade/finish` APIを追加します。 [#47172](https://github.com/pingcap/tidb/issues/47172) @[zimulala](https://github.com/zimulala) - TiKV @@ -44,7 +44,7 @@ TiDB バージョン: 7.1.2 - PD - - PD 呼び出し元のバックオフ メカニズムを最適化して、呼び出しが失敗したときの RPC 要求の頻度を減らします[#6556](https://github.com/tikv/pd/issues/6556) @[nolouch](https://github.com/nolouch) @[rleungx](https://github.com/rleungx) @[HuSharp](https://github.com/HuSharp) + - PD 呼び出し元のバックオフ メカニズムを最適化して、呼び出しが失敗したときの RPC リクエストの頻度を減らします[#6556](https://github.com/tikv/pd/issues/6556) @[nolouch](https://github.com/nolouch) @[rleungx](https://github.com/rleungx) @[HuSharp](https://github.com/HuSharp) - 発信者が切断されたときにCPUとメモリを時間内に解放するために、 `GetRegions`インターフェースにキャンセルメカニズムを導入する[#6835](https://github.com/tikv/pd/issues/6835) @[lhy1024](https://github.com/lhy1024) - TiFlash @@ -132,7 +132,7 @@ TiDB バージョン: 7.1.2 - オンラインアンセーフリカバリがタイムアウトで中止されない問題を修正 [#15346](https://github.com/tikv/tikv/issues/15346) @[Connor1996](https://github.com/Connor1996) - 暗号化により部分書き込み中にデータ破損が発生する可能性がある問題を修正 [#15080](https://github.com/tikv/tikv/issues/15080) @[tabokie](https://github.com/tabokie) - リージョンのメタデータが正しくないことによって引き起こされるTiKV panic問題を修正しました [#13311](https://github.com/tikv/tikv/issues/13311) @[cfzjywxk](https://github.com/cfzjywxk) - - オンラインワークロードがある場合にTiDB Lightningチェックサムコプロセッサの要求がタイムアウトする問題を修正しました [#15565](https://github.com/tikv/tikv/issues/15565) @[lance6716](https://github.com/lance6716) + - オンラインワークロードがある場合にTiDB Lightningチェックサムコプロセッサのリクエストがタイムアウトする問題を修正しました [#15565](https://github.com/tikv/tikv/issues/15565) @[lance6716](https://github.com/lance6716) - ピアを移動するとFollower Readのパフォーマンスが低下する可能性がある問題を修正[#15468](https://github.com/tikv/tikv/issues/15468) @[YuJuncen](https://github.com/YuJuncen) - PD diff --git a/releases/release-7.1.5.md b/releases/release-7.1.5.md index 26b55fedc8fa3..039685027d45f 100644 --- a/releases/release-7.1.5.md +++ b/releases/release-7.1.5.md @@ -60,7 +60,7 @@ TiDB バージョン: 7.1.5 - `TIDB_HOT_REGIONS`テーブルをクエリすると、誤って`INFORMATION_SCHEMA`テーブルが返される可能性がある問題を修正しました。 [#50810](https://github.com/pingcap/tidb/issues/50810) @[Defined2014](https://github.com/Defined2014) - `IFNULL`関数によって返される型が MySQL と一致しない問題を修正しました [#51765](https://github.com/pingcap/tidb/issues/51765) @[YangKeao](https://github.com/YangKeao) - TTL 機能により、データ範囲の分割が不正確になり、場合によってはでデータ ホットスポットが発生する問題を修正しました。 [#51527](https://github.com/pingcap/tidb/issues/51527) @[lcwangchao](https://github.com/lcwangchao) - - TiDBがオフラインになっているTiFlashノードにプローブ要求を送信し続ける問題を修正[#46602](https://github.com/pingcap/tidb/issues/46602) @[zyguan](https://github.com/zyguan) + - TiDBがオフラインになっているTiFlashノードにプローブリクエストを送信し続ける問題を修正[#46602](https://github.com/pingcap/tidb/issues/46602) @[zyguan](https://github.com/zyguan) - AutoIDLeaderの変更により、 `AUTO_ID_CACHE=1` の場合にAUTO_INCREMENT列の値が減少する可能性がある問題を修正しました。 [#52600](https://github.com/pingcap/tidb/issues/52600) @[tiancaiamao](https://github.com/tiancaiamao) - `INSERT IGNORE`を実行すると、一意インデックスとデータの間に不整合が発生する可能性がある問題を修正しました。 [#51784](https://github.com/pingcap/tidb/issues/51784) @[wjhuang2016](https://github.com/wjhuang2016) - 一意インデックスを追加するとTiDBがpanicする可能性がある問題を修正[#52312](https://github.com/pingcap/tidb/issues/52312) @[wjhuang2016](https://github.com/wjhuang2016) diff --git a/releases/release-7.1.6.md b/releases/release-7.1.6.md index efa646115bab4..8c26d01cea4c1 100644 --- a/releases/release-7.1.6.md +++ b/releases/release-7.1.6.md @@ -14,7 +14,7 @@ TiDB バージョン: 7.1.6 ## 互換性の変更 {#compatibility-changes} - [TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-7.1/docs/tidb_http_api.md)から取得される DDL 履歴タスクのデフォルトの制限を2048に設定して、過剰な履歴タスクによる OOM の問題を防止します。 [#55711](https://github.com/pingcap/tidb/issues/55711) @[joccau](https://github.com/joccau) -- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`目のイベントで主キーまたは非NULLの一意インデックス値が変更されると、TiCDCはこのイベントを`DELETE`目と`INSERT`目のイベントに分割していました。v7.1.6以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS` TiCDC `thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`件目のイベントを`DELETE`目と`INSERT`件目のイベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`目のイベントの順序が誤っている可能性があり、その結果、分割された`DELETE`と`INSERT`目のイベントの順序が誤っている可能性があることで発生するダウンストリームデータの不整合の問題を解決します。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v7.1/ticdc-split-update-behavior#split-update-events-for-mysql-sinks) してください@[lidezhu](https://github.com/lidezhu) [#10918](https://github.com/pingcap/tiflow/issues/10918) +- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`イベントで主キーまたは非NULLの一意インデックス値が変更されると、TiCDCはこのイベントを`DELETE`と`INSERT`イベントに分割していました。v7.1.6以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS`がTiCDCの`thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`イベントを`DELETE`と`INSERT`イベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`イベントの順序が誤っている可能性があり、その結果、分割された`DELETE`と`INSERT`イベントの順序が誤っている可能性があることで発生するダウンストリームデータの不整合の問題を解決します。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v7.1/ticdc-split-update-behavior#split-update-events-for-mysql-sinks)を参照してください。@[lidezhu](https://github.com/lidezhu) [#10918](https://github.com/pingcap/tiflow/issues/10918) - TiDB Lightning `strict-format`を使用して CSV ファイルをインポートする場合は、行末文字を設定する必要があります[#37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) - TiKV設定項目[`server.grpc-compression-type`](/tikv-configuration-file.md#grpc-compression-type)のスコープを変更します。 @@ -42,7 +42,7 @@ TiDB バージョン: 7.1.6 - `LENGTH()`と`ASCII()`関数の実行効率を最適化 [#9344](https://github.com/pingcap/tiflash/issues/9344) @[xzhangxian1008](https://github.com/xzhangxian1008) - TLS を有効にした後に証明書を更新することでTiFlash がpanicする可能性がある問題を軽減します[#8535](https://github.com/pingcap/tiflash/issues/8535) @[windtalker](https://github.com/windtalker) - - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセル要求にタイムリーに応答できるようにします[#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) + - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセルリクエストにタイムリーに応答できるようにします[#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) - 同時実行性の高いデータ読み取り操作におけるロック競合を減らし、短いクエリのパフォーマンスを最適化します[#9125](https://github.com/pingcap/tiflash/issues/9125) @[JinheLin](https://github.com/JinheLin) - クラスター化インデックスを持つテーブルで、バックグラウンドでの古いデータのガベージコレクションの速度が向上しました。 [#9529](https://github.com/pingcap/tiflash/issues/9529) @[JaySon-Huang](https://github.com/JaySon-Huang) @@ -195,7 +195,7 @@ TiDB バージョン: 7.1.6 - `DECIMAL`型の小数点部分がの場合に正しくない問題を修正しました [#16913](https://github.com/tikv/tikv/issues/16913) @[gengliqi](https://github.com/gengliqi) - クエリ内の`CONV()`関数が数値システム変換中にオーバーフローし、TiKV panicが発生する問題を修正しました。 [#16969](https://github.com/tikv/tikv/issues/16969) @[gengliqi](https://github.com/gengliqi) - 古いレプリカがRaftスナップショットを処理するときに、遅い分割操作と新しいレプリカの即時削除によってトリガーされ、TiKV がpanicになる可能性がある問題を修正しました。 [#17469](https://github.com/tikv/tikv/issues/17469) @[hbisheng](https://github.com/hbisheng) - - 同時実行性の高いコプロセッサー要求により TiKV OOM が発生する可能性がある問題を修正しました [#16653](https://github.com/tikv/tikv/issues/16653) @[overvenus](https://github.com/overvenus) + - 同時実行性の高いコプロセッサーリクエストにより TiKV OOM が発生する可能性がある問題を修正しました [#16653](https://github.com/tikv/tikv/issues/16653) @[overvenus](https://github.com/overvenus) - マスターキーがキー管理サービス (KMS) に保存されているときにマスターキーのローテーションを妨げる問題を修正しました [#17410](https://github.com/tikv/tikv/issues/17410) @[hhwyt](https://github.com/hhwyt) - tikv-ctlの`raft region`コマンドの出力にリージョンステータス情報が含まれていない問題を修正しました [#17037](https://github.com/tikv/tikv/issues/17037) @[glorv](https://github.com/glorv) - Grafana の TiKV パネルの**ストレージ非同期書き込み期間の**監視メトリックが不正確であるという問題を修正しました[#17579](https://github.com/tikv/tikv/issues/17579) @[overvenus](https://github.com/overvenus) @@ -233,7 +233,7 @@ TiDB バージョン: 7.1.6 - 遅延マテリアライゼーションが有効になっている場合に一部のクエリでエラーが報告される可能性がある問題を修正[#9472](https://github.com/pingcap/tiflash/issues/9472) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - TiFlashでサポートされていない一部の JSON関数がTiFlash にプッシュダウンされる問題を修正しました [#9444](https://github.com/pingcap/tiflash/issues/9444) @[windtalker](https://github.com/windtalker) - TiFlashで SSL 証明書の構成を空の文字列に設定すると、誤って TLS が有効になり、 TiFlash が起動しなくなる問題を修正しました[#9235](https://github.com/pingcap/tiflash/issues/9235) @[JaySon-Huang](https://github.com/JaySon-Huang) - - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取り要求タイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取りリクエストタイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - BRまたはTiDB Lightning 経由でデータをインポートした後、FastScanモードで多数の重複行が読み取られる可能性がある問題を修正しました。 [#9118](https://github.com/pingcap/tiflash/issues/9118) @[JinheLin](https://github.com/JinheLin) - テーブルに無効な文字を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブルスキーマを解析できない問題を修正しました。 [#9461](https://github.com/pingcap/tiflash/issues/9461) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - 遅延マテリアライゼーションが有効になった後、仮想生成列を含むクエリが誤った結果を返す可能性がある問題を修正[#9188](https://github.com/pingcap/tiflash/issues/9188) @[JinheLin](https://github.com/JinheLin) diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md index 2a58fe75f48c1..d7b78f8a1f6fc 100644 --- a/releases/release-7.2.0.md +++ b/releases/release-7.2.0.md @@ -26,7 +26,7 @@ TiDB バージョン: 7.2.0 - TiFlashはパイプライン実行モデルをサポートします（実験的） [#6518](https://github.com/pingcap/tiflash/issues/6518) @[SeaRise](https://github.com/SeaRise) - バージョン7.2.0より前は、 TiFlashエンジン内の各タスクは実行時に個別にスレッドリソースを要求する必要がありました。TiFlashはタスク数を制御することでスレッドリソースの使用量を制限し、過剰使用を防いでいましたが、この問題を完全に解消することはできませんでした。この問題に対処するため、バージョン7.2.0以降、 TiFlashはパイプライン実行モデルを導入しました。このモデルでは、すべてのスレッドリソースを一元的に管理し、タスクの実行を均一にスケジュールすることで、リソースの過剰使用を回避しながらスレッドリソースの利用率を最大化します。パイプライン実行モデルを有効または無効にするには、システム変数[`tidb_enable_tiflash_pipeline_model`](https://docs-archive.pingcap.com/tidb/v7.2/system-variables/#tidb_enable_tiflash_pipeline_model-new-in-v720)を変更してください。 + バージョン7.2.0より前は、 TiFlashエンジン内の各タスクは実行時に個別にスレッドリソースをリクエストする必要がありました。TiFlashはタスク数を制御することでスレッドリソースの使用量を制限し、過剰使用を防いでいましたが、この問題を完全に解消することはできませんでした。この問題に対処するため、バージョン7.2.0以降、 TiFlashはパイプライン実行モデルを導入しました。このモデルでは、すべてのスレッドリソースを一元的に管理し、タスクの実行を均一にスケジュールすることで、リソースの過剰使用を回避しながらスレッドリソースの利用率を最大化します。パイプライン実行モデルを有効または無効にするには、システム変数[`tidb_enable_tiflash_pipeline_model`](https://docs-archive.pingcap.com/tidb/v7.2/system-variables/#tidb_enable_tiflash_pipeline_model-new-in-v720)を変更してください。 詳細については、[ドキュメント](/tiflash/tiflash-pipeline-model.md)を参照してください。 @@ -191,7 +191,7 @@ TiDB バージョン: 7.2.0 - TiKV - - `pd.retry-interval`を使用した接続要求失敗などのシナリオで PD 接続の再試行間隔を設定することをサポートします [#14964](https://github.com/tikv/tikv/issues/14964) @[rleungx](https://github.com/rleungx) + - `pd.retry-interval`を使用した接続リクエスト失敗などのシナリオで PD 接続の再試行間隔を設定することをサポートします [#14964](https://github.com/tikv/tikv/issues/14964) @[rleungx](https://github.com/rleungx) - グローバルなリソース使用状況を組み込むことで、リソース制御スケジューリングアルゴリズムを最適化する [#14604](https://github.com/tikv/tikv/issues/14604) @[Connor1996](https://github.com/Connor1996) - `check_leader`リクエストに gzip 圧縮を使用してトラフィックを削減します [#14553](https://github.com/tikv/tikv/issues/14553) @[you06](https://github.com/you06) - `check_leader`リクエストに関連するメトリクスを追加 [#14658](https://github.com/tikv/tikv/issues/14658) @[you06](https://github.com/you06) diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index aeb0a1d2042a3..f14b593b28805 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -87,7 +87,7 @@ TiDB バージョン: 7.4.0 通常、TiKVはリクエストを数ミリ秒という非常に高速に処理します。しかし、TiKVノードがディスクI/Oジッターやネットワークレイテンシーに遭遇すると、リクエスト処理時間が大幅に増加する可能性があります。v7.4.0より前のバージョンでは、TiKVリクエストのタイムアウト制限は固定されており、調整できません。そのため、TiKVノードで問題が発生すると、TiDBは一定時間のタイムアウト応答を待機する必要があり、ジッター発生時のアプリケーションクエリパフォーマンスに顕著な影響が生じます。 - TiDB v7.4.0 では、新しいシステム変数[`tikv_client_read_timeout`](/system-variables.md#tikv_client_read_timeout-new-in-v740)が導入され、クエリで TiDB が TiKV に送信する RPC 読み取り要求のタイムアウトをカスタマイズできるようになりました。つまり、ディスクまたはネットワークの問題により TiKV ノードに送信された要求が遅延した場合、TiDB はより早くタイムアウトし、他の TiKV ノードに要求を再送信できるため、クエリのレイテンシーが短縮されます。すべての TiKV ノードでタイムアウトが発生した場合、TiDB はデフォルトのタイムアウトを使用して再試行します。さらに、クエリでオプティマイザヒント`/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */`を使用して、TiDB が TiKV RPC 読み取り要求を送信するタイムアウトを設定することもできます。この機能強化により、不安定なネットワークやストレージ環境に TiDB が柔軟に適応できるようになり、クエリのパフォーマンスが向上し、ユーザーエクスペリエンスが強化されます。 + TiDB v7.4.0 では、新しいシステム変数[`tikv_client_read_timeout`](/system-variables.md#tikv_client_read_timeout-new-in-v740)が導入され、クエリで TiDB が TiKV に送信する RPC 読み取りリクエストのタイムアウトをカスタマイズできるようになりました。つまり、ディスクまたはネットワークの問題により TiKV ノードに送信されたリクエストが遅延した場合、TiDB はより早くタイムアウトし、他の TiKV ノードにリクエストを再送信できるため、クエリのレイテンシーが短縮されます。すべての TiKV ノードでタイムアウトが発生した場合、TiDB はデフォルトのタイムアウトを使用して再試行します。さらに、クエリでオプティマイザヒント`/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */`を使用して、TiDB が TiKV RPC 読み取りリクエストを送信するタイムアウトを設定することもできます。この機能強化により、不安定なネットワークやストレージ環境に TiDB が柔軟に適応できるようになり、クエリのパフォーマンスが向上し、ユーザーエクスペリエンスが強化されます。 詳細については[ドキュメント](/system-variables.md#tikv_client_read_timeout-new-in-v740)を参照してください。 diff --git a/releases/release-7.5.0.md b/releases/release-7.5.0.md index 774d5cfe80fc8..2d083fc9d862e 100644 --- a/releases/release-7.5.0.md +++ b/releases/release-7.5.0.md @@ -121,7 +121,7 @@ TiDB 7.5.0は長期サポートリリース（LTS）です。 | コンフィグレーションファイル | コンフィグレーションパラメータ | 変更の種類 | 説明 | | -------------- | ---------------------------------------------------------------------------------------------------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------- | -| TiDB | [`tikv-client.copr-req-timeout`](/tidb-configuration-file.md#copr-req-timeout-new-in-v750) | 新しく追加された | 単一のコプロセッサー要求のタイムアウトを設定します。 | +| TiDB | [`tikv-client.copr-req-timeout`](/tidb-configuration-file.md#copr-req-timeout-new-in-v750) | 新しく追加された | 単一のコプロセッサーリクエストのタイムアウトを設定します。 | | TiKV | [`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval) | 変更 | 低速ノード検出の感度を向上させるためにアルゴリズムを最適化した後、デフォルト値を`500ms`から`100ms`に変更します。 | | TiKV | [`raftstore.region-compact-min-redundant-rows`](/tikv-configuration-file.md#region-compact-min-redundant-rows-new-in-v710) | 変更 | RocksDB の圧縮をトリガーするために必要な冗長 MVCC 行の数を設定します。v7.5.0 以降、この設定項目は`"raft-kv"`ストレージエンジンに対して有効になります。 | | TiKV | [`raftstore.region-compact-redundant-rows-percent`](/tikv-configuration-file.md#region-compact-redundant-rows-percent-new-in-v710) | 変更 | RocksDB の圧縮をトリガーするために必要な冗長 MVCC 行の割合を設定します。v7.5.0 以降、この設定項目は`"raft-kv"`ストレージエンジンに対して有効になります。 | @@ -206,7 +206,7 @@ v7.5.0 以降、次のコンテンツが`TiDB-community-toolkit`[バイナリパ - TiKV - - 悲観的トランザクションモードでのプリライト要求の再試行が、まれにデータ不整合のリスクを引き起こす可能性がある問題を修正しました [#11187](https://github.com/tikv/tikv/issues/11187) @[MyonKeminta](https://github.com/MyonKeminta) + - 悲観的トランザクションモードでのプリライトリクエストの再試行が、まれにデータ不整合のリスクを引き起こす可能性がある問題を修正しました [#11187](https://github.com/tikv/tikv/issues/11187) @[MyonKeminta](https://github.com/MyonKeminta) - PD diff --git a/releases/release-7.5.2.md b/releases/release-7.5.2.md index bd0ba3ef8f6b5..c7b6155e22df3 100644 --- a/releases/release-7.5.2.md +++ b/releases/release-7.5.2.md @@ -16,7 +16,7 @@ TiDB バージョン: 7.5.2 - RocksDB の TiKV 設定項目[`track-and-verify-wals-in-manifest`](https://docs.pingcap.com/tidb/v7.5/tikv-configuration-file#track-and-verify-wals-in-manifest-new-in-v659-v715-and-v752)を追加します。これは、Write Ahead Log (WAL) の破損の可能性を調査するのに役立ちます。 [#16549](https://github.com/tikv/tikv/issues/16549) @[v01dstar](https://github.com/v01dstar) - TiDB Lightning `strict-format`または`SPLIT_FILE`を使用して CSV ファイルをインポートする場合は、行末文字を設定する必要があります[#37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) - TiCDCオープンプロトコルの`sink.open.output-old-value`設定項目を追加して、更新前の値を下流に出力するかどうかを制御します。 [#10916](https://github.com/pingcap/tiflow/issues/10916) @[sdojjy](https://github.com/sdojjy) -- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`目のイベントで主キーまたは非NULLの一意インデックス値が変更されると、TiCDCはこのイベントを`DELETE`目と`INSERT`目のイベントに分割していました。v7.5.2以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS` TiCDC `thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`目のイベントを`DELETE` `INSERT`と13件目のイベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`目のイベントの順序が誤っている可能性があり、分割された`DELETE`と`INSERT`目のイベントの順序が誤っている可能性があるため、ダウンストリームデータの不整合が発生する問題に対処しています。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v7.5/ticdc-split-update-behavior#split-update-events-for-mysql-sinks) してください@[lidezhu](https://github.com/lidezhu) [#10918](https://github.com/pingcap/tiflow/issues/10918) +- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`イベントで主キーまたは非NULLの一意インデックス値が変更されると、TiCDCはこのイベントを`DELETE`と`INSERT`イベントに分割していました。v7.5.2以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS`がTiCDCの`thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`イベントを`DELETE`と`INSERT`イベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`イベントの順序が誤っている可能性があり、分割された`DELETE`と`INSERT`イベントの順序が誤っている可能性があるため、ダウンストリームデータの不整合が発生する問題に対処しています。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v7.5/ticdc-split-update-behavior#split-update-events-for-mysql-sinks)を参照してください。@[lidezhu](https://github.com/lidezhu) [#10918](https://github.com/pingcap/tiflow/issues/10918) ## 改善点 {#improvements} diff --git a/releases/release-7.5.3.md b/releases/release-7.5.3.md index 52c999e3cb6dd..c890f91a06daa 100644 --- a/releases/release-7.5.3.md +++ b/releases/release-7.5.3.md @@ -87,7 +87,7 @@ TiDB バージョン: 7.5.3 - TiKV - gRPC メッセージ圧縮方式を`grpc-compression-type`で設定しても、TiKV から TiDB に送信されるメッセージには反映されない問題を修正しました。 [#17176](https://github.com/tikv/tikv/issues/17176) @[ekexium](https://github.com/ekexium) - - 同時実行性の高いコプロセッサー要求により TiKV OOM が発生する可能性がある問題を修正しました [#16653](https://github.com/tikv/tikv/issues/16653) @[overvenus](https://github.com/overvenus) + - 同時実行性の高いコプロセッサーリクエストにより TiKV OOM が発生する可能性がある問題を修正しました [#16653](https://github.com/tikv/tikv/issues/16653) @[overvenus](https://github.com/overvenus) - CDC とログバックアップが`advance-ts-interval`構成を使用して`check_leader`のタイムアウトを制限しないため、TiKV が正常に再起動したときに`resolved_ts`遅延が大きくなる場合がある問題を修正しました[#17107](https://github.com/tikv/tikv/issues/17107) @[MyonKeminta](https://github.com/MyonKeminta) - 破損したRaftデータスナップショットを適用すると TiKV が繰り返しpanicする可能性がある問題を修正しました。 [#15292](https://github.com/tikv/tikv/issues/15292) @[LykxSassinator](https://github.com/LykxSassinator) diff --git a/releases/release-7.5.4.md b/releases/release-7.5.4.md index 1a8837062436c..d8e67e08ebe2e 100644 --- a/releases/release-7.5.4.md +++ b/releases/release-7.5.4.md @@ -33,7 +33,7 @@ TiDB バージョン: 7.5.4 - `LENGTH()`と`ASCII()`関数の実行効率を最適化 [#9344](https://github.com/pingcap/tiflash/issues/9344) @[xzhangxian1008](https://github.com/xzhangxian1008) - TLS を有効にした後に証明書を更新することでTiFlash がpanicする可能性がある問題を軽減します[#8535](https://github.com/pingcap/tiflash/issues/8535) @[windtalker](https://github.com/windtalker) - - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセル要求にタイムリーに応答できるようにします[#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) + - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセルリクエストにタイムリーに応答できるようにします[#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) - ツール @@ -93,7 +93,7 @@ TiDB バージョン: 7.5.4 - TiFlash - 分散ストレージおよびコンピューティングアーキテクチャでTiFlash書き込みノードが再起動に失敗する可能性がある問題を修正しました [#9282](https://github.com/pingcap/tiflash/issues/9282) @[JaySon-Huang](https://github.com/JaySon-Huang) - - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取り要求タイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取りリクエストタイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - `CAST()`関数を使用して文字列をタイムゾーンまたは無効な文字を含む日付時刻に変換すると、結果が正しくなくなる問題を修正しました[#8754](https://github.com/pingcap/tiflash/issues/8754) @[solotzg](https://github.com/solotzg) - 分散ストレージおよびコンピューティングアーキテクチャで、 TiFlash書き込みノードの読み取りスナップショットがタイムリーにリリースされない問題を修正しました。 [#9298](https://github.com/pingcap/tiflash/issues/9298) @[JinheLin](https://github.com/JinheLin) - テーブルに無効な文字を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブルスキーマを解析できない問題を修正しました。 [#9461](https://github.com/pingcap/tiflash/issues/9461) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) diff --git a/releases/release-7.5.7.md b/releases/release-7.5.7.md index 5cea735db8ef4..9f78c64de3f35 100644 --- a/releases/release-7.5.7.md +++ b/releases/release-7.5.7.md @@ -114,7 +114,7 @@ TiDB バージョン: 7.5.7 - CPUプロファイリング中にデッドロックが発生する可能性がある問題を修正 [#18474](https://github.com/tikv/tikv/issues/18474) @[YangKeao](https://github.com/YangKeao) - 特定のTiFlashレプリカによってオンライン アンセーフ リカバリがブロックされ、コミット インデックスが進まなくなる問題を修正しました。 [#18197](https://github.com/tikv/tikv/issues/18197) @[v01dstar](https://github.com/v01dstar) - TiKVがクライアントがデコードできない圧縮アルゴリズムを使用する可能性がある問題を修正しました [#18079](https://github.com/tikv/tikv/issues/18079) @[ekexium](https://github.com/ekexium) - - TiKV が高同時実行で過剰な SST 取り込み要求を許可する問題を修正 [#18452](https://github.com/tikv/tikv/issues/18452) @[hbisheng](https://github.com/hbisheng) + - TiKV が高同時実行で過剰な SST 取り込みリクエストを許可する問題を修正 [#18452](https://github.com/tikv/tikv/issues/18452) @[hbisheng](https://github.com/hbisheng) - Grafana の TiKV ダッシュボードで`Ingestion picked level`と`Compaction Job Size(files)`が誤って表示される問題を修正しました [#15990](https://github.com/tikv/tikv/issues/15990) @[Connor1996](https://github.com/Connor1996) - TiKV が再起動した後に予期しない`Server is busy`エラーが発生する問題を修正しました [#18233](https://github.com/tikv/tikv/issues/18233) @[LykxSassinator](https://github.com/LykxSassinator) - TiKVがブラジルとエジプトのタイムゾーンを誤って変換する問題を修正[#16220](https://github.com/tikv/tikv/issues/16220) @[overvenus](https://github.com/overvenus) diff --git a/releases/release-7.6.0.md b/releases/release-7.6.0.md index efc1fc751076c..6fc6d81c7086e 100644 --- a/releases/release-7.6.0.md +++ b/releases/release-7.6.0.md @@ -23,7 +23,7 @@ TiDB バージョン: 7.6.0 リージョン数の多いTiDBクラスタでは、ハートビート処理やタスクスケジューリングに伴うオーバーヘッドが増加するため、PDリーダーのCPU負荷が高くなる可能性があります。クラスタにTiDBインスタンスが多数存在し、リージョン情報へのリクエストが同時に多数発生すると、PDリーダーのCPU負荷はさらに高まり、PDサービスが利用できなくなる恐れがあります。 - 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリサービスの拡張性を向上させる Active PD Follower機能をサポートしています。Active PD Follower機能は、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) `ON`に設定することで有効にできます。この機能を有効にすると、TiDB はリージョン情報要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 + 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリサービスの拡張性を向上させる Active PD Follower機能をサポートしています。Active PD Follower機能は、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) `ON`に設定することで有効にできます。この機能を有効にすると、TiDB はリージョン情報リクエストをすべての PD サーバーに均等に分散し、PD フォロワーもリージョンリクエストを処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 詳細については、 [ドキュメント](/tune-region-performance.md#use-the-active-pd-follower-feature-to-enhance-the-scalability-of-pds-region-information-query-service)を参照してください。 @@ -239,7 +239,7 @@ TiDB バージョン: 7.6.0 | [`tidb_ignore_inlist_plan_digest`](/system-variables.md#tidb_ignore_inlist_plan_digest-new-in-v760) | 新しく追加された | プランダイジェストを生成する際に、TiDB が異なるクエリ間で`IN`リスト内の要素の差異を無視するかどうかを制御します。デフォルト値`OFF`は、差異を無視しないことを意味します。 | | [`tidb_opt_enable_fuzzy_binding`](/system-variables.md#tidb_opt_enable_fuzzy_binding-new-in-v760) | 新しく追加された | クロスデータベースバインディング機能を有効にするかどうかを制御します。デフォルト値`OFF`は、クロスデータベースバインディングが無効であることを意味します。 | | [`tidb_txn_entry_size_limit`](/system-variables.md#tidb_txn_entry_size_limit-new-in-v760) | 新しく追加された | TiDB 設定項目[`performance.txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)を動的に変更します。これは、TiDB 内の単一行のデータのサイズを制限します。この変数のデフォルト値は`0`です。これは、TiDB がデフォルトで設定項目`txn-entry-size-limit`の値を使用することを意味します。この変数がゼロ以外の値に設定されている場合、 `txn-entry-size-limit`も同じ値に設定されます。 | -| [`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) | 新しく追加された | 有効にするかどうかを制御します[アクティブなPDFollower](/tune-region-performance.md#use-the-active-pd-follower-feature-to-enhance-the-scalability-of-pds-region-information-query-service)機能 (実験的)。値が`OFF`の場合、TiDB は PD リーダーからのみリージョン情報を取得します。値が`ON`の場合、TiDB はリージョン情報の要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるため、PD リーダーの CPU 負荷が軽減されます。 | +| [`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) | 新しく追加された | 有効にするかどうかを制御します[アクティブなPDFollower](/tune-region-performance.md#use-the-active-pd-follower-feature-to-enhance-the-scalability-of-pds-region-information-query-service)機能 (実験的)。値が`OFF`の場合、TiDB は PD リーダーからのみリージョン情報を取得します。値が`ON`の場合、TiDB はリージョン情報のリクエストをすべての PD サーバーに均等に分散し、PD フォロワーもリージョンリクエストを処理できるため、PD リーダーの CPU 負荷が軽減されます。 | ### コンフィグレーションファイルパラメータ {#configuration-file-parameters} diff --git a/releases/release-8.0.0.md b/releases/release-8.0.0.md index 14e1e804edc26..a1669950892a9 100644 --- a/releases/release-8.0.0.md +++ b/releases/release-8.0.0.md @@ -303,7 +303,7 @@ TiDB バージョン: 8.0.0 | TiKV | [`rocksdb.defaultcf.titan.shared-blob-cache`](/tikv-configuration-file.md#shared-blob-cache-new-in-v800) | 新しく追加された | Titan blob ファイルと RocksDB ブロックファイルの共有キャッシュを有効にするかどうかを制御します。デフォルト値は`true`です。 | | TiKV | [`security.encryption.master-key.gcp.credential-file-path`](/encryption-at-rest.md#specify-a-master-key-via-kms) | 新しく追加された | `security.encryption.master-key.vendor`が`gcp`の場合に、Google Cloud 認証情報ファイルへのパスを指定します。 | | PD | [`schedule.enable-heartbeat-breakdown-metrics`](/pd-configuration-file.md#enable-heartbeat-breakdown-metrics-new-in-v800) | 新しく追加された | リージョンハートビートの内訳メトリクスを有効にするかどうかを制御します。これらのメトリクスは、リージョンハートビート処理の各段階で消費された時間を測定し、監視による分析を容易にします。デフォルト値は`true`です。 | -| PD | [`schedule.enable-heartbeat-concurrent-runner`](/pd-configuration-file.md#enable-heartbeat-concurrent-runner-new-in-v800) | 新しく追加された | リージョンハートビートの非同期同時処理を有効にするかどうかを制御します。有効にすると、独立したエグゼキュータがリージョンハートビート要求を非同期かつ同時に処理し、ハートビート処理のスループットを向上させ、レイテンシーを削減できます。デフォルト値は`true`です。 | +| PD | [`schedule.enable-heartbeat-concurrent-runner`](/pd-configuration-file.md#enable-heartbeat-concurrent-runner-new-in-v800) | 新しく追加された | リージョンハートビートの非同期同時処理を有効にするかどうかを制御します。有効にすると、独立したエグゼキュータがリージョンハートビートリクエストを非同期かつ同時に処理し、ハートビート処理のスループットを向上させ、レイテンシーを削減できます。デフォルト値は`true`です。 | | TiDB Lightning | [`tikv-importer.duplicate-resolution`](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#the-old-version-of-conflict-detection-deprecated-in-v800) | 非推奨 | 物理インポートモードで一意キーの競合を検出して解決するかどうかを制御します。v8.0.0以降は[`conflict.strategy`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)に置き換えられています。 | | TiDB Lightning | [`conflict.precheck-conflict-before-import`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) | 新しく追加された | TiDB にデータをインポートする前にデータの競合をチェックする、インポート前の競合検出を有効にするかどうかを制御します。このパラメータのデフォルト値は`false`で、これはTiDB Lightning がデータのインポート後にのみ競合をチェックすることを意味します。このパラメータは、物理インポートモード ( `tikv-importer.backend = "local"` ) でのみ使用できます。 | | TiDB Lightning | [`logical-import-batch-rows`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) | 新しく追加された | 論理インポートモードでトランザクションごとに挿入される行の最大数を制御します。デフォルト値は`65536`行です。 | diff --git a/releases/release-8.1.0.md b/releases/release-8.1.0.md index 9f170c09cba62..500a2b4fd0c5d 100644 --- a/releases/release-8.1.0.md +++ b/releases/release-8.1.0.md @@ -119,7 +119,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 | TiDB Lightning | [`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) | 変更 | デフォルト値を`9223372036854775807`から`10000`に変更することで、異常なタスクを迅速に中断し、対応する調整を迅速に行うことができます。これにより、異常なデータソースやテーブルスキーマ定義の誤りが原因で、インポート後に大量の競合データが発見されるというシナリオを回避し、時間と計算リソースを節約できます。 | | TiKV | [`raft-engine.batch-compression-threshold`](/tikv-configuration-file.md#batch-compression-threshold) | 変更 | デフォルト値を`"8KiB"`から`"4KiB"`に変更して、 Raftログの書き込みの IOPS オーバーヘッドを削減し、圧縮率を向上させます。 | | TiKV | [`memory.enable-thread-exclusive-arena`](/tikv-configuration-file.md#enable-thread-exclusive-arena-new-in-v810) | 新しく追加された | 各TiKVスレッドのメモリ使用量を追跡するために、TiKVスレッドレベルでメモリ割り当てステータスを表示するかどうかを制御します。デフォルト値は`true`です。 | -| TiCDC | [`security.client-allowed-user`](/ticdc/ticdc-server-config.md#cdc-server-configuration-file-parameters) | 新しく追加された | クライアント認証に許可されるユーザー名をリストします。このリストに含まれていないユーザー名による認証要求は拒否されます。デフォルト値はnullです。 | +| TiCDC | [`security.client-allowed-user`](/ticdc/ticdc-server-config.md#cdc-server-configuration-file-parameters) | 新しく追加された | クライアント認証に許可されるユーザー名をリストします。このリストに含まれていないユーザー名による認証リクエストは拒否されます。デフォルト値はnullです。 | | TiCDC | [`security.client-user-required`](/ticdc/ticdc-server-config.md#cdc-server-configuration-file-parameters) | 新しく追加された | クライアント認証にユーザー名とパスワードを使用するかどうかを制御します。デフォルト値は`false`です。 | | TiCDC | [`security.mtls`](/ticdc/ticdc-server-config.md#cdc-server-configuration-file-parameters) | 新しく追加された | TLSクライアント認証を有効にするかどうかを制御します。デフォルト値は`false`です。 | | TiCDC | [`sink.debezium.output-old-value`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | 行データが変更される前の値を出力するかどうかを制御します。デフォルト値は`true`です。無効にすると、 `UPDATE`イベントは"before"フィールドを出力しません。 | diff --git a/releases/release-8.1.1.md b/releases/release-8.1.1.md index 205c1683cd024..5387a20ed2232 100644 --- a/releases/release-8.1.1.md +++ b/releases/release-8.1.1.md @@ -159,7 +159,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - TiFlash - - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取り要求タイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取りリクエストタイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - `SUBSTRING_INDEX()`関数が一部のコーナーケースでTiFlash のクラッシュを引き起こす可能性がある問題を修正[#9116](https://github.com/pingcap/tiflash/issues/9116) @[wshwsh12](https://github.com/wshwsh12) - BRまたはTiDB Lightning 経由でデータをインポートした後、FastScanモードで多数の重複行が読み取られる可能性がある問題を修正しました。 [#9118](https://github.com/pingcap/tiflash/issues/9118) @[JinheLin](https://github.com/JinheLin) - データベースが作成直後に削除されるとTiFlash がpanicする可能性がある問題を修正[#9266](https://github.com/pingcap/tiflash/issues/9266) @[JaySon-Huang](https://github.com/JaySon-Huang) diff --git a/releases/release-8.1.2.md b/releases/release-8.1.2.md index 3d562aa5ee167..6e17f16660b04 100644 --- a/releases/release-8.1.2.md +++ b/releases/release-8.1.2.md @@ -36,8 +36,8 @@ TiDB バージョン: 8.1.2 - クラスター化インデックスを持つテーブルで、バックグラウンドでの古いデータのガベージコレクションの速度が向上しました。 [#9529](https://github.com/pingcap/tiflash/issues/9529) @[JaySon-Huang](https://github.com/JaySon-Huang) - TLS を有効にした後に証明書を更新することでTiFlash がpanicする可能性がある問題を軽減します[#8535](https://github.com/pingcap/tiflash/issues/8535) @[windtalker](https://github.com/windtalker) - - 分散ストレージとコンピューティング要求を処理するときにTiFlash が作成する必要があるスレッドの数を減らし、大量のそのような要求を処理するときにTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます[#9334](https://github.com/pingcap/tiflash/issues/9334) @[JinheLin](https://github.com/JinheLin) - - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセル要求にタイムリーに応答できるようにします[#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) + - 分散ストレージとコンピューティングリクエストを処理するときにTiFlash が作成する必要があるスレッドの数を減らし、大量のそのようなリクエストを処理するときにTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます[#9334](https://github.com/pingcap/tiflash/issues/9334) @[JinheLin](https://github.com/JinheLin) + - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセルリクエストにタイムリーに応答できるようにします[#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) - `LENGTH()`と`ASCII()`関数の実行効率を最適化 [#9344](https://github.com/pingcap/tiflash/issues/9344) @[xzhangxian1008](https://github.com/xzhangxian1008) - 分散ストレージおよびコンピューティングアーキテクチャ内のTiFlashコンピューティングノードの再試行戦略を最適化して、Amazon S3 からファイルをダウンロードする際の例外を処理します。 [#9695](https://github.com/pingcap/tiflash/issues/9695) @[JinheLin](https://github.com/JinheLin) diff --git a/releases/release-8.2.0.md b/releases/release-8.2.0.md index 77ced7c6a3234..d37a6d1b8359f 100644 --- a/releases/release-8.2.0.md +++ b/releases/release-8.2.0.md @@ -304,7 +304,7 @@ TiDB バージョン: 8.2.0 - `JSON_ARRAY_APPEND()`関数を TiKV にプッシュダウンすると TiKV がpanicを起こす問題を修正しました [#16930](https://github.com/tikv/tikv/issues/16930) @[dbsid](https://github.com/dbsid) - リーダーが失敗したスナップショットファイルを時間内にクリーンアップしない問題を修正 [#16976](https://github.com/tikv/tikv/issues/16976) @[hbisheng](https://github.com/hbisheng) - - 高度な同時コプロセッサー要求が TiKV OOM を引き起こす可能性がある問題を修正 [#16653](https://github.com/tikv/tikv/issues/16653) @[overvenus](https://github.com/overvenus) + - 同時実行性の高いコプロセッサーリクエストが TiKV OOM を引き起こす可能性がある問題を修正 [#16653](https://github.com/tikv/tikv/issues/16653) @[overvenus](https://github.com/overvenus) - `raftstore.periodic-full-compact-start-times`設定項目をオンラインで変更すると TiKV がpanicを引き起こす可能性がある問題を修正 [#17066](https://github.com/tikv/tikv/issues/17066) @[SpadeA-Tang](https://github.com/SpadeA-Tang) - `make docker`と`make docker_test`の不具合を修正 [#17075](https://github.com/tikv/tikv/issues/17075) @[shunki-fujita](https://github.com/shunki-fujita) - 監視ダッシュボードで**gRPC リクエストソースの期間**メトリクスが正しく表示されない問題を修正 [#17133](https://github.com/tikv/tikv/issues/17133) @[King-Dylan](https://github.com/King-Dylan) diff --git a/releases/release-8.3.0.md b/releases/release-8.3.0.md index 1560567dea0b3..2e2c4ca785e32 100644 --- a/releases/release-8.3.0.md +++ b/releases/release-8.3.0.md @@ -333,7 +333,7 @@ TiDBバージョン：8.3.0 - PD - リソースグループにロールをバインドする際にエラーが報告されない問題を修正 [#54417](https://github.com/pingcap/tidb/issues/54417) @[JmPotato](https://github.com/JmPotato) - - リソースグループが500ミリ秒以上トークンを要求するとクォータ制限に遭遇する問題を修正 [#8349](https://github.com/tikv/pd/issues/8349) @[nolouch](https://github.com/nolouch) + - リソースグループが500ミリ秒以上トークンをリクエストするとクォータ制限に遭遇する問題を修正 [#8349](https://github.com/tikv/pd/issues/8349) @[nolouch](https://github.com/nolouch) - `INFORMATION_SCHEMA.RUNAWAY_WATCHES`テーブル内の時間データ型が正しくない問題を修正 [#54770](https://github.com/pingcap/tidb/issues/54770) @[HuSharp](https://github.com/HuSharp) - リソースグループが高同時実行時にリソース使用量を効果的に制限できない問題を修正 [#8435](https://github.com/tikv/pd/issues/8435) @[nolouch](https://github.com/nolouch) - テーブル属性を取得する際に誤ったPD APIが呼び出される問題を修正 [#55188](https://github.com/pingcap/tidb/issues/55188) @[JmPotato](https://github.com/JmPotato) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index d4a908187956f..b83e605b3b21c 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -21,7 +21,7 @@ TiDB バージョン: 8.4.0 - TSOリクエストに並列バッチモードを導入し、TSO取得のレイテンシーを削減する[#54960](https://github.com/pingcap/tidb/issues/54960) [#8432](https://github.com/tikv/pd/issues/8432) @[MyonKeminta](https://github.com/MyonKeminta) - バージョン8.4.0より前では、TiDBはPDから[TSO](/tso.md)要求する際に、特定の期間に複数のTSO要求を収集し、それらをバッチ処理で順次処理することで、リモートプロシージャコール（RPC）要求の数を減らし、PDのワークロードを軽減していました。しかし、レイテンシーに敏感なシナリオでは、この逐次バッチ処理モードのパフォーマンスは理想的ではありませんでした。 + バージョン8.4.0より前では、TiDBはPDから[TSO](/tso.md)をリクエストする際に、特定の期間に複数のTSOリクエストを収集し、それらをバッチ処理で順次処理することで、リモートプロシージャコール（RPC）リクエストの数を減らし、PDのワークロードを軽減していました。しかし、レイテンシーに敏感なシナリオでは、この逐次バッチ処理モードのパフォーマンスは理想的ではありませんでした。 TiDB v8.4.0では、異なる同時実行能力を持つTSOリクエスト用の並列バッチモードが導入されました。並列モードはTSO取得のレイテンシーを短縮しますが、PDのワークロードが増加する可能性があります。TSO取得に並列RPCモードを設定するには、 [`tidb_tso_client_rpc_mode`](/system-variables.md#tidb_tso_client_rpc_mode-new-in-v840)システム変数を構成してください。 @@ -339,9 +339,9 @@ TiDB をアップグレードする前に、オペレーティングシステム - TiFlash - `LENGTH()`および`ASCII()`関数の実行効率を最適化する [#9344](https://github.com/pingcap/tiflash/issues/9344) @[xzhangxian1008](https://github.com/xzhangxian1008) - - TiFlashが分散ストレージとコンピューティング要求を処理する際に作成する必要のあるスレッド数を減らし、そのような要求を多数処理する際のTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます [#9334](https://github.com/pingcap/tiflash/issues/9334) @[JinheLin](https://github.com/JinheLin) + - TiFlashが分散ストレージとコンピューティングリクエストを処理する際に作成する必要のあるスレッド数を減らし、そのようなリクエストを多数処理する際のTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます [#9334](https://github.com/pingcap/tiflash/issues/9334) @[JinheLin](https://github.com/JinheLin) - パイプライン実行モデルにおけるタスク待機メカニズムの強化 [#8869](https://github.com/pingcap/tiflash/issues/8869) @[SeaRise](https://github.com/SeaRise) - - JOIN オペレーターがキャンセル要求にタイムリーに応答できるように、JOIN オペレーターのキャンセル メカニズムを改善 [#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) + - JOIN オペレーターがキャンセルリクエストにタイムリーに応答できるように、JOIN オペレーターのキャンセル メカニズムを改善 [#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) - ツール @@ -374,7 +374,7 @@ TiDB をアップグレードする前に、オペレーティングシステム - TopN オペレーターに続くオペレーターがメモリ制限を超えた場合にフォールバックアクションをトリガーできない問題を修正しました [#56185](https://github.com/pingcap/tidb/issues/56185) @[xzhangxian1008](https://github.com/xzhangxian1008) - ソートオペレーターの`ORDER BY`列に定数が含まれている場合に、列が固定されてしまう問題を修正しました。 [#55344](https://github.com/pingcap/tidb/issues/55344) @[xzhangxian1008](https://github.com/xzhangxian1008) - インデックスを追加する際に、PDリーダーを終了させた後に`8223 (HY000)`エラーが発生し、テーブル内のデータが不整合になる問題を修正しました [#55488](https://github.com/pingcap/tidb/issues/55488) @[tangenta](https://github.com/tangenta) - - DDL履歴ジョブが多すぎると、履歴DDLジョブに関する情報を要求するとOOMが発生する問題を修正 [#55711](https://github.com/pingcap/tidb/issues/55711) @[joccau](https://github.com/joccau) + - DDL履歴ジョブが多すぎると、履歴DDLジョブに関する情報をリクエストするとOOMが発生する問題を修正 [#55711](https://github.com/pingcap/tidb/issues/55711) @[joccau](https://github.com/joccau) - グローバルソートが有効で、リージョンサイズが96 MiBを超える場合に`IMPORT INTO`の実行が停止する問題を修正しました。 [#55374](https://github.com/pingcap/tidb/issues/55374) @[lance6716](https://github.com/lance6716) - 一時テーブルで`IMPORT INTO`を実行すると TiDB がクラッシュする問題を修正しました [#55970](https://github.com/pingcap/tidb/issues/55970) @[D3Hunter](https://github.com/D3Hunter) - 一意インデックスを追加すると`duplicate entry`エラーが発生する問題を修正 [#56161](https://github.com/pingcap/tidb/issues/56161) @[tangenta](https://github.com/tangenta) diff --git a/releases/release-8.5.0.md b/releases/release-8.5.0.md index 1f0a4aaf609f4..79f0a7ccf65cf 100644 --- a/releases/release-8.5.0.md +++ b/releases/release-8.5.0.md @@ -35,7 +35,7 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 リージョン数の多いTiDBクラスタでは、ハートビート処理やタスクスケジューリングに伴うオーバーヘッドが増加するため、PDリーダーのCPU負荷が高くなる可能性があります。クラスタにTiDBインスタンスが多数存在し、リージョン情報へのリクエストが同時に多数発生すると、PDリーダーのCPU負荷はさらに高まり、PDサービスが利用できなくなる恐れがあります。 - 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリサービスの拡張性を向上させる実験的機能として Active PD Followerが導入されました。v8.5.0 では、この機能が一般提供 (GA) になります。Active PD Follower機能を有効にするには、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760)を`ON`に設定します。この機能が有効になると、TiDB はリージョン情報要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 + 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリサービスの拡張性を向上させる実験的機能として Active PD Followerが導入されました。v8.5.0 では、この機能が一般提供 (GA) になります。Active PD Follower機能を有効にするには、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760)を`ON`に設定します。この機能が有効になると、TiDB はリージョン情報リクエストをすべての PD サーバーに均等に分散し、PD フォロワーもリージョンリクエストを処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 詳細については、 [ドキュメント](/tune-region-performance.md#use-the-active-pd-follower-feature-to-enhance-the-scalability-of-pds-region-information-query-service)を参照してください。 diff --git a/releases/release-8.5.4.md b/releases/release-8.5.4.md index efb389671c340..15978a40cc61f 100644 --- a/releases/release-8.5.4.md +++ b/releases/release-8.5.4.md @@ -42,7 +42,7 @@ TiDBバージョン：8.5.4 - TiFlashの正常なシャットダウンをサポート [#10266](https://github.com/pingcap/tiflash/issues/10266) @[gengliqi](https://github.com/gengliqi) - TiFlashサーバーをシャットダウンする際、 TiFlashは現在実行中のMPPタスクを構成可能なタイムアウト時間だけ継続させ、新しいMPPタスク要求を拒否するようになりました。デフォルトのタイムアウト時間は600秒で、 [`flash.graceful_wait_shutdown_timeout`](https://docs.pingcap.com/tidb/v8.5/tiflash-configuration#graceful_wait_shutdown_timeout-new-in-v854)設定項目を使用して調整できます。 + TiFlashサーバーをシャットダウンする際、 TiFlashは現在実行中のMPPタスクを構成可能なタイムアウト時間だけ継続させ、新しいMPPタスクリクエストを拒否するようになりました。デフォルトのタイムアウト時間は600秒で、 [`flash.graceful_wait_shutdown_timeout`](https://docs.pingcap.com/tidb/v8.5/tiflash-configuration#graceful_wait_shutdown_timeout-new-in-v854)設定項目を使用して調整できます。 - 実行中のすべてのMPPタスクがタイムアウト期間内に終了した場合、 TiFlashは直ちにシャットダウンします。 - タイムアウト期間が経過しても未完了のMPPタスクが残っている場合、 TiFlashは強制的にシャットダウンします。 diff --git a/releases/release-8.5.6.md b/releases/release-8.5.6.md index 287172ceb0e74..73b003953b62e 100644 --- a/releases/release-8.5.6.md +++ b/releases/release-8.5.6.md @@ -107,7 +107,7 @@ TiDBクラスタをv8.5.5で新規にデプロイした場合（つまり、v8.5 | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------- | | TiKV | [`gc.auto-compaction.mvcc-read-aware-enabled`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-read-aware-enabled-new-in-v856) | 新しく追加された | MVCC読み取り対応の圧縮を有効にするかどうかを制御します。デフォルト値は`false`です。 | | TiKV | [`gc.auto-compaction.mvcc-read-weight`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-read-weight-new-in-v856) | 新しく追加された | リージョンの圧縮優先度スコアを計算する際に、MVCC 読み取りアクティビティに適用される重み乗数。デフォルト値は`3.0`です。 | -| TiKV | [`gc.auto-compaction.mvcc-scan-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-scan-threshold-new-in-v856) | 新しく追加された | リージョンを圧縮候補としてマークするために、読み取り要求ごとにスキャンされる MVCC バージョンの最小数。デフォルト値は`1000`です。 | +| TiKV | [`gc.auto-compaction.mvcc-scan-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-scan-threshold-new-in-v856) | 新しく追加された | リージョンを圧縮候補としてマークするために、読み取りリクエストごとにスキャンされる MVCC バージョンの最小数。デフォルト値は`1000`です。 | | TiCDC | [`sink.csv.output-field-header`](https://docs.pingcap.com/tidb/v8.5/ticdc-csv#use-csv) | 新しく追加された | CSVファイルにヘッダー行を出力するかどうかを制御します。デフォルト値は`false`です。このパラメータはTiCDCの新しいアーキテクチャにのみ適用されます。 | ### システムテーブルの変更 {#system-table-changes} @@ -163,10 +163,10 @@ TiDBクラスタをv8.5.5で新規にデプロイした場合（つまり、v8.5 - クロスビームスキップリストのメモリリーク問題を修正 [#19285](https://github.com/tikv/tikv/issues/19285) @[ekexium](https://github.com/ekexium) - パーティションテーブルの一意でない列のグローバルインデックスが、場合によっては不整合になり、誤った結果を返す可能性がある問題を修正しました [#19262](https://github.com/tikv/tikv/issues/19262) @[mjonss](https://github.com/mjonss) - コプロセッサのスナップショット取得が停止すると、リクエストの期限が切れるまで統合リードプールワーカーが占有され、他のリードリクエストが遅延する問題を修正しました [#18491](https://github.com/tikv/tikv/issues/18491) @[AndreMouche](https://github.com/AndreMouche) - - ディスクがいっぱいの TiKV ノードでフォロワーの読み取りがブロックされたままになる可能性がある問題を修正するため、ディスクがいっぱいのフォロワーで読み取りインデックス要求を拒否します [#19201](https://github.com/tikv/tikv/issues/19201) @[glorv](https://github.com/glorv) + - ディスクがいっぱいの TiKV ノードでフォロワーの読み取りがブロックされたままになる可能性がある問題を修正するため、ディスクがいっぱいのフォロワーで読み取りインデックスリクエストを拒否します [#19201](https://github.com/tikv/tikv/issues/19201) @[glorv](https://github.com/glorv) - resolved-tsワーカーがビジー状態のときに、 resolved-tsタスクのバックログによって OOM が発生する可能性がある問題を修正 [#18359](https://github.com/tikv/tikv/issues/18359) @[overvenus](https://github.com/overvenus) - - リーダー転送中にロングテールフォロワーの読み取りレイテンシーが発生する可能性がある問題を修正するため、読み取りインデックス要求をより早く再試行し、専用の再試行間隔設定を追加しました [#18417](https://github.com/tikv/tikv/issues/18417) @[gengliqi](https://github.com/gengliqi) - - 悲観的トランザクションでプリライト要求を再試行する際に発生するまれなデータ不整合の問題を修正 [#11187](https://github.com/tikv/tikv/issues/11187) @[wk989898](https://github.com/wk989898) + - リーダー転送中にロングテールフォロワーの読み取りレイテンシーが発生する可能性がある問題を修正するため、読み取りインデックスリクエストをより早く再試行し、専用の再試行間隔設定を追加しました [#18417](https://github.com/tikv/tikv/issues/18417) @[gengliqi](https://github.com/gengliqi) + - 悲観的トランザクションでプリライトリクエストを再試行する際に発生するまれなデータ不整合の問題を修正 [#11187](https://github.com/tikv/tikv/issues/11187) @[wk989898](https://github.com/wk989898) - PD diff --git a/smooth-upgrade-tidb.md b/smooth-upgrade-tidb.md index f0c1aa0376bbb..e1b29d3ad8bc5 100644 --- a/smooth-upgrade-tidb.md +++ b/smooth-upgrade-tidb.md @@ -59,14 +59,14 @@ v1.14.0以降、 TiUPはこの機能を自動的にサポートします。つ You can take the following steps to upgrade TiDB manually or by using a script: -1. クラスター内の任意の TiDB ノードに HTTP アップグレード開始要求を送信します`curl -X POST http://{TiDBIP}:10080/upgrade/start` . +1. クラスター内の任意の TiDB ノードに HTTP アップグレード開始リクエストを送信します`curl -X POST http://{TiDBIP}:10080/upgrade/start` . - The TiDB cluster enters the **Upgrading** state. - The DDL operations to be performed are paused. 2. Replace the TiDB binary and perform a rolling upgrade. This process is the same as the original upgrade process. - システム DDL 操作はアップグレードプロセス中に実行されます。 -3. クラスター内のすべての TiDB ノードが正常にアップグレードされたら、任意の TiDB ノードに HTTP アップグレード完了要求を送信します`curl -X POST http://{TiDBIP}:10080/upgrade/finish` . +3. クラスター内のすべての TiDB ノードが正常にアップグレードされたら、任意の TiDB ノードに HTTP アップグレード完了リクエストを送信します`curl -X POST http://{TiDBIP}:10080/upgrade/finish` . - ユーザーの一時停止された DDL 操作が再開されます。 ## Limitations {#limitations} diff --git a/sql-statements/sql-statement-explain-analyze.md b/sql-statements/sql-statement-explain-analyze.md index 44cfae99465c9..9ccc073d45f84 100644 --- a/sql-statements/sql-statement-explain-analyze.md +++ b/sql-statements/sql-statement-explain-analyze.md @@ -102,7 +102,7 @@ EXPLAIN ANALYZE SELECT * FROM t1; ### Batch PointGet {#batch-point-get} -`Batch_Point_Get`オペレーターの実行情報は`Point_Get`オペレーターと似ていますが、 `Batch_Point_Get`通常、データを読み取りするために`BatchGet` RPC リクエストを TiKV に送信します。 +`Batch_Point_Get`オペレーターの実行情報は`Point_Get`オペレーターと似ていますが、 `Batch_Point_Get`は通常、データを読み取るために`BatchGet` RPC リクエストを TiKV に送信します。 `BatchGet:{num_rpc:2, total_time:83.13µs}` : TiKVに送信された`BatchGet`タイプのRPCリクエストの数( `num_rpc` )とすべてのRPCリクエストに費やされた合計時間( `total_time` )。 @@ -117,7 +117,7 @@ cop_task: {num: 6, max: 1.07587ms, min: 844.312µs, avg: 919.601µs, p95: 1.0758 - `cop_task` : `cop`のタスクの実行情報が含まれます。例: - `num` : cop タスクの数。 - `max` 、 `min` 、 `avg` 、 `p95` : cop タスクの実行に費やされた実行時間の最大値、最小値、平均値、および P95 値。 - - `max_proc_keys`と`p95_proc_keys` ：TiKVがすべてのcopタスクでスキャンしたキーバリューの数の最大値とP95値。最大値とP95値の差が大きい場合、データ分布が不均衡になる可能性があります。 + - `max_proc_keys`と`p95_proc_keys` ：TiKVがすべてのcopタスクでスキャンしたキー値の数の最大値とP95値。最大値とP95値の差が大きい場合、データ分布が不均衡になる可能性があります。 - `copr_cache_hit_ratio` : `cop`タスクリクエストに対するコプロセッサーキャッシュのヒット率。 - `rpc_info` : リクエストタイプ別に集計された、TiKV に送信された RPC リクエストの合計数と合計時間。 - `backoff` : さまざまなタイプのバックオフとバックオフの合計待機時間が含まれます。 diff --git a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md index ba27bf0290c74..9a53725fe328f 100644 --- a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md +++ b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md @@ -102,7 +102,7 @@ ERROR 1066 (42000): Not unique table/alias: 't' ### テーブルロックの取得 {#table-lock-acquisition} -- TiDBでは、セッションAが既にテーブルロックを保持している場合、セッションBがそのテーブルに書き込みを試みるとエラーが返されます。MySQLでは、セッションBの書き込み要求はセッションAがテーブルロックを解放するまでブロックされ、他のセッションからのテーブルロック要求は現在のセッションが`WRITE`ロックを解放するまでブロックされます。 +- TiDBでは、セッションAが既にテーブルロックを保持している場合、セッションBがそのテーブルに書き込みを試みるとエラーが返されます。MySQLでは、セッションBの書き込みリクエストはセッションAがテーブルロックを解放するまでブロックされ、他のセッションからのテーブルロックリクエストは現在のセッションが`WRITE`ロックを解放するまでブロックされます。 - TiDBでは、 `LOCK TABLES`文に必要なロックが別のセッションによって保持されている場合、 `LOCK TABLES`の文は待機する必要があり、この文の実行時にエラーが返されます。MySQLでは、この文はロックが取得されるまでブロックされます。 - TiDBでは、 `LOCK TABLES`文はクラスタ全体で有効です。MySQLでは、この文は現在のMySQLサーバーでのみ有効であり、NDBクラスタとは互換性がありません。 diff --git a/sql-statements/sql-statement-split-region.md b/sql-statements/sql-statement-split-region.md index 15172d73297ee..a9f978ccc4927 100644 --- a/sql-statements/sql-statement-split-region.md +++ b/sql-statements/sql-statement-split-region.md @@ -7,7 +7,7 @@ summary: TiDBデータベースにおけるスプリットリージョンの使 TiDBで新しいテーブルを作成するたびに、デフォルトで1つの[リージョン](/tidb-storage.md#region)が分割され、そのテーブルのデータが格納されます。このデフォルトの動作は、TiDB構成ファイルの`split-table`によって制御されます。このリージョン内のデータがデフォルトのリージョンサイズ制限を超えると、リージョンは2つに分割され始めます。 -上記の場合、初期状態ではリージョンが1つしかないため、すべての書き込み要求はリージョンが配置されているTiKV上で発生します。新しく作成されたテーブルへの書き込みが大量に発生すると、ホットスポットが発生します。 +上記の場合、初期状態ではリージョンが1つしかないため、すべての書き込みリクエストはリージョンが配置されているTiKV上で発生します。新しく作成されたテーブルへの書き込みが大量に発生すると、ホットスポットが発生します。 上記シナリオにおけるホットスポット問題を解決するために、TiDBは事前分割機能を導入しました。この機能は、指定されたパラメータに従って特定のテーブルに対して複数のリージョンを事前に分割し、それらを各TiKVノードに分散させることができます。 diff --git a/stale-read.md b/stale-read.md index b90130d7e9909..c1d1a7fee4b1e 100644 --- a/stale-read.md +++ b/stale-read.md @@ -13,15 +13,15 @@ summary: ステイル読み取りとその使用シナリオについて学習 -- シナリオ 1: トランザクションが読み取り操作のみを伴い、ある程度のデータの古さが許容される場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリ要求を任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のストレージノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、クエリ全体のスループットが向上し、クエリのパフォーマンスが大幅に向上します。 +- シナリオ 1: トランザクションが読み取り操作のみを伴い、ある程度のデータの古さが許容される場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリリクエストを任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のストレージノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、クエリ全体のスループットが向上し、クエリのパフォーマンスが大幅に向上します。 -- シナリオ 2: 地理的に分散したデプロイメントの一部のシナリオでは、フォロワーから読み取ったデータがLeaderに保存されているデータと整合していることを確認するために、強力な整合性を持つフォロワー読み取りを使用する場合、TiDB は検証のために異なるデータセンターに`Readindex`を要求します。これにより、クエリプロセス全体のアクセスレイテンシーが増加します。ステイル読み取りを使用すると、TiDB は現在のデータセンターのレプリカにアクセスして対応するデータを読み取りますが、リアルタイムパフォーマンスが多少犠牲になります。これにより、センター間接続によるネットワークレイテンシーが回避され、クエリ全体のアクセスレイテンシーが短縮されます。詳細については、 [3つのデータセンターデプロイにおけるローカル読み取りのベストプラクティス](/best-practices/three-dc-local-read.md)を参照してください。 +- シナリオ 2: 地理的に分散したデプロイメントの一部のシナリオでは、フォロワーから読み取ったデータがLeaderに保存されているデータと整合していることを確認するために、強力な整合性を持つフォロワー読み取りを使用する場合、TiDB は検証のために異なるデータセンターに`Readindex`をリクエストします。これにより、クエリプロセス全体のアクセスレイテンシーが増加します。ステイル読み取りを使用すると、TiDB は現在のデータセンターのレプリカにアクセスして対応するデータを読み取りますが、リアルタイムパフォーマンスが多少犠牲になります。これにより、センター間接続によるネットワークレイテンシーが回避され、クエリ全体のアクセスレイテンシーが短縮されます。詳細については、 [3つのデータセンターデプロイにおけるローカル読み取りのベストプラクティス](/best-practices/three-dc-local-read.md)を参照してください。 -トランザクションが読み取り操作のみで、ある程度のデータの古さを許容する場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリ要求を任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のストレージノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、全体的なクエリ スループットが向上し、クエリのパフォーマンスが大幅に向上します。 +トランザクションが読み取り操作のみで、ある程度のデータの古さを許容する場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリリクエストを任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のストレージノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、全体的なクエリ スループットが向上し、クエリのパフォーマンスが大幅に向上します。 diff --git a/statement-summary-tables.md b/statement-summary-tables.md index 883f2a5b1cd6c..d67c8361abab0 100644 --- a/statement-summary-tables.md +++ b/statement-summary-tables.md @@ -391,7 +391,7 @@ TiDBサーバーに関連するフィールド： TiKVコプロセッサータスクに関連するフィールド： -- `SUM_COP_TASK_NUM` : 送信されたコプロセッサー要求の総数。 +- `SUM_COP_TASK_NUM` : 送信されたコプロセッサーリクエストの総数。 - `MAX_COP_PROCESS_TIME` :コプロセッサータスクの最大実行時間。 - `MAX_COP_PROCESS_ADDRESS` : 実行時間が最大となるコプロセッサータスクのアドレス。 - `MAX_COP_WAIT_TIME` :コプロセッサータスクの最大待機時間。 diff --git a/system-variables.md b/system-variables.md index dc5f28713a55e..2614bf8834be3 100644 --- a/system-variables.md +++ b/system-variables.md @@ -801,10 +801,10 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `OFF` -- この変数は、アクティブ PDFollower機能を有効にするかどうかを制御します (現在はリージョン情報の要求にのみ適用されます)。値が`OFF`の場合、TiDB は PD リーダーからのみリージョン情報を取得します。値が`ON`の場合、TiDB はリージョン情報の要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるため、PD リーダーの CPU 負荷が軽減されます。 +- この変数は、アクティブ PDFollower機能を有効にするかどうかを制御します (現在はリージョン情報のリクエストにのみ適用されます)。値が`OFF`の場合、TiDB は PD リーダーからのみリージョン情報を取得します。値が`ON`の場合、TiDB はリージョン情報のリクエストをすべての PD サーバーに均等に分散し、PD フォロワーもリージョンリクエストを処理できるため、PD リーダーの CPU 負荷が軽減されます。 - アクティブPDFollowerを有効にするシナリオ： - リージョン数が多いクラスターでは、ハートビートの処理やタスクのスケジューリングに伴うオーバーヘッドが増加するため、PDリーダーのCPU負荷が高くなります。 - - TiDBインスタンスが多数存在するTiDBクラスタでは、リージョン情報に対する要求の同時発生率が高いため、PDリーダーに高いCPU負荷がかかります。 + - TiDBインスタンスが多数存在するTiDBクラスタでは、リージョン情報に対するリクエストの同時発生率が高いため、PDリーダーに高いCPU負荷がかかります。 ### performance_schema_session_connect_attrs_size New in v8.5.7 @@ -1050,7 +1050,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - デフォルト値: `4096` - 範囲: `[0, 9223372036854775807]` - 単位：バイト -- この変数は、 [`tidb_replica_read`](#tidb_replica_read-new-in-v40)が`closest-adaptive`に設定されている場合、TiDBサーバーが読み取り要求を TiDBサーバーと同じアベイラビリティゾーン内のレプリカに送信することを優先するしきい値を制御するために使用されます。推定結果がこのしきい値以上の場合、TiDB は読み取り要求を同じアベイラビリティゾーン内のレプリカに送信することを優先します。それ以外の場合は、TiDB はリーダーレプリカに読み取り要求を送信します。 +- この変数は、 [`tidb_replica_read`](#tidb_replica_read-new-in-v40)が`closest-adaptive`に設定されている場合、TiDBサーバーが読み取りリクエストを TiDBサーバーと同じアベイラビリティゾーン内のレプリカに送信することを優先するしきい値を制御するために使用されます。推定結果がこのしきい値以上の場合、TiDB は読み取りリクエストを同じアベイラビリティゾーン内のレプリカに送信することを優先します。それ以外の場合は、TiDB はリーダーレプリカに読み取りリクエストを送信します。 ### tidb_advancer_check_point_lag_limit New in v8.5.5 @@ -1081,11 +1081,11 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - 型: 整数 - デフォルト値: `1` - 範囲: `[0, 2]` -- この変数は、TiDBがTiFlashにコプロセッサ要求を送信する方法を制御するために使用されます。この変数には以下の値があります。 +- この変数は、TiDBがTiFlashにコプロセッサリクエストを送信する方法を制御するために使用されます。この変数には以下の値があります。 - `0` : リクエストをバッチで送信しません - `1` :集計および結合リクエストはバッチで送信されます - - `2` : すべてのコプロセッサ要求はバッチで送信されます + - `2` : すべてのコプロセッサリクエストはバッチで送信されます ### tidb_allow_fallback_to_tikv New in v5.0 @@ -1340,7 +1340,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - 型: 整数 - デフォルト値: `10` - 範囲: `[1, 2147483647]` -- この変数は、読み取り要求がロックに遭遇したときの`backoff`時間を設定するために使用されます。 +- この変数は、読み取りリクエストがロックに遭遇したときの`backoff`時間を設定するために使用されます。 ### tidb_backoff_weight @@ -1350,7 +1350,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - 型: 整数 - デフォルト値: `2` - 範囲: `[0, 2147483647]` -- この変数は、TiDB `backoff`の最大再試行待機時間の重みを増やすために使用されます。つまり、内部ネットワークまたは他のコンポーネント(TiKV、PD) の障害が発生した場合に再試行要求を送信する際の最大再試行待機時間です。この変数を使用して最大再試行待機時間を調整でき、最小値は`1`です。 +- この変数は、TiDB `backoff`の最大再試行待機時間の重みを増やすために使用されます。つまり、内部ネットワークまたは他のコンポーネント(TiKV、PD) の障害が発生した場合に再試行リクエストを送信する際の最大再試行待機時間です。この変数を使用して最大再試行待機時間を調整でき、最小値は`1`です。 例えば、TiDB が TiKV から KV を取得する際の基本再試行待機時間は 15 秒です。 `tidb_backoff_weight = 2`の場合、KV を取得する際の最大再試行待機時間は、*基本時間 * 2 = 30 秒*です。 @@ -2588,7 +2588,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Boolean - デフォルト値: `ON` -- この変数は、ページング方式を使用してコプロセッサ要求を送信するかどうかを制御します。TiDB バージョン (v5.4.0、v6.2.0) では、この変数は`IndexLookup`オペレーターにのみ有効です。v6.2.0 以降では、この変数はグローバルに有効です。v6.4.0 以降、この変数のデフォルト値は`OFF`から`ON`に変更されました。 +- この変数は、ページング方式を使用してコプロセッサリクエストを送信するかどうかを制御します。TiDB バージョン (v5.4.0、v6.2.0) では、この変数は`IndexLookup`オペレーターにのみ有効です。v6.2.0 以降では、この変数はグローバルに有効です。v6.4.0 以降、この変数のデフォルト値は`OFF`から`ON`に変更されました。 - ユーザーシナリオ： - すべてのOLTPシナリオにおいて、ページング方式を使用することが推奨されます。 @@ -2784,7 +2784,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `ON` - 値のオプション: `OFF` 、 `ON` -- この変数は、TiDB がチャンク オブジェクトのキャッシュを有効にするかどうかを制御します。値が`ON` `OFF`の場合、TiDB はシステムから直接チャンク オブジェクトを要求します。 +- この変数は、TiDB がチャンク オブジェクトのキャッシュを有効にするかどうかを制御します。値が`ON` `OFF`の場合、TiDB はシステムから直接チャンク オブジェクトをリクエストします。 ### tidb_enable_shared_lock_promotion New in v8.3.0 @@ -2972,7 +2972,7 @@ Query OK, 0 rows affected (0.09 sec) - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `OFF` -- この変数は、TSOFollowerプロキシ機能を有効にするかどうかを制御します。値が`OFF`の場合、TiDBはPDリーダーからのみTSOを取得します。値が`ON`の場合、TiDBはTSO要求をすべてのPDサーバーに均等に分散し、PDフォロワーもTSO要求を処理できるため、PDリーダーのCPU負荷が軽減されます。 +- この変数は、TSOFollowerプロキシ機能を有効にするかどうかを制御します。値が`OFF`の場合、TiDBはPDリーダーからのみTSOを取得します。値が`ON`の場合、TiDBはTSOリクエストをすべてのPDサーバーに均等に分散し、PDフォロワーもTSOリクエストを処理できるため、PDリーダーのCPU負荷が軽減されます。 - TSOFollowerプロキシを有効にするシナリオ： - TSOリクエストの負荷が高いため、PDリーダーのCPUがボトルネックとなり、TSO RPCリクエストのレイテンシーが増大します。 - TiDBクラスタには多数のTiDBインスタンスが存在するため、 [`tidb_tso_client_batch_max_wait_time`](#tidb_tso_client_batch_max_wait_time-new-in-v530)の値を増やしても、TSO RPCリクエストの高レイテンシーの問題は解消されません。 @@ -3430,7 +3430,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `ON` -- この変数は、非同期コミットにおけるcommit TSの計算方法を制御します。デフォルトでは（ `ON`値の場合）、2フェーズコミットはPDサーバーから新しいTSを要求し、そのTSを使用して最終的なcommit TSを計算します。この場合、すべての同時実行トランザクションに対して線形化可能性が保証されます。 +- この変数は、非同期コミットにおけるcommit TSの計算方法を制御します。デフォルトでは（ `ON`値の場合）、2フェーズコミットはPDサーバーから新しいTSをリクエストし、そのTSを使用して最終的なcommit TSを計算します。この場合、すべての同時実行トランザクションに対して線形化可能性が保証されます。 - この変数を`OFF`に設定すると、PDサーバーから TS を取得するプロセスがスキップされますが、その代償として、因果関係の一貫性のみが保証されますが、線形化可能性は保証されません。詳細については、ブログ投稿[TiDB 5.0 のトランザクションコミットを加速する非同期コミット](https://www.pingcap.com/blog/async-commit-the-accelerator-for-transaction-commit-in-tidb-5-0/)を参照してください。 - 因果関係の一貫性のみが必要なシナリオでは、この変数を`OFF`に設定することでパフォーマンスを向上させることができます。 @@ -3576,7 +3576,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `0` - 範囲: `[0, 18446744073709551615]` - この変数は、インデックス結合の選択にペナルティコストを適用するかどうかを決定します。ペナルティコストを適用すると、オプティマイザがインデックス結合を選択する可能性が低くなり、ハッシュ結合やTiFlash結合などの代替結合方法を選択する可能性が高くなります。 -- インデックス結合を選択すると、多数のテーブル検索要求が発生し、リソースを過剰に消費します。この変数を使用することで、オプティマイザがインデックス結合を選択する可能性を低減できます。 +- インデックス結合を選択すると、多数のテーブル検索リクエストが発生し、リソースを過剰に消費します。この変数を使用することで、オプティマイザがインデックス結合を選択する可能性を低減できます。 - この変数は、 [`tidb_cost_model_version`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数が`2`に設定されている場合にのみ有効になります。 ### tidb_index_lookup_concurrency @@ -3990,7 +3990,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `50000` - 範囲: `[1, 9223372036854775807]` - 単位：行 -- この変数は、コプロセッサのページング要求処理中に処理する最大行数を設定するために使用されます。値を小さく設定しすぎると、TiDBとTiKV間のRPC回数が増加します。一方、値を大きく設定しすぎると、データのロードやフルテーブルスキャンなど、場合によってはメモリ使用量が過剰になります。この変数のデフォルト値は、OLAPシナリオよりもOLTPシナリオで優れたパフォーマンスを発揮します。アプリケーションがストレージエンジンとしてTiKVのみを使用している場合は、OLAPワークロードクエリを実行する際にこの変数の値を増やすことを検討してください。これにより、パフォーマンスが向上する可能性があります。 +- この変数は、コプロセッサのページングリクエスト処理中に処理する最大行数を設定するために使用されます。値を小さく設定しすぎると、TiDBとTiKV間のRPC回数が増加します。一方、値を大きく設定しすぎると、データのロードやフルテーブルスキャンなど、場合によってはメモリ使用量が過剰になります。この変数のデフォルト値は、OLAPシナリオよりもOLTPシナリオで優れたパフォーマンスを発揮します。アプリケーションがストレージエンジンとしてTiKVのみを使用している場合は、OLAPワークロードクエリを実行する際にこの変数の値を増やすことを検討してください。これにより、パフォーマンスが向上する可能性があります。 ### tidb_max_tiflash_threads New in v6.1.0 @@ -4230,7 +4230,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `128` - 範囲: `[1, 9223372036854775807]` - 単位：行 -- この変数は、コプロセッサのページング要求処理中に最小行数を設定するために使用されます。値を小さく設定しすぎると、TiDBとTiKV間のRPC要求数が増加します。一方、値を大きく設定しすぎると、Limitを使用したIndexLookupクエリの実行時にパフォーマンスが低下する可能性があります。この変数のデフォルト値は、OLAPシナリオよりもOLTPシナリオで優れたパフォーマンスを発揮します。アプリケーションがストレージエンジンとしてTiKVのみを使用している場合は、OLAPワークロードクエリを実行する際にこの変数の値を増やすことを検討してください。これにより、パフォーマンスが向上する可能性があります。 +- この変数は、コプロセッサのページングリクエスト処理中に最小行数を設定するために使用されます。値を小さく設定しすぎると、TiDBとTiKV間のRPCリクエスト数が増加します。一方、値を大きく設定しすぎると、Limitを使用したIndexLookupクエリの実行時にパフォーマンスが低下する可能性があります。この変数のデフォルト値は、OLAPシナリオよりもOLTPシナリオで優れたパフォーマンスを発揮します。アプリケーションがストレージエンジンとしてTiKVのみを使用している場合は、OLAPワークロードクエリを実行する際にこの変数の値を増やすことを検討してください。これにより、パフォーマンスが向上する可能性があります。 ![Paging size impact on TPCH](/media/paging-size-impact-on-tpch.png) @@ -5152,7 +5152,7 @@ SHOW WARNINGS; - 型: Float - 範囲: `[0, 2147483647]` - デフォルト値: `20` -- TiDBがTiKVからデータを要求する際の起動コストを示します。この変数は[コストモデル](/cost-model.md)によって内部的に使用されるため、値を変更することは推奨され**ません**。 +- TiDBがTiKVからデータをリクエストする際の起動コストを示します。この変数は[コストモデル](/cost-model.md)によって内部的に使用されるため、値を変更することは推奨され**ません**。 ### tidb_opt_skew_distinct_agg New in v6.2.0 @@ -6515,7 +6515,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - デフォルト値: `0` - 範囲: `[0, 10]` - 単位：ミリ秒 -- この変数は、TiDBがPDからTSOを要求する際のバッチ操作の最大待機時間を設定するために使用されます。デフォルト値は`0`で、これは追加の待機時間がないことを意味します。 +- この変数は、TiDBがPDからTSOをリクエストする際のバッチ操作の最大待機時間を設定するために使用されます。デフォルト値は`0`で、これは追加の待機時間がないことを意味します。 - TiDBで使用されるPDクライアントは、PDからTSOリクエストを取得する際、同時に受信したTSOリクエストを可能な限り多く収集します。そして、収集したリクエストをバッチ処理で1つのRPCリクエストに統合し、PDに送信します。これにより、PDへの負荷を軽減できます。 - この変数を`0`より大きい値に設定した後、TiDBは各バッチマージの終了前に、この値の最大期間待機します。これは、より多くのTSOリクエストを収集し、バッチ操作の効果を向上させるためです。 - この変数の値を増加させるシナリオ： @@ -6724,7 +6724,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) -- この変数は、TiDB が TiKV に送信するトランザクションコミット要求のバッチサイズを制御するために使用されます。アプリケーションワークロード内のトランザクションの大部分に多数の書き込み操作が含まれている場合、この変数の値を大きくすることでバッチ処理のパフォーマンスを向上させることができます。ただし、この変数を大きすぎる値に設定して TiKV の[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)の制限を超えると、コミットが失敗する可能性があります。 +- この変数は、TiDB が TiKV に送信するトランザクションコミットリクエストのバッチサイズを制御するために使用されます。アプリケーションワークロード内のトランザクションの大部分に多数の書き込み操作が含まれている場合、この変数の値を大きくすることでバッチ処理のパフォーマンスを向上させることができます。ただし、この変数を大きすぎる値に設定して TiKV の[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)の制限を超えると、コミットが失敗する可能性があります。 diff --git a/ticdc/monitor-ticdc.md b/ticdc/monitor-ticdc.md index b7fce866ddd2a..0270ca06bbc55 100644 --- a/ticdc/monitor-ticdc.md +++ b/ticdc/monitor-ticdc.md @@ -31,45 +31,45 @@ cdc cli changefeed create --server=http://10.0.10.25:8300 --sink-uri="mysql://ro TiCDC の新しいアーキテクチャの監視ダッシュボードには、主に次のセクションが含まれます。 -- [**まとめ**](#summary) : TiCDCクラスターの概要情報 -- [**サーバ**](#server) : TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 +- [**Summary**](#summary) : TiCDCクラスターの概要情報 +- [**Server**](#server) : TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 - [**Log Puller**](#log-puller) : TiCDC Log Pullerモジュールの詳細情報 -- [**イベントストア**](#event-store) : TiCDCイベントストアモジュールの詳細情報 -- [**シンク**](#sink) : TiCDCシンクモジュールの詳細情報 +- [**Event Store**](#event-store) : TiCDCイベントストアモジュールの詳細情報 +- [**Sink**](#sink) : TiCDCシンクモジュールの詳細情報 -### まとめ {#summary} +### Summary {#summary} -以下は**概要**パネルの例です。 +以下は**Summary**パネルの例です。 ![Summary](/media/ticdc/ticdc-new-arch-metric-summary.png) -**概要**パネルの各メトリックの説明は次のとおりです。 +**Summary**パネルの各メトリックの説明は次のとおりです。 -- チェンジフィードチェックポイントラグ: 下流と上流の間のレプリケーションタスクのラグ +- Changefeed Checkpoint Lag: 下流と上流の間のレプリケーションタスクのラグ - Changefeed ResolvedTs Lag: TiCDCノードの内部処理の進行と上流データベース間の遅延 -- アップストリーム書き込みバイト/秒:アップストリームデータベースの書き込みスループット -- TiCDC入力バイト/秒: TiCDCがアップストリームから1秒あたりに受信するデータ量 -- シンクイベント行数/秒: TiCDCが1秒あたりにダウンストリームに書き込む行数 -- シンク書き込みバイト/秒: TiCDCが1秒あたりにダウンストリームに書き込むデータの量 -- チェンジフィードのステータス: 各チェンジフィードのステータス -- テーブルディスパッチャ数: 各チェンジフィードに対応するディスパッチャの数 -- メモリクォータ: イベントコレクタのメモリクォータと使用量。使用量が多すぎるとスロットリングが発生する可能性があります。 +- Upstream Write Bytes/s:アップストリームデータベースの書き込みスループット +- TiCDC Input Bytes/s: TiCDCがアップストリームから1秒あたりに受信するデータ量 +- Sink Event Row Count/s: TiCDCが1秒あたりにダウンストリームに書き込む行数 +- Sink Write Bytes/s: TiCDCが1秒あたりにダウンストリームに書き込むデータの量 +- The Status of Changefeeds: 各チェンジフィードのステータス +- Table Dispatcher Count: 各チェンジフィードに対応するディスパッチャの数 +- Memory Quota: イベントコレクタのメモリクォータと使用量。使用量が多すぎるとスロットリングが発生する可能性があります。 -### サーバ {#server} +### Server {#server} -以下は**サーバー**パネルの例です。 +以下は**Server**パネルの例です。 ![Server](/media/ticdc/ticdc-new-arch-metric-server.png) -**サーバー**パネルの各メトリックの説明は次のとおりです。 +**Server**パネルの各メトリックの説明は次のとおりです。 -- 稼働時間: TiKVノードとTiCDCノードが稼働している時間 -- Goroutine 数: TiCDC ノード上の Goroutine の数 -- オープンFD数: TiCDCノードによって開かれたファイルハンドルの数 -- CPU使用率: TiCDCノードのCPU使用率 -- メモリ使用量: TiCDCノードのメモリ使用量 -- 所有権履歴: TiCDC クラスター内の所有者ノードの履歴記録 -- PD Leader履歴:上流TiDBクラスタ内のPD Leaderノードの履歴記録 +- Uptime: TiKVノードとTiCDCノードが稼働している時間 +- Goroutine Count: TiCDC ノード上の Goroutine の数 +- Open FD Count: TiCDCノードによって開かれたファイルハンドルの数 +- CPU Usage: TiCDCノードのCPU使用率 +- Memory Usage: TiCDCノードのメモリ使用量 +- Ownership History: TiCDC クラスター内の所有者ノードの履歴記録 +- PD Leader History:上流TiDBクラスタ内のPD Leaderノードの履歴記録 ### Log Puller {#log-puller} @@ -79,51 +79,51 @@ TiCDC の新しいアーキテクチャの監視ダッシュボードには、 **Log Puller**パネルの各メトリックの説明は次のとおりです。 -- 入力イベント数/秒: TiCDCが1秒あたりに受信するイベント数 -- 未解決のリージョン要求数: TiCDC が送信したがまだ完了していないリージョン増分スキャン要求の数 -- リージョン要求終了スキャン所要時間:リージョン増分スキャンにかかる時間 -- 登録済みリージョン数: 登録済みリージョンの総数 -- メモリクォータ: Log Puller のメモリクォータと使用量。過剰な使用はスロットリングを引き起こす可能性があります。 -- 解決済みTsバッチサイズ（リージョン）: 1つの解決済みTsイベントに含まれるリージョンの数 +- Input Events/s: TiCDCが1秒あたりに受信するイベント数 +- Unresolved Region Request Count: TiCDC が送信したがまだ完了していないリージョン増分スキャンリクエストの数 +- Region Request Finish Scan Duration:リージョン増分スキャンにかかる時間 +- Subscribed Region Count: 登録済みリージョンの総数 +- Memory Quota: Log Puller のメモリクォータと使用量。過剰な使用はスロットリングを引き起こす可能性があります。 +- Resolved Ts Batch Size (Regions): 1つの解決済みTsイベントに含まれるリージョンの数 -### イベントストア {#event-store} +### Event Store {#event-store} -以下は、**イベントストア**パネルの例です。 +以下は、**Event Store**パネルの例です。 ![Event Store](/media/ticdc/ticdc-new-arch-metric-event-store.png) -**イベントストア**パネルの各メトリックの説明は次のとおりです。 - -- 解決されたTsラグ: イベントストアの処理の進行と上流データベース間のラグ -- レジスタディスパッチャStartTsラグ:ディスパッチャ登録StartTsと現在の時刻のラグ -- サブスクリプション解決Tsラグ: サブスクリプション処理の進行と上流データベース間のラグ -- サブスクリプションデータGCラグ: サブスクリプションデータGCの進行状況と現在の時刻の間のラグ -- 入力イベント数/秒: イベントストアが1秒あたりに処理するイベントの数 -- 入力バイト/秒: イベントストアが1秒あたりに処理するデータ量 -- 書き込みリクエスト数/秒: イベントストアが1秒あたりに実行する書き込みリクエストの数 -- 書き込みワーカービジー率: イベントストア書き込みスレッドの合計実行時間に対するI/O時間の比率 -- 圧縮行数/秒: イベントストアで 1秒あたりに圧縮された行数 (行サイズがしきい値を超えた場合にのみトリガーされます) -- 書き込み時間: イベントストアの書き込み操作にかかる時間 -- 書き込みバッチサイズ: 1回の書き込み操作のバッチサイズ -- 書き込みバッチイベント数: 1回の書き込みバッチに含まれる行変更イベントの数 -- ディスク上のデータサイズ: イベントストアがディスク上で占める合計データサイズ -- メモリ内のデータサイズ: イベントストアがメモリ内で占める合計データサイズ -- スキャン要求数/秒: イベントストアが1秒あたりに実行するスキャン要求の数 -- スキャンバイト数/秒: イベントストアが1秒あたりにスキャンするデータの量 - -### シンク {#sink} - -以下は**シンク**パネルの例です。 +**Event Store**パネルの各メトリックの説明は次のとおりです。 + +- Resolved Ts Lag: イベントストアの処理の進行と上流データベース間のラグ +- Register Dispatcher StartTs Lag:ディスパッチャ登録StartTsと現在の時刻のラグ +- Subscriptions Resolved Ts Lag: サブスクリプション処理の進行と上流データベース間のラグ +- Subscriptions Data GC Lag: サブスクリプションデータGCの進行状況と現在の時刻の間のラグ +- Input Event Count/s: イベントストアが1秒あたりに処理するイベントの数 +- Input Bytes/s: イベントストアが1秒あたりに処理するデータ量 +- Write Requests/s: イベントストアが1秒あたりに実行する書き込みリクエストの数 +- Write Worker Busy Ratio: イベントストア書き込みスレッドの合計実行時間に対するI/O時間の比率 +- Compressed Rows/s: イベントストアで 1秒あたりに圧縮された行数 (行サイズがしきい値を超えた場合にのみトリガーされます) +- Write Duration: イベントストアの書き込み操作にかかる時間 +- Write Batch Size: 1回の書き込み操作のバッチサイズ +- Write Batch Event Count: 1回の書き込みバッチに含まれる行変更イベントの数 +- Data Size On Disk: イベントストアがディスク上で占める合計データサイズ +- Data Size In Memory: イベントストアがメモリ内で占める合計データサイズ +- Scan Requests/s: イベントストアが1秒あたりに実行するスキャンリクエストの数 +- Scan Bytes/s: イベントストアが1秒あたりにスキャンするデータの量 + +### Sink {#sink} + +以下は**Sink**パネルの例です。 ![Sink](/media/ticdc/ticdc-new-arch-metric-sink.png) -**シンク**パネルの各メトリックの説明は次のとおりです。 +**Sink**パネルの各メトリックの説明は次のとおりです。 -- 出力行バッチ数: シンクモジュールによって書き込まれたDMLバッチあたりの平均行数 -- 出力行数（1秒あたり）: 1秒あたりに下流に書き込まれるDML行数 -- 出力DDL実行時間: 現在のノードの変更フィードのDDLイベントの実行に費やされた時間 -- シンクエラー数 / 分: シンクモジュールによって1分あたりに報告されたエラーの数 -- 出力DDL数/分: 現在のノードの変更フィードに対して1分あたりに実行されたDDLの数 +- Output Row Batch Count: シンクモジュールによって書き込まれたDMLバッチあたりの平均行数 +- Output Row Count (per second): 1秒あたりに下流に書き込まれるDML行数 +- Output DDL Executing Duration: 現在のノードの変更フィードのDDLイベントの実行に費やされた時間 +- Sink Error Count / m: シンクモジュールによって1分あたりに報告されたエラーの数 +- Output DDL Count / Minutes: 現在のノードの変更フィードに対して1分あたりに実行されたDDLの数 ## クラシックアーキテクチャにおける TiCDC のメトリクス {#metrics-for-ticdc-in-the-classic-architecture} @@ -131,86 +131,86 @@ TiUPを使用して TiDB クラスターをデプロイすると、TiDB と同 各パネルの説明は次のとおりです。 -- [**サーバ**](#server) : TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 -- [**チェンジフィード**](#changefeed) : TiCDCレプリケーションタスクの詳細情報 -- [**イベント**](#events) : TiCDCクラスタ内のデータフローに関する詳細情報 +- [**Server**](#server) : TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 +- [**Changefeed**](#changefeed) : TiCDCレプリケーションタスクの詳細情報 +- [**Events**](#events) : TiCDCクラスタ内のデータフローに関する詳細情報 - [**TiKV**](#tikv) : TiCDCに関連するTiKV情報 -### サーバ {#server} +### Server {#server} -以下は**サーバー**パネルの例です。 +以下は**Server**パネルの例です。 ![TiCDC Dashboard - Server metrics](/media/ticdc/ticdc-dashboard-server.png) -**サーバー**パネルの各メトリックの説明は次のとおりです。 +**Server**パネルの各メトリックの説明は次のとおりです。 -- 稼働時間: TiKVノードとTiCDCノードが稼働している時間 -- ゴルーチン数: TiCDCノードのゴルーチンの数 -- オープンFD数: TiCDCノードによって開かれたファイルハンドルの数 -- 所有権: TiCDC クラスター内のノードの現在のステータス -- 所有権の履歴: TiCDCクラスターの所有権の履歴 -- CPU使用率: TiCDCノードのCPU使用率 -- メモリ使用量: TiCDCノードのメモリ使用量 +- Uptime: TiKVノードとTiCDCノードが稼働している時間 +- Goroutine count: TiCDCノードのゴルーチンの数 +- Open FD count: TiCDCノードによって開かれたファイルハンドルの数 +- Ownership: TiCDC クラスター内のノードの現在のステータス +- Ownership history: TiCDCクラスターの所有権の履歴 +- CPU usage: TiCDCノードのCPU使用率 +- Memory usage: TiCDCノードのメモリ使用量 -### チェンジフィード {#changefeed} +### Changefeed {#changefeed} 以下は**Changefeed**パネルの例です。 ![TiCDC Dashboard - Changefeed metrics 1](/media/ticdc/ticdc-dashboard-changefeed-1.png) -- チェンジフィードテーブル数: 各 TiCDC ノードがレプリケーションタスクで複製する必要があるテーブルの数 -- プロセッサ解決ts: TiCDCクラスタで解決されたタイムスタンプ -- テーブル解決ts: レプリケーションタスク内の各テーブルのレプリケーションの進行状況 -- チェンジフィードチェックポイント：下流へのデータ複製の進行状況。通常、緑色のバーは黄色の線とつながっています。 -- PD etcdリクエスト数/秒: TiCDCノードがPDに送信するリクエスト数（1秒あたり） -- 終了エラー数/分: 1分あたりにレプリケーションタスクを中断するエラーの数 -- チェンジフィードチェックポイントラグ:上流と下流間のデータ複製の進行ラグ(単位は秒) -- プロセッサ解決tsラグ:上流ノードとTiCDCノード間のデータ複製の進行ラグ（単位は秒） +- Changefeed table count: 各 TiCDC ノードがレプリケーションタスクで複製する必要があるテーブルの数 +- Processor resolved ts: TiCDCクラスタで解決されたタイムスタンプ +- Table resolved ts: レプリケーションタスク内の各テーブルのレプリケーションの進行状況 +- Changefeed checkpoint：下流へのデータ複製の進行状況。通常、緑色のバーは黄色の線とつながっています。 +- PD etcd requests/s: TiCDCノードがPDに送信するリクエスト数（1秒あたり） +- Exit error count/m: 1分あたりにレプリケーションタスクを中断するエラーの数 +- Changefeed checkpoint lag:上流と下流間のデータ複製の進行ラグ(単位は秒) +- Processor resolved ts lag:上流ノードとTiCDCノード間のデータ複製の進行ラグ（単位は秒） ![TiCDC Dashboard - Changefeed metrics 2](/media/ticdc/ticdc-dashboard-changefeed-2.png) -- シンク書き込み時間: TiCDCがトランザクションの変更をダウンストリームに書き込むのに費やした時間のヒストグラム -- シンク書き込み期間パーセンタイル: TiCDC が 1秒以内にトランザクションの変更をダウンストリームに書き込むのに費やした時間 (P95、P99、および P999) -- フラッシュシンク期間: TiCDC が非同期的にデータを下流にフラッシュするのにかかった時間のヒストグラム -- フラッシュシンク期間パーセンタイル: TiCDC が 1秒以内にデータを非同期にダウンストリームにフラッシュするのにかかる時間 (P95、P99、および P999) +- Sink write duration: TiCDCがトランザクションの変更をダウンストリームに書き込むのに費やした時間のヒストグラム +- Sink write duration percentile: TiCDC が 1秒以内にトランザクションの変更をダウンストリームに書き込むのに費やした時間 (P95、P99、および P999) +- Flush sink duration: TiCDC が非同期的にデータを下流にフラッシュするのにかかった時間のヒストグラム +- Flush sink duration percentile: TiCDC が 1秒以内にデータを非同期にダウンストリームにフラッシュするのにかかる時間 (P95、P99、および P999) ![TiCDC Dashboard - Changefeed metrics 3](/media/ticdc/ticdc-dashboard-changefeed-3.png) -- MySQLシンク競合検出期間: MySQLシンク競合の検出に費やされた時間のヒストグラム -- MySQLシンク競合検出期間パーセンタイル: 1秒以内にMySQLシンク競合を検出するのに費やされた時間(P95、P99、P999) -- MySQLシンクワーカーの負荷: TiCDCノードのMySQLシンクワーカーのワークロード +- MySQL sink conflict detect duration: MySQLシンク競合の検出に費やされた時間のヒストグラム +- MySQL sink conflict detect duration percentile: 1秒以内にMySQLシンク競合を検出するのに費やされた時間(P95、P99、P999) +- MySQL sink worker load: TiCDCノードのMySQLシンクワーカーのワークロード ![TiCDC Dashboard - Changefeed metrics 4](/media/ticdc/ticdc-dashboard-changefeed-4.png) -- Changefeed キャッチアップ ETA: レプリケーションタスクが上流のクラスタデータに追いつくのに必要な推定時間です。上流の書き込み速度が TiCDC のレプリケーション速度よりも速い場合、この指標は非常に大きくなる可能性があります。TiCDC のレプリケーション速度は多くの要因に左右されるため、この指標は参考値であり、実際のレプリケーション時間とは異なる可能性があります。 +- Changefeed catch-up ETA: レプリケーションタスクが上流のクラスタデータに追いつくのに必要な推定時間です。上流の書き込み速度が TiCDC のレプリケーション速度よりも速い場合、この指標は非常に大きくなる可能性があります。TiCDC のレプリケーション速度は多くの要因に左右されるため、この指標は参考値であり、実際のレプリケーション時間とは異なる可能性があります。 -### イベント {#events} +### Events {#events} -以下は**イベント**パネルの例です。 +以下は**Events**パネルの例です。 ![TiCDC Dashboard - Events metrics 2](/media/ticdc/ticdc-dashboard-events-1.png) ![TiCDC Dashboard - Events metrics 2](/media/ticdc/ticdc-dashboard-events-2.png) ![TiCDC Dashboard - Events metrics 2](/media/ticdc/ticdc-dashboard-events-3.png) -**イベント**パネルの各メトリックの説明は次のとおりです。 - -- イベントフィード数: TiCDCノードのイベントフィードRPCリクエストの数 -- イベントサイズのパーセンタイル: TiCDCがTiKVから1秒以内に受信するイベントサイズ（P95、P99、P999） -- イベントフィードエラー/分: TiCDCノードのイベントフィードRPCリクエストによって1分あたりに報告されたエラーの数 -- KVクライアント受信イベント数/秒: TiCDCノードのKVクライアントモジュールがTiKVから1秒あたりに受信するイベント数 -- プラー受信イベント数/秒: TiCDCノードのプラーモジュールがKVクライアントから1秒あたりに受信するイベント数 -- プラー出力イベント数/秒: TiCDCノードのプラーモジュールがソーターモジュールに送信するイベント数/秒 -- シンクフラッシュ行数/秒: TiCDCノードが1秒あたりにダウンストリームに書き込むイベント数 -- プラーバッファサイズ: TiCDCノードがプラーモジュールにキャッシュするイベントの数 -- エントリソーターバッファサイズ: TiCDCノードがソーターモジュールにキャッシュするイベントの数 -- プロセッサ/マウントバッファサイズ: TiCDCノードがプロセッサモジュールとマウントモジュールにキャッシュするイベントの数 -- シンク行バッファサイズ: TiCDCノードがシンクモジュールにキャッシュするイベントの数 -- エントリソーターのソート期間: TiCDCノードがイベントをソートするのにかかった時間のヒストグラム -- エントリーソーターのソート所要時間パーセンタイル: TiCDCのソートイベントが1秒間に要した時間(P95、P99、P999) -- エントリソーターのマージ期間: TiCDCノードがソートされたイベントをマージするのにかかった時間のヒストグラム -- エントリソーターのマージ所要時間パーセンタイル: TiCDCがソートされたイベントを1秒以内にマージするのにかかる時間(P95、P99、P999) -- マウンターのアンマーシャリング期間: TiCDCノードがイベントをアンマーシャリングするのにかかった時間のヒストグラム -- マウンターのアンマーシャリング期間のパーセンタイル: TiCDC アンマーシャリング イベントが 1秒間に要した時間 (P95、P99、および P999) -- KVクライアントディスパッチイベント数/秒: KVクライアントモジュールがTiCDCノード間でディスパッチするイベント数 -- KVクライアントのバッチ解決サイズ: TiKVがTiCDCに送信する解決済みタイムスタンプメッセージのバッチサイズ +**Events**パネルの各メトリックの説明は次のとおりです。 + +- Eventfeed count: TiCDCノードのイベントフィードRPCリクエストの数 +- Event size percentile: TiCDCがTiKVから1秒以内に受信するイベントサイズ（P95、P99、P999） +- Eventfeed error/m: TiCDCノードのイベントフィードRPCリクエストによって1分あたりに報告されたエラーの数 +- KV client receive events/s: TiCDCノードのKVクライアントモジュールがTiKVから1秒あたりに受信するイベント数 +- Puller receive events/s: TiCDCノードのプラーモジュールがKVクライアントから1秒あたりに受信するイベント数 +- Puller output events/s: TiCDCノードのプラーモジュールがソーターモジュールに送信するイベント数/秒 +- Sink flush rows/s: TiCDCノードが1秒あたりにダウンストリームに書き込むイベント数 +- Puller buffer size: TiCDCノードがプラーモジュールにキャッシュするイベントの数 +- Entry sorter buffer size: TiCDCノードがソーターモジュールにキャッシュするイベントの数 +- Processor/Mounter buffer size: TiCDCノードがプロセッサモジュールとマウントモジュールにキャッシュするイベントの数 +- Sink row buffer size: TiCDCノードがシンクモジュールにキャッシュするイベントの数 +- Entry sorter sort duration: TiCDCノードがイベントをソートするのにかかった時間のヒストグラム +- Entry sorter sort duration percentile: TiCDCのソートイベントが1秒間に要した時間(P95、P99、P999) +- Entry sorter merge duration: TiCDCノードがソートされたイベントをマージするのにかかった時間のヒストグラム +- Entry sorter merge duration percentile: TiCDCがソートされたイベントを1秒以内にマージするのにかかる時間(P95、P99、P999) +- Mounter unmarshal duration: TiCDCノードがイベントをアンマーシャリングするのにかかった時間のヒストグラム +- Mounter unmarshal duration percentile: TiCDC アンマーシャリング イベントが 1秒間に要した時間 (P95、P99、および P999) +- KV client dispatch events/s: KVクライアントモジュールがTiCDCノード間でディスパッチするイベント数 +- KV client batch resolved size: TiKVがTiCDCに送信する解決済みタイムスタンプメッセージのバッチサイズ ### TiKV {#tikv} @@ -220,13 +220,13 @@ TiUPを使用して TiDB クラスターをデプロイすると、TiDB と同 **TiKV**パネルの各メトリックの説明は次のとおりです。 -- CDCエンドポイントCPU: TiKVノード上のCDCエンドポイントスレッドのCPU使用率 -- CDCワーカーCPU: TiKVノード上のCDCワーカースレッドのCPU使用率 +- CDC endpoint CPU: TiKVノード上のCDCエンドポイントスレッドのCPU使用率 +- CDC worker CPU: TiKVノード上のCDCワーカースレッドのCPU使用率 - Min resolved ts: TiKVノード上の最小解決タイムスタンプ - Min resolved region: TiKVノード上の最小解決タイムスタンプのリージョンID - Resolved ts lag duration percentile: TiKVノード上の最小解決タイムスタンプと現在の時刻の間のラグ -- 初期スキャン期間: TiKVノードがTiCDCノードに接続する際の増分スキャンに費やされた時間のヒストグラム -- 初期スキャン所要時間パーセンタイル: 1秒以内にTiKVノードの増分スキャンに費やされた時間(P95、P99、P999) -- ブロックキャッシュなしのメモリ: RocksDBブロックキャッシュを除いたTiKVノードのメモリ使用量 -- メモリ内のCDC保留バイト数: TiKVノード上のCDCモジュールのメモリ使用量 -- キャプチャされたリージョンの数: TiKVノード上のイベントキャプチャリージョンの数 +- Initial scan duration: TiKVノードがTiCDCノードに接続する際の増分スキャンに費やされた時間のヒストグラム +- Initial scan duration percentile: 1秒以内にTiKVノードの増分スキャンに費やされた時間(P95、P99、P999) +- Memory without block cache: RocksDBブロックキャッシュを除いたTiKVノードのメモリ使用量 +- CDC pending bytes in memory: TiKVノード上のCDCモジュールのメモリ使用量 +- Captured region count: TiKVノード上のイベントキャプチャリージョンの数 diff --git a/ticdc/ticdc-architecture.md b/ticdc/ticdc-architecture.md index ee829832d1479..11a8190355fb3 100644 --- a/ticdc/ticdc-architecture.md +++ b/ticdc/ticdc-architecture.md @@ -20,7 +20,7 @@ summary: TiCDCの新しいアーキテクチャの機能、アーキテクチャ TiCDCの新しいアーキテクチャは、ログサービスとダウンストリームアダプタという2つの主要コンポーネントで構成されています。 -- ログサービス：コアデータサービスレイヤーとして、ログサービスはアップストリームのTiDBクラスタから行の変更やDDLイベントなどの情報を取得し、変更データをローカルディスクに一時的に保存します。また、ダウンストリームアダプタからのデータ要求にも応答し、DMLデータとDDLデータを定期的にマージおよびソートして、ソート済みのデータをダウンストリームアダプタに送信します。 +- ログサービス：コアデータサービスレイヤーとして、ログサービスはアップストリームのTiDBクラスタから行の変更やDDLイベントなどの情報を取得し、変更データをローカルディスクに一時的に保存します。また、ダウンストリームアダプタからのデータリクエストにも応答し、DMLデータとDDLデータを定期的にマージおよびソートして、ソート済みのデータをダウンストリームアダプタに送信します。 - ダウンストリームアダプタ：ダウンストリームデータレプリケーション適応レイヤーとして、ダウンストリームアダプタはユーザーが開始する変更フィード操作を処理します。関連するレプリケーションタスクをスケジュールおよび生成し、ログサービスからデータを取得し、取得したデータをダウンストリームシステムにレプリケートします。 TiCDCの新しいアーキテクチャは、アーキテクチャをステートフルコンポーネントとステートレスコンポーネントに分離することで、システムの拡張性、信頼性、柔軟性を大幅に向上させています。ステートフルコンポーネントであるログサービスは、データの取得、ソート、およびストレージに重点を置いています。これを変更フィード処理ロジックから分離することで、複数の変更フィード間でデータを共有できるようになり、リソース利用率を効果的に向上させ、システムオーバーヘッドを削減できます。ステートレスコンポーネントであるダウンストリームアダプタは、インスタンス間でレプリケーションタスクを迅速に移行できる軽量スケジューリングメカニズムを使用しています。ワークロードの変化に基づいてレプリケーションタスクの分割とマージを動的に調整できるため、さまざまなシナリオで低遅延のレプリケーションが保証されます。 diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 6fd04b9ff183a..70d5bf6756bf5 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -13,7 +13,7 @@ summary: TiCDC を使用する際に遭遇する可能性のある FAQ につい ## TiCDC でタスクを作成するときに`start-ts`を選択するにはどうすればよいですか? {#how-do-i-choose-start-ts-when-creating-a-task-in-ticdc} -レプリケーションタスクの`start-ts`は、上流TiDBクラスタ内のタイムスタンプOracle（TSO）に対応します。TiCDCは、レプリケーションタスクでこのTSOにデータを要求します。したがって、レプリケーションタスクの`start-ts` 、以下の要件を満たす必要があります。 +レプリケーションタスクの`start-ts`は、上流TiDBクラスタ内のタイムスタンプOracle（TSO）に対応します。TiCDCは、レプリケーションタスクでこのTSOにデータをリクエストします。したがって、レプリケーションタスクの`start-ts` 、以下の要件を満たす必要があります。 - `start-ts`という値は、現在の TiDB クラスターの`tikv_gc_safe_point`という値よりも大きいです。それ以外の場合、タスクの作成時にエラーが発生します。 - タスクを開始する前に、ダウンストリームにすべてのデータが`start-ts`あることを確認してください。メッセージキューにデータを複製するなどのシナリオでは、アップストリームとダウンストリーム間のデータの整合性が要求されない場合は、アプリケーションのニーズに応じてこの要件を緩和できます。 diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 84f74cc8a6a9d..0bf6d2ab23049 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -68,7 +68,7 @@ TiCDCのアーキテクチャを次の図に示します。 アーキテクチャ図における各構成要素は、以下のように説明されます。 -- TiKVサーバー：TiDBクラスタ内のTiKVノード。データに変更が発生すると、TiKVノードは変更ログ（KV変更ログ）として変更内容をTiCDCノードに送信します。TiCDCノードは、変更ログが連続していないことを検出した場合、TiKVノードに変更ログの提供を積極的に要求します。 +- TiKVサーバー：TiDBクラスタ内のTiKVノード。データに変更が発生すると、TiKVノードは変更ログ（KV変更ログ）として変更内容をTiCDCノードに送信します。TiCDCノードは、変更ログが連続していないことを検出した場合、TiKVノードに変更ログの提供を積極的にリクエストします。 - TiCDC: TiCDCプロセスが実行されるTiCDCノード。各ノードではTiCDCプロセスが実行されます。各プロセスは、TiKVノード内の1つ以上のテーブルからデータ変更を取得し、シンクコンポーネントを介して下流システムにその変更を複製します。 - PD：TiDBクラスタのスケジューリングモジュール。このモジュールはクラスタデータのスケジューリングを担当し、通常は3つのPDノードで構成されます。PDはetcdクラスタを介して高可用性を提供します。etcdクラスタでは、TiCDCはノードの状態情報や変更フィードの設定などのメタデータを保存します。 diff --git a/ticdc/ticdc-server-config.md b/ticdc/ticdc-server-config.md index 330ff6256688c..07823e40ef4b1 100644 --- a/ticdc/ticdc-server-config.md +++ b/ticdc/ticdc-server-config.md @@ -102,7 +102,7 @@ summary: TiCDC で使用される CLI と設定パラメータについて学習 #### `client-allowed-user` {#client-allowed-user} -- クライアント認証に許可されるユーザー名をリストします。このリストにないユーザー名による認証要求は拒否されます。 +- クライアント認証に許可されるユーザー名をリストします。このリストにないユーザー名による認証リクエストは拒否されます。 - デフォルト値: `null` diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index d4e6dda709589..22fca46fad0a5 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -414,7 +414,7 @@ large-message-handle-compression = "none" - `large-message-handle-compression`で指定された圧縮アルゴリズムは、単一のKafkaメッセージを圧縮します。圧縮は、メッセージサイズの制限と比較する前に実行されます。 - 同時に、 [`sink-uri`](#configure-sink-uri-for-kafka)の`compression`パラメータを使用して圧縮アルゴリズムを設定することもできます。この圧縮アルゴリズムは、複数のKafkaメッセージを含むデータ送信リクエスト全体に適用されます。 -`large-message-handle-compression`を設定した場合、TiCDC はメッセージを受信すると、まずメッセージサイズ制限パラメータの値と比較し、サイズ制限を超えるメッセージを圧縮します。[`sink-uri`](#configure-sink-uri-for-kafka)に`compression`も設定した場合、TiCDC は`sink-uri`設定に基づいて、送信データ要求全体をシンクレベルで再度圧縮します。 +`large-message-handle-compression`を設定した場合、TiCDC はメッセージを受信すると、まずメッセージサイズ制限パラメータの値と比較し、サイズ制限を超えるメッセージを圧縮します。[`sink-uri`](#configure-sink-uri-for-kafka)に`compression`も設定した場合、TiCDC は`sink-uri`設定に基づいて、送信データリクエスト全体をシンクレベルで再度圧縮します。 前述の2つの圧縮方法の圧縮率は次のように計算されます`compression ratio = size before compression / size after compression * 100` 。 diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index 36e6c7fcf2e2d..9f7360563b39e 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -7,7 +7,7 @@ summary: TiCDC が UPDATE` イベントを分割するかどうかに関する ## MySQLシンクの`UPDATE`イベントを分割する {#split-update-events-for-mysql-sinks} -v6.5.10、v7.1.6、v7.5.2、v8.1.1、v8.2.0以降では、MySQLシンクを使用する場合、テーブルのレプリケーション要求を受信したTiCDCノードは、下流へのレプリケーションを開始する前に、PDから現在のタイムスタンプ`thresholdTS`を取得します。このタイムスタンプの値に基づいて、TiCDCは`UPDATE`イベントを分割するかどうかを決定します。 +v6.5.10、v7.1.6、v7.5.2、v8.1.1、v8.2.0以降では、MySQLシンクを使用する場合、テーブルのレプリケーションリクエストを受信したTiCDCノードは、下流へのレプリケーションを開始する前に、PDから現在のタイムスタンプ`thresholdTS`を取得します。このタイムスタンプの値に基づいて、TiCDCは`UPDATE`イベントを分割するかどうかを決定します。 - 1 つまたは複数の`UPDATE`変更を含むトランザクションの場合、トランザクション`commitTS` `thresholdTS`未満であれば、TiCDC は`UPDATE`イベントを`DELETE`イベントと`INSERT`イベントに分割してから、それらを Sorter モジュールに書き込みます。 - トランザクション`commitTS`が`thresholdTS`以上である`UPDATE`イベントの場合、TiCDC はそれらを分割しません。詳細については、GitHub の問題[#10918](https://github.com/pingcap/tiflow/issues/10918)を参照してください。 diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index e83f715054662..b510949a02668 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -171,7 +171,7 @@ TiDB Cloud APIは、RESTベースのインターフェースであり、 TiDB Cl [TiDBノード](/tidb-computing.md)MySQL互換エンドポイントを使用してアプリケーションに接続するステートレスなSQLレイヤーです。SQLクエリの解析、最適化、分散実行計画の作成などのタスクを処理します。 -TiDBノードを複数デプロイすることで、水平方向に拡張し、より高いワークロードに対応できます。これらのノードは、TiProxyやHAProxyなどのロードバランサーと連携して、シームレスなインターフェースを提供します。TiDBノード自体はデータを保存せず、データ要求を行ベースストレージの場合はTiKVノードに、列指向ストレージの場合はTiFlashノードに転送します。 +TiDBノードを複数デプロイすることで、水平方向に拡張し、より高いワークロードに対応できます。これらのノードは、TiProxyやHAProxyなどのロードバランサーと連携して、シームレスなインターフェースを提供します。TiDBノード自体はデータを保存せず、データリクエストを行ベースストレージの場合はTiKVノードに、列指向ストレージの場合はTiFlashノードに転送します。 ### TiKVノード {#tikv-node} diff --git a/tidb-cloud/changefeed-sink-to-apache-kafka.md b/tidb-cloud/changefeed-sink-to-apache-kafka.md index df7ee30c8dac4..98c4c2974fe3c 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -217,8 +217,8 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン 7. Kafkaで**TLS Encryption**オプションを有効にしてください。 8. **Next**をクリックしてネットワーク接続をテストしてください。テストが成功すると、次のページに移動します。 9. TiDB Cloudは**Private Service Connect**用のエンドポイントを作成しますが、これには数分かかる場合があります。 -10. エンドポイントが作成されたら、クラウドプロバイダーのコンソールにログインし、接続要求を承認してください。 -11. [TiDB Cloudコンソール](https://tidbcloud.com)に戻る 接続要求を承認したことを確認してください。TiDB Cloudは接続テストを実行し、テストが成功した場合は次のページに進みます。 +10. エンドポイントが作成されたら、クラウドプロバイダーのコンソールにログインし、接続リクエストを承認してください。 +11. [TiDB Cloudコンソール](https://tidbcloud.com)に戻る 接続リクエストを承認したことを確認してください。TiDB Cloudは接続テストを実行し、テストが成功した場合は次のページに進みます。 @@ -238,8 +238,8 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン 7. Kafkaで**TLS Encryption**オプションを有効にしてください。 8. **Next**をクリックしてネットワーク接続をテストしてください。テストが成功すると、次のページに移動します。 9. TiDB Cloudは**Private Link**のエンドポイントを作成しますが、これには数分かかる場合があります。 -10. エンドポイントが作成されたら、 [Azureポータル](https://portal.azure.com/)にログインして接続要求を承認してください。 -11. [TiDB Cloudコンソール](https://tidbcloud.com)に戻る 接続要求を承認したことを確認してください。TiDB Cloudは接続テストを実行し、テストが成功した場合は次のページに進みます。 +10. エンドポイントが作成されたら、 [Azureポータル](https://portal.azure.com/)にログインして接続リクエストを承認してください。 +11. [TiDB Cloudコンソール](https://tidbcloud.com)に戻る 接続リクエストを承認したことを確認してください。TiDB Cloudは接続テストを実行し、テストが成功した場合は次のページに進みます。 diff --git a/tidb-cloud/changefeed-sink-to-apache-pulsar.md b/tidb-cloud/changefeed-sink-to-apache-pulsar.md index 0adb623c6ac05..364140d49b830 100644 --- a/tidb-cloud/changefeed-sink-to-apache-pulsar.md +++ b/tidb-cloud/changefeed-sink-to-apache-pulsar.md @@ -97,7 +97,7 @@ Apache PulsarサービスにパブリックIPアクセスを提供する場合 - **Connectivity Method**：Pulsarエンドポイントへの接続方法に応じて、 **VPC Peering**または**Public**を選択してください。 - **Pulsar Broker** : Pulsar Broker のエンドポイントを入力します。ポートとドメインまたは IP アドレスはコロンで区切ります。例`example.org:6650` 。 -3. **Authentication**セクションで、Pulsarの認証設定に応じて**Auth Type**オプションを選択します。選択したオプションに基づいて、要求された認証情報を入力します。 +3. **Authentication**セクションで、Pulsarの認証設定に応じて**Auth Type**オプションを選択します。選択したオプションに基づいて、リクエストされた認証情報を入力します。 4. オプション：**Advanced Settings**セクションで、追加設定を構成します。 diff --git a/tidb-cloud/data-service-api-key.md b/tidb-cloud/data-service-api-key.md index 0c8baf8d571f6..6ca861128567a 100644 --- a/tidb-cloud/data-service-api-key.md +++ b/tidb-cloud/data-service-api-key.md @@ -8,7 +8,7 @@ summary: データアプリのAPIキーの作成、編集、削除方法を学 TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access_authentication)と[ダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)の両方をサポートしています。 - [基本認証](https://en.wikipedia.org/wiki/Basic_access_authentication)は、暗号化されていない Base64 エンコーディングを使用して、公開キーと秘密キーを送信します。 HTTPS により通信のセキュリティが確保されます。詳細については、 [RFC 7617 - 'Basic'HTTP認証方式](https://datatracker.ietf.org/doc/html/rfc7617)を参照してください。 -- [ダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)ネットワーク送信前に公開キー、秘密キー、サーバー提供のノンス値、HTTP メソッド、および要求された URI をハッシュすることにより、追加のセキュリティレイヤーを提供します。これにより、秘密キーが暗号化され、秘密キーが平文で送信されるのを防ぎます。詳細については、 [RFC 7616 - HTTPダイジェストアクセス認証](https://datatracker.ietf.org/doc/html/rfc7616)を参照してください。 +- [ダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)ネットワーク送信前に公開キー、秘密キー、サーバー提供のノンス値、HTTP メソッド、およびリクエストされた URI をハッシュすることにより、追加のセキュリティレイヤーを提供します。これにより、秘密キーが暗号化され、秘密キーが平文で送信されるのを防ぎます。詳細については、 [RFC 7616 - HTTPダイジェストアクセス認証](https://datatracker.ietf.org/doc/html/rfc7616)を参照してください。 > **Note:** > diff --git a/tidb-cloud/import-csv-files.md b/tidb-cloud/import-csv-files.md index 267caa1ca18f4..2d2fc4627ecee 100644 --- a/tidb-cloud/import-csv-files.md +++ b/tidb-cloud/import-csv-files.md @@ -238,13 +238,13 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に 4. **Next**をクリックしてください。 - 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 + 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイントリクエストを承認する必要があります。 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 2. **Networking** > **Private endpoint connections**をクリックします。 - 3. TiDB Cloudからの保留中の接続要求を見つけて、 **Approve**をクリックします。 + 3. TiDB Cloudからの保留中の接続リクエストを見つけて、 **Approve**をクリックします。 4. [TiDB Cloudコンソール](https://tidbcloud.com/)に戻ります。エンドポイントが承認されると、インポート ウィザードが自動的に続行されます。 diff --git a/tidb-cloud/import-parquet-files.md b/tidb-cloud/import-parquet-files.md index dc057fc9cf4fe..589e7e0bf5693 100644 --- a/tidb-cloud/import-parquet-files.md +++ b/tidb-cloud/import-parquet-files.md @@ -239,13 +239,13 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 4. **Next**をクリックしてください。 - 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 + 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイントリクエストを承認する必要があります。 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 2. **Networking** > **Private endpoint connections**をクリックします。 - 3. TiDB Cloudからの保留中の接続要求を見つけて、 **Approve**をクリックします。 + 3. TiDB Cloudからの保留中の接続リクエストを見つけて、 **Approve**をクリックします。 4. [TiDB Cloudコンソール](https://tidbcloud.com/)に戻ります。エンドポイントが承認されると、インポート ウィザードが自動的に続行されます。 diff --git a/tidb-cloud/import-sample-data.md b/tidb-cloud/import-sample-data.md index f5124b5b6b28c..f4210283d6b40 100644 --- a/tidb-cloud/import-sample-data.md +++ b/tidb-cloud/import-sample-data.md @@ -108,13 +108,13 @@ summary: TiDB Cloud DedicatedにUI経由でサンプルデータをインポー 4. **Next**をクリックしてください。 - 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。接続を開始するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 + 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。接続を開始するには、Azureポータルでこのエンドポイントリクエストを承認する必要があります。 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 2. **Networking** > **Private endpoint connections**をクリックします。 - 3. TiDB Cloudからの保留中の接続要求を見つけて、 **Approve**をクリックします。 + 3. TiDB Cloudからの保留中の接続リクエストを見つけて、 **Approve**をクリックします。 4. [TiDB Cloudコンソール](https://tidbcloud.com/)に戻ります。エンドポイントが承認されると、インポート ウィザードが自動的に続行されます。 diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md index 1d439520eab00..52085919fff8b 100644 --- a/tidb-cloud/migrate-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md @@ -432,7 +432,7 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ mysql -h -P 3306 -u -p --ssl-ca= -e "SELECT version();" ``` -5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。 +5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続リクエストを承認する必要があります。 @@ -458,7 +458,7 @@ Azure Database for MySQL - Flexible Server は、ネイティブのプライベ 4. [Azureポータル](https://portal.azure.com/)の で、MySQL Flexible Server インスタンスの概要ページ (プライベートエンドポイント オブジェクトではありません) に戻り、 **[Essentials]**セクションで**[JSON ビュー]**をクリックして、後で使用するためにリソース ID をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.DBforMySQL/flexibleServers/`形式です。このリソース ID (プライベートエンドポイント ID ではありません) を使用して、 TiDB Cloud DM を構成します。 -5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように構成する際には、Azureポータルに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。 +5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように構成する際には、Azureポータルに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続リクエストを承認する必要があります。 @@ -517,7 +517,7 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ mysql -h -P 3306 -u -p --ssl-ca= -e "SELECT version();" ``` -5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。 +5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続リクエストを承認する必要があります。 @@ -768,9 +768,9 @@ GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX, CREATE VIEW ON - 接続方法として**Public IP**または**VPC Peering**を使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - 接続方法として**Private Link**を使用する場合、エンドポイント要求を承認するよう求められます。 + - 接続方法として**Private Link**を使用する場合、エンドポイントリクエストを承認するよう求められます。 - AWSの場合： [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**をクリックし、 TiDB Cloudからのエンドポイントリクエストを承認します。 - - Azure の場合: [Azureポータル](https://portal.azure.com)に移動し、MySQL Flexible Server を名前で検索し、左側のナビゲーションペインで**Setting** > **Networking**をクリックし、右側の**Private endpoint**セクションを見つけて、 TiDB Cloudからの保留中の接続要求を承認します。 + - Azure の場合: [Azureポータル](https://portal.azure.com)に移動し、MySQL Flexible Server を名前で検索し、左側のナビゲーションペインで**Setting** > **Networking**をクリックし、右側の**Private endpoint**セクションを見つけて、 TiDB Cloudからの保留中の接続リクエストを承認します。 @@ -781,7 +781,7 @@ GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX, CREATE VIEW ON - 接続方法として**パブリック**を使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)でエンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**を選択し、 TiDB Cloudからのエンドポイント接続要求を承認してください。 + - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)でエンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**を選択し、 TiDB Cloudからのエンドポイント接続リクエストを承認してください。 diff --git a/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md b/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md index 182f92ed9e721..e97a89e30839c 100644 --- a/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md @@ -211,7 +211,7 @@ SHOW VARIABLES LIKE 'binlog_row_image'; - パブリックIPまたはVPCピアリングを使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - AWS Private Link を使用している場合、エンドポイント要求を承認するよう求められます。AWS [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成した AWS リージョンに切り替え、 **Endpoint services**をクリックしてエンドポイント要求を承認してください。 + - AWS Private Link を使用している場合、エンドポイントリクエストを承認するよう求められます。AWS [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成した AWS リージョンに切り替え、 **Endpoint services**をクリックしてエンドポイントリクエストを承認してください。 @@ -223,7 +223,7 @@ SHOW VARIABLES LIKE 'binlog_row_image'; - 接続方法として**パブリック**を使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**をクリックして、 TiDB Cloudからのエンドポイント接続要求を承認してください。 + - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**をクリックして、 TiDB Cloudからのエンドポイント接続リクエストを承認してください。 diff --git a/tidb-cloud/monitor-datadog-integration.md b/tidb-cloud/monitor-datadog-integration.md index b2c11aec30be4..53e06fedeb74c 100644 --- a/tidb-cloud/monitor-datadog-integration.md +++ b/tidb-cloud/monitor-datadog-integration.md @@ -114,7 +114,7 @@ Datadogは、TiDBクラスタに関して以下のメトリクスを追跡しま | :----------------------------------------- | :------- | :---------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | tidb_cloud.db_database_time | ゲージ | sql_type: Select|Insert|...
クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | TiDBで実行されているすべてのSQL文が1秒あたりに消費する合計時間。これには、すべてのプロセスのCPU時間と、アイドル状態ではない待機時間が含まれます。 | | tidb_cloud.db_query_per_second | ゲージ | タイプ: 選択|挿入|...
クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | すべての TiDB ノードで 1秒あたりに実行される SQL文の数。文の種類 ( `SELECT` 、 `INSERT` 、または`UPDATE` ) ごとにカウントされます。 | -| tidb_cloud.db_average_query_duration | ゲージ | sql_type: Select|Insert|...
クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | クライアントのネットワーク要求がTiDBに送信されてから、TiDBが要求を実行した後、クライアントに要求が返されるまでの時間。 | +| tidb_cloud.db_average_query_duration | ゲージ | sql_type: Select|Insert|...
クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | クライアントのネットワークリクエストがTiDBに送信されてから、TiDBがリクエストを実行した後、クライアントにリクエストが返されるまでの時間。 | | tidb_cloud.db_failed_queries | ゲージ | タイプ: 実行者:xxxx|パーサー:xxxx|...
クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | 各TiDBノードで1秒あたりに発生するSQL実行エラーに基づいた、エラーの種類（構文エラーや主キーの競合など）の統計情報。 | | tidb_cloud.db_total_connection | ゲージ | クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | TiDBサーバーにおける現在の接続数。 | | tidb_cloud.db_active_connections | ゲージ | クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | アクティブな接続数。 | diff --git a/tidb-cloud/monitor-new-relic-integration.md b/tidb-cloud/monitor-new-relic-integration.md index ef416ba4a0012..935eedb55a306 100644 --- a/tidb-cloud/monitor-new-relic-integration.md +++ b/tidb-cloud/monitor-new-relic-integration.md @@ -148,7 +148,7 @@ New Relicは、TiDBクラスタに関して以下のメトリクスを追跡し | :----------------------------------------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | tidb_cloud.db_database_time | ゲージ | sql_type: Select|Insert|...

クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | TiDBで実行されるすべてのSQL文が1秒あたりに消費する合計時間。これには、すべてのプロセスのCPU時間と、アイドル状態ではない待機時間が含まれます。 | | tidb_cloud.db_query_per_second | ゲージ | タイプ: 選択|挿入|...

クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | すべての TiDB ノードで 1秒あたりに実行される SQL文の数。これは`SELECT` 、 `INSERT` 、 `UPDATE` 、およびその他のタイプの文に従ってカウントされます。 | -| tidb_cloud.db_average_query_duration | ゲージ | sql_type: Select|Insert|...

クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | クライアントのネットワーク要求がTiDBに送信されてから、TiDBが要求を実行した後、クライアントに要求が返されるまでの時間。 | +| tidb_cloud.db_average_query_duration | ゲージ | sql_type: Select|Insert|...

クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | クライアントのネットワークリクエストがTiDBに送信されてから、TiDBがリクエストを実行した後、クライアントにリクエストが返されるまでの時間。 | | tidb_cloud.db_failed_queries | ゲージ | タイプ: 実行者:xxxx|パーサー:xxxx|...

クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | 各TiDBノードで1秒あたりに発生するSQL実行エラーに基づいた、エラーの種類（構文エラーや主キーの競合など）の統計情報。 | | tidb_cloud.db_total_connection | ゲージ | クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | TiDBサーバーにおける現在の接続数。 | | tidb_cloud.db_active_connections | ゲージ | クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | アクティブな接続数。 | diff --git a/tidb-cloud/optimize-resource-allocation.md b/tidb-cloud/optimize-resource-allocation.md index c6e80a1f9e9a8..2e41dcbbca5ff 100644 --- a/tidb-cloud/optimize-resource-allocation.md +++ b/tidb-cloud/optimize-resource-allocation.md @@ -32,7 +32,7 @@ TiDB Cloud Dedicatedは、 [リソース管理](/tidb-resource-control-ru-groups | 比較項目 | リソース管理 | TiDBノードグループ | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | | 分離レベル | TiKVまたはTiFlash論理レイヤー | TiDBノード物理レイヤー | -| フロー制御 | リソースグループに設定されたクォータに基づいて、ユーザーの読み取りおよび書き込み要求のフローを制御します。 | サポートされていません。 | +| フロー制御 | リソースグループに設定されたクォータに基づいて、ユーザーの読み取りおよび書き込みリクエストのフローを制御します。 | サポートされていません。 | | コンフィグレーション方法 | SQL文を使用して構成 | TiDB Cloudコンソールから設定 | | ワークロードの区別 | 次のレベルでのバインディング リソースをサポートします。
  • ユーザーレベル。
  • セッションレベル (セッションごとにリソースグループを設定します)。
  • ステートメントレベル (ステートメントごとにリソースグループを設定します)。
| さまざまなワークロードに異なる接続エンドポイントを提供します。 | | 料金 | 追加料金なし | TiDB ノードの追加に関連するコストは発生しますが、TiDB ノードグループの作成には追加コストは発生しません。 | diff --git a/tidb-cloud/plan-replayer.md b/tidb-cloud/plan-replayer.md index 4d4e471bb16e2..8b6f0e1315d28 100644 --- a/tidb-cloud/plan-replayer.md +++ b/tidb-cloud/plan-replayer.md @@ -48,7 +48,7 @@ SELECT * FROM orders WHERE customer_id = 1001; ### 履歴統計情報を使用する {#use-historical-statistics} -履歴統計情報が有効になっており、パフォーマンスの問題が特定の時刻に発生した場合は、`WITH STATS AS OF TIMESTAMP` を使用して、その時点で利用可能だった統計情報を要求します。TiDB は、指定したタイムスタンプより前に利用可能な最新の履歴統計情報を使用します。 +履歴統計情報が有効になっており、パフォーマンスの問題が特定の時刻に発生した場合は、`WITH STATS AS OF TIMESTAMP` を使用して、その時点で利用可能だった統計情報をリクエストします。TiDB は、指定したタイムスタンプより前に利用可能な最新の履歴統計情報を使用します。 ```sql PLAN REPLAYER DUMP WITH STATS AS OF TIMESTAMP diff --git a/tidb-cloud/releases/release-notes-2023.md b/tidb-cloud/releases/release-notes-2023.md index 953ee8f45f616..21d8a0e970ecd 100644 --- a/tidb-cloud/releases/release-notes-2023.md +++ b/tidb-cloud/releases/release-notes-2023.md @@ -228,7 +228,7 @@ summary: 2023年のTiDB Cloudのリリースノートについて説明します 詳細については[エンドポイントを呼び出す](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)を参照してください。 -- [Data Service（ベータ版）](https://tidbcloud.com/project/data-service)は指定された有効期間 (TTL) にわたって`GET`要求のエンドポイント応答のキャッシュをサポートします。 +- [Data Service（ベータ版）](https://tidbcloud.com/project/data-service)は指定された有効期間 (TTL) にわたって`GET`リクエストのエンドポイント応答のキャッシュをサポートします。 この機能により、データベースの負荷が軽減され、エンドポイントのレイテンシーが最適化されます。 @@ -954,7 +954,7 @@ summary: 2023年のTiDB Cloudのリリースノートについて説明します **コンソールの変更** -- 特定のクラスターに対するサポートを要求するプロセスを簡素化するために、各クラスターに**[サポートを受ける]**オプションを追加します。 +- 特定のクラスターに対するサポートをリクエストするプロセスを簡素化するために、各クラスターに**[サポートを受ける]**オプションを追加します。 クラスターのサポートは、次のいずれかの方法でリクエストできます。 diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md index 5787c6211b95b..4953b53551f21 100644 --- a/tidb-cloud/releases/tidb-cloud-release-notes.md +++ b/tidb-cloud/releases/tidb-cloud-release-notes.md @@ -760,7 +760,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', - [スロークエリ](/tidb-cloud/tune-performance.md#slow-query)ビュー、[DB監査ログ](/tidb-cloud/essential-database-audit-logging.md)、および[`INFORMATION_SCHEMA.PROCESSLIST`](/information-schema/information-schema-processlist.md)テーブル (ベータ版) に実際のクライアント IP アドレスを表示 - TiDB CloudはクライアントIPパススルーをサポートするようになり、スロークエリビュー、DB監査ログ、および`INFORMATION_SCHEMA.PROCESSLIST`テーブルで、ロードバランサー（LB）のIPアドレスではなく、実際のクライアントIPアドレスを表示できるようになりました。この機能により、データベース要求の真の発生源を正確に特定し、トラブルシューティングと分析を改善できます。 + TiDB CloudはクライアントIPパススルーをサポートするようになり、スロークエリビュー、DB監査ログ、および`INFORMATION_SCHEMA.PROCESSLIST`テーブルで、ロードバランサー（LB）のIPアドレスではなく、実際のクライアントIPアドレスを表示できるようになりました。この機能により、データベースリクエストの真の発生源を正確に特定し、トラブルシューティングと分析を改善できます。 現在、この機能はベータ版であり、AWSリージョン`Frankfurt (eu-central-1)`でのみ利用可能です。 diff --git a/tidb-cloud/serverless-high-availability.md b/tidb-cloud/serverless-high-availability.md index 0c5daa40c96b5..eacde67dfc7b5 100644 --- a/tidb-cloud/serverless-high-availability.md +++ b/tidb-cloud/serverless-high-availability.md @@ -14,7 +14,7 @@ TiDB Cloudは、デフォルトで高い可用性とデータの耐久性を維 ## 概要 {#overview} -TiDBは、 Raftコンセンサスアルゴリズムを用いて高い可用性とデータの耐久性を確保します。このアルゴリズムは、複数のノード間でデータの変更を一貫して複製するため、ノード障害やネットワーク分断が発生した場合でも、TiDBは読み取りおよび書き込み要求を処理できます。このアプローチにより、高いデータの耐久性と耐障害性の両方が実現されます。 +TiDBは、 Raftコンセンサスアルゴリズムを用いて高い可用性とデータの耐久性を確保します。このアルゴリズムは、複数のノード間でデータの変更を一貫して複製するため、ノード障害やネットワーク分断が発生した場合でも、TiDBは読み取りおよび書き込みリクエストを処理できます。このアプローチにより、高いデータの耐久性と耐障害性の両方が実現されます。 TiDB Cloudは、ゾーン別高可用性とリージョン別高可用性によってこれらの機能を拡張し、さまざまな運用要件に対応します。 diff --git a/tidb-cloud/serverless-private-link-connection.md b/tidb-cloud/serverless-private-link-connection.md index 1d413d83ce1c6..daaeb5ff2f6ea 100644 --- a/tidb-cloud/serverless-private-link-connection.md +++ b/tidb-cloud/serverless-private-link-connection.md @@ -71,7 +71,7 @@ ticloud serverless private-link-connection zones --cluster-id 5. **Create**をクリックします。 -6. [AWSコンソール](https://console.aws.amazon.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を承認します。 +6. [AWSコンソール](https://console.aws.amazon.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続リクエストを承認します。 @@ -85,7 +85,7 @@ TiDB Cloud CLI を使用してプライベートリンク接続を作成する ticloud serverless private-link-connection create -c --display-name --type AWS_ENDPOINT_SERVICE --aws.endpoint-service-name ``` -2. [AWSコンソール](https://console.aws.amazon.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を承認します。 +2. [AWSコンソール](https://console.aws.amazon.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続リクエストを承認します。 @@ -161,7 +161,7 @@ ticloud serverless private-link-connection zones --cluster-id 5. **Create**をクリックします。 -6. [Alibaba Cloudコンソール](https://console.alibabacloud.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を許可します。 +6. [Alibaba Cloudコンソール](https://console.alibabacloud.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続リクエストを許可します。 @@ -175,7 +175,7 @@ TiDB Cloud CLI を使用してプライベートリンク接続を作成する ticloud serverless private-link-connection create -c --display-name --type ALICLOUD_ENDPOINT_SERVICE --alicloud.endpoint-service-name ``` -2. [Alibaba Cloudコンソール](https://console.alibabacloud.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を許可します。 +2. [Alibaba Cloudコンソール](https://console.alibabacloud.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続リクエストを許可します。 diff --git a/tidb-cloud/set-up-sink-private-endpoint.md b/tidb-cloud/set-up-sink-private-endpoint.md index 5e891fd43d7f7..cdc44868f268b 100644 --- a/tidb-cloud/set-up-sink-private-endpoint.md +++ b/tidb-cloud/set-up-sink-private-endpoint.md @@ -110,7 +110,7 @@ changefeed ダウンストリーム サービスが Azure でホストされて 2. **Create Private Endpoint for External Services**ダイアログで、プライベートエンドポイントの名前を入力します。 -3. リマインダーに従って、 TiDB Cloudの[Google Cloud プロジェクト](https://cloud.google.com/resource-manager/docs/creating-managing-projects)にエンドポイントの作成を事前承認するよう許可するか、エンドポイント接続要求を受け取ったら手動で承認します。 +3. リマインダーに従って、 TiDB Cloudの[Google Cloud プロジェクト](https://cloud.google.com/resource-manager/docs/creating-managing-projects)にエンドポイントの作成を事前承認するよう許可するか、エンドポイント接続リクエストを受け取ったら手動で承認します。 4. セクション[ネットワーク](#network)で収集した**Service Attachment**を入力します。 diff --git a/tidb-cloud/set-up-vpc-peering-connections.md b/tidb-cloud/set-up-vpc-peering-connections.md index d2cdc26f5ea81..c10fe6a8daaf2 100644 --- a/tidb-cloud/set-up-vpc-peering-connections.md +++ b/tidb-cloud/set-up-vpc-peering-connections.md @@ -201,7 +201,7 @@ AWS CLI または AWS ダッシュボードを使用して、VPC ピアリング AWS ダッシュボードを使用して VPC ピアリング接続を構成することもできます。 -1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)でピア接続要求を受け入れることを確認します。 +1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)でピア接続リクエストを受け入れることを確認します。 1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)にサインインし、上部のメニューバーで**Services**をクリックします。検索ボックスに`VPC`と入力して、VPC サービスページに移動します。 diff --git a/tidb-cloud/tidb-cloud-auditing.md b/tidb-cloud/tidb-cloud-auditing.md index dee2c0a061af4..89ba80aaf2057 100644 --- a/tidb-cloud/tidb-cloud-auditing.md +++ b/tidb-cloud/tidb-cloud-auditing.md @@ -304,7 +304,7 @@ TiDB Cloudがデータベース監査ログを書き込む宛先として、組 > **Note:** > -> 監査ログファイルをTiDB Cloudに保存することを要求して選択した場合は、**Database Audit Logging**ページの**Audit Log Access**セクションからダウンロードできます。 +> 監査ログファイルをTiDB Cloudに保存することをリクエストして選択した場合は、**Database Audit Logging**ページの**Audit Log Access**セクションからダウンロードできます。 TiDB Cloud監査ログは、クラスター ID、ノード ID、およびログ作成日が完全修飾ファイルパスに組み込まれた読み取り可能なテキストファイルです。 diff --git a/tidb-cloud/tidb-cloud-glossary.md b/tidb-cloud/tidb-cloud-glossary.md index 9a5ba1cf0034a..cf505fa730a6c 100644 --- a/tidb-cloud/tidb-cloud-glossary.md +++ b/tidb-cloud/tidb-cloud-glossary.md @@ -178,7 +178,7 @@ TiDB Cloud Starter、 Essential、およびPremiumプランでは、リクエス - TiDB Cloud Starter は、消費された RU の合計数に基づいて請求されます。詳細については、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)を参照してください。 - TiDB Cloud Essentialは、プロビジョニングされた[リクエストキャパシティユニット（RCU）](#request-capacity-unit-rcu)の数に基づいて請求されます。 1つの RCU は、1秒あたり特定の数の RU を処理できる固定量のコンピューティングリソースを提供します。詳細については、 [TiDB Cloud Essential の価格詳細](https://www.pingcap.com/tidb-cloud-essential-pricing-details/)を参照してください。 - TiDB Cloud Premium は、ワークロードによって消費された実際のリクエストキャパシティユニット (RCU) に基づいて請求されます。 TiDB Cloudは1秒あたりの平均 RU を毎分計算し、その平均値を[リクエストキャパシティユニット（RCU）](#request-capacity-unit-rcu)として請求に使用します。詳細については、 [TiDB Cloud Premiumでユニットと容量をリクエストする](https://docs.pingcap.com/tidbcloud/architecture-concepts/?plan=premium#request-units-and-capacity-in-premium)を参照してください。 -TiDB Cloud Dedicatedおよび TiDB Self-Managedの場合、リクエストユニット (RU) はシステムリソースの消費を表すリソース抽象化ユニットであり、これには現在 CPU、IOPS、および IO 帯域幅のメトリクスが含まれます。これは、**請求目的ではなく**、データベース要求によって消費されるリソースを制限、分離、管理するためにリソース制御機能によって使用されます。詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md)を参照してください。 +TiDB Cloud Dedicatedおよび TiDB Self-Managedの場合、リクエストユニット (RU) はシステムリソースの消費を表すリソース抽象化ユニットであり、これには現在 CPU、IOPS、および IO 帯域幅のメトリクスが含まれます。これは、**請求目的ではなく**、データベースリクエストによって消費されるリソースを制限、分離、管理するためにリソース制御機能によって使用されます。詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md)を参照してください。 ## S {#s} diff --git a/tidb-cloud/tidb-cloud-tune-performance-overview.md b/tidb-cloud/tidb-cloud-tune-performance-overview.md index 883c10f66292e..22137f2f28f80 100644 --- a/tidb-cloud/tidb-cloud-tune-performance-overview.md +++ b/tidb-cloud/tidb-cloud-tune-performance-overview.md @@ -26,17 +26,17 @@ summary: TiDB Cloudで SQL パフォーマンスを分析および調整する ## ユーザー応答時間とシステムスループットの関係 {#relationship-between-user-response-time-and-system-throughput} -ユーザー応答時間は、サービス時間、キュー時間、およびユーザー要求を完了するための同時待機時間で構成されます。 +ユーザー応答時間は、サービス時間、キュー時間、およびユーザーリクエストを完了するための同時待機時間で構成されます。 ``` User Response time = Service time + Queuing delay + Coherency delay ``` - サービス時間: リクエストを処理するときにシステムが特定のリソースに消費する時間。たとえば、データベースが SQL リクエストを完了するために消費する CPU 時間など。 -- キューイング遅延: システムが要求を処理するときに、特定のリソースのサービスをキューで待機する時間。 +- キューイング遅延: システムがリクエストを処理するときに、特定のリソースのサービスをキューで待機する時間。 - 一貫性遅延: システムがリクエストを処理するときに共有リソースにアクセスできるように、他の同時タスクと通信して連携する時間。 -システムスループットとは、システムが1秒間に処理できるリクエストの数を指します。ユーザー応答時間とスループットは通常、反比例関係にあります。スループットが増加すると、システムリソースの使用率と、要求されたサービスのキューイングレイテンシーもそれに応じて増加します。リソース使用率が一定の変曲点を超えると、キューイングレイテンシーは劇的に増加します。 +システムスループットとは、システムが1秒間に処理できるリクエストの数を指します。ユーザー応答時間とスループットは通常、反比例関係にあります。スループットが増加すると、システムリソースの使用率と、リクエストされたサービスのキューイングレイテンシーもそれに応じて増加します。リソース使用率が一定の変曲点を超えると、キューイングレイテンシーは劇的に増加します。 例えば、OLTP負荷を実行しているデータベースシステムでは、CPU使用率が65%を超えると、CPUキューイングとスケジューリングのレイテンシーが大幅に増加します。これは、システムの同時リクエストが完全に独立していないため、これらのリクエストが連携して共有リソースを奪い合う可能性があるためです。例えば、異なるユーザーからのリクエストが、同じデータに対して相互に排他的なロック操作を実行する場合があります。リソース使用率が増加すると、キューイングとスケジューリングのレイテンシーも増加し、共有リソースが時間内に解放されず、他のタスクによる共有リソースの待機時間が長くなります。 diff --git a/tidb-cloud/v8.5-performance-highlights.md b/tidb-cloud/v8.5-performance-highlights.md index d2270c2cbb65b..340bef41cfac4 100644 --- a/tidb-cloud/v8.5-performance-highlights.md +++ b/tidb-cloud/v8.5-performance-highlights.md @@ -31,7 +31,7 @@ summary: TiDB バージョン v8.5.0 では、 TiDB Cloud Dedicated クラスタ - 頻繁なバージョン更新: 一部のワークロードでは、データが非常に頻繁に更新され、読み取られます。 - 履歴バージョンの長期保存：特定の時点へのフラッシュバックのサポートといったビジネス要件を満たすために、ユーザーはGC（ガベージコレクション）時間を過度に長く（例えば24時間など）設定することがあります。その結果、多版型同時実行制御（MVCC）バージョンが過剰に蓄積され、クエリの効率が大幅に低下します。 -MVCC バージョンが蓄積されると、要求されたデータと処理されたデータの間に大きなギャップが生じ、読み取りパフォーマンスが低下します。 +MVCC バージョンが蓄積されると、リクエストされたデータと処理されたデータの間に大きなギャップが生じ、読み取りパフォーマンスが低下します。 ### 解決 {#solution} diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index e2421cfb47e95..7fb5b7dfcb29d 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -349,7 +349,7 @@ TiDB 構成ファイルは、コマンドラインパラメーターよりも多 - TiDBにおけるログ書き込み操作のタイムアウトを設定します。ディスク障害によりログの書き込みができない場合、この設定項目によってTiDBプロセスがハングアップするのではなく、panicになることがあります。 - デフォルト値： `0` 。これはタイムアウトが設定されていないことを示します。 - 単位：秒 -- 一部のユーザーシナリオでは、TiDBログがホットプラグ対応ディスクまたはネットワーク接続ディスクに保存されることがありますが、これらのディスクが永久的に使用不能になる可能性があります。このような場合、TiDBは自動的に復旧できず、ログ書き込み操作は永久的にブロックされます。TiDBプロセスは実行されているように見えても、実際にはどの要求にも応答しません。この設定項目は、このような状況に対処するために設計されています。 +- 一部のユーザーシナリオでは、TiDBログがホットプラグ対応ディスクまたはネットワーク接続ディスクに保存されることがありますが、これらのディスクが永久的に使用不能になる可能性があります。このような場合、TiDBは自動的に復旧できず、ログ書き込み操作は永久的にブロックされます。TiDBプロセスは実行されているように見えても、実際にはどのリクエストにも応答しません。この設定項目は、このような状況に対処するために設計されています。 ### log.file {#logfile} @@ -799,7 +799,7 @@ opentracing.reporter に関連するコンフィグレーション項目。 > > この設定パラメータは将来のバージョンで非推奨になる可能性があります。値を変更**しないでください**。 -- 単一のコプロセッサー要求のタイムアウト時間。 +- 単一のコプロセッサーリクエストのタイムアウト時間。 - デフォルト値: `60` - 単位：秒 diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index 168cbbeaddada..9be7b0b92b966 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -250,7 +250,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 > > バージョン7.2.0以降、このパラメータは非推奨となり、設定後は無効になります。1回のリクエストでTiKVに送信されるデータ量を調整したい場合は、代わりに[`send-kv-size`](#send-kv-size-new-in-v720)パラメータを使用してください。 -- 物理インポートモードで TiKV にデータを送信するときに、1つの要求内の KV ペアの最大数を指定します。 +- 物理インポートモードで TiKV にデータを送信するときに、1つのリクエスト内の KV ペアの最大数を指定します。 diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index 4eed7ea317b47..31bd6d68ba88e 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -69,7 +69,7 @@ SET GLOBAL tidb_opt_fix_control = '44262:ON,44389:ON,44823:10000,44830:ON,44855: | [`tidb_opt_enable_mpp_shared_cte_execution`](/system-variables.md#tidb_opt_enable_mpp_shared_cte_execution-new-in-v720) | TiFlashへの非再帰的な[共通テーブル式（CTE）](/sql-statements/sql-statement-with.md)プッシュダウンを有効にします。 | これは実験的機能です。 | | [`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600) | Read Committed分離レベルの場合、この変数を有効にすると、グローバルタイムスタンプを取得する際のレイテンシーとコストが回避され、トランザクションレベルの読み取りレイテンシーが最適化されます。 | この機能は、Repeatable Read分離レベルとは互換性がありません。 | | [`tidb_guarantee_linearizability`](/system-variables.md#tidb_guarantee_linearizability-new-in-v50) | PDサーバーからのコミットタイムスタンプの取得をスキップすることでパフォーマンスを向上させます。 | これは、線形化可能性を犠牲にしてパフォーマンスを優先するものです。因果的一貫性のみが保証されます。厳密な線形化可能性が求められるシナリオには適していません。 | -| [`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) | PDFollower機能を有効にすると、PDフォロワーがリージョン要求を処理できるようになります。これにより、すべてのPDサーバーに負荷が均等に分散され、PDリーダーのCPU負荷が軽減されます。 | 該当なし | +| [`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) | PDFollower機能を有効にすると、PDフォロワーがリージョンリクエストを処理できるようになります。これにより、すべてのPDサーバーに負荷が均等に分散され、PDリーダーのCPU負荷が軽減されます。 | 該当なし | | [`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) | 高度なクエリ最適化戦略を有効にすることで、追加の最適化ルールとヒューリスティックを通じてパフォーマンスを向上させることができます。 | ワークロードによってパフォーマンスの向上度合いが異なるため、ご使用の環境で十分にテストを行ってください。 | 以下では、追加の最適化を可能にするオプティマイザ制御構成について説明します。 @@ -121,7 +121,7 @@ soft-pending-compaction-bytes-limit = "192GiB" | [`concurrent-send-snap-limit`](/tikv-configuration-file.md#concurrent-send-snap-limit) [`concurrent-recv-snap-limit`](/tikv-configuration-file.md#concurrent-recv-snap-limit) [`snap-io-max-bytes-per-sec`](/tikv-configuration-file.md#snap-io-max-bytes-per-sec) | TiKVのスケーリング操作中に、同時スナップショット転送量とI/O帯域幅の制限を設定します。制限値を高く設定すると、データ移行が高速化され、スケーリング時間が短縮されます。 | これらの制限を調整すると、スケーリング速度とオンライントランザクションパフォーマンスのトレードオフに影響します。 | | [`rocksdb.max-manifest-file-size`](/tikv-configuration-file.md#max-manifest-file-size) | RocksDB マニフェストファイルの最大サイズを設定します。このファイルには、SST ファイルとデータベースの状態変更に関するメタデータが記録されます。このサイズを大きくすると、マニフェストファイルの書き換え頻度が減り、フォアグラウンド書き込みパフォーマンスへの影響を最小限に抑えることができます。 | デフォルト値は`128MiB`です。SSTファイルが多数存在する環境（例えば、数十万個）では、マニフェストファイルの書き換えが頻繁に行われると、書き込みパフォーマンスが低下する可能性があります。このパラメータを`256MiB`以上の値に調整することで、最適なパフォーマンスを維持できます。 | | [`rocksdb.titan`](/tikv-configuration-file.md#rocksdbtitan) [`rocksdb.defaultcf.titan`](/tikv-configuration-file.md#rocksdbdefaultcftitan) [`min-blob-size`](/tikv-configuration-file.md#min-blob-size) [`blob-file-compression`](/tikv-configuration-file.md#blob-file-compression) | Titanストレージエンジンを有効にすることで、書き込み増幅を低減し、ディスクI/Oのボトルネックを緩和できます。特に、RocksDBの圧縮処理が書き込みワークロードに追いつかず、圧縮待ちバイトが蓄積される場合に有効です。 | 書き込み増幅が主なボトルネックである場合に有効にします。トレードオフは以下のとおりです。
  • 主キー範囲スキャンにおけるパフォーマンスへの影響の可能性。
  • 空間増幅率の向上（最悪の場合、最大2倍）。
  • ブロブキャッシュのための追加メモリ使用量。
| -| [`storage.scheduler-pending-write-threshold`](/tikv-configuration-file.md#scheduler-pending-write-threshold) | TiKVスケジューラで書き込みキューの最大サイズを設定します。保留中の書き込みタスクの合計サイズがこのしきい値を超えると、TiKVは新規書き込み要求に対してエラーコード`Server Is Busy`を返します。 | デフォルト値は`100MiB`です。書き込み同時実行数が多い場合や、一時的な書き込みスパイクが発生する場合は、このしきい値を上げる（例えば`512MiB`にする）ことで負荷に対応できます。ただし、書き込みキューが継続的に蓄積され、このしきい値を超える場合は、根本的なパフォーマンスの問題が発生している可能性があり、さらに調査が必要です。 | +| [`storage.scheduler-pending-write-threshold`](/tikv-configuration-file.md#scheduler-pending-write-threshold) | TiKVスケジューラで書き込みキューの最大サイズを設定します。保留中の書き込みタスクの合計サイズがこのしきい値を超えると、TiKVは新規書き込みリクエストに対してエラーコード`Server Is Busy`を返します。 | デフォルト値は`100MiB`です。書き込み同時実行数が多い場合や、一時的な書き込みスパイクが発生する場合は、このしきい値を上げる（例えば`512MiB`にする）ことで負荷に対応できます。ただし、書き込みキューが継続的に蓄積され、このしきい値を超える場合は、根本的なパフォーマンスの問題が発生している可能性があり、さらに調査が必要です。 | | [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold) | kvDB L0ファイルの数に基づいて、書き込みフロー制御がトリガーされるタイミングを制御します。しきい値を上げると、書き込み負荷が高い場合の書き込み停止が減少します。 | しきい値を高く設定すると、L0ファイルが多数存在する場合に、より積極的な圧縮処理が行われる可能性があります。 | | [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 書き込みフロー制御を管理するために、保留中の圧縮バイトのしきい値を制御します。ソフトリミットを設定すると、部分的な書き込み拒否が発生します。 | デフォルトのソフトリミットは`192GiB`です。書き込み負荷の高いシナリオでは、圧縮処理が追いつかない場合、保留中の圧縮バイトが蓄積され、フロー制御がトリガーされる可能性があります。リミットを調整することでバッファ領域を増やすことができますが、蓄積が続く場合は、さらなる調査が必要な根本的な問題があることを示しています。 | | [`rocksdb.(defaultcf|writecf|lockcf).level0-slowdown-writes-trigger`](/tikv-configuration-file.md#level0-slowdown-writes-trigger)と[`rocksdb.(defaultcf|writecf|lockcf).soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1) | `level0-slowdown-writes-trigger`と`soft-pending-compaction-bytes-limit`デフォルト値に手動で設定する必要があります。こうすることで、フロー制御パラメータの影響を受けなくなります。さらに、Rocksdbパラメータを設定して、デフォルトパラメータと同じ圧縮効率を維持してください。 | 詳細については、 [第18708号](https://github.com/tikv/tikv/issues/18708)を参照してください。 | @@ -145,7 +145,7 @@ soft-pending-compaction-bytes-limit = "192GiB" > **Note:** > -> TiKVは、システムの安定性を確保するために、スケジューラレイヤーでフロー制御を実装しています。保留中の圧縮バイト数や書き込みキューサイズなどの重要なしきい値を超えると、TiKVは書き込み要求を拒否し、ServerIsBusyエラーを返します。このエラーは、バックグラウンドの圧縮プロセスがフォアグラウンドの書き込み操作の現在の速度に追いつけないことを示しています。フロー制御が有効になると、通常、レイテンシーの急増とクエリスループットの低下（QPSの低下）が発生します。これらのパフォーマンス低下を防ぐには、包括的なキャパシティプランニングと、圧縮パラメータおよびストレージ設定の適切な構成が不可欠です。 +> TiKVは、システムの安定性を確保するために、スケジューラレイヤーでフロー制御を実装しています。保留中の圧縮バイト数や書き込みキューサイズなどの重要なしきい値を超えると、TiKVは書き込みリクエストを拒否し、ServerIsBusyエラーを返します。このエラーは、バックグラウンドの圧縮プロセスがフォアグラウンドの書き込み操作の現在の速度に追いつけないことを示しています。フロー制御が有効になると、通常、レイテンシーの急増とクエリスループットの低下（QPSの低下）が発生します。これらのパフォーマンス低下を防ぐには、包括的なキャパシティプランニングと、圧縮パラメータおよびストレージ設定の適切な構成が不可欠です。 ### TiFlash -ラーナー向け設定 {#tiflash-learner-configurations} @@ -333,10 +333,10 @@ go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p #### トラブルシューティング {#troubleshooting} -ワークロードに頻繁に発生する小規模なトランザクションや、タイムスタンプを頻繁に要求するクエリが含まれる場合、 [TSO（タイムスタンプオラクル）](/glossary.md#timestamp-oracle-tso)がパフォーマンスのボトルネックになる可能性があります。TSO の待機時間がシステムに影響を与えているかどうかを確認するには、 [**パフォーマンス概要 > SQL実行時間概要**](/grafana-performance-overview-dashboard.md#sql-execute-time-overview)パネルを確認してください。TSO の待機時間が SQL 実行時間の大部分を占める場合は、次の最適化を検討してください。 +ワークロードに頻繁に発生する小規模なトランザクションや、タイムスタンプを頻繁にリクエストするクエリが含まれる場合、 [TSO（タイムスタンプオラクル）](/glossary.md#timestamp-oracle-tso)がパフォーマンスのボトルネックになる可能性があります。TSO の待機時間がシステムに影響を与えているかどうかを確認するには、 [**パフォーマンス概要 > SQL実行時間概要**](/grafana-performance-overview-dashboard.md#sql-execute-time-overview)パネルを確認してください。TSO の待機時間が SQL 実行時間の大部分を占める場合は、次の最適化を検討してください。 - 厳密な一貫性を必要としない読み取り操作には、低精度TSO（ [`tidb_low_resolution_tso`](/system-variables.md#tidb_low_resolution_tso)を有効にする）を使用します。詳細については、 [解決策1：低精度TSOを使用する](#solution-1-low-precision-tso)を参照してください。 -- 可能な場合は、小さなトランザクションをまとめて大きなトランザクションにします。詳細については、 [解決策2：TSO要求の並列モード](#solution-2-parallel-mode-for-tso-requests)を参照してください。 +- 可能な場合は、小さなトランザクションをまとめて大きなトランザクションにします。詳細については、 [解決策2：TSOリクエストの並列モード](#solution-2-parallel-mode-for-tso-requests)を参照してください。 #### 解決策1：低精度TSO {#solution-1-low-precision-tso} @@ -350,7 +350,7 @@ go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p メリットとデメリット： -- キャッシュされたTSOを使用して古いデータの読み取りを有効にすることで、クエリのレイテンシーを削減し、新しいタイムスタンプを要求する必要性をなくします。 +- キャッシュされたTSOを使用して古いデータの読み取りを有効にすることで、クエリのレイテンシーを削減し、新しいタイムスタンプをリクエストする必要性をなくします。 - パフォーマンスとデータの一貫性のバランスを取る：この機能は、古い読み取りデータが許容されるシナリオにのみ適しています。厳密なデータの一貫性が求められる場合には、使用を推奨しません。 この最適化を有効にするには： @@ -359,7 +359,7 @@ go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p SET GLOBAL tidb_low_resolution_tso=ON; ``` -#### 解決策2：TSO要求の並列モード {#solution-2-parallel-mode-for-tso-requests} +#### 解決策2：TSOリクエストの並列モード {#solution-2-parallel-mode-for-tso-requests} システム変数[`tidb_tso_client_rpc_mode`](/system-variables.md#tidb_tso_client_rpc_mode-new-in-v840)は、TiDBがPDにTSO RPCリクエストを送信するモードを切り替えます。デフォルト値は`DEFAULT`です。以下の条件を満たす場合、パフォーマンス向上の可能性を考慮して、この変数を`PARALLEL`または`PARALLEL-FAST`に切り替えることを検討してください。 diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index b7e2a6a17eaf0..3ee9737861606 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -12,11 +12,11 @@ aliases: ['/ja/tidb/v8.5/tidb-resource-control/','/ja/tidb/stable/tidb-resource- クラスタ管理者として、リソース制御機能を使用して、リソースグループの作成、リソースグループの割り当て量の設定、およびユーザーをそれらのグループにバインドすることができます。 -TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能とTiKVレイヤーの優先度スケジューリング機能という2つのレイヤーのリソース管理機能を提供します。これらの2つの機能は、個別に、または同時に有効にすることができます。詳しくは[リソース制御のためのパラメータ](#parameters-for-resource-control)を参照してください。これにより、TiDBレイヤーはリソースグループに設定されたクォータに基づいてユーザーの読み取りおよび書き込み要求のフローを制御し、TiKVレイヤーは読み取りおよび書き込みクォータにマッピングされた優先度に基づいて要求をスケジュールすることができます。この操作を行うことで、アプリケーションのリソース分離を確保し、サービス品質（QoS）要件を満たすことができます。 +TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能とTiKVレイヤーの優先度スケジューリング機能という2つのレイヤーのリソース管理機能を提供します。これらの2つの機能は、個別に、または同時に有効にすることができます。詳しくは[リソース制御のためのパラメータ](#parameters-for-resource-control)を参照してください。これにより、TiDBレイヤーはリソースグループに設定されたクォータに基づいてユーザーの読み取りおよび書き込みリクエストのフローを制御し、TiKVレイヤーは読み取りおよび書き込みクォータにマッピングされた優先度に基づいてリクエストをスケジュールすることができます。この操作を行うことで、アプリケーションのリソース分離を確保し、サービス品質（QoS）要件を満たすことができます。 - TiDBフロー制御：TiDBフロー制御は[トークンバケットアルゴリズム](https://en.wikipedia.org/wiki/Token_bucket)を使用します。バケットに十分なトークンがなく、リソースグループが`BURSTABLE`オプションを指定していない場合、リソースグループへのリクエストはトークンバケットがトークンを補充するまで待機し、再試行します。再試行はタイムアウトにより失敗する可能性があります。 -- TiKV スケジューリング: 必要に応じて絶対優先度[（ `PRIORITY` ）](/information-schema/information-schema-resource-groups.md#examples)を設定できます。異なるリソースは`PRIORITY`設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKV は各リソースグループの`RU_PER_SEC`の値を使用して、各リソースグループの読み取りおよび書き込み要求の優先度を決定します。ストレージレイヤーは、優先度に基づいて優先度キューを使用して要求をスケジュールおよび処理します。 +- TiKV スケジューリング: 必要に応じて絶対優先度[（ `PRIORITY` ）](/information-schema/information-schema-resource-groups.md#examples)を設定できます。異なるリソースは`PRIORITY`設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKV は各リソースグループの`RU_PER_SEC`の値を使用して、各リソースグループの読み取りおよび書き込みリクエストの優先度を決定します。ストレージレイヤーは、優先度に基づいて優先度キューを使用してリクエストをスケジュールおよび処理します。 バージョン7.4.0以降、リソース制御機能はTiFlashリソースの制御をサポートしています。その原理は、TiDBフロー制御およびTiKVスケジューリングと同様です。 @@ -399,7 +399,7 @@ TiKVは、Grafanaの**TiKV**ダッシュボードに、さまざまなリソー 3. すべてのリソースグループの合計リソース割り当て（ `RU_PER_SEC` ）がシステム容量を超えた場合、どうなりますか？ - TiDB は、リソースグループを作成する際に容量を検証しません。システムに十分な利用可能なリソースがあれば、TiDB は各リソースグループのリソース要件を満たすことができます。システムリソースが制限を超えると、TiDB は優先度の高いリソースグループからの要求を満たすことを優先します。同じ優先度の要求すべてを満たすことができない場合、TiDB はリソース割り当て ( `RU_PER_SEC` ) に従ってリソースを比例的に割り当てます。 + TiDB は、リソースグループを作成する際に容量を検証しません。システムに十分な利用可能なリソースがあれば、TiDB は各リソースグループのリソース要件を満たすことができます。システムリソースが制限を超えると、TiDB は優先度の高いリソースグループからのリクエストを満たすことを優先します。同じ優先度のリクエストすべてを満たすことができない場合、TiDB はリソース割り当て ( `RU_PER_SEC` ) に従ってリソースを比例的に割り当てます。 ## 参照 {#see-also} diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index b12bb82f709b3..2bf8e23d96cc5 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -239,13 +239,13 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 4.3.1 TiKV RocksDB は`write stall`を検出します。 - TiKV インスタンスには 2つの RocksDB インスタンスがあり、1つは`data/raft`にありRaftログを格納し、もう 1つは`data/db`にあり実際のデータを格納します。ログで`grep "Stalling" RocksDB`を実行すると、停止の具体的な原因を確認できます。RocksDB ログは`LOG`で始まるファイルで、 `LOG`が現在のログです。 `write stall`は RocksDB にネイティブに組み込まれたパフォーマンス低下メカニズムです。RocksDB で`write stall`が発生すると、システムのパフォーマンスが大幅に低下します。バージョン 5.2.0 より前のバージョンでは、TiDB は`ServerIsBusy`に遭遇すると、 `write stall`エラーをクライアントに直接返すことで、すべての書き込み要求をブロックしようとしますが、これにより QPS パフォーマンスが急激に低下する可能性があります。バージョン 5.2.0 以降、TiKV は、スケジューリングレイヤーで書き込み要求を動的に遅延させることで書き込みを抑制する新しいフロー制御メカニズムを導入し、 `server is busy`が発生したときにクライアントに`write stall`を返す以前のメカニズムに取って代わります。新しいフロー制御メカニズムはデフォルトで有効になっており、TiKV は`write stall`および`KvDB` (memtable を除く) の`RaftDB`メカニズムを自動的に無効にします。ただし、保留中のリクエスト数が一定のしきい値を超えると、フロー制御メカニズムは引き続き有効になり、一部またはすべての書き込みリクエストを拒否し、 `server is busy`エラーをクライアントに返します。詳細な説明としきい値については、 [フロー制御構成](/tikv-configuration-file.md#storageflow-control)を参照してください。 + TiKV インスタンスには 2つの RocksDB インスタンスがあり、1つは`data/raft`にありRaftログを格納し、もう 1つは`data/db`にあり実際のデータを格納します。ログで`grep "Stalling" RocksDB`を実行すると、停止の具体的な原因を確認できます。RocksDB ログは`LOG`で始まるファイルで、 `LOG`が現在のログです。 `write stall`は RocksDB にネイティブに組み込まれたパフォーマンス低下メカニズムです。RocksDB で`write stall`が発生すると、システムのパフォーマンスが大幅に低下します。バージョン 5.2.0 より前のバージョンでは、TiDB は`ServerIsBusy`に遭遇すると、 `write stall`エラーをクライアントに直接返すことで、すべての書き込みリクエストをブロックしようとしますが、これにより QPS パフォーマンスが急激に低下する可能性があります。バージョン 5.2.0 以降、TiKV は、スケジューリングレイヤーで書き込みリクエストを動的に遅延させることで書き込みを抑制する新しいフロー制御メカニズムを導入し、 `server is busy`が発生したときにクライアントに`write stall`を返す以前のメカニズムに取って代わります。新しいフロー制御メカニズムはデフォルトで有効になっており、TiKV は`write stall`および`KvDB` (memtable を除く) の`RaftDB`メカニズムを自動的に無効にします。ただし、保留中のリクエスト数が一定のしきい値を超えると、フロー制御メカニズムは引き続き有効になり、一部またはすべての書き込みリクエストを拒否し、 `server is busy`エラーをクライアントに返します。詳細な説明としきい値については、 [フロー制御構成](/tikv-configuration-file.md#storageflow-control)を参照してください。 - `server is busy`エラーが、保留中の圧縮バイト数が多すぎるために発生する場合は、 [`soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)および[`hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit)パラメータの値を増やすことで、この問題を軽減できます。 - - 保留中の圧縮バイト数が`soft-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`192GiB` ) に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し始めます ( `ServerIsBusy`をクライアントに返します)。この場合、このパラメータの値を増やすことができます。たとえば、 `[storage.flow-control] soft-pending-compaction-bytes-limit = "384GiB"`のようにです。 + - 保留中の圧縮バイト数が`soft-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`192GiB` ) に達すると、フロー制御メカニズムは一部の書き込みリクエストを拒否し始めます ( `ServerIsBusy`をクライアントに返します)。この場合、このパラメータの値を増やすことができます。たとえば、 `[storage.flow-control] soft-pending-compaction-bytes-limit = "384GiB"`のようにです。 - - 保留中の圧縮バイト数が`hard-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`1024GiB` ) に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し始めます ( `ServerIsBusy`をクライアントに返します)。フロー制御メカニズムは`soft-pending-compaction-bytes-limit`のしきい値に達した後に書き込み速度を遅くするため、このシナリオが発生する可能性は低くなります。発生した場合は、このパラメータの値を増やすことができます (たとえば`[storage.flow-control] hard-pending-compaction-bytes-limit = "2048GiB"`など)。 + - 保留中の圧縮バイト数が`hard-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`1024GiB` ) に達すると、フロー制御メカニズムはすべての書き込みリクエストを拒否し始めます ( `ServerIsBusy`をクライアントに返します)。フロー制御メカニズムは`soft-pending-compaction-bytes-limit`のしきい値に達した後に書き込み速度を遅くするため、このシナリオが発生する可能性は低くなります。発生した場合は、このパラメータの値を増やすことができます (たとえば`[storage.flow-control] hard-pending-compaction-bytes-limit = "2048GiB"`など)。 - ディスクのI/O容量が長時間にわたって書き込み速度に追いつかない場合は、ディスクの容量を増やすことをお勧めします。ディスクのスループットが上限に達し、書き込みが停止する場合（例えば、SATA SSDはNVMe SSDよりも大幅に低い）、CPUリソースが十分であれば、より高い圧縮率の圧縮アルゴリズムを適用することができます。こうすることで、CPUリソースをディスクリソースに振り向け、ディスクへの負荷を軽減できます。 @@ -501,7 +501,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 7.1.2 `coprocessor.go`は`request outdated`を報告します。 - このエラーは、TiKVに送信されたコプロセッサ要求がTiKVのキューで60秒以上待機した場合に返されます。 + このエラーは、TiKVに送信されたコプロセッサリクエストがTiKVのキューで60秒以上待機した場合に返されます。 TiKVコプロセッサが長いキューに入っている理由を調査する必要があります。 @@ -528,7 +528,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 7.2.1 `key is locked` 。 - 読み取りと書き込みが競合しています。読み取り要求は、コミットされていないデータに遭遇したため、データがコミットされるまで待機する必要があります。 + 読み取りと書き込みが競合しています。読み取りリクエストは、コミットされていないデータに遭遇したため、データがコミットされるまで待機する必要があります。 このエラーの発生件数が少ない場合は業務に影響はありませんが、発生件数が多い場合は、業務において読み書きの競合が深刻であることを示しています。 diff --git a/tiflash-performance-tuning-methods.md b/tiflash-performance-tuning-methods.md index 594dc85f3b460..e674291698e72 100644 --- a/tiflash-performance-tuning-methods.md +++ b/tiflash-performance-tuning-methods.md @@ -28,11 +28,11 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ 次のメトリックを使用して、 TiFlashのスループットを取得できます。 - MPP クエリ数: 各TiFlashインスタンスの MPP クエリ数の瞬間値。TiFlashで処理する必要がある現在の MPP クエリ数 (処理中のクエリとスケジュール待ちのクエリを含む) を反映します。 -- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。 - - `run_mpp_task` 、および`mpp_establish_conn` `dispatch_mpp_task` MPP 要求です。 +- リクエスト QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサリクエストの数。 + - `run_mpp_task` 、および`mpp_establish_conn` `dispatch_mpp_task` MPP リクエストです。 - `batch` : バッチリクエストの数。 - - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサ要求の数。 - - `cop_execution` : 現在実行中のコプロセッサ要求の数。 + - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサリクエストの数。 + - `cop_execution` : 現在実行中のコプロセッサリクエストの数。 - `remote_read` `remote_read_sent`リモート読み取り関連のメトリックです。リモート読み取りの増加は通常`remote_read_constructed`システムに問題があることを示しています。 - Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG オペレーターの数。`table_scan`はテーブルスキャンオペレーター、 `selection`は選択オペレーター、 `aggregation`は集約オペレーター、 `top_n`は TopN オペレーター、 `limit`は制限オペレーター、 `join`は結合オペレーター、 `exchange_sender`はデータ送信オペレーター、 `exchange_receiver`はデータ受信オペレーターです。 @@ -48,13 +48,13 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ - SQL文によってクエリされるデータの量が大きい場合、オプティマイザはコストモデルに従って、 TiFlash のフルテーブルスキャンの方がコスト効率が高いと見積もる場合があります。 - クエリ対象のテーブルのスキーマに適切なインデックスがない場合、クエリ対象のデータ量が少ない場合でも、オプティマイザはクエリをTiFlashにプッシュダウンしてテーブル全体をスキャンするしかありません。このような場合、適切なインデックスを作成し、TiKVを介してデータにアクセスする方が効率的です。 -- 要求期間: すべてのTiFlashインスタンス内の各 MPP およびコプロセッサ要求タイプの合計処理期間。これには平均レイテンシーと p99レイテンシーが含まれます。 +- リクエスト期間: すべてのTiFlashインスタンス内の各 MPP およびコプロセッサリクエストタイプの合計処理期間。これには平均レイテンシーと p99レイテンシーが含まれます。 - リクエスト処理時間: `cop`と`batch cop`リクエストの実行開始から完了までの時間（待機時間を除く）。この指標は、平均レイテンシーとP99レイテンシーを含む、 `cop`と`batch cop`リクエストにのみ適用されます。 例1: TiFlash MPPリクエストの処理時間の概要 -次の図のワークロードでは、 `run_mpp_task`と`mpp_establish_conn`要求が合計処理時間の大部分を占めており、要求のほとんどが実行のためにTiFlashに完全にプッシュダウンされる MPP タスクであることがわかります。 +次の図のワークロードでは、 `run_mpp_task`と`mpp_establish_conn`リクエストが合計処理時間の大部分を占めており、リクエストのほとんどが実行のためにTiFlashに完全にプッシュダウンされる MPP タスクであることがわかります。 `cop`リクエストの処理時間は比較的短いため、リクエストの一部はデータアクセスとコプロセッサを介したフィルタリングのためにTiFlashにプッシュダウンされていることがわかります。 diff --git a/tiflash/maintain-tiflash.md b/tiflash/maintain-tiflash.md index 69eb7a21de1b5..b85f1cb577a17 100644 --- a/tiflash/maintain-tiflash.md +++ b/tiflash/maintain-tiflash.md @@ -32,10 +32,10 @@ TiFlash のバージョンを確認するには、次の2つの方法があり | ログ情報 | ログの説明 | | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------- | | `[INFO] [] ["KVStore: Start to persist [region 47, applied: term 6 index 10]"] [thread_id=23]` | データの複製が開始されます（ログの先頭の角括弧内の数字はスレッドIDを表します） | -| `[DEBUG] [] ["CoprocessorHandler: grpc::Status DB::CoprocessorHandler::execute(): Handling DAG request"] [thread_id=30]` | DAG要求の処理、つまりTiFlashがコプロセッサー要求の処理を開始する | -| `[DEBUG] [] ["CoprocessorHandler: grpc::Status DB::CoprocessorHandler::execute(): Handle DAG request done"] [thread_id=30]` | DAG要求の処理が完了しました。つまり、 TiFlashがコプロセッサー要求の処理を完了しました。 | +| `[DEBUG] [] ["CoprocessorHandler: grpc::Status DB::CoprocessorHandler::execute(): Handling DAG request"] [thread_id=30]` | DAGリクエストの処理、つまりTiFlashがコプロセッサーリクエストの処理を開始する | +| `[DEBUG] [] ["CoprocessorHandler: grpc::Status DB::CoprocessorHandler::execute(): Handle DAG request done"] [thread_id=30]` | DAGリクエストの処理が完了しました。つまり、 TiFlashがコプロセッサーリクエストの処理を完了しました。 | -コプロセッサー要求の開始または終了を見つけ、ログの先頭に印刷されているスレッド ID を通じてコプロセッサー要求の関連ログを見つけることができます。 +コプロセッサーリクエストの開始または終了を見つけ、ログの先頭に印刷されているスレッド ID を通じてコプロセッサーリクエストの関連ログを見つけることができます。 ## TiFlashシステムテーブル {#tiflash-system-table} diff --git a/tiflash/monitor-tiflash.md b/tiflash/monitor-tiflash.md index a94df401c7538..e7fe47f225323 100644 --- a/tiflash/monitor-tiflash.md +++ b/tiflash/monitor-tiflash.md @@ -37,14 +37,14 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## コプロセッサー {#coprocessor} -- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。`batch`はバッチ要求の数です。`batch_cop`はバッチ要求内のコプロセッサ要求の数です。`cop`はコプロセッサ インターフェイスを介して直接送信されたコプロセッサ要求の数です。`cop_dag`はすべてのコプロセッサ要求内の DAG 要求の数です。`super_batch`はスーパー バッチ機能を有効にするための要求の数です。 +- リクエスト QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサリクエストの数。`batch`はバッチリクエストの数です。`batch_cop`はバッチリクエスト内のコプロセッサリクエストの数です。`cop`はコプロセッサ インターフェイスを介して直接送信されたコプロセッサリクエストの数です。`cop_dag`はすべてのコプロセッサリクエスト内の DAG リクエストの数です。`super_batch`はスーパー バッチ機能を有効にするためのリクエストの数です。 - Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。`table_scan`はテーブルスキャン Executor です。`selection`は選択 Executor です。`aggregation`は集約 Executor です。`top_n`は`TopN` Executor です。`limit`は制限 Executor です。 - リクエスト期間: コプロセッサリクエストを処理するすべてのTiFlashインスタンスの合計期間。合計期間は、コプロセッサリクエストを受信してからリクエストへの応答が完了するまでの期間です。 -- エラー QPS: コプロセッサ要求を処理するすべてのTiFlashインスタンスのエラー数。`meet_lock`は読み取りデータがロックされていることを意味します。`region_not_found`はリージョンが存在しないことを意味します。`epoch_not_match`は読み取りリージョンエポックがローカル エポックと一致していないことを意味します。`kv_client_error`はTiKV との通信でエラーが返されたことを意味します。`internal_error`はTiFlashの内部システム エラーです。`other`はその他のタイプのエラーです。 +- エラー QPS: コプロセッサリクエストを処理するすべてのTiFlashインスタンスのエラー数。`meet_lock`は読み取りデータがロックされていることを意味します。`region_not_found`はリージョンが存在しないことを意味します。`epoch_not_match`は読み取りリージョンエポックがローカル エポックと一致していないことを意味します。`kv_client_error`はTiKV との通信でエラーが返されたことを意味します。`internal_error`はTiFlashの内部システム エラーです。`other`はその他のタイプのエラーです。 - リクエスト処理期間：すべてのTiFlashインスタンスがコプロセッサリクエストを処理する期間。処理時間は、コプロセッサリクエストの実行開始から完了までです。 - 応答バイト/秒: すべてのTiFlashインスタンスからの応答の合計バイト数。 -- Cop タスクのメモリ使用量: コプロセッサ要求を処理するすべてのTiFlashインスタンスの合計メモリ使用量。 -- 処理要求数: コプロセッサ要求を処理しているすべてのTiFlashインスタンスの総数。要求の分類は、要求QPSと同じです。 +- Cop タスクのメモリ使用量: コプロセッサリクエストを処理するすべてのTiFlashインスタンスの合計メモリ使用量。 +- 処理リクエスト数: コプロセッサリクエストを処理しているすべてのTiFlashインスタンスの総数。リクエストの分類は、リクエストQPSと同じです。 - RPC スレッド: 各TiFlashインスタンスで使用される RPC スレッドのリアルタイム数。 - RPC の最大スレッド数: 各TiFlashインスタンスで最近使用された RPC スレッドの最大数。 - スレッド: 各TiFlashインスタンスで使用されるスレッドのリアルタイム数。 @@ -68,7 +68,7 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## ストレージ {#storage} -- 書き込みコマンド OPS: すべてのTiFlashインスタンスのストレージレイヤーで 1秒あたりに受信される書き込み要求の数。 +- 書き込みコマンド OPS: すべてのTiFlashインスタンスのストレージレイヤーで 1秒あたりに受信される書き込みリクエストの数。 - 書き込み増幅: 各TiFlashインスタンスの書き込み増幅 (実際のディスク書き込みバイト数を論理データの書き込みバイト数で割った値)。`total`はこの開始以降の書き込み増幅で、 `5min`は過去 5分間の書き込み増幅です。 - 読み取りタスク OPS: TiFlashインスタンスごとのストレージレイヤーでの 1秒あたりの読み取りタスクの数。 - 粗セット フィルタ レート: ストレージストレージの粗セットレイヤーによってフィルタされた、過去 1分間に各TiFlashインスタンスによって読み取られたパケット数の割合。 @@ -103,4 +103,4 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas - 読み取りインデックス OPS: 各TiFlashインスタンスが`read_index`回のリクエストをトリガーする回数。これはトリガーされたリージョンの数に等しくなります。 - インデックス読み取り時間: すべてのTiFlashインスタンスの`read_index`が使用する時間。ほとんどの時間は、リージョンリーダーとのやり取りと再試行に使用されます。 -- インデックス待機期間: すべてのTiFlashインスタンスに対して`wait_index`が使用する時間。つまり、 `read_index`要求を受信した後、ローカルインデックス >= read_index になるまで待機する時間です。 +- インデックス待機期間: すべてのTiFlashインスタンスに対して`wait_index`が使用する時間。つまり、 `read_index`リクエストを受信した後、ローカルインデックス >= read_index になるまで待機する時間です。 diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 7228f8bb2a0ad..e50f330ec3eef 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -140,29 +140,29 @@ I/O トラフィック制限設定を構成します。 -- TiFlashは内部的にI/O要求を4つのタイプに分類します。フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取りです。`foreground_write_weight`はフォアグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は`foreground_write_weight` 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類の要求に帯域幅を割り当てます。 +- TiFlashは内部的にI/Oリクエストを4つのタイプに分類します。フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取りです。`foreground_write_weight`はフォアグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- I/O トラフィック制限が初期化されると、 TiFlash は`foreground_write_weight` 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類のリクエストに帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `background_write_weight` {#background_write_weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_write_weight`は、バックグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 `background_write_weight` 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類の要求に帯域幅を割り当てます。 +- TiFlashは内部的にI/Oリクエストを4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_write_weight`は、バックグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 `background_write_weight` 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類のリクエストに帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `foreground_read_weight` {#foreground_read_weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`foreground_read_weight`は、フォアグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 `foreground_read_weight` 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類の要求に帯域幅を割り当てます。 +- TiFlashは内部的にI/Oリクエストを4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`foreground_read_weight`は、フォアグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 `foreground_read_weight` 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類のリクエストに帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `background_read_weight` {#background_read_weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_read_weight`は、バックグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 `background_read_weight`の比率に従って、これら4種類の要求に帯域幅を割り当てます。 +- TiFlashは内部的にI/Oリクエストを4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_read_weight`は、バックグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 `background_read_weight`の比率に従って、これら4種類のリクエストに帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 @@ -382,7 +382,7 @@ I/O トラフィック制限設定を構成します。 ##### `cop_pool_max_queued_seconds`バージョン5.0の新機能 {#cop_pool_max_queued_seconds-new-in-v50} -- cop要求がTiFlashにキューイングできる最大時間を指定します。cop要求がこの設定で指定された値よりも長くキュー内で待機した場合、エラー`TiFlash Server is Busy`が返されます。 +- copリクエストがTiFlashにキューイングできる最大時間を指定します。copリクエストがこの設定で指定された値よりも長くキュー内で待機した場合、エラー`TiFlash Server is Busy`が返されます。 - `0`以下の値は制限がないことを示します。 - デフォルト値: `15` @@ -393,7 +393,7 @@ I/O トラフィック制限設定を構成します。 ##### `manual_compact_pool_size`バージョン6.1の新機能 {#manual_compact_pool_size-new-in-v61} -- TiFlash がTiDB から`ALTER TABLE ... COMPACT`を受信したときに同時に処理できる要求の数を指定します。 +- TiFlash がTiDB から`ALTER TABLE ... COMPACT`を受信したときに同時に処理できるリクエストの数を指定します。 - 値が`0`に設定されている場合、デフォルト値`1`が優先されます。 - デフォルト値: `1` diff --git a/tiflash/tiflash-mintso-scheduler.md b/tiflash/tiflash-mintso-scheduler.md index 01710ad73c9f0..d49e49fddbb62 100644 --- a/tiflash/tiflash-mintso-scheduler.md +++ b/tiflash/tiflash-mintso-scheduler.md @@ -11,13 +11,13 @@ TiFlash MinTSOスケジューラは、 TiFlash内の[MPP](/glossary.md#massively MPPクエリを処理する際、TiDBはクエリを1つ以上のMPPタスクに分割し、これらのMPPタスクを対応するTiFlashノードに送信してコンパイルおよび実行します。TiFlashが[パイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用する前に、各MPPタスクを実行するために複数のスレッドを使用する必要があります。具体的なスレッド数は、MPPタスクの複雑さとTiFlashに設定された同時実行パラメータによって異なります。 -同時実行性の高いシナリオでは、 TiFlashノードは複数のMPPタスクを同時に受信します。MPPタスクの実行が制御されていない場合、 TiFlashがシステムに要求する必要があるスレッド数は、MPPタスク数の増加に伴って直線的に増加します。スレッド数が多すぎるとTiFlashの実行効率に影響を与える可能性があります。また、オペレーティングシステム自体がサポートするスレッド数には制限があるため、オペレーティングシステムが提供できる以上のスレッドをTiFlashが要求するとエラーが発生します。 +同時実行性の高いシナリオでは、 TiFlashノードは複数のMPPタスクを同時に受信します。MPPタスクの実行が制御されていない場合、 TiFlashがシステムにリクエストする必要があるスレッド数は、MPPタスク数の増加に伴って直線的に増加します。スレッド数が多すぎるとTiFlashの実行効率に影響を与える可能性があります。また、オペレーティングシステム自体がサポートするスレッド数には制限があるため、オペレーティングシステムが提供できる以上のスレッドをTiFlashがリクエストするとエラーが発生します。 高い同時実行性が必要なシナリオで TiFlash の処理能力を向上させるには、 TiFlashに MPP タスク スケジューラを導入する必要があります。 ## 実装原理 {#implementation-principles} -[背景](#background)で述べたように、 TiFlashタスクスケジューラを導入する当初の目的は、MPP クエリ実行中に使用されるスレッド数を制御することです。シンプルなスケジューリング戦略は、 TiFlash が要求できる最大スレッド数を指定することです。スケジューラは、各 MPP タスクについて、システムで現在使用されているスレッド数と、MPP タスクが使用すると予想されるスレッド数に基づいて、その MPP タスクをスケジュールできるかどうかを判断します。 +[背景](#background)で述べたように、 TiFlashタスクスケジューラを導入する当初の目的は、MPP クエリ実行中に使用されるスレッド数を制御することです。シンプルなスケジューリング戦略は、 TiFlash がリクエストできる最大スレッド数を指定することです。スケジューラは、各 MPP タスクについて、システムで現在使用されているスレッド数と、MPP タスクが使用すると予想されるスレッド数に基づいて、その MPP タスクをスケジュールできるかどうかを判断します。 ![TiFlash MinTSO Scheduler v1](/media/tiflash/tiflash_mintso_v1.png) diff --git a/tiflash/tiflash-overview.md b/tiflash/tiflash-overview.md index c3a561ab2a83e..9ee9c6ffb9e75 100644 --- a/tiflash/tiflash-overview.md +++ b/tiflash/tiflash-overview.md @@ -63,7 +63,7 @@ TiFlash内のレプリカは、特別なロールであるRaft Learnerとして TiFlashはTiKVと同じスナップショット分離レベルの一貫性を提供し、最新のデータが読み取られることを保証します。つまり、TiKVに以前書き込まれたデータを読み取ることができます。このような一貫性は、データレプリケーションの進行状況を検証することで実現されます。 -TiFlash が読み取り要求を受信するたびに、リージョンレプリカはLeaderレプリカに進行状況検証要求（軽量 RPC 要求）を送信します。TiFlashは、読み取り要求のタイムスタンプに含まれるデータが現在のレプリケーション進行状況に含まれた場合にのみ、読み取り操作を実行します。 +TiFlash が読み取りリクエストを受信するたびに、リージョンレプリカはLeaderレプリカに進行状況検証リクエスト（軽量 RPC リクエスト）を送信します。TiFlashは、読み取りリクエストのタイムスタンプに含まれるデータが現在のレプリケーション進行状況に含まれた場合にのみ、読み取り操作を実行します。 ### 賢い選択 {#intelligent-choice} diff --git a/tiflash/tiflash-pipeline-model.md b/tiflash/tiflash-pipeline-model.md index 49eaf65860189..d4f067d70fcad 100644 --- a/tiflash/tiflash-pipeline-model.md +++ b/tiflash/tiflash-pipeline-model.md @@ -36,7 +36,7 @@ TiFlashのオリジナルのストリームモデルは、スレッドスケジ - パイプラインクエリ実行ツール - パイプラインクエリ実行エンジンは、TiDBノードから送信されたクエリ要求をパイプライン有向非巡回グラフ（DAG）に変換します。 + パイプラインクエリ実行エンジンは、TiDBノードから送信されたクエリリクエストをパイプライン有向非巡回グラフ（DAG）に変換します。 クエリ内のパイプラインブレーカーオペレーターを検出し、それらのオペレーターに基づいてクエリを複数のパイプラインに分割します。次に、パイプライン間の依存関係に基づいて、それらのパイプラインをDAG（有向非巡回グラフ）に組み立てます。 diff --git a/tiflash/tiflash-results-materialization.md b/tiflash/tiflash-results-materialization.md index b6161e142bdad..a954a3a6fb16f 100644 --- a/tiflash/tiflash-results-materialization.md +++ b/tiflash/tiflash-results-materialization.md @@ -43,7 +43,7 @@ SELECT app_name, country FROM t1; - 効率的なBIソリューション - 多くの BI アプリケーションでは、分析クエリ要求が非常に重くなります。たとえば、多くのユーザーが同時にレポートにアクセスして更新する場合、BI アプリケーションは大量の同時クエリ要求を処理する必要があります。この状況に効果的に対処するには、 `INSERT INTO SELECT`を使用してレポートのクエリ結果を TiDB テーブルに保存します。その後、エンドユーザーはレポートが更新されたときに結果テーブルから直接データをクエリできるため、計算と分析が何度も繰り返されるのを回避できます。同様に、履歴分析結果を保存することで、長時間の履歴データ分析の計算量をさらに削減できます。たとえば、日次売上利益を分析するために使用されるレポート`A`がある場合、 `INSERT INTO SELECT`を使用してレポート`A`の結果を結果テーブル`T`に保存できます。その後、先月の売上利益を分析するためにレポート`B`を生成する必要がある場合は、テーブル`T`の日次分析結果を直接使用できます。この方法は、計算量を大幅に削減するだけでなく、クエリ応答速度を向上させ、システム負荷を軽減します。 + 多くの BI アプリケーションでは、分析クエリリクエストが非常に重くなります。たとえば、多くのユーザーが同時にレポートにアクセスして更新する場合、BI アプリケーションは大量の同時クエリリクエストを処理する必要があります。この状況に効果的に対処するには、 `INSERT INTO SELECT`を使用してレポートのクエリ結果を TiDB テーブルに保存します。その後、エンドユーザーはレポートが更新されたときに結果テーブルから直接データをクエリできるため、計算と分析が何度も繰り返されるのを回避できます。同様に、履歴分析結果を保存することで、長時間の履歴データ分析の計算量をさらに削減できます。たとえば、日次売上利益を分析するために使用されるレポート`A`がある場合、 `INSERT INTO SELECT`を使用してレポート`A`の結果を結果テーブル`T`に保存できます。その後、先月の売上利益を分析するためにレポート`B`を生成する必要がある場合は、テーブル`T`の日次分析結果を直接使用できます。この方法は、計算量を大幅に削減するだけでなく、クエリ応答速度を向上させ、システム負荷を軽減します。 - TiFlashによるオンラインアプリケーションの提供 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 4d2c35974b467..ad3d66f06e97a 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -237,7 +237,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ### `end-point-request-max-handle-duration` {#end-point-request-max-handle-duration} -- TiDBからTiKVへの処理タスクのプッシュダウン要求に許容される最長期間 +- TiDBからTiKVへの処理タスクのプッシュダウンリクエストに許容される最長期間 - デフォルト値: `"60s"` - 最小値: `"1s"` @@ -283,7 +283,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ### `end-point-slow-log-threshold` {#end-point-slow-log-threshold} -- TiDBのプッシュダウン要求がスローログを出力するまでの時間しきい値。処理時間がこのしきい値を超えると、スローログが出力されます。 +- TiDBのプッシュダウンリクエストがスローログを出力するまでの時間しきい値。処理時間がこのしきい値を超えると、スローログが出力されます。 - デフォルト値: `"1s"` - 最小値: `0` @@ -311,7 +311,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ## readpool.unified {#readpoolunified} -読み取り要求を処理するシングルスレッドプールに関連するコンフィグレーション項目。このスレッドプールは、バージョン4.0以降、従来のストレージスレッドプールとコプロセッサスレッドプールに取って代わるものです。 +読み取りリクエストを処理するシングルスレッドプールに関連するコンフィグレーション項目。このスレッドプールは、バージョン4.0以降、従来のストレージスレッドプールとコプロセッサスレッドプールに取って代わるものです。 ### `min-thread-count` {#min-thread-count} @@ -369,7 +369,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ### `use-unified-pool` {#use-unified-pool-1} -- ストレージ要求に統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメーターの値が`false`の場合、このセクションの残りのパラメーター（ `readpool.storage` ）で構成された別のスレッドプールが使用されます。 +- ストレージリクエストに統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメーターの値が`false`の場合、このセクションの残りのパラメーター（ `readpool.storage` ）で構成された別のスレッドプールが使用されます。 - デフォルト値: このセクション ( `readpool.storage` ) に他の設定がない場合、デフォルト値は`true`です。それ以外の場合は、下位互換性のために、デフォルト値は`false`です。このオプションを有効にする前に、必要に応じて[`readpool.unified`](#readpoolunified)の設定を変更してください。 ### `high-concurrency` {#high-concurrency-1} @@ -423,24 +423,24 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ### `use-unified-pool` {#use-unified-pool} -- コプロセッサ要求に統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメータの値が`false`の場合、このセクションの残りのパラメータ（ `readpool.coprocessor` ）で構成された別のスレッドプールが使用されます。 +- コプロセッサリクエストに統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメータの値が`false`の場合、このセクションの残りのパラメータ（ `readpool.coprocessor` ）で構成された別のスレッドプールが使用されます。 - デフォルト値: このセクションのパラメータ ( `readpool.coprocessor` ) がいずれも設定されていない場合、デフォルト値は`true`です。それ以外の場合は、下位互換性のためにデフォルト値は`false`になります。このパラメータを有効にする前に、 [`readpool.unified`](#readpoolunified)の設定項目を調整してください。 ### `high-concurrency` {#high-concurrency} -- チェックポイントなどの優先度の高いコプロセッサー要求を処理する同時実行スレッドの許容数 +- チェックポイントなどの優先度の高いコプロセッサーリクエストを処理する同時実行スレッドの許容数 - デフォルト値: `CPU * 0.8` - 最小値: `1` ### `normal-concurrency` {#normal-concurrency} -- 通常優先度のコプロセッサー要求を処理する同時実行スレッドの許容数 +- 通常優先度のコプロセッサーリクエストを処理する同時実行スレッドの許容数 - デフォルト値: `CPU * 0.8` - 最小値: `1` ### `low-concurrency` {#low-concurrency} -- テーブルスキャンなどの低優先度コプロセッサー要求を処理する同時実行スレッドの許容数 +- テーブルスキャンなどの低優先度コプロセッサーリクエストを処理する同時実行スレッドの許容数 - デフォルト値: `CPU * 0.8` - 最小値: `1` @@ -513,7 +513,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ### `enable-async-apply-prewrite` {#enable-async-apply-prewrite} -- 非同期コミットトランザクションが、プリライト要求を適用する前にTiKVクライアントに応答するかどうかを決定します。この設定項目を有効にすると、適用時間が長い場合はレイテンシーを容易に短縮でき、適用時間が不安定な場合は遅延ジッターを低減できます。 +- 非同期コミットトランザクションが、プリライトリクエストを適用する前にTiKVクライアントに応答するかどうかを決定します。この設定項目を有効にすると、適用時間が長い場合はレイテンシーを容易に短縮でき、適用時間が不安定な場合は遅延ジッターを低減できます。 - デフォルト値: `false` ### `reserve-space` {#reserve-space} @@ -617,7 +617,7 @@ TiKVにおけるフロー制御メカニズムに関連するコンフィグレ ### `soft-pending-compaction-bytes-limit` {#soft-pending-compaction-bytes-limit-1} -- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し始め、 `ServerIsBusy`エラーを報告します。 +- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムは一部の書き込みリクエストを拒否し始め、 `ServerIsBusy`エラーを報告します。 > **Note:** > @@ -627,7 +627,7 @@ TiKVにおけるフロー制御メカニズムに関連するコンフィグレ ### `hard-pending-compaction-bytes-limit` {#hard-pending-compaction-bytes-limit-1} -- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。 `enable`が`true`に設定されている場合、この設定項目は`rocksdb.(defaultcf|writecf|lockcf).hard-pending-compaction-bytes-limit`を上書きします。 +- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムはすべての書き込みリクエストを拒否し、 `ServerIsBusy`エラーを報告します。 `enable`が`true`に設定されている場合、この設定項目は`rocksdb.(defaultcf|writecf|lockcf).hard-pending-compaction-bytes-limit`を上書きします。 - デフォルト値: `"1024GiB"` ## storage.io-rate-limit {#storageio-rate-limit} @@ -1114,7 +1114,7 @@ Raftstoreに関連するコンフィグレーション項目。 ### `apply-max-batch-size` {#apply-max-batch-size} -- Raftステートマシンは、BatchSystemによってデータ書き込み要求をバッチ処理します。この設定項目は、1つのバッチで要求を処理できるRaftステートマシンの最大数を指定します。 +- Raftステートマシンは、BatchSystemによってデータ書き込みリクエストをバッチ処理します。この設定項目は、1つのバッチでリクエストを処理できるRaftステートマシンの最大数を指定します。 - デフォルト値: `256` - 最小値: `0`より大きい - 最大値: `10240` @@ -1127,7 +1127,7 @@ Raftstoreに関連するコンフィグレーション項目。 ### `store-max-batch-size` {#store-max-batch-size} -- Raftステートマシンは、BatchSystemによってログをディスクに書き込む要求をバッチ処理します。この設定項目は、1つのバッチで要求を処理できるRaftステートマシンの最大数を指定します。 +- Raftステートマシンは、BatchSystemによってログをディスクに書き込むリクエストをバッチ処理します。この設定項目は、1つのバッチでリクエストを処理できるRaftステートマシンの最大数を指定します。 - `hibernate-regions`が有効になっている場合、デフォルト値は`256`です。 `hibernate-regions`が無効になっている場合、デフォルト値は`1024`です。 - 最小値: `0`より大きい - 最大値: `10240` @@ -2388,12 +2388,12 @@ TiKVの自動圧縮の動作を設定します。 ### `mvcc-read-aware-enabled` v8.5.6の新機能 {#mvcc-read-aware-enabled-new-in-v856} -- MVCC読み取り対応の圧縮を有効にするかどうかを制御します。有効にすると、TiKVは読み取り要求中にスキャンされたMVCCバージョンの数を追跡し、この情報を使用して、MVCC読み取り増幅率の高いリージョンに対して圧縮を優先します。これにより、スキャン中に多くの古いバージョンに遭遇するホットリージョンの読み取りレイテンシーが削減されます。 +- MVCC読み取り対応の圧縮を有効にするかどうかを制御します。有効にすると、TiKVは読み取りリクエスト中にスキャンされたMVCCバージョンの数を追跡し、この情報を使用して、MVCC読み取り増幅率の高いリージョンに対して圧縮を優先します。これにより、スキャン中に多くの古いバージョンに遭遇するホットリージョンの読み取りレイテンシーが削減されます。 - デフォルト値: `false` ### `mvcc-scan-threshold` v8.5.6で追加 {#mvcc-scan-threshold-new-in-v856} -- リージョンを圧縮候補としてマークするために、読み取り要求ごとにスキャンされる MVCC バージョンの最小数。この設定項目は、 [`mvcc-read-aware-enabled`](#mvcc-read-aware-enabled-new-in-v856)が`true`に設定されている場合にのみ有効になります。 +- リージョンを圧縮候補としてマークするために、読み取りリクエストごとにスキャンされる MVCC バージョンの最小数。この設定項目は、 [`mvcc-read-aware-enabled`](#mvcc-read-aware-enabled-new-in-v856)が`true`に設定されている場合にのみ有効になります。 - デフォルト値: `1000` - 最小値: `0` @@ -2627,11 +2627,11 @@ TiCDCに関連するコンフィグレーション項目。 フォアグラウンドのクォータリミッターに関連するコンフィグレーション項目。 -TiKV がデプロイされているマシンにリソースが限られている場合、たとえば、CPU が 4V、メモリが16GB しかないとします。このような状況では、TiKV のフォアグラウンドが読み書き要求を過剰に処理し、バックグラウンドで使用される CPU リソースがこれらの要求の処理に占有され、TiKV のパフォーマンスの安定性に影響する可能性があります。この状況を回避するには、フォアグラウンドのクォータ関連の設定項目を使用して、フォアグラウンドで使用される CPU リソースを制限できます。要求がクォータ リミッターをトリガーすると、要求は TiKV が CPU リソースを解放するまでしばらく待機させられます。正確な待機時間は要求の数によって異なり、最大待機時間は[`max-delay-duration`](#max-delay-duration-new-in-v600)の値を超えません。 +TiKV がデプロイされているマシンにリソースが限られている場合、たとえば、CPU が 4V、メモリが16GB しかないとします。このような状況では、TiKV のフォアグラウンドが読み書きリクエストを過剰に処理し、バックグラウンドで使用される CPU リソースがこれらのリクエストの処理に占有され、TiKV のパフォーマンスの安定性に影響する可能性があります。この状況を回避するには、フォアグラウンドのクォータ関連の設定項目を使用して、フォアグラウンドで使用される CPU リソースを制限できます。リクエストがクォータ リミッターをトリガーすると、リクエストは TiKV が CPU リソースを解放するまでしばらく待機させられます。正確な待機時間はリクエストの数によって異なり、最大待機時間は[`max-delay-duration`](#max-delay-duration-new-in-v600)の値を超えません。 #### `foreground-cpu-time` v6.0.0の新機能 {#foreground-cpu-time-new-in-v600} -- TiKVフォアグラウンドが読み取りおよび書き込み要求を処理するために使用するCPUリソースのソフトリミット。 +- TiKVフォアグラウンドが読み取りおよび書き込みリクエストを処理するために使用するCPUリソースのソフトリミット。 - デフォルト値： `0` （制限なしを意味します） - 単位：ミリCPU（例： `1500`は、フォアグラウンドリクエストが1.5VのCPUを消費することを意味します） - 推奨設定: 4 コアを超えるインスタンスの場合は、デフォルト値`0`を使用してください。4 コアのインスタンスの場合は、値を`1000`と`1500`の範囲に設定するとバランスが取れます。2 コアのインスタンスの場合は、値を`1200`より小さくしてください。 @@ -2652,7 +2652,7 @@ TiKV がデプロイされているマシンにリソースが限られている バックグラウンドクォータリミッターに関連するコンフィグレーション項目。 -TiKV がデプロイされているマシンにリソースが限られている場合、たとえば CPU が 4V、メモリが16GB しかない場合を考えてみましょう。このような状況では、TiKV のバックグラウンドで計算や読み書き要求が多すぎると、フォアグラウンドで使用される CPU リソースがこれらの要求の処理に占有され、TiKV のパフォーマンスの安定性に影響します。この状況を回避するには、バックグラウンドのクォータ関連の設定項目を使用して、バックグラウンドで使用される CPU リソースを制限できます。要求がクォータ リミッターをトリガーすると、TiKV が CPU リソースを解放するまで、要求はしばらく待機させられます。正確な待機時間は要求の数によって異なり、最大待機時間は[`max-delay-duration`](#max-delay-duration-new-in-v600)の値を超えません。 +TiKV がデプロイされているマシンにリソースが限られている場合、たとえば CPU が 4V、メモリが16GB しかない場合を考えてみましょう。このような状況では、TiKV のバックグラウンドで計算や読み書きリクエストが多すぎると、フォアグラウンドで使用される CPU リソースがこれらのリクエストの処理に占有され、TiKV のパフォーマンスの安定性に影響します。この状況を回避するには、バックグラウンドのクォータ関連の設定項目を使用して、バックグラウンドで使用される CPU リソースを制限できます。リクエストがクォータ リミッターをトリガーすると、TiKV が CPU リソースを解放するまで、リクエストはしばらく待機させられます。正確な待機時間はリクエストの数によって異なり、最大待機時間は[`max-delay-duration`](#max-delay-duration-new-in-v600)の値を超えません。 > **Warning:** > @@ -2661,7 +2661,7 @@ TiKV がデプロイされているマシンにリソースが限られている #### `background-cpu-time` v6.2.0の新機能 {#background-cpu-time-new-in-v620} -- TiKVバックグラウンドが読み取りおよび書き込み要求を処理するために使用するCPUリソースのソフトリミット。 +- TiKVバックグラウンドが読み取りおよび書き込みリクエストを処理するために使用するCPUリソースのソフトリミット。 - デフォルト値： `0` （制限なしを意味します） - 単位：ミリCPU（例： `1500`は、バックグラウンドリクエストが1.5VのCPUを消費することを意味します） @@ -2689,7 +2689,7 @@ TiKV API V2 が有効になっている場合にタイムスタンプを取得 ### `alloc-ahead-buffer` v6.4.0で追加 {#alloc-ahead-buffer-new-in-v640} - 事前割り当て済みのTSOキャッシュサイズ（期間）。 -- TiKV は、この設定項目で指定された期間に基づいて TSO キャッシュを事前割り当てします。TiKV は、前の期間に基づいて TSO の使用量を推定し、 `alloc-ahead-buffer`を満たす TSO をローカルに要求してキャッシュします。 +- TiKV は、この設定項目で指定された期間に基づいて TSO キャッシュを事前割り当てします。TiKV は、前の期間に基づいて TSO の使用量を推定し、 `alloc-ahead-buffer`を満たす TSO をローカルにリクエストしてキャッシュします。 - この設定項目は、TiKV API V2 が有効になっている場合の PD 障害の許容度を高めるためによく使用されます ( `storage.api-version = 2` )。 - この設定項目の値を大きくすると、TSOの消費量とTiKVのメモリオーバーヘッドが増加する可能性があります。十分なTSOを確保するには、PDの設定項目[`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval)の値を下げることをお勧めします。 - テストによると、 `alloc-ahead-buffer`がデフォルト値の場合、PDリーダーが故障して別のノードに切り替わると、書き込みリクエストのレイテンシーが一時的に増加し、QPSが約15%減少します。 @@ -2707,14 +2707,14 @@ TiKV API V2 が有効になっている場合にタイムスタンプを取得 ### `renew-batch-min-size` {#renew-batch-min-size} -- タイムスタンプ要求におけるTSOの最小数。 -- TiKV は、前の期間のタイムスタンプ消費量に応じて、キャッシュされたタイムスタンプの数を調整します。必要な TSO が少ない場合は、TiKV は要求される TSO の数を`renew-batch-min-size`に達するまで減らします。アプリケーションで大量のバースト書き込みトラフィックが頻繁に発生する場合は、このパラメータを適切な値に設定できます。このパラメータは、単一の tikv-server のキャッシュサイズであることに注意してください。このパラメータを大きすぎる値に設定し、クラスタに多数の tikv-server が含まれている場合、TSO の消費が速すぎることになります。 +- タイムスタンプリクエストにおけるTSOの最小数。 +- TiKV は、前の期間のタイムスタンプ消費量に応じて、キャッシュされたタイムスタンプの数を調整します。必要な TSO が少ない場合は、TiKV はリクエストされる TSO の数を`renew-batch-min-size`に達するまで減らします。アプリケーションで大量のバースト書き込みトラフィックが頻繁に発生する場合は、このパラメータを適切な値に設定できます。このパラメータは、単一の tikv-server のキャッシュサイズであることに注意してください。このパラメータを大きすぎる値に設定し、クラスタに多数の tikv-server が含まれている場合、TSO の消費が速すぎることになります。 - Grafana の**TiKV-RAW** \> **Causal timestamp**パネルでは、 **TSO バッチサイズ**は、アプリケーションのワークロードに応じて動的に調整されるローカルキャッシュされたタイムスタンプの数です。このメトリックを参照して`renew-batch-min-size`を調整できます。- デフォルト値: `100` ### `renew-batch-max-size` v6.4.0で追加 {#renew-batch-max-size-new-in-v640} -- タイムスタンプ要求におけるTSOの最大数。 -- デフォルトのTSO物理時間更新間隔（ `50ms` ）では、PDは最大262144個のTSOを提供します。要求されたTSOがこの数を超えると、PDはそれ以上TSOを提供しません。この設定項目は、TSOの枯渇と、TSO枯渇が他の業務に及ぼす逆効果を回避するために使用されます。高可用性を向上させるためにこの設定項目の値を増やす場合は、十分なTSOを確保するために、同時に[`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval)の値を減らす必要があります。 +- タイムスタンプリクエストにおけるTSOの最大数。 +- デフォルトのTSO物理時間更新間隔（ `50ms` ）では、PDは最大262144個のTSOを提供します。リクエストされたTSOがこの数を超えると、PDはそれ以上TSOを提供しません。この設定項目は、TSOの枯渇と、TSO枯渇が他の業務に及ぼす逆効果を回避するために使用されます。高可用性を向上させるためにこの設定項目の値を増やす場合は、十分なTSOを確保するために、同時に[`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval)の値を減らす必要があります。 - デフォルト値: `8192` ## resource-metering {#resource-metering} diff --git a/tikv-control.md b/tikv-control.md index 5fd13007a2e5c..72c71ef88e0e6 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -383,7 +383,7 @@ DebugClient::check_region_consistency: RpcFailure(RpcStatus { status: Unknown, d > > - `consistency-check`コマンドは TiDB のガベージコレクションと互換性がなく、誤ってエラーを報告する可能性があるため、使用はお勧めし**ません**。 > - このコマンドはリモートモードのみをサポートします。 -> - このコマンドが`success!`を返した場合でも、TiKVがパニック状態になるかどうかを確認する必要があります。これは、このコマンドがリーダーの整合性チェックを要求するプロポーザルに過ぎず、チェックプロセス全体が成功したかどうかをクライアント側から知ることができないためです。 +> - このコマンドが`success!`を返した場合でも、TiKVがパニック状態になるかどうかを確認する必要があります。これは、このコマンドがリーダーの整合性チェックをリクエストするプロポーザルに過ぎず、チェックプロセス全体が成功したかどうかをクライアント側から知ることができないためです。 ### スナップショットのメタをダンプ {#dump-snapshot-meta} diff --git a/tikv-in-memory-engine.md b/tikv-in-memory-engine.md index ddcfdae63af0b..03cf101457df0 100644 --- a/tikv-in-memory-engine.md +++ b/tikv-in-memory-engine.md @@ -24,10 +24,10 @@ TiKV MVCCインメモリエンジンは、最新の書き込み済みMVCCバー - 左側（インメモリエンジンが無効になっている場合）：テーブルレコードは、主キーに基づいて昇順でRocksDBに格納され、同じ行のすべてのMVCCバージョンが隣接して配置されます。 - 右側（インメモリエンジン有効）：RocksDB内のデータは左側のデータと同じですが、インメモリエンジンは2つの行それぞれについて最新の2つのMVCCバージョンをキャッシュします。 -- TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`8`のスキャン要求を処理する場合： +- TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`8`のスキャンリクエストを処理する場合： - インメモリエンジン（左図）がない場合、11個のMVCCバージョンを処理する必要があります。 - インメモリエンジン（右図）では、処理するMVCCバージョンは4つだけなので、リクエストのレイテンシーとCPU消費量が削減されます。 -- TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`7`のスキャン要求を処理する場合： +- TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`7`のスキャンリクエストを処理する場合： - メモリ内エンジン（右図）に必要な履歴バージョンが欠落しているため、キャッシュが無効になり、TiKVはRocksDBからデータを読み込むようにフォールバックします。 ## 使用法 {#usage} @@ -79,14 +79,14 @@ mvcc-amplification-threshold = 10 - [BR](/br/br-use-overview.md) ：インメモリエンジンはBRと併用できます。ただし、 BRリストア中は、リストア処理に関係するリージョンはインメモリエンジンから削除されます。BRが完了した後、対応するリージョンがホットスポットとして残っている場合は、インメモリエンジンによって自動的にロードされます。 - [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) ：インメモリエンジンはTiDB Lightningと併用できます。ただし、 TiDB Lightningが物理インポートモードで動作する場合、復元プロセスに関係するリージョンはインメモリエンジンから削除されます。物理インポートが完了すると、対応するリージョンがホットスポットとして残っている場合、それらはインメモリエンジンによって自動的にロードされます。 -- [Follower Read](/develop/dev-guide-use-follower-read.md)と[ステイル読み取り](/develop/dev-guide-use-stale-read.md) ：インメモリエンジンは、これら2つの機能と併用できます。ただし、インメモリエンジンはLeader上のコプロセッサ要求のみを高速化でき、Follower Readとステイル読み取り操作を高速化することはできません。 +- [Follower Read](/develop/dev-guide-use-follower-read.md)と[ステイル読み取り](/develop/dev-guide-use-stale-read.md) ：インメモリエンジンは、これら2つの機能と併用できます。ただし、インメモリエンジンはLeader上のコプロセッサリクエストのみを高速化でき、Follower Readとステイル読み取り操作を高速化することはできません。 - [`FLASHBACK CLUSTER`](/sql-statements/sql-statement-flashback-cluster.md) ：インメモリエンジンはFlashbackと併用できます。ただし、Flashbackはインメモリエンジンのキャッシュを無効化します。Flashback処理が完了すると、インメモリエンジンはホットスポット領域を自動的にロードします。 ## FAQ {#faq} ### インメモリエンジンは書き込みレイテンシーを低減し、書き込みスループットを向上させることができるか？ {#can-the-in-memory-engine-reduce-write-latency-and-increase-write-throughput} -いいえ。インメモリエンジンは、多数のMVCCバージョンをスキャンする読み取り要求のみを高速化できます。 +いいえ。インメモリエンジンは、多数のMVCCバージョンをスキャンする読み取りリクエストのみを高速化できます。 ### インメモリエンジンが私のシナリオを改善できるかどうかを判断するにはどうすればよいでしょうか？ {#how-to-determine-if-the-in-memory-engine-can-improve-my-scenario} diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index 18503f64ac74b..695a53d6563de 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -118,7 +118,7 @@ TiProxy の負荷分散ポリシーの構成。 - デフォルト値: `""` - ホットリロードのサポート: はい -- [ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)に使用するラベル名を指定します。TiProxy は、このラベル名に基づいて TiDB サーバーのラベル値を照合し、自分と同じラベル値を持つ TiDB サーバーへのルーティング要求を優先します。 +- [ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)に使用するラベル名を指定します。TiProxy は、このラベル名に基づいて TiDB サーバーのラベル値を照合し、自分と同じラベル値を持つ TiDB サーバーへのルーティングリクエストを優先します。 - デフォルト値の`label-name`は空文字列で、ラベルベースの負荷分散が使用されないことを示します。この負荷分散ポリシーを有効にするには、この設定項目を空でない文字列に設定し、TiProxy で[`labels`](#labels) 、TiDB で[`labels`](/tidb-configuration-file.md#labels)の両方を設定する必要があります。詳細については、 [ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)を参照してください。 #### `policy` {#policy} diff --git a/tiproxy/tiproxy-load-balance.md b/tiproxy/tiproxy-load-balance.md index 22b5fbe2c8279..92cd9ca1711a2 100644 --- a/tiproxy/tiproxy-load-balance.md +++ b/tiproxy/tiproxy-load-balance.md @@ -10,11 +10,11 @@ TiProxy v1.0.0 は、TiDB サーバーに対してステータスベースおよ デフォルトでは、TiProxy は次の優先順位でこれらのポリシーを適用します。 1. ステータスベースの負荷分散: TiDBサーバーがシャットダウンすると、TiProxy はその TiDBサーバーからオンラインの TiDBサーバーに接続を移行します。 -2. ラベルベースの負荷分散: TiProxy は、TiProxy インスタンスと同じラベルを共有する TiDB サーバーへのルーティング要求を優先し、コンピューティングレイヤーでのリソースの分離を可能にします。 +2. ラベルベースの負荷分散: TiProxy は、TiProxy インスタンスと同じラベルを共有する TiDB サーバーへのルーティングリクエストを優先し、コンピューティングレイヤーでのリソースの分離を可能にします。 3. ヘルスベースの負荷分散: TiDBサーバーのヘルスが異常な場合、TiProxy はその TiDBサーバーから正常な TiDBサーバーに接続を移行します。 4. メモリベースの負荷分散: TiDBサーバーがメモリ不足 (OOM) になる危険がある場合、TiProxy はその TiDBサーバーからメモリ使用量の少ない TiDBサーバーに接続を移行します。 5. CPU ベースの負荷分散: TiDBサーバーの CPU 使用率が他の TiDB サーバーよりもはるかに高い場合、TiProxy はその TiDBサーバーから CPU 使用率の低い TiDBサーバーに接続を移行します。 -6. ロケーションベースの負荷分散: TiProxy は、TiProxy に地理的に最も近い TiDBサーバーへのルーティング要求を優先します。 +6. ロケーションベースの負荷分散: TiProxy は、TiProxy に地理的に最も近い TiDBサーバーへのルーティングリクエストを優先します。 7. 接続数ベースの負荷分散: TiDBサーバーの接続数が他の TiDB サーバーよりも大幅に多い場合、TiProxy はその TiDBサーバーから接続数の少ない TiDBサーバーに接続を移行します。 負荷分散ポリシーの優先順位を調整するには、 [負荷分散ポリシーを構成する](#configure-load-balancing-policies)を参照してください。 @@ -137,8 +137,8 @@ TiProxy は、TiProxy サーバーと TiDB サーバーの場所に基づいて このポリシーは、次のシナリオに適しています。 -- TiDB クラスターがクラウド内のアベイラビリティゾーン全体にデプロイされている場合、TiProxy と TiDB サーバー間のアベイラビリティゾーン間のトラフィック コストを削減するために、TiProxy は同じアベイラビリティゾーン内の TiDB サーバーへのルーティング要求を優先します。 -- TiDB クラスターがデータセンター全体にデプロイされている場合、TiProxy と TiDB サーバー間のネットワークレイテンシーを削減するために、TiProxy は同じデータセンター内の TiDB サーバーへのルーティング要求を優先します。 +- TiDB クラスターがクラウド内のアベイラビリティゾーン全体にデプロイされている場合、TiProxy と TiDB サーバー間のアベイラビリティゾーン間のトラフィック コストを削減するために、TiProxy は同じアベイラビリティゾーン内の TiDB サーバーへのルーティングリクエストを優先します。 +- TiDB クラスターがデータセンター全体にデプロイされている場合、TiProxy と TiDB サーバー間のネットワークレイテンシーを削減するために、TiProxy は同じデータセンター内の TiDB サーバーへのルーティングリクエストを優先します。 デフォルトでは、このポリシーの優先度は、ヘルスベース、メモリベース、CPUベースの負荷分散ポリシーよりも低くなっています。優先度を[`policy`](/tiproxy/tiproxy-configuration.md#policy)から`location`に設定することで、優先度を上げることができます。可用性とパフォーマンスを維持するには、少なくとも3台のTiDBサーバーを同じ場所に配置することを推奨します。 @@ -185,7 +185,7 @@ pd_servers: - host: pd-host-3 ``` -上記の構成では、 `tiproxy-host-1`の`zone`設定が`tidb-host-1`と同じであるため、 `tiproxy-host-1`の TiProxy インスタンスは`tidb-host-1` TiDBサーバーへのルーティング要求を優先します。同様に、 `tiproxy-host-2`の TiProxy インスタンスは`tidb-host-2`の TiDBサーバーへのルーティング要求を優先します。 +上記の構成では、 `tiproxy-host-1`の`zone`設定が`tidb-host-1`と同じであるため、 `tiproxy-host-1`の TiProxy インスタンスは`tidb-host-1` TiDBサーバーへのルーティングリクエストを優先します。同様に、 `tiproxy-host-2`の TiProxy インスタンスは`tidb-host-2`の TiDBサーバーへのルーティングリクエストを優先します。 ## 接続数ベースの負荷分散 {#connection-count-based-load-balancing} diff --git a/tiup/tiup-command-clean.md b/tiup/tiup-command-clean.md index 3ff3296ac6d42..83a9bab246647 100644 --- a/tiup/tiup-command-clean.md +++ b/tiup/tiup-command-clean.md @@ -1,6 +1,6 @@ --- title: tiup clean -summary: この「tiup clean」コマンドは、コンポーネント操作中に生成されたデータを消去します。構文は「tiup clean [name] [flags]」で、すべての操作記録を消去するには「--all」オプションを使用します。 +summary: "tiup clean"コマンドは、コンポーネント操作中に生成されたデータを消去します。構文は"tiup clean [name] [flags]"で、すべての操作記録を消去するには"--all"オプションを使用します。 --- # tiup clean {#tiup-clean} diff --git a/tiup/tiup-command-mirror-merge.md b/tiup/tiup-command-mirror-merge.md index 2913fd2b07bf9..b15c02374150d 100644 --- a/tiup/tiup-command-mirror-merge.md +++ b/tiup/tiup-command-mirror-merge.md @@ -1,6 +1,6 @@ --- title: tiup mirror merge -summary: この「tiup mirror merge」コマンドは、1つまたは複数のミラーを現在のミラーにマージします。実行条件には、既存の所有者IDと対応する秘密鍵が含まれます。 +summary: `tiup mirror merge`コマンドは、1つまたは複数のミラーを現在のミラーにマージします。実行条件には、既存の所有者IDと対応する秘密鍵が含まれます。 --- # tiup mirror merge {#tiup-mirror-merge} diff --git a/tiup/tiup-command-status.md b/tiup/tiup-command-status.md index 12b872dc38464..241e21be8fac7 100644 --- a/tiup/tiup-command-status.md +++ b/tiup/tiup-command-status.md @@ -1,6 +1,6 @@ --- title: tiup status -summary: この「tiup status」コマンドは、「tiup 」コマンドでコンポーネントを実行した後、そのコンポーネントの動作情報を確認するために使用します。このコマンドは、動作中のコンポーネントの名前、コンポーネント名、PID、ステータス、作成時刻、ディレクトリ、バイナリ、引数を表示します。コンポーネントのステータスは、Up、Down、Tombstone、Pending Offline、Unknownのいずれかになります。ステータスはPDのスケジュール情報から取得されます。 +summary: "tiup status"コマンドは、"tiup "コマンドでコンポーネントを実行した後、そのコンポーネントの動作情報を確認するために使用します。このコマンドは、動作中のコンポーネントの名前、コンポーネント名、PID、ステータス、作成時刻、ディレクトリ、バイナリ、引数を表示します。コンポーネントのステータスは、Up、Down、Tombstone、Pending Offline、Unknownのいずれかになります。ステータスはPDのスケジュール情報から取得されます。 --- # tiup status {#tiup-status} diff --git a/tiup/tiup-component-cluster-stop.md b/tiup/tiup-component-cluster-stop.md index 7dd96acde570e..159ae1b79b7a6 100644 --- a/tiup/tiup-component-cluster-stop.md +++ b/tiup/tiup-component-cluster-stop.md @@ -1,6 +1,6 @@ --- title: tiup cluster stop -summary: この「tiup cluster stop」コマンドは、指定されたクラスターのすべてまたは一部のサービスを停止するために使用されます。コアサービスが停止すると、クラスターはサービスを提供できなくなります。コマンド構文は「tiup cluster stop [flags]」です。オプションには、停止するノードを指定する -N/--node、停止するノードの役割を指定する -R/--role、ヘルプ情報を表示する -h/--help があります。出力は、サービスの停止に関するログです。 +summary: "tiup cluster stop"コマンドは、指定されたクラスターのすべてまたは一部のサービスを停止するために使用されます。コアサービスが停止すると、クラスターはサービスを提供できなくなります。コマンド構文は"tiup cluster stop [flags]"です。オプションには、停止するノードを指定する -N/--node、停止するノードの役割を指定する -R/--role、ヘルプ情報を表示する -h/--help があります。出力は、サービスの停止に関するログです。 --- # tiup cluster stop {#tiup-cluster-stop} diff --git a/tiup/tiup-component-cluster-tls.md b/tiup/tiup-component-cluster-tls.md index 4a9a86dda2543..c48f871d6d1db 100644 --- a/tiup/tiup-component-cluster-tls.md +++ b/tiup/tiup-component-cluster-tls.md @@ -33,7 +33,7 @@ tiup cluster tls [flags] - クラスターの現在のTLSステータスに関係なく、TLSを強制的に有効または無効にします。 - データタイプ: `BOOLEAN` - デフォルト: `false` -- このオプションを指定しない場合、クラスターが既に要求された状態にある場合は、操作はスキップされます。 +- このオプションを指定しない場合、クラスターが既にリクエストされた状態にある場合は、操作はスキップされます。 ### --reload-certificate {#reload-certificate} diff --git a/tiup/tiup-component-dm-reload.md b/tiup/tiup-component-dm-reload.md index ff9506c738f4d..15393158f1de0 100644 --- a/tiup/tiup-component-dm-reload.md +++ b/tiup/tiup-component-dm-reload.md @@ -1,6 +1,6 @@ --- title: tiup dm reload -summary: この「tiup dm reload」コマンドは、変更されたクラスタ構成を適用し、サービスを再起動するために使用されます。再起動するノードとロールを指定したり、再起動プロセスをスキップしたりできます。また、このコマンドにはヘルプ情報を表示するオプションがあり、tiup-dmの実行ログも出力されます。 +summary: `tiup dm reload`コマンドは、変更されたクラスタ構成を適用し、サービスを再起動するために使用されます。再起動するノードとロールを指定したり、再起動プロセスをスキップしたりできます。また、このコマンドにはヘルプ情報を表示するオプションがあり、tiup-dmの実行ログも出力されます。 --- # tiup dm reload {#tiup-dm-reload} diff --git a/tiup/tiup-mirror-reference.md b/tiup/tiup-mirror-reference.md index 227c5b3a9aeec..979a560d9fb71 100644 --- a/tiup/tiup-mirror-reference.md +++ b/tiup/tiup-mirror-reference.md @@ -303,9 +303,9 @@ TiUPミラーでは、ルート証明書は他のメタデータファイルの - クライアントがインストールされると、バイナリに`root.json`ファイルが含まれます。 - 実行中のクライアントは、既存の`root.json`に基づいて次のタスクを実行します。 1. `root.json`からバージョンを取得し、 `N`としてマークします。 - 2. ミラーに`{N+1}.root.json`を要求します。要求が成功した場合、 `root.json`で記録した公開鍵を使用して、ファイルが有効かどうかを検証します。 - 3. ミラーから`timestamp.json`を要求し、 `root.json`に記録された公開鍵を使用してファイルが有効かどうかを確認します。 - 4. `timestamp.json`に記録された`snapshot.json`のチェックサムがローカルの`snapshot.json`のチェックサムと一致するかどうかを確認します。一致しない場合は、ミラーから最新の`snapshot.json`を要求し、 `root.json`に記録された公開鍵を使用してファイルの有効性を検証します。 - 5. `snapshot.json`からファイル`index.json`のバージョン番号`N`を取得し、ミラーに`{N}.index.json`を要求します。次に、 `root.json`に記録されている公開鍵を使用して、ファイルが有効かどうかを検証します。 - 6. `tidb.json`や`tikv.json`などのコンポーネントについては、クライアントは`snapshot.json`からコンポーネントのバージョン番号`N`を取得し、ミラーに`{N}.{component}.json`を要求します。次に、クライアントは`index.json`に記録されている公開鍵を使用して、ファイルの有効性を検証します。 - 7. コンポーネントのtarファイルの場合、クライアントは`{component}.json`からファイルのURLとチェックサムを取得し、tarパッケージのURLを要求します。そして、クライアントはチェックサムが正しいかどうかを検証します。 + 2. ミラーに`{N+1}.root.json`をリクエストします。リクエストが成功した場合、 `root.json`で記録した公開鍵を使用して、ファイルが有効かどうかを検証します。 + 3. ミラーから`timestamp.json`をリクエストし、 `root.json`に記録された公開鍵を使用してファイルが有効かどうかを確認します。 + 4. `timestamp.json`に記録された`snapshot.json`のチェックサムがローカルの`snapshot.json`のチェックサムと一致するかどうかを確認します。一致しない場合は、ミラーから最新の`snapshot.json`をリクエストし、 `root.json`に記録された公開鍵を使用してファイルの有効性を検証します。 + 5. `snapshot.json`からファイル`index.json`のバージョン番号`N`を取得し、ミラーに`{N}.index.json`をリクエストします。次に、 `root.json`に記録されている公開鍵を使用して、ファイルが有効かどうかを検証します。 + 6. `tidb.json`や`tikv.json`などのコンポーネントについては、クライアントは`snapshot.json`からコンポーネントのバージョン番号`N`を取得し、ミラーに`{N}.{component}.json`をリクエストします。次に、クライアントは`index.json`に記録されている公開鍵を使用して、ファイルの有効性を検証します。 + 7. コンポーネントのtarファイルの場合、クライアントは`{component}.json`からファイルのURLとチェックサムを取得し、tarパッケージのURLをリクエストします。そして、クライアントはチェックサムが正しいかどうかを検証します。 diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index cb832c0a6d420..a5c3b2ea272fb 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -177,7 +177,7 @@ TiDBのコプロセッサーキャッシュ機能は、計算結果のキャッ ## 散在する読み取りホットスポット {#scatter-read-hotspots} -読み取りホットスポットが発生すると、ホットスポット TiKV ノードは読み取り要求を時間内に処理できず、読み取り要求がキューイングされます。ただし、この時点ですべての TiKV リソースが使い果たされるわけではありません。レイテンシーを短縮するために、TiDB v7.1.0 では負荷ベースのレプリカ読み取り機能が導入されました。この機能により、TiDB はホットスポット TiKV ノードでキューイングすることなく、他の TiKV ノードからデータを読み取ることができます。読み取り要求のキューの長さは、 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700)システム変数を使用して制御できます。リーダーノードの推定キュー時間がこのしきい値を超えると、TiDB はフォロワーノードからのデータの読み取りを優先します。この機能により、読み取りホットスポットが発生すると、読み取りホットスポットを分散させない場合と比較して、読み取りスループットが 70% ～ 200% 向上します。 +読み取りホットスポットが発生すると、ホットスポット TiKV ノードは読み取りリクエストを時間内に処理できず、読み取りリクエストがキューイングされます。ただし、この時点ですべての TiKV リソースが使い果たされるわけではありません。レイテンシーを短縮するために、TiDB v7.1.0 では負荷ベースのレプリカ読み取り機能が導入されました。この機能により、TiDB はホットスポット TiKV ノードでキューイングすることなく、他の TiKV ノードからデータを読み取ることができます。読み取りリクエストのキューの長さは、 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700)システム変数を使用して制御できます。リーダーノードの推定キュー時間がこのしきい値を超えると、TiDB はフォロワーノードからのデータの読み取りを優先します。この機能により、読み取りホットスポットが発生すると、読み取りホットスポットを分散させない場合と比較して、読み取りスループットが 70% ～ 200% 向上します。 ### 読み取りホットスポット向けの CPU-aware hot Region scheduling {#cpu-aware-hot-region-scheduling-for-read-hotspots} diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index b81d3439c45e2..dc8cb6b01b7a8 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -163,11 +163,11 @@ CURRENT_SQL_DIGEST_TEXT: update `t` set `v` = `v` + ? where `id` = ? ; ### 読み書き競合 {#read-write-conflicts} -TiDBサーバーはクライアントからの読み取り要求を受信すると、物理時刻におけるグローバルに一意で増加するタイムスタンプを現在のトランザクションのstart_tsとして取得します。トランザクションはstart_tsより前の最新のデータ、つまりstart_tsより小さい最新のcommit_tsのターゲットキーを読み取る必要があります。トランザクションがターゲットキーが別のトランザクションによってロックされていることに気づき、そのトランザクションがどのフェーズにあるかを把握できない場合、読み取り/書き込み競合が発生します。図を以下に示します。 +TiDBサーバーはクライアントからの読み取りリクエストを受信すると、物理時刻におけるグローバルに一意で増加するタイムスタンプを現在のトランザクションのstart_tsとして取得します。トランザクションはstart_tsより前の最新のデータ、つまりstart_tsより小さい最新のcommit_tsのターゲットキーを読み取る必要があります。トランザクションがターゲットキーが別のトランザクションによってロックされていることに気づき、そのトランザクションがどのフェーズにあるかを把握できない場合、読み取り/書き込み競合が発生します。図を以下に示します。 ![read-write conflict](/media/troubleshooting-lock-pic-04.png) -Txn0はPrewriteフェーズを完了し、Commitフェーズに入ります。この時、Txn1は同じターゲットキーの読み取りを要求します。Txn1は、自身のstart_tsよりも小さい最新のcommit_tsのターゲットキーを読み取る必要があります。Txn1のstart_tsはTxn0のlock_tsよりも大きいため、Txn1はターゲットキーのロックが解除されるまで待機する必要がありますが、まだ解除されていません。その結果、Txn1はTxn0がコミットされたかどうかを確認できません。こうして、Txn1とTxn0の間で読み取り/書き込み競合が発生します。 +Txn0はPrewriteフェーズを完了し、Commitフェーズに入ります。この時、Txn1は同じターゲットキーの読み取りをリクエストします。Txn1は、自身のstart_tsよりも小さい最新のcommit_tsのターゲットキーを読み取る必要があります。Txn1のstart_tsはTxn0のlock_tsよりも大きいため、Txn1はターゲットキーのロックが解除されるまで待機する必要がありますが、まだ解除されていません。その結果、Txn1はTxn0がコミットされたかどうかを確認できません。こうして、Txn1とTxn0の間で読み取り/書き込み競合が発生します。 TiDB クラスター内の読み取り/書き込み競合は、次の方法で検出できます。 @@ -187,10 +187,10 @@ TiDB クラスター内の読み取り/書き込み競合は、次の方法で [INFO] [coprocessor.go:743] ["[TIME_COP_PROCESS] resp_time:406.038899ms txnStartTS:416643508703592451 region_id:8297 store_addr:10.8.1.208:20160 backoff_ms:255 backoff_types:[txnLockFast,txnLockFast] kv_process_ms:333 scan_total_write:0 scan_processed_write:0 scan_total_data:0 scan_processed_data:0 scan_total_lock:0 scan_processed_lock:0"] ``` - - txnStartTS: 読み取り要求を送信しているトランザクションのstart_ts。上記のログでは、 `416643508703592451`がstart_tsです。 - - backoff_types: 読み取り/書き込み競合が発生し、読み取り要求がバックオフと再試行を実行する場合、再試行のタイプは`TxnLockFast`なります。 + - txnStartTS: 読み取りリクエストを送信しているトランザクションのstart_ts。上記のログでは、 `416643508703592451`がstart_tsです。 + - backoff_types: 読み取り/書き込み競合が発生し、読み取りリクエストがバックオフと再試行を実行する場合、再試行のタイプは`TxnLockFast`なります。 - backoff_ms: 読み取りリクエストがバックオフとリトライに要した時間。単位はミリ秒です。上記のログでは、読み取りリクエストはバックオフとリトライに255ミリ秒を費やしています。 - - region_id: 読み取り要求のターゲット キーに対応するリージョンID。 + - region_id: 読み取りリクエストのターゲット キーに対応するリージョンID。 2. TiKVサーバーのログ @@ -200,7 +200,7 @@ TiDB クラスター内の読み取り/書き込み競合は、次の方法で [ERROR] [endpoint.rs:454] [error-response] [err=""locked primary_lock:7480000000000004D35F6980000000000000010380000000004C788E0380000000004C0748 lock_version: 411402933858205712 key: 7480000000000004D35F7280000000004C0748 lock_ttl: 3008 txn_size: 1""] ``` - このメッセージは、TiDBで読み取り/書き込み競合が発生したことを示しています。読み取り要求のターゲットキーは別のトランザクションによってロックされています。ロックは、コミットされていない楽観的トランザクションと、プリライトフェーズ後のコミットされていない悲観的トランザクションによって発生しています。 + このメッセージは、TiDBで読み取り/書き込み競合が発生したことを示しています。読み取りリクエストのターゲットキーは別のトランザクションによってロックされています。ロックは、コミットされていない楽観的トランザクションと、プリライトフェーズ後のコミットされていない悲観的トランザクションによって発生しています。 - primary_lock: ターゲット キーがプライマリ ロックによってロックされていることを示します。 - lock_version: ロックを所有するトランザクションの start_ts。 @@ -308,7 +308,7 @@ err="pessimistic lock retry limit reached" ### ロック待機タイムアウトを超えました {#lock-wait-timeout-exceeded} -悲観的トランザクションモードでは、トランザクションは互いのロックを待機します。ロック待機のタイムアウトは、TiDBのパラメータ[innodb_lock_wait_timeout](/pessimistic-transaction.md#behaviors)によって定義されます。これは、SQL文レベルでの最大ロック待機時間であり、SQL文がロックを要求したがロックが取得されなかった場合に想定される時間です。この時間が経過すると、TiDBは再びロックを試行せず、対応するエラーメッセージをクライアントに返します。 +悲観的トランザクションモードでは、トランザクションは互いのロックを待機します。ロック待機のタイムアウトは、TiDBのパラメータ[innodb_lock_wait_timeout](/pessimistic-transaction.md#behaviors)によって定義されます。これは、SQL文レベルでの最大ロック待機時間であり、SQL文がロックをリクエストしたがロックが取得されなかった場合に想定される時間です。この時間が経過すると、TiDBは再びロックを試行せず、対応するエラーメッセージをクライアントに返します。 待機ロックのタイムアウトが発生すると、次のエラーメッセージがクライアントに返されます。 @@ -337,7 +337,7 @@ TTL manager has timed out, pessimistic locks may expire, please commit or rollba ### ロックを取得しようとしたときにデッドロックが見つかりました {#deadlock-found-when-trying-to-get-lock} -2つ以上のトランザクション間でリソースの競合が発生すると、デッドロックが発生します。手動で対処しないと、互いにブロックし合うトランザクションは正常に実行されず、永遠に待機状態になります。デッドロックを解決するには、いずれかのトランザクションを手動で終了し、他のトランザクション要求を再開する必要があります。 +2つ以上のトランザクション間でリソースの競合が発生すると、デッドロックが発生します。手動で対処しないと、互いにブロックし合うトランザクションは正常に実行されず、永遠に待機状態になります。デッドロックを解決するには、いずれかのトランザクションを手動で終了し、他のトランザクションリクエストを再開する必要があります。 悲観的トランザクションでデッドロックが発生した場合、デッドロックを解除するには、いずれかのトランザクションを終了させる必要があります。クライアントはMySQLと同じ`Error 1213`エラーを返します。例： diff --git a/troubleshoot-write-conflicts.md b/troubleshoot-write-conflicts.md index a64996a59d860..049dc9f579e86 100644 --- a/troubleshoot-write-conflicts.md +++ b/troubleshoot-write-conflicts.md @@ -42,7 +42,7 @@ TiDB Grafana パネルで、 **KV エラー**の下にある次の監視メト - `wait_expired` 、トランザクションがロックの有効期限が切れるまで待機する必要があることを示します。 - `expired`ロックのTTLが期限切れであることを示します。その後、競合トランザクションはこのロックを解決できます。 -- **KV 再試行期間**は、KV 要求を再送信する期間を示します。 +- **KV 再試行期間**は、KV リクエストを再送信する期間を示します。 ![kv-retry-duration](/media/troubleshooting-write-conflict-kv-retry-duration.png) diff --git a/tune-region-performance.md b/tune-region-performance.md index 57f3065d94887..3f12f757c8c9e 100644 --- a/tune-region-performance.md +++ b/tune-region-performance.md @@ -45,9 +45,9 @@ TiKVは自動的に[最下層のデータを分割する](/best-practices/tidb-b 多数のリージョンを持つTiDBクラスターでは、ハートビート処理とタスクのスケジューリングによるオーバーヘッドの増加により、PDリーダーのCPU負荷が高くなる可能性があります。クラスターに多数のTiDBインスタンスがあり、リージョン情報へのリクエストが同時に発生すると、PDリーダーのCPU負荷がさらに高まり、PDサービスが利用できなくなる可能性があります。 -高可用性を確保するため、PDリーダーはリージョン情報をフォロワーとリアルタイムで同期します。PDフォロワーはリージョン情報をメモリに保持・保存し、リージョン情報要求を処理できるようにします。システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760)を`ON`に設定することで、アクティブPDFollower機能を有効にすることができます。この機能を有効にすると、TiDBはリージョン情報要求をすべてのPDサーバーに均等に分散し、PDフォロワーもリージョン要求を直接処理できるようになるため、PDリーダーのCPU負荷が軽減されます。 +高可用性を確保するため、PDリーダーはリージョン情報をフォロワーとリアルタイムで同期します。PDフォロワーはリージョン情報をメモリに保持・保存し、リージョン情報リクエストを処理できるようにします。システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760)を`ON`に設定することで、アクティブPDFollower機能を有効にすることができます。この機能を有効にすると、TiDBはリージョン情報リクエストをすべてのPDサーバーに均等に分散し、PDフォロワーもリージョンリクエストを直接処理できるようになるため、PDリーダーのCPU負荷が軽減されます。 PD は、リージョン同期ストリームのステータスを維持し、TiKV client-go のフォールバック メカニズムを使用することで、TiDB 内のリージョン情報が常に最新であることを保証します。 -- PDリーダーとフォロワー間のネットワークが不安定な場合、またはフォロワーが利用できない場合、リージョン同期ストリームは切断され、PDフォロワーはリージョン情報要求を拒否します。この場合、TiDBはPDリーダーへの要求を自動的に再試行し、フォロワーを一時的に利用不可としてマークします。 -- ネットワークが安定している場合でも、リーダーとフォロワー間の同期に遅延が生じる可能性があり、フォロワーから取得したリージョン情報の一部が古くなっている可能性があります。この場合、当該リージョンに対応するKV要求が失敗すると、TiDBはPDリーダーに最新のリージョン情報を自動的に再要求し、TiKVに再度KV要求を送信します。 +- PDリーダーとフォロワー間のネットワークが不安定な場合、またはフォロワーが利用できない場合、リージョン同期ストリームは切断され、PDフォロワーはリージョン情報リクエストを拒否します。この場合、TiDBはPDリーダーへのリクエストを自動的に再試行し、フォロワーを一時的に利用不可としてマークします。 +- ネットワークが安定している場合でも、リーダーとフォロワー間の同期に遅延が生じる可能性があり、フォロワーから取得したリージョン情報の一部が古くなっている可能性があります。この場合、当該リージョンに対応するKVリクエストが失敗すると、TiDBはPDリーダーに最新のリージョン情報を自動的に再リクエストし、TiKVに再度KVリクエストを送信します。 diff --git a/tune-tikv-thread-performance.md b/tune-tikv-thread-performance.md index 5619bc5fa198a..a1c89feeb2608 100644 --- a/tune-tikv-thread-performance.md +++ b/tune-tikv-thread-performance.md @@ -13,7 +13,7 @@ TiKVスレッドプールは、主にgRPC、Scheduler、UnifyReadPool、 Raftsto - gRPC スレッドプール: すべてのネットワークリクエストを処理し、さまざまなタスクタイプのリクエストをさまざまなスレッドプールに転送します。 -- スケジューラスレッドプール: 書き込みトランザクションの競合を検出し、2 フェーズコミット、悲観的ロック、トランザクション ロールバックなどの要求をキーと値のペアの配列に変換し、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 +- スケジューラスレッドプール: 書き込みトランザクションの競合を検出し、2 フェーズコミット、悲観的ロック、トランザクション ロールバックなどのリクエストをキーと値のペアの配列に変換し、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 - Raftstoreスレッドプール: @@ -23,15 +23,15 @@ TiKVスレッドプールは、主にgRPC、Scheduler、UnifyReadPool、 Raftsto - StoreWriter スレッドプール: すべてのRaftログをディスクに書き込み、結果をRaftstoreスレッドに返します。 -- Apply スレッドプール: Raftstoreスレッドプールから送信された送信ログを受信し、それをキーバリュー要求として解析し、RocksDB に書き込み、コールバック関数を呼び出して gRPC スレッドプールに書き込み要求が完了したことを通知し、結果をクライアントに返します。 +- Apply スレッドプール: Raftstoreスレッドプールから送信された送信ログを受信し、それをキー値リクエストとして解析し、RocksDB に書き込み、コールバック関数を呼び出して gRPC スレッドプールに書き込みリクエストが完了したことを通知し、結果をクライアントに返します。 - RocksDBスレッドプール：RocksDBがタスクを圧縮およびフラッシュするためのスレッドプールです。RocksDBのアーキテクチャと`Compact`操作については、 [RocksDB: フラッシュと RAM ストレージ用の永続的なキーバリューストア](https://github.com/facebook/rocksdb)を参照してください。 -- UnifyReadPool スレッドプール:コプロセッサースレッドプールとストレージ読み取りプールを組み合わせたものです。kv get、kv batch get、raw kv get、コプロセッサなどのすべての読み取り要求はこのスレッドプールで実行されます。 +- UnifyReadPool スレッドプール:コプロセッサースレッドプールとストレージ読み取りプールを組み合わせたものです。kv get、kv batch get、raw kv get、コプロセッサなどのすべての読み取りリクエストはこのスレッドプールで実行されます。 ## TiKV読み取り専用リクエスト {#tikv-read-only-requests} -TiKV の読み取り要求は次の種類に分類されます。 +TiKV の読み取りリクエストは次の種類に分類されます。 - ストレージ読み取りプールで実行される、特定の行または複数の行を指定する単純なクエリ。 - コプロセッサー読み取りプールで実行される複雑な集計計算と範囲クエリ。 @@ -45,7 +45,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで v8.5.4以降、gRPCスレッドプールのデフォルトサイズ（ `server.grpc-concurrency`で設定）が固定値の`5`から、CPUコア数に基づいて計算される適応値に変更されました。詳細な計算式については、 [`server.grpc-concurrency`](/tikv-configuration-file.md#grpc-concurrency)を参照してください。このスレッドプールはコンピューティングオーバーヘッドがほとんどなく、主にネットワークI/Oとデシリアライズリクエストを処理するため、通常はデフォルト設定を調整する必要はありません。 - TiKV でデプロイされたマシンの CPU コア数が少ない (8 個以下) 場合は、 `server.grpc-concurrency`設定項目を`2`に設定することを検討してください。 - - TiKV を導入したマシンの構成が非常に高く、TiKV が大量の読み取りおよび書き込み要求を処理し、Grafana でスレッド CPU を監視する値`gRPC poll CPU`が`server.grpc-concurrency`の 80% を超える場合は、スレッドプールの使用率を 80% 未満 (つまり、Grafana のメトリックが`80% * server.grpc-concurrency`未満) に保つために値`server.grpc-concurrency`を増やすことを検討してください。 + - TiKV を導入したマシンの構成が非常に高く、TiKV が大量の読み取りおよび書き込みリクエストを処理し、Grafana でスレッド CPU を監視する値`gRPC poll CPU`が`server.grpc-concurrency`の 80% を超える場合は、スレッドプールの使用率を 80% 未満 (つまり、Grafana のメトリックが`80% * server.grpc-concurrency`未満) に保つために値`server.grpc-concurrency`を増やすことを検討してください。 - スケジューラスレッドプール。 @@ -54,7 +54,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで このスレッドプールは主に、複雑なトランザクションリクエストを単純なキーバリューの読み取り/書き込みリクエストに変換するために使用されます。ただし、**スケジューラスレッドプール自体は書き込み操作を実行しません**。 - トランザクションの競合が検出されると、このスレッドプールは競合の結果を事前にクライアントに返します。 - - 競合が検出されない場合、このスレッドプールは書き込み操作を実行するキーバリュー要求をRaftログにマージし、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 + - 競合が検出されない場合、このスレッドプールは書き込み操作を実行するキー値リクエストをRaftログにマージし、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 一般的に、過度のスレッド切り替えを避けるには、スケジューラのスレッドプールの使用率を50%～75%に保つことが最善です。スレッドプールのサイズが`8`の場合、Grafanaでは400%～600%の範囲で`TiKV-Details.Thread CPU.scheduler worker CPU`を維持することをお勧めします。 @@ -71,7 +71,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで - StoreWriterスレッドプールは、CPUリソース全体が十分である場合にのみ有効にしてください。StoreWriterスレッドプールを有効にする際は、StoreWriterスレッドとRaftstoreスレッドのCPU使用率を80%未満に抑えてください。 - 書き込み要求がRaftstoreスレッドで処理される場合と比較して、理論上は、書き込み要求が StoreWriter スレッドで処理される場合、書き込みレイテンシーとデータ読み取りのテールレイテンシーが大幅に削減されます。ただし、書き込み速度が高速化すると、それに応じてRaftログの数が増加します。これにより、 Raftstoreスレッド、Apply スレッド、および gRPC スレッドの CPU オーバーヘッドが増加する可能性があります。この場合、CPU リソースが不足するとチューニング効果が打ち消され、結果として書き込み速度が以前よりも遅くなる可能性があります。したがって、CPU リソースが十分でない場合は、StoreWriter スレッドを有効にすることは推奨されません。Raftstore スレッドはほとんどの I/O 要求をStoreWriterスレッドに送信するため、 Raftstoreスレッドの CPU 使用率を 80% 未満に抑える必要があります。 + 書き込みリクエストがRaftstoreスレッドで処理される場合と比較して、理論上は、書き込みリクエストが StoreWriter スレッドで処理される場合、書き込みレイテンシーとデータ読み取りのテールレイテンシーが大幅に削減されます。ただし、書き込み速度が高速化すると、それに応じてRaftログの数が増加します。これにより、 Raftstoreスレッド、Apply スレッド、および gRPC スレッドの CPU オーバーヘッドが増加する可能性があります。この場合、CPU リソースが不足するとチューニング効果が打ち消され、結果として書き込み速度が以前よりも遅くなる可能性があります。したがって、CPU リソースが十分でない場合は、StoreWriter スレッドを有効にすることは推奨されません。Raftstore スレッドはほとんどの I/O リクエストをStoreWriterスレッドに送信するため、 Raftstoreスレッドの CPU 使用率を 80% 未満に抑える必要があります。 - ほとんどの場合、StoreWriter スレッドプールのサイズは 1 または 2 に設定してください。これは、StoreWriter スレッドプールのサイズがRaftログの数に影響するため、スレッドプールのサイズを大きくしすぎないようにするためです。CPU 使用率が 80% を超える場合は、スレッドプールのサイズを増やすことを検討してください。 From 446ef3671b4ab271ef36fb5d0d298b3d745a6c27 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 9 Sep 2026 15:04:24 +0900 Subject: [PATCH 2/3] i18n(ja): fix CodeRabbit-confirmed issues across 6 files --- system-variables.md | 2 +- tidb-cloud/changefeed-sink-to-apache-kafka.md | 4 ++-- tiflash-performance-tuning-methods.md | 2 +- tiup/tiup-command-clean.md | 2 +- tiup/tiup-command-status.md | 2 +- troubleshoot-lock-conflicts.md | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) diff --git a/system-variables.md b/system-variables.md index 2614bf8834be3..18da1fd08ed6b 100644 --- a/system-variables.md +++ b/system-variables.md @@ -2784,7 +2784,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `ON` - 値のオプション: `OFF` 、 `ON` -- この変数は、TiDB がチャンク オブジェクトのキャッシュを有効にするかどうかを制御します。値が`ON` `OFF`の場合、TiDB はシステムから直接チャンク オブジェクトをリクエストします。 +- この変数は、TiDB がチャンク オブジェクトのキャッシュを有効にするかどうかを制御します。値が`ON`の場合、TiDB はキャッシュされたチャンク オブジェクトの使用を優先し、要求されたオブジェクトがキャッシュにない場合のみシステムにリクエストします。値が`OFF`の場合、TiDB はシステムから直接チャンク オブジェクトをリクエストします。 ### tidb_enable_shared_lock_promotion New in v8.3.0 diff --git a/tidb-cloud/changefeed-sink-to-apache-kafka.md b/tidb-cloud/changefeed-sink-to-apache-kafka.md index 98c4c2974fe3c..6d08e22270a1d 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -218,7 +218,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン 8. **Next**をクリックしてネットワーク接続をテストしてください。テストが成功すると、次のページに移動します。 9. TiDB Cloudは**Private Service Connect**用のエンドポイントを作成しますが、これには数分かかる場合があります。 10. エンドポイントが作成されたら、クラウドプロバイダーのコンソールにログインし、接続リクエストを承認してください。 -11. [TiDB Cloudコンソール](https://tidbcloud.com)に戻る 接続リクエストを承認したことを確認してください。TiDB Cloudは接続テストを実行し、テストが成功した場合は次のページに進みます。 +11. [TiDB Cloudコンソール](https://tidbcloud.com)に戻り、接続リクエストを承認したことを確認してください。TiDB Cloudは接続テストを実行し、テストが成功した場合は次のページに進みます。 @@ -239,7 +239,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン 8. **Next**をクリックしてネットワーク接続をテストしてください。テストが成功すると、次のページに移動します。 9. TiDB Cloudは**Private Link**のエンドポイントを作成しますが、これには数分かかる場合があります。 10. エンドポイントが作成されたら、 [Azureポータル](https://portal.azure.com/)にログインして接続リクエストを承認してください。 -11. [TiDB Cloudコンソール](https://tidbcloud.com)に戻る 接続リクエストを承認したことを確認してください。TiDB Cloudは接続テストを実行し、テストが成功した場合は次のページに進みます。 +11. [TiDB Cloudコンソール](https://tidbcloud.com)に戻り、接続リクエストを承認したことを確認してください。TiDB Cloudは接続テストを実行し、テストが成功した場合は次のページに進みます。 diff --git a/tiflash-performance-tuning-methods.md b/tiflash-performance-tuning-methods.md index e674291698e72..52664a6ea3083 100644 --- a/tiflash-performance-tuning-methods.md +++ b/tiflash-performance-tuning-methods.md @@ -29,7 +29,7 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ - MPP クエリ数: 各TiFlashインスタンスの MPP クエリ数の瞬間値。TiFlashで処理する必要がある現在の MPP クエリ数 (処理中のクエリとスケジュール待ちのクエリを含む) を反映します。 - リクエスト QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサリクエストの数。 - - `run_mpp_task` 、および`mpp_establish_conn` `dispatch_mpp_task` MPP リクエストです。 + - `run_mpp_task`、`dispatch_mpp_task`、および`mpp_establish_conn`はMPPリクエストです。 - `batch` : バッチリクエストの数。 - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサリクエストの数。 - `cop_execution` : 現在実行中のコプロセッサリクエストの数。 diff --git a/tiup/tiup-command-clean.md b/tiup/tiup-command-clean.md index 83a9bab246647..8d1f37386ef0e 100644 --- a/tiup/tiup-command-clean.md +++ b/tiup/tiup-command-clean.md @@ -1,6 +1,6 @@ --- title: tiup clean -summary: "tiup clean"コマンドは、コンポーネント操作中に生成されたデータを消去します。構文は"tiup clean [name] [flags]"で、すべての操作記録を消去するには"--all"オプションを使用します。 +summary: `tiup clean`コマンドは、コンポーネント操作中に生成されたデータを消去します。構文は`tiup clean [name] [flags]`で、すべての操作記録を消去するには`--all`オプションを使用します。 --- # tiup clean {#tiup-clean} diff --git a/tiup/tiup-command-status.md b/tiup/tiup-command-status.md index 241e21be8fac7..a69d68dfb2b5b 100644 --- a/tiup/tiup-command-status.md +++ b/tiup/tiup-command-status.md @@ -1,6 +1,6 @@ --- title: tiup status -summary: "tiup status"コマンドは、"tiup "コマンドでコンポーネントを実行した後、そのコンポーネントの動作情報を確認するために使用します。このコマンドは、動作中のコンポーネントの名前、コンポーネント名、PID、ステータス、作成時刻、ディレクトリ、バイナリ、引数を表示します。コンポーネントのステータスは、Up、Down、Tombstone、Pending Offline、Unknownのいずれかになります。ステータスはPDのスケジュール情報から取得されます。 +summary: `tiup status`コマンドは、`tiup `コマンドでコンポーネントを実行した後、そのコンポーネントの動作情報を確認するために使用します。このコマンドは、動作中のコンポーネントの名前、コンポーネント名、PID、ステータス、作成時刻、ディレクトリ、バイナリ、引数を表示します。コンポーネントのステータスは、Up、Down、Tombstone、Pending Offline、Unknownのいずれかになります。ステータスはPDのスケジュール情報から取得されます。 --- # tiup status {#tiup-status} diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index dc8cb6b01b7a8..3a0392ecf6126 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -188,7 +188,7 @@ TiDB クラスター内の読み取り/書き込み競合は、次の方法で ``` - txnStartTS: 読み取りリクエストを送信しているトランザクションのstart_ts。上記のログでは、 `416643508703592451`がstart_tsです。 - - backoff_types: 読み取り/書き込み競合が発生し、読み取りリクエストがバックオフと再試行を実行する場合、再試行のタイプは`TxnLockFast`なります。 + - backoff_types: 読み取り/書き込み競合が発生し、読み取りリクエストがバックオフと再試行を実行する場合、再試行のタイプは`txnLockFast`になります。 - backoff_ms: 読み取りリクエストがバックオフとリトライに要した時間。単位はミリ秒です。上記のログでは、読み取りリクエストはバックオフとリトライに255ミリ秒を費やしています。 - region_id: 読み取りリクエストのターゲット キーに対応するリージョンID。 From 680862c588432383e944683af3f666e0a6e67e4c Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 10 Sep 2026 16:22:37 +0900 Subject: [PATCH 3/3] i18n(ja): clarify distributed storage and computing requests in release-8.1.2 The Japanese phrase repeated the request noun only after computing, making it read as if it applied solely to computing rather than both storage and computing. Repeat the noun after each term, per CodeRabbit's review comment on PR #23784. --- releases/release-8.1.2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases/release-8.1.2.md b/releases/release-8.1.2.md index 6e17f16660b04..563c27579da6b 100644 --- a/releases/release-8.1.2.md +++ b/releases/release-8.1.2.md @@ -36,7 +36,7 @@ TiDB バージョン: 8.1.2 - クラスター化インデックスを持つテーブルで、バックグラウンドでの古いデータのガベージコレクションの速度が向上しました。 [#9529](https://github.com/pingcap/tiflash/issues/9529) @[JaySon-Huang](https://github.com/JaySon-Huang) - TLS を有効にした後に証明書を更新することでTiFlash がpanicする可能性がある問題を軽減します[#8535](https://github.com/pingcap/tiflash/issues/8535) @[windtalker](https://github.com/windtalker) - - 分散ストレージとコンピューティングリクエストを処理するときにTiFlash が作成する必要があるスレッドの数を減らし、大量のそのようなリクエストを処理するときにTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます[#9334](https://github.com/pingcap/tiflash/issues/9334) @[JinheLin](https://github.com/JinheLin) + - 分散ストレージリクエストとコンピューティングリクエストを処理するときにTiFlash が作成する必要があるスレッドの数を減らし、大量のそのようなリクエストを処理するときにTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます[#9334](https://github.com/pingcap/tiflash/issues/9334) @[JinheLin](https://github.com/JinheLin) - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセルリクエストにタイムリーに応答できるようにします[#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) - `LENGTH()`と`ASCII()`関数の実行効率を最適化 [#9344](https://github.com/pingcap/tiflash/issues/9344) @[xzhangxian1008](https://github.com/xzhangxian1008) - 分散ストレージおよびコンピューティングアーキテクチャ内のTiFlashコンピューティングノードの再試行戦略を最適化して、Amazon S3 からファイルをダウンロードする際の例外を処理します。 [#9695](https://github.com/pingcap/tiflash/issues/9695) @[JinheLin](https://github.com/JinheLin)