diff --git a/ai/guides/join-queries.md b/ai/guides/join-queries.md index 484bf97860578..19671fd844576 100644 --- a/ai/guides/join-queries.md +++ b/ai/guides/join-queries.md @@ -14,7 +14,7 @@ summary: アプリケーションで複数のテーブル結合を使用する
-すでに[TiDBに接続](/ai/guides/connect.md)使用して`TiDBClient`あると仮定します。 +すでに[TiDBに接続](/ai/guides/connect.md)し、`TiDBClient`インスタンスがあるものと仮定します。 `documents`テーブルを作成し、いくつかのサンプル データを挿入します。 diff --git a/alert-rules.md b/alert-rules.md index 3b736b346f521..e36b896c596b9 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -449,7 +449,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME = "tikv_gc_leader_desc"`実行して、GC リーダーに対応する`tidb-server`を見つけます。 2. `tidb-server`のログを確認し、`grep gc_worker tidb.log` を実行します。 - 3. この時間中にGCワーカーがロックを解決中（最後のログは「start resolve locks」）または範囲を削除中（最後のログは「start delete {number} ranges」）であることが確認された場合、GCプロセスは正常に動作していることを意味します。それ以外の場合は、PingCAPまたはコミュニティから[サポートを受ける](/support.md)取得してください。 + 3. この時間中にGCワーカーがロックを解決中（最後のログは「start resolve locks」）または範囲を削除中（最後のログは「start delete {number} ranges」）であることが確認された場合、GCプロセスは正常に動作していることを意味します。それ以外の場合は、PingCAPまたはコミュニティから[サポートを受けて](/support.md)ください。 ### 重大レベルのアラート {#critical-level-alerts} diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md index d44bb2d93fdf4..caadbf6f0f0e5 100644 --- a/best-practices/tidb-partitioned-tables-best-practices.md +++ b/best-practices/tidb-partitioned-tables-best-practices.md @@ -365,7 +365,7 @@ TiDBは新しい行とインデックスエントリを「右端」のリージ > > このセクションでは、読み取りおよび書き込みホットスポットを軽減するための例として、パーティションテーブルを使用します。TiDB は、 [`AUTO_INCREMENT`](/auto-increment.md)や[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)などのホットスポット軽減のための追加機能も提供しています。 > -> 特定のシナリオでパーティションテーブルを使用する場合は、パーティション境界を維持するために`merge_option=deny`設定してください。詳細については[問題 #58128](https://github.com/pingcap/tidb/issues/58128)参照してください。 +> 特定のシナリオでパーティションテーブルを使用する場合は、パーティション境界を維持するために`merge_option=deny`を設定してください。詳細については[問題 #58128](https://github.com/pingcap/tidb/issues/58128)を参照してください。 ### パーティショニングの仕組み {#how-partitioning-works} diff --git a/best-practices/uuid.md b/best-practices/uuid.md index 612711f0681cb..900256df7a739 100644 --- a/best-practices/uuid.md +++ b/best-practices/uuid.md @@ -22,7 +22,7 @@ UUID を主キーとして使用すると、 [`AUTO_INCREMENT`](/auto-increment. ### バイナリとして保存 {#store-as-binary} -テキスト形式のUUID形式は次のようになります`ab06f63e-8fe7-11ec-a514-5405db7aad56`は36文字の文字列です。[`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin)使用すると、テキスト形式を16バイトのバイナリ形式に変換できます。これにより、テキストを[`BINARY(16)`](/data-type-string.md#binary-type)列に格納できます。UUIDを取得する際には、 [`BIN_TO_UUID()`](/functions-and-operators/miscellaneous-functions.md#bin_to_uuid)関数を使用してテキスト形式に戻すことができます。 +テキスト形式のUUID（例えば`ab06f63e-8fe7-11ec-a514-5405db7aad56`）は36文字の文字列です。[`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin)使用すると、テキスト形式を16バイトのバイナリ形式に変換できます。これにより、テキストを[`BINARY(16)`](/data-type-string.md#binary-type)列に格納できます。UUIDを取得する際には、 [`BIN_TO_UUID()`](/functions-and-operators/miscellaneous-functions.md#bin_to_uuid)関数を使用してテキスト形式に戻すことができます。 ### UUID形式のバイナリ順序とクラスター化された主キー {#uuid-format-binary-order-and-clustered-primary-keys} diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index 8a37e941c407b..b8c6d0761edd3 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -77,7 +77,7 @@ Global Flags: - `task-name` : ログバックアップのタスク名を指定します。この名前は、バックアップタスクのクエリ、一時停止、再開にも使用されます。 - `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。 - `--pd` : バックアップ クラスターの PD アドレスを指定します。BRはログ バックアップ タスクを開始するために PD にアクセスする必要があります。 -- `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのstorageとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのストレージとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 使用例: @@ -349,7 +349,7 @@ Global Flags: - `--dry-run` : コマンドを実行しますが、実際にはファイルを削除しません。 - `--until` : 指定されたタイムスタンプより前のすべてのログ バックアップ データを削除します。 -- `--storage` : バックアップストレージのアドレス。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--storage` : バックアップストレージのアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 使用例: @@ -390,7 +390,7 @@ Global Flags: このコマンドはバックアップストレージにのみアクセスし、TiDB クラスターにはアクセスしません。 -`--storage`パラメータはバックアップストレージのアドレスを指定するために使用されます。現在、 BR はログバックアップのstorageとして Amazon S3、GCS、または Azure Blob Storage をサポートしています。詳細については[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +`--storage`パラメータはバックアップストレージのアドレスを指定するために使用されます。現在、 BR はログバックアップのストレージとして Amazon S3、GCS、または Azure Blob Storage をサポートしています。詳細については[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 使用例: @@ -441,7 +441,7 @@ Global Flags: 出力例には共通パラメータのみが表示されています。これらのパラメータは以下のように記述されます。 -- `--full-backup-storage` : スナップショット（フル）バックアップのストレージアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--full-backup-storage` : スナップショット（フル）バックアップのストレージアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 - `--pitr-batch-count` : ログデータを復元する際の、1バッチあたりのファイル数の上限。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 - `--pitr-batch-size` : ログデータを復元する際の単一バッチの最大データサイズ（バイト単位）。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 - `--pitr-concurrency` : ログ復元中の同時タスク数。各同時タスクは、一度に1バッチのログデータを復元します。 @@ -449,7 +449,7 @@ Global Flags: - `--start-ts` : ログバックアップデータを復元する開始タイムスタンプ。ログバックアップデータのみを復元する必要がある場合は、このパラメータを指定する必要があります。 - `--pd` : 復元クラスターの PD アドレス。 - `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。 -- `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 使用例: diff --git a/br/br-snapshot-architecture.md b/br/br-snapshot-architecture.md index 441b8309236f4..5d5df295b02a4 100644 --- a/br/br-snapshot-architecture.md +++ b/br/br-snapshot-architecture.md @@ -160,7 +160,7 @@ sequenceDiagram ### SSTファイルの保存形式 {#storage-format-of-sst-files} - SST ファイルのストレージ形式の詳細については、 [RocksDBブロックベーステーブル形式](https://github.com/facebook/rocksdb/wiki/Rocksdb-BlockBasedTable-Format)を参照してください。 -- SST ファイルのバックアップ データのエンコード形式の詳細については、「テーブルデータ[テーブルデータのキー値へのマッピング](/tidb-computing.md#mapping-table-data-to-key-value)参照してください。 +- SST ファイルのバックアップ データのエンコード形式の詳細については、[テーブルデータのキー値へのマッピング](/tidb-computing.md#mapping-table-data-to-key-value)を参照してください。 ### バックアップファイルの構造 {#structure-of-backup-files} diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md index 581210cb32cd6..eaaadea742c80 100644 --- a/br/br-snapshot-manual.md +++ b/br/br-snapshot-manual.md @@ -182,7 +182,7 @@ tiup br restore full \ 上記のコマンドでは、次のようになります。 -- `--with-sys-table` : BR は、アカウント権限データ、SQL バインディング、統計情報など、**一部のシステムテーブルのデータ**を復元します（ [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)参照）。ただし、統計テーブル（ `mysql.stat_*` ）とシステム変数テーブル（ `mysql.tidb`および`mysql.global_variables` ）は復元されません。詳細については、 [`mysql`スキーマ内のテーブルを復元する](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema)参照してください。 +- `--with-sys-table` : BR は、アカウント権限データ、SQL バインディング、統計情報など、**一部のシステムテーブルのデータ**を復元します（ [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)を参照）。ただし、統計テーブル（ `mysql.stat_*` ）とシステム変数テーブル（ `mysql.tidb`および`mysql.global_variables` ）は復元されません。詳細については、 [`mysql`スキーマ内のテーブルを復元する](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema)参照してください。 - `--ratelimit` : 復元タスクを実行する**TiKVあたりの**最大速度。単位はMiB/sです。 - `--log-file` : `br`ログが書き込まれる対象ファイル。 diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md index d208ab115d40a..42b56577212c3 100644 --- a/data-type-date-and-time.md +++ b/data-type-date-and-time.md @@ -125,7 +125,7 @@ TIMESTAMP[(fsp)] #### タイムゾーンの処理 {#timezone-handling} -`TIMESTAMP`保存する場合、TiDB は`TIMESTAMP`値を現在のタイムゾーンから UTC タイムゾーンに変換します。5 `TIMESTAMP`取得する場合、TiDB は保存されている`TIMESTAMP`値を UTC タイムゾーンから現在のタイムゾーンに変換します（注: `DATETIME`この方法では処理されません）。各接続のデフォルトのタイムゾーンはサーバーのローカルタイムゾーンですが、環境変数`time_zone`で変更できます。 +`TIMESTAMP`保存する場合、TiDB は`TIMESTAMP`値を現在のタイムゾーンから UTC タイムゾーンに変換します。`TIMESTAMP`取得する場合、TiDB は保存されている`TIMESTAMP`値を UTC タイムゾーンから現在のタイムゾーンに変換します（注: `DATETIME`この方法では処理されません）。各接続のデフォルトのタイムゾーンはサーバーのローカルタイムゾーンですが、環境変数`time_zone`で変更できます。 > **警告：** > diff --git a/develop/dev-guide-aws-appflow-integration.md b/develop/dev-guide-aws-appflow-integration.md index 9e1e3004c6820..58ae13d48f0ce 100644 --- a/develop/dev-guide-aws-appflow-integration.md +++ b/develop/dev-guide-aws-appflow-integration.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-aws-appflow-integration/','/ja/tidb/dev/dev # TiDBとAmazon AppFlowを統合する {#integrate-tidb-with-amazon-appflow} -[Amazon AppFlow](https://aws.amazon.com/appflow/) Software as a Service (SaaS) アプリケーションを AWS サービスに接続し、データを安全に転送するために使用するフルマネージド API 統合サービスです。 Amazon AppFlow を使用すると、TiDB との間で、Salesforce、Amazon S3、LinkedIn、GitHub などのさまざまなタイプのデータプロバイダーにデータをインポートおよびエクスポートできます。詳細については、AWS ドキュメントの[サポートされている送信元および送信先アプリケーション](https://docs.aws.amazon.com/appflow/latest/userguide/app-specific.html)参照してください。 +[Amazon AppFlow](https://aws.amazon.com/appflow/)は、Software as a Service (SaaS) アプリケーションを AWS サービスに接続し、データを安全に転送するために使用するフルマネージド API 統合サービスです。 Amazon AppFlow を使用すると、TiDB との間で、Salesforce、Amazon S3、LinkedIn、GitHub などのさまざまなタイプのデータプロバイダーにデータをインポートおよびエクスポートできます。詳細については、AWS ドキュメントの[サポートされている送信元および送信先アプリケーション](https://docs.aws.amazon.com/appflow/latest/userguide/app-specific.html)参照してください。 このドキュメントでは、TiDBをAmazon AppFlowと統合する方法について説明し、 TiDB Cloud Starterインスタンスの統合を例として取り上げます。 diff --git a/develop/dev-guide-choose-driver-or-orm.md b/develop/dev-guide-choose-driver-or-orm.md index 849f0068982c2..08574841562d9 100644 --- a/develop/dev-guide-choose-driver-or-orm.md +++ b/develop/dev-guide-choose-driver-or-orm.md @@ -93,7 +93,7 @@ implementation group: 'org.bouncycastle', name: 'bcpkix-jdk15on', version: '1.67 > **注記：** > -> - 現在、Hibernate は[ネストされたトランザクションをサポートしていません](https://stackoverflow.com/questions/37927208/nested-transaction-in-spring-app-with-jpa-postgres)実行します。 +> - 現在、Hibernate は[ネストされたトランザクションをサポートしていません](https://stackoverflow.com/questions/37927208/nested-transaction-in-spring-app-with-jpa-postgres)。 > > - TiDBはv6.2.0以降、 [セーブポイント](/sql-statements/sql-statement-savepoint.md)サポートしています。5 `@Transactional` `Propagation.NESTED`トランザクション伝播オプションを使用するには、つまり`@Transactional(propagation = Propagation.NESTED)`設定するには、TiDBがv6.2.0以降であることを確認してください。 diff --git a/develop/dev-guide-sample-application-java-hibernate.md b/develop/dev-guide-sample-application-java-hibernate.md index 33ab298145d28..d5027ca36ea6e 100644 --- a/develop/dev-guide-sample-application-java-hibernate.md +++ b/develop/dev-guide-sample-application-java-hibernate.md @@ -325,7 +325,7 @@ TiDBで`CHECK`制約の適用を有効にするには、次のシステム変数 SET GLOBAL tidb_enable_check_constraint=ON; ``` -この設定がない場合、TiDB は`CHECK`制約構文を受け入れますが、それを強制しないため、予期しないデータ整合性の問題が発生する可能性があります。詳細については、 [`CHECK`制約](/constraints.md#check)参照してください。 。 +この設定がない場合、TiDB は`CHECK`制約構文を受け入れますが、それを強制しないため、予期しないデータ整合性の問題が発生する可能性があります。詳細については、 [`CHECK`制約](/constraints.md#check)を参照してください。 ## 次のステップ {#next-steps} diff --git a/develop/dev-guide-vector-search.md b/develop/dev-guide-vector-search.md index 6dd304962e9b9..1827b09edf88e 100644 --- a/develop/dev-guide-vector-search.md +++ b/develop/dev-guide-vector-search.md @@ -24,7 +24,7 @@ TiDB ベクトル検索を開始するには、次のチュートリアルを参 開発を加速させるために、TiDBベクトル検索を一般的なAIフレームワーク（LlamaIndexやLangChainなど）、埋め込みサービス（Jina AIなど）、ORMライブラリ（SQLAlchemy、Peewee、Django ORMなど）と統合できます。ニーズに最適なものを選択できます。 -詳細については[TiDB の AI 統合](/ai/integrations/vector-search-integration-overview.md)参照してください. +詳細については[TiDB の AI 統合](/ai/integrations/vector-search-integration-overview.md)を参照してください。 ## テキスト検索 {#text-search} diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index e29099d16ee54..119541f9c4c7d 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -252,7 +252,7 @@ hikari: - `maximumPoolSize` : プール内の最大接続数。デフォルト値は`10`です。コンテナ化された環境では、 Javaアプリケーションで使用可能な CPU コア数の 4～10 倍に設定することをお勧めします。この値を高く設定しすぎるとリソースの無駄遣いにつながり、低く設定しすぎると接続の取得が遅くなる可能性があります。 詳細については、を参照[プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)ください。 - `minimumIdle` : HikariCPでは、このパラメータを設定しないことを推奨します。デフォルト値は`maximumPoolSize`の値と同じで、接続プールのスケーリングを無効にします。これにより、トラフィックの急増時にも接続がすぐに利用可能になり、接続作成による遅延を回避できます。 - `connectionTimeout` : アプリケーションが接続プールから接続を取得するために待機する最大時間 (ミリ秒)。デフォルト値は`30000`ミリ秒 (30 秒) です。この時間内に利用可能な接続が得られない場合、 `SQLException`例外が発生します。 -- `maxLifetime` : プール内の接続の最大有効期間 (ミリ秒)。デフォルト値は`1800000`ミリ秒 (30 分) です。使用中の接続には影響しません。接続が閉じられた後、この設定に従って削除されます。この値を低く設定しすぎると、再接続が頻繁に発生する可能性があります。graceful [`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)使用している場合は、この値が待機時間よりも小さいことを確認してください。 +- `maxLifetime` : プール内の接続の最大有効期間 (ミリ秒)。デフォルト値は`1800000`ミリ秒 (30 分) です。使用中の接続には影響しません。接続が閉じられた後、この設定に従って削除されます。この値を低く設定しすぎると、再接続が頻繁に発生する可能性があります。[`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)を使用している場合は、この値が待機時間よりも小さいことを確認してください。 - `keepaliveTime` : プール内の接続に対するキープアライブ操作の間隔 (ミリ秒)。この設定は、データベースまたはネットワークのアイドルタイムアウトによって発生する切断を防ぐのに役立ちます。デフォルト値は`120000`ミリ秒 (2 分) です。プールは、アイドル状態の接続を維持するために JDBC4 `isValid()`メソッドを使用することを優先します。 ### プローブ構成 {#probe-configuration} @@ -260,7 +260,7 @@ hikari: 接続プールは、以下のようにクライアントからTiDBへの永続的な接続を維持します。 - バージョン5.4より前のTiDBでは、デフォルトでは（エラーが報告されない限り）クライアント接続を積極的に閉じることはありません。 -- バージョン5.4以降、TiDBはデフォルトで`28800`秒（つまり`8`時間）の非アクティブ状態が続くと、クライアント接続を自動的に閉じます。このタイムアウト設定は、TiDBおよびMySQL互換の`wait_timeout`変数を使用して制御できます。詳細については、 [JDBCクエリタイムアウト](/develop/dev-guide-timeouts-in-tidb.md#jdbc-query-timeout)参照してください。 . +- バージョン5.4以降、TiDBはデフォルトで`28800`秒（つまり`8`時間）の非アクティブ状態が続くと、クライアント接続を自動的に閉じます。このタイムアウト設定は、TiDBおよびMySQL互換の`wait_timeout`変数を使用して制御できます。詳細については、 [JDBCクエリタイムアウト](/develop/dev-guide-timeouts-in-tidb.md#jdbc-query-timeout)を参照してください。 さらに、クライアントとTiDBの間には、 [LVS](https://en.wikipedia.org/wiki/Linux_Virtual_Server)や[HAProxy](https://en.wikipedia.org/wiki/HAProxy)などのネットワークプロキシが存在する場合があります。これらのプロキシは通常、特定のアイドル期間（プロキシのアイドル設定によって決定されます）が経過すると、接続を自動的にクリーンアップします。接続プールは、プロキシのアイドル設定を監視するだけでなく、キープアライブのために接続を維持またはプローブする必要もあります。 diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index 333bccef7ece4..372a616937875 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -113,7 +113,7 @@ alertmanager_servers: > > - 特定のノードで有効にするパラメータについては、このノードの`config`でこれらのパラメータを設定します。 > -> - `.`構成のサブカテゴリ（例： `log.slow-threshold`を示します。その他の形式については、 [TiUP構成テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml)参照してください。 +> - `.`は構成のサブカテゴリ（例： `log.slow-threshold`）を示します。その他の形式については、 [TiUP構成テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml)参照してください。 > > - 詳細なパラメータの説明については、 [マスター`config.toml.example`](https://github.com/pingcap/tiflow/blob/release-8.5/dm/master/dm-master.toml)と[ワーカー`config.toml.example`](https://github.com/pingcap/tiflow/blob/release-8.5/dm/worker/dm-worker.toml)参照してください。 > diff --git a/dm/dm-precheck.md b/dm/dm-precheck.md index 87702d5be2c2b..708323899dff9 100644 --- a/dm/dm-precheck.md +++ b/dm/dm-precheck.md @@ -50,7 +50,7 @@ tiup dmctl check-task ./task.yaml - アップストリームのMySQLテーブルスキーマの互換性 - - アップストリームテーブルに外部キーがあるかどうかを確認してください。TiDBは外部キーをサポートしています（v8.5.0以降でGA）。また、DMはv8.5.6以降、外部キー制約を持つテーブルのレプリケーションを実験的にサポートしています。事前チェック中に、外部キーが検出された場合、DMは警告を返します。サポートされているシナリオと制限事項については、 [DM互換性カタログ](/dm/dm-compatibility-catalog.md#foreign-key-cascade-operations)参照してください。 . + - アップストリームテーブルに外部キーがあるかどうかを確認してください。TiDBは外部キーをサポートしています（v8.5.0以降でGA）。また、DMはv8.5.6以降、外部キー制約を持つテーブルのレプリケーションを実験的にサポートしています。事前チェック中に、外部キーが検出された場合、DMは警告を返します。サポートされているシナリオと制限事項については、 [DM互換性カタログ](/dm/dm-compatibility-catalog.md#foreign-key-cascade-operations)を参照してください。 - 上流のテーブルで TiDB と互換性のない文字セットが使用されていないか確認してください。詳細については、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)参照してください。 diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index 44d182539271f..e467552976db3 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -412,4 +412,4 @@ storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=ht ## トラブルシューティング {#troubleshooting} -前の手順で問題が発生した場合は、まず[TiDBに関するよくある質問](/faq/faq-overview.md)で問題の解決策を見つけてください。問題が解決しない場合は、 [バグを報告する](/support.md)実行してください。 +前の手順で問題が発生した場合は、まず[TiDBに関するよくある質問](/faq/faq-overview.md)で問題の解決策を見つけてください。問題が解決しない場合は、 [バグを報告](/support.md)してください。 diff --git a/dumpling-overview.md b/dumpling-overview.md index 153f8d378711e..432d36c9debe2 100644 --- a/dumpling-overview.md +++ b/dumpling-overview.md @@ -217,7 +217,7 @@ tiup dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test --filetype csv --sql 'se バージョン4.0.8以降、 Dumplingはクラウドストレージへのデータエクスポートをサポートしています。Amazon S3にデータをバックアップする必要がある場合は、 `-o`パラメータでAmazon S3ストレージパスを指定する必要があります。 -指定されたリージョンに Amazon S3 バケットを作成する必要があります ( [Amazonドキュメント - S3バケットの作成方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)参照)。バケット内にフォルダーを作成する必要がある場合は、 [Amazonドキュメント - フォルダの作成](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-folder.html)参照してください。 +指定されたリージョンに Amazon S3 バケットを作成する必要があります ( [Amazonドキュメント - S3バケットの作成方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)を参照)。バケット内にフォルダーを作成する必要がある場合は、 [Amazonドキュメント - フォルダの作成](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-folder.html)参照してください。 Amazon S3バックエンドストレージへのアクセス権限を持つアカウントの`SecretKey`と`AccessKey`を環境変数としてDumplingノードに渡します。 diff --git a/external-storage-uri.md b/external-storage-uri.md index 4fc4e4c1be64c..6fb79cb6f854f 100644 --- a/external-storage-uri.md +++ b/external-storage-uri.md @@ -31,8 +31,8 @@ URI の基本的な形式は次のとおりです。 - `sse` : アップロードされたオブジェクトの暗号化に使用されるサーバー側暗号化アルゴリズムを指定します (値のオプション: 空、 `AES256` 、または`aws:kms` )。 - `sse-kms-key-id` : `sse` `aws:kms`に設定されている場合は KMS ID を指定します。 - `acl` : アップロードされたオブジェクトの既定 ACL を指定します (たとえば、 `private`または`authenticated-read` )。 - - `role-arn` : 指定された[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)使用してサードパーティの Amazon S3 データにアクセスする必要がある場合、 `arn:aws:iam::888888888888:role/my-role`などの`role-arn` URL クエリパラメータで、対応する[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) IAMロールを指定できます。IAMIAMを使用してサードパーティの Amazon S3 データにアクセスする方法の詳細については、 [AWSドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)参照してください。BRはv7.6.0 以降でこのパラメータをサポートしています。 - - `external-id` : サードパーティから Amazon S3 データにアクセスする場合、正しい[外部ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)指定して[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)引き受けることが必要になる場合があります。この場合、この`external-id` URL クエリパラメータを使用して外部 ID を指定し、 IAMロールを引き受けることができることを確認できます。外部 ID は、Amazon S3 データにアクセスするためにIAMロール ARN と一緒にサードパーティによって提供される任意の文字列です。IAM ロールを引き受ける場合の外部 IDのIAMIAMに外部 ID を必要としない場合は、このパラメータを指定せずにIAMロールを引き受け、対応する Amazon S3 データにアクセスできます。 + - `role-arn` : 指定された[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)使用してサードパーティの Amazon S3 データにアクセスする必要がある場合、 `arn:aws:iam::888888888888:role/my-role`などの`role-arn` URL クエリパラメータで、対応する[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) IAMロールを指定できます。IAMを使用してサードパーティの Amazon S3 データにアクセスする方法の詳細については、 [AWSドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)参照してください。BRはv7.6.0 以降でこのパラメータをサポートしています。 + - `external-id` : サードパーティから Amazon S3 データにアクセスする場合、正しい[外部ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)指定して[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)引き受けることが必要になる場合があります。この場合、この`external-id` URL クエリパラメータを使用して外部 ID を指定し、 IAMロールを引き受けることができることを確認できます。外部 ID は、Amazon S3 データにアクセスするためにIAMロール ARN と一緒にサードパーティによって提供される任意の文字列です。IAM ロールを引き受ける場合の外部 IDのIAMに外部 ID を必要としない場合は、このパラメータを指定せずにIAMロールを引き受け、対応する Amazon S3 データにアクセスできます。 以下は、 TiDB LightningおよびBRの Amazon S3 URI の例です。この例では、特定のファイルパス`testfolder`指定する必要があります。 @@ -83,7 +83,7 @@ tiup cdc:v7.5.0 cli changefeed create \ > **注記：** > > - IAMロールを自動的に作成するには、 [TiDB Cloudコンソール](https://tidbcloud.com/)でクラスターの**[Amazon S3 からのデータのインポート]**ページに移動し、 **[フォルダー URI]**フィールドに入力し、 **[ロール ARN]**フィールドの [**ここをクリックして AWS CloudFormation で新しく作成] を**クリックして、 **[新しいロール ARN の追加]**ダイアログの画面上の指示に従います。 - > - AWS CloudFormation を使用してIAMロールを作成する際に問題が発生した場合は、 **「新しいロール ARN を追加」**ダイアログで**「問題が発生した場合は、ロール ARN を手動で作成する」を**クリックしてTiDB Cloudアカウント ID とTiDB Cloud外部 ID を取得し、 [ロール ARN を使用して Amazon S3 アクセスを構成する](https://docs.pingcap.com/tidbcloud/dedicated-external-storage#configure-amazon-s3-access-using-a-role-arn)の手順に従って手動でロールを作成してください。IAMIAMを設定する際は、 **「アカウント ID」**フィールドにTiDB Cloudアカウント ID を入力し、 [混乱した副官の攻撃](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)から保護するために**外部 ID を要求する」**を選択してください。 + > - AWS CloudFormation を使用してIAMロールを作成する際に問題が発生した場合は、 **「新しいロール ARN を追加」**ダイアログで**「問題が発生した場合は、ロール ARN を手動で作成する」を**クリックしてTiDB Cloudアカウント ID とTiDB Cloud外部 ID を取得し、 [ロール ARN を使用して Amazon S3 アクセスを構成する](https://docs.pingcap.com/tidbcloud/dedicated-external-storage#configure-amazon-s3-access-using-a-role-arn)の手順に従って手動でロールを作成してください。IAMを設定する際は、 **「アカウント ID」**フィールドにTiDB Cloudアカウント ID を入力し、 [混乱した副官の攻撃](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)から保護するために**外部 ID を要求する」**を選択してください。 > - セキュリティを強化するために、**最大セッション継続時間を**短く設定することで、 IAMロールの有効期間を短縮できます。詳細については、AWSドキュメントの[ロールの最大セッション期間を更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-settings.html#id_roles_update-session-duration)参照してください。 - `external-id` : TiDB Cloud がAmazon S3 データにアクセスするために必要なTiDB Cloud外部 ID を指定します。この ID は、 [TiDB Cloudコンソール](https://tidbcloud.com/)の**「新しいロール ARN を追加」**ダイアログから取得できます。詳細については、 [ロール ARN を使用して Amazon S3 アクセスを構成する](https://docs.pingcap.com/tidbcloud/dedicated-external-storage#configure-amazon-s3-access-using-a-role-arn)参照してください。 diff --git a/functions-and-operators/bit-functions-and-operators.md b/functions-and-operators/bit-functions-and-operators.md index c677541170875..6339da945e034 100644 --- a/functions-and-operators/bit-functions-and-operators.md +++ b/functions-and-operators/bit-functions-and-operators.md @@ -204,7 +204,7 @@ SELECT CONV(b'1010' ^ b'1100',10,2); `<<`演算子は左シフト演算を実行し、数値のビットを指定された位置数だけ左にシフトし、右側の空いたビットをゼロで埋めます。 -たとえば、次のステートメントでは、 `1< **注記** > -> - TiDBでは、 [`AUTO_ID_CACHE`](/auto-increment.md#auto_id_cache)指定するとMySQLが返す結果と異なる結果になる可能性があります。この不一致は、TiDBが各ノードにIDをキャッシュするため、IDの順序が乱れたり、IDに空白が生じたりする可能性があるためです。アプリケーションで厳密なID順序の維持が不可欠な場合は、 [MySQL互換モード](/auto-increment.md#mysql-compatibility-mode)有効にすることができます。 +> - TiDBでは、 [`AUTO_ID_CACHE`](/auto-increment.md#auto_id_cache)指定するとMySQLが返す結果と異なる結果になる可能性があります。この不一致は、TiDBが各ノードにIDをキャッシュするため、IDの順序が乱れたり、IDに空白が生じたりする可能性があるためです。アプリケーションで厳密なID順序の維持が不可欠な場合は、 [MySQL互換モード](/auto-increment.md#mysql-compatibility-mode)を有効にすることができます。 > > - 上の例ではIDが2ずつ増加しますが、MySQLでは同じシナリオでIDが1ずつ増加します。互換性に関する詳細は[AUTO_INCREMENT ID](/mysql-compatibility.md#auto-increment-id)参照してください。 diff --git a/releases/release-4.0-ga.md b/releases/release-4.0-ga.md index 2033849fa94e9..40e8478040fff 100644 --- a/releases/release-4.0-ga.md +++ b/releases/release-4.0-ga.md @@ -80,7 +80,7 @@ TiDB バージョン: 4.0.0 - `tidb_opt_agg_push_down`が有効になっていて、集計関数がパーティションテーブルをプッシュダウンしたときに、誤った処理ロジックによって発生するシステムパニックを修正しました。 [＃17328](https://github.com/pingcap/tidb/pull/17328) - 一部のケースで障害が発生した TiKV ノードにアクセスできない問題を修正[＃17342](https://github.com/pingcap/tidb/pull/17342) - `tidb.toml`の`isolation-read`設定項目が有効にならない問題を修正[＃17322](https://github.com/pingcap/tidb/pull/17322) - - `hint`使用してストリーム集約強制する場合に、処理ロジックが間違っているために出力結果の順序が間違っている問題を修正しました。 [＃17347](https://github.com/pingcap/tidb/pull/17347) + - `hint`を使用してストリーム集約を強制する場合に、処理ロジックが間違っているために出力結果の順序が間違っている問題を修正しました。 [＃17347](https://github.com/pingcap/tidb/pull/17347) - `insert`異なる`SQL_MODE` の下で DIV を処理する動作を修正 [＃17314](https://github.com/pingcap/tidb/pull/17314) - TiFlash diff --git a/releases/release-4.0.15.md b/releases/release-4.0.15.md index fa1cfafab23f0..c5225c147cf0a 100644 --- a/releases/release-4.0.15.md +++ b/releases/release-4.0.15.md @@ -62,7 +62,7 @@ TiDB バージョン: 4.0.15 - Dumpling - テーブル情報を取得する前にスキップしたデータベースをフィルタリングして、 `SHOW TABLE STATUS` のフィルタリング効率を向上させます。 [＃337](https://github.com/pingcap/dumpling/pull/337) - - エクスポートするテーブルのテーブル情報を取得するには`SHOW FULL TABLES`使用します。3 `SHOW TABLE STATUS`一部のMySQLバージョンでは正常に動作しないためです。 [＃322](https://github.com/pingcap/dumpling/issues/322) + - エクスポートするテーブルのテーブル情報を取得するには`SHOW FULL TABLES`を使用します。これは、`SHOW TABLE STATUS`が一部のMySQLバージョンでは正常に動作しないためです。 [＃322](https://github.com/pingcap/dumpling/issues/322) - `START TRANSACTION ... WITH CONSISTENT SNAPSHOT`または`SHOW CREATE TABLE`構文をサポートしていない MySQL 互換データベースのバックアップをサポート[＃309](https://github.com/pingcap/dumpling/issues/309) - Dumpling の警告ログを改良し、ダンプが失敗したという誤解を招く情報を回避する[＃340](https://github.com/pingcap/dumpling/pull/340) diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index 9e5140d35fe3f..c5d5006c285ac 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -399,7 +399,7 @@ FROM ( 実行計画を読む際は、上から下に向かって読み進めてください。次の例では、計画ツリーのリーフノードは`TableFullScan_18`で、テーブル全体のスキャンを実行します。このスキャンで得られた行は`Selection_19`演算子によって使用され、 `ge(trips.start_date, 2017-07-01 00:00:00.000000), le(trips.start_date, 2017-07-01 23:59:59.000000)`に基づいてデータがフィルタリングされます。その後、 group-by 演算子`StreamAgg_9`によって最終的な集計`COUNT(*)`実行されます。 -これらの3つの演算子（ `TableFullScan_18` ） `Selection_19` TiKV（ `StreamAgg_9`で`cop[tikv]` ）にプッシュダウンされ、TiKVでの早期フィルタリングと集計が可能になり、TiKVとTiDB間のデータ転送が削減されます。最後に、 `TableReader_21` `StreamAgg_9`からデータを読み取り、 `StreamAgg_20`最終的な集計`count(*)`実行します。 +これらの3つの演算子（`TableFullScan_18`、`Selection_19`、`StreamAgg_9`）はTiKV（`cop[tikv]`）にプッシュダウンされ、TiKVでの早期フィルタリングと集計が可能になり、TiKVとTiDB間のデータ転送が削減されます。最後に、`TableReader_21`が`StreamAgg_9`からデータを読み取り、`StreamAgg_20`が最終的な集計`count(*)`を実行します。 ```sql EXPLAIN SELECT COUNT(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59';