From f247efda6ba6de7cd14aaf312a7cd93852e1b12a Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Fri, 11 Sep 2026 11:39:20 +0900 Subject: [PATCH 1/3] i18n(ja): unify configuration file/parameter terminology (part 1/2) Split from a single branch that grew past CodeRabbit's 150-file review limit (265 files total). This is part 1/2, containing 133 of those files; part 2/2 is a separate PR with the remaining 132 files. Both parts are byte-identical to the original branch's content for their respective file subsets. Unifies the multi-way split rendering of "configuration" (file, parameter, item, flag, option, and other compounds, plus standalone/ bare use) across the corpus, consistent with the already-decided direction for configuration item/parameter/option compounds (PR #23596). Also includes several literal-identifier and false-friend fixes found during review (Grafana/TiDB Dashboard UI labels wrongly translated, a config-item key mistranslated as prose, a mistranslated table header, more natural table headers). Co-Authored-By: Claude Sonnet 5 --- TOC-tidb-cloud-essential.md | 2 +- TOC-tidb-cloud-starter.md | 4 +-- TOC-tidb-cloud.md | 4 +-- TOC.md | 30 +++++++++---------- _index.md | 2 +- ai/integrations/tidb-mcp-server.md | 2 +- benchmark/benchmark-tidb-using-sysbench.md | 4 +-- ...-performance-benchmarking-with-sysbench.md | 2 +- best-practices/haproxy-best-practices.md | 4 +-- .../three-nodes-hybrid-deployment.md | 2 +- .../tidb-partitioned-tables-best-practices.md | 2 +- br/backup-and-restore-storages.md | 2 +- br/br-monitoring-and-alert.md | 4 +-- cached-tables.md | 2 +- check-before-deployment.md | 2 +- clinic/clinic-data-instruction-for-tiup.md | 14 ++++----- clinic/clinic-introduction.md | 2 +- clinic/clinic-user-guide-for-tiup.md | 2 +- command-line-flags-for-pd-configuration.md | 4 +-- ...line-flags-for-scheduling-configuration.md | 2 +- command-line-flags-for-tidb-configuration.md | 4 +-- command-line-flags-for-tikv-configuration.md | 2 +- command-line-flags-for-tso-configuration.md | 2 +- configure-placement-rules.md | 2 +- coprocessor-cache.md | 4 +-- dashboard/dashboard-diagnostics-report.md | 4 +-- dashboard/dashboard-faq.md | 2 +- dashboard/dashboard-ops-reverse-proxy.md | 4 +-- dashboard/dashboard-resource-manager.md | 14 ++++----- deploy-monitoring-services.md | 10 +++---- develop/dev-guide-aws-appflow-integration.md | 2 +- develop/dev-guide-insert-data.md | 2 +- ...-optimistic-and-pessimistic-transaction.md | 4 +-- develop/dev-guide-prepared-statement.md | 2 +- develop/dev-guide-proxysql-integration.md | 4 +-- ...v-guide-third-party-tools-compatibility.md | 2 +- dm/deploy-a-dm-cluster-using-binary.md | 4 +-- dm/deploy-a-dm-cluster-using-tiup-offline.md | 10 +++---- dm/deploy-a-dm-cluster-using-tiup.md | 8 ++--- dm/dm-best-practices.md | 4 +-- dm/dm-binlog-event-filter.md | 4 +-- dm/dm-block-allow-table-lists.md | 2 +- dm/dm-config-overview.md | 18 +++++------ dm/dm-continuous-data-validation.md | 6 ++-- dm/dm-customized-secret-key.md | 8 ++--- dm/dm-enable-tls.md | 4 +-- dm/dm-export-import-config.md | 4 +-- dm/dm-faq.md | 16 +++++----- dm/dm-generate-self-signed-certificates.md | 4 +-- dm/dm-glossary.md | 2 +- dm/dm-handle-performance-issues.md | 2 +- dm/dm-hardware-and-software-requirements.md | 2 +- dm/dm-manage-source.md | 4 +-- dm/dm-master-configuration-file.md | 8 ++--- dm/dm-online-ddl-tool-support.md | 8 ++--- dm/dm-open-api.md | 2 +- dm/dm-precheck.md | 2 +- dm/dm-source-configuration-file.md | 14 ++++----- dm/dm-task-configuration-guide.md | 14 ++++----- dm/dm-tune-configuration.md | 2 +- dm/dm-worker-configuration-file.md | 12 ++++---- dm/feature-shard-merge-optimistic.md | 4 +-- dm/feature-shard-merge.md | 2 +- dm/maintain-dm-using-tiup.md | 4 +-- dm/manually-handling-sharding-ddl-locks.md | 6 ++-- dm/manually-upgrade-dm-1.0-to-2.0.md | 14 ++++----- dm/migrate-data-using-dm.md | 6 ++-- dm/quick-start-create-source.md | 2 +- dm/quick-start-create-task.md | 2 +- dm/quick-start-with-dm.md | 8 ++--- dm/relay-log.md | 12 ++++---- dm/task-configuration-file-full.md | 12 ++++---- dm/usage-scenario-master-slave-switch.md | 4 +-- dr-multi-replica.md | 2 +- dynamic-config.md | 14 ++++----- enable-disk-spill-encrypt.md | 2 +- enable-tls-between-clients-and-servers.md | 4 +-- encryption-at-rest.md | 12 ++++---- explain-joins.md | 4 +-- faq/high-reliability-faq.md | 2 +- filter-binlog-event.md | 4 +-- filter-dml-event.md | 4 +-- garbage-collection-configuration.md | 4 +-- generate-self-signed-certificates.md | 4 +-- geo-distributed-deployment-topology.md | 2 +- get-started-with-tidb-lightning.md | 2 +- hybrid-deployment-topology.md | 4 +-- .../information-schema-inspection-result.md | 2 +- maintain-tidb-using-tiup.md | 2 +- migrate-aurora-to-tidb.md | 4 +-- migrate-from-csv-files-to-tidb.md | 2 +- migrate-from-sql-files-to-tidb.md | 2 +- migrate-from-tidb-to-mysql.md | 2 +- migrate-from-tidb-to-tidb.md | 2 +- migrate-from-vitess.md | 2 +- migrate-large-mysql-shards-to-tidb.md | 6 ++-- migrate-large-mysql-to-tidb.md | 6 ++-- migrate-small-mysql-shards-to-tidb.md | 4 +-- migrate-small-mysql-to-tidb.md | 2 +- migrate-with-more-columns-downstream.md | 2 +- migrate-with-pt-ghost.md | 2 +- minimal-deployment-topology.md | 2 +- multi-data-centers-in-one-city-deployment.md | 4 +-- pd-configuration-file.md | 26 ++++++++-------- pd-microservices-deployment-topology.md | 4 +-- performance-tuning-overview.md | 2 +- production-deployment-using-tiup.md | 8 ++--- quick-start-with-tidb.md | 2 +- releases/release-2.0-ga.md | 6 ++-- releases/release-2.0-rc.1.md | 2 +- releases/release-2.0-rc.3.md | 2 +- releases/release-2.0.4.md | 2 +- releases/release-2.1.1.md | 2 +- releases/release-2.1.16.md | 2 +- releases/release-2.1.17.md | 4 +-- releases/release-2.1.18.md | 2 +- releases/release-3.0.2.md | 4 +-- releases/release-3.0.4.md | 4 +-- releases/release-3.1.0-beta.2.md | 2 +- releases/release-4.0-ga.md | 2 +- releases/release-4.0.0-beta.1.md | 2 +- releases/release-4.0.3.md | 2 +- releases/release-5.0.0.md | 2 +- releases/release-5.1.0.md | 4 +-- releases/release-5.2.0.md | 8 ++--- releases/release-5.3.0.md | 4 +-- releases/release-5.4.0.md | 12 ++++---- releases/release-6.0.0-dmr.md | 4 +-- releases/release-6.1.0.md | 12 ++++---- releases/release-6.1.4.md | 2 +- releases/release-6.2.0.md | 4 +-- releases/release-6.3.0.md | 8 ++--- releases/release-6.4.0.md | 8 ++--- 133 files changed, 327 insertions(+), 327 deletions(-) diff --git a/TOC-tidb-cloud-essential.md b/TOC-tidb-cloud-essential.md index 5e0d6ea6f20de..0fc856224731d 100644 --- a/TOC-tidb-cloud-essential.md +++ b/TOC-tidb-cloud-essential.md @@ -118,7 +118,7 @@ - [コプロセッサーキャッシュ](/coprocessor-cache.md) - ガベージコレクション（GC） - [概要](/garbage-collection-overview.md) - - [コンフィグレーション](/garbage-collection-configuration.md) + - [設定](/garbage-collection-configuration.md) - [TiFlashのパフォーマンスをチューニング](/tiflash/tune-tiflash-performance.md) - [TiDBのバージョンをアップグレードする](/tidb-cloud/upgrade-tidb-cluster.md) - [TiDB Cloud Essentialインスタンスを削除する](/tidb-cloud/delete-tidb-cluster.md) diff --git a/TOC-tidb-cloud-starter.md b/TOC-tidb-cloud-starter.md index 2c47e62b76f27..cd9f8a2c33f53 100644 --- a/TOC-tidb-cloud-starter.md +++ b/TOC-tidb-cloud-starter.md @@ -111,7 +111,7 @@ - [コプロセッサーキャッシュ](/coprocessor-cache.md) - ガベージコレクション（GC） - [概要](/garbage-collection-overview.md) - - [コンフィグレーション](/garbage-collection-configuration.md) + - [設定](/garbage-collection-configuration.md) - [TiFlashのパフォーマンスをチューニング](/tiflash/tune-tiflash-performance.md) - [TiDBのバージョンをアップグレードする](/tidb-cloud/upgrade-tidb-cluster.md) - [TiDB Cloud Starterインスタンスを削除する](/tidb-cloud/delete-tidb-cluster.md) @@ -152,7 +152,7 @@ - [Postmanで実行](/tidb-cloud/data-service-postman-integration.md) - [GitHubで自動デプロイ](/tidb-cloud/data-service-manage-github-connection.md) - [Next.jsでOpenAPI仕様を使用する](/tidb-cloud/data-service-oas-with-nextjs.md) - - [データアプリコンフィグレーションファイル](/tidb-cloud/data-service-app-config-files.md) + - [データアプリ設定ファイル](/tidb-cloud/data-service-app-config-files.md) - [応答とステータスコード](/tidb-cloud/data-service-response-and-status-code.md) - セキュリティ - [セキュリティ概要](/tidb-cloud/security-overview.md) diff --git a/TOC-tidb-cloud.md b/TOC-tidb-cloud.md index 81a02fa26d95c..a76677cd23959 100644 --- a/TOC-tidb-cloud.md +++ b/TOC-tidb-cloud.md @@ -131,7 +131,7 @@ - [コプロセッサーキャッシュ](/coprocessor-cache.md) - ガベージコレクション（GC） - [概要](/garbage-collection-overview.md) - - [コンフィグレーション](/garbage-collection-configuration.md) + - [設定](/garbage-collection-configuration.md) - [TiFlashのパフォーマンスをチューニング](/tiflash/tune-tiflash-performance.md) - リソース割り当ての最適化 - [リソース割り当ての概要](/tidb-cloud/optimize-resource-allocation.md) @@ -188,7 +188,7 @@ - [Postmanで実行](/tidb-cloud/data-service-postman-integration.md) - [GitHubで自動デプロイ](/tidb-cloud/data-service-manage-github-connection.md) - [Next.jsでOpenAPI仕様を使用する](/tidb-cloud/data-service-oas-with-nextjs.md) - - [データアプリコンフィグレーションファイル](/tidb-cloud/data-service-app-config-files.md) + - [データアプリ設定ファイル](/tidb-cloud/data-service-app-config-files.md) - [応答とステータスコード](/tidb-cloud/data-service-response-and-status-code.md) - ストリームデータ - [変更フィードの概要](/tidb-cloud/changefeed-overview.md) diff --git a/TOC.md b/TOC.md index 490efa917ae6d..8b5cddaa38380 100644 --- a/TOC.md +++ b/TOC.md @@ -16,7 +16,7 @@ - [サンプルデータベースのインポート](/import-example-data.md) - デプロイ - [ソフトウェアおよびハードウェアの要件](/hardware-and-software-requirements.md) - - [環境コンフィグレーションチェックリスト](/check-before-deployment.md) + - [環境設定チェックリスト](/check-before-deployment.md) - プランクラスタトポロジ - [最小トポロジー](/minimal-deployment-topology.md) - [TiFlashトポロジー](/tiflash-deployment-topology.md) @@ -161,7 +161,7 @@ - [毎日のチェックリスト](/daily-check.md) - [TiFlashの管理](/tiflash/maintain-tiflash.md) - [TiUPを使用してTiDBを管理](/maintain-tidb-using-tiup.md) - - [コンフィグレーションを動的に変更する](/dynamic-config.md) + - [設定を動的に変更する](/dynamic-config.md) - [オンラインの安全でない復旧](/online-unsafe-recovery.md) - [プライマリクラスタとセカンダリクラスタ間でデータを複製する](/replicate-between-primary-and-secondary-clusters.md) - 監視と警告 @@ -196,7 +196,7 @@ - インスタンスプロファイリング - [手動プロファイリング](/dashboard/dashboard-profiling.md) - [継続的なプロファイリング](/dashboard/continuous-profiling.md) - - セッション管理とコンフィグレーション + - セッション管理と設定 - [セッションを共有](/dashboard/dashboard-session-share.md) - [SSOの設定](/dashboard/dashboard-session-sso.md) - [FAQ](/dashboard/dashboard-faq.md) @@ -240,7 +240,7 @@ - [TiFlashの性能分析方法](/tiflash-performance-tuning-methods.md) - [TiCDCの性能分析方法](/ticdc-performance-tuning-methods.md) - [レイテンシーの内訳](/latency-breakdown.md) - - コンフィグレーション調整 + - 設定調整 - [オペレーティングシステムのパフォーマンスを調整します](/tune-operating-system.md) - [TiDBメモリのチューニング](/configure-memory-usage.md) - [TiKVスレッドを調整](/tune-tikv-thread-performance.md) @@ -252,7 +252,7 @@ - [コプロセッサーキャッシュ](/coprocessor-cache.md) - ガベージコレクション（GC） - [概要](/garbage-collection-overview.md) - - [コンフィグレーション](/garbage-collection-configuration.md) + - [設定](/garbage-collection-configuration.md) - SQLチューニング - [概要](/sql-tuning-overview.md) - クエリ実行計画の理解 @@ -316,10 +316,10 @@ - PDマイクロサービスを使用する - [PDマイクロサービスの概要](/pd-microservices.md) - [TiUPを使用してPDマイクロサービスノードをスケーリングする](/scale-microservices-using-tiup.md) - - [TSOコンフィグレーションファイル](/tso-configuration-file.md) - - [TSOコンフィグレーションフラグ](/command-line-flags-for-tso-configuration.md) - - [スケジュールコンフィグレーションファイル](/scheduling-configuration-file.md) - - [スケジューリングコンフィグレーションフラグ](/command-line-flags-for-scheduling-configuration.md) + - [TSO設定ファイル](/tso-configuration-file.md) + - [TSO設定フラグ](/command-line-flags-for-tso-configuration.md) + - [スケジュール設定ファイル](/scheduling-configuration-file.md) + - [スケジューリング設定フラグ](/command-line-flags-for-scheduling-configuration.md) - TiDBツール - [概要](/ecosystem-tool-user-guide.md) - [ユースケース](/ecosystem-tool-user-case.md) @@ -487,12 +487,12 @@ - [DML複製メカニズム](/dm/dm-replication-logic.md) - コマンドライン - [DM-master＆DM-worker](/dm/dm-command-line-flags.md) - - コンフィグレーションファイル + - 設定ファイル - [概要](/dm/dm-config-overview.md) - [上流データベース構成](/dm/dm-source-configuration-file.md) - [タスク構成](/dm/task-configuration-file-full.md) - - [DM-masterコンフィグレーション](/dm/dm-master-configuration-file.md) - - [DM-workerのコンフィグレーション](/dm/dm-worker-configuration-file.md) + - [DM-master設定](/dm/dm-master-configuration-file.md) + - [DM-workerの設定](/dm/dm-worker-configuration-file.md) - [テーブルセレクター](/dm/table-selector.md) - [OpenAPI](/dm/dm-open-api.md) - [互換性カタログ](/dm/dm-compatibility-catalog.md) @@ -541,7 +541,7 @@ - [エラー解決](/tidb-lightning/tidb-lightning-error-resolution.md) - [トラブルシューティング](/tidb-lightning/troubleshoot-tidb-lightning.md) - 参照 - - [コンフィグレーションファイル](/tidb-lightning/tidb-lightning-configuration.md) + - [設定ファイル](/tidb-lightning/tidb-lightning-configuration.md) - [コマンドラインフラグ](/tidb-lightning/tidb-lightning-command-line-full.md) - [監視](/tidb-lightning/monitor-tidb-lightning.md) - [ウェブインターフェース](/tidb-lightning/tidb-lightning-web-interface.md) @@ -562,7 +562,7 @@ - [概要](/tiproxy/tiproxy-overview.md) - [負荷分散ポリシー](/tiproxy/tiproxy-load-balance.md) - [交通情報リプレイ](/tiproxy/tiproxy-traffic-replay.md) - - [コンフィグレーション](/tiproxy/tiproxy-configuration.md) + - [設定](/tiproxy/tiproxy-configuration.md) - [コマンドラインパラメータ](/tiproxy/tiproxy-command-line-flags.md) - [モニタリング指標](/tiproxy/tiproxy-grafana.md) - [API](/tiproxy/tiproxy-api.md) @@ -602,7 +602,7 @@ - [システム変数](/system-variables.md) - [システム変数リファレンス](/system-variable-reference.md) - [サーバーステータス変数](/status-variables.md) - - コンフィグレーションファイルパラメータ + - 設定ファイルパラメータ - [tidb-server](/tidb-configuration-file.md) - [tikvサーバー](/tikv-configuration-file.md) - [tiflash-server](/tiflash/tiflash-configuration.md) diff --git a/_index.md b/_index.md index 028801c2ee4f2..bd0ee2c2f5392 100644 --- a/_index.md +++ b/_index.md @@ -127,7 +127,7 @@ summary: TiDBは、ハイブリッドトランザクションおよび分析処 -[TiDBコンフィグレーションファイルのパラメータ](https://docs.pingcap.com/ja/tidb/v8.5/tidb-configuration-file) +[TiDB設定ファイルのパラメータ](https://docs.pingcap.com/ja/tidb/v8.5/tidb-configuration-file) [TiDB コマンドラインフラグ](https://docs.pingcap.com/ja/tidb/v8.5/command-line-flags-for-tidb-configuration) diff --git a/ai/integrations/tidb-mcp-server.md b/ai/integrations/tidb-mcp-server.md index 8446f8508611c..7c4fbb2e9b3f9 100644 --- a/ai/integrations/tidb-mcp-server.md +++ b/ai/integrations/tidb-mcp-server.md @@ -110,7 +110,7 @@ MCPクライアントでSSEモードを使用してTiDB MCPサーバーを設定 uvx --from "pytidb[mcp]" tidb-mcp-server --transport sse ``` -6. `TiDB` MCPサーバー構成を、AIアプリケーション構成ファイルの`mcpServers`セクションに追加します。 +6. `TiDB` MCPサーバー構成を、AIアプリケーション設定ファイルの`mcpServers`セクションに追加します。 ```json { diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index f5aca65ceeb30..a30d8d87d0304 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -61,7 +61,7 @@ TiKV パフォーマンスチューニングの詳細については、 [TiKVパ ### Sysbenchの構成 {#sysbench-configuration} -これは Sysbench 構成ファイルの例です。 +これは Sysbench 設定ファイルの例です。 ```txt mysql-host={TIDB_HOST} @@ -164,7 +164,7 @@ HAproxyを例に挙げましょう。パラメータ`nbproc`を指定すると TiKV 全体の CPU 使用率は低いですが、クラスター内の一部のモジュールの CPU 使用率は高くなる可能性があります。 -ストレージ読み取りプール、コプロセッサ、gRPC など、TiKV 上の他のモジュールの最大同時実行制限は、TiKV 構成ファイルを通じて調整できます。 +ストレージ読み取りプール、コプロセッサ、gRPC など、TiKV 上の他のモジュールの最大同時実行制限は、TiKV 設定ファイルを通じて調整できます。 実際のCPU使用率は、GrafanaのTiKVスレッドCPUモニターパネルで確認できます。モジュールにボトルネックがある場合は、モジュールの同時実行性を高めることで調整できます。 diff --git a/benchmark/v3.0-performance-benchmarking-with-sysbench.md b/benchmark/v3.0-performance-benchmarking-with-sysbench.md index 0980282b35e9e..99a30ebee9aa4 100644 --- a/benchmark/v3.0-performance-benchmarking-with-sysbench.md +++ b/benchmark/v3.0-performance-benchmarking-with-sysbench.md @@ -1,6 +1,6 @@ --- title: TiDB Sysbench Performance Test Report -- v3.0 vs. v2.1 -summary: TiDB v3.0は、すべてのテストにおいてv2.1を上回り、QPSの向上とレイテンシーの低減を実現しました。v3.0におけるコンフィグレーションの変更が、パフォーマンスの向上に貢献しました。 +summary: TiDB v3.0は、すべてのテストにおいてv2.1を上回り、QPSの向上とレイテンシーの低減を実現しました。v3.0における設定の変更が、パフォーマンスの向上に貢献しました。 --- # TiDB Sysbench パフォーマンス テスト レポート - v3.0 と v2.1 の比較 {#tidb-sysbench-performance-test-report-v3-0-vs-v2-1} diff --git a/best-practices/haproxy-best-practices.md b/best-practices/haproxy-best-practices.md index 46b5158940f77..78355d73c5f3a 100644 --- a/best-practices/haproxy-best-practices.md +++ b/best-practices/haproxy-best-practices.md @@ -133,7 +133,7 @@ haproxy --help | `-C ` | 設定ファイルを読み込む前にディレクトリ``に変更します。 | | `-W` | マスターワーカーモード。 | | `-q` | "quiet"モードを設定します。これにより、構成の解析中および起動中に一部のメッセージが無効になります。 | -| `-c` | バインドを試みる前に、構成ファイルのチェックのみを実行して終了します。 | +| `-c` | バインドを試みる前に、設定ファイルのチェックのみを実行して終了します。 | | `-n ` | プロセスごとの接続制限を``に制限します。 | | `-m ` | すべてのプロセスにわたって割り当て可能なメモリのメモリを``メガバイトに制限します。 | | `-N ` | 組み込みのデフォルト値 (通常は 2000) ではなく、プロキシごとのデフォルトの maxconn を``に設定します。 | @@ -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/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index 0ead645c61372..92b252d9351c7 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/best-practices/three-nodes-hybrid-deployment.md @@ -48,7 +48,7 @@ tikv: 次のセクションでは、これらのパラメータの意味と調整方法を紹介します。 -### TiKVスレッドプールサイズのコンフィグレーション {#configuration-of-tikv-thread-pool-size} +### TiKVスレッドプールサイズの設定 {#configuration-of-tikv-thread-pool-size} このセクションでは、フォアグラウンドアプリケーションのスレッドプールのリソース割り当てに関連するパラメータを調整するためのベストプラクティスを紹介します。これらのスレッドプールサイズを縮小するとパフォーマンスが低下しますが、リソースが限られているハイブリッドデプロイシナリオでは、クラスター自体で高いパフォーマンスを達成することは困難です。このシナリオでは、パフォーマンスよりもクラスター全体の安定性が優先されます。 diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md index 5c07affe4847b..5d301e0b576c9 100644 --- a/best-practices/tidb-partitioned-tables-best-practices.md +++ b/best-practices/tidb-partitioned-tables-best-practices.md @@ -114,7 +114,7 @@ WHERE `fa`.`sid` IN ( 次の表は、365 個の範囲パーティションを持つテーブルから 400 行を返すクエリの結果を示しています。 -| コンフィグレーション | 平均クエリ時間 | COP タスク（インデックススキャン） | COP タスク（テーブル検索） | COP タスクの合計 | +| 設定 | 平均クエリ時間 | COP タスク（インデックススキャン） | COP タスク（テーブル検索） | COP タスクの合計 | | ------------------------- | ------- | ------------------ | ------------- | -------- | | パーティションテーブル | 12.6ミリ秒 | 72 | 79 | 151 | | ローカルインデックスを持つパーティションテーブル | 108ミリ秒 | 600 | 375 | 975 | diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md index 5b346dd3de425..48a95bd71e129 100644 --- a/br/backup-and-restore-storages.md +++ b/br/backup-and-restore-storages.md @@ -192,7 +192,7 @@ TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部スト systemctl edit tikv-24000 ``` - 2. TiKV 構成ファイルを編集して、次の3つの環境変数を構成します。 + 2. TiKV 設定ファイルを編集して、次の3つの環境変数を構成します。 ``` [Service] diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md index 7598379fcf5d7..a292715a2c961 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -18,7 +18,7 @@ summary: このドキュメントでは、ログバックアップの監視、 ### 監視構成 {#monitoring-configuration} - TiUPを使用してデプロイされたクラスターの場合、Prometheus は監視メトリックを自動的に収集します。 -- 手動でデプロイされたクラスターの場合は、 [TiDBクラスタ監視のデプロイ](/deploy-monitoring-services.md)の手順に従って、Prometheus 構成ファイルの`scrape_configs`セクションに TiKV 関連のジョブを追加します。 +- 手動でデプロイされたクラスターの場合は、 [TiDBクラスタ監視のデプロイ](/deploy-monitoring-services.md)の手順に従って、Prometheus 設定ファイルの`scrape_configs`セクションに TiKV 関連のジョブを追加します。 ### Grafanaの設定 {#grafana-configuration} @@ -61,7 +61,7 @@ summary: このドキュメントでは、ログバックアップの監視、 PITR でアラート項目を構成するには、次の手順に従います。 1. Prometheusが配置されているノードのアラートルール用の設定ファイル（例： `pitr.rules.yml` ）を作成します。このファイルには、 [Prometheusのドキュメント](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/) 、以下の推奨アラート項目、および設定サンプルに従ってアラートルールを記述します。 -2. Prometheus 構成ファイルの`rule_files`フィールドに、アラートルール ファイルのパスを追加します。 +2. Prometheus 設定ファイルの`rule_files`フィールドに、アラートルール ファイルのパスを追加します。 3. Prometheusプロセスにシグナル`SIGHUP`を送信するか（ `kill -HUP pid` ）、HTTPリクエスト`POST`を`http://prometheus-addr/-/reload`に送信します（HTTPリクエストを送信する前に、Prometheusの起動時にパラメータ`--web.enable-lifecycle`を追加します）。 推奨されるアラート項目は次のとおりです。 diff --git a/cached-tables.md b/cached-tables.md index a354f3f5b8b2a..afda0e0bc19a4 100644 --- a/cached-tables.md +++ b/cached-tables.md @@ -19,7 +19,7 @@ TiDB v6.0.0では、頻繁にアクセスされるものの更新頻度の低い テーブルのデータ量が少ないにもかかわらず、データへのアクセス頻度が高い場合、TiKVではデータが特定のリージョンに集中し、ホットスポットリージョンと呼ばれるリージョンがパフォーマンスに影響を与えます。そのため、キャッシュテーブルの典型的な使用シナリオは以下のようになります。 -- アプリケーションが構成情報を読み取るコンフィグレーションテーブル。 +- アプリケーションが構成情報を読み取る設定テーブル。 - 金融セクターの為替レート表。これらの表は1日に1回のみ更新され、リアルタイムではありません。 - ほとんど更新されない銀行支店またはネットワーク情報テーブル。 diff --git a/check-before-deployment.md b/check-before-deployment.md index 819be424c8356..f101f3434c98a 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -3,7 +3,7 @@ title: TiDB Environment and System Configuration Check summary: TiDB をデプロイする前に環境チェック操作について学習します。 --- -# TiDB環境とシステムコンフィグレーションのチェック {#tidb-environment-and-system-configuration-check} +# TiDB環境とシステム設定のチェック {#tidb-environment-and-system-configuration-check} このドキュメントでは、TiDB をデプロイする前に行う環境チェック手順について説明します。以下の手順は優先度順に説明されています。 diff --git a/clinic/clinic-data-instruction-for-tiup.md b/clinic/clinic-data-instruction-for-tiup.md index f635882564ade..19bba57dadcf8 100644 --- a/clinic/clinic-data-instruction-for-tiup.md +++ b/clinic/clinic-data-instruction-for-tiup.md @@ -33,7 +33,7 @@ PingCAP Clinicによって収集された診断データは、クラスターの | エラーログ | `tidb_stderr.log` | `--include=log` | | スローログ | `tidb_slow_query.log` | `--include=log` | | 監査ログ | `tidb-audit.log.json` | `--include=log` | -| コンフィグレーションファイル | `tidb.toml` | `--include=config` | +| 設定ファイル | `tidb.toml` | `--include=config` | | リアルタイム構成 | `config.json` | `--include=config` | ### TiKV診断データ {#tikv-diagnostic-data} @@ -42,7 +42,7 @@ PingCAP Clinicによって収集された診断データは、クラスターの | :------------- | :---------------- | :------------------------ | | ログ | `tikv.log` | `--include=log` | | エラーログ | `tikv_stderr.log` | `--include=log` | -| コンフィグレーションファイル | `tikv.toml` | `--include=config` | +| 設定ファイル | `tikv.toml` | `--include=config` | | リアルタイム構成 | `config.json` | `--include=config` | ### PD診断データ {#pd-diagnostic-data} @@ -51,7 +51,7 @@ PingCAP Clinicによって収集された診断データは、クラスターの | :--------------------------------------------------------------------------------------------- | :-------------------- | :------------------------ | | ログ | `pd.log` | `--include=log` | | エラーログ | `pd_stderr.log` | `--include=log` | -| コンフィグレーションファイル | `pd.toml` | `--include=config` | +| 設定ファイル | `pd.toml` | `--include=config` | | リアルタイム構成 | `config.json` | `--include=config` | | コマンド`tiup ctl:v pd -u http://${pd IP}:${PORT} store`の出力 | `store.json` | `--include=config` | | コマンド`tiup ctl:v pd -u http://${pd IP}:${PORT} config placement-rules show`の出力 | `placement-rule.json` | `--include=config` | @@ -62,7 +62,7 @@ PingCAP Clinicによって収集された診断データは、クラスターの | :------------- | :---------------------------------------------------------------- | :------------------------ | | ログ | `tiflash.log` | `--include=log` | | エラーログ | `tiflash_stderr.log` | `--include=log` | -| コンフィグレーションファイル | `tiflash-learner.toml` `tiflash-preprocessed.toml` `tiflash.toml` | `--include=config` | +| 設定ファイル | `tiflash-learner.toml` `tiflash-preprocessed.toml` `tiflash.toml` | `--include=config` | | リアルタイム構成 | `config.json` | `--include=config` | ### TiCDC診断データ {#ticdc-diagnostic-data} @@ -71,7 +71,7 @@ PingCAP Clinicによって収集された診断データは、クラスターの | :------------- | :------------------------------------------------------------------------ | :------------------------------------------------ | | ログ | `ticdc.log` | `--include=log` | | エラーログ | `ticdc_stderr.log` | `--include=log` | -| コンフィグレーションファイル | `ticdc.toml` | `--include=config` | +| 設定ファイル | `ticdc.toml` | `--include=config` | | デバッグデータ | `info.txt` `status.txt` `changefeeds.txt` `captures.txt` `processors.txt` | `--include=debug` (Diag はデフォルトではこのデータタイプを収集しません) | ### Prometheus監視データ {#prometheus-monitoring-data} @@ -115,7 +115,7 @@ PingCAP Clinicによって収集された診断データは、クラスターの | :------------- | :--------------------- | :------------------------ | | ログ | `dm-master.log` | `--include=log` | | エラーログ | `dm-master_stderr.log` | `--include=log` | -| コンフィグレーションファイル | `dm-master.toml` | `--include=config` | +| 設定ファイル | `dm-master.toml` | `--include=config` | ### dm-worker診断データ {#dm-worker-diagnostic-data} @@ -123,7 +123,7 @@ PingCAP Clinicによって収集された診断データは、クラスターの | :------------- | :--------------------- | :------------------------ | | ログ | `dm-worker.log` | `--include=log` | | エラーログ | `dm-worker_stderr.log` | `--include=log` | -| コンフィグレーションファイル | `dm-work.toml` | `--include=config` | +| 設定ファイル | `dm-work.toml` | `--include=config` | ### Prometheus監視データ {#prometheus-monitoring-data} diff --git a/clinic/clinic-introduction.md b/clinic/clinic-introduction.md index b99f0c089f2ec..b12ececcf89af 100644 --- a/clinic/clinic-introduction.md +++ b/clinic/clinic-introduction.md @@ -42,7 +42,7 @@ PingCAP Clinic は、クラスターの問題を診断するために次の2つ - SCP 経由でサーバーファイルを転送する - TiUPを使用してデプロイされたクラスターの場合、Diag はセキュリティコピー プロトコル (SCP) を介してターゲットコンポーネントのノードからログファイルと構成ファイルを直接収集できます。 + TiUPを使用してデプロイされたクラスターの場合、Diag はセキュリティコピー プロトコル (SCP) を介してターゲットコンポーネントのノードからログファイルと設定ファイルを直接収集できます。 - SSH経由でリモートコマンドを実行してデータを収集する diff --git a/clinic/clinic-user-guide-for-tiup.md b/clinic/clinic-user-guide-for-tiup.md index 27e3b079ac995..84a381d98e26a 100644 --- a/clinic/clinic-user-guide-for-tiup.md +++ b/clinic/clinic-user-guide-for-tiup.md @@ -218,7 +218,7 @@ Diag を使用すると、 TiUPを使用してデプロイされた TiDB クラ - カーネルパラメータのリスト: `sysctl.conf` - カーネルログ: `dmesg.log` - データ収集中のネットワーク接続: `ss.txt` -- コンフィグレーションデータ：各ノードの`config.json`ディレクトリ +- 設定データ：各ノードの`config.json`ディレクトリ - クラスター自体のメタ情報: in `meta.yaml` (このファイルは収集されたデータを保存するディレクトリの最上位にあります) - 監視データ： `/monitor`ファイルディレクトリ内。監視データはデフォルトで圧縮されており、直接表示できません。監視データを含むJSONファイルを直接表示するには、データ収集時に`--compress-metrics=false`パラメータで圧縮を無効にしてください。 diff --git a/command-line-flags-for-pd-configuration.md b/command-line-flags-for-pd-configuration.md index 3709ac4dfb10a..6f782c9be522d 100644 --- a/command-line-flags-for-pd-configuration.md +++ b/command-line-flags-for-pd-configuration.md @@ -3,7 +3,7 @@ title: PD Configuration Flags summary: PD のいくつかの構成フラグについて学習します。 --- -# PDコンフィグレーションフラグ {#pd-configuration-flags} +# PD設定フラグ {#pd-configuration-flags} PD は、コマンドラインフラグと環境変数を使用して構成できます。 @@ -77,7 +77,7 @@ PD は、コマンドラインフラグと環境変数を使用して構成で - ログローテーションを有効または無効にするには - デフォルト: `true` -- 値が true の場合、PD 構成ファイルの`[log.file]`に従います。 +- 値が true の場合、PD 設定ファイルの`[log.file]`に従います。 ## `--name` {#name} diff --git a/command-line-flags-for-scheduling-configuration.md b/command-line-flags-for-scheduling-configuration.md index 11060d1e4cb92..a2bd0e82a5c2c 100644 --- a/command-line-flags-for-scheduling-configuration.md +++ b/command-line-flags-for-scheduling-configuration.md @@ -3,7 +3,7 @@ title: Scheduling Configuration Flags summary: スケジュール構成フラグは、コマンドラインフラグまたは環境変数を介して構成できます。 --- -# スケジュールコンフィグレーションフラグ {#scheduling-configuration-flags} +# スケジュール設定フラグ {#scheduling-configuration-flags} スケジューリングノードは、PD用の`scheduling`マイクロサービスを提供するために使用されます。コマンドラインフラグまたは環境変数を使用して設定できます。 diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index 9dffec60dd405..7e6a7fca1739c 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -3,7 +3,7 @@ title: Configuration Options summary: TiDB の設定オプションについて学習します。 --- -# コンフィグレーションオプション {#configuration-options} +# 設定オプション {#configuration-options} TiDBクラスタを起動する際には、コマンドラインオプションまたは環境変数を使用して設定できます。このドキュメントでは、TiDBのコマンドオプションについて説明します。デフォルトのTiDBポートは、クライアントリクエスト用に`4000` 、ステータスレポート用に`10080`です。 @@ -17,7 +17,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション - 設定ファイル - デフォルト: `""` -- 設定ファイルが指定されている場合、TiDB は設定ファイルを読み取ります。対応する設定がコマンドラインオプションにも存在する場合、TiDB はコマンドラインオプションの設定を使用して設定ファイルの設定を上書きします。詳細な設定情報については、 [TiDBコンフィグレーションファイルの説明](/tidb-configuration-file.md)を参照してください。 +- 設定ファイルが指定されている場合、TiDB は設定ファイルを読み取ります。対応する設定がコマンドラインオプションにも存在する場合、TiDB はコマンドラインオプションの設定を使用して設定ファイルの設定を上書きします。詳細な設定情報については、 [TiDB設定ファイルの説明](/tidb-configuration-file.md)を参照してください。 ## `--config-check` {#--config-check} diff --git a/command-line-flags-for-tikv-configuration.md b/command-line-flags-for-tikv-configuration.md index 0545dcb2d1019..991acbbdecd78 100644 --- a/command-line-flags-for-tikv-configuration.md +++ b/command-line-flags-for-tikv-configuration.md @@ -3,7 +3,7 @@ title: TiKV Configuration Flags summary: TiKV のいくつかの構成フラグについて学習します。 --- -# TiKVコンフィグレーションフラグ {#tikv-configuration-flags} +# TiKV設定フラグ {#tikv-configuration-flags} TiKV は、コマンドラインパラメータに対していくつかの読み取り可能な単位変換をサポートしています。 diff --git a/command-line-flags-for-tso-configuration.md b/command-line-flags-for-tso-configuration.md index 721d4cb98e130..3cd170fa3997b 100644 --- a/command-line-flags-for-tso-configuration.md +++ b/command-line-flags-for-tso-configuration.md @@ -3,7 +3,7 @@ title: TSO Configuration Flags summary: TSO 構成フラグは、コマンドラインフラグまたは環境変数を介して構成できます。 --- -# TSOコンフィグレーションフラグ {#tso-configuration-flags} +# TSO設定フラグ {#tso-configuration-flags} TSOノードは、PD用の`tso`マイクロサービスを提供するために使用されます。コマンドラインフラグまたは環境変数を使用して設定できます。 diff --git a/configure-placement-rules.md b/configure-placement-rules.md index 9ed0bae036f70..797799642e92f 100644 --- a/configure-placement-rules.md +++ b/configure-placement-rules.md @@ -68,7 +68,7 @@ TiDBバージョン5.0以降では、配置ルール機能はデフォルトで ### 配置ルールを有効にする {#enable-placement-rules} -TiDB v5.0以降では、配置ルール機能はデフォルトで有効になっています。無効にするには、 [配置ルールを無効にする](#disable-placement-rules)を参照してください。無効にした後でこの機能を有効にするには、クラスターを初期化する前に、PD構成ファイルを以下のように変更します。 +TiDB v5.0以降では、配置ルール機能はデフォルトで有効になっています。無効にするには、 [配置ルールを無効にする](#disable-placement-rules)を参照してください。無効にした後でこの機能を有効にするには、クラスターを初期化する前に、PD設定ファイルを以下のように変更します。 ```toml [replication] diff --git a/coprocessor-cache.md b/coprocessor-cache.md index 8cf11338be1da..ee8e5ce1666a6 100644 --- a/coprocessor-cache.md +++ b/coprocessor-cache.md @@ -7,11 +7,11 @@ summary: コプロセッサーキャッシュの機能について学習しま v4.0 以降、TiDB インスタンスは TiKV (コプロセッサーキャッシュ機能) にプッシュダウンされる計算結果のキャッシュをサポートしており、これにより一部のシナリオで計算プロセスを高速化できます。 -## コンフィグレーション {#configuration} +## 設定 {#configuration} -コプロセッサーキャッシュは、TiDB設定ファイルの`tikv-client.copr-cache`設定項目で設定できます。コプロセッサーキャッシュの有効化と設定方法の詳細については、 [TiDBコンフィグレーションファイル](/tidb-configuration-file.md#tikv-clientcopr-cache-new-in-v400)を参照してください。 +コプロセッサーキャッシュは、TiDB設定ファイルの`tikv-client.copr-cache`設定項目で設定できます。コプロセッサーキャッシュの有効化と設定方法の詳細については、 [TiDB設定ファイル](/tidb-configuration-file.md#tikv-clientcopr-cache-new-in-v400)を参照してください。 diff --git a/dashboard/dashboard-diagnostics-report.md b/dashboard/dashboard-diagnostics-report.md index 113fd4f5390f0..48db31aa2cb3c 100644 --- a/dashboard/dashboard-diagnostics-report.md +++ b/dashboard/dashboard-diagnostics-report.md @@ -16,7 +16,7 @@ summary: TiDB Dashboard診断レポートでは、基本情報、診断情報、 - 負荷情報:サーバー、TiDB、PD、または TiKV の CPU、メモリ、その他の負荷情報が含まれます。 - 概要情報: 各 TiDB、PD、または TiKV モジュールの消費時間とエラー情報が含まれます。 - TiDB/PD/TiKV 監視情報:各コンポーネントの監視情報が含まれます。 -- コンフィグレーション情報: 各コンポーネントの構成情報が含まれます。 +- 設定情報: 各コンポーネントの構成情報が含まれます。 診断レポートの例は次のとおりです。 @@ -284,7 +284,7 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり - `GC Info` : TiKV 内のガベージコレクション (GC) 関連の監視情報。 - `Cache Hit` : TiKV 内の RocksDB の各キャッシュのヒット率情報。 -### コンフィグレーション情報 {#configuration-information} +### 設定情報 {#configuration-information} 設定情報では、一部のモジュールの設定値はレポート期間内に表示されます。ただし、これらのモジュールの他の設定値については履歴値を取得できないため、表示される値はレポート生成時点の現在の値となります。 diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index 6d84e6efc91a6..d4b9b51ff14f2 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -86,7 +86,7 @@ Web ページに`required component NgMonitoring is not started`が表示され ステップ2. TiUPを使用して、コントロールマシンにng_port設定項目を追加します。その後、Prometheusをリロードします。 -1. クラスター構成ファイルを編集モードで開きます。 +1. クラスター設定ファイルを編集モードで開きます。 ```shell tiup cluster edit-config ${cluster-name} diff --git a/dashboard/dashboard-ops-reverse-proxy.md b/dashboard/dashboard-ops-reverse-proxy.md index 81243e6f3343f..e34d84529b541 100644 --- a/dashboard/dashboard-ops-reverse-proxy.md +++ b/dashboard/dashboard-ops-reverse-proxy.md @@ -127,7 +127,7 @@ server_configs: デプロイされたクラスターの場合: -1. クラスターの構成ファイルを編集モードで開きます ( `CLUSTER_NAME`をクラスター名に置き換えます)。 +1. クラスターの設定ファイルを編集モードで開きます ( `CLUSTER_NAME`をクラスター名に置き換えます)。 ```shell tiup cluster edit-config CLUSTER_NAME @@ -146,7 +146,7 @@ server_configs: ... ``` - 変更後の構成ファイルは次のファイルのようになります。 + 変更後の設定ファイルは次のファイルのようになります。 ```yaml server_configs: diff --git a/dashboard/dashboard-resource-manager.md b/dashboard/dashboard-resource-manager.md index b11c91193bcb7..a8fbca2bca554 100644 --- a/dashboard/dashboard-resource-manager.md +++ b/dashboard/dashboard-resource-manager.md @@ -1,6 +1,6 @@ --- title: TiDB Dashboard Resource Manager Page -summary: TiDB Dashboardのリソースマネージャページは、クラスタ管理者がリソースグループを作成し、クォータを設定することでリソース分離を実装するのに役立ちます。クラスタ容量を推定し、リソース消費量を監視するための方法を提供します。このページには、TiDB Dashboardまたはブラウザからアクセスできます。このページには、構成、容量推定、およびメトリックのセクションがあります。容量推定方法には、ハードウェアのデプロイと実際のワークロードが含まれます。監視メトリックには、消費されたRUの合計、リソースグループによる消費RU、TiDB CPUクォータと使用量、TiKV CPUクォータと使用量、TiKV IO MBpsが含まれます。 +summary: TiDB Dashboardのリソースマネージャページは、クラスタ管理者がリソースグループを作成し、クォータを設定することでリソース分離を実装するのに役立ちます。クラスタ容量を推定し、リソース消費量を監視するための方法を提供します。このページには、TiDB Dashboardまたはブラウザからアクセスできます。このページには、Configuration、Estimate Capacity、およびMetricsのセクションがあります。容量推定方法には、ハードウェアのデプロイと実際のワークロードが含まれます。監視メトリックには、消費されたRUの合計、リソースグループによる消費RU、TiDB CPUクォータと使用量、TiKV CPUクォータと使用量、TiKV IO MBpsが含まれます。 --- # TiDB Dashboardリソースマネージャーページ {#tidb-dashboard-resource-manager-page} @@ -23,16 +23,16 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ リソースマネージャー ページには、次の3つのセクションがあります。 -- コンフィグレーション: このセクションには、TiDBの`RESOURCE_GROUPS`テーブルから取得したデータが表示されます。すべてのリソースグループに関する情報が含まれています。詳細については、 [`RESOURCE_GROUPS`](/information-schema/information-schema-resource-groups.md)を参照してください。 +- Configuration: このセクションには、TiDBの`RESOURCE_GROUPS`テーブルから取得したデータが表示されます。すべてのリソースグループに関する情報が含まれています。詳細については、 [`RESOURCE_GROUPS`](/information-schema/information-schema-resource-groups.md)を参照してください。 -- 容量の見積もり：リソース計画を立てる前に、クラスター全体の容量を把握する必要があります。以下のいずれかの方法を使用できます。 +- Estimate Capacity：リソース計画を立てる前に、クラスター全体の容量を把握する必要があります。以下のいずれかの方法を使用できます。 - [実際の作業負荷に基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload) - [ハードウェアのデプロイに基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) -- メトリクス: パネル上のメトリクスを観察することで、クラスターの現在の全体的なリソース消費状態を把握できます。 +- Metrics: パネル上のメトリクスを観察することで、クラスターの現在の全体的なリソース消費状態を把握できます。 -## 容量の見積もり {#estimate-capacity} +## Estimate Capacity {#estimate-capacity} リソース計画を立てる前に、クラスター全体の容量を把握しておく必要があります。TiDBは、現在のクラスターの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru#what-is-request-unit-ru)の容量を見積もる2つの方法を提供しています。 @@ -61,13 +61,13 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ - 時間枠内のワークロードが低すぎる場合、または`resource_manager_resource_unit`と`process_cpu_usage`監視データが欠落している場合は、エラーが報告されます`Error 1105 (HY000): The workload in selected time window is too low, with which TiDB is unable to reach a capacity estimation; please select another time window with higher workload, or calibrate resource by hardware instead`また、TiKVはmacOSのCPU使用率を監視しないため、実際のワークロードに基づく容量推定をサポートしておらず、このエラーも報告されます。 - [メトリクス](#metrics)セクションの**CPU 使用率**を使用して適切な時間範囲を選択できます。 + [Metrics](#metrics)セクションの**CPU 使用率**を使用して適切な時間範囲を選択できます。 > **Note:** > > 容量推定機能を使用するには、現在のログインユーザーが権限`SUPER`または`RESOURCE_GROUP_ADMIN` 、および一部のシステムテーブルに対する権限`SELECT`持っている必要があります。この機能を使用する前に、現在のユーザーがこれらの権限を持っていることを確認してください。権限がない場合、一部の機能が正しく動作しない可能性があります。詳細については、 [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md#privileges)を参照してください。 -## メトリクス {#metrics} +## Metrics {#metrics} パネル上のメトリクスを観察することで、クラスター全体の現在のリソース消費状況を把握できます。監視メトリクスとその意味は次のとおりです。 diff --git a/deploy-monitoring-services.md b/deploy-monitoring-services.md index 2eabdf2aec603..39d9b4dfaad9a 100644 --- a/deploy-monitoring-services.md +++ b/deploy-monitoring-services.md @@ -48,7 +48,7 @@ $ ./node_exporter --web.listen-address=":9100" \ ### ステップ3: Node1でPrometheusを起動する {#step-3-start-prometheus-on-node1} -Prometheus 構成ファイルを編集します。 +Prometheus 設定ファイルを編集します。 ```bash cd prometheus-2.49.1.linux-amd64 && @@ -103,7 +103,7 @@ scrape_configs: ... ``` -TiDB、PD、TiKV などのコンポーネントのアラーム ルールを有効にするには、対応するコンポーネントのアラーム ルール ファイルを個別にダウンロードし、アラーム ルール ファイルの構成を Prometheus 構成ファイルに追加します。 +TiDB、PD、TiKV などのコンポーネントのアラーム ルールを有効にするには、対応するコンポーネントのアラーム ルール ファイルを個別にダウンロードし、アラーム ルール ファイルの構成を Prometheus 設定ファイルに追加します。 - TiDB: [`tidb.rules.yml`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/metrics/alertmanager/tidb.rules.yml) - PD: [`pd.rules.yml`](https://github.com/tikv/pd/blob/release-8.5/metrics/alertmanager/pd.rules.yml) @@ -137,7 +137,7 @@ $ ./prometheus \ ### ステップ 4: Node1 で Grafana を開始する {#step-4-start-grafana-on-node1} -Grafana 構成ファイルを編集します。 +Grafana 設定ファイルを編集します。 ```ini cd grafana-7.5.17 && @@ -210,7 +210,7 @@ Grafana サービスを開始します。 > > **Change Password**手順では、 **Skip**を選択できます。 -2. Grafana サイドバー メニューで、**コンフィグレーション**内の**データソース**をクリックします。 +2. Grafana サイドバー メニューで、**Configuration**内の**データソース**をクリックします。 3. **データソースの追加**をクリックします。 @@ -231,7 +231,7 @@ PDサーバー、TiKVサーバー、および TiDBサーバーの Grafana ダッ 2. サイドバー メニューで、 **[ダッシュボード]** -> **[インポート]**をクリックして、 **[ダッシュボードのインポート]**ウィンドウを開きます。 -3. **Upload .json File**をクリックして JSON ファイルをアップロードします ( [pingcap/tidb](https://github.com/pingcap/tidb/tree/release-8.5/pkg/metrics/grafana) [tikv/tikv](https://github.com/tikv/tikv/tree/release-8.5/metrics/grafana)、および[tikv/pd](https://github.com/tikv/pd/tree/release-8.5/metrics/grafana)から TiDB Grafana 構成ファイルをダウンロードします)。 +3. **Upload .json File**をクリックして JSON ファイルをアップロードします ( [pingcap/tidb](https://github.com/pingcap/tidb/tree/release-8.5/pkg/metrics/grafana) [tikv/tikv](https://github.com/tikv/tikv/tree/release-8.5/metrics/grafana)、および[tikv/pd](https://github.com/tikv/pd/tree/release-8.5/metrics/grafana)から TiDB Grafana 設定ファイルをダウンロードします)。 > **Note:** > diff --git a/develop/dev-guide-aws-appflow-integration.md b/develop/dev-guide-aws-appflow-integration.md index 993b69a7b5d72..1c5f69b25c841 100644 --- a/develop/dev-guide-aws-appflow-integration.md +++ b/develop/dev-guide-aws-appflow-integration.md @@ -70,7 +70,7 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration > **Note:** > - > - `--guided`オプションでは、プロンプトが表示され、デプロイの手順を案内します。入力内容は構成ファイルに保存され、デフォルトでは`samconfig.toml`というファイルになります。 + > - `--guided`オプションでは、プロンプトが表示され、デプロイの手順を案内します。入力内容は設定ファイルに保存され、デフォルトでは`samconfig.toml`というファイルになります。 > - `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-insert-data.md b/develop/dev-guide-insert-data.md index e35a9fc7adbb8..99bfad6aeb051 100644 --- a/develop/dev-guide-insert-data.md +++ b/develop/dev-guide-insert-data.md @@ -79,7 +79,7 @@ try (Connection connection = ds.getConnection()) { MySQL JDBCDriverのデフォルト設定では、一括挿入のパフォーマンスを向上させるために、いくつかのパラメータを変更する必要があります。 -| パラメータ | 手段 | 推奨シナリオ | 推奨コンフィグレーション | +| パラメータ | 手段 | 推奨シナリオ | 推奨設定 | | :------------------------: | :------------------------------: | :-----------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------: | | `useServerPrepStmts` | サーバー側を使用してプリペアドステートメントを有効にするかどうか | プリペアドステートメントを複数回使用する必要がある場合 | `true` | | `cachePrepStmts` | クライアントがプリペアドステートメントをキャッシュするかどうか | `useServerPrepStmts=true` | `true` | diff --git a/develop/dev-guide-optimistic-and-pessimistic-transaction.md b/develop/dev-guide-optimistic-and-pessimistic-transaction.md index f3d40739e4af0..32639891a9e6a 100644 --- a/develop/dev-guide-optimistic-and-pessimistic-transaction.md +++ b/develop/dev-guide-optimistic-and-pessimistic-transaction.md @@ -106,7 +106,7 @@ func (tx *TiDBSqlTx) Rollback() error {
-**コンフィグレーションファイル** +**設定ファイル** Mavenを使用してパッケージを管理する場合は、 `pom.xml`の``ノードに以下の依存関係を追加して`HikariCP`インポートし、パッケージ化ターゲットとJARパッケージのメインクラスを起動するように設定します。以下は`pom.xml`の例です。 @@ -1165,7 +1165,7 @@ public class TxnExample { } ``` -**コンフィグレーションの変更** +**設定の変更** `pom.xml`の起動クラスを変更します。 diff --git a/develop/dev-guide-prepared-statement.md b/develop/dev-guide-prepared-statement.md index 8d4e9b44be507..eced8b7d8dc88 100644 --- a/develop/dev-guide-prepared-statement.md +++ b/develop/dev-guide-prepared-statement.md @@ -201,7 +201,7 @@ try (Connection connection = ds.getConnection()) { 次の構成は、JDBC で TiDB サーバー側のプリペアドステートメントを使用するのに役立ちます。 -| パラメータ | 手段 | 推奨シナリオ | 推奨コンフィグレーション | +| パラメータ | 手段 | 推奨シナリオ | 推奨設定 | | :---------------------: | :--------------------------------: | :-------------------------: | :---------------------------: | | `useServerPrepStmts` | サーバー側を使用してプリペアドステートメントを有効にするかどうか | プリペアドステートメントを複数回使用する必要がある場合 | `true` | | `cachePrepStmts` | クライアントがプリペアドステートメントをキャッシュするかどうか | `useServerPrepStmts=true` | `true` | diff --git a/develop/dev-guide-proxysql-integration.md b/develop/dev-guide-proxysql-integration.md index e0a644c1ade0b..54b74eac7f6b6 100644 --- a/develop/dev-guide-proxysql-integration.md +++ b/develop/dev-guide-proxysql-integration.md @@ -130,7 +130,7 @@ systemctl start docker 1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックすると、その概要ページに移動します。 2. 概要ページで、 **[接続]**ペインを見つけて、 `Endpoint` 、 `Port` 、および`User`フィールドをコピーします。ここで`Endpoint`はTiDB Cloud Starterインスタンスのホスト名です。 -#### ステップ2. ProxySQL構成ファイルを生成する {#step-2-generate-proxysql-configuration-files} +#### ステップ2. ProxySQL設定ファイルを生成する {#step-2-generate-proxysql-configuration-files} 1. TiDB および ProxySQL 用の[統合例のコードリポジトリ](https://github.com/pingcap-inc/tidb-proxysql-integration)クローンを作成します。 @@ -192,7 +192,7 @@ systemctl start docker -3. `proxysql-config.py`を実行してProxySQL構成ファイルを生成します。 +3. `proxysql-config.py`を実行してProxySQL設定ファイルを生成します。 diff --git a/develop/dev-guide-third-party-tools-compatibility.md b/develop/dev-guide-third-party-tools-compatibility.md index b93acd444b2b5..5f8f172c70b14 100644 --- a/develop/dev-guide-third-party-tools-compatibility.md +++ b/develop/dev-guide-third-party-tools-compatibility.md @@ -86,7 +86,7 @@ MySQL Connector/J の照合順序はクライアント側に保存され、サ **回避方法** -照合順序は手動で設定し、クライアント側の照合順序に依存しないでください。クライアント側のデフォルトの照合順序は、MySQL Connector/J 構成ファイルに保存されます。 +照合順序は手動で設定し、クライアント側の照合順序に依存しないでください。クライアント側のデフォルトの照合順序は、MySQL Connector/J 設定ファイルに保存されます。 ### `NO_BACKSLASH_ESCAPES`パラメータは効果がありません {#the-no-backslash-escapes-parameter-does-not-take-effect} diff --git a/dm/deploy-a-dm-cluster-using-binary.md b/dm/deploy-a-dm-cluster-using-binary.md index 00615ec40e76c..a21f02edfe31a 100644 --- a/dm/deploy-a-dm-cluster-using-binary.md +++ b/dm/deploy-a-dm-cluster-using-binary.md @@ -91,7 +91,7 @@ Usage of dm-master: > > 一部の設定がコマンドラインから参照できないため、上記の方法でDM-masterを設定できない場合があります。そのような場合は、代わりに設定ファイルを使用してください。 -#### DM-master構成ファイル {#dm-master-configuration-file} +#### DM-master設定ファイル {#dm-master-configuration-file} 以下はDM-masterの設定ファイルです。この方法でDM-masterを設定することをお勧めします。 @@ -166,7 +166,7 @@ Usage of worker: > > 一部の設定がコマンドラインから参照できないため、上記の方法でDM-workerを設定できない場合があります。そのような場合は、代わりに設定ファイルを使用してください。 -#### DM-worker構成ファイル {#dm-worker-configuration-file} +#### DM-worker設定ファイル {#dm-worker-configuration-file} 以下はDM-workerの設定ファイルです。この方法でDM-workerを設定することをお勧めします。 diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index 5cbf991df977f..7177303b059bc 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -66,11 +66,11 @@ source /home/tidb/.bash_profile ミラーを別のディレクトリに切り替えるには、 `tiup mirror set `コマンドを手動で実行します。公式ミラーに戻すには、 `tiup mirror set https://tiup-mirrors.pingcap.com`を実行します。 -## ステップ3: 初期化構成ファイルを編集する {#step-3-edit-the-initialization-configuration-file} +## ステップ3: 初期化設定ファイルを編集する {#step-3-edit-the-initialization-configuration-file} -さまざまなクラスター トポロジに応じて、クラスター初期化構成ファイルを編集する必要があります。 +さまざまなクラスター トポロジに応じて、クラスター初期化設定ファイルを編集する必要があります。 -完全な構成テンプレートについては、「 [TiUP設定パラメータ テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml) . 構成ファイルを作成する」 `topology.yaml`を参照してください。その他の複合シナリオでは、テンプレートに従って必要に応じて構成ファイルを編集します。 +完全な構成テンプレートについては、「 [TiUP設定パラメータ テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml) . 設定ファイルを作成する」 `topology.yaml`を参照してください。その他の複合シナリオでは、テンプレートに従って必要に応じて設定ファイルを編集します。 3 つの DM-master、3つの DM-worker、および 1つの監視コンポーネントインスタンスをデプロイする構成は次のとおりです。 @@ -109,7 +109,7 @@ alertmanager_servers: > > - DM クラスターの高可用性を確保するには、3つの DM-masterノードをデプロイすることをお勧めします。また、デプロイする DM-workerノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数より多くする必要があります (たとえば、DM-workerノードの数は、アップストリーム インスタンスの数より 2つ多くなります)。 > -> - グローバルに有効にする必要があるパラメータについては、構成ファイルの`server_configs`セクションで対応するコンポーネントのこれらのパラメータを構成します。 +> - グローバルに有効にする必要があるパラメータについては、設定ファイルの`server_configs`セクションで対応するコンポーネントのこれらのパラメータを構成します。 > > - 特定のノードで有効にするパラメータについては、このノードの`config`でこれらのパラメータを設定します。 > @@ -142,7 +142,7 @@ tiup dm deploy dm-test ${version} ./topology.yaml --user root [-p] [-i /home/roo - デプロイされた DM クラスターの名前は`dm-test`です。 - DMクラスタのバージョンは`${version}`です。TiUPでサポートされている最新バージョンを確認するには、 `tiup list dm-master`を実行します。 -- 初期化構成ファイルは`topology.yaml`です。 +- 初期化設定ファイルは`topology.yaml`です。 - `--user root` : `root`キーを使用してターゲットマシンにログインし、クラスターのデプロイを完了するか、 `ssh`および`sudo`権限を持つ他のユーザーを使用してデプロイを完了することができます。 - `[-i]`と`[-p]` : オプション。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。`[-i]`は、ターゲットマシンにアクセスできる`root`ユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。`[-p]`は、ユーザーパスワードを対話的に入力するために使用されます。 - TiUP DMは組み込みのSSHクライアントを使用します。制御マシンシステムにネイティブのSSHクライアントを使用する場合は、 [システムのネイティブSSHクライアントを使用してクラスターに接続する](/dm/maintain-dm-using-tiup.md#use-the-systems-native-ssh-client-to-connect-to-cluster)に従って設定を編集してください。 diff --git a/dm/deploy-a-dm-cluster-using-tiup.md b/dm/deploy-a-dm-cluster-using-tiup.md index 80c0777de9f86..7113bc6280995 100644 --- a/dm/deploy-a-dm-cluster-using-tiup.md +++ b/dm/deploy-a-dm-cluster-using-tiup.md @@ -39,13 +39,13 @@ TiUPはDM v2.0以降のバージョンの導入をサポートしています。 tiup install dm dmctl ``` -## ステップ2: 初期化構成ファイルを編集する {#step-2-edit-the-initialization-configuration-file} +## ステップ2: 初期化設定ファイルを編集する {#step-2-edit-the-initialization-configuration-file} -意図したクラスター トポロジに応じて、クラスター初期化構成ファイルを手動で作成および編集する必要があります。 +意図したクラスター トポロジに応じて、クラスター初期化設定ファイルを手動で作成および編集する必要があります。 [設定ファイルテンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml)に従って、YAML 設定ファイル（例： `topology.yaml` ）を作成する必要があります。その他のシナリオでは、設定を適宜編集してください。 -コマンド`tiup dm template > topology.yaml`を使用すると、構成ファイル テンプレートをすばやく生成できます。 +コマンド`tiup dm template > topology.yaml`を使用すると、設定ファイル テンプレートをすばやく生成できます。 3 つの DM-master、3つの DM-worker、および 1つの監視コンポーネントインスタンスをデプロイする構成は次のとおりです。 @@ -163,7 +163,7 @@ tiup dm deploy ${name} ${version} ./topology.yaml -u ${ssh_user} [-p] [-i /home/ | ------------------------ | ------------------------------------------------------------------------------- | | `${name}` | DM クラスターの名前 (例: dm-test) | | `${version}` | DM クラスターのバージョン`tiup list dm-master`を実行すると、サポートされている他のバージョンを確認できます。 | -| `./topology.yaml` | トポロジ構成ファイルのパス。 | +| `./topology.yaml` | トポロジ設定ファイルのパス。 | | `-u`または`--user` | クラスターのデプロイを完了するには、root ユーザーまたは ssh および sudo権限を持つ他のユーザーアカウントとしてターゲットマシンにログインします。 | | `-p`または`--password` | 対象ホストのパスワード。指定すると、パスワード認証が使用されます。 | | `-i`または`--identity_file` | SSH IDファイルのパス。指定すると公開鍵認証が使用されます（デフォルトは"/root/.ssh/id_rsa"）。 | diff --git a/dm/dm-best-practices.md b/dm/dm-best-practices.md index 1a824a3abad18..729ee8f6da8b7 100644 --- a/dm/dm-best-practices.md +++ b/dm/dm-best-practices.md @@ -175,7 +175,7 @@ TiDBスキーマ名はデフォルトでは大文字と小文字を区別しま #### フィルタールール {#filter-rules} -データソースの設定を開始するとすぐに、フィルタールールを設定できます。詳細については、 [データ移行タスクコンフィグレーションガイド](/dm/dm-task-configuration-guide.md)を参照してください。フィルタールールを設定することの利点は次のとおりです。 +データソースの設定を開始するとすぐに、フィルタールールを設定できます。詳細については、 [データ移行タスク設定ガイド](/dm/dm-task-configuration-guide.md)を参照してください。フィルタールールを設定することの利点は次のとおりです。 - ダウンストリームで処理する必要があるBinlogイベントの数を減らし、移行の効率を向上させます。 - 不要なリレーログのストレージを削減し、ディスク領域を節約します。 @@ -231,4 +231,4 @@ DM v6.2.0以降、DMは増分レプリケーションにおける継続的なデ ## 長期データ複製 {#long-term-data-replication} -DMを使用して長期的なデータレプリケーションタスクを実行する場合、メタデータのバックアップは必須です。メタデータのバックアップは、移行クラスタの再構築を確実にする一方で、移行タスクのバージョン管理を実現できます。詳細については、 [データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション](/dm/dm-export-import-config.md)を参照してください。 +DMを使用して長期的なデータレプリケーションタスクを実行する場合、メタデータのバックアップは必須です。メタデータのバックアップは、移行クラスタの再構築を確実にする一方で、移行タスクのバージョン管理を実現できます。詳細については、 [データソースのエクスポートとインポート、およびクラスターのタスク設定](/dm/dm-export-import-config.md)を参照してください。 diff --git a/dm/dm-binlog-event-filter.md b/dm/dm-binlog-event-filter.md index e3833fe8a291e..4be9722e460da 100644 --- a/dm/dm-binlog-event-filter.md +++ b/dm/dm-binlog-event-filter.md @@ -9,7 +9,7 @@ TiDB Data Migration (DM) は、特定のスキーマまたはテーブルのbinl ## binlogイベントフィルターを構成する {#configure-the-binlog-event-filter} -タスク構成ファイルに次の構成を追加します。 +タスク設定ファイルに次の構成を追加します。 ```yaml filters: @@ -21,7 +21,7 @@ filters: ​action: Ignore ``` -DM v2.0.2以降では、ソース設定ファイルでbinlogイベントフィルターを設定できます。詳細については、 [上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)を参照してください。 +DM v2.0.2以降では、ソース設定ファイルでbinlogイベントフィルターを設定できます。詳細については、 [上流データベース設定ファイル](/dm/dm-source-configuration-file.md)を参照してください。 一致するスキーマとテーブルにワイルドカードを使用する場合は、次の点に注意してください。 diff --git a/dm/dm-block-allow-table-lists.md b/dm/dm-block-allow-table-lists.md index 58f57436349da..5afd39eca60ab 100644 --- a/dm/dm-block-allow-table-lists.md +++ b/dm/dm-block-allow-table-lists.md @@ -9,7 +9,7 @@ TiDB Data Migration (DM) を使用してデータを移行する場合、ブロ ## ブロックリストと許可リストを設定する {#configure-the-block-and-allow-lists} -タスク構成ファイルに次の構成を追加します。 +タスク設定ファイルに次の構成を追加します。 ```yaml block-allow-list: # Use black-white-list if the DM version is earlier than or equal to v2.0.0-beta.2. diff --git a/dm/dm-config-overview.md b/dm/dm-config-overview.md index 9f0257cbc7c0c..6f585f956b64d 100644 --- a/dm/dm-config-overview.md +++ b/dm/dm-config-overview.md @@ -1,17 +1,17 @@ --- title: Data Migration Configuration File Overview -summary: このドキュメントでは、データ移行構成ファイルの概要を説明します。 +summary: このドキュメントでは、データ移行設定ファイルの概要を説明します。 --- -# データ移行コンフィグレーションファイルの概要 {#data-migration-configuration-file-overview} +# データ移行設定ファイルの概要 {#data-migration-configuration-file-overview} -このドキュメントでは、DM (データ移行) の構成ファイルの概要を説明します。 +このドキュメントでは、DM (データ移行) の設定ファイルの概要を説明します。 -## DMプロセス構成ファイル {#dm-process-configuration-files} +## DMプロセス設定ファイル {#dm-process-configuration-files} -- `dm-master.toml` : DM-masterプロセスの実行に関する設定ファイル。DM-masterのトポロジ情報とログが含まれます。詳細については、 [DM-masterコンフィグレーションファイル](/dm/dm-master-configuration-file.md)を参照してください。 -- `dm-worker.toml` : DM-workerプロセスの実行に関する設定ファイル。DM-workerのトポロジ情報とログが含まれます。詳細は[DM-workerコンフィグレーションファイル](/dm/dm-worker-configuration-file.md)を参照してください。 -- `source.yaml` : MySQLやMariaDBなどの上流データベースの設定。詳細は[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)を参照してください。 +- `dm-master.toml` : DM-masterプロセスの実行に関する設定ファイル。DM-masterのトポロジ情報とログが含まれます。詳細については、 [DM-master設定ファイル](/dm/dm-master-configuration-file.md)を参照してください。 +- `dm-worker.toml` : DM-workerプロセスの実行に関する設定ファイル。DM-workerのトポロジ情報とログが含まれます。詳細は[DM-worker設定ファイル](/dm/dm-worker-configuration-file.md)を参照してください。 +- `source.yaml` : MySQLやMariaDBなどの上流データベースの設定。詳細は[上流データベース設定ファイル](/dm/dm-source-configuration-file.md)を参照してください。 ## DM移行タスクの構成 {#dm-migration-task-configuration} @@ -20,14 +20,14 @@ summary: このドキュメントでは、データ移行構成ファイルの データ移行タスクを作成するには、次の手順に従います。 1. [dmctl を使用してデータソース構成を DM クラスターにロードします](/dm/dm-manage-source.md#operate-data-source) 。 -2. [タスクコンフィグレーションガイド](/dm/dm-task-configuration-guide.md)の説明を参考に設定ファイル`your_task.yaml`を作成します。 +2. [タスク設定ガイド](/dm/dm-task-configuration-guide.md)の説明を参考に設定ファイル`your_task.yaml`を作成します。 3. [dmctlを使用してデータ移行タスクを作成する](/dm/dm-create-task.md) 。 ### 重要な概念 {#important-concepts} このセクションでは、いくつかの重要な概念について説明します。 -| 概念 | 説明 | コンフィグレーションファイル | +| 概念 | 説明 | 設定ファイル | | :---------- | :-------------------------------------------------------------------------- | :--------------------------------------------------------- | | `source-id` | MySQLまたはMariaDBインスタンス、あるいはプライマリ/セカンダリ構造の移行グループを一意に表します。`source-id`の最大長は32です。 | `source_id` / `source.yaml` ;
`task.yaml`中`source-id` | | DM-masterID | DM-masterを一意に表す（ `dm-master.toml`の`master-addr`パラメータによって） | `master-addr` / `dm-master.toml` | diff --git a/dm/dm-continuous-data-validation.md b/dm/dm-continuous-data-validation.md index 14e4d4a754e25..d2a5255ed8a54 100644 --- a/dm/dm-continuous-data-validation.md +++ b/dm/dm-continuous-data-validation.md @@ -19,12 +19,12 @@ summary: 継続的なデータ検証の使用方法と継続的なデータ検 次のいずれかの方法を使用して、継続的なデータ検証を有効にすることができます。 -- タスク構成ファイルで有効にします。 +- タスク設定ファイルで有効にします。 - dmctl を使用して有効にします。 ### 方法1: タスク設定ファイルで有効にする {#method-1-enable-in-the-task-configuration-file} -継続的なデータ検証を有効にするには、タスク構成ファイルに次の設定項目を追加します。 +継続的なデータ検証を有効にするには、タスク設定ファイルに次の設定項目を追加します。 ```yaml # Add the following configuration items to the upstream database that needs to be validated: @@ -48,7 +48,7 @@ validators: - `worker-count` : バックグラウンドで実行される検証ワーカーの数。各ワーカーはゴルーチンです。 - `row-error-delay` : 指定された時間内に行が検証に合格できない場合、エラー行としてマークされます。デフォルト値は30分です。 -完全な構成については、 [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 +完全な構成については、 [DM 高度なタスク設定ファイル](/dm/task-configuration-file-full.md)を参照してください。 ### 方法2: dmctlを使用して有効にする {#method-2-enable-using-dmctl} diff --git a/dm/dm-customized-secret-key.md b/dm/dm-customized-secret-key.md index 716c3ee853a61..25d6fed96a020 100644 --- a/dm/dm-customized-secret-key.md +++ b/dm/dm-customized-secret-key.md @@ -18,20 +18,20 @@ DM はバージョン 8.0.0 以降では固定秘密キーを使用しなくな - [データソース構成](/dm/dm-source-configuration-file.md)と[移行タスクの構成](/dm/task-configuration-file-full.md)両方でプレーンテキスト パスワードが使用されている場合、アップグレードに追加の手順は必要ありません。 - [データソース構成](/dm/dm-source-configuration-file.md)と[移行タスクの構成](/dm/task-configuration-file-full.md)で暗号化されたパスワードが使用されている場合、または将来的に暗号化されたパスワードを使用する場合は、次の手順を実行する必要があります。 - 1. [DM-master構成ファイル](/dm/dm-master-configuration-file.md)に`secret-key-path`パラメータを追加し、カスタムキーファイルのパスを指定します。ファイルには、64 文字の 16 進数 AES-256 キーが含まれている必要があります。アップグレード前に[固定AES-256秘密鍵](https://github.com/pingcap/tiflow/blob/1252979421fc83ffa2a1548d981e505f7fc0b909/dm/pkg/encrypt/encrypt.go#L27)を使用して暗号化していた場合は、この秘密鍵をキーファイルにコピーできます。すべての DM-masterノードで同じ秘密鍵設定が使用されていることを確認してください。 + 1. [DM-master設定ファイル](/dm/dm-master-configuration-file.md)に`secret-key-path`パラメータを追加し、カスタムキーファイルのパスを指定します。ファイルには、64 文字の 16 進数 AES-256 キーが含まれている必要があります。アップグレード前に[固定AES-256秘密鍵](https://github.com/pingcap/tiflow/blob/1252979421fc83ffa2a1548d981e505f7fc0b909/dm/pkg/encrypt/encrypt.go#L27)を使用して暗号化していた場合は、この秘密鍵をキーファイルにコピーできます。すべての DM-masterノードで同じ秘密鍵設定が使用されていることを確認してください。 2. まずDM-masterのローリングアップグレードを実行し、次にDM-workerのローリングアップグレードを実行します。詳細については、 [ローリングアップグレード](/dm/maintain-dm-using-tiup.md#rolling-upgrade)を参照してください。 ## 暗号化と復号化の秘密鍵を更新する {#update-the-secret-key-for-encryption-and-decryption} 暗号化と復号化に使用される秘密キーを更新するには、次の手順を実行します。 -1. [DM-master構成ファイル](/dm/dm-master-configuration-file.md)の`secret-key-path`を更新します。 +1. [DM-master設定ファイル](/dm/dm-master-configuration-file.md)の`secret-key-path`を更新します。 > **Note:** > > - すべての DM-masterノードが同じ秘密キー構成に更新されていることを確認します。 - > - 秘密鍵の更新中は、新しい[データソース構成ファイル](/dm/dm-source-configuration-file.md)または[移行タスク構成ファイル](/dm/task-configuration-file-full.md)を作成しないでください。 + > - 秘密鍵の更新中は、新しい[データソース設定ファイル](/dm/dm-source-configuration-file.md)または[移行タスク設定ファイル](/dm/task-configuration-file-full.md)を作成しないでください。 2. DM-masterのローリング再起動を実行します。 -3. 新しい[データソース構成ファイル](/dm/dm-source-configuration-file.md)と[移行タスク構成ファイル](/dm/task-configuration-file-full.md)を作成するときは、 `tiup dmctl encrypt` (dmctl バージョン >= v8.0.0) で暗号化されたパスワードを使用します。 +3. 新しい[データソース設定ファイル](/dm/dm-source-configuration-file.md)と[移行タスク設定ファイル](/dm/task-configuration-file-full.md)を作成するときは、 `tiup dmctl encrypt` (dmctl バージョン >= v8.0.0) で暗号化されたパスワードを使用します。 diff --git a/dm/dm-enable-tls.md b/dm/dm-enable-tls.md index 251429316b8c8..8e64973bb353a 100644 --- a/dm/dm-enable-tls.md +++ b/dm/dm-enable-tls.md @@ -91,7 +91,7 @@ summary: DM 接続で TLS を有効にする方法を学習します。 1. アップストリームデータベースを設定し、暗号化サポートを有効にし、サーバー証明書を設定します。詳細な操作については、 [暗号化された接続の使用](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html)を参照してください。 -2. ソース構成ファイルで MySQL クライアント証明書を設定します。 +2. ソース設定ファイルで MySQL クライアント証明書を設定します。 > **Note:** > @@ -109,7 +109,7 @@ summary: DM 接続で TLS を有効にする方法を学習します。 1. 下流TiDBが暗号化接続を使用するように設定します。詳細な操作については、 [安全な接続を使用するように TiDBサーバーを構成する](/enable-tls-between-clients-and-servers.md#configure-tidb-server-to-use-secure-connections)を参照してください。 -2. タスク構成ファイルで TiDB クライアント証明書を設定します。 +2. タスク設定ファイルで TiDB クライアント証明書を設定します。 > **Note:** > diff --git a/dm/dm-export-import-config.md b/dm/dm-export-import-config.md index 176d1785acd70..0796d76d49e58 100644 --- a/dm/dm-export-import-config.md +++ b/dm/dm-export-import-config.md @@ -3,13 +3,13 @@ title: Export and Import Data Sources and Task Configuration of Clusters summary: DM を使用するときに、データソースとクラスターのタスク構成をエクスポートおよびインポートする方法を学習します。 --- -# データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション {#export-and-import-data-sources-and-task-configuration-of-clusters} +# データソースのエクスポートとインポート、およびクラスターのタスク設定 {#export-and-import-data-sources-and-task-configuration-of-clusters} `config`コマンドは、クラスターのデータソースとタスク構成をエクスポートおよびインポートするために使用されます。 > **Note:** > -> v2.0.5 より前のクラスターの場合は、dmctl (>= v2.0.5 かつ < v8.0.0) を使用して、データソースおよびタスク構成ファイルをエクスポートおよびインポートできます。 +> v2.0.5 より前のクラスターの場合は、dmctl (>= v2.0.5 かつ < v8.0.0) を使用して、データソースおよびタスク設定ファイルをエクスポートおよびインポートできます。 ```bash » help config diff --git a/dm/dm-faq.md b/dm/dm-faq.md index f1a27b61e813d..be2b5e2480c02 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -90,7 +90,7 @@ TiDBでサポートされていないDDL文に遭遇した場合は、dmctlを MySQLはエクスポート時にスナップショットを指定できないため、エクスポート中にデータ移行タスクを更新し、その後再起動してチェックポイントからエクスポートを再開することができません。そのため、`Dump`ステージで移行が必要なテーブルを動的に追加することはできません。 -移行のためにテーブルを追加する必要がある場合は、新しい構成ファイルを使用してタスクを直接再起動することをお勧めします。 +移行のためにテーブルを追加する必要がある場合は、新しい設定ファイルを使用してタスクを直接再起動することをお勧めします。 ### `Load`ステージ {#in-the-load-stage} @@ -125,11 +125,11 @@ MySQLはエクスポート時にスナップショットを指定できないた 以下のパラメータをデフォルトの 67108864 (64M) より大きい値に設定します。 - TiDBサーバーのグローバル変数: `max_allowed_packet` 。 -- タスク設定ファイル内の設定項目： `target-database.max-allowed-packet` 。詳細は[DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 +- タスク設定ファイル内の設定項目： `target-database.max-allowed-packet` 。詳細は[DM 高度なタスク設定ファイル](/dm/task-configuration-file-full.md)を参照してください。 ## DM 1.0 クラスターの既存の DM 移行タスクが DM 2.0 以降のクラスターで実行されているときに発生するエラー`Error 1054: Unknown column 'binlog_gtid' in 'field list'`を処理する方法を教えてください。 {#how-to-handle-the-error-error-1054-unknown-column-binlog_gtid-in-field-list-that-occurs-when-existing-dm-migration-tasks-of-an-dm-10-cluster-are-running-on-a-dm-20-or-newer-cluster} -DM v2.0 以降、増分データレプリケーションを続行するために DM 1.0 クラスターのタスク構成ファイルで`start-task`コマンドを直接実行すると、エラー`Error 1054: Unknown column 'binlog_gtid' in 'field list'`が発生します。 +DM v2.0 以降、増分データレプリケーションを続行するために DM 1.0 クラスターのタスク設定ファイルで`start-task`コマンドを直接実行すると、エラー`Error 1054: Unknown column 'binlog_gtid' in 'field list'`が発生します。 このエラーは[DM 1.0 クラスターの DM 移行タスクを DM 2.0 クラスターに手動でインポートする](/dm/manually-upgrade-dm-1.0-to-2.0.md)で処理できます。 @@ -218,7 +218,7 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する 1. ダウンストリームデータベースにインポートされたデータをクリーンアップします。 2. データを処理する DM-workerノードに TiDB-Lightningをデプロイします。 3. DM ダンプユニットがエクスポートするデータをインポートするには、TiDB-Lightning のローカルバックエンド モードを使用します。 - 4. 完全インポートが完了したら、次の方法でタスク構成ファイルを編集し、タスクを再起動します。 + 4. 完全インポートが完了したら、次の方法でタスク設定ファイルを編集し、タスクを再起動します。 - `task-mode`を`incremental`に変更します。 - ダンプユニットが出力するメタデータファイルに記録されている位置に値`mysql-instance.meta.pos`を設定します。 @@ -251,7 +251,7 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する これはDMの既知のバグで、DM v2.0.2で修正されています。このバグは、以下の2つの条件が同時に満たされた場合に発生します。 -1. ソース構成ファイルでは、パラメータ`enable-relay`と`enable-gtid`は`true`に設定されています。 +1. ソース設定ファイルでは、パラメータ`enable-relay`と`enable-gtid`は`true`に設定されています。 2. アップストリームデータベースは**MySQLセカンダリデータベース**です。コマンド`show binlog events in '' limit 2`を実行してデータベースの`previous_gtids`をクエリすると、次の例のように結果が不連続になります。 ``` @@ -332,7 +332,7 @@ query-status test - 現在の時刻から完全エクスポート タスクのメタデータに記録された位置までのアップストリーム バイナリ ログが消去されていない場合は、次の手順を実行できます。 1. 現在のタスクを停止し、連続しない GTID を持つすべてのデータソースを削除します。 - 2. すべてのソース構成ファイルで`enable-relay`を`false`に設定します。 + 2. すべてのソース設定ファイルで`enable-relay`を`false`に設定します。 3. 連続しない GTID を持つデータソース (上記の例の`mysql1`など) の場合は、タスクを増分タスクに変更し、 `binlog-name` 、 `binlog-pos` 、および`binlog-gtid`情報を含む各完全エクスポート タスクのメタデータ情報を使用して関連する`mysql-instances.meta`を構成します。 4. 増分タスクの`task.yaml`に`syncers.safe-mode`を`true`に設定し、タスクを再開します。 5. 増分タスクがすべての欠落データをダウンストリームに複製した後、タスクを停止し、 `task.yaml`の`safe-mode`を`false`に変更します。 @@ -344,10 +344,10 @@ query-status test 4. `task.yaml`の`syncers.safe-mode`を`true`に設定し、タスクを再開します。 5. 増分タスクがすべての欠落データをダウンストリームに複製した後、タスクを停止し、 `task.yaml`の`safe-mode`を`false`に変更します。 6. タスクを再度開始します。 - 7. データソースを再起動し、ソース構成ファイルで`enable-relay`または`enable-gtid`を`false`に設定します。 + 7. データソースを再起動し、ソース設定ファイルで`enable-relay`または`enable-gtid`を`false`に設定します。 - 上記の条件がいずれも満たされていない場合、またはタスクのデータ量が少ない場合は、次の手順を実行できます。 1. ダウンストリームデータベースにインポートされたデータをクリーンアップします。 - 2. データソースを再起動し、ソース構成ファイルで`enable-relay`または`enable-gtid`を`false`に設定します。 + 2. データソースを再起動し、ソース設定ファイルで`enable-relay`または`enable-gtid`を`false`に設定します。 3. 新しいタスクを作成し、コマンド`start-task task.yaml --remove-meta`を実行して、データを最初から再度移行します。 上記の 1 番目と 2 番目のソリューションで正常にレプリケートできるデータソース (上記の例の`mysql2`など) の場合は、増分タスクを設定するときに、 `subTaskStatus.sync`の`syncerBinlog`と`syncerBinlogGtid`情報を使用して関連する`mysql-instances.meta`を構成します。 diff --git a/dm/dm-generate-self-signed-certificates.md b/dm/dm-generate-self-signed-certificates.md index 3d358a4a1f477..ee2d8cb56ffd1 100644 --- a/dm/dm-generate-self-signed-certificates.md +++ b/dm/dm-generate-self-signed-certificates.md @@ -108,7 +108,7 @@ DM-master インスタンスに証明書を発行するには、次の手順を > > `0.0.0.0`のような特殊な IP を接続や通信に使用する場合は、 `alt_names`にも追加する必要があります。 -4. `openssl.cnf`ファイルを保存し、証明書リクエストファイルを生成します。( `Common Name (e.g. server FQDN or YOUR name) []:`に入力する際に、証明書に`dm`などの共通名 (CN) を割り当てます。これは、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントは、デフォルトでは検証を有効にしません。構成ファイルで有効にすることができます。) +4. `openssl.cnf`ファイルを保存し、証明書リクエストファイルを生成します。( `Common Name (e.g. server FQDN or YOUR name) []:`に入力する際に、証明書に`dm`などの共通名 (CN) を割り当てます。これは、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントは、デフォルトでは検証を有効にしません。設定ファイルで有効にすることができます。) ```bash openssl req -new -key master-key.pem -out master-cert.pem -config openssl.cnf @@ -148,7 +148,7 @@ DM-master インスタンスに証明書を発行するには、次の手順を openssl genrsa -out client-key.pem 2048 ``` -2. 証明書リクエストファイルを生成します (この手順では、証明書に共通名を割り当てることもできます。共通名は、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントはデフォルトで検証を有効にしませんが、構成ファイルで有効にすることができます)。 +2. 証明書リクエストファイルを生成します (この手順では、証明書に共通名を割り当てることもできます。共通名は、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントはデフォルトで検証を有効にしませんが、設定ファイルで有効にすることができます)。 ```bash openssl req -new -key client-key.pem -out client-cert.pem diff --git a/dm/dm-glossary.md b/dm/dm-glossary.md index c98906fcaaaa8..ce3cbe0ade10c 100644 --- a/dm/dm-glossary.md +++ b/dm/dm-glossary.md @@ -98,7 +98,7 @@ TiDB データ移行ツールを使用して、上流データベースの**増 このモードは、次のいずれかの状況で有効になります。 -- タスク構成ファイルの`safe-mode`パラメータが`true`に設定されている場合、セーフモードは有効なままになります。 +- タスク設定ファイルの`safe-mode`パラメータが`true`に設定されている場合、セーフモードは有効なままになります。 - シャードマージのシナリオでは、すべてのシャードテーブルで DDL文が複製される前は、セーフモードが有効なままになります。 - 完全移行タスクのダンプ処理単位に引数`--consistency none`が設定されている場合、エクスポート開始時のbinlogの変更がエクスポートされたデータに影響を与えるかどうかを判断できません。そのため、これらのbinlogの変更の増分レプリケーションではセーフモードが有効なままになります。 - タスクがエラーによって一時停止され、その後再開された場合、一部のデータに対する操作が 2回実行される可能性があります。 diff --git a/dm/dm-handle-performance-issues.md b/dm/dm-handle-performance-issues.md index 2b745b66aa44a..cc3f0b58633aa 100644 --- a/dm/dm-handle-performance-issues.md +++ b/dm/dm-handle-performance-issues.md @@ -86,7 +86,7 @@ DMはbinlogイベントからSQL文を構築した後、 `worker-count`キュー 負荷が分散されていない場合は、移行対象のテーブルに主キーまたは一意キーがあるかどうかを確認してください。これらのキーが存在しない場合は、主キーまたは一意キーを追加してください。負荷が分散されていない状態でこれらのキーが存在する場合は、DMをv1.0.5以降にアップグレードしてください。 -- データ移行リンク全体に顕著なレイテンシーがない場合、対応する曲線`DML queue remain length`はほぼ常に 0 になり、最大値はタスク構成ファイルの値`batch`を超えません。 +- データ移行リンク全体に顕著なレイテンシーがない場合、対応する曲線`DML queue remain length`はほぼ常に 0 になり、最大値はタスク設定ファイルの値`batch`を超えません。 - データ移行リンクに顕著なレイテンシーが見られ、各`q_*`に対応する`DML queue remain length`の曲線がほぼ同じで、ほぼ常に0である場合、DMが上流からのデータの読み取り、変換、または同時書き込みを時間内に実行できていないことを意味します（ボトルネックはリレーログユニットにある可能性があります）。トラブルシューティングについては、このドキュメントの前のセクションを参照してください。 diff --git a/dm/dm-hardware-and-software-requirements.md b/dm/dm-hardware-and-software-requirements.md index 162897eabc075..07433780b6114 100644 --- a/dm/dm-hardware-and-software-requirements.md +++ b/dm/dm-hardware-and-software-requirements.md @@ -45,7 +45,7 @@ DMは、64ビット汎用ハードウェアサーバープラットフォーム > **Note:** > > - 本番環境では、DM-master と DM-worker を同じサーバーに導入して実行することは推奨されません。DM-worker がディスクにデータを書き込むと、DM-master の高可用性コンポーネントによるディスクの使用が妨げられる可能性があるためです。 -> - パフォーマンスの問題が発生した場合は、ドキュメント[DMのコンフィグレーションを最適化する](/dm/dm-tune-configuration.md)に従ってタスク設定ファイルを変更することをお勧めします。設定ファイルを調整してもパフォーマンスが効果的に最適化されない場合は、サーバーのハードウェアをアップグレードしてみてください。 +> - パフォーマンスの問題が発生した場合は、ドキュメント[DMの設定を最適化する](/dm/dm-tune-configuration.md)に従ってタスク設定ファイルを変更することをお勧めします。設定ファイルを調整してもパフォーマンスが効果的に最適化されない場合は、サーバーのハードウェアをアップグレードしてみてください。 ## ターゲットデータベースのストレージ要件 {#downstream-storage-space-requirements} diff --git a/dm/dm-manage-source.md b/dm/dm-manage-source.md index 339cfb7dc86bd..b47c71b0df1cd 100644 --- a/dm/dm-manage-source.md +++ b/dm/dm-manage-source.md @@ -59,13 +59,13 @@ Global Flags: ### 使用例 {#usage-example} -次の`operate-source`コマンドを使用して、ソース構成ファイルを作成します。 +次の`operate-source`コマンドを使用して、ソース設定ファイルを作成します。 ```bash operate-source create ./source.yaml ``` -`source.yaml`の設定については[アップストリームデータベースコンフィグレーションファイルの概要](/dm/dm-source-configuration-file.md)を参照してください。 +`source.yaml`の設定については[アップストリームデータベース設定ファイルの概要](/dm/dm-source-configuration-file.md)を参照してください。 返される結果の例を次に示します。 diff --git a/dm/dm-master-configuration-file.md b/dm/dm-master-configuration-file.md index 7b02d7fdcd3a7..d6e7ccc246aab 100644 --- a/dm/dm-master-configuration-file.md +++ b/dm/dm-master-configuration-file.md @@ -3,11 +3,11 @@ title: DM-master Configuration File summary: DM-master の設定ファイルについて説明します。 --- -# DM-masterコンフィグレーションファイル {#dm-master-configuration-file} +# DM-master設定ファイル {#dm-master-configuration-file} -このドキュメントでは、構成ファイル テンプレートと、このファイル内の各設定パラメータの説明を含む、DM-master の構成について説明します。 +このドキュメントでは、設定ファイル テンプレートと、このファイル内の各設定パラメータの説明を含む、DM-master の構成について説明します。 -## コンフィグレーションファイルテンプレート {#configuration-file-template} +## 設定ファイルテンプレート {#configuration-file-template} 以下は DM-master の設定ファイル テンプレートです。 @@ -38,7 +38,7 @@ cert-allowed-cn = ["dm"] secret-key-path = "/path/to/secret/key" ``` -## コンフィグレーションパラメータ {#configuration-parameters} +## 設定パラメータ {#configuration-parameters} このセクションでは、DM-masterの設定パラメータについて説明します。 diff --git a/dm/dm-online-ddl-tool-support.md b/dm/dm-online-ddl-tool-support.md index 145bb27c08d78..222df77d002d0 100644 --- a/dm/dm-online-ddl-tool-support.md +++ b/dm/dm-online-ddl-tool-support.md @@ -21,9 +21,9 @@ MySQLエコシステムでは、gh-ostやpt-oscなどのツールが広く使用
-v2.0.5 以降のバージョンでは、 `task`構成ファイル内の`online-ddl`設定項目を使用する必要があります。 +v2.0.5 以降のバージョンでは、 `task`設定ファイル内の`online-ddl`設定項目を使用する必要があります。 -- アップストリーム MySQL/MariaDB (同時に) が gh-ost または pt-osc ツールを使用する場合は、タスク構成ファイルで`online-ddl`に`true`を設定します。 +- アップストリーム MySQL/MariaDB (同時に) が gh-ost または pt-osc ツールを使用する場合は、タスク設定ファイルで`online-ddl`に`true`を設定します。 ```yml online-ddl: true @@ -39,13 +39,13 @@ online-ddl: true v2.0.5 より前 (v2.0.5 を除く) では、 `task`設定ファイル内の`online-ddl-scheme`設定項目を使用する必要があります。 -- アップストリーム MySQL/MariaDB が gh-ost ツールを使用する場合は、タスク構成ファイルで設定します。 +- アップストリーム MySQL/MariaDB が gh-ost ツールを使用する場合は、タスク設定ファイルで設定します。 ```yml online-ddl-scheme: "gh-ost" ``` -- アップストリーム MySQL/MariaDB が pt ツールを使用する場合は、タスク構成ファイルで設定します。 +- アップストリーム MySQL/MariaDB が pt ツールを使用する場合は、タスク設定ファイルで設定します。 ```yml online-ddl-scheme: "pt" diff --git a/dm/dm-open-api.md b/dm/dm-open-api.md index ddfd7b610ae44..b6164e6b850e5 100644 --- a/dm/dm-open-api.md +++ b/dm/dm-open-api.md @@ -9,7 +9,7 @@ DM は、 [dmctlツール](/dm/dmctl-introduction.md)の機能と同様に、DM OpenAPI を有効にするには、次のいずれかの操作を実行します。 -- DM クラスターがバイナリを使用して直接デプロイされている場合は、DM-master構成ファイルに次の構成を追加します。 +- DM クラスターがバイナリを使用して直接デプロイされている場合は、DM-master設定ファイルに次の構成を追加します。 ```toml openapi = true diff --git a/dm/dm-precheck.md b/dm/dm-precheck.md index f38293650cea6..a6fc1e65d63f4 100644 --- a/dm/dm-precheck.md +++ b/dm/dm-precheck.md @@ -184,7 +184,7 @@ tiup dmctl check-task ./task.yaml 移行タスクの事前チェックは並列処理に対応しています。シャーディングされたテーブルの行数が100万行に達した場合でも、事前チェックは数分で完了します。 -事前チェックのスレッド数を指定するには、移行タスク構成ファイルの`threads`フィールドの`mydumpers`引数を設定します。 +事前チェックのスレッド数を指定するには、移行タスク設定ファイルの`threads`フィールドの`mydumpers`引数を設定します。 ```yaml mydumpers: # Configuration arguments of the dump processing unit diff --git a/dm/dm-source-configuration-file.md b/dm/dm-source-configuration-file.md index fd78e235b0abd..555e8ccf6ee1f 100644 --- a/dm/dm-source-configuration-file.md +++ b/dm/dm-source-configuration-file.md @@ -3,13 +3,13 @@ title: Upstream Database Configuration File of TiDB Data Migration summary: アップストリームデータベースの設定ファイルを学ぶ --- -# TiDB データ移行の上流データベースコンフィグレーションファイル {#upstream-database-configuration-file-of-tidb-data-migration} +# TiDB データ移行の上流データベース設定ファイル {#upstream-database-configuration-file-of-tidb-data-migration} -このドキュメントでは、アップストリーム データベースの構成ファイルについて紹介します。これには、構成ファイル テンプレートと、このファイル内の各設定パラメータの説明が含まれます。 +このドキュメントでは、アップストリーム データベースの設定ファイルについて紹介します。これには、設定ファイル テンプレートと、このファイル内の各設定パラメータの説明が含まれます。 -## コンフィグレーションファイルテンプレート {#configuration-file-template} +## 設定ファイルテンプレート {#configuration-file-template} -以下は、アップストリーム データベースの構成ファイル テンプレートです。 +以下は、アップストリーム データベースの設定ファイル テンプレートです。 ```yaml source-id: "mysql-replica-01" @@ -59,9 +59,9 @@ from: > > DM v2.0.1では、 `enable-gtid`と`enable-relay`を同時に`true`に設定しないでください。そうしないと、増分データが失われる可能性があります。 -## コンフィグレーションパラメータ {#configuration-parameters} +## 設定パラメータ {#configuration-parameters} -このセクションでは、構成ファイル内の各設定パラメータについて説明します。 +このセクションでは、設定ファイル内の各設定パラメータについて説明します。 ### グローバル構成 {#global-configuration} @@ -160,7 +160,7 @@ DMは定期的に現在のタスクステータスとエラーメッセージを ### Binlogイベントフィルター {#binlog-event-filter} -DM v2.0.2 以降では、ソース構成ファイルでbinlogイベントフィルターを構成できます。 +DM v2.0.2 以降では、ソース設定ファイルでbinlogイベントフィルターを構成できます。 #### `case-sensitive` {#case-sensitive} diff --git a/dm/dm-task-configuration-guide.md b/dm/dm-task-configuration-guide.md index 9ae1124ebbb42..f8c3b2e564e8c 100644 --- a/dm/dm-task-configuration-guide.md +++ b/dm/dm-task-configuration-guide.md @@ -3,7 +3,7 @@ title: Data Migration Task Configuration Guide summary: Data Migration (DM) でデータ移行タスクを構成する方法を学習します。 --- -# データ移行タスクコンフィグレーションガイド {#data-migration-task-configuration-guide} +# データ移行タスク設定ガイド {#data-migration-task-configuration-guide} このドキュメントでは、Data Migration (DM) でデータ移行タスクを構成する方法について説明します。 @@ -13,7 +13,7 @@ summary: Data Migration (DM) でデータ移行タスクを構成する方法を - データソースを表示するには、 [データソースの構成を確認する](/dm/dm-manage-source.md#check-data-source-configurations)を参照してください。 - データソースを作成するには、 [データソースを作成する](/dm/migrate-data-using-dm.md#step-3-create-data-source)を参照してください。 -- データソース構成ファイルを生成するには、 [ソース構成ファイルの紹介](/dm/dm-source-configuration-file.md)を参照してください。 +- データソース設定ファイルを生成するには、 [ソース設定ファイルの紹介](/dm/dm-source-configuration-file.md)を参照してください。 次の例`mysql-instances`は、データ移行タスクで移行する必要があるデータソースを構成する方法を示しています。 @@ -60,7 +60,7 @@ target-database: # Configuration of target TiDB database. データ移行タスクのデータソーステーブルのブロックリストと許可リストを構成するには、次の手順を実行します。 -1. タスク構成ファイルで、ブロックおよび許可リストのグローバル フィルタールール セットを構成します。 +1. タスク設定ファイルで、ブロックおよび許可リストのグローバル フィルタールール セットを構成します。 ```yaml block-allow-list: @@ -98,7 +98,7 @@ target-database: # Configuration of target TiDB database. データ移行タスクのbinlogイベントのフィルターを構成するには、次の手順を実行します。 -1. タスク構成ファイルで、 binlogイベントのグローバル フィルタールール セットを構成します。 +1. タスク設定ファイルで、 binlogイベントのグローバル フィルタールール セットを構成します。 ```yaml filters: # The filter rule set of data source binlog events. You can set multiple rules at the same time. @@ -133,11 +133,11 @@ target-database: # Configuration of target TiDB database. > > - データソースの特定のテーブルをダウンストリーム TiDB インスタンス内の別の名前のテーブルに移行する必要がない場合は、この構成をスキップします。 > -> - シャードマージタスクの場合は、タスク構成ファイルでマッピングルールを設定する**必要があります**。 +> - シャードマージタスクの場合は、タスク設定ファイルでマッピングルールを設定する**必要があります**。 データソーステーブルを指定されたダウンストリーム TiDB テーブルに移行するためのルーティング マッピングルールを構成するには、次の手順を実行します。 -1. タスク構成ファイルでグローバル ルーティング マッピングルール セットを構成します。 +1. タスク設定ファイルでグローバル ルーティング マッピングルール セットを構成します。 ```yaml routes: # The routing mapping rule set between the data source tables and downstream TiDB tables. You can set multiple rules at the same time. @@ -186,7 +186,7 @@ shard-mode: "pessimistic" # The shard merge mode. Optional modes are ""/"p ## その他の構成 {#other-configurations} -以下は、このドキュメントの全体的なタスク設定例です。完全なタスク設定テンプレートは[DMタスク構成ファイルの完全な紹介](/dm/task-configuration-file-full.md)にあります。 +以下は、このドキュメントの全体的なタスク設定例です。完全なタスク設定テンプレートは[DMタスク設定ファイルの完全な紹介](/dm/task-configuration-file-full.md)にあります。 ```yaml --- diff --git a/dm/dm-tune-configuration.md b/dm/dm-tune-configuration.md index c83104ef4e484..ed1f87cbd6be8 100644 --- a/dm/dm-tune-configuration.md +++ b/dm/dm-tune-configuration.md @@ -3,7 +3,7 @@ title: Optimize Configuration of DM summary: データ移行タスクの構成を最適化して、データ移行のパフォーマンスを向上させる方法を学習します。 --- -# DMのコンフィグレーションを最適化する {#optimize-configuration-of-dm} +# DMの設定を最適化する {#optimize-configuration-of-dm} このドキュメントでは、データ移行タスクの構成を最適化して、データ移行のパフォーマンスを向上させる方法を紹介します。 diff --git a/dm/dm-worker-configuration-file.md b/dm/dm-worker-configuration-file.md index 8be2c2f177336..feb91a5f1999a 100644 --- a/dm/dm-worker-configuration-file.md +++ b/dm/dm-worker-configuration-file.md @@ -3,13 +3,13 @@ title: DM-worker Configuration File summary: DM-worker の設定ファイルについて学習します。 --- -# DM-workerコンフィグレーションファイル {#dm-worker-configuration-file} +# DM-worker設定ファイル {#dm-worker-configuration-file} -このドキュメントでは、構成ファイル テンプレートと、このファイル内の各設定パラメータの説明を含む、DM-workerの構成について説明します。 +このドキュメントでは、設定ファイル テンプレートと、このファイル内の各設定パラメータの説明を含む、DM-workerの構成について説明します。 -## コンフィグレーションファイルテンプレート {#configuration-file-template} +## 設定ファイルテンプレート {#configuration-file-template} -以下は、DM-workerの構成ファイル テンプレートです。 +以下は、DM-workerの設定ファイル テンプレートです。 ```toml # Worker Configuration. @@ -34,7 +34,7 @@ ssl-key = "/path/to/key.pem" cert-allowed-cn = ["dm"] ``` -## コンフィグレーションパラメータ {#configuration-parameters} +## 設定パラメータ {#configuration-parameters} ### グローバル {#global} @@ -62,7 +62,7 @@ cert-allowed-cn = ["dm"] #### `join` {#join} -- DM-master構成ファイル内の 1つ以上の[`master-addr`](/dm/dm-master-configuration-file.md#global-configuration)に対応します。 +- DM-master設定ファイル内の 1つ以上の[`master-addr`](/dm/dm-master-configuration-file.md#global-configuration)に対応します。 #### `keepalive-ttl` {#keepalive-ttl} diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md index d493631c8daba..72137d95d7e87 100644 --- a/dm/feature-shard-merge-optimistic.md +++ b/dm/feature-shard-merge-optimistic.md @@ -19,9 +19,9 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル そのため、「楽観的モード」が必要になります。このモードでは、シャードテーブルに対して実行されたDDL文は、他のシャードテーブルと互換性のある文に自動的に変換され、すぐに下流に移行されます。これにより、DDL文がシャードテーブルによるDML移行の実行をブロックすることはありません。 -## 楽観的モードのコンフィグレーション {#configuration-of-the-optimistic-mode} +## 楽観的モードの設定 {#configuration-of-the-optimistic-mode} -楽観的モードを使用するには、タスク設定ファイルの`shard-mode`項目を`optimistic`に指定します。`strict-optimistic-shard-mode`の設定を有効にすると、楽観的モードの動作を制限できます。詳細なサンプル設定ファイルについては、 [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 +楽観的モードを使用するには、タスク設定ファイルの`shard-mode`項目を`optimistic`に指定します。`strict-optimistic-shard-mode`の設定を有効にすると、楽観的モードの動作を制限できます。詳細なサンプル設定ファイルについては、 [DM 高度なタスク設定ファイル](/dm/task-configuration-file-full.md)を参照してください。 ## 制限 {#restrictions} diff --git a/dm/feature-shard-merge.md b/dm/feature-shard-merge.md index e311bd29405a0..58d02788a58e8 100644 --- a/dm/feature-shard-merge.md +++ b/dm/feature-shard-merge.md @@ -13,7 +13,7 @@ DMは、複数の上流シャードテーブルのデータをTiDB内の1つの > **Note:** > -> - シャーディングされたテーブルからデータをマージして移行するには、タスク構成ファイルで`shard-mode`を設定する必要があります。 +> - シャーディングされたテーブルからデータをマージして移行するには、タスク設定ファイルで`shard-mode`を設定する必要があります。 > - DM は、シャーディングサポート機能のマージに、デフォルトで悲観的モードを使用します。（ドキュメントに特別な記述がない場合は、デフォルトで悲観的モードを使用します。） > - 楽観的モードの原理と制限事項を理解していない場合は、このモードの使用は推奨されません。そうしないと、移行の中断やデータの不整合など、深刻な結果を招く可能性があります。 diff --git a/dm/maintain-dm-using-tiup.md b/dm/maintain-dm-using-tiup.md index da54359b73397..594ac34c21bfc 100644 --- a/dm/maintain-dm-using-tiup.md +++ b/dm/maintain-dm-using-tiup.md @@ -167,11 +167,11 @@ tiup dm scale-in prod-cluster -N 172.16.5.140:8262 > **Note:** > -> v2.0.5 以降、dmctl は[データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション](/dm/dm-export-import-config.md)をサポートします。 +> v2.0.5 以降、dmctl は[データソースのエクスポートとインポート、およびクラスターのタスク設定](/dm/dm-export-import-config.md)をサポートします。 > > アップグレード前に、 `config export`を使用してクラスターの設定ファイルをエクスポートできます。アップグレード後に以前のバージョンにダウングレードする必要がある場合は、まず以前のクラスターを再デプロイし、 `config import`を使用して以前の設定ファイルをインポートできます。 > -> v2.0.5 より前のクラスターの場合は、dmctl (>= v2.0.5 かつ < v8.0.0) を使用して、データソースおよびタスク構成ファイルをエクスポートおよびインポートできます。 +> v2.0.5 より前のクラスターの場合は、dmctl (>= v2.0.5 かつ < v8.0.0) を使用して、データソースおよびタスク設定ファイルをエクスポートおよびインポートできます。 > > v2.0.2以降のクラスターでは、現在、リレーワーカー関連の設定の自動インポートはサポートされていません。`start-relay`コマンドを使用して手動で[リレーログを開始](/dm/relay-log.md#enable-and-disable-relay-log)を実行できます。 diff --git a/dm/manually-handling-sharding-ddl-locks.md b/dm/manually-handling-sharding-ddl-locks.md index ae8af599dcd4b..6c385941cbb94 100644 --- a/dm/manually-handling-sharding-ddl-locks.md +++ b/dm/manually-handling-sharding-ddl-locks.md @@ -157,7 +157,7 @@ shard-ddl-lock unlock test-`shard_db`.`shard_table` > **Note:** > -> シャーディング DDL イベントの移行プロセス中でないときに一部の DM-workerをオフラインにする必要がある場合、より適切な解決策は、まず`stop-task`を使用して実行中のタスクを停止し、DM-workerをオフラインにして、タスク構成ファイルから対応する構成情報を削除し、最後に`start-task`と新しいタスク構成を使用して移行タスクを再開することです。 +> シャーディング DDL イベントの移行プロセス中でないときに一部の DM-workerをオフラインにする必要がある場合、より適切な解決策は、まず`stop-task`を使用して実行中のタスクを停止し、DM-workerをオフラインにして、タスク設定ファイルから対応する構成情報を削除し、最後に`start-task`と新しいタスク構成を使用して移行タスクを再開することです。 #### 手動ソリューション {#manual-solution} @@ -281,8 +281,8 @@ MySQLとDMの操作プロセスは次のとおりです。 したがって、DDL ロックを手動でロック解除した後、次の操作を実行する必要があります。 1. 実行中のタスクを停止するには`stop-task`を使用します。 -2. タスク構成ファイルを更新し、構成ファイルからオフライン MySQL ソースの関連情報を削除します。 -3. `start-task`と新しいタスク構成ファイルを使用してタスクを再起動します。 +2. タスク設定ファイルを更新し、設定ファイルからオフライン MySQL ソースの関連情報を削除します。 +3. `start-task`と新しいタスク設定ファイルを使用してタスクを再起動します。 > **Note:** > diff --git a/dm/manually-upgrade-dm-1.0-to-2.0.md b/dm/manually-upgrade-dm-1.0-to-2.0.md index 4dbb1bf36e6d7..e29a59fa0682c 100644 --- a/dm/manually-upgrade-dm-1.0-to-2.0.md +++ b/dm/manually-upgrade-dm-1.0-to-2.0.md @@ -21,11 +21,11 @@ TiDB DM ツールを v1.0.x から v2.0+ に自動的にアップグレードす ## ステップ1：v2.0+設定ファイルを準備する {#step-1-prepare-v20-configuration-file} -バージョン2.0以降で準備された構成ファイルには、上流データベースの構成ファイルとデータ移行タスクの構成ファイルが含まれています。 +バージョン2.0以降で準備された設定ファイルには、上流データベースの設定ファイルとデータ移行タスクの設定ファイルが含まれています。 -### アップストリームデータベース構成ファイル {#upstream-database-configuration-file} +### アップストリームデータベース設定ファイル {#upstream-database-configuration-file} -v2.0以降では、[アップストリームデータベース構成ファイル](/dm/dm-source-configuration-file.md)がDM-workerのプロセス構成から分離されているため、 [v1.0.x DM-worker設定](/dm/dm-worker-configuration-file.md)をベースにしたソース構成を取得する必要があります。 +v2.0以降では、[アップストリームデータベース設定ファイル](/dm/dm-source-configuration-file.md)がDM-workerのプロセス構成から分離されているため、 [v1.0.x DM-worker設定](/dm/dm-worker-configuration-file.md)をベースにしたソース構成を取得する必要があります。 > **Note:** > @@ -96,7 +96,7 @@ from: password: "VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=" # Corresponds to the original `from.password`. ``` -### データ移行タスク構成ファイル {#data-migration-task-configuration-file} +### データ移行タスク設定ファイル {#data-migration-task-configuration-file} [データ移行タスク構成ガイド](/dm/dm-task-configuration-guide.md)については、v2.0+ は基本的に v1.0.x と互換性があります。 v1.0.x の設定を直接コピーできます。 @@ -133,9 +133,9 @@ from: +------------------+-------------------------+------------+ ``` -3. 新しいv2.0以降のデータ移行タスクを開始するには、v1.0.xのデータ移行タスク構成ファイルを更新してください。 +3. 新しいv2.0以降のデータ移行タスクを開始するには、v1.0.xのデータ移行タスク設定ファイルを更新してください。 - - v1.0.x のデータ移行タスク構成ファイルが`task_v1.yaml`の場合、それをコピーして`task_v2.yaml`に名前を変更します。 + - v1.0.x のデータ移行タスク設定ファイルが`task_v1.yaml`の場合、それをコピーして`task_v2.yaml`に名前を変更します。 - `task_v2.yaml`に対して以下の変更を行ってください。 - `name`を`task_v2`などの新しい名前に変更します。 - `task-mode`を`incremental`に変更します。 @@ -158,7 +158,7 @@ from: > > ソース構成で`enable-gtid`が有効になっている場合、現在、binlogまたはリレーログファイルを解析して、binlogの位置に対応する GTID セットを取得し、それを`meta`の`binlog-gtid`に設定する必要があります。 -4. [`start-task`](/dm/dm-create-task.md)コマンドを使用して、v2.0以降のデータ移行タスク構成ファイルからアップグレードされたデータ移行タスクを開始します。 +4. [`start-task`](/dm/dm-create-task.md)コマンドを使用して、v2.0以降のデータ移行タスク設定ファイルからアップグレードされたデータ移行タスクを開始します。 5. [`query-status`](/dm/dm-query-status.md)コマンドを使用して、データ移行タスクが正常に実行されているかどうかを確認してください。 diff --git a/dm/migrate-data-using-dm.md b/dm/migrate-data-using-dm.md index 1287b0f852dfa..5cc18765da60d 100644 --- a/dm/migrate-data-using-dm.md +++ b/dm/migrate-data-using-dm.md @@ -13,7 +13,7 @@ summary: データ移行ツールを使用して、全データと増分デー > **Note:** > -> - すべての DM 構成ファイルのデータベース パスワードには、 `dmctl`で暗号化されたパスワードを使用することをお勧めします。データベースのパスワードが空の場合、暗号化する必要はありません。 [dmctlを使用してデータベースのパスワードを暗号化します](/dm/dm-manage-source.md#encrypt-the-database-password)を参照してください。 +> - すべての DM 設定ファイルのデータベース パスワードには、 `dmctl`で暗号化されたパスワードを使用することをお勧めします。データベースのパスワードが空の場合、暗号化する必要はありません。 [dmctlを使用してデータベースのパスワードを暗号化します](/dm/dm-manage-source.md#encrypt-the-database-password)を参照してください。 > - 上流および下流データベースのユーザーは、対応する読み取り権限と書き込み権限を持っている必要があります。 ## ステップ2：クラスタ情報を確認する {#step-2-check-the-cluster-information} @@ -68,7 +68,7 @@ MySQL ホストで必要な権限のリストは[事前チェック](/dm/dm-prec 次の例では、上流の MySQL-1 および MySQL-2 インスタンスの`test_table`データベースにある`test_db`テーブルのすべてのデータを、TiDB の`test_table`データベースにある下流の`test_db`テーブルに、フルデータと増分データの両方のモードで移行する必要があることを想定しています。 -`task.yaml`タスク構成ファイルを以下のように編集します。 +`task.yaml`タスク設定ファイルを以下のように編集します。 ```yaml # The task name. You need to use a different name for each of the multiple tasks that @@ -127,7 +127,7 @@ mydumpers: > > データ移行タスクを初めて開始する前に、アップストリームの設定を完了しておく必要があります。設定が完了していない場合、タスクの開始時にエラーが発生します。 -データ移行タスクを開始するには、 `tiup dmctl`コマンドを実行してください。 `task.yaml`は、上記で編集した構成ファイルです。 +データ移行タスクを開始するには、 `tiup dmctl`コマンドを実行してください。 `task.yaml`は、上記で編集した設定ファイルです。 ```bash tiup dmctl --master-addr 172.16.10.71:8261 start-task ./task.yaml diff --git a/dm/quick-start-create-source.md b/dm/quick-start-create-source.md index 0fbcfd65e17da..c24dd29ee2a3d 100644 --- a/dm/quick-start-create-source.md +++ b/dm/quick-start-create-source.md @@ -55,7 +55,7 @@ summary: データ移行 (DM) のデータソースを作成する方法を学 tiup dmctl --master-addr operate-source create ./source-mysql-01.yaml ``` -その他の設定パラメータについては[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)を参照してください。 +その他の設定パラメータについては[上流データベース設定ファイル](/dm/dm-source-configuration-file.md)を参照してください。 返される結果は次のとおりです。 diff --git a/dm/quick-start-create-task.md b/dm/quick-start-create-task.md index 760c4a4fe1b91..5f4732b8a7b0f 100644 --- a/dm/quick-start-create-task.md +++ b/dm/quick-start-create-task.md @@ -102,7 +102,7 @@ fCxfQ9XKCezSzuCD0Wf5dUD+LsKegSg= この暗号化された値を保存し、次の手順で MySQL データソースを作成するときに使用します。 -### ソース構成ファイルを編集する {#edit-the-source-configuration-file} +### ソース設定ファイルを編集する {#edit-the-source-configuration-file} 次の設定を`conf/source1.yaml`に書き込みます。 diff --git a/dm/quick-start-with-dm.md b/dm/quick-start-with-dm.md index cdb44c3e1841f..3a48cbdfaa63a 100644 --- a/dm/quick-start-with-dm.md +++ b/dm/quick-start-with-dm.md @@ -305,7 +305,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー ソースMySQLデータベースを準備したら、TiDB DMをそのデータベースに接続するための設定を行います。そのためには、接続の詳細を含むソース設定ファイルを作成し、 `dmctl`ツールを使用して設定を適用します。 -1. ソース構成ファイル`mysql-01.yaml`を作成します。 +1. ソース設定ファイル`mysql-01.yaml`を作成します。 > **Note:** > @@ -330,7 +330,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー ソースデータベースを設定したら、TiDB DM で移行タスクを作成できます。このタスクは、ソース MySQL インスタンスを参照し、ターゲット TiDB データベースへの接続詳細を定義します。 -1. DMタスク構成ファイル`tiup-playground-task.yaml`を作成します。 +1. DMタスク設定ファイル`tiup-playground-task.yaml`を作成します。 ```yaml # Task @@ -349,7 +349,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー password: "" # If the password is not empty, it is recommended to use a password encrypted with dmctl. ``` -2. 構成ファイルを使用してタスクを開始します。 +2. 設定ファイルを使用してタスクを開始します。 ```shell tiup dmctl --master-addr 127.0.0.1:8261 start-task tiup-playground-task.yaml @@ -461,7 +461,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー -3. TiDB DM 構成ファイルが不要になった場合は削除します。 +3. TiDB DM 設定ファイルが不要になった場合は削除します。 ```shell rm mysql-01.yaml tiup-playground-task.yaml diff --git a/dm/relay-log.md b/dm/relay-log.md index bdf307ad8aace..2fc14e3096dc2 100644 --- a/dm/relay-log.md +++ b/dm/relay-log.md @@ -7,7 +7,7 @@ summary: DM リレーログのディレクトリ構造、初期移行ルール データ移行 (DM) リレーログは、データベースの変更を記述するイベントを含む番号付きファイルの複数のセットと、使用されたすべてのリレーログファイルの名前を含むインデックスファイルで構成されます。 -リレーログを有効にすると、DM-workerはアップストリームのbinlogをローカル設定ディレクトリに自動的に移行します（DMがTiUPを使用してデプロイされている場合、デフォルトの移行ディレクトリは`/`です）。デフォルト値は``で、 `relay-dir`に設定されていますが、 [上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)で変更できます。v5.4.0以降では、 [DM-worker構成ファイル](/dm/dm-worker-configuration-file.md)の`relay-dir`でローカル設定ディレクトリを設定できます。これは、アップストリームデータベースの設定ファイルよりも優先されます。 +リレーログを有効にすると、DM-workerはアップストリームのbinlogをローカル設定ディレクトリに自動的に移行します（DMがTiUPを使用してデプロイされている場合、デフォルトの移行ディレクトリは`/`です）。デフォルト値は``で、 `relay-dir`に設定されていますが、 [上流データベース設定ファイル](/dm/dm-source-configuration-file.md)で変更できます。v5.4.0以降では、 [DM-worker設定ファイル](/dm/dm-worker-configuration-file.md)の`relay-dir`でローカル設定ディレクトリを設定できます。これは、アップストリームデータベースの設定ファイルよりも優先されます。 ## ユーザーシナリオ {#user-scenarios} @@ -37,7 +37,7 @@ MySQLではストレージ容量が限られているため、最大保存期間 v5.4.0以降のバージョンでは、 `enable-relay`を`true`に設定することでリレーログを有効にできます。v5.4.0以降では、上流データソースをバインドする際に、DM-workerはデータソースの設定で`enable-relay`をチェックします。 `enable-relay`が`true`の場合、このデータソースに対してリレーログ機能が有効になります。 -詳しい設定方法については[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)を参照してください。 +詳しい設定方法については[上流データベース設定ファイル](/dm/dm-source-configuration-file.md)を参照してください。 さらに、 `start-relay`または`stop-relay`コマンドを使用してデータソースの`enable-relay`構成を動的に調整し、リレーログイン時間を有効または無効にすることもできます。 @@ -98,7 +98,7 @@ stop-relay -s mysql-replica-01 worker1 worker2 DM バージョン 2.0.2 より前のバージョン（v2.0.2 は含まない）では、DM-workerを上流データソースにバインドする際に、ソース設定ファイルの設定項目`enable-relay`がチェックされます。`enable-relay`が`true`に設定されている場合、DM はデータソースのリレーログ機能を有効にします。 -設定項目`enable-relay`の設定方法については[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)を参照してください。 +設定項目`enable-relay`の設定方法については[上流データベース設定ファイル](/dm/dm-source-configuration-file.md)を参照してください。
@@ -232,7 +232,7 @@ DM では、リレーログをパージする方法として、手動パージ > > - アクティブリレーログ：リレーログはデータ移行タスクによって使用されています。アクティブリレーログは現在、Syncerユニット内でのみ更新および書き込みされます。「すべて」モードのデータ移行タスクが、データソースのパージで設定された有効期限よりも長い時間、フルエクスポート/インポートを実行した場合でも、リレーログはパージされます。 > -> - 期限切れのリレーログ: リレーログファイルの最終変更時刻と現在の時刻の差が、構成ファイルの`expires`フィールドの値よりも大きくなっています。 +> - 期限切れのリレーログ: リレーログファイルの最終変更時刻と現在の時刻の差が、設定ファイルの`expires`フィールドの値よりも大きくなっています。 #### 自動パージ {#automatic-purge} @@ -362,12 +362,12 @@ deb76a2b-09cc-11e9-9129-5242cf3bb246.000003 - ローカルリレーログが有効な場合、つまりリレーログに有効な`server-uuid.index` 、 `subdir` 、 `relay.meta`ファイルが含まれている場合、DM-worker は`relay.meta`に記録された位置から移行を回復します。 -- 有効なローカルリレーログが存在しないが、アップストリームデータソース構成ファイルで`relay-binlog-name`または`relay-binlog-gtid`が指定されている場合: +- 有効なローカルリレーログが存在しないが、アップストリームデータソース設定ファイルで`relay-binlog-name`または`relay-binlog-gtid`が指定されている場合: - 非 GTID モードでは、 `relay-binlog-name`を指定すると、DM-workerは指定されたbinlogファイルから移行を開始します。 - GTID モードでは、 `relay-binlog-gtid`を指定すると、DM-workerは指定された GTID から移行を開始します。 -- 有効なローカルリレーログがなく、DM 構成ファイルに`relay-binlog-name`または`relay-binlog-gtid`が指定されていない場合: +- 有効なローカルリレーログがなく、DM 設定ファイルに`relay-binlog-name`または`relay-binlog-gtid`が指定されていない場合: - 非 GTID モードでは、DM-workerは、各サブタスクが移行している最も古いbinlogから移行を開始し、最新のbinlogが移行されるまで続けます。 diff --git a/dm/task-configuration-file-full.md b/dm/task-configuration-file-full.md index 76a6e1d0d63e4..3d5383038596b 100644 --- a/dm/task-configuration-file-full.md +++ b/dm/task-configuration-file-full.md @@ -3,7 +3,7 @@ title: DM Advanced Task Configuration File summary: このドキュメントでは、データ移行（DM）の高度なタスク設定ファイルについて、グローバル設定とインスタンス設定の両面から解説します。グローバル設定には基本設定と機能設定が含まれ、インスタンス設定では、上流側の1つまたは複数のMySQLインスタンスから下流側の同じインスタンスへのデータ移行のためのサブタスクを定義します。 --- -# DM 高度タスクコンフィグレーションファイル {#dm-advanced-task-configuration-file} +# DM 高度タスク設定ファイル {#dm-advanced-task-configuration-file} このドキュメントでは[インスタンス構成](#instance-configuration)[グローバル設定](#global-configuration)とインスタンス構成を含む、データ移行 (DM) の高度なタスク設定ファイルを紹介します。 @@ -13,7 +13,7 @@ summary: このドキュメントでは、データ移行（DM）の高度なタ ## タスク設定ファイルテンプレート（上級者向け） {#task-configuration-file-template-advanced} -以下は、**高度な**データ移行タスクを実行できるタスク構成ファイルのテンプレートです。 +以下は、**高度な**データ移行タスクを実行できるタスク設定ファイルのテンプレートです。 ```yaml --- @@ -239,7 +239,7 @@ mysql-instances: syncer-thread: 16 # The number of threads that the sync processing unit uses for replicating incremental data. `syncer-thread` corresponds to the `worker-count` configuration item of the syncers configuration. `syncer-thread` has overriding priority when the two items are both configured. When multiple instances are migrating data to TiDB at the same time, reduce the value according to the load. ``` -## コンフィグレーション順序 {#configuration-order} +## 設定順序 {#configuration-order} サンプル設定ファイルから、設定ファイルが`Global configuration`と`Instance configuration`の 2つの部分から構成されていることがわかります。ここで、 `Global configuration`には`Basic configuration`と`Feature configuration set`が含まれています。設定順序は次のとおりです。 @@ -276,15 +276,15 @@ mysql-instances: #### `mydumpers` {#mydumpers} -- ダンプ処理ユニットのコンフィグレーション引数。デフォルト設定で要件を満たしている場合は、この項目を設定する必要はありません。または、 `mydumper-thread`のみを使用して`thread`を設定することもできます。 +- ダンプ処理ユニットの設定引数。デフォルト設定で要件を満たしている場合は、この項目を設定する必要はありません。または、 `mydumper-thread`のみを使用して`thread`を設定することもできます。 #### `loaders` {#loaders} -- 負荷処理ユニットのコンフィグレーション引数。デフォルト設定で要件を満たしている場合は、この項目を設定する必要はありません。または、 `loader-thread`のみを使用して`pool-size`を設定することもできます。 +- 負荷処理ユニットの設定引数。デフォルト設定で要件を満たしている場合は、この項目を設定する必要はありません。または、 `loader-thread`のみを使用して`pool-size`を設定することもできます。 #### `syncers` {#syncers} -- 同期処理ユニットのコンフィグレーション引数。デフォルト設定で要件を満たしている場合は、この項目を設定する必要はありません。または、 `syncer-thread`のみを使用して`worker-count`を設定することもできます。 +- 同期処理ユニットの設定引数。デフォルト設定で要件を満たしている場合は、この項目を設定する必要はありません。または、 `syncer-thread`のみを使用して`worker-count`を設定することもできます。 ## インスタンス構成 {#instance-configuration} diff --git a/dm/usage-scenario-master-slave-switch.md b/dm/usage-scenario-master-slave-switch.md index ee6bb598b71cf..1d170318b7444 100644 --- a/dm/usage-scenario-master-slave-switch.md +++ b/dm/usage-scenario-master-slave-switch.md @@ -11,7 +11,7 @@ DM-worker が接続するアップストリーム MySQL インスタンスでダ > > - DM-worker接続は、同じプライマリ - セカンダリ移行クラスター内のインスタンスにのみ切り替えることができます。 > - 新しく接続する MySQL インスタンスには、DM-worker に必要なbinlogが必要です。 -> - DM-workerは GTID セット モードで動作する必要があります。つまり、対応するソース構成ファイルで`enable-gtid: true`を指定する必要があります。 +> - DM-workerは GTID セット モードで動作する必要があります。つまり、対応するソース設定ファイルで`enable-gtid: true`を指定する必要があります。 > - 接続切り替えは以下の2つのシナリオのみをサポートします。各シナリオの手順を厳密に守ってください。そうしないと、新しく接続されたMySQLインスタンスに合わせてDMクラスタを再デプロイし、データ移行タスクを最初からやり直す必要がある場合があります。 GTID セットの詳細については、 [MySQLドキュメント](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-concepts.html#replication-gtids-concepts-gtid-sets)を参照してください。 @@ -48,5 +48,5 @@ DM-worker 設定を変更して、DM-worker をアップストリーム内の新 - `gtid-E`には`gtid-S`が含まれます。 5. `stop-task`を使用すると、データ移行の実行中のタスクがすべて停止します。 6. `operator-source stop`コマンドを使用して、古い MySQL インスタンスのアドレスに対応するソース構成を DM クラスターから削除します。 -7. ソース構成ファイル内の MySQL インスタンスのアドレスを更新し、 `operate-source create`コマンドを使用して DM クラスターに新しいソース構成を再ロードします。 +7. ソース設定ファイル内の MySQL インスタンスのアドレスを更新し、 `operate-source create`コマンドを使用して DM クラスターに新しいソース構成を再ロードします。 8. 移行タスクを再開するには`start-task`を使用します。 diff --git a/dr-multi-replica.md b/dr-multi-replica.md index 577d9e358700f..07c8124465c9f 100644 --- a/dr-multi-replica.md +++ b/dr-multi-replica.md @@ -92,7 +92,7 @@ summary: 単一クラスターのマルチレプリカ災害復旧ソリュー - `server.grpc-compression-type: gzip`を設定すると、TiKV での gRPC メッセージ圧縮が有効になり、ネットワークトラフィックが削減されます。 - `raftstore.raft-min-election-timeout-ticks`と`raftstore.raft-max-election-timeout-ticks`を設定して、リージョン 3 が選挙に参加するまでの時間を延長し、このリージョン内のレプリカがリーダーとして投票されるのを防ぎます。 -2. 上記の構成ファイルを使用してクラスターを作成します。 +2. 上記の設定ファイルを使用してクラスターを作成します。 ```shell tiup cluster deploy drtest v6.4.0 ./topo.yaml diff --git a/dynamic-config.md b/dynamic-config.md index 27f346c47be2e..a9e6451b2ab52 100644 --- a/dynamic-config.md +++ b/dynamic-config.md @@ -3,7 +3,7 @@ title: Modify Configuration Dynamically summary: クラスター構成を動的に変更する方法を学習します。 --- -# コンフィグレーションを動的に変更する {#modify-configuration-dynamically} +# 設定を動的に変更する {#modify-configuration-dynamically} このドキュメントでは、クラスター構成を動的に変更する方法について説明します。 @@ -111,9 +111,9 @@ show warnings; 次の TiKV 設定項目は動的に変更できます。 -| コンフィグレーション項目 | 説明 | +| 設定項目 | 説明 | | :-------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------- | -| ログレベル | ログレベル。 | +| `log.level` | ログレベル。 | | `raftstore.raft-max-inflight-msgs` | 確認するRaftログの数。この数を超えると、 Raftステートマシンはログの送信速度を低下させます。 | | `raftstore.raft-log-gc-tick-interval` | Raftログを削除するポーリングタスクがスケジュールされる時間間隔 | | `raftstore.raft-log-gc-threshold` | 残存Raftログの最大許容数に関するソフト制限 | @@ -241,7 +241,7 @@ show warnings; - `db-name`が`rocksdb`の場合、 `cf-name`のオプションの値は`defaultcf` 、 `writecf` 、 `lockcf` 、および`raftcf`です。 - `db-name`が`raftdb`のとき、 `cf-name`の値は`defaultcf`になります。 -詳細なパラメータの説明については[TiKVコンフィグレーションファイル](/tikv-configuration-file.md)を参照してください。 +詳細なパラメータの説明については[TiKV設定ファイル](/tikv-configuration-file.md)を参照してください。 ### PD構成を動的に変更する {#modify-pd-configuration-dynamically} @@ -263,7 +263,7 @@ Query OK, 0 rows affected (0.01 sec) 次の PD 設定項目は動的に変更できます。 -| コンフィグレーション項目 | 説明 | +| 設定項目 | 説明 | | :--------------------------------------------------- | :--------------------------------------------------------- | | `log.level` | ログレベル | | `cluster-version` | クラスターバージョン | @@ -329,7 +329,7 @@ Query OK, 0 rows affected (0.01 sec) | `replication-mode.dr-auto-sync.wait-recover-timeout` | ネットワークが回復した後、 `sync-recover`状態に戻るまでの待機時間 | | `replication-mode.dr-auto-sync.pause-region-split` | `async_wait`と`async`ステータスでリージョン分割操作を一時停止するかどうかを制御します | -詳細なパラメータの説明については[PDコンフィグレーションファイル](/pd-configuration-file.md)を参照してください。 +詳細なパラメータの説明については[PD設定ファイル](/pd-configuration-file.md)を参照してください。 ### TiDB構成を動的に変更する {#modify-tidb-configuration-dynamically} @@ -362,7 +362,7 @@ select @@tidb_slow_log_threshold; 次の TiDB 設定項目は動的に変更できます。 -| コンフィグレーション項目 | SQL変数 | 説明 | +| 設定項目 | SQL変数 | 説明 | | ------------------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------------- | | `instance.tidb_enable_slow_log` | `tidb_enable_slow_log` | スローログを有効にするかどうかを制御します | | `instance.tidb_slow_log_threshold` | `tidb_slow_log_threshold` | スローログのしきい値を指定します | diff --git a/enable-disk-spill-encrypt.md b/enable-disk-spill-encrypt.md index 18e6810f5fcbe..dffe98f6da896 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-clients-and-servers.md b/enable-tls-between-clients-and-servers.md index 28a757e5d6933..3e1abe1100382 100644 --- a/enable-tls-between-clients-and-servers.md +++ b/enable-tls-between-clients-and-servers.md @@ -42,7 +42,7 @@ MySQLと同様に、TiDBは同じTCPポート上でTLS接続と非TLS接続の `auto-tls`は安全な接続を可能にしますが、クライアント証明書の検証は提供しません。証明書の検証、および証明書の生成方法を制御するには、以下の`ssl-cert` 、 `ssl-key` 、および`ssl-ca`変数の設定に関するアドバイスを参照してください。 -TiDBサーバーで独自の証明書を使用して安全な接続を有効にするには、TiDBサーバーを起動する際に、構成ファイルで`ssl-cert`と`ssl-key`両方のパラメータを指定する必要があります。サーバー認証のために`ssl-ca`パラメータを指定することもできます（[認証を有効にする](#enable-authentication)）。 +TiDBサーバーで独自の証明書を使用して安全な接続を有効にするには、TiDBサーバーを起動する際に、設定ファイルで`ssl-cert`と`ssl-key`両方のパラメータを指定する必要があります。サーバー認証のために`ssl-ca`パラメータを指定することもできます（[認証を有効にする](#enable-authentication)）。 パラメータで指定されるファイルはすべてPEM（Privacy Enhanced Mail）形式です。現在、TiDBはパスワードで保護された秘密鍵のインポートをサポートしていないため、パスワードなしの秘密鍵ファイルを提供する必要があります。証明書または秘密鍵が無効な場合、TiDBサーバーは通常どおり起動しますが、クライアントはTLS接続を介してTiDBサーバーに接続できません。 @@ -69,7 +69,7 @@ MySQL 8.xクライアントには、このパラメータに加えて2つのSSL MySQL 5.7および MariaDB クライアント以前のバージョンでは、 `--ssl-verify-server-cert`を使用してサーバー証明書の検証を有効にできます。 -詳細については、「MySQL の[暗号化接続のためのクライアント側コンフィグレーション](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration)を参照してください。 +詳細については、「MySQL の[暗号化接続のためのクライアント側設定](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration)を参照してください。 ## 認証を有効にする {#enable-authentication} diff --git a/encryption-at-rest.md b/encryption-at-rest.md index 599d1840a8689..8488f8458e953 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -68,7 +68,7 @@ TiKVは現在、 CTRモードでAES128、AES192、AES256、またはSM4（バー ### 暗号化を設定する {#configure-encryption} -暗号化を有効にするには、TiKV および PD の構成ファイルに暗号化セクションを追加します。 +暗号化を有効にするには、TiKV および PD の設定ファイルに暗号化セクションを追加します。 ``` [security.encryption] @@ -79,7 +79,7 @@ data-key-rotation-period = "168h" # 7 days - `data-encryption-method`は、暗号化アルゴリズムを指定します。指定可能な値は`"aes128-ctr"` 、 `"aes192-ctr"` 、 `"aes256-ctr"` 、 `"sm4-ctr"` （v6.3.0以降のバージョンのみ）、 `"plaintext"`です。デフォルト値は`"plaintext"`で、暗号化はデフォルトで無効になっています。 - 新しい TiKV クラスターまたは既存の TiKV クラスターの場合、暗号化が有効になった後に書き込まれたデータのみが暗号化されることが保証されます。 - - 暗号化を有効にした後に無効にするには、構成ファイルから`data-encryption-method`を削除するか、その値を`"plaintext"`に設定して、TiKV を再起動します。 + - 暗号化を有効にした後に無効にするには、設定ファイルから`data-encryption-method`を削除するか、その値を`"plaintext"`に設定して、TiKV を再起動します。 - 暗号化アルゴリズムを変更するには、値`data-encryption-method`をサポートされている暗号化アルゴリズムに置き換え、TiKVを再起動します。置き換え後、新しいデータが書き込まれると、以前の暗号化アルゴリズムで生成された暗号化ファイルが、新しい暗号化アルゴリズムで生成されたファイルに徐々に書き換えられます。 - `data-key-rotation-period`は、TiKV がキーをローテーションする頻度を指定します。 @@ -198,7 +198,7 @@ Azure でキーを作成するには、 [Azure ポータルを使用して Azure **ステップ2. マスターキーを設定する** -Azure KMS を使用してマスターキーを指定するには、TiKV 構成ファイルの`[security.encryption]`セクションの後に`[security.encryption.master-key]`構成を追加します。 +Azure KMS を使用してマスターキーを指定するには、TiKV 設定ファイルの`[security.encryption]`セクションの後に`[security.encryption.master-key]`構成を追加します。 ``` [security.encryption.master-key] @@ -306,7 +306,7 @@ AWS でキーを作成するには、TiKV のキーを作成する手順を参 ### 暗号化を設定する {#configure-encryption} -暗号化を有効にするには、 `tiflash-learner.toml`構成ファイルに暗号化セクションを追加します。 +暗号化を有効にするには、 `tiflash-learner.toml`設定ファイルに暗号化セクションを追加します。 ``` [security.encryption] @@ -348,7 +348,7 @@ server_configs: 上記の設定項目の意味は TiKV と同じです。 -ファイルに保存されているマスターキーを指定するには、 `tiflash-learner.toml`構成ファイルに次の構成を追加します。 +ファイルに保存されているマスターキーを指定するには、 `tiflash-learner.toml`設定ファイルに次の構成を追加します。 ``` [security.encryption.master-key] @@ -371,7 +371,7 @@ server_configs: TiFlashのマスターキーをローテーションするには、TiKV のマスターキーをローテーションする手順に従ってください。現在、 TiFlash はオンラインでのマスターキーのローテーションもサポートしていません。そのため、ローテーションを有効にするにはTiFlashを再起動する必要があります。オンラインクエリを処理している稼働中のTiFlashクラスターに対して、ローリング再起動を実行することをお勧めします。 -KMS CMK をローテーションするには、 `tiflash-learner.toml`構成ファイルに次の内容を追加します。 +KMS CMK をローテーションするには、 `tiflash-learner.toml`設定ファイルに次の内容を追加します。 ``` [security.encryption.master-key] diff --git a/explain-joins.md b/explain-joins.md index c02159786f909..41e1aa3135a68 100644 --- a/explain-joins.md +++ b/explain-joins.md @@ -169,7 +169,7 @@ EXPLAIN ANALYZE SELECT * FROM t1 INNER JOIN t2 ON t1.id = t2.t1_id WHERE t1.int_ ヒント[`INL_JOIN`](/optimizer-hints.md#inl_joint1_name--tl_name-)を使用したインデックス結合操作では、外部テーブルに結合する前に中間結果のハッシュテーブルが作成されます。TiDBは、ヒント[`INL_HASH_JOIN`](/optimizer-hints.md#inl_hash_join)を使用した外部テーブルへのハッシュテーブルの作成もサポートしています。これらのインデックス結合の各バリエーションは、SQLオプティマイザによって自動的に選択されます。 -### コンフィグレーション {#configuration} +### 設定 {#configuration} インデックス結合のパフォーマンスは、次のシステム変数の影響を受けます。 @@ -245,7 +245,7 @@ Query OK, 0 rows affected (0.00 sec) 5 rows in set (0.98 sec) ``` -### コンフィグレーション {#configuration} +### 設定 {#configuration} ハッシュ結合のパフォーマンスは、次のシステム変数の影響を受けます。 diff --git a/faq/high-reliability-faq.md b/faq/high-reliability-faq.md index d84c8e57e30d1..39885ce0c11e5 100644 --- a/faq/high-reliability-faq.md +++ b/faq/high-reliability-faq.md @@ -13,7 +13,7 @@ summary: TiDB の高信頼性に関連する FAQ について説明します。 ## 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/filter-binlog-event.md b/filter-binlog-event.md index 70db3345ac627..fc41031410d27 100644 --- a/filter-binlog-event.md +++ b/filter-binlog-event.md @@ -12,9 +12,9 @@ summary: データを移行するときにbinlogイベントをフィルター - [小さなデータセットの MySQL シャードを TiDB に移行してマージする](/migrate-small-mysql-shards-to-tidb.md) - [大規模データセットの MySQL シャードを TiDB に移行およびマージする](/migrate-large-mysql-shards-to-tidb.md) -## コンフィグレーション {#configuration} +## 設定 {#configuration} -binlogイベントフィルターを使用するには、以下に示すように、DM のタスク構成ファイルに`filter`を追加します。 +binlogイベントフィルターを使用するには、以下に示すように、DM のタスク設定ファイルに`filter`を追加します。 ```yaml filters: diff --git a/filter-dml-event.md b/filter-dml-event.md index 89a13400c0c73..024c8baab4bbd 100644 --- a/filter-dml-event.md +++ b/filter-dml-event.md @@ -16,7 +16,7 @@ summary: SQL 式を使用して DML イベントをフィルター処理する この問題に対処するため、DM v2.0.5以降では、増分データレプリケーションにおいて`binlog value filter`を使用したデータのフィルタリングをサポートしています。DM対応の`ROW`形式のbinlogでは、binlogイベントはすべての列の値を保持しており、これらの値に基づいてSQL式を設定できます。式で行の変更が`TRUE`と計算された場合、DMはこの行の変更を下流に複製しません。 -[Binlogイベントフィルター](/filter-binlog-event.md)と同様に、タスク設定ファイルで`binlog value filter`を設定する必要があります。詳細については、以下の設定例を参照してください。詳細なタスク設定と説明については、 [DM 高度なタスク構成ファイル](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced)を参照してください。 +[Binlogイベントフィルター](/filter-binlog-event.md)と同様に、タスク設定ファイルで`binlog value filter`を設定する必要があります。詳細については、以下の設定例を参照してください。詳細なタスク設定と説明については、 [DM 高度なタスク設定ファイル](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced)を参照してください。 ```yaml name: test @@ -54,7 +54,7 @@ MySQL [test]> select * from tbl; 2 rows in set (0.001 sec) ``` -## コンフィグレーションパラメータと説明 {#configuration-parameters-and-description} +## 設定パラメータと説明 {#configuration-parameters-and-description} - `schema` : 一致させる上流スキーマの名前。ワイルドカード一致や通常の一致はサポートされていません。 - `table` : 照合するアップストリームテーブルの名前。ワイルドカードによる照合や通常の照合はサポートされていません。 diff --git a/garbage-collection-configuration.md b/garbage-collection-configuration.md index bf0fa88fab80f..a730bd858a996 100644 --- a/garbage-collection-configuration.md +++ b/garbage-collection-configuration.md @@ -3,7 +3,7 @@ title: Garbage Collection Configuration summary: GC 設定パラメータについて学習します。 --- -# ガベージコレクションのコンフィグレーション {#garbage-collection-configuration} +# ガベージコレクションの設定 {#garbage-collection-configuration} 次のシステム変数を使用してガベージコレクション(GC) を構成できます。 @@ -62,7 +62,7 @@ TiDB v6.1.0では、アクティブなトランザクションがGCセーフポ -次の例は、TiKV 構成ファイルでメカニズムを有効にする方法を示しています。 +次の例は、TiKV 設定ファイルでメカニズムを有効にする方法を示しています。 ```toml [gc] diff --git a/generate-self-signed-certificates.md b/generate-self-signed-certificates.md index 8ea714fffa8bf..7688c29f12979 100644 --- a/generate-self-signed-certificates.md +++ b/generate-self-signed-certificates.md @@ -103,7 +103,7 @@ TiKV インスタンスに証明書を発行するには、次の手順を実行 IP.4 = 172.16.10.16 ``` -4. `openssl.cnf`ファイルを保存し、証明書リクエストファイルを生成します (この手順では、証明書に共通名を割り当てることもできます。共通名は、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントはデフォルトで検証を有効にしませんが、構成ファイルで有効にすることができます)。 +4. `openssl.cnf`ファイルを保存し、証明書リクエストファイルを生成します (この手順では、証明書に共通名を割り当てることもできます。共通名は、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントはデフォルトで検証を有効にしませんが、設定ファイルで有効にすることができます)。 ```bash openssl req -new -key tikv.key -out tikv.csr -config openssl.cnf @@ -141,7 +141,7 @@ TiKV インスタンスに証明書を発行するには、次の手順を実行 openssl genrsa -out client.key 2048 ``` -2. 証明書リクエストファイルを生成します (この手順では、証明書に共通名を割り当てることもできます。共通名は、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントはデフォルトで検証を有効にしませんが、構成ファイルで有効にすることができます)。 +2. 証明書リクエストファイルを生成します (この手順では、証明書に共通名を割り当てることもできます。共通名は、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントはデフォルトで検証を有効にしませんが、設定ファイルで有効にすることができます)。 ```bash openssl req -new -key client.key -out client.csr diff --git a/geo-distributed-deployment-topology.md b/geo-distributed-deployment-topology.md index df54ade748594..7bd85ed830e02 100644 --- a/geo-distributed-deployment-topology.md +++ b/geo-distributed-deployment-topology.md @@ -24,7 +24,7 @@ summary: TiDB の地理的に分散された展開トポロジについて学習 - [地理的に分散したトポロジテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/geo-redundancy-deployment.yaml) -上記の TiDB クラスター トポロジファイルの設定項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 +上記の TiDB クラスター トポロジファイルの設定項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジ設定ファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 ### 主なパラメータ {#key-parameters} diff --git a/get-started-with-tidb-lightning.md b/get-started-with-tidb-lightning.md index a11ce811ab3de..00644906c363c 100644 --- a/get-started-with-tidb-lightning.md +++ b/get-started-with-tidb-lightning.md @@ -62,7 +62,7 @@ tiup install tidb-lightning > > このセクションのインポート方法は、テストと機能体験にのみ適しています。本番環境については、 [MySQLからTiDBへの大規模データセットの移行](/migrate-large-mysql-to-tidb.md)を参照してください。 -1. 構成ファイル`tidb-lightning.toml`を作成し、クラスタ情報に基づいて以下の設定を入力してください。 +1. 設定ファイル`tidb-lightning.toml`を作成し、クラスタ情報に基づいて以下の設定を入力してください。 ```toml [lightning] diff --git a/hybrid-deployment-topology.md b/hybrid-deployment-topology.md index 54cc11a25c7bd..221e3b90d9060 100644 --- a/hybrid-deployment-topology.md +++ b/hybrid-deployment-topology.md @@ -29,7 +29,7 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて - [ハイブリッドデプロイのためのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-multi-instance.yaml) - [ハイブリッドデプロイのための複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-multi-instance.yaml) -上記の TiDB クラスター トポロジファイルの設定項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 +上記の TiDB クラスター トポロジファイルの設定項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジ設定ファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 ### 主なパラメータ {#key-parameters} @@ -99,7 +99,7 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて > **Note:** > -> - 構成ファイル テンプレートを編集するときは、必要なパラメータ、IP、ポート、およびディレクトリを変更します。 +> - 設定ファイル テンプレートを編集するときは、必要なパラメータ、IP、ポート、およびディレクトリを変更します。 > - 各コンポーネントでは、グローバルポートの`/-`がデフォルトの`deploy_dir`として使用されます。例えば、TiDBにポート`4001`を指定した場合、そのポートの`deploy_dir`はデフォルトで`/tidb-deploy/tidb-4001`になります。したがって、マルチインスタンスのシナリオでは、デフォルト以外のポートを指定する場合でも、ディレクトリを再度指定する必要はありません。 > - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPTiUPコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、コントロールマシンと同じユーザーを維持することもできます。 > - デプロイメントディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index f2d1df785b0eb..256ce543ebaab 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -214,7 +214,7 @@ select * from information_schema.inspection_rules where type='inspection'; - 以下の設定項目の値が期待どおりであるかどうかを確認します。 - | コンポーネント | コンフィグレーション項目 | しきい値 | + | コンポーネント | 設定項目 | しきい値 | | ---- | ------------------ | -------- | | TiDB | log.slow-threshold | `0`より大きい | diff --git a/maintain-tidb-using-tiup.md b/maintain-tidb-using-tiup.md index f76cff887a96e..bf03a97a0e98d 100644 --- a/maintain-tidb-using-tiup.md +++ b/maintain-tidb-using-tiup.md @@ -63,7 +63,7 @@ tiup cluster display ${cluster-name} クラスタの稼働中にコンポーネントのパラメータを変更する必要がある場合は、コマンド`edit-config`を実行してください。詳細な手順は次のとおりです。 -1. クラスターの構成ファイルを編集モードで開きます。 +1. クラスターの設定ファイルを編集モードで開きます。 ```bash tiup cluster edit-config ${cluster-name} diff --git a/migrate-aurora-to-tidb.md b/migrate-aurora-to-tidb.md index 71c224d3765ed..b7c1feddf6e14 100644 --- a/migrate-aurora-to-tidb.md +++ b/migrate-aurora-to-tidb.md @@ -109,7 +109,7 @@ nohup tiup tidb-lightning -config tidb-lightning-schema.toml > nohup.out 2>&1 & 2. Amazon Auroraスナップショットをエクスポートします。詳細な手順については、 [DBスナップショットデータをAmazon S3にエクスポートする](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_ExportSnapshot.html)を参照してください。binlogの位置を取得したら、5分以内にスナップショットをエクスポートします。そうしないと、記録されたbinlogの位置が古くなり、増分レプリケーション中にデータの競合が発生する可能性があります。 -#### 2.2 データファイル用のTiDB Lightning構成ファイルを作成する {#2-2-create-the-tidb-lightning-configuration-file-for-the-data-file} +#### 2.2 データファイル用のTiDB Lightning設定ファイルを作成する {#2-2-create-the-tidb-lightning-configuration-file-for-the-data-file} 新しい`tidb-lightning-data.toml`設定ファイルを作成し、以下の内容をファイルにコピーして、対応する内容を置き換えます。 @@ -253,7 +253,7 @@ mysql-instances: # safe-mode: true # If this field is set to true, DM changes INSERT of the data source to REPLACE for the target database, and changes UPDATE of the data source to DELETE and REPLACE for the target database. This is to ensure that when the table schema contains a primary key or unique index, DML statements can be imported repeatedly. In the first minute of starting or resuming an incremental replication task, DM automatically enables the safe mode. ``` -上記の YAML ファイルは、移行タスクに必要な最小構成です。その他の設定項目については、 [DM 高度タスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 +上記の YAML ファイルは、移行タスクに必要な最小構成です。その他の設定項目については、 [DM 高度タスク設定ファイル](/dm/task-configuration-file-full.md)を参照してください。 ### ステップ3. マイグレーションタスクを実行する {#step-3-run-the-migration-task} diff --git a/migrate-from-csv-files-to-tidb.md b/migrate-from-csv-files-to-tidb.md index 0749b64c73d11..a0e4692213203 100644 --- a/migrate-from-csv-files-to-tidb.md +++ b/migrate-from-csv-files-to-tidb.md @@ -90,7 +90,7 @@ status-port = "${status-port}" # During the import, TiDB Lightning needs to obta pd-addr = "${ip}:${port}" # The address of the PD cluster, e.g.: 172.16.31.3:2379. TiDB Lightning obtains some information from PD. When backend = "local", you must specify status-port and pd-addr correctly. Otherwise, the import will be abnormal. ``` -設定ファイルの詳細については、 [TiDB Lightning のコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 +設定ファイルの詳細については、 [TiDB Lightning の設定](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 ## ステップ4．インポートパフォーマンスの調整（オプション） {#step-4-tune-the-import-performance-optional} diff --git a/migrate-from-sql-files-to-tidb.md b/migrate-from-sql-files-to-tidb.md index 07c0d2a089653..a776e1f6489f7 100644 --- a/migrate-from-sql-files-to-tidb.md +++ b/migrate-from-sql-files-to-tidb.md @@ -63,7 +63,7 @@ status-port = "${status-port}" # During the import process, TiDB Lightning need pd-addr = "${ip}:${port}" # The address of the cluster's PD. TiDB Lightning obtains some information through PD, such as 172.16.31.3:2379. When backend = "local", you must correctly specify status-port and pd-addr. Otherwise, the import will encounter errors. ``` -設定ファイルの詳細については、 [TiDB Lightning のコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 +設定ファイルの詳細については、 [TiDB Lightning の設定](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 ## ステップ4．データのインポート {#step-4-import-the-data} diff --git a/migrate-from-tidb-to-mysql.md b/migrate-from-tidb-to-mysql.md index 064df0b3123d5..441dad48f2f50 100644 --- a/migrate-from-tidb-to-mysql.md +++ b/migrate-from-tidb-to-mysql.md @@ -124,7 +124,7 @@ summary: TiDB から MySQL 互換データベースにデータを移行する sync_diff_inspector -C ./config.yaml ``` - sync-diff-inspector の設定方法の詳細については[コンフィグレーションファイルの説明](/sync-diff-inspector/sync-diff-inspector-overview.md#configuration-file-description)を参照してください。このドキュメントでは、設定は以下のとおりです。 + sync-diff-inspector の設定方法の詳細については[設定ファイルの説明](/sync-diff-inspector/sync-diff-inspector-overview.md#configuration-file-description)を参照してください。このドキュメントでは、設定は以下のとおりです。 ```toml # Diff Configuration. diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index 3240b03487b43..6d1f3a79afefd 100644 --- a/migrate-from-tidb-to-tidb.md +++ b/migrate-from-tidb-to-tidb.md @@ -184,7 +184,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー sync_diff_inspector -C ./config.yaml ``` - sync-diff-inspector の設定方法の詳細については[コンフィグレーションファイルの説明](/sync-diff-inspector/sync-diff-inspector-overview.md#configuration-file-description)を参照してください。このドキュメントでは、設定は以下のとおりです。 + sync-diff-inspector の設定方法の詳細については[設定ファイルの説明](/sync-diff-inspector/sync-diff-inspector-overview.md#configuration-file-description)を参照してください。このドキュメントでは、設定は以下のとおりです。 ```shell # Diff Configuration. diff --git a/migrate-from-vitess.md b/migrate-from-vitess.md index 258b97eb3c940..85824e7f932de 100644 --- a/migrate-from-vitess.md +++ b/migrate-from-vitess.md @@ -9,7 +9,7 @@ summary: Vitess から TiDB にデータを移行するためのツールにつ VitessのバックエンドはMySQLベースであるため、VitessからTiDBにデータを移行する際には、MySQLに適用できるものと[Dumpling](/dumpling-overview.md)、[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)、[TiDB Data Migration (DM)](/dm/dm-overview.md)などの同じ移行ツールを使用できます。これらのツールは、データ移行のためにVitess内の各シャードに対して設定する必要があることに注意してください。 -通常、データ移行前にDMタスクの`task-mode`を`all`に、`import-mode`を`physical`に設定することを推奨します。詳細については、 [タスク構成ファイルテンプレート（上級）](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced)を参照してください。 +通常、データ移行前にDMタスクの`task-mode`を`all`に、`import-mode`を`physical`に設定することを推奨します。詳細については、 [タスク設定ファイルテンプレート（上級）](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced)を参照してください。 データサイズが 10 TiB を超える場合は、2つの手順でインポートを実行することをお勧めします。 diff --git a/migrate-large-mysql-shards-to-tidb.md b/migrate-large-mysql-shards-to-tidb.md index 153190b2f6064..b39f340e44e6e 100644 --- a/migrate-large-mysql-shards-to-tidb.md +++ b/migrate-large-mysql-shards-to-tidb.md @@ -255,7 +255,7 @@ tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml ### レプリケーションタスクを作成する {#create-a-replication-task} -`task.yaml`という名前のタスク構成ファイルを編集して、各データソースの増分レプリケーションモードとレプリケーション開始点を設定します。 +`task.yaml`という名前のタスク設定ファイルを編集して、各データソースの増分レプリケーションモードとレプリケーション開始点を設定します。 ```yaml name: task-test # The name of the task. Should be globally unique. @@ -320,7 +320,7 @@ mysql-instances: # safe-mode: true ``` -その他の構成については、 [DM 高度タスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 +その他の構成については、 [DM 高度タスク設定ファイル](/dm/task-configuration-file-full.md)を参照してください。 データ移行タスクを開始する前に、 `check-task`の`tiup dmctl`サブコマンドを使用して、構成が DM 構成要件を満たしているかどうかを確認することをお勧めします。 @@ -376,6 +376,6 @@ tiup dmctl --master-addr ${advertise-addr} query-status ${task-name} - [データ移行タスクを一時停止する](/dm/dm-pause-task.md) - [データ移行タスクを再開する](/dm/dm-resume-task.md) - [データ移行タスクを停止する](/dm/dm-stop-task.md) -- [クラスターのデータソースのエクスポートとインポート、およびタスクコンフィグレーション](/dm/dm-export-import-config.md) +- [クラスターのデータソースのエクスポートとインポート、およびタスク設定](/dm/dm-export-import-config.md) - [失敗したDDL文を処理する](/dm/handle-failed-ddl-statements.md) - [エラーを処理する](/dm/dm-error-handling.md) diff --git a/migrate-large-mysql-to-tidb.md b/migrate-large-mysql-to-tidb.md index 2e4c1d86c78de..dc220955a58d0 100644 --- a/migrate-large-mysql-to-tidb.md +++ b/migrate-large-mysql-to-tidb.md @@ -134,7 +134,7 @@ LIMIT pd-addr = "${ip}:${port}" # The address of the PD cluster, e.g.: 172.16.31.3:2379. TiDB Lightning obtains some information from PD. When backend = "local", you must specify status-port and pd-addr correctly. Otherwise, the import will be abnormal. ``` - TiDB Lightning構成の詳細については、 [TiDB Lightning のコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 + TiDB Lightning構成の詳細については、 [TiDB Lightning の設定](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 2. `tidb-lightning`を実行してインポートを開始します。コマンドラインでプログラムを直接起動すると、SIGHUP シグナルを受信した後にプロセスが予期せず終了する可能性があります。 `nohup`を使用してコマンドラインからプロセスを直接起動することは推奨されません。代わりに、次のスクリプトの内容を編集してください。例: @@ -232,7 +232,7 @@ LIMIT # safe-mode: true # If this field is set to true, DM changes INSERT of the data source to REPLACE for the target database, and changes UPDATE of the data source to DELETE and REPLACE for the target database. This is to ensure that when the table schema contains a primary key or unique index, DML statements can be imported repeatedly. In the first minute of starting or resuming an incremental replication task, DM automatically enables the safe mode. ``` - 上記の YAML は、移行タスクに必要な最小構成です。その他の設定項目については、 [DM 高度タスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 + 上記の YAML は、移行タスクに必要な最小構成です。その他の設定項目については、 [DM 高度タスク設定ファイル](/dm/task-configuration-file-full.md)を参照してください。 移行作業を開始する前に、エラーの可能性を減らすため、 `check-task`コマンドを実行して、構成が DM の要件を満たしていることを確認することをお勧めします。 @@ -283,5 +283,5 @@ DMが実行されている間、DM-worker、DM-master、およびdmctlは関連 - [データ移行タスクを一時停止する](/dm/dm-pause-task.md) - [データ移行タスクを再開する](/dm/dm-resume-task.md) - [データ移行タスクを停止する](/dm/dm-stop-task.md) -- [クラスターのデータソースのエクスポートとインポート、およびタスクコンフィグレーション](/dm/dm-export-import-config.md) +- [クラスターのデータソースのエクスポートとインポート、およびタスク設定](/dm/dm-export-import-config.md) - [失敗したDDL文を処理する](/dm/handle-failed-ddl-statements.md) diff --git a/migrate-small-mysql-shards-to-tidb.md b/migrate-small-mysql-shards-to-tidb.md index 69d75a912d5fa..b763da7906fb9 100644 --- a/migrate-small-mysql-shards-to-tidb.md +++ b/migrate-small-mysql-shards-to-tidb.md @@ -96,7 +96,7 @@ tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml ## ステップ2. 移行タスクを構成する {#step-2-configure-the-migration-task} -`task1.yaml`という名前のタスク構成ファイルを作成し、次の内容を書き込みます。 +`task1.yaml`という名前のタスク設定ファイルを作成し、次の内容を書き込みます。 ```yaml name: "shard_merge" # The name of the task. Should be globally unique. @@ -166,7 +166,7 @@ block-allow-list: # filter or only migrate all operations of some data do-dbs: ["store_*"] # The allow list of the schemas to be migrated, similar to replicate-do-db in MySQL. ``` -上記の例は、移行タスクを実行するための最小限の構成です。詳細については、 [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 +上記の例は、移行タスクを実行するための最小限の構成です。詳細については、 [DM 高度なタスク設定ファイル](/dm/task-configuration-file-full.md)を参照してください。 タスク ファイル内の`routes` 、およびその他`filters`構成の詳細については、次のドキュメントを参照してください。 diff --git a/migrate-small-mysql-to-tidb.md b/migrate-small-mysql-to-tidb.md index 9e780e430a586..d4b222c9888e4 100644 --- a/migrate-small-mysql-to-tidb.md +++ b/migrate-small-mysql-to-tidb.md @@ -83,7 +83,7 @@ block-allow-list: ``` -上記は移行を実行するための最小限のタスク構成です。タスクに関する詳細な設定項目については、 [DMタスクの完全な構成ファイルの紹介](/dm/task-configuration-file-full.md)を参照してください。 +上記は移行を実行するための最小限のタスク構成です。タスクに関する詳細な設定項目については、 [DMタスクの完全な設定ファイルの紹介](/dm/task-configuration-file-full.md)を参照してください。 ## ステップ3. 移行タスクを開始する {#step-3-start-the-migration-task} diff --git a/migrate-with-more-columns-downstream.md b/migrate-with-more-columns-downstream.md index 600146753ff04..10bd599b1c088 100644 --- a/migrate-with-more-columns-downstream.md +++ b/migrate-with-more-columns-downstream.md @@ -80,7 +80,7 @@ DM がダウンストリームテーブルスキーマを使用してアップ | `-master-addr` | dmctl が接続されるクラスター内の任意の DM-masterノードの`${advertise-addr}`を指定します。`${advertise-addr}`は 、DM-masterが外部にアドバタイズするアドレスを示します。 | | `binlog-schema set` | スキーマ情報を手動で設定します。 | | `-s` | ソースを指定します。`${source-id}`は MySQL データのソース ID を示します。 | - | `${task-name}` | データ移行タスクの`task.yaml`構成ファイルで定義されている移行タスクの名前を指定します。 | + | `${task-name}` | データ移行タスクの`task.yaml`設定ファイルで定義されている移行タスクの名前を指定します。 | | `${database-name}` | データベースを指定します。`${database-name}`はアップストリーム データベースの名前を示します。 | | `${table-name}` | アップストリームテーブルの名前を指定します。 | | `${schema-file}` | 設定するテーブルスキーマファイルを指定します。 | diff --git a/migrate-with-pt-ghost.md b/migrate-with-pt-ghost.md index 2a6ab9edd289d..5d627edef11ee 100644 --- a/migrate-with-pt-ghost.md +++ b/migrate-with-pt-ghost.md @@ -18,7 +18,7 @@ DM を使用して MySQL から TiDB にデータを移行する場合、 `onlin ## DM でオンライン DDL を有効にする {#enable-online-ddl-on-dm} -DM のタスク構成ファイルで、以下に示すように、グローバル パラメータ`online-ddl`を`true`に設定します。 +DM のタスク設定ファイルで、以下に示すように、グローバル パラメータ`online-ddl`を`true`に設定します。 ```yaml # ----------- Global configuration ----------- diff --git a/minimal-deployment-topology.md b/minimal-deployment-topology.md index 906311087d045..406bdb4a77656 100644 --- a/minimal-deployment-topology.md +++ b/minimal-deployment-topology.md @@ -25,7 +25,7 @@ summary: TiDB クラスターの最小限のデプロイメント トポロジ - [最小トポロジーのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-mini.yaml) - [最小トポロジーの複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-mini.yaml) -上記の TiDB クラスター トポロジファイルの設定項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 +上記の TiDB クラスター トポロジファイルの設定項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジ設定ファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 > **Note:** > diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md index 48d1912d10ac2..269e0eb958931 100644 --- a/multi-data-centers-in-one-city-deployment.md +++ b/multi-data-centers-in-one-city-deployment.md @@ -107,11 +107,11 @@ TiKVはMulti-Raftシステムであり、データは複数のリージョンに 3つのレプリカで構成されるRaftグループは、1つのレプリカ障害しか許容しないため、クラスターをN個のTiKVインスタンスにスケールアウトした場合でも、このクラスターが許容するレプリカ障害は1つだけです。2つのTiKVインスタンスに障害が発生すると、一部のリージョンでレプリカが失われ、このクラスター内のデータが不完全になる可能性があります。これらのリージョンのデータにアクセスするSQLリクエストは失敗します。N個のTiKVインスタンス間で2つの同時障害が発生する確率は、3個のTiKVインスタンス間で2つの同時障害が発生する確率よりもはるかに高くなります。つまり、Multi-RaftシステムをスケールアウトしてTiKVインスタンスの数を増やすほど、システムの可用性は低下します。 -上記の制限のため、TiKVの位置情報の記述には`label`が使用されます。ラベル情報は、デプロイメントまたはローリングアップグレード操作によってTiKV起動構成ファイルに更新されます。起動されたTiKVは、最新のラベル情報をPDに報告します。PDは、ユーザーが登録したラベル名（ラベルメタデータ）とTiKVトポロジに基づいて、リージョンレプリカを最適にスケジュールし、システムの可用性を向上させます。 +上記の制限のため、TiKVの位置情報の記述には`label`が使用されます。ラベル情報は、デプロイメントまたはローリングアップグレード操作によってTiKV起動設定ファイルに更新されます。起動されたTiKVは、最新のラベル情報をPDに報告します。PDは、ユーザーが登録したラベル名（ラベルメタデータ）とTiKVトポロジに基づいて、リージョンレプリカを最適にスケジュールし、システムの可用性を向上させます。 #### TiKVラベルの計画例 {#tikv-labels-planning-example} -システムの可用性と災害復旧能力を向上させるには、既存の物理リソースと災害復旧能力に応じてTiKVラベルを設計・計画する必要があります。また、計画されているトポロジに応じて、クラスタ初期化構成ファイルを編集する必要があります。 +システムの可用性と災害復旧能力を向上させるには、既存の物理リソースと災害復旧能力に応じてTiKVラベルを設計・計画する必要があります。また、計画されているトポロジに応じて、クラスタ初期化設定ファイルを編集する必要があります。 ```ini server_configs: diff --git a/pd-configuration-file.md b/pd-configuration-file.md index ca0c0606fff4a..4a5c8361f7eef 100644 --- a/pd-configuration-file.md +++ b/pd-configuration-file.md @@ -1,9 +1,9 @@ --- title: PD Configuration File -summary: PD 構成ファイルについて学習します。 +summary: PD 設定ファイルについて学習します。 --- -# PDコンフィグレーションファイル {#pd-configuration-file} +# PD設定ファイル {#pd-configuration-file} @@ -127,7 +127,7 @@ PD設定ファイルは、コマンドラインパラメータよりも多くの ## pd-server {#pd-server} -pd-server関連のコンフィグレーション項目 +pd-server関連の設定項目 ### `server-memory-limit` v6.6.0 の新機能 {#server-memory-limit-new-in-v660} @@ -193,7 +193,7 @@ pd-server関連のコンフィグレーション項目 ## security {#security} -セキュリティ関連のコンフィグレーション項目 +セキュリティ関連の設定項目 ### `cacert-path` {#cacert-path} @@ -219,7 +219,7 @@ pd-server関連のコンフィグレーション項目 ## `log` {#log} -ログ関連のコンフィグレーション項目 +ログ関連の設定項目 ### `level` {#level} @@ -240,7 +240,7 @@ pd-server関連のコンフィグレーション項目 ## `log.file` {#log-file} -ログファイルに関連するコンフィグレーション項目 +ログファイルに関連する設定項目 ### `max-size` {#max-size} @@ -263,7 +263,7 @@ pd-server関連のコンフィグレーション項目 ## `metric` {#metric} -監視に関連するコンフィグレーション項目 +監視に関連する設定項目 ### `interval` {#interval} @@ -272,13 +272,13 @@ pd-server関連のコンフィグレーション項目 ## `schedule` {#schedule} -スケジュールに関連するコンフィグレーション項目 +スケジュールに関連する設定項目 > **Note:** > > `schedule`に関連するこれらの PD 設定項目を変更するには、クラスターのステータスに基づいて次のいずれかの方法を選択します。 > -> - 新しくデプロイするクラスターの場合は、PD 構成ファイルを直接変更できます。 +> - 新しくデプロイするクラスターの場合は、PD 設定ファイルを直接変更できます。 > - 既存のクラスターの場合は、コマンドラインツール[PD Control](/pd-control.md)を使用して変更を加えてください。設定ファイル内の`schedule`に関連するPD設定項目を直接変更しても、既存のクラスターには反映されません。 ### `max-merge-region-size` {#max-merge-region-size} @@ -458,7 +458,7 @@ pd-server関連のコンフィグレーション項目 ## `replication` {#replication} -レプリカに関連するコンフィグレーション項目 +レプリカに関連する設定項目 ### `max-replicas` {#max-replicas} @@ -490,7 +490,7 @@ pd-server関連のコンフィグレーション項目 ## `label-property` （非推奨） {#label-property-deprecated} -ラベルに関連するコンフィグレーション項目`reject-leader`型のみをサポートします。 +ラベルに関連する設定項目`reject-leader`型のみをサポートします。 > **Note:** > @@ -508,7 +508,7 @@ pd-server関連のコンフィグレーション項目 ## `dashboard` {#dashboard} -[TiDB Dashboard](/dashboard/dashboard-intro.md)内蔵 PD に関するコンフィグレーション項目です。 +[TiDB Dashboard](/dashboard/dashboard-intro.md)内蔵 PD に関する設定項目です。 ### `disable-custom-prom-addr` {#disable-custom-prom-addr} @@ -548,7 +548,7 @@ pd-server関連のコンフィグレーション項目 ## `replication-mode` {#replication-mode} -全リージョンのレプリケーションモードに関するコンフィグレーション項目です。詳細は[DR自動同期モードを有効にする](/two-data-centers-in-one-city-deployment.md#enable-the-dr-auto-sync-mode)ご覧ください。 +全リージョンのレプリケーションモードに関する設定項目です。詳細は[DR自動同期モードを有効にする](/two-data-centers-in-one-city-deployment.md#enable-the-dr-auto-sync-mode)ご覧ください。 ## controller {#controller} diff --git a/pd-microservices-deployment-topology.md b/pd-microservices-deployment-topology.md index 83ad3405824a1..35e93f57ded17 100644 --- a/pd-microservices-deployment-topology.md +++ b/pd-microservices-deployment-topology.md @@ -80,12 +80,12 @@ grafana_servers: -前述の TiDB クラスター トポロジファイルの設定項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジ構成ファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 +前述の TiDB クラスター トポロジファイルの設定項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジ設定ファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 ### 主なパラメータ {#key-parameters} - `tso_servers`のインスタンスのレベル`host`構成では、ドメイン名ではなく IP アドレスのみがサポートされます。 -- TSO 設定項目の詳細については、 [TSO 構成ファイル](/tso-configuration-file.md)を参照してください。 +- TSO 設定項目の詳細については、 [TSO 設定ファイル](/tso-configuration-file.md)を参照してください。 - `scheduling_servers`のインスタンスのレベル`host`構成では、ドメイン名ではなく IP アドレスのみがサポートされます。 - スケジュール設定項目の詳細については、 [スケジュール設定ファイル](/scheduling-configuration-file.md)を参照してください。 diff --git a/performance-tuning-overview.md b/performance-tuning-overview.md index 28f35b7acc167..e76615a41d014 100644 --- a/performance-tuning-overview.md +++ b/performance-tuning-overview.md @@ -88,7 +88,7 @@ summary: このドキュメントでは、ユーザー応答時間、スルー - CPU、IO、ネットワークなどのリソース使用率 -- アプリケーション構成、データベース構成、オペレーティングシステム構成などのコンフィグレーション情報 +- アプリケーション構成、データベース構成、オペレーティングシステム構成などの設定情報 ### ステップ3. ユーザー応答時間のボトルネックを特定する {#step-3-identify-bottlenecks-in-user-response-time} diff --git a/production-deployment-using-tiup.md b/production-deployment-using-tiup.md index 52b685bd68b60..d635f73243f82 100644 --- a/production-deployment-using-tiup.md +++ b/production-deployment-using-tiup.md @@ -16,7 +16,7 @@ TiUPは、TiDB、 TiFlash、TiCDC、および監視システムのデプロイ 以下の文書を必ずお読みください。 - [TiDBのソフトウェアおよびハードウェア要件](/hardware-and-software-requirements.md) -- [TiDB環境およびシステムコンフィグレーションチェック](/check-before-deployment.md) +- [TiDB環境およびシステム設定チェック](/check-before-deployment.md) さらに、 [TiDBセキュリティ設定のベストプラクティス](/best-practices-for-security-configuration.md)について学習することをお勧めします。 @@ -251,15 +251,15 @@ alertmanager_servers: - host: 10.0.1.4 ``` -以下の例では、6つの一般的なシナリオを取り上げています。対応するリンク先のトポロジーの説明とテンプレートに従って、構成ファイル（ `topology.yaml`という名前）を変更する必要があります。その他のシナリオについては、構成テンプレートを適切に編集してください。 +以下の例では、6つの一般的なシナリオを取り上げています。対応するリンク先のトポロジーの説明とテンプレートに従って、設定ファイル（ `topology.yaml`という名前）を変更する必要があります。その他のシナリオについては、構成テンプレートを適切に編集してください。 -| 応用 | コンフィグレーションタスク | コンフィグレーションファイルテンプレート | トポロジーの説明 | +| 用途 | 設定タスク | 設定ファイルテンプレート | トポロジーの説明 | | :----------------------------------------------- | :------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------- | | OLTP | [最小限のトポロジーをデプロイ](/minimal-deployment-topology.md) | [シンプルな最小限の構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-mini.yaml)
[完全な最小構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-mini.yaml) | これは、tidb-server、tikv-server、およびpd-serverを含む基本的なクラスタトポロジーです。 | | HTAP | [TiFlashトポロジーをデプロイ](/tiflash-deployment-topology.md) | [シンプルなTiFlash設定テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiflash.yaml)
[TiFlashの完全な構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-tiflash.yaml) | これは、最小限のクラスタトポロジーとともにTiFlashをデプロイするためのものです。TiFlashは列指向ストレージエンジンであり、徐々に標準的なクラスタトポロジーへと進化していきます。 | | [TiCDC](/ticdc/ticdc-overview.md)を使用して増分データを複製する | [TiCDCトポロジーをデプロイ](/ticdc-deployment-topology.md) | [シンプルなTiCDC構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-cdc.yaml)
[TiCDC構成テンプレート全体](https://github.com/pingcap/docs/blob/master/config-templates/complex-cdc.yaml) | これは、最小限のクラスタトポロジーとともにTiCDCをデプロイするためのものです。TiCDCは、TiDB、MySQL、Kafka、MQ、ストレージサービスなど、複数のダウンストリームプラットフォームをサポートしています。 | | 1台のマシンに複数のインスタンスをデプロイ | [ハイブリッドトポロジーをデプロイ](/hybrid-deployment-topology.md) | [ハイブリッドデプロイ用のシンプルな構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-multi-instance.yaml)
[ハイブリッドデプロイ用の完全な構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-multi-instance.yaml) | ディレクトリ、ポート、リソース比率、ラベルなどの追加設定が必要な場合にも、展開トポロジが適用されます。 | -| TiDBクラスターをデータセンター全体にデプロイ | [地理的に分散した展開トポロジをデプロイ](/geo-distributed-deployment-topology.md) | [地理的に分散したデプロイメントのためのコンフィグレーションテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/geo-redundancy-deployment.yaml) | このトポロジーは、2つの都市に3つのデータセンターを配置する典型的なアーキテクチャを例として取り上げています。地理的に分散したデプロイメントアーキテクチャと、注意すべき重要な構成について解説します。 | +| TiDBクラスターをデータセンター全体にデプロイ | [地理的に分散した展開トポロジをデプロイ](/geo-distributed-deployment-topology.md) | [地理的に分散したデプロイメントのための設定テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/geo-redundancy-deployment.yaml) | このトポロジーは、2つの都市に3つのデータセンターを配置する典型的なアーキテクチャを例として取り上げています。地理的に分散したデプロイメントアーキテクチャと、注意すべき重要な構成について解説します。 | > **Note:** > diff --git a/quick-start-with-tidb.md b/quick-start-with-tidb.md index 847671db12da7..d3fdb720cfc30 100644 --- a/quick-start-with-tidb.md +++ b/quick-start-with-tidb.md @@ -338,7 +338,7 @@ TiDBクラスタの最小トポロジーは、以下のインスタンスで構 6. クラスターを作成して起動します。 - 次のテンプレートに従って[トポロジー構成ファイル](/tiup/tiup-cluster-topology-reference.md)を作成および編集し、 `topo.yaml`という名前を付けます。 + 次のテンプレートに従って[トポロジー設定ファイル](/tiup/tiup-cluster-topology-reference.md)を作成および編集し、 `topo.yaml`という名前を付けます。 ```yaml # # Global variables are applied to all deployments and used as the default value of diff --git a/releases/release-2.0-ga.md b/releases/release-2.0-ga.md index 0d864d2e41c2e..3d994757c234f 100644 --- a/releases/release-2.0-ga.md +++ b/releases/release-2.0-ga.md @@ -28,21 +28,21 @@ summary: 2018年4月27日にリリースされたTiDB 2.0 GAでは、MySQLとの - `Insert On Duplicate Key Update`文を最適化すると、パフォーマンスが10倍以上向上します - `Load Data`を最適化してパフォーマンスを10倍以上向上 - より多くのデータ型と関数を TiKV にプッシュダウン - - 物理オペレーターのメモリ使用量を計算し、メモリ使用量がしきい値を超えた場合の処理動作を構成ファイルとシステム変数で指定することをサポートします。 + - 物理オペレーターのメモリ使用量を計算し、メモリ使用量がしきい値を超えた場合の処理動作を設定ファイルとシステム変数で指定することをサポートします。 - OOM のリスクを軽減するために、単一の SQL 文によるメモリ使用量の制限をサポートします。 - CRUD 操作で暗黙的な RowID の使用をサポート - ポイントクエリのパフォーマンスを向上 - サーバ - プロキシプロトコルをサポートする - 監視メトリックを追加し、ログを改良する - - 構成ファイルの検証をサポート + - 設定ファイルの検証をサポート - HTTP API 経由で TiDB パラメータの情報を取得する機能をサポート - バッチモードでロックを解決してガベージコレクションを高速化します - マルチスレッドガベージコレクションをサポート - TLSをサポート - 互換性 - より多くのMySQL構文をサポート - - OGGデータレプリケーションツールをサポートするために、構成ファイル内の`lower_case_table_names`システム変数を変更することをサポートします。 + - OGGデータレプリケーションツールをサポートするために、設定ファイル内の`lower_case_table_names`システム変数を変更することをサポートします。 - Navicat管理ツールとの互換性を向上 - テーブル作成時刻を`Information_Schema`で表示できるようになりました - 一部の関数/式の戻り値の型がMySQLと異なる問題を修正しました diff --git a/releases/release-2.0-rc.1.md b/releases/release-2.0-rc.1.md index bb26add1723d2..ff01a44a0191d 100644 --- a/releases/release-2.0-rc.1.md +++ b/releases/release-2.0-rc.1.md @@ -11,7 +11,7 @@ summary: 2018年3月9日にリリースされたTiDB 2.0 RC1では、MySQLとの - OOMのリスクを軽減するために、単一のSQL文によるメモリ使用量の制限をサポートします。 - Stream Aggregate オペレーターを TiKV にプッシュダウンする機能をサポート -- 構成ファイルの検証をサポート +- 設定ファイルの検証をサポート - HTTP API 経由で TiDB 構成情報を取得する機能をサポート - パーサーのより多くのMySQL構文と互換性がある - Navicatとの互換性を向上 diff --git a/releases/release-2.0-rc.3.md b/releases/release-2.0-rc.3.md index 78b45bc354a22..335086bb66440 100644 --- a/releases/release-2.0-rc.3.md +++ b/releases/release-2.0-rc.3.md @@ -23,7 +23,7 @@ summary: 2018年3月23日にリリースされたTiDB 2.0 RC3では、MySQLと - 災害復旧のために`ADMIN RECOVER INDEX`を使用してインデックスデータの復旧をサポート - オンラインビジネスへの影響を軽減するために、 `ADD INDEX`操作の優先度を下げます。 - JSON型パラメータを使った集計関数をサポートする（例：`SUM/AVG`）。 -- OGGデータレプリケーションツールをサポートするために、構成ファイル内の`lower_case_table_names`システム変数の変更をサポートします。 +- OGGデータレプリケーションツールをサポートするために、設定ファイル内の`lower_case_table_names`システム変数の変更をサポートします。 - Navicat管理ツールとの互換性を向上 - CRUD 操作で暗黙的な RowID の使用をサポート diff --git a/releases/release-2.0.4.md b/releases/release-2.0.4.md index 5ab178a1ebe9f..38306b704c212 100644 --- a/releases/release-2.0.4.md +++ b/releases/release-2.0.4.md @@ -14,7 +14,7 @@ summary: TiDB 2.0.4は2018年6月15日にリリースされ、システムの互 - 監視項目のステートメントタイプの表示を改良 - クエリコストの見積り精度を最適化する - gRPCの`backoff max delay`のパラメータを設定する -- 構成ファイル内の単一のステートメントのメモリしきい値の構成をサポート +- 設定ファイル内の単一のステートメントのメモリしきい値の構成をサポート - オプティマイザのエラーをリファクタリングする - `Cast Decimal`データの副作用を修正 - 特定のシナリオで`Merge Join`演算子の誤った結果の問題を修正しました diff --git a/releases/release-2.1.1.md b/releases/release-2.1.1.md index 4b30259ae33b4..2e92583edf13a 100644 --- a/releases/release-2.1.1.md +++ b/releases/release-2.1.1.md @@ -28,7 +28,7 @@ summary: TiDB 2.1.1は2018年12月12日にリリースされ、安定性、SQL ## PD {#pd} -- 構成ファイルで一部の設定項目を`0`に設定できない問題を修正 [#1334](https://github.com/pingcap/pd/pull/1334) +- 設定ファイルで一部の設定項目を`0`に設定できない問題を修正 [#1334](https://github.com/pingcap/pd/pull/1334) - PD 起動するときに未定義の構成を確認します [#1362](https://github.com/pingcap/pd/pull/1362) - 遅延を最適化するために、リーダーを新しく作成されたピアに転送しないでください[#1339](https://github.com/pingcap/pd/pull/1339) - デッド`RaftCluster` により停止できない問題を修正 [#1370](https://github.com/pingcap/pd/pull/1370) diff --git a/releases/release-2.1.16.md b/releases/release-2.1.16.md index fc33369575612..9f497f1b1e02e 100644 --- a/releases/release-2.1.16.md +++ b/releases/release-2.1.16.md @@ -61,6 +61,6 @@ TiDB Ansible バージョン: 2.1.16 - Spark に`log4j`設定ファイルを追加する [#842](https://github.com/pingcap/tidb-ansible/pull/842) - tispark jarパッケージをv2.1.2 に更新します [#863](https://github.com/pingcap/tidb-ansible/pull/863) -- TiDB Binlog がKafka または ZooKeeper を使用する場合に Prometheus 構成ファイルが間違った形式で生成される問題を修正しました [#845](https://github.com/pingcap/tidb-ansible/pull/845) +- TiDB Binlog がKafka または ZooKeeper を使用する場合に Prometheus 設定ファイルが間違った形式で生成される問題を修正しました [#845](https://github.com/pingcap/tidb-ansible/pull/845) - `rolling_update.yml`オペレーション実行時にPDがLeaderの切り替えに失敗するバグを修正 [#888](https://github.com/pingcap/tidb-ansible/pull/888) - PDノードのローリング更新ロジックを最適化 - フォロワーを最初にアップグレードし、次にLeaderをアップグレード - 安定性を向上[#895](https://github.com/pingcap/tidb-ansible/pull/895) diff --git a/releases/release-2.1.17.md b/releases/release-2.1.17.md index 1c75d6c0f5194..d447f912a59d7 100644 --- a/releases/release-2.1.17.md +++ b/releases/release-2.1.17.md @@ -1,6 +1,6 @@ --- title: TiDB 2.1.17 Release Notes -summary: "TiDB 2.1.17 リリースノート: 新機能には、SHOW TABLE REGIONS` の `WHERE` 句、TiKV および PD の `config-check` 機能、pd-ctl の `remove-tombstone` コマンド、 Reparoの `worker-count` および `txn-batch` 設定項目が含まれます。PD のスケジュール プロセスと TiKV の起動プロセスが改善されました。TiDB スロークエリログと構成ファイルの動作が変更されました。SQL オプティマイザ、SQL 実行エンジン、サーバー、DDL、モニター、TiKV、PD、TiDB Binlog、 TiDB Lightning、および TiDB Ansible の修正と最適化が行われました。" +summary: "TiDB 2.1.17 リリースノート: 新機能には、SHOW TABLE REGIONS` の `WHERE` 句、TiKV および PD の `config-check` 機能、pd-ctl の `remove-tombstone` コマンド、 Reparoの `worker-count` および `txn-batch` 設定項目が含まれます。PD のスケジュール プロセスと TiKV の起動プロセスが改善されました。TiDB スロークエリログと設定ファイルの動作が変更されました。SQL オプティマイザ、SQL 実行エンジン、サーバー、DDL、モニター、TiKV、PD、TiDB Binlog、 TiDB Lightning、および TiDB Ansible の修正と最適化が行われました。" --- # TiDB 2.1.17 リリースノート {#tidb-2-1-17-release-notes} @@ -24,7 +24,7 @@ TiDB Ansible バージョン: 2.1.17 - 動作の変更 - TiDB スロークエリログの最後の再試行時刻から最初の実行時刻への変更`start ts` - TiDB スロークエリログの`Index_ids`フィールドを`Index_names`フィールドに置き換えて、スロークエリログの使いやすさを向上させます。 - - TiDB の構成ファイルに`split-region-max-num`パラメータを追加して、 `SPLIT TABLE`構文で許可されるリージョンの最大数を変更します。デフォルト構成では、1,000 から 10,000 に増加されます。 + - TiDB の設定ファイルに`split-region-max-num`パラメータを追加して、 `SPLIT TABLE`構文で許可されるリージョンの最大数を変更します。デフォルト構成では、1,000 から 10,000 に増加されます。 ## TiDB {#tidb} diff --git a/releases/release-2.1.18.md b/releases/release-2.1.18.md index 0193dca5baf36..3ddb6053c67c2 100644 --- a/releases/release-2.1.18.md +++ b/releases/release-2.1.18.md @@ -71,6 +71,6 @@ TiDB Ansible バージョン: 2.1.18 - TiDB Binlog に"queue size"と"query histogram"の 2つの監視項目を追加します。 [#952](https://github.com/pingcap/tidb-ansible/pull/952) - TiDBアラートルールを更新 [#961](https://github.com/pingcap/tidb-ansible/pull/961) -- デプロイおよびアップグレードの前に構成ファイルを確認する[#973](https://github.com/pingcap/tidb-ansible/pull/973) +- デプロイおよびアップグレードの前に設定ファイルを確認する[#973](https://github.com/pingcap/tidb-ansible/pull/973) - TiDB のインデックス速度を監視するための新しいメトリックを追加します [#987](https://github.com/pingcap/tidb-ansible/pull/987) - TiDB Binlog監視ダッシュボードを更新して、Grafana v4.6.3 と互換性を持たせました。 [#993](https://github.com/pingcap/tidb-ansible/pull/993) diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index 46b35d38c75fa..013137a6a769e 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -129,8 +129,8 @@ TiDB Lightning - ディスクパフォーマンスモニターが秒をミリ秒として扱う単位エラーを修正[#840](https://github.com/pingcap/tidb-ansible/pull/840) - Spark に`log4j`設定ファイルを追加する [#841](https://github.com/pingcap/tidb-ansible/pull/841) -- Binlogが有効で Kafka または ZooKeeper が構成されている場合に Prometheus 構成ファイルが間違った形式で生成される問題を修正[#844](https://github.com/pingcap/tidb-ansible/pull/844) -- 生成されたTiDB構成ファイルで`pessimistic-txn`設定パラメータが省略される問題を修正 [#850](https://github.com/pingcap/tidb-ansible/pull/850) +- Binlogが有効で Kafka または ZooKeeper が構成されている場合に Prometheus 設定ファイルが間違った形式で生成される問題を修正[#844](https://github.com/pingcap/tidb-ansible/pull/844) +- 生成されたTiDB設定ファイルで`pessimistic-txn`設定パラメータが省略される問題を修正 [#850](https://github.com/pingcap/tidb-ansible/pull/850) - TiDB Dashboardのメトリックを追加して最適化する [#853](https://github.com/pingcap/tidb-ansible/pull/853) - TiDB Dashboardの各監視項目の説明を追加します [#854](https://github.com/pingcap/tidb-ansible/pull/854) - TiDB サマリーダッシュボードを追加して、クラスターのステータスをより適切に表示し、問題をトラブルシューティングします[#855](https://github.com/pingcap/tidb-ansible/pull/855) diff --git a/releases/release-3.0.4.md b/releases/release-3.0.4.md index 753321d2c7cb2..2e6368b486d55 100644 --- a/releases/release-3.0.4.md +++ b/releases/release-3.0.4.md @@ -24,7 +24,7 @@ TiDB Ansible バージョン: 3.0.4 - デフォルト値の`txn-local-latches.enable`を`false`に更新して、TiDB のローカルトランザクションの競合をチェックするデフォルトの動作を無効にします。 - TiDBにグローバルスコープのシステム変数を`tidb_txn_mode`追加し、悲観的ロックの使用を許可します。ただし、TiDBはデフォルトで依然として楽観的ロックを採用していることに注意してください。 - TiDB スロークエリログの`Index_ids`フィールドを`Index_names`に置き換えて、スロークエリログの使いやすさを向上させます。 - - TiDB構成ファイルに`split-region-max-num`パラメータを追加して、 `SPLIT TABLE`構文で許可されるリージョンの最大数を変更します。 + - TiDB設定ファイルに`split-region-max-num`パラメータを追加して、 `SPLIT TABLE`構文で許可されるリージョンの最大数を変更します。 - SQL実行がメモリ制限を超えたときにリンクを切断する代わりに`Out Of Memory Quota`エラーを返します - 誤操作を避けるため、TiDBの列の`AUTO_INCREMENT`の属性の削除を禁止します。この属性を削除するには、 `tidb_allow_remove_auto_inc`のシステム変数を変更します。 - 修正された問題 @@ -126,4 +126,4 @@ TiDB Ansible バージョン: 3.0.4 - パスワードの有効期限が切れた場合などに発生する長い待機時間に対処するために、rawモジュールをシェルモジュールに置き換えます[#949](https://github.com/pingcap/tidb-ansible/pull/949) - TiDB設定項目`txn_local_latches`のデフォルト値を`false`に更新します - Grafanaダッシュボードの監視メトリックとアラートルールを最適化する[#962](https://github.com/pingcap/tidb-ansible/pull/962) [#963](https://github.com/pingcap/tidb-ansible/pull/963) [#969](https://github.com/pingcap/tidb-ansible/pull/963) -- デプロイおよびアップグレードの前に構成ファイルを確認する[#934](https://github.com/pingcap/tidb-ansible/pull/934) [#972](https://github.com/pingcap/tidb-ansible/pull/972) +- デプロイおよびアップグレードの前に設定ファイルを確認する[#934](https://github.com/pingcap/tidb-ansible/pull/934) [#972](https://github.com/pingcap/tidb-ansible/pull/972) diff --git a/releases/release-3.1.0-beta.2.md b/releases/release-3.1.0-beta.2.md index e48404113639a..7bc9b6a3c894e 100644 --- a/releases/release-3.1.0-beta.2.md +++ b/releases/release-3.1.0-beta.2.md @@ -19,7 +19,7 @@ TiDB Ansible バージョン: 3.1.0-beta.2 - ツール - TiDB Lightning - - 構成ファイルで設定されていない特定の項目については、 [TiDB Lightningコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md)で指定されたデフォルト設定を使用します。 [#255](https://github.com/pingcap/tidb-lightning/pull/255) + - 設定ファイルで設定されていない特定の項目については、 [TiDB Lightning設定](/tidb-lightning/tidb-lightning-configuration.md)で指定されたデフォルト設定を使用します。 [#255](https://github.com/pingcap/tidb-lightning/pull/255) - TiDBパスワードを設定するための`--tidb-password` CLIパラメータを追加する[#253](https://github.com/pingcap/tidb-lightning/pull/253) ## 新機能 {#new-features} diff --git a/releases/release-4.0-ga.md b/releases/release-4.0-ga.md index 774e9f3708423..92acda478bf87 100644 --- a/releases/release-4.0-ga.md +++ b/releases/release-4.0-ga.md @@ -1,6 +1,6 @@ --- title: TiDB 4.0 GA Release Notes -summary: TiDB 4.0.0 GA は 2020年 5月 28日にリリースされました。このバージョンでは、大規模トランザクションのエラーメッセージが最適化され、`Changefeed`構成ファイルの使いやすさが向上し、新しい設定項目とさまざまな構文および関数のサポートが追加され、TiKV、 TiFlash、PD、およびツールの複数のバグと問題が修正され、PD の新しい監視項目とさまざまな機能のサポートが追加され、Backup & Restore (BR) と TiCDC のさまざまな問題が修正されました。 +summary: TiDB 4.0.0 GA は 2020年 5月 28日にリリースされました。このバージョンでは、大規模トランザクションのエラーメッセージが最適化され、`Changefeed`設定ファイルの使いやすさが向上し、新しい設定項目とさまざまな構文および関数のサポートが追加され、TiKV、 TiFlash、PD、およびツールの複数のバグと問題が修正され、PD の新しい監視項目とさまざまな機能のサポートが追加され、Backup & Restore (BR) と TiCDC のさまざまな問題が修正されました。 --- # TiDB 4.0 GA リリースノート {#tidb-4-0-ga-release-notes} diff --git a/releases/release-4.0.0-beta.1.md b/releases/release-4.0.0-beta.1.md index ad94bef054fa4..b33b43b22a637 100644 --- a/releases/release-4.0.0-beta.1.md +++ b/releases/release-4.0.0-beta.1.md @@ -26,7 +26,7 @@ TiDB Ansible バージョン: 4.0.0-beta.1 - HTTP APIを最適化して構成マネージャーと互換性を持たせる [#2080](https://github.com/pingcap/pd/pull/2080) - TiDB Lightning - - 構成ファイルで設定されていない特定の項目については、ドキュメントで指定されたデフォルト設定を使用します。 [#255](https://github.com/pingcap/tidb-lightning/pull/255) + - 設定ファイルで設定されていない特定の項目については、ドキュメントで指定されたデフォルト設定を使用します。 [#255](https://github.com/pingcap/tidb-lightning/pull/255) - TiDB Ansible - `theflash`を`tiflash` に名前変更 [#1130](https://github.com/pingcap/tidb-ansible/pull/1130) diff --git a/releases/release-4.0.3.md b/releases/release-4.0.3.md index 61f5c0f6af3f9..86fc607e6857f 100644 --- a/releases/release-4.0.3.md +++ b/releases/release-4.0.3.md @@ -49,7 +49,7 @@ TiDB バージョン: 4.0.3 - デフォルトで`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) + - 構成チェッカーを以前のバージョンの設定ファイルと互換性のあるものにする [#18046](https://github.com/pingcap/tidb/pull/18046) - 実行情報の収集をデフォルトで有効にする[#18518](https://github.com/pingcap/tidb/pull/18518) - システムテーブル`tiflash_tables`と`tiflash_segments`を追加する[#18536](https://github.com/pingcap/tidb/pull/18536) - `AUTO RANDOM`実験的機能から一般公開となり、リリースされました。改善点と互換性の変更点は以下の通りです。 diff --git a/releases/release-5.0.0.md b/releases/release-5.0.0.md index 8cd09b1099f72..30303fa39c6df 100644 --- a/releases/release-5.0.0.md +++ b/releases/release-5.0.0.md @@ -62,7 +62,7 @@ TiDB バージョン: 5.0.0 > > 5.0 GA の`tidb_enable_clustered_index`の`INT_ONLY`値は、5.0 RC の`OFF`値と同じ意味です。 `OFF`設定の 5.0 RC クラスターから 5.0 GA にアップグレードすると、 `INT_ONLY`と表示されます。 -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} - TiDB の[`index-limit`](/tidb-configuration-file.md#index-limit-new-in-v50)設定項目を追加します。デフォルト値は`64`で、範囲は`[64,512]`です。MySQL テーブルは最大 64 個のインデックスをサポートします。この値がデフォルト設定を超え、テーブルに 64 個を超えるインデックスが作成された場合、テーブルスキーマが MySQL に再インポートされるとエラーが報告されます。 - TiDB が MySQL の ENUM/SET の長さ (ENUM の長さ < 255) と互換性があり、一貫性を保つように、 [`enable-enum-length-limit`](/tidb-configuration-file.md#enable-enum-length-limit-new-in-v50)設定項目を追加します。デフォルト値は`true`です。 diff --git a/releases/release-5.1.0.md b/releases/release-5.1.0.md index 7672e0e63b83c..9ec9700c3161f 100644 --- a/releases/release-5.1.0.md +++ b/releases/release-5.1.0.md @@ -36,9 +36,9 @@ TiDB バージョン: 5.1.0 | [`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-new-in-v51) | 新しく追加された | オプティマイザのコスト見積もりを無視し、クエリ実行に強制的に MPP モードを使用するかどうかを制御します。この変数のデータ型は`BOOL`で、デフォルト値は`false`です。 | | [`tidb_partition_prune_mode`](/system-variables.md#tidb_partition_prune_mode-new-in-v51) | 新しく追加された | パーティションテーブルの動的プルーニングモードを有効にするかどうかを指定します。この機能は実験的です。この変数のデフォルト値は`static`であり、これはパーティションテーブルの動的プルーニングモードがデフォルトで無効になっていることを意味します。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションアイテム | 変更の種類 | 説明 | +| 設定ファイル | 設定項目 | 変更の種類 | 説明 | | :------------- | :------------------------------------------------------------------------------------------------------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB設定ファイル | [`security.enable-sem`](/tidb-configuration-file.md#enable-sem) | 新しく追加された | セキュリティ強化モード（SEM）を有効にするかどうかを制御します。この設定項目のデフォルト値は`false`で、これはSEMが無効になっていることを意味します。 | | TiDB設定ファイル | `performance.committer-concurrency` | 変更 | 単一トランザクションのコミットフェーズにおけるコミット操作に関連するリクエストの同時実行数を制御します。デフォルト値は`16`から`128`に変更されます。 | diff --git a/releases/release-5.2.0.md b/releases/release-5.2.0.md index 45d2e22ae4826..881503fbf041f 100644 --- a/releases/release-5.2.0.md +++ b/releases/release-5.2.0.md @@ -1,6 +1,6 @@ --- title: TiDB 5.2 Release Notes -summary: TiDB 5.2.0では、式インデックスのサポート、Lock ビュー GA、 TiFlashのI/Oトラフィック制限など、新機能と改善点が導入されています。互換性の変更点としては、新しいシステム変数と構成ファイルパラメータが追加されています。また、TiDB、TiKV、 TiFlash、およびTiCDC、 BR、Lightning、 Dumplingなどのツールに対するバグ修正と機能強化も含まれています。 +summary: TiDB 5.2.0では、式インデックスのサポート、Lock ビュー GA、 TiFlashのI/Oトラフィック制限など、新機能と改善点が導入されています。互換性の変更点としては、新しいシステム変数と設定ファイルパラメータが追加されています。また、TiDB、TiKV、 TiFlash、およびTiCDC、 BR、Lightning、 Dumplingなどのツールに対するバグ修正と機能強化も含まれています。 --- # TiDB 5.2 リリースノート {#tidb-5-2-release-notes} @@ -40,9 +40,9 @@ TiDB バージョン: 5.2.0 | [`tidb_stmt_summary_max_stmt_count`](/system-variables.md#tidb_stmt_summary_max_stmt_count-new-in-v40) | 変更 | ステートメントサマリーテーブルがメモリに格納するステートメントの最大数を設定します。デフォルト値は`200`から`3000`に変更されます。 | | `tidb_enable_streaming` | 非推奨 | システム変数`enable-streaming`は非推奨であり、今後は使用しないことをお勧めします。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションアイテム | 変更の種類 | 説明 | +| 設定ファイル | 設定項目 | 変更の種類 | 説明 | | :------------- | :---------------------------------------------------------------------------------------------------------------------------- | :------- | :------------------------------------------------------------------------------------------------------------------------------ | | TiDB設定ファイル | [`pessimistic-txn.deadlock-history-collect-retryable`](/tidb-configuration-file.md#deadlock-history-collect-retryable) | 新しく追加された | [`INFORMATION\_SCHEMA.DEADLOCKS`](/information-schema/information-schema-deadlocks.md)テーブルが再試行可能なデッドロックエラーメッセージを収集するかどうかを制御します。 | | TiDB設定ファイル | [`security.auto-tls`](/tidb-configuration-file.md#auto-tls) | 新しく追加された | 起動時にTLS証明書を自動的に生成するかどうかを決定します。デフォルト値は`false`です。 | @@ -64,7 +64,7 @@ TiDB バージョン: 5.2.0 - TiDB クラスターを v4.0 から v5.2 にアップグレードすると、 [`tidb_multi_statement_mode`](/system-variables.md#tidb_multi_statement_mode-new-in-v4011)のデフォルト値が`WARN`から`OFF`に変更されます。 - アップグレード前に、TiDB 設定の[`feedback-probability`](https://docs-archive.pingcap.com/tidb/v5.2/tidb-configuration-file#feedback-probability)の値を確認してください。値が`0`でない場合、アップグレード後に「panic in the recoverable goroutine」というエラーが発生しますが、このエラーはアップグレードには影響しません。 - TiDBはMySQL 5.7のnoop変数`innodb_default_row_format`と互換性を持つようになりました。この変数を設定しても効果はありません。 [#23541](https://github.com/pingcap/tidb/issues/23541) -- TiDB 5.2以降では、システムセキュリティを向上させるため、クライアントからの接続のトランスレイヤーを暗号化することが推奨されています（必須ではありません）。TiDBは、TiDB内で暗号化を自動的に構成および有効化するAuto TLS機能を提供します。Auto TLS機能を使用するには、TiDBのアップグレード前に、TiDB構成ファイルの[`security.auto-tls`](/tidb-configuration-file.md#auto-tls)を`true`に設定してください。 +- TiDB 5.2以降では、システムセキュリティを向上させるため、クライアントからの接続のトランスレイヤーを暗号化することが推奨されています（必須ではありません）。TiDBは、TiDB内で暗号化を自動的に構成および有効化するAuto TLS機能を提供します。Auto TLS機能を使用するには、TiDBのアップグレード前に、TiDB設定ファイルの[`security.auto-tls`](/tidb-configuration-file.md#auto-tls)を`true`に設定してください。 - MySQL 8.0 からの移行を容易にし、セキュリティを向上させるために、 `caching_sha2_password`認証方式をサポートします。 ## 新機能 {#new-features} diff --git a/releases/release-5.3.0.md b/releases/release-5.3.0.md index 4b1f5c010da84..b5a998261209b 100644 --- a/releases/release-5.3.0.md +++ b/releases/release-5.3.0.md @@ -38,9 +38,9 @@ v5.3 の主な新機能または改善点は次のとおりです。 | [`tidb_tso_client_batch_max_wait_time`](/system-variables.md#tidb_tso_client_batch_max_wait_time-new-in-v530) | 新しく追加された | TiDBがPDにTSOをリクエストした際に、バッチ保存操作の最大待機時間を設定します。デフォルト値は`0`で、追加の待機時間はありません。 | | [`tidb_tmp_table_max_size`](/system-variables.md#tidb_tmp_table_max_size-new-in-v530) | 新しく追加された | [一時テーブル](/temporary-tables.md)個の最大サイズを制限します。一時テーブルがこのサイズを超えるとエラーが発生します。 | -### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} +### 設定ファイルのパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーション項目 | タイプを変更 | 説明 | +| 設定ファイル | 設定項目 | タイプを変更 | 説明 | | :------------- | :------------------------------------------------------------------------------------------------- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`prepared-plan-cache.capacity`](/tidb-configuration-file.md#capacity) | 変更 | キャッシュされるステートメントの数を制御します。デフォルト値は`100`から`1000`に変更されます。 | | TiKV | [`storage.reserve-space`](/tikv-configuration-file.md#reserve-space) | 変更 | TiKV起動時にディスク保護のために予約される領域を制御します。v5.3.0以降では、予約領域の80%がディスク容量不足時の運用・保守に必要な追加ディスク領域として使用され、残りの20%は一時ファイルの保存に使用されます。 | diff --git a/releases/release-5.4.0.md b/releases/release-5.4.0.md index 908dc5680c2be..01e4a9abff3b9 100644 --- a/releases/release-5.4.0.md +++ b/releases/release-5.4.0.md @@ -1,6 +1,6 @@ --- title: TiDB 5.4 Release Notes -summary: TiDB 5.4 では、GBK 文字セット、インデックスマージ、古いデータの読み取り、統計構成の永続化、および TiKV のログストレージエンジンとしてのRaft Engine の使用がサポートされます。また、バックアップの影響が改善され、Azure Blobストレージがサポートされ、 TiFlashと MPP エンジンが強化されます。互換性の変更には、新しいシステム変数と構成ファイルパラメーターが含まれます。その他の改善点には、SQL、セキュリティ、パフォーマンス、安定性、高可用性、データ移行、診断効率、およびデプロイメントが含まれます。バグ修正では、TiDB、TiKV、PD、 TiFlash、 BR、TiCDC、DM、 TiDB Lightning、および TiDB Binlogの問題に対処します。 +summary: TiDB 5.4 では、GBK 文字セット、インデックスマージ、古いデータの読み取り、統計構成の永続化、および TiKV のログストレージエンジンとしてのRaft Engine の使用がサポートされます。また、バックアップの影響が改善され、Azure Blobストレージがサポートされ、 TiFlashと MPP エンジンが強化されます。互換性の変更には、新しいシステム変数と設定ファイルパラメーターが含まれます。その他の改善点には、SQL、セキュリティ、パフォーマンス、安定性、高可用性、データ移行、診断効率、およびデプロイメントが含まれます。バグ修正では、TiDB、TiKV、PD、 TiFlash、 BR、TiCDC、DM、 TiDB Lightning、および TiDB Binlogの問題に対処します。 --- # TiDB 5.4 リリースノート {#tidb-5-4-release-notes} @@ -33,17 +33,17 @@ TiDB バージョン: 5.4.0
変数名変更の種類説明
tidb_enable_column_tracking新しく追加されたTiDBがPREDICATE COLUMNSを収集することを許可するかどうかを制御します。デフォルト値はOFF.
tidb_enable_paging新しく追加されたIndexLookUpオペレーターでコプロセッサリクエストを送信する際にページング方式を使用するかどうかを制御します。デフォルト値はOFFです。
IndexLookupとLimitを使用する読み取りクエリで、 LimitをIndexScanにプッシュダウンできない場合、読み取りクエリのレイテンシーが高くなり、TiKVのunified read poolのCPU使用率が高くなる可能性があります。このような場合、 Limitオペレーターは少量のデータしか必要としないため、 tidb_enable_paging ONに設定すると、TiDBが処理するデータ量が少なくなり、クエリのレイテンシーとリソース消費が削減されます。
tidb_enable_top_sql新しく追加されたTop SQL機能を有効にするかどうかを制御します。デフォルト値はOFFです。
tidb_persist_analyze_options新しく追加されたANALYZE構成の永続化機能を有効にするかどうかを制御します。デフォルト値はONです。
tidb_read_staleness新しく追加された現在のセッションで読み取れる履歴データの範囲を制御します。デフォルト値は0です。
tidb_regard_null_as_point新しく追加されたオプティマイザが、NULL等価性を含むクエリ条件をインデックスアクセスのプレフィックス条件として使用できるかどうかを制御します。
tidb_stats_load_sync_wait新しく追加された同期的に統計情報を読み込む機能を有効にするかどうかを制御します。デフォルト値の0は、この機能が無効になっており、統計情報が非同期的に読み込まれることを意味します。この機能が有効になっている場合、この変数は、SQL 最適化がタイムアウトする前に同期的に統計情報を読み込むのを待機できる最大時間を制御します。
tidb_stats_load_pseudo_timeout新しく追加された同期的に統計情報を読み込む際にタイムアウトが発生した場合、SQLが失敗するか（ OFF ）、擬似統計情報を使用するようにフォールバックするか（ ON ）を制御します。デフォルト値はOFFです。
tidb_backoff_lock_fast変更デフォルト値が100から10に変更されました。
tidb_enable_index_merge変更デフォルト値がOFFからONに変更されます。
  • TiDBクラスタをv4.0.0より前のバージョンからv5.4.0以降にアップグレードする場合、この変数はデフォルトでOFFなります。
  • TiDBクラスタをv4.0.0以降からv5.4.0以降にアップグレードした場合、この変数はアップグレード前と同じままです。
  • バージョン5.4.0以降で新たに作成されたTiDBクラスタでは、この変数はデフォルトでONなっています。
tidb_store_limit変更バージョン5.4.0より前は、この変数はインスタンスレベルとグローバルレベルの両方で設定可能でした。バージョン5.4.0以降は、この変数はグローバル設定のみをサポートします。
-### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーション | 変更の種類 | 説明 | +| 設定ファイル | 設定 | 変更の種類 | 説明 | | :------------- | :-------------------------------------------------------------------------------------------------------------- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`stats-load-concurrency`](/tidb-configuration-file.md#stats-load-concurrency-new-in-v540) | 新しく追加された | TiDBの同期ロード統計機能が同時に処理できる列の最大数を制御します。デフォルト値は`5`です。 | | TiDB | [`stats-load-queue-size`](/tidb-configuration-file.md#stats-load-queue-size-new-in-v540) | 新しく追加された | TiDBの同期ロード統計機能がキャッシュできる列リクエストの最大数を制御します。デフォルト値は`1000`です。 | | TiKV | [`snap-generator-pool-size`](/tikv-configuration-file.md#snap-generator-pool-size-new-in-v540) | 新しく追加された | `snap-generator`スレッドプールのサイズ。デフォルト値は`2`です。 | -| TiKV | `log.file.max-size` 、 `log.file.max-days` 、 `log.file.max-backups` | 新しく追加された | 詳細については、 [TiKVコンフィグレーションファイル - `log.file`](/tikv-configuration-file.md#logfile-new-in-v540)を参照してください。 | -| TiKV | `raft-engine` | 新しく追加された | `enable` 、 `dir` 、 `batch-compression-threshold` 、 `bytes-per-sync` 、 `target-file-size` 、 `purge-threshold` 、 `recovery-mode` 、 `recovery-read-block-size` 、 `recovery-read-block-size` 、および`recovery-threads`が含まれます。詳細は、 [TiKVコンフィグレーションファイル - `raft-engine`](/tikv-configuration-file.md#raft-engine)を参照してください。 | +| TiKV | `log.file.max-size` 、 `log.file.max-days` 、 `log.file.max-backups` | 新しく追加された | 詳細については、 [TiKV設定ファイル - `log.file`](/tikv-configuration-file.md#logfile-new-in-v540)を参照してください。 | +| TiKV | `raft-engine` | 新しく追加された | `enable` 、 `dir` 、 `batch-compression-threshold` 、 `bytes-per-sync` 、 `target-file-size` 、 `purge-threshold` 、 `recovery-mode` 、 `recovery-read-block-size` 、 `recovery-read-block-size` 、および`recovery-threads`が含まれます。詳細は、 [TiKV設定ファイル - `raft-engine`](/tikv-configuration-file.md#raft-engine)を参照してください。 | | TiKV | [`backup.enable-auto-tune`](/tikv-configuration-file.md#enable-auto-tune-new-in-v540) | 新しく追加された | v5.3.0 では、デフォルト値は`false`です。v5.4.0 以降では、デフォルト値は`true`に変更されました。このパラメータは、クラスタのリソース使用率が高い場合に、バックアップタスクで使用されるリソースを制限してクラスタへの影響を軽減するかどうかを制御します。デフォルト設定では、バックアップタスクの速度が低下する可能性があります。 | -| TiKV | `log-level` 、 `log-format` 、 `log-file` 、 `log-rotation-size` | 変更 | TiKV ログ パラメータの名前は、TiDB ログ パラメータと互換性のある名前`log.level` 、 `log.format` 、 `log.file.filename` 、および`log.enable-timestamp` 。古いパラメータのみを設定し、その値をデフォルト値以外に設定した場合、古いパラメータは新しいパラメータと互換性があります。古いパラメータと新しいパラメータの両方を設定した場合、新しいパラメータが有効になります。詳細については、[TiKVコンフィグレーションファイル - ログ](/tikv-configuration-file.md#log-new-in-v540)を参照してください。 | +| TiKV | `log-level` 、 `log-format` 、 `log-file` 、 `log-rotation-size` | 変更 | TiKV ログ パラメータの名前は、TiDB ログ パラメータと互換性のある名前`log.level` 、 `log.format` 、 `log.file.filename` 、および`log.enable-timestamp` 。古いパラメータのみを設定し、その値をデフォルト値以外に設定した場合、古いパラメータは新しいパラメータと互換性があります。古いパラメータと新しいパラメータの両方を設定した場合、新しいパラメータが有効になります。詳細については、[TiKV設定ファイル - ログ](/tikv-configuration-file.md#log-new-in-v540)を参照してください。 | | TiKV | `log-rotation-timespan` | 削除済み | ログファイルのローテーション間隔。この間隔が経過すると、ログファイルがローテーションされます。これは、現在のログファイルのファイル名にタイムスタンプが追加され、新しいログファイルが作成されることを意味します。 | | TiKV | `allow-remove-leader` | 削除済み | メインスイッチの削除を許可するかどうかを決定します。 | | TiKV | `raft-msg-flush-interval` | 削除済み | Raftメッセージがバッチで送信される間隔を決定します。Raftメッセージは、この設定項目で指定された間隔ごとにバッチで送信されます。 | diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md index 4ee42b5667d44..39fddcbe815b4 100644 --- a/releases/release-6.0.0-dmr.md +++ b/releases/release-6.0.0-dmr.md @@ -289,9 +289,9 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。
変数名タイプを変更説明
placement_checks削除済みDDL文がSQL の配置ルールで指定された配置ルールを検証するかどうかを制御します。tidb_placement_mode に置き換えられtidb_placement_modeた。
tidb_enable_alter_placement削除済みSQL で配置ルールを有効にするかどうかを制御します。
tidb_mem_quota_hashjoin
tidb_mem_quota_indexlookupjoin
tidb_mem_quota_indexlookupreader
tidb_mem_quota_mergejoin
tidb_mem_quota_sort
tidb_mem_quota_topn		削除済みv5.0以降、これらの変数はtidb_mem_quota_queryに置き換えられ、システム変数ドキュメントから削除されました。互換性を確保するため、これらの変数はソースコードに残されていました。TiDB 6.0.0以降、これらの変数はコードからも削除されています。
tidb_enable_mutation_checker新しく追加されたミューテーションチェッカーを有効にするかどうかを制御します。デフォルト値はONです。v6.0.0より前のバージョンからアップグレードする既存のクラスターの場合、ミューテーションチェッカーはデフォルトで無効になっています。
tidb_ignore_prepared_cache_close_stmt新しく追加されたプリペアドステートメントを閉じるコマンドを無視するかどうかを制御します。デフォルト値はOFFです。
tidb_mem_quota_binding_cache新しく追加されたキャッシュ保持バインディングのメモリ使用量のしきい値を設定します。デフォルト値は67108864 （64 MiB）です。
tidb_placement_mode新しく追加されたDDL文がSQLの配置ルールで指定された配置ルールを無視するかどうかを制御します。デフォルト値はstrictで、DDL文は配置ルールを無視しません。
tidb_rc_read_check_ts新しく追加された
  • トランザクション内の読み取りステートメントのレイテンシーを最適化します。読み取り/書き込みの競合が深刻な場合、この変数をオンにするとオーバーヘッドとレイテンシーが増加し、パフォーマンスが低下します。デフォルト値はoffです。
  • この変数はまだreplica-readと互換性がありません。読み取りリクエストでtidb_rc_read_check_tsがオンになっている場合、 replica-read を使用できない可能性があります。両方の変数を同時にオンにしないでください。
tidb_sysdate_is_now新しく追加されたSYSDATE関数をNOW関数に置き換えるかどうかを制御します。この設定項目は、MySQLオプションsysdate-is-nowと同じ効果があります。デフォルト値はOFFです。
tidb_table_cache_lease新しく追加されたテーブルキャッシュのリース時間を秒単位で制御します。デフォルト値は3です。
tidb_top_sql_max_meta_count新しく追加されたTop SQLによって1分間に収集されるSQL文タイプの最大数を制御します。デフォルト値は5000です。
tidb_top_sql_max_time_series_count新しく追加された負荷に最も寄与するSQL文（つまり、上位N文）を1分あたりにTop SQLで記録できる回数を制御します。デフォルト値は100です。
tidb_txn_assertion_level新しく追加されたアサーションレベルを制御します。アサーションは、データとインデックス間の整合性チェックであり、トランザクションのコミットプロセスにおいて、書き込まれるキーが存在するかどうかを確認します。デフォルトでは、ほとんどのチェック項目が有効になっており、パフォーマンスへの影響はほとんどありません。v6.0.0より前のバージョンからアップグレードした既存のクラスターでは、このチェックはデフォルトで無効になっています。
-### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} +### 設定ファイルのパラメータ {#configuration-file-parameters} -
コンフィグレーションファイルコンフィグレーションタイプを変更説明
TiDBstmt-summary.enable
stmt-summary.enable-internal-query
stmt-summary.history-size
stmt-summary.max-sql-length
stmt-summary.max-stmt-count
stmt-summary.refresh-interval		削除済みステートメントサマリーテーブルに関連するコンフィグレーション。これらの設定項目はすべて削除されました。ステートメントサマリーテーブルを制御するには、SQL変数を使用する必要があります。
TiDBnew_collations_enabled_on_first_bootstrap変更新しい照合順序のサポートを有効にするかどうかを制御します。バージョン6.0以降、デフォルト値はfalseからtrueに変更されました。この設定項目は、クラスターが初めて初期化されたときにのみ有効になります。最初のブートストラップ後は、この設定項目を使用して新しい照合順序順序フレームワークを有効化または無効化することはできません。
TiKVbackup.num-threads変更値の範囲は[1, CPU]に変更されます。
TiKVraftstore.apply-max-batch-size変更最大値は10240に変更されます。
TiKVraftstore.raft-max-size-per-msg変更最小値が0から0より大きい値に変更されます。
最大値は3GBに設定されています。
単位がMBからKB|MB|GBに変更されます。
TiKVraftstore.store-max-batch-size変更最大値は10240に設定されています。
TiKVreadpool.unified.max-thread-count変更調整可能な範囲は[min-thread-count, MAX(4, CPU)]に変更されます。
TiKVrocksdb.enable-pipelined-write変更デフォルト値がtrueからfalseに変更されました。この設定を有効にすると、従来のパイプライン書き込みが使用されます。この設定を無効にすると、新しいパイプラインコミットメカニズムが使用されます。
TiKVrocksdb.max-background-flushes変更CPU コア数が 10 の場合、デフォルト値は3です。
CPU コア数が 8 の場合、デフォルト値は2です。
TiKVrocksdb.max-background-jobs変更CPU コア数が 10 の場合、デフォルト値は9です。
CPU コア数が 8 の場合、デフォルト値は7です。
TiFlashprofiles.default.dt_enable_logical_split変更DeltaTreeストレージエンジンのセグメントが論理分割を使用するかどうかを決定します。デフォルト値はtrueからfalseに変更されます。
TiFlashprofiles.default.enable_elastic_threadpool変更エラスティックスレッドプールを有効にするかどうかを制御します。デフォルト値はfalseからtrueに変更されます。
TiFlashstorage.format_version変更TiFlashのデータ検証機能を制御します。デフォルト値は2から3に変更されます。
format_version 3に設定すると、ハードウェア障害による誤った読み取りを回避するために、すべてのTiFlashデータの読み取り操作に対して一貫性チェックが実行されます。
新しい形式のバージョンは、v5.4 より前のバージョンにそのままダウングレードすることはできないことに注意してください。
TiDBpessimistic-txn.pessimistic-auto-commit新しく追加された悲観的トランザクションモードがグローバルに有効になっている場合 ( tidb_txn_mode='pessimistic' )、自動コミット トランザクションが使用するトランザクションモードを決定します。
TiKVpessimistic-txn.in-memory新しく追加されたインメモリ悲観的ロックを有効にするかどうかを制御します。この機能を有効にすると、悲観的トランザクションは、悲観的ロックをディスクに書き込んだり他のレプリカに複製したりするのではなく、可能な限りTiKVメモリに悲観的ロックを保存します。これにより、悲観的トランザクションのパフォーマンスが向上しますが、悲観的ロックが失われる可能性がわずかながらあり、その結果、悲観的トランザクションがコミットに失敗する可能性があります。デフォルト値はtrueです。
TiKVquota新しく追加されたフロントエンドリクエストが占有するリソースを制限するQuota Limiter関連の設定項目を追加しました。Quota Limiterは実験的機能であり、デフォルトでは無効になっています。新しいクォータ関連の設定項目は、 foreground-cpu-time 、 foreground-write-bandwidth 、 foreground-read-bandwidth 、 max-delay-durationです。
TiFlashprofiles.default.dt_compression_method新しく追加されたTiFlashの圧縮アルゴリズムを指定します。オプションの値はLZ4 、 zstd 、 LZ4HCで、いずれも大文字と小文字は区別されません。デフォルト値はLZ4です。
TiFlashprofiles.default.dt_compression_level新しく追加されたTiFlashの圧縮レベルを指定します。デフォルト値は1です。
DM loaders.<name>.import-mode新しく追加されたフルインポートフェーズにおけるインポートモード。v6.0以降、DMはフルインポートフェーズでTiDB LightningのTiDBバックエンドモードを使用してデータをインポートします。以前のLoaderコンポーネントは使用されなくなりました。これは内部的な置き換えであり、日常業務への影響は見られません。
デフォルト値はsqlに設定されており、これはtidb-backendモードを使用することを意味します。稀に、tidb-backendは完全な互換性を持たない場合があります。このパラメータをloaderに設定することで、Loaderモードにフォールバックできます。
DM loaders.<name>.on-duplicate新しく追加されたフルインポートフェーズで競合を解決する方法を指定します。デフォルト値はreplaceで、これは新しいデータを使用して既存のデータを置き換えることを意味します。
TiCDC dial-timeout新しく追加された下流のKafkaとの接続を確立する際のタイムアウト。デフォルト値は10sです。
TiCDC read-timeout新しく追加された下流のKafkaから返されるレスポンスを取得する際のタイムアウト。デフォルト値は10sです。
TiCDC write-timeout新しく追加された下流のKafkaにリクエストを送信する際のタイムアウト。デフォルト値は10sです。
+
設定ファイル設定タイプを変更説明
TiDBstmt-summary.enable
stmt-summary.enable-internal-query
stmt-summary.history-size
stmt-summary.max-sql-length
stmt-summary.max-stmt-count
stmt-summary.refresh-interval		削除済みステートメントサマリーテーブルに関連する設定。これらの設定項目はすべて削除されました。ステートメントサマリーテーブルを制御するには、SQL変数を使用する必要があります。
TiDBnew_collations_enabled_on_first_bootstrap変更新しい照合順序のサポートを有効にするかどうかを制御します。バージョン6.0以降、デフォルト値はfalseからtrueに変更されました。この設定項目は、クラスターが初めて初期化されたときにのみ有効になります。最初のブートストラップ後は、この設定項目を使用して新しい照合順序順序フレームワークを有効化または無効化することはできません。
TiKVbackup.num-threads変更値の範囲は[1, CPU]に変更されます。
TiKVraftstore.apply-max-batch-size変更最大値は10240に変更されます。
TiKVraftstore.raft-max-size-per-msg変更最小値が0から0より大きい値に変更されます。
最大値は3GBに設定されています。
単位がMBからKB|MB|GBに変更されます。
TiKVraftstore.store-max-batch-size変更最大値は10240に設定されています。
TiKVreadpool.unified.max-thread-count変更調整可能な範囲は[min-thread-count, MAX(4, CPU)]に変更されます。
TiKVrocksdb.enable-pipelined-write変更デフォルト値がtrueからfalseに変更されました。この設定を有効にすると、従来のパイプライン書き込みが使用されます。この設定を無効にすると、新しいパイプラインコミットメカニズムが使用されます。
TiKVrocksdb.max-background-flushes変更CPU コア数が 10 の場合、デフォルト値は3です。
CPU コア数が 8 の場合、デフォルト値は2です。
TiKVrocksdb.max-background-jobs変更CPU コア数が 10 の場合、デフォルト値は9です。
CPU コア数が 8 の場合、デフォルト値は7です。
TiFlashprofiles.default.dt_enable_logical_split変更DeltaTreeストレージエンジンのセグメントが論理分割を使用するかどうかを決定します。デフォルト値はtrueからfalseに変更されます。
TiFlashprofiles.default.enable_elastic_threadpool変更エラスティックスレッドプールを有効にするかどうかを制御します。デフォルト値はfalseからtrueに変更されます。
TiFlashstorage.format_version変更TiFlashのデータ検証機能を制御します。デフォルト値は2から3に変更されます。
format_version 3に設定すると、ハードウェア障害による誤った読み取りを回避するために、すべてのTiFlashデータの読み取り操作に対して一貫性チェックが実行されます。
新しい形式のバージョンは、v5.4 より前のバージョンにそのままダウングレードすることはできないことに注意してください。
TiDBpessimistic-txn.pessimistic-auto-commit新しく追加された悲観的トランザクションモードがグローバルに有効になっている場合 ( tidb_txn_mode='pessimistic' )、自動コミット トランザクションが使用するトランザクションモードを決定します。
TiKVpessimistic-txn.in-memory新しく追加されたインメモリ悲観的ロックを有効にするかどうかを制御します。この機能を有効にすると、悲観的トランザクションは、悲観的ロックをディスクに書き込んだり他のレプリカに複製したりするのではなく、可能な限りTiKVメモリに悲観的ロックを保存します。これにより、悲観的トランザクションのパフォーマンスが向上しますが、悲観的ロックが失われる可能性がわずかながらあり、その結果、悲観的トランザクションがコミットに失敗する可能性があります。デフォルト値はtrueです。
TiKVquota新しく追加されたフロントエンドリクエストが占有するリソースを制限するQuota Limiter関連の設定項目を追加しました。Quota Limiterは実験的機能であり、デフォルトでは無効になっています。新しいクォータ関連の設定項目は、 foreground-cpu-time 、 foreground-write-bandwidth 、 foreground-read-bandwidth 、 max-delay-durationです。
TiFlashprofiles.default.dt_compression_method新しく追加されたTiFlashの圧縮アルゴリズムを指定します。オプションの値はLZ4 、 zstd 、 LZ4HCで、いずれも大文字と小文字は区別されません。デフォルト値はLZ4です。
TiFlashprofiles.default.dt_compression_level新しく追加されたTiFlashの圧縮レベルを指定します。デフォルト値は1です。
DM loaders.<name>.import-mode新しく追加されたフルインポートフェーズにおけるインポートモード。v6.0以降、DMはフルインポートフェーズでTiDB LightningのTiDBバックエンドモードを使用してデータをインポートします。以前のLoaderコンポーネントは使用されなくなりました。これは内部的な置き換えであり、日常業務への影響は見られません。
デフォルト値はsqlに設定されており、これはtidb-backendモードを使用することを意味します。稀に、tidb-backendは完全な互換性を持たない場合があります。このパラメータをloaderに設定することで、Loaderモードにフォールバックできます。
DM loaders.<name>.on-duplicate新しく追加されたフルインポートフェーズで競合を解決する方法を指定します。デフォルト値はreplaceで、これは新しいデータを使用して既存のデータを置き換えることを意味します。
TiCDC dial-timeout新しく追加された下流のKafkaとの接続を確立する際のタイムアウト。デフォルト値は10sです。
TiCDC read-timeout新しく追加された下流のKafkaから返されるレスポンスを取得する際のタイムアウト。デフォルト値は10sです。
TiCDC write-timeout新しく追加された下流のKafkaにリクエストを送信する際のタイムアウト。デフォルト値は10sです。
### その他 {#others} diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md index e7c5bd7ba75ac..3340071f89110 100644 --- a/releases/release-6.1.0.md +++ b/releases/release-6.1.0.md @@ -147,7 +147,7 @@ TiDB バージョン: 6.1.0 以前のバージョンのTiDBでは、設定項目を変更した後、変更を有効にするにはクラスタを再起動する必要がありました。これにより、オンラインサービスが中断される可能性がありました。この問題に対処するため、TiDB v6.1.0では動的設定機能が導入され、クラスタを再起動せずにパラメータ変更を検証できるようになりました。具体的な最適化は以下の通りです。 - - TiDBの一部の設定項目をシステム変数に変換し、動的に変更・保存できるようにします。変換後は元の設定項目は非推奨となることに注意してください。変換後の設定項目の詳細なリストについては、 [コンフィグレーションファイルのパラメータ](#configuration-file-parameters)を参照してください。 + - TiDBの一部の設定項目をシステム変数に変換し、動的に変更・保存できるようにします。変換後は元の設定項目は非推奨となることに注意してください。変換後の設定項目の詳細なリストについては、 [設定ファイルのパラメータ](#configuration-file-parameters)を参照してください。 - Support configuring some TiKV parameters online. For a detailed list of the parameters, see [その他](#others). - TiFlash設定項目`max_threads`をシステム変数`tidb_max_tiflash_threads`に変換し、構成を動的に変更して永続化できるようにします。変換後も元の設定項目は保持されることに注意してください。 @@ -252,9 +252,9 @@ TiDB バージョン: 6.1.0 | [`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-new-in-v610) | 新しく追加された | この設定は以前は`tidb.toml`オプション ( `prepared-plan-cache.capacity` ) でしたが、TiDB v6.1.0 以降ではシステム変数に変更されました。 | | [`tidb_stats_cache_mem_quota`](/system-variables.md#tidb_stats_cache_mem_quota-new-in-v610) | 新しく追加された | この変数は、TiDB 統計キャッシュのメモリクォータを設定します。 | -### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} +### 設定ファイルのパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーション | タイプを変更 | 説明 | +| 設定ファイル | 設定 | タイプを変更 | 説明 | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | `committer-concurrency` | 削除済み | システム変数`tidb_committer_concurrency`に置き換えられました。この設定項目は無効になりました。値を変更する場合は、対応するシステム変数を変更する必要があります。 | | TiDB | `lower-case-table-names` | 削除済み | 現在、TiDBは`lower_case_table_name=2`のみをサポートしています。別の値が設定されている場合は、クラスターをv6.1.0にアップグレードした後にその値は失われます。 | @@ -286,10 +286,10 @@ TiDB バージョン: 6.1.0 | TiCDC | [`dispatchers.partition`](/ticdc/ticdc-sink-to-kafka.md#customize-the-rules-for-topic-and-partition-dispatchers-of-kafka-sink) | 新しく追加された | `dispatchers.partition`は`dispatchers.dispatcher`の別名です。TiCDC が増分データを Kafka パーティションに送信する方法を制御します。 | | TiCDC | [`schema-registry`](/ticdc/ticdc-sink-to-kafka.md#integrate-ticdc-with-kafka-connect-confluent-platform) | 新しく追加された | Avro スキーマを保存するスキーマレジストリ エンドポイントを指定します。 | | DM | `dmctl start-relay`コマンドの`worker` | 削除済み | このパラメータの使用は推奨されません。よりシンプルな実装を提供します。 | -| DM | `relay-dir` in the source configuration file | 削除済み | ワーカー構成ファイル内の同じ設定項目に置き換えられます。 | +| DM | `relay-dir` in the source configuration file | 削除済み | ワーカー設定ファイル内の同じ設定項目に置き換えられます。 | | DM | タスク設定ファイル内の`is-sharding` | 削除済み | `shard-mode`設定項目に置き換えられました。 | | DM | タスク設定ファイル内の`auto-fix-gtid` | 削除済み | v5.x では非推奨となり、v6.1.0 では正式に削除されました。 | -| DM | ソース構成ファイルの`meta-dir`と`charset` | 削除済み | Deprecated in v5.x and officially deleted in v6.1.0. | +| DM | ソース設定ファイルの`meta-dir`と`charset` | 削除済み | Deprecated in v5.x and officially deleted in v6.1.0. | ### その他 {#others} @@ -312,7 +312,7 @@ TiDB バージョン: 6.1.0 - `server.max-grpc-send-msg-len` - `server.raft-msg-max-batch-size` -- v6.1.0では、一部の構成ファイルパラメータがシステム変数に変換されます。以前のバージョンからv6.1.0クラスターにアップグレード（オンラインおよびオフラインアップグレードを含む）する場合は、以下の点にご注意ください。 +- v6.1.0では、一部の設定ファイルパラメータがシステム変数に変換されます。以前のバージョンからv6.1.0クラスターにアップグレード（オンラインおよびオフラインアップグレードを含む）する場合は、以下の点にご注意ください。 - アップグレード前に設定ファイルに指定された設定項目が既に存在する場合、TiDBはアップグレードプロセス中に、設定された項目の値を対応するシステム変数の値に自動的に更新します。これにより、パラメータの最適化により、アップグレード後もシステムの動作は変わりません。 - 上記の自動更新はアップグレード中に1回のみ実行されます。アップグレード後は、廃止された設定項目は無効になります。 diff --git a/releases/release-6.1.4.md b/releases/release-6.1.4.md index 893b984623fe3..7ff5c0cf106be 100644 --- a/releases/release-6.1.4.md +++ b/releases/release-6.1.4.md @@ -78,7 +78,7 @@ TiDB バージョン: 6.1.4 - TiCDC - TiCDC が過度に多数のテーブルを複製するとチェックポイントが進めなくなる問題を修正しました [#8004](https://github.com/pingcap/tiflow/issues/8004) @[asddongmen](https://github.com/asddongmen) - - `transaction-atomicity`と`protocol`構成ファイル経由で更新できない問題を修正 [#7935](https://github.com/pingcap/tiflow/issues/7935) @[CharlesCheung96](https://github.com/CharlesCheung96) + - `transaction-atomicity`と`protocol`設定ファイル経由で更新できない問題を修正 [#7935](https://github.com/pingcap/tiflow/issues/7935) @[CharlesCheung96](https://github.com/CharlesCheung96) - TiFlashのバージョンがTiCDCのバージョンより新しい場合にTiCDCが誤ってエラーを報告する問題を修正しました [#7744](https://github.com/pingcap/tiflow/issues/7744) @[overvenus](https://github.com/overvenus) - TiCDCが大規模なトランザクションを複製するときにOOMが発生する問題を修正 [#7913](https://github.com/pingcap/tiflow/issues/7913) @[overvenus](https://github.com/overvenus) - TiCDCが大きなトランザクションを分割せずにデータを複製するとコンテキスト期限が超過するバグを修正 [#7982](https://github.com/pingcap/tiflow/issues/7982) @[Rustin170506](https://github.com/Rustin170506) diff --git a/releases/release-6.2.0.md b/releases/release-6.2.0.md index be49c96a76588..d99b3e42ba1fc 100644 --- a/releases/release-6.2.0.md +++ b/releases/release-6.2.0.md @@ -264,9 +264,9 @@ TiDBバージョン: 6.2.0-DMR | tidb_enable_change_multi_schema | 削除済み | この変数は、v6.2.0 以降では、デフォルトで 1つの`ALTER TABLE`文で複数の列またはインデックスを変更できるため、削除されます。 | | [tidb_enable_outer_join_reorder](/system-variables.md#tidb_enable_outer_join_reorder-new-in-v610) | 変更 | この変数は、TiDB の結合したテーブルの再配置アルゴリズムが Outer Join をサポートするかどうかを制御します。v6.1.0 では、デフォルト値は`ON`であり、これは Join Reorder の Outer Join のサポートがデフォルトで有効になっていることを意味します。v6.2.0 以降では、デフォルト値は`OFF`であり、これはサポートがデフォルトで無効になっていることを意味します。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーション | 変更の種類 | 説明 | +| 設定ファイル | 設定 | 変更の種類 | 説明 | | -------------- | ------------------------------------------------------------------------------------------------------------------------- | -------- | --------------------------------------------------------------------------------------------------- | | TiDB | フィードバック確率 | 削除済み | この設定はもはや有効ではなく、推奨されません。 | | TiDB | クエリフィードバック制限 | 削除済み | この設定はもはや有効ではなく、推奨されません。 | diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 2dee3801c6856..4d76cd0835a18 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -1,6 +1,6 @@ --- title: TiDB 6.3.0 Release Notes -summary: 2022年9月30日にリリースされたTiDB 6.3.0-DMRでは、TiKVでのSM4アルゴリズムを使用した保存時の暗号化、TiDBでのSM3アルゴリズムを使用した認証、JSONデータ型と関数のサポートなど、新機能と改善点が導入されています。また、実行時間メトリクスをより細かい粒度で提供し、スローログと`TRACE`ステートメントの出力を強化し、TiDB Dashboardでデッドロック履歴情報をサポートします。さらに、TiDB v6.3.0では、新しいシステム変数と構成ファイルパラメータが導入され、さまざまなバグと問題が修正されています。このリリースには、TiKV、PD、 TiFlash、Backup & Restore (BR)、TiCDC、TiDB Binlog、TiDB Data Migration (DM)、およびTiDB Lightningの改善も含まれています。 +summary: 2022年9月30日にリリースされたTiDB 6.3.0-DMRでは、TiKVでのSM4アルゴリズムを使用した保存時の暗号化、TiDBでのSM3アルゴリズムを使用した認証、JSONデータ型と関数のサポートなど、新機能と改善点が導入されています。また、実行時間メトリクスをより細かい粒度で提供し、スローログと`TRACE`ステートメントの出力を強化し、TiDB Dashboardでデッドロック履歴情報をサポートします。さらに、TiDB v6.3.0では、新しいシステム変数と設定ファイルパラメータが導入され、さまざまなバグと問題が修正されています。このリリースには、TiKV、PD、 TiFlash、Backup & Restore (BR)、TiCDC、TiDB Binlog、TiDB Data Migration (DM)、およびTiDB Lightningの改善も含まれています。 --- # TiDB 6.3.0 リリースノート {#tidb-6-3-0-release-notes} @@ -189,7 +189,7 @@ TiDBバージョン: 6.3.0-DMR - DM に新しい設定項目`safe-mode-duration`が追加されました [#6224](https://github.com/pingcap/tiflow/issues/6224) @[okJiang](https://github.com/okJiang) - この設定項目は、[タスク構成ファイル](/dm/task-configuration-file-full.md)ファイルに追加されます。DM が異常終了した後の自動セーフモードの継続時間を調整できます。デフォルト値は 60秒です。 `safe-mode-duration` `"0s"`に設定すると、DM が異常再起動後にセーフモードに入ろうとしたときにエラーが報告されます。 + この設定項目は、[タスク設定ファイル](/dm/task-configuration-file-full.md)ファイルに追加されます。DM が異常終了した後の自動セーフモードの継続時間を調整できます。デフォルト値は 60秒です。 `safe-mode-duration` `"0s"`に設定すると、DM が異常再起動後にセーフモードに入ろうとしたときにエラーが報告されます。 ### TiDBデータ共有サブスクリプション {#tidb-data-share-subscription} @@ -237,9 +237,9 @@ TiDBバージョン: 6.3.0-DMR | [`tidb_rc_write_check_ts`](/system-variables.md#tidb_rc_write_check_ts-new-in-v630) | 新しく追加された | タイムスタンプの取得を最適化するために使用され、悲観的トランザクションのRC分離レベルにおいてポイント書き込み競合が少ないシナリオに適しています。この変数を有効にすると、ポイント書き込みステートメントの実行中にグローバルタイムスタンプを取得する際に発生するレイテンシーとオーバーヘッドを回避できます。 | | [`tiflash_fastscan`](/system-variables.md#tiflash_fastscan-new-in-v630) | 新しく追加された | FastScanを有効にするかどうかを制御します。FastScan[ファストスキャン](/tiflash/use-fastscan.md)が有効になっている場合（ `ON`に設定）、 TiFlashはより効率的なクエリパフォーマンスを提供しますが、クエリ結果の正確性やデータの一貫性は保証されません。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーション | 変更の種類 | 説明 | +| 設定ファイル | 設定 | 変更の種類 | 説明 | | -------------- | ----------------------------------------------------------------------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`temp-dir`](/tidb-configuration-file.md#temp-dir-new-in-v630) | 新しく追加された | TiDB が一時データを格納するために使用するファイルシステム上の場所を指定します。機能が TiDB ノードでローカルストレージを必要とする場合、TiDB は対応する一時データをこの場所に格納します。デフォルト値は`/tmp/tidb`です。 | | TiKV | [`auto-adjust-pool-size`](/tikv-configuration-file.md#auto-adjust-pool-size-new-in-v630) | 新しく追加された | スレッドプールのサイズを自動的に調整するかどうかを制御します。有効にすると、現在のCPU使用率に基づいてUnifyReadPoolスレッドプールのサイズを自動的に調整することで、TiKVの読み取りパフォーマンスが最適化されます。 | diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 269b85ab161cf..685228fa29922 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -61,7 +61,7 @@ TiDBバージョン: 6.4.0-DMR - TiFlashは保存時の暗号化にSM4アルゴリズムをサポートしています [#5953](https://github.com/pingcap/tiflash/issues/5953) @[lidezhu](https://github.com/lidezhu) - TiFlashの保存時暗号化にSM4アルゴリズムを追加します。保存時暗号化を設定する際に、 `data-encryption-method`構成ファイル内の`sm4-ctr` 構成の値を`tiflash-learner.toml`暗号化機能を有効にできます。 + TiFlashの保存時暗号化にSM4アルゴリズムを追加します。保存時暗号化を設定する際に、 `data-encryption-method`設定ファイル内の`sm4-ctr` 構成の値を`tiflash-learner.toml`暗号化機能を有効にできます。 詳細については、[ユーザー向けドキュメント](/encryption-at-rest.md#tiflash)を参照してください。 @@ -254,7 +254,7 @@ TiDBバージョン: 6.4.0-DMR バージョン6.4.0以降では、binlogの位置やGTIDを指定せずに、増分移行を直接実行できます。DMは、タスク開始後にアップストリームから生成されたbinlogファイルを自動的に取得し、これらの増分データをダウンストリームに移行します。これにより、ユーザーは面倒な理解や複雑な設定から解放されます。 - 詳細については、 [DM 高度タスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 + 詳細については、 [DM 高度タスク設定ファイル](/dm/task-configuration-file-full.md)を参照してください。 - DMが移行タスクのステータスインジケーターを追加 [#7343](https://github.com/pingcap/tiflow/issues/7343) @[okJiang](https://github.com/okJiang) @@ -304,9 +304,9 @@ TiDBバージョン: 6.4.0-DMR | [`tidb_server_memory_limit_gc_trigger`](/system-variables.md#tidb_server_memory_limit_gc_trigger-new-in-v640) | 新しく追加された | TiDB が GC をトリガーしようとするしきい値を制御します (実験的)。デフォルト値は`70%`です。 | | [`tidb_server_memory_limit_sess_min_size`](/system-variables.md#tidb_server_memory_limit_sess_min_size-new-in-v640) | 新しく追加された | メモリ制限を有効にすると、TiDB は現在のインスタンスで最もメモリ使用量の多い SQL文を終了します。この変数は、終了する SQL文の最小メモリ使用量を指定します。デフォルト値は`134217728` (128 MiB) です。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | 変更の種類 | 説明 | +| 設定ファイル | 設定パラメータ | 変更の種類 | 説明 | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | `tidb_memory_usage_alarm_ratio` | 削除済み | この設定項目は無効になりました。 | | TiDB | `memory-usage-alarm-ratio` | 削除済み | システム変数[`tidb_memory_usage_alarm_ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio)に置き換えられました。この設定項目が TiDB バージョン v6.4.0 より前のバージョンで設定されていた場合、アップグレード後には有効になりません。 | From 44f780a7cac543d6df697b21b5b73987f7ea91ea Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Fri, 11 Sep 2026 13:35:27 +0900 Subject: [PATCH 2/3] i18n(ja): fix garbled sentences and swapped terms found by review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - deploy-a-dm-cluster-using-tiup-offline.md: repair garbled template-reference sentence - dm-precheck.md: fix swapped mydumpers/threads relationship - release-2.0.4.md: complete 構成→設定 unification within the same bullet - release-6.4.0.md: repair garbled TiFlash SM4 encryption sentence --- dm/deploy-a-dm-cluster-using-tiup-offline.md | 2 +- dm/dm-precheck.md | 2 +- releases/release-2.0.4.md | 2 +- releases/release-6.4.0.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index 7177303b059bc..82475c432f829 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -70,7 +70,7 @@ source /home/tidb/.bash_profile さまざまなクラスター トポロジに応じて、クラスター初期化設定ファイルを編集する必要があります。 -完全な構成テンプレートについては、「 [TiUP設定パラメータ テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml) . 設定ファイルを作成する」 `topology.yaml`を参照してください。その他の複合シナリオでは、テンプレートに従って必要に応じて設定ファイルを編集します。 +完全な設定テンプレートについては、[TiUP設定パラメータテンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml)を参照してください。`topology.yaml`という設定ファイルを作成し、その他の複合シナリオでは、テンプレートに従って必要に応じて設定ファイルを編集してください。 3 つの DM-master、3つの DM-worker、および 1つの監視コンポーネントインスタンスをデプロイする構成は次のとおりです。 diff --git a/dm/dm-precheck.md b/dm/dm-precheck.md index a6fc1e65d63f4..2af88288aa9dc 100644 --- a/dm/dm-precheck.md +++ b/dm/dm-precheck.md @@ -184,7 +184,7 @@ tiup dmctl check-task ./task.yaml 移行タスクの事前チェックは並列処理に対応しています。シャーディングされたテーブルの行数が100万行に達した場合でも、事前チェックは数分で完了します。 -事前チェックのスレッド数を指定するには、移行タスク設定ファイルの`threads`フィールドの`mydumpers`引数を設定します。 +事前チェックのスレッド数を指定するには、移行タスク設定ファイルの`mydumpers`設定項目にある`threads`フィールドを設定します。 ```yaml mydumpers: # Configuration arguments of the dump processing unit diff --git a/releases/release-2.0.4.md b/releases/release-2.0.4.md index 38306b704c212..72fd0cf8306e6 100644 --- a/releases/release-2.0.4.md +++ b/releases/release-2.0.4.md @@ -14,7 +14,7 @@ summary: TiDB 2.0.4は2018年6月15日にリリースされ、システムの互 - 監視項目のステートメントタイプの表示を改良 - クエリコストの見積り精度を最適化する - gRPCの`backoff max delay`のパラメータを設定する -- 設定ファイル内の単一のステートメントのメモリしきい値の構成をサポート +- 設定ファイル内の単一のステートメントのメモリしきい値の設定をサポート - オプティマイザのエラーをリファクタリングする - `Cast Decimal`データの副作用を修正 - 特定のシナリオで`Merge Join`演算子の誤った結果の問題を修正しました diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 685228fa29922..7e8393089158d 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -61,7 +61,7 @@ TiDBバージョン: 6.4.0-DMR - TiFlashは保存時の暗号化にSM4アルゴリズムをサポートしています [#5953](https://github.com/pingcap/tiflash/issues/5953) @[lidezhu](https://github.com/lidezhu) - TiFlashの保存時暗号化にSM4アルゴリズムを追加します。保存時暗号化を設定する際に、 `data-encryption-method`設定ファイル内の`sm4-ctr` 構成の値を`tiflash-learner.toml`暗号化機能を有効にできます。 + TiFlashの保存時暗号化にSM4アルゴリズムを追加します。保存時暗号化を設定する際に、`tiflash-learner.toml`設定ファイル内の`data-encryption-method`設定の値を`sm4-ctr`に設定することで、暗号化機能を有効にできます。 詳細については、[ユーザー向けドキュメント](/encryption-at-rest.md#tiflash)を参照してください。 From 0e78286f0e1888571752e7667a525b632a76d758 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 14 Sep 2026 13:50:51 +0900 Subject: [PATCH 3/3] i18n(ja): add missing particle in release-6.1.4.md TiCDC bullet MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Without a particle after \`protocol\`, "\`protocol\`設定ファイル" reads as one compound noun ("protocol's configuration file") rather than the intended "\`transaction-atomicity\` and \`protocol\` cannot be updated via the configuration file" (EN: "Fix the issue that \`transaction-atomicity\` and \`protocol\` cannot be updated via the configuration file"). Add が to disambiguate. Co-Authored-By: Claude Sonnet 5 --- releases/release-6.1.4.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases/release-6.1.4.md b/releases/release-6.1.4.md index 7ff5c0cf106be..296cc9cda46ba 100644 --- a/releases/release-6.1.4.md +++ b/releases/release-6.1.4.md @@ -78,7 +78,7 @@ TiDB バージョン: 6.1.4 - TiCDC - TiCDC が過度に多数のテーブルを複製するとチェックポイントが進めなくなる問題を修正しました [#8004](https://github.com/pingcap/tiflow/issues/8004) @[asddongmen](https://github.com/asddongmen) - - `transaction-atomicity`と`protocol`設定ファイル経由で更新できない問題を修正 [#7935](https://github.com/pingcap/tiflow/issues/7935) @[CharlesCheung96](https://github.com/CharlesCheung96) + - `transaction-atomicity`と`protocol`が設定ファイル経由で更新できない問題を修正 [#7935](https://github.com/pingcap/tiflow/issues/7935) @[CharlesCheung96](https://github.com/CharlesCheung96) - TiFlashのバージョンがTiCDCのバージョンより新しい場合にTiCDCが誤ってエラーを報告する問題を修正しました [#7744](https://github.com/pingcap/tiflow/issues/7744) @[overvenus](https://github.com/overvenus) - TiCDCが大規模なトランザクションを複製するときにOOMが発生する問題を修正 [#7913](https://github.com/pingcap/tiflow/issues/7913) @[overvenus](https://github.com/overvenus) - TiCDCが大きなトランザクションを分割せずにデータを複製するとコンテキスト期限が超過するバグを修正 [#7982](https://github.com/pingcap/tiflow/issues/7982) @[Rustin170506](https://github.com/Rustin170506)