From 0175b0983b5dbe90240b722cf3bbaf87c08d23a7 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 14:17:25 +0900 Subject: [PATCH 01/56] i18n(ja): restore literal quoted config/status/enum values across the corpus --- ai/examples/memory-with-pytidb.md | 4 +-- ai/guides/filtering.md | 2 +- ai/guides/tables.md | 2 +- ...or-search-integrate-with-amazon-bedrock.md | 2 +- ai/vector-search-get-started-using-python.md | 6 ++-- alert-rules.md | 6 ++-- as-of-timestamp.md | 2 +- benchmark/benchmark-sysbench-v3.md | 2 +- benchmark/benchmark-tidb-using-sysbench.md | 2 +- benchmark/benchmark-tpch.md | 6 ++-- best-practices/ddl-introduction.md | 6 ++-- best-practices/haproxy-best-practices.md | 6 ++-- .../multi-column-index-best-practices.md | 2 +- .../pd-scheduling-best-practices.md | 8 ++--- br/br-auto-tune.md | 2 +- choose-index.md | 4 +-- clinic/quick-start-with-clinic.md | 2 +- column-pruning.md | 2 +- command-line-flags-for-pd-configuration.md | 4 +-- ...line-flags-for-scheduling-configuration.md | 2 +- command-line-flags-for-tidb-configuration.md | 6 ++-- command-line-flags-for-tikv-configuration.md | 2 +- command-line-flags-for-tso-configuration.md | 2 +- configure-memory-usage.md | 2 +- configure-placement-rules.md | 2 +- dashboard/dashboard-access.md | 2 +- dashboard/dashboard-cluster-info.md | 4 +-- dashboard/dashboard-intro.md | 4 +-- dashboard/dashboard-ops-deploy.md | 2 +- dashboard/dashboard-session-sso.md | 4 +-- data-type-date-and-time.md | 30 ++++++++-------- develop/dev-guide-aws-appflow-integration.md | 2 +- develop/dev-guide-connection-parameters.md | 8 ++--- develop/dev-guide-object-naming-guidelines.md | 2 +- develop/dev-guide-sample-application-cs.md | 2 +- ...ide-sample-application-nodejs-sequelize.md | 2 +- develop/dev-guide-transaction-overview.md | 4 +-- .../dev-guide-use-common-table-expression.md | 2 +- develop/dev-guide-use-follower-read.md | 4 +-- develop/java-app-best-practices.md | 14 ++++---- dm/deploy-a-dm-cluster-using-tiup.md | 2 +- dm/dm-continuous-data-validation.md | 6 ++-- dm/dm-faq.md | 2 +- dm/dm-glossary.md | 4 +-- dm/dm-pause-task.md | 2 +- dm/dm-precheck.md | 4 +-- dm/dm-query-status.md | 8 ++--- dm/dm-replication-logic.md | 6 ++-- dm/dm-safe-mode.md | 2 +- dm/feature-shard-merge-optimistic.md | 8 ++--- dm/handle-failed-ddl-statements.md | 4 +-- dm/monitor-a-dm-cluster.md | 4 +-- dm/quick-start-create-source.md | 2 +- dm/quick-start-create-task.md | 4 +-- dm/relay-log.md | 6 ++-- dm/shard-merge-best-practices.md | 4 +-- dm/table-selector.md | 2 +- dr-multi-replica.md | 2 +- dr-secondary-cluster.md | 2 +- dr-solution-introduction.md | 8 ++--- dumpling-overview.md | 8 ++--- encryption-at-rest.md | 4 +-- error-codes.md | 2 +- explain-joins.md | 2 +- faq/upgrade-faq.md | 2 +- filter-dml-event.md | 2 +- foreign-key.md | 2 +- .../aggregate-group-by-functions.md | 10 +++--- .../date-and-time-functions.md | 16 ++++----- functions-and-operators/precision-math.md | 2 +- garbage-collection-overview.md | 2 +- glossary.md | 4 +-- grafana-overview-dashboard.md | 4 +-- grafana-tidb-dashboard.md | 2 +- identify-expensive-queries.md | 2 +- identify-slow-queries.md | 2 +- index-advisor.md | 4 +-- .../client-errors-summary-by-host.md | 2 +- .../information-schema-inspection-result.md | 6 ++-- ...rmation-schema-memory-usage-ops-history.md | 2 +- literal-values.md | 2 +- migrate-from-tidb-to-mysql.md | 2 +- migrate-small-mysql-to-tidb.md | 2 +- multi-data-centers-in-one-city-deployment.md | 2 +- non-transactional-dml.md | 2 +- overview.md | 2 +- partitioned-table.md | 2 +- password-management.md | 6 ++-- pd-configuration-file.md | 2 +- pd-control.md | 8 ++--- quick-start-with-tidb.md | 2 +- read-historical-data.md | 2 +- releases/release-2.0.1.md | 2 +- releases/release-2.0.6.md | 2 +- releases/release-2.1-rc.3.md | 2 +- releases/release-2.1-rc.4.md | 4 +-- releases/release-2.1.12.md | 2 +- releases/release-2.1.17.md | 2 +- releases/release-2.1.18.md | 2 +- releases/release-2.1.2.md | 2 +- releases/release-2.1.4.md | 2 +- releases/release-3.0.0-beta.1.md | 4 +-- releases/release-3.0.0-rc.1.md | 2 +- releases/release-3.0.0-rc.3.md | 2 +- releases/release-3.0.1.md | 2 +- releases/release-3.0.16.md | 2 +- releases/release-3.0.2.md | 2 +- releases/release-3.0.5.md | 2 +- releases/release-3.0.6.md | 2 +- releases/release-3.1.2.md | 2 +- releases/release-4.0.0-rc.md | 2 +- releases/release-4.0.11.md | 2 +- releases/release-4.0.12.md | 2 +- releases/release-4.0.14.md | 6 ++-- releases/release-4.0.15.md | 4 +-- releases/release-4.0.7.md | 2 +- releases/release-4.0.8.md | 2 +- releases/release-4.0.9.md | 6 ++-- releases/release-5.0.0-rc.md | 2 +- releases/release-5.0.0.md | 4 +-- releases/release-5.0.3.md | 2 +- releases/release-5.0.4.md | 8 ++--- releases/release-5.0.5.md | 2 +- releases/release-5.1.0.md | 4 +-- releases/release-5.1.2.md | 4 +-- releases/release-5.1.4.md | 4 +-- releases/release-5.2.0.md | 6 ++-- releases/release-5.3.0.md | 4 +-- releases/release-5.3.1.md | 4 +-- releases/release-5.4.0.md | 10 +++--- releases/release-6.0.0-dmr.md | 4 +-- releases/release-6.1.1.md | 2 +- releases/release-6.1.4.md | 6 ++-- releases/release-6.2.0.md | 10 +++--- releases/release-6.3.0.md | 2 +- releases/release-6.5.0.md | 2 +- releases/release-6.5.1.md | 4 +-- releases/release-6.5.3.md | 2 +- releases/release-6.6.0.md | 4 +-- releases/release-7.1.0.md | 2 +- releases/release-7.2.0.md | 2 +- releases/release-7.5.0.md | 2 +- releases/release-7.5.1.md | 2 +- releases/release-7.6.0.md | 2 +- releases/release-8.1.0.md | 6 ++-- releases/release-8.5.0.md | 2 +- releases/release-rc.1.md | 2 +- releases/release-rc.2.md | 2 +- resources/doc-templates/template-concept.md | 4 +-- role-based-access-control.md | 2 +- security-compatibility-with-mysql.md | 4 +-- sql-mode.md | 6 ++-- sql-plan-management.md | 2 +- sql-prepared-plan-cache.md | 2 +- sql-statements/sql-statement-alter-index.md | 2 +- sql-statements/sql-statement-alter-table.md | 2 +- sql-statements/sql-statement-backup.md | 2 +- .../sql-statement-calibrate-resource.md | 2 +- .../sql-statement-flashback-cluster.md | 2 +- sql-statements/sql-statement-restore.md | 4 +-- sql-statements/sql-statement-split-region.md | 2 +- stale-read.md | 2 +- statement-summary-tables.md | 4 +-- system-variables.md | 20 +++++------ table-filter.md | 8 ++--- ...e-data-centers-in-two-cities-deployment.md | 2 +- ticdc/ticdc-avro-protocol.md | 2 +- ticdc/ticdc-canal-json.md | 2 +- ticdc/ticdc-changefeed-config.md | 4 +-- ticdc/ticdc-debezium.md | 2 +- ticdc/ticdc-manage-changefeed.md | 2 +- ticdc/ticdc-open-api-v2.md | 4 +-- ticdc/ticdc-open-api.md | 2 +- ticdc/ticdc-sink-to-kafka.md | 6 ++-- tidb-cloud/backup-and-restore.md | 2 +- tidb-cloud/changefeed-sink-to-apache-kafka.md | 2 +- ...ess-firewall-rules-for-public-endpoints.md | 2 +- tidb-cloud/configure-sql-users.md | 2 +- tidb-cloud/csv-config-for-import-data.md | 2 +- tidb-cloud/data-service-api-key.md | 2 +- tidb-cloud/data-service-custom-domain.md | 2 +- tidb-cloud/dedicated-external-storage.md | 2 +- tidb-cloud/essential-changefeed-overview.md | 2 +- .../essential-changefeed-sink-to-kafka.md | 4 +-- .../essential-changefeed-sink-to-mysql.md | 2 +- tidb-cloud/features.md | 2 +- tidb-cloud/import-csv-files-serverless.md | 2 +- tidb-cloud/import-csv-files.md | 2 +- tidb-cloud/import-sample-data-serverless.md | 2 +- tidb-cloud/import-sample-data.md | 2 +- tidb-cloud/integrate-tidbcloud-with-n8n.md | 2 +- tidb-cloud/manage-projects-and-resources.md | 2 +- .../migrate-from-mysql-using-aws-dms.md | 2 +- ...migrate-from-mysql-using-data-migration.md | 2 +- tidb-cloud/migrate-from-op-tidb.md | 2 +- tidb-cloud/monitoring-concepts.md | 2 +- .../naming-conventions-for-data-import.md | 2 +- .../dual-layer-data-encryption-premium.md | 2 +- .../premium/import-csv-files-premium.md | 2 +- .../premium/migrate-from-op-tidb-premium.md | 2 +- ...on-2023-11-14-scale-feature-maintenance.md | 2 +- tidb-cloud/releases/release-notes-2022.md | 4 +-- tidb-cloud/releases/release-notes-2023.md | 6 ++-- tidb-cloud/releases/release-notes-2025.md | 8 ++--- .../releases/tidb-cloud-release-notes.md | 2 +- tidb-cloud/releases/tidb-x-cloud.202510.1.md | 2 +- tidb-cloud/serverless-faqs.md | 2 +- tidb-cloud/size-your-cluster.md | 4 +-- tidb-cloud/tidb-cloud-auditing.md | 2 +- ...b-cloud-dm-precheck-and-troubleshooting.md | 2 +- tidb-cloud/tidb-cloud-faq.md | 4 +-- ...troubleshoot-import-access-denied-error.md | 4 +-- tidb-configuration-file.md | 6 ++-- tidb-lightning/data-import-best-practices.md | 6 ++-- tidb-lightning/tidb-lightning-checkpoints.md | 4 +-- .../tidb-lightning-command-line-full.md | 8 ++--- .../tidb-lightning-configuration.md | 18 +++++----- .../tidb-lightning-distributed-import.md | 4 +-- tidb-lightning/tidb-lightning-faq.md | 4 +-- tidb-lightning/tidb-lightning-glossary.md | 6 ++-- .../tidb-lightning-physical-import-mode.md | 6 ++-- tidb-lightning/troubleshoot-tidb-lightning.md | 8 ++--- tidb-resource-control-runaway-queries.md | 2 +- tidb-scheduling.md | 4 +-- tidb-troubleshooting-map.md | 6 ++-- tiflash/tiflash-mintso-scheduler.md | 2 +- tiflash/use-tidb-to-read-tiflash.md | 8 ++--- tikv-configuration-file.md | 10 +++--- tikv-control.md | 4 +-- tikv-overview.md | 2 +- tiproxy/tiproxy-configuration.md | 2 +- tiup/tiup-cluster-topology-reference.md | 8 ++--- tiup/tiup-command-clean.md | 2 +- tiup/tiup-command-env.md | 6 ++-- tiup/tiup-command-mirror-genkey.md | 2 +- tiup/tiup-command-mirror-merge.md | 2 +- tiup/tiup-command-mirror.md | 2 +- tiup/tiup-command-status.md | 2 +- tiup/tiup-command-telemetry.md | 2 +- tiup/tiup-component-cluster-check.md | 2 +- tiup/tiup-component-cluster-display.md | 2 +- tiup/tiup-component-cluster-import.md | 2 +- tiup/tiup-component-cluster-meta-restore.md | 2 +- tiup/tiup-component-cluster-prune.md | 2 +- tiup/tiup-component-cluster-stop.md | 2 +- tiup/tiup-component-dm-import.md | 2 +- tiup/tiup-component-dm-list.md | 2 +- tiup/tiup-component-dm-prune.md | 2 +- tiup/tiup-component-dm-reload.md | 2 +- tiup/tiup-dm-topology-reference.md | 34 +++++++++---------- tiup/tiup-mirror.md | 2 +- tiup/tiup-overview.md | 2 +- troubleshoot-lock-conflicts.md | 16 ++++----- two-data-centers-in-one-city-deployment.md | 4 +-- upgrade-tidb-using-tiup.md | 10 +++--- user-account-management.md | 2 +- 256 files changed, 482 insertions(+), 482 deletions(-) diff --git a/ai/examples/memory-with-pytidb.md b/ai/examples/memory-with-pytidb.md index e983f5ae5c1d7..b04a73a5d968b 100644 --- a/ai/examples/memory-with-pytidb.md +++ b/ai/examples/memory-with-pytidb.md @@ -94,7 +94,7 @@ python main.py 1. デフォルトのチャットセッションで自己紹介をしてください。例えば、「こんにちは、ジョンです。ソフトウェアエンジニアとして働いていて、ギターが大好きです。」など。 2. 入力された情報はメモリビューアで確認できます。 3. 新しいチャットセッションを開始するには、サイドバーの**New chat**をクリックしてください。 -4. 新しいチャットセッションで「私は誰ですか？」と質問してください。AIが過去の会話からあなたの情報を記憶します。 +4. 新しいチャットセッションで"Who am I?"と質問してください。AIが過去の会話からあなたの情報を記憶します。 ## コマンドラインアプリケーションでメモリを操作する {#interact-with-memory-in-command-line-application} @@ -116,7 +116,7 @@ Goodbye! 最初の会話の後、AIアシスタントはあなたが提供した情報を記憶し、今後の質問に答える際にそれを使用します。 -これで、新しいチャットセッションを開始して、AIアシスタントに「私は誰ですか？」と尋ねることができます。 +これで、新しいチャットセッションを開始して、AIアシスタントに"Who am I?"と尋ねることができます。 **別のチャットセッションでの会話例：** diff --git a/ai/guides/filtering.md b/ai/guides/filtering.md index 864ae462165a8..1acb047d0318e 100644 --- a/ai/guides/filtering.md +++ b/ai/guides/filtering.md @@ -174,7 +174,7 @@ results = table.query( ).to_list() ``` -**例: JSONフィールド`meta.category`が「tech」に等しいレコードをフィルタリングする** +**例: JSONフィールド`meta.category`が'tech'に等しいレコードをフィルタリングする** ```python results = table.query( diff --git a/ai/guides/tables.md b/ai/guides/tables.md index 29d22012fd14f..dc784160affba 100644 --- a/ai/guides/tables.md +++ b/ai/guides/tables.md @@ -293,7 +293,7 @@ result = table.query( レコードをフィルタリングするには、 `WHERE`句を使用します。 -**例: カテゴリ「データベース」のレコードを10件取得する** +**例: カテゴリ"database"のレコードを10件取得する** ```sql SELECT * FROM items WHERE meta->>'$.category' = 'database' LIMIT 10; diff --git a/ai/integrations/vector-search-integrate-with-amazon-bedrock.md b/ai/integrations/vector-search-integrate-with-amazon-bedrock.md index 10d0aa22f9b4d..cc2645344bc11 100644 --- a/ai/integrations/vector-search-integrate-with-amazon-bedrock.md +++ b/ai/integrations/vector-search-integrate-with-amazon-bedrock.md @@ -261,7 +261,7 @@ def save_entities_with_embedding(session, contents): ### ステップ8．アプリケーションを実行する {#step-8-run-the-application} -1. `demo.py`に、データベースセッションを確立し、埋め込みを TiDB に保存し、例となる質問 (「TiDB とは何ですか？」など) を尋ね、モデルから結果を生成するための以下のコードを追加します。 +1. `demo.py`に、データベースセッションを確立し、埋め込みを TiDB に保存し、例となる質問 ("What is TiDB?"など) を尋ね、モデルから結果を生成するための以下のコードを追加します。 ```python if __name__ == "__main__": diff --git a/ai/vector-search-get-started-using-python.md b/ai/vector-search-get-started-using-python.md index cb0a75c30d68a..d1f415358e047 100644 --- a/ai/vector-search-get-started-using-python.md +++ b/ai/vector-search-get-started-using-python.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/vector-search-get-started-using-python/','/ja/tidb/de # Python を使って TiDB + AI を始めよう {#get-started-with-tidb-ai-via-python} -このチュートリアルでは、**セマンティック検索**機能を提供するシンプルなAIアプリケーションの開発方法を説明します。従来のキーワード検索とは異なり、セマンティック検索はクエリの背後にある意味をインテリジェントに理解し、最も関連性の高い結果を返します。たとえば、「犬」「魚」「木」というタイトルの文書があり、「泳ぐ動物」を検索すると、アプリケーションは「魚」を最も関連性の高い結果として識別します。 +このチュートリアルでは、**セマンティック検索**機能を提供するシンプルなAIアプリケーションの開発方法を説明します。従来のキーワード検索とは異なり、セマンティック検索はクエリの背後にある意味をインテリジェントに理解し、最も関連性の高い結果を返します。たとえば、"dog"、"fish"、"tree"というタイトルの文書があり、"a swimming animal"を検索すると、アプリケーションは"fish"を最も関連性の高い結果として識別します。 このチュートリアルでは、 [TiDB ベクトル検索](/ai/concepts/vector-search-overview.md)、Python、 [TiDB Vector SDK for Python](https://github.com/pingcap/tidb-vector-python) 、および AI モデルを使用して、この AI アプリケーションを開発します。 @@ -167,7 +167,7 @@ vector_store = TiDBVectorClient( ### ステップ6．テキス​​トデータを埋め込み、ベクトルを保存する {#step-6-embed-text-data-and-store-the-vectors} -このステップでは、「dog」、「fish」、「tree」などの単語を含むサンプル文書を準備します。以下のコードは`text_to_embedding()`関数を使用してこれらのテキスト文書をベクトル埋め込みに変換し、ベクトルストアに挿入します。 +このステップでは、"dog"、"fish"、"tree"などの単語を含むサンプル文書を準備します。以下のコードは`text_to_embedding()`関数を使用してこれらのテキスト文書をベクトル埋め込みに変換し、ベクトルストアに挿入します。 ```python documents = [ @@ -201,7 +201,7 @@ vector_store.insert( ### ステップ7．意味検索を実行する {#step-7-perform-semantic-search} -このステップでは、「泳ぐ動物」という単語を検索しますが、既存の文書にはこの単語と直接一致するものはありません。 +このステップでは、"a swimming animal"という単語を検索しますが、既存の文書にはこの単語と直接一致するものはありません。 以下のコードは`text_to_embedding()`関数を再度使用してクエリテキストをベクトル埋め込みに変換し、その埋め込みを使用してクエリを実行して、最も近い上位 3つの一致を見つけます。 diff --git a/alert-rules.md b/alert-rules.md index 9e729fd1edbed..0bf6bea382649 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-3} @@ -886,11 +886,11 @@ TiCDC アラートルールの詳細な説明については、 [TiCDCアラー - 説明： - マシン上には「確立」ステータスの TCP リンクが 50,000 個以上あります。 + マシン上には"establish"ステータスの TCP リンクが 50,000 個以上あります。 - 解決： - - マシンにログインし、 `ss -s`を実行して、現在のシステムで「estab」ステータスにある TCP リンクの数を確認します。 + - マシンにログインし、 `ss -s`を実行して、現在のシステムで"estab"ステータスにある TCP リンクの数を確認します。 - `netstat`を実行して異常なリンクがないか確認します。 #### `NODE_disk_read_latency_more_than_32ms` {#node_disk_read_latency_more_than_32ms} diff --git a/as-of-timestamp.md b/as-of-timestamp.md index 81f9dcd9c5e1b..10c74f552849b 100644 --- a/as-of-timestamp.md +++ b/as-of-timestamp.md @@ -21,7 +21,7 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標 - [`START TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-start-transaction.md) - [`SET TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-set-transaction.md) -正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには「2016-10-08 16:45:26」のように秒単位で十分です。`NOW(3)`関数を使用して、現在時刻をミリ秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。 +正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには"2016-10-08 16:45:26"のように秒単位で十分です。`NOW(3)`関数を使用して、現在時刻をミリ秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。 時間範囲を指定する場合は、句内で[`TIDB_BOUNDED_STALENESS()`](/functions-and-operators/tidb-functions.md#tidb_bounded_staleness)関数を使用できます。この関数を使用すると、TiDB は指定された時間範囲内で適切なタイムスタンプを選択します。「適切」とは、このタイムスタンプより前に開始され、アクセス先のレプリカにコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセス先のレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされていないことを意味します。この関数を呼び出すには`TIDB_BOUNDED_STALENESS(t1, t2)`を使用する必要があります。`t1`と`t2`は範囲の両端であり、datetime 値または時間関数を使用して指定できます。 diff --git a/benchmark/benchmark-sysbench-v3.md b/benchmark/benchmark-sysbench-v3.md index 162abfdd6ed47..136ddc0808962 100644 --- a/benchmark/benchmark-sysbench-v3.md +++ b/benchmark/benchmark-sysbench-v3.md @@ -1,6 +1,6 @@ --- title: TiDB Sysbench Performance Test Report -- v2.1 vs. v2.0 -summary: TiDB 2.1は「Point Select」テストにおいてTiDB 2.0を上回り、クエリパフォーマンスが50%向上しました。ただし、「Update Non-Index」テストと「Update Index」テストでは、両バージョンのパフォーマンスはほぼ同等でした。このテストは、2018年9月に中国北京で、特定のテスト環境と構成を使用して実施されました。 +summary: TiDB 2.1は`Point Select`テストにおいてTiDB 2.0を上回り、クエリパフォーマンスが50%向上しました。ただし、`Update Non-Index`テストと`Update Index`テストでは、両バージョンのパフォーマンスはほぼ同等でした。このテストは、2018年9月に中国北京で、特定のテスト環境と構成を使用して実施されました。 --- # TiDB Sysbench パフォーマンス テスト レポート - v2.1 と v2.0 の比較 {#tidb-sysbench-performance-test-report-v2-1-vs-v2-0} diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 33835ea825f29..0a4cb5b647c50 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -75,7 +75,7 @@ report-interval=10 db-driver=mysql ``` -上記のパラメータは、実際のニーズに合わせて調整できます。`TIDB_HOST`はTiDBサーバーのIPアドレス（設定ファイルに複数のアドレスを含めることはできないため）、 `threads`はテストにおける同時接続数で、「8、16、32、64、128、256」の範囲で調整できます。データをインポートする際は、threads = 8または16に設定することをお勧めします`threads`を調整したら、 **config**というファイルを保存します。 +上記のパラメータは、実際のニーズに合わせて調整できます。`TIDB_HOST`はTiDBサーバーのIPアドレス（設定ファイルに複数のアドレスを含めることはできないため）、 `threads`はテストにおける同時接続数で、"8, 16, 32, 64, 128, 256"の範囲で調整できます。データをインポートする際は、threads = 8または16に設定することをお勧めします`threads`を調整したら、 **config**というファイルを保存します。 サンプル**設定**ファイルとして以下を参照してください。 diff --git a/benchmark/benchmark-tpch.md b/benchmark/benchmark-tpch.md index 764179eba1597..7b5aca6da939a 100644 --- a/benchmark/benchmark-tpch.md +++ b/benchmark/benchmark-tpch.md @@ -103,6 +103,6 @@ TiDB 2.0: 以下の点に注意してください。 - 上の図では、オレンジ色のバーはリリース1.0のクエリ結果、青色のバーはリリース2.0のクエリ結果を表しています。Y軸はクエリの処理時間（秒）を表しており、短いほど高速です。 -- クエリ15は、現在TiDB 1.0でも2.0でもVIEWがサポートされていないため、「NaN」タグが付けられています。今後のリリースでVIEWのサポートを提供する予定です。 -- TiDB 1.0 列のクエリ 2、17、および 19 には、TiDB 1.0 がこれらのクエリの結果を返さなかったため、「NaN」タグが付けられています。 -- TiDB 1.0 列のクエリ 5、7、18、および 21 には、メモリ消費量が高すぎるため、「OOM」タグが付けられています。 +- クエリ15は、現在TiDB 1.0でも2.0でもVIEWがサポートされていないため、"NaN"タグが付けられています。今後のリリースでVIEWのサポートを提供する予定です。 +- TiDB 1.0 列のクエリ 2、17、および 19 には、TiDB 1.0 がこれらのクエリの結果を返さなかったため、"NaN"タグが付けられています。 +- TiDB 1.0 列のクエリ 5、7、18、および 21 には、メモリ消費量が高すぎるため、"OOM"タグが付けられています。 diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index dab6d85a1645e..9bff4eee0b60b 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -22,11 +22,11 @@ TiDBはオンラインDDLをサポートしています。つまり、データ - **論理 DDL文**: 論理 DDL文は通常、テーブル名の変更や列名の変更など、オブジェクトに格納されているデータを処理せずに、データベースオブジェクトのメタデータのみを変更します。 - TiDBでは、論理DDL文は「汎用DDL」とも呼ばれます。これらの文は通常、実行時間が短く、完了までに数十ミリ秒または数秒しかかからないことがよくあります。そのため、システムリソースをあまり消費せず、アプリケーションのワークロードにも影響を与えません。 + TiDBでは、論理DDL文は"general DDL"とも呼ばれます。これらの文は通常、実行時間が短く、完了までに数十ミリ秒または数秒しかかからないことがよくあります。そのため、システムリソースをあまり消費せず、アプリケーションのワークロードにも影響を与えません。 - **物理DDL文**：物理DDL文は、変更対象となるオブジェクトのメタデータを変更するだけでなく、オブジェクトに格納されているユーザーデータも変更します。例えば、TiDBがテーブルのインデックスを作成する場合、テーブルの定義を変更するだけでなく、新しく追加されたインデックスを構築するためにテーブル全体のスキャンを実行します。 - TiDBでは、物理DDL文は「reorg DDL」（再編成）とも呼ばれます。現在、物理DDL文には、 `ADD INDEX`と損失のある列型変更（例えば、 `INT`型から`CHAR`型への変更）のみが含まれます。これらの文の実行には時間がかかり、実行時間はテーブル内のデータ量、マシン構成、アプリケーションのワークロードによって影響を受けます。 + TiDBでは、物理DDL文は"reorg DDL"（再編成）とも呼ばれます。現在、物理DDL文には、 `ADD INDEX`と損失のある列型変更（例えば、 `INT`型から`CHAR`型への変更）のみが含まれます。これらの文の実行には時間がかかり、実行時間はテーブル内のデータ量、マシン構成、アプリケーションのワークロードによって影響を受けます。 物理DDL文の実行は、2つの理由からアプリケーションのワークロードに影響を与える可能性があります。1つは、データの読み取りと新規データの書き込みにTiKVのCPUリソースとI/Oリソースを消費することです。もう1つは、 **DDLオーナーとして機能するTiDBノード**、または**TiDB分散実行フレームワーク（DXF）によって`ADD INDEX`タスクを実行するようにスケジュールされたTiDBノードが、**対応する計算を実行するためにTiDBのCPUリソースを消費することです。 @@ -63,7 +63,7 @@ ADMIN SHOW DDL; TiDB DDL モジュールは設計当初からオンライン非同期変更モードを選択しており、これによりダウンタイムを経験することなくアプリケーションを変更できます。 -DDL変更は、ある状態から別の状態への遷移を伴い、通常は「変更前」の状態から「変更後」の状態へと遷移します。オンラインDDL変更では、この遷移は、相互に互換性のある複数の小さなバージョン状態を導入することによって発生します。DDL文の実行中、同じクラスタ内のTiDBノードは、変更オブジェクトの小さなバージョン間の差異が2バージョン以内であれば、異なる小さなバージョン変更を持つことができます。これは、隣接する小さなバージョンが相互に互換性を持つことができるためです。 +DDL変更は、ある状態から別の状態への遷移を伴い、通常は"before change"の状態から"after change"の状態へと遷移します。オンラインDDL変更では、この遷移は、相互に互換性のある複数の小さなバージョン状態を導入することによって発生します。DDL文の実行中、同じクラスタ内のTiDBノードは、変更オブジェクトの小さなバージョン間の差異が2バージョン以内であれば、異なる小さなバージョン変更を持つことができます。これは、隣接する小さなバージョンが相互に互換性を持つことができるためです。 このように、複数の小さなバージョンを経ることで、複数のTiDBノード間でメタデータが正しく同期されます。これにより、プロセス中にデータの変更を伴うユーザートランザクションの正確性と一貫性が維持されます。 diff --git a/best-practices/haproxy-best-practices.md b/best-practices/haproxy-best-practices.md index 8516460335929..934de422b9189 100644 --- a/best-practices/haproxy-best-practices.md +++ b/best-practices/haproxy-best-practices.md @@ -132,7 +132,7 @@ haproxy --help | `-D` | デーモンとして起動します。 | | `-C ` | 設定ファイルを読み込む前にディレクトリ``に変更します。 | | `-W` | マスターワーカーモード。 | -| `-q` | 「quiet」モードを設定します。これにより、構成の解析中および起動中に一部のメッセージが無効になります。 | +| `-q` | "quiet"モードを設定します。これにより、構成の解析中および起動中に一部のメッセージが無効になります。 | | `-c` | バインドを試みる前に、構成ファイルのチェックのみを実行して終了します。 | | `-n ` | プロセスごとの接続制限を``に制限します。 | | `-m ` | すべてのプロセスにわたって割り当て可能なメモリのメモリを``メガバイトに制限します。 | @@ -145,8 +145,8 @@ haproxy --help | `-dR` | SO_REUSEPORT の使用を無効にします。 | | `-dr` | サーバーのアドレス解決の失敗を無視します。 | | `-dV` | サーバー側での SSL 検証を無効にします。 | -| `-sf ` | 起動後、pidlist で指定されたPIDに「finish」シグナルを送信します。このシグナルを受信したプロセスは、すべてのセッションが終了するまで待機してから終了します。このオプションは最後に指定する必要があり、その後に任意の数のPIDが続きます。厳密には、SIGTTOUとSIGUSR1が送信されます。 | -| `-st ` | 起動後、pidlist で指定されたPIDに「terminate」シグナルを送信します。このシグナルを受信したプロセスは即座に終了し、すべてのアクティブなセッションが閉じられます。このオプションは最後に指定する必要があり、その後に任意の数のPIDが続きます。厳密に言えば、SIGTTOUとSIGTERMが送信されます。 | +| `-sf ` | 起動後、pidlist で指定されたPIDに"finish"シグナルを送信します。このシグナルを受信したプロセスは、すべてのセッションが終了するまで待機してから終了します。このオプションは最後に指定する必要があり、その後に任意の数のPIDが続きます。厳密には、SIGTTOUとSIGUSR1が送信されます。 | +| `-st ` | 起動後、pidlist で指定されたPIDに"terminate"シグナルを送信します。このシグナルを受信したプロセスは即座に終了し、すべてのアクティブなセッションが閉じられます。このオプションは最後に指定する必要があり、その後に任意の数のPIDが続きます。厳密に言えば、SIGTTOUとSIGTERMが送信されます。 | | `-x ` | 指定されたソケットに接続し、古いプロセスからすべてのリスニングソケットを取得します。その後、新しいソケットをバインドする代わりに、これらのソケットを使用します。 | | `-S [,...]` | マスターワーカーモードでは、マスターCLIを作成します。このCLIは、すべてのワーカーのCLIへのアクセスを可能にします。デバッグに役立ち、離脱中のプロセスにアクセスする便利な方法です。 | diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index cb3c0d19e2af5..28ecc2cf58076 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -129,7 +129,7 @@ TiDBオプティマイザには、強力な範囲導出コンポーネントが ## 複数列インデックスの分離条件（ `OR`条件） {#disjunctive-conditions-or-conditions-in-multi-column-indexes} -クエリに`OR`条件（「分離述語」と呼ばれる）がある場合、オプティマイザは各条件を個別に処理し、 `OR`条件の各部分について範囲を作成します。これらの範囲が重複している場合、オプティマイザはそれらを1つの連続した範囲に結合します。重複していない場合は、それぞれ別々の範囲として保持され、どちらもインデックススキャンに使用できます。 +クエリに`OR`条件（"disjunctive predicates"と呼ばれる）がある場合、オプティマイザは各条件を個別に処理し、 `OR`条件の各部分について範囲を作成します。これらの範囲が重複している場合、オプティマイザはそれらを1つの連続した範囲に結合します。重複していない場合は、それぞれ別々の範囲として保持され、どちらもインデックススキャンに使用できます。 ### 例1: 重複する範囲 {#example-1-overlapping-ranges} diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index b315baa8b453f..002f6b3951fed 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -57,7 +57,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ 2. `OperatorController`キューからオペレーターを取り出し、設定に基づいて一定の同時実行数で実行します。このステップでは、各オペレーターステップを対応するリージョンリーダーに割り当てます。 - 3. オペレーターは「終了」または「タイムアウト」としてマークされ、キューから削除されます。 + 3. オペレーターは"finish"または"timeout"としてマークされ、キューから削除されます。 ### 負荷分散 {#load-balancing} @@ -74,7 +74,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ - ストレージが不足している場合は、使用可能なストレージに基づいて割り当てます (異なるノード上のストレージの可用性のバランスをとるため)。 - どちらの状況も当てはまらない場合は、上記の2つの要素の加重合計に基づきます。 -ノードによってパフォーマンスが異なる場合があるため、ストアごとにロードバランシングの重みを設定することもできます。`leader-weight`と`region-weight`は、それぞれリーダー重みとリージョン重みを制御します（どちらもデフォルトは「1」です）。例えば、あるストアの`leader-weight`を「2」に設定すると、スケジューリングが安定した後、そのノードのリーダー数は他のノードの約2倍になります。同様に、あるストアの`leader-weight`を「0.5」に設定すると、そのノードのリーダー数は他のノードの約半分になります。 +ノードによってパフォーマンスが異なる場合があるため、ストアごとにロードバランシングの重みを設定することもできます。`leader-weight`と`region-weight`は、それぞれリーダー重みとリージョン重みを制御します（どちらもデフォルトは"1"です）。例えば、あるストアの`leader-weight`を"2"に設定すると、スケジューリングが安定した後、そのノードのリーダー数は他のノードの約2倍になります。同様に、あるストアの`leader-weight`を"0.5"に設定すると、そのノードのリーダー数は他のノードの約半分になります。 ### ホットリージョンのスケジュール {#hot-regions-scheduling} @@ -94,7 +94,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ ### スケールインと障害回復 {#scale-in-and-failure-recovery} -スケールインとは、コマンドを使用してストアをオフラインにし、「オフライン」としてマークするプロセスを指します。PDは、オフラインノード上のリージョンをスケジュールに従って他のノードに複製します。障害復旧は、ストアに障害が発生し、復旧できない場合に適用されます。この場合、対応するストアに分散されたピアを持つリージョンのレプリカが失われる可能性があり、PDは他のノードでレプリカを補充する必要があります。 +スケールインとは、コマンドを使用してストアをオフラインにし、"offline"としてマークするプロセスを指します。PDは、オフラインノード上のリージョンをスケジュールに従って他のノードに複製します。障害復旧は、ストアに障害が発生し、復旧できない場合に適用されます。この場合、対応するストアに分散されたピアを持つリージョンのレプリカが失われる可能性があり、PDは他のノードでレプリカを補充する必要があります。 スケールインと障害回復のプロセスは基本的に同じです。`replicaChecker`は異常な状態にあるリージョン ピアを見つけ、異常なピアを正常なストア上の新しいピアに置き換えるオペレーターを生成します。 @@ -219,7 +219,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー - PDは対応するバランシングスケジューラを生成できません。考えられる原因は次のとおりです。 - - スケジューラが有効化されていません。例えば、対応するスケジューラが削除されているか、制限が「​​0」に設定されている可能性があります。 + - スケジューラが有効化されていません。例えば、対応するスケジューラが削除されているか、制限が"0"に設定されている可能性があります。 - その他の制約。例えば、システム内の制約`evict-leader-scheduler`により、リーダーが対応するストアに移行できない、あるいはラベルプロパティが設定されているため、一部のストアがリーダーを拒否するといった状況です。 - クラスタトポロジによる制約。例えば、3つのデータセンターにまたがる3つのレプリカを持つクラスタでは、レプリカ分離のため、各リージョンの3つのレプリカが異なるデータセンターに分散されます。これらのデータセンター間でストア数が異なる場合、スケジューリングは各データセンター内ではバランスの取れた状態になりますが、グローバルではバランスが取れません。 diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md index 50097472545f1..ea37635dfa6b6 100644 --- a/br/br-auto-tune.md +++ b/br/br-auto-tune.md @@ -39,7 +39,7 @@ tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v 自動調整機能には、次の問題と対応する解決策があります。 -- 問題1：**書き込み負荷の高いクラスタ**では、自動チューニングによってワークロードとバックアップタスクが「正のフィードバックループ」に陥る可能性があります。つまり、バックアップタスクが過剰なリソースを消費し、クラスタが使用するリソースが少なくなるのです。この時点で、自動チューニングはクラスタのワークロードがそれほど高くないと誤って判断し、バックアップの実行速度を速めてしまう可能性があります。このような場合、自動チューニングは効果を発揮しません。 +- 問題1：**書き込み負荷の高いクラスタ**では、自動チューニングによってワークロードとバックアップタスクが"positive feedback loop"に陥る可能性があります。つまり、バックアップタスクが過剰なリソースを消費し、クラスタが使用するリソースが少なくなるのです。この時点で、自動チューニングはクラスタのワークロードがそれほど高くないと誤って判断し、バックアップの実行速度を速めてしまう可能性があります。このような場合、自動チューニングは効果を発揮しません。 - 解決策：バックアップタスクで使用されるスレッド数を制限したい場合は、手動で`backup.num-threads`小さい数値に調整してください。動作原理は以下のとおりです。 diff --git a/choose-index.md b/choose-index.md index 0ac29b5bad42f..3eff8c0801a9a 100644 --- a/choose-index.md +++ b/choose-index.md @@ -46,7 +46,7 @@ TiDBは、インデックスを選択するために以下のヒューリステ - ルール4：ルール2とルール3に基づいて候補インデックスが1つだけ選択された場合は、その候補インデックスを選択します。ルール2とルール3に基づいてそれぞれ2つの候補インデックスが選択された場合は、読み込む行数が少ない方のインデックスを選択します（インデックスを持つ行数＋テーブルから取得する行数）。 -上記のルールにおける「完全一致のインデックス」とは、インデックス付けされた各列が等しい条件を満たすことを意味します。 `EXPLAIN FORMAT = 'verbose' ...`ステートメントを実行する際に、事前ルールがインデックスに一致する場合、TiDB はインデックスが事前ルールに一致することを示す NOTE レベルの警告を出力します。 +上記のルールにおける"index with full match"とは、インデックス付けされた各列が等しい条件を満たすことを意味します。 `EXPLAIN FORMAT = 'verbose' ...`ステートメントを実行する際に、事前ルールがインデックスに一致する場合、TiDB はインデックスが事前ルールに一致することを示す NOTE レベルの警告を出力します。 次の例では、インデックス`idx_b`ルール 2 の条件「完全一致の一意インデックス + テーブルから行を取得する必要性」を満たしているため、TiDB はインデックス`idx_b`をアクセス パスとして選択し、 `SHOW WARNING`インデックス`idx_b`が事前ルールに一致することを示すメモを返します。 @@ -75,7 +75,7 @@ mysql> SHOW WARNINGS; スカイライン剪定は、インデックスに対するヒューリスティックなフィルタリングルールであり、誤った推定によるインデックス選択の誤りの可能性を低減できます。インデックスを評価するには、以下の次元が必要です。 -- インデックス付き列によってカバーされるアクセス条件の数はいくつでしょうか。「アクセス条件」とは、列範囲に変換できるWHERE句の条件のことです。インデックス付き列セットがカバーするアクセス条件が多いほど、この点において優れています。 +- インデックス付き列によってカバーされるアクセス条件の数はいくつでしょうか。"access condition"とは、列範囲に変換できるWHERE句の条件のことです。インデックス付き列セットがカバーするアクセス条件が多いほど、この点において優れています。 - テーブルにアクセスするためにインデックスを選択した場合に、テーブルから行を取得する必要があるかどうか（つまり、インデックスによって生成されるプランが IndexReader オペレーターまたは IndexLookupReader オペレーターであるかどうか）。テーブルから行を取得しないインデックスは、取得するインデックスよりもこの点で優れています。両方のインデックスが TiDB を使用してテーブルから行を取得する必要がある場合は、インデックス付き列によってカバーされるフィルタリング条件の数を比較します。フィルタリング条件とは、インデックスに基づいて判断できる`where`条件のことです。インデックスの列セットがより多くのアクセス条件をカバーするほど、テーブルから取得される行の数は少なくなり、この点でインデックスの性能が向上します。 diff --git a/clinic/quick-start-with-clinic.md b/clinic/quick-start-with-clinic.md index b4099314726be..48971bff92dbc 100644 --- a/clinic/quick-start-with-clinic.md +++ b/clinic/quick-start-with-clinic.md @@ -143,7 +143,7 @@ PingCAP Clinicを使用する前に、Diag をインストールし、データ 4. ヘルスレポートの結果を表示する - データがアップロードされると、Clinic Server はバックグラウンドで自動的にデータを処理します。ヘルスレポートは約5～15分で生成されます。診断データリンクを開き、「ヘルスレポート」をクリックすると、レポートをご覧いただけます。 + データがアップロードされると、Clinic Server はバックグラウンドで自動的にデータを処理します。ヘルスレポートは約5～15分で生成されます。診断データリンクを開き、"Health Report"をクリックすると、レポートをご覧いただけます。 ## 次は何？ {#what-s-next} diff --git a/column-pruning.md b/column-pruning.md index 0d29caac88aa0..dd267a7bbb99b 100644 --- a/column-pruning.md +++ b/column-pruning.md @@ -15,7 +15,7 @@ select a from t where b> 5 このクエリでは、列aと列bのみが使用され、列cと列dは冗長です。この文のクエリプランでは、 `Selection`の演算子が列bを使用し、 `DataSource`演算子が列aと列bを使用します。`DataSource`演算子は列cと列dを読み取らないため、これらはプルーニング可能です。 -そのため、TiDBはロジック最適化フェーズでトップダウンスキャンを実行する際に、リソースの無駄を削減するために冗長な列をプルーニングします。このスキャン処理は「カラムの剪定」と呼ばれ、ルール`columnPruner`に対応しています。 +そのため、TiDBはロジック最適化フェーズでトップダウンスキャンを実行する際に、リソースの無駄を削減するために冗長な列をプルーニングします。このスキャン処理は"Column Pruning"と呼ばれ、ルール`columnPruner`に対応しています。 diff --git a/command-line-flags-for-pd-configuration.md b/command-line-flags-for-pd-configuration.md index ceedfe9bdc7b4..3709ac4dfb10a 100644 --- a/command-line-flags-for-pd-configuration.md +++ b/command-line-flags-for-pd-configuration.md @@ -48,7 +48,7 @@ PD は、コマンドラインフラグと環境変数を使用して構成で - ブートストラップのための初期クラスタ構成 - デフォルト: `"{name}=http://{advertise-peer-url}"` -- たとえば、 `name`が「pd」、 `advertise-peer-urls`が`"http://192.168.100.113:2380"`の場合、 `initial-cluster`は`"pd=http://192.168.100.113:2380"`なります。 +- たとえば、 `name`が"pd"、 `advertise-peer-urls`が`"http://192.168.100.113:2380"`の場合、 `initial-cluster`は`"pd=http://192.168.100.113:2380"`なります。 - 3 つの PD サーバーを起動する必要がある場合、 `initial-cluster`は次のようになります。 ``` @@ -71,7 +71,7 @@ PD は、コマンドラインフラグと環境変数を使用して構成で - ログファイル - デフォルト: `""` -- このフラグが設定されていない場合、ログは「stderr」に書き込まれます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 +- このフラグが設定されていない場合、ログは"stderr"に書き込まれます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 ## `--log-rotate` {#log-rotate} diff --git a/command-line-flags-for-scheduling-configuration.md b/command-line-flags-for-scheduling-configuration.md index bd1c11a84817c..11060d1e4cb92 100644 --- a/command-line-flags-for-scheduling-configuration.md +++ b/command-line-flags-for-scheduling-configuration.md @@ -55,7 +55,7 @@ summary: スケジュール構成フラグは、コマンドラインフラグ - ログファイル。 - デフォルト: `""` -- このフラグが設定されていない場合、ログは「stderr」に出力されます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 +- このフラグが設定されていない場合、ログは"stderr"に出力されます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 ## `--name` v8.3.0 の新機能 {#name-new-in-v830} diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index 8df403ef8e4ba..a9af5806ed74d 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -71,7 +71,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション - ログファイル - デフォルト: `""` -- このオプションが設定されていない場合、ログは「stderr」に出力されます。このオプションが設定されている場合、ログは対応するファイルに出力されます。 +- このオプションが設定されていない場合、ログは"stderr"に出力されます。このオプションが設定されている場合、ログは対応するファイルに出力されます。 ## `--log-general` {#--log-general} @@ -106,7 +106,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## `--path` {#--path} -- 「unistore」のようなローカルストレージエンジンのデータディレクトリへのパス +- "unistore"のようなローカルストレージエンジンのデータディレクトリへのパス - `--store = tikv`の場合、パスを指定する必要があります。 `--store = unistore`の場合、パスを指定しないとデフォルト値が使用されます。 - TiKVのような分散ストレージエンジンの場合、 `--path`は実際のPDアドレスを指定します。PDサーバーを192.168.100.113:2379、192.168.100.114:2379、192.168.100.115:2379にデプロイすると仮定すると、 `--path`の値は「192.168.100.113:2379、192.168.100.114:2379、192.168.100.115:2379」となります。 - デフォルト: `"/tmp/tidb"` @@ -180,7 +180,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション - 最下層で TiDB が使用するストレージエンジンを指定します - デフォルト: `"unistore"` -- 「unistore」または「tikv」を選択できます。（「unistore」はローカルストレージエンジン、「tikv」は分散ストレージエンジンです） +- "unistore"または"tikv"を選択できます。（"unistore"はローカルストレージエンジン、"tikv"は分散ストレージエンジンです） ## `--temp-dir` {#--temp-dir} diff --git a/command-line-flags-for-tikv-configuration.md b/command-line-flags-for-tikv-configuration.md index 71f3b66f82417..0545dcb2d1019 100644 --- a/command-line-flags-for-tikv-configuration.md +++ b/command-line-flags-for-tikv-configuration.md @@ -89,7 +89,7 @@ TiKV は、コマンドラインパラメータに対していくつかの読み - ログファイル - デフォルト: `""` -- このフラグが設定されていない場合、ログは「stderr」に書き込まれます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 +- このフラグが設定されていない場合、ログは"stderr"に書き込まれます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 ## `--pd` {#--pd} diff --git a/command-line-flags-for-tso-configuration.md b/command-line-flags-for-tso-configuration.md index 6a4ac5cff4fa4..721d4cb98e130 100644 --- a/command-line-flags-for-tso-configuration.md +++ b/command-line-flags-for-tso-configuration.md @@ -55,7 +55,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために - ログファイル。 - デフォルト: `""` -- このフラグが設定されていない場合、ログは「stderr」に出力されます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 +- このフラグが設定されていない場合、ログは"stderr"に出力されます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 ## `--name` v8.3.0 の新機能 {#name-new-in-v830} diff --git a/configure-memory-usage.md b/configure-memory-usage.md index 37ff974a705a4..340715467a167 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -165,7 +165,7 @@ TiDBは、実行演算子のディスクへの書き込みをサポートして [tidb]> explain analyze select /*+ HASH_AGG() */ count(*) from t t1 join t t2 join t t3 group by t1.a, t2.a, t3.a; ``` - この SQL文を実行するとメモリが大量に消費されるため、次の「メモリクォータ不足」エラーメッセージが返されます。 + この SQL文を実行するとメモリが大量に消費されるため、次の`Out Of Memory Quota!`エラーメッセージが返されます。 ```sql ERROR 1105 (HY000): Out Of Memory Quota![conn_id=3] diff --git a/configure-placement-rules.md b/configure-placement-rules.md index 9ed0bae036f70..d2b962f45a249 100644 --- a/configure-placement-rules.md +++ b/configure-placement-rules.md @@ -19,7 +19,7 @@ TiDBバージョン5.0以降では、配置ルール機能はデフォルトで 複数のルールのキー範囲は重複する部分を持つ場合があり、これはリージョンが複数のルールに一致する可能性があることを意味します。この場合、PDはルールの属性に基づいて、ルールが互いに上書きされるか、同時に有効になるかを決定します。複数のルールが同時に有効になる場合、PDはルールマッチングのために、ルールのスタック順序に従って順番にスケジュールを生成します。 -さらに、異なるソースからのルールを互いに分離するという要件を満たすため、これらのルールをより柔軟に整理できます。そのため、「グループ」という概念が導入されました。一般的に、ユーザーは異なるソースに基づいてルールを異なるグループに配置できます。 +さらに、異なるソースからのルールを互いに分離するという要件を満たすため、これらのルールをより柔軟に整理できます。そのため、"Group"という概念が導入されました。一般的に、ユーザーは異なるソースに基づいてルールを異なるグループに配置できます。 ![Placement rules overview](/media/placement-rules-1.png) diff --git a/dashboard/dashboard-access.md b/dashboard/dashboard-access.md index 3c49769047341..6f0275c2bdaee 100644 --- a/dashboard/dashboard-access.md +++ b/dashboard/dashboard-access.md @@ -1,6 +1,6 @@ --- title: Access TiDB Dashboard -summary: TiDB Dashboardにアクセスするには、ブラウザで指定されたURLにアクセスしてください。複数のPDインスタンスの場合は、アドレスを任意のPDインスタンスのアドレスとポートに置き換えてください。Chrome、Firefox、またはEdgeブラウザ（最新バージョン）をご利用ください。TiDBルートアカウントまたはユーザー定義のSQLユーザーでサインインしてください。セッションは24時間有効です。言語は英語と中国語で切り替えられます。ログアウトするには、ユーザー名をクリックし、「ログアウト」ボタンをクリックしてください。 +summary: TiDB Dashboardにアクセスするには、ブラウザで指定されたURLにアクセスしてください。複数のPDインスタンスの場合は、アドレスを任意のPDインスタンスのアドレスとポートに置き換えてください。Chrome、Firefox、またはEdgeブラウザ（最新バージョン）をご利用ください。TiDBルートアカウントまたはユーザー定義のSQLユーザーでサインインしてください。セッションは24時間有効です。言語は英語と中国語で切り替えられます。ログアウトするには、ユーザー名をクリックし、"Logout"ボタンをクリックしてください。 --- # TiDB Dashboardにアクセスする {#access-tidb-dashboard} diff --git a/dashboard/dashboard-cluster-info.md b/dashboard/dashboard-cluster-info.md index 0667ecd83f0b0..c1b887f926f08 100644 --- a/dashboard/dashboard-cluster-info.md +++ b/dashboard/dashboard-cluster-info.md @@ -1,6 +1,6 @@ --- title: TiDB Dashboard Cluster Information Page -summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体のTiDB、TiKV、PD、 TiFlashコンポーネントの稼働状況、およびこれらのコンポーネントが配置されているホストの稼働状況を確認できます。このページにアクセスするには、TiDB Dashboardにログインし、左側のナビゲーションメニューで「クラスタ情報」をクリックするか、ブラウザで特定のURLにアクセスしてください。このページには、インスタンス、ホスト、ディスクのリストが表示され、各コンポーネントの詳細情報と稼働状況が表示されます。 +summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体のTiDB、TiKV、PD、 TiFlashコンポーネントの稼働状況、およびこれらのコンポーネントが配置されているホストの稼働状況を確認できます。このページにアクセスするには、TiDB Dashboardにログインし、左側のナビゲーションメニューでCluster Infoをクリックするか、ブラウザで特定のURLにアクセスしてください。このページには、インスタンス、ホスト、ディスクのリストが表示され、各コンポーネントの詳細情報と稼働状況が表示されます。 --- # TiDB Dashboardのクラスタ情報ページ {#tidb-dashboard-cluster-information-page} @@ -88,4 +88,4 @@ summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体 > **Note:** > -> コンポーネントの種類、パーティション構成、およびデプロイメント方法によっては、一部のホストのディスク情報が**ディスク**リストに表示されない場合があります。その場合、黄色の警告アイコン（⚠️）が表示されます。アイコンにマウスポインターを合わせると、「ホスト情報の取得に失敗しました」というツールヒントが表示されます。これは想定内の動作です。 +> コンポーネントの種類、パーティション構成、およびデプロイメント方法によっては、一部のホストのディスク情報が**ディスク**リストに表示されない場合があります。その場合、黄色の警告アイコン（⚠️）が表示されます。アイコンにマウスポインターを合わせると、"Failed to get host information"というツールヒントが表示されます。これは想定内の動作です。 diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md index 83fcc989403e8..0d19f6274b60b 100644 --- a/dashboard/dashboard-intro.md +++ b/dashboard/dashboard-intro.md @@ -37,13 +37,13 @@ TiDB DashboardのKey Visualizer機能は、クラスター全体の読み取り/ ## すべてのSQL文の実行情報のリストを表示します {#show-a-list-of-execution-information-of-all-sql-statements} -すべてのSQL文の実行情報は、「SQL文」ページに表示されます。このページでは、すべてのステージにおける実行時間と合計実行回数を確認できます。これにより、最もリソースを消費しているSQLクエリを分析して特定し、クラスター全体のパフォーマンスを向上させることができます。 +すべてのSQL文の実行情報は、"SQL Statements"ページに表示されます。このページでは、すべてのステージにおける実行時間と合計実行回数を確認できます。これにより、最もリソースを消費しているSQLクエリを分析して特定し、クラスター全体のパフォーマンスを向上させることができます。 詳細は[TiDB DashboardのSQL Statementsページ](/dashboard/dashboard-statement-list.md)参照。 ## スロークエリの詳細な実行情報を知る {#learn-the-detailed-execution-information-of-slow-queries} -TiDB Dashboardの「スロークエリ」ページには、実行に時間のかかるすべてのSQL文のリスト（SQLテキストと実行情報を含む）が表示されます。このページは、スロークエリやパフォーマンスジッターの原因を特定するのに役立ちます。 +TiDB Dashboardの"Slow Queries"ページには、実行に時間のかかるすべてのSQL文のリスト（SQLテキストと実行情報を含む）が表示されます。このページは、スロークエリやパフォーマンスジッターの原因を特定するのに役立ちます。 詳細は[スロークエリページ](/dashboard/dashboard-slow-query.md)を参照。 diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md index c204902919c7b..b6cce828e086e 100644 --- a/dashboard/dashboard-ops-deploy.md +++ b/dashboard/dashboard-ops-deploy.md @@ -1,6 +1,6 @@ --- title: Deploy TiDB Dashboard -summary: TiDB Dashboardは、v4.0以降のPDに組み込まれています。追加のデプロイメントは不要です。Kubernetes上に独立してデプロイすることも可能です。複数のPDインスタンスがデプロイされている場合、ダッシュボードとして機能するのは1つだけです。「tiup cluster display」コマンドを使用して、ダッシュボードの機能を確認してください。ダッシュボードの無効化と有効化は「tiup ctl」コマンドを使用して行うことができます。 +summary: TiDB Dashboardは、v4.0以降のPDに組み込まれています。追加のデプロイメントは不要です。Kubernetes上に独立してデプロイすることも可能です。複数のPDインスタンスがデプロイされている場合、ダッシュボードとして機能するのは1つだけです。`tiup cluster display`コマンドを使用して、ダッシュボードの機能を確認してください。ダッシュボードの無効化と有効化は`tiup ctl`コマンドを使用して行うことができます。 --- # TiDB Dashboardをデプロイ {#deploy-tidb-dashboard} diff --git a/dashboard/dashboard-session-sso.md b/dashboard/dashboard-session-sso.md index d5d5c924dd0f2..270395e1e38c7 100644 --- a/dashboard/dashboard-session-sso.md +++ b/dashboard/dashboard-session-sso.md @@ -1,6 +1,6 @@ --- title: Configure SSO for TiDB Dashboard -summary: TiDB Dashboardは、サインイン認証にOIDCベースのSSOをサポートしています。SSOを有効にするには、OIDCクライアントIDと検出URLを入力し、偽装を承認して設定を保存します。SSOを無効にするには、オプションの選択を解除して設定を更新します。SQLユーザーのパスワードが変更された場合は、パスワードを再入力してSSOを再度有効にしてください。設定後、「会社アカウントでサインイン」をクリックしてサインインプロセスを完了することで、SSO経由でサインインできます。Okta、Auth0、Casdoorを使用したSSO設定の例も提供されています。 +summary: TiDB Dashboardは、サインイン認証にOIDCベースのSSOをサポートしています。SSOを有効にするには、OIDCクライアントIDと検出URLを入力し、偽装を承認して設定を保存します。SSOを無効にするには、オプションの選択を解除して設定を更新します。SQLユーザーのパスワードが変更された場合は、パスワードを再入力してSSOを再度有効にしてください。設定後、"Sign in via Company Account"をクリックしてサインインプロセスを完了することで、SSO経由でサインインできます。Okta、Auth0、Casdoorを使用したSSO設定の例も提供されています。 --- # TiDB DashboardのSSOを構成する {#configure-sso-for-tidb-dashboard} @@ -168,7 +168,7 @@ Oktaと同様に、 [オーソ0](https://auth0.com/)もOIDC SSOアイデンテ ![Create Application](/media/dashboard/dashboard-session-sso-auth0-create-app.png) - ポップアップダイアログで、**Name**を入力します（例：「TiDB Dashboard」）。**Choose an application type**で**Single Page Web Applications**を選択します。 **Create**をクリックします。 + ポップアップダイアログで、**Name**を入力します（例："TiDB Dashboard"）。**Choose an application type**で**Single Page Web Applications**を選択します。 **Create**をクリックします。 4. **Settings**をクリックします。 diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md index ef225b5e95575..167b1341a4c35 100644 --- a/data-type-date-and-time.md +++ b/data-type-date-and-time.md @@ -11,7 +11,7 @@ TiDBは、時間値を格納するためにMySQLのすべての日付と時刻 日付と時刻の値の型を扱うときは、次の点に注意してください。 -- TiDB はさまざまな形式を解釈しようとしますが、日付部分は月-日-年や日-月-年ではなく、年-月-日 (たとえば、「1998-09-04」) の形式である必要があります。 +- TiDB はさまざまな形式を解釈しようとしますが、日付部分は月-日-年や日-月-年ではなく、年-月-日 (たとえば、'1998-09-04') の形式である必要があります。 - 日付の年の部分が 2 桁で指定されている場合、TiDB はそれを[特定のルール](#two-digit-year-portion-contained-in-the-date)に基づいて変換します。 @@ -65,9 +65,9 @@ TiDBは、時間値を格納するためにMySQLのすべての日付と時刻 - 異なる SQL モードを設定すると、TiDB の動作が変わる場合があります。 -- SQLモード`NO_ZERO_DATE`が有効になっていない場合、TiDBは列`DATE`と`DATETIME`の月または日にゼロ値（例：「2009-00-00」または「2009-01-00」）を許可します。この日付型を関数（例：列`DATE_SUB()`または`DATE_ADD()` ）で計算する場合、結果が不正確になる可能性があります。 +- SQLモード`NO_ZERO_DATE`が有効になっていない場合、TiDBは列`DATE`と`DATETIME`の月または日にゼロ値（例：'2009-00-00'または'2009-01-00'）を許可します。この日付型を関数（例：列`DATE_SUB()`または`DATE_ADD()` ）で計算する場合、結果が不正確になる可能性があります。 -- デフォルトでは、TiDBはSQLモード`NO_ZERO_DATE`を有効にします。このモードでは、「0000-00-00」などのゼロ値が保存されるのを防ぎます。 +- デフォルトでは、TiDBはSQLモード`NO_ZERO_DATE`を有効にします。このモードでは、'0000-00-00'などのゼロ値が保存されるのを防ぎます。 さまざまな種類のゼロ値を次の表に示します。 @@ -79,13 +79,13 @@ TiDBは、時間値を格納するためにMySQLのすべての日付と時刻 | TIMESTAMP | '0000-00-00 00:00:00' | | YEAR | 0000 | -無効な`DATE` 、 `DATETIME` 、 `TIMESTAMP`値は、SQL モードで許可されている場合、対応するタイプのゼロ値 (「0000-00-00」または「0000-00-00 00:00:00」) に自動的に変換されます。 +無効な`DATE` 、 `DATETIME` 、 `TIMESTAMP`値は、SQL モードで許可されている場合、対応するタイプのゼロ値 ('0000-00-00'または'0000-00-00 00:00:00') に自動的に変換されます。 ## サポートされているタイプ {#supported-types} ### `DATE`型 {#date-type} -`DATE`は日付部分のみを含み、時刻部分は含みません`YYYY-MM-DD`形式で表示されます。サポートされる範囲は「0000-01-01」から「9999-12-31」です。 +`DATE`は日付部分のみを含み、時刻部分は含みません`YYYY-MM-DD`形式で表示されます。サポートされる範囲は'0000-01-01'から'9999-12-31'です。 ```sql DATE @@ -101,7 +101,7 @@ TIME[(fsp)] > **Note:** > -> `TIME`の省略形に注意してください。例えば、「11:12」は「00:11:12」ではなく「11:12:00」を意味します。一方、「1112」は「00:11:12」を意味します。これらの違いは、 `:`文字の有無によって生じます。 +> `TIME`の省略形に注意してください。例えば、'11:12'は'00:11:12'ではなく'11:12:00'を意味します。一方、'1112'は'00:11:12'を意味します。これらの違いは、 `:`文字の有無によって生じます。 ### `DATETIME`型 {#datetime-type} @@ -117,7 +117,7 @@ DATETIME[(fsp)] `TIMESTAMP`日付部分と時刻部分の両方を含みます。有効な値の範囲は、UTC時間で「1970-01-01 00:00:01.000000」から「2038-01-19 03:14:07.999999」までです。オプションで0から6の範囲のfsp値を指定して、小数秒の精度を指定できます。省略した場合、デフォルトの精度は0です。 -`TIMESTAMP`では、月部分または日部分にゼロを含めることはできません。唯一の例外は、ゼロ値自体（「0000-00-00 00:00:00」）です。 +`TIMESTAMP`では、月部分または日部分にゼロを含めることはできません。唯一の例外は、ゼロ値自体（'0000-00-00 00:00:00'）です。 ```sql TIMESTAMP[(fsp)] @@ -133,7 +133,7 @@ TIMESTAMP[(fsp)] ### `YEAR`型 {#year-type} -`YEAR`型は「YYYY」形式で指定します。サポートされる値の範囲は1901から2155まで、または0000です。 +`YEAR`型は'YYYY'形式で指定します。サポートされる値の範囲は1901から2155まで、または0000です。 ```sql YEAR[(4)] @@ -142,10 +142,10 @@ YEAR[(4)] `YEAR`は次の形式規則に従います。 - 4桁の数字の範囲は1901年から2155年までです -- 4桁の文字列の範囲は「1901」から「2155」までです +- 4桁の文字列の範囲は'1901'から'2155'までです - 1桁または2桁の数字の範囲は1から99です。したがって、1〜69は2001〜2069に変換され、70〜99は1970〜1999に変換されます。 -- 1桁または2桁の文字列の範囲は「0」から「99」までです -- 値0は0000として扱われ、文字列「0」または「00」は2000として扱われます。 +- 1桁または2桁の文字列の範囲は'0'から'99'までです +- 値0は0000として扱われ、文字列'0'または'00'は2000として扱われます。 無効な値`YEAR`は自動的に 0000 に変換されます (ユーザーが`NO_ZERO_DATE` SQL モードを使用していない場合)。 @@ -208,16 +208,16 @@ CREATE TABLE t1 ( ## 日付と時刻の型間の変換 {#conversions-between-date-and-time-types} -日付型と時刻型の間で変換が必要になる場合があります。しかし、変換によっては情報が失われる可能性があります。例えば、 `DATE` 、 `DATETIME` 、 `TIMESTAMP`という値はそれぞれ独自の範囲を持ちます。 `TIMESTAMP`はUTC時間で1970年より前、またはUTC時間「2038-01-19 03:14:07」より後であってはなりません。このルールに基づくと、「1968-01-01」は有効な日付値である`DATE`または`DATETIME`ですが、 `TIMESTAMP`に変換すると 0 になります。 +日付型と時刻型の間で変換が必要になる場合があります。しかし、変換によっては情報が失われる可能性があります。例えば、 `DATE` 、 `DATETIME` 、 `TIMESTAMP`という値はそれぞれ独自の範囲を持ちます。 `TIMESTAMP`はUTC時間で1970年より前、またはUTC時間'2038-01-19 03:14:07'より後であってはなりません。このルールに基づくと、'1968-01-01'は有効な日付値である`DATE`または`DATETIME`ですが、 `TIMESTAMP`に変換すると 0 になります。 `DATE`の変換: -- `DATE`を`DATETIME`または`TIMESTAMP`に変換すると、DATEには時間情報が含まれていないため、時間部分「00:00:00」が追加されます。 -- `DATE`を`TIME`に変換すると、結果は「00:00:00」になります。 +- `DATE`を`DATETIME`または`TIMESTAMP`に変換すると、DATEには時間情報が含まれていないため、時間部分'00:00:00'が追加されます。 +- `DATE`を`TIME`に変換すると、結果は'00:00:00'になります。 `DATETIME`または`TIMESTAMP`の変換: -- `DATETIME`または`TIMESTAMP` `DATE`に変換する場合、時刻と小数部分は切り捨てられます。例えば、「1999-12-31 23:59:59.499」は「1999-12-31」に変換されます。 +- `DATETIME`または`TIMESTAMP` `DATE`に変換する場合、時刻と小数部分は切り捨てられます。例えば、'1999-12-31 23:59:59.499'は'1999-12-31'に変換されます。 - `DATETIME`または`TIMESTAMP`をTIMEに変換すると、 `TIME`は日付情報が含まれていないため、日付部分は破棄されます。 `TIME`を他の日時形式に変換すると、日付部分は自動的に`CURRENT_DATE()`に指定されます。最終的な変換結果は、 `TIME`と`CURRENT_DATE()`で構成される日付になります。つまり、TIME の値が '00:00:00' から '23:59:59' の範囲外の場合、変換後の日付部分は現在の日付を示しません。 diff --git a/develop/dev-guide-aws-appflow-integration.md b/develop/dev-guide-aws-appflow-integration.md index f685f5cb1a4fe..e0032c959f260 100644 --- a/develop/dev-guide-aws-appflow-integration.md +++ b/develop/dev-guide-aws-appflow-integration.md @@ -127,7 +127,7 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration ![connect to salesforce](/media/develop/aws-appflow-step-connect-to-salesforce.png) - 2. 「許可」をクリックして、AWSがSalesforceデータを読み取ることを**許可する**ことを確認してください。 + 2. **Allow**をクリックして、AWSがSalesforceデータを読み取ることを許可することを確認してください。 ![allow salesforce](/media/develop/aws-appflow-step-allow-salesforce.png) diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index 52f508c4ae6ca..629e50b52ab5a 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -198,7 +198,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 - **useServerPrepStmts** - **useServerPrepStmts**はデフォルトで`false`に設定されています。つまり、Prepare API を使用する場合でも、「prepare」操作はクライアント側でのみ実行されます。サーバーの解析オーバーヘッドを回避するため、同じ SQL文で Prepare API を複数回使用する場合は、この設定を`true`に設定することをお勧めします。 + **useServerPrepStmts**はデフォルトで`false`に設定されています。つまり、Prepare API を使用する場合でも、"prepare"操作はクライアント側でのみ実行されます。サーバーの解析オーバーヘッドを回避するため、同じ SQL文で Prepare API を複数回使用する場合は、この設定を`true`に設定することをお勧めします。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 @@ -207,7 +207,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 - **`cachePrepStmts`** - `useServerPrepStmts=true`ではサーバーがプリペアドステートメントを実行できますが、デフォルトではクライアントは実行後にプリペアドステートメントを閉じ、再利用しません。つまり、「準備」操作はテキストファイルの実行ほど効率的ではありません。この問題を解決するには、 `useServerPrepStmts=true`を設定した後、 `cachePrepStmts=true`を設定することをお勧めします。これにより、クライアントはプリペアドステートメントをキャッシュできるようになります。 + `useServerPrepStmts=true`ではサーバーがプリペアドステートメントを実行できますが、デフォルトではクライアントは実行後にプリペアドステートメントを閉じ、再利用しません。つまり、"prepare"操作はテキストファイルの実行ほど効率的ではありません。この問題を解決するには、 `useServerPrepStmts=true`を設定した後、 `cachePrepStmts=true`を設定することをお勧めします。これにより、クライアントはプリペアドステートメントをキャッシュできるようになります。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 @@ -229,7 +229,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 - **prepStmtCacheSize** - **prepStmtCacheSize**は、キャッシュされるプリペアドステートメントの数を制御します（デフォルト値は`25`です）。アプリケーションで多くの種類の SQL文を「準備」する必要があり、プリペアドステートメントを再利用したい場合は、この値を増やすことができます。 + **prepStmtCacheSize**は、キャッシュされるプリペアドステートメントの数を制御します（デフォルト値は`25`です）。アプリケーションで多くの種類の SQL文を"preparing"する必要があり、プリペアドステートメントを再利用したい場合は、この値を増やすことができます。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 @@ -264,7 +264,7 @@ INSERT INTO `t` (`a`) VALUES(12); INSERT INTO `t` (`a`) values(10),(11),(12); ``` -`INSERT`のステートメントの書き換えは、複数の「values」キーワードの後の値を連結して、1つのSQL文にすることです。`INSERT`のステートメントに他の違いがある場合は、書き換えることはできません。たとえば、次のようになります。 +`INSERT`のステートメントの書き換えは、複数の"values"キーワードの後の値を連結して、1つのSQL文にすることです。`INSERT`のステートメントに他の違いがある場合は、書き換えることはできません。たとえば、次のようになります。 ```sql INSERT INTO `t` (`a`) VALUES (10) ON DUPLICATE KEY UPDATE `a` = 10; diff --git a/develop/dev-guide-object-naming-guidelines.md b/develop/dev-guide-object-naming-guidelines.md index 82d941063ca60..164e4675b297b 100644 --- a/develop/dev-guide-object-naming-guidelines.md +++ b/develop/dev-guide-object-naming-guidelines.md @@ -34,7 +34,7 @@ aliases: ['/ja/tidb/stable/dev-guide-object-naming-guidelines/','/ja/tidbcloud/d - 列の命名は、列の実際の意味または略語です。 - 同じ意味を持つテーブル間では同じ列名を使用することをお勧めします。 -- 列に注釈を追加し、「0: オフライン、1: オンライン」などの列挙型の名前付きの値を指定することをお勧めします。 +- 列に注釈を追加し、"0: offline, 1: online"などの列挙型の名前付きの値を指定することをお勧めします。 - ブール列の名前は`is_{description}`にすることをお勧めします。例えば、 `member`テーブルの、メンバーが有効かどうかを示す列の名前は`is_enabled`にすることができます。 - 列名を 30 文字以上にすることは推奨されません。また、列の数は 60 未満にする必要があります。 - `order` 、 `from` 、 `desc`などのTiDB予約語を列名として使用しないでください。キーワードが予約されているかどうかを確認するには、 [TiDBキーワード](/keywords.md)を参照してください。 diff --git a/develop/dev-guide-sample-application-cs.md b/develop/dev-guide-sample-application-cs.md index 00193f4146fcf..2906b07569e71 100644 --- a/develop/dev-guide-sample-application-cs.md +++ b/develop/dev-guide-sample-application-cs.md @@ -59,7 +59,7 @@ log : Restored /home/dvaneeden/tidb_cs/tidb_cs.csproj (in 551 ms). ## ステップ3. コードを更新する {#step-3-update-the-code} -`Program.cs`内の「Hello World」の例を次のコードに置き換えてください。 +`Program.cs`内の"Hello World"の例を次のコードに置き換えてください。 ```cs using System; diff --git a/develop/dev-guide-sample-application-nodejs-sequelize.md b/develop/dev-guide-sample-application-nodejs-sequelize.md index 9a1fa197f1c2f..bb28ada12fd23 100644 --- a/develop/dev-guide-sample-application-nodejs-sequelize.md +++ b/develop/dev-guide-sample-application-nodejs-sequelize.md @@ -353,7 +353,7 @@ logger.info(deletedNewPlayer?.toJSON()); ## 次のステップ {#next-steps} - ORM フレームワーク Sequelize ドライバーの使用法の詳細については[Sequelizeのドキュメント](https://sequelize.org/)を参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)」、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」など[単一テーブルの読み取り](/develop/dev-guide-get-data-from-single-table.md)章を読んで、TiDB アプリケーション開発のベスト [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)の[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、[単一テーブルの読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベストプラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-transaction-overview.md b/develop/dev-guide-transaction-overview.md index f58dcc3d32530..9666759b9583a 100644 --- a/develop/dev-guide-transaction-overview.md +++ b/develop/dev-guide-transaction-overview.md @@ -126,7 +126,7 @@ SELECT * FROM `users`; ## トランザクション分離レベル {#transaction-isolation-levels} -トランザクション分離レベルは、データベースのトランザクション処理の基礎となります。**ACID**の「I」（Isolation）は、トランザクションの分離を意味します。 +トランザクション分離レベルは、データベースのトランザクション処理の基礎となります。**ACID**の"I"（Isolation）は、トランザクションの分離を意味します。 SQL-92 標準では、次の4つの分離レベルが定義されています。 @@ -159,7 +159,7 @@ mysql> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; ERROR 8048 (HY000): The isolation level 'SERIALIZABLE' is not supported. Set tidb_skip_isolation_level_check=1 to skip this error ``` -TiDBは、MySQLとの整合性を確保するために、スナップショット分離（SI）レベルの整合性（「repeatable read」とも呼ばれます）を実装しています。この分離レベルは[ANSI Repeatable Read Isolation Level](/transaction-isolation-levels.md#difference-between-tidb-and-ansi-repeatable-read)および[MySQL Repeatable Read Isolation Level](/transaction-isolation-levels.md#difference-between-tidb-and-mysql-repeatable-read)とは異なります。詳細については、 [TiDBトランザクション分離レベル](/transaction-isolation-levels.md)を参照してください。 +TiDBは、MySQLとの整合性を確保するために、スナップショット分離（SI）レベルの整合性（"repeatable read"とも呼ばれます）を実装しています。この分離レベルは[ANSI Repeatable Read Isolation Level](/transaction-isolation-levels.md#difference-between-tidb-and-ansi-repeatable-read)および[MySQL Repeatable Read Isolation Level](/transaction-isolation-levels.md#difference-between-tidb-and-mysql-repeatable-read)とは異なります。詳細については、 [TiDBトランザクション分離レベル](/transaction-isolation-levels.md)を参照してください。 ## ヘルプが必要ですか? {#need-help} diff --git a/develop/dev-guide-use-common-table-expression.md b/develop/dev-guide-use-common-table-expression.md index 446547c08c25e..457dd4d54eed3 100644 --- a/develop/dev-guide-use-common-table-expression.md +++ b/develop/dev-guide-use-common-table-expression.md @@ -110,7 +110,7 @@ public List getTop50EldestAuthorInfoByCTE() throws SQLException { -著者「Ray Macejkovic」は4冊の本を執筆していることがわかります。CTEクエリを使用すると、これらの4冊の本の順序と評価情報を次のように取得できます。 +著者"Ray Macejkovic"は4冊の本を執筆していることがわかります。CTEクエリを使用すると、これらの4冊の本の順序と評価情報を次のように取得できます。 ```sql WITH books_authored_by_rm AS ( diff --git a/develop/dev-guide-use-follower-read.md b/develop/dev-guide-use-follower-read.md index f675db5b9e207..bcb93c928af16 100644 --- a/develop/dev-guide-use-follower-read.md +++ b/develop/dev-guide-use-follower-read.md @@ -20,8 +20,8 @@ TiDBは、 [リージョン](/tidb-storage.md#region)基本単位として、ク 次のいずれかを実行すると、アプリケーションにホットスポットリージョンがあるかどうかを視覚的に分析できます。 -- TiDB Cloud: [TiDB Cloudコンソールのキー ビジュアライザー](/tidb-cloud/tune-performance.md#key-visualizer)に移動し、「メトリック選択ボックス」を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 -- TiDB Self-Managed: [TiDB DashboardのKey Visualizer](/dashboard/dashboard-key-visualizer.md)に移動し、「メトリック選択ボックス」を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 +- TiDB Cloud: [TiDB Cloudコンソールのキー ビジュアライザー](/tidb-cloud/tune-performance.md#key-visualizer)に移動し、"metrics selection box"を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 +- TiDB Self-Managed: [TiDB DashboardのKey Visualizer](/dashboard/dashboard-key-visualizer.md)に移動し、"metrics selection box"を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 ホットスポットの問題が存在する場合は、 [TiDBホットスポットの問題の処理](/troubleshoot-hot-spot-issues.md)を参照してトラブルシューティングを行うことができます。これにより、アプリケーション レベルでのホットスポットの生成を回避することができます。 diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index 4fd8aa081b41c..981668aa1b5c9 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -88,7 +88,7 @@ JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式 ##### `useServerPrepStmts` {#useserverprepstmts} -`useServerPrepStmts`はデフォルトで`false`に設定されています。つまり、Prepare API を使用する場合でも、「prepare」操作はクライアント側でのみ実行されます。サーバーの解析オーバーヘッドを回避するため、同じ SQL文で Prepare API を複数回使用する場合は、この設定を`true`に設定することをお勧めします。 +`useServerPrepStmts`はデフォルトで`false`に設定されています。つまり、Prepare API を使用する場合でも、"prepare"操作はクライアント側でのみ実行されます。サーバーの解析オーバーヘッドを回避するため、同じ SQL文で Prepare API を複数回使用する場合は、この設定を`true`に設定することをお勧めします。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 @@ -97,7 +97,7 @@ JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式 ##### `cachePrepStmts` {#cacheprepstmts} -`useServerPrepStmts=true`はサーバーがプリペアドステートメントを実行できるようにしますが、デフォルトではクライアントは実行後にプリペアドステートメントを閉じ、再利用しません。つまり、「準備」操作はテキストファイルの実行ほど効率的ではありません。この問題を解決するには、 `useServerPrepStmts=true`を設定した後、 `cachePrepStmts=true`も設定することをお勧めします。これにより、クライアントはプリペアドステートメントをキャッシュできるようになります。 +`useServerPrepStmts=true`はサーバーがプリペアドステートメントを実行できるようにしますが、デフォルトではクライアントは実行後にプリペアドステートメントを閉じ、再利用しません。つまり、"prepare"操作はテキストファイルの実行ほど効率的ではありません。この問題を解決するには、 `useServerPrepStmts=true`を設定した後、 `cachePrepStmts=true`も設定することをお勧めします。これにより、クライアントはプリペアドステートメントをキャッシュできるようになります。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 @@ -119,7 +119,7 @@ JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式 ##### `prepStmtCacheSize` {#prepstmtcachesize} -`prepStmtCacheSize`キャッシュされるプリペアドステートメントの数を制御します (デフォルト値は`25`です)。アプリケーションで多くの種類の SQL文を「準備」する必要があり、プリペアドステートメントを再利用したい場合は、この値を増やすことができます。 +`prepStmtCacheSize`キャッシュされるプリペアドステートメントの数を制御します (デフォルト値は`25`です)。アプリケーションで多くの種類の SQL文を"prepare"する必要があり、プリペアドステートメントを再利用したい場合は、この値を増やすことができます。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 @@ -158,7 +158,7 @@ insert into t(a) values(12); insert into t(a) values(10),(11),(12); ``` -`INSERT`文の書き換えは、複数の「values」キーワードの後の値を連結して 1つの SQL文にするものであることに注意してください。 `INSERT`文に他の違いがある場合、書き換えることはできません。たとえば、次のようになります。 +`INSERT`文の書き換えは、複数の"values"キーワードの後の値を連結して 1つの SQL文にするものであることに注意してください。 `INSERT`文に他の違いがある場合、書き換えることはできません。たとえば、次のようになります。 ```sql insert into t (a) values (10) on duplicate key update a = 10; @@ -296,8 +296,8 @@ The last packet sent successfully to the server was 3600000 milliseconds ago. Th MyBatis Mapperは2つのパラメータをサポートしています。 -- `select 1 from t where id = #{param1}` 、プリペアドステートメントとして`select 1 from t where id =?`に変換され、「準備済み」の状態になります。実際のパラメータは再利用されます。このパラメータを前述の接続準備パラメータと併用すると、最高のパフォーマンスが得られます。 -- `select 1 from t where id = ${param2}`はテキストファイル`select 1 from t where id = 1`に置き換えられ、実行されます。このステートメントが異なるパラメータに置き換えられて実行されると、MyBatis はステートメントの「準備」のために TiDB に異なるリクエストを送信します。これにより、TiDB が多数のプリペアドステートメントをキャッシュする可能性があり、この方法で SQL 操作を実行すると、インジェクションのセキュリティリスクが発生します。 +- `select 1 from t where id = #{param1}` 、プリペアドステートメントとして`select 1 from t where id =?`に変換され、"prepared"の状態になります。実際のパラメータは再利用されます。このパラメータを前述の接続準備パラメータと併用すると、最高のパフォーマンスが得られます。 +- `select 1 from t where id = ${param2}`はテキストファイル`select 1 from t where id = 1`に置き換えられ、実行されます。このステートメントが異なるパラメータに置き換えられて実行されると、MyBatis はステートメントの"preparing"のために TiDB に異なるリクエストを送信します。これにより、TiDB が多数のプリペアドステートメントをキャッシュする可能性があり、この方法で SQL 操作を実行すると、インジェクションのセキュリティリスクが発生します。 #### 動的SQLバッチ {#dynamic-sql-batch} @@ -319,7 +319,7 @@ MyBatis Mapperは2つのパラメータをサポートしています。 ``` -このマッパーは`insert on duplicate key update`文を生成します。 `(?,?,?)`に続く「値」の数は、渡されたリストの数によって決まります。最終的な効果は`rewriteBatchStatements=true`を使用した場合と同様で、クライアントと TiDB 間の通信オーバーヘッドを効果的に削減します。 +このマッパーは`insert on duplicate key update`文を生成します。 `(?,?,?)`に続く"values"の数は、渡されたリストの数によって決まります。最終的な効果は`rewriteBatchStatements=true`を使用した場合と同様で、クライアントと TiDB 間の通信オーバーヘッドを効果的に削減します。 前述のとおり、プリペアドステートメントの最大長が`prepStmtCacheSqlLimit`の値を超えると、キャッシュされないことにも注意する必要があります。 diff --git a/dm/deploy-a-dm-cluster-using-tiup.md b/dm/deploy-a-dm-cluster-using-tiup.md index bcda8ae9b398b..10c016ef04fcb 100644 --- a/dm/deploy-a-dm-cluster-using-tiup.md +++ b/dm/deploy-a-dm-cluster-using-tiup.md @@ -166,7 +166,7 @@ tiup dm deploy ${name} ${version} ./topology.yaml -u ${ssh_user} [-p] [-i /home/ | `./topology.yaml` | トポロジ構成ファイルのパス。 | | `-u`または`--user` | クラスターのデプロイを完了するには、root ユーザーまたは ssh および sudo権限を持つ他のユーザーアカウントとしてターゲットマシンにログインします。 | | `-p`または`--password` | 対象ホストのパスワード。指定すると、パスワード認証が使用されます。 | -| `-i`または`--identity_file` | SSH IDファイルのパス。指定すると公開鍵認証が使用されます（デフォルトは「/root/.ssh/id_rsa」）。 | +| `-i`または`--identity_file` | SSH IDファイルのパス。指定すると公開鍵認証が使用されます（デフォルトは"/root/.ssh/id_rsa"）。 | 出力ログの最後に``Deployed cluster `dm-test` successfully``が表示されます。これは、デプロイメントが成功したことを示します。 diff --git a/dm/dm-continuous-data-validation.md b/dm/dm-continuous-data-validation.md index 909c01fa84264..14e4d4a754e25 100644 --- a/dm/dm-continuous-data-validation.md +++ b/dm/dm-continuous-data-validation.md @@ -212,7 +212,7 @@ dmctl は 3つのエラー処理コマンドを提供します。 -h, --help help for clear-error ``` -- `ignore-error` : エラー行を無視します。このエラー行は「無視」としてマークされます。 +- `ignore-error` : エラー行を無視します。このエラー行は"ignored"としてマークされます。 ``` Usage: @@ -223,7 +223,7 @@ dmctl は 3つのエラー処理コマンドを提供します。 -h, --help help for ignore-error ``` -- `resolve-error` : エラー行は手動で処理され、「解決済み」としてマークされます。 +- `resolve-error` : エラー行は手動で処理され、"resolved"としてマークされます。 ``` Usage: @@ -285,7 +285,7 @@ DM における継続的なデータ検証 (バリデータ) のアーキテク - バリデータは、シンカーによって増分移行されたイベントのみをチェックします。イベントがシンカーによって処理されていない場合、バリデータは一時停止し、シンカーによる処理が完了するまで待機します。 - イベントがシンカーによって処理された場合、バリデーターは次の手順に進みます。 2. バリデータはbinlogイベントを解析し、ブロックリストと許可リスト、テーブルフィルター、テーブルルーティングに基づいて行をフィルタリングします。その後、バリデータは変更された行をバックグラウンドで実行される検証ワーカーに送信します。 -3. 検証ワーカーは、同じテーブルと同じ主キーに影響する変更された行をマージし、「期限切れ」データの検証を回避します。変更された行はメモリにキャッシュされます。 +3. 検証ワーカーは、同じテーブルと同じ主キーに影響する変更された行をマージし、"expired"データの検証を回避します。変更された行はメモリにキャッシュされます。 4. 検証ワーカーは、変更された行が一定数蓄積されるか、一定の時間間隔が経過すると、主キーを使用して下流のデータベースを照会し、現在のデータを取得して、変更された行と比較します。 5. 検証ワーカーはデータ検証を実行します。検証モードが`full`の場合、検証ワーカーは変更された行のデータを下流データベースのデータと比較します。検証モードが`fast`の場合、検証ワーカーは変更された行の存在のみを確認します。 - 変更された行が検証に合格した場合、変更された行はメモリから削除されます。 diff --git a/dm/dm-faq.md b/dm/dm-faq.md index dccbe0d59eb79..c1727c3a71795 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -145,7 +145,7 @@ DM v2.0 以降、増分データレプリケーションを続行するために 設定項目`block-allow-list`と`table-route`を確認します。 -- `block-allow-list`の下にある上流のデータベースとテーブルの名前を設定する必要があります。`do-tables`の前に「~」を追加すると、正規表現を使用して名前を一致させることができます。 +- `block-allow-list`の下にある上流のデータベースとテーブルの名前を設定する必要があります。`do-tables`の前に"~"を追加すると、正規表現を使用して名前を一致させることができます。 - `table-route` 、テーブル名の一致に正規表現ではなくワイルドカード文字を使用します。例えば、 `table_parttern_[0-63]` `table_parttern_0`から`table_pattern_6`までの 7つのテーブルのみに一致します。 ## DM がアップストリームからレプリケートしていないのに、 `replicate lag`モニター メトリックにデータが表示されないのはなぜですか? {#why-does-the-replicate-lag-monitor-metric-show-no-data-when-dm-is-not-replicating-from-upstream} diff --git a/dm/dm-glossary.md b/dm/dm-glossary.md index 0c7590c367329..f3ab9287479ba 100644 --- a/dm/dm-glossary.md +++ b/dm/dm-glossary.md @@ -70,7 +70,7 @@ GTIDはMySQLまたはMariaDBのグローバルトランザクションIDです TiDB データ移行ツールを使用して、アップストリーム データベースの**完全なデータを**ダウンストリームデータベースにコピーするプロセス。 -「完全」と明記している場合、「完全または増分」とは明記していない場合、「完全 + 増分」と明記している場合は、replicate/replication ではなく migrate/migration を使用します。 +"full"と明記している場合、"full or incremental"とは明記していない場合、"full + incremental"と明記している場合は、replicate/replication ではなく migrate/migration を使用します。 ## R {#r} @@ -88,7 +88,7 @@ TiDB データ移行ツールを使用して、アップストリーム デー TiDB データ移行ツールを使用して、上流データベースの**増分データを**下流データベースにコピーするプロセス。 -「増分」を明確に記載する場合は、 migrate/migration ではなく、replicate/replication を使用します。 +"incremental"を明確に記載する場合は、 migrate/migration ではなく、replicate/replication を使用します。 ## S {#s} diff --git a/dm/dm-pause-task.md b/dm/dm-pause-task.md index cb107f2f7ff36..0f4f1eeb94c83 100644 --- a/dm/dm-pause-task.md +++ b/dm/dm-pause-task.md @@ -9,7 +9,7 @@ summary: TiDB データ移行でデータ移行タスクを一時停止する方 `pause-task`は`stop-task`と次の点で異なります: -- `pause-task`は移行タスクを一時停止するだけです。タスクのステータス情報（メモリに保持されている）は`query-status`で照会できます。`stop-task`は移行タスクを終了し、このタスクに関連するすべての情報をメモリから削除します。つまり、 `query-status`を使用してステータス情報を照会することはできません。「チェックポイント」のような`dm_meta`や、下流に移行済みのデータは削除されません。 +- `pause-task`は移行タスクを一時停止するだけです。タスクのステータス情報（メモリに保持されている）は`query-status`で照会できます。`stop-task`は移行タスクを終了し、このタスクに関連するすべての情報をメモリから削除します。つまり、 `query-status`を使用してステータス情報を照会することはできません。"checkpoint"のような`dm_meta`や、下流に移行済みのデータは削除されません。 - `pause-task`を実行して移行タスクを一時停止した場合、同じ名前の新しいタスクを開始することはできません。また、一時停止したタスクは既に存在するため、そのタスクのリレーログを削除することもできません。`stop-task`を実行してタスクを停止した場合、同じ名前の新しいタスクを開始できます。また、停止したタスクは既に存在しないため、そのタスクのリレーログを削除することができます。 - `pause-task`は通常、トラブルシューティングのためにタスクを一時停止するために使用され、 `stop-task`は移行タスクを永続的に削除するか、 `start-task`と連携して構成情報を更新するために使用されます。 diff --git a/dm/dm-precheck.md b/dm/dm-precheck.md index bda4872eb56e7..0ba64199ee0fe 100644 --- a/dm/dm-precheck.md +++ b/dm/dm-precheck.md @@ -27,7 +27,7 @@ tiup dmctl check-task ./task.yaml > **Note:** > -> この文書では、必ず合格しなければならないチェック項目には「（必須）」というラベルが付いています。 +> この文書では、必ず合格しなければならないチェック項目には"（必須）"というラベルが付いています。 > - 必須チェック項目に合格しなかった場合、DM はチェック後にエラーを返し、移行タスクを続行しません。この場合、エラーメッセージに従って設定を変更し、事前チェック要件を満たした後にタスクを再試行してください。 > @@ -100,7 +100,7 @@ tiup dmctl check-task ./task.yaml - 下流データベース内の空のリージョン - - 空のリージョンの数が`max(1000, 3 * the number of tables)` (「1000」と「テーブル数の 3 倍」の大きい方) より大きい場合、事前チェックは警告を返します。関連する PD パラメータを調整して、空のリージョンの結合を高速化し、空のリージョンの数が減少するのを待つことができます。 [PDスケジューリングのベストプラクティス - 低速リージョンマージ](/best-practices/pd-scheduling-best-practices.md#region-merge-is-slow)を参照。 + - 空のリージョンの数が`max(1000, 3 * the number of tables)` ("1000"と「テーブル数の 3 倍」の大きい方) より大きい場合、事前チェックは警告を返します。関連する PD パラメータを調整して、空のリージョンの結合を高速化し、空のリージョンの数が減少するのを待つことができます。 [PDスケジューリングのベストプラクティス - 低速リージョンマージ](/best-practices/pd-scheduling-best-practices.md#region-merge-is-slow)を参照。 - 下流データベースにおけるリージョン分布 diff --git a/dm/dm-query-status.md b/dm/dm-query-status.md index b4396b9a6bb73..a08fe49e86aff 100644 --- a/dm/dm-query-status.md +++ b/dm/dm-query-status.md @@ -227,16 +227,16 @@ DM移行タスクのステータスは、DMワーカーに割り当てられた - `sourceStatus` : アップストリーム MySQL データベースの情報。 - `subTaskStatus` : アップストリーム MySQL データベースのすべてのサブタスクの情報。各サブタスクには以下のフィールドが含まれる場合があります。 - `name` : サブタスクの名前。 - - `stage` : サブタスクのステータス。「sources」の「subTaskStatus」の「stage」のステータスの説明とステータスの切り替え関係については、 [サブタスクのステータス](#subtask-status)を参照してください。 - - `unit` : 「チェック」、「ダンプ」、「ロード」、「同期」を含む DM の処理単位。 + - `stage` : サブタスクのステータス。"sources"の"subTaskStatus"の"stage"のステータスの説明とステータスの切り替え関係については、 [サブタスクのステータス](#subtask-status)を参照してください。 + - `unit` : "Check"、"Dump"、"Load"、"Sync"を含む DM の処理単位。 - `result` : サブタスクが失敗した場合にエラー情報を表示します。 - - `unresolvedDDLLockID` : シャーディングDDLロックID。異常状態におけるシャーディングDDLロックを手動で処理するために使用されます。「sources」の「subTaskStatus」の「unresolvedDDLLockID」の動作の詳細については、 [シャーディング DDL ロックを手動で処理する](/dm/manually-handling-sharding-ddl-locks.md)を参照してください。 + - `unresolvedDDLLockID` : シャーディングDDLロックID。異常状態におけるシャーディングDDLロックを手動で処理するために使用されます。"sources"の"subTaskStatus"の"unresolvedDDLLockID"の動作の詳細については、 [シャーディング DDL ロックを手動で処理する](/dm/manually-handling-sharding-ddl-locks.md)を参照してください。 - `sync` ： `Sync`処理ユニットの複製情報。この情報は、現在の処理ユニットと同じコンポーネントに関するものです。 - `masterBinlog` : アップストリーム データベース内のbinlog の位置。 - `masterBinlogGtid` : アップストリーム データベース内の GTID 情報。 - `syncerBinlog` : `Sync`処理単位で複製されたbinlogの位置。 - `syncerBinlogGtid` : GTID を使用して複製されたbinlogの位置。 - - `blockingDDLs` : 現在ブロックされているDDLリスト。このDMワーカーのすべての上流テーブルが「同期済み」ステータスにある場合にのみ空になります。この場合、実行されるかスキップされるシャーディングDDL文を示します。 + - `blockingDDLs` : 現在ブロックされているDDLリスト。このDMワーカーのすべての上流テーブルが"synced"ステータスにある場合にのみ空になります。この場合、実行されるかスキップされるシャーディングDDL文を示します。 - `unresolvedGroups` : 解決されていないシャーディンググループ。各グループには以下のフィールドが含まれます。 - `target` : 複製されるダウンストリームデータベーステーブル。 - `DDLs` : DDL文のリスト。 diff --git a/dm/dm-replication-logic.md b/dm/dm-replication-logic.md index 546015802fd06..2cdda6dbe8fd3 100644 --- a/dm/dm-replication-logic.md +++ b/dm/dm-replication-logic.md @@ -16,7 +16,7 @@ summary: DM のコア処理ユニット Sync が DML文を複製する方法に 2. データソースから読み取ったbinlogイベントを変換します。 1. [Binlogフィルター](/dm/dm-binlog-event-filter.md) : `filters`で設定されたbinlog式に従ってbinlogイベントをフィルタリングします。 - 2. [テーブルルーティング](/dm/dm-table-routing.md) : `routes`で設定された「データベース/テーブル」ルーティングルールに従って「データベース/テーブル」名を変換します。 + 2. [テーブルルーティング](/dm/dm-table-routing.md) : `routes`で設定された"database/table"ルーティングルールに従って"database/table"名を変換します。 3. [表現フィルター](/filter-dml-event.md) : `expression-filter`で設定された SQL 式に従ってbinlogイベントをフィルタリングします。 3. DML 実行計画を最適化します。 @@ -141,7 +141,7 @@ DMは行レベルでデータを複製するため、トランザクションの ### セーフモード {#safe-mode} -DML実行とチェックポイント更新の操作はアトミックではなく、チェックポイント更新と下流へのデータ書き込みの操作もアトミックではありません。DMが異常終了した場合、チェックポイントは終了時刻より前のリカバリポイントのみを記録する可能性があります。そのため、タスクが再開されると、DMは同じデータを複数回書き込む可能性があります。これは、DMが実際には「少なくとも1回の処理」ロジックを提供していることを意味し、同じデータが複数回処理される可能性があります。 +DML実行とチェックポイント更新の操作はアトミックではなく、チェックポイント更新と下流へのデータ書き込みの操作もアトミックではありません。DMが異常終了した場合、チェックポイントは終了時刻より前のリカバリポイントのみを記録する可能性があります。そのため、タスクが再開されると、DMは同じデータを複数回書き込む可能性があります。これは、DMが実際には"at least once processing"ロジックを提供していることを意味し、同じデータが複数回処理される可能性があります。 データが再入可能であることを確認するために、DM は異常終了から再起動するときにセーフモードに入ります。 @@ -152,4 +152,4 @@ DML実行とチェックポイント更新の操作はアトミックではな ### 正確に1回だけ処理 {#exactly-once-processing} -現在、DM は結果整合性のみを保証しており、「正確に 1回の処理」や「トランザクションの元の順序の維持」はサポートしていません。 +現在、DM は結果整合性のみを保証しており、"exactly-once processing"や"keeping the original order of transactions"はサポートしていません。 diff --git a/dm/dm-safe-mode.md b/dm/dm-safe-mode.md index f28e7c70c06bd..48b0abb68cb00 100644 --- a/dm/dm-safe-mode.md +++ b/dm/dm-safe-mode.md @@ -26,7 +26,7 @@ summary: DMセーフモードについて、その目的、動作原理、およ バージョン8.5.6以降、タスクセッションで`foreign_key_checks=1`を設定すると、DMは主キーまたは一意インデックス値を変更しない`DELETE` `UPDATE`ステップをスキップします。詳細については、[外部キーの処理](#foreign-key-handling-new-in-v856)キー を参照してください。 -`REPLACE`は、MySQL でデータを挿入するための固有の構文です。 `REPLACE`を使用してデータを挿入し、新しいデータと既存のデータに主キーまたは一意制約の競合がある場合、MySQL は競合するすべてのレコードを削除し、挿入操作を実行します。これは「強制挿入」と同等です。詳細については、MySQL ドキュメントの[`REPLACE`文](https://dev.mysql.com/doc/refman/8.0/en/replace.html)を参照してください。 +`REPLACE`は、MySQL でデータを挿入するための固有の構文です。 `REPLACE`を使用してデータを挿入し、新しいデータと既存のデータに主キーまたは一意制約の競合がある場合、MySQL は競合するすべてのレコードを削除し、挿入操作を実行します。これは"force insert"と同等です。詳細については、MySQL ドキュメントの[`REPLACE`文](https://dev.mysql.com/doc/refman/8.0/en/replace.html)を参照してください。 `dummydb.dummytbl`テーブルに主キー`id`があると仮定します。このテーブルに対して、次の SQL文を繰り返し実行します。 diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md index 26399f8b5c05b..8c3b91a1d027b 100644 --- a/dm/feature-shard-merge-optimistic.md +++ b/dm/feature-shard-merge-optimistic.md @@ -13,11 +13,11 @@ summary: DM が楽観的モードでシャードテーブルからデータを ## 背景 {#background} -DMは、シャーディングDDLと呼ばれるシャーディングテーブルへのDDL文のオンライン実行をサポートしており、デフォルトで「悲観的モード」を使用します。このモードでは、上流のシャーディングテーブルでDDL文が実行されると、そのテーブルのデータ移行は、他のすべてのシャーディングテーブルで同じDDL文が実行されるまで一時停止されます。その後、下流のシャーディングテーブルで同じDDL文が実行され、データ移行が再開されます。 +DMは、シャーディングDDLと呼ばれるシャーディングテーブルへのDDL文のオンライン実行をサポートしており、デフォルトで"pessimistic mode"を使用します。このモードでは、上流のシャーディングテーブルでDDL文が実行されると、そのテーブルのデータ移行は、他のすべてのシャーディングテーブルで同じDDL文が実行されるまで一時停止されます。その後、下流のシャーディングテーブルで同じDDL文が実行され、データ移行が再開されます。 悲観的モードでは、下流に移行されるデータが常に正しいことが保証されますが、データ移行が一時停止されるため、上流でのA/B変更には適していません。場合によっては、ユーザーは単一のシャードテーブルでDDL文の実行に長い時間を費やし、検証期間が経過した後に他のシャードテーブルのスキーマを変更することがあります。悲観的モードでは、これらのDDL文がデータ移行をブロックし、多くのbinlogイベントが蓄積される原因となります。 -そのため、「楽観的モード」が必要になります。このモードでは、シャードテーブルに対して実行されたDDL文は、他のシャードテーブルと互換性のある文に自動的に変換され、すぐに下流に移行されます。これにより、DDL文がシャードテーブルによるDML移行の実行をブロックすることはありません。 +そのため、"optimistic mode"が必要になります。このモードでは、シャードテーブルに対して実行されたDDL文は、他のシャードテーブルと互換性のある文に自動的に変換され、すぐに下流に移行されます。これにより、DDL文がシャードテーブルによるDML移行の実行をブロックすることはありません。 ## 楽観的モードのコンフィグレーション {#configuration-of-the-optimistic-mode} @@ -37,9 +37,9 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル - DDL文を実行する際は、DM移行のステータスを確認してください。エラーが報告された場合は、この一連のDDL文がデータの不整合を引き起こすかどうかを判断する必要があります。 -楽観的モードでは、上流で実行されたDDL文の大部分が、追加の作業なしに自動的に下流に移行されます。これらのDDL文は「タイプ1 DDL」と呼ばれます。 +楽観的モードでは、上流で実行されたDDL文の大部分が、追加の作業なしに自動的に下流に移行されます。これらのDDL文は"Type 1 DDL"と呼ばれます。 -列名、列の型、または列のデフォルト値を変更するDDL文は「Type 2 DDL」と呼ばれます。アップストリームでType 2 DDL文を実行する場合は、すべてのシャードテーブルで同じ順序でDDL文を実行するようにしてください。 +列名、列の型、または列のデフォルト値を変更するDDL文は"Type 2 DDL"と呼ばれます。アップストリームでType 2 DDL文を実行する場合は、すべてのシャードテーブルで同じ順序でDDL文を実行するようにしてください。 タイプ 2 DDL文の例を次に示します。 diff --git a/dm/handle-failed-ddl-statements.md b/dm/handle-failed-ddl-statements.md index 24c56b77c8a61..02a37593cf5e6 100644 --- a/dm/handle-failed-ddl-statements.md +++ b/dm/handle-failed-ddl-statements.md @@ -224,7 +224,7 @@ ERROR 8200 (HY000): Unsupported modify column: can't change decimal column preci #### シャードマージシナリオ {#shard-merge-scenario} -アップストリームにある以下の4つのテーブルを、ダウンストリームにある同じテーブル`` `shard_db`.`shard_table` ``にマージして移行する必要があると仮定します。タスクモードは「悲観的」です。 +アップストリームにある以下の4つのテーブルを、ダウンストリームにある同じテーブル`` `shard_db`.`shard_table` ``にマージして移行する必要があると仮定します。タスクモードは"pessimistic"です。 - MySQL インスタンス 1 には、 `shard_table_1`と`shard_table_2`テーブルを含む`shard_db_1`スキーマが含まれています。 - MySQL インスタンス 2 には、 `shard_table_1`と`shard_table_2`テーブルを含む`shard_db_2`スキーマが含まれています。 @@ -569,7 +569,7 @@ ALTER TABLE `db1`.`tbl1` ADD COLUMN new_col INT UNIQUE; #### シャードマージシナリオ {#shard-merge-scenario} -アップストリームにある以下の4つのテーブルを、ダウンストリームにある同じテーブル`` `shard_db`.`shard_table` ``にマージして移行する必要があると仮定します。タスクモードは「悲観的」です。 +アップストリームにある以下の4つのテーブルを、ダウンストリームにある同じテーブル`` `shard_db`.`shard_table` ``にマージして移行する必要があると仮定します。タスクモードは"pessimistic"です。 - MySQL インスタンス 1 にはスキーマ`shard_db_1`があり、そこには`shard_table_1`と`shard_table_2` 2つのテーブルがあります。 - MySQL インスタンス 2 にはスキーマ`shard_db_2`があり、そこには`shard_table_1`と`shard_table_2` 2つのテーブルがあります。 diff --git a/dm/monitor-a-dm-cluster.md b/dm/monitor-a-dm-cluster.md index 61d785c4dc4a6..553e0e712dfc6 100644 --- a/dm/monitor-a-dm-cluster.md +++ b/dm/monitor-a-dm-cluster.md @@ -118,7 +118,7 @@ Grafana ダッシュボードでは、DM のデフォルト名は`DM-task`です | リレーログデータの破損 | 破損したリレーログファイルの数 | 即時アラート | 緊急 | | マスターからのbinlogの読み取りに失敗しました | リレーログが上流のMySQLからbinlogを読み込む際に発生したエラーの数 | 即時アラート | 致命的 | | リレーログの書き込みに失敗しました | リレーログがbinlogをディスクに書き込むときに発生したエラーの数 | 即時アラート | 致命的 | -| binlogファイルインデックス | リレーログファイルの最大インデックス番号。例えば、「value = 1」は「relay-log.000001」を示します。 | 該当なし | 該当なし | +| binlogファイルインデックス | リレーログファイルの最大インデックス番号。例えば、"value = 1"は"relay-log.000001"を示します。 | 該当なし | 該当なし | | マスターとリレー間のbinlogファイルのギャップ | 上流マスターの背後にあるリレーログ内のbinlogファイルの数 | `relay`処理ユニットが上流マスターより遅れているbinlogファイルの数が1つ（> 1）を超え、その状態が10分以上続くと、アラートが発生します。 | 致命的 | | binlog位置 | 最新のリレーログファイルの書き込みオフセット | 該当なし | 該当なし | | binlogイベントの期間の読み取り | リレーログが上流のMySQLからbinlogを読み取る時間（秒） | 該当なし | 該当なし | @@ -139,7 +139,7 @@ Grafana ダッシュボードでは、インスタンスのデフォルト名は | リレーログデータの破損 | 破損したリレーログの数 | 即時アラート | 緊急 | | マスターからのbinlogの読み取りに失敗しました | リレーログが上流のMySQLからbinlogを読み込む際に発生したエラーの数 | 即時アラート | 致命的 | | リレーログの書き込みに失敗しました | リレーログがbinlogをディスクに書き込むときに発生したエラーの数 | 即時アラート | 致命的 | -| binlogファイルインデックス | リレーログファイルの最大インデックス番号。例えば、「value = 1」は「relay-log.000001」を示します。 | 該当なし | 該当なし | +| binlogファイルインデックス | リレーログファイルの最大インデックス番号。例えば、"value = 1"は"relay-log.000001"を示します。 | 該当なし | 該当なし | | マスターとリレー間のbinlogファイルのギャップ | `relay`処理ユニットが上流マスターより遅れているbinlogファイルの数 | `relay`処理ユニットが上流マスターより遅れているbinlogファイルの数が1つ（> 1）を超え、その状態が10分以上続くと、アラートが発生します。 | 致命的 | | binlog位置 | 最新のリレーログファイルの書き込みオフセット | 該当なし | 該当なし | | binlogの読み取り期間 | リレーログが上流のMySQLからbinlogを読み取る時間（秒） | 該当なし | 該当なし | diff --git a/dm/quick-start-create-source.md b/dm/quick-start-create-source.md index 4e381a0ccfd75..0fbcfd65e17da 100644 --- a/dm/quick-start-create-source.md +++ b/dm/quick-start-create-source.md @@ -31,7 +31,7 @@ summary: データ移行 (DM) のデータソースを作成する方法を学 2. データソースの設定ファイルを書き込む - データソースごとに、個別の設定ファイルを作成する必要があります。以下の例に従って、IDが「mysql-01」のデータソースを作成します。まず、設定ファイル`./source-mysql-01.yaml`を作成します。 + データソースごとに、個別の設定ファイルを作成する必要があります。以下の例に従って、IDが"mysql-01"のデータソースを作成します。まず、設定ファイル`./source-mysql-01.yaml`を作成します。 ```yaml source-id: "mysql-01" # The ID of the data source, you can refer this source-id in the task configuration and dmctl command to associate the corresponding data source. diff --git a/dm/quick-start-create-task.md b/dm/quick-start-create-task.md index c7b3e4b83882a..dfda8885b3375 100644 --- a/dm/quick-start-create-task.md +++ b/dm/quick-start-create-task.md @@ -86,7 +86,7 @@ mv tidb-latest-linux-amd64/bin/tidb-server ./ > - データベースにパスワードがない場合、この手順をスキップできます。 > - DM v1.0.6 以降のバージョンでは、プレーンテキスト パスワードを使用してソース情報を構成できます。 -安全上の理由から、暗号化されたパスワードを設定して使用することをお勧めします。dmctlを使用してMySQL/TiDBのパスワードを暗号化できます。パスワードが「123456」だと仮定します。 +安全上の理由から、暗号化されたパスワードを設定して使用することをお勧めします。dmctlを使用してMySQL/TiDBのパスワードを暗号化できます。パスワードが"123456"だと仮定します。 > **Note:** > @@ -135,7 +135,7 @@ MySQL2 の場合、上記のコマンドの設定ファイルを MySQL2 の設 ## データ移行タスクを作成する {#create-a-data-migration-task} -[準備されたデータ](#prepare-data)をインポートすると、MySQL1 インスタンスと MySQL2 インスタンスの両方に複数のシャードテーブルが作成されます。これらのテーブルは構造が同一で、テーブル名に同じプレフィックス「t」が付きます。また、これらのテーブルが配置されているデータベースのプレフィックスはすべて「sharding」です。また、主キーと一意キーの競合はありません（各シャードテーブルの主キーまたは一意キーは、他のテーブルのものと異なります）。 +[準備されたデータ](#prepare-data)をインポートすると、MySQL1 インスタンスと MySQL2 インスタンスの両方に複数のシャードテーブルが作成されます。これらのテーブルは構造が同一で、テーブル名に同じプレフィックス"t"が付きます。また、これらのテーブルが配置されているデータベースのプレフィックスはすべて"sharding"です。また、主キーと一意キーの競合はありません（各シャードテーブルの主キーまたは一意キーは、他のテーブルのものと異なります）。 ここで、これらのシャードテーブルをTiDBの`db_target.t_target`テーブルに移行する必要があるとします。手順は以下のとおりです。 diff --git a/dm/relay-log.md b/dm/relay-log.md index 4247fc249a755..c9f94dabcf653 100644 --- a/dm/relay-log.md +++ b/dm/relay-log.md @@ -248,15 +248,15 @@ purge: - `purge.interval` - バックグラウンドでの自動パージの間隔（秒単位）。 - - デフォルトでは「3600」であり、バックグラウンド パージ タスクが 3600秒ごとに実行されることを示します。 + - デフォルトでは"3600"であり、バックグラウンド パージ タスクが 3600秒ごとに実行されることを示します。 - `purge.expires` - リレーログ (以前にリレー処理ユニットに書き込まれ、現在実行中のデータ移行タスクによって使用されていないか、後で読み取られないログ) を自動バックグラウンド パージで消去されるまで保持できる時間数。 - - デフォルトは「0」で、リレーログの更新時刻に応じてデータのパージが実行されないことを示します。 + - デフォルトは"0"で、リレーログの更新時刻に応じてデータのパージが実行されないことを示します。 - `purge.remain-space` - 指定されたDMワーカーマシンが、自動バックグラウンドパージで安全にパージできるリレーログをパージしようとするディスク残量（GB単位）です`0`に設定すると、ディスク残量に応じたデータパージは実行されません。 - - デフォルトでは「15」で、使用可能なディスク容量が 15 GB 未満になると、DM マスターはリレーログを安全に消去しようとします。 + - デフォルトでは"15"で、使用可能なディスク容量が 15 GB 未満になると、DM マスターはリレーログを安全に消去しようとします。 #### 手動パージ {#manual-purge} diff --git a/dm/shard-merge-best-practices.md b/dm/shard-merge-best-practices.md index a20f8ab930de2..a7b9897e20cde 100644 --- a/dm/shard-merge-best-practices.md +++ b/dm/shard-merge-best-practices.md @@ -5,11 +5,11 @@ summary: シャードマージのシナリオにおけるデータ移行のベ # シャード統合シナリオにおけるデータ移行のベストプラクティス {#best-practices-of-data-migration-in-the-shard-merge-scenario} -このドキュメントでは、シャードマージ シナリオにおける[TiDB Data Migration (DM)](/dm/dm-overview.md)の機能と制限について説明し、アプリケーションのデータ移行のベストプラクティス ガイドを提供します (デフォルトの「悲観的」モードが使用されます)。 +このドキュメントでは、シャードマージ シナリオにおける[TiDB Data Migration (DM)](/dm/dm-overview.md)の機能と制限について説明し、アプリケーションのデータ移行のベストプラクティス ガイドを提供します (デフォルトの"pessimistic"モードが使用されます)。 ## 別のデータ移行タスクを使用する {#use-a-separate-data-migration-task} -[シャードテーブルからのデータのマージと移行](/dm/feature-shard-merge-pessimistic.md#principles)ドキュメントでは、「シャーディンググループ」の定義が次のように示されています。シャーディンググループは、同じダウンストリームテーブルにマージおよび移行する必要があるすべてのアップストリームテーブルで構成されます。 +[シャードテーブルからのデータのマージと移行](/dm/feature-shard-merge-pessimistic.md#principles)ドキュメントでは、"sharding group"の定義が次のように示されています。シャーディンググループは、同じダウンストリームテーブルにマージおよび移行する必要があるすべてのアップストリームテーブルで構成されます。 現在のシャーディングDDLメカニズムには、異なるシャーディングされたテーブルにおけるDDL操作によってもたらされるスキーマ変更を調整するための[使用制限](/dm/feature-shard-merge-pessimistic.md#restrictions)の制約があります。予期しない理由によりこれらの制約に違反した場合は、 [DMでシャーディングDDLロックを手動で処理する](/dm/manually-handling-sharding-ddl-locks.md)を実行するか、データ移行タスク全体をやり直す必要があります。 diff --git a/dm/table-selector.md b/dm/table-selector.md index 10ab89a660ba3..ee9159918d966 100644 --- a/dm/table-selector.md +++ b/dm/table-selector.md @@ -11,7 +11,7 @@ summary: データ移行のテーブルルーティング、 binlogイベント テーブルセレクターは`schema-pattern`で次の2つのワイルドカード文字`table-pattern`を使用します。 -- アスタリスク文字（ `*` 、「スター」とも呼ばれる） +- アスタリスク文字（ `*` 、"star"とも呼ばれる） - `*` 0文字以上の文字に一致します。例えば、 `doc*` `doc`と`document`に一致しますが、 `dodo`は一致しません。 - `*`単語の末尾にのみ配置できます。例えば、 `doc*`がサポートされていますが、 `do*c`はサポートされていません。 diff --git a/dr-multi-replica.md b/dr-multi-replica.md index 577d9e358700f..28780efe75c4b 100644 --- a/dr-multi-replica.md +++ b/dr-multi-replica.md @@ -18,7 +18,7 @@ summary: 単一クラスターのマルチレプリカ災害復旧ソリュー > **Note:** > -> [TiKVの「リージョン」](/glossary.md#regionpeerraft-group)データの範囲を意味し、「リージョン」という用語は物理的な場所を意味します。この2つの用語は互換性がありません。 +> [TiKVの"Region"](/glossary.md#regionpeerraft-group)データの範囲を意味し、"region"という用語は物理的な場所を意味します。この2つの用語は互換性がありません。 ## クラスターをセットアップしてレプリカを構成する {#set-up-a-cluster-and-configure-replicas} diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index 35f668da46285..4c13f79bf7eba 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -37,7 +37,7 @@ summary: TiCDCに基づいたプライマリセカンダリディザスタリカ > **Note:** > -> - [TiKVの「リージョン」](/glossary.md#regionpeerraft-group)はデータの範囲を意味し、「領域」という用語は物理的な場所を意味します。この2つの用語は互換性がありません。 +> - [TiKVの"Region"](/glossary.md#regionpeerraft-group)はデータの範囲を意味し、"region"という用語は物理的な場所を意味します。この2つの用語は互換性がありません。 > - セカンダリクラスタへのデータ複製のために複数のチェンジフィードを実行したり、既にセカンダリクラスタが存在する状態で別のセカンダリクラスタを実行したりしないでください。そうしないと、セカンダリクラスタのデータトランザクションの整合性が保証されません。 ### プライマリクラスターとセカンダリクラスターを設定する {#set-up-primary-and-secondary-clusters} diff --git a/dr-solution-introduction.md b/dr-solution-introduction.md index 36c907ad456dc..1392900e0bdd3 100644 --- a/dr-solution-introduction.md +++ b/dr-solution-introduction.md @@ -63,7 +63,7 @@ TiDBのバックアップおよび復元ツールとして、 BRは特定の時 ![Primary-secondary cluster DR](/media/dr/ticdc-dr.png) -前述のアーキテクチャは、2つのTiDBクラスタで構成されています。クラスタ1はリージョン1で動作し、読み取りおよび書き込み要求を処理します。クラスタ2はリージョン2で動作し、セカンダリクラスタとして機能します。クラスタ1で障害が発生した場合、クラスタ2がサービスを引き継ぎます。データ変更は、TiCDCを使用して2つのクラスタ間で複製されます。このアーキテクチャは、「1対1」の災害復旧ソリューションとも呼ばれます。 +前述のアーキテクチャは、2つのTiDBクラスタで構成されています。クラスタ1はリージョン1で動作し、読み取りおよび書き込み要求を処理します。クラスタ2はリージョン2で動作し、セカンダリクラスタとして機能します。クラスタ1で障害が発生した場合、クラスタ2がサービスを引き継ぎます。データ変更は、TiCDCを使用して2つのクラスタ間で複製されます。このアーキテクチャは、"1:1"の災害復旧ソリューションとも呼ばれます。 このアーキテクチャはシンプルで可用性が高く、領域レベルのエラー許容目標、スケーラブルな書き込み機能、秒単位の RPO、分単位以下の RTO を備えています。本番システムで RPO をゼロにする必要がない場合は、この DR ソリューションをお勧めします。このソリューションの詳細については、[プライマリおよびセカンダリクラスタに基づくDRソリューション](/dr-secondary-cluster.md)を参照してください。 @@ -71,7 +71,7 @@ TiDBのバックアップおよび復元ツールとして、 BRは特定の時 ![Multi-replica cluster DR](/media/dr/multi-replica-dr.png) -前述のアーキテクチャでは、各リージョンに、異なるアベイラブルゾーン（AZ）に配置された2つの完全なデータレプリカがあります。クラスタ全体は3つのリージョンにまたがっています。リージョン1は、読み取りおよび書き込み要求を処理するプライマリリージョンです。リージョン1が災害により完全に利用不能になった場合、リージョン2をDRリージョンとして使用できます。リージョン3は、多数決プロトコルを満たすために使用されるレプリカです。このアーキテクチャは「2-2-1」ソリューションとも呼ばれます。 +前述のアーキテクチャでは、各リージョンに、異なるアベイラブルゾーン（AZ）に配置された2つの完全なデータレプリカがあります。クラスタ全体は3つのリージョンにまたがっています。リージョン1は、読み取りおよび書き込み要求を処理するプライマリリージョンです。リージョン1が災害により完全に利用不能になった場合、リージョン2をDRリージョンとして使用できます。リージョン3は、多数決プロトコルを満たすために使用されるレプリカです。このアーキテクチャは"2-2-1"ソリューションとも呼ばれます。 このソリューションは、領域レベルのエラー耐性、スケーラブルな書き込み機能、ゼロ RPO、分単位以下の RTO を提供します。本番システムでゼロ RPO が必要な場合は、この DR ソリューションを使用することをお勧めします。このソリューションの詳細については、[単一クラスター内の複数のレプリカに基づく災害復旧ソリューション](/dr-multi-replica.md)を参照してください。 @@ -83,9 +83,9 @@ TiDBのバックアップおよび復元ツールとして、 BRは特定の時 前述のアーキテクチャでは、TiDBクラスタは2つ存在します。クラスタ1は、3つのリージョンにまたがる5つのレプリカで構成されています。リージョン1には、プライマリリージョンとして機能し、書き込みリクエストを処理する2つのレプリカがあります。リージョン2には、リージョン1のDRリージョンとして機能する2つのレプリカがあります。このリージョンは、レイテンシーの影響を受けにくい読み取りサービスを提供します。リージョン3にある最後のレプリカは、投票に使用されます。 -リージョン1とリージョン2のDRクラスタとして、クラスタ2はリージョン3で稼働し、3つのレプリカを含みます。TiCDCはクラスタ1からデータを複製します。このアーキテクチャは複雑に見えますが、複数のリージョンに対するエラー許容目標を高めることができます。複数のリージョンが同時に利用不能になった場合にRPOがゼロである必要がない場合は、このアーキテクチャは良い選択肢です。このアーキテクチャは「2-2-1:1」ソリューションとも呼ばれます。 +リージョン1とリージョン2のDRクラスタとして、クラスタ2はリージョン3で稼働し、3つのレプリカを含みます。TiCDCはクラスタ1からデータを複製します。このアーキテクチャは複雑に見えますが、複数のリージョンに対するエラー許容目標を高めることができます。複数のリージョンが同時に利用不能になった場合にRPOがゼロである必要がない場合は、このアーキテクチャは良い選択肢です。このアーキテクチャは"2-2-1:1"ソリューションとも呼ばれます。 -もちろん、エラー許容範囲が複数のリージョンに及び、RPOがゼロでなければならない場合は、5つのリージョンにまたがる少なくとも9つのレプリカを持つクラスターを作成することも検討できます。このアーキテクチャは「2-2-2-2-1」ソリューションとも呼ばれます。 +もちろん、エラー許容範囲が複数のリージョンに及び、RPOがゼロでなければならない場合は、5つのリージョンにまたがる少なくとも9つのレプリカを持つクラスターを作成することも検討できます。このアーキテクチャは"2-2-2-2-1"ソリューションとも呼ばれます。 ### BRに基づくDRソリューション {#dr-solution-based-on-br} diff --git a/dumpling-overview.md b/dumpling-overview.md index 64f71f9d85e2f..40b151d855f92 100644 --- a/dumpling-overview.md +++ b/dumpling-overview.md @@ -284,7 +284,7 @@ Dumpling、 `-B`オプションを使用して特定のデータベースをエ > > データ整合性オプションのデフォルト値は`auto`です。ほとんどの場合、 Dumplingのデフォルトのデータ整合性オプションを調整する必要はありません。 -Dumpling は`--consistency `オプションを使用して、「一貫性の保証」のためにデータをエクスポートする方法を制御します。スナップショットを使用して一貫性を確保する場合、 `--snapshot`オプションを使用してバックアップするタイムスタンプを指定できます。また、次のレベルの一貫性も使用できます。 +Dumpling は`--consistency `オプションを使用して、"consistency assurance"のためにデータをエクスポートする方法を制御します。スナップショットを使用して一貫性を確保する場合、 `--snapshot`オプションを使用してバックアップするタイムスタンプを指定できます。また、次のレベルの一貫性も使用できます。 - `flush` : [`FLUSH TABLES WITH READ LOCK`](https://dev.mysql.com/doc/refman/8.0/en/flush.html#flush-tables-with-read-lock)を使用すると、レプリカ データベースの DML および DDL 操作を一時的に中断し、バックアップ 接続のグローバルな一貫性を確保し、binlog位置 (POS) 情報を記録できます。ロックは、すべてのバックアップ 接続がトランザクションを開始すると解放されます。フルバックアップは、ピーク時以外の時間帯、または MySQL レプリカ データベースで実行することをお勧めします。TiDB はこの値をサポートしていないことに注意してください。 - `snapshot` : 指定されたタイムスタンプの一貫性のあるスナップショットを取得し、エクスポートします。 @@ -362,7 +362,7 @@ SET GLOBAL tidb_gc_life_time = '10m'; | `-T`または`--tables-list` | 指定したテーブルをエクスポートします | | | `-f`または`--filter` | フィルター パターンに一致するテーブルをエクスポートします。フィルターの構文については、[テーブルフィルター](/table-filter.md)を参照してください。 | `[\*.\*,!/^(mysql|sys|INFORMATION_SCHEMA|PERFORMANCE_SCHEMA|METRICS_SCHEMA|INSPECTION_SCHEMA)$/.\*]` （システムスキーマを除くすべてのデータベースまたはテーブルをエクスポート） | | `--case-sensitive` | テーブルフィルターが大文字と小文字を区別するかどうか | 偽（大文字小文字を区別しない） | -| `-h`または`--host` | 接続されたデータベースホストのIPアドレス | 「127.0.0.1」 | +| `-h`または`--host` | 接続されたデータベースホストのIPアドレス | "127.0.0.1" | | `-t`または`--threads` | 同時バックアップスレッド数 | 4 | | `-r`または`--rows` | テーブル内同時実行を有効にすると、エクスポートが高速化されます。デフォルト値は`0`で、無効を意味します。0 より大きい値は有効を意味し、値は`INT`型です。ソースデータベースが TiDB の場合、0 より大きい`-r`値は、TiDB リージョン情報が分割に使用され、メモリ使用量が削減されることを示します。特定の`-r`値は、分割アルゴリズムに影響しません。ソースデータベースが MySQL で、主キーまたは複合主キーの最初の列が`INT`型の場合、 `-r`を指定することで、テーブル内同時実行を有効にすることもできます。 | | | `-L`または`--logfile` | ログ出力アドレス。空欄の場合は、ログはコンソールに出力されます。 | 「」 | @@ -374,10 +374,10 @@ SET GLOBAL tidb_gc_life_time = '10m'; | `-m`または`--no-schemas` | データのみをエクスポートしてスキーマをエクスポートしないでください。 | | | `-s`または`--statement-size` | `INSERT`文のサイズを制御します。単位はバイトです。 | | | `-F`または`--filesize` | 分割されたテーブルのファイルサイズ。単位は`128B` 、 `64KiB` 、 `32MiB` 、 `1.5GiB`のように指定する必要があります。 | | -| `--filetype` | エクスポートされたファイル形式（csv/sql） | 「sql」 | +| `--filetype` | エクスポートされたファイル形式（csv/sql） | "sql" | | `-o`または`--output` | データのエクスポートに使用する絶対ローカルファイルパス、または[外部ストレージURI](/external-storage-uri.md)を指定してください。 | "./export-${time}" | | `-S`または`--sql` | 指定されたSQL文に従ってデータをエクスポートします。このコマンドは同時エクスポートをサポートしていません。 | | -| `--consistency` | フラッシュ: ダンプの前にFTWRLを使用してください
スナップショット: TSO の特定のスナップショットの TiDB データをダンプします
ロック: ダンプ対象のすべてのテーブルに対して`lock tables read`を実行します
none: ロックを追加せずにダンプします。これは一貫性を保証できません。
auto: MySQL の場合は --consistency flush を使用し、TiDB の場合は --consistency snapshot を使用します。 | 「自動」 | +| `--consistency` | フラッシュ: ダンプの前にFTWRLを使用してください
スナップショット: TSO の特定のスナップショットの TiDB データをダンプします
ロック: ダンプ対象のすべてのテーブルに対して`lock tables read`を実行します
none: ロックを追加せずにダンプします。これは一貫性を保証できません。
auto: MySQL の場合は --consistency flush を使用し、TiDB の場合は --consistency snapshot を使用します。 | "auto" | | `--snapshot` | スナップショットTSO。 `consistency=snapshot`の場合のみ有効。 | | | `--where` | `where`条件を使用して、テーブルバックアップの範囲を指定します。 | | | `-p`または`--password` | 接続先のデータベースホストのパスワード | | diff --git a/encryption-at-rest.md b/encryption-at-rest.md index 2077e4c4c1ef5..599d1840a8689 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -323,9 +323,9 @@ server_configs: security.encryption.data-key-rotation-period: "168h" # 7 days ``` -`data-encryption-method`に指定できる値は、「aes128-ctr」、「aes192-ctr」、「aes256-ctr」、「sm4-ctr」（v6.4.0 以降のみ）、「plaintext」です。デフォルト値は「plaintext」で、暗号化は無効です。`data-key-rotation-period`は、TiFlash がデータキーをローテーションする頻度を定義します。暗号化は、新規TiFlashクラスターまたは既存のTiFlashクラスターで有効にできますが、暗号化が有効になった後に書き込まれたデータのみが暗号化されることが保証されます。暗号化を無効にするには、設定ファイルの`data-encryption-method`を削除するか、「plaintext」にリセットし、 TiFlashを再起動します。暗号化方式を変更するには、設定ファイルの`data-encryption-method`を更新し、 TiFlash を再起動します。暗号化アルゴリズムを変更するには、 `data-encryption-method`をサポートされている暗号化アルゴリズムに置き換え、 TiFlash を再起動します。置き換え後、新しいデータが書き込まれると、以前の暗号化アルゴリズムで生成された暗号化ファイルは、新しい暗号化アルゴリズムで生成されたファイルに徐々に書き換えられます。 +`data-encryption-method`に指定できる値は、"aes128-ctr"、"aes192-ctr"、"aes256-ctr"、"sm4-ctr"（v6.4.0 以降のみ）、"plaintext"です。デフォルト値は"plaintext"で、暗号化は無効です。`data-key-rotation-period`は、TiFlash がデータキーをローテーションする頻度を定義します。暗号化は、新規TiFlashクラスターまたは既存のTiFlashクラスターで有効にできますが、暗号化が有効になった後に書き込まれたデータのみが暗号化されることが保証されます。暗号化を無効にするには、設定ファイルの`data-encryption-method`を削除するか、"plaintext"にリセットし、 TiFlashを再起動します。暗号化方式を変更するには、設定ファイルの`data-encryption-method`を更新し、 TiFlash を再起動します。暗号化アルゴリズムを変更するには、 `data-encryption-method`をサポートされている暗号化アルゴリズムに置き換え、 TiFlash を再起動します。置き換え後、新しいデータが書き込まれると、以前の暗号化アルゴリズムで生成された暗号化ファイルは、新しい暗号化アルゴリズムで生成されたファイルに徐々に書き換えられます。 -暗号化が有効になっている場合（つまり、 `data-encryption-method`が「プレーンテキスト」ではない場合）、マスターキーを指定する必要があります。AWS KMS CMK をマスターキーとして指定するには、 `tiflash-learner.toml`設定ファイルの`encryption`セクションの後に`encryption.master-key`セクションを追加します。 +暗号化が有効になっている場合（つまり、 `data-encryption-method`が"plaintext"ではない場合）、マスターキーを指定する必要があります。AWS KMS CMK をマスターキーとして指定するには、 `tiflash-learner.toml`設定ファイルの`encryption`セクションの後に`encryption.master-key`セクションを追加します。 ``` [security.encryption.master-key] diff --git a/error-codes.md b/error-codes.md index 0e17524d51602..99d6fcf8b63bf 100644 --- a/error-codes.md +++ b/error-codes.md @@ -579,7 +579,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 > **Note:** > - > 「30m」は、30分前に生成されたデータのみをクリーンアップすることを意味します。これにより、追加のストレージスペースが消費される可能性があります。 + > "30m"は、30分前に生成されたデータのみをクリーンアップすることを意味します。これにより、追加のストレージスペースが消費される可能性があります。 - エラー番号: 9500 diff --git a/explain-joins.md b/explain-joins.md index 1e3368e7e6684..a64fdb802312e 100644 --- a/explain-joins.md +++ b/explain-joins.md @@ -283,4 +283,4 @@ EXPLAIN SELECT /*+ MERGE_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; 1. Join Group のすべてのデータを`Build`側からメモリに読み込みます。 2. `Probe`面のデータを読み取ります。 -3. `Probe`側の各データ行が`Build`側の結合グループと完全に一致するかどうかを比較します。等価条件の他に、非等価条件もあります。ここでの「一致」とは、主に非等価条件が満たされているかどうかの確認を指します。結合グループとは、すべての結合キーの中で同じ値を持つデータを指します。 +3. `Probe`側の各データ行が`Build`側の結合グループと完全に一致するかどうかを比較します。等価条件の他に、非等価条件もあります。ここでの"match"とは、主に非等価条件が満たされているかどうかの確認を指します。結合グループとは、すべての結合キーの中で同じ値を持つデータを指します。 diff --git a/faq/upgrade-faq.md b/faq/upgrade-faq.md index ab473162c59e9..f35b4d523d186 100644 --- a/faq/upgrade-faq.md +++ b/faq/upgrade-faq.md @@ -102,7 +102,7 @@ alter table t change column a a varchar(22) character set utf8; - ポイント 1 によると、列の文字セットを指定しない場合はデフォルトで UTF8MB4 が使用されるため、元の文字セットと一致するように列の文字セットを指定する必要があります。 -- ポイント 2 によれば、HTTP API を介してテーブルのメタデータを取得し、列名とキーワード「Charset」を検索することで列の文字セットを見つけることができます。 +- ポイント 2 によれば、HTTP API を介してテーブルのメタデータを取得し、列名とキーワード"Charset"を検索することで列の文字セットを見つけることができます。 ```sh curl "http://$IP:10080/schema/test/t" | python -m json.tool diff --git a/filter-dml-event.md b/filter-dml-event.md index aa5ffeb563cac..89a13400c0c73 100644 --- a/filter-dml-event.md +++ b/filter-dml-event.md @@ -66,7 +66,7 @@ MySQL [test]> select * from tbl; > **Note:** > > - `update-old-value-expr`と`update-new-value-expr`を一緒に設定できます。 -> - `update-old-value-expr`と`update-new-value-expr`が一緒に設定されている場合、「更新 + 古い値」が`update-old-value-expr`に一致し、「更新 + 新しい値」が`update-new-value-expr`に一致する行がフィルタリングされます。 +> - `update-old-value-expr`と`update-new-value-expr`が一緒に設定されている場合、"update + old values"が`update-old-value-expr`に一致し、"update + new values"が`update-new-value-expr`に一致する行がフィルタリングされます。 > - `update-old-value-expr`と`update-new-value-expr`のいずれかが設定されている場合、設定された式によって**行の変更全体**をフィルタリングするかどうかが決定されます。つまり、古い値の削除と新しい値の挿入が全体としてフィルタリングされます。 SQL式は1つの列でも複数の列でも使用できます。また、TiDBでサポートされているSQL関数（ `c % 2 = 0` 、 `a*a + b*b = c*c` 、 `ts > NOW()`など）も使用できます。 diff --git a/foreign-key.md b/foreign-key.md index 137859b4c0ffb..a8f033d54a589 100644 --- a/foreign-key.md +++ b/foreign-key.md @@ -330,7 +330,7 @@ Create Table | CREATE TABLE `child` ( 外部キーを作成する際に名前を指定しない場合、TiDB によって生成される名前は MySQL によって生成される名前とは異なります。たとえば、TiDB によって生成される外部キー名は`fk_1` 、 `fk_2` 、 `fk_3`ですが、MySQL によって生成される外部キー名は`table_name_ibfk_1` 、 `table_name_ibfk_2` 、 `table_name_ibfk_3`です。 -MySQLとTiDBはどちらも「インライン`REFERENCES`仕様」を解析しますが、無視します。 `REFERENCES`定義の一部である`FOREIGN KEY`仕様のみがチェックされ、適用されます。次の例では`REFERENCES`句を使用して外部キー制約を作成します。 +MySQLとTiDBはどちらも"inline `REFERENCES` specifications"を解析しますが、無視します。 `REFERENCES`定義の一部である`FOREIGN KEY`仕様のみがチェックされ、適用されます。次の例では`REFERENCES`句を使用して外部キー制約を作成します。 ```sql CREATE TABLE parent ( diff --git a/functions-and-operators/aggregate-group-by-functions.md b/functions-and-operators/aggregate-group-by-functions.md index 21c09cfa6ed66..58e6b311ac3a0 100644 --- a/functions-and-operators/aggregate-group-by-functions.md +++ b/functions-and-operators/aggregate-group-by-functions.md @@ -93,7 +93,7 @@ TiDB v7.4.0以降、 `GROUP BY`句は`WITH ROLLUP`修飾子をサポートしま ## SQLモードのサポート {#sql-mode-support} -TiDBはSQLモード`ONLY_FULL_GROUP_BY`をサポートしており、有効にすると、曖昧な非集計列を含むクエリを拒否します。例えば、次のクエリは`ONLY_FULL_GROUP_BY`が有効になっていると無効になります。`SELECT`のリストにある非集計列「b」が`GROUP BY`ステートメントに含まれていないためです。 +TiDBはSQLモード`ONLY_FULL_GROUP_BY`をサポートしており、有効にすると、曖昧な非集計列を含むクエリを拒否します。例えば、次のクエリは`ONLY_FULL_GROUP_BY`が有効になっていると無効になります。`SELECT`のリストにある非集計列"b"が`GROUP BY`ステートメントに含まれていないためです。 ```sql drop table if exists t; @@ -121,7 +121,7 @@ TiDB は現在、デフォルトで[`ONLY_FULL_GROUP_BY`](/mysql-compatibility.m ### MySQLとの違い {#differences-from-mysql} -`ONLY_FULL_GROUP_BY`の現在の実装は、 MySQL 5.7の実装よりも厳密ではありません。例えば、結果が「c」で順序付けられることを期待して、次のクエリを実行するとします。 +`ONLY_FULL_GROUP_BY`の現在の実装は、 MySQL 5.7の実装よりも厳密ではありません。例えば、結果が"c"で順序付けられることを期待して、次のクエリを実行するとします。 ```sql drop table if exists t; @@ -130,7 +130,7 @@ insert into t values(1, 2, 1), (1, 2, 2), (1, 3, 1), (1, 3, 2); select distinct a, b from t order by c; ``` -結果を順序付けるには、まず重複を排除する必要があります。しかし、そのためにはどの行を保持すべきでしょうか？ この選択は「c」の保持値に影響し、さらに順序付けにも影響を与え、結果的に順序付けを恣意的なものにしてしまいます。 +結果を順序付けるには、まず重複を排除する必要があります。しかし、そのためにはどの行を保持すべきでしょうか？ この選択は"c"の保持値に影響し、さらに順序付けにも影響を与え、結果的に順序付けを恣意的なものにしてしまいます。 MySQL では、 `DISTINCT`と`ORDER BY`含むクエリは、 `ORDER BY`式のいずれかが以下の条件の少なくとも 1つを満たしていない場合、無効として拒否されます。 @@ -139,7 +139,7 @@ MySQL では、 `DISTINCT`と`ORDER BY`含むクエリは、 `ORDER BY`式のい しかし、TiDB では上記のクエリは有効です。詳細については、 [#4254](https://github.com/pingcap/tidb/issues/4254)を参照してください。 -標準SQLに対するTiDBのもう一つの拡張機能は、 `HAVING`句で`SELECT`リスト内のエイリアス式を参照することを許可します。例えば、次のクエリはテーブル「orders」に一度だけ出現する「name」の値を返します。 +標準SQLに対するTiDBのもう一つの拡張機能は、 `HAVING`句で`SELECT`リスト内のエイリアス式を参照することを許可します。例えば、次のクエリはテーブル"orders"に一度だけ出現する"name"の値を返します。 ```sql select name, count(name) from orders @@ -155,7 +155,7 @@ group by name having c = 1; ``` -標準 SQL では、 `GROUP BY`句で列式のみが許可されるため、次のようなステートメントは、「FLOOR(value/100)」が非列式であるため無効です。 +標準 SQL では、 `GROUP BY`句で列式のみが許可されるため、次のようなステートメントは、"FLOOR(value/100)"が非列式であるため無効です。 ```sql select id, floor(value/100) diff --git a/functions-and-operators/date-and-time-functions.md b/functions-and-operators/date-and-time-functions.md index 42af49f9d401d..78f7f608eda54 100644 --- a/functions-and-operators/date-and-time-functions.md +++ b/functions-and-operators/date-and-time-functions.md @@ -52,7 +52,7 @@ TiDB は、MySQL 8.0 で利用可能な[日付と時刻関数](https://dev.mysql | [`PERIOD_ADD()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_period-add) | 年月にピリオドを追加する | | [`PERIOD_DIFF()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_period-diff) | 期間間の月数を返す | | [`QUARTER()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_quarter) | 日付引数から四半期を返す | -| [`SEC_TO_TIME()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_sec-to-time) | 秒を「HH:MM:SS」形式に変換します | +| [`SEC_TO_TIME()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_sec-to-time) | 秒を"HH:MM:SS"形式に変換します | | [`SECOND()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_second) | 秒を返す（0～59） | | [`STR_TO_DATE()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_str-to-date) | 文字列を日付に変換する | | [`SUBDATE()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_subdate) | 3つの引数で呼び出された場合のDATE_SUB()の同義語 | @@ -85,15 +85,15 @@ TiDB は、MySQL 8.0 で利用可能な[日付と時刻関数](https://dev.mysql | 形式 | 説明 | | -------------- | -------------------------------------------------- | -| 「%a」 | 曜日の略称（日～土） | -| 「%D」 | 英語の接尾辞付きの月日（0日、1日、2日、3日） | -| 「%U」 | 週（00..53）、日曜日が週の最初の日です。WEEK() モード 0 | +| "%a" | 曜日の略称（日～土） | +| "%D" | 英語の接尾辞付きの月日（0日、1日、2日、3日） | +| "%U" | 週（00..53）、日曜日が週の最初の日です。WEEK() モード 0 | | "%u" | 週（00..53）、月曜日が週の最初の日です。WEEK() モード 1 | -| 「%V」 | 週（01..53）、日曜日が週の最初の日です。WEEK() モード 2。%X とともに使用されます。 | -| 「%v」 | 週（01..53）、月曜日が週の最初の日です。WEEK() モード 3。%x とともに使用されます。 | -| 「%W」 | 曜日名（日曜日..土曜日） | +| "%V" | 週（01..53）、日曜日が週の最初の日です。WEEK() モード 2。%X とともに使用されます。 | +| "%v" | 週（01..53）、月曜日が週の最初の日です。WEEK() モード 3。%x とともに使用されます。 | +| "%W" | 曜日名（日曜日..土曜日） | | "%w" | 曜日（0=日曜日、6=土曜日） | -| 「%X」 | 日曜日を週の最初の日とする週の年を 4 桁の数字で表します。 | +| "%X" | 日曜日を週の最初の日とする週の年を 4 桁の数字で表します。 | | "%x" | 週の年。月曜日を週の最初の日とする、数字 4 桁。 | 詳細は[問題 #30082](https://github.com/pingcap/tidb/issues/30082)ご覧ください。 diff --git a/functions-and-operators/precision-math.md b/functions-and-operators/precision-math.md index b0f5a2ba7dbb7..c81ac5274b5f4 100644 --- a/functions-and-operators/precision-math.md +++ b/functions-and-operators/precision-math.md @@ -106,7 +106,7 @@ INSERT INTO t SET i = 1/0; `ROUND()`関数の結果は、その引数が正確か近似かによって異なります。 -- 正確な数値の場合、 `ROUND()`関数は「半分を切り上げる」ルールを使用します。 +- 正確な数値の場合、 `ROUND()`関数は"round half up"ルールを使用します。 - 近似値の数値の場合、TiDB の結果は MySQL の結果と異なります。 ```sql diff --git a/garbage-collection-overview.md b/garbage-collection-overview.md index 6af76a281e13d..31dee64090f20 100644 --- a/garbage-collection-overview.md +++ b/garbage-collection-overview.md @@ -11,7 +11,7 @@ TiDBはMVCCを使用してトランザクションの同時実行を制御しま 各 TiDB クラスターには、GC プロセスを制御する GC リーダーとして選択される TiDB インスタンスが含まれています。 -TiDBでは、GCが定期的に実行されます。GCごとに、TiDBはまず「セーフポイント」と呼ばれるタイムスタンプを計算します。次に、セーフポイント以降のすべてのスナップショットがデータの整合性を保持しているという前提で、TiDBは古いデータをクリアします。具体的には、各GCプロセスには以下の3つのステップが含まれます。 +TiDBでは、GCが定期的に実行されます。GCごとに、TiDBはまず"safe point"と呼ばれるタイムスタンプを計算します。次に、セーフポイント以降のすべてのスナップショットがデータの整合性を保持しているという前提で、TiDBは古いデータをクリアします。具体的には、各GCプロセスには以下の3つのステップが含まれます。 1. ロックを解決します。このステップでは、TiDB はすべてのリージョンのセーフポイントの前のロックをスキャンし、これらのロックをクリアします。 2. 範囲を削除します。このステップでは、 `DROP TABLE` / `DROP INDEX`操作で生成された範囲全体の古いデータがすぐにクリアされます。 diff --git a/glossary.md b/glossary.md index dc08033492149..da9dc7d53b276 100644 --- a/glossary.md +++ b/glossary.md @@ -209,7 +209,7 @@ TiDBはv5.0以降、 TiFlashノードを介して大規模並列処理（MPP） ### 元の値（Old value） {#old-value} -TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出力する増分変更ログに「元の値」を含めるかどうかを指定できます。 +TiCDCが出力する増分変更ログにおける"original value"。TiCDCが出力する増分変更ログに"original value"を含めるかどうかを指定できます。 ### オンライン分析処理（OLAP） {#online-analytical-processing-olap} @@ -260,7 +260,7 @@ PD Control (pd-ctl) は、TiDB クラスタ内の Placement Driver (PD) と対 ### 保留中／ダウン中（Pending/Down） {#pendingdown} -「保留中」と「ダウン」は、ピアの2つの特別な状態です。「保留中」とは、フォロワーまたはラーナーのRaftログがリーダーのログと大きく異なる状態を指します。保留中のフォロワーはリーダーに選出されません。「ダウン」とは、ピアが長時間リーダーに応答しなくなった状態を指し、通常は対応するノードがダウンしているか、ネットワークから孤立していることを意味します。 +"Pending"と"Down"は、ピアの2つの特別な状態です。"Pending"とは、フォロワーまたはラーナーのRaftログがリーダーのログと大きく異なる状態を指します。保留中のフォロワーはリーダーに選出されません。"Down"とは、ピアが長時間リーダーに応答しなくなった状態を指し、通常は対応するノードがダウンしているか、ネットワークから孤立していることを意味します。 ### Placement Driver（PD） {#placement-driver-pd} diff --git a/grafana-overview-dashboard.md b/grafana-overview-dashboard.md index 9dc53d9565390..5082ffb21146f 100644 --- a/grafana-overview-dashboard.md +++ b/grafana-overview-dashboard.md @@ -9,7 +9,7 @@ TiUPを使用してTiDBクラスターをデプロイする場合、監視シス Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、Disk Performance、Performance_overviewといった一連のサブダッシュボードに分かれています。診断に役立つ多くの指標が用意されています。 -日常的な運用では、主要なメトリクスが表示される「概要」ダッシュボードから、コンポーネント（PD、TiDB、TiKV）のステータスとクラスタ全体の概要を確認できます。このドキュメントでは、これらの主要なメトリクスについて詳しく説明します。 +日常的な運用では、主要なメトリクスが表示される"Overview"ダッシュボードから、コンポーネント（PD、TiDB、TiKV）のステータスとクラスタ全体の概要を確認できます。このドキュメントでは、これらの主要なメトリクスについて詳しく説明します。 ## 主要な指標の説明 {#key-metrics-description} @@ -52,7 +52,7 @@ Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、 | TiKV | メモリ | 各 TiKV ノードのメモリ使用量。 | | | TiKV | ストアサイズ | 各 TiKV インスタンスによって使用されるストレージスペースのサイズ。 | | | TiKV | cfサイズ | 各カラムファミリー(略して CF) のサイズ。 | | -| TiKV | チャネルフル | 各 TiKV インスタンスでの「チャネルフル」エラーの数。 | 0 | +| TiKV | チャネルフル | 各 TiKV インスタンスでの"channel full"エラーの数。 | 0 | | TiKV | サーバーレポートの失敗 | 各 TiKV インスタンスによって報告されたエラーメッセージの数。 | 0 | | TiKV | スケジューラ保留コマンド | 各 TiKV インスタンス上の保留中のコマンドの数。 | | | TiKV | コプロセッサ実行者数 | TiKVが1秒あたりに受信したコプロセッサ操作の数。コプロセッサの種類ごとに個別にカウントされます。 | | diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 9a115db984343..810565ff81fcc 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -45,7 +45,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - 接続数: 各 TiDB インスタンスに接続されているクライアントの数 - オープンFDカウント: 各TiDBインスタンスのオープンファイルディスクリプタの統計 - 切断数: 各 TiDB インスタンスから切断されたクライアントの数 -- イベント OPM: 「開始」、「終了」、「正常シャットダウン」、「強制終了」、「ハング」などの主要なイベントの統計 +- イベント OPM: "start"、"close"、"graceful-shutdown"、"kill"、"hang"などの主要なイベントの統計 - Goroutine 数: 各 TiDB インスタンス上の Goroutine の数 - プリペアドステートメント数: 各 TiDB インスタンスで実行される`Prepare`のステートメントの数とその合計数 - Keep Alive OPM: 各TiDBインスタンスで毎分メトリクスが更新される回数。通常は注意する必要はありません。 diff --git a/identify-expensive-queries.md b/identify-expensive-queries.md index 8a5e62fd4e07c..df0c35f30507d 100644 --- a/identify-expensive-queries.md +++ b/identify-expensive-queries.md @@ -5,7 +5,7 @@ summary: TiDBは、実行時間またはメモリ使用量のしきい値を超 # コストの高いクエリを特定する {#identify-expensive-queries} -TiDBを使用すると、SQL実行中に高負荷なクエリを特定できるため、SQL実行のパフォーマンスを診断・改善できます。具体的には、実行時間が[`tidb_expensive_query_time_threshold`](/system-variables.md#tidb_expensive_query_time_threshold) （デフォルトでは60秒）を超える、またはメモリ使用量が[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) （デフォルトでは1GB）を超えるステートメントに関する情報が、 [tidb-server ログファイル](/tidb-configuration-file.md#logfile) （デフォルトでは「tidb.log」）に出力されます。 +TiDBを使用すると、SQL実行中に高負荷なクエリを特定できるため、SQL実行のパフォーマンスを診断・改善できます。具体的には、実行時間が[`tidb_expensive_query_time_threshold`](/system-variables.md#tidb_expensive_query_time_threshold) （デフォルトでは60秒）を超える、またはメモリ使用量が[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) （デフォルトでは1GB）を超えるステートメントに関する情報が、 [tidb-server ログファイル](/tidb-configuration-file.md#logfile) （デフォルトでは"tidb.log"）に出力されます。 > **Note:** > diff --git a/identify-slow-queries.md b/identify-slow-queries.md index 3b4894e310369..ba995fab66a90 100644 --- a/identify-slow-queries.md +++ b/identify-slow-queries.md @@ -5,7 +5,7 @@ summary: スロークエリログを使用して、問題のあるSQL文を特 # スロークエリを特定する {#identify-slow-queries} -ユーザーがスロークエリを特定し、SQL実行のパフォーマンスを分析および改善できるように、TiDBは実行時間が[`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold) （デフォルト値は300ミリ秒）を超えるステートメントを[スロークエリファイル](/tidb-configuration-file.md#slow-query-file)ファイル（デフォルト値は「tidb-slow.log」）に出力します。 +ユーザーがスロークエリを特定し、SQL実行のパフォーマンスを分析および改善できるように、TiDBは実行時間が[`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold) （デフォルト値は300ミリ秒）を超えるステートメントを[スロークエリファイル](/tidb-configuration-file.md#slow-query-file)ファイル（デフォルト値は"tidb-slow.log"）に出力します。 TiDBはデフォルトでスロークエリログを有効にしています。システム変数[`tidb_enable_slow_log`](/system-variables.md#tidb_enable_slow_log)を変更することで、この機能を有効または無効にできます。 diff --git a/index-advisor.md b/index-advisor.md index b96e1def964c9..1f87621e42f1d 100644 --- a/index-advisor.md +++ b/index-advisor.md @@ -11,7 +11,7 @@ TiDB v8.5.0では、クエリパフォーマンスを向上させるインデッ > > 現在、この機能は[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)インスタンスではご利用いただけません。 -インデックスアドバイザーは、クエリを分析して、 `WHERE` 、 `GROUP BY` 、 `ORDER BY`などの句からインデックス可能な列を特定します。次に、インデックス候補を生成し、仮想インデックスを使用してパフォーマンス上のメリットを推定します。TiDB は、遺伝的探索アルゴリズムを使用して最適なインデックスセットを選択します。まず単一列のインデックスから始め、複数列のインデックスを反復的に探索し、「What-If」分析を活用して、オプティマイザ プランのコストへの影響に基づいて潜在的なインデックスを評価します。アドバイザーは、インデックスを使用せずにクエリを実行する場合と比較して、インデックスによって全体のコストが削減される場合に、インデックスを推奨します。 +インデックスアドバイザーは、クエリを分析して、 `WHERE` 、 `GROUP BY` 、 `ORDER BY`などの句からインデックス可能な列を特定します。次に、インデックス候補を生成し、仮想インデックスを使用してパフォーマンス上のメリットを推定します。TiDB は、遺伝的探索アルゴリズムを使用して最適なインデックスセットを選択します。まず単一列のインデックスから始め、複数列のインデックスを反復的に探索し、"What-If"分析を活用して、オプティマイザ プランのコストへの影響に基づいて潜在的なインデックスを評価します。アドバイザーは、インデックスを使用せずにクエリを実行する場合と比較して、インデックスによって全体のコストが削減される場合に、インデックスを推奨します。 [新しい指標を推奨する](#recommend-indexes-using-the-recommend-index-statement)ことに加えて、インデックスアドバイザーは効率的なインデックス管理を確保するために[非アクティブなインデックスの削除](#remove-unused-indexes)も提案します。 @@ -196,7 +196,7 @@ WHERE last_access_time IS NOT NULL AND percentage_access_0 + percentage_access_0 例えば、 `/*+ HYPO_INDEX(t, idx_ab, a, b) */`コメントは、クエリプランナーに対し、 `idx_ab`テーブル上に、 `t`に対して、 `a` `b`名前の仮想インデックスを作成するように指示します。プランナーはインデックスのメタデータを生成しますが、物理的にインデックスを作成することはありません。該当する場合、プランナーはインデックス作成に伴うコストを発生させることなく、クエリ最適化中にこの仮想インデックスを考慮します。 -`RECOMMEND INDEX`アドバイザーは、仮説的なインデックスを使用して「もしも」分析を行い、さまざまなインデックスの潜在的なメリットを評価します。また、仮説的なインデックスを直接使用して、インデックスを作成する前にインデックス設計を試すこともできます。 +`RECOMMEND INDEX`アドバイザーは、仮説的なインデックスを使用して"What-If"分析を行い、さまざまなインデックスの潜在的なメリットを評価します。また、仮説的なインデックスを直接使用して、インデックスを作成する前にインデックス設計を試すこともできます。 次の例は、仮説インデックスを使用した`EXPLAIN`文を示しています。 diff --git a/information-schema/client-errors-summary-by-host.md b/information-schema/client-errors-summary-by-host.md index 711449605e661..b2c082f3d5a57 100644 --- a/information-schema/client-errors-summary-by-host.md +++ b/information-schema/client-errors-summary-by-host.md @@ -19,7 +19,7 @@ summary: "`CLIENT_ERRORS_SUMMARY_BY_HOST` INFORMATION_SCHEMA テーブルにつ - 時代遅れの MySQL クライアントライブラリ。 - 古いアプリケーション (新しいデプロイメントを展開するときにこのサーバーが見逃された可能性があります)。 -- ユーザー権限の「ホスト」部分の使用方法が間違っています。 +- ユーザー権限の"host"部分の使用方法が間違っています。 - 信頼性の低いネットワーク接続により、タイムアウトや接続切断がさらに発生します。 集計されたカウントは、ステートメント`FLUSH CLIENT_ERRORS_SUMMARY`を使用してリセットできます。集計は各 TiDBサーバーにローカルであり、メモリ内にのみ保持されます。TiDBサーバーを再起動すると、集計は失われます。 diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index 2f369f4361f93..2b10a4f6c0867 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -107,7 +107,7 @@ DETAILS | max duration of 172.16.5.40:20151 tikv rocksdb-write-duration was to - 2 行目は、クラスター内に 2つの異なる TiDB バージョンが存在することを示します。 - 3行目と4行目は、TiKVの書き込み遅延が長すぎることを示しています。予想される遅延は0.1秒以内ですが、実際の遅延は予想よりもはるかに長くなっています。 -「2020-03-26 00:03:00」から「2020-03-26 00:08:00」までなど、指定した範囲内にある問題を診断することもできます。時間範囲を指定するには、SQLヒントに`/*+ time_range() */`を指定します。次のクエリ例をご覧ください。 +"2020-03-26 00:03:00"から"2020-03-26 00:08:00"までなど、指定した範囲内にある問題を診断することもできます。時間範囲を指定するには、SQLヒントに`/*+ time_range() */`を指定します。次のクエリ例をご覧ください。 ```sql select /*+ time_range("2020-03-26 00:03:00", "2020-03-26 00:08:00") */ * from information_schema.inspection_result\G @@ -250,8 +250,8 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo | TiKV | 重大なエラー | tikv_critical_error_total_count | TiKV の重大なエラー。 | | TiKV | スケジューラがビジー状態 | tikv_scheduler_is_busy_total_count | TiKV スケジューラがビジー状態のため、TiKV が一時的に使用できなくなっています。 | | TiKV | コプロセッサがビジー状態 | tikv_コプロセッサがビジー状態の合計数 | TiKVコプロセッサーがビジー状態です。 | - | TiKV | チャネルがいっぱいです | tikv_チャンネルの合計数 | TiKV で「チャネルがいっぱいです」というエラーが発生します。 | - | TiKV | tikv_engine_write_stall | tikv_engine_write_stall | TiKV で「ストール」エラーが発生します。 | + | TiKV | チャネルがいっぱいです | tikv_チャンネルの合計数 | TiKV で"channel full"というエラーが発生します。 | + | TiKV | tikv_engine_write_stall | tikv_engine_write_stall | TiKV で"stall"エラーが発生します。 | - `metrics_schema.up`監視テーブルと`CLUSTER_LOG`システムテーブルを照会して、コンポーネントが再起動されているかどうかを確認します。 diff --git a/information-schema/information-schema-memory-usage-ops-history.md b/information-schema/information-schema-memory-usage-ops-history.md index c715120462aa0..b027cbb69fc7b 100644 --- a/information-schema/information-schema-memory-usage-ops-history.md +++ b/information-schema/information-schema-memory-usage-ops-history.md @@ -48,7 +48,7 @@ SELECT * FROM information_schema.memory_usage_ops_history; `MEMORY_USAGE_OPS_HISTORY`テーブル内の列は次のように説明されます。 - `TIME` : セッションが終了したときのタイムスタンプ。 -- `OPS` ：「セッションキル」 +- `OPS` ："SessionKill" - `MEMORY_LIMIT` : TiDB終了時のメモリ使用量制限（バイト単位）。この値はシステム変数`tidb_server_memory_limit`の値と同じです。[/system-variables.md#tidb_server_memory_limit-new-in-v640]。 - `MEMORY_CURRENT` : TiDB の現在のメモリ使用量 (バイト単位)。 - `PROCESSID` : 終了したセッションの接続 ID。 diff --git a/literal-values.md b/literal-values.md index cb1a2ff866535..d0a2436025b00 100644 --- a/literal-values.md +++ b/literal-values.md @@ -93,7 +93,7 @@ SELECT _utf8'some text'; TiDB は次の日付形式をサポートしています。 -- `'YYYY-MM-DD'`または`'YY-MM-DD'` : ここでの`-`という区切り文字は厳密ではありません。任意の句読点を使用できます。例えば、 `'2017-08-24'` 、 `'2017&08&24'` 、 `'2012@12^31'`はすべて有効な日付形式です。唯一の特別な句読点は「.」で、これは整数部と小数部を区切る小数点として扱われます。日付と時刻は`T`または空白で区切ることができます。例えば、 `2017-8-24 10:42:00`と`2017-8-24T10:42:00`は同じ日付と時刻を表します。 +- `'YYYY-MM-DD'`または`'YY-MM-DD'` : ここでの`-`という区切り文字は厳密ではありません。任意の句読点を使用できます。例えば、 `'2017-08-24'` 、 `'2017&08&24'` 、 `'2012@12^31'`はすべて有効な日付形式です。唯一の特別な句読点は"."で、これは整数部と小数部を区切る小数点として扱われます。日付と時刻は`T`または空白で区切ることができます。例えば、 `2017-8-24 10:42:00`と`2017-8-24T10:42:00`は同じ日付と時刻を表します。 - `'YYYYMMDDHHMMSS'`または`'YYMMDDHHMMSS'` : 例えば、 `'20170824104520'`と`'170824104520'`は`'2017-08-24 10:45:20'`とみなされます。ただし、 `'170824304520'`など範囲外の値を指定した場合、有効な日付として扱われません。 `YYYYMMDD HHMMSS` 、 `YYYYMMDD HH:MM:DD` 、 `YYYY-MM-DD HHMMSS`などの誤った形式は挿入に失敗することに注意してください。 - `YYYYMMDDHHMMSS`または`YYMMDDHHMMSS` : これらの形式では、一重引用符や二重引用符は使用されず、数字が使用されることに注意してください。例えば、 `20170824104520`は`'2017-08-24 10:45:20'`と解釈されます。 diff --git a/migrate-from-tidb-to-mysql.md b/migrate-from-tidb-to-mysql.md index 064df0b3123d5..02c486e6378f0 100644 --- a/migrate-from-tidb-to-mysql.md +++ b/migrate-from-tidb-to-mysql.md @@ -168,7 +168,7 @@ summary: TiDB から MySQL 互換データベースにデータを移行する - `--server` : TiCDC クラスター内の任意のノードの IP アドレス - `--sink-uri` : 下流クラスタのURI - `--changefeed-id` : チェンジフィードID、正規表現の形式でなければなりません、 `^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$` - - `--start-ts` : 変更フィードの開始タイムスタンプ。バックアップ時刻である必要があります (または[ステップ2. 全データの移行](#step-2-migrate-full-data)の「データのバックアップ」セクションの BackupTS) + - `--start-ts` : 変更フィードの開始タイムスタンプ。バックアップ時刻である必要があります (または[ステップ2. 全データの移行](#step-2-migrate-full-data)の"Back up data"セクションの BackupTS) changefeed 構成の詳細については、 [タスク設定ファイル](/ticdc/ticdc-changefeed-config.md)を参照してください。 diff --git a/migrate-small-mysql-to-tidb.md b/migrate-small-mysql-to-tidb.md index 09679f39a4048..989d15a27f5bb 100644 --- a/migrate-small-mysql-to-tidb.md +++ b/migrate-small-mysql-to-tidb.md @@ -5,7 +5,7 @@ summary: 小さなデータセットを MySQL から TiDB に移行する方法 # 小規模データセットをMySQLからTiDBに移行する {#migrate-small-datasets-from-mysql-to-tidb} -このドキュメントでは、TiDB Data Migration (DM) を使用して、MySQL から TiDB へ小規模データセットを移行する方法について説明します。移行モードは完全移行モードと増分レプリケーションモードです。このドキュメントにおける「小規模データセット」とは、1 TiB 未満のデータサイズを指します。 +このドキュメントでは、TiDB Data Migration (DM) を使用して、MySQL から TiDB へ小規模データセットを移行する方法について説明します。移行モードは完全移行モードと増分レプリケーションモードです。このドキュメントにおける"Small datasets"とは、1 TiB 未満のデータサイズを指します。 移行速度は、テーブルスキーマ内のインデックスの数、ハードウェア、ネットワーク環境などの複数の要因に応じて、30 GB/時間から 50 GB/時間まで変化します。 diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md index f601f6f18e592..251117d27b775 100644 --- a/multi-data-centers-in-one-city-deployment.md +++ b/multi-data-centers-in-one-city-deployment.md @@ -15,7 +15,7 @@ summary: 1つのリージョン内の複数のアベイラビリティゾーン 分散SQLデータベースであるTiDBは、従来のリレーショナルデータベースの優れた機能とNoSQLデータベースのスケーラビリティを兼ね備え、複数のアベイラビリティゾーン（AZ）をまたがる高可用性を実現します。このドキュメントでは、1つのリージョンに複数のAZをデプロイする方法について説明します。 -このドキュメントにおける「リージョン」という用語は地理的な領域を指し、「リージョン」はTiKVにおけるデータストレージの基本単位を指します。「AZ」はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 +このドキュメントにおける"region"という用語は地理的な領域を指し、大文字の"Region"はTiKVにおけるデータストレージの基本単位を指します。"AZ"はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 ## Raftプロトコル {#raft-protocol} diff --git a/non-transactional-dml.md b/non-transactional-dml.md index e63cb163108b6..cc86350b79020 100644 --- a/non-transactional-dml.md +++ b/non-transactional-dml.md @@ -402,7 +402,7 @@ WHERE t.c1 IS NULL; -### 非トランザクション`DELETE` 、通常の`DELETE`と同等ではない「例外的な」動作をします。 {#non-transactional-delete-has-exceptional-behavior-that-is-not-equivalent-to-ordinary-delete} +### 非トランザクション`DELETE` 、通常の`DELETE`と同等ではない"exceptional"動作をします。 {#non-transactional-delete-has-exceptional-behavior-that-is-not-equivalent-to-ordinary-delete} 非トランザクション DML文は、この DML文の元の形式と同等ではありません。次のような理由が考えられます。 diff --git a/overview.md b/overview.md index 795eb726bbcaa..f68fff15d22b6 100644 --- a/overview.md +++ b/overview.md @@ -13,7 +13,7 @@ summary: TiDBの主な機能と使用例について学びましょう。 --> -[TiDB](https://github.com/pingcap/tidb) （/'taɪdiːbi:/、「Ti」はチタンの略）は、ハイブリッドトランザクションおよび分析処理（HTAP）ワークロードをサポートするオープンソースの分散型SQLデータベースです。MySQLと互換性があり、水平スケーラビリティ、強力な一貫性、高可用性を備えています。TiDBの目標は、OLTP（オンライントランザクション処理）、OLAP（オンライン分析処理）、およびHTAPサービスを網羅するワンストップのデータベースソリューションをユーザーに提供することです。TiDBは、大規模データで高い可用性と強力な一貫性を必要とするさまざまなユースケースに適しています。 +[TiDB](https://github.com/pingcap/tidb) （/'taɪdiːbi:/、"Ti"はチタンの略）は、ハイブリッドトランザクションおよび分析処理（HTAP）ワークロードをサポートするオープンソースの分散型SQLデータベースです。MySQLと互換性があり、水平スケーラビリティ、強力な一貫性、高可用性を備えています。TiDBの目標は、OLTP（オンライントランザクション処理）、OLAP（オンライン分析処理）、およびHTAPサービスを網羅するワンストップのデータベースソリューションをユーザーに提供することです。TiDBは、大規模データで高い可用性と強力な一貫性を必要とするさまざまなユースケースに適しています。 TiDB Self-Managedは、TiDBの製品オプションの一つであり、ユーザーおよび組織が独自のインフラストラクチャ上にTiDBを柔軟にデプロイおよび管理できます。TiDB Self-Managedを利用することで、オープンソースの分散SQLデータベースの利点を活かしながら、環境を完全に制御できます。 diff --git a/partitioned-table.md b/partitioned-table.md index da5232cf85d7f..a11f75b037ad4 100644 --- a/partitioned-table.md +++ b/partitioned-table.md @@ -579,7 +579,7 @@ CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE) PARTITIONS 4; ``` -`t1`にデータ行を挿入し、 `col3`の値が「2005-09-15」である場合、この行はパーティション1に挿入されます。 +`t1`にデータ行を挿入し、 `col3`の値が"2005-09-15"である場合、この行はパーティション1に挿入されます。 ``` MOD(YEAR('2005-09-01'),4) diff --git a/password-management.md b/password-management.md index d2b499eb9b420..6b63a7a41c711 100644 --- a/password-management.md +++ b/password-management.md @@ -264,9 +264,9 @@ TiDB は、グローバルレベルとアカウント レベルでの自動パ ### 期限切れのパスワードの処理 {#handle-an-expired-password} -パスワードの有効期限切れに関するTiDBサーバーの動作を制御できます。パスワードの有効期限が切れると、サーバーはクライアントを切断するか、クライアントを「サンドボックスモード」に制限します。「サンドボックスモード」では、TiDBサーバーは期限切れのアカウントからの接続を許可します。ただし、この接続では、ユーザーはパスワードのリセットのみを実行できます。 +パスワードの有効期限切れに関するTiDBサーバーの動作を制御できます。パスワードの有効期限が切れると、サーバーはクライアントを切断するか、クライアントを"sandbox mode"に制限します。"sandbox mode"では、TiDBサーバーは期限切れのアカウントからの接続を許可します。ただし、この接続では、ユーザーはパスワードのリセットのみを実行できます。 -TiDBサーバーは、「サンドボックスモード」において、パスワードの有効期限が切れたユーザーを制限するかどうかを制御できます。パスワードの有効期限が切れた場合のTiDBサーバーの動作を制御するには、TiDB設定ファイルの[`security.disconnect-on-expired-password`](/tidb-configuration-file.md#disconnect-on-expired-password-new-in-v650)のパラメータを設定します。 +TiDBサーバーは、"sandbox mode"において、パスワードの有効期限が切れたユーザーを制限するかどうかを制御できます。パスワードの有効期限が切れた場合のTiDBサーバーの動作を制御するには、TiDB設定ファイルの[`security.disconnect-on-expired-password`](/tidb-configuration-file.md#disconnect-on-expired-password-new-in-v650)のパラメータを設定します。 ```toml [security] @@ -274,7 +274,7 @@ disconnect-on-expired-password = true ``` - `disconnect-on-expired-password` `true` (デフォルト) に設定すると、パスワードの有効期限が切れるとサーバーはクライアントとの接続を切断します。 -- `disconnect-on-expired-password` `false`に設定すると、サーバーは「サンドボックスモード」を有効にし、ユーザーがサーバーに接続できるようにします。ただし、ユーザーはパスワードのリセットのみ可能です。パスワードをリセットすると、ユーザーはSQL文を通常どおり実行できるようになります。 +- `disconnect-on-expired-password` `false`に設定すると、サーバーは"sandbox mode"を有効にし、ユーザーがサーバーに接続できるようにします。ただし、ユーザーはパスワードのリセットのみ可能です。パスワードをリセットすると、ユーザーはSQL文を通常どおり実行できるようになります。 `disconnect-on-expired-password`が有効になっている場合、アカウントのパスワードが期限切れになると、TiDB はそのアカウントからの接続を拒否します。このような場合、以下の方法でパスワードを変更できます。 diff --git a/pd-configuration-file.md b/pd-configuration-file.md index 0d8542eb0555f..4a494caed3a08 100644 --- a/pd-configuration-file.md +++ b/pd-configuration-file.md @@ -56,7 +56,7 @@ PD設定ファイルは、コマンドラインパラメータよりも多くの - ブートストラップのための初期クラスタ構成 - デフォルト値: `"{name}=http://{advertise-peer-url}"` -- たとえば、 `name`が「pd」、 `advertise-peer-urls`が`"http://192.168.100.113:2380"`の場合、 `initial-cluster`は`"pd=http://192.168.100.113:2380"`なります。 +- たとえば、 `name`が"pd"、 `advertise-peer-urls`が`"http://192.168.100.113:2380"`の場合、 `initial-cluster`は`"pd=http://192.168.100.113:2380"`なります。 - 3 つの PD サーバーを起動する必要がある場合、 `initial-cluster`は次のようになります。 ``` diff --git a/pd-control.md b/pd-control.md index ee9a441f7eea8..78ab3ed02c449 100644 --- a/pd-control.md +++ b/pd-control.md @@ -210,7 +210,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - config set enable-one-way-merge true // Enables one-way merging. ``` -- `enable-cross-table-merge`は 、テーブル間のリージョンのマージを有効にするために使用されます。`false`に設定すると、PD は異なるテーブルのリージョンをマージしません。このオプションは、キータイプが「テーブル」の場合にのみ機能します。 +- `enable-cross-table-merge`は 、テーブル間のリージョンのマージを有効にするために使用されます。`false`に設定すると、PD は異なるテーブルのリージョンをマージしません。このオプションは、キータイプが"table"の場合にのみ機能します。 ```bash config set enable-cross-table-merge true // Enable cross table merge. @@ -218,8 +218,8 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - `key-type`はクラスターで使用されるキーエンコーディングの種類を指定します。サポートされているオプションは ["table", "raw", "txn"] で、デフォルト値は "table" です。 - - クラスター内に TiDB インスタンスが存在しない場合は、 `key-type` 「raw」または「txn」になり、PD は`enable-cross-table-merge`設定に関係なくテーブル間でリージョンをマージできます。 - - クラスター内にTiDBインスタンスが存在する場合、 `key-type`は 「table」である必要があります。PDがテーブル間でリージョンをマージできるかどうかは、 `enable-cross-table-merge`によって決まります。`key-type`が 「raw」の場合、配置ルールは機能しません。 + - クラスター内に TiDB インスタンスが存在しない場合は、 `key-type` "raw"または"txn"になり、PD は`enable-cross-table-merge`設定に関係なくテーブル間でリージョンをマージできます。 + - クラスター内にTiDBインスタンスが存在する場合、 `key-type`は "table"である必要があります。PDがテーブル間でリージョンをマージできるかどうかは、 `enable-cross-table-merge`によって決まります。`key-type`が "raw"の場合、配置ルールは機能しません。 ```bash config set key-type raw // Enable cross table merge. @@ -634,7 +634,7 @@ member leader_priority pd-5 0 >> operator check 1 // Check the status of the operators related to Region 1 ``` -リージョンの分割は、可能な限り中央に近い位置から開始されます。この位置を特定するには、「スキャン」と「近似」という2つの戦略があります。これらの違いは、前者はリージョンをスキャンして中央のキーを決定するのに対し、後者はSSTファイルに記録された統計情報をチェックすることでおおよその位置を取得することです。一般的に、前者の方が精度が高く、後者はI/Oの消費量が少なく、処理が高速です。 +リージョンの分割は、可能な限り中央に近い位置から開始されます。この位置を特定するには、"scan"と"approximate"という2つの戦略があります。これらの違いは、前者はリージョンをスキャンして中央のキーを決定するのに対し、後者はSSTファイルに記録された統計情報をチェックすることでおおよその位置を取得することです。一般的に、前者の方が精度が高く、後者はI/Oの消費量が少なく、処理が高速です。 ### `ping` {#ping} diff --git a/quick-start-with-tidb.md b/quick-start-with-tidb.md index ac2bf411d92ca..847671db12da7 100644 --- a/quick-start-with-tidb.md +++ b/quick-start-with-tidb.md @@ -420,7 +420,7 @@ TiDBクラスタの最小トポロジーは、以下のインスタンスで構 > > 秘密鍵を使用する場合は、 `-i`を使用して鍵のパスを指定できます。 `-i`と`-p`を同時に使用しないでください。 - デプロイを完了するには、「y」と`root`ユーザーのパスワードを入力してください。 + デプロイを完了するには、"y"と`root`ユーザーのパスワードを入力してください。 ```log Do you want to continue? [y/N]: y diff --git a/read-historical-data.md b/read-historical-data.md index c9a589f9580e4..b71f6c133bba9 100644 --- a/read-historical-data.md +++ b/read-historical-data.md @@ -27,7 +27,7 @@ TiDB は、特別なクライアントやドライバーを使用せずに、標 - 変数は`SESSION`スコープ内で有効です。 - その値は`SET`文を使用して変更できます。 - 変数のデータ型はテキストです。 -- この変数はTSO（Timestamp Oracle）とdatetimeを受け入れます。TSOはPDから取得される、グローバルに一意なタイムサービスです。受け入れられるdatetimeの形式は「2016-10-08 16:45:26.999」です。通常、datetimeは秒単位の精度で設定できます（例：「2016-10-08 16:45:26」）。 +- この変数はTSO（Timestamp Oracle）とdatetimeを受け入れます。TSOはPDから取得される、グローバルに一意なタイムサービスです。受け入れられるdatetimeの形式は「2016-10-08 16:45:26.999」です。通常、datetimeは秒単位の精度で設定できます（例："2016-10-08 16:45:26"）。 - 変数が設定されると、TiDBはその値をタイムスタンプとしてスナップショットを作成します。これはデータ構造のみを対象としており、オーバーヘッドは発生しません。その後、すべての`SELECT`操作はこのスナップショットからデータを読み取ります。 > **Note:** diff --git a/releases/release-2.0.1.md b/releases/release-2.0.1.md index a929f4861d20a..91bb9dc9452b5 100644 --- a/releases/release-2.0.1.md +++ b/releases/release-2.0.1.md @@ -1,6 +1,6 @@ --- title: TiDB 2.0.1 Release Notes -summary: TiDB 2.0.1は2018年5月16日にリリースされ、MySQLとの互換性とシステムの安定性が向上しました。アップデートには、「インデックス追加」のリアルタイム進捗表示、統計情報の自動更新のための新しいセッション変数、バグ修正、互換性の向上、動作変更が含まれています。PDでは新しいスケジューラの追加、リージョンバランスの最適化、そして様々な問題の修正が行われました。TiKVでは、読み取り、スレッド呼び出し、raftstoreのブロッキング、分割によるダーティリードに関する問題が修正されました。全体として、このリリースはパフォーマンス、安定性、互換性の向上に重点を置いています。 +summary: TiDB 2.0.1は2018年5月16日にリリースされ、MySQLとの互換性とシステムの安定性が向上しました。アップデートには、'Add Index'のリアルタイム進捗表示、統計情報の自動更新のための新しいセッション変数、バグ修正、互換性の向上、動作変更が含まれています。PDでは新しいスケジューラの追加、リージョンバランスの最適化、そして様々な問題の修正が行われました。TiKVでは、読み取り、スレッド呼び出し、raftstoreのブロッキング、分割によるダーティリードに関する問題が修正されました。全体として、このリリースはパフォーマンス、安定性、互換性の向上に重点を置いています。 --- # TiDB 2.0.1 リリースノート {#tidb-2-0-1-release-notes} diff --git a/releases/release-2.0.6.md b/releases/release-2.0.6.md index a63a047987894..1ad39c998b003 100644 --- a/releases/release-2.0.6.md +++ b/releases/release-2.0.6.md @@ -10,7 +10,7 @@ summary: TiDB 2.0.6は、システムの互換性と安定性の向上を伴い ## TiDB {#tidb} - 改善点 - - ディスク容量を節約するために「システム変数の設定」ログを短くする[#7031](https://github.com/pingcap/tidb/pull/7031) + - ディスク容量を節約するために"set system variable"ログを短くする[#7031](https://github.com/pingcap/tidb/pull/7031) - `ADD INDEX`の実行中に遅い操作をログに記録して、トラブルシューティングを容易にします[#7083](https://github.com/pingcap/tidb/pull/7083) - 統計情報の更新時にトランザクションの競合を減らす[#7138](https://github.com/pingcap/tidb/pull/7138) - 推定待ちの値が統計範囲を超える場合の行数推定の精度を向上 [#7185](https://github.com/pingcap/tidb/pull/7185) diff --git a/releases/release-2.1-rc.3.md b/releases/release-2.1-rc.3.md index 8c5daf62527df..5a1ca63859deb 100644 --- a/releases/release-2.1-rc.3.md +++ b/releases/release-2.1-rc.3.md @@ -19,7 +19,7 @@ summary: TiDB 2.1 RC3は2018年9月29日にリリースされ、安定性、互 - SQL実行エンジン - トランザクションにおける読み取り要求のパフォーマンスを最適化する [#7717](https://github.com/pingcap/tidb/pull/7717) - 一部のエグゼキュータにおけるChunkメモリの割り当てコストを最適化する[#7540](https://github.com/pingcap/tidb/pull/7540) - - ポイントクエリですべての NULL 値が取得される列によって発生する「インデックス範囲外」panicを修正[#7790](https://github.com/pingcap/tidb/pull/7790) + - ポイントクエリですべての NULL 値が取得される列によって発生する"index out of range"panicを修正[#7790](https://github.com/pingcap/tidb/pull/7790) - サーバ - 設定ファイル内のメモリクォータが有効にならない問題を修正[#7729](https://github.com/pingcap/tidb/pull/7729) - 各ステートメントの実行優先度を設定するためのシステム変数`tidb_force_priority`を追加します。 [#7694](https://github.com/pingcap/tidb/pull/7694) diff --git a/releases/release-2.1-rc.4.md b/releases/release-2.1-rc.4.md index c41bd1802663b..ddd5c2a053960 100644 --- a/releases/release-2.1-rc.4.md +++ b/releases/release-2.1-rc.4.md @@ -28,7 +28,7 @@ summary: TiDB 2.1 RC4は2018年10月23日にリリースされ、安定性、SQL - ラッチをリファクタリングしてトランザクションの競合の誤判断を回避し、同時トランザクションの実行パフォーマンスを向上させる[#7711](https://github.com/pingcap/tidb/pull/7711) - 一部のケースでスロークエリを収集することによって発生するpanic問題を修正[#7874](https://github.com/pingcap/tidb/pull/7847) - `LOAD DATA`文で`ESCAPED BY`が空文字列の場合のpanic問題を修正 [#8005](https://github.com/pingcap/tidb/pull/8005) - - 「コプロセッサエラー」ログ情報を完了する [#8006](https://github.com/pingcap/tidb/pull/8006) + - "coprocessor error"ログ情報を完了する [#8006](https://github.com/pingcap/tidb/pull/8006) - 互換性 - クエリが空の場合、 `SHOW PROCESSLIST`結果の`Command`フィールドを`Sleep`に設定します[#7839](https://github.com/pingcap/tidb/pull/7839) - 表現 @@ -51,4 +51,4 @@ summary: TiDB 2.1 RC4は2018年10月23日にリリースされ、安定性、SQL - スナップショット適用によって発生するRocksDB書き込み停止問題を最適化 [#3606](https://github.com/tikv/tikv/pull/3606) - raftstore `tick`メトリックを追加 [#3657](https://github.com/tikv/tikv/pull/3657) - RocksDBをアップグレードし、書き込みブロックの問題を修正し、 `IngestExternalFile` を実行するときに書き込み操作によってソースファイルが破損する可能性がある問題を修正しました。 [#3661](https://github.com/tikv/tikv/pull/3661) -- grpcio をアップグレードし、「ping が多すぎる」と誤って報告される問題を修正しました[#3650](https://github.com/tikv/tikv/pull/3650) +- grpcio をアップグレードし、"too many pings"と誤って報告される問題を修正しました[#3650](https://github.com/tikv/tikv/pull/3650) diff --git a/releases/release-2.1.12.md b/releases/release-2.1.12.md index ed680fd159195..97445ac57cf44 100644 --- a/releases/release-2.1.12.md +++ b/releases/release-2.1.12.md @@ -15,7 +15,7 @@ TiDB Ansible バージョン: 2.1.12 - インデックスクエリフィードバックを使用する際に、一致しないデータ型によって発生する問題を修正しました [#10755](https://github.com/pingcap/tidb/pull/10755) - 一部のケースで文字セットの変更により BLOB 列がテキスト列に変更される問題を修正[#10745](https://github.com/pingcap/tidb/pull/10745) -- トランザクション内の`GRANT`の操作が、場合によっては「重複エントリ」を誤って報告する問題を修正しました[#10739](https://github.com/pingcap/tidb/pull/10739) +- トランザクション内の`GRANT`の操作が、場合によっては"Duplicate Entry"を誤って報告する問題を修正しました[#10739](https://github.com/pingcap/tidb/pull/10739) - 以下の機能のMySQLとの互換性を向上 - `DAYNAME`機能[#10732](https://github.com/pingcap/tidb/pull/10732) - `MONTHNAME`機能[#10733](https://github.com/pingcap/tidb/pull/10733) diff --git a/releases/release-2.1.17.md b/releases/release-2.1.17.md index ab9da424b08ac..1c75d6c0f5194 100644 --- a/releases/release-2.1.17.md +++ b/releases/release-2.1.17.md @@ -40,7 +40,7 @@ TiDB Ansible バージョン: 2.1.17 - `unaryMinus`関数によって返される結果が MySQL と互換性がない問題を修正しました。これは、整数結果がオーバーフローしたときに非小数点結果になるためです。 [#11990](https://github.com/pingcap/tidb/pull/11990) - `LOAD DATA`文の実行時にカウント順序が原因で`last_insert_id()`間違っている可能性がある問題を修正しました[#11994](https://github.com/pingcap/tidb/pull/11994) - ユーザーがAUTO_INCREMENT列データを明示的・暗黙的に混合して書き込む場合に`last_insert_id()`間違っている可能性がある問題を修正[#12001](https://github.com/pingcap/tidb/pull/12001) - - 関数`JSON_UNQUOTE`引用符の過剰使用に関するバグを修正しました。二重引用符で囲まれた値 ( `"` ) のみ引用符で囲まないようにします。例えば、「 `SELECT JSON_UNQUOTE("\\\\")` 」の結果は「 `\\` 」（変更なし）になります[#12096](https://github.com/pingcap/tidb/pull/12096) + - 関数`JSON_UNQUOTE`引用符の過剰使用に関するバグを修正しました。二重引用符で囲まれた値 ( `"` ) のみ引用符で囲まないようにします。例えば、 "`SELECT JSON_UNQUOTE("\\\\")`" の結果は "`\\`" （変更なし）になります[#12096](https://github.com/pingcap/tidb/pull/12096) - サーバ - TiDBトランザクション再試行する際、最後の再試行時刻から最初の実行時刻までの変更`start ts`スロークエリログに記録される [#11878](https://github.com/pingcap/tidb/pull/11878) - `LockResolver`のトランザクションのキーの数を追加して、リージョン全体のスキャン操作を回避し、キーの数が減ったときにロックを解決するコストを削減します[#11889](https://github.com/pingcap/tidb/pull/11889) diff --git a/releases/release-2.1.18.md b/releases/release-2.1.18.md index 8b891446fb500..b5a7b8ade6f20 100644 --- a/releases/release-2.1.18.md +++ b/releases/release-2.1.18.md @@ -69,7 +69,7 @@ TiDB Ansible バージョン: 2.1.18 ## TiDB Ansible {#tidb-ansible} -- TiDB Binlog に「キューサイズ」と「クエリヒストグラム」の 2つの監視項目を追加します。 [#952](https://github.com/pingcap/tidb-ansible/pull/952) +- TiDB Binlog に"queue size"と"query histogram"の 2つの監視項目を追加します。 [#952](https://github.com/pingcap/tidb-ansible/pull/952) - TiDBアラートルールを更新 [#961](https://github.com/pingcap/tidb-ansible/pull/961) - デプロイおよびアップグレードの前に構成ファイルを確認する[#973](https://github.com/pingcap/tidb-ansible/pull/973) - TiDB のインデックス速度を監視するための新しいメトリックを追加します [#987](https://github.com/pingcap/tidb-ansible/pull/987) diff --git a/releases/release-2.1.2.md b/releases/release-2.1.2.md index c653e57af1981..747798b08ad2b 100644 --- a/releases/release-2.1.2.md +++ b/releases/release-2.1.2.md @@ -1,6 +1,6 @@ --- title: TiDB 2.1.2 Release Notes -summary: TiDB 2.1.2およびTiDB Ansible 2.1.2は、2018年12月22日にリリースされました。このリリースでは、システムの互換性と安定性が向上しています。主なアップデートには、KafkaバージョンのTiDB Binlogとの互換性、ローリングアップデート中の終了メカニズムの改善、およびさまざまな問題の修正が含まれます。PDとTiKVにもアップデートが加えられ、リージョンマージの問題の修正や「DAY」単位の設定形式のサポートなどが行われました。さらに、 TiDB LightningとTiDB Binlogアップデートされ、新機能のサポートとボトルネックの解消が図られました。 +summary: TiDB 2.1.2およびTiDB Ansible 2.1.2は、2018年12月22日にリリースされました。このリリースでは、システムの互換性と安定性が向上しています。主なアップデートには、KafkaバージョンのTiDB Binlogとの互換性、ローリングアップデート中の終了メカニズムの改善、およびさまざまな問題の修正が含まれます。PDとTiKVにもアップデートが加えられ、リージョンマージの問題の修正や"DAY"単位の設定形式のサポートなどが行われました。さらに、 TiDB LightningとTiDB Binlogアップデートされ、新機能のサポートとボトルネックの解消が図られました。 --- # TiDB 2.1.2 リリースノート {#tidb-2-1-2-release-notes} diff --git a/releases/release-2.1.4.md b/releases/release-2.1.4.md index 15b2cf5e419c0..67e676f0be47f 100644 --- a/releases/release-2.1.4.md +++ b/releases/release-2.1.4.md @@ -17,7 +17,7 @@ summary: TiDB 2.1.4およびTiDB Ansible 2.1.4は、2019年2月15日にリリー - `VALUES`関数がENUM型を正しく処理しない問題を修正[#9280](https://github.com/pingcap/tidb/pull/9280) - 一部のケースで`DATE_ADD` `DATE_SUB`間違った結果の問題を修正[#9284](https://github.com/pingcap/tidb/pull/9284) - サーバ - - 「権限の再読み込み成功」ログを最適化し、DEBUGレベルに変更します。 [#9274](https://github.com/pingcap/tidb/pull/9274) + - "reload privilege success"ログを最適化し、DEBUGレベルに変更します。 [#9274](https://github.com/pingcap/tidb/pull/9274) - DDL - `tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`グローバル変数に変更する [#9134](https://github.com/pingcap/tidb/pull/9134) - いくつかの異常な状況で生成列にインデックスを追加することによって発生するバグを修正しました[#9289](https://github.com/pingcap/tidb/pull/9289) diff --git a/releases/release-3.0.0-beta.1.md b/releases/release-3.0.0-beta.1.md index 0af597d06df53..985ff482c855e 100644 --- a/releases/release-3.0.0-beta.1.md +++ b/releases/release-3.0.0-beta.1.md @@ -67,7 +67,7 @@ TiDB Ansible バージョン: 3.0.0-beta.1 - 統計に基づいて実際のデータ量と推定データ量の差を記録するための監視項目`high_error_rate_feedback_total`を追加します。 [#9209](https://github.com/pingcap/tidb/pull/9209) - データベースディメンションにQPS監視項目を追加します。これは、設定項目を使用して有効にできます。 [#9151](https://github.com/pingcap/tidb/pull/9151) - DDL - - DDLタスクの再試行回数を制限するために、 `ddl_error_count_limit`グローバル変数（デフォルトでは「512」）を追加します（この回数が制限を超えると、DDLタスクはキャンセルされます） [#9295](https://github.com/pingcap/tidb/pull/9295) + - DDLタスクの再試行回数を制限するために、 `ddl_error_count_limit`グローバル変数（デフォルトでは"512"）を追加します（この回数が制限を超えると、DDLタスクはキャンセルされます） [#9295](https://github.com/pingcap/tidb/pull/9295) - ALTER ALGORITHM `INPLACE` / `INSTANT` をサポート [#8811](https://github.com/pingcap/tidb/pull/8811) - `SHOW CREATE VIEW`文をサポートする [#9309](https://github.com/pingcap/tidb/pull/9309) - `SHOW CREATE USER`文をサポートする [#9240](https://github.com/pingcap/tidb/pull/9240) @@ -108,7 +108,7 @@ TiDB Ansible バージョン: 3.0.0-beta.1 - 生成列の複製をサポート - Lightning - TiKVの定期的なレベル1圧縮を無効にすることをサポートし、TiKVクラスタバージョンが2.1.4以降の場合、レベル1圧縮はインポートモードで自動的に実行されます[#4199](https://github.com/tikv/tikv/pull/4199) [#119](https://github.com/pingcap/tidb-lightning/pull/119) - - `table_concurrency`設定項目を追加して、インポートエンジンの数（デフォルトでは「16」）を制限し、インポーターのディスクスペース過剰な使用を回避します。 [#119](https://github.com/pingcap/tidb-lightning/pull/119) + - `table_concurrency`設定項目を追加して、インポートエンジンの数（デフォルトでは"16"）を制限し、インポーターのディスクスペース過剰な使用を回避します。 [#119](https://github.com/pingcap/tidb-lightning/pull/119) - メモリ使用量を削減するために、中間状態SSTをディスクに保存することをサポート[#4369](https://github.com/tikv/tikv/pull/4369) - TiKV-Importer のインポートパフォーマンスを最適化し、大規模なテーブルのデータとインデックスの個別インポートをサポートします[#132](https://github.com/pingcap/tidb-lightning/pull/132) - CSVファイルのインポートをサポート[#111](https://github.com/pingcap/tidb-lightning/pull/111) diff --git a/releases/release-3.0.0-rc.1.md b/releases/release-3.0.0-rc.1.md index 5a590e6f32dde..65c44dcb24cb9 100644 --- a/releases/release-3.0.0-rc.1.md +++ b/releases/release-3.0.0-rc.1.md @@ -64,7 +64,7 @@ TiDB Ansible バージョン: 3.0.0-rc.1 - ETCD アップグレード [#1452](https://github.com/pingcap/pd/pull/1452) - etcdとPDサーバーのログ形式を統一する - 事前投票でLeaderを選出できない問題を修正 - - 後続のリクエストをブロックしないように、失敗する可能性のある「提案」および「読み取り」リクエストを迅速にドロップすることをサポートします。 + - 後続のリクエストをブロックしないように、失敗する可能性のある"propose"および"read"リクエストを迅速にドロップすることをサポートします。 - リースのデッドロック問題を修正 - ホットストアがキーの統計情報を正しく生成しない問題を修正 [#1487](https://github.com/pingcap/pd/pull/1487) - 単一のPDノードからPDクラスターを強制的に再構築するサポート [#1485](https://github.com/pingcap/pd/pull/1485) diff --git a/releases/release-3.0.0-rc.3.md b/releases/release-3.0.0-rc.3.md index cec63101830b7..3fefc6aca2e9d 100644 --- a/releases/release-3.0.0-rc.3.md +++ b/releases/release-3.0.0-rc.3.md @@ -119,4 +119,4 @@ TiDB Ansible バージョン: 3.0.0-rc.3 ## TiDB Ansible {#tidb-ansible} -- クラスターの最大QPS値を予測するための監視項目を追加する（デフォルトでは「非表示」） [#f5cfa4d](https://github.com/pingcap/tidb-ansible/commit/f5cfa4d903bbcd77e01eddc8d31eabb6e6157f73) +- クラスターの最大QPS値を予測するための監視項目を追加する（デフォルトでは"hide"） [#f5cfa4d](https://github.com/pingcap/tidb-ansible/commit/f5cfa4d903bbcd77e01eddc8d31eabb6e6157f73) diff --git a/releases/release-3.0.1.md b/releases/release-3.0.1.md index e104c11bba2d0..563233d9dce85 100644 --- a/releases/release-3.0.1.md +++ b/releases/release-3.0.1.md @@ -38,7 +38,7 @@ TiDB Ansible バージョン: 3.0.1 - `SHOW PROCESSLIST`コマンドで表示される`DB`列と`INFO`列がMySQL と互換性がない問題を修正 [#11003](https://github.com/pingcap/tidb/pull/11003) - `skip-grant-table=true`が設定されている場合に`FLUSH PRIVILEGES`文によって発生するシステムpanicの問題を修正[#11027](https://github.com/pingcap/tidb/pull/11027) - テーブルの主キーが`UNSIGNED`整数の場合、 `FAST ANALYZE`で収集された主キー統計が正しくない問題を修正しました。 [#11099](https://github.com/pingcap/tidb/pull/11099) -- `FAST ANALYZE`文で「invalid key」エラーが報告される場合がある問題を修正[#11098](https://github.com/pingcap/tidb/pull/11098) +- `FAST ANALYZE`文で"invalid key"エラーが報告される場合がある問題を修正[#11098](https://github.com/pingcap/tidb/pull/11098) - 列のデフォルト値として`CURRENT_TIMESTAMP`が使用され、float精度が指定されている場合、 `SHOW CREATE TABLE`文で表示される精度が不完全になる問題を修正しました。 [#11088](https://github.com/pingcap/tidb/pull/11088) - MySQL との互換性を保つために、ウィンドウ関数がエラーを報告するときに関数名が小文字にならない問題を修正しました。 [#11118](https://github.com/pingcap/tidb/pull/11118) - TiKV クライアント バッチ gRPC のバックグラウンドスレッドがパニックを起こした後、TiDB が TiKV に接続できず、サービスを提供できなくなる問題を修正しました[#11101](https://github.com/pingcap/tidb/pull/11101) diff --git a/releases/release-3.0.16.md b/releases/release-3.0.16.md index 4efe4ae3be669..4778ee86e5466 100644 --- a/releases/release-3.0.16.md +++ b/releases/release-3.0.16.md @@ -1,6 +1,6 @@ --- title: TiDB 3.0.16 Release Notes -summary: TiDB 3.0.16は2020年7月3日にリリースされました。このリリースには、「is null」フィルター条件のサポート、SQLタイムアウト問題への対応、スロークエリログ内の機密情報の削除などの改善が含まれています。バグ修正には、データの不整合の問題の解決、panic問題の修正、JSON比較およびクエリ結果のエラーへの対応が含まれます。TiKVとPDについても、ストアハートビート、ピアの削除、エラー処理に関するバグ修正が行われました。 +summary: TiDB 3.0.16は2020年7月3日にリリースされました。このリリースには、"is null"フィルター条件のサポート、SQLタイムアウト問題への対応、スロークエリログ内の機密情報の削除などの改善が含まれています。バグ修正には、データの不整合の問題の解決、panic問題の修正、JSON比較およびクエリ結果のエラーへの対応が含まれます。TiKVとPDについても、ストアハートビート、ピアの削除、エラー処理に関するバグ修正が行われました。 --- # TiDB 3.0.16 リリースノート {#tidb-3-0-16-release-notes} diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index 3394454521222..a786ecc12cced 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -14,7 +14,7 @@ TiDB Ansible バージョン: 3.0.2 ## TiDB {#tidb} - SQLオプティマイザ - - クエリ内で同じテーブルが複数回出現し、論理的にクエリ結果が常に空になる場合に「スキーマ内に列が見つかりません」というメッセージが報告される問題を修正しました[#11247](https://github.com/pingcap/tidb/pull/11247) + - クエリ内で同じテーブルが複数回出現し、論理的にクエリ結果が常に空になる場合に"Can't find column in schema"というメッセージが報告される問題を修正しました[#11247](https://github.com/pingcap/tidb/pull/11247) - `TIDB_INLJ`ヒントが一部のケース（ `explain select /*+ TIDB_INLJ(t1) */ t1.b, t2.a from t t1, t t2 where t1.b = t2.a`など）で正しく機能しないことが原因でクエリプランが期待どおりに動作しない問題を修正しました[#11362](https://github.com/pingcap/tidb/pull/11362) - クエリ結果の列名が場合によっては間違っている問題を修正しました（ `SELECT IF(1,c,c) FROM t`など） [#11379](https://github.com/pingcap/tidb/pull/11379) - `SELECT 0 LIKE 'a string'`ようなクエリが`TRUE`返す問題を修正しました。これは、 `LIKE`式が暗黙的に0に変換される場合があるためです[#11411](https://github.com/pingcap/tidb/pull/11411) diff --git a/releases/release-3.0.5.md b/releases/release-3.0.5.md index 1f527428f820f..843308ee9ba34 100644 --- a/releases/release-3.0.5.md +++ b/releases/release-3.0.5.md @@ -26,7 +26,7 @@ TiDB Ansible バージョン: 3.0.5 - `from_unixtime`関数が null を処理するときに発生panic問題を修正 [#12551](https://github.com/pingcap/tidb/pull/12551) - DDLジョブをキャンセルする際に報告される`invalid list index`エラーを修正 [#12671](https://github.com/pingcap/tidb/pull/12671) - ウィンドウ関数の使用時に配列が範囲外になる問題を修正[#12660](https://github.com/pingcap/tidb/pull/12660) - - `AutoIncrement`列が暗黙的に割り当てられた場合の動作を改善し、MySQLのAUTO_INCREMENTロックのデフォルトモード（ [「連続」ロックモード](https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html) ）との一貫性を保ちます。1行の`Insert`文で複数の`AutoIncrement` IDを暗黙的に割り当てる場合、TiDBは割り当てられた値の連続性を保証します。この改善により、JDBC `getGeneratedKeys()`メソッドはどのようなシナリオでも正しい結果を得ることができます[#12602](https://github.com/pingcap/tidb/pull/12602) + - `AutoIncrement`列が暗黙的に割り当てられた場合の動作を改善し、MySQLのAUTO_INCREMENTロックのデフォルトモード（ ["consecutive"ロックモード](https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html) ）との一貫性を保ちます。1行の`Insert`文で複数の`AutoIncrement` IDを暗黙的に割り当てる場合、TiDBは割り当てられた値の連続性を保証します。この改善により、JDBC `getGeneratedKeys()`メソッドはどのようなシナリオでも正しい結果を得ることができます[#12602](https://github.com/pingcap/tidb/pull/12602) - `HashAgg` `Apply` の子ノードとして機能するときにクエリがハングする問題を修正しました [#12766](https://github.com/pingcap/tidb/pull/12766) - 型変換に関して、 `AND`と`OR`論理式が誤った結果を返す問題を修正しました。 [#12811](https://github.com/pingcap/tidb/pull/12811) - サーバ diff --git a/releases/release-3.0.6.md b/releases/release-3.0.6.md index 0e40787d11985..c22bdb5cb0b52 100644 --- a/releases/release-3.0.6.md +++ b/releases/release-3.0.6.md @@ -91,7 +91,7 @@ TiDB Ansible バージョン: 3.0.6 ## ツール {#tools} - TiDB Binlog - - Drainer で`initial-commit-ts` 「-1」に設定されている場合にPDから初期レプリケーションタイムスタンプを取得します。 [#788](https://github.com/pingcap/tidb-binlog/pull/788) + - Drainer で`initial-commit-ts` "-1"に設定されている場合にPDから初期レプリケーションタイムスタンプを取得します。 [#788](https://github.com/pingcap/tidb-binlog/pull/788) - Drainerの`Checkpoint`ストレージを下流から分離し、MySQLまたはローカルファイルへの保存`Checkpoint`サポートします。 [#790](https://github.com/pingcap/tidb-binlog/pull/790) - レプリケーションデータベース/テーブルフィルタリングを構成する際に空の値を使用することで発生するDrainer panicの問題を修正しました[#801](https://github.com/pingcap/tidb-binlog/pull/801) - Drainer が下流にbinlogファイルを適用できないためにpanicが発生した後、プロセスが終了せずにデッドロック状態になる問題を修正しました[#807](https://github.com/pingcap/tidb-binlog/pull/807) diff --git a/releases/release-3.1.2.md b/releases/release-3.1.2.md index a10f97c5ea752..9f93eef88b162 100644 --- a/releases/release-3.1.2.md +++ b/releases/release-3.1.2.md @@ -1,6 +1,6 @@ --- title: TiDB 3.1.2 Release Notes -summary: TiDB 3.1.2は2020年6月4日にリリースされました。バグ修正には、S3およびGCSを使用したバックアップおよびリストア時のエラー処理、およびリストア中の「DefaultNotFound」エラーが含まれます。バックアップ＆リストア（BR）などのツールは、ネットワーク状態が悪い場合に自動的に再試行するようになり、リストアの失敗やデータ損失の問題を修正し、S3ストレージを使用したサーバー側暗号化のためのAWS KMSをサポートします。 +summary: TiDB 3.1.2は2020年6月4日にリリースされました。バグ修正には、S3およびGCSを使用したバックアップおよびリストア時のエラー処理、およびリストア中の"DefaultNotFound"エラーが含まれます。バックアップ＆リストア（BR）などのツールは、ネットワーク状態が悪い場合に自動的に再試行するようになり、リストアの失敗やデータ損失の問題を修正し、S3ストレージを使用したサーバー側暗号化のためのAWS KMSをサポートします。 --- # TiDB 3.1.2 リリースノート {#tidb-3-1-2-release-notes} diff --git a/releases/release-4.0.0-rc.md b/releases/release-4.0.0-rc.md index 139c9449a10dc..4775d01e5a075 100644 --- a/releases/release-4.0.0-rc.md +++ b/releases/release-4.0.0-rc.md @@ -1,6 +1,6 @@ --- title: TiDB 4.0 RC Release Notes -summary: TiDB 4.0 RCは2020年4月8日にリリースされました。互換性の変更、バグ修正、新機能、ツールが含まれています。TiKVは悲観的トランザクションにおける「パイプライン化」機能をサポートし、TPC-Cパフォーマンスを20%向上させました。TiDBは大文字と小文字を区別しない照合順序を追加し、「RECOVER TABLE」構文を強化しました。TiKVはHTTPポートでTLSをサポートするようになりました。PDはHTTP APIを介してデフォルトのPD構成情報を取得できるようになりました。バグ修正には、レプリケーション、サブクエリ結果、DDLジョブの内部再試行に関する問題が含まれます。TiDB LightningやTiCDCなどのツールにもバグ修正と新機能が含まれています。 +summary: TiDB 4.0 RCは2020年4月8日にリリースされました。互換性の変更、バグ修正、新機能、ツールが含まれています。TiKVは悲観的トランザクションにおける"pipelined"機能をサポートし、TPC-Cパフォーマンスを20%向上させました。TiDBは大文字と小文字を区別しない照合順序を追加し、"RECOVER TABLE"構文を強化しました。TiKVはHTTPポートでTLSをサポートするようになりました。PDはHTTP APIを介してデフォルトのPD構成情報を取得できるようになりました。バグ修正には、レプリケーション、サブクエリ結果、DDLジョブの内部再試行に関する問題が含まれます。TiDB LightningやTiCDCなどのツールにもバグ修正と新機能が含まれています。 --- # TiDB 4.0 RC リリースノート {#tidb-4-0-rc-release-notes} diff --git a/releases/release-4.0.11.md b/releases/release-4.0.11.md index 9ff83dc97338f..1b79ffb8003aa 100644 --- a/releases/release-4.0.11.md +++ b/releases/release-4.0.11.md @@ -112,7 +112,7 @@ TiDB バージョン: 4.0.11 - デフォルト値`LEAD`と`LAG`フィールドタイプに適応できない問題を修正 [#21665](https://github.com/pingcap/tidb/pull/21665) - `LOAD DATA`文がベーステーブルにのみデータをロードできることを確認するためのチェックを実行します。 [#21638](https://github.com/pingcap/tidb/pull/21638) - `addtime`と`subtime`関数が無効な引数処理するときに発生する問題を修正しました [#21635](https://github.com/pingcap/tidb/pull/21635) - - 近似値の丸めルールを「最も近い偶数に丸める」に変更します[#21628](https://github.com/pingcap/tidb/pull/21628) + - 近似値の丸めルールを"round to the nearest even number"に変更します[#21628](https://github.com/pingcap/tidb/pull/21628) - `WEEK()`明示的に読み込まれるまで`@@GLOBAL.default_week_format`認識しない問題を修正[#21623](https://github.com/pingcap/tidb/pull/21623) - TiKV diff --git a/releases/release-4.0.12.md b/releases/release-4.0.12.md index 888748d2ba4b5..c65349e4c59d8 100644 --- a/releases/release-4.0.12.md +++ b/releases/release-4.0.12.md @@ -1,6 +1,6 @@ --- title: TiDB 4.0.12 Release Notes -summary: TiDB 4.0.12は2021年4月2日にリリースされました。新機能には、オンラインローリングアップデート用の「tiflashレプリカ」の状態を確認するツールが含まれています。TiDB、TiKV、PD、 TiFlash、および各種ツールの機能強化に加え、TiDB、TiKV、PD、 TiFlash、TiCDC、バックアップ＆リストア、 TiDB Lightningのバグ修正も実装されました。 +summary: TiDB 4.0.12は2021年4月2日にリリースされました。新機能には、オンラインローリングアップデート用の`tiflash replica`の状態を確認するツールが含まれています。TiDB、TiKV、PD、 TiFlash、および各種ツールの機能強化に加え、TiDB、TiKV、PD、 TiFlash、TiCDC、バックアップ＆リストア、 TiDB Lightningのバグ修正も実装されました。 --- # TiDB 4.0.12 リリースノート {#tidb-4-0-12-release-notes} diff --git a/releases/release-4.0.14.md b/releases/release-4.0.14.md index 6e89d96599b30..21d9ceb15c10e 100644 --- a/releases/release-4.0.14.md +++ b/releases/release-4.0.14.md @@ -110,7 +110,7 @@ TiDB バージョン: 4.0.14 - リージョンハートビートにより、TiKV が特定の状況で大規模なリージョンを分割できない問題を修正[#10111](https://github.com/tikv/tikv/issues/10111) - TiKVとTiDB 間のCMスケッチの形式の不一致によって発生した誤った統計を修正しました [#25638](https://github.com/pingcap/tidb/issues/25638) - `apply wait duration`メトリックの誤った統計を修正 [#9893](https://github.com/tikv/tikv/issues/9893) - - Titan で`delete_files_in_range`を使用した後に発生する「Missing Blob」エラーを修正 [#10232](https://github.com/tikv/tikv/pull/10232) + - Titan で`delete_files_in_range`を使用した後に発生する"Missing Blob"エラーを修正 [#10232](https://github.com/tikv/tikv/pull/10232) - PD @@ -124,8 +124,8 @@ TiDB バージョン: 4.0.14 - TiDB Dashboard - **プロファイリング**UIがすべてのTiDBインスタンスをプロファイリングできない問題を修正[#944](https://github.com/pingcap/tidb-dashboard/pull/944) - - **Statements**UIに「プラン数」が表示されない問題を修正しました[#939](https://github.com/pingcap/tidb-dashboard/pull/939) - - クラスタアップグレード後に**Slow Query**UIに「unknown field」エラーが表示される問題を修正しました [#902](https://github.com/pingcap/tidb-dashboard/issues/902) + - **Statements**UIに"Plan Count"が表示されない問題を修正しました[#939](https://github.com/pingcap/tidb-dashboard/pull/939) + - クラスタアップグレード後に**Slow Query**UIに"unknown field"エラーが表示される問題を修正しました [#902](https://github.com/pingcap/tidb-dashboard/issues/902) - TiFlash diff --git a/releases/release-4.0.15.md b/releases/release-4.0.15.md index 1c624ab37fec4..a8d5954f7b6ed 100644 --- a/releases/release-4.0.15.md +++ b/releases/release-4.0.15.md @@ -91,7 +91,7 @@ TiDB バージョン: 4.0.15 - 範囲構築するときにバイナリリテラルの照合順序順序が誤って設定されるバグを修正しました [#23672](https://github.com/pingcap/tidb/issues/23672) - - に`GROUP BY`と`UNION`両方が含まれている場合に発生する「index out of range」というエラーを修正しました。 [#26553](https://github.com/pingcap/tidb/pull/26553) + - に`GROUP BY`と`UNION`両方が含まれている場合に発生する"index out of range"というエラーを修正しました。 [#26553](https://github.com/pingcap/tidb/pull/26553) - TiKVにtombstoneストアがある場合、TiDBがリクエストの送信に失敗する可能性がある問題を修正[#23676](https://github.com/pingcap/tidb/issues/23676) [#24648](https://github.com/pingcap/tidb/issues/24648) @@ -101,7 +101,7 @@ TiDB バージョン: 4.0.15 - TiKV - - データ復元中にTDEが有効になっているとBRが「file already exists」というエラーを報告する問題を修正[#1179](https://github.com/pingcap/br/issues/1179) + - データ復元中にTDEが有効になっているとBRが"file already exists"というエラーを報告する問題を修正[#1179](https://github.com/pingcap/br/issues/1179) - 破損したスナップショットファイルによって引き起こされる潜在的なディスクフル問題を修正[#10813](https://github.com/tikv/tikv/issues/10813) - TiKVが古いリージョンを頻繁に削除する問題を修正[#10680](https://github.com/tikv/tikv/issues/10680) - TiKVがPDクライアントに頻繁に再接続する問題を修正 [#9690](https://github.com/tikv/tikv/issues/9690) diff --git a/releases/release-4.0.7.md b/releases/release-4.0.7.md index da942ad807f44..82712eee98762 100644 --- a/releases/release-4.0.7.md +++ b/releases/release-4.0.7.md @@ -1,6 +1,6 @@ --- title: TiDB 4.0.7 Release Notes -summary: TiDB 4.0.7は2020年9月29日にリリースされました。新機能には、PDクライアントへの「GetAllMembers」関数の追加と、TiDB Dashboardでのメトリクス関係グラフの生成のサポートが含まれます。TiDB、TiKV、PD、 TiFlash、および各種ツールに改善が行われました。また、TiDB、TiKV、PD、 TiFlash、およびBackup & RestoreやDumplingなどのツールのバグ修正も実装されました。 +summary: TiDB 4.0.7は2020年9月29日にリリースされました。新機能には、PDクライアントへの"GetAllMembers"関数の追加と、TiDB Dashboardでのメトリクス関係グラフの生成のサポートが含まれます。TiDB、TiKV、PD、 TiFlash、および各種ツールに改善が行われました。また、TiDB、TiKV、PD、 TiFlash、およびBackup & RestoreやDumplingなどのツールのバグ修正も実装されました。 --- # TiDB 4.0.7 リリースノート {#tidb-4-0-7-release-notes} diff --git a/releases/release-4.0.8.md b/releases/release-4.0.8.md index d6a856d751ce9..f982a26fe65c3 100644 --- a/releases/release-4.0.8.md +++ b/releases/release-4.0.8.md @@ -1,6 +1,6 @@ --- title: TiDB 4.0.8 Release Notes -summary: TiDB 4.0.8は2020年10月30日にリリースされました。新機能には、新しい集計関数「APPROX_PERCENTILE」のサポートと、 TiFlashにおける「CAST」関数のプッシュダウンが含まれます。TiDB、TiKV、PD、 TiFlashの機能強化に加え、TiDB、TiKV、PD、 TiFlash、バックアップとリストア（BR）、TiCDC、 TiDB Lightningのバグ修正も実装されました。 +summary: TiDB 4.0.8は2020年10月30日にリリースされました。新機能には、新しい集計関数`APPROX_PERCENTILE`のサポートと、 TiFlashにおける`CAST`関数のプッシュダウンが含まれます。TiDB、TiKV、PD、 TiFlashの機能強化に加え、TiDB、TiKV、PD、 TiFlash、バックアップとリストア（BR）、TiCDC、 TiDB Lightningのバグ修正も実装されました。 --- # TiDB 4.0.8 リリースノート {#tidb-4-0-8-release-notes} diff --git a/releases/release-4.0.9.md b/releases/release-4.0.9.md index eee77bb8353af..9bfe8999f444b 100644 --- a/releases/release-4.0.9.md +++ b/releases/release-4.0.9.md @@ -1,6 +1,6 @@ --- title: TiDB 4.0.9 Release Notes -summary: TiDB 4.0.9は2020年12月21日にリリースされました。このリリースには、互換性の変更、新機能、改善、バグ修正、そしてTiKV、TiDB Dashboard、PD、 TiFlash 、そして各種ツールのアップデートが含まれています。注目すべき変更点としては、TiDBにおける「enable-streaming」設定項目の廃止、 TiFlashにおけるストレージエンジンの最新データを複数のディスクに保存する機能のサポート、そしてTiDBとTiKVにおける各種バグ修正などが挙げられます。 +summary: TiDB 4.0.9は2020年12月21日にリリースされました。このリリースには、互換性の変更、新機能、改善、バグ修正、そしてTiKV、TiDB Dashboard、PD、 TiFlash 、そして各種ツールのアップデートが含まれています。注目すべき変更点としては、TiDBにおける`enable-streaming`設定項目の廃止、 TiFlashにおけるストレージエンジンの最新データを複数のディスクに保存する機能のサポート、そしてTiDBとTiKVにおける各種バグ修正などが挙げられます。 --- # TiDB 4.0.9 リリースノート {#tidb-4-0-9-release-notes} @@ -72,7 +72,7 @@ TiDB バージョン: 4.0.9 - TiDB Dashboard - - SQL文の「展開」をクリックすると展開を続ける [#775](https://github.com/pingcap/tidb-dashboard/pull/775) + - SQL文の"Expand"をクリックすると展開を続ける [#775](https://github.com/pingcap/tidb-dashboard/pull/775) - **SQL Statements**と**Slow Queries**の詳細ページを新しいウィンドウで開く [#816](https://github.com/pingcap/tidb-dashboard/pull/816) - **Slow Queries**の詳細における時間関連フィールドの説明の改善 [#817](https://github.com/pingcap/tidb-dashboard/pull/817) - 詳細なエラーメッセージを表示する[#794](https://github.com/pingcap/tidb-dashboard/pull/794) @@ -113,7 +113,7 @@ TiDB バージョン: 4.0.9 - デフォルトですべてのシステムスキーマを除外する[#459](https://github.com/pingcap/tidb-lightning/pull/459) - ローカルバックエンドまたはインポーターバックエンドのAUTO_RANDOM主キーのデフォルト値の設定をサポート [#457](https://github.com/pingcap/tidb-lightning/pull/457) - 範囲プロパティを使用して、Local-backend で範囲分割をより正確にします。 [#422](https://github.com/pingcap/tidb-lightning/pull/422) - - `tikv-importer.region-split-size` `mydumper.batch-size`人間が形式（「2.5 GiB」など） `mydumper.read-block-size`サポートする`mydumper.max-region-size` [#471](https://github.com/pingcap/tidb-lightning/pull/471) + - `tikv-importer.region-split-size` `mydumper.batch-size`人間が形式（"2.5 GiB"など） `mydumper.read-block-size`サポートする`mydumper.max-region-size` [#471](https://github.com/pingcap/tidb-lightning/pull/471) - TiDB Binlog diff --git a/releases/release-5.0.0-rc.md b/releases/release-5.0.0-rc.md index 1e32368c59cdb..9869c77874e4b 100644 --- a/releases/release-5.0.0-rc.md +++ b/releases/release-5.0.0-rc.md @@ -1,6 +1,6 @@ --- title: TiDB 5.0 RC Release Notes -summary: TiDB v5.0.0-rcはTiDB v5.0の前身バージョンです。クラスター化インデックス、非同期コミット、ジッターの低減、 Raft Joint Consensusアルゴリズム、最適化された「EXPLAIN」機能、不可視インデックス、エンタープライズデータの信頼性向上などの新機能が含まれています。また、セキュリティ対策として、エラーメッセージとログファイルの感度低下もサポートしています。パフォーマンス向上には、非同期コミット、オプティマイザの安定性、パフォーマンスジッターの低減が含まれます。また、リージョンメンバーシップ変更時のシステム可用性も向上します。さらに、AWS S3およびGoogle Cloud GCSへのバックアップとリストア、データのインポート/エクスポート、SQLパフォーマンスの問題のトラブルシューティングのための最適化された「EXPLAIN」機能もサポートしています。導入とメンテナンスの改善には、強化された「mirror」コマンドとより簡単なインストールプロセスが含まれます。 +summary: TiDB v5.0.0-rcはTiDB v5.0の前身バージョンです。クラスター化インデックス、非同期コミット、ジッターの低減、 Raft Joint Consensusアルゴリズム、最適化された`EXPLAIN`機能、不可視インデックス、エンタープライズデータの信頼性向上などの新機能が含まれています。また、セキュリティ対策として、エラーメッセージとログファイルの感度低下もサポートしています。パフォーマンス向上には、非同期コミット、オプティマイザの安定性、パフォーマンスジッターの低減が含まれます。また、リージョンメンバーシップ変更時のシステム可用性も向上します。さらに、AWS S3およびGoogle Cloud GCSへのバックアップとリストア、データのインポート/エクスポート、SQLパフォーマンスの問題のトラブルシューティングのための最適化された`EXPLAIN`機能もサポートしています。導入とメンテナンスの改善には、強化された`mirror`コマンドとより簡単なインストールプロセスが含まれます。 --- # TiDB 5.0 RC リリースノート {#tidb-5-0-rc-release-notes} diff --git a/releases/release-5.0.0.md b/releases/release-5.0.0.md index 8cd09b1099f72..96e64c6dcb1c0 100644 --- a/releases/release-5.0.0.md +++ b/releases/release-5.0.0.md @@ -369,9 +369,9 @@ Unified Sorterは、以前のバージョンの`memory` / `file`ソートエン [ユーザー向けドキュメント](/pd-configuration-file.md#enable-joint-consensus-new-in-v50)、 [#18079](https://github.com/pingcap/tidb/issues/18079) 、 [#7587](https://github.com/tikv/tikv/issues/7587) 、 [#2860](https://github.com/tikv/pd/issues/2860) -リージョンメンバーシップの変更処理では、「メンバーの追加」と「メンバーの削除」という2つの操作が2つのステップで実行されます。メンバーシップ変更処理の完了時にエラーが発生した場合、リージョンは利用できなくなり、フォアグラウンドアプリケーションのエラーが返されます。 +リージョンメンバーシップの変更処理では、"adding a member"と"deleting a member"という2つの操作が2つのステップで実行されます。メンバーシップ変更処理の完了時にエラーが発生した場合、リージョンは利用できなくなり、フォアグラウンドアプリケーションのエラーが返されます。 -導入されたRaft共同合意アルゴリズムは、リージョンメンバーシップ変更時のシステム可用性を向上させることができます。メンバーシップ変更時の「メンバーの追加」と「メンバーの削除」操作は1つの操作に統合され、すべてのメンバーに送信されます。変更処理中、リージョンは中間状態になります。変更されたメンバーのいずれかが故障した場合でも、システムは引き続き利用可能です。 +導入されたRaft共同合意アルゴリズムは、リージョンメンバーシップ変更時のシステム可用性を向上させることができます。メンバーシップ変更時の"adding a member"と"deleting a member"操作は1つの操作に統合され、すべてのメンバーに送信されます。変更処理中、リージョンは中間状態になります。変更されたメンバーのいずれかが故障した場合でも、システムは引き続き利用可能です。 この機能はデフォルトで有効になっています。 `pd-ctl config set enable-joint-consensus`コマンドを実行して`enable-joint-consensus`の値を`false`に設定することで無効にできます。 diff --git a/releases/release-5.0.3.md b/releases/release-5.0.3.md index e6f7bb2210c80..e13047ed9d9d1 100644 --- a/releases/release-5.0.3.md +++ b/releases/release-5.0.3.md @@ -136,7 +136,7 @@ TiDB バージョン: 5.0.3 - Backup & Restore (BR) - 復元中にすべてのシステムテーブルがフィルタリングされるバグを修正[#1197](https://github.com/pingcap/br/issues/1197) [#1201](https://github.com/pingcap/br/issues/1201) - - 復元中にTDEが有効になっていると、バックアップと復元で「ファイルが既に存在します」というエラーが報告される問題を修正しました[#1179](https://github.com/pingcap/br/issues/1179) + - 復元中にTDEが有効になっていると、バックアップと復元で"file already exists"というエラーが報告される問題を修正しました[#1179](https://github.com/pingcap/br/issues/1179) - TiDB Lightning diff --git a/releases/release-5.0.4.md b/releases/release-5.0.4.md index 177e51838217a..3f46ab67f898f 100644 --- a/releases/release-5.0.4.md +++ b/releases/release-5.0.4.md @@ -27,8 +27,8 @@ TiDB バージョン: 5.0.4 - `group_concat`関数の列に非ビン照合順序ある場合に発生する誤った実行結果を修正しました [#27429](https://github.com/pingcap/tidb/issues/27429) - 新しい照合順序が有効になっているときに、複数の列で`count(distinct)`式を使用すると間違った結果が返される問題を修正しました[#27091](https://github.com/pingcap/tidb/issues/27091) - `extract`関数の引数が負の期間の場合に発生する結果の誤りを修正 [#27236](https://github.com/pingcap/tidb/issues/27236) - - `SQL_MODE` 「STRICT_TRANS_TABLES」の場合、無効な日付を挿入してもエラーが報告されない問題を修正しました[#26762](https://github.com/pingcap/tidb/issues/26762) - - `SQL_MODE` 「NO_ZERO_IN_DATE」の場合に無効なデフォルト日付を使用してもエラーが報告されない問題を修正しました[#26766](https://github.com/pingcap/tidb/issues/26766) + - `SQL_MODE` 'STRICT_TRANS_TABLES'の場合、無効な日付を挿入してもエラーが報告されない問題を修正しました[#26762](https://github.com/pingcap/tidb/issues/26762) + - `SQL_MODE` 'NO_ZERO_IN_DATE'の場合に無効なデフォルト日付を使用してもエラーが報告されない問題を修正しました[#26766](https://github.com/pingcap/tidb/issues/26766) - プレフィックスインデックスのクエリ範囲に関するバグを修正 [#26029](https://github.com/pingcap/tidb/issues/26029) - `LOAD DATA`文が非 UTF8 データを異常にインポートする可能性がある問題を修正[#25979](https://github.com/pingcap/tidb/issues/25979) - `insert ignore on duplicate update`セカンダリインデックスに主キーと同じ列がある場合に間違ったデータが挿入される可能性がある問題を修正[#25809](https://github.com/pingcap/tidb/issues/25809) @@ -82,7 +82,7 @@ TiDB バージョン: 5.0.4 - スロガースレッドが過負荷になりキューがいっぱいになったときに、スレッドをブロックする代わりにログをドロップする[#10841](https://github.com/tikv/tikv/issues/10841) - TiKVコプロセッサのスローログに、リクエスト処理に費やされた時間のみを考慮するようにする [#10841](https://github.com/tikv/tikv/issues/10841) - 未確定エラーの可能性を減らすために、できるだけべき等な事前書き込みを行う[#10587](https://github.com/tikv/tikv/pull/10587) - - 書き込みフローが低い場合に「GC が動作できません」という誤った警告を回避する[#10662](https://github.com/tikv/tikv/pull/10662) + - 書き込みフローが低い場合に"GC can not work"という誤った警告を回避する[#10662](https://github.com/tikv/tikv/pull/10662) - 復元するデータベースが、バックアップ時の元のクラスタサイズと常に一致するようにします[#10643](https://github.com/tikv/tikv/pull/10643) - panic出力がログにフラッシュされていることを確認する [#9955](https://github.com/tikv/tikv/pull/9955) @@ -119,7 +119,7 @@ TiDB バージョン: 5.0.4 - 非同期コミットロックを解決する際に TiDB がpanicする可能性がある問題を修正[#25778](https://github.com/pingcap/tidb/issues/25778) - `INDEX MERGE` 使用時に列が見つからないことがあるバグを修正 [#25045](https://github.com/pingcap/tidb/issues/25045) - `ALTER USER REQUIRE SSL`ユーザーの`authentication_string` をクリアするバグを修正 [#25225](https://github.com/pingcap/tidb/issues/25225) - - 新しいクラスターの`tidb_gc_scan_lock_mode`グローバル変数の値が、実際のデフォルトモード「LEGACY」 ではなく「PHYSICAL」と表示されるバグを修正しました。 [#25100](https://github.com/pingcap/tidb/issues/25100) + - 新しいクラスターの`tidb_gc_scan_lock_mode`グローバル変数の値が、実際のデフォルトモード"LEGACY" ではなく"PHYSICAL"と表示されるバグを修正しました。 [#25100](https://github.com/pingcap/tidb/issues/25100) - `TIKV_REGION_PEERS`システムテーブルに正しい`DOWN`ステータスが表示されないバグを修正しました [#24879](https://github.com/pingcap/tidb/issues/24879) - HTTP API使用時に発生するメモリリークの問題を修正[#24649](https://github.com/pingcap/tidb/pull/24649) - ビューが`DEFINER` をサポートしない問題を修正 [#24414](https://github.com/pingcap/tidb/issues/24414) diff --git a/releases/release-5.0.5.md b/releases/release-5.0.5.md index f4c585a8d4507..136c5341aa493 100644 --- a/releases/release-5.0.5.md +++ b/releases/release-5.0.5.md @@ -1,6 +1,6 @@ --- title: TiDB 5.0.5 Release Note -summary: TiDB 5.0.5は2021年12月3日にリリースされました。TiKVのバグ修正では、複数のキーで呼び出された場合に「GcKeys」タスクが機能せず、コンパクションフィルタGCでMVCC削除情報が削除されない問題が修正されています。詳細はGitHubのIssue #11217をご覧ください。 +summary: TiDB 5.0.5は2021年12月3日にリリースされました。TiKVのバグ修正では、複数のキーで呼び出された場合に`GcKeys`タスクが機能せず、コンパクションフィルタGCでMVCC削除情報が削除されない問題が修正されています。詳細はGitHubのIssue #11217をご覧ください。 --- # TiDB 5.0.5 リリースノート {#tidb-5-0-5-release-note} diff --git a/releases/release-5.1.0.md b/releases/release-5.1.0.md index 5eb4e2eebd1a1..315d47ed78c8e 100644 --- a/releases/release-5.1.0.md +++ b/releases/release-5.1.0.md @@ -65,7 +65,7 @@ TiDB バージョン: 5.1.0 - TiDB のローリングアップグレード中は`alter table ... modify column`や`alter table ... change column`のようなステートメントを実行しないでください。 - バージョン5.1以降、各テーブルのTiFlashレプリカを作成する際に、システムテーブルのレプリカを設定する機能はサポートされなくなりました。クラスタをアップグレードする前に、関連するシステムテーブルのレプリカをクリアする必要があります。クリアしないと、アップグレードは失敗します。 - TiCDC の`cdc cli changefeed`コマンドの`--sort-dir`は非推奨です。代わりに、 `cdc server`コマンドで`--sort-dir` を設定できます。 [#1795](https://github.com/pingcap/tiflow/pull/1795) -- TiDB 5.1 にアップグレードした後、TiDB が「function READ ONLY has only noop implementation」というエラーを返す場合、 [`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)の値を`ON`に設定することで、TiDB がこのエラーを無視するようにできます。これは、MySQL の`read_only`変数が TiDB ではまだ有効になっていないためです (TiDB では「noop」動作です)。したがって、この変数が TiDB で設定されていても、TiDB クラスタにデータを書き込むことができます。 +- TiDB 5.1 にアップグレードした後、TiDB が「function READ ONLY has only noop implementation」というエラーを返す場合、 [`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)の値を`ON`に設定することで、TiDB がこのエラーを無視するようにできます。これは、MySQL の`read_only`変数が TiDB ではまだ有効になっていないためです (TiDB では'noop'動作です)。したがって、この変数が TiDB で設定されていても、TiDB クラスタにデータを書き込むことができます。 ## 新機能 {#new-features} @@ -167,7 +167,7 @@ TiDB バージョン: 5.1.0 - TiKVバックグラウンドタスク用の書き込みレート制限機能を追加する（TiKV書き込みレート制限機能） - 読み取りおよび書き込み要求の継続時間の安定性を確保するため、TiKV 書き込みレートリミッターは、GC や圧縮などの TiKV バックグラウンドタスクの書き込みトラフィックを平滑化します。TiKV バックグラウンドタスク書き込みレートリミッターのデフォルト値は「0MB」です。この値は、クラウドディスクメーカーが指定する最大 I/O 帯域幅など、ディスクの最適な I/O 帯域幅に設定することをお勧めします。 + 読み取りおよび書き込み要求の継続時間の安定性を確保するため、TiKV 書き込みレートリミッターは、GC や圧縮などの TiKV バックグラウンドタスクの書き込みトラフィックを平滑化します。TiKV バックグラウンドタスク書き込みレートリミッターのデフォルト値は"0MB"です。この値は、クラウドディスクメーカーが指定する最大 I/O 帯域幅など、ディスクの最適な I/O 帯域幅に設定することをお勧めします。 [ユーザー向けドキュメント](/tikv-configuration-file.md#storageio-rate-limit)、 [#9156](https://github.com/tikv/tikv/issues/9156) diff --git a/releases/release-5.1.2.md b/releases/release-5.1.2.md index c251da298ae2f..c4b78b21923a0 100644 --- a/releases/release-5.1.2.md +++ b/releases/release-5.1.2.md @@ -21,8 +21,8 @@ TiDB バージョン: 5.1.2 - `group_concat`関数の列に非ビン照合順序がある場合に発生する誤った実行結果を修正しました [#27429](https://github.com/pingcap/tidb/issues/27429) - 新しい照合順序が有効になっているときに、複数の列で`count(distinct)`式を使用すると間違った結果が返される問題を修正しました[#27091](https://github.com/pingcap/tidb/issues/27091) - `extract`関数の引数が負の期間の場合に発生する結果の誤りを修正 [#27236](https://github.com/pingcap/tidb/issues/27236) - - `SQL_MODE` 「STRICT_TRANS_TABLES」の場合、無効な日付を挿入してもエラーが報告されない問題を修正しました[#26762](https://github.com/pingcap/tidb/issues/26762) - - `SQL_MODE` 「NO_ZERO_IN_DATE」の場合に無効なデフォルト日付を使用してもエラーが報告されない問題を修正しました[#26766](https://github.com/pingcap/tidb/issues/26766) + - `SQL_MODE`が"STRICT_TRANS_TABLES"の場合、無効な日付を挿入してもエラーが報告されない問題を修正しました[#26762](https://github.com/pingcap/tidb/issues/26762) + - `SQL_MODE`が"NO_ZERO_IN_DATE"の場合に無効なデフォルト日付を使用してもエラーが報告されない問題を修正しました[#26766](https://github.com/pingcap/tidb/issues/26766) - ツール diff --git a/releases/release-5.1.4.md b/releases/release-5.1.4.md index 9e1643d8cef85..0108a7c1c66ea 100644 --- a/releases/release-5.1.4.md +++ b/releases/release-5.1.4.md @@ -53,7 +53,7 @@ TiDB バージョン: 5.1.4 - チェンジフィードを再開するための指数バックオフメカニズムを追加します[#3329](https://github.com/pingcap/tiflow/issues/3329) - 多数のテーブルを複製する際のレプリケーションのレイテンシーを削減する[#3900](https://github.com/pingcap/tiflow/issues/3900) - 増分スキャンの残り時間を観察するためのメトリックを追加します [#2985](https://github.com/pingcap/tiflow/issues/2985) - - 「EventFeed 再試行レート制限」ログの数を減らす[#4006](https://github.com/pingcap/tiflow/issues/4006) + - "EventFeed retry rate limited"ログの数を減らす[#4006](https://github.com/pingcap/tiflow/issues/4006) - `no owner alert`、`mounter row`、`table sink total row`、`buffer sink total row`を含む、PrometheusとGrafanaの監視メトリックとアラートを追加します [#4054](https://github.com/pingcap/tiflow/issues/4054) [#1606](https://github.com/pingcap/tiflow/issues/1606) - TiKVリロードのレート制限制御を最適化して、チェンジフィード初期化中のgPRC輻輳を軽減します[#3110](https://github.com/pingcap/ticdc/issues/3110) - TiKVストアがダウンしたときにKVクライアントが回復するまでの時間を短縮します[#3191](https://github.com/pingcap/tiflow/issues/3191) @@ -94,7 +94,7 @@ TiDB バージョン: 5.1.4 - 悲観的トランザクションで事前書き込み要求を再試行するときにまれに発生するデータの不整合の問題を修正[#11187](https://github.com/tikv/tikv/issues/11187) - 設定`resource-metering.enabled`が動作しないバグを修正[#11235](https://github.com/tikv/tikv/issues/11235) - `resolved_ts` で一部のコルーチンがリークする問題を修正 [#10965](https://github.com/tikv/tikv/issues/10965) - - 書き込みフローが低い場合に「GC が動作できません」という誤った警告が報告される問題を修正[#9910](https://github.com/tikv/tikv/issues/9910) + - 書き込みフローが低い場合に"GC can not work"という誤った警告が報告される問題を修正[#9910](https://github.com/tikv/tikv/issues/9910) - tikv-ctlが正しいリージョン関連情報を返すことができないバグを修正[#11393](https://github.com/tikv/tikv/issues/11393) - TiKVノードがダウンすると解決されたタイムスタンプが遅れる問題を修正しました [#11351](https://github.com/tikv/tikv/issues/11351) - 極端な状況でリージョンのマージ、ConfChange、スナップショットが同時に発生した場合に発生するpanicの問題を修正しました[#11475](https://github.com/tikv/tikv/issues/11475) diff --git a/releases/release-5.2.0.md b/releases/release-5.2.0.md index 770c634650052..84069398125c9 100644 --- a/releases/release-5.2.0.md +++ b/releases/release-5.2.0.md @@ -55,8 +55,8 @@ TiDB バージョン: 5.2.0 | TiKV設定ファイル | [`storage.flow-control.enable`](/tikv-configuration-file.md#enable) | 新しく追加された | フロー制御メカニズムを有効にするかどうかを決定します。デフォルト値は`true`です。 | | TiKV設定ファイル | [`storage.flow-control.memtables-threshold`](/tikv-configuration-file.md#memtables-threshold) | 新しく追加された | kvDB の memtable の数がこのしきい値に達すると、フロー制御メカニズムが動作を開始します。デフォルト値は`5`です。 | | TiKV設定ファイル | [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold) | 新しく追加された | kvDB L0 ファイルの数がこのしきい値に達すると、フロー制御メカニズムが動作を開始します。デフォルト値は`9`です。 | -| TiKV設定ファイル | [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 新しく追加された | KvDB の保留中の圧縮バイト数がこのしきい値に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。デフォルト値は「192GB」です。 | -| TiKV設定ファイル | [`storage.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit) | 新しく追加された | KvDB の保留中の圧縮バイト数がこのしきい値に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。デフォルト値は「1024GB」です。 | +| TiKV設定ファイル | [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 新しく追加された | KvDB の保留中の圧縮バイト数がこのしきい値に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。デフォルト値は"192GB"です。 | +| TiKV設定ファイル | [`storage.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit) | 新しく追加された | KvDB の保留中の圧縮バイト数がこのしきい値に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。デフォルト値は"1024GB"です。 | ### その他 {#others} @@ -208,7 +208,7 @@ Apple M1チップを搭載したMacコンピュータで`tiup playground`コマ - アップグレード後に既存のバインディングをキャッシュにロードできない問題を修正しました [#23295](https://github.com/pingcap/tidb/pull/23295) - `SHOW BINDINGS`の結果を ( `original_sql` 、 `update_time` ) で並べ替えることをサポートする [#26139](https://github.com/pingcap/tidb/pull/26139) - バインディングが存在する場合のクエリ最適化ロジックを改善し、クエリの最適化時間を短縮する [#26141](https://github.com/pingcap/tidb/pull/26141) - - 「削除済み」ステータスのバインディングに対してガベージコレクションを自動的に完了する機能をサポートする [#26206](https://github.com/pingcap/tidb/pull/26206) + - "deleted"ステータスのバインディングに対してガベージコレクションを自動的に完了する機能をサポートする [#26206](https://github.com/pingcap/tidb/pull/26206) - `EXPLAIN VERBOSE`の結果で、バインディングがクエリ最適化に使用されているかどうかを表示する機能のサポート [#26930](https://github.com/pingcap/tidb/pull/26930) - 現在の TiDB インスタンスのバインディング キャッシュに対応するタイムスタンプを表示するための新しいステータス バリエーション`last_plan_binding_update_time`を追加します [#26340](https://github.com/pingcap/tidb/pull/26340) - バインディング進化の開始時、またはベースライン進化を禁止する`admin evolve bindings`実行時にエラーを報告する機能をサポートする（現在、実験的機能であるため、TiDB Self-Managed バージョンでは無効になっている）。これにより、他の機能に影響が出る。 [#26333](https://github.com/pingcap/tidb/pull/26333) diff --git a/releases/release-5.3.0.md b/releases/release-5.3.0.md index 82a8675da9184..930481264e442 100644 --- a/releases/release-5.3.0.md +++ b/releases/release-5.3.0.md @@ -54,7 +54,7 @@ v5.3 の主な新機能または改善点は次のとおりです。 | PD | [`patrol-region-interval`](/pd-configuration-file.md#patrol-region-interval) | 変更 | replicaChecker がリージョンのヘルス状態をチェックする実行頻度を制御します。この値が小さいほど、replicaChecker の実行速度が速くなります。通常、このパラメータを調整する必要はありません。デフォルト値は`100ms`から`10ms`に変更されています。 | | PD | [`max-snapshot-count`](/pd-configuration-file.md#max-snapshot-count) | 変更 | 単一のストアが同時に受信または送信するスナップショットの最大数を制御します。PDスケジューラは、この設定に基づいて、通常のトラフィックに使用されるリソースがプリエンプトされるのを防ぎます。デフォルト値は`3`から`64`に変更されました。 | | PD | [`max-pending-peer-count`](/pd-configuration-file.md#max-pending-peer-count) | 変更 | 単一ストア内の保留中のピアの最大数を制御します。PDスケジューラはこの設定に依存して、一部のノードで古いログを持つリージョンが過剰に生成されるのを防ぎます。デフォルト値は`16`から`64`に変更されました。 | -| TiDB Lightning | `meta-schema-name` | 新しく追加された | ターゲットクラスター内の各TiDB Lightningインスタンスのメタ情報が格納されるスキーマ名。デフォルト値は「lightning_metadata」です。 | +| TiDB Lightning | `meta-schema-name` | 新しく追加された | ターゲットクラスター内の各TiDB Lightningインスタンスのメタ情報が格納されるスキーマ名。デフォルト値は"lightning_metadata"です。 | ### その他 {#others} @@ -81,7 +81,7 @@ v5.3 の主な新機能または改善点は次のとおりです。 - プラグインのデフォルトのストレージディレクトリが`""`から`/data/deploy/plugin`に変更されます。 -- DMコードは[TiCDCコードリポジトリのフォルダ「dm」](https://github.com/pingcap/tiflow/tree/release-5.3/dm)に移行されました。DMのバージョン番号はTiDBに準じます。v2.0.xの次に新しいDMバージョンはv5.3.0となり、v2.0.xからv5.3.0へのアップグレードはリスクなしで行えます。 +- DMコードは[TiCDCコードリポジトリのフォルダ"dm"](https://github.com/pingcap/tiflow/tree/release-5.3/dm)に移行されました。DMのバージョン番号はTiDBに準じます。v2.0.xの次に新しいDMバージョンはv5.3.0となり、v2.0.xからv5.3.0へのアップグレードはリスクなしで行えます。 - Prometheusのデフォルトのデプロイバージョンは、v2.8.1から2021年5月にリリースされる[バージョン2.27.1](https://github.com/prometheus/prometheus/releases/tag/v2.27.1)にアップグレードされました。このバージョンでは、より多くの機能が提供され、セキュリティ問題が修正されています。Prometheus v2.8.1と比較して、v2.27.1ではアラートの時刻表示がUnixタイムスタンプからUTCに変更されました。詳細は[Prometheusコミット](https://github.com/prometheus/prometheus/commit/7646cbca328278585be15fa615e22f2a50b47d06)を参照してください。 diff --git a/releases/release-5.3.1.md b/releases/release-5.3.1.md index 219483eacf0c6..afe9584bff377 100644 --- a/releases/release-5.3.1.md +++ b/releases/release-5.3.1.md @@ -43,7 +43,7 @@ TiDB バージョン: 5.3.1 - チェックポイントのタイムスタンプが予期せず進むのを避けるために、テーブルごとにシンクのチェックポイントを管理する[#3545](https://github.com/pingcap/tiflow/issues/3545) - チェンジフィードを再開するための指数バックオフメカニズムを追加します[#3329](https://github.com/pingcap/tiflow/issues/3329) - TiCDC がメッセージを Kafka パーティション間でより均等に分散するように、Kafka シンク`partition-num`のデフォルト値を 3 に変更します[#3337](https://github.com/pingcap/tiflow/issues/3337) - - 「EventFeed 再試行レート制限」ログの数を減らす[#4006](https://github.com/pingcap/tiflow/issues/4006) + - "EventFeed retry rate limited"ログの数を減らす[#4006](https://github.com/pingcap/tiflow/issues/4006) - デフォルト値の`max-message-bytes`を10M に設定する [#4041](https://github.com/pingcap/tiflow/issues/4041) - `no owner alert` `table sink total row`含む`buffer sink total row` PrometheusとGrafana 監視メトリックとアラート追加します`mounter row` [#4054](https://github.com/pingcap/tiflow/issues/4054) [#1606](https://github.com/pingcap/tiflow/issues/1606) - TiKVストアがダウンしたときにKVクライアントが回復するまでの時間を短縮します[#3191](https://github.com/pingcap/tiflow/issues/3191) @@ -160,6 +160,6 @@ TiDB バージョン: 5.3.1 - TiDB Lightning - 一部のインポートタスクにソースファイルが含まれていない場合にTiDB Lightningがメタデータスキーマを削除しない可能性があるバグを修正しました[#28144](https://github.com/pingcap/tidb/issues/28144) - - storageURL プレフィックスが「gcs://xxx」ではなく「gs://xxx」の場合にTiDB Lightning がエラーを返すバグを修正しました[#32742](https://github.com/pingcap/tidb/issues/32742) + - storageURL プレフィックスが"gcs://xxx"ではなく"gs://xxx"の場合にTiDB Lightning がエラーを返すバグを修正しました[#32742](https://github.com/pingcap/tidb/issues/32742) - --log-file="-" を設定しても stdout にログが出力されない問題を修正しました [#29876](https://github.com/pingcap/tidb/issues/29876) - S3ストレージパスが存在しない場合にTiDB Lightningがエラーを報告しない問題を修正[#30709](https://github.com/pingcap/tidb/issues/30709) diff --git a/releases/release-5.4.0.md b/releases/release-5.4.0.md index 1fb38ab7c64a3..c318a7038faea 100644 --- a/releases/release-5.4.0.md +++ b/releases/release-5.4.0.md @@ -47,18 +47,18 @@ TiDB バージョン: 5.4.0 | TiKV | `log-rotation-timespan` | 削除済み | ログファイルのローテーション間隔。この間隔が経過すると、ログファイルがローテーションされます。これは、現在のログファイルのファイル名にタイムスタンプが追加され、新しいログファイルが作成されることを意味します。 | | TiKV | `allow-remove-leader` | 削除済み | メインスイッチの削除を許可するかどうかを決定します。 | | TiKV | `raft-msg-flush-interval` | 削除済み | Raftメッセージがバッチで送信される間隔を決定します。Raftメッセージは、この設定項目で指定された間隔ごとにバッチで送信されます。 | -| PD | [`log.level`](/pd-configuration-file.md#level) | 変更 | デフォルト値が「INFO」から「info」に変更され、大文字と小文字を区別しないことが保証されます。 | +| PD | [`log.level`](/pd-configuration-file.md#level) | 変更 | デフォルト値が"INFO"から"info"に変更され、大文字と小文字を区別しないことが保証されます。 | | TiFlash | [`profile.default.enable_elastic_threadpool`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | エラスティックスレッドプール機能を有効にするか無効にするかを決定します。この設定項目を有効にすると、高並行処理シナリオでのTiFlash CPU 使用率が大幅に向上します。デフォルト値は`false`です。 | | TiFlash | [`storage.format_version`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | DTFile のバージョンを指定します。デフォルト値は`2`で、このバージョンではハッシュがデータファイルに埋め込まれます。値を`3`に設定することもできます。 `3`の場合、データファイルにはメタデータとトークンデータのチェックサムが含まれ、複数のハッシュアルゴリズムがサポートされます。 | | TiFlash | [`logger.count`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 変更 | デフォルト値は`10`に変更されます。 | | TiFlash | [`status.metrics_port`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 変更 | デフォルト値は`8234`に変更されます。 | | TiFlash | [`raftstore.apply-pool-size`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 新しく追加された | Raftデータをストレージにフラッシュするプール内のスレッドの許容数。デフォルト値は`4`です。 | | TiFlash | [`raftstore.store-pool-size`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 新しく追加された | Raftを処理するスレッドの許容数。これはRaftstoreスレッドプールのサイズです。デフォルト値は`4`です。 | -| TiDBデータ移行（DM） | [`collation_compatible`](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced) | 新しく追加された | `CREATE` SQL文のデフォルトの照合照合順序を同期するモード。値のオプションは「loose」（デフォルト）と「strict」です。 | +| TiDBデータ移行（DM） | [`collation_compatible`](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced) | 新しく追加された | `CREATE` SQL文のデフォルトの照合照合順序を同期するモード。値のオプションは"loose"（デフォルト）と"strict"です。 | | TiCDC | `max-message-bytes` | 変更 | Kafkaシンクの`max-message-bytes`のデフォルト値を`104857601`に変更します（10MB）。 | | TiCDC | `partition-num` | 変更 | Kafka Sink の`partition-num`のデフォルト値を`4`から`3`に変更します。これにより、TiCDC が Kafaka パーティションにメッセージをより均等に送信できるようになります。 | | TiDB Lightning | `meta-schema-name` | 変更 | ターゲット TiDB 内のメタデータのスキーマ名を指定します。v5.4.0 以降、このスキーマは有効になっている場合にのみ作成されます[並列インポート](/tidb-lightning/tidb-lightning-distributed-import.md)(対応するパラメータは`tikv-importer.incremental-import = true`です)。 | -| TiDB Lightning | `task-info-schema-name` | 新しく追加された | TiDB Lightning が競合を検出した際に、重複データが格納されるデータベース名を指定します。デフォルト値は「lightning_task_info」です。このパラメータは、「重複データの解決」機能を有効にしている場合にのみ指定してください。 | +| TiDB Lightning | `task-info-schema-name` | 新しく追加された | TiDB Lightning が競合を検出した際に、重複データが格納されるデータベース名を指定します。デフォルト値は"lightning_task_info"です。このパラメータは、"duplicate-resolution"機能を有効にしている場合にのみ指定してください。 | | TiDB Lightning | `incremental-import` | 新しく追加された | 既にデータが存在するテーブルにデータをインポートすることを許可するかどうかを決定します。デフォルト値は`false`です。 | ### その他 {#others} @@ -68,7 +68,7 @@ TiDB バージョン: 5.4.0 - バージョン5.4.0以降、プランキャッシュによってキャッシュされた実行計画に対してSQLバインディングを作成すると、対応するクエリに対して既にキャッシュされているプラ​​ンが無効化されます。この新しいバインディングは、バージョン5.4.0より前にキャッシュされた実行計画には影響しません。 - v5.3 以前のバージョンでは、 [TiDB Data Migration (DM)](https://docs.pingcap.com/tidb-data-migration/v5.3/)ドキュメントは TiDB ドキュメントから独立しています。 v5.4 以降、DM ドキュメントは同じバージョンの TiDB ドキュメントに統合されています。 DM ドキュメント サイトにアクセスせずに、 [DMドキュメント](/dm/dm-overview.md)を直接読むことができます。 - ポイントインタイムリカバリ（PITR）の実験的機能をcdclogとともに削除しました。バージョン5.4.0以降、cdclogベースのPITRおよびcdclogはサポートされなくなりました。 -- システム変数を「DEFAULT」に設定する動作をMySQLとの互換性を高める [#29680](https://github.com/pingcap/tidb/pull/29680) +- システム変数を"DEFAULT"に設定する動作をMySQLとの互換性を高める [#29680](https://github.com/pingcap/tidb/pull/29680) - システム変数`lc_time_names`を読み取り専用に設定する [#30084](https://github.com/pingcap/tidb/pull/30084) - `tidb_store_limit`のスコープを INSTANCE または GLOBAL から GLOBAL に変更する [#30756](https://github.com/pingcap/tidb/pull/30756) - 列にゼロが含まれている場合、整数型の列を時間型の列に変換することを禁止する [#25728](https://github.com/pingcap/tidb/pull/25728) @@ -217,7 +217,7 @@ TiDB バージョン: 5.4.0 - **TiDB Lightningは、並列インポート用のメタ情報を格納するスキーマ名を導入しました。** - TiDB Lightning、 `meta-schema-name`という設定項目が導入されました。並列インポートモードでは、このパラメータは、ターゲットクラスタ内の各TiDB Lightningインスタンスのメタ情報を格納するスキーマ名を指定します。デフォルト値は「lightning_metadata」です。このパラメータに設定する値は、同じ並列インポートに参加する各TiDB Lightningインスタンスで同じである必要があります。そうでない場合、インポートされたデータの正確性が保証されません。 + TiDB Lightning、 `meta-schema-name`という設定項目が導入されました。並列インポートモードでは、このパラメータは、ターゲットクラスタ内の各TiDB Lightningインスタンスのメタ情報を格納するスキーマ名を指定します。デフォルト値は"lightning_metadata"です。このパラメータに設定する値は、同じ並列インポートに参加する各TiDB Lightningインスタンスで同じである必要があります。そうでない場合、インポートされたデータの正確性が保証されません。 [ユーザー向けドキュメント](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md index 2eb76e0a1efd8..96bc074b7900a 100644 --- a/releases/release-6.0.0-dmr.md +++ b/releases/release-6.0.0-dmr.md @@ -213,7 +213,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - 指定した時間から移行タスクを開始することをサポート - 移行タスクに新しいパラメータ`--start-time`が追加されました。「2021-10-21 00:01:00」または「2021-10-21T00:01:00」の形式で時間を定義できます。 + 移行タスクに新しいパラメータ`--start-time`が追加されました。"2021-10-21 00:01:00"または"2021-10-21T00:01:00"の形式で時間を定義できます。 この機能は、シャードMySQLインスタンスから増分データを移行およびマージするシナリオで特に役立ちます。具体的には、増分移行タスクで各ソースにbinlog開始ポイントを設定する必要はありません。代わりに、 `safe-mode`の`--start-time`パラメータを使用することで、増分移行タスクを迅速に作成できます。 @@ -350,7 +350,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - TiKV - 多くのキー範囲を持つバッチに対するRaftstoreのサンプリング精度を向上[#12327](https://github.com/tikv/tikv/issues/12327) - - `debug/pprof/profile`に正しい「Content-Type」を追加して、プロファイルをより簡単に識別できるようにします[#11521](https://github.com/tikv/tikv/issues/11521) + - `debug/pprof/profile`に正しい"Content-Type"を追加して、プロファイルをより簡単に識別できるようにします[#11521](https://github.com/tikv/tikv/issues/11521) - Raftstore がハートビートを持っているときや読み取り要求を処理しているときにリーダーのリースの時間を無期限に更新し、レイテンシージッターを削減します[#11579](https://github.com/tikv/tikv/issues/11579) - リーダーを切り替える際にコストが最も低いストアを選択すると、パフォーマンスの安定性が向上します[#10602](https://github.com/tikv/tikv/issues/10602) - Raftログを非同期に取得することで、 Raftstore をブロックすることで発生するパフォーマンスジッターを軽減します。 [#11320](https://github.com/tikv/tikv/issues/11320) diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md index 4d6241f54d5d9..727656afa29d8 100644 --- a/releases/release-6.1.1.md +++ b/releases/release-6.1.1.md @@ -1,6 +1,6 @@ --- title: TiDB 6.1.1 Release Notes -summary: TiDB 6.1.1は2022年9月1日にリリースされました。変更点には、大文字と小文字を区別しない「SHOW DATABASES LIKE」ステートメント、「tidb_enable_outer_join_reorder」のデフォルト値の変更、オプティマイザとメトリクスレスポンスの圧縮の改善が含まれます。バグ修正では、「INL_HASH_JOIN」のハング、UPDATE`文実行中のパニック、クエリ結果の誤りなどの問題が修正されています。その他の変更点には、異なる品質基準に対するマルチレベルサポートと、「TiDB-community-toolkit」バイナリパッケージへの追加が含まれます。 +summary: TiDB 6.1.1は2022年9月1日にリリースされました。変更点には、大文字と小文字を区別しない`SHOW DATABASES LIKE`ステートメント、「tidb_enable_outer_join_reorder」のデフォルト値の変更、オプティマイザとメトリクスレスポンスの圧縮の改善が含まれます。バグ修正では、`INL_HASH_JOIN`のハング、UPDATE`文実行中のパニック、クエリ結果の誤りなどの問題が修正されています。その他の変更点には、異なる品質基準に対するマルチレベルサポートと、「TiDB-community-toolkit」バイナリパッケージへの追加が含まれます。 --- # TiDB 6.1.1 Release Notes {#tidb-6-1-1-release-notes} diff --git a/releases/release-6.1.4.md b/releases/release-6.1.4.md index 62aa52d0e8604..893b984623fe3 100644 --- a/releases/release-6.1.4.md +++ b/releases/release-6.1.4.md @@ -41,7 +41,7 @@ TiDB バージョン: 6.1.4 - テーブルを作成するときに、列のデフォルト値とタイプが一致せず、自動的に修正されない問題を修正しました[#34881](https://github.com/pingcap/tidb/issues/34881) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) @[mjonss](https://github.com/mjonss) - `LazyTxn.LockKeys`関数のデータ競合問題を修正 [#40355](https://github.com/pingcap/tidb/issues/40355) @[HuSharp](https://github.com/HuSharp) - 長いセッション接続で`INSERT`または`REPLACE`文がpanicする可能性がある問題を修正しました [#40351](https://github.com/pingcap/tidb/issues/40351) @[fanrenhoo](https://github.com/fanrenhoo) - - 「カーソル読み取り」メソッドを使用してデータを読み取ると、GC のためにエラーが返される可能性がある問題を修正しました。 [#39447](https://github.com/pingcap/tidb/issues/39447) @[zyguan](https://github.com/zyguan) + - "cursor read"メソッドを使用してデータを読み取ると、GC のためにエラーが返される可能性がある問題を修正しました。 [#39447](https://github.com/pingcap/tidb/issues/39447) @[zyguan](https://github.com/zyguan) - [`pessimistic-auto-commit`](/tidb-configuration-file.md#pessimistic-auto-commit-new-in-v600)設定項目がPointGetクエリで有効にならない問題を修正しました [#39928](https://github.com/pingcap/tidb/issues/39928) @[zyguan](https://github.com/zyguan) - `INFORMATION_SCHEMA.TIKV_REGION_STATUS`テーブルをクエリすると誤った結果が返される問題を修正[#37436](https://github.com/pingcap/tidb/issues/37436) @[zimulala](https://github.com/zimulala) - 一部のパターンの`IN`と`NOT IN`サブクエリが`Can't find column`エラーを報告する問題を修正しました [#37032](https://github.com/pingcap/tidb/issues/37032) @[AilinKid](https://github.com/AilinKid) @[lance6716](https://github.com/lance6716) @@ -88,9 +88,9 @@ TiDB バージョン: 6.1.4 - TiDB Data Migration (DM) - `SHOW GRANTS`の下流データベース名にワイルドカード ("*") が含まれている場合に、DM が事前チェック中にエラーを発生させる可能性があるバグを修正しました[`#7645`](https://github.com/pingcap/tiflow/issues/7645) @[lance6716](https://github.com/lance6716) - - binlogログクエリイベントの「COMMIT」によって DM がログを過剰に出力する問題を修正しました [`#7525`](https://github.com/pingcap/tiflow/issues/7525) @[liumengya94](https://github.com/liumengya94) + - binlogログクエリイベントの"COMMIT"によって DM がログを過剰に出力する問題を修正しました [`#7525`](https://github.com/pingcap/tiflow/issues/7525) @[liumengya94](https://github.com/liumengya94) - SSL が`ssl-ca`しか設定されていない場合に DM タスクが起動に失敗する問題を修正しました [#7941](https://github.com/pingcap/tiflow/issues/7941) @[liumengya94](https://github.com/liumengya94) - - 1つのテーブルに「更新」と「非更新」の両方の式フィルタが指定されている場合、すべての`UPDATE`文がスキップされるバグを修正しました[#7831](https://github.com/pingcap/tiflow/issues/7831) @[lance6716](https://github.com/lance6716) + - 1つのテーブルに"update"と"non-update"の両方の式フィルタが指定されている場合、すべての`UPDATE`文がスキップされるバグを修正しました[#7831](https://github.com/pingcap/tiflow/issues/7831) @[lance6716](https://github.com/lance6716) - テーブルに`update-old-value-expr`または`update-new-value-expr`のいずれか一方のみが設定されている場合に、フィルタルールが有効にならないか、DM がパニックになるバグを修正しました。 [#7774](https://github.com/pingcap/tiflow/issues/7774) @[lance6716](https://github.com/lance6716) - TiDB Lightning diff --git a/releases/release-6.2.0.md b/releases/release-6.2.0.md index f5e31b47a012b..1a1b343f3ceb7 100644 --- a/releases/release-6.2.0.md +++ b/releases/release-6.2.0.md @@ -170,7 +170,7 @@ TiDBバージョン: 6.2.0-DMR - トランザクションにおけるセーブポイントの設定をサポートする - トランザクションとは、データベースがACID特性を保証する一連の連続した操作の論理的な集合です。複雑なアプリケーションシナリオでは、トランザクション内で多数の操作を管理する必要があり、場合によってはトランザクション内の操作をロールバックする必要が生じることもあります。「セーブポイント」は、トランザクションの内部実装のための名前付きメカニズムです。このメカニズムを使用することで、トランザクション内のロールバックポイントを柔軟に制御でき、より複雑なトランザクションを管理し、多様なアプリケーション設計においてより自由度を高めることができます。 + トランザクションとは、データベースがACID特性を保証する一連の連続した操作の論理的な集合です。複雑なアプリケーションシナリオでは、トランザクション内で多数の操作を管理する必要があり、場合によってはトランザクション内の操作をロールバックする必要が生じることもあります。"Savepoint"は、トランザクションの内部実装のための名前付きメカニズムです。このメカニズムを使用することで、トランザクション内のロールバックポイントを柔軟に制御でき、より複雑なトランザクションを管理し、多様なアプリケーション設計においてより自由度を高めることができます。 [ユーザー向けドキュメント](/sql-statements/sql-statement-savepoint.md) [#6840](https://github.com/pingcap/tidb/issues/6840) @[crazycs520](https://github.com/crazycs520) @@ -224,10 +224,10 @@ TiDBバージョン: 6.2.0-DMR [ユーザー向けドキュメント](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#scope-of-pausing-scheduling-during-import) [#35148](https://github.com/pingcap/tidb/issues/35148) @[sleepymole](https://github.com/sleepymole) -- [TiDB Lightningのユーザー向けドキュメント](/tidb-lightning/tidb-lightning-overview.md)ドキュメントをリファクタリングして、その構造をより合理的かつ明確にします。 「バックエンド」の用語も、新規ユーザーの理解の障壁を下げるために変更されています。 +- [TiDB Lightningのユーザー向けドキュメント](/tidb-lightning/tidb-lightning-overview.md)ドキュメントをリファクタリングして、その構造をより合理的かつ明確にします。 "backend"の用語も、新規ユーザーの理解の障壁を下げるために変更されています。 - - 「ローカルバックエンド」を「物理インポートモード」に置き換えてください。 - - 「tidb backend」を「logical import mode」に置き換えてください。 + - "local backend"を"physical import mode"に置き換えてください。 + - "tidb backend"を"logical import mode"に置き換えてください。 ### TiDBデータ共有サブスクリプション {#tidb-data-share-subscription} @@ -403,7 +403,7 @@ TiDB v6.2.0以降、 BRを使用したRawKVのバックアップと復元は非 - テーブル作成時に、デフォルト値と列の型が一致せず、自動的に修正されない問題を修正しました [#34881](https://github.com/pingcap/tidb/issues/34881) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - `mysql.columns_priv`を実行した後、 `DROP USER`テーブルのデータが同期的に削除されない問題を修正しました [#35059](https://github.com/pingcap/tidb/issues/35059) @[lcwangchao](https://github.com/lcwangchao) - 一部のシステムのスキーマ内でテーブルを作成することを禁止することで、DDL ジャムの問題を修正します [#35205](https://github.com/pingcap/tidb/issues/35205) @[tangenta](https://github.com/tangenta) - - パーティション化されたテーブルをクエリした際に、場合によっては「index-out-of-range」および「non used index」エラーが報告される問題を修正しました [#35181](https://github.com/pingcap/tidb/issues/35181) @[mjonss](https://github.com/mjonss) + - パーティション化されたテーブルをクエリした際に、場合によっては"index-out-of-range"および"non used index"エラーが報告される問題を修正しました [#35181](https://github.com/pingcap/tidb/issues/35181) @[mjonss](https://github.com/mjonss) - `INTERVAL expr unit + expr`がエラーを報告する可能性がある問題を修正 [#30253](https://github.com/pingcap/tidb/issues/30253) @[mjonss](https://github.com/mjonss) - トランザクション内で作成された一時テーブルが見つからないバグを修正 [#35644](https://github.com/pingcap/tidb/issues/35644) @[djshow832](https://github.com/djshow832) - `ENUM`列に照合順序を設定する際に発生するpanic問題を修正しました [#31637](https://github.com/pingcap/tidb/issues/31637) @[wjhuang2016](https://github.com/wjhuang2016) diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 599ae7ba31ae5..2c81ffca30c49 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -324,7 +324,7 @@ TiDBバージョン: 6.3.0-DMR - TiDB Data Migration (DM) - MySQL 8.0をデータソースとして使用する際の互換性を向上させる [#6448](https://github.com/pingcap/tiflow/issues/6448) @[lance6716](https://github.com/lance6716) - - 「無効な接続」が発生した場合にDDLを非同期で実行することでDDLを最適化する [#4689](https://github.com/pingcap/tiflow/issues/4689) @[lyzx2001](https://github.com/lyzx2001) + - "invalid connection"が発生した場合にDDLを非同期で実行することでDDLを最適化する [#4689](https://github.com/pingcap/tiflow/issues/4689) @[lyzx2001](https://github.com/lyzx2001) - TiDB Lightning diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index fccec17e1d654..5ad8969ea14ab 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -415,7 +415,7 @@ v6.5.0 以降では、v4.0.7 で導入された`AMEND TRANSACTION`メカニズ - TiDB Dashboard - - スロークエリページに 3 つの新しいフィールドを追加します:「Is Prepared?」、「Is Plan from Cache?」、「Is Plan from Binding?」 [#1451](https://github.com/pingcap/tidb-dashboard/issues/1451) @[shhdgit](https://github.com/shhdgit) + - スロークエリページに 3 つの新しいフィールドを追加します:"Is Prepared?"、"Is Plan from Cache?"、"Is Plan from Binding?" [#1451](https://github.com/pingcap/tidb-dashboard/issues/1451) @[shhdgit](https://github.com/shhdgit) - Backup & Restore (BR) diff --git a/releases/release-6.5.1.md b/releases/release-6.5.1.md index 8267880e6ff45..02754287612cf 100644 --- a/releases/release-6.5.1.md +++ b/releases/release-6.5.1.md @@ -91,7 +91,7 @@ TiDB バージョン: 6.5.1 - 一意インデックスを追加するときに TiDB がパニックを起こす問題を修正しました [#40592](https://github.com/pingcap/tidb/issues/40592) @[tangenta](https://github.com/tangenta) - 同じテーブルを同時に切り捨てるときに、一部の切り捨て操作が MDL によってブロックされない問題を修正[#40484](https://github.com/pingcap/tidb/issues/40484) @[wjhuang2016](https://github.com/wjhuang2016) - 動的トリミングモードでパーティションテーブルにグローバルバインディングが作成された後にTiDBが再起動できない問題を修正しました [#40368](https://github.com/pingcap/tidb/issues/40368) @[Yisaer](https://github.com/Yisaer) - - 「カーソル読み取り」メソッドを使用してデータを読み取ると、GC のためにエラーが返される可能性がある問題を修正しました。 [#39447](https://github.com/pingcap/tidb/issues/39447) @[zyguan](https://github.com/zyguan) + - "cursor read"メソッドを使用してデータを読み取ると、GC のためにエラーが返される可能性がある問題を修正しました。 [#39447](https://github.com/pingcap/tidb/issues/39447) @[zyguan](https://github.com/zyguan) - `SHOW PROCESSLIST` の結果で`EXECUTE`情報が null になる問題を修正しました [#41156](https://github.com/pingcap/tidb/issues/41156) @[YangKeao](https://github.com/YangKeao) - `globalMemoryControl`クエリを強制終了しているときに、 `KILL`操作が終了しない可能性がある問題を修正しました [#41057](https://github.com/pingcap/tidb/issues/41057) @[wshwsh12](https://github.com/wshwsh12) - `indexMerge`エラーに遭遇した後に TiDB がpanicする可能性がある問題を修正[#41047](https://github.com/pingcap/tidb/issues/41047) [#40877](https://github.com/pingcap/tidb/issues/40877) @[guo-shaoge](https://github.com/guo-shaoge) @[windtalker](https://github.com/windtalker) @@ -182,7 +182,7 @@ TiDB バージョン: 6.5.1 - `binlog-schema delete`コマンドが実行に失敗する問題を修正 [#7373](https://github.com/pingcap/tiflow/issues/7373) @[liumengya94](https://github.com/liumengya94) - 最後のbinlogがスキップされたDDL の場合にチェックポイントが進まない問題を修正しました [#8175](https://github.com/pingcap/tiflow/issues/8175) @[D3Hunter](https://github.com/D3Hunter) - - 1つのテーブルに「更新」と「非更新」の両方の式フィルタが指定されている場合、すべての`UPDATE`文がスキップされるバグを修正しました[#7831](https://github.com/pingcap/tiflow/issues/7831) @[lance6716](https://github.com/lance6716) + - 1つのテーブルに"update"と"non-update"の両方の式フィルタが指定されている場合、すべての`UPDATE`文がスキップされるバグを修正しました[#7831](https://github.com/pingcap/tiflow/issues/7831) @[lance6716](https://github.com/lance6716) - TiDB Lightning diff --git a/releases/release-6.5.3.md b/releases/release-6.5.3.md index 0d981aa2effaa..c463ff68c050a 100644 --- a/releases/release-6.5.3.md +++ b/releases/release-6.5.3.md @@ -110,7 +110,7 @@ TiDB バージョン: 6.5.3 - Backup & Restore (BR) - - バックアップが失敗したときにBRのエラーメッセージ「resolve lock timeout」が誤解を招き、実際のエラー情報が隠れてしまう問題を修正しました[#43236](https://github.com/pingcap/tidb/issues/43236) @[YuJuncen](https://github.com/YuJuncen) + - バックアップが失敗したときにBRのエラーメッセージ"resolve lock timeout"が誤解を招き、実際のエラー情報が隠れてしまう問題を修正しました[#43236](https://github.com/pingcap/tidb/issues/43236) @[YuJuncen](https://github.com/YuJuncen) - TiCDC diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md index c4e12fd3f6bd7..f339ba71efa58 100644 --- a/releases/release-6.6.0.md +++ b/releases/release-6.6.0.md @@ -478,7 +478,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - JSON の not 演算子の実装が MySQL の実装と互換性がない問題を修正しました [#40683](https://github.com/pingcap/tidb/issues/40683) @[YangKeao](https://github.com/YangKeao) - 同時ビューがDDL操作をブロックする可能性がある問題を修正 [#40352](https://github.com/pingcap/tidb/issues/40352) @[zeminzhou](https://github.com/zeminzhou) - パーティションテーブルの列を変更するDDL文を同時に実行することによって発生するデータの不整合を修正 [#40620](https://github.com/pingcap/tidb/issues/40620) @[mjonss](https://github.com/mjonss)@[mjonss](https://github.com/mjonss) - - `caching_sha2_password`を認証に使用し、パスワードを指定しない場合に「不正なパケット」が報告される問題を修正 [#40831](https://github.com/pingcap/tidb/issues/40831) @[dveeden](https://github.com/dveeden) + - `caching_sha2_password`を認証に使用し、パスワードを指定しない場合に"Malformed packet"が報告される問題を修正 [#40831](https://github.com/pingcap/tidb/issues/40831) @[dveeden](https://github.com/dveeden) - テーブルの主キーに`ENUM`列が含まれている場合に TTL タスクが失敗する問題を修正しました [#40456](https://github.com/pingcap/tidb/issues/40456) @[lcwangchao](https://github.com/lcwangchao) - `mysql.tidb_mdl_view`で、MDLによってブロックされた一部のDDL操作をクエリできない問題を修正します。 [#40838](https://github.com/pingcap/tidb/issues/40838) @[YangKeao](https://github.com/YangKeao) - DDL取り込み中にデータ競合が発生する可能性がある問題を修正 [#40970](https://github.com/pingcap/tidb/issues/40970) @[tangenta](https://github.com/tangenta) @@ -548,7 +548,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - `binlog-schema delete`コマンドの実行に失敗する問題を修正しました [#7373](https://github.com/pingcap/tiflow/issues/7373) @[liumengya94](https://github.com/liumengya94) - 最後のbinlogがスキップされたDDLである場合にチェックポイントが進まない問題を修正 [#8175](https://github.com/pingcap/tiflow/issues/8175) @[D3Hunter](https://github.com/D3Hunter) - - 1 つのテーブルで「更新」タイプと「非更新」タイプの両方の式フィルターが指定されている場合、すべての`UPDATE`文がスキップされるバグを修正しました [#7831](https://github.com/pingcap/tiflow/issues/7831) @[lance6716](https://github.com/lance6716) + - 1 つのテーブルで"update"タイプと"non-update"タイプの両方の式フィルターが指定されている場合、すべての`UPDATE`文がスキップされるバグを修正しました [#7831](https://github.com/pingcap/tiflow/issues/7831) @[lance6716](https://github.com/lance6716) - テーブルに`update-old-value-expr`または`update-new-value-expr`のいずれか一方のみが設定されている場合、フィルタルールが有効にならないか、DM がパニックを起こすバグを修正しました。 [#7774](https://github.com/pingcap/tiflow/issues/7774) @[lance6716](https://github.com/lance6716) - TiDB Lightning diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index d8654c14b5288..22ec4f823c851 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -212,7 +212,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 v7.1.0 では、TiDB Enterprise Edition でデータベース監査機能が強化され、その機能が大幅に拡張され、ユーザーエクスペリエンスが向上して、企業のデータベース セキュリティ コンプライアンスのニーズに対応できるようになりました。 - - より詳細な監査イベント定義とよりきめ細かな監査設定のために、「フィルター」と「ルール」の概念を導入します。 + - より詳細な監査イベント定義とよりきめ細かな監査設定のために、"Filter"と"Rule"の概念を導入します。 - JSON 形式でのルールの定義をサポートし、よりユーザーフレンドリーな構成方法を提供します。 - 自動ログローテーションとスペース管理関数を追加し、保持時間とログサイズの 2つの次元でのログローテーションの構成をサポートします。 - 監査ログをTEXTと JSON 形式の両方で出力できるようにすることで、サードパーティツールとの統合が容易になります。 diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md index 4e7e882a3da0b..3dcc5fcca9df9 100644 --- a/releases/release-7.2.0.md +++ b/releases/release-7.2.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 7.2.0 バージョン7.2.0では、以下の主要な機能と改善点が導入されています。 -
カテゴリ特徴説明
拡張性とパフォーマンスリソースグループは暴走クエリの管理をサポートします（実験的）クエリのタイムアウトをより細かく管理できるようになり、クエリの分類に基づいて異なる動作を設定できるようになりました。指定したしきい値に達したクエリは、優先度を下げたり、終了させたりすることができます。
TiFlashはパイプライン実行モデルをサポートしています（実験的）。 TiFlashは、スレッドリソース制御を最適化するために、パイプライン実行モデルをサポートしています。
SQLデータインポート用の新しいSQL文「IMPORT INTO」をサポート（実験的） TiDB Lightningの導入とメンテナンスを簡素化するために、TiDB は新しい SQL文IMPORT INTO導入しました。これにより、Amazon S3 や Google Cloud Storage (GCS) からのリモートインポートを含むTiDB Lightningの物理インポートモードが TiDB に直接統合されます。
データベースの運用と可観測性DDLは一時停止および再開操作をサポートします（実験的）。この新機能により、インデックス作成などのリソースを大量に消費するDDL操作を一時的に中断し、リソースを節約してオンライントラフィックへの影響を最小限に抑えることができます。準備が整い次第、キャンセルや再起動の必要なく、これらの操作をシームレスに再開できます。この機能は、リソース利用効率の向上、ユーザーエクスペリエンスの改善、スキーマ変更の効率化に貢献します。
+
カテゴリ特徴説明
拡張性とパフォーマンスリソースグループは暴走クエリの管理をサポートします（実験的）クエリのタイムアウトをより細かく管理できるようになり、クエリの分類に基づいて異なる動作を設定できるようになりました。指定したしきい値に達したクエリは、優先度を下げたり、終了させたりすることができます。
TiFlashはパイプライン実行モデルをサポートしています（実験的）。 TiFlashは、スレッドリソース制御を最適化するために、パイプライン実行モデルをサポートしています。
SQLデータインポート用の新しいSQL文IMPORT INTOをサポート（実験的） TiDB Lightningの導入とメンテナンスを簡素化するために、TiDB は新しい SQL文IMPORT INTO導入しました。これにより、Amazon S3 や Google Cloud Storage (GCS) からのリモートインポートを含むTiDB Lightningの物理インポートモードが TiDB に直接統合されます。
データベースの運用と可観測性DDLは一時停止および再開操作をサポートします（実験的）。この新機能により、インデックス作成などのリソースを大量に消費するDDL操作を一時的に中断し、リソースを節約してオンライントラフィックへの影響を最小限に抑えることができます。準備が整い次第、キャンセルや再起動の必要なく、これらの操作をシームレスに再開できます。この機能は、リソース利用効率の向上、ユーザーエクスペリエンスの改善、スキーマ変更の効率化に貢献します。
## 機能の詳細 {#feature-details} diff --git a/releases/release-7.5.0.md b/releases/release-7.5.0.md index f45b6e6f120a7..1fec196115432 100644 --- a/releases/release-7.5.0.md +++ b/releases/release-7.5.0.md @@ -15,7 +15,7 @@ TiDB 7.5.0は長期サポートリリース（LTS）です。 以前の LTS 7.1.0 と比較して、7.5.0 には[7.2.0-DMR](/releases/release-7.2.0.md) 、 [7.3.0-DMR](/releases/release-7.3.0.md) 、および[7.4.0-DMR](/releases/release-7.4.0.md)でリリースされた新機能、改善点、およびバグ修正が含まれています。7.1.x から 7.5.0 にアップグレードすると、 [TiDB リリースノート PDF](https://docs-download.pingcap.com/pdf/tidb-v7.2-to-v7.5-en-release-notes.pdf)をダウンロードして、2つの LTS バージョン間のすべてのリリースノートを確認できます。次の表は、7.2.0 から 7.5.0 までのハイライトの一部を示しています。 -
カテゴリ特徴説明
拡張性とパフォーマンス複数のADD INDEXステートメントを並列実行することをサポートするこの機能により、単一のテーブルに対して複数のインデックスを同時に追加するジョブを実行できます。従来は、2つのADD INDEXステートメント（XとY ）を同時に実行するには、Xの実行時間とYの実行時間を合わせた時間が必要でした。この機能により、1つのSQLで2つのインデックスXとYを同時に追加できるため、DDLの実行時間が大幅に短縮されます。特に、テーブルサイズが大きいシナリオでは、社内テストデータによると、パフォーマンスが最大94%向上することが示されています。
信頼性と可用性グローバルソートの最適化（実験的、v7.4.0で導入） TiDB v7.1.0 では 、分散実行フレームワーク (DXF)が導入されました。v7.4 では、このフレームワークを活用するタスク向けにグローバルソートが導入され、データ再編成タスク中に一時的にデータが順不同になることで発生する不要な I/O、CPU、およびメモリの急増を解消します。グローバルソートは、外部共有オブジェクトストレージ(この最初のバージョンでは Amazon S3) を利用してジョブ実行中に中間ファイルを保存することで、柔軟性とコスト削減を実現します。ADD ADD INDEXやIMPORT INTOなどの操作は、より高速で、より堅牢で、より安定し、より柔軟になり、実行コストも削減されます。
バックグラウンドタスクのリソース制御（実験的、v7.4.0で導入）バージョン7.1.0では、ワークロード間のリソースおよびストレージアクセス干渉を軽減するために、リソース制御機能が導入されました。TiDB v7.4.0では、この制御がバックグラウンドタスクの優先度にも適用されるようになりました。v7.4.0では、リソース制御により、自動分析、バックアップと復元、 TiDB Lightningによる一括ロード、オンラインDDLなどのバックグラウンドタスクの実行優先度が識別され、管理されるようになりました。今後のリリースでは、この制御は最終的にすべてのバックグラウンドタスクに適用される予定です。
暴走クエリを管理するためのリソース制御（実験的、v7.2.0で導入）リソース制御は、リソースグループごとにワークロードをリソース分離するためのフレームワークですが、各グループ内の個々のクエリが作業にどのように影響するかについては何も規定していません。TiDB v7.2.0 では、「暴走クエリ制御」が導入され、リソースグループごとに TiDB がこれらのクエリをどのように識別して処理するかを制御できるようになりました。必要に応じて、実行時間の長いクエリを終了または制限することができ、クエリは、より汎用性を高めるために、正確な SQL テキスト、SQL ダイジェスト、または実行計画 ダイジェストで識別できます。v7.3.0 では、データベースレベルの SQL ブロックリストと同様に、既知の不正なクエリを事前に監視できるようになりました。
SQL MySQL 8.0との互換性（バージョン7.4.0で導入） MySQL 8.0 では、デフォルトの文字セットは utf8mb4 であり、utf8mb4 のデフォルトの照合照合順序はutf8mb4_0900_ai_ciです。TiDB v7.4.0 でこのサポートが追加されたことで、MySQL 8.0 との互換性が向上し、デフォルトの照合順序を持つ MySQL 8.0 データベースからの移行やレプリケーションがはるかにスムーズになりました。
データベースの運用と可観測性TiDB Lightningの物理インポートモードがIMPORT INTO (GA)でTiDBに統合されましたバージョン7.2.0より前は、ファイルシステムに基づいてデータをインポートするには、 TiDB Lightningをインストールし、その物理インポートモードを使用する必要がありました。現在では、同じ機能がIMPORT INTOステートメントに統合されているため、追加のツールをインストールすることなく、このステートメントを使用してデータを迅速にインポートできます。このステートメントは、並列インポート用の 分散実行フレームワーク（DXF）もサポートしており、大規模なインポート時のインポート効率が向上します。
ADD INDEXおよびIMPORT INTO SQL文を実行するTiDBノードを指定します（GA）。既存のTiDBノードの一部、または新しく追加されたTiDBノードでADD INDEXまたはIMPORT INTO SQL文を実行するかどうかを柔軟に指定できます。このアプローチにより、他のTiDBノードからリソースを分離できるため、業務への影響を防ぎながら、前述のSQL文の実行において最適なパフォーマンスを確保できます。この機能は、バージョン7.5.0で一般提供（GA）されます。
DDLは一時停止および再開操作をサポートします（一般提供）。インデックスの追加は大量のリソースを消費し、オンラインのトラフィックに影響を与える可能性があります。リソースグループでスロットリングしたり、ラベル付きノードに隔離したりした場合でも、緊急時にはこれらのジョブを一時停止する必要が生じる場合があります。TiDBはバージョン7.2.0以降、これらのバックグラウンドジョブを一度にいくつでも一時停止できる機能をネイティブにサポートしており、ジョブのキャンセルと再起動を回避しながら必要なリソースを解放できます。
TiDB DashboardはTiKVのヒーププロファイリングをサポートしています従来、TiKVのメモリ不足（OOM）やメモリ使用量過多の問題に対処するには、インスタンス環境でjeprofを手動で実行してヒーププロファイルを生成する必要がありました。v7.5.0以降、TiKVはヒーププロファイルのリモート処理に対応しました。これにより、ヒーププロファイルのフレームグラフとコールグラフに直接アクセスできるようになりました。この機能は、Goのヒーププロファイリングと同様に、シンプルで使いやすい操作性を提供します。
+
カテゴリ特徴説明
拡張性とパフォーマンス複数のADD INDEXステートメントを並列実行することをサポートするこの機能により、単一のテーブルに対して複数のインデックスを同時に追加するジョブを実行できます。従来は、2つのADD INDEXステートメント（XとY ）を同時に実行するには、Xの実行時間とYの実行時間を合わせた時間が必要でした。この機能により、1つのSQLで2つのインデックスXとYを同時に追加できるため、DDLの実行時間が大幅に短縮されます。特に、テーブルサイズが大きいシナリオでは、社内テストデータによると、パフォーマンスが最大94%向上することが示されています。
信頼性と可用性グローバルソートの最適化（実験的、v7.4.0で導入） TiDB v7.1.0 では 、分散実行フレームワーク (DXF)が導入されました。v7.4 では、このフレームワークを活用するタスク向けにグローバルソートが導入され、データ再編成タスク中に一時的にデータが順不同になることで発生する不要な I/O、CPU、およびメモリの急増を解消します。グローバルソートは、外部共有オブジェクトストレージ(この最初のバージョンでは Amazon S3) を利用してジョブ実行中に中間ファイルを保存することで、柔軟性とコスト削減を実現します。ADD ADD INDEXやIMPORT INTOなどの操作は、より高速で、より堅牢で、より安定し、より柔軟になり、実行コストも削減されます。
バックグラウンドタスクのリソース制御（実験的、v7.4.0で導入）バージョン7.1.0では、ワークロード間のリソースおよびストレージアクセス干渉を軽減するために、リソース制御機能が導入されました。TiDB v7.4.0では、この制御がバックグラウンドタスクの優先度にも適用されるようになりました。v7.4.0では、リソース制御により、自動分析、バックアップと復元、 TiDB Lightningによる一括ロード、オンラインDDLなどのバックグラウンドタスクの実行優先度が識別され、管理されるようになりました。今後のリリースでは、この制御は最終的にすべてのバックグラウンドタスクに適用される予定です。
暴走クエリを管理するためのリソース制御（実験的、v7.2.0で導入）リソース制御は、リソースグループごとにワークロードをリソース分離するためのフレームワークですが、各グループ内の個々のクエリが作業にどのように影響するかについては何も規定していません。TiDB v7.2.0 では、"runaway queries control"が導入され、リソースグループごとに TiDB がこれらのクエリをどのように識別して処理するかを制御できるようになりました。必要に応じて、実行時間の長いクエリを終了または制限することができ、クエリは、より汎用性を高めるために、正確な SQL テキスト、SQL ダイジェスト、または実行計画 ダイジェストで識別できます。v7.3.0 では、データベースレベルの SQL ブロックリストと同様に、既知の不正なクエリを事前に監視できるようになりました。
SQL MySQL 8.0との互換性（バージョン7.4.0で導入） MySQL 8.0 では、デフォルトの文字セットは utf8mb4 であり、utf8mb4 のデフォルトの照合照合順序はutf8mb4_0900_ai_ciです。TiDB v7.4.0 でこのサポートが追加されたことで、MySQL 8.0 との互換性が向上し、デフォルトの照合順序を持つ MySQL 8.0 データベースからの移行やレプリケーションがはるかにスムーズになりました。
データベースの運用と可観測性TiDB Lightningの物理インポートモードがIMPORT INTO (GA)でTiDBに統合されましたバージョン7.2.0より前は、ファイルシステムに基づいてデータをインポートするには、 TiDB Lightningをインストールし、その物理インポートモードを使用する必要がありました。現在では、同じ機能がIMPORT INTOステートメントに統合されているため、追加のツールをインストールすることなく、このステートメントを使用してデータを迅速にインポートできます。このステートメントは、並列インポート用の 分散実行フレームワーク（DXF）もサポートしており、大規模なインポート時のインポート効率が向上します。
ADD INDEXおよびIMPORT INTO SQL文を実行するTiDBノードを指定します（GA）。既存のTiDBノードの一部、または新しく追加されたTiDBノードでADD INDEXまたはIMPORT INTO SQL文を実行するかどうかを柔軟に指定できます。このアプローチにより、他のTiDBノードからリソースを分離できるため、業務への影響を防ぎながら、前述のSQL文の実行において最適なパフォーマンスを確保できます。この機能は、バージョン7.5.0で一般提供（GA）されます。
DDLは一時停止および再開操作をサポートします（一般提供）。インデックスの追加は大量のリソースを消費し、オンラインのトラフィックに影響を与える可能性があります。リソースグループでスロットリングしたり、ラベル付きノードに隔離したりした場合でも、緊急時にはこれらのジョブを一時停止する必要が生じる場合があります。TiDBはバージョン7.2.0以降、これらのバックグラウンドジョブを一度にいくつでも一時停止できる機能をネイティブにサポートしており、ジョブのキャンセルと再起動を回避しながら必要なリソースを解放できます。
TiDB DashboardはTiKVのヒーププロファイリングをサポートしています従来、TiKVのメモリ不足（OOM）やメモリ使用量過多の問題に対処するには、インスタンス環境でjeprofを手動で実行してヒーププロファイルを生成する必要がありました。v7.5.0以降、TiKVはヒーププロファイルのリモート処理に対応しました。これにより、ヒーププロファイルのフレームグラフとコールグラフに直接アクセスできるようになりました。この機能は、Goのヒーププロファイリングと同様に、シンプルで使いやすい操作性を提供します。
## 機能の詳細 {#feature-details} diff --git a/releases/release-7.5.1.md b/releases/release-7.5.1.md index 4745885509996..af85bfcb895af 100644 --- a/releases/release-7.5.1.md +++ b/releases/release-7.5.1.md @@ -237,4 +237,4 @@ TiDB バージョン: 7.5.1 - TiDB Data Migration (DM) - 下流のテーブル構造に`shard_row_id_bits` が含まれている場合に移行タスクエラーが発生する問題を修正しました [#10308](https://github.com/pingcap/tiflow/issues/10308) @[GMHDBJD](https://github.com/GMHDBJD) - - DM が「イベントタイプ切り捨てが無効です」というエラーに遭遇し、アップグレードが失敗する問題を修正しました[#10282](https://github.com/pingcap/tiflow/issues/10282) @[GMHDBJD](https://github.com/GMHDBJD) + - DM が"event type truncate not valid"というエラーに遭遇し、アップグレードが失敗する問題を修正しました[#10282](https://github.com/pingcap/tiflow/issues/10282) @[GMHDBJD](https://github.com/GMHDBJD) diff --git a/releases/release-7.6.0.md b/releases/release-7.6.0.md index b66af6c1f570a..984f06f15b91b 100644 --- a/releases/release-7.6.0.md +++ b/releases/release-7.6.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 7.6.0 バージョン7.6.0では、以下の主要な機能と改善点が導入されています。 -
カテゴリ機能／改善点説明
拡張性とパフォーマンスクロスデータベースSQLバインディング同じスキーマを持つ数百ものデータベースを管理する場合、これらのデータベース間でSQLバインディングを適用する必要が生じることがよくあります。例えば、SaaSやPaaSのデータプラットフォームでは、通常、各ユーザーが同じスキーマを持つ個別のデータベースを操作し、それらに対して同様のSQLクエリを実行します。このような場合、各データベースごとにSQLを個別にバインドするのは現実的ではありません。TiDB v7.6.0では、スキーマが同等のすべてのデータベース間でバインディングを一致させることができる、データベース間SQLバインディングが導入されました。
スナップショット復元速度を最大10倍向上（実験的） BR v7.6.0では、クラスターのスナップショット復元を高速化するための、実験的粗粒度リージョン分散アルゴリズムが導入されました。TiKVノードが多数存在するクラスターでは、このアルゴリズムにより、ノード間で負荷がより均等に分散され、ノードごとのネットワーク帯域幅がより有効に活用されるため、クラスターのリソース効率が大幅に向上します。実際のいくつかの事例では、この改善により復元プロセスが最大約10倍高速化されています。
テーブル作成をバッチ処理で行う際の処理速度を最大10倍向上（実験的）バージョン7.6.0で新しいDDLアーキテクチャが導入されたことで、バッチテーブル作成のパフォーマンスが最大10倍高速化され、目覚ましい改善が見られました。この大幅な機能強化により、多数のテーブルを作成するのに必要な時間が大幅に短縮されます。この高速化は、数十万から数十万ものテーブルが頻繁に発生するSaaS環境において特に顕著です。
アクティブなPDフォロワーを使用してPDのリージョン情報クエリサービスを強化する（実験的） TiDB v7.6.0では、実験的機能「アクティブPDFollower」が導入されました。これにより、PDフォロワーがリージョン情報クエリサービスを提供できるようになります。この機能は、多数のTiDBノードとリージョンを持つクラスターにおいて、PDクラスターがGetRegionおよびScanRegionsリクエストを処理する能力を向上させ、PDリーダーのCPU負荷を軽減します。
信頼性と可用性TiProxyのサポート（実験的） TiProxyサービスを完全にサポートし、デプロイツールを介して簡単にデプロイできます。これにより、TiDBへの接続を管理および維持し、ローリング再起動、アップグレード、またはスケーリングイベント後も接続が維持されます。
データ移行（DM）は、MySQL 8.0（GA）を正式にサポートします。これまで、DMを使用してMySQL 8.0からデータを移行する機能は実験的機能であり、本番環境では利用できませんでした。TiDB v7.6.0では、この機能の安定性と互換性が向上し、本番環境においてMySQL 8.0からTiDBへのデータ移行をスムーズかつ迅速に行えるようになりました。v7.6.0では、この機能が一般提供（GA）となります。
+
カテゴリ機能／改善点説明
拡張性とパフォーマンスクロスデータベースSQLバインディング同じスキーマを持つ数百ものデータベースを管理する場合、これらのデータベース間でSQLバインディングを適用する必要が生じることがよくあります。例えば、SaaSやPaaSのデータプラットフォームでは、通常、各ユーザーが同じスキーマを持つ個別のデータベースを操作し、それらに対して同様のSQLクエリを実行します。このような場合、各データベースごとにSQLを個別にバインドするのは現実的ではありません。TiDB v7.6.0では、スキーマが同等のすべてのデータベース間でバインディングを一致させることができる、データベース間SQLバインディングが導入されました。
スナップショット復元速度を最大10倍向上（実験的） BR v7.6.0では、クラスターのスナップショット復元を高速化するための、実験的粗粒度リージョン分散アルゴリズムが導入されました。TiKVノードが多数存在するクラスターでは、このアルゴリズムにより、ノード間で負荷がより均等に分散され、ノードごとのネットワーク帯域幅がより有効に活用されるため、クラスターのリソース効率が大幅に向上します。実際のいくつかの事例では、この改善により復元プロセスが最大約10倍高速化されています。
テーブル作成をバッチ処理で行う際の処理速度を最大10倍向上（実験的）バージョン7.6.0で新しいDDLアーキテクチャが導入されたことで、バッチテーブル作成のパフォーマンスが最大10倍高速化され、目覚ましい改善が見られました。この大幅な機能強化により、多数のテーブルを作成するのに必要な時間が大幅に短縮されます。この高速化は、数十万から数十万ものテーブルが頻繁に発生するSaaS環境において特に顕著です。
アクティブなPDフォロワーを使用してPDのリージョン情報クエリサービスを強化する（実験的） TiDB v7.6.0では、実験的機能"Active PD Follower"が導入されました。これにより、PDフォロワーがリージョン情報クエリサービスを提供できるようになります。この機能は、多数のTiDBノードとリージョンを持つクラスターにおいて、PDクラスターがGetRegionおよびScanRegionsリクエストを処理する能力を向上させ、PDリーダーのCPU負荷を軽減します。
信頼性と可用性TiProxyのサポート（実験的） TiProxyサービスを完全にサポートし、デプロイツールを介して簡単にデプロイできます。これにより、TiDBへの接続を管理および維持し、ローリング再起動、アップグレード、またはスケーリングイベント後も接続が維持されます。
データ移行（DM）は、MySQL 8.0（GA）を正式にサポートします。これまで、DMを使用してMySQL 8.0からデータを移行する機能は実験的機能であり、本番環境では利用できませんでした。TiDB v7.6.0では、この機能の安定性と互換性が向上し、本番環境においてMySQL 8.0からTiDBへのデータ移行をスムーズかつ迅速に行えるようになりました。v7.6.0では、この機能が一般提供（GA）となります。
## 機能の詳細 {#feature-details} diff --git a/releases/release-8.1.0.md b/releases/release-8.1.0.md index 049bb4cea70df..2c85ed2068084 100644 --- a/releases/release-8.1.0.md +++ b/releases/release-8.1.0.md @@ -17,7 +17,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 以前のLTSバージョン7.5.0と比較して、8.1.0にはバージョン[7.6.0-DMR](/releases/release-7.6.0.md)と[8.0.0-DMR](/releases/release-8.0.0.md)でリリースされた新機能、改善、バグ修正が含まれています。7.5.xから8.1.0にアップグレードする場合は、バージョン[TiDB リリースノート PDF](https://docs-download.pingcap.com/pdf/tidb-v7.6-to-v8.1-en-release-notes.pdf)をダウンロードして、2つのLTSバージョン間のすべてのリリースノートをご覧いただけます。以下の表は、7.6.0から8.1.0への主な変更点です。 -
カテゴリ機能/拡張機能説明
スケーラビリティとパフォーマンスクラスター スナップショットの復元速度の高速化(v8.0.0 で GA)この機能により、 BRはクラスタのスケールメリットを最大限に活用し、クラスタ内のすべてのTiKVノードがデータ復元の準備ステップに参加できるようになります。この機能により、大規模クラスタにおける大規模データセットの復元速度が大幅に向上します。実環境テストでは、この機能によりダウンロード帯域幅が飽和状態になり、ダウンロード速度が8～10倍、エンドツーエンドの復元速度が約1.5～3倍向上することが示されています。
バッチでテーブルを作成する場合、最大 10 倍の高速化を実現します(実験的、v7.6.0 で導入) v7.6.0での新しいDDLアーキテクチャの実装により、バッチテーブル作成のパフォーマンスが大幅に向上し、最大10倍高速化しました。この大幅な機能強化により、多数のテーブル作成に必要な時間が大幅に短縮されます。この高速化は、数万から数十万に及ぶ大量のテーブルが頻繁に使用されるSaaSシナリオにおいて特に顕著です。
アクティブ PD フォロワーを使用して、PD のリージョン情報クエリサービスを強化します(実験的、v7.6.0 で導入) TiDB v7.6.0では、PDフォロワーがリージョン情報クエリサービスを提供できる実験的機能「Active PD Follower 」が導入されました。この機能により、多数のTiDBノードとリージョンを持つクラスターにおいて、PDクラスターのGetRegionおよびScanRegionsリクエスト処理能力が向上し、PDリーダーのCPU負荷が軽減されます。
大規模なトランザクションのためのバルク DML (実験的、v8.0.0 で導入)大規模なクリーンアップジョブ、結合、集計といった大規模なバッチDMLジョブは、大量のメモリを消費する可能性があり、これまでは非常に大規模なスケールでは制限されていました。バルクDML（ tidb_dml_type = "bulk" ）は、トランザクション保証を提供し、OOM（メモリ不足）の問題を軽減しながら、大規模なバッチDMLタスクをより効率的に処理するための新しいDMLタイプです。この機能は、データのロードに使用する場合、インポート、ロード、リストアの各操作とは異なります。
膨大な数のテーブルがある場合のスキーマ情報のキャッシュの安定性を向上 (実験的、v8.0.0 で導入)マルチテナントアプリケーションの記録システムとしてTiDBを使用しているSaaS企業は、多くの場合、膨大な数のテーブルを保存する必要があります。以前のバージョンでは、100万個以上のテーブル数を処理することは可能でしたが、全体的なユーザーエクスペリエンスが低下する可能性がありました。TiDB v8.0.0では、 auto analyzeに優先キューを実装することで状況が改善され、プロセスの柔軟性が向上し、より広範なテーブルにわたる安定性が向上しました。
信頼性と可用性グローバルソート（v8.0.0 で GA）グローバルソート機能は、 IMPORT INTOおよびCREATE INDEXの安定性と効率性を向上させることを目的としています。処理対象のデータをグローバルにソートすることで、TiKVへのデータ書き込みの安定性、制御性、スケーラビリティが向上し、結果としてデータのインポートとインデックス作成におけるユーザーエクスペリエンスとサービス品質が向上します。グローバルソートを有効にすると、各IMPORT INTOまたはCREATE INDEXステートメントで、最大40TiBのデータのインポートまたはインデックスの追加がサポートされるようになりました。
データベース間 SQL バインディング(v7.6.0 で導入)同じスキーマを持つ数百のデータベースを管理する場合、これらのデータベース全体にSQLバインディングを適用する必要があることがよくあります。例えば、SaaSまたはPaaSデータプラットフォームでは、各ユーザーは通常、同じスキーマを持つ別々のデータベースを操作し、それらに対して類似のSQLクエリを実行します。このような場合、各データベースにSQLを個別にバインドするのは現実的ではありません。TiDB v7.6.0では、スキーマが同等なすべてのデータベース間で一致するバインディングを可能にする、データベース間SQLバインディングが導入されています。
TiProxy をサポート(v8.0.0 で GA)デプロイメントツールを使用して簡単にデプロイできる TiProxy サービスを完全にサポートし、ローリング リスタート、アップグレード、またはスケーリング イベントを通じて TiDB への接続を管理および維持できるようにします。
データ移行（DM）はMySQL 8.0（バージョン7.6.0でGA）を正式にサポートしますこれまで、DMを使用したMySQL 8.0からのデータ移行は実験的機能であり、本番環境ではご利用いただけませんでした。TiDB v7.6.0では、この機能の安定性と互換性が向上し、本番環境においてMySQL 8.0からTiDBへのデータ移行をスムーズかつ迅速に実行できるようになります。v7.6.0では、この機能が一般提供（GA）されます。
TiDB リソース制御は、予想よりも多くのリソースを消費するクエリの管理をサポートします (v8.1.0 で GA) TiDBは、リソースグループのルールを通じて、予想以上にリソースを消費するクエリを自動的に識別し、それらのクエリを制限またはキャンセルすることができます。ルールで識別されないクエリでも、手動でクエリ特性を追加し、適切な対策を講じることで、突発的なクエリパフォーマンスの問題がデータベース全体に与える影響を軽減できます。
DB操作と可観測性インデックス使用状況統計の監視をサポート（v8.0.0 で導入）適切なインデックス設計は、データベースのパフォーマンス維持に不可欠な前提条件です。TiDB v8.0.0では、インデックスの使用状況統計を提供するINFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブルとsys.schema_unused_indexesビューが導入されました。この機能は、データベース内のインデックスの効率性を評価し、インデックス設計を最適化するのに役立ちます。
データ移行TiCDC はSimpleプロトコルをサポートしています (v8.0.0 で導入) TiCDCは、新しいプロトコル「Simpleプロトコル」を導入しました。このプロトコルは、DDLおよびBOOTSTRAPイベントにテーブルスキーマ情報を埋め込むことで、スキーマをインバンドで追跡する機能を提供します。
TiCDC はDebezium 形式プロトコル(v8.0.0 で導入) をサポートしています。 TiCDC は新しいプロトコル、Debezium プロトコルを導入しました。TiCDC は、Debezium スタイルのメッセージを生成するプロトコルを使用して、データ変更イベントを Kafka シンクにパブリッシュできるようになりました。
TiCDC はクライアント認証をサポートしています (v8.1.0 で導入) TiCDCは、相互トランスポート層Security（mTLS）またはTiDBユーザー名とパスワードを使用したクライアント認証をサポートしています。この機能により、CLIまたはOpenAPIクライアントはTiCDCへの接続を認証できます。
+
カテゴリ機能/拡張機能説明
スケーラビリティとパフォーマンスクラスター スナップショットの復元速度の高速化(v8.0.0 で GA)この機能により、 BRはクラスタのスケールメリットを最大限に活用し、クラスタ内のすべてのTiKVノードがデータ復元の準備ステップに参加できるようになります。この機能により、大規模クラスタにおける大規模データセットの復元速度が大幅に向上します。実環境テストでは、この機能によりダウンロード帯域幅が飽和状態になり、ダウンロード速度が8～10倍、エンドツーエンドの復元速度が約1.5～3倍向上することが示されています。
バッチでテーブルを作成する場合、最大 10 倍の高速化を実現します(実験的、v7.6.0 で導入) v7.6.0での新しいDDLアーキテクチャの実装により、バッチテーブル作成のパフォーマンスが大幅に向上し、最大10倍高速化しました。この大幅な機能強化により、多数のテーブル作成に必要な時間が大幅に短縮されます。この高速化は、数万から数十万に及ぶ大量のテーブルが頻繁に使用されるSaaSシナリオにおいて特に顕著です。
アクティブ PD フォロワーを使用して、PD のリージョン情報クエリサービスを強化します(実験的、v7.6.0 で導入) TiDB v7.6.0では、PDフォロワーがリージョン情報クエリサービスを提供できる実験的機能"Active PD Follower"が導入されました。この機能により、多数のTiDBノードとリージョンを持つクラスターにおいて、PDクラスターのGetRegionおよびScanRegionsリクエスト処理能力が向上し、PDリーダーのCPU負荷が軽減されます。
大規模なトランザクションのためのバルク DML (実験的、v8.0.0 で導入)大規模なクリーンアップジョブ、結合、集計といった大規模なバッチDMLジョブは、大量のメモリを消費する可能性があり、これまでは非常に大規模なスケールでは制限されていました。バルクDML（ tidb_dml_type = "bulk" ）は、トランザクション保証を提供し、OOM（メモリ不足）の問題を軽減しながら、大規模なバッチDMLタスクをより効率的に処理するための新しいDMLタイプです。この機能は、データのロードに使用する場合、インポート、ロード、リストアの各操作とは異なります。
膨大な数のテーブルがある場合のスキーマ情報のキャッシュの安定性を向上 (実験的、v8.0.0 で導入)マルチテナントアプリケーションの記録システムとしてTiDBを使用しているSaaS企業は、多くの場合、膨大な数のテーブルを保存する必要があります。以前のバージョンでは、100万個以上のテーブル数を処理することは可能でしたが、全体的なユーザーエクスペリエンスが低下する可能性がありました。TiDB v8.0.0では、 auto analyzeに優先キューを実装することで状況が改善され、プロセスの柔軟性が向上し、より広範なテーブルにわたる安定性が向上しました。
信頼性と可用性グローバルソート（v8.0.0 で GA）グローバルソート機能は、 IMPORT INTOおよびCREATE INDEXの安定性と効率性を向上させることを目的としています。処理対象のデータをグローバルにソートすることで、TiKVへのデータ書き込みの安定性、制御性、スケーラビリティが向上し、結果としてデータのインポートとインデックス作成におけるユーザーエクスペリエンスとサービス品質が向上します。グローバルソートを有効にすると、各IMPORT INTOまたはCREATE INDEXステートメントで、最大40TiBのデータのインポートまたはインデックスの追加がサポートされるようになりました。
データベース間 SQL バインディング(v7.6.0 で導入)同じスキーマを持つ数百のデータベースを管理する場合、これらのデータベース全体にSQLバインディングを適用する必要があることがよくあります。例えば、SaaSまたはPaaSデータプラットフォームでは、各ユーザーは通常、同じスキーマを持つ別々のデータベースを操作し、それらに対して類似のSQLクエリを実行します。このような場合、各データベースにSQLを個別にバインドするのは現実的ではありません。TiDB v7.6.0では、スキーマが同等なすべてのデータベース間で一致するバインディングを可能にする、データベース間SQLバインディングが導入されています。
TiProxy をサポート(v8.0.0 で GA)デプロイメントツールを使用して簡単にデプロイできる TiProxy サービスを完全にサポートし、ローリング リスタート、アップグレード、またはスケーリング イベントを通じて TiDB への接続を管理および維持できるようにします。
データ移行（DM）はMySQL 8.0（バージョン7.6.0でGA）を正式にサポートしますこれまで、DMを使用したMySQL 8.0からのデータ移行は実験的機能であり、本番環境ではご利用いただけませんでした。TiDB v7.6.0では、この機能の安定性と互換性が向上し、本番環境においてMySQL 8.0からTiDBへのデータ移行をスムーズかつ迅速に実行できるようになります。v7.6.0では、この機能が一般提供（GA）されます。
TiDB リソース制御は、予想よりも多くのリソースを消費するクエリの管理をサポートします (v8.1.0 で GA) TiDBは、リソースグループのルールを通じて、予想以上にリソースを消費するクエリを自動的に識別し、それらのクエリを制限またはキャンセルすることができます。ルールで識別されないクエリでも、手動でクエリ特性を追加し、適切な対策を講じることで、突発的なクエリパフォーマンスの問題がデータベース全体に与える影響を軽減できます。
DB操作と可観測性インデックス使用状況統計の監視をサポート（v8.0.0 で導入）適切なインデックス設計は、データベースのパフォーマンス維持に不可欠な前提条件です。TiDB v8.0.0では、インデックスの使用状況統計を提供するINFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブルとsys.schema_unused_indexesビューが導入されました。この機能は、データベース内のインデックスの効率性を評価し、インデックス設計を最適化するのに役立ちます。
データ移行TiCDC はSimpleプロトコルをサポートしています (v8.0.0 で導入) TiCDCは、新しいプロトコル「Simpleプロトコル」を導入しました。このプロトコルは、DDLおよびBOOTSTRAPイベントにテーブルスキーマ情報を埋め込むことで、スキーマをインバンドで追跡する機能を提供します。
TiCDC はDebezium 形式プロトコル(v8.0.0 で導入) をサポートしています。 TiCDC は新しいプロトコル、Debezium プロトコルを導入しました。TiCDC は、Debezium スタイルのメッセージを生成するプロトコルを使用して、データ変更イベントを Kafka シンクにパブリッシュできるようになりました。
TiCDC はクライアント認証をサポートしています (v8.1.0 で導入) TiCDCは、相互トランスポート層Security（mTLS）またはTiDBユーザー名とパスワードを使用したクライアント認証をサポートしています。この機能により、CLIまたはOpenAPIクライアントはTiCDCへの接続を認証できます。
## 機能の詳細 {#feature-details} @@ -122,8 +122,8 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 | TiCDC | [`security.client-allowed-user`](/ticdc/ticdc-server-config.md#cdc-server-configuration-file-parameters) | 新しく追加された | クライアント認証に許可されるユーザー名をリストします。このリストに含まれていないユーザー名による認証要求は拒否されます。デフォルト値はnullです。 | | TiCDC | [`security.client-user-required`](/ticdc/ticdc-server-config.md#cdc-server-configuration-file-parameters) | 新しく追加された | クライアント認証にユーザー名とパスワードを使用するかどうかを制御します。デフォルト値は`false`です。 | | TiCDC | [`security.mtls`](/ticdc/ticdc-server-config.md#cdc-server-configuration-file-parameters) | 新しく追加された | TLSクライアント認証を有効にするかどうかを制御します。デフォルト値は`false`です。 | -| TiCDC | [`sink.debezium.output-old-value`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | 行データが変更される前の値を出力するかどうかを制御します。デフォルト値は`true`です。無効にすると、 `UPDATE`イベントは「before」フィールドを出力しません。 | -| TiCDC | [`sink.open.output-old-value`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | 行データが変更される前に値を出力するかどうかを制御します。デフォルト値は`true`です。無効にすると、イベント`UPDATE`は「p」フィールドを出力しません。 | +| TiCDC | [`sink.debezium.output-old-value`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | 行データが変更される前の値を出力するかどうかを制御します。デフォルト値は`true`です。無効にすると、 `UPDATE`イベントは"before"フィールドを出力しません。 | +| TiCDC | [`sink.open.output-old-value`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | 行データが変更される前に値を出力するかどうかを制御します。デフォルト値は`true`です。無効にすると、イベント`UPDATE`は"p"フィールドを出力しません。 | ## 非推奨の機能 {#deprecated-features} diff --git a/releases/release-8.5.0.md b/releases/release-8.5.0.md index c55d51ce4e4de..d9f3ffd267ad1 100644 --- a/releases/release-8.5.0.md +++ b/releases/release-8.5.0.md @@ -17,7 +17,7 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 以前の LTS 8.1.0 と比較して、8.5.0 には[8.2.0-DMR](/releases/release-8.2.0.md) 、 [8.3.0-DMR](/releases/release-8.3.0.md) 、および[8.4.0-DMR](/releases/release-8.4.0.md)でリリースされた新機能、改善点、およびバグ修正が含まれています。8.1.x から 8.5.0 にアップグレードすると、 [TiDB リリースノート PDF](https://docs-download.pingcap.com/pdf/tidb-v8.2-to-v8.5-en-release-notes.pdf)をダウンロードして、2つの LTS バージョン間のすべてのリリースノートを確認できます。次の表は、8.1.0 から 8.5.0 までのハイライトの一部を示しています。 -
カテゴリ機能／改善点説明
拡張性とパフォーマンス複数の次元でデータ処理のレイテンシーを削減するTiDBは、パフォーマンス向上のためにデータ処理を継続的に改良し、金融分野における低遅延SQL処理の要件を効果的に満たしています。主なアップデート内容は以下のとおりです。
TiKV MVCC インメモリエンジン (IME) (バージョン8.5.0で導入) TiKV MVCCのインメモリエンジンは、最新のMVCCバージョンのデータをメモリにキャッシュすることで、古いバージョンをスキップして最新のデータを迅速に取得できるようにします。この機能は、データレコードが頻繁に更新される場合や、履歴バージョンが長期間保持される場合に、データスキャン性能を大幅に向上させることができます。
アクティブなPDフォロワーを使用して、PDのリージョン情報クエリサービスを強化します（v8.5.0で一般提供開始）。 TiDB v7.6.0 では、実験的機能「アクティブ PDFollower」が導入されました。これにより、PD フォロワーがリージョン情報クエリサービスを提供できるようになります。この機能は、多数の TiDB ノードとリージョンを持つクラスターにおいて、PD クラスターがGetRegionおよびScanRegionsリクエストを処理する能力を向上させ、PD リーダーの CPU 負荷を軽減します。この機能は、v8.5.0 で一般提供 (GA) されます。
インスタンスレベルの実行プランキャッシュ（実験的、v8.4.0で導入）インスタンスレベルのプランキャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションでプランキャッシュを共有できます。セッションレベルのプランキャッシュと比較して、この機能はメモリに多くの実行計画をキャッシュすることで SQL コンパイル時間を短縮し、SQL 全体の実行時間を短縮します。これにより、OLTP のパフォーマンスとスループットが向上するとともに、メモリ使用量をより適切に制御し、データベースの安定性を高めることができます。
パーティションテーブルのグローバルインデックス（バージョン8.4.0で一般提供開始）グローバルインデックスは、パーティション化されていない列の取得効率を効果的に向上させ、一意キーにパーティションキーを含める必要があるという制約を取り除きます。この機能により、TiDBパーティションテーブルの利用シナリオが拡張され、パーティションテーブルのパフォーマンスが向上し、特定のクエリシナリオにおけるリソース消費量が削減されます。
Projectionオペレーターをストレージエンジンにデフォルトでプッシュダウンする機能（v8.3.0で導入） Projectionオペレーターをストレージエンジンにプッシュダウンすることで、ストレージノード全体に負荷を分散させ、ノード間のデータ転送量を削減できます。この最適化により、特定のSQLクエリの実行時間が短縮され、データベース全体のパフォーマンスが向上します。
統計情報を収集する際に不要な列を無視する機能（バージョン8.3.0で導入）オプティマイザが必要な情報を確実に取得できるという前提のもと、TiDBは統計情報の収集を高速化し、統計情報の適時性を向上させることで、最適な実行計画の選択を保証し、クラスタのパフォーマンスを向上させます。同時に、TiDBはシステムオーバーヘッドを削減し、リソース利用率も向上させます。
信頼性と可用性大規模クラスターの安定性を向上させるTiDBを使用してマルチテナントアプリケーションやSaaSアプリケーションを運用する企業は、多くの場合、大量のテーブルを保存する必要があります。バージョン8.5.0では、TiDBは大規模クラスタの安定性を大幅に向上させました。
暴走クエリに対するトリガーの追加サポート、およびリソースグループの切り替えサポート（v8.4.0で導入）暴走クエリは、予期しないSQLパフォーマンスの問題がシステムに与える影響を軽減する効果的な手段です。TiDB v8.4.0では、識別条件としてコプロセッサーによって処理されたキーの数（ PROCESSED_KEYS ）とリクエストユニット（ RU ）が導入され、識別されたクエリを指定されたリソースグループに配置することで、暴走クエリのより正確な識別と制御が可能になりました。
リソース制御のバックグラウンドタスクにおけるリソース使用量の上限設定をサポート（実験的、v8.4.0で導入）リソース制御のバックグラウンドタスクに最大パーセンテージ制限を設定することで、さまざまなアプリケーションシステムのニーズに基づいてリソース消費を制御できます。これにより、バックグラウンドタスクの消費量を低く抑え、オンラインサービスの品質を確保できます。
TiProxyのユースケースを強化および拡張するTiDBの高可用性を実現する上で重要なコンポーネントであるTiProxyは、SQLトラフィックのアクセスと転送にとどまらず、クラスタ変更の評価をサポートする機能も備えています。主な機能は以下のとおりです。
TiDBの並列HashAggアルゴリズムはディスクスピルをサポートしています（v8.2.0でGA対応）。 HashAgg は、同じフィールド値を持つ行を効率的に集計するために TiDB で広く使用されている集計オペレーターです。TiDB v8.0.0 では、処理速度をさらに向上させる実験的機能として parallel HashAgg が導入されました。メモリリソースが不足している場合、parallel HashAgg は一時的にソートされたデータをディスクに書き出すことで、過剰なメモリ使用による潜在的な OOM リスクを回避します。これにより、ノードの安定性を維持しながらクエリパフォーマンスが向上します。v8.2.0 では、この機能が一般提供 (GA) となり、デフォルトで有効になっているため、 tidb_executor_concurrencyを使用して parallel HashAgg の同時実行性を安全に構成できます。
SQL外部キー（バージョン8.5.0でGA対応）外部キーは、データベースにおける制約であり、テーブル間の関係を確立し、データの一貫性と整合性を確保します。外部キーは、子テーブルで参照されるデータが親テーブルに存在することを保証し、無効なデータの挿入を防ぎます。また、外部キーはカスケード操作（削除や更新時の自動同期など）をサポートし、ビジネスロジックの実装を簡素化し、データ関係を手動で維持する複雑さを軽減します。
ベクトル検索（実験的、v8.4.0で導入）ベクトル検索は、データの意味論に基づいた検索手法であり、より関連性の高い検索結果を提供します。AIや大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は、検索拡張生成（RAG）、意味検索、推薦システムなど、さまざまなシナリオで活用できます。
データベースの運用と可観測性TiKVおよびTiDBのCPU時間をメモリテーブルに表示する（バージョン8.4.0で導入） CPU時間はシステムテーブルに統合され、セッションやSQLなどの他のメトリックと並べて表示されるようになりました。これにより、CPU使用率の高い操作を複数の視点から把握し、診断効率を向上させることができます。これは、インスタンスにおけるCPUスパイクやクラスタにおける読み書きホットスポットなどのシナリオを診断する際に特に役立ちます。
TiKVのCPU時間をテーブル別またはデータベース別に集計して表示する機能をサポート（v8.4.0で導入）ホットスポットの問題が個々のSQL文によって引き起こされていない場合、 Top SQLでテーブルまたはデータベースレベルごとに集計されたCPU時間を使用することで、ホットスポットの原因となっているテーブルやアプリケーションを迅速に特定でき、ホットスポットやCPU消費の問題の診断効率を大幅に向上させることができます。
Backup & Restore (BR)は、 AWS SDK for Rustを使用して外部ストレージにアクセスします (v8.5.0 で導入)。 BRは、TiKVからAmazon S3などの外部ストレージにアクセスするために、元のRusotoライブラリをAWS SDK for Rustに置き換えます。この変更により、 IMDSv2やEKS Pod IdentityなどのAWS機能との互換性が向上します。
Securityスナップショットバックアップデータおよびログバックアップデータのクライアント側暗号化（v8.5.0で一般提供開始）バックアップデータをバックアップストレージにアップロードする前に、バックアップデータを暗号化することで、保管中および転送中のセキュリティを確保できます。
+
カテゴリ機能／改善点説明
拡張性とパフォーマンス複数の次元でデータ処理のレイテンシーを削減するTiDBは、パフォーマンス向上のためにデータ処理を継続的に改良し、金融分野における低遅延SQL処理の要件を効果的に満たしています。主なアップデート内容は以下のとおりです。
TiKV MVCC インメモリエンジン (IME) (バージョン8.5.0で導入) TiKV MVCCのインメモリエンジンは、最新のMVCCバージョンのデータをメモリにキャッシュすることで、古いバージョンをスキップして最新のデータを迅速に取得できるようにします。この機能は、データレコードが頻繁に更新される場合や、履歴バージョンが長期間保持される場合に、データスキャン性能を大幅に向上させることができます。
アクティブなPDフォロワーを使用して、PDのリージョン情報クエリサービスを強化します（v8.5.0で一般提供開始）。 TiDB v7.6.0 では、実験的機能"Active PD Follower"が導入されました。これにより、PD フォロワーがリージョン情報クエリサービスを提供できるようになります。この機能は、多数の TiDB ノードとリージョンを持つクラスターにおいて、PD クラスターがGetRegionおよびScanRegionsリクエストを処理する能力を向上させ、PD リーダーの CPU 負荷を軽減します。この機能は、v8.5.0 で一般提供 (GA) されます。
インスタンスレベルの実行プランキャッシュ（実験的、v8.4.0で導入）インスタンスレベルのプランキャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションでプランキャッシュを共有できます。セッションレベルのプランキャッシュと比較して、この機能はメモリに多くの実行計画をキャッシュすることで SQL コンパイル時間を短縮し、SQL 全体の実行時間を短縮します。これにより、OLTP のパフォーマンスとスループットが向上するとともに、メモリ使用量をより適切に制御し、データベースの安定性を高めることができます。
パーティションテーブルのグローバルインデックス（バージョン8.4.0で一般提供開始）グローバルインデックスは、パーティション化されていない列の取得効率を効果的に向上させ、一意キーにパーティションキーを含める必要があるという制約を取り除きます。この機能により、TiDBパーティションテーブルの利用シナリオが拡張され、パーティションテーブルのパフォーマンスが向上し、特定のクエリシナリオにおけるリソース消費量が削減されます。
Projectionオペレーターをストレージエンジンにデフォルトでプッシュダウンする機能（v8.3.0で導入） Projectionオペレーターをストレージエンジンにプッシュダウンすることで、ストレージノード全体に負荷を分散させ、ノード間のデータ転送量を削減できます。この最適化により、特定のSQLクエリの実行時間が短縮され、データベース全体のパフォーマンスが向上します。
統計情報を収集する際に不要な列を無視する機能（バージョン8.3.0で導入）オプティマイザが必要な情報を確実に取得できるという前提のもと、TiDBは統計情報の収集を高速化し、統計情報の適時性を向上させることで、最適な実行計画の選択を保証し、クラスタのパフォーマンスを向上させます。同時に、TiDBはシステムオーバーヘッドを削減し、リソース利用率も向上させます。
信頼性と可用性大規模クラスターの安定性を向上させるTiDBを使用してマルチテナントアプリケーションやSaaSアプリケーションを運用する企業は、多くの場合、大量のテーブルを保存する必要があります。バージョン8.5.0では、TiDBは大規模クラスタの安定性を大幅に向上させました。
暴走クエリに対するトリガーの追加サポート、およびリソースグループの切り替えサポート（v8.4.0で導入）暴走クエリは、予期しないSQLパフォーマンスの問題がシステムに与える影響を軽減する効果的な手段です。TiDB v8.4.0では、識別条件としてコプロセッサーによって処理されたキーの数（ PROCESSED_KEYS ）とリクエストユニット（ RU ）が導入され、識別されたクエリを指定されたリソースグループに配置することで、暴走クエリのより正確な識別と制御が可能になりました。
リソース制御のバックグラウンドタスクにおけるリソース使用量の上限設定をサポート（実験的、v8.4.0で導入）リソース制御のバックグラウンドタスクに最大パーセンテージ制限を設定することで、さまざまなアプリケーションシステムのニーズに基づいてリソース消費を制御できます。これにより、バックグラウンドタスクの消費量を低く抑え、オンラインサービスの品質を確保できます。
TiProxyのユースケースを強化および拡張するTiDBの高可用性を実現する上で重要なコンポーネントであるTiProxyは、SQLトラフィックのアクセスと転送にとどまらず、クラスタ変更の評価をサポートする機能も備えています。主な機能は以下のとおりです。
TiDBの並列HashAggアルゴリズムはディスクスピルをサポートしています（v8.2.0でGA対応）。 HashAgg は、同じフィールド値を持つ行を効率的に集計するために TiDB で広く使用されている集計オペレーターです。TiDB v8.0.0 では、処理速度をさらに向上させる実験的機能として parallel HashAgg が導入されました。メモリリソースが不足している場合、parallel HashAgg は一時的にソートされたデータをディスクに書き出すことで、過剰なメモリ使用による潜在的な OOM リスクを回避します。これにより、ノードの安定性を維持しながらクエリパフォーマンスが向上します。v8.2.0 では、この機能が一般提供 (GA) となり、デフォルトで有効になっているため、 tidb_executor_concurrencyを使用して parallel HashAgg の同時実行性を安全に構成できます。
SQL外部キー（バージョン8.5.0でGA対応）外部キーは、データベースにおける制約であり、テーブル間の関係を確立し、データの一貫性と整合性を確保します。外部キーは、子テーブルで参照されるデータが親テーブルに存在することを保証し、無効なデータの挿入を防ぎます。また、外部キーはカスケード操作（削除や更新時の自動同期など）をサポートし、ビジネスロジックの実装を簡素化し、データ関係を手動で維持する複雑さを軽減します。
ベクトル検索（実験的、v8.4.0で導入）ベクトル検索は、データの意味論に基づいた検索手法であり、より関連性の高い検索結果を提供します。AIや大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は、検索拡張生成（RAG）、意味検索、推薦システムなど、さまざまなシナリオで活用できます。
データベースの運用と可観測性TiKVおよびTiDBのCPU時間をメモリテーブルに表示する（バージョン8.4.0で導入） CPU時間はシステムテーブルに統合され、セッションやSQLなどの他のメトリックと並べて表示されるようになりました。これにより、CPU使用率の高い操作を複数の視点から把握し、診断効率を向上させることができます。これは、インスタンスにおけるCPUスパイクやクラスタにおける読み書きホットスポットなどのシナリオを診断する際に特に役立ちます。
TiKVのCPU時間をテーブル別またはデータベース別に集計して表示する機能をサポート（v8.4.0で導入）ホットスポットの問題が個々のSQL文によって引き起こされていない場合、 Top SQLでテーブルまたはデータベースレベルごとに集計されたCPU時間を使用することで、ホットスポットの原因となっているテーブルやアプリケーションを迅速に特定でき、ホットスポットやCPU消費の問題の診断効率を大幅に向上させることができます。
Backup & Restore (BR)は、 AWS SDK for Rustを使用して外部ストレージにアクセスします (v8.5.0 で導入)。 BRは、TiKVからAmazon S3などの外部ストレージにアクセスするために、元のRusotoライブラリをAWS SDK for Rustに置き換えます。この変更により、 IMDSv2やEKS Pod IdentityなどのAWS機能との互換性が向上します。
Securityスナップショットバックアップデータおよびログバックアップデータのクライアント側暗号化（v8.5.0で一般提供開始）バックアップデータをバックアップストレージにアップロードする前に、バックアップデータを暗号化することで、保管中および転送中のセキュリティを確保できます。
## 機能の詳細 {#feature-details} diff --git a/releases/release-rc.1.md b/releases/release-rc.1.md index 4d3efec8c2c4c..e99ca18b2d730 100644 --- a/releases/release-rc.1.md +++ b/releases/release-rc.1.md @@ -1,6 +1,6 @@ --- title: TiDB RC1 Release Notes -summary: TiDB RC1は2016年12月23日にリリースされました。アップデートには、TiKVの書き込み速度の向上とディスク使用量の削減、PDのスケジューリング戦略フレームワークの最適化、SQLクエリオプティマイザの機能追加、TiDBの新ツールなどが含まれています。また、MySQLの組み込み関数のサポートが強化され、「add index」ステートメントの速度も向上しています。 +summary: TiDB RC1は2016年12月23日にリリースされました。アップデートには、TiKVの書き込み速度の向上とディスク使用量の削減、PDのスケジューリング戦略フレームワークの最適化、SQLクエリオプティマイザの機能追加、TiDBの新ツールなどが含まれています。また、MySQLの組み込み関数のサポートが強化され、`add index`ステートメントの速度も向上しています。 --- # TiDB RC1 リリースノート {#tidb-rc1-release-notes} diff --git a/releases/release-rc.2.md b/releases/release-rc.2.md index 58a5ded9f6cd0..b6d973c7e984e 100644 --- a/releases/release-rc.2.md +++ b/releases/release-rc.2.md @@ -26,7 +26,7 @@ summary: 2017年3月1日にリリースされたTiDB RC2は、MySQLとの互換 - 大規模なトランザクションのクラスタブロックを回避するために、単一のトランザクションのサイズを制限します。 - データのロードプロセスでデータを自動的に分割する - AddIndex および Delete文のパフォーマンスを最適化します -- 「ANSI_QUOTES」sql_modeをサポート +- "ANSI_QUOTES"sql_modeをサポート - 監視システムを改善する - バグを修正 - メモリリークの問題を解決する diff --git a/resources/doc-templates/template-concept.md b/resources/doc-templates/template-concept.md index 1042801c40d7e..6c2aac8fcf638 100644 --- a/resources/doc-templates/template-concept.md +++ b/resources/doc-templates/template-concept.md @@ -30,7 +30,7 @@ summary: このドキュメントを115～145文字で要約してください ここで基本的な動作原理を説明したり、その原理を上記のコンポーネント紹介に統合したりすることもできます。 -### L3 見出し（オプション、例：「xxxコンポーネント」） {#l3-heading-optional-e-g-xxx-component} +### L3 見出し（オプション、例："xxxコンポーネント"） {#l3-heading-optional-e-g-xxx-component} コンポーネントが複雑な場合は、このように別のセクションで詳しく説明できます。 @@ -38,7 +38,7 @@ summary: このドキュメントを115～145文字で要約してください xxx -## L2 見出し (オプション、例:「主な機能/制限事項」) {#l2-heading-optional-e-g-key-features-limitations} +## L2 見出し (オプション、例:"主な機能/制限事項") {#l2-heading-optional-e-g-key-features-limitations} 2 番目の L2 見出しでは、主な機能、使用シナリオ、制限など、ユーザーが事前に知っておく必要のある基本情報を紹介します。 diff --git a/role-based-access-control.md b/role-based-access-control.md index 458585a719675..03a4a2c3a1518 100644 --- a/role-based-access-control.md +++ b/role-based-access-control.md @@ -79,7 +79,7 @@ GRANT 'app_read', 'app_write' TO 'rw_user1'@'localhost'; ユーザーにロールを付与しても、そのロールがすぐに有効になるわけではありません。ロールの有効化は別の操作です。 -次の操作は「関係ループ」を形成する可能性があります。 +次の操作は"relation loop"を形成する可能性があります。 ```sql CREATE USER 'u1', 'u2'; diff --git a/security-compatibility-with-mysql.md b/security-compatibility-with-mysql.md index da3df2b2ec2f6..d8e2461a0f199 100644 --- a/security-compatibility-with-mysql.md +++ b/security-compatibility-with-mysql.md @@ -27,8 +27,8 @@ TiDB と MySQL のパスワード有効期限ポリシーには次の違いが TiDB の有効期限メカニズムは、次の点で MySQL と異なります。 -- MySQL v5.7 および v8.0 では、クライアントとサーバーの構成を組み合わせて、クライアント接続に「サンドボックス モード」を有効にするかどうかを決定します。 -- TiDB では、 [`security.disconnect-on-expired-password`](/tidb-configuration-file.md#disconnect-on-expired-password-new-in-v650)設定項目だけで、クライアント接続に対して「サンドボックス モード」を有効にするかどうかが決まります。 +- MySQL v5.7 および v8.0 では、クライアントとサーバーの構成を組み合わせて、クライアント接続に"sandbox mode"を有効にするかどうかを決定します。 +- TiDB では、 [`security.disconnect-on-expired-password`](/tidb-configuration-file.md#disconnect-on-expired-password-new-in-v650)設定項目だけで、クライアント接続に対して"sandbox mode"を有効にするかどうかが決まります。 ### Password complexity policy {#password-complexity-policy} diff --git a/sql-mode.md b/sql-mode.md index bf0400a306a86..bbf9cc9ba897a 100644 --- a/sql-mode.md +++ b/sql-mode.md @@ -25,9 +25,9 @@ TiDB の起動後、 `SET [ SESSION | GLOBAL ] sql_mode='modes'`ステートメ | 名前 | 説明 | | :--------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `PIPES_AS_CONCAT` | 「||」を文字列連結演算子 ( `+` ) ( `CONCAT()`と同じ) として扱い、 `OR` (完全サポート) としては扱いません。 | +| `PIPES_AS_CONCAT` | "||"を文字列連結演算子 ( `+` ) ( `CONCAT()`と同じ) として扱い、 `OR` (完全サポート) としては扱いません。 | | `ANSI_QUOTES` | `"`を識別子として扱います。 `ANSI_QUOTES`が有効になっている場合、シングルクォートのみが文字列リテラルとして扱われ、ダブルクォートは識別子として扱われます。したがって、ダブルクォートを使用して文字列を引用することはできません。（完全サポート） | -| `IGNORE_SPACE` | このモードを有効にすると、システムはスペースを無視します。例えば、「user」と「user 」は同じものとして扱われます。（完全対応） | +| `IGNORE_SPACE` | このモードを有効にすると、システムはスペースを無視します。例えば、"user"と"user "は同じものとして扱われます。（完全対応） | | `ONLY_FULL_GROUP_BY` | SQL文が`SELECT` 、 `HAVING` 、または`ORDER BY`内の列を参照している場合、その列は集計されておらず、 `GROUP BY`句にも含まれていないため、無効となります。これは、そのような列をクエリ結果に表示することが異常であるためです。この設定は、 [`tidb_enable_new_only_full_group_by_check`](/system-variables.md#tidb_enable_new_only_full_group_by_check-new-in-v610)システム変数によって影響を受けます。（完全サポート） | | `NO_UNSIGNED_SUBTRACTION` | 減算演算において被演算項に記号がない場合、結果を`UNSIGNED`としてマークしません。（完全対応） | | `NO_DIR_IN_CREATE` | テーブル作成時に、 `INDEX DIRECTORY`および`DATA DIRECTORY`ディレクティブをすべて無視します。このオプションは、セカンダリレプリケーションサーバー（構文サポートのみ）でのみ有効です。 | @@ -39,7 +39,7 @@ TiDB の起動後、 `SET [ SESSION | GLOBAL ] sql_mode='modes'`ステートメ | `STRICT_TRANS_TABLES` | トランザクションストレージエンジンの厳格モードを有効にし、無効な値が挿入された後にステートメント全体をロールバックします。（完全サポート） | | `STRICT_ALL_TABLES` | トランザクションテーブルの場合、無効な値が挿入された後にトランザクションステートメント全体をロールバックします。（完全サポート） | | `NO_ZERO_IN_DATE` | 厳格モードでは、月または日の一部が`0`である日付は受け入れられません。 `IGNORE`オプションを使用すると、TiDB は同様の日付に対して '0000-00-00' を挿入します。非厳格モードでは、この日付は受け入れられますが、警告が表示されます。（完全サポート） | -| `NO_ZERO_DATE` | 厳格モードでは、「0000-00-00」を有効な日付として使用しません。ただし`IGNORE`オプションを使用すれば、ゼロの日付を挿入することは可能です。非厳格モードでは、この日付は受け入れられますが、警告が表示されます。（完全サポート） | +| `NO_ZERO_DATE` | 厳格モードでは、'0000-00-00'を有効な日付として使用しません。ただし`IGNORE`オプションを使用すれば、ゼロの日付を挿入することは可能です。非厳格モードでは、この日付は受け入れられますが、警告が表示されます。（完全サポート） | | `ALLOW_INVALID_DATES` | このモードでは、システムはすべての日付の有効性をチェックするわけではありません。 `1`から`12`までの月の値と、 `1`から`31`までの日付の値のみをチェックします。このモードは`DATE`列と`DATATIME`列にのみ適用されます。 `TIMESTAMP`列はすべて完全な有効性チェックが必要です。（完全サポート） | | `ERROR_FOR_DIVISION_BY_ZERO` | このモードが有効になっている場合、システムはデータ変更操作（ `0`または`INSERT`で`UPDATE`による除算を処理する際にエラーを返します。
このモードが有効になっていない場合、システムは警告を返し、代わりに`NULL`が使用されます。（完全サポート） | | `NO_AUTO_CREATE_USER` | `GRANT` 、指定されたパスワード以外の新規ユーザーを自動的に作成することを防止します（完全サポート）。 | diff --git a/sql-plan-management.md b/sql-plan-management.md index 4f42720d9ecd9..13c4379935e9f 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -345,7 +345,7 @@ DROP [GLOBAL | SESSION] BINDING FOR SQL DIGEST StringLiteralOrUserVariableList; > **Note:** > -> `DROP GLOBAL BINDING`を実行すると、現在の tidb-server インスタンスのキャッシュ内のバインディングが削除され、システムテーブル内の対応する行のステータスが「削除済み」に変更されます。この文はシステムテーブル内のレコードを直接削除しません。これは、他の tidb-server インスタンスがキャッシュ内の対応するバインディングを削除するために「削除済み」ステータスを読み取る必要があるためです。これらのシステムテーブル内の「削除済み」ステータスのレコードについては、100 `bind-info-lease` (デフォルト値は`3s`で、合計`300s` ) 間隔ごとに、バックグラウンドスレッドが 10 `bind-info-lease`前の`update_time`のバインディングの再利用とクリアの操作をトリガーします (すべての tidb-server インスタンスが「削除済み」ステータスを読み取り、キャッシュを更新できるようにするため)。 +> `DROP GLOBAL BINDING`を実行すると、現在の tidb-server インスタンスのキャッシュ内のバインディングが削除され、システムテーブル内の対応する行のステータスが"deleted"に変更されます。この文はシステムテーブル内のレコードを直接削除しません。これは、他の tidb-server インスタンスがキャッシュ内の対応するバインディングを削除するために"deleted"ステータスを読み取る必要があるためです。これらのシステムテーブル内の"deleted"ステータスのレコードについては、100 `bind-info-lease` (デフォルト値は`3s`で、合計`300s` ) 間隔ごとに、バックグラウンドスレッドが 10 `bind-info-lease`前の`update_time`のバインディングの再利用とクリアの操作をトリガーします (すべての tidb-server インスタンスが"deleted"ステータスを読み取り、キャッシュを更新できるようにするため)。 ### バインディングステータスの変更 {#change-binding-status} diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index 73223fc6ee6c2..f8ed4a8432340 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -346,7 +346,7 @@ mysql> select @@last_plan_from_cache; -- Reuse the last plan -TiDBページの**Executor**セクションの[Grafanaダッシュボード](/grafana-tidb-dashboard.md)には、「プランキャッシュOPSを使用するクエリ」と「プランキャッシュミスOPS」のグラフがあります。これらのグラフは、TiDBとアプリケーションの両方がSQLプランキャッシュが正しく動作するように正しく設定されているかどうかを確認できます。同じページの**Server**セクションには、「プリペアドステートメント数」のグラフがあります。アプリケーションがプリペアドステートメントを使用している場合、このグラフは0以外の値を示します。これはSQLプランキャッシュが正しく機能するために必要なものです。 +TiDBページの**Executor**セクションの[Grafanaダッシュボード](/grafana-tidb-dashboard.md)には、"Queries Using Plan Cache OPS"と"Plan Cache Miss OPS"のグラフがあります。これらのグラフは、TiDBとアプリケーションの両方がSQLプランキャッシュが正しく動作するように正しく設定されているかどうかを確認できます。同じページの**Server**セクションには、"Prepared Statement Count"のグラフがあります。アプリケーションがプリペアドステートメントを使用している場合、このグラフは0以外の値を示します。これはSQLプランキャッシュが正しく機能するために必要なものです。 ![sql\_plan\_cache](/media/performance/sql_plan_cache.png) diff --git a/sql-statements/sql-statement-alter-index.md b/sql-statements/sql-statement-alter-index.md index 4bc0067c06ab8..ee8160e601b8c 100644 --- a/sql-statements/sql-statement-alter-index.md +++ b/sql-statements/sql-statement-alter-index.md @@ -92,7 +92,7 @@ ERROR 1176 (42000): Key 'c1' doesn't exist in table 't1' > **Note:** > -> ここでの「不可視」とは、オプティマイザに対してのみ不可視であることを意味します。不可視インデックスを変更または削除することは可能です。 +> ここでの"Invisible"とは、オプティマイザに対してのみ不可視であることを意味します。不可視インデックスを変更または削除することは可能です。 ```sql ALTER TABLE t1 DROP INDEX c1; diff --git a/sql-statements/sql-statement-alter-table.md b/sql-statements/sql-statement-alter-table.md index 2426ca74d8d35..0a44eaa120809 100644 --- a/sql-statements/sql-statement-alter-table.md +++ b/sql-statements/sql-statement-alter-table.md @@ -134,7 +134,7 @@ ALTER TABLE t1 ADD INDEX (c1), ALGORITHM=INSTANT; ERROR 1846 (0A000): ALGORITHM=INSTANT is not supported. Reason: Cannot alter table by INSTANT. Try ALGORITHM=INPLACE. ``` -ただし、 `ALGORITHM=COPY`アサーションを`INPLACE`操作に使用すると、エラーではなく警告が生成されます。これは、TiDB がアサーションを「*このアルゴリズム以上」*と解釈するためです。TiDB が使用するアルゴリズムは MySQL と異なる可能性があるため、この動作の違いは MySQL との互換性を保つために役立ちます。 +ただし、 `ALGORITHM=COPY`アサーションを`INPLACE`操作に使用すると、エラーではなく警告が生成されます。これは、TiDB がアサーションを_このアルゴリズムまたはそれ以上_と解釈するためです。TiDB が使用するアルゴリズムは MySQL と異なる可能性があるため、この動作の違いは MySQL との互換性を保つために役立ちます。 ```sql ALTER TABLE t1 ADD INDEX (c1), ALGORITHM=COPY; diff --git a/sql-statements/sql-statement-backup.md b/sql-statements/sql-statement-backup.md index 08ebd3ca356d3..25e8b17978966 100644 --- a/sql-statements/sql-statement-backup.md +++ b/sql-statements/sql-statement-backup.md @@ -20,7 +20,7 @@ summary: TiDBデータベースにおけるBACKUPの使用方法の概要。 `BACKUP`および[`RESTORE`](/sql-statements/sql-statement-restore.md)タスクは、一度に 1つしか実行できません。 `BACKUP`または`RESTORE`文が同じ TiDBサーバーで既に実行されている場合、新しい`BACKUP`の実行は、以前のすべてのタスクが完了するまで待機します。 -`BACKUP` 「tikv」ストレージエンジンでのみ使用できます。「unistore」エンジンで`BACKUP`を使用すると失敗します。 +`BACKUP` "tikv"ストレージエンジンでのみ使用できます。"unistore"エンジンで`BACKUP`を使用すると失敗します。 ## 概要 {#synopsis} diff --git a/sql-statements/sql-statement-calibrate-resource.md b/sql-statements/sql-statement-calibrate-resource.md index d5a834039e1f7..c90cd3f1e5a1e 100644 --- a/sql-statements/sql-statement-calibrate-resource.md +++ b/sql-statements/sql-statement-calibrate-resource.md @@ -5,7 +5,7 @@ summary: TiDB データベースの CALIBRATE RESOURCE の使用法の概要。 # `CALIBRATE RESOURCE` {#calibrate-resource} -`CALIBRATE RESOURCE`文は、現在のクラスターの[「リクエストユニット（RU）」](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)容量を推定して出力するために使用されます。 +`CALIBRATE RESOURCE`文は、現在のクラスターの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)容量を推定して出力するために使用されます。 > **Note:** > diff --git a/sql-statements/sql-statement-flashback-cluster.md b/sql-statements/sql-statement-flashback-cluster.md index cd7bb5b296927..3ef645b7eb877 100644 --- a/sql-statements/sql-statement-flashback-cluster.md +++ b/sql-statements/sql-statement-flashback-cluster.md @@ -5,7 +5,7 @@ summary: TiDBデータベースにおけるFLASHBACK CLUSTERの使い方を学 # FLASHBACK CLUSTER {#flashback-cluster} -TiDB v6.4.0 では`FLASHBACK CLUSTER TO TIMESTAMP`構文が導入されました。これを使用すると、クラスタを特定の時点に復元できます。タイムスタンプを指定する際には、datetime 値を設定するか、time 関数を使用できます。datetime の形式は、たとえば「2016-10-08 16:45:26.999」のようになります。最小時間単位はミリ秒です。ただし、ほとんどの場合、時間単位を秒としてタイムスタンプを指定するだけで十分です。たとえば、「2016-10-08 16:45:26」のように指定します。 +TiDB v6.4.0 では`FLASHBACK CLUSTER TO TIMESTAMP`構文が導入されました。これを使用すると、クラスタを特定の時点に復元できます。タイムスタンプを指定する際には、datetime 値を設定するか、time 関数を使用できます。datetime の形式は、たとえば'2016-10-08 16:45:26.999'のようになります。最小時間単位はミリ秒です。ただし、ほとんどの場合、時間単位を秒としてタイムスタンプを指定するだけで十分です。たとえば、'2016-10-08 16:45:26'のように指定します。 TiDBは、v6.5.6、v7.1.3、v7.5.1、v7.6.0以降で`FLASHBACK CLUSTER TO TSO`構文を導入しました。この構文を使用すると、 [TSO](/tso.md)を使用してより正確なリカバリ時点を指定できるため、データリカバリの柔軟性が向上します。 diff --git a/sql-statements/sql-statement-restore.md b/sql-statements/sql-statement-restore.md index 52c2e8cce0077..cf86558fd2595 100644 --- a/sql-statements/sql-statement-restore.md +++ b/sql-statements/sql-statement-restore.md @@ -14,7 +14,7 @@ summary: TiDBデータベースにおけるRESTOREの使用方法の概要。 `RESTORE`文は、 [BRツール](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview)と同じエンジンを使用しますが、リストア プロセスは別のBRツールではなく TiDB 自体によって実行されます。BR のすべての利点と注意点もここに適用されます。特に、 **`RESTORE`は現在ACID準拠ではありません**。 `RESTORE`を実行する前に、次の要件が満たされていることを確認してください。 -- クラスターは「オフライン」状態であり、現在有効なTiDBセッションは、復元中のすべてのテーブルにアクセスできる唯一のアクティブなSQL接続です。 +- クラスターは"offline"状態であり、現在有効なTiDBセッションは、復元中のすべてのテーブルにアクセスできる唯一のアクティブなSQL接続です。 - 完全復元を実行する場合、復元対象のテーブルは既に存在してはなりません。既存のデータが上書きされ、データとインデックス間の不整合が発生する可能性があるためです。 - 増分復元を実行する場合、テーブルはバックアップが作成された時点の`LAST_BACKUP`タイムスタンプとまったく同じ状態である必要があります。 @@ -24,7 +24,7 @@ summary: TiDBデータベースにおけるRESTOREの使用方法の概要。 `BACKUP`と`RESTORE`のタスクは、一度に 1つしか実行できません。 `BACKUP`または`RESTORE`タスクが同じ TiDBサーバーで既に実行されている場合、新しい`RESTORE`実行は、以前のすべてのタスクが完了するまで待機します。 -`RESTORE` 「tikv」ストレージエンジンでのみ使用できます。「unistore」エンジンで`RESTORE`を使用すると失敗します。 +`RESTORE`は"tikv"ストレージエンジンでのみ使用できます。"unistore"エンジンで`RESTORE`を使用すると失敗します。 ## 概要 {#synopsis} diff --git a/sql-statements/sql-statement-split-region.md b/sql-statements/sql-statement-split-region.md index 3b8cb60d92c38..15172d73297ee 100644 --- a/sql-statements/sql-statement-split-region.md +++ b/sql-statements/sql-statement-split-region.md @@ -96,7 +96,7 @@ t22_r11 #### 均等に {#even-split} -`row_id`は整数であるため、分割するキーの値は、指定された`lower_value` 、 `upper_value` 、および`region_num`に従って計算できます。TiDB は最初にステップ値 ( `step = (upper_value - lower_value)/region_num` ) を計算します。次に、 `lower_value`と`upper_value`の間で各「ステップ」ごとに均等に分割して`region_num`で指定された数のリージョンを生成します。 +`row_id`は整数であるため、分割するキーの値は、指定された`lower_value` 、 `upper_value` 、および`region_num`に従って計算できます。TiDB は最初にステップ値 ( `step = (upper_value - lower_value)/region_num` ) を計算します。次に、 `lower_value`と`upper_value`の間で各"step"ごとに均等に分割して`region_num`で指定された数のリージョンを生成します。 例えば、テーブル t のキー範囲`minInt64` ~ `maxInt64`から均等に分割された 16 個のリージョンを作成したい場合は、次のステートメントを使用できます。 diff --git a/stale-read.md b/stale-read.md index b90130d7e9909..e6abce1a97cdf 100644 --- a/stale-read.md +++ b/stale-read.md @@ -31,7 +31,7 @@ TiDB は、次のようにステートメントレベル、セッションレベ - ステートメントレベル - 正確な時点の指定（**推奨**）：TiDB が特定の時点からグローバルに一貫性のあるデータを分離レベルに違反することなく読み取る必要がある場合は、クエリ文でその時点の対応するタイムスタンプを指定できます。詳細な使用方法については、 [`AS OF TIMESTAMP`句](/as-of-timestamp.md#syntax)を参照してください。 - - 時間範囲の指定：TiDB が分離レベルに違反することなく、特定の時間範囲内で可能な限り新しいデータを読み取る必要がある場合、クエリ文で時間範囲を指定できます。指定された時間範囲内で、TiDB は適切なタイムスタンプを選択して対応するデータを読み取ります。「適切」とは、このタイムスタンプより前に開始され、アクセスされたレプリカでコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセスされたレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされないことを意味します。詳細な使用方法については、 [`AS OF TIMESTAMP`句](/as-of-timestamp.md#syntax)および[`TIDB_BOUNDED_STALENESS`関数](/as-of-timestamp.md#syntax)の概要を参照してください。 + - 時間範囲の指定：TiDB が分離レベルに違反することなく、特定の時間範囲内で可能な限り新しいデータを読み取る必要がある場合、クエリ文で時間範囲を指定できます。指定された時間範囲内で、TiDB は適切なタイムスタンプを選択して対応するデータを読み取ります。"Suitable"とは、このタイムスタンプより前に開始され、アクセスされたレプリカでコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセスされたレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされないことを意味します。詳細な使用方法については、 [`AS OF TIMESTAMP`句](/as-of-timestamp.md#syntax)および[`TIDB_BOUNDED_STALENESS`関数](/as-of-timestamp.md#syntax)の概要を参照してください。 - セッションレベル - 時間範囲の指定：セッションにおいて、後続のクエリでTiDBが分離レベルに違反することなく、指定された時間範囲内で可能な限り新しいデータを読み取る必要がある場合は、システム変数`tidb_read_staleness`を設定することで時間範囲を指定できます。詳細な使用方法については、 [`tidb_read_staleness`](/tidb-read-staleness.md)を参照してください。 diff --git a/statement-summary-tables.md b/statement-summary-tables.md index 883f2a5b1cd6c..26c1b7bb2f911 100644 --- a/statement-summary-tables.md +++ b/statement-summary-tables.md @@ -25,7 +25,7 @@ SQL のパフォーマンス問題をより適切に処理するために、MySQ `statements_summary`は`information_schema`内のシステムテーブルです。 `statements_summary`は、SQL文をリソースグループ、SQL ダイジェスト、およびプランダイジェストごとにグループ化し、各 SQL カテゴリの統計情報を提供します。 -ここでいう「SQLダイジェスト」とは、スローログで使用されるものと同じ意味で、正規化されたSQL文から計算される一意の識別子です。正規化プロセスでは定数や空白文字は無視され、大文字と小文字は区別されません。したがって、構文が一貫しているステートメントは同じダイジェストを持ちます。例： +ここでいう"SQL digest"とは、スローログで使用されるものと同じ意味で、正規化されたSQL文から計算される一意の識別子です。正規化プロセスでは定数や空白文字は無視され、大文字と小文字は区別されません。したがって、構文が一貫しているステートメントは同じダイジェストを持ちます。例： ```sql SELECT * FROM employee WHERE id IN (1, 2, 3) AND salary BETWEEN 1000 AND 2000; @@ -38,7 +38,7 @@ select * from EMPLOYEE where ID in (4, 5) and SALARY between 3000 and 4000; select * from employee where id in (...) and salary between ? and ?; ``` -ここでいう「プランダイジェスト」とは、正規化された実行計画によって計算される一意の識別子を指します。正規化処理では定数は無視されます。同じSQL文でも実行計画が異なる場合があるため、異なるカテゴリに分類されることがあります。同じカテゴリのSQL文は、同じ実行計画を持ちます。 +ここでいう"plan digest"とは、正規化された実行計画によって計算される一意の識別子を指します。正規化処理では定数は無視されます。同じSQL文でも実行計画が異なる場合があるため、異なるカテゴリに分類されることがあります。同じカテゴリのSQL文は、同じ実行計画を持ちます。 `statements_summary`は、SQL モニタリングメトリックの集計結果が格納されます。一般的に、各モニタリングメトリックには、最大値と平均値が含まれます。たとえば、実行レイテンシーメトリックは、 `AVG_LATENCY` (平均レイテンシー) と`MAX_LATENCY` (最大レイテンシー) の 2つのフィールドに対応します。 diff --git a/system-variables.md b/system-variables.md index c87448750d22b..7581690ae405b 100644 --- a/system-variables.md +++ b/system-variables.md @@ -3719,8 +3719,8 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: "" - 型: String - これは読み取り専用変数です。TiDB内部で、現在のセッションにおける最後のDDL操作の情報を取得するために使用されます。 - - 「query」：最後のDDLクエリ文字列。 - - 「seq_num」：各DDL操作のシーケンス番号。DDL操作の順序を識別するために使用されます。 + - "query"：最後のDDLクエリ文字列。 + - "seq_num"：各DDL操作のシーケンス番号。DDL操作の順序を識別するために使用されます。 ### tidb_last_query_info New in v4.0.14 @@ -5493,7 +5493,7 @@ SHOW WARNINGS; - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - デフォルト値： `2097152` （2 MiB） -- 範囲: `[0, 9223372036854775807]` 、バイト単位。単位が「KiB|MiB|GiB|TiB」のメモリ形式もサポートされています。 `0`は制限なしを意味します。 +- 範囲: `[0, 9223372036854775807]` 、バイト単位。単位が"KiB|MiB|GiB|TiB"のメモリ形式もサポートされています。 `0`は制限なしを意味します。 - この変数は、プリペアドプランキャッシュまたは非プリペアドプランキャッシュにキャッシュできるプランの最大サイズを制御します。プランのサイズがこの値を超える場合、プランはキャッシュされません。詳細については、 [プリペアドプランキャッシュのメモリ管理](/sql-prepared-plan-cache.md#memory-management-of-prepared-plan-cache)と[非プリペアドプランキャッシュ](/sql-plan-management.md#usage)を参照してください。 ### tidb_pprof_sql_cpu New in v4.0 @@ -5832,7 +5832,7 @@ SHOW WARNINGS; - デフォルト値: `80%` - 範囲： - 値をパーセンテージ形式で設定できます。これは、メモリ使用量が総メモリに対して占める割合を意味します。値の範囲は`[1%, 99%]`です。 - - メモリサイズの値も設定できます。値の範囲はバイト単位で`0`から`[536870912, 9223372036854775807]`です。単位が「KiB|MiB|GiB|TiB」または「KB|MB|GB|TB」のメモリ形式もサポートされており、たとえば `90GiB` のように指定できます（数値と単位の間にスペースは入れません）。 `0`はメモリ制限なしを意味します。 + - メモリサイズの値も設定できます。値の範囲はバイト単位で`0`から`[536870912, 9223372036854775807]`です。単位が"KiB|MiB|GiB|TiB"または"KB|MB|GB|TB"のメモリ形式もサポートされており、たとえば `90GiB` のように指定できます（数値と単位の間にスペースは入れません）。 `0`はメモリ制限なしを意味します。 - この変数に 512 MiB 未満だが`0`ではないメモリサイズが設定されている場合、TiDB は 512 MiB を実際のサイズとして使用します。 - この変数は、TiDBインスタンスのメモリ制限を指定します。TiDBのメモリ使用量がこの制限に達すると、TiDBは現在実行中のSQL文のうち、最もメモリ使用量の多い文をキャンセルします。SQL文が正常にキャンセルされた後、TiDBはGolangのガベージコレクション（GC）を呼び出してメモリを解放し、メモリ負荷をできるだけ早く軽減しようとします。 - [`tidb_server_memory_limit_sess_min_size`](/system-variables.md#tidb_server_memory_limit_sess_min_size-new-in-v640)の制限を超えるメモリ使用量を持つ SQL文のみが、最初にキャンセルされる SQL文として選択されます。 @@ -5861,7 +5861,7 @@ SHOW WARNINGS; - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値： `134217728` （128 MiB） -- 範囲： `[128, 9223372036854775807]` （バイト単位）。単位が「KiB|MiB|GiB|TiB」または「KB|MB|GB|TB」のメモリ形式もサポートされており、たとえば `130MiB` のように指定できます（数値と単位の間にスペースは入れません）。 +- 範囲： `[128, 9223372036854775807]` （バイト単位）。単位が"KiB|MiB|GiB|TiB"または"KB|MB|GB|TB"のメモリ形式もサポートされており、たとえば `130MiB` のように指定できます（数値と単位の間にスペースは入れません）。 - メモリ制限を有効にすると、TiDB は現在のインスタンス上でメモリ使用量が最も高い SQL文を終了します。この変数は、終了する SQL文の最小メモリ使用量を指定します。メモリ使用量が低いセッションが多すぎるために TiDB インスタンスのメモリ使用量が制限を超えている場合は、この変数の値を適切に下げることで、より多くのセッションをキャンセルできるようになります。 ### tidb_service_scope New in v7.4.0 @@ -6037,7 +6037,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: "" -- `INFORMATION_SCHEMA.SLOW_QUERY`が照会されると、設定ファイル`slow-query-file`で設定されたスロークエリログ名のみが解析されます。デフォルトのスロークエリログ名は「tidb-slow.log」です。他のログを解析するには、 `tidb_slow_query_file`セッション変数を特定のファイルパスに設定し、 `INFORMATION_SCHEMA.SLOW_QUERY`を照会して、設定したファイルパスに基づいてスロークエリログを解析します。 +- `INFORMATION_SCHEMA.SLOW_QUERY`が照会されると、設定ファイル`slow-query-file`で設定されたスロークエリログ名のみが解析されます。デフォルトのスロークエリログ名は"tidb-slow.log"です。他のログを解析するには、 `tidb_slow_query_file`セッション変数を特定のファイルパスに設定し、 `INFORMATION_SCHEMA.SLOW_QUERY`を照会して、設定したファイルパスに基づいてスロークエリログを解析します。 @@ -6060,7 +6060,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: "" -- この変数は、セッションがデータを読み取る時点を設定するために使用されます。たとえば、変数を「2017-11-11 20:20:20」または「400036290571534337」のようなTSO番号に設定すると、現在のセッションはこの時点のデータを読み取ります。 +- この変数は、セッションがデータを読み取る時点を設定するために使用されます。たとえば、変数を"2017-11-11 20:20:20"または"400036290571534337"のようなTSO番号に設定すると、現在のセッションはこの時点のデータを読み取ります。 ### tidb_source_id New in v6.5.0 @@ -6774,7 +6774,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 指定可能な値: `pessimistic` 、 `optimistic` - この変数はトランザクションモードを設定するために使用されます。 TiDB 3.0 は悲観的トランザクションをサポートします。 TiDB 3.0.8 以降、[悲観的トランザクションモード](/pessimistic-transaction.md)はデフォルトで有効になっています。 - TiDBをv3.0.7以前のバージョンからv3.0.8以降のバージョンにアップグレードしても、デフォルトのトランザクションモードは変更されません。**新しく作成されたクラスタのみが、デフォルトで悲観的トランザクションモードを使用します**。 -- この変数が「楽観的」または「」に設定されている場合、TiDB は[楽観的トランザクションモード](/optimistic-transaction.md)を使用します。 +- この変数が"optimistic"または""に設定されている場合、TiDB は[楽観的トランザクションモード](/optimistic-transaction.md)を使用します。 ### tidb_use_plan_baselines New in v4.0 @@ -6951,7 +6951,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `SYSTEM` -- この変数は現在のタイムゾーンを返します。値は、「-8:00」のようなオフセット、または「America/Los_Angeles」のような名前付きゾーンのいずれかで指定できます。 +- この変数は現在のタイムゾーンを返します。値は、"-8:00"のようなオフセット、または"America/Los_Angeles"のような名前付きゾーンのいずれかで指定できます。 - 値`SYSTEM`は、タイムゾーンがシステムホストと同じである必要があることを意味します。システムホストのタイムゾーンは、 [`system_time_zone`](#system_time_zone)変数で取得できます。 ### timestamp @@ -7103,7 +7103,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 適用範囲：なし - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `8.0.11-TiDB-` (tidb バージョン) -- この変数は、MySQLのバージョンに続いてTiDBのバージョンを返します。例えば、「8.0.11-TiDB-v8.5.4」のようになります。 +- この変数は、MySQLのバージョンに続いてTiDBのバージョンを返します。例えば、"8.0.11-TiDB-v8.5.4"のようになります。 ### version_comment diff --git a/table-filter.md b/table-filter.md index a6182cfc29c8a..0f3950d8c7070 100644 --- a/table-filter.md +++ b/table-filter.md @@ -85,7 +85,7 @@ TOMLファイル内のテーブルフィルターは[文字列の配列](https:/ ### プレーンテーブル名 {#plain-table-names} -各テーブルフィルタールールは、「スキーマパターン」と「テーブルパターン」で構成され、ドット（ `.` ）で区切られます。完全修飾名がルールに一致するテーブルが受け入れられます。 +各テーブルフィルタールールは、"schema pattern"と"table pattern"で構成され、ドット（ `.` ）で区切られます。完全修飾名がルールに一致するテーブルが受け入れられます。 ``` db1.tbl1 @@ -109,8 +109,8 @@ db3.tbl3 - `*` — 0文字以上の文字に一致 - `?` — 1文字に一致 -- `[a-z]` — 「a」から「z」までの間の1文字に一致します -- `[!a-z]` — 「a」から「z」を除く 1つの文字に一致します。 +- `[a-z]` — "a"から"z"までの間の1文字に一致します +- `[!a-z]` — "a"から"z"を除く 1つの文字に一致します。 @@ -120,7 +120,7 @@ data.* *.backup_* ``` -ここでの「文字」とは、次のような Unicode コード ポイントを意味します。 +ここでの"Character"とは、次のような Unicode コード ポイントを意味します。 - U+00E9 (é) は 1 文字です。 - U+0065 U+0301 (é) は 2 文字です。 diff --git a/three-data-centers-in-two-cities-deployment.md b/three-data-centers-in-two-cities-deployment.md index e8edfacd3fd51..9be69c65f859c 100644 --- a/three-data-centers-in-two-cities-deployment.md +++ b/three-data-centers-in-two-cities-deployment.md @@ -7,7 +7,7 @@ summary: 2つのリージョンにある 3つのアベイラビリティゾー このドキュメントでは、2つのリージョンデプロイにおける 3つのアベイラビリティゾーン (AZ) のアーキテクチャと構成について説明します。 -このドキュメントにおける「リージョン」という用語は地理的な領域を指し、「リージョン」はTiKVにおけるデータストレージの基本単位を指します。「AZ」はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 +このドキュメントにおける"region"という用語は地理的な領域を指し、大文字の"Region"はTiKVにおけるデータストレージの基本単位を指します。"AZ"はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 ## 概要 {#overview} diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md index bfcd5c2244293..00e69a2e96854 100644 --- a/ticdc/ticdc-avro-protocol.md +++ b/ticdc/ticdc-avro-protocol.md @@ -88,7 +88,7 @@ TiCDC は DML イベントを Kafka イベントに変換し、イベントの デフォルトでは、AvroはDMLイベント内の変更された行のデータのみを収集し、データ変更の種類やTiDB固有のCommitTS（トランザクションの一意の識別子）は収集しません。この問題に対処するため、TiCDCはAvroプロトコルメッセージに以下の3つのTiDB拡張フィールドを導入しています。`sink-uri`で`enable-tidb-extension`を`true` （デフォルトは`false` ）に設定すると、TiCDCはメッセージ生成時にこれらの3つのフィールドをAvroメッセージに追加します。 -- `_tidb_op` : DML タイプ。「c」は挿入を示し、「u」は更新を示します。 +- `_tidb_op` : DML タイプ。"c"は挿入を示し、"u"は更新を示します。 - `_tidb_commit_ts` : トランザクションの一意の識別子。 - `_tidb_commit_physical_time` : トランザクション識別子内の物理的なタイムスタンプ。 diff --git a/ticdc/ticdc-canal-json.md b/ticdc/ticdc-canal-json.md index 26312da000dbe..3b67bd6f601cd 100644 --- a/ticdc/ticdc-canal-json.md +++ b/ticdc/ticdc-canal-json.md @@ -138,7 +138,7 @@ TiCDC は、DML データ変更イベントの行を次のようにエンコー TiCDCは、 `enable-tidb-extension`を`true`に設定した場合のみ、WATERMARKイベントを送信します。 `type`フィールドの値は`TIDB_WATERMARK`です。イベントには`_tidb`フィールドが含まれており、このフィールドにはパラメータ`watermarkTs`のみが含まれます。 `watermarkTs`の値は、イベント送信時に記録されるTSOです。 -このタイプのイベントを受信すると、 `commitTs`が`watermarkTs`より小さいすべてのイベントが送信されています。TiCDC は「少なくとも 1回」のセマンティクスを提供するため、データが繰り返し送信される可能性があります。その後に`commitTs`が`watermarkTs`より小さいイベントを受信した場合は、このイベントを無視しても問題ありません。 +このタイプのイベントを受信すると、 `commitTs`が`watermarkTs`より小さいすべてのイベントが送信されています。TiCDC は"At Least Once"のセマンティクスを提供するため、データが繰り返し送信される可能性があります。その後に`commitTs`が`watermarkTs`より小さいイベントを受信した場合は、このイベントを無視しても問題ありません。 以下は WATERMARK イベントの例です。 diff --git a/ticdc/ticdc-changefeed-config.md b/ticdc/ticdc-changefeed-config.md index 743fcbe695370..62250045689d1 100644 --- a/ticdc/ticdc-changefeed-config.md +++ b/ticdc/ticdc-changefeed-config.md @@ -350,14 +350,14 @@ v8.0.0 以降、TiCDC はSimple メッセージ エンコーディング プロ ##### `output-old-value` {#output-old-value} -- 行データが変更される前に値を出力するかどうかを制御します。デフォルト値は true です。無効にすると、 `UPDATE`イベントは「p」フィールドを出力しません。 +- 行データが変更される前に値を出力するかどうかを制御します。デフォルト値は true です。無効にすると、 `UPDATE`イベントは"p"フィールドを出力しません。 - デフォルト値: `true` #### sink.debezium {#sink-debezium} ##### `output-old-value` {#output-old-value} -- 行データが変更される前の値を出力するかどうかを制御します。デフォルト値は true です。無効にすると、 `UPDATE`イベントは「変更前」フィールドを出力しません。 +- 行データが変更される前の値を出力するかどうかを制御します。デフォルト値は true です。無効にすると、 `UPDATE`イベントは"before"フィールドを出力しません。 - デフォルト値: `true` ### consistent {#consistent} diff --git a/ticdc/ticdc-debezium.md b/ticdc/ticdc-debezium.md index 072c150b81ecd..2ad3a98c89fc0 100644 --- a/ticdc/ticdc-debezium.md +++ b/ticdc/ticdc-debezium.md @@ -5,7 +5,7 @@ summary: TiCDC Debezium プロトコルの概念とその使用方法を学び # TiCDC Debeziumプロトコル {#ticdc-debezium-protocol} -TiCDC [Debezium](https://debezium.io/) 、データベースの変更をキャプチャするためのツールです。キャプチャされたデータベースの変更はそれぞれ「イベント」と呼ばれるメッセージに変換され、Kafka に送信されます。v8.0.0以降、TiCDCはDebezium形式でTiDBの行データ変更（DMLイベント）をKafkaに直接送信することをサポートしているため、これまでDebeziumのMySQL統合を使用していたユーザーにとって、MySQLデータベースからの移行が簡素化されます。[TiCDC v8.5.4-release.1](https://github.com/pingcap/ticdc/releases/tag/v8.5.4-release.1)（[新しい TiCDC アーキテクチャ](/ticdc/ticdc-architecture.md)）以降、TiCDC は Debezium 形式で DDL イベントと WATERMARK イベントを送信することもサポートしています。 +TiCDC [Debezium](https://debezium.io/) 、データベースの変更をキャプチャするためのツールです。キャプチャされたデータベースの変更はそれぞれ"event"と呼ばれるメッセージに変換され、Kafka に送信されます。v8.0.0以降、TiCDCはDebezium形式でTiDBの行データ変更（DMLイベント）をKafkaに直接送信することをサポートしているため、これまでDebeziumのMySQL統合を使用していたユーザーにとって、MySQLデータベースからの移行が簡素化されます。[TiCDC v8.5.4-release.1](https://github.com/pingcap/ticdc/releases/tag/v8.5.4-release.1)（[新しい TiCDC アーキテクチャ](/ticdc/ticdc-architecture.md)）以降、TiCDC は Debezium 形式で DDL イベントと WATERMARK イベントを送信することもサポートしています。 ## Debeziumメッセージ形式を使用する {#use-the-debezium-message-format} diff --git a/ticdc/ticdc-manage-changefeed.md b/ticdc/ticdc-manage-changefeed.md index f509f39d499f3..7bcb7c7a5b404 100644 --- a/ticdc/ticdc-manage-changefeed.md +++ b/ticdc/ticdc-manage-changefeed.md @@ -289,7 +289,7 @@ v4.0.13 以降に`cdc cli`を使用して作成された changefeed の場合、 cdc cli --server="http://10.0.10.25:8300" changefeed query --changefeed-id=simple-replication-task | grep 'sort_engine' ``` -上記のコマンドの出力で、値`sort_engine`が「unified」の場合、変更フィードで Unified Sorter が有効になっていることを意味します。 +上記のコマンドの出力で、値`sort_engine`が"unified"の場合、変更フィードで Unified Sorter が有効になっていることを意味します。 > **Note:** > diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md index 3df565964a707..1bcd5cbbedc07 100644 --- a/ticdc/ticdc-open-api-v2.md +++ b/ticdc/ticdc-open-api-v2.md @@ -372,7 +372,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | パラメータ名 | 説明 | | :----------------- | :-------------------------------------------------------------------------------------------- | -| `output_old_value` | `BOOLEAN`型。行データが変更される前の値を出力するかどうかを制御します。デフォルト値はtrueです。無効にすると、UPDATEイベントは「before」フィールドを出力しません。 | +| `output_old_value` | `BOOLEAN`型。行データが変更される前の値を出力するかどうかを制御します。デフォルト値はtrueです。無効にすると、UPDATEイベントは"before"フィールドを出力しません。 | ### 例 {#example} @@ -1060,7 +1060,7 @@ curl -X POST http://127.0.0.1:8300/api/v2/owner/resign | :---------- | :---------- | | `log_level` | 設定するログレベル。 | -`log_level` 、「debug」、「info」、「warn」、「error」、「dpanic」、「panic」、「fatal」の[zapが提供するログレベル](https://godoc.org/go.uber.org/zap#UnmarshalText)サポートします。 +`log_level` 、"debug"、"info"、"warn"、"error"、"dpanic"、"panic"、"fatal"の[zapが提供するログレベル](https://godoc.org/go.uber.org/zap#UnmarshalText)サポートします。 ### 例 {#example} diff --git a/ticdc/ticdc-open-api.md b/ticdc/ticdc-open-api.md index 0cf6327d081d1..c137cb8d9e02c 100644 --- a/ticdc/ticdc-open-api.md +++ b/ticdc/ticdc-open-api.md @@ -556,7 +556,7 @@ curl -X POST -H "'Content-type':'application/json'" http://127.0.0.1:8300/api/v1 | :---------- | :---------- | | `log_level` | 設定するログレベル。 | -`log_level` 、「debug」、「info」、「warn」、「error」、「dpanic」、「panic」、「fatal」の[zapが提供するログレベル](https://godoc.org/go.uber.org/zap#UnmarshalText)サポートします。 +`log_level` 、"debug"、"info"、"warn"、"error"、"dpanic"、"panic"、"fatal"の[zapが提供するログレベル](https://godoc.org/go.uber.org/zap#UnmarshalText)サポートします。 ### 例 {#example} diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index cb92cae80dbbe..d4e6dda709589 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -230,8 +230,8 @@ dispatchers = [ ] ``` -- マッチャールールに一致するテーブルは、対応するトピック式で指定されたポリシーに従ってディスパッチされます。例えば、テーブル`test3.aa`は「トピック式2」に従ってディスパッチされ、テーブル`test5.aa`は「トピック式3」に従ってディスパッチされます。 -- 複数のマッチャールールに一致するテーブルの場合、最初に一致するトピック式に従ってディスパッチされます。例えば、 `test1.aa`テーブルは「トピック式 1」に従ってディスパッチされます。 +- マッチャールールに一致するテーブルは、対応するトピック式で指定されたポリシーに従ってディスパッチされます。例えば、テーブル`test3.aa`は"Topic expression 2"に従ってディスパッチされ、テーブル`test5.aa`は"Topic expression 3"に従ってディスパッチされます。 +- 複数のマッチャールールに一致するテーブルの場合、最初に一致するトピック式に従ってディスパッチされます。例えば、 `test1.aa`テーブルは"Topic expression 1"に従ってディスパッチされます。 - どのマッチャールールにも一致しないテーブルの場合、対応するデータ変更イベントは`--sink-uri`で指定されたデフォルトトピックに送信されます。例えば、 `test10.aa`テーブルはデフォルトトピックに送信されます。 - マッチャールールに一致するもののトピックディスパッチャーを指定していないテーブルの場合、対応するデータ変更は`--sink-uri`で指定されたデフォルトトピックに送信されます。例えば、 `test6.aa`テーブルはデフォルトトピックに送信されます。 @@ -260,7 +260,7 @@ Topic 式の形式は`[prefix]{schema}[middle][{table}][suffix]`です。 - `matcher = ['test5.*, 'test6.*'], topic = "hard_code_topic_name"` - `test5`と`test6`のすべてのテーブルに対応するデータ変更イベントは、トピック`hard_code_topic_name`に送信されます。トピック名は直接指定できます。 - `matcher = ['*.*'], topic = "{schema}_{table}"` - - TiCDC が監視するすべてのテーブルは、「schema_table」ルールに従って個別のトピックにディスパッチされます。例えば、テーブル`test.account`の場合、TiCDC はデータ変更ログを`test_account`という名前のトピックにディスパッチします。 + - TiCDC が監視するすべてのテーブルは、"schema_table"ルールに従って個別のトピックにディスパッチされます。例えば、テーブル`test.account`の場合、TiCDC はデータ変更ログを`test_account`という名前のトピックにディスパッチします。 ### DDLイベントをディスパッチする {#dispatch-ddl-events} diff --git a/tidb-cloud/backup-and-restore.md b/tidb-cloud/backup-and-restore.md index fe1143c0ae754..3cc6454311172 100644 --- a/tidb-cloud/backup-and-restore.md +++ b/tidb-cloud/backup-and-restore.md @@ -183,7 +183,7 @@ TiDB Cloud Dedicatedクラスターに手動バックアップを適用するに > **Note:** > -> 現在、この機能はリクエストに応じてのみ利用可能です。この機能をリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下隅にある**？**をクリックし、 次に**Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。チケットを作成し、**Description**フィールドに「バックアップのエクスポート機能の申請」と入力して、 **Submit**をクリックします。 +> 現在、この機能はリクエストに応じてのみ利用可能です。この機能をリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下隅にある**？**をクリックし、 次に**Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。チケットを作成し、**Description**フィールドに"Apply for the export backups feature"と入力して、 **Submit**をクリックします。 diff --git a/tidb-cloud/changefeed-sink-to-apache-kafka.md b/tidb-cloud/changefeed-sink-to-apache-kafka.md index 2c58e708ad514..5fdb06de337ac 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -277,7 +277,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン - Avroは、コンパクトで高速なバイナリデータフォーマットであり、豊富なデータ構造を備え、様々なフローシステムで広く利用されています。詳細については、 [Avroデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol)を参照してください。 - Canal-JSONは、解析が容易なプレーンなJSONテキスト形式です。詳細については、 [Canal-JSONデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-canal-json)を参照してください。 - オープンプロトコルは、監視、キャッシュ、全文インデックス作成、分析エンジン、および異なるデータベース間のプライマリとセカンダリのレプリケーションのためのデータソースを提供する行レベルのデータ変更通知プロトコルです。詳細については、 [オープンプロトコルデータフォーマット](https://docs.pingcap.com/tidb/stable/ticdc-open-protocol)を参照してください。 - - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を「イベント」と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)を参照してください。 + - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を"event"と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)を参照してください。 5. TiDB拡張フィールドをKafkaメッセージ本文に追加する場合は、 **TiDB Extension**オプションを有効にしてください。 diff --git a/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md b/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md index 41319bc293f99..47bdd66a0309d 100644 --- a/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md +++ b/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md @@ -13,7 +13,7 @@ summary: TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスへの ## 公開エンドポイント {#public-endpoints} -TiDB Cloud StarterまたはEssentialインスタンスでパブリックアクセスを設定すると、パブリックエンドポイント経由でインスタンスにアクセスできるようになります。つまり、 TiDB Cloud StarterまたはEssentialインスタンスはインターネット経由でアクセス可能になります。パブリックエンドポイントは、公開されている DNS アドレスです。「承認済みネットワーク」とは、TiDB Cloud StarterまたはEssentialインスタンスへのアクセスを許可する IP アドレスの範囲を指します。これらのアクセス許可は、**ファイアウォールルール**によって適用されます。 +TiDB Cloud StarterまたはEssentialインスタンスでパブリックアクセスを設定すると、パブリックエンドポイント経由でインスタンスにアクセスできるようになります。つまり、 TiDB Cloud StarterまたはEssentialインスタンスはインターネット経由でアクセス可能になります。パブリックエンドポイントは、公開されている DNS アドレスです。"authorized network"とは、TiDB Cloud StarterまたはEssentialインスタンスへのアクセスを許可する IP アドレスの範囲を指します。これらのアクセス許可は、**ファイアウォールルール**によって適用されます。 ### 公共アクセスの特徴 {#characteristics-of-public-access} diff --git a/tidb-cloud/configure-sql-users.md b/tidb-cloud/configure-sql-users.md index 6305af86298db..9fb39ee5a22d1 100644 --- a/tidb-cloud/configure-sql-users.md +++ b/tidb-cloud/configure-sql-users.md @@ -9,7 +9,7 @@ summary: TiDB Cloudコンソールでデータベースユーザーとロール > **Note:** > -> - **SQL Users**ページはパブリックプレビューであり、リクエストがあった場合のみ利用可能です。この機能をリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**?**をクリックし、**Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。チケットを作成し、 **Description**フィールドに「SQLユーザーページの申請」と入力して、 **Submit**をクリックします。 +> - **SQL Users**ページはパブリックプレビューであり、リクエストがあった場合のみ利用可能です。この機能をリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**?**をクリックし、**Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。チケットを作成し、 **Description**フィールドに"Apply for the SQL Users page"と入力して、 **Submit**をクリックします。 > - データベースのユーザーと役割[組織およびプロジェクトのユーザーと役割](/tidb-cloud/manage-user-access.md)から独立しています。データベースユーザーは TiDB クラスター内のデータベースにアクセスするために使用され、組織およびプロジェクト ユーザーは[TiDB Cloudコンソール](https://tidbcloud.com/)内の組織およびプロジェクトにアクセスするために使用されます。 > - **SQL Users**ページに加えて、SQL クライアントを使用してクラスターに接続し、SQL文を作成することによって、データベースユーザーとロールを管理することもできます。詳細については、 [TiDBユーザーアカウント管理](https://docs.pingcap.com/tidb/dev/user-account-management)を参照してください。 diff --git a/tidb-cloud/csv-config-for-import-data.md b/tidb-cloud/csv-config-for-import-data.md index 30cd97452f125..f44e6de5a17a4 100644 --- a/tidb-cloud/csv-config-for-import-data.md +++ b/tidb-cloud/csv-config-for-import-data.md @@ -17,7 +17,7 @@ summary: TiDB Cloudのインポートデータサービスで CSV 構成を使 - 共通の値: - - CSV（カンマ区切り値）の場合は`,`上記のスクリーンショットに示すように、「1」、「Michael」、「male」は3つのフィールドを表します。 + - CSV（カンマ区切り値）の場合は`,`上記のスクリーンショットに示すように、"1"、"Michael"、"male"は3つのフィールドを表します。 - TSV (タブ区切り値)の場合は`"\t"` 。 - デフォルト: `,` diff --git a/tidb-cloud/data-service-api-key.md b/tidb-cloud/data-service-api-key.md index cc3549c8fb3b9..b2291f652e833 100644 --- a/tidb-cloud/data-service-api-key.md +++ b/tidb-cloud/data-service-api-key.md @@ -7,7 +7,7 @@ summary: データアプリのAPIキーの作成、編集、削除方法を学 TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access_authentication)と[ダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)の両方をサポートしています。 -- [基本認証](https://en.wikipedia.org/wiki/Basic_access_authentication)は、暗号化されていない Base64 エンコーディングを使用して、公開キーと秘密キーを送信します。 HTTPS により通信のセキュリティが確保されます。詳細については、 [RFC 7617 - 「基本」HTTP認証方式](https://datatracker.ietf.org/doc/html/rfc7617)を参照してください。 +- [基本認証](https://en.wikipedia.org/wiki/Basic_access_authentication)は、暗号化されていない Base64 エンコーディングを使用して、公開キーと秘密キーを送信します。 HTTPS により通信のセキュリティが確保されます。詳細については、 [RFC 7617 - "Basic"HTTP認証方式](https://datatracker.ietf.org/doc/html/rfc7617)を参照してください。 - [ダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)ネットワーク送信前に公開キー、秘密キー、サーバー提供のノンス値、HTTP メソッド、および要求された URI をハッシュすることにより、追加のセキュリティレイヤーを提供します。これにより、秘密キーが暗号化され、秘密キーが平文で送信されるのを防ぎます。詳細については、 [RFC 7616 - HTTPダイジェストアクセス認証](https://datatracker.ietf.org/doc/html/rfc7616)を参照してください。 > **Note:** diff --git a/tidb-cloud/data-service-custom-domain.md b/tidb-cloud/data-service-custom-domain.md index 6a625625a2c37..333c624fa306a 100644 --- a/tidb-cloud/data-service-custom-domain.md +++ b/tidb-cloud/data-service-custom-domain.md @@ -13,7 +13,7 @@ TiDB Cloud Data Serviceは、各データアプリのエンドポイントにア データアプリのカスタムドメインを設定する前に、以下の点にご注意ください。 -- セキュリティ上の理由から、カスタムドメインのリクエストはHTTPSのみをサポートしています。カスタムドメインの設定が完了すると、「Let's Encrypt」証明書が自動的に適用されます。 +- セキュリティ上の理由から、カスタムドメインのリクエストはHTTPSのみをサポートしています。カスタムドメインの設定が完了すると、"Let's Encrypt"証明書が自動的に適用されます。 - カスタムドメインは、 TiDB Cloud Data Service内で一意である必要があります。 - TiDB Cloud Starterインスタンスのリージョンによって決定されるデフォルトドメインごとに、設定できるカスタムドメインは1つだけです。 diff --git a/tidb-cloud/dedicated-external-storage.md b/tidb-cloud/dedicated-external-storage.md index 642a0e9db657e..083fd1c5ce857 100644 --- a/tidb-cloud/dedicated-external-storage.md +++ b/tidb-cloud/dedicated-external-storage.md @@ -119,7 +119,7 @@ TiDB Cloudのバケットアクセスを設定し、以下の手順でロールA - **Trusted entity type**で**AWS account**を選択します。 - **An AWS account**の下にある**Another AWS account**を選択し、 TiDB CloudアカウントIDを**Account ID**フィールドに貼り付けます。 - - **オプション**で**Require external ID**をクリックして[混乱した副官の問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)回避し、 TiDB Cloud外部IDを**External ID**フィールドに貼り付けます。「外部IDを必須にする」を選択せず​​にロールを作成すると、S3バケットURIとIAMロールARNを持つユーザーであれば誰でもAmazon S3バケットにアクセスできる可能性があります。アカウントIDと外部IDの両方を使用してロールを作成すると、同じプロジェクトおよび同じリージョンで実行されているTiDBクラスタのみがバケットにアクセスできます。 + - **オプション**で**Require external ID**をクリックして[混乱した副官の問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)回避し、 TiDB Cloud外部IDを**External ID**フィールドに貼り付けます。"Require external ID"を選択せず​​にロールを作成すると、S3バケットURIとIAMロールARNを持つユーザーであれば誰でもAmazon S3バケットにアクセスできる可能性があります。アカウントIDと外部IDの両方を使用してロールを作成すると、同じプロジェクトおよび同じリージョンで実行されているTiDBクラスタのみがバケットにアクセスできます。 3. **Next**をクリックしてポリシー一覧を開き、先ほど作成したポリシーを選択してから**Next**をクリックします。 diff --git a/tidb-cloud/essential-changefeed-overview.md b/tidb-cloud/essential-changefeed-overview.md index 959e3ec07c7e1..029f9759e2dd9 100644 --- a/tidb-cloud/essential-changefeed-overview.md +++ b/tidb-cloud/essential-changefeed-overview.md @@ -13,7 +13,7 @@ TiDB Cloud changefeed を使用すると、TiDB Cloudから他のデータサー > > 1. [TiDB Cloudコンソール](https://tidbcloud.com)の右下隅にある**?**をクリックします。 > 2. **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。 -> 3. チケットを作成します。「説明」欄に「changefeedへの申請」と入力します。 +> 3. チケットを作成します。"Description"欄に"Apply for changefeed"と入力します。 > 4. **Submit**をクリックしてください。 > - TiDB Cloud Essentialインスタンスごとに最大10個の変更フィードが許可されています。 > - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンスでは、変更フィード機能は利用できません。 diff --git a/tidb-cloud/essential-changefeed-sink-to-kafka.md b/tidb-cloud/essential-changefeed-sink-to-kafka.md index c5780fa8fc995..4abc617cce7d4 100644 --- a/tidb-cloud/essential-changefeed-sink-to-kafka.md +++ b/tidb-cloud/essential-changefeed-sink-to-kafka.md @@ -13,7 +13,7 @@ summary: このドキュメントでは、TiDB Cloud Essentialから Apache Kafk > > 1. [TiDB Cloudコンソール](https://tidbcloud.com)の右下隅にある**?**をクリックします。 > 2. **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。 -> 3. チケットを作成します。「説明」欄に「changefeedへの申請」と入力します。 +> 3. チケットを作成します。"Description"欄に"Apply for changefeed"と入力します。 > 4. **Submit**をクリックしてください。 ## 制限 {#restrictions} @@ -153,7 +153,7 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト - Avroは、コンパクトで高速なバイナリデータフォーマットであり、豊富なデータ構造を備え、様々なフローシステムで広く利用されています。詳細については、 [Avroデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol)を参照してください。 - Canal-JSONは、解析が容易なプレーンなJSONテキスト形式です。詳細については、 [Canal-JSONデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-canal-json)を参照してください。 - オープンプロトコルは、監視、キャッシュ、全文インデックス作成、分析エンジン、および異なるデータベース間のプライマリとセカンダリのレプリケーションのためのデータソースを提供する行レベルのデータ変更通知プロトコルです。詳細については、 [オープンプロトコルデータフォーマット](https://docs.pingcap.com/tidb/stable/ticdc-open-protocol)を参照してください。 - - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を「イベント」と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)を参照してください。 + - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を"event"と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)を参照してください。 5. TiDB拡張フィールドをKafkaメッセージ本文に追加する場合は、 **TiDB Extension**オプションを有効にしてください。 diff --git a/tidb-cloud/essential-changefeed-sink-to-mysql.md b/tidb-cloud/essential-changefeed-sink-to-mysql.md index 7c44d0a2cc5b8..6e1e30862f162 100644 --- a/tidb-cloud/essential-changefeed-sink-to-mysql.md +++ b/tidb-cloud/essential-changefeed-sink-to-mysql.md @@ -13,7 +13,7 @@ summary: このドキュメントでは、Sink to MySQL changefeed を使用し > > 1. [TiDB Cloudコンソール](https://tidbcloud.com)の右下隅にある**?**をクリックします。 > 2. **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。 -> 3. チケットを作成します。「説明」欄に「changefeedへの申請」と入力します。 +> 3. チケットを作成します。"Description"欄に"Apply for changefeed"と入力します。 > 4. **Submit**をクリックしてください。 ## 制限 {#restrictions} diff --git a/tidb-cloud/features.md b/tidb-cloud/features.md index e133879d2a7b9..d178e2d1e7be0 100644 --- a/tidb-cloud/features.md +++ b/tidb-cloud/features.md @@ -20,4 +20,4 @@ summary: TiDB Cloudの各プランにおける機能サポート状況につい > **Tip:** > -> プライベートプレビューで機能をリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下隅にある**？**をクリックします。 次に、 **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。チケットを作成し、**Description**フィールドに「``の申請」と入力して、 **Submit**をクリックします。 +> プライベートプレビューで機能をリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下隅にある**？**をクリックします。 次に、 **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。チケットを作成し、**Description**フィールドに"Apply for ``"と入力して、 **Submit**をクリックします。 diff --git a/tidb-cloud/import-csv-files-serverless.md b/tidb-cloud/import-csv-files-serverless.md index 219db49f51852..f4c2a8b766c26 100644 --- a/tidb-cloud/import-csv-files-serverless.md +++ b/tidb-cloud/import-csv-files-serverless.md @@ -27,7 +27,7 @@ summary: Amazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object St - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`と`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 - - TiDB Cloudは、 `.gzip` 、 `.gz` 、 `.zstd` 、 `.zst` `.snappy`の各形式の圧縮ファイルのインポートをサポートしています。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。この形式では、 `${suffix}`は省略可能で、「000001」などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 + - TiDB Cloudは、 `.gzip` 、 `.gz` 、 `.zstd` 、 `.zst` `.snappy`の各形式の圧縮ファイルのインポートをサポートしています。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。この形式では、 `${suffix}`は省略可能で、"000001"などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 > **Note:** > diff --git a/tidb-cloud/import-csv-files.md b/tidb-cloud/import-csv-files.md index 093e549b65f30..df2bd454ee12f 100644 --- a/tidb-cloud/import-csv-files.md +++ b/tidb-cloud/import-csv-files.md @@ -30,7 +30,7 @@ aliases: ['/ja/tidbcloud/migrate-from-amazon-s3-or-gcs','/ja/tidbcloud/migrate-f - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`と`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順でなければなりません。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 - - TiDB Cloudは、 `.gzip` 、 `.gz` 、{ `.zst` `.zstd` 、および`.snappy`形式で圧縮ファイルをインポートすることをサポートしています。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`は省略可能で、「000001」などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 + - TiDB Cloudは、 `.gzip` 、 `.gz` 、{ `.zst` `.zstd` 、および`.snappy`形式で圧縮ファイルをインポートすることをサポートしています。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`は省略可能で、'000001'などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 > **Note:** > diff --git a/tidb-cloud/import-sample-data-serverless.md b/tidb-cloud/import-sample-data-serverless.md index 597685f699247..71f329456ccb2 100644 --- a/tidb-cloud/import-sample-data-serverless.md +++ b/tidb-cloud/import-sample-data-serverless.md @@ -43,7 +43,7 @@ summary: TiDB Cloud StarterまたはTiDB Cloud EssentialにUI経由でサンプ TiDB Cloud StarterまたはEssentialインスタンスに接続した後、ターミナルでいくつかのクエリを実行して結果を確認できます。例： -1. 「12th & U St NW」から始まる旅行記録を取得してください。 +1. "12th & U St NW"から始まる旅行記録を取得してください。 ```sql use bikeshare; diff --git a/tidb-cloud/import-sample-data.md b/tidb-cloud/import-sample-data.md index cde1e823913ed..f5124b5b6b28c 100644 --- a/tidb-cloud/import-sample-data.md +++ b/tidb-cloud/import-sample-data.md @@ -137,7 +137,7 @@ summary: TiDB Cloud DedicatedにUI経由でサンプルデータをインポー クラスターに接続した後、ターミナルでいくつかのクエリを実行して結果を確認できます。例えば、次のようになります。 -1. 「12th & U St NW」から始まる旅行記録を取得してください。 +1. "12th & U St NW"から始まる旅行記録を取得してください。 ```sql use bikeshare; diff --git a/tidb-cloud/integrate-tidbcloud-with-n8n.md b/tidb-cloud/integrate-tidbcloud-with-n8n.md index 3742c29945be4..547d867244d5b 100644 --- a/tidb-cloud/integrate-tidbcloud-with-n8n.md +++ b/tidb-cloud/integrate-tidbcloud-with-n8n.md @@ -162,7 +162,7 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ #### メッセージを作成する {#build-message} -1. RSSフィードの「読む」ノードの右側にある**+**をクリックします。 +1. "RSS Feed Read"ノードの右側にある**+**をクリックします。 2. `code`を検索してワークスペースに追加します。 3. `Run Once for All Items`モードを選択してください。 4. **JavaScript**ボックスに、以下のコードをコピー＆ペーストしてください。 diff --git a/tidb-cloud/manage-projects-and-resources.md b/tidb-cloud/manage-projects-and-resources.md index 8ce666627dca3..94b6c3b69e5d4 100644 --- a/tidb-cloud/manage-projects-and-resources.md +++ b/tidb-cloud/manage-projects-and-resources.md @@ -1,6 +1,6 @@ --- title: Manage TiDB Cloud Resources and Projects -summary: TiDB Cloudのリソースとプロジェクトの管理方法については、「マイTiDB」ページをご覧ください。 +summary: TiDB Cloudのリソースとプロジェクトの管理方法については、My TiDBページをご覧ください。 --- # TiDB Cloudのリソースとプロジェクトを管理する {#manage-tidb-cloud-resources-and-projects} diff --git a/tidb-cloud/migrate-from-mysql-using-aws-dms.md b/tidb-cloud/migrate-from-mysql-using-aws-dms.md index c935538ca47b5..6ccf8e8434883 100644 --- a/tidb-cloud/migrate-from-mysql-using-aws-dms.md +++ b/tidb-cloud/migrate-from-mysql-using-aws-dms.md @@ -170,7 +170,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 4. **Table mappings**のセクションで、移行するデータベースを指定します。 - スキーマ名は、Amazon RDS インスタンス内のデータベース名です。**Source name**のデフォルト値は「%」で、これは Amazon RDS 内のすべてのデータベースが TiDB に移行されることを意味します。これにより、Amazon RDS 内の`mysql`や`sys`などのシステムデータベースが TiDB クラスターに移行され、タスクが失敗します。そのため、特定のデータベース名を入力するか、すべてのシステムデータベースを除外することをお勧めします。たとえば、次のスクリーンショットの設定に従って、 `franktest`という名前のデータベースと、そのデータベース内のすべてのテーブルのみが移行されます。 + スキーマ名は、Amazon RDS インスタンス内のデータベース名です。**Source name**のデフォルト値は"%"で、これは Amazon RDS 内のすべてのデータベースが TiDB に移行されることを意味します。これにより、Amazon RDS 内の`mysql`や`sys`などのシステムデータベースが TiDB クラスターに移行され、タスクが失敗します。そのため、特定のデータベース名を入力するか、すべてのシステムデータベースを除外することをお勧めします。たとえば、次のスクリーンショットの設定に従って、 `franktest`という名前のデータベースと、そのデータベース内のすべてのテーブルのみが移行されます。 ![Table mappings](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-table-mappings.png) diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md index f1dd366b5914c..0a8ad07a35530 100644 --- a/tidb-cloud/migrate-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md @@ -288,7 +288,7 @@ SHOW VARIABLES WHERE Variable_name IN - 保存期間：最低3日間（推奨7日間）に設定してください。 - - 保持ファイル: 古いログが時期尚早に上書きされないように、「最大ファイル数」が十分であることを確認してください。 + - 保持ファイル: 古いログが時期尚早に上書きされないように、"Max number of files"が十分であることを確認してください。 - ストレージ保護：ストレージの使用状況を綿密に監視してください。ディスク容量の使用量がシステムしきい値に達すると、保持期間の設定に関わらず、RDS は最も古いバイナリログを自動的に削除しますのでご注意ください。 diff --git a/tidb-cloud/migrate-from-op-tidb.md b/tidb-cloud/migrate-from-op-tidb.md index 9b897f0d49e5e..cd9be228d6da3 100644 --- a/tidb-cloud/migrate-from-op-tidb.md +++ b/tidb-cloud/migrate-from-op-tidb.md @@ -343,7 +343,7 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート 6. 増分レプリケーションタスクを確認します。 - - 出力に「変更フィードの作成に成功しました！」というメッセージが表示された場合、レプリケーションタスクは正常に作成されています。 + - 出力に"Create changefeed successfully!"というメッセージが表示された場合、レプリケーションタスクは正常に作成されています。 - 状態が`normal`の場合、レプリケーションタスクは正常です。 diff --git a/tidb-cloud/monitoring-concepts.md b/tidb-cloud/monitoring-concepts.md index 6457a3b3265cf..4a6e92b1b2bee 100644 --- a/tidb-cloud/monitoring-concepts.md +++ b/tidb-cloud/monitoring-concepts.md @@ -32,7 +32,7 @@ TiDB Cloudのモニタリング機能は、TiDBのパフォーマンスを監視 - 変更フィードアラート -TiDB Cloudコンソールの「アラート」ページでは、 TiDB Cloud EssentialインスタンスまたはTiDB Cloud Dedicatedクラスタのアラートを表示したり、アラートルールを編集したり、アラート通知メールを購読したりできます。 +TiDB Cloudコンソールの**Alerts**ページでは、 TiDB Cloud EssentialインスタンスまたはTiDB Cloud Dedicatedクラスタのアラートを表示したり、アラートルールを編集したり、アラート通知メールを購読したりできます。 詳細については、 [TiDB Cloudの組み込みアラート機能](/tidb-cloud/monitor-built-in-alerting.md)を参照してください。 diff --git a/tidb-cloud/naming-conventions-for-data-import.md b/tidb-cloud/naming-conventions-for-data-import.md index 72d2e1253dbf0..7ddc834960680 100644 --- a/tidb-cloud/naming-conventions-for-data-import.md +++ b/tidb-cloud/naming-conventions-for-data-import.md @@ -83,7 +83,7 @@ Parquetファイルをインポートする際は、データファイルに以 ### Auroraのスナップショット {#aurora-snapshot} -Aurora Snapshot ファイルの場合、 `.parquet`フォルダー内の`${db_name}.${table_name}/`サフィックスを持つすべてのファイルは、命名規則に準拠します。データファイル名には、「az、0-9、-、_、."」で構成される任意のプレフィックスとサフィックス「.parquet」を含めることができます。 +Aurora Snapshot ファイルの場合、 `.parquet`フォルダー内の`${db_name}.${table_name}/`サフィックスを持つすべてのファイルは、命名規則に準拠します。データファイル名には、"a-z, 0-9, - , _ , ."で構成される任意のプレフィックスとサフィックス".parquet"を含めることができます。 例えば： diff --git a/tidb-cloud/premium/dual-layer-data-encryption-premium.md b/tidb-cloud/premium/dual-layer-data-encryption-premium.md index 1fa40dea6eb93..641f439b5e966 100644 --- a/tidb-cloud/premium/dual-layer-data-encryption-premium.md +++ b/tidb-cloud/premium/dual-layer-data-encryption-premium.md @@ -9,7 +9,7 @@ summary: TiDB Cloud Premiumインスタンスでデュアルレイヤーデー > **Note:** > -> 現在、デュアルレイヤーデータ暗号化機能はリクエストに応じてのみ利用可能です。この機能をリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)**？**をクリックし、 次に**Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。チケットを作成し、 **Description**フィールドに「デュアルレイヤーデータ暗号化の申請」と入力して、 **Submit**をクリックします。 +> 現在、デュアルレイヤーデータ暗号化機能はリクエストに応じてのみ利用可能です。この機能をリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)**？**をクリックし、 次に**Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。チケットを作成し、 **Description**フィールドに"Apply for Dual-Layer Data Encryption"と入力して、 **Submit**をクリックします。 ## 概要 {#overview} diff --git a/tidb-cloud/premium/import-csv-files-premium.md b/tidb-cloud/premium/import-csv-files-premium.md index 190b2f3da1ed9..76b83818a2c15 100644 --- a/tidb-cloud/premium/import-csv-files-premium.md +++ b/tidb-cloud/premium/import-csv-files-premium.md @@ -28,7 +28,7 @@ summary: Amazon S3またはAlibaba Cloud Object Storage Service（OSS）からCS - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`や`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 - - TiDB Cloud Premium は、 `.gzip` 、 `.gz` 、 `.zst` `.zstd` 、{ `.snappy`の形式で圧縮ファイルをインポートできます。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`省略可能で、「000001」などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 + - TiDB Cloud Premium は、 `.gzip` 、 `.gz` 、 `.zst` `.zstd` 、{ `.snappy`の形式で圧縮ファイルをインポートできます。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`省略可能で、"000001"などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 > **Note:** > diff --git a/tidb-cloud/premium/migrate-from-op-tidb-premium.md b/tidb-cloud/premium/migrate-from-op-tidb-premium.md index 6e503ec202aa4..f5b5912ea2db9 100644 --- a/tidb-cloud/premium/migrate-from-op-tidb-premium.md +++ b/tidb-cloud/premium/migrate-from-op-tidb-premium.md @@ -337,7 +337,7 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート 6. 増分レプリケーションタスクを確認します。 - - 出力に「変更フィードの作成に成功しました！」というメッセージが表示された場合、レプリケーションタスクは正常に作成されています。 + - 出力に"Create changefeed successfully!"というメッセージが表示された場合、レプリケーションタスクは正常に作成されています。 - 状態が`normal`の場合、レプリケーションタスクは正常です。 diff --git a/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md b/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md index 381b611d31f6c..6e800bb4d3887 100644 --- a/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md +++ b/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md @@ -19,7 +19,7 @@ summary: 2023年 11月 14日のTiDB Cloud Dedicated Scale 機能メンテナン ## インパクト {#impact} -メンテナンス期間中は、 [vCPUとRAMを変更する](https://docs.pingcap.com/tidbcloud/scale-tidb-cluster#change-vcpu-and-ram)無効化され、専用クラスタの vCPU と RAM を変更することはできません。ただし、 「クラスタの変更」ページでノード番号またはストレージを変更することは可能です。TiDB クラスタは通常通りデータの読み取りと書き込みを行うため、オンラインビジネスへの悪影響はありません。 +メンテナンス期間中は、 [vCPUとRAMを変更する](https://docs.pingcap.com/tidbcloud/scale-tidb-cluster#change-vcpu-and-ram)無効化され、専用クラスタの vCPU と RAM を変更することはできません。ただし、 "Modify Cluster"ページでノード番号またはストレージを変更することは可能です。TiDB クラスタは通常通りデータの読み取りと書き込みを行うため、オンラインビジネスへの悪影響はありません。 ### TiDB Cloudコンソール UI の影響を受ける機能 {#affected-features-of-tidb-cloud-console-ui} diff --git a/tidb-cloud/releases/release-notes-2022.md b/tidb-cloud/releases/release-notes-2022.md index b536c1e688810..0d8e3dbf37be8 100644 --- a/tidb-cloud/releases/release-notes-2022.md +++ b/tidb-cloud/releases/release-notes-2022.md @@ -147,7 +147,7 @@ summary: 2022年のTiDB Cloudのリリースノートについて説明します この機能はまだベータ版であり、リクエストに応じてのみ利用可能です。 - TiDB Cloudコンソールの右下隅にある**[ヘルプ]**をクリックします。 - - ダイアログの**説明**フィールドに「PITR を申請」と入力し、 **[送信]**をクリックします。 + - ダイアログの**説明**フィールドに"Apply for PITR"と入力し、 **[送信]**をクリックします。 - データベース監査ログ機能が GA になりました。 @@ -385,7 +385,7 @@ summary: 2022年のTiDB Cloudのリリースノートについて説明します 現在、 TiDB Cloud APIはベータ版であり、リクエストに応じてのみご利用いただけます。APIアクセスを申請するには、リクエストを送信してください。 - [TiDB Cloudコンソール](https://tidbcloud.com/project/clusters)の右下にある**[ヘルプ]**をクリックします。 - - ダイアログの**説明**フィールドに「 TiDB Cloud API に申請」と入力し、 **[送信]**をクリックします。 + - ダイアログの**説明**フィールドに"Apply for TiDB Cloud API"と入力し、 **[送信]**をクリックします。 ## 2022年8月16日 {#august-16-2022} diff --git a/tidb-cloud/releases/release-notes-2023.md b/tidb-cloud/releases/release-notes-2023.md index 8421fe69bf042..cc0bc7e24d56c 100644 --- a/tidb-cloud/releases/release-notes-2023.md +++ b/tidb-cloud/releases/release-notes-2023.md @@ -249,7 +249,7 @@ summary: 2023年のTiDB Cloudのリリースノートについて説明します - [Data Service（ベータ版）](https://tidbcloud.com/project/data-service)では基本認証がサポートされるようになりました。 - [「基本」HTTP認証](https://datatracker.ietf.org/doc/html/rfc7617)を使用したリクエストでは、公開鍵をユーザー名として、秘密鍵をパスワードとして提供できます。ダイジェスト認証と比較して、基本認証はよりシンプルで、Data Serviceエンドポイントを呼び出す際に簡単に使用できます。 + ["Basic" HTTP認証](https://datatracker.ietf.org/doc/html/rfc7617)を使用したリクエストでは、公開鍵をユーザー名として、秘密鍵をパスワードとして提供できます。ダイジェスト認証と比較して、基本認証はよりシンプルで、Data Serviceエンドポイントを呼び出す際に簡単に使用できます。 詳細については[エンドポイントを呼び出す](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)を参照してください。 @@ -479,8 +479,8 @@ summary: 2023年のTiDB Cloudのリリースノートについて説明します - 簡素化と明確化を目指し、製品名を更新しました。 - 「TiDB Cloud Serverless Tier」は「TiDB Cloud Serverless」という名前になりました。 - - 「TiDB Cloud Dedicated Tier」は「TiDB Cloud Dedicated」という名前になりました。 - - 「TiDB On-Premises」は「TiDB Self-Managed」という名前になりました。 + - "TiDB Cloud Dedicated Tier"は"TiDB Cloud Dedicated"という名前になりました。 + - "TiDB On-Premises"は"TiDB Self-Managed"という名前になりました。 刷新された名前でも、変わらぬ素晴らしいパフォーマンスをお楽しみください。お客様の体験こそが私たちの最優先事項です。 diff --git a/tidb-cloud/releases/release-notes-2025.md b/tidb-cloud/releases/release-notes-2025.md index 1522d8be83c1f..53b0bc7c2b0e6 100644 --- a/tidb-cloud/releases/release-notes-2025.md +++ b/tidb-cloud/releases/release-notes-2025.md @@ -374,9 +374,9 @@ summary: 2025年のTiDB Cloudのリリースノートについて説明します - **TiDB Cloud Starter** - - 「TiDB Cloud Serverless」の名前を「TiDB Cloud Starter」に変更します。 + - "TiDB Cloud Serverless"の名前を"TiDB Cloud Starter"に変更します。 - オートスケーリングのエントリープランは、新規ユーザーにとっての役割をより明確にするため、「TiDB Cloud Starter」に名称が変更されました。すべての機能、料金、無料利用枠に変更はありません。 + オートスケーリングのエントリープランは、新規ユーザーにとっての役割をより明確にするため、"TiDB Cloud Starter"に名称が変更されました。すべての機能、料金、無料利用枠に変更はありません。 2025年8月12日（PDT）より、既存のServerless クラスターは[TiDB Cloudコンソール](https://tidbcloud.com)にStarterとして表示されます。接続文字列、エンドポイント、データは変更されないため、コードを変更したり、ダウンタイムをスケジュールしたりする必要はありません。 @@ -416,9 +416,9 @@ summary: 2025年のTiDB Cloudのリリースノートについて説明します - **TiDB Cloud Starter** - 「TiDB Cloud Serverless」の名前を「TiDB Cloud Starter」に変更します。 + "TiDB Cloud Serverless"の名前を"TiDB Cloud Starter"に変更します。 - オートスケーリングのエントリープランは、新規ユーザーにとっての役割をより明確にするため、「TiDB Cloud Starter」に名称が変更されました。すべての機能、料金、無料利用枠に変更はありません。 + オートスケーリングのエントリープランは、新規ユーザーにとっての役割をより明確にするため、"TiDB Cloud Starter"に名称が変更されました。すべての機能、料金、無料利用枠に変更はありません。 2025年8月12日（PDT）より、既存のServerless クラスターは[TiDB Cloudコンソール](https://tidbcloud.com)にStarterとして表示されます。接続文字列、エンドポイント、データは変更されないため、コードを変更したり、ダウンタイムをスケジュールしたりする必要はありません。 diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md index bbbc053d854fd..b1f148b2b092e 100644 --- a/tidb-cloud/releases/tidb-cloud-release-notes.md +++ b/tidb-cloud/releases/tidb-cloud-release-notes.md @@ -684,7 +684,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', 詳細については、[クラウドストレージからサンプルデータ（SQLファイル）をインポートする](/tidb-cloud/import-sample-data.md)、[クラウドストレージからCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)、および[クラウドストレージからApache Parquetファイルをインポートする](/tidb-cloud/import-parquet-files.md)を参照してください。 - - セキュリティ追跡を強化するため、 TiDB Cloudのコンソール監査ログに「パブリックエンドポイントの有効化/無効化」イベントを追加します。 + - セキュリティ追跡を強化するため、 TiDB Cloudのコンソール監査ログに"Enable/Disable Public Endpoint"イベントを追加します。 ## 2026年2月3日 {#february-3-2026} diff --git a/tidb-cloud/releases/tidb-x-cloud.202510.1.md b/tidb-cloud/releases/tidb-x-cloud.202510.1.md index 3d3b99659467b..ac756d252e60f 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202510.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202510.1.md @@ -32,7 +32,7 @@ summary: TiDB-X-CLOUD.202510.1 カーネルの機能について説明します - **スケーリングの高速化**: 物理データ移行の必要をなくすことで、スケーリング性能を最大 10 倍向上させます。 - **タスク分離**: バックグラウンドのメンテナンスタスク（compaction など）とオンラインのトランザクション処理トラフィックの間で、干渉が発生しないようにします。 - - **リソースの弾力性**: コンピュートリソースがストレージ容量とは独立してスケールする、真の「pay-as-you-go」モデルを実現します。 + - **リソースの弾力性**: コンピュートリソースがストレージ容量とは独立してスケールする、真の"pay-as-you-go"モデルを実現します。 詳細は、[TiDB X アーキテクチャ](https://docs.pingcap.com/tidbcloud/tidb-x-architecture/?plan=premium) を参照してください。 diff --git a/tidb-cloud/serverless-faqs.md b/tidb-cloud/serverless-faqs.md index a7fb83301863d..343619fe9ca25 100644 --- a/tidb-cloud/serverless-faqs.md +++ b/tidb-cloud/serverless-faqs.md @@ -22,7 +22,7 @@ TiDB Cloud Starter は、2025年 8月 12日よりTiDB Cloud Serverless の新し Starter に名前が変更される前、 TiDB Cloudの Serverless 層は何千人もの開発者のエントリ ポイントとして機能し、自動的にスケーリングされ、数秒で起動し、十分な無料割り当てを超えるまでコストがかからない、本番環境対応のデータベースを提供していました。 -「サーバーレス」は、サービスが舞台裏でどのように動作するかを正確に反映していますが、初めて使用するユーザーの多くは、この用語が抽象的で、さまざまな意味が詰め込まれていると感じました。 +"serverless"は、サービスが舞台裏でどのように動作するかを正確に反映していますが、初めて使用するユーザーの多くは、この用語が抽象的で、さまざまな意味が詰め込まれていると感じました。 このエントリー層の目的をより明確にするため、 TiDB Cloudを使った構築を最も早く開始できる「Starter」に名称を変更しました。Serverless層に関するこれまでの内容はそのままです。 diff --git a/tidb-cloud/size-your-cluster.md b/tidb-cloud/size-your-cluster.md index e87838beab0c7..42d78887be5f4 100644 --- a/tidb-cloud/size-your-cluster.md +++ b/tidb-cloud/size-your-cluster.md @@ -211,7 +211,7 @@ Standardストレージタイプは、AWS でホストされ、TiDB バージョ #### PerformanceストレージとPlusストレージ {#performance-and-plus-storage} -PerformanceストレージとPlusストレージは、より高いパフォーマンスと安定性を提供し、これらの拡張機能を反映した価格設定となっています。現在、これらの2つのストレージタイプは、AWSにデプロイされたクラスターに対してのみ、リクエストに応じて利用可能です。PerformanceストレージまたはPlusストレージをリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**?**をクリックし、 **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に進みます。チケットを作成し、**Description**フィールドに「TiKVストレージタイプを申請」と入力して、 **Submit**をクリックします。 +PerformanceストレージとPlusストレージは、より高いパフォーマンスと安定性を提供し、これらの拡張機能を反映した価格設定となっています。現在、これらの2つのストレージタイプは、AWSにデプロイされたクラスターに対してのみ、リクエストに応じて利用可能です。PerformanceストレージまたはPlusストレージをリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**?**をクリックし、 **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に進みます。チケットを作成し、**Description**フィールドに"Apply for TiKV storage type"と入力して、 **Submit**をクリックします。 ## サイズTiFlash {#size-tiflash} @@ -269,4 +269,4 @@ Basicストレージは、パフォーマンスとコスト効率のバランス #### Plusストレージ {#plus-storage} -Plusストレージは、より高いパフォーマンスと安定性を提供し、これらの拡張機能を反映した価格設定となっています。現在、このストレージタイプは、AWSにデプロイされたクラスターに対してのみ、リクエストに応じて利用可能です。リクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**?**をクリックし、 **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に進みます。チケットを作成し、 **Description**フィールドに「 TiFlashストレージタイプを申請」と入力して、 **Submit**をクリックしてください。 +Plusストレージは、より高いパフォーマンスと安定性を提供し、これらの拡張機能を反映した価格設定となっています。現在、このストレージタイプは、AWSにデプロイされたクラスターに対してのみ、リクエストに応じて利用可能です。リクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**?**をクリックし、 **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に進みます。チケットを作成し、 **Description**フィールドに"Apply for TiFlash storage type"と入力して、 **Submit**をクリックしてください。 diff --git a/tidb-cloud/tidb-cloud-auditing.md b/tidb-cloud/tidb-cloud-auditing.md index 820699d4b272e..b7440651f6b56 100644 --- a/tidb-cloud/tidb-cloud-auditing.md +++ b/tidb-cloud/tidb-cloud-auditing.md @@ -14,7 +14,7 @@ TiDB Cloud は、実行された SQL文など、データベースへのユー > - AWS および Google Cloud でホストされるクラスターの場合: TiDB バージョンが v7.5.6 以降、または v8.5.2 以降である必要があります。 > - Azure でホストされるクラスターの場合: TiDB バージョンが v7.5.6 以降、または v8.5.2 以降であり、クラスターが 2026年 4月 15日以降に作成されている必要があります。 > -> その他のすべての TiDB バージョンまたはクラスター構成では、データベース監査ログはリクエストに応じて利用できます。対象外のクラスターへのアクセスをリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**？**をクリックし、 **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に進みます。チケットを作成し、 **Description**欄に「データベース監査ログの申請」と入力して、 **Submit**をクリックしてください。 +> その他のすべての TiDB バージョンまたはクラスター構成では、データベース監査ログはリクエストに応じて利用できます。対象外のクラスターへのアクセスをリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**？**をクリックし、 **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に進みます。チケットを作成し、 **Description**欄に"Apply for database audit logging"と入力して、 **Submit**をクリックしてください。 > > このドキュメントは、監査ログ機能のパブリックプレビュー版にのみ適用されます。以前のバージョンのデータベース監査ログを使用している場合は、 [TiDB Cloud Database Audit Logging (Legacy)](/tidb-cloud/tidb-cloud-auditing-legacy.md)を参照してください。 diff --git a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md index e0929da1e3987..29d20787d9a1e 100644 --- a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md +++ b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md @@ -72,7 +72,7 @@ TiDB Cloudクラスターでエラーが発生した場合は、ドキュメン このエラーは、ソースデータベースへの接続に失敗したことを意味します。ソースデータベースが起動しており、指定されたパラメータを使用して接続できるかどうかを確認してください。ソースデータベースが利用可能であることを確認したら、 **Restart**をクリックしてタスクの復旧を試みてください。 -### 移行タスクが中断され、「ドライバー: 接続不良」または「無効な接続」というエラーが含まれています。 {#the-migration-task-is-interrupted-and-contains-the-error-driver-bad-connection-or-invalid-connection} +### 移行タスクが中断され、"driver: bad connection"または"invalid connection"というエラーが含まれています。 {#the-migration-task-is-interrupted-and-contains-the-error-driver-bad-connection-or-invalid-connection} このエラーは、ダウンストリームの TiDB クラスタへの接続に失敗したことを意味します。ダウンストリームの TiDB クラスタが正常な状態（ `Available`および`Modifying`を含む）であり、ジョブで指定されたユーザー名とパスワードで接続できるかどうかを確認してください。ダウンストリームの TiDB クラスタが利用可能であることを確認したら、 **Restart**をクリックしてタスクを再開してみてください。 diff --git a/tidb-cloud/tidb-cloud-faq.md b/tidb-cloud/tidb-cloud-faq.md index 96ecdca27dedc..8a402f8cb9f62 100644 --- a/tidb-cloud/tidb-cloud-faq.md +++ b/tidb-cloud/tidb-cloud-faq.md @@ -55,7 +55,7 @@ TiDBは、金融サービス、ゲーム、eコマースなど、さまざまな TiDB Cloudは99.99% の SLA を提供します。詳細については、 [TiDB Cloudサービスのサービスレベル契約](https://www.pingcap.com/legal/service-level-agreement-for-tidb-cloud-services/)を参照してください。 -### TiDB Cloudにおける「PREVIEW」とはどういう意味ですか？ {#what-does-preview-mean-in-tidb-cloud} +### TiDB Cloudにおける"PREVIEW"とはどういう意味ですか？ {#what-does-preview-mean-in-tidb-cloud} PREVIEWとは、 TiDB Cloudの機能またはサービスが一般提供（GA）される前に、一般公開されるプレビュー段階のことです。 @@ -87,7 +87,7 @@ Placement Driver（PD）は、クラスターのメタデータを格納する ### TiDBはTiKVノード間でどのようにデータを複製するのですか？ {#how-does-tidb-replicate-data-between-the-tikv-nodes} -TiKVはキーと値のペアの空間をキー範囲に分割し、各キー範囲を「リージョン」として扱います。TiKVでは、データはクラスタ内のすべてのノードに分散され、リージョンを基本単位として使用します。PDは、リージョンをクラスタ内のすべてのノードにできるだけ均等に分散（スケジューリング）する役割を担います。 +TiKVはキーと値のペアの空間をキー範囲に分割し、各キー範囲を"Region"として扱います。TiKVでは、データはクラスタ内のすべてのノードに分散され、リージョンを基本単位として使用します。PDは、リージョンをクラスタ内のすべてのノードにできるだけ均等に分散（スケジューリング）する役割を担います。 TiDBは、 Raftコンセンサスアルゴリズムを使用して、リージョンごとにデータを複製します。異なるノードに保存されたリージョンの複数のレプリカがRaftグループを形成します。 diff --git a/tidb-cloud/troubleshoot-import-access-denied-error.md b/tidb-cloud/troubleshoot-import-access-denied-error.md index 9749c5c21c2ac..86a80bb206d77 100644 --- a/tidb-cloud/troubleshoot-import-access-denied-error.md +++ b/tidb-cloud/troubleshoot-import-access-denied-error.md @@ -73,7 +73,7 @@ IAMロールが存在しない場合は、 [Amazon S3 アクセスを構成す IAMユーザーの AWS アクセスキーを使用して Amazon S3 バケットにアクセスすると、次のエラーが発生する場合があります。 -- アクセスキーID「{access_key_id}」とシークレットアクセスキー「{secret_access_key}」を使用したソース「{bucket_uri}」へのアクセスが拒否されました。 +- アクセスキーID'{access_key_id}'とシークレットアクセスキー'{secret_access_key}'を使用したソース'{bucket_uri}'へのアクセスが拒否されました。 これは、権限不足のため、 TiDB Cloud がAmazon S3 バケットにアクセスできなかったことを示しています。Amazon S3 バケットにアクセスするには、以下の権限が必要です。 @@ -200,7 +200,7 @@ IAMユーザーのポリシーを確認するには、次の手順を実行し 1. AWS マネジメントコンソールで Amazon S3 コンソールを開き、 **Buckets**ページに移動します。バケットのリストが表示されます。 2. バケットのリストで、対象のバケットを見つけてクリックします。バケット情報ページが表示されます。 -3. バケット情報ページで**Permissions**タブをクリックし、 **Object Ownership**領域までスクロールダウンします。「Object Ownership」設定が「Bucket owner enforced」になっていることを確認してください。 +3. バケット情報ページで**Permissions**タブをクリックし、 **Object Ownership**領域までスクロールダウンします。"Object Ownership"設定が"Bucket owner enforced"になっていることを確認してください。 設定が「Bucket owner enforced」ではない場合、アカウントにこのバケット内のすべてのオブジェクトに対する十分な権限がないため、エラー`AccessDenied`が発生します。 diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index d3d5d9a2290d9..4101c1a6eb0c5 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -197,7 +197,7 @@ TiDB 構成ファイルは、コマンドラインパラメーターよりも多 - TCP4のみでのリスニングを有効または無効にします。 - デフォルト値: `false` -- [TCPヘッダーからの実際のクライアントIP](https://github.com/alibaba/LVS/tree/master/kernel/net/toa)が「tcp4」プロトコルで正しく解析できるため、ロードバランシングのために TiDB を LVS とともに使用する場合、このオプションを有効にすると便利です。 +- [TCPヘッダーからの実際のクライアントIP](https://github.com/alibaba/LVS/tree/master/kernel/net/toa)が"tcp4"プロトコルで正しく解析できるため、ロードバランシングのために TiDB を LVS とともに使用する場合、このオプションを有効にすると便利です。 ### `enable-enum-length-limit` v5.0で追加 {#enable-enum-length-limit-new-in-v50} @@ -473,7 +473,7 @@ TiDB 構成ファイルは、コマンドラインパラメーターよりも多 - パスワードの有効期限が切れたときに、TiDBがクライアント接続を切断するかどうかを決定します。 - デフォルト値: `true` - オプション値: `true` 、 `false` -- `true`に設定すると、パスワードの有効期限が切れたときにクライアント接続が切断されます。 `false`に設定すると、クライアント接続は「サンドボックスモード」に制限され、ユーザーはパスワードリセット操作のみを実行できます。 +- `true`に設定すると、パスワードの有効期限が切れたときにクライアント接続が切断されます。 `false`に設定すると、クライアント接続は"sandbox mode"に制限され、ユーザーはパスワードリセット操作のみを実行できます。 ### `session-token-signing-cert` v6.4.0 の新機能 {#session-token-signing-cert-new-in-v640} @@ -899,7 +899,7 @@ TiDBサービスの状態に関するコンフィグレーション。 - TiDBがデータを読み取ることを許可するエンジンを制御します。 - デフォルト値: ["tikv", "tiflash", "tidb"]。これは、エンジンがオプティマイザによって自動的に選択されることを示します。 -- 値のオプション: 「tikv」、「tiflash」、「tidb」の任意の組み合わせ。例: ["tikv", "tidb"] または ["tiflash", "tidb"] +- 値のオプション: "tikv"、"tiflash"、"tidb"の任意の組み合わせ。例: ["tikv", "tidb"] または ["tiflash", "tidb"] ## instance {#instance} diff --git a/tidb-lightning/data-import-best-practices.md b/tidb-lightning/data-import-best-practices.md index ef7cf0471541f..2a15dca4d7dc0 100644 --- a/tidb-lightning/data-import-best-practices.md +++ b/tidb-lightning/data-import-best-practices.md @@ -19,7 +19,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni - [ソースファイルの準備](#prepare-source-files) - [ストレージスペースの見積もり](#estimate-storage-space) - [設定パラメータを変更する](#change-configuration-parameters) -- [「checksum mismatch」エラーを解決する](#resolve-the-checksum-mismatch-error) +- ["checksum mismatch"エラーを解決する](#resolve-the-checksum-mismatch-error) - [チェックポイントを有効にする](#enable-checkpoint) - [トラブルシューティング](#troubleshooting) @@ -97,9 +97,9 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni TiDB Lightningパラメータの詳細については、 [TiDB Lightning設定パラメータ](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 -## 「checksum mismatch」エラーを解決する {#resolve-the-checksum-mismatch-error} +## "checksum mismatch"エラーを解決する {#resolve-the-checksum-mismatch-error} -データ検証中に競合が発生する可能性があります。エラーメッセージは「checksum mismatch」です。この問題を解決するには、必要に応じて以下の手順を実行してください。 +データ検証中に競合が発生する可能性があります。エラーメッセージは"checksum mismatch"です。この問題を解決するには、必要に応じて以下の手順を実行してください。 1. ソースデータで主キーまたは一意キーの競合がないか確認し、再インポート前に競合を解決してください。ほとんどの場合、これが最も一般的な原因です。 2. テーブルの主キーまたは一意キーの定義が適切かどうかを確認してください。適切でない場合は、テーブル定義を修正してデータを再インポートしてください。 diff --git a/tidb-lightning/tidb-lightning-checkpoints.md b/tidb-lightning/tidb-lightning-checkpoints.md index 625fe6748ce49..83f4c9b0474c4 100644 --- a/tidb-lightning/tidb-lightning-checkpoints.md +++ b/tidb-lightning/tidb-lightning-checkpoints.md @@ -70,7 +70,7 @@ tidb-lightning-ctl --checkpoint-error-destroy='`schema`.`table`' - 以前にテーブル`` `schema`.`table` ``インポートに失敗した場合、このオプションは次の操作を実行します。 1. ターゲットデータベースからテーブル`` `schema`.`table` ``を削除します。つまり、インポートされたすべてのデータが削除されます。 - 2. このテーブルのチェックポイント レコードを「まだ開始されていない」状態にリセットします。 + 2. このテーブルのチェックポイント レコードを"not yet started"状態にリセットします。 - テーブル`` `schema`.`table` ``に関連するエラーがない場合、この操作は何も実行されません。 @@ -91,7 +91,7 @@ tidb-lightning-ctl --checkpoint-error-ignore=all > **Note:** > -> このオプションは、エラーが実際に無視できると確信できる場合にのみ使用してください。そうでない場合、インポートされたデータの一部が失われる可能性があります。唯一の安全策は最終的な「チェックサム」チェックであるため、 `--checkpoint-error-ignore`を使用する場合は常に「チェックサム」オプションを有効にする必要があります。 +> このオプションは、エラーが実際に無視できると確信できる場合にのみ使用してください。そうでない場合、インポートされたデータの一部が失われる可能性があります。唯一の安全策は最終的な"checksum"チェックであるため、 `--checkpoint-error-ignore`を使用する場合は常に"checksum"オプションを有効にする必要があります。 ### `--checkpoint-remove` {#--checkpoint-remove} diff --git a/tidb-lightning/tidb-lightning-command-line-full.md b/tidb-lightning/tidb-lightning-command-line-full.md index 4f83c74c2f8a4..660105ed69470 100644 --- a/tidb-lightning/tidb-lightning-command-line-full.md +++ b/tidb-lightning/tidb-lightning-command-line-full.md @@ -21,7 +21,7 @@ TiDB Lightning は、設定ファイルまたはコマンドラインから設 | `-L ` | ログレベル：`debug` 、 `info` 、 `warn` 、 `error` 、または`fatal` 。デフォルトは`info` 。 | `lightning.level` | | `-f ` | [テーブルフィルタルール](/table-filter.md) 。複数回指定できます。 | `mydumper.filter` | | `--backend ` | インポートモードを選択します。`local`は[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を、 `tidb`は[論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)を指します。 | `tikv-importer.backend` | -| `--log-file ` | ログファイルのパス。デフォルトでは`/tmp/lightning.log.{timestamp}`です。「-」に設定すると、ログファイルは標準出力に出力されます。 | `lightning.log-file` | +| `--log-file ` | ログファイルのパス。デフォルトでは`/tmp/lightning.log.{timestamp}`です。"-"に設定すると、ログファイルは標準出力に出力されます。 | `lightning.log-file` | | `--status-addr ` | TiDB Lightning HTTPサーバーのリスニング アドレス | `lightning.status-addr` | | `--pd-urls ` | PDエンドポイントアドレス。v7.6.0以降、TiDBは複数のPDアドレスの設定をサポートします。 | `tidb.pd-addr` | | `--tidb-host ` | TiDBサーバーホスト | `tidb.host` | @@ -30,15 +30,15 @@ TiDB Lightning は、設定ファイルまたはコマンドラインから設 | `--tidb-user ` | TiDBに接続するためのユーザー名 | `tidb.user` | | `--tidb-password ` | TiDBに接続するためのパスワード。パスワードはプレーンテキストまたはBase64エンコードのいずれかで指定できます。 | `tidb.password` | | `--enable-checkpoint ` | チェックポイントを有効にするかどうか（デフォルト = true） | `checkpoint.enable` | -| `--analyze ` | インポート後にテーブルを分析します。使用可能な値は「必須」、「オプション」（デフォルト値）、および「オフ」です。 | `post-restore.analyze` | -| `--checksum ` | インポート後にチェックサムを比較します。使用可能な値は「必須」（デフォルト値）、「オプション」、「オフ」です。 | `post-restore.checksum` | +| `--analyze ` | インポート後にテーブルを分析します。使用可能な値は"required"、"optional"（デフォルト値）、および"off"です。 | `post-restore.analyze` | +| `--checksum ` | インポート後にチェックサムを比較します。使用可能な値は"required"（デフォルト値）、"optional"、"off"です。 | `post-restore.checksum` | | `--check-requirements ` | タスクを開始する前にクラスターのバージョンの互換性を確認し、実行中に TiKV に 10% 以上の空き容量が残っているかどうかを確認します。(デフォルト = true) | `lightning.check-requirements` | | `--ca ` | TLS接続のCA証明書パス | `security.ca-path` | | `--cert ` | TLS接続の証明書パス | `security.cert-path` | | `--key ` | TLS接続の秘密鍵パス | `security.key-path` | | `--server-mode` | TiDB Lightningをサーバーモードで起動します。このモードでは、TiDB Lightningはすぐにインポートを開始するのではなく、HTTP API を通じてインポートタスクが送信されるのを待機します。 | `lightning.server-mode` | -コマンドラインパラメータと設定ファイル内の対応する設定の両方を指定した場合、コマンドラインパラメータが優先されます。例えば、 `tiup tidb-lightning -L debug --config cfg.toml`を実行すると、 `cfg.toml`の内容に関係なく、ログレベルは常に「debug」に設定されます。 +コマンドラインパラメータと設定ファイル内の対応する設定の両方を指定した場合、コマンドラインパラメータが優先されます。例えば、 `tiup tidb-lightning -L debug --config cfg.toml`を実行すると、 `cfg.toml`の内容に関係なく、ログレベルは常に"debug"に設定されます。 ## `tidb-lightning-ctl` {#tidb-lightning-ctl} diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index c6c64513f07d0..0a1b8620fbcbc 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -7,7 +7,7 @@ summary: TiDB Lightningの CLI の使用方法とサンプル構成について このドキュメントでは、グローバル設定とタスク設定のサンプルを提供し、コマンドラインパラメータの使用方法を説明します。サンプル設定ファイルは[`lightning/tidb-lightning.toml`](https://github.com/pingcap/tidb/blob/master/lightning/tidb-lightning.toml)にあります。 -TiDB Lightningには「グローバル」と「タスク」という2つの設定クラスがあり、構造は互換性があります。これらの違いは、サーバーモードが有効な場合にのみ発生します。サーバーモードが無効（デフォルト）の場合、TiDB Lightningは1つのタスクのみを実行し、グローバル設定とタスク設定の両方に同じ設定ファイルを使用します。 +TiDB Lightningには"global"と"task"という2つの設定クラスがあり、構造は互換性があります。これらの違いは、サーバーモードが有効な場合にのみ発生します。サーバーモードが無効（デフォルト）の場合、TiDB Lightningは1つのタスクのみを実行し、グローバル設定とタスク設定の両方に同じ設定ファイルを使用します。 ## TiDB Lightning （グローバル） {#tidb-lightning-global} @@ -68,13 +68,13 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `index-concurrency` {#index-concurrency} -- 同時に開くインデックスエンジンの最大数。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時実行数を制御します。通常はデフォルト値を使用してください。 +- 同時に開くインデックスエンジンの最大数。各テーブルは、インデックスを格納する1つの"index engine"と、行データを格納する複数の"data engine"に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時実行数を制御します。通常はデフォルト値を使用してください。 #### `table-concurrency` {#table-concurrency} -- 同時に開くことができるデータエンジンの最大数です。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時接続数を制御します。通常はデフォルト値を使用してください。 +- 同時に開くことができるデータエンジンの最大数です。各テーブルは、インデックスを格納する1つの"index engine"と、行データを格納する複数の"data engine"に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時接続数を制御します。通常はデフォルト値を使用してください。 @@ -242,7 +242,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - デフォルト値: `'none'` - 値のオプション: - `'none'` : 重複レコードを検出しません。データソースに重複レコードがある場合、ターゲットTiDBでデータの不整合が発生する可能性があります。`duplicate-resolution = 'none'`を設定し、 `conflict.strategy`を設定していない場合、 TiDB Lightningは自動的に`conflict.strategy`に`""`を割り当てます。 - - `'remove'` : `duplicate-resolution = 'remove'`設定し、 `conflict.strategy`設定しない場合、 TiDB Lightning は自動的に`conflict.strategy`に「置換」を割り当て、新しいバージョンの競合検出を有効にします。 + - `'remove'` : `duplicate-resolution = 'remove'`設定し、 `conflict.strategy`設定しない場合、 TiDB Lightning は自動的に`conflict.strategy`に"replace"を割り当て、新しいバージョンの競合検出を有効にします。 #### `send-kv-pairs` {#send-kv-pairs} @@ -364,8 +364,8 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `batch-import-ratio` {#batch-import-ratio} - エンジンファイルは順番にインポートする必要があります。並列処理のため、複数のデータエンジンがほぼ同時にインポートされ、キューが生成されてリソースが浪費されます。そのため、 TiDB Lightning、リソースを適切に配分するために、最初の数バッチのサイズをわずかに大きくしています。 -- スケールアップ係数はこのパラメータによって制御されます。このパラメータは、完全な同時実行における「インポート」ステップと「書き込み」ステップの所要時間の比率を表します。これは、約1GiBの単一テーブルにおける比率（インポート所要時間/書き込み所要時間）を使用して計算できます。正確な時間はログで確認できます。 -- 「インポート」の方が高速であれば、バッチサイズの分散は小さくなり、比率が 0 であればバッチサイズは均一になります。 +- スケールアップ係数はこのパラメータによって制御されます。このパラメータは、完全な同時実行における"import"ステップと"write"ステップの所要時間の比率を表します。これは、約1GiBの単一テーブルにおける比率（インポート所要時間/書き込み所要時間）を使用して計算できます。正確な時間はログで確認できます。 +- "import"の方が高速であれば、バッチサイズの分散は小さくなり、比率が 0 であればバッチサイズは均一になります。 - 範囲: `[0, 1)` @@ -405,7 +405,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - ソースデータファイルの文字セット変換中に互換性のない文字があった場合に置換する文字を指定します。 - この設定は、フィールドセパレーター、引用符定義子、改行と重複してはいけません。デフォルト値を変更すると、ソースデータファイルの解析パフォーマンスが低下する可能性があります。 -- デフォルト値: `"\uFFFD"` 。これは、UTF-8 エンコードにおける「エラー」の Rune または Unicode 置換文字です。 +- デフォルト値: `"\uFFFD"` 。これは、UTF-8 エンコードにおける"error"の Rune または Unicode 置換文字です。 #### `strict-format` {#strict-format} @@ -414,7 +414,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - 値のオプション: `true` 、 `false` - `strict-format = true`次のことが求められます: - CSV では、引用符で囲まれている場合でも、すべての値にリテラルの改行 ( `U+000A`と`U+000D` 、または`\r`と`\n` ) を含めることはできません。つまり、改行は行を区切るために厳密に使用されます。 - - 厳密なフォーマットにより、 TiDB Lightningは並列処理において大きなファイルの分割位置を迅速に特定できます。ただし、入力データが「厳密」でない場合、有効なデータが半分に分割され、結果が破損する可能性があります。 + - 厳密なフォーマットにより、 TiDB Lightningは並列処理において大きなファイルの分割位置を迅速に特定できます。ただし、入力データが"strict"でない場合、有効なデータが半分に分割され、結果が破損する可能性があります。 #### `max-region-size` {#max-region-size} @@ -590,7 +590,7 @@ CSV ファイルの解析方法を構成します。 - SQL 接続に TLS を使用するかどうかを制御します。 - 値のオプション: - - `""` : [`[tidb.security]`](#tidbsecurity)セクションが設定されている場合、TLS を強制します（「cluster」と同じ）。それ以外の場合は`"false"`と同じです。 + - `""` : [`[tidb.security]`](#tidbsecurity)セクションが設定されている場合、TLS を強制します（"cluster"と同じ）。それ以外の場合は`"false"`と同じです。 - `"false"` : TLS を無効にします。 - `"cluster"` : TLS を強制し、 [`[tidb.security]`](#tidbsecurity)セクションで指定された CA を使用してサーバーの証明書を検証します。 - `"skip-verify"` : TLSを強制しますが、サーバーの証明書を検証しません。この設定は安全ではないことに注意してください。 diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index 7adb5880eee52..cf3b093fc5556 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -127,7 +127,7 @@ nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out & 並列インポート中、 TiDB Lightning はタスクの開始後に次のチェックを自動的に実行します。 - ローカルディスク（構成`sort-kv-dir`で制御）とTiKVクラスターに、データのインポートに必要な空き容量があるかどうかを確認してください。必要なディスク容量については、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)を参照してください。TiDB Lightningはデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。 -- TiKVクラスタ内のリージョンが均等に分散されているか、また空きリージョンが多すぎないかを確認してください。空きリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 +- TiKVクラスタ内のリージョンが均等に分散されているか、また空きリージョンが多すぎないかを確認してください。空きリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり"1000"または"3 times the number of tables"のいずれか大きい方を超える場合、インポートは実行できません。 - データソースからデータが順番にインポートされているか確認します。確認結果に基づいて`mydumper.batch-size`のサイズが自動的に調整されます。そのため、 `mydumper.batch-size`構成は利用できなくなります。 チェックをオフにして、 `lightning.check-requirements`設定で強制インポートを実行することもできます。詳細なチェックについては、 [TiDB Lightning事前チェック](/tidb-lightning/tidb-lightning-prechecks.md)を参照してください。 @@ -198,7 +198,7 @@ parallel-import = true - ソースファイル内の無効なデータを示すチェックサムの不一致など、データの不正確さにつながるエラーがログに記録されている場合は、次の手順を実行してこの問題を解決できます。 - 1. 成功したノードを含むすべてのLightningノードで[`checkpoint-error-destroy`](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-destroy)コマンドを実行します。このコマンドは、失敗したテーブルからインポートされたデータを削除し、これらのテーブルのチェックポイントステータスを「未開始」にリセットします。 + 1. 成功したノードを含むすべてのLightningノードで[`checkpoint-error-destroy`](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-destroy)コマンドを実行します。このコマンドは、失敗したテーブルからインポートされたデータを削除し、これらのテーブルのチェックポイントステータスを"not yet started"にリセットします。 2. 正常に終了するノードを含むすべてのTiDB Lightningノードで[`filter`](/table-filter.md)パラメータを使用して、失敗したテーブルのデータを再構成してインポートします。 diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md index c2cdb13221e8f..a8fc59cc8bd85 100644 --- a/tidb-lightning/tidb-lightning-faq.md +++ b/tidb-lightning/tidb-lightning-faq.md @@ -87,7 +87,7 @@ TiDB Lightning は、10 ギガビット ネットワークカードで使用す ## TiDB Lightning がターゲット TiKV クラスターにこれほど多くの空き容量を必要とするのはなぜですか? {#why-tidb-lightning-requires-so-much-free-space-in-the-target-tikv-cluster} -デフォルト設定のレプリカ数3の場合、ターゲットTiKVクラスターに必要な容量はデータソースの6倍になります。「2」という倍数は、以下の要素がデータソースに反映されていないため、控えめな見積もりです。 +デフォルト設定のレプリカ数3の場合、ターゲットTiKVクラスターに必要な容量はデータソースの6倍になります。"2"という倍数は、以下の要素がデータソースに反映されていないため、控えめな見積もりです。 - インデックスが占めるスペース - RocksDBにおける空間増幅 @@ -153,7 +153,7 @@ CREATE PLACEMENT POLICY p1 PRIMARY_REGION="us-east" REGIONS="us-east,us-west"; ![TiDB Lightning FAQ - situation 1](/media/lightning-faq-situation-1.jpg) -**状況2：**ターゲットクラスタがフォロワーレプリカを「us-mid」リージョン内の別のTiKVノードに配置しており、トポロジ内に「us-west」リージョンが含まれていない場合。このような場合、ターゲットクラスタで配置ポリシーを作成すると、 TiDB Lightningはエラーを報告します。 +**状況2：**ターゲットクラスタがフォロワーレプリカを"us-mid"リージョン内の別のTiKVノードに配置しており、トポロジ内に"us-west"リージョンが含まれていない場合。このような場合、ターゲットクラスタで配置ポリシーを作成すると、 TiDB Lightningはエラーを報告します。 ![TiDB Lightning FAQ - situation 2](/media/lightning-faq-situation-2.jpg) diff --git a/tidb-lightning/tidb-lightning-glossary.md b/tidb-lightning/tidb-lightning-glossary.md index 060beffabc0c6..3244ff136d95e 100644 --- a/tidb-lightning/tidb-lightning-glossary.md +++ b/tidb-lightning/tidb-lightning-glossary.md @@ -31,7 +31,7 @@ TiDB LightningはTiDBを経由せずにデータをインポートするため ### バックエンド {#back-end} -バックエンドとは、TiDB Lightningが解析結果を送信する宛先です。「backend」とも表記されます。 +バックエンドとは、TiDB Lightningが解析結果を送信する宛先です。"backend"とも表記されます。 詳細は[TiDB Lightningアーキテクチャ](/tidb-lightning/tidb-lightning-overview.md)を参照。 @@ -93,7 +93,7 @@ TiKV インポーターでは、エンジンは KV ペアをソートするた TiDB Lightningは、エンジンを介してTiKV Importerにデータを転送します。まずエンジンを開き、KVペアを（順序は問わず）エンジンに送信し、最後にエンジンを閉じます。エンジンは閉じた後、受信したKVペアをソートします。閉じられたエンジンは、TiKVストアにアップロードして取り込みを行うことができます。 -エンジンは TiKV インポーターの`import-dir`を一時ストレージとして使用します。これは「エンジンファイル」と呼ばれることもあります。 +エンジンは TiKV インポーターの`import-dir`を一時ストレージとして使用します。これは"engine files"と呼ばれることもあります。 [データエンジン](/tidb-lightning/tidb-lightning-glossary.md#data-engine)と[インデックスエンジン](/tidb-lightning/tidb-lightning-glossary.md#index-engine)も参照してください。 @@ -139,7 +139,7 @@ TiDB Lightningは複数のインデックスエンジンを同時に処理しま ### KVペア {#kv-pair} -「キーと値のペア」の略語。 +"key-value pair"の略語。 ### KVエンコーダ {#kv-encoder} diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md index 72e68af080c32..6cadfbb29edff 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode.md @@ -19,7 +19,7 @@ backend = "local" ## 実装 {#implementation} -1. TiDB Lightningは、データをインポートする前に、TiKVノードを自動的に「インポートモード」に切り替えます。これにより、書き込みパフォーマンスが向上し、自動コンパクションが停止します。TiDB Lightningは、 TiDB Lightningのバージョンに応じて、グローバルスケジューリングを一時停止するかどうかを決定します。 +1. TiDB Lightningは、データをインポートする前に、TiKVノードを自動的に"import mode"に切り替えます。これにより、書き込みパフォーマンスが向上し、自動コンパクションが停止します。TiDB Lightningは、 TiDB Lightningのバージョンに応じて、グローバルスケジューリングを一時停止するかどうかを決定します。 - v7.1.0 以降では、 TiDB Lightningパラメータ[`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md)を使用して、一時停止スケジュールの範囲を制御できます。 - TiDB Lightningバージョン v6.2.0 から v7.0.0 の場合、グローバルスケジューリングの一時停止の動作は TiDB クラスタのバージョンによって異なります。TiDB クラスタが v6.1.0 以上の場合、 TiDB Lightning はターゲットテーブルデータが格納されているリージョンのスケジューリングを一時停止します。インポートが完了すると、 TiDB Lightning はスケジューリングを回復します。その他のバージョンの場合、 TiDB Lightning はグローバルスケジューリングを一時停止します。 @@ -31,7 +31,7 @@ backend = "local" 3. 各テーブルは複数の連続した**ブロック**に分割されるため、 TiDB Lightning は大規模なテーブル (200 GB 以上) からデータを並列にインポートできます。 -4. TiDB Lightningは、キーと値のペアを処理するために、各ブロックごとに「エンジンファイル」を用意します。TiDB LightningはSQLダンプを並列に読み取り、データソースをTiDBと同じエンコーディングでキーと値のペアに変換し、キーと値のペアをソートしてローカルの一時ストレージファイルに書き込みます。 +4. TiDB Lightningは、キーと値のペアを処理するために、各ブロックごとに"engine file"を用意します。TiDB LightningはSQLダンプを並列に読み取り、データソースをTiDBと同じエンコーディングでキーと値のペアに変換し、キーと値のペアをソートしてローカルの一時ストレージファイルに書き込みます。 5. エンジンファイルが書き込まれると、 TiDB Lightning はターゲット TiKV クラスター上のデータの分割とスケジュールを開始し、その後、データを TiKV クラスターにインポートします。 @@ -43,7 +43,7 @@ backend = "local" AUTO_INCREMENT IDは行数の**上限**に基づいて推定され、テーブルデータファイルの合計サイズに比例します。そのため、AUTO_INCREMENT IDは通常、実際の行数よりも大きくなります。これは、AUTO_INCREMENT IDが[必ずしも連続しているわけではない](/mysql-compatibility.md#auto-increment-id)ため、正常な動作です。 -7. すべての手順が完了すると、 TiDB Lightningは自動的にTiKVノードを「通常モード」に切り替えます。グローバルスケジューリングが一時停止されている場合、 TiDB Lightningはグローバルスケジューリングも回復します。その後、TiDBクラスタは通常通りサービスを提供できるようになります。 +7. すべての手順が完了すると、 TiDB Lightningは自動的にTiKVノードを"normal mode"に切り替えます。グローバルスケジューリングが一時停止されている場合、 TiDB Lightningはグローバルスケジューリングも回復します。その後、TiDBクラスタは通常通りサービスを提供できるようになります。 ## 要件と制限 {#requirements-and-restrictions} diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md index e512b7ef851bb..42fa6b2a586d7 100644 --- a/tidb-lightning/troubleshoot-tidb-lightning.md +++ b/tidb-lightning/troubleshoot-tidb-lightning.md @@ -27,7 +27,7 @@ TiDB Lightning が遅くなる理由はいくつかあります。 TiDB Lightningは、データソースを256MB程度の複数のファイルに分割し、並列処理することで最適に動作します。各ファイルのサイズが大きすぎると、 TiDB Lightningが応答しない場合があります。 -データソースが CSV であり、すべての CSV ファイルに改行制御文字 (U+000A および U+000D) を含むフィールドがない場合は、「厳密な形式」をオンにして、 TiDB Lightning が大きなファイルを自動的に分割するようにすることができます。 +データソースが CSV であり、すべての CSV ファイルに改行制御文字 (U+000A および U+000D) を含むフィールドがない場合は、"strict format"をオンにして、 TiDB Lightning が大きなファイルを自動的に分割するようにすることができます。 ```toml [mydumper] @@ -48,17 +48,17 @@ strict-format = true コマンドラインで直接`nohup`を使用して`tidb-lightning`を起動することは推奨されません。スクリプトを実行することで[`tidb-lightning`を起動する](/get-started-with-tidb-lightning.md#step-4-start-tidb-lightning)ことができます。 -また、 TiDB Lightningの最後のログに「Context cancellation」というエラーが表示されている場合は、最初の「ERROR」レベルのログを探す必要があります。この「ERROR」レベルのログには通常、「got signal to exit」が続きます。これは、 TiDB Lightningが割り込み信号を受信して終了したことを示しています。 +また、 TiDB Lightningの最後のログに"Context canceled"というエラーが表示されている場合は、最初の"ERROR"レベルのログを探す必要があります。この"ERROR"レベルのログには通常、"got signal to exit"が続きます。これは、 TiDB Lightningが割り込み信号を受信して終了したことを示しています。 ## TiDB クラスターは多くの CPU リソースを消費し、 TiDB Lightningを使用すると非常に遅くなります。 {#the-tidb-cluster-uses-lots-of-cpu-resources-and-runs-very-slowly-after-using-tidb-lightning} -`tidb-lightning`異常終了した場合、クラスターは本番には適さない「インポートモード」で停止している可能性があります。現在のモードは次のコマンドで取得できます。 +`tidb-lightning`異常終了した場合、クラスターは本番には適さない"import mode"で停止している可能性があります。現在のモードは次のコマンドで取得できます。 ```sh tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode ``` -次のコマンドを使用して、クラスターを強制的に「通常モード」に戻すことができます。 +次のコマンドを使用して、クラスターを強制的に"normal mode"に戻すことができます。 ```sh tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index 591710efd2e5a..7c2c44d10e268 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -9,7 +9,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 > > この機能は、[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)クラスターでは利用できません。 -ランナウェイクエリとは、予想よりも多くの時間やリソースを消費するクエリです。以下では、ランナウェイクエリを管理する機能を説明するために「ランナ**ウェイクエリ」という**用語を使用します。 +ランナウェイクエリとは、予想よりも多くの時間やリソースを消費するクエリです。以下では、ランナウェイクエリを管理する機能を説明するために**ランナウェイクエリ**という用語を使用します。 - バージョン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)を実行することで、リソースグループ内のランナウェイクエリウォッチリストを手動で管理できます。 diff --git a/tidb-scheduling.md b/tidb-scheduling.md index 9c65bd62ebb72..44155d282cacc 100644 --- a/tidb-scheduling.md +++ b/tidb-scheduling.md @@ -80,9 +80,9 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン PD制御を使用して、TiKVストアのステータス（稼働中、切断、オフライン、ダウン、または廃棄）を確認できます。以下は、すべてのステータスとその関係についての説明です。 - **Up** : TiKVストアが稼働中です。 - - **切断**：PDとTiKVストア間のハートビートメッセージが20秒以上失われます。失われた期間が`max-store-down-time`で指定された時間を超えると、「切断」ステータスが「ダウン」に変わります。 + - **切断**：PDとTiKVストア間のハートビートメッセージが20秒以上失われます。失われた期間が`max-store-down-time`で指定された時間を超えると、"Disconnect"ステータスが"Down"に変わります。 - **ダウン**：PDとTiKVストア間のハートビートメッセージが`max-store-down-time` （デフォルトでは30分）以上途絶えています。この状態になると、TiKVストアは各リージョンのレプリカを残存ストアに補充し始めます。 - - **オフライン**: TiKV ストアは、 PD Controlによって手動でオフラインになっています。これは、ストアがオフラインになるまでの中間ステータスです。このステータスのストアは、すべてのリージョンを、再配置条件を満たす他の「稼働中」ストアに移動します。 `leader_count`と`region_count` ( PD Controlから取得) の両方が`0`を示している場合、ストアのステータスは「オフライン」から「廃棄」に変わります。「オフライン」ステータスでは、ストア サービスまたはストアが配置されている物理サーバーを無効に**しないでください**。ストアがオフラインになるプロセス中に、クラスターにリージョンを再配置するターゲット ストアがない場合 (クラスター内にレプリカを保持するのに十分なストアがない場合など)、ストアは常に「オフライン」ステータスになります。 + - **オフライン**: TiKV ストアは、 PD Controlによって手動でオフラインになっています。これは、ストアがオフラインになるまでの中間ステータスです。このステータスのストアは、すべてのリージョンを、再配置条件を満たす他の"Up"ストアに移動します。 `leader_count`と`region_count` ( PD Controlから取得) の両方が`0`を示している場合、ストアのステータスは"Offline"から"Tombstone"に変わります。"Offline"ステータスでは、ストア サービスまたはストアが配置されている物理サーバーを無効に**しないでください**。ストアがオフラインになるプロセス中に、クラスターにリージョンを再配置するターゲット ストアがない場合 (クラスター内にレプリカを保持するのに十分なストアがない場合など)、ストアは常に"Offline"ステータスになります。 - **tombstone**：TiKVストアは完全にオフラインです。この状態では、 `remove-tombstone`インターフェースを使用してTiKVを安全にクリーンアップできます。v6.5.0以降、手動で処理しない限り、ノードがtombstoneに変換されてから1か月後にPDは内部的に保存されたtombstoneレコードを自動的に削除します。 ![TiKV store status relationship](/media/tikv-store-status-relationship.png) diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index 289e346798202..af316dff6e5aa 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -109,7 +109,7 @@ summary: TiDBでよく発生するエラーのトラブルシューティング - `dmesg -T | grep tidb-server`を実行してください。結果として、エラーが発生した時点付近の OOM-killer ログが表示されます。 - - エラーが発生した時点（つまり、tidb-serverが再起動した時点）の前後の`tidb.log`にある「Welcome to TiDB」ログをgrepします。 + - エラーが発生した時点（つまり、tidb-serverが再起動した時点）の前後の`tidb.log`にある"Welcome to TiDB"ログをgrepします。 - `fatal error: runtime: out of memory`または`cannot allocate memory` `tidb_stderr.log`内で検索します。 @@ -119,7 +119,7 @@ summary: TiDBでよく発生するエラーのトラブルシューティング - 3.2.2 OOMを引き起こすSQL文を特定します。（現在、TiDBのすべてのバージョンではSQL文を正確に特定できません。SQL文を特定した後、OOMがそのSQL文によって引き起こされているかどうかを分析する必要があります。） - - バージョン3.0.0以降の場合、 `tidb.log`内の「expensive_query」をgrepしてください。このログメッセージには、タイムアウトした、またはメモリ割り当て量を超過したSQLクエリが記録されています。 + - バージョン3.0.0以降の場合、 `tidb.log`内の"expensive_query"をgrepしてください。このログメッセージには、タイムアウトした、またはメモリ割り当て量を超過したSQLクエリが記録されています。 - バージョンが v3.0.0 未満の場合、 `tidb.log`で "メモリ exceeded quota" を grep して、メモリクォータを超える SQL クエリを特定します。 @@ -466,7 +466,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 原因3：データソースがマシンによって生成され、 [Dumpling](/dumpling-overview.md)によってバックアップされていない場合は、テーブルの制約を遵守していることを確認してください。例： - - `AUTO_INCREMENT`列は正の値である必要があり、「0」という値を含んではいけません。 + - `AUTO_INCREMENT`列は正の値である必要があり、"0"という値を含んではいけません。 - UNIQUEキーとPRIMARYキーには重複するエントリがあってはなりません。 - 解決策: [トラブルシューティングソリューション](/tidb-lightning/troubleshoot-tidb-lightning.md#checksum-failed-checksum-mismatched-remote-vs-local)を参照してください。 diff --git a/tiflash/tiflash-mintso-scheduler.md b/tiflash/tiflash-mintso-scheduler.md index 01710ad73c9f0..88a6c89f93135 100644 --- a/tiflash/tiflash-mintso-scheduler.md +++ b/tiflash/tiflash-mintso-scheduler.md @@ -55,7 +55,7 @@ EXPLAIN SELECT count(*) FROM t0 a JOIN t0 b ON a.id = b.id; ソフトリミットとハードリミットは、デッドロックを回避するために次のように連携して機能します。ソフトリミットは、すべてのクエリで使用されるスレッドの総数を制限し、スレッドリソースの枯渇を回避しながらリソースを最大限に活用できるようにします。ハードリミットは、いかなる状況においても、システム内の少なくとも1つのクエリがソフトリミットを破り、スレッドリソースを取得して実行を継続できるようにすることで、デッドロックを回避します。スレッド数がハードリミットを超えない限り、システム内には常に1つのクエリが存在し、そのクエリのすべてのMPPタスクが正常に実行され、デッドロックを回避します。 -MinTSOスケジューラの目的は、システムスレッドの数を制御しながら、システム内に常に1つの特別なクエリが存在し、そのクエリですべてのMPPタスクをスケジュールできるようにすることです。MinTSOスケジューラは完全に分散されたスケジューラであり、各TiFlashノードは自身の情報のみに基づいてMPPタスクをスケジュールします。したがって、 TiFlashノード上のすべてのMinTSOスケジューラは同じ「特別な」クエリを識別する必要があります。TiDBでは、各クエリは読み取りタイムスタンプ（ `start_ts` ）を持ち、MinTSOスケジューラは現在のTiFlashノード上で最も小さい`start_ts`を持つクエリを「特別な」クエリとして定義します。グローバル最小値はローカル最小値でもあるという原則に基づき、すべてのTiFlashノードによって選択される「特別な」クエリは、MinTSOクエリと呼ばれる同じである必要があります。 +MinTSOスケジューラの目的は、システムスレッドの数を制御しながら、システム内に常に1つの特別なクエリが存在し、そのクエリですべてのMPPタスクをスケジュールできるようにすることです。MinTSOスケジューラは完全に分散されたスケジューラであり、各TiFlashノードは自身の情報のみに基づいてMPPタスクをスケジュールします。したがって、 TiFlashノード上のすべてのMinTSOスケジューラは同じ"special"クエリを識別する必要があります。TiDBでは、各クエリは読み取りタイムスタンプ（ `start_ts` ）を持ち、MinTSOスケジューラは現在のTiFlashノード上で最も小さい`start_ts`を持つクエリを"special"クエリとして定義します。グローバル最小値はローカル最小値でもあるという原則に基づき、すべてのTiFlashノードによって選択される"special"クエリは、MinTSOクエリと呼ばれる同じである必要があります。 MinTSO スケジューラのスケジューリング プロセスは次のとおりです。 diff --git a/tiflash/use-tidb-to-read-tiflash.md b/tiflash/use-tidb-to-read-tiflash.md index 0c9d45805146b..2a20193d0a3b7 100644 --- a/tiflash/use-tidb-to-read-tiflash.md +++ b/tiflash/use-tidb-to-read-tiflash.md @@ -48,7 +48,7 @@ explain analyze select count(*) from test.t; ## エンジン分離 {#engine-isolation} -エンジン分離とは、対応する変数を設定することで、すべてのクエリが指定されたエンジンのレプリカを使用するように指定することです。オプションのエンジンは、「tikv」、「tidb」（TiDBの内部メモリテーブル領域を示し、一部のTiDBシステムテーブルが格納されており、ユーザーが積極的に使用することはできません）、および「tiflash」です。 +エンジン分離とは、対応する変数を設定することで、すべてのクエリが指定されたエンジンのレプリカを使用するように指定することです。オプションのエンジンは、"tikv"、"tidb"（TiDBの内部メモリテーブル領域を示し、一部のTiDBシステムテーブルが格納されており、ユーザーが積極的に使用することはできません）、および"tiflash"です。 @@ -77,11 +77,11 @@ explain analyze select count(*) from test.t; SESSION レベルのデフォルト構成は、TiDB INSTANCE レベルの構成を継承します。 -最終的なエンジン構成はセッションレベルの構成です。つまり、セッションレベルの構成はインスタンスレベルの構成をオーバーライドします。例えば、インスタンスレベルで「tikv」を設定し、セッションレベルで「tiflash」を設定した場合、 TiFlashレプリカが読み込まれます。最終的なエンジン構成が「tikv」と「tiflash」の場合、TiKVレプリカとTiFlashレプリカの両方が読み込まれ、オプティマイザはより適切なエンジンを自動的に選択して実行します。 +最終的なエンジン構成はセッションレベルの構成です。つまり、セッションレベルの構成はインスタンスレベルの構成をオーバーライドします。例えば、インスタンスレベルで"tikv"を設定し、セッションレベルで"tiflash"を設定した場合、 TiFlashレプリカが読み込まれます。最終的なエンジン構成が"tikv"と"tiflash"の場合、TiKVレプリカとTiFlashレプリカの両方が読み込まれ、オプティマイザはより適切なエンジンを自動的に選択して実行します。 > **Note:** > -> [TiDB Dashboard](/dashboard/dashboard-intro.md)およびその他のコンポーネントは、TiDBメモリテーブル領域に格納されている一部のシステムテーブルを読み取る必要があるため、インスタンスレベルのエンジン構成に常に「tidb」エンジンを追加することをお勧めします。 +> [TiDB Dashboard](/dashboard/dashboard-intro.md)およびその他のコンポーネントは、TiDBメモリテーブル領域に格納されている一部のシステムテーブルを読み取る必要があるため、インスタンスレベルのエンジン構成に常に"tidb"エンジンを追加することをお勧めします。 @@ -101,7 +101,7 @@ set SESSION tidb_isolation_read_engines = "engine list separated by commas"; -クエリされたテーブルに指定されたエンジンのレプリカがない場合 (たとえば、エンジンが「tiflash」として設定されているが、テーブルにTiFlashレプリカがない場合)、クエリはエラーを返します。 +クエリされたテーブルに指定されたエンジンのレプリカがない場合 (たとえば、エンジンが"tiflash"として設定されているが、テーブルにTiFlashレプリカがない場合)、クエリはエラーを返します。 ## 手動ヒント {#manual-hint} diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index a50204d97ce8e..f3f534df4afc8 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -30,7 +30,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 - スローログを保存するファイル - この設定項目が設定されていないが、 `log.file.filename`が設定されている場合、スローログは`log.file.filename`で指定されたログファイルに出力されます。 -- `slow-log-file`も`log.file.filename`も設定されていない場合、デフォルトではすべてのログが「stderr」に出力されます。 +- `slow-log-file`も`log.file.filename`も設定されていない場合、デフォルトではすべてのログが"stderr"に出力されます。 - 両方の設定項目が設定されている場合、通常のログは`log.file.filename`で指定されたログファイルに出力され、スローログは`slow-log-file`で設定されたログファイルに出力されます。 - デフォルト値: `""` @@ -80,7 +80,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ### `filename` v5.4.0 で追加 {#filename-new-in-v540} -- ログファイル。この設定項目が設定されていない場合、ログはデフォルトで「stderr」に出力されます。この設定項目が設定されている場合、ログは対応するファイルに出力されます。 +- ログファイル。この設定項目が設定されていない場合、ログはデフォルトで"stderr"に出力されます。この設定項目が設定されている場合、ログは対応するファイルに出力されます。 - デフォルト値: `""` ### `max-size` v5.4.0の新機能 {#max-size-new-in-v540} @@ -243,7 +243,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ### `end-point-memory-quota` v8.2.0 の新機能 {#end-point-memory-quota-new-in-v820} -- TiKVコプロセッサーのリクエストが使用できるメモリの最大容量。この制限を超えると、以降のコプロセッサーのリクエストは「サーバーがビジー状態です」というエラーで拒否されます。 +- TiKVコプロセッサーのリクエストが使用できるメモリの最大容量。この制限を超えると、以降のコプロセッサーのリクエストは"server is busy."というエラーで拒否されます。 - デフォルト値：システムメモリ全体の12.5%と500MiBのうち大きい方の値。 ### `snap-io-max-bytes-per-sec` {#snap-io-max-bytes-per-sec} @@ -531,7 +531,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 > - `enable-ttl`を`true`または`false`に設定してください。**既存**の TiKV クラスターでは、この設定項目の値を変更**しないでください**。 `enable-ttl`値が異なる TiKV クラスターでは、使用するデータ形式が異なります。そのため、既存の TiKV クラスターでこの項目の値を変更すると、クラスターはデータを異なる形式で保存するため、TiKV クラスターを再起動すると「can't enable TTL on a non-ttl」というエラーが発生します。 > - `enable-ttl` TiKV クラスタ**でのみ**使用してください。TiDB ノードを含むクラスタ (つまり、そのようなクラスタでは`enable-ttl`を`true`に設定する) では、 `storage.api-version = 2`が設定されていない限り、この設定項目を**使用しないでください**。そうしないと、データの破損や TiDB クラスタのアップグレード失敗などの重大な問題が発生します。 -- [TTL](/time-to-live.md)は「Time to live」の略です。この項目を有効にすると、TiKVはTTLに達したデータを自動的に削除します。TTLの値を設定するには、クライアント経由でデータを書き込む際のリクエストで指定する必要があります。TTLが指定されていない場合、TiKVは該当するデータを自動的に削除しません。 +- [TTL](/time-to-live.md)は"Time to live"の略です。この項目を有効にすると、TiKVはTTLに達したデータを自動的に削除します。TTLの値を設定するには、クライアント経由でデータを書き込む際のリクエストで指定する必要があります。TTLが指定されていない場合、TiKVは該当するデータを自動的に削除しません。 - デフォルト値: `false` ### `ttl-check-poll-interval` {#ttl-check-poll-interval} @@ -2267,7 +2267,7 @@ Raft Engineに関連するコンフィグレーション項目。 - データファイルの暗号化方法 - 値のオプション: "plaintext", "aes128-ctr", "aes192-ctr", "aes256-ctr", "sm4-ctr" (v6.3.0以降でサポート) -- 「plaintext」以外の値を指定すると、暗号化が有効になり、マスターキーを指定する必要があります。 +- "plaintext"以外の値を指定すると、暗号化が有効になり、マスターキーを指定する必要があります。 - デフォルト値: `"plaintext"` ### `data-key-rotation-period` {#data-key-rotation-period} diff --git a/tikv-control.md b/tikv-control.md index 9ca1104a1b026..5fd13007a2e5c 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -507,7 +507,7 @@ TiKVを再起動すると、リージョンは残りの正常なレプリカを ### MVCCデータ破損からの回復 {#recover-from-mvcc-data-corruption} -MVCCデータ破損によりTiKVが正常に動作しない場合は、コマンド`recover-mvcc`を使用してください。このコマンドは、3つのCF（「default」、「write」、「lock」）をクロスチェックし、様々な不整合を回復します。 +MVCCデータ破損によりTiKVが正常に動作しない場合は、コマンド`recover-mvcc`を使用してください。このコマンドは、3つのCF（"default"、"write"、"lock"）をクロスチェックし、様々な不整合を回復します。 - `-r`オプションを使用して、関係するリージョンを`region_id`で指定します。 - PD エンドポイントを指定するには、 `-p`オプションを使用します。 @@ -584,7 +584,7 @@ region = "us-west-2" `--ids`オプションを使用すると、出力するデータ暗号化キーのIDをカンマ区切りのリストで指定できます。`--ids`を指定しない場合は、すべてのデータ暗号化キーと、最新のアクティブなデータ暗号化キーのIDである現在のキーIDが出力されます。 -このコマンドを使用すると、機密情報が公開される可能性があることを警告するメッセージが表示されます。続行するには「同意します」と入力してください。 +このコマンドを使用すると、機密情報が公開される可能性があることを警告するメッセージが表示されます。続行するには"I consent"と入力してください。 ```shell tikv-ctl --config=./conf.toml encryption-meta dump-key diff --git a/tikv-overview.md b/tikv-overview.md index c18ce5ef52d1e..d7f4650e06513 100644 --- a/tikv-overview.md +++ b/tikv-overview.md @@ -25,7 +25,7 @@ TiKVは、クラスター内の各リージョンの適切なサイズを維持 PD がレプリカをある TiKV ノードから別の TiKV ノードに移動する場合、まずターゲットノードにLearnerレプリカを追加し、 LearnerレプリカのデータがLeaderレプリカのデータとほぼ同じになったら、PD はそれをFollowerレプリカに変更し、ソース ノードのFollowerレプリカを削除します。 -Leaderレプリカをあるノードから別のノードに移動させる場合も同様のメカニズムが採用されます。違いは、LearnerレプリカがFollowerレプリカになった後、「Leader移行」処理が実行され、Followerレプリカが自らをLeaderに選出するための選挙を積極的に提案することです。最終的に、新しいLeaderはソースノードから古いLeaderレプリカを削除します。 +Leaderレプリカをあるノードから別のノードに移動させる場合も同様のメカニズムが採用されます。違いは、LearnerレプリカがFollowerレプリカになった後、"Leader Transfer"処理が実行され、Followerレプリカが自らをLeaderに選出するための選挙を積極的に提案することです。最終的に、新しいLeaderはソースノードから古いLeaderレプリカを削除します。 ## 分散トランザクション {#distributed-transaction} diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index af960b002ff91..cff97b2051558 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -58,7 +58,7 @@ SQL ポートのコンフィグレーション。 - デフォルト値: `0` - ホットリロードのサポート: はい - 単位: 秒 -- TiProxyがシャットダウンすると、HTTPステータスは「unhealthy」を返しますが、SQLポートは`graceful-wait-before-shutdown`秒間は新規接続を受け付けます。その後、新規接続は拒否され、クライアントの負荷が増大します。クライアントとTiProxyの間に他のプロキシ（NLBなど）が存在しない場合は、この値を`0`に設定することをお勧めします。 +- TiProxyがシャットダウンすると、HTTPステータスは"unhealthy"を返しますが、SQLポートは`graceful-wait-before-shutdown`秒間は新規接続を受け付けます。その後、新規接続は拒否され、クライアントの負荷が増大します。クライアントとTiProxyの間に他のプロキシ（NLBなど）が存在しない場合は、この値を`0`に設定することをお勧めします。 #### `graceful-close-conn-timeout` {#graceful-close-conn-timeout} diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index 71fb6e1cfc432..77f8cbd88fbbb 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -74,15 +74,15 @@ TiUPを使用した TiDB デプロイメントのトポロジ構成ファイル - `log_dir`相対パスの場合、コンポーネントログは`/`に配置されます。 ``の計算規則については、 `deploy_dir`フィールドの適用規則を参照してください。 -- `os` : ターゲットマシンのオペレーティングシステム。このフィールドは、ターゲットマシンにプッシュされるコンポーネントをどのオペレーティングシステムに適応させるかを制御します。デフォルト値は「linux」です。 +- `os` : ターゲットマシンのオペレーティングシステム。このフィールドは、ターゲットマシンにプッシュされるコンポーネントをどのオペレーティングシステムに適応させるかを制御します。デフォルト値は"linux"です。 -- `arch` : ターゲットマシンのCPUアーキテクチャ。このフィールドは、ターゲットマシンにプッシュされるバイナリパッケージをどのプラットフォームに適合させるかを制御します。サポートされている値は「amd64」と「arm64」です。デフォルト値は「amd64」です。 +- `arch` : ターゲットマシンのCPUアーキテクチャ。このフィールドは、ターゲットマシンにプッシュされるバイナリパッケージをどのプラットフォームに適合させるかを制御します。サポートされている値は"amd64"と"arm64"です。デフォルト値は"amd64"です。 -- `pd_mode` : PD動作モード。このフィールドは、 [PDマイクロサービス](/pd-microservices.md)を有効にするかどうかを制御します。サポートされる値は「ms」です。このフィールドを指定すると、PDマイクロサービスが有効になります。 +- `pd_mode` : PD動作モード。このフィールドは、 [PDマイクロサービス](/pd-microservices.md)を有効にするかどうかを制御します。サポートされる値は"ms"です。このフィールドを指定すると、PDマイクロサービスが有効になります。 - `resource_control` : ランタイムリソース制御。このフィールドのすべての設定は、systemd のサービスファイルに書き込まれます。デフォルトでは制限はありません。制御可能なリソースは以下のとおりです。 - - `memory_limit` : 最大ランタイムメモリを制限します。たとえば、「2G」は最大2GBのメモリが使用できることを意味します。 + - `memory_limit` : 最大ランタイムメモリを制限します。たとえば、"2G"は最大2GBのメモリが使用できることを意味します。 - `cpu_quota` : 実行時のCPU使用率の上限を制限します。例：200% diff --git a/tiup/tiup-command-clean.md b/tiup/tiup-command-clean.md index a0ed808b0effb..83a9bab246647 100644 --- a/tiup/tiup-command-clean.md +++ b/tiup/tiup-command-clean.md @@ -1,6 +1,6 @@ --- title: tiup clean -summary: 「tiup clean」コマンドは、コンポーネント操作中に生成されたデータを消去します。構文は「tiup clean [name] [flags]」で、すべての操作記録を消去するには「--all」オプションを使用します。 +summary: "tiup clean"コマンドは、コンポーネント操作中に生成されたデータを消去します。構文は"tiup clean [name] [flags]"で、すべての操作記録を消去するには"--all"オプションを使用します。 --- # tiup clean {#tiup-clean} diff --git a/tiup/tiup-command-env.md b/tiup/tiup-command-env.md index aabd19e6d7c68..77602b2d5d057 100644 --- a/tiup/tiup-command-env.md +++ b/tiup/tiup-command-env.md @@ -1,6 +1,6 @@ --- title: tiup env -summary: TiUPは、環境変数を用いた柔軟でカスタマイズされたインターフェースを提供します。tiup env`コマンドは、ユーザー定義の環境変数とその値を照会します。`tiup env [name1...N]`を使用すると、指定した変数、またはデフォルトですべての変数が表示されます。オプションはありません。出力は、指定がない場合は「{key}」="{value}"のリスト、指定されている場合は「{value}」のリストが順番に出力されます。値が空の場合、 TiUPはデフォルトを使用します。 +summary: TiUPは、環境変数を用いた柔軟でカスタマイズされたインターフェースを提供します。tiup env`コマンドは、ユーザー定義の環境変数とその値を照会します。`tiup env [name1...N]`を使用すると、指定した変数、またはデフォルトですべての変数が表示されます。オプションはありません。出力は、指定がない場合は"{key}"="{value}"のリスト、指定されている場合は"{value}"のリストが順番に出力されます。値が空の場合、 TiUPはデフォルトを使用します。 --- # tiup env {#tiup-env} @@ -21,8 +21,8 @@ tiup env [name1...N] ## 出力 {#output} -- `[name1...N]`を指定しない場合は「{key}」="{value}"のリストが出力されます。 -- `[name1...N]`を指定した場合は、「{value}」リストが順に出力されます。 +- `[name1...N]`を指定しない場合は"{key}"="{value}"のリストが出力されます。 +- `[name1...N]`を指定した場合は、"{value}"リストが順に出力されます。 上記の出力で、 `value`が空の場合、環境変数の値が設定されていないことを意味します。この場合、 TiUP はデフォルト値を使用します。 diff --git a/tiup/tiup-command-mirror-genkey.md b/tiup/tiup-command-mirror-genkey.md index d3bc2d3b9c885..10a6ee1fcbb6c 100644 --- a/tiup/tiup-command-mirror-genkey.md +++ b/tiup/tiup-command-mirror-genkey.md @@ -29,7 +29,7 @@ tiup mirror genkey [flags] - キーの名前を指定します。この名前は、最終的に生成されるファイルの名前も決定します。生成される秘密鍵ファイルのパスは`${TIUP_HOME}/keys/{name}.json`です。 `TIUP_HOME`は TiUPのホームディレクトリ（デフォルトでは`$HOME/.tiup`を指します。 `name`は `-n/--name`で指定される秘密鍵の名前を指します。 - データ型: `STRING` -- デフォルト:「private」 +- デフォルト:"private" ### -p, --public {#p-public} diff --git a/tiup/tiup-command-mirror-merge.md b/tiup/tiup-command-mirror-merge.md index 2031f0d512a4c..22ea39ac0269b 100644 --- a/tiup/tiup-command-mirror-merge.md +++ b/tiup/tiup-command-mirror-merge.md @@ -1,6 +1,6 @@ --- title: tiup mirror merge -summary: 「tiup mirror merge」コマンドは、1つまたは複数のミラーを現在のミラーにマージします。実行条件には、既存の所有者IDと対応する秘密鍵が含まれます。 +summary: "tiup mirror merge"コマンドは、1つまたは複数のミラーを現在のミラーにマージします。実行条件には、既存の所有者IDと対応する秘密鍵が含まれます。 --- # tiup mirror merge {#tiup-mirror-merge} diff --git a/tiup/tiup-command-mirror.md b/tiup/tiup-command-mirror.md index 92ab0b4073930..ad196ab0ae652 100644 --- a/tiup/tiup-command-mirror.md +++ b/tiup/tiup-command-mirror.md @@ -1,6 +1,6 @@ --- title: tiup mirror -summary: TiUPミラーはTiUPの重要な概念であり、ローカルおよびリモートミラーリングをサポートします。「tiup mirror」コマンドは、ミラーの管理、コンポーネントの作成、配布、キーの管理を行います。構文は「tiup mirror <コマンド> [フラグ]」です。サポートされているサブコマンドには、genkey、sign、init、set、grant、publish、modify、rotate、clone、mergeなどがあります。 +summary: TiUPミラーはTiUPの重要な概念であり、ローカルおよびリモートミラーリングをサポートします。'tiup mirror'コマンドは、ミラーの管理、コンポーネントの作成、配布、キーの管理を行います。構文は'tiup mirror [flags]'です。サポートされているサブコマンドには、genkey、sign、init、set、grant、publish、modify、rotate、clone、mergeなどがあります。 --- # tiup mirror {#tiup-mirror} diff --git a/tiup/tiup-command-status.md b/tiup/tiup-command-status.md index 0a612d0699b5b..241e21be8fac7 100644 --- a/tiup/tiup-command-status.md +++ b/tiup/tiup-command-status.md @@ -1,6 +1,6 @@ --- title: tiup status -summary: 「tiup status」コマンドは、「tiup <コンポーネント>」コマンドでコンポーネントを実行した後、そのコンポーネントの動作情報を確認するために使用します。このコマンドは、動作中のコンポーネントの名前、コンポーネント名、PID、ステータス、作成時刻、ディレクトリ、バイナリ、引数を表示します。コンポーネントのステータスは、「Up」、「Down」、「Tombstone」、「Pending Offline」、「Unknown」のいずれかになります。ステータスはPDのスケジュール情報から取得されます。 +summary: "tiup status"コマンドは、"tiup "コマンドでコンポーネントを実行した後、そのコンポーネントの動作情報を確認するために使用します。このコマンドは、動作中のコンポーネントの名前、コンポーネント名、PID、ステータス、作成時刻、ディレクトリ、バイナリ、引数を表示します。コンポーネントのステータスは、Up、Down、Tombstone、Pending Offline、Unknownのいずれかになります。ステータスはPDのスケジュール情報から取得されます。 --- # tiup status {#tiup-status} diff --git a/tiup/tiup-command-telemetry.md b/tiup/tiup-command-telemetry.md index 961a2206e22c5..55bc0f2276146 100644 --- a/tiup/tiup-command-telemetry.md +++ b/tiup/tiup-command-telemetry.md @@ -1,6 +1,6 @@ --- title: tiup telemetry -summary: TiUPテレメトリはv1.11.3でデフォルトで無効化されました。使用状況情報は収集されず、PingCAPと共有もされません。有効化すると、テレメトリ識別子とコマンド実行ステータスが共有されます。クラスタの詳細は共有されません。「tiup telemetry」コマンドを使用し、status、reset、enable、disableなどのサブコマンドでテレメトリを制御してください。 +summary: TiUPテレメトリはv1.11.3でデフォルトで無効化されました。使用状況情報は収集されず、PingCAPと共有もされません。有効化すると、テレメトリ識別子とコマンド実行ステータスが共有されます。クラスタの詳細は共有されません。"tiup telemetry"コマンドを使用し、status、reset、enable、disableなどのサブコマンドでテレメトリを制御してください。 --- # tiup telemetry {#tiup-telemetry} diff --git a/tiup/tiup-component-cluster-check.md b/tiup/tiup-component-cluster-check.md index c9896ccf829de..5c5d0a4fb9a8a 100644 --- a/tiup/tiup-component-cluster-check.md +++ b/tiup/tiup-component-cluster-check.md @@ -1,6 +1,6 @@ --- title: tiup cluster check -summary: TiUP クラスタは、ハードウェアとソフトウェア環境が本番の要件を満たしていることを確認するための「check」コマンドを提供します。OSバージョン、CPUサポート、時刻同期、システム制限などをチェックします。オプションには、自動修復や、CPUコア数、メモリサイズ、ディスクパフォーマンスのチェックの有効化などがあります。チェックを実行するには、「tiup cluster check [flags]」コマンドを使用します。自動修復を試行するには、「--apply」を使用します。チェックするノードとロールを指定するには、「-N, --node」および「-R, --role」を使用します。特定のチェックを有効にするには、「--enable-cpu」、「--enable-disk」、「--enable-mem」を使用します。 +summary: TiUP クラスタは、ハードウェアとソフトウェア環境が本番の要件を満たしていることを確認するための`check`コマンドを提供します。OSバージョン、CPUサポート、時刻同期、システム制限などをチェックします。オプションには、自動修復や、CPUコア数、メモリサイズ、ディスクパフォーマンスのチェックの有効化などがあります。チェックを実行するには、`tiup cluster check [flags]`コマンドを使用します。自動修復を試行するには、`--apply`を使用します。チェックするノードとロールを指定するには、`-N, --node`および`-R, --role`を使用します。特定のチェックを有効にするには、`--enable-cpu`、`--enable-disk`、`--enable-mem`を使用します。 --- # tiup cluster check {#tiup-cluster-check} diff --git a/tiup/tiup-component-cluster-display.md b/tiup/tiup-component-cluster-display.md index 3713ea33aeaea..2a5511849e1c1 100644 --- a/tiup/tiup-component-cluster-display.md +++ b/tiup/tiup-component-cluster-display.md @@ -1,6 +1,6 @@ --- title: tiup cluster display -summary: tiup cluster displayコマンドは、クラスタ内の各コンポーネントの動作状況を効率的に表示します。ダッシュボード情報、ノードステータス、CPUおよびメモリ使用率などを表示するオプションが用意されています。出力には、クラスタ名、バージョン、SSHクライアントの種類、ダッシュボードアドレス、ノードの詳細を含む表が含まれます。ノードのサービスステータスは、「稼働中」、「停止中」、「廃棄済み」、「オフライン保留中」、「不明」のいずれかになります。 +summary: tiup cluster displayコマンドは、クラスタ内の各コンポーネントの動作状況を効率的に表示します。ダッシュボード情報、ノードステータス、CPUおよびメモリ使用率などを表示するオプションが用意されています。出力には、クラスタ名、バージョン、SSHクライアントの種類、ダッシュボードアドレス、ノードの詳細を含む表が含まれます。ノードのサービスステータスは、"Up"、"Down"、"Tombstone"、"Pending Offline"、"Unknown"のいずれかになります。 --- # tiup cluster display {#tiup-cluster-display} diff --git a/tiup/tiup-component-cluster-import.md b/tiup/tiup-component-cluster-import.md index 2df7b7e681f2b..03240ce101e52 100644 --- a/tiup/tiup-component-cluster-import.md +++ b/tiup/tiup-component-cluster-import.md @@ -1,6 +1,6 @@ --- title: tiup cluster import -summary: TiUP クラスタは、TiDB AnsibleからTiUPにTiDBクラスターを転送して管理するための「import」コマンドを提供しています。特定の構成のクラスターでは「import」を使用しないでください。インポートプロセスをカスタマイズするには、「--dir」や「--rename」などのオプションを使用してください。 +summary: TiUP クラスタは、TiDB AnsibleからTiUPにTiDBクラスターを転送して管理するための`import`コマンドを提供しています。特定の構成のクラスターでは`import`を使用しないでください。インポートプロセスをカスタマイズするには、`--dir`や`--rename`などのオプションを使用してください。 --- # tiup cluster import {#tiup-cluster-import} diff --git a/tiup/tiup-component-cluster-meta-restore.md b/tiup/tiup-component-cluster-meta-restore.md index adadbccf35785..b13dd72e041a2 100644 --- a/tiup/tiup-component-cluster-meta-restore.md +++ b/tiup/tiup-component-cluster-meta-restore.md @@ -1,6 +1,6 @@ --- title: tiup cluster meta restore -summary: TiUPメタファイルを復元するには、クラスター名とバックアップファイルのパスを指定して「tiup cluster meta restore」コマンドを使用します。復元操作は現在のメタファイルを上書きするため、ファイルが失われた場合にのみ実行してください。「-h」または「--help」オプションを指定するとヘルプ情報が出力。出力には、 tiup-clusterの実行ログが含まれます。 +summary: TiUPメタファイルを復元するには、クラスター名とバックアップファイルのパスを指定して「tiup cluster meta restore」コマンドを使用します。復元操作は現在のメタファイルを上書きするため、ファイルが失われた場合にのみ実行してください。"-h"または"--help"オプションを指定するとヘルプ情報が出力。出力には、 tiup-clusterの実行ログが含まれます。 --- # tiup cluster meta restore {#tiup-cluster-meta-restore} diff --git a/tiup/tiup-component-cluster-prune.md b/tiup/tiup-component-cluster-prune.md index 98960c1ca5fc5..762c995b4de9c 100644 --- a/tiup/tiup-component-cluster-prune.md +++ b/tiup/tiup-component-cluster-prune.md @@ -1,6 +1,6 @@ --- title: tiup cluster prune -summary: クラスターをスケールアウトする際、 TiUP は一部のコンポーネントのサービスを即時に停止したり、データを削除したりしません。データのスケジューリングが完了するまで待ってから、「tiup cluster prune」コマンドを手動で実行してクリーンアップする必要があります。構文は「tiup cluster prune [flags]」です。オプション「-h, --help」を指定するとヘルプ情報が出力、クリーンアッププロセスのログが出力されます。 +summary: クラスターをスケールアウトする際、 TiUP は一部のコンポーネントのサービスを即時に停止したり、データを削除したりしません。データのスケジューリングが完了するまで待ってから、"tiup cluster prune"コマンドを手動で実行してクリーンアップする必要があります。構文は"tiup cluster prune [flags]"です。オプション"-h, --help"を指定するとヘルプ情報が出力、クリーンアッププロセスのログが出力されます。 --- # tiup cluster prune {#tiup-cluster-prune} diff --git a/tiup/tiup-component-cluster-stop.md b/tiup/tiup-component-cluster-stop.md index bd75909659d24..159ae1b79b7a6 100644 --- a/tiup/tiup-component-cluster-stop.md +++ b/tiup/tiup-component-cluster-stop.md @@ -1,6 +1,6 @@ --- title: tiup cluster stop -summary: 「tiup cluster stop」コマンドは、指定されたクラスターのすべてまたは一部のサービスを停止するために使用されます。コアサービスが停止すると、クラスターはサービスを提供できなくなります。コマンド構文は「tiup cluster stop [flags] 」です。オプションには、停止するノードを指定する -N/--node、停止するノードの役割を指定する -R/--role、ヘルプ情報を表示する -h/--help があります。出力は、サービスの停止に関するログです。 +summary: "tiup cluster stop"コマンドは、指定されたクラスターのすべてまたは一部のサービスを停止するために使用されます。コアサービスが停止すると、クラスターはサービスを提供できなくなります。コマンド構文は"tiup cluster stop [flags]"です。オプションには、停止するノードを指定する -N/--node、停止するノードの役割を指定する -R/--role、ヘルプ情報を表示する -h/--help があります。出力は、サービスの停止に関するログです。 --- # tiup cluster stop {#tiup-cluster-stop} diff --git a/tiup/tiup-component-dm-import.md b/tiup/tiup-component-dm-import.md index c130ff1b728f3..4eaedd6dc4c05 100644 --- a/tiup/tiup-component-dm-import.md +++ b/tiup/tiup-component-dm-import.md @@ -1,6 +1,6 @@ --- title: tiup dm import -summary: TiUP DMの「import」コマンドは、DMクラスタをv1.0からv2.0以降のバージョンにアップグレードするために使用されます。このコマンドは、v1.0クラスタからのDMポータルコンポーネントのインポートをサポートしておらず、インポート前に元のクラスタを停止する必要があります。このコマンドはDM v2.0.0-rc.2以降のバージョンへのインポートのみをサポートしており、DM v1.0クラスタを新しいDM v2.0クラスタにインポートするために使用できます。インポート後、クラスタ内のDMマスターノードは1つだけになり、一部のコンポーネントのデプロイメントディレクトリは元のクラスタと異なる場合があります。 +summary: TiUP DMの"import"コマンドは、DMクラスタをv1.0からv2.0以降のバージョンにアップグレードするために使用されます。このコマンドは、v1.0クラスタからのDMポータルコンポーネントのインポートをサポートしておらず、インポート前に元のクラスタを停止する必要があります。このコマンドはDM v2.0.0-rc.2以降のバージョンへのインポートのみをサポートしており、DM v1.0クラスタを新しいDM v2.0クラスタにインポートするために使用できます。インポート後、クラスタ内のDMマスターノードは1つだけになり、一部のコンポーネントのデプロイメントディレクトリは元のクラスタと異なる場合があります。 --- # tiup dm import DM v1.0 のアップグレードのみ {#tiup-dm-import-only-for-upgrading-dm-v10} diff --git a/tiup/tiup-component-dm-list.md b/tiup/tiup-component-dm-list.md index 2deb3d1ac9b62..a1afe432413b0 100644 --- a/tiup/tiup-component-dm-list.md +++ b/tiup/tiup-component-dm-list.md @@ -1,6 +1,6 @@ --- title: tiup dm list -summary: tiup-dm は、同一の制御マシンを用いた複数のクラスタのデプロイをサポートします。「tiup dm list」コマンドは、現在ログインしているユーザーがデプロイしたクラスタを確認します。データは ~/.tiup/ storage/dm/clusters/ ディレクトリに保存されます。ユーザーはクラスタ名、デプロイしたユーザー、バージョン、パス、秘密鍵を確認できます。 +summary: tiup-dm は、同一の制御マシンを用いた複数のクラスタのデプロイをサポートします。"tiup dm list"コマンドは、現在ログインしているユーザーがデプロイしたクラスタを確認します。データは ~/.tiup/ storage/dm/clusters/ ディレクトリに保存されます。ユーザーはクラスタ名、デプロイしたユーザー、バージョン、パス、秘密鍵を確認できます。 --- # tiup dm list {#tiup-dm-list} diff --git a/tiup/tiup-component-dm-prune.md b/tiup/tiup-component-dm-prune.md index 65862f8d03e9c..98f0bc65c6ca4 100644 --- a/tiup/tiup-component-dm-prune.md +++ b/tiup/tiup-component-dm-prune.md @@ -1,6 +1,6 @@ --- title: tiup dm prune -summary: クラスターをスケールさせる際、etcd内の少量のメタデータがクリーンアップされない場合がありますが、通常は問題にはなりません。必要に応じて、「tiup dm prune」コマンドを手動で実行してメタデータをクリーンアップできます。コマンド構文は「tiup dm prune [flags]」です。オプション「-h, --help」を指定するとヘルプ情報が出力、クリーンアッププロセスのログが出力されます。 +summary: クラスターをスケールさせる際、etcd内の少量のメタデータがクリーンアップされない場合がありますが、通常は問題にはなりません。必要に応じて、"tiup dm prune"コマンドを手動で実行してメタデータをクリーンアップできます。コマンド構文は"tiup dm prune [flags]"です。オプション"-h, --help"を指定するとヘルプ情報が出力、クリーンアッププロセスのログが出力されます。 --- # tiup dm prune {#tiup-dm-prune} diff --git a/tiup/tiup-component-dm-reload.md b/tiup/tiup-component-dm-reload.md index 7bf40cd012a54..15393158f1de0 100644 --- a/tiup/tiup-component-dm-reload.md +++ b/tiup/tiup-component-dm-reload.md @@ -1,6 +1,6 @@ --- title: tiup dm reload -summary: 「tiup dm reload」コマンドは、変更されたクラスタ構成を適用し、サービスを再起動するために使用されます。再起動するノードとロールを指定したり、再起動プロセスをスキップしたりできます。また、このコマンドにはヘルプ情報を表示するオプションがあり、tiup-dmの実行ログも出力されます。 +summary: `tiup dm reload`コマンドは、変更されたクラスタ構成を適用し、サービスを再起動するために使用されます。再起動するノードとロールを指定したり、再起動プロセスをスキップしたりできます。また、このコマンドにはヘルプ情報を表示するオプションがあり、tiup-dmの実行ログも出力されます。 --- # tiup dm reload {#tiup-dm-reload} diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 7954bbf29aee6..cdc455556adba 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -25,27 +25,27 @@ TiUPを使用した DM クラスターのデプロイメントのトポロジ構 `global`セクションはクラスターのグローバル構成に対応し、次のフィールドがあります。 -- `user` : デプロイされたクラスタを起動するユーザー。デフォルト値は「tidb」です。``に指定されたユーザーがターゲットマシン上に存在しない場合、 TiUP は自動的にユーザーの作成を試みます。 +- `user` : デプロイされたクラスタを起動するユーザー。デフォルト値は"tidb"です。``に指定されたユーザーがターゲットマシン上に存在しない場合、 TiUP は自動的にユーザーの作成を試みます。 - `group` : ユーザーが自動作成された際に所属するユーザーグループ。デフォルト値は``フィールドと同じです。指定されたグループが存在しない場合は、自動的に作成されます。 -- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポート。デフォルト値は「22」です。 -- `deploy_dir` : 各コンポーネントのデプロイメントディレクトリ。デフォルト値は「deploy」です。構築ルールは以下のとおりです。 +- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポート。デフォルト値は"22"です。 +- `deploy_dir` : 各コンポーネントのデプロイメントディレクトリ。デフォルト値は"deploy"です。構築ルールは以下のとおりです。 - 絶対パス`deploy_dir`インスタンスレベルで構成されている場合、実際のデプロイメントディレクトリはインスタンスに対して構成されている`deploy_dir`なります。 - 各インスタンスに対して`deploy_dir`設定しない場合、デフォルト値は相対パス`-`なります。 - `global.deploy_dir`絶対パスに設定すると、コンポーネントは`/`ディレクトリにデプロイされます。 - `global.deploy_dir`相対パスに設定すると、コンポーネントは`/home///`ディレクトリにデプロイされます。 -- `data_dir` : データディレクトリ。デフォルト値は「data」です。構築ルールは以下のとおりです。 +- `data_dir` : データディレクトリ。デフォルト値は"data"です。構築ルールは以下のとおりです。 - 絶対パス`data_dir`インスタンスレベルで構成されている場合、実際のデータディレクトリはインスタンスに構成されている`data_dir`なります。 - 各インスタンスに対して`data_dir`が設定されていない場合、デフォルト値は``なります。 - `data_dir`相対パスに設定されている場合、コンポーネントデータは`/`に保存されます。 ``の構築規則については、 `deploy_dir`フィールドの構築規則を参照してください。 -- `log_dir` : データディレクトリ。デフォルト値は「log」です。構築ルールは以下のとおりです。 +- `log_dir` : データディレクトリ。デフォルト値は"log"です。構築ルールは以下のとおりです。 - インスタンスレベルで絶対パス`log_dir`が設定されている場合、実際のログディレクトリはインスタンスに設定されている`log_dir`なります。 - 各インスタンスについて、ユーザーが`log_dir`設定しない場合、デフォルト値は``なります。 - `log_dir`が相対パスの場合、コンポーネントログは`/`に保存されます。 ``の構築ルールについては、 `deploy_dir`フィールドの構築ルールを参照してください。 -- `os` : ターゲットマシンのオペレーティングシステム。このフィールドは、ターゲットマシンにプッシュされるコンポーネントをどのオペレーティングシステムに適応させるかを制御します。デフォルト値は「linux」です。 -- `arch` : ターゲットマシンのCPUアーキテクチャ。このフィールドは、ターゲットマシンにプッシュされるバイナリパッケージをどのプラットフォームに適合させるかを制御します。サポートされている値は「amd64」と「arm64」です。デフォルト値は「amd64」です。 +- `os` : ターゲットマシンのオペレーティングシステム。このフィールドは、ターゲットマシンにプッシュされるコンポーネントをどのオペレーティングシステムに適応させるかを制御します。デフォルト値は"linux"です。 +- `arch` : ターゲットマシンのCPUアーキテクチャ。このフィールドは、ターゲットマシンにプッシュされるバイナリパッケージをどのプラットフォームに適合させるかを制御します。サポートされている値は"amd64"と"arm64"です。デフォルト値は"amd64"です。 - `resource_control` : ランタイムリソース制御。このフィールドのすべての設定は、systemd のサービスファイルに書き込まれます。デフォルトでは制限はありません。制御可能なリソースは以下のとおりです。 - - `memory_limit` : 実行時の最大メモリを制限します。例えば、「2G」は最大2GBのメモリが使用できることを意味します。 - - `cpu_quota` : 実行時のCPU使用率の上限を制限します。例: 「200%」 + - `memory_limit` : 実行時の最大メモリを制限します。例えば、"2G"は最大2GBのメモリが使用できることを意味します。 + - `cpu_quota` : 実行時のCPU使用率の上限を制限します。例: "200%" - `io_read_bandwidth_max` : ディスク読み取りの最大I/O帯域幅を制限します。例： `"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M"` 。 - `io_write_bandwidth_max` : ディスク書き込みの最大I/O帯域幅を制限します。例： `"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M"` 。 - `limit_core` : コアダンプのサイズを制御します。 @@ -88,8 +88,8 @@ server_configs: - `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 - `name` : DMマスターインスタンスの名前を指定します。名前はインスタンスごとに一意である必要があります。一意でない場合、クラスターをデプロイできません。 -- `port` : DMマスターがサービスを提供するポートを指定します。デフォルト値は「8261」です。 -- `peer_port` : DMマスター間の通信ポートを指定します。デフォルト値は「8291」です。 +- `port` : DMマスターがサービスを提供するポートを指定します。デフォルト値は"8261"です。 +- `peer_port` : DMマスター間の通信ポートを指定します。デフォルト値は"8291"です。 - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 @@ -145,7 +145,7 @@ master_servers: - `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 - `name` : DMワーカーインスタンスの名前を指定します。名前はインスタンスごとに一意である必要があります。一意でない場合、クラスターをデプロイできません。 -- `port` : DMワーカーがサービスを提供するポートを指定します。デフォルト値は「8262」です。 +- `port` : DMワーカーがサービスを提供するポートを指定します。デフォルト値は"8262"です。 - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 @@ -188,12 +188,12 @@ worker_servers: - `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 -- `port` : Prometheusがサービスを提供するポートを指定します。デフォルト値は「9090」です。 +- `port` : Prometheusがサービスを提供するポートを指定します。デフォルト値は"9090"です。 - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 - `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンに[numactl](https://linux.die.net/man/8/numactl)がインストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)を使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 -- `storage_retention` : Prometheus監視データの保持期間を指定します。デフォルト値は「15日」です。 +- `storage_retention` : Prometheus監視データの保持期間を指定します。デフォルト値は"15d"です。 - `rule_dir` : `*.rules.yml`のファイルすべてが保存されているローカルディレクトリを指定します。指定されたディレクトリ内のファイルは、クラスター構成の初期化フェーズでPrometheusルールとしてターゲットマシンに送信されます。 - `remote_config` : Prometheusデータのリモートへの書き込み、またはリモートからのデータの読み取りをサポートします。このフィールドには2つの設定があります。 - `remote_write` : Prometheus ドキュメント[``](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write)を参照してください。 @@ -246,7 +246,7 @@ monitoring_servers: - `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 -- `port` : Grafanaがサービスを提供するポートを指定します。デフォルト値は「3000」です。 +- `port` : Grafanaがサービスを提供するポートを指定します。デフォルト値は"3000"です。 - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`os`値です。 - `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`arch`値になります。 @@ -284,8 +284,8 @@ grafana_servers: - `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 -- `web_port` : AlertmanagerがWebサービスを提供するポートを指定します。デフォルト値は「9093」です。 -- `cluster_port` : Alertmanager間の通信ポートを指定します。デフォルト値は「9094」です。 +- `web_port` : AlertmanagerがWebサービスを提供するポートを指定します。デフォルト値は"9093"です。 +- `cluster_port` : Alertmanager間の通信ポートを指定します。デフォルト値は"9094"です。 - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 diff --git a/tiup/tiup-mirror.md b/tiup/tiup-mirror.md index 14ee220768bae..6fef5e0bf12eb 100644 --- a/tiup/tiup-mirror.md +++ b/tiup/tiup-mirror.md @@ -60,7 +60,7 @@ tiup mirror clone [global-version] [flags] - クローン作成時にバージョンを一致させるためにプレフィックスマッチングを使用するかどうかを決定します - フラグ`--prefix`が指定された場合、クローンのバージョン番号はプレフィックスによって照合されます。例えば、 `--prefix` 「v5.0.0」と指定した場合、「v5.0.0-rc」と「v5.0.0」が一致します。 + フラグ`--prefix`が指定された場合、クローンのバージョン番号はプレフィックスによって照合されます。例えば、 `--prefix` "v5.0.0"と指定した場合、"v5.0.0-rc"と"v5.0.0"が一致します。 - 完全なクローンを使用するかどうかを決定します diff --git a/tiup/tiup-overview.md b/tiup/tiup-overview.md index 47216508f003e..df1be5704872b 100644 --- a/tiup/tiup-overview.md +++ b/tiup/tiup-overview.md @@ -127,4 +127,4 @@ Use "tiup [command] --help" for more information about a command. TiUPコマンドは TiUP の内部コードに実装され、パッケージ管理操作に使用されますが、 TiUPコンポーネントはTiUPコマンドによってインストールされる独立したコンポーネントパッケージです。 -たとえば、 `tiup list`コマンドを実行すると、 TiUP は独自の内部コードを直接実行します。`tiup playground`コマンドを実行すると、 TiUP は「playground」という名前のローカル パッケージがあるかどうかを確認し、ない場合はミラーからパッケージをダウンロードして実行します。 +たとえば、 `tiup list`コマンドを実行すると、 TiUP は独自の内部コードを直接実行します。`tiup playground`コマンドを実行すると、 TiUP は"playground"という名前のローカル パッケージがあるかどうかを確認し、ない場合はミラーからパッケージをダウンロードして実行します。 diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index b1bba59725f90..b81d3439c45e2 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -223,29 +223,29 @@ TiDB クラスター内の読み取り/書き込み競合は、次の方法で ### KeyIsLockedエラー {#keyislocked-error} -トランザクションのPrewriteフェーズでは、TiDBは書き込み競合の有無を確認し、対象キーが他のトランザクションによってロックされているかどうかを確認します。キーがロックされている場合、TiKVサーバーは「KeyIsLocked」エラーを出力します。現在、このエラーメッセージはTiDBとTiKVのログには出力されません。読み取り競合と同様に、「KeyIsLocked」エラーが発生した場合、TiDBは自動的にトランザクションのバックオフと再試行を実行します。 +トランザクションのPrewriteフェーズでは、TiDBは書き込み競合の有無を確認し、対象キーが他のトランザクションによってロックされているかどうかを確認します。キーがロックされている場合、TiKVサーバーは"KeyIsLocked"エラーを出力します。現在、このエラーメッセージはTiDBとTiKVのログには出力されません。読み取り競合と同様に、"KeyIsLocked"エラーが発生した場合、TiDBは自動的にトランザクションのバックオフと再試行を実行します。 -Grafana の TiDB モニタリングで「KeyIsLocked」エラーがあるかどうかを確認できます。 +Grafana の TiDB モニタリングで"KeyIsLocked"エラーがあるかどうかを確認できます。 -TiDBダッシュボードの`KV Errors`パネルには、トランザクションによって発生した書き込み競合を確認するための2つの監視メトリック`Lock Resolve OPS`と`KV Backoff OPS`あります。`Lock Resolve OPS`の`resolve`の項目と`KV Backoff OPS`の`txnLock`の項目に明らかな上昇傾向が見られる場合、「KeyIsLocked」エラーが発生します。`resolve`はロックを解除しようとする操作を指し、`txnLock`は書き込み競合を表します。 +TiDBダッシュボードの`KV Errors`パネルには、トランザクションによって発生した書き込み競合を確認するための2つの監視メトリック`Lock Resolve OPS`と`KV Backoff OPS`あります。`Lock Resolve OPS`の`resolve`の項目と`KV Backoff OPS`の`txnLock`の項目に明らかな上昇傾向が見られる場合、"KeyIsLocked"エラーが発生します。`resolve`はロックを解除しようとする操作を指し、`txnLock`は書き込み競合を表します。 ![KV-backoff-txnLockFast-optimistic-01](/media/troubleshooting-lock-pic-07.png) ![KV-Errors-resolve-optimistic-01](/media/troubleshooting-lock-pic-08.png) 解決策: - 監視中にtxnLockが少量発生しても、あまり気にする必要はありません。バックオフとリトライはバックグラウンドで自動的に実行されます。リトライの初回は100ミリ秒、最大1回のリトライ時間は3000ミリ秒です。 -- `KV Backoff OPS`に「txnLock」操作が多すぎる場合は、アプリケーション側から書き込み競合の原因を分析することをお勧めします。 +- `KV Backoff OPS`に"txnLock"操作が多すぎる場合は、アプリケーション側から書き込み競合の原因を分析することをお勧めします。 - アプリケーションで書き込み-書き込み競合が発生するシナリオの場合は、悲観的トランザクションモードを使用することを強くお勧めします。 ### LockNotFoundエラー {#locknotfound-error} -「TxnLockNotFound」というエラーログは、トランザクションのコミット時間がTTL時間よりも長く、トランザクションをコミットしようとした際に、そのロックが他のトランザクションによってロールバックされたことを意味します。TiDBサーバーがトランザクションコミットの再試行を有効にしている場合、このトランザクションは[tidb_retry_limit](/system-variables.md#tidb_retry_limit)に従って再実行されます。（明示的トランザクションと暗黙的トランザクションの違いに注意してください。） +"TxnLockNotFound"というエラーログは、トランザクションのコミット時間がTTL時間よりも長く、トランザクションをコミットしようとした際に、そのロックが他のトランザクションによってロールバックされたことを意味します。TiDBサーバーがトランザクションコミットの再試行を有効にしている場合、このトランザクションは[tidb_retry_limit](/system-variables.md#tidb_retry_limit)に従って再実行されます。（明示的トランザクションと暗黙的トランザクションの違いに注意してください。） -「LockNotFound」エラーがあるかどうかは、次の方法で確認できます。 +"LockNotFound"エラーがあるかどうかは、次の方法で確認できます。 1. TiDBサーバーのログを確認する - 「TxnLockNotFound」エラーが発生した場合、TiDB ログ メッセージは次のようになります。 + "TxnLockNotFound"エラーが発生した場合、TiDB ログ メッセージは次のようになります。 ```log [WARN] [session.go:446] ["commit failed"] [conn=149370] ["finished txn"="Txn{state=invalid}"] [error="[kv:6]Error: KV error safe to retry tikv restarts txn: Txn(Mvcc(TxnLockNotFound{ start_ts: 412720515987275779, commit_ts: 412720519984971777, key: [116, 128, 0, 0, 0, 0, 1, 111, 16, 95, 114, 128, 0, 0, 0, 0, 0, 0, 2] })) [try again later]"] @@ -256,7 +256,7 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ 2. TiKVサーバーのログを確認する - 「TxnLockNotFound」エラーが発生した場合、TiKV ログ メッセージは次のようになります。 + "TxnLockNotFound"エラーが発生した場合、TiKV ログ メッセージは次のようになります。 ```log Error: KV error safe to retry restarts txn: Txn(Mvcc(TxnLockNotFound)) [ERROR [Kv.rs:708] ["KvService::batch_raft send response fail"] [err=RemoteStoped] diff --git a/two-data-centers-in-one-city-deployment.md b/two-data-centers-in-one-city-deployment.md index 51c8e4c1744a1..fc15bac59398d 100644 --- a/two-data-centers-in-one-city-deployment.md +++ b/two-data-centers-in-one-city-deployment.md @@ -7,7 +7,7 @@ summary: 1つのリージョンに 2つのアベイラビリティゾーンを このドキュメントでは、アーキテクチャ、構成、このデプロイメント モードを有効にする方法、このモードでレプリカを使用する方法など、1つのリージョン内の 2つのアベイラビリティゾーン (AZ) のデプロイメント モードについて説明します。 -このドキュメントにおける「リージョン」という用語は地理的な領域を指し、「リージョン」はTiKVにおけるデータストレージの基本単位を指します。「AZ」はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 +このドキュメントにおける"region"という用語は地理的な領域を指し、大文字の"Region"はTiKVにおけるデータストレージの基本単位を指します。"AZ"はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 ## 導入 {#introduction} @@ -234,7 +234,7 @@ cat default.json 設定項目の説明: - `replication-mode`は有効にするレプリケーションモードです。上記の例では`dr-auto-sync`に設定されています。デフォルトでは、多数決プロトコルが使用されます。 -- `label-key`は異なる AZ を区別するために使用され、配置ルールに一致する必要があります。この例では、プライマリ AZ は「east」、災害復旧 AZ は「west」です。 +- `label-key`は異なる AZ を区別するために使用され、配置ルールに一致する必要があります。この例では、プライマリ AZ は"east"、災害復旧 AZ は"west"です。 - `primary-replicas`はプライマリ AZ 内の Voter レプリカの数です。 - `dr-replicas`は、災害復旧 (DR) AZ 内の投票者レプリカの数です。 - `wait-store-timeout`は、ネットワークの分離または障害発生時に非同期レプリケーションモードに切り替えるまでの待機時間です。ネットワーク障害の時間が待機時間を超えると、非同期レプリケーションモードが有効になります。デフォルトの待機時間は60秒です。 diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index 06b4a2a098b64..9ad0a57e74350 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -53,7 +53,7 @@ summary: TiUPを使用してTiDBをアップグレードする方法を学びま - TiCDC、 TiFlash、およびその他のコンポーネントのバージョンアップグレードをサポートします。 - クラスターが TiCDC クラシックアーキテクチャ(v8.1.2 など) を使用している場合は、メジャーバージョン間のアップグレード中に変更フィードを実行し続けないでください。この場合、次の手順を順番に実行します。すべての変更フィードを一時停止し、TiCDC をアップグレードし、TiDB クラスターをアップグレードし、すべての変更フィードを再開します。詳細については、 [以前のバージョンからのアップグレードに関する互換性に関する注意事項](/ticdc/ticdc-compatibility.md#compatibility-notes-for-upgrading-from-earlier-versions)を参照してください。 - TiFlashをv6.3.0より前のバージョンからv6.3.0以降のバージョンにアップグレードする場合、Linux AMD64アーキテクチャではCPUがAVX2命令セットを、Linux ARM64アーキテクチャではARMv8命令セットアーキテクチャをサポートしている必要があることに注意してください。詳細は[v6.3.0 リリースノート](/releases/release-6.3.0.md#others)の説明を参照してください。 -- 各バージョンの互換性に関する詳細な変更点については、各バージョンの[リリースノート](/releases/_index.md)を参照してください。該当するリリースノートの「互換性の変更点」セクションに従って、クラスタ構成を変更してください。 +- 各バージョンの互換性に関する詳細な変更点については、各バージョンの[リリースノート](/releases/_index.md)を参照してください。該当するリリースノートの"Compatibility Changes"セクションに従って、クラスタ構成を変更してください。 - クラスターをv5.3より前のバージョンからv5.3以降のバージョンに更新する場合、デフォルトでデプロイされているPrometheusによって生成されるアラートの時刻フォーマットが変更されることに注意してください。このフォーマット変更はPrometheus v2.27.1から導入されています。詳細については、 [Prometheus](https://github.com/prometheus/prometheus/commit/7646cbca328278585be15fa615e22f2a50b47d06)を参照してください。 ## 準備 {#preparations} @@ -149,7 +149,7 @@ tiup update cluster 2. [トポロジー](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)設定テンプレートのフォーマットを参照し、トポロジファイルの`server_configs`セクションに変更したいパラメータを入力します。 -3. 変更後、 「: + w + q」と入力して変更を保存し、編集モードを終了します。変更を確定するには「Y」と入力してください。 +3. 変更後、 「: + w + q」と入力して変更を保存し、編集モードを終了します。変更を確定するにはYと入力してください。 ### ステップ4：クラスターのDDLとバックアップの状態を確認します {#step-4-check-the-ddl-and-backup-status-of-the-cluster} @@ -170,10 +170,10 @@ tiup update cluster tiup cluster check --cluster ``` -コマンドが実行されると、「リージョンステータス」のチェック結果が出力されます。 +コマンドが実行されると、"Region status"のチェック結果が出力されます。 -- 結果が「すべてのリージョンは正常です」であれば、現在のクラスター内のすべてのリージョンは正常であり、アップグレードを続行できます。 -- 結果が「リージョンが完全に正常ではありません：m個のミスピア、n個の保留ピア」で、「他の操作を行う前に、異常なリージョンを修正してください。」というメッセージが表示される場合、現在のクラスタ内の一部のリージョンに異常があります。チェック結果が「すべてのリージョンが正常です」になるまで、異常のトラブルシューティングを行う必要があります。その後、アップグレードを続行できます。 +- 結果が"All Regions are healthy"であれば、現在のクラスター内のすべてのリージョンは正常であり、アップグレードを続行できます。 +- 結果が「リージョンが完全に正常ではありません：m個のミスピア、n個の保留ピア」で、「他の操作を行う前に、異常なリージョンを修正してください。」というメッセージが表示される場合、現在のクラスタ内の一部のリージョンに異常があります。チェック結果が"All Regions are healthy"になるまで、異常のトラブルシューティングを行う必要があります。その後、アップグレードを続行できます。 ## TiDBクラスタをアップグレードする {#upgrade-the-tidb-cluster} diff --git a/user-account-management.md b/user-account-management.md index 5bf67dc6dc881..f9fbcfce2a574 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -42,7 +42,7 @@ CREATE USER [IF NOT EXISTS] user [IDENTIFIED BY 'auth_string']; CREATE USER 'test'@'127.0.0.1' IDENTIFIED BY 'xxx'; ``` -TiDBアカウント名はユーザー名とホスト名で構成されます。アカウント名の構文は「user_name@host_name」です。 +TiDBアカウント名はユーザー名とホスト名で構成されます。アカウント名の構文は"user_name"@"host_name"です。 - `user_name`は大文字と小文字が区別されます。 From 33ed00a62a7f18a4ef9d6145e23f403ddae89dca Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 14:37:31 +0900 Subject: [PATCH 02/56] revert: 'prepare'/'preparing' is rhetorical emphasis on Prepare API, not a literal value --- develop/dev-guide-connection-parameters.md | 6 +++--- develop/java-app-best-practices.md | 10 +++++----- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index 629e50b52ab5a..4765ec33db707 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -198,7 +198,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 - **useServerPrepStmts** - **useServerPrepStmts**はデフォルトで`false`に設定されています。つまり、Prepare API を使用する場合でも、"prepare"操作はクライアント側でのみ実行されます。サーバーの解析オーバーヘッドを回避するため、同じ SQL文で Prepare API を複数回使用する場合は、この設定を`true`に設定することをお勧めします。 + **useServerPrepStmts**はデフォルトで`false`に設定されています。つまり、Prepare API を使用する場合でも、「prepare」操作はクライアント側でのみ実行されます。サーバーの解析オーバーヘッドを回避するため、同じ SQL文で Prepare API を複数回使用する場合は、この設定を`true`に設定することをお勧めします。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 @@ -207,7 +207,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 - **`cachePrepStmts`** - `useServerPrepStmts=true`ではサーバーがプリペアドステートメントを実行できますが、デフォルトではクライアントは実行後にプリペアドステートメントを閉じ、再利用しません。つまり、"prepare"操作はテキストファイルの実行ほど効率的ではありません。この問題を解決するには、 `useServerPrepStmts=true`を設定した後、 `cachePrepStmts=true`を設定することをお勧めします。これにより、クライアントはプリペアドステートメントをキャッシュできるようになります。 + `useServerPrepStmts=true`ではサーバーがプリペアドステートメントを実行できますが、デフォルトではクライアントは実行後にプリペアドステートメントを閉じ、再利用しません。つまり、「準備」操作はテキストファイルの実行ほど効率的ではありません。この問題を解決するには、 `useServerPrepStmts=true`を設定した後、 `cachePrepStmts=true`を設定することをお勧めします。これにより、クライアントはプリペアドステートメントをキャッシュできるようになります。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 @@ -229,7 +229,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 - **prepStmtCacheSize** - **prepStmtCacheSize**は、キャッシュされるプリペアドステートメントの数を制御します（デフォルト値は`25`です）。アプリケーションで多くの種類の SQL文を"preparing"する必要があり、プリペアドステートメントを再利用したい場合は、この値を増やすことができます。 + **prepStmtCacheSize**は、キャッシュされるプリペアドステートメントの数を制御します（デフォルト値は`25`です）。アプリケーションで多くの種類の SQL文を「準備」する必要があり、プリペアドステートメントを再利用したい場合は、この値を増やすことができます。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index 981668aa1b5c9..f4c5c6f42e678 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -88,7 +88,7 @@ JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式 ##### `useServerPrepStmts` {#useserverprepstmts} -`useServerPrepStmts`はデフォルトで`false`に設定されています。つまり、Prepare API を使用する場合でも、"prepare"操作はクライアント側でのみ実行されます。サーバーの解析オーバーヘッドを回避するため、同じ SQL文で Prepare API を複数回使用する場合は、この設定を`true`に設定することをお勧めします。 +`useServerPrepStmts`はデフォルトで`false`に設定されています。つまり、Prepare API を使用する場合でも、「prepare」操作はクライアント側でのみ実行されます。サーバーの解析オーバーヘッドを回避するため、同じ SQL文で Prepare API を複数回使用する場合は、この設定を`true`に設定することをお勧めします。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 @@ -97,7 +97,7 @@ JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式 ##### `cachePrepStmts` {#cacheprepstmts} -`useServerPrepStmts=true`はサーバーがプリペアドステートメントを実行できるようにしますが、デフォルトではクライアントは実行後にプリペアドステートメントを閉じ、再利用しません。つまり、"prepare"操作はテキストファイルの実行ほど効率的ではありません。この問題を解決するには、 `useServerPrepStmts=true`を設定した後、 `cachePrepStmts=true`も設定することをお勧めします。これにより、クライアントはプリペアドステートメントをキャッシュできるようになります。 +`useServerPrepStmts=true`はサーバーがプリペアドステートメントを実行できるようにしますが、デフォルトではクライアントは実行後にプリペアドステートメントを閉じ、再利用しません。つまり、「準備」操作はテキストファイルの実行ほど効率的ではありません。この問題を解決するには、 `useServerPrepStmts=true`を設定した後、 `cachePrepStmts=true`も設定することをお勧めします。これにより、クライアントはプリペアドステートメントをキャッシュできるようになります。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 @@ -119,7 +119,7 @@ JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式 ##### `prepStmtCacheSize` {#prepstmtcachesize} -`prepStmtCacheSize`キャッシュされるプリペアドステートメントの数を制御します (デフォルト値は`25`です)。アプリケーションで多くの種類の SQL文を"prepare"する必要があり、プリペアドステートメントを再利用したい場合は、この値を増やすことができます。 +`prepStmtCacheSize`キャッシュされるプリペアドステートメントの数を制御します (デフォルト値は`25`です)。アプリケーションで多くの種類の SQL文を「準備」する必要があり、プリペアドステートメントを再利用したい場合は、この値を増やすことができます。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 @@ -296,8 +296,8 @@ The last packet sent successfully to the server was 3600000 milliseconds ago. Th MyBatis Mapperは2つのパラメータをサポートしています。 -- `select 1 from t where id = #{param1}` 、プリペアドステートメントとして`select 1 from t where id =?`に変換され、"prepared"の状態になります。実際のパラメータは再利用されます。このパラメータを前述の接続準備パラメータと併用すると、最高のパフォーマンスが得られます。 -- `select 1 from t where id = ${param2}`はテキストファイル`select 1 from t where id = 1`に置き換えられ、実行されます。このステートメントが異なるパラメータに置き換えられて実行されると、MyBatis はステートメントの"preparing"のために TiDB に異なるリクエストを送信します。これにより、TiDB が多数のプリペアドステートメントをキャッシュする可能性があり、この方法で SQL 操作を実行すると、インジェクションのセキュリティリスクが発生します。 +- `select 1 from t where id = #{param1}` 、プリペアドステートメントとして`select 1 from t where id =?`に変換され、「準備済み」の状態になります。実際のパラメータは再利用されます。このパラメータを前述の接続準備パラメータと併用すると、最高のパフォーマンスが得られます。 +- `select 1 from t where id = ${param2}`はテキストファイル`select 1 from t where id = 1`に置き換えられ、実行されます。このステートメントが異なるパラメータに置き換えられて実行されると、MyBatis はステートメントの「準備」のために TiDB に異なるリクエストを送信します。これにより、TiDB が多数のプリペアドステートメントをキャッシュする可能性があり、この方法で SQL 操作を実行すると、インジェクションのセキュリティリスクが発生します。 #### 動的SQLバッチ {#dynamic-sql-batch} From 7b927414a41025729a3fa0febf786f51cdabdd32 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 14:41:28 +0900 Subject: [PATCH 03/56] revert: 3 more rhetorical-emphasis-on-translated-term cases wrongly changed to straight quotes --- dm/dm-precheck.md | 2 +- resources/doc-templates/template-concept.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/dm/dm-precheck.md b/dm/dm-precheck.md index 0ba64199ee0fe..fbc66554f5736 100644 --- a/dm/dm-precheck.md +++ b/dm/dm-precheck.md @@ -27,7 +27,7 @@ tiup dmctl check-task ./task.yaml > **Note:** > -> この文書では、必ず合格しなければならないチェック項目には"（必須）"というラベルが付いています。 +> この文書では、必ず合格しなければならないチェック項目には「（必須）」というラベルが付いています。 > - 必須チェック項目に合格しなかった場合、DM はチェック後にエラーを返し、移行タスクを続行しません。この場合、エラーメッセージに従って設定を変更し、事前チェック要件を満たした後にタスクを再試行してください。 > diff --git a/resources/doc-templates/template-concept.md b/resources/doc-templates/template-concept.md index 6c2aac8fcf638..1042801c40d7e 100644 --- a/resources/doc-templates/template-concept.md +++ b/resources/doc-templates/template-concept.md @@ -30,7 +30,7 @@ summary: このドキュメントを115～145文字で要約してください ここで基本的な動作原理を説明したり、その原理を上記のコンポーネント紹介に統合したりすることもできます。 -### L3 見出し（オプション、例："xxxコンポーネント"） {#l3-heading-optional-e-g-xxx-component} +### L3 見出し（オプション、例：「xxxコンポーネント」） {#l3-heading-optional-e-g-xxx-component} コンポーネントが複雑な場合は、このように別のセクションで詳しく説明できます。 @@ -38,7 +38,7 @@ summary: このドキュメントを115～145文字で要約してください xxx -## L2 見出し (オプション、例:"主な機能/制限事項") {#l2-heading-optional-e-g-key-features-limitations} +## L2 見出し (オプション、例:「主な機能/制限事項」) {#l2-heading-optional-e-g-key-features-limitations} 2 番目の L2 見出しでは、主な機能、使用シナリオ、制限など、ユーザーが事前に知っておく必要のある基本情報を紹介します。 From 5e1cf11a8084364017540479015067e7691a55b7 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 14:44:20 +0900 Subject: [PATCH 04/56] i18n(ja): add Japanese gloss for general DDL, matching the existing reorg DDL gloss --- best-practices/ddl-introduction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index 9bff4eee0b60b..9bd9f76497739 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -22,7 +22,7 @@ TiDBはオンラインDDLをサポートしています。つまり、データ - **論理 DDL文**: 論理 DDL文は通常、テーブル名の変更や列名の変更など、オブジェクトに格納されているデータを処理せずに、データベースオブジェクトのメタデータのみを変更します。 - TiDBでは、論理DDL文は"general DDL"とも呼ばれます。これらの文は通常、実行時間が短く、完了までに数十ミリ秒または数秒しかかからないことがよくあります。そのため、システムリソースをあまり消費せず、アプリケーションのワークロードにも影響を与えません。 + TiDBでは、論理DDL文は"general DDL"（汎用DDL）とも呼ばれます。これらの文は通常、実行時間が短く、完了までに数十ミリ秒または数秒しかかからないことがよくあります。そのため、システムリソースをあまり消費せず、アプリケーションのワークロードにも影響を与えません。 - **物理DDL文**：物理DDL文は、変更対象となるオブジェクトのメタデータを変更するだけでなく、オブジェクトに格納されているユーザーデータも変更します。例えば、TiDBがテーブルのインデックスを作成する場合、テーブルの定義を変更するだけでなく、新しく追加されたインデックスを構築するためにテーブル全体のスキャンを実行します。 From e15cfbdb9bce61c5e25fd787183a93d38cf250cf Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 14:45:48 +0900 Subject: [PATCH 05/56] i18n(ja): symmetric reorg-DDL gloss + revert before/after-change rhetorical quoting --- best-practices/ddl-introduction.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index 9bd9f76497739..4352f8ac3fd9c 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -26,7 +26,7 @@ TiDBはオンラインDDLをサポートしています。つまり、データ - **物理DDL文**：物理DDL文は、変更対象となるオブジェクトのメタデータを変更するだけでなく、オブジェクトに格納されているユーザーデータも変更します。例えば、TiDBがテーブルのインデックスを作成する場合、テーブルの定義を変更するだけでなく、新しく追加されたインデックスを構築するためにテーブル全体のスキャンを実行します。 - TiDBでは、物理DDL文は"reorg DDL"（再編成）とも呼ばれます。現在、物理DDL文には、 `ADD INDEX`と損失のある列型変更（例えば、 `INT`型から`CHAR`型への変更）のみが含まれます。これらの文の実行には時間がかかり、実行時間はテーブル内のデータ量、マシン構成、アプリケーションのワークロードによって影響を受けます。 + TiDBでは、物理DDL文は"reorg DDL"（再編成DDL）とも呼ばれます。現在、物理DDL文には、 `ADD INDEX`と損失のある列型変更（例えば、 `INT`型から`CHAR`型への変更）のみが含まれます。これらの文の実行には時間がかかり、実行時間はテーブル内のデータ量、マシン構成、アプリケーションのワークロードによって影響を受けます。 物理DDL文の実行は、2つの理由からアプリケーションのワークロードに影響を与える可能性があります。1つは、データの読み取りと新規データの書き込みにTiKVのCPUリソースとI/Oリソースを消費することです。もう1つは、 **DDLオーナーとして機能するTiDBノード**、または**TiDB分散実行フレームワーク（DXF）によって`ADD INDEX`タスクを実行するようにスケジュールされたTiDBノードが、**対応する計算を実行するためにTiDBのCPUリソースを消費することです。 @@ -63,7 +63,7 @@ ADMIN SHOW DDL; TiDB DDL モジュールは設計当初からオンライン非同期変更モードを選択しており、これによりダウンタイムを経験することなくアプリケーションを変更できます。 -DDL変更は、ある状態から別の状態への遷移を伴い、通常は"before change"の状態から"after change"の状態へと遷移します。オンラインDDL変更では、この遷移は、相互に互換性のある複数の小さなバージョン状態を導入することによって発生します。DDL文の実行中、同じクラスタ内のTiDBノードは、変更オブジェクトの小さなバージョン間の差異が2バージョン以内であれば、異なる小さなバージョン変更を持つことができます。これは、隣接する小さなバージョンが相互に互換性を持つことができるためです。 +DDL変更は、ある状態から別の状態への遷移を伴い、通常は「変更前」の状態から「変更後」の状態へと遷移します。オンラインDDL変更では、この遷移は、相互に互換性のある複数の小さなバージョン状態を導入することによって発生します。DDL文の実行中、同じクラスタ内のTiDBノードは、変更オブジェクトの小さなバージョン間の差異が2バージョン以内であれば、異なる小さなバージョン変更を持つことができます。これは、隣接する小さなバージョンが相互に互換性を持つことができるためです。 このように、複数の小さなバージョンを経ることで、複数のTiDBノード間でメタデータが正しく同期されます。これにより、プロセス中にデータの変更を伴うユーザートランザクションの正確性と一貫性が維持されます。 From 03879ef8b3d68823b4cdede68135c9037d229d25 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 14:49:12 +0900 Subject: [PATCH 06/56] i18n(ja): add Japanese gloss for disjunctive predicates and simplify clause structure --- best-practices/multi-column-index-best-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 28ecc2cf58076..5c837444205ba 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -129,7 +129,7 @@ TiDBオプティマイザには、強力な範囲導出コンポーネントが ## 複数列インデックスの分離条件（ `OR`条件） {#disjunctive-conditions-or-conditions-in-multi-column-indexes} -クエリに`OR`条件（"disjunctive predicates"と呼ばれる）がある場合、オプティマイザは各条件を個別に処理し、 `OR`条件の各部分について範囲を作成します。これらの範囲が重複している場合、オプティマイザはそれらを1つの連続した範囲に結合します。重複していない場合は、それぞれ別々の範囲として保持され、どちらもインデックススキャンに使用できます。 +クエリに"disjunctive predicates"（選言述語）と呼ばれる`OR`条件がある場合、オプティマイザは各条件を個別に処理し、 `OR`条件の各部分について範囲を作成します。これらの範囲が重複している場合、オプティマイザはそれらを1つの連続した範囲に結合します。重複していない場合は、それぞれ別々の範囲として保持され、どちらもインデックススキャンに使用できます。 ### 例1: 重複する範囲 {#example-1-overlapping-ranges} From 163fa5b7a840a7e4693d577a262939cc91782cbe Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 14:50:24 +0900 Subject: [PATCH 07/56] i18n(ja): translate positive feedback loop, a well-established engineering term --- br/br-auto-tune.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md index ea37635dfa6b6..50097472545f1 100644 --- a/br/br-auto-tune.md +++ b/br/br-auto-tune.md @@ -39,7 +39,7 @@ tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v 自動調整機能には、次の問題と対応する解決策があります。 -- 問題1：**書き込み負荷の高いクラスタ**では、自動チューニングによってワークロードとバックアップタスクが"positive feedback loop"に陥る可能性があります。つまり、バックアップタスクが過剰なリソースを消費し、クラスタが使用するリソースが少なくなるのです。この時点で、自動チューニングはクラスタのワークロードがそれほど高くないと誤って判断し、バックアップの実行速度を速めてしまう可能性があります。このような場合、自動チューニングは効果を発揮しません。 +- 問題1：**書き込み負荷の高いクラスタ**では、自動チューニングによってワークロードとバックアップタスクが「正のフィードバックループ」に陥る可能性があります。つまり、バックアップタスクが過剰なリソースを消費し、クラスタが使用するリソースが少なくなるのです。この時点で、自動チューニングはクラスタのワークロードがそれほど高くないと誤って判断し、バックアップの実行速度を速めてしまう可能性があります。このような場合、自動チューニングは効果を発揮しません。 - 解決策：バックアップタスクで使用されるスレッド数を制限したい場合は、手動で`backup.num-threads`小さい数値に調整してください。動作原理は以下のとおりです。 From c86bbf397ba3611babb976183faf983cd5a04f3b Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 14:51:39 +0900 Subject: [PATCH 08/56] revert: expired is not a literal DM validation state value --- dm/dm-continuous-data-validation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dm/dm-continuous-data-validation.md b/dm/dm-continuous-data-validation.md index 14e4d4a754e25..c5cba15f0fb95 100644 --- a/dm/dm-continuous-data-validation.md +++ b/dm/dm-continuous-data-validation.md @@ -285,7 +285,7 @@ DM における継続的なデータ検証 (バリデータ) のアーキテク - バリデータは、シンカーによって増分移行されたイベントのみをチェックします。イベントがシンカーによって処理されていない場合、バリデータは一時停止し、シンカーによる処理が完了するまで待機します。 - イベントがシンカーによって処理された場合、バリデーターは次の手順に進みます。 2. バリデータはbinlogイベントを解析し、ブロックリストと許可リスト、テーブルフィルター、テーブルルーティングに基づいて行をフィルタリングします。その後、バリデータは変更された行をバックグラウンドで実行される検証ワーカーに送信します。 -3. 検証ワーカーは、同じテーブルと同じ主キーに影響する変更された行をマージし、"expired"データの検証を回避します。変更された行はメモリにキャッシュされます。 +3. 検証ワーカーは、同じテーブルと同じ主キーに影響する変更された行をマージし、「期限切れ」データの検証を回避します。変更された行はメモリにキャッシュされます。 4. 検証ワーカーは、変更された行が一定数蓄積されるか、一定の時間間隔が経過すると、主キーを使用して下流のデータベースを照会し、現在のデータを取得して、変更された行と比較します。 5. 検証ワーカーはデータ検証を実行します。検証モードが`full`の場合、検証ワーカーは変更された行のデータを下流データベースのデータと比較します。検証モードが`fast`の場合、検証ワーカーは変更された行の存在のみを確認します。 - 変更された行が検証に合格した場合、変更された行はメモリから削除されます。 From 1ec72d13684fb6c4ab92f08cc6aa794afbf45984 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 14:54:40 +0900 Subject: [PATCH 09/56] i18n(ja): translate exactly/at-least-once processing, transaction order, and force insert --- dm/dm-replication-logic.md | 4 ++-- dm/dm-safe-mode.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/dm/dm-replication-logic.md b/dm/dm-replication-logic.md index 2cdda6dbe8fd3..4eec71d5ec105 100644 --- a/dm/dm-replication-logic.md +++ b/dm/dm-replication-logic.md @@ -141,7 +141,7 @@ DMは行レベルでデータを複製するため、トランザクションの ### セーフモード {#safe-mode} -DML実行とチェックポイント更新の操作はアトミックではなく、チェックポイント更新と下流へのデータ書き込みの操作もアトミックではありません。DMが異常終了した場合、チェックポイントは終了時刻より前のリカバリポイントのみを記録する可能性があります。そのため、タスクが再開されると、DMは同じデータを複数回書き込む可能性があります。これは、DMが実際には"at least once processing"ロジックを提供していることを意味し、同じデータが複数回処理される可能性があります。 +DML実行とチェックポイント更新の操作はアトミックではなく、チェックポイント更新と下流へのデータ書き込みの操作もアトミックではありません。DMが異常終了した場合、チェックポイントは終了時刻より前のリカバリポイントのみを記録する可能性があります。そのため、タスクが再開されると、DMは同じデータを複数回書き込む可能性があります。これは、DMが実際には「少なくとも1回の処理」ロジックを提供していることを意味し、同じデータが複数回処理される可能性があります。 データが再入可能であることを確認するために、DM は異常終了から再起動するときにセーフモードに入ります。 @@ -152,4 +152,4 @@ DML実行とチェックポイント更新の操作はアトミックではな ### 正確に1回だけ処理 {#exactly-once-processing} -現在、DM は結果整合性のみを保証しており、"exactly-once processing"や"keeping the original order of transactions"はサポートしていません。 +現在、DM は結果整合性のみを保証しており、「正確に1回だけ処理」や「トランザクションの元の順序を維持すること」はサポートしていません。 diff --git a/dm/dm-safe-mode.md b/dm/dm-safe-mode.md index 48b0abb68cb00..f28e7c70c06bd 100644 --- a/dm/dm-safe-mode.md +++ b/dm/dm-safe-mode.md @@ -26,7 +26,7 @@ summary: DMセーフモードについて、その目的、動作原理、およ バージョン8.5.6以降、タスクセッションで`foreign_key_checks=1`を設定すると、DMは主キーまたは一意インデックス値を変更しない`DELETE` `UPDATE`ステップをスキップします。詳細については、[外部キーの処理](#foreign-key-handling-new-in-v856)キー を参照してください。 -`REPLACE`は、MySQL でデータを挿入するための固有の構文です。 `REPLACE`を使用してデータを挿入し、新しいデータと既存のデータに主キーまたは一意制約の競合がある場合、MySQL は競合するすべてのレコードを削除し、挿入操作を実行します。これは"force insert"と同等です。詳細については、MySQL ドキュメントの[`REPLACE`文](https://dev.mysql.com/doc/refman/8.0/en/replace.html)を参照してください。 +`REPLACE`は、MySQL でデータを挿入するための固有の構文です。 `REPLACE`を使用してデータを挿入し、新しいデータと既存のデータに主キーまたは一意制約の競合がある場合、MySQL は競合するすべてのレコードを削除し、挿入操作を実行します。これは「強制挿入」と同等です。詳細については、MySQL ドキュメントの[`REPLACE`文](https://dev.mysql.com/doc/refman/8.0/en/replace.html)を参照してください。 `dummydb.dummytbl`テーブルに主キー`id`があると仮定します。このテーブルに対して、次の SQL文を繰り返し実行します。 From bb69d1fec523b210d03c4af96844e02a710e58d7 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 15:18:37 +0900 Subject: [PATCH 10/56] i18n(ja): clarify coprocessor error log wording per actual PR #8006 content --- releases/release-2.1-rc.4.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases/release-2.1-rc.4.md b/releases/release-2.1-rc.4.md index ddd5c2a053960..0a14d2fdc2040 100644 --- a/releases/release-2.1-rc.4.md +++ b/releases/release-2.1-rc.4.md @@ -28,7 +28,7 @@ summary: TiDB 2.1 RC4は2018年10月23日にリリースされ、安定性、SQL - ラッチをリファクタリングしてトランザクションの競合の誤判断を回避し、同時トランザクションの実行パフォーマンスを向上させる[#7711](https://github.com/pingcap/tidb/pull/7711) - 一部のケースでスロークエリを収集することによって発生するpanic問題を修正[#7874](https://github.com/pingcap/tidb/pull/7847) - `LOAD DATA`文で`ESCAPED BY`が空文字列の場合のpanic問題を修正 [#8005](https://github.com/pingcap/tidb/pull/8005) - - "coprocessor error"ログ情報を完了する [#8006](https://github.com/pingcap/tidb/pull/8006) + - "coprocessor error"ログの情報を拡充する [#8006](https://github.com/pingcap/tidb/pull/8006) - 互換性 - クエリが空の場合、 `SHOW PROCESSLIST`結果の`Command`フィールドを`Sleep`に設定します[#7839](https://github.com/pingcap/tidb/pull/7839) - 表現 From c61e58d06f939e7bf2e77661c1eadf6c658ef98d Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 15:20:29 +0900 Subject: [PATCH 11/56] i18n(ja): restore dropped query subject in GROUP BY/UNION index-out-of-range bug fix --- releases/release-4.0.15.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases/release-4.0.15.md b/releases/release-4.0.15.md index a8d5954f7b6ed..8d293818fcc6a 100644 --- a/releases/release-4.0.15.md +++ b/releases/release-4.0.15.md @@ -91,7 +91,7 @@ TiDB バージョン: 4.0.15 - 範囲構築するときにバイナリリテラルの照合順序順序が誤って設定されるバグを修正しました [#23672](https://github.com/pingcap/tidb/issues/23672) - - に`GROUP BY`と`UNION`両方が含まれている場合に発生する"index out of range"というエラーを修正しました。 [#26553](https://github.com/pingcap/tidb/pull/26553) + - クエリに`GROUP BY`と`UNION`の両方が含まれている場合に発生する"index out of range"というエラーを修正しました。 [#26553](https://github.com/pingcap/tidb/pull/26553) - TiKVにtombstoneストアがある場合、TiDBがリクエストの送信に失敗する可能性がある問題を修正[#23676](https://github.com/pingcap/tidb/issues/23676) [#24648](https://github.com/pingcap/tidb/issues/24648) From 0ac9b9ef35617ab63d7732c3387995e2ed255319 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 15:21:22 +0900 Subject: [PATCH 12/56] i18n(ja): use backticks for pipelined and RECOVER TABLE in summary, matching body usage --- releases/release-4.0.0-rc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases/release-4.0.0-rc.md b/releases/release-4.0.0-rc.md index 4775d01e5a075..e73d19c44a7ed 100644 --- a/releases/release-4.0.0-rc.md +++ b/releases/release-4.0.0-rc.md @@ -1,6 +1,6 @@ --- title: TiDB 4.0 RC Release Notes -summary: TiDB 4.0 RCは2020年4月8日にリリースされました。互換性の変更、バグ修正、新機能、ツールが含まれています。TiKVは悲観的トランザクションにおける"pipelined"機能をサポートし、TPC-Cパフォーマンスを20%向上させました。TiDBは大文字と小文字を区別しない照合順序を追加し、"RECOVER TABLE"構文を強化しました。TiKVはHTTPポートでTLSをサポートするようになりました。PDはHTTP APIを介してデフォルトのPD構成情報を取得できるようになりました。バグ修正には、レプリケーション、サブクエリ結果、DDLジョブの内部再試行に関する問題が含まれます。TiDB LightningやTiCDCなどのツールにもバグ修正と新機能が含まれています。 +summary: TiDB 4.0 RCは2020年4月8日にリリースされました。互換性の変更、バグ修正、新機能、ツールが含まれています。TiKVは悲観的トランザクションにおける`pipelined`機能をサポートし、TPC-Cパフォーマンスを20%向上させました。TiDBは大文字と小文字を区別しない照合順序を追加し、`RECOVER TABLE`構文を強化しました。TiKVはHTTPポートでTLSをサポートするようになりました。PDはHTTP APIを介してデフォルトのPD構成情報を取得できるようになりました。バグ修正には、レプリケーション、サブクエリ結果、DDLジョブの内部再試行に関する問題が含まれます。TiDB LightningやTiCDCなどのツールにもバグ修正と新機能が含まれています。 --- # TiDB 4.0 RC リリースノート {#tidb-4-0-rc-release-notes} From a76215cffaeb1b83c4131340d1c19b5eb6b79d24 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 15:23:08 +0900 Subject: [PATCH 13/56] i18n(ja): translate adding/deleting a member, descriptive Raft operation names --- releases/release-5.0.0.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/releases/release-5.0.0.md b/releases/release-5.0.0.md index 96e64c6dcb1c0..8cd09b1099f72 100644 --- a/releases/release-5.0.0.md +++ b/releases/release-5.0.0.md @@ -369,9 +369,9 @@ Unified Sorterは、以前のバージョンの`memory` / `file`ソートエン [ユーザー向けドキュメント](/pd-configuration-file.md#enable-joint-consensus-new-in-v50)、 [#18079](https://github.com/pingcap/tidb/issues/18079) 、 [#7587](https://github.com/tikv/tikv/issues/7587) 、 [#2860](https://github.com/tikv/pd/issues/2860) -リージョンメンバーシップの変更処理では、"adding a member"と"deleting a member"という2つの操作が2つのステップで実行されます。メンバーシップ変更処理の完了時にエラーが発生した場合、リージョンは利用できなくなり、フォアグラウンドアプリケーションのエラーが返されます。 +リージョンメンバーシップの変更処理では、「メンバーの追加」と「メンバーの削除」という2つの操作が2つのステップで実行されます。メンバーシップ変更処理の完了時にエラーが発生した場合、リージョンは利用できなくなり、フォアグラウンドアプリケーションのエラーが返されます。 -導入されたRaft共同合意アルゴリズムは、リージョンメンバーシップ変更時のシステム可用性を向上させることができます。メンバーシップ変更時の"adding a member"と"deleting a member"操作は1つの操作に統合され、すべてのメンバーに送信されます。変更処理中、リージョンは中間状態になります。変更されたメンバーのいずれかが故障した場合でも、システムは引き続き利用可能です。 +導入されたRaft共同合意アルゴリズムは、リージョンメンバーシップ変更時のシステム可用性を向上させることができます。メンバーシップ変更時の「メンバーの追加」と「メンバーの削除」操作は1つの操作に統合され、すべてのメンバーに送信されます。変更処理中、リージョンは中間状態になります。変更されたメンバーのいずれかが故障した場合でも、システムは引き続き利用可能です。 この機能はデフォルトで有効になっています。 `pd-ctl config set enable-joint-consensus`コマンドを実行して`enable-joint-consensus`の値を`false`に設定することで無効にできます。 From bbf64e36ebdc97ee77eca17c83717c30d6dcc9b5 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 15:24:55 +0900 Subject: [PATCH 14/56] i18n(ja): fix quote-style mismatch, EN uses single quotes for these SQL_MODE values --- releases/release-5.1.2.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/releases/release-5.1.2.md b/releases/release-5.1.2.md index c4b78b21923a0..0debe37c7382e 100644 --- a/releases/release-5.1.2.md +++ b/releases/release-5.1.2.md @@ -21,8 +21,8 @@ TiDB バージョン: 5.1.2 - `group_concat`関数の列に非ビン照合順序がある場合に発生する誤った実行結果を修正しました [#27429](https://github.com/pingcap/tidb/issues/27429) - 新しい照合順序が有効になっているときに、複数の列で`count(distinct)`式を使用すると間違った結果が返される問題を修正しました[#27091](https://github.com/pingcap/tidb/issues/27091) - `extract`関数の引数が負の期間の場合に発生する結果の誤りを修正 [#27236](https://github.com/pingcap/tidb/issues/27236) - - `SQL_MODE`が"STRICT_TRANS_TABLES"の場合、無効な日付を挿入してもエラーが報告されない問題を修正しました[#26762](https://github.com/pingcap/tidb/issues/26762) - - `SQL_MODE`が"NO_ZERO_IN_DATE"の場合に無効なデフォルト日付を使用してもエラーが報告されない問題を修正しました[#26766](https://github.com/pingcap/tidb/issues/26766) + - `SQL_MODE`が'STRICT_TRANS_TABLES'の場合、無効な日付を挿入してもエラーが報告されない問題を修正しました[#26762](https://github.com/pingcap/tidb/issues/26762) + - `SQL_MODE`が'NO_ZERO_IN_DATE'の場合に無効なデフォルト日付を使用してもエラーが報告されない問題を修正しました[#26766](https://github.com/pingcap/tidb/issues/26766) - ツール From 202c290eb020627fe786e2864ce7231d5a2daed1 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 15:31:34 +0900 Subject: [PATCH 15/56] i18n(ja): restore missing object particle before support, translate At Least Once semantics --- ticdc/ticdc-canal-json.md | 2 +- ticdc/ticdc-open-api-v2.md | 2 +- ticdc/ticdc-open-api.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/ticdc/ticdc-canal-json.md b/ticdc/ticdc-canal-json.md index 3b67bd6f601cd..a6f78cf875c55 100644 --- a/ticdc/ticdc-canal-json.md +++ b/ticdc/ticdc-canal-json.md @@ -138,7 +138,7 @@ TiCDC は、DML データ変更イベントの行を次のようにエンコー TiCDCは、 `enable-tidb-extension`を`true`に設定した場合のみ、WATERMARKイベントを送信します。 `type`フィールドの値は`TIDB_WATERMARK`です。イベントには`_tidb`フィールドが含まれており、このフィールドにはパラメータ`watermarkTs`のみが含まれます。 `watermarkTs`の値は、イベント送信時に記録されるTSOです。 -このタイプのイベントを受信すると、 `commitTs`が`watermarkTs`より小さいすべてのイベントが送信されています。TiCDC は"At Least Once"のセマンティクスを提供するため、データが繰り返し送信される可能性があります。その後に`commitTs`が`watermarkTs`より小さいイベントを受信した場合は、このイベントを無視しても問題ありません。 +このタイプのイベントを受信すると、 `commitTs`が`watermarkTs`より小さいすべてのイベントが送信されています。TiCDC は「少なくとも1回」のセマンティクスを提供するため、データが繰り返し送信される可能性があります。その後に`commitTs`が`watermarkTs`より小さいイベントを受信した場合は、このイベントを無視しても問題ありません。 以下は WATERMARK イベントの例です。 diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md index 1bcd5cbbedc07..d5d6219405fa3 100644 --- a/ticdc/ticdc-open-api-v2.md +++ b/ticdc/ticdc-open-api-v2.md @@ -1060,7 +1060,7 @@ curl -X POST http://127.0.0.1:8300/api/v2/owner/resign | :---------- | :---------- | | `log_level` | 設定するログレベル。 | -`log_level` 、"debug"、"info"、"warn"、"error"、"dpanic"、"panic"、"fatal"の[zapが提供するログレベル](https://godoc.org/go.uber.org/zap#UnmarshalText)サポートします。 +`log_level` 、"debug"、"info"、"warn"、"error"、"dpanic"、"panic"、"fatal"の[zapが提供するログレベル](https://godoc.org/go.uber.org/zap#UnmarshalText)をサポートします。 ### 例 {#example} diff --git a/ticdc/ticdc-open-api.md b/ticdc/ticdc-open-api.md index c137cb8d9e02c..3bb43b778b289 100644 --- a/ticdc/ticdc-open-api.md +++ b/ticdc/ticdc-open-api.md @@ -556,7 +556,7 @@ curl -X POST -H "'Content-type':'application/json'" http://127.0.0.1:8300/api/v1 | :---------- | :---------- | | `log_level` | 設定するログレベル。 | -`log_level` 、"debug"、"info"、"warn"、"error"、"dpanic"、"panic"、"fatal"の[zapが提供するログレベル](https://godoc.org/go.uber.org/zap#UnmarshalText)サポートします。 +`log_level` 、"debug"、"info"、"warn"、"error"、"dpanic"、"panic"、"fatal"の[zapが提供するログレベル](https://godoc.org/go.uber.org/zap#UnmarshalText)をサポートします。 ### 例 {#example} From 5fca17c2c839c2c6d63ceaca85875201c61f1180 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 15:38:24 +0900 Subject: [PATCH 16/56] i18n(ja): restore Description/Send as English UI labels in PITR/API apply steps --- tidb-cloud/releases/release-notes-2022.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tidb-cloud/releases/release-notes-2022.md b/tidb-cloud/releases/release-notes-2022.md index 0d8e3dbf37be8..834b902950f46 100644 --- a/tidb-cloud/releases/release-notes-2022.md +++ b/tidb-cloud/releases/release-notes-2022.md @@ -147,7 +147,7 @@ summary: 2022年のTiDB Cloudのリリースノートについて説明します この機能はまだベータ版であり、リクエストに応じてのみ利用可能です。 - TiDB Cloudコンソールの右下隅にある**[ヘルプ]**をクリックします。 - - ダイアログの**説明**フィールドに"Apply for PITR"と入力し、 **[送信]**をクリックします。 + - ダイアログの**Description**フィールドに"Apply for PITR"と入力し、 **[Send]**をクリックします。 - データベース監査ログ機能が GA になりました。 @@ -385,7 +385,7 @@ summary: 2022年のTiDB Cloudのリリースノートについて説明します 現在、 TiDB Cloud APIはベータ版であり、リクエストに応じてのみご利用いただけます。APIアクセスを申請するには、リクエストを送信してください。 - [TiDB Cloudコンソール](https://tidbcloud.com/project/clusters)の右下にある**[ヘルプ]**をクリックします。 - - ダイアログの**説明**フィールドに"Apply for TiDB Cloud API"と入力し、 **[送信]**をクリックします。 + - ダイアログの**Description**フィールドに"Apply for TiDB Cloud API"と入力し、 **[Send]**をクリックします。 ## 2022年8月16日 {#august-16-2022} From 707c002aab3e92f90ee6001e3f4a3a6cba135475 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 7 Sep 2026 15:53:15 +0900 Subject: [PATCH 17/56] i18n(ja): revert exceptional to Japanese emphasis quotes, restore dropped topic particle --- non-transactional-dml.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/non-transactional-dml.md b/non-transactional-dml.md index cc86350b79020..e7bb961e3d65b 100644 --- a/non-transactional-dml.md +++ b/non-transactional-dml.md @@ -402,7 +402,7 @@ WHERE t.c1 IS NULL; -### 非トランザクション`DELETE` 、通常の`DELETE`と同等ではない"exceptional"動作をします。 {#non-transactional-delete-has-exceptional-behavior-that-is-not-equivalent-to-ordinary-delete} +### 非トランザクション`DELETE`は、通常の`DELETE`と同等ではない「例外的な」動作をします。 {#non-transactional-delete-has-exceptional-behavior-that-is-not-equivalent-to-ordinary-delete} 非トランザクション DML文は、この DML文の元の形式と同等ではありません。次のような理由が考えられます。 From b0a014faf2bf48e195a6ab2f3d889f13ded39b7b Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 09:10:01 +0900 Subject: [PATCH 18/56] i18n(ja): fix quote-style mismatches and missed-sibling conversions found in full corpus audit --- alert-rules.md | 2 +- as-of-timestamp.md | 2 +- configure-memory-usage.md | 2 +- dashboard/dashboard-access.md | 2 +- dashboard/dashboard-intro.md | 4 ++-- explain-joins.md | 2 +- garbage-collection-overview.md | 2 +- grafana-overview-dashboard.md | 2 +- literal-values.md | 2 +- read-historical-data.md | 2 +- releases/release-2.1.2.md | 2 +- releases/release-3.0.16.md | 2 +- releases/release-3.1.2.md | 2 +- releases/release-4.0.7.md | 2 +- releases/release-5.1.0.md | 2 +- releases/release-6.0.0-dmr.md | 2 +- releases/release-6.1.1.md | 2 +- sql-plan-management.md | 2 +- stale-read.md | 2 +- statement-summary-tables.md | 4 ++-- system-variables.md | 4 ++-- tidb-cloud/data-service-api-key.md | 2 +- tidb-cloud/import-csv-files-serverless.md | 2 +- tidb-cloud/integrate-tidbcloud-with-n8n.md | 2 +- tidb-cloud/premium/import-csv-files-premium.md | 2 +- .../notification-2023-11-14-scale-feature-maintenance.md | 2 +- tidb-cloud/releases/release-notes-2023.md | 4 ++-- tidb-cloud/tidb-cloud-auditing.md | 2 +- tidb-lightning/tidb-lightning-command-line-full.md | 2 +- tiflash/tiflash-mintso-scheduler.md | 2 +- tiproxy/tiproxy-configuration.md | 2 +- tiup/tiup-command-mirror-merge.md | 2 +- tiup/tiup-command-telemetry.md | 2 +- tiup/tiup-component-cluster-display.md | 2 +- tiup/tiup-component-cluster-meta-restore.md | 2 +- tiup/tiup-component-cluster-prune.md | 2 +- tiup/tiup-component-dm-import.md | 2 +- upgrade-tidb-using-tiup.md | 2 +- user-account-management.md | 2 +- 39 files changed, 43 insertions(+), 43 deletions(-) diff --git a/alert-rules.md b/alert-rules.md index 0bf6bea382649..255ff23d3c3aa 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-3} diff --git a/as-of-timestamp.md b/as-of-timestamp.md index 10c74f552849b..a164c51444e48 100644 --- a/as-of-timestamp.md +++ b/as-of-timestamp.md @@ -21,7 +21,7 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標 - [`START TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-start-transaction.md) - [`SET TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-set-transaction.md) -正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには"2016-10-08 16:45:26"のように秒単位で十分です。`NOW(3)`関数を使用して、現在時刻をミリ秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。 +正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は"2016-10-08 16:45:26.999"のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには"2016-10-08 16:45:26"のように秒単位で十分です。`NOW(3)`関数を使用して、現在時刻をミリ秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。 時間範囲を指定する場合は、句内で[`TIDB_BOUNDED_STALENESS()`](/functions-and-operators/tidb-functions.md#tidb_bounded_staleness)関数を使用できます。この関数を使用すると、TiDB は指定された時間範囲内で適切なタイムスタンプを選択します。「適切」とは、このタイムスタンプより前に開始され、アクセス先のレプリカにコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセス先のレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされていないことを意味します。この関数を呼び出すには`TIDB_BOUNDED_STALENESS(t1, t2)`を使用する必要があります。`t1`と`t2`は範囲の両端であり、datetime 値または時間関数を使用して指定できます。 diff --git a/configure-memory-usage.md b/configure-memory-usage.md index 340715467a167..901c465c09a1d 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -165,7 +165,7 @@ TiDBは、実行演算子のディスクへの書き込みをサポートして [tidb]> explain analyze select /*+ HASH_AGG() */ count(*) from t t1 join t t2 join t t3 group by t1.a, t2.a, t3.a; ``` - この SQL文を実行するとメモリが大量に消費されるため、次の`Out Of Memory Quota!`エラーメッセージが返されます。 + この SQL文を実行するとメモリが大量に消費されるため、次の"Out of Memory Quota"エラーメッセージが返されます。 ```sql ERROR 1105 (HY000): Out Of Memory Quota![conn_id=3] diff --git a/dashboard/dashboard-access.md b/dashboard/dashboard-access.md index 6f0275c2bdaee..14f3ad0d3fbe2 100644 --- a/dashboard/dashboard-access.md +++ b/dashboard/dashboard-access.md @@ -1,6 +1,6 @@ --- title: Access TiDB Dashboard -summary: TiDB Dashboardにアクセスするには、ブラウザで指定されたURLにアクセスしてください。複数のPDインスタンスの場合は、アドレスを任意のPDインスタンスのアドレスとポートに置き換えてください。Chrome、Firefox、またはEdgeブラウザ（最新バージョン）をご利用ください。TiDBルートアカウントまたはユーザー定義のSQLユーザーでサインインしてください。セッションは24時間有効です。言語は英語と中国語で切り替えられます。ログアウトするには、ユーザー名をクリックし、"Logout"ボタンをクリックしてください。 +summary: TiDB Dashboardにアクセスするには、ブラウザで指定されたURLにアクセスしてください。複数のPDインスタンスの場合は、アドレスを任意のPDインスタンスのアドレスとポートに置き換えてください。Chrome、Firefox、またはEdgeブラウザ（最新バージョン）をご利用ください。TiDBルートアカウントまたはユーザー定義のSQLユーザーでサインインしてください。セッションは24時間有効です。言語は英語と中国語で切り替えられます。ログアウトするには、ユーザー名をクリックし、**Logout**ボタンをクリックしてください。 --- # TiDB Dashboardにアクセスする {#access-tidb-dashboard} diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md index 0d19f6274b60b..a8a25fe6eb130 100644 --- a/dashboard/dashboard-intro.md +++ b/dashboard/dashboard-intro.md @@ -37,13 +37,13 @@ TiDB DashboardのKey Visualizer機能は、クラスター全体の読み取り/ ## すべてのSQL文の実行情報のリストを表示します {#show-a-list-of-execution-information-of-all-sql-statements} -すべてのSQL文の実行情報は、"SQL Statements"ページに表示されます。このページでは、すべてのステージにおける実行時間と合計実行回数を確認できます。これにより、最もリソースを消費しているSQLクエリを分析して特定し、クラスター全体のパフォーマンスを向上させることができます。 +すべてのSQL文の実行情報は、**SQL Statements**ページに表示されます。このページでは、すべてのステージにおける実行時間と合計実行回数を確認できます。これにより、最もリソースを消費しているSQLクエリを分析して特定し、クラスター全体のパフォーマンスを向上させることができます。 詳細は[TiDB DashboardのSQL Statementsページ](/dashboard/dashboard-statement-list.md)参照。 ## スロークエリの詳細な実行情報を知る {#learn-the-detailed-execution-information-of-slow-queries} -TiDB Dashboardの"Slow Queries"ページには、実行に時間のかかるすべてのSQL文のリスト（SQLテキストと実行情報を含む）が表示されます。このページは、スロークエリやパフォーマンスジッターの原因を特定するのに役立ちます。 +TiDB Dashboardの**Slow Queries**ページには、実行に時間のかかるすべてのSQL文のリスト（SQLテキストと実行情報を含む）が表示されます。このページは、スロークエリやパフォーマンスジッターの原因を特定するのに役立ちます。 詳細は[スロークエリページ](/dashboard/dashboard-slow-query.md)を参照。 diff --git a/explain-joins.md b/explain-joins.md index a64fdb802312e..1e3368e7e6684 100644 --- a/explain-joins.md +++ b/explain-joins.md @@ -283,4 +283,4 @@ EXPLAIN SELECT /*+ MERGE_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; 1. Join Group のすべてのデータを`Build`側からメモリに読み込みます。 2. `Probe`面のデータを読み取ります。 -3. `Probe`側の各データ行が`Build`側の結合グループと完全に一致するかどうかを比較します。等価条件の他に、非等価条件もあります。ここでの"match"とは、主に非等価条件が満たされているかどうかの確認を指します。結合グループとは、すべての結合キーの中で同じ値を持つデータを指します。 +3. `Probe`側の各データ行が`Build`側の結合グループと完全に一致するかどうかを比較します。等価条件の他に、非等価条件もあります。ここでの「一致」とは、主に非等価条件が満たされているかどうかの確認を指します。結合グループとは、すべての結合キーの中で同じ値を持つデータを指します。 diff --git a/garbage-collection-overview.md b/garbage-collection-overview.md index 31dee64090f20..6af76a281e13d 100644 --- a/garbage-collection-overview.md +++ b/garbage-collection-overview.md @@ -11,7 +11,7 @@ TiDBはMVCCを使用してトランザクションの同時実行を制御しま 各 TiDB クラスターには、GC プロセスを制御する GC リーダーとして選択される TiDB インスタンスが含まれています。 -TiDBでは、GCが定期的に実行されます。GCごとに、TiDBはまず"safe point"と呼ばれるタイムスタンプを計算します。次に、セーフポイント以降のすべてのスナップショットがデータの整合性を保持しているという前提で、TiDBは古いデータをクリアします。具体的には、各GCプロセスには以下の3つのステップが含まれます。 +TiDBでは、GCが定期的に実行されます。GCごとに、TiDBはまず「セーフポイント」と呼ばれるタイムスタンプを計算します。次に、セーフポイント以降のすべてのスナップショットがデータの整合性を保持しているという前提で、TiDBは古いデータをクリアします。具体的には、各GCプロセスには以下の3つのステップが含まれます。 1. ロックを解決します。このステップでは、TiDB はすべてのリージョンのセーフポイントの前のロックをスキャンし、これらのロックをクリアします。 2. 範囲を削除します。このステップでは、 `DROP TABLE` / `DROP INDEX`操作で生成された範囲全体の古いデータがすぐにクリアされます。 diff --git a/grafana-overview-dashboard.md b/grafana-overview-dashboard.md index 5082ffb21146f..e34f1593be23d 100644 --- a/grafana-overview-dashboard.md +++ b/grafana-overview-dashboard.md @@ -9,7 +9,7 @@ TiUPを使用してTiDBクラスターをデプロイする場合、監視シス Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、Disk Performance、Performance_overviewといった一連のサブダッシュボードに分かれています。診断に役立つ多くの指標が用意されています。 -日常的な運用では、主要なメトリクスが表示される"Overview"ダッシュボードから、コンポーネント（PD、TiDB、TiKV）のステータスとクラスタ全体の概要を確認できます。このドキュメントでは、これらの主要なメトリクスについて詳しく説明します。 +日常的な運用では、主要なメトリクスが表示されるOverviewダッシュボードから、コンポーネント（PD、TiDB、TiKV）のステータスとクラスタ全体の概要を確認できます。このドキュメントでは、これらの主要なメトリクスについて詳しく説明します。 ## 主要な指標の説明 {#key-metrics-description} diff --git a/literal-values.md b/literal-values.md index d0a2436025b00..fc7d2c0d73615 100644 --- a/literal-values.md +++ b/literal-values.md @@ -93,7 +93,7 @@ SELECT _utf8'some text'; TiDB は次の日付形式をサポートしています。 -- `'YYYY-MM-DD'`または`'YY-MM-DD'` : ここでの`-`という区切り文字は厳密ではありません。任意の句読点を使用できます。例えば、 `'2017-08-24'` 、 `'2017&08&24'` 、 `'2012@12^31'`はすべて有効な日付形式です。唯一の特別な句読点は"."で、これは整数部と小数部を区切る小数点として扱われます。日付と時刻は`T`または空白で区切ることができます。例えば、 `2017-8-24 10:42:00`と`2017-8-24T10:42:00`は同じ日付と時刻を表します。 +- `'YYYY-MM-DD'`または`'YY-MM-DD'` : ここでの`-`という区切り文字は厳密ではありません。任意の句読点を使用できます。例えば、 `'2017-08-24'` 、 `'2017&08&24'` 、 `'2012@12^31'`はすべて有効な日付形式です。唯一の特別な句読点は'.'で、これは整数部と小数部を区切る小数点として扱われます。日付と時刻は`T`または空白で区切ることができます。例えば、 `2017-8-24 10:42:00`と`2017-8-24T10:42:00`は同じ日付と時刻を表します。 - `'YYYYMMDDHHMMSS'`または`'YYMMDDHHMMSS'` : 例えば、 `'20170824104520'`と`'170824104520'`は`'2017-08-24 10:45:20'`とみなされます。ただし、 `'170824304520'`など範囲外の値を指定した場合、有効な日付として扱われません。 `YYYYMMDD HHMMSS` 、 `YYYYMMDD HH:MM:DD` 、 `YYYY-MM-DD HHMMSS`などの誤った形式は挿入に失敗することに注意してください。 - `YYYYMMDDHHMMSS`または`YYMMDDHHMMSS` : これらの形式では、一重引用符や二重引用符は使用されず、数字が使用されることに注意してください。例えば、 `20170824104520`は`'2017-08-24 10:45:20'`と解釈されます。 diff --git a/read-historical-data.md b/read-historical-data.md index b71f6c133bba9..226031f62391c 100644 --- a/read-historical-data.md +++ b/read-historical-data.md @@ -27,7 +27,7 @@ TiDB は、特別なクライアントやドライバーを使用せずに、標 - 変数は`SESSION`スコープ内で有効です。 - その値は`SET`文を使用して変更できます。 - 変数のデータ型はテキストです。 -- この変数はTSO（Timestamp Oracle）とdatetimeを受け入れます。TSOはPDから取得される、グローバルに一意なタイムサービスです。受け入れられるdatetimeの形式は「2016-10-08 16:45:26.999」です。通常、datetimeは秒単位の精度で設定できます（例："2016-10-08 16:45:26"）。 +- この変数はTSO（Timestamp Oracle）とdatetimeを受け入れます。TSOはPDから取得される、グローバルに一意なタイムサービスです。受け入れられるdatetimeの形式は"2016-10-08 16:45:26.999"です。通常、datetimeは秒単位の精度で設定できます（例："2016-10-08 16:45:26"）。 - 変数が設定されると、TiDBはその値をタイムスタンプとしてスナップショットを作成します。これはデータ構造のみを対象としており、オーバーヘッドは発生しません。その後、すべての`SELECT`操作はこのスナップショットからデータを読み取ります。 > **Note:** diff --git a/releases/release-2.1.2.md b/releases/release-2.1.2.md index 747798b08ad2b..e8b0da12b48d8 100644 --- a/releases/release-2.1.2.md +++ b/releases/release-2.1.2.md @@ -1,6 +1,6 @@ --- title: TiDB 2.1.2 Release Notes -summary: TiDB 2.1.2およびTiDB Ansible 2.1.2は、2018年12月22日にリリースされました。このリリースでは、システムの互換性と安定性が向上しています。主なアップデートには、KafkaバージョンのTiDB Binlogとの互換性、ローリングアップデート中の終了メカニズムの改善、およびさまざまな問題の修正が含まれます。PDとTiKVにもアップデートが加えられ、リージョンマージの問題の修正や"DAY"単位の設定形式のサポートなどが行われました。さらに、 TiDB LightningとTiDB Binlogアップデートされ、新機能のサポートとボトルネックの解消が図られました。 +summary: TiDB 2.1.2およびTiDB Ansible 2.1.2は、2018年12月22日にリリースされました。このリリースでは、システムの互換性と安定性が向上しています。主なアップデートには、KafkaバージョンのTiDB Binlogとの互換性、ローリングアップデート中の終了メカニズムの改善、およびさまざまな問題の修正が含まれます。PDとTiKVにもアップデートが加えられ、リージョンマージの問題の修正や'DAY'単位の設定形式のサポートなどが行われました。さらに、 TiDB LightningとTiDB Binlogアップデートされ、新機能のサポートとボトルネックの解消が図られました。 --- # TiDB 2.1.2 リリースノート {#tidb-2-1-2-release-notes} diff --git a/releases/release-3.0.16.md b/releases/release-3.0.16.md index 4778ee86e5466..68c5463f66c5a 100644 --- a/releases/release-3.0.16.md +++ b/releases/release-3.0.16.md @@ -1,6 +1,6 @@ --- title: TiDB 3.0.16 Release Notes -summary: TiDB 3.0.16は2020年7月3日にリリースされました。このリリースには、"is null"フィルター条件のサポート、SQLタイムアウト問題への対応、スロークエリログ内の機密情報の削除などの改善が含まれています。バグ修正には、データの不整合の問題の解決、panic問題の修正、JSON比較およびクエリ結果のエラーへの対応が含まれます。TiKVとPDについても、ストアハートビート、ピアの削除、エラー処理に関するバグ修正が行われました。 +summary: TiDB 3.0.16は2020年7月3日にリリースされました。このリリースには、'is null'フィルター条件のサポート、SQLタイムアウト問題への対応、スロークエリログ内の機密情報の削除などの改善が含まれています。バグ修正には、データの不整合の問題の解決、panic問題の修正、JSON比較およびクエリ結果のエラーへの対応が含まれます。TiKVとPDについても、ストアハートビート、ピアの削除、エラー処理に関するバグ修正が行われました。 --- # TiDB 3.0.16 リリースノート {#tidb-3-0-16-release-notes} diff --git a/releases/release-3.1.2.md b/releases/release-3.1.2.md index 9f93eef88b162..066627a4419ab 100644 --- a/releases/release-3.1.2.md +++ b/releases/release-3.1.2.md @@ -1,6 +1,6 @@ --- title: TiDB 3.1.2 Release Notes -summary: TiDB 3.1.2は2020年6月4日にリリースされました。バグ修正には、S3およびGCSを使用したバックアップおよびリストア時のエラー処理、およびリストア中の"DefaultNotFound"エラーが含まれます。バックアップ＆リストア（BR）などのツールは、ネットワーク状態が悪い場合に自動的に再試行するようになり、リストアの失敗やデータ損失の問題を修正し、S3ストレージを使用したサーバー側暗号化のためのAWS KMSをサポートします。 +summary: TiDB 3.1.2は2020年6月4日にリリースされました。バグ修正には、S3およびGCSを使用したバックアップおよびリストア時のエラー処理、およびリストア中の`DefaultNotFound`エラーが含まれます。バックアップ＆リストア（BR）などのツールは、ネットワーク状態が悪い場合に自動的に再試行するようになり、リストアの失敗やデータ損失の問題を修正し、S3ストレージを使用したサーバー側暗号化のためのAWS KMSをサポートします。 --- # TiDB 3.1.2 リリースノート {#tidb-3-1-2-release-notes} diff --git a/releases/release-4.0.7.md b/releases/release-4.0.7.md index 3daa1db9b2e94..5e49f7172d8a6 100644 --- a/releases/release-4.0.7.md +++ b/releases/release-4.0.7.md @@ -1,6 +1,6 @@ --- title: TiDB 4.0.7 Release Notes -summary: TiDB 4.0.7は2020年9月29日にリリースされました。新機能には、PDクライアントへの"GetAllMembers"関数の追加と、TiDB Dashboardでのメトリクス関係グラフの生成のサポートが含まれます。TiDB、TiKV、PD、 TiFlash、および各種ツールに改善が行われました。また、TiDB、TiKV、PD、 TiFlash、およびBackup & RestoreやDumplingなどのツールのバグ修正も実装されました。 +summary: TiDB 4.0.7は2020年9月29日にリリースされました。新機能には、PDクライアントへの`GetAllMembers`関数の追加と、TiDB Dashboardでのメトリクス関係グラフの生成のサポートが含まれます。TiDB、TiKV、PD、 TiFlash、および各種ツールに改善が行われました。また、TiDB、TiKV、PD、 TiFlash、およびBackup & RestoreやDumplingなどのツールのバグ修正も実装されました。 --- # TiDB 4.0.7 リリースノート {#tidb-4-0-7-release-notes} diff --git a/releases/release-5.1.0.md b/releases/release-5.1.0.md index 315d47ed78c8e..2cbb36cafdf42 100644 --- a/releases/release-5.1.0.md +++ b/releases/release-5.1.0.md @@ -65,7 +65,7 @@ TiDB バージョン: 5.1.0 - TiDB のローリングアップグレード中は`alter table ... modify column`や`alter table ... change column`のようなステートメントを実行しないでください。 - バージョン5.1以降、各テーブルのTiFlashレプリカを作成する際に、システムテーブルのレプリカを設定する機能はサポートされなくなりました。クラスタをアップグレードする前に、関連するシステムテーブルのレプリカをクリアする必要があります。クリアしないと、アップグレードは失敗します。 - TiCDC の`cdc cli changefeed`コマンドの`--sort-dir`は非推奨です。代わりに、 `cdc server`コマンドで`--sort-dir` を設定できます。 [#1795](https://github.com/pingcap/tiflow/pull/1795) -- TiDB 5.1 にアップグレードした後、TiDB が「function READ ONLY has only noop implementation」というエラーを返す場合、 [`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)の値を`ON`に設定することで、TiDB がこのエラーを無視するようにできます。これは、MySQL の`read_only`変数が TiDB ではまだ有効になっていないためです (TiDB では'noop'動作です)。したがって、この変数が TiDB で設定されていても、TiDB クラスタにデータを書き込むことができます。 +- TiDB 5.1 にアップグレードした後、TiDB が"function READ ONLY has only noop implementation"というエラーを返す場合、 [`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)の値を`ON`に設定することで、TiDB がこのエラーを無視するようにできます。これは、MySQL の`read_only`変数が TiDB ではまだ有効になっていないためです (TiDB では'noop'動作です)。したがって、この変数が TiDB で設定されていても、TiDB クラスタにデータを書き込むことができます。 ## 新機能 {#new-features} diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md index 42e51b6bcf828..9ee9e2d466d9d 100644 --- a/releases/release-6.0.0-dmr.md +++ b/releases/release-6.0.0-dmr.md @@ -213,7 +213,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - 指定した時間から移行タスクを開始することをサポート - 移行タスクに新しいパラメータ`--start-time`が追加されました。"2021-10-21 00:01:00"または"2021-10-21T00:01:00"の形式で時間を定義できます。 + 移行タスクに新しいパラメータ`--start-time`が追加されました。'2021-10-21 00:01:00'または'2021-10-21T00:01:00'の形式で時間を定義できます。 この機能は、シャードMySQLインスタンスから増分データを移行およびマージするシナリオで特に役立ちます。具体的には、増分移行タスクで各ソースにbinlog開始ポイントを設定する必要はありません。代わりに、 `safe-mode`の`--start-time`パラメータを使用することで、増分移行タスクを迅速に作成できます。 diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md index 7e32e43f5318d..1746973b89217 100644 --- a/releases/release-6.1.1.md +++ b/releases/release-6.1.1.md @@ -1,6 +1,6 @@ --- title: TiDB 6.1.1 Release Notes -summary: TiDB 6.1.1は2022年9月1日にリリースされました。変更点には、大文字と小文字を区別しない`SHOW DATABASES LIKE`ステートメント、「tidb_enable_outer_join_reorder」のデフォルト値の変更、オプティマイザとメトリクスレスポンスの圧縮の改善が含まれます。バグ修正では、`INL_HASH_JOIN`のハング、UPDATE`文実行中のパニック、クエリ結果の誤りなどの問題が修正されています。その他の変更点には、異なる品質基準に対するマルチレベルサポートと、「TiDB-community-toolkit」バイナリパッケージへの追加が含まれます。 +summary: TiDB 6.1.1は2022年9月1日にリリースされました。変更点には、大文字と小文字を区別しない`SHOW DATABASES LIKE`ステートメント、`tidb_enable_outer_join_reorder`のデフォルト値の変更、オプティマイザとメトリクスレスポンスの圧縮の改善が含まれます。バグ修正では、`INL_HASH_JOIN`のハング、UPDATE`文実行中のパニック、クエリ結果の誤りなどの問題が修正されています。その他の変更点には、異なる品質基準に対するマルチレベルサポートと、`TiDB-community-toolkit`バイナリパッケージへの追加が含まれます。 --- # TiDB 6.1.1 Release Notes {#tidb-6-1-1-release-notes} diff --git a/sql-plan-management.md b/sql-plan-management.md index 13c4379935e9f..38974e5f96976 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -345,7 +345,7 @@ DROP [GLOBAL | SESSION] BINDING FOR SQL DIGEST StringLiteralOrUserVariableList; > **Note:** > -> `DROP GLOBAL BINDING`を実行すると、現在の tidb-server インスタンスのキャッシュ内のバインディングが削除され、システムテーブル内の対応する行のステータスが"deleted"に変更されます。この文はシステムテーブル内のレコードを直接削除しません。これは、他の tidb-server インスタンスがキャッシュ内の対応するバインディングを削除するために"deleted"ステータスを読み取る必要があるためです。これらのシステムテーブル内の"deleted"ステータスのレコードについては、100 `bind-info-lease` (デフォルト値は`3s`で、合計`300s` ) 間隔ごとに、バックグラウンドスレッドが 10 `bind-info-lease`前の`update_time`のバインディングの再利用とクリアの操作をトリガーします (すべての tidb-server インスタンスが"deleted"ステータスを読み取り、キャッシュを更新できるようにするため)。 +> `DROP GLOBAL BINDING`を実行すると、現在の tidb-server インスタンスのキャッシュ内のバインディングが削除され、システムテーブル内の対応する行のステータスが'deleted'に変更されます。この文はシステムテーブル内のレコードを直接削除しません。これは、他の tidb-server インスタンスがキャッシュ内の対応するバインディングを削除するために'deleted'ステータスを読み取る必要があるためです。これらのシステムテーブル内の'deleted'ステータスのレコードについては、100 `bind-info-lease` (デフォルト値は`3s`で、合計`300s` ) 間隔ごとに、バックグラウンドスレッドが 10 `bind-info-lease`前の`update_time`のバインディングの再利用とクリアの操作をトリガーします (すべての tidb-server インスタンスが'deleted'ステータスを読み取り、キャッシュを更新できるようにするため)。 ### バインディングステータスの変更 {#change-binding-status} diff --git a/stale-read.md b/stale-read.md index e6abce1a97cdf..b90130d7e9909 100644 --- a/stale-read.md +++ b/stale-read.md @@ -31,7 +31,7 @@ TiDB は、次のようにステートメントレベル、セッションレベ - ステートメントレベル - 正確な時点の指定（**推奨**）：TiDB が特定の時点からグローバルに一貫性のあるデータを分離レベルに違反することなく読み取る必要がある場合は、クエリ文でその時点の対応するタイムスタンプを指定できます。詳細な使用方法については、 [`AS OF TIMESTAMP`句](/as-of-timestamp.md#syntax)を参照してください。 - - 時間範囲の指定：TiDB が分離レベルに違反することなく、特定の時間範囲内で可能な限り新しいデータを読み取る必要がある場合、クエリ文で時間範囲を指定できます。指定された時間範囲内で、TiDB は適切なタイムスタンプを選択して対応するデータを読み取ります。"Suitable"とは、このタイムスタンプより前に開始され、アクセスされたレプリカでコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセスされたレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされないことを意味します。詳細な使用方法については、 [`AS OF TIMESTAMP`句](/as-of-timestamp.md#syntax)および[`TIDB_BOUNDED_STALENESS`関数](/as-of-timestamp.md#syntax)の概要を参照してください。 + - 時間範囲の指定：TiDB が分離レベルに違反することなく、特定の時間範囲内で可能な限り新しいデータを読み取る必要がある場合、クエリ文で時間範囲を指定できます。指定された時間範囲内で、TiDB は適切なタイムスタンプを選択して対応するデータを読み取ります。「適切」とは、このタイムスタンプより前に開始され、アクセスされたレプリカでコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセスされたレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされないことを意味します。詳細な使用方法については、 [`AS OF TIMESTAMP`句](/as-of-timestamp.md#syntax)および[`TIDB_BOUNDED_STALENESS`関数](/as-of-timestamp.md#syntax)の概要を参照してください。 - セッションレベル - 時間範囲の指定：セッションにおいて、後続のクエリでTiDBが分離レベルに違反することなく、指定された時間範囲内で可能な限り新しいデータを読み取る必要がある場合は、システム変数`tidb_read_staleness`を設定することで時間範囲を指定できます。詳細な使用方法については、 [`tidb_read_staleness`](/tidb-read-staleness.md)を参照してください。 diff --git a/statement-summary-tables.md b/statement-summary-tables.md index 26c1b7bb2f911..883f2a5b1cd6c 100644 --- a/statement-summary-tables.md +++ b/statement-summary-tables.md @@ -25,7 +25,7 @@ SQL のパフォーマンス問題をより適切に処理するために、MySQ `statements_summary`は`information_schema`内のシステムテーブルです。 `statements_summary`は、SQL文をリソースグループ、SQL ダイジェスト、およびプランダイジェストごとにグループ化し、各 SQL カテゴリの統計情報を提供します。 -ここでいう"SQL digest"とは、スローログで使用されるものと同じ意味で、正規化されたSQL文から計算される一意の識別子です。正規化プロセスでは定数や空白文字は無視され、大文字と小文字は区別されません。したがって、構文が一貫しているステートメントは同じダイジェストを持ちます。例： +ここでいう「SQLダイジェスト」とは、スローログで使用されるものと同じ意味で、正規化されたSQL文から計算される一意の識別子です。正規化プロセスでは定数や空白文字は無視され、大文字と小文字は区別されません。したがって、構文が一貫しているステートメントは同じダイジェストを持ちます。例： ```sql SELECT * FROM employee WHERE id IN (1, 2, 3) AND salary BETWEEN 1000 AND 2000; @@ -38,7 +38,7 @@ select * from EMPLOYEE where ID in (4, 5) and SALARY between 3000 and 4000; select * from employee where id in (...) and salary between ? and ?; ``` -ここでいう"plan digest"とは、正規化された実行計画によって計算される一意の識別子を指します。正規化処理では定数は無視されます。同じSQL文でも実行計画が異なる場合があるため、異なるカテゴリに分類されることがあります。同じカテゴリのSQL文は、同じ実行計画を持ちます。 +ここでいう「プランダイジェスト」とは、正規化された実行計画によって計算される一意の識別子を指します。正規化処理では定数は無視されます。同じSQL文でも実行計画が異なる場合があるため、異なるカテゴリに分類されることがあります。同じカテゴリのSQL文は、同じ実行計画を持ちます。 `statements_summary`は、SQL モニタリングメトリックの集計結果が格納されます。一般的に、各モニタリングメトリックには、最大値と平均値が含まれます。たとえば、実行レイテンシーメトリックは、 `AVG_LATENCY` (平均レイテンシー) と`MAX_LATENCY` (最大レイテンシー) の 2つのフィールドに対応します。 diff --git a/system-variables.md b/system-variables.md index 7581690ae405b..f8db2d9946100 100644 --- a/system-variables.md +++ b/system-variables.md @@ -6951,7 +6951,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `SYSTEM` -- この変数は現在のタイムゾーンを返します。値は、"-8:00"のようなオフセット、または"America/Los_Angeles"のような名前付きゾーンのいずれかで指定できます。 +- この変数は現在のタイムゾーンを返します。値は、'-8:00'のようなオフセット、または'America/Los_Angeles'のような名前付きゾーンのいずれかで指定できます。 - 値`SYSTEM`は、タイムゾーンがシステムホストと同じである必要があることを意味します。システムホストのタイムゾーンは、 [`system_time_zone`](#system_time_zone)変数で取得できます。 ### timestamp @@ -7103,7 +7103,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 適用範囲：なし - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `8.0.11-TiDB-` (tidb バージョン) -- この変数は、MySQLのバージョンに続いてTiDBのバージョンを返します。例えば、"8.0.11-TiDB-v8.5.4"のようになります。 +- この変数は、MySQLのバージョンに続いてTiDBのバージョンを返します。例えば、'8.0.11-TiDB-v8.5.4'のようになります。 ### version_comment diff --git a/tidb-cloud/data-service-api-key.md b/tidb-cloud/data-service-api-key.md index b2291f652e833..0c8baf8d571f6 100644 --- a/tidb-cloud/data-service-api-key.md +++ b/tidb-cloud/data-service-api-key.md @@ -7,7 +7,7 @@ summary: データアプリのAPIキーの作成、編集、削除方法を学 TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access_authentication)と[ダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)の両方をサポートしています。 -- [基本認証](https://en.wikipedia.org/wiki/Basic_access_authentication)は、暗号化されていない Base64 エンコーディングを使用して、公開キーと秘密キーを送信します。 HTTPS により通信のセキュリティが確保されます。詳細については、 [RFC 7617 - "Basic"HTTP認証方式](https://datatracker.ietf.org/doc/html/rfc7617)を参照してください。 +- [基本認証](https://en.wikipedia.org/wiki/Basic_access_authentication)は、暗号化されていない Base64 エンコーディングを使用して、公開キーと秘密キーを送信します。 HTTPS により通信のセキュリティが確保されます。詳細については、 [RFC 7617 - 'Basic'HTTP認証方式](https://datatracker.ietf.org/doc/html/rfc7617)を参照してください。 - [ダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)ネットワーク送信前に公開キー、秘密キー、サーバー提供のノンス値、HTTP メソッド、および要求された URI をハッシュすることにより、追加のセキュリティレイヤーを提供します。これにより、秘密キーが暗号化され、秘密キーが平文で送信されるのを防ぎます。詳細については、 [RFC 7616 - HTTPダイジェストアクセス認証](https://datatracker.ietf.org/doc/html/rfc7616)を参照してください。 > **Note:** diff --git a/tidb-cloud/import-csv-files-serverless.md b/tidb-cloud/import-csv-files-serverless.md index f4c2a8b766c26..cf05985a6529a 100644 --- a/tidb-cloud/import-csv-files-serverless.md +++ b/tidb-cloud/import-csv-files-serverless.md @@ -27,7 +27,7 @@ summary: Amazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object St - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`と`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 - - TiDB Cloudは、 `.gzip` 、 `.gz` 、 `.zstd` 、 `.zst` `.snappy`の各形式の圧縮ファイルのインポートをサポートしています。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。この形式では、 `${suffix}`は省略可能で、"000001"などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 + - TiDB Cloudは、 `.gzip` 、 `.gz` 、 `.zstd` 、 `.zst` `.snappy`の各形式の圧縮ファイルのインポートをサポートしています。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。この形式では、 `${suffix}`は省略可能で、'000001'などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 > **Note:** > diff --git a/tidb-cloud/integrate-tidbcloud-with-n8n.md b/tidb-cloud/integrate-tidbcloud-with-n8n.md index 547d867244d5b..b7561a417eb79 100644 --- a/tidb-cloud/integrate-tidbcloud-with-n8n.md +++ b/tidb-cloud/integrate-tidbcloud-with-n8n.md @@ -162,7 +162,7 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ #### メッセージを作成する {#build-message} -1. "RSS Feed Read"ノードの右側にある**+**をクリックします。 +1. RSS Feed Readノードの右側にある**+**をクリックします。 2. `code`を検索してワークスペースに追加します。 3. `Run Once for All Items`モードを選択してください。 4. **JavaScript**ボックスに、以下のコードをコピー＆ペーストしてください。 diff --git a/tidb-cloud/premium/import-csv-files-premium.md b/tidb-cloud/premium/import-csv-files-premium.md index 76b83818a2c15..07687a9091d64 100644 --- a/tidb-cloud/premium/import-csv-files-premium.md +++ b/tidb-cloud/premium/import-csv-files-premium.md @@ -28,7 +28,7 @@ summary: Amazon S3またはAlibaba Cloud Object Storage Service（OSS）からCS - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`や`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 - - TiDB Cloud Premium は、 `.gzip` 、 `.gz` 、 `.zst` `.zstd` 、{ `.snappy`の形式で圧縮ファイルをインポートできます。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`省略可能で、"000001"などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 + - TiDB Cloud Premium は、 `.gzip` 、 `.gz` 、 `.zst` `.zstd` 、{ `.snappy`の形式で圧縮ファイルをインポートできます。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`省略可能で、'000001'などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 > **Note:** > diff --git a/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md b/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md index 6e800bb4d3887..da62ec1035d3b 100644 --- a/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md +++ b/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md @@ -19,7 +19,7 @@ summary: 2023年 11月 14日のTiDB Cloud Dedicated Scale 機能メンテナン ## インパクト {#impact} -メンテナンス期間中は、 [vCPUとRAMを変更する](https://docs.pingcap.com/tidbcloud/scale-tidb-cluster#change-vcpu-and-ram)無効化され、専用クラスタの vCPU と RAM を変更することはできません。ただし、 "Modify Cluster"ページでノード番号またはストレージを変更することは可能です。TiDB クラスタは通常通りデータの読み取りと書き込みを行うため、オンラインビジネスへの悪影響はありません。 +メンテナンス期間中は、 [vCPUとRAMを変更する](https://docs.pingcap.com/tidbcloud/scale-tidb-cluster#change-vcpu-and-ram)無効化され、専用クラスタの vCPU と RAM を変更することはできません。ただし、 **Modify Cluster**ページでノード番号またはストレージを変更することは可能です。TiDB クラスタは通常通りデータの読み取りと書き込みを行うため、オンラインビジネスへの悪影響はありません。 ### TiDB Cloudコンソール UI の影響を受ける機能 {#affected-features-of-tidb-cloud-console-ui} diff --git a/tidb-cloud/releases/release-notes-2023.md b/tidb-cloud/releases/release-notes-2023.md index cc0bc7e24d56c..64ed6cf2a0aa1 100644 --- a/tidb-cloud/releases/release-notes-2023.md +++ b/tidb-cloud/releases/release-notes-2023.md @@ -249,7 +249,7 @@ summary: 2023年のTiDB Cloudのリリースノートについて説明します - [Data Service（ベータ版）](https://tidbcloud.com/project/data-service)では基本認証がサポートされるようになりました。 - ["Basic" HTTP認証](https://datatracker.ietf.org/doc/html/rfc7617)を使用したリクエストでは、公開鍵をユーザー名として、秘密鍵をパスワードとして提供できます。ダイジェスト認証と比較して、基本認証はよりシンプルで、Data Serviceエンドポイントを呼び出す際に簡単に使用できます。 + ['Basic' HTTP認証](https://datatracker.ietf.org/doc/html/rfc7617)を使用したリクエストでは、公開鍵をユーザー名として、秘密鍵をパスワードとして提供できます。ダイジェスト認証と比較して、基本認証はよりシンプルで、Data Serviceエンドポイントを呼び出す際に簡単に使用できます。 詳細については[エンドポイントを呼び出す](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)を参照してください。 @@ -478,7 +478,7 @@ summary: 2023年のTiDB Cloudのリリースノートについて説明します - 簡素化と明確化を目指し、製品名を更新しました。 - - 「TiDB Cloud Serverless Tier」は「TiDB Cloud Serverless」という名前になりました。 + - "TiDB Cloud Serverless Tier"は"TiDB Cloud Serverless"という名前になりました。 - "TiDB Cloud Dedicated Tier"は"TiDB Cloud Dedicated"という名前になりました。 - "TiDB On-Premises"は"TiDB Self-Managed"という名前になりました。 diff --git a/tidb-cloud/tidb-cloud-auditing.md b/tidb-cloud/tidb-cloud-auditing.md index b7440651f6b56..2ee09af8b33b4 100644 --- a/tidb-cloud/tidb-cloud-auditing.md +++ b/tidb-cloud/tidb-cloud-auditing.md @@ -43,7 +43,7 @@ TiDB Cloudは、 TiDB Cloud Dedicatedクラスタの監査ログをクラウド > **Note:** > -> AWS にデプロイされた TiDB クラスターでは、データベース監査ログを有効にする際に、監査ログファイルをTiDB Cloudに保存することを選択できます。現在、この機能はリクエストに応じてのみ利用可能です。この機能をリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**?**をクリックし、 **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に進みます。チケットを作成し、 **Description**フィールドに「監査ログファイルをTiDB Cloudに保存する申請」と入力して、 **Submit**をクリックします。 +> AWS にデプロイされた TiDB クラスターでは、データベース監査ログを有効にする際に、監査ログファイルをTiDB Cloudに保存することを選択できます。現在、この機能はリクエストに応じてのみ利用可能です。この機能をリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**?**をクリックし、 **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に進みます。チケットを作成し、 **Description**フィールドに"Apply to store audit log files in TiDB Cloud"と入力して、 **Submit**をクリックします。 ### AWSの監査ログを有効にする {#enable-audit-logging-for-aws} diff --git a/tidb-lightning/tidb-lightning-command-line-full.md b/tidb-lightning/tidb-lightning-command-line-full.md index 660105ed69470..bb958368ed89e 100644 --- a/tidb-lightning/tidb-lightning-command-line-full.md +++ b/tidb-lightning/tidb-lightning-command-line-full.md @@ -21,7 +21,7 @@ TiDB Lightning は、設定ファイルまたはコマンドラインから設 | `-L ` | ログレベル：`debug` 、 `info` 、 `warn` 、 `error` 、または`fatal` 。デフォルトは`info` 。 | `lightning.level` | | `-f ` | [テーブルフィルタルール](/table-filter.md) 。複数回指定できます。 | `mydumper.filter` | | `--backend ` | インポートモードを選択します。`local`は[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を、 `tidb`は[論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)を指します。 | `tikv-importer.backend` | -| `--log-file ` | ログファイルのパス。デフォルトでは`/tmp/lightning.log.{timestamp}`です。"-"に設定すると、ログファイルは標準出力に出力されます。 | `lightning.log-file` | +| `--log-file ` | ログファイルのパス。デフォルトでは`/tmp/lightning.log.{timestamp}`です。'-'に設定すると、ログファイルは標準出力に出力されます。 | `lightning.log-file` | | `--status-addr ` | TiDB Lightning HTTPサーバーのリスニング アドレス | `lightning.status-addr` | | `--pd-urls ` | PDエンドポイントアドレス。v7.6.0以降、TiDBは複数のPDアドレスの設定をサポートします。 | `tidb.pd-addr` | | `--tidb-host ` | TiDBサーバーホスト | `tidb.host` | diff --git a/tiflash/tiflash-mintso-scheduler.md b/tiflash/tiflash-mintso-scheduler.md index 88a6c89f93135..01710ad73c9f0 100644 --- a/tiflash/tiflash-mintso-scheduler.md +++ b/tiflash/tiflash-mintso-scheduler.md @@ -55,7 +55,7 @@ EXPLAIN SELECT count(*) FROM t0 a JOIN t0 b ON a.id = b.id; ソフトリミットとハードリミットは、デッドロックを回避するために次のように連携して機能します。ソフトリミットは、すべてのクエリで使用されるスレッドの総数を制限し、スレッドリソースの枯渇を回避しながらリソースを最大限に活用できるようにします。ハードリミットは、いかなる状況においても、システム内の少なくとも1つのクエリがソフトリミットを破り、スレッドリソースを取得して実行を継続できるようにすることで、デッドロックを回避します。スレッド数がハードリミットを超えない限り、システム内には常に1つのクエリが存在し、そのクエリのすべてのMPPタスクが正常に実行され、デッドロックを回避します。 -MinTSOスケジューラの目的は、システムスレッドの数を制御しながら、システム内に常に1つの特別なクエリが存在し、そのクエリですべてのMPPタスクをスケジュールできるようにすることです。MinTSOスケジューラは完全に分散されたスケジューラであり、各TiFlashノードは自身の情報のみに基づいてMPPタスクをスケジュールします。したがって、 TiFlashノード上のすべてのMinTSOスケジューラは同じ"special"クエリを識別する必要があります。TiDBでは、各クエリは読み取りタイムスタンプ（ `start_ts` ）を持ち、MinTSOスケジューラは現在のTiFlashノード上で最も小さい`start_ts`を持つクエリを"special"クエリとして定義します。グローバル最小値はローカル最小値でもあるという原則に基づき、すべてのTiFlashノードによって選択される"special"クエリは、MinTSOクエリと呼ばれる同じである必要があります。 +MinTSOスケジューラの目的は、システムスレッドの数を制御しながら、システム内に常に1つの特別なクエリが存在し、そのクエリですべてのMPPタスクをスケジュールできるようにすることです。MinTSOスケジューラは完全に分散されたスケジューラであり、各TiFlashノードは自身の情報のみに基づいてMPPタスクをスケジュールします。したがって、 TiFlashノード上のすべてのMinTSOスケジューラは同じ「特別な」クエリを識別する必要があります。TiDBでは、各クエリは読み取りタイムスタンプ（ `start_ts` ）を持ち、MinTSOスケジューラは現在のTiFlashノード上で最も小さい`start_ts`を持つクエリを「特別な」クエリとして定義します。グローバル最小値はローカル最小値でもあるという原則に基づき、すべてのTiFlashノードによって選択される「特別な」クエリは、MinTSOクエリと呼ばれる同じである必要があります。 MinTSO スケジューラのスケジューリング プロセスは次のとおりです。 diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index cff97b2051558..1e059f08f0794 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -58,7 +58,7 @@ SQL ポートのコンフィグレーション。 - デフォルト値: `0` - ホットリロードのサポート: はい - 単位: 秒 -- TiProxyがシャットダウンすると、HTTPステータスは"unhealthy"を返しますが、SQLポートは`graceful-wait-before-shutdown`秒間は新規接続を受け付けます。その後、新規接続は拒否され、クライアントの負荷が増大します。クライアントとTiProxyの間に他のプロキシ（NLBなど）が存在しない場合は、この値を`0`に設定することをお勧めします。 +- TiProxyがシャットダウンすると、HTTPステータスはunhealthyを返しますが、SQLポートは`graceful-wait-before-shutdown`秒間は新規接続を受け付けます。その後、新規接続は拒否され、クライアントの負荷が増大します。クライアントとTiProxyの間に他のプロキシ（NLBなど）が存在しない場合は、この値を`0`に設定することをお勧めします。 #### `graceful-close-conn-timeout` {#graceful-close-conn-timeout} diff --git a/tiup/tiup-command-mirror-merge.md b/tiup/tiup-command-mirror-merge.md index 22ea39ac0269b..b15c02374150d 100644 --- a/tiup/tiup-command-mirror-merge.md +++ b/tiup/tiup-command-mirror-merge.md @@ -1,6 +1,6 @@ --- title: tiup mirror merge -summary: "tiup mirror merge"コマンドは、1つまたは複数のミラーを現在のミラーにマージします。実行条件には、既存の所有者IDと対応する秘密鍵が含まれます。 +summary: `tiup mirror merge`コマンドは、1つまたは複数のミラーを現在のミラーにマージします。実行条件には、既存の所有者IDと対応する秘密鍵が含まれます。 --- # tiup mirror merge {#tiup-mirror-merge} diff --git a/tiup/tiup-command-telemetry.md b/tiup/tiup-command-telemetry.md index 55bc0f2276146..6b8e3527edee2 100644 --- a/tiup/tiup-command-telemetry.md +++ b/tiup/tiup-command-telemetry.md @@ -1,6 +1,6 @@ --- title: tiup telemetry -summary: TiUPテレメトリはv1.11.3でデフォルトで無効化されました。使用状況情報は収集されず、PingCAPと共有もされません。有効化すると、テレメトリ識別子とコマンド実行ステータスが共有されます。クラスタの詳細は共有されません。"tiup telemetry"コマンドを使用し、status、reset、enable、disableなどのサブコマンドでテレメトリを制御してください。 +summary: TiUPテレメトリはv1.11.3でデフォルトで無効化されました。使用状況情報は収集されず、PingCAPと共有もされません。有効化すると、テレメトリ識別子とコマンド実行ステータスが共有されます。クラスタの詳細は共有されません。'tiup telemetry'コマンドを使用し、status、reset、enable、disableなどのサブコマンドでテレメトリを制御してください。 --- # tiup telemetry {#tiup-telemetry} diff --git a/tiup/tiup-component-cluster-display.md b/tiup/tiup-component-cluster-display.md index 2a5511849e1c1..72f937fe204a0 100644 --- a/tiup/tiup-component-cluster-display.md +++ b/tiup/tiup-component-cluster-display.md @@ -1,6 +1,6 @@ --- title: tiup cluster display -summary: tiup cluster displayコマンドは、クラスタ内の各コンポーネントの動作状況を効率的に表示します。ダッシュボード情報、ノードステータス、CPUおよびメモリ使用率などを表示するオプションが用意されています。出力には、クラスタ名、バージョン、SSHクライアントの種類、ダッシュボードアドレス、ノードの詳細を含む表が含まれます。ノードのサービスステータスは、"Up"、"Down"、"Tombstone"、"Pending Offline"、"Unknown"のいずれかになります。 +summary: tiup cluster displayコマンドは、クラスタ内の各コンポーネントの動作状況を効率的に表示します。ダッシュボード情報、ノードステータス、CPUおよびメモリ使用率などを表示するオプションが用意されています。出力には、クラスタ名、バージョン、SSHクライアントの種類、ダッシュボードアドレス、ノードの詳細を含む表が含まれます。ノードのサービスステータスは、Up、Down、Tombstone、Pending Offline、Unknownのいずれかになります。 --- # tiup cluster display {#tiup-cluster-display} diff --git a/tiup/tiup-component-cluster-meta-restore.md b/tiup/tiup-component-cluster-meta-restore.md index b13dd72e041a2..ae022dd4ffce0 100644 --- a/tiup/tiup-component-cluster-meta-restore.md +++ b/tiup/tiup-component-cluster-meta-restore.md @@ -1,6 +1,6 @@ --- title: tiup cluster meta restore -summary: TiUPメタファイルを復元するには、クラスター名とバックアップファイルのパスを指定して「tiup cluster meta restore」コマンドを使用します。復元操作は現在のメタファイルを上書きするため、ファイルが失われた場合にのみ実行してください。"-h"または"--help"オプションを指定するとヘルプ情報が出力。出力には、 tiup-clusterの実行ログが含まれます。 +summary: TiUPメタファイルを復元するには、クラスター名とバックアップファイルのパスを指定して`tiup cluster meta restore`コマンドを使用します。復元操作は現在のメタファイルを上書きするため、ファイルが失われた場合にのみ実行してください。`-h`または`--help`オプションを指定するとヘルプ情報が出力。出力には、 tiup-clusterの実行ログが含まれます。 --- # tiup cluster meta restore {#tiup-cluster-meta-restore} diff --git a/tiup/tiup-component-cluster-prune.md b/tiup/tiup-component-cluster-prune.md index 762c995b4de9c..471dd3b2e85fa 100644 --- a/tiup/tiup-component-cluster-prune.md +++ b/tiup/tiup-component-cluster-prune.md @@ -1,6 +1,6 @@ --- title: tiup cluster prune -summary: クラスターをスケールアウトする際、 TiUP は一部のコンポーネントのサービスを即時に停止したり、データを削除したりしません。データのスケジューリングが完了するまで待ってから、"tiup cluster prune"コマンドを手動で実行してクリーンアップする必要があります。構文は"tiup cluster prune [flags]"です。オプション"-h, --help"を指定するとヘルプ情報が出力、クリーンアッププロセスのログが出力されます。 +summary: クラスターをスケールアウトする際、 TiUP は一部のコンポーネントのサービスを即時に停止したり、データを削除したりしません。データのスケジューリングが完了するまで待ってから、'tiup cluster prune'コマンドを手動で実行してクリーンアップする必要があります。構文は'tiup cluster prune [flags]'です。オプション'-h, --help'を指定するとヘルプ情報が出力、クリーンアッププロセスのログが出力されます。 --- # tiup cluster prune {#tiup-cluster-prune} diff --git a/tiup/tiup-component-dm-import.md b/tiup/tiup-component-dm-import.md index af106194df3d7..3292b4960e637 100644 --- a/tiup/tiup-component-dm-import.md +++ b/tiup/tiup-component-dm-import.md @@ -1,6 +1,6 @@ --- title: tiup dm import -summary: TiUP DMの"import"コマンドは、DMクラスタをv1.0からv2.0以降のバージョンにアップグレードするために使用されます。このコマンドは、v1.0クラスタからのDMポータルコンポーネントのインポートをサポートしておらず、インポート前に元のクラスタを停止する必要があります。このコマンドはDM v2.0.0-rc.2以降のバージョンへのインポートのみをサポートしており、DM v1.0クラスタを新しいDM v2.0クラスタにインポートするために使用できます。インポート後、クラスタ内のDM-masterノードは1つだけになり、一部のコンポーネントのデプロイメントディレクトリは元のクラスタと異なる場合があります。 +summary: TiUP DMの`import`コマンドは、DMクラスタをv1.0からv2.0以降のバージョンにアップグレードするために使用されます。このコマンドは、v1.0クラスタからのDMポータルコンポーネントのインポートをサポートしておらず、インポート前に元のクラスタを停止する必要があります。このコマンドはDM v2.0.0-rc.2以降のバージョンへのインポートのみをサポートしており、DM v1.0クラスタを新しいDM v2.0クラスタにインポートするために使用できます。インポート後、クラスタ内のDM-masterノードは1つだけになり、一部のコンポーネントのデプロイメントディレクトリは元のクラスタと異なる場合があります。 --- # tiup dm import DM v1.0 のアップグレードのみ {#tiup-dm-import-only-for-upgrading-dm-v10} diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index 9ad0a57e74350..0a773296e205c 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -149,7 +149,7 @@ tiup update cluster 2. [トポロジー](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)設定テンプレートのフォーマットを参照し、トポロジファイルの`server_configs`セクションに変更したいパラメータを入力します。 -3. 変更後、 「: + w + q」と入力して変更を保存し、編集モードを終了します。変更を確定するにはYと入力してください。 +3. 変更後、 : + w + qと入力して変更を保存し、編集モードを終了します。変更を確定するにはYと入力してください。 ### ステップ4：クラスターのDDLとバックアップの状態を確認します {#step-4-check-the-ddl-and-backup-status-of-the-cluster} diff --git a/user-account-management.md b/user-account-management.md index f9fbcfce2a574..664e016e958a3 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -42,7 +42,7 @@ CREATE USER [IF NOT EXISTS] user [IDENTIFIED BY 'auth_string']; CREATE USER 'test'@'127.0.0.1' IDENTIFIED BY 'xxx'; ``` -TiDBアカウント名はユーザー名とホスト名で構成されます。アカウント名の構文は"user_name"@"host_name"です。 +TiDBアカウント名はユーザー名とホスト名で構成されます。アカウント名の構文は'user_name'@'host_name'です。 - `user_name`は大文字と小文字が区別されます。 From 7431e71a83a08a9f614e43a865364e10de480614 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 09:12:58 +0900 Subject: [PATCH 19/56] i18n(ja): keep At Least Once / exactly-once processing as English delivery-semantics terms --- dm/dm-replication-logic.md | 2 +- ticdc/ticdc-canal-json.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dm/dm-replication-logic.md b/dm/dm-replication-logic.md index 4eec71d5ec105..00ced62ea3d7b 100644 --- a/dm/dm-replication-logic.md +++ b/dm/dm-replication-logic.md @@ -152,4 +152,4 @@ DML実行とチェックポイント更新の操作はアトミックではな ### 正確に1回だけ処理 {#exactly-once-processing} -現在、DM は結果整合性のみを保証しており、「正確に1回だけ処理」や「トランザクションの元の順序を維持すること」はサポートしていません。 +現在、DM は結果整合性のみを保証しており、"exactly-once processing"や「トランザクションの元の順序を維持すること」はサポートしていません。 diff --git a/ticdc/ticdc-canal-json.md b/ticdc/ticdc-canal-json.md index a6f78cf875c55..3b67bd6f601cd 100644 --- a/ticdc/ticdc-canal-json.md +++ b/ticdc/ticdc-canal-json.md @@ -138,7 +138,7 @@ TiCDC は、DML データ変更イベントの行を次のようにエンコー TiCDCは、 `enable-tidb-extension`を`true`に設定した場合のみ、WATERMARKイベントを送信します。 `type`フィールドの値は`TIDB_WATERMARK`です。イベントには`_tidb`フィールドが含まれており、このフィールドにはパラメータ`watermarkTs`のみが含まれます。 `watermarkTs`の値は、イベント送信時に記録されるTSOです。 -このタイプのイベントを受信すると、 `commitTs`が`watermarkTs`より小さいすべてのイベントが送信されています。TiCDC は「少なくとも1回」のセマンティクスを提供するため、データが繰り返し送信される可能性があります。その後に`commitTs`が`watermarkTs`より小さいイベントを受信した場合は、このイベントを無視しても問題ありません。 +このタイプのイベントを受信すると、 `commitTs`が`watermarkTs`より小さいすべてのイベントが送信されています。TiCDC は"At Least Once"のセマンティクスを提供するため、データが繰り返し送信される可能性があります。その後に`commitTs`が`watermarkTs`より小さいイベントを受信した場合は、このイベントを無視しても問題ありません。 以下は WATERMARK イベントの例です。 From f5f705e714af15e558c470dbc60331b6f737a93a Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 09:28:35 +0900 Subject: [PATCH 20/56] i18n(ja): move trapped subject particle out of bold span in DDL Owner/DXF sentence --- best-practices/ddl-introduction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index 4352f8ac3fd9c..3fdb99762c6f3 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -28,7 +28,7 @@ TiDBはオンラインDDLをサポートしています。つまり、データ TiDBでは、物理DDL文は"reorg DDL"（再編成DDL）とも呼ばれます。現在、物理DDL文には、 `ADD INDEX`と損失のある列型変更（例えば、 `INT`型から`CHAR`型への変更）のみが含まれます。これらの文の実行には時間がかかり、実行時間はテーブル内のデータ量、マシン構成、アプリケーションのワークロードによって影響を受けます。 - 物理DDL文の実行は、2つの理由からアプリケーションのワークロードに影響を与える可能性があります。1つは、データの読み取りと新規データの書き込みにTiKVのCPUリソースとI/Oリソースを消費することです。もう1つは、 **DDLオーナーとして機能するTiDBノード**、または**TiDB分散実行フレームワーク（DXF）によって`ADD INDEX`タスクを実行するようにスケジュールされたTiDBノードが、**対応する計算を実行するためにTiDBのCPUリソースを消費することです。 + 物理DDL文の実行は、2つの理由からアプリケーションのワークロードに影響を与える可能性があります。1つは、データの読み取りと新規データの書き込みにTiKVのCPUリソースとI/Oリソースを消費することです。もう1つは、 **DDLオーナーとして機能するTiDBノード**、または**TiDB分散実行フレームワーク（DXF）によって`ADD INDEX`タスクを実行するようにスケジュールされたTiDBノード**が、対応する計算を実行するためにTiDBのCPUリソースを消費することです。 > **Note:** > From 3d93d742b5a0b9c1b03d29649d4e6b3a6d8e9318 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 09:34:50 +0900 Subject: [PATCH 21/56] i18n(ja): revert checkpoint to established Japanese glossary term --- dm/dm-pause-task.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dm/dm-pause-task.md b/dm/dm-pause-task.md index 0f4f1eeb94c83..cb107f2f7ff36 100644 --- a/dm/dm-pause-task.md +++ b/dm/dm-pause-task.md @@ -9,7 +9,7 @@ summary: TiDB データ移行でデータ移行タスクを一時停止する方 `pause-task`は`stop-task`と次の点で異なります: -- `pause-task`は移行タスクを一時停止するだけです。タスクのステータス情報（メモリに保持されている）は`query-status`で照会できます。`stop-task`は移行タスクを終了し、このタスクに関連するすべての情報をメモリから削除します。つまり、 `query-status`を使用してステータス情報を照会することはできません。"checkpoint"のような`dm_meta`や、下流に移行済みのデータは削除されません。 +- `pause-task`は移行タスクを一時停止するだけです。タスクのステータス情報（メモリに保持されている）は`query-status`で照会できます。`stop-task`は移行タスクを終了し、このタスクに関連するすべての情報をメモリから削除します。つまり、 `query-status`を使用してステータス情報を照会することはできません。「チェックポイント」のような`dm_meta`や、下流に移行済みのデータは削除されません。 - `pause-task`を実行して移行タスクを一時停止した場合、同じ名前の新しいタスクを開始することはできません。また、一時停止したタスクは既に存在するため、そのタスクのリレーログを削除することもできません。`stop-task`を実行してタスクを停止した場合、同じ名前の新しいタスクを開始できます。また、停止したタスクは既に存在しないため、そのタスクのリレーログを削除することができます。 - `pause-task`は通常、トラブルシューティングのためにタスクを一時停止するために使用され、 `stop-task`は移行タスクを永続的に削除するか、 `start-task`と連携して構成情報を更新するために使用されます。 From 85d7c74894de0509b4a22f6f607b814da8547b1e Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 09:37:54 +0900 Subject: [PATCH 22/56] i18n(ja): revert pessimistic/optimistic mode definitional quotes to established Japanese terms --- dm/feature-shard-merge-optimistic.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md index 12db57b903ede..7bf4fab4e91fa 100644 --- a/dm/feature-shard-merge-optimistic.md +++ b/dm/feature-shard-merge-optimistic.md @@ -13,11 +13,11 @@ summary: DM が楽観的モードでシャードテーブルからデータを ## 背景 {#background} -DMは、シャーディングDDLと呼ばれるシャーディングテーブルへのDDL文のオンライン実行をサポートしており、デフォルトで"pessimistic mode"を使用します。このモードでは、上流のシャーディングテーブルでDDL文が実行されると、そのテーブルのデータ移行は、他のすべてのシャーディングテーブルで同じDDL文が実行されるまで一時停止されます。その後、下流のシャーディングテーブルで同じDDL文が実行され、データ移行が再開されます。 +DMは、シャーディングDDLと呼ばれるシャーディングテーブルへのDDL文のオンライン実行をサポートしており、デフォルトで「悲観的モード」を使用します。このモードでは、上流のシャーディングテーブルでDDL文が実行されると、そのテーブルのデータ移行は、他のすべてのシャーディングテーブルで同じDDL文が実行されるまで一時停止されます。その後、下流のシャーディングテーブルで同じDDL文が実行され、データ移行が再開されます。 悲観的モードでは、下流に移行されるデータが常に正しいことが保証されますが、データ移行が一時停止されるため、上流でのA/B変更には適していません。場合によっては、ユーザーは単一のシャードテーブルでDDL文の実行に長い時間を費やし、検証期間が経過した後に他のシャードテーブルのスキーマを変更することがあります。悲観的モードでは、これらのDDL文がデータ移行をブロックし、多くのbinlogイベントが蓄積される原因となります。 -そのため、"optimistic mode"が必要になります。このモードでは、シャードテーブルに対して実行されたDDL文は、他のシャードテーブルと互換性のある文に自動的に変換され、すぐに下流に移行されます。これにより、DDL文がシャードテーブルによるDML移行の実行をブロックすることはありません。 +そのため、「楽観的モード」が必要になります。このモードでは、シャードテーブルに対して実行されたDDL文は、他のシャードテーブルと互換性のある文に自動的に変換され、すぐに下流に移行されます。これにより、DDL文がシャードテーブルによるDML移行の実行をブロックすることはありません。 ## 楽観的モードのコンフィグレーション {#configuration-of-the-optimistic-mode} From 60ab0616e3f1cd5bc511df7dc05e0baa8e294af1 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 09:40:06 +0900 Subject: [PATCH 23/56] i18n(ja): revert sharding group definitional quote to established Japanese term --- dm/shard-merge-best-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dm/shard-merge-best-practices.md b/dm/shard-merge-best-practices.md index b6b853518873a..44bd9863e5191 100644 --- a/dm/shard-merge-best-practices.md +++ b/dm/shard-merge-best-practices.md @@ -9,7 +9,7 @@ summary: シャードマージのシナリオにおけるデータ移行のベ ## 別のデータ移行タスクを使用する {#use-a-separate-data-migration-task} -[シャードテーブルからのデータのマージと移行](/dm/feature-shard-merge-pessimistic.md#principles)ドキュメントでは、"sharding group"の定義が次のように示されています。シャーディンググループは、同じダウンストリームテーブルにマージおよび移行する必要があるすべてのアップストリームテーブルで構成されます。 +[シャードテーブルからのデータのマージと移行](/dm/feature-shard-merge-pessimistic.md#principles)ドキュメントでは、「シャーディンググループ」の定義が次のように示されています。シャーディンググループは、同じダウンストリームテーブルにマージおよび移行する必要があるすべてのアップストリームテーブルで構成されます。 現在のシャーディングDDLメカニズムには、異なるシャーディングされたテーブルにおけるDDL操作によってもたらされるスキーマ変更を調整するための[使用制限](/dm/feature-shard-merge-pessimistic.md#restrictions)の制約があります。予期しない理由によりこれらの制約に違反した場合は、 [DMでシャーディングDDLロックを手動で処理する](/dm/manually-handling-sharding-ddl-locks.md)を実行するか、データ移行タスク全体をやり直す必要があります。 From 3db54a8a80eb1960513b9407839d4f52444bb755 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 09:44:04 +0900 Subject: [PATCH 24/56] i18n(ja): restore dropped subject particle before initial-commit-ts value --- releases/release-3.0.6.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases/release-3.0.6.md b/releases/release-3.0.6.md index c22bdb5cb0b52..089447a0730b7 100644 --- a/releases/release-3.0.6.md +++ b/releases/release-3.0.6.md @@ -91,7 +91,7 @@ TiDB Ansible バージョン: 3.0.6 ## ツール {#tools} - TiDB Binlog - - Drainer で`initial-commit-ts` "-1"に設定されている場合にPDから初期レプリケーションタイムスタンプを取得します。 [#788](https://github.com/pingcap/tidb-binlog/pull/788) + - Drainer で`initial-commit-ts`が"-1"に設定されている場合にPDから初期レプリケーションタイムスタンプを取得します。 [#788](https://github.com/pingcap/tidb-binlog/pull/788) - Drainerの`Checkpoint`ストレージを下流から分離し、MySQLまたはローカルファイルへの保存`Checkpoint`サポートします。 [#790](https://github.com/pingcap/tidb-binlog/pull/790) - レプリケーションデータベース/テーブルフィルタリングを構成する際に空の値を使用することで発生するDrainer panicの問題を修正しました[#801](https://github.com/pingcap/tidb-binlog/pull/801) - Drainer が下流にbinlogファイルを適用できないためにpanicが発生した後、プロセスが終了せずにデッドロック状態になる問題を修正しました[#807](https://github.com/pingcap/tidb-binlog/pull/807) From 948492a56f1091ab540a9573d4df1751ebbd336f Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 09:45:23 +0900 Subject: [PATCH 25/56] i18n(ja): fix scrambled word order in Checkpoint save-support sentence --- releases/release-3.0.6.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases/release-3.0.6.md b/releases/release-3.0.6.md index 089447a0730b7..08bdeff87c05e 100644 --- a/releases/release-3.0.6.md +++ b/releases/release-3.0.6.md @@ -92,7 +92,7 @@ TiDB Ansible バージョン: 3.0.6 - TiDB Binlog - Drainer で`initial-commit-ts`が"-1"に設定されている場合にPDから初期レプリケーションタイムスタンプを取得します。 [#788](https://github.com/pingcap/tidb-binlog/pull/788) - - Drainerの`Checkpoint`ストレージを下流から分離し、MySQLまたはローカルファイルへの保存`Checkpoint`サポートします。 [#790](https://github.com/pingcap/tidb-binlog/pull/790) + - Drainerの`Checkpoint`ストレージを下流から分離し、MySQLまたはローカルファイルへの`Checkpoint`の保存をサポートします。 [#790](https://github.com/pingcap/tidb-binlog/pull/790) - レプリケーションデータベース/テーブルフィルタリングを構成する際に空の値を使用することで発生するDrainer panicの問題を修正しました[#801](https://github.com/pingcap/tidb-binlog/pull/801) - Drainer が下流にbinlogファイルを適用できないためにpanicが発生した後、プロセスが終了せずにデッドロック状態になる問題を修正しました[#807](https://github.com/pingcap/tidb-binlog/pull/807) - gRPC の`GracefulStop` が原因で、Pumpが終了時にブロックされる問題を修正しました。 [#817](https://github.com/pingcap/tidb-binlog/pull/817) From b0817379c8c21b0512af0604cb15ef08de55f509 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 09:46:27 +0900 Subject: [PATCH 26/56] i18n(ja): clarify Expand-click keeps expanded state rather than continuing to expand --- releases/release-4.0.9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases/release-4.0.9.md b/releases/release-4.0.9.md index 9bfe8999f444b..f7946c638d6c1 100644 --- a/releases/release-4.0.9.md +++ b/releases/release-4.0.9.md @@ -72,7 +72,7 @@ TiDB バージョン: 4.0.9 - TiDB Dashboard - - SQL文の"Expand"をクリックすると展開を続ける [#775](https://github.com/pingcap/tidb-dashboard/pull/775) + - SQL文で"Expand"をクリックした後も展開状態を維持する [#775](https://github.com/pingcap/tidb-dashboard/pull/775) - **SQL Statements**と**Slow Queries**の詳細ページを新しいウィンドウで開く [#816](https://github.com/pingcap/tidb-dashboard/pull/816) - **Slow Queries**の詳細における時間関連フィールドの説明の改善 [#817](https://github.com/pingcap/tidb-dashboard/pull/817) - 詳細なエラーメッセージを表示する[#794](https://github.com/pingcap/tidb-dashboard/pull/794) From 14834380f2b7880a4d4cfb8947e95a8748a737bf Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 09:51:13 +0900 Subject: [PATCH 27/56] i18n(ja): fix mixed-translation panel name and scrambled word order in release-5.0.4.md --- releases/release-5.0.4.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/releases/release-5.0.4.md b/releases/release-5.0.4.md index fbf30ff915300..0cf53153595e6 100644 --- a/releases/release-5.0.4.md +++ b/releases/release-5.0.4.md @@ -32,7 +32,7 @@ TiDB バージョン: 5.0.4 - プレフィックスインデックスのクエリ範囲に関するバグを修正 [#26029](https://github.com/pingcap/tidb/issues/26029) - `LOAD DATA`文が非 UTF8 データを異常にインポートする可能性がある問題を修正[#25979](https://github.com/pingcap/tidb/issues/25979) - `insert ignore on duplicate update`セカンダリインデックスに主キーと同じ列がある場合に間違ったデータが挿入される可能性がある問題を修正[#25809](https://github.com/pingcap/tidb/issues/25809) - - パーティションテーブルにクラスター化インデックスがある場合に間違ったデータが挿入される可能性が`insert ignore duplicate update`問題を修正しました[#25846](https://github.com/pingcap/tidb/issues/25846) + - パーティションテーブルにクラスター化インデックスがある場合に`insert ignore duplicate update`が間違ったデータを挿入する可能性がある問題を修正しました[#25846](https://github.com/pingcap/tidb/issues/25846) - PointGetまたはバッチPointGetでキーが`ENUM`型の場合にクエリ結果が間違っている可能性がある問題を修正しました [#24562](https://github.com/pingcap/tidb/issues/24562) - `BIT`型の値を割ったときに発生する誤った結果を修正しました [#23479](https://github.com/pingcap/tidb/issues/23479) - `prepared`ステートメントと直接クエリの結果が矛盾する可能性がある問題を修正[#22949](https://github.com/pingcap/tidb/issues/22949) @@ -129,7 +129,7 @@ TiDB バージョン: 5.0.4 - 射影演算子を実行するときに TiDB がパニックを起こす問題を修正しました [#24264](https://github.com/pingcap/tidb/issues/24264) - 統計情報によりクエリがpanicになる可能性がある問題を修正[#24061](https://github.com/pingcap/tidb/pull/24061) - `BIT`列で`approx_percentile`関数を使用するとpanicする可能性がある問題を修正しました[#23662](https://github.com/pingcap/tidb/issues/23662) - - Grafanaの**コプロセッサー Cache**パネルのメトリックが間違っている問題を修正しました[#26338](https://github.com/pingcap/tidb/issues/26338) + - Grafanaの**Coprocessor Cache**パネルのメトリックが間違っている問題を修正しました[#26338](https://github.com/pingcap/tidb/issues/26338) - 同じパーティションを同時に切り捨てるとDDL文がスタックする問題を修正しました[#26229](https://github.com/pingcap/tidb/issues/26229) - セッション変数を`GROUP BY`項目として使用した場合に発生する誤ったクエリ結果の問題を修正しました [#27106](https://github.com/pingcap/tidb/issues/27106) - テーブルを結合する際の`VARCHAR`とタイムスタンプ間の誤った暗黙的な変換を修正しました [#25902](https://github.com/pingcap/tidb/issues/25902) @@ -161,8 +161,8 @@ TiDB バージョン: 5.0.4 - 集計関数`COUNT`または`COUNT DISTINCT`を実行するときに予期しない結果が発生する問題を修正しました - MPPタスク実行時に発生する可能性のあるpanic問題を修正 - 複数のディスクにデプロイされたときにTiFlash がデータを復元できない潜在的なバグを修正しました - - 解体時に発生する可能性のあるpanic問題を修正`SharedQueryBlockInputStream` - - 解体時に発生する可能性のあるpanic問題を修正`MPPTask` + - `SharedQueryBlockInputStream`の解体時に発生する可能性のあるpanic問題を修正 + - `MPPTask`の解体時に発生する可能性のあるpanic問題を修正 - TiFlash がMPP 接続を確立できなかった場合に予期しない結果が発生する問題を修正しました - ロックを解決する際に発生する可能性のあるpanic問題を修正 - 書き込みが集中するとメトリクスのストアサイズが不正確になる問題を修正しました From 9b2f226cda3121f1778753a9e77c6764c8aa42ea Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 09:51:57 +0900 Subject: [PATCH 28/56] i18n(ja): restore dropped subject particle before SQL_MODE values --- releases/release-5.0.4.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/releases/release-5.0.4.md b/releases/release-5.0.4.md index 0cf53153595e6..82141cc0e47e4 100644 --- a/releases/release-5.0.4.md +++ b/releases/release-5.0.4.md @@ -27,8 +27,8 @@ TiDB バージョン: 5.0.4 - `group_concat`関数の列に非ビン照合順序ある場合に発生する誤った実行結果を修正しました [#27429](https://github.com/pingcap/tidb/issues/27429) - 新しい照合順序が有効になっているときに、複数の列で`count(distinct)`式を使用すると間違った結果が返される問題を修正しました[#27091](https://github.com/pingcap/tidb/issues/27091) - `extract`関数の引数が負の期間の場合に発生する結果の誤りを修正 [#27236](https://github.com/pingcap/tidb/issues/27236) - - `SQL_MODE` 'STRICT_TRANS_TABLES'の場合、無効な日付を挿入してもエラーが報告されない問題を修正しました[#26762](https://github.com/pingcap/tidb/issues/26762) - - `SQL_MODE` 'NO_ZERO_IN_DATE'の場合に無効なデフォルト日付を使用してもエラーが報告されない問題を修正しました[#26766](https://github.com/pingcap/tidb/issues/26766) + - `SQL_MODE`が'STRICT_TRANS_TABLES'の場合、無効な日付を挿入してもエラーが報告されない問題を修正しました[#26762](https://github.com/pingcap/tidb/issues/26762) + - `SQL_MODE`が'NO_ZERO_IN_DATE'の場合に無効なデフォルト日付を使用してもエラーが報告されない問題を修正しました[#26766](https://github.com/pingcap/tidb/issues/26766) - プレフィックスインデックスのクエリ範囲に関するバグを修正 [#26029](https://github.com/pingcap/tidb/issues/26029) - `LOAD DATA`文が非 UTF8 データを異常にインポートする可能性がある問題を修正[#25979](https://github.com/pingcap/tidb/issues/25979) - `insert ignore on duplicate update`セカンダリインデックスに主キーと同じ列がある場合に間違ったデータが挿入される可能性がある問題を修正[#25809](https://github.com/pingcap/tidb/issues/25809) From 3e62384f4af24dc4d70e5d49e832d365384dcf3f Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:10:30 +0900 Subject: [PATCH 29/56] i18n(ja): use natural term for object destruction, fix scrambled word order in sibling release note --- releases/release-5.0.4.md | 4 ++-- releases/release-5.1.1.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/releases/release-5.0.4.md b/releases/release-5.0.4.md index 82141cc0e47e4..d872e6be64a6e 100644 --- a/releases/release-5.0.4.md +++ b/releases/release-5.0.4.md @@ -161,8 +161,8 @@ TiDB バージョン: 5.0.4 - 集計関数`COUNT`または`COUNT DISTINCT`を実行するときに予期しない結果が発生する問題を修正しました - MPPタスク実行時に発生する可能性のあるpanic問題を修正 - 複数のディスクにデプロイされたときにTiFlash がデータを復元できない潜在的なバグを修正しました - - `SharedQueryBlockInputStream`の解体時に発生する可能性のあるpanic問題を修正 - - `MPPTask`の解体時に発生する可能性のあるpanic問題を修正 + - `SharedQueryBlockInputStream`の破棄時に発生する可能性のあるpanic問題を修正 + - `MPPTask`の破棄時に発生する可能性のあるpanic問題を修正 - TiFlash がMPP 接続を確立できなかった場合に予期しない結果が発生する問題を修正しました - ロックを解決する際に発生する可能性のあるpanic問題を修正 - 書き込みが集中するとメトリクスのストアサイズが不正確になる問題を修正しました diff --git a/releases/release-5.1.1.md b/releases/release-5.1.1.md index 1d379e139ebd5..57d13cf4fb340 100644 --- a/releases/release-5.1.1.md +++ b/releases/release-5.1.1.md @@ -131,8 +131,8 @@ TiDB バージョン: 5.1.1 - 集計関数`COUNT`または`COUNT DISTINCT`を実行するときに予期しない結果が発生する問題を修正しました - 複数のディスクにデプロイされたときにTiFlash がデータを復元できない潜在的なバグを修正しました - TiDB DashboardがTiFlashのディスク情報を正しく表示できない問題を修正 - - 解体時に発生する可能性のあるpanic問題を修正`SharedQueryBlockInputStream` - - 解体時に発生する可能性のあるpanic問題を修正`MPPTask` + - `SharedQueryBlockInputStream`の破棄時に発生する可能性のあるpanic問題を修正 + - `MPPTask`の破棄時に発生する可能性のあるpanic問題を修正 - スナップショット経由でデータを同期した後に発生する可能性のあるデータの不整合の問題を修正 - ツール From 39f96c2a94d34614e333ce9ffa0cbd8644c1b8d6 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:11:25 +0900 Subject: [PATCH 30/56] i18n(ja): restore dropped particle before meta-schema-name introduction sentence --- releases/release-5.4.0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases/release-5.4.0.md b/releases/release-5.4.0.md index 1347868fdd7f0..4d7e8d52fb838 100644 --- a/releases/release-5.4.0.md +++ b/releases/release-5.4.0.md @@ -217,7 +217,7 @@ TiDB バージョン: 5.4.0 - **TiDB Lightningは、並列インポート用のメタ情報を格納するスキーマ名を導入しました。** - TiDB Lightning、 `meta-schema-name`という設定項目が導入されました。並列インポートモードでは、このパラメータは、ターゲットクラスタ内の各TiDB Lightningインスタンスのメタ情報を格納するスキーマ名を指定します。デフォルト値は"lightning_metadata"です。このパラメータに設定する値は、同じ並列インポートに参加する各TiDB Lightningインスタンスで同じである必要があります。そうでない場合、インポートされたデータの正確性が保証されません。 + TiDB Lightningに、 `meta-schema-name`という設定項目が導入されました。並列インポートモードでは、このパラメータは、ターゲットクラスタ内の各TiDB Lightningインスタンスのメタ情報を格納するスキーマ名を指定します。デフォルト値は"lightning_metadata"です。このパラメータに設定する値は、同じ並列インポートに参加する各TiDB Lightningインスタンスで同じである必要があります。そうでない場合、インポートされたデータの正確性が保証されません。 [ユーザー向けドキュメント](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) From 6e2de68795115365a298f07a1eaf473025f38143 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:13:08 +0900 Subject: [PATCH 31/56] i18n(ja): revert Invisible definitional quote to established Japanese term --- sql-statements/sql-statement-alter-index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sql-statements/sql-statement-alter-index.md b/sql-statements/sql-statement-alter-index.md index ee8160e601b8c..4bc0067c06ab8 100644 --- a/sql-statements/sql-statement-alter-index.md +++ b/sql-statements/sql-statement-alter-index.md @@ -92,7 +92,7 @@ ERROR 1176 (42000): Key 'c1' doesn't exist in table 't1' > **Note:** > -> ここでの"Invisible"とは、オプティマイザに対してのみ不可視であることを意味します。不可視インデックスを変更または削除することは可能です。 +> ここでの「不可視」とは、オプティマイザに対してのみ不可視であることを意味します。不可視インデックスを変更または削除することは可能です。 ```sql ALTER TABLE t1 DROP INDEX c1; From 435bd9d0b00c5b16ac28d855bec4be15383e0202 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:18:12 +0900 Subject: [PATCH 32/56] i18n(ja): fix node-count mistranslation and restore dropped subject particle --- .../notification-2023-11-14-scale-feature-maintenance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md b/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md index da62ec1035d3b..299cc90d831f3 100644 --- a/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md +++ b/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md @@ -19,7 +19,7 @@ summary: 2023年 11月 14日のTiDB Cloud Dedicated Scale 機能メンテナン ## インパクト {#impact} -メンテナンス期間中は、 [vCPUとRAMを変更する](https://docs.pingcap.com/tidbcloud/scale-tidb-cluster#change-vcpu-and-ram)無効化され、専用クラスタの vCPU と RAM を変更することはできません。ただし、 **Modify Cluster**ページでノード番号またはストレージを変更することは可能です。TiDB クラスタは通常通りデータの読み取りと書き込みを行うため、オンラインビジネスへの悪影響はありません。 +メンテナンス期間中は、 [vCPUとRAMを変更する](https://docs.pingcap.com/tidbcloud/scale-tidb-cluster#change-vcpu-and-ram)が無効化され、専用クラスタの vCPU と RAM を変更することはできません。ただし、 **Modify Cluster**ページでノード数またはストレージを変更することは可能です。TiDB クラスタは通常通りデータの読み取りと書き込みを行うため、オンラインビジネスへの悪影響はありません。 ### TiDB Cloudコンソール UI の影響を受ける機能 {#affected-features-of-tidb-cloud-console-ui} From 00fe0c33abd69b883774d27ca5e93e4801e29c23 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:20:55 +0900 Subject: [PATCH 33/56] i18n(ja): revert authorized network definitional quote to established Japanese term --- .../configure-serverless-firewall-rules-for-public-endpoints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md b/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md index 47bdd66a0309d..41319bc293f99 100644 --- a/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md +++ b/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md @@ -13,7 +13,7 @@ summary: TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスへの ## 公開エンドポイント {#public-endpoints} -TiDB Cloud StarterまたはEssentialインスタンスでパブリックアクセスを設定すると、パブリックエンドポイント経由でインスタンスにアクセスできるようになります。つまり、 TiDB Cloud StarterまたはEssentialインスタンスはインターネット経由でアクセス可能になります。パブリックエンドポイントは、公開されている DNS アドレスです。"authorized network"とは、TiDB Cloud StarterまたはEssentialインスタンスへのアクセスを許可する IP アドレスの範囲を指します。これらのアクセス許可は、**ファイアウォールルール**によって適用されます。 +TiDB Cloud StarterまたはEssentialインスタンスでパブリックアクセスを設定すると、パブリックエンドポイント経由でインスタンスにアクセスできるようになります。つまり、 TiDB Cloud StarterまたはEssentialインスタンスはインターネット経由でアクセス可能になります。パブリックエンドポイントは、公開されている DNS アドレスです。「承認済みネットワーク」とは、TiDB Cloud StarterまたはEssentialインスタンスへのアクセスを許可する IP アドレスの範囲を指します。これらのアクセス許可は、**ファイアウォールルール**によって適用されます。 ### 公共アクセスの特徴 {#characteristics-of-public-access} From ee73337964762a9951822ea42b4b8fc767e84c76 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:22:32 +0900 Subject: [PATCH 34/56] i18n(ja): fix scrambled compression-format list and stray brace artifact --- tidb-cloud/import-csv-files.md | 2 +- tidb-cloud/premium/import-csv-files-premium.md | 2 +- tidb-cloud/releases/release-notes-2023.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tidb-cloud/import-csv-files.md b/tidb-cloud/import-csv-files.md index df2bd454ee12f..267caa1ca18f4 100644 --- a/tidb-cloud/import-csv-files.md +++ b/tidb-cloud/import-csv-files.md @@ -30,7 +30,7 @@ aliases: ['/ja/tidbcloud/migrate-from-amazon-s3-or-gcs','/ja/tidbcloud/migrate-f - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`と`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順でなければなりません。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 - - TiDB Cloudは、 `.gzip` 、 `.gz` 、{ `.zst` `.zstd` 、および`.snappy`形式で圧縮ファイルをインポートすることをサポートしています。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`は省略可能で、'000001'などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 + - TiDB Cloudは、 `.gzip` 、 `.gz` 、 `.zstd` 、 `.zst` 、および`.snappy`形式で圧縮ファイルをインポートすることをサポートしています。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`は省略可能で、'000001'などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 > **Note:** > diff --git a/tidb-cloud/premium/import-csv-files-premium.md b/tidb-cloud/premium/import-csv-files-premium.md index 07687a9091d64..208fcf048616c 100644 --- a/tidb-cloud/premium/import-csv-files-premium.md +++ b/tidb-cloud/premium/import-csv-files-premium.md @@ -28,7 +28,7 @@ summary: Amazon S3またはAlibaba Cloud Object Storage Service（OSS）からCS - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`や`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 - - TiDB Cloud Premium は、 `.gzip` 、 `.gz` 、 `.zst` `.zstd` 、{ `.snappy`の形式で圧縮ファイルをインポートできます。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`省略可能で、'000001'などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 + - TiDB Cloud Premium は、 `.gzip` 、 `.gz` 、 `.zstd` 、 `.zst` 、および`.snappy`の形式で圧縮ファイルをインポートできます。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`省略可能で、'000001'などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 > **Note:** > diff --git a/tidb-cloud/releases/release-notes-2023.md b/tidb-cloud/releases/release-notes-2023.md index 64ed6cf2a0aa1..2c1168ba31e39 100644 --- a/tidb-cloud/releases/release-notes-2023.md +++ b/tidb-cloud/releases/release-notes-2023.md @@ -533,7 +533,7 @@ summary: 2023年のTiDB Cloudのリリースノートについて説明します 詳細な手順については、 [ノードサイズを変更する](/tidb-cloud/scale-tidb-cluster.md#change-vcpu-and-ram)を参照してください。 -- 圧縮ファイルのインポートをサポートします。CSVファイルとSQLファイルの形式は、 `.gzip` `.zst` 。この機能`.gz` `.zstd`より効率的かつコスト効率の高いデータインポートが可能になり、データ転送コスト`.snappy`削減できます。 +- 圧縮ファイルのインポートをサポートします。CSVファイルとSQLファイルを`.gzip`、 `.gz`、 `.zstd`、 `.zst`、および`.snappy`形式でインポートできます。この機能により、より効率的かつコスト効率の高いデータインポートが可能になり、データ転送コストを削減できます。 詳細については、 [クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)および[サンプルデータのインポート](/tidb-cloud/import-sample-data.md)を参照してください。 From 1f0f5b279083d4640a13a4ca57a152466c79cd79 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:24:37 +0900 Subject: [PATCH 35/56] i18n(ja): revert serverless definitional quote to established Japanese term --- tidb-cloud/serverless-faqs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/serverless-faqs.md b/tidb-cloud/serverless-faqs.md index 343619fe9ca25..a7fb83301863d 100644 --- a/tidb-cloud/serverless-faqs.md +++ b/tidb-cloud/serverless-faqs.md @@ -22,7 +22,7 @@ TiDB Cloud Starter は、2025年 8月 12日よりTiDB Cloud Serverless の新し Starter に名前が変更される前、 TiDB Cloudの Serverless 層は何千人もの開発者のエントリ ポイントとして機能し、自動的にスケーリングされ、数秒で起動し、十分な無料割り当てを超えるまでコストがかからない、本番環境対応のデータベースを提供していました。 -"serverless"は、サービスが舞台裏でどのように動作するかを正確に反映していますが、初めて使用するユーザーの多くは、この用語が抽象的で、さまざまな意味が詰め込まれていると感じました。 +「サーバーレス」は、サービスが舞台裏でどのように動作するかを正確に反映していますが、初めて使用するユーザーの多くは、この用語が抽象的で、さまざまな意味が詰め込まれていると感じました。 このエントリー層の目的をより明確にするため、 TiDB Cloudを使った構築を最も早く開始できる「Starter」に名称を変更しました。Serverless層に関するこれまでの内容はそのままです。 From 2df2770b00beea2b6a2851759ccf3ea45efd5908 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:25:49 +0900 Subject: [PATCH 36/56] i18n(ja): add missing outer quotes around literal access-denied error message --- tidb-cloud/troubleshoot-import-access-denied-error.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/troubleshoot-import-access-denied-error.md b/tidb-cloud/troubleshoot-import-access-denied-error.md index 86a80bb206d77..d5d0132aa737a 100644 --- a/tidb-cloud/troubleshoot-import-access-denied-error.md +++ b/tidb-cloud/troubleshoot-import-access-denied-error.md @@ -73,7 +73,7 @@ IAMロールが存在しない場合は、 [Amazon S3 アクセスを構成す IAMユーザーの AWS アクセスキーを使用して Amazon S3 バケットにアクセスすると、次のエラーが発生する場合があります。 -- アクセスキーID'{access_key_id}'とシークレットアクセスキー'{secret_access_key}'を使用したソース'{bucket_uri}'へのアクセスが拒否されました。 +- "アクセスキーID'{access_key_id}'とシークレットアクセスキー'{secret_access_key}'を使用したソース'{bucket_uri}'へのアクセスが拒否されました" これは、権限不足のため、 TiDB Cloud がAmazon S3 バケットにアクセスできなかったことを示しています。Amazon S3 バケットにアクセスするには、以下の権限が必要です。 From 098a0a806dfa1ece013b0cf607774a04ba15a1fe Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:28:25 +0900 Subject: [PATCH 37/56] i18n(ja): unify max(1000, tables*3) rhetorical restatement to Japanese across sibling docs --- dm/dm-precheck.md | 2 +- tidb-lightning/tidb-lightning-distributed-import.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dm/dm-precheck.md b/dm/dm-precheck.md index fbc66554f5736..bda4872eb56e7 100644 --- a/dm/dm-precheck.md +++ b/dm/dm-precheck.md @@ -100,7 +100,7 @@ tiup dmctl check-task ./task.yaml - 下流データベース内の空のリージョン - - 空のリージョンの数が`max(1000, 3 * the number of tables)` ("1000"と「テーブル数の 3 倍」の大きい方) より大きい場合、事前チェックは警告を返します。関連する PD パラメータを調整して、空のリージョンの結合を高速化し、空のリージョンの数が減少するのを待つことができます。 [PDスケジューリングのベストプラクティス - 低速リージョンマージ](/best-practices/pd-scheduling-best-practices.md#region-merge-is-slow)を参照。 + - 空のリージョンの数が`max(1000, 3 * the number of tables)` (「1000」と「テーブル数の 3 倍」の大きい方) より大きい場合、事前チェックは警告を返します。関連する PD パラメータを調整して、空のリージョンの結合を高速化し、空のリージョンの数が減少するのを待つことができます。 [PDスケジューリングのベストプラクティス - 低速リージョンマージ](/best-practices/pd-scheduling-best-practices.md#region-merge-is-slow)を参照。 - 下流データベースにおけるリージョン分布 diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index cf3b093fc5556..147a7dde34531 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -127,7 +127,7 @@ nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out & 並列インポート中、 TiDB Lightning はタスクの開始後に次のチェックを自動的に実行します。 - ローカルディスク（構成`sort-kv-dir`で制御）とTiKVクラスターに、データのインポートに必要な空き容量があるかどうかを確認してください。必要なディスク容量については、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)を参照してください。TiDB Lightningはデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。 -- TiKVクラスタ内のリージョンが均等に分散されているか、また空きリージョンが多すぎないかを確認してください。空きリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり"1000"または"3 times the number of tables"のいずれか大きい方を超える場合、インポートは実行できません。 +- TiKVクラスタ内のリージョンが均等に分散されているか、また空きリージョンが多すぎないかを確認してください。空きリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 - データソースからデータが順番にインポートされているか確認します。確認結果に基づいて`mydumper.batch-size`のサイズが自動的に調整されます。そのため、 `mydumper.batch-size`構成は利用できなくなります。 チェックをオフにして、 `lightning.check-requirements`設定で強制インポートを実行することもできます。詳細なチェックについては、 [TiDB Lightning事前チェック](/tidb-lightning/tidb-lightning-prechecks.md)を参照してください。 From 7277ecaa1618ed6983bd3bfef378f67319e26ca5 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:30:10 +0900 Subject: [PATCH 38/56] i18n(ja): revert index-with-full-match and access-condition definitional quotes to established Japanese terms --- choose-index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/choose-index.md b/choose-index.md index 3eff8c0801a9a..0ac29b5bad42f 100644 --- a/choose-index.md +++ b/choose-index.md @@ -46,7 +46,7 @@ TiDBは、インデックスを選択するために以下のヒューリステ - ルール4：ルール2とルール3に基づいて候補インデックスが1つだけ選択された場合は、その候補インデックスを選択します。ルール2とルール3に基づいてそれぞれ2つの候補インデックスが選択された場合は、読み込む行数が少ない方のインデックスを選択します（インデックスを持つ行数＋テーブルから取得する行数）。 -上記のルールにおける"index with full match"とは、インデックス付けされた各列が等しい条件を満たすことを意味します。 `EXPLAIN FORMAT = 'verbose' ...`ステートメントを実行する際に、事前ルールがインデックスに一致する場合、TiDB はインデックスが事前ルールに一致することを示す NOTE レベルの警告を出力します。 +上記のルールにおける「完全一致のインデックス」とは、インデックス付けされた各列が等しい条件を満たすことを意味します。 `EXPLAIN FORMAT = 'verbose' ...`ステートメントを実行する際に、事前ルールがインデックスに一致する場合、TiDB はインデックスが事前ルールに一致することを示す NOTE レベルの警告を出力します。 次の例では、インデックス`idx_b`ルール 2 の条件「完全一致の一意インデックス + テーブルから行を取得する必要性」を満たしているため、TiDB はインデックス`idx_b`をアクセス パスとして選択し、 `SHOW WARNING`インデックス`idx_b`が事前ルールに一致することを示すメモを返します。 @@ -75,7 +75,7 @@ mysql> SHOW WARNINGS; スカイライン剪定は、インデックスに対するヒューリスティックなフィルタリングルールであり、誤った推定によるインデックス選択の誤りの可能性を低減できます。インデックスを評価するには、以下の次元が必要です。 -- インデックス付き列によってカバーされるアクセス条件の数はいくつでしょうか。"access condition"とは、列範囲に変換できるWHERE句の条件のことです。インデックス付き列セットがカバーするアクセス条件が多いほど、この点において優れています。 +- インデックス付き列によってカバーされるアクセス条件の数はいくつでしょうか。「アクセス条件」とは、列範囲に変換できるWHERE句の条件のことです。インデックス付き列セットがカバーするアクセス条件が多いほど、この点において優れています。 - テーブルにアクセスするためにインデックスを選択した場合に、テーブルから行を取得する必要があるかどうか（つまり、インデックスによって生成されるプランが IndexReader オペレーターまたは IndexLookupReader オペレーターであるかどうか）。テーブルから行を取得しないインデックスは、取得するインデックスよりもこの点で優れています。両方のインデックスが TiDB を使用してテーブルから行を取得する必要がある場合は、インデックス付き列によってカバーされるフィルタリング条件の数を比較します。フィルタリング条件とは、インデックスに基づいて判断できる`where`条件のことです。インデックスの列セットがより多くのアクセス条件をカバーするほど、テーブルから取得される行の数は少なくなり、この点でインデックスの性能が向上します。 From adba9b1724fd058efc3e097568d4c30fb6eb218c Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:30:53 +0900 Subject: [PATCH 39/56] i18n(ja): revert Column Pruning definitional quote to established Japanese term --- column-pruning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/column-pruning.md b/column-pruning.md index dd267a7bbb99b..135e1a3e3f2ce 100644 --- a/column-pruning.md +++ b/column-pruning.md @@ -15,7 +15,7 @@ select a from t where b> 5 このクエリでは、列aと列bのみが使用され、列cと列dは冗長です。この文のクエリプランでは、 `Selection`の演算子が列bを使用し、 `DataSource`演算子が列aと列bを使用します。`DataSource`演算子は列cと列dを読み取らないため、これらはプルーニング可能です。 -そのため、TiDBはロジック最適化フェーズでトップダウンスキャンを実行する際に、リソースの無駄を削減するために冗長な列をプルーニングします。このスキャン処理は"Column Pruning"と呼ばれ、ルール`columnPruner`に対応しています。 +そのため、TiDBはロジック最適化フェーズでトップダウンスキャンを実行する際に、リソースの無駄を削減するために冗長な列をプルーニングします。このスキャン処理は「列プルーニング」と呼ばれ、ルール`columnPruner`に対応しています。 From f521af5e27fbc33a3ecc4398766635926cedf445 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:31:32 +0900 Subject: [PATCH 40/56] i18n(ja): revert Group definitional quote to established Japanese term --- configure-placement-rules.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure-placement-rules.md b/configure-placement-rules.md index d2b962f45a249..9ed0bae036f70 100644 --- a/configure-placement-rules.md +++ b/configure-placement-rules.md @@ -19,7 +19,7 @@ TiDBバージョン5.0以降では、配置ルール機能はデフォルトで 複数のルールのキー範囲は重複する部分を持つ場合があり、これはリージョンが複数のルールに一致する可能性があることを意味します。この場合、PDはルールの属性に基づいて、ルールが互いに上書きされるか、同時に有効になるかを決定します。複数のルールが同時に有効になる場合、PDはルールマッチングのために、ルールのスタック順序に従って順番にスケジュールを生成します。 -さらに、異なるソースからのルールを互いに分離するという要件を満たすため、これらのルールをより柔軟に整理できます。そのため、"Group"という概念が導入されました。一般的に、ユーザーは異なるソースに基づいてルールを異なるグループに配置できます。 +さらに、異なるソースからのルールを互いに分離するという要件を満たすため、これらのルールをより柔軟に整理できます。そのため、「グループ」という概念が導入されました。一般的に、ユーザーは異なるソースに基づいてルールを異なるグループに配置できます。 ![Placement rules overview](/media/placement-rules-1.png) From dd9683f8a969f826c9ed51f20a37f36b12aaf77a Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:32:33 +0900 Subject: [PATCH 41/56] i18n(ja): revert consistency assurance definitional quote to established Japanese term --- dumpling-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dumpling-overview.md b/dumpling-overview.md index 40b151d855f92..9d70d4e4897a1 100644 --- a/dumpling-overview.md +++ b/dumpling-overview.md @@ -284,7 +284,7 @@ Dumpling、 `-B`オプションを使用して特定のデータベースをエ > > データ整合性オプションのデフォルト値は`auto`です。ほとんどの場合、 Dumplingのデフォルトのデータ整合性オプションを調整する必要はありません。 -Dumpling は`--consistency `オプションを使用して、"consistency assurance"のためにデータをエクスポートする方法を制御します。スナップショットを使用して一貫性を確保する場合、 `--snapshot`オプションを使用してバックアップするタイムスタンプを指定できます。また、次のレベルの一貫性も使用できます。 +Dumpling は`--consistency `オプションを使用して、「一貫性の保証」のためにデータをエクスポートする方法を制御します。スナップショットを使用して一貫性を確保する場合、 `--snapshot`オプションを使用してバックアップするタイムスタンプを指定できます。また、次のレベルの一貫性も使用できます。 - `flush` : [`FLUSH TABLES WITH READ LOCK`](https://dev.mysql.com/doc/refman/8.0/en/flush.html#flush-tables-with-read-lock)を使用すると、レプリカ データベースの DML および DDL 操作を一時的に中断し、バックアップ 接続のグローバルな一貫性を確保し、binlog位置 (POS) 情報を記録できます。ロックは、すべてのバックアップ 接続がトランザクションを開始すると解放されます。フルバックアップは、ピーク時以外の時間帯、または MySQL レプリカ データベースで実行することをお勧めします。TiDB はこの値をサポートしていないことに注意してください。 - `snapshot` : 指定されたタイムスタンプの一貫性のあるスナップショットを取得し、エクスポートします。 From bfb3d440a8a59d550b96a1b180be4b06c0663186 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:33:30 +0900 Subject: [PATCH 42/56] i18n(ja): revert inline REFERENCES specifications quote to established Japanese/backtick mix --- foreign-key.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/foreign-key.md b/foreign-key.md index a8f033d54a589..137859b4c0ffb 100644 --- a/foreign-key.md +++ b/foreign-key.md @@ -330,7 +330,7 @@ Create Table | CREATE TABLE `child` ( 外部キーを作成する際に名前を指定しない場合、TiDB によって生成される名前は MySQL によって生成される名前とは異なります。たとえば、TiDB によって生成される外部キー名は`fk_1` 、 `fk_2` 、 `fk_3`ですが、MySQL によって生成される外部キー名は`table_name_ibfk_1` 、 `table_name_ibfk_2` 、 `table_name_ibfk_3`です。 -MySQLとTiDBはどちらも"inline `REFERENCES` specifications"を解析しますが、無視します。 `REFERENCES`定義の一部である`FOREIGN KEY`仕様のみがチェックされ、適用されます。次の例では`REFERENCES`句を使用して外部キー制約を作成します。 +MySQLとTiDBはどちらも「インライン`REFERENCES`仕様」を解析しますが、無視します。 `REFERENCES`定義の一部である`FOREIGN KEY`仕様のみがチェックされ、適用されます。次の例では`REFERENCES`句を使用して外部キー制約を作成します。 ```sql CREATE TABLE parent ( From 0cd4706346d9d2dbd79d290f46e63ec073284358 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:34:41 +0900 Subject: [PATCH 43/56] i18n(ja): revert original value definitional quote to established Japanese glossary term --- glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/glossary.md b/glossary.md index da9dc7d53b276..cca53fe951de0 100644 --- a/glossary.md +++ b/glossary.md @@ -209,7 +209,7 @@ TiDBはv5.0以降、 TiFlashノードを介して大規模並列処理（MPP） ### 元の値（Old value） {#old-value} -TiCDCが出力する増分変更ログにおける"original value"。TiCDCが出力する増分変更ログに"original value"を含めるかどうかを指定できます。 +TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出力する増分変更ログに「元の値」を含めるかどうかを指定できます。 ### オンライン分析処理（OLAP） {#online-analytical-processing-olap} From c8ff27ca16847db3edcc5d7e1cbe34a94c27f368 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:37:21 +0900 Subject: [PATCH 44/56] i18n(ja): fix self-reference to Back up data section heading, matching sibling doc --- migrate-from-tidb-to-mysql.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/migrate-from-tidb-to-mysql.md b/migrate-from-tidb-to-mysql.md index 02c486e6378f0..064df0b3123d5 100644 --- a/migrate-from-tidb-to-mysql.md +++ b/migrate-from-tidb-to-mysql.md @@ -168,7 +168,7 @@ summary: TiDB から MySQL 互換データベースにデータを移行する - `--server` : TiCDC クラスター内の任意のノードの IP アドレス - `--sink-uri` : 下流クラスタのURI - `--changefeed-id` : チェンジフィードID、正規表現の形式でなければなりません、 `^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$` - - `--start-ts` : 変更フィードの開始タイムスタンプ。バックアップ時刻である必要があります (または[ステップ2. 全データの移行](#step-2-migrate-full-data)の"Back up data"セクションの BackupTS) + - `--start-ts` : 変更フィードの開始タイムスタンプ。バックアップ時刻である必要があります (または[ステップ2. 全データの移行](#step-2-migrate-full-data)の「データのバックアップ」セクションの BackupTS) changefeed 構成の詳細については、 [タスク設定ファイル](/ticdc/ticdc-changefeed-config.md)を参照してください。 From 8002ea344f8f1abf41b02089d61dad2202c3f044 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:38:54 +0900 Subject: [PATCH 45/56] i18n(ja): revert small-datasets and sandbox-mode definitional quotes to established Japanese terms --- migrate-small-mysql-to-tidb.md | 2 +- password-management.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/migrate-small-mysql-to-tidb.md b/migrate-small-mysql-to-tidb.md index b276432857f7a..9e780e430a586 100644 --- a/migrate-small-mysql-to-tidb.md +++ b/migrate-small-mysql-to-tidb.md @@ -5,7 +5,7 @@ summary: 小さなデータセットを MySQL から TiDB に移行する方法 # 小規模データセットをMySQLからTiDBに移行する {#migrate-small-datasets-from-mysql-to-tidb} -このドキュメントでは、TiDB Data Migration (DM) を使用して、MySQL から TiDB へ小規模データセットを移行する方法について説明します。移行モードは完全移行モードと増分レプリケーションモードです。このドキュメントにおける"Small datasets"とは、1 TiB 未満のデータサイズを指します。 +このドキュメントでは、TiDB Data Migration (DM) を使用して、MySQL から TiDB へ小規模データセットを移行する方法について説明します。移行モードは完全移行モードと増分レプリケーションモードです。このドキュメントにおける「小規模データセット」とは、1 TiB 未満のデータサイズを指します。 移行速度は、テーブルスキーマ内のインデックスの数、ハードウェア、ネットワーク環境などの複数の要因に応じて、30 GB/時間から 50 GB/時間まで変化します。 diff --git a/password-management.md b/password-management.md index 6b63a7a41c711..d2b499eb9b420 100644 --- a/password-management.md +++ b/password-management.md @@ -264,9 +264,9 @@ TiDB は、グローバルレベルとアカウント レベルでの自動パ ### 期限切れのパスワードの処理 {#handle-an-expired-password} -パスワードの有効期限切れに関するTiDBサーバーの動作を制御できます。パスワードの有効期限が切れると、サーバーはクライアントを切断するか、クライアントを"sandbox mode"に制限します。"sandbox mode"では、TiDBサーバーは期限切れのアカウントからの接続を許可します。ただし、この接続では、ユーザーはパスワードのリセットのみを実行できます。 +パスワードの有効期限切れに関するTiDBサーバーの動作を制御できます。パスワードの有効期限が切れると、サーバーはクライアントを切断するか、クライアントを「サンドボックスモード」に制限します。「サンドボックスモード」では、TiDBサーバーは期限切れのアカウントからの接続を許可します。ただし、この接続では、ユーザーはパスワードのリセットのみを実行できます。 -TiDBサーバーは、"sandbox mode"において、パスワードの有効期限が切れたユーザーを制限するかどうかを制御できます。パスワードの有効期限が切れた場合のTiDBサーバーの動作を制御するには、TiDB設定ファイルの[`security.disconnect-on-expired-password`](/tidb-configuration-file.md#disconnect-on-expired-password-new-in-v650)のパラメータを設定します。 +TiDBサーバーは、「サンドボックスモード」において、パスワードの有効期限が切れたユーザーを制限するかどうかを制御できます。パスワードの有効期限が切れた場合のTiDBサーバーの動作を制御するには、TiDB設定ファイルの[`security.disconnect-on-expired-password`](/tidb-configuration-file.md#disconnect-on-expired-password-new-in-v650)のパラメータを設定します。 ```toml [security] @@ -274,7 +274,7 @@ disconnect-on-expired-password = true ``` - `disconnect-on-expired-password` `true` (デフォルト) に設定すると、パスワードの有効期限が切れるとサーバーはクライアントとの接続を切断します。 -- `disconnect-on-expired-password` `false`に設定すると、サーバーは"sandbox mode"を有効にし、ユーザーがサーバーに接続できるようにします。ただし、ユーザーはパスワードのリセットのみ可能です。パスワードをリセットすると、ユーザーはSQL文を通常どおり実行できるようになります。 +- `disconnect-on-expired-password` `false`に設定すると、サーバーは「サンドボックスモード」を有効にし、ユーザーがサーバーに接続できるようにします。ただし、ユーザーはパスワードのリセットのみ可能です。パスワードをリセットすると、ユーザーはSQL文を通常どおり実行できるようになります。 `disconnect-on-expired-password`が有効になっている場合、アカウントのパスワードが期限切れになると、TiDB はそのアカウントからの接続を拒否します。このような場合、以下の方法でパスワードを変更できます。 From b5d897f07d6d44b5ce2a428b5496da5c6ea6cf10 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:39:33 +0900 Subject: [PATCH 46/56] i18n(ja): revert scan/approximate definitional quotes to established Japanese terms --- pd-control.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pd-control.md b/pd-control.md index 78ab3ed02c449..cab26b4c8eb7f 100644 --- a/pd-control.md +++ b/pd-control.md @@ -634,7 +634,7 @@ member leader_priority pd-5 0 >> operator check 1 // Check the status of the operators related to Region 1 ``` -リージョンの分割は、可能な限り中央に近い位置から開始されます。この位置を特定するには、"scan"と"approximate"という2つの戦略があります。これらの違いは、前者はリージョンをスキャンして中央のキーを決定するのに対し、後者はSSTファイルに記録された統計情報をチェックすることでおおよその位置を取得することです。一般的に、前者の方が精度が高く、後者はI/Oの消費量が少なく、処理が高速です。 +リージョンの分割は、可能な限り中央に近い位置から開始されます。この位置を特定するには、「スキャン」と「近似」という2つの戦略があります。これらの違いは、前者はリージョンをスキャンして中央のキーを決定するのに対し、後者はSSTファイルに記録された統計情報をチェックすることでおおよその位置を取得することです。一般的に、前者の方が精度が高く、後者はI/Oの消費量が少なく、処理が高速です。 ### `ping` {#ping} From 339bf696debbf314dc5acff37868026f2cde26dc Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:40:43 +0900 Subject: [PATCH 47/56] i18n(ja): revert relation-loop and sandbox-mode definitional quotes to established Japanese terms --- role-based-access-control.md | 2 +- security-compatibility-with-mysql.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/role-based-access-control.md b/role-based-access-control.md index 03a4a2c3a1518..458585a719675 100644 --- a/role-based-access-control.md +++ b/role-based-access-control.md @@ -79,7 +79,7 @@ GRANT 'app_read', 'app_write' TO 'rw_user1'@'localhost'; ユーザーにロールを付与しても、そのロールがすぐに有効になるわけではありません。ロールの有効化は別の操作です。 -次の操作は"relation loop"を形成する可能性があります。 +次の操作は「関係ループ」を形成する可能性があります。 ```sql CREATE USER 'u1', 'u2'; diff --git a/security-compatibility-with-mysql.md b/security-compatibility-with-mysql.md index d8e2461a0f199..da3df2b2ec2f6 100644 --- a/security-compatibility-with-mysql.md +++ b/security-compatibility-with-mysql.md @@ -27,8 +27,8 @@ TiDB と MySQL のパスワード有効期限ポリシーには次の違いが TiDB の有効期限メカニズムは、次の点で MySQL と異なります。 -- MySQL v5.7 および v8.0 では、クライアントとサーバーの構成を組み合わせて、クライアント接続に"sandbox mode"を有効にするかどうかを決定します。 -- TiDB では、 [`security.disconnect-on-expired-password`](/tidb-configuration-file.md#disconnect-on-expired-password-new-in-v650)設定項目だけで、クライアント接続に対して"sandbox mode"を有効にするかどうかが決まります。 +- MySQL v5.7 および v8.0 では、クライアントとサーバーの構成を組み合わせて、クライアント接続に「サンドボックス モード」を有効にするかどうかを決定します。 +- TiDB では、 [`security.disconnect-on-expired-password`](/tidb-configuration-file.md#disconnect-on-expired-password-new-in-v650)設定項目だけで、クライアント接続に対して「サンドボックス モード」を有効にするかどうかが決まります。 ### Password complexity policy {#password-complexity-policy} From cd27ae95dd57b335b7c008f9e8ddf405a6aab5c4 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:41:45 +0900 Subject: [PATCH 48/56] i18n(ja): revert schema pattern/table pattern definitional quotes to established Japanese terms --- table-filter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/table-filter.md b/table-filter.md index 0f3950d8c7070..cd46a52fda933 100644 --- a/table-filter.md +++ b/table-filter.md @@ -85,7 +85,7 @@ TOMLファイル内のテーブルフィルターは[文字列の配列](https:/ ### プレーンテーブル名 {#plain-table-names} -各テーブルフィルタールールは、"schema pattern"と"table pattern"で構成され、ドット（ `.` ）で区切られます。完全修飾名がルールに一致するテーブルが受け入れられます。 +各テーブルフィルタールールは、「スキーマパターン」と「テーブルパターン」で構成され、ドット（ `.` ）で区切られます。完全修飾名がルールに一致するテーブルが受け入れられます。 ``` db1.tbl1 From 6df92c097c30d08e9b7cff69a38be309d1a685a1 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:42:36 +0900 Subject: [PATCH 49/56] i18n(ja): revert Character and sandbox-mode definitional quotes to established Japanese terms --- table-filter.md | 2 +- tidb-configuration-file.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/table-filter.md b/table-filter.md index cd46a52fda933..c86d6fe81830d 100644 --- a/table-filter.md +++ b/table-filter.md @@ -120,7 +120,7 @@ data.* *.backup_* ``` -ここでの"Character"とは、次のような Unicode コード ポイントを意味します。 +ここでの「文字」とは、次のような Unicode コード ポイントを意味します。 - U+00E9 (é) は 1 文字です。 - U+0065 U+0301 (é) は 2 文字です。 diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index 4101c1a6eb0c5..546ff3db9d2ea 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -473,7 +473,7 @@ TiDB 構成ファイルは、コマンドラインパラメーターよりも多 - パスワードの有効期限が切れたときに、TiDBがクライアント接続を切断するかどうかを決定します。 - デフォルト値: `true` - オプション値: `true` 、 `false` -- `true`に設定すると、パスワードの有効期限が切れたときにクライアント接続が切断されます。 `false`に設定すると、クライアント接続は"sandbox mode"に制限され、ユーザーはパスワードリセット操作のみを実行できます。 +- `true`に設定すると、パスワードの有効期限が切れたときにクライアント接続が切断されます。 `false`に設定すると、クライアント接続は「サンドボックスモード」に制限され、ユーザーはパスワードリセット操作のみを実行できます。 ### `session-token-signing-cert` v6.4.0 の新機能 {#session-token-signing-cert-new-in-v640} From d8518ec614e29a2a2e02ca5b6340d4e7d4f31410 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 10:43:50 +0900 Subject: [PATCH 50/56] i18n(ja): revert Leader Transfer and Compatibility Changes section-name quotes to established Japanese terms --- tikv-overview.md | 2 +- upgrade-tidb-using-tiup.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tikv-overview.md b/tikv-overview.md index d7f4650e06513..c18ce5ef52d1e 100644 --- a/tikv-overview.md +++ b/tikv-overview.md @@ -25,7 +25,7 @@ TiKVは、クラスター内の各リージョンの適切なサイズを維持 PD がレプリカをある TiKV ノードから別の TiKV ノードに移動する場合、まずターゲットノードにLearnerレプリカを追加し、 LearnerレプリカのデータがLeaderレプリカのデータとほぼ同じになったら、PD はそれをFollowerレプリカに変更し、ソース ノードのFollowerレプリカを削除します。 -Leaderレプリカをあるノードから別のノードに移動させる場合も同様のメカニズムが採用されます。違いは、LearnerレプリカがFollowerレプリカになった後、"Leader Transfer"処理が実行され、Followerレプリカが自らをLeaderに選出するための選挙を積極的に提案することです。最終的に、新しいLeaderはソースノードから古いLeaderレプリカを削除します。 +Leaderレプリカをあるノードから別のノードに移動させる場合も同様のメカニズムが採用されます。違いは、LearnerレプリカがFollowerレプリカになった後、「Leader移行」処理が実行され、Followerレプリカが自らをLeaderに選出するための選挙を積極的に提案することです。最終的に、新しいLeaderはソースノードから古いLeaderレプリカを削除します。 ## 分散トランザクション {#distributed-transaction} diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index 0a773296e205c..7134276cbf772 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -53,7 +53,7 @@ summary: TiUPを使用してTiDBをアップグレードする方法を学びま - TiCDC、 TiFlash、およびその他のコンポーネントのバージョンアップグレードをサポートします。 - クラスターが TiCDC クラシックアーキテクチャ(v8.1.2 など) を使用している場合は、メジャーバージョン間のアップグレード中に変更フィードを実行し続けないでください。この場合、次の手順を順番に実行します。すべての変更フィードを一時停止し、TiCDC をアップグレードし、TiDB クラスターをアップグレードし、すべての変更フィードを再開します。詳細については、 [以前のバージョンからのアップグレードに関する互換性に関する注意事項](/ticdc/ticdc-compatibility.md#compatibility-notes-for-upgrading-from-earlier-versions)を参照してください。 - TiFlashをv6.3.0より前のバージョンからv6.3.0以降のバージョンにアップグレードする場合、Linux AMD64アーキテクチャではCPUがAVX2命令セットを、Linux ARM64アーキテクチャではARMv8命令セットアーキテクチャをサポートしている必要があることに注意してください。詳細は[v6.3.0 リリースノート](/releases/release-6.3.0.md#others)の説明を参照してください。 -- 各バージョンの互換性に関する詳細な変更点については、各バージョンの[リリースノート](/releases/_index.md)を参照してください。該当するリリースノートの"Compatibility Changes"セクションに従って、クラスタ構成を変更してください。 +- 各バージョンの互換性に関する詳細な変更点については、各バージョンの[リリースノート](/releases/_index.md)を参照してください。該当するリリースノートの「互換性の変更点」セクションに従って、クラスタ構成を変更してください。 - クラスターをv5.3より前のバージョンからv5.3以降のバージョンに更新する場合、デフォルトでデプロイされているPrometheusによって生成されるアラートの時刻フォーマットが変更されることに注意してください。このフォーマット変更はPrometheus v2.27.1から導入されています。詳細については、 [Prometheus](https://github.com/prometheus/prometheus/commit/7646cbca328278585be15fa615e22f2a50b47d06)を参照してください。 ## 準備 {#preparations} From fce7b858a29effcc51a82c35b72b9dbdbcb766d3 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 11:00:01 +0900 Subject: [PATCH 51/56] i18n(ja): revert definitional self-reference quotes to established Japanese terms across corpus --- best-practices/pd-scheduling-best-practices.md | 4 ++-- develop/dev-guide-use-follower-read.md | 4 ++-- dm/dm-continuous-data-validation.md | 4 ++-- dm/dm-replication-logic.md | 2 +- dm/feature-shard-merge-optimistic.md | 2 +- dr-multi-replica.md | 2 +- dr-secondary-cluster.md | 2 +- glossary.md | 2 +- multi-data-centers-in-one-city-deployment.md | 2 +- releases/release-6.2.0.md | 4 ++-- releases/release-7.1.0.md | 2 +- releases/release-7.5.0.md | 2 +- three-data-centers-in-two-cities-deployment.md | 2 +- ticdc/ticdc-debezium.md | 2 +- tidb-cloud/changefeed-sink-to-apache-kafka.md | 2 +- tidb-cloud/essential-changefeed-sink-to-kafka.md | 2 +- tidb-cloud/tidb-cloud-faq.md | 4 ++-- tidb-lightning/tidb-lightning-configuration.md | 4 ++-- tidb-lightning/tidb-lightning-glossary.md | 6 +++--- tidb-lightning/tidb-lightning-physical-import-mode.md | 6 +++--- 20 files changed, 30 insertions(+), 30 deletions(-) diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 002f6b3951fed..534b591be767c 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -57,7 +57,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ 2. `OperatorController`キューからオペレーターを取り出し、設定に基づいて一定の同時実行数で実行します。このステップでは、各オペレーターステップを対応するリージョンリーダーに割り当てます。 - 3. オペレーターは"finish"または"timeout"としてマークされ、キューから削除されます。 + 3. オペレーターは「終了」または「タイムアウト」としてマークされ、キューから削除されます。 ### 負荷分散 {#load-balancing} @@ -94,7 +94,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ ### スケールインと障害回復 {#scale-in-and-failure-recovery} -スケールインとは、コマンドを使用してストアをオフラインにし、"offline"としてマークするプロセスを指します。PDは、オフラインノード上のリージョンをスケジュールに従って他のノードに複製します。障害復旧は、ストアに障害が発生し、復旧できない場合に適用されます。この場合、対応するストアに分散されたピアを持つリージョンのレプリカが失われる可能性があり、PDは他のノードでレプリカを補充する必要があります。 +スケールインとは、コマンドを使用してストアをオフラインにし、「オフライン」としてマークするプロセスを指します。PDは、オフラインノード上のリージョンをスケジュールに従って他のノードに複製します。障害復旧は、ストアに障害が発生し、復旧できない場合に適用されます。この場合、対応するストアに分散されたピアを持つリージョンのレプリカが失われる可能性があり、PDは他のノードでレプリカを補充する必要があります。 スケールインと障害回復のプロセスは基本的に同じです。`replicaChecker`は異常な状態にあるリージョン ピアを見つけ、異常なピアを正常なストア上の新しいピアに置き換えるオペレーターを生成します。 diff --git a/develop/dev-guide-use-follower-read.md b/develop/dev-guide-use-follower-read.md index bcb93c928af16..f675db5b9e207 100644 --- a/develop/dev-guide-use-follower-read.md +++ b/develop/dev-guide-use-follower-read.md @@ -20,8 +20,8 @@ TiDBは、 [リージョン](/tidb-storage.md#region)基本単位として、ク 次のいずれかを実行すると、アプリケーションにホットスポットリージョンがあるかどうかを視覚的に分析できます。 -- TiDB Cloud: [TiDB Cloudコンソールのキー ビジュアライザー](/tidb-cloud/tune-performance.md#key-visualizer)に移動し、"metrics selection box"を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 -- TiDB Self-Managed: [TiDB DashboardのKey Visualizer](/dashboard/dashboard-key-visualizer.md)に移動し、"metrics selection box"を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 +- TiDB Cloud: [TiDB Cloudコンソールのキー ビジュアライザー](/tidb-cloud/tune-performance.md#key-visualizer)に移動し、「メトリック選択ボックス」を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 +- TiDB Self-Managed: [TiDB DashboardのKey Visualizer](/dashboard/dashboard-key-visualizer.md)に移動し、「メトリック選択ボックス」を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 ホットスポットの問題が存在する場合は、 [TiDBホットスポットの問題の処理](/troubleshoot-hot-spot-issues.md)を参照してトラブルシューティングを行うことができます。これにより、アプリケーション レベルでのホットスポットの生成を回避することができます。 diff --git a/dm/dm-continuous-data-validation.md b/dm/dm-continuous-data-validation.md index c5cba15f0fb95..909c01fa84264 100644 --- a/dm/dm-continuous-data-validation.md +++ b/dm/dm-continuous-data-validation.md @@ -212,7 +212,7 @@ dmctl は 3つのエラー処理コマンドを提供します。 -h, --help help for clear-error ``` -- `ignore-error` : エラー行を無視します。このエラー行は"ignored"としてマークされます。 +- `ignore-error` : エラー行を無視します。このエラー行は「無視」としてマークされます。 ``` Usage: @@ -223,7 +223,7 @@ dmctl は 3つのエラー処理コマンドを提供します。 -h, --help help for ignore-error ``` -- `resolve-error` : エラー行は手動で処理され、"resolved"としてマークされます。 +- `resolve-error` : エラー行は手動で処理され、「解決済み」としてマークされます。 ``` Usage: diff --git a/dm/dm-replication-logic.md b/dm/dm-replication-logic.md index 00ced62ea3d7b..36e4576995112 100644 --- a/dm/dm-replication-logic.md +++ b/dm/dm-replication-logic.md @@ -16,7 +16,7 @@ summary: DM のコア処理ユニット Sync が DML文を複製する方法に 2. データソースから読み取ったbinlogイベントを変換します。 1. [Binlogフィルター](/dm/dm-binlog-event-filter.md) : `filters`で設定されたbinlog式に従ってbinlogイベントをフィルタリングします。 - 2. [テーブルルーティング](/dm/dm-table-routing.md) : `routes`で設定された"database/table"ルーティングルールに従って"database/table"名を変換します。 + 2. [テーブルルーティング](/dm/dm-table-routing.md) : `routes`で設定された「データベース/テーブル」ルーティングルールに従って「データベース/テーブル」名を変換します。 3. [表現フィルター](/filter-dml-event.md) : `expression-filter`で設定された SQL 式に従ってbinlogイベントをフィルタリングします。 3. DML 実行計画を最適化します。 diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md index 7bf4fab4e91fa..d493631c8daba 100644 --- a/dm/feature-shard-merge-optimistic.md +++ b/dm/feature-shard-merge-optimistic.md @@ -37,7 +37,7 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル - DDL文を実行する際は、DM移行のステータスを確認してください。エラーが報告された場合は、この一連のDDL文がデータの不整合を引き起こすかどうかを判断する必要があります。 -楽観的モードでは、上流で実行されたDDL文の大部分が、追加の作業なしに自動的に下流に移行されます。これらのDDL文は"Type 1 DDL"と呼ばれます。 +楽観的モードでは、上流で実行されたDDL文の大部分が、追加の作業なしに自動的に下流に移行されます。これらのDDL文は「タイプ1 DDL」と呼ばれます。 列名、列の型、または列のデフォルト値を変更するDDL文は"Type 2 DDL"と呼ばれます。アップストリームでType 2 DDL文を実行する場合は、すべてのシャードテーブルで同じ順序でDDL文を実行するようにしてください。 diff --git a/dr-multi-replica.md b/dr-multi-replica.md index 28780efe75c4b..577d9e358700f 100644 --- a/dr-multi-replica.md +++ b/dr-multi-replica.md @@ -18,7 +18,7 @@ summary: 単一クラスターのマルチレプリカ災害復旧ソリュー > **Note:** > -> [TiKVの"Region"](/glossary.md#regionpeerraft-group)データの範囲を意味し、"region"という用語は物理的な場所を意味します。この2つの用語は互換性がありません。 +> [TiKVの「リージョン」](/glossary.md#regionpeerraft-group)データの範囲を意味し、「リージョン」という用語は物理的な場所を意味します。この2つの用語は互換性がありません。 ## クラスターをセットアップしてレプリカを構成する {#set-up-a-cluster-and-configure-replicas} diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index 4c13f79bf7eba..35f668da46285 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -37,7 +37,7 @@ summary: TiCDCに基づいたプライマリセカンダリディザスタリカ > **Note:** > -> - [TiKVの"Region"](/glossary.md#regionpeerraft-group)はデータの範囲を意味し、"region"という用語は物理的な場所を意味します。この2つの用語は互換性がありません。 +> - [TiKVの「リージョン」](/glossary.md#regionpeerraft-group)はデータの範囲を意味し、「領域」という用語は物理的な場所を意味します。この2つの用語は互換性がありません。 > - セカンダリクラスタへのデータ複製のために複数のチェンジフィードを実行したり、既にセカンダリクラスタが存在する状態で別のセカンダリクラスタを実行したりしないでください。そうしないと、セカンダリクラスタのデータトランザクションの整合性が保証されません。 ### プライマリクラスターとセカンダリクラスターを設定する {#set-up-primary-and-secondary-clusters} diff --git a/glossary.md b/glossary.md index cca53fe951de0..dc08033492149 100644 --- a/glossary.md +++ b/glossary.md @@ -260,7 +260,7 @@ PD Control (pd-ctl) は、TiDB クラスタ内の Placement Driver (PD) と対 ### 保留中／ダウン中（Pending/Down） {#pendingdown} -"Pending"と"Down"は、ピアの2つの特別な状態です。"Pending"とは、フォロワーまたはラーナーのRaftログがリーダーのログと大きく異なる状態を指します。保留中のフォロワーはリーダーに選出されません。"Down"とは、ピアが長時間リーダーに応答しなくなった状態を指し、通常は対応するノードがダウンしているか、ネットワークから孤立していることを意味します。 +「保留中」と「ダウン」は、ピアの2つの特別な状態です。「保留中」とは、フォロワーまたはラーナーのRaftログがリーダーのログと大きく異なる状態を指します。保留中のフォロワーはリーダーに選出されません。「ダウン」とは、ピアが長時間リーダーに応答しなくなった状態を指し、通常は対応するノードがダウンしているか、ネットワークから孤立していることを意味します。 ### Placement Driver（PD） {#placement-driver-pd} diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md index 251117d27b775..f601f6f18e592 100644 --- a/multi-data-centers-in-one-city-deployment.md +++ b/multi-data-centers-in-one-city-deployment.md @@ -15,7 +15,7 @@ summary: 1つのリージョン内の複数のアベイラビリティゾーン 分散SQLデータベースであるTiDBは、従来のリレーショナルデータベースの優れた機能とNoSQLデータベースのスケーラビリティを兼ね備え、複数のアベイラビリティゾーン（AZ）をまたがる高可用性を実現します。このドキュメントでは、1つのリージョンに複数のAZをデプロイする方法について説明します。 -このドキュメントにおける"region"という用語は地理的な領域を指し、大文字の"Region"はTiKVにおけるデータストレージの基本単位を指します。"AZ"はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 +このドキュメントにおける「リージョン」という用語は地理的な領域を指し、「リージョン」はTiKVにおけるデータストレージの基本単位を指します。「AZ」はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 ## Raftプロトコル {#raft-protocol} diff --git a/releases/release-6.2.0.md b/releases/release-6.2.0.md index 1a1b343f3ceb7..1f96c2cefe040 100644 --- a/releases/release-6.2.0.md +++ b/releases/release-6.2.0.md @@ -170,7 +170,7 @@ TiDBバージョン: 6.2.0-DMR - トランザクションにおけるセーブポイントの設定をサポートする - トランザクションとは、データベースがACID特性を保証する一連の連続した操作の論理的な集合です。複雑なアプリケーションシナリオでは、トランザクション内で多数の操作を管理する必要があり、場合によってはトランザクション内の操作をロールバックする必要が生じることもあります。"Savepoint"は、トランザクションの内部実装のための名前付きメカニズムです。このメカニズムを使用することで、トランザクション内のロールバックポイントを柔軟に制御でき、より複雑なトランザクションを管理し、多様なアプリケーション設計においてより自由度を高めることができます。 + トランザクションとは、データベースがACID特性を保証する一連の連続した操作の論理的な集合です。複雑なアプリケーションシナリオでは、トランザクション内で多数の操作を管理する必要があり、場合によってはトランザクション内の操作をロールバックする必要が生じることもあります。「セーブポイント」は、トランザクションの内部実装のための名前付きメカニズムです。このメカニズムを使用することで、トランザクション内のロールバックポイントを柔軟に制御でき、より複雑なトランザクションを管理し、多様なアプリケーション設計においてより自由度を高めることができます。 [ユーザー向けドキュメント](/sql-statements/sql-statement-savepoint.md) [#6840](https://github.com/pingcap/tidb/issues/6840) @[crazycs520](https://github.com/crazycs520) @@ -224,7 +224,7 @@ TiDBバージョン: 6.2.0-DMR [ユーザー向けドキュメント](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#scope-of-pausing-scheduling-during-import) [#35148](https://github.com/pingcap/tidb/issues/35148) @[sleepymole](https://github.com/sleepymole) -- [TiDB Lightningのユーザー向けドキュメント](/tidb-lightning/tidb-lightning-overview.md)ドキュメントをリファクタリングして、その構造をより合理的かつ明確にします。 "backend"の用語も、新規ユーザーの理解の障壁を下げるために変更されています。 +- [TiDB Lightningのユーザー向けドキュメント](/tidb-lightning/tidb-lightning-overview.md)ドキュメントをリファクタリングして、その構造をより合理的かつ明確にします。 「バックエンド」の用語も、新規ユーザーの理解の障壁を下げるために変更されています。 - "local backend"を"physical import mode"に置き換えてください。 - "tidb backend"を"logical import mode"に置き換えてください。 diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index 22ec4f823c851..d8654c14b5288 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -212,7 +212,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 v7.1.0 では、TiDB Enterprise Edition でデータベース監査機能が強化され、その機能が大幅に拡張され、ユーザーエクスペリエンスが向上して、企業のデータベース セキュリティ コンプライアンスのニーズに対応できるようになりました。 - - より詳細な監査イベント定義とよりきめ細かな監査設定のために、"Filter"と"Rule"の概念を導入します。 + - より詳細な監査イベント定義とよりきめ細かな監査設定のために、「フィルター」と「ルール」の概念を導入します。 - JSON 形式でのルールの定義をサポートし、よりユーザーフレンドリーな構成方法を提供します。 - 自動ログローテーションとスペース管理関数を追加し、保持時間とログサイズの 2つの次元でのログローテーションの構成をサポートします。 - 監査ログをTEXTと JSON 形式の両方で出力できるようにすることで、サードパーティツールとの統合が容易になります。 diff --git a/releases/release-7.5.0.md b/releases/release-7.5.0.md index 1fec196115432..f45b6e6f120a7 100644 --- a/releases/release-7.5.0.md +++ b/releases/release-7.5.0.md @@ -15,7 +15,7 @@ TiDB 7.5.0は長期サポートリリース（LTS）です。 以前の LTS 7.1.0 と比較して、7.5.0 には[7.2.0-DMR](/releases/release-7.2.0.md) 、 [7.3.0-DMR](/releases/release-7.3.0.md) 、および[7.4.0-DMR](/releases/release-7.4.0.md)でリリースされた新機能、改善点、およびバグ修正が含まれています。7.1.x から 7.5.0 にアップグレードすると、 [TiDB リリースノート PDF](https://docs-download.pingcap.com/pdf/tidb-v7.2-to-v7.5-en-release-notes.pdf)をダウンロードして、2つの LTS バージョン間のすべてのリリースノートを確認できます。次の表は、7.2.0 から 7.5.0 までのハイライトの一部を示しています。 -
カテゴリ特徴説明
拡張性とパフォーマンス複数のADD INDEXステートメントを並列実行することをサポートするこの機能により、単一のテーブルに対して複数のインデックスを同時に追加するジョブを実行できます。従来は、2つのADD INDEXステートメント（XとY ）を同時に実行するには、Xの実行時間とYの実行時間を合わせた時間が必要でした。この機能により、1つのSQLで2つのインデックスXとYを同時に追加できるため、DDLの実行時間が大幅に短縮されます。特に、テーブルサイズが大きいシナリオでは、社内テストデータによると、パフォーマンスが最大94%向上することが示されています。
信頼性と可用性グローバルソートの最適化（実験的、v7.4.0で導入） TiDB v7.1.0 では 、分散実行フレームワーク (DXF)が導入されました。v7.4 では、このフレームワークを活用するタスク向けにグローバルソートが導入され、データ再編成タスク中に一時的にデータが順不同になることで発生する不要な I/O、CPU、およびメモリの急増を解消します。グローバルソートは、外部共有オブジェクトストレージ(この最初のバージョンでは Amazon S3) を利用してジョブ実行中に中間ファイルを保存することで、柔軟性とコスト削減を実現します。ADD ADD INDEXやIMPORT INTOなどの操作は、より高速で、より堅牢で、より安定し、より柔軟になり、実行コストも削減されます。
バックグラウンドタスクのリソース制御（実験的、v7.4.0で導入）バージョン7.1.0では、ワークロード間のリソースおよびストレージアクセス干渉を軽減するために、リソース制御機能が導入されました。TiDB v7.4.0では、この制御がバックグラウンドタスクの優先度にも適用されるようになりました。v7.4.0では、リソース制御により、自動分析、バックアップと復元、 TiDB Lightningによる一括ロード、オンラインDDLなどのバックグラウンドタスクの実行優先度が識別され、管理されるようになりました。今後のリリースでは、この制御は最終的にすべてのバックグラウンドタスクに適用される予定です。
暴走クエリを管理するためのリソース制御（実験的、v7.2.0で導入）リソース制御は、リソースグループごとにワークロードをリソース分離するためのフレームワークですが、各グループ内の個々のクエリが作業にどのように影響するかについては何も規定していません。TiDB v7.2.0 では、"runaway queries control"が導入され、リソースグループごとに TiDB がこれらのクエリをどのように識別して処理するかを制御できるようになりました。必要に応じて、実行時間の長いクエリを終了または制限することができ、クエリは、より汎用性を高めるために、正確な SQL テキスト、SQL ダイジェスト、または実行計画 ダイジェストで識別できます。v7.3.0 では、データベースレベルの SQL ブロックリストと同様に、既知の不正なクエリを事前に監視できるようになりました。
SQL MySQL 8.0との互換性（バージョン7.4.0で導入） MySQL 8.0 では、デフォルトの文字セットは utf8mb4 であり、utf8mb4 のデフォルトの照合照合順序はutf8mb4_0900_ai_ciです。TiDB v7.4.0 でこのサポートが追加されたことで、MySQL 8.0 との互換性が向上し、デフォルトの照合順序を持つ MySQL 8.0 データベースからの移行やレプリケーションがはるかにスムーズになりました。
データベースの運用と可観測性TiDB Lightningの物理インポートモードがIMPORT INTO (GA)でTiDBに統合されましたバージョン7.2.0より前は、ファイルシステムに基づいてデータをインポートするには、 TiDB Lightningをインストールし、その物理インポートモードを使用する必要がありました。現在では、同じ機能がIMPORT INTOステートメントに統合されているため、追加のツールをインストールすることなく、このステートメントを使用してデータを迅速にインポートできます。このステートメントは、並列インポート用の 分散実行フレームワーク（DXF）もサポートしており、大規模なインポート時のインポート効率が向上します。
ADD INDEXおよびIMPORT INTO SQL文を実行するTiDBノードを指定します（GA）。既存のTiDBノードの一部、または新しく追加されたTiDBノードでADD INDEXまたはIMPORT INTO SQL文を実行するかどうかを柔軟に指定できます。このアプローチにより、他のTiDBノードからリソースを分離できるため、業務への影響を防ぎながら、前述のSQL文の実行において最適なパフォーマンスを確保できます。この機能は、バージョン7.5.0で一般提供（GA）されます。
DDLは一時停止および再開操作をサポートします（一般提供）。インデックスの追加は大量のリソースを消費し、オンラインのトラフィックに影響を与える可能性があります。リソースグループでスロットリングしたり、ラベル付きノードに隔離したりした場合でも、緊急時にはこれらのジョブを一時停止する必要が生じる場合があります。TiDBはバージョン7.2.0以降、これらのバックグラウンドジョブを一度にいくつでも一時停止できる機能をネイティブにサポートしており、ジョブのキャンセルと再起動を回避しながら必要なリソースを解放できます。
TiDB DashboardはTiKVのヒーププロファイリングをサポートしています従来、TiKVのメモリ不足（OOM）やメモリ使用量過多の問題に対処するには、インスタンス環境でjeprofを手動で実行してヒーププロファイルを生成する必要がありました。v7.5.0以降、TiKVはヒーププロファイルのリモート処理に対応しました。これにより、ヒーププロファイルのフレームグラフとコールグラフに直接アクセスできるようになりました。この機能は、Goのヒーププロファイリングと同様に、シンプルで使いやすい操作性を提供します。
+
カテゴリ特徴説明
拡張性とパフォーマンス複数のADD INDEXステートメントを並列実行することをサポートするこの機能により、単一のテーブルに対して複数のインデックスを同時に追加するジョブを実行できます。従来は、2つのADD INDEXステートメント（XとY ）を同時に実行するには、Xの実行時間とYの実行時間を合わせた時間が必要でした。この機能により、1つのSQLで2つのインデックスXとYを同時に追加できるため、DDLの実行時間が大幅に短縮されます。特に、テーブルサイズが大きいシナリオでは、社内テストデータによると、パフォーマンスが最大94%向上することが示されています。
信頼性と可用性グローバルソートの最適化（実験的、v7.4.0で導入） TiDB v7.1.0 では 、分散実行フレームワーク (DXF)が導入されました。v7.4 では、このフレームワークを活用するタスク向けにグローバルソートが導入され、データ再編成タスク中に一時的にデータが順不同になることで発生する不要な I/O、CPU、およびメモリの急増を解消します。グローバルソートは、外部共有オブジェクトストレージ(この最初のバージョンでは Amazon S3) を利用してジョブ実行中に中間ファイルを保存することで、柔軟性とコスト削減を実現します。ADD ADD INDEXやIMPORT INTOなどの操作は、より高速で、より堅牢で、より安定し、より柔軟になり、実行コストも削減されます。
バックグラウンドタスクのリソース制御（実験的、v7.4.0で導入）バージョン7.1.0では、ワークロード間のリソースおよびストレージアクセス干渉を軽減するために、リソース制御機能が導入されました。TiDB v7.4.0では、この制御がバックグラウンドタスクの優先度にも適用されるようになりました。v7.4.0では、リソース制御により、自動分析、バックアップと復元、 TiDB Lightningによる一括ロード、オンラインDDLなどのバックグラウンドタスクの実行優先度が識別され、管理されるようになりました。今後のリリースでは、この制御は最終的にすべてのバックグラウンドタスクに適用される予定です。
暴走クエリを管理するためのリソース制御（実験的、v7.2.0で導入）リソース制御は、リソースグループごとにワークロードをリソース分離するためのフレームワークですが、各グループ内の個々のクエリが作業にどのように影響するかについては何も規定していません。TiDB v7.2.0 では、「暴走クエリ制御」が導入され、リソースグループごとに TiDB がこれらのクエリをどのように識別して処理するかを制御できるようになりました。必要に応じて、実行時間の長いクエリを終了または制限することができ、クエリは、より汎用性を高めるために、正確な SQL テキスト、SQL ダイジェスト、または実行計画 ダイジェストで識別できます。v7.3.0 では、データベースレベルの SQL ブロックリストと同様に、既知の不正なクエリを事前に監視できるようになりました。
SQL MySQL 8.0との互換性（バージョン7.4.0で導入） MySQL 8.0 では、デフォルトの文字セットは utf8mb4 であり、utf8mb4 のデフォルトの照合照合順序はutf8mb4_0900_ai_ciです。TiDB v7.4.0 でこのサポートが追加されたことで、MySQL 8.0 との互換性が向上し、デフォルトの照合順序を持つ MySQL 8.0 データベースからの移行やレプリケーションがはるかにスムーズになりました。
データベースの運用と可観測性TiDB Lightningの物理インポートモードがIMPORT INTO (GA)でTiDBに統合されましたバージョン7.2.0より前は、ファイルシステムに基づいてデータをインポートするには、 TiDB Lightningをインストールし、その物理インポートモードを使用する必要がありました。現在では、同じ機能がIMPORT INTOステートメントに統合されているため、追加のツールをインストールすることなく、このステートメントを使用してデータを迅速にインポートできます。このステートメントは、並列インポート用の 分散実行フレームワーク（DXF）もサポートしており、大規模なインポート時のインポート効率が向上します。
ADD INDEXおよびIMPORT INTO SQL文を実行するTiDBノードを指定します（GA）。既存のTiDBノードの一部、または新しく追加されたTiDBノードでADD INDEXまたはIMPORT INTO SQL文を実行するかどうかを柔軟に指定できます。このアプローチにより、他のTiDBノードからリソースを分離できるため、業務への影響を防ぎながら、前述のSQL文の実行において最適なパフォーマンスを確保できます。この機能は、バージョン7.5.0で一般提供（GA）されます。
DDLは一時停止および再開操作をサポートします（一般提供）。インデックスの追加は大量のリソースを消費し、オンラインのトラフィックに影響を与える可能性があります。リソースグループでスロットリングしたり、ラベル付きノードに隔離したりした場合でも、緊急時にはこれらのジョブを一時停止する必要が生じる場合があります。TiDBはバージョン7.2.0以降、これらのバックグラウンドジョブを一度にいくつでも一時停止できる機能をネイティブにサポートしており、ジョブのキャンセルと再起動を回避しながら必要なリソースを解放できます。
TiDB DashboardはTiKVのヒーププロファイリングをサポートしています従来、TiKVのメモリ不足（OOM）やメモリ使用量過多の問題に対処するには、インスタンス環境でjeprofを手動で実行してヒーププロファイルを生成する必要がありました。v7.5.0以降、TiKVはヒーププロファイルのリモート処理に対応しました。これにより、ヒーププロファイルのフレームグラフとコールグラフに直接アクセスできるようになりました。この機能は、Goのヒーププロファイリングと同様に、シンプルで使いやすい操作性を提供します。
## 機能の詳細 {#feature-details} diff --git a/three-data-centers-in-two-cities-deployment.md b/three-data-centers-in-two-cities-deployment.md index 9be69c65f859c..e8edfacd3fd51 100644 --- a/three-data-centers-in-two-cities-deployment.md +++ b/three-data-centers-in-two-cities-deployment.md @@ -7,7 +7,7 @@ summary: 2つのリージョンにある 3つのアベイラビリティゾー このドキュメントでは、2つのリージョンデプロイにおける 3つのアベイラビリティゾーン (AZ) のアーキテクチャと構成について説明します。 -このドキュメントにおける"region"という用語は地理的な領域を指し、大文字の"Region"はTiKVにおけるデータストレージの基本単位を指します。"AZ"はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 +このドキュメントにおける「リージョン」という用語は地理的な領域を指し、「リージョン」はTiKVにおけるデータストレージの基本単位を指します。「AZ」はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 ## 概要 {#overview} diff --git a/ticdc/ticdc-debezium.md b/ticdc/ticdc-debezium.md index 2ad3a98c89fc0..3900897370e94 100644 --- a/ticdc/ticdc-debezium.md +++ b/ticdc/ticdc-debezium.md @@ -5,7 +5,7 @@ summary: TiCDC Debezium プロトコルの概念とその使用方法を学び # TiCDC Debeziumプロトコル {#ticdc-debezium-protocol} -TiCDC [Debezium](https://debezium.io/) 、データベースの変更をキャプチャするためのツールです。キャプチャされたデータベースの変更はそれぞれ"event"と呼ばれるメッセージに変換され、Kafka に送信されます。v8.0.0以降、TiCDCはDebezium形式でTiDBの行データ変更（DMLイベント）をKafkaに直接送信することをサポートしているため、これまでDebeziumのMySQL統合を使用していたユーザーにとって、MySQLデータベースからの移行が簡素化されます。[TiCDC v8.5.4-release.1](https://github.com/pingcap/ticdc/releases/tag/v8.5.4-release.1)（[新しい TiCDC アーキテクチャ](/ticdc/ticdc-architecture.md)）以降、TiCDC は Debezium 形式で DDL イベントと WATERMARK イベントを送信することもサポートしています。 +TiCDCの[Debezium](https://debezium.io/)は、データベースの変更をキャプチャするためのツールです。キャプチャされたデータベースの変更はそれぞれ「イベント」と呼ばれるメッセージに変換され、Kafka に送信されます。v8.0.0以降、TiCDCはDebezium形式でTiDBの行データ変更（DMLイベント）をKafkaに直接送信することをサポートしているため、これまでDebeziumのMySQL統合を使用していたユーザーにとって、MySQLデータベースからの移行が簡素化されます。[TiCDC v8.5.4-release.1](https://github.com/pingcap/ticdc/releases/tag/v8.5.4-release.1)（[新しい TiCDC アーキテクチャ](/ticdc/ticdc-architecture.md)）以降、TiCDC は Debezium 形式で DDL イベントと WATERMARK イベントを送信することもサポートしています。 ## Debeziumメッセージ形式を使用する {#use-the-debezium-message-format} diff --git a/tidb-cloud/changefeed-sink-to-apache-kafka.md b/tidb-cloud/changefeed-sink-to-apache-kafka.md index 5fdb06de337ac..2c58e708ad514 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -277,7 +277,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン - Avroは、コンパクトで高速なバイナリデータフォーマットであり、豊富なデータ構造を備え、様々なフローシステムで広く利用されています。詳細については、 [Avroデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol)を参照してください。 - Canal-JSONは、解析が容易なプレーンなJSONテキスト形式です。詳細については、 [Canal-JSONデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-canal-json)を参照してください。 - オープンプロトコルは、監視、キャッシュ、全文インデックス作成、分析エンジン、および異なるデータベース間のプライマリとセカンダリのレプリケーションのためのデータソースを提供する行レベルのデータ変更通知プロトコルです。詳細については、 [オープンプロトコルデータフォーマット](https://docs.pingcap.com/tidb/stable/ticdc-open-protocol)を参照してください。 - - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を"event"と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)を参照してください。 + - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を「イベント」と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)を参照してください。 5. TiDB拡張フィールドをKafkaメッセージ本文に追加する場合は、 **TiDB Extension**オプションを有効にしてください。 diff --git a/tidb-cloud/essential-changefeed-sink-to-kafka.md b/tidb-cloud/essential-changefeed-sink-to-kafka.md index 4abc617cce7d4..052db36d141e9 100644 --- a/tidb-cloud/essential-changefeed-sink-to-kafka.md +++ b/tidb-cloud/essential-changefeed-sink-to-kafka.md @@ -153,7 +153,7 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト - Avroは、コンパクトで高速なバイナリデータフォーマットであり、豊富なデータ構造を備え、様々なフローシステムで広く利用されています。詳細については、 [Avroデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol)を参照してください。 - Canal-JSONは、解析が容易なプレーンなJSONテキスト形式です。詳細については、 [Canal-JSONデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-canal-json)を参照してください。 - オープンプロトコルは、監視、キャッシュ、全文インデックス作成、分析エンジン、および異なるデータベース間のプライマリとセカンダリのレプリケーションのためのデータソースを提供する行レベルのデータ変更通知プロトコルです。詳細については、 [オープンプロトコルデータフォーマット](https://docs.pingcap.com/tidb/stable/ticdc-open-protocol)を参照してください。 - - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を"event"と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)を参照してください。 + - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を「イベント」と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)を参照してください。 5. TiDB拡張フィールドをKafkaメッセージ本文に追加する場合は、 **TiDB Extension**オプションを有効にしてください。 diff --git a/tidb-cloud/tidb-cloud-faq.md b/tidb-cloud/tidb-cloud-faq.md index 8a402f8cb9f62..96ecdca27dedc 100644 --- a/tidb-cloud/tidb-cloud-faq.md +++ b/tidb-cloud/tidb-cloud-faq.md @@ -55,7 +55,7 @@ TiDBは、金融サービス、ゲーム、eコマースなど、さまざまな TiDB Cloudは99.99% の SLA を提供します。詳細については、 [TiDB Cloudサービスのサービスレベル契約](https://www.pingcap.com/legal/service-level-agreement-for-tidb-cloud-services/)を参照してください。 -### TiDB Cloudにおける"PREVIEW"とはどういう意味ですか？ {#what-does-preview-mean-in-tidb-cloud} +### TiDB Cloudにおける「PREVIEW」とはどういう意味ですか？ {#what-does-preview-mean-in-tidb-cloud} PREVIEWとは、 TiDB Cloudの機能またはサービスが一般提供（GA）される前に、一般公開されるプレビュー段階のことです。 @@ -87,7 +87,7 @@ Placement Driver（PD）は、クラスターのメタデータを格納する ### TiDBはTiKVノード間でどのようにデータを複製するのですか？ {#how-does-tidb-replicate-data-between-the-tikv-nodes} -TiKVはキーと値のペアの空間をキー範囲に分割し、各キー範囲を"Region"として扱います。TiKVでは、データはクラスタ内のすべてのノードに分散され、リージョンを基本単位として使用します。PDは、リージョンをクラスタ内のすべてのノードにできるだけ均等に分散（スケジューリング）する役割を担います。 +TiKVはキーと値のペアの空間をキー範囲に分割し、各キー範囲を「リージョン」として扱います。TiKVでは、データはクラスタ内のすべてのノードに分散され、リージョンを基本単位として使用します。PDは、リージョンをクラスタ内のすべてのノードにできるだけ均等に分散（スケジューリング）する役割を担います。 TiDBは、 Raftコンセンサスアルゴリズムを使用して、リージョンごとにデータを複製します。異なるノードに保存されたリージョンの複数のレプリカがRaftグループを形成します。 diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index 0a1b8620fbcbc..032862c4a1b1c 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -7,7 +7,7 @@ summary: TiDB Lightningの CLI の使用方法とサンプル構成について このドキュメントでは、グローバル設定とタスク設定のサンプルを提供し、コマンドラインパラメータの使用方法を説明します。サンプル設定ファイルは[`lightning/tidb-lightning.toml`](https://github.com/pingcap/tidb/blob/master/lightning/tidb-lightning.toml)にあります。 -TiDB Lightningには"global"と"task"という2つの設定クラスがあり、構造は互換性があります。これらの違いは、サーバーモードが有効な場合にのみ発生します。サーバーモードが無効（デフォルト）の場合、TiDB Lightningは1つのタスクのみを実行し、グローバル設定とタスク設定の両方に同じ設定ファイルを使用します。 +TiDB Lightningには「グローバル」と「タスク」という2つの設定クラスがあり、構造は互換性があります。これらの違いは、サーバーモードが有効な場合にのみ発生します。サーバーモードが無効（デフォルト）の場合、TiDB Lightningは1つのタスクのみを実行し、グローバル設定とタスク設定の両方に同じ設定ファイルを使用します。 ## TiDB Lightning （グローバル） {#tidb-lightning-global} @@ -414,7 +414,7 @@ TiDB Lightningには"global"と"task"という2つの設定クラスがあり、 - 値のオプション: `true` 、 `false` - `strict-format = true`次のことが求められます: - CSV では、引用符で囲まれている場合でも、すべての値にリテラルの改行 ( `U+000A`と`U+000D` 、または`\r`と`\n` ) を含めることはできません。つまり、改行は行を区切るために厳密に使用されます。 - - 厳密なフォーマットにより、 TiDB Lightningは並列処理において大きなファイルの分割位置を迅速に特定できます。ただし、入力データが"strict"でない場合、有効なデータが半分に分割され、結果が破損する可能性があります。 + - 厳密なフォーマットにより、 TiDB Lightningは並列処理において大きなファイルの分割位置を迅速に特定できます。ただし、入力データが「厳密」でない場合、有効なデータが半分に分割され、結果が破損する可能性があります。 #### `max-region-size` {#max-region-size} diff --git a/tidb-lightning/tidb-lightning-glossary.md b/tidb-lightning/tidb-lightning-glossary.md index 3244ff136d95e..060beffabc0c6 100644 --- a/tidb-lightning/tidb-lightning-glossary.md +++ b/tidb-lightning/tidb-lightning-glossary.md @@ -31,7 +31,7 @@ TiDB LightningはTiDBを経由せずにデータをインポートするため ### バックエンド {#back-end} -バックエンドとは、TiDB Lightningが解析結果を送信する宛先です。"backend"とも表記されます。 +バックエンドとは、TiDB Lightningが解析結果を送信する宛先です。「backend」とも表記されます。 詳細は[TiDB Lightningアーキテクチャ](/tidb-lightning/tidb-lightning-overview.md)を参照。 @@ -93,7 +93,7 @@ TiKV インポーターでは、エンジンは KV ペアをソートするた TiDB Lightningは、エンジンを介してTiKV Importerにデータを転送します。まずエンジンを開き、KVペアを（順序は問わず）エンジンに送信し、最後にエンジンを閉じます。エンジンは閉じた後、受信したKVペアをソートします。閉じられたエンジンは、TiKVストアにアップロードして取り込みを行うことができます。 -エンジンは TiKV インポーターの`import-dir`を一時ストレージとして使用します。これは"engine files"と呼ばれることもあります。 +エンジンは TiKV インポーターの`import-dir`を一時ストレージとして使用します。これは「エンジンファイル」と呼ばれることもあります。 [データエンジン](/tidb-lightning/tidb-lightning-glossary.md#data-engine)と[インデックスエンジン](/tidb-lightning/tidb-lightning-glossary.md#index-engine)も参照してください。 @@ -139,7 +139,7 @@ TiDB Lightningは複数のインデックスエンジンを同時に処理しま ### KVペア {#kv-pair} -"key-value pair"の略語。 +「キーと値のペア」の略語。 ### KVエンコーダ {#kv-encoder} diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md index 6cadfbb29edff..72e68af080c32 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode.md @@ -19,7 +19,7 @@ backend = "local" ## 実装 {#implementation} -1. TiDB Lightningは、データをインポートする前に、TiKVノードを自動的に"import mode"に切り替えます。これにより、書き込みパフォーマンスが向上し、自動コンパクションが停止します。TiDB Lightningは、 TiDB Lightningのバージョンに応じて、グローバルスケジューリングを一時停止するかどうかを決定します。 +1. TiDB Lightningは、データをインポートする前に、TiKVノードを自動的に「インポートモード」に切り替えます。これにより、書き込みパフォーマンスが向上し、自動コンパクションが停止します。TiDB Lightningは、 TiDB Lightningのバージョンに応じて、グローバルスケジューリングを一時停止するかどうかを決定します。 - v7.1.0 以降では、 TiDB Lightningパラメータ[`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md)を使用して、一時停止スケジュールの範囲を制御できます。 - TiDB Lightningバージョン v6.2.0 から v7.0.0 の場合、グローバルスケジューリングの一時停止の動作は TiDB クラスタのバージョンによって異なります。TiDB クラスタが v6.1.0 以上の場合、 TiDB Lightning はターゲットテーブルデータが格納されているリージョンのスケジューリングを一時停止します。インポートが完了すると、 TiDB Lightning はスケジューリングを回復します。その他のバージョンの場合、 TiDB Lightning はグローバルスケジューリングを一時停止します。 @@ -31,7 +31,7 @@ backend = "local" 3. 各テーブルは複数の連続した**ブロック**に分割されるため、 TiDB Lightning は大規模なテーブル (200 GB 以上) からデータを並列にインポートできます。 -4. TiDB Lightningは、キーと値のペアを処理するために、各ブロックごとに"engine file"を用意します。TiDB LightningはSQLダンプを並列に読み取り、データソースをTiDBと同じエンコーディングでキーと値のペアに変換し、キーと値のペアをソートしてローカルの一時ストレージファイルに書き込みます。 +4. TiDB Lightningは、キーと値のペアを処理するために、各ブロックごとに「エンジンファイル」を用意します。TiDB LightningはSQLダンプを並列に読み取り、データソースをTiDBと同じエンコーディングでキーと値のペアに変換し、キーと値のペアをソートしてローカルの一時ストレージファイルに書き込みます。 5. エンジンファイルが書き込まれると、 TiDB Lightning はターゲット TiKV クラスター上のデータの分割とスケジュールを開始し、その後、データを TiKV クラスターにインポートします。 @@ -43,7 +43,7 @@ backend = "local" AUTO_INCREMENT IDは行数の**上限**に基づいて推定され、テーブルデータファイルの合計サイズに比例します。そのため、AUTO_INCREMENT IDは通常、実際の行数よりも大きくなります。これは、AUTO_INCREMENT IDが[必ずしも連続しているわけではない](/mysql-compatibility.md#auto-increment-id)ため、正常な動作です。 -7. すべての手順が完了すると、 TiDB Lightningは自動的にTiKVノードを"normal mode"に切り替えます。グローバルスケジューリングが一時停止されている場合、 TiDB Lightningはグローバルスケジューリングも回復します。その後、TiDBクラスタは通常通りサービスを提供できるようになります。 +7. すべての手順が完了すると、 TiDB Lightningは自動的にTiKVノードを「通常モード」に切り替えます。グローバルスケジューリングが一時停止されている場合、 TiDB Lightningはグローバルスケジューリングも回復します。その後、TiDBクラスタは通常通りサービスを提供できるようになります。 ## 要件と制限 {#requirements-and-restrictions} From 31350246952f80590f0854b95a5d9624ff3677dc Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 11:03:12 +0900 Subject: [PATCH 52/56] i18n(ja): revert index engine/data engine definitional quotes to established Japanese terms --- tidb-lightning/tidb-lightning-configuration.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index 032862c4a1b1c..e6468c23f37b8 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -68,13 +68,13 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `index-concurrency` {#index-concurrency} -- 同時に開くインデックスエンジンの最大数。各テーブルは、インデックスを格納する1つの"index engine"と、行データを格納する複数の"data engine"に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時実行数を制御します。通常はデフォルト値を使用してください。 +- 同時に開くインデックスエンジンの最大数。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時実行数を制御します。通常はデフォルト値を使用してください。 #### `table-concurrency` {#table-concurrency} -- 同時に開くことができるデータエンジンの最大数です。各テーブルは、インデックスを格納する1つの"index engine"と、行データを格納する複数の"data engine"に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時接続数を制御します。通常はデフォルト値を使用してください。 +- 同時に開くことができるデータエンジンの最大数です。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時接続数を制御します。通常はデフォルト値を使用してください。 From de7f708072199139a2aa7cdb038996cbd1a7a053 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 14:02:45 +0900 Subject: [PATCH 53/56] i18n(ja): remove spurious bold around SQL Statements/Slow Queries page names, matching unbolded EN prose --- dashboard/dashboard-intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md index a8a25fe6eb130..19fb5595a8941 100644 --- a/dashboard/dashboard-intro.md +++ b/dashboard/dashboard-intro.md @@ -37,13 +37,13 @@ TiDB DashboardのKey Visualizer機能は、クラスター全体の読み取り/ ## すべてのSQL文の実行情報のリストを表示します {#show-a-list-of-execution-information-of-all-sql-statements} -すべてのSQL文の実行情報は、**SQL Statements**ページに表示されます。このページでは、すべてのステージにおける実行時間と合計実行回数を確認できます。これにより、最もリソースを消費しているSQLクエリを分析して特定し、クラスター全体のパフォーマンスを向上させることができます。 +すべてのSQL文の実行情報は、SQL Statementsページに表示されます。このページでは、すべてのステージにおける実行時間と合計実行回数を確認できます。これにより、最もリソースを消費しているSQLクエリを分析して特定し、クラスター全体のパフォーマンスを向上させることができます。 詳細は[TiDB DashboardのSQL Statementsページ](/dashboard/dashboard-statement-list.md)参照。 ## スロークエリの詳細な実行情報を知る {#learn-the-detailed-execution-information-of-slow-queries} -TiDB Dashboardの**Slow Queries**ページには、実行に時間のかかるすべてのSQL文のリスト（SQLテキストと実行情報を含む）が表示されます。このページは、スロークエリやパフォーマンスジッターの原因を特定するのに役立ちます。 +TiDB DashboardのSlow Queriesページには、実行に時間のかかるすべてのSQL文のリスト（SQLテキストと実行情報を含む）が表示されます。このページは、スロークエリやパフォーマンスジッターの原因を特定するのに役立ちます。 詳細は[スロークエリページ](/dashboard/dashboard-slow-query.md)を参照。 From 56b771d6543fcff333960b1efbba85780e4c4f2c Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 14:05:06 +0900 Subject: [PATCH 54/56] i18n(ja): fix literal config filename, quote-character mismatches, and register inconsistency in WEEK() mode descriptions --- benchmark/benchmark-tidb-using-sysbench.md | 2 +- functions-and-operators/date-and-time-functions.md | 12 ++++++------ partitioned-table.md | 2 +- .../troubleshoot-import-access-denied-error.md | 4 ++-- upgrade-tidb-using-tiup.md | 2 +- 5 files changed, 11 insertions(+), 11 deletions(-) diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 0a4cb5b647c50..3033905c98a97 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -77,7 +77,7 @@ db-driver=mysql 上記のパラメータは、実際のニーズに合わせて調整できます。`TIDB_HOST`はTiDBサーバーのIPアドレス（設定ファイルに複数のアドレスを含めることはできないため）、 `threads`はテストにおける同時接続数で、"8, 16, 32, 64, 128, 256"の範囲で調整できます。データをインポートする際は、threads = 8または16に設定することをお勧めします`threads`を調整したら、 **config**というファイルを保存します。 -サンプル**設定**ファイルとして以下を参照してください。 +サンプル**config**ファイルとして以下を参照してください。 ```txt mysql-host=172.16.30.33 diff --git a/functions-and-operators/date-and-time-functions.md b/functions-and-operators/date-and-time-functions.md index 3480680464a3a..02bea799ce176 100644 --- a/functions-and-operators/date-and-time-functions.md +++ b/functions-and-operators/date-and-time-functions.md @@ -50,9 +50,9 @@ TiDB は、MySQL 8.0 で利用可能な[日付と時刻関数](https://dev.mysql | [`MONTHNAME()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_monthname) | 月の名前を返す | | [`NOW()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_now) | 現在の日付と時刻を返す | | [`PERIOD_ADD()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_period-add) | 年月にピリオドを追加する | -| [`PERIOD_DIFF()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_period-diff) | 期間間の月数を返す | +| [`PERIOD_DIFF()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_period-diff) | 2つの期間間の月数を返す | | [`QUARTER()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_quarter) | 日付引数から四半期を返す | -| [`SEC_TO_TIME()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_sec-to-time) | 秒を"HH:MM:SS"形式に変換します | +| [`SEC_TO_TIME()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_sec-to-time) | 秒を'HH:MM:SS'形式に変換します | | [`SECOND()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_second) | 秒を返す（0～59） | | [`STR_TO_DATE()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_str-to-date) | 文字列を日付に変換する | | [`SUBDATE()`](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_subdate) | 3つの引数で呼び出された場合のDATE_SUB()の同義語 | @@ -87,10 +87,10 @@ TiDB は、MySQL 8.0 で利用可能な[日付と時刻関数](https://dev.mysql | -------------- | -------------------------------------------------- | | "%a" | 曜日の略称（日～土） | | "%D" | 英語の接尾辞付きの月日（0日、1日、2日、3日） | -| "%U" | 週（00..53）、日曜日が週の最初の日です。WEEK() モード 0 | -| "%u" | 週（00..53）、月曜日が週の最初の日です。WEEK() モード 1 | -| "%V" | 週（01..53）、日曜日が週の最初の日です。WEEK() モード 2。%X とともに使用されます。 | -| "%v" | 週（01..53）、月曜日が週の最初の日です。WEEK() モード 3。%x とともに使用されます。 | +| "%U" | 週（00..53）、日曜日を週の最初の日とする、WEEK() モード 0 | +| "%u" | 週（00..53）、月曜日を週の最初の日とする、WEEK() モード 1 | +| "%V" | 週（01..53）、日曜日を週の最初の日とする、WEEK() モード 2、%X とともに使用 | +| "%v" | 週（01..53）、月曜日を週の最初の日とする、WEEK() モード 3、%x とともに使用 | | "%W" | 曜日名（日曜日..土曜日） | | "%w" | 曜日（0=日曜日、6=土曜日） | | "%X" | 日曜日を週の最初の日とする週の年を 4 桁の数字で表します。 | diff --git a/partitioned-table.md b/partitioned-table.md index a11f75b037ad4..d4d072c226d07 100644 --- a/partitioned-table.md +++ b/partitioned-table.md @@ -579,7 +579,7 @@ CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE) PARTITIONS 4; ``` -`t1`にデータ行を挿入し、 `col3`の値が"2005-09-15"である場合、この行はパーティション1に挿入されます。 +`t1`にデータ行を挿入し、 `col3`の値が'2005-09-15'である場合、この行はパーティション1に挿入されます。 ``` MOD(YEAR('2005-09-01'),4) diff --git a/tidb-cloud/troubleshoot-import-access-denied-error.md b/tidb-cloud/troubleshoot-import-access-denied-error.md index d5d0132aa737a..70e7158c13dfc 100644 --- a/tidb-cloud/troubleshoot-import-access-denied-error.md +++ b/tidb-cloud/troubleshoot-import-access-denied-error.md @@ -202,9 +202,9 @@ IAMユーザーのポリシーを確認するには、次の手順を実行し 2. バケットのリストで、対象のバケットを見つけてクリックします。バケット情報ページが表示されます。 3. バケット情報ページで**Permissions**タブをクリックし、 **Object Ownership**領域までスクロールダウンします。"Object Ownership"設定が"Bucket owner enforced"になっていることを確認してください。 - 設定が「Bucket owner enforced」ではない場合、アカウントにこのバケット内のすべてのオブジェクトに対する十分な権限がないため、エラー`AccessDenied`が発生します。 + 設定が"Bucket owner enforced"ではない場合、アカウントにこのバケット内のすべてのオブジェクトに対する十分な権限がないため、エラー`AccessDenied`が発生します。 -このエラーに対処するには、Object Ownership領域の右上にある**Edit**をクリックし、所有権を「Bucket owner enforced」に変更してください。ただし、このバケットを使用している他のアプリケーションに影響する可能性がありますのでご注意ください。 +このエラーに対処するには、Object Ownership領域の右上にある**Edit**をクリックし、所有権を"Bucket owner enforced"に変更してください。ただし、このバケットを使用している他のアプリケーションに影響する可能性がありますのでご注意ください。 ### バケットの暗号化タイプを確認してください {#check-your-bucket-encryption-type} diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index 7134276cbf772..ca15de8820e26 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -173,7 +173,7 @@ tiup cluster check --cluster コマンドが実行されると、"Region status"のチェック結果が出力されます。 - 結果が"All Regions are healthy"であれば、現在のクラスター内のすべてのリージョンは正常であり、アップグレードを続行できます。 -- 結果が「リージョンが完全に正常ではありません：m個のミスピア、n個の保留ピア」で、「他の操作を行う前に、異常なリージョンを修正してください。」というメッセージが表示される場合、現在のクラスタ内の一部のリージョンに異常があります。チェック結果が"All Regions are healthy"になるまで、異常のトラブルシューティングを行う必要があります。その後、アップグレードを続行できます。 +- 結果が"Regions are not fully healthy: m miss-peer, n pending-peer"で、"Please fix unhealthy regions before other operations."というメッセージが表示される場合、現在のクラスタ内の一部のリージョンに異常があります。チェック結果が"All Regions are healthy"になるまで、異常のトラブルシューティングを行う必要があります。その後、アップグレードを続行できます。 ## TiDBクラスタをアップグレードする {#upgrade-the-tidb-cluster} From 41f4d9bcfc07653a1f98da6f68fac4a02272dd6c Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 14:08:34 +0900 Subject: [PATCH 55/56] i18n(ja): restore literal rule/metric identifiers mistranslated into Japanese across diagnostic tables --- .../information-schema-inspection-result.md | 46 +++++++++---------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index 2b10a4f6c0867..a2854d3943398 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -246,11 +246,11 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo | コンポーネント | エラー名 | 監視テーブル | エラーの説明 | | ---- | ----------------------- | ---------------------------------- | -------------------------------------------- | - | TiDB | パニックカウント | tidb_panic_count_total_count | TiDB でパニックが発生します。 | - | TiKV | 重大なエラー | tikv_critical_error_total_count | TiKV の重大なエラー。 | - | TiKV | スケジューラがビジー状態 | tikv_scheduler_is_busy_total_count | TiKV スケジューラがビジー状態のため、TiKV が一時的に使用できなくなっています。 | - | TiKV | コプロセッサがビジー状態 | tikv_コプロセッサがビジー状態の合計数 | TiKVコプロセッサーがビジー状態です。 | - | TiKV | チャネルがいっぱいです | tikv_チャンネルの合計数 | TiKV で"channel full"というエラーが発生します。 | + | TiDB | panic-count | tidb_panic_count_total_count | TiDB でパニックが発生します。 | + | TiKV | critical-error | tikv_critical_error_total_count | TiKV の重大なエラー。 | + | TiKV | scheduler-is-busy | tikv_scheduler_is_busy_total_count | TiKV スケジューラがビジー状態のため、TiKV が一時的に使用できなくなっています。 | + | TiKV | coprocessor-is-busy | tikv_coprocessor_is_busy_total_count | TiKVコプロセッサーがビジー状態です。 | + | TiKV | channel-is-full | tikv_channel_full_total_count | TiKV で"channel full"というエラーが発生します。 | | TiKV | tikv_engine_write_stall | tikv_engine_write_stall | TiKV で"stall"エラーが発生します。 | - `metrics_schema.up`監視テーブルと`CLUSTER_LOG`システムテーブルを照会して、コンポーネントが再起動されているかどうかを確認します。 @@ -261,25 +261,25 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo | コンポーネント | 監視メトリック | 監視テーブル | 期待値 | 説明 | | :--- | :------------------- | :---------------------------------- | :-------- | :--------------------------------------------------------------------------------------------------------------- | -| TiDB | tso期間 | pd_tso_wait_duration | 50ミリ秒未満 | トランザクションの TSO を取得するまでの待機時間。 | -| TiDB | トークン取得期間 | tidb_get_token_duration | 1ミリ秒未満 | トークンの取得にかかる時間を照会します。関連するTiDB設定項目は[`token-limit`](/command-line-flags-for-tidb-configuration.md#--token-limit)です。 | -| TiDB | ロードスキーマ期間 | tidb_load_schema_duration | 1秒未満 | TiDB がスキーマ メタデータを更新するのにかかる時間。 | -| TiKV | スケジューラコマンド期間 | tikv_scheduler_command_duration | 0.1秒未満 | TiKV が KV `cmd`要求を実行するのにかかる時間。 | -| TiKV | ハンドルスナップショット期間 | tikv_handle_snapshot_duration | 30代未満 | TiKV がスナップショットを処理するのにかかる時間。 | -| TiKV | ストレージ書き込み時間 | tikv_storage_async_request_duration | 0.1秒未満 | TiKV の書き込みレイテンシー。 | -| TiKV | ストレージスナップショットの期間 | tikv_storage_async_request_duration | 50ミリ秒未満 | TiKV がスナップショットを取得するのにかかる時間。 | -| TiKV | rocksdb書き込み時間 | tikv_engine_write_duration | 100ミリ秒未満 | TiKV RocksDB の書き込みレイテンシー。 | +| TiDB | tso-duration | pd_tso_wait_duration | 50ミリ秒未満 | トランザクションの TSO を取得するまでの待機時間。 | +| TiDB | get-token-duration | tidb_get_token_duration | 1ミリ秒未満 | トークンの取得にかかる時間を照会します。関連するTiDB設定項目は[`token-limit`](/command-line-flags-for-tidb-configuration.md#--token-limit)です。 | +| TiDB | load-schema-duration | tidb_load_schema_duration | 1秒未満 | TiDB がスキーマ メタデータを更新するのにかかる時間。 | +| TiKV | scheduler-cmd-duration | tikv_scheduler_command_duration | 0.1秒未満 | TiKV が KV `cmd`要求を実行するのにかかる時間。 | +| TiKV | handle-snapshot-duration | tikv_handle_snapshot_duration | 30秒未満 | TiKV がスナップショットを処理するのにかかる時間。 | +| TiKV | storage-write-duration | tikv_storage_async_request_duration | 0.1秒未満 | TiKV の書き込みレイテンシー。 | +| TiKV | storage-snapshot-duration | tikv_storage_async_request_duration | 50ミリ秒未満 | TiKV がスナップショットを取得するのにかかる時間。 | +| TiKV | rocksdb-write-duration | tikv_engine_write_duration | 100ミリ秒未満 | TiKV RocksDB の書き込みレイテンシー。 | | TiKV | rocksdb-get-duration | tikv_engine_max_get_duration | 50ミリ秒未満 | TiKV RocksDB の読み取りレイテンシー。 | -| TiKV | rocksdbシーク時間 | tikv_engine_max_seek_duration | 50ミリ秒未満 | TiKV RocksDB の実行レイテンシーは`seek` 。 | -| TiKV | スケジューラ保留コマンドカウント | tikv_scheduler_pending_commands | 1000未満 | TiKV で停止したコマンドの数。 | -| TiKV | インデックスブロックキャッシュヒット | tikv_block_index_cache_hit | 0.95 | TiKV のインデックスブロックキャッシュのヒット率。 | -| TiKV | フィルターブロックキャッシュヒット | tikv_block_filter_cache_hit | 0.95 | TiKV のフィルターブロックキャッシュのヒット率。 | -| TiKV | データブロックキャッシュヒット | tikv_block_data_cache_hit | 0.80 | TiKV のデータブロックキャッシュのヒット率。 | -| TiKV | リーダースコアバランス | pd_scheduler_store_status | < 0.05 | 各TiKVインスタンスのリーダースコアが均衡しているかどうかを確認します。インスタンス間の期待される差は5%未満です。 | -| TiKV | リージョンスコアバランス | pd_scheduler_store_status | < 0.05 | 各TiKVインスタンスのリージョンスコアが均衡しているかどうかを確認します。インスタンス間の期待される差は5%未満です。 | -| TiKV | ストア利用可能バランス | pd_scheduler_store_status | < 0.2 | 各TiKVインスタンスの利用可能なストレージのバランスを確認します。インスタンス間の差は20%未満であることが想定されています。 | -| TiKV | リージョン数 | pd_scheduler_store_status | 20000未満 | 各 TiKV インスタンスのリージョン数を確認します。1つのインスタンスあたりのリージョン数は 20,000 未満と想定されています。 | -| PD | リージョンの健康 | pd_region_health | 100未満 | クラスター内でスケジュール処理中のリージョンの数を検出します。想定される数は合計で100未満です。 | +| TiKV | rocksdb-seek-duration | tikv_engine_max_seek_duration | 50ミリ秒未満 | TiKV RocksDB の実行レイテンシーは`seek` 。 | +| TiKV | scheduler-pending-cmd-coun | tikv_scheduler_pending_commands | 1000未満 | TiKV で停止したコマンドの数。 | +| TiKV | index-block-cache-hit | tikv_block_index_cache_hit | 0.95 | TiKV のインデックスブロックキャッシュのヒット率。 | +| TiKV | filter-block-cache-hit | tikv_block_filter_cache_hit | 0.95 | TiKV のフィルターブロックキャッシュのヒット率。 | +| TiKV | data-block-cache-hit | tikv_block_data_cache_hit | 0.80 | TiKV のデータブロックキャッシュのヒット率。 | +| TiKV | leader-score-balance | pd_scheduler_store_status | < 0.05 | 各TiKVインスタンスのリーダースコアが均衡しているかどうかを確認します。インスタンス間の期待される差は5%未満です。 | +| TiKV | region-score-balance | pd_scheduler_store_status | < 0.05 | 各TiKVインスタンスのリージョンスコアが均衡しているかどうかを確認します。インスタンス間の期待される差は5%未満です。 | +| TiKV | store-available-balance | pd_scheduler_store_status | < 0.2 | 各TiKVインスタンスの利用可能なストレージのバランスを確認します。インスタンス間の差は20%未満であることが想定されています。 | +| TiKV | region-count | pd_scheduler_store_status | 20000未満 | 各 TiKV インスタンスのリージョン数を確認します。1つのインスタンスあたりのリージョン数は 20,000 未満と想定されています。 | +| PD | region-health | pd_region_health | 100未満 | クラスター内でスケジュール処理中のリージョンの数を検出します。想定される数は合計で100未満です。 | さらに、このルールは、TiKV インスタンス内の次のスレッドの CPU 使用率が高すぎるかどうかもチェックします。 From b47153ca80b3670bde88d3816e056e04b309c03d Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 8 Sep 2026 14:11:25 +0900 Subject: [PATCH 56/56] i18n(ja): rename Expected value column header to threshold value to avoid statistical-expectation ambiguity --- information-schema/information-schema-inspection-result.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index a2854d3943398..bf54340131278 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -214,7 +214,7 @@ select * from information_schema.inspection_rules where type='inspection'; - 以下の設定項目の値が期待どおりであるかどうかを確認します。 - | コンポーネント | コンフィグレーション項目 | 期待値 | + | コンポーネント | コンフィグレーション項目 | しきい値 | | ---- | ------------------ | -------- | | TiDB | log.slow-threshold | `0`より大きい | @@ -259,7 +259,7 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo `threshold-check`診断ルールは、メトリックスキーマ内の関連する監視システムテーブルを照会して、クラスター内の次のメトリックがしきい値を超えているかどうかを確認します。 -| コンポーネント | 監視メトリック | 監視テーブル | 期待値 | 説明 | +| コンポーネント | 監視メトリック | 監視テーブル | しきい値 | 説明 | | :--- | :------------------- | :---------------------------------- | :-------- | :--------------------------------------------------------------------------------------------------------------- | | TiDB | tso-duration | pd_tso_wait_duration | 50ミリ秒未満 | トランザクションの TSO を取得するまでの待機時間。 | | TiDB | get-token-duration | tidb_get_token_duration | 1ミリ秒未満 | トークンの取得にかかる時間を照会します。関連するTiDB設定項目は[`token-limit`](/command-line-flags-for-tidb-configuration.md#--token-limit)です。 |