From 56a3582d72639d25b7298aee92d36c63de7e9b86 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 15 Jul 2026 13:27:42 +0900 Subject: [PATCH] =?UTF-8?q?i18n(ja):=20add=20missing=20object-marker=20par?= =?UTF-8?q?ticle=20(=E3=82=92)=20before=20code-span=20transitive=20verbs?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Verbs: 使用/実行/削除/取得/確認/指定/保存/作成/更新/生成/定義/出力/表示/計算/記録/参照 (followed by an active conjugation). Ambiguous verbs (設定/変更/追加/変換/適用: を/に/から) and passive され are excluded. Co-Authored-By: Claude Opus 4.8 (1M context) --- ai/guides/auto-embedding.md | 2 +- ai/guides/filtering.md | 2 +- ai/guides/tables.md | 4 +-- ai/guides/vector-search.md | 2 +- ai/quickstart-via-sql.md | 2 +- .../vector-search-improve-performance.md | 2 +- ai/reference/vector-search-index.md | 2 +- alert-rules.md | 12 +++---- analyze-slow-queries.md | 4 +-- as-of-timestamp.md | 4 +-- auto-increment.md | 8 ++--- auto-random.md | 12 +++---- batch-processing.md | 2 +- benchmark/benchmark-sysbench-v4-vs-v3.md | 2 +- benchmark/benchmark-tidb-using-ch.md | 2 +- benchmark/benchmark-tidb-using-sysbench.md | 2 +- best-practices/haproxy-best-practices.md | 2 +- .../high-concurrency-best-practices.md | 4 +-- .../index-management-best-practices.md | 8 ++--- .../pd-scheduling-best-practices.md | 2 +- .../three-nodes-hybrid-deployment.md | 2 +- .../tidb-partitioned-tables-best-practices.md | 6 ++-- best-practices/uuid.md | 2 +- blocklist-control-plan.md | 8 ++--- br/backup-and-restore-storages.md | 4 +-- br/br-auto-tune.md | 2 +- br/br-checkpoint-restore.md | 8 ++--- br/br-compact-log-backup.md | 2 +- br/br-incremental-guide.md | 2 +- br/br-monitoring-and-alert.md | 6 ++-- br/br-pitr-guide.md | 8 ++--- br/br-pitr-manual.md | 28 ++++++++-------- br/br-snapshot-guide.md | 2 +- br/br-snapshot-manual.md | 4 +-- br/br-use-overview.md | 2 +- cached-tables.md | 4 +-- character-set-and-collation.md | 20 ++++++------ check-before-deployment.md | 18 +++++------ clinic/clinic-user-guide-for-tiup.md | 2 +- command-line-flags-for-tidb-configuration.md | 16 +++++----- command-line-flags-for-tikv-configuration.md | 2 +- comment-syntax.md | 8 ++--- configure-memory-usage.md | 2 +- configure-placement-rules.md | 4 +-- configure-time-zone.md | 2 +- constraints.md | 6 ++-- coprocessor-cache.md | 2 +- dashboard/dashboard-diagnostics-report.md | 4 +-- data-type-date-and-time.md | 4 +-- data-type-json.md | 4 +-- data-type-numeric.md | 2 +- data-type-overview.md | 2 +- data-type-string.md | 2 +- ddl_embedded_analyze.md | 2 +- develop/dev-guide-choose-driver-or-orm.md | 2 +- develop/dev-guide-connection-parameters.md | 2 +- develop/dev-guide-join-tables.md | 4 +-- .../dev-guide-optimize-sql-best-practices.md | 4 +-- develop/dev-guide-optimize-sql.md | 6 ++-- develop/dev-guide-paginate-results.md | 4 +-- develop/dev-guide-playground-gitpod.md | 4 +-- develop/dev-guide-proxysql-integration.md | 2 +- ...guide-sample-application-java-hibernate.md | 2 +- ...ide-sample-application-java-spring-boot.md | 2 +- ...dev-guide-sql-development-specification.md | 4 +-- ...v-guide-third-party-tools-compatibility.md | 4 +-- develop/dev-guide-transaction-troubleshoot.md | 4 +-- develop/dev-guide-update-data.md | 2 +- develop/serverless-driver-prisma-example.md | 2 +- dm/deploy-a-dm-cluster-using-binary.md | 2 +- dm/deploy-a-dm-cluster-using-tiup-offline.md | 2 +- dm/deploy-a-dm-cluster-using-tiup.md | 2 +- dm/dm-best-practices.md | 4 +-- dm/dm-binlog-event-filter.md | 2 +- dm/dm-continuous-data-validation.md | 6 ++-- dm/dm-customized-secret-key.md | 2 +- dm/dm-error-handling.md | 20 ++++++------ dm/dm-faq.md | 10 +++--- dm/dm-handle-performance-issues.md | 10 +++--- dm/dm-manage-schema.md | 4 +-- dm/dm-manage-source.md | 6 ++-- dm/dm-online-ddl-tool-support.md | 2 +- dm/dm-pause-task.md | 4 +-- dm/dm-performance-test.md | 8 ++--- dm/dm-query-status.md | 8 ++--- dm/dm-webui-guide.md | 2 +- dm/feature-expression-filter.md | 2 +- dm/feature-online-ddl.md | 4 +-- dm/handle-failed-ddl-statements.md | 26 +++++++-------- dm/maintain-dm-using-tiup.md | 22 ++++++------- dm/manually-handling-sharding-ddl-locks.md | 32 +++++++++---------- dm/quick-start-with-dm.md | 2 +- dm/relay-log.md | 6 ++-- dm/shard-merge-best-practices.md | 12 +++---- dm/table-selector.md | 2 +- dm/usage-scenario-master-slave-switch.md | 10 +++--- dr-secondary-cluster.md | 2 +- dynamic-config.md | 16 +++++----- ecosystem-tool-user-guide.md | 2 +- enable-tls-between-components.md | 2 +- encryption-at-rest.md | 6 ++-- error-codes.md | 12 +++---- explain-aggregation.md | 2 +- explain-indexes.md | 4 +-- explain-joins.md | 2 +- explain-mpp.md | 2 +- explain-overview.md | 2 +- explain-walkthrough.md | 8 ++--- extended-statistics.md | 4 +-- external-storage-uri.md | 8 ++--- faq/backup-and-restore-faq.md | 10 +++--- faq/high-reliability-faq.md | 2 +- faq/sql-faq.md | 14 ++++---- faq/upgrade-faq.md | 2 +- filter-dml-event.md | 2 +- follower-read.md | 2 +- .../bit-functions-and-operators.md | 6 ++-- functions-and-operators/group-by-modifier.md | 6 ++-- .../information-functions.md | 2 +- functions-and-operators/string-functions.md | 6 ++-- functions-and-operators/tidb-functions.md | 8 ++--- generate-self-signed-certificates.md | 2 +- generated-columns.md | 2 +- identify-slow-queries.md | 2 +- .../client-errors-summary-by-host.md | 2 +- .../client-errors-summary-by-user.md | 2 +- .../client-errors-summary-global.md | 2 +- .../information-schema-cluster-log.md | 2 +- .../information-schema-inspection-result.md | 4 +-- .../information-schema-inspection-summary.md | 4 +-- .../information-schema-metrics-summary.md | 2 +- .../information-schema-sql-diagnostics.md | 2 +- maintain-tidb-using-tiup.md | 2 +- metrics-schema.md | 2 +- migrate-from-tidb-to-mysql.md | 2 +- migrate-from-tidb-to-tidb.md | 4 +-- migrate-small-mysql-shards-to-tidb.md | 6 ++-- migrate-small-mysql-to-tidb.md | 4 +-- migrate-with-more-columns-downstream.md | 2 +- non-transactional-dml.md | 6 ++-- online-unsafe-recovery.md | 2 +- optimizer-hints.md | 20 ++++++------ oracle-functions-to-tidb.md | 2 +- partition-pruning.md | 2 +- password-management.md | 2 +- pd-control.md | 2 +- pd-microservices.md | 2 +- performance-tuning-practices.md | 2 +- pessimistic-transaction.md | 2 +- pipelined-dml.md | 2 +- privilege-management.md | 2 +- read-historical-data.md | 6 ++-- releases/release-1.0.8.md | 2 +- releases/release-1.1-alpha.md | 2 +- releases/release-1.1-beta.md | 2 +- releases/release-2.0-ga.md | 6 ++-- releases/release-2.0-rc.3.md | 4 +-- releases/release-2.0-rc.4.md | 2 +- releases/release-2.0.3.md | 2 +- releases/release-2.1-beta.md | 6 ++-- releases/release-2.1-rc.1.md | 2 +- releases/release-2.1-rc.5.md | 2 +- releases/release-2.1.10.md | 2 +- releases/release-2.1.13.md | 2 +- releases/release-2.1.19.md | 4 +-- releases/release-2.1.8.md | 2 +- releases/release-3.0-ga.md | 8 ++--- releases/release-3.0.0-rc.1.md | 2 +- releases/release-3.0.0-rc.3.md | 4 +-- releases/release-3.0.11.md | 4 +-- releases/release-3.0.14.md | 2 +- releases/release-3.0.2.md | 4 +-- releases/release-3.0.20.md | 2 +- releases/release-3.0.3.md | 2 +- releases/release-3.0.6.md | 6 ++-- releases/release-3.0.8.md | 2 +- releases/release-3.1.0-rc.md | 2 +- releases/release-3.1.1.md | 2 +- releases/release-4.0-ga.md | 4 +-- releases/release-4.0.0-beta.1.md | 2 +- releases/release-4.0.0-beta.md | 2 +- releases/release-4.0.0-rc.1.md | 2 +- releases/release-4.0.0-rc.2.md | 4 +-- releases/release-4.0.0-rc.md | 2 +- releases/release-4.0.11.md | 2 +- releases/release-4.0.13.md | 6 ++-- releases/release-4.0.14.md | 4 +-- releases/release-4.0.15.md | 4 +-- releases/release-4.0.3.md | 4 +-- releases/release-4.0.5.md | 4 +-- releases/release-4.0.7.md | 2 +- releases/release-4.0.8.md | 2 +- releases/release-4.0.9.md | 2 +- releases/release-5.0.0-rc.md | 8 ++--- releases/release-5.0.0.md | 2 +- releases/release-5.0.1.md | 4 +-- releases/release-5.0.3.md | 2 +- releases/release-5.0.4.md | 6 ++-- releases/release-5.1.1.md | 6 ++-- releases/release-5.1.2.md | 2 +- releases/release-5.1.4.md | 4 +-- releases/release-5.2.2.md | 2 +- releases/release-5.3.0.md | 4 +-- releases/release-5.3.1.md | 2 +- releases/release-5.4.0.md | 2 +- releases/release-6.1.0.md | 4 +-- releases/release-6.1.6.md | 6 ++-- releases/release-6.1.7.md | 4 +-- releases/release-6.5.0.md | 6 ++-- releases/release-6.5.1.md | 4 +-- releases/release-6.5.10.md | 2 +- releases/release-6.5.12.md | 4 +-- releases/release-6.5.2.md | 4 +-- releases/release-6.5.3.md | 2 +- releases/release-6.5.4.md | 4 +-- releases/release-6.5.6.md | 4 +-- releases/release-6.5.8.md | 8 ++--- releases/release-7.1.0.md | 12 +++---- releases/release-7.1.1.md | 2 +- releases/release-7.1.3.md | 2 +- releases/release-7.1.4.md | 6 ++-- releases/release-7.1.5.md | 2 +- releases/release-7.1.6.md | 8 ++--- releases/release-7.4.0.md | 4 +-- releases/release-7.5.1.md | 16 +++++----- releases/release-7.5.2.md | 4 +-- releases/release-7.5.3.md | 8 ++--- releases/release-7.5.5.md | 8 ++--- releases/release-7.5.6.md | 8 ++--- releases/release-7.5.7.md | 4 +-- releases/release-8.0.0.md | 2 +- releases/release-8.1.0.md | 2 +- releases/release-8.1.1.md | 6 ++-- releases/release-8.3.0.md | 2 +- releases/release-pre-ga.md | 2 +- releases/release-rc.1.md | 2 +- resources/doc-templates/template-concept.md | 2 +- role-based-access-control.md | 10 +++--- runtime-filter.md | 2 +- scale-microservices-using-tiup.md | 6 ++-- scale-tidb-using-tiup.md | 4 +-- security-compatibility-with-mysql.md | 24 +++++++------- sql-logical-optimization.md | 2 +- sql-non-prepared-plan-cache.md | 4 +-- sql-plan-management.md | 4 +-- sql-plan-replayer.md | 4 +-- sql-prepared-plan-cache.md | 10 +++--- .../sql-statement-admin-bdr-role.md | 6 ++-- .../sql-statement-admin-cancel-ddl.md | 2 +- .../sql-statement-admin-check-table-index.md | 2 +- .../sql-statement-admin-resume-ddl.md | 2 +- .../sql-statement-admin-show-ddl.md | 8 ++--- .../sql-statement-alter-sequence.md | 2 +- sql-statements/sql-statement-alter-table.md | 2 +- sql-statements/sql-statement-analyze-table.md | 4 +-- sql-statements/sql-statement-batch.md | 2 +- .../sql-statement-calibrate-resource.md | 4 +-- .../sql-statement-create-binding.md | 2 +- .../sql-statement-create-database.md | 4 +-- sql-statements/sql-statement-create-role.md | 4 +-- .../sql-statement-create-sequence.md | 2 +- sql-statements/sql-statement-do.md | 2 +- sql-statements/sql-statement-drop-role.md | 4 +-- sql-statements/sql-statement-drop-table.md | 6 ++-- sql-statements/sql-statement-drop-user.md | 2 +- .../sql-statement-explain-analyze.md | 4 +-- sql-statements/sql-statement-explain.md | 8 ++--- .../sql-statement-flashback-database.md | 4 +-- .../sql-statement-flashback-table.md | 2 +- sql-statements/sql-statement-grant-role.md | 6 ++-- sql-statements/sql-statement-import-into.md | 2 +- sql-statements/sql-statement-load-data.md | 14 ++++---- sql-statements/sql-statement-lock-stats.md | 6 ++-- ...statement-lock-tables-and-unlock-tables.md | 2 +- sql-statements/sql-statement-recover-table.md | 6 ++-- sql-statements/sql-statement-restore.md | 2 +- sql-statements/sql-statement-revoke-role.md | 4 +-- sql-statements/sql-statement-savepoint.md | 4 +-- .../sql-statement-set-default-role.md | 4 +-- sql-statements/sql-statement-set-variable.md | 4 +-- .../sql-statement-show-stats-healthy.md | 2 +- .../sql-statement-show-stats-locked.md | 2 +- .../sql-statement-show-stats-meta.md | 2 +- sql-statements/sql-statement-show-tables.md | 2 +- sql-tuning-best-practice.md | 8 ++--- statistics.md | 2 +- storage-engine/titan-configuration.md | 2 +- subquery-optimization.md | 2 +- sync-diff-inspector/shard-diff.md | 2 +- system-variables.md | 8 ++--- table-filter.md | 4 +-- ticdc/ticdc-bidirectional-replication.md | 10 +++--- ticdc/ticdc-changefeed-overview.md | 2 +- ticdc/ticdc-client-authentication.md | 8 ++--- ticdc/ticdc-ddl.md | 2 +- ticdc/ticdc-faq.md | 8 ++--- ticdc/ticdc-manage-changefeed.md | 8 ++--- ticdc/ticdc-open-api-v2.md | 4 +-- ticdc/ticdc-open-api.md | 4 +-- ticdc/ticdc-sink-to-kafka.md | 8 ++--- ticdc/ticdc-sink-to-pulsar.md | 6 ++-- ticdc/ticdc-split-update-behavior.md | 2 +- ticdc/ticdc-upstream-downstream-check.md | 4 +-- ticdc/troubleshoot-ticdc.md | 10 +++--- tidb-cloud/csv-config-for-import-data.md | 2 +- tidb-cloud/data-service-manage-endpoint.md | 4 +-- .../premium/migrate-from-op-tidb-premium.md | 2 +- tidb-cloud/releases/release-notes-2023.md | 4 +-- tidb-cloud/releases/release-notes-2025.md | 4 +-- ...s-private-link-connection-to-amazon-msk.md | 2 +- ...rivate-link-connection-to-aws-confluent.md | 2 +- .../serverless-private-link-connection.md | 2 +- ...lf-hosted-kafka-private-service-connect.md | 4 +-- tidb-cloud/size-your-cluster.md | 4 +-- tidb-cloud/terraform-use-backup-resource.md | 4 +-- tidb-cloud/terraform-use-cluster-resource.md | 14 ++++---- ...erraform-use-dedicated-cluster-resource.md | 10 +++--- ...se-dedicated-network-container-resource.md | 4 +-- ...ed-private-endpoint-connection-resource.md | 4 +-- tidb-cloud/terraform-use-import-resource.md | 6 ++-- ...erraform-use-serverless-branch-resource.md | 4 +-- ...rless-cluster-resource-manage-essential.md | 8 ++--- ...rraform-use-serverless-cluster-resource.md | 8 ++--- ...erraform-use-serverless-export-resource.md | 6 ++-- tidb-cloud/terraform-use-sql-user-resource.md | 6 ++-- tidb-cloud/ticloud-cluster-create.md | 2 +- ...serverless-audit-log-filter-rule-create.md | 2 +- tidb-cloud/tidb-cloud-import-local-files.md | 4 +-- .../tidb-cloud-tls-connect-to-dedicated.md | 8 ++--- tidb-cloud/transaction-concepts.md | 2 +- tidb-cloud/use-chat2query-sessions.md | 2 +- ...v6.5-performance-benchmarking-with-tpcc.md | 2 +- ...v7.1-performance-benchmarking-with-tpcc.md | 2 +- ...v7.5-performance-benchmarking-with-tpcc.md | 2 +- ...v8.1-performance-benchmarking-with-tpcc.md | 2 +- ...v8.5-performance-benchmarking-with-tpcc.md | 2 +- tidb-computing.md | 2 +- tidb-control.md | 14 ++++---- tidb-lightning/deploy-tidb-lightning.md | 2 +- .../import-into-vs-tidb-lightning.md | 2 +- tidb-lightning/tidb-lightning-checkpoints.md | 2 +- .../tidb-lightning-command-line-full.md | 4 +-- ...b-lightning-compatibility-and-scenarios.md | 2 +- .../tidb-lightning-configuration.md | 4 +-- tidb-lightning/tidb-lightning-data-source.md | 8 ++--- .../tidb-lightning-distributed-import.md | 6 ++-- tidb-lightning/tidb-lightning-faq.md | 2 +- tidb-lightning/troubleshoot-tidb-lightning.md | 8 ++--- tidb-monitoring-api.md | 4 +-- tidb-read-staleness.md | 2 +- tidb-resource-control-background-tasks.md | 2 +- tidb-resource-control-runaway-queries.md | 4 +-- tidb-rowid.md | 16 +++++----- tidb-troubleshooting-map.md | 2 +- tidb-upgrade-migration-guide.md | 2 +- tiflash-upgrade-guide.md | 2 +- tiflash/create-tiflash-replicas.md | 2 +- tiflash/tiflash-command-line-flags.md | 2 +- tiflash/tiflash-results-materialization.md | 4 +-- tiflash/troubleshoot-tiflash.md | 6 ++-- tiflash/tune-tiflash-performance.md | 2 +- tiflash/use-tidb-to-read-tiflash.md | 2 +- tikv-control.md | 28 ++++++++-------- time-to-live.md | 8 ++--- tiproxy/tiproxy-command-line-flags.md | 4 +-- tiproxy/tiproxy-configuration.md | 2 +- tiproxy/tiproxy-performance-test.md | 4 +-- tiup/tiup-bench.md | 6 ++-- tiup/tiup-cluster-no-sudo-mode.md | 8 ++--- tiup/tiup-cluster.md | 16 +++++----- tiup/tiup-command-completion.md | 4 +-- tiup/tiup-command-env.md | 4 +-- tiup/tiup-command-list.md | 2 +- tiup/tiup-command-mirror-clone.md | 2 +- tiup/tiup-command-mirror-genkey.md | 6 ++-- tiup/tiup-command-mirror-modify.md | 2 +- tiup/tiup-command-mirror-rotate.md | 6 ++-- tiup/tiup-component-cluster-audit.md | 4 +-- tiup/tiup-component-cluster-check.md | 4 +-- tiup/tiup-component-cluster-deploy.md | 2 +- tiup/tiup-component-cluster-disable.md | 2 +- tiup/tiup-component-cluster-enable.md | 2 +- tiup/tiup-component-cluster-patch.md | 2 +- tiup/tiup-component-cluster-reload.md | 6 ++-- tiup/tiup-component-cluster-scale-in.md | 2 +- tiup/tiup-component-cluster-scale-out.md | 2 +- tiup/tiup-component-cluster-upgrade.md | 6 ++-- tiup/tiup-component-dm-audit.md | 4 +-- tiup/tiup-component-dm-disable.md | 2 +- tiup/tiup-component-dm-enable.md | 2 +- tiup/tiup-component-dm-import.md | 4 +-- tiup/tiup-component-dm-patch.md | 10 +++--- tiup/tiup-component-dm-reload.md | 4 +-- tiup/tiup-component-management.md | 4 +-- tiup/tiup-mirror-reference.md | 4 +-- tiup/tiup-mirror.md | 8 ++--- tiup/tiup-playground.md | 2 +- tiup/tiup-reference.md | 6 ++-- tiup/tiup-troubleshooting-guide.md | 12 +++---- transaction-overview.md | 2 +- troubleshoot-cpu-issues.md | 12 +++---- troubleshoot-hot-spot-issues.md | 10 +++--- troubleshoot-lock-conflicts.md | 4 +-- troubleshoot-stale-read.md | 2 +- troubleshoot-tidb-oom.md | 14 ++++---- troubleshoot-write-conflicts.md | 4 +-- tune-operating-system.md | 4 +-- 407 files changed, 946 insertions(+), 946 deletions(-) diff --git a/ai/guides/auto-embedding.md b/ai/guides/auto-embedding.md index b8ad302fb7dbf..6e82021aae68b 100644 --- a/ai/guides/auto-embedding.md +++ b/ai/guides/auto-embedding.md @@ -29,7 +29,7 @@ embed_func = EmbeddingFunction( ### ステップ2. テーブルとベクトルフィールドを作成する {#step-2-create-a-table-and-a-vector-field} -テーブル スキーマにベクトル フィールドを作成するには、 `embed_func.VectorField()`使用します。 +テーブル スキーマにベクトル フィールドを作成するには、 `embed_func.VectorField()`を使用します。 自動埋め込みを有効にするには、埋め込みたいフィールドに`source_field`設定します。 diff --git a/ai/guides/filtering.md b/ai/guides/filtering.md index 63d54b1762e6c..a594492e603d7 100644 --- a/ai/guides/filtering.md +++ b/ai/guides/filtering.md @@ -13,7 +13,7 @@ summary: アプリケーションでフィルタリングを使用する方法 [`pytidb`](https://github.com/pingcap/pytidb)は、開発者が AI アプリケーションを効率的に構築できるように設計されています。 -`pytidb`使用する場合、 `table.query()` 、 `table.delete()` 、 `table.update()` 、および`table.search()`メソッドに**filters**パラメータを渡すことでフィルタリングを適用できます。 +`pytidb`を使用する場合、 `table.query()` 、 `table.delete()` 、 `table.update()` 、および`table.search()`メソッドに**filters**パラメータを渡すことでフィルタリングを適用できます。 **フィルター**パラメータは、 [辞書フィルター](#dictionary-filters)と[SQL文字列フィルター](#sql-string-filters) 2 つの形式をサポートします。 diff --git a/ai/guides/tables.md b/ai/guides/tables.md index 728d7f58c83c1..9515e1be5b69a 100644 --- a/ai/guides/tables.md +++ b/ai/guides/tables.md @@ -155,7 +155,7 @@ VALUES ### ディクト付き {#with-dict} -`dict`使って行を表し、それをテーブルに挿入することもできます。この方法はより柔軟で、データを挿入するために`TableModel`使用する必要がありません。 +`dict`使って行を表し、それをテーブルに挿入することもできます。この方法はより柔軟で、データを挿入するために`TableModel`を使用する必要がありません。 単一のレコードを挿入するには: @@ -192,7 +192,7 @@ VALUES (1, 'TiDB is a distributed SQL database', '[0.1, 0.2, 0.3]', '{"category" > **注記：** > -> テーブル内にレコードIDが既に存在する場合、 `table.save()`​​レコード全体を上書きします。レコードの一部のみを変更するには、 `table.update()`使用します。 +> テーブル内にレコードIDが既に存在する場合、 `table.save()`​​レコード全体を上書きします。レコードの一部のみを変更するには、 `table.update()`を使用します。
diff --git a/ai/guides/vector-search.md b/ai/guides/vector-search.md index ee4a29cad19c7..c7b12d97a0b4d 100644 --- a/ai/guides/vector-search.md +++ b/ai/guides/vector-search.md @@ -20,7 +20,7 @@ summary: アプリケーションでベクトル検索を使用する方法を
-`client.create_table()`使用してテーブルを作成し、 `VectorField`使用してベクトル フィールドを定義できます。 +`client.create_table()`を使用してテーブルを作成し、 `VectorField`を使用してベクトル フィールドを定義できます。 次の例では、4 つの列を持つ`documents`テーブルを作成します。 diff --git a/ai/quickstart-via-sql.md b/ai/quickstart-via-sql.md index 01cf80778a70e..7de5ce85ea65f 100644 --- a/ai/quickstart-via-sql.md +++ b/ai/quickstart-via-sql.md @@ -143,7 +143,7 @@ SELECT * FROM embedded_documents; この例では、検索語は「泳ぐ動物」であり、それに対応するベクトル埋め込みは`[1,2,3]`であると想定されています。実際のアプリケーションでは、埋め込みモデルを使用して、ユーザーの検索語をベクトル埋め込みに変換する必要があります。 -次の SQL ステートメントを実行すると、TiDB はテーブル内のベクトル埋め込み間のコサイン距離 ( `[1,2,3]`計算してソートすることにより、 `vec_cosine_distance` } に最も近い上位 3 つのドキュメントを特定します。 +次の SQL ステートメントを実行すると、TiDB はテーブル内のベクトル埋め込み間のコサイン距離 ( `[1,2,3]`を計算してソートすることにより、 `vec_cosine_distance` } に最も近い上位 3 つのドキュメントを特定します。 ```sql SELECT id, document, vec_cosine_distance(embedding, '[1,2,3]') AS distance diff --git a/ai/reference/vector-search-improve-performance.md b/ai/reference/vector-search-improve-performance.md index 2354aef96b905..f717b0b80ea5c 100644 --- a/ai/reference/vector-search-improve-performance.md +++ b/ai/reference/vector-search-improve-performance.md @@ -33,7 +33,7 @@ OpenAI `text-embedding-3-large`などの特定の埋め込みモデルは[埋め ベクトル埋め込みデータは通常サイズが大きく、検索プロセスでのみ使用されます。クエリ結果からベクトル列を除外することで、TiDBサーバーとSQLクライアント間で転送されるデータ量を大幅に削減し、クエリパフォーマンスを向上させることができます。 -ベクトル列を除外するには、 `SELECT *`使用してすべての列を取得するのではなく、 `SELECT`句で取得する列を明示的にリストします。 +ベクトル列を除外するには、 `SELECT *`を使用してすべての列を取得するのではなく、 `SELECT`句で取得する列を明示的にリストします。 ## インデックスをウォームアップする {#warm-up-the-index} diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md index e5288a27d59b2..c98a28f5ea637 100644 --- a/ai/reference/vector-search-index.md +++ b/ai/reference/vector-search-index.md @@ -144,7 +144,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES; 詳細については[`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md)参照してください。 -さらに、 `ADMIN SHOW DDL JOBS;`実行して`row count`を確認することで、DDLジョブの実行進捗状況を監視できます。ただし、 `row count`値は`TIFLASH_INDEXES`の`rows_stable_indexed`フィールドから取得されるため、この方法は完全に正確ではありません。この方法は、インデックス作成の進捗状況を追跡するための参照として使用できます。 +さらに、 `ADMIN SHOW DDL JOBS;`を実行して`row count`を確認することで、DDLジョブの実行進捗状況を監視できます。ただし、 `row count`値は`TIFLASH_INDEXES`の`rows_stable_indexed`フィールドから取得されるため、この方法は完全に正確ではありません。この方法は、インデックス作成の進捗状況を追跡するための参照として使用できます。 ## ベクトルインデックスが使用されているかどうかを確認する {#check-whether-the-vector-index-is-used} diff --git a/alert-rules.md b/alert-rules.md index 3b736b346f521..8dc56b50f2771 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -168,7 +168,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 解決： - `admin show ddl`実行して、時間のかかる`add index`操作が実行されているかどうかを確認します。 + `admin show ddl`を実行して、時間のかかる`add index`操作が実行されているかどうかを確認します。 ## PDアラートルール {#pd-alert-rules} @@ -447,7 +447,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 解決： - 1. `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME = "tikv_gc_leader_desc"`実行して、GC リーダーに対応する`tidb-server`を見つけます。 + 1. `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME = "tikv_gc_leader_desc"`を実行して、GC リーダーに対応する`tidb-server`を見つけます。 2. `tidb-server`のログを確認し、`grep gc_worker tidb.log` を実行します。 3. この時間中にGCワーカーがロックを解決中（最後のログは「start resolve locks」）または範囲を削除中（最後のログは「start delete {number} ranges」）であることが確認された場合、GCプロセスは正常に動作していることを意味します。それ以外の場合は、PingCAPまたはコミュニティから[サポートを受ける](/support.md)取得してください。 @@ -768,7 +768,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 解決： - リージョン分割の速度は書き込み速度よりも遅いです。この問題を軽減するには、TiDBをバッチ分割をサポートするバージョン（2.1.0-rc1以上）にアップデートすることをお勧めします。一時的にアップデートできない場合は、 `pd-ctl operator add split-region --policy=approximate`使用して手動でリージョンを分割できます。 + リージョン分割の速度は書き込み速度よりも遅いです。この問題を軽減するには、TiDBをバッチ分割をサポートするバージョン（2.1.0-rc1以上）にアップデートすることをお勧めします。一時的にアップデートできない場合は、 `pd-ctl operator add split-region --policy=approximate`を使用して手動でリージョンを分割できます。 ## TiFlashアラートルール {#tiflash-alert-rules} @@ -844,7 +844,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - 解決： - Grafana Node Exporter ダッシュボードでホストのメモリ パネルを確認し、使用済みメモリが多すぎるかどうか、使用可能なメモリが少なすぎるかどうかを確認します。 - - マシンにログインし、コマンド`free -m`を実行してメモリ使用量を確認します。コマンド`top`実行すると、メモリ使用量が過度に高い異常なプロセスがあるかどうかを確認できます。 + - マシンにログインし、コマンド`free -m`を実行してメモリ使用量を確認します。コマンド`top`を実行すると、メモリ使用量が過度に高い異常なプロセスがあるかどうかを確認できます。 ### 警告レベルのアラート {#warning-level-alerts} @@ -890,8 +890,8 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - 解決： - - マシンにログインし、 `ss -s`実行して、現在のシステムで「estab」ステータスにある TCP リンクの数を確認します。 - - `netstat`実行して異常なリンクがないか確認します。 + - マシンにログインし、 `ss -s`を実行して、現在のシステムで「estab」ステータスにある TCP リンクの数を確認します。 + - `netstat`を実行して異常なリンクがないか確認します。 #### `NODE_disk_read_latency_more_than_32ms` {#node-disk-read-latency-more-than-32ms} diff --git a/analyze-slow-queries.md b/analyze-slow-queries.md index 2d39a6a325cdf..5fd02bbac1426 100644 --- a/analyze-slow-queries.md +++ b/analyze-slow-queries.md @@ -41,7 +41,7 @@ summary: スロークエリを見つけて分析する方法を学びます。 上記の方法は、以下の点で異なります。 - スロー ログには、解析から結果の返却まで、SQL 実行のほぼすべての段階の期間が記録され、比較的包括的です (TiDB Dashboardでスロー ログを直感的にクエリおよび分析できます)。 -- `EXPLAIN ANALYZE`実行すると、実際のSQL実行における各演算子の消費時間を知ることができます。結果には、実行時間に関するより詳細な統計情報が含まれます。 +- `EXPLAIN ANALYZE`を実行すると、実際のSQL実行における各演算子の消費時間を知ることができます。結果には、実行時間に関するより詳細な統計情報が含まれます。 まとめると、スローログと`EXPLAIN ANALYZE`ステートメントは、SQLクエリの実行がどのコンポーネント（TiDBまたはTiKV）でどの段階で遅いのかを判断するのに役立ちます。これにより、クエリのパフォーマンスボトルネックを正確に特定できます。 @@ -102,7 +102,7 @@ SQL文の実行中に、TiDBは複数のTiKVインスタンスからデータを TiKV上に古いMVCCバージョンが多すぎる場合、またはGCのMVCC履歴データの保持期間が長い場合、過剰なMVCCバージョンが蓄積される可能性があります。これらの不要なMVCCバージョンを処理すると、スキャンのパフォーマンスに影響する可能性があります。 -`Total_keys`と`Processed_keys`確認してください。大きく異なる場合は、TiKVインスタンスに古いバージョンのキーが多すぎます。 +`Total_keys`と`Processed_keys`を確認してください。大きく異なる場合は、TiKVインスタンスに古いバージョンのキーが多すぎます。 ... # Total_keys: 2215187529 Processed_keys: 1108056368 diff --git a/as-of-timestamp.md b/as-of-timestamp.md index 39cb0a34d9965..bdf0e91f716c7 100644 --- a/as-of-timestamp.md +++ b/as-of-timestamp.md @@ -23,7 +23,7 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標 正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには「2016-10-08 16:45:26」のように秒単位で十分です。3 関数を使用して、現在時刻を`NOW(3)`秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。 -時間範囲を指定する場合は、句内で[`TIDB_BOUNDED_STALENESS()`](/functions-and-operators/tidb-functions.md#tidb_bounded_staleness)関数を使用できます。この関数を使用すると、TiDB は指定された時間範囲内で適切なタイムスタンプを選択します。「適切」とは、このタイムスタンプより前に開始され、アクセス先のレプリカにコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセス先のレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされていないことを意味します。この関数を呼び出すには`TIDB_BOUNDED_STALENESS(t1, t2)`使用する必要があります。5 と`t2` `t1`範囲の両端であり、datetime 値または時間関数を使用して指定できます。 +時間範囲を指定する場合は、句内で[`TIDB_BOUNDED_STALENESS()`](/functions-and-operators/tidb-functions.md#tidb_bounded_staleness)関数を使用できます。この関数を使用すると、TiDB は指定された時間範囲内で適切なタイムスタンプを選択します。「適切」とは、このタイムスタンプより前に開始され、アクセス先のレプリカにコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセス先のレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされていないことを意味します。この関数を呼び出すには`TIDB_BOUNDED_STALENESS(t1, t2)`を使用する必要があります。5 と`t2` `t1`範囲の両端であり、datetime 値または時間関数を使用して指定できます。 `AS OF TIMESTAMP`句の例をいくつか示します。 @@ -42,7 +42,7 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標 ## 使用例 {#usage-examples} -このセクションでは、いくつかの例を用いて、 `AS OF TIMESTAMP`句の様々な使用方法を説明します。まず、リカバリ用のデータの準備方法を紹介し、次に`SELECT` 、 `START TRANSACTION READ ONLY AS OF TIMESTAMP` 、 `SET TRANSACTION READ ONLY AS OF TIMESTAMP`でそれぞれ`AS OF TIMESTAMP`使用する方法を示します。 +このセクションでは、いくつかの例を用いて、 `AS OF TIMESTAMP`句の様々な使用方法を説明します。まず、リカバリ用のデータの準備方法を紹介し、次に`SELECT` 、 `START TRANSACTION READ ONLY AS OF TIMESTAMP` 、 `SET TRANSACTION READ ONLY AS OF TIMESTAMP`でそれぞれ`AS OF TIMESTAMP`を使用する方法を示します。 ### データサンプルを準備する {#prepare-data-sample} diff --git a/auto-increment.md b/auto-increment.md index 32ddb3b37a250..ebd02b59e5ad1 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -206,7 +206,7 @@ Query OK, 1 row affected (0.03 sec) 4 rows in set (0.00 sec) ``` -初期TiDBサーバーに対する新たな`INSERT`操作は、 `AUTO_INCREMENT`の値`4`生成します。これは、初期TiDBサーバーの`AUTO_INCREMENT`キャッシュにまだ割り当て用のスペースが残っているためです。この場合、 `4`の値が`2000001`の後に挿入されるため、値のシーケンスはグローバルに単調であるとは考えられません。 +初期TiDBサーバーに対する新たな`INSERT`操作は、 `AUTO_INCREMENT`の値`4`を生成します。これは、初期TiDBサーバーの`AUTO_INCREMENT`キャッシュにまだ割り当て用のスペースが残っているためです。この場合、 `4`の値が`2000001`の後に挿入されるため、値のシーケンスはグローバルに単調であるとは考えられません。 ```sql mysql> INSERT INTO t (a) VALUES (NULL); @@ -284,7 +284,7 @@ mysql> SELECT * FROM t ORDER BY b; 11 rows in set (0.00 sec) ``` -値`2030000`が挿入された後、次の値は`2060001`です。このシーケンスのジャンプは、別の TiDBサーバーが中間キャッシュ範囲`[2030001-2060000]`取得しているためです。複数の TiDB サーバーが展開されている場合、キャッシュ要求がインターリーブされるため、 `AUTO_INCREMENT`シーケンスにギャップが生じます。 +値`2030000`が挿入された後、次の値は`2060001`です。このシーケンスのジャンプは、別の TiDBサーバーが中間キャッシュ範囲`[2030001-2060000]`を取得しているためです。複数の TiDB サーバーが展開されている場合、キャッシュ要求がインターリーブされるため、 `AUTO_INCREMENT`シーケンスにギャップが生じます。 ### キャッシュサイズの制御 {#cache-size-control} @@ -466,7 +466,7 @@ IDは常に増加し、 `AUTO_ID_CACHE 0`のような大きなギャップは発 - TiDB v6.6.0 以前のバージョンの場合、定義された列は主キーまたはインデックス プレフィックスのいずれかである必要があります。 - `INTEGER` 、 `FLOAT` 、または`DOUBLE`タイプの列に定義する必要があります。 - `DEFAULT`列の値と同じ列には指定できません。 -- `ALTER TABLE` 、属性`AUTO_INCREMENT`を持つ列を追加または変更するために使用できません。これには、属性`AUTO_INCREMENT`既存の列に追加するために`ALTER TABLE ... MODIFY/CHANGE COLUMN`使用することや、属性`AUTO_INCREMENT`を持つ列を追加するために`ALTER TABLE ... ADD COLUMN`使用することも含まれます。 -- `ALTER TABLE` `AUTO_INCREMENT`属性を削除するために使用できます。ただし、v2.1.18 および v3.0.4 以降、TiDB はセッション変数`@@tidb_allow_remove_auto_inc`使用して、列の`AUTO_INCREMENT`の属性を削除するために`ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`使用できるかどうかを制御します。デフォルトでは、 `ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`使用して`AUTO_INCREMENT`番目の属性を削除することはできません。 +- `ALTER TABLE` 、属性`AUTO_INCREMENT`を持つ列を追加または変更するために使用できません。これには、属性`AUTO_INCREMENT`既存の列に追加するために`ALTER TABLE ... MODIFY/CHANGE COLUMN`を使用することや、属性`AUTO_INCREMENT`を持つ列を追加するために`ALTER TABLE ... ADD COLUMN`を使用することも含まれます。 +- `ALTER TABLE` `AUTO_INCREMENT`属性を削除するために使用できます。ただし、v2.1.18 および v3.0.4 以降、TiDB はセッション変数`@@tidb_allow_remove_auto_inc`を使用して、列の`AUTO_INCREMENT`の属性を削除するために`ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用できるかどうかを制御します。デフォルトでは、 `ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用して`AUTO_INCREMENT`番目の属性を削除することはできません。 - `ALTER TABLE` 、 `AUTO_INCREMENT`値を小さい値に設定するには`FORCE`オプションが必要です。 - `AUTO_INCREMENT` `MAX()`より小さい値に設定すると、既存の値がスキップされないため、キーが重複することになります。 diff --git a/auto-random.md b/auto-random.md index 61cc19bf30eb4..f494930132654 100644 --- a/auto-random.md +++ b/auto-random.md @@ -120,7 +120,7 @@ TiDB によって自動的に割り当てられる`AUTO_RANDOM(S, R)`列の値 - 値に符号付きビットがあるかどうかは、対応する列に`UNSIGNED`属性があるかどうかによって決まります。 - 符号ビットの長さは、属性`UNSIGNED`有無によって決まります。属性`UNSIGNED`がある場合、長さは`0`です。そうでない場合、長さは`1`です。 - 予約ビットの長さは`64-R`です。予約ビットは常に`0`です。 -- シャードビットの内容は、現在のトランザクションの開始時刻のハッシュ値を計算することで得られます。異なるシャードビット長（10など）を使用する場合は、テーブル作成時に`AUTO_RANDOM(10)`指定します。 +- シャードビットの内容は、現在のトランザクションの開始時刻のハッシュ値を計算することで得られます。異なるシャードビット長（10など）を使用する場合は、テーブル作成時に`AUTO_RANDOM(10)`を指定します。 - AUTO_INCREMENTビットの値はストレージエンジンに格納され、順次割り当てられます。新しい値が割り当てられるたびに、値は1ずつ増加します。AUTO_INCREMENTビットは、 `AUTO_RANDOM`の値がグローバルに一意であることを保証します。AUTO_INCREMENTビットが使い果たされると、値が再び割り当てられる際にエラー`Failed to read auto-increment value from storage engine`が報告されます。 - 値の範囲：最終的に生成される値の最大ビット数 = シャードビット数 + AUTO_INCREMENTビット数。符号付き列の範囲は`[-(2^(R-1))+1, (2^(R-1))-1]` 、符号なし列の範囲は`[0, (2^R)-1]`です。 - `AUTO_RANDOM` `PRE_SPLIT_REGIONS`と組み合わせて使用できます。テーブルが正常に作成されると、 `PRE_SPLIT_REGIONS`テーブル内のデータを`2^(PRE_SPLIT_REGIONS)`で指定された数のリージョンに事前に分割します。 @@ -141,7 +141,7 @@ TiDB によって自動的に割り当てられる`AUTO_RANDOM(S, R)`列の値 列番号が`AUTO_RANDOM`であるテーブルのシャードビット数を確認するには、 `SHOW CREATE TABLE`ステートメントを実行します。また、 `information_schema.tables`システムテーブルの列番号`TIDB_ROW_ID_SHARDING_INFO`で、 `PK_AUTO_RANDOM_BITS=x`のモードの値を確認することもできます`x`はシャードビット数です。 -`AUTO_RANDOM`列のテーブルを作成した後、 `SHOW WARNINGS`使用して最大暗黙的割り当て時間を表示できます。 +`AUTO_RANDOM`列のテーブルを作成した後、 `SHOW WARNINGS`を使用して最大暗黙的割り当て時間を表示できます。 ```sql CREATE TABLE t (a BIGINT AUTO_RANDOM, b VARCHAR(255), PRIMARY KEY (a)); @@ -195,19 +195,19 @@ ALTER TABLE t FORCE AUTO_RANDOM_BASE = 1000; > **注記：** > -> `FORCE`使用する場合は、ゼロ以外の正の整数を指定する必要があります。 +> `FORCE`を使用する場合は、ゼロ以外の正の整数を指定する必要があります。 どちらのコマンドも、すべてのTiDBノードにおける後続の`AUTO_RANDOM`値生成で使用されるAUTO_INCREMENTビットの開始点を変更します。すでに割り当てられているIDには影響しません。 ## 制限 {#restrictions} -`AUTO_RANDOM`使用する場合は、次の制限に注意してください。 +`AUTO_RANDOM`を使用する場合は、次の制限に注意してください。 - 明示的に値を挿入するには、システム変数`@@allow_auto_random_explicit_insert`の値を`1` （デフォルトは`0` ）に設定する必要があります。データを挿入する際に、属性`AUTO_RANDOM`持つ列に明示的に値を指定することは推奨さ**れません**。そうしないと、このテーブルに自動的に割り当てられる数値が事前に使い果たされてしまう可能性があります。 - この属性は、主キー列に**のみ**`BIGINT`型で指定してください。それ以外の場合はエラーが発生します。また、主キーの属性が`NONCLUSTERED`の場合、整数型の主キーであっても`AUTO_RANDOM`サポートされません`CLUSTERED`型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 -- `ALTER TABLE`使用して`AUTO_RANDOM`属性を変更することはできません (この属性の追加や削除を含む)。 +- `ALTER TABLE`を使用して`AUTO_RANDOM`属性を変更することはできません (この属性の追加や削除を含む)。 - 最大値が列タイプの最大値に近い場合は、 `ALTER TABLE`を使用して`AUTO_INCREMENT`から`AUTO_RANDOM`に変更することはできません。 - `AUTO_RANDOM`属性で指定された主キー列の列タイプを変更することはできません。 -- 同じ列に同時に`AUTO_RANDOM`と`AUTO_INCREMENT`指定することはできません。 +- 同じ列に同時に`AUTO_RANDOM`と`AUTO_INCREMENT`を指定することはできません。 - 同じ列に`AUTO_RANDOM`と`DEFAULT` (列のデフォルト値) を同時に指定することはできません。 - 列に`AUTO_RANDOM`使用されている場合、自動生成される値が非常に大きくなる可能性があるため、列属性を`AUTO_INCREMENT`に戻すのは困難です。 diff --git a/batch-processing.md b/batch-processing.md index 3da81974e746a..69ccf23c35745 100644 --- a/batch-processing.md +++ b/batch-processing.md @@ -45,7 +45,7 @@ summary: パイプライン DML、非トランザクション DML、IMPORT INTO` ### ユースケース {#use-cases} -- データの移行や復旧などのデータインポートシナリオに適しています。該当する場合は、 TiDB Lightningではなく`IMPORT INTO`使用することをお勧めします。 +- データの移行や復旧などのデータインポートシナリオに適しています。該当する場合は、 TiDB Lightningではなく`IMPORT INTO`を使用することをお勧めします。 詳細については[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)参照してください。 diff --git a/benchmark/benchmark-sysbench-v4-vs-v3.md b/benchmark/benchmark-sysbench-v4-vs-v3.md index 32cca59095e26..190c5078d036a 100644 --- a/benchmark/benchmark-sysbench-v4-vs-v3.md +++ b/benchmark/benchmark-sysbench-v4-vs-v3.md @@ -93,7 +93,7 @@ set global tidb_disable_txn_auto_retry=0; 2. Sysbench を使用して、各テーブルに 1,000 万行のデータが含まれる 16 個のテーブルをインポートします。 3. 各テーブルに対して`analyze table`ステートメントを実行します。 4. さまざまな同時実行テストの前に、復元に使用するデータをバックアップします。これにより、各テストのデータの一貫性が確保されます。 -5. Sysbenchクライアントを起動して`update_index` `update_non_index` `point_select` `read_write`実行します。AWS NLB経由でTiDBのストレステストを実行します。各テストのウォームアップには1分、テストには5分かかります。 +5. Sysbenchクライアントを起動して`update_index` `update_non_index` `point_select` `read_write`を実行します。AWS NLB経由でTiDBのストレステストを実行します。各テストのウォームアップには1分、テストには5分かかります。 6. 各タイプのテストが完了したら、クラスターを停止し、手順 4 のバックアップ データでクラスターを上書きして、クラスターを再起動します。 ### テストデータを準備する {#prepare-test-data} diff --git a/benchmark/benchmark-tidb-using-ch.md b/benchmark/benchmark-tidb-using-ch.md index f1cc155bef27b..791ae30b09b70 100644 --- a/benchmark/benchmark-tidb-using-ch.md +++ b/benchmark/benchmark-tidb-using-ch.md @@ -62,7 +62,7 @@ TiFlashをデプロイした後、 TiFlash はTiKV データを自動的に複 ALTER DATABASE tpcc SET tiflash replica 2; -`tpcc`データベース内のすべてのテーブルのレプリケーションが完了しているかどうかを確認するには、次のステートメントを実行します。3 句は、確認するデータベースとテーブルを指定します。すべてのデータベースのレプリケーション状態を確認する場合は、ステートメントから`WHERE`句`WHERE`削除します。 +`tpcc`データベース内のすべてのテーブルのレプリケーションが完了しているかどうかを確認するには、次のステートメントを実行します。3 句は、確認するデータベースとテーブルを指定します。すべてのデータベースのレプリケーション状態を確認する場合は、ステートメントから`WHERE`句`WHERE`を削除します。 ```sql SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'tpcc'; diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 8ef9aca7cbb11..5c960ad8f5ae0 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -158,7 +158,7 @@ sysbench --config-file=config oltp_read_only --tables=32 --table-size=10000000 - この問題は多くの場合、プロキシの使用に関係しています。単一のTiDBサーバーに負荷をかけ、それぞれの結果を合計し、プロキシを使用した結果と比較することができます。 -HAproxyを例に挙げましょう。パラメータ`nbproc`指定すると、起動できるプロセスの最大数を増やすことができます。HAproxyの最新バージョンでは、 `nbthread`と`cpu-map`サポートされています。これらはすべて、プロキシの使用によるパフォーマンスへの悪影響を軽減します。 +HAproxyを例に挙げましょう。パラメータ`nbproc`を指定すると、起動できるプロセスの最大数を増やすことができます。HAproxyの最新バージョンでは、 `nbthread`と`cpu-map`サポートされています。これらはすべて、プロキシの使用によるパフォーマンスへの悪影響を軽減します。 ### 同時実行性が高いのに、TiKV の CPU 使用率が低いのはなぜですか? {#under-high-concurrency-why-is-the-cpu-utilization-rate-of-tikv-still-low} diff --git a/best-practices/haproxy-best-practices.md b/best-practices/haproxy-best-practices.md index 3e00a7a3deb1e..8aa2eaaca724d 100644 --- a/best-practices/haproxy-best-practices.md +++ b/best-practices/haproxy-best-practices.md @@ -196,7 +196,7 @@ listen tidb-cluster # Database load balancing. server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3 ``` -`SHOW PROCESSLIST`使用して送信元 IP アドレスを確認するには、 [PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)を TiDB に接続するように設定する必要があります。 +`SHOW PROCESSLIST`を使用して送信元 IP アドレスを確認するには、 [PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)を TiDB に接続するように設定する必要があります。 ```yaml server tidb-1 10.9.18.229:4000 send-proxy check inter 2000 rise 2 fall 3 diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md index 3f0cfff798c58..cbe16b2ccce7b 100644 --- a/best-practices/high-concurrency-best-practices.md +++ b/best-practices/high-concurrency-best-practices.md @@ -194,7 +194,7 @@ ORDER BY テーブルに主キーがない場合、または主キーが`Int`型ではなく、ランダムに分布する主キーIDを生成したくない場合、TiDBは暗黙的に`_tidb_rowid`列を行IDとして提供します。一般的に、 `SHARD_ROW_ID_BITS`列のパラメータを使用しない場合、 `_tidb_rowid`列の値も単調に増加するため、ホットスポットが発生する可能性があります。詳細は[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)を参照してください。 -このような状況でホットスポット問題を回避するには、テーブル作成時に`SHARD_ROW_ID_BITS`と`PRE_SPLIT_REGIONS`使用します。 `PRE_SPLIT_REGIONS`の詳細については、 [分割前のリージョン](/sql-statements/sql-statement-split-region.md#pre_split_regions)を参照してください。 +このような状況でホットスポット問題を回避するには、テーブル作成時に`SHARD_ROW_ID_BITS`と`PRE_SPLIT_REGIONS`を使用します。 `PRE_SPLIT_REGIONS`の詳細については、 [分割前のリージョン](/sql-statements/sql-statement-split-region.md#pre_split_regions)を参照してください。 `SHARD_ROW_ID_BITS` 、 `_tidb_rowid`列に生成された行 ID をランダムに散布するために使用されます。4 `PRE_SPLIT_REGIONS` 、テーブルの作成後にリージョンを事前に分割するために使用されます。 @@ -221,7 +221,7 @@ create table t (a int, b int) SHARD_ROW_ID_BITS = 4 PRE_SPLIT_REGIONS=3; **問題2:** -テーブルの主キーが整数型で、テーブルが主キーの一意性を確保するために`AUTO_INCREMENT`使用している場合 (必ずしも連続または増分ではない)、TiDB は主キーの行値を`_tidb_rowid`として直接使用するため、このテーブルでホットスポットを分散するために`SHARD_ROW_ID_BITS`使用することはできません。 +テーブルの主キーが整数型で、テーブルが主キーの一意性を確保するために`AUTO_INCREMENT`を使用している場合 (必ずしも連続または増分ではない)、TiDB は主キーの行値を`_tidb_rowid`として直接使用するため、このテーブルでホットスポットを分散するために`SHARD_ROW_ID_BITS`を使用することはできません。 このシナリオの問題に対処するには、データを挿入する際に`AUTO_INCREMENT` [`AUTO_RANDOM`](/auto-random.md) （列属性）に置き換えます。そうすることで、TiDBは整数型の主キー列に自動的に値を割り当て、行IDの連続性が失われ、ホットスポットが分散されます。 diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index b52410574ac9d..d1c21c93acc09 100644 --- a/best-practices/index-management-best-practices.md +++ b/best-practices/index-management-best-practices.md @@ -163,7 +163,7 @@ ORDER BY total_queries DESC; `TIDB_INDEX_USAGE`と同様に、このシステムテーブルはノードの再起動後にデータを保持しません。ノードがダウンした場合、記録されたインデックス使用状況データは失われます。 -`CLUSTER_TIDB_INDEX_USAGE`使用すると、インデックスの動作を全体的に把握でき、インデックス戦略が分散クエリのワークロードに適合していることを確認できます。 +`CLUSTER_TIDB_INDEX_USAGE`を使用すると、インデックスの動作を全体的に把握でき、インデックス戦略が分散クエリのワークロードに適合していることを確認できます。 ## schema_unused_indexesを使用して未使用のインデックスを識別する {#identify-unused-indexes-using-code-schema-unused-indexes-code} @@ -175,7 +175,7 @@ ORDER BY total_queries DESC; - `INSERT` 、 `UPDATE` 、 `DELETE`クエリにオーバーヘッドを追加するインデックスを削除することで、DML 操作を高速化します。 - クエリ パターンを手動で分析する必要なく、インデックス監査を合理化します。 -`schema_unused_indexes`使用すると、不要なインデックスをすばやく識別し、最小限の労力でデータベースのオーバーヘッドを削減できます。 +`schema_unused_indexes`を使用すると、不要なインデックスをすばやく識別し、最小限の労力でデータベースのオーバーヘッドを削減できます。 ### schema_unused_indexes仕組み {#how-code-schema-unused-indexes-code-works} @@ -198,7 +198,7 @@ SELECT * FROM sys.schema_unused_indexes; ### schema_unused_indexesを使用する際の考慮事項 {#considerations-when-using-code-schema-unused-indexes-code} -`schema_unused_indexes`使用する場合は、次の点に注意してください。 +`schema_unused_indexes`を使用する場合は、次の点に注意してください。 #### インデックスは最後の再起動以降のみ未使用とみなされます {#indexes-are-considered-unused-only-since-the-last-restart} @@ -302,7 +302,7 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; - フィルタリングの効率を向上させるために列を追加します。 - インデックス構造の変更 (プレフィックス インデックス、複合インデックスなど)。 - - インデックスの選択性を分析します。3 `TIDB_INDEX_USAGE`フィールドのうち`PERCENTAGE_ACCESS_*`使用して、インデックスがデータをどの程度適切にフィルタリングしているかを評価します。 + - インデックスの選択性を分析します。3 `TIDB_INDEX_USAGE`フィールドのうち`PERCENTAGE_ACCESS_*`を使用して、インデックスがデータをどの程度適切にフィルタリングしているかを評価します。 4. **DML パフォーマンスへの影響に注意してください。** diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 4ceb0ff28f373..8d74a5cf7b66a 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -78,7 +78,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ ### ホットリージョンのスケジュール {#hot-regions-scheduling} -ホットリージョンのスケジューリングには`hot-region-scheduler`使用します。TiDB v3.0以降では、このプロセスは次のように実行されます。 +ホットリージョンのスケジューリングには`hot-region-scheduler`を使用します。TiDB v3.0以降では、このプロセスは次のように実行されます。 1. ストアから報告された情報に基づいて、一定期間内に特定のしきい値を超える読み取り/書き込みトラフィックを判別し、ホットリージョンをカウントします。 diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index 9c17f7cd94c21..78380f3329fec 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/best-practices/three-nodes-hybrid-deployment.md @@ -99,7 +99,7 @@ RocksDBスレッドプールの最適化方法は、コンパクションスレ #### `gc.max_write_bytes_per_sec` {#gc-max-write-bytes-per-sec} -TiDBはマルチバージョン同時実行制御（MVCC）モデルを使用しているため、TiKVは定期的に古いバージョンのデータをバックグラウンドで消去します。利用可能なリソースが限られている場合、この操作によって定期的なパフォーマンスジッターが発生します。1パラメータ`gc.max_write_bytes_per_sec`使用すると、このような操作のリソース使用量を制限できます。 +TiDBはマルチバージョン同時実行制御（MVCC）モデルを使用しているため、TiKVは定期的に古いバージョンのデータをバックグラウンドで消去します。利用可能なリソースが限られている場合、この操作によって定期的なパフォーマンスジッターが発生します。1パラメータ`gc.max_write_bytes_per_sec`を使用すると、このような操作のリソース使用量を制限できます。 ![GC Impact](/media/best-practices/three-nodes-gc-impact.png) diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md index d44bb2d93fdf4..46d88e9c05f27 100644 --- a/best-practices/tidb-partitioned-tables-best-practices.md +++ b/best-practices/tidb-partitioned-tables-best-practices.md @@ -170,12 +170,12 @@ WHERE `fa`.`sid` IN ( > **注記：** > > - TiDB v8.5.3以前のバージョンでは、一意の列に対してのみグローバルインデックスを作成できました。v8.5.4以降では、一意でない列に対してもグローバルインデックスを作成できます。この制限は、将来のLTSバージョンで解除される予定です。 -> - 一意でないグローバル インデックスの場合は、 `ADD UNIQUE INDEX`ではなく`ADD INDEX`使用します。 +> - 一意でないグローバル インデックスの場合は、 `ADD UNIQUE INDEX`ではなく`ADD INDEX`を使用します。 > - `GLOBAL`キーワードを明示的に指定する必要があります。 ##### オプション1: ALTER TABLEを使用する {#option-1-use-code-alter-table-code} -既存のパーティションテーブルにグローバルインデックスを追加するには、 `ALTER TABLE`使用します。 +既存のパーティションテーブルにグローバルインデックスを追加するには、 `ALTER TABLE`を使用します。 ```sql ALTER TABLE @@ -604,7 +604,7 @@ SHOW TABLE employees PARTITION (p4) regions; #### デメリット {#disadvantages} -`DROP PARTITION`使用して大量の履歴データを効率的に削除することはできません。 +`DROP PARTITION`を使用して大量の履歴データを効率的に削除することはできません。 #### 適切なシナリオ {#suitable-scenarios} diff --git a/best-practices/uuid.md b/best-practices/uuid.md index 612711f0681cb..640c5afeeb653 100644 --- a/best-practices/uuid.md +++ b/best-practices/uuid.md @@ -32,7 +32,7 @@ UUID を主キーとして使用すると、 [`AUTO_INCREMENT`](/auto-increment. ホットスポットを回避するために、UUID ベースの主キーに[`CLUSTERED`オプション](/clustered-indexes.md)明示的に設定することもできます。 -`swap_flag`の効果を示すために、同じ構造を持つ2つのテーブルを示します。違いは、 `uuid_demo_1`に挿入されたデータは`UUID_TO_BIN(?, 0)`使用し、 `uuid_demo_2` `UUID_TO_BIN(?, 1)`使用していることです。 +`swap_flag`の効果を示すために、同じ構造を持つ2つのテーブルを示します。違いは、 `uuid_demo_1`に挿入されたデータは`UUID_TO_BIN(?, 0)`使用し、 `uuid_demo_2` `UUID_TO_BIN(?, 1)`を使用していることです。 以下の Key Visualizer のスクリーンショットでは、バイナリ形式でフィールドの順序が入れ替わった`uuid_demo_2`テーブルの 1 つのリージョンに書き込みが集中していることがわかります。 diff --git a/blocklist-control-plan.md b/blocklist-control-plan.md index 1d50372e08c2d..c527b5c27a1da 100644 --- a/blocklist-control-plan.md +++ b/blocklist-control-plan.md @@ -112,7 +112,7 @@ DESC mysql.expr_pushdown_blacklist; 1. 対応する関数名または演算子名と、プッシュダウンを無効にするコンポーネントのセットを`mysql.expr_pushdown_blacklist`テーブルに挿入します。 -2. `admin reload expr_pushdown_blacklist`実行します。 +2. `admin reload expr_pushdown_blacklist`を実行します。 ### ブロックリストから削除 {#remove-from-the-blocklist} @@ -120,7 +120,7 @@ DESC mysql.expr_pushdown_blacklist; 1. 対応する関数名または演算子名、およびプッシュダウンを無効にするコンポーネントのセットを`mysql.expr_pushdown_blacklist`テーブルから削除します。 -2. `admin reload expr_pushdown_blacklist`実行します。 +2. `admin reload expr_pushdown_blacklist`を実行します。 > **注記：** > @@ -149,7 +149,7 @@ DESC mysql.expr_pushdown_blacklist; 3 rows in set (0.00 sec) ``` -2. 式を`mysql.expr_pushdown_blacklist`テーブルに挿入し、 `admin reload expr_pushdown_blacklist`実行します。 +2. 式を`mysql.expr_pushdown_blacklist`テーブルに挿入し、 `admin reload expr_pushdown_blacklist`を実行します。 ```sql INSERT INTO mysql.expr_pushdown_blacklist VALUES('<','tikv',''), ('>','tikv',''); @@ -185,7 +185,7 @@ DESC mysql.expr_pushdown_blacklist; 3 rows in set (0.00 sec) ``` -4. ブロックリストから 1 つの式 (ここでは`>` ) を削除し、 `admin reload expr_pushdown_blacklist`実行します。 +4. ブロックリストから 1 つの式 (ここでは`>` ) を削除し、 `admin reload expr_pushdown_blacklist`を実行します。 ```sql DELETE FROM mysql.expr_pushdown_blacklist WHERE name = '>'; diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md index 5b52764d9ae8e..08bd3994ede89 100644 --- a/br/backup-and-restore-storages.md +++ b/br/backup-and-restore-storages.md @@ -171,11 +171,11 @@ TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部スト - 方法1: 共有アクセス署名を指定する - URIに`account-name`と`sas-token`指定した場合、指定されたアカウント名と共有アクセス署名（SAS）トークンを使用して認証が行われます。SASトークンには`&`という文字が含まれていることに注意してください。これをURIに追加する前に、 `%26`としてエンコードする必要があります。パーセントエンコードを使用して、 `sas-token`全体を直接エンコードすることもできます。 + URIに`account-name`と`sas-token`を指定した場合、指定されたアカウント名と共有アクセス署名（SAS）トークンを使用して認証が行われます。SASトークンには`&`という文字が含まれていることに注意してください。これをURIに追加する前に、 `%26`としてエンコードする必要があります。パーセントエンコードを使用して、 `sas-token`全体を直接エンコードすることもできます。 - 方法2: アクセスキーを指定する - URIに`account-name`と`account-key`指定すると、指定されたアカウント名とアカウントキーを用いて認証が行われます。URIでキーを指定する方法に加え、 BRは環境変数`$AZURE_STORAGE_KEY`からキーを読み取ることもできます。 + URIに`account-name`と`account-key`を指定すると、指定されたアカウント名とアカウントキーを用いて認証が行われます。URIでキーを指定する方法に加え、 BRは環境変数`$AZURE_STORAGE_KEY`からキーを読み取ることもできます。 - 方法3: バックアップと復元にAzure ADを使用する diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md index 1651751b09c7f..df65dc67ed7a2 100644 --- a/br/br-auto-tune.md +++ b/br/br-auto-tune.md @@ -31,7 +31,7 @@ TiKVは自動チューニング機能の動的な設定をサポートしてい tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v ``` -オフライン クラスターでバックアップ タスクを実行する場合、バックアップを高速化するために、 `backup.num-threads`の値を`tikv-ctl`使用してより大きな数値に変更できます。 +オフライン クラスターでバックアップ タスクを実行する場合、バックアップを高速化するために、 `backup.num-threads`の値を`tikv-ctl`を使用してより大きな数値に変更できます。 ## 制限事項 {#limitations} diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index c8f4f607fe7c4..307fec2651bfa 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -47,7 +47,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた ログの復元が完了すると、GCは手動で起動することなく自動的に再起動されます。ただし、復元を続行しない場合は、以下の手順でGCを手動で有効にすることができます。 -`br` GCを一時停止する原理は、 `SET config tikv gc.ratio-threshold = -1.0`実行して`gc.ratio-threshold`負の値に設定し、GCを一時停止することです。 [`gc.ratio-threshold`](/tikv-configuration-file.md#ratio-threshold)の値を変更することで、GCを手動で有効にすることができます。例えば、デフォルト値にリセットするには、 `SET config tikv gc.ratio-threshold = 1.1`実行します。 +`br` GCを一時停止する原理は、 `SET config tikv gc.ratio-threshold = -1.0`を実行して`gc.ratio-threshold`負の値に設定し、GCを一時停止することです。 [`gc.ratio-threshold`](/tikv-configuration-file.md#ratio-threshold)の値を変更することで、GCを手動で有効にすることができます。例えば、デフォルト値にリセットするには、 `SET config tikv gc.ratio-threshold = 1.1`を実行します。 ### 一部のデータは再度復元する必要があります {#some-data-needs-to-be-restored-again} @@ -87,7 +87,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた 初期リストアでは、 `br`スナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。 -初期復元中にログ復元フェーズに入ると、 `br`ターゲットクラスターに`__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、アップストリームクラスターID、および復元時間範囲（ `start-ts`と`restored-ts` ）が記録されます。このフェーズで復元に失敗した場合は、再試行時にチェックポイントデータベースに記録されているのと同じ`start-ts`と`restored-ts`指定する必要があります。そうでない場合、 `br`エラーを報告し、現在指定されている復元時間範囲またはアップストリームクラスターIDがチェックポイントレコードと異なることを通知します。復元クラスターがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。 +初期復元中にログ復元フェーズに入ると、 `br`ターゲットクラスターに`__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、アップストリームクラスターID、および復元時間範囲（ `start-ts`と`restored-ts` ）が記録されます。このフェーズで復元に失敗した場合は、再試行時にチェックポイントデータベースに記録されているのと同じ`start-ts`と`restored-ts`を指定する必要があります。そうでない場合、 `br`エラーを報告し、現在指定されている復元時間範囲またはアップストリームクラスターIDがチェックポイントレコードと異なることを通知します。復元クラスターがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。 初期リストア中のログリストアフェーズに入る前に、 `br` `restored-ts`時点における上流および下流のクラスタデータベースとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、システムテーブル`mysql.tidb_pitr_id_map`に保存されます。mysql.tidb_pitr_id_map**からデータを恣意的に削除すると`mysql.tidb_pitr_id_map` PITRリストアデータの不整合が発生する可能性があります。** @@ -141,7 +141,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた ### スナップショットの復元 {#snapshot-restore} -初期復元中に、 `br`指定された外部ストレージに`restore-{downstream-cluster-ID}/snapshot`パス`br`作成します。このパスには、チェックポイントデータ、上流クラスタID、およびバックアップデータのBackupTSが記録されます。 +初期復元中に、 `br`指定された外部ストレージに`restore-{downstream-cluster-ID}/snapshot`パス`br`を作成します。このパスには、チェックポイントデータ、上流クラスタID、およびバックアップデータのBackupTSが記録されます。 復元が失敗した場合は、同じコマンドを使用して再試行できます。1 `br` 、指定された外部ストレージパスからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 @@ -153,7 +153,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた 初期リストアでは、 `br`スナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `restore-{downstream-cluster-ID}/snapshot`パスに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。 -初期復元中にログ復元フェーズに入ると、 `br`​​指定された外部ストレージに`restore-{downstream-cluster-ID}/log`パスを作成します。このパスには、チェックポイント データ、アップストリーム クラスタ ID、および復元時間範囲 ( `start-ts`と`restored-ts` ) が記録されます。このフェーズで復元が失敗した場合は、再試行時にチェックポイント データベースに記録されているのと同じ`start-ts`と`restored-ts`指定する必要があります。そうでない場合、 `br`はエラーを報告し、現在指定されている復元時間範囲またはアップストリーム クラスタ ID がチェックポイント レコードと異なることを通知します。復元クラスタがクリーンアップされている場合は、外部ストレージ内のチェックポイント データを手動でクリーンアップするか、チェックポイント データを保存するための別の外部ストレージパスを指定して、別のバックアップで再試行できます。 +初期復元中にログ復元フェーズに入ると、 `br`​​指定された外部ストレージに`restore-{downstream-cluster-ID}/log`パスを作成します。このパスには、チェックポイント データ、アップストリーム クラスタ ID、および復元時間範囲 ( `start-ts`と`restored-ts` ) が記録されます。このフェーズで復元が失敗した場合は、再試行時にチェックポイント データベースに記録されているのと同じ`start-ts`と`restored-ts`を指定する必要があります。そうでない場合、 `br`はエラーを報告し、現在指定されている復元時間範囲またはアップストリーム クラスタ ID がチェックポイント レコードと異なることを通知します。復元クラスタがクリーンアップされている場合は、外部ストレージ内のチェックポイント データを手動でクリーンアップするか、チェックポイント データを保存するための別の外部ストレージパスを指定して、別のバックアップで再試行できます。 初期リストア中のログリストアフェーズに入る前に、 `br` `restored-ts`時点における上流クラスタと下流クラスタのデータベースIDとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、ファイル名`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`でチェックポイントストレージに保存されます。pitr_id_maps **`pitr_id_maps`からファイルを恣意的に削除すると、PITR リストアデータの不整合が発生する可能性があります。** diff --git a/br/br-compact-log-backup.md b/br/br-compact-log-backup.md index 1847adc675a91..992e82af2c082 100644 --- a/br/br-compact-log-backup.md +++ b/br/br-compact-log-backup.md @@ -78,7 +78,7 @@ echo $(( $(date --date '2004-05-06 15:02:01Z' +%s%3N) << 18 )) > **注記：** > -> macOS ユーザーの場合は、 Homebrew経由で`coreutils`インストールし、 `date`ではなく`gdate`使用する必要があります。 +> macOS ユーザーの場合は、 Homebrew経由で`coreutils`インストールし、 `date`ではなく`gdate`を使用する必要があります。 > > ```shell > echo $(( $(gdate --date '2004-05-06 15:02:01Z' +%s%3N) << 18 )) diff --git a/br/br-incremental-guide.md b/br/br-incremental-guide.md index bdb278c25e7f3..95bfa5050fb38 100644 --- a/br/br-incremental-guide.md +++ b/br/br-incremental-guide.md @@ -25,7 +25,7 @@ TiDBクラスターの増分データは、期間の開始スナップショッ ## 増分データをバックアップする {#back-up-incremental-data} -増分データをバックアップするには、 `tiup br backup`コマンドを、**最終バックアップのタイムスタンプ**`--lastbackupts`を指定して実行します。これにより、br コマンドラインツールは`lastbackupts`から現在時刻の間に生成された増分データを自動的にバックアップします。9 `--lastbackupts`取得するには、 `validate`コマンドを実行します。以下は例です。 +増分データをバックアップするには、 `tiup br backup`コマンドを、**最終バックアップのタイムスタンプ**`--lastbackupts`を指定して実行します。これにより、br コマンドラインツールは`lastbackupts`から現在時刻の間に生成された増分データを自動的にバックアップします。9 `--lastbackupts`を取得するには、 `validate`コマンドを実行します。以下は例です。 ```shell LAST_BACKUP_TS=`tiup br validate decode --field="end-version" --storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"| tail -n1` diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md index 5c5e93107cf28..87e4ba29e3031 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -97,19 +97,19 @@ groups: - 警告項目: `max(time() - tidb_log_backup_last_checkpoint / 262144000) by (task) / 3600 > 2 and max(tidb_log_backup_last_checkpoint) by (task) > 0 and max(tikv_log_backup_task_status) by (task) == 1` - 警戒レベル：警告 -- 説明: ログバックアップタスクが2時間以上一時停止されています。このアラートはリマインダーであり、できるだけ早く`br log resume`実行してください。 +- 説明: ログバックアップタスクが2時間以上一時停止されています。このアラートはリマインダーであり、できるだけ早く`br log resume`を実行してください。 #### ログバックアップ一時停止中（12時間以上） {#logbackuppausingmorethan12h} - 警告項目: `max(time() - tidb_log_backup_last_checkpoint / 262144000) by (task) / 3600 > 12 and max(tidb_log_backup_last_checkpoint) by (task) > 0 and max(tikv_log_backup_task_status) by (task) == 1` - 警戒レベル: 重大 -- 説明: ログバックアップタスクが12時間以上一時停止されています。タスクを再開するには、できるだけ早く`br log resume`実行してください。ログタスクの一時停止時間が長すぎると、データが失われるリスクがあります。 +- 説明: ログバックアップタスクが12時間以上一時停止されています。タスクを再開するには、できるだけ早く`br log resume`を実行してください。ログタスクの一時停止時間が長すぎると、データが失われるリスクがあります。 #### ログバックアップ失敗 {#logbackupfailed} - 警告項目: `max(tikv_log_backup_task_status) by (task) == 2 and max(tidb_log_backup_last_checkpoint) by (task) > 0` - 警戒レベル: 重大 -- 説明: ログバックアップタスクが失敗しました。失敗の原因を確認するには、 `br log status`実行する必要があります。必要に応じて、TiKV ログをさらに確認する必要があります。 +- 説明: ログバックアップタスクが失敗しました。失敗の原因を確認するには、 `br log status`を実行する必要があります。必要に応じて、TiKV ログをさらに確認する必要があります。 #### ログバックアップGCセーフポイントがチェックポイントを超える {#logbackupgcsafepointexceedscheckpoint} diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md index f4f31a53d7978..37db52651dce1 100644 --- a/br/br-pitr-guide.md +++ b/br/br-pitr-guide.md @@ -18,7 +18,7 @@ br コマンドライン ツール (以下、 `br`と呼びます) を使用し > - 以下の例では、Amazon S3 アクセスキーとシークレットキーを使用して権限を承認することを前提としています。IAM ロールを使用して権限を承認する場合は、 `--send-credentials-to-tikv`を`false`に設定する必要があります。 > - 他のストレージシステムまたは認証方法を使用して権限を認証する場合は、 [バックアップストレージ](/br/backup-and-restore-storages.md)に従ってパラメータ設定を調整します。 -ログ バックアップを開始するには、 `tiup br log start`実行します。クラスターは 1 回につき 1 つのログ バックアップ タスクのみ実行できます。 +ログ バックアップを開始するには、 `tiup br log start`を実行します。クラスターは 1 回につき 1 つのログ バックアップ タスクのみ実行できます。 ```shell tiup br log start --task-name=pitr --pd "${PD_IP}:2379" \ @@ -70,7 +70,7 @@ tiup br log status --task-name=pitr --pd "${PD_IP}:2379" ### 定期的に完全バックアップを実行する {#run-full-backup-regularly} -スナップショットバックアップは、フルバックアップの方法として使用できます。1 `tiup br backup full`実行すると、固定スケジュール（たとえば2日ごと）に従ってクラスタースナップショットをバックアップストレージにバックアップできます。 +スナップショットバックアップは、フルバックアップの方法として使用できます。1 `tiup br backup full`を実行すると、固定スケジュール（たとえば2日ごと）に従ってクラスタースナップショットをバックアップストレージにバックアップできます。 ```shell tiup br backup full --pd "${PD_IP}:2379" \ @@ -79,7 +79,7 @@ tiup br backup full --pd "${PD_IP}:2379" \ ## PITRを実行する {#run-pitr} -バックアップ保持期間内の任意の時点にクラスターを復元するには、 `tiup br restore point`使用します。このコマンドを実行する際は、**復元する時点**、**その時点より前の最新のスナップショットバックアップデータ**、および**ログバックアップデータ**を指定する必要があります。BRは復元に必要なデータを自動的に判別して読み取り、これらのデータを指定されたクラスターに順番に復元します。 +バックアップ保持期間内の任意の時点にクラスターを復元するには、 `tiup br restore point`を使用します。このコマンドを実行する際は、**復元する時点**、**その時点より前の最新のスナップショットバックアップデータ**、および**ログバックアップデータ**を指定する必要があります。BRは復元に必要なデータを自動的に判別して読み取り、これらのデータを指定されたクラスターに順番に復元します。 ```shell tiup br restore point --pd "${PD_IP}:2379" \ @@ -106,7 +106,7 @@ Restore KV Files <-------------------------------------------------------------- [TiDB バックアップと復元の使用概要](/br/br-use-overview.md)で説明したとおり: -PITRを実行するには、復元ポイントより前のフルバックアップと、フルバックアップポイントから復元ポイントまでのログバックアップを復元する必要があります。そのため、バックアップ保持期間を超えるログバックアップについては、 `tiup br log truncate`使用して指定時点より前のバックアップを削除できます。**フルスナップショットより前のログバックアップのみを削除することをお勧めします**。 +PITRを実行するには、復元ポイントより前のフルバックアップと、フルバックアップポイントから復元ポイントまでのログバックアップを復元する必要があります。そのため、バックアップ保持期間を超えるログバックアップについては、 `tiup br log truncate`を使用して指定時点より前のバックアップを削除できます。**フルスナップショットより前のログバックアップのみを削除することをお勧めします**。 次の手順では、バックアップ保持期間を超えたバックアップ データをクリーンアップする方法について説明します。 diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index 8a37e941c407b..67cf617e503e8 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -48,7 +48,7 @@ Available Commands: `tiup br log start`コマンドを実行すると、ログバックアップタスクを開始できます。このタスクはTiDBクラスターのバックグラウンドで実行され、KVストレージの変更ログをバックアップストレージに自動的にバックアップします。 -ヘルプ情報を表示するには、 `tiup br log start --help`実行します。 +ヘルプ情報を表示するには、 `tiup br log start --help`を実行します。 ```shell tiup br log start --help @@ -75,7 +75,7 @@ Global Flags: - `--start-ts` : ログバックアップの開始タイムスタンプを指定します。このパラメータが指定されていない場合、バックアッププログラムは現在の時刻を`start-ts`として使用します。 - `task-name` : ログバックアップのタスク名を指定します。この名前は、バックアップタスクのクエリ、一時停止、再開にも使用されます。 -- `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。 +- `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`を指定します。 - `--pd` : バックアップ クラスターの PD アドレスを指定します。BRはログ バックアップ タスクを開始するために PD にアクセスする必要があります。 - `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのstorageとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 @@ -156,7 +156,7 @@ tiup br log start \ `tiup br log status`コマンドを実行して、ログ バックアップの状態を照会できます。 -ヘルプ情報を表示するには、 `tiup br log status --help`実行します。 +ヘルプ情報を表示するには、 `tiup br log status --help`を実行します。 ```shell tiup br log status --help @@ -213,7 +213,7 @@ checkpoint[global]: 2022-07-25 22:52:15.518 +0800; gap=2m52s 実行中のログ バックアップ タスクを一時停止するには、 `tiup br log pause`コマンドを実行します。 -ヘルプ情報を表示するには、 `tiup br log pause --help`実行します。 +ヘルプ情報を表示するには、 `tiup br log pause --help`を実行します。 ```shell tiup br log pause --help @@ -247,7 +247,7 @@ tiup br log pause --task-name=pitr --pd="${PD_IP}:2379" 一時停止されたバックアップ タスクを再開するには、 `tiup br log resume`コマンドを実行します。 -ヘルプ情報を表示するには、 `tiup br log resume --help`実行します。 +ヘルプ情報を表示するには、 `tiup br log resume --help`を実行します。 ```shell tiup br log resume --help @@ -267,7 +267,7 @@ Global Flags: -u, --pd strings PD address (default [127.0.0.1:2379]) ``` -バックアップタスクが24時間以上一時停止された後、 `tiup br log resume`実行するとエラーが発生し、 BRはバックアップデータが失われたというメッセージを表示します。このエラーに対処するには、 [バックアップと復元に関するよくある質問](/faq/backup-and-restore-faq.md#what-should-i-do-if-the-error-message-errbackupgcsafepointexceeded-is-returned-when-using-the-br-log-resume-command-to-resume-a-suspended-task)を参照してください。 +バックアップタスクが24時間以上一時停止された後、 `tiup br log resume`を実行するとエラーが発生し、 BRはバックアップデータが失われたというメッセージを表示します。このエラーに対処するには、 [バックアップと復元に関するよくある質問](/faq/backup-and-restore-faq.md#what-should-i-do-if-the-error-message-errbackupgcsafepointexceeded-is-returned-when-using-the-br-log-resume-command-to-resume-a-suspended-task)を参照してください。 使用例: @@ -283,7 +283,7 @@ tiup br log resume --task-name=pitr --pd="${PD_IP}:2379" ログバックアップタスクを停止するには、コマンド`tiup br log stop`を実行します。このコマンドは、バックアップクラスター内のタスクメタデータをクリーンアップします。 -ヘルプ情報を表示するには、 `tiup br log stop --help`実行します。 +ヘルプ情報を表示するには、 `tiup br log stop --help`を実行します。 ```shell tiup br log stop --help @@ -305,7 +305,7 @@ Global Flags: > **注記：** > -> このコマンドは注意して使用してください。ログバックアップタスクを一時停止する必要がある場合は、代わりに`tiup br log pause`と`tiup br log resume`使用してください。 +> このコマンドは注意して使用してください。ログバックアップタスクを一時停止する必要がある場合は、代わりに`tiup br log pause`と`tiup br log resume`を使用してください。 使用例: @@ -318,14 +318,14 @@ tiup br log stop --task-name=pitr --pd="${PD_IP}:2379" `tiup br log stop`コマンドを実行してログバックアップタスクを停止した後、別の`--storage`ディレクトリに新しいログバックアップタスクを作成するか、 `tiup br log start`コマンドを実行して元の`--storage`ディレクトリでログバックアップタスクを再開できます。元の`--storage`ディレクトリでタスクを再開する場合は、以下の点に注意してください。 - タスクを再開するための`--storage`ディレクトリのパラメータは、停止されたタスクと同じである必要があります。 -- `--start-ts`指定する必要はありません。BRは最後のバックアップ チェックポイントから自動的にバックアップを開始します。 +- `--start-ts`を指定する必要はありません。BRは最後のバックアップ チェックポイントから自動的にバックアップを開始します。 - タスクが長時間停止し、複数のバージョンのデータがガベージコレクションされている場合、タスクを再開しようとするとエラー`BR:Backup:ErrBackupGCSafepointExceeded`が報告されます。この場合、別のディレクトリ`--storage`に新しいログバックアップタスクを作成する必要があります。 ### ログバックアップデータをクリーンアップする {#clean-up-log-backup-data} `tiup br log truncate`コマンドを実行して、古くなった、または不要になったログ バックアップ データをクリーンアップできます。 -ヘルプ情報を表示するには、 `tiup br log truncate --help`実行します。 +ヘルプ情報を表示するには、 `tiup br log truncate --help`を実行します。 ```shell tiup br log truncate --help @@ -372,7 +372,7 @@ Removing metadata... DONE; take = 24.038962ms `tiup br log metadata`コマンドを実行すると、復元できる最も古いタイムスタンプや最新のタイムスタンプなど、ストレージシステム内のログ バックアップ メタデータを表示できます。 -ヘルプ情報を表示するには、 `tiup br log metadata --help`実行します。 +ヘルプ情報を表示するには、 `tiup br log metadata --help`を実行します。 ```shell tiup br log metadata --help @@ -408,11 +408,11 @@ tiup br log metadata --storage='s3://backup-101/logbackup?access-key=${access-ke > **注記：** > -> `restore point`の増分バックアップ アドレスとして`--full-backup-storage`指定した場合、このバックアップと以前の増分バックアップを復元するには、増分バックアップと後続のログ バックアップとの互換性を確保するために、パラメータ`--allow-pitr-from-incremental` `true`に設定する必要があります。 +> `restore point`の増分バックアップ アドレスとして`--full-backup-storage`を指定した場合、このバックアップと以前の増分バックアップを復元するには、増分バックアップと後続のログ バックアップとの互換性を確保するために、パラメータ`--allow-pitr-from-incremental` `true`に設定する必要があります。 `tiup br restore point`コマンドを実行して、新しいクラスターで PITR を実行したり、ログ バックアップ データを復元したりできます。 -ヘルプ情報を表示するには、 `tiup br restore point --help`実行します。 +ヘルプ情報を表示するには、 `tiup br restore point --help`を実行します。 ```shell tiup br restore point --help @@ -448,7 +448,7 @@ Global Flags: - `--restored-ts` : データを復元するタイムスタンプ。このパラメータが指定されていない場合、 BRはログバックアップで利用可能な最新のタイムスタンプ、つまりバックアップデータのチェックポイントにデータを復元します。 - `--start-ts` : ログバックアップデータを復元する開始タイムスタンプ。ログバックアップデータのみを復元する必要がある場合は、このパラメータを指定する必要があります。 - `--pd` : 復元クラスターの PD アドレス。 -- `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。 +- `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`を指定します。 - `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 使用例: diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md index 07253fa19c383..f799bf3234ce8 100644 --- a/br/br-snapshot-guide.md +++ b/br/br-snapshot-guide.md @@ -67,7 +67,7 @@ tiup br validate decode --field="end-version" \ > **注記：** > > - BR v7.5.0以前のバージョンでは、TiKVノードあたりのスナップショット復元速度は約100 MiB/秒です。 -> - BR v7.6.0以降、大規模なリージョンを含むシナリオにおける潜在的なリストアのボトルネックに対処するため、 BRは粗粒度リージョン散乱アルゴリズム（実験的）によるリストアの高速化をサポートしています。この機能は、コマンドラインパラメータ`--granularity="coarse-grained"`指定することで有効にできます。 +> - BR v7.6.0以降、大規模なリージョンを含むシナリオにおける潜在的なリストアのボトルネックに対処するため、 BRは粗粒度リージョン散乱アルゴリズム（実験的）によるリストアの高速化をサポートしています。この機能は、コマンドラインパラメータ`--granularity="coarse-grained"`を指定することで有効にできます。 > - BR v8.0.0以降、粗粒度リージョン分散アルゴリズムによるスナップショット復元が一般提供（GA）となり、デフォルトで有効になっています。BRは、粗粒度リージョン分散アルゴリズムの採用、データベースとテーブルのバッチ作成、SSTファイルダウンロードと取り込み操作間の相互影響の低減、テーブル統計情報の復元の高速化など、さまざまな最適化を実装することで、スナップショット復元の速度を大幅に向上させています。実際のケースのテスト結果によると、スナップショット復元用のSSTファイルダウンロード速度は最大で約10倍向上し、TiKVノードあたりのデータ復元速度は1.2 GiB/sで安定し、エンドツーエンドの復元速度は約1.5～3倍向上し、100 TiBのデータを1時間以内に復元できます。 > - BR v8.2.0以降、コマンドラインパラメータ`--granularity`は非推奨となり、粗粒度リージョン散乱アルゴリズムがデフォルトで有効になっています。 > - BR v8.3.0 以降では、スナップショット復元タスクで TiKV とTiFlashのディスク空き容量チェックが導入されました。タスクの開始時に、 BR は復元対象の SST ファイルのサイズに基づいて TiKV とTiFlash に十分なディスク空き容量があるかどうかを確認します。TiKV v8.3.0 以降のバージョンでは、TiKV は各 SST ファイルをダウンロードする前に十分なディスク空き容量があるかどうかを確認します。これらのチェックのいずれかで空き容量が不足している場合、復元タスクはエラーで失敗します。 `--check-requirements=false`を設定することで、復元タスクの開始時のチェックをスキップできますが、TiKV が各 SST ファイルをダウンロードする前のディスク空き容量チェックはスキップできません。 diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md index 581210cb32cd6..b0cead611564c 100644 --- a/br/br-snapshot-manual.md +++ b/br/br-snapshot-manual.md @@ -110,7 +110,7 @@ tiup br backup full \ TiDB v7.5.0以降、 `br`コマンドラインツールに`--ignore-stats`パラメータが導入されました。このパラメータを`false`に設定すると、 `br`コマンドラインツールは列、インデックス、およびテーブルの統計情報のバックアップをサポートします。この場合、バックアップから復元されたTiDBデータベースの統計情報収集タスクを手動で実行したり、自動収集タスクの完了を待ったりする必要はありません。この機能により、データベースのメンテナンス作業が簡素化され、クエリパフォーマンスが向上します。 -このパラメータを`false`に設定しない場合、 `br`コマンドライン ツールはデフォルト設定の`--ignore-stats=true`使用します。つまり、データのバックアップ中に統計はバックアップされません。 +このパラメータを`false`に設定しない場合、 `br`コマンドライン ツールはデフォルト設定の`--ignore-stats=true`を使用します。つまり、データのバックアップ中に統計はバックアップされません。 以下は、クラスター スナップショット データをバックアップし、テーブル統計を`--ignore-stats=false`でバックアップする例です。 @@ -212,7 +212,7 @@ tiup br restore full \ ## データベースまたはテーブルを復元する {#restore-a-database-or-a-table} -`br`使用すると、バックアップデータから指定したデータベースまたはテーブルの部分的なデータを復元できます。この機能により、復元中に不要なデータを除外できます。 +`br`を使用すると、バックアップデータから指定したデータベースまたはテーブルの部分的なデータを復元できます。この機能により、復元中に不要なデータを除外できます。 ### データベースを復元する {#restore-a-database} diff --git a/br/br-use-overview.md b/br/br-use-overview.md index 62cf198bc1524..d5e1337cc10bc 100644 --- a/br/br-use-overview.md +++ b/br/br-use-overview.md @@ -57,7 +57,7 @@ TiDB クラスターを独自に構築したデータ センターに導入す ### データを復元するにはどうすればいいですか? {#how-to-restore-data} -- 完全バックアップ データのみを復元するには、 `tiup br restore`使用して、指定したバックアップの完全復元を実行できます。 +- 完全バックアップ データのみを復元するには、 `tiup br restore`を使用して、指定したバックアップの完全復元を実行できます。 - ログ バックアップを開始し、定期的に完全バックアップを実行している場合は、 `tiup br restore point`コマンドを実行して、バックアップ保持期間内の任意の時点にデータを復元できます。 ## BRをデプロイて使用する {#deploy-and-use-br} diff --git a/cached-tables.md b/cached-tables.md index a90b2d8264389..8d9def88a6845 100644 --- a/cached-tables.md +++ b/cached-tables.md @@ -201,7 +201,7 @@ mysql> ALTER TABLE users ADD INDEX k_id(id); ERROR 8242 (HY000): 'Alter Table' is unsupported on cache tables. ``` -キャッシュされたテーブルを通常のテーブルに戻すには、 `ALTER TABLE t NOCACHE`使用します。 +キャッシュされたテーブルを通常のテーブルに戻すには、 `ALTER TABLE t NOCACHE`を使用します。 ```sql ALTER TABLE users NOCACHE; @@ -236,7 +236,7 @@ Query OK, 0 rows affected (0.00 sec) キャッシュテーブルは、MySQL構文に対するTiDBの拡張です。1 `ALTER TABLE ... CACHE`を認識できるのはTiDBのみです。TiDB移行ツール（Backup & Restore (BR)、TiCDC、 Dumplingなど）は、キャッシュテーブルをサポートし**ていません**。これらのツールは、キャッシュテーブルを通常のテーブルとして扱います。 -つまり、キャッシュテーブルはバックアップとリストアが行われると、通常のテーブルになります。下流クラスターが別のTiDBクラスターであり、キャッシュテーブル機能を引き続き使用したい場合は、下流クラスターで`ALTER TABLE ... CACHE`実行することで、キャッシュテーブルを手動で有効化できます。 +つまり、キャッシュテーブルはバックアップとリストアが行われると、通常のテーブルになります。下流クラスターが別のTiDBクラスターであり、キャッシュテーブル機能を引き続き使用したい場合は、下流クラスターで`ALTER TABLE ... CACHE`を実行することで、キャッシュテーブルを手動で有効化できます。 ## 参照 {#see-also} diff --git a/character-set-and-collation.md b/character-set-and-collation.md index 41d3961c86dc6..c61ca53852bb8 100644 --- a/character-set-and-collation.md +++ b/character-set-and-collation.md @@ -146,8 +146,8 @@ SHOW COLLATION; > > ただし、TiDB のデフォルトの照合順序は、クライアントの[接続照合順序](https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html#charset-connection-system-variables)設定にも影響されます。例えば、MySQL 8.x クライアントでは、 `utf8mb4`文字セットの接続照合順序はデフォルトで`utf8mb4_0900_ai_ci`に設定されています。 > -> - TiDB v7.4.0 より前では、クライアントが`utf8mb4_0900_ai_ci` [接続照合順序](https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html#charset-connection-system-variables)として使用すると、TiDB は`utf8mb4_0900_ai_ci`照合順序をサポートしていないため、TiDB は TiDBサーバーのデフォルトの照合照合順序`utf8mb4_bin`使用します。 -> - v7.4.0 以降、クライアントが[接続照合順序](https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html#charset-connection-system-variables)として`utf8mb4_0900_ai_ci`使用する場合、TiDB はクライアントの構成に従って、デフォルトの照合順序として`utf8mb4_0900_ai_ci`使用します。 +> - TiDB v7.4.0 より前では、クライアントが`utf8mb4_0900_ai_ci` [接続照合順序](https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html#charset-connection-system-variables)として使用すると、TiDB は`utf8mb4_0900_ai_ci`照合順序をサポートしていないため、TiDB は TiDBサーバーのデフォルトの照合照合順序`utf8mb4_bin`を使用します。 +> - v7.4.0 以降、クライアントが[接続照合順序](https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html#charset-connection-system-variables)として`utf8mb4_0900_ai_ci`を使用する場合、TiDB はクライアントの構成に従って、デフォルトの照合順序として`utf8mb4_0900_ai_ci`を使用します。 次のステートメントを使用すると、文字セットに対応する照合順序 ( [照合のための新しいフレームワーク](#new-framework-for-collations)下) を表示できます。 @@ -176,7 +176,7 @@ MySQLでは、文字セット`utf8`最大3バイトに制限されています MySQL と TiDB の両方で、 `utf8`と`utf8mb3`同じ文字セットのエイリアスです。 -TiDBはデフォルトで、文字セット`utf8`を最大3バイトに制限しています。これは、TiDBで作成されたデータがMySQLで安全に復元できることを保証するためです。システム変数[`tidb_check_mb4_value_in_utf8`](/system-variables.md#tidb_check_mb4_value_in_utf8)の値を`OFF`に変更することで、この制限を無効にすることができます。ただし、完全なUnicodeサポートと高い互換性のためには、代わりに`utf8mb4`使用することをお勧めします。 +TiDBはデフォルトで、文字セット`utf8`を最大3バイトに制限しています。これは、TiDBで作成されたデータがMySQLで安全に復元できることを保証するためです。システム変数[`tidb_check_mb4_value_in_utf8`](/system-variables.md#tidb_check_mb4_value_in_utf8)の値を`OFF`に変更することで、この制限を無効にすることができます。ただし、完全なUnicodeサポートと高い互換性のためには、代わりに`utf8mb4`を使用することをお勧めします。 以下は、4バイトの絵文字をテーブルに挿入する際のデフォルトの動作を示しています。1 `INSERT`文は`utf8`文字セットでは失敗しますが、 `utf8mb4`の文では成功します。 @@ -245,7 +245,7 @@ ALTER DATABASE db_name ここで`DATABASE` `SCHEMA`に置き換えることができます。 -データベースによって文字セットと照合順序が異なる場合があります。現在のデータベースの文字セットと照合順序を確認するには、 `character_set_database`と`collation_database`使用します。 +データベースによって文字セットと照合順序が異なる場合があります。現在のデータベースの文字セットと照合順序を確認するには、 `character_set_database`と`collation_database`を使用します。 ```sql CREATE SCHEMA test1 CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; @@ -372,9 +372,9 @@ SELECT _utf8mb4'string' COLLATE utf8mb4_general_ci; ルール: -- ルール 1: `CHARACTER SET charset_name`と`COLLATE collation_name`指定すると、 `charset_name`文字セットと`collation_name`照合順序が直接使用されます。 -- ルール 2: `CHARACTER SET charset_name`指定して`COLLATE collation_name`指定しない場合は、 `charset_name`文字セットとデフォルトの照合順序`charset_name`が使用されます。 -- ルール 3: `CHARACTER SET charset_name`も`COLLATE collation_name`指定しない場合は、システム変数`character_set_connection`と`collation_connection`で指定された文字セットと照合順序が使用されます。 +- ルール 1: `CHARACTER SET charset_name`と`COLLATE collation_name`を指定すると、 `charset_name`文字セットと`collation_name`照合順序が直接使用されます。 +- ルール 2: `CHARACTER SET charset_name`を指定して`COLLATE collation_name`を指定しない場合は、 `charset_name`文字セットとデフォルトの照合順序`charset_name`が使用されます。 +- ルール 3: `CHARACTER SET charset_name`も`COLLATE collation_name`を指定しない場合は、システム変数`character_set_connection`と`collation_connection`で指定された文字セットと照合順序が使用されます。 ### クライアント接続の文字セットと照合順序 {#client-connection-character-set-and-collation} @@ -419,15 +419,15 @@ SELECT _utf8mb4'string' COLLATE utf8mb4_general_ci; ## 文字セットと照合順序の選択に関する一般的なルール {#general-rules-on-selecting-character-sets-and-collation} -- ルール 1: `CHARACTER SET charset_name`と`COLLATE collation_name`指定すると、 `charset_name`文字セットと`collation_name`照合順序が直接使用されます。 -- ルール 2: `CHARACTER SET charset_name`指定し、 `COLLATE collation_name`指定しない場合は、 `charset_name`文字セットとデフォルトの照合順序`charset_name`が使用されます。 +- ルール 1: `CHARACTER SET charset_name`と`COLLATE collation_name`を指定すると、 `charset_name`文字セットと`collation_name`照合順序が直接使用されます。 +- ルール 2: `CHARACTER SET charset_name`指定し、 `COLLATE collation_name`を指定しない場合は、 `charset_name`文字セットとデフォルトの照合順序`charset_name`が使用されます。 - ルール 3: `CHARACTER SET charset_name`も`COLLATE collation_name`も指定しない場合は、最適化レベルが高い文字セットと照合順序が使用されます。 ## 文字の有効性チェック {#validity-check-of-characters} 指定された文字セットが`utf8`または`utf8mb4`場合、TiDB は有効な`utf8`文字のみをサポートします。無効な文字の場合、TiDB は`incorrect utf8 value`エラーを報告します。TiDB のこの文字の有効性チェックは MySQL 8.0 と互換性がありますが、 MySQL 5.7以前のバージョンとは互換性がありません。 -このエラー報告を無効にするには、 `set @@tidb_skip_utf8_check=1;`使用して文字チェックをスキップします。 +このエラー報告を無効にするには、 `set @@tidb_skip_utf8_check=1;`を使用して文字チェックをスキップします。 > **注記：** > diff --git a/check-before-deployment.md b/check-before-deployment.md index fe28a9b0187d1..f446d1883318a 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -285,7 +285,7 @@ NTP サービスがインストールされ、NTPサーバーと正常に同期 Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled; vendor preset: disabled) Active: active (running) since 一 2017-12-18 13:13:19 CST; 3s ago - - `Unit ntpd.service could not be found.`返された場合は、次のコマンドを試して、システムが NTP とのクロック同期を実行するために`ntpd`ではなく`chronyd`使用するように設定されているかどうかを確認します。 + - `Unit ntpd.service could not be found.`返された場合は、次のコマンドを試して、システムが NTP とのクロック同期を実行するために`ntpd`ではなく`chronyd`を使用するように設定されているかどうかを確認します。 ```bash sudo systemctl status chronyd.service @@ -297,7 +297,7 @@ NTP サービスがインストールされ、NTPサーバーと正常に同期 結果に`chronyd`と`ntpd`どちらも設定されていないと表示された場合は、どちらもシステムにインストールされていないことを意味します。まず`chronyd`または`ntpd`をインストールし、自動起動できることを確認してください。デフォルトでは`ntpd`が使用されます。 - システムが`chronyd`使用するように構成されている場合は、手順 3 に進みます。 + システムが`chronyd`を使用するように構成されている場合は、手順 3 に進みます。 2. `ntpstat`コマンドを実行して、NTP サービスが NTPサーバーと同期しているかどうかを確認します。 @@ -357,7 +357,7 @@ NTP サービスがインストールされ、NTPサーバーと正常に同期 506 Cannot talk to daemon - - オフセットが大きすぎると思われる場合は、コマンド`chronyc makestep`を実行してすぐに時間オフセットを修正できます。そうでない場合は、 `chronyd`実行して徐々に時間オフセットを修正します。 + - オフセットが大きすぎると思われる場合は、コマンド`chronyc makestep`を実行してすぐに時間オフセットを修正できます。そうでない場合は、 `chronyd`を実行して徐々に時間オフセットを修正します。 NTPサービスの同期をできるだけ早く開始するには、次のコマンドを実行してください。1 `pool.ntp.org` NTPサーバーに置き換えてください。 @@ -430,7 +430,7 @@ sudo systemctl enable ntpd.service > > `[none] mq-deadline kyber bfq` 、NVMe デバイスが`none` I/Oスケジューラを使用しており、変更の必要がないことを示します。 -3. ディスクの`ID_SERIAL`確認するには、次のコマンドを実行します。 +3. ディスクの`ID_SERIAL`を確認するには、次のコマンドを実行します。 ```bash udevadm info --name=/dev/sdb | grep ID_SERIAL @@ -441,7 +441,7 @@ sudo systemctl enable ntpd.service > **注記：** > - > - 複数のディスクにデータ ディレクトリが割り当てられている場合は、各ディスクの`ID_SERIAL`記録するために、各ディスクに対して上記のコマンドを実行する必要があります。 + > - 複数のディスクにデータ ディレクトリが割り当てられている場合は、各ディスクの`ID_SERIAL`を記録するために、各ディスクに対して上記のコマンドを実行する必要があります。 > - デバイスが`noop`または`none`スケジューラを使用している場合は、 `ID_SERIAL`を記録したり、udev ルールや調整されたプロファイルを構成したりする必要はありません。 4. cpufreq モジュールの電源ポリシーを確認するには、次のコマンドを実行します。 @@ -521,7 +521,7 @@ sudo systemctl enable ntpd.service > **注記：** > - > `grubby`実行する前に、まず`grubby`パッケージをインストールします。 + > `grubby`を実行する前に、まず`grubby`パッケージをインストールします。 ```bash grubby --default-kernel @@ -531,7 +531,7 @@ sudo systemctl enable ntpd.service /boot/vmlinuz-3.10.0-957.el7.x86_64 ``` - 2. カーネル構成を変更するには、 `grubby --update-kernel`実行します。 + 2. カーネル構成を変更するには、 `grubby --update-kernel`を実行します。 ```bash grubby --args="transparent_hugepage=never" --update-kernel `grubby --default-kernel` @@ -541,7 +541,7 @@ sudo systemctl enable ntpd.service > > `--update-kernel`後に実際のバージョン番号（ `--update-kernel /boot/vmlinuz-3.10.0-957.el7.x86_64`や`ALL` ）を指定することもできます。 - 3. 変更されたデフォルトのカーネル構成を確認するには、 `grubby --info`実行します。 + 3. 変更されたデフォルトのカーネル構成を確認するには、 `grubby --info`を実行します。 ```bash grubby --info /boot/vmlinuz-3.10.0-957.el7.x86_64 @@ -703,7 +703,7 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t ssh-copy-id -i ~/.ssh/id_rsa.pub 10.0.1.1 ``` -4. `tidb`ユーザーアカウントを使用してコントロールマシンにログインし、 `ssh`使用してターゲットマシンの IP アドレスにログインします。パスワードを入力する必要がなく、正常にログインできれば、SSH 相互信頼が正常に設定されています。 +4. `tidb`ユーザーアカウントを使用してコントロールマシンにログインし、 `ssh`を使用してターゲットマシンの IP アドレスにログインします。パスワードを入力する必要がなく、正常にログインできれば、SSH 相互信頼が正常に設定されています。 ```bash ssh 10.0.1.1 diff --git a/clinic/clinic-user-guide-for-tiup.md b/clinic/clinic-user-guide-for-tiup.md index 6d21af324bb2e..139dbc77f18c6 100644 --- a/clinic/clinic-user-guide-for-tiup.md +++ b/clinic/clinic-user-guide-for-tiup.md @@ -162,7 +162,7 @@ Diag を使用すると、 TiUPを使用して展開された TiDB クラスタ パラメータの使用に関するヒント: - Diag では、データ収集時間の指定に加えて、より多くのパラメータを指定できます。すべてのパラメータを取得するには、コマンド`tiup diag collect -h`または`tiup diag collectdm -h`実行します。 + Diag では、データ収集時間の指定に加えて、より多くのパラメータを指定できます。すべてのパラメータを取得するには、コマンド`tiup diag collect -h`または`tiup diag collectdm -h`を実行します。 > **注記：** > diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index 280dd40e95dff..1f30e998895c9 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -31,7 +31,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## `--cors` {#cors} -- TiDB HTTPステータスサービスのクロスオリジンリクエスト共有（CORS）リクエストの値`Access-Control-Allow-Origin`指定します。 +- TiDB HTTPステータスサービスのクロスオリジンリクエスト共有（CORS）リクエストの値`Access-Control-Allow-Origin`を指定します。 - デフォルト: `""` ## `--host` {#host} @@ -48,7 +48,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## `--initialize-secure` {#initialize-secure} -- tidb-server の初期化時に、認証方式`auth_socket`使用してアカウント`root`を作成するかどうかを制御します。 `true`に設定した場合、TiDB への初回ログインにはソケット接続を使用する必要があります。これにより、セキュリティが強化されます。 +- tidb-server の初期化時に、認証方式`auth_socket`を使用してアカウント`root`を作成するかどうかを制御します。 `true`に設定した場合、TiDB への初回ログインにはソケット接続を使用する必要があります。これにより、セキュリティが強化されます。 - デフォルト: `false` ## `--initialize-sql-file` {#initialize-sql-file} @@ -110,7 +110,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション - `--store = tikv`場合、パスを指定する必要があります。 `--store = unistore`場合、パスを指定しないとデフォルト値が使用されます。 - TiKVのような分散ストレージエンジンの場合、 `--path`実際のPDアドレスを指定します。PDサーバーを192.168.100.113:2379、192.168.100.114:2379、192.168.100.115:2379にデプロイすると仮定すると、 `--path`値は「192.168.100.113:2379、192.168.100.114:2379、192.168.100.115:2379」となります。 - デフォルト: `"/tmp/tidb"` -- 純粋なインメモリ TiDB を有効にするには、 `tidb-server --store=unistore --path=""`使用します。 +- 純粋なインメモリ TiDB を有効にするには、 `tidb-server --store=unistore --path=""`を使用します。 ## `--proxy-protocol-fallbackable` {#proxy-protocol-fallbackable} @@ -122,11 +122,11 @@ TiDBクラスタを起動する際には、コマンドラインオプション - [PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)使用して TiDB に接続できるプロキシ サーバーの IP アドレスのリスト。 - デフォルト: `""` - 通常、リバースプロキシを経由してTiDBにアクセスする場合、TiDBはリバースプロキシサーバーのIPアドレスをクライアントのIPアドレスとして取得します。PROXYプロトコルを有効にすると、HAProxyなどのこのプロトコルをサポートするリバースプロキシは、実際のクライアントIPアドレスをTiDBに渡すことができます。 -- このフラグを設定すると、TiDBは設定された送信元IPアドレスがPROXYプロトコルを使用してTiDBに接続することを許可します。PROXY以外のプロトコルが使用されている場合、この接続は拒否されます。その他のアドレスはPROXYプロトコルを使用せずにTiDBに接続できます。このフラグを空のままにすると、どのIPアドレスもPROXYプロトコルを使用してTiDBに接続できなくなります。値は、IPアドレス（192.168.1.50）またはCIDR（192.168.1.0/24）で、区切り文字として`,`使用します。3 `*`任意のIPアドレスを意味します。 +- このフラグを設定すると、TiDBは設定された送信元IPアドレスがPROXYプロトコルを使用してTiDBに接続することを許可します。PROXY以外のプロトコルが使用されている場合、この接続は拒否されます。その他のアドレスはPROXYプロトコルを使用せずにTiDBに接続できます。このフラグを空のままにすると、どのIPアドレスもPROXYプロトコルを使用してTiDBに接続できなくなります。値は、IPアドレス（192.168.1.50）またはCIDR（192.168.1.0/24）で、区切り文字として`,`を使用します。3 `*`任意のIPアドレスを意味します。 > **警告：** > -> `*` 、任意の IP アドレスのクライアントが自身の IP アドレスを報告できるようになるため、セキュリティリスクが生じる可能性があるため、注意して使用してください。また、 `*`使用すると、 `--proxy-protocol-fallbackable` `true`に設定しないと、TiDB に直接接続する内部コンポーネント（TiDB Dashboardなど）が利用できなくなる可能性があります。 +> `*` 、任意の IP アドレスのクライアントが自身の IP アドレスを報告できるようになるため、セキュリティリスクが生じる可能性があるため、注意して使用してください。また、 `*`を使用すると、 `--proxy-protocol-fallbackable` `true`に設定しないと、TiDB に直接接続する内部コンポーネント（TiDB Dashboardなど）が利用できなくなる可能性があります。 > **注記：** > @@ -161,7 +161,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション - TiDB サービスは、外部接続に Unix ソケット ファイルを使用します。 - デフォルト: `""` -- `/tmp/tidb.sock`使用して Unix ソケット ファイルを開きます。 +- `/tmp/tidb.sock`を使用して Unix ソケット ファイルを開きます。 ## `--status` {#status} @@ -220,9 +220,9 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## `--redact` {#redact} -- サブコマンド`collect-log`使用するときに、 TiDBサーバーがログ ファイルを非感度化するかどうかを決定します。 +- サブコマンド`collect-log`を使用するときに、 TiDBサーバーがログ ファイルを非感度化するかどうかを決定します。 - デフォルト: false -- 値が`true`の場合、マスキング操作となり、 `‹ ›`マーク記号で囲まれたすべてのフィールドが`?`に置き換えられます。値が`false`の場合、リストア操作となり、すべてのマーク記号が削除されます。この機能を使用するには、 `./tidb-server --redact=xxx collect-log `実行して、 ``で指定された TiDBサーバーログファイルを非感応化またはリストアし、 ``に出力します。詳細については、システム変数[`tidb_redact_log`](/system-variables.md#tidb_redact_log)参照してください。 +- 値が`true`の場合、マスキング操作となり、 `‹ ›`マーク記号で囲まれたすべてのフィールドが`?`に置き換えられます。値が`false`の場合、リストア操作となり、すべてのマーク記号が削除されます。この機能を使用するには、 `./tidb-server --redact=xxx collect-log `を実行して、 ``で指定された TiDBサーバーログファイルを非感応化またはリストアし、 ``に出力します。詳細については、システム変数[`tidb_redact_log`](/system-variables.md#tidb_redact_log)参照してください。 ## `--repair-mode` {#repair-mode} diff --git a/command-line-flags-for-tikv-configuration.md b/command-line-flags-for-tikv-configuration.md index ee00768b3a89d..d90321ec732aa 100644 --- a/command-line-flags-for-tikv-configuration.md +++ b/command-line-flags-for-tikv-configuration.md @@ -95,4 +95,4 @@ TiKV は、コマンドラインパラメータに対していくつかの読み - PDサーバーのアドレスリスト - デフォルト: `""` -- TiKVを動作させるには、TiKVサーバーをPDサーバーに接続する際に値`--pd`使用する必要があります。複数のPDアドレスはカンマで区切ってください（例：192.168.100.113:2379, 192.168.100.114:2379, 192.168.100.115:2379）。 +- TiKVを動作させるには、TiKVサーバーをPDサーバーに接続する際に値`--pd`を使用する必要があります。複数のPDアドレスはカンマで区切ってください（例：192.168.100.113:2379, 192.168.100.114:2379, 192.168.100.115:2379）。 diff --git a/comment-syntax.md b/comment-syntax.md index acaf71da718be..9b46baedde4aa 100644 --- a/comment-syntax.md +++ b/comment-syntax.md @@ -9,7 +9,7 @@ summary: このドキュメントでは、TiDB でサポートされているコ TiDB は次の 3 つのコメント スタイルをサポートしています。 -- 行をコメント化するには`#`使用します。 +- 行をコメント化するには`#`を使用します。 ```sql SELECT 1+1; # comments @@ -22,7 +22,7 @@ TiDB は次の 3 つのコメント スタイルをサポートしています +------+ 1 row in set (0.00 sec) -- 行をコメント化するには`--`使用します。 +- 行をコメント化するには`--`を使用します。 ```sql SELECT 1+1; -- comments @@ -48,7 +48,7 @@ TiDB は次の 3 つのコメント スタイルをサポートしています +--------+ 1 row in set (0.01 sec) -- ブロックまたは複数行をコメント化するには`/* */`使用します。 +- ブロックまたは複数行をコメント化するには`/* */`を使用します。 ```sql SELECT 1 /* this is an in-line comment */ + 1; @@ -123,6 +123,6 @@ TiDB がサポートするオプティマイザヒントの詳細については > **注記：** > -> MySQLクライアントでは、TiDB固有のコメント構文はコメントとして扱われ、デフォルトでクリアされます。5.7.7より前のMySQLクライアントでは、ヒントもコメントとして扱われ、デフォルトでクリアされます。クライアント起動時には、 `--comments`オプションを使用することをお勧めします。例えば、 `mysql -h 127.0.0.1 -P 4000 -uroot --comments`指定します。 +> MySQLクライアントでは、TiDB固有のコメント構文はコメントとして扱われ、デフォルトでクリアされます。5.7.7より前のMySQLクライアントでは、ヒントもコメントとして扱われ、デフォルトでクリアされます。クライアント起動時には、 `--comments`オプションを使用することをお勧めします。例えば、 `mysql -h 127.0.0.1 -P 4000 -uroot --comments`を指定します。 詳細については[コメント構文](https://dev.mysql.com/doc/refman/8.0/en/comments.html)参照してください。 diff --git a/configure-memory-usage.md b/configure-memory-usage.md index 03728301f06e5..eabb98f1743ce 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -102,7 +102,7 @@ tidb-server インスタンスのメモリ使用量がメモリしきい値 (デ 2. `CREATE TABLE t(a int);`を実行し、1000 行のデータを挿入します。 -3. `select * from t t1 join t t2 join t t3 order by t1.a`実行します。この SQL 文は 10 億件のレコードを出力し、大量のメモリを消費するため、アラームがトリガーされます。 +3. `select * from t t1 join t t2 join t t3 order by t1.a`を実行します。この SQL 文は 10 億件のレコードを出力し、大量のメモリを消費するため、アラームがトリガーされます。 4. システムメモリの合計、現在のシステムメモリ使用量、tidb-server インスタンスのメモリ使用量、およびステータス ファイルのディレクトリを記録する`tidb.log`ファイルを確認します。 diff --git a/configure-placement-rules.md b/configure-placement-rules.md index 29f8c1dada2f8..1bf4537a87c7e 100644 --- a/configure-placement-rules.md +++ b/configure-placement-rules.md @@ -223,7 +223,7 @@ Success! ルール グループとグループ内のすべてのルールを同時に表示および変更するには、サブコマンド`rule-bundle`を実行します。 -このサブコマンドでは、 `get {group_id}`使用してグループを照会し、出力結果にはルール グループとグループのルールがネストされた形式で表示されます。 +このサブコマンドでは、 `get {group_id}`を使用してグループを照会し、出力結果にはルール グループとグループのルールがネストされた形式で表示されます。 ```bash pd-ctl config placement-rules rule-bundle get pd @@ -371,7 +371,7 @@ table ttt ranges: (NOTE: key range might be changed after DDL) ### シナリオ3: テーブルに2つのTiFlashレプリカを追加する {#scenario-3-add-two-tiflash-replicas-for-a-table} -テーブルの行キーに別のルールを追加し、 `count`から`2`の範囲で制限します。 `label_constraints`使用することで、レプリカが`engine = tiflash`のノードに生成されるようにします。ここで別途`group_id`使用するのは、このルールがシステム内の他のソースのルールと重複したり衝突したりしないようにするためです。 +テーブルの行キーに別のルールを追加し、 `count`から`2`の範囲で制限します。 `label_constraints`を使用することで、レプリカが`engine = tiflash`のノードに生成されるようにします。ここで別途`group_id`を使用するのは、このルールがシステム内の他のソースのルールと重複したり衝突したりしないようにするためです。 ```json { diff --git a/configure-time-zone.md b/configure-time-zone.md index 57200e87af981..87b2d2c5b482f 100644 --- a/configure-time-zone.md +++ b/configure-time-zone.md @@ -9,7 +9,7 @@ TiDBのタイムゾーンは、システム変数[`time_zone`](/system-variables 1. TiDB は`TZ`環境変数の使用を優先します。 2. `TZ`環境変数が失敗した場合、TiDB は`/etc/localtime`ソフト リンクからタイム ゾーンを読み取ります。 -3. 上記の両方の方法が失敗した場合、TiDB はシステムタイムゾーンとして`UTC`使用します。 +3. 上記の両方の方法が失敗した場合、TiDB はシステムタイムゾーンとして`UTC`を使用します。 ## タイムゾーン設定を表示する {#view-time-zone-settings} diff --git a/constraints.md b/constraints.md index 51c8b5502c69f..d09b9304ce1c6 100644 --- a/constraints.md +++ b/constraints.md @@ -117,10 +117,10 @@ ALTER TABLE t DROP CONSTRAINT t_chk_1; テーブルに[`CHECK`制約を追加する](#add-check-constraints)設定すると、データの挿入または更新時に TiDB が制約チェックを実装する必要があるかどうかを指定できます。 -- `NOT ENFORCED`指定すると、TiDB はデータの挿入または更新時に制約条件をチェックしません。 +- `NOT ENFORCED`を指定すると、TiDB はデータの挿入または更新時に制約条件をチェックしません。 - `NOT ENFORCED`指定されていないか`ENFORCED`指定されている場合、TiDB はデータの挿入または更新中に制約条件をチェックします。 -制約を追加するときに`[NOT] ENFORCED`指定するだけでなく、 `ALTER TABLE`ステートメントを使用して`CHECK`制約を有効または無効にすることもできます。例： +制約を追加するときに`[NOT] ENFORCED`を指定するだけでなく、 `ALTER TABLE`ステートメントを使用して`CHECK`制約を有効または無効にすることもできます。例： ```sql ALTER TABLE t ALTER CONSTRAINT c1 NOT ENFORCED; @@ -129,7 +129,7 @@ ALTER TABLE t ALTER CONSTRAINT c1 NOT ENFORCED; ### MySQLの互換性 {#mysql-compatibility} - 列（例： `ALTER TABLE t ADD COLUMN a CHECK(a > 0)` ）の追加時に`CHECK`制約を追加することはサポートされていません。この場合、列のみが正常に追加され、TiDBは`CHECK`制約を無視し、エラーを報告しません。 -- `ALTER TABLE t CHANGE a b int CHECK(b > 0)`使用して`CHECK`制約を追加することはサポートされていません。この文を実行すると、TiDBはエラーを報告します。 +- `ALTER TABLE t CHANGE a b int CHECK(b > 0)`を使用して`CHECK`制約を追加することはサポートされていません。この文を実行すると、TiDBはエラーを報告します。 ## 一意キー {#unique-key} diff --git a/coprocessor-cache.md b/coprocessor-cache.md index b2b589441c767..f4ae8fa7ec96c 100644 --- a/coprocessor-cache.md +++ b/coprocessor-cache.md @@ -50,7 +50,7 @@ v4.0 以降、TiDB インスタンスは TiKV (コプロセッサーキャッシ ## キャッシュ効果を確認する {#check-the-cache-effect} -`EXPLAIN ANALYZE`実行するか、Grafana 監視パネルを表示することで、コプロセッサーのキャッシュ効果を確認できます。 +`EXPLAIN ANALYZE`を実行するか、Grafana 監視パネルを表示することで、コプロセッサーのキャッシュ効果を確認できます。 ### EXPLAIN ANALYZE使用する {#use-code-explain-analyze-code} diff --git a/dashboard/dashboard-diagnostics-report.md b/dashboard/dashboard-diagnostics-report.md index bffbb0467c20d..ca868cdc0d331 100644 --- a/dashboard/dashboard-diagnostics-report.md +++ b/dashboard/dashboard-diagnostics-report.md @@ -208,7 +208,7 @@ TiDBには自動診断結果が組み込まれています。各フィールド #### 各コンポーネントでエラーが発生しました {#errors-occurred-in-each-component} -表`Errors Occurred in Each Component`は、TiDBとTiKVにおけるエラーの総数を示しています。binlogへのbinlog失敗、 `tikv server is busy`などです。各エラーの具体的な意味については`TiKV channel full`行のコメント`tikv write stall`参照してください。 +表`Errors Occurred in Each Component`は、TiDBとTiKVにおけるエラーの総数を示しています。binlogへのbinlog失敗、 `tikv server is busy`などです。各エラーの具体的な意味については`TiKV channel full`行のコメント`tikv write stall`を参照してください。 ![Errors Occurred in Each Component report](/media/dashboard/dashboard-diagnostics-error.png) @@ -363,6 +363,6 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり - `Table` : この監視メトリックが比較レポート内のどのテーブルから取得されるかを示します。たとえば、 `TiKV, coprocessor_info` TiKVコンポーネントの`coprocessor_info`のテーブルを示します。 - `METRIC_NAME` : 監視メトリック名。2 `expand`クリックすると、メトリックの異なるラベルの比較が表示されます。 - `LABEL` : 監視メトリックに対応するラベル。例えば、監視メトリック`TiKV Coprocessor scan`には、TiKVアドレス、リクエストタイプ、操作タイプ、操作カラムファミリーを表す2つのラベル（ `instance` 、 `req` 、 `tag` 、 `sql_type` ）があります。 -- `MAX_DIFF` : `t1.VALUE`と`t2.VALUE`の`DIFF_RATIO`計算した結果の差の値。 +- `MAX_DIFF` : `t1.VALUE`と`t2.VALUE`の`DIFF_RATIO`を計算した結果の差の値。 上記の表から、 `t2`時間範囲では`t1`時間範囲よりもコプロセッサー要求がはるかに多く、 `t2`の TiDB の SQL 解析時間が大幅に長くなっていることがわかります。 diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md index d208ab115d40a..ed414ae0736ca 100644 --- a/data-type-date-and-time.md +++ b/data-type-date-and-time.md @@ -125,7 +125,7 @@ TIMESTAMP[(fsp)] #### タイムゾーンの処理 {#timezone-handling} -`TIMESTAMP`保存する場合、TiDB は`TIMESTAMP`値を現在のタイムゾーンから UTC タイムゾーンに変換します。5 `TIMESTAMP`取得する場合、TiDB は保存されている`TIMESTAMP`値を UTC タイムゾーンから現在のタイムゾーンに変換します（注: `DATETIME`この方法では処理されません）。各接続のデフォルトのタイムゾーンはサーバーのローカルタイムゾーンですが、環境変数`time_zone`で変更できます。 +`TIMESTAMP`を保存する場合、TiDB は`TIMESTAMP`値を現在のタイムゾーンから UTC タイムゾーンに変換します。5 `TIMESTAMP`を取得する場合、TiDB は保存されている`TIMESTAMP`値を UTC タイムゾーンから現在のタイムゾーンに変換します（注: `DATETIME`この方法では処理されません）。各接続のデフォルトのタイムゾーンはサーバーのローカルタイムゾーンですが、環境変数`time_zone`で変更できます。 > **警告：** > @@ -177,7 +177,7 @@ CREATE TABLE t1 ( `DATETIME`と`TIMESTAMP`値は、マイクロ秒単位の精度で最大 6 桁の小数部を持つことができます`DATETIME`型または`TIMESTAMP`型の列では、小数部は破棄されずに保存されます。小数部がある場合、値は「YYYY-MM-DD HH:MM:SS[.fraction]」の形式で表され、小数部の範囲は 000000 から 999999 です。小数部と残りの部分を区切るために小数点を使用する必要があります。 -- 小数精度をサポートする列を定義するには`type_name(fsp)`使用します。3 `type_name` `TIME` 、 `DATETIME`または`TIMESTAMP`になります。例えば、 +- 小数精度をサポートする列を定義するには`type_name(fsp)`を使用します。3 `type_name` `TIME` 、 `DATETIME`または`TIMESTAMP`になります。例えば、 ```sql CREATE TABLE t1 (t TIME(3), dt DATETIME(6)); diff --git a/data-type-json.md b/data-type-json.md index f52fa47cb2dc4..49a2a9aadbc0b 100644 --- a/data-type-json.md +++ b/data-type-json.md @@ -83,9 +83,9 @@ JSONドキュメント内の値には型があります。これは[`JSON_TYPE` 詳細については、第[＃9999](https://github.com/pingcap/tidb/issues/9999)を参照してください。 -- TiDB では、 `ORDER BY`使用して JSON 配列または JSON オブジェクトをソートできます。 +- TiDB では、 `ORDER BY`を使用して JSON 配列または JSON オブジェクトをソートできます。 - MySQL では、 `ORDER BY`使用して JSON 配列または JSON オブジェクトをソートすると、MySQL から警告が返され、ソート結果が比較演算の結果と一致しなくなります。 + MySQL では、 `ORDER BY`を使用して JSON 配列または JSON オブジェクトをソートすると、MySQL から警告が返され、ソート結果が比較演算の結果と一致しなくなります。 ```sql CREATE TABLE t(j JSON); diff --git a/data-type-numeric.md b/data-type-numeric.md index d0b1367493d8c..d6c76627be4d5 100644 --- a/data-type-numeric.md +++ b/data-type-numeric.md @@ -136,7 +136,7 @@ TiDBは、 `FLOAT` 、 `DOUBLE`含むすべてのMySQL浮動小数点型をサ `FLOAT`型は単精度浮動小数点数を保存します。許容値は-3.402823466E+38～-1.175494351E-38、0、1.175494351E-38～3.402823466E+38です。これらはIEEE標準に基づく理論上の制限です。実際の範囲は、ハードウェアやオペレーティングシステムによって若干狭くなる場合があります。 -`FLOAT(p)`必要なビット精度を表すために使用できます。TiDB はこの値を使用して、結果のデータ型に`FLOAT`使用するか`DOUBLE`使用するかを決定します。p が 0 から 24 の場合、データ型は M 値または D 値を持たない FLOAT になります。p が 25 から 53 の場合、データ型は M 値または D 値を持たない`DOUBLE`になります。結果の列の範囲は、単精度`FLOAT`または倍精度`DOUBLE`データ型と同じです。 +`FLOAT(p)`必要なビット精度を表すために使用できます。TiDB はこの値を使用して、結果のデータ型に`FLOAT`を使用するか`DOUBLE`を使用するかを決定します。p が 0 から 24 の場合、データ型は M 値または D 値を持たない FLOAT になります。p が 25 から 53 の場合、データ型は M 値または D 値を持たない`DOUBLE`になります。結果の列の範囲は、単精度`FLOAT`または倍精度`DOUBLE`データ型と同じです。 ```sql FLOAT[(M,D)] [UNSIGNED] [ZEROFILL] diff --git a/data-type-overview.md b/data-type-overview.md index ff5bff57b9f32..a45005bd07a8d 100644 --- a/data-type-overview.md +++ b/data-type-overview.md @@ -29,4 +29,4 @@ TiDBは[文字列型](/data-type-string.md) MySQLの`SPATIAL`型を除くすべ - `D`浮動小数点型と固定小数点型に適用され、小数点以下の桁数 (スケール) を示します。 -- `fsp` `TIME` 、 `DATETIME` 、 `TIMESTAMP`型に適用され、小数秒の精度を表します。8 `fsp`指定する場合は、0から6の範囲でなければなりません。0 は小数部がないことを意味します。省略した場合、デフォルトの精度は0です。 +- `fsp` `TIME` 、 `DATETIME` 、 `TIMESTAMP`型に適用され、小数秒の精度を表します。8 `fsp`を指定する場合は、0から6の範囲でなければなりません。0 は小数部がないことを意味します。省略した場合、デフォルトの精度は0です。 diff --git a/data-type-string.md b/data-type-string.md index 05af978d4623b..4d240391c9e44 100644 --- a/data-type-string.md +++ b/data-type-string.md @@ -37,7 +37,7 @@ TiDBは、 `CHAR` 、 `VARCHAR` 、 `BINARY` 、 `VARBINARY` 、 `BLOB` 、 `TEX ### TEXTタイプ {#code-text-code-type} -`TEXT`は可変長の文字列です。列の最大長は65,535バイトです。オプションのM引数は文字数で、 `TEXT`列の最適な型を自動的に選択するために使用されます。例えば`TEXT(60)`指定すると、最大255バイトを保持できる`TINYTEXT`データ型が生成され、1文字あたり最大4バイト（4×60=240）の60文字のUTF-8文字列に適合します。M引数の使用は推奨されません。 +`TEXT`は可変長の文字列です。列の最大長は65,535バイトです。オプションのM引数は文字数で、 `TEXT`列の最適な型を自動的に選択するために使用されます。例えば`TEXT(60)`を指定すると、最大255バイトを保持できる`TINYTEXT`データ型が生成され、1文字あたり最大4バイト（4×60=240）の60文字のUTF-8文字列に適合します。M引数の使用は推奨されません。 ```sql TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] diff --git a/ddl_embedded_analyze.md b/ddl_embedded_analyze.md index 27fc9f4c6bbc9..b5c578cbb7251 100644 --- a/ddl_embedded_analyze.md +++ b/ddl_embedded_analyze.md @@ -39,7 +39,7 @@ EXPLAIN SELECT * FROM t WHERE a > 4; 前のプランでは、新しく作成されたインデックスにはまだ統計情報がないため、TiDB はパス推定にヒューリスティック ルールのみに頼ることができます。インデックス アクセス パスでテーブル検索が不要でコストが大幅に低い場合を除き、オプティマイザはより安定した既存のパスを選択する傾向があります。前の例では、フル テーブル スキャンが選択されています。ただし、データ分散の観点から見ると、 `t.a > 4`実際には 0 行を返します。新しいインデックス`idx_a`が使用された場合、クエリは関連する行をすばやく見つけて、フル テーブル スキャンを回避できます。この例では、DDL がインデックスを作成した後、統計がすぐに収集されないため、生成されたプランは最適ではありませんが、オプティマイザは元のプランを引き続き使用するため、クエリのパフォーマンスは大幅に低下しません。ただし、 [問題 #57948](https://github.com/pingcap/tidb/issues/57948)によると、場合によってはヒューリスティックによって古いインデックスと新しいインデックスが不当に比較され、元のプランが依存しているインデックスが削除され、最終的にフル テーブル スキャンにフォールバックすることがあります。 -v8.5.0以降、TiDBはインデックス間のヒューリスティック比較と、統計情報が欠落している場合の動作を改善しました。それでもなお、複雑なシナリオでは、DDLに`ANALYZE`を埋め込むことがプラン変更を防ぐ最善の方法です。システム変数[`tidb_stats_update_during_ddl`](/system-variables.md#tidb_stats_update_during_ddl-new-in-v854)を使用して、インデックス作成時または再編成時に埋め込み`ANALYZE`実行するかどうかを制御できます。デフォルト値は`OFF`です。 +v8.5.0以降、TiDBはインデックス間のヒューリスティック比較と、統計情報が欠落している場合の動作を改善しました。それでもなお、複雑なシナリオでは、DDLに`ANALYZE`を埋め込むことがプラン変更を防ぐ最善の方法です。システム変数[`tidb_stats_update_during_ddl`](/system-variables.md#tidb_stats_update_during_ddl-new-in-v854)を使用して、インデックス作成時または再編成時に埋め込み`ANALYZE`を実行するかどうかを制御できます。デフォルト値は`OFF`です。 ## `ADD INDEX` DDL {#add-index-ddl} diff --git a/develop/dev-guide-choose-driver-or-orm.md b/develop/dev-guide-choose-driver-or-orm.md index 849f0068982c2..e270a8ce6f4d2 100644 --- a/develop/dev-guide-choose-driver-or-orm.md +++ b/develop/dev-guide-choose-driver-or-orm.md @@ -131,7 +131,7 @@ implementation 'mysql:mysql-connector-java:8.0.33' > **注記：** > -> `Hibernate`バージョンをアップグレードできない場合は、代わりにMySQL 5.7方言`org.hibernate.dialect.MySQL57Dialect`使用してください。ただし、この設定では予期しない結果が生じる可能性があり、 [シーケンス](/sql-statements/sql-statement-create-sequence.md)などの TiDB 固有の機能が一部利用できなくなる可能性があります。 +> `Hibernate`バージョンをアップグレードできない場合は、代わりにMySQL 5.7方言`org.hibernate.dialect.MySQL57Dialect`を使用してください。ただし、この設定では予期しない結果が生じる可能性があり、 [シーケンス](/sql-statements/sql-statement-create-sequence.md)などの TiDB 固有の機能が一部利用できなくなる可能性があります。
diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index 3e4cf68bccf8d..afddb5af595b4 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -230,7 +230,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 #### バッチ関連パラメータ {#batch-related-parameters} -バッチ書き込みを処理する際は、 `rewriteBatchedStatements=true`設定することをお勧めします。3 または`executeBatch()` `addBatch()`使用した後でも、JDBC はデフォルトでは SQL を 1 つずつ送信します。例: +バッチ書き込みを処理する際は、 `rewriteBatchedStatements=true`設定することをお勧めします。3 または`executeBatch()` `addBatch()`を使用した後でも、JDBC はデフォルトでは SQL を 1 つずつ送信します。例: ```java pstmt = prepare("INSERT INTO `t` (a) values(?)"); diff --git a/develop/dev-guide-join-tables.md b/develop/dev-guide-join-tables.md index 11a2d98884efe..add1175ae86d3 100644 --- a/develop/dev-guide-join-tables.md +++ b/develop/dev-guide-join-tables.md @@ -149,7 +149,7 @@ DELETE FROM ratings WHERE book_id = 3438991610; +------------+---------------------------------+---------------+ 10 rows in set (0.30 sec) -`INNER JOIN`使用するとどうなるでしょうか？試してみるのはあなた次第です。 +`INNER JOIN`を使用するとどうなるでしょうか？試してみるのはあなた次第です。
@@ -234,7 +234,7 @@ LIMIT 10; 実際のビジネスシナリオでは、複数のテーブルを結合する文が非常に一般的です。結合の実行効率は、結合する各テーブルの順序に左右されます。TiDBは、結合したテーブルの再配置アルゴリズムを使用して、複数のテーブルを結合する順序を決定します。 -オプティマイザによって選択された結合順序が予想どおりに最適でない場合は、 `STRAIGHT_JOIN`使用して、TiDB が`FROM`句で使用されるテーブルの順序でクエリを結合するように強制できます。 +オプティマイザによって選択された結合順序が予想どおりに最適でない場合は、 `STRAIGHT_JOIN`を使用して、TiDB が`FROM`句で使用されるテーブルの順序でクエリを結合するように強制できます。 ```sql EXPLAIN SELECT * diff --git a/develop/dev-guide-optimize-sql-best-practices.md b/develop/dev-guide-optimize-sql-best-practices.md index dad031a4c803e..51d07d471fe47 100644 --- a/develop/dev-guide-optimize-sql-best-practices.md +++ b/develop/dev-guide-optimize-sql-best-practices.md @@ -83,7 +83,7 @@ public void batchInsert(Connection connection) throws SQLException { ### 必要な列のみをクエリする {#only-query-the-columns-you-need} -すべての列のデータが必要ない場合は、 `SELECT *`使用してすべての列のデータを取得しないでください。次のクエリは非効率的です。 +すべての列のデータが必要ない場合は、 `SELECT *`を使用してすべての列のデータを取得しないでください。次のクエリは非効率的です。 ```sql SELECT * FROM books WHERE title = 'Marian Yost'; @@ -111,7 +111,7 @@ SELECT title, price FROM books WHERE title = 'Marian Yost'; TRUNCATE TABLE t; ``` -完全なテーブルデータに`DELETE`使用することはお勧めしません。 +完全なテーブルデータに`DELETE`を使用することはお勧めしません。 ```sql DELETE FROM t; diff --git a/develop/dev-guide-optimize-sql.md b/develop/dev-guide-optimize-sql.md index bb19a3490b725..803a5275f5170 100644 --- a/develop/dev-guide-optimize-sql.md +++ b/develop/dev-guide-optimize-sql.md @@ -42,7 +42,7 @@ SELECT * FROM books WHERE title = 'Marian Yost'; Time: 0.582s ``` -このクエリが遅い理由を理解するには、 `EXPLAIN`使用して実行プランを確認します。 +このクエリが遅い理由を理解するには、 `EXPLAIN`を使用して実行プランを確認します。 ```sql EXPLAIN SELECT * FROM books WHERE title = 'Marian Yost'; @@ -90,7 +90,7 @@ SELECT * FROM books WHERE title = 'Marian Yost'; Time: 0.007s ``` -パフォーマンスが向上した理由を理解するには、 `EXPLAIN`使用して新しい実行プランを確認します。 +パフォーマンスが向上した理由を理解するには、 `EXPLAIN`を使用して新しい実行プランを確認します。 ```sql EXPLAIN SELECT * FROM books WHERE title = 'Marian Yost'; @@ -221,7 +221,7 @@ SELECT * FROM books WHERE id = 896; Time: 0.004s ``` -実行プランを確認するには`EXPLAIN`使用します。 +実行プランを確認するには`EXPLAIN`を使用します。 ```sql EXPLAIN SELECT * FROM books WHERE id = 896; diff --git a/develop/dev-guide-paginate-results.md b/develop/dev-guide-paginate-results.md index b6956c2d29059..0321f46463f60 100644 --- a/develop/dev-guide-paginate-results.md +++ b/develop/dev-guide-paginate-results.md @@ -123,7 +123,7 @@ ORDER BY id;
-Javaで、ページのメタ情報を保存するクラスを`PageMeta`定義します。 +Javaで、ページのメタ情報を保存するクラスを`PageMeta`を定義します。 ```java public class PageMeta { @@ -256,7 +256,7 @@ ORDER BY page_num; クラスター化インデックス テーブル (「インデックス構成テーブル」とも呼ばれます) の場合、 `concat`関数を使用して複数の列の値をキーとして連結し、ウィンドウ関数を使用してページング情報を照会できます。 -この時点ではキーは文字列であり、 `min`と`max`集約関数を介したスライスで正しい`start_key`と`end_key`取得するには、文字列の長さが常に一定であることを確認する必要があります。文字列連結のフィールドの長さが固定でない場合は、 `LPAD`関数を使用してパディングすることができます。 +この時点ではキーは文字列であり、 `min`と`max`集約関数を介したスライスで正しい`start_key`と`end_key`を取得するには、文字列の長さが常に一定であることを確認する必要があります。文字列連結のフィールドの長さが固定でない場合は、 `LPAD`関数を使用してパディングすることができます。 たとえば、次のようにして`ratings`テーブル内のデータのページング バッチを実装できます。 diff --git a/develop/dev-guide-playground-gitpod.md b/develop/dev-guide-playground-gitpod.md index ec7757b488077..26964019871ee 100644 --- a/develop/dev-guide-playground-gitpod.md +++ b/develop/dev-guide-playground-gitpod.md @@ -107,7 +107,7 @@ RUN sudo apt install mysql-client -y RUN curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh ``` -次に、 `.gitpod.yml`更新する必要があります。 +次に、 `.gitpod.yml`を更新する必要があります。 ```yml # This configuration file was automatically generated by Gitpod. @@ -160,7 +160,7 @@ ports: `https://gitpod.io/#`アクセスして、最新のコードが適用された新しい Gitpod ワークスペースを作成します。 -確立されたすべてのワークスペースについては、 `https://gitpod.io/workspaces`参照してください。 +確立されたすべてのワークスペースについては、 `https://gitpod.io/workspaces`を参照してください。 ## まとめ {#summary} diff --git a/develop/dev-guide-proxysql-integration.md b/develop/dev-guide-proxysql-integration.md index e5babdc51e0ff..afd6c103b2d86 100644 --- a/develop/dev-guide-proxysql-integration.md +++ b/develop/dev-guide-proxysql-integration.md @@ -389,7 +389,7 @@ systemctl start docker > **注記：** > - > ***デバッグの場合：*** TiDB Cloud Starterインスタンスに接続できない場合は、ファイル`tidb-cloud-connect.cnf` 、 `proxysql-prepare.sql` 、および`proxysql-connect.py`確認してください。提供したサーバー情報が利用可能で正しいことを確認してください。 + > ***デバッグの場合：*** TiDB Cloud Starterインスタンスに接続できない場合は、ファイル`tidb-cloud-connect.cnf` 、 `proxysql-prepare.sql` 、および`proxysql-connect.py`を確認してください。提供したサーバー情報が利用可能で正しいことを確認してください。 3. コンテナを停止して削除し、前のディレクトリに戻るには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-java-hibernate.md b/develop/dev-guide-sample-application-java-hibernate.md index 33ab298145d28..ef3887f64d179 100644 --- a/develop/dev-guide-sample-application-java-hibernate.md +++ b/develop/dev-guide-sample-application-java-hibernate.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-sample-application-java-hibernate/','/ja/ti # Hibernateを使用してTiDBに接続する {#connect-to-tidb-with-hibernate} -TiDBはMySQL互換データベースであり、[Hibernate](https://hibernate.org/orm/)人気のオープンソースJava ORMです。TiDBはMySQLとの互換性が非常に高いため、長期的な互換性を確保するには、Hibernateの方言として`org.hibernate.dialect.MySQLDialect`使用することをお勧めします。あるいは、 [Hibernateコミュニティ方言](https://github.com/hibernate/hibernate-orm/tree/main/hibernate-community-dialects)にはTiDB専用の方言（ `org.hibernate.community.dialect.TiDBDialect` ）も用意されていますが、PingCAPではメンテナンスされていません。 `MySQLDialect`を使用して互換性の問題が発生した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告してください。 +TiDBはMySQL互換データベースであり、[Hibernate](https://hibernate.org/orm/)人気のオープンソースJava ORMです。TiDBはMySQLとの互換性が非常に高いため、長期的な互換性を確保するには、Hibernateの方言として`org.hibernate.dialect.MySQLDialect`を使用することをお勧めします。あるいは、 [Hibernateコミュニティ方言](https://github.com/hibernate/hibernate-orm/tree/main/hibernate-community-dialects)にはTiDB専用の方言（ `org.hibernate.community.dialect.TiDBDialect` ）も用意されていますが、PingCAPではメンテナンスされていません。 `MySQLDialect`を使用して互換性の問題が発生した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告してください。 このチュートリアルでは、TiDBとHibernateを使用して以下のタスクを実行する方法を学ぶことができます。 diff --git a/develop/dev-guide-sample-application-java-spring-boot.md b/develop/dev-guide-sample-application-java-spring-boot.md index 8766e91425ae0..23722a2eb4a37 100644 --- a/develop/dev-guide-sample-application-java-spring-boot.md +++ b/develop/dev-guide-sample-application-java-spring-boot.md @@ -259,7 +259,7 @@ public interface PlayerRepository extends JpaRepository { } ``` -次に、 `@Autowired`を必要とするクラスに`PlayerRepository`使用して自動依存性注入を行うことができます。これにより、CRUD関数を直接使用できるようになります。以下に例を示します。 +次に、 `@Autowired`を必要とするクラスに`PlayerRepository`を使用して自動依存性注入を行うことができます。これにより、CRUD関数を直接使用できるようになります。以下に例を示します。 ```java @Autowired diff --git a/develop/dev-guide-sql-development-specification.md b/develop/dev-guide-sql-development-specification.md index 7bbc85e85417d..ded709c537ac4 100644 --- a/develop/dev-guide-sql-development-specification.md +++ b/develop/dev-guide-sql-development-specification.md @@ -15,8 +15,8 @@ aliases: ['/ja/tidb/stable/dev-guide-sql-development-specification/','/ja/tidbcl ## SELECT *の使用法 {#code-select-code-usage} -- 基本原則: クエリに`SELECT *`使用しないでください。 -- 詳細：必要に応じて適切な列を選択し、 `SELECT *`使用してすべてのフィールドを読み取ることは避けてください。このような操作はネットワーク帯域幅を消費するためです。カバーインデックスを効果的に活用するには、クエリ対象のフィールドをインデックスに追加することを検討してください。 +- 基本原則: クエリに`SELECT *`を使用しないでください。 +- 詳細：必要に応じて適切な列を選択し、 `SELECT *`を使用してすべてのフィールドを読み取ることは避けてください。このような操作はネットワーク帯域幅を消費するためです。カバーインデックスを効果的に活用するには、クエリ対象のフィールドをインデックスに追加することを検討してください。 ## フィールドで関数を使用する {#use-functions-on-fields} diff --git a/develop/dev-guide-third-party-tools-compatibility.md b/develop/dev-guide-third-party-tools-compatibility.md index 95fb09db7c451..c07f5a7970423 100644 --- a/develop/dev-guide-third-party-tools-compatibility.md +++ b/develop/dev-guide-third-party-tools-compatibility.md @@ -96,7 +96,7 @@ TiDBでは、 `\`番目の文字をエスケープせずに`NO_BACKSLASH_ESCAPES **回避方法** -TiDB では`NO_BACKSLASH_ESCAPES`と`\`を使用しないでください。SQL ステートメントでは`\\`使用してください。 +TiDB では`NO_BACKSLASH_ESCAPES`と`\`を使用しないでください。SQL ステートメントでは`\\`を使用してください。 ### INDEX_USED関連のパラメータはサポートされていません {#the-code-index-used-code-related-parameters-are-not-supported} @@ -143,7 +143,7 @@ MySQL Connector/J 8.0.32 以前のバージョンを使用している場合、 > **注記：** > -> `useConfigs=maxPerformance`は一連の設定が含まれています。MySQL Connector/J 8.0 および MySQL Connector/J 5.1 の詳細な設定については、それぞれ[mysql-コネクタ-j 8.0](https://github.com/mysql/mysql-connector-j/blob/release/8.0/src/main/resources/com/mysql/cj/configurations/maxPerformance.properties)および[mysql-コネクタ-j 5.1](https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/configs/maxPerformance.properties)参照してください。 `maxPerformance`使用する場合は`useLocalTransactionState`無効にする必要があります。つまり、 `useConfigs=maxPerformance&useLocalTransactionState=false`使用してください。 +> `useConfigs=maxPerformance`は一連の設定が含まれています。MySQL Connector/J 8.0 および MySQL Connector/J 5.1 の詳細な設定については、それぞれ[mysql-コネクタ-j 8.0](https://github.com/mysql/mysql-connector-j/blob/release/8.0/src/main/resources/com/mysql/cj/configurations/maxPerformance.properties)および[mysql-コネクタ-j 5.1](https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/configs/maxPerformance.properties)参照してください。 `maxPerformance`を使用する場合は`useLocalTransactionState`無効にする必要があります。つまり、 `useConfigs=maxPerformance&useLocalTransactionState=false`を使用してください。 このバグはMySQL Connector/J 8.0.33で修正されました。8.0.xシリーズのアップデートは終了しているため、安定性とパフォーマンスを向上させるためにMySQL Connector/Jを[最新の一般提供（GA）バージョン](https://dev.mysql.com/downloads/connector/j/)にアップグレードすることを強くお勧めします。 diff --git a/develop/dev-guide-transaction-troubleshoot.md b/develop/dev-guide-transaction-troubleshoot.md index 5256a346a1481..e4f58ba3aafae 100644 --- a/develop/dev-guide-transaction-troubleshoot.md +++ b/develop/dev-guide-transaction-troubleshoot.md @@ -37,7 +37,7 @@ TiDB悲観的トランザクション モードでは、2 つのクライアン | UPDATE books SET stock=stock-1 WHERE id=2; -- 実行はブロックされます | | | | UPDATE books SET stock=stock-1 WHERE id=1; -- デッドロックエラーが発生します | -クライアントBでデッドロックエラーが発生すると、TiDBはクライアントBのトランザクションを自動的にロールバックします。クライアントAの`id=2`更新は正常に実行されます。その後、 `COMMIT`実行してトランザクションを終了できます。 +クライアントBでデッドロックエラーが発生すると、TiDBはクライアントBのトランザクションを自動的にロールバックします。クライアントAの`id=2`更新は正常に実行されます。その後、 `COMMIT`を実行してトランザクションを終了できます。 ### 解決策1: デッドロックを回避する {#solution-1-avoid-deadlocks} @@ -85,7 +85,7 @@ MySQL などの従来のデータベースとは異なり、TiDB では、楽観 再試行ロジックは次のルールに従う必要があります。 - 失敗した再試行回数が`max_retries`制限に達した場合、エラーをスローします。 -- SQL実行例外をキャッチするには`try ... catch ...`使用します。以下のエラーが発生した場合は再試行してください。その他のエラーが発生した場合はロールバックしてください。 +- SQL実行例外をキャッチするには`try ... catch ...`を使用します。以下のエラーが発生した場合は再試行してください。その他のエラーが発生した場合はロールバックしてください。 - `Error 8002: can not retry select for update statement` : SELECT FOR UPDATE 書き込み競合エラー - `Error 8022: Error: KV error safe to retry` : トランザクションのコミットに失敗したエラー。 - `Error 8028: Information schema is changed during the execution of the statement` : DDL 操作によってテーブル スキーマが変更され、トランザクションのコミットでエラーが発生しました。 diff --git a/develop/dev-guide-update-data.md b/develop/dev-guide-update-data.md index 2557a8215595a..0bbca1ad3ee4f 100644 --- a/develop/dev-guide-update-data.md +++ b/develop/dev-guide-update-data.md @@ -150,7 +150,7 @@ VALUES (?, ?, ?, NOW()) ON DUPLICATE KEY UPDATE `score` = ?, `rated_at` = NOW()" ## 一括更新 {#bulk-update} -テーブル内の複数のデータ行を更新する必要がある場合は、 [`INSERT ON DUPLICATE KEY UPDATE`使用する](#use-insert-on-duplicate-key-update)`WHERE`句を使用して、更新する必要のあるデータをフィルタリングできます。 +テーブル内の複数のデータ行を更新する必要がある場合は、 [`INSERT ON DUPLICATE KEY UPDATE`を使用する](#use-insert-on-duplicate-key-update)`WHERE`句を使用して、更新する必要のあるデータをフィルタリングできます。 ただし、多数の行 (たとえば、1 万行以上) を更新する必要がある場合は、データを繰り返し更新すること、つまり、更新が完了するまで各繰り返しでデータの一部のみを更新することをお勧めします。これは、TiDB が単一トランザクションのサイズを制限しているためです ( [トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)。一度にあまりに多くのデータ更新を行うと、長時間ロックが保持されたり ([悲観的トランザクション](/pessimistic-transaction.md))、競合が発生したり ([楽観的トランザクション](/optimistic-transaction.md)) されます。プログラムまたはスクリプトでループを使用すると、操作を完了できます。 diff --git a/develop/serverless-driver-prisma-example.md b/develop/serverless-driver-prisma-example.md index 55fe92b0d517d..2d4020e224351 100644 --- a/develop/serverless-driver-prisma-example.md +++ b/develop/serverless-driver-prisma-example.md @@ -76,7 +76,7 @@ const prisma = new PrismaClient({ adapter }); ## Node.js環境でPrismaアダプターを使用する {#use-the-prisma-adapter-in-node-js-environments} -このセクションでは、Node.js 環境で`@tidbcloud/prisma-adapter`使用する方法の例を示します。 +このセクションでは、Node.js 環境で`@tidbcloud/prisma-adapter`を使用する方法の例を示します。 ### 始める前に {#before-you-begin} diff --git a/dm/deploy-a-dm-cluster-using-binary.md b/dm/deploy-a-dm-cluster-using-binary.md index bd64ef9d764a1..9e7821de4e006 100644 --- a/dm/deploy-a-dm-cluster-using-binary.md +++ b/dm/deploy-a-dm-cluster-using-binary.md @@ -121,7 +121,7 @@ DM マスターのコマンドライン パラメータの説明は次のとお > **注記：** > - > このコマンドを実行した後、コンソールにはログは出力されません。実行時ログを表示するには、 `tail -f dm-master.log`実行してください。 + > このコマンドを実行した後、コンソールにはログは出力されません。実行時ログを表示するには、 `tail -f dm-master.log`を実行してください。 3. DM-master2とDM-master3については、設定ファイルの`name`それぞれ`master2`と`master3`に変更し、 `peer-urls`それぞれ`192.168.0.5:8291`と`192.168.0.6:8291`に変更します。その後、手順2を繰り返します。 diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index 333bccef7ece4..5707d244a162e 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -141,7 +141,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`実行します。 +- DMクラスタのバージョンは`${version}`です。TiUPでサポートされている最新バージョンを確認するには、 `tiup list dm-master`を実行します。 - 初期化構成ファイルは`topology.yaml`です。 - `--user root` : `root`キーを使用してターゲット マシンにログインし、クラスターの展開を完了するか、 `ssh`および`sudo`権限を持つ他のユーザーを使用して展開を完了することができます。 - `[-i]`と`[-p]` : オプション。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。4 `[-i]` 、ターゲットマシンにアクセスできる`root`ユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。10 `[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 diff --git a/dm/deploy-a-dm-cluster-using-tiup.md b/dm/deploy-a-dm-cluster-using-tiup.md index b49df9298cdec..c66a4cbe444c3 100644 --- a/dm/deploy-a-dm-cluster-using-tiup.md +++ b/dm/deploy-a-dm-cluster-using-tiup.md @@ -162,7 +162,7 @@ tiup dm deploy ${name} ${version} ./topology.yaml -u ${ssh_user} [-p] [-i /home/ | パラメータ | 説明 | | ------------------------ | ------------------------------------------------------------------------------- | | `${name}` | DM クラスターの名前 (例: dm-test) | -| `${version}` | DM クラスターのバージョン`tiup list dm-master`実行すると、サポートされている他のバージョンを確認できます。 | +| `${version}` | DM クラスターのバージョン`tiup list dm-master`を実行すると、サポートされている他のバージョンを確認できます。 | | `./topology.yaml` | トポロジ構成ファイルのパス。 | | `-u`または`--user` | クラスターの展開を完了するには、root ユーザーまたは ssh および sudo権限を持つ他のユーザー アカウントとしてターゲット マシンにログインします。 | | `-p`または`--password` | 対象ホストのパスワード。指定すると、パスワード認証が使用されます。 | diff --git a/dm/dm-best-practices.md b/dm/dm-best-practices.md index 8f6e7656a50a7..e5d9f3feb3c46 100644 --- a/dm/dm-best-practices.md +++ b/dm/dm-best-practices.md @@ -53,7 +53,7 @@ TiDBの`AUTO_INCREMENT`はMySQLの`AUTO_INCREMENT`と互換性があります。 - 非クラスター化インデックス + `shard row id bit` - 非クラスター化インデックスと`shard row id bit`使用すると、 `AUTO_INCREMENT`使用時の書き込みホットスポット問題を回避できます。ただし、このシナリオでは、主キーを使用してクエリを実行する際にテーブル参照がクエリパフォーマンスに影響を与える可能性があります。 + 非クラスター化インデックスと`shard row id bit`を使用すると、 `AUTO_INCREMENT`使用時の書き込みホットスポット問題を回避できます。ただし、このシナリオでは、主キーを使用してクエリを実行する際にテーブル参照がクエリパフォーマンスに影響を与える可能性があります。 - クラスター化インデックス + 外部分散IDジェネレータ @@ -72,7 +72,7 @@ TiDBの`AUTO_INCREMENT`はMySQLの`AUTO_INCREMENT`と互換性があります。 | シナリオ | 推奨される解決策 | 長所 | 短所 | | :-------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -|
  • TiDB は、プライマリおよび書き込み集中型データベースとして機能します。
  • ビジネス ロジックは、主キー ID の連続性に大きく依存します。
    • | 非クラスター化インデックスを持つテーブルを作成し、 `SHARD_ROW_ID_BIT`設定します。主キー列として`SEQUENCE`使用します。 | データ書き込みのホットスポットを回避し、ビジネス データの継続性と単調な増加を確保できます。 |
  • データ書き込みの継続性を確保するために、データ書き込みのスループット容量が低下します。
  • 主キークエリのパフォーマンスが低下します。
    • | +|
  • TiDB は、プライマリおよび書き込み集中型データベースとして機能します。
  • ビジネス ロジックは、主キー ID の連続性に大きく依存します。
    • | 非クラスター化インデックスを持つテーブルを作成し、 `SHARD_ROW_ID_BIT`設定します。主キー列として`SEQUENCE`を使用します。 | データ書き込みのホットスポットを回避し、ビジネス データの継続性と単調な増加を確保できます。 |
  • データ書き込みの継続性を確保するために、データ書き込みのスループット容量が低下します。
  • 主キークエリのパフォーマンスが低下します。
    • | |
  • TiDB は、プライマリおよび書き込み集中型データベースとして機能します。
  • ビジネス ロジックは、主キー ID の増分に大きく依存します。
    • | 非クラスター化インデックスを持つテーブルを作成し、 `SHARD_ROW_ID_BIT`設定します。アプリケーションIDジェネレータを使用して主キーIDを生成します。 | データ書き込みホットスポットを回避し、データ書き込みのパフォーマンスを保証し、ビジネスデータの増分を保証しますが、継続性を保証することはできません。 |
  • アプリケーションをカスタマイズする必要があります。
  • 外部 ID ジェネレーターはクロックの精度に大きく依存しており、障害が発生する可能性があります。
    • | |
  • TiDB は、プライマリおよび書き込み集中型データベースとして機能します。
  • ビジネス ロジックは主キー ID の連続性に依存しません。
    • | クラスター化インデックスを持つテーブルを作成し、主キー列に`AUTO_RANDOM`設定します。 |
  • データ書き込みホットスポットを回避でき、主キーのクエリ パフォーマンスが優れています。
  • `AUTO_INCREMENT`から`AUTO_RANDOM`への切り替えもスムーズに行えます。
    • |
  • 主キー ID はランダムです。
  • 書き込みスループット能力は制限されています。
  • 挿入時間列を使用してビジネス データを並べ替えることをお勧めします。
  • 主キー ID を使用してデータを並べ替える必要がある場合は、クエリに対して 5 ビットを左シフトすることができ、これによりデータの増分が保証されます。
    • | | TiDB は読み取り専用データベースとして機能します。 | 非クラスター化インデックスを持つテーブルを作成し、 `SHARD_ROW_ID_BIT`設定します。主キー列はデータソースと一貫性を保ちます。 |
  • データ書き込みホットスポットを回避できます。
  • カスタマイズコストが少なくて済みます。
    • | 主キーのクエリ パフォーマンスが影響を受けます。 | diff --git a/dm/dm-binlog-event-filter.md b/dm/dm-binlog-event-filter.md index 17ce31f228a57..9593466579e23 100644 --- a/dm/dm-binlog-event-filter.md +++ b/dm/dm-binlog-event-filter.md @@ -160,7 +160,7 @@ filters: ### TiDBパーサーがサポートしていないSQL文を除外する {#filter-out-the-sql-statements-that-the-tidb-parser-does-not-support} -TiDBパーサーがサポートしていないSQL文については、DMは解析できず、 `schema` / `table`情報を取得できません。そのため、グローバルフィルタリングルール`schema-pattern: "*"`使用する必要があります。 +TiDBパーサーがサポートしていないSQL文については、DMは解析できず、 `schema` / `table`情報を取得できません。そのため、グローバルフィルタリングルール`schema-pattern: "*"`を使用する必要があります。 > **注記：** > diff --git a/dm/dm-continuous-data-validation.md b/dm/dm-continuous-data-validation.md index 7689f54b6da30..a30f464853476 100644 --- a/dm/dm-continuous-data-validation.md +++ b/dm/dm-continuous-data-validation.md @@ -65,7 +65,7 @@ validators: - `--mode` : 検証モードを指定します。指定できる値は`fast`と`full`です。 - `--start-time` : 検証の開始時刻を指定します。形式は`2021-10-21 00:01:00`または`2021-10-21T00:01:00`に従います。 -- `task` : 継続的検証を有効にするタスク名を指定します。2 `--all-task`指定すると、すべてのタスクに対して検証が有効になります。 +- `task` : 継続的検証を有効にするタスク名を指定します。2 `--all-task`を指定すると、すべてのタスクに対して検証が有効になります。 例えば： @@ -119,7 +119,7 @@ dmctl --master-addr=127.0.0.1:8261 validation start --start-time 2021-10-21T00:0 -h, --help help for status --table-stage string filter validation tables by stage: running/stopped -上記のコマンドで`--table-stage`使用すると、検証対象のテーブルをフィルタリングしたり、検証を停止したりできます。出力例: +上記のコマンドで`--table-stage`を使用すると、検証対象のテーブルをフィルタリングしたり、検証を停止したりできます。出力例: ```json { @@ -195,7 +195,7 @@ dmctl --master-addr=127.0.0.1:8261 validation start --start-time 2021-10-21T00:0 dmctl は 3 つのエラー処理コマンドを提供します。 -- `clear-error` : エラー行をクリアします。2 コマンド`show-error`実行すると、エラー行は表示されなくなります。 +- `clear-error` : エラー行をクリアします。2 コマンド`show-error`を実行すると、エラー行は表示されなくなります。 Usage: dmctl validation clear-error [flags] diff --git a/dm/dm-customized-secret-key.md b/dm/dm-customized-secret-key.md index b5a60629565be..053f655fe7c42 100644 --- a/dm/dm-customized-secret-key.md +++ b/dm/dm-customized-secret-key.md @@ -10,7 +10,7 @@ summary: DM（データ移行）データ ソースおよび移行タスク構 ## 使用法 {#usage} 1. カスタムキーファイルを作成します。このファイルには、64文字の16進数AES-256秘密鍵が含まれている必要があります。この鍵を生成する方法の一つは、ランダムデータ（例えば`head -n 256 /dev/urandom | sha256sum`のSHA256チェックサムを計算することです。 -2. DM-master [コマンドラインフラグ](/dm/dm-command-line-flags.md)または[設定ファイル](/dm/dm-master-configuration-file.md)で、カスタム キー ファイルのパスとして`secret-key-path`指定します。 +2. DM-master [コマンドラインフラグ](/dm/dm-command-line-flags.md)または[設定ファイル](/dm/dm-master-configuration-file.md)で、カスタム キー ファイルのパスとして`secret-key-path`を指定します。 ## v8.0.0 より前のバージョンからアップグレードする {#upgrade-from-a-version-earlier-than-v8-0-0} diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md index 131fe19e62965..fb2d0bcf09762 100644 --- a/dm/dm-error-handling.md +++ b/dm/dm-error-handling.md @@ -113,10 +113,10 @@ DM の実行中にエラーが発生した場合は、次の手順に従って #### ソリューション {#solutions} -DMは移行タスクにおいてデータを下流へ並行して移行する機能を備えているため、タスクが中断されると様々なエラーが発生する可能性があります。これらのエラーは`query-status`使用して確認できます。 +DMは移行タスクにおいてデータを下流へ並行して移行する機能を備えているため、タスクが中断されると様々なエラーが発生する可能性があります。これらのエラーは`query-status`を使用して確認できます。 - 増分レプリケーション プロセス中に`invalid connection`エラーのみが発生した場合、DM はタスクを自動的に再試行します。 -- バージョンの問題により DM が自動的に再試行されない場合、または再試行に失敗した場合は、 `stop-task`使用してタスクを停止し、 `start-task`使用してタスクを再起動します。 +- バージョンの問題により DM が自動的に再試行されない場合、または再試行に失敗した場合は、 `stop-task`を使用してタスクを停止し、 `start-task`を使用してタスクを再起動します。 ### 移行タスクがdriver: bad connectionエラーが返されました {#a-migration-task-is-interrupted-with-the-code-driver-bad-connection-code-error-returned} @@ -126,7 +126,7 @@ DMは移行タスクにおいてデータを下流へ並行して移行する機 #### 解決 {#solution} -現在のバージョンのDMは、エラー発生時に自動的に再試行します。自動再試行をサポートしていない以前のバージョンをご利用の場合は、コマンド`stop-task`を実行してタスクを停止し、その後コマンド`start-task`実行してタスクを再開してください。 +現在のバージョンのDMは、エラー発生時に自動的に再試行します。自動再試行をサポートしていない以前のバージョンをご利用の場合は、コマンド`stop-task`を実行してタスクを停止し、その後コマンド`start-task`を実行してタスクを再開してください。 ### リレーユニットはevent from * in * diff from passed-in event *スローするか、または、 binlogエラーの取得または解析に失敗して移行タスクが中断され、binlog get binlog error ERROR 1236 (HY000)やbinlog checksum mismatch, data may be corrupted 。 {#the-relay-unit-throws-error-code-event-from-in-diff-from-passed-in-event-code-or-a-migration-task-is-interrupted-with-failing-to-get-or-parse-binlog-errors-like-code-get-binlog-error-error-1236-hy000-code-and-code-binlog-checksum-mismatch-data-may-be-corrupted-code-returned} @@ -134,7 +134,7 @@ DMは移行タスクにおいてデータを下流へ並行して移行する機 リレー ログ プルまたは増分レプリケーションの DM プロセス中に、アップストリームbinlogファイルのサイズが**4 GB**を超えると、この 2 つのエラーが発生する可能性があります。 -**原因：**リレーログを書き込む際、DMはbinlogの位置とbinlogファイルのサイズに基づいてイベント検証を行い、複製されたbinlogの位置をチェックポイントとして保存する必要があります。しかし、公式のMySQLではbinlogの位置を`uint32`保存しています。そのため、4GBを超えるbinlogファイルのbinlogの位置がオーバーフローし、上記のエラーが発生します。 +**原因：**リレーログを書き込む際、DMはbinlogの位置とbinlogファイルのサイズに基づいてイベント検証を行い、複製されたbinlogの位置をチェックポイントとして保存する必要があります。しかし、公式のMySQLではbinlogの位置を`uint32`を保存しています。そのため、4GBを超えるbinlogファイルのbinlogの位置がオーバーフローし、上記のエラーが発生します。 #### ソリューション {#solutions} @@ -146,7 +146,7 @@ DMは移行タスクにおいてデータを下流へ並行して移行する機 3. アップストリーム内の対応するbinlogファイルをリレー ログ ファイルとしてリレー ログ ディレクトリにコピーします。 -4. リレーログディレクトリ内の対応する`relay.meta`のファイルを更新し、次のbinlogファイルから取得します。DMワーカーに`enable_gtid` ～ `true`指定した場合は、 `relay.meta`ファイルを更新するときに、次のbinlogファイルに対応するGTIDを変更する必要があります。それ以外の場合は、GTIDを変更する必要はありません。 +4. リレーログディレクトリ内の対応する`relay.meta`のファイルを更新し、次のbinlogファイルから取得します。DMワーカーに`enable_gtid` ～ `true`を指定した場合は、 `relay.meta`ファイルを更新するときに、次のbinlogファイルに対応するGTIDを変更する必要があります。それ以外の場合は、GTIDを変更する必要はありません。 例: エラーが発生した場合、 `binlog-name = "mysql-bin.004451"`と`binlog-pos = 2453`をそれぞれ`binlog-name = "mysql-bin.004452"`と`binlog-pos = 4`に更新し、 `binlog-gtid`を`f0e914ef-54cf-11e7-813d-6c92bf2fa791:1-138218058`に更新します。 @@ -156,7 +156,7 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ 1. エラーが発生したときに、対応するbinlogファイルのサイズが 4GB を超えたことをアップストリームで特定します。 -2. `stop-task`使用して移行タスクを停止します。 +2. `stop-task`を使用して移行タスクを停止します。 3. グローバル チェックポイントとダウンストリーム`dm_meta`データベースの各テーブル チェックポイントの`binlog_name` 、エラーのあるbinlogファイルの名前に更新します。5 `binlog_pos` 、移行が完了した有効な位置の値 (例: 4) に更新します。 @@ -166,11 +166,11 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ UPDATE dm_test_syncer_checkpoint SET binlog_name='mysql-bin|000001.004451', binlog_pos = 4 WHERE id='replica-1'; ``` -4. 再入可能性を確保するには、移行タスク構成の`syncers`セクションで`safe-mode: true`指定します。 +4. 再入可能性を確保するには、移行タスク構成の`syncers`セクションで`safe-mode: true`を指定します。 -5. `start-task`使用して移行タスクを開始します。 +5. `start-task`を使用して移行タスクを開始します。 -6. `query-status`使用して移行タスクのステータスを確認する。元のエラーの原因となったリレーログファイルの移行が完了したら、 `safe-mode`元の値に戻して移行タスクを再開できます。 +6. `query-status`を使用して移行タスクのステータスを確認する。元のエラーの原因となったリレーログファイルの移行が完了したら、 `safe-mode`元の値に戻して移行タスクを再開できます。 ### タスクをクエリするかログを確認すると、 Access denied for user 'root'@'172.31.43.27' (using password: YES)表示されます。 {#code-access-denied-for-user-root-172-31-43-27-using-password-yes-code-shows-when-you-query-the-task-or-check-the-log} @@ -200,4 +200,4 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ - TiDBサーバーで`set @@global.max_allowed_packet=134217728` （ `134217728` =128MB）を実行します。 - - まず、DMタスク設定ファイルのセクション`target-database`に`max-allowed-packet: 134217728` （128MB）を追加します。次に、コマンド`stop-task`を実行し、コマンド`start-task`実行します。 + - まず、DMタスク設定ファイルのセクション`target-database`に`max-allowed-packet: 134217728` （128MB）を追加します。次に、コマンド`stop-task`を実行し、コマンド`start-task`を実行します。 diff --git a/dm/dm-faq.md b/dm/dm-faq.md index 1129293e864ae..13434d7c6d845 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -48,7 +48,7 @@ TiDBでサポートされていないDDL文に遭遇した場合は、dmctlを 3. データ移行タスクを再開するには、次のいずれかの方法を使用します。 - - タスク設定ファイルで新しいタスク名を指定します。次に、 `start-task {task-config-file}`実行します。 + - タスク設定ファイルで新しいタスク名を指定します。次に、 `start-task {task-config-file}`を実行します。 - `start-task --remove-meta {task-config-file}`を実行します。 ## online-ddl: trueを設定した後、gh-ost テーブルに関連する DDL 操作によって返されたエラーをどのように処理しますか? {#how-to-handle-the-error-returned-by-the-ddl-operation-related-to-the-gh-ost-table-after-code-online-ddl-true-code-is-set} @@ -102,7 +102,7 @@ MySQLはエクスポート時にスナップショットを指定できないた 既存の移行タスクに対応するグローバルチェックポイント（ `is_global=1` ）の位置情報を`checkpoint-T` （例： `(mysql-bin.000100, 1234)` ）として記録します。移行タスクに追加するテーブルのフルエクスポート`metedata` （または`Sync`ステージにある別のデータ移行タスクのチェックポイント）の位置情報を`checkpoint-S` （例： `(mysql-bin.000099, 5678)` ）として記録します。以下の手順でテーブルを移行タスクに追加できます。 -1. 既存の移行タスクを停止するには、 `stop-task`使用します。追加するテーブルが実行中の別の移行タスクに属している場合は、そのタスクも停止してください。 +1. 既存の移行タスクを停止するには、 `stop-task`を使用します。追加するテーブルが実行中の別の移行タスクに属している場合は、そのタスクも停止してください。 2. MySQLクライアントを使用して下流のTiDBデータベースに接続し、既存の移行タスクに対応するチェックポイントテーブルの情報を、 `checkpoint-T`と`checkpoint-S`の間の小さい方の値に手動で更新します。この例では`(mysql- bin.000099, 5678)`です。 @@ -179,7 +179,7 @@ curl -X POST -d "tidb_general_log=0" http://{TiDBIP}:10080/settings ## DM v1.0 では、タスクにエラーがある場合にコマンドsql-skip一部のステートメントをスキップできないのはなぜですか? {#in-dm-v1-0-why-does-the-command-code-sql-skip-code-fail-to-skip-some-statements-when-the-task-is-in-error} -まず、 `sql-skip`実行した後もbinlogの位置が進んでいるかどうかを確認する必要があります。進んでいる場合は、 `sql-skip`有効になっていることを意味します。このエラーが繰り返し発生する理由は、アップストリームがサポートされていない複数の DDL 文を送信しているためです。5 `sql-skip -s `使用して、これらの文に一致するパターンを設定できます。 +まず、 `sql-skip`を実行した後もbinlogの位置が進んでいるかどうかを確認する必要があります。進んでいる場合は、 `sql-skip`有効になっていることを意味します。このエラーが繰り返し発生する理由は、アップストリームがサポートされていない複数の DDL 文を送信しているためです。5 `sql-skip -s `を使用して、これらの文に一致するパターンを設定できます。 場合によっては、エラー メッセージに`parse statement`情報が含まれます。次に例を示します。 @@ -241,7 +241,7 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する 2. [TiUP DMオフラインパッケージ](https://download.pingcap.com/tidb-dm-v2.0.1-linux-amd64.tar.gz)をダウンロードして解凍します。 3. オフライン パッケージの`grafana-v4.0.3-**.tar.gz`解凍します。 4. フォルダー`deploy/grafana-$port/bin/public` `grafana-v4.0.3-**.tar.gz`のフォルダー`public`に置き換えます。 - 5. `tiup dm restart $cluster_name -R grafana`実行して Grafana サービスを再起動します。 + 5. `tiup dm restart $cluster_name -R grafana`を実行して Grafana サービスを再起動します。 ## DM v2.0 では、タスクでenable-relayとenable-gtid同時に有効になっている場合、コマンドquery-statusのクエリ結果に、Syncer チェックポイント GTID が連続していないと表示されるのはなぜですか? {#in-dm-v2-0-why-does-the-query-result-of-the-command-code-query-status-code-show-that-the-syncer-checkpoint-gtids-are-inconsecutive-if-the-task-has-code-enable-relay-code-and-code-enable-gtid-code-enabled-at-the-same-time} @@ -260,7 +260,7 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する | mysql-bin.000005 | 123 | Previous_gtids | 123452 | 194 | d3618e68-6052-11eb-a68b-0242ac110002:6-7 | +------------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+ -このバグは、dmctlで`query-status `実行してタスク情報を照会した際に、 `subTaskStatus.sync.syncerBinlogGtid`連続していないのに`subTaskStatus.sync.masterBinlogGtid`が連続していることがわかった場合に発生します。次の例をご覧ください。 +このバグは、dmctlで`query-status `を実行してタスク情報を照会した際に、 `subTaskStatus.sync.syncerBinlogGtid`連続していないのに`subTaskStatus.sync.masterBinlogGtid`が連続していることがわかった場合に発生します。次の例をご覧ください。 query-status test { diff --git a/dm/dm-handle-performance-issues.md b/dm/dm-handle-performance-issues.md index 7c5c39b9f4db1..947ec60e79bda 100644 --- a/dm/dm-handle-performance-issues.md +++ b/dm/dm-handle-performance-issues.md @@ -15,13 +15,13 @@ summary: DM に存在する可能性のある一般的なパフォーマンス - Grafana 監視ダッシュボードで[監視メトリック](/dm/monitor-a-dm-cluster.md#task)表示できます。 - 診断するコンポーネントは正常に動作しています。そうでない場合、監視メトリックの例外が発生する可能性があり、パフォーマンスの問題の診断に影響する可能性があります。 -データ移行のレイテンシーが大きい場合、ボトルネックが DMコンポーネント内にあるか、TiDB クラスター内にあるかを素早く判断するには、まず[下流にSQL文を書き込む](#write-sql-statements-to-downstream)の`DML queue remain length`確認します。 +データ移行のレイテンシーが大きい場合、ボトルネックが DMコンポーネント内にあるか、TiDB クラスター内にあるかを素早く判断するには、まず[下流にSQL文を書き込む](#write-sql-statements-to-downstream)の`DML queue remain length`を確認します。 ## リレーログユニット {#relay-log-unit} -リレーログユニットのパフォーマンス問題を診断するには、監視メトリック`binlog file gap between master and relay`確認します。このメトリックの詳細については、 [リレーログの監視メトリクス](/dm/monitor-a-dm-cluster.md#relay-log)を参照してください。このメトリックが長時間にわたって1より大きい場合、通常はパフォーマンス問題が発生していることを示します。このメトリックが0の場合、通常はパフォーマンス問題が発生していないことを示します。 +リレーログユニットのパフォーマンス問題を診断するには、監視メトリック`binlog file gap between master and relay`を確認します。このメトリックの詳細については、 [リレーログの監視メトリクス](/dm/monitor-a-dm-cluster.md#relay-log)を参照してください。このメトリックが長時間にわたって1より大きい場合、通常はパフォーマンス問題が発生していることを示します。このメトリックが0の場合、通常はパフォーマンス問題が発生していないことを示します。 -`binlog file gap between master and relay`の値が 0 であるにもかかわらず、パフォーマンスに問題があると思われる場合は、 `binlog pos`確認してください。このメトリックの`master` `relay`よりも大幅に大きい場合は、パフォーマンスに問題がある可能性があります。その場合は、問題を診断し、適切に対処してください。 +`binlog file gap between master and relay`の値が 0 であるにもかかわらず、パフォーマンスに問題があると思われる場合は、 `binlog pos`を確認してください。このメトリックの`master` `relay`よりも大幅に大きい場合は、パフォーマンスに問題がある可能性があります。その場合は、問題を診断し、適切に対処してください。 ### binlogデータを読み取る {#read-binlog-data} @@ -60,7 +60,7 @@ Binlogレプリケーションユニットのパフォーマンス問題を診 - このメトリックが長時間にわたって 1 より大きい場合、通常はパフォーマンスの問題があることを示します。 - このメトリックが 0 の場合、通常はパフォーマンスの問題がないことを示します。 -`binlog file gap between master and syncer`長期間にわたって1より大きい場合は、 `binlog file gap between relay and syncer`確認して、レイテンシーが主にどのユニットに存在しているかを特定してください。この値が通常0の場合、レイテンシーはリレーログユニットに存在している可能性があります。その場合は[リレーログユニット](#relay-log-unit)を参照して問題を解決してください。それ以外の場合は、引き続きBinlogレプリケーションユニットを確認してください。 +`binlog file gap between master and syncer`長期間にわたって1より大きい場合は、 `binlog file gap between relay and syncer`を確認して、レイテンシーが主にどのユニットに存在しているかを特定してください。この値が通常0の場合、レイテンシーはリレーログユニットに存在している可能性があります。その場合は[リレーログユニット](#relay-log-unit)を参照して問題を解決してください。それ以外の場合は、引き続きBinlogレプリケーションユニットを確認してください。 ### binlogデータを読み取る {#read-binlog-data} @@ -90,7 +90,7 @@ DMはbinlogイベントからSQL文を構築した後、 `worker-count`キュー - データ移行リンクに顕著なレイテンシーが見られ、各`q_*`に対応する`DML queue remain length`の曲線がほぼ同じで、ほぼ常に0である場合、DMが上流からのデータの読み取り、変換、または同時書き込みを時間内に実行できていないことを意味します（ボトルネックはリレーログユニットにある可能性があります）。トラブルシューティングについては、このドキュメントの前のセクションを参照してください。 -`DML queue remain length`に対応する曲線が0でない場合（通常、最大値は1024以下）、下流へのSQL文の書き込み時にボトルネックが発生していることを示します。3 `transaction execution latency`使用すると、下流への単一トランザクションの実行に要した時間を表示できます。 +`DML queue remain length`に対応する曲線が0でない場合（通常、最大値は1024以下）、下流へのSQL文の書き込み時にボトルネックが発生していることを示します。3 `transaction execution latency`を使用すると、下流への単一トランザクションの実行に要した時間を表示できます。 `transaction execution latency`は通常数十ミリ秒です。この値が大きすぎる場合は、下流データベースの監視に基づいて下流のパフォーマンスを確認してください。また、DMと下流データベース間のネットワークレイテンシーが大きくないか確認することもできます。 diff --git a/dm/dm-manage-schema.md b/dm/dm-manage-schema.md index 648bc3ac07e2e..3508d6bf4a5b3 100644 --- a/dm/dm-manage-schema.md +++ b/dm/dm-manage-schema.md @@ -36,7 +36,7 @@ DMが増分レプリケーションを実行する際、まず上流のbinlogを - [楽観的モードシャーディングDDLサポート](/dm/feature-shard-merge-optimistic.md)を有効にした移行中に、下流テーブルの`schema-D` 、上流の一部のシャードテーブルの`schema-B`および`schema-I`と不整合になる可能性があります。このような場合でも、DM は`schema-I`と`schema-B`整合性を維持し、DML に対応するbinlogイベントを正常に解析できるようにします。 -- 下流テーブルに上流テーブルよりも多くの列がある場合、 `schema-D` `schema-B`および`schema-I`と不整合になる可能性があります。完全なデータ移行（ `task-mode=all` ）では、DMが自動的に不整合を処理します。増分移行（ `task-mode=incremental` ）では、タスクが初めて開始され、内部スキーマ情報がまだないため、DMは自動的に下流スキーマ（ `schema-D` ）を読み取り、 `schema-I`更新します（この動作はDMのバージョンによって異なります）。その後、DMが`schema-I`使用して`schema-B`のbinlogを解析すると、 `Column count doesn't match value count`エラーが報告されます。詳細については、 [より多くの列を持つ下流の TiDB テーブルにデータを移行する](/migrate-with-more-columns-downstream.md)を参照してください。 +- 下流テーブルに上流テーブルよりも多くの列がある場合、 `schema-D` `schema-B`および`schema-I`と不整合になる可能性があります。完全なデータ移行（ `task-mode=all` ）では、DMが自動的に不整合を処理します。増分移行（ `task-mode=incremental` ）では、タスクが初めて開始され、内部スキーマ情報がまだないため、DMは自動的に下流スキーマ（ `schema-D` ）を読み取り、 `schema-I`を更新します（この動作はDMのバージョンによって異なります）。その後、DMが`schema-I`を使用して`schema-B`のbinlogを解析すると、 `Column count doesn't match value count`エラーが報告されます。詳細については、 [より多くの列を持つ下流の TiDB テーブルにデータを移行する](/migrate-with-more-columns-downstream.md)を参照してください。 `binlog-schema`コマンドを実行して、DM で管理されている`schema-I`テーブル スキーマを取得、変更、または削除できます。 @@ -86,7 +86,7 @@ help binlog-schema ### テーブルスキーマを取得する {#get-the-table-schema} -テーブル スキーマを取得するには、コマンド`binlog-schema list`実行します。 +テーブル スキーマを取得するには、コマンド`binlog-schema list`を実行します。 ```bash help binlog-schema list diff --git a/dm/dm-manage-source.md b/dm/dm-manage-source.md index dc6525d105058..a6f23c2362ac1 100644 --- a/dm/dm-manage-source.md +++ b/dm/dm-manage-source.md @@ -84,7 +84,7 @@ operate-source create ./source.yaml > > `config`コマンドは DM v6.0 以降のバージョンでのみサポートされます。それ以前のバージョンでは、 `get-config`コマンドを使用する必要があります。 -`source-id`わかっている場合は、 `dmctl --master-addr config source `実行してデータ ソース構成を取得できます。 +`source-id`わかっている場合は、 `dmctl --master-addr config source `を実行してデータ ソース構成を取得できます。 ```bash config source mysql-replica-01 @@ -148,7 +148,7 @@ help transfer-source ### 使用例 {#usage-example} -DM ワーカーのバインディングがわからない場合は、 `dmctl --master-addr list-member --worker`実行して、すべてのワーカーの現在のバインディングを一覧表示できます。 +DM ワーカーのバインディングがわからない場合は、 `dmctl --master-addr list-member --worker`を実行して、すべてのワーカーの現在のバインディングを一覧表示できます。 ```bash list-member --worker @@ -191,7 +191,7 @@ transfer-source mysql-replica-01 dm-worker-2 "msg": "" } -`dmctl --master-addr list-member --worker`実行して、コマンドが有効になるかどうかを確認します。 +`dmctl --master-addr list-member --worker`を実行して、コマンドが有効になるかどうかを確認します。 ```bash list-member --worker diff --git a/dm/dm-online-ddl-tool-support.md b/dm/dm-online-ddl-tool-support.md index e20279d67b577..92d28faa80f1d 100644 --- a/dm/dm-online-ddl-tool-support.md +++ b/dm/dm-online-ddl-tool-support.md @@ -31,7 +31,7 @@ online-ddl: true > **注記：** > -> v2.0.5以降、 `online-ddl-scheme`非推奨となりました。そのため、 `online-ddl-scheme`ではなく`online-ddl`使用する必要があります。つまり、 `online-ddl: true`設定すると`online-ddl-scheme`上書きされ、 `online-ddl-scheme: "pt"`または`online-ddl-scheme: "gh-ost"`は`online-ddl: true`に変換されます。 +> v2.0.5以降、 `online-ddl-scheme`非推奨となりました。そのため、 `online-ddl-scheme`ではなく`online-ddl`を使用する必要があります。つまり、 `online-ddl: true`設定すると`online-ddl-scheme`上書きされ、 `online-ddl-scheme: "pt"`または`online-ddl-scheme: "gh-ost"`は`online-ddl: true`に変換されます。
    diff --git a/dm/dm-pause-task.md b/dm/dm-pause-task.md index abe974766cd79..79a00f37d33cb 100644 --- a/dm/dm-pause-task.md +++ b/dm/dm-pause-task.md @@ -9,8 +9,8 @@ summary: TiDB データ移行でデータ移行タスクを一時停止する方 `pause-task` `stop-task`次の点で異なります: -- `pause-task`移行タスクを一時停止するだけです。タスクのステータス情報（メモリに保持されている）は`query-status`で照会できます。4 `stop-task`移行タスクを終了し、このタスクに関連するすべての情報をメモリから削除します。つまり、 `query-status`使用してステータス情報を照会することはできません。「チェックポイント」のような`dm_meta`や、下流に移行済みのデータは削除されません。 -- `pause-task`実行して移行タスクを一時停止した場合、同じ名前の新しいタスクを開始することはできません。また、一時停止したタスクは既に存在するため、そのタスクのリレーログを削除することもできません`stop-task`実行してタスクを停止した場合、同じ名前の新しいタスクを開始できます。また、停止したタスクは既に存在しないため、そのタスクのリレーログを削除することができます。 +- `pause-task`移行タスクを一時停止するだけです。タスクのステータス情報（メモリに保持されている）は`query-status`で照会できます。4 `stop-task`移行タスクを終了し、このタスクに関連するすべての情報をメモリから削除します。つまり、 `query-status`を使用してステータス情報を照会することはできません。「チェックポイント」のような`dm_meta`や、下流に移行済みのデータは削除されません。 +- `pause-task`を実行して移行タスクを一時停止した場合、同じ名前の新しいタスクを開始することはできません。また、一時停止したタスクは既に存在するため、そのタスクのリレーログを削除することもできません`stop-task`を実行してタスクを停止した場合、同じ名前の新しいタスクを開始できます。また、停止したタスクは既に存在しないため、そのタスクのリレーログを削除することができます。 - `pause-task`は通常、トラブルシューティングのためにタスクを一時停止するために使用され、 `stop-task`は移行タスクを永続的に削除するか、 `start-task`と連携して構成情報を更新するために使用されます。 ```bash diff --git a/dm/dm-performance-test.md b/dm/dm-performance-test.md index 2c58d5ee2be09..12e8de544de91 100644 --- a/dm/dm-performance-test.md +++ b/dm/dm-performance-test.md @@ -38,7 +38,7 @@ CREATE TABLE `sbtest` ( #### テストデータを生成する {#generate-test-data} -`sysbench`使用してアップストリームにテストテーブルを作成し、完全インポート用のテストデータを生成します。テストデータを生成するには、以下の`sysbench`コマンドを実行します。 +`sysbench`を使用してアップストリームにテストテーブルを作成し、完全インポート用のテストデータを生成します。テストデータを生成するには、以下の`sysbench`コマンドを実行します。 ```bash sysbench --test=oltp_insert --tables=4 --mysql-host=172.16.4.40 --mysql-port=3306 --mysql-user=root --mysql-db=dm_benchmark --db-driver=mysql --table-size=50000000 prepare @@ -84,7 +84,7 @@ mydumpers: > **注記：** > -> - マルチスレッドを使用して単一のテーブルから同時にデータをエクスポートするには、設定項目`mydumpers`のオプション`rows`使用します。これにより、データのエクスポートが高速化されます。 +> - マルチスレッドを使用して単一のテーブルから同時にデータをエクスポートするには、設定項目`mydumpers`のオプション`rows`を使用します。これにより、データのエクスポートが高速化されます。 > - 異なる構成でのパフォーマンスをテストするには、 `mysql-instances`構成の`loader-thread`と、 `mydumpers`構成項目の`rows`と`threads`調整できます。 #### テスト結果を取得する {#get-test-results} @@ -99,7 +99,7 @@ DM-worker のログを確認してください。1 `all data files have been fin #### テーブルを初期化する {#initialize-tables} -アップストリームにテスト テーブルを作成するには`sysbench`使用します。 +アップストリームにテスト テーブルを作成するには`sysbench`を使用します。 #### データ移行タスクを作成する {#create-a-data-migration-task} @@ -156,4 +156,4 @@ sysbench --test=oltp_insert --tables=4 --num-threads=32 --mysql-host=172.17.4.40 #### テスト結果を取得する {#get-test-results} -DMの移行ステータスを確認するには、コマンド`query-status`実行してください。DMの監視メトリクスを確認するには、Grafanaを使用してください。ここでの監視メトリクスとは、 `finished sqls jobs` （単位時間あたりに完了したジョブ数）およびその他の関連メトリクスを指します。詳細については、 [Binlog移行監視メトリクス](/dm/monitor-a-dm-cluster.md#binlog-replication)参照してください。 +DMの移行ステータスを確認するには、コマンド`query-status`を実行してください。DMの監視メトリクスを確認するには、Grafanaを使用してください。ここでの監視メトリクスとは、 `finished sqls jobs` （単位時間あたりに完了したジョブ数）およびその他の関連メトリクスを指します。詳細については、 [Binlog移行監視メトリクス](/dm/monitor-a-dm-cluster.md#binlog-replication)参照してください。 diff --git a/dm/dm-query-status.md b/dm/dm-query-status.md index 2383396674776..798e43d52b7db 100644 --- a/dm/dm-query-status.md +++ b/dm/dm-query-status.md @@ -11,7 +11,7 @@ summary: データ複製タスクのステータスを照会する方法を学 `query-status`以下の手順で使用することをお勧めします。 -1. `query-status`使用して、進行中の各タスクが正常な状態であるかどうかを確認します。 +1. `query-status`を使用して、進行中の各タスクが正常な状態であるかどうかを確認します。 2. タスクでエラーが発生した場合は、 `query-status `コマンドを使用して詳細なエラー情報を表示します。このコマンドの`` 、エラーが発生したタスクの名前を示します。 成功したクエリ結果は次のとおりです。 @@ -276,14 +276,14 @@ DM移行タスクのステータスは、DMワーカーに割り当てられた - 一時停止状態。 - サブタスクでエラーが発生した場合は、 `Paused`に切り替えられます。 - - サブタスクが`Running`状態のときに`pause-task`実行すると、タスクは`Paused`に切り替わります。 + - サブタスクが`Running`状態のときに`pause-task`を実行すると、タスクは`Paused`に切り替わります。 - サブタスクがこの状態にある場合、 `resume-task`コマンドを実行してタスクを再開できます。 - `Stopped` : - 停止状態。 - - サブタスクが`Running`または`Paused`状態のときに`stop-task`実行すると、タスクは`Stopped`に切り替わります。 - - サブタスクがこの状態にある場合、 `resume-task`使用してタスクを再開することはできません。 + - サブタスクが`Running`または`Paused`状態のときに`stop-task`を実行すると、タスクは`Stopped`に切り替わります。 + - サブタスクがこの状態にある場合、 `resume-task`を使用してタスクを再開することはできません。 - `Finished` : diff --git a/dm/dm-webui-guide.md b/dm/dm-webui-guide.md index f9e65fdcfc429..0af52ae2fb9d4 100644 --- a/dm/dm-webui-guide.md +++ b/dm/dm-webui-guide.md @@ -64,7 +64,7 @@ DMでは、移行タスクの各サブタスクは、フルダンプ -> フ 移行タスクに設定された移行ルールのステータスは**、「レプリケーションの詳細」**ページで確認できます。このページでは、タスク、ソース、データベース名によるクエリがサポートされています。 -クエリ結果には、アップストリーム テーブルとダウンストリーム テーブルの対応する情報が含まれるため、クエリ結果が多すぎるとページの応答が遅くなる可能性があるため、 `.*`使用するときは注意してください。 +クエリ結果には、アップストリーム テーブルとダウンストリーム テーブルの対応する情報が含まれるため、クエリ結果が多すぎるとページの応答が遅くなる可能性があるため、 `.*`を使用するときは注意してください。 ## クラスタ {#cluster} diff --git a/dm/feature-expression-filter.md b/dm/feature-expression-filter.md index 81067f7d2c4e0..2685cfcc8606b 100644 --- a/dm/feature-expression-filter.md +++ b/dm/feature-expression-filter.md @@ -9,6 +9,6 @@ summary: 増分データ移行では、SQL式を使用してbinlogイベント 増分データ移行プロセスでは、 [Binlogイベントをフィルタリングする](/filter-binlog-event.md)機能を使用して特定の種類のbinlogイベントをフィルタリングできます。例えば、アーカイブや監査の目的で、下流にデータを移行する際に`DELETE`イベントをフィルタリングできます。ただし、Binlogイベントフィルタでは、特定の行の`DELETE`のイベントをフィルタリングするかどうかを、よりきめ細かく判断することはできません。 -上記の問題を解決するため、DMはv2.0.5以降、増分移行中に`binlog value filter`使用したデータのフィルタリングをサポートしています。DMがサポートする`ROW`形式のbinlogには、binlogイベントのすべての列の値が含まれます。これらの値に基づいてSQL式を設定できます。SQL式が行の変更を`TRUE`と評価した場合、DMは行の変更を下流に移行しません。 +上記の問題を解決するため、DMはv2.0.5以降、増分移行中に`binlog value filter`を使用したデータのフィルタリングをサポートしています。DMがサポートする`ROW`形式のbinlogには、binlogイベントのすべての列の値が含まれます。これらの値に基づいてSQL式を設定できます。SQL式が行の変更を`TRUE`と評価した場合、DMは行の変更を下流に移行しません。 詳しい操作と実装については[SQL 式を使用して DML イベントをフィルタリングする](/filter-dml-event.md)参照してください。 diff --git a/dm/feature-online-ddl.md b/dm/feature-online-ddl.md index 72026224f846a..bfd17db681ab9 100644 --- a/dm/feature-online-ddl.md +++ b/dm/feature-online-ddl.md @@ -93,7 +93,7 @@ gh-ost で主に使用される SQL ステートメントとそれに対応す rename test._test4_gho to test.test4; ``` - - DMは`rename to _test4_del`を実行しません。3 `rename ghost_table to origin table`実行する場合、DMは以下の手順を実行します。 + - DMは`rename to _test4_del`を実行しません。3 `rename ghost_table to origin table`を実行する場合、DMは以下の手順を実行します。 - ステップ3でメモリに記録されたDDLを読み取ります - `ghost_table`と`ghost_schema` `origin_table`とそれに対応するスキーマに置き換えます @@ -183,7 +183,7 @@ pt-osc で主に使用される SQL 文とそれに対応する DM の操作は rename test._test4_new to test.test4; ``` - - DMは`rename to _test4_old`を実行しません。3 `rename ghost_table to origin table`実行する場合、DMは以下の手順を実行します。 + - DMは`rename to _test4_old`を実行しません。3 `rename ghost_table to origin table`を実行する場合、DMは以下の手順を実行します。 - ステップ2でメモリに記録されたDDLを読み取ります - `ghost_table`と`ghost_schema` `origin_table`とそれに対応するスキーマに置き換えます diff --git a/dm/handle-failed-ddl-statements.md b/dm/handle-failed-ddl-statements.md index abafa293ad40f..3600331968c39 100644 --- a/dm/handle-failed-ddl-statements.md +++ b/dm/handle-failed-ddl-statements.md @@ -23,9 +23,9 @@ summary: TiDB データ移行ツールを使用してデータを移行すると 移行中に、TiDB でサポートされていない DDL ステートメントがアップストリームで実行され、ダウンストリームに移行され、その結果、移行タスクが中断されます。 -- この DDL ステートメントがダウンストリーム TiDB でスキップされることが許容される場合は、 `binlog skip `使用してこの DDL ステートメントの移行をスキップし、移行を再開できます。 -- この DDL ステートメントを他の DDL ステートメントに置き換えても問題ない場合は、 `binlog replace `使用してこの DDL ステートメントを置き換え、移行を再開できます。 -- 他の DDL ステートメントがダウンストリーム TiDB に挿入されることが許容される場合は、 `binlog inject `使用して他の DDL ステートメントを挿入し、移行を再開できます。 +- この DDL ステートメントがダウンストリーム TiDB でスキップされることが許容される場合は、 `binlog skip `を使用してこの DDL ステートメントの移行をスキップし、移行を再開できます。 +- この DDL ステートメントを他の DDL ステートメントに置き換えても問題ない場合は、 `binlog replace `を使用してこの DDL ステートメントを置き換え、移行を再開できます。 +- 他の DDL ステートメントがダウンストリーム TiDB に挿入されることが許容される場合は、 `binlog inject `を使用して他の DDL ステートメントを挿入し、移行を再開できます。 ## コマンド {#commands} @@ -138,9 +138,9 @@ ALTER TABLE db1.tbl1 CHANGE c2 c2 DECIMAL (10, 3); ERROR 8200 (HY000): Unsupported modify column: can't change decimal column precision -実際の本番環境では、このDDL文が下流のTiDBで実行されない（つまり、元のテーブルスキーマが保持される）ことが許容されると仮定します。その場合、 `binlog skip `使用してこのDDL文をスキップし、移行を再開できます。手順は以下のとおりです。 +実際の本番環境では、このDDL文が下流のTiDBで実行されない（つまり、元のテーブルスキーマが保持される）ことが許容されると仮定します。その場合、 `binlog skip `を使用してこのDDL文をスキップし、移行を再開できます。手順は以下のとおりです。 -1. `binlog skip `実行して、現在失敗している DDL ステートメントをスキップします。 +1. `binlog skip `を実行して、現在失敗している DDL ステートメントをスキップします。 ```bash » binlog skip test @@ -159,7 +159,7 @@ ALTER TABLE db1.tbl1 CHANGE c2 c2 DECIMAL (10, 3); ] } -2. タスクのステータスを表示するには、 `query-status `実行します。 +2. タスクのステータスを表示するには、 `query-status `を実行します。 ```bash » query-status test @@ -242,7 +242,7 @@ SHOW CREATE TABLE shard_db.shard_table; ALTER TABLE `shard_db_*`.`shard_table_*` CHARACTER SET LATIN1 COLLATE LATIN1_DANISH_CI; ``` -このDDL文はTiDBでサポートされていないため、DMの移行タスクは中断されます。コマンド`query-status` `shard_db_1`実行すると、MySQLインスタンス1のテーブル`shard_table_1`とMySQLインスタンス`shard_table_1` `shard_db_2`以下のエラーが報告されます。 +このDDL文はTiDBでサポートされていないため、DMの移行タスクは中断されます。コマンド`query-status` `shard_db_1`を実行すると、MySQLインスタンス1のテーブル`shard_table_1`とMySQLインスタンス`shard_table_1` `shard_db_2`以下のエラーが報告されます。 { "Message": "cannot track DDL: ALTER TABLE `shard_db_1`.`shard_table_1` CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI", @@ -256,9 +256,9 @@ ALTER TABLE `shard_db_*`.`shard_table_*` CHARACTER SET LATIN1 COLLATE LATIN1_DAN "RawCause": "[ddl:8200]Unsupported modify charset from latin1 to utf8" } -実際の本番環境では、このDDL文が下流のTiDBで実行されない（つまり、元のテーブルスキーマが保持される）ことが許容されると仮定します。その場合、 `binlog skip `使用してこのDDL文をスキップし、移行を再開できます。手順は以下のとおりです。 +実際の本番環境では、このDDL文が下流のTiDBで実行されない（つまり、元のテーブルスキーマが保持される）ことが許容されると仮定します。その場合、 `binlog skip `を使用してこのDDL文をスキップし、移行を再開できます。手順は以下のとおりです。 -1. `binlog skip `実行して、MySQL インスタンス 1 と 2 で現在失敗している DDL ステートメントをスキップします。 +1. `binlog skip `を実行して、MySQL インスタンス 1 と 2 で現在失敗している DDL ステートメントをスキップします。 ```bash » binlog skip test @@ -322,7 +322,7 @@ ALTER TABLE `shard_db_*`.`shard_table_*` CHARACTER SET LATIN1 COLLATE LATIN1_DAN ] } -4. タスクのステータスを表示するには`query-status `使用します。 +4. タスクのステータスを表示するには`query-status `を使用します。 ```bash » query-status test @@ -482,7 +482,7 @@ ALTER TABLE `db1`.`tbl1` ADD COLUMN new_col INT UNIQUE; ] } -2. タスクのステータスを表示するには`query-status `使用します。 +2. タスクのステータスを表示するには`query-status `を使用します。 ```bash » query-status test @@ -617,7 +617,7 @@ ALTER TABLE `shard_db_*`.`shard_table_*` ADD COLUMN new_col INT UNIQUE; ] } -2. `query-status `使用してタスクのステータス`shard_table_2` `shard_db_1` `shard_table_2` `shard_db_2`された次のエラーを確認できます。 +2. `query-status `を使用してタスクのステータス`shard_table_2` `shard_db_1` `shard_table_2` `shard_db_2`された次のエラーを確認できます。 { "Message": "detect inconsistent DDL sequence from source ... ddls: [ALTER TABLE `shard_db`.`tb` ADD COLUMN `new_col` INT UNIQUE KEY] source: `shard_db_1`.`shard_table_2`], right DDL sequence should be ..." @@ -665,7 +665,7 @@ ALTER TABLE `shard_db_*`.`shard_table_*` ADD COLUMN new_col INT UNIQUE; ] } -4. タスクのステータスを表示するには`query-status `使用します。 +4. タスクのステータスを表示するには`query-status `を使用します。 ```bash » query-status test diff --git a/dm/maintain-dm-using-tiup.md b/dm/maintain-dm-using-tiup.md index 5b3fe240d2216..409b7d4daa6e4 100644 --- a/dm/maintain-dm-using-tiup.md +++ b/dm/maintain-dm-using-tiup.md @@ -77,7 +77,7 @@ tiup dm list tiup dm start prod-cluster ``` -クラスターの名前を忘れた場合は、 `tiup dm list`実行してクラスター リストを表示します。 +クラスターの名前を忘れた場合は、 `tiup dm list`を実行してクラスター リストを表示します。 ## クラスターのステータスを確認する {#check-the-cluster-status} @@ -101,7 +101,7 @@ tiup dm display prod-cluster 172.19.0.101:3000 grafana 172.19.0.101 3000 linux/x86_64 Up - /home/tidb/deploy/grafana-3000 172.19.0.101:9090 prometheus 172.19.0.101 9090 linux/x86_64 Up /home/tidb/data/prometheus-9090 /home/tidb/deploy/prometheus-9090 -`Status`列では、 `Up`または`Down`使用して、サービスが正常に実行されているかどうかを示します。 +`Status`列では、 `Up`または`Down`を使用して、サービスが正常に実行されているかどうかを示します。 DMマスターコンポーネントの場合、ステータスに`|L`が付加され、DMマスターノードがLeaderであることを示します。DMワーカーコンポーネントの場合、 `Free`現在のDMワーカーノードがアップストリームにバインドされていないことを示します。 @@ -112,7 +112,7 @@ DMマスターコンポーネントの場合、ステータスに`|L`が付加 クラスターをスケールインすると、DM マスター コンポーネントと DM ワーカー コンポーネントに対する DM 操作が次の順序で実行されます。 1. コンポーネントプロセスを停止します。 -2. DM-master の API を呼び出して`member`削除します。 +2. DM-master の API を呼び出して`member`を削除します。 3. ノードに関連するデータ ファイルをクリーンアップします。 スケールイン コマンドの基本的な使用法: @@ -155,7 +155,7 @@ tiup dm scale-in prod-cluster -N 172.16.5.140:8262 tiup dm scale-out prod-cluster scale.yaml ``` - コマンドを実行した後、 `tiup dm display prod-cluster`実行してスケールアウトされたクラスターのステータスを確認できます。 + コマンドを実行した後、 `tiup dm display prod-cluster`を実行してスケールアウトされたクラスターのステータスを確認できます。 ## ローリングアップグレード {#rolling-upgrade} @@ -163,7 +163,7 @@ tiup dm scale-in prod-cluster -N 172.16.5.140:8262 > > v2.0.5 以降、dmctl は[データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション](/dm/dm-export-import-config.md)サポートします。 > -> アップグレード前に、 `config export`使用してクラスターの設定ファイルをエクスポートできます。アップグレード後に以前のバージョンにダウングレードする必要がある場合は、まず以前のクラスターを再デプロイし、 `config import`使用して以前の設定ファイルをインポートできます。 +> アップグレード前に、 `config export`を使用してクラスターの設定ファイルをエクスポートできます。アップグレード後に以前のバージョンにダウングレードする必要がある場合は、まず以前のクラスターを再デプロイし、 `config import`を使用して以前の設定ファイルをインポートできます。 > > v2.0.5 より前のクラスターの場合は、dmctl (>= v2.0.5 かつ < v8.0.0) を使用して、データ ソースおよびタスク構成ファイルをエクスポートおよびインポートできます。 > @@ -191,7 +191,7 @@ tiup dm upgrade prod-cluster ${version} tiup dm edit-config prod-cluster ``` -TiUP DMは設定ファイルをviエディタで開きます。他のエディタを使用する場合は、環境変数`EDITOR`使用してエディタをカスタマイズします（例： `export EDITOR=nano` ）。ファイルの編集後、変更を保存します。新しい設定をクラスターに適用するには、次のコマンドを実行します。 +TiUP DMは設定ファイルをviエディタで開きます。他のエディタを使用する場合は、環境変数`EDITOR`を使用してエディタをカスタマイズします（例： `export EDITOR=nano` ）。ファイルの編集後、変更を保存します。新しい設定をクラスターに適用するには、次のコマンドを実行します。 ```bash tiup dm reload prod-cluster @@ -243,11 +243,11 @@ tiup dm patch prod-cluster /tmp/dm--hotfix.tar.gz -N 172.16.4.5:8261 > > - TiUP は、DM 1.0 クラスターへの DM Portalコンポーネントのインポートをサポートしていません。 > - インポートする前に元のクラスターを停止する必要があります。 -> - 2.0 にアップグレードする必要があるタスクでは`stop-task`実行しないでください。 +> - 2.0 にアップグレードする必要があるタスクでは`stop-task`を実行しないでください。 > - TiUP は、v2.0.0-rc.2 以降のバージョンの DM クラスターへのインポートのみをサポートします。 > - `import`コマンドは、DM 1.0 クラスターから新しい DM 2.0 クラスターにデータをインポートするために使用されます。既存の DM 2.0 クラスターに DM 移行タスクをインポートする必要がある場合は、 [TiDB データ移行を v1.0.x から v2.0+ に手動でアップグレードする](/dm/manually-upgrade-dm-1.0-to-2.0.md)参照してください。 > - 一部のコンポーネントのデプロイメントディレクトリは、元のクラスタのものと異なります。詳細を確認するには、 `display`コマンドを実行してください。 -> - インポートする前に`tiup update --self && tiup update dm`実行して、 TiUP DMコンポーネントが最新バージョンであることを確認します。 +> - インポートする前に`tiup update --self && tiup update dm`を実行して、 TiUP DMコンポーネントが最新バージョンであることを確認します。 > - インポート後、クラスターにはDMマスターノードが1つだけ存在します。DMマスターをスケールアウトするには、 [クラスターをスケールアウトする](#scale-out-a-cluster)を参照してください。 TiUPがリリースされる前は、DMクラスターのデプロイにはDM-Ansibleがよく使用されていました。DM-AnsibleによってデプロイされたDM 1.0クラスターをTiUPで引き継ぐには、 `import`コマンドを使用します。 @@ -258,7 +258,7 @@ TiUPがリリースされる前は、DMクラスターのデプロイにはDM-An tiup dm import --dir=/path/to/dm-ansible --cluster-version ${version} ``` -`tiup list dm-master`実行すると、 TiUPでサポートされている最新のクラスター バージョンが表示されます。 +`tiup list dm-master`を実行すると、 TiUPでサポートされている最新のクラスター バージョンが表示されます。 `import`コマンドを使用するプロセスは次のとおりです。 @@ -313,7 +313,7 @@ Flags: --sudo use root permissions (default false) ``` -たとえば、すべての DM ノードで`ls /tmp`実行するには、次のコマンドを実行します。 +たとえば、すべての DM ノードで`ls /tmp`を実行するには、次のコマンドを実行します。 ```bash tiup dm exec prod-cluster --command='ls /tmp' @@ -333,7 +333,7 @@ dmctlのバージョンを指定します。このコマンドを実行する前 tiup dmctl:${version} [args] -以前のdmctlコマンドでソースを追加するには`dmctl --master-addr master1:8261 operate-source create /tmp/source1.yml`使用します。dmctlがTiUPに統合された後は、コマンドは以下のようになります。 +以前のdmctlコマンドでソースを追加するには`dmctl --master-addr master1:8261 operate-source create /tmp/source1.yml`を使用します。dmctlがTiUPに統合された後は、コマンドは以下のようになります。 ```bash tiup dmctl --master-addr master1:8261 operate-source create /tmp/source1.yml diff --git a/dm/manually-handling-sharding-ddl-locks.md b/dm/manually-handling-sharding-ddl-locks.md index f8771f47b8b59..b2d45a5ef76f8 100644 --- a/dm/manually-handling-sharding-ddl-locks.md +++ b/dm/manually-handling-sharding-ddl-locks.md @@ -11,14 +11,14 @@ DMはシャーディングDDLロックを使用して、操作が正しい順序 > > - このドキュメントは、悲観的調整モードでのシャーディング DDL ロックの処理にのみ適用されます。 > - このドキュメントの「コマンドの使用法」セクションに記載されているコマンドは対話型モードです。コマンドラインモードでは、エラーレポートを回避するためにエスケープ文字を追加する必要があります。 -> - コマンドによってもたらされる可能性のある影響を完全に認識し、それを受け入れられる場合を除き、 `shard-ddl-lock unlock`使用しないでください。 +> - コマンドによってもたらされる可能性のある影響を完全に認識し、それを受け入れられる場合を除き、 `shard-ddl-lock unlock`を使用しないでください。 > - 異常な DDL ロックを手動で処理する前に、DM [シャードマージの原則](/dm/feature-shard-merge-pessimistic.md#principles)必ず読んでください。 ## 指示 {#command} ### `shard-ddl-lock` {#shard-ddl-lock} -このコマンドを使用すると、DDLロックを表示し、DMマスターに指定されたDDLロックの解放を要求できます。このコマンドはDM v6.0以降でのみサポートされています。それより前のバージョンでは、コマンド`show-ddl-locks`と`unlock-ddl-locks`使用する必要があります。 +このコマンドを使用すると、DDLロックを表示し、DMマスターに指定されたDDLロックの解放を要求できます。このコマンドはDM v6.0以降でのみサポートされています。それより前のバージョンでは、コマンド`show-ddl-locks`と`unlock-ddl-locks`を使用する必要があります。 ```bash shard-ddl-lock -h @@ -48,7 +48,7 @@ shard-ddl-lock -h ### `shard-ddl-lock [task] [flags]` {#shard-ddl-lock-task-flags} -`shard-ddl-lock [task] [flags]`使用すると、現在の DM マスターの DDL ロック情報を表示できます。例: +`shard-ddl-lock [task] [flags]`を使用すると、現在の DM マスターの DDL ロック情報を表示できます。例: ```bash shard-ddl-lock test @@ -149,7 +149,7 @@ shard-ddl-lock unlock test-`shard_db`.`shard_table` > **注記：** > -> シャーディング DDL イベントの移行プロセス中でないときに一部の DM ワーカーをオフラインにする必要がある場合、より適切な解決策は、まず`stop-task`使用して実行中のタスクを停止し、DM ワーカーをオフラインにして、タスク構成ファイルから対応する構成情報を削除し、最後に`start-task`と新しいタスク構成を使用して移行タスクを再開することです。 +> シャーディング DDL イベントの移行プロセス中でないときに一部の DM ワーカーをオフラインにする必要がある場合、より適切な解決策は、まず`stop-task`を使用して実行中のタスクを停止し、DM ワーカーをオフラインにして、タスク構成ファイルから対応する構成情報を削除し、最後に`start-task`と新しいタスク構成を使用して移行タスクを再開することです。 #### 手動ソリューション {#manual-solution} @@ -189,7 +189,7 @@ MySQLとDMの操作プロセスは次のとおりです。 2. DM-worker は、受信した`mysql-replica-01`の 2 つのシャード テーブルの DDL 情報を DM-master に送信し、DM-master は対応する DDL ロックを作成します。 -3. 現在の DDL ロックの情報を確認するには、 `shard-ddl-lock`使用します。 +3. 現在の DDL ロックの情報を確認するには、 `shard-ddl-lock`を使用します。 ```bash » shard-ddl-lock test @@ -222,9 +222,9 @@ MySQLとDMの操作プロセスは次のとおりです。 - 返される結果`unsynced` by `shard-ddl-lock`には常に`mysql-replica-02`の情報が含まれています。 -6. `shard-ddl-lock unlock`使用して`DM-master`要求し、DDL ロックをアクティブにロック解除します。 +6. `shard-ddl-lock unlock`を使用して`DM-master`要求し、DDL ロックをアクティブにロック解除します。 - - DDL ロックの所有者がオフラインになった場合は、パラメータ`--owner`使用して、別の DM ワーカーを新しい所有者として指定し、DDL を実行できます。 + - DDL ロックの所有者がオフラインになった場合は、パラメータ`--owner`を使用して、別の DM ワーカーを新しい所有者として指定し、DDL を実行できます。 - いずれかの MySQL ソースがエラーを報告した場合、 `result`が`false`に設定され、この時点で、各 MySQL ソースのエラーが許容範囲内であり、期待どおりであるかどうかを慎重に確認する必要があります。 ```bash @@ -235,7 +235,7 @@ MySQLとDMの操作プロセスは次のとおりです。 "result": true, "msg": "" -7. `shard-ddl-lock`使用して、DDL ロックが正常に解除されたかどうかを確認します。 +7. `shard-ddl-lock`を使用して、DDL ロックが正常に解除されたかどうかを確認します。 ```bash » shard-ddl-lock test @@ -262,21 +262,21 @@ MySQLとDMの操作プロセスは次のとおりです。 +-------------+--------------------------------------------------+ ``` -9. `query-status`使用して、移行タスクが正常かどうかを確認します。 +9. `query-status`を使用して、移行タスクが正常かどうかを確認します。 #### インパクト {#impact} -`shard-ddl-lock unlock`使用して手動でロックを解除した後、タスク構成情報に含まれるオフライン MySQL ソースを処理しないと、次のシャーディング DDL イベントを受信したときにロックを自動的に移行できない可能性があります。 +`shard-ddl-lock unlock`を使用して手動でロックを解除した後、タスク構成情報に含まれるオフライン MySQL ソースを処理しないと、次のシャーディング DDL イベントを受信したときにロックを自動的に移行できない可能性があります。 したがって、DDL ロックを手動でロック解除した後、次の操作を実行する必要があります。 -1. 実行中のタスクを停止するには`stop-task`使用します。 +1. 実行中のタスクを停止するには`stop-task`を使用します。 2. タスク構成ファイルを更新し、構成ファイルからオフライン MySQL ソースの関連情報を削除します。 3. `start-task`と新しいタスク構成ファイルを使用してタスクを再起動します。 > **注記：** > -> `shard-ddl-lock unlock`実行した後、オフラインになった MySQL ソースが再ロードされ、DM ワーカーがシャード テーブルのデータを移行しようとすると、データとダウンストリーム テーブル構造の間で一致エラーが発生する可能性があります。 +> `shard-ddl-lock unlock`を実行した後、オフラインになった MySQL ソースが再ロードされ、DM ワーカーがシャード テーブルのデータを移行しようとすると、データとダウンストリーム テーブル構造の間で一致エラーが発生する可能性があります。 ### シナリオ2: DDLロック解除プロセス中に一部のDMワーカーが異常停止するか、ネットワーク障害が発生する {#scenario-2-some-dm-workers-stop-abnormally-or-the-network-failure-occurs-during-the-ddl-unlocking-process} @@ -303,7 +303,7 @@ MySQLとDMの操作プロセスは次のとおりです。 操作プロセスは次のとおりです。 -1. `shard-ddl-lock`使用して、 DDL の対応するロックが`DM-master`に存在するかどうかを確認します。 +1. `shard-ddl-lock`を使用して、 DDL の対応するロックが`DM-master`に存在するかどうかを確認します。 `synced`状態にあるのは`mysql-replica-02`だけです。 @@ -332,7 +332,7 @@ MySQLとDMの操作プロセスは次のとおりです。 } ``` -2. `shard-ddl-lock`使用して`DM-master`ロックを解除するよう依頼します。 +2. `shard-ddl-lock`を使用して`DM-master`ロックを解除するよう依頼します。 - ロック解除プロセス中に、オーナーはダウンストリームへのDDL操作を再度実行しようとします（再起動前の元のオーナーは、ダウンストリームへのDDL操作を一度実行しています）。DDL操作が複数回実行可能であることを確認してください。 @@ -344,9 +344,9 @@ MySQLとDMの操作プロセスは次のとおりです。 } ``` -3. `shard-ddl-lock`使用して、DDL ロックが正常に解除されたかどうかを確認します。 +3. `shard-ddl-lock`を使用して、DDL ロックが正常に解除されたかどうかを確認します。 -4. `query-status`使用して、移行タスクが正常かどうかを確認します。 +4. `query-status`を使用して、移行タスクが正常かどうかを確認します。 #### インパクト {#impact} diff --git a/dm/quick-start-with-dm.md b/dm/quick-start-with-dm.md index 21860767f77ab..9cc856ce8ced4 100644 --- a/dm/quick-start-with-dm.md +++ b/dm/quick-start-with-dm.md @@ -23,7 +23,7 @@ summary: TiUP Playground を使用してデータ移行環境をすばやくセ > **注記：** > - > 既にTiUPがインストールされている場合は、フラグ`--dm-master`と`--dm-worker`使用するには、v1.16.1 以降にアップデートされていることを確認してください。現在のバージョンを確認するには、次のコマンドを実行します。 + > 既にTiUPがインストールされている場合は、フラグ`--dm-master`と`--dm-worker`を使用するには、v1.16.1 以降にアップデートされていることを確認してください。現在のバージョンを確認するには、次のコマンドを実行します。 > > ```shell > tiup --version diff --git a/dm/relay-log.md b/dm/relay-log.md index 8046effb439ed..a54b1321d0568 100644 --- a/dm/relay-log.md +++ b/dm/relay-log.md @@ -158,7 +158,7 @@ query-status -s mysql-replica-01 ### リレーログの一時停止と再開 {#pause-and-resume-relay-log} -コマンド`pause-relay`リレーログのプル処理を一時停止し、コマンド`resume-relay`で再開できます。これらの2つのコマンドを実行する際は、上流データソースの`source-id`指定する必要があります。以下の例をご覧ください。 +コマンド`pause-relay`リレーログのプル処理を一時停止し、コマンド`resume-relay`で再開できます。これらの2つのコマンドを実行する際は、上流データソースの`source-id`を指定する必要があります。以下の例をご覧ください。 ```bash pause-relay -s mysql-replica-01 -s mysql-replica-02 @@ -342,8 +342,8 @@ purge: - 有効なローカルリレーログが存在しないが、アップストリームデータソース構成ファイルで`relay-binlog-name`または`relay-binlog-gtid`指定されている場合: - - 非 GTID モードでは、 `relay-binlog-name`指定すると、DM ワーカーは指定されたbinlogファイルから移行を開始します。 - - GTID モードでは、 `relay-binlog-gtid`指定すると、DM ワーカーは指定された GTID から移行を開始します。 + - 非 GTID モードでは、 `relay-binlog-name`を指定すると、DM ワーカーは指定されたbinlogファイルから移行を開始します。 + - GTID モードでは、 `relay-binlog-gtid`を指定すると、DM ワーカーは指定された GTID から移行を開始します。 - 有効なローカルリレーログがなく、DM 構成ファイルに`relay-binlog-name`または`relay-binlog-gtid`指定されていない場合: diff --git a/dm/shard-merge-best-practices.md b/dm/shard-merge-best-practices.md index a880affb0e779..20c0f55aaed57 100644 --- a/dm/shard-merge-best-practices.md +++ b/dm/shard-merge-best-practices.md @@ -131,13 +131,13 @@ CREATE TABLE `tbl_multi_pk` ( 1. アップストリームのシャード テーブルで実行されたすべてのシャーディング DDL の調整が完了するまで待機します。 -2. データ移行タスクを停止するには、 `stop-task`実行します。 +2. データ移行タスクを停止するには、 `stop-task`を実行します。 3. アップストリームに新しいシャード テーブルを作成します。 4. `task.yaml`ファイル内の構成で、新しく追加されたシャード テーブルを他の既存のシャード テーブルと 1 つのダウンストリーム テーブルにマージできることを確認します。 -5. タスクを開始するには`start-task`実行します。 +5. タスクを開始するには`start-task`を実行します。 6. 実行`query-status` 、データ移行タスクが正常に処理されたかどうか、および上流のデータがすでにマージされて下流のデータベースに移行されているかどうかを確認します。 @@ -147,17 +147,17 @@ CREATE TABLE `tbl_multi_pk` ( 1. シャード化されたテーブルを削除し、 [`SHOW BINLOG EVENTS`](https://dev.mysql.com/doc/refman/8.0/en/show-binlog-events.html)実行して、 binlogイベント内の`DROP TABLE`ステートメントに対応する`End_log_pos`を取得し、それを*Pos-M*としてマークします。 -2. `query-status`実行して、DMによって処理されたbinlogイベントに対応する位置（ `syncerBinlog` ）を取得し、それを*Pos-S*としてマークします。 +2. `query-status`を実行して、DMによって処理されたbinlogイベントに対応する位置（ `syncerBinlog` ）を取得し、それを*Pos-S*としてマークします。 3. *Pos-S*が*Pos-M*より大きい場合、DM が`DROP TABLE`のステートメントをすべて処理し、ドロップ前のテーブルのデータが下流に移行されているため、後続の操作を実行できることを意味します。それ以外の場合は、DM がデータの移行を完了するまで待機してください。 -4. タスクを停止するには`stop-task`実行します。 +4. タスクを停止するには`stop-task`を実行します。 5. `task.yaml`ファイル内の構成で、アップストリーム内の削除されたシャード テーブルが無視されることを確認します。 -6. タスクを開始するには`start-task`実行します。 +6. タスクを開始するには`start-task`を実行します。 -7. 実行`query-status`実行して、データ移行タスクが正常に処理されたかどうかを確認します。 +7. 実行`query-status`を実行して、データ移行タスクが正常に処理されたかどうかを確認します。 ## 速度制限と交通流制御 {#speed-limits-and-traffic-flow-control} diff --git a/dm/table-selector.md b/dm/table-selector.md index a9ab3caca35de..def7d359c98e0 100644 --- a/dm/table-selector.md +++ b/dm/table-selector.md @@ -9,7 +9,7 @@ summary: データ移行のテーブル ルーティング、 binlogイベント ## ワイルドカード文字 {#wildcard-character} -テーブルセレクターは`schema-pattern`で次の 2 つのワイルドカード文字`table-pattern`使用します。 +テーブルセレクターは`schema-pattern`で次の 2 つのワイルドカード文字`table-pattern`を使用します。 - アスタリスク文字（ `*` 、「スター」とも呼ばれる） diff --git a/dm/usage-scenario-master-slave-switch.md b/dm/usage-scenario-master-slave-switch.md index 7cce9a31bb1bd..0535b2a0f0fd1 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 ワーカー接続は、同じプライマリ - セカンダリ移行クラスター内のインスタンスにのみ切り替えることができます。 > - 新しく接続する MySQL インスタンスには、DM-worker に必要なbinlogが必要です。 -> - DM ワーカーは GTID セット モードで動作する必要があります。つまり、対応するソース構成ファイルで`enable-gtid: true`指定する必要があります。 +> - DM ワーカーは 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)を参照してください。 @@ -32,9 +32,9 @@ DM-worker が仮想 IP (VIP) を介してアップストリーム MySQL イン 4. 以下の条件が満たされていることを確認してください。満たされていない場合、DM-work 接続を新しい MySQL インスタンスに切り替えることはできません。 - `gtid-S`には`gtid-P`含まれます。4 `gtid-P`空になる場合があります。 - `gtid-E`には`gtid-S`含まれます。 -5. `pause-task`使用すると、データ移行の実行中のすべてのタスクが一時停止されます。 +5. `pause-task`を使用すると、データ移行の実行中のすべてのタスクが一時停止されます。 6. 新しい MySQL インスタンスに直接送信されるように VIP を変更します。 -7. 前の移行タスクを再開するには、 `resume-task`使用します。 +7. 前の移行タスクを再開するには、 `resume-task`を使用します。 ## DM-workerが接続する上流のMySQLインスタンスのアドレスを変更する {#change-the-address-of-the-upstream-mysql-instance-that-dm-worker-connects-to} @@ -46,7 +46,7 @@ DM-worker 設定を変更して、DM-worker をアップストリーム内の新 4. 以下の条件が満たされていることを確認してください。満たされていない場合、DM-work 接続を新しい MySQL インスタンスに切り替えることはできません。 - `gtid-S`には`gtid-P`含まれます。4 `gtid-P`空になる場合があります。 - `gtid-E`には`gtid-S`含まれます。 -5. `stop-task`使用すると、データ移行の実行中のタスクがすべて停止します。 +5. `stop-task`を使用すると、データ移行の実行中のタスクがすべて停止します。 6. `operator-source stop`コマンドを使用して、古い MySQL インスタンスのアドレスに対応するソース構成を DM クラスターから削除します。 7. ソース構成ファイル内の MySQL インスタンスのアドレスを更新し、 `operate-source create`コマンドを使用して DM クラスターに新しいソース構成を再ロードします。 -8. 移行タスクを再開するには`start-task`使用します。 +8. 移行タスクを再開するには`start-task`を使用します。 diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index 44d182539271f..67a86f3296911 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -369,7 +369,7 @@ TiDBのプライマリクラスタとセカンダリクラスタを再構築す プライマリ/セカンダリDRシナリオでは、セカンダリクラスタを読み取り専用クラスタとして使用し、レイテンシに影響されないクエリを実行するのが一般的です。TiDBも、プライマリ/セカンダリDRソリューションにおいてこの機能を提供しています。 -変更フィードを作成する際に、構成ファイルで同期ポイント機能を有効にします。すると、変更フィードは定期的に（ `sync-point-interval`タイミングで）、セカンダリクラスタ上で`SET GLOBAL tidb_external_ts = @@tidb_current_ts`実行することにより、セカンダリクラスタに複製された一貫性のあるスナップショットポイントを設定します。 +変更フィードを作成する際に、構成ファイルで同期ポイント機能を有効にします。すると、変更フィードは定期的に（ `sync-point-interval`タイミングで）、セカンダリクラスタ上で`SET GLOBAL tidb_external_ts = @@tidb_current_ts`を実行することにより、セカンダリクラスタに複製された一貫性のあるスナップショットポイントを設定します。 セカンダリクラスタからデータを照会するには、ビジネスアプリケーションで`SET GLOBAL|SESSION tidb_enable_external_ts_read = ON;`設定します。そうすることで、プライマリクラスタとトランザクション的に整合性のあるデータを取得できます。 diff --git a/dynamic-config.md b/dynamic-config.md index d0fd7c54a36ee..20bf4b14466b1 100644 --- a/dynamic-config.md +++ b/dynamic-config.md @@ -53,8 +53,8 @@ show config where type='tikv' and name='log.level' > **注記：** > -> - TiKV設定項目を動的に変更すると、TiKV設定ファイルは自動的に更新されます。ただし、 `tiup edit-config`実行して対応する設定項目も変更する必要があります。そうしないと、 `upgrade`や`reload`などの操作によって変更内容が上書きされてしまいます。設定項目の変更方法の詳細については、 [TiUPを使用して構成を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)を参照してください。 -> - `tiup edit-config`実行した後、 `tiup reload`を実行する必要はありません。 +> - TiKV設定項目を動的に変更すると、TiKV設定ファイルは自動的に更新されます。ただし、 `tiup edit-config`を実行して対応する設定項目も変更する必要があります。そうしないと、 `upgrade`や`reload`などの操作によって変更内容が上書きされてしまいます。設定項目の変更方法の詳細については、 [TiUPを使用して構成を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)を参照してください。 +> - `tiup edit-config`を実行した後、 `tiup reload`を実行する必要はありません。 `set config`ステートメントを使用すると、インスタンス アドレスまたはコンポーネントタイプに応じて、単一のインスタンスの構成またはすべてのインスタンスの構成を変更できます。 @@ -103,7 +103,7 @@ show warnings; 1 row in set (0.00 sec) ``` -バッチ変更はアトミック性を保証するものではありません。一部のインスタンスでは変更が成功し、他のインスタンスでは失敗する可能性があります。1 `set tikv key=val`使用して TiKV クラスター全体の設定を変更すると、一部のインスタンスで変更が失敗する可能性があります。3 `show warnings`使用して結果を確認できます。 +バッチ変更はアトミック性を保証するものではありません。一部のインスタンスでは変更が成功し、他のインスタンスでは失敗する可能性があります。1 `set tikv key=val`を使用して TiKV クラスター全体の設定を変更すると、一部のインスタンスで変更が失敗する可能性があります。3 `show warnings`を使用して結果を確認できます。 一部の変更が失敗した場合は、対応するステートメントを再実行するか、失敗したインスタンスを個別に変更する必要があります。ネットワークの問題やマシンの障害により一部のTiKVインスタンスにアクセスできない場合は、復旧後にこれらのインスタンスを変更してください。 @@ -225,9 +225,9 @@ show warnings; | `storage.scheduler-worker-pool-size` | スケジューラスレッドプール内のスレッド数 | | `import.num-threads` | 復元またはインポート RPC 要求を処理するスレッドの数 (動的な変更は v8.1.2 以降でサポートされます) | | `backup.num-threads` | バックアップ スレッドの数 (v4.0.3 以降でサポート) | -| `split.qps-threshold` | リージョンで`load-base-split`実行するためのしきい値。リージョンの読み取りリクエストのQPSが10秒連続で`qps-threshold`超える場合、このリージョンは分割される必要があります。 | -| `split.byte-threshold` | リージョンで`load-base-split`実行するためのしきい値。リージョンの読み取りリクエストのトラフィックが10秒間連続して`byte-threshold`を超える場合、このリージョンは分割されます。 | -| `split.region-cpu-overload-threshold-ratio` | リージョンで`load-base-split`実行するためのしきい値。リージョンの統合読み取りプールのCPU使用率が10秒連続で`region-cpu-overload-threshold-ratio`を超えた場合、このリージョンは分割されます。(v6.2.0以降でサポート) | +| `split.qps-threshold` | リージョンで`load-base-split`を実行するためのしきい値。リージョンの読み取りリクエストのQPSが10秒連続で`qps-threshold`超える場合、このリージョンは分割される必要があります。 | +| `split.byte-threshold` | リージョンで`load-base-split`を実行するためのしきい値。リージョンの読み取りリクエストのトラフィックが10秒間連続して`byte-threshold`を超える場合、このリージョンは分割されます。 | +| `split.region-cpu-overload-threshold-ratio` | リージョンで`load-base-split`を実行するためのしきい値。リージョンの統合読み取りプールのCPU使用率が10秒連続で`region-cpu-overload-threshold-ratio`を超えた場合、このリージョンは分割されます。(v6.2.0以降でサポート) | | `split.split-balance-score` | `load-base-split`というパラメータは、2つの分割されたリージョンの負荷が可能な限り均等になるようにします。値が小さいほど、負荷は均等になります。ただし、値が小さすぎると分割が失敗する可能性があります。 | | `split.split-contained-score` | パラメータは`load-base-split`です。値が小さいほど、リージョン分割後のリージョン間アクセス数が少なくなります。 | | `cdc.min-ts-interval` | 解決されたTSが転送される時間間隔 | @@ -337,7 +337,7 @@ Query OK, 0 rows affected (0.01 sec) 次の例は、 `tidb_slow_log_threshold`変数を使用して`slow-threshold`動的に変更する方法を示しています。 -デフォルト値`slow-threshold`は 300 ミリ秒です。 `tidb_slow_log_threshold`使用すると 200 ミリ秒に設定できます。 +デフォルト値`slow-threshold`は 300 ミリ秒です。 `tidb_slow_log_threshold`を使用すると 200 ミリ秒に設定できます。 ```sql set tidb_slow_log_threshold = 200; @@ -378,7 +378,7 @@ select @@tidb_slow_log_threshold; 現在、システム変数[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610)使用してTiFlash構成`max_threads`を変更できます。この変数は、 TiFlashが要求を実行するための最大同時実行性を指​​定します。 -デフォルト値は`tidb_max_tiflash_threads` `-1` 、このシステム変数は無効であり、 TiFlash設定ファイルの設定に依存することを示します。 `tidb_max_tiflash_threads`使用すると、 `max_threads`から 10 に設定できます。 +デフォルト値は`tidb_max_tiflash_threads` `-1` 、このシステム変数は無効であり、 TiFlash設定ファイルの設定に依存することを示します。 `tidb_max_tiflash_threads`を使用すると、 `max_threads`から 10 に設定できます。 ```sql set tidb_max_tiflash_threads = 10; diff --git a/ecosystem-tool-user-guide.md b/ecosystem-tool-user-guide.md index 0f86e8e642c23..ae39c10b543d3 100644 --- a/ecosystem-tool-user-guide.md +++ b/ecosystem-tool-user-guide.md @@ -96,7 +96,7 @@ TiDB Lightningの基本は次のとおりです。 > **注記：** > -> Loaderツールはメンテナンスされなくなりました。Loaderに関連するシナリオでは、代わりに`Logical Import Mode`使用することをお勧めします。 +> Loaderツールはメンテナンスされなくなりました。Loaderに関連するシナリオでは、代わりに`Logical Import Mode`を使用することをお勧めします。 ### バックアップと復元 - Backup & Restore (BR) {#backup-and-restore-backup-x26-restore-br} diff --git a/enable-tls-between-components.md b/enable-tls-between-components.md index 542c1180e5819..d2f94f4b3d614 100644 --- a/enable-tls-between-components.md +++ b/enable-tls-between-components.md @@ -151,7 +151,7 @@ summary: TiDB コンポーネント間の TLS 認証を有効にする方法を > **注記：** > -> - v8.4.0以降、PD構成項目`cert-allowed-cn`複数の値をサポートします。必要に応じて、TiDB用構成項目`cluster-verify-cn`とその他のコンポーネント用構成項目`cert-allowed-cn`に、複数の`Common Name`設定できます。TiUPはコンポーネントのステータスを照会する際に別の識別子を使用することに注意してください。例えば、クラスター名が`test`の場合、 TiUPは`Common Name`として`test-client`使用します。 +> - v8.4.0以降、PD構成項目`cert-allowed-cn`複数の値をサポートします。必要に応じて、TiDB用構成項目`cluster-verify-cn`とその他のコンポーネント用構成項目`cert-allowed-cn`に、複数の`Common Name`設定できます。TiUPはコンポーネントのステータスを照会する際に別の識別子を使用することに注意してください。例えば、クラスター名が`test`の場合、 TiUPは`Common Name`として`test-client`を使用します。 > - v8.3.0以前のバージョンでは、PD設定項目`cert-allowed-cn`には単一の値しか設定できません。そのため、すべての認証オブジェクトの`Common Name`同じ値に設定する必要があります。関連する設定例については、 [v8.3.0 ドキュメント](https://docs-archive.pingcap.com/tidb/v8.3/enable-tls-between-components/)参照してください。 - TiDB diff --git a/encryption-at-rest.md b/encryption-at-rest.md index fd72cf4f465b4..c750a2e2c1bc5 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -77,7 +77,7 @@ TiKVは現在、 CTRモードでAES128、AES192、AES256、またはSM4（バー - `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 がキーをローテーションする頻度を指定します。 @@ -232,7 +232,7 @@ Azure KMS を使用してマスター キーを指定するには、TiKV 構成 ### マスターキーを回転させる {#rotate-the-master-key} -マスターキーをローテーションするには、設定で新しいマスターキーと古いマスターキーの両方を指定し、TiKVを再起動する必要があります。新しいマスターキーを指定するには`security.encryption.master-key`使用し、古いマスターキーを指定するには`security.encryption.previous-master-key`使用します。 `security.encryption.previous-master-key`の設定形式は`encryption.master-key`と同じです。再起動後、TiKVは新しいマスターキーと古いマスターキーの両方にアクセスする必要がありますが、TiKVが起動して実行されると、TiKVは新しいキーのみにアクセスする必要があります。それ以降は、設定ファイルに`encryption.previous-master-key`設定を残しておいても問題ありません。再起動後も、TiKVは新しいマスターキーを使用して既存のデータを復号化できなかった場合にのみ、古いキーを使用しようとします。 +マスターキーをローテーションするには、設定で新しいマスターキーと古いマスターキーの両方を指定し、TiKVを再起動する必要があります。新しいマスターキーを指定するには`security.encryption.master-key`使用し、古いマスターキーを指定するには`security.encryption.previous-master-key`を使用します。 `security.encryption.previous-master-key`の設定形式は`encryption.master-key`と同じです。再起動後、TiKVは新しいマスターキーと古いマスターキーの両方にアクセスする必要がありますが、TiKVが起動して実行されると、TiKVは新しいキーのみにアクセスする必要があります。それ以降は、設定ファイルに`encryption.previous-master-key`設定を残しておいても問題ありません。再起動後も、TiKVは新しいマスターキーを使用して既存のデータを復号化できなかった場合にのみ、古いキーを使用しようとします。 現在、オンラインでのマスターキーのローテーションはサポートされていないため、TiKVを再起動する必要があります。オンラインクエリを処理している稼働中のTiKVクラスターに対して、ローリング再起動を実行することをお勧めします。 @@ -303,7 +303,7 @@ AWS でキーを作成するには、TiKV のキーを作成する手順を参 security.encryption.data-encryption-method: "aes128-ctr" security.encryption.data-key-rotation-period: "168h" # 7 days -`data-encryption-method`に指定できる値は、「aes128-ctr」、「aes192-ctr」、「aes256-ctr」、「sm4-ctr」（v6.4.0 以降のみ）、「plaintext」です。デフォルト値は「plaintext」で、暗号化は無効です。3 `data-key-rotation-period` 、 TiFlash がデータキーをローテーションする頻度を定義します。暗号化は、新規TiFlashクラスターまたは既存のTiFlashクラスターで有効にできますが、暗号化が有効になった後に書き込まれたデータのみが暗号化されることが保証されます。暗号化を無効にするには、設定ファイルの`data-encryption-method`削除するか、「plaintext」にリセットし、 TiFlashを再起動します。暗号化方式を変更するには、設定ファイルの`data-encryption-method`更新し、 TiFlash を再起動します。暗号化アルゴリズムを変更するには、 `data-encryption-method`サポートされている暗号化アルゴリズムに置き換え、 TiFlash を再起動します。置き換え後、新しいデータが書き込まれると、以前の暗号化アルゴリズムで生成された暗号化ファイルは、新しい暗号化アルゴリズムで生成されたファイルに徐々に書き換えられます。 +`data-encryption-method`に指定できる値は、「aes128-ctr」、「aes192-ctr」、「aes256-ctr」、「sm4-ctr」（v6.4.0 以降のみ）、「plaintext」です。デフォルト値は「plaintext」で、暗号化は無効です。3 `data-key-rotation-period` 、 TiFlash がデータキーをローテーションする頻度を定義します。暗号化は、新規TiFlashクラスターまたは既存のTiFlashクラスターで有効にできますが、暗号化が有効になった後に書き込まれたデータのみが暗号化されることが保証されます。暗号化を無効にするには、設定ファイルの`data-encryption-method`を削除するか、「plaintext」にリセットし、 TiFlashを再起動します。暗号化方式を変更するには、設定ファイルの`data-encryption-method`更新し、 TiFlash を再起動します。暗号化アルゴリズムを変更するには、 `data-encryption-method`サポートされている暗号化アルゴリズムに置き換え、 TiFlash を再起動します。置き換え後、新しいデータが書き込まれると、以前の暗号化アルゴリズムで生成された暗号化ファイルは、新しい暗号化アルゴリズムで生成されたファイルに徐々に書き換えられます。 暗号化が有効になっている場合（つまり、 `data-encryption-method` 「プレーンテキスト」ではない場合）、マスターキーを指定する必要があります。AWS KMS CMK をマスターキーとして指定するには、 `tiflash-learner.toml`設定ファイルの`encryption`セクションの後に`encryption.master-key`セクションを追加します。 diff --git a/error-codes.md b/error-codes.md index 0c2a66dcdf2a4..96c55e3768e70 100644 --- a/error-codes.md +++ b/error-codes.md @@ -357,7 +357,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8154 - 現在、 `LOAD DATA` TiDBサーバーからのローカルデータのインポートをサポートしていません。3 `LOCAL`指定してクライアントからインポートするか、S3 または GCS にデータをアップロードしてからインポートすることができます。5 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)参照してください。 + 現在、 `LOAD DATA` TiDBサーバーからのローカルデータのインポートをサポートしていません。3 `LOCAL`を指定してクライアントからインポートするか、S3 または GCS にデータをアップロードしてからインポートすることができます。5 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)参照してください。 - エラー番号: 8156 @@ -409,7 +409,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8173 - `IMPORT INTO`実行すると、TiDB は現在の環境（下流テーブルが空かどうかなど）をチェックします。具体的な対処方法については、具体的なエラーメッセージを参照してください。 + `IMPORT INTO`を実行すると、TiDB は現在の環境（下流テーブルが空かどうかなど）をチェックします。具体的な対処方法については、具体的なエラーメッセージを参照してください。 - エラー番号: 8200 @@ -461,7 +461,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8228 - シーケンスに`SETVAL`使用すると、サポートされていない型が指定されます。 + シーケンスに`SETVAL`を使用すると、サポートされていない型が指定されます。 関数の例については[シーケンスドキュメント](/sql-statements/sql-statement-create-sequence.md#examples)参照してください。 @@ -525,7 +525,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8263 - このDDLは特定のBDRロールでは実行できません。クラスタが[双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md)になっていることを確認してください。クラスタが双方向レプリケーションになっていない場合は、 `ADMIN UNSET BDR ROLE;`使用してDDLを正常化できます。 + このDDLは特定のBDRロールでは実行できません。クラスタが[双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md)になっていることを確認してください。クラスタが双方向レプリケーションになっていない場合は、 `ADMIN UNSET BDR ROLE;`を使用してDDLを正常化できます。 - エラー番号: 9001 @@ -626,7 +626,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 このエラーは次のように処理できます。 - ログにpanicがあるかどうかを確認します。 - - `dmesg -T | grep -i oom`使用して dmesg に OOM が存在するかどうかを確認します。 + - `dmesg -T | grep -i oom`を使用して dmesg に OOM が存在するかどうかを確認します。 - 長時間アクセスがない場合も、このエラーが発生する可能性があります。これは通常、TCPタイムアウトが原因です。TCPが長時間使用されていない場合、オペレーティングシステムによって強制終了されます。 - エラー番号: 1105 (HY000) @@ -641,7 +641,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 `LOAD DATA LOCAL`ステートメントを実行したが、MySQL クライアントがこのステートメントの実行を許可していない場合 ( `local_infile`オプションの値が 0 の場合)、このエラーが発生します。 - 解決策は、MySQLクライアントの起動時にオプション`--local-infile=1`使用することです。例えば、コマンド`mysql --local-infile=1 -u root -h 127.0.0.1 -P 4000`を実行します。デフォルト値`local-infile`はMySQLクライアントのバージョンによって異なります。そのため、特定のMySQLクライアントで設定する必要があります。 + 解決策は、MySQLクライアントの起動時にオプション`--local-infile=1`を使用することです。例えば、コマンド`mysql --local-infile=1 -u root -h 127.0.0.1 -P 4000`を実行します。デフォルト値`local-infile`はMySQLクライアントのバージョンによって異なります。そのため、特定のMySQLクライアントで設定する必要があります。 - エラー番号: 9001 (HY000) diff --git a/explain-aggregation.md b/explain-aggregation.md index c6898a8f18006..0a994becae482 100644 --- a/explain-aggregation.md +++ b/explain-aggregation.md @@ -47,7 +47,7 @@ SHOW TABLE t1 REGIONS; 4 rows in set (0.00 sec) ``` -以下の集計文で`EXPLAIN`使用すると、まず TiKV 内の各リージョンで`└─StreamAgg_8`実行されていることがわかります。その後、各 TiKVリージョンは 1 行を TiDB に送り返し、TiDB は各リージョンのデータを`StreamAgg_16`に集計します。 +以下の集計文で`EXPLAIN`を使用すると、まず TiKV 内の各リージョンで`└─StreamAgg_8`実行されていることがわかります。その後、各 TiKVリージョンは 1 行を TiDB に送り返し、TiDB は各リージョンのデータを`StreamAgg_16`に集計します。 ```sql EXPLAIN SELECT COUNT(*) FROM t1; diff --git a/explain-indexes.md b/explain-indexes.md index 7ec1a7286619c..bf9b5f096c9cf 100644 --- a/explain-indexes.md +++ b/explain-indexes.md @@ -247,9 +247,9 @@ EXPLAIN SELECT MAX(intkey) FROM t1; 5 rows in set (0.00 sec) ``` -上記の文では、各TiKVリージョンに対してタスク`IndexFullScan`が実行されます。3 `FullScan`名前にもかかわらず、読み取る必要があるのは最初の行（ `└─Limit_28` ）のみです。各TiKVリージョンは`MIN`または`MAX`値をTiDBに返し、TiDBはストリーム集計を実行して単一行をフィルタリングします。また、集約関数`MAX`または`MIN`使用したストリーム集計により、テーブルが空の場合に`NULL`返されることも保証されます。 +上記の文では、各TiKVリージョンに対してタスク`IndexFullScan`が実行されます。3 `FullScan`名前にもかかわらず、読み取る必要があるのは最初の行（ `└─Limit_28` ）のみです。各TiKVリージョンは`MIN`または`MAX`値をTiDBに返し、TiDBはストリーム集計を実行して単一行をフィルタリングします。また、集約関数`MAX`または`MIN`を使用したストリーム集計により、テーブルが空の場合に`NULL`返されることも保証されます。 -対照的に、インデックスなしの値に対して関数`MIN`実行すると、結果は`TableFullScan`になります。このクエリではTiKV内のすべての行をスキャンする必要がありますが、各TiKVリージョンがTiDBに1行のみを返すように、 `TopN`計算が実行されます。 `TopN` TiKVとTiDB間で過剰な行が転送されるのを防ぎますが、この文は、インデックスを利用できる上記の例`MIN`よりもはるかに効率が悪いと考えられます。 +対照的に、インデックスなしの値に対して関数`MIN`を実行すると、結果は`TableFullScan`になります。このクエリではTiKV内のすべての行をスキャンする必要がありますが、各TiKVリージョンがTiDBに1行のみを返すように、 `TopN`計算が実行されます。 `TopN` TiKVとTiDB間で過剰な行が転送されるのを防ぎますが、この文は、インデックスを利用できる上記の例`MIN`よりもはるかに効率が悪いと考えられます。 ```sql EXPLAIN SELECT MIN(pad1) FROM t1; diff --git a/explain-joins.md b/explain-joins.md index 8dd543f5d9dd8..b34a42139f4af 100644 --- a/explain-joins.md +++ b/explain-joins.md @@ -211,7 +211,7 @@ EXPLAIN SELECT /*+ HASH_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; ### 実行時統計 {#runtime-statistics} -[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) (デフォルト値: 1 GB) を超え、 [`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom)値が`ON` (デフォルト) の場合、TiDB は一時ストレージの使用を試み、ハッシュ結合の一部として使用される`Build`演算子をディスク上に作成する可能性があります。メモリ使用量などの実行時統計は、結果テーブル`EXPLAIN ANALYZE`の`execution info`に記録されます。次の例は、1 GB (デフォルト) と`tidb_mem_quota_query`の 500 MB のクォータで`EXPLAIN ANALYZE`実行した場合の出力を示しています。500 MB の場合、ディスクは一時ストレージとして使用されます。 +[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) (デフォルト値: 1 GB) を超え、 [`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom)値が`ON` (デフォルト) の場合、TiDB は一時ストレージの使用を試み、ハッシュ結合の一部として使用される`Build`演算子をディスク上に作成する可能性があります。メモリ使用量などの実行時統計は、結果テーブル`EXPLAIN ANALYZE`の`execution info`に記録されます。次の例は、1 GB (デフォルト) と`tidb_mem_quota_query`の 500 MB のクォータで`EXPLAIN ANALYZE`を実行した場合の出力を示しています。500 MB の場合、ディスクは一時ストレージとして使用されます。 ```sql EXPLAIN ANALYZE SELECT /*+ HASH_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; diff --git a/explain-mpp.md b/explain-mpp.md index 644952d30c1a7..253df48c18fe9 100644 --- a/explain-mpp.md +++ b/explain-mpp.md @@ -187,4 +187,4 @@ mysql > EXPLAIN SELECT COUNT(*) AS count_order FROM lineitem GROUP BY l_returnfl +----------------------------------------+--------------+--------------+----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ ``` -上記の実行計画結果では、TiDBはバージョン`1`のMPP実行計画を使用して`TableReader`構築しています。タイプ`HashPartition`の`ExchangeSender`演算子はデータ圧縮モード`FAST`使用しています。タイプ`PassThrough`の`ExchangeSender`演算子ではデータ圧縮は有効になっていません。 +上記の実行計画結果では、TiDBはバージョン`1`のMPP実行計画を使用して`TableReader`構築しています。タイプ`HashPartition`の`ExchangeSender`演算子はデータ圧縮モード`FAST`を使用しています。タイプ`PassThrough`の`ExchangeSender`演算子ではデータ圧縮は有効になっていません。 diff --git a/explain-overview.md b/explain-overview.md index 9200644202fb0..3727a7dabea33 100644 --- a/explain-overview.md +++ b/explain-overview.md @@ -172,6 +172,6 @@ SQL最適化の目標の一つは、計算を可能な限りTiKVに委ねるこ - `range: [1,1]` 、クエリのwhere句の述語（ `a = 1` ）がTiKV（タスクは`cop[tikv]` ）にプッシュダウンされたことを示しています。 - `keep order:false` 、このクエリのセマンティクスでは TiKV が結果を順番に返す必要がないことを示しています。クエリが順序付けを必要とするように変更された場合（例えば`SELECT * FROM t WHERE a = 1 ORDER BY id` ）、この条件は`keep order:true`になります。 -- `stats:pseudo` 、 `estRows`に示されている推定値が正確ではない可能性があることを示しています。TiDB はバックグラウンド処理の一環として定期的に統計を更新します。4 `ANALYZE TABLE t`実行して手動で更新することもできます。 +- `stats:pseudo` 、 `estRows`に示されている推定値が正確ではない可能性があることを示しています。TiDB はバックグラウンド処理の一環として定期的に統計を更新します。4 `ANALYZE TABLE t`を実行して手動で更新することもできます。 `EXPLAIN`文の実行後、異なる演算子は異なる情報を出力します。オプティマイザヒントを使用してオプティマイザの動作を制御し、それによって物理演算子の選択を制御できます。例えば、 `/*+ HASH_JOIN(t1, t2) */`オプティマイザが`Hash Join`アルゴリズムを使用することを意味します。詳細については、 [オプティマイザヒント](/optimizer-hints.md)参照してください。 diff --git a/explain-walkthrough.md b/explain-walkthrough.md index 5222c35d625e1..1e70e325fb371 100644 --- a/explain-walkthrough.md +++ b/explain-walkthrough.md @@ -39,7 +39,7 @@ EXPLAIN SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00 子演算子`└─TableFullScan_18`から戻ると、その実行プロセスは次のようになります。これは現時点では最適ではありません。 1. コプロセッサ（TiKV）は、 `trips`テーブル全体を`TableFullScan`演算として読み取ります。その後、読み取った行をTiKV内の`Selection_19`の演算子に渡します。 -2. 述語`WHERE start_date BETWEEN ..`演算子`Selection_19`でフィルタリングされます。この選択に該当する行は約`250`行と推定されます。この数は統計情報と演算子のロジックに基づいて推定されることに注意してください。演算子`└─TableFullScan_18` `stats:pseudo`表示されますが、これはテーブルに実際の統計情報が存在しないことを意味します。11 `ANALYZE TABLE trips`実行して統計情報を収集すると、統計の精度が向上することが期待されます。 +2. 述語`WHERE start_date BETWEEN ..`演算子`Selection_19`でフィルタリングされます。この選択に該当する行は約`250`行と推定されます。この数は統計情報と演算子のロジックに基づいて推定されることに注意してください。演算子`└─TableFullScan_18` `stats:pseudo`表示されますが、これはテーブルに実際の統計情報が存在しないことを意味します。11 `ANALYZE TABLE trips`を実行して統計情報を収集すると、統計の精度が向上することが期待されます。 3. 選択基準を満たす行には、関数`count`が適用されます。これも演算子`StreamAgg_9`内で完了しますが、演算子 3 も TiKV 内にあります ( `cop[tikv]` )。TiKV コプロセッサは、MySQL の組み込み関数を多数実行できます。そのうちの 1 つが`count`です。 4. `StreamAgg_9`の結果は、TiDBサーバー内にある`TableReader_21`演算子（ `root`のタスク）に送信されます。この演算子の`estRows`列の値は`1`です。これは、演算子がアクセス対象のTiKVリージョンごとに1行ずつ受け取ることを意味します。これらのリクエストの詳細については、 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)参照してください。 5. 次に、演算子`StreamAgg_20`は演算子`└─TableReader_21`の各行に関数`count`適用します。これは演算子[`SHOW TABLE REGIONS`](/sql-statements/sql-statement-show-table-regions.md)からもわかるように、約 56 行になります。これはルート演算子であるため、結果をクライアントに返します。 @@ -50,7 +50,7 @@ EXPLAIN SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00 ## 現在のパフォーマンスを評価する {#assess-the-current-performance} -`EXPLAIN`クエリ実行プランを返すだけで、クエリは実行されません。実際の実行時間を取得するには、クエリを実行するか、 `EXPLAIN ANALYZE`使用してください。 +`EXPLAIN`クエリ実行プランを返すだけで、クエリは実行されません。実際の実行時間を取得するには、クエリを実行するか、 `EXPLAIN ANALYZE`を使用してください。 ```sql EXPLAIN ANALYZE SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59'; @@ -71,7 +71,7 @@ EXPLAIN ANALYZE SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 上記のクエリの例は実行に`1.03`秒かかりますが、これは理想的なパフォーマンスではありません。 -上記`EXPLAIN ANALYZE`の結果から、 `actRows`推定値の一部（ `estRows` ）が不正確であることを示しています（1万行と予想していたのに1900万行が検出された）。これは`└─TableFullScan_18`の`operator info` （ `stats:pseudo` ）で既に示されています。まず[`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)実行し、次に`EXPLAIN ANALYZE`実行すると、推定値がはるかに近くなることがわかります。 +上記`EXPLAIN ANALYZE`の結果から、 `actRows`推定値の一部（ `estRows` ）が不正確であることを示しています（1万行と予想していたのに1900万行が検出された）。これは`└─TableFullScan_18`の`operator info` （ `stats:pseudo` ）で既に示されています。まず[`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)実行し、次に`EXPLAIN ANALYZE`を実行すると、推定値がはるかに近くなることがわかります。 ```sql ANALYZE TABLE trips; @@ -93,7 +93,7 @@ Query OK, 0 rows affected (10.22 sec) 5 rows in set (0.93 sec) ``` -`ANALYZE TABLE`実行すると、演算子`└─TableFullScan_18`推定行数が正確であり、演算子`└─Selection_19`の推定行数も大幅に近づいたことがわかります。上記の 2 つのケースでは、実行プラン（TiDB がこのクエリを実行するために使用する演算子セット）は変更されていませんが、統計情報が古くなっているために、最適ではないプランが頻繁に発生します。 +`ANALYZE TABLE`を実行すると、演算子`└─TableFullScan_18`推定行数が正確であり、演算子`└─Selection_19`の推定行数も大幅に近づいたことがわかります。上記の 2 つのケースでは、実行プラン（TiDB がこのクエリを実行するために使用する演算子セット）は変更されていませんが、統計情報が古くなっているために、最適ではないプランが頻繁に発生します。 `ANALYZE TABLE`に加えて、TiDB はしきい値[`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio)に達した後、バックグラウンド操作として統計情報を自動的に再生成します。5 [`SHOW STATS_HEALTHY`](/sql-statements/sql-statement-show-stats-healthy.md)ステートメントを実行すると、TiDB がこのしきい値にどれだけ近いか（TiDB が統計情報をどの程度健全であると見なしているか）を確認できます。 diff --git a/extended-statistics.md b/extended-statistics.md index d2aabaa5ccfc2..90872530a25cd 100644 --- a/extended-statistics.md +++ b/extended-statistics.md @@ -129,7 +129,7 @@ SELECT * FROM t WHERE col1 > 1 ORDER BY col2 LIMIT 1; 上記のクエリを実行する場合、TiDB オプティマイザーにはテーブル`t`アクセスするための次のオプションがあります。 -- `col1`のインデックスを使用してテーブル`t`にアクセスし、結果を`col2`でソートして`Top-1`計算します。 +- `col1`のインデックスを使用してテーブル`t`にアクセスし、結果を`col2`でソートして`Top-1`を計算します。 - `col2`のインデックスを使用して、 `col1 > 1`満たす最初の行を検索します。このアクセス方法のコストは、TiDBが`col2`の順序でテーブルをスキャンする際に、どれだけの行がフィルタリングされるかに主に依存します。 拡張統計がない場合、TiDB オプティマイザーは`col1`と`col2`独立していると想定するだけなので、**大きな推定誤差が生じます**。 @@ -142,7 +142,7 @@ SELECT * FROM t WHERE col1 > 1 ORDER BY col2 LIMIT 1; ALTER TABLE t ADD STATS_EXTENDED s1 correlation(col1, col2); ``` -オブジェクト作成後に`ANALYZE`実行すると、 TiDB はテーブル`t`の`col1`と`col2`の[ピアソン相関係数](https://en.wikipedia.org/wiki/Pearson_correlation_coefficient)計算し、オブジェクトをテーブル`mysql.stats_extended`に書き込みます。 +オブジェクト作成後に`ANALYZE`を実行すると、 TiDB はテーブル`t`の`col1`と`col2`の[ピアソン相関係数](https://en.wikipedia.org/wiki/Pearson_correlation_coefficient)計算し、オブジェクトをテーブル`mysql.stats_extended`に書き込みます。 ### ステップ4. 拡張統計がどのように違いを生むかを確認する {#step-4-see-how-extended-statistics-make-a-difference} diff --git a/external-storage-uri.md b/external-storage-uri.md index 4fc4e4c1be64c..6e0aaed883c65 100644 --- a/external-storage-uri.md +++ b/external-storage-uri.md @@ -34,7 +34,7 @@ URI の基本的な形式は次のとおりです。 - `role-arn` : 指定された[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)使用してサードパーティの Amazon S3 データにアクセスする必要がある場合、 `arn:aws:iam::888888888888:role/my-role`などの`role-arn` URL クエリパラメータで、対応する[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) IAMロールを指定できます。IAMIAMを使用してサードパーティの Amazon S3 データにアクセスする方法の詳細については、 [AWSドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)参照してください。BRはv7.6.0 以降でこのパラメータをサポートしています。 - `external-id` : サードパーティから Amazon S3 データにアクセスする場合、正しい[外部ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)指定して[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)引き受けることが必要になる場合があります。この場合、この`external-id` URL クエリパラメータを使用して外部 ID を指定し、 IAMロールを引き受けることができることを確認できます。外部 ID は、Amazon S3 データにアクセスするためにIAMロール ARN と一緒にサードパーティによって提供される任意の文字列です。IAM ロールを引き受ける場合の外部 IDのIAMIAMに外部 ID を必要としない場合は、このパラメータを指定せずにIAMロールを引き受け、対応する Amazon S3 データにアクセスできます。 -以下は、 TiDB LightningおよびBRの Amazon S3 URI の例です。この例では、特定のファイルパス`testfolder`指定する必要があります。 +以下は、 TiDB LightningおよびBRの Amazon S3 URI の例です。この例では、特定のファイルパス`testfolder`を指定する必要があります。 ```shell s3://external/testfolder?access-key=${access-key}&secret-access-key=${secret-access-key} @@ -108,7 +108,7 @@ s3://external/testfolder?access-key=${access-key}&secret-access-key=${secret-acc -以下は、 TiDB LightningとBRのGCS URIの例です。この例では、特定のファイルパス`testfolder`指定する必要があります。 +以下は、 TiDB LightningとBRのGCS URIの例です。この例では、特定のファイルパス`testfolder`を指定する必要があります。 ```shell gcs://external/testfolder?credentials-file=${credentials-file-path} @@ -116,7 +116,7 @@ gcs://external/testfolder?credentials-file=${credentials-file-path} -以下は[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)の GCS URI の例です。この例では、特定のファイル名`test.csv`指定する必要があります。 +以下は[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)の GCS URI の例です。この例では、特定のファイル名`test.csv`を指定する必要があります。 ```shell gcs://external/test.csv?credentials-file=${credentials-file-path} @@ -135,7 +135,7 @@ gcs://external/test.csv?credentials-file=${credentials-file-path} - `encryption-scope` : サーバー側の暗号化に[暗号化範囲](https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-scope-manage?tabs=powershell#upload-a-blob-with-an-encryption-scope)指定します。 - `encryption-key` : AES256 暗号化アルゴリズムを使用するサーバー側暗号化の場合は[暗号化キー](https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-customer-provided-keys)指定します。 -以下は、 BRのAzure Blob Storage URIの例です。この例では、特定のファイルパス`testfolder`指定する必要があります。 +以下は、 BRのAzure Blob Storage URIの例です。この例では、特定のファイルパス`testfolder`を指定する必要があります。 ```shell azure://external/testfolder?account-name=${account-name}&account-key=${account-key} diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md index 6212b4c493be5..172251d63f765 100644 --- a/faq/backup-and-restore-faq.md +++ b/faq/backup-and-restore-faq.md @@ -20,11 +20,11 @@ TiKVは[動的構成](/tikv-control.md#modify-the-tikv-configuration-dynamically - 自動調整を無効にする: TiKV 構成項目[`backup.enable-auto-tune`](/tikv-configuration-file.md#enable-auto-tune-new-in-v540)を`false`に設定します。 - 自動チューニングを有効にする： `backup.enable-auto-tune`を`true`に設定します。v5.3.x から v5.4.0 以降のバージョンにアップグレードしたクラスターでは、自動チューニング機能はデフォルトで無効になっています。手動で有効にする必要があります。 -`tikv-ctl`使用して自動調整を有効または無効にするには、 [オートチューンを使用する](/br/br-auto-tune.md#use-auto-tune)を参照してください。 +`tikv-ctl`を使用して自動調整を有効または無効にするには、 [オートチューンを使用する](/br/br-auto-tune.md#use-auto-tune)を参照してください。 さらに、自動チューニングにより、バックアップ タスクで使用されるデフォルトのスレッド数が削減されます。詳細については、 `backup.num-threads` ](/tikv-configuration-file.md#num-threads-1) を参照してください。そのため、Grafana ダッシュボードでは、バックアップ タスクで使用される速度、CPU 使用率、および I/O リソース使用率が、v5.4.0 より前のバージョンよりも低くなります。v5.4.0 より前では、デフォルト値`backup.num-threads`は`CPU * 0.75`でした。つまり、バックアップ タスクで使用されるスレッド数は、論理 CPU コアの 75% を占めていました。その最大値は`32`でした。v5.4.0 以降、この構成項目のデフォルト値は`CPU * 0.5` 、最大値は`8`です。 -オフライン クラスターでバックアップ タスクを実行する場合、バックアップを高速化するために、 `backup.num-threads`の値を`tikv-ctl`使用してより大きな数値に変更できます。 +オフライン クラスターでバックアップ タスクを実行する場合、バックアップを高速化するために、 `backup.num-threads`の値を`tikv-ctl`を使用してより大きな数値に変更できます。 ## PITRの問題 {#pitr-issues} @@ -105,7 +105,7 @@ Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepo ログバックアップタスクを一時停止すると、MVCCデータがガベージコレクションされるのを防ぐため、一時停止中のタスクプログラムは現在のチェックポイントをサービスセーフポイントとして自動的に設定します。これにより、24時間以内に生成されたMVCCデータが保持されます。バックアップチェックポイントのMVCCデータが24時間以上経過している場合、そのチェックポイントのデータはガベージコレクションされ、バックアップタスクを再開できなくなります。 -この問題を解決するには、 `br log stop`使用して現在のタスクを削除し、 `br log start`を使用してログバックアップタスクを作成します。同時に、後続の PITR のためにフルバックアップを実行できます。 +この問題を解決するには、 `br log stop`を使用して現在のタスクを削除し、 `br log start`を使用してログバックアップタスクを作成します。同時に、後続の PITR のためにフルバックアップを実行できます。 ### PITR テーブル フィルターの使用時にエラー メッセージ[ddl:8204]invalid ddl job type: noneが返された場合はどうすればよいですか? {#what-should-i-do-if-the-error-message-code-ddl-8204-invalid-ddl-job-type-none-code-is-returned-when-using-the-pitr-table-filter} @@ -170,7 +170,7 @@ BRを使用して[`--ddl-batch-size`](/br/br-batch-create-table.md#use-batch-cre ### データの復元中にcould not read local://...:download sst failedというエラー メッセージが返された場合、どうすればよいですか? {#what-should-i-do-if-the-error-message-code-could-not-read-local-download-sst-failed-code-is-returned-during-data-restore} -データを復元する場合、各ノードは**すべての**バックアップファイル（SSTファイル）にアクセスできる必要があります。デフォルトでは、ストレージを`local`使用している場合、バックアップファイルが複数のノードに分散しているため、データを復元できません。そのため、各TiKVノードのバックアップファイルを他のTiKVノードにコピーする必要があります。**バックアップデータは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、またはNFSに保存することをお勧めします**。 +データを復元する場合、各ノードは**すべての**バックアップファイル（SSTファイル）にアクセスできる必要があります。デフォルトでは、ストレージを`local`を使用している場合、バックアップファイルが複数のノードに分散しているため、データを復元できません。そのため、各TiKVノードのバックアップファイルを他のTiKVノードにコピーする必要があります。**バックアップデータは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、またはNFSに保存することをお勧めします**。 ### ルートを使用してbrを実行しようとしたがうまくいかなかった場合、「 Permission denied 」またはNo such file or directory 」というエラーを処理するにはどうすればよいでしょうか? {#what-should-i-do-to-handle-the-code-permission-denied-code-or-code-no-such-file-or-directory-code-error-even-if-i-have-tried-to-run-code-br-code-using-root-in-vain} @@ -295,7 +295,7 @@ BRは統計情報をバックアップしません（v4.0.9を除く）。その v4.0.9では、 BRはデフォルトで統計情報をバックアップしますが、メモリ消費量が多すぎます。バックアッププロセスが確実に実行されるよう、v4.0.10以降では統計情報のバックアップはデフォルトで無効化されています。 -テーブルに対して`ANALYZE`実行しないと、TiDBは統計情報が不正確であるため最適な実行プランを選択できません。クエリパフォーマンスが重要でない場合は、 `ANALYZE`無視できます。 +テーブルに対して`ANALYZE`を実行しないと、TiDBは統計情報が不正確であるため最適な実行プランを選択できません。クエリパフォーマンスが重要でない場合は、 `ANALYZE`無視できます。 ### 複数の復元タスクを同時に開始して、単一のクラスターのデータを復元できますか? {#can-i-start-multiple-restore-tasks-at-the-same-time-to-restore-the-data-of-a-single-cluster} diff --git a/faq/high-reliability-faq.md b/faq/high-reliability-faq.md index fb012ee5beb2c..c47c7d50d8744 100644 --- a/faq/high-reliability-faq.md +++ b/faq/high-reliability-faq.md @@ -15,7 +15,7 @@ summary: TiDB の高信頼性に関連する FAQ について説明します。 - v3.0.8 以降、TiDB は構成ファイル内の[`server-version`](/tidb-configuration-file.md#server-version)変更することでサーバーのバージョン文字列を変更することをサポートしています。 -- v4.0 以降、 TiUPを使用して TiDB をデプロイする場合は、 `tiup cluster edit-config `実行して次のセクションを編集することで、適切なバージョン文字列を指定することもできます。 +- v4.0 以降、 TiUPを使用して TiDB をデプロイする場合は、 `tiup cluster edit-config `を実行して次のセクションを編集することで、適切なバージョン文字列を指定することもできます。 server_configs: tidb: diff --git a/faq/sql-faq.md b/faq/sql-faq.md index b9a0bf480b590..ed698bccb16dc 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -64,7 +64,7 @@ DROP GLOBAL BINDING for これはバグではありません。レコードのデフォルトの順序は様々な状況に依存し、一貫性は保証されません。 -MySQLでは、クエリが単一スレッドで実行されるため、結果の順序は安定しているように見えるかもしれません。しかし、新しいバージョンにアップグレードすると、クエリプランが変更される場合があります。結果の順序を指定したい場合は、常に`ORDER BY`使用することをお勧めします。 +MySQLでは、クエリが単一スレッドで実行されるため、結果の順序は安定しているように見えるかもしれません。しかし、新しいバージョンにアップグレードすると、クエリプランが変更される場合があります。結果の順序を指定したい場合は、常に`ORDER BY`を使用することをお勧めします。 参照文献は[ISO/IEC 9075:1992、データベース言語SQL - 1992年7月30日](http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt)にあり、次のように述べられています。 @@ -328,7 +328,7 @@ TiDB v6.2.0以降、TiDB DDLモジュールは並列フレームワークを採 1. DDL ステートメントの実行を遅くするその他の理由を排除します。 2. DDL 所有者ノードを識別するには、次のいずれかの方法を使用します。 - - 現在のクラスターの所有者を取得するには、 `curl http://{TiDBIP}:10080/info/all`使用します。 + - 現在のクラスターの所有者を取得するには、 `curl http://{TiDBIP}:10080/info/all`を使用します。 - 監視ダッシュボードの**DDL** > **DDL META OPM**から、特定の期間の所有者を確認する。 - 所有者が存在しない場合は、次を使用して所有者の選択を手動でトリガーしてみてください: `curl -X POST http://{TiDBIP}:10080/ddl/owner/resign` 。 @@ -344,11 +344,11 @@ JDBC URL に`connectionCollation`が設定されていない場合、次の 2 **シナリオ 1** : JDBC URL に`connectionCollation`も`characterEncoding`も設定されていない -- Connector/J 8.0.25以前のバージョンでは、JDBCドライバはサーバーのデフォルトの文字セットを使用しようとします。TiDBのデフォルトの文字セットは`utf8mb4`であるため、ドライバは接続照合順序として`utf8mb4_bin`使用します。 +- Connector/J 8.0.25以前のバージョンでは、JDBCドライバはサーバーのデフォルトの文字セットを使用しようとします。TiDBのデフォルトの文字セットは`utf8mb4`であるため、ドライバは接続照合順序として`utf8mb4_bin`を使用します。 - Connector/J 8.0.26 以降のバージョンでは、JDBC ドライバーは`utf8mb4`文字セットを使用し、戻り値`SELECT VERSION()`に基づいて照合順序を自動的に選択します。 - - 戻り値が`8.0.1`未満の場合、ドライバは接続照合順序として`utf8mb4_general_ci`使用します。TiDB はドライバに従い、照合順序として`utf8mb4_general_ci`使用します。 - - 戻り値が`8.0.1`以上の場合、ドライバは接続照合順序として`utf8mb4_0900_ai_ci`使用します。TiDB v7.4.0 以降のバージョンではドライバに従い、照合順序として`utf8mb4_0900_ai_ci`使用しますが、TiDB v7.4.0 より前のバージョンでは`utf8mb4_0900_ai_ci`照合順序がサポートされていないため、デフォルトの照合照合順序`utf8mb4_bin`が使用されます。 + - 戻り値が`8.0.1`未満の場合、ドライバは接続照合順序として`utf8mb4_general_ci`を使用します。TiDB はドライバに従い、照合順序として`utf8mb4_general_ci`を使用します。 + - 戻り値が`8.0.1`以上の場合、ドライバは接続照合順序として`utf8mb4_0900_ai_ci`を使用します。TiDB v7.4.0 以降のバージョンではドライバに従い、照合順序として`utf8mb4_0900_ai_ci`を使用しますが、TiDB v7.4.0 より前のバージョンでは`utf8mb4_0900_ai_ci`照合順序がサポートされていないため、デフォルトの照合照合順序`utf8mb4_bin`が使用されます。 **シナリオ2** ：JDBC URLに`characterEncoding=utf8`設定されていますが、 `connectionCollation`設定されていません。JDBCドライバーはマッピングルールに従って`utf8mb4`文字セットを使用します。照合順序はシナリオ1で説明したルールに従って決定されます。 @@ -421,7 +421,7 @@ SELECT 'café' = 'cafe' COLLATE utf8mb4_0900_ai_ci; -- Returns 1 (TRUE) ### 現在の DDL ジョブの進行状況を表示するにはどうすればよいでしょうか? {#how-to-view-the-progress-of-the-current-ddl-job} -`ADMIN SHOW DDL`使用すると、現在の DDL ジョブの進行状況を表示できます。操作は以下のとおりです。 +`ADMIN SHOW DDL`を使用すると、現在の DDL ジョブの進行状況を表示できます。操作は以下のとおりです。 ```sql ADMIN SHOW DDL; @@ -447,7 +447,7 @@ ADMIN SHOW DDL; ### テーブルでanalyze実行する必要があるかどうかを判断するにはどうすればよいでしょうか? {#how-to-determine-whether-i-need-to-execute-code-analyze-code-on-a-table} -`SHOW STATS_HEALTHY`を使用して`Healthy`フィールドを確認する。通常、フィールド値が 60 より小さい場合は、テーブルで`ANALYZE`実行する必要があります。 +`SHOW STATS_HEALTHY`を使用して`Healthy`フィールドを確認する。通常、フィールド値が 60 より小さい場合は、テーブルで`ANALYZE`を実行する必要があります。 ### クエリプランがツリーとして表現される場合のIDルールは何ですか？このツリーの実行順序は何ですか？ {#what-is-the-id-rule-when-a-query-plan-is-presented-as-a-tree-what-is-the-execution-order-for-this-tree} diff --git a/faq/upgrade-faq.md b/faq/upgrade-faq.md index 80530c56b5155..228477ea9fe0e 100644 --- a/faq/upgrade-faq.md +++ b/faq/upgrade-faq.md @@ -253,7 +253,7 @@ TiDB v2.1.1以前のバージョンでは、文字セットがUTF-8の場合、 Query OK, 1 row affected - 具体的には、変数`tidb_skip_utf8_check`使用すると、データのUTF-8およびUTF8MB4の有効性チェックをスキップできます。ただし、チェックをスキップすると、MySQLがチェックを実行するため、TiDBからMySQLへのデータのレプリケーションに失敗する可能性があります。 + 具体的には、変数`tidb_skip_utf8_check`を使用すると、データのUTF-8およびUTF8MB4の有効性チェックをスキップできます。ただし、チェックをスキップすると、MySQLがチェックを実行するため、TiDBからMySQLへのデータのレプリケーションに失敗する可能性があります。 UTF-8チェックのみをスキップしたい場合は、 `tidb_check_mb4_value_in_utf8`設定できます。この変数はv2.1.3で`config.toml`ファイルに追加され、設定ファイルの`check-mb4-value-in-utf8`変更してクラスターを再起動することで有効になります。 diff --git a/filter-dml-event.md b/filter-dml-event.md index 711a51c0ef5ab..b54e065d84c99 100644 --- a/filter-dml-event.md +++ b/filter-dml-event.md @@ -14,7 +14,7 @@ summary: SQL 式を使用して DML イベントをフィルター処理する 増分データレプリケーションを実行する際に、 [Binlogイベントフィルター](/filter-binlog-event.md)使用して特定の種類のbinlogイベントをフィルタリングできます。例えば、アーカイブや監査などの目的で、 `DELETE`イベントを下流に複製しないように選択できます。ただし、 Binlogイベントフィルタは、より細かい粒度が求められる行の`DELETE`のイベントをフィルタリングするかどうかを判断できません。 -この問題に対処するため、DM v2.0.5以降では、増分データレプリケーションにおいて`binlog value filter`使用したデータのフィルタリングをサポートしています。DM対応の`ROW`形式のbinlogでは、binlogイベントはすべての列の値を保持しており、これらの値に基づいてSQL式を設定できます。式で行の変更が`TRUE`と計算された場合、DMはこの行の変更を下流に複製しません。 +この問題に対処するため、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)を参照してください。 diff --git a/follower-read.md b/follower-read.md index 905fb9be2238c..5db63126c14c4 100644 --- a/follower-read.md +++ b/follower-read.md @@ -113,7 +113,7 @@ Follower Read には、TiKV 読み取りリクエストをリーダーレプリ ### 強力な一貫性のある読み取り {#strongly-consistent-reads} -フォロワーノードが読み取り要求を処理する際、まずRaftプロトコルの`ReadIndex`使用してリージョンのリーダーとやり取りし、現在のRaftグループの最新のコミットインデックスを取得します。リーダーの最新のコミットインデックスがフォロワーにローカルに適用された後、読み取り要求の処理が開始されます。 +フォロワーノードが読み取り要求を処理する際、まずRaftプロトコルの`ReadIndex`を使用してリージョンのリーダーとやり取りし、現在のRaftグループの最新のコミットインデックスを取得します。リーダーの最新のコミットインデックスがフォロワーにローカルに適用された後、読み取り要求の処理が開始されます。 ![read-index-flow](/media/follower-read/read-index.png) diff --git a/functions-and-operators/bit-functions-and-operators.md b/functions-and-operators/bit-functions-and-operators.md index c677541170875..3db3d31ce0e12 100644 --- a/functions-and-operators/bit-functions-and-operators.md +++ b/functions-and-operators/bit-functions-and-operators.md @@ -36,7 +36,7 @@ SELECT BIT_COUNT(b'00101001'); > **注記：** > -> 引数`expr`が2進数の場合、 `b'00101001'`のように数値の前に明示的に`b`指定する必要があります。そうでない場合、この関数はそれを文字列として扱い、異なる結果を返します。例えば、 `BIT_COUNT('00101001')`文字列`'00101001'` 10進数の`101001`に変換し、その2進数形式における`1`ビットの数を`11000100001010001`カウントするため、 `7`返します。 +> 引数`expr`が2進数の場合、 `b'00101001'`のように数値の前に明示的に`b`を指定する必要があります。そうでない場合、この関数はそれを文字列として扱い、異なる結果を返します。例えば、 `BIT_COUNT('00101001')`文字列`'00101001'` 10進数の`101001`に変換し、その2進数形式における`1`ビットの数を`11000100001010001`カウントするため、 `7`返します。 次の例は前の例と似ていますが、引数としてビットリテラルではなく16進リテラルを使用しています`CONV()`関数は`0x29` 16進数（基数16）から2進数（基数2）に変換し、2進数では`00101001`あることを示します。 @@ -204,7 +204,7 @@ SELECT CONV(b'1010' ^ b'1100',10,2); `<<`演算子は左シフト演算を実行し、数値のビットを指定された位置数だけ左にシフトし、右側の空いたビットをゼロで埋めます。 -たとえば、次のステートメントでは、 `1<>`演算子は右シフト演算を実行し、数値のビットを指定された位置数だけ右にシフトし、左側の空いたビットをゼロで埋めます。 -たとえば、次の文では、 `1024>>n`使用して、値`1024` (2 進数では`10000000000` ) を`n`位置右にシフトします。 +たとえば、次の文では、 `1024>>n`を使用して、値`1024` (2 進数では`10000000000` ) を`n`位置右にシフトします。 ```sql WITH RECURSIVE cte(n) AS ( diff --git a/functions-and-operators/group-by-modifier.md b/functions-and-operators/group-by-modifier.md index 55665b83855c7..3ac32b6c1d5fb 100644 --- a/functions-and-operators/group-by-modifier.md +++ b/functions-and-operators/group-by-modifier.md @@ -50,7 +50,7 @@ v8.3.0より前のTiDBでは、 [TiFlash MPPモード](/tiflash/use-tiflash-mpp- v8.3.0以降では、上記の制限は解除されました。TiDBクラスターにTiFlashノードが含まれているかどうかに関係なく、TiDBは`WITH ROLLUP`構文の有効な実行プランの生成をサポートします。 -TiDBとTiFlashのどちらが演算子`Expand`実行するかを確認するには、実行プランで演算子`Expand`の属性`task`確認します。詳細については、 [ROLLUP実行プランの解釈方法](#how-to-interpret-the-rollup-execution-plan)参照してください。 +TiDBとTiFlashのどちらが演算子`Expand`を実行するかを確認するには、実行プランで演算子`Expand`の属性`task`を確認します。詳細については、 [ROLLUP実行プランの解釈方法](#how-to-interpret-the-rollup-execution-plan)参照してください。 ## 例 {#examples} @@ -110,7 +110,7 @@ SELECT year, month, SUM(profit) AS profit from bank GROUP BY year, month WITH RO `WITH ROLLUP`結果のうち`NULL`値は、Aggregate 演算子が適用される直前に生成されます。したがって、 `SELECT` 、 `HAVING` 、 `ORDER BY`句で`NULL`値を使用して、集計結果をさらに絞り込むことができます。 -たとえば、 `HAVING`句の`NULL`使用して、2 次元グループの集計結果のみをフィルタリングして表示できます。 +たとえば、 `HAVING`句の`NULL`を使用して、2 次元グループの集計結果のみをフィルタリングして表示できます。 ```sql SELECT year, month, SUM(profit) AS profit FROM bank GROUP BY year, month WITH ROLLUP HAVING year IS NOT null AND month IS NOT null; @@ -154,7 +154,7 @@ GROUPING(day, month, year): + result for GROUPING(day) << 2 ``` -`GROUPING()`関数で複数のパラメータを使用することで、任意の高次元で集計結果を効率的にフィルタリングできます。例えば、 `GROUPING(year, month)`使用すると、各年と全年の集計結果を素早くフィルタリングできます。 +`GROUPING()`関数で複数のパラメータを使用することで、任意の高次元で集計結果を効率的にフィルタリングできます。例えば、 `GROUPING(year, month)`を使用すると、各年と全年の集計結果を素早くフィルタリングできます。 ```sql SELECT year, month, SUM(profit) AS profit, grouping(year) as grp_year, grouping(month) as grp_month FROM bank GROUP BY year, month WITH ROLLUP HAVING GROUPING(year, month) <> 0 ORDER BY year DESC, month DESC; diff --git a/functions-and-operators/information-functions.md b/functions-and-operators/information-functions.md index b3af3f6e13cc9..da2b0b592cb2d 100644 --- a/functions-and-operators/information-functions.md +++ b/functions-and-operators/information-functions.md @@ -164,7 +164,7 @@ SELECT FOUND_ROWS(); > **注記：** > -> クエリ修飾子`SQL_CALC_FOUND_ROWS` 、クエリ修飾子`LIMIT`を考慮せずに結果セットの合計行数を計算しますが、クエリ修飾子[`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)有効な場合にのみ使用できます。このクエリ修飾子は、MySQL 8.0.17 以降では非推奨です。代わりにクエリ修飾子`COUNT(*)`使用することをお勧めします。 +> クエリ修飾子`SQL_CALC_FOUND_ROWS` 、クエリ修飾子`LIMIT`を考慮せずに結果セットの合計行数を計算しますが、クエリ修飾子[`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)有効な場合にのみ使用できます。このクエリ修飾子は、MySQL 8.0.17 以降では非推奨です。代わりにクエリ修飾子`COUNT(*)`を使用することをお勧めします。 ### 最終挿入ID() {#last-insert-id} diff --git a/functions-and-operators/string-functions.md b/functions-and-operators/string-functions.md index 19eaecad26813..a8ccf046d0058 100644 --- a/functions-and-operators/string-functions.md +++ b/functions-and-operators/string-functions.md @@ -632,7 +632,7 @@ mysql> SELECT FROM_BASE64('MTIzNDU2'); `HEX()`関数は、指定された引数をその16進数値の文字列表現に変換します。引数は文字列または数値のいずれかです。 - 引数が文字列の場合、 `HEX(str)` `str`の16進文字列表現を返します。この関数は、 `str`の各文字の各バイトを2桁の16進数に変換します。例えば、UTF-8またはASCII文字セットの文字`a` 2進値では`00111101` 、16進表記では`61`として表されます。 -- 引数が数値の場合、 `HEX(n)` `n`の16進文字列表現を返します。この関数は引数`n` `BIGINT`として扱い、これは`CONV(n, 10, 16)`使用するのと同じ意味になります。 +- 引数が数値の場合、 `HEX(n)` `n`の16進文字列表現を返します。この関数は引数`n` `BIGINT`として扱い、これは`CONV(n, 10, 16)`を使用するのと同じ意味になります。 - 引数が`NULL`の場合、関数は`NULL`返します。 > **注記：** @@ -1052,7 +1052,7 @@ SELECT 10000 LIKE '12%' AS result; +--------+ ``` -`utf8mb4_unicode_ci`などの照合順序を明示的に指定するには、 `COLLATE`使用します。 +`utf8mb4_unicode_ci`などの照合順序を明示的に指定するには、 `COLLATE`を使用します。 ```sql SELECT '🍣🍺Sushi🍣🍺' COLLATE utf8mb4_unicode_ci LIKE '%SUSHI%' AS result; @@ -2303,7 +2303,7 @@ TiDB と MySQL 間の`match_type`の値オプションは次のとおりです - MySQL は空の文字列を置き換えず、結果として`""`返します。 - TiDB は空の文字列を置き換え、結果として`"123"`返します。 -- TiDBでグループをキャプチャするために使用するキーワードはMySQLとは異なります。MySQLではキーワードとして`$`使用しますが、TiDBでは`\\`使用します。また、TiDBは`0`から`9`の番号のグループのみをキャプチャできます。 +- TiDBでグループをキャプチャするために使用するキーワードはMySQLとは異なります。MySQLではキーワードとして`$`を使用しますが、TiDBでは`\\`を使用します。また、TiDBは`0`から`9`の番号のグループのみをキャプチャできます。 たとえば、次の SQL ステートメントは TiDB に`ab`返します。 diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index 692ea2683b124..193c3ff507e15 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -74,7 +74,7 @@ CREATE RESOURCE GROUP rg2 RU_PER_SEC = 2000; ALTER USER 'user1' RESOURCE GROUP `rg1`; ``` -`user1`使用してログインし、現在のユーザーにバインドされているリソース グループを表示します。 +`user1`を使用してログインし、現在のユーザーにバインドされているリソース グループを表示します。 ```sql SELECT CURRENT_RESOURCE_GROUP(); @@ -87,7 +87,7 @@ SELECT CURRENT_RESOURCE_GROUP(); +--------------------------+ 1 row in set (0.00 sec) -`SET RESOURCE GROUP`実行して、現在のセッションのリソース グループを`rg2`に設定し、現在のユーザーにバインドされているリソース グループを表示します。 +`SET RESOURCE GROUP`を実行して、現在のセッションのリソース グループを`rg2`に設定し、現在のユーザーにバインドされているリソース グループを表示します。 ```sql SET RESOURCE GROUP `rg2`; @@ -292,7 +292,7 @@ SELECT tidb_decode_plan('8QIYMAkzMV83CQEH8E85LjA0CWRhdGE6U2VsZWN0aW9uXzYJOTYwCXR > **注記：** > > - この機能を使用できるのは、 [PROCESS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_process)権限を持つユーザーのみです。 -> - `TIDB_DECODE_SQL_DIGESTS`実行すると、TiDB は各 SQL ダイジェストに対応するステートメントをステートメントサマリーテーブルから照会します。そのため、どの SQL ダイジェストに対しても、必ず対応するステートメントが見つかるとは限りません。見つかるのはクラスタ内で実行されたステートメントのみであり、これらの SQL ステートメントを照会できるかどうかは、ステートメントサマリーテーブルの関連設定にも影響されます。ステートメントサマリーテーブルの詳細については、 [明細書要約表](/statement-summary-tables.md)参照してください。 +> - `TIDB_DECODE_SQL_DIGESTS`を実行すると、TiDB は各 SQL ダイジェストに対応するステートメントをステートメントサマリーテーブルから照会します。そのため、どの SQL ダイジェストに対しても、必ず対応するステートメントが見つかるとは限りません。見つかるのはクラスタ内で実行されたステートメントのみであり、これらの SQL ステートメントを照会できるかどうかは、ステートメントサマリーテーブルの関連設定にも影響されます。ステートメントサマリーテーブルの詳細については、 [明細書要約表](/statement-summary-tables.md)参照してください。 > - この関数はオーバーヘッドが大きいため、行数の多いクエリ（例えば、大規模で高負荷なクラスターでテーブル`information_schema.cluster_tidb_trx`全体を検索するなど）では、この関数を使用するとクエリの実行時間が長くなりすぎる可能性があります。注意して使用してください。 > - この関数は、呼び出されるたびに内部的に`STATEMENTS_SUMMARY` 、 `STATEMENTS_SUMMARY_HISTORY` 、 `CLUSTER_STATEMENTS_SUMMARY` 、 `CLUSTER_STATEMENTS_SUMMARY_HISTORY`テーブルを照会し、そのクエリに`UNION`演算が含まれるため、オーバーヘッドが大きくなります。この関数は現在ベクトル化をサポートしていません。つまり、複数行のデータに対してこの関数を呼び出す場合、上記のクエリは各行ごとに個別に実行されます。 @@ -471,7 +471,7 @@ SELECT *, TIDB_ROW_CHECKSUM() FROM t WHERE id = 1; - 作成: - インデックスフィールド`a`にシャードインデックスを作成するには、 `uk((tidb_shard(a)), a))`使用します。一意のセカンダリインデックス`uk((tidb_shard(a)), a))`内のインデックスフィールド`a`のデータが単調に増加または減少することでホットスポットが発生した場合、インデックスのプレフィックス`tidb_shard(a)`によってホットスポットを分散させることで、クラスターのスケーラビリティを向上させることができます。 + インデックスフィールド`a`にシャードインデックスを作成するには、 `uk((tidb_shard(a)), a))`を使用します。一意のセカンダリインデックス`uk((tidb_shard(a)), a))`内のインデックスフィールド`a`のデータが単調に増加または減少することでホットスポットが発生した場合、インデックスのプレフィックス`tidb_shard(a)`によってホットスポットを分散させることで、クラスターのスケーラビリティを向上させることができます。 - シナリオ: diff --git a/generate-self-signed-certificates.md b/generate-self-signed-certificates.md index 9cedddca86cf1..5e3112acef9d8 100644 --- a/generate-self-signed-certificates.md +++ b/generate-self-signed-certificates.md @@ -9,7 +9,7 @@ summary: openssl` を使用して自己署名証明書を生成します。 > > クライアントとサーバー間の TLS を有効にするには、 `auto-tls`設定するだけです。 -このドキュメントでは、 `openssl`使用して自己署名証明書を生成する例を示します。また、必要に応じて、要件を満たす証明書と鍵を生成することもできます。 +このドキュメントでは、 `openssl`を使用して自己署名証明書を生成する例を示します。また、必要に応じて、要件を満たす証明書と鍵を生成することもできます。 インスタンス クラスターのトポロジが次のとおりであると仮定します。 diff --git a/generated-columns.md b/generated-columns.md index 6d2b53d1cf5b5..cad3ed137a60f 100644 --- a/generated-columns.md +++ b/generated-columns.md @@ -67,7 +67,7 @@ EXPLAIN SELECT name, id FROM person WHERE city = 'Beijing'; +---------------------------------+---------+-----------+--------------------------------+-------------------------------------------------------------+ ``` -クエリ実行プランからは、条件`city ='Beijing'`満たす行の`HANDLE`読み込むために`city`インデックスが使用され、次にこの`HANDLE`使用して行のデータを読み込んでいることがわかります。 +クエリ実行プランからは、条件`city ='Beijing'`満たす行の`HANDLE`読み込むために`city`インデックスが使用され、次にこの`HANDLE`を使用して行のデータを読み込んでいることがわかります。 パス`$.city`にデータが存在しない場合、 `JSON_EXTRACT` `NULL`返します。 `city`必ず`NOT NULL`になるという制約を適用したい場合は、次のように仮想生成列を定義します。 diff --git a/identify-slow-queries.md b/identify-slow-queries.md index 267459a01647f..b34cd6876cc3e 100644 --- a/identify-slow-queries.md +++ b/identify-slow-queries.md @@ -95,7 +95,7 @@ insert into t select * from t; - `Prewrite_time` : 2 フェーズ トランザクション コミットの最初のフェーズ (プリライト) の期間。 - `Commit_time` : 2 フェーズ トランザクション コミットの第 2 フェーズ (コミット) の期間。 -- `Get_commit_ts_time` : 2 フェーズ トランザクション コミットの第 2 フェーズ (コミット) で`commit_ts`取得するのに費やされた時間。 +- `Get_commit_ts_time` : 2 フェーズ トランザクション コミットの第 2 フェーズ (コミット) で`commit_ts`を取得するのに費やされた時間。 - `Local_latch_wait_time` : TiDB が 2 相トランザクションコミットの第 2 相 (コミット) の前にロックを待機するのに費やす時間。 - `Write_keys` : トランザクションが TiKV の Write CF に書き込むキーの数。 - `Write_size` : トランザクションがコミットされたときに書き込まれるキーまたは値の合計サイズ。 diff --git a/information-schema/client-errors-summary-by-host.md b/information-schema/client-errors-summary-by-host.md index 218391370a028..bbfec0bdbd5a8 100644 --- a/information-schema/client-errors-summary-by-host.md +++ b/information-schema/client-errors-summary-by-host.md @@ -56,7 +56,7 @@ DESC CLIENT_ERRORS_SUMMARY_BY_HOST; - `FIRST_SEEN` : このエラー (または警告) がクライアント ホストから初めて確認されました。 - `LAST_SEEN` : このエラー (または警告) がクライアント ホストから最後に確認された時刻。 -以下の例は、クライアントがローカルTiDBサーバーに接続する際に生成される警告を示しています。1 `FLUSH CLIENT_ERRORS_SUMMARY`実行するとサマリーはリセットされます。 +以下の例は、クライアントがローカルTiDBサーバーに接続する際に生成される警告を示しています。1 `FLUSH CLIENT_ERRORS_SUMMARY`を実行するとサマリーはリセットされます。 ```sql SELECT 0/0; diff --git a/information-schema/client-errors-summary-by-user.md b/information-schema/client-errors-summary-by-user.md index d05ffd44e5886..d86110933dc8b 100644 --- a/information-schema/client-errors-summary-by-user.md +++ b/information-schema/client-errors-summary-by-user.md @@ -55,7 +55,7 @@ DESC CLIENT_ERRORS_SUMMARY_BY_USER; - `FIRST_SEEN` : このエラー (または警告) がユーザーに初めて送信されたとき。 - `LAST_SEEN` : このエラー (または警告) がユーザーに最後に送信された時刻。 -以下の例は、クライアントがローカルTiDBサーバーに接続する際に生成される警告を示しています。1 `FLUSH CLIENT_ERRORS_SUMMARY`実行するとサマリーはリセットされます。 +以下の例は、クライアントがローカルTiDBサーバーに接続する際に生成される警告を示しています。1 `FLUSH CLIENT_ERRORS_SUMMARY`を実行するとサマリーはリセットされます。 ```sql SELECT 0/0; diff --git a/information-schema/client-errors-summary-global.md b/information-schema/client-errors-summary-global.md index 064d2c2576eef..7c6c6dc2838e7 100644 --- a/information-schema/client-errors-summary-global.md +++ b/information-schema/client-errors-summary-global.md @@ -47,7 +47,7 @@ DESC CLIENT_ERRORS_SUMMARY_GLOBAL; - `FIRST_SEEN` : このエラー (または警告) が最初に送信されたとき。 - `LAST_SEEN` : このエラー (または警告) が最後に送信された時刻。 -以下の例は、ローカルTiDBサーバーへの接続時に生成される警告を示しています。1 `FLUSH CLIENT_ERRORS_SUMMARY`実行するとサマリーがリセットされます。 +以下の例は、ローカルTiDBサーバーへの接続時に生成される警告を示しています。1 `FLUSH CLIENT_ERRORS_SUMMARY`を実行するとサマリーがリセットされます。 ```sql SELECT 0/0; diff --git a/information-schema/information-schema-cluster-log.md b/information-schema/information-schema-cluster-log.md index 9b54163a4e350..5aa9e70ea3cc7 100644 --- a/information-schema/information-schema-cluster-log.md +++ b/information-schema/information-schema-cluster-log.md @@ -43,7 +43,7 @@ DESC cluster_log; > > - クラスターログテーブルのすべてのフィールドは、対応するインスタンスにプッシュダウンされて実行されます。クラスターログテーブルの使用に伴うオーバーヘッドを削減するには、検索に使用するキーワード、時間範囲、そして可能な限り多くの条件を指定する必要があります。例えば、 `select * from cluster_log where message like '%ddl%' and time > '2020-05-18 20:40:00' and time<'2020-05-18 21:40:00' and type='tidb'`に指定します。 > -> - `message`フィールドは`like`と`regexp`正規表現をサポートしており、対応するパターンは`regexp`としてエンコードされます。複数の`message`条件を指定すると、 `grep`コマンドの`pipeline`形式と同じになります。例えば、 `select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*' and time > '2020-05-18 20:40:00' and time<'2020-05-18 21:40:00'`ステートメントを実行すると、すべてのクラスターインスタンスで`grep 'coprocessor' xxx.log | grep -E '.*slow.*'`実行するのと同じになります。 +> - `message`フィールドは`like`と`regexp`正規表現をサポートしており、対応するパターンは`regexp`としてエンコードされます。複数の`message`条件を指定すると、 `grep`コマンドの`pipeline`形式と同じになります。例えば、 `select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*' and time > '2020-05-18 20:40:00' and time<'2020-05-18 21:40:00'`ステートメントを実行すると、すべてのクラスターインスタンスで`grep 'coprocessor' xxx.log | grep -E '.*slow.*'`を実行するのと同じになります。 次の例は、 `CLUSTER_LOG`テーブルを使用して DDL ステートメントの実行プロセスをクエリする方法を示しています。 diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index f9a8789a4141a..8bdbbd3a959ab 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -7,7 +7,7 @@ summary: INSPECTION_RESULT` 診断結果テーブルを確認します。 TiDB には、システム内の障害や隠れた問題を検出するための診断ルールがいくつか組み込まれています。 -`INSPECTION_RESULT`診断テーブルは、問題を迅速に発見し、手作業の繰り返しを削減するのに役立ちます。3 ステートメント`select * from information_schema.inspection_result`使用して、内部診断をトリガーできます。 +`INSPECTION_RESULT`診断テーブルは、問題を迅速に発見し、手作業の繰り返しを削減するのに役立ちます。3 ステートメント`select * from information_schema.inspection_result`を使用して、内部診断をトリガーできます。 > **注記：** > @@ -107,7 +107,7 @@ DETAILS | max duration of 172.16.5.40:20151 tikv rocksdb-write-duration was to - 2 行目は、クラスター内に 2 つの異なる TiDB バージョンが存在することを示します。 - 3行目と4行目は、TiKVの書き込み遅延が長すぎることを示しています。予想される遅延は0.1秒以内ですが、実際の遅延は予想よりもはるかに長くなっています。 -「2020-03-26 00:03:00」から「2020-03-26 00:08:00」までなど、指定した範囲内にある問題を診断することもできます。時間範囲を指定するには、SQLヒントに`/*+ time_range() */`指定します。次のクエリ例をご覧ください。 +「2020-03-26 00:03:00」から「2020-03-26 00:08:00」までなど、指定した範囲内にある問題を診断することもできます。時間範囲を指定するには、SQLヒントに`/*+ time_range() */`を指定します。次のクエリ例をご覧ください。 ```sql select /*+ time_range("2020-03-26 00:03:00", "2020-03-26 00:08:00") */ * from information_schema.inspection_result\G diff --git a/information-schema/information-schema-inspection-summary.md b/information-schema/information-schema-inspection-summary.md index 8c0f9e9a05ebf..20e1883fd39a7 100644 --- a/information-schema/information-schema-inspection-summary.md +++ b/information-schema/information-schema-inspection-summary.md @@ -40,12 +40,12 @@ DESC inspection_summary; - `RULE` : 要約ルール。新しいルールは継続的に追加されるため、 `select * from inspection_rules where type='summary'`ステートメントを実行すると最新のルールリストを照会できます。 - `INSTANCE` : 監視対象インスタンス。 - `METRICS_NAME` : 監視メトリック名。 -- `QUANTILE` : `QUANTILE`含む監視テーブルに有効です。述語をプッシュダウンすることで、複数のパーセンタイルを指定できます。例えば、 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)`実行してDDL関連の監視メトリックを要約し、P80/P90/P99/P999の結果を照会できます。6 、 `MIN_VALUE` 、 `MAX_VALUE` `AVG_VALUE` 、集計の平均値、最小値、最大値を示します。 +- `QUANTILE` : `QUANTILE`含む監視テーブルに有効です。述語をプッシュダウンすることで、複数のパーセンタイルを指定できます。例えば、 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)`を実行してDDL関連の監視メトリックを要約し、P80/P90/P99/P999の結果を照会できます。6 、 `MIN_VALUE` 、 `MAX_VALUE` `AVG_VALUE` 、集計の平均値、最小値、最大値を示します。 - `COMMENT` : 対応する監視メトリックに関するコメント。 > **注記：** > -> すべての結果を要約するとオーバーヘッドが発生するため、SQL述語で特定の`rule`表示してオーバーヘッドを削減することをお勧めします。例えば、 `select * from inspection_summary where rule in ('read-link', 'ddl')`実行すると、読み取りリンクとDDL関連の監視メトリックが要約されます。 +> すべての結果を要約するとオーバーヘッドが発生するため、SQL述語で特定の`rule`を表示してオーバーヘッドを削減することをお勧めします。例えば、 `select * from inspection_summary where rule in ('read-link', 'ddl')`を実行すると、読み取りリンクとDDL関連の監視メトリックが要約されます。 使用例: diff --git a/information-schema/information-schema-metrics-summary.md b/information-schema/information-schema-metrics-summary.md index 886f89f94ee82..101c39f5c9c85 100644 --- a/information-schema/information-schema-metrics-summary.md +++ b/information-schema/information-schema-metrics-summary.md @@ -39,7 +39,7 @@ DESC metrics_summary; フィールドの説明: - `METRICS_NAME` : 監視テーブル名。 -- `QUANTILE` : パーセンタイル。SQL文を使用して`QUANTILE`指定することもできます。例: +- `QUANTILE` : パーセンタイル。SQL文を使用して`QUANTILE`を指定することもできます。例: - `select * from metrics_summary where quantile=0.99` 0.99 パーセンタイルのデータを表示することを指定します。 - `select * from metrics_summary where quantile in (0.80, 0.90, 0.99, 0.999)` 、0.8、0.90、0.99、0.999 パーセンタイルのデータを同時に表示することを指定します。 - `SUM_VALUE` 、 `AVG_VALUE` 、 `MIN_VALUE` 、 `MAX_VALUE`それぞれ合計、平均値、最小値、最大値を意味します。 diff --git a/information-schema/information-schema-sql-diagnostics.md b/information-schema/information-schema-sql-diagnostics.md index 519691da3ac65..12d6d9bb0d74c 100644 --- a/information-schema/information-schema-sql-diagnostics.md +++ b/information-schema/information-schema-sql-diagnostics.md @@ -52,5 +52,5 @@ TiDB クラスターには多くの監視メトリックがあるため、TiDB 上記のクラスタ情報テーブルおよびクラスタ監視テーブルでは、クラスタのトラブルシューティングを行うために手動でSQL文を実行する必要があります。TiDB v4.0は自動診断をサポートしています。既存の基本情報テーブルをベースにした診断関連のシステムテーブルを使用することで、診断を自動実行できます。自動診断に関連するシステムテーブルは以下のとおりです。 -- 診断結果テーブル[`information_schema.inspection_result`](/information-schema/information-schema-inspection-result.md)には、システムの診断結果が表示されます。診断は受動的にトリガーされます。3 `select * from inspection_result`実行すると、すべての診断ルールがトリガーされ、システムが診断され、システム内の障害またはリスクが結果に表示されます。 +- 診断結果テーブル[`information_schema.inspection_result`](/information-schema/information-schema-inspection-result.md)には、システムの診断結果が表示されます。診断は受動的にトリガーされます。3 `select * from inspection_result`を実行すると、すべての診断ルールがトリガーされ、システムが診断され、システム内の障害またはリスクが結果に表示されます。 - 診断サマリーテーブル[`information_schema.inspection_summary`](/information-schema/information-schema-inspection-summary.md) 、特定のリンクまたはモジュールの監視情報を要約したものです。モジュールまたはリンク全体のコンテキストに基づいて、トラブルシューティングを行い、問題を特定することができます。 diff --git a/maintain-tidb-using-tiup.md b/maintain-tidb-using-tiup.md index 4bff3ae375dda..0acfe098bd96f 100644 --- a/maintain-tidb-using-tiup.md +++ b/maintain-tidb-using-tiup.md @@ -31,7 +31,7 @@ tiup cluster start ${cluster-name} > **注記：** > -> `${cluster-name}`クラスター名に置き換えてください。クラスター名を忘れた場合は、 `tiup cluster list`実行して確認してください。 +> `${cluster-name}`クラスター名に置き換えてください。クラスター名を忘れた場合は、 `tiup cluster list`を実行して確認してください。 コマンドに`-R`または`-N`パラメータを追加することで、一部のコンポーネントのみを起動できます。例： diff --git a/metrics-schema.md b/metrics-schema.md index a12d08ea267b6..54b9628d5ed6f 100644 --- a/metrics-schema.md +++ b/metrics-schema.md @@ -188,7 +188,7 @@ DESC SELECT * FROM metrics_schema.tidb_query_duration WHERE value is not null AN [ `2020-03-25 23:40:00` , `2020-03-25 23:42:00` ] の範囲では、各ラベルに3つの時間値しかないことに気づくかもしれません。実行プランでは、 `step`の値は1分であり、これらの値の間隔は1分であることを意味します。7 `step`次の2つのセッション変数によって決定されます。 -- `tidb_metric_query_step` : クエリ解決ステップ幅。Prometheusから`query_range`データを取得するには、 `start_time` 、 `end_time` 、 `step`指定する必要があります。 `step` 、この変数の値が使用されます。 +- `tidb_metric_query_step` : クエリ解決ステップ幅。Prometheusから`query_range`データを取得するには、 `start_time` 、 `end_time` 、 `step`を指定する必要があります。 `step` 、この変数の値が使用されます。 - `tidb_metric_query_range_duration` : 監視データが照会されると、 `PROMQL`の`$ RANGE_DURATION`のフィールドの値がこの変数の値に置き換えられます。デフォルト値は60秒です。 監視項目の値を異なる粒度で表示するには、監視テーブルをクエリする前に、上記の2つのセッション変数を変更します。例： diff --git a/migrate-from-tidb-to-mysql.md b/migrate-from-tidb-to-mysql.md index 30d5582840908..cfa2d78945bb4 100644 --- a/migrate-from-tidb-to-mysql.md +++ b/migrate-from-tidb-to-mysql.md @@ -37,7 +37,7 @@ summary: TiDB から MySQL 互換データベースにデータを移行する 3. サービスのワークロードをシミュレートします。 - ラボ環境では、 `go-tpc`使用してTiDBクラスタの上流にデータを書き込むことができます。これは、TiDBクラスタでイベントの変更を生成するためです。以下のコマンドを実行して、TiDBクラスタに`tpcc`という名前のデータベースを作成し、 TiUP benchを使用してこのデータベースにデータを書き込みます。 + ラボ環境では、 `go-tpc`を使用してTiDBクラスタの上流にデータを書き込むことができます。これは、TiDBクラスタでイベントの変更を生成するためです。以下のコマンドを実行して、TiDBクラスタに`tpcc`という名前のデータベースを作成し、 TiUP benchを使用してこのデータベースにデータを書き込みます。 ```shell tiup bench tpcc -H 127.0.0.1 -P 4000 -D tpcc --warehouses 4 prepare diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index 1a7ae01b60495..11d55e204580d 100644 --- a/migrate-from-tidb-to-tidb.md +++ b/migrate-from-tidb-to-tidb.md @@ -99,7 +99,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー ## ステップ2. 全データの移行 {#step-2-migrate-full-data} -環境構築後、 [BR](https://github.com/pingcap/tidb/tree/release-8.5/br)のバックアップ・リストア関数を使用して全データを移行できます。BRは[3つの方法](/br/br-use-overview.md#deploy-and-use-br)で起動できます。本稿では、SQL文`BACKUP`と`RESTORE`使用します。 +環境構築後、 [BR](https://github.com/pingcap/tidb/tree/release-8.5/br)のバックアップ・リストア関数を使用して全データを移行できます。BRは[3つの方法](/br/br-use-overview.md#deploy-and-use-br)で起動できます。本稿では、SQL文`BACKUP`と`RESTORE`を使用します。 > **注記：** > @@ -276,7 +276,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー } ] -2. ダウンストリームからアップストリームへのチェンジフィードを作成します。アップストリームとダウンストリームのデータは一致しており、クラスターに新しいデータが書き込まれていないため、デフォルト設定を使用するには`start-ts`指定しないでください。 +2. ダウンストリームからアップストリームへのチェンジフィードを作成します。アップストリームとダウンストリームのデータは一致しており、クラスターに新しいデータが書き込まれていないため、デフォルト設定を使用するには`start-ts`を指定しないでください。 ```shell tiup cdc cli changefeed create --server=http://172.16.6.125:8300 --sink-uri="mysql://root:@172.16.6.122:4000" --changefeed-id="downstream -to-upstream" diff --git a/migrate-small-mysql-shards-to-tidb.md b/migrate-small-mysql-shards-to-tidb.md index dbc0ff7723a77..54d900d12fa77 100644 --- a/migrate-small-mysql-shards-to-tidb.md +++ b/migrate-small-mysql-shards-to-tidb.md @@ -79,7 +79,7 @@ from: port: ${port} # For example: 3306 ``` -ターミナルで次のコマンドを実行します。1 `tiup dmctl`指定して、データソース構成を DM クラスターに読み込みます。 +ターミナルで次のコマンドを実行します。1 `tiup dmctl`を指定して、データソース構成を DM クラスターに読み込みます。 ```shell tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml @@ -198,13 +198,13 @@ tiup dmctl --master-addr ${advertise-addr} start-task task.yaml ## ステップ4. タスクを確認する {#step-4-check-the-task} -移行タスクを開始した後、 `dmtcl tiup`使用して`query-status`実行し、タスクのステータスを表示できます。 +移行タスクを開始した後、 `dmtcl tiup`を使用して`query-status`実行し、タスクのステータスを表示できます。 ```shell tiup dmctl --master-addr ${advertise-addr} query-status ${task-name} ``` -エラーが発生した場合は、 `query-status ${task-name}`使用して詳細情報を表示してください。3 `query-status`のクエリ結果、タスクステータス、サブタスクステータスの詳細については、 [TiDB データ移行クエリのステータス](/dm/dm-query-status.md)参照してください。 +エラーが発生した場合は、 `query-status ${task-name}`を使用して詳細情報を表示してください。3 `query-status`のクエリ結果、タスクステータス、サブタスクステータスの詳細については、 [TiDB データ移行クエリのステータス](/dm/dm-query-status.md)参照してください。 ## ステップ5. タスクを監視し、ログを確認する（オプション） {#step-5-monitor-tasks-and-check-logs-optional} diff --git a/migrate-small-mysql-to-tidb.md b/migrate-small-mysql-to-tidb.md index 26f997b3bcb93..4d1570e0d7c87 100644 --- a/migrate-small-mysql-to-tidb.md +++ b/migrate-small-mysql-to-tidb.md @@ -34,7 +34,7 @@ from: port: 3306 ``` -次に、次のコマンドを実行して、 `tiup dmctl`使用してデータ ソース構成を DM クラスターにロードします。 +次に、次のコマンドを実行して、 `tiup dmctl`を使用してデータ ソース構成を DM クラスターにロードします。 ```shell tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml @@ -110,7 +110,7 @@ tiup dmctl --master-addr ${advertise-addr} start-task task.yaml ## ステップ4: 移行タスクのステータスを確認する {#step-4-check-the-migration-task-status} -DM クラスターに進行中の移行タスクがあるかどうか、タスクのステータス、その他の情報を確認するには、 `tiup dmctl`使用して`query-status`コマンドを実行します。 +DM クラスターに進行中の移行タスクがあるかどうか、タスクのステータス、その他の情報を確認するには、 `tiup dmctl`を使用して`query-status`コマンドを実行します。 ```shell tiup dmctl --master-addr ${advertise-addr} query-status ${task-name} diff --git a/migrate-with-more-columns-downstream.md b/migrate-with-more-columns-downstream.md index 43b32687af0fb..c03e83ab5e530 100644 --- a/migrate-with-more-columns-downstream.md +++ b/migrate-with-more-columns-downstream.md @@ -73,7 +73,7 @@ DM がダウンストリーム テーブル スキーマを使用してアップ | パラメータ | 説明 | | :------------------ | :--------------------------------------------------------------------------------------------------------------- | - | `-master-addr` | dmctl が接続されるクラスター内の任意の DM マスター ノードの`${advertise-addr}`指定します。3 `${advertise-addr}` 、DM マスターが外部にアドバタイズするアドレスを示します。 | + | `-master-addr` | dmctl が接続されるクラスター内の任意の DM マスター ノードの`${advertise-addr}`を指定します。3 `${advertise-addr}` 、DM マスターが外部にアドバタイズするアドレスを示します。 | | `binlog-schema set` | スキーマ情報を手動で設定します。 | | `-s` | ソースを指定します。1 `${source-id}` MySQL データのソース ID を示します。 | | `${task-name}` | データ移行タスクの`task.yaml`構成ファイルで定義されている移行タスクの名前を指定します。 | diff --git a/non-transactional-dml.md b/non-transactional-dml.md index fb0cd1b30f371..593b654723e35 100644 --- a/non-transactional-dml.md +++ b/non-transactional-dml.md @@ -51,7 +51,7 @@ summary: TiDBの非トランザクションDMLステートメントについて - 非トランザクション`INSERT INTO ... SELECT`ステートメント内で同じテーブルから選択して変更する場合は、シャード列を変更しないでください。そうしないと、複数のバッチが同じ行を読み取り、データを複数回挿入する可能性があります。 - `BATCH ON test.t.id LIMIT 10000 INSERT INTO t SELECT id+1, value FROM t;`使用は推奨されません。 - `BATCH ON test.t.id LIMIT 10000 INSERT INTO t SELECT id, value FROM t;`を使用することをお勧めします。 - - シャード列`id`に`AUTO_INCREMENT`属性がある場合は、 `BATCH ON test.t.id LIMIT 10000 INSERT INTO t(value) SELECT value FROM t;`使用することをお勧めします。 + - シャード列`id`に`AUTO_INCREMENT`属性がある場合は、 `BATCH ON test.t.id LIMIT 10000 INSERT INTO t(value) SELECT value FROM t;`を使用することをお勧めします。 - 非トランザクション`UPDATE` 、 `INSERT ... ON DUPLICATE KEY UPDATE` 、または`REPLACE INTO`ステートメントでシャード列を更新しないでください。 - 例えば、非トランザクション`UPDATE`ステートメントの場合、分割された SQL ステートメントは順番に実行されます。前のバッチの変更は、前のバッチがコミットされた後に次のバッチによって読み取られるため、同じデータ行が複数回変更されることになります。 - これらのステートメントは`BATCH ON test.t.id LIMIT 10000 UPDATE t SET test.t.id = test.t.id-1;`サポートしていません。 @@ -162,7 +162,7 @@ SELECT * FROM t2; ### 実行の進行状況を確認する {#check-the-execution-progress} -非トランザクションDML文の実行中は、 `SHOW PROCESSLIST`使用して進行状況を確認できます。返される結果の`Time`フィールドは、現在のバッチ実行の消費時間を示します。ログとスローログには、非トランザクションDML実行中の各分割文の進行状況も記録されます。例: +非トランザクションDML文の実行中は、 `SHOW PROCESSLIST`を使用して進行状況を確認できます。返される結果の`Time`フィールドは、現在のバッチ実行の消費時間を示します。ログとスローログには、非トランザクションDML実行中の各分割文の進行状況も記録されます。例: ```sql SHOW PROCESSLIST; @@ -179,7 +179,7 @@ SHOW PROCESSLIST; ### 非トランザクションDML文を終了する {#terminate-a-non-transactional-dml-statement} -非トランザクションDML文を終了するには、 `KILL TIDB `使用します。TiDBは現在実行中のバッチ以降のすべてのバッチをキャンセルします。実行結果はログから取得できます。 +非トランザクションDML文を終了するには、 `KILL TIDB `を使用します。TiDBは現在実行中のバッチ以降のすべてのバッチをキャンセルします。実行結果はログから取得できます。 `KILL TIDB`詳細については、参考文献[`KILL`](/sql-statements/sql-statement-kill.md)を参照してください。 diff --git a/online-unsafe-recovery.md b/online-unsafe-recovery.md index e696705b3c89a..8b0a70ca43a6d 100644 --- a/online-unsafe-recovery.md +++ b/online-unsafe-recovery.md @@ -149,7 +149,7 @@ PDはリカバリプランのディスパッチに成功した後、TiKVから } ``` -影響を受けるテーブル ID を取得したら、クエリ`INFORMATION_SCHEMA.TABLES`実行して、影響を受けるテーブル名を表示できます。 +影響を受けるテーブル ID を取得したら、クエリ`INFORMATION_SCHEMA.TABLES`を実行して、影響を受けるテーブル名を表示できます。 ```sql SELECT TABLE_SCHEMA, TABLE_NAME, TIDB_TABLE_ID FROM INFORMATION_SCHEMA.TABLES WHERE TIDB_TABLE_ID IN (64, 27); diff --git a/optimizer-hints.md b/optimizer-hints.md index fa0f49d2d8779..a4c28466e0c9d 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -72,7 +72,7 @@ SELECT /*+ QB_NAME(QB1) */ * FROM (SELECT * FROM t) t1, (SELECT * FROM t) t2; > **注記：** > -> 上記の例では、ヒントが`QB_NAME`から`sel_2`指定し、元の 2 番目のクエリ ブロック`SELECT`に新しい`QB_NAME`指定していない場合、2 番目のクエリ ブロック`SELECT`に対して`sel_2`無効な名前になります。 +> 上記の例では、ヒントが`QB_NAME`から`sel_2`指定し、元の 2 番目のクエリ ブロック`SELECT`に新しい`QB_NAME`を指定していない場合、2 番目のクエリ ブロック`SELECT`に対して`sel_2`無効な名前になります。 ### MERGE_JOIN(t1_name [, tl_name ...]) {#merge-join-t1-name-tl-name} @@ -108,7 +108,7 @@ SELECT /*+ INL_JOIN(t1, t2) */ * FROM t1, t2, t3 WHERE t1.id = t2.id AND t2.id = 上記のSQL文では、ヒント`INL_JOIN(t1, t2)`はオプティマイザに、 `t1`と`t2`に対してインデックス・ネストループ結合アルゴリズムを使用するように指示しています。これは、 `t1`と`t2`の間でインデックス・ネストループ結合アルゴリズムが使用されることを意味するわけではないことに注意してください。ヒントは、 `t1`と`t2`がそれぞれ別のテーブル（ `t3` ）に対してインデックス・ネストループ結合アルゴリズムを使用することを示しています。 -`INL_JOIN()`で指定されたパラメータは、クエリプランを作成する際に内部テーブルとして使用される候補テーブルです。例えば、 `INL_JOIN(t1)` 、TiDB がクエリプランを作成する際に内部テーブルとして`t1`を使用することを検討することを意味します。候補テーブルに別名がある場合は、 `INL_JOIN()`のパラメータとしてその別名を使用する必要があります。別名がない場合は、テーブルの元の名前をパラメータとして使用してください。例えば、 `select /*+ INL_JOIN(t1) */ * from t t1, t t2 where t1.a = t2.b;`クエリでは、 `INL_JOIN()`のパラメータとして`t`ではなく、 `t`テーブルの別名である`t1`または`t2`使用する必要があります。 +`INL_JOIN()`で指定されたパラメータは、クエリプランを作成する際に内部テーブルとして使用される候補テーブルです。例えば、 `INL_JOIN(t1)` 、TiDB がクエリプランを作成する際に内部テーブルとして`t1`を使用することを検討することを意味します。候補テーブルに別名がある場合は、 `INL_JOIN()`のパラメータとしてその別名を使用する必要があります。別名がない場合は、テーブルの元の名前をパラメータとして使用してください。例えば、 `select /*+ INL_JOIN(t1) */ * from t t1, t t2 where t1.a = t2.b;`クエリでは、 `INL_JOIN()`のパラメータとして`t`ではなく、 `t`テーブルの別名である`t1`または`t2`を使用する必要があります。 > **注記：** > @@ -182,7 +182,7 @@ SELECT /*+ HASH_JOIN_PROBE(t2) */ * FROM t1, t2 WHERE t1.id = t2.id; 同様に、実行プランでインデックス結合が選択されている場合、準結合クエリは駆動テーブルとして外部クエリのみを使用できます。この場合、サブクエリの結果が外部クエリの結果よりも小さい場合、実行速度が予想よりも遅くなる可能性があります。 -`SEMI_JOIN_REWRITE()`使用してクエリを書き換えると、オプティマイザーは選択範囲を拡張して、より適切な実行プランを選択できます。 +`SEMI_JOIN_REWRITE()`を使用してクエリを書き換えると、オプティマイザーは選択範囲を拡張して、より適切な実行プランを選択できます。 ```sql -- Does not use SEMI_JOIN_REWRITE() to rewrite the query. @@ -575,7 +575,7 @@ SHOW WARNINGS; > **注記：** > -> クエリ文に外部結合が含まれている場合、ヒントには結合順序を入れ替え可能なテーブルのみを指定できます。ヒントに結合順序を入れ替えられないテーブルが含まれている場合、ヒントは無効になります。例えば、 `SELECT * FROM t1 LEFT JOIN (t2 JOIN t3 JOIN t4) ON t1.a = t2.a;`で`t2` `t3` `t4`テーブルの結合順序を制御したい場合、 `LEADING`のヒントに`t1`指定することはできません。 +> クエリ文に外部結合が含まれている場合、ヒントには結合順序を入れ替え可能なテーブルのみを指定できます。ヒントに結合順序を入れ替えられないテーブルが含まれている場合、ヒントは無効になります。例えば、 `SELECT * FROM t1 LEFT JOIN (t2 JOIN t3 JOIN t4) ON t1.a = t2.a;`で`t2` `t3` `t4`テーブルの結合順序を制御したい場合、 `LEADING`のヒントに`t1`を指定することはできません。 ### マージ（） {#merge} @@ -655,7 +655,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * > **注記：** > -> - ビューでグローバルヒントを使用するには、対応するヒントをビューに`QB_NAME`定義する必要があります。そうしないと、グローバルヒントは有効になりません。 +> - ビューでグローバルヒントを使用するには、対応するヒントをビューに`QB_NAME`を定義する必要があります。そうしないと、グローバルヒントは有効になりません。 > > - ヒントを使用してビュー内の複数のテーブル名を指定する場合、同じヒントに表示されるテーブル名が同じビューの同じクエリ ブロック内にあることを確認する必要があります。 > @@ -679,7 +679,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * SELECT /*+ QB_NAME(v2_1, v2) merge_join(t@v2_1) */ * FROM v2; ``` -- ビュー`v2`の 2 番目のクエリ ブロックにヒント`MERGE_JOIN()`と`STREAM_AGG()`指定します。 +- ビュー`v2`の 2 番目のクエリ ブロックにヒント`MERGE_JOIN()`と`STREAM_AGG()`を指定します。 ```sql SELECT /*+ QB_NAME(v2_2, v2.@SEL_2) merge_join(t1@v2_2) stream_agg(@v2_2) */ * FROM v2; @@ -691,7 +691,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * SELECT /*+ QB_NAME(v1_1, v2.v1@SEL_2) hash_join(t@v1_1) */ * FROM v2; ``` -- ビュー`v1`の 2 番目のクエリ ブロックにヒント`HASH_JOIN()`と`HASH_AGG()`指定します。 +- ビュー`v1`の 2 番目のクエリ ブロックにヒント`HASH_JOIN()`と`HASH_AGG()`を指定します。 ```sql SELECT /*+ QB_NAME(v1_2, v2.v1@SEL_2 .@SEL_2) hash_join(t1@v1_2) hash_agg(@v1_2) */ * FROM v2; @@ -854,7 +854,7 @@ SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10; > **注記：** > -> TiDB v8.2.0以降、このヒントに対する権限制御が導入されました。システム変数[`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820) `ON`に設定されている場合、このヒントを使用するには`SUPER` 、 `RESOURCE_GROUP_ADMIN` 、または`RESOURCE_GROUP_USER`権限が必要です。必要な権限がない場合、このヒントは無視され、TiDBは警告を返します。クエリ実行後に`SHOW WARNINGS;`実行すると、詳細を確認できます。 +> TiDB v8.2.0以降、このヒントに対する権限制御が導入されました。システム変数[`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820) `ON`に設定されている場合、このヒントを使用するには`SUPER` 、 `RESOURCE_GROUP_ADMIN` 、または`RESOURCE_GROUP_USER`権限が必要です。必要な権限がない場合、このヒントは無視され、TiDBは警告を返します。クエリ実行後に`SHOW WARNINGS;`を実行すると、詳細を確認できます。 ## ヒントが効かない一般的な問題のトラブルシューティング {#troubleshoot-common-issues-that-hints-do-not-take-effect} @@ -938,7 +938,7 @@ SHOW WARNINGS; 場合によっては、テーブルを結合する列で組み込み関数を使用すると、オプティマイザーが`IndexJoin`プランを選択できず、 `INL_JOIN`ヒントも有効にならないことがあります。 -たとえば、次のクエリは、テーブルを結合する列`tname`で組み込み関数`substr`使用します。 +たとえば、次のクエリは、テーブルを結合する列`tname`で組み込み関数`substr`を使用します。 ```sql CREATE TABLE t1 (id varchar(10) primary key, tname varchar(10)); @@ -1056,7 +1056,7 @@ EXPLAIN SELECT /*+ inl_join(t1, t3) */ * FROM t1, t2, t3 WHERE t1.id = t2.id AND 前の例では、 `t1`と`t3`は`IndexJoin`によって直接結合されていません。 -`t1`と`t3`の間で直接`IndexJoin`実行するには、まず[`LEADING(t1, t3)`ヒント](#leadingt1_name--tl_name-)使用して`t1`と`t3`の結合順序を指定し、次に`INL_JOIN`ヒントを使用して結合アルゴリズムを指定します。例: +`t1`と`t3`の間で直接`IndexJoin`を実行するには、まず[`LEADING(t1, t3)`ヒント](#leadingt1_name--tl_name-)使用して`t1`と`t3`の結合順序を指定し、次に`INL_JOIN`ヒントを使用して結合アルゴリズムを指定します。例: ```sql EXPLAIN SELECT /*+ leading(t1, t3), inl_join(t3) */ * FROM t1, t2, t3 WHERE t1.id = t2.id AND t2.id = t3.id AND t1.id = t3.id; diff --git a/oracle-functions-to-tidb.md b/oracle-functions-to-tidb.md index f2f4964f8ff6c..6fd03e7521d78 100644 --- a/oracle-functions-to-tidb.md +++ b/oracle-functions-to-tidb.md @@ -31,7 +31,7 @@ summary: Oracle と TiDB の関数と構文の比較を学習します。 | 値を切り捨てる | `TRUNC(2.136) = 2`
    `TRUNC(2.136,2) = 2.13` | `TRUNCATE(2.136,0) = 2`
    `TRUNCATE(2.136,2) = 2.13` | データの精度は保持されます。対応する小数点以下の桁は切り捨てられますが、四捨五入は行われません。 | | シーケンス内の次の値を取得する | `sequence_name.NEXTVAL` | `NEXTVAL(sequence_name)` | | | ランダムなシーケンス値を取得する | `SYS_GUID()` | `UUID()` | TiDB は、Universal Unique Identifier (UUID) を返します。 | -| 左結合または右結合 | `SELECT * FROM a, b WHERE a.id = b.id(+);`
    `SELECT * FROM a, b WHERE a.id(+) = b.id;` | `SELECT * FROM a LEFT JOIN b ON a.id = b.id;`
    `SELECT * FROM a RIGHT JOIN b ON a.id = b.id;` | 相関クエリでは、TiDBは左結合または右結合に(+)の使用をサポートしていません。代わりに`LEFT JOIN`または`RIGHT JOIN`使用してください。 | +| 左結合または右結合 | `SELECT * FROM a, b WHERE a.id = b.id(+);`
    `SELECT * FROM a, b WHERE a.id(+) = b.id;` | `SELECT * FROM a LEFT JOIN b ON a.id = b.id;`
    `SELECT * FROM a RIGHT JOIN b ON a.id = b.id;` | 相関クエリでは、TiDBは左結合または右結合に(+)の使用をサポートしていません。代わりに`LEFT JOIN`または`RIGHT JOIN`を使用してください。 | | `NVL()` | `NVL(key,val)` | `IFNULL(key,val)` | フィールドの値が`NULL`の場合、 `val`返します。それ以外の場合は、フィールドの値を返します。 | | `NVL2()` | `NVL2(key, val1, val2)` | `IF(key is NOT NULL, val1, val2)` | フィールドの値が`NULL`でない場合は`val1`返し、そうでない場合は`val2`返します。 | | `DECODE()` |
  • `DECODE(key,val1,val2,val3)`
  • `DECODE(value,if1,val1,if2,val2,...,ifn,valn,val)`
    • |
  • `IF(key=val1,val2,val3)`
  • `CASE WHEN value=if1 THEN val1 WHEN value=if2 THEN val2,...,WHEN value=ifn THEN valn ELSE val END`
    • |
  • フィールドの値が`val1`の場合、 `val2`を返します。それ以外の場合は`val3`返します。
  • フィールドの値が条件1（ `if1` ）を満たす場合は`val1`返します。条件2（ `if2` ）を満たす場合は`val2`返します。条件3（ `if3` ）を満たす場合は`val3`返します。
    • | diff --git a/partition-pruning.md b/partition-pruning.md index aea8230e7e54a..4be477dbb3ce4 100644 --- a/partition-pruning.md +++ b/partition-pruning.md @@ -164,7 +164,7 @@ explain select * from t where x = 3; +-------------------------+----------+-----------+-----------------------+--------------------------------+ ``` -パーティションプルーニングは、クエリ条件`in`使用する等価比較にも適用されます。例: +パーティションプルーニングは、クエリ条件`in`を使用する等価比較にも適用されます。例: ```sql create table t (x int) partition by range (x) ( diff --git a/password-management.md b/password-management.md index 125e64debd9d0..cf1f3fd547294 100644 --- a/password-management.md +++ b/password-management.md @@ -192,7 +192,7 @@ ALTER USER 'test'@'localhost' PASSWORD EXPIRE; データベース管理者によってアカウントのパスワードの有効期限が設定されている場合、TiDBにログインする前にパスワードを変更する必要があります。手動で設定した有効期限は取り消すことはできません。 -`CREATE ROLE`文で作成されたロールはパスワードを必要としないため、パスワードフィールドは空になります。このような場合、TiDB は`password_expired`属性を`'Y'`に設定します。これは、ロールのパスワードが手動で期限切れになっていることを意味します。この設計の目的は、ロールのロックが解除され、空のパスワードで TiDB にログインすることを防ぐことです。7 文でロールのロックが解除されると、パスワードが空であってもこのアカウントでログインできます。そのため、TiDB は`ALTER USER ... ACCOUNT UNLOCK`属性`password_expired`使用してパスワードを手動で期限切れにし、ユーザーがアカウントに有効なパスワードを設定するようにしています。 +`CREATE ROLE`文で作成されたロールはパスワードを必要としないため、パスワードフィールドは空になります。このような場合、TiDB は`password_expired`属性を`'Y'`に設定します。これは、ロールのパスワードが手動で期限切れになっていることを意味します。この設計の目的は、ロールのロックが解除され、空のパスワードで TiDB にログインすることを防ぐことです。7 文でロールのロックが解除されると、パスワードが空であってもこのアカウントでログインできます。そのため、TiDB は`ALTER USER ... ACCOUNT UNLOCK`属性`password_expired`を使用してパスワードを手動で期限切れにし、ユーザーがアカウントに有効なパスワードを設定するようにしています。 ```sql mysql> CREATE ROLE testrole; diff --git a/pd-control.md b/pd-control.md index 4f8fe35565d57..7ee8c7cf23d3a 100644 --- a/pd-control.md +++ b/pd-control.md @@ -1299,7 +1299,7 @@ store weight 1 5 10 > **注記：** > -> `pd-ctl`使用すると、TiKVストアの状態（ `Up` 、 `Disconnect` 、 `Offline` 、 `Down` 、または`Tombstone` ）を確認できます。各状態の関係については、 [TiKVストアの各状態間の関係](/tidb-scheduling.md#information-collection)参照してください。 +> `pd-ctl`を使用すると、TiKVストアの状態（ `Up` 、 `Disconnect` 、 `Offline` 、 `Down` 、または`Tombstone` ）を確認できます。各状態の関係については、 [TiKVストアの各状態間の関係](/tidb-scheduling.md#information-collection)参照してください。 ### `log [fatal | error | warn | info | debug]` {#log-fatal-error-warn-info-debug} diff --git a/pd-microservices.md b/pd-microservices.md index 7d15867516ad5..1d377641b604b 100644 --- a/pd-microservices.md +++ b/pd-microservices.md @@ -84,7 +84,7 @@ PD マイクロサービスをデプロイして使用する場合、次の点 - `scheduling`マイクロサービスがクラスターにデプロイされている場合、クラスターのスケジューリング機能は`scheduling`マイクロサービスによって提供されます。5 `scheduling`マイクロサービスがデプロイされていない場合でも、クラスターのスケジューリング機能はPDによって提供されます。 - `scheduling`マイクロサービスは動的スイッチングをサポートしており、これはデフォルトで有効になっています（ `enable-scheduling-fallback`デフォルトで`true`に設定されています）。7 `scheduling`サービスのプロセスが終了した場合、PD はデフォルトでクラスターのスケジューリングサービスを継続します。 - `scheduling`マイクロサービスと PD のバイナリバージョンが異なる場合、スケジューリングロジックの変更を防ぐため、 `pd-ctl config set enable-scheduling-fallback false`実行して`scheduling`マイクロサービスの動的切り替え機能を無効化できます。この機能を無効化すると、 `scheduling`マイクロサービスのプロセスが終了しても PD はスケジューリングサービスを引き継ぎません。つまり、 `scheduling`マイクロサービスが再起動されるまで、クラスターのスケジューリングサービスは利用できなくなります。 + `scheduling`マイクロサービスと PD のバイナリバージョンが異なる場合、スケジューリングロジックの変更を防ぐため、 `pd-ctl config set enable-scheduling-fallback false`を実行して`scheduling`マイクロサービスの動的切り替え機能を無効化できます。この機能を無効化すると、 `scheduling`マイクロサービスのプロセスが終了しても PD はスケジューリングサービスを引き継ぎません。つまり、 `scheduling`マイクロサービスが再起動されるまで、クラスターのスケジューリングサービスは利用できなくなります。 ## ツールの互換性 {#tool-compatibility} diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index a104543980128..0578f99267be3 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -298,7 +298,7 @@ TiDBの平均CPU使用率は827%から577%に低下しました。QPSが増加 - SQLフェーズ別データベース時間では、 `execute`最も時間がかかり、データベース時間とほぼ一致しています。一方、SQL実行時間の概要では、 `tso wait`最も時間がかかり、 `execute`の4分の1以上がTSOの待機に費やされています。 - 1秒あたり`tso wait`回の実行時間の合計は5.46秒です。3 `tso wait`実行時間の平均は196マイクロ秒、1秒あたり`tso cmd`回の実行時間は28,000回で、QPSの30,900に非常に近い値です。これは、TiDBの分離レベル`read committed`の実装により、トランザクション内のすべてのSQL文がPDにTSOを要求する必要があるためです。 -TiDB v6.0 は`rc read`提供します。これは`tso cmd`削減することで`read committed`分離レベルを最適化します。この機能はグローバル変数`set global tidb_rc_read_check_ts=on;`によって制御されます。この変数を有効にすると、TiDB のデフォルトの動作は`repeatable-read`分離レベルと同じように動作し、PD から取得する必要があるのは`start-ts`と`commit-ts`です。トランザクション内のステートメントは、最初に`start-ts`使用して TiKV からデータを読み取ります。TiKV から読み取られたデータが`start-ts`より前の場合、データは直接返されます。TiKV から読み取られたデータが`start-ts`より後の場合、データは破棄されます。TiDB は PD から TSO を要求し、読み取りを再試行します。後続のステートメントの`for update ts`では、最新の PD TSO が使用されます。 +TiDB v6.0 は`rc read`提供します。これは`tso cmd`削減することで`read committed`分離レベルを最適化します。この機能はグローバル変数`set global tidb_rc_read_check_ts=on;`によって制御されます。この変数を有効にすると、TiDB のデフォルトの動作は`repeatable-read`分離レベルと同じように動作し、PD から取得する必要があるのは`start-ts`と`commit-ts`です。トランザクション内のステートメントは、最初に`start-ts`を使用して TiKV からデータを読み取ります。TiKV から読み取られたデータが`start-ts`より前の場合、データは直接返されます。TiKV から読み取られたデータが`start-ts`より後の場合、データは破棄されます。TiDB は PD から TSO を要求し、読み取りを再試行します。後続のステートメントの`for update ts`では、最新の PD TSO が使用されます。 ## シナリオ6: tidb_rc_read_check_ts変数を有効にしてTSOリクエストを削減する {#scenario-6-enable-the-code-tidb-rc-read-check-ts-code-variable-to-reduce-tso-requests} diff --git a/pessimistic-transaction.md b/pessimistic-transaction.md index 68a100174b989..20d3744bd4b95 100644 --- a/pessimistic-transaction.md +++ b/pessimistic-transaction.md @@ -108,7 +108,7 @@ TiDB の悲観的なトランザクションは、MySQL のトランザクショ 2. TiDB は`SELECT LOCK IN SHARE MODE`をサポートしていません。 - TiDB はデフォルトでは`SELECT LOCK IN SHARE MODE`構文をサポートしていません。tidb_enable_noop_functions [`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)有効にすることで、TiDB を`SELECT LOCK IN SHARE MODE`構文と互換性を持たせることができます。 `SELECT LOCK IN SHARE MODE`実行しても、ロックなしの場合と同じ効果が得られるため、他のトランザクションの読み取りまたは書き込み操作をブロックすることはありません。 + TiDB はデフォルトでは`SELECT LOCK IN SHARE MODE`構文をサポートしていません。tidb_enable_noop_functions [`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)有効にすることで、TiDB を`SELECT LOCK IN SHARE MODE`構文と互換性を持たせることができます。 `SELECT LOCK IN SHARE MODE`を実行しても、ロックなしの場合と同じ効果が得られるため、他のトランザクションの読み取りまたは書き込み操作をブロックすることはありません。 TiDB は v8.3.0 以降、 [`tidb_enable_shared_lock_promotion`](/system-variables.md#tidb_enable_shared_lock_promotion-new-in-v830)システム変数を使用して`SELECT LOCK IN SHARE MODE`ステートメントを有効にしてロックを追加することをサポートしています。ただし、この時点で追加されるロックは真の共有ロックではなく、 `SELECT FOR UPDATE`と互換性のある排他ロックであることに注意してください。読み取り中に並列書き込みトランザクションによってデータが変更されないように書き込みをブロックしつつ、TiDB を`SELECT LOCK IN SHARE MODE`構文と互換性を維持したい場合は、この変数を有効にできます。この変数を有効にすると、 [`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)が有効になっているかどうかに関係なく、 `SELECT LOCK IN SHARE MODE`ステートメントに影響します。 diff --git a/pipelined-dml.md b/pipelined-dml.md index 51f04639ac86e..33ece11024b9d 100644 --- a/pipelined-dml.md +++ b/pipelined-dml.md @@ -132,7 +132,7 @@ SELECT @@tidb_last_txn_info; ### パイプライン DML を使用してクエリが実行されなかったのはなぜですか? {#why-wasn-t-my-query-executed-using-pipelined-dml} -TiDBがパイプラインDMLを使用したステートメントの実行を拒否した場合、それに応じた警告メッセージが生成されます。1 `SHOW WARNINGS;`実行すると警告の内容を確認し、原因を特定できます。 +TiDBがパイプラインDMLを使用したステートメントの実行を拒否した場合、それに応じた警告メッセージが生成されます。1 `SHOW WARNINGS;`を実行すると警告の内容を確認し、原因を特定できます。 一般的な理由: diff --git a/privilege-management.md b/privilege-management.md index 9325d6e9855c5..3005afceb352c 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -244,7 +244,7 @@ SHOW GRANTS FOR `rw_user`@`192.168.%`; - `RESTRICTED_VARIABLES_ADMIN`は、SEM が有効になっている場合に、権限所有者がすべてのシステム変数を表示できるようにします。 - `RESTRICTED_USER_ADMIN` SEM が有効になっている場合、特権所有者が SUPER ユーザーによってアクセス権を取り消されることを禁止します。 - `RESTRICTED_CONNECTION_ADMIN`権限所有者が`RESTRICTED_USER_ADMIN`ユーザーの接続を強制終了することを許可します。この権限は`KILL`および`KILL TIDB`ステートメントに影響します。 -- `RESTRICTED_REPLICA_WRITER_ADMIN`使用すると、TiDB クラスタで読み取り専用モードが有効になっている場合でも、権限所有者は影響を受けることなく書き込みまたは更新操作を実行できます。詳細については、 [`tidb_restricted_read_only`](/system-variables.md#tidb_restricted_read_only-new-in-v520)参照してください。 +- `RESTRICTED_REPLICA_WRITER_ADMIN`を使用すると、TiDB クラスタで読み取り専用モードが有効になっている場合でも、権限所有者は影響を受けることなく書き込みまたは更新操作を実行できます。詳細については、 [`tidb_restricted_read_only`](/system-variables.md#tidb_restricted_read_only-new-in-v520)参照してください。 動的権限の全セットを確認するには、 `SHOW PRIVILEGES`ステートメントを実行してください。プラグインは新しい権限を追加できるため、割り当て可能な権限のリストは、TiDB のインストール環境によって異なる場合があります。 diff --git a/read-historical-data.md b/read-historical-data.md index a6610a8210ec4..38096a8b21eef 100644 --- a/read-historical-data.md +++ b/read-historical-data.md @@ -5,7 +5,7 @@ summary: システム変数 tidb_snapshot` を使用して、TiDB が履歴バ # システム変数tidb_snapshotを使用して履歴データを読み取る {#read-historical-data-using-the-system-variable-code-tidb-snapshot-code} -このドキュメントでは、システム変数`tidb_snapshot`使用して履歴バージョンからデータを読み取る方法について説明します。これには、履歴データを保存するための具体的な使用例と戦略も含まれます。 +このドキュメントでは、システム変数`tidb_snapshot`を使用して履歴バージョンからデータを読み取る方法について説明します。これには、履歴データを保存するための具体的な使用例と戦略も含まれます。 > **注記：** > @@ -119,7 +119,7 @@ TiDBでは、ガベージコレクション（GC）が定期的に実行され > **注記：** > - > `@@`システム変数を示すのに使用され、 `@`ユーザー変数を示すのに使用されるため、 `tidb_snapshot`前に`@`ではなく`@@`使用する必要があります。 + > `@@`システム変数を示すのに使用され、 `@`ユーザー変数を示すのに使用されるため、 `tidb_snapshot`前に`@`ではなく`@@`を使用する必要があります。 **結果:**次のステートメントから読み取られるのは、更新操作前のデータ、つまり履歴データです。 @@ -156,7 +156,7 @@ TiDBでは、ガベージコレクション（GC）が定期的に実行され > **注記：** > - > `@@`システム変数を示すのに使用され、 `@`ユーザー変数を示すのに使用されるため、 `tidb_snapshot`前に`@`ではなく`@@`使用する必要があります。 + > `@@`システム変数を示すのに使用され、 `@`ユーザー変数を示すのに使用されるため、 `tidb_snapshot`前に`@`ではなく`@@`を使用する必要があります。 ## 履歴データを復元する方法 {#how-to-restore-historical-data} diff --git a/releases/release-1.0.8.md b/releases/release-1.0.8.md index 9816416182acf..18250d1638388 100644 --- a/releases/release-1.0.8.md +++ b/releases/release-1.0.8.md @@ -29,7 +29,7 @@ summary: TiDB 1.0.8がリリースされました。このアップデートに ## TiKV {#tikv} - [`DeleteFilesInRanges`を使用して古いデータを消去し、TiKVの起動速度を向上させます](https://github.com/pingcap/tikv/pull/2740) -- [コプロセッサーの合計に`Decimal`使用する](https://github.com/pingcap/tikv/pull/2754) +- [コプロセッサーの合計に`Decimal`を使用する](https://github.com/pingcap/tikv/pull/2754) - [受信したスナップショットのメタデータを強制的に同期して安全性を確保します](https://github.com/pingcap/tikv/pull/2758) 1.0.7 から 1.0.8 にアップグレードするには、PD -> TiKV -> TiDB のローリング アップグレード順序に従います。 diff --git a/releases/release-1.1-alpha.md b/releases/release-1.1-alpha.md index df9275a092a3a..01ce7fbfea608 100644 --- a/releases/release-1.1-alpha.md +++ b/releases/release-1.1-alpha.md @@ -15,7 +15,7 @@ summary: 2018年1月19日にリリースされたTiDB 1.1 Alphaでは、MySQLと - よりコンパクトな構造を使用して、統計情報のメモリ使用量を削減します - tidb-server の起動時に統計情報の読み込みを高速化 - より正確なクエリコスト評価を提供する - - `Count-Min Sketch`使用すると、一意インデックスを使用したクエリのコストをより正確に見積もることができます。 + - `Count-Min Sketch`を使用すると、一意インデックスを使用したクエリのコストをより正確に見積もることができます。 - インデックスを最大限に活用するために、より複雑な条件をサポートします - SQLエグゼキューター - Chunkアーキテクチャを使用してすべてのエグゼキュータ演算子をリファクタリングし、分析ステートメントの実行パフォーマンスを向上させ、メモリ使用量を削減します。 diff --git a/releases/release-1.1-beta.md b/releases/release-1.1-beta.md index 43952583a4281..05f0c5c267fc6 100644 --- a/releases/release-1.1-beta.md +++ b/releases/release-1.1-beta.md @@ -42,7 +42,7 @@ summary: 2018年2月24日にリリースされたTiDB 1.1ベータ版では、My - GC 速度を向上させるために、バッチでロックを解決することをサポート - GCの同時実行をサポートしてGC速度を向上 - PDスケジュールをより正確にするために、RocksDBコンパクションリスナーを使用してリージョンサイズを更新します。 -- `DeleteFilesInRanges`使用して古いデータを一括削除し、TiKV の起動を高速化します。 +- `DeleteFilesInRanges`を使用して古いデータを一括削除し、TiKV の起動を高速化します。 - 保持されたファイルが多くのスペースを占有しないように、 Raftスナップショットの最大サイズを設定します。 - `tikv-ctl`のリカバリ操作でより多くの回復操作をサポート - 順序付きフロー集約操作を最適化する diff --git a/releases/release-2.0-ga.md b/releases/release-2.0-ga.md index 1919615ba76d8..9ffea620710d1 100644 --- a/releases/release-2.0-ga.md +++ b/releases/release-2.0-ga.md @@ -14,7 +14,7 @@ summary: 2018年4月27日にリリースされたTiDB 2.0 GAでは、MySQLとの - tidb-server プロセスを起動するときに統計情報の読み込みを高速化します - 統計情報の動的な更新をサポート [実験的] - コストモデルを最適化して、より正確なクエリコスト評価を提供します - - `Count-Min Sketch`使用すると、ポイントクエリのコストをより正確に見積もることができます。 + - `Count-Min Sketch`を使用すると、ポイントクエリのコストをより正確に見積もることができます。 - インデックスを最大限に活用するために、より複雑な条件の分析をサポート - `STRAIGHT_JOIN`構文を使用して`Join`順序を手動で指定することをサポートします - `GROUP BY`句が空の場合は、パフォーマンスを向上させるためにストリーム集計演算子を使用します。 @@ -108,13 +108,13 @@ summary: 2018年4月27日にリリースされたTiDB 2.0 GAでは、MySQLとの - SST ファイルをインポートするための`ImportSST` API をサポート [実験的] - TiKV インポーターバイナリを追加してTiDB Lightningと統合し、データを素早くインポートします [実験的] - パフォーマンス - - `ReadPool`使用して読み取りパフォーマンスを最適化し、 `raw_get/get/batch_get`を30％増加させます + - `ReadPool`を使用して読み取りパフォーマンスを最適化し、 `raw_get/get/batch_get`を30％増加させます - メトリクスのパフォーマンスを向上させる - Raftショットプロセスが完了したらすぐにPDに通知して、バランス調整を高速化します。 - RocksDBのフラッシュによって発生するパフォーマンスジッターを解決する - データを削除した後のスペース回収メカニズムを最適化 - サーバーの起動時にガベージクリーンアップを高速化 - - `DeleteFilesInRanges`使用してレプリカ移行中のI/Oオーバーヘッドを削減 + - `DeleteFilesInRanges`を使用してレプリカ移行中のI/Oオーバーヘッドを削減 - 安定性 - PDリーダーが切り替わったときにgRPC呼び出しが返されない問題を修正しました - スナップショットによってノードがオフラインになる速度が遅くなる問題を修正しました diff --git a/releases/release-2.0-rc.3.md b/releases/release-2.0-rc.3.md index 7b59526f90955..c9ee9d9718b18 100644 --- a/releases/release-2.0-rc.3.md +++ b/releases/release-2.0-rc.3.md @@ -17,7 +17,7 @@ summary: 2018年3月23日にリリースされたTiDB 2.0 RC3では、MySQLと - メモリ制御を改善し、 `IndexLookupExecutor`メモリに関する統計情報を追加します - `ADD INDEX`の実行速度を最適化して、いくつかのシナリオで速度を大幅に向上させます - `GROUP BY`サブステートメントが空の場合にストリーム集計演算子を使用して速度を上げます -- `STRAIGHT_JOIN`使用してオプティマイザの`Join Reorder`最適化を閉じることをサポート +- `STRAIGHT_JOIN`を使用してオプティマイザの`Join Reorder`最適化を閉じることをサポート - DDLジョブのより詳細なステータス情報を`ADMIN SHOW DDL JOBS`で出力します - `ADMIN SHOW DDL JOB QUERIES`を使用して現在実行中のDDLジョブの元のステートメントを照会する機能をサポート - 災害復旧のために`ADMIN RECOVER INDEX`を使用してインデックスデータの復旧をサポート @@ -55,5 +55,5 @@ summary: 2018年3月23日にリリースされたTiDB 2.0 RC3では、MySQLと - サーバー起動時のガベージクリーンアップを高速化 - 圧縮イベントに応じて対応するリージョンのサイズ情報を更新します - リクエストのタイムアウトを回避するためにサイズを`scan lock`に制限します -- `DeleteRange`使用すると、リージョンの削除が高速化されます +- `DeleteRange`を使用すると、リージョンの削除が高速化されます - RocksDBパラメータのオンライン変更をサポート diff --git a/releases/release-2.0-rc.4.md b/releases/release-2.0-rc.4.md index d64eb691a8868..f172f8150909c 100644 --- a/releases/release-2.0-rc.4.md +++ b/releases/release-2.0-rc.4.md @@ -24,7 +24,7 @@ summary: 2018年3月30日にリリースされたTiDB 2.0 RC4では、MySQLと ## PD {#pd} - 単一リージョン内のホットスポットを処理するために、リージョンを手動で分割することをサポートします。 -- `pdctl` `config show all`実行するとラベルプロパティが表示されない問題を修正しました +- `pdctl` `config show all`を実行するとラベルプロパティが表示されない問題を修正しました - メトリクスとコード構造を最適化する ## TiKV {#tikv} diff --git a/releases/release-2.0.3.md b/releases/release-2.0.3.md index cdd00cd2c2e8b..a3acf15746b77 100644 --- a/releases/release-2.0.3.md +++ b/releases/release-2.0.3.md @@ -23,7 +23,7 @@ summary: TiDB 2.0.3は、システムの互換性と安定性の向上を伴い - 特定の式パラメータで`MAX` `MIN`panic問題を修正 - 特殊な条件で結果`JOIN`がnullになる問題を修正 - 範囲の構築とクエリ時の`IN`式の問題を修正 -- `Prepare`使用してクエリを実行し、 `Plan Cache`有効になっている場合の範囲計算の問題を修正しました +- `Prepare`を使用してクエリを実行し、 `Plan Cache`有効になっている場合の範囲計算の問題を修正しました - 異常な状況でスキーマ情報が頻繁に読み込まれる問題を修正 ## PD {#pd} diff --git a/releases/release-2.1-beta.md b/releases/release-2.1-beta.md index 7db1dd708492c..f2bf636c6b9ea 100644 --- a/releases/release-2.1-beta.md +++ b/releases/release-2.1-beta.md @@ -75,10 +75,10 @@ summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイ - Rustをバージョン`nightly-2018-06-14`にアップグレードする - `Raft PreVote`有効にすると、ネットワーク分離後にネットワークが回復したときに生成されるリーダーの再選出を回避します。 -- RocksDBの各レイヤーのファイル数と関連情報`ingest`表示するメトリックを追加します。 +- RocksDBの各レイヤーのファイル数と関連情報`ingest`を表示するメトリックを追加します。 - GC が機能しているときにバージョンが多すぎると`key`印刷する -- `static metric`使用してマルチラベルメトリックのパフォーマンスを最適化します（YCSB `raw get` 3％向上します） +- `static metric`を使用してマルチラベルメトリックのパフォーマンスを最適化します（YCSB `raw get` 3％向上します） - 複数のモジュールから`box`削除し、パターンを使用して動作パフォーマンスを改善します（YCSB `raw get` 3％向上します） -- `asynchronous log`使用するとログの書き込みパフォーマンスが向上します +- `asynchronous log`を使用するとログの書き込みパフォーマンスが向上します - スレッドのステータスを収集するためのメトリックを追加する - アプリケーションで使用される`box`を減らすことでメモリコピー回数を減らし、パフォーマンスを向上させます diff --git a/releases/release-2.1-rc.1.md b/releases/release-2.1-rc.1.md index e44d16356a14b..94a42c3f4ac58 100644 --- a/releases/release-2.1-rc.1.md +++ b/releases/release-2.1-rc.1.md @@ -132,7 +132,7 @@ summary: TiDB 2.1 RC1は2018年8月24日にリリースされ、安定性、SQL - ホットリージョンへの書き込み操作によってリージョンが大きくなりすぎるのを避けるために`batch split`サポートします - インデックススキャンの効率を向上させるために、行数に基づいてリージョンを分割することをサポートします。 - パフォーマンス - - `LocalReader`使用して読み取り操作をraftstoreスレッドから分離し、読み取りレイテンシーを低下させます。 + - `LocalReader`を使用して読み取り操作をraftstoreスレッドから分離し、読み取りレイテンシーを低下させます。 - MVCCフレームワークをリファクタリングし、メモリ使用量を最適化してスキャン読み取りパフォーマンスを改善します。 - I/O使用量を削減するために統計推定に基づいてリージョンを分割する機能をサポート - ロールバックレコードへの連続書き込み操作によって読み取りパフォーマンスが影響を受ける問題を最適化します。 diff --git a/releases/release-2.1-rc.5.md b/releases/release-2.1-rc.5.md index d2f503009c26d..0ddea573a9013 100644 --- a/releases/release-2.1-rc.5.md +++ b/releases/release-2.1-rc.5.md @@ -40,7 +40,7 @@ summary: TiDB 2.1 RC5は2018年11月12日にリリースされ、安定性、SQL - ticlientの`Scan`コマンドに上限を追加して、オーバーバウンドスキャン 回避する [＃8247](https://github.com/pingcap/tidb/pull/8247) [＃8081](https://github.com/pingcap/tidb/pull/8081) - DDL - トランザクション内でDDL文を実行するとエラーが発生する場合がある問題を修正[＃8056](https://github.com/pingcap/tidb/pull/8056) - - パーティションテーブルで`truncate table`実行しても効果がない問題を修正[＃8103](https://github.com/pingcap/tidb/pull/8103) + - パーティションテーブルで`truncate table`を実行しても効果がない問題を修正[＃8103](https://github.com/pingcap/tidb/pull/8103) - 一部のケースでDDL操作がキャンセルされた後に正しくロールバックされない問題を修正しました[＃8057](https://github.com/pingcap/tidb/pull/8057) - 次の利用可能な行ID を返すコマンド`admin show next_row_id`を追加します。 [＃8268](https://github.com/pingcap/tidb/pull/8268) diff --git a/releases/release-2.1.10.md b/releases/release-2.1.10.md index d1c52d17555d8..e6453bff15dc4 100644 --- a/releases/release-2.1.10.md +++ b/releases/release-2.1.10.md @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 2.1.10 ## TiDB {#tidb} -- `tidb_snapshot`使用して履歴データ読み取るときに、一部の異常によりテーブル スキーマが正しくなくなる問題を修正しました。 [＃10359](https://github.com/pingcap/tidb/pull/10359) +- `tidb_snapshot`を使用して履歴データ読み取るときに、一部の異常によりテーブル スキーマが正しくなくなる問題を修正しました。 [＃10359](https://github.com/pingcap/tidb/pull/10359) - `NOT`関数が場合によっては誤った読み取り結果を引き起こす問題を修正[＃10363](https://github.com/pingcap/tidb/pull/10363) - `Replace`または`Insert on duplicate update`ステートメントの`Generated Column`の誤った動作を修正します [＃10385](https://github.com/pingcap/tidb/pull/10385) - `DATE` `DATETIME` の`BETWEEN`機能のバグを修正 [＃10407](https://github.com/pingcap/tidb/pull/10407) diff --git a/releases/release-2.1.13.md b/releases/release-2.1.13.md index b56770f283b73..fad50cfe701f3 100644 --- a/releases/release-2.1.13.md +++ b/releases/release-2.1.13.md @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 2.1.13 ## TiDB {#tidb} -- ホットスポットの問題を軽減するために、列に`AUTO_INCREMENT`属性が含まれている場合に`SHARD_ROW_ID_BITS`使用して行 ID を分散させる機能を追加します[＃10788](https://github.com/pingcap/tidb/pull/10788) +- ホットスポットの問題を軽減するために、列に`AUTO_INCREMENT`属性が含まれている場合に`SHARD_ROW_ID_BITS`を使用して行 ID を分散させる機能を追加します[＃10788](https://github.com/pingcap/tidb/pull/10788) - 無効な DDL メタデータの有効期間を最適化して、TiDB クラスタアップグレード後に DDL 操作の通常の実行を回復する速度を向上します。 [＃10789](https://github.com/pingcap/tidb/pull/10789) - `execdetails.ExecDetails`ポインタの結果としてコプロセッサーリソースを迅速に解放できないことによって引き起こされる、高同時シナリオでのOOM問題を修正しました。 [＃10833](https://github.com/pingcap/tidb/pull/10833) - 統計情報を更新するかどうかを制御する`update-stats`構成項目を追加します[＃10772](https://github.com/pingcap/tidb/pull/10772) diff --git a/releases/release-2.1.19.md b/releases/release-2.1.19.md index 85565b7678af1..801daa6203ccc 100644 --- a/releases/release-2.1.19.md +++ b/releases/release-2.1.19.md @@ -22,7 +22,7 @@ TiDB Ansible バージョン: 2.1.19 - `minAutoAnalyzeRatio`制約を取り除き、自動`ANALYZE`をよりタイムリーにする [＃14013](https://github.com/pingcap/tidb/pull/14013) - `WHERE`句に一意キー等号条件が含まれている場合に推定行数が`1`より大きくなる問題を修正しました。 [＃13385](https://github.com/pingcap/tidb/pull/13385) - SQL実行エンジン - - `ConvertJSONToInt` で`unit64`中間結果として`int64`使用するときに精度オーバーフローが発生する問題を修正しました。 [＃13036](https://github.com/pingcap/tidb/pull/13036) + - `ConvertJSONToInt` で`unit64`中間結果として`int64`を使用するときに精度オーバーフローが発生する問題を修正しました。 [＃13036](https://github.com/pingcap/tidb/pull/13036) - クエリに`SLEEP`関数が含まれている場合（たとえば`select 1 from (select sleep(1)) t;)` ）、列の整理によってクエリ内の`sleep(1)`無効になる問題を修正しました[＃13039](https://github.com/pingcap/tidb/pull/13039) - `INSERT ON DUPLICATE UPDATE`文で`Chunk`再利用してメモリのオーバーヘッドを削減します [＃12999](https://github.com/pingcap/tidb/pull/12999) - `slow_query`テーブルにトランザクション関連のフィールドを追加します。 [＃13129](https://github.com/pingcap/tidb/pull/13129) @@ -58,7 +58,7 @@ TiDB Ansible バージョン: 2.1.19 - TiDBサーバーのバージョンを制御および変更するための`server-version`構成項目を追加します。 [＃13904](https://github.com/pingcap/tidb/pull/13904) - Go1.13でコンパイルされたバイナリ`plugin`正常に動作しない問題を修正[＃13527](https://github.com/pingcap/tidb/pull/13527) - DDL - - テーブルが作成され、テーブルに`COLLATE` が含まれている場合、列のシステムのデフォルトの文字セットの代わりにテーブルの`COLLATE`使用します。 [＃13190](https://github.com/pingcap/tidb/pull/13190) + - テーブルが作成され、テーブルに`COLLATE` が含まれている場合、列のシステムのデフォルトの文字セットの代わりにテーブルの`COLLATE`を使用します。 [＃13190](https://github.com/pingcap/tidb/pull/13190) - テーブルを作成するときにインデックス名の長さを制限する [＃13311](https://github.com/pingcap/tidb/pull/13311) - テーブル名を変更するときにテーブル名の長さがチェックされない問題を修正[＃13345](https://github.com/pingcap/tidb/pull/13345) - `BIT`列の幅の範囲を確認する [＃13511](https://github.com/pingcap/tidb/pull/13511) diff --git a/releases/release-2.1.8.md b/releases/release-2.1.8.md index ee6e303aa9719..724786410ab1f 100644 --- a/releases/release-2.1.8.md +++ b/releases/release-2.1.8.md @@ -50,7 +50,7 @@ TiDB Ansible バージョン: 2.1.8 ## ツール {#tools} -- Lightning のテーブルインポートの順序を最適化して、インポートプロセス中にクラスター上で`Checksum`と`Analyze`実行する大きなテーブルの影響を軽減し、 `Checksum`と`Analyze`の成功率を向上させます[＃156](https://github.com/pingcap/tidb-lightning/pull/156) +- Lightning のテーブルインポートの順序を最適化して、インポートプロセス中にクラスター上で`Checksum`と`Analyze`を実行する大きなテーブルの影響を軽減し、 `Checksum`と`Analyze`の成功率を向上させます[＃156](https://github.com/pingcap/tidb-lightning/pull/156) - KVエンコーダの追加解析作業を回避するために、データソースファイルの内容をTiDBの`types.Datum`に直接解析することで、LightningのエンコードSQLパフォーマンスを50％向上しました。 [＃145](https://github.com/pingcap/tidb-lightning/pull/145) - TiDB Binlog Pumpに`storage.sync-log`構成項目を追加して、 Pump でローカルストレージのディスクを非同期にフラッシュすることをサポートします。 [＃529](https://github.com/pingcap/tidb-binlog/pull/529) - TiDB Binlog PumpとDrainer 間の通信のトラフィック圧縮をサポート [＃530](https://github.com/pingcap/tidb-binlog/pull/530) diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index 1caca0bfca048..5cacf6c13f8cd 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -33,7 +33,7 @@ TiDB Ansible バージョン: 3.0.0 - SQLオプティマイザー - `NOT EXISTS`サブクエリを最適化し、 `Anti Semi Join`に変換してパフォーマンスを向上させます - `Outer Join`の定数伝播を最適化し、 `Outer Join`除去の最適化ルールを追加して、効果のない計算を減らし、パフォーマンスを向上させます。 - - パフォーマンスを向上させるために、集計後に`IN`サブクエリを`Inner Join`実行するように最適化します。 + - パフォーマンスを向上させるために、集計後に`IN`サブクエリを`Inner Join`を実行するように最適化します。 - `Index Join`最適化してより多くのシナリオに適応する - レンジパーティションのパーティションプルーニング最適化ルールの改善 - `_tidb_rowid`のクエリロジックを最適化して、テーブル全体のスキャンを回避し、パフォーマンスを向上させます。 @@ -76,7 +76,7 @@ TiDB Ansible バージョン: 3.0.0 - `CREATE TABLE`ステートメントを使用してテーブルを作成するときに、リージョンを事前に割り当てる`pre_split_regions`オプションを追加して、テーブル作成後の大量の書き込みによって発生する書き込みホットリージョンを軽減します。 - ホットスポットの問題を軽減するために、SQL ステートメントを使用して指定されたテーブルのインデックスと範囲でリージョンを分割することをサポートします。 - DDLタスクの再試行回数を制限するために`ddl_error_count_limit`グローバル変数を追加します。 - - ホットスポットの問題を軽減するために、列に AUTO_INCREMENT 属性が含まれている場合に行 ID を分散するために`SHARD_ROW_ID_BITS`使用する機能を追加します。 + - ホットスポットの問題を軽減するために、列に AUTO_INCREMENT 属性が含まれている場合に行 ID を分散するために`SHARD_ROW_ID_BITS`を使用する機能を追加します。 - 無効な DDL メタデータの有効期間を最適化して、TiDB クラスタのアップグレード後に DDL 操作の通常の実行を回復する速度を向上します。 - トランザクション - 悲観的トランザクションモードをサポート（**Experimental**） @@ -87,7 +87,7 @@ TiDB Ansible バージョン: 3.0.0 - 分離レベルがSERIALIZABLEに設定されている場合にエラーを報告するかどうかを制御する`tidb_skip_isolation_level_check`変数を追加します。 - `tidb_disable_txn_auto_retry`システム変数を変更して、再試行可能なすべてのエラーで機能するようにします。 - 権限管理 - - `ANALYZE` `USE`ステートメント`SET GLOBAL`権限チェック`SHOW PROCESSLIST`実行する + - `ANALYZE` `USE`ステートメント`SET GLOBAL`権限チェック`SHOW PROCESSLIST`を実行する - ロールベースのアクセス制御 (RBAC) をサポート (**Experimental**) - サーバ - スロークエリ ログを最適化します。 @@ -96,7 +96,7 @@ TiDB Ansible バージョン: 3.0.0 - メモリテーブルの`INFORMATION_SCHEMA.SLOW_QUERY`と`ADMIN SHOW SLOW`ステートメントを使用してスロー クエリ ログをクエリできるように、ログ クエリ メソッドを最適化します。 - ツールによる収集と分析を容易にするために、ログシステムを再構築し、統一されたログフォーマット仕様を開発する - ステータスのクエリ、TiDB Binlog の有効化、TiDB Binlog戦略の維持と送信など、SQL ステートメントを使用した TiDB Binlogサービスの管理をサポートします。 - - `unix_socket`使用してデータベースに接続することをサポートします + - `unix_socket`を使用してデータベースに接続することをサポートします - SQL文のサポート`Trace` - トラブルシューティングを容易にするために、 `/debug/zip` HTTP インターフェースを介して TiDB インスタンスの情報を取得することをサポートします。 - トラブルシューティングを容易にするために監視項目を最適化します。 diff --git a/releases/release-3.0.0-rc.1.md b/releases/release-3.0.0-rc.1.md index 5983b6c1735eb..c054b7ebc2beb 100644 --- a/releases/release-3.0.0-rc.1.md +++ b/releases/release-3.0.0-rc.1.md @@ -55,7 +55,7 @@ TiDB Ansible バージョン: 3.0.0-rc.1 - TiDB の古いバージョンにおける UTF8 および UTF8MB4 文字セットの互換性の問題を修正しました [＃9820](https://github.com/pingcap/tidb/pull/9820) - 表の`shard_row_id_bits`の潜在的なバグを修正 [＃9868](https://github.com/pingcap/tidb/pull/9868) - テーブルの文字セットを変更しても列の文字セットが変更されないバグを修正[＃9790](https://github.com/pingcap/tidb/pull/9790) - - 列のデフォルト値として`BINARY` / `BIT`使用する場合の`SHOW COLUMN`の潜在的なバグを修正[＃9897](https://github.com/pingcap/tidb/pull/9897) + - 列のデフォルト値として`BINARY` / `BIT`を使用する場合の`SHOW COLUMN`の潜在的なバグを修正[＃9897](https://github.com/pingcap/tidb/pull/9897) - `SHOW FULL COLUMNS`文で`CHARSET` `COLLATION`説明を表示する際の互換性の問題を修正 [＃10007](https://github.com/pingcap/tidb/pull/10007) - `SHOW COLLATIONS`文が TiDB でサポートされている照合順序のみをリストする問題を修正しました [＃10186](https://github.com/pingcap/tidb/pull/10186) diff --git a/releases/release-3.0.0-rc.3.md b/releases/release-3.0.0-rc.3.md index 3d1494ee8be4a..b7a629ad236ae 100644 --- a/releases/release-3.0.0-rc.3.md +++ b/releases/release-3.0.0-rc.3.md @@ -21,7 +21,7 @@ TiDB Ansible バージョン: 3.0.0-rc.3 - 仮想生成列統計を収集する機能を削除します [＃10629](https://github.com/pingcap/tidb/pull/10629) - ポイントクエリ中に主キー定数がオーバーフローする問題を修正[＃10699](https://github.com/pingcap/tidb/pull/10699) - `fast analyze`で初期化されていない情報を使用するとpanicが発生する問題を修正[＃10691](https://github.com/pingcap/tidb/pull/10691) - - `prepare`使用して`create view`文を実行すると、間違った列情報のためにpanicが発生する問題を修正しました [＃10713](https://github.com/pingcap/tidb/pull/10713) + - `prepare`を使用して`create view`文を実行すると、間違った列情報のためにpanicが発生する問題を修正しました [＃10713](https://github.com/pingcap/tidb/pull/10713) - ウィンドウ関数処理時に列情報が複製されない問題を修正 [＃10720](https://github.com/pingcap/tidb/pull/10720) - インデックス結合における内部テーブル選択の選択率の誤った推定を修正 [＃10854](https://github.com/pingcap/tidb/pull/10854) - `stats-lease`変数値が0の場合の自動読み込み統計をサポート[＃10811](https://github.com/pingcap/tidb/pull/10811) @@ -53,7 +53,7 @@ TiDB Ansible バージョン: 3.0.0-rc.3 - DDL - `alter table`を使用して文字セットを変更すると`blob`型が変更される問題を修正[＃10698](https://github.com/pingcap/tidb/pull/10698) - - ホットスポットの問題を軽減するために、列に`AUTO_INCREMENT`属性が含まれている場合に`SHARD_ROW_ID_BITS`使用して行 ID を分散させる機能を追加します[＃10794](https://github.com/pingcap/tidb/pull/10794) + - ホットスポットの問題を軽減するために、列に`AUTO_INCREMENT`属性が含まれている場合に`SHARD_ROW_ID_BITS`を使用して行 ID を分散させる機能を追加します[＃10794](https://github.com/pingcap/tidb/pull/10794) - `alter table`文を使用して、保存された生成列の追加を禁止します。 [＃10808](https://github.com/pingcap/tidb/pull/10808) - DDLメタデータの無効な生存時間を最適化し、クラスタのアップグレード後にDDL操作が遅くなる期間を短縮します[＃10795](https://github.com/pingcap/tidb/pull/10795) diff --git a/releases/release-3.0.11.md b/releases/release-3.0.11.md index 10efd7f064031..755c0695c5c4a 100644 --- a/releases/release-3.0.11.md +++ b/releases/release-3.0.11.md @@ -37,12 +37,12 @@ TiDB Ansible バージョン: 3.0.11 ## バグ修正 {#bug-fixes} - TiDB - - `Union`使用するクエリが読み取り専用としてマークされていないため、楽観的トランザクションを再試行するときに Goroutine リークが発生する問題を修正しました[＃15076](https://github.com/pingcap/tidb/pull/15076) + - `Union`を使用するクエリが読み取り専用としてマークされていないため、楽観的トランザクションを再試行するときに Goroutine リークが発生する問題を修正しました[＃15076](https://github.com/pingcap/tidb/pull/15076) - `SET SESSION tidb_snapshot = 'xxx';`ステートメント実行時に`tidb_snapshot`パラメータの値が正しく使用されていないため、スナップショット時に`SHOW TABLE STATUS`でテーブルの状態を正しく出力できない問題を修正しました [＃14391](https://github.com/pingcap/tidb/pull/14391) - `Sort Merge Join`と`ORDER BY DESC`同時に含まれるSQL文によって発生する誤った結果を修正する[＃14664](https://github.com/pingcap/tidb/pull/14664) - サポートされていない式を使用してパーティションテーブルを作成する際にTiDBサーバーがpanicを修正しました。このpanicを修正すると、エラー情報`This partition function is not allowed`返されます[＃14769](https://github.com/pingcap/tidb/pull/14769) - `Union` を含むサブクエリで`select max() from subquery`文を実行したときに発生した誤った結果を修正しました [＃14944](https://github.com/pingcap/tidb/pull/14944) - - 実行バインディングを削除する`DROP BINDING`実行した後に`SHOW BINDINGS`ステートメントを実行するとエラーメッセージが返される問題を修正しました [＃14865](https://github.com/pingcap/tidb/pull/14865) + - 実行バインディングを削除する`DROP BINDING`を実行した後に`SHOW BINDINGS`ステートメントを実行するとエラーメッセージが返される問題を修正しました [＃14865](https://github.com/pingcap/tidb/pull/14865) - MySQLプロトコルではクエリのエイリアスの最大長が256文字であるが、TiDBはこのプロトコルに従ってクエリ結果に[別名を切る](https://dev.mysql.com/doc/refman/8.0/en/identifier-length.html)出力しないため、接続が切断される問題を修正しました。 [＃14940](https://github.com/pingcap/tidb/pull/14940) - `DIV`で文字列型を使用した際に発生する可能性のある誤ったクエリ結果を修正しました。例えば、 `select 1 / '2007' div 1`文正しく実行できるようになりました。 [＃14098](https://github.com/pingcap/tidb/pull/14098) diff --git a/releases/release-3.0.14.md b/releases/release-3.0.14.md index 8b52639fcf225..96f2b65efab1f 100644 --- a/releases/release-3.0.14.md +++ b/releases/release-3.0.14.md @@ -82,7 +82,7 @@ TiDB バージョン: 3.0.14 - トランザクションが関連テーブルロックしないため、テーブルに対して同時 DDL 操作が実行され、ブロッキングが存在する場合に、トランザクションのコミット中に`schema change`報告される問題を修正しました。 [＃15707](https://github.com/pingcap/tidb/pull/15707) - `IF(not_int, *, *)` の誤った動作を修正 [＃15356](https://github.com/pingcap/tidb/pull/15356) - `CASE WHEN (not_int)` の誤った動作を修正 [＃15359](https://github.com/pingcap/tidb/pull/15359) - - 現在のスキーマに含まれない`view`使用すると`Unknown column`エラー メッセージが返される問題を修正しました [＃15866](https://github.com/pingcap/tidb/pull/15866) + - 現在のスキーマに含まれない`view`を使用すると`Unknown column`エラー メッセージが返される問題を修正しました [＃15866](https://github.com/pingcap/tidb/pull/15866) - 時間文字列の解析結果がMySQL と互換性がない問題を修正 [＃16242](https://github.com/pingcap/tidb/pull/16242) - `left join`の右子ノードに`null`列が存在する場合に照合順序子がpanicを修正 [＃16528](https://github.com/pingcap/tidb/pull/16528) - TiKVが`StaleCommand`エラーメッセージを返し続けているときにSQL実行がブロックされているにもかかわらずエラーメッセージが返されない問題を修正しました[＃16528](https://github.com/pingcap/tidb/pull/16528) diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index d3bb7ea323b64..ffbfb8dd56fba 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -56,7 +56,7 @@ TiDB Ansible バージョン: 3.0.2 - サーバ - CSVファイル内の欠落しているフィールド`LOAD DATA` `TIMESTAMP`処理する際に、自動的に追加された値が現在のタイムスタンプではなく0になる問題を修正しました。 [＃11250](https://github.com/pingcap/tidb/pull/11250) - `SHOW CREATE USER`文が関連する権限を正しくチェックせず、 `SHOW CREATE USER CURRENT_USER()`によって返される`USER`と`HOST`間違っている可能性がある問題を修正しました[＃11229](https://github.com/pingcap/tidb/pull/11229) - - JDBC で`executeBatch`使用すると返される結果が間違っている可能性がある問題を修正しました [＃11290](https://github.com/pingcap/tidb/pull/11290) + - JDBC で`executeBatch`を使用すると返される結果が間違っている可能性がある問題を修正しました [＃11290](https://github.com/pingcap/tidb/pull/11290) - TiKVサーバーのポートを変更するときにストリーミングクライアントのログ情報の出力を削減します [＃11370](https://github.com/pingcap/tidb/pull/11370) - ストリーミングクライアントが長時間ブロックされないように、ストリーミングクライアントをTiKVサーバーに再接続するロジックを最適化します[＃11372](https://github.com/pingcap/tidb/pull/11372) - `INFORMATION_SCHEMA.TIDB_HOT_REGIONS` に`REGION_ID`を足す [＃11350](https://github.com/pingcap/tidb/pull/11350) @@ -83,7 +83,7 @@ TiDB Ansible バージョン: 3.0.2 - 次の問題を修正しました[＃11492](https://github.com/pingcap/tidb/pull/11492) : - 照合順序を明示的に指定し、文字セットを指定していない場合、列の文字セットと照合順序が一致しません。 - `ALTER TABLE … MODIFY COLUMN`で指定された文字セットと照合順序の間に矛盾がある場合、エラーは正しく報告されません。 - - `ALTER TABLE … MODIFY COLUMN`使用して文字セットと照合順序を複数回指定すると、MySQL との互換性がなくなる + - `ALTER TABLE … MODIFY COLUMN`を使用して文字セットと照合順序を複数回指定すると、MySQL との互換性がなくなる - サブクエリのトレース詳細を`TRACE`クエリの結果に追加する [＃11458](https://github.com/pingcap/tidb/pull/11458) - `ADMIN CHECK TABLE`実行パフォーマンスを最適化し、実行時間を大幅に短縮する[＃11547](https://github.com/pingcap/tidb/pull/11547) - `SPLIT TABLE … REGIONS/INDEX`で返された結果を追加し、 `TOTAL_SPLIT_REGION`と`SCATTER_FINISH_RATIO`に、結果のタイムアウト前に正常に分割されたリージョンの数を表示するようにします。 [＃11484](https://github.com/pingcap/tidb/pull/11484) diff --git a/releases/release-3.0.20.md b/releases/release-3.0.20.md index 50d224b79c716..8f57e8f4567f6 100644 --- a/releases/release-3.0.20.md +++ b/releases/release-3.0.20.md @@ -36,7 +36,7 @@ TiDB バージョン: 3.0.20 - TiKVクライアントのgoroutineリークの問題を修正 [＃20863](https://github.com/pingcap/tidb/pull/20863) - `year`型の誤ったデフォルトのゼロ値を修正 [＃20828](https://github.com/pingcap/tidb/pull/20828) - インデックス検索結合におけるゴルーチンリークの問題を修正 [＃20791](https://github.com/pingcap/tidb/pull/20791) - - `INSERT SELECT FOR UPDATE`実行すると悲観的トランザクションで不正なパケットが返される問題を修正 [＃20681](https://github.com/pingcap/tidb/pull/20681) + - `INSERT SELECT FOR UPDATE`を実行すると悲観的トランザクションで不正なパケットが返される問題を修正 [＃20681](https://github.com/pingcap/tidb/pull/20681) - 不明なタイムゾーンを修正`'posixrules'` [＃20605](https://github.com/pingcap/tidb/pull/20605) - 符号なし整数型をビット型に変換するときに発生する問題を修正しました [＃20362](https://github.com/pingcap/tidb/pull/20362) - ビット型列の破損したデフォルト値を修正 [＃20339](https://github.com/pingcap/tidb/pull/20339) diff --git a/releases/release-3.0.3.md b/releases/release-3.0.3.md index c5bfc2698f3b5..f49640581e62a 100644 --- a/releases/release-3.0.3.md +++ b/releases/release-3.0.3.md @@ -27,7 +27,7 @@ TiDB Ansible バージョン: 3.0.3 - Pump/Drainerのステータスを変更するSQL文を実行するとpanicが発生する可能性がある問題を修正しました。 [＃11827](https://github.com/pingcap/tidb/pull/11827) - Autocommit = 1 で`begin`文がない場合に`select ... for update`でpanicが発生する可能性がある問題を修正しました[＃11736](https://github.com/pingcap/tidb/pull/11736) - `set default role`文の実行時に発生する可能性のある権限チェックエラーを修正[＃11777](https://github.com/pingcap/tidb/pull/11777) - - `create user`または`drop user`実行したときに発生する可能性のある権限チェックエラーを修正[＃11814](https://github.com/pingcap/tidb/pull/11814) + - `create user`または`drop user`を実行したときに発生する可能性のある権限チェックエラーを修正[＃11814](https://github.com/pingcap/tidb/pull/11814) - `select ... for update`文が`PointGetExecutor`関数に組み込まれると自動的に再試行される可能性がある問題を修正しました [＃11718](https://github.com/pingcap/tidb/pull/11718) - ウィンドウ関数がパーティションを処理するときに発生する可能性のある境界エラーを修正しました [＃11825](https://github.com/pingcap/tidb/pull/11825) - `time`関数が不正な形式の引数処理するときに EOF エラーが発生する問題を修正しました [＃11893](https://github.com/pingcap/tidb/pull/11893) diff --git a/releases/release-3.0.6.md b/releases/release-3.0.6.md index 39bfb49ea889b..7e11616221c07 100644 --- a/releases/release-3.0.6.md +++ b/releases/release-3.0.6.md @@ -27,8 +27,8 @@ TiDB Ansible バージョン: 3.0.6 - `INSERT ON DUPLICATE UPDATE`文で`Chunk`再利用してメモリオーバーヘッドを削減する [＃12998](https://github.com/pingcap/tidb/pull/12998) - `JSON_VALID`組み込み関数のサポートを追加 [＃13133](https://github.com/pingcap/tidb/pull/13133) - パーティションテーブルで`ADMIN CHECK TABLE`実行をサポート [＃13140](https://github.com/pingcap/tidb/pull/13140) - - 空のテーブルで`FAST ANALYZE`実行したときに発生するpanic問題を修正 [＃13343](https://github.com/pingcap/tidb/pull/13343) - - 複数列のインデックスを含む空のテーブルで`FAST ANALYZE`実行するとpanic問題を修正[＃13394](https://github.com/pingcap/tidb/pull/13394) + - 空のテーブルで`FAST ANALYZE`を実行したときに発生するpanic問題を修正 [＃13343](https://github.com/pingcap/tidb/pull/13343) + - 複数列のインデックスを含む空のテーブルで`FAST ANALYZE`を実行するとpanic問題を修正[＃13394](https://github.com/pingcap/tidb/pull/13394) - `WHERE`句に一意キー等号条件が含まれている場合に推定行数が 1 より大きくなる問題を修正しました [＃13382](https://github.com/pingcap/tidb/pull/13382) - TiDB で`Streaming`有効になっている場合に返されるデータが重複する可能性がある問題を修正しました [＃13254](https://github.com/pingcap/tidb/pull/13254) - 推定精度を向上させるために、count-minスケッチから上位N個の値を抽出します[＃13429](https://github.com/pingcap/tidb/pull/13429) @@ -63,7 +63,7 @@ TiDB Ansible バージョン: 3.0.6 - `Write_size` - `Prewrite_region` - `Txn_retry` - - テーブルが作成され、テーブルに`COLLATE` が含まれている場合、列のシステムのデフォルトの文字セットの代わりにテーブルの`COLLATE`使用します。 [＃13174](https://github.com/pingcap/tidb/pull/13174) + - テーブルが作成され、テーブルに`COLLATE` が含まれている場合、列のシステムのデフォルトの文字セットの代わりにテーブルの`COLLATE`を使用します。 [＃13174](https://github.com/pingcap/tidb/pull/13174) - テーブルを作成するときにインデックス名の長さを制限する [＃13310](https://github.com/pingcap/tidb/pull/13310) - テーブル名を変更するときにテーブル名の長さがチェックされない問題を修正[＃13346](https://github.com/pingcap/tidb/pull/13346) - TiDB で主キーの追加/削除をサポートするために、 `alter-primary-key`構成（デフォルトでは無効）を追加します。 [＃13522](https://github.com/pingcap/tidb/pull/13522) diff --git a/releases/release-3.0.8.md b/releases/release-3.0.8.md index 8be827310c7f6..6c96ef4b9076f 100644 --- a/releases/release-3.0.8.md +++ b/releases/release-3.0.8.md @@ -91,7 +91,7 @@ TiDB Ansible バージョン: 3.0.8 ## PD {#pd} - クライアント - - `context`使用してクライアントを作成し、新しいクライアントを作成するときにタイムアウト期間を設定することをサポートします。 [＃1994](https://github.com/pingcap/pd/pull/1994) + - `context`を使用してクライアントを作成し、新しいクライアントを作成するときにタイムアウト期間を設定することをサポートします。 [＃1994](https://github.com/pingcap/pd/pull/1994) - `KeepAlive`接続作成をサポート [＃2035](https://github.com/pingcap/pd/pull/2035) - `/api/v1/regions` API のパフォーマンスを最適化 [＃1986](https://github.com/pingcap/pd/pull/1986) - `tombstone`状態でストアを削除するとpanicが発生する可能性がある問題を修正[＃2038](https://github.com/pingcap/pd/pull/2038) diff --git a/releases/release-3.1.0-rc.md b/releases/release-3.1.0-rc.md index 3818654d11437..757f838372083 100644 --- a/releases/release-3.1.0-rc.md +++ b/releases/release-3.1.0-rc.md @@ -75,7 +75,7 @@ TiDB Ansible バージョン: 3.1.0-rc - TiFlashレプリカのステータスを更新するとDDL操作が停止する可能性がある問題を修正しました[＃15161](https://github.com/pingcap/tidb/pull/15161) - プッシュダウンできない述語がある場合、 `Aggregation`プッシュダウンと`TopN`プッシュダウンを禁止する[＃15141](https://github.com/pingcap/tidb/pull/15141) - ネストされた`view`作成を禁止する [＃15440](https://github.com/pingcap/tidb/pull/15440) - - `SET ROLE ALL` の後に`SELECT CURRENT_ROLE()`実行したときに発生したエラーを修正 [＃15570](https://github.com/pingcap/tidb/pull/15570) + - `SET ROLE ALL` の後に`SELECT CURRENT_ROLE()`を実行したときに発生したエラーを修正 [＃15570](https://github.com/pingcap/tidb/pull/15570) - `select view_name.col_name from view_name`文実行するときに`view`名前を識別できない問題を修正 [＃15573](https://github.com/pingcap/tidb/pull/15573) - binlog情報書き込み中にDDL文を前処理するとエラーが発生する可能性がある問題を修正 [＃15444](https://github.com/pingcap/tidb/pull/15444) - `view` s とパーティションテーブル両方にアクセスする際に発生するpanicを修正 [＃15560](https://github.com/pingcap/tidb/pull/15560) diff --git a/releases/release-3.1.1.md b/releases/release-3.1.1.md index 801401514f5f0..13529eec80c8f 100644 --- a/releases/release-3.1.1.md +++ b/releases/release-3.1.1.md @@ -32,7 +32,7 @@ TiDB Ansible バージョン: 3.1.1 - インスタンスレベルでの分離読み取り設定が有効にならない問題と、TiDB をアップグレードした後に分離読み取り設定が誤って保持される問題を修正しました[＃16482](https://github.com/pingcap/tidb/pull/16482) [＃16802](https://github.com/pingcap/tidb/pull/16802) - ハッシュパーティションテーブルのパーティション選択構文を修正し、 `partition (P0)` などの構文でエラーが報告されないようにしました。 [＃16076](https://github.com/pingcap/tidb/pull/16076) - `UPDATE` SQL 文がビューからのクエリのみ実行し、ビューを更新しない場合でも、更新文でエラーが報告される問題を修正しました[＃16789](https://github.com/pingcap/tidb/pull/16789) - - ネストされたクエリから`not not`削除することによって誤った結果が発生する問題を修正しました [＃16423](https://github.com/pingcap/tidb/pull/16423) + - ネストされたクエリから`not not`を削除することによって誤った結果が発生する問題を修正しました [＃16423](https://github.com/pingcap/tidb/pull/16423) - TiFlash diff --git a/releases/release-4.0-ga.md b/releases/release-4.0-ga.md index 2033849fa94e9..c75ba073368e4 100644 --- a/releases/release-4.0-ga.md +++ b/releases/release-4.0-ga.md @@ -80,7 +80,7 @@ TiDB バージョン: 4.0.0 - `tidb_opt_agg_push_down`が有効になっていて、集計関数がパーティションテーブルをプッシュダウンしたときに、誤った処理ロジックによって発生するシステムパニックを修正しました。 [＃17328](https://github.com/pingcap/tidb/pull/17328) - 一部のケースで障害が発生した TiKV ノードにアクセスできない問題を修正[＃17342](https://github.com/pingcap/tidb/pull/17342) - `tidb.toml`の`isolation-read`設定項目が有効にならない問題を修正[＃17322](https://github.com/pingcap/tidb/pull/17322) - - `hint`使用してストリーム集約強制する場合に、処理ロジックが間違っているために出力結果の順序が間違っている問題を修正しました。 [＃17347](https://github.com/pingcap/tidb/pull/17347) + - `hint`を使用してストリーム集約強制する場合に、処理ロジックが間違っているために出力結果の順序が間違っている問題を修正しました。 [＃17347](https://github.com/pingcap/tidb/pull/17347) - `insert`異なる`SQL_MODE` の下で DIV を処理する動作を修正 [＃17314](https://github.com/pingcap/tidb/pull/17314) - TiFlash @@ -103,7 +103,7 @@ TiDB バージョン: 4.0.0 - PD - - pd-ctl を使用して`evict-leader-scheduler`または`grant-leader-scheduler`削除するときに発生する 404 エラーを修正しました [＃2446](https://github.com/pingcap/pd/pull/2446) + - pd-ctl を使用して`evict-leader-scheduler`または`grant-leader-scheduler`を削除するときに発生する 404 エラーを修正しました [＃2446](https://github.com/pingcap/pd/pull/2446) - TiFlashレプリカが存在する場合に`presplit`機能が正しく動作しない可能性がある問題を修正しました[＃2447](https://github.com/pingcap/pd/pull/2447) - ツール diff --git a/releases/release-4.0.0-beta.1.md b/releases/release-4.0.0-beta.1.md index 256059db4232e..c91e6285817f4 100644 --- a/releases/release-4.0.0-beta.1.md +++ b/releases/release-4.0.0-beta.1.md @@ -78,7 +78,7 @@ TiDB Ansible バージョン: 4.0.0-beta.1 ## バグ修正 {#bug-fixes} - TiDB - - 64文字を超える列名で`view`作成するとエラーが報告される問題を修正しました[＃14850](https://github.com/pingcap/tidb/pull/14850) + - 64文字を超える列名で`view`を作成するとエラーが報告される問題を修正しました[＃14850](https://github.com/pingcap/tidb/pull/14850) - `create or replace view`文が正しく処理されていないため、 `information_schema.views`に重複データが存在する問題を修正[＃14832](https://github.com/pingcap/tidb/pull/14832) - `plan cache`有効になっている場合の`BatchPointGet`の誤った結果を修正[＃14855](https://github.com/pingcap/tidb/pull/14855) - タイムゾーンを変更した後にデータが間違ったパーティションテーブルに挿入される問題を修正[＃14370](https://github.com/pingcap/tidb/pull/14370) diff --git a/releases/release-4.0.0-beta.md b/releases/release-4.0.0-beta.md index df90ee9292fbf..d59f639caff48 100644 --- a/releases/release-4.0.0-beta.md +++ b/releases/release-4.0.0-beta.md @@ -51,7 +51,7 @@ TiDB Ansible バージョン: 4.0.0-beta - `LOAD DATA` で16進数と2進数の表現を区切り文字としてサポート [＃11029](https://github.com/pingcap/tidb/pull/11029) - `IndexLookupJoin` `IndexHashJoin`と`IndexMergeJoin`に分割することで、 `IndexLookupJoin`のパフォーマンスを向上させ、実行時のメモリ消費量を削減します[＃8861](https://github.com/pingcap/tidb/pull/8861) [＃12139](https://github.com/pingcap/tidb/pull/12139) [＃12349](https://github.com/pingcap/tidb/pull/12349) [＃13238](https://github.com/pingcap/tidb/pull/13238) [＃13451](https://github.com/pingcap/tidb/pull/13451) [＃13714](https://github.com/pingcap/tidb/pull/13714) - RBAC [＃13896](https://github.com/pingcap/tidb/pull/13896) [＃13820](https://github.com/pingcap/tidb/pull/13820) [＃13940](https://github.com/pingcap/tidb/pull/13940) [＃14090](https://github.com/pingcap/tidb/pull/14090) に関連するいくつかの問題を修正 [＃13014](https://github.com/pingcap/tidb/pull/13014) [＃13940](https://github.com/pingcap/tidb/pull/13940) -- `SELECT`文に`union` が含まれているため`VIEW`作成できない問題を修正しました [＃12595](https://github.com/pingcap/tidb/pull/12595) +- `SELECT`文に`union` が含まれているため`VIEW`を作成できない問題を修正しました [＃12595](https://github.com/pingcap/tidb/pull/12595) - `CAST`関数に関連するいくつかの問題を修正 - [＃12858](https://github.com/pingcap/tidb/pull/12858) [＃11968](https://github.com/pingcap/tidb/pull/11968) [＃11640](https://github.com/pingcap/tidb/pull/11640) [＃11483](https://github.com/pingcap/tidb/pull/11483) [＃11493](https://github.com/pingcap/tidb/pull/11493) - [＃11376](https://github.com/pingcap/tidb/pull/11376) [＃11355](https://github.com/pingcap/tidb/pull/11355) [＃11114](https://github.com/pingcap/tidb/pull/11114) [＃14405](https://github.com/pingcap/tidb/pull/14405) [＃14323](https://github.com/pingcap/tidb/pull/14323) diff --git a/releases/release-4.0.0-rc.1.md b/releases/release-4.0.0-rc.1.md index 40f315676641c..8537d66ed1022 100644 --- a/releases/release-4.0.0-rc.1.md +++ b/releases/release-4.0.0-rc.1.md @@ -74,7 +74,7 @@ TiDB バージョン: 4.0.0-rc.1 - Placement Driver（PD） - - `config manager`削除して、他のコンポーネントがコンポーネント構成を制御できるようにします[＃2349](https://github.com/pingcap/pd/pull/2349) + - `config manager`を削除して、他のコンポーネントがコンポーネント構成を制御できるようにします[＃2349](https://github.com/pingcap/pd/pull/2349) - TiFlash diff --git a/releases/release-4.0.0-rc.2.md b/releases/release-4.0.0-rc.2.md index 6de4cdb87369c..15b116423a537 100644 --- a/releases/release-4.0.0-rc.2.md +++ b/releases/release-4.0.0-rc.2.md @@ -118,7 +118,7 @@ TiDB バージョン: 4.0.0-rc.2 - TiFlashではサポートされているがTiKVではサポートされていないフィルタ条件が`IndexLookupJoin`演算子にプッシュダウンされたときに発生するエラーを修正しました [＃17036](https://github.com/pingcap/tidb/pull/17036) - 照合順序が有効になった後に発生する可能性のある`LIKE`の同時実行の問題を修正[＃16997](https://github.com/pingcap/tidb/pull/16997) - 照合順序が有効になった後、 `LIKE`関数が`Range`クエリインデックスを正しく構築できない問題を修正しました[＃16783](https://github.com/pingcap/tidb/pull/16783) - - `Plan Cache`文がトリガーされた後に`@@LAST_PLAN_FROM_CACHE`実行すると間違った値が返される問題を修正[＃16831](https://github.com/pingcap/tidb/pull/16831) + - `Plan Cache`文がトリガーされた後に`@@LAST_PLAN_FROM_CACHE`を実行すると間違った値が返される問題を修正[＃16831](https://github.com/pingcap/tidb/pull/16831) - `IndexMerge` の候補パスを計算するときにインデックスの`TableFilter`失われる問題を修正しました [＃16947](https://github.com/pingcap/tidb/pull/16947) - `MergeJoin`ヒントを使用し、 `TableDual`演算子が存在する場合に物理クエリプランを生成できない問題を修正しました[＃17016](https://github.com/pingcap/tidb/pull/17016) - ステートメントサマリーテーブルの`Stmt_Type`列の値の大文字と小文字の誤りを修正しました。 [＃17018](https://github.com/pingcap/tidb/pull/17018) @@ -130,7 +130,7 @@ TiDB バージョン: 4.0.0-rc.2 - `Float`値に`AND`演算子を使用したときに誤った結果が出る問題を修正しました [＃16666](https://github.com/pingcap/tidb/pull/16666) - 高価なログの`WAIT_TIME`フィールドの誤った情報を修正 [＃16907](https://github.com/pingcap/tidb/pull/16907) - 悲観的トランザクションモードで`SELECT FOR UPDATE`文がスローログに記録できない問題を修正 [＃16897](https://github.com/pingcap/tidb/pull/16897) - - `Enum`または`Set`タイプの列で`SELECT DISTINCT`実行したときに発生する誤った結果を修正[＃16892](https://github.com/pingcap/tidb/pull/16892) + - `Enum`または`Set`タイプの列で`SELECT DISTINCT`を実行したときに発生する誤った結果を修正[＃16892](https://github.com/pingcap/tidb/pull/16892) - `SHOW CREATE TABLE`文の`auto_random_base`の表示エラーを修正 [＃16864](https://github.com/pingcap/tidb/pull/16864) - `WHERE`句の`string_value`の誤った値を修正する [＃16559](https://github.com/pingcap/tidb/pull/16559) - `GROUP BY`ウィンドウ関数のエラーメッセージがMySQL と一致しない問題を修正しました [＃16165](https://github.com/pingcap/tidb/pull/16165) diff --git a/releases/release-4.0.0-rc.md b/releases/release-4.0.0-rc.md index 2c64a9466923d..612de074c812b 100644 --- a/releases/release-4.0.0-rc.md +++ b/releases/release-4.0.0-rc.md @@ -80,7 +80,7 @@ TiUPバージョン: 0.0.3 - 内部レコードのジョブクエリが正しくないため、 `PREPARE`ステートメントを使用して DDL ジョブを実行すると、上流と下流間のレプリケーションが失敗する可能性がある問題を修正しました。 [＃15435](https://github.com/pingcap/tidb/pull/15435) - 分離レベル`Read Committed` 、分離レベルでサブクエリ結果が不正確になる問題を修正 [＃15471](https://github.com/pingcap/tidb/pull/15471) - - `INSERT ... VALUES`使用して`BIT(N)`データ型指定するときに発生する可能性のある誤った動作の問題を修正しました [＃15350](https://github.com/pingcap/tidb/pull/15350) + - `INSERT ... VALUES`を使用して`BIT(N)`データ型指定するときに発生する可能性のある誤った動作の問題を修正しました [＃15350](https://github.com/pingcap/tidb/pull/15350) - `ErrorCount`の値が正しく合計されないため、DDL ジョブの内部再試行で期待どおりの結果が完全に得られない問題を修正しました[＃15373](https://github.com/pingcap/tidb/pull/15373) - TiDBがTiFlash に接続したときにガベージコレクションが異常動作する可能性がある問題を修正しました [＃15505](https://github.com/pingcap/tidb/pull/15505) - インライン投影の最適化によって誤った結果が発生する問題を修正[＃15411](https://github.com/pingcap/tidb/pull/15411) diff --git a/releases/release-4.0.11.md b/releases/release-4.0.11.md index 3084852117fd7..7f1c9f8ca7ee0 100644 --- a/releases/release-4.0.11.md +++ b/releases/release-4.0.11.md @@ -107,7 +107,7 @@ TiDB バージョン: 4.0.11 - `cast`関数の強制値が正しく設定されていない問題を修正[＃21714](https://github.com/pingcap/tidb/pull/21714) - `IF`関数使用時に予期しないpanicが発生する問題を修正 [＃21711](https://github.com/pingcap/tidb/pull/21711) - JSON検索から返される`NULL`結果がMySQL と互換性がない問題を修正しました [＃21700](https://github.com/pingcap/tidb/pull/21700) - - `ORDER BY`と`HAVING`使用して`only_full_group_by`モードをチェックするときに発生する問題を修正しました[＃21697](https://github.com/pingcap/tidb/pull/21697) + - `ORDER BY`と`HAVING`を使用して`only_full_group_by`モードをチェックするときに発生する問題を修正しました[＃21697](https://github.com/pingcap/tidb/pull/21697) - `Day`と`Time`の単位がMySQL と互換性がない問題を修正 [＃21676](https://github.com/pingcap/tidb/pull/21676) - デフォルト値`LEAD`と`LAG`フィールドタイプに適応できない問題を修正 [＃21665](https://github.com/pingcap/tidb/pull/21665) - `LOAD DATA`文がベーステーブルにのみデータをロードできることを確認するためのチェックを実行します。 [＃21638](https://github.com/pingcap/tidb/pull/21638) diff --git a/releases/release-4.0.13.md b/releases/release-4.0.13.md index b54c7dfd39b98..bbcb3ec1f3c45 100644 --- a/releases/release-4.0.13.md +++ b/releases/release-4.0.13.md @@ -59,7 +59,7 @@ TiDB バージョン: 4.0.13 - データの読み取りにマルチカラムインデックスを使用する際に重複したクエリ結果が発生する問題を修正[＃24634](https://github.com/pingcap/tidb/pull/24634) - DIV式で`BIT`型定数を除数として使用した場合に間違ったクエリ結果が発生する問題を修正しました [＃24266](https://github.com/pingcap/tidb/pull/24266) - `NO_ZERO_IN_DATE` SQLモードがDDL文で設定されたデフォルトの列値に反映されない問題を修正 [＃24185](https://github.com/pingcap/tidb/pull/24185) - - `BIT`型の列と`INTEGER`型の列の間で`UNION`使用すると間違ったクエリ結果が発生する問題を修正しました[＃24026](https://github.com/pingcap/tidb/pull/24026) + - `BIT`型の列と`INTEGER`型の列の間で`UNION`を使用すると間違ったクエリ結果が発生する問題を修正しました[＃24026](https://github.com/pingcap/tidb/pull/24026) - `BINARY`タイプと`CHAR`タイプを比較すると`TableDual`プランが誤って作成される問題を修正しました[＃23917](https://github.com/pingcap/tidb/pull/23917) - `insert ignore on duplicate`文が予期せずテーブルレコードを削除する可能性がある問題を修正しました [＃23825](https://github.com/pingcap/tidb/pull/23825) - 監査プラグインが TiDB panicを引き起こす問題を修正[＃23819](https://github.com/pingcap/tidb/pull/23819) @@ -72,7 +72,7 @@ TiDB バージョン: 4.0.13 - プレフィックス列インデックスで演算子`IndexJoin`間違った結果を返す問題を修正しました [＃23691](https://github.com/pingcap/tidb/pull/23691) - `BINARY`型列の照合順序が適切に処理されないため、間違ったクエリ結果が発生する問題を修正しました[＃23598](https://github.com/pingcap/tidb/pull/23598) - `UPDATE`番目の文に`HAVING`番目の句を含む結合クエリが含まれている場合に発生するクエリpanicの問題を修正しました[＃23575](https://github.com/pingcap/tidb/pull/23575) - - 比較式で定数`NULL`使用するとTiFlashが誤った結果を返す問題を修正しました [＃23474](https://github.com/pingcap/tidb/pull/23474) + - 比較式で定数`NULL`を使用するとTiFlashが誤った結果を返す問題を修正しました [＃23474](https://github.com/pingcap/tidb/pull/23474) - `YEAR`型の列と`STRING`定数比較したときに誤った結果が出る問題を修正しました [＃23335](https://github.com/pingcap/tidb/pull/23335) - `session.group_concat_max_len`小さすぎると`group_concat`パニックになる問題を修正[＃23257](https://github.com/pingcap/tidb/pull/23257) - `TIME`型の列に`BETWEEN`式を使用したときに間違ったクエリ結果が発生する問題を修正しました [＃23233](https://github.com/pingcap/tidb/pull/23233) @@ -82,7 +82,7 @@ TiDB バージョン: 4.0.13 - `USE_INDEX_MERGE`ヒントが効かない問題を修正[＃22924](https://github.com/pingcap/tidb/pull/22924) - `WHERE`句で`ENUM`列または`SET`列をフィルターとして使用すると、クエリが間違った結果を返すバグを修正しました[＃22814](https://github.com/pingcap/tidb/pull/22814) - クラスター化インデックスと新しい照合順序を同時に使用するとクエリが間違った結果を返すバグを修正[＃21408](https://github.com/pingcap/tidb/pull/21408) - - `enable_new_collation`有効にした状態で`ANALYZE`実行した際に発生するpanicを修正[＃21299](https://github.com/pingcap/tidb/pull/21299) + - `enable_new_collation`有効にした状態で`ANALYZE`を実行した際に発生するpanicを修正[＃21299](https://github.com/pingcap/tidb/pull/21299) - SQLビューがSQL DEFINER に関連付けられたデフォルトのロールを正しく処理しない問題を修正しました。 [＃24531](https://github.com/pingcap/tidb/pull/24531) - DDLジョブのキャンセルがスタックする問題を修正[＃24445](https://github.com/pingcap/tidb/pull/24445) - `concat`関数が照合順序誤って処理する問題を修正しました [＃24300](https://github.com/pingcap/tidb/pull/24300) diff --git a/releases/release-4.0.14.md b/releases/release-4.0.14.md index d467246005927..2124f1e3f86e3 100644 --- a/releases/release-4.0.14.md +++ b/releases/release-4.0.14.md @@ -37,7 +37,7 @@ TiDB バージョン: 4.0.14 - TiDB - - `UPDATE`読み取りで`point get`または`batch point get`使用して、インデックスキーの`LOCK`レコードを`PUT`レコードに変更します[＃26223](https://github.com/pingcap/tidb/pull/26223) + - `UPDATE`読み取りで`point get`または`batch point get`を使用して、インデックスキーの`LOCK`レコードを`PUT`レコードに変更します[＃26223](https://github.com/pingcap/tidb/pull/26223) - MySQLシステム変数`init_connect`とその関連機能サポートする [＃26031](https://github.com/pingcap/tidb/pull/26031) - クエリ結果をより安定させるために、安定した結果モードをサポートします[＃26003](https://github.com/pingcap/tidb/pull/26003) - 組み込み関数`json_unquote()`をTiKV にプッシュダウンする機能をサポート [＃25721](https://github.com/pingcap/tidb/pull/25721) @@ -110,7 +110,7 @@ TiDB バージョン: 4.0.14 - リージョンハートビートにより、TiKV が特定の状況で大規模なリージョンを分割できない問題を修正[＃10111](https://github.com/tikv/tikv/issues/10111) - TiKVとTiDB 間のCMスケッチの形式の不一致によって発生した誤った統計を修正しました [＃25638](https://github.com/pingcap/tidb/issues/25638) - `apply wait duration`メトリックの誤った統計を修正 [＃9893](https://github.com/tikv/tikv/issues/9893) - - Titan で`delete_files_in_range`使用した後に発生する「Missing Blob」エラーを修正 [＃10232](https://github.com/tikv/tikv/pull/10232) + - Titan で`delete_files_in_range`を使用した後に発生する「Missing Blob」エラーを修正 [＃10232](https://github.com/tikv/tikv/pull/10232) - PD diff --git a/releases/release-4.0.15.md b/releases/release-4.0.15.md index fa1cfafab23f0..974fc81ff372e 100644 --- a/releases/release-4.0.15.md +++ b/releases/release-4.0.15.md @@ -13,7 +13,7 @@ TiDB バージョン: 4.0.15 - TiDB - - 新規セッションで`SHOW VARIABLES`実行すると遅くなる問題を修正しました。この修正により、 で行われた変更の一部が元に戻り、互換性の問題が発生する可能性があります[＃24326](https://github.com/pingcap/tidb/issues/24326) [＃21045](https://github.com/pingcap/tidb/pull/21045) + - 新規セッションで`SHOW VARIABLES`を実行すると遅くなる問題を修正しました。この修正により、 で行われた変更の一部が元に戻り、互換性の問題が発生する可能性があります[＃24326](https://github.com/pingcap/tidb/issues/24326) [＃21045](https://github.com/pingcap/tidb/pull/21045) @@ -62,7 +62,7 @@ TiDB バージョン: 4.0.15 - Dumpling - テーブル情報を取得する前にスキップしたデータベースをフィルタリングして、 `SHOW TABLE STATUS` のフィルタリング効率を向上させます。 [＃337](https://github.com/pingcap/dumpling/pull/337) - - エクスポートするテーブルのテーブル情報を取得するには`SHOW FULL TABLES`使用します。3 `SHOW TABLE STATUS`一部のMySQLバージョンでは正常に動作しないためです。 [＃322](https://github.com/pingcap/dumpling/issues/322) + - エクスポートするテーブルのテーブル情報を取得するには`SHOW FULL TABLES`を使用します。3 `SHOW TABLE STATUS`一部のMySQLバージョンでは正常に動作しないためです。 [＃322](https://github.com/pingcap/dumpling/issues/322) - `START TRANSACTION ... WITH CONSISTENT SNAPSHOT`または`SHOW CREATE TABLE`構文をサポートしていない MySQL 互換データベースのバックアップをサポート[＃309](https://github.com/pingcap/dumpling/issues/309) - Dumpling の警告ログを改良し、ダンプが失敗したという誤解を招く情報を回避する[＃340](https://github.com/pingcap/dumpling/pull/340) diff --git a/releases/release-4.0.3.md b/releases/release-4.0.3.md index 0e8fe8402d53c..fcc9f9b1cbfd5 100644 --- a/releases/release-4.0.3.md +++ b/releases/release-4.0.3.md @@ -55,7 +55,7 @@ TiDB バージョン: 4.0.3 - `AUTO RANDOM`実験的機能から一般公開となり、リリースされました。改善点と互換性の変更点は以下の通りです。 - 設定ファイル内の`experimental.allow-auto-random`非推奨です。この項目の設定に関わらず、列の`AUTO RANDOM`機能はいつでも定義できます[＃18613](https://github.com/pingcap/tidb/pull/18613) [＃18623](https://github.com/pingcap/tidb/pull/18623) - `AUTO RANDOM`列への明示的な書き込みを制御するために、セッション変数`tidb_allow_auto_random_explicit_insert`追加します。デフォルト値は`false`です。これは、列への明示的な書き込みによって発生する予期し`AUTO_RANDOM_BASE`更新を回避するためです[＃18508](https://github.com/pingcap/tidb/pull/18508) - - `BIGINT`列と`UNSIGNED BIGINT`列にのみ`AUTO_RANDOM`定義できるようにし、シャードビットの最大数を`15`に制限することで、割り当て可能なスペースが急速に消費されるのを回避します[＃18538](https://github.com/pingcap/tidb/pull/18538) + - `BIGINT`列と`UNSIGNED BIGINT`列にのみ`AUTO_RANDOM`を定義できるようにし、シャードビットの最大数を`15`に制限することで、割り当て可能なスペースが急速に消費されるのを回避します[＃18538](https://github.com/pingcap/tidb/pull/18538) - `BIGINT`列に`AUTO_RANDOM`属性を定義し、主キーに負の値を挿入するときに`AUTO_RANDOM_BASE`更新をトリガーしないでください。 [＃17987](https://github.com/pingcap/tidb/pull/17987) - `UNSIGNED BIGINT`列に`AUTO_RANDOM`属性を定義するときに、IDの割り当てに整数の最上位ビットを使用します。これにより、割り当て可能なスペースが増えます。 [＃18404](https://github.com/pingcap/tidb/pull/18404) - `SHOW CREATE TABLE` の結果の`AUTO_RANDOM`属性の更新をサポートします [＃18316](https://github.com/pingcap/tidb/pull/18316) @@ -162,7 +162,7 @@ TiDB バージョン: 4.0.3 - Dumpling - - Dumplingが`--r`指定した場合に`NULL`値を省略する問題を修正[＃119](https://github.com/pingcap/dumpling/pull/119) + - Dumplingが`--r`を指定した場合に`NULL`値を省略する問題を修正[＃119](https://github.com/pingcap/dumpling/pull/119) - テーブルのフラッシュがテーブルをダンプに実行できない可能性があるバグを修正しました [＃117](https://github.com/pingcap/dumpling/pull/117) - TiDB Lightning diff --git a/releases/release-4.0.5.md b/releases/release-4.0.5.md index 1205ab48e16e2..87c23c3575e6c 100644 --- a/releases/release-4.0.5.md +++ b/releases/release-4.0.5.md @@ -117,7 +117,7 @@ TiDB バージョン: 4.0.5 - `STR_TO_DATE`のフォーマットトークン '%r'、 '%h' の処理が MySQL と矛盾している問題を修正しました。 [＃18727](https://github.com/pingcap/tidb/pull/18727) - `cluster_info`表の TiDB バージョン情報が PD/TiKV のバージョン情報と一致しない問題を修正しました。 [＃18413](https://github.com/pingcap/tidb/pull/18413) - 悲観的トランザクションの既存のチェックを修正[＃19004](https://github.com/pingcap/tidb/pull/19004) - - `union select for update`実行すると同時競合発生する可能性がある問題を修正 [＃19006](https://github.com/pingcap/tidb/pull/19006) + - `union select for update`を実行すると同時競合発生する可能性がある問題を修正 [＃19006](https://github.com/pingcap/tidb/pull/19006) - `apply` `PointGet`演算子の子がある場合の間違ったクエリ結果を修正しました [＃19046](https://github.com/pingcap/tidb/pull/19046) - `IndexLookUp` `Apply`演算子の内側にある場合に発生する誤った結果を修正します。 [＃19496](https://github.com/pingcap/tidb/pull/19496) - `anti-semi-join`クエリの誤った結果を修正 [＃19472](https://github.com/pingcap/tidb/pull/19472) @@ -166,7 +166,7 @@ TiDB バージョン: 4.0.5 - TiCDC - - 失敗した`changefeed`削除できない問題を修正[＃782](https://github.com/pingcap/tiflow/pull/782) + - 失敗した`changefeed`を削除できない問題を修正[＃782](https://github.com/pingcap/tiflow/pull/782) - ハンドルインデックスとして1つの一意インデックスを選択して無効なイベント`delete`修正します [＃787](https://github.com/pingcap/tiflow/pull/787) - GCセーフポイントが停止した`changefeed` のチェックポイントを超えて転送されるバグを修正 [＃797](https://github.com/pingcap/tiflow/pull/797) - ネットワークI/O待機によりタスクの終了がブロックされるバグを修正[＃825](https://github.com/pingcap/tiflow/pull/825) diff --git a/releases/release-4.0.7.md b/releases/release-4.0.7.md index 4d6f1c10612ff..a2d3f16396c67 100644 --- a/releases/release-4.0.7.md +++ b/releases/release-4.0.7.md @@ -67,7 +67,7 @@ TiDB バージョン: 4.0.7 - `slow-log`ファイルが存在しない場合に発生するクエリエラーを修正[＃20051](https://github.com/pingcap/tidb/pull/20051) - コンテキストがキャンセルされたときにリージョン要求が再試行され続ける問題を修正[＃20031](https://github.com/pingcap/tidb/pull/20031) - ストリーミングリクエストで`cluster_slow_query`のテーブルの時間型をクエリするとエラーが発生する可能性がある問題を修正しました[＃19943](https://github.com/pingcap/tidb/pull/19943) - - `case when`使用する DML ステートメントがスキーマ変更引き起こす可能性がある問題を修正しました [＃20095](https://github.com/pingcap/tidb/pull/20095) + - `case when`を使用する DML ステートメントがスキーマ変更引き起こす可能性がある問題を修正しました [＃20095](https://github.com/pingcap/tidb/pull/20095) - スローログの`prev_stmt`情報が感度低下しない問題を修正[＃20048](https://github.com/pingcap/tidb/pull/20048) - tidb-server が異常終了した際にテーブルロックを解除しない問題を修正[＃20020](https://github.com/pingcap/tidb/pull/20020) - `ENUM`と`SET`タイプのデータを挿入するときに発生する誤ったエラーメッセージを修正しました [＃19950](https://github.com/pingcap/tidb/pull/19950) diff --git a/releases/release-4.0.8.md b/releases/release-4.0.8.md index 2f6f97456c9d4..bafee16aed957 100644 --- a/releases/release-4.0.8.md +++ b/releases/release-4.0.8.md @@ -112,7 +112,7 @@ TiDB バージョン: 4.0.8 - 生成された列が不正な`NULL`値を処理できないバグを修正しました[＃20216](https://github.com/pingcap/tidb/pull/20216) - 範囲外の`YEAR`型データの不正確なエラー情報を修正 [＃20170](https://github.com/pingcap/tidb/pull/20170) - 悲観的トランザクション再試行中に発生する可能性のある予期しないエラー`invalid auto-id`を修正[＃20134](https://github.com/pingcap/tidb/pull/20134) - - `ALTER TABLE`使用して`Enum`タイプ[＃20046](https://github.com/pingcap/tidb/pull/20046) `Set`するときに制約がチェックされない問題を修正 + - `ALTER TABLE`を使用して`Enum`タイプ[＃20046](https://github.com/pingcap/tidb/pull/20046) `Set`するときに制約がチェックされない問題を修正 - 複数の演算子を並行処理に使用した場合に記録される`cop`タスクの誤った実行時間情報を修正[＃19947](https://github.com/pingcap/tidb/pull/19947) - 読み取り専用システム変数をセッション変数として明示的に選択できない問題を修正[＃19944](https://github.com/pingcap/tidb/pull/19944) - 重複した`ORDER BY`条件により、最適ではない実行プランが発生する可能性がある問題を修正しました。 [＃20333](https://github.com/pingcap/tidb/pull/20333) diff --git a/releases/release-4.0.9.md b/releases/release-4.0.9.md index 6898e2545606c..c70a7ef194e26 100644 --- a/releases/release-4.0.9.md +++ b/releases/release-4.0.9.md @@ -88,7 +88,7 @@ TiDB バージョン: 4.0.9 - Backup & Restore (BR) - - コマンドラインで曖昧な引数`--checksum false`使用しないでください。この引数はチェックサムを正しく無効化しません`--checksum=false`のみ使用できます[＃588](https://github.com/pingcap/br/pull/588) + - コマンドラインで曖昧な引数`--checksum false`を使用しないでください。この引数はチェックサムを正しく無効化しません`--checksum=false`のみ使用できます[＃588](https://github.com/pingcap/br/pull/588) - BRが誤って存在した後にPDが元の構成を回復できるように、PD構成を一時的に変更することをサポートします[＃596](https://github.com/pingcap/br/pull/596) - 復元後のテーブル分析をサポート[＃622](https://github.com/pingcap/br/pull/622) - `read index not ready`と`proposal in merging mode`エラーを再試行してください[＃626](https://github.com/pingcap/br/pull/626) diff --git a/releases/release-5.0.0-rc.md b/releases/release-5.0.0-rc.md index 8c4a7c35898ea..2154059d1eff4 100644 --- a/releases/release-5.0.0-rc.md +++ b/releases/release-5.0.0-rc.md @@ -36,7 +36,7 @@ v5.0 の主な新機能または改善点は次のとおりです。 ユーザーは、 `tidb_enable_clustered_index`変数を変更することでクラスター化インデックス機能を有効にできます。この機能を有効にすると、新規作成されたテーブルにのみ適用され、複数の列を持つ主キー、または単一の列に整数型以外の型を持つ主キーに適用されます。主キーが単一の列に整数型を持つ場合、またはテーブルに主キーがない場合、データはクラスター化インデックスの影響を受けず、以前と同じ方法で並べ替えられます。 -たとえば、テーブル（ `tbl_name` ）にクラスター化インデックスがあるかどうかを確認するには、 `select tidb_pk_type from information_schema.tables where table_name = '{tbl_name}'`実行します。 +たとえば、テーブル（ `tbl_name` ）にクラスター化インデックスがあるかどうかを確認するには、 `select tidb_pk_type from information_schema.tables where table_name = '{tbl_name}'`を実行します。 - [ユーザードキュメント](/system-variables.md#tidb_enable_clustered_index-new-in-v50) - 関連号: [＃4841](https://github.com/pingcap/tidb/issues/4841) @@ -175,7 +175,7 @@ TiDBのスケジューリングプロセスは、I/O、ネットワーク、CPU SQLパフォーマンスの問題をトラブルシューティングする際には、原因を特定するための詳細な診断情報が必要です。以前のTiDBバージョンでは、 `EXPLAIN`ステートメントで収集される情報は十分に詳細ではありませんでした。DBAはログ情報、監視情報、あるいは推測のみに基づいてトラブルシューティングを行っていましたが、これは非効率的でした。TiDB v5.0では、ユーザーがパフォーマンスの問題をより効率的にトラブルシューティングできるよう、以下の改善が行われました。 - `EXPLAIN ANALYZE`すべてのDML文の分析をサポートし、実際のパフォーマンスプランと各演算子の実行情報を表示します[＃18056](https://github.com/pingcap/tidb/issues/18056) -- ユーザーは`EXPLAIN FOR CONNECTION`使用して、実行中のSQL文のステータス情報を分析できます。この情報には、各演算子の実行時間と処理された行数が含まれます[＃18233](https://github.com/pingcap/tidb/issues/18233) +- ユーザーは`EXPLAIN FOR CONNECTION`を使用して、実行中のSQL文のステータス情報を分析できます。この情報には、各演算子の実行時間と処理された行数が含まれます[＃18233](https://github.com/pingcap/tidb/issues/18233) - `EXPLAIN ANALYZE`の出力には、オペレータによって送信された RPC 要求の数、ロック競合の解決にかかる時間、ネットワークレイテンシー、RocksDB でスキャンされた削除済みデータの量、RocksDB キャッシュのヒット率など、さらに詳しい情報が含まれています[＃18663](https://github.com/pingcap/tidb/issues/18663) - SQL文の詳細な実行情報はスローログに記録されます。これは`EXPLAIN ANALYZE`の出力情報と一致しています。この情報には、各演算子の実行時間、処理された行数、送信されたRPC要求の数などが含まれます[＃15009](https://github.com/pingcap/tidb/issues/15009) @@ -183,7 +183,7 @@ SQLパフォーマンスの問題をトラブルシューティングする際 ## 展開と保守 {#deployment-and-maintenance} -- 以前は、TiDB Ansibleの設定情報がTiUPにインポートされると、 TiUPはユーザー設定を`ansible-imported-configs`ディレクトリに保存していました。その後、ユーザーが`tiup cluster edit-config`使用して設定を編集する必要がある場合、インポートされた設定はエディターインターフェースに表示されず、ユーザーの混乱を招く可能性がありました。TiDB v5.0では、TiDB Ansibleの設定がインポートされると、 TiUPは設定情報を`ansible-imported-configs`とエディターインターフェースの両方に保存します。この改善により、ユーザーはクラスター設定を編集する際に、インポートされた設定を確認できます。 +- 以前は、TiDB Ansibleの設定情報がTiUPにインポートされると、 TiUPはユーザー設定を`ansible-imported-configs`ディレクトリに保存していました。その後、ユーザーが`tiup cluster edit-config`を使用して設定を編集する必要がある場合、インポートされた設定はエディターインターフェースに表示されず、ユーザーの混乱を招く可能性がありました。TiDB v5.0では、TiDB Ansibleの設定がインポートされると、 TiUPは設定情報を`ansible-imported-configs`とエディターインターフェースの両方に保存します。この改善により、ユーザーはクラスター設定を編集する際に、インポートされた設定を確認できます。 - 複数のミラーを 1 つにマージし、ローカル ミラーにコンポーネントを公開し、ローカル ミラーにコンポーネント所有者を追加する機能をサポートする拡張`mirror`コマンド[＃814](https://github.com/pingcap/tiup/issues/814) - 大規模企業、特に金融業界では、本番環境の変更は慎重に検討されます。バージョンごとにCDを使用してインストールする必要があると、面倒な作業になる可能性があります。TiDB v5.0では、 TiUPの`merge`コマンドで複数のインストールパッケージを1つにマージできるため、インストール作業が簡素化されます。 - - v4.0では、自分で構築したミラーを公開するにはtiup-serverを起動する必要があり、使い勝手が悪かったです。v5.0では、 `tiup mirror set`使用して現在のミラーをローカルミラーに設定するだけで、自分で構築したミラーを公開できます。 + - v4.0では、自分で構築したミラーを公開するにはtiup-serverを起動する必要があり、使い勝手が悪かったです。v5.0では、 `tiup mirror set`を使用して現在のミラーをローカルミラーに設定するだけで、自分で構築したミラーを公開できます。 diff --git a/releases/release-5.0.0.md b/releases/release-5.0.0.md index d958d71dea1a2..7ac5047ca4049 100644 --- a/releases/release-5.0.0.md +++ b/releases/release-5.0.0.md @@ -224,7 +224,7 @@ CREATE TABLE `t` (`a` VARCHAR(255) PRIMARY KEY CLUSTERED, `b` INT); `CREATE TABLE`ステートメントにキーワード`CLUSTERED | NONCLUSTERED`が含まれている場合、そのステートメントはシステム変数と構成項目の設定を上書きします。 -ステートメントでキーワード`CLUSTERED | NONCLUSTERED`指定して、クラスター化インデックス機能を使用することをお勧めします。この方法により、TiDB は必要に応じてシステム内のクラスター化インデックスと非クラスター化インデックスのすべてのデータ型を同時に使用できるようになり、より柔軟に対応できます。 +ステートメントでキーワード`CLUSTERED | NONCLUSTERED`を指定して、クラスター化インデックス機能を使用することをお勧めします。この方法により、TiDB は必要に応じてシステム内のクラスター化インデックスと非クラスター化インデックスのすべてのデータ型を同時に使用できるようになり、より柔軟に対応できます。 `tidb_enable_clustered_index = INT_ONLY`の使用は推奨されません。 `INT_ONLY`は、この機能の互換性を確保するために一時的に使用されており、将来的に廃止される予定です。 diff --git a/releases/release-5.0.1.md b/releases/release-5.0.1.md index 568193d7c920d..1e5eac631c609 100644 --- a/releases/release-5.0.1.md +++ b/releases/release-5.0.1.md @@ -21,7 +21,7 @@ TiDB バージョン: 5.0.1 - TiKV - - `zstd`使用してリージョンスナップショットを圧縮します [＃10005](https://github.com/tikv/tikv/pull/10005) + - `zstd`を使用してリージョンスナップショットを圧縮します [＃10005](https://github.com/tikv/tikv/pull/10005) - PD @@ -67,7 +67,7 @@ TiDB バージョン: 5.0.1 - `receiver`秒以内に対応するタスクが見つからないバグを修正 - `cancelMPPQuery`に無効なイテレータが存在する可能性がある問題を修正 - `bitwise`演算子の動作がTiDBと異なるバグを修正 - - `prefix key`使用する際に範囲が重複することで発生するアラートの問題を修正 + - `prefix key`を使用する際に範囲が重複することで発生するアラートの問題を修正 - 文字列型を整数型にキャストするときに誤った結果が返される問題を修正しました - 連続した高速書き込みによりTiFlashのメモリが不足する可能性がある問題を修正しました - 重複した列名によりTiFlashでエラーが発生する問題を修正しました diff --git a/releases/release-5.0.3.md b/releases/release-5.0.3.md index f9d7eaebe92fc..4aa015f301dbc 100644 --- a/releases/release-5.0.3.md +++ b/releases/release-5.0.3.md @@ -79,7 +79,7 @@ TiDB バージョン: 5.0.3 - `SET`型列でマージ結合を使用すると誤った結果が返される問題を修正しました [＃25669](https://github.com/pingcap/tidb/issues/25669) - `IN`式の引数におけるデータ破損の問題を修正 [＃25591](https://github.com/pingcap/tidb/issues/25591) - GCのセッションがグローバル変数の影響を受けないようにする[＃24976](https://github.com/pingcap/tidb/issues/24976) - - ウィンドウ関数クエリで`limit`使用するときに発生するpanic問題を修正 [＃25344](https://github.com/pingcap/tidb/issues/25344) + - ウィンドウ関数クエリで`limit`を使用するときに発生するpanic問題を修正 [＃25344](https://github.com/pingcap/tidb/issues/25344) - `Limit` を使用してパーティションテーブルをクエリしたときに返される誤った値を修正しました [＃24636](https://github.com/pingcap/tidb/issues/24636) - `IFNULL` `ENUM`または`SET`タイプの列に正しく反映されない問題を修正 [＃24944](https://github.com/pingcap/tidb/issues/24944) - 結合サブクエリの`count` `first_row` に変更することで発生する誤った結果を修正しました [＃24865](https://github.com/pingcap/tidb/issues/24865) diff --git a/releases/release-5.0.4.md b/releases/release-5.0.4.md index 96c318f7328ae..7fe361e8a1375 100644 --- a/releases/release-5.0.4.md +++ b/releases/release-5.0.4.md @@ -13,7 +13,7 @@ TiDB バージョン: 5.0.4 - TiDB - - 新規セッションで`SHOW VARIABLES`実行すると遅くなる問題を修正しました。この修正により、 で行われた変更の一部が元に戻り、互換性の問題が発生する可能性があります[＃24326](https://github.com/pingcap/tidb/issues/24326) [＃19341](https://github.com/pingcap/tidb/pull/19341) + - 新規セッションで`SHOW VARIABLES`を実行すると遅くなる問題を修正しました。この修正により、 で行われた変更の一部が元に戻り、互換性の問題が発生する可能性があります[＃24326](https://github.com/pingcap/tidb/issues/24326) [＃19341](https://github.com/pingcap/tidb/pull/19341) - `tidb_stmt_summary_max_stmt_count`変数のデフォルト値を`200`から`3000`に変更します[＃25873](https://github.com/pingcap/tidb/pull/25873) @@ -148,7 +148,7 @@ TiDB バージョン: 5.0.4 - PD - PDがダウンしたピアを時間内に修復しない問題を修正[＃4077](https://github.com/tikv/pd/issues/4077) - - `replication.max-replicas`更新した後、デフォルトの配置ルールのレプリカ数が一定のままになる問題を修正[＃3886](https://github.com/tikv/pd/issues/3886) + - `replication.max-replicas`を更新した後、デフォルトの配置ルールのレプリカ数が一定のままになる問題を修正[＃3886](https://github.com/tikv/pd/issues/3886) - TiKV をスケールアウトするときに PD がpanic可能性があるバグを修正しました [＃3868](https://github.com/tikv/pd/issues/3868) - 複数のスケジューラが同時に実行されているときに発生するスケジュール競合の問題を修正[＃3807](https://github.com/tikv/pd/issues/3807) - スケジューラが削除された後でも再び表示されることがある問題を修正[＃2572](https://github.com/tikv/pd/issues/2572) @@ -158,7 +158,7 @@ TiDB バージョン: 5.0.4 - テーブルスキャンタスクの実行時に発生する可能性のあるpanic問題を修正しました - MPPタスク実行時に発生する可能性のあるメモリリークの問題を修正 - TiFlashがDAQリクエストを処理する際に`duplicated region`エラーを発生させるバグを修正しました - - 集計関数`COUNT`または`COUNT DISTINCT`実行するときに予期しない結果が発生する問題を修正しました + - 集計関数`COUNT`または`COUNT DISTINCT`を実行するときに予期しない結果が発生する問題を修正しました - MPPタスク実行時に発生する可能性のあるpanic問題を修正 - 複数のディスクに展開されたときにTiFlash がデータを復元できない潜在的なバグを修正しました - 解体時に発生する可能性のあるpanic問題を修正`SharedQueryBlockInputStream` diff --git a/releases/release-5.1.1.md b/releases/release-5.1.1.md index c5dee168c68b7..4db6ddc24bd0e 100644 --- a/releases/release-5.1.1.md +++ b/releases/release-5.1.1.md @@ -43,7 +43,7 @@ TiDB バージョン: 5.1.1 - クエリ結果をより安定させるために、安定した結果モードをサポートします[＃25995](https://github.com/pingcap/tidb/pull/25995) - 組み込み関数`json_unquote()`をTiKV にプッシュダウンする機能をサポート [＃26265](https://github.com/pingcap/tidb/pull/26265) - MPPクエリの再試行をサポート[＃26480](https://github.com/pingcap/tidb/pull/26480) - - `UPDATE`読み取りで`point get`または`batch point get`使用して、インデックスキーの`LOCK`レコードを`PUT`レコードに変更します[＃26225](https://github.com/pingcap/tidb/pull/26225) + - `UPDATE`読み取りで`point get`または`batch point get`を使用して、インデックスキーの`LOCK`レコードを`PUT`レコードに変更します[＃26225](https://github.com/pingcap/tidb/pull/26225) - 古いクエリからのビューの作成を禁止する[＃26200](https://github.com/pingcap/tidb/pull/26200) - MPPモードで`COUNT(DISTINCT)`集約機能を徹底的にプッシュダウンする [＃26194](https://github.com/pingcap/tidb/pull/26194) - MPPクエリを起動する前にTiFlashの可用性を確認してください [＃26192](https://github.com/pingcap/tidb/pull/26192) @@ -56,7 +56,7 @@ TiDB バージョン: 5.1.1 - 未確定エラーの可能性を減らすために、事前書き込みリクエストを可能な限りべき等にしてください[＃10586](https://github.com/tikv/tikv/pull/10586) - 多数の期限切れコマンドを処理する際のスタックオーバーフローのリスクを防ぐ[＃10502](https://github.com/tikv/tikv/pull/10502) - - `max_ts` を更新するためにステイル読み取り要求の`start_ts`使用しないことで、コミット要求の再試行を過度に回避します。 [＃10451](https://github.com/tikv/tikv/pull/10451) + - `max_ts` を更新するためにステイル読み取り要求の`start_ts`を使用しないことで、コミット要求の再試行を過度に回避します。 [＃10451](https://github.com/tikv/tikv/pull/10451) - 読み取り準備と書き込み準備は別々に処理して読み取りレイテンシーを削減する[＃10592](https://github.com/tikv/tikv/pull/10592) - I/Oレート制限が有効になっている場合のデータインポート速度への影響を軽減します[＃10390](https://github.com/tikv/tikv/pull/10390) - Raft gRPC接続間の負荷分散を改善する[＃10495](https://github.com/tikv/tikv/pull/10495) @@ -128,7 +128,7 @@ TiDB バージョン: 5.1.1 - 読み取り負荷が大きい場合に発生するpanic問題を修正しました - `DateFormat`関数の実行時に発生する可能性のあるpanic問題を修正 - MPPタスク実行時に発生する可能性のあるメモリリークの問題を修正 - - 集計関数`COUNT`または`COUNT DISTINCT`実行するときに予期しない結果が発生する問題を修正しました + - 集計関数`COUNT`または`COUNT DISTINCT`を実行するときに予期しない結果が発生する問題を修正しました - 複数のディスクに展開されたときにTiFlash がデータを復元できない潜在的なバグを修正しました - TiDB DashboardがTiFlashのディスク情報を正しく表示できない問題を修正 - 解体時に発生する可能性のあるpanic問題を修正`SharedQueryBlockInputStream` diff --git a/releases/release-5.1.2.md b/releases/release-5.1.2.md index 7e3bf30f2ca4c..f21e584bdfc86 100644 --- a/releases/release-5.1.2.md +++ b/releases/release-5.1.2.md @@ -110,7 +110,7 @@ TiDB バージョン: 5.1.2 - PD - PDがダウンしたピアを時間内に修復しない問題を修正[＃4077](https://github.com/tikv/pd/issues/4077) - - `replication.max-replicas`更新した後、デフォルトの配置ルールのレプリカ数が一定のままになる問題を修正[＃3886](https://github.com/tikv/pd/issues/3886) + - `replication.max-replicas`を更新した後、デフォルトの配置ルールのレプリカ数が一定のままになる問題を修正[＃3886](https://github.com/tikv/pd/issues/3886) - TiKV をスケールアウトするときに PD がpanic可能性があるバグを修正しました [＃3868](https://github.com/tikv/pd/issues/3868) - クラスターにエビクトリーダースケジューラがある場合にホットリージョンスケジューラが動作しないバグを修正しました [＃3697](https://github.com/tikv/pd/issues/3697) diff --git a/releases/release-5.1.4.md b/releases/release-5.1.4.md index f7b92fee271bf..4837e5337b18e 100644 --- a/releases/release-5.1.4.md +++ b/releases/release-5.1.4.md @@ -65,7 +65,7 @@ TiDB バージョン: 5.1.4 - システム変数`tidb_analyze_version` `2` に設定されている場合に発生するメモリリークのバグを修正しました [＃32499](https://github.com/pingcap/tidb/issues/32499) - `MaxDays`と`MaxBackups`設定がスローログに反映されない問題を修正 [＃25716](https://github.com/pingcap/tidb/issues/25716) - `INSERT ... SELECT ... ON DUPLICATE KEY UPDATE`文を実行するとpanicが発生する問題を修正しました [＃28078](https://github.com/pingcap/tidb/issues/28078) - - `ENUM`種類の列に対して`JOIN`実行するときに発生する可能性のある誤った結果を修正 [＃27831](https://github.com/pingcap/tidb/issues/27831) + - `ENUM`種類の列に対して`JOIN`を実行するときに発生する可能性のある誤った結果を修正 [＃27831](https://github.com/pingcap/tidb/issues/27831) - INDEX HASH JOINが`send on closed channel`エラーを返す問題を修正しました[＃31129](https://github.com/pingcap/tidb/issues/31129) - [`BatchCommands`](/tidb-configuration-file.md#max-batch-size) APIを使用すると、まれにTiKVへのTiDBリクエストの送信がブロックされる可能性がある問題を修正しました[＃32500](https://github.com/pingcap/tidb/issues/32500) - 楽観的トランザクションモードで潜在的なデータインデックスの不整合が発生する問題を修正 [＃30410](https://github.com/pingcap/tidb/issues/30410) @@ -84,7 +84,7 @@ TiDB バージョン: 5.1.4 - TiKV - - GCワーカーがビジー状態のときにTiKVがデータ範囲を削除できない（ `unsafe_destroy_range`実行できない）というバグを修正[＃11903](https://github.com/tikv/tikv/issues/11903) + - GCワーカーがビジー状態のときにTiKVがデータ範囲を削除できない（ `unsafe_destroy_range`を実行できない）というバグを修正[＃11903](https://github.com/tikv/tikv/issues/11903) - ピアを破棄するとレイテンシーが大きくなる可能性がある問題を修正[＃10210](https://github.com/tikv/tikv/issues/10210) - 領域が空の場合に関数`any_value`が誤った結果を返すバグを修正しました[＃11735](https://github.com/tikv/tikv/issues/11735) - 初期化されていないレプリカを削除すると古いレプリカが再作成される可能性がある問題を修正[＃10533](https://github.com/tikv/tikv/issues/10533) diff --git a/releases/release-5.2.2.md b/releases/release-5.2.2.md index 85fb3ff1dd2b8..8de8c8802de2e 100644 --- a/releases/release-5.2.2.md +++ b/releases/release-5.2.2.md @@ -60,7 +60,7 @@ TiDB バージョン: 5.2.2 - `%s value is out of range in '%s'`エラーメッセージに`DECIMAL overflow`が欠落している問題を修正 [＃27964](https://github.com/pingcap/tidb/issues/27964) - MPPノードの可用性検出が一部のコーナーケースで機能しないバグを修正[＃3118](https://github.com/pingcap/tics/issues/3118) - `MPP task ID` を割り当てる際の`DATA RACE`問題を修正 [＃27952](https://github.com/pingcap/tidb/issues/27952) - - 空の`dual table`削除した後の MPP クエリの`INDEX OUT OF RANGE`エラーを修正します[＃28250](https://github.com/pingcap/tidb/issues/28250) + - 空の`dual table`を削除した後の MPP クエリの`INDEX OUT OF RANGE`エラーを修正します[＃28250](https://github.com/pingcap/tidb/issues/28250) - MPPクエリの誤検知エラーログ`invalid cop task execution summaries length`の問題を修正 [＃1791](https://github.com/pingcap/tics/issues/1791) - MPPクエリのエラーログ`cannot found column in Schema column`の問題を修正 [＃28149](https://github.com/pingcap/tidb/pull/28149) - TiFlashがシャットダウンするときに TiDB がpanic可能性がある問題を修正[＃28096](https://github.com/pingcap/tidb/issues/28096) diff --git a/releases/release-5.3.0.md b/releases/release-5.3.0.md index bc6b3427f5440..2f18b3ab3090b 100644 --- a/releases/release-5.3.0.md +++ b/releases/release-5.3.0.md @@ -71,7 +71,7 @@ v5.3 の主な新機能または改善点は次のとおりです。 - v5.3.0より前のリリースでは、システム変数が無効な値に設定された場合、TiDBはエラーを報告します。v5.3.0以降のリリースでは、システム変数が無効な値に設定された場合、TiDBは「|警告 | 1292 | 切り捨てられた不正なxxx: 'xx'」などの警告とともに成功を返します。 -- `SHOW CREATE VIEW`実行するために`SHOW VIEW`権限が必要ない問題を修正しました。これで、 `SHOW CREATE VIEW`文を実行するには`SHOW VIEW`権限が必要になります。 +- `SHOW CREATE VIEW`を実行するために`SHOW VIEW`権限が必要ない問題を修正しました。これで、 `SHOW CREATE VIEW`文を実行するには`SHOW VIEW`権限が必要になります。 - システム変数`sql_auto_is_null`が noop関数に追加されます。 `tidb_enable_noop_functions = 0/OFF`の場合、この変数値を変更するとエラーが発生します。 @@ -277,7 +277,7 @@ TiCDC v5.3.0以降、TiDBクラスター間の循環レプリケーション機 - ディスクスペース保護を強化してストレージの安定性を向上 - ディスク書き込みエラーが発生した場合にTiKVがpanicに陥る可能性がある問題を解決するため、TiKVは2段階のしきい値防御メカニズムを導入し、過剰なトラフィックによるディスク残容量の枯渇を防ぎます。さらに、このメカニズムは、しきい値に達した際に領域を回収する機能も提供します。残容量しきい値に達すると、一部の書き込み操作が失敗し、TiKVはディスクフルエラーとディスクフルノードのリストを返します。この場合、領域を回復してサービスを復旧するには、 `Drop/Truncate Table`実行するか、ノードをスケールアウトします。 + ディスク書き込みエラーが発生した場合にTiKVがpanicに陥る可能性がある問題を解決するため、TiKVは2段階のしきい値防御メカニズムを導入し、過剰なトラフィックによるディスク残容量の枯渇を防ぎます。さらに、このメカニズムは、しきい値に達した際に領域を回収する機能も提供します。残容量しきい値に達すると、一部の書き込み操作が失敗し、TiKVはディスクフルエラーとディスクフルノードのリストを返します。この場合、領域を回復してサービスを復旧するには、 `Drop/Truncate Table`を実行するか、ノードをスケールアウトします。 - L0フロー制御のアルゴリズムを簡素化する [＃10879](https://github.com/tikv/tikv/issues/10879) diff --git a/releases/release-5.3.1.md b/releases/release-5.3.1.md index e6a0a1e98c703..ec3171493baa7 100644 --- a/releases/release-5.3.1.md +++ b/releases/release-5.3.1.md @@ -74,7 +74,7 @@ TiDB バージョン: 5.3.1 - フロー制御が有効で、 `level0_slowdown_trigger`明示的に設定されている場合に QPS が低下する問題を修正しました[＃11424](https://github.com/tikv/tikv/issues/11424) - cgroup コントローラがマウントされていない場合に発生するpanic問題を修正[＃11569](https://github.com/tikv/tikv/issues/11569) - TiKVの動作が停止した後にResolved TSのレイテンシーが増加する問題を修正[＃11351](https://github.com/tikv/tikv/issues/11351) - - GCワーカーがビジー状態のときにTiKVがデータ範囲を削除できない（ `unsafe_destroy_range`実行できない）というバグを修正[＃11903](https://github.com/tikv/tikv/issues/11903) + - GCワーカーがビジー状態のときにTiKVがデータ範囲を削除できない（ `unsafe_destroy_range`を実行できない）というバグを修正[＃11903](https://github.com/tikv/tikv/issues/11903) - ピアを破棄するとレイテンシーが大きくなる可能性がある問題を修正[＃10210](https://github.com/tikv/tikv/issues/10210) - リージョンが空の場合に関数`any_value`が誤った結果を返すバグを修正しました[＃11735](https://github.com/tikv/tikv/issues/11735) - 初期化されていないレプリカを削除すると古いレプリカが再作成される可能性がある問題を修正[＃10533](https://github.com/tikv/tikv/issues/10533) diff --git a/releases/release-5.4.0.md b/releases/release-5.4.0.md index 2633d7407ba9b..c1b01878337be 100644 --- a/releases/release-5.4.0.md +++ b/releases/release-5.4.0.md @@ -394,7 +394,7 @@ TiDB バージョン: 5.4.0 - Backup & Restore (BR) - リストア操作完了後にリージョン分布が不均一になる可能性がある問題を修正 [#30425](https://github.com/pingcap/tidb/issues/30425) - - `'/'`バックアップストレージとして使用している場合、エンドポイントで`minio`指定できない問題を修正しました [#30104](https://github.com/pingcap/tidb/issues/30104) + - `'/'`バックアップストレージとして使用している場合、エンドポイントで`minio`を指定できない問題を修正しました [#30104](https://github.com/pingcap/tidb/issues/30104) - システムテーブルの同時バックアップによってテーブル名の更新が失敗し、システムテーブルを復元できない問題を修正しました [#29710](https://github.com/pingcap/tidb/issues/29710) - TiCDC diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md index 6be04e891e954..ea3d7163c415f 100644 --- a/releases/release-6.1.0.md +++ b/releases/release-6.1.0.md @@ -329,8 +329,8 @@ TiDB バージョン: 6.1.0 - `UnionScanRead` オペレータのパフォーマンスを向上させる [#32433](https://github.com/pingcap/tidb/issues/32433) - `EXPLAIN`の出力におけるタスクタイプの表示を改善（MPPタスクタイプを追加） [＃33332](https://github.com/pingcap/tidb/issues/33332) - - 列のデフォルト値として`rand()`使用することをサポートします [＃10377](https://github.com/pingcap/tidb/issues/10377) - - 列のデフォルト値として`uuid()`使用することをサポートします [＃33870](https://github.com/pingcap/tidb/issues/33870) + - 列のデフォルト値として`rand()`を使用することをサポートします [＃10377](https://github.com/pingcap/tidb/issues/10377) + - 列のデフォルト値として`uuid()`を使用することをサポートします [＃33870](https://github.com/pingcap/tidb/issues/33870) - Support modifying the character set of columns from `latin1` to `utf8`/`utf8mb4` [＃34008](https://github.com/pingcap/tidb/issues/34008) - TiKV diff --git a/releases/release-6.1.6.md b/releases/release-6.1.6.md index 1b91b76df9114..13269eec4485a 100644 --- a/releases/release-6.1.6.md +++ b/releases/release-6.1.6.md @@ -53,8 +53,8 @@ TiDB バージョン: 6.1.6 - プランキャッシュがシャッフル演算子をキャッシュし、誤った結果を返す可能性がある問題を修正[＃38335](https://github.com/pingcap/tidb/issues/38335) @ [qw4990](https://github.com/qw4990) @ [fzzf678](https://github.com/fzzf678) - インデックスマージを使用して`SET`型の列を含むテーブルを読み取ると、誤った結果[＃41293](https://github.com/pingcap/tidb/issues/41293) @ [time-and-fate](https://github.com/time-and-fate)が発生する可能性がある問題を修正しました - プリペアドプランキャッシュが有効な場合にフルインデックススキャンでエラーが発生する可能性がある問題を修正[＃42150](https://github.com/pingcap/tidb/issues/42150) @ [fzzf678](https://github.com/fzzf678) - - DDL文の実行中に`PointGet`使用してテーブルを読み込むSQL文がpanic[＃41622](https://github.com/pingcap/tidb/issues/41622) @ [tiancaiamao](https://github.com/tiancaiamao)をスローする可能性がある問題を修正しました - - トランザクション内で`PointUpdate`実行した後、TiDB が`SELECT`文[＃28011](https://github.com/pingcap/tidb/issues/28011) @ [zyguan](https://github.com/zyguan)に対して誤った結果を返す問題を修正しました。 + - DDL文の実行中に`PointGet`を使用してテーブルを読み込むSQL文がpanic[＃41622](https://github.com/pingcap/tidb/issues/41622) @ [tiancaiamao](https://github.com/tiancaiamao)をスローする可能性がある問題を修正しました + - トランザクション内で`PointUpdate`を実行した後、TiDB が`SELECT`文[＃28011](https://github.com/pingcap/tidb/issues/28011) @ [zyguan](https://github.com/zyguan)に対して誤った結果を返す問題を修正しました。 - メモリリークとパフォーマンスの低下を防ぐため、期限切れのリージョンキャッシュを定期的にクリアします[＃40461](https://github.com/pingcap/tidb/issues/40461) @ [sticnarf](https://github.com/sticnarf) @ [zyguan](https://github.com/zyguan) - Fix the issue that `INSERT IGNORE` and `REPLACE` statements do not lock keys that do not modify values [＃42121](https://github.com/pingcap/tidb/issues/42121) @ [zyguan](https://github.com/zyguan) @@ -84,7 +84,7 @@ TiDB バージョン: 6.1.6 - データレプリケーション中の`UPDATE`と`INSERT`ステートメントの順序が乱れると、 `Duplicate entry`エラー[＃8597](https://github.com/pingcap/tiflow/issues/8597) @ [sdojjy](https://github.com/sdojjy)が発生する可能性がある問題を修正しました。 - PDとTiCDC [＃8562](https://github.com/pingcap/tiflow/issues/8562) @ [overvenus](https://github.com/overvenus)間のネットワーク分離によって発生するTiCDCサービスの異常終了問題を修正 - - TiDB または MySQL シンクにデータを複製するときに、主キー[＃8420](https://github.com/pingcap/tiflow/issues/8420) @ [zhaoxinyu](https://github.com/zhaoxinyu)のない非 NULL ユニーク インデックスを持つ列に`CHARACTER SET`指定した場合に発生するデータの不整合を修正しました。 + - TiDB または MySQL シンクにデータを複製するときに、主キー[＃8420](https://github.com/pingcap/tiflow/issues/8420) @ [zhaoxinyu](https://github.com/zhaoxinyu)のない非 NULL ユニーク インデックスを持つ列に`CHARACTER SET`を指定した場合に発生するデータの不整合を修正しました。 - `db sorter`のメモリ使用量が`cgroup memory limit` [＃8588](https://github.com/pingcap/tiflow/issues/8588) @ [amyangfei](https://github.com/amyangfei)で制御されない問題を修正 - 無効な入力[＃7903](https://github.com/pingcap/tiflow/issues/7903)に対する`cdc cli`のエラーメッセージを[チャールズ・チュン96](https://github.com/CharlesCheung96)で最適化します - S3storage障害[＃8089](https://github.com/pingcap/tiflow/issues/8089) @ [CharlesCheung96](https://github.com/CharlesCheung96)に対して、REDO ログが許容できる期間が不十分である問題を修正しました diff --git a/releases/release-6.1.7.md b/releases/release-6.1.7.md index 4a5bedc6afb98..7a290cff012a1 100644 --- a/releases/release-6.1.7.md +++ b/releases/release-6.1.7.md @@ -52,10 +52,10 @@ TiDB バージョン: 6.1.7 - テーブル名の変更中に TiCDC が行の変更の一部を失う可能性がある問題を修正[＃43338](https://github.com/pingcap/tidb/issues/43338) @ [tangenta](https://github.com/tangenta) - パーティション化されたテーブルにおける配置ルールの動作の問題を修正し、削除されたパーティションにおける配置ルールが正しく設定され、再利用されるようになりました[＃44116](https://github.com/pingcap/tidb/issues/44116) @ [lcwangchao](https://github.com/lcwangchao) - `tidb_scatter_region`有効にすると、パーティションが切り捨てられた後にリージョンが自動的に分割されない問題を修正しました[＃43174](https://github.com/pingcap/tidb/issues/43174) [＃43028](https://github.com/pingcap/tidb/issues/43028) - - 多数のパーティションとTiFlashレプリカを持つパーティション テーブルに対して`TRUNCATE TABLE`実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。 [＃42940](https://github.com/pingcap/tidb/issues/42940) @ [mjonss](https://github.com/mjonss) + - 多数のパーティションとTiFlashレプリカを持つパーティション テーブルに対して`TRUNCATE TABLE`を実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。 [＃42940](https://github.com/pingcap/tidb/issues/42940) @ [mjonss](https://github.com/mjonss) - ウィンドウ関数をTiFlash にプッシュダウンする際の実行プランが正しくない問題を修正しました [＃43922](https://github.com/pingcap/tidb/issues/43922) @ [gengliqi](https://github.com/gengliqi) - 非相関サブクエリを含むステートメントで共通テーブル式 (CTE) を使用すると誤った結果が返される可能性がある問題を修正しました [＃44051](https://github.com/pingcap/tidb/issues/44051) @ [winoros](https://github.com/winoros) - - カーソルフェッチで`memTracker`使用するとメモリリークが発生する問題を修正[＃44254](https://github.com/pingcap/tidb/issues/44254) @ [YangKeao](https://github.com/YangKeao) + - カーソルフェッチで`memTracker`を使用するとメモリリークが発生する問題を修正[＃44254](https://github.com/pingcap/tidb/issues/44254) @ [YangKeao](https://github.com/YangKeao) - `INFORMATION_SCHEMA.DDL_JOBS`テーブルの`QUERY`列のデータ長が列定義を超える可能性がある問題を修正しました [＃42440](https://github.com/pingcap/tidb/issues/42440) @ [tiancaiamao](https://github.com/tiancaiamao) - `min, max`クエリ結果が正しくない問題を修正[＃43805](https://github.com/pingcap/tidb/issues/43805) @ [wshwsh12](https://github.com/wshwsh12) - TiDBがテーブルを分析するときに構文エラーを報告する問題を修正しました [＃43392](https://github.com/pingcap/tidb/issues/43392) @ [guo-shaoge](https://github.com/guo-shaoge) diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index 94f83a2fde705..a902c33829dfe 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -88,7 +88,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では SQL文の場合、実行中の様々な要因により、オプティマイザが以前の最適な実行プランではなく新しい実行プランを選択することがあり、SQLパフォーマンスに影響が出ることがあります。この場合、最適な実行プランがまだクリアされていない場合、SQL実行履歴に残ります。 - TiDB v6.5.0では、 [`CREATE [GLOBAL | SESSION] BINDING`](/sql-statements/sql-statement-create-binding.md)ステートメントのバインディングオブジェクトを拡張することで、履歴実行プランのバインディングをサポートします。SQLステートメントの実行プランが変更された場合、元の実行プランがSQL実行履歴メモリテーブル（例えば`statements_summary`に残っている限り、 `CREATE [GLOBAL | SESSION] BINDING`ステートメントで`plan_digest`指定することで元の実行プランをバインドし、SQLパフォーマンスを迅速に回復できます。この機能により、実行プラン変更の問題への対応プロセスが簡素化され、メンテナンス効率が向上します。 + TiDB v6.5.0では、 [`CREATE [GLOBAL | SESSION] BINDING`](/sql-statements/sql-statement-create-binding.md)ステートメントのバインディングオブジェクトを拡張することで、履歴実行プランのバインディングをサポートします。SQLステートメントの実行プランが変更された場合、元の実行プランがSQL実行履歴メモリテーブル（例えば`statements_summary`に残っている限り、 `CREATE [GLOBAL | SESSION] BINDING`ステートメントで`plan_digest`を指定することで元の実行プランをバインドし、SQLパフォーマンスを迅速に回復できます。この機能により、実行プラン変更の問題への対応プロセスが簡素化され、メンテナンス効率が向上します。 詳細については[ドキュメント](/sql-plan-management.md#create-a-binding-according-to-a-historical-execution-plan)参照してください。 @@ -211,7 +211,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - JSON形式での実行プランの出力をサポート[＃39261](https://github.com/pingcap/tidb/issues/39261) @ [fzzf678](https://github.com/fzzf678) - TiDB v6.5.0では、実行プランの出力形式が拡張されました。3 `EXPLAIN`に`FORMAT = "tidb_json"`指定することで、SQL実行プランをJSON形式で出力できます。この機能により、SQLデバッグツールや診断ツールは実行プランをより便利かつ正確に読み取ることができるため、SQL診断やチューニングの利便性が向上します。 + TiDB v6.5.0では、実行プランの出力形式が拡張されました。3 `EXPLAIN`に`FORMAT = "tidb_json"`を指定することで、SQL実行プランをJSON形式で出力できます。この機能により、SQLデバッグツールや診断ツールは実行プランをより便利かつ正確に読み取ることができるため、SQL診断やチューニングの利便性が向上します。 詳細については[ドキュメント](/sql-statements/sql-statement-explain.md)参照してください。 @@ -441,7 +441,7 @@ v6.5.0 以降では、v4.0.7 で導入された`AMEND TRANSACTION`メカニズ - 一部のケースで発生するチャンク再利用機能のメモリチャンクの誤用問題を修正[＃38917](https://github.com/pingcap/tidb/issues/38917) @ [keeplearning20221](https://github.com/keeplearning20221) - `tidb_constraint_check_in_place_pessimistic`の内部セッションがグローバル設定の影響を受ける可能性がある問題を修正しました [＃38766](https://github.com/pingcap/tidb/issues/38766) @ [ekexium](https://github.com/ekexium) - `AUTO_INCREMENT`列が`CHECK`制約で動作しない問題を修正 [＃38894](https://github.com/pingcap/tidb/issues/38894) @ [YangKeao](https://github.com/YangKeao) - - `INSERT IGNORE INTO`使用して`STRING`型のデータを`SMALLINT`型のAUTO_INCREMENT列に挿入すると、エラーが発生する問題を修正しました。 [＃38483](https://github.com/pingcap/tidb/issues/38483) @ [hawkingrei](https://github.com/hawkingrei) + - `INSERT IGNORE INTO`を使用して`STRING`型のデータを`SMALLINT`型のAUTO_INCREMENT列に挿入すると、エラーが発生する問題を修正しました。 [＃38483](https://github.com/pingcap/tidb/issues/38483) @ [hawkingrei](https://github.com/hawkingrei) - パーティションテーブルのパーティション列の名前を変更する操作で NULL ポインタ エラーが発生する問題を修正しました。 [＃38932](https://github.com/pingcap/tidb/issues/38932) @ [mjonss](https://github.com/mjonss) - パーティションテーブルのパーティション列を変更すると、DDLがハングする問題を修正しました。 [＃38530](https://github.com/pingcap/tidb/issues/38530) @ [mjonss](https://github.com/mjonss) - v4.0.16からv6.4.0 にアップグレードした後に`ADMIN SHOW JOB`操作がパニックになる問題を修正 [＃38980](https://github.com/pingcap/tidb/issues/38980) @ [tangenta](https://github.com/tangenta) diff --git a/releases/release-6.5.1.md b/releases/release-6.5.1.md index 246f8357b2330..2f47fd4348cb5 100644 --- a/releases/release-6.5.1.md +++ b/releases/release-6.5.1.md @@ -120,7 +120,7 @@ TiDB バージョン: 6.5.1 - インデックス[＃40698](https://github.com/pingcap/tidb/issues/40698) [＃40730](https://github.com/pingcap/tidb/issues/40730) [＃41459](https://github.com/pingcap/tidb/issues/41459) を追加するときにデータの不整合が発生する問題を修正しました [＃40217](https://github.com/pingcap/tidb/issues/40217) @ [tangenta](https://github.com/tangenta) [＃40464](https://github.com/pingcap/tidb/issues/40464) - インデックスを追加するときに`Pessimistic lock not found`エラーが発生する問題を修正しました [＃41515](https://github.com/pingcap/tidb/issues/41515) @ [tangenta](https://github.com/tangenta) - 一意インデックスを追加するときに誤って報告される重複キーエラーの問題を修正しました [＃41630](https://github.com/pingcap/tidb/issues/41630) @ [tangenta](https://github.com/tangenta) - - TiDB で`paging`使用するとパフォーマンスが低下する問題を修正 [＃40741](https://github.com/pingcap/tidb/issues/40741) @ [solotzg](https://github.com/solotzg) + - TiDB で`paging`を使用するとパフォーマンスが低下する問題を修正 [＃40741](https://github.com/pingcap/tidb/issues/40741) @ [solotzg](https://github.com/solotzg) - TiKV @@ -175,7 +175,7 @@ TiDB バージョン: 6.5.1 - REDOログがメタへの書き込みを有効にするとパフォーマンスが低下する問題を修正しました [＃8074](https://github.com/pingcap/tiflow/issues/8074) @ [CharlesCheung96](https://github.com/CharlesCheung96) - TiCDCが大きなトランザクションを@ [Rustin170506](https://github.com/Rustin170506)に分割せずにデータを複製するとコンテキスト期限が超過するバグを修正 [＃7982](https://github.com/pingcap/tiflow/issues/7982) - PDが異常なときにチェンジフィードを一時停止すると、誤ったステータスになる問題を修正しました。 [＃8330](https://github.com/pingcap/tiflow/issues/8330) @ [sdojjy](https://github.com/sdojjy) - - TiDB または MySQL シンクにデータを複製するときに、主キーのない非 NULL ユニーク インデックスを持つ列に`CHARACTER SET`指定した場合に発生するデータの不整合を修正しました。 [＃8420](https://github.com/pingcap/tiflow/issues/8420) @ [asddongmen](https://github.com/asddongmen) + - TiDB または MySQL シンクにデータを複製するときに、主キーのない非 NULL ユニーク インデックスを持つ列に`CHARACTER SET`を指定した場合に発生するデータの不整合を修正しました。 [＃8420](https://github.com/pingcap/tiflow/issues/8420) @ [asddongmen](https://github.com/asddongmen) - テーブルスケジューリングとブラックホールシンクのpanic問題を修正[＃8024](https://github.com/pingcap/tiflow/issues/8024) [＃8142](https://github.com/pingcap/tiflow/issues/8142) @ [hicqu](https://github.com/hicqu) - TiDB Data Migration (DM) diff --git a/releases/release-6.5.10.md b/releases/release-6.5.10.md index 5d540c6a30691..4cfcacfb1e298 100644 --- a/releases/release-6.5.10.md +++ b/releases/release-6.5.10.md @@ -105,7 +105,7 @@ TiDB バージョン: 6.5.10 - TiFlash - - データベース間で`ALTER TABLE ... EXCHANGE PARTITION`実行した後にTiFlash がスキーマの同期に失敗する可能性がある問題を修正しました[＃7296](https://github.com/pingcap/tiflash/issues/7296) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - データベース間で`ALTER TABLE ... EXCHANGE PARTITION`を実行した後にTiFlash がスキーマの同期に失敗する可能性がある問題を修正しました[＃7296](https://github.com/pingcap/tiflash/issues/7296) @ [JaySon-Huang](https://github.com/JaySon-Huang) - 空のキー範囲を持つクエリがTiFlashで読み取りタスクを正しく生成できず、 TiFlashクエリがブロックされる可能性がある問題を修正しました。 [＃9108](https://github.com/pingcap/tiflash/issues/9108) @ [JinheLin](https://github.com/JinheLin) - `SUBSTRING_INDEX()`関数が一部のコーナーケースでTiFlash のクラッシュを引き起こす可能性がある問題を修正[＃9116](https://github.com/pingcap/tiflash/issues/9116) @ [wshwsh12](https://github.com/wshwsh12) - クラスタをv6.5.0より前のバージョンからv6.5.0以降にアップグレードするときに、 TiFlashメタデータが破損してプロセスがpanicになる可能性がある問題を修正しました[＃9039](https://github.com/pingcap/tiflash/issues/9039) @ [JaySon-Huang](https://github.com/JaySon-Huang) diff --git a/releases/release-6.5.12.md b/releases/release-6.5.12.md index 3ac885d8a8d98..c657d4e949923 100644 --- a/releases/release-6.5.12.md +++ b/releases/release-6.5.12.md @@ -58,7 +58,7 @@ TiDBバージョン: 6.5.12 - `CREATE VIEW`ステートメントで変数またはパラメータを使用してもエラーが報告されない問題を修正[＃53176](https://github.com/pingcap/tidb/issues/53176) @ [mjonss](https://github.com/mjonss) - 解放されていないセッションリソースがメモリリークを引き起こす可能性がある問題を修正[＃56271](https://github.com/pingcap/tidb/issues/56271) @ [lance6716](https://github.com/lance6716) - 分散実行フレームワークの PD メンバーを変更した後に`ADD INDEX`実行が失敗する可能性がある問題を修正しました [＃48680](https://github.com/pingcap/tidb/issues/48680) @ [lance6716](https://github.com/lance6716) - - `cluster_slow_query table`クエリするときに`ORDER BY`使用すると、順序付けられていない結果が生成される可能性がある問題を修正しました。 [＃51723](https://github.com/pingcap/tidb/issues/51723) @ [Defined2014](https://github.com/Defined2014) + - `cluster_slow_query table`クエリするときに`ORDER BY`を使用すると、順序付けられていない結果が生成される可能性がある問題を修正しました。 [＃51723](https://github.com/pingcap/tidb/issues/51723) @ [Defined2014](https://github.com/Defined2014) - stale read が読み取り操作のタイムスタンプを厳密に検証しない問題を修正しました。その結果、TSO と実際の物理時間の間にオフセットが存在する場合に、トランザクションの一貫性にわずかながら影響する可能性が生じます。 [＃56809](https://github.com/pingcap/tidb/issues/56809) @ [MyonKeminta](https://github.com/MyonKeminta) - クエリ`INFORMATION_SCHEMA.columns`のパフォーマンスが@ [lance6716](https://github.com/lance6716)で低下する問題を修正 [＃58184](https://github.com/pingcap/tidb/issues/58184) - `INSERT ... ON DUPLICATE KEY`文が`mysql_insert_id` と互換性がない問題を修正 [＃55965](https://github.com/pingcap/tidb/issues/55965) @ [tiancaiamao](https://github.com/tiancaiamao) @@ -131,7 +131,7 @@ TiDBバージョン: 6.5.12 - TiFlashでサポートされていない一部の JSON関数がTiFlash にプッシュダウンされる問題を修正しました [＃9444](https://github.com/pingcap/tiflash/issues/9444) @ [windtalker](https://github.com/windtalker) - 2番目のパラメータが負のの場合に`SUBSTRING()`関数が誤った結果を返す問題を修正しました [＃9604](https://github.com/pingcap/tiflash/issues/9604) @ [guo-shaoge](https://github.com/guo-shaoge) - `LPAD()`と`RPAD()`関数が、場合によっては誤った結果を返す問題を修正しました[＃9465](https://github.com/pingcap/tiflash/issues/9465) @ [guo-shaoge](https://github.com/guo-shaoge) - - 大きなテーブルで`DROP TABLE`実行するとTiFlash OOM が発生する可能性がある問題を修正しました [＃9437](https://github.com/pingcap/tiflash/issues/9437) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - 大きなテーブルで`DROP TABLE`を実行するとTiFlash OOM が発生する可能性がある問題を修正しました [＃9437](https://github.com/pingcap/tiflash/issues/9437) @ [JaySon-Huang](https://github.com/JaySon-Huang) - CPUコア数を取得する際にゼロ除算エラーが発生し、 TiFlashが起動に失敗する問題を修正しました。 [＃9212](https://github.com/pingcap/tiflash/issues/9212) @ [xzhangxian1008](https://github.com/xzhangxian1008) - 大量のデータをインポートした後にTiFlash のメモリ使用量が高くなる可能性がある問題を修正[＃9812](https://github.com/pingcap/tiflash/issues/9812) @ [CalvinNeo](https://github.com/CalvinNeo) diff --git a/releases/release-6.5.2.md b/releases/release-6.5.2.md index 49e34efbc1ab8..ee707980517ec 100644 --- a/releases/release-6.5.2.md +++ b/releases/release-6.5.2.md @@ -51,13 +51,13 @@ TiDB バージョン: 6.5.2 - TiDB - キャッシュテーブルに新しい列が追加された後、列のデフォルト値ではなく値が`NULL`なる問題を修正しました。 [＃42928](https://github.com/pingcap/tidb/issues/42928) @ [lqs](https://github.com/lqs) - - 多数のパーティションとTiFlashレプリカを持つパーティション テーブルに対して`TRUNCATE TABLE`実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。 [＃42940](https://github.com/pingcap/tidb/issues/42940) @ [mjonss](https://github.com/mjonss) + - 多数のパーティションとTiFlashレプリカを持つパーティション テーブルに対して`TRUNCATE TABLE`を実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。 [＃42940](https://github.com/pingcap/tidb/issues/42940) @ [mjonss](https://github.com/mjonss) - `DROP TABLE`操作が実行されているときに`ADMIN SHOW DDL JOBS`結果にテーブル名が表示されない問題を修正[＃42268](https://github.com/pingcap/tidb/issues/42268) @ [tiancaiamao](https://github.com/tiancaiamao) - cgroup 情報の読み取りエラーにより、TiDBサーバーが起動できない問題を修正しました。エラー メッセージは「cgroup v1 からファイルメモリ.stat を読み取れません: /sys/メモリ.stat をオープンすると、そのようなファイルまたはディレクトリが見つかりません」です[＃42659](https://github.com/pingcap/tidb/issues/42659) @ [hawkingrei](https://github.com/hawkingrei) - DDLデータバックフィルを実行するときにトランザクションで頻繁に発生する書き込み競合を修正 [＃24427](https://github.com/pingcap/tidb/issues/24427) @ [mjonss](https://github.com/mjonss) - 実行プランを生成する際に不整合な InfoSchema が取得され、TiDB panicが発生する問題を修正しました。 [＃41622](https://github.com/pingcap/tidb/issues/41622) @ [tiancaiamao](https://github.com/tiancaiamao) - DDLを使用して浮動小数点型を変更し、長さを変更せずに小数点以下の桁数を減らしても、古いデータが同じままになる問題を修正しました[＃41281](https://github.com/pingcap/tidb/issues/41281) @ [zimulala](https://github.com/zimulala) - - トランザクション内で`PointUpdate`実行した後、TiDB が`SELECT`文に対して誤った結果を返す問題を修正しました。 [＃28011](https://github.com/pingcap/tidb/issues/28011) @ [zyguan](https://github.com/zyguan) + - トランザクション内で`PointUpdate`を実行した後、TiDB が`SELECT`文に対して誤った結果を返す問題を修正しました。 [＃28011](https://github.com/pingcap/tidb/issues/28011) @ [zyguan](https://github.com/zyguan) - カーソルフェッチを使用し、実行、フェッチ、およびクローズの間に他のステートメントを実行すると、フェッチおよびクローズコマンドが誤った結果を返したり、TiDB がpanicたりする可能性がある問題を修正しました[＃40094](https://github.com/pingcap/tidb/issues/40094) @ [YangKeao](https://github.com/YangKeao) - `INSERT IGNORE`と`REPLACE`ステートメントが値を変更しないキーをロックしない問題を修正しました [＃42121](https://github.com/pingcap/tidb/issues/42121) @ [zyguan](https://github.com/zyguan) - 実行中にTiFlash が生成された列に対してエラーを報告する問題を修正[＃40663](https://github.com/pingcap/tidb/issues/40663) @ [guo-shaoge](https://github.com/guo-shaoge) diff --git a/releases/release-6.5.3.md b/releases/release-6.5.3.md index ab85e9562dd24..40c01fc59d976 100644 --- a/releases/release-6.5.3.md +++ b/releases/release-6.5.3.md @@ -75,7 +75,7 @@ TiDB バージョン: 6.5.3 - `ADMIN SHOW DDL JOBS LIMIT`誤った結果を返す問題を修正[＃42298](https://github.com/pingcap/tidb/issues/42298) @ [CbcWestwolf](https://github.com/CbcWestwolf) - パスワードの複雑さのチェックが有効になっているときに`tidb_auth_token`ユーザーの作成に失敗する問題を修正[＃44098](https://github.com/pingcap/tidb/issues/44098) @ [CbcWestwolf](https://github.com/CbcWestwolf) - 動的プルーニングモードで内部結合中にパーティションが見つからない問題を修正 [＃43686](https://github.com/pingcap/tidb/issues/43686) @ [mjonss](https://github.com/mjonss) - - パーティションテーブルで`MODIFY COLUMN`実行すると`Data Truncated`警告が発生する問題を修正しました [＃41118](https://github.com/pingcap/tidb/issues/41118) @ [mjonss](https://github.com/mjonss) + - パーティションテーブルで`MODIFY COLUMN`を実行すると`Data Truncated`警告が発生する問題を修正しました [＃41118](https://github.com/pingcap/tidb/issues/41118) @ [mjonss](https://github.com/mjonss) - IPv6環境で誤ったTiDBアドレスが表示される問題を修正[＃43260](https://github.com/pingcap/tidb/issues/43260) @ [nexustar](https://github.com/nexustar) - 述語をプッシュダウンするときに CTE 結果が正しくない問題を修正しました [＃43645](https://github.com/pingcap/tidb/issues/43645) @ [winoros](https://github.com/winoros) - 非相関サブクエリを含むステートメントで共通テーブル式 (CTE) を使用すると誤った結果が返される可能性がある問題を修正しました [＃44051](https://github.com/pingcap/tidb/issues/44051) @ [winoros](https://github.com/winoros) diff --git a/releases/release-6.5.4.md b/releases/release-6.5.4.md index 22712c6fa04cc..3a8d9f866ca18 100644 --- a/releases/release-6.5.4.md +++ b/releases/release-6.5.4.md @@ -13,7 +13,7 @@ TiDB バージョン: 6.5.4 ## 互換性の変更 {#compatibility-changes} -- `Cursor Fetch`使用して大きな結果セットを取得するときにTiDBがメモリを大量に消費する問題を修正するために、TiDBは結果セットを自動的にディスクに書き込んでメモリを解放します[＃43233](https://github.com/pingcap/tidb/issues/43233) @ [YangKeao](https://github.com/YangKeao) +- `Cursor Fetch`を使用して大きな結果セットを取得するときにTiDBがメモリを大量に消費する問題を修正するために、TiDBは結果セットを自動的にディスクに書き込んでメモリを解放します[＃43233](https://github.com/pingcap/tidb/issues/43233) @ [YangKeao](https://github.com/YangKeao) - RocksDBの定期的な圧縮をデフォルトで無効にすることで、TiKV RocksDBのデフォルトの動作がv6.5.0より前のバージョンと一致するようになりました。この変更により、アップグレード後に大量の圧縮が行われることによるパフォーマンスへの影響を回避できます。さらに、TiKVでは2つの新しい設定項目[`rocksdb.[defaultcf|writecf|lockcf].periodic-compaction-seconds`](https://docs.pingcap.com/tidb/v6.5/tikv-configuration-file#periodic-compaction-seconds-new-in-v654)と[`rocksdb.[defaultcf|writecf|lockcf].ttl`](https://docs.pingcap.com/tidb/v6.5/tikv-configuration-file#ttl-new-in-v654)導入され、RocksDB の定期的な圧縮を手動で設定できるようになりました。 [＃15355](https://github.com/tikv/tikv/issues/15355) @ [LykxSassinator](https://github.com/LykxSassinator) ### 動作の変更 {#behavior-changes} @@ -132,7 +132,7 @@ TiDB バージョン: 6.5.4 - etcd がすでに起動しているがクライアントがまだ接続していない場合、クライアントを呼び出すと PD がpanicになる可能性がある問題を修正しました。 [＃6860](https://github.com/tikv/pd/issues/6860) @ [HuSharp](https://github.com/HuSharp) - リーダーが長時間退出できない問題を修正[＃6918](https://github.com/tikv/pd/issues/6918) @ [bufferflies](https://github.com/bufferflies) - - 配置ルールが`LOCATION_LABELS`使用する場合、SQL とルールチェッカーがと互換性がない問題を修正しました [＃38605](https://github.com/pingcap/tidb/issues/38605) @ [nolouch](https://github.com/nolouch) + - 配置ルールが`LOCATION_LABELS`を使用する場合、SQL とルールチェッカーがと互換性がない問題を修正しました [＃38605](https://github.com/pingcap/tidb/issues/38605) @ [nolouch](https://github.com/nolouch) - PD が予期せず複数のラーナーをリージョンに追加する可能性がある問題を修正しました。 [＃5786](https://github.com/tikv/pd/issues/5786) @ [HunDunDM](https://github.com/HunDunDM) - ルールチェッカーがピアを選択した場合に、不健全なピアを削除できない問題を修正しました [＃6559](https://github.com/tikv/pd/issues/6559) @ [nolouch](https://github.com/nolouch) - `unsafe recovery`で不合格になったラーナーのピアが`auto-detect`モードで無視される問題を修正 [＃6690](https://github.com/tikv/pd/issues/6690) @ [v01dstar](https://github.com/v01dstar) diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index 1623cc73b807e..f9aea4cb23fa3 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -82,7 +82,7 @@ TiDB バージョン: 6.5.6 - `tidb_enable_ordered_result_mode`有効になっているときにpanicが発生する可能性がある問題を修正[＃45044](https://github.com/pingcap/tidb/issues/45044) @ [qw4990](https://github.com/qw4990) - ウィンドウ関数によって導入されたソートを削減するために、オプティマイザが誤って IndexFullScan を選択する問題を修正しました。 [＃46177](https://github.com/pingcap/tidb/issues/46177) @ [qw4990](https://github.com/qw4990) - 述語が共通テーブル式にプッシュダウンされたときに結果が不正確になる可能性がある問題を修正しました [＃47881](https://github.com/pingcap/tidb/issues/47881) @ [winoros](https://github.com/winoros) - - DUALテーブルを最初のサブノードとして`UNION ALL`実行するとエラーが発生する可能性がある問題を修正しました。 [＃48755](https://github.com/pingcap/tidb/issues/48755) @ [winoros](https://github.com/winoros) + - DUALテーブルを最初のサブノードとして`UNION ALL`を実行するとエラーが発生する可能性がある問題を修正しました。 [＃48755](https://github.com/pingcap/tidb/issues/48755) @ [winoros](https://github.com/winoros) - 特定の状況で列の整理によってpanicが発生する可能性がある問題を修正[＃47331](https://github.com/pingcap/tidb/issues/47331) @ [Rustin170506](https://github.com/Rustin170506) - 集計関数またはウィンドウ関数を含む共通テーブル式 (CTE) が他の再帰 CTE によって参照されるときに発生する可能性のある構文エラーの問題を修正しました[＃47603](https://github.com/pingcap/tidb/issues/47603) [＃47711](https://github.com/pingcap/tidb/issues/47711) @ [elsa0520](https://github.com/elsa0520) - プリペアドステートメントで`QB_NAME`ヒントを使用すると例外が発生する可能性がある問題を修正しました [＃46817](https://github.com/pingcap/tidb/issues/46817) @ [jackysp](https://github.com/jackysp) @@ -151,7 +151,7 @@ TiDB バージョン: 6.5.6 - TiCDC - アップストリームで損失のある DDL 文を実行すると TiCDCサーバーがpanic可能性がある問題を修正しました。 [＃9739](https://github.com/pingcap/tiflow/issues/9739) @ [hicqu](https://github.com/hicqu) - - 再実行ログ機能を有効にした状態で`RESUME`実行するとレプリケーションタスクがエラーを報告する問題を修正[＃9769](https://github.com/pingcap/tiflow/issues/9769) @ [hicqu](https://github.com/hicqu) + - 再実行ログ機能を有効にした状態で`RESUME`を実行するとレプリケーションタスクがエラーを報告する問題を修正[＃9769](https://github.com/pingcap/tiflow/issues/9769) @ [hicqu](https://github.com/hicqu) - TiKVノードがクラッシュするとレプリケーションラグが長くなる問題を修正[＃9741](https://github.com/pingcap/tiflow/issues/9741) @ [sdojjy](https://github.com/sdojjy) - `WHERE`文が TiDB または MySQL にデータを複製するときに主キーを条件として使用しない問題を修正しました [＃9988](https://github.com/pingcap/tiflow/issues/9988) @ [asddongmen](https://github.com/asddongmen) - レプリケーションタスクのワークロードが TiCDC ノード間で均等に分散されない問題を修正しました [＃9839](https://github.com/pingcap/tiflow/issues/9839) @ [3AceShowHand](https://github.com/3AceShowHand) diff --git a/releases/release-6.5.8.md b/releases/release-6.5.8.md index 179d63a89f271..b00f3d95c1ee2 100644 --- a/releases/release-6.5.8.md +++ b/releases/release-6.5.8.md @@ -42,10 +42,10 @@ TiDB バージョン: 6.5.8 - 誤ったパーティションプルーニングが原因で、範囲パーティションテーブルのクエリ結果が間違っている場合がある問題を修正しました。 [＃50082](https://github.com/pingcap/tidb/issues/50082) @ [Defined2014](https://github.com/Defined2014) - `AUTO_ID_CACHE=1` のAUTO_INCREMENT列を使用すると同時競合によりAUTO_INCREMENT ID 割り当てでエラーが報告される問題を修正しました。 [＃50519](https://github.com/pingcap/tidb/issues/50519) @ [tiancaiamao](https://github.com/tiancaiamao) - 多数のテーブルまたはパーティションを処理するときに TiDB ノードが OOM エラーに遭遇する可能性がある問題を軽減します。 [＃50077](https://github.com/pingcap/tidb/issues/50077) @ [zimulala](https://github.com/zimulala) - - DDL所有者がネットワークから分離されている後に`ADD INDEX`実行すると、TiDB分散実行フレームワーク（DXF）でデータが不整合になる問題を修正しました [＃49773](https://github.com/pingcap/tidb/issues/49773) @ [tangenta](https://github.com/tangenta) + - DDL所有者がネットワークから分離されている後に`ADD INDEX`を実行すると、TiDB分散実行フレームワーク（DXF）でデータが不整合になる問題を修正しました [＃49773](https://github.com/pingcap/tidb/issues/49773) @ [tangenta](https://github.com/tangenta) - クエリに Apply 演算子が含まれており、 `fatal error: concurrent map writes`エラーが発生すると TiDB がpanic可能性がある問題を修正しました。 [＃50347](https://github.com/pingcap/tidb/issues/50347) @ [SeaRise](https://github.com/SeaRise) - `COM_STMT_EXECUTE`まで実行された`COMMIT`または`ROLLBACK`操作が、タイムアウトしたトランザクションをで終了できない問題を修正しました。 [＃49151](https://github.com/pingcap/tidb/issues/49151) @ [zyguan](https://github.com/zyguan) - - `PREPARE`メソッドを使用して`SELECT INTO OUTFILE`実行すると、エラーではなく、誤って成功メッセージが返される問題を修正しました。 [＃49166](https://github.com/pingcap/tidb/issues/49166) @ [qw4990](https://github.com/qw4990) + - `PREPARE`メソッドを使用して`SELECT INTO OUTFILE`を実行すると、エラーではなく、誤って成功メッセージが返される問題を修正しました。 [＃49166](https://github.com/pingcap/tidb/issues/49166) @ [qw4990](https://github.com/qw4990) - `ORDER BY`句で`UNIQUE`インデックス検索を実行するとエラーが発生する可能性がある問題を修正しました。 [＃49920](https://github.com/pingcap/tidb/issues/49920) @ [jackysp](https://github.com/jackysp) - `tidb_multi_statement_mode`モードが有効になっている場合、インデックス検索を使用する`DELETE`および`UPDATE`ステートメントでエラーが報告される可能性がある問題を修正しました[＃50012](https://github.com/pingcap/tidb/issues/50012) @ [tangenta](https://github.com/tangenta) - `LEADING`ヒントが`UNION ALL`ステートメントで有効にならない問題を修正しました [＃50067](https://github.com/pingcap/tidb/issues/50067) @ [hawkingrei](https://github.com/hawkingrei) @@ -61,12 +61,12 @@ TiDB バージョン: 6.5.8 - PD - - `pd-ctl`使用してリーダーのないリージョンを照会すると、PD がpanicになる可能性がある問題を修正しました。 [＃7630](https://github.com/tikv/pd/issues/7630) @ [rleungx](https://github.com/rleungx) + - `pd-ctl`を使用してリーダーのないリージョンを照会すると、PD がpanicになる可能性がある問題を修正しました。 [＃7630](https://github.com/tikv/pd/issues/7630) @ [rleungx](https://github.com/rleungx) - TiFlash - `lowerUTF8`と`upperUTF8`関数で、大文字と小文字が異なるバイトを占めることができない問題を修正しました。 [＃8484](https://github.com/pingcap/tiflash/issues/8484) @ [gengliqi](https://github.com/gengliqi) - - `ALTER TABLE ... MODIFY COLUMN ... NOT NULL`実行した後にTiFlash がパニックを起こし、NULL 可能列がに非 NULL に変更される問題を修正しました。 [＃8419](https://github.com/pingcap/tiflash/issues/8419) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - `ALTER TABLE ... MODIFY COLUMN ... NOT NULL`を実行した後にTiFlash がパニックを起こし、NULL 可能列がに非 NULL に変更される問題を修正しました。 [＃8419](https://github.com/pingcap/tiflash/issues/8419) @ [JaySon-Huang](https://github.com/JaySon-Huang) - クエリを終了した後、 TiFlash上の多数のタスクが同時にキャンセルされると、同時データの競合によりTiFlashがクラッシュする問題を修正[＃7432](https://github.com/pingcap/tiflash/issues/7432) @ [SeaRise](https://github.com/SeaRise) - ツール diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index 4dad15890f21d..5e1a0d8bbf5cc 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -251,7 +251,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | [`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700) | 変更 | デフォルト値を`OFF`から`ON`に変更します。これは、 TiFlash の遅延マテリアライゼーション機能がデフォルトで有効になっていることを意味します。 | | [`authentication_ldap_sasl_auth_method_name`](/system-variables.md#authentication_ldap_sasl_auth_method_name-new-in-v710) | 新しく追加された | LDAP SASL 認証における認証方法名を指定します。 | | [`authentication_ldap_sasl_bind_base_dn`](/system-variables.md#authentication_ldap_sasl_bind_base_dn-new-in-v710) | 新しく追加された | LDAP SASL認証における検索ツリー内の検索範囲を制限します。1 `AS ...`の句を指定せずにユーザーが作成された場合、TiDBはユーザー名に基づいてLDAPサーバー内の`dn`の句を自動的に検索します。 | -| [`authentication_ldap_sasl_bind_root_dn`](/system-variables.md#authentication_ldap_sasl_bind_root_dn-new-in-v710) | 新しく追加された | LDAP SASL 認証でユーザーを検索するために LDAPサーバーにログインするために使用される`dn`指定します。 | +| [`authentication_ldap_sasl_bind_root_dn`](/system-variables.md#authentication_ldap_sasl_bind_root_dn-new-in-v710) | 新しく追加された | LDAP SASL 認証でユーザーを検索するために LDAPサーバーにログインするために使用される`dn`を指定します。 | | [`authentication_ldap_sasl_bind_root_pwd`](/system-variables.md#authentication_ldap_sasl_bind_root_pwd-new-in-v710) | 新しく追加された | LDAP SASL 認証でユーザーを検索するために LDAPサーバーにログインするために使用されるパスワードを指定します。 | | [`authentication_ldap_sasl_ca_path`](/system-variables.md#authentication_ldap_sasl_ca_path-new-in-v710) | 新しく追加された | LDAP SASL 認証における StartTLS 接続用の証明機関ファイルの絶対パスを指定します。 | | [`authentication_ldap_sasl_init_pool_size`](/system-variables.md#authentication_ldap_sasl_init_pool_size-new-in-v710) | 新しく追加された | LDAP SASL 認証で LDAPサーバーへの接続プール内の初期接続を指定します。 | @@ -261,7 +261,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | [`authentication_ldap_sasl_tls`](/system-variables.md#authentication_ldap_sasl_tls-new-in-v710) | 新しく追加された | プラグインによる LDAPサーバーへの接続が LDAP SASL 認証の StartTLS で保護されるかどうかを指定します。 | | [`authentication_ldap_simple_auth_method_name`](/system-variables.md#authentication_ldap_simple_auth_method_name-new-in-v710) | 新しく追加された | LDAP簡易認証における認証方式名を指定します。1 `SIMPLE`サポートされます。 | | [`authentication_ldap_simple_bind_base_dn`](/system-variables.md#authentication_ldap_simple_bind_base_dn-new-in-v710) | 新しく追加された | LDAP簡易認証における検索ツリー内の検索範囲を制限します。1 `AS ...`の句を指定せずにユーザーが作成された場合、TiDBはユーザー名に基づいてLDAPサーバー内の`dn`の句を自動的に検索します。 | -| [`authentication_ldap_simple_bind_root_dn`](/system-variables.md#authentication_ldap_simple_bind_root_dn-new-in-v710) | 新しく追加された | LDAP 簡易認証でユーザーを検索するために LDAPサーバーにログインするために使用される`dn`指定します。 | +| [`authentication_ldap_simple_bind_root_dn`](/system-variables.md#authentication_ldap_simple_bind_root_dn-new-in-v710) | 新しく追加された | LDAP 簡易認証でユーザーを検索するために LDAPサーバーにログインするために使用される`dn`を指定します。 | | [`authentication_ldap_simple_bind_root_pwd`](/system-variables.md#authentication_ldap_simple_bind_root_pwd-new-in-v710) | 新しく追加された | LDAP 簡易認証でユーザーを検索するために LDAPサーバーにログインするために使用されるパスワードを指定します。 | | [`authentication_ldap_simple_ca_path`](/system-variables.md#authentication_ldap_simple_ca_path-new-in-v710) | 新しく追加された | LDAP 簡易認証での StartTLS 接続用の証明機関ファイルの絶対パスを指定します。 | | [`authentication_ldap_simple_init_pool_size`](/system-variables.md#authentication_ldap_simple_init_pool_size-new-in-v710) | 新しく追加された | LDAP 簡易認証で、LDAPサーバーへの接続プール内の初期接続を指定します。 | @@ -309,7 +309,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - TiDB - 対応する列の個別値の数を、 `SHOW INDEX`結果の Cardinality 列に表示します。 [＃42227](https://github.com/pingcap/tidb/issues/42227) @ [winoros](https://github.com/winoros) - - TTLスキャンクエリがTiKVブロックキャッシュに影響を与えないようにするには`SQL_NO_CACHE`使用します。 [＃43206](https://github.com/pingcap/tidb/issues/43206) @ [lcwangchao](https://github.com/lcwangchao) + - TTLスキャンクエリがTiKVブロックキャッシュに影響を与えないようにするには`SQL_NO_CACHE`を使用します。 [＃43206](https://github.com/pingcap/tidb/issues/43206) @ [lcwangchao](https://github.com/lcwangchao) - `MAX_EXECUTION_TIME`に関連するエラーメッセージを改善し、MySQL と互換性を持たせます [＃43031](https://github.com/pingcap/tidb/issues/43031) @ [dveeden](https://github.com/dveeden) - IndexLookUp のパーティションテーブルでの MergeSort 演算子の使用をサポート [＃26166](https://github.com/pingcap/tidb/issues/26166) @ [Defined2014](https://github.com/Defined2014) - MySQL と互換性を持たせるために`caching_sha2_password`拡張します [＃43576](https://github.com/pingcap/tidb/issues/43576) @ [asjdf](https://github.com/asjdf) @@ -358,14 +358,14 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - TiDB - - パーティションを再編成した後、手動で`ANALYZE TABLE`実行するプロンプトが表示されない問題を修正しました。 [＃42183](https://github.com/pingcap/tidb/issues/42183) @ [CbcWestwolf](https://github.com/CbcWestwolf) + - パーティションを再編成した後、手動で`ANALYZE TABLE`を実行するプロンプトが表示されない問題を修正しました。 [＃42183](https://github.com/pingcap/tidb/issues/42183) @ [CbcWestwolf](https://github.com/CbcWestwolf) - `DROP TABLE`操作が実行されているときに`ADMIN SHOW DDL JOBS`結果にテーブル名が表示されない問題を修正[＃42268](https://github.com/pingcap/tidb/issues/42268) @ [tiancaiamao](https://github.com/tiancaiamao) - Grafana モニタリング パネルで`Ignore Event Per Minute`と`Stats Cache LRU Cost`チャートが正常に表示されないことがある問題を修正しました [＃42562](https://github.com/pingcap/tidb/issues/42562) @ [pingandb](https://github.com/pingandb) - `INFORMATION_SCHEMA.COLUMNS`テーブルをクエリするときに`ORDINAL_POSITION`列が誤った結果を返す問題を修正しました [＃43379](https://github.com/pingcap/tidb/issues/43379) @ [bb7133](https://github.com/bb7133) - キャッシュ テーブルに新しい列が追加された後、列のデフォルト値ではなく値が`NULL`になる問題を修正しました。 [＃42928](https://github.com/pingcap/tidb/issues/42928) @ [lqs](https://github.com/lqs) - 述語をプッシュダウンするときに CTE 結果が正しくない問題を修正しました [＃43645](https://github.com/pingcap/tidb/issues/43645) @ [winoros](https://github.com/winoros) - - 多数のパーティションとTiFlashレプリカを持つパーティション テーブルに対して`TRUNCATE TABLE`実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。 [＃42940](https://github.com/pingcap/tidb/issues/42940) @ [mjonss](https://github.com/mjonss) - - パーティションテーブル の作成時に`SUBPARTITION`使用すると警告が表示されない問題を修正 [＃41200](https://github.com/pingcap/tidb/issues/41200) @ [mjonss](https://github.com/mjonss) [＃41198](https://github.com/pingcap/tidb/issues/41198) + - 多数のパーティションとTiFlashレプリカを持つパーティション テーブルに対して`TRUNCATE TABLE`を実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。 [＃42940](https://github.com/pingcap/tidb/issues/42940) @ [mjonss](https://github.com/mjonss) + - パーティションテーブル の作成時に`SUBPARTITION`を使用すると警告が表示されない問題を修正 [＃41200](https://github.com/pingcap/tidb/issues/41200) @ [mjonss](https://github.com/mjonss) [＃41198](https://github.com/pingcap/tidb/issues/41198) - 生成された列の値オーバーフローの問題を処理する際の MySQL との非互換性の問題を修正しました [＃40066](https://github.com/pingcap/tidb/issues/40066) @ [jiyfhust](https://github.com/jiyfhust) - `REORGANIZE PARTITION`他の DDL 操作と同時に実行できない問題を修正 [＃42442](https://github.com/pingcap/tidb/issues/42442) @ [bb7133](https://github.com/bb7133) - DDL でパーティション再編成タスクをキャンセルすると、後続の DDL 操作が失敗する可能性がある問題を修正しました[＃42448](https://github.com/pingcap/tidb/issues/42448) @ [lcwangchao](https://github.com/lcwangchao) diff --git a/releases/release-7.1.1.md b/releases/release-7.1.1.md index f37bc4e4bbab8..347b9eef12a4b 100644 --- a/releases/release-7.1.1.md +++ b/releases/release-7.1.1.md @@ -88,7 +88,7 @@ TiDB バージョン: 7.1.1 - 取り込みモードでインデックスの追加が失敗する問題を修正 [＃44137](https://github.com/pingcap/tidb/issues/44137) @ [tangenta](https://github.com/tangenta) - テーブルパーティション定義で`FLOOR()`関数を使用してパーティション列をに丸めた場合、 `SELECT`ステートメントがパーティションテーブルに対してエラーを返す問題を修正しました。 [＃42323](https://github.com/pingcap/tidb/issues/42323) @ [jiyfhust](https://github.com/jiyfhust) - フォロワー読み取りが再試行前にフラッシュバックエラーを処理せず、クエリエラーが発生する問題を修正しました [＃43673](https://github.com/pingcap/tidb/issues/43673) @ [you06](https://github.com/you06) - - カーソルフェッチで`memTracker`使用するとメモリリークが発生する問題を修正[＃44254](https://github.com/pingcap/tidb/issues/44254) @ [YangKeao](https://github.com/YangKeao) + - カーソルフェッチで`memTracker`を使用するとメモリリークが発生する問題を修正[＃44254](https://github.com/pingcap/tidb/issues/44254) @ [YangKeao](https://github.com/YangKeao) - `SHOW PROCESSLIST`文でサブクエリ時間が長い文のトランザクションの TxnStart を表示できない問題を修正[＃40851](https://github.com/pingcap/tidb/issues/40851) @ [crazycs520](https://github.com/crazycs520) - `LEADING`ヒントがブロックエイリアスのクエリをサポートしない問題を修正しました [＃44645](https://github.com/pingcap/tidb/issues/44645) @ [qw4990](https://github.com/qw4990) - `PREPARE stmt FROM "ANALYZE TABLE xxx"` `tidb_mem_quota_query` で殺される可能性がある問題を修正 [＃44320](https://github.com/pingcap/tidb/issues/44320) @ [chrysan](https://github.com/chrysan) diff --git a/releases/release-7.1.3.md b/releases/release-7.1.3.md index 38c6b284e1447..d6bbfec4aacac 100644 --- a/releases/release-7.1.3.md +++ b/releases/release-7.1.3.md @@ -73,7 +73,7 @@ TiDB バージョン: 7.1.3 - パーティション列タイプが`DATETIME` の場合に`ALTER TABLE ... LAST PARTITION`実行が失敗する問題を修正しました [＃48814](https://github.com/pingcap/tidb/issues/48814) @ [crazycs520](https://github.com/crazycs520) - `IMPORT INTO`実行中に実際のエラーメッセージが他のエラーメッセージによって上書きされる可能性がある問題を修正[＃47992](https://github.com/pingcap/tidb/issues/47992) [＃47781](https://github.com/pingcap/tidb/issues/47781) @ [D3Hunter](https://github.com/D3Hunter) - cgroup v2コンテナにデプロイされたTiDBが検出できない問題を修正[＃48342](https://github.com/pingcap/tidb/issues/48342) @ [D3Hunter](https://github.com/D3Hunter) - - DUALテーブルを最初のサブノードとして`UNION ALL`実行するとエラーが発生する可能性がある問題を修正しました。 [＃48755](https://github.com/pingcap/tidb/issues/48755) @ [winoros](https://github.com/winoros) + - DUALテーブルを最初のサブノードとして`UNION ALL`を実行するとエラーが発生する可能性がある問題を修正しました。 [＃48755](https://github.com/pingcap/tidb/issues/48755) @ [winoros](https://github.com/winoros) - DDL `jobID` 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) - `TABLESAMPLE` によって返されるソートされていない行データの問題を修正しました [＃48253](https://github.com/pingcap/tidb/issues/48253) @ [tangenta](https://github.com/tangenta) - `tidb_enable_ordered_result_mode`有効になっているときにpanicが発生する可能性がある問題を修正[＃45044](https://github.com/pingcap/tidb/issues/45044) @ [qw4990](https://github.com/qw4990) diff --git a/releases/release-7.1.4.md b/releases/release-7.1.4.md index c4fba3938468a..6ec5c7fc9ae4b 100644 --- a/releases/release-7.1.4.md +++ b/releases/release-7.1.4.md @@ -88,13 +88,13 @@ TiDBバージョン: 7.1.4 - 集計関数をグループ計算に使用すると発生する可能性のある`Can't find column ...`エラーを修正[＃50926](https://github.com/pingcap/tidb/issues/50926) @ [qw4990](https://github.com/qw4990) - 定数伝播で`ENUM`または`SET`型を処理するときに TiDB が間違ったクエリ結果を返す問題を修正しました [＃49440](https://github.com/pingcap/tidb/issues/49440) @ [winoros](https://github.com/winoros) - 依存関係のある 2 つの DDL タスクの完了時間がと誤って順序付けられる問題を修正しました。 [＃49498](https://github.com/pingcap/tidb/issues/49498) @ [tangenta](https://github.com/tangenta) - - `tidb_enable_prepared_plan_cache`システム変数が有効になってから無効になった後に`EXECUTE`ステートメントを使用して`PREPARE STMT`実行すると、TiDB がpanicになる可能性がある問題を修正しました[＃49344](https://github.com/pingcap/tidb/issues/49344) @ [qw4990](https://github.com/qw4990) + - `tidb_enable_prepared_plan_cache`システム変数が有効になってから無効になった後に`EXECUTE`ステートメントを使用して`PREPARE STMT`を実行すると、TiDB がpanicになる可能性がある問題を修正しました[＃49344](https://github.com/pingcap/tidb/issues/49344) @ [qw4990](https://github.com/qw4990) - ネストされた`UNION`のクエリで`LIMIT`と`OPRDERBY`無効になる可能性がある問題を修正しました [＃49377](https://github.com/pingcap/tidb/issues/49377) @ [AilinKid](https://github.com/AilinKid) - `LEADING`ヒントが`UNION ALL`ステートメントで有効にならない問題を修正しました [＃50067](https://github.com/pingcap/tidb/issues/50067) @ [hawkingrei](https://github.com/hawkingrei) - `COM_STMT_EXECUTE`まで実行された`COMMIT`または`ROLLBACK`操作が、タイムアウトしたトランザクションをで終了できない問題を修正しました。 [＃49151](https://github.com/pingcap/tidb/issues/49151) @ [zyguan](https://github.com/zyguan) - 無効なオプティマイザヒントによって有効なヒントが無効になる可能性がある問題を修正[＃49308](https://github.com/pingcap/tidb/issues/49308) @ [hawkingrei](https://github.com/hawkingrei) - 一部のタイムゾーンで夏時間が正しく表示されない問題を修正 [＃49586](https://github.com/pingcap/tidb/issues/49586) @ [overvenus](https://github.com/overvenus) - - `PREPARE`メソッドを使用して`SELECT INTO OUTFILE`実行すると、エラーではなく、誤って成功メッセージが返される問題を修正しました。 [＃49166](https://github.com/pingcap/tidb/issues/49166) @ [qw4990](https://github.com/qw4990) + - `PREPARE`メソッドを使用して`SELECT INTO OUTFILE`を実行すると、エラーではなく、誤って成功メッセージが返される問題を修正しました。 [＃49166](https://github.com/pingcap/tidb/issues/49166) @ [qw4990](https://github.com/qw4990) - PD との相互作用の問題により、 `tiup cluster upgrade/start`を使用してローリング アップグレードを実行すると TiDB がpanicになる可能性がある問題を修正しました。 [＃50152](https://github.com/pingcap/tidb/issues/50152) @ [zimulala](https://github.com/zimulala) - 空のテーブルにインデックスを追加したときに期待される最適化が有効にならない問題を修正しました [＃49682](https://github.com/pingcap/tidb/issues/49682) @ [zimulala](https://github.com/zimulala) - 多数のテーブルまたはパーティションが作成された場合に TiDB が OOM になる可能性がある問題を修正[＃50077](https://github.com/pingcap/tidb/issues/50077) @ [zimulala](https://github.com/zimulala) @@ -148,7 +148,7 @@ TiDBバージョン: 7.1.4 - `lowerUTF8`と`upperUTF8`関数で、大文字と小文字が異なるバイトを占めることができない問題を修正しました。 [＃8484](https://github.com/pingcap/tiflash/issues/8484) @ [gengliqi](https://github.com/gengliqi) - 短いクエリが正常に実行され、過剰な情報ログが出力される問題を修正しました。 [＃8592](https://github.com/pingcap/tiflash/issues/8592) @ [windtalker](https://github.com/windtalker) - クエリの低速化によりメモリ使用量が大幅に増加する問題を修正 [＃8564](https://github.com/pingcap/tiflash/issues/8564) @ [JinheLin](https://github.com/JinheLin) - - `ALTER TABLE ... MODIFY COLUMN ... NOT NULL`実行した後にTiFlash がパニックを起こし、null 許容列がに非 null 許容に変更される問題を修正しました。 [＃8419](https://github.com/pingcap/tiflash/issues/8419) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - `ALTER TABLE ... MODIFY COLUMN ... NOT NULL`を実行した後にTiFlash がパニックを起こし、null 許容列がに非 null 許容に変更される問題を修正しました。 [＃8419](https://github.com/pingcap/tiflash/issues/8419) @ [JaySon-Huang](https://github.com/JaySon-Huang) - クエリを終了した後、 TiFlash上の多数のタスクが同時にキャンセルされると、同時データの競合によりTiFlash がクラッシュする問題を修正[＃7432](https://github.com/pingcap/tiflash/issues/7432) @ [SeaRise](https://github.com/SeaRise) - リモート読み取り中にTiFlashがクラッシュする可能性がある問題を修正 [＃8685](https://github.com/pingcap/tiflash/issues/8685) @ [zanmato1984](https://github.com/zanmato1984) - 結合に非等価条件が含まれている場合に、 TiFlash Anti Semi Join が誤った結果を返す可能性がある問題を修正しました。 [＃8791](https://github.com/pingcap/tiflash/issues/8791) @ [windtalker](https://github.com/windtalker) diff --git a/releases/release-7.1.5.md b/releases/release-7.1.5.md index 7deeb89890036..7b1cd12ecf9fd 100644 --- a/releases/release-7.1.5.md +++ b/releases/release-7.1.5.md @@ -62,7 +62,7 @@ TiDB バージョン: 7.1.5 - TTL 機能により、データ範囲の分割が不正確になり、場合によってはでデータ ホットスポットが発生する問題を修正しました。 [＃51527](https://github.com/pingcap/tidb/issues/51527) @ [lcwangchao](https://github.com/lcwangchao) - TiDBがオフラインになっているTiFlashノードにプローブ要求を送信し続ける問題を修正[＃46602](https://github.com/pingcap/tidb/issues/46602) @ [zyguan](https://github.com/zyguan) - AutoIDLeaderの変更により、 `AUTO_ID_CACHE=1` の場合にAUTO_INCREMENT列の値が減少する可能性がある問題を修正しました。 [＃52600](https://github.com/pingcap/tidb/issues/52600) @ [tiancaiamao](https://github.com/tiancaiamao) - - `INSERT IGNORE`実行すると、一意インデックスとデータの間に不整合が発生する可能性がある問題を修正しました。 [＃51784](https://github.com/pingcap/tidb/issues/51784) @ [wjhuang2016](https://github.com/wjhuang2016) + - `INSERT IGNORE`を実行すると、一意インデックスとデータの間に不整合が発生する可能性がある問題を修正しました。 [＃51784](https://github.com/pingcap/tidb/issues/51784) @ [wjhuang2016](https://github.com/wjhuang2016) - 一意インデックスを追加するとTiDBがpanic可能性がある問題を修正[＃52312](https://github.com/pingcap/tidb/issues/52312) @ [wjhuang2016](https://github.com/wjhuang2016) - 関連するサブクエリがある場合にウィンドウ関数がpanic可能性がある問題を修正[＃42734](https://github.com/pingcap/tidb/issues/42734) @ [Rustin170506](https://github.com/Rustin170506) - `init-stats`プロセスが TiDB をpanicに陥らせ、 `load stats`プロセスが終了する可能性がある問題を修正しました。 [＃51581](https://github.com/pingcap/tidb/issues/51581) @ [hawkingrei](https://github.com/hawkingrei) diff --git a/releases/release-7.1.6.md b/releases/release-7.1.6.md index 569d2fffa9dbd..d3d671f24f4bd 100644 --- a/releases/release-7.1.6.md +++ b/releases/release-7.1.6.md @@ -77,7 +77,7 @@ TiDB バージョン: 7.1.6 - `YEAR`型の列を範囲外の符号なし整数と比較すると誤った結果が発生する問題を修正[＃50235](https://github.com/pingcap/tidb/issues/50235) @ [qw4990](https://github.com/qw4990) - SQLが異常に中断されたときに`INDEX_HASH_JOIN`正常に終了できない問題を修正[＃54688](https://github.com/pingcap/tidb/issues/54688) @ [wshwsh12](https://github.com/wshwsh12) - 分散実行フレームワーク (DXF) を使用してインデックスを追加する際のネットワーク パーティションによって、データ インデックスの不整合が発生する可能性がある問題を修正しました。 [＃54897](https://github.com/pingcap/tidb/issues/54897) @ [tangenta](https://github.com/tangenta) - - `SHOW WARNINGS;`使用して警告を取得するとpanicが発生する可能性がある問題を修正しました [＃48756](https://github.com/pingcap/tidb/issues/48756) @ [xhebox](https://github.com/xhebox) + - `SHOW WARNINGS;`を使用して警告を取得するとpanicが発生する可能性がある問題を修正しました [＃48756](https://github.com/pingcap/tidb/issues/48756) @ [xhebox](https://github.com/xhebox) - `INFORMATION_SCHEMA.CLUSTER_SLOW_QUERY`テーブルをクエリすると TiDB がpanicを起こす可能性がある問題を修正[＃54324](https://github.com/pingcap/tidb/issues/54324) @ [tiancaiamao](https://github.com/tiancaiamao) - `HashJoin`または`IndexLookUp`演算子が`Apply`演算子の駆動側サブノードである場合に`memTracker`切り離されないことで発生する異常に高いメモリ使用量の問題を修正しました。 [＃54005](https://github.com/pingcap/tidb/issues/54005) @ [XuHuaiyu](https://github.com/XuHuaiyu) - 再帰CTEクエリが無効なポインタを生成する可能性がある問題を修正しました [＃54449](https://github.com/pingcap/tidb/issues/54449) @ [hawkingrei](https://github.com/hawkingrei) @@ -123,7 +123,7 @@ TiDB バージョン: 7.1.6 - `auth_socket`認証プラグインを使用しているときに、TiDB が認証されていないユーザーの接続を拒否できないことがある問題を修正しました。 [＃54031](https://github.com/pingcap/tidb/issues/54031) @ [lcwangchao](https://github.com/lcwangchao) - `memory_quota`ヒントがサブクエリで機能しない可能性がある問題を修正しました [＃53834](https://github.com/pingcap/tidb/issues/53834) @ [qw4990](https://github.com/qw4990) - プランキャッシュシナリオでメタデータロックがDDL操作の実行を阻止できない問題を修正 [＃51407](https://github.com/pingcap/tidb/issues/51407) @ [wjhuang2016](https://github.com/wjhuang2016) - - 列のデフォルト値として`CURRENT_DATE()`使用すると、クエリ結果が正しくなくなる問題を修正しました [＃53746](https://github.com/pingcap/tidb/issues/53746) @ [tangenta](https://github.com/tangenta) + - 列のデフォルト値として`CURRENT_DATE()`を使用すると、クエリ結果が正しくなくなる問題を修正しました [＃53746](https://github.com/pingcap/tidb/issues/53746) @ [tangenta](https://github.com/tangenta) - `COALESCE()`関数が`DATE`の型パラメータに対して誤った結果型を返す問題を修正しました [＃46475](https://github.com/pingcap/tidb/issues/46475) @ [xzhangxian1008](https://github.com/xzhangxian1008) - `PipelinedWindow`の`Open`メソッドのパラメータをリセットして、 `PipelinedWindow`が`Apply`の子ノードとして使用されたときに発生する予期しないエラーを修正します。これはの繰り返し操作による以前のパラメータ値の再利用が原因です。 [＃53600](https://github.com/pingcap/tidb/issues/53600) @ [XuHuaiyu](https://github.com/XuHuaiyu) - 相関サブクエリにおける TopN 演算子の誤った結果を修正 [＃52777](https://github.com/pingcap/tidb/issues/52777) @ [yibin87](https://github.com/yibin87) @@ -156,7 +156,7 @@ TiDB バージョン: 7.1.6 - インデックス追加中の再試行によって発生するデータ インデックスの不整合の問題を修正しました [＃55808](https://github.com/pingcap/tidb/issues/55808) @ [lance6716](https://github.com/lance6716) - 列の不安定な一意のIDにより、 `UPDATE`文がエラーを返す可能性がある問題を修正しました。 [＃53236](https://github.com/pingcap/tidb/issues/53236) @ [winoros](https://github.com/winoros) - トランザクション内のステートメントが OOM によって強制終了された後、TiDB が同じトランザクション内で次のステートメントの実行を継続すると、エラー`Trying to start aggressive locking while it's already started`が発生し、panicが発生する可能性がある問題を修正しました。 [＃53540](https://github.com/pingcap/tidb/issues/53540) @ [MyonKeminta](https://github.com/MyonKeminta) - - `RECOVER TABLE BY JOB JOB_ID;`実行すると TiDB がpanicを起こす可能性がある問題を修正[＃55113](https://github.com/pingcap/tidb/issues/55113) @ [crazycs520](https://github.com/crazycs520) + - `RECOVER TABLE BY JOB JOB_ID;`を実行すると TiDB がpanicを起こす可能性がある問題を修正[＃55113](https://github.com/pingcap/tidb/issues/55113) @ [crazycs520](https://github.com/crazycs520) - 分散実行フレームワークの PD メンバーを変更した後に`ADD INDEX`実行が失敗する可能性がある問題を修正しました [＃48680](https://github.com/pingcap/tidb/issues/48680) @ [lance6716](https://github.com/lance6716) - 2人のDDL所有者が同時に存在する可能性がある問題を修正[＃54689](https://github.com/pingcap/tidb/issues/54689) @ [joccau](https://github.com/joccau) - `ADD INDEX`の実行中に TiDB のローリング再起動が発生すると、インデックスの追加操作が失敗する可能性がある問題を修正しました[＃52805](https://github.com/pingcap/tidb/issues/52805) @ [tangenta](https://github.com/tangenta) @@ -246,7 +246,7 @@ TiDB バージョン: 7.1.6 - 空のキー範囲を持つクエリがTiFlash上で読み取りタスクを正しく生成できず、 TiFlashクエリがブロックされる可能性がある問題を修正しました。 [＃9108](https://github.com/pingcap/tiflash/issues/9108) @ [JinheLin](https://github.com/JinheLin) - 特定のケースで関数`CAST AS DECIMAL`の結果の符号が正しくない問題を修正[＃9301](https://github.com/pingcap/tiflash/issues/9301) @ [guo-shaoge](https://github.com/guo-shaoge) - `SUBSTRING()`関数が特定の整数型に対して`pos`と`len`引数をサポートせず、クエリエラーが発生する問題を修正しました [＃9473](https://github.com/pingcap/tiflash/issues/9473) @ [gengliqi](https://github.com/gengliqi) - - 大きなテーブルで`DROP TABLE`実行するとTiFlash OOM が発生する可能性がある問題を修正しました [＃9437](https://github.com/pingcap/tiflash/issues/9437) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - 大きなテーブルで`DROP TABLE`を実行するとTiFlash OOM が発生する可能性がある問題を修正しました [＃9437](https://github.com/pingcap/tiflash/issues/9437) @ [JaySon-Huang](https://github.com/JaySon-Huang) - ツール diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index 3154eec22c2fc..01b7a3c5419fa 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -87,7 +87,7 @@ TiDB バージョン: 7.4.0 通常、TiKVはリクエストを数ミリ秒という非常に高速に処理します。しかし、TiKVノードがディスクI/Oジッターやネットワークレイテンシーに遭遇すると、リクエスト処理時間が大幅に増加する可能性があります。v7.4.0より前のバージョンでは、TiKVリクエストのタイムアウト制限は固定されており、調整できません。そのため、TiKVノードで問題が発生すると、TiDBは一定時間のタイムアウト応答を待機する必要があり、ジッター発生時のアプリケーションクエリパフォーマンスに顕著な影響が生じます。 - TiDB v7.4.0 では、新しいシステム変数[`tikv_client_read_timeout`](/system-variables.md#tikv_client_read_timeout-new-in-v740)が導入され、クエリで TiDB が TiKV に送信する RPC 読み取り要求のタイムアウトをカスタマイズできるようになりました。つまり、ディスクまたはネットワークの問題により TiKV ノードに送信された要求が遅延した場合、TiDB はより早くタイムアウトし、他の TiKV ノードに要求を再送信できるため、クエリのレイテンシーが短縮されます。すべての TiKV ノードでタイムアウトが発生した場合、TiDB はデフォルトのタイムアウトを使用して再試行します。さらに、クエリでオプティマイザヒント`/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */`使用して、TiDB が TiKV RPC 読み取り要求を送信するタイムアウトを設定することもできます。この機能強化により、不安定なネットワークやstorage環境に TiDB が柔軟に適応できるようになり、クエリのパフォーマンスが向上し、ユーザーエクスペリエンスが強化されます。 + TiDB v7.4.0 では、新しいシステム変数[`tikv_client_read_timeout`](/system-variables.md#tikv_client_read_timeout-new-in-v740)が導入され、クエリで TiDB が TiKV に送信する RPC 読み取り要求のタイムアウトをカスタマイズできるようになりました。つまり、ディスクまたはネットワークの問題により TiKV ノードに送信された要求が遅延した場合、TiDB はより早くタイムアウトし、他の TiKV ノードに要求を再送信できるため、クエリのレイテンシーが短縮されます。すべての TiKV ノードでタイムアウトが発生した場合、TiDB はデフォルトのタイムアウトを使用して再試行します。さらに、クエリでオプティマイザヒント`/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */`を使用して、TiDB が TiKV RPC 読み取り要求を送信するタイムアウトを設定することもできます。この機能強化により、不安定なネットワークやstorage環境に TiDB が柔軟に適応できるようになり、クエリのパフォーマンスが向上し、ユーザーエクスペリエンスが強化されます。 詳細については[ドキュメント](/system-variables.md#tikv_client_read_timeout-new-in-v740)参照してください。 @@ -211,7 +211,7 @@ TiDB バージョン: 7.4.0 - Dumplingは、データをCSVファイルにエクスポートする際に、ユーザー定義のターミネータをサポートします[＃46982](https://github.com/pingcap/tidb/issues/46982) @ [GMHDBJD](https://github.com/GMHDBJD) - バージョン7.4.0より前のDumplingでは、データをCSVファイルにエクスポートする際に、行末文字として`"\r\n"`使用します。そのため、行末文字として`"\n"`しか認識しない下流システムでは、エクスポートされたCSVファイルを解析できないか、解析前にサードパーティ製の変換ツールを使用する必要があります。 + バージョン7.4.0より前のDumplingでは、データをCSVファイルにエクスポートする際に、行末文字として`"\r\n"`を使用します。そのため、行末文字として`"\n"`しか認識しない下流システムでは、エクスポートされたCSVファイルを解析できないか、解析前にサードパーティ製の変換ツールを使用する必要があります。 バージョン7.4.0以降、 Dumplingに新しいパラメータ`--csv-line-terminator`が導入されました。このパラメータを使用すると、データをCSVファイルにエクスポートする際に、任意の終端文字を指定できます。このパラメータは`"\r\n"`と`"\n"`サポートしています。以前のバージョンとの一貫性を保つため、デフォルトの終端文字は`"\r\n"`です。 diff --git a/releases/release-7.5.1.md b/releases/release-7.5.1.md index b7a8d90122b91..c6577c27a3a04 100644 --- a/releases/release-7.5.1.md +++ b/releases/release-7.5.1.md @@ -25,7 +25,7 @@ TiDB バージョン: 7.5.1 - TiDB - - DDLスキーマの再ロードプロセス中に`tikv_client_read_timeout`使用して、クラスタでのメタリージョンLeaderの読み取り不可の影響を軽減します。 [＃48124](https://github.com/pingcap/tidb/issues/48124) @ [cfzjywxk](https://github.com/cfzjywxk) + - DDLスキーマの再ロードプロセス中に`tikv_client_read_timeout`を使用して、クラスタでのメタリージョンLeaderの読み取り不可の影響を軽減します。 [＃48124](https://github.com/pingcap/tidb/issues/48124) @ [cfzjywxk](https://github.com/cfzjywxk) - リソース制御に関する可観測性を強化する[＃49318](https://github.com/pingcap/tidb/issues/49318) @ [glorv](https://github.com/glorv) @ [bufferflies](https://github.com/bufferflies) @ [nolouch](https://github.com/nolouch) @@ -102,7 +102,7 @@ TiDB バージョン: 7.5.1 - `INFORMATION_SCHEMA.ANALYZE_STATUS`システムテーブルをクエリするときにユーザーがエラーを受け取る可能性がある問題を修正しました [＃48835](https://github.com/pingcap/tidb/issues/48835) @ [Rustin170506](https://github.com/Rustin170506) - TiDB が`group by` の定数値を誤って削除することによる間違ったクエリ結果の問題を修正しました [＃38756](https://github.com/pingcap/tidb/issues/38756) @ [Rustin170506](https://github.com/Rustin170506) - テーブル上の`ANALYZE`タスクのうち`processed_rows`が、そのテーブルの合計行数を超える可能性がある問題を修正しました。 [＃50632](https://github.com/pingcap/tidb/issues/50632) @ [hawkingrei](https://github.com/hawkingrei) - - `tidb_enable_prepared_plan_cache`システム変数が有効になってから無効になった後に`EXECUTE`ステートメントを使用して`PREPARE STMT`実行すると、TiDB がpanicになる可能性がある問題を修正しました[＃49344](https://github.com/pingcap/tidb/issues/49344) @ [qw4990](https://github.com/qw4990) + - `tidb_enable_prepared_plan_cache`システム変数が有効になってから無効になった後に`EXECUTE`ステートメントを使用して`PREPARE STMT`を実行すると、TiDB がpanicになる可能性がある問題を修正しました[＃49344](https://github.com/pingcap/tidb/issues/49344) @ [qw4990](https://github.com/qw4990) - クエリで`NATURAL JOIN` が使用される場合に発生する可能性のある`Column ... in from clause is ambiguous`エラーを修正します [＃32044](https://github.com/pingcap/tidb/issues/32044) @ [AilinKid](https://github.com/AilinKid) - 多値インデックスを使用して空の JSON 配列にアクセスすると、誤った結果が返される可能性がある問題を修正しました[＃50125](https://github.com/pingcap/tidb/issues/50125) @ [YangKeao](https://github.com/YangKeao) - 集計関数をグループ計算に使用すると発生する可能性のある`Can't find column ...`エラーを修正[＃50926](https://github.com/pingcap/tidb/issues/50926) @ [qw4990](https://github.com/qw4990) @@ -124,7 +124,7 @@ TiDB バージョン: 7.5.1 - MPPで計算された`COUNT(INT)`の結果が正しくない可能性がある問題を修正[＃48643](https://github.com/pingcap/tidb/issues/48643) @ [AilinKid](https://github.com/AilinKid) - `ENUM`または`SET`種類の無効な値を解析すると、SQL ステートメント エラーが直接発生する問題を修正しました。 [＃49487](https://github.com/pingcap/tidb/issues/49487) @ [winoros](https://github.com/winoros) - TiDBがパニックを起こしてエラーを報告する問題を修正`invalid memory address or nil pointer dereference` [＃42739](https://github.com/pingcap/tidb/issues/42739) @ [CbcWestwolf](https://github.com/CbcWestwolf) - - 最初のサブノードとしてDUALテーブルを使用して`UNION ALL`実行すると、エラーが発生する可能性がある問題を修正しました。 [＃48755](https://github.com/pingcap/tidb/issues/48755) @ [winoros](https://github.com/winoros) + - 最初のサブノードとしてDUALテーブルを使用して`UNION ALL`を実行すると、エラーが発生する可能性がある問題を修正しました。 [＃48755](https://github.com/pingcap/tidb/issues/48755) @ [winoros](https://github.com/winoros) - 共通ヒントが`UNION ALL`文で有効にならない問題を修正 [＃50068](https://github.com/pingcap/tidb/issues/50068) @ [hawkingrei](https://github.com/hawkingrei) - 正常なシャットダウン中に TiDBサーバーがpanic可能性がある問題を修正[＃36793](https://github.com/pingcap/tidb/issues/36793) @ [bb7133](https://github.com/bb7133) - 一部のタイムゾーンで夏時間が正しく表示されない問題を修正 [＃49586](https://github.com/pingcap/tidb/issues/49586) @ [overvenus](https://github.com/overvenus) @@ -138,7 +138,7 @@ TiDB バージョン: 7.5.1 - `COM_STMT_EXECUTE`まで実行された`COMMIT`または`ROLLBACK`操作が、タイムアウトしたトランザクションをで終了できない問題を修正しました。 [＃49151](https://github.com/pingcap/tidb/issues/49151) @ [zyguan](https://github.com/zyguan) - ヒストグラムの境界に`NULL` が含まれている場合、ヒストグラム統計が読み取り可能な文字列に解析されない可能性がある問題を修正しました。 [＃49823](https://github.com/pingcap/tidb/issues/49823) @ [AilinKid](https://github.com/AilinKid) - 共通テーブル式 (CTE) を含むクエリがメモリ制限を超えたときに予期せず停止する問題を修正[＃49096](https://github.com/pingcap/tidb/issues/49096) @ [AilinKid](https://github.com/AilinKid) - - DDL所有者がネットワークから分離されているの後に`ADD INDEX`実行すると、TiDB分散実行フレームワーク（DXF）でデータが不整合になる問題を修正しました [＃49773](https://github.com/pingcap/tidb/issues/49773) @ [tangenta](https://github.com/tangenta) + - DDL所有者がネットワークから分離されているの後に`ADD INDEX`を実行すると、TiDB分散実行フレームワーク（DXF）でデータが不整合になる問題を修正しました [＃49773](https://github.com/pingcap/tidb/issues/49773) @ [tangenta](https://github.com/tangenta) - `AUTO_ID_CACHE=1` のAUTO_INCREMENT列を使用すると同時競合によりAUTO_INCREMENT ID 割り当てでエラーが報告される問題を修正しました。 [＃50519](https://github.com/pingcap/tidb/issues/50519) @ [tiancaiamao](https://github.com/tiancaiamao) - クエリに Apply 演算子が含まれており、 `fatal error: concurrent map writes`エラーが発生すると TiDB がpanicになる可能性がある問題を修正しました。 [＃50347](https://github.com/pingcap/tidb/issues/50347) @ [SeaRise](https://github.com/SeaRise) - DDL `jobID` 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) @@ -148,12 +148,12 @@ TiDB バージョン: 7.5.1 - ネストされた`UNION`のクエリで`LIMIT`と`OPRDERBY`無効になる可能性がある問題を修正しました [＃49377](https://github.com/pingcap/tidb/issues/49377) @ [AilinKid](https://github.com/AilinKid) - メモリが`tidb_mem_quota_query` を超えると IndexHashJoin 演算子を含むクエリが停止する問題を修正しました [＃49033](https://github.com/pingcap/tidb/issues/49033) @ [XuHuaiyu](https://github.com/XuHuaiyu) - 定数伝播で`ENUM`または`SET`型を処理するときに TiDB が間違ったクエリ結果を返す問題を修正しました [＃49440](https://github.com/pingcap/tidb/issues/49440) @ [winoros](https://github.com/winoros) - - `PREPARE`メソッドを使用して`SELECT INTO OUTFILE`実行すると、エラーではなく、誤って成功メッセージが返される問題を修正しました。 [＃49166](https://github.com/pingcap/tidb/issues/49166) @ [qw4990](https://github.com/qw4990) + - `PREPARE`メソッドを使用して`SELECT INTO OUTFILE`を実行すると、エラーではなく、誤って成功メッセージが返される問題を修正しました。 [＃49166](https://github.com/pingcap/tidb/issues/49166) @ [qw4990](https://github.com/qw4990) - クエリがソートを強制するオプティマイザヒント（ `STREAM_AGG()`など）を使用し、その実行プランに`IndexMerge` が含まれている場合、強制ソートが無効になる可能性がある問題を修正しました。 [＃49605](https://github.com/pingcap/tidb/issues/49605) @ [AilinKid](https://github.com/AilinKid) - テーブルがと多数ある場合に、テーブルが`AUTO_ID_CACHE=1`の場合に gRPC クライアント リークが発生する可能性がある問題を修正しました。 [＃48869](https://github.com/pingcap/tidb/issues/48869) @ [tiancaiamao](https://github.com/tiancaiamao) - 非厳密モード（ `sql_mode = ''` ）で、 `INSERT`実行中に切り捨てが行われても、エラーが報告される問題を修正しました。 [＃49369](https://github.com/pingcap/tidb/issues/49369) @[tiancaiamao](https://github.com/tiancaiamao) - データの末尾にスペースが含まれている場合に`LIKE`で`_`ワイルドカードを使用すると、誤ったクエリ結果が返される可能性がある問題を修正しました [＃48983](https://github.com/pingcap/tidb/issues/48983) @ [time-and-fate](https://github.com/time-and-fate) - - `tidb_mem_quota_query`システム変数を更新した後に`ADMIN CHECK`実行すると`ERROR 8175` が返される問題を修正しました [＃49258](https://github.com/pingcap/tidb/issues/49258) @ [tangenta](https://github.com/tangenta) + - `tidb_mem_quota_query`システム変数を更新した後に`ADMIN CHECK`を実行すると`ERROR 8175` が返される問題を修正しました [＃49258](https://github.com/pingcap/tidb/issues/49258) @ [tangenta](https://github.com/tangenta) - Golang の暗黙的な変換アルゴリズムによって発生する統計情報の構築における過剰な統計エラーの問題を修正しました [＃49801](https://github.com/pingcap/tidb/issues/49801) @ [qw4990](https://github.com/qw4990) - CTE を含むクエリが、 `tidb_max_chunk_size`小さい値に設定されている場合に`runtime error: index out of range [32] with length 32`報告する問題を修正しました。 [＃48808](https://github.com/pingcap/tidb/issues/48808) @ [guo-shaoge](https://github.com/guo-shaoge) @@ -198,12 +198,12 @@ TiDB バージョン: 7.5.1 - ストリーム読み取り中に複数のパーティション テーブルをスキャンするときに発生する可能性のある OOM 問題を修正しました。 [＃8505](https://github.com/pingcap/tiflash/issues/8505) @ [gengliqi](https://github.com/gengliqi) - クエリ中にTiFlash がメモリ制限に遭遇した場合のメモリリークの問題を修正しました [＃8447](https://github.com/pingcap/tiflash/issues/8447) @ [JinheLin](https://github.com/JinheLin) - TiFlash が同時 DDL 実行中に競合に遭遇した場合のTiFlash panic問題を修正[＃8578](https://github.com/pingcap/tiflash/issues/8578) @ [JaySon-Huang](https://github.com/JaySon-Huang) - - `ALTER TABLE ... MODIFY COLUMN ... NOT NULL`実行した後にTiFlash がパニックを起こし、null 許容列がに非 null 許容に変更される問題を修正しました。 [＃8419](https://github.com/pingcap/tiflash/issues/8419) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - `ALTER TABLE ... MODIFY COLUMN ... NOT NULL`を実行した後にTiFlash がパニックを起こし、null 許容列がに非 null 許容に変更される問題を修正しました。 [＃8419](https://github.com/pingcap/tiflash/issues/8419) @ [JaySon-Huang](https://github.com/JaySon-Huang) - `ColumnRef in (Literal, Func...)` のようなフィルタリング条件でクエリを実行したときにクエリ結果が正しくない問題を修正しました [＃8631](https://github.com/pingcap/tiflash/issues/8631) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - `FLASHBACK DATABASE` を実行した後もTiFlashレプリカのデータがガベージコレクションされる問題を修正しました [＃8450](https://github.com/pingcap/tiflash/issues/8450) @ [JaySon-Huang](https://github.com/JaySon-Huang) - 分散ストレージおよびコンピューティングアーキテクチャで、 TiFlash がオブジェクトストレージデータの GC 所有者を選択できない可能性がある問題を修正しました。 [＃8519](https://github.com/pingcap/tiflash/issues/8519) @ [JaySon-Huang](https://github.com/JaySon-Huang) - 定数文字列パラメータを含む`GREATEST`または`LEAST`関数で発生する可能性のある、ランダムに無効なメモリアクセスの問題を修正しました。 [＃8604](https://github.com/pingcap/tiflash/issues/8604) @ [windtalker](https://github.com/windtalker) - - ポイントインタイムリカバリ（PITR）を実行した後、または`FLASHBACK CLUSTER TO`実行した後にTiFlashレプリカデータが誤って削除され、データ異常が発生する可能性がある問題を修正しました。 [＃8777](https://github.com/pingcap/tiflash/issues/8777) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - ポイントインタイムリカバリ（PITR）を実行した後、または`FLASHBACK CLUSTER TO`を実行した後にTiFlashレプリカデータが誤って削除され、データ異常が発生する可能性がある問題を修正しました。 [＃8777](https://github.com/pingcap/tiflash/issues/8777) @ [JaySon-Huang](https://github.com/JaySon-Huang) - 結合に非等価条件が含まれている場合に、 TiFlash Anti Semi Join が誤った結果を返す可能性がある問題を修正しました。 [＃8791](https://github.com/pingcap/tiflash/issues/8791) @ [windtalker](https://github.com/windtalker) - ツール diff --git a/releases/release-7.5.2.md b/releases/release-7.5.2.md index 7d9bc518b7c0c..bf1bfa2653921 100644 --- a/releases/release-7.5.2.md +++ b/releases/release-7.5.2.md @@ -14,7 +14,7 @@ TiDB バージョン: 7.5.2 ## 互換性の変更 {#compatibility-changes} - RocksDB の TiKV 構成項目[`track-and-verify-wals-in-manifest`](https://docs.pingcap.com/tidb/v7.5/tikv-configuration-file#track-and-verify-wals-in-manifest-new-in-v659-v715-and-v752)追加します。これは、Write Ahead Log (WAL) の破損の可能性を調査するのに役立ちます。 [＃16549](https://github.com/tikv/tikv/issues/16549) @ [v01dstar](https://github.com/v01dstar) -- TiDB Lightning `strict-format`または`SPLIT_FILE`使用して CSV ファイルをインポートする場合は、行末文字を設定する必要があります[＃37338](https://github.com/pingcap/tidb/issues/37338) @ [lance6716](https://github.com/lance6716) +- TiDB Lightning `strict-format`または`SPLIT_FILE`を使用して CSV ファイルをインポートする場合は、行末文字を設定する必要があります[＃37338](https://github.com/pingcap/tidb/issues/37338) @ [lance6716](https://github.com/lance6716) - TiCDCオープンプロトコルの`sink.open.output-old-value`設定項目を追加して、更新前の値を下流に出力するかどうかを制御します。 [＃10916](https://github.com/pingcap/tiflow/issues/10916) @ [sdojjy](https://github.com/sdojjy) - 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`目のイベントで主キーまたは非NULLの一意インデックス値が変更されると、TiCDCはこのイベントを`DELETE`目と`INSERT`目のイベントに分割していました。v7.5.2以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS` TiCDC `thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`目のイベントを`DELETE` `INSERT`と13件目のイベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`目のイベントの順序が誤っている可能性があり、分割された`DELETE`と`INSERT`目のイベントの順序が誤っている可能性があるため、ダウンストリームデータの不整合が発生する問題に対処しています。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v7.5/ticdc-split-update-behavior#split-update-events-for-mysql-sinks) してください@ [lidezhu](https://github.com/lidezhu) [＃10918](https://github.com/pingcap/tiflow/issues/10918) @@ -127,7 +127,7 @@ TiDB バージョン: 7.5.2 - 照合の新しいフレームワークが無効になっているときに、異なる照合を含む式によってクエリがpanicになる可能性がある問題を修正しました[＃52772](https://github.com/pingcap/tidb/issues/52772) @ [wjhuang2016](https://github.com/wjhuang2016) - 複数値インデックスを持つテーブルを含むSQL文を実行すると、 `Can't find a proper physical plan for this query`エラーが返される可能性がある問題を修正しました。 [＃49438](https://github.com/pingcap/tidb/issues/49438) @ [qw4990](https://github.com/qw4990) - TiDBが式内のシステム変数の型を正しく変換できない問題を修正 [＃43527](https://github.com/pingcap/tidb/issues/43527) @ [Rustin170506](https://github.com/Rustin170506) - - `INSERT IGNORE`実行すると、一意インデックスとデータの間に不整合が発生する可能性がある問題を修正しました。 [＃51784](https://github.com/pingcap/tidb/issues/51784) @ [wjhuang2016](https://github.com/wjhuang2016) + - `INSERT IGNORE`を実行すると、一意インデックスとデータの間に不整合が発生する可能性がある問題を修正しました。 [＃51784](https://github.com/pingcap/tidb/issues/51784) @ [wjhuang2016](https://github.com/wjhuang2016) - OOMエラー発生後に自動統計収集が停止する問題を修正[＃51993](https://github.com/pingcap/tidb/issues/51993) @ [Rustin170506](https://github.com/Rustin170506) - `tidb_mem_quota_analyze`が有効になっていて、統計の更新に使用されるメモリが制限を超えると TiDB がクラッシュする可能性がある問題を修正しました。 [＃52601](https://github.com/pingcap/tidb/issues/52601) @ [hawkingrei](https://github.com/hawkingrei) - 複数のレベルの`max_execute_time`設定が互いに干渉する問題を修正[＃50914](https://github.com/pingcap/tidb/issues/50914) @ [jiyfhust](https://github.com/jiyfhust) diff --git a/releases/release-7.5.3.md b/releases/release-7.5.3.md index bfa59c12e4523..f2ceee8f0108a 100644 --- a/releases/release-7.5.3.md +++ b/releases/release-7.5.3.md @@ -60,7 +60,7 @@ TiDB バージョン: 7.5.3 - `HashJoin`または`IndexLookUp`演算子が`Apply`演算子の駆動側サブノードである場合に`memTracker`切り離されないことで発生する異常に高いメモリ使用量の問題を修正しました。 [＃54005](https://github.com/pingcap/tidb/issues/54005) @ [XuHuaiyu](https://github.com/XuHuaiyu) - 再帰CTE演算子がメモリ使用量を誤って追跡する問題を修正しました [＃54181](https://github.com/pingcap/tidb/issues/54181) @ [guo-shaoge](https://github.com/guo-shaoge) - トランザクションで使用されるメモリが複数回追跡される可能性がある問題を修正[＃53984](https://github.com/pingcap/tidb/issues/53984) @ [ekexium](https://github.com/ekexium) - - `SHOW WARNINGS;`使用して警告を取得するとpanicが発生する可能性がある問題を修正しました [＃48756](https://github.com/pingcap/tidb/issues/48756) @ [xhebox](https://github.com/xhebox) + - `SHOW WARNINGS;`を使用して警告を取得するとpanicが発生する可能性がある問題を修正しました [＃48756](https://github.com/pingcap/tidb/issues/48756) @ [xhebox](https://github.com/xhebox) - `sql_mode=''` の場合に、フィールドの`UNSIGNED`型を`-1`に更新すると`0`ではなく`null`返される問題を修正しました。 [＃47816](https://github.com/pingcap/tidb/issues/47816) @ [lcwangchao](https://github.com/lcwangchao) - 最初の引数が`month`で、2番目の引数が負の場合に`TIMESTAMPADD()`関数が無限ループに入る問題を修正しました。 [＃54908](https://github.com/pingcap/tidb/issues/54908) @ [xzhangxian1008](https://github.com/xzhangxian1008) - ハンドシェイクが完了する前に一部の接続が終了した場合に、Grafana の接続数監視メトリックが正しくない問題を修正しました[＃54428](https://github.com/pingcap/tidb/issues/54428) @ [YangKeao](https://github.com/YangKeao) @@ -75,13 +75,13 @@ TiDB バージョン: 7.5.3 - 特定の状況下でプランキャッシュを使用する際に、メタデータロックの不適切な使用によって異常なデータが書き込まれる可能性がある問題を修正しました[＃53634](https://github.com/pingcap/tidb/issues/53634) @ [zimulala](https://github.com/zimulala) - クエリ内の特定のフィルター条件により、プランナーモジュールが`invalid memory address or nil pointer dereference`エラー[＃53582](https://github.com/pingcap/tidb/issues/53582) [＃53580](https://github.com/pingcap/tidb/issues/53580) を報告する可能性がある問題を修正しました [＃53603](https://github.com/pingcap/tidb/issues/53603) @ [YangKeao](https://github.com/YangKeao) [＃53594](https://github.com/pingcap/tidb/issues/53594) - トランザクション内のステートメントが OOM によって強制終了された後、TiDB が同じトランザクション内で次のステートメントの実行を継続すると、エラー`Trying to start aggressive locking while it's already started`が発生し、panicが発生する可能性がある問題を修正しました。 [＃53540](https://github.com/pingcap/tidb/issues/53540) @ [MyonKeminta](https://github.com/MyonKeminta) - - `ALTER TABLE ... REMOVE PARTITIONING`実行するとでデータが失われる可能性がある問題を修正 [＃53385](https://github.com/pingcap/tidb/issues/53385) @ [mjonss](https://github.com/mjonss) + - `ALTER TABLE ... REMOVE PARTITIONING`を実行するとでデータが失われる可能性がある問題を修正 [＃53385](https://github.com/pingcap/tidb/issues/53385) @ [mjonss](https://github.com/mjonss) - `?`の引数を含む`CONV`の式を持つ`PREPARE` `EXECUTE`ステートメントを複数回実行すると、誤ったクエリ結果が返される可能性がある問題を修正しました[＃53505](https://github.com/pingcap/tidb/issues/53505) @ [qw4990](https://github.com/qw4990) - `auth_socket`認証プラグインを使用しているときに、TiDB が認証されていないユーザーの接続を拒否できないことがある問題を修正しました。 [＃54031](https://github.com/pingcap/tidb/issues/54031) @ [lcwangchao](https://github.com/lcwangchao) - 情報スキーマキャッシュミスにより、古い読み取りのクエリレイテンシーが増加する問題を修正しました。 [＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520) - `STATE`フィールドのうち`size`が定義されていないため、 `INFORMATION_SCHEMA.TIDB_TRX`テーブルの`STATE`フィールドが空になる問題を修正しました[＃53026](https://github.com/pingcap/tidb/issues/53026) @ [cfzjywxk](https://github.com/cfzjywxk) - 自動統計収集中にシステム変数`tidb_enable_async_merge_global_stats`と`tidb_analyze_partition_concurrency`有効にならない問題を修正[＃53972](https://github.com/pingcap/tidb/issues/53972) @ [Rustin170506](https://github.com/Rustin170506) - - 列のデフォルト値として`CURRENT_DATE()`使用すると、クエリ結果が正しくなくなる問題を修正しました [＃53746](https://github.com/pingcap/tidb/issues/53746) @ [tangenta](https://github.com/tangenta) + - 列のデフォルト値として`CURRENT_DATE()`を使用すると、クエリ結果が正しくなくなる問題を修正しました [＃53746](https://github.com/pingcap/tidb/issues/53746) @ [tangenta](https://github.com/tangenta) - `SELECT ... FOR UPDATE` の間違ったPointGetプランを再利用する問題を修正しました [＃54652](https://github.com/pingcap/tidb/issues/54652) @ [qw4990](https://github.com/qw4990) - TiKV @@ -110,7 +110,7 @@ TiDB バージョン: 7.5.3 - TiFlashで SSL 証明書の構成を空の文字列に設定すると、誤って TLS が有効になり、 TiFlash が起動しなくなる問題を修正しました[＃9235](https://github.com/pingcap/tiflash/issues/9235) @ [JaySon-Huang](https://github.com/JaySon-Huang) - 遅延マテリアライゼーションが有効になった後に、一部のクエリで列タイプの不一致エラーが報告される可能性がある問題を修正[＃9175](https://github.com/pingcap/tiflash/issues/9175) @ [JinheLin](https://github.com/JinheLin) - 遅延マテリアライゼーションが有効になった後、仮想生成列を含むクエリが誤った結果を返す可能性がある問題を修正[＃9188](https://github.com/pingcap/tiflash/issues/9188) @ [JinheLin](https://github.com/JinheLin) - - データベースにまたがる空のパーティションを持つパーティションテーブルで`RENAME TABLE ... TO ...`実行した後にTiFlash がpanic可能性がある問題を修正しました。 [＃9132](https://github.com/pingcap/tiflash/issues/9132) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - データベースにまたがる空のパーティションを持つパーティションテーブルで`RENAME TABLE ... TO ...`を実行した後にTiFlash がpanic可能性がある問題を修正しました。 [＃9132](https://github.com/pingcap/tiflash/issues/9132) @ [JaySon-Huang](https://github.com/JaySon-Huang) - データベースが作成直後に削除されるとTiFlash がpanic可能性がある問題を修正[＃9266](https://github.com/pingcap/tiflash/issues/9266) @ [JaySon-Huang](https://github.com/JaySon-Huang) - ツール diff --git a/releases/release-7.5.5.md b/releases/release-7.5.5.md index 3fb9b44362135..3d6d023f1324e 100644 --- a/releases/release-7.5.5.md +++ b/releases/release-7.5.5.md @@ -62,7 +62,7 @@ TiDB バージョン: 7.5.5 - `ADD INDEX` を実行するときに TiDB がインデックスの長さ制限をチェックしない問題を修正しました [＃56930](https://github.com/pingcap/tidb/issues/56930) @ [fzzf678](https://github.com/fzzf678) - TTLタスクをキャンセルした際に、対応するSQLが強制終了されない問題を修正[＃56511](https://github.com/pingcap/tidb/issues/56511) @ [lcwangchao](https://github.com/lcwangchao) - エイリアスを持つマルチテーブル`DELETE`ステートメントに対して実行プラン バインディングを作成できない問題を修正しました。 [＃56726](https://github.com/pingcap/tidb/issues/56726) @ [hawkingrei](https://github.com/hawkingrei) - - `ANALYZE`使用してテーブルの統計情報を収集するときに、テーブルに仮想生成列の式インデックスが含まれていると、実行時にエラーが報告される問題を修正しました。 [＃57079](https://github.com/pingcap/tidb/issues/57079) @ [hawkingrei](https://github.com/hawkingrei) + - `ANALYZE`を使用してテーブルの統計情報を収集するときに、テーブルに仮想生成列の式インデックスが含まれていると、実行時にエラーが報告される問題を修正しました。 [＃57079](https://github.com/pingcap/tidb/issues/57079) @ [hawkingrei](https://github.com/hawkingrei) - 配置ルールを含むテーブル構造をインポートするときに Plan Replayer がエラーを報告する可能性がある問題を修正しました。 [＃54961](https://github.com/pingcap/tidb/issues/54961) @ [hawkingrei](https://github.com/hawkingrei) - CTE でデータベース名を解析するときに間違ったデータベース名が返される問題を修正しました [＃54582](https://github.com/pingcap/tidb/issues/54582) @ [hawkingrei](https://github.com/hawkingrei) - `INSERT ... ON DUPLICATE KEY`文が`mysql_insert_id` と互換性がない問題を修正 [＃55965](https://github.com/pingcap/tidb/issues/55965) @ [tiancaiamao](https://github.com/tiancaiamao) @@ -74,15 +74,15 @@ TiDB バージョン: 7.5.5 - 書き込み競合が発生したときにTTLタスクをキャンセルできない問題を修正[＃56422](https://github.com/pingcap/tidb/issues/56422) @ [YangKeao](https://github.com/YangKeao) - CTE に`ORDER BY` 、 `LIMIT` 、または`SELECT DISTINCT`句が含まれており、別の CTE の再帰部分によって参照されている場合、誤ってインライン化され、実行エラーが発生する可能性がある問題を修正しました。 [＃56603](https://github.com/pingcap/tidb/issues/56603) @ [elsa0520](https://github.com/elsa0520) - `UPDATE`文が`ENUM`型の値を誤って更新する問題を修正しました [＃56832](https://github.com/pingcap/tidb/issues/56832) @ [xhebox](https://github.com/xhebox) - - `RECOVER TABLE BY JOB JOB_ID;`実行すると TiDB がpanicを起こす可能性がある問題を修正[＃55113](https://github.com/pingcap/tidb/issues/55113) @ [crazycs520](https://github.com/crazycs520) + - `RECOVER TABLE BY JOB JOB_ID;`を実行すると TiDB がpanicを起こす可能性がある問題を修正[＃55113](https://github.com/pingcap/tidb/issues/55113) @ [crazycs520](https://github.com/crazycs520) - クエリに利用可能なインデックスマージ実行プランがある場合に`read_from_storage`ヒントが有効にならない可能性がある問題を修正しました [＃56217](https://github.com/pingcap/tidb/issues/56217) @ [AilinKid](https://github.com/AilinKid) - 異常終了時に`INDEX_HASH_JOIN`アップする可能性がある問題を修正[＃54055](https://github.com/pingcap/tidb/issues/54055) @ [wshwsh12](https://github.com/wshwsh12) - 分散実行フレームワーク (DXF) に関連するシステム テーブルをクエリすると、アップグレードが失敗する可能性がある問題を修正しました[＃49263](https://github.com/pingcap/tidb/issues/49263) @ [D3Hunter](https://github.com/D3Hunter) - DDL内部トランザクションエラー`GC life time is shorter than transaction duration`によりインデックス追加が失敗する問題を修正[＃57043](https://github.com/pingcap/tidb/issues/57043) @ [tangenta](https://github.com/tangenta) - - `EXCHANGE PARTITION`実行して無効な行に遭遇すると、InfoSchema が完全にロードされ、エラー`failed to load schema diff`が報告される問題を修正しました。 [＃56685](https://github.com/pingcap/tidb/issues/56685) @ [D3Hunter](https://github.com/D3Hunter) + - `EXCHANGE PARTITION`を実行して無効な行に遭遇すると、InfoSchema が完全にロードされ、エラー`failed to load schema diff`が報告される問題を修正しました。 [＃56685](https://github.com/pingcap/tidb/issues/56685) @ [D3Hunter](https://github.com/D3Hunter) - `tidb_ddl_enable_fast_reorg`と`new_collations_enabled_on_first_bootstrap`有効になっているときに照合順序が正しく処理されず、データ インデックスが不一致になる問題を修正しました。 [＃58036](https://github.com/pingcap/tidb/issues/58036) @ [djshow832](https://github.com/djshow832) - プランキャッシュがインデックスを追加するときに間違ったスキーマを使用するため、データインデックスが不整合になる問題を修正しました。 [＃56733](https://github.com/pingcap/tidb/issues/56733) @ [wjhuang2016](https://github.com/wjhuang2016) - - アップグレード中に`ALTER TABLE TIFLASH REPLICA`実行するとTiDBノードがクラッシュする問題を修正[＃57863](https://github.com/pingcap/tidb/issues/57863) @ [tangenta](https://github.com/tangenta) + - アップグレード中に`ALTER TABLE TIFLASH REPLICA`を実行するとTiDBノードがクラッシュする問題を修正[＃57863](https://github.com/pingcap/tidb/issues/57863) @ [tangenta](https://github.com/tangenta) - クエリ`INFORMATION_SCHEMA.columns`のパフォーマンスが@ [lance6716](https://github.com/lance6716)で低下する問題を修正 [＃58184](https://github.com/pingcap/tidb/issues/58184) - TiFlashシステムテーブルを照会するためのデフォルトのタイムアウトが短すぎる問題を修正[＃57816](https://github.com/pingcap/tidb/issues/57816) @ [JaySon-Huang](https://github.com/JaySon-Huang) - `default_collation_for_utf8mb4`変数の値が`SET NAMES`ステートメントで機能しない問題を修正しました [＃56439](https://github.com/pingcap/tidb/issues/56439) @ [Defined2014](https://github.com/Defined2014) diff --git a/releases/release-7.5.6.md b/releases/release-7.5.6.md index 6a9d51689b6ea..6e3160abfcdc6 100644 --- a/releases/release-7.5.6.md +++ b/releases/release-7.5.6.md @@ -53,7 +53,7 @@ TiDB バージョン: 7.5.6 - 同じ名前のビューを2つ作成してもエラーが報告されない問題を修正[＃58769](https://github.com/pingcap/tidb/issues/58769) @ [tiancaiamao](https://github.com/tiancaiamao) - `BIT`型から`CHAR`型にデータを変換すると TiKV パニックが発生する可能性がある問題を修正しました [＃56494](https://github.com/pingcap/tidb/issues/56494) @ [lcwangchao](https://github.com/lcwangchao) - ハートビートを失った TTL ジョブが他のジョブのハートビートの取得をブロックする問題を修正しました [＃57915](https://github.com/pingcap/tidb/issues/57915) @ [YangKeao](https://github.com/YangKeao) - - 不一致な値タイプとタイプ変換エラーを含む条件`IN`使用してパーティション テーブルをクエリすると、誤ったクエリ結果が発生する問題を修正しました。 [＃54746](https://github.com/pingcap/tidb/issues/54746) @ [mjonss](https://github.com/mjonss) + - 不一致な値タイプとタイプ変換エラーを含む条件`IN`を使用してパーティション テーブルをクエリすると、誤ったクエリ結果が発生する問題を修正しました。 [＃54746](https://github.com/pingcap/tidb/issues/54746) @ [mjonss](https://github.com/mjonss) - `BIT`列のデフォルト値が正しくない問題を修正[＃57301](https://github.com/pingcap/tidb/issues/57301) @ [YangKeao](https://github.com/YangKeao) - Prepareプロトコルで、クライアントがUTF8以外の文字セットを使用するとエラーが発生する問題を修正しました。 [＃58870](https://github.com/pingcap/tidb/issues/58870) @ [xhebox](https://github.com/xhebox) - `CREATE VIEW`ステートメントで変数またはパラメータを使用してもエラーが報告されない問題を修正[＃53176](https://github.com/pingcap/tidb/issues/53176) @ [mjonss](https://github.com/mjonss) @@ -63,11 +63,11 @@ TiDB バージョン: 7.5.6 - Grafanaの**Stats Healthy Distribution**パネルのデータが正しくない可能性がある問題を修正しました[＃57176](https://github.com/pingcap/tidb/issues/57176) @ [hawkingrei](https://github.com/hawkingrei) - `tidb_ttl_delete_rate_limit` を変更するときに一部の TTL ジョブがハングする可能性がある問題を修正しました [＃58484](https://github.com/pingcap/tidb/issues/58484) @ [lcwangchao](https://github.com/lcwangchao) - 統計の不適切な例外処理により、バックグラウンドタスクがタイムアウトしたときにメモリ内の統計が誤って削除される問題を修正しました[＃57901](https://github.com/pingcap/tidb/issues/57901) @ [hawkingrei](https://github.com/hawkingrei) - - `cluster_slow_query table`クエリするときに`ORDER BY`使用すると、順序付けられていない結果が生成される可能性がある問題を修正しました。 [＃51723](https://github.com/pingcap/tidb/issues/51723) @ [Defined2014](https://github.com/Defined2014) + - `cluster_slow_query table`クエリするときに`ORDER BY`を使用すると、順序付けられていない結果が生成される可能性がある問題を修正しました。 [＃51723](https://github.com/pingcap/tidb/issues/51723) @ [Defined2014](https://github.com/Defined2014) - 仮想生成列の依存関係に属性`ON UPDATE`持つ列が含まれている場合、更新された行のデータとそのインデックスデータが不整合になる可能性がある問題を修正しました[＃56829](https://github.com/pingcap/tidb/issues/56829) @ [joechenrh](https://github.com/joechenrh) - TiDBハートビートが失われた場合に TTL ジョブをキャンセルできない問題を修正[＃57784](https://github.com/pingcap/tidb/issues/57784) @ [YangKeao](https://github.com/YangKeao) - パラメータが`Enum` 、または`Set`型の場合、 `Conv()`関数はTiKV にプッシュダウンされなくなりました`Bit` [＃51877](https://github.com/pingcap/tidb/issues/51877) @ [yibin87](https://github.com/yibin87) - - 分散ストレージおよびコンピューティングアーキテクチャのTiFlashノードを含むクラスターで`ALTER TABLE ... PLACEMENT POLICY ...`実行した後、リージョンピアが誤ってTiFlashコンピューティングノードに追加される可能性がある問題を修正しました。 [＃58633](https://github.com/pingcap/tidb/issues/58633) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - 分散ストレージおよびコンピューティングアーキテクチャのTiFlashノードを含むクラスターで`ALTER TABLE ... PLACEMENT POLICY ...`を実行した後、リージョンピアが誤ってTiFlashコンピューティングノードに追加される可能性がある問題を修正しました。 [＃58633](https://github.com/pingcap/tidb/issues/58633) @ [JaySon-Huang](https://github.com/JaySon-Huang) - DDL所有者がに変更されるとジョブステータスが上書きされる問題を修正 [＃52747](https://github.com/pingcap/tidb/issues/52747) @ [D3Hunter](https://github.com/D3Hunter) - ハッシュパーティションテーブルで条件`is null`クエリを実行するとpanicが発生する問題を修正 [＃58374](https://github.com/pingcap/tidb/issues/58374) @ [Defined2014](https://github.com/Defined2014) - 生成された列を含むパーティション テーブルをクエリするときにエラーが発生する問題を修正しました。 [＃58475](https://github.com/pingcap/tidb/issues/58475) @ [joechenrh](https://github.com/joechenrh) @@ -105,7 +105,7 @@ TiDB バージョン: 7.5.6 - メモリ使用量が少ないときにTiFlash が予期せずRaftメッセージの処理を拒否する可能性がある問題を修正[＃9745](https://github.com/pingcap/tiflash/issues/9745) @ [CalvinNeo](https://github.com/CalvinNeo) - 大量のデータをインポートした後にTiFlash のメモリ使用量が高くなる可能性がある問題を修正[＃9812](https://github.com/pingcap/tiflash/issues/9812) @ [CalvinNeo](https://github.com/CalvinNeo) - - パーティションテーブルに対するクエリが、パーティションテーブルで`ALTER TABLE ... RENAME COLUMN`実行した後にエラーを返す可能性がある問題を修正しました。 [＃9787](https://github.com/pingcap/tiflash/issues/9787) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - パーティションテーブルに対するクエリが、パーティションテーブルで`ALTER TABLE ... RENAME COLUMN`を実行した後にエラーを返す可能性がある問題を修正しました。 [＃9787](https://github.com/pingcap/tiflash/issues/9787) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - 特定の状況でTiFlash が予期せず終了したときにエラー スタック トレースを印刷できないことがある問題を修正[＃9902](https://github.com/pingcap/tiflash/issues/9902) @ [JaySon-Huang](https://github.com/JaySon-Huang) - `profiles.default.init_thread_count_scale` `0` に設定するとTiFlash の起動がブロックされる可能性がある問題を修正しました [＃9906](https://github.com/pingcap/tiflash/issues/9906) @ [JaySon-Huang](https://github.com/JaySon-Huang) - クエリに仮想列が含まれており、リモート読み取りをトリガーするときに`Not found column`エラーが発生する可能性がある問題を修正しました。 [＃9561](https://github.com/pingcap/tiflash/issues/9561) @ [guo-shaoge](https://github.com/guo-shaoge) diff --git a/releases/release-7.5.7.md b/releases/release-7.5.7.md index c86e72f30aa7b..68f98d378b5fd 100644 --- a/releases/release-7.5.7.md +++ b/releases/release-7.5.7.md @@ -84,7 +84,7 @@ TiDB バージョン: 7.5.7 - 修正コントロール#44855が有効になっている場合にTiDBセッションがクラッシュする可能性がある問題を修正[＃59762](https://github.com/pingcap/tidb/issues/59762) @ [winoros](https://github.com/winoros) - `IndexLookup`オペレータが`context canceled`エラーに遭遇したときに冗長なログエントリを削除します [＃61072](https://github.com/pingcap/tidb/issues/61072) @ [yibin87](https://github.com/yibin87) - 統計の不適切な例外処理により、バックグラウンドタスクがタイムアウトしたときにメモリ内の統計が誤って削除される問題を修正しました[＃57901](https://github.com/pingcap/tidb/issues/57901) @ [hawkingrei](https://github.com/hawkingrei) - - `ADD UNIQUE INDEX`実行するとデータの不整合が発生する可能性がある問題を修正[＃60339](https://github.com/pingcap/tidb/issues/60339) @ [tangenta](https://github.com/tangenta) + - `ADD UNIQUE INDEX`を実行するとデータの不整合が発生する可能性がある問題を修正[＃60339](https://github.com/pingcap/tidb/issues/60339) @ [tangenta](https://github.com/tangenta) - 統計システムテーブルに非公開インデックスが表示される問題を修正しました [＃60430](https://github.com/pingcap/tidb/issues/60430) @ [tangenta](https://github.com/tangenta) - ハッシュ結合v1演算子の`Close()`メソッドがpanicから回復できない問題を修正しました [＃60926](https://github.com/pingcap/tidb/issues/60926) @ [xzhangxian1008](https://github.com/xzhangxian1008) - `PhysicalExchangeSender.HashCol`の浅いコピーによりTiFlash がクラッシュしたり、誤った結果が生成される問題を修正[＃60517](https://github.com/pingcap/tidb/issues/60517) @ [windtalker](https://github.com/windtalker) @@ -105,7 +105,7 @@ TiDB バージョン: 7.5.7 - システム変数`tidb_cost_model_version`のデフォルト値が誤って設定されている問題を修正[＃61565](https://github.com/pingcap/tidb/issues/61565) @ [hawkingrei](https://github.com/hawkingrei) - テーブルの最初の列が仮想生成列の場合に統計が正しくない可能性がある問題を修正しました [＃61606](https://github.com/pingcap/tidb/issues/61606) @ [winoros](https://github.com/winoros) - 述語の簡素化でプラン キャッシュが誤ってスキップされる問題を修正しました [＃61513](https://github.com/pingcap/tidb/issues/61513) @ [hawkingrei](https://github.com/hawkingrei) - - インデックスの追加中に`ADMIN CANCEL DDL JOBS`実行すると、インデックスの追加プロセスがハングする問題を修正しました。 [＃61087](https://github.com/pingcap/tidb/issues/61087) @ [tangenta](https://github.com/tangenta) + - インデックスの追加中に`ADMIN CANCEL DDL JOBS`を実行すると、インデックスの追加プロセスがハングする問題を修正しました。 [＃61087](https://github.com/pingcap/tidb/issues/61087) @ [tangenta](https://github.com/tangenta) - 一部の内部 SQL 実行が失敗した後でも`ADMIN CHECK`が成功を返す問題を修正[＃61612](https://github.com/pingcap/tidb/issues/61612) @ [joechenrh](https://github.com/joechenrh) - マルチスキーマ変更で複数のインデックスを追加した後にデータとインデックスが不整合になる問題を修正 [＃61255](https://github.com/pingcap/tidb/issues/61255) @ [tangenta](https://github.com/tangenta) diff --git a/releases/release-8.0.0.md b/releases/release-8.0.0.md index cc3f784df25cb..2261dd3dde9cf 100644 --- a/releases/release-8.0.0.md +++ b/releases/release-8.0.0.md @@ -335,7 +335,7 @@ TiDB バージョン: 8.0.0 - ディスクへのデータ流出中にクエリをキャンセルする機能をサポートし、データ流出機能の終了メカニズムを最適化します [#50511](https://github.com/pingcap/tidb/issues/50511) @[wshwsh12](https://github.com/wshwsh12) - 複数の等しい条件を持つテーブル結合クエリを処理する際に、部分条件に一致するインデックスを使用してインデックス結合を構築することをサポートする [#47233](https://github.com/pingcap/tidb/issues/47233) @[winoros](https://github.com/winoros) - クエリ内のソート要件を識別し、ソート要件を満たすインデックスを選択するインデックスマージ機能を強化します [#48359](https://github.com/pingcap/tidb/issues/48359) @[AilinKid](https://github.com/AilinKid) - - `Apply`演算子が同時に実行されない場合、TiDB では`SHOW WARNINGS`実行することで、同時実行をブロックしている演算子の名前を表示できます。 [#50256](https://github.com/pingcap/tidb/issues/50256) @[hawkingrei](https://github.com/hawkingrei) + - `Apply`演算子が同時に実行されない場合、TiDB では`SHOW WARNINGS`を実行することで、同時実行をブロックしている演算子の名前を表示できます。 [#50256](https://github.com/pingcap/tidb/issues/50256) @[hawkingrei](https://github.com/hawkingrei) - `point get`クエリがすべてのインデックスでサポートされている場合に、クエリに最適なインデックスを選択することで`point get`クエリのインデックス選択を最適化します。 [#50184](https://github.com/pingcap/tidb/issues/50184) @[elsa0520](https://github.com/elsa0520) - TiKVの負荷が高い時に広範囲にわたるタイムアウトが発生するのを避けるため、統計情報を同期的にロードするタスクの優先度を一時的に「高」に調整します。タイムアウトが発生すると、統計情報がロードされない可能性があります。 [#50332](https://github.com/pingcap/tidb/issues/50332) @[winoros](https://github.com/winoros) - `PREPARE`ステートメントが実行プランキャッシュにヒットしなかった場合、TiDB では`SHOW WARNINGS`を実行することで理由を確認できます。 [#50407](https://github.com/pingcap/tidb/issues/50407) @[hawkingrei](https://github.com/hawkingrei) diff --git a/releases/release-8.1.0.md b/releases/release-8.1.0.md index d6fd27fab9ff8..c202fb6be3223 100644 --- a/releases/release-8.1.0.md +++ b/releases/release-8.1.0.md @@ -210,7 +210,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 - IndexHashJoin が Anti Left Outer Semi Join を計算するときに冗長なデータを出力する問題を修正しました。 [＃52923](https://github.com/pingcap/tidb/issues/52923) @ [yibin87](https://github.com/yibin87) - 相関サブクエリにおける TopN 演算子の誤った結果を修正 [＃52777](https://github.com/pingcap/tidb/issues/52777) @ [yibin87](https://github.com/yibin87) - HashJoinプローブの不正確な実行時間統計を修正 [＃52222](https://github.com/pingcap/tidb/issues/52222) @ [windtalker](https://github.com/windtalker) - - 静的パーティションプルーニングモードで`TABLESAMPLE`使用すると誤った結果が返される問題を修正（ `tidb_partition_prune_mode='static'` ） [＃52282](https://github.com/pingcap/tidb/issues/52282) @ [tangenta](https://github.com/tangenta) + - 静的パーティションプルーニングモードで`TABLESAMPLE`を使用すると誤った結果が返される問題を修正（ `tidb_partition_prune_mode='static'` ） [＃52282](https://github.com/pingcap/tidb/issues/52282) @ [tangenta](https://github.com/tangenta) - 夏時間でTTLが1時間ずれる問題を修正 [＃51675](https://github.com/pingcap/tidb/issues/51675) @ [lcwangchao](https://github.com/lcwangchao) - TiDB Dashboardのモニタリングページにおける接続数（接続数）の計算と表示が誤っていた問題を修正しました。 [＃51889](https://github.com/pingcap/tidb/issues/51889) @ [YangKeao](https://github.com/YangKeao) - パーティションDDLタスクをロールバックするときにステータスが停止する問題を修正しました [＃51090](https://github.com/pingcap/tidb/issues/51090) @ [jiyfhust](https://github.com/jiyfhust) diff --git a/releases/release-8.1.1.md b/releases/release-8.1.1.md index 9a042064dfe33..960bdf4e41538 100644 --- a/releases/release-8.1.1.md +++ b/releases/release-8.1.1.md @@ -73,7 +73,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - トランザクション内のステートメントが OOM によって強制終了された後、TiDB が同じトランザクション内で次のステートメントの実行を継続すると、エラー`Trying to start aggressive locking while it's already started`が発生し、panicが発生する可能性がある問題を修正しました。 [＃53540](https://github.com/pingcap/tidb/issues/53540) @ [MyonKeminta](https://github.com/MyonKeminta) - `?`の引数を含む`CONV`の式を持つ`PREPARE` `EXECUTE`ステートメントを複数回実行すると、誤ったクエリ結果が返される可能性がある問題を修正しました[＃53505](https://github.com/pingcap/tidb/issues/53505) @ [qw4990](https://github.com/qw4990) - 再帰CTE演算子がメモリ使用量を誤って追跡する問題を修正しました [＃54181](https://github.com/pingcap/tidb/issues/54181) @ [guo-shaoge](https://github.com/guo-shaoge) - - `SHOW WARNINGS;`使用して警告を取得するとpanicが発生する可能性がある問題を修正しました [＃48756](https://github.com/pingcap/tidb/issues/48756) @ [xhebox](https://github.com/xhebox) + - `SHOW WARNINGS;`を使用して警告を取得するとpanicが発生する可能性がある問題を修正しました [＃48756](https://github.com/pingcap/tidb/issues/48756) @ [xhebox](https://github.com/xhebox) - TopN演算子が誤ってプッシュダウンされる可能性がある問題を修正しました [＃37986](https://github.com/pingcap/tidb/issues/37986) @ [qw4990](https://github.com/qw4990) - 常に`true` となる述語を持つ`SHOW ERRORS`ステートメントを実行すると TiDB がパニックを起こす問題を修正しました。 [＃46962](https://github.com/pingcap/tidb/issues/46962) @ [elsa0520](https://github.com/elsa0520) - `STATE`フィールドのうち`size`が定義されていないため、 `INFORMATION_SCHEMA.TIDB_TRX`テーブルの`STATE`フィールドが空になる問題を修正しました[＃53026](https://github.com/pingcap/tidb/issues/53026) @ [cfzjywxk](https://github.com/cfzjywxk) @@ -109,7 +109,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - 述語の`Longlong`型のオーバーフローの問題を修正 [＃45783](https://github.com/pingcap/tidb/issues/45783) @ [hawkingrei](https://github.com/hawkingrei) - `GROUP BY`ステートメント内の間接プレースホルダ`?`参照が列を見つけられない問題を修正しました [＃53872](https://github.com/pingcap/tidb/issues/53872) @ [qw4990](https://github.com/qw4990) - トランザクションで使用されるメモリが複数回追跡される可能性がある問題を修正[＃53984](https://github.com/pingcap/tidb/issues/53984) @ [ekexium](https://github.com/ekexium) - - 列のデフォルト値として`CURRENT_DATE()`使用すると、クエリ結果が正しくなくなる問題を修正しました [＃53746](https://github.com/pingcap/tidb/issues/53746) @ [tangenta](https://github.com/tangenta) + - 列のデフォルト値として`CURRENT_DATE()`を使用すると、クエリ結果が正しくなくなる問題を修正しました [＃53746](https://github.com/pingcap/tidb/issues/53746) @ [tangenta](https://github.com/tangenta) - グローバルソートを使用してインデックスを追加するときにパフォーマンスが不安定になる問題を修正しました [＃54147](https://github.com/pingcap/tidb/issues/54147) @ [tangenta](https://github.com/tangenta) - v7.1 からアップグレードした後に`SHOW IMPORT JOBS`エラー`Unknown column 'summary'`を報告する問題を修正しました [＃54241](https://github.com/pingcap/tidb/issues/54241) @ [tangenta](https://github.com/tangenta) - `root`ユーザーが`tidb_mdl_view` を照会できない問題を修正 [＃53292](https://github.com/pingcap/tidb/issues/53292) @ [tangenta](https://github.com/tangenta) @@ -165,7 +165,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - データベースが作成直後に削除されるとTiFlash がpanic可能性がある問題を修正[＃9266](https://github.com/pingcap/tiflash/issues/9266) @ [JaySon-Huang](https://github.com/JaySon-Huang) - TiFlashで SSL 証明書の構成を空の文字列に設定すると、誤って TLS が有効になり、 TiFlash が起動しなくなる問題を修正しました[＃9235](https://github.com/pingcap/tiflash/issues/9235) @ [JaySon-Huang](https://github.com/JaySon-Huang) - 分散ストレージおよびコンピューティングアーキテクチャで、DDL操作で非NULL列を追加した後にクエリでNULL値が誤って返される可能性がある問題を修正しました。 [＃9084](https://github.com/pingcap/tiflash/issues/9084) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - - データベースにまたがる空のパーティションを持つパーティションテーブルで`RENAME TABLE ... TO ...`実行した後にTiFlash がpanic可能性がある問題を修正しました。 [＃9132](https://github.com/pingcap/tiflash/issues/9132) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - データベースにまたがる空のパーティションを持つパーティションテーブルで`RENAME TABLE ... TO ...`を実行した後にTiFlash がpanic可能性がある問題を修正しました。 [＃9132](https://github.com/pingcap/tiflash/issues/9132) @ [JaySon-Huang](https://github.com/JaySon-Huang) - 空のパーティションを含むパーティション テーブルでクエリを実行するときに発生するクエリ タイムアウトの問題を修正しました。 [＃9024](https://github.com/pingcap/tiflash/issues/9024) @ [JinheLin](https://github.com/JinheLin) - 遅延マテリアライゼーションが有効になった後に、一部のクエリで列タイプの不一致エラーが報告される可能性がある問題を修正[＃9175](https://github.com/pingcap/tiflash/issues/9175) @ [JinheLin](https://github.com/JinheLin) - 遅延マテリアライゼーションが有効になった後、仮想生成列を含むクエリが誤った結果を返す可能性がある問題を修正[＃9188](https://github.com/pingcap/tiflash/issues/9188) @ [JinheLin](https://github.com/JinheLin) diff --git a/releases/release-8.3.0.md b/releases/release-8.3.0.md index 5d4481afc1c35..de80f597f3fb6 100644 --- a/releases/release-8.3.0.md +++ b/releases/release-8.3.0.md @@ -350,7 +350,7 @@ TiDBバージョン：8.3.0 - TiFlash - `CAST()`関数を使用して文字列をタイムゾーンまたは無効な文字を含む datetime に変換すると、結果が正しくない問題を修正しました [#8754](https://github.com/pingcap/tiflash/issues/8754) @[solotzg](https://github.com/solotzg) - - データベース全体に空のパーティションがあるパーティションテーブルで`RENAME TABLE ... TO ...`実行するとTiFlash がpanicになる問題を修正 [#9132](https://github.com/pingcap/tiflash/issues/9132) @[JaySon-Huang](https://github.com/JaySon-Huang) + - データベース全体に空のパーティションがあるパーティションテーブルで`RENAME TABLE ... TO ...`を実行するとTiFlash がpanicになる問題を修正 [#9132](https://github.com/pingcap/tiflash/issues/9132) @[JaySon-Huang](https://github.com/JaySon-Huang) - 遅延マテリアライゼーションが有効になった後、一部のクエリで列型の不一致エラーが報告される可能性がある問題を修正 [#9175](https://github.com/pingcap/tiflash/issues/9175) @[JinheLin](https://github.com/JinheLin) - 仮想生成列を含むクエリが遅延マテリアライゼーション有効後に誤った結果を返す可能性がある問題を修正 [#9188](https://github.com/pingcap/tiflash/issues/9188) @[JinheLin](https://github.com/JinheLin) - TiFlashでSSL証明書の設定を空文字列に設定するとTLSが誤って有効になり、 TiFlashが起動に失敗する問題を修正しました [#9235](https://github.com/pingcap/tiflash/issues/9235) @[JaySon-Huang](https://github.com/JaySon-Huang) diff --git a/releases/release-pre-ga.md b/releases/release-pre-ga.md index f0be8bce4f187..58f56a6780928 100644 --- a/releases/release-pre-ga.md +++ b/releases/release-pre-ga.md @@ -27,7 +27,7 @@ summary: 2017年8月30日にリリースされたTiDBのプレGAリリースは ## TiKV {#tikv} - 専用のRocksdbインスタンスを使用してRaftログを保存する -- レプリカの削除を高速化するには`DeleteRange`使用します +- レプリカの削除を高速化するには`DeleteRange`を使用します - コプロセッサーはより多くのプッシュダウン演算子をサポートするようになりました - パフォーマンスと安定性を向上 diff --git a/releases/release-rc.1.md b/releases/release-rc.1.md index 530806bde56fc..73d8486fd6ed7 100644 --- a/releases/release-rc.1.md +++ b/releases/release-rc.1.md @@ -35,7 +35,7 @@ summary: TiDB RC1は2016年12月23日にリリースされました。アップ - `add index`文目の速度が向上します。 - 次のステートメントがサポートされています。 - 列の名前を変更するには、 `CHANGE COLUMN`ステートメントを使用します。 - - 一部の列タイプ転送には、 `ALTER TABLE`ステートメントのうち`MODIFY COLUMN`と`CHANGE COLUMN`使用します。 + - 一部の列タイプ転送には、 `ALTER TABLE`ステートメントのうち`MODIFY COLUMN`と`CHANGE COLUMN`を使用します。 ## 新しいツール {#new-tools} diff --git a/resources/doc-templates/template-concept.md b/resources/doc-templates/template-concept.md index 78a197443bbf9..afb4ff3e55586 100644 --- a/resources/doc-templates/template-concept.md +++ b/resources/doc-templates/template-concept.md @@ -21,7 +21,7 @@ summary: このドキュメントを115～145文字で要約してください -画像サイズは 300 KB 以下にしてください。 `.png`または`.jpg`使用してください。 `.gif`または`.svg`使用しないでください。 +画像サイズは 300 KB 以下にしてください。 `.png`または`.jpg`を使用してください。 `.gif`または`.svg`を使用しないでください。 画像の下に、より詳細な説明を記入してください。各コンポーネントを紹介する際には、順序なしリスト（ `*` / `+` / `-` ）を使用してください。 diff --git a/role-based-access-control.md b/role-based-access-control.md index cb53e7a386fe9..8c149c76b6ee4 100644 --- a/role-based-access-control.md +++ b/role-based-access-control.md @@ -58,7 +58,7 @@ GRANT ALL ON app_db.* TO 'app_developer'; ユーザー`dev1` `app_db`に対するすべての権限を持つ開発者ロールを持ち、ユーザー`read_user1`と`read_user2` `app_db`に対する読み取り専用権限を持ち、ユーザー`rw_user1` `app_db`に対する読み取り権限と書き込み権限を持っているとします。 -`CREATE USER`使用してユーザーを作成します。 +`CREATE USER`を使用してユーザーを作成します。 ```sql CREATE USER 'dev1'@'localhost' IDENTIFIED BY 'dev1pass'; @@ -67,7 +67,7 @@ CREATE USER 'read_user2'@'localhost' IDENTIFIED BY 'read_user2pass'; CREATE USER 'rw_user1'@'localhost' IDENTIFIED BY 'rw_user1pass'; ``` -次に`GRANT`使用してユーザーにロールを付与します +次に`GRANT`を使用してユーザーにロールを付与します ```sql GRANT 'app_developer' TO 'dev1'@'localhost'; @@ -151,7 +151,7 @@ SHOW GRANTS FOR 'read_user1'@'localhost' USING 'app_read'; | GRANT `app_read`@`%` TO `read_user1`@`localhost` | +--------------------------------------------------------+ -現在のユーザーの権限を確認するには、 `SHOW GRANTS`または`SHOW GRANTS FOR CURRENT_USER()`使用します。5 と`SHOW GRANTS FOR CURRENT_USER()` `SHOW GRANTS`の点で異なります。 +現在のユーザーの権限を確認するには、 `SHOW GRANTS`または`SHOW GRANTS FOR CURRENT_USER()`を使用します。5 と`SHOW GRANTS FOR CURRENT_USER()` `SHOW GRANTS`の点で異なります。 - `SHOW GRANTS` 、現在のユーザーに対して有効なロールの権限を示します。 - `SHOW GRANTS FOR CURRENT_USER()`場合、有効なロールの権限は表示されません。 @@ -236,7 +236,7 @@ SET ROLE ALL EXCEPT 'app_read' > **注記：** > -> `SET ROLE`使用してロールを有効にすると、このロールは現在のセッションでのみ有効になります。 +> `SET ROLE`を使用してロールを有効にすると、このロールは現在のセッションでのみ有効になります。 ### 現在有効なロールを確認する {#check-the-current-enabled-role} @@ -288,7 +288,7 @@ REVOKE 'app_read', 'app_write' FROM 'rw_user1'@'localhost'; ### 権限を取り消す {#revoke-a-privilege} -`REVOKE`文は`GRANT`の逆です。 `REVOKE`使用すると`app_write`の権限を取り消すことができます。 +`REVOKE`文は`GRANT`の逆です。 `REVOKE`を使用すると`app_write`の権限を取り消すことができます。 ```sql REVOKE INSERT, UPDATE, DELETE ON app_db.* FROM 'app_write'; diff --git a/runtime-filter.md b/runtime-filter.md index 80480b274e9be..6118fc25f96da 100644 --- a/runtime-filter.md +++ b/runtime-filter.md @@ -78,7 +78,7 @@ WHERE ss_date_sk = d_date_sk ランタイム フィルターを使用するには、 TiFlashレプリカを含むテーブルを作成し、 [`tidb_runtime_filter_mode`](/system-variables.md#tidb_runtime_filter_mode-new-in-v720)を`LOCAL`に設定する必要があります。 -このセクションでは、TPC-DS データセットを例に、結合操作にテーブル`catalog_sales`とテーブル`date_dim`使用して、ランタイム フィルターによってクエリ効率がどのように向上するかを説明します。 +このセクションでは、TPC-DS データセットを例に、結合操作にテーブル`catalog_sales`とテーブル`date_dim`を使用して、ランタイム フィルターによってクエリ効率がどのように向上するかを説明します。 ### ステップ1. 結合するテーブルのTiFlashレプリカを作成する {#step-1-create-tiflash-replicas-for-tables-to-be-joined} diff --git a/scale-microservices-using-tiup.md b/scale-microservices-using-tiup.md index bd3d0eaf9dc0a..94f448781b965 100644 --- a/scale-microservices-using-tiup.md +++ b/scale-microservices-using-tiup.md @@ -7,7 +7,7 @@ summary: TiUPを使用してクラスター内の PD マイクロサービス このドキュメントでは、クラスター内の[PDマイクロサービス](/pd-microservices.md)ノード (TSO ノードとスケジューリング ノードを含む) をスケーリングする方法と、 TiUPを使用して PD 動作モードを切り替える方法について説明します。 -現在のクラスター名リストを表示するには、 `tiup cluster list`実行します。 +現在のクラスター名リストを表示するには、 `tiup cluster list`を実行します。 たとえば、クラスターの元のトポロジは次のようになります。 @@ -57,7 +57,7 @@ scheduling_servers: port: 3379 ``` -現在のクラスターの構成を表示するには、 `tiup cluster edit-config `実行します。 `global`と`server_configs`のパラメータ設定は`scale-out.yml`に継承されるため、 `scale-out.yml`でも有効になります。 +現在のクラスターの構成を表示するには、 `tiup cluster edit-config `を実行します。 `global`と`server_configs`のパラメータ設定は`scale-out.yml`に継承されるため、 `scale-out.yml`でも有効になります。 ### 2.スケールアウトコマンドを実行する {#2-run-the-scale-out-command} @@ -269,7 +269,7 @@ PD マイクロサービスが有効になっているクラスター (IP アド tiup cluster edit-config ``` - `global`から`pd_mode: ms`削除します: + `global`から`pd_mode: ms`を削除します: ```ini global: diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md index da495762cb29f..857359c601344 100644 --- a/scale-tidb-using-tiup.md +++ b/scale-tidb-using-tiup.md @@ -9,7 +9,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する このドキュメントでは、 TiUPを使用して TiDB、TiKV、PD、TiCDC、またはTiFlashクラスターをスケーリングする方法について説明します。TiUPをインストールしていない場合は、 [ステップ2. 制御マシンにTiUPをデプロイ](/production-deployment-using-tiup.md#step-2-deploy-tiup-on-the-control-machine)の手順を参照してください。 -現在のクラスター名リストを表示するには、 `tiup cluster list`実行します。 +現在のクラスター名リストを表示するには、 `tiup cluster list`を実行します。 たとえば、クラスターの元のトポロジが次のようになっているとします。 @@ -80,7 +80,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する log_dir: /tidb-deploy/pd-2379/log ``` - 現在のクラスターの構成を表示するには、 `tiup cluster edit-config `実行します。 `global`と`server_configs`のパラメータ設定は`scale-out.yml`に継承されるため、 `scale-out.yml`でも有効になります。 + 現在のクラスターの構成を表示するには、 `tiup cluster edit-config `を実行します。 `global`と`server_configs`のパラメータ設定は`scale-out.yml`に継承されるため、 `scale-out.yml`でも有効になります。 2. スケールアウト コマンドを実行します。 diff --git a/security-compatibility-with-mysql.md b/security-compatibility-with-mysql.md index 8e9d28dbdab08..470f2a504cddf 100644 --- a/security-compatibility-with-mysql.md +++ b/security-compatibility-with-mysql.md @@ -49,7 +49,7 @@ The password complexity policies of TiDB and MySQL have the following difference - 辞書チェック: - In MySQL v5.7, you can specify a file path using the `validate_password_dictionary_file` variable. The file contains a list of words that are not allowed to exist in passwords. - - MySQL v8.0では、変数`validate_password.dictionary_file`使用してファイルパスを指定できます。このファイルには、パスワードに使用できない単語のリストが含まれています。 + - MySQL v8.0では、変数`validate_password.dictionary_file`を使用してファイルパスを指定できます。このファイルには、パスワードに使用できない単語のリストが含まれています。 - TiDBでは、システム変数[`validate_password.dictionary`](/system-variables.md#validate_passworddictionary-new-in-v650)を使用して文字列を指定できます。この文字列には、パスワードに使用できない単語のリストが含まれます。 ### パスワード失敗の追跡 {#password-failure-tracking} @@ -67,13 +67,13 @@ TiDB と MySQL のパスワード失敗追跡ポリシーには、次の違い - MySQL 8.0: - サーバーを再起動すると、すべてのアカウントの失敗した試行回数がリセットされます。 - - `FLUSH PRIVILEGES`実行すると、すべてのアカウントの失敗した試行回数がリセットされます。 - - `ALTER USER ... ACCOUNT UNLOCK`実行してアカウントのロックを解除すると、カウントはリセットされます。 + - `FLUSH PRIVILEGES`を実行すると、すべてのアカウントの失敗した試行回数がリセットされます。 + - `ALTER USER ... ACCOUNT UNLOCK`を実行してアカウントのロックを解除すると、カウントはリセットされます。 - アカウントが正常にログインすると、カウントはリセットされます。 - TiDB: - - `ALTER USER ... ACCOUNT UNLOCK`実行してアカウントのロックを解除すると、カウントはリセットされます。 + - `ALTER USER ... ACCOUNT UNLOCK`を実行してアカウントのロックを解除すると、カウントはリセットされます。 - When an account logs in successfully, the count is reset. - 自動的にロックされるユーザーの場合、次のシナリオで失敗した試行回数がリセットされます。 @@ -83,12 +83,12 @@ TiDB と MySQL のパスワード失敗追跡ポリシーには、次の違い - サーバーを再起動すると、すべてのアカウントの一時ロックがリセットされます。 - When `FLUSH PRIVILEGES` is executed, the temporary locking for all accounts is reset. - アカウントのロック時間が終了した場合、次回のログイン試行時にアカウントの一時ロックはリセットされます。 - - `ALTER USER ... ACCOUNT UNLOCK`実行してアカウントのロックを解除すると、アカウントの一時的なロックがリセットされます。 + - `ALTER USER ... ACCOUNT UNLOCK`を実行してアカウントのロックを解除すると、アカウントの一時的なロックがリセットされます。 - TiDB: - アカウントのロック時間が終了した場合、次回のログイン試行時にアカウントの一時ロックはリセットされます。 - - `ALTER USER ... ACCOUNT UNLOCK`実行してアカウントのロックを解除すると、アカウントの一時的なロックがリセットされます。 + - `ALTER USER ... ACCOUNT UNLOCK`を実行してアカウントのロックを解除すると、アカウントの一時的なロックがリセットされます。 ### パスワード再利用ポリシー {#password-reuse-policy} @@ -100,10 +100,10 @@ The password reuse policies of TiDB and MySQL have the following differences: TiDBとMySQLの実装メカニズムは一貫しています。どちらも`mysql.password_history`のシステムテーブルを使用してパスワード再利用管理機能を実装しています。ただし、 `mysql.user`システムテーブルに存在しないユーザーを削除する場合、TiDBとMySQLの動作は異なります。 -- シナリオ：ユーザー（ `user01` ）は通常の方法で作成されず、 `INSERT INTO mysql.password_history VALUES (...)`文を使用して`user01`のレコードを`mysql.password_history`システムテーブルに追加することで作成されます。この場合、 `user01`のレコードは`mysql.user`システムテーブルに存在しないため、 `user01`に対して`DROP USER`実行すると、TiDBとMySQLの動作が異なります。 +- シナリオ：ユーザー（ `user01` ）は通常の方法で作成されず、 `INSERT INTO mysql.password_history VALUES (...)`文を使用して`user01`のレコードを`mysql.password_history`システムテーブルに追加することで作成されます。この場合、 `user01`のレコードは`mysql.user`システムテーブルに存在しないため、 `user01`に対して`DROP USER`を実行すると、TiDBとMySQLの動作が異なります。 - - MySQL: `DROP USER user01`実行すると、MySQL は`mysql.user`と`mysql.password_history`から`user01`探します。いずれかのシステムテーブルに`user01`が含まれている場合、 `DROP USER`文は正常に実行され、エラーは報告されません。 - - TiDB: `DROP USER user01`実行すると、TiDBは`mysql.user`からのみ`user01`検索しようとします。関連レコードが見つからない場合、 `DROP USER`文は失敗し、エラーが報告されます。文を正常に実行し、 `mysql.password_history`から`user01`レコードを削除したい場合は、代わりに`DROP USER IF EXISTS user01`使用してください。 + - MySQL: `DROP USER user01`を実行すると、MySQL は`mysql.user`と`mysql.password_history`から`user01`探します。いずれかのシステムテーブルに`user01`が含まれている場合、 `DROP USER`文は正常に実行され、エラーは報告されません。 + - TiDB: `DROP USER user01`を実行すると、TiDBは`mysql.user`からのみ`user01`検索しようとします。関連レコードが見つからない場合、 `DROP USER`文は失敗し、エラーが報告されます。文を正常に実行し、 `mysql.password_history`から`user01`レコードを削除したい場合は、代わりに`DROP USER IF EXISTS user01`を使用してください。 ## Authentication plugin status {#authentication-plugin-status} @@ -189,7 +189,7 @@ Here is an example for Header: > **警告：** > > - ヘッダーとペイロードのBase64エンコードは可逆です。機密情報を添付し**ないで**ください。 -> - `tidb_auth_token`認証方法では、クライアントが[`mysql_clear_password`](https://dev.mysql.com/doc/refman/8.0/en/cleartext-pluggable-authentication.html)プラグインをサポートし、トークンをプレーンテキストで TiDB に送信する必要があります。そのため、 `tidb_auth_token`使用する前に[クライアントとサーバー間のTLSを有効にする](/enable-tls-between-clients-and-servers.md)実行する必要があります。 +> - `tidb_auth_token`認証方法では、クライアントが[`mysql_clear_password`](https://dev.mysql.com/doc/refman/8.0/en/cleartext-pluggable-authentication.html)プラグインをサポートし、トークンをプレーンテキストで TiDB に送信する必要があります。そのため、 `tidb_auth_token`を使用する前に[クライアントとサーバー間のTLSを有効にする](/enable-tls-between-clients-and-servers.md)実行する必要があります。 #### 使用法 {#usage} @@ -212,9 +212,9 @@ TiDB Self-Managed ユーザーの認証方法として`tidb_auth_token`設定し 2. `tidb-server`起動し、定期的に JWKS を更新して`auth-token-jwks`で指定されたパスに保存します。 -3. `tidb_auth_token`でユーザーを作成し、必要に応じて`REQUIRE TOKEN_ISSUER`と`ATTRIBUTE '{"email": "xxxx@pingcap.com"}`を使用して`iss`と`email`指定します。 +3. `tidb_auth_token`でユーザーを作成し、必要に応じて`REQUIRE TOKEN_ISSUER`と`ATTRIBUTE '{"email": "xxxx@pingcap.com"}`を使用して`iss`と`email`を指定します。 - たとえば、 `tidb_auth_token`を持つユーザー`user@pingcap.com`作成します。 + たとえば、 `tidb_auth_token`を持つユーザー`user@pingcap.com`を作成します。 ```sql CREATE USER 'user@pingcap.com' IDENTIFIED WITH 'tidb_auth_token' REQUIRE TOKEN_ISSUER 'issuer-abc' ATTRIBUTE '{"email": "user@pingcap.com"}'; diff --git a/sql-logical-optimization.md b/sql-logical-optimization.md index 876a541974aca..a9cebb24d7a37 100644 --- a/sql-logical-optimization.md +++ b/sql-logical-optimization.md @@ -5,7 +5,7 @@ summary: SQL論理最適化の章では、TiDBクエリプラン生成におけ # SQL論理最適化 {#sql-logical-optimization} -この章では、TiDBが最終的なクエリプランを生成する仕組みを理解するために、いくつかの重要なロジックの書き換えについて説明します。例えば、TiDBでクエリ`select * from t where t.a in (select t1.a from t1 where t1.b=t.b)`実行すると、TiDBがここで書き換えを行ったため、サブクエリ`IN` `t.a in (select t1.a from t1 where t1.b=t.b)`存在しないことがわかります。 +この章では、TiDBが最終的なクエリプランを生成する仕組みを理解するために、いくつかの重要なロジックの書き換えについて説明します。例えば、TiDBでクエリ`select * from t where t.a in (select t1.a from t1 where t1.b=t.b)`を実行すると、TiDBがここで書き換えを行ったため、サブクエリ`IN` `t.a in (select t1.a from t1 where t1.b=t.b)`存在しないことがわかります。 この章では、次の重要な書き換えについて説明します。 diff --git a/sql-non-prepared-plan-cache.md b/sql-non-prepared-plan-cache.md index a9f01d20efeef..e21c968bc90df 100644 --- a/sql-non-prepared-plan-cache.md +++ b/sql-non-prepared-plan-cache.md @@ -89,7 +89,7 @@ TiDBは、パラメータ化されたクエリに対して1つのプランのみ - パラメータ化後のパラメータ数が200を超えるクエリ（例： `SELECT * FROM t WHERE a in (1, 2, 3, ... 201)` ）は、デフォルトではサポートされません。v7.3.0以降では、システム変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)に[`44823`](/optimizer-fix-controls.md#44823-new-in-v730)を設定することで、この制限を変更できます。 - 仮想列、一時テーブル、ビュー、またはメモリテーブルにアクセスするクエリはサポートされていません (例: `SELECT * FROM INFORMATION_SCHEMA.COLUMNS` 、 `COLUMNS`は TiDBメモリテーブル)。 - ヒントまたはバインディングを含むクエリはサポートされていません。 -- DML文、または`FOR UPDATE`句を含む`SELECT`文はデフォルトではサポートされていません。この制限を解除するには、 `SET tidb_enable_non_prepared_plan_cache_for_dml = ON`実行してください。 +- DML文、または`FOR UPDATE`句を含む`SELECT`文はデフォルトではサポートされていません。この制限を解除するには、 `SET tidb_enable_non_prepared_plan_cache_for_dml = ON`を実行してください。 After you enable this feature, the optimizer quickly evaluates the query. If it does not meet the support conditions for non-prepared plan cache, the query falls back to the regular optimization process. @@ -121,7 +121,7 @@ EXPLAIN FORMAT='plan_cache' SELECT * FROM (SELECT a+1 FROM t) t; 3 rows in set, 1 warning (0.00 sec) ``` -キャッシュにヒットできないクエリを表示するには、 `SHOW warnings;`実行します。 +キャッシュにヒットできないクエリを表示するには、 `SHOW warnings;`を実行します。 ```sql SHOW warnings; diff --git a/sql-plan-management.md b/sql-plan-management.md index 4cb6bcb00aff4..15e4571cbcffa 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -228,7 +228,7 @@ SQL文の実行計画を過去の実行計画に固定するには、Plan Digest - この機能は、過去の実行計画に基づいてヒントを生成し、生成されたヒントをバインディングに使用します。過去の実行計画は[明細書要約表](/statement-summary-tables.md)に保存されるため、この機能を使用する前に、 [`tidb_enable_stmt_summary`](/system-variables.md#tidb_enable_stmt_summary-new-in-v304)システム変数を有効にする必要があります。 - TiFlashクエリ、3つ以上のテーブルを含む結合クエリ、およびサブクエリを含むクエリの場合、自動生成されるヒントが適切ではないため、プランが完全にバインドされない可能性があります。このような場合、バインドの作成時に警告が表示されます。 -- 履歴実行プランがヒント付きのSQL文用である場合、ヒントはバインディングに追加されます。例えば、 `SELECT /*+ max_execution_time(1000) */ * FROM t`実行した後、そのプランダイジェストで作成されたバインディングには`max_execution_time(1000)`含まれます。 +- 履歴実行プランがヒント付きのSQL文用である場合、ヒントはバインディングに追加されます。例えば、 `SELECT /*+ max_execution_time(1000) */ * FROM t`を実行した後、そのプランダイジェストで作成されたバインディングには`max_execution_time(1000)`含まれます。 このバインディング メソッドの SQL ステートメントは次のとおりです。 @@ -338,7 +338,7 @@ DROP [GLOBAL | SESSION] BINDING FOR SQL DIGEST StringLiteralOrUserVariableList; > **注記：** > -> `DROP GLOBAL BINDING`実行すると、現在の tidb-server インスタンスのキャッシュ内のバインディングが削除され、システムテーブル内の対応する行のステータスが「削除済み」に変更されます。この文はシステムテーブル内のレコードを直接削除しません。これは、他の tidb-server インスタンスがキャッシュ内の対応するバインディングを削除するために「削除済み」ステータスを読み取る必要があるためです。これらのシステムテーブル内の「削除済み」ステータスのレコードについては、100 `bind-info-lease` (デフォルト値は`3s`で、合計`300s` ) 間隔ごとに、バックグラウンドスレッドが 10 `bind-info-lease`の前に`update_time`のバインディングの再利用とクリアの操作をトリガーします (すべての tidb-server インスタンスが「削除済み」ステータスを読み取り、キャッシュを更新できるようにするため)。 +> `DROP GLOBAL BINDING`を実行すると、現在の tidb-server インスタンスのキャッシュ内のバインディングが削除され、システムテーブル内の対応する行のステータスが「削除済み」に変更されます。この文はシステムテーブル内のレコードを直接削除しません。これは、他の tidb-server インスタンスがキャッシュ内の対応するバインディングを削除するために「削除済み」ステータスを読み取る必要があるためです。これらのシステムテーブル内の「削除済み」ステータスのレコードについては、100 `bind-info-lease` (デフォルト値は`3s`で、合計`300s` ) 間隔ごとに、バックグラウンドスレッドが 10 `bind-info-lease`の前に`update_time`のバインディングの再利用とクリアの操作をトリガーします (すべての tidb-server インスタンスが「削除済み」ステータスを読み取り、キャッシュを更新できるようにするため)。 ### バインディングステータスの変更 {#change-binding-status} diff --git a/sql-plan-replayer.md b/sql-plan-replayer.md index c746c756b5970..5ceb9a96f212c 100644 --- a/sql-plan-replayer.md +++ b/sql-plan-replayer.md @@ -14,7 +14,7 @@ TiDB クラスタの問題を特定してトラブルシューティングする ## PLAN REPLAYERを使用してクラスター情報をエクスポートします {#use-code-plan-replayer-code-to-export-cluster-information} -`PLAN REPLAYER`使用すると、TiDBクラスタのオンサイト情報を保存できます。エクスポートインターフェースは次のとおりです。 +`PLAN REPLAYER`を使用すると、TiDBクラスタのオンサイト情報を保存できます。エクスポートインターフェースは次のとおりです。 ```sql PLAN REPLAYER DUMP [WITH STATS AS OF TIMESTAMP expression] EXPLAIN [ANALYZE] sql-statement; @@ -190,7 +190,7 @@ mysql> show stats_meta; ## PLAN REPLAYER CAPTUREを使用してターゲットプランをキャプチャします {#use-code-plan-replayer-capture-code-to-capture-target-plans} -TiDBの実行プランを特定する場合、対象となるSQL文と実行プランがクエリ内にまれにしか出現しないため、 `PLAN REPLAYER`使用して文とプランを直接取得できない場合があります。このような場合、 `PLAN REPLAYER CAPTURE`使用すると、対象となるSQL文と実行プランのオプティマイザー情報を取得できます。 +TiDBの実行プランを特定する場合、対象となるSQL文と実行プランがクエリ内にまれにしか出現しないため、 `PLAN REPLAYER`を使用して文とプランを直接取得できない場合があります。このような場合、 `PLAN REPLAYER CAPTURE`を使用すると、対象となるSQL文と実行プランのオプティマイザー情報を取得できます。 `PLAN REPLAYER CAPTURE`は主に次の機能があります。 diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index ca01408c77a8b..6144379cf4028 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -8,7 +8,7 @@ summary: TiDB の SQL プリペアドプランキャッシュについて学習 TiDBは、 `Prepare`と`Execute`クエリの実行プランのキャッシュをサポートしています。これには、以下の2つの形式のプリペアドステートメントが含まれます。 - プロトコル機能`COM_STMT_PREPARE`および`COM_STMT_EXECUTE`使用。 -- SQL ステートメント`PREPARE`と`EXECUTE`使用します。 +- SQL ステートメント`PREPARE`と`EXECUTE`を使用します。 TiDB オプティマイザーは、これら 2 種類のクエリを同じ方法で処理します。準備時に、パラメータ化されたクエリは AST (抽象構文ツリー) に解析され、キャッシュされます。その後の実行時に、保存された AST と特定のパラメータ値に基づいて実行プランが生成されます。 @@ -56,7 +56,7 @@ LRUリンクリストは、 `Prepare` / `Execute`セッションをまたいで - 実行プランは、キャッシュされているかどうかに関わらず、SQLバインディングの影響を受けます。キャッシュされていない実行プラン（最初の`Execute` ）は、既存のSQLバインディングの影響を受けます。キャッシュされている実行プランは、新しいSQLバインディングが作成されると無効になります。 - キャッシュされたプランは、統計、最適化ルール、式によるブロックリストのプッシュダウンの変更の影響を受けません。 - `Execute`のパラメータが異なることを考慮し、実行プランキャッシュは、適応性を確保するために、特定のパラメータ値に密接に関連する一部の積極的なクエリ最適化手法を禁止します。これにより、クエリプランが特定のパラメータ値に対して最適にならない可能性があります。例えば、クエリのフィルタ条件が`where a > ? And a < ?`で、最初の`Execute`ステートメントのパラメータがそれぞれ`2`と`1`あるとします。これらの 2 つのパラメータが次回の実行時に`1`と`2`なる可能性があることを考慮すると、オプティマイザは現在のパラメータ値に固有の最適な`TableDual`実行プランを生成しません。 -- キャッシュの無効化と削除を考慮しない場合、実行プラン キャッシュはさまざまなパラメーター値に適用され、理論上は特定の値に対して最適ではない実行プランが生成されます。たとえば、フィルター条件が`where a < ?`で、最初の実行に使用されたパラメーター値が`1`の場合、オプティマイザーは最適な`IndexScan`実行プランを生成し、それをキャッシュに格納します。後続の実行で値が`10000`になった場合、 `TableScan`プランの方が適している可能性があります。ただし、実行プラン キャッシュがあるため、以前に生成された`IndexScan`使用して実行されます。そのため、実行プラン キャッシュは、クエリが単純 (コンパイル率が高い) で実行プランが比較的固定されているアプリケーション シナリオに適しています。 +- キャッシュの無効化と削除を考慮しない場合、実行プラン キャッシュはさまざまなパラメーター値に適用され、理論上は特定の値に対して最適ではない実行プランが生成されます。たとえば、フィルター条件が`where a < ?`で、最初の実行に使用されたパラメーター値が`1`の場合、オプティマイザーは最適な`IndexScan`実行プランを生成し、それをキャッシュに格納します。後続の実行で値が`10000`になった場合、 `TableScan`プランの方が適している可能性があります。ただし、実行プラン キャッシュがあるため、以前に生成された`IndexScan`を使用して実行されます。そのため、実行プラン キャッシュは、クエリが単純 (コンパイル率が高い) で実行プランが比較的固定されているアプリケーション シナリオに適しています。 バージョン6.1.0以降、実行プランキャッシュはデフォルトで有効になっています。プリペアドプランキャッシュはシステム変数[`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610)を介して制御できます。 @@ -128,7 +128,7 @@ MySQL [test]> select @@last_plan_from_cache; ### SHOW WARNINGSを使用して診断する {#use-code-show-warnings-code-to-diagnose} -一部のクエリまたはプランはキャッシュできません。1 ステートメント`SHOW WARNINGS`使用して、クエリまたはプランがキャッシュされているかどうかを確認できます。キャッシュされていない場合は、結果で失敗の理由を確認できます。例: +一部のクエリまたはプランはキャッシュできません。1 ステートメント`SHOW WARNINGS`を使用して、クエリまたはプランがキャッシュされているかどうかを確認できます。キャッシュされていない場合は、結果で失敗の理由を確認できます。例: ```sql mysql> PREPARE st FROM 'SELECT * FROM t WHERE a > (SELECT MAX(a) FROM t)'; -- The query contains a subquery and cannot be cached. @@ -289,7 +289,7 @@ ERROR 1105 (HY000): Do not support the 'admin flush global scope.' ## COM_STMT_CLOSEコマンドとDEALLOCATE PREPAREステートメントを無視します。 {#ignore-the-code-com-stmt-close-code-command-and-the-code-deallocate-prepare-code-statement} -SQL ステートメントの構文解析コストを削減するには、 `prepare stmt` 1 回実行し、次に`execute stmt`複数回実行してから`deallocate prepare`実行することをお勧めします。 +SQL ステートメントの構文解析コストを削減するには、 `prepare stmt` 1 回実行し、次に`execute stmt`複数回実行してから`deallocate prepare`を実行することをお勧めします。 ```sql MySQL [test]> prepare stmt from '...'; -- Prepare once @@ -299,7 +299,7 @@ MySQL [test]> execute stmt using ...; -- Execute multiple times MySQL [test]> deallocate prepare stmt; -- Release the prepared statement ``` -実際の練習では、以下に示すように、 `execute stmt`実行した後、毎回`deallocate prepare`実行することに慣れているかもしれません。 +実際の練習では、以下に示すように、 `execute stmt`を実行した後、毎回`deallocate prepare`を実行することに慣れているかもしれません。 ```sql MySQL [test]> prepare stmt from '...'; -- Prepare once diff --git a/sql-statements/sql-statement-admin-bdr-role.md b/sql-statements/sql-statement-admin-bdr-role.md index d351c3e6ae370..6decf7d249ca3 100644 --- a/sql-statements/sql-statement-admin-bdr-role.md +++ b/sql-statements/sql-statement-admin-bdr-role.md @@ -5,9 +5,9 @@ summary: TiDB データベースの ADMIN [SET|SHOW|UNSET] BDR ROLE の使用法 # ADMIN [SET|SHOW|UNSET] BDR ROLE {#admin-set-show-unset-bdr-role} -- クラスターのBDRロールを設定するには、 `ADMIN SET BDR ROLE`使用します。現在、TiDBクラスターには`PRIMARY`と`SECONDARY` BDRロールを設定できます。BDRロールの詳細については、 [TiCDC 双方向レプリケーションにおける DDL 同期](/ticdc/ticdc-bidirectional-replication.md#ddl-replication)参照してください。 -- クラスターの BDR ロールを表示するには、 `ADMIN SHOW BDR ROLE`使用します。 -- クラスターの BDR ロールを設定解除するには、 `ADMIN UNSET BDR ROLE`使用します。 +- クラスターのBDRロールを設定するには、 `ADMIN SET BDR ROLE`を使用します。現在、TiDBクラスターには`PRIMARY`と`SECONDARY` BDRロールを設定できます。BDRロールの詳細については、 [TiCDC 双方向レプリケーションにおける DDL 同期](/ticdc/ticdc-bidirectional-replication.md#ddl-replication)参照してください。 +- クラスターの BDR ロールを表示するには、 `ADMIN SHOW BDR ROLE`を使用します。 +- クラスターの BDR ロールを設定解除するには、 `ADMIN UNSET BDR ROLE`を使用します。 ## 概要 {#synopsis} diff --git a/sql-statements/sql-statement-admin-cancel-ddl.md b/sql-statements/sql-statement-admin-cancel-ddl.md index 79d4ea26cfd43..3eef7f4c123be 100644 --- a/sql-statements/sql-statement-admin-cancel-ddl.md +++ b/sql-statements/sql-statement-admin-cancel-ddl.md @@ -22,7 +22,7 @@ NumList ::= ## 例 {#examples} -現在実行中の DDL ジョブをキャンセルし、対応するジョブが正常にキャンセルされたかどうかを返すには、 `ADMIN CANCEL DDL JOBS`使用します。 +現在実行中の DDL ジョブをキャンセルし、対応するジョブが正常にキャンセルされたかどうかを返すには、 `ADMIN CANCEL DDL JOBS`を使用します。 ```sql ADMIN CANCEL DDL JOBS job_id [, job_id] ...; diff --git a/sql-statements/sql-statement-admin-check-table-index.md b/sql-statements/sql-statement-admin-check-table-index.md index 7985957f2df68..64bd71800db73 100644 --- a/sql-statements/sql-statement-admin-check-table-index.md +++ b/sql-statements/sql-statement-admin-check-table-index.md @@ -39,7 +39,7 @@ HandleRange ::= '(' Int64Num ',' Int64Num ')' ## 例 {#examples} -`tbl_name`テーブル内のすべてのデータと対応するインデックスの一貫性をチェックするには、 `ADMIN CHECK TABLE`使用します。 +`tbl_name`テーブル内のすべてのデータと対応するインデックスの一貫性をチェックするには、 `ADMIN CHECK TABLE`を使用します。 ```sql ADMIN CHECK TABLE tbl_name [, tbl_name] ...; diff --git a/sql-statements/sql-statement-admin-resume-ddl.md b/sql-statements/sql-statement-admin-resume-ddl.md index 2bf17694b63fe..f24b2415ceefd 100644 --- a/sql-statements/sql-statement-admin-resume-ddl.md +++ b/sql-statements/sql-statement-admin-resume-ddl.md @@ -5,7 +5,7 @@ summary: TiDB データベースの ADMIN RESUME DDL の使用法の概要。 # ADMIN RESUME DDL JOBS {#admin-resume-ddl-jobs} -`ADMIN RESUME DDL`使用すると、一時停止中のDDLジョブを再開できます。`job_id` [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)実行すると確認できます。 +`ADMIN RESUME DDL`を使用すると、一時停止中のDDLジョブを再開できます。`job_id` [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)実行すると確認できます。 このステートメントを使用すると、一時停止中のDDLジョブを再開できます。再開が完了した後も、DDLジョブを実行するSQL文は実行中として表示されます。すでに完了しているDDLジョブを再開しようとすると、列`RESULT`にエラー`DDL Job:90 not found`が表示されます。これは、ジョブがDDL待機キューから削除されたことを示します。 diff --git a/sql-statements/sql-statement-admin-show-ddl.md b/sql-statements/sql-statement-admin-show-ddl.md index 742ed21e6f504..efd83ea7bc3d1 100644 --- a/sql-statements/sql-statement-admin-show-ddl.md +++ b/sql-statements/sql-statement-admin-show-ddl.md @@ -29,7 +29,7 @@ WhereClauseOptional ::= ### `ADMIN SHOW DDL` {#admin-show-ddl} -現在実行中のDDLジョブのステータスを表示するには、 `ADMIN SHOW DDL`使用します。出力には、現在のスキーマバージョン、DDL IDと所有者のアドレス、実行中のDDLジョブとSQL文、現在のTiDBインスタンスのDDL IDが含まれます。返される結果フィールドは以下のとおりです。 +現在実行中のDDLジョブのステータスを表示するには、 `ADMIN SHOW DDL`を使用します。出力には、現在のスキーマバージョン、DDL IDと所有者のアドレス、実行中のDDLジョブとSQL文、現在のTiDBインスタンスのDDL IDが含まれます。返される結果フィールドは以下のとおりです。 - `SCHEMA_VER` : スキーマのバージョンを示す数値。 - `OWNER_ID` : DDL所有者のUUID。2 [`TIDB_IS_DDL_OWNER()`](/functions-and-operators/tidb-functions.md)参照してください。 @@ -96,7 +96,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `DXF` : [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)で構成された Distributed eXecution Framework (DXF) を使用して実行されるタスク。 - `service_scope` : [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)で設定された TiDB ノードのサービス スコープ。 - `thread` : バックフィルタスクの同時実行数。初期値は`tidb_ddl_reorg_worker_cnt`に設定できます。4 [`ADMIN ALTER DDL JOBS`](/sql-statements/sql-statement-admin-alter-ddl.md)指定することで動的な変更が可能です。 - - `batch_size` : バックフィルタスクのバッチサイズ。初期値は`tidb_ddl_reorg_batch_size`に設定できます。4 `ADMIN ALTER DDL JOBS`指定することで動的な変更が可能です。 + - `batch_size` : バックフィルタスクのバッチサイズ。初期値は`tidb_ddl_reorg_batch_size`に設定できます。4 `ADMIN ALTER DDL JOBS`を指定することで動的な変更が可能です。 - `max_write_speed` : インジェストタスクのインポート時のフロー制御。初期値は`tidb_ddl_reorg_max_write_speed`に設定できます。4 による動的な変更`ADMIN ALTER DDL JOBS`サポートされます。 @@ -173,7 +173,7 @@ ADMIN SHOW DDL JOBS [NUM] [WHERE where_condition]; ### `ADMIN SHOW DDL JOB QUERIES` {#admin-show-ddl-job-queries} -`job_id`に対応する DDL ジョブの元の SQL ステートメントを表示するには、 `ADMIN SHOW DDL JOB QUERIES`使用します。 +`job_id`に対応する DDL ジョブの元の SQL ステートメントを表示するには、 `ADMIN SHOW DDL JOB QUERIES`を使用します。 ```sql ADMIN SHOW DDL JOBS; @@ -194,7 +194,7 @@ DDL 履歴ジョブ キュー内の過去 10 件の結果のうち、 `job_id` ### `ADMIN SHOW DDL JOB QUERIES LIMIT m OFFSET n` {#admin-show-ddl-job-queries-limit-m-offset-n} -`job_id`に対応する指定された範囲`[n+1, n+m]`内の DDL ジョブの元の SQL ステートメントを表示するには、 `ADMIN SHOW DDL JOB QUERIES LIMIT m OFFSET n`使用します。 +`job_id`に対応する指定された範囲`[n+1, n+m]`内の DDL ジョブの元の SQL ステートメントを表示するには、 `ADMIN SHOW DDL JOB QUERIES LIMIT m OFFSET n`を使用します。 ```sql ADMIN SHOW DDL JOB QUERIES LIMIT m; # Retrieve first m rows diff --git a/sql-statements/sql-statement-alter-sequence.md b/sql-statements/sql-statement-alter-sequence.md index aff601ba453a8..591fb9fe8e478 100644 --- a/sql-statements/sql-statement-alter-sequence.md +++ b/sql-statements/sql-statement-alter-sequence.md @@ -60,7 +60,7 @@ ALTER SEQUENCE sequence_name > **注記：** > -> `START`値を変更しても、 `ALTER SEQUENCE ... RESTART`実行するまで生成された値には影響しません。 +> `START`値を変更しても、 `ALTER SEQUENCE ... RESTART`を実行するまで生成された値には影響しません。 ## SEQUENCE関数 {#code-sequence-code-function} diff --git a/sql-statements/sql-statement-alter-table.md b/sql-statements/sql-statement-alter-table.md index a2dea678f684a..cf12622957dba 100644 --- a/sql-statements/sql-statement-alter-table.md +++ b/sql-statements/sql-statement-alter-table.md @@ -170,7 +170,7 @@ TiDB の`ALTER TABLE`には次の主な制限が適用されます。 - 一部のデータ型 (たとえば、一部の TIME、Bit、Set、Enum、JSON 型) の変更は、TiDB と MySQL 間の`CAST`関数の動作の互換性の問題によりサポートされていません。 -- `AFFINITY`オプションは TiDB 拡張構文です。テーブルで`AFFINITY`有効にすると、パーティションの追加、削除、再編成、スワップなど、そのテーブルのパーティションスキームを変更できなくなります。パーティションスキームを変更するには、まず`AFFINITY`削除する必要があります。 +- `AFFINITY`オプションは TiDB 拡張構文です。テーブルで`AFFINITY`有効にすると、パーティションの追加、削除、再編成、スワップなど、そのテーブルのパーティションスキームを変更できなくなります。パーティションスキームを変更するには、まず`AFFINITY`を削除する必要があります。 - 空間データ型はサポートされていません。 diff --git a/sql-statements/sql-statement-analyze-table.md b/sql-statements/sql-statement-analyze-table.md index 2421bbbc05d64..0aa2be06c9723 100644 --- a/sql-statements/sql-statement-analyze-table.md +++ b/sql-statements/sql-statement-analyze-table.md @@ -5,7 +5,7 @@ summary: TiDB データベースに対する ANALYZE の使用法の概要。 # ANALYZE {#analyze} -このステートメントは、TiDBがテーブルとインデックスに対して構築する統計情報を更新します。大規模なバッチ更新またはレコードのインポートを実行した後、またはクエリ実行プランが最適ではないことに気付いた場合は、 `ANALYZE`実行することをお勧めします。 +このステートメントは、TiDBがテーブルとインデックスに対して構築する統計情報を更新します。大規模なバッチ更新またはレコードのインポートを実行した後、またはクエリ実行プランが最適ではないことに気付いた場合は、 `ANALYZE`を実行することをお勧めします。 TiDB は、統計が自身の推定値と一致していないことが判明すると、時間の経過とともに統計を自動的に更新します。 @@ -96,7 +96,7 @@ mysql> EXPLAIN SELECT * FROM t1 WHERE c1 = 3; TiDBは、収集する統計情報と、クエリ実行時に統計情報を利用する方法の**両方**においてMySQLとは異なります。この文は構文的にはMySQLに似ていますが、以下の違いがあります。 -- TiDBは、 `ANALYZE TABLE`実行時に、ごく最近コミットされた変更を反映させない可能性があります。行のバッチ更新後、統計情報の更新にこれらの変更を反映させるには、 `ANALYZE TABLE`実行する前に`sleep(1)`実行する必要がある場合があります[＃16570](https://github.com/pingcap/tidb/issues/16570)参照してください。 +- TiDBは、 `ANALYZE TABLE`実行時に、ごく最近コミットされた変更を反映させない可能性があります。行のバッチ更新後、統計情報の更新にこれらの変更を反映させるには、 `ANALYZE TABLE`を実行する前に`sleep(1)`を実行する必要がある場合があります[＃16570](https://github.com/pingcap/tidb/issues/16570)参照してください。 - `ANALYZE TABLE` 、MySQL よりも TiDB で実行するのに大幅に時間がかかります。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-batch.md b/sql-statements/sql-statement-batch.md index 43df6bde9f9a2..f094a2710f822 100644 --- a/sql-statements/sql-statement-batch.md +++ b/sql-statements/sql-statement-batch.md @@ -19,7 +19,7 @@ summary: TiDB データベースにおける BATCH の使用法の概要。 BATCH ON test.t2.id LIMIT 1 INSERT INTO t SELECT t2.id, t2.v, t3.v FROM t2 JOIN t3 ON t2.k = t3.k; ``` -上記の文では、分割する列を`test.t2.id`と指定しており、これは明確な値です。次のように`id`指定すると、エラーが発生します。 +上記の文では、分割する列を`test.t2.id`と指定しており、これは明確な値です。次のように`id`を指定すると、エラーが発生します。 ```sql BATCH ON id LIMIT 1 INSERT INTO t SELECT t2.id, t2.v, t3.v FROM t2 JOIN t3 ON t2.k = t3.k; diff --git a/sql-statements/sql-statement-calibrate-resource.md b/sql-statements/sql-statement-calibrate-resource.md index ef8fd002c0a68..82cff826b1b40 100644 --- a/sql-statements/sql-statement-calibrate-resource.md +++ b/sql-statements/sql-statement-calibrate-resource.md @@ -75,7 +75,7 @@ CALIBRATE RESOURCE START_TIME '2023-04-18 08:00:00' DURATION '20m'; 1 row in set (0.01 sec) ``` -実際のワークロードに応じて RU 容量を表示するには、開始時刻`START_TIME`と終了時刻`END_TIME`指定します。 +実際のワークロードに応じて RU 容量を表示するには、開始時刻`START_TIME`と終了時刻`END_TIME`を指定します。 ```sql CALIBRATE RESOURCE START_TIME '2023-04-18 08:00:00' END_TIME '2023-04-18 08:20:00'; @@ -110,7 +110,7 @@ CALIBRATE RESOURCE START_TIME '2023-04-18 08:00:00' DURATION '60m'; 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 ``` -RU容量を表示するには`WORKLOAD`指定します。デフォルト値は`TPCC`です。 +RU容量を表示するには`WORKLOAD`を指定します。デフォルト値は`TPCC`です。 ```sql CALIBRATE RESOURCE; diff --git a/sql-statements/sql-statement-create-binding.md b/sql-statements/sql-statement-create-binding.md index ad590f98be976..01a936ee2bd8f 100644 --- a/sql-statements/sql-statement-create-binding.md +++ b/sql-statements/sql-statement-create-binding.md @@ -310,7 +310,7 @@ Empty set (0.002 sec) ## SQL文の切り捨て {#sql-statement-truncation} -`CREATE BINDING ... FROM HISTORY USING PLAN DIGEST`使用すると、そのダイジェストの[ステートメントサマリーテーブル](/statement-summary-tables.md)に格納されているSQL文が[`tidb_stmt_summary_max_sql_length`](/system-variables.md#tidb_stmt_summary_max_sql_length-new-in-v40)より長いために切り捨てられ、バインディングが失敗する可能性があります。この場合、 `tidb_stmt_summary_max_sql_length`増やす必要があります。 +`CREATE BINDING ... FROM HISTORY USING PLAN DIGEST`を使用すると、そのダイジェストの[ステートメントサマリーテーブル](/statement-summary-tables.md)に格納されているSQL文が[`tidb_stmt_summary_max_sql_length`](/system-variables.md#tidb_stmt_summary_max_sql_length-new-in-v40)より長いために切り捨てられ、バインディングが失敗する可能性があります。この場合、 `tidb_stmt_summary_max_sql_length`増やす必要があります。 ## 権限 {#permissions} diff --git a/sql-statements/sql-statement-create-database.md b/sql-statements/sql-statement-create-database.md index 49f131e5c9015..16deaa9851e34 100644 --- a/sql-statements/sql-statement-create-database.md +++ b/sql-statements/sql-statement-create-database.md @@ -47,9 +47,9 @@ create_specification: | [DEFAULT] COLLATE [=] collation_name ``` -既存のデータベースを作成し、 `IF NOT EXISTS`指定しないと、エラーが表示されます。 +既存のデータベースを作成し、 `IF NOT EXISTS`を指定しないと、エラーが表示されます。 -`create_specification`オプションは、データベース内の特定の`CHARACTER SET`と`COLLATE`指定するために使用されます。現在、TiDB は一部の文字セットと照合順序のみをサポートしています。詳細については、 [文字セットと照合順序のサポート](/character-set-and-collation.md)参照してください。 +`create_specification`オプションは、データベース内の特定の`CHARACTER SET`と`COLLATE`を指定するために使用されます。現在、TiDB は一部の文字セットと照合順序のみをサポートしています。詳細については、 [文字セットと照合順序のサポート](/character-set-and-collation.md)参照してください。 ## 例 {#examples} diff --git a/sql-statements/sql-statement-create-role.md b/sql-statements/sql-statement-create-role.md index 8164cff23d05b..b5ca97d7261f3 100644 --- a/sql-statements/sql-statement-create-role.md +++ b/sql-statements/sql-statement-create-role.md @@ -50,7 +50,7 @@ Query OK, 0 rows affected (0.01 sec) mysql -h 127.0.0.1 -P 4000 -u jennifer ``` -デフォルトでは、 `analyticsteam`ロールに関連付けられた権限を使用できるようにするには、 `jennifer` `SET ROLE analyticsteam`実行する必要があることに注意してください。 +デフォルトでは、 `analyticsteam`ロールに関連付けられた権限を使用できるようにするには、 `jennifer` `SET ROLE analyticsteam`を実行する必要があることに注意してください。 ```sql SHOW GRANTS; @@ -105,7 +105,7 @@ Query OK, 0 rows affected (0.02 sec) mysql -h 127.0.0.1 -P 4000 -u jennifer ``` -この後、ユーザー`jennifer`ロール`analyticsteam`に関連付け`jennifer`た権限を持ち、ステートメント`SET ROLE`実行する必要がなくなります。 +この後、ユーザー`jennifer`ロール`analyticsteam`に関連付け`jennifer`た権限を持ち、ステートメント`SET ROLE`を実行する必要がなくなります。 ```sql SHOW GRANTS; diff --git a/sql-statements/sql-statement-create-sequence.md b/sql-statements/sql-statement-create-sequence.md index 74b640171989c..08eb222225db9 100644 --- a/sql-statements/sql-statement-create-sequence.md +++ b/sql-statements/sql-statement-create-sequence.md @@ -190,7 +190,7 @@ CREATE [TEMPORARY] SEQUENCE [IF NOT EXISTS] sequence_name +-----------------+ 1 row in set (0.00 sec) -- `NEXTVAL()`使用して次の値を取得する場合、次の値はシーケンスによって定義された等差数列の規則に従います。 +- `NEXTVAL()`を使用して次の値を取得する場合、次の値はシーケンスによって定義された等差数列の規則に従います。 ```sql SELECT next value for seq2; diff --git a/sql-statements/sql-statement-do.md b/sql-statements/sql-statement-do.md index 2d468fea05512..b82c7e3f1f191 100644 --- a/sql-statements/sql-statement-do.md +++ b/sql-statements/sql-statement-do.md @@ -9,7 +9,7 @@ summary: TiDB データベースにおける DO の使用法の概要。 > **注記：** > -> `DO`式のみを実行します。2 `SELECT`使用できるすべてのケースで使用できるわけではありません。例えば、 `DO id FROM t1`テーブルを参照するため無効です。 +> `DO`式のみを実行します。2 `SELECT`を使用できるすべてのケースで使用できるわけではありません。例えば、 `DO id FROM t1`テーブルを参照するため無効です。 MySQLでは、ストアドプロシージャやトリガーの実行が一般的なユースケースです。TiDBはストアドプロシージャやトリガーを提供していないため、この機能の用途は限定されます。 diff --git a/sql-statements/sql-statement-drop-role.md b/sql-statements/sql-statement-drop-role.md index 5639d9e99b2f1..5b9b6a507ee8d 100644 --- a/sql-statements/sql-statement-drop-role.md +++ b/sql-statements/sql-statement-drop-role.md @@ -47,7 +47,7 @@ Query OK, 0 rows affected (0.01 sec) mysql -h 127.0.0.1 -P 4000 -u jennifer ``` -デフォルトでは、 `analyticsteam`ロールに関連付けられた権限を使用できるようにするには、 `jennifer` `SET ROLE analyticsteam`実行する必要があることに注意してください。 +デフォルトでは、 `analyticsteam`ロールに関連付けられた権限を使用できるようにするには、 `jennifer` `SET ROLE analyticsteam`を実行する必要があることに注意してください。 ```sql SHOW GRANTS; @@ -102,7 +102,7 @@ Query OK, 0 rows affected (0.02 sec) mysql -h 127.0.0.1 -P 4000 -u jennifer ``` -この後、ユーザー`jennifer`ロール`analyticsteam`に関連付け`jennifer`た権限を持ち、ステートメント`SET ROLE`実行する必要がなくなります。 +この後、ユーザー`jennifer`ロール`analyticsteam`に関連付け`jennifer`た権限を持ち、ステートメント`SET ROLE`を実行する必要がなくなります。 ```sql SHOW GRANTS; diff --git a/sql-statements/sql-statement-drop-table.md b/sql-statements/sql-statement-drop-table.md index dd20c82abb839..98b31c530506d 100644 --- a/sql-statements/sql-statement-drop-table.md +++ b/sql-statements/sql-statement-drop-table.md @@ -28,9 +28,9 @@ TableNameList ::= 通常のテーブルと一時テーブルを削除するには、次の構文を使用できます。 -- ローカル一時テーブルを削除するには`DROP TEMPORARY TABLE`使用します。 -- グローバル一時テーブルを削除するには`DROP GLOBAL TEMPORARY TABLE`使用します。 -- 通常のテーブルまたは一時テーブルを削除するには、 `DROP TABLE`使用します。 +- ローカル一時テーブルを削除するには`DROP TEMPORARY TABLE`を使用します。 +- グローバル一時テーブルを削除するには`DROP GLOBAL TEMPORARY TABLE`を使用します。 +- 通常のテーブルまたは一時テーブルを削除するには、 `DROP TABLE`を使用します。 ## 例 {#examples} diff --git a/sql-statements/sql-statement-drop-user.md b/sql-statements/sql-statement-drop-user.md index 0a14d0d3c48e3..160fe7f75649d 100644 --- a/sql-statements/sql-statement-drop-user.md +++ b/sql-statements/sql-statement-drop-user.md @@ -5,7 +5,7 @@ summary: TiDB データベースの DROP USER の使用法の概要。 # DROP USER {#drop-user} -この文は、TiDBシステムデータベースからユーザーを削除します。オプションのキーワード`IF EXISTS`使用すると、ユーザーが存在しない場合にエラーを出力しません。この文には`CREATE USER`権限が必要です。 +この文は、TiDBシステムデータベースからユーザーを削除します。オプションのキーワード`IF EXISTS`を使用すると、ユーザーが存在しない場合にエラーを出力しません。この文には`CREATE USER`権限が必要です。 ## 概要 {#synopsis} diff --git a/sql-statements/sql-statement-explain-analyze.md b/sql-statements/sql-statement-explain-analyze.md index 3eb85e47b473f..e03d2d3ed5de6 100644 --- a/sql-statements/sql-statement-explain-analyze.md +++ b/sql-statements/sql-statement-explain-analyze.md @@ -5,11 +5,11 @@ summary: TiDB データベースのEXPLAIN ANALYZE の使用法の概要。 # EXPLAIN ANALYZE {#explain-analyze} -`EXPLAIN ANALYZE`文は`EXPLAIN`と似た動作をしますが、大きな違いは実際に文を実行する点です。これにより、クエリプランニングに使用された推定値と、実行時に検出された実際の値を比較できます。推定値が実際の値と大きく異なる場合は、影響を受けるテーブルに対して`ANALYZE TABLE`実行することを検討してください。 +`EXPLAIN ANALYZE`文は`EXPLAIN`と似た動作をしますが、大きな違いは実際に文を実行する点です。これにより、クエリプランニングに使用された推定値と、実行時に検出された実際の値を比較できます。推定値が実際の値と大きく異なる場合は、影響を受けるテーブルに対して`ANALYZE TABLE`を実行することを検討してください。 > **注記：** > -> `EXPLAIN ANALYZE`使用してDML文を実行すると、データの変更が正常に実行されます。現時点では、DML文の実行プランはまだ表示**できません**。 +> `EXPLAIN ANALYZE`を使用してDML文を実行すると、データの変更が正常に実行されます。現時点では、DML文の実行プランはまだ表示**できません**。 ## 概要 {#synopsis} diff --git a/sql-statements/sql-statement-explain.md b/sql-statements/sql-statement-explain.md index c78d51472761e..87646454a324b 100644 --- a/sql-statements/sql-statement-explain.md +++ b/sql-statements/sql-statement-explain.md @@ -5,7 +5,7 @@ summary: TiDB データベースにおけるEXPLAINの使用法の概要。 # `EXPLAIN` {#explain} -`EXPLAIN`の文は、クエリを実行せずにその実行プランを表示します。これは、クエリを実行する`EXPLAIN ANALYZE`の文を補完するものです。5 `EXPLAIN`出力が期待される結果と一致しない場合は、クエリ内の各テーブルに対して`ANALYZE TABLE`実行して、テーブル統計が最新であることを確認することを検討してください。 +`EXPLAIN`の文は、クエリを実行せずにその実行プランを表示します。これは、クエリを実行する`EXPLAIN ANALYZE`の文を補完するものです。5 `EXPLAIN`出力が期待される結果と一致しない場合は、クエリ内の各テーブルに対して`ANALYZE TABLE`を実行して、テーブル統計が最新であることを確認することを検討してください。 > **注記：** > @@ -45,7 +45,7 @@ ExplainableStmt ::= > > 返される実行プランにおいて、 `IndexJoin`および`Apply`演算子のすべてのプローブ側子ノードについて、v6.4.0 以降では`estRows`の意味が v6.4.0 以前と異なります。詳細は[TiDB クエリ実行プランの概要](/explain-overview.md#understand-explain-output)を参照してください。 -現在、TiDBの`EXPLAIN`は5つの列（ `id` `estRows` `access object`出力します。実行プラン内の各演算子`task`これらの属性によって記述され、 `EXPLAIN`出力の各行は演算子`operator info`記述します。各属性の説明は次のとおりです。 +現在、TiDBの`EXPLAIN`は5つの列（ `id` `estRows` `access object`を出力します。実行プラン内の各演算子`task`これらの属性によって記述され、 `EXPLAIN`出力の各行は演算子`operator info`記述します。各属性の説明は次のとおりです。 | 属性名 | 説明 | | :--------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -211,7 +211,7 @@ EXPLAIN FORMAT = "brief" DELETE FROM t1 WHERE c1 = 3;
    -MySQL 標準の結果形式に加えて、TiDB は DotGraph もサポートしており、次の例のように`FORMAT = "dot"`指定する必要があります。 +MySQL 標準の結果形式に加えて、TiDB は DotGraph もサポートしており、次の例のように`FORMAT = "dot"`を指定する必要があります。 ```sql CREATE TABLE t(a bigint, b bigint); @@ -269,7 +269,7 @@ The xx.dot is the result returned by the above statement.
    -JSON形式で出力を取得するには、 `EXPLAIN`ステートメントに`FORMAT = "tidb_json"`指定します。以下は例です。 +JSON形式で出力を取得するには、 `EXPLAIN`ステートメントに`FORMAT = "tidb_json"`を指定します。以下は例です。 ```sql CREATE TABLE t(id int primary key, a int, b int, key(a)); diff --git a/sql-statements/sql-statement-flashback-database.md b/sql-statements/sql-statement-flashback-database.md index 13d373803deb8..42606453d0cf8 100644 --- a/sql-statements/sql-statement-flashback-database.md +++ b/sql-statements/sql-statement-flashback-database.md @@ -5,7 +5,7 @@ summary: TiDB データベースでの FLASHBACK DATABASE の使用方法を学 # FLASHBACK DATABASE {#flashback-database} -TiDB v6.4.0 では`FLASHBACK DATABASE`構文が導入されました。`FLASHBACK DATABASE`使用すると、ガベージコレクション (GC) の有効期間内に`DROP`ステートメントによって削除されたデータベースとそのデータを復元できます。 +TiDB v6.4.0 では`FLASHBACK DATABASE`構文が導入されました。`FLASHBACK DATABASE`を使用すると、ガベージコレクション (GC) の有効期間内に`DROP`ステートメントによって削除されたデータベースとそのデータを復元できます。 履歴データの保持期間は、システム変数[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)設定することで設定できます。デフォルト値は`10m0s`です。現在の`safePoint` 、つまりGCが実行された時点までを照会するには、次のSQL文を使用します。 @@ -13,7 +13,7 @@ TiDB v6.4.0 では`FLASHBACK DATABASE`構文が導入されました。`FLASHBAC SELECT * FROM mysql.tidb WHERE variable_name = 'tikv_gc_safe_point'; ``` -`tikv_gc_safe_point`回目以降に`DROP`でデータベースが削除されていれば、 `FLASHBACK DATABASE`使用してデータベースを復元できます。 +`tikv_gc_safe_point`回目以降に`DROP`でデータベースが削除されていれば、 `FLASHBACK DATABASE`を使用してデータベースを復元できます。 ## 構文 {#syntax} diff --git a/sql-statements/sql-statement-flashback-table.md b/sql-statements/sql-statement-flashback-table.md index b230ed0a096ee..69d46642b416e 100644 --- a/sql-statements/sql-statement-flashback-table.md +++ b/sql-statements/sql-statement-flashback-table.md @@ -5,7 +5,7 @@ summary: FLASHBACK TABLE` ステートメントを使用してテーブルを回 # FLASHBACK TABLE {#flashback-table} -`FLASHBACK TABLE`構文は TiDB 4.0 以降で導入されました。ステートメント`FLASHBACK TABLE`使用すると、ガベージコレクション (GC) の有効期間中に`DROP`または`TRUNCATE`操作によって削除されたテーブルとデータを復元できます。 +`FLASHBACK TABLE`構文は TiDB 4.0 以降で導入されました。ステートメント`FLASHBACK TABLE`を使用すると、ガベージコレクション (GC) の有効期間中に`DROP`または`TRUNCATE`操作によって削除されたテーブルとデータを復元できます。 システム変数[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50) （デフォルト: `10m0s` ）は、以前のバージョンの行の保持期間を定義します。ガベージコレクションが実行された現在の`safePoint`間は、次のクエリで取得できます。 diff --git a/sql-statements/sql-statement-grant-role.md b/sql-statements/sql-statement-grant-role.md index 22f481fb39109..6bc9e53d42689 100644 --- a/sql-statements/sql-statement-grant-role.md +++ b/sql-statements/sql-statement-grant-role.md @@ -5,7 +5,7 @@ summary: TiDB データベースに対する GRANT の使用法の概要 # `GRANT <role>` {#grant-x3c-role} -既存のユーザーに、以前に作成したロールを割り当てます。ユーザーは、ステートメント`SET ROLE `を使用してロールの権限を引き受けるか、ステートメント`SET ROLE ALL`使用して割り当てられているすべてのロールを引き受けることができます。 +既存のユーザーに、以前に作成したロールを割り当てます。ユーザーは、ステートメント`SET ROLE `を使用してロールの権限を引き受けるか、ステートメント`SET ROLE ALL`を使用して割り当てられているすべてのロールを引き受けることができます。 ## 概要 {#synopsis} @@ -50,7 +50,7 @@ Query OK, 0 rows affected (0.01 sec) mysql -h 127.0.0.1 -P 4000 -u jennifer ``` -デフォルトでは、 `analyticsteam`ロールに関連付けられた権限を使用できるようにするには、 `jennifer` `SET ROLE analyticsteam`実行する必要があることに注意してください。 +デフォルトでは、 `analyticsteam`ロールに関連付けられた権限を使用できるようにするには、 `jennifer` `SET ROLE analyticsteam`を実行する必要があることに注意してください。 ```sql SHOW GRANTS; @@ -105,7 +105,7 @@ Query OK, 0 rows affected (0.02 sec) mysql -h 127.0.0.1 -P 4000 -u jennifer ``` -この後、ユーザー`jennifer`ロール`analyticsteam`に関連付け`jennifer`た権限を持ち、ステートメント`SET ROLE`実行する必要がなくなります。 +この後、ユーザー`jennifer`ロール`analyticsteam`に関連付け`jennifer`た権限を持ち、ステートメント`SET ROLE`を実行する必要がなくなります。 ```sql SHOW GRANTS; diff --git a/sql-statements/sql-statement-import-into.md b/sql-statements/sql-statement-import-into.md index 55a01714138bb..7be8463fb1995 100644 --- a/sql-statements/sql-statement-import-into.md +++ b/sql-statements/sql-statement-import-into.md @@ -341,7 +341,7 @@ IMPORT INTO t FROM 's3://bucket/path/to/file.parquet?access-key=XXX&secret-acces ## IMPORT INTO ... FROM SELECT使用法 {#code-import-into-from-select-code-usage} -`IMPORT INTO ... FROM SELECT`使用すると`SELECT`ステートメントのクエリ結果を TiDB の空のテーブルにインポートできます。また、 [`AS OF TIMESTAMP`](/as-of-timestamp.md)でクエリされた履歴データをインポートするためにも使用できます。 +`IMPORT INTO ... FROM SELECT`を使用すると`SELECT`ステートメントのクエリ結果を TiDB の空のテーブルにインポートできます。また、 [`AS OF TIMESTAMP`](/as-of-timestamp.md)でクエリされた履歴データをインポートするためにも使用できます。 ### SELECTクエリの結果をインポートします {#import-the-query-result-of-code-select-code} diff --git a/sql-statements/sql-statement-load-data.md b/sql-statements/sql-statement-load-data.md index da70369787ac6..e8414ee133e36 100644 --- a/sql-statements/sql-statement-load-data.md +++ b/sql-statements/sql-statement-load-data.md @@ -46,7 +46,7 @@ Fields ::= ### `LOCAL` {#local} -`LOCAL`使用して、インポートするクライアント上のデータ ファイルを指定できます。ファイル パラメーターは、クライアント上のファイル システム パスである必要があります。 +`LOCAL`を使用して、インポートするクライアント上のデータ ファイルを指定できます。ファイル パラメーターは、クライアント上のファイル システム パスである必要があります。 TiDB Cloudを使用している場合、 `LOAD DATA`ステートメントを使用してローカル データ ファイルをロードするには、 TiDB Cloudに接続するときに接続文字列に`--local-infile`オプションを追加する必要があります。 @@ -60,7 +60,7 @@ TiDB Cloudを使用している場合、 `LOAD DATA`ステートメントを使 ### REPLACEとIGNORE {#code-replace-code-and-code-ignore-code} -`REPLACE`と`IGNORE`使用して、重複データの処理方法を指定できます。 +`REPLACE`と`IGNORE`を使用して、重複データの処理方法を指定できます。 - `REPLACE` : 既存のデータは上書きされます。 - `IGNORE` : 重複行は無視され、既存のデータは保持されます。 @@ -71,13 +71,13 @@ TiDB Cloudを使用している場合、 `LOAD DATA`ステートメントを使 -`LOCAL`指定しない場合は、 [外部ストレージ](/br/backup-and-restore-storages.md)で詳述されているように、ファイル パラメータは有効な S3 または GCS パスである必要があります。 +`LOCAL`を指定しない場合は、 [外部ストレージ](/br/backup-and-restore-storages.md)で詳述されているように、ファイル パラメータは有効な S3 または GCS パスである必要があります。 -`LOCAL`指定しない場合は、 [外部ストレージ](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)で詳述されているように、ファイル パラメータは有効な S3 または GCS パスである必要があります。 +`LOCAL`を指定しない場合は、 [外部ストレージ](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)で詳述されているように、ファイル パラメータは有効な S3 または GCS パスである必要があります。 @@ -97,11 +97,11 @@ TiDB Cloudを使用している場合、 `LOAD DATA`ステートメントを使 - `FIELDS ENCLOSED BY` : データの囲み文字を指定します。 - `LINES TERMINATED BY` : 特定の文字で行を終了する場合に、行末文字を指定します。 -`DEFINED NULL BY`使用すると、データ ファイル内で NULL 値をどのように表現するかを指定できます。 +`DEFINED NULL BY`を使用すると、データ ファイル内で NULL 値をどのように表現するかを指定できます。 - MySQL の動作と一致して、 `ESCAPED BY` NULL でない場合、たとえばデフォルト値`\`使用されると、 `\N` NULL 値と見なされます。 -- `DEFINED NULL BY 'my-null'`ように`DEFINED NULL BY`使用すると、 `my-null` NULL 値と見なされます。 -- `DEFINED NULL BY ... OPTIONALLY ENCLOSED`使用する場合、 `DEFINED NULL BY 'my-null' OPTIONALLY ENCLOSED` 、 `my-null` 、 `"my-null"` ( `ENCLOSED BY '"`仮定) は NULL 値と見なされます。 +- `DEFINED NULL BY 'my-null'`ように`DEFINED NULL BY`を使用すると、 `my-null` NULL 値と見なされます。 +- `DEFINED NULL BY ... OPTIONALLY ENCLOSED`を使用する場合、 `DEFINED NULL BY 'my-null' OPTIONALLY ENCLOSED` 、 `my-null` 、 `"my-null"` ( `ENCLOSED BY '"`仮定) は NULL 値と見なされます。 - `DEFINED NULL BY`や`DEFINED NULL BY ... OPTIONALLY ENCLOSED`ではなく`ENCLOSED BY` （例えば`ENCLOSED BY '"'`を使用した場合、 `NULL` NULL 値とみなされます。この動作はMySQLと一致しています。 - それ以外の場合は、NULL 値とはみなされません。 diff --git a/sql-statements/sql-statement-lock-stats.md b/sql-statements/sql-statement-lock-stats.md index 4e63ce9ae9468..fe03f71e73d87 100644 --- a/sql-statements/sql-statement-lock-stats.md +++ b/sql-statements/sql-statement-lock-stats.md @@ -47,7 +47,7 @@ mysql> SHOW WARNINGS; 1 row in set (0.00 sec) ``` -テーブル`t`の統計情報をロックし、 `ANALYZE`実行します。 `SHOW STATS_LOCKED`の出力から、テーブル`t`の統計情報がロックされていることがわかります。警告メッセージは、 `ANALYZE`文がテーブル`t`をスキップしたことを示しています。 +テーブル`t`の統計情報をロックし、 `ANALYZE`を実行します。 `SHOW STATS_LOCKED`の出力から、テーブル`t`の統計情報がロックされていることがわかります。警告メッセージは、 `ANALYZE`文がテーブル`t`をスキップしたことを示しています。 ```sql mysql> LOCK STATS t; @@ -74,7 +74,7 @@ mysql> SHOW WARNINGS; 2 rows in set (0.00 sec) ``` -さらに、 `LOCK STATS`使用してパーティションの統計情報をロックすることもできます。例: +さらに、 `LOCK STATS`を使用してパーティションの統計情報をロックすることもできます。例: パーティションテーブル`t`を作成し、そこにデータを挿入します。パーティション`p1`の統計情報がロックされていない場合、 `ANALYZE`ステートメントは正常に実行できます。 @@ -103,7 +103,7 @@ mysql> SHOW WARNINGS; 6 rows in set (0.01 sec) ``` -パーティション`p1`の統計情報をロックし、 `ANALYZE`実行します。警告メッセージには、 `ANALYZE`文がパーティション`p1`スキップしたことが示されています。 +パーティション`p1`の統計情報をロックし、 `ANALYZE`を実行します。警告メッセージには、 `ANALYZE`文がパーティション`p1`スキップしたことが示されています。 ```sql mysql> LOCK STATS t PARTITION p1; diff --git a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md index 8bcd84048e00f..7e7a7836099ba 100644 --- a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md +++ b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md @@ -82,7 +82,7 @@ ERROR 1066 (42000): Not unique table/alias: 't' セッションによって保持されているテーブルロックが解放されると、それらはすべて同時に解放されます。セッションは、明示的または暗黙的にロックを解放できます。 -- セッションは`UNLOCK TABLES`使用して明示的にロックを解除できます。 +- セッションは`UNLOCK TABLES`を使用して明示的にロックを解除できます。 - セッションがすでにロックを保持しているときにロックを取得するために`LOCK TABLES`ステートメントを発行すると、新しいロックが取得される前に既存のロックが暗黙的に解放されます。 クライアントセッションの接続が正常終了か異常終了かにかかわらず終了した場合、TiDB はセッションで保持されていたすべてのテーブルロックを暗黙的に解放します。クライアントが再接続すると、ロックは無効になります。そのため、クライアント側で自動再接続を有効にすることは推奨されません。自動再接続を有効にすると、再接続が発生してもクライアントには通知されず、すべてのテーブルロックまたは現在のトランザクションが失われます。一方、自動再接続が無効になっている場合、接続が切断されると、次のステートメントが発行されるときにエラーが発生します。クライアントはエラーを検出し、ロックの再取得やトランザクションのやり直しなどの適切なアクションを実行できます。 diff --git a/sql-statements/sql-statement-recover-table.md b/sql-statements/sql-statement-recover-table.md index 6d2254c8a77bb..c4f1f21b057da 100644 --- a/sql-statements/sql-statement-recover-table.md +++ b/sql-statements/sql-statement-recover-table.md @@ -33,7 +33,7 @@ NUM ::= intLit > **注記：** > -> テーブルが削除され、GCの有効期間が過ぎた場合、 `RECOVER TABLE`ではテーブルを回復できません。このシナリオで`RECOVER TABLE`実行すると、 `snapshot is older than GC safe point 2019-07-10 13:45:57 +0800 CST`ようなエラーが返されます。 +> テーブルが削除され、GCの有効期間が過ぎた場合、 `RECOVER TABLE`ではテーブルを回復できません。このシナリオで`RECOVER TABLE`を実行すると、 `snapshot is older than GC safe point 2019-07-10 13:45:57 +0800 CST`ようなエラーが返されます。 ## 例 {#examples} @@ -51,7 +51,7 @@ NUM ::= intLit - 使用されたテーブル`DDL JOB ID`に応じて、削除されたテーブルを回復します。 - テーブル`t`削除して別の`t`を作成し、さらに新しく作成したテーブル`t`を削除したとします。この場合、最初に削除した`t`復元するには、テーブル`DDL JOB ID`指定するメソッドを使用する必要があります。 + テーブル`t`を削除して別の`t`を作成し、さらに新しく作成したテーブル`t`を削除したとします。この場合、最初に削除した`t`復元するには、テーブル`DDL JOB ID`を指定するメソッドを使用する必要があります。 ```sql DROP TABLE t; @@ -61,7 +61,7 @@ NUM ::= intLit ADMIN SHOW DDL JOBS 1; ``` - 上記の2番目のステートメントは、テーブルの`DDL JOB ID`を検索して`t`削除するために使用されます。次の例では、IDは`53`です。 + 上記の2番目のステートメントは、テーブルの`DDL JOB ID`を検索して`t`を削除するために使用されます。次の例では、IDは`53`です。 +--------+---------+------------+------------+--------------+-----------+----------+-----------+-----------------------------------+--------+ | JOB_ID | DB_NAME | TABLE_NAME | JOB_TYPE | SCHEMA_STATE | SCHEMA_ID | TABLE_ID | ROW_COUNT | START_TIME | STATE | diff --git a/sql-statements/sql-statement-restore.md b/sql-statements/sql-statement-restore.md index a833500ad4975..bea5a5a6775f2 100644 --- a/sql-statements/sql-statement-restore.md +++ b/sql-statements/sql-statement-restore.md @@ -12,7 +12,7 @@ summary: TiDBデータベースにおけるRESTOREの使用方法の概要。 > - この機能は実験的です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 > - この機能は、 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)インスタンスではご利用いただけません。 -`RESTORE`ステートメントは、 [BRツール](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview)と同じエンジンを使用しますが、リストア プロセスは別のBRツールではなく TiDB 自体によって実行されます。BR のすべての利点と注意点もここに適用されます。特に、 **`RESTORE`は現在ACID準拠ではありません**。 `RESTORE`実行する前に、次の要件が満たされていることを確認してください。 +`RESTORE`ステートメントは、 [BRツール](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview)と同じエンジンを使用しますが、リストア プロセスは別のBRツールではなく TiDB 自体によって実行されます。BR のすべての利点と注意点もここに適用されます。特に、 **`RESTORE`は現在ACID準拠ではありません**。 `RESTORE`を実行する前に、次の要件が満たされていることを確認してください。 - クラスターは「オフライン」状態であり、現在有効なTiDBセッションは、復元中のすべてのテーブルにアクセスできる唯一のアクティブなSQL接続です。 - 完全復元を実行する場合、復元対象のテーブルは既に存在してはなりません。既存のデータが上書きされ、データとインデックス間の不整合が発生する可能性があるためです。 diff --git a/sql-statements/sql-statement-revoke-role.md b/sql-statements/sql-statement-revoke-role.md index eee429642d2fb..a9762ecf6d7e0 100644 --- a/sql-statements/sql-statement-revoke-role.md +++ b/sql-statements/sql-statement-revoke-role.md @@ -50,7 +50,7 @@ Query OK, 0 rows affected (0.01 sec) mysql -h 127.0.0.1 -P 4000 -u jennifer ``` -デフォルトでは、 `analyticsteam`ロールに関連付けられた権限を使用できるようにするには、 `jennifer` `SET ROLE analyticsteam`実行する必要があることに注意してください。 +デフォルトでは、 `analyticsteam`ロールに関連付けられた権限を使用できるようにするには、 `jennifer` `SET ROLE analyticsteam`を実行する必要があることに注意してください。 ```sql SHOW GRANTS; @@ -105,7 +105,7 @@ Query OK, 0 rows affected (0.02 sec) mysql -h 127.0.0.1 -P 4000 -u jennifer ``` -この後、ユーザー`jennifer`ロール`analyticsteam`に関連付け`jennifer`た権限を持ち、ステートメント`SET ROLE`実行する必要がなくなります。 +この後、ユーザー`jennifer`ロール`analyticsteam`に関連付け`jennifer`た権限を持ち、ステートメント`SET ROLE`を実行する必要がなくなります。 ```sql SHOW GRANTS; diff --git a/sql-statements/sql-statement-savepoint.md b/sql-statements/sql-statement-savepoint.md index d0661deb2abf1..0d665cfe7dd85 100644 --- a/sql-statements/sql-statement-savepoint.md +++ b/sql-statements/sql-statement-savepoint.md @@ -15,7 +15,7 @@ RELEASE SAVEPOINT identifier > **警告：** > -> [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630)無効になっている場合、悲観的トランザクションで`SAVEPOINT`使用することはできません。 +> [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630)無効になっている場合、悲観的トランザクションで`SAVEPOINT`を使用することはできません。 - `SAVEPOINT` 、現在のトランザクションに指定された名前のセーブポイントを設定するために使用されます。同じ名前のセーブポイントが既に存在する場合、それは削除され、同じ名前の新しいセーブポイントが設定されます。 @@ -147,7 +147,7 @@ SELECT * FROM t1; ## MySQLの互換性 {#mysql-compatibility} -`ROLLBACK TO SAVEPOINT`使用してトランザクションを指定されたセーブポイントまでロールバックすると、MySQL は指定されたセーブポイント以降に保持されているロックのみを解放します。一方、TiDB の悲観的トランザクションでは、TiDB は指定されたセーブポイント以降に保持されているロックをすぐには解放しません。代わりに、TiDB はトランザクションがコミットまたはロールバックされた時点ですべてのロックを解放します。 +`ROLLBACK TO SAVEPOINT`を使用してトランザクションを指定されたセーブポイントまでロールバックすると、MySQL は指定されたセーブポイント以降に保持されているロックのみを解放します。一方、TiDB の悲観的トランザクションでは、TiDB は指定されたセーブポイント以降に保持されているロックをすぐには解放しません。代わりに、TiDB はトランザクションがコミットまたはロールバックされた時点ですべてのロックを解放します。 TiDB は MySQL 構文`ROLLBACK WORK TO SAVEPOINT ...`サポートしていません。 diff --git a/sql-statements/sql-statement-set-default-role.md b/sql-statements/sql-statement-set-default-role.md index d1bdd6c36572c..3c8eb50016f85 100644 --- a/sql-statements/sql-statement-set-default-role.md +++ b/sql-statements/sql-statement-set-default-role.md @@ -44,7 +44,7 @@ Query OK, 0 rows affected (0.01 sec) mysql -h 127.0.0.1 -P 4000 -u jennifer ``` -デフォルトでは、 `analyticsteam`ロールに関連付けられた権限を使用できるようにするには、 `jennifer` `SET ROLE analyticsteam`実行する必要があることに注意してください。 +デフォルトでは、 `analyticsteam`ロールに関連付けられた権限を使用できるようにするには、 `jennifer` `SET ROLE analyticsteam`を実行する必要があることに注意してください。 ```sql SHOW GRANTS; @@ -99,7 +99,7 @@ Query OK, 0 rows affected (0.02 sec) mysql -h 127.0.0.1 -P 4000 -u jennifer ``` -この後、ユーザー`jennifer`ロール`analyticsteam`に関連付け`jennifer`た権限を持ち、ステートメント`SET ROLE`実行する必要がなくなります。 +この後、ユーザー`jennifer`ロール`analyticsteam`に関連付け`jennifer`た権限を持ち、ステートメント`SET ROLE`を実行する必要がなくなります。 ```sql SHOW GRANTS; diff --git a/sql-statements/sql-statement-set-variable.md b/sql-statements/sql-statement-set-variable.md index ed8c3110bc765..7a6344d4d3363 100644 --- a/sql-statements/sql-statement-set-variable.md +++ b/sql-statements/sql-statement-set-variable.md @@ -71,7 +71,7 @@ mysql> SHOW SESSION VARIABLES LIKE 'sql_mode'; 1 row in set (0.00 sec) ``` -`SET SESSION`使用するとすぐに有効になります。 +`SET SESSION`を使用するとすぐに有効になります。 ```sql mysql> SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER'; @@ -110,7 +110,7 @@ SELECT @myvar, @myvar + 1; - グローバル変数: ほとんどのシステム変数 (たとえば、クラスターの動作やオプティマイザーの動作に影響するもの) の場合、 `SET GLOBAL`で行われた変更はクラスター内のすべての TiDB インスタンスに適用されます。 - インスタンス レベルの変数: 一部のシステム変数 (たとえば、 `max_connections` ) の場合、 `SET GLOBAL`で行われた変更は、現在の接続で使用されている TiDB インスタンスにのみ適用されます。 - したがって、 `SET GLOBAL`使用して変数を変更する場合は、常にその変数の[ドキュメント](/system-variables.md) 、特に「クラスターに保持」属性をチェックして、変更の範囲を確認してください。 + したがって、 `SET GLOBAL`を使用して変数を変更する場合は、常にその変数の[ドキュメント](/system-variables.md) 、特に「クラスターに保持」属性をチェックして、変更の範囲を確認してください。 - TiDBは、いくつかの変数を読み取りと設定の両方が可能としています。これは、アプリケーションとコネクタの両方がMySQL変数を読み取るのが一般的であるため、MySQLとの互換性を保つために必要です。例えば、JDBCコネクタは、その動作に依存していないにもかかわらず、クエリキャッシュ設定の読み取りと設定の両方を行います。 diff --git a/sql-statements/sql-statement-show-stats-healthy.md b/sql-statements/sql-statement-show-stats-healthy.md index 1799009c40e3d..7f2a8de8b9a65 100644 --- a/sql-statements/sql-statement-show-stats-healthy.md +++ b/sql-statements/sql-statement-show-stats-healthy.md @@ -31,7 +31,7 @@ ShowLikeOrWhere ::= ## 例 {#examples} -サンプルデータをロードして`ANALYZE`実行します。 +サンプルデータをロードして`ANALYZE`を実行します。 ```sql CREATE TABLE t1 ( diff --git a/sql-statements/sql-statement-show-stats-locked.md b/sql-statements/sql-statement-show-stats-locked.md index 554517baf55c4..324f24de69fcd 100644 --- a/sql-statements/sql-statement-show-stats-locked.md +++ b/sql-statements/sql-statement-show-stats-locked.md @@ -48,7 +48,7 @@ mysql> SHOW WARNINGS; 1 row in set (0.00 sec) ``` -テーブル`t`の統計情報をロックし、 `SHOW STATS_LOCKED`実行します。出力には、テーブル`t`の統計情報がロックされたことが示されます。 +テーブル`t`の統計情報をロックし、 `SHOW STATS_LOCKED`を実行します。出力には、テーブル`t`の統計情報がロックされたことが示されます。 ```sql mysql> LOCK STATS t; diff --git a/sql-statements/sql-statement-show-stats-meta.md b/sql-statements/sql-statement-show-stats-meta.md index 986b0f95481cf..767094c489e0e 100644 --- a/sql-statements/sql-statement-show-stats-meta.md +++ b/sql-statements/sql-statement-show-stats-meta.md @@ -5,7 +5,7 @@ summary: TiDB データベースの SHOW STATS_META の使用法の概要。 # SHOW STATS_META {#show-stats-meta} -`SHOW STATS_META`使用すると、テーブル内の行数と、そのテーブルで変更された行数を表示できます。このステートメントを使用する場合、 `ShowLikeOrWhere`句を使用して必要な情報をフィルタリングできます。 +`SHOW STATS_META`を使用すると、テーブル内の行数と、そのテーブルで変更された行数を表示できます。このステートメントを使用する場合、 `ShowLikeOrWhere`句を使用して必要な情報をフィルタリングできます。 現在、 `SHOW STATS_META`ステートメントは次の列を出力します。 diff --git a/sql-statements/sql-statement-show-tables.md b/sql-statements/sql-statement-show-tables.md index ddd6d494e28e0..8a643e2d80757 100644 --- a/sql-statements/sql-statement-show-tables.md +++ b/sql-statements/sql-statement-show-tables.md @@ -7,7 +7,7 @@ summary: TiDB データベースの SHOW [FULL] TABLES の使用法の概要。 このステートメントは、現在選択されているデータベース内のテーブルとビューのリストを表示します。オプションのキーワード`FULL`は、テーブルのタイプが`BASE TABLE`、`SEQUENCE`、または`VIEW`のいずれであるかを示します。 -別のデータベース内のテーブルを表示するには、 `SHOW TABLES IN DatabaseName`使用します。 +別のデータベース内のテーブルを表示するには、 `SHOW TABLES IN DatabaseName`を使用します。 ## 概要 {#synopsis} diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index 9e5140d35fe3f..146527b8f82ce 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -101,7 +101,7 @@ TiDBは、リテラルとバインド変数を`?`に置き換えることで、S - 最も遅い SQL クエリ。 - TiKV から最も多くのデータを読み取る SQL クエリ。 -- 詳細な実行分析を行うには、クエリをクリックして`EXPLAIN ANALYZE`出力します。 +- 詳細な実行分析を行うには、クエリをクリックして`EXPLAIN ANALYZE`を出力します。 **「スロークエリ」**ページにはSQL実行頻度は表示されません。クエリの実行時間が単一インスタンスの[`tidb_slow_log_threshold`](/tidb-configuration-file.md#tidb_slow_log_threshold)設定項目を超えた場合、このページにそのクエリが表示されます。 @@ -123,7 +123,7 @@ TiDB Dashboardに加えて、他のツールを使用してリソースを大量 PLAN REPLAYER DUMP EXPLAIN [ANALYZE] [WITH STATS AS OF TIMESTAMP expression] sql-statement; ``` -可能な限り`EXPLAIN ANALYZE`使用してください。これは、実行プランと実際のパフォーマンス メトリックの両方が提供され、クエリ パフォーマンスに関するより正確な分析情報が得られるためです。 +可能な限り`EXPLAIN ANALYZE`を使用してください。これは、実行プランと実際のパフォーマンス メトリックの両方が提供され、クエリ パフォーマンスに関するより正確な分析情報が得られるためです。 ## SQLチューニングガイド {#sql-tuning-guide} @@ -399,7 +399,7 @@ FROM ( 実行計画を読む際は、上から下に向かって読み進めてください。次の例では、計画ツリーのリーフノードは`TableFullScan_18`で、テーブル全体のスキャンを実行します。このスキャンで得られた行は`Selection_19`演算子によって使用され、 `ge(trips.start_date, 2017-07-01 00:00:00.000000), le(trips.start_date, 2017-07-01 23:59:59.000000)`に基づいてデータがフィルタリングされます。その後、 group-by 演算子`StreamAgg_9`によって最終的な集計`COUNT(*)`実行されます。 -これらの3つの演算子（ `TableFullScan_18` ） `Selection_19` TiKV（ `StreamAgg_9`で`cop[tikv]` ）にプッシュダウンされ、TiKVでの早期フィルタリングと集計が可能になり、TiKVとTiDB間のデータ転送が削減されます。最後に、 `TableReader_21` `StreamAgg_9`からデータを読み取り、 `StreamAgg_20`最終的な集計`count(*)`実行します。 +これらの3つの演算子（ `TableFullScan_18` ） `Selection_19` TiKV（ `StreamAgg_9`で`cop[tikv]` ）にプッシュダウンされ、TiKVでの早期フィルタリングと集計が可能になり、TiKVとTiDB間のデータ転送が削減されます。最後に、 `TableReader_21` `StreamAgg_9`からデータを読み取り、 `StreamAgg_20`最終的な集計`count(*)`を実行します。 ```sql EXPLAIN SELECT COUNT(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59'; @@ -686,7 +686,7 @@ LIMIT 1000 ``` -実行プランには170ミリ秒の期間が表示されています。TiDBは`test_index`使用して、フィルター`snapshot_id = 459840`で`IndexRangeScan_20`実行します。次に、テーブルからすべての列を取得し、 `IndexLookUp_23`後に5,715行をTiDBに返します。TiDBはこれらの行をソートし、1,000行を返します。 +実行プランには170ミリ秒の期間が表示されています。TiDBは`test_index`を使用して、フィルター`snapshot_id = 459840`で`IndexRangeScan_20`を実行します。次に、テーブルからすべての列を取得し、 `IndexLookUp_23`後に5,715行をTiDBに返します。TiDBはこれらの行をソートし、1,000行を返します。 列`id`は主キーであるため、暗黙的にインデックス`test_idx`に含まれます。ただし、 `IndexRangeScan_20`順序を保証しません。これは、列`test_idx`はインデックスプレフィックス列`snapshot_id`後に 2 つの追加列（ `user_id`と`status` ）が含まれているためです。その結果、列`id`の順序は保持されません。 diff --git a/statistics.md b/statistics.md index abe3c691b5f2c..9061590e4e9f9 100644 --- a/statistics.md +++ b/statistics.md @@ -300,7 +300,7 @@ auto analyze操作に使用される特定のテーブルに保持されてい SELECT sample_num, sample_rate, buckets, topn, column_choice, column_ids FROM mysql.analyze_options opt JOIN information_schema.tables tbl ON opt.table_id = tbl.tidb_table_id WHERE tbl.table_schema = '{db_name}' AND tbl.table_name = '{table_name}'; ``` -TiDB は、最新の`ANALYZE`ステートメントで指定された新しい構成を使用して、以前に記録された永続構成を上書きします。たとえば、 `ANALYZE TABLE t WITH 200 TOPN;`実行すると、 `ANALYZE`ステートメントの上位 200 個の値が設定されます。その後、 `ANALYZE TABLE t WITH 0.1 SAMPLERATE;`を実行すると、 `ANALYZE`と同様に、自動`ANALYZE TABLE t WITH 200 TOPN, 0.1 SAMPLERATE;` 。 +TiDB は、最新の`ANALYZE`ステートメントで指定された新しい構成を使用して、以前に記録された永続構成を上書きします。たとえば、 `ANALYZE TABLE t WITH 200 TOPN;`を実行すると、 `ANALYZE`ステートメントの上位 200 個の値が設定されます。その後、 `ANALYZE TABLE t WITH 0.1 SAMPLERATE;`を実行すると、 `ANALYZE`と同様に、自動`ANALYZE TABLE t WITH 200 TOPN, 0.1 SAMPLERATE;` 。 ### ANALYZE構成の永続化を無効にする {#disable-analyze-configuration-persistence} diff --git a/storage-engine/titan-configuration.md b/storage-engine/titan-configuration.md index d02d4cac0564b..266ce88ea7495 100644 --- a/storage-engine/titan-configuration.md +++ b/storage-engine/titan-configuration.md @@ -142,7 +142,7 @@ Titanを無効にするには、オプション`rocksdb.defaultcf.titan.blob-run 1. Titanを無効化したいTiKVノードの設定を更新します。設定の更新は2つの方法で行えます。 - - `tiup cluster edit-config`実行し、設定ファイルを編集して`tiup cluster reload -R tikv`実行します。 + - `tiup cluster edit-config`実行し、設定ファイルを編集して`tiup cluster reload -R tikv`を実行します。 - 構成ファイルを手動で更新し、TiKV を再起動します。 diff --git a/subquery-optimization.md b/subquery-optimization.md index 0a1a256fec76d..31486ca2834a8 100644 --- a/subquery-optimization.md +++ b/subquery-optimization.md @@ -90,4 +90,4 @@ explain select * from t1 where exists (select * from t2); 同様に、実行プランでインデックス結合が選択されている場合、準結合クエリは駆動テーブルとして外部クエリのみを使用できます。この場合、サブクエリの結果が外部クエリの結果よりも小さい場合、実行速度が予想よりも遅くなる可能性があります。 -`SEMI_JOIN_REWRITE()`使用してクエリを書き換えると、オプティマイザーは選択範囲を拡張して、より適切な実行プランを選択できます。 +`SEMI_JOIN_REWRITE()`を使用してクエリを書き換えると、オプティマイザーは選択範囲を拡張して、より適切な実行プランを選択できます。 diff --git a/sync-diff-inspector/shard-diff.md b/sync-diff-inspector/shard-diff.md index 3342e7c2dcfe9..d9a4ed5e0934a 100644 --- a/sync-diff-inspector/shard-diff.md +++ b/sync-diff-inspector/shard-diff.md @@ -7,7 +7,7 @@ summary: シャーディング シナリオでのデータ チェックについ sync-diff-inspector は、シャーディングシナリオにおけるデータチェックをサポートします。[TiDB Data Migration](/dm/dm-overview.md)を使用して複数の MySQL インスタンスから TiDB にデータを複製する場合、sync-diff-inspector を使用して上流と下流のデータをチェックできます。 -上流のシャードテーブルの数が少なく、シャードテーブルの命名規則にパターンがない場合（以下を参照）、 `Datasource config`使用して`table-0`設定し、対応する`rules`設定して、上流データベースと下流データベース間のマッピング関係を持つテーブルを設定できます。この設定方法では、すべてのシャードテーブルを設定する必要があります。 +上流のシャードテーブルの数が少なく、シャードテーブルの命名規則にパターンがない場合（以下を参照）、 `Datasource config`を使用して`table-0`設定し、対応する`rules`設定して、上流データベースと下流データベース間のマッピング関係を持つテーブルを設定できます。この設定方法では、すべてのシャードテーブルを設定する必要があります。 ![shard-table-replica-1](/media/shard-table-replica-1.png) diff --git a/system-variables.md b/system-variables.md index 8d15a712ae9c8..e0607af279916 100644 --- a/system-variables.md +++ b/system-variables.md @@ -1290,7 +1290,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: Float - デフォルト値: `0.5` - 範囲: `(0, 1]` 。v8.0.0 以前のバージョンの範囲は`[0, 18446744073709551615]`です。 -- この変数は、TiDB がバックグラウンド スレッドで[`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)自動的に実行してテーブル統計を更新する際のしきい値を設定するために使用されます。たとえば、値が 0.5 の場合、テーブル内の行の 50% 以上が変更されたときに自動分析がトリガーされます。 `tidb_auto_analyze_start_time`と`tidb_auto_analyze_end_time`指定することで、自動分析を特定の時間帯のみ実行するように制限できます。 +- この変数は、TiDB がバックグラウンド スレッドで[`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)自動的に実行してテーブル統計を更新する際のしきい値を設定するために使用されます。たとえば、値が 0.5 の場合、テーブル内の行の 50% 以上が変更されたときに自動分析がトリガーされます。 `tidb_auto_analyze_start_time`と`tidb_auto_analyze_end_time`を指定することで、自動分析を特定の時間帯のみ実行するように制限できます。 > **注記：** > @@ -2259,7 +2259,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `ON` -- この変数は、パーティション テーブルに対して[グローバルインデックス](/global-indexes.md)インデックスの作成をサポートするかどうかを制御します。この変数を有効にすると、TiDB では、インデックス定義で`GLOBAL`指定することで**、パーティション式で使用されているすべての列を含まない**一意インデックスを作成できます。 +- この変数は、パーティション テーブルに対して[グローバルインデックス](/global-indexes.md)インデックスの作成をサポートするかどうかを制御します。この変数を有効にすると、TiDB では、インデックス定義で`GLOBAL`を指定することで**、パーティション式で使用されているすべての列を含まない**一意インデックスを作成できます。 - この変数は v8.4.0 以降非推奨になりました。その値はデフォルト値`ON`に固定されています。つまり、[グローバルインデックス](/global-indexes.md)はデフォルトで有効になっています。 ### tidb_enable_lazy_cursor_fetch v8.3.0で追加 {#tidb-enable-lazy-cursor-fetch-new-in-v830} @@ -3429,7 +3429,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `ON` -- この変数は、新しい照合順序が有効になっているクラスタで MPP ハッシュパーティション交換演算子を生成するかどうかを制御します。 `true`演算子を生成することを意味し、 `false`生成しないことを意味します。 +- この変数は、新しい照合順序が有効になっているクラスタで MPP ハッシュパーティション交換演算子を生成するかどうかを制御します。 `true`演算子を生成することを意味し、 `false`を生成しないことを意味します。 - この変数はTiDBの内部動作に使用されます。この変数を設定することは**推奨されません**。 ### tidb_hash_join_concurrency {#tidb-hash-join-concurrency} @@ -5992,7 +5992,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - デフォルト値: "" - 型: String - この変数は、スロークエリログのトリガールールを定義します。多次元メトリクスを組み合わせることで、より柔軟で詳細なログ記録を実現します。 -- このシステム変数の使用方法の詳細については、 [`tidb_slow_log_rules`使用する](/identify-slow-queries.md#use-tidb_slow_log_rules)参照してください。 +- このシステム変数の使用方法の詳細については、 [`tidb_slow_log_rules`を使用する](/identify-slow-queries.md#use-tidb_slow_log_rules)参照してください。 > **ヒント：** > diff --git a/table-filter.md b/table-filter.md index 21462807d3c68..97b1a126ffcea 100644 --- a/table-filter.md +++ b/table-filter.md @@ -166,7 +166,7 @@ tiup dumpling -f 'employees.*' -f '*.WorkOrder' 簡潔性と将来の互換性のため、次のシーケンスは禁止されています。 -- 空白をトリミングした後の行末に`\`ます (末尾のリテラル空白に一致させるには`[ ]`使用します)。 +- 空白をトリミングした後の行末に`\`ます (末尾のリテラル空白に一致させるには`[ ]`を使用します)。 - `\`に続く任意のASCII英数字（ `[0-9a-zA-Z]` ）。特に、 `\0` 、 `\r` 、 `\n` 、 `\t`のようなC言語風のエスケープシーケンスは、現時点では意味を持ちません。 ### 引用符付き識別子 {#quoted-identifier} @@ -204,7 +204,7 @@ tiup dumpling -f 'employees.*' -f '*.WorkOrder' テーブル名がフィルター リスト内のどのルールにも一致しない場合は、デフォルトの動作ではそのような一致しないテーブルは無視されます。 -ブロック リストを作成するには、最初のルールとして明示的に`*.*`使用する必要があります。そうしないと、すべてのテーブルが除外されます。 +ブロック リストを作成するには、最初のルールとして明示的に`*.*`を使用する必要があります。そうしないと、すべてのテーブルが除外されます。 ```bash # every table will be filtered out diff --git a/ticdc/ticdc-bidirectional-replication.md b/ticdc/ticdc-bidirectional-replication.md index e8239d0e109f0..32840c9efaef4 100644 --- a/ticdc/ticdc-bidirectional-replication.md +++ b/ticdc/ticdc-bidirectional-replication.md @@ -102,7 +102,7 @@ BDRロールが設定されていない場合、任意のDDLを実行できま ### 複製可能なDDLのレプリケーションシナリオ {#replication-scenarios-of-replicable-ddls} -1. TiDB クラスターを選択し、 `ADMIN SET BDR ROLE PRIMARY`実行してそれをプライマリ クラスターとして設定します。 +1. TiDB クラスターを選択し、 `ADMIN SET BDR ROLE PRIMARY`を実行してそれをプライマリ クラスターとして設定します。 ```sql ADMIN SET BDR ROLE PRIMARY; @@ -118,7 +118,7 @@ BDRロールが設定されていない場合、任意のDDLを実行できま | primary | +----------+ -2. 他の TiDB クラスターで`ADMIN SET BDR ROLE SECONDARY`実行して、それらをセカンダリ クラスターとして設定します。 +2. 他の TiDB クラスターで`ADMIN SET BDR ROLE SECONDARY`を実行して、それらをセカンダリ クラスターとして設定します。 3. プライマリクラスターで**レプリケート可能なDDL**を実行します。正常に実行されたDDLは、TiCDCによってセカンダリクラスターにレプリケートされます。 @@ -131,7 +131,7 @@ BDRロールが設定されていない場合、任意のDDLを実行できま ### 複製不可能なDDLのレプリケーションシナリオ {#replication-scenarios-of-non-replicable-ddls} -1. すべての TiDB クラスターで`ADMIN UNSET BDR ROLE`実行して、BDR ロールを設定解除します。 +1. すべての TiDB クラスターで`ADMIN UNSET BDR ROLE`を実行して、BDR ロールを設定解除します。 2. すべてのクラスターで DDL を実行する必要があるテーブルへのデータの書き込みを停止します。 3. すべてのクラスター内の対応するテーブルへのすべての書き込みが他のクラスターに複製されるまで待機し、各 TiDB クラスターですべての DDL を手動で実行します。 4. DDL が完了するまで待ってから、データの書き込みを再開します。 @@ -139,7 +139,7 @@ BDRロールが設定されていない場合、任意のDDLを実行できま > **警告：** > -> すべてのTiDBクラスターで`ADMIN UNSET BDR ROLE`実行すると、TiCDCによってDDLは複製されません。各クラスターで個別にDDLを手動で実行する必要があります。 +> すべてのTiDBクラスターで`ADMIN UNSET BDR ROLE`を実行すると、TiCDCによってDDLは複製されません。各クラスターで個別にDDLを手動で実行する必要があります。 ## 双方向レプリケーションを停止する {#stop-bidirectional-replication} @@ -159,7 +159,7 @@ BDRロールが設定されていない場合、任意のDDLを実行できま > > 他のシナリオではBDRロールを設定しないでください。例えば、BDRロールを`PRIMARY` 、 `SECONDARY` 、そして0つを同時に設定しないでください。BDRロールを誤って設定すると、TiDBはデータレプリケーション中にデータの正確性と一貫性を保証できません。 -- 通常、レプリケートされたテーブルでのデータ競合を避けるため、 [`AUTO_INCREMENT`](/auto-increment.md)または[`AUTO_RANDOM`](/auto-random.md)使用しないでください。5 または`AUTO_INCREMENT` `AUTO_RANDOM`使用する必要がある場合は、異なるクラスタに異なる主キーを割り当てることができるように、異なるクラスタに異なる`auto_increment_increment`と`auto_increment_offset`設定できます。例えば、双方向レプリケーションに3つのTiDBクラスタ（A、B、C）がある場合、次のように設定します。 +- 通常、レプリケートされたテーブルでのデータ競合を避けるため、 [`AUTO_INCREMENT`](/auto-increment.md)または[`AUTO_RANDOM`](/auto-random.md)使用しないでください。5 または`AUTO_INCREMENT` `AUTO_RANDOM`を使用する必要がある場合は、異なるクラスタに異なる主キーを割り当てることができるように、異なるクラスタに異なる`auto_increment_increment`と`auto_increment_offset`設定できます。例えば、双方向レプリケーションに3つのTiDBクラスタ（A、B、C）がある場合、次のように設定します。 - クラスタAでは、 `auto_increment_increment=3`と`auto_increment_offset=2000`設定します - クラスタBでは、 `auto_increment_increment=3`と`auto_increment_offset=2001`設定します diff --git a/ticdc/ticdc-changefeed-overview.md b/ticdc/ticdc-changefeed-overview.md index f83a3283cde69..6e714cc3a0776 100644 --- a/ticdc/ticdc-changefeed-overview.md +++ b/ticdc/ticdc-changefeed-overview.md @@ -40,7 +40,7 @@ summary: チェンジフィードの基本的な概念、状態の定義、お ## チェンジフィードを操作する {#operate-changefeeds} -TiCDCクラスターとそのレプリケーションタスクは、コマンドラインツール`cdc cli`使用して管理できます。詳細については、 [TiCDC の変更フィードを管理する](/ticdc/ticdc-manage-changefeed.md)参照してください。 +TiCDCクラスターとそのレプリケーションタスクは、コマンドラインツール`cdc cli`を使用して管理できます。詳細については、 [TiCDC の変更フィードを管理する](/ticdc/ticdc-manage-changefeed.md)参照してください。 HTTPインターフェース（TiCDC OpenAPI機能）を使用して、TiCDCクラスターとそのレプリケーションタスクを管理することもできます。詳細については、 [TiCDC オープンAPI](/ticdc/ticdc-open-api.md)参照してください。 diff --git a/ticdc/ticdc-client-authentication.md b/ticdc/ticdc-client-authentication.md index d4def7b98e9e8..b1e47a13c08e1 100644 --- a/ticdc/ticdc-client-authentication.md +++ b/ticdc/ticdc-client-authentication.md @@ -33,7 +33,7 @@ v8.1.0 以降、TiCDC は Mutual Transport Layer Security (mTLS) または TiDB [TiCDC コマンドラインツール](/ticdc/ticdc-manage-changefeed.md)使用する場合、以下の方法でクライアント証明書を指定できます。TiCDC は以下の順序でクライアント証明書の読み取りを試みます。 - 1. コマンドラインパラメータ`--cert`と`--key`使用して、証明書と秘密鍵を指定します。サーバーが自己署名証明書を使用している場合は、パラメータ`--ca`を使用して信頼できる CA 証明書も指定する必要があります。 + 1. コマンドラインパラメータ`--cert`と`--key`を使用して、証明書と秘密鍵を指定します。サーバーが自己署名証明書を使用している場合は、パラメータ`--ca`を使用して信頼できる CA 証明書も指定する必要があります。 ```bash cdc cli changefeed list --cert client.crt --key client.key --ca ca.crt @@ -53,7 +53,7 @@ v8.1.0 以降、TiCDC は Mutual Transport Layer Security (mTLS) または TiDB
    - [TiCDC オープンAPI](/ticdc/ticdc-open-api-v2.md)使用する場合、 `--cert`と`--key`使用してクライアント証明書と秘密鍵を指定できます。サーバーが自己署名証明書を使用する場合は、 `--cacert`パラメータを使用して信頼されたCA証明書も指定する必要があります。例： + [TiCDC オープンAPI](/ticdc/ticdc-open-api-v2.md)使用する場合、 `--cert`と`--key`を使用してクライアント証明書と秘密鍵を指定できます。サーバーが自己署名証明書を使用する場合は、 `--cacert`パラメータを使用して信頼されたCA証明書も指定する必要があります。例： ```bash curl -X GET http://127.0.0.1:8300/api/v2/status --cert client.crt --key client.key --cacert ca.crt @@ -87,7 +87,7 @@ v8.1.0 以降、TiCDC は Mutual Transport Layer Security (mTLS) または TiDB [TiCDC コマンドラインツール](/ticdc/ticdc-manage-changefeed.md)使用する場合、以下の方法でユーザー名とパスワードを指定できます。TiCDC は以下の順序でクライアント証明書の読み取りを試みます。 - 1. コマンドラインパラメータ`--user`と`--password`使用してユーザー名とパスワードを指定します。 + 1. コマンドラインパラメータ`--user`と`--password`を使用してユーザー名とパスワードを指定します。 ```bash cdc cli changefeed list --user test --password password @@ -99,7 +99,7 @@ v8.1.0 以降、TiCDC は Mutual Transport Layer Security (mTLS) または TiDB cdc cli changefeed list --user test ``` - 3. 環境変数`TICDC_USER`と`TICDC_PASSWORD`使用してユーザー名とパスワードを指定します。 + 3. 環境変数`TICDC_USER`と`TICDC_PASSWORD`を使用してユーザー名とパスワードを指定します。 ```bash export TICDC_USER=test diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md index 8ccde3e4d9120..04e379cedaa62 100644 --- a/ticdc/ticdc-ddl.md +++ b/ticdc/ticdc-ddl.md @@ -63,7 +63,7 @@ summary: TiCDC でサポートされている DDL ステートメントといく ダウンストリームがTiDBの場合、TiCDCは`ADD INDEX`と`CREATE INDEX` DDL操作を非同期的に実行し、変更フィードレプリケーションのレイテンシーへの影響を最小限に抑えます。つまり、 `ADD INDEX`と`CREATE INDEX` DDLをダウンストリームTiDBにレプリケーションして実行した後、TiCDCはDDL実行の完了を待たずに直ちに戻ります。これにより、後続のDML実行がブロックされることを回避できます。 -ダウンストリームで`ADD INDEX`または`CREATE INDEX` DDL 操作が実行されている間に、TiCDC が同じテーブルに対して次の DDL 操作を実行すると、この DDL 操作が`queueing`状態で長時間ブロックされる可能性があります。これにより、TiCDC はこの DDL 操作を繰り返し実行することになり、再試行に時間がかかりすぎると、レプリケーションタスクが失敗する可能性があります。v8.4.0 以降では、TiCDC がダウンストリームデータベースに対して`SUPER`権限を持っている場合、定期的に`ADMIN SHOW DDL JOBS`実行して、非同期で実行された DDL タスクのステータスを確認します。TiCDC は、インデックス作成が完了するまで待ってからレプリケーションを続行します。これによりレプリケーションのレイテンシーが増加する可能性がありますが、レプリケーションタスクの失敗を回避できます。 +ダウンストリームで`ADD INDEX`または`CREATE INDEX` DDL 操作が実行されている間に、TiCDC が同じテーブルに対して次の DDL 操作を実行すると、この DDL 操作が`queueing`状態で長時間ブロックされる可能性があります。これにより、TiCDC はこの DDL 操作を繰り返し実行することになり、再試行に時間がかかりすぎると、レプリケーションタスクが失敗する可能性があります。v8.4.0 以降では、TiCDC がダウンストリームデータベースに対して`SUPER`権限を持っている場合、定期的に`ADMIN SHOW DDL JOBS`を実行して、非同期で実行された DDL タスクのステータスを確認します。TiCDC は、インデックス作成が完了するまで待ってからレプリケーションを続行します。これによりレプリケーションのレイテンシーが増加する可能性がありますが、レプリケーションタスクの失敗を回避できます。 > **注記：** > diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 8b4d6c129c7bc..84df5df8df578 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -18,15 +18,15 @@ summary: TiCDC を使用する際に遭遇する可能性のある FAQ につい - `start-ts`という値は、現在の TiDB クラスターの`tikv_gc_safe_point`という値よりも大きいです。それ以外の場合、タスクの作成時にエラーが発生します。 - タスクを開始する前に、ダウンストリームにすべてのデータが`start-ts`あることを確認してください。メッセージキューにデータを複製するなどのシナリオでは、アップストリームとダウンストリーム間のデータの整合性が要求されない場合は、アプリケーションのニーズに応じてこの要件を緩和できます。 -`start-ts`指定しない場合、または`start-ts` `0`として指定した場合、レプリケーション タスクが開始されると、TiCDC は現在の TSO を取得し、この TSO からタスクを開始します。 +`start-ts`を指定しない場合、または`start-ts` `0`として指定した場合、レプリケーション タスクが開始されると、TiCDC は現在の TSO を取得し、この TSO からタスクを開始します。 ## TiCDC でタスクを作成するときに一部のテーブルを複製できないのはなぜですか? {#why-can-t-some-tables-be-replicated-when-i-create-a-task-in-ticdc} -`cdc cli changefeed create`実行してレプリケーションタスクを作成すると、TiCDC は上流のテーブルが[レプリケーション要件](/ticdc/ticdc-overview.md#best-practices)を満たしているかどうかを確認します。要件を満たしていないテーブルがある場合は、 `some tables are not eligible to replicate`不適格なテーブルのリストが返されます。タスクの作成を続行するには`Y`または`y`選択できます。この場合、これらのテーブルに対するすべての更新はレプリケーション中に自動的に無視されます。 `Y`または`y`以外の入力を選択した場合、レプリケーションタスクは作成されません。 +`cdc cli changefeed create`を実行してレプリケーションタスクを作成すると、TiCDC は上流のテーブルが[レプリケーション要件](/ticdc/ticdc-overview.md#best-practices)を満たしているかどうかを確認します。要件を満たしていないテーブルがある場合は、 `some tables are not eligible to replicate`不適格なテーブルのリストが返されます。タスクの作成を続行するには`Y`または`y`選択できます。この場合、これらのテーブルに対するすべての更新はレプリケーション中に自動的に無視されます。 `Y`または`y`以外の入力を選択した場合、レプリケーションタスクは作成されません。 ## TiCDC レプリケーション タスクの状態を確認するにはどうすればよいですか? {#how-do-i-view-the-state-of-ticdc-replication-tasks} -TiCDC レプリケーションタスクのステータスを表示するには、 `cdc cli`使用します。例: +TiCDC レプリケーションタスクのステータスを表示するには、 `cdc cli`を使用します。例: ```shell cdc cli changefeed list --server=http://127.0.0.1:8300 @@ -185,7 +185,7 @@ TiCDC がサービス GC セーフポイントに設定するデフォルトの ## レプリケーション タスクが失敗した後に回復するにはどうすればよいですか? {#how-to-recover-a-replication-task-after-it-fails} -1. `cdc cli changefeed query`使用してレプリケーション タスクのエラー情報を照会し、できるだけ早くエラーを修正します。 +1. `cdc cli changefeed query`を使用してレプリケーション タスクのエラー情報を照会し、できるだけ早くエラーを修正します。 2. 値を`gc-ttl`に増やすと、エラーを修正するための時間が長くなり、エラーが修正された後にレプリケーションの遅延が`gc-ttl`超えたためにレプリケーション タスクが`failed`ステータスにならないようになります。 3. システムへの影響を評価した後、TiDB の値を[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)増やして GC をブロックし、データを保持して、エラーが修正された後に GC がデータをクリーンアップすることによってレプリケーション タスクが`failed`ステータスにならないようにします。 diff --git a/ticdc/ticdc-manage-changefeed.md b/ticdc/ticdc-manage-changefeed.md index 71aad2817d900..72b474447bf58 100644 --- a/ticdc/ticdc-manage-changefeed.md +++ b/ticdc/ticdc-manage-changefeed.md @@ -169,12 +169,12 @@ cdc cli changefeed resume --server=http://10.0.10.25:8300 --changefeed-id simple ``` - `--changefeed-id=uuid` 、再開するレプリケーション タスクに対応する変更フィード ID を表します。 -- `--overwrite-checkpoint-ts` : v6.2.0以降では、レプリケーションタスクを再開する開始TSOを指定できます。TiCDCは指定されたTSOからデータのプルを開始します。引数には`now`または特定のTSO（434873584621453313など）を指定できます。指定するTSOは、GCセーフポイントからCurrentTSOまでの範囲内である必要があります。この引数を指定しない場合、TiCDCはデフォルトで現在の`checkpoint-ts`からデータを複製します。現在のTSO値`checkpoint-ts`確認するには、 `cdc cli changefeed list`コマンドを使用します。 +- `--overwrite-checkpoint-ts` : v6.2.0以降では、レプリケーションタスクを再開する開始TSOを指定できます。TiCDCは指定されたTSOからデータのプルを開始します。引数には`now`または特定のTSO（434873584621453313など）を指定できます。指定するTSOは、GCセーフポイントからCurrentTSOまでの範囲内である必要があります。この引数を指定しない場合、TiCDCはデフォルトで現在の`checkpoint-ts`からデータを複製します。現在のTSO値`checkpoint-ts`を確認するには、 `cdc cli changefeed list`コマンドを使用します。 - `--no-confirm` : レプリケーションが再開されたときに、関連情報を確認する必要はありません。デフォルトは`false`です。 > **注記：** > -> - `--overwrite-checkpoint-ts` （ `t2` ）で指定されたTSOがchangefeed（ `t1` ）の現在のチェックポイントTSOよりも大きい場合、 `t1`と`t2`間のデータは下流に複製されません。これによりデータ損失が発生します。13 `cdc cli changefeed query`実行すると`t1`取得できます。 +> - `--overwrite-checkpoint-ts` （ `t2` ）で指定されたTSOがchangefeed（ `t1` ）の現在のチェックポイントTSOよりも大きい場合、 `t1`と`t2`間のデータは下流に複製されません。これによりデータ損失が発生します。13 `cdc cli changefeed query`を実行すると`t1`取得できます。 > - `--overwrite-checkpoint-ts` （ `t2` ）で指定されたTSOがチェンジフィード（ `t1` ）の現在のチェックポイントTSOより小さい場合、TiCDCは古い時点（ `t2` ）からデータをプルします。これにより、データの重複が発生する可能性があります（たとえば、下流がMQシンクの場合）。 ## レプリケーションタスクを削除する {#remove-a-replication-task} @@ -187,7 +187,7 @@ cdc cli changefeed remove --server=http://10.0.10.25:8300 --changefeed-id simple 上記のコマンドでは、次のようになります。 -- `--changefeed-id=uuid`削除するレプリケーション タスクに対応する変更フィードの ID を表します。 +- `--changefeed-id=uuid`を削除するレプリケーション タスクに対応する変更フィードの ID を表します。 ## タスク構成の更新 {#update-task-configuration} @@ -294,4 +294,4 @@ cdc cli --server="http://10.0.10.25:8300" changefeed query --changefeed-id=simpl > **注記：** > > - サーバーで、レイテンシーが長く、帯域幅が制限されている機械式ハード ドライブやその他のストレージデバイスが使用されている場合、Unified Sorter のパフォーマンスは大幅に低下します。 -> - デフォルトでは、Unified Sorter は一時ファイルの保存に`data_dir`使用します。空きディスク容量が 500 GiB 以上であることを確認することをお勧めします。本番環境では、各ノードの空きディスク容量が（業務で許容される最大遅延時間`checkpoint-ts` ）×（業務ピーク時のアップストリーム書き込みトラフィック）よりも大きいことを確認することをお勧めします。また、 `changefeed`作成した後に大量の履歴データを複製する予定がある場合は、各ノードの空き容量が複製データの量よりも大きいことを確認してください。 +> - デフォルトでは、Unified Sorter は一時ファイルの保存に`data_dir`を使用します。空きディスク容量が 500 GiB 以上であることを確認することをお勧めします。本番環境では、各ノードの空きディスク容量が（業務で許容される最大遅延時間`checkpoint-ts` ）×（業務ピーク時のアップストリーム書き込みトラフィック）よりも大きいことを確認することをお勧めします。また、 `changefeed`を作成した後に大量の履歴データを複製する予定がある場合は、各ノードの空き容量が複製データの量よりも大きいことを確認してください。 diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md index 658fcb6f45be5..0a3dee3350f1a 100644 --- a/ticdc/ticdc-open-api-v2.md +++ b/ticdc/ticdc-open-api-v2.md @@ -279,7 +279,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | パラメータ名 | 説明 | | :-------------------- | :--------------------------------------------------------------------------------------------------------------------- | | `event_filters` | イベントをフィルタリングするための設定。(オプション) | -| `ignore_txn_start_ts` | `UINT64 ARRAY`型。これを指定すると、 `[1, 2]`など`start_ts`指定するトランザクションは無視されます。（オプション） | +| `ignore_txn_start_ts` | `UINT64 ARRAY`型。これを指定すると、 `[1, 2]`など`start_ts`を指定するトランザクションは無視されます。（オプション） | | `rules` | `STRING ARRAY`型。テーブルスキーマフィルタリングのルール（例： `['foo*.*', 'bar*.*']` ）。詳細については、 [テーブルフィルター](/table-filter.md)参照してください。（オプション） | `filter.event_filters`パラメータの説明は以下のとおりです。詳細については[変更フィードログフィルター](/ticdc/ticdc-filter.md)参照してください。 @@ -313,7 +313,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | `schema_registry` | `STRING`型。スキーマレジストリアドレス。（オプション） | | `terminator` | `STRING`型。ターミネータは、2つのデータ変更イベントを区切るために使用されます。デフォルト値はnullで、 `"\r\n"`ターミネータとして使用されます。（オプション） | | `transaction_atomicity` | `STRING`型。トランザクションのアトミック性レベル。（オプション） | -| `only_output_updated_columns` | `BOOLEAN`型。2 または`canal-json`プロトコル`open-protocol`使用するMQシンクの場合、変更された列のみを出力するかどうかを指定できます。デフォルト値は`false`です。（オプション） | +| `only_output_updated_columns` | `BOOLEAN`型。2 または`canal-json`プロトコル`open-protocol`を使用するMQシンクの場合、変更された列のみを出力するかどうかを指定できます。デフォルト値は`false`です。（オプション） | | `cloud_storage_config` | ストレージシンクの構成。(オプション) | | `open` | オープンプロトコルの構成。(オプション) | | `debezium` | Debezium プロトコルの設定。(オプション) | diff --git a/ticdc/ticdc-open-api.md b/ticdc/ticdc-open-api.md index c778a08f937d0..32f8c319e534c 100644 --- a/ticdc/ticdc-open-api.md +++ b/ticdc/ticdc-open-api.md @@ -117,9 +117,9 @@ curl -X GET http://127.0.0.1:8300/api/v1/health 上記の表のその他のパラメータについては、次のようにさらに詳しく説明します。 -`force_replicate` : このパラメータのデフォルトは`false`です。4 `true`指定すると、TiCDC は一意インデックスを持たないテーブルを強制的に複製しようとします。 +`force_replicate` : このパラメータのデフォルトは`false`です。4 `true`を指定すると、TiCDC は一意インデックスを持たないテーブルを強制的に複製しようとします。 -`ignore_ineligible_table` : このパラメータのデフォルトは`false`です。4 `true`指定すると、TiCDC は複製できないテーブルを無視します。 +`ignore_ineligible_table` : このパラメータのデフォルトは`false`です。4 `true`を指定すると、TiCDC は複製できないテーブルを無視します。 `filter_rules` : テーブルスキーマフィルタリングのルール（例： `filter_rules = ['foo*.*','bar*.*']` ）。詳細については、 [テーブルフィルター](/table-filter.md)ドキュメントを参照してください。 diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index c125fbc8ab208..38a7dcc4bd8de 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -129,7 +129,7 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na - SASL/スクラム - SCRAM-SHA-256とSCRAM-SHA-512はPLAIN方式に似ています。対応する認証方式として`sasl-mechanism`指定するだけです。 + SCRAM-SHA-256とSCRAM-SHA-512はPLAIN方式に似ています。対応する認証方式として`sasl-mechanism`を指定するだけです。 - SASL/GSSAPI @@ -151,7 +151,7 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na - TLS/SSL暗号化 - KafkaブローカーでTLS/SSL暗号化が有効になっている場合は、 `--sink-uri`に`-enable-tls=true`パラメータを追加する必要があります。自己署名証明書を使用する場合は、 `--sink-uri`に`ca` 、 `cert` 、 `key`指定する必要があります。 + KafkaブローカーでTLS/SSL暗号化が有効になっている場合は、 `--sink-uri`に`-enable-tls=true`パラメータを追加する必要があります。自己署名証明書を使用する場合は、 `--sink-uri`に`ca` 、 `cert` 、 `key`を指定する必要があります。 - ACL認証 @@ -277,7 +277,7 @@ Topic 式の形式は`[prefix]{schema}[middle][{table}][suffix]`です。 ### パーティションディスパッチャ {#partition-dispatchers} -`partition = "xxx"` `index-value`ディスパッチャ`columns`指定するために使用できます。3、5、7、9、11 `default` 5つ`ts`ディスパッチャをサポートします。ディスパッチャのルールは以下のとおり`table` 。 +`partition = "xxx"` `index-value`ディスパッチャ`columns`を指定するために使用できます。3、5、7、9、11 `default` 5つ`ts`ディスパッチャをサポートします。ディスパッチャのルールは以下のとおり`table` 。 - `default` : デフォルトで`table`ディスパッチャルールを使用します。スキーマ名とテーブル名に基づいてパーティション番号を計算し、テーブルからのデータが必ず同じパーティションに送信されるようにします。その結果、1つのテーブルからのデータは1つのパーティションにのみ存在し、順序付けが保証されます。ただし、このディスパッチャルールは送信スループットを制限し、コンシューマーを追加しても消費速度を向上させることはできません。 - `index-value` : 主キー、一意インデックス、または`index`で明示的に指定されたインデックスのいずれかを使用してパーティション番号を計算し、テーブルデータを複数のパーティションに分散します。単一のテーブルのデータは複数のパーティションに送信され、各パーティションのデータは順序付けされます。コンシューマーを追加することで、消費速度を向上させることができます。このディスパッチャは、同じ行への更新が同じパーティションに送信されるようにすることで、その行の順序付けされた処理を保証します。 @@ -385,7 +385,7 @@ SELECT COUNT(*) FROM INFORMATION_SCHEMA.TIKV_REGION_STATUS WHERE DB_NAME="databa Kafkaトピックは、受信できるメッセージのサイズに制限を設定します。この制限はパラメータ[`max.message.bytes`](https://kafka.apache.org/documentation/#topicconfigs_max.message.bytes)によって制御されます。TiCDC Kafkaシンクがこの制限を超えるデータを送信した場合、チェンジフィードはエラーを報告し、データのレプリケーションを続行できません。この問題を解決するために、TiCDCは新しい設定`large-message-handle-option`を追加し、以下のソリューションを提供します。 -現在、この機能はCanal-JSONとOpen Protocolの2つのエンコーディングプロトコルをサポートしています。Canal-JSONプロトコルを使用する場合は、 `sink-uri`のうち`enable-tidb-extension=true`指定する必要があります。 +現在、この機能はCanal-JSONとOpen Protocolの2つのエンコーディングプロトコルをサポートしています。Canal-JSONプロトコルを使用する場合は、 `sink-uri`のうち`enable-tidb-extension=true`を指定する必要があります。 ### TiCDCデータ圧縮 {#ticdc-data-compression} diff --git a/ticdc/ticdc-sink-to-pulsar.md b/ticdc/ticdc-sink-to-pulsar.md index fc04b6a393198..e58e7cfde22b3 100644 --- a/ticdc/ticdc-sink-to-pulsar.md +++ b/ticdc/ticdc-sink-to-pulsar.md @@ -138,7 +138,7 @@ send-timeout=30 ### ベストプラクティス {#best-practice} -- チェンジフィードを作成する際は、パラメータ`protocol`指定する必要があります。現在、Pulsarへのデータレプリケーションにはプロトコル`canal-json`のみがサポートされています。 +- チェンジフィードを作成する際は、パラメータ`protocol`を指定する必要があります。現在、Pulsarへのデータレプリケーションにはプロトコル`canal-json`のみがサポートされています。 - `pulsar-producer-cache-size`パラメータは、Pulsarクライアントにキャッシュされるプロデューサーの数を示します。Pulsarでは各プロデューサーが1つのトピックにしか対応できないため、TiCDCはプロデューサーのキャッシュにLRU方式を採用しており、デフォルトの制限は10240です。複製する必要があるトピックの数がデフォルト値よりも多い場合は、この数を増やす必要があります。 ### TLS暗号化伝送 {#tls-encrypted-transmission} @@ -272,7 +272,7 @@ dispatchers = [ ### トピックディスパッチャ {#topic-dispatcher} -`topic = "xxx"`使用するとトピックディスパッチャを指定し、トピック式を使用して柔軟なトピックディスパッチポリシーを実装できます。トピックの総数は1000未満にすることをお勧めします。 +`topic = "xxx"`を使用するとトピックディスパッチャを指定し、トピック式を使用して柔軟なトピックディスパッチポリシーを実装できます。トピックの総数は1000未満にすることをお勧めします。 トピック表現の形式は`[tenant_and_namespace][prefix]{schema}[middle][{table}][suffix]`です。各部分の意味は次のとおりです。 @@ -325,7 +325,7 @@ dispatchers = [ 発送ルールは以下のとおりです。 -- `default` : デフォルトでは、イベントはスキーマ名とテーブル名によってディスパッチされます。これは`table`指定した場合と同じです。 +- `default` : デフォルトでは、イベントはスキーマ名とテーブル名によってディスパッチされます。これは`table`を指定した場合と同じです。 - `ts` : 行変更の commitT を使用してハッシュ計算を実行し、イベントをディスパッチします。 - `index-value` : テーブルの主キーまたは一意インデックスの値を使用してハッシュ計算を実行し、イベントをディスパッチします。 - `table` : スキーマ名とテーブル名を使用してハッシュ計算を実行し、イベントをディスパッチします。 diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index df2027c5e7b3e..c08bffcc87db2 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -7,7 +7,7 @@ summary: TiCDC が UPDATE` イベントを分割するかどうかに関する ## MySQLシンクのUPDATEイベントを分割する {#split-code-update-code-events-for-mysql-sinks} -v6.5.10、v7.1.6、v7.5.2、v8.1.1、v8.2.0以降では、MySQLシンクを使用する場合、テーブルのレプリケーション要求を受信したTiCDCノードは、下流へのレプリケーションを開始する前に、PDから現在のタイムスタンプ`thresholdTS`取得します。このタイムスタンプの値に基づいて、TiCDCは`UPDATE`イベントを分割するかどうかを決定します。 +v6.5.10、v7.1.6、v7.5.2、v8.1.1、v8.2.0以降では、MySQLシンクを使用する場合、テーブルのレプリケーション要求を受信したTiCDCノードは、下流へのレプリケーションを開始する前に、PDから現在のタイムスタンプ`thresholdTS`を取得します。このタイムスタンプの値に基づいて、TiCDCは`UPDATE`イベントを分割するかどうかを決定します。 - 1 つまたは複数の`UPDATE`変更を含むトランザクションの場合、トランザクション`commitTS` `thresholdTS`未満であれば、TiCDC は`UPDATE`イベントを`DELETE`イベントと`INSERT`イベントに分割してから、それらを Sorter モジュールに書き込みます。 - トランザクション`commitTS`が`thresholdTS`以上であるイベントが`UPDATE`ある場合、TiCDC はそれらを分割しません。詳細については、GitHub の問題[＃10918](https://github.com/pingcap/tiflow/issues/10918)参照してください。 diff --git a/ticdc/ticdc-upstream-downstream-check.md b/ticdc/ticdc-upstream-downstream-check.md index 66e9f2dccdfe6..0a429d45c9fb4 100644 --- a/ticdc/ticdc-upstream-downstream-check.md +++ b/ticdc/ticdc-upstream-downstream-check.md @@ -100,7 +100,7 @@ select * from tidb_cdc.syncpoint_v1; - v6.4.0 以降では、 `SYSTEM_VARIABLES_ADMIN`または`SUPER`権限を持つ changefeed のみが TiCDC Syncpoint 機能を使用できます。 - v8.2.0 以降、TiCDC は`primary_ts`値の生成ルールに次の調整を加えます。 - - TiCDC が新しい`primary_ts`生成するときは、その値は`sync-point-interval`の整数倍である必要があります。 - - TiCDCは、新しいチェンジフィードごとに初期値`primary_ts`計算します。この初期値は、チェンジフィードの開始時刻（ `startTs` ）以上であり、 `sync-point-interval`の最小の整数倍です。 + - TiCDC が新しい`primary_ts`を生成するときは、その値は`sync-point-interval`の整数倍である必要があります。 + - TiCDCは、新しいチェンジフィードごとに初期値`primary_ts`を計算します。この初期値は、チェンジフィードの開始時刻（ `startTs` ）以上であり、 `sync-point-interval`の最小の整数倍です。 この設定は、データレプリケーション中に異なる変更フィードの同期ポイントを揃えるために使用されます。例えば、複数の下流クラスタは、 [`FLASHBACK TABLE`](/sql-statements/sql-statement-flashback-table.md)番目のステートメントを実行することで、同じ`primary_ts`番目の同期ポイントの`secondary_ts`番目の状態に復元することができ、下流クラスタ間でデータの一貫性を確保できます。 diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index 257c4b553c151..fdf76d914b526 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -17,12 +17,12 @@ summary: TiCDC の使用時に発生する可能性のある問題のトラブ - Grafanaダッシュボードで、レプリケーションタスクの監視メトリック`changefeed checkpoint` （適切な`changefeed id`選択）を確認してください。メトリック値が変化しない場合、またはメトリック`checkpoint lag`が増加し続ける場合、レプリケーションタスクが中断されている可能性があります。 - 監視メトリック`exit error count`を確認してください。メトリック値が`0`より大きい場合、レプリケーションタスクでエラーが発生しました。 -- `cdc cli changefeed list`と`cdc cli changefeed query`実行して、レプリケーションタスクのステータスを確認します。5 `stopped`タスクが停止したことを意味し、 `error`は詳細なエラーメッセージを示します。エラー発生後、TiCDCサーバーログで`error on running processor`検索してエラースタックを確認し、トラブルシューティングを行うことができます。 +- `cdc cli changefeed list`と`cdc cli changefeed query`を実行して、レプリケーションタスクのステータスを確認します。5 `stopped`タスクが停止したことを意味し、 `error`は詳細なエラーメッセージを示します。エラー発生後、TiCDCサーバーログで`error on running processor`検索してエラースタックを確認し、トラブルシューティングを行うことができます。 - 極端なケースでは、TiCDC サービスが再起動されることがあります。トラブルシューティングのために、TiCDCサーバーログの`FATAL`レベル目のログを検索できます。 ### レプリケーション タスクが手動で停止されたかどうかを確認するにはどうすればよいですか? {#how-do-i-know-whether-the-replication-task-is-stopped-manually} -レプリケーションタスクが手動で停止されているかどうかを確認するには、 `cdc cli`実行します。例: +レプリケーションタスクが手動で停止されているかどうかを確認するには、 `cdc cli`を実行します。例: ```shell cdc cli changefeed query --server=http://127.0.0.1:8300 --changefeed-id 28c43ffc-2316-4f4f-a70b-d1a7c59ba79f @@ -38,7 +38,7 @@ cdc cli changefeed query --server=http://127.0.0.1:8300 --changefeed-id 28c43ffc - このシナリオでは、TiCDCはタスク情報を保存します。TiCDCはPDにサービスGCセーフポイントを設定しているため、タスクチェックポイント以降のデータは有効期間`gc-ttl`内にTiKV GCによってクリーンアップされません。 - - 対処方法：ダウンストリームが正常に戻った後、 `cdc cli changefeed resume`実行することでレプリケーション タスクを再開できます。 + - 対処方法：ダウンストリームが正常に戻った後、 `cdc cli changefeed resume`を実行することでレプリケーション タスクを再開できます。 - ダウンストリームに互換性のない SQL ステートメントがあるため、レプリケーションを続行できません。 @@ -85,7 +85,7 @@ v4.0.9 以降では、レプリケーション タスクで統合ソーター機 ## 変更フィードの下流にMySQLなどのデータベースがあり、TiCDCが時間のかかるDDL文を実行すると、他のすべての変更フィードがブロックされます。どうすればよいでしょうか？ {#when-the-downstream-of-a-changefeed-is-a-database-similar-to-mysql-and-ticdc-executes-a-time-consuming-ddl-statement-all-other-changefeeds-are-blocked-what-should-i-do} 1. 時間のかかるDDL文を含む変更フィードの実行を一時停止します。すると、他の変更フィードがブロックされなくなったことがわかります。 -2. TiCDC ログで`apply job`フィールドを検索し、時間のかかる DDL ステートメントの`start-ts`確認します。 +2. TiCDC ログで`apply job`フィールドを検索し、時間のかかる DDL ステートメントの`start-ts`を確認します。 3. 下流のDDL文を手動で実行します。実行が完了したら、以下の操作を続行します。 4. changefeed 設定を変更し、上記の`start-ts` `ignore-txn-start-ts`構成項目に追加します。 5. 一時停止された変更フィードを再開します。 @@ -112,7 +112,7 @@ TiCDC が Kafka に送信するメッセージのサイズを制御するには ## TiCDC レプリケーション中に、ダウンストリームで DDL ステートメントの実行が失敗したかどうかを確認するにはどうすればよいでしょうか? レプリケーションを再開するにはどうすればよいでしょうか? {#how-can-i-find-out-whether-a-ddl-statement-fails-to-execute-in-downstream-during-ticdc-replication-how-to-resume-the-replication} -DDL文の実行に失敗した場合、レプリケーションタスク（changefeed）は自動的に停止します。checkpoint-tsはDDL文のfinish-tsです。TiCDCにこの文の実行を下流で再試行させたい場合は、 `cdc cli changefeed resume`指定してレプリケーションタスクを再開してください。例： +DDL文の実行に失敗した場合、レプリケーションタスク（changefeed）は自動的に停止します。checkpoint-tsはDDL文のfinish-tsです。TiCDCにこの文の実行を下流で再試行させたい場合は、 `cdc cli changefeed resume`を指定してレプリケーションタスクを再開してください。例： ```shell cdc cli changefeed resume -c test-cf --server=http://127.0.0.1:8300 diff --git a/tidb-cloud/csv-config-for-import-data.md b/tidb-cloud/csv-config-for-import-data.md index 8e6db7aca8e50..8e2ecd9ec3a74 100644 --- a/tidb-cloud/csv-config-for-import-data.md +++ b/tidb-cloud/csv-config-for-import-data.md @@ -59,7 +59,7 @@ summary: TiDB Cloudのインポート データ サービスで CSV 構成を使 - 値が`True`の場合、 `"nick name is \"Mike\""` `nick name is "Mike"`として解析され、ターゲット テーブルに書き込まれます。 - 値が`False`の場合、 `"nick name is \"` 、 `Mike\` 、 `""`の3つのフィールドとして解析されます。しかし、フィールドが互いに分離されていないため、正しく解析できません。 - 標準CSVファイルの場合、記録するフィールドに二重引用符で囲まれた文字が含まれている場合は、エスケープ処理のために二重引用符を2つ使用する必要があります。この場合、二重引用符を`Backslash escape = True`使用すると解析エラーが発生しますが、 `Backslash escape = False`使用すると正しく解析されます。典型的なシナリオは、インポートされたフィールドにJSONコンテンツが含まれている場合です。標準CSVのJSONフィールドは通常、次のように保存されます。 + 標準CSVファイルの場合、記録するフィールドに二重引用符で囲まれた文字が含まれている場合は、エスケープ処理のために二重引用符を2つ使用する必要があります。この場合、二重引用符を`Backslash escape = True`を使用すると解析エラーが発生しますが、 `Backslash escape = False`を使用すると正しく解析されます。典型的なシナリオは、インポートされたフィールドにJSONコンテンツが含まれている場合です。標準CSVのJSONフィールドは通常、次のように保存されます。 `"{""key1"":""val1"", ""key2"": ""val2""}"` diff --git a/tidb-cloud/data-service-manage-endpoint.md b/tidb-cloud/data-service-manage-endpoint.md index 464a34bfc2eff..356882e0c6627 100644 --- a/tidb-cloud/data-service-manage-endpoint.md +++ b/tidb-cloud/data-service-manage-endpoint.md @@ -193,7 +193,7 @@ TiDB Cloud Data Serviceでは、以下のようにして1つまたは複数の - **タグ**：エンドポイントのグループを識別するために使用されるタグ。 -- **ページネーション**：このプロパティは、リクエストメソッドが`GET`で、エンドポイントの最後の SQL ステートメントが`SELECT`操作の場合にのみ使用できます。**ページネーションが**有効になっている場合、エンドポイントを呼び出す際にクエリ パラメータとして`page`と`page_size`指定することで、結果をページネーションできます（例`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id?page=&page_size=` 。詳細については、[エンドポイントを呼び出す](#call-an-endpoint)参照してください。 +- **ページネーション**：このプロパティは、リクエストメソッドが`GET`で、エンドポイントの最後の SQL ステートメントが`SELECT`操作の場合にのみ使用できます。**ページネーションが**有効になっている場合、エンドポイントを呼び出す際にクエリ パラメータとして`page`と`page_size`を指定することで、結果をページネーションできます（例`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id?page=&page_size=` 。詳細については、[エンドポイントを呼び出す](#call-an-endpoint)参照してください。 > **注記：** > @@ -208,7 +208,7 @@ TiDB Cloud Data Serviceでは、以下のようにして1つまたは複数の > **注記：** > - > **バッチ操作**が有効になっているエンドポイントは、リクエスト本文に配列形式とオブジェクト形式の両方をサポートしています。 `[{dataObject1}, {dataObject2}]`と`{items: [{dataObject1}, {dataObject2}]}`です。他のシステムとの互換性を高めるため、オブジェクト形式`{items: [{dataObject1}, {dataObject2}]}`使用することをお勧めします。 + > **バッチ操作**が有効になっているエンドポイントは、リクエスト本文に配列形式とオブジェクト形式の両方をサポートしています。 `[{dataObject1}, {dataObject2}]`と`{items: [{dataObject1}, {dataObject2}]}`です。他のシステムとの互換性を高めるため、オブジェクト形式`{items: [{dataObject1}, {dataObject2}]}`を使用することをお勧めします。 ### SQL文を書く {#write-sql-statements} diff --git a/tidb-cloud/premium/migrate-from-op-tidb-premium.md b/tidb-cloud/premium/migrate-from-op-tidb-premium.md index 81cabdd611792..38886fcba8c6b 100644 --- a/tidb-cloud/premium/migrate-from-op-tidb-premium.md +++ b/tidb-cloud/premium/migrate-from-op-tidb-premium.md @@ -79,7 +79,7 @@ tiup update --self && tiup update dumpling 上流の TiDB Self-Managed クラスターからTiDB Cloud Premium に増分データを複製するには、 [TiCDCをデプロイする](https://docs.pingcap.com/tidb/dev/deploy-ticdc)必要があります。 -1. 現在の TiDB バージョンが TiCDC をサポートしているかどうかを確認します。 TiDB v4.0.8.rc.1 以降のバージョンは TiCDC をサポートします。 TiDB のバージョンを確認するには、TiDB Self-Managed クラスターで`select tidb_version();`実行します。アップグレードする必要がある場合は、 [TiUPを使用してTiDBをアップグレードする](https://docs.pingcap.com/tidb/dev/deploy-ticdc#upgrade-ticdc-using-tiup)参照してください。 +1. 現在の TiDB バージョンが TiCDC をサポートしているかどうかを確認します。 TiDB v4.0.8.rc.1 以降のバージョンは TiCDC をサポートします。 TiDB のバージョンを確認するには、TiDB Self-Managed クラスターで`select tidb_version();`を実行します。アップグレードする必要がある場合は、 [TiUPを使用してTiDBをアップグレードする](https://docs.pingcap.com/tidb/dev/deploy-ticdc#upgrade-ticdc-using-tiup)参照してください。 2. TiCDCコンポーネントをTiDB Self-Managedクラスターに追加します。 [TiUPを使用して、既存のTiDBクラスタにTiCDCを追加またはスケールアウトします](https://docs.pingcap.com/tidb/dev/deploy-ticdc#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup)参照してください。 `scale-out.yml`ファイルを編集して TiCDC を追加します。 diff --git a/tidb-cloud/releases/release-notes-2023.md b/tidb-cloud/releases/release-notes-2023.md index 6e4e63d1faeef..f6be73609c6e7 100644 --- a/tidb-cloud/releases/release-notes-2023.md +++ b/tidb-cloud/releases/release-notes-2023.md @@ -217,7 +217,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - [データサービス（ベータ版）](https://tidbcloud.com/project/data-service)開発エクスペリエンスを向上させるために`GET`リクエストのページ分割をサポートします。 - `GET`リクエストの場合、**アドバンスプロパティ**で**ページネーションを**有効にし、エンドポイントを呼び出す際にクエリパラメータとして`page`と`page_size`指定することで、結果をページ分けできます。例えば、1 ページあたり 10 項目の 2 ページ目を取得するには、次のコマンドを使用します。 + `GET`リクエストの場合、**アドバンスプロパティ**で**ページネーションを**有効にし、エンドポイントを呼び出す際にクエリパラメータとして`page`と`page_size`を指定することで、結果をページ分けできます。例えば、1 ページあたり 10 項目の 2 ページ目を取得するには、次のコマンドを使用します。 ```bash curl --digest --user ':' \ @@ -914,7 +914,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - TiDB Cloud CLI クライアント[`ticloud`](/tidb-cloud/cli-reference.md)を紹介します。 - `ticloud`使用すると、ターミナルやその他の自動ワークフローから数行のコマンドでTiDB Cloudリソースを簡単に管理できます。特にGitHub Actionsについては、 `ticloud`簡単に設定できるように[`setup-tidbcloud-cli`](https://github.com/marketplace/actions/set-up-tidbcloud-cli)提供しています。 + `ticloud`を使用すると、ターミナルやその他の自動ワークフローから数行のコマンドでTiDB Cloudリソースを簡単に管理できます。特にGitHub Actionsについては、 `ticloud`簡単に設定できるように[`setup-tidbcloud-cli`](https://github.com/marketplace/actions/set-up-tidbcloud-cli)提供しています。 詳細については、 [TiDB Cloud CLI クイックスタート](/tidb-cloud/get-started-with-cli.md)および[TiDB Cloud CLI リファレンス](/tidb-cloud/cli-reference.md)を参照してください。 diff --git a/tidb-cloud/releases/release-notes-2025.md b/tidb-cloud/releases/release-notes-2025.md index 728c505030c58..0d175451e142c 100644 --- a/tidb-cloud/releases/release-notes-2025.md +++ b/tidb-cloud/releases/release-notes-2025.md @@ -267,7 +267,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 分割動作の詳細については、 [MySQL以外のシンクの主キーまたは一意キーの`UPDATE`イベントを分割する](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)参照してください。 - - Google Cloud でホストされている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに新しいノード サイズ`32 vCPU, 64 GiB`指定します。 + - Google Cloud でホストされている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに新しいノード サイズ`32 vCPU, 64 GiB`を指定します。 この新しいノード サイズは、TiDB ノードで使用できます。 @@ -487,7 +487,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- Google Cloud でホストされている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに新しいノード サイズ`32 vCPU, 128 GiB`指定します。 +- Google Cloud でホストされている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに新しいノード サイズ`32 vCPU, 128 GiB`を指定します。 この新しいサイズは、TiDB、TiKV、およびTiFlashノードで使用できます。 diff --git a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md index 6a974fda65a7b..cbfdac1ea427c 100644 --- a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md +++ b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md @@ -152,6 +152,6 @@ SASL/SCRAM の代わりに、 IAM認証を使用して MSK クラスターと同 ## ステップ 5. TiDB Cloudで Amazon MSK プロビジョニングされたプライベートリンク接続を作成する {#step-5-create-an-amazon-msk-provisioned-private-link-connection-in-tidb-cloud} -MSK クラスターの`ARN`使用して、 TiDB Cloudにプライベート リンク接続を作成します。 +MSK クラスターの`ARN`を使用して、 TiDB Cloudにプライベート リンク接続を作成します。 詳細については[Amazon MSK プロビジョニングされたプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-amazon-msk-provisioned-private-link-connection)参照してください。 diff --git a/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md b/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md index fa03f03bbb491..8dd35b5ecb6cf 100644 --- a/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md +++ b/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md @@ -61,7 +61,7 @@ Confluent Cloud ネットワークの一意の名前を取得するには、次 TiDB Cloudでプライベート リンク接続を作成するには、次の手順を実行します。 -1. Confluent Cloud の`VPC Service Endpoint`使用して、 TiDB Cloudにプライベート リンク接続を作成します。 +1. Confluent Cloud の`VPC Service Endpoint`を使用して、 TiDB Cloudにプライベート リンク接続を作成します。 詳細については[AWS エンドポイントサービスプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-aws-endpoint-service-private-link-connection)参照してください。 diff --git a/tidb-cloud/serverless-private-link-connection.md b/tidb-cloud/serverless-private-link-connection.md index b74a70e824d70..f5ff6ed64dd7d 100644 --- a/tidb-cloud/serverless-private-link-connection.md +++ b/tidb-cloud/serverless-private-link-connection.md @@ -221,7 +221,7 @@ TiDB Cloudコンソールを使用してドメインをプライベート リン TiDB Cloud CLI を使用してTiDB Cloud管理対象ドメインをアタッチするには、次の手順を実行します。 -1. `dry run`使用すると、アタッチするドメインをプレビューできます。次のステップで使用する一意の名前が出力されます。 +1. `dry run`を使用すると、アタッチするドメインをプレビューできます。次のステップで使用する一意の名前が出力されます。 ```shell ticloud serverless private-link-connection attach-domains -c --private-link-connection-id --type TIDBCLOUD_MANAGED --dry-run diff --git a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md index 34e413c0f2102..81859bb6e0b51 100644 --- a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md +++ b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md @@ -181,7 +181,7 @@ VM をプロビジョニングするには、 [VMインスタンス](https://con - 外部: `39092` - 外部アドバタイズされたリスナーポートの範囲: `9093~9095` -2. SSHを使用して各ブローカーノードにログインします。各ブローカーノードごとに、以下の内容を含む設定ファイル`~/config/server.properties`作成します。 +2. SSHを使用して各ブローカーノードにログインします。各ブローカーノードごとに、以下の内容を含む設定ファイル`~/config/server.properties`を作成します。 ```properties # broker-node1 ~/config/server.properties @@ -356,7 +356,7 @@ VM をプロビジョニングするには、 [VMインスタンス](https://con consume_messages ``` -4. `produce.sh`と`consume.sh`実行して、Kafkaクラスターが実行中であることを確認してください。これらのスクリプトは、後ほどネットワーク接続テストにも再利用されます。スクリプトは`--partitions 3 --replication-factor 3`のトピックを作成します。3つのブローカーすべてにデータが含まれていることを確認してください。ネットワーク接続がテストされるよう、スクリプトが3つのブローカーすべてに接続されることを確認してください。 +4. `produce.sh`と`consume.sh`を実行して、Kafkaクラスターが実行中であることを確認してください。これらのスクリプトは、後ほどネットワーク接続テストにも再利用されます。スクリプトは`--partitions 3 --replication-factor 3`のトピックを作成します。3つのブローカーすべてにデータが含まれていることを確認してください。ネットワーク接続がテストされるよう、スクリプトが3つのブローカーすべてに接続されることを確認してください。 ```shell # Test write message. diff --git a/tidb-cloud/size-your-cluster.md b/tidb-cloud/size-your-cluster.md index 7d085ff3ec2ea..e03027847bdf1 100644 --- a/tidb-cloud/size-your-cluster.md +++ b/tidb-cloud/size-your-cluster.md @@ -69,7 +69,7 @@ TiDBノード数が8未満の場合、パフォーマンス偏差係数はほぼ `node count = ceil(overall expected performance ÷ performance per node * (1 - performance deviation coefficient))` -式では、まず`node count = ceil(overall expected performance ÷ performance per node)`計算して大まかなノード数を取得し、対応するパフォーマンス偏差係数を使用してノード数の最終結果を取得する必要があります。 +式では、まず`node count = ceil(overall expected performance ÷ performance per node)`を計算して大まかなノード数を取得し、対応するパフォーマンス偏差係数を使用してノード数の最終結果を取得する必要があります。 例えば、混合ワークロードにおける全体的な期待パフォーマンスが 110,000 QPS、P95レイテンシーが約 100 ミリ秒で、8 vCPU、16 GiB の TiDB ノードを使用したいとします。この場合、前述の表から 8 vCPU、16 GiB の TiDB ノードの推定 TiDB パフォーマンス（ `15,500` ）を取得し、以下のように TiDB ノードの大まかな数を計算できます。 @@ -159,7 +159,7 @@ TiKVノード数が8未満の場合、パフォーマンス偏差係数はほぼ `node count = ceil(overall expected performance ÷ performance per node * (1 - performance deviation coefficient))` -式では、まず`node count = ceil(overall expected performance ÷ performance per node)`計算して大まかなノード数を取得し、対応するパフォーマンス偏差係数を使用してノード数の最終結果を取得する必要があります。 +式では、まず`node count = ceil(overall expected performance ÷ performance per node)`を計算して大まかなノード数を取得し、対応するパフォーマンス偏差係数を使用してノード数の最終結果を取得する必要があります。 例えば、混合ワークロードにおける全体的な期待パフォーマンスが110,000 QPS、P95レイテンシーが約100ミリ秒で、8 vCPU、32 GiB TiKVノードを使用したいとします。この場合、前述の表から8 vCPU、32 GiB TiKVノードの推定TiKVパフォーマンス（ `17,800` ）を取得し、TiKVノードの大まかな数を以下のように計算します。 diff --git a/tidb-cloud/terraform-use-backup-resource.md b/tidb-cloud/terraform-use-backup-resource.md index e253b87a1454e..b76cb8f95e0f5 100644 --- a/tidb-cloud/terraform-use-backup-resource.md +++ b/tidb-cloud/terraform-use-backup-resource.md @@ -99,7 +99,7 @@ summary: tidbcloud_backup` リソースを使用してTiDB Cloudクラスター ``` -5. `terraform state show tidbcloud_backup.${resource-name}`使用してバックアップのステータスを確認します。 +5. `terraform state show tidbcloud_backup.${resource-name}`を使用してバックアップのステータスを確認します。 $ terraform state show tidbcloud_backup.example_backup @@ -157,6 +157,6 @@ summary: tidbcloud_backup` リソースを使用してTiDB Cloudクラスター Enter a value: yes -ここで、コマンド`terraform show`実行すると、リソースがクリアされているため何も表示されません。 +ここで、コマンド`terraform show`を実行すると、リソースがクリアされているため何も表示されません。 $ terraform show diff --git a/tidb-cloud/terraform-use-cluster-resource.md b/tidb-cloud/terraform-use-cluster-resource.md index 3c179c1474030..0aa2fdcf3bab2 100644 --- a/tidb-cloud/terraform-use-cluster-resource.md +++ b/tidb-cloud/terraform-use-cluster-resource.md @@ -7,11 +7,11 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを > **警告：** > -> [TiDB Cloud Terraform プロバイダー](https://registry.terraform.io/providers/tidbcloud/tidbcloud) v0.4.0以降、リソース`tidbcloud_cluster`非推奨となりました。代わりにリソース`tidbcloud_dedicated_cluster`またはリソース`tidbcloud_serverless_cluster`使用することをお勧めします。詳細については、 [`tidbcloud_dedicated_cluster`リソースを使用する](/tidb-cloud/terraform-use-dedicated-cluster-resource.md)または[`tidbcloud_serverless_cluster`リソースを使用する](/tidb-cloud/terraform-use-serverless-cluster-resource.md)をご覧ください。 +> [TiDB Cloud Terraform プロバイダー](https://registry.terraform.io/providers/tidbcloud/tidbcloud) v0.4.0以降、リソース`tidbcloud_cluster`非推奨となりました。代わりにリソース`tidbcloud_dedicated_cluster`またはリソース`tidbcloud_serverless_cluster`を使用することをお勧めします。詳細については、 [`tidbcloud_dedicated_cluster`リソースを使用する](/tidb-cloud/terraform-use-dedicated-cluster-resource.md)または[`tidbcloud_serverless_cluster`リソースを使用する](/tidb-cloud/terraform-use-serverless-cluster-resource.md)をご覧ください。 このドキュメントでは、 `tidbcloud_cluster`リソースを使用してTiDB Cloudクラスターを管理する方法を学習できます。 -さらに、データ ソース`tidbcloud_projects`と`tidbcloud_cluster_specs`使用して必要な情報を取得する方法も学習します。 +さらに、データ ソース`tidbcloud_projects`と`tidbcloud_cluster_specs`を使用して必要な情報を取得する方法も学習します。 `tidbcloud_cluster`リソースの機能は次のとおりです。 @@ -68,7 +68,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを 2. 設定を適用するには、コマンド`terraform apply`を実行してください。続行するには、確認プロンプトで`yes`と入力してください。 - プロンプトをスキップするには、 `terraform apply --auto-approve`使用します。 + プロンプトをスキップするには、 `terraform apply --auto-approve`を使用します。 $ terraform apply --auto-approve @@ -546,7 +546,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の Apply complete! Resources: 0 added, 1 changed, 0 destroyed. -4. ステータスを確認するには`terraform state show tidbcloud_cluster.${resource-name}`使用します。 +4. ステータスを確認するには`terraform state show tidbcloud_cluster.${resource-name}`を使用します。 $ terraform state show tidbcloud_cluster.example_cluster @@ -899,11 +899,11 @@ Terraform で管理されていない TiDB クラスターの場合は、イン region = "eu-central-1" } -5. `terraform fmt`使用して構成ファイルをフォーマットできます。 +5. `terraform fmt`を使用して構成ファイルをフォーマットできます。 $ terraform fmt -6. 設定と状態の一貫性を確保するには、 `terraform plan`または`terraform apply`実行してください。 `No changes`が表示されれば、インポートは成功です。 +6. 設定と状態の一貫性を確保するには、 `terraform plan`または`terraform apply`を実行してください。 `No changes`が表示されれば、インポートは成功です。 $ terraform apply @@ -931,6 +931,6 @@ Terraform で管理されていない TiDB クラスターの場合は、イン Enter a value: yes -ここで、コマンド`terraform show`実行すると、リソースがクリアされているため何も表示されません。 +ここで、コマンド`terraform show`を実行すると、リソースがクリアされているため何も表示されません。 $ terraform show diff --git a/tidb-cloud/terraform-use-dedicated-cluster-resource.md b/tidb-cloud/terraform-use-dedicated-cluster-resource.md index 756c02618104e..a0b618637555f 100644 --- a/tidb-cloud/terraform-use-dedicated-cluster-resource.md +++ b/tidb-cloud/terraform-use-dedicated-cluster-resource.md @@ -64,7 +64,7 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi 2. 設定を適用するには、コマンド`terraform apply`を実行してください。続行するには、確認プロンプトで`yes`と入力してください。 - プロンプトをスキップするには、 `terraform apply --auto-approve`使用します。 + プロンプトをスキップするには、 `terraform apply --auto-approve`を使用します。 ```shell $ terraform apply --auto-approve @@ -244,7 +244,7 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi 通常、 TiDB Cloud Dedicated クラスターの作成には少なくとも 10 分かかります。 -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_cluster.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_cluster.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_dedicated_cluster.example_cluster @@ -486,7 +486,7 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 Apply complete! Resources: 0 added, 1 changed, 0 destroyed. ``` -4. `terraform state show tidbcloud_dedicated_cluster.${resource-name}`使用して状態を確認します。 +4. `terraform state show tidbcloud_dedicated_cluster.${resource-name}`を使用して状態を確認します。 $ terraform state show tidbcloud_dedicated_cluster.example_cluster @@ -1021,7 +1021,7 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 Apply complete! Resources: 0 added, 0 changed, 1 destroyed. ``` -ここで、コマンド`terraform show`実行すると、リソースがクリアされているため何も表示されません。 +ここで、コマンド`terraform show`を実行すると、リソースがクリアされているため何も表示されません。 $ terraform show @@ -1054,7 +1054,7 @@ Terraform によって管理されていない TiDB クラスターの場合は 生成された構成ファイルを確認し、ニーズを満たしていることを確認してください。必要に応じて、このファイルの内容を任意の場所に移動することもできます。 - 次に、 `terraform apply`実行してインフラストラクチャをインポートします。適用後、出力例は次のようになります。 + 次に、 `terraform apply`を実行してインフラストラクチャをインポートします。適用後、出力例は次のようになります。 ```shell tidbcloud_dedicated_cluster.example_cluster: Importing... diff --git a/tidb-cloud/terraform-use-dedicated-network-container-resource.md b/tidb-cloud/terraform-use-dedicated-network-container-resource.md index 9168133332c00..c6999423378fd 100644 --- a/tidb-cloud/terraform-use-dedicated-network-container-resource.md +++ b/tidb-cloud/terraform-use-dedicated-network-container-resource.md @@ -114,7 +114,7 @@ summary: tidbcloud_dedicated_network_container` リソースを使用して、 T TiDB Cloud Dedicated ネットワークコンテナのリージョンにTiDB Cloud Dedicated クラスターを作成するまで、リソースのステータスは`INACTIVE`ままです。その後、ステータスは`ACTIVE`に変わります。 -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_network_container.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_network_container.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_dedicated_network_container.example @@ -165,7 +165,7 @@ Terraform によって管理されていないTiDB Cloud Dedicated ネットワ 生成された構成ファイルを確認し、ニーズを満たしていることを確認してください。必要に応じて、このファイルの内容を任意の場所に移動することもできます。 - 次に、 `terraform apply`実行してインフラストラクチャをインポートします。適用後、出力例は次のようになります。 + 次に、 `terraform apply`を実行してインフラストラクチャをインポートします。適用後、出力例は次のようになります。 ```shell tidbcloud_dedicated_network_container.example: Importing... [id=10423692645683000000,example] diff --git a/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md b/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md index 751d23874e18b..500a468cb2333 100644 --- a/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md +++ b/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md @@ -117,7 +117,7 @@ summary: tidbcloud_dedicated_private_endpoint_connection` リソースを使用 Apply complete! Resources: 1 added, 0 changed, 0 destroyed. ``` -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_private_endpoint_connection.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_private_endpoint_connection.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_dedicated_private_endpoint_connection.example @@ -230,6 +230,6 @@ TiDB Cloud Dedicated プライベート エンドポイント接続を削除す Apply complete! Resources: 0 added, 0 changed, 1 destroyed. ``` -ここで、コマンド`terraform show`実行すると、リソースがクリアされているため何も表示されません。 +ここで、コマンド`terraform show`を実行すると、リソースがクリアされているため何も表示されません。 $ terraform show diff --git a/tidb-cloud/terraform-use-import-resource.md b/tidb-cloud/terraform-use-import-resource.md index 3788b4b59a276..1b427bfe9dec8 100644 --- a/tidb-cloud/terraform-use-import-resource.md +++ b/tidb-cloud/terraform-use-import-resource.md @@ -83,7 +83,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク tidbcloud_import.example_local: Creating... tidbcloud_import.example_local: Creation complete after 6s [id=781074] -4. `terraform state show tidbcloud_import.${resource-name}`使用してインポート タスクのステータスを確認します。 +4. `terraform state show tidbcloud_import.${resource-name}`を使用してインポート タスクのステータスを確認します。 $ terraform state show tidbcloud_import.example_local # tidbcloud_import.example_local: @@ -122,7 +122,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク type = "LOCAL" } -5. 数分後にステータスを更新するには`terraform refresh`使用します。 +5. 数分後にステータスを更新するには`terraform refresh`を使用します。 $ terraform refresh && terraform state show tidbcloud_import.example_local tidbcloud_import.example_local: Refreshing state... [id=781074] @@ -231,7 +231,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク tidbcloud_import.example_s3_parquet: Creating... tidbcloud_import.example_s3_parquet: Creation complete after 4s [id=781076] -3. `terraform refresh`と`terraform state show tidbcloud_import.${resource-name}`使用して、インポート タスクのステータスを更新および確認します。 +3. `terraform refresh`と`terraform state show tidbcloud_import.${resource-name}`を使用して、インポート タスクのステータスを更新および確認します。 ## インポートタスクを更新する {#update-an-import-task} diff --git a/tidb-cloud/terraform-use-serverless-branch-resource.md b/tidb-cloud/terraform-use-serverless-branch-resource.md index 06b4371bc1743..3ac49bd6d27a2 100644 --- a/tidb-cloud/terraform-use-serverless-branch-resource.md +++ b/tidb-cloud/terraform-use-serverless-branch-resource.md @@ -116,7 +116,7 @@ summary: サーバーレス ブランチ リソースを使用して、 TiDB Clo Apply complete! Resources: 1 added, 0 changed, 0 destroyed. ``` -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_branch.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_branch.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_branch.example @@ -185,7 +185,7 @@ Terraform によって管理されていないTiDB Cloud Starter またはTiDB C 生成された構成ファイルを確認し、ニーズを満たしていることを確認してください。必要に応じて、このファイルの内容を任意の場所に移動することもできます。 - 次に、 `terraform apply`実行してインフラストラクチャをインポートします。適用後、出力例は次のようになります。 + 次に、 `terraform apply`を実行してインフラストラクチャをインポートします。適用後、出力例は次のようになります。 ```shell tidbcloud_serverless_branch.example: Importing... diff --git a/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md b/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md index 6d7a23b15867a..616511b46f297 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md @@ -64,7 +64,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Ess 2. 設定を適用するには、コマンド`terraform apply`を実行してください。続行するには、確認プロンプトで`yes`と入力してください。 - プロンプトをスキップするには、 `terraform apply --auto-approve`使用します。 + プロンプトをスキップするには、 `terraform apply --auto-approve`を使用します。 ```shell $ terraform apply --auto-approve @@ -226,7 +226,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Ess Apply complete! Resources: 1 added, 0 changed, 0 destroyed. ``` -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_cluster.example @@ -357,7 +357,7 @@ tidbcloud_serverless_cluster.example: Modifications complete after 8s Apply complete! Resources: 0 added, 1 changed, 0 destroyed. ``` -次に、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`使用してリソースの状態を確認します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +次に、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`を使用してリソースの状態を確認します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_cluster.example @@ -444,7 +444,7 @@ Terraform によって管理されていないTiDB Cloud Essential クラスタ 生成された構成ファイルを確認し、ニーズを満たしていることを確認してください。必要に応じて、このファイルの内容を任意の場所に移動することもできます。 - 次に、 `terraform apply`実行してインフラストラクチャをインポートします。適用後、出力例は次のようになります。 + 次に、 `terraform apply`を実行してインフラストラクチャをインポートします。適用後、出力例は次のようになります。 ```shell tidbcloud_serverless_cluster.example: Importing... diff --git a/tidb-cloud/terraform-use-serverless-cluster-resource.md b/tidb-cloud/terraform-use-serverless-cluster-resource.md index dfaffd90e0145..adf68013365a3 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource.md @@ -64,7 +64,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Sta 2. 設定を適用するには、コマンド`terraform apply`を実行してください。続行するには、確認プロンプトで`yes`と入力してください。 - プロンプトをスキップするには、 `terraform apply --auto-approve`使用します。 + プロンプトをスキップするには、 `terraform apply --auto-approve`を使用します。 ```shell $ terraform apply --auto-approve @@ -224,7 +224,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Sta Apply complete! Resources: 1 added, 0 changed, 0 destroyed. ``` -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_cluster.example @@ -352,7 +352,7 @@ tidbcloud_serverless_cluster.example: Modifications complete after 8s Apply complete! Resources: 0 added, 1 changed, 0 destroyed. ``` -次に、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`使用してリソースの状態を確認します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +次に、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`を使用してリソースの状態を確認します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_cluster.example @@ -438,7 +438,7 @@ Terraform によって管理されていないTiDB Cloud Starter クラスター 生成された構成ファイルを確認し、ニーズを満たしていることを確認してください。必要に応じて、このファイルの内容を任意の場所に移動することもできます。 - 次に、 `terraform apply`実行してインフラストラクチャをインポートします。適用後、出力例は次のようになります。 + 次に、 `terraform apply`を実行してインフラストラクチャをインポートします。適用後、出力例は次のようになります。 ```shell tidbcloud_serverless_cluster.example: Importing... diff --git a/tidb-cloud/terraform-use-serverless-export-resource.md b/tidb-cloud/terraform-use-serverless-export-resource.md index b2e626a8751f6..f7fa47f6388a8 100644 --- a/tidb-cloud/terraform-use-serverless-export-resource.md +++ b/tidb-cloud/terraform-use-serverless-export-resource.md @@ -115,9 +115,9 @@ summary: tidbcloud_serverless_export` リソースを使用して、 TiDB Cloud この例では、 `tidbcloud_serverless_export.example`リソースがクラスター全体からデータをエクスポートするエクスポート タスクを作成します。 - このリソースは同期されていません。1 `terraform refresh`使用すると最新の状態を取得できます。 + このリソースは同期されていません。1 `terraform refresh`を使用すると最新の状態を取得できます。 -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_export.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_export.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_export.example @@ -167,7 +167,7 @@ TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータ エ 生成された構成ファイルを確認し、ニーズを満たしていることを確認してください。必要に応じて、このファイルの内容を任意の場所に移動することもできます。 - 次に、 `terraform apply`実行してインフラストラクチャをインポートします。適用後、出力例は次のようになります。 + 次に、 `terraform apply`を実行してインフラストラクチャをインポートします。適用後、出力例は次のようになります。 ```shell tidbcloud_serverless_export.example: Importing... diff --git a/tidb-cloud/terraform-use-sql-user-resource.md b/tidb-cloud/terraform-use-sql-user-resource.md index f882364a431f6..ef3ea8fc58c82 100644 --- a/tidb-cloud/terraform-use-sql-user-resource.md +++ b/tidb-cloud/terraform-use-sql-user-resource.md @@ -107,7 +107,7 @@ summary: tidbcloud_sql_user` リソースを使用してTiDB Cloud SQL ユーザ Apply complete! Resources: 1 added, 0 changed, 0 destroyed. ``` -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_sql_user.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_sql_user.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_sql_user.example @@ -178,7 +178,7 @@ summary: tidbcloud_sql_user` リソースを使用してTiDB Cloud SQL ユーザ Apply complete! Resources: 0 added, 1 changed, 0 destroyed. ``` -4. `terraform state show tidbcloud_sql_user.${resource-name}`使用して状態を確認します。 +4. `terraform state show tidbcloud_sql_user.${resource-name}`を使用して状態を確認します。 $ terraform state show tidbcloud_sql_user.example # tidbcloud_sql_user.example: @@ -269,6 +269,6 @@ SQL ユーザーを削除するには、 `tidbcloud_sql_user`リソースの構 Apply complete! Resources: 0 added, 0 changed, 1 destroyed. ``` -ここで、コマンド`terraform show`実行すると、リソースがクリアされているため何も表示されません。 +ここで、コマンド`terraform show`を実行すると、リソースがクリアされているため何も表示されません。 $ terraform show diff --git a/tidb-cloud/ticloud-cluster-create.md b/tidb-cloud/ticloud-cluster-create.md index 5fcd0eb1f74d8..c8a8fca02c537 100644 --- a/tidb-cloud/ticloud-cluster-create.md +++ b/tidb-cloud/ticloud-cluster-create.md @@ -46,7 +46,7 @@ ticloud serverless create --display-name --region --max- | -n, --display-name 文字列 | 作成するクラスターの名前を指定します。 | はい | 非対話型モードでのみ動作します。 | | --spending-limit-monthly int | 月間最大支出限度額を USD セント単位で指定します。 | いいえ | 非対話型モードでのみ動作します。 | | -p, --project-id 文字列 | クラスターが作成されるプロジェクトのIDを指定します。デフォルト値は`default project`です。 | いいえ | 非対話型モードでのみ動作します。 | -| -r, --region 文字列 | クラウドリージョンの名前を指定します。1 コマンド`ticloud serverless region`使用すると、利用可能なすべてのリージョンを表示できます。 | はい | 非対話型モードでのみ動作します。 | +| -r, --region 文字列 | クラウドリージョンの名前を指定します。1 コマンド`ticloud serverless region`を使用すると、利用可能なすべてのリージョンを表示できます。 | はい | 非対話型モードでのみ動作します。 | | --disable-public-endpoint | パブリックエンドポイントを無効にします。クラスターへのパブリックアクセスを禁止する場合は、このオプションを使用します。 | いいえ | 非対話型モードでのみ動作します。 | | --encryption | 二重層データ暗号化を有効にします。TiDB Cloud Essential クラスタではデフォルトで有効、 TiDB Cloud Starter クラスタではデフォルトで無効になっています。 | いいえ | 非対話型モードでのみ動作します。 | | --max-rcu int32 | TiDB Cloud Essential クラスターの最大リクエスト容量単位 (RCU) を 100000 まで設定します。 | いいえ | 非対話型モードでのみ動作します。 | diff --git a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md index 151e4a61b2df1..243699103bfad 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md +++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md @@ -37,7 +37,7 @@ ticloud serverless audit-log filter-rule create --cluster-id --disp | -------------------- | ------------------------------------------------------------------------------------- | --- | ------------------------------------ | | -c, --cluster-id 文字列 | クラスターの ID。 | はい | 非対話型モードでのみ動作します。 | | --display-name 文字列 | フィルター ルールの表示名。 | はい | 非対話型モードでのみ動作します。 | -| --rule | フィルタールール式。フィルターテンプレートを表示するには`ticloud serverless audit-log filter-rule template`使用します。 | はい | 非対話型モードでのみ動作します。 | +| --rule | フィルタールール式。フィルターテンプレートを表示するには`ticloud serverless audit-log filter-rule template`を使用します。 | はい | 非対話型モードでのみ動作します。 | | -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | ## 継承されたフラグ {#inherited-flags} diff --git a/tidb-cloud/tidb-cloud-import-local-files.md b/tidb-cloud/tidb-cloud-import-local-files.md index 3e5e9de1762df..615ca22a98e3a 100644 --- a/tidb-cloud/tidb-cloud-import-local-files.md +++ b/tidb-cloud/tidb-cloud-import-local-files.md @@ -100,7 +100,7 @@ CREATE TABLE `import_test` ( LOAD DATA LOCAL INFILE 'load.txt' INTO TABLE import_test FIELDS TERMINATED BY ',' (name, address); ``` -`mysql`使用していて`ERROR 2068 (HY000): LOAD DATA LOCAL INFILE file request rejected due to restrictions on access.`遭遇した場合は、接続文字列に`--local-infile=true`追加できます。 +`mysql`を使用していて`ERROR 2068 (HY000): LOAD DATA LOCAL INFILE file request rejected due to restrictions on access.`遭遇した場合は、接続文字列に`--local-infile=true`追加できます。 ### TiDB Cloudにデータをインポートした後、予約キーワードを含む列をクエリできないのはなぜですか? {#why-can-t-i-query-a-column-with-a-reserved-keyword-after-importing-data-into-tidb-cloud} @@ -110,7 +110,7 @@ LOAD DATA LOCAL INFILE 'load.txt' INTO TABLE import_test FIELDS TERMINATED BY ', ファイルが250MiBより大きい場合は、 [TiDB Cloud CLI](/tidb-cloud/get-started-with-cli.md)使用してファイルをインポートできます。詳細については、 [`ticloud serverless import start`](/tidb-cloud/ticloud-import-start.md)を参照してください。 -あるいは、 `split [-l ${line_count}]`ユーティリティを使って複数の小さなファイルに分割することもできます（LinuxまたはmacOSのみ）。例えば、 `split -l 100000 tidb-01.csv small_files`実行すると、 `tidb-01.csv`というファイルが行長`100000`で分割され、分割後のファイルの名前は`small_files${suffix}`なります。その後、これらの小さなファイルをTiDB Cloudに1つずつインポートできます。 +あるいは、 `split [-l ${line_count}]`ユーティリティを使って複数の小さなファイルに分割することもできます（LinuxまたはmacOSのみ）。例えば、 `split -l 100000 tidb-01.csv small_files`を実行すると、 `tidb-01.csv`というファイルが行長`100000`で分割され、分割後のファイルの名前は`small_files${suffix}`なります。その後、これらの小さなファイルをTiDB Cloudに1つずつインポートできます。 次のスクリプトを参照してください。 diff --git a/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md b/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md index 1db04a06a8f5c..f227b87aae8d9 100644 --- a/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md +++ b/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md @@ -53,8 +53,8 @@ mysql --connect-timeout 15 --ssl-mode=VERIFY_IDENTITY --ssl-ca=ca.pem --tls-vers パラメータの説明： - `--ssl-mode=VERIFY_IDENTITY`では、MySQL CLI クライアントは TLS を有効にし、 TiDB Cloud Dedicated クラスターを検証することを強制します。 -- `--ssl-ca=`使用して、ダウンロードした TiDB クラスター`ca.pem`のローカル パスを指定します。 -- TLSプロトコルのバージョンを制限するには、 `--tls-version=TLSv1.2`使用します。TLS 1.3を使用する場合は、バージョンを`TLSv1.3`に設定できます。 +- `--ssl-ca=`を使用して、ダウンロードした TiDB クラスター`ca.pem`のローカル パスを指定します。 +- TLSプロトコルのバージョンを制限するには、 `--tls-version=TLSv1.2`を使用します。TLS 1.3を使用する場合は、バージョンを`TLSv1.3`に設定できます。
    @@ -68,7 +68,7 @@ mycli --ssl-ca=ca.pem --ssl-verify-server-cert -u root -h tidb.eqlfbdgthh8.clust パラメータの説明： -- `--ssl-ca=`使用して、ダウンロードした TiDB クラスター`ca.pem`のローカル パスを指定します。 +- `--ssl-ca=`を使用して、ダウンロードした TiDB クラスター`ca.pem`のローカル パスを指定します。 - `--ssl-verify-server-cert`でTiDB Cloud Dedicated クラスターを検証します。
    @@ -140,7 +140,7 @@ jdbc:mysql://tidb.srgnqxji5bc.clusters.staging.tidb-cloud.com:4000/test?user=roo パラメータの説明： - TLS を有効にしてTiDB Cloud Dedicated クラスターを検証するには、 `ssl_mode="VERIFY_IDENTITY"`設定します。 -- `ssl={"ca": ""}`使用して、ダウンロードした TiDB クラスター`ca.pem`のローカル パスを指定します。 +- `ssl={"ca": ""}`を使用して、ダウンロードした TiDB クラスター`ca.pem`のローカル パスを指定します。
    diff --git a/tidb-cloud/transaction-concepts.md b/tidb-cloud/transaction-concepts.md index 79a62d2934ca8..46cbe1a4401ea 100644 --- a/tidb-cloud/transaction-concepts.md +++ b/tidb-cloud/transaction-concepts.md @@ -17,7 +17,7 @@ TiDBの楽観的トランザクションモデルは、コミットフェーズ ## 悲観的なトランザクションモード {#pessimistic-transaction-mode} -TiDBでは、悲観的トランザクションモードはMySQLとほぼ同じ動作をします。トランザクションは実行フェーズでロックを適用し、競合状況での再試行を回避し、高い成功率を保証します。悲観的ロックを適用することで、 `SELECT FOR UPDATE`使用して事前にデータをロックすることもできます。 +TiDBでは、悲観的トランザクションモードはMySQLとほぼ同じ動作をします。トランザクションは実行フェーズでロックを適用し、競合状況での再試行を回避し、高い成功率を保証します。悲観的ロックを適用することで、 `SELECT FOR UPDATE`を使用して事前にデータをロックすることもできます。 ただし、アプリケーション シナリオの競合が少ない場合は、楽観的トランザクション モデルの方がパフォーマンスが向上します。 diff --git a/tidb-cloud/use-chat2query-sessions.md b/tidb-cloud/use-chat2query-sessions.md index ec44cc74c158f..13ba09071b633 100644 --- a/tidb-cloud/use-chat2query-sessions.md +++ b/tidb-cloud/use-chat2query-sessions.md @@ -5,7 +5,7 @@ summary: Chat2Query セッション関連 API を使用して、マルチラウ # マルチラウンドChat2Queryを開始する {#start-multi-round-chat2query} -Chat2Query API v3以降では、セッション関連のエンドポイントを呼び出すことで、複数ラウンドのチャットを開始できます`/v3/chat2data`エンドポイントから返される`session_id`使用して、次のラウンドで会話を続行できます。 +Chat2Query API v3以降では、セッション関連のエンドポイントを呼び出すことで、複数ラウンドのチャットを開始できます`/v3/chat2data`エンドポイントから返される`session_id`を使用して、次のラウンドで会話を続行できます。 ## 始める前に {#before-you-begin} diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md index 5daacd14614b2..9568c4995c5ed 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md @@ -88,7 +88,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ SET tidb_index_serial_scan_concurrency=16; ``` -5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`実行します。同時実行ごとにテストは 2 時間かかります。 +5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2 時間かかります。 ```shell go-tpc tpcc --host ${HOST} -P 4000 --warehouses 1000 run -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md index e9575f4d31436..031a4c2cb4cf8 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md @@ -89,7 +89,7 @@ aliases: ['/ja/tidbcloud/v7.1.0-performance-benchmarking-with-tpcc'] SET tidb_index_serial_scan_concurrency=16; ``` -5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`実行します。同時実行ごとにテストは 2 時間かかります。 +5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2 時間かかります。 ```shell go-tpc tpcc --host ${HOST} -P 4000 --warehouses 1000 run -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md index 5421626304f9d..bcd206886f175 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md @@ -89,7 +89,7 @@ aliases: ['/ja/tidbcloud/v7.5.0-performance-benchmarking-with-tpcc'] SET tidb_index_serial_scan_concurrency=16; ``` -5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`実行します。同時実行ごとにテストは 2 時間かかります。 +5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2 時間かかります。 ```shell go-tpc tpcc --host ${HOST} -P 4000 --warehouses 1000 run -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md index a4b676a81667d..5a4bf1fc5b4c4 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md @@ -100,7 +100,7 @@ raft-engine.prefill-for-recycle = true SET tidb_index_serial_scan_concurrency=16; ``` -5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`実行します。同時実行ごとにテストは 2 時間かかります。 +5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2 時間かかります。 ```shell go-tpc tpcc --host ${HOST} -P 4000 --warehouses 1000 run -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md index 313fad506bf4d..decdedad16a1b 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md @@ -100,7 +100,7 @@ raft-engine.prefill-for-recycle = true SET tidb_index_serial_scan_concurrency=16; ``` -5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`実行します。同時実行ごとにテストは 2 時間かかります。 +5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2 時間かかります。 ```shell go-tpc tpcc --host ${HOST} -P 4000 --warehouses 1000 run -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-computing.md b/tidb-computing.md index 7e07dd5d674d5..8d87a2eb64462 100644 --- a/tidb-computing.md +++ b/tidb-computing.md @@ -114,7 +114,7 @@ SQL コンピューティングの最もシンプルなソリューションは 1. キー範囲を構築します。表内のすべての`RowID` `[0, MaxInt64)`範囲に含まれます。行データの`Key`エンコード規則に従って、 `0`と`MaxInt64`を使用すると、左閉じ、右開きの`[StartKey, EndKey)`範囲を構築できます。 2. キー範囲のスキャン: 上記で構築されたキー範囲に従って TiKV 内のデータを読み取ります。 3. データのフィルタリング：読み込んだデータ行ごとに、式`name = "TiDB"`を計算します。結果が`true`場合は、この行に戻ります。そうでない場合は、この行をスキップします。 -4. `Count(*)`計算します。要件を満たす行ごとに、 `Count(*)`の結果を合計します。 +4. `Count(*)`を計算します。要件を満たす行ごとに、 `Count(*)`の結果を合計します。 **全体のプロセスは次のように示されます。** diff --git a/tidb-control.md b/tidb-control.md index a7f01b1b77676..699bc03586d39 100644 --- a/tidb-control.md +++ b/tidb-control.md @@ -26,7 +26,7 @@ TiUPをインストールした後、 `tiup ctl:v tidb`コマ ### ソースコードからコンパイルする {#compile-from-source-code} - コンパイル環境要件: [Go](https://golang.org/) 1.25以降 -- コンパイル手順: [TiDB制御プロジェクト](https://github.com/pingcap/tidb-ctl)のルート ディレクトリに移動し、 `make`コマンドを使用してコンパイルし、 `tidb-ctl`生成します。 +- コンパイル手順: [TiDB制御プロジェクト](https://github.com/pingcap/tidb-ctl)のルート ディレクトリに移動し、 `make`コマンドを使用してコンパイルし、 `tidb-ctl`を生成します。 - コンパイル ドキュメント: ヘルプ ファイルは`doc`ディレクトリにあります。ヘルプ ファイルが失われた場合、または更新する場合は、 `make doc`コマンドを使用してヘルプ ファイルを生成します。 ## 使い方の紹介 {#usage-introduction} @@ -59,16 +59,16 @@ TiUPをインストールした後、 `tiup ctl:v tidb`コマ ### ヘルプを受ける {#get-help} -使用情報を取得するには`tidb-ctl -h/--help`使用します。 +使用情報を取得するには`tidb-ctl -h/--help`を使用します。 TiDBコントロールは複数のコマンド層で構成されています。各コマンド／サブコマンドの後に`-h/--help`を付けると、それぞれの使用状況情報を取得できます。 次の例は、スキーマ情報を取得する方法を示しています。 -使用方法の詳細を取得するには、 `tidb-ctl schema -h`使用します。 `schema`コマンド自体には、 `in`と`tid` 2つのサブコマンドがあります。 +使用方法の詳細を取得するには、 `tidb-ctl schema -h`を使用します。 `schema`コマンド自体には、 `in`と`tid` 2つのサブコマンドがあります。 - `in` 、データベース名を通じてデータベース内のすべてのテーブルのテーブル スキーマを取得するために使用されます。 -- `tid` 、データベース全体で一意の`table_id`使用してテーブル スキーマを取得するために使用されます。 +- `tid` 、データベース全体で一意の`table_id`を使用してテーブル スキーマを取得するために使用されます。 ### グローバルオプション {#global-options} @@ -98,7 +98,7 @@ TiDBコントロールは複数のコマンド層で構成されています。 tidb-ctl schema in ``` -たとえば、 `tidb-ctl schema in mysql`実行すると次の結果が返されます。 +たとえば、 `tidb-ctl schema in mysql`を実行すると次の結果が返されます。 ```json [ @@ -118,7 +118,7 @@ tidb-ctl schema in 結果はJSON形式で表示されます。（上記の出力は切り捨てられています。） -- テーブル名を指定する場合は、 `tidb-ctl schema in -n `使用してフィルタリングします。 +- テーブル名を指定する場合は、 `tidb-ctl schema in -n
    `を使用してフィルタリングします。 たとえば、 `tidb-ctl schema in mysql -n db` `mysql`データベース内の`db`テーブルのテーブル スキーマを返します。 @@ -276,7 +276,7 @@ tidb-ctl base64decode [table_id] [base64_data] ### logコマンド {#the-code-log-code-command} -TiDBエラーログのスタック情報は1行形式です。1 `tidb-ctl log`指定すると、複数行形式に変更できます。 +TiDBエラーログのスタック情報は1行形式です。1 `tidb-ctl log`を指定すると、複数行形式に変更できます。 ### keyrangeコマンド {#the-code-keyrange-code-command} diff --git a/tidb-lightning/deploy-tidb-lightning.md b/tidb-lightning/deploy-tidb-lightning.md index 3e339ec584196..6b53030ca65a3 100644 --- a/tidb-lightning/deploy-tidb-lightning.md +++ b/tidb-lightning/deploy-tidb-lightning.md @@ -18,7 +18,7 @@ summary: TiDB Lightningをデプロイ、大量の新しいデータを迅速に curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh ``` - このコマンドは、 TiUP を環境変数`PATH`に自動的に追加します。 TiUP を使用するには、新しいターミナルセッションを開始するか、 `source ~/.bashrc`実行する必要があります。（環境によっては`source ~/.profile`実行する必要がある場合があります。具体的なコマンドについては、 TiUPの出力を確認してください。） + このコマンドは、 TiUP を環境変数`PATH`に自動的に追加します。 TiUP を使用するには、新しいターミナルセッションを開始するか、 `source ~/.bashrc`を実行する必要があります。（環境によっては`source ~/.profile`を実行する必要がある場合があります。具体的なコマンドについては、 TiUPの出力を確認してください。） 2. TiUPを使用してTiDB Lightningをインストールします。 diff --git a/tidb-lightning/import-into-vs-tidb-lightning.md b/tidb-lightning/import-into-vs-tidb-lightning.md index 70ceb6cb370d4..b7a5ebf3d27a6 100644 --- a/tidb-lightning/import-into-vs-tidb-lightning.md +++ b/tidb-lightning/import-into-vs-tidb-lightning.md @@ -7,7 +7,7 @@ summary: IMPORT INTO` とTiDB Lightningの違いについて説明します。 多くのユーザーから、 [TiDB Lightning](/tidb-lightning/tidb-lightning-configuration.md)の展開、構成、メンテナンスは、特に[並列インポート](/tidb-lightning/tidb-lightning-distributed-import.md)の大規模なデータセットが関係するシナリオでは複雑であるというフィードバックが寄せられています。 -皆様からのフィードバックに基づき、TiDBはTiDB Lightningの一部の機能を[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) SQL文に段階的に統合してきました。3 `IMPORT INTO`実行することでデータを直接インポートできるため、データインポートの効率が向上します。さらに、 `IMPORT INTO`自動分散タスクスケジューリングや[TiDB グローバルソート](/tidb-global-sort.md)といった、 TiDB Lightningにはない機能もサポートされています。 +皆様からのフィードバックに基づき、TiDBはTiDB Lightningの一部の機能を[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) SQL文に段階的に統合してきました。3 `IMPORT INTO`を実行することでデータを直接インポートできるため、データインポートの効率が向上します。さらに、 `IMPORT INTO`自動分散タスクスケジューリングや[TiDB グローバルソート](/tidb-global-sort.md)といった、 TiDB Lightningにはない機能もサポートされています。 `IMPORT INTO`はv7.2.0で導入され、v7.5.0で一般提供（GA）されます。今後のバージョンでも引き続き改良と最適化が行われます。2 `IMPORT INTO`機能がTiDB Lightningを完全に置き換えることが可能になった時点で、 TiDB Lightningは廃止されます。その際には、TiDBのリリースノートおよびドキュメントで事前にお知らせいたします。 diff --git a/tidb-lightning/tidb-lightning-checkpoints.md b/tidb-lightning/tidb-lightning-checkpoints.md index 753370ebbadf8..5462aa4391725 100644 --- a/tidb-lightning/tidb-lightning-checkpoints.md +++ b/tidb-lightning/tidb-lightning-checkpoints.md @@ -91,7 +91,7 @@ tidb-lightning-ctl --checkpoint-error-ignore=all > **注記：** > -> このオプションは、エラーが実際に無視できると確信できる場合にのみ使用してください。そうでない場合、インポートされたデータの一部が失われる可能性があります。唯一の安全策は最終的な「チェックサム」チェックであるため、 `--checkpoint-error-ignore`使用する場合は常に「チェックサム」オプションを有効にする必要があります。 +> このオプションは、エラーが実際に無視できると確信できる場合にのみ使用してください。そうでない場合、インポートされたデータの一部が失われる可能性があります。唯一の安全策は最終的な「チェックサム」チェックであるため、 `--checkpoint-error-ignore`を使用する場合は常に「チェックサム」オプションを有効にする必要があります。 ### `--checkpoint-remove` {#checkpoint-remove} diff --git a/tidb-lightning/tidb-lightning-command-line-full.md b/tidb-lightning/tidb-lightning-command-line-full.md index 097cb6ea851f9..147809ea448ba 100644 --- a/tidb-lightning/tidb-lightning-command-line-full.md +++ b/tidb-lightning/tidb-lightning-command-line-full.md @@ -11,7 +11,7 @@ TiDB Lightning は、設定ファイルまたはコマンドラインから設 ### `tidb-lightning` {#tidb-lightning} -`tidb-lightning`使用して次のパラメータを設定できます。 +`tidb-lightning`を使用して次のパラメータを設定できます。 | パラメータ | 説明 | 対応する構成項目 | | :---------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------- | @@ -38,7 +38,7 @@ TiDB Lightning は、設定ファイルまたはコマンドラインから設 | `--key ` | TLS接続の秘密鍵パス | `security.key-path` | | `--server-mode` | TiDB Lightningをサーバーモードで起動します。このモードでは、TiDB Lightningはすぐにインポートを開始するのではなく、HTTP API を通じてインポートタスクが送信されるのを待機します。 | `lightning.server-mode` | -コマンドラインパラメータと設定ファイル内の対応する設定の両方を指定した場合、コマンドラインパラメータが優先されます。例えば、 `tiup tidb-lightning -L debug --config cfg.toml`実行すると、 `cfg.toml`の内容に関係なく、ログレベルは常に「debug」に設定されます。 +コマンドラインパラメータと設定ファイル内の対応する設定の両方を指定した場合、コマンドラインパラメータが優先されます。例えば、 `tiup tidb-lightning -L debug --config cfg.toml`を実行すると、 `cfg.toml`の内容に関係なく、ログレベルは常に「debug」に設定されます。 ## `tidb-lightning-ctl` {#tidb-lightning-ctl} diff --git a/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md b/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md index 1255d6eca8b68..abb5f82c352f0 100644 --- a/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md +++ b/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md @@ -75,4 +75,4 @@ TiCDC を物理インポート モードで使用することは、短期的に このシナリオでは、TiCDC の changefeed が有効になっている場合、 `IMPORT INTO`ステートメントを送信した後に互換性チェックでエラーが報告されます。そのステートメントの[`WithOptions`](/sql-statements/sql-statement-import-into.md#withoptions)に`DISABLE_PRECHECK` (v8.0.0 で導入) を含めて再送信することができます。これにより、データインポートタスクは互換性チェックを無視し、データを直接インポートします。 - 上流 TiDB クラスターのインポートタスクが完了したら、 `IMPORT INTO`使用して下流 TiDB クラスターに同じデータをインポートします。下流に Redshift や Snowflake などのデータベースがある場合は、クラウドストレージサービスから CSV、SQL、または Parquet ファイルを読み取り、データベースに書き込むように設定できます。 + 上流 TiDB クラスターのインポートタスクが完了したら、 `IMPORT INTO`を使用して下流 TiDB クラスターに同じデータをインポートします。下流に Redshift や Snowflake などのデータベースがある場合は、クラウドストレージサービスから CSV、SQL、または Parquet ファイルを読み取り、データベースに書き込むように設定できます。 diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index 4c28b337393a4..8d596f4247cc5 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -159,7 +159,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `dsn` {#dsn} - チェックポイントストレージの場所を示すデータ ソース名 (DSN)。 -- `file`ドライバの場合、DSNはパスです。パスが指定されていない場合、 TiDB Lightningはデフォルト値の`/tmp/CHECKPOINT_SCHEMA.pb`使用します。 +- `file`ドライバの場合、DSNはパスです。パスが指定されていない場合、 TiDB Lightningはデフォルト値の`/tmp/CHECKPOINT_SCHEMA.pb`を使用します。 - `mysql`ドライバーの場合、 DSN は`USER:PASS@tcp(HOST:PORT)/`形式の URL です。 - URL が指定されていない場合は、 `[tidb]`セクションの TiDBサーバーがチェックポイントの保存に使用されます。 - ターゲット TiDB クラスターの負荷を軽減するには、別の MySQL 互換データベースサーバーを指定することをお勧めします。 @@ -656,7 +656,7 @@ CSV ファイルの解析方法を構成します。 #### `analyze` {#analyze} -- チェックサムが完了した後に各テーブルに対して`ANALYZE TABLE
    `実行するかどうかを指定します。 +- チェックサムが完了した後に各テーブルに対して`ANALYZE TABLE
    `を実行するかどうかを指定します。 - デフォルト値: `"optional"` - `"off"` `"optional"`オプション: `"required"` diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md index dd8eee34f1be4..0094bee8b5ecb 100644 --- a/tidb-lightning/tidb-lightning-data-source.md +++ b/tidb-lightning/tidb-lightning-data-source.md @@ -73,7 +73,7 @@ table = '$2' type = '$3' ``` -`gzip`使用してデータファイルをバックアップする場合は、それに応じて圧縮形式を設定する必要があります。データファイル`pattern`のマッチングルールは`'^({schema_regrex})\.({table_regrex})\.({file_serial_regrex})\.(csv|parquet|sql)\.(gz)'`です。圧縮ファイル形式を表すために、 `compression` `'$4'`として指定できます。例： +`gzip`を使用してデータファイルをバックアップする場合は、それに応じて圧縮形式を設定する必要があります。データファイル`pattern`のマッチングルールは`'^({schema_regrex})\.({table_regrex})\.({file_serial_regrex})\.(csv|parquet|sql)\.(gz)'`です。圧縮ファイル形式を表すために、 `compression` `'$4'`として指定できます。例： ```toml [mydumper] @@ -153,7 +153,7 @@ trim-last-separator = false - CSV (カンマ区切り値)の場合は`','` 。 - TSV (タブ区切り値)の場合は`"\t"` 。 - - `"\u0001"`指定すると ASCII 文字`0x01`使用されます。 + - `"\u0001"`を指定すると ASCII 文字`0x01`使用されます。 - LOAD DATA ステートメントの`FIELDS TERMINATED BY`オプションに対応します。 @@ -230,7 +230,7 @@ trim-last-separator = false - `trim-last-separator = false`場合、これは 5 つのフィールド`('A', '', 'B', '', '')`の行として解釈されます。 - `trim-last-separator = true`場合、これは 3 つのフィールド`('A', '', 'B')`の行として解釈されます。 -- このオプションは非推奨です。代わりにオプション`terminator`使用してください。 +- このオプションは非推奨です。代わりにオプション`terminator`を使用してください。 既存の構成が次の場合: @@ -369,7 +369,7 @@ TiDB Lightningは現在、 Dumplingでエクスポートされた圧縮ファイ TiDB Lightningは、命名パターンに従ったデータファイルのみを認識します。場合によっては、データファイルが命名パターンに従っていない可能性があり、その場合、ファイルのインポートなしでデータのインポートが短時間で完了します。 -この問題を解決するには、カスタマイズした式でデータ ファイルを一致させるために`[[mydumper.files]]`使用します。 +この問題を解決するには、カスタマイズした式でデータ ファイルを一致させるために`[[mydumper.files]]`を使用します。 S3にエクスポートされたAuroraスナップショットを例に挙げます。Parquetファイルの完全パスは`S3://some-bucket/some-subdir/some-database/some-database.some-table/part-00000-c5a881bb-58ff-4ee6-1111-b41ecff340a3-c000.gz.parquet`です。 diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index 0f129cf749a7d..fb638f29a3ac7 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -75,8 +75,8 @@ TiDB Lightning は実行時に一部のリソースを排他的に使用しま TiDB Lightningがデプロイされている 5 つのノード上の 2 つのシャード テーブルをエクスポートします。 -- 2つのシャードテーブルが同じMySQLインスタンス内にある場合、 Dumplingのパラメータ`--filter`使用して直接エクスポートできます。TiDB Lightningを使用してインポートする場合は、 Dumplingがデータをエクスポートするディレクトリとして`data-source-dir`指定できます。 -- 2つのシャードテーブルのデータが異なるMySQLノードに分散されている場合は、 Dumplingを使用して個別にエクスポートする必要があります。エクスポートしたデータは、同じ親ディレクトリ内、かつ異なるサブディレクトリに配置する必要があります。TiDB Lightningを使用して並列インポートを実行する場合は、親ディレクトリとして`data-source-dir`指定する必要があります。 +- 2つのシャードテーブルが同じMySQLインスタンス内にある場合、 Dumplingのパラメータ`--filter`を使用して直接エクスポートできます。TiDB Lightningを使用してインポートする場合は、 Dumplingがデータをエクスポートするディレクトリとして`data-source-dir`指定できます。 +- 2つのシャードテーブルのデータが異なるMySQLノードに分散されている場合は、 Dumplingを使用して個別にエクスポートする必要があります。エクスポートしたデータは、同じ親ディレクトリ内、かつ異なるサブディレクトリに配置する必要があります。TiDB Lightningを使用して並列インポートを実行する場合は、親ディレクトリとして`data-source-dir`を指定する必要があります。 Dumpling を使用してデータをエクスポートする方法の詳細については、 [Dumpling](/dumpling-overview.md)参照してください。 @@ -113,7 +113,7 @@ Dumpling を使用してデータをエクスポートする方法の詳細に 並列インポート中、各TiDB Lightningノードのサーバー構成要件は、非並列インポートモードの場合と同じです。各TiDB Lightningノードは同じリソースを使用する必要があります。各ノードは異なるサーバーにデプロイすることをお勧めします。詳細なデプロイ手順については、 [TiDB Lightningをデプロイ](/tidb-lightning/deploy-tidb-lightning.md)参照してください。 -各サーバーで順番にTiDB Lightningを起動します。コマンドラインから`nohup`指定して直接起動すると、SIGHUPシグナルによって終了する可能性があります。そのため、スクリプトに`nohup`指定することをお勧めします。例： +各サーバーで順番にTiDB Lightningを起動します。コマンドラインから`nohup`を指定して直接起動すると、SIGHUPシグナルによって終了する可能性があります。そのため、スクリプトに`nohup`を指定することをお勧めします。例： ```shell # !/bin/bash diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md index c60fbc0b02b40..302f0444c3026 100644 --- a/tidb-lightning/tidb-lightning-faq.md +++ b/tidb-lightning/tidb-lightning-faq.md @@ -174,7 +174,7 @@ TiDB LightningでSQLの配置ルールを使用するには、データをター tiup dumpling -B test -o /tmp/bck1 -2. 次の内容のファイルを`/tmp/tidb-lightning.toml`作成します。 +2. 次の内容のファイルを`/tmp/tidb-lightning.toml`を作成します。 ```toml [tidb] diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md index 5b58043485fc6..eedd2581e4d20 100644 --- a/tidb-lightning/troubleshoot-tidb-lightning.md +++ b/tidb-lightning/troubleshoot-tidb-lightning.md @@ -21,7 +21,7 @@ TiDB Lightning が遅くなる理由はいくつかあります。 **原因 2** : テーブル スキーマが複雑すぎます。 -インデックスを追加するたびに、各行に新しいKVペアが作成されます。インデックスがN個ある場合、実際にインポートされるサイズはDumpling出力のサイズの約(N+1)倍になります。インデックスが無視できるほど小さい場合は、まずスキーマからインデックスを削除し、インポート完了後に`CREATE INDEX`使用して再度追加することができます。 +インデックスを追加するたびに、各行に新しいKVペアが作成されます。インデックスがN個ある場合、実際にインポートされるサイズはDumpling出力のサイズの約(N+1)倍になります。インデックスが無視できるほど小さい場合は、まずスキーマからインデックスを削除し、インポート完了後に`CREATE INDEX`を使用して再度追加することができます。 **原因 3** : 各ファイルが大きすぎます。 @@ -44,7 +44,7 @@ strict-format = true [2018/08/10 07:29:08.310 +08:00] [INFO] [main.go:41] ["got signal to exit"] [signal=hangup] -コマンドラインで直接`nohup`使用して`tidb-lightning`起動することは推奨されません。スクリプトを実行することで[`tidb-lightning`を起動する](/get-started-with-tidb-lightning.md#step-4-start-tidb-lightning)起動できます。 +コマンドラインで直接`nohup`を使用して`tidb-lightning`起動することは推奨されません。スクリプトを実行することで[`tidb-lightning`を起動する](/get-started-with-tidb-lightning.md#step-4-start-tidb-lightning)起動できます。 また、 TiDB Lightningの最後のログに「Context cancellation」というエラーが表示されている場合は、最初の「ERROR」レベルのログを探す必要があります。この「ERROR」レベルのログには通常、「got signal to exit」が続きます。これは、 TiDB Lightningが割り込み信号を受信して終了したことを示しています。 @@ -84,7 +84,7 @@ tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode **ソリューション**： -1. `tidb-lightning-ctl`使用して破損したデータを削除し、テーブル構造とデータを確認して、 TiDB Lightningを再起動して、影響を受けるテーブルを再度インポートします。 +1. `tidb-lightning-ctl`を使用して破損したデータを削除し、テーブル構造とデータを確認して、 TiDB Lightningを再起動して、影響を受けるテーブルを再度インポートします。 ```sh tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=all @@ -139,7 +139,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= 2. クラスター全体で同じ最新バージョン`tzdata` (バージョン 2018i 以上) が使用されていることを確認します。 - CentOS では、 `yum info tzdata`実行してインストールされているバージョンとアップデートの有無を確認します。3 `yum upgrade tzdata`実行してパッケージをアップグレードします。 + CentOS では、 `yum info tzdata`を実行してインストールされているバージョンとアップデートの有無を確認します。3 `yum upgrade tzdata`を実行してパッケージをアップグレードします。 ### `[Error 8025: entry too large, the max entry size is 6291456]` {#error-8025-entry-too-large-the-max-entry-size-is-6291456} diff --git a/tidb-monitoring-api.md b/tidb-monitoring-api.md index 87081599a9226..237b31cb9e4cc 100644 --- a/tidb-monitoring-api.md +++ b/tidb-monitoring-api.md @@ -21,7 +21,7 @@ summary: TiDB 監視サービスの API を学習します。 ### 実行ステータス {#running-status} -次の例では、 `http://${host}:${port}/status`使用して TiDBサーバーの現在のステータスを取得し、サーバーが稼働中かどうかを判断します。結果は**JSON**形式で返されます。 +次の例では、 `http://${host}:${port}/status`を使用して TiDBサーバーの現在のステータスを取得し、サーバーが稼働中かどうかを判断します。結果は**JSON**形式で返されます。 ```bash curl http://127.0.0.1:10080/status @@ -34,7 +34,7 @@ curl http://127.0.0.1:10080/status #### 保管情報 {#storage-information} -次の例では、 `http://${host}:${port}/schema_storage/${db}/${table}`使用して特定のデータテーブルのストレージ情報を取得します。結果は**JSON**形式で返されます。 +次の例では、 `http://${host}:${port}/schema_storage/${db}/${table}`を使用して特定のデータテーブルのストレージ情報を取得します。結果は**JSON**形式で返されます。 ```bash curl http://127.0.0.1:10080/schema_storage/mysql/stats_histograms diff --git a/tidb-read-staleness.md b/tidb-read-staleness.md index 0e2fe25c6e14e..1810e616e7d31 100644 --- a/tidb-read-staleness.md +++ b/tidb-read-staleness.md @@ -95,7 +95,7 @@ summary: tidb_read_staleness` システム変数を使用して履歴データ > **注記：** > - > - `tidb_read_staleness`前には`@`ではなく`@@`使用します。7 `@@`システム変数、 `@`ユーザー変数を意味します。 + > - `tidb_read_staleness`前には`@`ではなく`@@`を使用します。7 `@@`システム変数、 `@`ユーザー変数を意味します。 > - 履歴時間範囲（値`tidb_read_staleness` ）は、手順 3 と手順 4 に費やした合計時間に応じて設定する必要があります。そうしないと、クエリ結果には履歴データではなく最新のデータが表示されてしまいます。したがって、操作に費やした時間に応じてこの時間範囲を調整する必要があります。例えば、この例では設定時間範囲が 5 秒であるため、手順 3 と手順 4 を 5 秒以内に完了する必要があります。 ここで読み取られるデータは更新前のデータ、つまり履歴データです。 diff --git a/tidb-resource-control-background-tasks.md b/tidb-resource-control-background-tasks.md index 72ec188cc7cfc..ff75d489e57da 100644 --- a/tidb-resource-control-background-tasks.md +++ b/tidb-resource-control-background-tasks.md @@ -84,7 +84,7 @@ TiDB は次の種類のバックグラウンド タスクをサポートして | default | UNLIMITED | MEDIUM | YES | NULL | TASK_TYPES='br,ddl', UTILIZATION_LIMIT=30 | +---------+------------+----------+-----------+-------------+-------------------------------------------+ -5. 現在のセッションのタスクを明示的にバックグラウンドタイプとしてマークするには、 `tidb_request_source_type`使用してタスクタイプを明示的に指定します。例を以下に示します。 +5. 現在のセッションのタスクを明示的にバックグラウンドタイプとしてマークするには、 `tidb_request_source_type`を使用してタスクタイプを明示的に指定します。例を以下に示します。 ```sql SET @@tidb_request_source_type="background"; diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index 50a3880f94fde..f6c6828d0e1e5 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -41,7 +41,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 `WATCH`の`DURATION`オプションは識別項目の有効期間を示し、デフォルトでは無期限です。 -監視項目を追加した後、 `QUERY_LIMIT`設定が変更または削除されても、対応する機能と`ACTION`変更または削除されません。監視項目を削除するには`QUERY WATCH REMOVE`使用します。 +監視項目を追加した後、 `QUERY_LIMIT`設定が変更または削除されても、対応する機能と`ACTION`変更または削除されません。監視項目を削除するには`QUERY WATCH REMOVE`を使用します。 `QUERY_LIMIT`のパラメータは次のとおりです。 @@ -110,7 +110,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 QUERY WATCH ADD RESOURCE GROUP rg1 ACTION SWITCH_GROUP(rg2) SQL TEXT SIMILAR TO 'select * from test.t2'; ``` -- `PLAN DIGEST`使用して`rg1`リソース グループのランナウェイ クエリ監視リストに一致する機能を追加し、 `ACTION` `KILL`として指定します。 +- `PLAN DIGEST`を使用して`rg1`リソース グループのランナウェイ クエリ監視リストに一致する機能を追加し、 `ACTION` `KILL`として指定します。 ```sql QUERY WATCH ADD RESOURCE GROUP rg1 ACTION KILL PLAN DIGEST 'd08bc323a934c39dc41948b0a073725be3398479b6fa4f6dd1db2a9b115f7f57'; diff --git a/tidb-rowid.md b/tidb-rowid.md index cf98b701677a6..5da3ab1940031 100644 --- a/tidb-rowid.md +++ b/tidb-rowid.md @@ -5,18 +5,18 @@ summary: _tidb_rowid`とは何か、いつ利用できるのか、そして安 # `_tidb_rowid` {#tidb-rowid} -`_tidb_rowid`はTiDBによって自動的に生成される非表示のシステム列です。クラスター化インデックスを使用しないテーブルの場合、この列はテーブルの内部行IDとして機能します。テーブルスキーマでこの列を宣言または変更することはできませんが、テーブルが内部行IDとして`_tidb_rowid`使用している場合は、SQLで参照できます。 +`_tidb_rowid`はTiDBによって自動的に生成される非表示のシステム列です。クラスター化インデックスを使用しないテーブルの場合、この列はテーブルの内部行IDとして機能します。テーブルスキーマでこの列を宣言または変更することはできませんが、テーブルが内部行IDとして`_tidb_rowid`を使用している場合は、SQLで参照できます。 現在の実装では、 `_tidb_rowid`はTiDBによって自動的に管理される追加の`BIGINT NOT NULL`列です。 > **警告：** > -> - `_tidb_rowid`常にグローバルに一意であるとは限らないことに注意してください。クラスター化インデックスを使用しないパーティションテーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`実行すると、異なるパーティション間で`_tidb_rowid`値が重複する可能性があります。 +> - `_tidb_rowid`常にグローバルに一意であるとは限らないことに注意してください。クラスター化インデックスを使用しないパーティションテーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`を実行すると、異なるパーティション間で`_tidb_rowid`値が重複する可能性があります。 > - 安定した一意の識別子が必要な場合は、 `_tidb_rowid`に依存するのではなく、明示的な主キーを定義して使用してください。 ## _tidb_rowidが利用可能な場合 {#when-code-tidb-rowid-code-is-available} -TiDBでは、テーブルが一意の行識別子としてクラスター化された主キーを使用しない場合、各行を識別するために`_tidb_rowid`使用します。実際には、これは次のタイプのテーブルが`_tidb_rowid`使用することを意味します。 +TiDBでは、テーブルが一意の行識別子としてクラスター化された主キーを使用しない場合、各行を識別するために`_tidb_rowid`を使用します。実際には、これは次のタイプのテーブルが`_tidb_rowid`を使用することを意味します。 - 主キーのないテーブル - 主キーが明示的に`NONCLUSTERED`と定義されているテーブル @@ -50,7 +50,7 @@ ERROR 1054 (42S22): Unknown column '_tidb_rowid' in 'field list' ## _tidb_rowidを読み込む {#read-code-tidb-rowid-code} -`_tidb_rowid`使用するテーブルの場合、 `SELECT`ステートメントで`_tidb_rowid`クエリできます。これは、ページネーション、トラブルシューティング、バッチ処理などのタスクに役立ちます。 +`_tidb_rowid`を使用するテーブルの場合、 `SELECT`ステートメントで`_tidb_rowid`クエリできます。これは、ページネーション、トラブルシューティング、バッチ処理などのタスクに役立ちます。 例： @@ -70,7 +70,7 @@ SELECT _tidb_rowid, a, b FROM t ORDER BY _tidb_rowid; +-------------+---+---+ ``` -TiDB が行 ID に割り当てる次の値を表示するには、 `SHOW TABLE ... NEXT_ROW_ID`使用します。 +TiDB が行 ID に割り当てる次の値を表示するには、 `SHOW TABLE ... NEXT_ROW_ID`を使用します。 ```sql SHOW TABLE t NEXT_ROW_ID; @@ -123,12 +123,12 @@ SELECT _tidb_rowid, a, b FROM t WHERE _tidb_rowid = 100; - `_tidb_rowid`という名前のユーザー列を作成することはできません。 - 既存のユーザー列の名前を`_tidb_rowid`に変更することはできません。 - `_tidb_rowid`はTiDBの内部列です。ビジネス上の主キーや長期的な識別子として扱わないでください。 -- パーティション化された非クラスター化テーブルでは、 `_tidb_rowid`値はパーティション間で一意であることが保証されません。3 `EXCHANGE PARTITION`実行した後、異なるパーティションに同じ`_tidb_rowid`値を持つ行が含まれる可能性があります。 +- パーティション化された非クラスター化テーブルでは、 `_tidb_rowid`値はパーティション間で一意であることが保証されません。3 `EXCHANGE PARTITION`を実行した後、異なるパーティションに同じ`_tidb_rowid`値を持つ行が含まれる可能性があります。 - `_tidb_rowid`存在するかどうかは、テーブルのスキーマによって異なります。クラスター化インデックスを持つテーブルの場合は、行識別子として主キーを使用してください。 ## ホットスポットの問題に対処する {#address-hotspot-issues} -`_tidb_rowid`使用するテーブルの場合、TiDB はデフォルトで行 ID を昇順で割り当てます。書き込み負荷の高いワークロードでは、これにより書き込みホットスポットが発生する可能性があります。 +`_tidb_rowid`を使用するテーブルの場合、TiDB はデフォルトで行 ID を昇順で割り当てます。書き込み負荷の高いワークロードでは、これにより書き込みホットスポットが発生する可能性があります。 この問題を軽減するために（行IDとして`_tidb_rowid`を使用するテーブルの場合）、行IDをより均等に分配するために[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)使用し、必要に応じてリージョンを事前に分割するために[`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)使用することを検討してください。 @@ -141,7 +141,7 @@ CREATE TABLE t ( ) SHARD_ROW_ID_BITS = 4; ``` -`SHARD_ROW_ID_BITS` `_tidb_rowid`使用するテーブルにのみ適用され、クラスター化インデックスを持つテーブルには適用されません。 +`SHARD_ROW_ID_BITS` `_tidb_rowid`を使用するテーブルにのみ適用され、クラスター化インデックスを持つテーブルには適用されません。 ## 関連する記述と変数 {#related-statements-and-variables} diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index 6e67a4cb8b6eb..a91dc9ac73530 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -362,7 +362,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - PD はLeaderを選出できません: PD ログには`lease is not expired`が表示されます。 [この問題は](https://github.com/etcd-io/etcd/issues/10355)v3.0.x および v2.1.19 で修正されました。中国語の[ケース875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md)参照してください。 - - 選挙が遅い：リージョンの読み込み時間が長い。この問題は、PD ログで`grep "regions cost"`実行することで確認できます。結果が`load 460927 regions cost 11.77099s`のように秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0 では、 `region storage`を`use-region-storage`に設定することで`true`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。詳細は、 [ケース429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md) （中国語）を参照してください。 + - 選挙が遅い：リージョンの読み込み時間が長い。この問題は、PD ログで`grep "regions cost"`を実行することで確認できます。結果が`load 460927 regions cost 11.77099s`のように秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0 では、 `region storage`を`use-region-storage`に設定することで`true`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。詳細は、 [ケース429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md) （中国語）を参照してください。 - 5.2.3 TiDBがSQLステートメントを実行する際にPDがタイムアウトしました。 diff --git a/tidb-upgrade-migration-guide.md b/tidb-upgrade-migration-guide.md index 48a6b7e183856..6f2409ac9b0b1 100644 --- a/tidb-upgrade-migration-guide.md +++ b/tidb-upgrade-migration-guide.md @@ -232,7 +232,7 @@ tiup cluster start # Start the cluster 3. 新しいクラスターと古いクラスター間のデータの整合性を確認します。 - - TiCDC が追いついたら、新しいクラスターから`down-tso`取得します。 + - TiCDC が追いついたら、新しいクラスターから`down-tso`を取得します。 - [同期差分インスペクター](/sync-diff-inspector/sync-diff-inspector-overview.md)ツールを使用して、 `up-tso`と`down-tso`の新しいクラスターと古いクラスター間のデータの一貫性を比較します。 4. フォワード Changefeed レプリケーション タスクを一時停止します。 diff --git a/tiflash-upgrade-guide.md b/tiflash-upgrade-guide.md index 1db6c51f938fc..8322e9ea85c8c 100644 --- a/tiflash-upgrade-guide.md +++ b/tiflash-upgrade-guide.md @@ -26,7 +26,7 @@ summary: TiFlash をアップグレードする際の注意事項を説明しま TiFlashをv5.3.0より前のバージョンからv5.3.0以降にアップグレードするには、 TiFlashを停止してからアップグレードする必要があります。TiUPを使用してTiFlashをアップグレードする際は、以下の点にご注意ください。 -- TiUPクラスタのバージョンがv1.12.0以降の場合、 TiFlashを停止してからアップグレードすることはできません。アップグレード先のバージョンでTiUPクラスタのバージョンがv1.12.0以降が必要な場合は、まず`tiup cluster:v1.11.3 `使用してTiFlashを中間バージョンにアップグレードし、TiDBクラスタのオンラインアップグレードを実行した後、 TiUPバージョンをアップグレードし、その後TiDBクラスタを停止せずに直接アップグレード先のバージョンにアップグレードすることをお勧めします。 +- TiUPクラスタのバージョンがv1.12.0以降の場合、 TiFlashを停止してからアップグレードすることはできません。アップグレード先のバージョンでTiUPクラスタのバージョンがv1.12.0以降が必要な場合は、まず`tiup cluster:v1.11.3 `を使用してTiFlashを中間バージョンにアップグレードし、TiDBクラスタのオンラインアップグレードを実行した後、 TiUPバージョンをアップグレードし、その後TiDBクラスタを停止せずに直接アップグレード先のバージョンにアップグレードすることをお勧めします。 - TiUPクラスターのバージョンが v1.12.0 より前の場合は、次の手順を実行してTiFlash をアップグレードします。 次の手順に従うと、 TiUPを使用して他のコンポーネントを中断せずにTiFlash をアップグレードできます。 diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md index 8c53f4366a211..fa7f65719e90b 100644 --- a/tiflash/create-tiflash-replicas.md +++ b/tiflash/create-tiflash-replicas.md @@ -287,4 +287,4 @@ TiFlashは、異なるゾーンに対するレプリカ選択戦略の設定を > **注記：** > -> 構文`ALTER TABLE table_name SET TIFLASH REPLICA count LOCATION LABELS location_labels;`において、 `location_labels`に複数のラベルを指定すると、TiDBはそれらを正しく解析して配置ルールを設定できません。したがって、 TiFlashレプリカの設定には`LOCATION LABELS`使用しないでください。 +> 構文`ALTER TABLE table_name SET TIFLASH REPLICA count LOCATION LABELS location_labels;`において、 `location_labels`に複数のラベルを指定すると、TiDBはそれらを正しく解析して配置ルールを設定できません。したがって、 TiFlashレプリカの設定には`LOCATION LABELS`を使用しないでください。 diff --git a/tiflash/tiflash-command-line-flags.md b/tiflash/tiflash-command-line-flags.md index 100f0475941c4..3491fa05ecb3f 100644 --- a/tiflash/tiflash-command-line-flags.md +++ b/tiflash/tiflash-command-line-flags.md @@ -31,7 +31,7 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま - `--frame` : 検証フレームのサイズ。デフォルト値は`1048576`です。このパラメータは`version`が`2`場合にのみ有効です。 - `--compression` : 対象の圧縮アルゴリズム。値のオプションは`LZ4` （デフォルト）、 `LZ4HC` 、 `zstd` 、 `none`です。 - `--level` : 目標圧縮レベル。指定しない場合は、圧縮アルゴリズムに応じて推奨圧縮レベルがデフォルトで使用されます。2 `compression` `LZ4`または`zstd`に設定されている場合、デフォルトのレベルは 1 です。8 `compression` `LZ4HC`に設定されている場合、デフォルトのレベルは 9 です。 - - `--config-file` : `dttool migrate`の設定ファイルは[`server`の設定ファイル](/tiflash/tiflash-command-line-flags.md#server---config-file)と同じです。詳細については`--imitative`参照してください。 + - `--config-file` : `dttool migrate`の設定ファイルは[`server`の設定ファイル](/tiflash/tiflash-command-line-flags.md#server---config-file)と同じです。詳細については`--imitative`を参照してください。 - `--file-id` : DTFileのID。例えば、DTFile `dmf_123`のIDは`123`です。 - `--workdir` : `dmf_xxx`の親ディレクトリ。 - `--dry` : ドライランモード。移行プロセスのみが出力されます。 diff --git a/tiflash/tiflash-results-materialization.md b/tiflash/tiflash-results-materialization.md index 459dcbb8376cb..0c404347e564a 100644 --- a/tiflash/tiflash-results-materialization.md +++ b/tiflash/tiflash-results-materialization.md @@ -43,11 +43,11 @@ SELECT app_name, country FROM t1; - 効率的なBIソリューション - 多くの BI アプリケーションでは、分析クエリ要求が非常に重くなります。たとえば、多くのユーザーが同時にレポートにアクセスして更新する場合、BI アプリケーションは大量の同時クエリ要求を処理する必要があります。この状況に効果的に対処するには、 `INSERT INTO SELECT`使用してレポートのクエリ結果を TiDB テーブルに保存します。その後、エンドユーザーはレポートが更新されたときに結果テーブルから直接データをクエリできるため、計算と分析が何度も繰り返されるのを回避できます。同様に、履歴分析結果を保存することで、長時間の履歴データ分析の計算量をさらに削減できます。たとえば、日次売上利益を分析するために使用されるレポート`A`がある場合、 `INSERT INTO SELECT`を使用してレポート`A`の結果を結果テーブル`T`に保存できます。その後、先月の売上利益を分析するためにレポート`B`生成する必要がある場合は、テーブル`T`の日次分析結果を直接使用できます。この方法は、計算量を大幅に削減するだけでなく、クエリ応答速度を向上させ、システム負荷を軽減します。 + 多くの BI アプリケーションでは、分析クエリ要求が非常に重くなります。たとえば、多くのユーザーが同時にレポートにアクセスして更新する場合、BI アプリケーションは大量の同時クエリ要求を処理する必要があります。この状況に効果的に対処するには、 `INSERT INTO SELECT`を使用してレポートのクエリ結果を TiDB テーブルに保存します。その後、エンドユーザーはレポートが更新されたときに結果テーブルから直接データをクエリできるため、計算と分析が何度も繰り返されるのを回避できます。同様に、履歴分析結果を保存することで、長時間の履歴データ分析の計算量をさらに削減できます。たとえば、日次売上利益を分析するために使用されるレポート`A`がある場合、 `INSERT INTO SELECT`を使用してレポート`A`の結果を結果テーブル`T`に保存できます。その後、先月の売上利益を分析するためにレポート`B`を生成する必要がある場合は、テーブル`T`の日次分析結果を直接使用できます。この方法は、計算量を大幅に削減するだけでなく、クエリ応答速度を向上させ、システム負荷を軽減します。 - TiFlashによるオンライン アプリケーションの提供 - TiFlashがサポートする同時リクエスト数は、データ量とクエリの複雑さによって異なりますが、通常は 100 QPS を超えることはありません。1 `INSERT INTO SELECT`指定してTiFlashクエリ結果を保存し、クエリ結果テーブルを使用して、同時実行性の高いオンラインリクエストをサポートできます。結果テーブルのデータは、 TiFlash の同時実行制限をはるかに下回る低頻度（例：0.5 秒間隔）でバックグラウンドで更新できますが、データの鮮度は高いレベルで維持されます。 + TiFlashがサポートする同時リクエスト数は、データ量とクエリの複雑さによって異なりますが、通常は 100 QPS を超えることはありません。1 `INSERT INTO SELECT`を指定してTiFlashクエリ結果を保存し、クエリ結果テーブルを使用して、同時実行性の高いオンラインリクエストをサポートできます。結果テーブルのデータは、 TiFlash の同時実行制限をはるかに下回る低頻度（例：0.5 秒間隔）でバックグラウンドで更新できますが、データの鮮度は高いレベルで維持されます。 ## 例 {#example} diff --git a/tiflash/troubleshoot-tiflash.md b/tiflash/troubleshoot-tiflash.md index 91ea99d97dc4b..918c9150b30db 100644 --- a/tiflash/troubleshoot-tiflash.md +++ b/tiflash/troubleshoot-tiflash.md @@ -65,7 +65,7 @@ TiFlashのワークロードが大きすぎてTiFlashデータのレプリケー 2. すべてのTiFlashノードをクラスターから削除する必要があるシナリオで、表`INFORMATION_SCHEMA.TIFLASH_REPLICA`にクラスター内にTiFlashレプリカが存在しないことが示されていても、 TiFlashノードの削除が依然として失敗する場合は、最近`DROP TABLE .`または`DROP DATABASE `操作を実行したかどうかを確認します。 - TiFlashレプリカを持つテーブルまたはデータベースの場合、 `DROP TABLE .`または`DROP DATABASE `実行した後、TiDBはPD内の対応するテーブルのTiFlashレプリケーションルールをすぐに削除しません。代わりに、対応するテーブルがガベージコレクション（GC）条件を満たすまで待機してから、これらのレプリケーションルールを削除します。GCが完了すると、対応するTiFlashノードを正常に削除できます。 + TiFlashレプリカを持つテーブルまたはデータベースの場合、 `DROP TABLE .`または`DROP DATABASE `を実行した後、TiDBはPD内の対応するテーブルのTiFlashレプリケーションルールをすぐに削除しません。代わりに、対応するテーブルがガベージコレクション（GC）条件を満たすまで待機してから、これらのレプリケーションルールを削除します。GCが完了すると、対応するTiFlashノードを正常に削除できます。 GC 条件が満たされる前にTiFlashのデータ複製ルールを手動で削除するには、次の操作を実行できます。 @@ -212,9 +212,9 @@ TiDB クラスターを展開した後、 TiFlashレプリカの作成が継続 ## データはTiFlashに複製されません {#data-is-not-replicated-to-tiflash} -TiFlashノードをデプロイし、 `ALTER TABLE ... SET TIFLASH REPLICA ...`実行してレプリケーションを開始したにもかかわらず、データが複製されません。この場合、次の手順を実行することで問題を特定し、対処できます。 +TiFlashノードをデプロイし、 `ALTER TABLE ... SET TIFLASH REPLICA ...`を実行してレプリケーションを開始したにもかかわらず、データが複製されません。この場合、次の手順を実行することで問題を特定し、対処できます。 -1. `ALTER TABLE ... SET TIFLASH REPLICA ...`実行してレプリケーションが成功したかどうかを確認し、出力を確認します。 +1. `ALTER TABLE ... SET TIFLASH REPLICA ...`を実行してレプリケーションが成功したかどうかを確認し、出力を確認します。 - クエリがブロックされている場合は、 `SELECT * FROM information_schema.tiflash_replica`ステートメントを実行して、 TiFlashレプリカが作成されたかどうかを確認します。 - [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)を通じて、DDL 文が期待どおりに実行されているかどうかを確認します。TiFlash レプリカ文のTiFlashをブロックする可能性のある他の DDL 文 ( `ADD INDEX`など) が実行中かどうかを確認します。 diff --git a/tiflash/tune-tiflash-performance.md b/tiflash/tune-tiflash-performance.md index 9b4d1a1f228f5..bc9b9b04c18d4 100644 --- a/tiflash/tune-tiflash-performance.md +++ b/tiflash/tune-tiflash-performance.md @@ -175,7 +175,7 @@ TiFlashは、 `Sum`列など、 `Distinct`列を受け入れる一部の集計 set @@tidb_opt_distinct_agg_push_down = ON; ``` -以下の例は、変数`tidb_opt_distinct_agg_push_down`有効にする前と有効にした後のクエリ結果を示しています。この変数を有効にする前は、TiDB はTiFlashからすべてのデータを読み取り、TiDB 内で`distinct`実行する必要があります。この変数を有効にすると、 `distinct a` TiFlashにプッシュダウンされ、新しい`group by`列である`test.t.a` `HashAgg_6`に追加されます。クエリ結果の 2 つの警告は、集計関数をTiFlashに完全にプッシュダウンできないことを示しています。 +以下の例は、変数`tidb_opt_distinct_agg_push_down`有効にする前と有効にした後のクエリ結果を示しています。この変数を有効にする前は、TiDB はTiFlashからすべてのデータを読み取り、TiDB 内で`distinct`を実行する必要があります。この変数を有効にすると、 `distinct a` TiFlashにプッシュダウンされ、新しい`group by`列である`test.t.a` `HashAgg_6`に追加されます。クエリ結果の 2 つの警告は、集計関数をTiFlashに完全にプッシュダウンできないことを示しています。 `tidb_opt_distinct_agg_push_down`有効になる前: diff --git a/tiflash/use-tidb-to-read-tiflash.md b/tiflash/use-tidb-to-read-tiflash.md index 74ac4be0daa85..476b9771d36a9 100644 --- a/tiflash/use-tidb-to-read-tiflash.md +++ b/tiflash/use-tidb-to-read-tiflash.md @@ -111,7 +111,7 @@ select /*+ read_from_storage(tiflash[table_name]) */ ... from table_name; select /*+ read_from_storage(tiflash[alias_a,alias_b]) */ ... from table_name_1 as alias_a, table_name_2 as alias_b where alias_a.column_1 = alias_b.column_2; ``` -上記の文では、 `tiflash[]`オプティマイザにTiFlashレプリカの読み取りを指示します。また、 `tikv[]`使用すると、必要に応じてオプティマイザに TiKV レプリカの読み取りを指示できます。ヒント構文の詳細については、 [ストレージからの読み取り](/optimizer-hints.md#read_from_storagetiflasht1_name--tl_name--tikvt2_name--tl_name-)を参照してください。 +上記の文では、 `tiflash[]`オプティマイザにTiFlashレプリカの読み取りを指示します。また、 `tikv[]`を使用すると、必要に応じてオプティマイザに TiKV レプリカの読み取りを指示できます。ヒント構文の詳細については、 [ストレージからの読み取り](/optimizer-hints.md#read_from_storagetiflasht1_name--tl_name--tikvt2_name--tl_name-)を参照してください。 ヒントで指定されたテーブルに指定されたエンジンのレプリカが存在しない場合、ヒントは無視され、警告が報告されます。また、ヒントはエンジン分離を前提としてのみ有効です。ヒントで指定されたエンジンがエンジン分離リストに含まれていない場合も、ヒントは無視され、警告が報告されます。 diff --git a/tikv-control.md b/tikv-control.md index 037dc39b3f8cf..0d02f6da04dee 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -129,13 +129,13 @@ AAFF ## サブコマンド、いくつかのオプションとフラグ {#subcommands-some-options-and-flags} -このセクションでは、 `tikv-ctl`サポートするサブコマンドについて詳しく説明します。一部のサブコマンドは多くのオプションをサポートしています。詳細については、 `tikv-ctl --help `実行してください。 +このセクションでは、 `tikv-ctl`サポートするサブコマンドについて詳しく説明します。一部のサブコマンドは多くのオプションをサポートしています。詳細については、 `tikv-ctl --help `を実行してください。 ### Raftステートマシンの情報を表示する {#view-information-of-the-raft-state-machine} -特定の時点におけるRaftステートマシンのステータスを表示するには、サブコマンド`raft`使用します。ステータス情報は、3つの構造体（ **RegionLocalState** 、 **RaftLocalState** 、 **RegionApplyState** ）と、特定のログの対応するエントリの2つの部分で構成されます。 +特定の時点におけるRaftステートマシンのステータスを表示するには、サブコマンド`raft`を使用します。ステータス情報は、3つの構造体（ **RegionLocalState** 、 **RaftLocalState** 、 **RegionApplyState** ）と、特定のログの対応するエントリの2つの部分で構成されます。 -上記の情報を取得するには、それぞれサブコマンド`region`と`log`使用します。これら2つのサブコマンドは、リモートモードとローカルモードを同時にサポートします。 +上記の情報を取得するには、それぞれサブコマンド`region`と`log`を使用します。これら2つのサブコマンドは、リモートモードとローカルモードを同時にサポートします。 `region`サブコマンドの場合: @@ -239,7 +239,7 @@ tikv-ctl --data-dir /path/to/tikv mvcc -k "zmDB:29\000\000\377\000\374\000\000\0 `raw-scan`コマンドはRocksDBから直接スキャンします。データキーをスキャンするには、キーの先頭に`'z'`追加する必要があることに注意してください。 -`--from`と`--to`オプションを使用して`write`スキャンする範囲を指定します（デフォルトでは無制限） `--limit`使用すると、出力するキーの最大数を制限します（デフォルトでは30） `--cf`使用すると、スキャンする cf を指定します（ `default` 、または`lock` ）。 +`--from`と`--to`オプションを使用して`write`スキャンする範囲を指定します（デフォルトでは無制限） `--limit`を使用すると、出力するキーの最大数を制限します（デフォルトでは30） `--cf`を使用すると、スキャンする cf を指定します（ `default` 、または`lock` ）。 ```shell tikv-ctl --data-dir /var/lib/tikv raw-scan --from 'zt' --limit 2 --cf default @@ -310,8 +310,8 @@ tikv-ctl --host localhost:20160 region-properties -r 2 `compact-cluster`コマンドを使用して、TiKV クラスタ全体のデータを手動で圧縮します。このコマンドのフラグは、 `compact`コマンドと同じ意味と使用法を持ちます。唯一の違いは次のとおりです。 -- `compact-cluster`コマンドでは、 `--pd`使用して PD のアドレスを指定し、 `tikv-ctl`クラスター内のすべての TiKV ノードをコンパクト ターゲットとして見つけられるようにします。 -- `compact`コマンドでは、 `--data-dir`または`--host`使用して、単一の TiKV をコンパクト ターゲットとして指定します。 +- `compact-cluster`コマンドでは、 `--pd`を使用して PD のアドレスを指定し、 `tikv-ctl`クラスター内のすべての TiKV ノードをコンパクト ターゲットとして見つけられるようにします。 +- `compact`コマンドでは、 `--data-dir`または`--host`を使用して、単一の TiKV をコンパクト ターゲットとして指定します。 ### リージョンをtombstoneに設定する {#set-a-region-to-tombstone} @@ -444,13 +444,13 @@ tikv-ctl --host ip:port modify-tikv-config -n rocksdb.rate-bytes-per-sec -v "1GB `unsafe-recover remove-fail-stores`コマンドを使用すると、障害が発生したマシンをリージョンのピアリストから削除できます。このコマンドを実行する前に、対象の TiKV ストアのサービスを停止してファイルロックを解除する必要があります。 -`-s`オプションは、カンマ区切りで複数の`store_id`指定でき、 `-r`フラグを使用して対象となるリージョンを指定します。特定のストア内のすべてのリージョンに対してこの操作を実行する必要がある場合は、 `--all-regions`指定するだけで済みます。 +`-s`オプションは、カンマ区切りで複数の`store_id`指定でき、 `-r`フラグを使用して対象となるリージョンを指定します。特定のストア内のすべてのリージョンに対してこの操作を実行する必要がある場合は、 `--all-regions`を指定するだけで済みます。 > **警告：** > > - 誤った操作が行われた場合、クラスターの復旧が困難になる可能性があります。潜在的なリスクを認識し、本番環境ではこの機能の使用を避けてください。 -> - `--all-regions`オプションを使用する場合、このコマンドはクラスタに接続されている残りのすべてのストアに対して実行する必要があります。損傷したストアを復旧する前に、これらの正常なストアがサービスの提供を停止していることを確認する必要があります。そうしないと、リージョンレプリカ内のピアリストの不整合により、 `split-region`または`remove-peer`実行した際にエラーが発生します。これにより、他のメタデータ間の不整合も発生し、最終的にはリージョンが利用できなくなります。 -> - `remove-fail-stores`実行した後は、削除したノードを再起動したり、クラスターに追加したりすることはできません。そうしないと、メタデータに不整合が生じ、最終的にはリージョンが利用できなくなります。 +> - `--all-regions`オプションを使用する場合、このコマンドはクラスタに接続されている残りのすべてのストアに対して実行する必要があります。損傷したストアを復旧する前に、これらの正常なストアがサービスの提供を停止していることを確認する必要があります。そうしないと、リージョンレプリカ内のピアリストの不整合により、 `split-region`または`remove-peer`を実行した際にエラーが発生します。これにより、他のメタデータ間の不整合も発生し、最終的にはリージョンが利用できなくなります。 +> - `remove-fail-stores`を実行した後は、削除したノードを再起動したり、クラスターに追加したりすることはできません。そうしないと、メタデータに不整合が生じ、最終的にはリージョンが利用できなくなります。 ```shell tikv-ctl --data-dir /path/to/tikv unsafe-recover remove-fail-stores -s 3 -r 1001,1002 @@ -471,7 +471,7 @@ TiKVを再起動すると、リージョンは残りの正常なレプリカを ### MVCCデータ破損からの回復 {#recover-from-mvcc-data-corruption} -MVCCデータ破損によりTiKVが正常に動作しない場合は、コマンド`recover-mvcc`使用してください。このコマンドは、3つのCF（「default」、「write」、「lock」）をクロスチェックし、様々な不整合を回復します。 +MVCCデータ破損によりTiKVが正常に動作しない場合は、コマンド`recover-mvcc`を使用してください。このコマンドは、3つのCF（「default」、「write」、「lock」）をクロスチェックし、様々な不整合を回復します。 - `-r`オプションを使用して、関係するリージョンを`region_id`で指定します。 - PD エンドポイントを指定するには、 `-p`オプションを使用します。 @@ -513,13 +513,13 @@ tikv-ctl ldb --hex manifest_dump --path=/tmp/db/MANIFEST-000001 暗号化メタデータをダンプするには、サブコマンド`encryption-meta`を使用します。このサブコマンドは、データファイルの暗号化情報と、使用されているデータ暗号化キーのリストという2種類のメタデータをダンプできます。 -データファイルの暗号化情報をダンプするには、サブコマンド`encryption-meta dump-file`使用します。TiKV デプロイメントに`data-dir`指定するには、TiKV 構成ファイルを作成する必要があります。 +データファイルの暗号化情報をダンプするには、サブコマンド`encryption-meta dump-file`を使用します。TiKV デプロイメントに`data-dir`を指定するには、TiKV 構成ファイルを作成する必要があります。 # conf.toml [storage] data-dir = "/path/to/tikv/data" -`--path`オプションは、対象のデータファイルへの絶対パスまたは相対パスを指定するために使用できます。データファイルが暗号化されていない場合、コマンドは空の出力を返すことがあります。3 `--path`指定しない場合は、すべてのデータファイルの暗号化情報が出力されます。 +`--path`オプションは、対象のデータファイルへの絶対パスまたは相対パスを指定するために使用できます。データファイルが暗号化されていない場合、コマンドは空の出力を返すことがあります。3 `--path`を指定しない場合は、すべてのデータファイルの暗号化情報が出力されます。 ```shell tikv-ctl --config=./conf.toml encryption-meta dump-file --path=/path/to/tikv/data/db/CURRENT @@ -527,7 +527,7 @@ tikv-ctl --config=./conf.toml encryption-meta dump-file --path=/path/to/tikv/dat /path/to/tikv/data/db/CURRENT: key_id: 9291156302549018620 iv: E3C2FDBF63FC03BFC28F265D7E78283F method: Aes128Ctr -データ暗号化キーをダンプするには、サブコマンド`encryption-meta dump-key`使用します。 `data-dir`に加えて、設定ファイルで現在使用されているマスターキーも指定する必要があります。マスターキーの設定方法については、 [保存時の暗号化](/encryption-at-rest.md)を参照してください。また、このコマンドでは`security.encryption.previous-master-key`設定は無視され、マスターキーのローテーションは実行されません。 +データ暗号化キーをダンプするには、サブコマンド`encryption-meta dump-key`を使用します。 `data-dir`に加えて、設定ファイルで現在使用されているマスターキーも指定する必要があります。マスターキーの設定方法については、 [保存時の暗号化](/encryption-at-rest.md)を参照してください。また、このコマンドでは`security.encryption.previous-master-key`設定は無視され、マスターキーのローテーションは実行されません。 # conf.toml [storage] @@ -540,7 +540,7 @@ tikv-ctl --config=./conf.toml encryption-meta dump-file --path=/path/to/tikv/dat マスターキーがAWS KMSキーの場合、 `tikv-ctl` KMSキーへのアクセス権を持っている必要があります。AWS KMSキーへのアクセス権は、環境変数、AWSデフォルト設定ファイル、またはIAMロールのいずれか適切な方法で`tikv-ctl`に付与できます。使用方法についてはAWSドキュメントを参照してください。 -`--ids`オプションを使用すると、出力するデータ暗号化キーのIDをカンマ区切りのリストで指定できます。3 `--ids`指定しない場合は、すべてのデータ暗号化キーと、最新のアクティブなデータ暗号化キーのIDである現在のキーIDが出力されます。 +`--ids`オプションを使用すると、出力するデータ暗号化キーのIDをカンマ区切りのリストで指定できます。3 `--ids`を指定しない場合は、すべてのデータ暗号化キーと、最新のアクティブなデータ暗号化キーのIDである現在のキーIDが出力されます。 このコマンドを使用すると、機密情報が公開される可能性があることを警告するメッセージが表示されます。続行するには「同意します」と入力してください。 diff --git a/time-to-live.md b/time-to-live.md index 45bb41bede6e2..c66038b173663 100644 --- a/time-to-live.md +++ b/time-to-live.md @@ -30,7 +30,7 @@ TTLは、オンラインの読み取りおよび書き込みワークロード ) TTL = `created_at` + INTERVAL 3 MONTH; ``` - 上記の例では、テーブル`t1`を作成し、TTLタイムスタンプ列に`created_at`指定しています。これはデータの作成時刻を示します。また、テーブル内で行が保持できる最長期間を 3 か月から`INTERVAL 3 MONTH`に設定しています。この値を超えて保持されるデータは、後で削除されます。 + 上記の例では、テーブル`t1`を作成し、TTLタイムスタンプ列に`created_at`を指定しています。これはデータの作成時刻を示します。また、テーブル内で行が保持できる最長期間を 3 か月から`INTERVAL 3 MONTH`に設定しています。この値を超えて保持されるデータは、後で削除されます。 - 期限切れのデータをクリーンアップする機能を有効または無効にするには、 `TTL_ENABLE`属性を設定します。 @@ -80,7 +80,7 @@ TTLは、オンラインの読み取りおよび書き込みワークロード TTL は[データ型のデフォルト値](/data-type-default-values.md)と組み合わせて使用​​できます。以下に一般的な使用例を2つ示します。 -- 列のデフォルト値を現在の作成時刻に指定し、この列をTTLタイムスタンプ列として使用するには、 `DEFAULT CURRENT_TIMESTAMP`使用します。3か月前に作成されたレコードは期限切れです。 +- 列のデフォルト値を現在の作成時刻に指定し、この列をTTLタイムスタンプ列として使用するには、 `DEFAULT CURRENT_TIMESTAMP`を使用します。3か月前に作成されたレコードは期限切れです。 ```sql CREATE TABLE t1 ( @@ -243,8 +243,8 @@ TTL は、他の TiDB 移行、バックアップ、およびリカバリ ツー | 機能名 | 説明 | | :-------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [`FLASHBACK TABLE`](/sql-statements/sql-statement-flashback-table.md) | `FLASHBACK TABLE`指定すると、テーブルの`TTL_ENABLE`属性が`OFF`に設定されます。これにより、TiDBはフラッシュバック後に期限切れのデータを直ちに削除しなくなります。各テーブルのTTLを再度有効にするには、 `TTL_ENABLE`属性を手動でオンにする必要があります。 | -| [`FLASHBACK DATABASE`](/sql-statements/sql-statement-flashback-database.md) | `FLASHBACK DATABASE`指定すると、テーブルの`TTL_ENABLE`属性が`OFF`に設定され、 `TTL_ENABLE`属性は変更されません。これにより、TiDBはフラッシュバック後に期限切れのデータを直ちに削除しなくなります。各テーブルのTTLを再度有効にするには、 `TTL_ENABLE`属性を手動でオンにする必要があります。 | +| [`FLASHBACK TABLE`](/sql-statements/sql-statement-flashback-table.md) | `FLASHBACK TABLE`を指定すると、テーブルの`TTL_ENABLE`属性が`OFF`に設定されます。これにより、TiDBはフラッシュバック後に期限切れのデータを直ちに削除しなくなります。各テーブルのTTLを再度有効にするには、 `TTL_ENABLE`属性を手動でオンにする必要があります。 | +| [`FLASHBACK DATABASE`](/sql-statements/sql-statement-flashback-database.md) | `FLASHBACK DATABASE`を指定すると、テーブルの`TTL_ENABLE`属性が`OFF`に設定され、 `TTL_ENABLE`属性は変更されません。これにより、TiDBはフラッシュバック後に期限切れのデータを直ちに削除しなくなります。各テーブルのTTLを再度有効にするには、 `TTL_ENABLE`属性を手動でオンにする必要があります。 | | [`FLASHBACK CLUSTER`](/sql-statements/sql-statement-flashback-cluster.md) | `FLASHBACK CLUSTER`はシステム変数[`TIDB_TTL_JOB_ENABLE`](/system-variables.md#tidb_ttl_job_enable-new-in-v650)を`OFF`に設定し、 `TTL_ENABLE`属性の値は変更しません。 | ## 制限事項 {#limitations} diff --git a/tiproxy/tiproxy-command-line-flags.md b/tiproxy/tiproxy-command-line-flags.md index 2a129f5911300..61ae949b1ce61 100644 --- a/tiproxy/tiproxy-command-line-flags.md +++ b/tiproxy/tiproxy-command-line-flags.md @@ -54,7 +54,7 @@ ls `tiup --binary tiproxy`ctl コンパイル環境要件: [Go](https://golang.org/) 1.21以降 -コンパイル手順: [TiProxyプロジェクト](https://github.com/pingcap/tiproxy)のルート ディレクトリに移動し、 `make`コマンドを使用してコンパイルし、 `tiproxyctl`生成します。 +コンパイル手順: [TiProxyプロジェクト](https://github.com/pingcap/tiproxy)のルート ディレクトリに移動し、 `make`コマンドを使用してコンパイルし、 `tiproxyctl`を生成します。 ```shell git clone https://github.com/pingcap/tiproxy.git @@ -160,7 +160,7 @@ level = 'warning' オプション: - `--output` : (必須) トラフィック ファイルを保存するディレクトリを指定します。 -- `--duration` : (必須) キャプチャ期間を指定します。単位は`m` (分)、 `h` (時間)、 `d` (日) のいずれかです。例えば、 `--duration=1h`指定すると 1 時間のトラフィックがキャプチャされます。 +- `--duration` : (必須) キャプチャ期間を指定します。単位は`m` (分)、 `h` (時間)、 `d` (日) のいずれかです。例えば、 `--duration=1h`を指定すると 1 時間のトラフィックがキャプチャされます。 例： diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index 5a58dbbc130d8..1d70c89a00f4a 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -35,7 +35,7 @@ skip-ca = true > **ヒント：** > -> 設定項目の値を調整する必要がある場合は、 [設定を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)を参照してください。通常、変更を行うと再起動が必要になります。TiProxy はホットリロードをサポートしているため、 `tiup cluster reload --skip-restart`実行することで再起動を省略できます。 +> 設定項目の値を調整する必要がある場合は、 [設定を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)を参照してください。通常、変更を行うと再起動が必要になります。TiProxy はホットリロードをサポートしているため、 `tiup cluster reload --skip-restart`を実行することで再起動を省略できます。 ### プロキシ {#proxy} diff --git a/tiproxy/tiproxy-performance-test.md b/tiproxy/tiproxy-performance-test.md index 95e371e3513a4..27abafb8e93da 100644 --- a/tiproxy/tiproxy-performance-test.md +++ b/tiproxy/tiproxy-performance-test.md @@ -254,7 +254,7 @@ sysbench oltp_point_select \ ### テスト計画 {#test-plan} -このテストは、クライアントが長時間接続を使用する場合、多数のアイドル接続がQPSに最小限の影響しか与えないことを検証することを目的としています。このテストでは、5,000、10,000、15,000のアイドル状態の長時間接続を作成し、 `sysbench`実行します。 +このテストは、クライアントが長時間接続を使用する場合、多数のアイドル接続がQPSに最小限の影響しか与えないことを検証することを目的としています。このテストでは、5,000、10,000、15,000のアイドル状態の長時間接続を作成し、 `sysbench`を実行します。 このテストでは、 `conn-buffer-size`構成のデフォルト値を使用します。 @@ -318,7 +318,7 @@ sysbench oltp_point_select \ ### テスト計画 {#test-plan} -このテストは、TiProxyにおける[トラフィックキャプチャ](/tiproxy/tiproxy-traffic-replay.md)パフォーマンスへの影響を評価することを目的としています。TiProxy v1.3.0を使用し、トラフィックキャプチャを有効または無効にした場合のQPSとTiProxyのCPU使用率を比較した後、異なる同時実行数で`sysbench`実行します。トラフィックファイルの圧縮によって周期的にQPSが変動するため、このテストでは平均QPSと最小QPSの両方を比較します。 +このテストは、TiProxyにおける[トラフィックキャプチャ](/tiproxy/tiproxy-traffic-replay.md)パフォーマンスへの影響を評価することを目的としています。TiProxy v1.3.0を使用し、トラフィックキャプチャを有効または無効にした場合のQPSとTiProxyのCPU使用率を比較した後、異なる同時実行数で`sysbench`を実行します。トラフィックファイルの圧縮によって周期的にQPSが変動するため、このテストでは平均QPSと最小QPSの両方を比較します。 テストを実行するには、次のコマンドを使用します。 diff --git a/tiup/tiup-bench.md b/tiup/tiup-bench.md index d2e1710d0ddb6..a448324941572 100644 --- a/tiup/tiup-bench.md +++ b/tiup/tiup-bench.md @@ -40,12 +40,12 @@ tiup bench rawsql # Benchmark a database using arbitrary SQL files --time duration Total execution time (default to 2562047h47m16.854775807s) -U, --user string Database user (default to "root") -- `--host`と`--port`にカンマ区切りの値を指定すると、クライアント側の負荷分散が有効になります。例えば`--host 172.16.4.1,172.16.4.2 --port 4000,4001`指定すると、プログラムはラウンドロビン方式で選択された 172.16.4.1:4000、172.16.4.1:4001、172.16.4.2:4000、172.16.4.2:4001 に接続します。 +- `--host`と`--port`にカンマ区切りの値を指定すると、クライアント側の負荷分散が有効になります。例えば`--host 172.16.4.1,172.16.4.2 --port 4000,4001`を指定すると、プログラムはラウンドロビン方式で選択された 172.16.4.1:4000、172.16.4.1:4001、172.16.4.2:4000、172.16.4.2:4001 に接続します。 - ローカルデプロイメントの場合、デフォルトのデータベースホストアドレスは`127.0.0.1`です。リモートデータベースに接続する場合は、ホストとその他の関連パラメータを指定する必要があります。例: `tiup bench tpcc -H 192.168.169.31 -P 4000 -D tpcc -U root -p tidb --warehouses 4 --parts 4 prepare` - `--conn-params` [クエリ文字列](https://en.wikipedia.org/wiki/Query_string)の形式に従う必要があります。データベースによってパラメータが異なる場合があります。例: - `--conn-params tidb_isolation_read_engines='tiflash'` TiDB にTiFlashからの読み取りを強制します。 - `--conn-params sslmode=disable` 、PostgreSQL に接続するときに SSL を無効にします。 -- CH-benCHmark を実行する場合、 `--ap-host` 、 `--ap-port` 、 `--ap-conn-params`使用して、OLAP クエリ用のスタンドアロン TiDBサーバーを指定できます。 +- CH-benCHmark を実行する場合、 `--ap-host` 、 `--ap-port` 、 `--ap-conn-params`を使用して、OLAP クエリ用のスタンドアロン TiDBサーバーを指定できます。 次のセクションでは、 TiUPを使用して TPC-C、TPC-H、YCSB テストを実行する方法について説明します。 @@ -200,7 +200,7 @@ YCSB を介して TiDB と TiKV の両方をストレス テストできます ## TiUPを使用してRawSQLテストを実行する {#run-rawsql-test-using-tiup} -任意のクエリを SQL ファイルに記述し、次のように`tiup bench rawsql`実行してテストに使用することができます。 +任意のクエリを SQL ファイルに記述し、次のように`tiup bench rawsql`を実行してテストに使用することができます。 1. データとクエリを準備します。 diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md index 6dfb8dc0e5a9a..26d98b93f1e40 100644 --- a/tiup/tiup-cluster-no-sudo-mode.md +++ b/tiup/tiup-cluster-no-sudo-mode.md @@ -74,7 +74,7 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ └─3358 /usr/bin/pulseaudio --daemonize=no --log-target=journal ``` - 3. `systemctl --user`実行します。エラーが発生しない場合は、 `systemd user`モードが正常に開始されたことを示します。 + 3. `systemctl --user`を実行します。エラーが発生しない場合は、 `systemd user`モードが正常に開始されたことを示します。 3. `root`ユーザーを使用して次のコマンドを実行し、 systemd ユーザー`tidb`の lingering を有効にします。 @@ -85,7 +85,7 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ 参考として、systemd のドキュメント[systemd ユーザーインスタンスの自動起動](https://wiki.archlinux.org/title/Systemd/User#Automatic_start-up_of_systemd_user_instances)読んでみてください。 -4. 制御マシンで`ssh-keygen`使用してキーを生成します。 +4. 制御マシンで`ssh-keygen`を使用してキーを生成します。 ```shell ssh-keygen @@ -139,7 +139,7 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ > > 最小インストールを使用する場合は、 `tar`パッケージがインストールされていることを確認してください。インストールされていない場合、 `tiup cluster check`コマンドは失敗します。 -`tiup cluster check topology.yaml --user tidb`実行すると、いくつかのチェック項目が失敗する可能性があります。以下に例を示します。 +`tiup cluster check topology.yaml --user tidb`を実行すると、いくつかのチェック項目が失敗する可能性があります。以下に例を示します。 ```shell Node Check Result Message @@ -158,7 +158,7 @@ Node Check Result Message 192.168.124.27 service Fail service firewalld is running but should be stopped ``` -no-sudoモードでは、 `tidb`ユーザーにはsudo権限がありません。そのため、 `tiup cluster check topology.yaml --apply --user tidb`実行しても失敗したチェック項目を自動的に修正することはできません。対象マシンで`root`ユーザーを使用して手動で修正する必要があります。 +no-sudoモードでは、 `tidb`ユーザーにはsudo権限がありません。そのため、 `tiup cluster check topology.yaml --apply --user tidb`を実行しても失敗したチェック項目を自動的に修正することはできません。対象マシンで`root`ユーザーを使用して手動で修正する必要があります。 詳細については、 [TiDB環境とシステムコンフィグレーションのチェック](/check-before-deployment.md)参照してください。ドキュメントの手順[SSH相互信頼とパスワードなしのsudoを手動で設定する](/check-before-deployment.md#manually-configure-the-ssh-mutual-trust-and-sudo-without-password)スキップする必要があることに注意してください。 diff --git a/tiup/tiup-cluster.md b/tiup/tiup-cluster.md index c106889838cb6..f908c609783cb 100644 --- a/tiup/tiup-cluster.md +++ b/tiup/tiup-cluster.md @@ -183,7 +183,7 @@ tiup cluster start prod-cluster クラスターの名前を忘れた場合は、 `tiup cluster list`を実行してクラスター リストを表示します。 -TiUPはデーモンプロセスを起動するために`systemd`使用します。プロセスが予期せず終了した場合、15秒後に再起動されます。 +TiUPはデーモンプロセスを起動するために`systemd`を使用します。プロセスが予期せず終了した場合、15秒後に再起動されます。 ## クラスターのステータスを確認する {#check-the-cluster-status} @@ -256,7 +256,7 @@ tiup cluster scale-in -N tiup cluster scale-in prod-cluster -N 172.16.5.140:20160 ``` -`tiup cluster display`実行すると、TiKV ノードが`Offline`マークされていることがわかります。 +`tiup cluster display`を実行すると、TiKV ノードが`Offline`マークされていることがわかります。 ```bash tiup cluster display prod-cluster @@ -423,7 +423,7 @@ alertmanager_servers: - `monitoring_servers`の`rule_dir`フィールドで指定されたフォルダーには、完全な`*.rules.yml`ファイルが含まれている必要があります。 - `alertmanager_servers`の`config_file`欄に指定するファイルの形式については[Alertmanager 構成テンプレート](https://github.com/pingcap/tiup/blob/master/embed/templates/config/alertmanager.yml)を参照してください。 -`tiup reload`実行すると、 TiUP はまずターゲットマシン上の古い設定ファイルをすべて削除し、次にコントロールマシンから対応する設定ファイルをターゲットマシンの対応する設定ディレクトリにアップロードします。したがって、特定の設定ファイルを変更する場合は、すべての設定ファイル（変更されていないものも含む）が同じディレクトリにあることを確認してください。例えば、Grafana の`tidb.json`ファイルを変更するには、まず Grafana の`dashboards`ディレクトリにある`*.json`ファイルすべてをローカルディレクトリにコピーする必要があります。そうしないと、ターゲットマシンから他の JSON ファイルが失われます。 +`tiup reload`を実行すると、 TiUP はまずターゲットマシン上の古い設定ファイルをすべて削除し、次にコントロールマシンから対応する設定ファイルをターゲットマシンの対応する設定ディレクトリにアップロードします。したがって、特定の設定ファイルを変更する場合は、すべての設定ファイル（変更されていないものも含む）が同じディレクトリにあることを確認してください。例えば、Grafana の`tidb.json`ファイルを変更するには、まず Grafana の`dashboards`ディレクトリにある`*.json`ファイルすべてをローカルディレクトリにコピーする必要があります。そうしないと、ターゲットマシンから他の JSON ファイルが失われます。 > **注記：** > @@ -566,7 +566,7 @@ Global Flags: -y, --yes Skip all confirmations and assumes 'yes' ``` -たとえば、すべての TiDB ノードで`ls /tmp`実行するには、次のコマンドを実行します。 +たとえば、すべての TiDB ノードで`ls /tmp`を実行するには、次のコマンドを実行します。 ```bash tiup cluster exec test-cluster --command='ls /tmp' @@ -593,7 +593,7 @@ tikv-ctl [args] = tiup ctl tikv [args] etcdctl [args] = tiup ctl etcd [args] ``` -たとえば、以前に`pd-ctl -u http://127.0.0.1:2379 store`実行してストアを表示していた場合、今度はTiUPで次のコマンドを実行できます。 +たとえば、以前に`pd-ctl -u http://127.0.0.1:2379 store`を実行してストアを表示していた場合、今度はTiUPで次のコマンドを実行できます。 ```bash tiup ctl:v pd -u http://127.0.0.1:2379 store @@ -672,12 +672,12 @@ export TIUP_NATIVE_SSH=enable TiUPデータは、ユーザーのホームディレクトリ内の`.tiup`ディレクトリに保存されます。コントロールマシンを移行するには、以下の手順に従って`.tiup`ディレクトリを対応するターゲットマシンにコピーします。 -1. 元のマシンのホームディレクトリで`tar czvf tiup.tar.gz .tiup`実行します。 +1. 元のマシンのホームディレクトリで`tar czvf tiup.tar.gz .tiup`を実行します。 2. `tiup.tar.gz`ターゲット マシンのホーム ディレクトリにコピーします。 -3. 対象マシンのホームディレクトリで`tar xzvf tiup.tar.gz`実行します。 +3. 対象マシンのホームディレクトリで`tar xzvf tiup.tar.gz`を実行します。 4. `.tiup`ディレクトリを`PATH`環境変数に追加します。 - `bash`使用し、 `tidb`ユーザーの場合は、 `~/.bashrc`に`export PATH=/home/tidb/.tiup/bin:$PATH`追加して`source ~/.bashrc`実行します。その後、使用するシェルとユーザーに応じて調整してください。 + `bash`使用し、 `tidb`ユーザーの場合は、 `~/.bashrc`に`export PATH=/home/tidb/.tiup/bin:$PATH`追加して`source ~/.bashrc`を実行します。その後、使用するシェルとユーザーに応じて調整してください。 > **注記：** > diff --git a/tiup/tiup-command-completion.md b/tiup/tiup-command-completion.md index 06d1568fda918..30d183f814e77 100644 --- a/tiup/tiup-command-completion.md +++ b/tiup/tiup-command-completion.md @@ -9,8 +9,8 @@ summary: TiUPは、 tiup completionコマンドを使用して、bash`および` `bash`コマンドを実行するには、まず`bash-completion`をインストールする必要があります。以下の手順をご覧ください。 -- macOS の場合: bash バージョンが 4.1 より前の場合は`brew install bash-completion`実行し、それ以外の場合は`brew install bash-completion@2`実行します。 -- Linuxの場合：パッケージマネージャーを使用して`bash-completion`インストールします。たとえば、 `yum install bash-completion`または`apt install bash-completion`実行します。 +- macOS の場合: bash バージョンが 4.1 より前の場合は`brew install bash-completion`実行し、それ以外の場合は`brew install bash-completion@2`を実行します。 +- Linuxの場合：パッケージマネージャーを使用して`bash-completion`インストールします。たとえば、 `yum install bash-completion`または`apt install bash-completion`を実行します。 ## 構文 {#syntax} diff --git a/tiup/tiup-command-env.md b/tiup/tiup-command-env.md index 9a88eb7ecb625..2874884bf92e9 100644 --- a/tiup/tiup-command-env.md +++ b/tiup/tiup-command-env.md @@ -21,8 +21,8 @@ tiup env [name1...N] ## 出力 {#output} -- `[name1...N]`指定しない場合は「{key}」="{value}"のリストが出力されます。 -- `[name1...N]`指定した場合は、「{value}」リストが順に出力されます。 +- `[name1...N]`を指定しない場合は「{key}」="{value}"のリストが出力されます。 +- `[name1...N]`を指定した場合は、「{value}」リストが順に出力されます。 上記の出力で、 `value`が空の場合、環境変数の値が設定されていないことを意味します。この場合、 TiUP はデフォルト値を使用します。 diff --git a/tiup/tiup-command-list.md b/tiup/tiup-command-list.md index 392006205fc1a..b530175393564 100644 --- a/tiup/tiup-command-list.md +++ b/tiup/tiup-command-list.md @@ -38,7 +38,7 @@ tiup list [component] [flags] ## 出力 {#outputs} - `[component]`が設定されていない場合: - - `--verbose`指定した場合: TiUP は、 `Name` (コンポーネント名)、 `Installed` (インストールされているバージョン)、 `Owner` (コンポーネント所有者)、および`Description` (コンポーネントの説明) で構成されるコンポーネント情報リストを出力します。 + - `--verbose`を指定した場合: TiUP は、 `Name` (コンポーネント名)、 `Installed` (インストールされているバージョン)、 `Owner` (コンポーネント所有者)、および`Description` (コンポーネントの説明) で構成されるコンポーネント情報リストを出力します。 - `--verbose`が指定されていない場合: TiUP は、 `Name` (コンポーネント名)、 `Owner` (コンポーネント所有者)、および`Description` (コンポーネントの説明) で構成されるコンポーネント情報リストを出力します。 - `[component]`設定されている場合: - 指定されたコンポーネントが存在する場合: TiUP は、指定されたコンポーネントのバージョン情報リストを出力します。リストは、 `Version` (バージョン番号)、 `Installed` (インストール状態)、 `Release` (リリース日)、および`Platforms` (サポートされているプラットフォーム) で構成されます。 diff --git a/tiup/tiup-command-mirror-clone.md b/tiup/tiup-command-mirror-clone.md index 114f18c78a6a5..9b59e46a95585 100644 --- a/tiup/tiup-command-mirror-clone.md +++ b/tiup/tiup-command-mirror-clone.md @@ -14,7 +14,7 @@ tiup mirror clone [global version] [flags] ``` - `` 、クローンミラーへのローカルパスを設定するために使用されます。パスが存在しない場合は、 TiUPによって自動的に作成されます。 -- `[global version]`指定した場合、 TiUP は指定されたバージョンのすべてのコンポーネントのクローンを作成しようとします。指定されたバージョンを持たないコンポーネントがある場合は、 TiUP はその最新バージョンのクローンを作成します。 +- `[global version]`を指定した場合、 TiUP は指定されたバージョンのすべてのコンポーネントのクローンを作成しようとします。指定されたバージョンを持たないコンポーネントがある場合は、 TiUP はその最新バージョンのクローンを作成します。 ## オプション {#options} diff --git a/tiup/tiup-command-mirror-genkey.md b/tiup/tiup-command-mirror-genkey.md index ae73002d61978..3b6a35e75eba2 100644 --- a/tiup/tiup-command-mirror-genkey.md +++ b/tiup/tiup-command-mirror-genkey.md @@ -47,9 +47,9 @@ tiup mirror genkey [flags] ## 出力 {#outputs} - `-p/--public`が指定されていない場合: - - `-n/--name`で指定された秘密鍵が存在する場合: TiUP は`Key already exists, skipped`出力します。 - - `-n/--name`で指定された秘密鍵が存在しない場合: TiUP は`private key have been write to ${TIUP_HOME}/keys/{name}.json`出力します。 -- `-p/--public`指定した場合: + - `-n/--name`で指定された秘密鍵が存在する場合: TiUP は`Key already exists, skipped`を出力します。 + - `-n/--name`で指定された秘密鍵が存在しない場合: TiUP は`private key have been write to ${TIUP_HOME}/keys/{name}.json`を出力します。 +- `-p/--public`を指定した場合: - `-n/--name`で指定された秘密鍵が存在しない場合: TiUP はエラー`Error: open ${TIUP_HOME}/keys/{name}.json: no such file or directory`報告します。 - `-n/--name`で指定された秘密鍵が存在する場合： TiUPは対応する公開鍵の内容を出力します。 diff --git a/tiup/tiup-command-mirror-modify.md b/tiup/tiup-command-mirror-modify.md index 1737102719cb6..346c4598653af 100644 --- a/tiup/tiup-command-mirror-modify.md +++ b/tiup/tiup-command-mirror-modify.md @@ -37,7 +37,7 @@ tiup mirror modify [:version] [flags] ### - 隠れる {#hide} -- コンポーネントを非表示にするかどうかを指定します。コンポーネントが非表示の場合、 `tiup list`の結果リストには表示されません。非表示のコンポーネントを表示するには、 `tiup list --all`使用します。 +- コンポーネントを非表示にするかどうかを指定します。コンポーネントが非表示の場合、 `tiup list`の結果リストには表示されません。非表示のコンポーネントを表示するには、 `tiup list --all`を使用します。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 diff --git a/tiup/tiup-command-mirror-rotate.md b/tiup/tiup-command-mirror-rotate.md index 63cb56d4bab70..646a1a4dcfe91 100644 --- a/tiup/tiup-command-mirror-rotate.md +++ b/tiup/tiup-command-mirror-rotate.md @@ -17,7 +17,7 @@ summary: TiUPミラーローテートは、 TiUPミラー内のroot.jsonファ TiUPミラーの詳細については、 [TiUPミラーリファレンス](/tiup/tiup-mirror-reference.md)参照してください。 -以下の場合には`root.json`更新する必要があります。 +以下の場合には`root.json`を更新する必要があります。 - ミラーのキーを交換してください。 - 証明書ファイルの有効期限を更新します。 @@ -26,9 +26,9 @@ TiUPミラーの詳細については、 [TiUPミラーリファレンス](/tiup 1. ユーザー（クライアント）は`root.json`のコンテンツを更新します。 2. すべての管理者が新しい`root.json`ファイルに署名します。 -3. tiup-server は`snapshot.json`更新して、新しい`root.json`ファイルのバージョンを記録します。 +3. tiup-server は`snapshot.json`を更新して、新しい`root.json`ファイルのバージョンを記録します。 4. tiup-server は新しい`snapshot.json`ファイルに署名します。 -5. tiup-server は`timestamp.json`更新して、新しい`snapshot.json`ファイルのハッシュ値を記録します。 +5. tiup-server は`timestamp.json`を更新して、新しい`snapshot.json`ファイルのハッシュ値を記録します。 6. tiup-server は新しい`timestamp.json`ファイルに署名します。 TiUP はコマンド`tiup mirror rotate`を使用して上記のプロセスを自動化します。 diff --git a/tiup/tiup-component-cluster-audit.md b/tiup/tiup-component-cluster-audit.md index 8481ad452e688..b7b45b87239d1 100644 --- a/tiup/tiup-component-cluster-audit.md +++ b/tiup/tiup-component-cluster-audit.md @@ -26,8 +26,8 @@ tiup cluster audit [audit-id] [flags] ## 出力 {#outputs} -- `[audit-id]`指定した場合、対応する実行ログが出力されます。 -- `[audit-id]`指定しない場合は、次のフィールドを含むテーブルが出力されます。 +- `[audit-id]`を指定した場合、対応する実行ログが出力されます。 +- `[audit-id]`を指定しない場合は、次のフィールドを含むテーブルが出力されます。 - ID: レコードに対応する`audit-id` - 時間: レコードに対応するコマンドの実行時間 - コマンド: レコードに対応するコマンド diff --git a/tiup/tiup-component-cluster-check.md b/tiup/tiup-component-cluster-check.md index 03b090de6385b..be95d6e0012ca 100644 --- a/tiup/tiup-component-cluster-check.md +++ b/tiup/tiup-component-cluster-check.md @@ -58,7 +58,7 @@ THP が有効になっているかどうかを確認するには、次のコマ `never`に設定されていない場合は`grubby --update-kernel=ALL --args="transparent_hugepage=never"`に変更できます。 -実行中の設定を変更するには、再起動するか、 `echo never > /sys/kernel/mm/transparent_hugepage/enabled`実行します。 +実行中の設定を変更するには、再起動するか、 `echo never > /sys/kernel/mm/transparent_hugepage/enabled`を実行します。 ### システム制限 {#system-limits} @@ -138,7 +138,7 @@ tiup cluster check [flags] > **注記：** > -> チェックに``使用する場合は、コマンドに`--cluster`オプションを追加する必要があります。 +> チェックに``を使用する場合は、コマンドに`--cluster`オプションを追加する必要があります。 ## オプション {#options} diff --git a/tiup/tiup-component-cluster-deploy.md b/tiup/tiup-component-cluster-deploy.md index 28323d22d9f08..e542c85fc1ccc 100644 --- a/tiup/tiup-component-cluster-deploy.md +++ b/tiup/tiup-component-cluster-deploy.md @@ -47,7 +47,7 @@ tiup cluster deploy [flags] - このオプションはラベル チェックをスキップするために使用されます。 - 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、PDがクラスタトポロジを学習できないため、同じ物理マシン上の異なるTiKVノードにリージョンの複数のレプリカをスケジュールし、その物理マシンを単一のポイントにしてしまうというリスクが生じます。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)参照してください。 -- テスト環境では、このリスクが重要になる可能性があるため、 `--no-labels`使用してチェックをスキップできます。 +- テスト環境では、このリスクが重要になる可能性があるため、 `--no-labels`を使用してチェックをスキップできます。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 diff --git a/tiup/tiup-component-cluster-disable.md b/tiup/tiup-component-cluster-disable.md index bb6b5b1caa9e6..87a7da4652fd8 100644 --- a/tiup/tiup-component-cluster-disable.md +++ b/tiup/tiup-component-cluster-disable.md @@ -5,7 +5,7 @@ summary: tiup cluster disable`コマンドは、マシンの再起動後にク # tiup cluster disable {#tiup-cluster-disable} -クラスタサービスが配置されているマシンを再起動すると、クラスタサービスは自動的に有効化されます。クラスタサービスの自動有効化を無効にするには、コマンド`tiup cluster disable`使用します。このコマンドは、指定されたノードでコマンド`systemctl disable `を実行し、サービスの自動有効化を無効にします。 +クラスタサービスが配置されているマシンを再起動すると、クラスタサービスは自動的に有効化されます。クラスタサービスの自動有効化を無効にするには、コマンド`tiup cluster disable`を使用します。このコマンドは、指定されたノードでコマンド`systemctl disable `を実行し、サービスの自動有効化を無効にします。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-cluster-enable.md b/tiup/tiup-component-cluster-enable.md index 34434e7c003b2..bd87123a5b45c 100644 --- a/tiup/tiup-component-cluster-enable.md +++ b/tiup/tiup-component-cluster-enable.md @@ -5,7 +5,7 @@ summary: tiup cluster enable` コマンドは、マシンの再起動後にク # tiup cluster enable {#tiup-cluster-enable} -`tiup cluster enable`コマンドは、マシンの再起動後にクラスタサービスを自動的に有効化するように設定するために使用されます。このコマンドは、指定されたノードで`systemctl enable `実行することで、サービスの自動有効化を有効にします。 +`tiup cluster enable`コマンドは、マシンの再起動後にクラスタサービスを自動的に有効化するように設定するために使用されます。このコマンドは、指定されたノードで`systemctl enable `を実行することで、サービスの自動有効化を有効にします。 > **注記：** > diff --git a/tiup/tiup-component-cluster-patch.md b/tiup/tiup-component-cluster-patch.md index d1696087c3a19..c667ed6b3712e 100644 --- a/tiup/tiup-component-cluster-patch.md +++ b/tiup/tiup-component-cluster-patch.md @@ -71,7 +71,7 @@ tiup cluster patch [flags] ### --overwrite {#overwrite} -- 特定のコンポーネント（TiDBやTiKVなど）にパッチを適用した後、TiUPクラスタがそのコンポーネントをスケールアウトすると、 TiUPはデフォルトで元のコンポーネントバージョンを使用します。将来クラスタがスケールアウトする際にパッチを適用したバージョンを使用するには、コマンドでオプション`--overwrite`指定する必要があります。 +- 特定のコンポーネント（TiDBやTiKVなど）にパッチを適用した後、TiUPクラスタがそのコンポーネントをスケールアウトすると、 TiUPはデフォルトで元のコンポーネントバージョンを使用します。将来クラスタがスケールアウトする際にパッチを適用したバージョンを使用するには、コマンドでオプション`--overwrite`を指定する必要があります。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 diff --git a/tiup/tiup-component-cluster-reload.md b/tiup/tiup-component-cluster-reload.md index 55f0b371960c5..1a5b96c61e8b9 100644 --- a/tiup/tiup-component-cluster-reload.md +++ b/tiup/tiup-component-cluster-reload.md @@ -35,7 +35,7 @@ tiup cluster reload [flags] ### --ignore-config-check {#ignore-config-check} -- コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `使用して TiDB、TiKV、PD コンポーネントの設定がチェックされます。3 ``デプロイされたバイナリファイルのパスです。5 ``ユーザー設定に基づいて生成された設定ファイルです。このチェックをスキップしたい場合は、このオプションを使用できます。 +- コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `を使用して TiDB、TiKV、PD コンポーネントの設定がチェックされます。3 ``デプロイされたバイナリファイルのパスです。5 ``ユーザー設定に基づいて生成された設定ファイルです。このチェックをスキップしたい場合は、このオプションを使用できます。 - データ型: `BOOLEAN` - デフォルト: false @@ -48,7 +48,7 @@ tiup cluster reload [flags] > **注記：** > > - `-R, --role`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 -> - オプション`--skip-restart`指定した場合、オプション`-N, --node`は無効になります。 +> - オプション`--skip-restart`を指定した場合、オプション`-N, --node`は無効になります。 ### -R, --role {#r-role} @@ -59,7 +59,7 @@ tiup cluster reload [flags] > **注記：** > > 1. `-N, --node`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 -> 2. オプション`--skip-restart`指定した場合、オプション`-R, --role`は無効になります。 +> 2. オプション`--skip-restart`を指定した場合、オプション`-R, --role`は無効になります。 ### --skip-restart {#skip-restart} diff --git a/tiup/tiup-component-cluster-scale-in.md b/tiup/tiup-component-cluster-scale-in.md index 7d5d71942058b..ca925ee6646b0 100644 --- a/tiup/tiup-component-cluster-scale-in.md +++ b/tiup/tiup-component-cluster-scale-in.md @@ -15,7 +15,7 @@ TiKV およびTiFlashコンポーネントは非同期的にオフラインに 1. TiUPクラスタはAPI を介してノードをオフラインにし、プロセスが完了するのを待たずにすぐに終了します。 2. スケールインされているノードのステータスを確認するには、 `tiup cluster display`コマンドを実行し、ステータスが`Tombstone`なるまで待つ必要があります。 - 3. ステータス`Tombstone`のノードをクリーンアップするには、コマンド`tiup cluster prune`実行する必要があります。コマンド`tiup cluster prune`は以下の操作を実行します。 + 3. ステータス`Tombstone`のノードをクリーンアップするには、コマンド`tiup cluster prune`を実行する必要があります。コマンド`tiup cluster prune`は以下の操作を実行します。 - オフラインになったノードのサービスを停止します。 - オフラインになったノードのデータ ファイルをクリーンアップします。 diff --git a/tiup/tiup-component-cluster-scale-out.md b/tiup/tiup-component-cluster-scale-out.md index 2c50b0e80f702..1f0b86002ecb0 100644 --- a/tiup/tiup-component-cluster-scale-out.md +++ b/tiup/tiup-component-cluster-scale-out.md @@ -43,7 +43,7 @@ tiup cluster scale-out [flags] - このオプションはラベル チェックをスキップするために使用されます。 - 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、リスクが生じます。PDはクラスタトポロジを把握していないため、同じ物理マシン上の異なるTiKVノードにリージョンのレプリカを複数スケジュールしてしまう可能性があり、その結果、この物理マシンが単一障害点となります。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)参照してください。 -- テスト環境では、このリスクは問題にならない可能性があり、 `--no-labels`使用してチェックをスキップできます。 +- テスト環境では、このリスクは問題にならない可能性があり、 `--no-labels`を使用してチェックをスキップできます。 - データ型: `BOOLEAN` - デフォルト: false diff --git a/tiup/tiup-component-cluster-upgrade.md b/tiup/tiup-component-cluster-upgrade.md index 8c21d57363a7b..160fad3374ab7 100644 --- a/tiup/tiup-component-cluster-upgrade.md +++ b/tiup/tiup-component-cluster-upgrade.md @@ -20,7 +20,7 @@ tiup cluster upgrade [flags] ### --force {#force} -- クラスターをアップグレードするには、クラスターが現在起動していることを確認する必要があります。場合によっては、クラスターが起動していない状態でアップグレードを実行したい場合があります。その場合は、 `--force`使用すると、アップグレード中のエラーを無視し、バイナリファイルを強制的に置き換えてクラスターを起動できます。 +- クラスターをアップグレードするには、クラスターが現在起動していることを確認する必要があります。場合によっては、クラスターが起動していない状態でアップグレードを実行したい場合があります。その場合は、 `--force`を使用すると、アップグレード中のエラーを無視し、バイナリファイルを強制的に置き換えてクラスターを起動できます。 - データ型: `BOOLEAN` - デフォルト: false @@ -40,13 +40,13 @@ tiup cluster upgrade [flags] ### --ignore-config-check {#ignore-config-check} -- バイナリの更新後、 ` --config-check `使用して TiDB、TiKV、PD コンポーネントの構成チェックが実行されます。3 ``新しくデプロイされたバイナリへのパス、 ``ユーザー設定に基づいて生成された構成ファイルです。このチェックをスキップするには、 `--ignore-config-check`オプションを使用します。 +- バイナリの更新後、 ` --config-check `を使用して TiDB、TiKV、PD コンポーネントの構成チェックが実行されます。3 ``新しくデプロイされたバイナリへのパス、 ``ユーザー設定に基づいて生成された構成ファイルです。このチェックをスキップするには、 `--ignore-config-check`オプションを使用します。 - データ型: `BOOLEAN` - デフォルト: false ### --ignore-version-check {#ignore-version-check} -- アップグレード前に、 TiUP はターゲットバージョンが現在のバージョン以上であるかどうかを確認します。このチェックを省略するには、オプション`--ignore-version-check`使用します。 +- アップグレード前に、 TiUP はターゲットバージョンが現在のバージョン以上であるかどうかを確認します。このチェックを省略するには、オプション`--ignore-version-check`を使用します。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 diff --git a/tiup/tiup-component-dm-audit.md b/tiup/tiup-component-dm-audit.md index 0a6a82e9b90c5..12c1490ef690e 100644 --- a/tiup/tiup-component-dm-audit.md +++ b/tiup/tiup-component-dm-audit.md @@ -26,8 +26,8 @@ tiup dm audit [audit-id] [flags] ## 出力 {#output} -- `[audit-id]`指定した場合、対応する実行ログが出力されます。 -- `[audit-id]`指定しない場合は、次のフィールドを含むテーブルが出力されます。 +- `[audit-id]`を指定した場合、対応する実行ログが出力されます。 +- `[audit-id]`を指定しない場合は、次のフィールドを含むテーブルが出力されます。 - ID: このレコードに対応する`audit-id` - 時間: レコードに対応するコマンドの実行時間 - コマンド: レコードに対応するコマンド diff --git a/tiup/tiup-component-dm-disable.md b/tiup/tiup-component-dm-disable.md index 0621dd5af5a9e..ed9434c7b08e3 100644 --- a/tiup/tiup-component-dm-disable.md +++ b/tiup/tiup-component-dm-disable.md @@ -5,7 +5,7 @@ summary: tiup dm disable`コマンドは、マシンの再起動後にクラス # tiup dm 無効 {#tiup-dm-disable} -クラスタサービスが配置されているマシンを再起動すると、クラスタサービスは自動的に有効化されます。クラスタサービスの自動有効化を無効にするには、コマンド`tiup dm disable`使用します。このコマンドは、指定されたノードでコマンド`systemctl disable `を実行し、サービスの自動有効化を無効にします。 +クラスタサービスが配置されているマシンを再起動すると、クラスタサービスは自動的に有効化されます。クラスタサービスの自動有効化を無効にするには、コマンド`tiup dm disable`を使用します。このコマンドは、指定されたノードでコマンド`systemctl disable `を実行し、サービスの自動有効化を無効にします。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-dm-enable.md b/tiup/tiup-component-dm-enable.md index a96b0a81ef009..2760af78c63a8 100644 --- a/tiup/tiup-component-dm-enable.md +++ b/tiup/tiup-component-dm-enable.md @@ -5,7 +5,7 @@ summary: tiup dm enable`コマンドは、マシンの再起動後にクラス # tiup dm 有効 {#tiup-dm-enable} -`tiup dm enable`コマンドは、マシンの再起動後にクラスタサービスを自動的に有効化するように設定するために使用されます。このコマンドは、指定されたノードで`systemctl enable `実行することで、サービスの自動有効化を有効にします。 +`tiup dm enable`コマンドは、マシンの再起動後にクラスタサービスを自動的に有効化するように設定するために使用されます。このコマンドは、指定されたノードで`systemctl enable `を実行することで、サービスの自動有効化を有効にします。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-dm-import.md b/tiup/tiup-component-dm-import.md index 3e2356b7fab10..d50143ef23e6b 100644 --- a/tiup/tiup-component-dm-import.md +++ b/tiup/tiup-component-dm-import.md @@ -17,11 +17,11 @@ DM v1.0では、クラスターは基本的にTiDB Ansibleを使用してデプ > > - このコマンドは、DM v1.0 クラスターからの DM Portal コンポーネントのインポートをサポートしていません。 > - クラスターをインポートする前に、まず元のクラスターの実行を停止します。 -> - v2.0 にアップグレードする必要があるデータ移行タスクの場合、これらのタスクで`stop-task`実行しないでください。 +> - v2.0 にアップグレードする必要があるデータ移行タスクの場合、これらのタスクで`stop-task`を実行しないでください。 > - このコマンドは、DM v2.0.0-rc.2 以降のバージョンへのインポートのみをサポートします。 > - `import`コマンドは、DM v1.0 クラスタを新しい DM v2.0 クラスタにインポートするために使用されます。既存の v2.0 クラスタにデータ移行タスクをインポートする必要がある場合は、 [TiDB データ移行を v1.0.x から v2.0+ に手動でアップグレードする](/dm/manually-upgrade-dm-1.0-to-2.0.md)を参照してください。 > - 一部のコンポーネントのデプロイメントディレクトリは、元のクラスタのものと異なる場合`display`あります。1 コマンドで確認できます。 -> - クラスターをインポートする前に、 `tiup update --self && tiup update dm`実行してTiUP DMコンポーネントを最新バージョンにアップグレードします。 +> - クラスターをインポートする前に、 `tiup update --self && tiup update dm`を実行してTiUP DMコンポーネントを最新バージョンにアップグレードします。 > - クラスターをインポートすると、クラスター内のDMマスターノードは1つだけになります。DMマスターノードをスケールアウトするには、 [`scale out`コマンド](/tiup/tiup-component-dm-scale-out.md)を参照してください。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-dm-patch.md b/tiup/tiup-component-dm-patch.md index 4f3ce90f63a11..1389f0b91d139 100644 --- a/tiup/tiup-component-dm-patch.md +++ b/tiup/tiup-component-dm-patch.md @@ -28,18 +28,18 @@ tiup dm patch [flags] - 置換するコンポーネントの名前`${component}` (dm-master、dm-worker ...)、コンポーネントの`${version}` (v2.0.0、v2.0.1 ...)、およびコンポーネントが実行されるオペレーティング システム`${os}`とプラットフォーム`${arch}`決定します。 - コマンド`wget https://tiup-mirrors.pingcap.com/${component}-${version}-${os}-${arch}.tar.gz -O /tmp/${component}-${version}-${os}-${arch}.tar.gz`を使用して現在のコンポーネントパッケージをダウンロードします。 -- `mkdir -p /tmp/package && cd /tmp/package`実行して、ファイルをパックするための一時ディレクトリを作成します。 -- `tar xf /tmp/${component}-${version}-${os}-${arch}.tar.gz`実行して元のバイナリ パッケージを解凍します。 -- `find .`実行して、一時パッケージ ディレクトリ内のファイル構造を表示します。 +- `mkdir -p /tmp/package && cd /tmp/package`を実行して、ファイルをパックするための一時ディレクトリを作成します。 +- `tar xf /tmp/${component}-${version}-${os}-${arch}.tar.gz`を実行して元のバイナリ パッケージを解凍します。 +- `find .`を実行して、一時パッケージ ディレクトリ内のファイル構造を表示します。 - バイナリ ファイルまたは構成ファイルを一時ディレクトリ内の対応する場所にコピーします。 -- `tar czf /tmp/${component}-hotfix-${os}-${arch}.tar.gz *`実行して、一時ディレクトリにファイルをパックします。 +- `tar czf /tmp/${component}-hotfix-${os}-${arch}.tar.gz *`を実行して、一時ディレクトリにファイルをパックします。 - 最後に、 `tiup dm patch`コマンドの``の値として`/tmp/${component}-hotfix-${os}-${arch}.tar.gz`使用できます。 ## オプション {#options} ### --overwrite {#overwrite} -- 特定のコンポーネント（dm-workerなど）にパッチを適用した後、tiup-dmがそのコンポーネントをスケールアウトすると、tiup-dmはデフォルトで元のコンポーネントバージョンを使用します。将来クラスタがスケールアウトした際にパッチを適用したバージョンを使用するには、コマンドでオプション`--overwrite`指定する必要があります。 +- 特定のコンポーネント（dm-workerなど）にパッチを適用した後、tiup-dmがそのコンポーネントをスケールアウトすると、tiup-dmはデフォルトで元のコンポーネントバージョンを使用します。将来クラスタがスケールアウトした際にパッチを適用したバージョンを使用するには、コマンドでオプション`--overwrite`を指定する必要があります。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 diff --git a/tiup/tiup-component-dm-reload.md b/tiup/tiup-component-dm-reload.md index 8f2eae4671733..f47fec9bfad8c 100644 --- a/tiup/tiup-component-dm-reload.md +++ b/tiup/tiup-component-dm-reload.md @@ -26,7 +26,7 @@ tiup dm reload [flags] > **注記：** > > - `-R, --role`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 -> - オプション`--skip-restart`指定した場合、オプション`-N, --node`は無効になります。 +> - オプション`--skip-restart`を指定した場合、オプション`-N, --node`は無効になります。 ### -R, --role {#r-role} @@ -37,7 +37,7 @@ tiup dm reload [flags] > **注記：** > > - `-N, --node`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 -> - オプション`--skip-restart`指定した場合、オプション`-R, --role`は無効になります。 +> - オプション`--skip-restart`を指定した場合、オプション`-R, --role`は無効になります。 ### --skip-restart {#skip-restart} diff --git a/tiup/tiup-component-management.md b/tiup/tiup-component-management.md index d963b531d0585..7e5279fd813bb 100644 --- a/tiup/tiup-component-management.md +++ b/tiup/tiup-component-management.md @@ -109,7 +109,7 @@ Flags: コンポーネントが起動する前に、 TiUP はコンポーネント用のディレクトリを作成し、そのディレクトリにコンポーネントを配置して操作を行います。コンポーネントはこのディレクトリ内にすべてのデータを生成し、このディレクトリの名前はコンポーネント操作時に指定されたタグ名になります。タグが指定されていない場合は、ランダムにタグ名が生成されます。この作業ディレクトリは、インスタンスの終了時に*自動的に削除され*ます。 -同じコンポーネントを複数回起動し、前回の作業ディレクトリを再利用したい場合は、コンポーネント起動時に同じ名前のタグ`--tag`指定することで、タグを1つ指定できます。タグを指定すると、インスタンス終了時に作業ディレクトリが*自動的に削除されなくなり*、作業ディレクトリの再利用が容易になります。 +同じコンポーネントを複数回起動し、前回の作業ディレクトリを再利用したい場合は、コンポーネント起動時に同じ名前のタグ`--tag`を指定することで、タグを1つ指定できます。タグを指定すると、インスタンス終了時に作業ディレクトリが*自動的に削除されなくなり*、作業ディレクトリの再利用が容易になります。 例 1: TiDB v8.5.3 を操作します。 @@ -154,7 +154,7 @@ tiup clean [tag] [flags] - `--all` : すべてのインスタンス情報をクリーンアップします。 -上記のコマンドでは、 `tag`クリーンアップするインスタンスタグです。3 `--all`使用すると、タグは渡されません。 +上記のコマンドでは、 `tag`クリーンアップするインスタンスタグです。3 `--all`を使用すると、タグは渡されません。 例 1: `experiment`タグ名を持つコンポーネントインスタンスをクリーンアップします。 diff --git a/tiup/tiup-mirror-reference.md b/tiup/tiup-mirror-reference.md index 4434d69e8e92b..0d93d74725206 100644 --- a/tiup/tiup-mirror-reference.md +++ b/tiup/tiup-mirror-reference.md @@ -14,8 +14,8 @@ TiUPミラーは、コンポーネントとそのメタデータを保存するT 次の 2 つの方法のいずれかを使用してTiUPミラーを作成できます。 -- ミラーを最初から作成するには、 `tiup mirror init`実行します。 -- 既存のミラーからクローンを作成するには、 `tiup mirror clone`実行します。 +- ミラーを最初から作成するには、 `tiup mirror init`を実行します。 +- 既存のミラーからクローンを作成するには、 `tiup mirror clone`を実行します。 ミラーを作成した後、 `tiup mirror`コマンドを使用してミラーにコンポーネントを追加したり、ミラーからコンポーネントを削除したりできます。TiUPは、ミラーからファイルを削除するのではなく、ファイルを追加して新しいバージョン番号を割り当てることでミラーを更新します。 diff --git a/tiup/tiup-mirror.md b/tiup/tiup-mirror.md index ac8f58ba3bd68..35c043577ac30 100644 --- a/tiup/tiup-mirror.md +++ b/tiup/tiup-mirror.md @@ -80,7 +80,7 @@ tiup mirror clone [global-version] [flags] - パッケージの特定のバージョンをクローンするかどうかを決定します - コンポーネントの1つのバージョンのみ（すべてのバージョンではなく）を複製したい場合は、 `--=`使用してそのバージョンを指定します。例： + コンポーネントの1つのバージョンのみ（すべてのバージョンではなく）を複製したい場合は、 `--=`を使用してそのバージョンを指定します。例： - `tiup mirror clone --tidb v8.5.3`コマンドを実行して、TiDBコンポーネントの v8.5.3 バージョンのクローンを作成します。 - `tiup mirror clone --tidb v8.5.3 --tikv all`コマンドを実行して、TiDBコンポーネントの v8.5.3 バージョンと TiKVコンポーネントのすべてのバージョンのクローンを作成します。 @@ -102,9 +102,9 @@ tiup mirror set https://tiup-mirror.example.com/ > **注記：** > -> `tiup mirror clone`実行したマシンで`tiup mirror set...`実行した場合、次に`tiup mirror clone...`実行したときに、マシンはリモートミラーではなくローカルミラーからクローンを作成します。そのため、プライベートミラーを更新する前に`tiup mirror set --reset`実行してミラーをリセットする必要があります。 +> `tiup mirror clone`を実行したマシンで`tiup mirror set...`を実行した場合、次に`tiup mirror clone...`を実行したときに、マシンはリモートミラーではなくローカルミラーからクローンを作成します。そのため、プライベートミラーを更新する前に`tiup mirror set --reset`を実行してミラーをリセットする必要があります。 -ミラーを使用する別の方法は、環境変数`TIUP_MIRRORS`使用することです。以下は、プライベートリポジトリで`tiup list`実行する例です。 +ミラーを使用する別の方法は、環境変数`TIUP_MIRRORS`を使用することです。以下は、プライベートリポジトリで`tiup list`を実行する例です。 ```bash export TIUP_MIRRORS=/shared_data/tiup @@ -191,7 +191,7 @@ tiup mirror grant jdoe Starting component `hello`: /home/dvaneeden/.tiup/components/hello/v0.0.1/hello hello - `tiup mirror merge`使用すると、カスタムコンポーネントを含むリポジトリを別のリポジトリにマージできます。これは、 `/data/my_custom_components`内のすべてのコンポーネントが現在の`$USER`によって署名されていることを前提としています。 + `tiup mirror merge`を使用すると、カスタムコンポーネントを含むリポジトリを別のリポジトリにマージできます。これは、 `/data/my_custom_components`内のすべてのコンポーネントが現在の`$USER`によって署名されていることを前提としています。 ```bash $ tiup mirror set /data/my_mirror diff --git a/tiup/tiup-playground.md b/tiup/tiup-playground.md index 5c2d08c7f7e55..fd8ead0050847 100644 --- a/tiup/tiup-playground.md +++ b/tiup/tiup-playground.md @@ -142,7 +142,7 @@ tiup playground scale-out --db 2 ## クラスタースケールイン {#scale-in-a-cluster} -対応するインスタンスでスケールするには、 `tiup playground scale-in`コマンドで`pid`を指定できます。5 `pid`表示するには、 `tiup playground display`実行します。 +対応するインスタンスでスケールするには、 `tiup playground scale-in`コマンドで`pid`を指定できます。5 `pid`を表示するには、 `tiup playground display`を実行します。 ```shell tiup playground scale-in --pid 86526 diff --git a/tiup/tiup-reference.md b/tiup/tiup-reference.md index 1400313927b04..d086e5508be39 100644 --- a/tiup/tiup-reference.md +++ b/tiup/tiup-reference.md @@ -25,8 +25,8 @@ tiup [flags] [args...] # Runs a component - このオプションを有効にすると、指定されたバイナリ ファイルのパスが出力されます。 - - `tiup --binary `実行すると、最新の安定版がインストールされた``コンポーネントのパスが表示されます。5 ``インストールされていない場合はエラーが返されます。 - - `tiup --binary :`実行すると、インストールされた``コンポーネントの``パスが出力されます。この``が出力されない場合は、エラーが返されます。 + - `tiup --binary `を実行すると、最新の安定版がインストールされた``コンポーネントのパスが表示されます。5 ``インストールされていない場合はエラーが返されます。 + - `tiup --binary :`を実行すると、インストールされた``コンポーネントの``パスが出力されます。この``が出力されない場合は、エラーが返されます。 - データ型: `BOOLEAN` @@ -47,7 +47,7 @@ tiup [flags] [args...] # Runs a component ### -T, --タグ {#t-tag} -- 起動するコンポーネントのタグを指定します。一部のコンポーネントは実行中にディスクストレージを使用する必要があり、 TiUP はこの実行のために一時的なストレージディレクトリを割り当てます。TiUPに固定のディレクトリを割り当てたい場合は、ディレクトリ名に`-T/--tag`指定します。これにより、同じタグを持つ複数の実行で、同じファイルバッチの読み取りと書き込みが可能になります。 +- 起動するコンポーネントのタグを指定します。一部のコンポーネントは実行中にディスクストレージを使用する必要があり、 TiUP はこの実行のために一時的なストレージディレクトリを割り当てます。TiUPに固定のディレクトリを割り当てたい場合は、ディレクトリ名に`-T/--tag`を指定します。これにより、同じタグを持つ複数の実行で、同じファイルバッチの読み取りと書き込みが可能になります。 - データ型: `STRING` ### -v, --バージョン {#v-version} diff --git a/tiup/tiup-troubleshooting-guide.md b/tiup/tiup-troubleshooting-guide.md index 6ba4809fba802..e83c875fb0669 100644 --- a/tiup/tiup-troubleshooting-guide.md +++ b/tiup/tiup-troubleshooting-guide.md @@ -11,11 +11,11 @@ summary: TiUPの使用中に問題が発生した場合のトラブルシュー ### tiup listを使用して最新のコンポーネントリストを表示できません {#can-t-see-the-latest-component-list-using-code-tiup-list-code} -TiUPはミラーサーバーから最新のコンポーネントリストを毎回更新するわけではありません。1 `tiup list`実行することで、コンポーネントリストを強制的に更新できます。 +TiUPはミラーサーバーから最新のコンポーネントリストを毎回更新するわけではありません。1 `tiup list`を実行することで、コンポーネントリストを強制的に更新できます。 ### tiup list <component>を使用してコンポーネントの最新バージョン情報を表示できません {#can-t-see-the-latest-version-information-of-a-component-using-code-tiup-list-x3c-component-code} -前回の問題と同様に、コンポーネントのバージョン情報は、ローカルキャッシュが存在しない場合にのみミラーサーバーから取得されます。1 `tiup list `実行することでコンポーネントリストを更新できます。 +前回の問題と同様に、コンポーネントのバージョン情報は、ローカルキャッシュが存在しない場合にのみミラーサーバーから取得されます。1 `tiup list `を実行することでコンポーネントリストを更新できます。 ### コンポーネントのダウンロードプロセスが中断されました {#component-downloading-process-is-interrupted} @@ -31,9 +31,9 @@ CDNサーバーのキャッシュ時間が短いため、新しいチェック デプロイメント中に、コンポーネントパッケージがリモートホストにアップロードされ、初期化が実行されます。このプロセスではリモートホストへの接続が必要です。このエラーは、リモートホストに接続するためのSSH秘密鍵が見つからないために発生します。 -この問題を解決するには、 `tiup cluster deploy -i identity_file`実行して秘密鍵を指定したかどうかを確認します。 +この問題を解決するには、 `tiup cluster deploy -i identity_file`を実行して秘密鍵を指定したかどうかを確認します。 -- `-i`フラグが指定されていない場合、 TiUP は秘密鍵のパスを自動的に検出しない可能性があります。3 `-i`使用して秘密鍵のパスを明示的に指定することをお勧めします。 +- `-i`フラグが指定されていない場合、 TiUP は秘密鍵のパスを自動的に検出しない可能性があります。3 `-i`を使用して秘密鍵のパスを明示的に指定することをお勧めします。 - フラグ`-i`が指定されている場合、 TiUPは指定された秘密鍵を使用してリモートホストにログインできない可能性があります。3コマンド`ssh -i identity_file user@remote`手動で実行することで確認できます。 - リモート ホストへのログインにパスワードを使用する場合は、フラグ`-p`を指定して正しいログイン パスワードを入力したことを確認してください。 @@ -47,9 +47,9 @@ CDNサーバーのキャッシュ時間が短いため、新しいチェック 2. 新しいコンポーネントをリモートに配布 3. すべてのコンポーネントのローリング再起動を実行します -ローリング再起動中にアップグレードが中断された場合は、操作`tiup cluster upgrade`を繰り返す代わりに、操作`tiup cluster restart -N -N `使用して、再起動が完了していないノードを再起動できます。 +ローリング再起動中にアップグレードが中断された場合は、操作`tiup cluster upgrade`を繰り返す代わりに、操作`tiup cluster restart -N -N `を使用して、再起動が完了していないノードを再起動できます。 -同じコンポーネントの再起動されていないノードの数が比較的多い場合は、 `tiup cluster restart -R `実行して特定のタイプのコンポーネントを再起動することもできます。 +同じコンポーネントの再起動されていないノードの数が比較的多い場合は、 `tiup cluster restart -R `を実行して特定のタイプのコンポーネントを再起動することもできます。 ### アップグレード中に、 node_exporter-9100.service/blackbox_exporter-9115.serviceが存在しないことがわかります。 {#during-the-upgrade-you-find-that-code-node-exporter-9100-service-blackbox-exporter-9115-service-code-does-not-exist} diff --git a/transaction-overview.md b/transaction-overview.md index fa5d8c4d8e15a..7d18027e356a9 100644 --- a/transaction-overview.md +++ b/transaction-overview.md @@ -161,7 +161,7 @@ SET GLOBAL autocommit = 0; > **注記：** > -> 一部の文は暗黙的にコミットされます。例えば、 `[BEGIN|START TRANSACTION]`実行すると、最後のトランザクションが暗黙的にコミットされ、新しいトランザクションが開始されます。この動作はMySQLとの互換性を保つために必要です。詳細は[暗黙のコミット](https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html)を参照してください。 +> 一部の文は暗黙的にコミットされます。例えば、 `[BEGIN|START TRANSACTION]`を実行すると、最後のトランザクションが暗黙的にコミットされ、新しいトランザクションが開始されます。この動作はMySQLとの互換性を保つために必要です。詳細は[暗黙のコミット](https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html)を参照してください。 TiDBは明示的なトランザクション（`[BEGIN|START TRANSACTION]`と`COMMIT`を使用してトランザクションの開始と終了を定義する）と暗黙的なトランザクション（`SET autocommit = 1`）をサポートしています。 diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index c28665f9290ce..d4bc897d0f6d0 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -32,8 +32,8 @@ summary: 読み取りおよび書き込みのレイテンシーが長くなる - `set global tidb_auto_analyze_start_time='00:00 +0800';` - `set global tidb_auto_analyze_end_time='06:00 +0800';` - 実行プランをバインドする - - アプリケーションの SQL ステートメントを変更し、 `use index`実行して、列のインデックスを一貫して使用します。 - - 3.0バージョンでは、アプリケーションのSQL文を変更する必要はありません`create global binding`使用して、 `force index`のバインディングSQL文を作成します。 + - アプリケーションの SQL ステートメントを変更し、 `use index`を実行して、列のインデックスを一貫して使用します。 + - 3.0バージョンでは、アプリケーションのSQL文を変更する必要はありません`create global binding`を使用して、 `force index`のバインディングSQL文を作成します。 - 4.0 バージョンでは[SQLプラン管理](/sql-plan-management.md)サポートされており、不安定な実行プランによるパフォーマンスの低下を回避します。 ### PD異常 {#pd-anomalies} @@ -46,13 +46,13 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - ディスクの問題です。PDノードが配置されているディスクのI/O負荷が最大になっています。PDノードが、I/O需要の高い他のコンポーネントと同時にデプロイされていないか、またディスクの健全性を確認してください。Grafanaのモニターメトリクス（**ディスクパフォーマンス**、**レイテンシー**/**負荷**）を確認することで原因を確認できます。必要に応じて、FIOツールを使用してディスクのチェック**を**実行することもできます。 -- PDピア間のネットワークに問題が発生しています。PDログには`lost the TCP streaming connection`表示されています。Grafana -> **PD** -> **etcd**モニターの`round trip`確認して、PDノード間のネットワークに問題が発生し**て**いないか確認し、原因を検証する必要があります。 +- PDピア間のネットワークに問題が発生しています。PDログには`lost the TCP streaming connection`表示されています。Grafana -> **PD** -> **etcd**モニターの`round trip`を確認して、PDノード間のネットワークに問題が発生し**て**いないか確認し、原因を検証する必要があります。 - サーバーの負荷が高いです。ログには`server is likely overloaded`表示されています。 - PD がLeaderを選出できません: PD ログには`lease is not expired`表示されます。3 [この号](https://github.com/etcd-io/etcd/issues/10355) v3.0.x および v2.1.19 で修正されました。 -- リーダー選出が遅い。リージョンの読み込み時間が長い。この問題は、PDログで`grep "regions cost"`実行することで確認できます。結果が`load 460927 regions cost 11.77099s`秒など秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0では、 `use-region-storage`を`true`に設定することで`region storage`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。 +- リーダー選出が遅い。リージョンの読み込み時間が長い。この問題は、PDログで`grep "regions cost"`を実行することで確認できます。結果が`load 460927 regions cost 11.77099s`秒など秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0では、 `use-region-storage`を`true`に設定することで`region storage`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。 - TiDBとPD間のネットワークに問題があります。Grafana -> **blackbox_exporter** -> **ping レイテンシー****モニター**にアクセスして、TiDBからPD Leaderへのネットワークが正常に動作しているかどうかを確認してください。 @@ -86,7 +86,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - ネットワーク分離のため再選。 -- `block-cache`設定が大きすぎる場合、TiKV OOM が発生する可能性があります。問題の原因を確認するには、 **Grafana**モニターで該当するインスタンスを選択し、RocksDB の`block cache size`確認してください。同時に、 `[storage.block-cache] capacity = # "1GB"`パラメータが正しく設定されているかどうかを確認してください。デフォルトでは、 **TiKV**の`block-cache`マシンの総メモリの`45%`に設定されています。コンテナに TiKV をデプロイする際には、このパラメータを明示的に指定する必要があります。TiKV は物理マシンのメモリを取得するため、コンテナのメモリ制限を超える可能性があります。 +- `block-cache`設定が大きすぎる場合、TiKV OOM が発生する可能性があります。問題の原因を確認するには、 **Grafana**モニターで該当するインスタンスを選択し、RocksDB の`block cache size`を確認してください。同時に、 `[storage.block-cache] capacity = # "1GB"`パラメータが正しく設定されているかどうかを確認してください。デフォルトでは、 **TiKV**の`block-cache`マシンの総メモリの`45%`に設定されています。コンテナに TiKV をデプロイする際には、このパラメータを明示的に指定する必要があります。TiKV は物理マシンのメモリを取得するため、コンテナのメモリ制限を超える可能性があります。 - コプロセッサーは大量の大きなクエリを受信し、大量のデータを返します。gRPCはコプロセッサがデータを返すのに間に合うようにデータを送信できず、OOMが発生します。原因を確認するには、モニター**Grafana** -> **TiKV詳細**->**コプロセッサ概要**で、 `response size` `network outbound`トラフィックを超えているかどうかを確認してください。 @@ -124,7 +124,7 @@ CPU リソースの使用量がボトルネックになります。 **パラメータ調整:** -現在、 `tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`使用してインデックス作成の速度を動的に調整できます。通常、値が小さいほどシステムへの影響は小さくなりますが、実行時間は長くなります。 +現在、 `tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`を使用してインデックス作成の速度を動的に調整できます。通常、値が小さいほどシステムへの影響は小さくなりますが、実行時間は長くなります。 一般的なケースでは、まずデフォルト値（ `4`と`256` ）をそのままにして、クラスターのリソース使用量と応答速度を観察し、その後、同時実行性を高めるために値を`tidb_ddl_reorg_worker_cnt`に増やします。モニターで明らかなジッターが見られない場合は、値を`tidb_ddl_reorg_batch_size`に増やします。インデックス作成に関係する列が頻繁に更新される場合、結果として生じる多くの競合により、インデックス作成が失敗し、再試行されることになります。 diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 3affeed9ad8ec..12764f1faf182 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -100,7 +100,7 @@ ALTER TABLE: ALTER TABLE t SHARD_ROW_ID_BITS = 4; `CLUSTERED`型の主キーを持つテーブルの場合、TiDBはテーブルの主キーをRowIDとして使用します。この場合、 `SHARD_ROW_ID_BITS`オプションはRowIDの生成ルールを変更するため使用できません。5 `NONCLUSTERED`の主キーを持つテーブルの場合、TiDBは自動的に割り当てられた64ビット整数をRowIDとして使用します。この場合、 `SHARD_ROW_ID_BITS` `CLUSTERED`が使用できます。9型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 -以下の2つの負荷図は、主キーを持たない2つのテーブルで`SHARD_ROW_ID_BITS`使用してホットスポットを分散させた場合を示しています。最初の図はホットスポットを分散させる前の状況を示し、2番目の図はホットスポットを分散させた後の状況を示しています。 +以下の2つの負荷図は、主キーを持たない2つのテーブルで`SHARD_ROW_ID_BITS`を使用してホットスポットを分散させた場合を示しています。最初の図はホットスポットを分散させる前の状況を示し、2番目の図はホットスポットを分散させた後の状況を示しています。 ![Dashboard Example 5](/media/troubleshoot-hot-spot-issues-5.png) @@ -110,11 +110,11 @@ ALTER TABLE: ALTER TABLE t SHARD_ROW_ID_BITS = 4; ## AUTO_RANDOMを使用してAUTO_INCREMENT主キー ホットスポット テーブルを処理する {#handle-auto-increment-primary-key-hotspot-tables-using-code-auto-random-code} -AUTO_INCREMENT主キーによってもたらされる書き込みホットスポットを解決するには、 `AUTO_RANDOM`使用して、AUTO_INCREMENT主キーを持つホットスポット テーブルを処理します。 +AUTO_INCREMENT主キーによってもたらされる書き込みホットスポットを解決するには、 `AUTO_RANDOM`を使用して、AUTO_INCREMENT主キーを持つホットスポット テーブルを処理します。 この機能を有効にすると、TiDB は書き込みホットスポットを分散させる目的を達成するために、ランダムに分散され、重複のない (スペースが使い果たされる前に) 主キーを生成します。 -TiDB によって生成される主キーはAUTO_INCREMENT主キーではなくなり、 `LAST_INSERT_ID()`使用して前回割り当てられた主キー値を取得できることに注意してください。 +TiDB によって生成される主キーはAUTO_INCREMENT主キーではなくなり、 `LAST_INSERT_ID()`を使用して前回割り当てられた主キー値を取得できることに注意してください。 この機能を使用するには、 `CREATE TABLE`ステートメントの`AUTO_INCREMENT`を`AUTO_RANDOM`に変更してください。この機能は、主キーの一意性のみを保証する必要がある非アプリケーションシナリオに適しています。 @@ -146,13 +146,13 @@ SELECT LAST_INSERT_ID(); +------------------+ ``` -以下の2つの負荷図は、 `AUTO_INCREMENT` ～ `AUTO_RANDOM`を変更してホットスポットを分散させる前と後の状況を示しています。最初の図では`AUTO_INCREMENT`使用し、2番目の図では`AUTO_RANDOM`使用しています。 +以下の2つの負荷図は、 `AUTO_INCREMENT` ～ `AUTO_RANDOM`を変更してホットスポットを分散させる前と後の状況を示しています。最初の図では`AUTO_INCREMENT`使用し、2番目の図では`AUTO_RANDOM`を使用しています。 ![Dashboard Example 7](/media/troubleshoot-hot-spot-issues-7.png) ![Dashboard Example 8](/media/troubleshoot-hot-spot-issues-8.png) -上記の負荷図に示されているように、 `AUTO_INCREMENT`代わりに`AUTO_RANDOM`使用すると、ホットスポットを適切に分散できます。 +上記の負荷図に示されているように、 `AUTO_INCREMENT`代わりに`AUTO_RANDOM`を使用すると、ホットスポットを適切に分散できます。 詳細については[AUTO_RANDOM](/auto-random.md)参照してください。 diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index 9efa64ab38156..a670732502171 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -75,7 +75,7 @@ select `key`, count(*) as `count` from information_schema.data_lock_waits group 頻繁に問題が発生しているキーがわかっている場合は、 `TIDB_TRX`または`CLUSTER_TIDB_TRX`テーブルからキーをロックしようとしたトランザクションの情報を取得してみることができます。 -`TIDB_TRX`と`CLUSTER_TIDB_TRX`テーブルに表示される情報は、クエリ実行時に実行中のトランザクションの情報でもあることに注意してください。これらのテーブルには、完了したトランザクションの情報は表示されません。同時実行トランザクションの数が多い場合、クエリの結果セットも大きくなる可能性があります。5 句または`where`句`limit`使用すると、ロック待機時間が長いトランザクションをフィルタリングできます。Lock ビューで複数のテーブルを結合する場合、異なるテーブルのデータが同時に取得されない可能性があり、異なるテーブルの情報が一致しない可能性があることに注意してください。 +`TIDB_TRX`と`CLUSTER_TIDB_TRX`テーブルに表示される情報は、クエリ実行時に実行中のトランザクションの情報でもあることに注意してください。これらのテーブルには、完了したトランザクションの情報は表示されません。同時実行トランザクションの数が多い場合、クエリの結果セットも大きくなる可能性があります。5 句または`where`句`limit`を使用すると、ロック待機時間が長いトランザクションをフィルタリングできます。Lock ビューで複数のテーブルを結合する場合、異なるテーブルのデータが同時に取得されない可能性があり、異なるテーブルの情報が一致しない可能性があることに注意してください。 たとえば、 `where`句を使用してロック待機時間が長いトランザクションをフィルタリングするには、次の SQL ステートメントを実行します。 @@ -251,7 +251,7 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ [WARN] [session.go:446] ["commit failed"] [conn=149370] ["finished txn"="Txn{state=invalid}"] [error="[kv:6]Error: KV error safe to retry tikv restarts txn: Txn(Mvcc(TxnLockNotFound{ start_ts: 412720515987275779, commit_ts: 412720519984971777, key: [116, 128, 0, 0, 0, 0, 1, 111, 16, 95, 114, 128, 0, 0, 0, 0, 0, 0, 2] })) [try again later]"] ``` - - start_ts: 他のトランザクションによってロックがロールバックされたためにエラー`TxnLockNotFound`出力したトランザクションのstart_ts。上記のログでは、 `412720515987275779`がstart_tsです。 + - start_ts: 他のトランザクションによってロックがロールバックされたためにエラー`TxnLockNotFound`を出力したトランザクションのstart_ts。上記のログでは、 `412720515987275779`がstart_tsです。 - commit_ts: エラー`TxnLockNotFound`を出力したトランザクションのcommit_ts。上記のログでは、 `412720519984971777`がcommit_tsです。 2. TiKVサーバーのログを確認する diff --git a/troubleshoot-stale-read.md b/troubleshoot-stale-read.md index 94a3ed4496522..0bf2f3604915a 100644 --- a/troubleshoot-stale-read.md +++ b/troubleshoot-stale-read.md @@ -61,7 +61,7 @@ resolved-ts）は、この値より小さいタイムスタンプを持つすべ ### Grafanaを使って診断する {#use-grafana-to-diagnose} -[**TiKV詳細**>**解決済みTS**ダッシュボード](/grafana-tikv-dashboard.md#resolved-ts)では、各TiKVのresolved-tsとsafe-tsが最も小さいリージョンを特定できます。これらのタイムスタンプが実時間より大幅に遅れている場合は、 `tikv-ctl`使用してこれらのリージョンの詳細を確認する必要があります。 +[**TiKV詳細**>**解決済みTS**ダッシュボード](/grafana-tikv-dashboard.md#resolved-ts)では、各TiKVのresolved-tsとsafe-tsが最も小さいリージョンを特定できます。これらのタイムスタンプが実時間より大幅に遅れている場合は、 `tikv-ctl`を使用してこれらのリージョンの詳細を確認する必要があります。 ### tikv-ctlを使用して診断する {#use-code-tikv-ctl-code-to-diagnose} diff --git a/troubleshoot-tidb-oom.md b/troubleshoot-tidb-oom.md index 5b2d606d4e1b2..a5e3a756f1c38 100644 --- a/troubleshoot-tidb-oom.md +++ b/troubleshoot-tidb-oom.md @@ -18,7 +18,7 @@ summary: TiDB OOM (メモリ不足) の問題を診断して解決する方法 - **TiDB** >**サーバー**>**稼働時間が**突然ゼロに低下します。 - **TiDB-Runtime** >**メモリ使用量で**は、 `estimate-inuse`メトリックが上昇し続けていることがわかります。 -- `tidb.log`確認すると、次のログ エントリが見つかります。 +- `tidb.log`を確認すると、次のログ エントリが見つかります。 - OOMに関するアラーム: `[WARN] [memory_usage_alarm.go:139] ["tidb-server has the risk of OOM because of memory usage exceeds alarm ratio. Running SQLs and heap profile will be recorded in record path"]` 。詳細については、 [`memory-usage-alarm-ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio)参照してください。 - 再起動に関するログエントリ: `[INFO] [printer.go:33] ["Welcome to TiDB."]` 。 @@ -95,7 +95,7 @@ OOM 問題のさまざまな原因に応じて、SQL ステートメントのメ - 一部の演算子と関数はstorageレベルへのプッシュダウンがサポートされていないため、中間結果セットが大量に蓄積されます。このような場合は、SQL文を修正するか、ヒントを使用して最適化し、プッシュダウンをサポートする関数または演算子を使用する必要があります。 -- 実行プランにはHashAgg演算子が含まれています。HashAggは複数のスレッドで同時に実行されるため、高速ですがメモリ消費量は多くなります。代わりに`STREAM_AGG()`使用することもできます。 +- 実行プランにはHashAgg演算子が含まれています。HashAggは複数のスレッドで同時に実行されるため、高速ですがメモリ消費量は多くなります。代わりに`STREAM_AGG()`を使用することもできます。 - 同時実行数の増加によるメモリ問題を回避するには、同時に読み取る領域の数を減らすか、演算子の同時実行数を減らしてください。対応するシステム変数は次のとおりです。 - [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) @@ -174,11 +174,11 @@ OOM 問題の根本原因を特定するには、次の情報を収集する必 - より多くのメモリを消費する SQL ステートメントを確認します。 - TiDB Dashboardで、SQL ステートメントの分析、スロークエリ、メモリ使用量を確認する。 - - `INFORMATION_SCHEMA`の`SLOW_QUERY`と`CLUSTER_SLOW_QUERY`確認してください。 + - `INFORMATION_SCHEMA`の`SLOW_QUERY`と`CLUSTER_SLOW_QUERY`を確認してください。 - 各 TiDB ノードで`tidb_slow_query.log`チェックします。 - - `grep "expensive_query" tidb.log`実行して、対応するログ エントリを確認します。 - - `EXPLAIN ANALYZE`実行して、演算子のメモリ使用量を確認します。 - - `SELECT * FROM information_schema.processlist;`実行して`MEM`列の値を確認します。 + - `grep "expensive_query" tidb.log`を実行して、対応するログ エントリを確認します。 + - `EXPLAIN ANALYZE`を実行して、演算子のメモリ使用量を確認します。 + - `SELECT * FROM information_schema.processlist;`を実行して`MEM`列の値を確認します。 - メモリ使用量が多いときに TiDB プロファイル情報を収集するには、次のコマンドを実行します。 @@ -186,7 +186,7 @@ OOM 問題の根本原因を特定するには、次の情報を収集する必 curl -G "http://{TiDBIP}:10080/debug/zip?seconds=10" > profile.zip ``` -- `grep "tidb-server has the risk of OOM" tidb.log`実行して、TiDB サーバーによって収集されたアラートファイルのパスを確認します。出力例を以下に示します。 +- `grep "tidb-server has the risk of OOM" tidb.log`を実行して、TiDB サーバーによって収集されたアラートファイルのパスを確認します。出力例を以下に示します。 ```shell ["tidb-server has the risk of OOM because of memory usage exceeds alarm ratio. Running SQLs and heap profile will be recorded in record path"] ["is tidb_server_memory_limit set"=false] ["system memory total"=14388137984] ["system memory usage"=11897434112] ["tidb-server memory usage"=11223572312] [memory-usage-alarm-ratio=0.8] ["record path"="/tmp/0_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storage/record"] diff --git a/troubleshoot-write-conflicts.md b/troubleshoot-write-conflicts.md index 41d0c8121021a..8d69561836485 100644 --- a/troubleshoot-write-conflicts.md +++ b/troubleshoot-write-conflicts.md @@ -59,7 +59,7 @@ TiDBログを検索するキーワードとして`[kv:9007]Write conflict`を使 上記のログの説明は次のとおりです。 - `[kv:9007]Write conflict` : 書き込み間の競合を示します。 -- `txnStartTS=416617006551793665` : 現在のトランザクションの`start_ts`示します。4ツール`pd-ctl`使用して、 `start_ts`物理時間に変換できます。 +- `txnStartTS=416617006551793665` : 現在のトランザクションの`start_ts`示します。4ツール`pd-ctl`を使用して、 `start_ts`物理時間に変換できます。 - `conflictStartTS=416617018650001409` : 書き込み競合トランザクションの`start_ts`示します。 - `conflictCommitTS=416617023093080065` : 書き込み競合トランザクションの`commit_ts`示します。 - `key={tableID=47, indexID=1, indexValues={string, }}` : 書き込み競合キーを示します。2 `tableID`書き込み競合テーブルのIDを示します。4 `indexID`書き込み競合インデックスのIDを示します。書き込み競合キーがレコードキーの場合、ログには競合が発生しているレコード（行）を示す`handle=x`が出力。8 `indexValues`競合が発生しているインデックスの値を示します。 @@ -71,7 +71,7 @@ TiDBログを検索するキーワードとして`[kv:9007]Write conflict`を使 tiup ctl:v pd -u https://127.0.0.1:2379 tso {TIMESTAMP} ``` -`tableID`使用して、関連するテーブルの名前を見つけることができます。 +`tableID`を使用して、関連するテーブルの名前を見つけることができます。 ```shell curl http://{TiDBIP}:10080/db-table/{TableID} diff --git a/tune-operating-system.md b/tune-operating-system.md index 51fe9742c944e..7765f4042022e 100644 --- a/tune-operating-system.md +++ b/tune-operating-system.md @@ -109,7 +109,7 @@ echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler ネットワーク スタックは大部分が自己最適化されていますが、ネットワーク パケット処理における次の側面がボトルネックとなり、パフォーマンスに影響を及ぼす可能性があります。 -- NICハードウェアキャッシュ：ハードウェアレベルでパケットロスを正しく監視するには、コマンド`ethtool -S ${NIC_DEV_NAME}`使用してフィールド`drops`監視します。パケットロスが発生した場合、ハード/ソフト割り込みの処理速度がNICの受信速度に追いつかない可能性があります。受信バッファサイズが上限を下回っている場合は、パケットロスを回避するためにRXバッファを増やすことも検討できます。クエリコマンドは`ethtool -g ${NIC_DEV_NAME}` 、変更コマンドは`ethtool -G ${NIC_DEV_NAME}`です。 +- NICハードウェアキャッシュ：ハードウェアレベルでパケットロスを正しく監視するには、コマンド`ethtool -S ${NIC_DEV_NAME}`を使用してフィールド`drops`監視します。パケットロスが発生した場合、ハード/ソフト割り込みの処理速度がNICの受信速度に追いつかない可能性があります。受信バッファサイズが上限を下回っている場合は、パケットロスを回避するためにRXバッファを増やすことも検討できます。クエリコマンドは`ethtool -g ${NIC_DEV_NAME}` 、変更コマンドは`ethtool -G ${NIC_DEV_NAME}`です。 - ハードウェア割り込み：NICが受信側スケーリング（RSS、マルチNIC受信とも呼ばれる）機能をサポートしている場合は、 `/proc/interrupts` NIC割り込みを確認してください。割り込みが不均等な場合は、 [CPU—周波数スケーリング](#cpufrequency-scaling) 、 [CPU—割り込み親和性](#cpuinterrupt-affinity) 、および[NUMA CPU バインディング](#numa-cpu-binding)参照してください。NICがRSSをサポートしていない場合、またはRSSの数が物理CPUコア数よりも大幅に少ない場合は、受信パケットステアリング（RPS、RSSのソフトウェア実装とみなすことができます）と、RPSの拡張である受信フローステアリング（RFS）を設定してください。詳細な設定については、 [カーネルドキュメント](https://www.kernel.org/doc/Documentation/networking/scaling.txt)参照してください。 @@ -119,7 +119,7 @@ echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler - イーサネット フロー制御: NIC とスイッチがフロー制御機能をサポートしている場合は、この機能を使用して、カーネルが NIC キュー内のデータを処理するための時間を確保し、NIC バッファ オーバーフローの問題を回避できます。 -- 割り込みの統合：ハードウェア割り込みが多すぎるとシステムパフォーマンスが低下し、ハードウェア割り込みが遅すぎるとパケット損失が発生します。新しいNICは割り込み統合機能をサポートしており、ドライバがハードウェア割り込みの数を自動的に調整できます。この機能を有効にするには`ethtool -c ${NIC_DEV_NAME}` 、有効にするには`ethtool -C ${NIC_DEV_NAME}`実行します。アダプティブモードでは、NICが割り込み統合を自動的に調整します。このモードでは、ドライバはトラフィックモードとカーネル受信モードをチェックし、パケット損失を防ぐためにリアルタイムで統合設定を評価します。NICのブランドによって機能やデフォルト設定が異なります。詳細については、NICのマニュアルを参照してください。 +- 割り込みの統合：ハードウェア割り込みが多すぎるとシステムパフォーマンスが低下し、ハードウェア割り込みが遅すぎるとパケット損失が発生します。新しいNICは割り込み統合機能をサポートしており、ドライバがハードウェア割り込みの数を自動的に調整できます。この機能を有効にするには`ethtool -c ${NIC_DEV_NAME}` 、有効にするには`ethtool -C ${NIC_DEV_NAME}`を実行します。アダプティブモードでは、NICが割り込み統合を自動的に調整します。このモードでは、ドライバはトラフィックモードとカーネル受信モードをチェックし、パケット損失を防ぐためにリアルタイムで統合設定を評価します。NICのブランドによって機能やデフォルト設定が異なります。詳細については、NICのマニュアルを参照してください。 - アダプタキュー：カーネルはプロトコルスタックを処理する前に、このキューを使用してNICが受信したデータをバッファリングします。各CPUには独自のバックログキューがあります。このキューにキャッシュできるパケットの最大数は`netdev_max_backlog`です。2列目の`/proc/net/softnet_stat`注目してください。行の2列目が増加し続ける場合、CPU [行-1]キューがいっぱいになり、データパケットが失われていることを意味します。この問題を解決するには、 `net.core.netdev_max_backlog`値を2倍に増やし続けます。