From ff3f51955b3c41e661692c3c2636a566ad2cee76 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 2 Sep 2026 10:43:12 +0900 Subject: [PATCH 1/9] i18n(ja): remove spurious middle-dots from katakana compound terms MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Middle-dot (・) was used to split many katakana technical compound terms that should be written as one continuous word, matching the standing katakana-compound-spacing convention (no separator between katakana words in a single term) and the same pattern already fixed for OLTP in PR #23692. Examples: インデックス・ネストループ → インデックスネストループ (Index Nested Loop [Join]), プライマリ・ セカンダリ → プライマリセカンダリ, アルター・リソース・グループ → アルターリソースグループ, データベース・アズ・ア・サービス → データベースアズアサービス (Database as a Service). Also found and fixed 2 GitHub-username mistransliterations where a middle-dot had been incorrectly inserted into a single username (release-6.5.6.md, release-7.1.3.md: CharlesCheung96, tonyxuqqi). Left untouched (verified false positives / legitimate uses): - Foreign personal names, where middle-dot is the correct Japanese convention (e.g. Ketanji Brown Jackson in ai/integrations/vector-search-integrate-with-langchain.md). - Middle-dot used as a genuine 'and' list separator between two distinct EN-sourced actions/items (e.g. 構成・セットアップ = configure and set up, 開発・テスト = development and testing) — these are correct Japanese and not part of this defect class. - 3 sites where EN explicitly uses "and" between two distinct actions (incremental backup and restore; backup and restore functions; merge and import) were reworded with と/および instead of silently joining into one compound, to preserve the "and" meaning. --- ai/examples/image-search-with-pytidb.md | 4 ++-- br/br-checkpoint-backup.md | 8 ++++---- br/br-checkpoint-restore.md | 2 +- develop/dev-guide-connection-parameters.md | 2 +- develop/dev-guide-create-table.md | 4 ++-- develop/dev-guide-hybrid-oltp-and-olap-queries.md | 2 +- dr-secondary-cluster.md | 8 ++++---- explore-htap.md | 4 ++-- faq/deploy-and-maintain-faq.md | 2 +- glossary.md | 2 +- import-example-data.md | 2 +- migrate-from-tidb-to-tidb.md | 2 +- migration-overview.md | 2 +- optimizer-hints.md | 8 ++++---- privilege-management.md | 2 +- releases/release-6.1.0.md | 2 +- releases/release-6.5.6.md | 4 ++-- releases/release-7.1.0.md | 4 ++-- releases/release-7.1.3.md | 2 +- sql-plan-management.md | 2 +- tidb-cloud/architecture-concepts.md | 4 ++-- tidb-cloud/dedicated/_index.md | 2 +- tidb-cloud/essential/_index.md | 2 +- tidb-cloud/premium/_index.md | 2 +- tidb-cloud/secure-connections-to-serverless-clusters.md | 2 +- tidb-cloud/starter/_index.md | 2 +- tidb-cloud/tidb-cloud-faq.md | 4 ++-- tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md | 2 +- tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md | 2 +- tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md | 2 +- tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md | 2 +- tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md | 2 +- tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md | 2 +- tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md | 2 +- tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md | 2 +- tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md | 2 +- tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md | 2 +- tidb-resource-control-ru-groups.md | 2 +- tidb-resource-control-runaway-queries.md | 2 +- troubleshoot-lock-conflicts.md | 2 +- 40 files changed, 56 insertions(+), 56 deletions(-) diff --git a/ai/examples/image-search-with-pytidb.md b/ai/examples/image-search-with-pytidb.md index 27e6cd2ffefaf..25699d99b2d64 100644 --- a/ai/examples/image-search-with-pytidb.md +++ b/ai/examples/image-search-with-pytidb.md @@ -61,7 +61,7 @@ EOF ### ステップ4．データセットをダウンロードして解凍する {#step-4-download-and-extract-the-dataset} -[オックスフォード・ペットデータセット](https://www.robots.ox.ac.uk/~vgg/data/pets/)を使用して、ペット画像をデータベースに読み込んで検索するデモです。 +[オックスフォードペットデータセット](https://www.robots.ox.ac.uk/~vgg/data/pets/)を使用して、ペット画像をデータベースに読み込んで検索するデモです。 *Linux/macOSの場合：* @@ -86,7 +86,7 @@ streamlit run app.py サンプルアプリでは、 **Load Sample Data**ボタンをクリックすると、サンプルデータがデータベースに読み込まれます。 -または、オックスフォード・ペット・データセットのすべてのデータを読み込みたい場合は、 **Load All Data**ボタンをクリックしてください。 +または、オックスフォードペットデータセットのすべてのデータを読み込みたい場合は、 **Load All Data**ボタンをクリックしてください。 ### ステップ7. 検索 {#step-7-search} diff --git a/br/br-checkpoint-backup.md b/br/br-checkpoint-backup.md index db4c849cd6ba4..9f49854d4fb13 100644 --- a/br/br-checkpoint-backup.md +++ b/br/br-checkpoint-backup.md @@ -1,13 +1,13 @@ --- title: Checkpoint Backup -summary: TiDB v6.5.0では、中断されたバックアップを再開するためのチェックポイント・バックアップ機能が導入され、最初からやり直す必要性が軽減されます。この機能はバックアップ済みのシャードを記録してバックアップを再開しますが、GCメカニズムに依存するため、一部のデータの再バックアップが必要になる場合があります。br`ツールは、データのガベージコレクションを回避するために定期的に`gc-safepoint`を更新し、必要に応じて保持期間を延長できます。 +summary: TiDB v6.5.0では、中断されたバックアップを再開するためのチェックポイントバックアップ機能が導入され、最初からやり直す必要性が軽減されます。この機能はバックアップ済みのシャードを記録してバックアップを再開しますが、GCメカニズムに依存するため、一部のデータの再バックアップが必要になる場合があります。br`ツールは、データのガベージコレクションを回避するために定期的に`gc-safepoint`を更新し、必要に応じて保持期間を延長できます。 --- # チェックポイントバックアップ {#checkpoint-backup} スナップショットバックアップは、ディスク枯渇やノードクラッシュなどの回復可能なエラーにより中断される可能性があります。TiDB v6.5.0より前のバージョンでは、中断前にバックアップされたデータはエラーが解決された後でも無効となり、最初からバックアップをやり直す必要がありました。大規模クラスターの場合、これはかなりのコスト増加につながります。 -TiDB v6.5.0では、バックアップとリストア（BR）にチェックポイント・バックアップ機能が導入され、中断されたバックアップを続行できるようになりました。この機能により、中断されたバックアップのほとんどのデータを保持できます。 +TiDB v6.5.0では、バックアップとリストア（BR）にチェックポイントバックアップ機能が導入され、中断されたバックアップを続行できるようになりました。この機能により、中断されたバックアップのほとんどのデータを保持できます。 ## アプリケーションシナリオ {#application-scenarios} @@ -17,13 +17,13 @@ TiDBクラスタが大規模で、障害発生後に再度バックアップを スナップショットバックアップ中、 `br`テーブルを対応するキー空間にエンコードし、バックアップRPCリクエストを生成してTiKVノードに送信します。バックアップリクエストを受信すると、TiKVノードは要求された範囲内のデータをバックアップします。TiKVノードは、リージョンのデータのバックアップを完了するたびに、この範囲のバックアップ情報を`br`に返します。 -`br` TiKV ノードから返された情報を記録し、 `br`バックアップされたキー範囲を取得するのに役立ちます。チェックポイント・バックアップ機能は、定期的に新しいバックアップ情報を外部ストレージにアップロードし、バックアップされたキー範囲を永続化します。 +`br` TiKV ノードから返された情報を記録し、 `br`バックアップされたキー範囲を取得するのに役立ちます。チェックポイントバックアップ機能は、定期的に新しいバックアップ情報を外部ストレージにアップロードし、バックアップされたキー範囲を永続化します。 `br`バックアップを再試行する際、外部ストレージからバックアップ済みのキー範囲を読み取り、バックアップタスクのキー範囲と比較します。この差分データは、 `br`チェックポイントバックアップでまだバックアップする必要があるキー範囲を特定するのに役立ちます。 ## 使用制限 {#usage-limitations} -チェックポイント・バックアップはGCメカニズムに依存しており、バックアップされたすべてのデータを復元できるわけではありません。詳細については、以下のセクションで説明します。 +チェックポイントバックアップはGCメカニズムに依存しており、バックアップされたすべてのデータを復元できるわけではありません。詳細については、以下のセクションで説明します。 ### バックアップの再試行はGCの前に行う必要があります {#backup-retry-must-be-prior-to-gc} diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index ac56c6ecf0ab8..640088bf2a2e5 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -7,7 +7,7 @@ summary: TiDB v7.1.0ではチェックポイント復元が導入され、中断 スナップショットの復元やログの復元は、ディスク枯渇やノードクラッシュなどの回復可能なエラーにより中断される可能性があります。TiDB v7.1.0より前のバージョンでは、エラーに対処した後でも中断前の復元の進行状況が無効になり、復元を最初からやり直す必要がありました。大規模クラスターでは、これはかなりの追加コストが発生します。 -TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイント・リストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。 +TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイントリストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。 ## アプリケーションシナリオ {#application-scenarios} diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index 7bda2ed107107..d5809ea5a6c91 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -152,7 +152,7 @@ JDBC API の使用方法については、 [JDBC公式チュートリアル](htt #### Prepare APIを使用する {#use-prepare-api} -OLTP（オンライン・トランザクション処理）シナリオでは、プログラムからデータベースに送信されるSQL文は、パラメータ変更を除けば、複数のタイプが存在します。そのため、通常の[テキストファイルからの実行](https://docs.oracle.com/javase/tutorial/jdbc/basics/processingsqlstatements.html#executing_queries)ではなく[プリペアドステートメント](https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html)を使用し、プリペアドステートメントを再利用して直接実行することをお勧めします。これにより、TiDBでSQL実行計画を繰り返し解析および生成するオーバーヘッドを回避できます。 +OLTP（オンライントランザクション処理）シナリオでは、プログラムからデータベースに送信されるSQL文は、パラメータ変更を除けば、複数のタイプが存在します。そのため、通常の[テキストファイルからの実行](https://docs.oracle.com/javase/tutorial/jdbc/basics/processingsqlstatements.html#executing_queries)ではなく[プリペアドステートメント](https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html)を使用し、プリペアドステートメントを再利用して直接実行することをお勧めします。これにより、TiDBでSQL実行計画を繰り返し解析および生成するオーバーヘッドを回避できます。 現在、ほとんどの上位フレームワークはSQL実行のためにPrepare APIを呼び出しています。開発でJDBC APIを直接使用する場合は、Prepare APIを選択するように注意してください。 diff --git a/develop/dev-guide-create-table.md b/develop/dev-guide-create-table.md index 05d5c34bf4381..72bbace4c6e82 100644 --- a/develop/dev-guide-create-table.md +++ b/develop/dev-guide-create-table.md @@ -234,9 +234,9 @@ CREATE TABLE `bookshop`.`users` ( `bookshop`アプリケーションを使用して`ratings`テーブルに対して OLAP 分析を実行したいとします。たとえば、**書籍の評価と評価のタイミングに有意な相関関係があるかどうかを**クエリし、ユーザーによる書籍の評価が客観的かどうかを分析したいとします。この場合、 `ratings`テーブル全体の`score`フィールドと`rated_at`フィールドをクエリする必要があります。この操作は、OLTP 専用データベースではリソースを大量に消費します。または、ETL やその他のデータ同期ツールを使用して、OLTP データベースから専用の OLAP データベースにデータをエクスポートして分析することもできます。 -このシナリオでは、OLTPとOLAPの両方のシナリオをサポートする**HTAP（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）**データベースであるTiDBが、理想的なワンストップデータベースソリューションとなります。 +このシナリオでは、OLTPとOLAPの両方のシナリオをサポートする**HTAP（ハイブリッドトランザクションアンドアナリティカルプロセッシング）**データベースであるTiDBが、理想的なワンストップデータベースソリューションとなります。 -TiDBでは、オンライン・トランザクション処理（OLTP）には行ベースのストレージエンジンである[TiKV](/tikv-overview.md)、オンライン分析処理（OLAP）には列指向ストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)を使用できます。設定後、 TiFlashはRaft Learnerコンセンサスアルゴリズムに従ってTiKVからリアルタイムでデータを複製し、TiKVとTiFlash間のデータの一貫性を厳密に確保します。 +TiDBでは、オンライントランザクション処理（OLTP）には行ベースのストレージエンジンである[TiKV](/tikv-overview.md)、オンライン分析処理（OLAP）には列指向ストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)を使用できます。設定後、 TiFlashはRaft Learnerコンセンサスアルゴリズムに従ってTiKVからリアルタイムでデータを複製し、TiKVとTiFlash間のデータの一貫性を厳密に確保します。 ### 列ベースのデータを複製する {#replicate-column-based-data} diff --git a/develop/dev-guide-hybrid-oltp-and-olap-queries.md b/develop/dev-guide-hybrid-oltp-and-olap-queries.md index 197218edb068a..aff5e3c989626 100644 --- a/develop/dev-guide-hybrid-oltp-and-olap-queries.md +++ b/develop/dev-guide-hybrid-oltp-and-olap-queries.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-hybrid-oltp-and-olap-queries/','/ja/tidbclo # HTAPクエリ {#htap-queries} -HTAPは、Hybrid Transactional and Analytical Processing（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）の略です。従来、データベースはトランザクション処理または分析シナリオ向けに設計されることが多く、データプラットフォームはトランザクション処理と分析処理に分割する必要があり、分析クエリへの迅速な応答のために、トランザクションデータベースから分析データベースにデータを複製する必要がありました。TiDBデータベースはトランザクションと分析の両方のタスクを実行できるため、データプラットフォームの構築が大幅に簡素化され、ユーザーはより新鮮なデータを分析に使用できるようになります。 +HTAPは、Hybrid Transactional and Analytical Processing（ハイブリッドトランザクションアンドアナリティカルプロセッシング）の略です。従来、データベースはトランザクション処理または分析シナリオ向けに設計されることが多く、データプラットフォームはトランザクション処理と分析処理に分割する必要があり、分析クエリへの迅速な応答のために、トランザクションデータベースから分析データベースにデータを複製する必要がありました。TiDBデータベースはトランザクションと分析の両方のタスクを実行できるため、データプラットフォームの構築が大幅に簡素化され、ユーザーはより新鮮なデータを分析に使用できるようになります。 TiDBは、オンライントランザクション処理（OLTP）には行ベースのストレージエンジンであるTiKVを使用し、オンライン分析処理（OLAP）には列指向ストレージエンジンであるTiFlashを使用します。HTAPでは、行ベースのストレージエンジンと列指向ストレージエンジンが共存します。どちらのストレージエンジンも、データを自動的に複製し、強力な一貫性を維持できます。行ベースのストレージエンジンはOLTPのパフォーマンスを最適化し、列指向ストレージエンジンはOLAPのパフォーマンスを最適化します。 diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index ff5f6a8c67e9d..6ffce57b93b53 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -1,15 +1,15 @@ --- title: DR Solution Based on Primary and Secondary Clusters -summary: TiCDCに基づいたプライマリ・セカンダリディザスタリカバリの実装方法を学びましょう。 +summary: TiCDCに基づいたプライマリセカンダリディザスタリカバリの実装方法を学びましょう。 --- # プライマリクラスタとセカンダリクラスタに基づく災害復旧ソリューション {#dr-solution-based-on-primary-and-secondary-clusters} プライマリデータベースとセカンダリデータベースに基づく災害リカバリ（DR）は、一般的なソリューションです。このソリューションでは、DRシステムはプライマリクラスタとセカンダリクラスタで構成されます。プライマリクラスタはユーザーからのリクエストを処理し、セカンダリクラスタはプライマリクラスタからデータをバックアップします。プライマリクラスタに障害が発生した場合、セカンダリクラスタがサービスを引き継ぎ、バックアップデータを使用してサービスの提供を継続します。これにより、障害による中断なく、ビジネスシステムが正常に稼働し続けることが保証されます。 -プライマリ・セカンダリ型災害復旧ソリューションには、以下の利点があります。 +プライマリセカンダリ型災害復旧ソリューションには、以下の利点があります。 -- 高可用性：プライマリ・セカンダリアーキテクチャによりシステムの可用性が向上し、あらゆる障害からの迅速なリカバリが保証されます。 +- 高可用性：プライマリセカンダリアーキテクチャによりシステムの可用性が向上し、あらゆる障害からの迅速なリカバリが保証されます。 - 高速切り替え：プライマリクラスタに障害が発生した場合、システムはセカンダリクラスタに迅速に切り替えてサービスの提供を継続できます。 - データの一貫性：セカンダリクラスタは、プライマリクラスタのデータをほぼリアルタイムでバックアップします。これにより、システムが障害発生時にセカンダリクラスタに切り替わった場合でも、データは基本的に最新の状態に保たれます。 @@ -408,7 +408,7 @@ storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=ht > **Note:** > -> プライマリ・セカンダリ型の災害復旧アーキテクチャでは、セカンダリクラスタは1つのチェンジフィードからのデータしか複製できません。そうでない場合、セカンダリクラスタのデータトランザクションの整合性は保証されません。 +> プライマリセカンダリ型の災害復旧アーキテクチャでは、セカンダリクラスタは1つのチェンジフィードからのデータしか複製できません。そうでない場合、セカンダリクラスタのデータトランザクションの整合性は保証されません。 ### プライマリクラスターとセカンダリクラスター間で双方向レプリケーションを実行する {#perform-bidirectional-replication-between-the-primary-and-secondary-clusters} diff --git a/explore-htap.md b/explore-htap.md index 152f9d34bf4a7..ee41b1b3f21d8 100644 --- a/explore-htap.md +++ b/explore-htap.md @@ -39,7 +39,7 @@ TiDBの全体的なパフォーマンスを向上させるため、以下の技 - ハイブリッドワークロードの分離 - 高負荷なオンライン・トランザクション処理（OLTP）ワークロードを処理する際、システムは同時にOLAPワークロードも処理する必要が生じる場合があります。システム全体の安定性を確保するため、OLAPクエリがOLTPのパフォーマンスに与える影響を回避することが求められます。 + 高負荷なオンライントランザクション処理（OLTP）ワークロードを処理する際、システムは同時にOLAPワークロードも処理する必要が生じる場合があります。システム全体の安定性を確保するため、OLAPクエリがOLTPのパフォーマンスに与える影響を回避することが求められます。 - ETLテクノロジースタックを簡素化する @@ -51,7 +51,7 @@ TiDBの全体的なパフォーマンスを向上させるため、以下の技 ## アーキテクチャ {#architecture} -TiDBでは、オンライン・トランザクション処理（OLTP）用の行ベースのストレージエンジン[TiKV](/tikv-overview.md)と、オンライン分析処理（OLAP）用の列指向のストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)が共存し、データを自動的に複製し、強力な一貫性を維持します。 +TiDBでは、オンライントランザクション処理（OLTP）用の行ベースのストレージエンジン[TiKV](/tikv-overview.md)と、オンライン分析処理（OLAP）用の列指向のストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)が共存し、データを自動的に複製し、強力な一貫性を維持します。 アーキテクチャの詳細については、 [TiDB HTAPのアーキテクチャ](/tiflash/tiflash-overview.md#architecture)を参照してください。 diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 4e59c9780f57c..14aba8199eac5 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -15,7 +15,7 @@ TiDB がサポートするオペレーティングシステムについては、 ### 開発、テスト、または本番環境における TiDB クラスターの推奨ハードウェア構成は何ですか? {#what-is-the-recommended-hardware-configuration-for-a-tidb-cluster-in-the-development-test-or-production-environment} -TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェア・サーバー・プラットフォーム、またはARMアーキテクチャのハードウェア・サーバー・プラットフォームに導入および実行できます。開発環境、テスト環境、および本番環境におけるサーバー・ハードウェア構成の要件と推奨事項については、 [ソフトウェアとハ​​ードウェアの推奨事項 - サーバー要件](/hardware-and-software-requirements.md#server-requirements)を参照してください。 +TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェアサーバープラットフォーム、またはARMアーキテクチャのハードウェアサーバープラットフォームに導入および実行できます。開発環境、テスト環境、および本番環境におけるサーバーハードウェア構成の要件と推奨事項については、 [ソフトウェアとハ​​ードウェアの推奨事項 - サーバー要件](/hardware-and-software-requirements.md#server-requirements)を参照してください。 ### 10 ギガビットのネットワークカード 2枚の目的は何ですか? {#whats-the-purposes-of-2-network-cards-of-10-gigabit} diff --git a/glossary.md b/glossary.md index 02a2f398b19e6..b77bb0956f316 100644 --- a/glossary.md +++ b/glossary.md @@ -217,7 +217,7 @@ TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出 ### オンライントランザクション処理（OLTP） {#online-transaction-processing-oltp} -オンライン・トランザクション処理（OLTP）とは、レコードの選択、挿入、更新、削除といったトランザクション処理に特化したデータベースワークロードを指します。 +オンライントランザクション処理（OLTP）とは、レコードの選択、挿入、更新、削除といったトランザクション処理に特化したデータベースワークロードを指します。 ### メモリ不足 (OOM) {#out-of-memory-oom} diff --git a/import-example-data.md b/import-example-data.md index ed177b8463540..6fb38efdd0bc3 100644 --- a/import-example-data.md +++ b/import-example-data.md @@ -5,7 +5,7 @@ summary: Bikeshare サンプルデータベースをインストールします # サンプルデータベースのインポート {#import-example-database} -TiDB マニュアルで使用されている例では、 [キャピタル・バイクシェア・データライセンス契約](https://www.capitalbikeshare.com/data-license-agreement)でリリースされた Capital Bikeshare の[システムデータ](https://www.capitalbikeshare.com/system-data)が使用されています。 +TiDB マニュアルで使用されている例では、 [キャピタルバイクシェアデータライセンス契約](https://www.capitalbikeshare.com/data-license-agreement)でリリースされた Capital Bikeshare の[システムデータ](https://www.capitalbikeshare.com/system-data)が使用されています。 ## すべてのデータファイルをダウンロードする {#download-all-data-files} diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index a43f57f86b1c7..28e04290682a6 100644 --- a/migrate-from-tidb-to-tidb.md +++ b/migrate-from-tidb-to-tidb.md @@ -99,7 +99,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー ## ステップ2. 全データの移行 {#step-2-migrate-full-data} -環境構築後、 [BR](https://github.com/pingcap/tidb/tree/release-8.5/br)のバックアップ・リストア関数を使用して全データを移行できます。BRは[3つの方法](/br/br-use-overview.md#deploy-and-use-br)で起動できます。本稿では、SQL文`BACKUP`と`RESTORE`を使用します。 +環境構築後、 [BR](https://github.com/pingcap/tidb/tree/release-8.5/br)のバックアップおよびリストア関数を使用して全データを移行できます。BRは[3つの方法](/br/br-use-overview.md#deploy-and-use-br)で起動できます。本稿では、SQL文`BACKUP`と`RESTORE`を使用します。 > **Note:** > diff --git a/migration-overview.md b/migration-overview.md index ac63d56bdb9ed..e01981dbe0d18 100644 --- a/migration-overview.md +++ b/migration-overview.md @@ -40,7 +40,7 @@ Auroraから AWS にデプロイされた TiDB クラスターにデータを移 - [小さなデータセットの MySQL シャードを TiDB に移行してマージする](/migrate-small-mysql-shards-to-tidb.md) -シャードテーブルのデータサイズが大きく（例えば1TiB以上）、移行期間中に他のアプリケーションによるTiDBへの書き込みを許可しない場合は、 TiDB Lightningを使用してシャードテーブルを迅速にマージ・インポートできます。その後、DMを使用して、アプリケーションのニーズに応じて増分シャーディングデータ（binlog）を複製できます。 +シャードテーブルのデータサイズが大きく（例えば1TiB以上）、移行期間中に他のアプリケーションによるTiDBへの書き込みを許可しない場合は、 TiDB Lightningを使用してシャードテーブルを迅速にマージおよびインポートできます。その後、DMを使用して、アプリケーションのニーズに応じて増分シャーディングデータ（binlog）を複製できます。 - [大規模データセットの MySQL シャードを TiDB に移行およびマージする](/migrate-large-mysql-shards-to-tidb.md) diff --git a/optimizer-hints.md b/optimizer-hints.md index 85b297fec9225..2903278789382 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -100,13 +100,13 @@ SELECT /*+ NO_MERGE_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; > > 場合によっては、 `INL_JOIN`ヒントが効かないことがあります。詳しくは[`INL_JOIN`ヒントは有効になりません](#inl_join-hint-does-not-take-effect)を参照してください。 -ヒント`INL_JOIN(t1_name [, tl_name ...])`は、指定されたテーブルに対してインデックス・ネストループ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムは、状況によってはシステムリソースの消費量が少なく、処理時間も短縮される可能性がありますが、状況によっては逆の結果になることもあります。外部テーブルが`WHERE`条件でフィルタリングされた後、結果セットが10,000行未満の場合、このヒントを使用することをお勧めします。例： +ヒント`INL_JOIN(t1_name [, tl_name ...])`は、指定されたテーブルに対してインデックスネストループ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムは、状況によってはシステムリソースの消費量が少なく、処理時間も短縮される可能性がありますが、状況によっては逆の結果になることもあります。外部テーブルが`WHERE`条件でフィルタリングされた後、結果セットが10,000行未満の場合、このヒントを使用することをお勧めします。例： ```sql SELECT /*+ INL_JOIN(t1, t2) */ * FROM t1, t2, t3 WHERE t1.id = t2.id AND t2.id = t3.id; ``` -上記のSQL文では、ヒント`INL_JOIN(t1, t2)`はオプティマイザに、 `t1`と`t2`に対してインデックス・ネストループ結合アルゴリズムを使用するように指示しています。これは、 `t1`と`t2`の間でインデックス・ネストループ結合アルゴリズムが使用されることを意味するわけではないことに注意してください。ヒントは、 `t1`と`t2`がそれぞれ別のテーブル（ `t3` ）に対してインデックス・ネストループ結合アルゴリズムを使用することを示しています。 +上記のSQL文では、ヒント`INL_JOIN(t1, t2)`はオプティマイザに、 `t1`と`t2`に対してインデックスネストループ結合アルゴリズムを使用するように指示しています。これは、 `t1`と`t2`の間でインデックスネストループ結合アルゴリズムが使用されることを意味するわけではないことに注意してください。ヒントは、 `t1`と`t2`がそれぞれ別のテーブル（ `t3` ）に対してインデックスネストループ結合アルゴリズムを使用することを示しています。 `INL_JOIN()`で指定されたパラメータは、クエリプランを作成する際に内部テーブルとして使用される候補テーブルです。例えば、 `INL_JOIN(t1)`は、TiDB がクエリプランを作成する際に内部テーブルとして`t1`を使用することを検討することを意味します。候補テーブルに別名がある場合は、 `INL_JOIN()`のパラメータとしてその別名を使用する必要があります。別名がない場合は、テーブルの元の名前をパラメータとして使用してください。例えば、 `select /*+ INL_JOIN(t1) */ * from t t1, t t2 where t1.a = t2.b;`というクエリでは、 `INL_JOIN()`のパラメータとして`t`ではなく、 `t`テーブルの別名である`t1`または`t2`を使用する必要があります。 @@ -124,7 +124,7 @@ SELECT /*+ NO_INDEX_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; ### INL_HASH_JOIN {#inl_hash_join} -ヒント`INL_HASH_JOIN(t1_name [, tl_name])`は、インデックス・ネストループ・ハッシュ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムを使用するための条件は、インデックス・ネストループ結合アルゴリズムを使用するための条件と同じです。2つのアルゴリズムの違いは、 `INL_JOIN`は結合された内部テーブルにハッシュテーブルを作成するのに対し、 `INL_HASH_JOIN`は結合された外部テーブルにハッシュテーブルを作成する点です。 `INL_HASH_JOIN`はメモリ使用量に制限がありますが、ヒント`INL_JOIN`は内部テーブルで一致する行数に応じてメモリ使用量が異なります。 +ヒント`INL_HASH_JOIN(t1_name [, tl_name])`は、インデックスネストループハッシュ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムを使用するための条件は、インデックスネストループ結合アルゴリズムを使用するための条件と同じです。2つのアルゴリズムの違いは、 `INL_JOIN`は結合された内部テーブルにハッシュテーブルを作成するのに対し、 `INL_HASH_JOIN`は結合された外部テーブルにハッシュテーブルを作成する点です。 `INL_HASH_JOIN`はメモリ使用量に制限がありますが、ヒント`INL_JOIN`は内部テーブルで一致する行数に応じてメモリ使用量が異なります。 ### NO_INDEX_HASH_JOIN(t1_name [, tl_name ...]) {#no_index_hash_joint1_name--tl_name-} @@ -136,7 +136,7 @@ SELECT /*+ NO_INDEX_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; > > TiDB v8.3.0 以降、`INL_MERGE_JOIN`ヒントは非推奨となり、誤った結果を返す可能性があるため、効果がなくなりました。クエリでこのヒントを指定した場合、TiDB はこれを無視して別の結合アルゴリズムを選択します。 -TiDB v8.3.0 より前では、ヒント`INL_MERGE_JOIN(t1_name [, tl_name])`は、インデックス・ネストループ・マージ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムを使用する条件は、インデックス・ネストループ結合アルゴリズムを使用する条件と同じです。 +TiDB v8.3.0 より前では、ヒント`INL_MERGE_JOIN(t1_name [, tl_name])`は、インデックスネストループマージ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムを使用する条件は、インデックスネストループ結合アルゴリズムを使用する条件と同じです。 ### NO_INDEX_MERGE_JOIN(t1_name [, tl_name ...]) {#no_index_merge_joint1_name--tl_name-} diff --git a/privilege-management.md b/privilege-management.md index 29bb4f35f1b09..a8d49022f5f9e 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -483,7 +483,7 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; `SUPER`または`RESOURCE_GROUP_ADMIN`の権限が必要です。 -### アルター・リソース・グループ {#alter-resource-group} +### アルターリソースグループ {#alter-resource-group} `SUPER`または`RESOURCE_GROUP_ADMIN`の権限が必要です。 diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md index 82cedaf896d59..921459fda92bc 100644 --- a/releases/release-6.1.0.md +++ b/releases/release-6.1.0.md @@ -174,7 +174,7 @@ TiDB バージョン: 6.1.0 TiKV API V2 は、次のような新しい Raw Key Valueストレージ形式とアクセス インターフェイスを提供します。 - - データはMVCCに保存され、データの変更タイムスタンプが記録されます。この機能は、変更データキャプチャ（CDC）と増分バックアップ・リストアの実装の基盤となります。 + - データはMVCCに保存され、データの変更タイムスタンプが記録されます。この機能は、変更データキャプチャ（CDC）と増分バックアップおよびリストアの実装の基盤となります。 - データはさまざまな使用法に応じてスコープ設定され、単一の TiDB クラスター、トランザクション KV、RawKV アプリケーションの共存をサポートします。 diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index 72d09b6430980..4d0001436557a 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -21,7 +21,7 @@ TiDB バージョン: 6.5.6 - [`encoding-worker-num`](/ticdc/ticdc-changefeed-config.md)と[`flush-worker-num`](/ticdc/ticdc-changefeed-config.md) : 異なるマシンの仕様に基づいて、再実行モジュールに異なる同時実行パラメータを設定できます[＃10048](https://github.com/pingcap/tiflow/issues/10048) @[CharlesCheung96](https://github.com/CharlesCheung96) - [`compression`](/ticdc/ticdc-changefeed-config.md) : REDOログファイルの圧縮動作を設定できます[＃10176](https://github.com/pingcap/tiflow/issues/10176) @[sdojjy](https://github.com/sdojjy) - [`changefeed-error-stuck-duration`](/ticdc/ticdc-changefeed-config.md) : 内部エラーまたは例外が発生したときに、変更フィードが自動的に再試行される期間を設定できます[＃9875](https://github.com/pingcap/tiflow/issues/9875) @[asddongmen](https://github.com/asddongmen) - - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージにデータを複製するときに履歴データの自動クリーンアップを設定できます[チャールズ・チュン96](https://github.com/CharlesCheung96) [＃10109](https://github.com/pingcap/tiflow/issues/10109) + - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージにデータを複製するときに履歴データの自動クリーンアップを設定できます[チャールズチュン96](https://github.com/CharlesCheung96) [＃10109](https://github.com/pingcap/tiflow/issues/10109) ## 改善点 {#improvements} @@ -33,7 +33,7 @@ TiDB バージョン: 6.5.6 - OOM を防ぐためにリゾルバのメモリ使用量を最適化します [＃15458](https://github.com/tikv/tikv/issues/15458) @[overvenus](https://github.com/overvenus) - ルータオブジェクトのLRUCacheを排除してメモリ使用量を削減し、OOM を防止します。 [＃15430](https://github.com/tikv/tikv/issues/15430) @[Connor1996](https://github.com/Connor1996) - - `apply_router`と`raft_router`指標に`alive`と`leak`監視ディメンションを追加します[トニー・シュッキ](https://github.com/tonyxuqqi) [＃15357](https://github.com/tikv/tikv/issues/15357) + - `apply_router`と`raft_router`指標に`alive`と`leak`監視ディメンションを追加します[トニーシュッキ](https://github.com/tonyxuqqi) [＃15357](https://github.com/tikv/tikv/issues/15357) - PD diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index 7d7a499991a26..b0f377bbc1a29 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} @@ -101,7 +101,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 スナップショットの復元やログの復元は、ディスク枯渇やノードクラッシュなどの回復可能なエラーにより中断される可能性があります。TiDB v7.1.0より前のバージョンでは、エラーに対処した後でも中断前の復元の進行状況が無効になり、復元を最初からやり直す必要がありました。大規模クラスターでは、これはかなりの追加コストが発生します。 - TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイント・リストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。 + TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイントリストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。 詳細については[ドキュメント](/br/br-checkpoint-restore.md)を参照してください。 diff --git a/releases/release-7.1.3.md b/releases/release-7.1.3.md index 01c1db6657718..392f8dcd29ef6 100644 --- a/releases/release-7.1.3.md +++ b/releases/release-7.1.3.md @@ -18,7 +18,7 @@ TiDB バージョン: 7.1.3 - [`sql-mode`](/ticdc/ticdc-changefeed-config.md) : TiCDC がデータを複製するときに DDL ステートメントを解析するために使用する[SQLモード](https://docs.pingcap.com/tidb/v7.1/ticdc-ddl#sql-mode)を設定できます[＃9876](https://github.com/pingcap/tiflow/issues/9876) @[asddongmen](https://github.com/asddongmen) - [`encoding-worker-num`](/ticdc/ticdc-changefeed-config.md)と[`flush-worker-num`](/ticdc/ticdc-changefeed-config.md) : 異なるマシンの仕様に基づいて、再実行モジュールに異なる同時実行パラメータを設定できます[＃10048](https://github.com/pingcap/tiflow/issues/10048) @[CharlesCheung96](https://github.com/CharlesCheung96) - [`compression`](/ticdc/ticdc-changefeed-config.md) : REDOログファイルの圧縮動作を設定できます[＃10176](https://github.com/pingcap/tiflow/issues/10176) @[sdojjy](https://github.com/sdojjy) - - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージにデータを複製するときに履歴データの自動クリーンアップを設定できます[チャールズ・チュン96](https://github.com/CharlesCheung96) [＃10109](https://github.com/pingcap/tiflow/issues/10109) + - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージにデータを複製するときに履歴データの自動クリーンアップを設定できます[チャールズチュン96](https://github.com/CharlesCheung96) [＃10109](https://github.com/pingcap/tiflow/issues/10109) ## 改善点 {#improvements} diff --git a/sql-plan-management.md b/sql-plan-management.md index 2225f4ec691ba..de66ee199d548 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -630,7 +630,7 @@ SHOW GLOBAL BINDINGS; [アップグレード中の実行計画の回帰を防ぐ](#prevent-regression-of-execution-plans-during-an-upgrade)に使用されるこの機能は、キャプチャ条件を満たすクエリをキャプチャし、これらのクエリのバインディングを作成します。 -プラン・ベースラインとは、オプティマイザがSQL文の実行に使用できる承認済みのプランの集合を指します。通常、TiDBはプランが適切に実行されることを確認した後にのみ、プランをプラン・ベースラインに追加します。ここで言うプランとは、オプティマイザが実行計画を再現するために必要なすべてのプラン関連の詳細（SQLプラン識別子、ヒントセット、バインド値、オプティマイザ環境など）を包含するものです。 +プランベースラインとは、オプティマイザがSQL文の実行に使用できる承認済みのプランの集合を指します。通常、TiDBはプランが適切に実行されることを確認した後にのみ、プランをプランベースラインに追加します。ここで言うプランとは、オプティマイザが実行計画を再現するために必要なすべてのプラン関連の詳細（SQLプラン識別子、ヒントセット、バインド値、オプティマイザ環境など）を包含するものです。 ### キャプチャを有効にする {#enable-capturing} diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index 4354d53eba98d..27466887460c0 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -7,13 +7,13 @@ summary: TiDB Cloudのアーキテクチャ概念について学びましょう -TiDB Cloudは、フルマネージド型のデータベース・アズ・ア・サービス（DBaaS）であり、オープンソースのHTAP（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)の柔軟性とパワーを、Amazon Web Services（AWS）、Google Cloud、Microsoft Azure、およびAlibaba Cloudに提供します。 +TiDB Cloudは、フルマネージド型のデータベースアズアサービス（DBaaS）であり、オープンソースのHTAP（ハイブリッドトランザクションアンドアナリティカルプロセッシング）データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)の柔軟性とパワーを、Amazon Web Services（AWS）、Google Cloud、Microsoft Azure、およびAlibaba Cloudに提供します。 -TiDB Cloudは、フルマネージド型のデータベース・アズ・ア・サービス（DBaaS）であり、オープンソースのHTAP（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)の柔軟性とパワーを、Amazon Web Services（AWS）、Google Cloud、およびMicrosoft Azureに提供します。 +TiDB Cloudは、フルマネージド型のデータベースアズアサービス（DBaaS）であり、オープンソースのHTAP（ハイブリッドトランザクションアンドアナリティカルプロセッシング）データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)の柔軟性とパワーを、Amazon Web Services（AWS）、Google Cloud、およびMicrosoft Azureに提供します。 diff --git a/tidb-cloud/dedicated/_index.md b/tidb-cloud/dedicated/_index.md index adb8cd80da229..0a5f0bfcf2b67 100644 --- a/tidb-cloud/dedicated/_index.md +++ b/tidb-cloud/dedicated/_index.md @@ -3,7 +3,7 @@ title: TiDB Cloud Documentation aliases: ['/ja/tidbcloud/privacy-policy','/ja/tidbcloud/terms-of-service','/ja/tidbcloud/service-level-agreement'] hide_sidebar: true hide_commit: true -summary: TiDB Cloudは、TiDBの優れた機能すべてをクラウドに提供する、フルマネージドのデータベース・アズ・ア・サービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ保護、課金、統合、参照のためのガイド、サンプル、リファレンスを提供しています。 +summary: TiDB Cloudは、TiDBの優れた機能すべてをクラウドに提供する、フルマネージドのデータベースアズアサービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ保護、課金、統合、参照のためのガイド、サンプル、リファレンスを提供しています。 --- diff --git a/tidb-cloud/essential/_index.md b/tidb-cloud/essential/_index.md index f52c9aa34e3d5..f2255ea8a16d4 100644 --- a/tidb-cloud/essential/_index.md +++ b/tidb-cloud/essential/_index.md @@ -2,7 +2,7 @@ title: TiDB Cloud Documentation hide_sidebar: true hide_commit: true -summary: TiDB Cloudは、 TiDBの優れた機能すべてをクラウドに提供する、フルマネージドのデータベース・アズ・ア・サービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ保護、課金、統合、参照のためのガイド、サンプル、リファレンスを提供しています。 +summary: TiDB Cloudは、 TiDBの優れた機能すべてをクラウドに提供する、フルマネージドのデータベースアズアサービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ保護、課金、統合、参照のためのガイド、サンプル、リファレンスを提供しています。 --- diff --git a/tidb-cloud/premium/_index.md b/tidb-cloud/premium/_index.md index 65c7bc9902b5a..c55ff262ab5c3 100644 --- a/tidb-cloud/premium/_index.md +++ b/tidb-cloud/premium/_index.md @@ -2,7 +2,7 @@ title: TiDB Cloud Documentation hide_sidebar: true hide_commit: true -summary: TiDB Cloudは、TiDBの優れた機能をすべてクラウド上で提供する、フルマネージド型のデータベース・アズ・ア・サービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ、課金、統合、参照のためのガイド、サンプル、リファレンスを提供します。 +summary: TiDB Cloudは、TiDBの優れた機能をすべてクラウド上で提供する、フルマネージド型のデータベースアズアサービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ、課金、統合、参照のためのガイド、サンプル、リファレンスを提供します。 --- diff --git a/tidb-cloud/secure-connections-to-serverless-clusters.md b/tidb-cloud/secure-connections-to-serverless-clusters.md index 21dbf8d67767e..7a61a3e29f795 100644 --- a/tidb-cloud/secure-connections-to-serverless-clusters.md +++ b/tidb-cloud/secure-connections-to-serverless-clusters.md @@ -45,7 +45,7 @@ aliases: ['/ja/tidbcloud/secure-connections-to-serverless-tier-clusters'] ### ルート証明書の発行と有効性 {#root-certificate-issuance-and-validity} -TiDB Cloudは、クライアントとTiDB Cloudクラスタ間のTLS接続において、 [レッツ・エンクリプト](https://letsencrypt.org/)の証明書を証明機関（CA）として使用します。TiDB Cloud証明書の有効期限が切れると、クラスタの通常の動作や確立されたTLSセキュア接続に影響を与えることなく、自動的にローテーションされます。 +TiDB Cloudは、クライアントとTiDB Cloudクラスタ間のTLS接続において、 [レッツエンクリプト](https://letsencrypt.org/)の証明書を証明機関（CA）として使用します。TiDB Cloud証明書の有効期限が切れると、クラスタの通常の動作や確立されたTLSセキュア接続に影響を与えることなく、自動的にローテーションされます。 JavaやGoなど、クライアントがシステムのルートCAストアをデフォルトで使用する場合、CAルートのパスを指定せずにTiDB Cloudクラスタに安全に接続できます。ただし、一部のドライバやORMはシステムルートCAストアを使用しません。そのような場合は、ドライバやORMのCAルートパスをシステムルートCAストアに設定する必要があります。例えば、macOS上のPythonで[mysqlclient](https://github.com/PyMySQL/mysqlclient)を使用してTiDB Cloudクラスタに接続する場合、引数`ssl`に`ca: /etc/ssl/cert.pem`を設定する必要があります。 diff --git a/tidb-cloud/starter/_index.md b/tidb-cloud/starter/_index.md index bd05b89ecf258..16011a64fba8d 100644 --- a/tidb-cloud/starter/_index.md +++ b/tidb-cloud/starter/_index.md @@ -2,7 +2,7 @@ title: TiDB Cloud Documentation hide_sidebar: true hide_commit: true -summary: TiDB Cloudは、 TiDBの優れた機能すべてをクラウドに提供する、フルマネージドのデータベース・アズ・ア・サービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ保護、課金、統合、参照のためのガイド、サンプル、リファレンスを提供しています。 +summary: TiDB Cloudは、 TiDBの優れた機能すべてをクラウドに提供する、フルマネージドのデータベースアズアサービス（DBaaS）です。学習、試用、開発、保守、移行、監視、チューニング、セキュリティ保護、課金、統合、参照のためのガイド、サンプル、リファレンスを提供しています。 --- diff --git a/tidb-cloud/tidb-cloud-faq.md b/tidb-cloud/tidb-cloud-faq.md index b226e0e164142..a7939290d4cc1 100644 --- a/tidb-cloud/tidb-cloud-faq.md +++ b/tidb-cloud/tidb-cloud-faq.md @@ -117,7 +117,7 @@ TiDB は MySQL と高い互換性があります。データがセルフホス ### TiDB CloudのHTAP機能を利用するにはどうすればよいですか？ {#how-do-i-make-use-of-tidb-cloud-s-htap-capabilities} -従来、データベースにはオンライン・トランザクション処理（OLTP）データベースとオンライン分析処理（OLAP）データベースの2種類がありました。OLTPとOLAPのリクエストは、多くの場合、それぞれ独立したデータベースで処理されます。このような従来のアーキテクチャでは、OLTPデータベースからOLAP用のデータウェアハウスやデータレイクへデータを移行するには、時間がかかり、エラーが発生しやすいプロセスとなります。 +従来、データベースにはオンライントランザクション処理（OLTP）データベースとオンライン分析処理（OLAP）データベースの2種類がありました。OLTPとOLAPのリクエストは、多くの場合、それぞれ独立したデータベースで処理されます。このような従来のアーキテクチャでは、OLTPデータベースからOLAP用のデータウェアハウスやデータレイクへデータを移行するには、時間がかかり、エラーが発生しやすいプロセスとなります。 TiDB Cloudは、ハイブリッドトランザクション分析処理（HTAP）データベースとして、OLTP（TiKV）ストアとOLAP（ TiFlash ）ストア間でデータを自動的に確実に複製することで、システムアーキテクチャの簡素化、メンテナンスの複雑さの軽減、トランザクションデータに対するリアルタイム分析のサポートを実現します。HTAPの一般的なユースケースとしては、ユーザーパーソナライゼーション、AIによるレコメンデーション、不正検出、ビジネスインテリジェンス、リアルタイムレポートなどが挙げられます。 @@ -152,7 +152,7 @@ TiDB CloudはTLS 1.2またはTLS 1.3をサポートしています。 ### TiDB Cloudを自分のVPC内で実行できますか？ {#can-i-run-tidb-cloud-in-my-vpc} -いいえ。TiDB Cloudはデータベース・アズ・ア・サービス（DBaaS）であり、 TiDB Cloud VPC内でのみ動作します。クラウドコンピューティングのマネージドサービスとして、 TiDB Cloudは物理ハードウェアのセットアップやソフトウェアのインストールを必要とせずにデータベースへのアクセスを提供します。 +いいえ。TiDB Cloudはデータベースアズアサービス（DBaaS）であり、 TiDB Cloud VPC内でのみ動作します。クラウドコンピューティングのマネージドサービスとして、 TiDB Cloudは物理ハードウェアのセットアップやソフトウェアのインストールを必要とせずにデータベースへのアクセスを提供します。 ### 私のTiDB Cloudのリソースは安全ですか？ {#is-my-tidb-cloud-resource-secure} diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md index a76ac9dd73893..d8f00fb911852 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md @@ -29,7 +29,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ ### ベンチマーク実行者 {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md index 530ad43570577..e3454294df72a 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md @@ -29,7 +29,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ ### ベンチマーク実行者 {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md index 99837c4fb90c6..2587f02e40360 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md @@ -50,7 +50,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ ### ベンチマーク実行者 {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md index fa5211f4a314e..614462b2be7c5 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md @@ -30,7 +30,7 @@ aliases: ['/ja/tidbcloud/v7.1.0-performance-benchmarking-with-tpcc'] ### ベンチマーク実行者 {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md index b0c34ee9a4433..ac3ce03462f16 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md @@ -50,7 +50,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ ### ベンチマーク実行者 {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md index 3762632bcfcd2..b0540dcff6d74 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md @@ -30,7 +30,7 @@ aliases: ['/ja/tidbcloud/v7.5.0-performance-benchmarking-with-tpcc'] ### ベンチマーク実行者 {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md index c9e1fa40aa0fd..0a03cfbc9dff7 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md @@ -55,7 +55,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ ### ベンチマーク実行者 {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md index bc5fb92dc8636..8b6b3fbbc53f9 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md @@ -41,7 +41,7 @@ raft-engine.prefill-for-recycle = true ### ベンチマーク実行者 {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md index 3ef88396906b7..a7e34475fa8ce 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md @@ -55,7 +55,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ ### ベンチマーク実行者 {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md index fd579d1452477..2bd01a244c40d 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md @@ -41,7 +41,7 @@ raft-engine.prefill-for-recycle = true ### ベンチマーク実行者 {#benchmark-executor} -ベンチマーク・エグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 +ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 - マシンタイプ: Amazon EC2 (us-west-2) - インスタンスタイプ: c6a.2xlarge diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index 22e13176b0ca8..73558225f9fd3 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -404,7 +404,7 @@ TiKVは、Grafanaの**TiKV**ダッシュボードに、さまざまなリソー ## 参照 {#see-also} - [リソースグループを作成する](/sql-statements/sql-statement-create-resource-group.md) -- [アルター・リソース・グループ](/sql-statements/sql-statement-alter-resource-group.md) +- [アルターリソースグループ](/sql-statements/sql-statement-alter-resource-group.md) - [リソースグループを削除する](/sql-statements/sql-statement-drop-resource-group.md) - [リソースグループRFC](https://github.com/pingcap/tidb/blob/release-8.5/docs/design/2022-11-25-global-resource-control.md) diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index ffbeb0692f00d..eb17ca5f08882 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -12,7 +12,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ランナウェイクエリとは、予想よりも多くの時間やリソースを消費するクエリです。以下では、ランナウェイクエリを管理する機能を説明するために「ランナ**ウェイクエリ」という**用語を使用します。 - バージョン7.2.0以降、リソース制御機能にランナウェイクエリの管理機能が導入されました。リソースグループに対してランナウェイクエリを特定するための条件を設定し、ランナウェイクエリによるリソースの枯渇や他のクエリへの影響を防ぐためのアクションを自動的に実行できます。[`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md)または[`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md)に`QUERY_LIMIT`フィールドを含めることで、リソースグループのランナウェイクエリを管理できます。 -- バージョン7.3.0以降、リソース制御機能にランナウェイ・ウォッチの手動管理が導入され、特定のSQL文またはダイジェストに対するランナウェイ・クエリを迅速に特定できるようになりました。ステートメント[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)を実行することで、リソースグループ内のランナウェイ・クエリ・ウォッチリストを手動で管理できます。 +- バージョン7.3.0以降、リソース制御機能にランナウェイウォッチの手動管理が導入され、特定のSQL文またはダイジェストに対するランナウェイクエリを迅速に特定できるようになりました。ステートメント[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)を実行することで、リソースグループ内のランナウェイクエリウォッチリストを手動で管理できます。 リソース制御機能の詳細については、 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)を参照してください。 diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index fb5843551d3e8..c57f9e47f7552 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -283,7 +283,7 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ > **Note:** > -> 悲観的・トランザクション・モードが設定されている場合でも、自動コミット・トランザクションはまず楽観的・モードでコミットを試行します。競合が発生した場合、自動再試行中にトランザクションは悲観的・トランザクション・モードに切り替わります。 +> 悲観的トランザクションモードが設定されている場合でも、自動コミットトランザクションはまず楽観的モードでコミットを試行します。競合が発生した場合、自動再試行中にトランザクションは悲観的トランザクションモードに切り替わります。 ### 読み書き競合 {#read-write-conflicts} From 3004a5e8e801c4092337176d8e44ff536763ae28 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 2 Sep 2026 10:47:18 +0900 Subject: [PATCH 2/9] i18n(ja): keep HTAP full-name gloss in English instead of long katakana --- develop/dev-guide-create-table.md | 2 +- develop/dev-guide-hybrid-oltp-and-olap-queries.md | 2 +- tidb-cloud/architecture-concepts.md | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/develop/dev-guide-create-table.md b/develop/dev-guide-create-table.md index 72bbace4c6e82..8d687c05e385f 100644 --- a/develop/dev-guide-create-table.md +++ b/develop/dev-guide-create-table.md @@ -234,7 +234,7 @@ CREATE TABLE `bookshop`.`users` ( `bookshop`アプリケーションを使用して`ratings`テーブルに対して OLAP 分析を実行したいとします。たとえば、**書籍の評価と評価のタイミングに有意な相関関係があるかどうかを**クエリし、ユーザーによる書籍の評価が客観的かどうかを分析したいとします。この場合、 `ratings`テーブル全体の`score`フィールドと`rated_at`フィールドをクエリする必要があります。この操作は、OLTP 専用データベースではリソースを大量に消費します。または、ETL やその他のデータ同期ツールを使用して、OLTP データベースから専用の OLAP データベースにデータをエクスポートして分析することもできます。 -このシナリオでは、OLTPとOLAPの両方のシナリオをサポートする**HTAP（ハイブリッドトランザクションアンドアナリティカルプロセッシング）**データベースであるTiDBが、理想的なワンストップデータベースソリューションとなります。 +このシナリオでは、OLTPとOLAPの両方のシナリオをサポートする**HTAP（Hybrid Transactional and Analytical Processing）**データベースであるTiDBが、理想的なワンストップデータベースソリューションとなります。 TiDBでは、オンライントランザクション処理（OLTP）には行ベースのストレージエンジンである[TiKV](/tikv-overview.md)、オンライン分析処理（OLAP）には列指向ストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)を使用できます。設定後、 TiFlashはRaft Learnerコンセンサスアルゴリズムに従ってTiKVからリアルタイムでデータを複製し、TiKVとTiFlash間のデータの一貫性を厳密に確保します。 diff --git a/develop/dev-guide-hybrid-oltp-and-olap-queries.md b/develop/dev-guide-hybrid-oltp-and-olap-queries.md index aff5e3c989626..837435992f83a 100644 --- a/develop/dev-guide-hybrid-oltp-and-olap-queries.md +++ b/develop/dev-guide-hybrid-oltp-and-olap-queries.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-hybrid-oltp-and-olap-queries/','/ja/tidbclo # HTAPクエリ {#htap-queries} -HTAPは、Hybrid Transactional and Analytical Processing（ハイブリッドトランザクションアンドアナリティカルプロセッシング）の略です。従来、データベースはトランザクション処理または分析シナリオ向けに設計されることが多く、データプラットフォームはトランザクション処理と分析処理に分割する必要があり、分析クエリへの迅速な応答のために、トランザクションデータベースから分析データベースにデータを複製する必要がありました。TiDBデータベースはトランザクションと分析の両方のタスクを実行できるため、データプラットフォームの構築が大幅に簡素化され、ユーザーはより新鮮なデータを分析に使用できるようになります。 +HTAPは、Hybrid Transactional and Analytical Processingの略です。従来、データベースはトランザクション処理または分析シナリオ向けに設計されることが多く、データプラットフォームはトランザクション処理と分析処理に分割する必要があり、分析クエリへの迅速な応答のために、トランザクションデータベースから分析データベースにデータを複製する必要がありました。TiDBデータベースはトランザクションと分析の両方のタスクを実行できるため、データプラットフォームの構築が大幅に簡素化され、ユーザーはより新鮮なデータを分析に使用できるようになります。 TiDBは、オンライントランザクション処理（OLTP）には行ベースのストレージエンジンであるTiKVを使用し、オンライン分析処理（OLAP）には列指向ストレージエンジンであるTiFlashを使用します。HTAPでは、行ベースのストレージエンジンと列指向ストレージエンジンが共存します。どちらのストレージエンジンも、データを自動的に複製し、強力な一貫性を維持できます。行ベースのストレージエンジンはOLTPのパフォーマンスを最適化し、列指向ストレージエンジンはOLAPのパフォーマンスを最適化します。 diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index 27466887460c0..6d7ce3cd6c54d 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -7,13 +7,13 @@ summary: TiDB Cloudのアーキテクチャ概念について学びましょう -TiDB Cloudは、フルマネージド型のデータベースアズアサービス（DBaaS）であり、オープンソースのHTAP（ハイブリッドトランザクションアンドアナリティカルプロセッシング）データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)の柔軟性とパワーを、Amazon Web Services（AWS）、Google Cloud、Microsoft Azure、およびAlibaba Cloudに提供します。 +TiDB Cloudは、フルマネージド型のデータベースアズアサービス（DBaaS）であり、オープンソースのHTAP（Hybrid Transactional and Analytical Processing）データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)の柔軟性とパワーを、Amazon Web Services（AWS）、Google Cloud、Microsoft Azure、およびAlibaba Cloudに提供します。 -TiDB Cloudは、フルマネージド型のデータベースアズアサービス（DBaaS）であり、オープンソースのHTAP（ハイブリッドトランザクションアンドアナリティカルプロセッシング）データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)の柔軟性とパワーを、Amazon Web Services（AWS）、Google Cloud、およびMicrosoft Azureに提供します。 +TiDB Cloudは、フルマネージド型のデータベースアズアサービス（DBaaS）であり、オープンソースのHTAP（Hybrid Transactional and Analytical Processing）データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)の柔軟性とパワーを、Amazon Web Services（AWS）、Google Cloud、およびMicrosoft Azureに提供します。 From b0640d00e45a5728acdeeec8a42e2e4903efef47 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 2 Sep 2026 10:48:10 +0900 Subject: [PATCH 3/9] i18n(ja): keep GitHub usernames in literal English instead of katakana --- releases/release-6.5.6.md | 4 ++-- releases/release-7.1.3.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index 4d0001436557a..4568293f4768f 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -21,7 +21,7 @@ TiDB バージョン: 6.5.6 - [`encoding-worker-num`](/ticdc/ticdc-changefeed-config.md)と[`flush-worker-num`](/ticdc/ticdc-changefeed-config.md) : 異なるマシンの仕様に基づいて、再実行モジュールに異なる同時実行パラメータを設定できます[＃10048](https://github.com/pingcap/tiflow/issues/10048) @[CharlesCheung96](https://github.com/CharlesCheung96) - [`compression`](/ticdc/ticdc-changefeed-config.md) : REDOログファイルの圧縮動作を設定できます[＃10176](https://github.com/pingcap/tiflow/issues/10176) @[sdojjy](https://github.com/sdojjy) - [`changefeed-error-stuck-duration`](/ticdc/ticdc-changefeed-config.md) : 内部エラーまたは例外が発生したときに、変更フィードが自動的に再試行される期間を設定できます[＃9875](https://github.com/pingcap/tiflow/issues/9875) @[asddongmen](https://github.com/asddongmen) - - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージにデータを複製するときに履歴データの自動クリーンアップを設定できます[チャールズチュン96](https://github.com/CharlesCheung96) [＃10109](https://github.com/pingcap/tiflow/issues/10109) + - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージにデータを複製するときに履歴データの自動クリーンアップを設定できます[CharlesCheung96](https://github.com/CharlesCheung96) [＃10109](https://github.com/pingcap/tiflow/issues/10109) ## 改善点 {#improvements} @@ -33,7 +33,7 @@ TiDB バージョン: 6.5.6 - OOM を防ぐためにリゾルバのメモリ使用量を最適化します [＃15458](https://github.com/tikv/tikv/issues/15458) @[overvenus](https://github.com/overvenus) - ルータオブジェクトのLRUCacheを排除してメモリ使用量を削減し、OOM を防止します。 [＃15430](https://github.com/tikv/tikv/issues/15430) @[Connor1996](https://github.com/Connor1996) - - `apply_router`と`raft_router`指標に`alive`と`leak`監視ディメンションを追加します[トニーシュッキ](https://github.com/tonyxuqqi) [＃15357](https://github.com/tikv/tikv/issues/15357) + - `apply_router`と`raft_router`指標に`alive`と`leak`監視ディメンションを追加します[tonyxuqqi](https://github.com/tonyxuqqi) [＃15357](https://github.com/tikv/tikv/issues/15357) - PD diff --git a/releases/release-7.1.3.md b/releases/release-7.1.3.md index 392f8dcd29ef6..af0f97a44f188 100644 --- a/releases/release-7.1.3.md +++ b/releases/release-7.1.3.md @@ -18,7 +18,7 @@ TiDB バージョン: 7.1.3 - [`sql-mode`](/ticdc/ticdc-changefeed-config.md) : TiCDC がデータを複製するときに DDL ステートメントを解析するために使用する[SQLモード](https://docs.pingcap.com/tidb/v7.1/ticdc-ddl#sql-mode)を設定できます[＃9876](https://github.com/pingcap/tiflow/issues/9876) @[asddongmen](https://github.com/asddongmen) - [`encoding-worker-num`](/ticdc/ticdc-changefeed-config.md)と[`flush-worker-num`](/ticdc/ticdc-changefeed-config.md) : 異なるマシンの仕様に基づいて、再実行モジュールに異なる同時実行パラメータを設定できます[＃10048](https://github.com/pingcap/tiflow/issues/10048) @[CharlesCheung96](https://github.com/CharlesCheung96) - [`compression`](/ticdc/ticdc-changefeed-config.md) : REDOログファイルの圧縮動作を設定できます[＃10176](https://github.com/pingcap/tiflow/issues/10176) @[sdojjy](https://github.com/sdojjy) - - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージにデータを複製するときに履歴データの自動クリーンアップを設定できます[チャールズチュン96](https://github.com/CharlesCheung96) [＃10109](https://github.com/pingcap/tiflow/issues/10109) + - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージにデータを複製するときに履歴データの自動クリーンアップを設定できます[CharlesCheung96](https://github.com/CharlesCheung96) [＃10109](https://github.com/pingcap/tiflow/issues/10109) ## 改善点 {#improvements} From b4d595329fa3374592ad97a76bb82707b4bda1cd Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 2 Sep 2026 10:48:58 +0900 Subject: [PATCH 4/9] i18n(ja): keep Let's Encrypt proper noun in English instead of katakana --- tidb-cloud/secure-connections-to-serverless-clusters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/secure-connections-to-serverless-clusters.md b/tidb-cloud/secure-connections-to-serverless-clusters.md index 7a61a3e29f795..3e5808875025e 100644 --- a/tidb-cloud/secure-connections-to-serverless-clusters.md +++ b/tidb-cloud/secure-connections-to-serverless-clusters.md @@ -45,7 +45,7 @@ aliases: ['/ja/tidbcloud/secure-connections-to-serverless-tier-clusters'] ### ルート証明書の発行と有効性 {#root-certificate-issuance-and-validity} -TiDB Cloudは、クライアントとTiDB Cloudクラスタ間のTLS接続において、 [レッツエンクリプト](https://letsencrypt.org/)の証明書を証明機関（CA）として使用します。TiDB Cloud証明書の有効期限が切れると、クラスタの通常の動作や確立されたTLSセキュア接続に影響を与えることなく、自動的にローテーションされます。 +TiDB Cloudは、クライアントとTiDB Cloudクラスタ間のTLS接続において、 [Let's Encrypt](https://letsencrypt.org/)の証明書を証明機関（CA）として使用します。TiDB Cloud証明書の有効期限が切れると、クラスタの通常の動作や確立されたTLSセキュア接続に影響を与えることなく、自動的にローテーションされます。 JavaやGoなど、クライアントがシステムのルートCAストアをデフォルトで使用する場合、CAルートのパスを指定せずにTiDB Cloudクラスタに安全に接続できます。ただし、一部のドライバやORMはシステムルートCAストアを使用しません。そのような場合は、ドライバやORMのCAルートパスをシステムルートCAストアに設定する必要があります。例えば、macOS上のPythonで[mysqlclient](https://github.com/PyMySQL/mysqlclient)を使用してTiDB Cloudクラスタに接続する場合、引数`ssl`に`ca: /etc/ssl/cert.pem`を設定する必要があります。 From ec67fcccf4d2bd1b2cc5d58997da8850f31eecd4 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 2 Sep 2026 10:51:39 +0900 Subject: [PATCH 5/9] i18n(ja): fix benchmark-executor heading/spacing consistency, function-vs-feature wording, and Capital Bikeshare license link text --- import-example-data.md | 2 +- migrate-from-tidb-to-tidb.md | 2 +- tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md | 4 ++-- tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md | 4 ++-- tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md | 4 ++-- tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md | 4 ++-- tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md | 4 ++-- tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md | 4 ++-- tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md | 4 ++-- tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md | 4 ++-- tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md | 4 ++-- tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md | 4 ++-- 12 files changed, 22 insertions(+), 22 deletions(-) diff --git a/import-example-data.md b/import-example-data.md index 6fb38efdd0bc3..9dc592465daae 100644 --- a/import-example-data.md +++ b/import-example-data.md @@ -5,7 +5,7 @@ summary: Bikeshare サンプルデータベースをインストールします # サンプルデータベースのインポート {#import-example-database} -TiDB マニュアルで使用されている例では、 [キャピタルバイクシェアデータライセンス契約](https://www.capitalbikeshare.com/data-license-agreement)でリリースされた Capital Bikeshare の[システムデータ](https://www.capitalbikeshare.com/system-data)が使用されています。 +TiDB マニュアルで使用されている例では、 [Capital Bikeshare Data License Agreement](https://www.capitalbikeshare.com/data-license-agreement)でリリースされた Capital Bikeshare の[システムデータ](https://www.capitalbikeshare.com/system-data)が使用されています。 ## すべてのデータファイルをダウンロードする {#download-all-data-files} diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index 28e04290682a6..a622c724fc6a0 100644 --- a/migrate-from-tidb-to-tidb.md +++ b/migrate-from-tidb-to-tidb.md @@ -99,7 +99,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー ## ステップ2. 全データの移行 {#step-2-migrate-full-data} -環境構築後、 [BR](https://github.com/pingcap/tidb/tree/release-8.5/br)のバックアップおよびリストア関数を使用して全データを移行できます。BRは[3つの方法](/br/br-use-overview.md#deploy-and-use-br)で起動できます。本稿では、SQL文`BACKUP`と`RESTORE`を使用します。 +環境構築後、 [BR](https://github.com/pingcap/tidb/tree/release-8.5/br)のバックアップおよびリストア機能を使用して全データを移行できます。BRは[3つの方法](/br/br-use-overview.md#deploy-and-use-br)で起動できます。本稿では、SQL文`BACKUP`と`RESTORE`を使用します。 > **Note:** > diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md index d8f00fb911852..277044ea53bb9 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md @@ -27,7 +27,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ | TiDB | 16 vCPU、32 GiB | 2 | 該当なし | | TiKV | 16 vCPU、64 GiB | 3 | 1000ギガバイト | -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 @@ -43,7 +43,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md index e3454294df72a..bf0a56c77a6eb 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md @@ -27,7 +27,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ | TiDB | 16 vCPU、32 GiB | 2 | 該当なし | | TiKV | 16 vCPU、64 GiB | 3 | 1000ギガバイト | -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 @@ -42,7 +42,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md index 2587f02e40360..2ed5ba9791ce4 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md @@ -48,7 +48,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = true ``` -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 @@ -64,7 +64,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md index 614462b2be7c5..29e00becd1c63 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md @@ -28,7 +28,7 @@ aliases: ['/ja/tidbcloud/v7.1.0-performance-benchmarking-with-tpcc'] | TiDB | 16 vCPU、32 GiB | 2 | 該当なし | | TiKV | 16 vCPU、64 GiB | 3 | 1000ギガバイト | -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 @@ -43,7 +43,7 @@ aliases: ['/ja/tidbcloud/v7.1.0-performance-benchmarking-with-tpcc'] 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md index ac3ce03462f16..e57363aa66bd6 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md @@ -48,7 +48,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = true ``` -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 @@ -64,7 +64,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md index b0540dcff6d74..2da1f8387cef1 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md @@ -28,7 +28,7 @@ aliases: ['/ja/tidbcloud/v7.5.0-performance-benchmarking-with-tpcc'] | TiDB | 16 vCPU、32 GiB | 2 | 該当なし | | TiKV | 16 vCPU、64 GiB | 3 | 1000ギガバイト | -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 @@ -43,7 +43,7 @@ aliases: ['/ja/tidbcloud/v7.5.0-performance-benchmarking-with-tpcc'] 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md index 0a03cfbc9dff7..053a5dfbd4991 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md @@ -53,7 +53,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = true ``` -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 @@ -69,7 +69,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md index 8b6b3fbbc53f9..7e31c2060d06b 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md @@ -39,7 +39,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = true ``` -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 @@ -54,7 +54,7 @@ raft-engine.prefill-for-recycle = true 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md index a7e34475fa8ce..667eeba80f389 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md @@ -53,7 +53,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = true ``` -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 @@ -69,7 +69,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md index 2bd01a244c40d..27008b71082ce 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md @@ -39,7 +39,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = true ``` -### ベンチマーク実行者 {#benchmark-executor} +### ベンチマークエグゼキュータ {#benchmark-executor} ベンチマークエグゼキュータはTiDBクラスタにSQLクエリを送信します。このテストでは、ハードウェア構成は次のとおりです。 @@ -54,7 +54,7 @@ raft-engine.prefill-for-recycle = true 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 -2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 +2. ベンチマークエグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 From a09ebe14d116fd58e7322237774bafb11577914e Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 2 Sep 2026 10:53:55 +0900 Subject: [PATCH 6/9] i18n(ja): restore literal English SQL command name headings in privilege-management.md Nearly every heading in the privilege-related-operations section of privilege-management.md had translated the literal SQL command name (matching a section heading per statement, e.g. ALTER, BACKUP, CREATE DATABASE, GRANT, REVOKE, CREATE/ALTER/DROP RESOURCE GROUP) into descriptive Japanese, instead of keeping it as literal English like the rest of the corpus consistently does (confirmed via TOC.md and sql-statements/sql-statement-overview.md, which both correctly keep these as literal backtick-quoted English). 31 headings restored. Also fixed the matching CREATE/DROP RESOURCE GROUP entries in tidb-resource-control-ru-groups.md's See also list, which had the same descriptive-Japanese mistranslation for 2 of its 3 sibling entries. --- privilege-management.md | 62 +++++++++++++++--------------- tidb-resource-control-ru-groups.md | 6 +-- 2 files changed, 34 insertions(+), 34 deletions(-) diff --git a/privilege-management.md b/privilege-management.md index a8d49022f5f9e..6b6a82e912bb6 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -338,7 +338,7 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; 31 rows in set (0.00 sec) ``` -### 変更する {#alter} +### ALTER {#alter} - `ALTER`ステートメントすべてにおいて、ユーザーは対応するテーブルに対する`ALTER`権限を持っている必要があります。 - `ALTER...DROP`および`ALTER...RENAME TO`以外のステートメントについては、ユーザーは対応するテーブルに対して`INSERT`および`CREATE`の権限を持っている必要があります。 @@ -349,29 +349,29 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; > > MySQL 5.7のドキュメントでは、テーブルに対して`INSERT`操作を実行するには、 `CREATE`および`ALTER`の権限であるとされています。しかし、実際にはMySQL 5.7では、この場合`ALTER`権限のみが必要です。現在、TiDB の`ALTER`権限は、MySQL の実際の動作と一致しています。 -### バックアップ {#backup} +### BACKUP {#backup} `SUPER`または`BACKUP_ADMIN`の権限が必要です。 -### インポートジョブをキャンセルする {#cancel-import-job} +### CANCEL IMPORT JOB {#cancel-import-job} 他のユーザーが作成したジョブをキャンセルするには`SUPER`権限が必要です。それ以外の場合は、現在のユーザーが作成したジョブのみキャンセルできます。 -### データベースの作成 {#create-database} +### CREATE DATABASE {#create-database} データベースに対する`CREATE`権限が必要です。 -### インデックスを作成する {#create-index} +### CREATE INDEX {#create-index} テーブルに対する`INDEX`権限が必要です。 -### テーブルを作成する {#create-table} +### CREATE TABLE {#create-table} テーブルに対する`CREATE`権限が必要です。 `CREATE TABLE...LIKE...`ステートメントを実行するには、テーブルに対する`SELECT`権限が必要です。 -### ビューの作成 {#create-view} +### CREATE VIEW {#create-view} `CREATE VIEW`権限が必要です。 @@ -379,47 +379,47 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; > > 現在のユーザーがビューを作成したユーザーでない場合、 `CREATE VIEW`と`SUPER`の両方の権限が必要です。 -### データベースの削除 {#drop-database} +### DROP DATABASE {#drop-database} データベースに対する`DROP`権限が必要です。 -### インデックスを削除 {#drop-index} +### DROP INDEX {#drop-index} テーブルに対する`INDEX`権限が必要です。 -### テーブルを削除する {#drop-tables} +### DROP TABLES {#drop-tables} テーブルに対する`DROP`権限が必要です。 -### インポート先 {#import-into} +### IMPORT INTO {#import-into} 対象テーブルに対して`SELECT` 、 `UPDATE` 、 `INSERT` 、 `DELETE` 、および`ALTER`の権限が必要です。TiDBにローカルに保存されているファイルをインポートするには、 `FILE`権限も必要です。 -### データの読み込み {#load-data} +### LOAD DATA {#load-data} テーブルに対して`INSERT`権限が必要です。 `REPLACE INTO`を使用する場合は、 `DELETE`権限も必要です。 -### テーブルを切り捨てる {#truncate-table} +### TRUNCATE TABLE {#truncate-table} テーブルに対する`DROP`権限が必要です。 -### テーブル名の変更 {#rename-table} +### RENAME TABLE {#rename-table} テーブル名を変更する前に、 `ALTER`および`DROP`の権限が必要であり、テーブル名を変更する後には`CREATE`および`INSERT`の権限。 -### 表の分析 {#analyze-table} +### ANALYZE TABLE {#analyze-table} テーブルに対する`INSERT`および`SELECT`の権限が必要です。 -### ロック統計 {#lock-stats} +### LOCK STATS {#lock-stats} テーブルに対する`INSERT`および`SELECT`の権限が必要です。 -### 統計情報をアンロックする {#unlock-stats} +### UNLOCK STATS {#unlock-stats} テーブルに対する`INSERT`および`SELECT`の権限が必要です。 -### 見せる {#show} +### SHOW {#show} `SHOW CREATE TABLE`テーブルに対する単一の権限を必要とします。 @@ -433,23 +433,23 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; `SHOW STATS_LOCKED`は`mysql.stats_table_locked`テーブルに対する`SELECT`権限を必要とします。 -### ロール/ユーザーの作成 {#create-role-user} +### CREATE ROLE/USER {#create-role-user} `CREATE ROLE`には`CREATE ROLE`の権限が必要です。 `CREATE USER`には`CREATE USER`の権限が必要です。 -### ロール/ユーザーを削除する {#drop-role-user} +### DROP ROLE/USER {#drop-role-user} `DROP ROLE`には`DROP ROLE`の権限が必要です。 `DROP USER`には`CREATE USER`の権限が必要です。 -### ユーザーの変更 {#alter-user} +### ALTER USER {#alter-user} `CREATE USER`権限が必要です。 -### 付与 {#grant} +### GRANT {#grant} `GRANT`によって付与された権限を持つ`GRANT`権限が必要です。 @@ -457,21 +457,21 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; `GRANT ROLE`には`SUPER`または`ROLE_ADMIN`権限が必要です。 -### 取り消す {#revoke} +### REVOKE {#revoke} `GRANT`権限と、 `REVOKE`ステートメントで指定されている権限が必要です。 `REVOKE ROLE`には`SUPER`または`ROLE_ADMIN`権限が必要です。 -### グローバル設定 {#set-global} +### SET GLOBAL {#set-global} グローバル変数を設定するには、 `SUPER`または`SYSTEM_VARIABLES_ADMIN`の権限が必要です。 -### 管理者 {#admin} +### ADMIN {#admin} `SUPER`の権限が必要です。 -### デフォルトロールを設定する {#set-default-role} +### SET DEFAULT ROLE {#set-default-role} `SUPER`の権限が必要です。 @@ -479,23 +479,23 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; 他のユーザーセッションを終了するには、 `SUPER`または`CONNECTION_ADMIN`の権限が必要です。 -### リソースグループを作成する {#create-resource-group} +### CREATE RESOURCE GROUP {#create-resource-group} `SUPER`または`RESOURCE_GROUP_ADMIN`の権限が必要です。 -### アルターリソースグループ {#alter-resource-group} +### ALTER RESOURCE GROUP {#alter-resource-group} `SUPER`または`RESOURCE_GROUP_ADMIN`の権限が必要です。 -### リソースグループを削除する {#drop-resource-group} +### DROP RESOURCE GROUP {#drop-resource-group} `SUPER`または`RESOURCE_GROUP_ADMIN`の権限が必要です。 -### リソースの校正 {#calibrate-resource} +### CALIBRATE RESOURCE {#calibrate-resource} `SUPER`または`RESOURCE_GROUP_ADMIN`の権限が必要です。 -### リソースグループを設定する {#set-resource-group} +### SET RESOURCE GROUP {#set-resource-group} システム変数[`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820) `ON`に設定されている場合、このステートメントを実行するには`SUPER`または`RESOURCE_GROUP_ADMIN`または`RESOURCE_GROUP_USER`の権限が必要です。 diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index 73558225f9fd3..c60199e2f0e88 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -403,9 +403,9 @@ TiKVは、Grafanaの**TiKV**ダッシュボードに、さまざまなリソー ## 参照 {#see-also} -- [リソースグループを作成する](/sql-statements/sql-statement-create-resource-group.md) -- [アルターリソースグループ](/sql-statements/sql-statement-alter-resource-group.md) -- [リソースグループを削除する](/sql-statements/sql-statement-drop-resource-group.md) +- [CREATE RESOURCE GROUP](/sql-statements/sql-statement-create-resource-group.md) +- [ALTER RESOURCE GROUP](/sql-statements/sql-statement-alter-resource-group.md) +- [DROP RESOURCE GROUP](/sql-statements/sql-statement-drop-resource-group.md) - [リソースグループRFC](https://github.com/pingcap/tidb/blob/release-8.5/docs/design/2022-11-25-global-resource-control.md) ## 関連リソース {#related-resources} From 1b40baf7c23b5ff98bb78274c4c6d3b3a5740cb3 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 2 Sep 2026 11:05:00 +0900 Subject: [PATCH 7/9] i18n(ja): fix grammar, missing particles, and scrambled word order in privilege-management.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Multiple defects found via user's line-by-line review of the privilege-related-operations section: - Broken verb ending (X権限ている -> X権限を持っている) in the ALTER bullet list - RENAME TABLE description ended as an incomplete sentence fragment with no verb, and used incorrect する後 instead of した後 - SHOW CREATE TABLE / SHOW GRANTS / User+Host sentences missing a subject-marking は particle, causing misreadable run-ons - SHOW GRANTS description had SELECT and mysql swapped (said "mysql privilege to the SELECT database" instead of "SELECT privilege to the mysql database") - Same swap defect in the user-table paragraph (DELETE/user reversed) and in the tables_priv/columns_priv paragraph (% and tables_priv reversed) - ALTER USER dropped the の particle, inconsistent with every sibling entry's "Xの権限が必要です" pattern - GRANT section had a garbled single-noun-phrase structure instead of mirroring the correctly-structured REVOKE section right below it (both should say "X権限と、Yの権限が必要です") - SET RESOURCE GROUP: missing が particle before 「ONに設定されている場合」 - Time of effect section: missing などの before both statement-list summaries, making 4 example statements read as if they were collectively named "privilege management statement(s)" rather than examples of that category --- privilege-management.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/privilege-management.md b/privilege-management.md index 6b6a82e912bb6..51a1d4c2fd174 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -343,7 +343,7 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; - `ALTER`ステートメントすべてにおいて、ユーザーは対応するテーブルに対する`ALTER`権限を持っている必要があります。 - `ALTER...DROP`および`ALTER...RENAME TO`以外のステートメントについては、ユーザーは対応するテーブルに対して`INSERT`および`CREATE`の権限を持っている必要があります。 - `ALTER...DROP`ステートメントを使用するには、ユーザーは対応するテーブルに対して`DROP`権限を持っている必要があります。 -- `ALTER...RENAME TO`ステートメントを実行するには、ユーザーは名前変更前にテーブルに対する`DROP`権限を持ち、名前変更後にテーブルに対する`CREATE`および`INSERT`権限ている必要があります。 +- `ALTER...RENAME TO`ステートメントを実行するには、ユーザーは名前変更前にテーブルに対する`DROP`権限を持ち、名前変更後にテーブルに対する`CREATE`および`INSERT`権限を持っている必要があります。 > **Note:** > @@ -405,7 +405,7 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; ### RENAME TABLE {#rename-table} -テーブル名を変更する前に、 `ALTER`および`DROP`の権限が必要であり、テーブル名を変更する後には`CREATE`および`INSERT`の権限。 +テーブル名を変更する前に、 `ALTER`および`DROP`の権限が必要であり、テーブル名を変更した後には`CREATE`および`INSERT`の権限が必要です。 ### ANALYZE TABLE {#analyze-table} @@ -421,11 +421,11 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; ### SHOW {#show} -`SHOW CREATE TABLE`テーブルに対する単一の権限を必要とします。 +`SHOW CREATE TABLE`は、テーブルに対する単一の権限を必要とします。 `SHOW CREATE VIEW`には`SHOW VIEW`の権限が必要です。 -`SHOW GRANTS`は`SELECT`データベースへの`mysql`権限を必要とします。対象ユーザーが現在のユーザーである場合、 `SHOW GRANTS`権限を必要としません。 +`SHOW GRANTS`は`mysql`データベースへの`SELECT`権限を必要とします。対象ユーザーが現在のユーザーである場合、 `SHOW GRANTS`は権限を必要としません。 `SHOW PROCESSLIST`は、他のユーザーに属する接続を表示するために`PROCESS`の権限を必要とします。 @@ -447,11 +447,11 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; ### ALTER USER {#alter-user} -`CREATE USER`権限が必要です。 +`CREATE USER`の権限が必要です。 ### GRANT {#grant} -`GRANT`によって付与された権限を持つ`GRANT`権限が必要です。 +`GRANT`権限と、 `GRANT`によって付与される権限が必要です。 ユーザーを暗黙的に作成するには、追加の`CREATE USER`権限が必要です。 @@ -497,7 +497,7 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; ### SET RESOURCE GROUP {#set-resource-group} -システム変数[`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820) `ON`に設定されている場合、このステートメントを実行するには`SUPER`または`RESOURCE_GROUP_ADMIN`または`RESOURCE_GROUP_USER`の権限が必要です。 +システム変数[`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820)が`ON`に設定されている場合、このステートメントを実行するには`SUPER`または`RESOURCE_GROUP_ADMIN`または`RESOURCE_GROUP_USER`の権限が必要です。 ## 特権システムの導入 {#implementation-of-the-privilege-system} @@ -539,7 +539,7 @@ SELECT User,Host,Select_priv,Insert_priv FROM mysql.user LIMIT 1; ユーザーの識別は、接続を開始するホスト`Host`とユーザー名`User`の2つの情報に基づいています。ユーザー名が空でない場合、指定されたユーザー名と完全に一致する必要があります。 -`User` + `Host` `user`テーブルの複数の行に一致する可能性があります。このシナリオに対処するため、 `user`テーブルの行はソートされます。クライアントが接続すると、テーブルの行が 1つずつチェックされ、最初に一致した行が検証に使用されます。ソート時には、ホストがユーザーよりも優先されます。 +`User`+`Host`は、 `user`テーブルの複数の行に一致する可能性があります。このシナリオに対処するため、 `user`テーブルの行はソートされます。クライアントが接続すると、テーブルの行が 1つずつチェックされ、最初に一致した行が検証に使用されます。ソート時には、ホストがユーザーよりも優先されます。 ### リクエストの確認 {#request-verification} @@ -547,16 +547,16 @@ SELECT User,Host,Select_priv,Insert_priv FROM mysql.user LIMIT 1; データベース関連のリクエスト（ `INSERT` 、 `UPDATE` ）の場合、リクエスト検証プロセスではまず`mysql.user`テーブルでユーザーのグローバル権限を確認します。権限が付与されている場合は、直接アクセスできます。付与されていない場合は、 `mysql.db`テーブルを確認します。 -`user`テーブルは、デフォルトのデータベースに関係なく、グローバルな権限を持ちます。たとえば、 `DELETE`の`user`権限は、任意の行、テーブル、またはデータベースに適用できます。 +`user`テーブルは、デフォルトのデータベースに関係なく、グローバルな権限を持ちます。たとえば、 `user`の`DELETE`権限は、任意の行、テーブル、またはデータベースに適用できます。 `db`テーブルでは、空のユーザーは匿名ユーザー名に一致します。 `User`列ではワイルドカードは使用できません。 `Host`列と`Db`列の値には、パターンマッチングを使用できる`%`と`_`を使用できます。 `user`および`db`テーブルのデータも、メモリにロードされるときにソートされます。 -`%`と`tables_priv`における`columns_priv`の使用方法は似ていますが、 `Db` 、 `Table_name` 、 `Column_name`の列値には`%`を含めることはできません。読み込み時のソートも同様です。 +`tables_priv`と`columns_priv`における`%`の使用方法は似ていますが、 `Db` 、 `Table_name` 、 `Column_name`の列値には`%`を含めることはできません。読み込み時のソートも同様です。 ### 有効期間 {#time-of-effect} -TiDB が起動すると、いくつかの権限チェックテーブルがメモリにロードされ、キャッシュされたデータを使用して権限が検証されます。 `GRANT` 、 `REVOKE` 、 `CREATE USER` 、 `DROP USER`権限管理ステートメントを実行すると、すぐに反映されます。 +TiDB が起動すると、いくつかの権限チェックテーブルがメモリにロードされ、キャッシュされたデータを使用して権限が検証されます。 `GRANT` 、 `REVOKE` 、 `CREATE USER` 、 `DROP USER`などの権限管理ステートメントを実行すると、すぐに反映されます。 -`mysql.user`などのテーブルを`INSERT` 、 `DELETE` 、 `UPDATE`手動で編集しても、すぐに反映されません。この動作は MySQL と互換性があり、権限キャッシュは[`FLUSH PRIVILEGES`](/sql-statements/sql-statement-flush-privileges.md)ステートメントで更新できます。 +`mysql.user`などのテーブルを`INSERT` 、 `DELETE` 、 `UPDATE`などのステートメントで手動編集しても、すぐに反映されません。この動作は MySQL と互換性があり、権限キャッシュは[`FLUSH PRIVILEGES`](/sql-statements/sql-statement-flush-privileges.md)ステートメントで更新できます。 From f0fada3d3d008e24ddaa52dfc215e39ea363680c Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 2 Sep 2026 11:07:29 +0900 Subject: [PATCH 8/9] Revert "i18n(ja): fix grammar, missing particles, and scrambled word order in privilege-management.md" This reverts commit 1b40baf7c23b5ff98bb78274c4c6d3b3a5740cb3. --- privilege-management.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/privilege-management.md b/privilege-management.md index 51a1d4c2fd174..6b6a82e912bb6 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -343,7 +343,7 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; - `ALTER`ステートメントすべてにおいて、ユーザーは対応するテーブルに対する`ALTER`権限を持っている必要があります。 - `ALTER...DROP`および`ALTER...RENAME TO`以外のステートメントについては、ユーザーは対応するテーブルに対して`INSERT`および`CREATE`の権限を持っている必要があります。 - `ALTER...DROP`ステートメントを使用するには、ユーザーは対応するテーブルに対して`DROP`権限を持っている必要があります。 -- `ALTER...RENAME TO`ステートメントを実行するには、ユーザーは名前変更前にテーブルに対する`DROP`権限を持ち、名前変更後にテーブルに対する`CREATE`および`INSERT`権限を持っている必要があります。 +- `ALTER...RENAME TO`ステートメントを実行するには、ユーザーは名前変更前にテーブルに対する`DROP`権限を持ち、名前変更後にテーブルに対する`CREATE`および`INSERT`権限ている必要があります。 > **Note:** > @@ -405,7 +405,7 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; ### RENAME TABLE {#rename-table} -テーブル名を変更する前に、 `ALTER`および`DROP`の権限が必要であり、テーブル名を変更した後には`CREATE`および`INSERT`の権限が必要です。 +テーブル名を変更する前に、 `ALTER`および`DROP`の権限が必要であり、テーブル名を変更する後には`CREATE`および`INSERT`の権限。 ### ANALYZE TABLE {#analyze-table} @@ -421,11 +421,11 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; ### SHOW {#show} -`SHOW CREATE TABLE`は、テーブルに対する単一の権限を必要とします。 +`SHOW CREATE TABLE`テーブルに対する単一の権限を必要とします。 `SHOW CREATE VIEW`には`SHOW VIEW`の権限が必要です。 -`SHOW GRANTS`は`mysql`データベースへの`SELECT`権限を必要とします。対象ユーザーが現在のユーザーである場合、 `SHOW GRANTS`は権限を必要としません。 +`SHOW GRANTS`は`SELECT`データベースへの`mysql`権限を必要とします。対象ユーザーが現在のユーザーである場合、 `SHOW GRANTS`権限を必要としません。 `SHOW PROCESSLIST`は、他のユーザーに属する接続を表示するために`PROCESS`の権限を必要とします。 @@ -447,11 +447,11 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; ### ALTER USER {#alter-user} -`CREATE USER`の権限が必要です。 +`CREATE USER`権限が必要です。 ### GRANT {#grant} -`GRANT`権限と、 `GRANT`によって付与される権限が必要です。 +`GRANT`によって付与された権限を持つ`GRANT`権限が必要です。 ユーザーを暗黙的に作成するには、追加の`CREATE USER`権限が必要です。 @@ -497,7 +497,7 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; ### SET RESOURCE GROUP {#set-resource-group} -システム変数[`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820)が`ON`に設定されている場合、このステートメントを実行するには`SUPER`または`RESOURCE_GROUP_ADMIN`または`RESOURCE_GROUP_USER`の権限が必要です。 +システム変数[`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820) `ON`に設定されている場合、このステートメントを実行するには`SUPER`または`RESOURCE_GROUP_ADMIN`または`RESOURCE_GROUP_USER`の権限が必要です。 ## 特権システムの導入 {#implementation-of-the-privilege-system} @@ -539,7 +539,7 @@ SELECT User,Host,Select_priv,Insert_priv FROM mysql.user LIMIT 1; ユーザーの識別は、接続を開始するホスト`Host`とユーザー名`User`の2つの情報に基づいています。ユーザー名が空でない場合、指定されたユーザー名と完全に一致する必要があります。 -`User`+`Host`は、 `user`テーブルの複数の行に一致する可能性があります。このシナリオに対処するため、 `user`テーブルの行はソートされます。クライアントが接続すると、テーブルの行が 1つずつチェックされ、最初に一致した行が検証に使用されます。ソート時には、ホストがユーザーよりも優先されます。 +`User` + `Host` `user`テーブルの複数の行に一致する可能性があります。このシナリオに対処するため、 `user`テーブルの行はソートされます。クライアントが接続すると、テーブルの行が 1つずつチェックされ、最初に一致した行が検証に使用されます。ソート時には、ホストがユーザーよりも優先されます。 ### リクエストの確認 {#request-verification} @@ -547,16 +547,16 @@ SELECT User,Host,Select_priv,Insert_priv FROM mysql.user LIMIT 1; データベース関連のリクエスト（ `INSERT` 、 `UPDATE` ）の場合、リクエスト検証プロセスではまず`mysql.user`テーブルでユーザーのグローバル権限を確認します。権限が付与されている場合は、直接アクセスできます。付与されていない場合は、 `mysql.db`テーブルを確認します。 -`user`テーブルは、デフォルトのデータベースに関係なく、グローバルな権限を持ちます。たとえば、 `user`の`DELETE`権限は、任意の行、テーブル、またはデータベースに適用できます。 +`user`テーブルは、デフォルトのデータベースに関係なく、グローバルな権限を持ちます。たとえば、 `DELETE`の`user`権限は、任意の行、テーブル、またはデータベースに適用できます。 `db`テーブルでは、空のユーザーは匿名ユーザー名に一致します。 `User`列ではワイルドカードは使用できません。 `Host`列と`Db`列の値には、パターンマッチングを使用できる`%`と`_`を使用できます。 `user`および`db`テーブルのデータも、メモリにロードされるときにソートされます。 -`tables_priv`と`columns_priv`における`%`の使用方法は似ていますが、 `Db` 、 `Table_name` 、 `Column_name`の列値には`%`を含めることはできません。読み込み時のソートも同様です。 +`%`と`tables_priv`における`columns_priv`の使用方法は似ていますが、 `Db` 、 `Table_name` 、 `Column_name`の列値には`%`を含めることはできません。読み込み時のソートも同様です。 ### 有効期間 {#time-of-effect} -TiDB が起動すると、いくつかの権限チェックテーブルがメモリにロードされ、キャッシュされたデータを使用して権限が検証されます。 `GRANT` 、 `REVOKE` 、 `CREATE USER` 、 `DROP USER`などの権限管理ステートメントを実行すると、すぐに反映されます。 +TiDB が起動すると、いくつかの権限チェックテーブルがメモリにロードされ、キャッシュされたデータを使用して権限が検証されます。 `GRANT` 、 `REVOKE` 、 `CREATE USER` 、 `DROP USER`権限管理ステートメントを実行すると、すぐに反映されます。 -`mysql.user`などのテーブルを`INSERT` 、 `DELETE` 、 `UPDATE`などのステートメントで手動編集しても、すぐに反映されません。この動作は MySQL と互換性があり、権限キャッシュは[`FLUSH PRIVILEGES`](/sql-statements/sql-statement-flush-privileges.md)ステートメントで更新できます。 +`mysql.user`などのテーブルを`INSERT` 、 `DELETE` 、 `UPDATE`手動で編集しても、すぐに反映されません。この動作は MySQL と互換性があり、権限キャッシュは[`FLUSH PRIVILEGES`](/sql-statements/sql-statement-flush-privileges.md)ステートメントで更新できます。 From 5f116a62b01c6c55392c963d2a2fda60f8896c2d Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 2 Sep 2026 11:07:29 +0900 Subject: [PATCH 9/9] Revert "i18n(ja): restore literal English SQL command name headings in privilege-management.md" This reverts commit a09ebe14d116fd58e7322237774bafb11577914e. --- privilege-management.md | 62 +++++++++++++++--------------- tidb-resource-control-ru-groups.md | 6 +-- 2 files changed, 34 insertions(+), 34 deletions(-) diff --git a/privilege-management.md b/privilege-management.md index 6b6a82e912bb6..a8d49022f5f9e 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -338,7 +338,7 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; 31 rows in set (0.00 sec) ``` -### ALTER {#alter} +### 変更する {#alter} - `ALTER`ステートメントすべてにおいて、ユーザーは対応するテーブルに対する`ALTER`権限を持っている必要があります。 - `ALTER...DROP`および`ALTER...RENAME TO`以外のステートメントについては、ユーザーは対応するテーブルに対して`INSERT`および`CREATE`の権限を持っている必要があります。 @@ -349,29 +349,29 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; > > MySQL 5.7のドキュメントでは、テーブルに対して`INSERT`操作を実行するには、 `CREATE`および`ALTER`の権限であるとされています。しかし、実際にはMySQL 5.7では、この場合`ALTER`権限のみが必要です。現在、TiDB の`ALTER`権限は、MySQL の実際の動作と一致しています。 -### BACKUP {#backup} +### バックアップ {#backup} `SUPER`または`BACKUP_ADMIN`の権限が必要です。 -### CANCEL IMPORT JOB {#cancel-import-job} +### インポートジョブをキャンセルする {#cancel-import-job} 他のユーザーが作成したジョブをキャンセルするには`SUPER`権限が必要です。それ以外の場合は、現在のユーザーが作成したジョブのみキャンセルできます。 -### CREATE DATABASE {#create-database} +### データベースの作成 {#create-database} データベースに対する`CREATE`権限が必要です。 -### CREATE INDEX {#create-index} +### インデックスを作成する {#create-index} テーブルに対する`INDEX`権限が必要です。 -### CREATE TABLE {#create-table} +### テーブルを作成する {#create-table} テーブルに対する`CREATE`権限が必要です。 `CREATE TABLE...LIKE...`ステートメントを実行するには、テーブルに対する`SELECT`権限が必要です。 -### CREATE VIEW {#create-view} +### ビューの作成 {#create-view} `CREATE VIEW`権限が必要です。 @@ -379,47 +379,47 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; > > 現在のユーザーがビューを作成したユーザーでない場合、 `CREATE VIEW`と`SUPER`の両方の権限が必要です。 -### DROP DATABASE {#drop-database} +### データベースの削除 {#drop-database} データベースに対する`DROP`権限が必要です。 -### DROP INDEX {#drop-index} +### インデックスを削除 {#drop-index} テーブルに対する`INDEX`権限が必要です。 -### DROP TABLES {#drop-tables} +### テーブルを削除する {#drop-tables} テーブルに対する`DROP`権限が必要です。 -### IMPORT INTO {#import-into} +### インポート先 {#import-into} 対象テーブルに対して`SELECT` 、 `UPDATE` 、 `INSERT` 、 `DELETE` 、および`ALTER`の権限が必要です。TiDBにローカルに保存されているファイルをインポートするには、 `FILE`権限も必要です。 -### LOAD DATA {#load-data} +### データの読み込み {#load-data} テーブルに対して`INSERT`権限が必要です。 `REPLACE INTO`を使用する場合は、 `DELETE`権限も必要です。 -### TRUNCATE TABLE {#truncate-table} +### テーブルを切り捨てる {#truncate-table} テーブルに対する`DROP`権限が必要です。 -### RENAME TABLE {#rename-table} +### テーブル名の変更 {#rename-table} テーブル名を変更する前に、 `ALTER`および`DROP`の権限が必要であり、テーブル名を変更する後には`CREATE`および`INSERT`の権限。 -### ANALYZE TABLE {#analyze-table} +### 表の分析 {#analyze-table} テーブルに対する`INSERT`および`SELECT`の権限が必要です。 -### LOCK STATS {#lock-stats} +### ロック統計 {#lock-stats} テーブルに対する`INSERT`および`SELECT`の権限が必要です。 -### UNLOCK STATS {#unlock-stats} +### 統計情報をアンロックする {#unlock-stats} テーブルに対する`INSERT`および`SELECT`の権限が必要です。 -### SHOW {#show} +### 見せる {#show} `SHOW CREATE TABLE`テーブルに対する単一の権限を必要とします。 @@ -433,23 +433,23 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; `SHOW STATS_LOCKED`は`mysql.stats_table_locked`テーブルに対する`SELECT`権限を必要とします。 -### CREATE ROLE/USER {#create-role-user} +### ロール/ユーザーの作成 {#create-role-user} `CREATE ROLE`には`CREATE ROLE`の権限が必要です。 `CREATE USER`には`CREATE USER`の権限が必要です。 -### DROP ROLE/USER {#drop-role-user} +### ロール/ユーザーを削除する {#drop-role-user} `DROP ROLE`には`DROP ROLE`の権限が必要です。 `DROP USER`には`CREATE USER`の権限が必要です。 -### ALTER USER {#alter-user} +### ユーザーの変更 {#alter-user} `CREATE USER`権限が必要です。 -### GRANT {#grant} +### 付与 {#grant} `GRANT`によって付与された権限を持つ`GRANT`権限が必要です。 @@ -457,21 +457,21 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; `GRANT ROLE`には`SUPER`または`ROLE_ADMIN`権限が必要です。 -### REVOKE {#revoke} +### 取り消す {#revoke} `GRANT`権限と、 `REVOKE`ステートメントで指定されている権限が必要です。 `REVOKE ROLE`には`SUPER`または`ROLE_ADMIN`権限が必要です。 -### SET GLOBAL {#set-global} +### グローバル設定 {#set-global} グローバル変数を設定するには、 `SUPER`または`SYSTEM_VARIABLES_ADMIN`の権限が必要です。 -### ADMIN {#admin} +### 管理者 {#admin} `SUPER`の権限が必要です。 -### SET DEFAULT ROLE {#set-default-role} +### デフォルトロールを設定する {#set-default-role} `SUPER`の権限が必要です。 @@ -479,23 +479,23 @@ SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE grantee = "'root'@'%'"; 他のユーザーセッションを終了するには、 `SUPER`または`CONNECTION_ADMIN`の権限が必要です。 -### CREATE RESOURCE GROUP {#create-resource-group} +### リソースグループを作成する {#create-resource-group} `SUPER`または`RESOURCE_GROUP_ADMIN`の権限が必要です。 -### ALTER RESOURCE GROUP {#alter-resource-group} +### アルターリソースグループ {#alter-resource-group} `SUPER`または`RESOURCE_GROUP_ADMIN`の権限が必要です。 -### DROP RESOURCE GROUP {#drop-resource-group} +### リソースグループを削除する {#drop-resource-group} `SUPER`または`RESOURCE_GROUP_ADMIN`の権限が必要です。 -### CALIBRATE RESOURCE {#calibrate-resource} +### リソースの校正 {#calibrate-resource} `SUPER`または`RESOURCE_GROUP_ADMIN`の権限が必要です。 -### SET RESOURCE GROUP {#set-resource-group} +### リソースグループを設定する {#set-resource-group} システム変数[`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820) `ON`に設定されている場合、このステートメントを実行するには`SUPER`または`RESOURCE_GROUP_ADMIN`または`RESOURCE_GROUP_USER`の権限が必要です。 diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index c60199e2f0e88..73558225f9fd3 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -403,9 +403,9 @@ TiKVは、Grafanaの**TiKV**ダッシュボードに、さまざまなリソー ## 参照 {#see-also} -- [CREATE RESOURCE GROUP](/sql-statements/sql-statement-create-resource-group.md) -- [ALTER RESOURCE GROUP](/sql-statements/sql-statement-alter-resource-group.md) -- [DROP RESOURCE GROUP](/sql-statements/sql-statement-drop-resource-group.md) +- [リソースグループを作成する](/sql-statements/sql-statement-create-resource-group.md) +- [アルターリソースグループ](/sql-statements/sql-statement-alter-resource-group.md) +- [リソースグループを削除する](/sql-statements/sql-statement-drop-resource-group.md) - [リソースグループRFC](https://github.com/pingcap/tidb/blob/release-8.5/docs/design/2022-11-25-global-resource-control.md) ## 関連リソース {#related-resources}