diff --git a/auto-increment.md b/auto-increment.md index 16ac74a383500..feb80e401a08e 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -84,7 +84,7 @@ mysql> SELECT * FROM t; 上記の使用法はMySQLの`AUTO_INCREMENT`と同じです。ただし、暗黙的に割り当てられる具体的な値に関しては、TiDBはMySQLとは大きく異なります。 -## 実施原則 {#implementation-principles} +## 実装原理 {#implementation-principles} TiDB は`AUTO_INCREMENT`暗黙的な割り当てを次のように実装します。 diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index 3eed6a0aea860..702cccb6c94b2 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -13,7 +13,7 @@ TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポ TiDBクラスタが大規模で、障害発生後に再度リストアを行う余裕がない場合は、チェックポイントリストア機能を使用できます。brコマンドラインツール（以下、 `br` ）は、リストアされたシャードを定期的に記録します。これにより、次回のリストア再試行では、異常終了に近いリカバリ進捗ポイントを使用できます。 -## 実施原則 {#implementation-principles} +## 実装原理 {#implementation-principles} チェックポイント復元の実装は、スナップショット復元とログ復元の2つの部分に分かれています。詳細については、 [実装の詳細: チェックポイントデータを下流のクラスタに保存する](#implementation-details-store-checkpoint-data-in-the-downstream-cluster)と[実装の詳細: チェックポイントデータを外部ストレージに保存する](#implementation-details-store-checkpoint-data-in-the-external-storage)参照してください。 diff --git a/clinic/clinic-introduction.md b/clinic/clinic-introduction.md index 390155e0a4161..b67420a8c0659 100644 --- a/clinic/clinic-introduction.md +++ b/clinic/clinic-introduction.md @@ -34,7 +34,7 @@ PingCAP Clinic は、クラスターの問題を診断するために次の 2 クラスタが現時点で安定して動作している場合でも、潜在的な安定性リスクを検出するために、定期的にクラスタを検査する必要があります。PingCAP Clinicが提供するローカルおよびサーバー側のクイックチェック機能を使用することで、クラスタの潜在的な健全性リスクを特定できます。 -## 実施原則 {#implementation-principles} +## 実装原理 {#implementation-principles} このセクションでは、Diag がクラスターから診断データを収集する実装原則について説明します。 diff --git a/configure-load-base-split.md b/configure-load-base-split.md index 310ae1c1e9de2..4628e3aa57fcb 100644 --- a/configure-load-base-split.md +++ b/configure-load-base-split.md @@ -20,7 +20,7 @@ TiDBでは、負荷が特定のノードに集中すると、ホットスポッ - リージョンを均等に分割することは、必ずしも最適な選択とは限りません。リクエストが少数のキーに集中する可能性があるためです。このような場合、均等分割後もホットスポットがいずれかのリージョンに残る可能性があり、目的を達成するには複数回の均等分割が必要になる場合があります。 - 人間の介入はタイムリーでも簡単でもない。 -## 実施原則 {#implementation-principles} +## 実装原理 {#implementation-principles} Load Base Splitは、統計情報に基づいてリージョンを自動的に分割します。読み取り負荷またはCPU使用率が10秒間継続的にしきい値を超えるリージョンを特定し、これらのリージョンを適切な位置で分割します。分割位置の選択にあたっては、分割後の両リージョンのアクセス負荷のバランスを取り、リージョン間のアクセスを回避しようとします。 diff --git a/configure-store-limit.md b/configure-store-limit.md index 117c443b9c449..bbc5db824db5f 100644 --- a/configure-store-limit.md +++ b/configure-store-limit.md @@ -7,7 +7,7 @@ summary: ストア制限の機能について学びます。 ストア制限はPDの機能です。様々なシナリオにおいてパフォーマンスを向上させるために、スケジューリング速度をより細かく制御できるように設計されています。 -## 実施原則 {#implementation-principles} +## 実装原理 {#implementation-principles} PDはオペレータ単位でスケジューリングを実行します。オペレータには複数のスケジューリング操作が含まれる場合があります。例： diff --git a/dm/dm-manage-schema.md b/dm/dm-manage-schema.md index c6dc5768180c1..b5702e1dda563 100644 --- a/dm/dm-manage-schema.md +++ b/dm/dm-manage-schema.md @@ -11,7 +11,7 @@ DMが増分レプリケーションを実行する際、まず上流のbinlogを 特別な状況に対処したり、テーブル スキーマの不一致によって発生する移行の中断を処理したりするために、DM は内部テーブル スキーマを取得、変更、および削除する`binlog-schema`コマンドを提供します。 -## 実施原則 {#implementation-principles} +## 実装原理 {#implementation-principles} 内部テーブル スキーマは次のソースから取得されます。 @@ -44,7 +44,7 @@ DMが増分レプリケーションを実行する際、まず上流のbinlogを > > `binlog-schema`コマンドは DM v6.0 以降のバージョンでのみサポートされます。それ以前のバージョンでは、 `operate-schema`コマンドを使用する必要があります。 -## 指示 {#command} +## コマンド {#command} ```bash help binlog-schema diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md index 58197acc70682..1ee05898a3250 100644 --- a/dm/feature-shard-merge-optimistic.md +++ b/dm/feature-shard-merge-optimistic.md @@ -105,7 +105,7 @@ ALTER TABLE `tbl00` ADD COLUMN `Age` INT DEFAULT -1; この時点で、 `DEFAULT 0`と`DEFAULT -1`互いに互換性がないため、 `tbl00`の`Age`列は不整合になります。このような状況では、DMはエラーを報告しますが、データの不整合を手動で修正する必要があります。 -## 実施原則 {#implementation-principle} +## 実装原理 {#implementation-principle} 楽観的モードでは、DMワーカーは上流からDDL文を受信すると、更新されたテーブルスキーマをDMマスターに転送します。DMワーカーは各シャードテーブルの現在のスキーマを追跡し、DMマスターはこれらのスキーマを、各シャードテーブルのDML文と互換性のある複合スキーマにマージします。その後、DMマスターは対応するDDL文を下流に移行します。DML文は下流に直接移行されます。 diff --git a/dm/manually-handling-sharding-ddl-locks.md b/dm/manually-handling-sharding-ddl-locks.md index 7f4696320975f..2e1f33ddd750c 100644 --- a/dm/manually-handling-sharding-ddl-locks.md +++ b/dm/manually-handling-sharding-ddl-locks.md @@ -14,7 +14,7 @@ DMはシャーディングDDLロックを使用して、操作が正しい順序 > - コマンドによってもたらされる可能性のある影響を完全に認識し、それを受け入れられる場合を除き、 `shard-ddl-lock unlock`使用しないでください。 > - 異常な DDL ロックを手動で処理する前に、DM [シャードマージの原則](/dm/feature-shard-merge-pessimistic.md#principles)必ず読んでください。 -## 指示 {#command} +## コマンド {#command} ### `shard-ddl-lock` {#shard-ddl-lock} diff --git a/pd-control.md b/pd-control.md index 66fcba40da399..8ed2671a2755b 100644 --- a/pd-control.md +++ b/pd-control.md @@ -105,7 +105,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - バージョン情報を出力して終了します - デフォルト: false -## 指示 {#command} +## コマンド {#command} ### `cluster` {#cluster} diff --git a/sql-statements/sql-statement-flashback-table.md b/sql-statements/sql-statement-flashback-table.md index a2ad760a6c8ae..96c7367c53da8 100644 --- a/sql-statements/sql-statement-flashback-table.md +++ b/sql-statements/sql-statement-flashback-table.md @@ -60,7 +60,7 @@ FlashbackToNewName ::= FLASHBACK TABLE t TO t1; ``` -## 実施原則 {#implementation-principle} +## 実装原理 {#implementation-principle} テーブルを削除する際、TiDBはテーブルメタデータのみを削除し、削除対象のテーブルデータ（行データとインデックスデータ）を`mysql.gc_delete_range`テーブルに書き込みます。TiDBのバックグラウンドにあるGCワーカーは、GCの有効期間を超えたキーを`mysql.gc_delete_range`テーブルから定期的に削除します。 diff --git a/sql-statements/sql-statement-recover-table.md b/sql-statements/sql-statement-recover-table.md index 7101fb62698b2..35b1237897fb6 100644 --- a/sql-statements/sql-statement-recover-table.md +++ b/sql-statements/sql-statement-recover-table.md @@ -75,7 +75,7 @@ NUM ::= intLit このメソッドは、 `DDL JOB ID`を介して削除されたテーブルを回復します。対応するDDLジョブが`DROP TABLE`タイプでない場合は、エラーが発生します。 -## 実施原則 {#implementation-principle} +## 実装原理 {#implementation-principle} テーブルを削除する際、TiDBはテーブルメタデータのみを削除し、削除対象のテーブルデータ（行データとインデックスデータ）を`mysql.gc_delete_range`テーブルに書き込みます。TiDBのバックグラウンドにあるGCワーカーは、GCの有効期間を超えたキーを`mysql.gc_delete_range`テーブルから定期的に削除します。 diff --git a/tidb-distributed-execution-framework.md b/tidb-distributed-execution-framework.md index 2622df94855cf..de835a87f4a07 100644 --- a/tidb-distributed-execution-framework.md +++ b/tidb-distributed-execution-framework.md @@ -104,7 +104,7 @@ v8.1.0以降、タスク実行中に新しいノードが追加された場合 > - バージョンv7.4.0からv8.0.0まで、複数のTiDBノードを持つクラスターでは、2つ以上のTiDBノードで[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)から`background`設定することを強くお勧めします。この変数を1つのTiDBノードにのみ設定した場合、そのノードが再起動または障害を起こした場合、タスクは`tidb_service_scope = ''`が設定されているTiDBノードに再スケジュールされ、これらのTiDBノードで実行されているアプリケーションに影響を及ぼします。 > - 分散タスクの実行中、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)構成への変更は現在のタスクには適用されませんが、次のタスクからは適用されます。 -## 実施原則 {#implementation-principles} +## 実装原理 {#implementation-principles} DXF のアーキテクチャは次のとおりです。 diff --git a/tidb-global-sort.md b/tidb-global-sort.md index 9eb76bbea3586..86f5b737ad48a 100644 --- a/tidb-global-sort.md +++ b/tidb-global-sort.md @@ -75,7 +75,7 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ > > [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)については、 [`CLOUD_STORAGE_URI`](/sql-statements/sql-statement-import-into.md#withoptions)オプションを使用してクラウドストレージのパスを指定することもできます。 [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)と`CLOUD_STORAGE_URI`両方に有効なクラウドストレージのパスが設定されている場合、 `CLOUD_STORAGE_URI`の設定が[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)に有効になります。 -## 実施原則 {#implementation-principles} +## 実装原理 {#implementation-principles} グローバルソート機能のアルゴリズムは次のとおりです。 diff --git a/tiflash/tiflash-mintso-scheduler.md b/tiflash/tiflash-mintso-scheduler.md index e4149b573fd46..8f6dcc85c8238 100644 --- a/tiflash/tiflash-mintso-scheduler.md +++ b/tiflash/tiflash-mintso-scheduler.md @@ -15,7 +15,7 @@ MPPクエリを処理する際、TiDBはクエリを1つ以上のMPPタスクに 高い同時実行性が必要なシナリオで TiFlash の処理能力を向上させるには、 TiFlashに MPP タスク スケジューラを導入する必要があります。 -## 実施原則 {#implementation-principles} +## 実装原理 {#implementation-principles} [背景](#background)で述べたように、 TiFlashタスクスケジューラを導入する当初の目的は、MPP クエリ実行中に使用されるスレッド数を制御することです。シンプルなスケジューリング戦略は、 TiFlash が要求できる最大スレッド数を指定することです。スケジューラは、各 MPP タスクについて、システムで現在使用されているスレッド数と、MPP タスクが使用すると予想されるスレッド数に基づいて、その MPP タスクをスケジュールできるかどうかを判断します。 diff --git a/tikv-in-memory-engine.md b/tikv-in-memory-engine.md index 1c552d8a68f68..cb2d4cf865eda 100644 --- a/tikv-in-memory-engine.md +++ b/tikv-in-memory-engine.md @@ -12,7 +12,7 @@ TiKV MVCCインメモリエンジンは、以下のシナリオに適してい - 頻繁に更新または削除されるレコードを照会する必要があるアプリケーション。 - TiDBに履歴バージョンをより長い期間（例えば24時間）保持するために、 [`tidb_gc_life_time`](/garbage-collection-configuration.md#garbage-collection-configuration)調整する必要があるアプリケーション。 -## 実施原則 {#implementation-principles} +## 実装原理 {#implementation-principles} TiKV MVCCインメモリエンジンは、最新の書き込み済みMVCCバージョンをメモリにキャッシュし、TiDBとは独立したMVCC GCメカニズムを実装しています。これにより、メモリ内のMVCCバージョンに対して高速なGCを実行でき、クエリ中にスキャンされるバージョンの数を削減することで、リクエストのレイテンシーを低減し、CPUオーバーヘッドを削減します。