From 4f9089b3b699474eb8e6933bbd0e1f673111fc57 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 27 Aug 2026 13:27:10 +0900 Subject: [PATCH] i18n(ja): fix dropped particles before common action verbs (batch 2) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fixed missing particles (mostly を, a few が/は/で/に) immediately before common action verbs (設定する, 有効にする, 追加する, 実行する, 使用する, インストールする, 検索する, etc.) where a code-span, closing paren, or bracket directly touches the verb with no particle in between. Combines four parallel groups covering 190 files total. - group 0: 47 particle insertions/corrections across 42 files - group 1: ~55 particle insertions across 49 files - group 2: 71 particle insertions/fixes across 46 files - group 3: ~48 particle insertions across 51 files A number of adjacent pre-existing MT defects were also fixed alongside the flagged particles when directly confirmed against the release-8.5 EN source, including scrambled/reordered code-span lists, duplicated or wrong verbs, garbled/duplicated link text, and misplaced PR-link/terms breaking sentences. See the individual group commits on the source branch for the full per-file breakdown. Co-Authored-By: Claude Sonnet 5 --- ai/guides/vector-search-hybrid-search.md | 4 ++-- ai/quickstart-via-python.md | 2 +- auto-increment.md | 2 +- auto-random.md | 2 +- benchmark/benchmark-tidb-using-sysbench.md | 2 +- best-practices/best-practices-on-public-cloud.md | 2 +- best-practices/haproxy-best-practices.md | 2 +- best-practices/massive-regions-best-practices.md | 4 ++-- best-practices/pd-scheduling-best-practices.md | 2 +- .../tidb-partitioned-tables-best-practices.md | 2 +- br/br-monitoring-and-alert.md | 2 +- br/br-pitr-guide.md | 2 +- br/br-pitr-manual.md | 2 +- br/br-snapshot-guide.md | 4 ++-- br/use-br-command-line-tool.md | 2 +- certificate-authentication.md | 2 +- clinic/quick-start-with-clinic.md | 4 ++-- ...nd-line-flags-for-scheduling-configuration.md | 2 +- command-line-flags-for-tso-configuration.md | 2 +- constraints.md | 2 +- coprocessor-cache.md | 2 +- daily-check.md | 2 +- dashboard/top-sql.md | 4 ++-- data-type-date-and-time.md | 4 ++-- deploy-monitoring-services.md | 2 +- develop/dev-guide-aws-appflow-integration.md | 2 +- develop/dev-guide-connection-parameters.md | 16 ++++++++-------- ...ide-optimistic-and-pessimistic-transaction.md | 2 +- develop/dev-guide-paginate-results.md | 2 +- develop/dev-guide-timeouts-in-tidb.md | 2 +- develop/dev-guide-unstable-result-set.md | 2 +- develop/dev-guide-use-stale-read.md | 4 ++-- develop/java-app-best-practices.md | 4 ++-- dm/dm-compatibility-catalog.md | 2 +- dm/dm-error-handling.md | 2 +- dm/dm-webui-guide.md | 2 +- dm/feature-shard-merge-pessimistic.md | 2 +- dm/relay-log.md | 2 +- dr-multi-replica.md | 4 ++-- enable-disk-spill-encrypt.md | 2 +- enable-tls-between-components.md | 6 +++--- encryption-at-rest.md | 2 +- error-codes.md | 2 +- explain-overview.md | 2 +- faq/backup-and-restore-faq.md | 2 +- faq/deploy-and-maintain-faq.md | 2 +- faq/high-reliability-faq.md | 4 ++-- faq/migration-tidb-faq.md | 2 +- faq/sql-faq.md | 8 ++++---- faq/upgrade-faq.md | 4 ++-- foreign-key.md | 4 ++-- functions-and-operators/precision-math.md | 2 +- functions-and-operators/set-operators.md | 2 +- global-indexes.md | 2 +- grafana-tidb-dashboard.md | 2 +- log-redaction.md | 2 +- migrate-with-pt-ghost.md | 2 +- optimistic-transaction.md | 2 +- performance-tuning-methods.md | 6 +++--- performance-tuning-practices.md | 2 +- releases/release-2.0-ga.md | 4 ++-- releases/release-2.0-rc.4.md | 2 +- releases/release-2.1-beta.md | 6 +++--- releases/release-2.1-ga.md | 6 +++--- releases/release-2.1-rc.1.md | 2 +- releases/release-2.1-rc.2.md | 2 +- releases/release-2.1.11.md | 2 +- releases/release-3.0-ga.md | 4 ++-- releases/release-3.0.16.md | 2 +- releases/release-3.0.19.md | 2 +- releases/release-3.0.2.md | 2 +- releases/release-3.0.9.md | 2 +- releases/release-4.0-ga.md | 2 +- releases/release-4.0.0-rc.md | 2 +- releases/release-4.0.11.md | 2 +- releases/release-4.0.13.md | 2 +- releases/release-4.0.3.md | 2 +- releases/release-4.0.6.md | 2 +- releases/release-4.0.8.md | 2 +- releases/release-4.0.9.md | 4 ++-- releases/release-5.0.0-rc.md | 2 +- releases/release-5.0.2.md | 2 +- releases/release-5.3.0.md | 2 +- releases/release-6.1.0.md | 2 +- releases/release-6.1.7.md | 2 +- releases/release-6.3.0.md | 2 +- releases/release-6.5.1.md | 2 +- releases/release-6.5.4.md | 2 +- releases/release-6.5.6.md | 4 ++-- releases/release-7.1.0.md | 8 ++++---- releases/release-7.1.2.md | 2 +- releases/release-7.1.3.md | 4 ++-- releases/release-7.4.0.md | 6 +++--- releases/release-7.5.1.md | 2 +- releases/release-7.5.7.md | 2 +- releases/release-7.6.0.md | 4 ++-- releases/release-8.0.0.md | 4 ++-- releases/release-8.1.0.md | 2 +- releases/release-8.1.1.md | 2 +- releases/release-8.1.2.md | 2 +- releases/release-8.4.0.md | 6 +++--- resources/markdownlint-rules.md | 2 +- role-based-access-control.md | 2 +- runtime-filter.md | 2 +- schedule-replicas-by-topology-labels.md | 14 +++++++------- scheduling-configuration-file.md | 4 ++-- shard-row-id-bits.md | 4 ++-- sql-plan-replayer.md | 8 ++++---- sql-prepared-plan-cache.md | 8 ++++---- sql-statements/sql-statement-add-column.md | 2 +- .../sql-statement-admin-checksum-table.md | 2 +- sql-statements/sql-statement-alter-index.md | 2 +- sql-statements/sql-statement-alter-table.md | 2 +- sql-statements/sql-statement-commit.md | 2 +- sql-statements/sql-statement-create-index.md | 2 +- .../sql-statement-flashback-database.md | 2 +- sql-statements/sql-statement-load-data.md | 2 +- sql-statements/sql-statement-lock-stats.md | 2 +- ...ql-statement-lock-tables-and-unlock-tables.md | 2 +- sql-statements/sql-statement-recover-table.md | 2 +- sql-statements/sql-statement-set-role.md | 2 +- stale-read.md | 4 ++-- storage-engine/titan-configuration.md | 6 +++--- storage-engine/titan-overview.md | 2 +- .../sync-diff-inspector-overview.md | 2 +- table-attributes.md | 4 ++-- ticdc/ticdc-architecture.md | 2 +- ticdc/ticdc-avro-protocol.md | 4 ++-- ticdc/ticdc-canal-json.md | 2 +- ticdc/ticdc-changefeed-overview.md | 2 +- ticdc/ticdc-faq.md | 8 ++++---- ticdc/ticdc-filter.md | 2 +- ticdc/ticdc-integrity-check.md | 2 +- ticdc/ticdc-server-config.md | 2 +- ticdc/ticdc-simple-protocol.md | 2 +- ticdc/ticdc-sink-to-cloud-storage.md | 4 ++-- ticdc/ticdc-sink-to-kafka.md | 4 ++-- ticdc/ticdc-split-update-behavior.md | 4 ++-- ticdc/ticdc-upstream-downstream-check.md | 4 ++-- tidb-cloud/changefeed-sink-to-apache-pulsar.md | 2 +- tidb-cloud/connected-lark-ticket-creation.md | 2 +- tidb-cloud/csv-config-for-import-data.md | 2 +- tidb-cloud/data-service-manage-endpoint.md | 2 +- .../data-service-manage-github-connection.md | 4 ++-- tidb-cloud/integrate-tidbcloud-with-zapier.md | 2 +- tidb-cloud/limited-sql-features.md | 2 +- tidb-cloud/manage-user-access.md | 2 +- tidb-cloud/monitor-new-relic-integration.md | 2 +- .../premium/built-in-monitoring-premium.md | 2 +- .../premium/import-with-mysql-cli-premium.md | 2 +- tidb-cloud/releases/release-notes-2022.md | 2 +- tidb-cloud/releases/release-notes-2025.md | 2 +- tidb-cloud/serverless-faqs.md | 2 +- tidb-cloud/serverless-limitations.md | 2 +- tidb-cloud/set-up-vpc-peering-connections.md | 4 ++-- .../terraform-use-serverless-branch-resource.md | 2 +- tidb-cloud/tidb-cloud-encrypt-cmek-aws.md | 2 +- tidb-cloud/use-chat2query-api.md | 2 +- tidb-configuration-file.md | 2 +- tidb-distributed-execution-framework.md | 6 +++--- tidb-external-ts.md | 6 +++--- tidb-lightning/tidb-lightning-configuration.md | 2 +- .../tidb-lightning-logical-import-mode.md | 2 +- tidb-lightning/troubleshoot-tidb-lightning.md | 2 +- tidb-read-staleness.md | 2 +- tidb-resource-control-runaway-queries.md | 2 +- tidb-scheduling.md | 2 +- tidb-troubleshooting-map.md | 2 +- tiflash/tiflash-configuration.md | 4 ++-- tiflash/tiflash-spill-disk.md | 2 +- tiflash/troubleshoot-tiflash.md | 4 ++-- tiflash/use-fastscan.md | 4 ++-- tiflash/use-tiflash-mpp-mode.md | 2 +- tikv-control.md | 2 +- tikv-in-memory-engine.md | 2 +- tiproxy/tiproxy-command-line-flags.md | 2 +- tiproxy/tiproxy-configuration.md | 6 +++--- tiproxy/tiproxy-load-balance.md | 4 ++-- tiproxy/tiproxy-performance-test.md | 2 +- tiup/tiup-cluster-topology-reference.md | 4 ++-- tiup/tiup-command-completion.md | 2 +- tiup/tiup-component-management.md | 2 +- transaction-isolation-levels.md | 2 +- troubleshoot-cpu-issues.md | 2 +- troubleshoot-data-inconsistency-errors.md | 2 +- troubleshoot-high-disk-io.md | 2 +- troubleshoot-tidb-cluster.md | 8 ++++---- troubleshoot-tidb-oom.md | 2 +- tso-configuration-file.md | 4 ++-- tune-region-performance.md | 2 +- 190 files changed, 277 insertions(+), 277 deletions(-) diff --git a/ai/guides/vector-search-hybrid-search.md b/ai/guides/vector-search-hybrid-search.md index a43e94d63ea3a..a7486f5addd00 100644 --- a/ai/guides/vector-search-hybrid-search.md +++ b/ai/guides/vector-search-hybrid-search.md @@ -160,7 +160,7 @@ df = ( 詳細については、 [RRF論文](https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf)を参照してください。 -`method`メソッドで`"rrf"`パラメーター`.fusion()`有効にします。 +`.fusion()`メソッドで`method`パラメーターを`"rrf"`に指定することで、相互ランク融合を有効にします。 ```python results = ( @@ -185,7 +185,7 @@ results = ( final_score = vs_weight * vector_score + fts_weight * fulltext_score ``` -`method`メソッドで`"weighted"`パラメーター`.fusion()`有効にします。 +`.fusion()`メソッドで`method`パラメーターを`"weighted"`に指定することで、加重スコア融合を有効にします。 例えば、ベクトル検索の重みを大きくするには、 `vs_weight`パラメータを 0.7 に、 `fts_weight`パラメータを 0.3 に設定します。 diff --git a/ai/quickstart-via-python.md b/ai/quickstart-via-python.md index 1d54e8f97091a..bc1e1bc5508d5 100644 --- a/ai/quickstart-via-python.md +++ b/ai/quickstart-via-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} -このドキュメントでは、Python SDK を使用して TiDB で[ベクトル検索](/ai/concepts/vector-search-overview.md)開始する方法を説明します。手順に従って、TiDB で動作する最初の AI アプリケーションを構築します。 +このドキュメントでは、Python SDK を使用して TiDB で[ベクトル検索](/ai/concepts/vector-search-overview.md)を開始する方法を説明します。手順に従って、TiDB で動作する最初の AI アプリケーションを構築します。 このドキュメントに従うことで、以下のことを学ぶことができます。 diff --git a/auto-increment.md b/auto-increment.md index 4612a750ec218..b4718cbb09b1e 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -33,7 +33,7 @@ summary: TiDB の AUTO_INCREMENT` 列属性について学習します。 > **Note:** > -> すべての TiDB サーバーで`AUTO_INCREMENT`数値を単調にしたい場合、TiDB バージョンが v6.5.0 以降であれば、 [MySQL互換モード](#mysql-compatibility-mode)有効にすることをお勧めします。 +> すべての TiDB サーバーで`AUTO_INCREMENT`数値を単調にしたい場合、TiDB バージョンが v6.5.0 以降であれば、 [MySQL互換モード](#mysql-compatibility-mode)を有効にすることをお勧めします。 以下は`AUTO_INCREMENT`の基本的な例です。 diff --git a/auto-random.md b/auto-random.md index 44879cfeaf050..4db06f7fc0e3e 100644 --- a/auto-random.md +++ b/auto-random.md @@ -182,7 +182,7 @@ ALTER TABLE t AUTO_RANDOM_BASE=0; > **Note:** > -> `FORCE`キーワードを使用して`AUTO_RANDOM_BASE`から`0`設定することはできません。これを試みるとエラーが発生します。 +> `FORCE`キーワードを使用して`AUTO_RANDOM_BASE`を`0`に設定することはできません。これを試みるとエラーが発生します。 ### オプション2: 特定の基本値を手動で設定する {#option-2-manually-set-a-specific-base-value} diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 23e4219b96854..d1e5c97a553b3 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -95,7 +95,7 @@ db-driver=mysql > **Note:** > -> 楽観的トランザクションモデルを有効にすると（TiDBはデフォルトで悲観的トランザクションモードを使用します）、同時実行の競合が検出されるとTiDBはトランザクションをロールバックします。1～ `tidb_disable_txn_auto_retry` `off`設定すると、トランザクションの競合が発生した後に自動再試行メカニズムが有効になり、トランザクション競合エラーによってSysbenchが終了するのを防ぐことができます。 +> 楽観的トランザクションモデルを有効にすると（TiDBはデフォルトで悲観的トランザクションモードを使用します）、同時実行の競合が検出されるとTiDBはトランザクションをロールバックします。1～ `tidb_disable_txn_auto_retry`を`off`に設定すると、トランザクションの競合が発生した後に自動再試行メカニズムが有効になり、トランザクション競合エラーによってSysbenchが終了するのを防ぐことができます。 データをインポートする前に、TiDBにいくつかの設定を行う必要があります。MySQLクライアントで以下のコマンドを実行してください。 diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md index adfc41015802e..b52eb4128da4e 100644 --- a/best-practices/best-practices-on-public-cloud.md +++ b/best-practices/best-practices-on-public-cloud.md @@ -113,7 +113,7 @@ Azure 上のRaft Engineに専用の 32 GB [Ultra Disk](https://learn.microsoft.c ### 例 3: TiKV マニフェストのRaft Engine用に Google Cloud に専用の pd-ssd ディスクを接続する {#example-3-attach-a-dedicated-pd-ssd-disk-on-google-cloud-for-raft-engine-on-tikv-manifest} -次の TiKV 構成例は、 [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable)によってデプロイされた Google Cloud 上のクラスタに 512 GB の追加のディスク[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)を接続し、この特定のディスクにRaft Engineログを保存するように`raft-engine.dir`構成する方法を示しています。 +次の TiKV 構成例は、 [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable)によってデプロイされた Google Cloud 上のクラスタに 512 GB の追加のディスク[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)を接続し、この特定のディスクにRaft Engineログを保存するように`raft-engine.dir`を構成する方法を示しています。 ``` tikv: diff --git a/best-practices/haproxy-best-practices.md b/best-practices/haproxy-best-practices.md index 3d33c81091e83..8516460335929 100644 --- a/best-practices/haproxy-best-practices.md +++ b/best-practices/haproxy-best-practices.md @@ -206,7 +206,7 @@ listen tidb-cluster # Database load balancing. > **Note:** > -> PROXY プロトコルを使用する前に、TiDBサーバーの構成ファイルで[`proxy-protocol.networks`](/tidb-configuration-file.md#networks)構成する必要があります。 +> PROXY プロトコルを使用する前に、TiDBサーバーの構成ファイルで[`proxy-protocol.networks`](/tidb-configuration-file.md#networks)を構成する必要があります。 ### HAProxyを起動する {#start-haproxy} diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md index 29083fd078216..c08501cdd0911 100644 --- a/best-practices/massive-regions-best-practices.md +++ b/best-practices/massive-regions-best-practices.md @@ -88,9 +88,9 @@ TiKVでは、デフォルトで`raftstore.store-pool-size`から`2`に設定さ > > TiDB v3.0 以降では`Region Merge`がデフォルトで有効になっています。 -`Region Merge`有効にすることで、Regionの数を減らすこともできます。`Region Split`は異なり、 `Region Merge`スケジュール設定によって隣接する小さなRegionを結合するプロセスです。データを削除した後、または`Drop Table`もしくは`Truncate Table`ステートメントを実行した後、小さなRegion、あるいは空のRegionを結合することで、リソース消費を削減できます。 +`Region Merge`を有効にすることで、Regionの数を減らすこともできます。`Region Split`は異なり、 `Region Merge`スケジュール設定によって隣接する小さなRegionを結合するプロセスです。データを削除した後、または`Drop Table`もしくは`Truncate Table`ステートメントを実行した後、小さなRegion、あるいは空のRegionを結合することで、リソース消費を削減できます。 -次のパラメータを設定して`Region Merge`有効にします。 +次のパラメータを設定して`Region Merge`を有効にします。 ``` config set max-merge-region-size 54 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 8ceea749b2c17..7014540f0da66 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -299,4 +299,4 @@ v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニ > **Note:** > -> **Leaderの排除は**、PDがTiKVの低速ノードにスケジューリング要求を送信し、TiKVが受信したスケジューリング要求を順次実行することで実現されます。**低速I/O**などの要因により、低速ノードでは要求が蓄積され、一部のリーダーは遅延した要求が処理されるまで**Leaderの排除**要求を処理できない場合があります。その結果**、Leaderの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。 +> **Leaderの排除は**、PDがTiKVの低速ノードにスケジューリング要求を送信し、TiKVが受信したスケジューリング要求を順次実行することで実現されます。**低速I/O**などの要因により、低速ノードでは要求が蓄積され、一部のリーダーは遅延した要求が処理されるまで**Leaderの排除**要求を処理できない場合があります。その結果**、Leaderの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`を有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。 diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md index eae929715b7c3..78899f954fc39 100644 --- a/best-practices/tidb-partitioned-tables-best-practices.md +++ b/best-practices/tidb-partitioned-tables-best-practices.md @@ -261,7 +261,7 @@ TTL パフォーマンスに関する調査結果は次のとおりです。 - この操作はメタデータ レベルで実行されるため、最小限のリソースしか使用されません。 - `DROP PARTITION` 、特に大規模な履歴データセットの場合、TTL よりも高速で予測可能です。 -#### TiDBでTTLと`DROP PARTITION`使用する {#use-ttl-and-drop-partition-in-tidb} +#### TiDBでTTLと`DROP PARTITION`を使用する {#use-ttl-and-drop-partition-in-tidb} 以下の例では匿名化されたテーブル構造を使用しています。TTLの詳細については、 [TTL（Time to Live）を使用して定期的にデータを削除する](/time-to-live.md)を参照してください。 diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md index b78933f0d109e..02e3a3351eeeb 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -62,7 +62,7 @@ PITR でアラート項目を構成するには、次の手順に従います。 1. Prometheusが配置されているノードのアラートルール用の設定ファイル（例： `pitr.rules.yml` ）を作成します。このファイルには、 [Prometheusのドキュメント](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/) 、以下の推奨アラート項目、および設定サンプルに従ってアラートルールを記述します。 2. Prometheus 構成ファイルの`rule_files`フィールドに、アラートルール ファイルのパスを追加します。 -3. Prometheusプロセスにシグナル`SIGHUP`送信するか（ `kill -HUP pid` ）、HTTPリクエスト`POST`を`http://prometheus-addr/-/reload`に送信します（HTTPリクエストを送信する前に、Prometheusの起動時にパラメータ`--web.enable-lifecycle`を追加します）。 +3. Prometheusプロセスにシグナル`SIGHUP`を送信するか（ `kill -HUP pid` ）、HTTPリクエスト`POST`を`http://prometheus-addr/-/reload`に送信します（HTTPリクエストを送信する前に、Prometheusの起動時にパラメータ`--web.enable-lifecycle`を追加します）。 推奨されるアラート項目は次のとおりです。 diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md index 4868349539199..395f100fa47e5 100644 --- a/br/br-pitr-guide.md +++ b/br/br-pitr-guide.md @@ -5,7 +5,7 @@ summary: TiDB ログバックアップおよび PITR ガイドでは、br コマ # TiDB ログバックアップと PITR ガイド {#tidb-log-backup-and-pitr-guide} -フルバックアップ（スナップショットバックアップ）には、ある時点におけるクラスタ全体のデータが含まれますが、TiDBログバックアップは、アプリケーションによって書き込まれたデータを指定されたストレージにタイムリーにバックアップできます。必要に応じて復元ポイントを選択、つまりポイントインタイムリカバリ（PITR）を実行したい場合は、 [ログバックアップを開始する](#start-log-backup)と[定期的に完全バックアップを実行する](#run-full-backup-regularly)選択できます。 +フルバックアップ（スナップショットバックアップ）には、ある時点におけるクラスタ全体のデータが含まれますが、TiDBログバックアップは、アプリケーションによって書き込まれたデータを指定されたストレージにタイムリーにバックアップできます。必要に応じて復元ポイントを選択、つまりポイントインタイムリカバリ（PITR）を実行したい場合は、 [ログバックアップを開始する](#start-log-backup)と[定期的に完全バックアップを実行する](#run-full-backup-regularly)ことができます。 br コマンドラインツール (以下、 `br`と呼びます) を使用してデータをバックアップまたは復元する前に、まず[インストール`br`](/br/br-use-overview.md#deploy-and-use-br)行う必要があります。 diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index c11ec3413dcd2..a92f480cd685c 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -471,7 +471,7 @@ Restore KV Files <-------------------------------------------------------------- > > - クラスターを初めて復元する際は、完全なスナップショットデータを指定する必要があります。そうしないと、テーブルIDルールの書き換えにより、新しく作成されたテーブルの一部のデータが正しくなくなる可能性があります。詳細については、GitHub の問題[＃54418](https://github.com/pingcap/tidb/issues/54418)をご覧ください。 > - 特定の期間のログバックアップデータを繰り返しリストアすることはできません。範囲`[t1=10, t2=20)`のログバックアップデータを繰り返しリストアすると、リストアされたデータに不整合が生じる可能性があります。 -> - 異なる期間のログデータを複数のバッチで復元する場合は、ログデータが連続した順序で復元されるようにしてください。ログバックアップデータ`[t1, t2)` 、 `[t2, t3)` 、 `[t3, t4)`を連続した順序で復元すると、復元されたデータは整合性を保ちます。ただし、 `[t1, t2)`復元した後、 `[t2, t3)`スキップして`[t3, t4)`を復元すると、復元されたデータは不整合になる可能性があります。 +> - 異なる期間のログデータを複数のバッチで復元する場合は、ログデータが連続した順序で復元されるようにしてください。ログバックアップデータ`[t1, t2)` 、 `[t2, t3)` 、 `[t3, t4)`を連続した順序で復元すると、復元されたデータは整合性を保ちます。ただし、 `[t1, t2)`を復元した後、 `[t2, t3)`をスキップして`[t3, t4)`を復元すると、復元されたデータは不整合になる可能性があります。 ### 暗号化されたログバックアップデータを復元する {#restore-encrypted-log-backup-data} diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md index 7929a881c1fc6..3839d2b969018 100644 --- a/br/br-snapshot-guide.md +++ b/br/br-snapshot-guide.md @@ -119,7 +119,7 @@ tiup br restore db \ --storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" ``` -上記のコマンドでは、 `--db`復元するデータベースの名前を指定します。 +上記のコマンドでは、 `--db`は復元するデータベースの名前を指定します。 **テーブルを復元する** @@ -132,7 +132,7 @@ tiup br restore table --pd "${PD_IP}:2379" \ --storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" ``` -上記のコマンドでは、 `--db`復元するデータベースの名前を指定し、 `--table`復元するテーブルの名前を指定します。 +上記のコマンドでは、 `--db`は復元するデータベースの名前を指定し、 `--table`は復元するテーブルの名前を指定します。 **テーブルフィルターを使用して複数のテーブルを復元します。** diff --git a/br/use-br-command-line-tool.md b/br/use-br-command-line-tool.md index a65eedd565f27..437cb217abb8f 100644 --- a/br/use-br-command-line-tool.md +++ b/br/use-br-command-line-tool.md @@ -57,7 +57,7 @@ tiup br backup full --pd "${PD_IP}:2379" \ - `--cert` : PEM 形式の SSL 証明書へのパスを指定します。 - `--key` : PEM 形式の SSL 証明書キーへのパスを指定します。 - `--status-addr` : `br` Prometheus に統計を提供するリスニング アドレスを指定します。 -- `--concurrency` : バックアップタスクを複数のリクエストに分割し、同じ TiKV ノードに同時に送信する方法を制御します。このパラメータは主にBRから TiKV へのリクエスト分割の粒度に影響し、全体的なバックアップスループットを直接決定するものではありません。ほとんどの場合、この値を変更する必要はありません。バックアップパフォーマンスを向上させるには、代わりに[`tikv.backup.num-threads`](/tikv-configuration-file.md#num-threads-1)調整する必要があります。 +- `--concurrency` : バックアップタスクを複数のリクエストに分割し、同じ TiKV ノードに同時に送信する方法を制御します。このパラメータは主にBRから TiKV へのリクエスト分割の粒度に影響し、全体的なバックアップスループットを直接決定するものではありません。ほとんどの場合、この値を変更する必要はありません。バックアップパフォーマンスを向上させるには、代わりに[`tikv.backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整する必要があります。 - `--pitr-concurrency` : ログ復元中の同時タスクの数。 - `--tikv-max-restore-concurrency` : スナップショット復元中の TiKV ノードあたりの同時タスクの最大数。 - `--compression` : バックアップファイルの生成に使用する圧縮アルゴリズムを決定します。`lz4` 、 `snappy` 、 `zstd`をサポートし、デフォルトは`zstd`です（通常は変更する必要はありません）。異なる圧縮アルゴリズムの選択に関するガイダンスについては、 [この文書](https://github.com/EighteenZi/rocksdb_wiki/blob/master/Compression.md)を参照してください。 diff --git a/certificate-authentication.md b/certificate-authentication.md index 2f9d84b60ee68..2046bdc73d1e9 100644 --- a/certificate-authentication.md +++ b/certificate-authentication.md @@ -285,7 +285,7 @@ mysql -u test -h 0.0.0.0 -P 4000 --ssl-cert /path/to/client-cert.new.pem --ssl-k ### ユーザー証明書情報を構成する {#configure-user-certificate-information} -ユーザー証明書情報（ `REQUIRE SUBJECT` `REQUIRE CIPHER`を取得したら、ユーザーの作成、権限の付与、またはユーザーの変更時にこれらの情報`REQUIRE SAN`検証されるように設定します。以下の文の`` `REQUIRE ISSUER`する情報に置き換えてください。 +ユーザー証明書情報（ `REQUIRE SUBJECT` 、 `REQUIRE ISSUER` 、 `REQUIRE SAN` 、 `REQUIRE CIPHER` ）を取得したら、ユーザーの作成、権限の付与、またはユーザーの変更時にこれらの情報が検証されるように設定します。以下の文の``を対応する情報に置き換えてください。 スペースまたは`and`区切り文字として使用して、1つのオプションまたは複数のオプションを設定できます。 diff --git a/clinic/quick-start-with-clinic.md b/clinic/quick-start-with-clinic.md index d941bfb217541..bd0a61cc2858c 100644 --- a/clinic/quick-start-with-clinic.md +++ b/clinic/quick-start-with-clinic.md @@ -58,9 +58,9 @@ PingCAP Clinicを使用する前に、Diag をインストールし、データ > - データセキュリティのため、TiDBはトークン作成時にのみトークン情報を表示します。トークン情報を紛失した場合は、古いトークンを削除して新しいトークンを作成できます。 > - トークンはデータのアップロードにのみ使用されます。 -5. Diag にトークンと`region`設定します。 +5. Diag にトークンと`region`を設定します。 - - `clinic.token`設定するには、次のコマンドを実行します。 + - `clinic.token`を設定するには、次のコマンドを実行します。 ```bash tiup diag config clinic.token ${token-value} diff --git a/command-line-flags-for-scheduling-configuration.md b/command-line-flags-for-scheduling-configuration.md index dbcc8348347fa..bd1c11a84817c 100644 --- a/command-line-flags-for-scheduling-configuration.md +++ b/command-line-flags-for-scheduling-configuration.md @@ -12,7 +12,7 @@ summary: スケジュール構成フラグは、コマンドラインフラグ - クライアントがスケジューリング ノードにアクセスするための URL。 - デフォルト: `${listen-addr}` - Docker や NAT ネットワーク環境などの状況では、クライアントが`scheduling`でリッスンされるデフォルトのクライアント URL を通じてスケジューリング ノードにアクセスできない場合は、クライアント アクセス用に`--advertise-listen-addr`手動で設定する必要があります。 -- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `--advertise-listen-addr="http://192.168.100.113:3379"`設定できます。そうすることで、クライアントは`http://192.168.100.113:3379`を通じてこのサービスを見つけることができるようになります。 +- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `--advertise-listen-addr="http://192.168.100.113:3379"`を設定できます。そうすることで、クライアントは`http://192.168.100.113:3379`を通じてこのサービスを見つけることができるようになります。 ## `--backend-endpoints` {#backend-endpoints} diff --git a/command-line-flags-for-tso-configuration.md b/command-line-flags-for-tso-configuration.md index c89b372c8b6b4..6a4ac5cff4fa4 100644 --- a/command-line-flags-for-tso-configuration.md +++ b/command-line-flags-for-tso-configuration.md @@ -12,7 +12,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために - クライアントが TSO ノードにアクセスするための URL。 - デフォルト: `${listen-addr}` - Docker や NAT ネットワーク環境などの状況では、クライアントが`tso`でリッスンされるデフォルトのクライアント URL を通じて TSO ノードにアクセスできない場合は、クライアント アクセス用に`--advertise-listen-addr`手動で設定する必要があります。 -- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `--advertise-listen-addr="http://192.168.100.113:3379"`設定できます。そうすることで、クライアントは`http://192.168.100.113:3379`を通じてこのサービスを見つけることができるようになります。 +- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `--advertise-listen-addr="http://192.168.100.113:3379"`を設定できます。そうすることで、クライアントは`http://192.168.100.113:3379`を通じてこのサービスを見つけることができるようになります。 ## `--backend-endpoints` {#backend-endpoints} diff --git a/constraints.md b/constraints.md index 4be27539706c8..d583aececbddd 100644 --- a/constraints.md +++ b/constraints.md @@ -121,7 +121,7 @@ ALTER TABLE t DROP CONSTRAINT t_chk_1; ### `CHECK`制約を有効または無効にする {#enable-or-disable-check-constraints} -テーブルに[`CHECK`制約を追加する](#add-check-constraints)設定すると、データの挿入または更新時に TiDB が制約チェックを実装する必要があるかどうかを指定できます。 +テーブルに[`CHECK`制約を追加する](#add-check-constraints)場合、データの挿入または更新時に TiDB が制約チェックを実装する必要があるかどうかを指定できます。 - `NOT ENFORCED`を指定すると、TiDB はデータの挿入または更新時に制約条件をチェックしません。 - `NOT ENFORCED`が指定されていないか`ENFORCED`が指定されている場合、TiDB はデータの挿入または更新中に制約条件をチェックします。 diff --git a/coprocessor-cache.md b/coprocessor-cache.md index fc47abef05fac..05aacd397b5a3 100644 --- a/coprocessor-cache.md +++ b/coprocessor-cache.md @@ -52,7 +52,7 @@ v4.0 以降、TiDB インスタンスは TiKV (コプロセッサーキャッシ `EXPLAIN ANALYZE`を実行するか、Grafana 監視パネルを表示することで、コプロセッサーのキャッシュ効果を確認できます。 -### `EXPLAIN ANALYZE`使用する {#use-explain-analyze} +### `EXPLAIN ANALYZE`を使用する {#use-explain-analyze} [テーブルにアクセスするための演算子](/choose-index.md#operators-for-accessing-tables)のキャッシュヒット率は[`EXPLAIN ANALYZE`ステートメント](/sql-statements/sql-statement-explain-analyze.md)を使って確認できます。次の例をご覧ください。 diff --git a/daily-check.md b/daily-check.md index 64678a477c739..8614d7f881468 100644 --- a/daily-check.md +++ b/daily-check.md @@ -38,7 +38,7 @@ CPU、メモリ、ディスクの使用状況を確認できます。いずれ ![Region panel](/media/region-panel.png) - `down-peer-region-count` ： Raftリーダーによって報告された、応答しないピアを持つリージョンの数。 -- `empty-region-count` ：サイズが1MiB未満の空のリージョンの数。これらのリージョンは、 `TRUNCATE TABLE` / `DROP TABLE`ステートメントを実行することによって生成されます。この数が多い場合は、 `Region Merge`有効にして複数のテーブル間でリージョンをマージすることを検討してください。 +- `empty-region-count` ：サイズが1MiB未満の空のリージョンの数。これらのリージョンは、 `TRUNCATE TABLE` / `DROP TABLE`ステートメントを実行することによって生成されます。この数が多い場合は、 `Region Merge`を有効にして複数のテーブル間でリージョンをマージすることを検討してください。 - `extra-peer-region-count` ：追加のレプリカを持つリージョンの数。これらのリージョンはスケジューリング処理中に生成されます。 - `learner-peer-region-count` ：ラーナーピアが存在するリージョンの数。ラーナーピアのソースは様々で、例えば、 TiFlashのラーナーピアや、設定済みの配置ルールに含まれるラーナーピアなどがあります。 - `miss-peer-region-count` ：レプリカが不足しているリージョンの数。この値は必ずしも`0`より大きいとは限りません。 diff --git a/dashboard/top-sql.md b/dashboard/top-sql.md index ba45955bb0997..e5a8ef3825b20 100644 --- a/dashboard/top-sql.md +++ b/dashboard/top-sql.md @@ -57,7 +57,7 @@ Top SQLは、有効にするとクラスタのパフォーマンスにわずか Top SQLを有効にすると、この時点以降に収集されたデータのみを表示でき、有効化前の履歴データは補完されません。データ表示には通常約1分の遅延があるため、新しいデータを確認するには少し待つ必要があります。Top SQLを無効にした後も、履歴データの有効期限が切れていなければ、Top SQLページにはこの履歴データが引き続き表示されますが、新しいデータは収集も表示もされなくなります。 -UIに加えて、TiDBシステム変数[`tidb_enable_top_sql`](/system-variables.md#tidb_enable_top_sql-new-in-v540)設定することで、 Top SQL機能を有効にすることもできます。 +UIに加えて、TiDBシステム変数[`tidb_enable_top_sql`](/system-variables.md#tidb_enable_top_sql-new-in-v540)を設定することで、 Top SQL機能を有効にすることもできます。 ```sql SET GLOBAL tidb_enable_top_sql = 1; @@ -161,7 +161,7 @@ TiUPトポロジー設定の詳細については、 [TiUPクラスターのト Top SQLを無効にすると、Top SQLは新しいデータの収集を停止しますが、有効期限が切れる前の履歴データは引き続き表示できます。 -UIに加えて、TiDBシステム変数[`tidb_enable_top_sql`](/system-variables.md#tidb_enable_top_sql-new-in-v540)設定することで、 Top SQL機能を無効にすることもできます。 +UIに加えて、TiDBシステム変数[`tidb_enable_top_sql`](/system-variables.md#tidb_enable_top_sql-new-in-v540)を設定することで、 Top SQL機能を無効にすることもできます。 ```sql SET GLOBAL tidb_enable_top_sql = 0; diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md index 2d002f272a008..ef225b5e95575 100644 --- a/data-type-date-and-time.md +++ b/data-type-date-and-time.md @@ -67,7 +67,7 @@ TiDBは、時間値を格納するためにMySQLのすべての日付と時刻 - 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」などのゼロ値が保存されるのを防ぎます。 さまざまな種類のゼロ値を次の表に示します。 @@ -187,7 +187,7 @@ CREATE TABLE t1 ( `0`は小数部がないことを意味します。`fsp`を省略した場合、デフォルトは0です。 -- 小数部を含む`TIME` 、 `DATETIME` 、または`TIMESTAMP`挿入する場合、小数部の桁数が少なすぎる、または多すぎる場合は、四捨五入が必要になることがあります。例： +- 小数部を含む`TIME` 、 `DATETIME` 、または`TIMESTAMP`を挿入する場合、小数部の桁数が少なすぎる、または多すぎる場合は、四捨五入が必要になることがあります。例： ```sql mysql> CREATE TABLE fractest( c1 TIME(2), c2 DATETIME(2), c3 TIMESTAMP(2) ); diff --git a/deploy-monitoring-services.md b/deploy-monitoring-services.md index 63e283139441c..455f63b33175a 100644 --- a/deploy-monitoring-services.md +++ b/deploy-monitoring-services.md @@ -36,7 +36,7 @@ tar -xzf node_exporter-v1.3.1-linux-amd64.tar.gz tar -xzf grafana-7.5.17.linux-amd64.tar.gz ``` -### ステップ2: Node1、Node2、Node3、Node4で`node_exporter`起動する {#step-2-start-node-exporter-on-node1-node2-node3-and-node4} +### ステップ2: Node1、Node2、Node3、Node4で`node_exporter`を起動する {#step-2-start-node-exporter-on-node1-node2-node3-and-node4} ```bash cd node_exporter-v1.3.1-linux-amd64 diff --git a/develop/dev-guide-aws-appflow-integration.md b/develop/dev-guide-aws-appflow-integration.md index ab0fadde4331d..a981f906f00ba 100644 --- a/develop/dev-guide-aws-appflow-integration.md +++ b/develop/dev-guide-aws-appflow-integration.md @@ -71,7 +71,7 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration > **Note:** > > - `--guided`オプションでは、プロンプトが表示され、デプロイの手順を案内します。入力内容は構成ファイルに保存され、デフォルトでは`samconfig.toml`というファイルになります。 - > - `stack_name`デプロイする AWS Lambda の名前を指定します。 + > - `stack_name`は、デプロイする AWS Lambda の名前を指定します。 > - このガイドでは、TiDB Cloud Starterのクラウドプロバイダーとして AWS を使用しています。ソースまたは宛先として Amazon S3 を使用するには、AWS Lambda の`region`を Amazon S3 と同じに設定する必要があります。 > - 既に`sam deploy --guided`を実行したことがある場合は、代わりに`sam deploy`を実行するだけで、SAM CLI は設定ファイル`samconfig.toml`を使用して操作を簡素化します。 diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index 71eaf0ae2acba..4ec22456ba4d4 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -20,7 +20,7 @@ aliases: ['/ja/tidb/stable/dev-guide-connection-parameters/','/ja/tidb/dev/dev-g TiDB（MySQL）接続の構築は、（少なくともOLTPシナリオにおいては）比較的コストがかかります。これは、TCP接続の確立に加えて、接続認証も必要となるためです。そのため、クライアントは通常、TiDB（MySQL）接続を接続プールに保存して再利用します。 -Javaには[Tomcat JDBC](https://tomcat.apache.org/tomcat-10.1-doc/jdbc-pool.html) [HikariCP](https://github.com/brettwooldridge/HikariCP) [dbcp](https://commons.apache.org/proper/commons-dbcp/)多くの接続プール実装があります。TiDBは使用できる接続プール[druid](https://github.com/alibaba/druid)制限しないため、アプリケーションに合わせて好きなもの[c3p0](https://www.mchange.com/projects/c3p0/)選択できます。 +Javaには[Tomcat JDBC](https://tomcat.apache.org/tomcat-10.1-doc/jdbc-pool.html) [HikariCP](https://github.com/brettwooldridge/HikariCP) [dbcp](https://commons.apache.org/proper/commons-dbcp/)多くの接続プール実装があります。TiDBは使用できる接続プール[druid](https://github.com/alibaba/druid)制限しないため、アプリケーションに合わせて好きなもの[c3p0](https://www.mchange.com/projects/c3p0/)を選択できます。 ### 接続数を設定する {#configure-the-number-of-connections} @@ -118,7 +118,7 @@ connections = ((core_count * 2) + effective_spindle_count) このメモは以下を示しています。 -- **core_countは**、 [ハイパースレッディング](https://en.wikipedia.org/wiki/Hyper-threading)有効にするかどうかに関わらず、物理コアの数です。 +- **core_countは**、 [ハイパースレッディング](https://en.wikipedia.org/wiki/Hyper-threading)を有効にするかどうかに関わらず、物理コアの数です。 - データが完全にキャッシュされると、 **effective_spindle_count を**`0`に設定する必要があります。キャッシュのヒット率が低下すると、カウントは実際の数値である`HDD`に近づきます。 - **この計算式が*SSD*にも有効かどうかは検証されておらず、不明である。** @@ -164,7 +164,7 @@ OLTP（オンライン・トランザクション処理）シナリオでは、 > **Note:** > -> デフォルトのMySQL Connector/Jの実装では、 `addBatch()`でバッチに追加されたSQL文の送信時間は`executeBatch()`呼び出されるまで遅延されますが、実際のネットワーク転送中は文は1つずつ送信されます。そのため、この方法は通常、通信オーバーヘッドを削減しません。 +> デフォルトのMySQL Connector/Jの実装では、 `addBatch()`でバッチに追加されたSQL文の送信時間は`executeBatch()`が呼び出されるまで遅延されますが、実際のネットワーク転送中は文は1つずつ送信されます。そのため、この方法は通常、通信オーバーヘッドを削減しません。 > > バッチネットワーク転送を行う場合は、JDBC接続パラメータで`rewriteBatchedStatements = true`を設定する必要があります。詳細なパラメータ設定については、 [バッチ関連パラメータ](#batch-related-parameters)を参照してください。 @@ -180,7 +180,7 @@ JDBCでは通常、以下の2つの処理方法が使用されます。 クライアントが読み取りを完了するか、 `resultset`閉じる前にクエリでこのようなエラーが発生するのを回避するには、URLに`clobberStreamingResults=true`パラメータを追加できます。そうすると、 `resultset`自動的に閉じられますが、前のストリーミングクエリで読み取られる結果セットは失われます。 -- 2つ目の方法：まず正の整数として[`FetchSize`設定](http://makejavafaster.blogspot.com/2015/06/jdbc-fetch-size-performance.html)設定し、次にJDBC URLで`useCursorFetch = true`設定することで、カーソルフェッチを使用します。 +- 2つ目の方法：まず正の整数として[`FetchSize`設定](http://makejavafaster.blogspot.com/2015/06/jdbc-fetch-size-performance.html)設定し、次にJDBC URLで`useCursorFetch = true`を設定することで、カーソルフェッチを使用します。 TiDBは両方の方法をサポートしていますが、実装がよりシンプルで実行効率も優れているため、 `FetchSize`から`Integer.MIN_VALUE`に設定する最初の方法を使用することをお勧めします。 @@ -207,14 +207,14 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 - **`cachePrepStmts`** - `useServerPrepStmts=true`ではサーバーがプリペアドステートメントを実行できますが、デフォルトではクライアントは実行後にプリペアドステートメントを閉じ、再利用しません。つまり、「準備」操作はテキストファイルの実行ほど効率的ではありません。この問題を解決するには、 `useServerPrepStmts=true`設定した後、 `cachePrepStmts=true`設定することをお勧めします。これにより、クライアントはプリペアドステートメントをキャッシュできるようになります。 + `useServerPrepStmts=true`ではサーバーがプリペアドステートメントを実行できますが、デフォルトではクライアントは実行後にプリペアドステートメントを閉じ、再利用しません。つまり、「準備」操作はテキストファイルの実行ほど効率的ではありません。この問題を解決するには、 `useServerPrepStmts=true`を設定した後、 `cachePrepStmts=true`を設定することをお勧めします。これにより、クライアントはプリペアドステートメントをキャッシュできるようになります。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 - TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 - リクエスト内の`COM_STMT_EXECUTE`の数が`COM_STMT_PREPARE`の数よりはるかに多い場合、この設定は既に有効になっていることを意味します。 - さらに、 `useConfigs=maxPerformance`設定すると、 `cachePrepStmts=true`含む複数のパラメータが同時に設定されます。 + さらに、 `useConfigs=maxPerformance`を設定すると、 `cachePrepStmts=true`含む複数のパラメータが同時に設定されます。 - **prepStmtCacheSqlLimit** @@ -238,7 +238,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 #### バッチ関連パラメータ {#batch-related-parameters} -バッチ書き込みを処理する際は、 `rewriteBatchedStatements=true`設定することをお勧めします。`addBatch()`または`executeBatch()`を使用した後でも、JDBC はデフォルトでは SQL を 1つずつ送信します。例: +バッチ書き込みを処理する際は、 `rewriteBatchedStatements=true`を設定することをお勧めします。`addBatch()`または`executeBatch()`を使用した後でも、JDBC はデフォルトでは SQL を 1つずつ送信します。例: ```java pstmt = prepare("INSERT INTO `t` (a) values(?)"); @@ -258,7 +258,7 @@ INSERT INTO `t` (`a`) VALUES(11); INSERT INTO `t` (`a`) VALUES(12); ``` -しかし、 `rewriteBatchedStatements=true`設定すると、TiDB に送信される SQL ステートメントは単一の`INSERT`ステートメントになります。 +しかし、 `rewriteBatchedStatements=true`を設定すると、TiDB に送信される SQL ステートメントは単一の`INSERT`ステートメントになります。 ```sql INSERT INTO `t` (`a`) values(10),(11),(12); diff --git a/develop/dev-guide-optimistic-and-pessimistic-transaction.md b/develop/dev-guide-optimistic-and-pessimistic-transaction.md index 6c44387ef7afe..9b7e438f80747 100644 --- a/develop/dev-guide-optimistic-and-pessimistic-transaction.md +++ b/develop/dev-guide-optimistic-and-pessimistic-transaction.md @@ -583,7 +583,7 @@ func createUser(txn *util.TiDBSqlTx, id int, nickname string, balance decimal.De } ``` -次に、 `helper.go`呼び出して受信したコマンドライン引数を処理する`txn.go`と`main`関数を記述します。 +次に、 `helper.go`を呼び出して受信したコマンドライン引数を処理する`txn.go`と`main`関数を記述します。 ```go package main diff --git a/develop/dev-guide-paginate-results.md b/develop/dev-guide-paginate-results.md index e4e171ef73c12..08a79c911dfd9 100644 --- a/develop/dev-guide-paginate-results.md +++ b/develop/dev-guide-paginate-results.md @@ -78,7 +78,7 @@ public List getLatestBooksPage(Long pageNumber, Long pageSize) throws SQLE
-まず、データを主キーでソートし、ウィンドウ関数`row_number()`呼び出して各行の行番号を生成します。次に、集計関数を呼び出して行番号を指定されたページサイズでグループ化し、各ページの最小値と最大値を計算します。 +まず、データを主キーでソートし、ウィンドウ関数`row_number()`を呼び出して各行の行番号を生成します。次に、集計関数を呼び出して行番号を指定されたページサイズでグループ化し、各ページの最小値と最大値を計算します。 ```sql SELECT diff --git a/develop/dev-guide-timeouts-in-tidb.md b/develop/dev-guide-timeouts-in-tidb.md index 5737205237955..611737bd5d38e 100644 --- a/develop/dev-guide-timeouts-in-tidb.md +++ b/develop/dev-guide-timeouts-in-tidb.md @@ -22,7 +22,7 @@ TiDBのトランザクション実装では、MVCC（Multiple Version Concurrenc 一時的に読み取り時間を長くする必要がある場合は、MVCC バージョンの保持時間を長くすることができます。 -- v5.0 より前の TiDB バージョンの場合: TiDB の`mysql.tidb`のテーブルの`tikv_gc_life_time`調整します。 +- v5.0 より前の TiDB バージョンの場合: TiDB の`mysql.tidb`のテーブルの`tikv_gc_life_time`を調整します。 - TiDB v5.0 以降のバージョンの場合: システム変数[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)を調整します。 システム変数の設定はグローバルかつ即座に反映されます。値を増やすと既存のスナップショットの有効期間が延長され、値を減らすとすべてのスナップショットの有効期間が即座に短縮されます。MVCCのバージョンが多すぎると、TiDBクラスタのパフォーマンスに影響します。そのため、この変数は適切なタイミングで以前の設定に戻す必要があります。 diff --git a/develop/dev-guide-unstable-result-set.md b/develop/dev-guide-unstable-result-set.md index ea2776a94434d..ec8ee9d2f4a12 100644 --- a/develop/dev-guide-unstable-result-set.md +++ b/develop/dev-guide-unstable-result-set.md @@ -112,7 +112,7 @@ mysql> select a.class, a.stuname, max(b.courscore) from stu_info a join stu_scor ERROR 1055 (42000): Expression #2 of ORDER BY is not in GROUP BY clause and contains nonaggregated column '' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by ``` -**実行結果**: 上記の例は、 `sql_mode`に`ONLY_FULL_GROUP_BY`設定した場合の効果を示しています。 +**実行結果**: 上記の例は、 `sql_mode`に`ONLY_FULL_GROUP_BY`を設定した場合の効果を示しています。 ## 注文方法 {#order-by} diff --git a/develop/dev-guide-use-stale-read.md b/develop/dev-guide-use-stale-read.md index c8019488a3eb7..a66cc6d801367 100644 --- a/develop/dev-guide-use-stale-read.md +++ b/develop/dev-guide-use-stale-read.md @@ -292,7 +292,7 @@ public static class StaleReadHelper { } ``` -次に、 `BookDAO`クラスのトランザクションを通じてステイル読み取り機能を有効にするメソッドを定義します。クエリ文に`AS OF TIMESTAMP`追加する代わりに、このメソッドを使用してクエリを実行します。 +次に、 `BookDAO`クラスのトランザクションを通じてステイル読み取り機能を有効にするメソッドを定義します。クエリ文に`AS OF TIMESTAMP`を追加する代わりに、このメソッドを使用してクエリを実行します。 ```java public class BookDAO { @@ -398,7 +398,7 @@ public static class TxnHelper { } ``` -次に、 `BookDAO`クラスのトランザクションを通じてステイル読み取り機能を有効にするメソッドを定義します。クエリ文に`AS OF TIMESTAMP`追加する代わりに、このメソッドを使用してクエリを実行します。 +次に、 `BookDAO`クラスのトランザクションを通じてステイル読み取り機能を有効にするメソッドを定義します。クエリ文に`AS OF TIMESTAMP`を追加する代わりに、このメソッドを使用してクエリを実行します。 ```java public class BookDAO { diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index 810d4f5def6af..2dcd26cbb054b 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -50,7 +50,7 @@ OLTP (オンライン トランザクション処理) シナリオの場合、 #### バッチAPIを使用する {#use-batch-api} -バッチ挿入の場合は、 [`addBatch` / `executeBatch` API](https://docs.oracle.com/en/java/javase/25/docs/api/java.sql/java/sql/Statement.html#executeBatch())使用できます。 `addBatch()`メソッドは、複数の SQL ステートメントを最初にクライアントにキャッシュし、 `executeBatch`メソッドを呼び出すときにそれらをまとめてデータベースサーバーに送信するために使用されます。 +バッチ挿入の場合は、 [`addBatch` / `executeBatch` API](https://docs.oracle.com/en/java/javase/25/docs/api/java.sql/java/sql/Statement.html#executeBatch())を使用できます。 `addBatch()`メソッドは、複数の SQL ステートメントを最初にクライアントにキャッシュし、 `executeBatch`メソッドを呼び出すときにそれらをまとめてデータベースサーバーに送信するために使用されます。 > **Note:** > @@ -220,7 +220,7 @@ jdbc:mysql://:/?characterEncoding=UTF-8& > **Note:** > -> パブリック ネットワーク経由で接続している場合は、 `useSSL=true`と[TiDBクライアントとサーバー間でTLSを有効にする](/enable-tls-between-clients-and-servers.md)設定する必要があります。 +> パブリック ネットワーク経由で接続している場合は、 `useSSL=true`と[TiDBクライアントとサーバー間でTLSを有効にする](/enable-tls-between-clients-and-servers.md)を設定する必要があります。 ## 接続プール {#connection-pool} diff --git a/dm/dm-compatibility-catalog.md b/dm/dm-compatibility-catalog.md index 0d838c5f2e786..dcd0789f30cc7 100644 --- a/dm/dm-compatibility-catalog.md +++ b/dm/dm-compatibility-catalog.md @@ -53,7 +53,7 @@ DMは、さまざまなソースからTiDBクラスタへのデータ移行を - `foreign_key_checks=1`の場合、外部キーのメタデータは、ソースとダウンストリーム間で一貫している必要があります。DM が不整合を検出した場合は、 `binlog-schema update --from-target`を実行してメタデータを再同期してください。 - セーフモードで`foreign_key_checks=1`を有効にすると、`UPDATE`が主キーまたは一意キーの値を変更する場合、DM は`ON UPDATE CASCADE`を正しく複製しません。DM は、このようなステートメントを`DELETE` + `REPLACE`に書き換え、 `ON DELETE`アクションではなく`ON UPDATE`アクションをトリガーします。この場合、DM はステートメントを拒否し、タスクを一時停止します。DM はキー値を変更しない`UPDATE`ステートメントを正しく複製します。 -バージョン8.5.6より前のバージョンでは、DMはダウンストリームに外部キー制約を作成しますが、セッション変数[`foreign_key_checks=OFF`](/system-variables.md#foreign_key_checks)設定するため、制約を適用しません。その結果、カスケード操作はダウンストリームに複製されません。 +バージョン8.5.6より前のバージョンでは、DMはダウンストリームに外部キー制約を作成しますが、セッション変数[`foreign_key_checks=OFF`](/system-variables.md#foreign_key_checks)を設定するため、制約を適用しません。その結果、カスケード操作はダウンストリームに複製されません。 ### MariaDBに関する注記 {#mariadb-notes} diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md index c9452a005d877..cebfad18e61af 100644 --- a/dm/dm-error-handling.md +++ b/dm/dm-error-handling.md @@ -172,7 +172,7 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ 6. `query-status`を使用して移行タスクのステータスを確認する。元のエラーの原因となったリレーログファイルの移行が完了したら、 `safe-mode`元の値に戻して移行タスクを再開できます。 -### タスクをクエリするかログを確認すると、 `Access denied for user 'root'@'172.31.43.27' (using password: YES)`表示されます。 {#access-denied-for-user-root172314327-using-password-yes-shows-when-you-query-the-task-or-check-the-log} +### タスクをクエリするかログを確認すると、 `Access denied for user 'root'@'172.31.43.27' (using password: YES)`が表示されます。 {#access-denied-for-user-root172314327-using-password-yes-shows-when-you-query-the-task-or-check-the-log} すべてのDM設定ファイルにおけるデータベース関連のパスワードについては、 `dmctl`で暗号化したパスワードを使用することをお勧めします。データベースパスワードが空の場合は、暗号化する必要はありません。プレーンテキストパスワードの暗号化方法については、 [dmctlを使用してデータベースパスワードを暗号化する](/dm/dm-manage-source.md#encrypt-the-database-password)を参照してください。 diff --git a/dm/dm-webui-guide.md b/dm/dm-webui-guide.md index 82a83cb497c98..4f3ba4d70c527 100644 --- a/dm/dm-webui-guide.md +++ b/dm/dm-webui-guide.md @@ -29,7 +29,7 @@ DM WebUI には次のページがあります。 ## アクセス方法 {#access-method} -[OpenAPI](/dm/dm-open-api.md#maintain-dm-clusters-using-openapi)有効にすると、DM クラスターの任意のマスターノードからDM WebUIにアクセスできます。アクセスポートはデフォルトで`8261`で、DM OpenAPI のポートと同じです。アクセスアドレスの例： `http://{master_ip}:{master_port}/dashboard/` 。 +[OpenAPI](/dm/dm-open-api.md#maintain-dm-clusters-using-openapi)を有効にすると、DM クラスターの任意のマスターノードからDM WebUIにアクセスできます。アクセスポートはデフォルトで`8261`で、DM OpenAPI のポートと同じです。アクセスアドレスの例： `http://{master_ip}:{master_port}/dashboard/` 。 ## 移住 {#migration} diff --git a/dm/feature-shard-merge-pessimistic.md b/dm/feature-shard-merge-pessimistic.md index ed53a9a52765f..a31ea5246a80e 100644 --- a/dm/feature-shard-merge-pessimistic.md +++ b/dm/feature-shard-merge-pessimistic.md @@ -92,7 +92,7 @@ sequenceDiagram 1. `DM-worker-1`は`t1`の MySQL インスタンス 1 から DDL ステートメントを受信し、対応する DDL および DML ステートメントのデータ移行を一時停止し、DDL 情報を`DM-master`に送信します。 2. `DM-master`は受信した DDL 情報に基づいてこの DDL ステートメントの移行を調整する必要があると判断し、この DDL ステートメントのロックを作成し、DDL ロック情報を`DM-worker-1`に送り返し、同時に`DM-worker-1`をこのロックの所有者としてマークします。 3. `DM-worker-2`は、`t3`の MySQL インスタンス 2 から DDL ステートメントを受信するまで DML ステートメントの移行を継続し、この DDL ステートメントのデータ移行を一時停止し、DDL 情報を`DM-master`に送信します。 -4. `DM-master`受信した DDL 情報に基づいて、この DDL ステートメントのロックが既に存在すると判断し、ロック情報を`DM-worker-2`に直接送信します。 +4. `DM-master`は受信した DDL 情報に基づいて、この DDL ステートメントのロックが既に存在すると判断し、ロック情報を`DM-worker-2`に直接送信します。 5. タスクの開始時の構成情報、アップストリームの MySQL インスタンスのシャーディングされたテーブル情報、およびデプロイメント トポロジ情報に基づいて、 `DM-master`はマージされるすべてのアップストリームのシャーディングされたテーブルのこの DDL ステートメントを受信したと判断し、DDL ロックの所有者 ( `DM-worker-1` ) にこの DDL ステートメントをダウンストリームに移行するように要求します。 6. `DM-worker-1`は、ステップ #2 で受信した DDL ロック情報に基づいて DDL ステートメント実行要求を検証し、この DDL ステートメントをダウンストリームに移行し、結果を`DM-master`に送信します。この操作が成功した場合、 `DM-worker-1`は後続の ( `t2`のbinlogから始まる) DML ステートメントの移行を続行します。 7. `DM-master`はロック所有者から DDL が正常に実行されたという応答を受け取り、DDL ロックを待機している他のすべての DM-worker ( `DM-worker-2` ) に、この DDL ステートメントを無視し、後続の ( `t4`のbinlogから始まる) DML ステートメントの移行を続行するように要求します。 diff --git a/dm/relay-log.md b/dm/relay-log.md index 1dedc9d4efb10..e7bd529853ea9 100644 --- a/dm/relay-log.md +++ b/dm/relay-log.md @@ -375,4 +375,4 @@ deb76a2b-09cc-11e9-9129-5242cf3bb246.000003 > **Note:** > - > 上流のリレーログがパージされている場合はエラーが発生します。この場合、移行の開始位置を指定するために[`relay-binlog-gtid`](/dm/dm-source-configuration-file.md#global-configuration)設定する必要があります。 + > 上流のリレーログがパージされている場合はエラーが発生します。この場合、移行の開始位置を指定するために[`relay-binlog-gtid`](/dm/dm-source-configuration-file.md#global-configuration)を設定する必要があります。 diff --git a/dr-multi-replica.md b/dr-multi-replica.md index 15d076ca4326d..f908835bcb529 100644 --- a/dr-multi-replica.md +++ b/dr-multi-replica.md @@ -89,8 +89,8 @@ summary: 単一クラスターのマルチレプリカ災害復旧ソリュー 上記の構成では、次のオプションを使用して、リージョン間 DR を最適化します。 - - `server.grpc-compression-type: gzip`設定すると、TiKV での gRPC メッセージ圧縮が有効になり、ネットワークトラフィックが削減されます。 - - `raftstore.raft-min-election-timeout-ticks`と`raftstore.raft-max-election-timeout-ticks`設定して、リージョン 3 が選挙に参加するまでの時間を延長し、このリージョン内のレプリカがリーダーとして投票されるのを防ぎます。 + - `server.grpc-compression-type: gzip`を設定すると、TiKV での gRPC メッセージ圧縮が有効になり、ネットワークトラフィックが削減されます。 + - `raftstore.raft-min-election-timeout-ticks`と`raftstore.raft-max-election-timeout-ticks`を設定して、リージョン 3 が選挙に参加するまでの時間を延長し、このリージョン内のレプリカがリーダーとして投票されるのを防ぎます。 2. 上記の構成ファイルを使用してクラスターを作成します。 diff --git a/enable-disk-spill-encrypt.md b/enable-disk-spill-encrypt.md index bc769ed7397b6..8f2a5aaf2928a 100644 --- a/enable-disk-spill-encrypt.md +++ b/enable-disk-spill-encrypt.md @@ -11,7 +11,7 @@ summary: TiDB でディスクスピルの暗号化を有効にする方法を学 ## 設定 {#configure} -ディスクスピル ファイルの暗号化を有効にするには、TiDB 構成ファイルのセクション`[security]`の項目[`spilled-file-encryption-method`](/tidb-configuration-file.md#spilled-file-encryption-method)構成します。 +ディスクスピル ファイルの暗号化を有効にするには、TiDB 構成ファイルのセクション`[security]`の項目[`spilled-file-encryption-method`](/tidb-configuration-file.md#spilled-file-encryption-method)を構成します。 ```toml [security] diff --git a/enable-tls-between-components.md b/enable-tls-between-components.md index 144e0206fd6c7..7a330755b0fde 100644 --- a/enable-tls-between-components.md +++ b/enable-tls-between-components.md @@ -23,13 +23,13 @@ summary: TiDB コンポーネント間の TLS 認証を有効にする方法を - `openssl`選択した場合は[自己署名証明書の生成](/generate-self-signed-certificates.md)を参照できます。 + `openssl`を選択した場合は[自己署名証明書の生成](/generate-self-signed-certificates.md)を参照できます。 - `openssl`選択した場合は[自己署名証明書の生成](https://docs.pingcap.com/tidb/stable/generate-self-signed-certificates)を参照できます。 + `openssl`を選択した場合は[自己署名証明書の生成](https://docs.pingcap.com/tidb/stable/generate-self-signed-certificates)を参照できます。 @@ -151,7 +151,7 @@ summary: TiDB コンポーネント間の TLS 認証を有効にする方法を > **Note:** > -> - v8.4.0以降、PD構成項目`cert-allowed-cn`複数の値をサポートします。必要に応じて、TiDB用構成項目`cluster-verify-cn`とその他のコンポーネント用構成項目`cert-allowed-cn`に、複数の`Common Name`設定できます。TiUPはコンポーネントのステータスを照会する際に別の識別子を使用することに注意してください。例えば、クラスター名が`test`の場合、 TiUPは`Common Name`として`test-client`を使用します。 +> - v8.4.0以降、PD構成項目`cert-allowed-cn`複数の値をサポートします。必要に応じて、TiDB用構成項目`cluster-verify-cn`とその他のコンポーネント用構成項目`cert-allowed-cn`に、複数の`Common Name`を設定できます。TiUPはコンポーネントのステータスを照会する際に別の識別子を使用することに注意してください。例えば、クラスター名が`test`の場合、 TiUPは`Common Name`として`test-client`を使用します。 > - v8.3.0以前のバージョンでは、PD設定項目`cert-allowed-cn`には単一の値しか設定できません。そのため、すべての認証オブジェクトの`Common Name`同じ値に設定する必要があります。関連する設定例については、 [v8.3.0 ドキュメント](https://docs-archive.pingcap.com/tidb/v8.3/enable-tls-between-components/)を参照してください。 - TiDB diff --git a/encryption-at-rest.md b/encryption-at-rest.md index ee0d1f3514ed6..a8b6c653d36a2 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -171,7 +171,7 @@ credential-file-path = "/path/to/credential.json" ``` - `key-id` KMS CMK のキー ID を指定します。 -- `vendor = "gcp"` の場合、`credential-file-path`は検証資格情報ファイルのパスを指定します。現在、このファイルではサービスアカウントと認証ユーザーの2種類の資格情報がサポートされています。TiKVの実行環境が既に[アプリケーションのデフォルト資格情報](https://cloud.google.com/docs/authentication/application-default-credentials)で構成されている場合は、 `credential-file-path`設定する必要はありません。 +- `vendor = "gcp"` の場合、`credential-file-path`は検証資格情報ファイルのパスを指定します。現在、このファイルではサービスアカウントと認証ユーザーの2種類の資格情報がサポートされています。TiKVの実行環境が既に[アプリケーションのデフォルト資格情報](https://cloud.google.com/docs/authentication/application-default-credentials)で構成されている場合は、 `credential-file-path`を設定する必要はありません。 Google Cloud KMS シナリオで Workload Identity Federation (WIF) を使用する必要がある場合は、代わりに `gcp_v2` を使用します。 diff --git a/error-codes.md b/error-codes.md index 009b2d5eb05e5..0e386d455a47e 100644 --- a/error-codes.md +++ b/error-codes.md @@ -21,7 +21,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 リクエストによって使用されたメモリが、TiDBメモリ使用量のしきい値制限を超えています。 - システム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)構成して、単一の SQL ステートメントのメモリ制限を増やします。 + システム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)を構成して、単一の SQL ステートメントのメモリ制限を増やします。 - エラー番号: 8002 diff --git a/explain-overview.md b/explain-overview.md index 951edab17ecfc..93b6e0062f641 100644 --- a/explain-overview.md +++ b/explain-overview.md @@ -146,7 +146,7 @@ TiDBは、TiKV/ TiFlashからスキャンされたデータまたは計算結果 構造はツリー構造のように見えますが、クエリの実行において子ノードが親ノードより先に完了している必要は必ずしもありません。TiDBはクエリ内並列処理をサポートしているため、より正確な表現は、子ノードが親ノード*に流れ込む*というものです。親ノード、子ノード、兄弟ノードの演算子によって、クエリの一部が並列実行される可能性*があります*。 -前の例では、演算子`├─IndexRangeScan_8(Build)`はインデックス`a(a)`に一致する行の内部`RowID`検索します。次に、演算子`└─TableRowIDScan_9(Probe)`これらの行をテーブルから取得します。 +前の例では、演算子`├─IndexRangeScan_8(Build)`はインデックス`a(a)`に一致する行の内部`RowID`を検索します。次に、演算子`└─TableRowIDScan_9(Probe)`はこれらの行をテーブルから取得します。 #### 範囲クエリ {#range-query} diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md index f7b5c8c67b662..737bc4e9b76cc 100644 --- a/faq/backup-and-restore-faq.md +++ b/faq/backup-and-restore-faq.md @@ -259,7 +259,7 @@ br restore full -f '*.*' -f '!mysql.*' -f 'mysql.usertable' -s $external_storage - `-f '*.*'`はデフォルトのルールを上書きするために使用されます - `-f '!mysql.*'`特に指定がない限り、 `mysql`テーブルを復元しないようにBRに指示します。 -- `-f 'mysql.usertable'` `mysql.usertable`復元する必要があることを示します。 +- `-f 'mysql.usertable'` `mysql.usertable`を復元する必要があることを示します。 `mysql.usertable`を復元する必要がある場合は、次のコマンドを実行します。 diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 2305ff358244c..bede7ca1f0adc 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -69,7 +69,7 @@ TiDB `label`の設定は、クラスタのデプロイメントアーキテク ### `fio`コマンドを使用して TiKV インスタンスのディスク パフォーマンスをテストするにはどうすればよいですか? {#how-to-use-the-fio-command-to-test-the-disk-performance-of-the-tikv-instance} -以下の例では`ioengine=psync` （同期I/O）を使用しているため、 `iodepth`通常`1`に固定され、同時実行性は主に`numjobs`によって制御されます。ファイルシステムキャッシュをバイパスするには、 `direct=1`設定することをお勧めします。 +以下の例では`ioengine=psync` （同期I/O）を使用しているため、 `iodepth`は通常`1`に固定され、同時実行性は主に`numjobs`によって制御されます。ファイルシステムキャッシュをバイパスするには、 `direct=1`を設定することをお勧めします。 - ランダム読み取りテスト: diff --git a/faq/high-reliability-faq.md b/faq/high-reliability-faq.md index b70c61c019ff2..d84c8e57e30d1 100644 --- a/faq/high-reliability-faq.md +++ b/faq/high-reliability-faq.md @@ -9,11 +9,11 @@ summary: TiDB の高信頼性に関連する FAQ について説明します。 ## TiDB はデータ暗号化をサポートしていますか? {#does-tidb-support-data-encryption} -はい。ネットワークトラフィック内のデータを暗号化するには、 [TiDBクライアントとサーバー間のTLSを有効にする](/enable-tls-between-clients-and-servers.md)有効にします。ストレージエンジン内のデータを暗号化するには、 [透過的なデータ暗号化（TDE）](/encryption-at-rest.md)有効にします。 +はい。ネットワークトラフィック内のデータを暗号化するには、 [TiDBクライアントとサーバー間のTLS](/enable-tls-between-clients-and-servers.md)を有効にします。ストレージエンジン内のデータを暗号化するには、 [透過的なデータ暗号化（TDE）](/encryption-at-rest.md)を有効にします。 ## TiDB は、サーバーの MySQL バージョン文字列を、セキュリティ脆弱性スキャン ツールに必要な特定のバージョンに変更することをサポートしていますか? {#does-tidb-support-modifying-the-mysql-version-string-of-the-server-to-a-specific-one-that-is-required-by-the-security-vulnerability-scanning-tool} -- v3.0.8 以降、TiDB は構成ファイル内の[`server-version`](/tidb-configuration-file.md#server-version)変更することでサーバーのバージョン文字列を変更することをサポートしています。 +- v3.0.8 以降、TiDB は構成ファイル内の[`server-version`](/tidb-configuration-file.md#server-version)を変更することでサーバーのバージョン文字列を変更することをサポートしています。 - v4.0 以降、 TiUPを使用して TiDB をデプロイする場合は、 `tiup cluster edit-config `を実行して次のセクションを編集することで、適切なバージョン文字列を指定することもできます。 diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md index 53b3e91b8dddb..923130434c23b 100644 --- a/faq/migration-tidb-faq.md +++ b/faq/migration-tidb-faq.md @@ -113,7 +113,7 @@ Sqoopでは、 `--batch`各バッチで100個の`statement`文をコミットす この問題には次の原因が考えられます。 -- データベースの主キーが均等に分散されていません (たとえば、 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)有効にした場合)。 +- データベースの主キーが均等に分散されていません (たとえば、 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)を有効にした場合)。 - アップストリーム データベースは TiDB であり、エクスポートされたテーブルはパーティションテーブルです。 上記のケースでは、 Dumpling はエクスポート時に過度に大きなデータチャンクを分割し、過度に大きな結果を含むクエリを送信します。この問題に対処するには、 Dumplingの最新バージョンを入手してください。 diff --git a/faq/sql-faq.md b/faq/sql-faq.md index b436cee6b3aaa..b787756b5e2cc 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -9,7 +9,7 @@ summary: TiDB SQLに関連する FAQ について説明します。 ## TiDB はセカンダリキーをサポートしていますか? {#does-tidb-support-the-secondary-key} -はい。主キーではない列に、一意の[セカンダリインデックス](/develop/dev-guide-create-secondary-indexes.md)を持つ[`NOT NULL`制約](/constraints.md#not-null)設定できます。この場合、その列はセカンダリキーとして機能します。 +はい。主キーではない列に、一意の[セカンダリインデックス](/develop/dev-guide-create-secondary-indexes.md)を持つ[`NOT NULL`制約](/constraints.md#not-null)を設定できます。この場合、その列はセカンダリキーとして機能します。 ## 大きなテーブルで DDL 操作を実行する場合、TiDB はどのように機能しますか? {#how-does-tidb-perform-when-executing-ddl-operations-on-a-large-table} @@ -146,7 +146,7 @@ TiDBのデフォルトの文字セットは`utf8mb4`です。文字列はmemcomp TiDBのAUTO_INCREMENT ID機能は、自動的に増分され一意であることが保証されているだけで、連続的に割り当てられることは保証されていません。現在、TiDBはIDをバッチで割り当てています。複数のTiDBサーバーに同時にデータが挿入された場合、割り当てられるIDは連続的ではありません。複数のスレッドが`tidb-server`のインスタンスに同時にデータを挿入した場合、後で挿入されたデータのAUTO_INCREMENT IDは小さくなる可能性があります。TiDBでは整数フィールドに`AUTO_INCREMENT`を指定できますが、1つのテーブルに`AUTO_INCREMENT`フィールドは1つしか指定できません。詳細については、 [AUTO_INCREMENT ID](/mysql-compatibility.md#auto-increment-id)と[AUTO_INCREMENT属性](/auto-increment.md)を参照してください。 -## TiDB の`sql_mode`変更するにはどうすればよいですか? {#how-do-i-modify-the-sql_mode-in-tidb} +## TiDB の`sql_mode`を変更するにはどうすればよいですか? {#how-do-i-modify-the-sql_mode-in-tidb} TiDB は、SESSION または GLOBAL ベースで[`sql_mode`](/system-variables.md#sql_mode)システム変数を変更することをサポートします。 @@ -231,7 +231,7 @@ TiDBは、 [グローバル](/system-variables.md#tidb_force_priority)単位ま システム変数`tidb_auto_analyze_ratio`のデフォルト値は`0.5`で、この機能がデフォルトで有効になっていることを示します。システム変数`tidb_auto_analyze_ratio`を[`pseudo-estimate-ratio`](/tidb-configuration-file.md#pseudo-estimate-ratio)以上（デフォルト値は`0.8` ）に設定することは推奨されません。そうしないと、オプティマイザーが疑似統計を使用する可能性があります。TiDB v5.3.0 では[`tidb_enable_pseudo_for_outdated_stats`](/system-variables.md#tidb_enable_pseudo_for_outdated_stats-new-in-v530)変数が導入され、これを`OFF`に設定すると、統計が古くても疑似統計は使用されません。 -`auto analyze`無効にするには、システム変数[`tidb_enable_auto_analyze`](/system-variables.md#tidb_enable_auto_analyze-new-in-v610)を使用します。 +`auto analyze`を無効にするには、システム変数[`tidb_enable_auto_analyze`](/system-variables.md#tidb_enable_auto_analyze-new-in-v610)を使用します。 ## オプティマイザーヒントを使用してオプティマイザーの動作をオーバーライドできますか? {#can-i-use-optimizer-hints-to-override-the-optimizer-behavior} @@ -451,7 +451,7 @@ RUNNING_JOBS: ID:121, Type:add index, State:running, SchemaState:write reorganiz はい。TiDBはコストベースオプティマイザを使用しています。コストモデルと統計は常に最適化されています。また、TiDBはハッシュ結合やソートマージ結合などの結合アルゴリズムもサポートしています。 -### テーブルで`analyze`実行する必要があるかどうかを判断するにはどうすればよいでしょうか? {#how-to-determine-whether-i-need-to-execute-analyze-on-a-table} +### テーブルで`analyze`を実行する必要があるかどうかを判断するにはどうすればよいでしょうか? {#how-to-determine-whether-i-need-to-execute-analyze-on-a-table} `SHOW STATS_HEALTHY`を使用して`Healthy`フィールドを確認します。通常、フィールド値が 60 より小さい場合は、テーブルで`ANALYZE`を実行する必要があります。 diff --git a/faq/upgrade-faq.md b/faq/upgrade-faq.md index f16336580de89..ee3bfb4193a25 100644 --- a/faq/upgrade-faq.md +++ b/faq/upgrade-faq.md @@ -283,9 +283,9 @@ TiDB v2.1.1以前のバージョンでは、文字セットがUTF-8の場合、 具体的には、変数`tidb_skip_utf8_check`を使用すると、データのUTF-8およびUTF8MB4の有効性チェックをスキップできます。ただし、チェックをスキップしても、MySQL側ではチェックが実行されるため、TiDBからMySQLへのデータのレプリケーションに失敗する可能性があります。 - UTF-8チェックのみをスキップしたい場合は、 `tidb_check_mb4_value_in_utf8`設定できます。この変数はv2.1.3で`config.toml`ファイルに追加され、設定ファイルの`check-mb4-value-in-utf8`変更してクラスターを再起動することで有効になります。 + UTF-8チェックのみをスキップしたい場合は、 `tidb_check_mb4_value_in_utf8`を設定できます。この変数はv2.1.3で`config.toml`ファイルに追加され、設定ファイルの`check-mb4-value-in-utf8`を変更してクラスターを再起動することで有効になります。 - v2.1.5 以降では、HTTP API とセッション変数を通じて`tidb_check_mb4_value_in_utf8`設定できます。 + v2.1.5 以降では、HTTP API とセッション変数を通じて`tidb_check_mb4_value_in_utf8`を設定できます。 - HTTP API（HTTP APIは単一のサーバーでのみ有効化できます） diff --git a/foreign-key.md b/foreign-key.md index 29e595850b145..c66d034d20897 100644 --- a/foreign-key.md +++ b/foreign-key.md @@ -187,7 +187,7 @@ TiDBは外部キー制約チェックをサポートしており、これはシ デフォルトでは、悲観的トランザクションでは、親テーブルの行に対する外部キーチェックのロック動作は、対応する行に対して`SELECT ... FOR UPDATE`を使用してロック読み取りを実行すること（つまり、排他ロックを取得すること）と同等です。子テーブルに対する高同時実行書き込みシナリオで、多数のトランザクションが同じ親テーブルの行を繰り返し参照する場合、深刻なロック競合が発生する可能性があります。 -システム変数[`tidb_foreign_key_check_in_shared_lock`](/system-variables.md#tidb_foreign_key_check_in_shared_lock-new-in-v856)有効にすると、外部キーチェックで共有ロックを使用できるようになります。共有ロックを使用すると、複数のトランザクションが同じ親テーブルの行に対して同時に外部キーチェックを実行できるため、ロックの競合が軽減され、子テーブルへの同時書き込みのパフォーマンスが向上します。 +システム変数[`tidb_foreign_key_check_in_shared_lock`](/system-variables.md#tidb_foreign_key_check_in_shared_lock-new-in-v856)を有効にすると、外部キーチェックで共有ロックを使用できるようになります。共有ロックを使用すると、複数のトランザクションが同じ親テーブルの行に対して同時に外部キーチェックを実行できるため、ロックの競合が軽減され、子テーブルへの同時書き込みのパフォーマンスが向上します。 ## 外部キーの定義とメタデータ {#definition-and-metadata-of-foreign-keys} @@ -313,7 +313,7 @@ Create Table | CREATE TABLE `child` ( - [DM](/dm/dm-overview.md) : v8.5.6以降、DMは実験的機能として外部キー制約を使用するテーブルのレプリケーションをサポートしています。サポートされているシナリオと制限事項については、 [DM互換性カタログ](/dm/dm-compatibility-catalog.md#foreign-key-cascade-operations)を参照してください。 v8.5.6より前のバージョンでは、DMはTiDBへのデータレプリケーション時に[`foreign_key_checks`](/system-variables.md#foreign_key_checks)システム変数を無効にするため、カスケード操作はダウンストリームクラスタにレプリケートされません。 - [TiCDC](/ticdc/ticdc-overview.md) v6.6.0 は外部キーに対応しています。以前のバージョンの TiCDC では、外部キーを持つテーブルをレプリケートする際にエラーが発生する場合があります。TiCDC バージョン 6.6.0 より前のバージョンを使用する場合は、ダウンストリーム TiDB クラスタの`foreign_key_checks`を無効にすることをお勧めします。 -- [BR](/br/backup-and-restore-overview.md) v6.6.0 は外部キーに対応しています。以前のバージョンのBRでは、外部キーを持つテーブルを v6.6.0 以降のクラスタに復元する際にエラーが発生する場合があります。v6.6.0 より前のバージョンのBRを使用する場合は、クラスタを復元する前に、ダウンストリーム TiDB クラスタの`foreign_key_checks`無効にすることをお勧めします。 +- [BR](/br/backup-and-restore-overview.md) v6.6.0 は外部キーに対応しています。以前のバージョンのBRでは、外部キーを持つテーブルを v6.6.0 以降のクラスタに復元する際にエラーが発生する場合があります。v6.6.0 より前のバージョンのBRを使用する場合は、クラスタを復元する前に、ダウンストリーム TiDB クラスタの`foreign_key_checks`を無効にすることをお勧めします。 - [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用する場合、対象テーブルで外部キーが使用されている場合は、データのインポート前にダウンストリーム TiDB クラスタの`foreign_key_checks`を無効にすることをお勧めします。v6.6.0 より前のバージョンでは、このシステム変数を無効にしても効果がなく、ダウンストリームデータベースユーザーに`REFERENCES`権限を付与するか、ダウンストリームデータベースに対象テーブルを事前に手動で作成して、スムーズなデータインポートを確保する必要があります。 diff --git a/functions-and-operators/precision-math.md b/functions-and-operators/precision-math.md index 4774abf9608c5..9bfd2a94cf578 100644 --- a/functions-and-operators/precision-math.md +++ b/functions-and-operators/precision-math.md @@ -82,7 +82,7 @@ SET sql_mode = 'TRADITIONAL`; - 厳密モードでは、数字で始まっていない文字列（空文字列を含む）を数字として使用することはできません。エラーまたは警告が発生します。 - 数値で始まる文字列は変換可能ですが、末尾の非数値部分は切り捨てられます。厳密モードでは、切り捨てられた部分にスペース以外の文字が含まれている場合、エラーまたは警告が発生します。 -デフォルトでは、0による除算の結果はNULLとなり、警告は表示されません。SQLモードを適切に設定することで、0による除算を制限できます。SQLモード`ERROR_FOR_DIVISION_BY_ZERO`有効にすると、TiDBは0による除算を以下のように処理します。 +デフォルトでは、0による除算の結果はNULLとなり、警告は表示されません。SQLモードを適切に設定することで、0による除算を制限できます。SQLモード`ERROR_FOR_DIVISION_BY_ZERO`を有効にすると、TiDBは0による除算を以下のように処理します。 - 厳密モードでは、挿入と更新は禁止され、エラーが発生します。 - 厳密モードでない場合は警告が発生します。 diff --git a/functions-and-operators/set-operators.md b/functions-and-operators/set-operators.md index aa3a8c49b217e..6452b5bea3dd6 100644 --- a/functions-and-operators/set-operators.md +++ b/functions-and-operators/set-operators.md @@ -114,7 +114,7 @@ TiDB は、括弧を使用して集合演算の優先順位を指定すること 1 rows in set (0.00 sec) ``` -## `ORDER BY`と`LIMIT`使用する {#use-order-by-and-limit} +## `ORDER BY`と`LIMIT`を使用する {#use-order-by-and-limit} TiDBは、集合演算の結果全体に対して`ORDER BY`または`LIMIT`句の使用をサポートしています。これらの2つの句は、ステートメント全体の末尾に配置する必要があります。 diff --git a/global-indexes.md b/global-indexes.md index ed441ea7ade1b..36f7eabbb3d6b 100644 --- a/global-indexes.md +++ b/global-indexes.md @@ -219,7 +219,7 @@ CREATE TABLE `sbtest` ( ### エンコード方法 {#encoding-method} -TiDBでは、インデックスエントリはキーと値のペアとしてエンコードされます。パーティションテーブルの場合、各パーティションはTiKVレイヤーで独立した物理テーブルとして扱われ、それぞれに`partitionID`設定されます。したがって、パーティションテーブルにおけるインデックスエントリのエンコードは次のようになります。 +TiDBでは、インデックスエントリはキーと値のペアとしてエンコードされます。パーティションテーブルの場合、各パーティションはTiKVレイヤーで独立した物理テーブルとして扱われ、それぞれに`partitionID`が設定されます。したがって、パーティションテーブルにおけるインデックスエントリのエンコードは次のようになります。 ``` Unique key diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index e245c5cb6c75d..5c0fdc0d5f77c 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -75,7 +75,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - トランザクション書き込みサイズバイトレートと合計: トランザクション内で書き込まれるバイト数と書き込まれたバイト数の合計 - トランザクション書き込みサイズバイト: トランザクションで書き込まれたデータのサイズ - 悲観的ロックの取得期間: ロックの追加にかかる時間 -- TTL 寿命到達カウンタ: TTL の上限に達したトランザクションの数。TTL 上限のデフォルト値は 1時間です。これは、悲観的トランザクションの最初のロック、または楽観的トランザクションの最初の事前書き込みから 1時間が経過したことを意味します。TTL 上限のデフォルト値は 1時間です。TTL 寿命の上限は、TiDB 設定ファイルで`max-txn-TTL`変更することで変更できます。 +- TTL 寿命到達カウンタ: TTL の上限に達したトランザクションの数。TTL 上限のデフォルト値は 1時間です。これは、悲観的トランザクションの最初のロック、または楽観的トランザクションの最初の事前書き込みから 1時間が経過したことを意味します。TTL 上限のデフォルト値は 1時間です。TTL 寿命の上限は、TiDB 設定ファイルで`max-txn-TTL`を変更することで変更できます。 - ロードセーフポイントOPS: `Safepoint`がロードされる回数。`Safepoint`は 、トランザクションがデータを読み取る際に`Safepoint`より前のデータが読み込まれないようにすることで、データの安全性を確保するためのものです`Safepoint`より前のデータはGCによってクリーンアップされる可能性があります。 - 悲観的ステートメント再試行回数（OPS）：悲観的ステートメントの再試行回数。ステートメントがロックを追加しようとすると、書き込み競合が発生する可能性があります。この場合、ステートメントは新しいスナップショットを取得し、再度ロックを追加します。 - 1秒あたりのトランザクションタイプ: 2フェーズコミット (2PC)、非同期コミット、および1フェーズコミット (1PC) メカニズムを使用して1秒あたりにコミットされたトランザクションの数 (成功トランザクションと失敗トランザクションの両方を含む) diff --git a/log-redaction.md b/log-redaction.md index aa16fd85d7af1..eae61f898304d 100644 --- a/log-redaction.md +++ b/log-redaction.md @@ -11,7 +11,7 @@ TiDBが詳細なログ情報を提供する場合、ログに機密データ（ TiDB側でログの秘匿化を有効にするには、 [`global.tidb_redact_log`](/system-variables.md#tidb_redact_log)を`ON`または`MARKER`に設定します。この設定値のデフォルトは`OFF`で、ログの秘匿化が無効であることを意味します。 -`set`構文を使用してグローバル変数`tidb_redact_log`設定できます。 +`set`構文を使用してグローバル変数`tidb_redact_log`を設定できます。 ```sql set @@global.tidb_redact_log = ON; diff --git a/migrate-with-pt-ghost.md b/migrate-with-pt-ghost.md index bbda360856dd4..e9e708b58150b 100644 --- a/migrate-with-pt-ghost.md +++ b/migrate-with-pt-ghost.md @@ -7,7 +7,7 @@ summary: オンライン DDL ツール gh-ost または pt-osc を使用する 本番環境では、DDL実行中のテーブルロックによって、データベースからの読み取りまたは書き込みがある程度ブロックされる可能性があります。そのため、読み取りと書き込みへの影響を最小限に抑えるため、オンラインDDLツールを使用してDDLを実行することがよくあります。一般的なDDLツールは[gh-ost](https://github.com/github/gh-ost)と[pt-osc](https://www.percona.com/doc/percona-toolkit/3.0/pt-online-schema-change.html)です。 -DM を使用して MySQL から TiDB にデータを移行する場合、 `online-ddl`有効にして DM と gh-ost または pt-osc の連携を許可できます。 +DM を使用して MySQL から TiDB にデータを移行する場合、 `online-ddl`を有効にして DM と gh-ost または pt-osc の連携を許可できます。 詳細なレプリケーション手順については、シナリオごとに次のドキュメントを参照してください。 diff --git a/optimistic-transaction.md b/optimistic-transaction.md index 400f092b52fc6..7347302742ff4 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -174,7 +174,7 @@ tidb_retry_limit = 10 ステップ2では、TiDBは書き込み操作を含むSQLステートメントのみを再試行します。ただし、再試行中に、TiDBはトランザクションの開始を示す新しいバージョン番号を受け取ります。つまり、TiDBは新しいバージョン`start_ts`のデータを使用してSQLステートメントを再試行します。この場合、トランザクションが他のクエリ結果を使用してデータを更新すると、分離レベル`REPEATABLE READ`が侵害されるため、結果に矛盾が生じる可能性があります。 -アプリケーションが更新の損失を許容でき、 `REPEATABLE READ`分離整合性を必要としない場合は、 `tidb_disable_txn_auto_retry = OFF`設定することでこの機能を有効にできます。 +アプリケーションが更新の損失を許容でき、 `REPEATABLE READ`分離整合性を必要としない場合は、 `tidb_disable_txn_auto_retry = OFF`を設定することでこの機能を有効にできます。 ## 競合検出 {#conflict-detection} diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md index 716a4f7a0bcc2..1cb14c727746a 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -453,7 +453,7 @@ TiKV は次の手順で書き込み要求を処理します。 Raftstore は`Store`スレッドと`Apply`スレッドで構成されています。 - - `Store`スレッドはRaftメッセージと新しい`proposals`処理します。新しい`proposals`受信すると、リーダーノードの`Store`スレッドはローカルRaft DBに書き込み、メッセージを複数のフォロワーノードにコピーします。ほとんどの場合、この`proposals`正常に永続化されると、 `proposals`が正常にコミットされます。 + - `Store`スレッドはRaftメッセージと新しい`proposals`を処理します。新しい`proposals`を受信すると、リーダーノードの`Store`スレッドはローカルRaft DBに書き込み、メッセージを複数のフォロワーノードにコピーします。ほとんどの場合、この`proposals`正常に永続化されると、 `proposals`が正常にコミットされます。 - `Apply`スレッドはコミットされた`proposals`データをKV DBに書き込みます。データがKV DBに正常に書き込まれると、 `Apply`スレッドは書き込み要求が完了したことを外部に通知します。 ![TiKV Write](/media/performance/store_apply.png) @@ -545,8 +545,8 @@ v5.4.0 では、gPRC モジュールが最適化され、 Raftログのレプリ スレッド`Store`の場合、 `Commit Log Duration`は`Apply Log Duration`よりも明らかに高い値です。一方、 `Append Log Duration`は`Apply Log Duration`よりも大幅に高い値であり、スレッド`Store`はCPUとI/Oの両方でボトルネックが発生している可能性があることを示しています。`Commit Log Duration`と`Append Log Duration`を削減する方法としては、以下のものが考えられます。 - TiKV CPU リソースが十分な場合は、 `raftstore.store-pool-size`の値を増やして`Store`スレッドを追加することを検討してください。 -- TiDBがv5.4.0以降の場合は、 `raft-engine.enable: true`設定して[`Raft Engine`](/tikv-configuration-file.md#raft-engine)有効にすることを検討してください。RaftRaft Engineは軽量な実行パスを備えています。これにより、I/O書き込みの削減と、一部のシナリオにおける書き込みのロングテールレイテンシーの削減に役立ちます。 -- TiKV CPU リソースが十分で、TiDB が v5.3.0 以降の場合は、 `raftstore.store-io-pool-size: 1`設定して[`StoreWriter`](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)有効にすることを検討してください。 +- TiDBがv5.4.0以降の場合は、 `raft-engine.enable: true`を設定して[`Raft Engine`](/tikv-configuration-file.md#raft-engine)を有効にすることを検討してください。RaftRaft Engineは軽量な実行パスを備えています。これにより、I/O書き込みの削減と、一部のシナリオにおける書き込みのロングテールレイテンシーの削減に役立ちます。 +- TiKV CPU リソースが十分で、TiDB が v5.3.0 以降の場合は、 `raftstore.store-io-pool-size: 1`を設定して[`StoreWriter`](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を有効にすることを検討してください。 ## TiDB のバージョンが v6.1.0 より前の場合、パフォーマンス概要ダッシュボードを使用するにはどうすればよいですか? {#if-my-tidb-version-is-earlier-than-v6-1-0-what-should-i-do-to-use-the-performance-overview-dashboard} diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index 186da6172d4bd..f7a3d74b059a5 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -357,7 +357,7 @@ RC 読み取りを使用した後、QPS は 30.9k から 34.9k に増加し、 ` ### 分析の結論 {#analysis-conclusion} -RC Read を`set global tidb_rc_read_check_ts=on;`有効にした後、RC Read によって`tso cmd`の時間が大幅に短縮され、 `tso wait`と平均クエリ期間が短縮され、QPS が向上しました。 +RC Read を`set global tidb_rc_read_check_ts=on;`で有効にした後、RC Read によって`tso cmd`の時間が大幅に短縮され、 `tso wait`と平均クエリ期間が短縮され、QPS が向上しました。 現在のデータベース時間とレイテンシーの両方のボトルネックはフェーズ`execute`にあり、このフェーズでは`Get`と`Cop`の読み取りリクエストが最も高い割合を占めています。このワークロードのテーブルのほとんどは読み取り専用か、ほとんど変更されないため、TiDB v6.0.0以降でサポートされている小さなテーブルのキャッシュ機能を使用して、これらの小さなテーブルのデータをキャッシュすることで、KV読み取りリクエストの待機時間とリソース消費を削減できます。 diff --git a/releases/release-2.0-ga.md b/releases/release-2.0-ga.md index 2fc4155b6397a..1d1b34fce9157 100644 --- a/releases/release-2.0-ga.md +++ b/releases/release-2.0-ga.md @@ -26,7 +26,7 @@ summary: 2018年4月27日にリリースされたTiDB 2.0 GAでは、MySQLとの - ストリーミング集計演算子のプッシュダウンをサポート - `Insert Into Ignore`ステートメントを最適化すると、パフォーマンスが10倍以上向上します - `Insert On Duplicate Key Update`ステートメントを最適化すると、パフォーマンスが10倍以上向上します - - `Load Data`最適化してパフォーマンスを10倍以上向上 + - `Load Data`を最適化してパフォーマンスを10倍以上向上 - より多くのデータ型と関数を TiKV にプッシュダウン - 物理演算子のメモリ使用量を計算し、メモリ使用量がしきい値を超えた場合の処理動作を構成ファイルとシステム変数で指定することをサポートします。 - OOM のリスクを軽減するために、単一の SQL 文によるメモリ使用量の制限をサポートします。 @@ -125,7 +125,7 @@ summary: 2018年4月27日にリリースされたTiDB 2.0 GAでは、MySQLとの - OOMを回避するためにスナップショットを受信するときにメモリ使用量を制限する - CIテストの速度を上げる - スナップショットが多すぎることによるOOM問題を修正 - - gRPCの`keepalive`構成する + - gRPCの`keepalive`を構成する - リージョン番号の増加によって発生するOOM問題を修正 ## TiSpark {#tispark} diff --git a/releases/release-2.0-rc.4.md b/releases/release-2.0-rc.4.md index 7991233741014..55ee89d1e6f03 100644 --- a/releases/release-2.0-rc.4.md +++ b/releases/release-2.0-rc.4.md @@ -19,7 +19,7 @@ summary: 2018年3月30日にリリースされたTiDB 2.0 RC4では、MySQLと - `CREATE VIEW`文の解析の問題を修正 - 1つの文に`ORDER BY`と`LIMIT 0`両方が含まれている場合にpanic問題を修正しました - `DecodeBytes`の実行パフォーマンスを向上させる -- 無駄な実行計画の作成を避けるために、 `LIMIT 0` ～ `TableDual`最適化します。 +- 無駄な実行計画の作成を避けるために、 `LIMIT 0` ～ `TableDual`を最適化します。 ## PD {#pd} diff --git a/releases/release-2.1-beta.md b/releases/release-2.1-beta.md index 3c83f3d32ed1e..432f571f4d581 100644 --- a/releases/release-2.1-beta.md +++ b/releases/release-2.1-beta.md @@ -13,7 +13,7 @@ summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイ - 実行パフォーマンスを向上させるために、選択範囲`Index Join`を最適化します。 - 相関サブクエリを最適化し、 `Filter`プッシュダウンし、インデックス範囲を拡張して、一部のクエリの効率を桁違いに向上させます。 - `UPDATE`と`DELETE`ステートメントの`Index Hint`と`Join Hint`をサポートする - - 利用可能なインデックスが存在しない場合にヒント`TIDM_SMJ`検証する + - 利用可能なインデックスが存在しない場合にヒント`TIDM_SMJ`を検証する - `ABS` `CEIL` `IS TRUE` `FLOOR`ダウン`IS FALSE`関数 - 特に定数の折り畳み処理で`IF`と`IFNULL`関数を処理する - SQL実行エンジン @@ -62,7 +62,7 @@ summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイ - Balance Scheduler が小さなリージョンを頻繁にスケジュールする問題を最適化します。 - ホットスポットスケジューラを最適化し、トラフィック統計情報のジッタに対する適応性を向上させます。 - `region merge`をスケジュールするときに行数の多い領域をスキップする -- スケジュール中にマシン障害によってデータが利用できなくなるリスクを軽減するために、デフォルトで`raft learner`有効にします。 +- スケジュール中にマシン障害によってデータが利用できなくなるリスクを軽減するために、デフォルトで`raft learner`を有効にします。 - `pd-recover`から`max-replica`取り除く - `Filter`指標を追加 - tikv-ctl unsafe リカバリ後にリージョン情報が更新されない問題を修正しました @@ -74,7 +74,7 @@ summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイ ## TiKV {#tikv} - Rustをバージョン`nightly-2018-06-14`にアップグレードする -- `Raft PreVote`有効にすると、ネットワーク分離後にネットワークが回復したときに生成されるリーダーの再選出を回避します。 +- `Raft PreVote`を有効にすると、ネットワーク分離後にネットワークが回復したときに生成されるリーダーの再選出を回避します。 - RocksDBの各レイヤーのファイル数と`ingest`関連情報を表示するメトリックを追加します。 - GC が機能しているときにバージョンが多すぎると`key`印刷する - `static metric`を使用してマルチラベルメトリックのパフォーマンスを最適化します（YCSB `raw get`が3％向上します） diff --git a/releases/release-2.1-ga.md b/releases/release-2.1-ga.md index ee2e10d7a3755..3adae7a33d85a 100644 --- a/releases/release-2.1-ga.md +++ b/releases/release-2.1-ga.md @@ -15,9 +15,9 @@ summary: TiDB 2.1 GA は 2018年 11月 30日にリリースされ、安定性、 - `Index Join`の外部テーブルの選択を最適化し、行数の推定値がより小さいテーブルを外部テーブルとして使用します。 - - 適切なインデックスがなくてもマージ結合を使用できるように結合ヒント`TIDB_SMJ`最適化します。 + - 適切なインデックスがなくてもマージ結合を使用できるように結合ヒント`TIDB_SMJ`を最適化します。 - - 結合ヒント`TIDB_INLJ`最適化して、結合する内部テーブルを指定します。 + - 結合ヒント`TIDB_INLJ`を最適化して、結合する内部テーブルを指定します。 - 相関サブクエリを最適化し、フィルタをプッシュダウン、インデックスの選択範囲を拡張することで、一部のクエリの効率が桁違いに向上します。 @@ -145,7 +145,7 @@ summary: TiDB 2.1 GA は 2018年 11月 30日にリリースされ、安定性、 - ネットワーク分離後にネットワークが回復したときにリーダーの再選出を回避するためにPDノード間で[`Raft PreVote`を有効にする](https://github.com/pingcap/pd/blob/5c7b18cf3af91098f07cf46df0b59fbf8c7c5462/conf/config.toml#L22) - - スケジュール中にマシン障害によってデータが利用できなくなるリスクを軽減するために、デフォルトで`raft learner`有効にします。 + - スケジュール中にマシン障害によってデータが利用できなくなるリスクを軽減するために、デフォルトで`raft learner`を有効にします。 - TSO 割り当てはシステムクロックの逆戻りの影響を受けなくなりました。 diff --git a/releases/release-2.1-rc.1.md b/releases/release-2.1-rc.1.md index 124d4e44055e5..75f129a2bce10 100644 --- a/releases/release-2.1-rc.1.md +++ b/releases/release-2.1-rc.1.md @@ -140,7 +140,7 @@ summary: TiDB 2.1 RC1は2018年8月24日にリリースされ、安定性、SQL - 改善点 - 多数の関数関数にプッシュダウンのサポートを追加し、文字セットのサポートを改善しました。 - GCワークフローを最適化し、GC速度を向上させ、GCがシステムに与える影響を軽減します。 - - `prevote`有効にすると、ネットワークが異常な場合のサービス回復が高速化されます + - `prevote`を有効にすると、ネットワークが異常な場合のサービス回復が高速化されます - RocksDBログファイルの関連設定項目を追加します - `scheduler_latch`のデフォルト設定を調整する - tikv-ctl を使用して手動でデータを圧縮するときに、RocksDB の最下層のデータを圧縮するかどうかの設定をサポートします。 diff --git a/releases/release-2.1-rc.2.md b/releases/release-2.1-rc.2.md index 2b8584af1c6c8..06e5232b2b8b6 100644 --- a/releases/release-2.1-rc.2.md +++ b/releases/release-2.1-rc.2.md @@ -49,7 +49,7 @@ summary: TiDB 2.1 RC2は2018年9月14日にリリースされ、安定性、SQL - TiDBクラスタを起動するときにグローバルシステムのタイムゾーンを設定する [＃7638](https://github.com/pingcap/tidb/pull/7638) - 互換性 - `Year`型に符号なしフラグを追加 [＃7542](https://github.com/pingcap/tidb/pull/7542) - - `Prepare`モードで`Year`型の結果の長さ`Execute`設定する問題を修正 [＃7525](https://github.com/pingcap/tidb/pull/7525) + - `Prepare` / `Execute`モードで`Year`型の結果の長さを設定する問題を修正 [＃7525](https://github.com/pingcap/tidb/pull/7525) - `Prepare`モードで`Execute`タイムスタンプを挿入する問題を修正[＃7506](https://github.com/pingcap/tidb/pull/7506) - 整数除算のエラー処理の問題を修正 [＃7492](https://github.com/pingcap/tidb/pull/7492) - `ComStmtSendLongData` 処理時の互換性の問題を修正 [＃7485](https://github.com/pingcap/tidb/pull/7485) diff --git a/releases/release-2.1.11.md b/releases/release-2.1.11.md index 5a052b5c08a18..075988cd1d28a 100644 --- a/releases/release-2.1.11.md +++ b/releases/release-2.1.11.md @@ -18,7 +18,7 @@ TiDB Ansible バージョン: 2.1.11 - バケット数を更新するときに重複していないフィードバックをマージする [＃10569](https://github.com/pingcap/tidb/pull/10569) - `unix_timestamp()-unix_timestamp(now())` の計算エラーを修正 [＃10491](https://github.com/pingcap/tidb/pull/10491) - MySQL 8.0 との`period_diff`互換性の問題を修正 [＃10501](https://github.com/pingcap/tidb/pull/10501) -- 例外を回避するために統計を収集するときに`Virtual Column`スキップする[＃10628](https://github.com/pingcap/tidb/pull/10628) +- 例外を回避するために統計を収集するときに`Virtual Column`をスキップする[＃10628](https://github.com/pingcap/tidb/pull/10628) - `SHOW OPEN TABLES`ステートメントサポートする [＃10374](https://github.com/pingcap/tidb/pull/10374) - 場合によっては goroutine リークが発生する可能性がある問題を修正[＃10656](https://github.com/pingcap/tidb/pull/10656) - `tidb_snapshot`変数を設定すると、場合によっては時間形式の解析が正しく行われない可能性がある問題を修正しました。 [＃10637](https://github.com/pingcap/tidb/pull/10637) diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index bc9a493365437..c24632f99713c 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -34,7 +34,7 @@ TiDB Ansible バージョン: 3.0.0 - `NOT EXISTS`サブクエリを最適化し、 `Anti Semi Join`に変換してパフォーマンスを向上させます - `Outer Join`の定数伝播を最適化し、 `Outer Join`除去の最適化ルールを追加して、効果のない計算を減らし、パフォーマンスを向上させます。 - パフォーマンスを向上させるために、集計後に`Inner Join`を実行するように`IN`サブクエリを最適化します。 - - `Index Join`最適化してより多くのシナリオに適応する + - `Index Join`を最適化してより多くのシナリオに適応する - レンジパーティションのパーティションプルーニング最適化ルールの改善 - `_tidb_rowid`のクエリロジックを最適化して、テーブル全体のスキャンを回避し、パフォーマンスを向上させます。 - 複合インデックスのアクセス条件を抽出する際に、フィルタ内に関連する列がある場合に、インデックスのプレフィックス列をさらに一致させてパフォーマンスを向上します。 @@ -46,7 +46,7 @@ TiDB Ansible バージョン: 3.0.0 - 統計収集のパフォーマンスを向上させるために、単調に増加するインデックス列に対する増分分析操作をサポートします。 - `DO`文でサブクエリの使用をサポート - トランザクションで`Index Join`使用をサポート - - パラメータのないDDL文をサポートするために`prepare` `execute`最適化します + - パラメータのないDDL文をサポートするために`prepare` `execute`を最適化します - `stats-lease`変数値が0の場合に統計を自動的にロードするようにシステムの動作を変更します - 履歴統計のエクスポートをサポート - ヒストグラムの`dump`相関`load`サポート diff --git a/releases/release-3.0.16.md b/releases/release-3.0.16.md index 4622d1ac82094..100537e4f01ba 100644 --- a/releases/release-3.0.16.md +++ b/releases/release-3.0.16.md @@ -20,7 +20,7 @@ TiDB バージョン: 3.0.16 - 将来の Go バージョンとの互換性を保つために、 `json.Unmarshal` in `job.DecodeArgs`の使用法を修正します。 [＃17887](https://github.com/pingcap/tidb/pull/17887) - スロークエリログとステートメントサマリーテーブルから機密情報を削除します [＃18128](https://github.com/pingcap/tidb/pull/18128) - MySQLの動作を`DateTime`区切り文字に一致させる [＃17499](https://github.com/pingcap/tidb/pull/17499) - - MySQL と一致する範囲の日付形式で`%h`処理します [＃17496](https://github.com/pingcap/tidb/pull/17496) + - MySQL と一致する範囲の日付形式で`%h`を処理します [＃17496](https://github.com/pingcap/tidb/pull/17496) - TiKV diff --git a/releases/release-3.0.19.md b/releases/release-3.0.19.md index 84a7107db0f93..b5b8272646a23 100644 --- a/releases/release-3.0.19.md +++ b/releases/release-3.0.19.md @@ -38,7 +38,7 @@ TiDBバージョン: 3.0.19 - `slow-log`ファイルが存在しない場合に発生するクエリエラーを修正[＃20050](https://github.com/pingcap/tidb/pull/20050) - `SHOW STATS_META`と`SHOW STATS_BUCKET`の権限チェックを追加する[＃19759](https://github.com/pingcap/tidb/pull/19759) - 小数型を整数型に変更することを禁止する[＃19681](https://github.com/pingcap/tidb/pull/19681) - - `ENUM`型列[＃20045](https://github.com/pingcap/tidb/pull/20045) `SET`変更する際に制約がチェックされない問題を修正 + - `ENUM` / `SET`型列を変更する際に制約がチェックされない問題を修正 [＃20045](https://github.com/pingcap/tidb/pull/20045) - panic後にtidb-serverがテーブルロックを解放しないバグを修正[＃20021](https://github.com/pingcap/tidb/pull/20021) - `WHERE`句で`OR`演算子が正しく処理されないバグを修正 [＃19901](https://github.com/pingcap/tidb/pull/19901) diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index 236e784f5e074..bc95b9f2089b4 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -54,7 +54,7 @@ TiDB Ansible バージョン: 3.0.2 - SQL 文で現在時刻を計算し、その値が複数回取得された場合に結果が MySQL と互換性がない問題を修正しました。同じ SQL 文で現在時刻を取得する場合は同じ値を使用します[＃11394](https://github.com/pingcap/tidb/pull/11394) - `baseExecutor`の`Close`エラーを報告しているにもかかわらず、 `ChildExecutor`に対して`Close`が呼び出されない問題を修正しました。この問題は、 `KILL`文が実行されず、 `ChildExecutor`が閉じられていない場合にGoroutineリークを引き起こす可能性があります[＃11576](https://github.com/pingcap/tidb/pull/11576) - サーバ - - CSVファイル内の欠落しているフィールド`LOAD DATA` `TIMESTAMP`処理する際に、自動的に追加された値が現在のタイムスタンプではなく0になる問題を修正しました。 [＃11250](https://github.com/pingcap/tidb/pull/11250) + - CSVファイル内で欠落している`TIMESTAMP`フィールドを`LOAD DATA`が処理する際に、自動的に追加された値が現在のタイムスタンプではなく0になる問題を修正しました。 [＃11250](https://github.com/pingcap/tidb/pull/11250) - `SHOW CREATE USER`文が関連する権限を正しくチェックせず、 `SHOW CREATE USER CURRENT_USER()`によって返される`USER`と`HOST`間違っている可能性がある問題を修正しました[＃11229](https://github.com/pingcap/tidb/pull/11229) - JDBC で`executeBatch`を使用すると返される結果が間違っている可能性がある問題を修正しました [＃11290](https://github.com/pingcap/tidb/pull/11290) - TiKVサーバーのポートを変更するときにストリーミングクライアントのログ情報の出力を削減します [＃11370](https://github.com/pingcap/tidb/pull/11370) diff --git a/releases/release-3.0.9.md b/releases/release-3.0.9.md index 9f1c2d38d726d..06b0055a8ad44 100644 --- a/releases/release-3.0.9.md +++ b/releases/release-3.0.9.md @@ -37,7 +37,7 @@ TiDB Ansible バージョン: 3.0.9 - Raftstore - 構成変更を高速化して、リージョン分散高速化します。 [＃6421](https://github.com/tikv/tikv/pull/6421) - トランザクション - - `tikv_lock_manager_waiter_lifetime_duration` `tikv_lock_manager_detect_duration`監視メトリックを追加して、 `waiter`の寿命、デッドロックの検出にかかる時間コスト、および`Wait`表の状態`tikv_lock_manager_detect_duration`監視します。 [＃6392](https://github.com/tikv/tikv/pull/6392) + - `tikv_lock_manager_waiter_lifetime_duration` `tikv_lock_manager_detect_duration`監視メトリックを追加して、 `waiter`の寿命、デッドロックの検出にかかる時間コスト、および`Wait`表の状態`tikv_lock_manager_detect_duration`を監視します。 [＃6392](https://github.com/tikv/tikv/pull/6392) - 極端な状況でリージョンリーダーまたはデッドロック検出器のリーダーを変更することによって発生するトランザクション実行のレイテンシーを削減するために、次の構成項目を最適化します[＃6429](https://github.com/tikv/tikv/pull/6429) - デフォルト値の`wait-for-lock-time`を`3s`から`1s`に変更します - デフォルト値の`wake-up-delay-duration`を`100ms`から`20ms`に変更します diff --git a/releases/release-4.0-ga.md b/releases/release-4.0-ga.md index 737be305a80c5..7dbeffa11852e 100644 --- a/releases/release-4.0-ga.md +++ b/releases/release-4.0-ga.md @@ -86,7 +86,7 @@ TiDB バージョン: 4.0.0 - TiFlash - 検索ログ機能における正規表現のマッチング動作が他のコンポーネントと一致しない問題を修正しました - - デフォルトで遅延処理の最適化`Raft Compact Log Command`無効にすることで、ノードが大量のデータを書き込むときに過剰な再起動時間がかかる問題を修正しました。 + - デフォルトで遅延処理の最適化`Raft Compact Log Command`を無効にすることで、ノードが大量のデータを書き込むときに過剰な再起動時間がかかる問題を修正しました。 - 一部のシナリオで TiDB が`DROP DATABASE`ステートメントを誤って処理するため、システムの起動に失敗する問題を修正しました。 - `Server_info`の CPU 情報を収集する方法が他のコンポーネントと異なる問題を修正しました - `batch coprocessor`が有効な場合に`Query`文を実行するとエラー`Too Many Pings`が報告される問題を修正しました diff --git a/releases/release-4.0.0-rc.md b/releases/release-4.0.0-rc.md index 92e5f21540a94..0ea1dff28d488 100644 --- a/releases/release-4.0.0-rc.md +++ b/releases/release-4.0.0-rc.md @@ -46,7 +46,7 @@ TiUPバージョン: 0.0.3 - TiDB - - 大文字と小文字を区別しない照合順序を追加して、ユーザーが新しいクラスターで`utf8mb4_general_ci`と`utf8_general_ci`有効にできるようにします。 [＃33](https://github.com/pingcap/tidb/projects/33) + - 大文字と小文字を区別しない照合順序を追加して、ユーザーが新しいクラスターで`utf8mb4_general_ci`と`utf8_general_ci`を有効にできるようにします。 [＃33](https://github.com/pingcap/tidb/projects/33) - 切り捨てられたテーブル回復をサポートするために`RECOVER TABLE`構文を拡張します [＃15398](https://github.com/pingcap/tidb/pull/15398) - tidb-server ステータスポートが使用中の場合、アラートログを返す代わりに開始を拒否します[＃15177](https://github.com/pingcap/tidb/pull/15177) - デフォルトの列値としてシーケンスを使用する書き込みパフォーマンスを最適化する[＃15216](https://github.com/pingcap/tidb/pull/15216) diff --git a/releases/release-4.0.11.md b/releases/release-4.0.11.md index c31ee8e26ce06..c3e5fd8ee1785 100644 --- a/releases/release-4.0.11.md +++ b/releases/release-4.0.11.md @@ -149,7 +149,7 @@ TiDB バージョン: 4.0.11 - `ErrTaskStatusNotExists`と`capture`セッションの終了が同時に発生した場合、TiCDCサービスが予期せず終了する可能性があるバグを修正[＃1240](https://github.com/pingcap/tiflow/pull/1240) - `changefeed`が別の`changefeed` の影響を受ける可能性があるという古い値の切り替え問題を修正しました [＃1347](https://github.com/pingcap/tiflow/pull/1347) - - 無効な`sort-engine`パラメータを持つ新しい`changefeed`処理するときにTiCDCサービスがハングする可能性があるバグを修正しました [＃1309](https://github.com/pingcap/tiflow/pull/1309) + - 無効な`sort-engine`パラメータを持つ新しい`changefeed`を処理するときにTiCDCサービスがハングする可能性があるバグを修正しました [＃1309](https://github.com/pingcap/tiflow/pull/1309) - 非オーナーノードでデバッグ情報を取得する際に発生するpanicの問題を修正[＃1349](https://github.com/pingcap/tiflow/pull/1349) - テーブルを追加または削除したときに、 `ticdc_processor_num_of_tables`と`ticdc_processor_table_resolved_ts`メトリックが正しく更新されない問題を修正しました。 [＃1351](https://github.com/pingcap/tiflow/pull/1351) - テーブルを追加するときにプロセッサがクラッシュした場合に潜在的なデータ損失が発生する問題を修正しました [＃1363](https://github.com/pingcap/tiflow/pull/1363) diff --git a/releases/release-4.0.13.md b/releases/release-4.0.13.md index 7e42400f3a512..29bdd36f97676 100644 --- a/releases/release-4.0.13.md +++ b/releases/release-4.0.13.md @@ -82,7 +82,7 @@ TiDB バージョン: 4.0.13 - `USE_INDEX_MERGE`ヒントが効かない問題を修正[＃22924](https://github.com/pingcap/tidb/pull/22924) - `WHERE`句で`ENUM`列または`SET`列をフィルターとして使用すると、クエリが間違った結果を返すバグを修正しました[＃22814](https://github.com/pingcap/tidb/pull/22814) - クラスター化インデックスと新しい照合順序を同時に使用するとクエリが間違った結果を返すバグを修正[＃21408](https://github.com/pingcap/tidb/pull/21408) - - `enable_new_collation`有効にした状態で`ANALYZE`を実行した際に発生するpanicを修正[＃21299](https://github.com/pingcap/tidb/pull/21299) + - `enable_new_collation`を有効にした状態で`ANALYZE`を実行した際に発生するpanicを修正[＃21299](https://github.com/pingcap/tidb/pull/21299) - SQLビューがSQL DEFINER に関連付けられたデフォルトのロールを正しく処理しない問題を修正しました。 [＃24531](https://github.com/pingcap/tidb/pull/24531) - DDLジョブのキャンセルがスタックする問題を修正[＃24445](https://github.com/pingcap/tidb/pull/24445) - `concat`関数が照合順序誤って処理する問題を修正しました [＃24300](https://github.com/pingcap/tidb/pull/24300) diff --git a/releases/release-4.0.3.md b/releases/release-4.0.3.md index da3b76e3f8585..89606b6f9d233 100644 --- a/releases/release-4.0.3.md +++ b/releases/release-4.0.3.md @@ -46,7 +46,7 @@ TiDB バージョン: 4.0.3 - TiDB - SQLクエリをログに記録するときに感度を下げるかどうかを制御する`tidb_log_desensitization`グローバル変数を追加します[＃18581](https://github.com/pingcap/tidb/pull/18581) - - デフォルトで`tidb_allow_batch_cop`有効にする[＃18552](https://github.com/pingcap/tidb/pull/18552) + - デフォルトで`tidb_allow_batch_cop`を有効にする[＃18552](https://github.com/pingcap/tidb/pull/18552) - クエリのキャンセルを高速化[＃18505](https://github.com/pingcap/tidb/pull/18505) - `tidb_decode_plan`の結果にヘッダーを追加 [＃18501](https://github.com/pingcap/tidb/pull/18501) - 構成チェッカーを以前のバージョンの構成ファイルと互換性のあるものにする [＃18046](https://github.com/pingcap/tidb/pull/18046) diff --git a/releases/release-4.0.6.md b/releases/release-4.0.6.md index 839f60014e975..851a5c45eb169 100644 --- a/releases/release-4.0.6.md +++ b/releases/release-4.0.6.md @@ -40,7 +40,7 @@ TiDB バージョン: 4.0.6 - プロセスリストのSQLダイジェストを追加する [＃19829](https://github.com/pingcap/tidb/pull/19829) - 自動コミット文の再試行ために悲観的トランザクションモードに切り替える [＃19796](https://github.com/pingcap/tidb/pull/19796) - `Str_to_date()` の`%r`と`%T`データ形式をサポート [＃19693](https://github.com/pingcap/tidb/pull/19693) - - `SELECT INTO OUTFILE`有効にするとファイル権限必要になります [＃19577](https://github.com/pingcap/tidb/pull/19577) + - `SELECT INTO OUTFILE`を有効にするとファイル権限が必要になります [＃19577](https://github.com/pingcap/tidb/pull/19577) - `stddev_pop`機能サポートする [＃19541](https://github.com/pingcap/tidb/pull/19541) - `TiDB-Runtime`ダッシュボードを追加する [＃19396](https://github.com/pingcap/tidb/pull/19396) - `ALTER TABLE`アルゴリズム互換性を向上 [＃19364](https://github.com/pingcap/tidb/pull/19364) diff --git a/releases/release-4.0.8.md b/releases/release-4.0.8.md index b92a1f6adcc1a..2e3dbf688d19e 100644 --- a/releases/release-4.0.8.md +++ b/releases/release-4.0.8.md @@ -35,7 +35,7 @@ TiDB バージョン: 4.0.8 - SQL オプティマイザが潜在的な新しいプランを検証しているときに、より多くのデバッグ情報を記録するために、プランバインディング ステージ中にタイムアウト実行計画を待機します[＃20530](https://github.com/pingcap/tidb/pull/20530) - スローログに実行再試行時間を追加し、スロークエリの結果[＃20495](https://github.com/pingcap/tidb/pull/20495) [＃20494](https://github.com/pingcap/tidb/pull/20494) - `table_storage_stats`システムテーブルを追加する [＃20431](https://github.com/pingcap/tidb/pull/20431) - - `INSERT` `REPLACE`のRPC実行時統計情報`UPDATE`追加する[＃20430](https://github.com/pingcap/tidb/pull/20430) + - `INSERT` / `UPDATE` / `REPLACE`文のRPC実行時統計情報を追加する[＃20430](https://github.com/pingcap/tidb/pull/20430) - `EXPLAIN FOR CONNECTION` の結果に演算子情報を追加します [＃20384](https://github.com/pingcap/tidb/pull/20384) - クライアントの接続/切断アクティビティのTiDBエラーログを`DEBUG`レベルに調整します。 [＃20321](https://github.com/pingcap/tidb/pull/20321) - コプロセッサーキャッシュの監視メトリックを追加します。 [＃20293](https://github.com/pingcap/tidb/pull/20293) diff --git a/releases/release-4.0.9.md b/releases/release-4.0.9.md index 4a1631bc7db48..445b8d8feeece 100644 --- a/releases/release-4.0.9.md +++ b/releases/release-4.0.9.md @@ -62,7 +62,7 @@ TiDB バージョン: 4.0.9 - パイプライン化された悲観的ロックの成功率を向上させる[＃9086](https://github.com/tikv/tikv/pull/9086) - デフォルト値の`apply-max-batch-size`と`store-max-batch-size`を`1024` に変更します [＃9020](https://github.com/tikv/tikv/pull/9020) - `max-background-flushes`構成項目追加する [＃8947](https://github.com/tikv/tikv/pull/8947) - - パフォーマンスを向上させるためにデフォルトで`force-consistency-checks`無効にする[＃9029](https://github.com/tikv/tikv/pull/9029) + - パフォーマンスを向上させるためにデフォルトで`force-consistency-checks`を無効にする[＃9029](https://github.com/tikv/tikv/pull/9029) - リージョンサイズを`pd heartbeat worker`から`split check worker` にオフロードする [＃9185](https://github.com/tikv/tikv/pull/9185) - PD @@ -172,7 +172,7 @@ TiDB バージョン: 4.0.9 - リーダーが転送された後にFollower Readが古いデータを返す可能性があるバグを修正[＃9240](https://github.com/tikv/tikv/pull/9240) - 悲観的ロックで古い値が読み取られる可能性がある問題を修正 [＃9282](https://github.com/tikv/tikv/pull/9282) - リーダー転送後にレプリカ読み取りで古いデータが取得される可能性があるバグを修正[＃9240](https://github.com/tikv/tikv/pull/9240) - - プロファイリング後に`SIGPROF`受信すると発生するTiKVクラッシュの問題を修正 [＃9229](https://github.com/tikv/tikv/pull/9229) + - プロファイリング後に`SIGPROF`を受信すると発生するTiKVクラッシュの問題を修正 [＃9229](https://github.com/tikv/tikv/pull/9229) - PD diff --git a/releases/release-5.0.0-rc.md b/releases/release-5.0.0-rc.md index 027cda150042e..82cc27a67e0b0 100644 --- a/releases/release-5.0.0-rc.md +++ b/releases/release-5.0.0-rc.md @@ -101,7 +101,7 @@ TiDB では、ID 情報やクレジットカード番号などの機密情報の ただし、非同期コミットが有効になっている場合、トランザクションの外部一貫性は`tidb_guarantee_external_consistency = ON`設定されている場合**のみ**保証されます。非同期コミットを有効にすると、パフォーマンスが低下する可能性があります。 -ユーザーは、グローバル変数`tidb_enable_async_commit = ON`設定することでこの機能を有効にできます。 +ユーザーは、グローバル変数`tidb_enable_async_commit = ON`を設定することでこの機能を有効にできます。 - [ユーザードキュメント](/system-variables.md#tidb_enable_async_commit-new-in-v50) - 関連号: [＃8316](https://github.com/tikv/tikv/issues/8316) diff --git a/releases/release-5.0.2.md b/releases/release-5.0.2.md index 6b8cb0fe4dfed..b97aafb1c698c 100644 --- a/releases/release-5.0.2.md +++ b/releases/release-5.0.2.md @@ -15,7 +15,7 @@ TiDB バージョン: 5.0.2 - TiCDC - - `cdc cli changefeed`コマンドの`--sort-dir`非推奨です。代わりに、 `cdc server`コマンドの`--sort-dir`設定できます[＃1795](https://github.com/pingcap/tiflow/pull/1795) + - `cdc cli changefeed`コマンドの`--sort-dir`非推奨です。代わりに、 `cdc server`コマンドの`--sort-dir`を設定できます[＃1795](https://github.com/pingcap/tiflow/pull/1795) ## 新機能 {#new-features} diff --git a/releases/release-5.3.0.md b/releases/release-5.3.0.md index 3a6b2526f2665..f5499aaba94d7 100644 --- a/releases/release-5.3.0.md +++ b/releases/release-5.3.0.md @@ -32,7 +32,7 @@ v5.3 の主な新機能または改善点は次のとおりです。 | 変数名 | タイプを変更 | 説明 | | :---------------------------------------------------------------------------------------------------------------- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40) | 変更 | 一時テーブルが TiDB でサポートされるようになったため、 `CREATE TEMPORARY TABLE`と`DROP TEMPORARY TABLE` `tidb_enable_noop_functions`有効にする必要がなくなりました。 | +| [`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40) | 変更 | 一時テーブルが TiDB でサポートされるようになったため、 `CREATE TEMPORARY TABLE`と`DROP TEMPORARY TABLE` `tidb_enable_noop_functions`を有効にする必要がなくなりました。 | | [`tidb_enable_pseudo_for_outdated_stats`](/system-variables.md#tidb_enable_pseudo_for_outdated_stats-new-in-v530) | 新しく追加された | テーブルの統計情報が期限切れになった場合のオプティマイザの動作を制御します。デフォルト値は`ON`です。テーブル内の変更された行数が総行数の80%を超える場合（この比率は設定[`pseudo-estimate-ratio`](/tidb-configuration-file.md#pseudo-estimate-ratio)で調整できます）、オプティマイザは総行数以外の統計情報は信頼できないと判断し、代わりに疑似統計情報を使用します。値を`OFF`に設定すると、統計情報が期限切れになってもオプティマイザは引き続きそれらを使用します。 | | [`tidb_enable_tso_follower_proxy`](/system-variables.md#tidb_enable_tso_follower_proxy-new-in-v530) | 新しく追加された | TSOFollowerプロキシ機能を有効または無効にします。デフォルト値は`OFF`で、これはTSOFollowerプロキシ機能が無効であることを意味します。この場合、TiDBはPDリーダーからのみTSOを取得します。この機能を有効にすると、TiDBはTSOを取得する際にすべてのPDノードに均等にリクエストを送信します。PDフォロワーはTSOリクエストを転送することで、PDリーダーのCPU負荷を軽減します。 | | [`tidb_tso_client_batch_max_wait_time`](/system-variables.md#tidb_tso_client_batch_max_wait_time-new-in-v530) | 新しく追加された | TiDBがPDにTSOを要求した際に、バッチ保存操作の最大待機時間を設定します。デフォルト値は`0`で、追加の待機時間はありません。 | diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md index 05b019cce2a41..67d07438b171b 100644 --- a/releases/release-6.1.0.md +++ b/releases/release-6.1.0.md @@ -61,7 +61,7 @@ TiDB バージョン: 6.1.0 - カスタマイズされたリージョンサイズをサポート - v6.1.0以降では、 [`coprocessor.region-split-size`](/tikv-configuration-file.md#region-split-size)設定することでリージョンのサイズを大きく設定できます。これにより、リージョンの数を効果的に削減し、リージョンの管理を容易にし、クラスターのパフォーマンスと安定性を向上させることができます。 + v6.1.0以降では、 [`coprocessor.region-split-size`](/tikv-configuration-file.md#region-split-size)を設定することでリージョンのサイズを大きく設定できます。これにより、リージョンの数を効果的に削減し、リージョンの管理を容易にし、クラスターのパフォーマンスと安定性を向上させることができます。 [ユーザードキュメント](/tune-region-performance.md#use-region-split-size-to-adjust-region-size) [＃11515](https://github.com/tikv/tikv/issues/11515) diff --git a/releases/release-6.1.7.md b/releases/release-6.1.7.md index 414e72ba4d58b..b19eec07cf229 100644 --- a/releases/release-6.1.7.md +++ b/releases/release-6.1.7.md @@ -51,7 +51,7 @@ TiDB バージョン: 6.1.7 - `ON UPDATE`文が主キーを正しく更新しない場合にデータとインデックスが不整合になる問題を修正しました [＃44565](https://github.com/pingcap/tidb/issues/44565) @[zyguan](https://github.com/zyguan) - テーブル名の変更中に TiCDC が行の変更の一部を失う可能性がある問題を修正[＃43338](https://github.com/pingcap/tidb/issues/43338) @[tangenta](https://github.com/tangenta) - パーティション化されたテーブルにおける配置ルールの動作の問題を修正し、削除されたパーティションにおける配置ルールが正しく設定され、再利用されるようになりました[＃44116](https://github.com/pingcap/tidb/issues/44116) @[lcwangchao](https://github.com/lcwangchao) - - `tidb_scatter_region`有効にすると、パーティションが切り捨てられた後にリージョンが自動的に分割されない問題を修正しました[＃43174](https://github.com/pingcap/tidb/issues/43174) [＃43028](https://github.com/pingcap/tidb/issues/43028) + - `tidb_scatter_region`を有効にすると、パーティションが切り捨てられた後にリージョンが自動的に分割されない問題を修正しました[＃43174](https://github.com/pingcap/tidb/issues/43174) [＃43028](https://github.com/pingcap/tidb/issues/43028) - 多数のパーティションとTiFlashレプリカを持つパーティションテーブルに対して`TRUNCATE TABLE`を実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。 [＃42940](https://github.com/pingcap/tidb/issues/42940) @[mjonss](https://github.com/mjonss) - ウィンドウ関数をTiFlash にプッシュダウンする際の実行計画が正しくない問題を修正しました [＃43922](https://github.com/pingcap/tidb/issues/43922) @[gengliqi](https://github.com/gengliqi) - 非相関サブクエリを含むステートメントで共通テーブル式 (CTE) を使用すると誤った結果が返される可能性がある問題を修正しました [＃44051](https://github.com/pingcap/tidb/issues/44051) @[winoros](https://github.com/winoros) diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 9e7068a7e2b60..8ba281ccb54f4 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -185,7 +185,7 @@ TiDBバージョン: 6.3.0-DMR ### データ移行 {#data-migration} -- TiDB Lightning は[Apache HiveによってエクスポートされたParquetファイルをTiDBにインポートする](/tidb-lightning/tidb-lightning-data-source.md#parquet)インポートする [#37536](https://github.com/pingcap/tidb/issues/37536) @[buchuitoudegou](https://github.com/buchuitoudegou) +- TiDB Lightning は[Apache HiveによってエクスポートされたParquetファイルをTiDBにインポートする](/tidb-lightning/tidb-lightning-data-source.md#parquet)ことをサポートしています [#37536](https://github.com/pingcap/tidb/issues/37536) @[buchuitoudegou](https://github.com/buchuitoudegou) - DM に新しい設定項目`safe-mode-duration`が追加されました [#6224](https://github.com/pingcap/tiflow/issues/6224) @[okJiang](https://github.com/okJiang) diff --git a/releases/release-6.5.1.md b/releases/release-6.5.1.md index b2d7bc933e350..6aeedd1e7e096 100644 --- a/releases/release-6.5.1.md +++ b/releases/release-6.5.1.md @@ -98,7 +98,7 @@ TiDB バージョン: 6.5.1 - `ANALYZE`文が`KILL` で終了する可能性がある問題を修正しました [＃41825](https://github.com/pingcap/tidb/issues/41825) @[XuHuaiyu](https://github.com/XuHuaiyu) - `indexMerge` で goroutine リークが発生する可能性がある問題を修正しました [＃41605](https://github.com/pingcap/tidb/issues/41605) @[guo-shaoge](https://github.com/guo-shaoge) [＃41545](https://github.com/pingcap/tidb/issues/41545) - 符号なしの`TINYINT` / `SMALLINT` / `INT`値を`0` より小さい`DECIMAL` / `FLOAT` / `DOUBLE`値と比較するときに誤った結果になる可能性がある問題を修正しました。 [＃41736](https://github.com/pingcap/tidb/issues/41736) @[LittleFall](https://github.com/LittleFall) - - `tidb_enable_reuse_chunk`有効にするとメモリリークが発生する可能性がある問題を修正 [＃40987](https://github.com/pingcap/tidb/issues/40987) @[guo-shaoge](https://github.com/guo-shaoge) + - `tidb_enable_reuse_chunk`を有効にするとメモリリークが発生する可能性がある問題を修正 [＃40987](https://github.com/pingcap/tidb/issues/40987) @[guo-shaoge](https://github.com/guo-shaoge) - タイムゾーンでのデータ競合によりデータインデックスの不整合が発生する可能性がある問題を修正[＃40710](https://github.com/pingcap/tidb/issues/40710) @[wjhuang2016](https://github.com/wjhuang2016) - `batch cop`実行中のスキャン詳細情報が不正確になる可能性がある問題を修正[＃41582](https://github.com/pingcap/tidb/issues/41582) @[you06](https://github.com/you06) - `cop`の上限同時実行数が制限されない問題を修正 [＃41134](https://github.com/pingcap/tidb/issues/41134) @[you06](https://github.com/you06) diff --git a/releases/release-6.5.4.md b/releases/release-6.5.4.md index be179e46e1954..dce6477a35a1c 100644 --- a/releases/release-6.5.4.md +++ b/releases/release-6.5.4.md @@ -190,7 +190,7 @@ TiDB バージョン: 6.5.4 - `checksum = "optional"` のときにチェックサムがエラーを報告する問題を修正しました [＃45382](https://github.com/pingcap/tidb/issues/45382) @[lyzx2001](https://github.com/lyzx2001) - PDクラスタアドレスが変更されるとデータのインポートが失敗する問題を修正しました [＃43436](https://github.com/pingcap/tidb/issues/43436) @[lichunzhu](https://github.com/lichunzhu) - 一部のPDノードが失敗した場合にデータのインポートが失敗する問題を修正しました [＃43400](https://github.com/pingcap/tidb/issues/43400) @[lichunzhu](https://github.com/lichunzhu) - - AUTO_INCREMENT列を持つテーブルが`AUTO_ID_CACHE=1`設定すると、ID アロケータのベース値が正しくなくなるという問題を修正しました [＃46100](https://github.com/pingcap/tidb/issues/46100) @[D3Hunter](https://github.com/D3Hunter) + - AUTO_INCREMENT列を持つテーブルが`AUTO_ID_CACHE=1`を設定すると、ID アロケータのベース値が正しくなくなるという問題を修正しました [＃46100](https://github.com/pingcap/tidb/issues/46100) @[D3Hunter](https://github.com/D3Hunter) - Dumpling diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index b41db21f858dc..72d09b6430980 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -17,7 +17,7 @@ TiDB バージョン: 6.5.6 - オプティマイザがテーブルに対してハッシュ結合を選択するかどうかを制御する[`tidb_opt_enable_hash_join`](https://docs.pingcap.com/tidb/v6.5/system-variables#tidb_opt_enable_hash_join-new-in-v656)システム変数を導入します。 [＃46695](https://github.com/pingcap/tidb/issues/46695) @[coderplay](https://github.com/coderplay) - さらなるテストの結果、 TiCDC Changefeed構成項目[`case-sensitive`](/ticdc/ticdc-changefeed-config.md)のデフォルト値が`true`から`false`に変更されました。これは、デフォルトでは TiCDC 構成ファイル内のテーブル名とデータベース名が大文字と小文字を区別しないことを意味します[＃10047](https://github.com/pingcap/tiflow/issues/10047) @[sdojjy](https://github.com/sdojjy) - TiCDC Changefeed、次の新しい構成項目が導入されています。 - - [`sql-mode`](/ticdc/ticdc-changefeed-config.md) : TiCDC がデータを複製するときに DDL ステートメントを解析するために使用する[SQLモード](https://docs.pingcap.com/tidb/v6.5/ticdc-ddl#sql-mode)設定できます[＃9876](https://github.com/pingcap/tiflow/issues/9876) @[asddongmen](https://github.com/asddongmen) + - [`sql-mode`](/ticdc/ticdc-changefeed-config.md) : TiCDC がデータを複製するときに DDL ステートメントを解析するために使用する[SQLモード](https://docs.pingcap.com/tidb/v6.5/ticdc-ddl#sql-mode)を設定できます[＃9876](https://github.com/pingcap/tiflow/issues/9876) @[asddongmen](https://github.com/asddongmen) - [`encoding-worker-num`](/ticdc/ticdc-changefeed-config.md)と[`flush-worker-num`](/ticdc/ticdc-changefeed-config.md) : 異なるマシンの仕様に基づいて、再実行モジュールに異なる同時実行パラメータを設定できます[＃10048](https://github.com/pingcap/tiflow/issues/10048) @[CharlesCheung96](https://github.com/CharlesCheung96) - [`compression`](/ticdc/ticdc-changefeed-config.md) : REDOログファイルの圧縮動作を設定できます[＃10176](https://github.com/pingcap/tiflow/issues/10176) @[sdojjy](https://github.com/sdojjy) - [`changefeed-error-stuck-duration`](/ticdc/ticdc-changefeed-config.md) : 内部エラーまたは例外が発生したときに、変更フィードが自動的に再試行される期間を設定できます[＃9875](https://github.com/pingcap/tiflow/issues/9875) @[asddongmen](https://github.com/asddongmen) @@ -50,7 +50,7 @@ TiDB バージョン: 6.5.6 - TiCDC - - `sink-uri`構成で`content-compatible=true`設定することにより、 TiCDC Canal-JSON コンテンツ フォーマット[公式Canal出力のコンテンツ形式と互換性がある](https://docs.pingcap.com/tidb/v6.5/ticdc-canal-json#compatibility-with-the-official-canal)作成をサポートします。 [＃10106](https://github.com/pingcap/tiflow/issues/10106) @[3AceShowHand](https://github.com/3AceShowHand) + - `sink-uri`構成で`content-compatible=true`を設定することにより、 TiCDC Canal-JSON コンテンツ フォーマット[公式Canal出力のコンテンツ形式と互換性がある](https://docs.pingcap.com/tidb/v6.5/ticdc-canal-json#compatibility-with-the-official-canal)作成をサポートします。 [＃10106](https://github.com/pingcap/tiflow/issues/10106) @[3AceShowHand](https://github.com/3AceShowHand) - `ADD INDEX` DDL操作を複製する実行ロジックを最適化して、後続のDMLステートメントをブロックしないようにします。 [＃9644](https://github.com/pingcap/tiflow/issues/9644) @[sdojjy](https://github.com/sdojjy) - TiCDC 増分スキャンによる上流 TiKV への影響を軽減 [＃11390](https://github.com/tikv/tikv/issues/11390) @[hicqu](https://github.com/hicqu) diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index 4a24396be239a..84bf323a245c2 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -234,7 +234,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 TiFlash をv7.1.0 にアップグレードした場合、TiDB を v7.1.0 にアップグレードする際に、TiDB はTiFlashシステムテーブル ( [`INFORMATION_SCHEMA.TIFLASH_TABLES`](/information-schema/information-schema-tiflash-tables.md)と[`INFORMATION_SCHEMA.TIFLASH_SEGMENTS`](/information-schema/information-schema-tiflash-segments.md) ) を読み取ることができません。 -- TiDB バージョン v6.2.0 から v7.0.0 のTiDB Lightning は、TiDB クラスターのバージョンに基づいてグローバルスケジューリングを一時停止するかどうかを決定します。TiDB クラスター バージョン >= v6.1.0 の場合、スケジュールはターゲットテーブルデータを格納するリージョンに対してのみ一時停止され、ターゲットテーブルのインポートが完了すると再開されます。その他のバージョンの場合、 TiDB Lightning はグローバルスケジューリングを一時停止します。TiDB v7.1.0 以降では、 [`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md)設定することで、グローバルスケジューリングを一時停止するかどうかを制御できます。デフォルトでは、 TiDB Lightning はターゲットテーブルデータを格納するリージョンのスケジュールを一時停止します。ターゲットクラスターのバージョンが v6.1.0 より前の場合、エラーが発生します。この場合、パラメータの値を`"global"`に変更して再試行できます。 +- TiDB バージョン v6.2.0 から v7.0.0 のTiDB Lightning は、TiDB クラスターのバージョンに基づいてグローバルスケジューリングを一時停止するかどうかを決定します。TiDB クラスター バージョン >= v6.1.0 の場合、スケジュールはターゲットテーブルデータを格納するリージョンに対してのみ一時停止され、ターゲットテーブルのインポートが完了すると再開されます。その他のバージョンの場合、 TiDB Lightning はグローバルスケジューリングを一時停止します。TiDB v7.1.0 以降では、 [`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md)を設定することで、グローバルスケジューリングを一時停止するかどうかを制御できます。デフォルトでは、 TiDB Lightning はターゲットテーブルデータを格納するリージョンのスケジュールを一時停止します。ターゲットクラスターのバージョンが v6.1.0 より前の場合、エラーが発生します。この場合、パラメータの値を`"global"`に変更して再試行できます。 - TiDB v7.1.0で[`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)を使用すると、FLASHBACK操作が完了した後も、一部のリージョンがFLASHBACKプロセスに残る可能性があります。v7.1.0ではこの機能の使用を避けることをお勧めします。詳細については、問題を参照してください。この問題が発生した場合は、機能[TiDBスナップショットのバックアップと復元](/br/br-snapshot-guide.md)を使用してデータを復元できます。 [＃44292](https://github.com/pingcap/tidb/issues/44292) @@ -382,7 +382,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - `Limit` を使用してパーティションテーブルをクエリしたときに返される誤った値を修正しました [＃24636](https://github.com/pingcap/tidb/issues/24636) - IPv6環境で誤ったTiDBアドレスが表示される問題を修正[＃43260](https://github.com/pingcap/tidb/issues/43260) @[nexustar](https://github.com/nexustar) - システム変数`tidb_enable_tiflash_read_for_write_stmt`と`tidb_enable_exchange_partition` に誤った値が表示される問題を修正しました [＃43281](https://github.com/pingcap/tidb/issues/43281) @[gengliqi](https://github.com/gengliqi) - - `tidb_scatter_region`有効にすると、パーティションが切り捨てられた後にリージョンが自動的に分割されない問題を修正しました[＃43174](https://github.com/pingcap/tidb/issues/43174) [＃43028](https://github.com/pingcap/tidb/issues/43028) @[jiyfhust](https://github.com/jiyfhust) + - `tidb_scatter_region`を有効にすると、パーティションが切り捨てられた後にリージョンが自動的に分割されない問題を修正しました[＃43174](https://github.com/pingcap/tidb/issues/43174) [＃43028](https://github.com/pingcap/tidb/issues/43028) @[jiyfhust](https://github.com/jiyfhust) - 生成列を持つテーブルにチェックを追加し、これらの列でサポートされていない DDL 操作のエラーを報告します[＃38988](https://github.com/pingcap/tidb/issues/38988) [＃24321](https://github.com/pingcap/tidb/issues/24321) @[tiancaiamao](https://github.com/tiancaiamao) - 特定の型変換エラーでエラーメッセージが正しく表示されない問題を修正 [＃41730](https://github.com/pingcap/tidb/issues/41730) @[hawkingrei](https://github.com/hawkingrei) - TiDBノードが正常にシャットダウンした後、このノードでトリガーされたDDLタスクがキャンセルされる問題を修正しました[＃43854](https://github.com/pingcap/tidb/issues/43854) @[zimulala](https://github.com/zimulala) @@ -408,8 +408,8 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - TiKV - - `tidb_pessimistic_txn_fair_locking`有効にすると、極端なケースで、失敗した RPC 再試行によって期限切れになったリクエストが、解決ロック操作中にデータの正確性に影響を与える可能性がある問題を修正しました。 [＃14551](https://github.com/tikv/tikv/issues/14551) @[MyonKeminta](https://github.com/MyonKeminta) - - `tidb_pessimistic_txn_fair_locking`有効にすると、極端なケースで、失敗した RPC 再試行によって期限切れのリクエストが発生し、トランザクションの競合が無視され、トランザクションの一貫性に影響する可能性がある問題を修正しました。 [＃14311](https://github.com/tikv/tikv/issues/14311) @[MyonKeminta](https://github.com/MyonKeminta) + - `tidb_pessimistic_txn_fair_locking`を有効にすると、極端なケースで、失敗した RPC 再試行によって期限切れになったリクエストが、解決ロック操作中にデータの正確性に影響を与える可能性がある問題を修正しました。 [＃14551](https://github.com/tikv/tikv/issues/14551) @[MyonKeminta](https://github.com/MyonKeminta) + - `tidb_pessimistic_txn_fair_locking`を有効にすると、極端なケースで、失敗した RPC 再試行によって期限切れのリクエストが発生し、トランザクションの競合が無視され、トランザクションの一貫性に影響する可能性がある問題を修正しました。 [＃14311](https://github.com/tikv/tikv/issues/14311) @[MyonKeminta](https://github.com/MyonKeminta) - 暗号化キーIDの競合により古いキーが削除される可能性がある問題を修正しました [＃14585](https://github.com/tikv/tikv/issues/14585) @[tabokie](https://github.com/tabokie) - クラスタを以前のバージョンから v6.5 以降のバージョンにアップグレードしたときに、累積したロック レコードによって発生するパフォーマンス低下の問題を修正しました。 [＃14780](https://github.com/tikv/tikv/issues/14780) @[MyonKeminta](https://github.com/MyonKeminta) - PITRリカバリプロセス中に`raft entry is too large`エラーが発生する問題を修正 [＃14313](https://github.com/tikv/tikv/issues/14313) @[YuJuncen](https://github.com/YuJuncen) diff --git a/releases/release-7.1.2.md b/releases/release-7.1.2.md index d9a0f901e9fc9..58386f0b9a3a7 100644 --- a/releases/release-7.1.2.md +++ b/releases/release-7.1.2.md @@ -179,7 +179,7 @@ TiDB バージョン: 7.1.2 - 異常な状態のレプリケーションタスクが上流のGC をブロックする問題を修正しました [＃9543](https://github.com/pingcap/tiflow/issues/9543) @[CharlesCheung96](https://github.com/CharlesCheung96) - オブジェクトストレージにデータを複製するとデータの不整合が発生する可能性がある問題を修正[＃9592](https://github.com/pingcap/tiflow/issues/9592) @[CharlesCheung96](https://github.com/CharlesCheung96) - - `redo-resolved-ts`有効にすると、changefeed が失敗する可能性がある問題を修正[＃9769](https://github.com/pingcap/tiflow/issues/9769) @[CharlesCheung96](https://github.com/CharlesCheung96) + - `redo-resolved-ts`を有効にすると、changefeed が失敗する可能性がある問題を修正[＃9769](https://github.com/pingcap/tiflow/issues/9769) @[CharlesCheung96](https://github.com/CharlesCheung96) - 間違ったメモリ情報を取得すると、一部のオペレーティングシステムで OOM 問題が発生する可能性がある問題を修正[＃9762](https://github.com/pingcap/tiflow/issues/9762) @[sdojjy](https://github.com/sdojjy) - `scale-out`が有効になっている場合のノード間の書き込みキーの不均等な配布の問題を修正[＃9665](https://github.com/pingcap/tiflow/issues/9665) @[sdojjy](https://github.com/sdojjy) - ログに機密ユーザー情報が記録される問題を修正 [＃9690](https://github.com/pingcap/tiflow/issues/9690) @[sdojjy](https://github.com/sdojjy) diff --git a/releases/release-7.1.3.md b/releases/release-7.1.3.md index 306c0661379e8..01c1db6657718 100644 --- a/releases/release-7.1.3.md +++ b/releases/release-7.1.3.md @@ -15,7 +15,7 @@ TiDB バージョン: 7.1.3 - さらなるテストの結果、 TiCDC Changefeed構成項目[`case-sensitive`](/ticdc/ticdc-changefeed-config.md)のデフォルト値が`true`から`false`に変更されました。これは、デフォルトでは TiCDC 構成ファイル内のテーブル名とデータベース名が大文字と小文字を区別しないことを意味します[＃10047](https://github.com/pingcap/tiflow/issues/10047) @[sdojjy](https://github.com/sdojjy) - TiCDC Changefeed、次の新しい構成項目が導入されています。 - - [`sql-mode`](/ticdc/ticdc-changefeed-config.md) : TiCDC がデータを複製するときに DDL ステートメントを解析するために使用する[SQLモード](https://docs.pingcap.com/tidb/v7.1/ticdc-ddl#sql-mode)設定できます[＃9876](https://github.com/pingcap/tiflow/issues/9876) @[asddongmen](https://github.com/asddongmen) + - [`sql-mode`](/ticdc/ticdc-changefeed-config.md) : TiCDC がデータを複製するときに DDL ステートメントを解析するために使用する[SQLモード](https://docs.pingcap.com/tidb/v7.1/ticdc-ddl#sql-mode)を設定できます[＃9876](https://github.com/pingcap/tiflow/issues/9876) @[asddongmen](https://github.com/asddongmen) - [`encoding-worker-num`](/ticdc/ticdc-changefeed-config.md)と[`flush-worker-num`](/ticdc/ticdc-changefeed-config.md) : 異なるマシンの仕様に基づいて、再実行モジュールに異なる同時実行パラメータを設定できます[＃10048](https://github.com/pingcap/tiflow/issues/10048) @[CharlesCheung96](https://github.com/CharlesCheung96) - [`compression`](/ticdc/ticdc-changefeed-config.md) : REDOログファイルの圧縮動作を設定できます[＃10176](https://github.com/pingcap/tiflow/issues/10176) @[sdojjy](https://github.com/sdojjy) - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージにデータを複製するときに履歴データの自動クリーンアップを設定できます[チャールズ・チュン96](https://github.com/CharlesCheung96) [＃10109](https://github.com/pingcap/tiflow/issues/10109) @@ -45,7 +45,7 @@ TiDB バージョン: 7.1.3 - S3へのデータの並列書き込みやlz4圧縮アルゴリズムの採用など、REDOログのパフォーマンスを最適化します[＃10176](https://github.com/pingcap/tiflow/issues/10176) [＃10226](https://github.com/pingcap/tiflow/issues/10226) @[sdojjy](https://github.com/sdojjy) - 並列度を増やすことで、TiCDC がオブジェクトストレージにデータを複製する際のパフォーマンスが向上します。 [＃10098](https://github.com/pingcap/tiflow/issues/10098) @[CharlesCheung96](https://github.com/CharlesCheung96) - TiCDC 増分スキャンによる上流 TiKV への影響を軽減 [＃11390](https://github.com/tikv/tikv/issues/11390) @[hicqu](https://github.com/hicqu) - - `sink-uri`構成で`content-compatible=true`設定することにより、 TiCDC Canal-JSON コンテンツ フォーマット[公式Canal出力のコンテンツ形式と互換性がある](https://docs.pingcap.com/tidb/v6.5/ticdc-canal-json#compatibility-with-the-official-canal)作成をサポートします。 [＃10106](https://github.com/pingcap/tiflow/issues/10106) @[3AceShowHand](https://github.com/3AceShowHand) + - `sink-uri`構成で`content-compatible=true`を設定することにより、 TiCDC Canal-JSON コンテンツ フォーマット[公式Canal出力のコンテンツ形式と互換性がある](https://docs.pingcap.com/tidb/v6.5/ticdc-canal-json#compatibility-with-the-official-canal)作成をサポートします。 [＃10106](https://github.com/pingcap/tiflow/issues/10106) @[3AceShowHand](https://github.com/3AceShowHand) - TiDB Lightning diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index 2c8ff30143943..76bbc21746dbf 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -188,7 +188,7 @@ TiDB バージョン: 7.4.0 SQL実行の問題をトラブルシューティングする際には、根本原因を特定するために、TiDBコンポーネントログの内容を相関させる必要があることがよくあります。v7.4.0以降、TiDBはセッション接続ID（ `CONNECTION_ID` ）をセッション関連ログ（TiDBログ、スロークエリログ、TiKVコプロセッサからのスローログなど）に書き込むことができます。セッション接続IDに基づいて複数の種類のログの内容を相関させることで、トラブルシューティングと診断の効率を向上させることができます。 - さらに、セッションレベルのシステム変数[`tidb_session_alias`](/system-variables.md#tidb_session_alias-new-in-v740)設定することで、上記のログにカスタム識別子を追加できます。ログにアプリケーション識別情報を挿入できるこの機能により、ログの内容とアプリケーションを関連付け、アプリケーションからログへのリンクを構築し、診断の難易度を軽減できます。 + さらに、セッションレベルのシステム変数[`tidb_session_alias`](/system-variables.md#tidb_session_alias-new-in-v740)を設定することで、上記のログにカスタム識別子を追加できます。ログにアプリケーション識別情報を挿入できるこの機能により、ログの内容とアプリケーションを関連付け、アプリケーションからログへのリンクを構築し、診断の難易度を軽減できます。 - TiDB Dashboardは、実行計画をテーブルビューで表示することをサポートしています[＃1589](https://github.com/pingcap/tidb-dashboard/issues/1589) @[baurine](https://github.com/baurine) @@ -295,7 +295,7 @@ TiDB バージョン: 7.4.0 - パーティションテーブル[＃47071](https://github.com/pingcap/tidb/issues/47071) での`ANALYZE`操作のメモリ使用量とパフォーマンスを最適化します [＃46804](https://github.com/pingcap/tidb/issues/46804) @[hawkingrei](https://github.com/hawkingrei) [＃47104](https://github.com/pingcap/tidb/issues/47104) - 統計ガベージコレクションメモリ使用量とパフォーマンスを最適化します [＃31778](https://github.com/pingcap/tidb/issues/31778) @[winoros](https://github.com/winoros) - - インデックスマージ交差のプッシュダウン`limit`最適化してクエリパフォーマンスを向上させる [＃46863](https://github.com/pingcap/tidb/issues/46863) @[AilinKid](https://github.com/AilinKid) + - インデックスマージ交差のプッシュダウン`limit`を最適化してクエリパフォーマンスを向上させる [＃46863](https://github.com/pingcap/tidb/issues/46863) @[AilinKid](https://github.com/AilinKid) - `IndexLookup`多くのテーブル取得タスクが含まれる場合に、誤ってフルテーブルスキャンを選択する可能性を最小限に抑えるようにコストモデルを改善します[＃45132](https://github.com/pingcap/tidb/issues/45132) @[qw4990](https://github.com/qw4990) - 結合除去ルールを最適化して、 `join on unique keys` のクエリパフォーマンスを向上させます。 [＃46248](https://github.com/pingcap/tidb/issues/46248) @[fixdb](https://github.com/fixdb) - 実行エラーを回避するために、多値インデックス列の照合順序を`binary`に変更します[＃46717](https://github.com/pingcap/tidb/issues/46717) @[YangKeao](https://github.com/YangKeao) @@ -436,7 +436,7 @@ TiDB バージョン: 7.4.0 - TiDB Lightning - - TiDB Lightningがテーブル`NONCLUSTERED auto_increment`と`AUTO_ID_CACHE=1`インポートした後、データを挿入するとエラーが返される問題を修正しました[＃46100](https://github.com/pingcap/tidb/issues/46100) @[tiancaiamao](https://github.com/tiancaiamao) + - TiDB Lightningがテーブル`NONCLUSTERED auto_increment`と`AUTO_ID_CACHE=1`をインポートした後、データを挿入するとエラーが返される問題を修正しました[＃46100](https://github.com/pingcap/tidb/issues/46100) @[tiancaiamao](https://github.com/tiancaiamao) - `checksum = "optional"` のときにチェックサムがエラーを報告する問題を修正しました [＃45382](https://github.com/pingcap/tidb/issues/45382) @[lyzx2001](https://github.com/lyzx2001) - PDクラスタアドレスが変更されるとデータのインポートが失敗する問題を修正しました [＃43436](https://github.com/pingcap/tidb/issues/43436) @[lichunzhu](https://github.com/lichunzhu) diff --git a/releases/release-7.5.1.md b/releases/release-7.5.1.md index 9e2af860af3a0..1cd8760b22c29 100644 --- a/releases/release-7.5.1.md +++ b/releases/release-7.5.1.md @@ -159,7 +159,7 @@ TiDB バージョン: 7.5.1 - TiKV - - `tidb_enable_row_level_checksum`有効にすると TiKV がpanicを起こす可能性がある問題を修正[＃16371](https://github.com/tikv/tikv/issues/16371) @[cfzjywxk](https://github.com/cfzjywxk) + - `tidb_enable_row_level_checksum`を有効にすると TiKV がpanicを起こす可能性がある問題を修正[＃16371](https://github.com/tikv/tikv/issues/16371) @[cfzjywxk](https://github.com/cfzjywxk) - gRPC スレッドが`is_shutdown` をチェックしているときに TiKV がpanicする可能性がある問題を修正しました [＃16236](https://github.com/tikv/tikv/issues/16236) @[pingyu](https://github.com/pingyu) - TiKVがブラジルとエジプトのタイムゾーンを誤って変換する問題を修正[＃16220](https://github.com/tikv/tikv/issues/16220) @[overvenus](https://github.com/overvenus) - Titanの`blob-run-mode`オンラインに更新できない問題を修正 [＃15978](https://github.com/tikv/tikv/issues/15978) @[tonyxuqqi](https://github.com/tonyxuqqi) diff --git a/releases/release-7.5.7.md b/releases/release-7.5.7.md index 59bb01428a857..a6ff57929b869 100644 --- a/releases/release-7.5.7.md +++ b/releases/release-7.5.7.md @@ -128,7 +128,7 @@ TiDB バージョン: 7.5.7 - デフォルト値`lease`が正しく設定されていない問題を修正[＃9156](https://github.com/tikv/pd/issues/9156) @[rleungx](https://github.com/rleungx) - TiDB Dashboard TCP接続を不適切に閉じるとPDゴルーチンリークが発生する可能性がある問題を修正[＃9402](https://github.com/tikv/pd/issues/9402) @[baurine](https://github.com/baurine) - 新しく追加された TiKV ノードがスケジュールされない可能性がある問題を修正しました [＃9145](https://github.com/tikv/pd/issues/9145) @[bufferflies](https://github.com/bufferflies) - - `tidb_enable_tso_follower_proxy`有効にすると TSO サービスが利用できなくなる可能性がある問題を修正[＃9188](https://github.com/tikv/pd/issues/9188) @[Tema](https://github.com/Tema) + - `tidb_enable_tso_follower_proxy`を有効にすると TSO サービスが利用できなくなる可能性がある問題を修正[＃9188](https://github.com/tikv/pd/issues/9188) @[Tema](https://github.com/Tema) - TiFlash diff --git a/releases/release-7.6.0.md b/releases/release-7.6.0.md index f7c5afca7f738..c6065d52678fd 100644 --- a/releases/release-7.6.0.md +++ b/releases/release-7.6.0.md @@ -83,7 +83,7 @@ TiDB バージョン: 7.6.0 TiDBはv7.6.0以降、TiKVの定期的なフルコンパクションをサポートしています。この機能は、ガベージコレクション（GC）を拡張し、冗長なデータバージョンを排除するものです。アプリケーションのアクティビティに明らかなピークと谷が見られるシナリオでは、この機能を使用してアイドル期間中にデータコンパクションを実行することで、ピーク時のパフォーマンスを向上させることができます。 - TiKV の設定項目[`periodic-full-compact-start-times`](/tikv-configuration-file.md#periodic-full-compact-start-times-new-in-v760)設定することで、TiKV が定期的な完全圧縮を開始する特定の時間を設定できます。また、 [`periodic-full-compact-start-max-cpu`](/tikv-configuration-file.md#periodic-full-compact-start-max-cpu-new-in-v760)を設定することで、TiKV の定期的な完全圧縮の最大 CPU 使用率を制限できます。 `periodic-full-compact-start-max-cpu`のデフォルト値は`0.1`です。これは、TiKV の CPU 使用率が 10% 未満の場合にのみ定期的な完全圧縮がトリガーされることを意味し、アプリケーションのトラフィックへの影響を軽減します。 + TiKV の設定項目[`periodic-full-compact-start-times`](/tikv-configuration-file.md#periodic-full-compact-start-times-new-in-v760)を設定することで、TiKV が定期的な完全圧縮を開始する特定の時間を設定できます。また、 [`periodic-full-compact-start-max-cpu`](/tikv-configuration-file.md#periodic-full-compact-start-max-cpu-new-in-v760)を設定することで、TiKV の定期的な完全圧縮の最大 CPU 使用率を制限できます。 `periodic-full-compact-start-max-cpu`のデフォルト値は`0.1`です。これは、TiKV の CPU 使用率が 10% 未満の場合にのみ定期的な完全圧縮がトリガーされることを意味し、アプリケーションのトラフィックへの影響を軽減します。 詳細については、 [ドキュメント](/tikv-configuration-file.md#periodic-full-compact-start-times-new-in-v760)を参照してください。 @@ -105,7 +105,7 @@ TiDB バージョン: 7.6.0 さらに、クロスデータベースバインディングは、ユーザーデータとワークロードの不均一な分布や急激な変化によって引き起こされるSQLパフォーマンスの問題を効果的に軽減できます。SaaSプロバイダーは、クロスデータベースバインディングを使用して、大量のデータを持つユーザーによって検証された実行計画を修正することで、すべてのユーザーの実行計画を固定できます。SaaSプロバイダーにとって、この機能は利便性とユーザーエクスペリエンスを大幅に向上させます。 - クロスデータベースバインディングによって発生するシステムオーバーヘッド（1%未満）のため、TiDBはこの機能をデフォルトで無効にしています。クロスデータベースバインディングを使用するには、まずシステム変数[`tidb_opt_enable_fuzzy_binding`](/system-variables.md#tidb_opt_enable_fuzzy_binding-new-in-v760)有効にする必要があります。 + クロスデータベースバインディングによって発生するシステムオーバーヘッド（1%未満）のため、TiDBはこの機能をデフォルトで無効にしています。クロスデータベースバインディングを使用するには、まずシステム変数[`tidb_opt_enable_fuzzy_binding`](/system-variables.md#tidb_opt_enable_fuzzy_binding-new-in-v760)を有効にする必要があります。 詳細については、 [ドキュメント](/sql-plan-management.md#cross-database-binding)を参照してください。 diff --git a/releases/release-8.0.0.md b/releases/release-8.0.0.md index 0f0aab7728c77..61e899b7e426f 100644 --- a/releases/release-8.0.0.md +++ b/releases/release-8.0.0.md @@ -127,7 +127,7 @@ TiDB バージョン: 8.0.0 バージョン 8.0.0 以降、TiDB は大量のデータを処理するための DML タイプをサポートしています。この DML タイプは、実行中にデータを TiKV にタイムリーに書き込み、すべてのトランザクション データをメモリに継続的に格納することを回避し、メモリ制限を超える大量のデータの処理をサポートします。この DML タイプはトランザクションの整合性を保証し、標準 DML と同じ構文を使用します。 `INSERT` 、 `UPDATE` 、 `REPLACE` 、および`DELETE`ステートメントは、この新しい DML タイプを使用して大規模な DML 操作を実行できます。 - この DML タイプは[パイプラインDML](https://github.com/pingcap/tidb/blob/release-8.0/docs/design/2024-01-09-pipelined-DML.md)機能によって実装され、自動コミットが有効になっているステートメントでのみ有効になります。この DML タイプを有効にするかどうかは、システム変数[`tidb_dml_type`](/system-variables.md#tidb_dml_type-new-in-v800)設定することで制御できます。 + この DML タイプは[パイプラインDML](https://github.com/pingcap/tidb/blob/release-8.0/docs/design/2024-01-09-pipelined-DML.md)機能によって実装され、自動コミットが有効になっているステートメントでのみ有効になります。この DML タイプを有効にするかどうかは、システム変数[`tidb_dml_type`](/system-variables.md#tidb_dml_type-new-in-v800)を設定することで制御できます。 詳細については、 [ドキュメント](/system-variables.md#tidb_dml_type-new-in-v800)を参照してください。 @@ -161,7 +161,7 @@ TiDB バージョン: 8.0.0 - 一般ログの別ファイルへの書き込みをサポート [#51248](https://github.com/pingcap/tidb/issues/51248) @[Defined2014](https://github.com/Defined2014) - 一般ログは、MySQL互換の機能で、実行されたすべてのSQLステートメントをログに記録し、問題の診断に役立ちます。TiDBもこの機能をサポートしています。変数[`tidb_general_log`](/system-variables.md#tidb_general_log)設定することで有効にできます。ただし、以前のバージョンでは、一般ログの内容は他の情報とともにTiDBインスタンスログにしか書き込まれず、ログを長期間保持する必要があるユーザーにとっては不便でした。 + 一般ログは、MySQL互換の機能で、実行されたすべてのSQLステートメントをログに記録し、問題の診断に役立ちます。TiDBもこの機能をサポートしています。変数[`tidb_general_log`](/system-variables.md#tidb_general_log)を設定することで有効にできます。ただし、以前のバージョンでは、一般ログの内容は他の情報とともにTiDBインスタンスログにしか書き込まれず、ログを長期間保持する必要があるユーザーにとっては不便でした。 バージョン8.0.0以降では、設定項目[`log.general-log-file`](/tidb-configuration-file.md#general-log-file-new-in-v800)に有効なファイル名を設定することで、一般ログを指定したファイルに書き込むことができます。一般ログは、インスタンスログと同じローテーションおよび保持ポリシーに従います。 diff --git a/releases/release-8.1.0.md b/releases/release-8.1.0.md index 402c242b49d3b..e64af38a733fb 100644 --- a/releases/release-8.1.0.md +++ b/releases/release-8.1.0.md @@ -51,7 +51,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 DXFはv7.5.0で一般提供（GA）されますが、デフォルトでは無効になっています。つまり、 `ADD INDEX`または`IMPORT INTO`タスクは、デフォルトでは1つのTiDBノードによってのみ実行されます。 - TiDB v8.1.0以降、この機能はデフォルトで有効になっています（ [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)デフォルト`ON`に設定されます）。この機能を有効にすると、DXFは複数のTiDBノードで同じ`ADD INDEX`または`IMPORT INTO`タスクを並列実行するようにスケジュールできます。これにより、TiDBクラスターのリソースを最大限に活用し、これらのタスクのパフォーマンスを大幅に向上させることができます。さらに、TiDBノードを追加し、追加したノードに[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)設定することで、 `ADD INDEX`および`IMPORT INTO`タスクのパフォーマンスを直線的に向上させることができます。 + TiDB v8.1.0以降、この機能はデフォルトで有効になっています（ [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)デフォルト`ON`に設定されます）。この機能を有効にすると、DXFは複数のTiDBノードで同じ`ADD INDEX`または`IMPORT INTO`タスクを並列実行するようにスケジュールできます。これにより、TiDBクラスターのリソースを最大限に活用し、これらのタスクのパフォーマンスを大幅に向上させることができます。さらに、TiDBノードを追加し、追加したノードに[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)を設定することで、 `ADD INDEX`および`IMPORT INTO`タスクのパフォーマンスを直線的に向上させることができます。 詳細については[ドキュメント](/tidb-distributed-execution-framework.md)を参照してください。 diff --git a/releases/release-8.1.1.md b/releases/release-8.1.1.md index 346c439cdae25..d269120400b8d 100644 --- a/releases/release-8.1.1.md +++ b/releases/release-8.1.1.md @@ -13,7 +13,7 @@ TiDB バージョン: 8.1.1 ## 互換性の変更 {#compatibility-changes} -- TiDB Lightningを使用してCSVファイルをインポートする際、並列性とインポートパフォーマンスを向上させるために大きなCSVファイルを複数の小さなCSVファイルに分割するために`strict-format = true`設定する場合は、明示的に`terminator`を指定する必要があります。値は`\r` 、または`\r\n` `\n`かです。行末文字を指定しないと、CSVファイルデータの解析時に例外が発生する可能性があります[＃37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) +- TiDB Lightningを使用してCSVファイルをインポートする際、並列性とインポートパフォーマンスを向上させるために大きなCSVファイルを複数の小さなCSVファイルに分割するために`strict-format = true`を設定する場合は、明示的に`terminator`を指定する必要があります。値は`\r` 、または`\r\n` `\n`かです。行末文字を指定しないと、CSVファイルデータの解析時に例外が発生する可能性があります[＃37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) - [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してCSVファイルをインポートする際、 `SPLIT_FILE`パラメータを指定して大きなCSVファイルを複数の小さなCSVファイルに分割し、同時実行性とインポートパフォーマンスを向上させる場合は、行末文字`LINES_TERMINATED_BY`を明示的に指定する必要があります。値は`\r` 、 `\n` 、または`\r\n`です。行末文字を指定しないと、CSVファイルデータの解析時に例外が発生する可能性があります[＃37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) - 並列計算中のディスクオーバーフローによるクエリ結果の誤りを回避するため、変数[`tidb_enable_parallel_hashagg_spill`](https://docs.pingcap.com/tidb/v8.1/system-variables#tidb_enable_parallel_hashagg_spill-new-in-v800)のデフォルト値を`ON`から`OFF`に変更してください。v8.0.0またはv8.1.0からv8.1.1にアップグレードしたクラスターの場合、この変数はアップグレード後もデフォルト値の`ON`のままとなるため、手動で`OFF`に変更することをお勧めします[＃55290](https://github.com/pingcap/tidb/issues/55290) @[xzhangxian1008](https://github.com/xzhangxian1008) - TiKV構成項目[`server.grpc-compression-type`](/tikv-configuration-file.md#grpc-compression-type)のスコープを変更します。 diff --git a/releases/release-8.1.2.md b/releases/release-8.1.2.md index a4abc1135f32c..34d12b3d23a87 100644 --- a/releases/release-8.1.2.md +++ b/releases/release-8.1.2.md @@ -149,7 +149,7 @@ TiDB バージョン: 8.1.2 - TiCDC - PullerモジュールのResolved TSレイテンシーモニタリングで誤った値が表示される問題を修正しました [＃11561](https://github.com/pingcap/tiflow/issues/11561) @[wlwilliamx](https://github.com/wlwilliamx) - - `enable-table-across-nodes`有効にすると、リージョン分割中にテーブルの一部のスパン レプリケーションタスクが失われる可能性がある問題を修正しました。 [＃11675](https://github.com/pingcap/tiflow/issues/11675) @[wk989898](https://github.com/wk989898) + - `enable-table-across-nodes`を有効にすると、リージョン分割中にテーブルの一部のスパン レプリケーションタスクが失われる可能性がある問題を修正しました。 [＃11675](https://github.com/pingcap/tiflow/issues/11675) @[wk989898](https://github.com/wk989898) - やり直しモジュールがエラーを正しく報告できない問題を修正しました [＃11744](https://github.com/pingcap/tiflow/issues/11744) @[CharlesCheung96](https://github.com/CharlesCheung96) - TiDB DDL 所有者の変更中に DDL タスクのスキーマバージョンが非増分になったときに、TiCDC が誤って DDL タスクを破棄する問題を修正[＃11714](https://github.com/pingcap/tiflow/issues/11714) @[wlwilliamx](https://github.com/wlwilliamx) - チェンジフィードチェックポイントの**barrier-ts**監視メトリックが不正確になる可能性がある問題を修正しました[＃11553](https://github.com/pingcap/tiflow/issues/11553) @[3AceShowHand](https://github.com/3AceShowHand) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index 43c20658106c3..c4483c26fe537 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -215,7 +215,7 @@ TiDB バージョン: 8.4.0 | ------------------------------------------------------------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `log_bin` | 削除済み | バージョン8.4.0では、 [TiDB Binlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)が削除されました。この変数はTiDB Binlogが使用されているかどうかを示し、バージョン8.4.0以降は削除されます。 | | `sql_log_bin` | 削除済み | バージョン8.4.0では、 [TiDB Binlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)が削除されました。この変数は、変更内容をTiDB Binlogに書き込むかどうかを示すもので、バージョン8.4.0以降は削除されます。 | -| [`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760) | 非推奨 | v8.4.0 では、この変数は非推奨です。その値はデフォルト値`ON`に固定されます。つまり、[グローバルインデックス](/global-indexes.md)はデフォルトで有効になっています。 `GLOBAL`または`CREATE TABLE`を実行してグローバルインデックスを作成する際に、対応する列にキーワード`ALTER TABLE`追加するだけで済みます。 | +| [`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760) | 非推奨 | v8.4.0 では、この変数は非推奨です。その値はデフォルト値`ON`に固定されます。つまり、[グローバルインデックス](/global-indexes.md)はデフォルトで有効になっています。 `CREATE TABLE`または`ALTER TABLE`を実行してグローバルインデックスを作成する際に、対応する列にキーワード`GLOBAL`を追加するだけで済みます。 | | [`tidb_enable_list_partition`](/system-variables.md#tidb_enable_list_partition-new-in-v50) | 非推奨 | バージョン8.4.0では、この変数は非推奨となります。その値はデフォルト値`ON`に固定され、[リスト分割](/partitioned-table.md#list-partitioning)がデフォルトで有効になります。 | | [`tidb_enable_table_partition`](/system-variables.md#tidb_enable_table_partition) | 非推奨 | v8.4.0 では、この変数は非推奨になりました。その値はデフォルト値`ON`に固定されます。つまり、[テーブルパーティショニング](/partitioned-table.md)はデフォルトで有効になります。 | | [`tidb_analyze_partition_concurrency`](/system-variables.md#tidb_analyze_partition_concurrency) | 変更 | 値の範囲を`[1, 18446744073709551615]`から`[1, 128]`に変更します。 | @@ -229,8 +229,8 @@ TiDB バージョン: 8.4.0 | [`tidb_hash_join_version`](/system-variables.md#tidb_hash_join_version-new-in-v840) | 新しく追加された | TiDB がハッシュ結合演算子の最適化バージョンを使用するかどうかを制御します。デフォルト値の`legacy`は、最適化バージョンが使用されないことを意味します。これを`optimized`に設定すると、TiDB はハッシュ結合演算子の実行時に最適化バージョンを使用して、ハッシュ結合のパフォーマンスを向上させます。 | | [`tidb_instance_plan_cache_max_size`](/system-variables.md#tidb_instance_plan_cache_max_size-new-in-v840) | 新しく追加された | インスタンスプランキャッシュの最大メモリ使用量を設定します。 | | [`tidb_instance_plan_cache_reserved_percentage`](/system-variables.md#tidb_instance_plan_cache_reserved_percentage-new-in-v840) | 新しく追加された | メモリ解放後にインスタンスプランキャッシュ用に予約されるアイドルメモリの割合を制御します。 | -| [`tidb_pre_split_regions`](/system-variables.md#tidb_pre_split_regions-new-in-v840) | 新しく追加された | バージョン 8.4.0 より前では、新しく作成されたテーブルのデフォルトの行分割スライス数を設定するには、各`PRE_SPLIT_REGIONS` SQL ステートメントで`CREATE TABLE`宣言する必要がありましたが、多数のテーブルを同様に構成する必要がある場合は複雑でした。この変数は、このような問題を解決するために導入されました。使いやすさを向上させるために、このシステム変数を`GLOBAL`または`SESSION`レベルで設定できます。 | -| [`tidb_shard_row_id_bits`](/system-variables.md#tidb_shard_row_id_bits-new-in-v840) | 新しく追加された | バージョン 8.4.0 より前では、新しく作成されたテーブルの行 ID のスライス数のデフォルト設定を行うには、 `SHARD_ROW_ID_BITS`または`CREATE TABLE` SQL ステートメントごとに`ALTER TABLE`宣言する必要がありましたが、多数のテーブルを同様に構成する必要がある場合は複雑でした。この変数は、このような問題を解決するために導入されました。使いやすさを向上させるために、このシステム変数を`GLOBAL`または`SESSION`レベルで設定できます。 | +| [`tidb_pre_split_regions`](/system-variables.md#tidb_pre_split_regions-new-in-v840) | 新しく追加された | バージョン 8.4.0 より前では、新しく作成されたテーブルのデフォルトの行分割スライス数を設定するには、各`CREATE TABLE` SQL ステートメントで`PRE_SPLIT_REGIONS`を宣言する必要がありましたが、多数のテーブルを同様に構成する必要がある場合は複雑でした。この変数は、このような問題を解決するために導入されました。使いやすさを向上させるために、このシステム変数を`GLOBAL`または`SESSION`レベルで設定できます。 | +| [`tidb_shard_row_id_bits`](/system-variables.md#tidb_shard_row_id_bits-new-in-v840) | 新しく追加された | バージョン 8.4.0 より前では、新しく作成されたテーブルの行 ID のスライス数のデフォルト設定を行うには、 `CREATE TABLE`または`ALTER TABLE` SQL ステートメントごとに`SHARD_ROW_ID_BITS`を宣言する必要がありましたが、多数のテーブルを同様に構成する必要がある場合は複雑でした。この変数は、このような問題を解決するために導入されました。使いやすさを向上させるために、このシステム変数を`GLOBAL`または`SESSION`レベルで設定できます。 | | [`tidb_tso_client_rpc_mode`](/system-variables.md#tidb_tso_client_rpc_mode-new-in-v840) | 新しく追加された | TiDBがPDにTSO RPCリクエストを送信するモードを切り替えます。このモードによって、TSO RPCリクエストを並列処理できるかどうかが決まり、各TS取得操作のバッチ待機時間に影響するため、特定のシナリオにおけるクエリ実行中のTS取得の待機時間を短縮できます。 | ### コンフィグレーションパラメータ {#configuration-parameters} diff --git a/resources/markdownlint-rules.md b/resources/markdownlint-rules.md index 1f25f9c4e0edd..b0b179cb60df9 100644 --- a/resources/markdownlint-rules.md +++ b/resources/markdownlint-rules.md @@ -31,7 +31,7 @@ PRを送信する前に関連するMarkdownルールをよく理解しておら | 13 | [MD012 - 連続する複数の空白行](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md012---multiple-consecutive-blank-lines) | 連続する複数の空白行は許可されません。 | | 14 | [MD027 - 引用符の後の複数のスペース](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md027---multiple-spaces-after-blockquote-symbol) | ブロック引用記号`>`の後に複数のスペースを入れることはできません。スペースは**1つ**だけ使用でき、その後に引用文を続けます。 | | 15 | [MD029 - 順序付きリスト項目の接頭辞](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md029---ordered-list-item-prefix) | 順序付きリストを使用する場合、項目のプレフィックスは`1.`から始まり、数値順に増加する必要があります。 | -| 16 | [MD030 - リストマーカーの後のスペース](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md030---spaces-after-list-markers) | リストを使用すると、リスト マーカー ( `+` 、または`*` ) とリスト項目のテキストの間に**スペースが 1つ**`-`追加されます。 | +| 16 | [MD030 - リストマーカーの後のスペース](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md030---spaces-after-list-markers) | リストを使用すると、リスト マーカー ( `+` 、 `-` 、 `*` 、または番号) とリスト項目のテキストの間に**スペースが 1つ**だけ追加されます。 | | 17 | [MD032 - リストは空白行で囲む必要があります](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md032---lists-should-be-surrounded-by-blank-lines) | リスト (あらゆる種類) の前後には空白行が必要です。 | | 18 | [MD031 - 囲まれたコードブロックは空白行で囲む必要があります](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md031---fenced-code-blocks-should-be-surrounded-by-blank-lines) | コード ブロックの前後には空白行が必要です。 | | 19 | [MD034 - ベアURLが使用されている](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md034---bare-url-used) | ドキュメント内ではURLそのものの使用は許可されていません。ユーザーがURLを直接クリックして開くようにしたい場合は、URLを山括弧で囲んでください（ `` ）。特別な状況下でURLそのものを使用する必要がある場合、ユーザーがクリックして開く必要がない場合は、URLをバッククォートで囲んでください（ `` `URL` `` ）。 | diff --git a/role-based-access-control.md b/role-based-access-control.md index 225fd3d15cb8d..74f60f2f29702 100644 --- a/role-based-access-control.md +++ b/role-based-access-control.md @@ -210,7 +210,7 @@ SET ROLE { } ``` -たとえば、 `rw_user1`ログインした後、次のステートメントを使用して、現在のセッションでのみ有効なロール`app_read`と`app_write`有効にできます。 +たとえば、 `rw_user1`ログインした後、次のステートメントを使用して、現在のセッションでのみ有効なロール`app_read`と`app_write`を有効にできます。 ```sql SET ROLE 'app_read', 'app_write'; diff --git a/runtime-filter.md b/runtime-filter.md index 8075d4e56faf9..1f6cfe6f2a2f8 100644 --- a/runtime-filter.md +++ b/runtime-filter.md @@ -224,7 +224,7 @@ EXPLAIN ANALYZE SELECT cs_ship_date_sk FROM catalog_sales, date_dim 2 つのクエリの実行情報を比較すると、次の改善点がわかります。 -- IO 削減: TableFullScan 演算子の`total_scanned_rows`比較すると、ランタイムフィルターを有効にすると`TableFullScan`のスキャン量が 2/3 削減されることがわかります。 +- IO 削減: TableFullScan 演算子の`total_scanned_rows`を比較すると、ランタイムフィルターを有効にすると`TableFullScan`のスキャン量が 2/3 削減されることがわかります。 - ハッシュ結合のパフォーマンス向上: `HashJoin`演算子の実行時間が 376.1 ミリ秒から 157.6 ミリ秒に短縮されました。 ### ベストプラクティス {#best-practices} diff --git a/schedule-replicas-by-topology-labels.md b/schedule-replicas-by-topology-labels.md index 11d70bf894542..e2371119925a1 100644 --- a/schedule-replicas-by-topology-labels.md +++ b/schedule-replicas-by-topology-labels.md @@ -15,7 +15,7 @@ TiDBクラスターの高可用性と災害復旧能力を向上させるには ## TiKV、 TiFlash、TiDBの`labels`を構成する {#configure-labels-for-tikv-tiflash-and-tidb} -クラスター トポロジに基づいて、TiKV、 TiFlash、および TiDB に`labels`設定できます。 +クラスター トポロジに基づいて、TiKV、 TiFlash、および TiDB に`labels`を設定できます。 ### TiUPを使用してクラスターを構成する (推奨) {#configure-a-cluster-using-tiup-recommended} @@ -198,9 +198,9 @@ host = "" #### (オプション) TiDBの`labels`を構成する {#optional-configure-labels-for-tidb} -[Followerが読んだ](/follower-read.md)有効になっている場合、TiDB が同じリージョンからのデータを優先的に読み取るようにするには、TiDB ノードに対して`labels`設定する必要があります。 +[Followerが読んだ](/follower-read.md)有効になっている場合、TiDB が同じリージョンからのデータを優先的に読み取るようにするには、TiDB ノードに対して`labels`を設定する必要があります。 -構成ファイルを使用して、TiDB に`labels`設定できます。 +構成ファイルを使用して、TiDB に`labels`を設定できます。 ```toml [labels] @@ -227,9 +227,9 @@ host = "" > - 設定を有効にするには、PDに`location-labels` 、TiKVに`labels`同時に設定する必要があります。そうしないと、PDはトポロジに従ってスケジューリングを実行しません。 > - SQL の配置ルールを使用する場合、TiKV の場合は`labels`のみ設定する必要があります。現在、SQL の配置ルールは PD の`location-labels`設定と互換性がなく、この設定は無視されます。`location-labels` SQL の配置ルールを同時に使用することは推奨されません。予期しない結果が発生する可能性があります。 -`location-labels`構成するには、クラスターの状況に応じて次のいずれかの方法を選択します。 +`location-labels`を構成するには、クラスターの状況に応じて次のいずれかの方法を選択します。 -- PD クラスターが初期化されていない場合は、PD 構成ファイルで`location-labels`構成します。 +- PD クラスターが初期化されていない場合は、PD 構成ファイルで`location-labels`を構成します。 ```toml [replication] @@ -244,7 +244,7 @@ host = "" ## PDの`isolation-level`を設定する {#configure-isolation-level-for-pd} -`location-labels`が設定されている場合は、PD 設定ファイルで`isolation-level`設定することで、TiKV クラスターのトポロジ分離要件をさらに強化できます。 +`location-labels`が設定されている場合は、PD 設定ファイルで`isolation-level`を設定することで、TiKV クラスターのトポロジ分離要件をさらに強化できます。 上記の手順に従って`location-labels`をゾーン -> ラック -> ホストと設定して 3 層クラスタトポロジを作成したと仮定すると、次のように`isolation-level`を`zone`に設定できます。 @@ -279,6 +279,6 @@ PD はラベルレイヤーに従ってレプリカをスケジュールし、 `isolation-level`設定が`zone`に設定されている場合、これは物理レベルでのリージョンレプリカの最小分離要件を指定します。この場合、PD は常に同じリージョンのレプリカが異なるゾーンに分散されることを保証します。この分離制限に従うことで`max-replicas`のマルチレプリカ要件が満たされない場合でも、PD はそれに応じてスケジュールを設定しません。3つのデータ ゾーン (z1、z2、z3) に分散された TiKV クラスターを例にとると、各リージョンに 3つのレプリカが必要な場合、PD は同じリージョンの 3つのレプリカをそれぞれこれらの 3つのデータ ゾーンに分散します。z1 で停電が発生し、一定時間 (デフォルトでは 30分、 [`max-store-down-time`](/pd-configuration-file.md#max-store-down-time)によって制御) が経過しても回復できない場合、PD は z1 のリージョンレプリカが使用できなくなったと判断します。ただし、 `isolation-level` `zone`に設定されているため、PD は、同じリージョンの異なるレプリカが同じデータ ゾーンにスケジュールされないことを厳密に保証する必要があります。 z2 と z3 の両方にすでにレプリカがあるため、現時点でレプリカが 2つしかない場合でも、PD は最小分離レベル制限`isolation-level`の下ではスケジュールを実行しません。 -同様に、 `isolation-level` `rack`に設定すると、同一データセンター内の異なるラックに最小分離レベルが適用されます。この構成では、ゾーンレイヤーでの分離が可能な限り最初に保証されます。ゾーンレベルでの分離が保証できない場合、PD は同じゾーン内の同じラックに異なるレプリカがスケジュールされることを避けようとします。`host` `isolation-level`設定した場合も同様にスケジューリングが行われ、PD はまずラックの分離レベルを保証し、次にホストの分離レベルを保証します。 +同様に、 `isolation-level`を`rack`に設定すると、同一データセンター内の異なるラックに最小分離レベルが適用されます。この構成では、ゾーンレイヤーでの分離が可能な限り最初に保証されます。ゾーンレベルでの分離が保証できない場合、PD は同じゾーン内の同じラックに異なるレプリカがスケジュールされることを避けようとします。 `isolation-level`を`host`に設定した場合も同様にスケジューリングが行われ、PD はまずラックの分離レベルを保証し、次にホストの分離レベルを保証します。 要約すると、PDは現在のトポロジに応じてクラスターの災害復旧を最大化します。したがって、一定レベルの災害復旧を実現したい場合は、トポロジに応じて、異なるサイトに`max-replicas`台以上のマシンを展開する必要があります。TiDBは、 `isolation-level`などの必須構成項目も提供しており、さまざまなシナリオに応じてデータのトポロジ分離レベルをより柔軟に制御できます。 diff --git a/scheduling-configuration-file.md b/scheduling-configuration-file.md index 415e87d962fc8..e2cded83e5823 100644 --- a/scheduling-configuration-file.md +++ b/scheduling-configuration-file.md @@ -34,8 +34,8 @@ summary: スケジューリング構成ファイルには、ノード名、デ - クライアントがスケジューリングノードにアクセスするためのURL - デフォルト値: `"${listen-addr}"` -- Docker や NAT ネットワーク環境などの状況では、クライアントがスケジューリング ノードによってリッスンされるデフォルトのクライアント URL を通じてスケジューリング ノードにアクセスできない場合は、クライアント アクセスに手動で`advertise-listen-addr`設定する必要があります。 -- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `advertise-listen-addr="http://192.168.100.113:2379"`設定できます。そうすることで、クライアントは`http://192.168.100.113:2379`を通じてこのサービスを見つけることができるようになります。 +- Docker や NAT ネットワーク環境などの状況では、クライアントがスケジューリング ノードによってリッスンされるデフォルトのクライアント URL を通じてスケジューリング ノードにアクセスできない場合は、クライアント アクセスに手動で`advertise-listen-addr`を設定する必要があります。 +- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `advertise-listen-addr="http://192.168.100.113:2379"`を設定できます。そうすることで、クライアントは`http://192.168.100.113:2379`を通じてこのサービスを見つけることができるようになります。 ### `backend-endpoints` {#backend-endpoints} diff --git a/shard-row-id-bits.md b/shard-row-id-bits.md index 633aa8292ad79..ba484ba1e7536 100644 --- a/shard-row-id-bits.md +++ b/shard-row-id-bits.md @@ -11,13 +11,13 @@ summary: SHARD_ROW_ID_BITS属性について学びましょう。 クラスター化されていない主キーまたは主キーのないテーブルの場合、TiDB は自動的に生成された[`_tidb_rowid`](/tidb-rowid.md)を暗黙のAUTO_INCREMENT行IDとして使用します。多数の`INSERT`操作が実行されると、データは単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 -ホットスポットの問題を軽減するには、 `SHARD_ROW_ID_BITS`設定できます。行 ID は分散しており、データは複数の異なるリージョンに書き込まれます。 +ホットスポットの問題を軽減するには、 `SHARD_ROW_ID_BITS`を設定できます。行 ID は分散しており、データは複数の異なるリージョンに書き込まれます。 - `SHARD_ROW_ID_BITS = 4` 16個のシャードを示します - `SHARD_ROW_ID_BITS = 6` 64個のシャードを示します - `SHARD_ROW_ID_BITS = 0`デフォルトの1シャードを示します -`SHARD_ROW_ID_BITS = S`設定すると、 `_tidb_rowid`の構造は次のようになります。 +`SHARD_ROW_ID_BITS = S`を設定すると、 `_tidb_rowid`の構造は次のようになります。 | サインビット | シャードビット | AUTO_INCREMENTビット | | ------ | ------ | ------------ | diff --git a/sql-plan-replayer.md b/sql-plan-replayer.md index 7984f2efeb67f..620169d5641d7 100644 --- a/sql-plan-replayer.md +++ b/sql-plan-replayer.md @@ -133,7 +133,7 @@ curl http://127.0.0.1:10080/plan_replayer/dump/replayer_JOGvpu4t7dssySqJfTtS4A== PLAN REPLAYER LOAD 'file_name'; ``` -上記のステートメントでは、 `file_name`インポートする`ZIP`ファイルの名前です。 +上記のステートメントでは、 `file_name`はインポートする`ZIP`ファイルの名前です。 例えば： @@ -204,7 +204,7 @@ TiDBの実行計画を特定する場合、対象となるSQL文と実行計画 `PLAN REPLAYER CAPTURE`はシステム変数[`tidb_enable_plan_replayer_capture`](/system-variables.md#tidb_enable_plan_replayer_capture)によって制御されます。`PLAN REPLAYER CAPTURE`を有効にするには、システム変数の値を`ON`に設定します。 -### `PLAN REPLAYER CAPTURE`使用する {#use-plan-replayer-capture} +### `PLAN REPLAYER CAPTURE`を使用する {#use-plan-replayer-capture} 次のステートメントを使用して、対象の SQL ステートメントと実行計画のダイジェストを TiDB クラスターに登録できます。 @@ -282,11 +282,11 @@ Empty set (0.01 sec) ## `PLAN REPLAYER CONTINUOUS CAPTURE`を使用する {#use-plan-replayer-continuous-capture} -`PLAN REPLAYER CONTINUOUS CAPTURE`有効にすると、TiDB はアプリケーションの SQL 文を`SQL DIGEST`と`PLAN DIGEST`に基づいて`PLAN REPLAYER`方法で非同期的に記録します。同じ DIGEST を共有する SQL 文と実行計画については、 `PLAN REPLAYER CONTINUOUS CAPTURE`によって重複して記録されません。 +`PLAN REPLAYER CONTINUOUS CAPTURE`を有効にすると、TiDB はアプリケーションの SQL 文を`SQL DIGEST`と`PLAN DIGEST`に基づいて`PLAN REPLAYER`方法で非同期的に記録します。同じ DIGEST を共有する SQL 文と実行計画については、 `PLAN REPLAYER CONTINUOUS CAPTURE`によって重複して記録されません。 ### `PLAN REPLAYER CONTINUOUS CAPTURE`を有効にする {#enable-plan-replayer-continuous-capture} -`PLAN REPLAYER CONTINUOUS CAPTURE`はシステム変数[`tidb_enable_plan_replayer_continuous_capture`](/system-variables.md#tidb_enable_plan_replayer_continuous_capture-new-in-v700)によって制御されます。`PLAN REPLAYER CONTINUOUS CAPTURE`有効にするには、システム変数の値を`ON`に設定します。 +`PLAN REPLAYER CONTINUOUS CAPTURE`はシステム変数[`tidb_enable_plan_replayer_continuous_capture`](/system-variables.md#tidb_enable_plan_replayer_continuous_capture-new-in-v700)によって制御されます。`PLAN REPLAYER CONTINUOUS CAPTURE`を有効にするには、システム変数の値を`ON`に設定します。 ### キャプチャ結果を表示する {#view-the-capture-results} diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index 62f4558ff9f9f..72912e2253f9a 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -29,7 +29,7 @@ TiDB の現在のバージョンでは、 `Prepare`ステートメントが次 - クエリには`Order By`の後に`?`が続きます（例： `Order By ?` ）。このようなクエリは、 `?`で指定された列に基づいてデータをソートします。異なる列をターゲットとするクエリが同じ実行計画を使用すると、結果は正しくありません。そのため、このようなクエリはキャッシュされません。ただし、 `Order By a+?`のように一般的なクエリの場合はキャッシュされます。 - クエリは`Group By`の後に`?`を含みます（例： `Group By?` ）。このようなクエリは、 `?`で指定された列に基づいてデータをグループ化します。異なる列をターゲットとするクエリが同じ実行計画を使用すると、結果は正しくありません。そのため、このようなクエリはキャッシュされません。ただし、 `Group By a+?`のように一般的なクエリの場合はキャッシュされます。 - クエリには、ウィンドウ関数`Window Frame`の定義に`?` （ `(partition by year order by sale rows ? preceding)`など）が含まれています。ウィンドウ関数の他の場所に`?`出現する場合、クエリはキャッシュされます。 -- このクエリには、 `int`と`string`比較するためのパラメータ`c_int >= ?`や`c_int in (?, ?)`など）が含まれています。ここで、 `?`文字列型（ `set @x='123'`など）を示します。クエリ結果がMySQLと互換性を持つようにするには、各クエリでパラメータを調整する必要があるため、このようなクエリはキャッシュされません。 +- このクエリには、 `int`と`string`を比較するためのパラメータ`c_int >= ?`や`c_int in (?, ?)`など）が含まれています。ここで、 `?`文字列型（ `set @x='123'`など）を示します。クエリ結果がMySQLと互換性を持つようにするには、各クエリでパラメータを調整する必要があるため、このようなクエリはキャッシュされません。 - このプランは`TiFlash`アクセスしようとします。 - ほとんどの場合、現在の`Prepare`ステートメントにパラメータがない限り、 `TableDual`を含むプランはキャッシュされません。 - このクエリは、 `information_schema.columns`などのTiDBシステムビューにアクセスします。システムビューにアクセスするために`Prepare`および`Execute`ステートメントを使用することは推奨されません。 @@ -201,7 +201,7 @@ LIMIT 10; ![grafana\_panels](/media/planCache-memoryUsage-planNum-panels.png) -バージョン7.1.0以降では、システム変数[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)設定することで、各セッションでキャッシュできるプランの最大数を制御できます。環境によって推奨値は以下のとおりです。監視パネルに応じて調整してください。 +バージョン7.1.0以降では、システム変数[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を設定することで、各セッションでキャッシュできるプランの最大数を制御できます。環境によって推奨値は以下のとおりです。監視パネルに応じて調整してください。 @@ -211,7 +211,7 @@ LIMIT 10; 例えば、現在のTiDBインスタンスには50の同時セッションがあり、各セッションには約100のキャッシュプランがあります。この場合、メモリ消費量は約`50 * 100 * 100 KiB` = `512 MB`になります。 -システム変数[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)設定することで、各セッションでキャッシュできるプランの最大数を制御できます。環境によって推奨される値は次のとおりです。 +システム変数[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を設定することで、各セッションでキャッシュできるプランの最大数を制御できます。環境によって推奨される値は次のとおりです。 @@ -222,7 +222,7 @@ LIMIT 10; TiDBサーバーの未使用メモリが一定のしきい値を下回ると、プランキャッシュのメモリ保護メカニズムがトリガーされ、キャッシュされたプランの一部が削除されます。 -システム変数`tidb_prepared_plan_cache_memory_guard_ratio`設定することで、しきい値を制御できます。しきい値はデフォルトで 0.1 に設定されており、TiDBサーバーの未使用メモリが総メモリの 10% 未満（メモリの 90% が使用済み）になると、メモリ保護メカニズムが起動します。 +システム変数`tidb_prepared_plan_cache_memory_guard_ratio`を設定することで、しきい値を制御できます。しきい値はデフォルトで 0.1 に設定されており、TiDBサーバーの未使用メモリが総メモリの 10% 未満（メモリの 90% が使用済み）になると、メモリ保護メカニズムが起動します。 diff --git a/sql-statements/sql-statement-add-column.md b/sql-statements/sql-statement-add-column.md index 21a67975e225b..74dcc8088a801 100644 --- a/sql-statements/sql-statement-add-column.md +++ b/sql-statements/sql-statement-add-column.md @@ -88,7 +88,7 @@ mysql> SELECT * FROM t1; - 新しい列を追加してそれを`PRIMARY KEY`に設定することはサポートされていません。 - 新しい列を追加して`AUTO_INCREMENT`に設定することはサポートされていません。 - 生成列の追加には制限があります[生成列の制限](/generated-columns.md#limitations)を参照してください。 -- 新しい列を追加するときに`PRIMARY KEY`または`UNIQUE INDEX`を`GLOBAL`として指定して[グローバルインデックス](/global-indexes.md)設定することは、 [パーティションテーブル](/partitioned-table.md)の TiDB 拡張であり、MySQL と互換性がありません。 +- 新しい列を追加するときに`PRIMARY KEY`または`UNIQUE INDEX`を`GLOBAL`として指定して[グローバルインデックス](/global-indexes.md)を設定することは、 [パーティションテーブル](/partitioned-table.md)の TiDB 拡張であり、MySQL と互換性がありません。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-admin-checksum-table.md b/sql-statements/sql-statement-admin-checksum-table.md index 241698b32cf39..2b8fbbf85bb86 100644 --- a/sql-statements/sql-statement-admin-checksum-table.md +++ b/sql-statements/sql-statement-admin-checksum-table.md @@ -20,7 +20,7 @@ category: reference [チェックサム](https://docs.pingcap.com/tidb/stable/tidb-lightning-glossary#checksum)テーブルのデータと`table_id`などのプロパティに基づいて計算されます。つまり、同じデータを持ちながらも`table_id`値が異なる 2つのテーブルでは、チェックサムは異なります。 -[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE `実行されます。 +[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE
`が実行されます。 diff --git a/sql-statements/sql-statement-alter-index.md b/sql-statements/sql-statement-alter-index.md index 41c70de511ad5..81483e48223ed 100644 --- a/sql-statements/sql-statement-alter-index.md +++ b/sql-statements/sql-statement-alter-index.md @@ -5,7 +5,7 @@ summary: TiDB データベースの ALTER INDEX の使用法の概要。 # ALTER INDEX {#alter-index} -`ALTER INDEX`文は、インデックスの可視性を`Visible`または`Invisible`に変更するために使用されます。不可視インデックスはDML文によって維持されますが、クエリオプティマイザでは使用されません。これは、インデックスを恒久的に削除する前に二重チェックを行いたい場合に便利です。TiDB v8.0.0以降では、システム変数[`tidb_opt_use_invisible_indexes`](/system-variables.md#tidb_opt_use_invisible_indexes-new-in-v800)変更することで、オプティマイザが不可視インデックスを選択するように設定できます。 +`ALTER INDEX`文は、インデックスの可視性を`Visible`または`Invisible`に変更するために使用されます。不可視インデックスはDML文によって維持されますが、クエリオプティマイザでは使用されません。これは、インデックスを恒久的に削除する前に二重チェックを行いたい場合に便利です。TiDB v8.0.0以降では、システム変数[`tidb_opt_use_invisible_indexes`](/system-variables.md#tidb_opt_use_invisible_indexes-new-in-v800)を変更することで、オプティマイザが不可視インデックスを選択するように設定できます。 ## 概要 {#synopsis} diff --git a/sql-statements/sql-statement-alter-table.md b/sql-statements/sql-statement-alter-table.md index d36d6ab5e3e95..c52fe2691ace3 100644 --- a/sql-statements/sql-statement-alter-table.md +++ b/sql-statements/sql-statement-alter-table.md @@ -170,7 +170,7 @@ TiDB の`ALTER TABLE`には次の主な制限が適用されます。 - 一部のデータ型 (たとえば、一部の TIME、Bit、Set、Enum、JSON 型) の変更は、TiDB と MySQL 間の`CAST`関数の動作の互換性の問題によりサポートされていません。 -- `AFFINITY`オプションは TiDB 拡張構文です。テーブルで`AFFINITY`有効にすると、パーティションの追加、削除、再編成、スワップなど、そのテーブルのパーティションスキームを変更できなくなります。パーティションスキームを変更するには、まず`AFFINITY`を削除する必要があります。 +- `AFFINITY`オプションは TiDB 拡張構文です。テーブルで`AFFINITY`を有効にすると、パーティションの追加、削除、再編成、スワップなど、そのテーブルのパーティションスキームを変更できなくなります。パーティションスキームを変更するには、まず`AFFINITY`を削除する必要があります。 - 空間データ型はサポートされていません。 diff --git a/sql-statements/sql-statement-commit.md b/sql-statements/sql-statement-commit.md index 27db34d126405..395158d662057 100644 --- a/sql-statements/sql-statement-commit.md +++ b/sql-statements/sql-statement-commit.md @@ -40,7 +40,7 @@ Query OK, 0 rows affected (0.01 sec) - 現在、TiDBはメタデータロック（MDL）を使用して、DDL文によるトランザクションで使用されるテーブルの変更をデフォルトで防止しています。メタデータロックの動作はTiDBとMySQLで異なります。詳細については、 [メタデータロック](/metadata-lock.md)を参照してください。 - TiDB 3.0.8以降のバージョンでは、デフォルトで[悲観的ロック](/pessimistic-transaction.md)が使用されます。 [楽観的ロック](/optimistic-transaction.md)を使用する場合は、別のトランザクションによって行が変更されているために`COMMIT`ステートメントが失敗する可能性があることを考慮することが重要です。 -- 楽観的ロックが有効な場合、制約`UNIQUE`と`PRIMARY KEY`チェックは文のコミットまで延期されます。これにより、制約`COMMIT`文が失敗する状況が増えます。この動作は`tidb_constraint_check_in_place=ON`設定することで変更できます。 +- 楽観的ロックが有効な場合、制約`UNIQUE`と`PRIMARY KEY`チェックは文のコミットまで延期されます。これにより、制約`COMMIT`文が失敗する状況が増えます。この動作は`tidb_constraint_check_in_place=ON`を設定することで変更できます。 - TiDBは構文`ROLLBACK AND [NO] RELEASE`を解析しますが、無視します。この機能はMySQLでトランザクションのコミット直後にクライアントセッションを切断するために使用されます。TiDBでは、代わりにクライアントドライバの`mysql_close()`機能を使用することをお勧めします。 - TiDBは構文`ROLLBACK AND [NO] CHAIN`を解析しますが、無視します。この機能はMySQLで使用され、現在のトランザクションがコミットされている間に、同じ分離レベルで新しいトランザクションを即座に開始します。TiDBでは、代わりに新しいトランザクションを開始することが推奨されます。 diff --git a/sql-statements/sql-statement-create-index.md b/sql-statements/sql-statement-create-index.md index 55e1ee76ab9d0..69ec9c6f6c655 100644 --- a/sql-statements/sql-statement-create-index.md +++ b/sql-statements/sql-statement-create-index.md @@ -505,7 +505,7 @@ CREATE TABLE t1 (c1 INT, c2 INT, UNIQUE(c2)); CREATE UNIQUE INDEX c1 ON t1 (c1) INVISIBLE; ``` -TiDB v8.0.0以降では、システム変数[`tidb_opt_use_invisible_indexes`](/system-variables.md#tidb_opt_use_invisible_indexes-new-in-v800)変更することで、オプティマイザに不可視インデックスを選択させることができます。 +TiDB v8.0.0以降では、システム変数[`tidb_opt_use_invisible_indexes`](/system-variables.md#tidb_opt_use_invisible_indexes-new-in-v800)を変更することで、オプティマイザに不可視インデックスを選択させることができます。 詳細については、 [`ALTER INDEX`](/sql-statements/sql-statement-alter-index.md)を参照してください。 diff --git a/sql-statements/sql-statement-flashback-database.md b/sql-statements/sql-statement-flashback-database.md index 2c1f7928eb6f8..ccd86cf3ab4fe 100644 --- a/sql-statements/sql-statement-flashback-database.md +++ b/sql-statements/sql-statement-flashback-database.md @@ -7,7 +7,7 @@ summary: TiDB データベースでの FLASHBACK DATABASE の使用方法を学 TiDB v6.4.0 では`FLASHBACK DATABASE`構文が導入されました。`FLASHBACK DATABASE`を使用すると、ガベージコレクション (GC) の有効期間内に`DROP`ステートメントによって削除されたデータベースとそのデータを復元できます。 -履歴データの保持期間は、システム変数[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)設定することで設定できます。デフォルト値は`10m0s`です。現在の`safePoint` 、つまりGCが実行された時点までを照会するには、次のSQL文を使用します。 +履歴データの保持期間は、システム変数[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)を設定することで設定できます。デフォルト値は`10m0s`です。現在の`safePoint` 、つまりGCが実行された時点までを照会するには、次のSQL文を使用します。 ```sql SELECT * FROM mysql.tidb WHERE variable_name = 'tikv_gc_safe_point'; diff --git a/sql-statements/sql-statement-load-data.md b/sql-statements/sql-statement-load-data.md index 8246157113aa1..45b794997efc0 100644 --- a/sql-statements/sql-statement-load-data.md +++ b/sql-statements/sql-statement-load-data.md @@ -129,7 +129,7 @@ FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\' LINES TERMINATED BY '\n' STARTING BY '' ``` -`IGNORE LINES`パラメータを設定することで、ファイルの最初の`number`行を無視できます。例えば、 `IGNORE 1 LINES`設定すると、ファイルの最初の行が無視されます。 +`IGNORE LINES`パラメータを設定することで、ファイルの最初の`number`行を無視できます。例えば、 `IGNORE 1 LINES`を設定すると、ファイルの最初の行が無視されます。 ## 例 {#examples} diff --git a/sql-statements/sql-statement-lock-stats.md b/sql-statements/sql-statement-lock-stats.md index ee702a1d1f489..f3cfdf6afbaea 100644 --- a/sql-statements/sql-statement-lock-stats.md +++ b/sql-statements/sql-statement-lock-stats.md @@ -103,7 +103,7 @@ mysql> SHOW WARNINGS; 6 rows in set (0.01 sec) ``` -パーティション`p1`の統計情報をロックし、 `ANALYZE`を実行します。警告メッセージには、 `ANALYZE`文がパーティション`p1`スキップしたことが示されています。 +パーティション`p1`の統計情報をロックし、 `ANALYZE`を実行します。警告メッセージには、 `ANALYZE`文がパーティション`p1`をスキップしたことが示されています。 ```sql mysql> LOCK STATS t PARTITION p1; diff --git a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md index 4161f86b72aec..afd61679127ad 100644 --- a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md +++ b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md @@ -21,7 +21,7 @@ TiDBでは、クライアントセッションがテーブルロックを取得 > > テーブルロック機能はデフォルトで無効になっています。 > -> - TiDB Self-Managed の場合、テーブルロック機能を有効にするには、すべての TiDB インスタンスの構成ファイルで[`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400) ～ `true`設定する必要があります。 +> - TiDB Self-Managed の場合、テーブルロック機能を有効にするには、すべての TiDB インスタンスの構成ファイルで[`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400)を`true`に設定する必要があります。 > - TiDB Cloud Dedicated の場合、テーブルロック機能を有効にするには、 [TiDB Cloudサポート](https://docs.pingcap.com/tidbcloud/tidb-cloud-support)連絡して[`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400)を`true`に設定する必要があります。 > - [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、 [`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400)から`true`設定はサポートされていません。 diff --git a/sql-statements/sql-statement-recover-table.md b/sql-statements/sql-statement-recover-table.md index 0c490d26cffd9..a0b8f2523c800 100644 --- a/sql-statements/sql-statement-recover-table.md +++ b/sql-statements/sql-statement-recover-table.md @@ -51,7 +51,7 @@ NUM ::= intLit - 使用されたテーブル`DDL JOB ID`に応じて、削除されたテーブルを回復します。 - テーブル`t`を削除して別の`t`を作成し、さらに新しく作成したテーブル`t`を削除したとします。この場合、最初に削除した`t`復元するには、テーブル`DDL JOB ID`を指定するメソッドを使用する必要があります。 + テーブル`t`を削除して別の`t`を作成し、さらに新しく作成したテーブル`t`を削除したとします。この場合、最初に削除した`t`を復元するには、テーブル`DDL JOB ID`を指定するメソッドを使用する必要があります。 ```sql DROP TABLE t; diff --git a/sql-statements/sql-statement-set-role.md b/sql-statements/sql-statement-set-role.md index bcca8ac709270..a350de7c539f0 100644 --- a/sql-statements/sql-statement-set-role.md +++ b/sql-statements/sql-statement-set-role.md @@ -41,7 +41,7 @@ SELECT CURRENT_ROLE(); 1 row in set (0.000 sec) ``` -`'r2'`と`'r3'`有効にするには、次の`SET ROLE`ステートメントを実行します。 +`'r2'`と`'r3'`を有効にするには、次の`SET ROLE`ステートメントを実行します。 ```sql SET ROLE 'r2', 'r3'; diff --git a/stale-read.md b/stale-read.md index 288cce8952e7f..a486f6870ceb6 100644 --- a/stale-read.md +++ b/stale-read.md @@ -33,9 +33,9 @@ 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_read_staleness`設定することで時間範囲を指定できます。詳細な使用方法については、 [`tidb_read_staleness`](/tidb-read-staleness.md)を参照してください。 + - 時間範囲の指定：セッションにおいて、後続のクエリでTiDBが分離レベルに違反することなく、指定された時間範囲内で可能な限り新しいデータを読み取る必要がある場合は、システム変数`tidb_read_staleness`を設定することで時間範囲を指定できます。詳細な使用方法については、 [`tidb_read_staleness`](/tidb-read-staleness.md)を参照してください。 -さらに、TiDBは、システム変数[`tidb_external_ts`](/system-variables.md#tidb_external_ts-new-in-v640)と[`tidb_enable_external_ts_read`](/system-variables.md#tidb_enable_external_ts_read-new-in-v640)設定することで、セッションレベルまたはグローバルレベルで正確な時点を指定する方法を提供しています。詳細な使用方法については、 [`tidb_external_ts`を使用してステイル読み取り](/tidb-external-ts.md)を参照してください。 +さらに、TiDBは、システム変数[`tidb_external_ts`](/system-variables.md#tidb_external_ts-new-in-v640)と[`tidb_enable_external_ts_read`](/system-variables.md#tidb_enable_external_ts_read-new-in-v640)を設定することで、セッションレベルまたはグローバルレベルで正確な時点を指定する方法を提供しています。詳細な使用方法については、 [`tidb_external_ts`を使用してステイル読み取り](/tidb-external-ts.md)を参照してください。 ### ステイル読み取りのレイテンシーを削減 {#reduce-stale-read-latency} diff --git a/storage-engine/titan-configuration.md b/storage-engine/titan-configuration.md index 207e0094f96a5..986a9385f1d51 100644 --- a/storage-engine/titan-configuration.md +++ b/storage-engine/titan-configuration.md @@ -99,11 +99,11 @@ Titanの値のキャッシュサイズを制御するには、 [`blob-cache-size BLOBファイル内の古いデータ（対応するキーが更新または削除されたデータ）の割合が、 [`discardable-ratio`](/tikv-configuration-file.md#discardable-ratio)で設定されたしきい値を超えると、Titan GCがトリガーされます。このしきい値を下げると、スペースの増幅を軽減できますが、Titan GCの頻度が高くなる可能性があります。この値を上げると、Titan GC、I/O帯域幅、CPU消費量を削減できますが、ディスク容量の使用量は増加します。 -**TiKV の詳細**-**スレッド CPU** - **RocksDB CPU**から、Titan GC スレッドが長時間にわたってフルロード状態になっていることが確認された場合は、 [`max-background-gc`](/tikv-configuration-file.md#max-background-gc)調整して Titan GC スレッドプールのサイズを増やすことを検討してください。 +**TiKV の詳細**-**スレッド CPU** - **RocksDB CPU**から、Titan GC スレッドが長時間にわたってフルロード状態になっていることが確認された場合は、 [`max-background-gc`](/tikv-configuration-file.md#max-background-gc)を調整して Titan GC スレッドプールのサイズを増やすことを検討してください。 ### `rate-bytes-per-sec` {#rate-bytes-per-sec} -[`rate-bytes-per-sec`](/tikv-configuration-file.md#rate-bytes-per-sec)調整すると、RocksDB 圧縮の I/O レートを制限し、トラフィック量が多いときのフォアグラウンドの読み取りおよび書き込みパフォーマンスへの影響を軽減できます。 +[`rate-bytes-per-sec`](/tikv-configuration-file.md#rate-bytes-per-sec)を調整すると、RocksDB 圧縮の I/O レートを制限し、トラフィック量が多いときのフォアグラウンドの読み取りおよび書き込みパフォーマンスへの影響を軽減できます。 ### `shared-blob-cache` (v8.0.0 の新機能) {#shared-blob-cache-new-in-v8-0-0} @@ -154,7 +154,7 @@ Titanを無効にするには、オプション`rocksdb.defaultcf.titan.blob-run > **Note:** > - > TitanとRocksDBの両方のデータを収容するのに十分なディスク容量がない場合は、デフォルト値の`0.5` （ [`discardable-ratio`](/tikv-configuration-file.md#discardable-ratio)を使用することをお勧めします。一般的に、使用可能なディスク容量が50%未満の場合は、デフォルト値を使用することをお勧めします。これは、 `discardable-ratio = 1.0`設定するとRocksDBデータが増加し続けるためです。同時に、Titan内の既存のBLOBファイルをリサイクルするには、そのファイル内のすべてのデータをRocksDBに変換する必要があり、これは時間のかかるプロセスです。ただし、ディスクサイズが十分に大きい場合は、 `discardable-ratio = 1.0`設定すると、圧縮時にBLOBファイル自体のGCを削減できるため、帯域幅を節約できます。 + > TitanとRocksDBの両方のデータを収容するのに十分なディスク容量がない場合は、デフォルト値の`0.5` （ [`discardable-ratio`](/tikv-configuration-file.md#discardable-ratio)を使用することをお勧めします。一般的に、使用可能なディスク容量が50%未満の場合は、デフォルト値を使用することをお勧めします。これは、 `discardable-ratio = 1.0`を設定するとRocksDBデータが増加し続けるためです。同時に、Titan内の既存のBLOBファイルをリサイクルするには、そのファイル内のすべてのデータをRocksDBに変換する必要があり、これは時間のかかるプロセスです。ただし、ディスクサイズが十分に大きい場合は、 `discardable-ratio = 1.0`を設定すると、圧縮時にBLOBファイル自体のGCを削減できるため、帯域幅を節約できます。 2. （オプション）tikv-ctlを使用してフルコンパクションを実行します。このプロセスは大量のI/OとCPUリソースを消費します。 diff --git a/storage-engine/titan-overview.md b/storage-engine/titan-overview.md index aa4d57288e071..6f22050065db7 100644 --- a/storage-engine/titan-overview.md +++ b/storage-engine/titan-overview.md @@ -120,7 +120,7 @@ Titan は、選択された BLOB ファイルについて、各値に対応す レンジマージは、レベルマージに基づくGCの最適化されたアプローチです。ただし、以下の状況では、LSMツリーの最下位レベルの順序が悪くなる可能性があります。 -- `level_compaction_dynamic_level_bytes`有効にすると、LSM ツリーの各レベルのデータ量が動的に増加し、最下位レベルのソートされた実行が増加し続けます。 +- `level_compaction_dynamic_level_bytes`を有効にすると、LSM ツリーの各レベルのデータ量が動的に増加し、最下位レベルのソートされた実行が増加し続けます。 - 特定の範囲のデータが頻繁に圧縮され、その範囲内でソートされた実行が多数発生します。 ![RangeMerge](/media/titan/titan-7.png) diff --git a/sync-diff-inspector/sync-diff-inspector-overview.md b/sync-diff-inspector/sync-diff-inspector-overview.md index d924408bb213c..4bce69c935d6b 100644 --- a/sync-diff-inspector/sync-diff-inspector-overview.md +++ b/sync-diff-inspector/sync-diff-inspector-overview.md @@ -326,7 +326,7 @@ REPLACE INTO `sbtest`.`sbtest99`(`id`,`k`,`c`,`pad`) VALUES (3700000,2501808,'he - 自動入力される timestamp カラムを含むデータセットを検証する場合は、`DEFAULT CURRENT_TIMESTAMP` に依存するのではなく、検証データに対して決定論的な TIMESTAMP 値を設定することを検討してください。あるいは、その正確な値が検証目的にとって重要でない場合は、`ignore-columns` を使用して自動入力される TIMESTAMP カラムを除外してください。 - アップストリームテーブルとダウンストリームテーブルで主キーが異なる場合、sync-diff-inspector は元の主キー列を使用してチャンクを分割しません。たとえば、MySQL のシャーディングされたテーブルが、元の主キーとシャードキーを含む複合主キーを使用して TiDB にマージされる場合などです。この場合、 `index-fields`を使用して元の主キー列を構成し、 `check-data-only`を`true`に設定します。 - sync-diff-inspector は、まず TiDB の統計情報に基づいてデータをチャンクに分割します。統計情報の正確性を保証する必要があります。TiDB サーバーの*ワークロードが軽い*場合は、 `analyze table {table_name}`コマンドを手動で実行できます。 -- `table-rules`に特に注意してください。 `schema-pattern="test1"` 、 `table-pattern = "t_1"` 、 `target-schema="test2"` 、 `target-table = "t_2"`構成すると、ソースデータベースの`test1` 、 `t_1`スキーマと、ターゲットデータベースの`test2` 、 `t_2`スキーマが比較されます。 sync-diff-inspector ではシャーディングがデフォルトで有効になっているため、ソースデータベースに`test2` . `t_2`テーブルがある場合、シャーディングとして機能しているソースデータベースの`test1` . `t_1`テーブルと`test2` . `t_2`テーブルが、ターゲットデータベースの`test2` . `t_2`テーブルと比較されます。 +- `table-rules`に特に注意してください。 `schema-pattern="test1"` 、 `table-pattern = "t_1"` 、 `target-schema="test2"` 、 `target-table = "t_2"`を構成すると、ソースデータベースの`test1` 、 `t_1`スキーマと、ターゲットデータベースの`test2` 、 `t_2`スキーマが比較されます。 sync-diff-inspector ではシャーディングがデフォルトで有効になっているため、ソースデータベースに`test2` . `t_2`テーブルがある場合、シャーディングとして機能しているソースデータベースの`test1` . `t_1`テーブルと`test2` . `t_2`テーブルが、ターゲットデータベースの`test2` . `t_2`テーブルと比較されます。 - 生成されたSQLファイルは、データ修復の際の参照としてのみ使用されます。データ修復のためにこれらのSQL文を実行する前に、必ず内容を確認してください。 ## 関連リソース {#related-resources} diff --git a/table-attributes.md b/table-attributes.md index cfffbb67bb2e7..2277566b1c5a4 100644 --- a/table-attributes.md +++ b/table-attributes.md @@ -15,7 +15,7 @@ summary: TiDB のテーブル属性機能の使用方法を学習します。 -現在、TiDBは、リージョンマージの動作を制御するために、テーブルまたはパーティションに属性`merge_option`追加することのみをサポートしています。属性`merge_option`は、ホットスポットに対処する方法の一部にすぎません。 +現在、TiDBは、リージョンマージの動作を制御するために、テーブルまたはパーティションに属性`merge_option`を追加することのみをサポートしています。属性`merge_option`は、ホットスポットに対処する方法の一部にすぎません。 @@ -25,7 +25,7 @@ summary: TiDB のテーブル属性機能の使用方法を学習します。 ## 使用法 {#usage} -テーブル属性は`key=value`の形式です。複数の属性はカンマで区切られます。以下の例では、 `t`変更するテーブル名、 `p`変更するパーティション名です。 `[]`の項目はオプションです。 +テーブル属性は`key=value`の形式です。複数の属性はカンマで区切られます。以下の例では、 `t`は変更するテーブル名、 `p`は変更するパーティション名です。 `[]`の項目はオプションです。 - テーブルまたはパーティションの属性を設定します。 diff --git a/ticdc/ticdc-architecture.md b/ticdc/ticdc-architecture.md index 0b684003083a2..009e1dd72e9ac 100644 --- a/ticdc/ticdc-architecture.md +++ b/ticdc/ticdc-architecture.md @@ -55,7 +55,7 @@ TiCDCの新しいアーキテクチャは、アーキテクチャをステート ## 新機能 {#new-features} -新しいアーキテクチャでは、すべてのシンクに対して**テーブルレベルのタスク分割が**サポートされています。この機能は、changefeed 設定で`scheduler.enable-table-across-nodes = true`設定することで有効にできます。 +新しいアーキテクチャでは、すべてのシンクに対して**テーブルレベルのタスク分割が**サポートされています。この機能は、changefeed 設定で`scheduler.enable-table-across-nodes = true`を設定することで有効にできます。 この機能を有効にすると、TiCDC は、以下のいずれかの条件を満たすテーブルを自動的に分割し、複数のノードに分散させて並列レプリケーションを実行します。これにより、レプリケーションの効率とリソース利用率が向上します。 diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md index de890bc2f8d23..e384a3c5000e5 100644 --- a/ticdc/ticdc-avro-protocol.md +++ b/ticdc/ticdc-avro-protocol.md @@ -25,7 +25,7 @@ cdc cli changefeed create --server=http://127.0.0.1:8300 --changefeed-id="kafka- > **Note:** > -> Avroプロトコルを使用する場合、1つのKafkaトピックには1つのテーブルのデータのみを含めることができます。設定ファイルで[トピックディスパッチャ](/ticdc/ticdc-sink-to-kafka.md#topic-dispatchers)設定する必要があります。 +> Avroプロトコルを使用する場合、1つのKafkaトピックには1つのテーブルのデータのみを含めることができます。設定ファイルで[トピックディスパッチャ](/ticdc/ticdc-sink-to-kafka.md#topic-dispatchers)を設定する必要があります。 ```shell [sink] @@ -105,7 +105,7 @@ dispatchers = [ ] ``` -[`enable-tidb-extension`](#tidb-extension-fields)有効にすると、値のデータ形式は次のようになります。 +[`enable-tidb-extension`](#tidb-extension-fields)を有効にすると、値のデータ形式は次のようになります。 ``` { diff --git a/ticdc/ticdc-canal-json.md b/ticdc/ticdc-canal-json.md index a0545ae2ba8bd..901c1b7555254 100644 --- a/ticdc/ticdc-canal-json.md +++ b/ticdc/ticdc-canal-json.md @@ -305,7 +305,7 @@ TiCDCにおけるCanal-JSONデータ形式の実装方法（ `Update`イベン ### 公式Canalとの互換性 {#compatibility-with-the-official-canal} -v6.5.6、v7.1.3、v7.6.0以降、 TiCDC Canal-JSONは公式Canalのデータ形式との互換性をサポートしています。チェンジフィードを作成する際に、 `sink-uri`のうち`content-compatible=true`設定することでこの機能を有効にすることができます。このモードでは、TiCDCは公式Canalと互換性のあるCanal-JSON形式のデータを出力します。具体的な変更点は以下の通りです。 +v6.5.6、v7.1.3、v7.6.0以降、 TiCDC Canal-JSONは公式Canalのデータ形式との互換性をサポートしています。チェンジフィードを作成する際に、 `sink-uri`のうち`content-compatible=true`を設定することでこの機能を有効にすることができます。このモードでは、TiCDCは公式Canalと互換性のあるCanal-JSON形式のデータを出力します。具体的な変更点は以下の通りです。 - `mysqlType`フィールドには、各タイプのタイプ パラメータの完全な情報が含まれています。 - `Update`タイプのイベントは、変更された列データのみを出力します。 diff --git a/ticdc/ticdc-changefeed-overview.md b/ticdc/ticdc-changefeed-overview.md index 6af7b690ec229..fd797702c202b 100644 --- a/ticdc/ticdc-changefeed-overview.md +++ b/ticdc/ticdc-changefeed-overview.md @@ -44,4 +44,4 @@ TiCDCクラスターとそのレプリケーションタスクは、コマンド HTTPインターフェース（TiCDC OpenAPI機能）を使用して、TiCDCクラスターとそのレプリケーションタスクを管理することもできます。詳細については、 [TiCDC OpenAPI](/ticdc/ticdc-open-api.md)を参照してください。 -TiCDC がTiUPを使用してデプロイされている場合は、 `tiup cdc:v cli`コマンドを実行することで`cdc cli`起動できます。 `v` TiCDC クラスターのバージョン（例： `v8.5.3` ）に置き換えてください。 `cdc cli`直接実行することもできます。 +TiCDC がTiUPを使用してデプロイされている場合は、 `tiup cdc:v cli`コマンドを実行することで`cdc cli`を起動できます。 `v`を TiCDC クラスターのバージョン（例： `v8.5.3` ）に置き換えてください。 `cdc cli`を直接実行することもできます。 diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 2cfb8913dc02c..9b1ed06304615 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -11,7 +11,7 @@ summary: TiCDC を使用する際に遭遇する可能性のある FAQ につい > > このドキュメントでは、 `cdc cli`コマンドで指定されているサーバーアドレスは`--server=http://127.0.0.1:8300`です。コマンドを使用する際は、このアドレスを実際の PD アドレスに置き換えてください。 -## TiCDC でタスクを作成するときに`start-ts`選択するにはどうすればよいですか? {#how-do-i-choose-start-ts-when-creating-a-task-in-ticdc} +## TiCDC でタスクを作成するときに`start-ts`を選択するにはどうすればよいですか? {#how-do-i-choose-start-ts-when-creating-a-task-in-ticdc} レプリケーションタスクの`start-ts`は、上流TiDBクラスタ内のタイムスタンプOracle（TSO）に対応します。TiCDCは、レプリケーションタスクでこのTSOにデータを要求します。したがって、レプリケーションタスクの`start-ts` 、以下の要件を満たす必要があります。 @@ -164,7 +164,7 @@ v4.0.0-rc.1以降、PDはサービスレベルのGCセーフポイントの設 この機能により、レプリケーションタスクが利用できないか中断された場合でも、TiCDC によって消費されるデータは GC によって消去されることなく TiKV に保持されます。 -TiCDCサーバーの起動時に、GCセーフポイントのTime To Live（TTL）期間を`gc-ttl`設定することで指定できます。また、 [TiUPを使用して変更する](/ticdc/deploy-ticdc.md#modify-ticdc-cluster-configurations-using-tiup) `gc-ttl`を設定することもできます。デフォルト値は24時間です。TiCDCでは、この値は以下の意味を持ちます。 +TiCDCサーバーの起動時に、GCセーフポイントのTime To Live（TTL）期間を`gc-ttl`を設定することで指定できます。また、 [TiUPを使用して変更する](/ticdc/deploy-ticdc.md#modify-ticdc-cluster-configurations-using-tiup) `gc-ttl`を設定することもできます。デフォルト値は24時間です。TiCDCでは、この値は以下の意味を持ちます。 - TiCDC サービスが停止した後、GC セーフポイントが PD に保持される最大時間。 - TiKVのGCがTiCDCのGCセーフポイントによってブロックされている場合、 `gc-ttl` TiCDCレプリケーションタスクの最大レプリケ​​ーション遅延を示します。レプリケーションタスクの遅延が`gc-ttl`で設定された値を超えると、レプリケーションタスクは`failed`状態になり、 `ErrGCTTLExceeded`エラーを報告します。この状態は回復できず、GCセーフポイントの進行をブロックしなくなります。 @@ -198,7 +198,7 @@ TiCDC がサービス GC セーフポイントに設定するデフォルトの > **Note:** > -> `sink-uri`の`time-zone`パラメータは、 `mysql`と`tidb`シンクにのみ適用されます。Kafka、Pulsar、Cloud Storage など、下流のデータベースセッションのタイムゾーンが関係しないシンクの場合、 `time-zone`設定する必要はありません。このようなシナリオでは、上流のデータベースのタイムゾーンと TiCDC サーバーの`--tz`パラメータ設定が一致していることを確認するだけで済みます。 +> `sink-uri`の`time-zone`パラメータは、 `mysql`と`tidb`シンクにのみ適用されます。Kafka、Pulsar、Cloud Storage など、下流のデータベースセッションのタイムゾーンが関係しないシンクの場合、 `time-zone`を設定する必要はありません。このようなシナリオでは、上流のデータベースのタイムゾーンと TiCDC サーバーの`--tz`パラメータ設定が一致していることを確認するだけで済みます。 > **Note:** > @@ -528,6 +528,6 @@ TiCDCはSaramaクライアントを使用してKafkaにデータを複製しま connections.max.idle.ms=86400000 # Set to 1 day ``` - 実際のレプリケーションワークロードに応じて、 `connections.max.idle.ms`の値を調整することをお勧めします。例えば、TiCDCの変更フィードが常に数分以内にデータをレプリケートする場合は、非常に大きな値ではなく、数分程度の`connections.max.idle.ms`設定できます。 + 実際のレプリケーションワークロードに応じて、 `connections.max.idle.ms`の値を調整することをお勧めします。例えば、TiCDCの変更フィードが常に数分以内にデータをレプリケートする場合は、非常に大きな値ではなく、数分程度の`connections.max.idle.ms`を設定できます。 2. 設定変更を適用するには、Kafka を再起動してください。これにより、接続が途中で閉じられるのを防ぎ、 `broken pipe`を減らすことができます。 diff --git a/ticdc/ticdc-filter.md b/ticdc/ticdc-filter.md index fdd8853a920a7..c28d2b206ec39 100644 --- a/ticdc/ticdc-filter.md +++ b/ticdc/ticdc-filter.md @@ -115,7 +115,7 @@ ignore-update-new-value-expr = "gender = 'male' and age > 18" # Ignore update DM > **Note:** > - > TiDBのDDL文は、 `ALTER TABLE t MODIFY COLUMN a INT, ADD COLUMN b INT, DROP COLUMN c;`のように単一テーブルの複数の属性を同時に変更することをサポートしています。この操作はMultiSchemaChangeとして定義されています。このタイプのDDLを除外したい場合は、 `ignore-event`で`"multi schema change"`設定する必要があります。 + > TiDBのDDL文は、 `ALTER TABLE t MODIFY COLUMN a INT, ADD COLUMN b INT, DROP COLUMN c;`のように単一テーブルの複数の属性を同時に変更することをサポートしています。この操作はMultiSchemaChangeとして定義されています。このタイプのDDLを除外したい場合は、 `ignore-event`で`"multi schema change"`を設定する必要があります。 - `ignore-sql` : フィルタリングするDDL文の正規表現。このパラメータは文字列の配列を受け付け、複数の正規表現を設定できます。この設定はDDLイベントにのみ適用されます。 diff --git a/ticdc/ticdc-integrity-check.md b/ticdc/ticdc-integrity-check.md index c310be6b975b0..c910e685ba47a 100644 --- a/ticdc/ticdc-integrity-check.md +++ b/ticdc/ticdc-integrity-check.md @@ -27,7 +27,7 @@ TiCDCはデフォルトでデータ整合性検証を無効にしています。 corruption-handle-level = "warn" ``` -3. データエンコード形式としてAvroを使用する場合は、 [`sink-uri`](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka)に[`enable-tidb-extension=true`](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka)設定する必要があります。ネットワーク転送中に数値精度が失われ、チェックサム検証エラーが発生するのを防ぐため、 [`avro-decimal-handling-mode=string`](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka)と[`avro-bigint-unsigned-handling-mode=string`](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka)設定する必要があります。以下に例を示します。 +3. データエンコード形式としてAvroを使用する場合は、 [`sink-uri`](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka)に[`enable-tidb-extension=true`](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka)を設定する必要があります。ネットワーク転送中に数値精度が失われ、チェックサム検証エラーが発生するのを防ぐため、 [`avro-decimal-handling-mode=string`](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka)と[`avro-bigint-unsigned-handling-mode=string`](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka)を設定する必要があります。以下に例を示します。 ```shell cdc cli changefeed create --server=http://127.0.0.1:8300 --changefeed-id="kafka-avro-checksum" --sink-uri="kafka://127.0.0.1:9092/topic-name?protocol=avro&enable-tidb-extension=true&avro-decimal-handling-mode=string&avro-bigint-unsigned-handling-mode=string" --schema-registry=http://127.0.0.1:8081 --config changefeed_config.toml diff --git a/ticdc/ticdc-server-config.md b/ticdc/ticdc-server-config.md index e40a621841f34..0f3c8498b5053 100644 --- a/ticdc/ticdc-server-config.md +++ b/ticdc/ticdc-server-config.md @@ -15,7 +15,7 @@ summary: TiCDC で使用される CLI と構成パラメータについて学習 - `advertise-addr` : クライアントがTiCDCにアクセスするために使用するアドバタイズされたアドレス。指定されていない場合、値は`addr`と同じになります。 - `pd` : PD エンドポイントのコンマ区切りリスト。 - `config` : TiCDCが使用する設定ファイルのアドレス（オプション）。このオプションはTiCDC v5.0.0以降でサポートされています。このオプションはTiUP v1.4.0以降のTiCDCデプロイメントで使用できます。詳細な設定については、 [TiCDC Changefeed構成](/ticdc/ticdc-changefeed-config.md)を参照してください。 -- `data-dir` : TiCDC がファイルを保存するためにディスクを使用する必要があるときに使用するディレクトリを指定します。TiCDC が使用するソートエンジンと REDO ログは、このディレクトリに一時ファイルを保存します。このディレクトリの空きディスク容量は 500 GiB 以上確保することをお勧めします。TiUPを使用している場合は、セクション[`cdc_servers`](/tiup/tiup-cluster-topology-reference.md#cdc_servers)で`data_dir`設定するか、 `global`でデフォルトのパス`data_dir`を直接使用できます。 +- `data-dir` : TiCDC がファイルを保存するためにディスクを使用する必要があるときに使用するディレクトリを指定します。TiCDC が使用するソートエンジンと REDO ログは、このディレクトリに一時ファイルを保存します。このディレクトリの空きディスク容量は 500 GiB 以上確保することをお勧めします。TiUPを使用している場合は、セクション[`cdc_servers`](/tiup/tiup-cluster-topology-reference.md#cdc_servers)で`data_dir`を設定するか、 `global`でデフォルトのパス`data_dir`を直接使用できます。 - `gc-ttl` : TiCDC によって設定される PD のサービスレベル`GC safepoint`の TTL (Time To Live) と、レプリケーションタスクが一時停止できる期間（秒単位）。デフォルト値は`86400`で、これは 24時間を意味します。注: TiCDC レプリケーションタスクの一時停止は、TiCDC GC セーフポイントの進行に影響します。つまり、 [TiCDC GCセーフポイントの完全な動作](/ticdc/ticdc-faq.md#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint)で詳述されているように、上流の TiDB GC の進行にも影響します。 - `log-file` : TiCDCプロセス実行時にログが出力されるパス。このパラメータが指定されていない場合、ログは標準出力（stdout）に書き込まれます。 - `log-level` : TiCDCプロセス実行時のログレベル。デフォルト値は`"info"`です。 diff --git a/ticdc/ticdc-simple-protocol.md b/ticdc/ticdc-simple-protocol.md index 96e9a84583dde..81ecd4c26ddc1 100644 --- a/ticdc/ticdc-simple-protocol.md +++ b/ticdc/ticdc-simple-protocol.md @@ -494,7 +494,7 @@ TiCDC は`BOOTSTRAP`イベントを次の JSON 形式でエンコードします - 生成時間: - 新しい変更フィードを作成した後、テーブルの最初の DML イベントが送信される前に、TiCDC はテーブルスキーマを構築するために`BOOTSTRAP`イベントをダウンストリームに送信します。 - - さらに、TiCDCは、新しく参加したコンシューマーがテーブルスキーマを構築できるように、定期的にイベントを`BOOTSTRAP`送信します。デフォルトの送信間隔は120秒または10000メッセージごとです。送信間隔は、 `sink`設定でパラメータ`send-bootstrap-interval-in-sec`と`send-bootstrap-in-msg-count`設定することで調整できます。 + - さらに、TiCDCは、新しく参加したコンシューマーがテーブルスキーマを構築できるように、定期的にイベントを`BOOTSTRAP`送信します。デフォルトの送信間隔は120秒または10000メッセージごとです。送信間隔は、 `sink`設定でパラメータ`send-bootstrap-interval-in-sec`と`send-bootstrap-in-msg-count`を設定することで調整できます。 - テーブルが30分以内に新しいDMLメッセージを受信しない場合、そのテーブルは非アクティブとみなされます。TiCDCは、新しいDMLイベントを受信するまで、そのテーブルへの`BOOTSTRAP`の送信を停止します。 - 送信先: デフォルトでは、TiCDC は対応するトピックのすべてのパーティションに`BOOTSTRAP`イベントを送信します。シンク設定の`send-bootstrap-to-all-partition`パラメータを設定することで、送信戦略を調整できます。 diff --git a/ticdc/ticdc-sink-to-cloud-storage.md b/ticdc/ticdc-sink-to-cloud-storage.md index 20b513a64db5f..f3c7ac2a9a45d 100644 --- a/ticdc/ticdc-sink-to-cloud-storage.md +++ b/ticdc/ticdc-sink-to-cloud-storage.md @@ -122,11 +122,11 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを - 方法1: 共有アクセス署名を指定する - URIに`account-name`と`sas-token`設定した場合、このパラメーターで指定されたストレージアカウント名と共有アクセス署名トークンが使用されます。共有アクセス署名トークンには`&`文字が含まれているため、URIに追加する前に`%26`としてエンコードする必要があります。パーセントエンコードを使用して、 `sas-token`全体を直接エンコードすることもできます。 + URIに`account-name`と`sas-token`を設定した場合、このパラメーターで指定されたストレージアカウント名と共有アクセス署名トークンが使用されます。共有アクセス署名トークンには`&`文字が含まれているため、URIに追加する前に`%26`としてエンコードする必要があります。パーセントエンコードを使用して、 `sas-token`全体を直接エンコードすることもできます。 - 方法2: アクセスキーを指定する - URIで`account-name`と`account-key`設定した場合、このパラメータで指定されたストレージアカウント名とキーが使用されます。URIでキーファイルを指定するだけでなく、TiCDCは環境変数`$AZURE_STORAGE_KEY`からキーを読み取ることもできます。 + URIで`account-name`と`account-key`を設定した場合、このパラメータで指定されたストレージアカウント名とキーが使用されます。URIでキーファイルを指定するだけでなく、TiCDCは環境変数`$AZURE_STORAGE_KEY`からキーを読み取ることもできます。 - 方法3: Azure ADを使用してバックアップを復元する diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index 15f285fa516e3..ee0d329c6fcb3 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -54,7 +54,7 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na > **Tip:** > -> 下流のKafkaに複数のホストまたはポートがある場合は、シンクURIに複数の`[host]:[port]`設定できます。例： +> 下流のKafkaに複数のホストまたはポートがある場合は、シンクURIに複数の`[host]:[port]`を設定できます。例： > > ```shell > [scheme]://[host]:[port],[host]:[port],[host]:[port][/path]?[query_parameters] @@ -194,7 +194,7 @@ dispatchers = [ ### TiCDC を AWS Glue スキーマレジストリと統合する {#integrate-ticdc-with-aws-glue-schema-registry} -v7.4.0以降、TiCDCは、ユーザーがデータレプリケーションに[Avroプロトコル](/ticdc/ticdc-avro-protocol.md)選択した場合、スキーマレジストリとして[AWS Glue スキーマレジストリ](https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html)使用をサポートします。設定例は次のとおりです。 +v7.4.0以降、TiCDCは、ユーザーがデータレプリケーションに[Avroプロトコル](/ticdc/ticdc-avro-protocol.md)を選択した場合、スキーマレジストリとして[AWS Glue スキーマレジストリ](https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html)使用をサポートします。設定例は次のとおりです。 ```shell ./cdc cli changefeed create --server=127.0.0.1:8300 --changefeed-id="kafka-glue-test" --sink-uri="kafka://127.0.0.1:9092/topic-name?&protocol=avro&replication-factor=3" --config changefeed_glue.toml diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index 368254797794a..497bff73703cd 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -116,8 +116,8 @@ COMMIT; v6.5.10、v7.1.6、v7.5.3、v8.1.1以降、MySQL以外のシンクを使用する場合、TiCDCはGitHub Issue [＃11211](https://github.com/pingcap/tiflow/issues/11211)に記載されているように、 `output-raw-change-event`パラメータを介して主キーまたは一意キーの`UPDATE`イベントを分割するかどうかを制御できるようになりました。このパラメータの具体的な動作は次のとおりです。 -- `output-raw-change-event = false`設定すると、主キーまたは null 以外の一意インデックス値が`UPDATE`イベントで変更された場合、TiCDC はイベントを`DELETE`と`INSERT`イベントに分割し、すべてのイベントが`INSERT`イベントの前の`DELETE`イベントのシーケンスに従うようにします。 -- `output-raw-change-event = true`設定すると、TiCDCは`UPDATE`イベントを分割せず、 [MySQL以外のシンクの主キーまたは一意キーの`UPDATE`イベントを分割する](/ticdc/ticdc-split-update-behavior.md#split-primary-or-unique-key-update-events-for-non-mysql-sinks)で説明した問題への対処はコンシューマー側で行います。そうしないと、データの不整合が発生するリスクがあります。テーブルの主キーがクラスター化インデックスである場合、主キーへの更新はTiDB内で依然として`DELETE`つと`INSERT`イベントに分割されますが、この動作は`output-raw-change-event`パラメータの影響を受けません。 +- `output-raw-change-event = false`を設定すると、主キーまたは null 以外の一意インデックス値が`UPDATE`イベントで変更された場合、TiCDC はイベントを`DELETE`と`INSERT`イベントに分割し、すべてのイベントが`INSERT`イベントの前の`DELETE`イベントのシーケンスに従うようにします。 +- `output-raw-change-event = true`を設定すると、TiCDCは`UPDATE`イベントを分割せず、 [MySQL以外のシンクの主キーまたは一意キーの`UPDATE`イベントを分割する](/ticdc/ticdc-split-update-behavior.md#split-primary-or-unique-key-update-events-for-non-mysql-sinks)で説明した問題への対処はコンシューマー側で行います。そうしないと、データの不整合が発生するリスクがあります。テーブルの主キーがクラスター化インデックスである場合、主キーへの更新はTiDB内で依然として`DELETE`つと`INSERT`イベントに分割されますが、この動作は`output-raw-change-event`パラメータの影響を受けません。 > **Note** > diff --git a/ticdc/ticdc-upstream-downstream-check.md b/ticdc/ticdc-upstream-downstream-check.md index c84706a5c4138..e8b88a0a78808 100644 --- a/ticdc/ticdc-upstream-downstream-check.md +++ b/ticdc/ticdc-upstream-downstream-check.md @@ -37,7 +37,7 @@ sync-point-retention = "1h" > > 一貫性のあるスナップショット読み取りを実行する前に、 [同期ポイント機能を有効にしました](#enable-syncpoint)確保されていることを確認してください。複数のレプリケーションタスクが同じ下流 TiDB クラスターを使用し、同期ポイントが有効になっている場合、各タスクはそれぞれのレプリケーションの進行状況に基づいて`tidb_external_ts`と`ts-map`を更新します。この場合、 `ts-map`テーブルからレコードを読み取ることで、レプリケーションタスクレベルで一貫性のあるスナップショット読み取りを設定する必要があります。また、下流アプリケーションが`tidb_enable_external_ts_read`を使用してデータを読み取ることは避ける必要があります。複数のレプリケーションタスクが互いに干渉し、結果に矛盾が生じる可能性があるためです。 -バックアップ クラスターからデータを照会する必要がある場合は、アプリケーションがバックアップ クラスター上でトランザクション的に一貫性のあるデータを取得するように`SET GLOBAL|SESSION tidb_enable_external_ts_read = ON;`設定できます。 +バックアップ クラスターからデータを照会する必要がある場合は、アプリケーションがバックアップ クラスター上でトランザクション的に一貫性のあるデータを取得するように`SET GLOBAL|SESSION tidb_enable_external_ts_read = ON;`を設定できます。 さらに、 `ts-map`をクエリして、スナップショット読み取りの以前の時点を選択することもできます。 @@ -47,7 +47,7 @@ sync-point-retention = "1h" > > データ一貫性検証を実行する前に、 [同期ポイント機能を有効にしました](#enable-syncpoint)あることを確認してください。 -アップストリームクラスターとダウンストリームクラスターのデータを検証するには、sync-diff-inspector で`snapshot`設定するだけです。 +アップストリームクラスターとダウンストリームクラスターのデータを検証するには、sync-diff-inspector で`snapshot`を設定するだけです。 ### ステップ1: `ts-map`を取得する {#step-1-obtain-ts-map} diff --git a/tidb-cloud/changefeed-sink-to-apache-pulsar.md b/tidb-cloud/changefeed-sink-to-apache-pulsar.md index 8b493c42f1f21..338ade9d8293e 100644 --- a/tidb-cloud/changefeed-sink-to-apache-pulsar.md +++ b/tidb-cloud/changefeed-sink-to-apache-pulsar.md @@ -27,7 +27,7 @@ Apache Pulsarにデータをストリーミングするためのチェンジフ - ネットワーク接続を設定する - Pulsar ACL認証のための権限を追加する -- Apache Pulsarでトピックを手動で作成するか、Apache Pulsarブローカーの設定で[`allowAutoTopicCreation`](https://pulsar.apache.org/reference/#/4.0.x/config/reference-configuration-broker?id=allowautotopiccreation)有効にしてください。 +- Apache Pulsarでトピックを手動で作成するか、Apache Pulsarブローカーの設定で[`allowAutoTopicCreation`](https://pulsar.apache.org/reference/#/4.0.x/config/reference-configuration-broker?id=allowautotopiccreation)を有効にしてください。 ### ネットワーク {#network} diff --git a/tidb-cloud/connected-lark-ticket-creation.md b/tidb-cloud/connected-lark-ticket-creation.md index 65f66431bc66d..3560a0e7371eb 100644 --- a/tidb-cloud/connected-lark-ticket-creation.md +++ b/tidb-cloud/connected-lark-ticket-creation.md @@ -29,7 +29,7 @@ TiDB Cloud **Enterprise** [サポートプラン](/tidb-cloud/connected-care-det ## チケットの最新情報を購読する {#subscribe-to-ticket-updates} -[サポートチケットを作成する](#create-a-support-ticket)設定すると、Lark **PingCAP Support Group**でチケットの更新情報を直接受け取ることができます。サポートエンジニアがチケットに返信すると、ボットがグループに更新メッセージを投稿します。メッセージには、チケットのタイトル、チケットへのリンク、最新のコメントが含まれます。 +[サポートチケットを作成する](#create-a-support-ticket)と、Lark **PingCAP Support Group**でチケットの更新情報を直接受け取ることができます。サポートエンジニアがチケットに返信すると、ボットがグループに更新メッセージを投稿します。メッセージには、チケットのタイトル、チケットへのリンク、最新のコメントが含まれます。 ![lark-ticket-creation-5](/media/tidb-cloud/connected-lark-ticket-creation-5.png) diff --git a/tidb-cloud/csv-config-for-import-data.md b/tidb-cloud/csv-config-for-import-data.md index 6f34aef20d5f7..3e0885915d488 100644 --- a/tidb-cloud/csv-config-for-import-data.md +++ b/tidb-cloud/csv-config-for-import-data.md @@ -63,7 +63,7 @@ summary: TiDB Cloudのインポートデータサービスで CSV 構成を使 `"{""key1"":""val1"", ""key2"": ""val2""}"` - この場合、 `Backslash escape = False`設定すると、フィールドは次のようにデータベースに正しくエスケープされます。 + この場合、 `Backslash escape = False`を設定すると、フィールドは次のようにデータベースに正しくエスケープされます。 `{"key1": "val1", "key2": "val2"}` diff --git a/tidb-cloud/data-service-manage-endpoint.md b/tidb-cloud/data-service-manage-endpoint.md index 45656417e1b76..5e0ff904c3d28 100644 --- a/tidb-cloud/data-service-manage-endpoint.md +++ b/tidb-cloud/data-service-manage-endpoint.md @@ -492,7 +492,7 @@ TiDB Cloud Data Serviceは、エンドポイントを呼び出すのに役立つ > **Note:** > -> エンドポイントを削除する前に、エンドポイントがオンラインでないことを確認してください。そうしないと、エンドポイントを削除できません。エンドポイントのデプロイを解除するには、「エンドポイント[エンドポイントをアンデプロイする](#undeploy-an-endpoint)デプロイする」を参照してください。 +> エンドポイントを削除する前に、エンドポイントがオンラインでないことを確認してください。そうしないと、エンドポイントを削除できません。エンドポイントのデプロイを解除するには、 [エンドポイントをアンデプロイする](#undeploy-an-endpoint)を参照してください。 エンドポイントを削除するには、以下の手順を実行します。 diff --git a/tidb-cloud/data-service-manage-github-connection.md b/tidb-cloud/data-service-manage-github-connection.md index bb6fe51e3670b..3dcbe963eaf52 100644 --- a/tidb-cloud/data-service-manage-github-connection.md +++ b/tidb-cloud/data-service-manage-github-connection.md @@ -48,7 +48,7 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git > > - ディレクトリ名はスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata`のようになります。指定したディレクトリが対象のリポジトリとブランチに存在しない場合は、自動的に作成されます。 > - リポジトリ、ブランチ、ディレクトリの組み合わせによって構成ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで構成されたエンドポイントによって、指定したパス内のファイルが上書きされます。 - > - 指定したパスに別のデータアプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータアプリにインポートする場合は、「誰でもデータ[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)インポートする」を参照してください。 + > - 指定したパスに別のデータアプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータアプリにインポートする場合は、[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)を参照してください。 4. TiDB CloudコンソールまたはGitHubで行われたデータアプリの変更を相互に同期させるには、 **Configure Auto Sync & Deployment**を有効にします。 @@ -153,7 +153,7 @@ TiDB Cloudコンソールでデータアプリのエンドポイント[データ > > - ディレクトリ名はスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata`のようになります。指定したディレクトリが対象のリポジトリとブランチに存在しない場合は、自動的に作成されます。 > - リポジトリ、ブランチ、ディレクトリの組み合わせによって構成ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで構成されたエンドポイントによって、指定したパス内のファイルが上書きされます。 - > - 指定したパスに別のデータアプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータアプリにインポートする場合は、「誰でもデータ[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)インポートする」を参照してください。 + > - 指定したパスに別のデータアプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータアプリにインポートする場合は、[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)を参照してください。 5. TiDB CloudコンソールまたはGitHubで行われたデータアプリの変更を相互に同期させるには、 **Configure Auto Sync & Deployment**を有効にします。 diff --git a/tidb-cloud/integrate-tidbcloud-with-zapier.md b/tidb-cloud/integrate-tidbcloud-with-zapier.md index ab4bb5ef34f2b..9330177083407 100644 --- a/tidb-cloud/integrate-tidbcloud-with-zapier.md +++ b/tidb-cloud/integrate-tidbcloud-with-zapier.md @@ -91,7 +91,7 @@ Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations) **Test action**をクリックすると、Zapierがテーブルを作成します。テストをスキップすることも可能で、その場合はワークフローが初めて実行されるときにテーブルが作成されます。 -### ステップ4： `Create Row in TiDB Cloud`設定する {#step-4-set-up-the-create-row-in-tidb-cloud-action} +### ステップ4： `Create Row in TiDB Cloud`を設定する {#step-4-set-up-the-create-row-in-tidb-cloud-action} 1. アプリとイベントを選択 diff --git a/tidb-cloud/limited-sql-features.md b/tidb-cloud/limited-sql-features.md index 471ad3e97b107..135ef74cde879 100644 --- a/tidb-cloud/limited-sql-features.md +++ b/tidb-cloud/limited-sql-features.md @@ -227,6 +227,6 @@ TiDB Cloud Dedicated はTiDB がサポートするほぼすべてのワークロ [^2]: DrainerとPump はTiDB Cloudではサポートされていません。 -[^3]: サポートされていません。TiDB Cloud Dedicated クラスターで`require_secure_transport`有効にすると、SQL クライアント接続が失敗します。 +[^3]: サポートされていません。TiDB Cloud Dedicated クラスターで`require_secure_transport`を有効にすると、SQL クライアント接続が失敗します。 [^4]: `CALIBRATE RESOURCE`ステートメントはTiDB Cloud Dedicatedではサポートされていません。クラスターのRU容量を見積もるには、代わりにTiDB Cloudコンソールの[Calibrate Resource](/tidb-cloud/calibrate-resource.md)機能を使用してください。 diff --git a/tidb-cloud/manage-user-access.md b/tidb-cloud/manage-user-access.md index b55ba3233a32f..dd03945a20f20 100644 --- a/tidb-cloud/manage-user-access.md +++ b/tidb-cloud/manage-user-access.md @@ -133,7 +133,7 @@ TiDB Cloudは、組織、プロジェクト、インスタンスの各レベル | ---------------------------------------------------------------------------------------------------- | --------------- | -------------------------------- | ------------------------------- | ---------------- | | プロジェクト設定の管理 | ✅ | ❌ | ❌ | ❌ | | プロジェクトへのユーザーの招待や削除、およびユーザーのプロジェクトにおける役割の編集を行います。 | ✅ | ❌ | ❌ | ❌ | -| プロジェクトの[データベース監査ログ](/tidb-cloud/tidb-cloud-auditing.md)管理します。 | ✅ | ❌ | ❌ | ❌ | +| プロジェクトの[データベース監査ログ](/tidb-cloud/tidb-cloud-auditing.md)を管理します。 | ✅ | ❌ | ❌ | ❌ | | プロジェクト内のすべてのTiDB Cloud Starterインスタンスの[支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)を管理します。 | ✅ | ❌ | ❌ | ❌ | | プロジェクトの種類に応じてサポートされるインスタンスやクラスタの作成、変更、移動、削除など、プロジェクト内のリソース操作を管理します。 | ✅ | ❌ | ❌ | ❌ | | プロジェクト内のTiDB Cloud StarterおよびTiDB Cloud Essentialインスタンスのブランチを管理します。ブランチの作成、接続、削除などを行います。 | ✅ | ❌ | ❌ | ❌ | diff --git a/tidb-cloud/monitor-new-relic-integration.md b/tidb-cloud/monitor-new-relic-integration.md index 4adab41c81b36..74b189dac76e5 100644 --- a/tidb-cloud/monitor-new-relic-integration.md +++ b/tidb-cloud/monitor-new-relic-integration.md @@ -88,7 +88,7 @@ TiDB Cloudは、2023年4月11日よりプロジェクトレベルのNew Relic統 1. 新しいダッシュボード用のJSONファイルを準備します。 - 1. テンプレートの JSON ファイルを[ここ](https://github.com/pingcap/diag/blob/integration/integration/dashboards/newrelic-dashboard.json)ダウンロードします。 + 1. テンプレートの JSON ファイルを[ここ](https://github.com/pingcap/diag/blob/integration/integration/dashboards/newrelic-dashboard.json)からダウンロードします。 2. JSONファイルで、4行目に`"permissions": "PUBLIC_READ_WRITE"`以下のように追加します。 diff --git a/tidb-cloud/premium/built-in-monitoring-premium.md b/tidb-cloud/premium/built-in-monitoring-premium.md index e0704385c634a..08de449102dfa 100644 --- a/tidb-cloud/premium/built-in-monitoring-premium.md +++ b/tidb-cloud/premium/built-in-monitoring-premium.md @@ -31,7 +31,7 @@ TiDB Cloud Premiumインスタンスの場合、メトリクスデータは7日 | メトリック名 | ラベル | 説明 | | :------------------ | :------------------------------------------------------------------------------------------------------------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 1秒あたりのリクエストユニット数 | 1秒あたりの合計RU、平均RU/秒 | リクエストユニット (RU) は、クエリまたはトランザクションのリソース消費を追跡するために使用される測定単位です。 `Total RU per second` 1秒あたりのリアルタイム RU 消費量を表示します。 `AVG RU/s`選択した時間範囲における 1秒あたりの平均 RU 消費量を表示し、リソース消費量をよりよく理解するのに役立ちます。実行するクエリに加えて、バックグラウンド アクティビティも RU を消費する可能性があります。そのため、QPS が 0 の場合でも、1秒あたりの RU 消費量は 0 を超える場合があります。 | +| 1秒あたりのリクエストユニット数 | 1秒あたりの合計RU、平均RU/秒 | リクエストユニット (RU) は、クエリまたはトランザクションのリソース消費を追跡するために使用される測定単位です。 `Total RU per second` 1秒あたりのリアルタイム RU 消費量を表示します。 `AVG RU/s`は選択した時間範囲における 1秒あたりの平均 RU 消費量を表示し、リソース消費量をよりよく理解するのに役立ちます。実行するクエリに加えて、バックグラウンド アクティビティも RU を消費する可能性があります。そのため、QPS が 0 の場合でも、1秒あたりの RU 消費量は 0 を超える場合があります。 | | 使用済みストレージサイズ | {タイプ} | 行ストアのサイズと列ストアのサイズ。 | | 1秒あたりのクエリ数 | すべて、{SQLタイプ} | 1秒あたりに実行される SQL ステートメントの数。これは、 `SELECT` 、 `INSERT` 、 `UPDATE`などの SQL タイプごとに収集されます。 | | クエリ実行時間 | avg、avg-{SQLタイプ}、99、99-{SQLタイプ} | クライアントからTiDBへのリクエストを受信して​​から、TiDBがリクエストを実行し、結果をクライアントに返すまでの時間。 | diff --git a/tidb-cloud/premium/import-with-mysql-cli-premium.md b/tidb-cloud/premium/import-with-mysql-cli-premium.md index 21cb831042b60..d3770eda66023 100644 --- a/tidb-cloud/premium/import-with-mysql-cli-premium.md +++ b/tidb-cloud/premium/import-with-mysql-cli-premium.md @@ -9,7 +9,7 @@ summary: MySQLコマンドラインクライアント（mysql`）を使用して > **Tip:** > -> - 論理インポートは、比較的小さな SQL ファイルまたは CSV ファイルに最適です。クラウドストレージからのより高速な並列インポート、または[Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)エクスポートからの複数のファイルの処理については、 [クラウドストレージからCSVファイルをTiDB Cloud Premiumにインポートする](/tidb-cloud/premium/import-csv-files-premium.md)インポートするを参照してください。 +> - 論理インポートは、比較的小さな SQL ファイルまたは CSV ファイルに最適です。クラウドストレージからのより高速な並列インポート、または[Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)エクスポートからの複数のファイルの処理については、 [クラウドストレージからCSVファイルをTiDB Cloud Premiumにインポートする](/tidb-cloud/premium/import-csv-files-premium.md)を参照してください。 > - TiDB Cloud StarterまたはEssentialについては、 [MySQL CLI を介してTiDB Cloud StarterまたはEssentialにデータをインポートする](/tidb-cloud/import-with-mysql-cli-serverless.md)を参照してください。 > - TiDB Cloud Dedicatedについては、 [MySQL CLI を介してTiDB Cloud Dedicatedにデータをインポートする](/tidb-cloud/import-with-mysql-cli.md)を参照してください。 diff --git a/tidb-cloud/releases/release-notes-2022.md b/tidb-cloud/releases/release-notes-2022.md index 37a399674ef43..dc55a903fe4f7 100644 --- a/tidb-cloud/releases/release-notes-2022.md +++ b/tidb-cloud/releases/release-notes-2022.md @@ -463,7 +463,7 @@ summary: 2022年のTiDB Cloudのリリースノートについて説明します ## 2022年7月19日 {#july-19-2022} -- [TiKVノードサイズ](/tidb-cloud/size-your-cluster.md#tikv-vcpu-and-ram) : `8 vCPU, 32 GiB`の新しいオプションを提供します。8 vCPU TiKVノードの場合は、 `8 vCPU, 32 GiB`または`8 vCPU, 64 GiB`選択できます。 +- [TiKVノードサイズ](/tidb-cloud/size-your-cluster.md#tikv-vcpu-and-ram) : `8 vCPU, 32 GiB`の新しいオプションを提供します。8 vCPU TiKVノードの場合は、 `8 vCPU, 32 GiB`または`8 vCPU, 64 GiB`を選択できます。 - [**TiDBに接続する**](/tidb-cloud/connect-via-standard-connection.md)ダイアログに提供されるサンプルコードで構文のハイライト表示をサポートし、コードの可読性を向上させました。サンプルコード内で置換が必要なパラメータを簡単に特定できます。 - [**データインポートタスク**](/tidb-cloud/import-sample-data.md)ページでインポートタスクを確認した後、 TiDB Cloud がソースデータにアクセスできるかどうかを自動的に検証することをサポートします。 - TiDB Cloudコンソールのテーマ カラーを[PingCAPウェブサイト](https://www.pingcap.com/)のテーマ カラーと一致するように変更します。 diff --git a/tidb-cloud/releases/release-notes-2025.md b/tidb-cloud/releases/release-notes-2025.md index 246a3a104b869..efb2e9eef3a65 100644 --- a/tidb-cloud/releases/release-notes-2025.md +++ b/tidb-cloud/releases/release-notes-2025.md @@ -493,7 +493,7 @@ summary: 2025年のTiDB Cloudのリリースノートについて説明します - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)の TiKV スケーリング プロセスを改善して、クラスターの安定性を強化します。 - TiKV ノードの[vCPUとRAMのサイズを変更する](/tidb-cloud/scale-tidb-cluster.md#change-vcpu-and-ram)追加すると、 TiDB Cloud は、クラスターの内部サービスに新しい構成をサポートするために追加の容量が必要かどうかを自動的に確認します。 + TiKV ノードの[vCPUとRAMのサイズを変更する](/tidb-cloud/scale-tidb-cluster.md#change-vcpu-and-ram)と、 TiDB Cloud は、クラスターの内部サービスに新しい構成をサポートするために追加の容量が必要かどうかを自動的に確認します。 - 拡張が必要な​​場合は、 TiDB Cloud は続行する前に確認を求めます。 - スケーリング後の現在の内部サービス容量がすでに必要なサイズよりも大きい場合、 TiDB Cloud は、クラスターの安定性に影響を与える可能性のある不要な変更を回避するために、内部サービスの既存の構成を保持します。 diff --git a/tidb-cloud/serverless-faqs.md b/tidb-cloud/serverless-faqs.md index 748f8942ef4ee..8709396b85d24 100644 --- a/tidb-cloud/serverless-faqs.md +++ b/tidb-cloud/serverless-faqs.md @@ -108,7 +108,7 @@ TiDB Cloud Starter クラスターに月間使用制限が設定されている ### 無料プランの制限は何ですか? {#what-are-the-limitations-of-the-free-plan} -無料プランでは、スケーラブルでないリソースのため、クラスターのパフォーマンスが制限されます。そのため、クエリあたりのメモリ割り当てが256MiBに制限され、1秒あたりのリクエストユニット（RU）に顕著なボトルネックが発生する可能性があります。クラスターのパフォーマンスを最大化し、これらの制限を回避するには、 TiDB Cloud Starterクラスターに[毎月の支出限度額を設定する](/tidb-cloud/manage-serverless-spend-limit.md)追加できます。 +無料プランでは、スケーラブルでないリソースのため、クラスターのパフォーマンスが制限されます。そのため、クエリあたりのメモリ割り当てが256MiBに制限され、1秒あたりのリクエストユニット（RU）に顕著なボトルネックが発生する可能性があります。クラスターのパフォーマンスを最大化し、これらの制限を回避するには、 TiDB Cloud Starterクラスターに[毎月の支出限度額を設定する](/tidb-cloud/manage-serverless-spend-limit.md)ことができます。 ### ワークロードに必要な RU の数を見積もって、月間予算を計画するにはどうすればよいですか? {#how-can-i-estimate-the-number-of-rus-required-by-my-workloads-and-plan-my-monthly-budget} diff --git a/tidb-cloud/serverless-limitations.md b/tidb-cloud/serverless-limitations.md index 8f123ed391464..8455623c6d758 100644 --- a/tidb-cloud/serverless-limitations.md +++ b/tidb-cloud/serverless-limitations.md @@ -64,7 +64,7 @@ TiDB Cloud Starter/EssentialとTiDB Cloud Dedicated間の機能ギャップを ## 使用量制限 {#usage-quota} -TiDB Cloudでは、組織ごとに最大5つのクラスター（デフォルトでは[無料のTiDB Cloud Starterクラスター](/tidb-cloud/select-cluster-tier.md#starter)を作成できます。TiDB Cloud Starterクラスターをさらに作成するには、クレジットカード情報と使用量に応じた[毎月の支出限度額を設定する](/tidb-cloud/manage-serverless-spend-limit.md)追加する必要があります。 +TiDB Cloudでは、組織ごとに最大5つのクラスター（デフォルトでは[無料のTiDB Cloud Starterクラスター](/tidb-cloud/select-cluster-tier.md#starter)を作成できます。TiDB Cloud Starterクラスターをさらに作成するには、クレジットカード情報と使用量に応じた[毎月の支出限度額を設定する](/tidb-cloud/manage-serverless-spend-limit.md)を追加する必要があります。 組織内の最初の 5つのTiDB Cloud Starter クラスターについては、 TiDB Cloud は次のようにクラスターごとに無料使用量割り当てを提供します。 diff --git a/tidb-cloud/set-up-vpc-peering-connections.md b/tidb-cloud/set-up-vpc-peering-connections.md index 72bac4c81de7a..f069d79c82058 100644 --- a/tidb-cloud/set-up-vpc-peering-connections.md +++ b/tidb-cloud/set-up-vpc-peering-connections.md @@ -9,7 +9,7 @@ summary: VPC ピアリング経由でTiDB Cloud Dedicated に接続する方法 > > VPC ピアリング接続は、AWS および Google Cloud でホストされているTiDB Cloud Dedicated クラスターでのみ利用できます。 -アプリケーションをVPCピアリング経由でTiDB Cloudに接続するには、 TiDB Cloudで[VPCピアリング](/tidb-cloud/tidb-cloud-glossary.md#vpc-peering)設定する必要があります。このドキュメントでは、VPCピアリング接続[AWS上](#set-up-vpc-peering-on-aws)と[Google Cloudで](#set-up-vpc-peering-on-google-cloud)設定と、VPCピアリング経由でTiDB Cloudに接続する手順について説明します。 +アプリケーションをVPCピアリング経由でTiDB Cloudに接続するには、 TiDB Cloudで[VPCピアリング](/tidb-cloud/tidb-cloud-glossary.md#vpc-peering)を設定する必要があります。このドキュメントでは、VPCピアリング接続[AWS上](#set-up-vpc-peering-on-aws)と[Google Cloudで](#set-up-vpc-peering-on-google-cloud)設定と、VPCピアリング経由でTiDB Cloudに接続する手順について説明します。 VPCピアリングは、2つのVPC間のネットワーク接続であり、プライベートIPアドレスを使用してトラフィックをルーティングできます。どちらのVPC内のインスタンスも、同じネットワーク内にあるかのように相互に通信できます。 @@ -17,7 +17,7 @@ VPCピアリングは、2つのVPC間のネットワーク接続であり、プ > **Tip:** > -> アプリケーションをTiDB Cloudに接続するには、 TiDB Cloudで[プライベートエンドポイント接続](/tidb-cloud/set-up-private-endpoint-connections.md)設定することもできます。TiDB Cloudは安全でプライベートであり、データがパブリックインターネットに公開されることはありません。VPCピアリング接続ではなく、プライベートエンドポイントを使用することをお勧めします。 +> アプリケーションをTiDB Cloudに接続するには、 TiDB Cloudで[プライベートエンドポイント接続](/tidb-cloud/set-up-private-endpoint-connections.md)を設定することもできます。TiDB Cloudは安全でプライベートであり、データがパブリックインターネットに公開されることはありません。VPCピアリング接続ではなく、プライベートエンドポイントを使用することをお勧めします。 ## 前提条件: リージョンの CIDR を設定する {#prerequisite-set-a-cidr-for-a-region} diff --git a/tidb-cloud/terraform-use-serverless-branch-resource.md b/tidb-cloud/terraform-use-serverless-branch-resource.md index 9381a81f2f76d..1170643009aab 100644 --- a/tidb-cloud/terraform-use-serverless-branch-resource.md +++ b/tidb-cloud/terraform-use-serverless-branch-resource.md @@ -5,7 +5,7 @@ summary: サーバーレス ブランチ リソースを使用して、 TiDB Clo # `tidbcloud_serverless_branch`リソースを使用する {#use-the-tidbcloud-serverless-branch-resource} -このドキュメントでは、 `tidbcloud_serverless_branch`リソースを使用して[TiDB Cloud Starter またはTiDB Cloud Essential ブランチ](/tidb-cloud/branch-manage.md)管理する方法について説明します。 +このドキュメントでは、 `tidbcloud_serverless_branch`リソースを使用して[TiDB Cloud Starter またはTiDB Cloud Essential ブランチ](/tidb-cloud/branch-manage.md)を管理する方法について説明します。 `tidbcloud_serverless_branch`リソースの機能は次のとおりです。 diff --git a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md index 59a43fe4b09f5..b90699ca514ef 100644 --- a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md +++ b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md @@ -151,7 +151,7 @@ TiDB Cloudコンソールまたは API を使用して、プロジェクトの C ## CMEKを回転させる {#rotate-cmek} -AWS KMS で[自動CMEKローテーション](http://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)設定できます。このローテーションを有効にすると、 TiDB Cloudのプロジェクト設定で CMEK ID を含む**Encryption Access**を更新する必要はありません。 +AWS KMS で[自動CMEKローテーション](http://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)を設定できます。このローテーションを有効にすると、 TiDB Cloudのプロジェクト設定で CMEK ID を含む**Encryption Access**を更新する必要はありません。 ## CMEK を取り消して復元する {#revoke-and-restore-cmek} diff --git a/tidb-cloud/use-chat2query-api.md b/tidb-cloud/use-chat2query-api.md index 2f20efb2f1646..125263cd7b65e 100644 --- a/tidb-cloud/use-chat2query-api.md +++ b/tidb-cloud/use-chat2query-api.md @@ -240,7 +240,7 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request GET 'https://v7.3.0で追加 {#enable-32bits-connection-id-new-in-v730} diff --git a/tidb-distributed-execution-framework.md b/tidb-distributed-execution-framework.md index 31cc527393737..6f1cf6c0a4d70 100644 --- a/tidb-distributed-execution-framework.md +++ b/tidb-distributed-execution-framework.md @@ -91,17 +91,17 @@ DXF を使用して[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)タ ## タスクのスケジュール {#task-scheduling} -デフォルトでは、DXFはすべてのTiDBノードを分散タスクの実行対象としてスケジュールします。v7.4.0以降、TiDB Self-Managedクラスターでは、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)設定することで、DXFが分散タスクの実行対象としてスケジュールするTiDBノードを制御できます。 +デフォルトでは、DXFはすべてのTiDBノードを分散タスクの実行対象としてスケジュールします。v7.4.0以降、TiDB Self-Managedクラスターでは、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)を設定することで、DXFが分散タスクの実行対象としてスケジュールするTiDBノードを制御できます。 - バージョンv7.4.0からv8.0.0までの場合、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)のオプション値は`''`または`background`です。現在のクラスターに`tidb_service_scope = 'background'`のTiDBノードがある場合、DXFはこれらのノードにタスクの実行をスケジュールします。障害または通常のスケールインにより、現在のクラスターに`tidb_service_scope = 'background'` TiDBノードがない場合、DXFは`tidb_service_scope = ''`のノードにタスクの実行をスケジュールします。 - v8.1.0以降では、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)任意の有効な値に設定できます。分散タスクが送信されると、タスクは現在接続されているTiDBノードの[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)値にバインドされ、DXFは同じ[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)値を持つTiDBノードにのみタスクの実行をスケジュールします。ただし、以前のバージョンとの設定互換性を保つため、分散タスクが`tidb_service_scope = ''`ノードに送信され、現在のクラスターに`tidb_service_scope = 'background'`のTiDBノードがある場合、DXFは`tidb_service_scope = 'background'`のTiDBノードにタスクの実行をスケジュールします。 -v8.1.0以降、タスク実行中に新しいノードが追加された場合、DXFは前述のルールに基づいて、新しいノードにタスクを実行するかどうかをスケジュールするかどうかを決定します。新しく追加されたノードにタスクを実行させたくない場合は、事前にそれらのノードに異なる[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)設定することをお勧めします。 +v8.1.0以降、タスク実行中に新しいノードが追加された場合、DXFは前述のルールに基づいて、新しいノードにタスクを実行するかどうかをスケジュールするかどうかを決定します。新しく追加されたノードにタスクを実行させたくない場合は、事前にそれらのノードに異なる[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)を設定することをお勧めします。 > **Note:** > -> - バージョンv7.4.0からv8.0.0まで、複数のTiDBノードを持つクラスターでは、2つ以上のTiDBノードで[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)から`background`設定することを強くお勧めします。この変数を1つのTiDBノードにのみ設定した場合、そのノードが再起動または障害を起こした場合、タスクは`tidb_service_scope = ''`が設定されているTiDBノードに再スケジュールされ、これらのTiDBノードで実行されているアプリケーションに影響を及ぼします。 +> - バージョンv7.4.0からv8.0.0まで、複数のTiDBノードを持つクラスターでは、2つ以上のTiDBノードで[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)を`background`に設定することを強くお勧めします。この変数を1つのTiDBノードにのみ設定した場合、そのノードが再起動または障害を起こした場合、タスクは`tidb_service_scope = ''`が設定されているTiDBノードに再スケジュールされ、これらのTiDBノードで実行されているアプリケーションに影響を及ぼします。 > - 分散タスクの実行中、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)構成への変更は現在のタスクには適用されませんが、次のタスクからは適用されます。 ## 実装原理 {#implementation-principles} diff --git a/tidb-external-ts.md b/tidb-external-ts.md index 108c18001cad9..a1e10b80ea67d 100644 --- a/tidb-external-ts.md +++ b/tidb-external-ts.md @@ -9,7 +9,7 @@ summary: tidb_external_ts` 変数を使用して履歴データを読み取る ## シナリオ {#scenarios} -指定した時点からの履歴データの読み取りは、TiCDCなどのデータレプリケーションツールにとって非常に便利です。データレプリケーションツールが特定の時点より前のデータレプリケーションを完了した後、下流TiDBのシステム変数`tidb_external_ts`設定することで、その時点より前のデータを読み取ることができます。これにより、データレプリケーションによるデータの不整合を防ぐことができます。 +指定した時点からの履歴データの読み取りは、TiCDCなどのデータレプリケーションツールにとって非常に便利です。データレプリケーションツールが特定の時点より前のデータレプリケーションを完了した後、下流TiDBのシステム変数`tidb_external_ts`を設定することで、その時点より前のデータを読み取ることができます。これにより、データレプリケーションによるデータの不整合を防ぐことができます。 ## 機能の説明 {#feature-description} @@ -17,7 +17,7 @@ summary: tidb_external_ts` 変数を使用して履歴データを読み取る システム変数[`tidb_enable_external_ts_read`](/system-variables.md#tidb_enable_external_ts_read-new-in-v640) 、履歴データを現在のセッションで読み取るか、グローバルで読み取るかを制御します。デフォルト値は`OFF`で、履歴データの読み取り機能は無効であり、 `tidb_external_ts`は無視されます。`tidb_enable_external_ts_read`はグローバルに`ON`に設定すると、すべてのクエリは`tidb_external_ts`で指定された時刻より前に履歴データを読み取ります。`tidb_enable_external_ts_read`は特定のセッションのみ`ON`に設定すると、そのセッションのクエリのみが履歴データを読み取ります。 -`tidb_enable_external_ts_read`有効にすると、TiDB は読み取り専用になります。すべての書き込みクエリは`ERROR 1836 (HY000): Running in read-only mode`ようなエラーで失敗します。 +`tidb_enable_external_ts_read`を有効にすると、TiDB は読み取り専用になります。すべての書き込みクエリは`ERROR 1836 (HY000): Running in read-only mode`ようなエラーで失敗します。 ## 使用例 {#usage-examples} @@ -110,4 +110,4 @@ summary: tidb_external_ts` 変数を使用して履歴データを読み取る 3 rows in set (0.00 sec) ``` - 新しい行が挿入される前にタイムスタンプに`tidb_external_ts`設定されるため、 `tidb_enable_external_ts_read`有効になった後は新しく挿入された行は返されません。 + 新しい行が挿入される前にタイムスタンプに`tidb_external_ts`が設定されるため、 `tidb_enable_external_ts_read`有効になった後は新しく挿入された行は返されません。 diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index ebd26ddde0e05..c3c455c959d9c 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -193,7 +193,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `precheck-conflict-before-import` {#precheck-conflict-before-import} - インポート前の競合検出を有効にするかどうかを制御します。これは、TiDBにインポートする前にデータの競合をチェックします。このパラメータは、物理インポートモードでのみ使用できます。 -- 競合レコードの数が 1,000,000 を超えるシナリオでは、競合検出のパフォーマンスを向上させるために`precheck-conflict-before-import = true`設定することをお勧めします。 +- 競合レコードの数が 1,000,000 を超えるシナリオでは、競合検出のパフォーマンスを向上させるために`precheck-conflict-before-import = true`を設定することをお勧めします。 - その他のシナリオでは、無効にすることをお勧めします。 - デフォルト値: `false` - 値のオプション: diff --git a/tidb-lightning/tidb-lightning-logical-import-mode.md b/tidb-lightning/tidb-lightning-logical-import-mode.md index 13a1614f542a8..8da87d8b92190 100644 --- a/tidb-lightning/tidb-lightning-logical-import-mode.md +++ b/tidb-lightning/tidb-lightning-logical-import-mode.md @@ -15,7 +15,7 @@ TiDBクラスターに既にデータが含まれており、外部アプリケ **オペレーティング·システム**： -CentOS 7の新規インスタンスの使用をお勧めします。仮想マシンはローカルホストまたはクラウドにデプロイできます。TiDB Lightningはデフォルトで必要なCPUリソースを消費するため、専用サーバーにデプロイすることをお勧めします。これが不可能な場合は、他のTiDBコンポーネント（例：tikv-server）と一緒に単一のサーバーにデプロイし、 TiDB LightningからのCPU使用量を制限するように`region-concurrency`設定できます。通常、サイズは論理CPUの75%に設定できます。 +CentOS 7の新規インスタンスの使用をお勧めします。仮想マシンはローカルホストまたはクラウドにデプロイできます。TiDB Lightningはデフォルトで必要なCPUリソースを消費するため、専用サーバーにデプロイすることをお勧めします。これが不可能な場合は、他のTiDBコンポーネント（例：tikv-server）と一緒に単一のサーバーにデプロイし、 TiDB LightningからのCPU使用量を制限するように`region-concurrency`を設定できます。通常、サイズは論理CPUの75%に設定できます。 **メモリとCPU** : diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md index ac82fa2baec2b..e512b7ef851bb 100644 --- a/tidb-lightning/troubleshoot-tidb-lightning.md +++ b/tidb-lightning/troubleshoot-tidb-lightning.md @@ -46,7 +46,7 @@ strict-format = true [2018/08/10 07:29:08.310 +08:00] [INFO] [main.go:41] ["got signal to exit"] [signal=hangup] ``` -コマンドラインで直接`nohup`を使用して`tidb-lightning`起動することは推奨されません。スクリプトを実行することで[`tidb-lightning`を起動する](/get-started-with-tidb-lightning.md#step-4-start-tidb-lightning)起動できます。 +コマンドラインで直接`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が割り込み信号を受信して終了したことを示しています。 diff --git a/tidb-read-staleness.md b/tidb-read-staleness.md index 2a673a1424717..7638441700bdc 100644 --- a/tidb-read-staleness.md +++ b/tidb-read-staleness.md @@ -11,7 +11,7 @@ summary: tidb_read_staleness` システム変数を使用して履歴データ システム変数`tidb_read_staleness` 、TiDB が現在のセッションで読み取ることができる履歴データの時間範囲を設定するために使用されます。この変数のデータ型は int 型で、スコープは`SESSION`です。値を設定すると、TiDB はこの変数で許可された範囲から可能な限り新しいタイムスタンプを選択し、以降のすべての読み取り操作はこのタイムスタンプに対して実行されます。例えば、この変数の値が`-5`に設定されている場合、TiKV に対応する履歴バージョンのデータが存在するという条件で、TiDB は 5秒の時間範囲内で可能な限り新しいタイムスタンプを選択します。 -`tidb_read_staleness`有効にした後でも、次の操作を実行できます。 +`tidb_read_staleness`を有効にした後でも、次の操作を実行できます。 - 現在のセッションでデータの挿入、変更、削除、またはDML操作を実行します。これらの文は`tidb_read_staleness`の影響を受けません。 - 現在のセッションで対話型トランザクションを開始します。このトランザクション内のクエリは最新のデータを読み取ります。 diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index cf4270bdd747e..ffbeb0692f00d 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -92,7 +92,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 - `PLAN DIGEST`は`PLAN`と同じです。次のパラメータはダイジェスト文字列です。 - `SQL TEXT`入力SQLを生の文字列（ `EXACT` ）として一致させるか、次のパラメータに応じて`SQL DIGEST` （ `SIMILAR` ）または`PLAN DIGEST` （ `PLAN` ）に解析してコンパイルします。 -- デフォルトのリソースグループのランナウェイクエリ監視リストに一致する機能を追加します (事前にデフォルトのリソースグループに`QUERY LIMIT`設定する必要があります)。 +- デフォルトのリソースグループのランナウェイクエリ監視リストに一致する機能を追加します (事前にデフォルトのリソースグループに`QUERY LIMIT`を設定する必要があります)。 ```sql QUERY WATCH ADD ACTION KILL SQL TEXT EXACT TO 'select * from test.t2'; diff --git a/tidb-scheduling.md b/tidb-scheduling.md index 43e8ddfa9c9ea..b1419bc0de457 100644 --- a/tidb-scheduling.md +++ b/tidb-scheduling.md @@ -122,7 +122,7 @@ PDは、リージョンリーダーのハートビートから、リージョン - TiKV ピアは複数のラックに配置されており、ラックに障害が発生してもシステムは利用可能であると予想されます。 - TiKV ピアは複数のデータセンターにあり、データセンターに障害が発生した場合でもシステムは利用可能であると予想されます。 -これらの要件の鍵となるのは、ピアが同じ「ポジション」を持つことができることです。これは、障害耐性の最小単位です。リージョンのレプリカは、同じユニットに存在してはなりません。そこで、TiKVピアに[ラベル](https://github.com/tikv/tikv/blob/v4.0.0-beta/etc/config-template.toml#L140)設定し、PDに[場所ラベル](https://github.com/pingcap/pd/blob/v4.0.0-beta/conf/config.toml#L100)設定することで、ポジションのマーキングに使用するラベルを指定できます。 +これらの要件の鍵となるのは、ピアが同じ「ポジション」を持つことができることです。これは、障害耐性の最小単位です。リージョンのレプリカは、同じユニットに存在してはなりません。そこで、TiKVピアに[ラベル](https://github.com/tikv/tikv/blob/v4.0.0-beta/etc/config-template.toml#L140)を設定し、PDに[場所ラベル](https://github.com/pingcap/pd/blob/v4.0.0-beta/conf/config.toml#L100)を設定することで、ポジションのマーキングに使用するラベルを指定できます。 **戦略3: レプリカはストア間でバランスをとる必要がある** diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index d65e48b408d8f..623ca2c7fb416 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -450,7 +450,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - `region-concurrency`設定値が高すぎるため、スレッド競合が発生し、パフォーマンスが低下します。トラブルシューティング方法は次の3つです。 - - 設定は、ログの先頭から`region-concurrency`検索することで見つけることができます。 + - 設定は、ログの先頭から`region-concurrency`を検索することで見つけることができます。 - TiDB Lightning が他のサービス (たとえば Importer) とサーバーを共有している場合は、 `region-concurrency`そのサーバーの CPU コアの総数の 75% に手動で設定する必要があります。 - CPU にクォータが設定されている場合 (例えば、Kubernetes の設定によって制限されている場合)、 TiDB Lightning はこの値を読み取れない可能性があります。この場合、 `region-concurrency`も手動で減らす必要があります。 diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 5999f0131c881..1e8a4ab663909 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -393,7 +393,7 @@ I/O トラフィック制限設定を構成します。 ##### `manual_compact_pool_size`バージョン6.1の新機能 {#manual_compact_pool_size-new-in-v61} -- TiFlash がTiDB から`ALTER TABLE ... COMPACT`受信したときに同時に処理できる要求の数を指定します。 +- TiFlash がTiDB から`ALTER TABLE ... COMPACT`を受信したときに同時に処理できる要求の数を指定します。 - 値が`0`に設定されている場合、デフォルト値`1`が優先されます。 - デフォルト値: `1` @@ -469,7 +469,7 @@ I/O トラフィック制限設定を構成します。 - 構成項目が`false`または`"off"`に設定されている場合、ログの秘匿化は無効になります。 - 構成項目が`true`または`"on"`に設定されている場合、ログ内のすべてのユーザーデータは`?`に置き換えられます。 - 設定項目を`"marker"`に設定すると、ログ内のすべてのユーザーデータは`‹ ›`で囲まれます。ユーザーデータに`‹`または`›`が含まれている場合、 `‹`は`‹‹`に、 `›`は`››`にエスケープされます。マークされたログに基づいて、ログを表示する際にマークされた情報を非感度化するかどうかを決定できます。 -- [`tiflash-learner.toml`](#configure-the-tiflash-learnertoml-file)での tiflash-learner のログインにも`security.redact-info-log`設定する必要があることに注意してください。 +- [`tiflash-learner.toml`](#configure-the-tiflash-learnertoml-file)での tiflash-learner のログインにも`security.redact-info-log`を設定する必要があることに注意してください。 ##### `ca_path` {#ca_path} diff --git a/tiflash/tiflash-spill-disk.md b/tiflash/tiflash-spill-disk.md index 0b6fdcc881b7f..7a037626bc4b7 100644 --- a/tiflash/tiflash-spill-disk.md +++ b/tiflash/tiflash-spill-disk.md @@ -72,7 +72,7 @@ TiFlash は、データをディスクに書き出すための 2つのトリガ HAVING SUM(l_quantity) > 314; ``` -5. TiFlashのログを見ると、 `tidb_max_bytes_before_tiflash_external_group_by`設定するとTiFlash が中間結果のスピルをトリガーし、クエリで使用されるメモリが大幅に削減されることがわかります。 +5. TiFlashのログを見ると、 `tidb_max_bytes_before_tiflash_external_group_by`を設定するとTiFlash が中間結果のスピルをトリガーし、クエリで使用されるメモリが大幅に削減されることがわかります。 ``` [DEBUG] [MemoryTracker.cpp:69] ["Peak memory usage (total): 12.80 GiB."] [source=MemoryTracker] [thread_id=110] diff --git a/tiflash/troubleshoot-tiflash.md b/tiflash/troubleshoot-tiflash.md index 96785e4d48a57..c90450e79718a 100644 --- a/tiflash/troubleshoot-tiflash.md +++ b/tiflash/troubleshoot-tiflash.md @@ -238,9 +238,9 @@ TiFlashノードをデプロイし、 `ALTER TABLE ... SET TIFLASH REPLICA ...` TiDB DDL 所有者のログを検索し、TiDB が PD に配置ルールを追加するように通知したかどうかを確認します。 - - パーティション化されていないテーブルの場合は、 `ConfigureTiFlashPDForTable`検索します。 + - パーティション化されていないテーブルの場合は、 `ConfigureTiFlashPDForTable`を検索します。 - - パーティション化されたテーブルの場合は、 `ConfigureTiFlashPDForPartitions`検索します。 + - パーティション化されたテーブルの場合は、 `ConfigureTiFlashPDForPartitions`を検索します。 - キーワードが見つかった場合は、次のステップに進みます。 diff --git a/tiflash/use-fastscan.md b/tiflash/use-fastscan.md index c12444b40a857..0f0be0ee73f61 100644 --- a/tiflash/use-fastscan.md +++ b/tiflash/use-fastscan.md @@ -9,7 +9,7 @@ summary: FastScan を使用して OLAP シナリオでのクエリを高速化 TiFlash はデフォルトでクエリ結果の精度とデータの一貫性を保証します。FastScan 機能を使用すると、 TiFlash はより効率的なクエリパフォーマンスを提供しますが、クエリ結果の精度とデータの一貫性は保証されません。 -一部のOLAPシナリオでは、クエリ結果の精度に多少の許容範囲が認められます。このような場合、より高いクエリパフォーマンスが必要な場合は、セッションレベルまたはグローバルレベルでFastScan機能を有効にできます。FastScan機能を有効にするかどうかは、変数[`tiflash_fastscan`](/system-variables.md#tiflash_fastscan-new-in-v630)設定することで選択できます。 +一部のOLAPシナリオでは、クエリ結果の精度に多少の許容範囲が認められます。このような場合、より高いクエリパフォーマンスが必要な場合は、セッションレベルまたはグローバルレベルでFastScan機能を有効にできます。FastScan機能を有効にするかどうかは、変数[`tiflash_fastscan`](/system-variables.md#tiflash_fastscan-new-in-v630)を設定することで選択できます。 ## 制限 {#restrictions} @@ -78,7 +78,7 @@ show global variables like 'tiflash_fastscan'; set session tiflash_fastscan=ON; ``` -グローバルレベルで`tiflash_fastscan`設定することもできます。新しい設定は新しいセッションで有効になりますが、現在のセッションと以前のセッションには適用されません。また、新しいセッションでは、セッションレベルとグローバルレベルの両方の`tiflash_fastscan`に新しい値が設定されます。 +グローバルレベルで`tiflash_fastscan`を設定することもできます。新しい設定は新しいセッションで有効になりますが、現在のセッションと以前のセッションには適用されません。また、新しいセッションでは、セッションレベルとグローバルレベルの両方の`tiflash_fastscan`に新しい値が設定されます。 ``` set global tiflash_fastscan=ON; diff --git a/tiflash/use-tiflash-mpp-mode.md b/tiflash/use-tiflash-mpp-mode.md index ab668fc94171d..1430242a9fd66 100644 --- a/tiflash/use-tiflash-mpp-mode.md +++ b/tiflash/use-tiflash-mpp-mode.md @@ -115,7 +115,7 @@ TiFlash は、ブロードキャスト ハッシュ結合を使用するかど ## MPP モードでパーティションテーブルにアクセスする {#access-partitioned-tables-in-the-mpp-mode} -MPP モードでパーティションテーブルにアクセスするには、まず[動的剪定モード](https://docs.pingcap.com/tidb/stable/partitioned-table#dynamic-pruning-mode)有効にする必要があります。 +MPP モードでパーティションテーブルにアクセスするには、まず[動的剪定モード](https://docs.pingcap.com/tidb/stable/partitioned-table#dynamic-pruning-mode)を有効にする必要があります。 例： diff --git a/tikv-control.md b/tikv-control.md index 6a46e95694327..1b1484ec95eba 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -251,7 +251,7 @@ key: zmDB:29\000\000\377\000\374\000\000\000\000\000\000\377\000H\000\000\000\00 ### 生のキーをスキャンする {#scan-raw-keys} -`raw-scan`コマンドはRocksDBから直接スキャンします。データキーをスキャンするには、キーの先頭に`'z'`追加する必要があることに注意してください。 +`raw-scan`コマンドはRocksDBから直接スキャンします。データキーをスキャンするには、キーの先頭に`'z'`を追加する必要があることに注意してください。 `--from`と`--to`オプションを使用して`write`スキャンする範囲を指定します（デフォルトでは無制限） `--limit`を使用すると、出力するキーの最大数を制限します（デフォルトでは30） `--cf`を使用すると、スキャンする cf を指定します（ `default` 、 `write` 、または`lock` ）。 diff --git a/tikv-in-memory-engine.md b/tikv-in-memory-engine.md index 90a32dab5880a..0e5b2838a2822 100644 --- a/tikv-in-memory-engine.md +++ b/tikv-in-memory-engine.md @@ -10,7 +10,7 @@ TiKV MVCC インメモリエンジン (IME) は、主に多数の MVCC 履歴バ TiKV MVCCインメモリエンジンは、以下のシナリオに適しています。 - 頻繁に更新または削除されるレコードを照会する必要があるアプリケーション。 -- TiDBに履歴バージョンをより長い期間（例えば24時間）保持するために、 [`tidb_gc_life_time`](/garbage-collection-configuration.md#garbage-collection-configuration)調整する必要があるアプリケーション。 +- TiDBに履歴バージョンをより長い期間（例えば24時間）保持するために、 [`tidb_gc_life_time`](/garbage-collection-configuration.md#garbage-collection-configuration)を調整する必要があるアプリケーション。 ## 実装原理 {#implementation-principles} diff --git a/tiproxy/tiproxy-command-line-flags.md b/tiproxy/tiproxy-command-line-flags.md index 4a85184321500..ff893e6cfe071 100644 --- a/tiproxy/tiproxy-command-line-flags.md +++ b/tiproxy/tiproxy-command-line-flags.md @@ -39,7 +39,7 @@ TiProxy Control は、次の2つの方法のいずれかを使用してインス #### TiUPを使用してインストール {#install-using-tiup} -[TiUP](/tiup/tiup-overview.md)インストールした後、 `tiup install tiproxy`コマンドを使用して TiProxy と TiProxy Control のバイナリプログラムをダウンロードしてインストールできます。インストール後、 `tiup --binary tiproxy`コマンドを使用して TiProxy のインストールパスを確認できます。TiProxy Control は TiProxy と同じディレクトリにあります。 +[TiUP](/tiup/tiup-overview.md)をインストールした後、 `tiup install tiproxy`コマンドを使用して TiProxy と TiProxy Control のバイナリプログラムをダウンロードしてインストールできます。インストール後、 `tiup --binary tiproxy`コマンドを使用して TiProxy のインストールパスを確認できます。TiProxy Control は TiProxy と同じディレクトリにあります。 例えば： diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index 8df32ec44df5e..e1b365ff9e5dc 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -91,7 +91,7 @@ SQL ポートのコンフィグレーション。 - デフォルト値: `""` - ホットリロードのサポート: はい、ただし新規接続のみ - 可能な`"v2"` : `""` -- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にしてください。PROXYプロトコルを有効にすると、TiProxyは実際のクライアントIPアドレスをTiDBに渡すことができます。`"v2"` PROXYプロトコルバージョン2の使用を示し、 `""` PROXYプロトコルの無効化を示します。TiProxyでPROXYプロトコルが有効になっている場合は、TiDBサーバーでも[PROXYプロトコル](/tidb-configuration-file.md#proxy-protocol)有効にする必要があります。 +- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)を有効にしてください。PROXYプロトコルを有効にすると、TiProxyは実際のクライアントIPアドレスをTiDBに渡すことができます。`"v2"` PROXYプロトコルバージョン2の使用を示し、 `""` PROXYプロトコルの無効化を示します。TiProxyでPROXYプロトコルが有効になっている場合は、TiDBサーバーでも[PROXYプロトコル](/tidb-configuration-file.md#proxy-protocol)を有効にする必要があります。 ### API {#api} @@ -108,7 +108,7 @@ HTTP ゲートウェイの構成。 - デフォルト値: `""` - ホットリロードのサポート: いいえ - 可能な`"v2"` : `""` -- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にします。`"v2"` PROXY プロトコル バージョン 2 を使用することを示し、 `""` PROXY プロトコルを無効にすることを示します。 +- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)を有効にします。`"v2"` PROXY プロトコル バージョン 2 を使用することを示し、 `""` PROXY プロトコルを無効にすることを示します。 ### バランス {#balance} @@ -246,7 +246,7 @@ TLS オブジェクト フィールド: クライアント TLS オブジェクトの場合: - サーバー証明書の検証をスキップするには、 `ca`または`skip-ca`を設定する必要があります。 -- オプションで、サーバー側のクライアント検証に合格するために`cert`または`key`設定できます。 +- オプションで、サーバー側のクライアント検証に合格するために`cert`または`key`を設定できます。 - 役に立たないフィールド: 自動証明書。 サーバーTLS オブジェクトの場合: diff --git a/tiproxy/tiproxy-load-balance.md b/tiproxy/tiproxy-load-balance.md index 3617a29234bba..364b2c900efb5 100644 --- a/tiproxy/tiproxy-load-balance.md +++ b/tiproxy/tiproxy-load-balance.md @@ -40,8 +40,8 @@ TiProxy は、SQL ポートとステータスポートを使用して、TiDBサ 1. TiProxy で[`balance.label-name`](/tiproxy/tiproxy-configuration.md#label-name)を`"app"`に設定すると、TiDB サーバーはラベル名`"app"`によって照合され、接続は一致するラベル値を持つ TiDB サーバーにルーティングされます。 2. 少なくとも 2つの TiProxy インスタンスをデプロイ。トランザクション ワークロードに使用する TiProxy インスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "Order"}`に設定し、BI ワークロードに使用するインスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "BI"}`に設定します。 3. オプション：高可用性を実現するには、少なくとも4つのTiProxyインスタンスを導入し、ワークロードごとに異なる仮想IPアドレスを設定します。例えば、トランザクションワークロード用のTiProxyインスタンス2つを仮想IP `10.0.1.10/24`に設定し、BIワークロード用のインスタンス2つを仮想IP `10.0.1.20/24`に設定します。この機能を使用するには、TiProxy v1.3.1以降が必要です。 -4. TiDB インスタンスを 2つのグループに分割し、それぞれ[`labels`](/tidb-configuration-file.md#labels)設定します。一方のグループに`"app": "Order"`ラベルを追加し、もう一方のグループに`"app": "BI"`ラベルを追加します。 -5. オプション:ストレージレイヤーの分離の場合は、 [配置ルール](/configure-placement-rules.md)または[リソース管理](/tidb-resource-control-ru-groups.md)構成します。 +4. TiDB インスタンスを 2つのグループに分割し、それぞれ[`labels`](/tidb-configuration-file.md#labels)を設定します。一方のグループに`"app": "Order"`ラベルを追加し、もう一方のグループに`"app": "BI"`ラベルを追加します。 +5. オプション:ストレージレイヤーの分離の場合は、 [配置ルール](/configure-placement-rules.md)または[リソース管理](/tidb-resource-control-ru-groups.md)を構成します。 6. 仮想IPが設定されている場合、トランザクションクライアントとBIクライアントはそれぞれ2つの仮想IPアドレスに接続します。仮想IPが設定されていない場合、トランザクションクライアントとBIクライアントはそれぞれ2つのTiProxyアドレスに接続します。 ラベルベースの負荷分散 diff --git a/tiproxy/tiproxy-performance-test.md b/tiproxy/tiproxy-performance-test.md index e06226d0dfa3e..123f3011a1035 100644 --- a/tiproxy/tiproxy-performance-test.md +++ b/tiproxy/tiproxy-performance-test.md @@ -14,7 +14,7 @@ summary: TiProxy のパフォーマンスと HAProxy との比較について学 - クエリ結果セットの行数は TiProxy の QPS に大きな影響を与え、その影響は HAProxy の場合と同じです。 - TiProxy のパフォーマンスは、vCPU の数にほぼ比例して向上します。そのため、vCPU の数を増やすことで、QPS の上限を効果的に向上させることができます。 - 長い接続の数と短い接続を作成する頻度は、TiProxy の QPS にほとんど影響を与えません。 -- TiProxyのCPU使用率が高いほど、 [トラフィックキャプチャ](/tiproxy/tiproxy-traffic-replay.md)有効化した場合のQPSへの影響が大きくなります。TiProxyのCPU使用率が約70%の場合、トラフィックキャプチャを有効化すると、平均QPSが約3%、最小QPSが約7%低下します。後者の低下は、トラフィックファイルの圧縮中に発生する周期的なQPS低下によって発生します。 +- TiProxyのCPU使用率が高いほど、 [トラフィックキャプチャ](/tiproxy/tiproxy-traffic-replay.md)を有効化した場合のQPSへの影響が大きくなります。TiProxyのCPU使用率が約70%の場合、トラフィックキャプチャを有効化すると、平均QPSが約3%、最小QPSが約7%低下します。後者の低下は、トラフィックファイルの圧縮中に発生する周期的なQPS低下によって発生します。 ## テスト環境 {#test-environment} diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index 52b0070ee3fe2..13a79e240d7c6 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -50,7 +50,7 @@ TiUPを使用した TiDB デプロイメントのトポロジ構成ファイル - `deploy_dir` : 各コンポーネントの配置ディレクトリ。デフォルト値は`"deployed"`です。適用ルールは以下のとおりです。 - - インスタンスレベルで絶対パス`deploy_dir`が設定されている場合、実際のデプロイメントディレクトリはインスタンスに対して`deploy_dir`設定されます。 + - インスタンスレベルで絶対パス`deploy_dir`が設定されている場合、実際のデプロイメントディレクトリはインスタンスに対して`deploy_dir`が設定されます。 - 各インスタンスに対して`deploy_dir`設定しない場合、デフォルト値は相対パス`-`になります。 @@ -60,7 +60,7 @@ TiUPを使用した TiDB デプロイメントのトポロジ構成ファイル - `data_dir` : データディレクトリ。デフォルト値: `"data"` 。適用ルールは以下のとおりです。 - - インスタンスレベルで絶対パス`data_dir`が設定されている場合、実際のデプロイメントディレクトリはインスタンスに対して`data_dir`設定されます。 + - インスタンスレベルで絶対パス`data_dir`が設定されている場合、実際のデプロイメントディレクトリはインスタンスに対して`data_dir`が設定されます。 - 各インスタンスに対して`data_dir`設定しない場合、デフォルト値は``になります。 diff --git a/tiup/tiup-command-completion.md b/tiup/tiup-command-completion.md index d38a892c7f68c..72079015950e8 100644 --- a/tiup/tiup-command-completion.md +++ b/tiup/tiup-command-completion.md @@ -10,7 +10,7 @@ summary: TiUPは、 tiup completionコマンドを使用して、bash`および` `bash`コマンドを実行するには、まず`bash-completion`をインストールする必要があります。以下の手順をご覧ください。 - macOS の場合: bash バージョンが 4.1 より前の場合は`brew install bash-completion`を実行し、それ以外の場合は`brew install bash-completion@2`を実行します。 -- Linuxの場合：パッケージマネージャーを使用して`bash-completion`インストールします。たとえば、 `yum install bash-completion`または`apt install bash-completion`を実行します。 +- Linuxの場合：パッケージマネージャーを使用して`bash-completion`をインストールします。たとえば、 `yum install bash-completion`または`apt install bash-completion`を実行します。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-management.md b/tiup/tiup-component-management.md index 04aa3993b268e..84200c5bf7fc4 100644 --- a/tiup/tiup-component-management.md +++ b/tiup/tiup-component-management.md @@ -186,7 +186,7 @@ tiup uninstall [component][:version] [flags] `component`はアンインストールするコンポーネントです。`version`はアンインストールするバージョンです。`tiup uninstall`では、 `component`と`version`どちらも無視できます。どちらか一方を無視する場合は、 `--all`フラグを追加する必要があります。 - バージョンを無視する場合、 `--all`を追加すると、このコンポーネントのすべてのバージョンがアンインストールされます。 -- バージョンとコンポーネントの両方が無視される場合、 `--all`追加すると、すべてのバージョンのすべてのコンポーネントがアンインストールされます。 +- バージョンとコンポーネントの両方が無視される場合、 `--all`を追加すると、すべてのバージョンのすべてのコンポーネントがアンインストールされます。 例 1: TiDB v8.5.3 をアンインストールします。 diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md index a49d0146c2343..1d90969eadcc2 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -80,7 +80,7 @@ v6.0.0以降、TiDBは、読み取り/書き込み競合が稀なシナリオに 分離レベル`READ-COMMITTED`が使用され、ステートメントが`SELECT`多く、読み取り/書き込みの競合がまれなシナリオでは、この変数を有効にすると、グローバル タイムスタンプを取得する際のレイテンシーとコストを回避できます。 -v6.3.0以降、TiDBはポイント書き込みの競合が少ないシナリオにおいて、システム変数[`tidb_rc_write_check_ts`](/system-variables.md#tidb_rc_write_check_ts-new-in-v630)有効にすることでタイムスタンプ取得の最適化をサポートします。この変数を有効にすると、ポイント書き込みステートメントの実行中に、TiDBは現在のトランザクションの有効なタイムスタンプを使用してデータの読み取りとロックを試みます。[`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600)が有効になっている場合も、TiDBは同様にデータを読み取ります。 +v6.3.0以降、TiDBはポイント書き込みの競合が少ないシナリオにおいて、システム変数[`tidb_rc_write_check_ts`](/system-variables.md#tidb_rc_write_check_ts-new-in-v630)を有効にすることでタイムスタンプ取得の最適化をサポートします。この変数を有効にすると、ポイント書き込みステートメントの実行中に、TiDBは現在のトランザクションの有効なタイムスタンプを使用してデータの読み取りとロックを試みます。[`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600)が有効になっている場合も、TiDBは同様にデータを読み取ります。 現在、適用可能なポイント書き込みステートメントの種類は`UPDATE` 、 `DELETE` 、 `SELECT ...... FOR UPDATE`です。ポイント書き込みステートメントとは、主キーまたは一意キーをフィルター条件として使用し、最終実行演算子に`POINT-GET`含まれる書き込みステートメントを指します。現在、3種類のポイント書き込みステートメントに共通するのは、まずキー値に基づいてポイントクエリを実行することです。キーが存在する場合は、キーをロックします。キーが存在しない場合は、空のセットを返します。 diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index 5d9e0f654ce25..b6fc862f41d30 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -94,7 +94,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ TiKV にはボトルネックになる可能性のある単一スレッドがいくつかあります。 -- TiKVインスタンス内のリージョンが多すぎると、単一のgRPCスレッドがボトルネックになります（ **Grafana** -> **TiKV詳細**->**スレッドCPU/gRPC CPU Per Thread**メトリックを確認してください）。v3.x以降のバージョンでは、 `Hibernate Region`有効にするとこの問題を解決できます。 +- TiKVインスタンス内のリージョンが多すぎると、単一のgRPCスレッドがボトルネックになります（ **Grafana** -> **TiKV詳細**->**スレッドCPU/gRPC CPU Per Thread**メトリックを確認してください）。v3.x以降のバージョンでは、 `Hibernate Region`を有効にするとこの問題を解決できます。 - v3.0 より前のバージョンでは、raftstore スレッドまたは apply スレッドがボトルネックになる場合 ( **Grafana** -> **TiKV-details** -> **Thread CPU/raft store CPU**および**Async apply CPU**メトリックが`80%`超える)、TiKV (v2.x) インスタンスをスケールアウトするか、マルチスレッド対応の v3.x にアップグレードできます。 ### CPU負荷が増加する {#cpu-load-increases} diff --git a/troubleshoot-data-inconsistency-errors.md b/troubleshoot-data-inconsistency-errors.md index 8059682b1f478..48eb3f57d57fc 100644 --- a/troubleshoot-data-inconsistency-errors.md +++ b/troubleshoot-data-inconsistency-errors.md @@ -109,6 +109,6 @@ TiDBは、トランザクションまたは[`ADMIN CHECK [TABLE|INDEX]`](/sql-st > **Note:** > -> `tidb_enable_mutation_checker`と`tidb_txn_assertion_level`無効にすると、すべての SQL ステートメントの対応するチェックがバイパスされます。 +> `tidb_enable_mutation_checker`と`tidb_txn_assertion_level`を無効にすると、すべての SQL ステートメントの対応するチェックがバイパスされます。 トランザクション実行で報告されたその他のエラー、および[`ADMIN CHECK [TABLE|INDEX]`](/sql-statements/sql-statement-admin-check-table-index.md)ステートメントの実行中に報告されたすべてのエラーについては、データがすでに不整合であるため、対応するチェックをバイパスすることはできません。 diff --git a/troubleshoot-high-disk-io.md b/troubleshoot-high-disk-io.md index cd23c3f67f483..58b7f77750e96 100644 --- a/troubleshoot-high-disk-io.md +++ b/troubleshoot-high-disk-io.md @@ -57,7 +57,7 @@ TiDBクラスターのメインストレージコンポーネントはTiKVです - `[raftstore]`のうち`apply-pool-size`は小さすぎます。この値は`[1, 5]`の範囲で、大きすぎないように設定することをお勧めします。`Thread CPU`/`apply cpu`の値も比較的高くなっています。 - マシンの CPU リソースが不足しています。 - - 単一リージョンの書き込みホットスポットの問題（現在、この問題の解決は進行中です）。単一スレッド`apply`のCPU使用率が高くなっています（Grafana式に`by (instance, name)`追加することで確認できます）。 + - 単一リージョンの書き込みホットスポットの問題（現在、この問題の解決は進行中です）。単一スレッド`apply`のCPU使用率が高くなっています（Grafana式に`by (instance, name)`を追加することで確認できます）。 - RocksDBへの書き込み速度が遅く、 `RocksDB kv` / `max write duration`高い値です。1つのRaftログには複数のキーと値のペア（kv）が含まれる場合があります。128 kvが一括でRocksDBに書き込まれるため、 `apply`ログ1つにつきRocksDBへの書き込みが複数回発生する可能性があります。 - その他の原因の場合は、バグとして報告してください。 diff --git a/troubleshoot-tidb-cluster.md b/troubleshoot-tidb-cluster.md index f6433919c7d7b..002172a7da571 100644 --- a/troubleshoot-tidb-cluster.md +++ b/troubleshoot-tidb-cluster.md @@ -32,7 +32,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 3. データがクリアされ、サービスが再デプロイされる場合は、次の点を確認してください。 - `tikv-server`と`pd-server`のデータはすべてクリアされます。特定のデータは`tikv-server`に保存され、メタデータは`pd-server`に保存されます。2つのサーバーのうち1つだけがクリアされると、データの整合性が失われます。 - - `pd-server`と`tikv-server`のデータがクリアされ、 `pd-server`と`tikv-server`再起動された後、 `tidb-server`も再起動する必要があります。クラスタIDは`pd-server`初期化される際にランダムに割り当てられます。そのため、クラスタが再デプロイされるとクラスタIDが変更され、新しいクラスタIDを取得するには`tidb-server`再起動する必要があります。 + - `pd-server`と`tikv-server`のデータがクリアされ、 `pd-server`と`tikv-server`が再起動された後、 `tidb-server`も再起動する必要があります。クラスタIDは`pd-server`が初期化される際にランダムに割り当てられます。そのため、クラスタが再デプロイされるとクラスタIDが変更され、新しいクラスタIDを取得するには`tidb-server`を再起動する必要があります。 ## `tidb-server`を起動できません {#cannot-start-tidb-server} @@ -44,7 +44,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 - ポートが使用中です。 - `lsof -i:port`コマンドを使用して、特定のポートに関連するすべてのネットワークを表示し、 `tidb-server`開始するポートが使用されていないことを確認します。 + `lsof -i:port`コマンドを使用して、特定のポートに関連するすべてのネットワークを表示し、 `tidb-server`を開始するポートが使用されていないことを確認します。 @@ -59,7 +59,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 - 起動パラメータのエラー: [TiKVの設定とオプション](/command-line-flags-for-tikv-configuration.md)を参照してください。 -- ポートが使用中です: `lsof -i:port`コマンドを使用して、特定のポートに関連するすべてのネットワークを表示し、 `tikv-server`開始するポートが使用されていないことを確認します。 +- ポートが使用中です: `lsof -i:port`コマンドを使用して、特定のポートに関連するすべてのネットワークを表示し、 `tikv-server`を開始するポートが使用されていないことを確認します。 @@ -85,7 +85,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 - ポートが使用中です。 - `lsof -i:port`コマンドを使用して、特定のポートに関連するすべてのネットワークを表示し、 `pd-server`開始するポートが使用されていないことを確認します。 + `lsof -i:port`コマンドを使用して、特定のポートに関連するすべてのネットワークを表示し、 `pd-server`を開始するポートが使用されていないことを確認します。 ## TiDB/TiKV/PDプロセスが予期せず中止される {#the-tidb-tikv-pd-process-aborts-unexpectedly} diff --git a/troubleshoot-tidb-oom.md b/troubleshoot-tidb-oom.md index c11aedc5867a0..433bfd5c03a06 100644 --- a/troubleshoot-tidb-oom.md +++ b/troubleshoot-tidb-oom.md @@ -81,7 +81,7 @@ OOM の問題は通常、次の原因で発生します。 > **Note:** > -> [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)設定した場合、エラーが発生します: `ERROR 1105 (HY000): Out Of Memory Quota![conn_id=54]` 。これはデータベースのメモリ使用量制御の動作によるもので、正常な動作です。 +> [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)を設定した場合、エラーが発生します: `ERROR 1105 (HY000): Out Of Memory Quota![conn_id=54]` 。これはデータベースのメモリ使用量制御の動作によるもので、正常な動作です。 #### SQL文を実行するとメモリ消費量が多すぎる {#executing-sql-statements-consumes-too-much-memory} diff --git a/tso-configuration-file.md b/tso-configuration-file.md index 7e82be05ade11..71ff5fb5cad55 100644 --- a/tso-configuration-file.md +++ b/tso-configuration-file.md @@ -34,8 +34,8 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために - クライアントがTSOノードにアクセスするためのURL - デフォルト値: `"${listen-addr}"` -- Docker や NAT ネットワーク環境などの状況では、クライアントが TSO ノードによってリッスンされるデフォルトのクライアント URL を通じて TSO ノードにアクセスできない場合は、クライアント アクセスに手動で`advertise-listen-addr`設定する必要があります。 -- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `advertise-listen-addr="http://192.168.100.113:3379"`設定できます。そうすることで、クライアントは`http://192.168.100.113:3379`を通じてこのサービスを見つけることができるようになります。 +- Docker や NAT ネットワーク環境などの状況では、クライアントが TSO ノードによってリッスンされるデフォルトのクライアント URL を通じて TSO ノードにアクセスできない場合は、クライアント アクセスに手動で`advertise-listen-addr`を設定する必要があります。 +- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `advertise-listen-addr="http://192.168.100.113:3379"`を設定できます。そうすることで、クライアントは`http://192.168.100.113:3379`を通じてこのサービスを見つけることができるようになります。 ### `backend-endpoints` {#backend-endpoints} diff --git a/tune-region-performance.md b/tune-region-performance.md index daac54f085909..d21765218fb42 100644 --- a/tune-region-performance.md +++ b/tune-region-performance.md @@ -19,7 +19,7 @@ TiKVは自動的に[最下層のデータを分割する](/best-practices/tidb-b > - v6.5.0 以降、この機能は一般提供 (GA) されます。 > - v8.4.0以降、リージョンのデフォルトサイズが96MiBから256MiBに変更されました。リージョンサイズを増やすと、リージョンの数を減らすことができます。 -多くのリージョンのパフォーマンスオーバーヘッドを削減するには、 [休止状態リージョン](/best-practices/massive-regions-best-practices.md#method-4-increase-the-number-of-tikv-instances)または[`Region Merge`](/best-practices/massive-regions-best-practices.md#method-5-adjust-raft-base-tick-interval)有効にすることもできます。 +多くのリージョンのパフォーマンスオーバーヘッドを削減するには、 [休止状態リージョン](/best-practices/massive-regions-best-practices.md#method-4-increase-the-number-of-tikv-instances)または[`Region Merge`](/best-practices/massive-regions-best-practices.md#method-5-adjust-raft-base-tick-interval)を有効にすることもできます。 ## リージョンサイズを調整するには、 `region-split-size`を使用します。 {#use-region-split-size-to-adjust-region-size}