diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md index adfc41015802e..476d0d87b7e76 100644 --- a/best-practices/best-practices-on-public-cloud.md +++ b/best-practices/best-practices-on-public-cloud.md @@ -137,7 +137,7 @@ TiDBを複数のアベイラビリティゾーン（AZ）にまたがってデ AZ間の読み取りトラフィックを削減するには、 [Follower Read機能](/follower-read.md)を有効にします。これにより、TiDBは同じアベイラビリティゾーン内のレプリカを優先的に選択します。この機能を有効にするには、 [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)変数を`closest-replicas`または`closest-adaptive`に設定します。 -TiFlash MPPタスクのデータシャッフルによって発生するネットワークトラフィックを削減するため、複数のTiFlashインスタンスを同じアベイラビリティゾーン（AZ）にデプロイすることをお勧めします。v6.6.0以降では、 [圧縮交換](/explain-mpp.md#mpp-version-and-exchange-data-compression)デフォルトで有効になっており、MPPデータシャッフルによって発生するネットワークトラフィックを削減します。 +TiFlash MPPタスクのデータシャッフルによって発生するネットワークトラフィックを削減するため、複数のTiFlashインスタンスを同じアベイラビリティゾーン（AZ）にデプロイすることをお勧めします。v6.6.0以降では、 [圧縮交換](/explain-mpp.md#mpp-version-and-exchange-data-compression)はデフォルトで有効になっており、MPPデータシャッフルによって発生するネットワークトラフィックを削減します。 ## Google Cloud でのライブ マイグレーション メンテナンス イベントを軽減する {#mitigate-live-migration-maintenance-events-on-google-cloud} diff --git a/faq/manage-cluster-faq.md b/faq/manage-cluster-faq.md index f5e03b86f52f8..2c6e16f717f3f 100644 --- a/faq/manage-cluster-faq.md +++ b/faq/manage-cluster-faq.md @@ -49,7 +49,7 @@ MySQL と同様に、TiDB にはシステムテーブルも含まれており、 TiDB v6.1.0 では、グローバルキル機能が導入されました (デフォルトで有効になっている`enable-global-kill`設定によって制御されます)。グローバルキルが有効になっている場合は、 `kill session_id`を実行するだけです。 - TiDB のバージョンが v6.1.0 より前、またはグローバル キル機能が有効になっていない場合、 `kill session_id`デフォルトでは有効になりません。DML ステートメントを終了するには、クライアントを DML ステートメントを実行している TiDB インスタンスに直接接続してから、 `kill tidb session_id`ステートメントを実行する必要があります。クライアントが別の TiDB インスタンスに接続している場合、またはクライアントと TiDB クラスタの間にプロキシがある場合、 `kill tidb session_id`ステートメントが別の TiDB インスタンスにルーティングされ、別のセッションが誤って終了する可能性があります。詳細については、[`KILL`](/sql-statements/sql-statement-kill.md)を参照してください。 + TiDB のバージョンが v6.1.0 より前、またはグローバル キル機能が有効になっていない場合、 `kill session_id`はデフォルトでは有効になりません。DML ステートメントを終了するには、クライアントを DML ステートメントを実行している TiDB インスタンスに直接接続してから、 `kill tidb session_id`ステートメントを実行する必要があります。クライアントが別の TiDB インスタンスに接続している場合、またはクライアントと TiDB クラスタの間にプロキシがある場合、 `kill tidb session_id`ステートメントが別の TiDB インスタンスにルーティングされ、別のセッションが誤って終了する可能性があります。詳細については、[`KILL`](/sql-statements/sql-statement-kill.md)を参照してください。 - DDL ステートメントを強制終了するには、まず`admin show ddl jobs`を使用して終了する必要のある DDL ジョブの ID を見つけ、次に`admin cancel ddl jobs 'job_id' [, 'job_id'] ...`を実行します。詳細については、 [`ADMIN`ステートメント](/sql-statements/sql-statement-admin.md)を参照してください。 diff --git a/hybrid-deployment-topology.md b/hybrid-deployment-topology.md index a235c176cfdfb..67d4251b4ce66 100644 --- a/hybrid-deployment-topology.md +++ b/hybrid-deployment-topology.md @@ -100,6 +100,6 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて > **Note:** > > - 構成ファイル テンプレートを編集するときは、必要なパラメータ、IP、ポート、およびディレクトリを変更します。 -> - 各コンポーネントは、グローバルポートの`/-`デフォルトでポート`deploy_dir`として使用します。例えば、TiDBがポート`4001`を指定した場合、そのポート`deploy_dir`デフォルトで`/tidb-deploy/tidb-4001`なります。したがって、マルチインスタンスのシナリオでは、デフォルト以外のポートを指定する場合、ディレクトリを再度指定する必要はありません。 +> - 各コンポーネントでは、グローバルポートの`/-`がデフォルトの`deploy_dir`として使用されます。例えば、TiDBにポート`4001`を指定した場合、そのポートの`deploy_dir`はデフォルトで`/tidb-deploy/tidb-4001`になります。したがって、マルチインスタンスのシナリオでは、デフォルト以外のポートを指定する場合でも、ディレクトリを再度指定する必要はありません。 > - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPTiUPコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、コントロールマシンと同じユーザーを維持することもできます。 > - デプロイメントディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index d1a3780c60ffb..20940e63c777a 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -169,7 +169,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - [ビュー](/views.md) で実行計画生成に干渉するグローバルオプティマイザヒントをサポートします [＃37887](https://github.com/pingcap/tidb/issues/37887) @[Reminiscent](https://github.com/Reminiscent) - ビューアクセスのシナリオによっては、最適なパフォーマンスを実現するために、ビュー内のクエリの実行計画にオプティマイザヒントを使用して介入する必要があります。TiDB v6.5.0以降、ビュー内のクエリブロックへのグローバルヒントの追加がサポートされ、クエリで定義されたヒントがビュー内で有効になります。この機能により、ネストされたビューを含む複雑なSQL文にヒントを挿入できるようになり、実行計画の制御が強化され、複雑な文のパフォーマンスが安定します。グローバルヒントを使用するには、 [クエリブロックに名前を付ける](/optimizer-hints.md#step-1-define-the-query-block-name-of-the-view-using-the-qb_name-hint)と[ヒント参照を指定する](/optimizer-hints.md#step-2-add-the-target-hints)必要です。 + ビューアクセスのシナリオによっては、最適なパフォーマンスを実現するために、ビュー内のクエリの実行計画にオプティマイザヒントを使用して介入する必要があります。TiDB v6.5.0以降、ビュー内のクエリブロックへのグローバルヒントの追加がサポートされ、クエリで定義されたヒントがビュー内で有効になります。この機能により、ネストされたビューを含む複雑なSQL文にヒントを挿入できるようになり、実行計画の制御が強化され、複雑な文のパフォーマンスが安定します。グローバルヒントを使用するには、 [クエリブロックに名前を付け](/optimizer-hints.md#step-1-define-the-query-block-name-of-the-view-using-the-qb_name-hint)、 [ヒント参照を指定する](/optimizer-hints.md#step-2-add-the-target-hints)必要があります。 詳細については[ドキュメント](/optimizer-hints.md#hints-that-take-effect-globally)を参照してください。 diff --git a/releases/release-8.2.0.md b/releases/release-8.2.0.md index 39db3bfc07354..e4db3e1bc0e04 100644 --- a/releases/release-8.2.0.md +++ b/releases/release-8.2.0.md @@ -180,7 +180,7 @@ TiDB バージョン: 8.2.0 - バージョン8.2.0以降、 [`enable-replica-selector-v2`](/tidb-configuration-file.md#enable-replica-selector-v2-new-in-v800)設定項目は非推奨となりました。TiKVへのRPCリクエスト送信時には、デフォルトで新しいバージョンのリージョンレプリカセレクタが使用されます。 - バージョン8.2.0以降、 BRスナップショット復元パラメータ`--concurrency`は非推奨となりました。代替手段として、 [`--tikv-max-restore-concurrency`](/br/use-br-command-line-tool.md#common-options)を使用して、スナップショット復元中のTiKVノードごとの同時実行タスクの最大数を設定できます。 - - v8.2.0 以降、 BRスナップショット復元パラメータ`--granularity`は非推奨となり、 [粗視化リージョン散乱アルゴリズム](/br/br-snapshot-guide.md#restore-cluster-snapshots)デフォルトで有効になります。 + - v8.2.0 以降、 BRスナップショット復元パラメータ`--granularity`は非推奨となり、 [粗視化リージョン散乱アルゴリズム](/br/br-snapshot-guide.md#restore-cluster-snapshots)はデフォルトで有効になります。 - 以下の機能は、将来のバージョンで廃止される予定です。 diff --git a/sql-statements/sql-statement-backup.md b/sql-statements/sql-statement-backup.md index 2fa792e0752ea..d93913cb88c5c 100644 --- a/sql-statements/sql-statement-backup.md +++ b/sql-statements/sql-statement-backup.md @@ -119,7 +119,7 @@ BACKUP DATABASE `test` TO 's3://example-bucket-2020/backup-05/' `RATE_LIMIT`を使用して、TiKVノードあたりの平均アップロード速度を制限し、ネットワーク帯域幅を削減します。 -バックアップが完了する前に、 `BACKUP`デフォルトでクラスタ上のデータに対してチェックサムを実行し、データの正当性を検証します。単一テーブルでのチェックサムタスクのデフォルトの同時実行数は 4 ですが、 `CHECKSUM_CONCURRENCY`パラメータを使用して調整できます。データの検証が不要であると確信している場合は、 `CHECKSUM`パラメータを`FALSE`に設定してチェックを無効にできます。 +バックアップが完了する前に、 `BACKUP`はデフォルトでクラスタ上のデータに対してチェックサムを実行し、データの正当性を検証します。単一テーブルでのチェックサムタスクのデフォルトの同時実行数は 4 ですが、 `CHECKSUM_CONCURRENCY`パラメータを使用して調整できます。データの検証が不要であると確信している場合は、 `CHECKSUM`パラメータを`FALSE`に設定してチェックを無効にできます。 テーブルとインデックスのバックアップにおいて、 BRが同時に実行できるタスクの数を指定するには、 `CONCURRENCY`パラメーターを使用します。このパラメーターは、 BR内のスレッドプールサイズを制御し、バックアップ操作のパフォーマンスと効率を最適化します。 diff --git a/sql-statements/sql-statement-set-transaction.md b/sql-statements/sql-statement-set-transaction.md index 5b820f9dbe897..612f0a8af063f 100644 --- a/sql-statements/sql-statement-set-transaction.md +++ b/sql-statements/sql-statement-set-transaction.md @@ -63,7 +63,7 @@ mysql> SHOW SESSION VARIABLES LIKE 'transaction_isolation'; ## MySQLとの互換性 {#mysql-compatibility} - TiDB は、構文でのみトランザクションを読み取り専用として設定する機能をサポートしています。 -- 分離レベル`READ-UNCOMMITTED`および`SERIALIZABLE`サポートされていません。 +- 分離レベル`READ-UNCOMMITTED`および`SERIALIZABLE`はサポートされていません。 - `REPEATABLE-READ`分離レベルは、MySQL と部分的に互換性のあるスナップショット分離テクノロジを使用することで実現されます。 - 悲観的トランザクションでは、TiDBはMySQLと互換性のある2つの分離レベル（`REPEATABLE-READ`と`READ-COMMITTED`）をサポートしています。詳細については、 [分離レベル](/transaction-isolation-levels.md)を参照してください。 diff --git a/ticdc/ticdc-compatibility.md b/ticdc/ticdc-compatibility.md index 98ba07be9a6ea..b19ce9f039659 100644 --- a/ticdc/ticdc-compatibility.md +++ b/ticdc/ticdc-compatibility.md @@ -115,8 +115,8 @@ TiCDCクラスタのバージョンに対応する`cdc`実行可能ファイル | バージョン | `sort-engine`機能 | 注記 | おすすめ | | :---------------------------------------------------- | :--------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :-------------------------------------------------------------- | | v4.0.11 またはそれ以前の v4.0 バージョン、v5.0.0-rc | これはチェンジフィード構成項目であり、 `file`ソーターと`unified`ソーターの一時ファイルディレクトリを指定します。 | これらのバージョンでは、 `file`ソーターと`unified`ソーターは**実験的機能**であり、本番環境での使用は推奨され**ません**。

複数のチェンジフィードが`unified`ソーターを`sort-engine`として使用する場合、実際の一時ファイルディレクトリは、いずれかのチェンジフィードの`sort-dir`構成になる可能性があり、各TiCDCノードで使用されるディレクトリは異なる可能性があります。 | `unified`ソーターを本番環境で使用することは推奨されません。 | -| v4.0.12、v4.0.13、v5.0.0、および v5.0.1 | これは、changefeed または`cdc server`の構成項目です。 | デフォルトでは、変更フィードの`sort-dir`設定は有効にならず、 `sort-dir`の`cdc server`設定は`/tmp/cdc_sort`にデフォルト設定されます。本番環境では`cdc server`のみを設定することをお勧めします。

TiUPを使用してTiCDCをデプロイする場合は、最新のTiUPバージョンを使用し、TiCDCサーバー構成で`sorter.sort-dir`を設定することをお勧めします。

`unified`ソーターは、v4.0.13、v5.0.0、v5.0.1 でデフォルトで有効になっています。クラスターをこれらのバージョンにアップグレードする場合は、TiCDCサーバー構成で`sorter.sort-dir`正しく構成されていることを確認してください。 | `sort-dir` `cdc server`コマンドラインパラメータ (またはTiUP) を使用して設定する必要があります。 | -| v4.0.14以降、v4.0バージョン、v5.0.3以降、v5.0バージョン、それ以降のTiDBバージョン | `sort-dir`は非推奨です。 `data-dir`を設定することをお勧めします。 | 最新バージョンのTiUPを使用して`data-dir`を構成できます。これらの TiDB バージョンでは、 `unified`ソーターがデフォルトで有効になっています。クラスターをアップグレードする際は、 `data-dir`正しく構成されていることを確認してください。そうでない場合、 `/tmp/cdc_data`デフォルトで一時ファイル ディレクトリとして使用されます。

ディレクトリが配置されているデバイスのストレージ容量が不足している場合、ハードディスクの空き容量不足の問題が発生する可能性があります。この場合、changefeed の以前の`sort-dir`設定は無効になります。 | `data-dir` `cdc server`コマンドラインパラメータ (またはTiUP) を使用して設定する必要があります。 | +| v4.0.12、v4.0.13、v5.0.0、および v5.0.1 | これは、changefeed または`cdc server`の構成項目です。 | デフォルトでは、変更フィードの`sort-dir`設定は有効にならず、 `sort-dir`の`cdc server`設定は`/tmp/cdc_sort`にデフォルト設定されます。本番環境では`cdc server`のみを設定することをお勧めします。

TiUPを使用してTiCDCをデプロイする場合は、最新のTiUPバージョンを使用し、TiCDCサーバー構成で`sorter.sort-dir`を設定することをお勧めします。

`unified`ソーターは、v4.0.13、v5.0.0、v5.0.1 でデフォルトで有効になっています。クラスターをこれらのバージョンにアップグレードする場合は、TiCDCサーバー構成で`sorter.sort-dir`が正しく構成されていることを確認してください。 | `sort-dir`を`cdc server`コマンドラインパラメータ (またはTiUP) を使用して設定する必要があります。 | +| v4.0.14以降のv4.0バージョン、v5.0.3以降のv5.0バージョン、それ以降のTiDBバージョン | `sort-dir`は非推奨です。 `data-dir`を設定することをお勧めします。 | 最新バージョンのTiUPを使用して`data-dir`を構成できます。これらの TiDB バージョンでは、 `unified`ソーターがデフォルトで有効になっています。クラスターをアップグレードする際は、 `data-dir`が正しく構成されていることを確認してください。そうでない場合、 `/tmp/cdc_data`はデフォルトで一時ファイル ディレクトリとして使用されます。

ディレクトリが配置されているデバイスのストレージ容量が不足している場合、ハードディスクの空き容量不足の問題が発生する可能性があります。この場合、changefeed の以前の`sort-dir`設定は無効になります。 | `data-dir`を`cdc server`コマンドラインパラメータ (またはTiUP) を使用して設定する必要があります。 | | v6.0.0以降のバージョン | `data-dir` TiCDC によって生成された一時ファイルを保存するために使用されます。 | バージョン6.0.0以降、TiCDCはデフォルトで`db sorter`ソートエンジンとして使用します。 `data-dir`はこのエンジンのディスクディレクトリです。 | `data-dir` `cdc server`コマンドラインパラメータ (またはTiUP) を使用して設定する必要があります。 | ### 一時テーブルとの互換性 {#compatibility-with-temporary-tables} diff --git a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md index 59a43fe4b09f5..e44182f3b7e86 100644 --- a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md +++ b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md @@ -19,7 +19,7 @@ aliases: ['/ja/tidbcloud/tidb-cloud-encrypt-cmek'] - 現在、 TiDB Cloud はCMEK を提供するために AWS KMS と Azure Key Vault の使用のみをサポートしています。 - CMEK を使用するには、プロジェクトの作成時に CMEK を有効にし、クラスタを作成する前に CMEK 関連の設定を完了する必要があります。既存のプロジェクトでは CMEK を有効にできません。 - 現在、CMEK 対応プロジェクトでは、AWS と Azure でホストされるクラスターを[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)つだけ作成できます。 -- 現在、CMEK 対応プロジェクトでは、 [デュアルリージョンバックアップ](/tidb-cloud/backup-and-restore-concepts.md#dual-region-backup)サポートされていません。 +- 現在、CMEK 対応プロジェクトでは、 [デュアルリージョンバックアップ](/tidb-cloud/backup-and-restore-concepts.md#dual-region-backup)はサポートされていません。 - 現在、CMEK 対応プロジェクトでは、AWS と Azure で CMEK を有効化できます。クラウドプロバイダーごとに、リージョンごとに 1つの固有の暗号化キーを設定できます。選択したクラウドプロバイダーの暗号化キーを設定したリージョンでのみ、クラスタを作成できます。 ## CMEKを有効にする {#enable-cmek} diff --git a/tidb-rowid.md b/tidb-rowid.md index 7c425b5a740f3..ec0c376f2f491 100644 --- a/tidb-rowid.md +++ b/tidb-rowid.md @@ -38,7 +38,7 @@ SELECT _tidb_rowid, a, b FROM t1; SELECT _tidb_rowid, id, a FROM t2; ``` -`t3`の場合、クラスター化された主キーが既に行識別子になっているため、 `_tidb_rowid`利用できません。 +`t3`の場合、クラスター化された主キーが既に行識別子になっているため、 `_tidb_rowid`は利用できません。 ```sql SELECT _tidb_rowid, id, a FROM t3;