From 2f1f19df3223cabd36435abf033b694aea7e19e8 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Fri, 24 Jul 2026 10:14:49 +0900 Subject: [PATCH] i18n(ja): restore text dropped by the translation pipeline (part 2) --- CONTRIBUTING.md | 2 +- agg-distinct-optimization.md | 2 +- ai/guides/image-search.md | 2 +- ai/guides/vector-search.md | 2 +- ai/reference/vector-search-data-types.md | 2 +- ai/reference/vector-search-index.md | 4 +- alert-rules.md | 8 +-- analyze-slow-queries.md | 2 +- as-of-timestamp.md | 4 +- auto-increment.md | 4 +- auto-random.md | 2 +- benchmark/benchmark-tidb-using-ch.md | 8 +-- benchmark/benchmark-tidb-using-sysbench.md | 2 +- ...line-workloads-and-add-index-operations.md | 6 +- best-practices/ddl-introduction.md | 2 +- .../grafana-monitor-best-practices.md | 2 +- .../high-concurrency-best-practices.md | 10 +-- .../index-management-best-practices.md | 2 +- .../massive-regions-best-practices.md | 6 +- .../multi-column-index-best-practices.md | 6 +- .../pd-scheduling-best-practices.md | 26 +++---- best-practices/saas-best-practices.md | 2 +- .../three-nodes-hybrid-deployment.md | 2 +- best-practices/uuid.md | 2 +- binary-package.md | 2 +- blocklist-control-plan.md | 8 +-- br/br-auto-tune.md | 2 +- br/br-batch-create-table.md | 2 +- br/br-checkpoint-backup.md | 4 +- br/br-checkpoint-restore.md | 66 ++++++++--------- br/br-incremental-guide.md | 2 +- br/br-monitoring-and-alert.md | 2 +- br/br-pitr-guide.md | 2 +- br/br-pitr-manual.md | 6 +- br/br-snapshot-manual.md | 4 +- br/use-br-command-line-tool.md | 8 +-- cached-tables.md | 4 +- certificate-authentication.md | 2 +- character-set-and-collation.md | 6 +- check-before-deployment.md | 10 +-- clinic/clinic-user-guide-for-tiup.md | 2 +- column-pruning.md | 2 +- command-line-flags-for-tidb-configuration.md | 2 +- command-line-flags-for-tikv-configuration.md | 2 +- comment-syntax.md | 2 +- configure-load-base-split.md | 4 +- configure-memory-usage.md | 4 +- configure-placement-rules.md | 2 +- daily-check.md | 2 +- dashboard/dashboard-diagnostics-report.md | 6 +- dashboard/dashboard-diagnostics-usage.md | 6 +- dashboard/dashboard-faq.md | 2 +- dashboard/dashboard-metrics-relation.md | 6 +- dashboard/dashboard-ops-reverse-proxy.md | 2 +- data-type-date-and-time.md | 8 +-- data-type-default-values.md | 6 +- data-type-overview.md | 2 +- data-type-string.md | 4 +- ddl_embedded_analyze.md | 2 +- develop/dev-guide-choose-driver-or-orm.md | 4 +- develop/dev-guide-connection-parameters.md | 10 +-- develop/dev-guide-join-tables.md | 2 +- .../dev-guide-optimize-sql-best-practices.md | 2 +- develop/dev-guide-optimize-sql.md | 4 +- develop/dev-guide-paginate-results.md | 2 +- develop/dev-guide-prepared-statement.md | 2 +- ...dev-guide-sql-development-specification.md | 2 +- ...v-guide-third-party-tools-compatibility.md | 2 +- develop/dev-guide-time-to-live.md | 2 +- develop/dev-guide-transaction-overview.md | 2 +- ...v-guide-unique-serial-number-generation.md | 2 +- develop/dev-guide-unstable-result-set.md | 2 +- develop/dev-guide-update-data.md | 4 +- .../dev-guide-use-common-table-expression.md | 2 +- develop/java-app-best-practices.md | 2 +- dm/deploy-a-dm-cluster-using-tiup-offline.md | 2 +- dm/deploy-a-dm-cluster-using-tiup.md | 2 +- dm/dm-block-allow-table-lists.md | 6 +- dm/dm-command-line-flags.md | 6 +- dm/dm-config-overview.md | 2 +- dm/dm-continuous-data-validation.md | 4 +- dm/dm-error-handling.md | 4 +- dm/dm-faq.md | 70 +++++++++---------- dm/dm-glossary.md | 2 +- dm/dm-handle-performance-issues.md | 6 +- dm/dm-pause-task.md | 4 +- dm/dm-performance-test.md | 2 +- dm/dm-stop-task.md | 2 +- dm/dm-table-routing.md | 2 +- dm/dm-tune-configuration.md | 2 +- dm/feature-online-ddl.md | 4 +- dm/feature-shard-merge-optimistic.md | 4 +- dm/feature-shard-merge-pessimistic.md | 2 +- dm/handle-failed-ddl-statements.md | 32 ++++----- dm/maintain-dm-using-tiup.md | 4 +- dm/manually-handling-sharding-ddl-locks.md | 6 +- dm/quick-start-create-task.md | 2 +- dm/quick-start-with-dm.md | 4 +- dm/relay-log.md | 4 +- dm/usage-scenario-master-slave-switch.md | 4 +- dr-secondary-cluster.md | 2 +- dynamic-config.md | 8 +-- encryption-at-rest.md | 10 +-- error-codes.md | 16 ++--- explain-aggregation.md | 2 +- explain-index-merge.md | 4 +- explain-indexes.md | 8 +-- explain-mpp.md | 2 +- explain-overview.md | 10 +-- explain-partitions.md | 2 +- explain-subqueries.md | 2 +- explain-walkthrough.md | 10 +-- exporting-grafana-snapshots.md | 2 +- extended-statistics.md | 2 +- faq/backup-and-restore-faq.md | 2 +- faq/deploy-and-maintain-faq.md | 4 +- faq/migration-tidb-faq.md | 6 +- faq/monitor-faq.md | 2 +- faq/sql-faq.md | 12 ++-- faq/tidb-faq.md | 2 +- filter-dml-event.md | 4 +- follower-read.md | 2 +- .../aggregate-group-by-functions.md | 6 +- .../cast-functions-and-operators.md | 4 +- .../control-flow-functions.md | 2 +- .../encryption-and-compression-functions.md | 2 +- .../functions-and-operators-overview.md | 2 +- functions-and-operators/group-by-modifier.md | 10 +-- .../information-functions.md | 2 +- functions-and-operators/json-functions.md | 4 +- .../json-functions-aggregate.md | 2 +- .../json-functions/json-functions-modify.md | 2 +- .../json-functions/json-functions-return.md | 2 +- .../json-functions/json-functions-search.md | 2 +- functions-and-operators/locking-functions.md | 2 +- functions-and-operators/precision-math.md | 6 +- functions-and-operators/set-operators.md | 2 +- functions-and-operators/string-functions.md | 20 +++--- functions-and-operators/tidb-functions.md | 18 ++--- functions-and-operators/window-functions.md | 2 +- garbage-collection-configuration.md | 2 +- global-indexes.md | 4 +- glossary.md | 4 +- grafana-overview-dashboard.md | 2 +- grafana-pd-dashboard.md | 2 +- grafana-performance-overview-dashboard.md | 2 +- grafana-resource-control-dashboard.md | 24 +++---- grafana-tidb-dashboard.md | 4 +- hybrid-deployment-topology.md | 2 +- identify-expensive-queries.md | 2 +- .../client-errors-summary-by-host.md | 2 +- .../client-errors-summary-by-user.md | 4 +- .../client-errors-summary-global.md | 2 +- .../information-schema-character-sets.md | 2 +- ...a-collation-character-set-applicability.md | 4 +- .../information-schema-collations.md | 2 +- .../information-schema-data-lock-waits.md | 2 +- .../information-schema-deadlocks.md | 6 +- .../information-schema-inspection-result.md | 4 +- .../information-schema-inspection-summary.md | 4 +- .../information-schema-metrics-summary.md | 4 +- .../information-schema-sequences.md | 2 +- .../information-schema-sql-diagnostics.md | 2 +- .../information-schema-table-constraints.md | 2 +- .../information-schema-tables.md | 2 +- ...formation-schema-tidb-check-constraints.md | 2 +- .../information-schema-tidb-servers-info.md | 2 +- .../information-schema-tidb-trx.md | 6 +- .../information-schema-tiflash-replica.md | 2 +- .../information-schema-tiflash-segments.md | 2 +- .../information-schema-tiflash-tables.md | 2 +- .../information-schema-variables-info.md | 2 +- latency-breakdown.md | 10 +-- literal-values.md | 6 +- log-redaction.md | 2 +- metadata-lock.md | 4 +- metrics-schema.md | 10 +-- migrate-from-tidb-to-tidb.md | 2 +- migrate-large-mysql-shards-to-tidb.md | 2 +- migrate-large-mysql-to-tidb.md | 2 +- migrate-small-mysql-shards-to-tidb.md | 4 +- migrate-with-more-columns-downstream.md | 6 +- migration-overview.md | 2 +- multi-data-centers-in-one-city-deployment.md | 2 +- optimizer-fix-controls.md | 2 +- optimizer-hints.md | 4 +- oracle-functions-to-tidb.md | 4 +- partition-pruning.md | 2 +- password-management.md | 8 +-- pd-configuration-file.md | 2 +- pd-control.md | 30 ++++---- pd-microservices.md | 6 +- performance-tuning-methods.md | 10 +-- performance-tuning-overview.md | 2 +- performance-tuning-practices.md | 6 +- pipelined-dml.md | 2 +- predicate-push-down.md | 2 +- quick-start-with-htap.md | 2 +- read-historical-data.md | 2 +- releases/release-2.1.17.md | 2 +- releases/release-2.1.19.md | 2 +- releases/release-3.0-ga.md | 4 +- releases/release-3.0.2.md | 4 +- releases/release-3.0.6.md | 2 +- releases/release-3.0.9.md | 2 +- releases/release-4.0.0-beta.md | 2 +- releases/release-4.0.0-rc.1.md | 2 +- releases/release-4.0.15.md | 2 +- releases/release-5.2.4.md | 2 +- releases/release-5.3.2.md | 2 +- releases/release-6.1.1.md | 2 +- releases/release-6.1.6.md | 2 +- releases/release-6.4.0.md | 4 +- releases/release-6.5.0.md | 10 +-- releases/release-6.5.6.md | 2 +- releases/release-6.6.0.md | 2 +- releases/release-7.0.0.md | 4 +- releases/release-7.1.0.md | 68 +++++++++--------- releases/release-7.1.3.md | 4 +- releases/release-7.1.4.md | 16 ++--- releases/release-7.4.0.md | 6 +- releases/release-7.5.1.md | 4 +- releases/release-8.4.0.md | 4 +- releases/release-8.5.0.md | 2 +- releases/release-8.5.1.md | 4 +- releases/release-8.5.4.md | 2 +- releases/versioning.md | 12 ++-- role-based-access-control.md | 2 +- runtime-filter.md | 4 +- scale-microservices-using-tiup.md | 4 +- scale-tidb-using-tiup.md | 8 +-- schedule-replicas-by-topology-labels.md | 8 +-- security-compatibility-with-mysql.md | 2 +- smooth-upgrade-tidb.md | 2 +- sql-plan-management.md | 6 +- sql-plan-replayer.md | 4 +- sql-prepared-plan-cache.md | 4 +- .../sql-statement-admin-cancel-ddl.md | 2 +- .../sql-statement-admin-checksum-table.md | 2 +- .../sql-statement-admin-pause-ddl.md | 4 +- .../sql-statement-admin-resume-ddl.md | 4 +- .../sql-statement-admin-show-ddl.md | 26 +++---- .../sql-statement-alter-sequence.md | 10 +-- .../sql-statement-alter-table-compact.md | 4 +- sql-statements/sql-statement-alter-table.md | 2 +- .../sql-statement-calibrate-resource.md | 2 +- .../sql-statement-create-sequence.md | 10 +-- sql-statements/sql-statement-create-view.md | 4 +- sql-statements/sql-statement-do.md | 4 +- sql-statements/sql-statement-drop-index.md | 2 +- .../sql-statement-explain-analyze.md | 8 +-- sql-statements/sql-statement-explain.md | 22 +++--- .../sql-statement-flashback-database.md | 2 +- .../sql-statement-flashback-table.md | 2 +- sql-statements/sql-statement-import-into.md | 2 +- ...statement-lock-tables-and-unlock-tables.md | 4 +- sql-statements/sql-statement-savepoint.md | 2 +- .../sql-statement-show-analyze-status.md | 2 +- sql-statements/sql-statement-truncate.md | 2 +- sql-tuning-best-practice.md | 10 +-- statement-summary-tables.md | 2 +- statistics.md | 10 +-- storage-engine/titan-configuration.md | 4 +- storage-engine/titan-overview.md | 4 +- sys-schema/sys-schema.md | 2 +- system-variables.md | 12 ++-- table-affinity.md | 4 +- table-attributes.md | 8 +-- ticdc/integrate-confluent-using-ticdc.md | 8 +-- ticdc/ticdc-alert-rules.md | 4 +- ticdc/ticdc-avro-protocol.md | 8 +-- ticdc/ticdc-bidirectional-replication.md | 4 +- ticdc/ticdc-canal-json.md | 8 +-- ticdc/ticdc-changefeed-overview.md | 2 +- ticdc/ticdc-csv.md | 2 +- ticdc/ticdc-data-replication-capabilities.md | 2 +- ticdc/ticdc-ddl.md | 2 +- ticdc/ticdc-debezium.md | 2 +- ticdc/ticdc-faq.md | 2 +- ticdc/ticdc-manage-changefeed.md | 6 +- ticdc/ticdc-open-api-v2.md | 24 +++---- ticdc/ticdc-open-api.md | 6 +- ticdc/ticdc-server-config.md | 2 +- ticdc/ticdc-simple-protocol.md | 4 +- ticdc/ticdc-sink-to-cloud-storage.md | 2 +- ticdc/ticdc-sink-to-kafka.md | 6 +- ticdc/ticdc-sink-to-pulsar.md | 2 +- ticdc/ticdc-split-update-behavior.md | 4 +- ticdc/troubleshoot-ticdc.md | 18 ++--- tidb-cloud/data-service-api-key.md | 2 +- tidb-cloud/data-service-app-config-files.md | 2 +- tidb-cloud/data-service-get-started.md | 2 +- tidb-cloud/data-service-manage-data-app.md | 2 +- tidb-cloud/migrate-from-op-tidb.md | 2 +- tidb-cloud/prometheus-grafana-integration.md | 2 +- ...fication-2023-09-26-console-maintenance.md | 4 +- tidb-cloud/releases/release-notes-2021.md | 2 +- tidb-cloud/releases/release-notes-2022.md | 2 +- tidb-cloud/releases/release-notes-2023.md | 2 +- tidb-cloud/releases/release-notes-2024.md | 2 +- tidb-cloud/releases/release-notes-2025.md | 2 +- tidb-cloud/serverless-export.md | 2 +- tidb-cloud/serverless-limitations.md | 6 +- ...s-private-link-connection-to-amazon-msk.md | 8 +-- ...ection-to-self-hosted-kafka-in-alicloud.md | 4 +- ...-connection-to-self-hosted-kafka-in-aws.md | 4 +- .../set-up-private-endpoint-connections.md | 2 +- tidb-cloud/set-up-vpc-peering-connections.md | 2 +- ...-self-hosted-kafka-private-link-service.md | 4 +- ...-self-hosted-kafka-private-link-service.md | 2 +- ...lf-hosted-kafka-private-service-connect.md | 6 +- tidb-cloud/sql-proxy-account.md | 2 +- tidb-cloud/terraform-use-cluster-resource.md | 10 +-- ...erraform-use-dedicated-cluster-resource.md | 6 +- ...se-dedicated-network-container-resource.md | 2 +- ...ed-private-endpoint-connection-resource.md | 2 +- ...form-use-dedicated-vpc-peering-resource.md | 2 +- tidb-cloud/terraform-use-import-resource.md | 2 +- ...erraform-use-serverless-branch-resource.md | 2 +- ...rless-cluster-resource-manage-essential.md | 6 +- ...rraform-use-serverless-cluster-resource.md | 6 +- ...erraform-use-serverless-export-resource.md | 6 +- tidb-cloud/terraform-use-sql-user-resource.md | 6 +- tidb-cloud/ticloud-cluster-create.md | 2 +- tidb-cloud/ticloud-import-start.md | 6 +- ...loud-serverless-audit-log-config-update.md | 6 +- tidb-cloud/tidb-cloud-encrypt-cmek-aws.md | 2 +- tidb-cloud/tidb-cloud-htap-quickstart.md | 4 +- tidb-cloud/tidb-cloud-poc.md | 12 ++-- tidb-cloud/tidb-node-group-management.md | 2 +- ...troubleshoot-import-access-denied-error.md | 2 +- tidb-cloud/use-chat2query-api.md | 10 +-- tidb-cloud/use-chat2query-knowledge.md | 2 +- tidb-cloud/use-chat2query-sessions.md | 2 +- ...-performance-benchmarking-with-sysbench.md | 2 +- ...v6.5-performance-benchmarking-with-tpcc.md | 2 +- ...-performance-benchmarking-with-sysbench.md | 2 +- ...v7.1-performance-benchmarking-with-tpcc.md | 2 +- ...-performance-benchmarking-with-sysbench.md | 2 +- ...v7.5-performance-benchmarking-with-tpcc.md | 2 +- ...-performance-benchmarking-with-sysbench.md | 2 +- ...v8.1-performance-benchmarking-with-tpcc.md | 2 +- ...-performance-benchmarking-with-sysbench.md | 2 +- ...v8.5-performance-benchmarking-with-tpcc.md | 2 +- tidb-cloud/v8.5-performance-highlights.md | 2 +- tidb-computing.md | 4 +- tidb-control.md | 6 +- tidb-external-ts.md | 2 +- tidb-global-sort.md | 6 +- .../import-into-vs-tidb-lightning.md | 6 +- tidb-lightning/monitor-tidb-lightning.md | 2 +- .../tidb-lightning-command-line-full.md | 2 +- .../tidb-lightning-configuration.md | 14 ++-- tidb-lightning/tidb-lightning-data-source.md | 4 +- .../tidb-lightning-distributed-import.md | 2 +- tidb-lightning/tidb-lightning-faq.md | 2 +- tidb-lightning/tidb-lightning-requirements.md | 2 +- tidb-lightning/troubleshoot-tidb-lightning.md | 6 +- tidb-read-staleness.md | 2 +- tidb-resource-control-runaway-queries.md | 8 +-- tidb-rowid.md | 2 +- tidb-scheduling.md | 2 +- tidb-troubleshooting-map.md | 2 +- tiflash-performance-tuning-methods.md | 2 +- tiflash/create-tiflash-replicas.md | 8 +-- tiflash/monitor-tiflash.md | 10 +-- tiflash/tiflash-alert-rules.md | 6 +- tiflash/tiflash-command-line-flags.md | 16 ++--- tiflash/tiflash-configuration.md | 20 +++--- tiflash/tiflash-overview.md | 2 +- tiflash/tiflash-results-materialization.md | 4 +- tiflash/troubleshoot-tiflash.md | 2 +- tiflash/tune-tiflash-performance.md | 20 +++--- tiflash/use-tidb-to-read-tiflash.md | 2 +- tiflash/use-tiflash-mpp-mode.md | 4 +- tikv-configuration-file.md | 4 +- tikv-control.md | 8 +-- time-to-live.md | 4 +- tiproxy/tiproxy-api.md | 2 +- tiproxy/tiproxy-configuration.md | 12 ++-- tiproxy/tiproxy-overview.md | 2 +- tiproxy/tiproxy-traffic-replay.md | 2 +- tiup/tiup-cluster-no-sudo-mode.md | 2 +- tiup/tiup-cluster-topology-reference.md | 10 +-- tiup/tiup-cluster.md | 4 +- tiup/tiup-command-env.md | 2 +- tiup/tiup-command-install.md | 2 +- tiup/tiup-command-list.md | 6 +- tiup/tiup-command-mirror-clone.md | 2 +- tiup/tiup-command-mirror-genkey.md | 4 +- tiup/tiup-command-mirror-grant.md | 2 +- tiup/tiup-command-mirror-publish.md | 2 +- tiup/tiup-command-mirror-set.md | 2 +- tiup/tiup-command-uninstall.md | 4 +- tiup/tiup-component-cluster-check.md | 2 +- tiup/tiup-component-cluster-clean.md | 2 +- tiup/tiup-component-cluster-deploy.md | 6 +- tiup/tiup-component-cluster-display.md | 4 +- tiup/tiup-component-cluster-edit-config.md | 2 +- tiup/tiup-component-cluster-help.md | 2 +- tiup/tiup-component-cluster-list.md | 2 +- tiup/tiup-component-cluster-reload.md | 28 ++++---- tiup/tiup-component-cluster-rename.md | 2 +- tiup/tiup-component-cluster-replay.md | 2 +- tiup/tiup-component-cluster-upgrade.md | 46 ++++++------ tiup/tiup-component-dm-display.md | 2 +- tiup/tiup-component-dm-edit-config.md | 2 +- tiup/tiup-component-dm-import.md | 4 +- tiup/tiup-component-dm-list.md | 2 +- tiup/tiup-component-dm-patch.md | 2 +- tiup/tiup-component-dm-replay.md | 2 +- tiup/tiup-component-dm-scale-out.md | 2 +- tiup/tiup-component-management.md | 6 +- tiup/tiup-dm-topology-reference.md | 12 ++-- tiup/tiup-overview.md | 2 +- tiup/tiup-playground.md | 2 +- tiup/tiup-reference.md | 6 +- tiup/tiup-troubleshooting-guide.md | 8 +-- transaction-isolation-levels.md | 2 +- transaction-overview.md | 2 +- troubleshoot-cpu-issues.md | 8 +-- troubleshoot-high-disk-io.md | 6 +- troubleshoot-hot-spot-issues.md | 6 +- troubleshoot-lock-conflicts.md | 2 +- troubleshoot-tidb-cluster.md | 2 +- troubleshoot-write-conflicts.md | 14 ++-- tune-operating-system.md | 2 +- tune-tikv-memory-performance.md | 2 +- tune-tikv-thread-performance.md | 2 +- upgrade-monitoring-services.md | 4 +- upgrade-tidb-using-tiup.md | 2 +- user-account-management.md | 2 +- wrong-index-solution.md | 2 +- 433 files changed, 1071 insertions(+), 1071 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f11775cfcf50c..66421e649ac7a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -121,7 +121,7 @@ TiDB 用の新しいドキュメントを作成する場合は、当社のスタ ### ステップ8: プルリクエストを作成する {#step-8-create-a-pull-request} 1. [https://github.com/$user/docs](https://github.com/$user/docs)でフォークにアクセスします ( `$user` GitHub ID に置き換えます) -2. `new-branch-name`ブランチの横にある`Compare & pull request`ボタンをクリックして PR を作成します。5 [プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style)参照してください。 +2. `new-branch-name`ブランチの横にある`Compare & pull request`ボタンをクリックして PR を作成します。詳細は[プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style)を参照してください。 これで、PR が正常に送信されました。この PR がマージされると、自動的に TiDB ドキュメントの貢献者になります。 diff --git a/agg-distinct-optimization.md b/agg-distinct-optimization.md index 5380aec6c3752..1a66387a25401 100644 --- a/agg-distinct-optimization.md +++ b/agg-distinct-optimization.md @@ -39,7 +39,7 @@ TiDB の[`tidb_opt_distinct_agg_push_down`](/system-variables.md#tidb_opt_distin -この最適化の例として、以下のクエリを見てみましょう。1 `tidb_opt_distinct_agg_push_down`デフォルトで無効になっており、集計関数はTiDBレイヤーで実行されます。この最適化を有効にするために値を`1`に設定すると、 `count(distinct a)`の`distinct a`部分が TiKV またはTiFlashコプロセッサーにプッシュされます。TiKVコプロセッサーには、列 a の重複値を削除する HashAgg_5 があります。これにより、TiDBレイヤーにおける`HashAgg_8`の計算オーバーヘッドが削減される可能性があります。 +この最適化の例として、以下のクエリを見てみましょう。`tidb_opt_distinct_agg_push_down`デフォルトで無効になっており、集計関数はTiDBレイヤーで実行されます。この最適化を有効にするために値を`1`に設定すると、 `count(distinct a)`の`distinct a`部分が TiKV またはTiFlashコプロセッサーにプッシュされます。TiKVコプロセッサーには、列 a の重複値を削除する HashAgg_5 があります。これにより、TiDBレイヤーにおける`HashAgg_8`の計算オーバーヘッドが削減される可能性があります。 ```sql mysql> desc select count(distinct a) from test.t; diff --git a/ai/guides/image-search.md b/ai/guides/image-search.md index f0e2a5a36128b..91773b75c3b40 100644 --- a/ai/guides/image-search.md +++ b/ai/guides/image-search.md @@ -36,7 +36,7 @@ image_embed = EmbeddingFunction( ### ステップ2. テーブルとベクトルフィールドを作成する {#step-2-create-a-table-and-vector-field} -`VectorField()`画像の埋め込みを格納するためのベクトルフィールドを定義します。3 `source_field`画像のURLを格納するフィールドを指定するためのパラメータです。 +`VectorField()`画像の埋め込みを格納するためのベクトルフィールドを定義します。`source_field`画像のURLを格納するフィールドを指定するためのパラメータです。 ```python from pytidb.schema import TableModel, Field diff --git a/ai/guides/vector-search.md b/ai/guides/vector-search.md index 144601ef6fa77..de249762385f1 100644 --- a/ai/guides/vector-search.md +++ b/ai/guides/vector-search.md @@ -323,7 +323,7 @@ results = ( > **Note:** > -> ベクトルインデックスを使用する場合、最後の`limit`が非常に小さいと結果の精度が低下する可能性があります。3 `.num_candidate()`の方法を使用すると、ベクトル検索フェーズでベクトルインデックスから取得する候補の数を、 `limit`番目のパラメータを変更せずに制御できます。 +> ベクトルインデックスを使用する場合、最後の`limit`が非常に小さいと結果の精度が低下する可能性があります。`.num_candidate()`の方法を使用すると、ベクトル検索フェーズでベクトルインデックスから取得する候補の数を、 `limit`番目のパラメータを変更せずに制御できます。 > `num_candidate`値を大きくすると、一般的に再現率は向上しますが、クエリのパフォーマンスが低下する可能性があります。データセットと精度要件に応じてこの値を調整してください。 diff --git a/ai/reference/vector-search-data-types.md b/ai/reference/vector-search-data-types.md index dc43bf22635b8..22fb9d110e7f6 100644 --- a/ai/reference/vector-search-data-types.md +++ b/ai/reference/vector-search-data-types.md @@ -212,7 +212,7 @@ Vector と String 間のキャストを行うには、次の関数を使用し 1 row in set (0.01 sec) ``` -ベクトルを明示的に文字列表現にキャストすることもできます。1関数`VEC_AS_TEXT()`例に挙げましょう。 +ベクトルを明示的に文字列表現にキャストすることもできます。`VEC_AS_TEXT()`関数の使用を例に挙げましょう。 ```sql -- The string is first implicitly cast to a vector, and then the vector is explicitly cast to a string, thus returning a string in the normalized format: diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md index d85170f30e6aa..ce2756d4cb5a9 100644 --- a/ai/reference/vector-search-index.md +++ b/ai/reference/vector-search-index.md @@ -130,7 +130,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES; +---------------+------------+----------+-------------+---------------+-----------+----------+------------+---------------------+-------------------------+--------------------+------------------------+---------------+------------------+ ``` -- インデックス構築の進行状況は、 `ROWS_STABLE_INDEXED`と`ROWS_STABLE_NOT_INDEXED`列で確認できます。5 `ROWS_STABLE_NOT_INDEXED` 0になると、インデックス構築が完了します。 +- インデックス構築の進行状況は、 `ROWS_STABLE_INDEXED`と`ROWS_STABLE_NOT_INDEXED`列で確認できます。`ROWS_STABLE_NOT_INDEXED` 0になると、インデックス構築が完了します。 参考までに、768次元の500MiBベクトルデータセットのインデックス作成には最大20分かかる場合があります。インデクサーは複数のテーブルに対して並列実行できます。現在、インデクサーの優先度や速度の調整はサポートされていません。 @@ -148,7 +148,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES; ## ベクトルインデックスが使用されているかどうかを確認する {#check-whether-the-vector-index-is-used} -クエリがベクトルインデックスを使用しているかどうかを確認するには、 [`EXPLAIN`](/sql-statements/sql-statement-explain.md)または[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)ステートメントを使用します。9 `TableFullScan`キュータの`operator info`列に`annIndex:`表示されている場合、このテーブルスキャンはベクトルインデックスを使用していることを意味します。 +クエリがベクトルインデックスを使用しているかどうかを確認するには、 [`EXPLAIN`](/sql-statements/sql-statement-explain.md)または[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)ステートメントを使用します。`TableFullScan`エグゼキュータの`operator info`列に`annIndex:`が表示されている場合、このテーブルスキャンはベクトルインデックスを使用していることを意味します。 **例: ベクトルインデックスが使用される** diff --git a/alert-rules.md b/alert-rules.md index 3b736b346f521..907536c61733d 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -406,7 +406,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 説明： - 低速TiKVノードがあります。1 `raftstore.inspect-interval` TiKV低速ノードの検出を制御します。詳細については[`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)参照してください。 + 低速TiKVノードがあります。`raftstore.inspect-interval` TiKV低速ノードの検出を制御します。詳細については[`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)を参照してください。 - 解決： @@ -467,7 +467,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. ネットワークがクリアかどうかを確認してください。 2. リモート TiKV がダウンしていないかどうかを確認します。 - 3. リモートTiKVがダウンしていない場合は、圧力が高すぎないか確認してください。1の解決策を参照してください[`TiKV_channel_full_total`](#tikv_channel_full_total) + 3. リモートTiKVがダウンしていない場合は、圧力が高すぎないか確認してください。[`TiKV_channel_full_total`](#tikv_channel_full_total)の解決策を参照してください。 #### `TiKV_channel_full_total` {#tikv-channel-full-total} @@ -555,7 +555,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. TiDB ログからスロー クエリ ログを確認し、クエリでインデックスまたは完全なテーブル スキャンが使用されているかどうか、または分析に必要かどうかを確認します。 2. ホットスポットがあるかどうかを確認します。 - 3. コプロセッサーモニターで、 `coprocessor table/index scan`の`total`と`process`一致しているかどうかを確認してください。大きく異なる場合は、無効なクエリが多すぎることを示しています。7 `over seek bound`あるかどうかも確認できます。もしそうであれば、GC が時間内に処理できないバージョンが多すぎます。その場合は、並列 GC スレッドの数を増やす必要があります。 + 3. コプロセッサーモニターで、 `coprocessor table/index scan`の`total`と`process`一致しているかどうかを確認してください。大きく異なる場合は、無効なクエリが多すぎることを示しています。`over seek bound`あるかどうかも確認できます。もしそうであれば、GC が時間内に処理できないバージョンが多すぎます。その場合は、並列 GC スレッドの数を増やす必要があります。 #### `TiKV_raftstore_thread_cpu_seconds_total` {#tikv-raftstore-thread-cpu-seconds-total} @@ -567,7 +567,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま このルールは、 Raftstoreによる CPU 使用率を監視します。値が高い場合、 Raftstoreスレッドへの負荷が高いことを示します。 - アラートしきい値は[`raftstore.store-pool-size`](/tikv-configuration-file.md#store-pool-size)値の 80% です。3 `raftstore.store-pool-size`デフォルトで 2 なので、アラートしきい値は 1.6 になります。 + アラートしきい値は[`raftstore.store-pool-size`](/tikv-configuration-file.md#store-pool-size)値の 80% です。`raftstore.store-pool-size`デフォルトで 2 なので、アラートしきい値は 1.6 になります。 - 解決： diff --git a/analyze-slow-queries.md b/analyze-slow-queries.md index 2d39a6a325cdf..74d96b9c1374b 100644 --- a/analyze-slow-queries.md +++ b/analyze-slow-queries.md @@ -59,7 +59,7 @@ summary: スロークエリを見つけて分析する方法を学びます。 ### TiKVはデータ処理が遅い {#tikv-is-slow-in-data-processing} -TiKVによるデータ処理が遅い場合、 `EXPLAIN ANALYZE`の結果から簡単に特定できます。次の例では、 `StreamAgg_8`と`TableFullScan_15` 、つまり2つの`tikv-task`秒（ `task`列の`cop[tikv]`で示される）の実行に`170ms`かかります。15 `170ms`差し引くと、TiDB演算子の実行時間は全体の実行時間に占める割合が非常に小さくなります。これは、ボトルネックがTiKVにあることを示しています。 +TiKVによるデータ処理が遅い場合、 `EXPLAIN ANALYZE`の結果から簡単に特定できます。次の例では、 `StreamAgg_8`と`TableFullScan_15` 、つまり2つの`tikv-task`秒（ `task`列の`cop[tikv]`で示される）の実行に`170ms`かかります。`170ms`を差し引くと、TiDB演算子の実行時間は全体の実行時間に占める割合が非常に小さくなります。これは、ボトルネックがTiKVにあることを示しています。 ```sql +----------------------------+---------+---------+-----------+---------------+------------------------------------------------------------------------------+---------------------------------+-----------+------+ diff --git a/as-of-timestamp.md b/as-of-timestamp.md index 135eb7059d303..0a5c177fe05d5 100644 --- a/as-of-timestamp.md +++ b/as-of-timestamp.md @@ -21,9 +21,9 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標 - [`START TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-start-transaction.md) - [`SET TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-set-transaction.md) -正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには「2016-10-08 16:45:26」のように秒単位で十分です。3 関数を使用して、現在時刻を`NOW(3)`秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。 +正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには「2016-10-08 16:45:26」のように秒単位で十分です。`NOW(3)`関数を使用して、現在時刻をミリ秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。 -時間範囲を指定する場合は、句内で[`TIDB_BOUNDED_STALENESS()`](/functions-and-operators/tidb-functions.md#tidb_bounded_staleness)関数を使用できます。この関数を使用すると、TiDB は指定された時間範囲内で適切なタイムスタンプを選択します。「適切」とは、このタイムスタンプより前に開始され、アクセス先のレプリカにコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセス先のレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされていないことを意味します。この関数を呼び出すには`TIDB_BOUNDED_STALENESS(t1, t2)`使用する必要があります。5 と`t2` `t1`範囲の両端であり、datetime 値または時間関数を使用して指定できます。 +時間範囲を指定する場合は、句内で[`TIDB_BOUNDED_STALENESS()`](/functions-and-operators/tidb-functions.md#tidb_bounded_staleness)関数を使用できます。この関数を使用すると、TiDB は指定された時間範囲内で適切なタイムスタンプを選択します。「適切」とは、このタイムスタンプより前に開始され、アクセス先のレプリカにコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセス先のレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされていないことを意味します。この関数を呼び出すには`TIDB_BOUNDED_STALENESS(t1, t2)`を使用する必要があります。`t1`と`t2`は範囲の両端であり、datetime 値または時間関数を使用して指定できます。 `AS OF TIMESTAMP`句の例をいくつか示します。 diff --git a/auto-increment.md b/auto-increment.md index 16ac74a383500..85d2f2067ca83 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -27,7 +27,7 @@ summary: TiDB の AUTO_INCREMENT` 列属性について学習します。 ## コンセプト {#concept} -`AUTO_INCREMENT` 、デフォルトの列値を自動的に入力するために使用される列属性です。2 `INSERT`ステートメントで`AUTO_INCREMENT`番目の列の値が指定されていない場合、システムは自動的にこの列に値を割り当てます。 +`AUTO_INCREMENT` 、デフォルトの列値を自動的に入力するために使用される列属性です。`INSERT`ステートメントで`AUTO_INCREMENT`番目の列の値が指定されていない場合、システムは自動的にこの列に値を割り当てます。 パフォーマンス上の理由から、各TiDBサーバーには、 `AUTO_INCREMENT`個の数値が一括で割り当てられます（デフォルトでは3万個）。つまり、 `AUTO_INCREMENT`数値は一意であることが保証されますが、 `INSERT`ステートメントに割り当てられる値は、TiDBサーバーごとに単調なものになります。 @@ -94,7 +94,7 @@ TiDB は`AUTO_INCREMENT`暗黙的な割り当てを次のように実装しま CREATE TABLE t(id int UNIQUE KEY AUTO_INCREMENT, c int); ``` -クラスター内に2つのTiDBインスタンス（ `A`と`B`があるとします。7テーブルに対してそれぞれ`t`と`B` `A` `INSERT`ステートメントを実行すると、次のようになります。 +クラスター内に2つのTiDBインスタンス（ `A`と`B` ）があるとします。`A`と`B`でそれぞれ`t`テーブルに対して`INSERT`ステートメントを実行すると、次のようになります。 ```sql INSERT INTO t (c) VALUES (1) diff --git a/auto-random.md b/auto-random.md index e44184f606411..c30684ff43975 100644 --- a/auto-random.md +++ b/auto-random.md @@ -177,7 +177,7 @@ TiDBインスタンスが1つの場合、ノードは明示的な挿入を処理 ALTER TABLE t AUTO_RANDOM_BASE=0; ``` -このステートメントは適切な基数を自動的に決定します。1 `Can't reset AUTO_INCREMENT to 0 without FORCE option, using XXX instead`ような警告メッセージが表示されますが、基数は変更さ**れる**ため、この警告は無視しても問題ありません。 +このステートメントは適切な基数を自動的に決定します。`Can't reset AUTO_INCREMENT to 0 without FORCE option, using XXX instead`ような警告メッセージが表示されますが、基数は変更さ**れる**ため、この警告は無視しても問題ありません。 > **Note:** > diff --git a/benchmark/benchmark-tidb-using-ch.md b/benchmark/benchmark-tidb-using-ch.md index f1cc155bef27b..96dbfcec8b9f9 100644 --- a/benchmark/benchmark-tidb-using-ch.md +++ b/benchmark/benchmark-tidb-using-ch.md @@ -58,11 +58,11 @@ tiup bench ch -H 172.16.5.140 -P 4000 -D tpcc prepare ## TiFlashレプリカを作成する {#create-tiflash-replicas} -TiFlashをデプロイした後、 TiFlash はTiKV データを自動的に複製しません。1 `tpcc`のTiFlashレプリカを作成するには、次の SQL 文を実行する必要があります。指定されたTiFlashレプリカが作成されると、TiKV は最新のデータをリアルタイムでTiFlashに自動的に複製します。次の例では、クラスターに 2 つのTiFlashノードをデプロイし、レプリカ数を 2 に設定しています。 +TiFlashをデプロイした後、 TiFlash はTiKV データを自動的に複製しません。`tpcc`のTiFlashレプリカを作成するには、次の SQL 文を実行する必要があります。指定されたTiFlashレプリカが作成されると、TiKV は最新のデータをリアルタイムでTiFlashに自動的に複製します。次の例では、クラスターに 2 つのTiFlashノードをデプロイし、レプリカ数を 2 に設定しています。 ALTER DATABASE tpcc SET tiflash replica 2; -`tpcc`データベース内のすべてのテーブルのレプリケーションが完了しているかどうかを確認するには、次のステートメントを実行します。3 句は、確認するデータベースとテーブルを指定します。すべてのデータベースのレプリケーション状態を確認する場合は、ステートメントから`WHERE`句`WHERE`削除します。 +`tpcc`データベース内のすべてのテーブルのレプリケーションが完了しているかどうかを確認するには、次のステートメントを実行します。`WHERE`句は、確認するデータベースとテーブルを指定します。すべてのデータベースのレプリケーション状態を確認する場合は、ステートメントから`WHERE`句を削除します。 ```sql SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'tpcc'; @@ -70,8 +70,8 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'tpcc'; 上記のステートメントの結果は次のようになります。 -- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。2 `1`利用可能、 `0`利用不可を意味します。レプリカが利用可能になると、このステータスは変更されません。 -- `PROGRESS`レプリケーションの進行状況を示します。値は`0`から`1`までです。6 `1` TiFlashレプリカのレプリケーションが完了したことを意味します。 +- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。`1`利用可能、 `0`利用不可を意味します。レプリカが利用可能になると、このステータスは変更されません。 +- `PROGRESS`レプリケーションの進行状況を示します。値は`0`から`1`までです。`1` TiFlashレプリカのレプリケーションが完了したことを意味します。 ## 統計を収集する {#collect-statistics} diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 46ec6f22032f0..9cb4ff24587c0 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -75,7 +75,7 @@ report-interval=10 db-driver=mysql ``` -上記のパラメータは、実際のニーズに合わせて調整できます。1 `TIDB_HOST` TiDBサーバーのIPアドレス（設定ファイルに複数のアドレスを含めることはできないため）、 `threads`テストにおける同時接続数で、「8、16、32、64、128、256」の範囲で調整できます。データをインポートする際は、threads = 8または16に設定することをお勧めします`threads`を調整したら、 **config**というファイルを保存します。 +上記のパラメータは、実際のニーズに合わせて調整できます。`TIDB_HOST` TiDBサーバーのIPアドレス（設定ファイルに複数のアドレスを含めることはできないため）、 `threads`テストにおける同時接続数で、「8、16、32、64、128、256」の範囲で調整できます。データをインポートする際は、threads = 8または16に設定することをお勧めします`threads`を調整したら、 **config**というファイルを保存します。 サンプル**設定**ファイルとして以下を参照してください。 diff --git a/benchmark/online-workloads-and-add-index-operations.md b/benchmark/online-workloads-and-add-index-operations.md index ff17cb1a4a9b7..66f1f1f4ce19d 100644 --- a/benchmark/online-workloads-and-add-index-operations.md +++ b/benchmark/online-workloads-and-add-index-operations.md @@ -82,7 +82,7 @@ sysbench $testname \ ## テストプラン1: ADD INDEX文の対象列への書き込み操作を頻繁に実行する {#test-plan-1-frequently-perform-write-operations-to-the-target-column-of-the-code-add-index-code-statement} 1. `oltp_read_write`テストを開始します。 -2. 手順`alter table sbtest1 add index c_idx(c)`と同時に実行します。1 を使用してインデックスを追加します。 +2. 手順 1 と同時に実行します。`alter table sbtest1 add index c_idx(c)`を使用してインデックスを追加します。 3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_write`を停止します。 4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 @@ -217,7 +217,7 @@ sysbench $testname \ ## テストプラン 2: ADD INDEXステートメントのターゲット列への書き込み操作を実行しない (クエリのみ) {#test-plan-2-do-not-perform-write-operations-to-the-target-column-of-the-code-add-index-code-statement-query-only} 1. `oltp_read_only`テストを開始します。 -2. 手順`alter table sbtest1 add index c_idx(c)`と同時に実行します。1 を使用してインデックスを追加します。 +2. 手順 1 と同時に実行します。`alter table sbtest1 add index c_idx(c)`を使用してインデックスを追加します。 3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_only`を停止します。 4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 @@ -279,7 +279,7 @@ sysbench $testname \ ## テストプラン3: ADD INDEX文のターゲット列はオンラインワークロードとは無関係です {#test-plan-3-the-target-column-of-the-code-add-index-code-statement-is-irrelevant-to-online-workloads} 1. `oltp_read_write`テストを開始します。 -2. 手順`alter table test add index pad_idx(pad)`と同時に実行します。1 を使用してインデックスを追加します。 +2. 手順 1 と同時に実行します。`alter table test add index pad_idx(pad)`を使用してインデックスを追加します。 3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_only`を停止します。 4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index ac6eea311de1e..27eaaf6146423 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -161,7 +161,7 @@ TiDB v6.2.0以降、単一の`ALTER`文でテーブル内の複数のスキー ### 読み取りと書き込みのパフォーマンスを確認する {#check-the-read-and-write-performance} -TiDBがインデックスを追加する際、データのバックフィルフェーズによってクラスターの読み取りと書き込みに負荷がかかります。1 `ADD INDEX`のコマンドが送信され、 `write reorg`番目のフェーズが開始されたら、GrafanaダッシュボードでTiDBとTiKVの読み取りと書き込みのパフォーマンスメトリックとアプリケーションの応答時間を確認し、 `ADD INDEX`操作がクラスターに影響を与えているかどうかを確認することをお勧めします。 +TiDBがインデックスを追加する際、データのバックフィルフェーズによってクラスターの読み取りと書き込みに負荷がかかります。`ADD INDEX`のコマンドが送信され、 `write reorg`番目のフェーズが開始されたら、GrafanaダッシュボードでTiDBとTiKVの読み取りと書き込みのパフォーマンスメトリックとアプリケーションの応答時間を確認し、 `ADD INDEX`操作がクラスターに影響を与えているかどうかを確認することをお勧めします。 ## DDL関連コマンド {#ddl-related-commands} diff --git a/best-practices/grafana-monitor-best-practices.md b/best-practices/grafana-monitor-best-practices.md index 51a9323935c03..edfdb9cd51c0b 100644 --- a/best-practices/grafana-monitor-best-practices.md +++ b/best-practices/grafana-monitor-best-practices.md @@ -10,7 +10,7 @@ aliases: ['/ja/docs/dev/best-practices/grafana-monitor-best-practices/','/ja/doc ## 監視アーキテクチャ {#monitoring-architecture} -[Prometheus](https://prometheus.io/)は、多次元データ モデルと柔軟なクエリ言語を備えた時系列データベースです。2 [Grafana](https://grafana.com/) 、メトリックを分析および視覚化するためのオープン ソースの監視システムです。 +[Prometheus](https://prometheus.io/)は、多次元データ モデルと柔軟なクエリ言語を備えた時系列データベースです。[Grafana](https://grafana.com/)は、メトリックを分析および視覚化するためのオープン ソースの監視システムです。 ![The monitoring architecture in the TiDB cluster](/media/prometheus-in-tidb.png) diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md index 494bae9aea1c6..60531f2500cb2 100644 --- a/best-practices/high-concurrency-best-practices.md +++ b/best-practices/high-concurrency-best-practices.md @@ -60,7 +60,7 @@ CREATE TABLE IF NOT EXISTS TEST_HOTSPOT( ) ``` -このテーブルは構造が単純です。主キーの`id`以外に、セカンダリインデックスは存在しません。このテーブルにデータを書き込むには、次のステートメントを実行してください。3 `id`乱数として離散的に生成されます。 +このテーブルは構造が単純です。主キーの`id`以外に、セカンダリインデックスは存在しません。このテーブルにデータを書き込むには、次のステートメントを実行してください。`id`乱数として離散的に生成されます。 ```sql SET SESSION cte_max_recursion_depth = 1000000; @@ -92,7 +92,7 @@ FROM ![QPS1](/media/best-practices/QPS1.png) -クライアントは短時間で「集中的な」書き込みリクエストを開始し、TiDBは3K QPSの書き込みを受信しました。理論上、負荷は6つのTiKVノードに均等に分散されるはずです。しかし、各TiKVノードのCPU使用率から判断すると、負荷分散は不均一です。1 `tikv-3`ノードが書き込みのホットスポットとなっています。 +クライアントは短時間で「集中的な」書き込みリクエストを開始し、TiDBは3K QPSの書き込みを受信しました。理論上、負荷は6つのTiKVノードに均等に分散されるはずです。しかし、各TiKVノードのCPU使用率から判断すると、負荷分散は不均一です。`tikv-3`ノードが書き込みのホットスポットとなっています。 ![QPS2](/media/best-practices/QPS2.png) @@ -156,9 +156,9 @@ TiDBは汎用的な用途向けのデータベースであり、データ分布 SPLIT TABLE TEST_HOTSPOT BETWEEN (0) AND (9223372036854775807) REGIONS 128; ``` -事前分割操作の後、 `SHOW TABLE test_hotspot REGIONS;`のステートメントを実行して、 リージョン scattering の状態を確認します。3 `SCATTERING`の列の値がすべて`0`であれば、スケジューリングは成功です。 +事前分割操作の後、 `SHOW TABLE test_hotspot REGIONS;`のステートメントを実行して、 リージョン scattering の状態を確認します。`SCATTERING`の列の値がすべて`0`であれば、スケジューリングは成功です。 -次のSQL文を使用して、リージョンリーダーの分布を確認することもできます。1 `table_name`実際のテーブル名に置き換えてください。 +次のSQL文を使用して、リージョンリーダーの分布を確認することもできます。`table_name`実際のテーブル名に置き換えてください。 ```sql SELECT @@ -196,7 +196,7 @@ ORDER BY このような状況でホットスポット問題を回避するには、テーブル作成時に`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` 、テーブルの作成後にリージョンを事前に分割するために使用されます。 +`SHARD_ROW_ID_BITS` 、 `_tidb_rowid`列に生成された行 ID をランダムに散布するために使用されます。`PRE_SPLIT_REGIONS` 、テーブルの作成後にリージョンを事前に分割するために使用されます。 > **Note:** > diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index b52410574ac9d..b5d478686ac96 100644 --- a/best-practices/index-management-best-practices.md +++ b/best-practices/index-management-best-practices.md @@ -302,7 +302,7 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; - フィルタリングの効率を向上させるために列を追加します。 - インデックス構造の変更 (プレフィックス インデックス、複合インデックスなど)。 - - インデックスの選択性を分析します。3 `TIDB_INDEX_USAGE`フィールドのうち`PERCENTAGE_ACCESS_*`使用して、インデックスがデータをどの程度適切にフィルタリングしているかを評価します。 + - インデックスの選択性を分析します。`TIDB_INDEX_USAGE`フィールドのうち`PERCENTAGE_ACCESS_*`を使用して、インデックスがデータをどの程度適切にフィルタリングしているかを評価します。 4. **DML パフォーマンスへの影響に注意してください。** diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md index 341868db839a4..aee058aa3e467 100644 --- a/best-practices/massive-regions-best-practices.md +++ b/best-practices/massive-regions-best-practices.md @@ -88,7 +88,7 @@ TiKVでは、デフォルトで`raftstore.store-pool-size`から`2`に設定さ > > TiDB v3.0 以降では`Region Merge`がデフォルトで有効になっています。 -`Region Merge`有効にすることで、Regionの数を減らすこともできます。3 `Region Split`は異なり、 `Region Merge`スケジュール設定によって隣接する小さなRegionを結合するプロセスです。データを削除した後、または`Drop Table`もしくは`Truncate Table`ステートメントを実行した後、小さなRegion、あるいは空のRegionを結合することで、リソース消費を削減できます。 +`Region Merge`有効にすることで、Regionの数を減らすこともできます。`Region Split`は異なり、 `Region Merge`スケジュール設定によって隣接する小さなRegionを結合するプロセスです。データを削除した後、または`Drop Table`もしくは`Truncate Table`ステートメントを実行した後、小さなRegion、あるいは空のRegionを結合することで、リソース消費を削減できます。 次のパラメータを設定して`Region Merge`有効にします。 @@ -102,7 +102,7 @@ TiKVでは、デフォルトで`raftstore.store-pool-size`から`2`に設定さ - [`max-merge-region-keys`](/pd-configuration-file.md#max-merge-region-keys) - [`merge-schedule-limit`](/pd-configuration-file.md#merge-schedule-limit) -`Region Merge`パラメータのデフォルト設定はかなり保守的です。5 [PDスケジュールのベストプラクティス](/best-practices/pd-scheduling-best-practices.md#region-merge-is-slow)記載されている方法を参考にすれば、 `Region Merge`プロセスを高速化できます。 +`Region Merge`パラメータのデフォルト設定はかなり保守的です。[PDスケジュールのベストプラクティス](/best-practices/pd-scheduling-best-practices.md#region-merge-is-slow)に記載されている方法を参考にすれば、 `Region Merge`プロセスを高速化できます。 ### 方法4: TiKVインスタンスの数を増やす {#method-4-increase-the-number-of-tikv-instances} @@ -122,7 +122,7 @@ I/O リソースと CPU リソースが十分な場合は、単一のマシン raft-election-timeout = raft-base-tick-interval * raft-election-timeout-ticks raft-heartbeat-interval = raft-base-tick-interval * raft-heartbeat-ticks -リージョンフォロワーが`raft-election-timeout`間隔以内にリーダーからのハートビートを受信しなかった場合、これらのフォロワーはリーダーが故障したと判断し、新たな選出を開始します。3 `raft-heartbeat-interval` 、リーダーがフォロワーにハートビートを送信する間隔です。したがって、この値を`raft-base-tick-interval`に増やすと、 Raftステートマシンから送信されるネットワークメッセージの数は減りますが、 Raftステートマシンがリーダーの故障を検出するまでの時間が長くなります。 +リージョンフォロワーが`raft-election-timeout`間隔以内にリーダーからのハートビートを受信しなかった場合、これらのフォロワーはリーダーが故障したと判断し、新たな選出を開始します。`raft-heartbeat-interval` 、リーダーがフォロワーにハートビートを送信する間隔です。したがって、この値を`raft-base-tick-interval`に増やすと、 Raftステートマシンから送信されるネットワークメッセージの数は減りますが、 Raftステートマシンがリーダーの故障を検出するまでの時間が長くなります。 ### 方法6:リージョンのサイズを調整する {#method-6-adjust-region-size} diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 247e9544b4434..820f3d41ce223 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -56,7 +56,7 @@ EXPLAIN FORMAT = "brief" SELECT * FROM listings WHERE price < 2000; CREATE INDEX idx_city_bedrooms_price ON listings (city, bedrooms, price); ``` -SQLの複数列インデックスは辞書式順序で並べられます。1 `(city, bedrooms, price)`インデックスの場合、データはまず`city`でソートされ、次に各都市内で`bedrooms`でソートされ、最後に各`(city, bedrooms)`組み合わせ内で`price`でソートされます。この順序付けにより、TiDBは各条件に基づいて効率的に行にアクセスできます。 +SQLの複数列インデックスは辞書式順序で並べられます。`(city, bedrooms, price)`インデックスの場合、データはまず`city`でソートされ、次に各都市内で`bedrooms`でソートされ、最後に各`(city, bedrooms)`組み合わせ内で`price`でソートされます。この順序付けにより、TiDBは各条件に基づいて効率的に行にアクセスできます。 1. プライマリフィルターである`city`でフィルターします。 2. オプションで、その都市内で`bedrooms`でフィルタリングします。 @@ -223,8 +223,8 @@ CREATE TABLE t1 ( TiDBオプティマイザは条件を分解した後、各部分の範囲を計算し、それらを結合します。この例では、次のように導出されます。 - - `(a1, b1) > (1, 10)`場合: `a1 > 1`の場合は 3 、 `a1 = 1`および`b1 > 10`の場合は`(1, +inf]` `(1, 10, 1, +inf]`の範囲を作成します。 - - `(a1, b1) < (10, 20)`の場合: `a1 < 10`と`[10, -inf, 10, 20)`の場合は範囲`[-inf, 10)`を作成し、 `a1 = 10`と`b1 < 20`の場合は範囲​​ 7 を作成します。 + - `(a1, b1) > (1, 10)`の場合: `a1 > 1`の場合は範囲`(1, +inf]`を作成し、 `a1 = 1`および`b1 > 10`の場合は`(1, 10, 1, +inf]`を作成します。 + - `(a1, b1) < (10, 20)`の場合: `a1 < 10`の場合は範囲`[-inf, 10)`を作成し、 `a1 = 10`と`b1 < 20`の場合は範囲`[10, -inf, 10, 20)`を作成します。 最終結果では、これらを組み合わせて、洗練された範囲`(1, 10, 1, +inf] UNION (1, 10) UNION [10, -inf, 10, 20)`得られます。 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index c05ad675ed769..6364d71498c26 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -68,17 +68,17 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ 1. リソースの可用性に応じてストアを評価します。 2. `balance-leader`または`balance-region` 、高スコアのストアから低スコアのストアへ、リーダーまたはピアを継続的に異動させます。 -しかし、評価方法は異なります。1 `balance-leader`ストア内のリーダーに対応するすべてのリージョンサイズの合計を使用しますが、 `balance-region`の方法は比較的複雑です。各ノードの具体的なストレージ容量に応じて、 `balance-region`の評価方法は以下のようになります。 +しかし、評価方法は異なります。`balance-leader`ストア内のリーダーに対応するすべてのリージョンサイズの合計を使用しますが、 `balance-region`の方法は比較的複雑です。各ノードの具体的なストレージ容量に応じて、 `balance-region`の評価方法は以下のようになります。 - 十分なストレージがある場合のデータ量に基づいて（ノード間でデータ分散のバランスをとるため）。 - ストレージが不足している場合は、使用可能なストレージに基づいて割り当てます (異なるノード上のストレージの可用性のバランスをとるため)。 - どちらの状況も当てはまらない場合は、上記の 2 つの要素の加重合計に基づきます。 -ノードによってパフォーマンスが異なる場合があるため、ストアごとにロードバランシングの重みを設定することもできます。1と`region-weight` `leader-weight`それぞれリーダー重みとリージョン重みを制御します（どちらもデフォルトは「1」です）。例えば、あるストアの`leader-weight` 「2」に設定すると、スケジューリングが安定した後、そのノードのリーダー数は他のノードの約2倍になります。同様に、あるストアの`leader-weight` 「0.5」に設定すると、そのノードのリーダー数は他のノードの約半分になります。 +ノードによってパフォーマンスが異なる場合があるため、ストアごとにロードバランシングの重みを設定することもできます。`leader-weight`と`region-weight`は、それぞれリーダー重みとリージョン重みを制御します（どちらもデフォルトは「1」です）。例えば、あるストアの`leader-weight`を「2」に設定すると、スケジューリングが安定した後、そのノードのリーダー数は他のノードの約2倍になります。同様に、あるストアの`leader-weight`を「0.5」に設定すると、そのノードのリーダー数は他のノードの約半分になります。 ### ホットリージョンのスケジュール {#hot-regions-scheduling} -ホットリージョンのスケジューリングには`hot-region-scheduler`使用します。TiDB v3.0以降では、このプロセスは次のように実行されます。 +ホットリージョンのスケジューリングには`hot-region-scheduler`を使用します。TiDB v3.0以降では、このプロセスは次のように実行されます。 1. ストアから報告された情報に基づいて、一定期間内に特定のしきい値を超える読み取り/書き込みトラフィックを判別し、ホットリージョンをカウントします。 @@ -96,7 +96,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ スケールインとは、コマンドを使用してストアをオフラインにし、「オフライン」としてマークするプロセスを指します。PDは、オフラインノード上のリージョンをスケジュールに従って他のノードに複製します。障害復旧は、ストアに障害が発生し、復旧できない場合に適用されます。この場合、対応するストアに分散されたピアを持つリージョンのレプリカが失われる可能性があり、PDは他のノードでレプリカを補充する必要があります。 -スケールインと障害回復のプロセスは基本的に同じです。1 `replicaChecker`異常な状態にあるリージョン ピアを見つけ、異常なピアを正常なストア上の新しいピアに置き換える演算子を生成します。 +スケールインと障害回復のプロセスは基本的に同じです。`replicaChecker`異常な状態にあるリージョン ピアを見つけ、異常なピアを正常なストア上の新しいピアに置き換える演算子を生成します。 ### リージョンの統合 {#region-merge} @@ -165,7 +165,7 @@ pd-ctl のストア コマンドを使用して、各ストアの残高ステー pd-ctl を使用すると、以下の3つの側面からスケジューリング戦略を調整できます。詳細は[PD Control](/pd-control.md)を参照してください。 -### スケジューラを手動で追加/削除する {#add-delete-scheduler-manually} +### スケジューラを手動で追加/削除する {#adddelete-scheduler-manually} PDはpd-ctlを介してスケジューラを動的に追加および削除することをサポートしています。例： @@ -173,7 +173,7 @@ PDはpd-ctlを介してスケジューラを動的に追加および削除する - `scheduler remove balance-leader-scheduler` : バランスリーダースケジューラを削除（無効化）する - `scheduler add evict-leader-scheduler 1` : ストア 1 のすべてのリーダーを削除するスケジューラを追加します。 -### オペレータを手動で追加/削除する {#add-delete-operators-manually} +### オペレータを手動で追加/削除する {#adddelete-operators-manually} PDはpd-ctlを介してオペレータを直接追加または削除することもできます。例えば： @@ -196,7 +196,7 @@ pd-ctl の`config show`コマンドを使用してスケジュール設定を確 このセクションでは、いくつかの一般的なシナリオを通じて PD スケジューリング戦略のベスト プラクティスについて説明します。 -### リーダー/リージョンが均等に分布していない {#leaders-regions-are-not-evenly-distributed} +### リーダー/リージョンが均等に分布していない {#leadersregions-are-not-evenly-distributed} PDの評価メカニズムでは、異なるストアのリーダー数とリージョン数だけでは負荷分散状況を完全に反映できないと判断されます。そのため、TiKVの実際の負荷やストレージ使用量から、負荷の不均衡が発生しているかどうかを確認する必要があります。 @@ -213,7 +213,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー - オペレータが正常に生成されていても、スケジュール処理が遅い場合は、次のことが考えられます。 - - スケジューリング速度は、負荷分散を目的としてデフォルトで制限されています。1 または`region-schedule-limit` `leader-schedule-limit`を大きくしても、通常のサービスに大きな影響はありません。また、 `max-pending-peer-count`および`max-snapshot-count`で指定された制限を適切に緩和することもできます。 + - スケジューリング速度は、負荷分散を目的としてデフォルトで制限されています。`leader-schedule-limit`または`region-schedule-limit`を大きくしても、通常のサービスに大きな影響はありません。また、 `max-pending-peer-count`および`max-snapshot-count`で指定された制限を適切に緩和することもできます。 - 他のスケジューリングタスクが同時に実行されているため、バランシングの速度が低下しています。この場合、バランシングが他のスケジューリングタスクよりも優先される可能性がある場合は、他のタスクを停止するか、速度を制限することができます。例えば、バランシングの実行中に一部のノードをオフラインにすると、両方の操作でクォータ`region-schedule-limit`が消費されます。このような場合、スケジューラの速度を制限してノードを削除するか、 `enable-replace-offline-replica = false`設定して一時的に無効にすることができます。 - スケジューリングプロセスが遅すぎます。原因を確認するには`RemovePeer` **Operator ステップの所要時間**メトリックを確認してください。通常、スナップショットの送受信を伴わないステップ（ `TransferLeader` `PromoteLearner` ）は数ミリ秒で完了するはずですが、スナップショットを伴うステップ（ `AddLearner` `AddPeer` ）は数十秒で完了すると予想されます。所要時間が明らかに長すぎる場合は、TiKV の負荷が高いか、ネットワークのボトルネックが発生している可能性があります。具体的な分析が必要です。 @@ -229,8 +229,8 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー オペレーターは正常に生成されたが、スケジュール プロセスが遅い場合は、次の理由が考えられます。 -- スケジューリング速度はデフォルトで制限されています。1 または`leader-schedule-limit` `replica-schedule-limit`値を大きく調整できます。同様に、 `max-pending-peer-count`と`max-snapshot-count`の制限を緩和することも検討できます。 -- 他のスケジューリングタスクが同時に実行され、システム内のリソースを奪い合っています。解決策は[リーダー/リージョンが均等に分布していない](#leaders-regions-are-not-evenly-distributed)を参照してください。 +- スケジューリング速度はデフォルトで制限されています。`leader-schedule-limit`または`replica-schedule-limit`の値を大きく調整できます。同様に、 `max-pending-peer-count`と`max-snapshot-count`の制限を緩和することも検討できます。 +- 他のスケジューリングタスクが同時に実行され、システム内のリソースを奪い合っています。解決策は[リーダー/リージョンが均等に分布していない](#leadersregions-are-not-evenly-distributed)を参照してください。 - 単一ノードをオフラインにすると、処理対象となるリージョンリーダー（レプリカ3台構成では約1/3）が削除対象のノードに分散されます。そのため、処理速度はこの単一ノードによるスナップショット生成速度によって制限されます。「 `evict-leader-scheduler`を手動で追加することで、リージョンリーダーの移行速度を上げることができます。 対応する演算子の生成に失敗した場合、考えられる理由は次のとおりです。 @@ -240,7 +240,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー ### ノードをオンラインにするのが遅い {#bringing-nodes-online-is-slow} -現在、ノードのオンライン化はバランスリージョンメカニズムを通じてスケジュールされています。トラブルシューティングについては[リーダー/リージョンが均等に分布していない](#leaders-regions-are-not-evenly-distributed)を参照してください。 +現在、ノードのオンライン化はバランスリージョンメカニズムを通じてスケジュールされています。トラブルシューティングについては[リーダー/リージョンが均等に分布していない](#leadersregions-are-not-evenly-distributed)を参照してください。 ### ホットリージョンが均等に分布していない {#hot-regions-are-not-evenly-distributed} @@ -293,9 +293,9 @@ TiKV ノードに障害が発生した場合、PD はデフォルトで、対応 実用的には、ノード障害が回復不可能と判断された場合、直ちにオフラインにすることができます。これにより、PDはすぐに別のノードにレプリカを補充し、データ損失のリスクを軽減します。一方、ノードが回復可能と判断されたものの、30分以内に回復できない場合は、タイムアウト後にレプリカの不必要な補充とリソースの浪費を回避するために、一時的に`max-store-down-time`大きく調整することができます。 -TiDB v5.2.0以降、TiKVは低速ディスクノードを検出するメカニズムを導入しました。このメカニズムは、TiKV内のリクエストをサンプリングすることで、1から100までのスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。1 [`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe)加算することで、低速ノードをスケジュールできます。低速と検出されたTiKVノードが1つだけで、その低速スコアが上限（デフォルトでは80）に達した場合、そのノードのリーダーは排除されます（ `evict-leader-scheduler`加算した場合と同様の効果）。 +TiDB v5.2.0以降、TiKVは低速ディスクノードを検出するメカニズムを導入しました。このメカニズムは、TiKV内のリクエストをサンプリングすることで、1から100までのスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。[`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe)を追加することで、低速ノードをスケジュールできます。低速と検出されたTiKVノードが1つだけで、その低速スコアが上限（デフォルトでは80）に達した場合、そのノードのリーダーは排除されます（ `evict-leader-scheduler`加算した場合と同様の効果）。 -v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニズムを導入しました。低速ディスクノード検出と同様に、このメカニズムはTiKVノード間のネットワークレイテンシーをプローブし、スコアを計算することで低速ノードを特定します。このメカニズムを有効にするには[`enable-network-slow-store`](/pd-control.md#scheduler-config-evict-slow-store-scheduler)指定します（デフォルトでは無効）。 +v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニズムを導入しました。低速ディスクノード検出と同様に、このメカニズムはTiKVノード間のネットワークレイテンシーをプローブし、スコアを計算することで低速ノードを特定します。このメカニズムを有効にするには[`enable-network-slow-store`](/pd-control.md#scheduler-config-evict-slow-store-scheduler)を指定します（デフォルトでは無効）。 > **Note:** > diff --git a/best-practices/saas-best-practices.md b/best-practices/saas-best-practices.md index a9d825dc0ae9d..8b2d954d6755c 100644 --- a/best-practices/saas-best-practices.md +++ b/best-practices/saas-best-practices.md @@ -78,7 +78,7 @@ SaaSマルチテナントシナリオでは、通常、各ユーザーはTiDBに - より多くの同時リクエストをサポートするには、TiDB 構成項目[`token-limit`](/tidb-configuration-file.md#token-limit) (デフォルトでは`1000` ) を増やします。 - TiDBのメモリ使用量は接続数にほぼ比例します。実際のテストでは、アイドル接続が20万件あると、TiDBのメモリ使用量が約30GiB増加しました。実際の接続数に基づいて、TiDBのメモリ仕様を増やすことをお勧めします。 -- `PREPARED`ステートメントを使用する場合、各接続はセッションレベルのプリペアドプランキャッシュを維持します。3 `DEALLOCATE`ステートメントが長時間実行されない場合、キャッシュに過剰なプランが蓄積され、メモリ使用量が増加する可能性があります。実際のテストでは、 `IndexRangeScan`含む 400,000 の実行プランで約 5 GiB のメモリが消費されました。これに応じてメモリ仕様を増やすことをお勧めします。 +- `PREPARED`ステートメントを使用する場合、各接続はセッションレベルのプリペアドプランキャッシュを維持します。`DEALLOCATE`ステートメントが長時間実行されない場合、キャッシュに過剰なプランが蓄積され、メモリ使用量が増加する可能性があります。実際のテストでは、 `IndexRangeScan`含む 400,000 の実行プランで約 5 GiB のメモリが消費されました。これに応じてメモリ仕様を増やすことをお勧めします。 ## 古いものを使用するには、慎重に読んでください {#use-stale-read-carefully} diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index 85f78bc255dce..d4c3f25221f6b 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/best-practices/three-nodes-hybrid-deployment.md @@ -123,4 +123,4 @@ tiup ctl:v tikv --host=${ip:port} modify-tikv-config -n gc.max_ このパラメータは、Goプロセス全体で使用できるCPUコアの数を制御するために使用されます。デフォルトでは、この値は現在のマシンまたはcgroupのCPUコア数と同じです。 -Goの実行中、GCなどのバックグラウンドタスクには一定量のスレッドが使用されます。1パラメータの値を制限しないと、これらのバックグラウンドタスク`performance.max-procs` CPUを過剰に消費することになります。 +Goの実行中、GCなどのバックグラウンドタスクには一定量のスレッドが使用されます。`performance.max-procs`パラメータの値を制限しないと、これらのバックグラウンドタスクがCPUを過剰に消費することになります。 diff --git a/best-practices/uuid.md b/best-practices/uuid.md index 612711f0681cb..0823a30c5e3e6 100644 --- a/best-practices/uuid.md +++ b/best-practices/uuid.md @@ -61,4 +61,4 @@ Key Visualizer の詳細については、次のドキュメントを参照し ## MySQLの互換性 {#mysql-compatibility} -UUIDはMySQLでも使用できます。1と`UUID_TO_BIN()` `BIN_TO_UUID()`はMySQL 8.0で導入されました。5 `UUID()`関数はそれ以前のMySQLバージョンでも使用できます。 +UUIDはMySQLでも使用できます。`BIN_TO_UUID()`と`UUID_TO_BIN()`関数はMySQL 8.0で導入されました。`UUID()`関数はそれ以前のMySQLバージョンでも使用できます。 diff --git a/binary-package.md b/binary-package.md index f05d2a97436cc..e1f20539f63e3 100644 --- a/binary-package.md +++ b/binary-package.md @@ -70,7 +70,7 @@ TiDBバイナリパッケージは、amd64およびarm64アーキテクチャで > **Note:** > -> `{version}`インストールするツールのバージョンによって異なります。2 `{arch}`システムのアーキテクチャによって異なり、 `amd64`または`arm64`になります。 +> `{version}`インストールするツールのバージョンによって異なります。`{arch}`システムのアーキテクチャによって異なり、 `amd64`または`arm64`になります。 ## 参照 {#see-also} diff --git a/blocklist-control-plan.md b/blocklist-control-plan.md index 51b15a307a8f8..b8f5af85477a3 100644 --- a/blocklist-control-plan.md +++ b/blocklist-control-plan.md @@ -96,10 +96,10 @@ DESC mysql.expr_pushdown_blacklist; 上記の各フィールドの説明は次のとおりです。 - `name` : プッシュダウンが無効になっている関数の名前。 -- `store_type` : 関数の計算時にプッシュダウンされないようにするコンポーネントを指定します。指定できる要素は`tidb` 、 `tikv` 、 `tiflash`です。8 `store_type`大文字と小文字を区別しません。複数の要素を指定する必要がある場合は、各コンポーネントをカンマで区切ってください。 - - `store_type`が`tidb`場合、TiDBメモリテーブルの読み取り中に他の TiDB サーバーで関数を実行できるかどうかを示します。 - - `store_type`が`tikv`場合、関数が TiKV サーバーのコプロセッサーコンポーネントで実行できるかどうかを示します。 - - `store_type`が`tiflash`場合、関数がTiFlash Server のコプロセッサーコンポーネントで実行できるかどうかを示します。 +- `store_type` : 関数の計算時にプッシュダウンされないようにするコンポーネントを指定します。指定できる要素は`tidb` 、 `tikv` 、 `tiflash`です。`store_type`大文字と小文字を区別しません。複数の要素を指定する必要がある場合は、各コンポーネントをカンマで区切ってください。 + - `store_type`が`tidb`の場合、TiDBメモリテーブルの読み取り中に他の TiDB サーバーで関数を実行できるかどうかを示します。 + - `store_type`が`tikv`の場合、関数が TiKV サーバーのコプロセッサーコンポーネントで実行できるかどうかを示します。 + - `store_type`が`tiflash`の場合、関数がTiFlash Server のコプロセッサーコンポーネントで実行できるかどうかを示します。 - `reason` : この関数がブロックリストに追加された理由を記録します。 ### 使用法 {#usage} diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md index 40834f360723d..2906edf460807 100644 --- a/br/br-auto-tune.md +++ b/br/br-auto-tune.md @@ -69,7 +69,7 @@ tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v - 自動調整により、 `backup.auto-tune-refresh-interval`分ごとに統計が更新され、バックアップ タスクで使用できる CPU コアの最大数が再計算されます。 - デフォルト値: `1m` -以下は、自動チューニングの動作例です。1 `*`バックアップ タスクで使用される CPU コアを示します。3 `^`他のタスクで使用される CPU コアを示します。5 `-` 、アイドル状態の CPU コアを示します。 +以下は、自動チューニングの動作例です。`*`バックアップ タスクで使用される CPU コアを示します。`^`他のタスクで使用される CPU コアを示します。`-` 、アイドル状態の CPU コアを示します。 |--------| The server has 8 logical CPU cores. |****----| By default, `backup.num-threads` is `4`. Note that auto-tune makes sure that the thread pool size is never larger than `backup.num-threads`. diff --git a/br/br-batch-create-table.md b/br/br-batch-create-table.md index 0552092e49534..6e0fb791bcb2e 100644 --- a/br/br-batch-create-table.md +++ b/br/br-batch-create-table.md @@ -22,7 +22,7 @@ summary: TiDB v6.0.0では、データ復元時のテーブル作成プロセス ## バッチテーブル作成を使用する {#use-batch-create-table} -BRはデフォルトでバッチテーブル作成機能を有効にします。v6.0.0以降では、復元プロセスを高速化するために、デフォルト設定は`--ddl-batch-size=128` 。そのため、このパラメータを設定する必要はありません。3 `--ddl-batch-size=128` 、バッチでテーブルを作成し、各バッチで128個のテーブルを作成することを意味します。 +BRはデフォルトでバッチテーブル作成機能を有効にします。v6.0.0以降では、復元プロセスを高速化するために、デフォルト設定は`--ddl-batch-size=128` 。そのため、このパラメータを設定する必要はありません。`--ddl-batch-size=128` 、バッチでテーブルを作成し、各バッチで128個のテーブルを作成することを意味します。 この機能を無効にするには、 `--ddl-batch-size`を`1`に設定します。以下のコマンド例をご覧ください。 diff --git a/br/br-checkpoint-backup.md b/br/br-checkpoint-backup.md index 59ee872255126..69011305a8f0c 100644 --- a/br/br-checkpoint-backup.md +++ b/br/br-checkpoint-backup.md @@ -27,7 +27,7 @@ TiDBクラスタが大規模で、障害発生後に再度バックアップを ### バックアップの再試行はGCの前に行う必要があります {#backup-retry-must-be-prior-to-gc} -バックアップ中、 `br` PD内のバックアップスナップショット`gc-safepoint`を定期的に更新し、データのガベージコレクションを回避します。5 `br`終了すると、 `gc-safepoint`時間内に更新されません。その結果、次のバックアップ再試行までに、データがガベージコレクションされている可能性があります。 +バックアップ中、 `br` PD内のバックアップスナップショット`gc-safepoint`を定期的に更新し、データのガベージコレクションを回避します。`br`終了すると、 `gc-safepoint`時間内に更新されません。その結果、次のバックアップ再試行までに、データがガベージコレクションされている可能性があります。 このような状況を回避するため、 `gcttl`指定されていない場合、 `br`デフォルトで`gc-safepoint`約1時間保持します。必要に応じて、 `gcttl`パラメータを設定することで保持期間を延長できます。 @@ -49,4 +49,4 @@ tiup br backup full \ - 中断の原因がエラーである場合、 `br`終了前にバックアップされたデータのメタ情報を保持します。この場合、次回の再試行では、バックアップ中のデータのみを再度バックアップする必要があります。 -- `br`プロセスがシステムによって中断された場合、 `br`外部ストレージにバックアップされたデータのメタ情報を永続化できません。5 `br` 30秒ごとにメタ情報を永続化するため、中断前の30秒間にバックアップされたデータは永続化できず、次回の再試行時に再度バックアップする必要があります。 +- `br`プロセスがシステムによって中断された場合、 `br`外部ストレージにバックアップされたデータのメタ情報を永続化できません。`br` 30秒ごとにメタ情報を永続化するため、中断前の30秒間にバックアップされたデータは永続化できず、次回の再試行時に再度バックアップする必要があります。 diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index 3eed6a0aea860..60e0b02308329 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -13,19 +13,19 @@ TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポ TiDBクラスタが大規模で、障害発生後に再度リストアを行う余裕がない場合は、チェックポイントリストア機能を使用できます。brコマンドラインツール（以下、 `br` ）は、リストアされたシャードを定期的に記録します。これにより、次回のリストア再試行では、異常終了に近いリカバリ進捗ポイントを使用できます。 -## 実施原則 {#implementation-principles} +## 実装原理 {#implementation-principles} -チェックポイント復元の実装は、スナップショット復元とログ復元の2つの部分に分かれています。詳細については、 [実装の詳細: チェックポイントデータを下流のクラスタに保存する](#implementation-details-store-checkpoint-data-in-the-downstream-cluster)と[実装の詳細: チェックポイントデータを外部ストレージに保存する](#implementation-details-store-checkpoint-data-in-the-external-storage)参照してください。 +チェックポイント復元の実装は、スナップショット復元とログ復元の2つの部分に分かれています。詳細については、 [実装の詳細: チェックポイントデータを下流のクラスタに保存する](#implementation-details-store-checkpoint-data-in-the-downstream-cluster)と[実装の詳細: チェックポイントデータを外部ストレージに保存する](#implementation-details-store-checkpoint-data-in-the-external-storage)を参照してください。 ### スナップショットの復元 {#snapshot-restore} -スナップショット復元の実装は[スナップショットバックアップ](/br/br-checkpoint-backup.md#implementation-details)と同様です。3 `br` 、キー範囲（リージョン）内のすべてのSSTファイルを一括して復元します。復元が完了すると、 `br`この範囲と復元されたクラスタテーブルのテーブルIDを記録します。チェックポイント復元機能は、復元されたキー範囲を永続化するために、新しい復元情報を定期的に外部ストレージにアップロードします。 +スナップショット復元の実装は[スナップショットバックアップ](/br/br-checkpoint-backup.md#implementation-details)と同様です。 `br`は、キー範囲（リージョン）内のすべてのSSTファイルを一括して復元します。復元が完了すると、 `br`はこの範囲と復元されたクラスタテーブルのテーブルIDを記録します。チェックポイント復元機能は、復元されたキー範囲を永続化するために、新しい復元情報を定期的に外部ストレージにアップロードします。 -`br`復元を再試行する際、外部ストレージから復元されたキー範囲を読み取り、対応するテーブルIDと照合します。復元中、 `br`チェックポイント復元で記録されたキー範囲と重複し、同じテーブルIDを持つキー範囲をスキップします。 +`br`は復元を再試行する際、外部ストレージから復元されたキー範囲を読み取り、対応するテーブルIDと照合します。復元中、 `br`はチェックポイント復元で記録されたキー範囲と重複し、同じテーブルIDを持つキー範囲をスキップします。 -`br`リストアを再試行する前にテーブルを削除した場合、再試行時に新しく作成されたテーブルのテーブルIDは、以前にチェックポイントリストアに記録されたテーブルIDと異なります。この場合、 `br`以前のチェックポイントリストア情報をバイパスし、テーブルを再度リストアします。つまり、新しいIDを持つ同じテーブルは、古いIDのチェックポイントリストア情報を無視し、新しいIDに対応する新しいチェックポイントリストア情報を記録することになります。 +`br`がリストアを再試行する前にテーブルを削除した場合、再試行時に新しく作成されたテーブルのテーブルIDは、以前にチェックポイントリストアに記録されたテーブルIDと異なります。この場合、 `br`は以前のチェックポイントリストア情報をバイパスし、テーブルを再度リストアします。つまり、新しいIDを持つ同じテーブルは、古いIDのチェックポイントリストア情報を無視し、新しいIDに対応する新しいチェックポイントリストア情報を記録することになります。 -MVCC (Multi-Version Concurrency Control) メカニズムを使用しているため、指定されたタイムスタンプを持つデータを順序なしで繰り返し書き込むことができます。 +MVCC (Multi-Version Concurrency Control) メカニズムを使用しているため、指定されたタイムスタンプを持つデータを、順不同かつ繰り返し書き込むことができます。 スナップショット復元を使用してデータベースまたはテーブルのDDLを復元する場合、パラメータ`ifExists`が追加されます。既に作成済みとみなされる既存のデータベースまたはテーブルの場合、パラメータ`br`を指定すると復元は自動的にスキップされます。 @@ -35,27 +35,27 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた スナップショットバックアップファイルとは異なり、ログバックアップファイルの範囲は重複する可能性があります。そのため、キー範囲を復旧進捗メタデータとして直接使用することはできません。また、ログバックアップファイルの数が多すぎる場合もあります。ただし、各ログバックアップファイルは、ログバックアップメタデータ内で固定の位置を持ちます。つまり、ログバックアップメタデータ内の一意の位置を、復旧進捗メタデータとして各ログバックアップファイルに割り当てることができます。 -ログバックアップメタデータには、ファイルメタデータの配列が含まれています。配列内の各ファイルメタデータは、複数のログバックアップファイルで構成されるファイルを表します。ファイルメタデータには、連結されたファイル内のログバックアップファイルのオフセットとサイズが記録されます。したがって、トリプル`(log backup metadata name, file metadata array offset, log backup file array offset)` `br`してログバックアップファイルを一意に識別できます。 +ログバックアップメタデータには、ファイルメタデータの配列が含まれています。配列内の各ファイルメタデータは、複数のログバックアップファイルで構成されるファイルを表します。ファイルメタデータには、連結されたファイル内のログバックアップファイルのオフセットとサイズが記録されます。したがって、`br`は`(ログバックアップメタデータ名、ファイルメタデータ配列オフセット、ログバックアップファイル配列オフセット)`の3つの要素の組を使用してログバックアップファイルを一意に識別できます。 ## 使用制限 {#usage-limitations} -チェックポイント復元はGCメカニズムに依存しており、復元されたすべてのデータを記録することはできません。詳細については、以下のセクションで説明します。 +チェックポイント復元はGCメカニズムに依存しており、復元されたすべてのデータを記録できるわけではありません。詳細については、以下のセクションで説明します。 ### GCは一時停止されます {#gc-will-be-paused} -ログの復元中、復元されたデータの順序は不規則です。つまり、キーの削除レコードが書き込みレコードよりも先に復元される可能性があります。この時にGCがトリガーされると、キーのすべてのデータが削除され、GCはキーの後続の書き込みレコードを処理できなくなります。このような状況を回避するため、 `br`ログの復元中にGCを一時停止します。3 `br`途中で終了した場合、GCは一時停止状態のままになります。 +ログの復元中、復元されたデータの順序は不規則です。つまり、キーの削除レコードが書き込みレコードよりも先に復元される可能性があります。この時にGCがトリガーされると、キーのすべてのデータが削除され、GCはキーの後続の書き込みレコードを処理できなくなります。このような状況を回避するため、 `br`はログの復元中にGCを一時停止します。`br`が途中で終了した場合、GCは一時停止状態のままになります。 ログの復元が完了すると、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`は、 `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} -`br`復元を再試行する場合、復元中のデータやチェックポイントによって記録されていないデータなど、復元されたデータの一部を再度復元する必要がある場合があります。 +`br`は復元を再試行する場合、復元中のデータやチェックポイントによって記録されていないデータなど、復元されたデータの一部を再度復元する必要がある場合があります。 -- 中断の原因がエラーである場合、 `br`終了前に復元されたデータのメタ情報を保持します。この場合、次回の再試行では復元中のデータのみを再度復元する必要があります。 +- 中断の原因がエラーである場合、 `br`は終了前に復元されたデータのメタ情報を保持します。この場合、次回の再試行では復元中のデータのみを再度復元する必要があります。 -- `br`プロセスがシステムによって中断された場合、 `br`外部ストレージに復元されたデータのメタ情報を永続化できません。5 `br` 30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。 +- `br`プロセスがシステムによって中断された場合、 `br`は外部ストレージに復元されたデータのメタ情報を永続化できません。`br`は30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。 ### 復元中にクラスタデータを変更しないようにする {#avoid-modifying-cluster-data-during-the-restore} @@ -63,43 +63,43 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた ### クロスメジャーバージョンのチェックポイントリカバリは推奨されません {#cross-major-version-checkpoint-recovery-is-not-recommended} -メジャーバージョン間のチェックポイントリカバリは推奨されません。v8.5.0より前のLong-Term Support (LTS)バージョンを使用して`br`リカバリが失敗したクラスターの場合、v8.5.0以降のLTSバージョンを使用してリカバリを続行することはできません。また、その逆も同様です。 +メジャーバージョン間のチェックポイントリカバリは推奨されません。v8.5.0より前のLong-Term Support (LTS)バージョンを使用して`br`のリカバリが失敗したクラスターの場合、v8.5.0以降のLTSバージョンを使用してリカバリを続行することはできません。また、その逆も同様です。 ## 実装の詳細: チェックポイントデータを下流のクラスタに保存する {#implementation-details-store-checkpoint-data-in-the-downstream-cluster} > **Note:** > -> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して`--checkpoint-storage`チェックポイントデータのストレージを指定できます。 +> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。`--checkpoint-storage`パラメータを使用して、チェックポイントデータのストレージを指定できます。 チェックポイント復元操作は、スナップショット復元と PITR 復元の 2 つの部分に分かれています。 ### スナップショットの復元 {#snapshot-restore} -初期復元中に、 `br`ターゲットクラスタに`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、上流クラスタID、およびバックアップデータの BackupTS が記録されます。 +初期復元中に、 `br`はターゲットクラスタに`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、上流クラスタID、およびバックアップデータの BackupTS が記録されます。 -復元が失敗した場合は、同じコマンドを使用して再試行できます。1 `br` `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 +復元が失敗した場合は、同じコマンドを使用して再試行できます。`br`は`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 -復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、 `br`エラーを報告します。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。 +復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、 `br`はエラーを報告します。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。 ### PITR復元 {#pitr-restore} -[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)スナップショットの復元フェーズとログの復元フェーズで構成されます。 +[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)はスナップショットの復元フェーズとログの復元フェーズで構成されます。 -初期リストアでは、 `br`スナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。 +初期リストアでは、 `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リストアデータの不整合が発生する可能性があります。** +初期リストア中のログリストアフェーズに入る前に、 `br`が`restored-ts`時点における上流および下流のクラスタデータベースとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、システムテーブル`mysql.tidb_pitr_id_map`に保存されます。 **`mysql.tidb_pitr_id_map`からデータを恣意的に削除すると、PITRリストアデータの不整合が発生する可能性があります。** > **Note:** > -> 以前のバージョンのクラスターとの互換性を確保するため、v8.5.5以降では、復元クラスターにシステムテーブル`mysql.tidb_pitr_id_map`存在しない場合、 `pitr_id_map`データがログバックアップディレクトリに書き込まれます。ファイル名は`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`です。 +> 以前のバージョンのクラスターとの互換性を確保するため、v8.5.5以降では、復元クラスターにシステムテーブル`mysql.tidb_pitr_id_map`が存在しない場合、 `pitr_id_map`データがログバックアップディレクトリに書き込まれます。ファイル名は`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`です。 ## 実装の詳細: チェックポイントデータを外部ストレージに保存する {#implementation-details-store-checkpoint-data-in-the-external-storage} > **Note:** > -> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して`--checkpoint-storage`チェックポイントデータの外部ストレージを指定できます。例： +> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。`--checkpoint-storage`パラメータを使用して、チェックポイントデータの外部ストレージを指定できます。例： > > ```shell > ./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints" @@ -107,9 +107,9 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた 外部ストレージでは、チェックポイント データのディレクトリ構造は次のようになります。 -- ルート パス`restore-{downstream-cluster-ID}` 、ダウンストリーム クラスター ID `{downstream-cluster-ID}`を使用して、異なる復元クラスターを区別します。 +- ルート パス`restore-{downstream-cluster-ID}`は、ダウンストリーム クラスター ID `{downstream-cluster-ID}`を使用して、異なる復元クラスターを区別します。 - パス`restore-{downstream-cluster-ID}/log`は、ログ復元フェーズ中にログ ファイルのチェックポイント データが保存されます。 -- パス`restore-{downstream-cluster-ID}/sst` 、ログ復元フェーズ中にログ バックアップによってバックアップされない SST ファイルのチェックポイント データが保存されます。 +- パス`restore-{downstream-cluster-ID}/sst`は、ログ復元フェーズ中にログ バックアップによってバックアップされない SST ファイルのチェックポイント データが保存されます。 - パス`restore-{downstream-cluster-ID}/snapshot`は、スナップショット復元フェーズ中にチェックポイント データが保存されます。 @@ -141,21 +141,21 @@ 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` 、指定された外部ストレージパスからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 +復元が失敗した場合は、同じコマンドを使用して再試行できます。`br`は、指定された外部ストレージパスからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 -復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、エラーコード`br`報告されます。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがすでにクリーンアップされている場合は、外部ストレージ内のチェックポイントデータを手動でクリーンアップするか、チェックポイントデータを保存する別の外部ストレージパスを指定して、別のバックアップで再試行してください。 +復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、 `br`はエラーを報告します。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがすでにクリーンアップされている場合は、外部ストレージ内のチェックポイントデータを手動でクリーンアップするか、チェックポイントデータを保存する別の外部ストレージパスを指定して、別のバックアップで再試行してください。 ### PITR復元 {#pitr-restore} -[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)スナップショットの復元フェーズとログの復元フェーズで構成されます。 +[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)はスナップショットの復元フェーズとログの復元フェーズで構成されます。 -初期リストアでは、 `br`スナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `restore-{downstream-cluster-ID}/snapshot`パスに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。 +初期リストアでは、 `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 リストアデータの不整合が発生する可能性があります。** +初期リストア中のログリストアフェーズに入る前に、 `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 リストアデータの不整合が発生する可能性があります。** > **Note:** > diff --git a/br/br-incremental-guide.md b/br/br-incremental-guide.md index aa1c14d034724..3086c95422986 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`から現在時刻の間に生成された増分データを自動的にバックアップします。`--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..db50b8f02f666 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -49,7 +49,7 @@ summary: このドキュメントでは、ログバックアップの監視、 | **tikv_log_backup_initial_scan_operations** | カウンタ | 初期スキャン中の RocksDB 関連操作の統計。
`cf :: {"default", "write", "lock"}, op :: RocksDBOP` | | **tikv_log_backup_enabled** | カウンタ | ログバックアップを有効にするかどうか。値が`0`より大きい場合、ログバックアップは有効になります。 | | **tikv_log_backup_observed_region** | ゲージ | リッスンされているリージョンの数。 | -| **tikv_log_backup_task_status** | ゲージ | ログ バックアップ タスクのステータス。1 `0`実行中、 `1`一時停止中、 `2`エラーを意味します。
`task :: string` | +| **tikv_log_backup_task_status** | ゲージ | ログ バックアップ タスクのステータス。`0`実行中、 `1`一時停止中、 `2`エラーを意味します。
`task :: string` | | **tikv_log_backup_pending_initial_scan** | ゲージ | 保留中の初期スキャンの統計。
`stage :: {"queuing", "executing"}` | ### ログバックアップアラート {#log-backup-alerts} diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md index d767ec031cd54..1d3bfc327c408 100644 --- a/br/br-pitr-guide.md +++ b/br/br-pitr-guide.md @@ -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日ごと）に従ってクラスタースナップショットをバックアップストレージにバックアップできます。 +スナップショットバックアップは、フルバックアップの方法として使用できます。`tiup br backup full`を実行すると、固定スケジュール（たとえば2日ごと）に従ってクラスタースナップショットをバックアップストレージにバックアップできます。 ```shell tiup br backup full --pd "${PD_IP}:2379" \ diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index 8384351938299..353a0afa40b9d 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -94,9 +94,9 @@ BR を使用すると、ログ バックアップ データをバックアップ TiDB v8.4.0 以降では、ログ バックアップ コマンドで次のパラメータ ( [スナップショットバックアップの暗号化](/br/br-snapshot-manual.md#encrypt-the-backup-data)に類似) を渡すことで、ログ バックアップ データを暗号化できます。 -- `--log.crypter.method` : 暗号化アルゴリズム。2、4、6 `aes192-ctr` `aes128-ctr`かになります。デフォルト値は`aes256-ctr` `plaintext` 、データは暗号化されません。 +- `--log.crypter.method` : 暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr` 、または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 - `--log.crypter.key` : 16進文字列形式の暗号化キー。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）、アルゴリズム`aes192-ctr`の場合は24バイト、アルゴリズム`aes256-ctr`の場合は32バイトのキーです。 -- `--log.crypter.key-file` : キーファイル。2 `crypter.key`渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 +- `--log.crypter.key-file` : キーファイル。`crypter.key`渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 次に例を示します。 @@ -111,7 +111,7 @@ tiup br log start \ ただし、セキュリティ要件が高いシナリオでは、固定の暗号化キーをコマンドラインで直接渡すことは望ましくない場合があります。セキュリティをさらに強化するには、マスターキーベースの暗号化システムを使用して暗号化キーを管理できます。このシステムは、ログバックアップファイルごとに異なるデータキーを生成し、マスターキーのローテーションをサポートします。以下のパラメータを使用して設定できます。 -- `--master-key-crypter-method` : マスターキーに基づく暗号化アルゴリズム。2、4 `aes192-ctr`または`aes256-ctr` `aes128-ctr`かになります。デフォルト値は`plaintext`で、データは暗号化されません。 +- `--master-key-crypter-method` : マスターキーに基づく暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr`または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 - `--master-key` ：マスターキーの設定。ローカルディスクに保存されたマスターキー、またはクラウドキー管理サービス（KMS）によって管理されたマスターキーを使用できます。 ローカル ディスクに保存されているマスター キーを使用して暗号化します。 diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md index 28c5d01bc98b0..2a24efa55226f 100644 --- a/br/br-snapshot-manual.md +++ b/br/br-snapshot-manual.md @@ -133,7 +133,7 @@ tiup br restore full \ バックアップと復元機能は、データをバックアップする際に、統計情報をJSON形式で`backupmeta`ファイルに保存します。データを復元する際には、JSON形式の統計情報をクラスターに読み込みます。詳細については、 [負荷統計](/sql-statements/sql-statement-load-stats.md)参照してください。 -v8.5.5以降、 BRは`--fast-load-sys-tables`パラメータを導入し、デフォルトで有効になっています。3 `br`ラインツールを使用して新しいクラスターにデータを復元する場合、上流クラスターと下流クラスター間のテーブルとパーティションのIDを再利用できます（そうでない場合、 BRは自動的に統計を論理的にロードします） `--fast-load-sys-tables`有効にすると、 BRはまず統計関連のシステムテーブルを一時システムデータベース`__TiDB_BR_Temporary_mysql`に復元し、次に`RENAME TABLE`ステートメントを使用してこれらのテーブルを`mysql`データベース内の対応するテーブルとアトミックにスワップします。 +v8.5.5以降、 BRは`--fast-load-sys-tables`パラメータを導入し、デフォルトで有効になっています。`br`ラインツールを使用して新しいクラスターにデータを復元する場合、上流クラスターと下流クラスター間のテーブルとパーティションのIDを再利用できます（そうでない場合、 BRは自動的に統計を論理的にロードします） `--fast-load-sys-tables`有効にすると、 BRはまず統計関連のシステムテーブルを一時システムデータベース`__TiDB_BR_Temporary_mysql`に復元し、次に`RENAME TABLE`ステートメントを使用してこれらのテーブルを`mysql`データベース内の対応するテーブルとアトミックにスワップします。 次に例を示します。 @@ -150,7 +150,7 @@ TiDB v5.3.0 以降では、次のパラメータを設定することでバッ - `--crypter.method` : 暗号化アルゴリズム`aes128-ctr` `aes192-ctr`または`aes256-ctr`いずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 - `--crypter.key` : 16進文字列形式の暗号化キー。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）、アルゴリズム`aes192-ctr`の場合は24バイト、アルゴリズム`aes256-ctr`の場合は32バイトのキーです。 -- `--crypter.key-file` : キーファイル。2 `crypter.key`渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 +- `--crypter.key-file` : キーファイル。`crypter.key`渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 次に例を示します。 diff --git a/br/use-br-command-line-tool.md b/br/use-br-command-line-tool.md index dbc9bf6040a6a..49e14520207fe 100644 --- a/br/use-br-command-line-tool.md +++ b/br/use-br-command-line-tool.md @@ -22,7 +22,7 @@ tiup br backup full --pd "${PD_IP}:2379" \ - `backup` : `tiup br`のサブコマンド。 - `full` : `tiup br backup`のサブコマンド。 -- `-s` (または`--storage` ): バックアップ ファイルが保存されるパスを指定するオプション。4 は`"s3://backup-data/snapshot-202209081330/"` `-s`パラメーターです。 +- `-s` (または`--storage` ): バックアップ ファイルが保存されるパスを指定するオプション。`"s3://backup-data/snapshot-202209081330/"`は`-s`のパラメーターです。 - `--pd` : PD サービス アドレスを指定するオプション`"${PD_IP}:2379"`は`--pd`のパラメーターです。 ### コマンドとサブコマンド {#commands-and-sub-commands} @@ -60,12 +60,12 @@ tiup br backup full --pd "${PD_IP}:2379" \ - `--concurrency` : バックアップタスクを複数のリクエストに分割し、同じ TiKV ノードに同時に送信する方法を制御します。このパラメータは主にBRから TiKV へのリクエスト分割の粒度に影響し、全体的なバックアップスループットを直接決定するものではありません。ほとんどの場合、この値を変更する必要はありません。バックアップパフォーマンスを向上させるには、代わりに[`tikv.backup.num-threads`](/tikv-configuration-file.md#num-threads-1)調整する必要があります。 - `--pitr-concurrency` : ログ復元中の同時タスクの数。 - `--tikv-max-restore-concurrency` : スナップショット復元中の TiKV ノードあたりの同時タスクの最大数。 -- `--compression` : バックアップファイルの生成に使用する圧縮アルゴリズムを決定します。2、4、6 `lz4`サポートし、デフォルトは`zstd`です（通常は変更する必要`zstd`ありません）。異なる圧縮アルゴリズムの選択に関するガイダンスについては、 [この文書](https://github.com/EighteenZi/rocksdb_wiki/blob/master/Compression.md)を`snappy`してください。 -- `--compression-level` : バックアップに選択した圧縮アルゴリズムに対応する圧縮レベルを設定します。2 `zstd`のデフォルトの圧縮レベルは 3 です。ほとんどの場合、このオプションを設定する必要はありません。 +- `--compression` : バックアップファイルの生成に使用する圧縮アルゴリズムを決定します。`lz4` 、 `snappy` 、 `zstd`をサポートし、デフォルトは`zstd`です（通常は変更する必要はありません）。異なる圧縮アルゴリズムの選択に関するガイダンスについては、 [この文書](https://github.com/EighteenZi/rocksdb_wiki/blob/master/Compression.md)を参照してください。 +- `--compression-level` : バックアップに選択した圧縮アルゴリズムに対応する圧縮レベルを設定します。`zstd`のデフォルトの圧縮レベルは 3 です。ほとんどの場合、このオプションを設定する必要はありません。 ## フルバックアップのコマンド {#commands-of-full-backup} -クラスターデータをバックアップするには、 `tiup br backup`コマンドを実行します。3 または`full` `table`コマンドを追加して、バックアップ操作の範囲（クラスター全体（ `full` ）または単一のテーブル（ `table` ））を指定できます。 +クラスターデータをバックアップするには、 `tiup br backup`コマンドを実行します。`full`または`table`サブコマンドを追加して、バックアップ操作の範囲（クラスター全体（ `full` ）または単一のテーブル（ `table` ））を指定できます。 - [TiDB クラスターのスナップショットをバックアップする](/br/br-snapshot-manual.md#back-up-cluster-snapshots) - [データベースをバックアップする](/br/br-snapshot-manual.md#back-up-a-database) diff --git a/cached-tables.md b/cached-tables.md index 7f28b90f0646d..49b0785841e8c 100644 --- a/cached-tables.md +++ b/cached-tables.md @@ -72,7 +72,7 @@ SHOW CREATE TABLE users; 1 row in set (0.00 sec) ``` -キャッシュされたテーブルからデータを読み込んだ後、TiDBはデータをメモリにロードします。1 文[`TRACE`](/sql-statements/sql-statement-trace.md)使用すると、データがメモリにロードされているかどうかを確認できます。キャッシュにロードされていない場合、返される結果には`regionRequest.SendReqCtx`属性が含まれます。これは、TiDBがTiKVからデータを読み込んでいることを示します。 +キャッシュされたテーブルからデータを読み込んだ後、TiDBはデータをメモリにロードします。[`TRACE`](/sql-statements/sql-statement-trace.md)文を使用すると、データがメモリにロードされているかどうかを確認できます。キャッシュにロードされていない場合、返される結果には`regionRequest.SendReqCtx`属性が含まれます。これは、TiDBがTiKVからデータを読み込んでいることを示します。 ```sql TRACE SELECT * FROM users; @@ -234,7 +234,7 @@ Query OK, 0 rows affected (0.00 sec) ## TiDB移行ツールとの互換性 {#compatibility-with-tidb-migration-tools} -キャッシュテーブルは、MySQL構文に対するTiDBの拡張です。1 `ALTER TABLE ... CACHE`を認識できるのはTiDBのみです。TiDB移行ツール（Backup & Restore (BR)、TiCDC、 Dumplingなど）は、キャッシュテーブルをサポートし**ていません**。これらのツールは、キャッシュテーブルを通常のテーブルとして扱います。 +キャッシュテーブルは、MySQL構文に対するTiDBの拡張です。`ALTER TABLE ... CACHE`を認識できるのはTiDBのみです。TiDB移行ツール（Backup & Restore (BR)、TiCDC、 Dumplingなど）は、キャッシュテーブルをサポートし**ていません**。これらのツールは、キャッシュテーブルを通常のテーブルとして扱います。 つまり、キャッシュテーブルはバックアップとリストアが行われると、通常のテーブルになります。下流クラスターが別のTiDBクラスターであり、キャッシュテーブル機能を引き続き使用したい場合は、下流クラスターで`ALTER TABLE ... CACHE`実行することで、キャッシュテーブルを手動で有効化できます。 diff --git a/certificate-authentication.md b/certificate-authentication.md index 2405bba23e874..9721af9f02ac1 100644 --- a/certificate-authentication.md +++ b/certificate-authentication.md @@ -198,7 +198,7 @@ openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pem ### サーバー証明書を使用するように TiDB を構成する {#configure-tidb-to-use-server-certificate} -TiDB設定ファイルの`[security]`セクションを変更します。この手順では`path/to/server-key.pem` CA証明書、サーバー鍵、サーバー証明書`path/to/ca-cert.pem`保存されるディレクトリを指定します。3、5、7 `path/to/server-cert.pem`任意のディレクトリに置き換えることができます。 +TiDB設定ファイルの`[security]`セクションを変更します。この手順では、CA証明書、サーバー鍵、サーバー証明書が保存されるディレクトリを指定します。`path/to/server-cert.pem` 、 `path/to/server-key.pem` 、 `path/to/ca-cert.pem`は任意のディレクトリに置き換えることができます。 ```toml [security] diff --git a/character-set-and-collation.md b/character-set-and-collation.md index 86cd3ed7d28ba..63922b4275ae5 100644 --- a/character-set-and-collation.md +++ b/character-set-and-collation.md @@ -178,7 +178,7 @@ 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`使用することをお勧めします。 -以下は、4バイトの絵文字をテーブルに挿入する際のデフォルトの動作を示しています。1 `INSERT`文は`utf8`文字セットでは失敗しますが、 `utf8mb4`の文では成功します。 +以下は、4バイトの絵文字をテーブルに挿入する際のデフォルトの動作を示しています。`INSERT`文は`utf8`文字セットでは失敗しますが、 `utf8mb4`の文では成功します。 ```sql CREATE TABLE utf8_test ( @@ -382,7 +382,7 @@ SELECT _utf8mb4'string' COLLATE utf8mb4_general_ci; - デフォルト データベースの文字セットと照合順序は、システム変数`character_set_database`と`collation_database`の値です。 -`character_set_connection`と`collation_connection` 、各接続の文字セットと照合順序を指定するために使用できます。5 `character_set_client` 、クライアントの文字セットを設定するための変数です。 +`character_set_connection`と`collation_connection` 、各接続の文字セットと照合順序を指定するために使用できます。`character_set_client` 、クライアントの文字セットを設定するための変数です。 結果を返す前に、 `character_set_results`システム変数は、結果のメタデータを含む、サーバーがクライアントにクエリ結果を返す文字セットを示します。 @@ -390,7 +390,7 @@ SELECT _utf8mb4'string' COLLATE utf8mb4_general_ci; - `SET NAMES 'charset_name' [COLLATE 'collation_name']` - `SET NAMES` 、クライアントがサーバーに SQL ステートメントを送信するために使用する文字セットを示します。2 `SET NAMES utf8mb4` 、クライアントからのすべてのリクエストとサーバーからの結果に utf8mb4 が使用されることを示します。 + `SET NAMES` 、クライアントがサーバーに SQL ステートメントを送信するために使用する文字セットを示します。`SET NAMES utf8mb4` 、クライアントからのすべてのリクエストとサーバーからの結果に utf8mb4 が使用されることを示します。 `SET NAMES 'charset_name'`文は次の文の組み合わせと同等です。 diff --git a/check-before-deployment.md b/check-before-deployment.md index 3d9b7dd67e5bc..e47e6cdc8f850 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -275,7 +275,7 @@ TiDB は、 ACIDモデルにおけるトランザクションの線形一貫性 NTP サービスがインストールされ、NTPサーバーと正常に同期しているかどうかを確認するには、次の手順を実行します。 -1. 次のコマンドを実行します。1 `running`返された場合、NTPサービスは実行中です。 +1. 次のコマンドを実行します。`running`が返された場合、NTPサービスは実行中です。 ```bash sudo systemctl status ntpd.service @@ -359,7 +359,7 @@ NTP サービスがインストールされ、NTPサーバーと正常に同期 - オフセットが大きすぎると思われる場合は、コマンド`chronyc makestep`を実行してすぐに時間オフセットを修正できます。そうでない場合は、 `chronyd`実行して徐々に時間オフセットを修正します。 -NTPサービスの同期をできるだけ早く開始するには、次のコマンドを実行してください。1 `pool.ntp.org` NTPサーバーに置き換えてください。 +NTPサービスの同期をできるだけ早く開始するには、次のコマンドを実行してください。`pool.ntp.org` NTPサーバーに置き換えてください。 ```bash sudo systemctl stop ntpd.service && \ @@ -656,7 +656,7 @@ sudo systemctl enable ntpd.service > > - `vm.min_free_kbytes`は、システムによって予約される空きメモリの最小量 (KiB 単位) を制御する Linux カーネル パラメータです。 > - `vm.min_free_kbytes`に設定すると、メモリ回収メカニズムに影響します。設定値が大きすぎると利用可能なメモリが減少し、小さすぎるとメモリ要求速度がバックグラウンド回収速度を超え、メモリ回収が発生し、結果としてメモリ割り当てが遅延する可能性があります。 - > - 少なくとも`vm.min_free_kbytes` ～ `1048576` KiB（1 GiB）に設定することをお勧めします。5 [NUMAがインストールされている](/check-before-deployment.md#install-the-numactl-tool)の場合は、 `number of NUMA nodes * 1048576` KiBに設定することをお勧めします。 + > - `vm.min_free_kbytes`を少なくとも`1048576` KiB（1 GiB）に設定することをお勧めします。[NUMAがインストールされている](/check-before-deployment.md#install-the-numactl-tool)場合は、 `number of NUMA nodes * 1048576` KiBに設定することをお勧めします。 > - Linux カーネル 4.11 以前を実行しているシステムの場合は、 `net.ipv4.tcp_tw_recycle = 0`を設定することをお勧めします。 10. ユーザーの`limits.conf`ファイルを構成するには、次のコマンドを実行します。 @@ -696,7 +696,7 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t tidb ALL=(ALL) NOPASSWD: ALL -3. `tidb`ユーザーでコントロールマシンにログインし、以下のコマンドを実行します。3 `10.0.1.1`ターゲットマシンの IP アドレスに置き換え、プロンプトが表示されたらターゲットマシンの`tidb`ユーザーパスワードを入力します。コマンド実行後、SSH 相互信頼が既に作成されています。これは他のマシンにも適用されます。新しく作成された`tidb`ユーザーには`.ssh`ディレクトリがありません。このようなディレクトリを作成するには、RSA キーを生成するコマンドを実行します。コントロールマシンに TiDB コンポーネントを展開するには、コントロールマシンとコントロールマシン自体の相互信頼を設定します。 +3. `tidb`ユーザーでコントロールマシンにログインし、以下のコマンドを実行します。`10.0.1.1`ターゲットマシンの IP アドレスに置き換え、プロンプトが表示されたらターゲットマシンの`tidb`ユーザーパスワードを入力します。コマンド実行後、SSH 相互信頼が既に作成されています。これは他のマシンにも適用されます。新しく作成された`tidb`ユーザーには`.ssh`ディレクトリがありません。このようなディレクトリを作成するには、RSA キーを生成するコマンドを実行します。コントロールマシンに TiDB コンポーネントを展開するには、コントロールマシンとコントロールマシン自体の相互信頼を設定します。 ```bash ssh-keygen -t rsa @@ -756,6 +756,6 @@ sudo yum -y install numactl SELinux を無効にするか、permissive モードに設定する必要があります。現在のステータスを確認するには、 [ゲットエンフォース(8)](https://linux.die.net/man/8/getenforce)ユーティリティを使用してください。 -SELinuxが無効になっていない場合は、 `/etc/selinux/config`ファイルを開き、 `SELINUX=`で始まる行を`SELINUX=disabled`に変更します。この変更を行った後、システムを再起動する必要があります。7または`enforcing` `permissive` `disabled`への変更は、再起動しないと有効になりません。 +SELinuxが無効になっていない場合は、 `/etc/selinux/config`ファイルを開き、 `SELINUX=`で始まる行を`SELINUX=disabled`に変更します。この変更を行った後、システムを再起動する必要があります。`enforcing`または`permissive`から`disabled`への変更は、再起動しないと有効になりません。 一部のシステム（Ubuntuなど）では、 `/etc/selinux/config`ファイルが存在せず、getenforceユーティリティがインストールされていない場合があります。その場合は、この手順をスキップしてください。 diff --git a/clinic/clinic-user-guide-for-tiup.md b/clinic/clinic-user-guide-for-tiup.md index a8d4f14500f88..1ef08eb25f7f0 100644 --- a/clinic/clinic-user-guide-for-tiup.md +++ b/clinic/clinic-user-guide-for-tiup.md @@ -243,7 +243,7 @@ PingCAPテクニカルサポートスタッフにクラスター診断データ tiup diag upload ``` -アップロードが完了すると、出力に`Download URL`が表示されます。3 `Download URL`リンクを開いてアップロードされたデータを確認するか、以前に連絡したPingCAPテクニカルサポートスタッフにリンクを送信してください。 +アップロードが完了すると、出力に`Download URL`が表示されます。`Download URL`リンクを開いてアップロードされたデータを確認するか、以前に連絡したPingCAPテクニカルサポートスタッフにリンクを送信してください。 #### 方法2. データをパックしてアップロードする {#method-2-pack-and-upload-data} diff --git a/column-pruning.md b/column-pruning.md index 403e4040c4e19..0d29caac88aa0 100644 --- a/column-pruning.md +++ b/column-pruning.md @@ -13,7 +13,7 @@ summary: TiDB での列プルーニングの使用法について学習します select a from t where b> 5 ``` -このクエリでは、列aと列bのみが使用され、列cと列dは冗長です。この文のクエリプランでは、 `Selection`の演算子が列bを使用し、 `DataSource`演算子が列aと列bを使用します。5 `DataSource`演算子は列cと列dを読み取らないため、これらはプルーニング可能です。 +このクエリでは、列aと列bのみが使用され、列cと列dは冗長です。この文のクエリプランでは、 `Selection`の演算子が列bを使用し、 `DataSource`演算子が列aと列bを使用します。`DataSource`演算子は列cと列dを読み取らないため、これらはプルーニング可能です。 そのため、TiDBはロジック最適化フェーズでトップダウンスキャンを実行する際に、リソースの無駄を削減するために冗長な列をプルーニングします。このスキャン処理は「カラムの剪定」と呼ばれ、ルール`columnPruner`に対応しています。 diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index 7dbc450dab5c8..c17d9b4b33471 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -122,7 +122,7 @@ 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）で、区切り文字として`,`を使用します。`*`任意のIPアドレスを意味します。 > **Warning:** > diff --git a/command-line-flags-for-tikv-configuration.md b/command-line-flags-for-tikv-configuration.md index ee00768b3a89d..79823e2f2063f 100644 --- a/command-line-flags-for-tikv-configuration.md +++ b/command-line-flags-for-tikv-configuration.md @@ -53,7 +53,7 @@ TiKV は、コマンドラインパラメータに対していくつかの読み - このフラグを使用すると、使用可能な構成値が`FORMAT`に従ってリストされ、終了します。 - `FORMAT`の値オプション: `json` 。現在、JSON 形式のみがサポートされています。 -- 出力されるJSONには、設定名（Name）、デフォルト値（DefaultValue）、現在の値（ValueInFile）のみが記載されます。1または`--config` `-C`されている場合は、ファイル内の設定項目の現在の値とデフォルト値が一緒に記載され、 `-C`または`--config`が指定されていない項目にはデフォルト値のみが設定されます。以下は例です。 +- 出力されるJSONには、設定名（Name）、デフォルト値（DefaultValue）、現在の値（ValueInFile）のみが記載されます。`-C`または`--config`が指定されている場合は、ファイル内の設定項目の現在の値とデフォルト値が一緒に記載され、 `-C`または`--config`が指定されていない項目にはデフォルト値のみが設定されます。以下は例です。 ```json { diff --git a/comment-syntax.md b/comment-syntax.md index 44d164965a193..4d356d68369ac 100644 --- a/comment-syntax.md +++ b/comment-syntax.md @@ -109,7 +109,7 @@ MySQLでは、コメントにサーバーのバージョン番号（例： `/*!5 TiDB には独自のコメント構文 (つまり、TiDB 固有のコメント構文) があり、次の 2 種類に分けられます。 - `/*T! Specific code */` : この構文は TiDB によってのみ解析および実行され、他のデータベースでは無視されます。 -- `/*T![feature_id] Specific code */` : この構文は、TiDBの異なるバージョン間の互換性を確保するために使用されます。TiDBは、現在のバージョンで`feature_id`の対応する機能を実装している場合にのみ、このコメント内のSQLフラグメントを解析できます。例えば、 `AUTO_RANDOM`機能はv3.1.1で導入されているため、このバージョンのTiDBは`/*T![auto_rand] auto_random */`を`auto_random`に解析できます。10 `AUTO_RANDOM`機能はv3.0.0では実装されていないため、上記のSQL文フラグメントは無視されます。/* **`/*T![`文字内にスペースを入れないでください**。 +- `/*T![feature_id] Specific code */` : この構文は、TiDBの異なるバージョン間の互換性を確保するために使用されます。TiDBは、現在のバージョンで`feature_id`の対応する機能を実装している場合にのみ、このコメント内のSQLフラグメントを解析できます。例えば、 `AUTO_RANDOM`機能はv3.1.1で導入されているため、このバージョンのTiDBは`/*T![auto_rand] auto_random */`を`auto_random`に解析できます。`AUTO_RANDOM`機能はv3.0.0では実装されていないため、上記のSQL文フラグメントは無視されます。**`/*T![`文字内にスペースを入れないでください**。 ## オプティマイザコメント構文 {#optimizer-comment-syntax} diff --git a/configure-load-base-split.md b/configure-load-base-split.md index 310ae1c1e9de2..eee47692d3bbb 100644 --- a/configure-load-base-split.md +++ b/configure-load-base-split.md @@ -20,7 +20,7 @@ TiDBでは、負荷が特定のノードに集中すると、ホットスポッ - リージョンを均等に分割することは、必ずしも最適な選択とは限りません。リクエストが少数のキーに集中する可能性があるためです。このような場合、均等分割後もホットスポットがいずれかのリージョンに残る可能性があり、目的を達成するには複数回の均等分割が必要になる場合があります。 - 人間の介入はタイムリーでも簡単でもない。 -## 実施原則 {#implementation-principles} +## 実装原理 {#implementation-principles} Load Base Splitは、統計情報に基づいてリージョンを自動的に分割します。読み取り負荷またはCPU使用率が10秒間継続的にしきい値を超えるリージョンを特定し、これらのリージョンを適切な位置で分割します。分割位置の選択にあたっては、分割後の両リージョンのアクセス負荷のバランスを取り、リージョン間のアクセスを回避しようとします。 @@ -32,7 +32,7 @@ Load Base Splitによって分割されたリージョンは、すぐにはマ - [`split.qps-threshold`](/tikv-configuration-file.md#qps-threshold) :リージョンがホットスポットと判断されるQPSのしきい値。4GB [`region-split-size`](/tikv-configuration-file.md#region-split-size)の場合はデフォルト値は1秒あたり`3000` 、それ以外の場合はデフォルト値は`7000`です。 - [`split.byte-threshold`](/tikv-configuration-file.md#byte-threshold-new-in-v50) : (v5.0で導入)リージョンがホットスポットとして識別されるトラフィックしきい値。単位はバイトです`region-split-size`が4GB未満の場合はデフォルト値は30MiB/秒、それ以外の場合は100MiB/秒です。 -- [`split.region-cpu-overload-threshold-ratio`](/tikv-configuration-file.md#region-cpu-overload-threshold-ratio-new-in-v620) : (v6.2.0 で導入)リージョンがホットスポットと判断される CPU 使用率のしきい値 (読み取りスレッドプールの CPU 時間の割合)。4 `region-split-size`未満の場合はデフォルト値は`0.25` 、それ以外の場合はデフォルト値は`0.75`です。 +- [`split.region-cpu-overload-threshold-ratio`](/tikv-configuration-file.md#region-cpu-overload-threshold-ratio-new-in-v620) : (v6.2.0 で導入)リージョンがホットスポットと判断される CPU 使用率のしきい値 (読み取りスレッドプールの CPU 時間の割合)。`region-split-size`が4GB未満の場合はデフォルト値は`0.25` 、それ以外の場合はデフォルト値は`0.75`です。 リージョンが10 秒連続して次のいずれかの条件を満たした場合、TiKV はリージョンを分割しようとします。 diff --git a/configure-memory-usage.md b/configure-memory-usage.md index 916aa933340da..fd4c9b1b6c6cc 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -127,7 +127,7 @@ TiDBが使用するトランザクションモデルでは、トランザクシ ### フロー制御 {#flow-control} -- TiDBは、データ読み取り演算子の動的メモリ制御をサポートしています。デフォルトでは、この演算子はデータ読み取りに使用できる最大スレッド数を使用します。1 [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency)のSQL実行でメモリ使用量が毎回[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)超えると、データ読み取り演算子は1つのスレッドを停止します。 +- TiDBは、データ読み取り演算子の動的メモリ制御をサポートしています。デフォルトでは、この演算子は[`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency)で許可される最大スレッド数を使用してデータを読み取ります。単一のSQL実行でメモリ使用量が毎回[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)を超えると、データ読み取り演算子は1つのスレッドを停止します。 - このフロー制御動作は、システム変数[`tidb_enable_rate_limit_action`](/system-variables.md#tidb_enable_rate_limit_action)によって制御されます。 @@ -145,7 +145,7 @@ TiDBは、実行演算子のディスクへの書き込みをサポートして > **Note:** > -> HashAgg のディスクスピルは、 `DISTINCT`集計関数を含む SQL 実行をサポートしていません。3 `DISTINCT`集計関数を含む SQL 実行でメモリ使用量が多すぎる場合、ディスクスピルは適用されません。 +> HashAgg のディスクスピルは、 `DISTINCT`集計関数を含む SQL 実行をサポートしていません。`DISTINCT`集計関数を含む SQL 実行でメモリ使用量が多すぎる場合、ディスクスピルは適用されません。 次の例では、メモリを消費する SQL ステートメントを使用して、HashAgg のディスク スピル機能を示します。 diff --git a/configure-placement-rules.md b/configure-placement-rules.md index e86e0381fcad6..6faa0c1ca53bc 100644 --- a/configure-placement-rules.md +++ b/configure-placement-rules.md @@ -326,7 +326,7 @@ table ttt ranges: (NOTE: key range might be changed after DDL) ### シナリオ2: 3つのデータセンターに5つのレプリカを2:2:1の割合で配置し、Leaderは3番目のデータセンターに配置しない {#scenario-2-place-five-replicas-in-three-data-centers-in-the-proportion-of-2-2-1-and-the-leader-should-not-be-in-the-third-data-center} -3つのルールを作成します。レプリカ数をそれぞれ`2` 、 `2` 、 `1`に設定します。各ルールで、レプリカを対応するデータセンター`label_constraints`から 8 に制限します。さらに、Leaderを必要としないデータセンターについては、 `role`を`follower`に変更します。 +3つのルールを作成します。レプリカ数をそれぞれ`2` 、 `2` 、 `1`に設定します。各ルールで、 `label_constraints`によってレプリカを対応するデータセンターに制限します。さらに、Leaderを必要としないデータセンターについては、 `role`を`follower`に変更します。 ```json [ diff --git a/daily-check.md b/daily-check.md index 80be291715c06..c0973713d7083 100644 --- a/daily-check.md +++ b/daily-check.md @@ -18,7 +18,7 @@ TiDB Dashboardは、TiDBデータベースの運用と保守を簡素化しま ![Instance panel](/media/instance-status-panel.png) - **ステータス**：このインジケーターは、ステータスが正常かどうかを確認するために使用されます。オンラインノードの場合は、このインジケーターは無視できます。 -- **稼働時間**：重要な指標です。2の`Up Time`が変更されている場合は、コンポーネントが再起動された理由を特定する必要があります。 +- **稼働時間**：重要な指標です。`Up Time`が変更されている場合は、コンポーネントが再起動された理由を特定する必要があります。 - **バージョン**、**デプロイメントディレクトリ**、 **Gitハッシュ**：これらの指標を確認することで、バージョンやデプロイメントディレクトリの不整合や誤りを回避できます。 ### ホストパネル {#host-panel} diff --git a/dashboard/dashboard-diagnostics-report.md b/dashboard/dashboard-diagnostics-report.md index d5ecd51e047e4..30ef5ba154cc6 100644 --- a/dashboard/dashboard-diagnostics-report.md +++ b/dashboard/dashboard-diagnostics-report.md @@ -53,7 +53,7 @@ summary: TiDB Dashboard診断レポートでは、基本情報、診断情報、 上記の表のフィールドの説明は次のとおりです。 - `HOST` :サーバーの IP アドレス。 -- `INSTANCE` :サーバーにデプロイされているインスタンスの数。たとえば、 `pd * 1`サーバーに PD インスタンスが 1 つデプロイされていることを意味します。4 `tidb * 2 pd * 1` 、サーバーに TiDB インスタンスが 2 つと PD インスタンスが 1 つデプロイされていることを意味します。 +- `INSTANCE` :サーバーにデプロイされているインスタンスの数。たとえば、 `pd * 1`サーバーに PD インスタンスが 1 つデプロイされていることを意味します。`tidb * 2 pd * 1` 、サーバーに TiDB インスタンスが 2 つと PD インスタンスが 1 つデプロイされていることを意味します。 - `CPU_CORES` :サーバーの CPU コア数 (物理コアまたは論理コア) を示します。 - `MEMORY` :サーバーのメモリサイズを示します。単位はGBです。 - `DISK` :サーバーのディスクサイズを示します。単位はGBです。 @@ -325,7 +325,7 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり ![Compare Report Time Range report](/media/dashboard/dashboard-diagnostics-compare-time.png) -上記の表では、 `t1`正常な時間範囲、つまり基準時間範囲です。3 `t2`異常な時間範囲です。 +上記の表では、 `t1`正常な時間範囲、つまり基準時間範囲です。`t2`異常な時間範囲です。 スロークエリに関連するテーブルは次のように表示されます。 @@ -361,7 +361,7 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり ![Maximum Different Item table](/media/dashboard/dashboard-diagnostics-maximum-different-item.png) - `Table` : この監視メトリックが比較レポート内のどのテーブルから取得されるかを示します。たとえば、 `TiKV, coprocessor_info` TiKVコンポーネントの`coprocessor_info`のテーブルを示します。 -- `METRIC_NAME` : 監視メトリック名。2 `expand`クリックすると、メトリックの異なるラベルの比較が表示されます。 +- `METRIC_NAME` : 監視メトリック名。`expand`クリックすると、メトリックの異なるラベルの比較が表示されます。 - `LABEL` : 監視メトリックに対応するラベル。例えば、監視メトリック`TiKV Coprocessor scan`には、TiKVアドレス、リクエストタイプ、操作タイプ、操作カラムファミリーを表す2つのラベル（ `instance` 、 `req` 、 `tag` 、 `sql_type` ）があります。 - `MAX_DIFF` : `t1.VALUE`と`t2.VALUE`の`DIFF_RATIO`計算した結果の差の値。 diff --git a/dashboard/dashboard-diagnostics-usage.md b/dashboard/dashboard-diagnostics-usage.md index 8512682b93462..b5aa4f86b5e04 100644 --- a/dashboard/dashboard-diagnostics-usage.md +++ b/dashboard/dashboard-diagnostics-usage.md @@ -15,7 +15,7 @@ summary: TiDB Dashboardの診断レポートは、異なる時間範囲でのシ ![QPS example](/media/dashboard/dashboard-diagnostics-usage1.png) -`go-ycsb` `2020-03-10 13:24:30`テストの結果は上の画像に示されています。3でQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの診断レポートを使用して原因を特定できます。 +`go-ycsb`圧力テストの結果は上の画像に示されています。`2020-03-10 13:24:30`にQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの診断レポートを使用して原因を特定できます。 次の 2 つの時間範囲でシステムを比較するレポートを生成します。 @@ -65,7 +65,7 @@ digest | 24bd6d8a9b238086c9b8c3d240ad4ef32f79ce94cf5a468c0b8fe1eb5f8 ![QPS results](/media/dashboard/dashboard-diagnostics-usage3.png) -もう`go-ycsb`圧力テストの結果を上の`2020-03-08 01:46:30`に示します。3でQPSが急激に低下し始め、回復していないことがわかります。 +もう1つの`go-ycsb`圧力テストの結果を上の画像に示します。`2020-03-08 01:46:30`にQPSが急激に低下し始め、回復していないことがわかります。 次の 2 つの時間範囲でシステムを比較するレポートを生成します。 @@ -96,7 +96,7 @@ MESSAGE | [expensivequery.go:167] [expensive_query] [cost_time=60.085949605s] [ ![QPS results](/media/dashboard/dashboard-diagnostics-usage5.png) -`go-ycsb` `2020-05-22 22:14:00`テストの結果は上の画像に示されています。3でQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの比較診断レポートを使用して、原因を特定できます。 +`go-ycsb`圧力テストの結果は上の画像に示されています。`2020-05-22 22:14:00`にQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの比較診断レポートを使用して、原因を特定できます。 次の 2 つの時間範囲でシステムを比較するレポートを生成します。 diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index cff3050e93c2b..ee10b88533a47 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -42,7 +42,7 @@ Prometheusインスタンスをデプロイしてもこの問題が引き続き 2. アップグレード後、Prometheus インスタンスを使用して新しいクラスターをデプロイすると、メトリックが正常に表示されます。 -3. アップグレード後、既存のクラスターを再起動してメトリクスアドレスを報告できます。1 `CLUSTER_NAME`実際のクラスター名に置き換えてください。 +3. アップグレード後、既存のクラスターを再起動してメトリクスアドレスを報告できます。`CLUSTER_NAME`実際のクラスター名に置き換えてください。 ```bash tiup cluster start CLUSTER_NAME diff --git a/dashboard/dashboard-metrics-relation.md b/dashboard/dashboard-metrics-relation.md index 0e5a09182bcf2..be30ffe687e8e 100644 --- a/dashboard/dashboard-metrics-relation.md +++ b/dashboard/dashboard-metrics-relation.md @@ -42,8 +42,8 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー ![tidb\_execute node example1](/media/dashboard/dashboard-metrics-relation-node-example1.png) - `tidb_execute` 、TiDB 実行エンジンでの SQL クエリの実行期間を表す監視メトリックの名前です。 -- `19306.46s` 、メトリック`tidb_execute`の合計実行時間が 19306.46 秒であることを示します。4 `89.40%` 、19306.46 秒がすべての SQL クエリ（ユーザー SQL クエリと TiDB 内部 SQL クエリを含む）の合計実行時間の 89.40% を占めていることを示します。クエリの合計実行時間は、 `tidb_query`の合計実行時間です。 -- `9070.18s` 、 `tidb_execute`ノード自体の合計実行時間が 9070.18 秒であり、残りがその子ノードによって消費された時間であることを表します。4 `42.00%` 、9070.18 秒がすべてのクエリの合計クエリ時間の 42.00% を占めることを表します。 +- `19306.46s` 、メトリック`tidb_execute`の合計実行時間が 19306.46 秒であることを示します。`89.40%` 、19306.46 秒がすべての SQL クエリ（ユーザー SQL クエリと TiDB 内部 SQL クエリを含む）の合計実行時間の 89.40% を占めていることを示します。クエリの合計実行時間は、 `tidb_query`の合計実行時間です。 +- `9070.18s` 、 `tidb_execute`ノード自体の合計実行時間が 9070.18 秒であり、残りがその子ノードによって消費された時間であることを表します。`42.00%` 、9070.18 秒がすべてのクエリの合計クエリ時間の 42.00% を占めることを表します。 ボックス領域にマウスを移動すると、 `tidb_execute`メトリック ノードの詳細が表示されます。 @@ -64,7 +64,7 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー さらに、 `tidb_execute`は`tidb_cop`ボックス領域を指す点線の矢印もあり、次のことを示しています。 -`tidb_execute` `tidb_cop`番目のメトリックの実行時間が含まれますが、同時に`cop`リクエストが実行される場合があります。例えば、2 つのテーブルに対して`join`クエリを実行する`execute`番目の実行時間は 60 秒ですが、その間に結合した 2 つのテーブルに対してテーブルスキャンリクエストが同時に実行されます。10 `cop`のリクエストの実行時間がそれぞれ 40 秒と 30 秒の場合、 `cop`のリクエストの合計実行時間は 70 秒になります。しかし、 `execute`実行時間はわずか 60 秒です。したがって、親ノードの実行時間に子ノードの実行時間が完全に含まれていない場合、点線の矢印は子ノードを指します。 +`tidb_execute`には`tidb_cop`メトリックの実行時間が含まれますが、同時に`cop`リクエストが実行される場合があります。例えば、2 つのテーブルに対して`join`クエリを実行する`execute`の実行時間は 60 秒ですが、その間に結合した 2 つのテーブルに対してテーブルスキャンリクエストが同時に実行されます。`cop`リクエストの実行時間がそれぞれ 40 秒と 30 秒の場合、 `cop`のリクエストの合計実行時間は 70 秒になります。しかし、 `execute`の実行時間はわずか 60 秒です。したがって、親ノードの実行時間に子ノードの実行時間が完全に含まれていない場合、点線の矢印は子ノードを指します。 > **Note:** > diff --git a/dashboard/dashboard-ops-reverse-proxy.md b/dashboard/dashboard-ops-reverse-proxy.md index 1fd44bad0d685..c58b1d5902f91 100644 --- a/dashboard/dashboard-ops-reverse-proxy.md +++ b/dashboard/dashboard-ops-reverse-proxy.md @@ -133,7 +133,7 @@ server_configs: tiup cluster edit-config CLUSTER_NAME ``` -2. `server_configs`の`pd`設定の下にある設定項目を変更または追加します。5 `server_configs`存在しない場合は、最上位レベルに追加します。 +2. `server_configs`の`pd`設定の下にある設定項目を変更または追加します。`server_configs`存在しない場合は、最上位レベルに追加します。 ```yaml monitored: diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md index 1609f9b4452fd..ac08acdf96aee 100644 --- a/data-type-date-and-time.md +++ b/data-type-date-and-time.md @@ -93,7 +93,7 @@ DATE ### TIME型 {#code-time-code-type} -`TIME`型の場合、フォーマットは`HH:MM:SS[.fraction]`で、有効な値の範囲は '-838:59:59.000000' から '838:59:59.000000' です。5 `TIME` 、1 日の時刻だけでなく、2 つのイベント間の時間間隔も示します。オプションで 0 から 6 の範囲の`fsp`値を指定し、小数秒の精度を指定できます。省略した場合、デフォルトの精度は 0 です。 +`TIME`型の場合、フォーマットは`HH:MM:SS[.fraction]`で、有効な値の範囲は '-838:59:59.000000' から '838:59:59.000000' です。`TIME` 、1 日の時刻だけでなく、2 つのイベント間の時間間隔も示します。オプションで 0 から 6 の範囲の`fsp`値を指定し、小数秒の精度を指定できます。省略した場合、デフォルトの精度は 0 です。 ```sql TIME[(fsp)] @@ -125,7 +125,7 @@ TIMESTAMP[(fsp)] #### タイムゾーンの処理 {#timezone-handling} -`TIMESTAMP`保存する場合、TiDB は`TIMESTAMP`値を現在のタイムゾーンから UTC タイムゾーンに変換します。5 `TIMESTAMP`取得する場合、TiDB は保存されている`TIMESTAMP`値を UTC タイムゾーンから現在のタイムゾーンに変換します（注: `DATETIME`この方法では処理されません）。各接続のデフォルトのタイムゾーンはサーバーのローカルタイムゾーンですが、環境変数`time_zone`で変更できます。 +`TIMESTAMP`を保存する場合、TiDB は`TIMESTAMP`値を現在のタイムゾーンから UTC タイムゾーンに変換します。`TIMESTAMP`を取得する場合、TiDB は保存されている`TIMESTAMP`値を UTC タイムゾーンから現在のタイムゾーンに変換します（注: `DATETIME`この方法では処理されません）。各接続のデフォルトのタイムゾーンはサーバーのローカルタイムゾーンですが、環境変数`time_zone`で変更できます。 > **Warning:** > @@ -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)`を使用します。`type_name` `TIME` 、 `DATETIME`または`TIMESTAMP`になります。例えば、 ```sql CREATE TABLE t1 (t TIME(3), dt DATETIME(6)); @@ -185,7 +185,7 @@ CREATE TABLE t1 ( `fsp` 0 から 6 までの範囲でなければなりません。 - `0`小数部がないことを意味します。2 `fsp`省略した場合、デフォルトは0です。 + `0`小数部がないことを意味します。`fsp`省略した場合、デフォルトは0です。 - 小数部を含む`TIME` 、 `DATETIME` 、または`TIMESTAMP`挿入する場合、小数部の桁数が少なすぎる、または多すぎる場合は、四捨五入が必要になることがあります。例： diff --git a/data-type-default-values.md b/data-type-default-values.md index cdefc492e06a5..853d03a4e6920 100644 --- a/data-type-default-values.md +++ b/data-type-default-values.md @@ -27,9 +27,9 @@ summary: TiDB のデータ型のデフォルト値について学習します。 暗黙のデフォルトは次のように定義されます。 -- 数値型の場合、デフォルトは 0 です。1 `AUTO_INCREMENT`で宣言された場合、デフォルトはシーケンス内の次の値になります。 -- `TIMESTAMP`以外の日付と時刻型の場合、デフォルト値はその型に適切な「ゼロ」値です。3 `TIMESTAMP`場合、デフォルト値は現在の日付と時刻です。 -- `ENUM`以外の文字列型の場合、デフォルト値は空文字列です。3 `ENUM`場合、デフォルト値は最初の列挙値です。 +- 数値型の場合、デフォルトは 0 です。`AUTO_INCREMENT`で宣言された場合、デフォルトはシーケンス内の次の値になります。 +- `TIMESTAMP`以外の日付と時刻型の場合、デフォルト値はその型に適切な「ゼロ」値です。`TIMESTAMP`の場合、デフォルト値は現在の日付と時刻です。 +- `ENUM`以外の文字列型の場合、デフォルト値は空文字列です。`ENUM`の場合、デフォルト値は最初の列挙値です。 ## 式をデフォルト値として指定する {#specify-expressions-as-default-values} diff --git a/data-type-overview.md b/data-type-overview.md index 732f8888ebe3f..67e3e229b88d0 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`型に適用され、小数秒の精度を表します。`fsp`を指定する場合は、0から6の範囲でなければなりません。0 は小数部がないことを意味します。省略した場合、デフォルトの精度は0です。 diff --git a/data-type-string.md b/data-type-string.md index 05af978d4623b..feb53a60b9416 100644 --- a/data-type-string.md +++ b/data-type-string.md @@ -11,7 +11,7 @@ TiDBは、 `CHAR` 、 `VARCHAR` 、 `BINARY` 、 `VARBINARY` 、 `BLOB` 、 `TEX ### CHAR型 {#code-char-code-type} -`CHAR`は固定長文字列です。Mは列の長さを文字数（バイト数ではありません）で表します。Mの範囲は0から255です。2とは異なり、 `VARCHAR`列にデータを挿入する場合、末尾のスペース`CHAR`切り捨てられます。 +`CHAR`は固定長文字列です。Mは列の長さを文字数（バイト数ではありません）で表します。Mの範囲は0から255です。`VARCHAR`型とは異なり、 `CHAR`列にデータを挿入する場合、末尾のスペースは切り捨てられます。 ```sql [NATIONAL] CHAR[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] @@ -19,7 +19,7 @@ TiDBは、 `CHAR` 、 `VARCHAR` 、 `BINARY` 、 `VARBINARY` 、 `BLOB` 、 `TEX ### VARCHAR型 {#code-varchar-code-type} -`VARCHAR`は可変長の文字列です。Mは列の最大長（バイト数ではありません）を文字数で表します。2 `VARCHAR`最大サイズは65,535バイトを超えることはできません。4 `VARCHAR`長さは、行の最大長と使用されている文字セットによって決まります。 +`VARCHAR`は可変長の文字列です。Mは列の最大長（バイト数ではありません）を文字数で表します。`VARCHAR`最大サイズは65,535バイトを超えることはできません。`VARCHAR`長さは、行の最大長と使用されている文字セットによって決まります。 1文字が占めるスペースは、文字セットによって異なります。次の表は、1文字が消費するバイト数と、各文字セットにおける`VARCHAR`列の長さの範囲を示しています。 diff --git a/ddl_embedded_analyze.md b/ddl_embedded_analyze.md index 27fc9f4c6bbc9..8a82d6c359e5a 100644 --- a/ddl_embedded_analyze.md +++ b/ddl_embedded_analyze.md @@ -45,7 +45,7 @@ v8.5.0以降、TiDBはインデックス間のヒューリスティック比較 `tidb_stats_update_during_ddl`が`ON`の場合、 [`ADD INDEX`](/sql-statements/sql-statement-add-index.md)実行すると、再編成フェーズの終了後に埋め込まれた`ANALYZE`操作が自動的に実行されます。この`ANALYZE`操作は、新しく作成されたインデックスがユーザーに表示される前に、その統計情報を収集し、その後`ADD INDEX`残りのフェーズに進みます。 -`ANALYZE`時間がかかる可能性があることを考慮して、TiDB は最初の Reorg の実行時間に基づいてタイムアウトしきい値を設定します。3 `ANALYZE`タイムアウトすると、 `ADD INDEX` `ANALYZE`完了を同期的に待つのをやめ、後続のプロセスを続行します。これにより、インデックスがユーザーにとってより早く表示されます。つまり、インデックス統計は`ANALYZE`非同期的に完了した後に更新されます。 +`ANALYZE`時間がかかる可能性があることを考慮して、TiDB は最初の Reorg の実行時間に基づいてタイムアウトしきい値を設定します。`ANALYZE`タイムアウトすると、 `ADD INDEX` `ANALYZE`完了を同期的に待つのをやめ、後続のプロセスを続行します。これにより、インデックスがユーザーにとってより早く表示されます。つまり、インデックス統計は`ANALYZE`非同期的に完了した後に更新されます。 例えば： diff --git a/develop/dev-guide-choose-driver-or-orm.md b/develop/dev-guide-choose-driver-or-orm.md index 185dab7b52f6e..e62faa53e512d 100644 --- a/develop/dev-guide-choose-driver-or-orm.md +++ b/develop/dev-guide-choose-driver-or-orm.md @@ -95,7 +95,7 @@ implementation group: 'org.bouncycastle', name: 'bcpkix-jdk15on', version: '1.67 > > - 現在、Hibernate は[ネストされたトランザクションをサポートしていません](https://stackoverflow.com/questions/37927208/nested-transaction-in-spring-app-with-jpa-postgres)実行します。 > -> - TiDBはv6.2.0以降、 [セーブポイント](/sql-statements/sql-statement-savepoint.md)サポートしています。5 `@Transactional` `Propagation.NESTED`トランザクション伝播オプションを使用するには、つまり`@Transactional(propagation = Propagation.NESTED)`設定するには、TiDBがv6.2.0以降であることを確認してください。 +> - TiDBはv6.2.0以降、 [セーブポイント](/sql-statements/sql-statement-savepoint.md)サポートしています。`@Transactional` `Propagation.NESTED`トランザクション伝播オプションを使用するには、つまり`@Transactional(propagation = Propagation.NESTED)`設定するには、TiDBがv6.2.0以降であることを確認してください。 サポートレベル:**フル** @@ -127,7 +127,7 @@ implementation 'mysql:mysql-connector-java:8.0.33' - Hibernate を使用してネイティブJavaで TiDB アプリケーションを構築する例については、 [TiDBとHibernateを使ったシンプルなCRUDアプリの構築](/develop/dev-guide-sample-application-java-hibernate.md)参照してください。 - Spring Data JPA または Hibernate を使用して Spring で TiDB アプリケーションを構築する例については、 [Spring Bootを使用してTiDBアプリを構築する](/develop/dev-guide-sample-application-java-spring-boot.md)参照してください。 -さらに、 [Hibernate設定ファイル](https://www.tutorialspoint.com/hibernate/hibernate_configuration.htm) : `org.hibernate.dialect.TiDBDialect`で TiDB 方言を指定する必要があります。これは Hibernate `6.0.0.Beta2`以降でのみサポートされます。7 `Hibernate`バージョンが`6.0.0.Beta2`より前の場合は、まずアップグレードしてください。 +さらに、 [Hibernate設定ファイル](https://www.tutorialspoint.com/hibernate/hibernate_configuration.htm) : `org.hibernate.dialect.TiDBDialect`で TiDB 方言を指定する必要があります。これは Hibernate `6.0.0.Beta2`以降でのみサポートされます。`Hibernate`バージョンが`6.0.0.Beta2`より前の場合は、まずアップグレードしてください。 > **Note:** > diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index cc1892edc14cc..14f6a0e4cb2b9 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -152,7 +152,7 @@ OLTP（オンライン・トランザクション処理）シナリオでは、 #### バッチAPIを使用する {#use-batch-api} -バッチ挿入の場合は、 [`addBatch` / `executeBatch` API](https://docs.oracle.com/en/java/javase/25/docs/api/java.sql/java/sql/Statement.html#executeBatch())を使用できます。3 `addBatch()`は、複数の SQL ステートメントを最初にクライアントにキャッシュし、 `executeBatch`メソッドを呼び出すときにそれらをまとめてデータベースサーバーに送信するために使用されます。 +バッチ挿入の場合は、 [`addBatch` / `executeBatch` API](https://docs.oracle.com/en/java/javase/25/docs/api/java.sql/java/sql/Statement.html#executeBatch())を使用できます。`addBatch()`は、複数の SQL ステートメントを最初にクライアントにキャッシュし、 `executeBatch`メソッドを呼び出すときにそれらをまとめてデータベースサーバーに送信するために使用されます。 > **Note:** > @@ -176,7 +176,7 @@ JDBCでは通常、以下の2つの処理方法が使用されます。 TiDBは両方の方法をサポートしていますが、実装がよりシンプルで実行効率も優れているため、 `FetchSize`から`Integer.MIN_VALUE`に設定する最初の方法を使用することをお勧めします。 -2番目の方法では、TiDBはまずすべてのデータをTiDBノードにロードし、次に`FetchSize`に従ってクライアントにデータを返します。そのため、通常は最初の方法よりも多くのメモリを消費します。3 [`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom) `ON`設定されている場合、TiDBは結果を一時的にハードディスクに書き込む可能性があります。 +2番目の方法では、TiDBはまずすべてのデータをTiDBノードにロードし、次に`FetchSize`に従ってクライアントにデータを返します。そのため、通常は最初の方法よりも多くのメモリを消費します。[`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom)が`ON`に設定されている場合、TiDBは結果を一時的にハードディスクに書き込む可能性があります。 システム変数[`tidb_enable_lazy_cursor_fetch`](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830) `ON`に設定されている場合、TiDB はクライアントがデータを取得するときにのみデータの一部を読み取ろうとします。これによりメモリ使用量が削減されます。詳細および制限事項については、 [`tidb_enable_lazy_cursor_fetch`システム変数の完全な説明](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830)を参照してください。 @@ -230,7 +230,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 #### バッチ関連パラメータ {#batch-related-parameters} -バッチ書き込みを処理する際は、 `rewriteBatchedStatements=true`設定することをお勧めします。3 または`executeBatch()` `addBatch()`使用した後でも、JDBC はデフォルトでは SQL を 1 つずつ送信します。例: +バッチ書き込みを処理する際は、 `rewriteBatchedStatements=true`設定することをお勧めします。`addBatch()`または`executeBatch()`を使用した後でも、JDBC はデフォルトでは SQL を 1 つずつ送信します。例: ```java pstmt = prepare("INSERT INTO `t` (a) values(?)"); @@ -256,7 +256,7 @@ INSERT INTO `t` (`a`) VALUES(12); INSERT INTO `t` (`a`) values(10),(11),(12); ``` -`INSERT`のステートメントの書き換えは、複数の「values」キーワードの後の値を連結して、1つのSQLステートメントにすることです。3 `INSERT`のステートメントに他の違いがある場合は、書き換えることはできません。たとえば、次のようになります。 +`INSERT`のステートメントの書き換えは、複数の「values」キーワードの後の値を連結して、1つのSQLステートメントにすることです。`INSERT`のステートメントに他の違いがある場合は、書き換えることはできません。たとえば、次のようになります。 ```sql INSERT INTO `t` (`a`) VALUES (10) ON DUPLICATE KEY UPDATE `a` = 10; @@ -296,7 +296,7 @@ UPDATE `t` SET `a` = 10 WHERE `id` = 1; UPDATE `t` SET `a` = 11 WHERE `id` = 2; #### タイムアウト関連のパラメータ {#timeout-related-parameters} -TiDB はタイムアウトを制御するために 2 つの MySQL 互換パラメータ ( [`wait_timeout`](/system-variables.md#wait_timeout)と[`max_execution_time`](/system-variables.md#max_execution_time) ) を提供します。これらの 2 つのパラメータはそれぞれ、 Javaアプリケーションとの接続アイドルタイムアウトと接続内の SQL 実行のタイムアウトを制御します。つまり、これらのパラメータは、TiDB とJavaアプリケーション間の接続の最長アイドル時間と最長ビジー時間を制御します。TiDB v5.4 以降、 `wait_timeout`のデフォルト値は`28800`秒で、8 時間です。v5.4 より前の TiDB バージョンでは、デフォルト値は`0`で、タイムアウトは無制限です。11 のデフォルト値は`max_execution_time` `0` 、SQL ステートメントの最大実行時間は無制限であり、 `SELECT`ステートメントすべて ( `SELECT ... FOR UPDATE`を含む) に適用されます。 +TiDB はタイムアウトを制御するために 2 つの MySQL 互換パラメータ ( [`wait_timeout`](/system-variables.md#wait_timeout)と[`max_execution_time`](/system-variables.md#max_execution_time) ) を提供します。これらの 2 つのパラメータはそれぞれ、 Javaアプリケーションとの接続アイドルタイムアウトと接続内の SQL 実行のタイムアウトを制御します。つまり、これらのパラメータは、TiDB とJavaアプリケーション間の接続の最長アイドル時間と最長ビジー時間を制御します。TiDB v5.4 以降、 `wait_timeout`のデフォルト値は`28800`秒で、8 時間です。v5.4 より前の TiDB バージョンでは、デフォルト値は`0`で、タイムアウトは無制限です。`max_execution_time`のデフォルト値は`0`で、SQL ステートメントの最大実行時間は無制限であり、 `SELECT`ステートメントすべて ( `SELECT ... FOR UPDATE`を含む) に適用されます。 デフォルト値の[`wait_timeout`](/system-variables.md#wait_timeout)は比較的大きな値です。トランザクションが開始されてもコミットもロールバックもされないような状況では、ロックの保持時間が長引くのを防ぐために、よりきめ細かな制御と短いタイムアウトが必要になる場合があります。このような場合は、 [`tidb_idle_transaction_timeout`](/system-variables.md#tidb_idle_transaction_timeout-new-in-v760) （TiDB v7.6.0で導入）を使用して、ユーザーセッション内のトランザクションのアイドルタイムアウトを制御できます。 diff --git a/develop/dev-guide-join-tables.md b/develop/dev-guide-join-tables.md index 11a2d98884efe..0ebb5cebe45e8 100644 --- a/develop/dev-guide-join-tables.md +++ b/develop/dev-guide-join-tables.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-join-tables/','/ja/tidbcloud/dev-guide-join # 複数テーブルの結合クエリ {#multi-table-join-queries} -多くのシナリオでは、1つのクエリで複数のテーブルからデータを取得する必要があります。1 `JOIN`ステートメントを使用して、2つ以上のテーブルのデータを結合できます。 +多くのシナリオでは、1つのクエリで複数のテーブルからデータを取得する必要があります。`JOIN`ステートメントを使用して、2つ以上のテーブルのデータを結合できます。 ## 結合タイプ {#join-types} diff --git a/develop/dev-guide-optimize-sql-best-practices.md b/develop/dev-guide-optimize-sql-best-practices.md index dad031a4c803e..06181bcf4ef6f 100644 --- a/develop/dev-guide-optimize-sql-best-practices.md +++ b/develop/dev-guide-optimize-sql-best-practices.md @@ -131,7 +131,7 @@ DELETE FROM t; ### インデックスのベストプラクティスを追加する {#add-index-best-practices} -TiDBはオンラインのインデックス追加操作をサポートしています。1 [インデックスを追加](/sql-statements/sql-statement-add-index.md)または[インデックスの作成](/sql-statements/sql-statement-create-index.md)文でインデックスを追加できます。テーブルへのデータの読み取りと書き込みはブロックされません。以下のシステム変数を変更することで、インデックス追加操作のフェーズ`re-organize`における同時実行性とバッチサイズを調整できます。 +TiDBはオンラインのインデックス追加操作をサポートしています。[インデックスを追加](/sql-statements/sql-statement-add-index.md)または[インデックスの作成](/sql-statements/sql-statement-create-index.md)文でインデックスを追加できます。テーブルへのデータの読み取りと書き込みはブロックされません。以下のシステム変数を変更することで、インデックス追加操作のフェーズ`re-organize`における同時実行性とバッチサイズを調整できます。 - [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) - [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) diff --git a/develop/dev-guide-optimize-sql.md b/develop/dev-guide-optimize-sql.md index bb19a3490b725..cd4330754113b 100644 --- a/develop/dev-guide-optimize-sql.md +++ b/develop/dev-guide-optimize-sql.md @@ -58,7 +58,7 @@ EXPLAIN SELECT * FROM books WHERE title = 'Marian Yost'; +---------------------+------------+-----------+---------------+-----------------------------------------+ ``` -実行プランの`TableFullScan_5`からわかるように、TiDBは`books`番目のテーブルに対してフルテーブルスキャンを実行し、各行について`title`条件を満たすかどうかを確認します。9の`estRows` `TableFullScan_5`の値は`1000000.00`です。これは、オプティマイザがこのフルテーブルスキャンで`1000000.00`行のデータが使用されると見積もっていることを意味します。 +実行プランの`TableFullScan_5`からわかるように、TiDBは`books`テーブルに対してフルテーブルスキャンを実行し、各行について`title`が条件を満たすかどうかを確認します。`TableFullScan_5`の`estRows`の値は`1000000.00`です。これは、オプティマイザがこのフルテーブルスキャンで`1000000.00`行のデータが使用されると見積もっていることを意味します。 `EXPLAIN`の使用方法の詳細については、 [`EXPLAIN`ウォークスルー](/explain-walkthrough.md)参照してください。 @@ -106,7 +106,7 @@ EXPLAIN SELECT * FROM books WHERE title = 'Marian Yost'; +---------------------------+---------+-----------+-------------------------------------+-------------------------------------------------------+ ``` -実行プランの`IndexLookup_10`からわかるように、TiDBは`title_idx`番目のインデックスを使ってデータをクエリします。5 `estRows`の値は`1.27`です。これは、オプティマイザが`1.27`行しかスキャンされないと見積もっていることを意味します。推定されるスキャン行数は、フルテーブルスキャンの`1000000.00`行のデータよりもはるかに少ないです。 +実行プランの`IndexLookup_10`からわかるように、TiDBは`title_idx`番目のインデックスを使ってデータをクエリします。`estRows`の値は`1.27`です。これは、オプティマイザが`1.27`行しかスキャンされないと見積もっていることを意味します。推定されるスキャン行数は、フルテーブルスキャンの`1000000.00`行のデータよりもはるかに少ないです。 実行プラン`IndexLookup_10`では、まず`IndexRangeScan_8`演算子を使用して`title_idx`インデックスを通じて条件を満たすインデックス データを読み取り、次に`TableLookup_9`演算子を使用して、インデックス データに格納されている行 ID に従って対応する行をクエリします。 diff --git a/develop/dev-guide-paginate-results.md b/develop/dev-guide-paginate-results.md index 35cb5cf3fa3dc..29ac3c6448192 100644 --- a/develop/dev-guide-paginate-results.md +++ b/develop/dev-guide-paginate-results.md @@ -260,7 +260,7 @@ ORDER BY page_num; たとえば、次のようにして`ratings`テーブル内のデータのページング バッチを実装できます。 -以下のステートメントを使用してメタ情報テーブルを作成します。5 種類の`book_id`と`user_id`を連結したキーは、同じ長さに変換できないため、 `bigint`の最大ビット数である`LPAD` `bigint`を使用して`0`をパディングします。 +以下のステートメントを使用してメタ情報テーブルを作成します。`bigint`型の`book_id`と`user_id`を連結したキーは、同じ長さに変換できないため、 `bigint`の最大ビット数である 19 に従って`LPAD`関数を使用して`0`をパディングします。 ```sql SELECT diff --git a/develop/dev-guide-prepared-statement.md b/develop/dev-guide-prepared-statement.md index 744013ef926e0..9c8edf7876089 100644 --- a/develop/dev-guide-prepared-statement.md +++ b/develop/dev-guide-prepared-statement.md @@ -130,7 +130,7 @@ try (Connection connection = ds.getConnection()) { ### INSERT例 {#code-insert-code-example} -[`books`](/develop/dev-guide-bookshop-schema-design.md#books-table)を例に挙げると、 `title = TiDB Developer Guide` 、 `type = Science & Technology` 、 `stock = 100` 、 `price = 0.0` 、 `published_at = NOW()` （挿入時の現在時刻）の書籍を挿入する必要があります。17 `books`の**主キー**に`AUTO_RANDOM`属性を指定する必要がないことに注意してください。データの挿入に関する詳細は、 [データの挿入](/develop/dev-guide-insert-data.md)参照してください。 +[`books`](/develop/dev-guide-bookshop-schema-design.md#books-table)を例に挙げると、 `title = TiDB Developer Guide` 、 `type = Science & Technology` 、 `stock = 100` 、 `price = 0.0` 、 `published_at = NOW()` （挿入時の現在時刻）の書籍を挿入する必要があります。`books`の**主キー**に`AUTO_RANDOM`属性を指定する必要がないことに注意してください。データの挿入に関する詳細は、 [データの挿入](/develop/dev-guide-insert-data.md)を参照してください。 diff --git a/develop/dev-guide-sql-development-specification.md b/develop/dev-guide-sql-development-specification.md index 7bbc85e85417d..c75c27a07c32c 100644 --- a/develop/dev-guide-sql-development-specification.md +++ b/develop/dev-guide-sql-development-specification.md @@ -42,7 +42,7 @@ aliases: ['/ja/tidb/stable/dev-guide-sql-development-specification/','/ja/tidbcl ## その他の仕様 {#other-specifications} - 条件`WHERE`のインデックス列に対して数学演算や関数を実行しないでください。 -- `OR` `IN`または`UNION`に置き換えてください。7 の数は`IN` `300`でなければなりません。 +- `OR`を`IN`または`UNION`に置き換えてください。`IN`の数は`300`未満でなければなりません。 - あいまいプレフィックスクエリには`%`プレフィックスを使用しないでください。 - アプリケーションが**マルチステートメント**を使用して SQL を実行する場合、つまり複数の SQL がセミコロンで結合され、一度にクライアントに送信されて実行される場合、TiDB は最初の SQL 実行の結果のみを返します。 - 式を使用する場合は、その式がストレージレイヤー（TiKVまたはTiFlash ）へのコンピューティングのプッシュダウンをサポートしているかどうかを確認してください。サポートされていない場合は、TiDBレイヤーでメモリ消費量が増加し、OOMが発生する可能性が高くなります。ストレージレイヤーにプッシュダウンできるコンピューティングは以下の通りです。 diff --git a/develop/dev-guide-third-party-tools-compatibility.md b/develop/dev-guide-third-party-tools-compatibility.md index e7d8f71c82944..9cd5058d38fdc 100644 --- a/develop/dev-guide-third-party-tools-compatibility.md +++ b/develop/dev-guide-third-party-tools-compatibility.md @@ -125,7 +125,7 @@ TiDB に`enablePacketDebug`パラメータを設定しないでください。 **説明** -TiDB は`UpdatableResultSet`サポートしていません。5 パラメータ`ResultSet.CONCUR_UPDATABLE`指定**しないでください**。また、 `ResultSet`内のデータを更新**しないでください**。 +TiDB は`UpdatableResultSet`サポートしていません。`ResultSet.CONCUR_UPDATABLE`パラメータを指定**しないでください**。また、 `ResultSet`内のデータを更新**しないでください**。 **回避方法** diff --git a/develop/dev-guide-time-to-live.md b/develop/dev-guide-time-to-live.md index 6d7dd1c787479..4b8b42b7d6d8f 100644 --- a/develop/dev-guide-time-to-live.md +++ b/develop/dev-guide-time-to-live.md @@ -38,7 +38,7 @@ CREATE TABLE app_messages ( ) TTL = `created_at` + INTERVAL 3 MONTH; ``` -この例では、 `TTL = ...`有効期限ポリシーを定義します。3 `created_at`には各行の作成時刻が記録され、 `INTERVAL 3 MONTH`各行が最大 3 か月間保持されることを指定します。 +この例では、 `TTL = ...`有効期限ポリシーを定義します。`created_at`には各行の作成時刻が記録され、 `INTERVAL 3 MONTH`各行が最大 3 か月間保持されることを指定します。 ### 既存のテーブルのTTL属性を構成する {#configure-the-ttl-attribute-for-an-existing-table} diff --git a/develop/dev-guide-transaction-overview.md b/develop/dev-guide-transaction-overview.md index 2c292c1649b24..2d13f657a6105 100644 --- a/develop/dev-guide-transaction-overview.md +++ b/develop/dev-guide-transaction-overview.md @@ -61,7 +61,7 @@ BEGIN; START TRANSACTION; ``` -TiDBのデフォルトのトランザクションモードは悲観的です。1 [楽観的トランザクションモデル](/develop/dev-guide-optimistic-and-pessimistic-transaction.md)明示的に指定することもできます。 +TiDBのデフォルトのトランザクションモードは悲観的です。[楽観的トランザクションモデル](/develop/dev-guide-optimistic-and-pessimistic-transaction.md)を明示的に指定することもできます。 ```sql BEGIN OPTIMISTIC; diff --git a/develop/dev-guide-unique-serial-number-generation.md b/develop/dev-guide-unique-serial-number-generation.md index 8c3c2a9eb6c0d..1815266022887 100644 --- a/develop/dev-guide-unique-serial-number-generation.md +++ b/develop/dev-guide-unique-serial-number-generation.md @@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/dev-guide-unique-serial-number-generation/','/ja/tidb ## AUTO_INCREMENT列 {#auto-increment-column} -`AUTO_INCREMENT`は、MySQL プロトコルと互換性のある多くの RDBMS の列属性です。2 属性を使用すると、データベースはユーザーの介入なしにこの列に自動的に値を割り当てることができます。テーブル内のレコード数が増加すると、この列の値は自動的に増加し、一意であることが保証されます。 `AUTO_INCREMENT`のシナリオでは、 `AUTO_INCREMENT`列は実際には意味を持たない代理主キーとして使用されます。 +`AUTO_INCREMENT`は、MySQL プロトコルと互換性のある多くの RDBMS の列属性です。`AUTO_INCREMENT`属性を使用すると、データベースはユーザーの介入なしにこの列に自動的に値を割り当てることができます。テーブル内のレコード数が増加すると、この列の値は自動的に増加し、一意であることが保証されます。 `AUTO_INCREMENT`のシナリオでは、 `AUTO_INCREMENT`列は実際には意味を持たない代理主キーとして使用されます。 `AUTO_INCREMENT`列の制限は、列が整数型でなければならず、割り当てられる値も整数でなければならないことです。アプリケーションで必要なシリアル番号が文字、数字、その他の文字で区切られている場合、ユーザーは`AUTO_INCREMENT`列を通してシリアル番号に必要なAUTO_INCREMENT番号を取得することが困難になります。 diff --git a/develop/dev-guide-unstable-result-set.md b/develop/dev-guide-unstable-result-set.md index 40bfe15ec8bae..343a843aad345 100644 --- a/develop/dev-guide-unstable-result-set.md +++ b/develop/dev-guide-unstable-result-set.md @@ -48,7 +48,7 @@ ORDER BY 3 rows in set (0.00 sec) ``` -`a` . `class`および`a` . `stuname`フィールドは`GROUP BY`文で指定されており、選択された列は`a` . `class` 、 `a` . `stuname` 、 `b` . `courscore`です。23 `GROUP BY`条件に含まれない唯一の列である`b` . `courscore`も、 `max()`関数を使用して一意の値で指定されています。このSQL文を曖昧さなく満たす結果は***1つだけ***あり、これを`FULL GROUP BY`構文と呼びます。 +`a` . `class`および`a` . `stuname`フィールドは`GROUP BY`文で指定されており、選択された列は`a` . `class` 、 `a` . `stuname` 、 `b` . `courscore`です。`GROUP BY`条件に含まれない唯一の列である`b` . `courscore`も、 `max()`関数を使用して一意の値で指定されています。このSQL文を曖昧さなく満たす結果は***1つだけ***あり、これを`FULL GROUP BY`構文と呼びます。 反例として、構文`NON-FULL GROUP BY`があります。例えば、この2つのテーブルに次のSQLクエリを記述します (delete `a` . `stuname` in `GROUP BY` )。 diff --git a/develop/dev-guide-update-data.md b/develop/dev-guide-update-data.md index 8dc3eca7d1295..3b4837f472ad8 100644 --- a/develop/dev-guide-update-data.md +++ b/develop/dev-guide-update-data.md @@ -255,7 +255,7 @@ func placeHolder(n int) string { } ``` -各イテレーションでは、 `SELECT`主キーの順にクエリを実行します。10 ポイントスケールに更新されていない行 ( `1000`は { `ten_point`の最大`false` PLACEHOLDER-1-PLACEHOLDER-E}} まで主キー値を選択します。 `SELECT`ステートメントは、重複を防ぐために、前の`SELECT`の結果の中で最大の主キーよりも大きい主キーを選択します。次に、一括更新を使用して、 `score`列に`2`を掛け、 `ten_point`を`true`に設定します。 `ten_point`を更新する目的は、クラッシュ後に再起動した場合に更新アプリケーションが同じ行を繰り返し更新してデータ破損を引き起こすのを防ぐためです。各ループの`time.Sleep(time.Second)`は、更新アプリケーションがハードウェア リソースを過剰に消費するのを防ぐために、更新アプリケーションを 1 秒間一時停止させます。 +各イテレーションでは、 `SELECT`主キーの順にクエリを実行します。10 ポイントスケールに更新されていない行 ( `ten_point`が`false` ) の主キー値を最大`1000`件まで選択します。 `SELECT`ステートメントは、重複を防ぐために、前の`SELECT`の結果の中で最大の主キーよりも大きい主キーを選択します。次に、一括更新を使用して、 `score`列に`2`を掛け、 `ten_point`を`true`に設定します。 `ten_point`を更新する目的は、クラッシュ後に再起動した場合に更新アプリケーションが同じ行を繰り返し更新してデータ破損を引き起こすのを防ぐためです。各ループの`time.Sleep(time.Second)`は、更新アプリケーションがハードウェア リソースを過剰に消費するのを防ぐために、更新アプリケーションを 1 秒間一時停止させます。 @@ -421,7 +421,7 @@ public class BatchUpdateExample { ``` -各イテレーションでは、 `SELECT`主キーの順にクエリを実行します。10 ポイントスケールに更新されていない行 ( `1000`は { `ten_point`の最大`false` PLACEHOLDER-1-PLACEHOLDER-E}} まで主キー値を選択します。 `SELECT`ステートメントは、重複を防ぐために、前の`SELECT`の結果の中で最大の主キーよりも大きい主キーを選択します。次に、一括更新を使用して、 `score`列に`2`を掛け、 `ten_point`を`true`に設定します。 `ten_point`を更新する目的は、クラッシュ後に再起動した場合に更新アプリケーションが同じ行を繰り返し更新してデータ破損を引き起こすのを防ぐためです。各ループの`TimeUnit.SECONDS.sleep(1);`は、更新アプリケーションがハードウェア リソースを過剰に消費するのを防ぐために、更新アプリケーションを 1 秒間一時停止させます。 +各イテレーションでは、 `SELECT`主キーの順にクエリを実行します。10 ポイントスケールに更新されていない行 ( `ten_point`が`false` ) の主キー値を最大`1000`件まで選択します。 `SELECT`ステートメントは、重複を防ぐために、前の`SELECT`の結果の中で最大の主キーよりも大きい主キーを選択します。次に、一括更新を使用して、 `score`列に`2`を掛け、 `ten_point`を`true`に設定します。 `ten_point`を更新する目的は、クラッシュ後に再起動した場合に更新アプリケーションが同じ行を繰り返し更新してデータ破損を引き起こすのを防ぐためです。各ループの`TimeUnit.SECONDS.sleep(1);`は、更新アプリケーションがハードウェア リソースを過剰に消費するのを防ぐために、更新アプリケーションを 1 秒間一時停止させます。 diff --git a/develop/dev-guide-use-common-table-expression.md b/develop/dev-guide-use-common-table-expression.md index 695c1b562ff56..50fb0494f9592 100644 --- a/develop/dev-guide-use-common-table-expression.md +++ b/develop/dev-guide-use-common-table-expression.md @@ -159,7 +159,7 @@ FROM まず、CTEブロック`books_authored_by_rm`で著者（ID `2299112019` ）が執筆した書籍を調べます。次に、 `books_with_average_ratings`と`books_with_orders`でこれらの書籍の平均評価と順位をそれぞれ求めます。最後に、 `JOIN`ステートメントで結果を集計します。 -`books_authored_by_rm`のクエリは一度だけ実行され、その後 TiDB は結果をキャッシュするための一時領域を作成することに注意してください。3 と`books_with_orders` `books_with_average_ratings`クエリが`books_authored_by_rm`を参照する場合、TiDB はこの一時領域から直接結果を取得します。 +`books_authored_by_rm`のクエリは一度だけ実行され、その後 TiDB は結果をキャッシュするための一時領域を作成することに注意してください。`books_with_average_ratings`と`books_with_orders`のクエリが`books_authored_by_rm`を参照する場合、TiDB はこの一時領域から直接結果を取得します。 > **Tip:** > diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index d998b339c1257..472416ad6d40e 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -249,7 +249,7 @@ hikari: パラメータの説明は以下の通りです。詳細については、 [HikariCPの公式ドキュメント](https://github.com/brettwooldridge/HikariCP/blob/dev/README.md)を参照してください。 -- `maximumPoolSize` : プール内の最大接続数。デフォルト値は`10`です。コンテナ化された環境では、 Javaアプリケーションで使用可能な CPU コア数の 4～10 倍に設定することをお勧めします。この値を高く設定しすぎるとリソースの無駄遣いにつながり、低く設定しすぎると接続の取得が遅くなる可能性があります。 詳細については、を参照[プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)ください。 +- `maximumPoolSize` : プール内の最大接続数。デフォルト値は`10`です。コンテナ化された環境では、 Javaアプリケーションで使用可能な CPU コア数の 4～10 倍に設定することをお勧めします。この値を高く設定しすぎるとリソースの無駄遣いにつながり、低く設定しすぎると接続の取得が遅くなる可能性があります。 詳細については、[プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)を参照してくださいください。 - `minimumIdle` : HikariCPでは、このパラメータを設定しないことを推奨します。デフォルト値は`maximumPoolSize`の値と同じで、接続プールのスケーリングを無効にします。これにより、トラフィックの急増時にも接続がすぐに利用可能になり、接続作成による遅延を回避できます。 - `connectionTimeout` : アプリケーションが接続プールから接続を取得するために待機する最大時間 (ミリ秒)。デフォルト値は`30000`ミリ秒 (30 秒) です。この時間内に利用可能な接続が得られない場合、 `SQLException`例外が発生します。 - `maxLifetime` : プール内の接続の最大有効期間 (ミリ秒)。デフォルト値は`1800000`ミリ秒 (30 分) です。使用中の接続には影響しません。接続が閉じられた後、この設定に従って削除されます。この値を低く設定しすぎると、再接続が頻繁に発生する可能性があります。graceful [`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)使用している場合は、この値が待機時間よりも小さいことを確認してください。 diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index 90d47fd8b66a3..2f6f92256dee6 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -144,7 +144,7 @@ tiup dm deploy dm-test ${version} ./topology.yaml --user root [-p] [-i /home/roo - DMクラスタのバージョンは`${version}`です。TiUPでサポートされている最新バージョンを確認するには、 `tiup list dm-master`実行します。 - 初期化構成ファイルは`topology.yaml`です。 - `--user root` : `root`キーを使用してターゲット マシンにログインし、クラスターの展開を完了するか、 `ssh`および`sudo`権限を持つ他のユーザーを使用して展開を完了することができます。 -- `[-i]`と`[-p]` : オプション。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。4 `[-i]` 、ターゲットマシンにアクセスできる`root`ユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。10 `[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 +- `[-i]`と`[-p]` : オプション。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。`[-i]` 、ターゲットマシンにアクセスできる`root`ユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。10 `[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 - TiUP DMは組み込みのSSHクライアントを使用します。制御マシンシステムにネイティブのSSHクライアントを使用する場合は、 [システムのネイティブSSHクライアントを使用してクラスターに接続する](/dm/maintain-dm-using-tiup.md#use-the-systems-native-ssh-client-to-connect-to-cluster)に従って設定を編集してください。 出力ログの最後に``Deployed cluster `dm-test` successfully``表示されます。これは、デプロイメントが成功したことを示します。 diff --git a/dm/deploy-a-dm-cluster-using-tiup.md b/dm/deploy-a-dm-cluster-using-tiup.md index 07b9624e179cd..9b62e82daa14d 100644 --- a/dm/deploy-a-dm-cluster-using-tiup.md +++ b/dm/deploy-a-dm-cluster-using-tiup.md @@ -141,7 +141,7 @@ alertmanager_servers: > - TiUPノードは、すべての DM マスター ノードの`port` (デフォルトでは`8261` ) に接続できます。 > - TiUPノードは、すべての DM ワーカー ノードの`port` (デフォルトでは`8262` ) に接続できます。 -`master_servers.host.config`パラメータの詳細については[マスターパラメータ](https://github.com/pingcap/tiflow/blob/release-8.5/dm/master/dm-master.toml)を参照してください。5 `worker_servers.host.config`のパラメータの詳細については[ワーカーパラメータ](https://github.com/pingcap/tiflow/blob/release-8.5/dm/worker/dm-worker.toml)を参照してください。 +`master_servers.host.config`パラメータの詳細については[マスターパラメータ](https://github.com/pingcap/tiflow/blob/release-8.5/dm/master/dm-master.toml)を参照してください。`worker_servers.host.config`のパラメータの詳細については[ワーカーパラメータ](https://github.com/pingcap/tiflow/blob/release-8.5/dm/worker/dm-worker.toml)を参照してください。 ## ステップ3: デプロイメントコマンドを実行する {#step-3-execute-the-deployment-command} diff --git a/dm/dm-block-allow-table-lists.md b/dm/dm-block-allow-table-lists.md index 0f60f1fa9824e..06e27956a6f6b 100644 --- a/dm/dm-block-allow-table-lists.md +++ b/dm/dm-block-allow-table-lists.md @@ -36,7 +36,7 @@ block-allow-list: # Use black-white-list if the DM version is earlie シンプルなシナリオでは、スキーマとテーブルのマッチングにワイルドカードを使用することをお勧めします。ただし、以下のバージョンの違いにご注意ください。 -- `*` `[]`含むワイルドカードがサポートされています。ワイルドカードマッチでは`*`記号は1 `?`だけ使用でき、末尾になければなりません。例えば、 `tbl-name: "t*"`の場合、 `"t*"` `t`で始まるすべてのテーブルを表します。詳細は[ワイルドカードマッチング](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax)参照してください。 +- `*` 、 `?` 、 `[]`を含むワイルドカードがサポートされています。ワイルドカードマッチでは`*`記号は1つだけ使用でき、末尾になければなりません。例えば、 `tbl-name: "t*"`の場合、 `"t*"`は`t`で始まるすべてのテーブルを表します。詳細は[ワイルドカードマッチング](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax)を参照してください。 - 正規表現は`~`文字で始まる必要があります。 @@ -44,8 +44,8 @@ block-allow-list: # Use black-white-list if the DM version is earlie - `do-dbs` : MySQL の[`replicate-do-db`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-do-db)と同様に、移行するスキーマのリストを許可します。 - `ignore-dbs` : 移行するスキーマのブロック リスト (MySQL の[`replicate-ignore-db`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-ignore-db)に類似)。 -- `do-tables` : 移行するテーブルのリストを許可します（MySQLの[`replicate-do-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-do-table)に相当）。4と`tbl-name` `db-name`を指定する必要があります。 -- `ignore-tables` : 移行対象テーブルのブロックリスト（MySQLの[`replicate-ignore-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-ignore-table)に相当）。4と`tbl-name` `db-name`を指定する必要があります。 +- `do-tables` : 移行するテーブルのリストを許可します（MySQLの[`replicate-do-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-do-table)に相当）。`db-name`と`tbl-name`の両方を指定する必要があります。 +- `ignore-tables` : 移行対象テーブルのブロックリスト（MySQLの[`replicate-ignore-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-ignore-table)に相当）。`db-name`と`tbl-name`の両方を指定する必要があります。 上記のパラメータの値が`~`文字で始まる場合、その値の以降の文字は[正規表現](https://golang.org/pkg/regexp/syntax/#hdr-syntax)として扱われます。このパラメータは、スキーマ名またはテーブル名を一致させるために使用できます。 diff --git a/dm/dm-command-line-flags.md b/dm/dm-command-line-flags.md index bb1411fc9d53e..96c7bf97959f1 100644 --- a/dm/dm-command-line-flags.md +++ b/dm/dm-command-line-flags.md @@ -13,13 +13,13 @@ summary: DM のコマンドライン フラグについて学習します。 - クライアントのリクエストを受信するために使用されるDMマスターの外部アドレス - デフォルト値は`"{master-addr}"`です -- オプションフラグ。1の形式をとることができます`"domain-name:port"` +- オプションフラグ。`"domain-name:port"`の形式をとることができます。 ### `--advertise-peer-urls` {#advertise-peer-urls} - DMマスターノード間の通信用の外部アドレス - デフォルト値は`"{peer-urls}"`です -- オプションフラグ。1の形式をとることができます`"http(s)://domain-name:port"` +- オプションフラグ。`"http(s)://domain-name:port"`の形式をとることができます。 ### `--config` {#config} @@ -87,7 +87,7 @@ summary: DM のコマンドライン フラグについて学習します。 - クライアントのリクエストを受信するために使用されるDMワーカーの外部アドレス - デフォルト値は`"{worker-addr}"`です -- オプションフラグ。1の形式をとることができます`"domain-name:port"` +- オプションフラグ。`"domain-name:port"`の形式をとることができます。 ### `--config` {#config} diff --git a/dm/dm-config-overview.md b/dm/dm-config-overview.md index c130f9f79aa8f..5751a1e2fceb3 100644 --- a/dm/dm-config-overview.md +++ b/dm/dm-config-overview.md @@ -29,6 +29,6 @@ summary: このドキュメントでは、データ移行構成ファイルの | コンセプト | 説明 | コンフィグレーションファイル | | :---------- | :-------------------------------------------------------------------------- | :--------------------------------------------------------- | -| `source-id` | MySQLまたはMariaDBインスタンス、あるいはプライマリ/セカンダリ構造の移行グループを一意に表します。1の最大長は`source-id`です。 | `source_id` / `source.yaml` ;
`task.yaml`中`source-id` | +| `source-id` | MySQLまたはMariaDBインスタンス、あるいはプライマリ/セカンダリ構造の移行グループを一意に表します。`source-id`の最大長は32です。 | `source_id` / `source.yaml` ;
`task.yaml`中`source-id` | | DMマスターID | DMマスターを一意に表す（ `dm-master.toml`の`master-addr`パラメータによって） | `master-addr` / `dm-master.toml` | | DMワーカーID | DMワーカーを一意に表す（ `dm-worker.toml`の`worker-addr`のパラメータによって） | `worker-addr` / `dm-worker.toml` | diff --git a/dm/dm-continuous-data-validation.md b/dm/dm-continuous-data-validation.md index 7689f54b6da30..db547db263c92 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` : 継続的検証を有効にするタスク名を指定します。`--all-task`を指定すると、すべてのタスクに対して検証が有効になります。 例えば： @@ -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` : エラー行をクリアします。`show-error`コマンドを実行すると、エラー行は表示されなくなります。 Usage: dmctl validation clear-error [flags] diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md index 131fe19e62965..b1f6da8c45c85 100644 --- a/dm/dm-error-handling.md +++ b/dm/dm-error-handling.md @@ -158,7 +158,7 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ 2. `stop-task`使用して移行タスクを停止します。 -3. グローバル チェックポイントとダウンストリーム`dm_meta`データベースの各テーブル チェックポイントの`binlog_name` 、エラーのあるbinlogファイルの名前に更新します。5 `binlog_pos` 、移行が完了した有効な位置の値 (例: 4) に更新します。 +3. グローバル チェックポイントとダウンストリーム`dm_meta`データベースの各テーブル チェックポイントの`binlog_name` 、エラーのあるbinlogファイルの名前に更新します。`binlog_pos` 、移行が完了した有効な位置の値 (例: 4) に更新します。 例：エラーが発生したタスクの名前が`dm_test` 、対応するタスク`source-id`が`replica-1` 、対応するbinlogファイルが`mysql-bin|000001.004451`場合、次のコマンドを実行します。 @@ -182,7 +182,7 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ #### 理由 {#reasons} -- MySQLクライアントとMySQL/TiDBサーバーの両方に`max_allowed_packet`クォータ制限があります。3 `max_allowed_packet`いずれかが制限を超えると、クライアントはエラーメッセージを受け取ります。現在、最新バージョンのDMとTiDBサーバーでは、デフォルト値は`max_allowed_packet`ではなく`64M`です。 +- MySQLクライアントとMySQL/TiDBサーバーの両方に`max_allowed_packet`のクォータ制限があります。`max_allowed_packet`のいずれかが制限を超えると、クライアントはエラーメッセージを受け取ります。現在、最新バージョンのDMとTiDBサーバーでは、`max_allowed_packet`のデフォルト値は`64M`です。 - DM の完全データ インポート処理ユニットは、DM のダンプ処理ユニットによってエクスポートされた SQL ファイルの分割をサポートしていません。 diff --git a/dm/dm-faq.md b/dm/dm-faq.md index f610439f922af..d20c329f6237d 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -16,11 +16,11 @@ Alibaba Cloud RDS の主キーのないアップストリーム テーブルの 互換性に関する既知の問題は次のとおりです。 - **Alibaba Cloud RDS**では、主キーのないアップストリーム テーブルの場合、そのbinlog には非表示の主キー列がまだ含まれており、元のテーブル構造と一致していません。 -- **HUAWEI Cloud RDS**では、 binlogファイルの直接読み取りはサポートされていません。詳細については、 [HUAWEI Cloud RDS はBinlogバックアップファイルを直接読み取ることができますか?](https://support.huaweicloud.com/en-us/rds_faq/rds_faq_0210.html)参照してください。 +- **HUAWEI Cloud RDS**では、 binlogファイルの直接読み取りはサポートされていません。詳細については、 [HUAWEI Cloud RDS はBinlogバックアップファイルを直接読み取ることができますか?](https://support.huaweicloud.com/en-us/rds_faq/rds_faq_0210.html)を参照してください。 -## タスク構成のブロックおよび許可リストの正規表現は、 non-capturing (?!) ? {#does-the-regular-expression-of-the-block-and-allow-list-in-the-task-configuration-support-code-non-capturing-code} +## タスク構成のブロックおよび許可リストの正規表現は、 non-capturing (?!) ? {#does-the-regular-expression-of-the-block-and-allow-list-in-the-task-configuration-support-non-capturing-} -現在、DMはこれをサポートしておらず、 Golang標準ライブラリの正規表現のみをサポートしています。Golangでサポートされている正規表現については、 [re2構文](https://github.com/google/re2/wiki/Syntax)参照してください。 +現在、DMはこれをサポートしておらず、 Golang標準ライブラリの正規表現のみをサポートしています。Golangでサポートされている正規表現については、 [re2構文](https://github.com/google/re2/wiki/Syntax)を参照してください。 ## アップストリームで実行されたステートメントに複数の DDL 操作が含まれている場合、DM はそのような移行をサポートしますか? {#if-a-statement-executed-upstream-contains-multiple-ddl-operations-does-dm-support-such-migration} @@ -28,11 +28,11 @@ DMは、複数のDDL変更操作を含む単一のステートメントを、1 ## 互換性のない DDL ステートメントをどのように処理しますか? {#how-to-handle-incompatible-ddl-statements} -TiDBでサポートされていないDDL文に遭遇した場合は、dmctlを使用して手動で処理する必要があります（DDL文をスキップするか、指定されたDDL文に置き換えます）。詳細は[失敗したDDLステートメントを処理する](/dm/handle-failed-ddl-statements.md)参照してください。 +TiDBでサポートされていないDDL文に遭遇した場合は、dmctlを使用して手動で処理する必要があります（DDL文をスキップするか、指定されたDDL文に置き換えます）。詳細は[失敗したDDLステートメントを処理する](/dm/handle-failed-ddl-statements.md)を参照してください。 > **Note:** > -> 現在、TiDBはMySQLがサポートするすべてのDDL文と互換性がありません[MySQLの互換性](/mysql-compatibility.md#ddl-operations)参照してください。 +> 現在、TiDBはMySQLがサポートするすべてのDDL文と互換性があるわけではありません[MySQLの互換性](/mysql-compatibility.md#ddl-operations)を参照してください。 ## DM はビュー関連の DDL ステートメントと DML ステートメントを TiDB に複製しますか? {#does-dm-replicate-view-related-ddl-statements-and-dml-statements-to-tidb} @@ -48,10 +48,10 @@ 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} +## online-ddl: trueを設定した後、gh-ost テーブルに関連する DDL 操作によって返されたエラーをどのように処理しますか? {#how-to-handle-the-error-returned-by-the-ddl-operation-related-to-the-gh-ost-table-after-online-ddl-true-is-set} [unit=Sync] ["error information"="{\"msg\":\"[code=36046:class=sync-unit:scope=internal:level=high] online ddls on ghost table `xxx`.`_xxxx_gho`\\ngithub.com/pingcap/tiflow/pkg/terror.(*Error).Generate ...... @@ -84,17 +84,17 @@ TiDBでサポートされていないDDL文に遭遇した場合は、dmctlを > > 既存のデータ移行タスクにテーブルを追加するのは複雑なため、必要な場合にのみこの操作を実行することをお勧めします。 -### Dump段階 {#in-the-code-dump-code-stage} +### Dump段階 {#in-the-dump-stage} MySQLはエクスポート時にスナップショットを指定できないため、エクスポート中にデータ移行タスクを更新し、その後再起動してチェックポイントからエクスポートを再開することができません。そのため、第`Dump`ステージで移行が必要なテーブルを動的に追加することはできません。 移行のためにテーブルを追加する必要がある場合は、新しい構成ファイルを使用してタスクを直接再起動することをお勧めします。 -### Loadステージ {#in-the-code-load-code-stage} +### Loadステージ {#in-the-load-stage} エクスポート中、複数のデータ移行タスクは通常、異なるbinlogの位置を持ちます。第`Load`ステージでタスクをマージすると、binlogの位置について合意が得られない可能性があります。そのため、第`Load`ステージでデータ移行タスクにテーブルを追加することは推奨されません。 -### Sync段階では {#in-the-code-sync-code-stage} +### Sync段階では {#in-the-sync-stage} データ移行タスクが第`Sync`ステージにあるときに、設定ファイルにテーブルを追加してタスクを再開すると、DMは新しく追加されたテーブルに対して完全なエクスポートとインポートを再実行しません。代わりに、DMは前回のチェックポイントから増分レプリケーションを継続します。 @@ -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)`です。 @@ -116,26 +116,26 @@ MySQLはエクスポート時にスナップショットを指定できないた 4. `start-task`を使用してタスクを開始します。 -5. `query-status`までタスクの状態を観察します。3 `syncerBinlog` `checkpoint-T`と`checkpoint-S`のうち大きい方の値を超えた場合、 `safe-mode`元の値に戻し、タスクを再開します。この例では`(mysql-bin.000100, 1234)`です。 +5. `query-status`までタスクの状態を観察します。`syncerBinlog` `checkpoint-T`と`checkpoint-S`のうち大きい方の値を超えた場合、 `safe-mode`元の値に戻し、タスクを再開します。この例では`(mysql-bin.000100, 1234)`です。 -## packet for query is too large. Try adjusting the 'max_allowed_packet' variable ？ {#how-to-handle-the-error-code-packet-for-query-is-too-large-try-adjusting-the-max-allowed-packet-variable-code-that-occurs-during-the-full-import} +## packet for query is too large. Try adjusting the 'max_allowed_packet' variable ？ {#how-to-handle-the-error-packet-for-query-is-too-large-try-adjusting-the-max_allowed_packet-variable-that-occurs-during-the-full-import} 以下のパラメータをデフォルトの 67108864 (64M) より大きい値に設定します。 - TiDBサーバーのグローバル変数: `max_allowed_packet` 。 - タスク設定ファイル内の設定項目： `target-database.max-allowed-packet` 。詳細は[DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 -## DM 1.0 クラスターの既存の DM 移行タスクが DM 2.0 以降のクラスターで実行されているときに発生するエラーError 1054: Unknown column 'binlog_gtid' in 'field list'を処理する方法を教えてください。 {#how-to-handle-the-error-code-error-1054-unknown-column-binlog-gtid-in-field-list-code-that-occurs-when-existing-dm-migration-tasks-of-an-dm-1-0-cluster-are-running-on-a-dm-2-0-or-newer-cluster} +## DM 1.0 クラスターの既存の DM 移行タスクが DM 2.0 以降のクラスターで実行されているときに発生するエラーError 1054: Unknown column 'binlog_gtid' in 'field list'を処理する方法を教えてください。 {#how-to-handle-the-error-error-1054-unknown-column-binlog_gtid-in-field-list-that-occurs-when-existing-dm-migration-tasks-of-an-dm-10-cluster-are-running-on-a-dm-20-or-newer-cluster} DM v2.0 以降、増分データレプリケーションを続行するために DM 1.0 クラスターのタスク構成ファイルで`start-task`コマンドを直接実行すると、エラー`Error 1054: Unknown column 'binlog_gtid' in 'field list'`が発生します。 このエラーは[DM 1.0 クラスターの DM 移行タスクを DM 2.0 クラスターに手動でインポートする](/dm/manually-upgrade-dm-1.0-to-2.0.md)で処理できます。 -## TiUP がDM の一部のバージョン (たとえば、v2.0.0-hotfix) の展開に失敗するのはなぜですか? {#why-does-tiup-fail-to-deploy-some-versions-of-dm-for-example-v2-0-0-hotfix} +## TiUP がDM の一部のバージョン (たとえば、v2.0.0-hotfix) の展開に失敗するのはなぜですか? {#why-does-tiup-fail-to-deploy-some-versions-of-dm-for-example-v200-hotfix} `tiup list dm-master`コマンドを使用すると、 TiUP がデプロイをサポートしている DM バージョンを表示できます。このコマンドで表示されない DM バージョンはTiUP管理されません。 -## DM がデータを複製しているときに発生するエラーparse mydumper metadata error: EOFを処理するにはどうすればよいですか? {#how-to-handle-the-error-code-parse-mydumper-metadata-error-eof-code-that-occurs-when-dm-is-replicating-data} +## DM がデータを複製しているときに発生するエラーparse mydumper metadata error: EOFを処理するにはどうすればよいですか? {#how-to-handle-the-error-parse-mydumper-metadata-error-eof-that-occurs-when-dm-is-replicating-data} このエラーをさらに分析するには、エラーメッセージとログファイルを確認してください。原因としては、権限不足のためにダンプユニットが正しいメタデータファイルを生成していないことが考えられます。 @@ -143,18 +143,18 @@ DM v2.0 以降、増分データレプリケーションを続行するために 構成項目`block-allow-list`と`table-route`を確認します。 -- `block-allow-list`下にある上流のデータベースとテーブルの名前を設定する必要があります。3 `do-tables`前に「~」を追加すると、正規表現を使用して名前を一致させることができます。 +- `block-allow-list`の下にある上流のデータベースとテーブルの名前を設定する必要があります。`do-tables`の前に「~」を追加すると、正規表現を使用して名前を一致させることができます。 - `table-route` 、テーブル名の一致に正規表現ではなくワイルドカード文字を使用します。例えば、 `table_parttern_[0-63]` `table_parttern_0`から`table_pattern_6`までの 7 つのテーブルのみに一致します。 -## DM がアップストリームからレプリケートしていないのに、 replicate lagモニター メトリックにデータが表示されないのはなぜですか? {#why-does-the-code-replicate-lag-code-monitor-metric-show-no-data-when-dm-is-not-replicating-from-upstream} +## DM がアップストリームからレプリケートしていないのに、 replicate lagモニター メトリックにデータが表示されないのはなぜですか? {#why-does-the-replicate-lag-monitor-metric-show-no-data-when-dm-is-not-replicating-from-upstream} DM 1.0では、監視データを生成するには`enable-heartbeat`有効にする必要があります。DM 2.0以降のバージョンでは、この機能はサポートされていないため、監視メトリック`replicate lag`にはデータが存在しないことが想定されます。 -## DM がタスクを開始しているときに、 context deadline exceededを示すエラー メッセージのRawCauseでfail to initial unit Sync of subtaskエラーを処理する方法を教えてください。 {#how-to-handle-the-error-code-fail-to-initial-unit-sync-of-subtask-code-when-dm-is-starting-a-task-with-the-code-rawcause-code-in-the-error-message-showing-code-context-deadline-exceeded-code} +## DM がタスクを開始しているときに、 context deadline exceededを示すエラー メッセージのRawCauseでfail to initial unit Sync of subtaskエラーを処理する方法を教えてください。 {#how-to-handle-the-error-fail-to-initial-unit-sync-of-subtask-when-dm-is-starting-a-task-with-the-rawcause-in-the-error-message-showing-context-deadline-exceeded} これはDM 2.0.0バージョンの既知の問題であり、DM 2.0.1バージョンで修正される予定です。レプリケーションタスクで処理するテーブル数が多い場合に発生する可能性があります。TiUPを使用してDMをデプロイしている場合は、DMをナイトリーバージョンにアップグレードすることでこの問題を修正できます。または、GitHubの[DMのリリースページ](https://github.com/pingcap/tiflow/releases)から2.0.0-hotfixバージョンをダウンロードし、実行ファイルを手動で置き換えることもできます。 -## DM がデータを複製しているときにduplicate entryエラーを処理するにはどうすればよいでしょうか? {#how-to-handle-the-error-code-duplicate-entry-code-when-dm-is-replicating-data} +## DM がデータを複製しているときにduplicate entryエラーを処理するにはどうすればよいでしょうか? {#how-to-handle-the-error-duplicate-entry-when-dm-is-replicating-data} まず、以下の点を確認して確認する必要があります。 @@ -173,13 +173,13 @@ curl -X POST -d "tidb_general_log=0" http://{TiDBIP}:10080/settings `duplicate entry`エラーが発生した場合は、競合データを含むレコードのログ ファイルを確認する必要があります。 -## 一部の監視パネルにNo data pointと表示されるのはなぜですか? {#why-do-some-monitoring-panels-show-code-no-data-point-code} +## 一部の監視パネルにNo data pointと表示されるのはなぜですか? {#why-do-some-monitoring-panels-show-no-data-point} -一部のパネルにデータが表示されないのは正常です。例えば、エラーが報告されていない場合、DDLロックがない場合、またはリレーログ機能が有効になっていない場合、対応するパネルには`No data point`表示されます。各パネルの詳細については、 [DM モニタリング メトリック](/dm/monitor-a-dm-cluster.md)参照してください。 +一部のパネルにデータが表示されないのは正常です。例えば、エラーが報告されていない場合、DDLロックがない場合、またはリレーログ機能が有効になっていない場合、対応するパネルには`No data point`が表示されます。各パネルの詳細については、 [DM モニタリング メトリック](/dm/monitor-a-dm-cluster.md)を参照してください。 -## 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} +## DM v1.0 では、タスクにエラーがある場合にコマンドsql-skip一部のステートメントをスキップできないのはなぜですか? {#in-dm-v10-why-does-the-command-sql-skip-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 文を送信しているためです。`sql-skip -s `を使用して、これらの文に一致するパターンを設定できます。 場合によっては、エラー メッセージに`parse statement`情報が含まれます。次に例を示します。 @@ -189,13 +189,13 @@ curl -X POST -d "tidb_general_log=0" http://{TiDBIP}:10080/settings DM v6.0以降、 `sql-skip`と`handle-error`が`binlog`に置き換えられました。この問題を回避するには、代わりに`binlog`コマンドを使用してください。 -## DM がレプリケートされているときに、ダウンストリームにREPLACEステートメントが表示され続けるのはなぜですか? {#why-do-code-replace-code-statements-keep-appearing-in-the-downstream-when-dm-is-replicating} +## DM がレプリケートされているときに、ダウンストリームにREPLACEステートメントが表示され続けるのはなぜですか? {#why-do-replace-statements-keep-appearing-in-the-downstream-when-dm-is-replicating} タスクに対して[セーフモード](/dm/dm-glossary.md#safe-mode)が自動的に有効になっているかどうかを確認する必要があります。エラー発生後にタスクが自動的に再開される場合、または高可用性スケジュールが設定されている場合は、タスクの開始または再開から1分以内であるため、セーフモードが有効になっています。 DM-worker のログファイルを確認し、 `change count`含む行を探してください。その行の`new count` 0 でない場合、セーフモードが有効になっています。セーフモードが有効になっている理由を確認するには、セーフモードがいつ発生するか、またそれ以前にエラーが報告されているかどうかを確認してください。 -## DM v2.0 では、タスク中に DM が再起動すると、完全インポート タスクが失敗するのはなぜですか? {#in-dm-v2-0-why-does-the-full-import-task-fail-if-dm-restarts-during-the-task} +## DM v2.0 では、タスク中に DM が再起動すると、完全インポート タスクが失敗するのはなぜですか? {#in-dm-v20-why-does-the-full-import-task-fail-if-dm-restarts-during-the-task} DM v2.0.1 以前のバージョンでは、完全インポートが完了する前に DM が再起動すると、上流のデータソースと DM ワーカーノード間のバインディングが変更される可能性があります。例えば、ダンプユニットの中間データが DM ワーカーノード A にあるにもかかわらず、ロードユニットが DM ワーカーノード B で実行されている場合、操作が失敗する可能性があります。 @@ -218,7 +218,7 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する - `task-mode`を`incremental`に変更します。 - ダンプユニットが出力するメタデータファイルに記録されている位置に値`mysql-instance.meta.pos`を設定します。 -## 増分タスク中に再起動すると、DM がエラーERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.はなぜですか? {#why-does-dm-report-the-error-code-error-1236-hy000-the-slave-is-connecting-using-change-master-to-master-auto-position-1-but-the-master-has-purged-binary-logs-containing-gtids-that-the-slave-requires-code-if-it-restarts-during-an-incremental-task} +## 増分タスク中に再起動すると、DM がエラーERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.はなぜですか? {#why-does-dm-report-the-error-error-1236-hy000-the-slave-is-connecting-using-change-master-to-master_auto_position--1-but-the-master-has-purged-binary-logs-containing-gtids-that-the-slave-requires-if-it-restarts-during-an-incremental-task} このエラーは、ダンプ ユニットによって出力されたメタデータ ファイルに記録されたアップストリームbinlogの位置が、完全な移行中に消去されたことを示します。 @@ -229,7 +229,7 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する 1. 移行タスクが完了する前に必要なbinlogファイルが誤って削除されるのを防ぐため、上流のMySQLデータベースの値を`expire_logs_days`に増やしてください。データ量が多い場合は、タスクを高速化するために、DumplingとTiDB Lightningを同時に使用することをお勧めします。 2. このタスクのリレー ログ機能を有効にすると、binlogの位置が消去されていても DM がリレー ログからデータを読み取ることができます。 -## クラスターがTiUP v1.3.0 または v1.3.1 を使用してデプロイされている場合、DM クラスターの Grafana ダッシュボードに「 failed to fetch dashboard表示されるのはなぜですか? {#why-does-the-grafana-dashboard-of-a-dm-cluster-display-code-failed-to-fetch-dashboard-code-if-the-cluster-is-deployed-using-tiup-v1-3-0-or-v1-3-1} +## クラスターがTiUP v1.3.0 または v1.3.1 を使用してデプロイされている場合、DM クラスターの Grafana ダッシュボードに「 failed to fetch dashboard表示されるのはなぜですか? {#why-does-the-grafana-dashboard-of-a-dm-cluster-display-failed-to-fetch-dashboard-if-the-cluster-is-deployed-using-tiup-v130-or-v131} これはTiUPの既知のバグで、 TiUP v1.3.2 で修正されています。この問題に対する解決策は以下の2つです。 @@ -241,9 +241,9 @@ 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} +## DM v2.0 では、タスクでenable-relayとenable-gtid同時に有効になっている場合、コマンドquery-statusのクエリ結果に、Syncer チェックポイント GTID が連続していないと表示されるのはなぜですか? {#in-dm-v20-why-does-the-query-result-of-the-command-query-status-show-that-the-syncer-checkpoint-gtids-are-inconsecutive-if-the-task-has-enable-relay-and-enable-gtid-enabled-at-the-same-time} これはDMの既知のバグで、DM v2.0.2で修正されています。このバグは、以下の2つの条件が同時に満たされた場合に発生します。 @@ -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 { @@ -346,7 +346,7 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する 上記の 1 番目と 2 番目のソリューションで正常にレプリケートできるデータ ソース (上記の例の`mysql2`など) の場合は、増分タスクを設定するときに、 `subTaskStatus.sync`の`syncerBinlog`と`syncerBinlogGtid`情報を使用して関連する`mysql-instances.meta`構成します。 -## DM v2.0 では、 heartbeat機能が有効になっている仮想 IP 環境で DM ワーカーと MySQL インスタンス間の接続を切り替えるときに、「ハートビート構成が以前使用したものと異なります: serverID が等しくありません」というエラーをどのように処理すればよいですか? {#in-dm-v2-0-how-do-i-handle-the-error-heartbeat-config-is-different-from-previous-used-serverid-not-equal-when-switching-the-connection-between-dm-workers-and-mysql-instances-in-a-virtual-ip-environment-with-the-code-heartbeat-code-feature-enabled} +## DM v2.0 では、 heartbeat機能が有効になっている仮想 IP 環境で DM ワーカーと MySQL インスタンス間の接続を切り替えるときに、「ハートビート構成が以前使用したものと異なります: serverID が等しくありません」というエラーをどのように処理すればよいですか? {#in-dm-v20-how-do-i-handle-the-error-heartbeat-config-is-different-from-previous-used-serverid-not-equal-when-switching-the-connection-between-dm-workers-and-mysql-instances-in-a-virtual-ip-environment-with-the-heartbeat-feature-enabled} DM v2.0以降のバージョンでは、 `heartbeat`機能はデフォルトで無効になっています。タスク設定ファイルでこの機能を有効にすると、高可用性機能に支障をきたします。この問題を解決するには、タスク設定ファイルで`enable-heartbeat`を`false`に設定して`heartbeat`機能を無効にし、その後タスク設定ファイルをリロードしてください。DMは、以降のリリースで`heartbeat`機能を強制的に無効にします。 @@ -368,7 +368,7 @@ dmctl execute コマンドを使用すると、DM マスターへの接続に失 > > `proxy`に関連する環境変数には`http_proxy` 、 `https_proxy` 、 `no_proxy`があります。上記の手順を実行しても接続エラーが解決しない場合は、 `http_proxy`と`no_proxy`の設定パラメータが正しいかどうかを確認してください。 -## DM バージョン 2.0.2 から 2.0.6 で start-relay コマンドを実行したときに返されるエラーを処理するにはどうすればよいですか? {#how-to-handle-the-returned-error-when-executing-start-relay-command-for-dm-versions-from-2-0-2-to-2-0-6} +## DM バージョン 2.0.2 から 2.0.6 で start-relay コマンドを実行したときに返されるエラーを処理するにはどうすればよいですか? {#how-to-handle-the-returned-error-when-executing-start-relay-command-for-dm-versions-from-202-to-206} flush local meta, Rawcause: open relay-dir/xxx.000001/relay.metayyyy: no such file or directory @@ -386,6 +386,6 @@ dmctl execute コマンドを使用すると、DM マスターへの接続に失 - DM を v2.0.7 以降のバージョンにアップグレードします。 -## ロード ユニットがUnknown character setエラーを報告するのはなぜですか? {#why-does-the-load-unit-report-the-code-unknown-character-set-code-error} +## ロード ユニットがUnknown character setエラーを報告するのはなぜですか? {#why-does-the-load-unit-report-the-unknown-character-set-error} -TiDBはMySQLのすべての文字セットをサポートしていません。そのため、フルインポート中にテーブルスキーマを作成する際にサポートされていない文字セットが使用されると、DMはこのエラーを報告します。このエラーを回避するには、特定のデータに応じて、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)を使用して下流で事前にテーブルスキーマを作成してください。 +TiDBはMySQLのすべての文字セットをサポートしているわけではありません。そのため、フルインポート中にテーブルスキーマを作成する際にサポートされていない文字セットが使用されると、DMはこのエラーを報告します。このエラーを回避するには、特定のデータに応じて、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)を使用して下流で事前にテーブルスキーマを作成してください。 diff --git a/dm/dm-glossary.md b/dm/dm-glossary.md index 9b35617f3f4a9..85b6e12647a83 100644 --- a/dm/dm-glossary.md +++ b/dm/dm-glossary.md @@ -94,7 +94,7 @@ TiDB データ移行ツールを使用して、上流データベースの**増 ### セーフモード {#safe-mode} -セーフモードは、テーブルスキーマに主キーまたは一意インデックスが存在する場合に、DML文を複数回インポートできるモードです。このモードでは、上流の文の一部は、書き換えられた後にのみ下流に移行されます。1 `INSERT`文は`REPLACE`に書き換えられ、 `UPDATE`文は`DELETE`と`REPLACE`に書き換えられます。 +セーフモードは、テーブルスキーマに主キーまたは一意インデックスが存在する場合に、DML文を複数回インポートできるモードです。このモードでは、上流の文の一部は、書き換えられた後にのみ下流に移行されます。`INSERT`文は`REPLACE`に書き換えられ、 `UPDATE`文は`DELETE`と`REPLACE`に書き換えられます。 このモードは、次のいずれかの状況で有効になります。 diff --git a/dm/dm-handle-performance-issues.md b/dm/dm-handle-performance-issues.md index f778206ee21b5..347f55d2f7dd4 100644 --- a/dm/dm-handle-performance-issues.md +++ b/dm/dm-handle-performance-issues.md @@ -47,7 +47,7 @@ DMのリレー処理ユニットは、binlogイベントをDMメモリに読み ### リレーログファイルを書き込む {#write-relay-log-files} -binlogイベントをリレーログファイルに書き込む場合、関連するパフォーマンスメトリックは`write relay log duration`です。3 `binlog event size`大きすぎる場合は、この値はマイクロ秒単位にする必要があります。5 `write relay log duration`大きすぎる場合は、ディスクの書き込みパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DMワーカーにローカルSSDを使用してください。 +binlogイベントをリレーログファイルに書き込む場合、関連するパフォーマンスメトリックは`write relay log duration`です。`binlog event size`大きすぎる場合は、この値はマイクロ秒単位にする必要があります。`write relay log duration`大きすぎる場合は、ディスクの書き込みパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DMワーカーにローカルSSDを使用してください。 ## 負荷ユニット {#load-unit} @@ -68,7 +68,7 @@ Binlogレプリケーションユニットは、設定に応じて、上流のMy - DM のBinlogレプリケーション処理ユニットがアップストリーム MySQL/MariaDB からbinlogイベントを読み取る場合、問題を特定して解決するには、「リレー ログ ユニット」セクションの[binlogデータを読み取る](#read-binlog-data)参照してください。 -- DMのBinlogレプリケーション処理ユニットがリレーログファイルからbinlogイベントを読み取る場合、 `binlog event size`が大きすぎない場合、 `read binlog event duration`の値はマイクロ秒単位にする必要があります。5 `read binlog event duration`大きすぎる場合は、ディスクの読み取りパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DMワーカーにローカルSSDを使用してください。 +- DMのBinlogレプリケーション処理ユニットがリレーログファイルからbinlogイベントを読み取る場合、 `binlog event size`が大きすぎない場合、 `read binlog event duration`の値はマイクロ秒単位にする必要があります。`read binlog event duration`大きすぎる場合は、ディスクの読み取りパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DMワーカーにローカルSSDを使用してください。 ### binlogイベント変換 {#binlog-event-conversion} @@ -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文の書き込み時にボトルネックが発生していることを示します。`transaction execution latency`を使用すると、下流への単一トランザクションの実行に要した時間を表示できます。 `transaction execution latency`は通常数十ミリ秒です。この値が大きすぎる場合は、下流データベースの監視に基づいて下流のパフォーマンスを確認してください。また、DMと下流データベース間のネットワークレイテンシーが大きくないか確認することもできます。 diff --git a/dm/dm-pause-task.md b/dm/dm-pause-task.md index abe974766cd79..b0c1763f1ea2f 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`で照会できます。`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 ee3f91839dabb..7a3d59428a1dc 100644 --- a/dm/dm-performance-test.md +++ b/dm/dm-performance-test.md @@ -89,7 +89,7 @@ mydumpers: #### テスト結果を取得する {#get-test-results} -DM-worker のログを確認してください。1 `all data files have been finished`表示されている場合は、すべてのデータがインポートされたことを意味します。この場合、データのインポートにかかった時間を確認できます。サンプルログは次のとおりです。 +DM-worker のログを確認してください。`all data files have been finished`が表示されている場合は、すべてのデータがインポートされたことを意味します。この場合、データのインポートにかかった時間を確認できます。サンプルログは次のとおりです。 [INFO] [loader.go:604] ["all data files have been finished"] [task=test] [unit=load] ["cost time"=52.439796ms] diff --git a/dm/dm-stop-task.md b/dm/dm-stop-task.md index 1c65c2c378b08..3ddfe61948af2 100644 --- a/dm/dm-stop-task.md +++ b/dm/dm-stop-task.md @@ -5,7 +5,7 @@ summary: データ移行タスクを停止する方法を学びます。 # データ移行タスクを停止する {#stop-a-data-migration-task} -`stop-task`コマンドを使用してデータ移行タスクを停止できます。3 と`stop-task` `pause-task`違いについては、 [データ移行タスクを一時停止する](/dm/dm-pause-task.md)を参照してください。 +`stop-task`コマンドを使用してデータ移行タスクを停止できます。`stop-task`と`pause-task`の違いについては、 [データ移行タスクを一時停止する](/dm/dm-pause-task.md)を参照してください。 ```bash help stop-task diff --git a/dm/dm-table-routing.md b/dm/dm-table-routing.md index 47d12abb39273..d7342e80230d0 100644 --- a/dm/dm-table-routing.md +++ b/dm/dm-table-routing.md @@ -40,7 +40,7 @@ routes: データベース名とテーブル名のマッチングには、正規表現とワイルドカードがサポートされています。シンプルなシナリオでは、スキーマとテーブルのマッチングにワイルドカードを使用することをお勧めします。ただし、以下の点にご注意ください。 -- `*` `[]`含むワイルドカードがサポートされています。ワイルドカードマッチでは`*`記号は1 `?`だけ使用でき、末尾になければなりません。例えば、 `table-pattern: "t_*"`の場合、 `"t_*"` `t_`で始まるすべてのテーブルを表します。詳細は[ワイルドカードマッチング](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax)参照してください。 +- `*` 、 `?` 、 `[]`を含むワイルドカードがサポートされています。ワイルドカードマッチでは`*`記号は1つだけ使用でき、末尾になければなりません。例えば、 `table-pattern: "t_*"`の場合、 `"t_*"`は`t_`で始まるすべてのテーブルを表します。詳細は[ワイルドカードマッチング](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax)を参照してください。 - `table-regexp` 、 `schema-regexp` 、 `source-regexp`正規表現のみをサポートし、 `~`記号で始まることはできません。 diff --git a/dm/dm-tune-configuration.md b/dm/dm-tune-configuration.md index 50843ec6ab929..be49bef77288e 100644 --- a/dm/dm-tune-configuration.md +++ b/dm/dm-tune-configuration.md @@ -13,7 +13,7 @@ summary: データ移行タスクの構成を最適化して、データ移行 ### `rows` {#rows} -`rows`オプションを設定すると、マルチスレッドを使用して単一テーブルから同時にデータをエクスポートできます。3 `rows`値は、エクスポートされる各チャンクに含まれる行の最大数です。このオプションを有効にすると、MySQL 単一テーブルのデータを同時にエクスポートする際に、DM は分割ベンチマークとして列を選択します。この列は、主キー列、一意インデックス列、通常のインデックス列（優先度の高いものから`BIGINT`ものの順）のいずれかになります。この列`MEDIUMINT`整数型（例： `INT` ）であることを確認してください。 +`rows`オプションを設定すると、マルチスレッドを使用して単一テーブルから同時にデータをエクスポートできます。`rows`の値は、エクスポートされる各チャンクに含まれる行の最大数です。このオプションを有効にすると、MySQL 単一テーブルのデータを同時にエクスポートする際に、DM は分割ベンチマークとして列を選択します。この列は、主キー列、一意インデックス列、通常のインデックス列（優先度の高いものから低いものの順）のいずれかになります。この列が整数型（例： `INT` 、 `MEDIUMINT` 、 `BIGINT` ）であることを確認してください。 `rows`の値は 10000 まで設定できます。この値は、テーブルの総行数とデータベースのパフォーマンスに応じて変更できます。また、同時実行スレッド数を制御するには`threads`設定する必要があります。デフォルトでは`threads`の値は 4 です。この値は必要に応じて調整できます。 diff --git a/dm/feature-online-ddl.md b/dm/feature-online-ddl.md index 212a9fc271c04..a445199b63095 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`を実行しません。`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`を実行しません。`rename ghost_table to origin table`を実行する場合、DMは以下の手順を実行します。 - ステップ2でメモリに記録されたDDLを読み取ります - `ghost_table`と`ghost_schema` `origin_table`とそれに対応するスキーマに置き換えます diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md index 58197acc70682..134828be9c6d9 100644 --- a/dm/feature-shard-merge-optimistic.md +++ b/dm/feature-shard-merge-optimistic.md @@ -21,7 +21,7 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル ## 楽観的モードのコンフィグレーション {#configuration-of-the-optimistic-mode} -楽観的モードを使用するには、タスク設定ファイルの`shard-mode`項目を`optimistic`に指定します。5 `strict-optimistic-shard-mode`の設定を有効にすると、楽観的モードの動作を制限できます。詳細なサンプル設定ファイルについては、 [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)参照してください。 +楽観的モードを使用するには、タスク設定ファイルの`shard-mode`項目を`optimistic`に指定します。`strict-optimistic-shard-mode`の設定を有効にすると、楽観的モードの動作を制限できます。詳細なサンプル設定ファイルについては、 [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 ## 制限 {#restrictions} @@ -48,7 +48,7 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル - デフォルト値のない`NOT NULL`列を追加します: `ALTER TABLE table_name ADD COLUMN column_1 NOT NULL;` 。 - インデックスの名前を変更します: `ALTER TABLE table_name RENAME INDEX index_1 TO index_2;` 。 -シャードテーブルが上記のDDL文を実行する際、 `strict-optimistic-shard-mode: true`設定されている場合はタスクが直接中断され、エラーが報告されます。3 `strict-optimistic-shard-mode: false`設定されている場合、または指定されていない場合は、シャードテーブル内のDDL文の実行順序が異なるため、移行が中断されます。例： +シャードテーブルが上記のDDL文を実行する際、 `strict-optimistic-shard-mode: true`設定されている場合はタスクが直接中断され、エラーが報告されます。`strict-optimistic-shard-mode: false`設定されている場合、または指定されていない場合は、シャードテーブル内のDDL文の実行順序が異なるため、移行が中断されます。例： - シャード 1 は列の名前を変更し、列の種類を変更します。 1. 列の名前を変更します: `ALTER TABLE table_name RENAME COLUMN column_1 TO column_2;` . diff --git a/dm/feature-shard-merge-pessimistic.md b/dm/feature-shard-merge-pessimistic.md index a93fbe0991e4e..dbb752493a3b6 100644 --- a/dm/feature-shard-merge-pessimistic.md +++ b/dm/feature-shard-merge-pessimistic.md @@ -51,7 +51,7 @@ DM の悲観的モードでは、シャーディング DDL の使用に関して 4. `t3`では、インスタンス 2 からのシャーディング DDL イベントが受信されます。 5. `t4`以降、同期ユニットはインスタンス2からの`schema V2`のDMLイベントも受信します。 -シャーディングされたテーブルの DDL ステートメントは、移行プロセス中に処理されないものとします。インスタンス 1 の DDL ステートメントがダウンストリームに移行された後、ダウンストリームのテーブル スキーマは`schema V2`に変更されます。しかし、インスタンス 2 では、DM-worker の同期ユニットは`schema V1`から`t2`への`t3`の DML イベントをまだ受信しています。そのため、 `schema V1`の DML ステートメントがダウンストリームに移行される際に、DML ステートメントとテーブル スキーマの不整合によりエラーが発生し、データが正常に移行されない可能性があります。 +シャーディングされたテーブルの DDL ステートメントは、移行プロセス中に処理されないものとします。インスタンス 1 の DDL ステートメントがダウンストリームに移行された後、ダウンストリームのテーブル スキーマは`schema V2`に変更されます。しかし、インスタンス 2 では、DM-worker の同期ユニットは`t2`から`t3`までの`schema V1`の DML イベントをまだ受信しています。そのため、 `schema V1`の DML ステートメントがダウンストリームに移行される際に、DML ステートメントとテーブル スキーマの不整合によりエラーが発生し、データが正常に移行されない可能性があります。 ## 原則 {#principles} diff --git a/dm/handle-failed-ddl-statements.md b/dm/handle-failed-ddl-statements.md index abafa293ad40f..8f879f1e1ffe3 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} @@ -33,7 +33,7 @@ dmctl を使用して失敗した DDL ステートメントを手動で処理す ### クエリステータス {#query-status} -`query-status`コマンドは、各 MySQL インスタンス内のサブタスクやリレーユニットなどの現在の状態を問い合わせるために使用されます。詳細については、 [クエリステータス](/dm/dm-query-status.md)参照してください。 +`query-status`コマンドは、各 MySQL インスタンス内のサブタスクやリレーユニットなどの現在の状態を問い合わせるために使用されます。詳細については、 [クエリステータス](/dm/dm-query-status.md)を参照してください。 ### binlog {#binlog} @@ -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`コマンドを実行すると、MySQLインスタンス1の`shard_db_1`.`shard_table_1`テーブル、およびMySQLインスタンス2の`shard_db_2`.`shard_table_1`テーブルによって報告される以下のエラーが確認できます。 { "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 @@ -283,7 +283,7 @@ ALTER TABLE `shard_db_*`.`shard_table_*` CHARACTER SET LATIN1 COLLATE LATIN1_DAN ] } -2. `query-status`コマンドを実行すると、MySQL インスタンス 1 の`shard_db_1` `shard_table_2`と MySQL インスタンス 2 `shard_table_2` `shard_db_2`によって報告されたエラーを確認できます。 +2. `query-status`コマンドを実行すると、MySQLインスタンス1の`shard_db_1`.`shard_table_2`テーブル、およびMySQLインスタンス2の`shard_db_2`.`shard_table_2`テーブルによって報告されるエラーを確認できます。 { "Message": "cannot track DDL: ALTER TABLE `shard_db_1`.`shard_table_2` CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI", @@ -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 @@ -565,7 +565,7 @@ SHOW CREATE TABLE shard_db.shard_table; ALTER TABLE `shard_db_*`.`shard_table_*` ADD COLUMN new_col INT UNIQUE; ``` -このDDL文はTiDBでサポートされていないため、移行タスクは中断されます。コマンド`query-status`を実行すると、MySQLインスタンス`shard_table_1` `shard_db_1` MySQLインスタンス2のテーブル`shard_db_2`で以下のエラー`shard_table_1`報告されます。 +このDDL文はTiDBでサポートされていないため、移行タスクは中断されます。`query-status`コマンドを実行すると、MySQLインスタンス1の`shard_db_1`.`shard_table_1`テーブル、およびMySQLインスタンス2の`shard_db_2`.`shard_table_1`テーブルによって報告される以下のエラーが確認できます。 { "Message": "cannot track DDL: ALTER TABLE `shard_db_1`.`shard_table_1` ADD COLUMN `new_col` INT UNIQUE KEY", @@ -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 `を使用してタスクのステータスを表示すると、MySQLインスタンス1の`shard_db_1`.`shard_table_2`テーブル、およびMySQLインスタンス2の`shard_db_2`.`shard_table_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 7959a96a1c879..be8301b9c71df 100644 --- a/dm/maintain-dm-using-tiup.md +++ b/dm/maintain-dm-using-tiup.md @@ -269,7 +269,7 @@ tiup dm import --dir=/path/to/dm-ansible --cluster-version ${version} ## 操作ログを確認する {#view-the-operation-log} -操作ログを表示するには、 `audit`コマンドを使用します。3 `audit`の使用方法は次のとおりです。 +操作ログを表示するには、 `audit`コマンドを使用します。`audit`の使用方法は次のとおりです。 ```bash Usage: @@ -299,7 +299,7 @@ tiup dm audit 4D5kQY ## DM クラスター内のホストでコマンドを実行する {#run-commands-on-a-host-in-the-dm-cluster} -DMクラスタ内のホストでコマンドを実行するには、 `exec`コマンドを使用します。3 `exec`のコマンドの使用方法は次のとおりです。 +DMクラスタ内のホストでコマンドを実行するには、 `exec`コマンドを使用します。`exec`のコマンドの使用方法は次のとおりです。 ```bash Usage: diff --git a/dm/manually-handling-sharding-ddl-locks.md b/dm/manually-handling-sharding-ddl-locks.md index 7f4696320975f..cb8ed87774028 100644 --- a/dm/manually-handling-sharding-ddl-locks.md +++ b/dm/manually-handling-sharding-ddl-locks.md @@ -42,7 +42,7 @@ shard-ddl-lock -h -- `shard-ddl-lock [command]` : 指定された DDL ロックを解放するように DM マスターに要求します。2 `[command]`値として`unlock`のみを受け入れます。 +- `shard-ddl-lock [command]` : 指定された DDL ロックを解放するように DM マスターに要求します。`[command]`値として`unlock`のみを受け入れます。 ## 使用例 {#usage-examples} @@ -82,7 +82,7 @@ shard-ddl-lock test ### `shard-ddl-lock unlock` {#shard-ddl-lock-unlock} -このコマンドは、所有者に DDL ステートメントを実行するよう要求し、所有者以外の他のすべての DM ワーカーに DDL ステートメントをスキップするよう要求し、 `DM-master`のロック情報を削除するなど、指定された`DM-master`ロックのロックを解除するように 1 に積極的に要求します。 +このコマンドは、所有者に DDL ステートメントを実行するよう要求し、所有者以外の他のすべての DM ワーカーに DDL ステートメントをスキップするよう要求し、 `DM-master`のロック情報を削除するなど、指定された DDL ロックを解除するように`DM-master`に積極的に要求します。 > **Note:** > @@ -153,7 +153,7 @@ shard-ddl-lock unlock test-`shard_db`.`shard_table` #### 手動ソリューション {#manual-solution} -アップストリームにインスタンス`MySQL-1` （ `mysql-replica-01` ）と`MySQL-2` （ `mysql-replica-02` ）の2つがあり、 `shard_table_1`に`MySQL-1` `shard_db_1`の`shard_table_2`つ、 `shard_db_2` `MySQL-2`テーブル`shard_db_2` `shard_table_1` 2 `shard_table` `shard_table_2` `shard_db`する必要`shard_db_1`あります。 +アップストリームにインスタンス`MySQL-1` （ `mysql-replica-01` ）と`MySQL-2` （ `mysql-replica-02` ）の2つがあり、 `MySQL-1`に`shard_db_1`の`shard_table_1`と`shard_db_1`の`shard_table_2`の2つのテーブル、 `MySQL-2`に`shard_db_2`の`shard_table_1`と`shard_db_2`の`shard_table_2`の2つのテーブルがあるとします。ここで、これら4つのテーブルをマージして、ダウンストリームTiDBの`shard_db`の`shard_table`テーブルに移行する必要があります。 初期のテーブル構造は次のとおりです。 diff --git a/dm/quick-start-create-task.md b/dm/quick-start-create-task.md index 97267bcf3ac53..617cae7779ed1 100644 --- a/dm/quick-start-create-task.md +++ b/dm/quick-start-create-task.md @@ -119,7 +119,7 @@ from: port: 3306 ``` -MySQL2データソースで、上記の設定を`conf/source2.yaml`にコピーします。3 `name` `mysql-replica-02`に変更し、 `password`と`port`適切な値に変更する必要があります。 +MySQL2データソースで、上記の設定を`conf/source2.yaml`にコピーします。`name` `mysql-replica-02`に変更し、 `password`と`port`適切な値に変更する必要があります。 ### ソースを作成する {#create-a-source} diff --git a/dm/quick-start-with-dm.md b/dm/quick-start-with-dm.md index 75d76ad8ea5d9..8b51d0672d9c7 100644 --- a/dm/quick-start-with-dm.md +++ b/dm/quick-start-with-dm.md @@ -357,7 +357,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー ## ステップ5: データ複製を確認する {#step-5-verify-the-data-replication} -移行タスクを開始したら、データレプリケーションが期待どおりに動作しているかどうかを確認します。1 `dmctl`を使用してタスクのステータスを確認し、ターゲット TiDB データベースに接続して、ソース MySQL データベースからデータが正常に複製されていることを確認します。 +移行タスクを開始したら、データレプリケーションが期待どおりに動作しているかどうかを確認します。`dmctl`を使用してタスクのステータスを確認し、ターゲット TiDB データベースに接続して、ソース MySQL データベースからデータが正常に複製されていることを確認します。 1. TiDB DM タスクのステータスを確認します。 @@ -371,7 +371,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー mysql --host 127.0.0.1 --port 4000 -u root --prompt 'tidb> ' ``` -3. 複製されたデータを確認します。1 [ステップ2](#step-2-prepare-a-source-database-optional)サンプルデータを作成した場合、MySQLソースデータベースからターゲットTiDBデータベースに複製されたテーブル`hello_tidb`が表示されます。 +3. 複製されたデータを確認します。[ステップ2](#step-2-prepare-a-source-database-optional)でサンプルデータを作成した場合、MySQLソースデータベースからターゲットTiDBデータベースに複製されたテーブル`hello_tidb`が表示されます。 ```sql SELECT * FROM hello.hello_tidb; diff --git a/dm/relay-log.md b/dm/relay-log.md index 34432aa7c7766..0a17c878b8f9f 100644 --- a/dm/relay-log.md +++ b/dm/relay-log.md @@ -88,7 +88,7 @@ stop-relay -s mysql-replica-01 worker1 worker2
-DM バージョン 2.0.2 より前のバージョン（v2.0.2 は含まない）では、DM ワーカーを上流データソースにバインドする際に、ソース設定ファイルの設定項目`enable-relay`チェックされます。3 `enable-relay` `true`に設定されている場合、DM はデータソースのリレーログ機能を有効にします。 +DM バージョン 2.0.2 より前のバージョン（v2.0.2 は含まない）では、DM ワーカーを上流データソースにバインドする際に、ソース設定ファイルの設定項目`enable-relay`チェックされます。`enable-relay` `true`に設定されている場合、DM はデータソースのリレーログ機能を有効にします。 設定項目`enable-relay`設定方法については[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)参照してください。 @@ -276,7 +276,7 @@ purge: purge-relay -s mysql-replica-01 --filename mysql-bin.000001 --sub-dir e4e0e8ab-09cc-11e9-9220-82cc35207219.000002 ``` -- dmctlで次の`purge-relay`コマンドを実行すると、**現在の**（ `deb76a2b-09cc-11e9-9129-5242cf3bb246.000003` ）ディレクトリの`mysql-bin.000001`より前のすべてのリレーログファイル（ `deb76a2b-09cc-11e9-9129-5242cf3bb246.000001`と`e4e0e8ab-09cc-11e9-9220-82cc35207219.000002`にあるすべてのリレーログファイル）が削除されます。13 `deb76a2b-09cc-11e9-9129-5242cf3bb246.000003`ファイルは保持されます。 +- dmctlで次の`purge-relay`コマンドを実行すると、**現在の**（ `deb76a2b-09cc-11e9-9129-5242cf3bb246.000003` ）ディレクトリの`mysql-bin.000001`より前のすべてのリレーログファイル（ `deb76a2b-09cc-11e9-9129-5242cf3bb246.000001`と`e4e0e8ab-09cc-11e9-9220-82cc35207219.000002`にあるすべてのリレーログファイル）が削除されます。`deb76a2b-09cc-11e9-9129-5242cf3bb246.000003`内のファイルは保持されます。 ```bash purge-relay -s mysql-replica-01 --filename mysql-bin.000001 diff --git a/dm/usage-scenario-master-slave-switch.md b/dm/usage-scenario-master-slave-switch.md index d09b30d675ab4..f0e5e949cf6f6 100644 --- a/dm/usage-scenario-master-slave-switch.md +++ b/dm/usage-scenario-master-slave-switch.md @@ -30,7 +30,7 @@ DM-worker が仮想 IP (VIP) を介してアップストリーム MySQL イン 2. 新しいMySQLインスタンスで`SELECT @@GLOBAL.gtid_purged;`コマンドを使用して、削除されたバイナリログに対応するGTIDセットを取得します。これらのセットを`gtid-P`としてマークします。 3. 新しいMySQLインスタンスで`SELECT @@GLOBAL.gtid_executed;`コマンドを使用して、正常に実行されたすべてのトランザクションに対応するGTIDセットを取得します。これらのセットに`gtid-E`とマークを付けます。 4. 以下の条件が満たされていることを確認してください。満たされていない場合、DM-work 接続を新しい MySQL インスタンスに切り替えることはできません。 - - `gtid-S`には`gtid-P`含まれます。4 `gtid-P`空になる場合があります。 + - `gtid-S`には`gtid-P`含まれます。`gtid-P`空になる場合があります。 - `gtid-E`には`gtid-S`含まれます。 5. `pause-task`使用すると、データ移行の実行中のすべてのタスクが一時停止されます。 6. 新しい MySQL インスタンスに直接送信されるように VIP を変更します。 @@ -44,7 +44,7 @@ DM-worker 設定を変更して、DM-worker をアップストリーム内の新 2. 新しいMySQLインスタンスで`SELECT @@GLOBAL.gtid_purged;`コマンドを使用して、削除されたバイナリログに対応するGTIDセットを取得します。このセットを`gtid-P`としてマークします。 3. 新しいMySQLインスタンスで`SELECT @@GLOBAL.gtid_executed;`コマンドを使用して、正常に実行されたすべてのトランザクションに対応するGTIDセットを取得します。これらのセットを`gtid-E`としてマークします。 4. 以下の条件が満たされていることを確認してください。満たされていない場合、DM-work 接続を新しい MySQL インスタンスに切り替えることはできません。 - - `gtid-S`には`gtid-P`含まれます。4 `gtid-P`空になる場合があります。 + - `gtid-S`には`gtid-P`含まれます。`gtid-P`空になる場合があります。 - `gtid-E`には`gtid-S`含まれます。 5. `stop-task`使用すると、データ移行の実行中のタスクがすべて停止します。 6. `operator-source stop`コマンドを使用して、古い MySQL インスタンスのアドレスに対応するソース構成を DM クラスターから削除します。 diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index 2ca3e465dd058..48c6220a62033 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -185,7 +185,7 @@ nohup ./minio server ./data --address :6060 & +----------------------+----------+--------------------+---------------------+---------------------+ 1 row in set (2.11 sec) - `BACKUP`のステートメントが実行されると、TiDBはバックアップデータに関するメタデータを返します。3 `BackupTS`のステートメントには注意してください。これは、バックアップ前に生成されたデータが含まれているためです。このドキュメントでは、 `BackupTS`**を増分マイグレーションの開始**として使用します。 + `BACKUP`のステートメントが実行されると、TiDBはバックアップデータに関するメタデータを返します。`BackupTS`のステートメントには注意してください。これは、バックアップ前に生成されたデータが含まれているためです。このドキュメントでは、 `BackupTS`**を増分マイグレーションの開始**として使用します。 3. データの復元。セカンダリクラスタで以下のステートメント`RESTORE`を実行してデータを復元します。 diff --git a/dynamic-config.md b/dynamic-config.md index d254657886f3f..6125cf0e12147 100644 --- a/dynamic-config.md +++ b/dynamic-config.md @@ -103,7 +103,7 @@ show warnings; 1 row in set (0.00 sec) ``` -バッチ変更はアトミック性を保証するものではありません。一部のインスタンスでは変更が成功し、他のインスタンスでは失敗する可能性があります。1 `set tikv key=val`使用して TiKV クラスター全体の設定を変更すると、一部のインスタンスで変更が失敗する可能性があります。3 `show warnings`使用して結果を確認できます。 +バッチ変更はアトミック性を保証するものではありません。一部のインスタンスでは変更が成功し、他のインスタンスでは失敗する可能性があります。`set tikv key=val`を使用して TiKV クラスター全体の設定を変更すると、一部のインスタンスで変更が失敗する可能性があります。`show warnings`を使用して結果を確認できます。 一部の変更が失敗した場合は、対応するステートメントを再実行するか、失敗したインスタンスを個別に変更する必要があります。ネットワークの問題やマシンの障害により一部のTiKVインスタンスにアクセスできない場合は、復旧後にこれらのインスタンスを変更してください。 @@ -236,7 +236,7 @@ show warnings; | `cdc.incremental-scan-speed-limit` | 履歴データの増分スキャンの速度の上限 | | `cdc.incremental-scan-concurrency` | 履歴データの同時増分スキャンタスクの最大数 | -上記の表で、プレフィックスが`{db-name}`または`{db-name}.{cf-name}`パラメータはRocksDB関連の設定です。5のオプション値は`db-name` `rocksdb` `raftdb`です。 +上記の表で、`{db-name}`または`{db-name}.{cf-name}`プレフィックスを持つパラメータはRocksDB関連の設定です。`db-name`のオプション値は`rocksdb`と`raftdb`です。 - `db-name`が`rocksdb`の場合、 `cf-name`のオプションの値は`defaultcf` 、 `writecf` 、 `lockcf` 、および`raftcf`です。 - `db-name`が`raftdb`とき、 `cf-name`の値は`defaultcf`になります。 @@ -333,7 +333,7 @@ Query OK, 0 rows affected (0.01 sec) ### TiDB構成を動的に変更する {#modify-tidb-configuration-dynamically} -現在、TiDB構成の変更方法は、TiKVおよびPD構成の変更方法とは異なります。1 [システム変数](/system-variables.md)使用してTiDB構成を変更できます。 +現在、TiDB構成の変更方法は、TiKVおよびPD構成の変更方法とは異なります。[システム変数](/system-variables.md)を使用してTiDB構成を変更できます。 次の例は、 `tidb_slow_log_threshold`変数を使用して`slow-threshold`動的に変更する方法を示しています。 @@ -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/encryption-at-rest.md b/encryption-at-rest.md index 3ecfc18555a5f..e502c2976dd78 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -7,7 +7,7 @@ summary: 機密データを保護するために保存時の暗号化を有効 > **Note:** > -> クラスターがAWS上にデプロイされており、EBSストレージを使用している場合は、EBS暗号化を使用することをお勧めします。1 [AWS ドキュメント - EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)参照してください。AWS上でローカルNVMeストレージなど、EBS以外のストレージを使用している場合は、このドキュメントで紹介されている保存時の暗号化を使用することをお勧めします。 +> クラスターがAWS上にデプロイされており、EBSストレージを使用している場合は、EBS暗号化を使用することをお勧めします。[AWS ドキュメント - EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)を参照してください。AWS上でローカルNVMeストレージなど、EBS以外のストレージを使用している場合は、このドキュメントで紹介されている保存時の暗号化を使用することをお勧めします。 保存時の暗号化とは、データが保存時に暗号化されることを意味します。データベースの場合、この機能はTDE（透過的データ暗号化）とも呼ばれます。これは、転送中の暗号化（TLS）や使用中の暗号化（ほとんど使用されません）とは対照的です。保存時の暗号化はSSDドライブ、ファイルシステム、クラウドベンダーなど、さまざまな方法で実行できますが、TiKVが保存前に暗号化を行うことで、攻撃者がデータにアクセスするにはデータベースへの認証が必要となることを確実にします。例えば、攻撃者が物理マシンにアクセスできたとしても、ディスク上のファイルをコピーするだけではデータにアクセスできません。 @@ -47,7 +47,7 @@ BRは、S3へのデータバックアップ時にS3サーバー側暗号化（SS ### ログ記録 {#logging} -TiKV、TiDB、およびPD情報ログには、デバッグ用のユーザーデータが含まれる場合があります。情報ログとその中に含まれるデータは暗号化されません。1 [ログ編集](/log-redaction.md)有効にすることを推奨します。 +TiKV、TiDB、およびPD情報ログには、デバッグ用のユーザーデータが含まれる場合があります。情報ログとその中に含まれるデータは暗号化されません。[ログ編集](/log-redaction.md)を有効にすることを推奨します。 ## 保存時の TiKV 暗号化 {#tikv-encryption-at-rest} @@ -123,7 +123,7 @@ AWS KMS を使用してマスターキーを指定するには、TiKV 設定フ region = "us-west-2" endpoint = "https://kms.us-west-2.amazonaws.com" -`key-id` KMS CMK のキー ID を指定します。3 `region` KMS CMK の AWS リージョン名です。5 はオプションであり、AWS 以外のベンダーの AWS KMS 互換サービスを使用している場合や、 `endpoint` [KMS の VPC エンドポイント](https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html)使用する必要がある場合を除き、通常は指定する必要はありません。 +`key-id`は KMS CMK のキー ID を指定します。`region`は KMS CMK の AWS リージョン名です。`endpoint`はオプションであり、AWS 以外のベンダーの AWS KMS 互換サービスを使用している場合や、 [KMS の VPC エンドポイント](https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html)を使用する必要がある場合を除き、通常は指定する必要はありません。 AWSでも[マルチリージョンキー](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)使用できます。この場合、特定のリージョンに主キーを設定し、必要なリージョンにレプリカキーを追加する必要があります。 @@ -258,7 +258,7 @@ TiKVをGrafanaでデプロイしている場合は、保存時の暗号化を監 - 暗号化メタファイル サイズ: 暗号化メタデータ ファイルのサイズ。 - 読み取り/書き込み暗号化メタ期間: 暗号化のメタデータを操作するための追加のオーバーヘッド。 -デバッグのために、 `tikv-ctl`コマンドを使用すると、ファイルの暗号化に使用された暗号化方式やデータキーID、データキーのリストなどの暗号化メタデータをダンプできます。この操作により機密データが漏洩する可能性があるため、本番での使用は推奨されません。3 [TiKV Control](/tikv-control.md#dump-encryption-metadata)ドキュメントを参照してください。 +デバッグのために、 `tikv-ctl`コマンドを使用すると、ファイルの暗号化に使用された暗号化方式やデータキーID、データキーのリストなどの暗号化メタデータをダンプできます。この操作により機密データが漏洩する可能性があるため、本番での使用は推奨されません。[TiKV Control](/tikv-control.md#dump-encryption-metadata)ドキュメントを参照してください。 ### TiKVバージョン間の互換性 {#compatibility-between-tikv-versions} @@ -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」で、暗号化は無効です。`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 01f4113a20504..d60638c40e67c 100644 --- a/error-codes.md +++ b/error-codes.md @@ -121,15 +121,15 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8032 - 無効な`year`形式が使用されています。3 `year` 1 桁、2 桁、または 4 桁のみを受け入れます。 + 無効な`year`形式が使用されています。`year` 1 桁、2 桁、または 4 桁のみを受け入れます。 - エラー番号: 8033 - 無効な値`year`が使用されています。3 `year`有効範囲は(1901, 2155)です。 + 無効な値`year`が使用されています。`year`有効範囲は(1901, 2155)です。 - エラー番号: 8037 - `week`関数で無効な`mode`形式が使用されています。5 `mode` [0, 7] 以内の 1 桁の数字でなければなりません。 + `week`関数で無効な`mode`形式が使用されています。`mode` [0, 7] 以内の 1 桁の数字でなければなりません。 - エラー番号: 8038 @@ -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サーバーからのローカルデータのインポートをサポートしていません。`LOCAL`を指定してクライアントからインポートするか、S3 または GCS にデータをアップロードしてからインポートすることができます。[`LOAD DATA`](/sql-statements/sql-statement-load-data.md)を参照してください。 - エラー番号: 8156 @@ -481,7 +481,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8249 - リソースグループが存在しません。このエラーは、存在しないリソースグループを変更またはバインドした場合に返されます。1 [リソースグループを作成する](/tidb-resource-control-ru-groups.md#create-a-resource-group)参照してください。 + リソースグループが存在しません。このエラーは、存在しないリソースグループを変更またはバインドした場合に返されます。[リソースグループを作成する](/tidb-resource-control-ru-groups.md#create-a-resource-group)を参照してください。 - エラー番号: 8250 @@ -505,11 +505,11 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8253 - クエリはランナウェイクエリの条件を満たしているため停止します。1 [ランナウェイクエリ](/tidb-resource-control-runaway-queries.md)参照してください。 + クエリはランナウェイクエリの条件を満たしているため停止します。[ランナウェイクエリ](/tidb-resource-control-runaway-queries.md)を参照してください。 - エラー番号: 8254 - クエリは、ランナウェイクエリの隔離監視条件を満たしているため停止します。1 [ランナウェイクエリ](/tidb-resource-control-runaway-queries.md)参照してください。 + クエリは、ランナウェイクエリの隔離監視条件を満たしているため停止します。[ランナウェイクエリ](/tidb-resource-control-runaway-queries.md)を参照してください。 - エラー番号: 8260 @@ -571,7 +571,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 完全なエラーメッセージ: `ERROR 9006 (HY000): GC life time is shorter than transaction duration` - 間隔`GC Life Time`は短すぎます。長いトランザクションによって読み取られるはずだったデータが削除される可能性があります。3 [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)次のコマンドで調整できます。 + 間隔`GC Life Time`は短すぎます。長いトランザクションによって読み取られるはずだったデータが削除される可能性があります。[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)は次のコマンドで調整できます。 ```sql SET GLOBAL tidb_gc_life_time = '30m'; diff --git a/explain-aggregation.md b/explain-aggregation.md index 57a57cab71f15..e7927a26c4f6f 100644 --- a/explain-aggregation.md +++ b/explain-aggregation.md @@ -65,7 +65,7 @@ EXPLAIN SELECT COUNT(*) FROM t1; 4 rows in set (0.00 sec) ``` -これは`EXPLAIN ANALYZE`で最も簡単に確認できます。1 では、 `TableFullScan`使用されており、セカンダリ インデックスがないため、 `actRows` `SHOW TABLE REGIONS`のリージョンの数と一致しています。 +これは`EXPLAIN ANALYZE`で最も簡単に確認できます。`EXPLAIN ANALYZE`では、 `TableFullScan`が使用されており、セカンダリ インデックスがないため、 `actRows`は`SHOW TABLE REGIONS`のリージョンの数と一致しています。 ```sql EXPLAIN ANALYZE SELECT COUNT(*) FROM t1; diff --git a/explain-index-merge.md b/explain-index-merge.md index 5d20e97ab8e36..03e8a7649377d 100644 --- a/explain-index-merge.md +++ b/explain-index-merge.md @@ -48,7 +48,7 @@ EXPLAIN SELECT /*+ USE_INDEX_MERGE(t) */ * FROM t WHERE a > 1 OR b > 1; 上記のクエリでは、オプティマイザはテーブルにアクセスするためにユニオン型のインデックスマージを選択します。インデックスマージにより、オプティマイザはテーブルごとに複数のインデックスを使用し、各インデックスから返された結果をマージして、上記の出力の後者の実行プランを生成することができます。 -出力において、 `IndexMerge_8`演算子の`operator info`の`type: union`情報は、この演算子がユニオン型インデックスマージであることを示しています。この演算子には3つの子ノードがあります。7と`IndexRangeScan_6` `IndexRangeScan_5`範囲に従って条件を満たす`RowID`をスキャンし、その後、 `TableRowIDScan_7`演算子はこれらの`RowID`に基づいて条件を満たすすべてのデータを正確に読み取ります。 +出力において、 `IndexMerge_8`演算子の`operator info`の`type: union`情報は、この演算子がユニオン型インデックスマージであることを示しています。この演算子には3つの子ノードがあります。`IndexRangeScan_5`と`IndexRangeScan_6`は範囲に従って条件を満たす`RowID`をスキャンし、その後、 `TableRowIDScan_7`演算子はこれらの`RowID`に基づいて条件を満たすすべてのデータを正確に読み取ります。 `IndexRangeScan` / `TableRangeScan`ように特定のデータ範囲に対して実行されるスキャン演算の場合、結果の`operator info`列には、 `IndexFullScan` / `TableFullScan`のような他のスキャン演算と比較して、スキャン範囲に関する追加情報が含まれます。上記の例では、 `IndexRangeScan_5`演算子の`range:(1,+inf]` 、演算子が 1 から正の無限大までデータをスキャンすることを示しています。 @@ -84,7 +84,7 @@ EXPLAIN SELECT /*+ USE_INDEX_MERGE(t, idx_a, idx_b, idx_c) */ * FROM t WHERE a > - 3 つのフィルタ条件のそれぞれについて、それぞれの選択性は非常に高いため、単一のインデックスを使用した`IndexLookUp`の実行効率は理想的ではありません。 - 3 つのフィルター条件の全体的な選択性は低いです。 -交差型インデックスマージを使用してテーブルにアクセスする場合、オプティマイザはテーブルに対して複数のインデックスを使用し、各インデックスから返される結果をマージして、前述の出力例の`IndexMerge`の実行プランを生成することができます。7 `IndexMerge_9`の演算子の`operator info`の情報`type: intersection`は、この演算子が交差型インデックスマージであることを示しています。実行プランのその他の部分は、前述のユニオン型インデックスマージの例と同様です。 +交差型インデックスマージを使用してテーブルにアクセスする場合、オプティマイザはテーブルに対して複数のインデックスを使用し、各インデックスから返される結果をマージして、前述の出力例の`IndexMerge`の実行プランを生成することができます。`IndexMerge_9`の演算子の`operator info`の情報`type: intersection`は、この演算子が交差型インデックスマージであることを示しています。実行プランのその他の部分は、前述のユニオン型インデックスマージの例と同様です。 > **Note:** > diff --git a/explain-indexes.md b/explain-indexes.md index 7ec1a7286619c..b0283fca677c8 100644 --- a/explain-indexes.md +++ b/explain-indexes.md @@ -132,7 +132,7 @@ EXPLAIN SELECT * FROM t1 ORDER BY intkey DESC LIMIT 10; ## インデックスリーダー {#indexreader} -TiDBは*カバーインデックス最適化*をサポートしています。インデックスからすべての行を取得できる場合、TiDBは通常`IndexLookup`で必要な2番目のステップを省略します。次の2つの例を考えてみましょう。 +TiDBは*カバリングインデックス最適化*をサポートしています。インデックスからすべての行を取得できる場合、TiDBは通常`IndexLookup`で必要な2番目のステップを省略します。次の2つの例を考えてみましょう。 ```sql EXPLAIN SELECT * FROM t1 WHERE intkey = 123; @@ -161,7 +161,7 @@ EXPLAIN SELECT id FROM t1 WHERE intkey = 123; `id`内部的には`RowID`でもあるため、インデックス`intkey`に格納されます。インデックス`intkey`を`└─IndexRangeScan_5`の一部として使用することで、インデックス`RowID`の値を直接返すことができます。 -## Point_Get と Batch_Point_Get {#point-get-and-batch-point-get} +## Point_Get と Batch_Point_Get {#point_get-and-batch_point_get} TiDBは、主キーまたは一意キーから直接データを取得する際に、 `Point_Get`または`Batch_Point_Get`演算子を使用します。これらの演算子は`IndexLookup`よりも効率的です。例えば、 @@ -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`が実行されます。`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-mpp.md b/explain-mpp.md index 644952d30c1a7..25b608683c532 100644 --- a/explain-mpp.md +++ b/explain-mpp.md @@ -29,7 +29,7 @@ EXPLAIN SELECT COUNT(*) FROM t1 GROUP BY id; ## Exchange 演算子 {#exchange-operators} -`ExchangeReceiver`と`ExchangeSender` 、MPP実行プランに特有の2つの交換演算子です。4 演算子`ExchangeReceiver`下流のクエリフラグメントからデータを読み取り、 `ExchangeSender`演算子は下流のクエリフラグメントから上流のクエリフラグメントにデータを送信します。MPPモードでは、各MPPクエリフラグメントのルート演算子は`ExchangeSender`です。つまり、クエリフラグメントは`ExchangeSender`演算子によって区切られます。 +`ExchangeReceiver`と`ExchangeSender` 、MPP実行プランに特有の2つの交換演算子です。`ExchangeReceiver`演算子は下流のクエリフラグメントからデータを読み取り、 `ExchangeSender`演算子は下流のクエリフラグメントから上流のクエリフラグメントにデータを送信します。MPPモードでは、各MPPクエリフラグメントのルート演算子は`ExchangeSender`です。つまり、クエリフラグメントは`ExchangeSender`演算子によって区切られます。 以下は単純な MPP 実行プランです。 diff --git a/explain-overview.md b/explain-overview.md index 349b558a121d3..a0a9f280441d9 100644 --- a/explain-overview.md +++ b/explain-overview.md @@ -7,7 +7,7 @@ summary: TiDB の EXPLAIN` ステートメントによって返される実行 > **Note:** > -> MySQLクライアントを使用してTiDBに接続する場合、出力結果を行の折り返しなしでより明確に読み取るには、 `pager less -S`コマンドを使用します。3 `EXPLAIN`結果が出力された後、キーボードの右矢印→キーを押して出力を水平にスクロールします。 +> MySQLクライアントを使用してTiDBに接続する場合、出力結果を行の折り返しなしでより明確に読み取るには、 `pager less -S`コマンドを使用します。`EXPLAIN`結果が出力された後、キーボードの右矢印→キーを押して出力を水平にスクロールします。 SQLは宣言型言語です。クエリの結果がどのようになるべきかを記述するものであり、実際に結果を取得する**方法論**を記述するものではありません。TiDBは、テーブルを結合する順序や、インデックスの使用可能性など、クエリの実行方法の可能性をすべて考慮します。*クエリ実行プランを検討する*プロセスは、SQL最適化と呼ばれます。 @@ -35,7 +35,7 @@ Records: 2 Duplicates: 0 Warnings: 0 3 rows in set (0.00 sec) ``` -`EXPLAIN`実際のクエリを実行しません。2 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)クエリを実行し、 `EXPLAIN`情報を表示します。これは、選択された実行プランが最適ではないケースを診断するのに役立ちます。6 `EXPLAIN`使用例については、以下のドキュメントをご覧ください。 +`EXPLAIN`実際のクエリを実行しません。2 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)クエリを実行し、 `EXPLAIN`情報を表示します。これは、選択された実行プランが最適ではないケースを診断するのに役立ちます。`EXPLAIN`使用例については、以下のドキュメントをご覧ください。 - [インデックス](/explain-indexes.md) - [テーブル結合](/explain-joins.md) @@ -141,8 +141,8 @@ TiDBは、TiKV/ TiFlashからスキャンされたデータまたは計算結果 - **TableReader** : TiKV の`TableFullScan`や`TableRangeScan`の基礎となる演算子によって取得されたデータを集計します。 - **IndexReader** : TiKV の`IndexFullScan`や`IndexRangeScan`の基礎となる演算子によって取得されたデータを集計します。 -- **IndexLookUp** : まず、 `Build`側でスキャンされたRowID（TiKV内）を集計します。次に、 `Probe`側でこれらのRowIDに基づいてTiKVからデータを正確に読み取ります。6 `Build`には`IndexFullScan`や`IndexRangeScan`などの演算子があり、 `Probe`側には`TableRowIDScan`演算子があります。 -- **IndexMerge** : `IndexLookUp`と同様です。4 `IndexMerge` `IndexLookupReader`の拡張と見なすことができます。8 `IndexMerge`複数のインデックスの同時読み取りをサポートします。10 は`Build`あり、 `Probe`は1つです。14 の実行プロセスは`IndexMerge` `IndexLookUp`同じです。 +- **IndexLookUp** : まず、 `Build`側でスキャンされたRowID（TiKV内）を集計します。次に、 `Probe`側でこれらのRowIDに基づいてTiKVからデータを正確に読み取ります。`Build`側には`IndexFullScan`や`IndexRangeScan`などの演算子があり、 `Probe`側には`TableRowIDScan`演算子があります。 +- **IndexMerge** : `IndexLookUp`と同様です。4 `IndexMerge` `IndexLookupReader`の拡張と見なすことができます。8 `IndexMerge`複数のインデックスの同時読み取りをサポートします。`Build`は多数あり、 `Probe`は1つです。`IndexMerge`の実行プロセスは`IndexLookUp`と同じです。 構造はツリー構造のように見えますが、クエリの実行において子ノードが親ノードより先に完了している必要は必ずしもありません。TiDBはクエリ内並列処理をサポートしているため、より正確な表現は、子ノードが親ノード*に流れ込む*というものです。親ノード、子ノード、兄弟ノードの演算子によって、クエリの一部が並列実行される可能性*があります*。 @@ -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 はバックグラウンド処理の一環として定期的に統計を更新します。`ANALYZE TABLE t`を実行して手動で更新することもできます。 `EXPLAIN`文の実行後、異なる演算子は異なる情報を出力します。オプティマイザヒントを使用してオプティマイザの動作を制御し、それによって物理演算子の選択を制御できます。例えば、 `/*+ HASH_JOIN(t1, t2) */`オプティマイザが`Hash Join`アルゴリズムを使用することを意味します。詳細については、 [オプティマイザヒント](/optimizer-hints.md)参照してください。 diff --git a/explain-partitions.md b/explain-partitions.md index ef2a8f8515ed0..ba65217d73389 100644 --- a/explain-partitions.md +++ b/explain-partitions.md @@ -5,7 +5,7 @@ summary: TiDB のEXPLAINステートメントによって返される実行プ # パーティションを使用したステートメントの説明 {#explain-statements-using-partitions} -`EXPLAIN`文は、TiDBがクエリを実行するためにアクセスする必要があるパーティションを表示します。3 [パーティションプルーニング](/partition-pruning.md)のため、表示されるパーティションはパーティション全体のサブセットのみであることがよくあります。このドキュメントでは、一般的なパーティションテーブルに対する最適化のいくつかと、 `EXPLAIN`の出力の解釈方法について説明します。 +`EXPLAIN`文は、TiDBがクエリを実行するためにアクセスする必要があるパーティションを表示します。[パーティションプルーニング](/partition-pruning.md)のため、表示されるパーティションはパーティション全体のサブセットのみであることがよくあります。このドキュメントでは、一般的なパーティションテーブルに対する最適化のいくつかと、 `EXPLAIN`の出力の解釈方法について説明します。 このドキュメントで使用されているサンプル データ: diff --git a/explain-subqueries.md b/explain-subqueries.md index 0e9e7f467dc7f..e67476e74f32f 100644 --- a/explain-subqueries.md +++ b/explain-subqueries.md @@ -47,7 +47,7 @@ ANALYZE TABLE t1, t2, t3; ## 内部結合（一意でないサブクエリ） {#inner-join-non-unique-subquery} -次の例では、 `IN`サブクエリがテーブル`t2`からIDのリストを検索します。セマンティクスの正確性を保つため、TiDBは列`t1_id`一意であることを保証する必要があります。7 `EXPLAIN`のサブクエリを使用すると、重複を削除して`INNER JOIN`操作を実行するための実行プランを確認できます。 +次の例では、 `IN`サブクエリがテーブル`t2`からIDのリストを検索します。セマンティクスの正確性を保つため、TiDBは列`t1_id`一意であることを保証する必要があります。`EXPLAIN`のサブクエリを使用すると、重複を削除して`INNER JOIN`操作を実行するための実行プランを確認できます。 ```sql EXPLAIN SELECT * FROM t1 WHERE id IN (SELECT t1_id FROM t2); diff --git a/explain-walkthrough.md b/explain-walkthrough.md index a9c5823245829..0e6e5c0ddc01a 100644 --- a/explain-walkthrough.md +++ b/explain-walkthrough.md @@ -39,9 +39,9 @@ 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`実行して統計情報を収集すると、統計の精度が向上することが期待されます。 -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)参照してください。 +2. 述語`WHERE start_date BETWEEN ..`は演算子`Selection_19`でフィルタリングされます。この選択に該当する行は約`250`行と推定されます。この数は統計情報と演算子のロジックに基づいて推定されることに注意してください。演算子`└─TableFullScan_18`には`stats:pseudo`と表示されますが、これはテーブルに実際の統計情報が存在しないことを意味します。`ANALYZE TABLE trips`を実行して統計情報を収集すると、統計の精度が向上することが期待されます。 +3. 選択基準を満たす行には、関数`count`が適用されます。これも演算子`StreamAgg_9`内で完了しますが、この演算子も 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 行になります。これはルート演算子であるため、結果をクライアントに返します。 > **Note:** @@ -95,7 +95,7 @@ Query OK, 0 rows affected (10.22 sec) `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 が統計情報をどの程度健全であると見なしているか）を確認できます。 +`ANALYZE TABLE`に加えて、TiDB はしきい値[`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio)に達した後、バックグラウンド操作として統計情報を自動的に再生成します。[`SHOW STATS_HEALTHY`](/sql-statements/sql-statement-show-stats-healthy.md)ステートメントを実行すると、TiDB がこのしきい値にどれだけ近いか（TiDB が統計情報をどの程度健全であると見なしているか）を確認できます。 ```sql SHOW STATS_HEALTHY; @@ -118,7 +118,7 @@ SHOW STATS_HEALTHY; - TiDB ( `StreamAgg_20` )とTiKV ( `└─StreamAgg_9` )の両方で行数を集計するには、メモリ使用量の面で非常に効率的なストリーム集計を使用します。 -現在の実行プランの最大の問題は、述語`start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59'`すぐに適用されないことです。まず演算子`TableFullScan`ですべての行が読み込まれ、その後選択が適用されます。5 `SHOW CREATE TABLE trips`出力から原因がわかります。 +現在の実行プランの最大の問題は、述語`start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59'`すぐに適用されないことです。まず演算子`TableFullScan`ですべての行が読み込まれ、その後選択が適用されます。`SHOW CREATE TABLE trips`出力から原因がわかります。 ```sql SHOW CREATE TABLE trips\G diff --git a/exporting-grafana-snapshots.md b/exporting-grafana-snapshots.md index c4461b0b7c205..fe84274c75c49 100644 --- a/exporting-grafana-snapshots.md +++ b/exporting-grafana-snapshots.md @@ -14,7 +14,7 @@ summary: Grafana ダッシュボードのスナップショットをエクスポ > > 現在、MetricsToolはGrafana v6.xxでのみ使用できます。 -メトリクスデータはトラブルシューティングにおいて重要です。リモートアシスタンスを依頼した場合、サポートスタッフが問題を診断するためにGrafanaダッシュボードを確認する必要がある場合があります。1 [メトリクスツール](https://metricstool.pingcap.net/) 、Grafanaダッシュボードのスナップショットをローカルファイルとしてエクスポートし、可視化するのに役立ちます。これらのスナップショットを外部の担当者と共有することで、Grafanaサーバー上の他の機密情報へのアクセスを外部に漏らすことなく、グラフを正確に読み取ることができます。 +メトリクスデータはトラブルシューティングにおいて重要です。リモートアシスタンスを依頼した場合、サポートスタッフが問題を診断するためにGrafanaダッシュボードを確認する必要がある場合があります。[メトリクスツール](https://metricstool.pingcap.net/)は、Grafanaダッシュボードのスナップショットをローカルファイルとしてエクスポートし、可視化するのに役立ちます。これらのスナップショットを外部の担当者と共有することで、Grafanaサーバー上の他の機密情報へのアクセスを外部に漏らすことなく、グラフを正確に読み取ることができます。 ## 使用法 {#usage} diff --git a/extended-statistics.md b/extended-statistics.md index 25f3c3b595807..04c39d7f1e875 100644 --- a/extended-statistics.md +++ b/extended-statistics.md @@ -156,4 +156,4 @@ SELECT * FROM t WHERE col1 <= 1 OR col1 IS NULL; 前のクエリ結果に1を加えたものが、最終的な行数の推定値となります。これにより、独立仮定を用いる必要がなくなり、**大きな推定誤差を回避できます**。 -相関係数（この例では`1` ）がシステム変数`tidb_opt_correlation_threshold`の値より小さい場合、オプティマイザは独立仮定を使用しますが、ヒューリスティックに推定値も増加させます。5 `tidb_opt_correlation_exp_factor`値が大きいほど、推定結果は大きくなります。相関係数の絶対値が大きいほど、推定結果は大きくなります。 +相関係数（この例では`1` ）がシステム変数`tidb_opt_correlation_threshold`の値より小さい場合、オプティマイザは独立仮定を使用しますが、ヒューリスティックに推定値も増加させます。`tidb_opt_correlation_exp_factor`値が大きいほど、推定結果は大きくなります。相関係数の絶対値が大きいほど、推定結果は大きくなります。 diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md index 072ff14e2432a..8b4d351db6024 100644 --- a/faq/backup-and-restore-faq.md +++ b/faq/backup-and-restore-faq.md @@ -269,7 +269,7 @@ br restore full -f 'mysql.usertable' -s $external_storage_url --with-sys-table [テーブルフィルター](/table-filter.md#syntax)設定しても、 **BR は次のシステム テーブルを復元しないこと**に注意してください。 -- 統計表（ `mysql.stat_*` ）。ただし、統計は復元可能です。3 [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)参照してください。 +- 統計表（ `mysql.stat_*` ）。ただし、統計は復元可能です。[統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)を参照してください。 - システム変数テーブル（ `mysql.tidb` `mysql.global_variables` - [その他のシステムテーブル](https://github.com/pingcap/tidb/blob/release-8.5/br/pkg/restore/snap_client/systable_restore.go#L31) diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 63482d8ba1d96..dc42ad44a77ea 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -35,7 +35,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ ## インストールと展開 {#installation-and-deployment} -本番環境では、 [TiUP](/tiup/tiup-overview.md)使用してTiDBクラスタをデプロイすることをお勧めします。3 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)参照してください。 +本番環境では、 [TiUP](/tiup/tiup-overview.md)を使用してTiDBクラスタをデプロイすることをお勧めします。[TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)を参照してください。 ### TiKV/PD 用に変更されたtoml構成が有効にならないのはなぜですか? {#why-the-modified-code-toml-code-configuration-for-tikv-pd-does-not-take-effect} @@ -51,7 +51,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ ### TiDB でスロークエリログを個別に記録するにはどうすればよいですか? スロークエリの SQL ステートメントを見つけるにはどうすればよいでしょうか? {#how-to-separately-record-the-slow-query-log-in-tidb-how-to-locate-the-slow-query-sql-statement} -1. TiDBのスロークエリの定義は、TiDB設定ファイルにあります。1 `tidb_slow_log_threshold: 300`は、スロークエリのしきい値（単位：ミリ秒）を設定するために使用されます。 +1. TiDBのスロークエリの定義は、TiDB設定ファイルにあります。`tidb_slow_log_threshold: 300`は、スロークエリのしきい値（単位：ミリ秒）を設定するために使用されます。 2. スロークエリが発生した場合、Grafana を使用してスロークエリが発生している`tidb-server`インスタンスとスロークエリの時刻を特定し、該当ノードのログに記録された SQL 文の情報を見つけることができます。 diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md index 027d18f160ff0..3658ffc5bb940 100644 --- a/faq/migration-tidb-faq.md +++ b/faq/migration-tidb-faq.md @@ -140,7 +140,7 @@ Sqoopでは、 `--batch`各バッチで100個の`statement`文をコミットす ### transaction too largeエラーメッセージが表示されます {#the-error-message-code-transaction-too-large-code-is-displayed} -基盤となるストレージエンジンの制限により、TiDB の各キーと値のエントリ（1行）は 6MB 以下にする必要があります。1 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)設定値は最大 120MB まで調整できます。 +基盤となるストレージエンジンの制限により、TiDB の各キーと値のエントリ（1行）は 6MB 以下にする必要があります。[`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)設定値は最大 120MB まで調整できます。 分散トランザクションは2相コミットを必要とし、最下層でRaftレプリケーションを実行します。トランザクションが非常に大きい場合、コミットプロセスは非常に遅くなり、書き込み競合が発生する可能性が高くなります。さらに、失敗したトランザクションのロールバックは、不要なパフォーマンスの低下につながります。これらの問題を回避するため、デフォルトでは、トランザクション内のキーと値のエントリの合計サイズを100MB以下に制限しています。より大きなトランザクションが必要な場合は、TiDB設定ファイルの値`txn-total-size-limit`変更してください。この設定項目の最大値は10GBです。実際の制限は、マシンの物理メモリにも影響されます。 @@ -152,7 +152,7 @@ Google Cloud Spanner には[同様の制限](https://cloud.google.com/spanner/do ### TiDB はデータを削除した後すぐにスペースを解放しますか? {#does-tidb-release-space-immediately-after-deleting-data} -`DELETE` `TRUNCATE`操作`DROP`いずれもデータを即時に解放しません。7と`TRUNCATE` `DROP`操作では、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。11 `DELETE`操作では、データは削除されますが、TiDB GCに従って領域は解放されません。後続のデータがRocksDBに書き込まれ、 `COMPACT`実行されると、領域は再利用されます。 +`DELETE` 、 `TRUNCATE` 、 `DROP`操作はいずれもデータを即時に解放しません。`TRUNCATE`と`DROP`操作では、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。`DELETE`操作では、データは削除されますが、TiDB GCに従って領域は解放されません。後続のデータがRocksDBに書き込まれ、 `COMPACT`が実行されると、領域は再利用されます。 ### データをロードするときに、ターゲット テーブルで DDL 操作を実行できますか? {#can-i-execute-ddl-operations-on-the-target-table-when-loading-data} @@ -170,7 +170,7 @@ Google Cloud Spanner には[同様の制限](https://cloud.google.com/spanner/do 大量のデータを削除する場合は、 `Delete from t where xx limit 5000;`使用をお勧めします。これはループを通して削除を行い、 `Affected Rows == 0`ループ終了条件として使用することで、トランザクションサイズの制限を超えないようにします。ビジネスフィルタリングロジックを満たすことを前提として、強力なフィルターインデックス列を追加するか、 `id >= 5000*n+m and id < 5000*(n+1)+m`のように主キーを直接使用して範囲を選択することをお勧めします。 -一度に削除する必要があるデータの量が非常に多い場合、このループメソッドは削除処理が後方に移動するにつれて速度が低下します。前のデータを削除した後、多くの削除フラグが短期間残り（その後、すべてガベージコレクションによって処理されます）、後続のDelete文に影響を与えます。可能であれば、Where条件を絞り込むことをお勧めします。1 [詳細はTiDBベストプラクティスをご覧ください](https://www.pingcap.com/blog/tidb-best-practice/#write)参照してください。 +一度に削除する必要があるデータの量が非常に多い場合、このループメソッドは削除処理が後方に移動するにつれて速度が低下します。前のデータを削除した後、多くの削除フラグが短期間残り（その後、すべてガベージコレクションによって処理されます）、後続のDelete文に影響を与えます。可能であれば、Where条件を絞り込むことをお勧めします。[詳細はTiDBベストプラクティスをご覧ください](https://www.pingcap.com/blog/tidb-best-practice/#write)を参照してください。 ### TiDB のデータ読み込み速度を向上させるにはどうすればよいでしょうか? {#how-to-improve-the-data-loading-speed-in-tidb} diff --git a/faq/monitor-faq.md b/faq/monitor-faq.md index 676c6b5bc567a..3a5238b0ee953 100644 --- a/faq/monitor-faq.md +++ b/faq/monitor-faq.md @@ -22,7 +22,7 @@ TiDBの監視システムは、PrometheusとGrafanaで構成されています ## リージョンヘルスモニター {#region-health-monitor} -TiDB 2.0では、リージョンの健全性はPDメトリック監視ページで監視されます。監視項目`Region Health`には、すべてのリージョンレプリカのステータスの統計が表示されます。3 `miss`レプリカ不足、 `extra`レプリカが不足していることを示します。さらに、 `Region Health`分離レベル`label`も示します。11 `level-1` 、リージョンレプリカが最初の`label`レベルで物理的に分離されていることを示します。17 `location label`設定されていない場合、すべてのリージョンは`level-0`になります。 +TiDB 2.0では、リージョンの健全性はPDメトリック監視ページで監視されます。監視項目`Region Health`には、すべてのリージョンレプリカのステータスの統計が表示されます。`miss`はレプリカ不足、 `extra`は余分なレプリカが存在することを示します。さらに、 `Region Health`は`label`による分離レベルも示します。`level-1`は、リージョンレプリカが最初の`label`レベルで物理的に分離されていることを示します。`location label`が設定されていない場合、すべてのリージョンは`level-0`になります。 ## ステートメントカウントモニターのselectsimplefullの意味は何ですか? {#what-is-the-meaning-of-code-selectsimplefull-code-in-statement-count-monitor} diff --git a/faq/sql-faq.md b/faq/sql-faq.md index 90db954e13360..d0e04a2380dab 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -180,7 +180,7 @@ Sqoopでは、 `--batch`各バッチで100文をコミットすることを意 ## TiDB はデータを削除した直後にスペースを解放しますか? {#does-tidb-release-space-immediately-after-deleting-data} -`DELETE` `TRUNCATE`操作はいずれもデータ`DROP` `TRUNCATE` `DROP`は、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。11 `DELETE`操作では、データは削除されますが、圧縮が実行されるまで領域は即時に解放されません。 +`DELETE` 、 `TRUNCATE` 、 `DROP`操作はいずれもデータを即時に解放しません。`TRUNCATE`と`DROP`操作では、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。`DELETE`操作では、データは削除されますが、圧縮が実行されるまで領域は即時に解放されません。 ## データを削除するとクエリ速度が遅くなるのはなぜですか? {#why-does-the-query-speed-get-slow-after-data-is-deleted} @@ -194,7 +194,7 @@ TiDBはマルチバージョン同時実行制御（MVCC）を使用している TiDB `SHOW PROCESSLIST`の表示内容は MySQL `SHOW PROCESSLIST`とほぼ同じです。TiDB `SHOW PROCESSLIST`ではシステムプロセスIDが表示されません。表示されるのは現在のセッションIDです。TiDB `SHOW PROCESSLIST`と MySQL `SHOW PROCESSLIST`の違いは次のとおりです。 -- TiDBは分散データベースであるため、 `tidb-server`インスタンスはSQL文を解析および実行するためのステートレスエンジンです（詳細は[TiDBアーキテクチャ](/tidb-architecture.md)を参照）。5 `SHOW PROCESSLIST` 、ユーザーがMySQLクライアントからログインした`tidb-server`インスタンスで実行されたセッションリストを表示します。クラスタ内で実行されているすべてのセッションのリストではありません。ただし、MySQLはスタンドアロンデータベースであり、 `SHOW PROCESSLIST`はMySQLで実行されたすべてのSQL文を表示します。 +- TiDBは分散データベースであるため、 `tidb-server`インスタンスはSQL文を解析および実行するためのステートレスエンジンです（詳細は[TiDBアーキテクチャ](/tidb-architecture.md)を参照）。`SHOW PROCESSLIST` 、ユーザーがMySQLクライアントからログインした`tidb-server`インスタンスで実行されたセッションリストを表示します。クラスタ内で実行されているすべてのセッションのリストではありません。ただし、MySQLはスタンドアロンデータベースであり、 `SHOW PROCESSLIST`はMySQLで実行されたすべてのSQL文を表示します。 - TiDBの`State`列は、クエリ実行中に継続的に更新されるわけではありません。TiDBは並列クエリをサポートしているため、各ステートメントが複数の*状態*にある場合があり、単一の値に単純化することが困難です。 ## SQL コミットの実行優先度を制御または変更するにはどうすればよいですか? {#how-to-control-or-change-the-execution-priority-of-sql-commits} @@ -413,7 +413,7 @@ SELECT 'café' = 'cafe' COLLATE utf8mb4_0900_ai_ci; -- Returns 1 (TRUE) 推奨事項: -- ハードウェア構成を改善してください。1 [TiDB のソフトウェアおよびハードウェア要件](/hardware-and-software-requirements.md)参照してください。 +- ハードウェア構成を改善してください。[TiDB のソフトウェアおよびハードウェア要件](/hardware-and-software-requirements.md)を参照してください。 - 同時実行性を向上させます。デフォルト値は10です。50に上げて試してみることもできますが、通常はデフォルト値の2～4倍の改善が見られます。 - 大量のデータの場合は`count`をテストします。 - TiKV設定を最適化します。1と[TiKVメモリパフォーマンスの調整](/tune-tikv-memory-performance.md) [TiKVスレッドのパフォーマンスを調整する](/tune-tikv-thread-performance.md)参照してください。 @@ -439,7 +439,7 @@ ADMIN SHOW DDL; - `ADMIN SHOW DDL` : 実行中のDDLジョブを表示する - `ADMIN SHOW DDL JOBS` : 現在の DDL ジョブ キュー内のすべての結果 (実行中および実行待ちのタスクを含む) と、完了した DDL ジョブ キューの最後の 10 件の結果を表示します。 -- `ADMIN SHOW DDL JOBS QUERIES 'job_id' [, 'job_id'] ...` : `job_id`に対応する DDL タスクの元の SQL ステートメントを表示します。4 `job_id`実行中の DDL ジョブと DDL 履歴ジョブ キュー内の最後の 10 件の結果のみを検索します。 +- `ADMIN SHOW DDL JOBS QUERIES 'job_id' [, 'job_id'] ...` : `job_id`に対応する DDL タスクの元の SQL ステートメントを表示します。`job_id`実行中の DDL ジョブと DDL 履歴ジョブ キュー内の最後の 10 件の結果のみを検索します。 ### TiDB は CBO (コストベース最適化) をサポートしていますか? サポートしている場合、どの程度サポートしていますか? {#does-tidb-support-cbo-cost-based-optimization-if-yes-to-what-extent} @@ -457,9 +457,9 @@ ADMIN SHOW DDL; 現在、 TiDB のコンピューティング タスクは、タスク`cop task`と`root task`の 2 つの異なるタイプに属しています。 -`cop task`は、分散実行のために KV エンドにプッシュダウンされるコンピューティング タスクです。2 `root task` 、TiDB エンドでの単一ポイント実行のためのコンピューティング タスクです。 +`cop task`は、分散実行のために KV エンドにプッシュダウンされるコンピューティング タスクです。`root task` 、TiDB エンドでの単一ポイント実行のためのコンピューティング タスクです。 -通常、 `root task`の入力データは`cop task`から取得されます。5 `root task`データを処理している間、TiKVの`cop task`同時にデータを処理し、TiDBの`root task`からのプルを待機します。したがって、 `cop`タスクは`root task`と並行して実行されていると見なすことができますが、それらのデータには上流と下流の関係があります。実行プロセス中、それらはしばらくの間並行して実行されます。たとえば、最初の`cop task`は[100, 200]のデータを処理し、2番目の`cop task`は[1, 100]のデータを処理します。詳細は[TiDBクエリプランの理解](/explain-overview.md)参照してください。 +通常、 `root task`の入力データは`cop task`から取得されます。`root task`データを処理している間、TiKVの`cop task`同時にデータを処理し、TiDBの`root task`からのプルを待機します。したがって、 `cop`タスクは`root task`と並行して実行されていると見なすことができますが、それらのデータには上流と下流の関係があります。実行プロセス中、それらはしばらくの間並行して実行されます。たとえば、最初の`cop task`は[100, 200]のデータを処理し、2番目の`cop task`は[1, 100]のデータを処理します。詳細は[TiDBクエリプランの理解](/explain-overview.md)を参照してください。 ## データベースの最適化 {#database-optimization} diff --git a/faq/tidb-faq.md b/faq/tidb-faq.md index 250fafed4f2c1..d79460d058afb 100644 --- a/faq/tidb-faq.md +++ b/faq/tidb-faq.md @@ -49,7 +49,7 @@ TiDBクラスタは、TiDBサーバー、PD（Placement Driver）サーバー、 はい。TiDB は、単一の場所に少数のノードがある場合でも、多数の[複数のデータセンターにまたがるノード](/multi-data-centers-in-one-city-deployment.md)がある場合でも、クラスター全体にトランザクションを分散します。 -GoogleのPercolatorに着想を得たTiDBのトランザクションモデルは、主に2フェーズコミットプロトコルをベースに、実用的な最適化が施されています。このモデルは、タイムスタンプアロケータを利用して各トランザクションに単調増加するタイムスタンプを割り当てることで、競合を検出します。1 [PD](/tidb-architecture.md#placement-driver-pd-server) TiDBクラスタ内でタイムスタンプアロケータとして機能します。 +GoogleのPercolatorに着想を得たTiDBのトランザクションモデルは、主に2フェーズコミットプロトコルをベースに、実用的な最適化が施されています。このモデルは、タイムスタンプアロケータを利用して各トランザクションに単調増加するタイムスタンプを割り当てることで、競合を検出します。[PD](/tidb-architecture.md#placement-driver-pd-server)は、TiDBクラスタ内でタイムスタンプアロケータとして機能します。 ### TiDB を操作するためにどのプログラミング言語を使用できますか? {#what-programming-language-can-i-use-to-work-with-tidb} diff --git a/filter-dml-event.md b/filter-dml-event.md index 41f9fbee380e5..62826c2288ebf 100644 --- a/filter-dml-event.md +++ b/filter-dml-event.md @@ -41,7 +41,7 @@ expression-filter: INSERT INTO tbl(id, c) VALUES (1, 1), (2, 2), (3, 3), (4, 4); ``` -次に、下流のテーブル`tb1`に対してクエリを実行します。3 `c`奇数行のみがレプリケートされていることがわかります。 +次に、下流のテーブル`tb1`に対してクエリを実行します。`c`奇数行のみがレプリケートされていることがわかります。 ```sql MySQL [test]> select * from tbl; @@ -71,7 +71,7 @@ MySQL [test]> select * from tbl; SQL式は1つの列でも複数の列でも使用できます。また、TiDBでサポートされているSQL関数（ `c % 2 = 0` 、 `a*a + b*b = c*c` 、 `ts > NOW()`など）も使用できます。 -`TIMESTAMP`デフォルトタイムゾーンは、タスク設定ファイルで指定されたタイムゾーンです。デフォルト値はダウンストリームのタイムゾーンです。3 `c_timestamp = '2021-01-01 12:34:56.5678+08:00'`ように明示的にタイムゾーンを指定することもできます。 +`TIMESTAMP`デフォルトタイムゾーンは、タスク設定ファイルで指定されたタイムゾーンです。デフォルト値はダウンストリームのタイムゾーンです。`c_timestamp = '2021-01-01 12:34:56.5678+08:00'`ように明示的にタイムゾーンを指定することもできます。 `expression-filter`設定項目で複数のフィルタリングルールを設定できます。上流データソースは、 `expression-filters`の必要なルールを参照してルールを有効にします。複数のルールを使用する場合、**いずれ**かのルールに一致すると、行の変更全体がフィルタリングされます。 diff --git a/follower-read.md b/follower-read.md index ef8470a19d85b..940374b0262b8 100644 --- a/follower-read.md +++ b/follower-read.md @@ -15,7 +15,7 @@ Follower Read を実行する際、TiDBはトポロジ情報に基づいて適 -Follower Read を実行する際、TiDB はトポロジ情報に基づいて適切なレプリカを選択します。具体的には、TiDB はラベル`zone`を用いてローカルレプリカを識別します。TiDB ノードのラベル`zone`がターゲット TiKV ノードのラベル 3 と同じ場合、TiDB はそのレプリカをローカルレプリカと見なします。ラベル`zone`はTiDB Cloudで自動的に設定されます。 +Follower Read を実行する際、TiDB はトポロジ情報に基づいて適切なレプリカを選択します。具体的には、TiDB はラベル`zone`を用いてローカルレプリカを識別します。TiDB ノードのラベル`zone`がターゲット TiKV ノードのラベルと同じ場合、TiDB はそのレプリカをローカルレプリカと見なします。ラベル`zone`はTiDB Cloudで自動的に設定されます。 diff --git a/functions-and-operators/aggregate-group-by-functions.md b/functions-and-operators/aggregate-group-by-functions.md index 5336e0f6624bb..aecb2d5633943 100644 --- a/functions-and-operators/aggregate-group-by-functions.md +++ b/functions-and-operators/aggregate-group-by-functions.md @@ -34,7 +34,7 @@ summary: TiDB でサポートされている集計関数について学習しま - `APPROX_PERCENTILE(expr, constant_integer_expr)` - この関数は`expr`のパーセンタイルを返します。引数`constant_integer_expr`は、 5 から`[1,100]`の範囲の定数整数であるパーセンタイル値を示します。パーセンタイル P k （ `k`はパーセンタイルを表します）は、データセット内に P k以下の値が少なくとも`k%`あることを示します。 + この関数は`expr`のパーセンタイルを返します。引数`constant_integer_expr`は、 `[1,100]`の範囲の定数整数であるパーセンタイル値を示します。パーセンタイル P k （ `k`はパーセンタイルを表します）は、データセット内に P k以下の値が少なくとも`k%`あることを示します。 この関数は、 `expr`の戻り値の型として[数値型](/data-type-numeric.md)と[日付と時刻の種類](/data-type-date-and-time.md)をサポートします。その他の戻り値の型については、 `APPROX_PERCENTILE` `NULL`を返します。 @@ -61,7 +61,7 @@ summary: TiDB でサポートされている集計関数について学習しま - `APPROX_COUNT_DISTINCT(expr, [expr...])` - この関数は、異なる値の数を数える点では`COUNT(DISTINCT)`に似ていますが、近似値を返します。3 `BJKST`アルゴリズムを使用することで、べき乗分布を持つ大規模なデータセットを処理する際のメモリ消費量を大幅に削減します。さらに、低カーディナリティデータの場合、この関数はCPU使用率を効率的に維持しながら高い精度を実現します。 + この関数は、異なる値の数を数える点では`COUNT(DISTINCT)`に似ていますが、近似値を返します。`BJKST`アルゴリズムを使用することで、べき乗分布を持つ大規模なデータセットを処理する際のメモリ消費量を大幅に削減します。さらに、低カーディナリティデータの場合、この関数はCPU使用率を効率的に維持しながら高い精度を実現します。 次の例は、この関数の使用方法を示しています。 @@ -91,7 +91,7 @@ TiDB v7.4.0以降、 `GROUP BY`句は`WITH ROLLUP`修飾子をサポートしま ## SQLモードのサポート {#sql-mode-support} -TiDBはSQLモード`ONLY_FULL_GROUP_BY`をサポートしており、有効にすると、曖昧な非集計列を含むクエリを拒否します。例えば、次のクエリは`ONLY_FULL_GROUP_BY`が有効になっていると無効になります。5 `SELECT`のリストにある非集計列「b」が`GROUP BY`ステートメントに含まれていないためです。 +TiDBはSQLモード`ONLY_FULL_GROUP_BY`をサポートしており、有効にすると、曖昧な非集計列を含むクエリを拒否します。例えば、次のクエリは`ONLY_FULL_GROUP_BY`が有効になっていると無効になります。`SELECT`のリストにある非集計列「b」が`GROUP BY`ステートメントに含まれていないためです。 ```sql drop table if exists t; diff --git a/functions-and-operators/cast-functions-and-operators.md b/functions-and-operators/cast-functions-and-operators.md index 88476a7c03f5f..9756135831c1f 100644 --- a/functions-and-operators/cast-functions-and-operators.md +++ b/functions-and-operators/cast-functions-and-operators.md @@ -15,7 +15,7 @@ summary: キャスト関数と演算子について学習します。 > **Note:** > -> TiDBとMySQLは、 `SELECT CAST(MeN AS CHAR)` （またはそれに相当する`SELECT CONVERT(MeM, CHAR)` ）の結果に一貫性がありません。5 `MeN`倍精度浮動小数点数（科学的記数法）を表します。MySQLは`-15 <= N <= 14`場合は完全な数値を表示し、 `N < -15`または`N > 14`場合は科学的記数法を表示します。しかし、TiDBは常に完全な数値を表示します。例えば、MySQLでは`SELECT CAST(3.1415e15 AS CHAR)`の結果を`3.1415e15`と表示しますが、TiDBでは`3141500000000000`と表示します。 +> TiDBとMySQLは、 `SELECT CAST(MeN AS CHAR)` （またはそれに相当する`SELECT CONVERT(MeM, CHAR)` ）の結果に一貫性がありません。`MeN`は倍精度浮動小数点数（科学的記数法）を表します。MySQLは`-15 <= N <= 14`の場合は完全な数値を表示し、 `N < -15`または`N > 14`の場合は科学的記数法を表示します。しかし、TiDBは常に完全な数値を表示します。例えば、MySQLでは`SELECT CAST(3.1415e15 AS CHAR)`の結果を`3.1415e15`と表示しますが、TiDBでは`3141500000000000`と表示します。 ## バイナリ {#binary} @@ -35,7 +35,7 @@ MySQL 8.0.27以降、 [`BINARY`](https://dev.mysql.com/doc/refman/8.0/en/cast-fu | `CHAR(n)` | 文字列 | はい、ただし長さが指定されている場合のみ | | `DATE` | 日付 | はい | | `DATETIME(fsp)` | 日付/時刻（ `fsp`はオプション） | はい | -| `DECIMAL(n, m)` | `n`進数。1 と`m`オプションで、指定しない場合は`10`と`0`になります。 | いいえ | +| `DECIMAL(n, m)` | 10進数。`n`と`m`はオプションで、指定しない場合は`10`と`0`になります。 | いいえ | | `DOUBLE` | 倍精度浮動小数点数 | いいえ | | `FLOAT(n)` | 浮動小数点数`n`オプションで、 `0`から`53`の範囲で指定します。 | いいえ | | `JSON` | JSON | いいえ | diff --git a/functions-and-operators/control-flow-functions.md b/functions-and-operators/control-flow-functions.md index 4090a510fb3aa..5dcb9a912cf99 100644 --- a/functions-and-operators/control-flow-functions.md +++ b/functions-and-operators/control-flow-functions.md @@ -87,7 +87,7 @@ SELECT n, IF(n MOD 2, "odd", "even") FROM d; ## IFNULL() {#ifnull} -[`IFNULL(expr1,expr2)`](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#function_ifnull)関数は、クエリ内の NULL 値を処理するために使用されます。3 `expr1` `NULL`でない場合は`expr1`返し、そうでない場合は`expr2`返します。 +[`IFNULL(expr1,expr2)`](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#function_ifnull)関数は、クエリ内の NULL 値を処理するために使用されます。`expr1`が`NULL`でない場合は`expr1`を返し、そうでない場合は`expr2`を返します。 例： diff --git a/functions-and-operators/encryption-and-compression-functions.md b/functions-and-operators/encryption-and-compression-functions.md index 11537a962f906..0807e047b1a29 100644 --- a/functions-and-operators/encryption-and-compression-functions.md +++ b/functions-and-operators/encryption-and-compression-functions.md @@ -185,7 +185,7 @@ SELECT SHA1('abc'); ### `SHA2()` {#sha2} -`SHA2(str, n)`関数は`n` [SHA-2](https://en.wikipedia.org/wiki/SHA-2)ファミリーのアルゴリズムを使用してハッシュを計算します。5 引数はアルゴリズムを選択するために使用されます。7 `SHA2()` 、引数のいずれかが`NULL`の場合、または`n`で選択されたアルゴリズムが不明またはサポートされていない場合、 `NULL`返します。 +`SHA2(str, n)`関数は[SHA-2](https://en.wikipedia.org/wiki/SHA-2)ファミリーのアルゴリズムを使用してハッシュを計算します。`n`引数はアルゴリズムを選択するために使用されます。`SHA2()`は、引数のいずれかが`NULL`の場合、または`n`で選択されたアルゴリズムが不明またはサポートされていない場合、 `NULL`を返します。 サポートされているアルゴリズムは次のとおりです。 diff --git a/functions-and-operators/functions-and-operators-overview.md b/functions-and-operators/functions-and-operators-overview.md index 1185c94a5eec5..1fe0349e6bcd9 100644 --- a/functions-and-operators/functions-and-operators-overview.md +++ b/functions-and-operators/functions-and-operators-overview.md @@ -5,7 +5,7 @@ summary: 関数と演算子の使い方を学びます。 # 関数と演算子のリファレンス {#function-and-operator-reference} -TiDBの関数と演算子の使い方はMySQLと似ています。1 [MySQLの関数と演算子](https://dev.mysql.com/doc/refman/8.0/en/functions.html)参照してください。 +TiDBの関数と演算子の使い方はMySQLと似ています。[MySQLの関数と演算子](https://dev.mysql.com/doc/refman/8.0/en/functions.html)を参照してください。 SQL 文では、 [`SELECT`](/sql-statements/sql-statement-select.md)文の`ORDER BY`と`HAVING`句、 [`SELECT`](/sql-statements/sql-statement-select.md) / [`DELETE`](/sql-statements/sql-statement-delete.md) / [`UPDATE`](/sql-statements/sql-statement-update.md)文の`WHERE`句、 [`SET`](/sql-statements/sql-statement-set-variable.md)文で式を使用できます。 diff --git a/functions-and-operators/group-by-modifier.md b/functions-and-operators/group-by-modifier.md index 2bfaa2988f863..ec78ea73a6c93 100644 --- a/functions-and-operators/group-by-modifier.md +++ b/functions-and-operators/group-by-modifier.md @@ -32,7 +32,7 @@ SELECT count(1) FROM t GROUP BY a,b,c WITH ROLLUP; ## ユースケース {#use-cases} -複数`WITH ROLLUP`列からのデータの集計と要約は、OLAP（オンライン分析処理）シナリオでよく使用されます。1 修飾子を使用すると、集計結果に他の高レベルディメンションからのスーパーサマリー情報を表示する行を追加できます。これにより、スーパーサマリー情報を高度なデータ分析やレポート作成に活用できます。 +複数の列からのデータの集計と要約は、OLAP（オンライン分析処理）シナリオでよく使用されます。`WITH ROLLUP`修飾子を使用すると、集計結果に他の高レベルディメンションからのスーパーサマリー情報を表示する行を追加できます。これにより、スーパーサマリー情報を高度なデータ分析やレポート作成に活用できます。 ## 前提条件 {#prerequisites} @@ -100,7 +100,7 @@ SELECT year, month, SUM(profit) AS profit from bank GROUP BY year, month WITH RO 6 rows in set (0.025 sec) ``` -上記の結果には、年と月の両方、年ごと、全体という異なるディメンションで集計されたデータが含まれています。結果において、 `NULL`値が存在しない行は、その行の`profit`年と月の両方をグループ化して計算されていることを示します。7 列の値が`NULL`で`month`行は、その行の`profit` 1 年間のすべての月を集計して計算されていることを示し、 `year`列の値が`NULL`である行は、その行の`profit`すべての年を集計して計算されていることを示します。 +上記の結果には、年と月の両方、年ごと、全体という異なるディメンションで集計されたデータが含まれています。結果において、 `NULL`値が存在しない行は、その行の`profit`年と月の両方をグループ化して計算されていることを示します。`month`列の値が`NULL`である行は、その行の`profit`が 1 年間のすべての月を集計して計算されていることを示し、 `year`列の値が`NULL`である行は、その行の`profit`すべての年を集計して計算されていることを示します。 具体的には： @@ -124,7 +124,7 @@ SELECT year, month, SUM(profit) AS profit FROM bank GROUP BY year, month WITH RO 3 rows in set (0.02 sec) ``` -`GROUP BY`の列にネイティブ`NULL`値が含まれている場合、 `WITH ROLLUP`の集計結果がクエリ結果を誤解させる可能性があることに注意してください。この問題に対処するには、 `GROUPING()`関数を使用して、ネイティブ`NULL`値と`WITH ROLLUP`によって生成された`NULL`値を区別できます。この関数はグループ化式をパラメータとして受け取り、現在の結果でグループ化式が集計されているかどうかを示す`0`または`1`返します。19 `1`集計されていることを表し、 `0`集計されていないことを表します。 +`GROUP BY`の列にネイティブ`NULL`値が含まれている場合、 `WITH ROLLUP`の集計結果がクエリ結果を誤解させる可能性があることに注意してください。この問題に対処するには、 `GROUPING()`関数を使用して、ネイティブ`NULL`値と`WITH ROLLUP`によって生成された`NULL`値を区別できます。この関数はグループ化式をパラメータとして受け取り、現在の結果でグループ化式が集計されているかどうかを示す`0`または`1`を返します。`1`は集計されていることを表し、 `0`は集計されていないことを表します。 次の例は、 `GROUPING()`関数の使用方法を示しています。 @@ -174,7 +174,7 @@ SELECT year, month, SUM(profit) AS profit, grouping(year) as grp_year, grouping( `Expand`演算子の実装は`Projection`演算子と似ています。違いは、 `Expand`多階層の`Projection`であり、複数階層の射影演算式を含むことです。生データの各行に対して、 `Projection`演算子は結果に 1 行のみを生成しますが、 `Expand`演算子は結果に複数行を生成します（行数は射影演算式のレベル数に等しくなります）。 -次の例は、 TiFlashノードのない TiDB クラスターの実行プランを示しています。3 `Expand`演算子のうちの`task` `root`であり、 `Expand`演算子が TiDB で実行されることを示しています。 +次の例は、 TiFlashノードのない TiDB クラスターの実行プランを示しています。`Expand`演算子のうちの`task` `root`であり、 `Expand`演算子が TiDB で実行されることを示しています。 ```sql EXPLAIN SELECT year, month, grouping(year), grouping(month), SUM(profit) AS profit FROM bank GROUP BY year, month WITH ROLLUP; @@ -191,7 +191,7 @@ EXPLAIN SELECT year, month, grouping(year), grouping(month), SUM(profit) AS prof 6 rows in set (0.00 sec) ``` -次の例は、 TiFlash MPP モードでの実行プランを示しています。3 `Expand`演算子のうち`task` `mpp[tiflash]`であり、これは`Expand`演算子がTiFlashで実行されることを示しています。 +次の例は、 TiFlash MPP モードでの実行プランを示しています。`Expand`演算子のうち`task` `mpp[tiflash]`であり、これは`Expand`演算子がTiFlashで実行されることを示しています。 ```sql EXPLAIN SELECT year, month, grouping(year), grouping(month), SUM(profit) AS profit FROM bank GROUP BY year, month WITH ROLLUP; diff --git a/functions-and-operators/information-functions.md b/functions-and-operators/information-functions.md index 69c4dcd077ed7..0a21868441f75 100644 --- a/functions-and-operators/information-functions.md +++ b/functions-and-operators/information-functions.md @@ -241,7 +241,7 @@ SELECT ROW_COUNT(); ### ユーザー（） {#user} -`USER()`関数は現在の接続のユーザーを返します。5 `USER()`ワイルドカードではなく実際のIPアドレスを表示するため、 `CURRENT_USER()`の出力とは若干異なる場合があります。 +`USER()`関数は現在の接続のユーザーを返します。`USER()`ワイルドカードではなく実際のIPアドレスを表示するため、 `CURRENT_USER()`の出力とは若干異なる場合があります。 ```sql SELECT USER(), CURRENT_USER(); diff --git a/functions-and-operators/json-functions.md b/functions-and-operators/json-functions.md index cb128a98d9522..4b12505d6834f 100644 --- a/functions-and-operators/json-functions.md +++ b/functions-and-operators/json-functions.md @@ -22,7 +22,7 @@ JSON関数を使用して[JSONデータ型](/data-type-json.md)のデータを | [JSON_CONTAINS()](/functions-and-operators/json-functions/json-functions-search.md#json_contains) | 指定された候補JSONドキュメントがターゲットJSONドキュメント内に含まれているかどうかを1または0を返すことで示します。 | | [JSON_CONTAINS_PATH()](/functions-and-operators/json-functions/json-functions-search.md#json_contains_path) | JSONドキュメントに指定されたパスのデータが含まれているかどうかを示す0または1を返します。 | | [JSON_EXTRACT()](/functions-and-operators/json-functions/json-functions-search.md#json_extract) | `path`引数に一致するドキュメントの部分から選択されたJSONドキュメントからデータを返します。 | -| [->](/functions-and-operators/json-functions/json-functions-search.md#-) | 評価パスの後のJSON列から値を返します。1の別名です`JSON_EXTRACT(doc, path_literal)` | +| [->](/functions-and-operators/json-functions/json-functions-search.md#-) | 評価パスの後のJSON列から値を返します。`JSON_EXTRACT(doc, path_literal)`の別名です。 | | [->>](/functions-and-operators/json-functions/json-functions-search.md#--1) | 評価パスの後のJSON列から値を返し、結果を引用符で囲まない`JSON_UNQUOTE(JSON_EXTRACT(doc, path_literal))`の別名。 | | [JSON_KEYS()](/functions-and-operators/json-functions/json-functions-search.md#json_keys) | JSONオブジェクトの最上位レベルの値からキーをJSON配列として返します。パス引数が指定されている場合は、選択したパスから最上位レベルのキーを返します。 | | [JSON_SEARCH()](/functions-and-operators/json-functions/json-functions-search.md#json_search) | JSONドキュメントで文字列の1つまたはすべてに一致するものを検索する | @@ -128,7 +128,7 @@ JSON関数を使用して[JSONデータ型](/data-type-json.md)のデータを | JSONパス | 説明 | 例[`JSON_EXTRACT()`](/functions-and-operators/json-functions/json-functions-search.md#json_extract) | | ------------------------------------- | -------------------------- | ---------------------------------------------------------------------------------------------------- | | `$` | 文書のルート | 完全な文書を返します | -| `$.database` | `database`オブジェクト | `"database"`から始まる完全な構造を返します。3 `"migration_tool"`それ以下の構造は含まれません。 | +| `$.database` | `database`オブジェクト | `"database"`から始まる完全な構造を返します。`"migration_tool"`それ以下の構造は含まれません。 | | `$.database.name` | データベースの名前。 | `"TiDB"` | | `$.database.features` | すべてのデータベース機能 | `["distributed", "scalable", "relational", "cloud native"]` | | `$.database.features[0]` | 最初のデータベース機能。 | `"distributed"` | diff --git a/functions-and-operators/json-functions/json-functions-aggregate.md b/functions-and-operators/json-functions/json-functions-aggregate.md index fb577dfeee191..c5085f38695e4 100644 --- a/functions-and-operators/json-functions/json-functions-aggregate.md +++ b/functions-and-operators/json-functions/json-functions-aggregate.md @@ -11,7 +11,7 @@ TiDB は MySQL 8.0 で利用可能な[2つの集計JSON関数](https://dev.mysql ## `JSON_ARRAYAGG()` {#json-arrayagg} -`JSON_ARRAYAGG(key)`関数は、指定された`key`に従ってキーの値を JSON 配列に集約します。5 `key`通常、式または列名です。 +`JSON_ARRAYAGG(key)`関数は、指定された`key`に従ってキーの値を JSON 配列に集約します。`key`通常、式または列名です。 例： diff --git a/functions-and-operators/json-functions/json-functions-modify.md b/functions-and-operators/json-functions/json-functions-modify.md index fced3289c3acd..d3f8f754cce7e 100644 --- a/functions-and-operators/json-functions/json-functions-modify.md +++ b/functions-and-operators/json-functions/json-functions-modify.md @@ -282,7 +282,7 @@ SELECT JSON_UNQUOTE('"foo"'); +-----------------------+ 1 row in set (0.00 sec) -この関数は[`JSON_EXTRACT()`](/functions-and-operators/json-functions/json-functions-search.md#json_extract)と一緒に使用されることが多いです。以下の例では、最初の例では引用符付きのJSON値を抽出し、2番目の例では2つの関数を組み合わせて引用符を解除しています。3 `JSON_UNQUOTE(JSON_EXTRACT(...))`代わりに[`->>`](/functions-and-operators/json-functions/json-functions-search.md#--1)演算子を使用できることに注意してください。 +この関数は[`JSON_EXTRACT()`](/functions-and-operators/json-functions/json-functions-search.md#json_extract)と一緒に使用されることが多いです。以下の例では、最初の例では引用符付きのJSON値を抽出し、2番目の例では2つの関数を組み合わせて引用符を解除しています。`JSON_UNQUOTE(JSON_EXTRACT(...))`の代わりに[`->>`](/functions-and-operators/json-functions/json-functions-search.md#--1)演算子を使用できることに注意してください。 ```sql SELECT JSON_EXTRACT('{"database": "TiDB"}', '$.database'); diff --git a/functions-and-operators/json-functions/json-functions-return.md b/functions-and-operators/json-functions/json-functions-return.md index 9c7d26964ab81..34f56a1467294 100644 --- a/functions-and-operators/json-functions/json-functions-return.md +++ b/functions-and-operators/json-functions/json-functions-return.md @@ -32,7 +32,7 @@ SELECT JSON_DEPTH('{"weather": {"current": "sunny"}}'); ## `JSON_LENGTH()` {#json-length} -`JSON_LENGTH(json_doc [,path])`番目の関数はJSONドキュメントの長さを返します。3 `path`引数が指定された場合は、パス内の値の長さを返します。 +`JSON_LENGTH(json_doc [,path])`番目の関数はJSONドキュメントの長さを返します。`path`引数が指定された場合は、パス内の値の長さを返します。 例: diff --git a/functions-and-operators/json-functions/json-functions-search.md b/functions-and-operators/json-functions/json-functions-search.md index 3ca624b0e3a37..7fc8bd6f542c5 100644 --- a/functions-and-operators/json-functions/json-functions-search.md +++ b/functions-and-operators/json-functions/json-functions-search.md @@ -184,7 +184,7 @@ FROM ( ## `JSON_KEYS()` {#json-keys} -`JSON_KEYS(json_doc [,path])`関数は、JSONオブジェクトの最上位キーをJSON配列として返します。3 引数`path`指定された場合は、選択されたパスの最上位キーを返します。 +`JSON_KEYS(json_doc [,path])`関数は、JSONオブジェクトの最上位キーをJSON配列として返します。`path`引数が指定された場合は、選択されたパスの最上位キーを返します。 例: diff --git a/functions-and-operators/locking-functions.md b/functions-and-operators/locking-functions.md index ac4970fd8925c..0b07a2cb30555 100644 --- a/functions-and-operators/locking-functions.md +++ b/functions-and-operators/locking-functions.md @@ -15,7 +15,7 @@ TiDB は、MySQL 8.0 で利用可能なユーザー レベル[ロック関数](h | [`IS_FREE_LOCK(lockName)`](https://dev.mysql.com/doc/refman/8.0/en/locking-functions.html#function_is-free-lock) | ロックが空いているかどうかを確認します。 | | [`IS_USED_LOCK(lockName)`](https://dev.mysql.com/doc/refman/8.0/en/locking-functions.html#function_is-used-lock) | ロックが使用中かどうかを確認します。使用中の場合、対応する接続IDを返します。 | | [`RELEASE_ALL_LOCKS()`](https://dev.mysql.com/doc/refman/8.0/en/locking-functions.html#function_release-all-locks) | 現在のセッションによって保持されているすべてのロックを解除します。 | -| [`RELEASE_LOCK(lockName)`](https://dev.mysql.com/doc/refman/8.0/en/locking-functions.html#function_release-lock) | 以前に取得したロックを解除します。1 `lockName`パラメータは64文字以内でなければなりません。 | +| [`RELEASE_LOCK(lockName)`](https://dev.mysql.com/doc/refman/8.0/en/locking-functions.html#function_release-lock) | 以前に取得したロックを解除します。`lockName`パラメータは64文字以内でなければなりません。 | ## MySQLの互換性 {#mysql-compatibility} diff --git a/functions-and-operators/precision-math.md b/functions-and-operators/precision-math.md index 690b9942bcb54..cb449f07be042 100644 --- a/functions-and-operators/precision-math.md +++ b/functions-and-operators/precision-math.md @@ -44,11 +44,11 @@ DECIMAL 列の値は、9桁の小数点を4バイトにパックするバイナ | 5～6 | 3 | | 7～9 | 4 | -例えば、 `DECIMAL(18,9)`列は小数点の両側に9桁ずつあるため、整数部と小数部はそれぞれ4バイト必要です。3 `DECIMAL(20,6)`列は14桁の整数部と6桁の小数部で構成されます。整数部は9桁で4バイト、残りの5桁で3バイト必要です。小数部は6桁で3バイト必要です。 +例えば、 `DECIMAL(18,9)`列は小数点の両側に9桁ずつあるため、整数部と小数部はそれぞれ4バイト必要です。`DECIMAL(20,6)`列は14桁の整数部と6桁の小数部で構成されます。整数部は9桁で4バイト、残りの5桁で3バイト必要です。小数部は6桁で3バイト必要です。 -DECIMAL列には、先頭の`+`文字目、 `-`文字目、または先頭の`0`桁目は格納されません。9 `DECIMAL(5,1)`列に`+0003.1`挿入した場合、 `3.1`として格納されます。負の数の場合、リテラルの`-`文字目は格納されません。 +DECIMAL列には、先頭の`+`文字目、 `-`文字目、または先頭の`0`桁目は格納されません。`DECIMAL(5,1)`列に`+0003.1`挿入した場合、 `3.1`として格納されます。負の数の場合、リテラルの`-`文字目は格納されません。 -DECIMAL列では、列定義で指定された範囲を超える値は許可されません。例えば、 `DECIMAL(3,0)`列は`-999`から`999`までの範囲をサポートします。7 `DECIMAL(M,D)`列では、小数点の左側に最大`M - D`桁までしか許可されません。 +DECIMAL列では、列定義で指定された範囲を超える値は許可されません。例えば、 `DECIMAL(3,0)`列は`-999`から`999`までの範囲をサポートします。`DECIMAL(M,D)`列では、小数点の左側に最大`M - D`桁までしか許可されません。 DECIMAL 値の内部形式の詳細については、TiDB ソース コードの[`mydecimal.go`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/types/mydecimal.go)参照してください。 diff --git a/functions-and-operators/set-operators.md b/functions-and-operators/set-operators.md index 6b17f7d878ea4..517345391c29d 100644 --- a/functions-and-operators/set-operators.md +++ b/functions-and-operators/set-operators.md @@ -22,7 +22,7 @@ SELECT 1 UNION SELECT 2; 2 rows in set (0.00 sec) ``` -TiDB は`UNION DISTINCT`と`UNION ALL`両方の演算子をサポートします。5 `UNION DISTINCT`結果セットから重複レコードを削除し、 `UNION ALL`重複を含むすべてのレコードを保持します。TiDB では`UNION DISTINCT`デフォルトで使用されます。 +TiDB は`UNION DISTINCT`と`UNION ALL`両方の演算子をサポートします。`UNION DISTINCT`結果セットから重複レコードを削除し、 `UNION ALL`重複を含むすべてのレコードを保持します。TiDB では`UNION DISTINCT`デフォルトで使用されます。 ```sql CREATE TABLE t1 (a int); diff --git a/functions-and-operators/string-functions.md b/functions-and-operators/string-functions.md index bf33fc04d5a2b..9f48e8a709b06 100644 --- a/functions-and-operators/string-functions.md +++ b/functions-and-operators/string-functions.md @@ -537,8 +537,8 @@ SELECT FIND_IN_SET('Go', 'COBOL,BASIC,Rust,Go,Java,Fortran'); 引数: - `X` : 書式設定する数値。数値、数値文字列、または科学的記数法の数値を指定できます。 -- `D` : 返される値の小数点以下の桁数。この関数は、数値を小数点以下`X`から`D`桁に丸めます。8 `X`実際の小数点以下の桁数よりも`D`大きい場合、結果の長さに合わせて0が補われます。 -- `[locale]` : 小数点の区切り、千単位の区切り、および結果の数値の区切りに使用するロケール設定を指定します。有効なロケール値は、システム変数[`lc_time_names`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_lc_time_names)の有効な値と同じです。指定されていない場合、または地域設定が`NULL`場合、デフォルトで地域設定`'en_US'`が使用されます。この引数はオプションです。 +- `D` : 返される値の小数点以下の桁数。この関数は、数値を小数点以下`X`から`D`桁に丸めます。`X`実際の小数点以下の桁数よりも`D`大きい場合、結果の長さに合わせて0が補われます。 +- `[locale]` : 小数点の区切り、千単位の区切り、および結果の数値の区切りに使用するロケール設定を指定します。有効なロケール値は、システム変数[`lc_time_names`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_lc_time_names)の有効な値と同じです。指定されていない場合、または地域設定が`NULL`の場合、デフォルトで地域設定`'en_US'`が使用されます。この引数はオプションです。 動作: @@ -819,7 +819,7 @@ SELECT INSTR(0123, "12"); LEFT(`str`, `len`) ``` -- `str` : 文字を抽出する元の文字列。2 `str`マルチバイト文字が含まれている場合、関数はそれを単一のコードポイントとしてカウントします。 +- `str` : 文字を抽出する元の文字列。`str`マルチバイト文字が含まれている場合、関数はそれを単一のコードポイントとしてカウントします。 - `len` : 返される文字の長さ。 - `len` 0 以下の場合、関数は空の文字列を返します。 - `len` `str`の長さ以上である場合、関数は元の`str`を返します。 @@ -928,7 +928,7 @@ SELECT LENGTH(NULL); ### `LIKE` {#like} -`LIKE`演算子は単純な文字列マッチングに使用されます。式`expr LIKE pat [ESCAPE 'escape_char']` `1` ( `TRUE` ) または`0` ( `FALSE` ) を返します。13 または`expr` `pat`いずれかが`NULL`の場合、結果は`NULL`なります。 +`LIKE`演算子は単純な文字列マッチングに使用されます。式`expr LIKE pat [ESCAPE 'escape_char']` `1` ( `TRUE` ) または`0` ( `FALSE` ) を返します。`expr`または`pat`のいずれかが`NULL`の場合、結果は`NULL`になります。 `LIKE`では次の 2 つのワイルドカード パラメータを使用できます。 @@ -1360,8 +1360,8 @@ SELECT CONCAT('«',LTRIM(' hello'),'»'); MAKE_SET(bits, str1, str2, ...) ``` -- `bits` : 結果セットに含める後続の文字列引数を制御します。2 `bits` `NULL`に設定されている場合、関数は`NULL`返します。 -- `str1, str2, ...` : 文字列のリスト。各文字列は、引数`bits`右から左へのビットに対応します。4 `str1`右から最初のビット、 `str2`右から2番目のビットに対応し、以下同様です。対応するビットが`1`の場合、文字列は結果に含まれます。それ以外の場合は含まれません。 +- `bits` : 結果セットに含める後続の文字列引数を制御します。`bits` `NULL`に設定されている場合、関数は`NULL`を返します。 +- `str1, str2, ...` : 文字列のリスト。各文字列は、引数`bits`右から左へのビットに対応します。`str1`右から最初のビット、 `str2`右から2番目のビットに対応し、以下同様です。対応するビットが`1`の場合、文字列は結果に含まれます。それ以外の場合は含まれません。 例: @@ -1434,7 +1434,7 @@ SELECT MAKE_SET(b'111','foo','bar','baz'); `MID(str, pos[, len])`関数は、指定された`pos`位置から始まり、長さが`len`部分文字列を返します。 -TiDB v8.4.0以降、2つの引数を持つバリアント`MID(str, pos)`がサポートされます。3 `len`指定されていない場合、この関数は指定された`pos`番目の位置から文字列の末尾までの残りのすべての文字を返します。 +TiDB v8.4.0以降、2つの引数を持つバリアント`MID(str, pos)`がサポートされます。`len`が指定されていない場合、この関数は指定された`pos`番目の位置から文字列の末尾までの残りのすべての文字を返します。 引数のいずれかが`NULL`の場合、関数は`NULL`返します。 @@ -2229,13 +2229,13 @@ SELECT UPPER('bigdata') AS result_upper, UPPER(null) AS result_null; WEIGHT_STRING(str [AS {CHAR|BINARY}(N)]) ``` -- `str` : 入力文字列式。2、4、6 `TEXT`の非バイナリ文字列の場合、戻り値`VARCHAR`は文字列の照合順序重みが含まれます。8、10、12 `BLOB`の`BINARY` `VARBINARY`列の場合、戻り値`CHAR`入力値と同じになります。 +- `str` : 入力文字列式。`CHAR` 、 `VARCHAR` 、 `TEXT`などの非バイナリ文字列の場合、戻り値には文字列の照合順序重みが含まれます。`BINARY` 、 `VARBINARY` 、 `BLOB`などのバイナリ文字列の場合、戻り値は入力値と同じになります。 -- `AS {CHAR|BINARY}(N)` : 出力のタイプと長さを指定するために使用されるオプションのパラメータ。2 `CHAR`文字データ型を表し、 `BINARY`バイナリ データ型を表します。6 `N`出力長を指定します。これは 1 以上の整数です。 +- `AS {CHAR|BINARY}(N)` : 出力のタイプと長さを指定するために使用されるオプションのパラメータ。`CHAR`文字データ型を表し、 `BINARY`バイナリ データ型を表します。`N`出力長を指定します。これは 1 以上の整数です。 > **Note:** > -> `N`文字列の長さより短い場合、文字列は切り捨てられます。3 `N`文字列の長さを超える場合、 `AS CHAR(N)`指定された長さになるまで文字列にスペースを埋め込み、 `AS BINARY(N)`指定された長さになるまで文字列に`0x00`埋め込みます。 +> `N`文字列の長さより短い場合、文字列は切り捨てられます。`N`文字列の長さを超える場合、 `AS CHAR(N)`は指定された長さになるまで文字列にスペースを埋め込み、 `AS BINARY(N)`は指定された長さになるまで文字列に`0x00`埋め込みます。 例： diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index 168be1a46d220..3fdf8ae90453d 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -11,8 +11,8 @@ summary: TiDB 固有の関数の使用法について学習します。 | 関数名 | 機能の説明 | | :------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 現在のセッションがバインドされているリソースグループの名前を返します。1 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)参照してください。 | -| [`TIDB_BOUNDED_STALENESS()`](#tidb_bounded_staleness) | 指定された時間範囲内の最新のデータを読み取るようTiDBに指示します。1 [`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md)参照してください。 | +| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 現在のセッションがバインドされているリソースグループの名前を返します。[リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)を参照してください。 | +| [`TIDB_BOUNDED_STALENESS()`](#tidb_bounded_staleness) | 指定された時間範囲内の最新のデータを読み取るようTiDBに指示します。[`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md)を参照してください。 | | [`TIDB_CURRENT_TSO()`](#tidb_current_tso) | 現在の[TiDB のタイムスタンプ Oracle (TSO)](/tso.md)を返します。 | | [`TIDB_DECODE_BINARY_PLAN()`](#tidb_decode_binary_plan) | バイナリ プランをデコードします。 | | [`TIDB_DECODE_KEY()`](#tidb_decode_key) | TiDBエンコードされたキーエントリを、 `_tidb_rowid`と`table_id`含むJSON構造にデコードします。これらのエンコードされたキーは、一部のシステムテーブルやログ出力で確認できます。 | @@ -36,8 +36,8 @@ summary: TiDB 固有の関数の使用法について学習します。 | 関数名 | 機能の説明 | | :------------------------------------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 現在のセッションがバインドされているリソースグループ名を返します。1 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)参照してください。 | -| [`TIDB_BOUNDED_STALENESS()`](#tidb_bounded_staleness) | 指定された時間範囲内の最新のデータを読み取るようTiDBに指示します。1 [`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md)参照してください。 | +| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 現在のセッションがバインドされているリソースグループ名を返します。[リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)を参照してください。 | +| [`TIDB_BOUNDED_STALENESS()`](#tidb_bounded_staleness) | 指定された時間範囲内の最新のデータを読み取るようTiDBに指示します。[`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md)を参照してください。 | | [`TIDB_CURRENT_TSO()`](#tidb_current_tso) | 現在の[TiDB のタイムスタンプ Oracle (TSO)](/tso.md)を返します。 | | [`TIDB_DECODE_BINARY_PLAN()`](#tidb_decode_binary_plan) | バイナリ プランをデコードします。 | | [`TIDB_DECODE_KEY()`](#tidb_decode_key) | TiDBエンコードされたキーエントリを、 `_tidb_rowid`と`table_id`含むJSON構造にデコードします。これらのエンコードされたキーは、一部のシステムテーブルやログ出力で確認できます。 | @@ -59,7 +59,7 @@ summary: TiDB 固有の関数の使用法について学習します。 ## 現在のリソースグループ {#current-resource-group} -`CURRENT_RESOURCE_GROUP()`機能は、現在のセッションがバインドされているリソースグループ名を表示するために使用されます。3 [リソース管理](/tidb-resource-control-ru-groups.md)機能を有効にすると、SQL ステートメントで使用できるリソースは、バインドされているリソースグループのリソースクォータによって制限されます。 +`CURRENT_RESOURCE_GROUP()`機能は、現在のセッションがバインドされているリソースグループ名を表示するために使用されます。[リソース管理](/tidb-resource-control-ru-groups.md)機能を有効にすると、SQL ステートメントで使用できるリソースは、バインドされているリソースグループのリソースクォータによって制限されます。 セッションが確立されると、TiDB はログインユーザーがデフォルトでバインドされているリソースグループにセッションをバインドします。ユーザーがどのリソースグループにもバインドされていない場合、セッションは`default`リソースグループにバインドされます。セッションが確立されると、ユーザーのバインドされているリソースグループが[ユーザーにバインドされたリソースグループを変更する](/sql-statements/sql-statement-alter-user.md#modify-basic-user-information)で変更されても、バインドされているリソースグループはデフォルトで変更されません。現在のセッションのバインドされているリソースグループを変更するには、 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)使用します。 @@ -264,9 +264,9 @@ ORDER BY ## TIDB_デコード_プラン {#tidb-decode-plan} -TiDB実行プランは、スロークエリログにエンコードされた形式で保存されています。1関数`TIDB_DECODE_PLAN()` 、エンコードされたプランを人間が読める形式にデコードするために使用されます。 +TiDB実行プランは、スロークエリログにエンコードされた形式で保存されています。`TIDB_DECODE_PLAN()`関数は、エンコードされたプランを人間が読める形式にデコードするために使用されます。 -この関数は、ステートメント実行時にプランが取得されるため便利です。1 `EXPLAIN`ステートメントを再実行すると、データの分布と統計が時間の経過とともに変化するため、異なる結果が生成される可能性があります。 +この関数は、ステートメント実行時にプランが取得されるため便利です。`EXPLAIN`ステートメントを再実行すると、データの分布と統計が時間の経過とともに変化するため、異なる結果が生成される可能性があります。 ```sql SELECT tidb_decode_plan('8QIYMAkzMV83CQEH8E85LjA0CWRhdGE6U2VsZWN0aW9uXzYJOTYwCXRpbWU6NzEzLjHCtXMsIGxvb3BzOjIsIGNvcF90YXNrOiB7bnVtOiAxLCBtYXg6IDU2OC41wgErRHByb2Nfa2V5czogMCwgcnBjXxEpAQwFWBAgNTQ5LglZyGNvcHJfY2FjaGVfaGl0X3JhdGlvOiAwLjAwfQkzLjk5IEtCCU4vQQoxCTFfNgkxXzAJMwm2SGx0KHRlc3QudC5hLCAxMDAwMCkNuQRrdgmiAHsFbBQzMTMuOMIBmQnEDDk2MH0BUgEEGAoyCTQzXzUFVwX1oGFibGU6dCwga2VlcCBvcmRlcjpmYWxzZSwgc3RhdHM6cHNldWRvCTk2ISE2aAAIMTUzXmYA')\G @@ -285,7 +285,7 @@ SELECT tidb_decode_plan('8QIYMAkzMV83CQEH8E85LjA0CWRhdGE6U2VsZWN0aW9uXzYJOTYwCXR `TIDB_DECODE_SQL_DIGESTS()`関数は、クラスタ内のSQLダイジェストセットに対応する正規化されたSQL文（フォーマットと引数のない形式）を照会するために使用されます。この関数は1つまたは2つの引数を取ります。 - `digests` : 文字列。このパラメータはJSON文字列配列の形式であり、配列内の各文字列はSQLダイジェストです。 -- `stmtTruncateLength` : 整数（オプション）。返される結果内の各SQL文の長さを制限するために使用されます。SQL文が指定された長さを超えた場合、文は切り捨てられます。2 `0`長さが無制限であることを意味します。 +- `stmtTruncateLength` : 整数（オプション）。返される結果内の各SQL文の長さを制限するために使用されます。SQL文が指定された長さを超えた場合、文は切り捨てられます。`0`長さが無制限であることを意味します。 この関数は、JSON文字列配列形式の文字列を返します。配列の*i*番目の項目は、 `digests`パラメータの*i*番目の要素に対応する正規化されたSQL文です。 `digests`パラメータの要素が有効なSQLダイジェストでないか、システムが対応するSQL文を見つけられない場合、返される結果の対応する項目は`null`なります。切り捨て長が指定されている場合（ `stmtTruncateLength > 0` ）、返される結果のこの長さを超える各文については、最初の`stmtTruncateLength`文字が保持され、切り捨てを示すために末尾にサフィックス`"..."`が追加されます。 `digests`パラメータが`NULL`の場合、関数の戻り値は`NULL`なります。 @@ -378,7 +378,7 @@ SELECT TIDB_IS_DDL_OWNER(); ## TIDB_PARSE_TSO {#tidb-parse-tso} -`TIDB_PARSE_TSO()`関数は、TiDB TSO タイムスタンプから物理タイムスタンプを抽出します。3 [TSO](/tso.md) Time Stamp Oracle を表し、PD (Placement Driver) によってトランザクションごとに発行される単調に増加するタイムスタンプです。 +`TIDB_PARSE_TSO()`関数は、TiDB TSO タイムスタンプから物理タイムスタンプを抽出します。[TSO](/tso.md)は Time Stamp Oracle を表し、PD (Placement Driver) によってトランザクションごとに発行される単調に増加するタイムスタンプです。 TSO は次の 2 つの部分で構成される数値です。 diff --git a/functions-and-operators/window-functions.md b/functions-and-operators/window-functions.md index 9e2e1bda5e9b2..1061d1aa9093e 100644 --- a/functions-and-operators/window-functions.md +++ b/functions-and-operators/window-functions.md @@ -65,7 +65,7 @@ FROM ## `DENSE_RANK()` {#dense-rank} -`DENSE_RANK()`関数は現在行の順位を返します。3 [`RANK()`](#rank)と似ていますが、同順位（同じ値と順序条件を共有する行）の場合に空白を残しません。 +`DENSE_RANK()`関数は現在行の順位を返します。[`RANK()`](#rank)と似ていますが、同順位（同じ値と順序条件を共有する行）の場合に空白を残しません。 ```sql SELECT diff --git a/garbage-collection-configuration.md b/garbage-collection-configuration.md index 5884b0e49ffc7..10d6a974e9939 100644 --- a/garbage-collection-configuration.md +++ b/garbage-collection-configuration.md @@ -26,7 +26,7 @@ summary: GC 構成パラメータについて学習します。 -TiKVはGC I/O制限をサポートしています。1を設定すると、GCワーカーの`gc.max-write-bytes-per-sec`秒あたりの書き込み回数を制限し、通常のリクエストへの影響を軽減できます。 +TiKVはGC I/O制限をサポートしています。`gc.max-write-bytes-per-sec`を設定すると、GCワーカーの1秒あたりの書き込み量を制限し、通常のリクエストへの影響を軽減できます。 `0`この機能を無効にすることを示します。 diff --git a/global-indexes.md b/global-indexes.md index 587ed3a045ff6..bb6297883669e 100644 --- a/global-indexes.md +++ b/global-indexes.md @@ -43,7 +43,7 @@ summary: TiDB グローバル インデックスの使用例、利点、使用 - **v7.6.0より前**：TiDBはパーティションテーブル上のローカルインデックスのみをサポートします。つまり、パーティションテーブルの一意キーには、パーティション式内のすべての列を含める必要があります。パーティションキーを使用しないクエリはすべてのパーティションをスキャンする必要があり、クエリパフォーマンスが低下します。 - **v7.6.0** : グローバルインデックスを有効にするシステム変数[`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760)が導入されました。ただし、この機能は現時点ではまだ開発中であり、本番での使用は推奨されません。 - **v8.3.0** : グローバルインデックスが実験的機能としてリリースされました。インデックスを定義する際に`GLOBAL`キーワードを使用することで、明示的にグローバルインデックスを作成できます。 -- **v8.4.0** : グローバルインデックス機能が一般提供（GA）されました。システム変数`tidb_enable_global_index`を設定せずに、キーワード`GLOBAL`を使って直接グローバルインデックスを作成できます。このバージョン以降、システム変数 4 は非推奨となり、値は`ON`に固定されます。つまり、グローバルインデックスはデフォルトで有効になります。 +- **v8.4.0** : グローバルインデックス機能が一般提供（GA）されました。システム変数`tidb_enable_global_index`を設定せずに、キーワード`GLOBAL`を使って直接グローバルインデックスを作成できます。このバージョン以降、システム変数は非推奨となり、値は`ON`に固定されます。つまり、グローバルインデックスはデフォルトで有効になります。 - **v8.5.0** : グローバル インデックスは、パーティション式のすべての列を含めることをサポートします。 ## グローバルインデックスとローカルインデックス {#global-indexes-vs-local-indexes} @@ -203,7 +203,7 @@ CREATE TABLE `sbtest` ( ) partition by hash(id) partitions 5; ``` -前述のテーブルスキーマを例に挙げましょう。1 `idx`ローカルインデックス、 `global_idx`はグローバルインデックスです。5 のデータは`PartitionID1_i_xxx`や`PartitionID2_i_xxx`など`idx`つの異なる範囲に分散されていますが、 `global_idx`のデータは単一の範囲 ( `TableID_i_xxx` ) に集中しています。 +前述のテーブルスキーマを例に挙げましょう。1 `idx`ローカルインデックス、 `global_idx`はグローバルインデックスです。`idx`のデータは`PartitionID1_i_xxx`や`PartitionID2_i_xxx`など 5 つの異なる範囲に分散されていますが、 `global_idx`のデータは単一の範囲 ( `TableID_i_xxx` ) に集中しています。 `k`に関連するクエリ（例えば`SELECT * FROM sbtest WHERE k > 1`を実行すると、ローカルインデックス`idx`は5つの個別の範囲を生成しますが、グローバルインデックス`global_idx`は1つの範囲のみを生成します。TiDBの各範囲は1つ以上のRPCリクエストに対応するため、グローバルインデックスを使用することでRPCリクエストの数を数倍削減でき、インデックスクエリのパフォーマンスが向上します。 diff --git a/glossary.md b/glossary.md index 2bf4423b4f092..da92d58ff5b69 100644 --- a/glossary.md +++ b/glossary.md @@ -143,7 +143,7 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ ### グローバルトランザクション識別子（GTID） {#global-transaction-identifiers-gtids} -グローバルトランザクション識別子（GTID）は、MySQLバイナリログで使用される一意のトランザクションIDで、どのトランザクションが複製されたかを追跡するために使用されます。1 [データ移行（DM）](/dm/dm-overview.md) 、これらのIDを使用して一貫性のあるレプリケーションを保証します。 +グローバルトランザクション識別子（GTID）は、MySQLバイナリログで使用される一意のトランザクションIDで、どのトランザクションが複製されたかを追跡するために使用されます。[データ移行（DM）](/dm/dm-overview.md)は、これらのIDを使用して一貫性のあるレプリケーションを保証します。 ## H {#a-id-h-class-letter-href-h-h-a} @@ -339,7 +339,7 @@ TiKV におけるデータストレージの最小単位はリージョンであ ### セキュリティ強化モード（SEM） {#security-enhanced-mode-sem} -セキュリティ強化モード（SEM）は、TiDB管理者の権限をより細かく制御するために使用されます。1 [セキュリティ強化Linux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux)のシステムに触発されたSEMは、 `SUPER`権限を持つユーザーの機能を制限し、代わりに`RESTRICTED`つのきめ細かい権限を必要とします。これらの権限は、特定の管理アクションを制御するために明示的に付与される必要があります。 +セキュリティ強化モード（SEM）は、TiDB管理者の権限をより細かく制御するために使用されます。[セキュリティ強化Linux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux)のようなシステムに触発されたSEMは、 `SUPER`権限を持つユーザーの機能を制限し、代わりに`RESTRICTED`つのきめ細かい権限を必要とします。これらの権限は、特定の管理アクションを制御するために明示的に付与される必要があります。 詳細については、 [システム変数に関するドキュメント - `tidb_enable_enhanced_security`](/system-variables.md#tidb_enable_enhanced_security)参照してください。 diff --git a/grafana-overview-dashboard.md b/grafana-overview-dashboard.md index b2c42ee3a31f6..f44cc1ec9af75 100644 --- a/grafana-overview-dashboard.md +++ b/grafana-overview-dashboard.md @@ -31,7 +31,7 @@ Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、 | PD | ホットリードリージョンのリーダー分布 | 各 TiKV インスタンス上の読み取りホットスポットであるリーダーの合計数。 | | | PD | リージョンのハートビートレポート | インスタンスごとに PD に報告されたハートビートの数。 | | | PD | 99%リージョンハートビートレイテンシー | TiKV インスタンスごとのハートビートレイテンシー(P99)。 | | -| TiDB | ステートメントOPS | 1 秒あたりに実行される異なるタイプの SQL ステートメントの数。1 、 `SELECT` 、 `UPDATE`など`INSERT`ステートメントのタイプに応じてカウントされます。 | | +| TiDB | ステートメントOPS | 1 秒あたりに実行される異なるタイプの SQL ステートメントの数。`SELECT` 、 `INSERT` 、 `UPDATE`などのステートメントのタイプに応じてカウントされます。 | | | TiDB | 間隔 | 実行時間。
1. クライアントのネットワーク要求がTiDBに送信されてから、TiDBが要求を実行した後にクライアントに返されるまでの時間。通常、クライアント要求はSQL文の形式で送信されますが、この時間には`COM_PING` 、 `COM_SLEEP` 、 `COM_STMT_FETCH` 、 `COM_SEND_LONG_DATA`などのコマンドの実行時間も含まれる場合があります。
2. TiDBはマルチクエリをサポートしているため、 `select 1; select 1; select 1;`ように複数のSQL文を一度に送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 | | | TiDB | インスタンスごとのCPS | インスタンス別 CPS: コマンド実行結果の成功または失敗に応じて分類された、各 TiDB インスタンスのコマンド統計。 | | | TiDB | クエリ OPM の失敗 | 各TiDBインスタンスにおける1秒あたりのSQL文実行時に発生したエラー数に基づく、エラーの種類（構文エラーや主キーの競合など）の統計情報。エラーが発生したモジュールとエラーコードが含まれます。 | | diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md index 058013252f195..53aeb6e49785f 100644 --- a/grafana-pd-dashboard.md +++ b/grafana-pd-dashboard.md @@ -134,7 +134,7 @@ PD ダッシュボード メトリック項目の説明は次のとおりです - PDサーバTSO処理時間とクライアント受信時間: PDがTSO要求を受信してからPDクライアントがTSO応答を受信するまでの時間 - 処理要求数: TiDB 要求の数 -- リクエスト処理時間: TiDBリクエストの処理に要した時間。1 (P99) `100ms`である必要があります。 +- リクエスト処理時間: TiDBリクエストの処理に要した時間。(P99) は`100ms`未満である必要があります。 ![PD Dashboard - TiDB metrics](/media/pd-dashboard-tidb-v4.png) diff --git a/grafana-performance-overview-dashboard.md b/grafana-performance-overview-dashboard.md index a669748df2459..4e39e66b4308b 100644 --- a/grafana-performance-overview-dashboard.md +++ b/grafana-performance-overview-dashboard.md @@ -180,7 +180,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサ要求の数。 - `cop_dag` : すべてのコプロセッサ要求内の DAG 要求の数。 - `super_batch` : スーパーバッチ機能を有効にするリクエストの数。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。1 `table_scan`テーブル スキャン Executor です。3 は選択 Executor です`selection` `aggregation`集約 Executor です`top_n`は`TopN` Executor です`limit`制限 Executor です。 +- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。1 `table_scan`テーブル スキャン Executor です。`selection`は選択 Executor です。 `aggregation`集約 Executor です`top_n`は`TopN` Executor です`limit`制限 Executor です。 - リクエスト期間の概要: すべてのTiFlashインスタンスのすべてのリクエスト タイプについて、1 秒あたりの合計処理時間の積み上げグラフを提供します。 - リクエスト期間: すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの合計処理期間。コプロセッサリクエストの受信からリクエストへの応答が完了するまでの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 - リクエスト処理時間：すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの実際の処理時間。コプロセッサリクエストの実行開始から完了までの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 diff --git a/grafana-resource-control-dashboard.md b/grafana-resource-control-dashboard.md index 715650dfe473f..969cc9214fa48 100644 --- a/grafana-resource-control-dashboard.md +++ b/grafana-resource-control-dashboard.md @@ -17,32 +17,32 @@ TiDBはフロー制御に[トークンバケットアルゴリズム](https://en ## リクエストユニットに関するメトリクス {#metrics-about-request-unit} -- RU: 各リソースグループの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)の消費情報。リアルタイムで計算されます。3 `total`は、すべてのリソースグループで消費されるリクエストユニットの合計です。各リソースグループのリクエストユニット消費量は、読み取り消費量（読み取りリクエストユニット）と書き込み消費量（書き込みリクエストユニット）の合計と等しくなります。 +- RU: 各リソースグループの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)の消費情報。リアルタイムで計算されます。`total`は、すべてのリソースグループで消費されるリクエストユニットの合計です。各リソースグループのリクエストユニット消費量は、読み取り消費量（読み取りリクエストユニット）と書き込み消費量（書き込みリクエストユニット）の合計と等しくなります。 - クエリあたりのRU: 各SQL文が1秒あたりに消費するリクエストユニットの平均数。上記のRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- RRU: リアルタイムで計算される各リソース グループの読み取り要求単位消費情報。1 `total` 、すべてのリソース グループによって消費される読み取り要求単位の合計です。 +- RRU: リアルタイムで計算される各リソース グループの読み取り要求単位消費情報。`total` 、すべてのリソース グループによって消費される読み取り要求単位の合計です。 - クエリあたりのRRU: 各SQL文が1秒あたりに消費する平均読み取り要求ユニット数。上記のRRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- WRU: リアルタイムで計算される各リソース グループの書き込み要求単位消費情報。1 `total` 、すべてのリソース グループによって消費される書き込み要求単位の合計です。 +- WRU: リアルタイムで計算される各リソース グループの書き込み要求単位消費情報。`total` 、すべてのリソース グループによって消費される書き込み要求単位の合計です。 - クエリあたりのWRU: 各SQL文が1秒あたりに消費する書き込みリクエストユニット（WRRU）の平均数。上記のWRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 - 利用可能なRU: 各リソースグループのRUトークンバケット内の利用可能なトークン数。この値が`0`場合、このリソースグループは`RU_PER_SEC`割合でトークンを消費し、レート制限状態にあるとみなされます。 - クエリの最大期間: リソース グループに関する最大クエリ期間。 ## リソースに関する指標 {#metrics-about-resources} -- KVリクエスト数: 各リソースグループに対するKVリクエストの数（1秒あたり）。リクエストは読み取りと書き込みの2種類に分類されます。1 `total` 、すべてのリソースグループのKVリクエストの合計です。 +- KVリクエスト数: 各リソースグループに対するKVリクエストの数（1秒あたり）。リクエストは読み取りと書き込みの2種類に分類されます。`total` 、すべてのリソースグループのKVリクエストの合計です。 - クエリあたりのKVリクエスト数: 各SQL文による1秒あたりの読み取りおよび書き込みKVリクエストの平均数。上記のKVリクエスト数メトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- 読み取りバイト数: 各リソース グループによって読み取られたデータの量 (1 秒あたりに計算)。1 `total` 、すべてのリソース グループによって読み取られたデータの合計です。 +- 読み取りバイト数: 各リソース グループによって読み取られたデータの量 (1 秒あたりに計算)。`total` 、すべてのリソース グループによって読み取られたデータの合計です。 - クエリあたりの読み取りバイト数: 各SQL文が1秒あたりに読み取るデータの平均量。上記の読み取りバイト数メトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- 書き込みバイト数: 各リソース グループによって書き込まれたデータの量。リアルタイムで計算されます。1 `total` 、すべてのリソース グループによって書き込まれたデータの合計です。 +- 書き込みバイト数: 各リソース グループによって書き込まれたデータの量。リアルタイムで計算されます。`total` 、すべてのリソース グループによって書き込まれたデータの合計です。 - クエリあたりの書き込みバイト数: 各SQL文が1秒あたりに書き込むデータ量の平均。上記の「書き込みバイト数」メトリックを、1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- KV CPU 時間: 各リソース グループで消費された KVレイヤーCPU 時間 (リアルタイムで計算)。1 `total` 、すべてのリソース グループで消費された KVレイヤーCPU 時間の合計です。 -- SQL CPU 時間: 各リソース グループで消費された SQLレイヤーのCPU 時間 (リアルタイムで計算)。1 `total` 、すべてのリソース グループで消費された SQLレイヤーのCPU 時間の合計です。 +- KV CPU 時間: 各リソース グループで消費された KVレイヤーCPU 時間 (リアルタイムで計算)。`total` 、すべてのリソース グループで消費された KVレイヤーCPU 時間の合計です。 +- SQL CPU 時間: 各リソース グループで消費された SQLレイヤーのCPU 時間 (リアルタイムで計算)。`total` 、すべてのリソース グループで消費された SQLレイヤーのCPU 時間の合計です。 ## リソース コントローラー クライアントに関するメトリクス {#metrics-about-resource-controller-client} - アクティブ リソース グループ: リアルタイムで計算された、各リソース コントローラー クライアントのリソース グループの数。 -- 合計 KV 要求数: 各リソース コントローラー クライアントの KV 要求の数。リアルタイムでリソース グループごとに計算されます。1 `total` 、すべてのリソース コントローラー クライアントの KV 要求の合計です。 -- 失敗した KV 要求数: 各リソース コントローラー クライアントの失敗した KV 要求の数。リアルタイムでリソース グループごとに計算されます。1 `total` 、すべてのリソース コントローラー クライアントの失敗した KV 要求の合計です。 -- 成功した KV 要求数: 各リソース コントローラー クライアントの成功した KV 要求の数。リアルタイムでリソース グループごとに計算されます。1 `total` 、すべてのリソース コントローラー クライアントの成功した KV 要求の合計です。 +- 合計 KV 要求数: 各リソース コントローラー クライアントの KV 要求の数。リアルタイムでリソース グループごとに計算されます。`total` 、すべてのリソース コントローラー クライアントの KV 要求の合計です。 +- 失敗した KV 要求数: 各リソース コントローラー クライアントの失敗した KV 要求の数。リアルタイムでリソース グループごとに計算されます。`total` 、すべてのリソース コントローラー クライアントの失敗した KV 要求の合計です。 +- 成功した KV 要求数: 各リソース コントローラー クライアントの成功した KV 要求の数。リアルタイムでリソース グループごとに計算されます。`total` 、すべてのリソース コントローラー クライアントの成功した KV 要求の合計です。 - 成功した KV 要求の待機期間 (99/90): 各リソース コントローラー クライアントの成功した KV 要求の待機時間 (異なるパーセンタイル)。リアルタイムでリソース グループごとに計算されます。 - トークン要求処理期間 (999/99): 各リソース コントローラー クライアントのサーバー側からのトークン要求の待機時間 (異なるパーセンタイル)。リアルタイムでリソース グループごとに計算されます。 -- トークン要求数: 各リソース コントローラー クライアントに対するサーバー側からのトークン要求の数。リアルタイムでリソース グループごとに計算されます。1 と`failed` `successful`すべてのリソース コントローラー クライアントの成功したトークン要求と失敗したトークン要求の合計です。 +- トークン要求数: 各リソース コントローラー クライアントに対するサーバー側からのトークン要求の数。リアルタイムでリソース グループごとに計算されます。`successful`と`failed`はすべてのリソース コントローラー クライアントの成功したトークン要求と失敗したトークン要求の合計です。 diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 0400ea802201e..ba6636dae5ed7 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -24,7 +24,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - クライアントのネットワーク要求がTiDBに送信されてから、TiDBがそれを実行した後にクライアントに返される`COM_STMT_FETCH`の時間。通常、クライアント要求はSQL文の形式で送信されますが、 `COM_PING` `COM_SEND_LONG_DATA`のコマンドの実行時間も含まれる場合があります`COM_SLEEP` - TiDBはマルチクエリをサポートしているため、 `select 1; select 1; select 1;`ような複数のSQL文を一度に送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 - 1秒あたりのコマンド数: コマンド実行結果の成功または失敗に応じて分類される、TiDBによって1秒あたりに処理されるコマンドの数 -- QPS: すべての TiDB インスタンスで`SELECT`秒あたりに実行される SQL ステートメントの数。1、3、5 `UPDATE`およびその他のタイプのステートメントに従ってカウントされます`INSERT` +- QPS: すべての TiDB インスタンスで秒あたりに実行される SQL ステートメントの数。`SELECT` 、 `INSERT` 、 `UPDATE`およびその他のタイプのステートメントに従ってカウントされます - インスタンス別CPS: コマンド実行結果の成功または失敗に応じて分類された各TiDBインスタンスのコマンド統計 - 失敗したクエリOPM：各TiDBインスタンスで1分間にSQL文を実行した際に発生したエラー数に基づく、エラーの種類（構文エラーや主キーの競合など）の統計情報。エラーが発生したモジュールとエラーコードが含まれます。 - スロークエリ：スロークエリの処理時間の統計（スロークエリ全体の時間コスト、コプロセッサーの時間コスト、コプロセッサーのスケジューリングの待機時間）。スロークエリは、内部SQL文と一般SQL文に分類されます。 @@ -76,7 +76,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - トランザクション書き込みサイズバイト: トランザクションで書き込まれたデータのサイズ - 悲観的ロックの取得期間: ロックの追加にかかる時間 - TTL 寿命到達カウンタ: TTL の上限に達したトランザクションの数。TTL 上限のデフォルト値は 1 時間です。これは、悲観的トランザクションの最初のロック、または楽観的トランザクションの最初の事前書き込みから 1 時間が経過したことを意味します。TTL 上限のデフォルト値は 1 時間です。TTL 寿命の上限は、TiDB 設定ファイルで`max-txn-TTL`変更することで変更できます。 -- ロードセーフポイントOPS: `Safepoint`がロードされる回数。3 `Safepoint` 、トランザクションがデータを読み取る際に`Safepoint`より前のデータが読み込まれないようにすることで、データの安全性を確保するためのものです`Safepoint`より前のデータはGCによってクリーンアップされる可能性があります。 +- ロードセーフポイントOPS: `Safepoint`がロードされる回数。`Safepoint` 、トランザクションがデータを読み取る際に`Safepoint`より前のデータが読み込まれないようにすることで、データの安全性を確保するためのものです`Safepoint`より前のデータはGCによってクリーンアップされる可能性があります。 - 悲観的ステートメント再試行回数（OPS）：悲観的ステートメントの再試行回数。ステートメントがロックを追加しようとすると、書き込み競合が発生する可能性があります。この場合、ステートメントは新しいスナップショットを取得し、再度ロックを追加します。 - 1秒あたりのトランザクションタイプ: 2フェーズコミット (2PC)、非同期コミット、および1フェーズコミット (1PC) メカニズムを使用して1秒あたりにコミットされたトランザクションの数 (成功トランザクションと失敗トランザクションの両方を含む) diff --git a/hybrid-deployment-topology.md b/hybrid-deployment-topology.md index 91f0ab0f9ab88..0c5e759bbf59e 100644 --- a/hybrid-deployment-topology.md +++ b/hybrid-deployment-topology.md @@ -37,7 +37,7 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて - TiKVの設定を最適化する - - `readpool`スレッドプールに自己適応するように設定します。3 パラメータ`readpool.unified.max-thread-count`設定することで、 `readpool.storage`と`readpool.coprocessor`統合スレッドプールを共有し、それぞれ自己適応スイッチを設定できます。 + - `readpool`スレッドプールに自己適応するように設定します。`readpool.unified.max-thread-count`パラメータを設定することで、 `readpool.storage`と`readpool.coprocessor`統合スレッドプールを共有し、それぞれ自己適応スイッチを設定できます。 - `readpool.storage`と`readpool.coprocessor`有効にする: diff --git a/identify-expensive-queries.md b/identify-expensive-queries.md index 17a85f37bea7e..c1ff0f6a56eca 100644 --- a/identify-expensive-queries.md +++ b/identify-expensive-queries.md @@ -44,7 +44,7 @@ TiKVコプロセッサータスク関連フィールド: - `wait_time` : TiKV 内のステートメントにおけるすべてのコプロセッサー要求の合計待機時間。TiKV のコプロセッサーは限られた数のスレッドを実行するため、コプロセッサーのすべてのスレッドが動作している場合でも、要求がキューイングされる可能性があります。キュー内の要求の処理に時間がかかる場合、後続の要求の待機時間が増加します。 - `request_count` : ステートメントが送信するコプロセッサー要求の数。 - `total_keys` :コプロセッサーがスキャンしたキーの数。 -- `processed_keys` :コプロセッサーが処理したキーの数。2 と比較すると、 `total_keys` `processed_keys`古いバージョンの MVCC は含まれません。6 と`processed_keys` `total_keys`差が大きいことから、古いバージョンが多数存在することがわかります。 +- `processed_keys` :コプロセッサーが処理したキーの数。`total_keys`と比較すると、 `processed_keys`には古いバージョンの MVCC は含まれません。`processed_keys`と`total_keys`の差が大きいことから、古いバージョンが多数存在することがわかります。 - `num_cop_tasks` : ステートメントが送信するコプロセッサー要求の数。 - `process_avg_time` :コプロセッサータスクの平均実行時間。 - `process_p90_time` :コプロセッサータスクの P90 実行時間。 diff --git a/information-schema/client-errors-summary-by-host.md b/information-schema/client-errors-summary-by-host.md index 218391370a028..709448b0847ed 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サーバーに接続する際に生成される警告を示しています。`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..a9578e4c3178f 100644 --- a/information-schema/client-errors-summary-by-user.md +++ b/information-schema/client-errors-summary-by-user.md @@ -13,7 +13,7 @@ summary: CLIENT_ERRORS_SUMMARY_BY_USER` INFORMATION_SCHEMA テーブルについ - 権限エラー。 - 存在しないテーブル。 -クライアントエラーはMySQLサーバープロトコルを介してクライアントに返され、アプリケーションは適切なアクションを実行することが期待されます。1 `INFORMATION_SCHEMA.CLIENT_ERRORS_SUMMARY_BY_USER`表は、アプリケーションがTiDBサーバーから返されたエラーを適切に処理（またはログに記録）していないシナリオにおいて、エラーを検査するための便利な方法を提供します。 +クライアントエラーはMySQLサーバープロトコルを介してクライアントに返され、アプリケーションは適切なアクションを実行することが期待されます。`INFORMATION_SCHEMA.CLIENT_ERRORS_SUMMARY_BY_USER`表は、アプリケーションがTiDBサーバーから返されたエラーを適切に処理（またはログに記録）していないシナリオにおいて、エラーを検査するための便利な方法を提供します。 `CLIENT_ERRORS_SUMMARY_BY_USER`ユーザーごとにエラーを要約するため、あるユーザーサーバーが他のサーバーよりも多くのエラーを生成しているシナリオを診断するのに役立ちます。考えられるシナリオには以下が含まれます。 @@ -55,7 +55,7 @@ DESC CLIENT_ERRORS_SUMMARY_BY_USER; - `FIRST_SEEN` : このエラー (または警告) がユーザーに初めて送信されたとき。 - `LAST_SEEN` : このエラー (または警告) がユーザーに最後に送信された時刻。 -以下の例は、クライアントがローカルTiDBサーバーに接続する際に生成される警告を示しています。1 `FLUSH CLIENT_ERRORS_SUMMARY`実行するとサマリーはリセットされます。 +以下の例は、クライアントがローカルTiDBサーバーに接続する際に生成される警告を示しています。`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..e1c4d1fe41f1a 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サーバーへの接続時に生成される警告を示しています。`FLUSH CLIENT_ERRORS_SUMMARY`を実行するとサマリーがリセットされます。 ```sql SELECT 0/0; diff --git a/information-schema/information-schema-character-sets.md b/information-schema/information-schema-character-sets.md index bb83d24d15968..6d5797771e7a2 100644 --- a/information-schema/information-schema-character-sets.md +++ b/information-schema/information-schema-character-sets.md @@ -24,7 +24,7 @@ DESC CHARACTER_SETS; +----------------------+-------------+------+------+---------+-------+ 4 rows in set (0.00 sec) -`CHARACTER_SETS`テーブルをビュー: +`CHARACTER_SETS`テーブルを確認します: ```sql SELECT * FROM `CHARACTER_SETS`; diff --git a/information-schema/information-schema-collation-character-set-applicability.md b/information-schema/information-schema-collation-character-set-applicability.md index 701ffd3722a57..86e9e2ab7ba61 100644 --- a/information-schema/information-schema-collation-character-set-applicability.md +++ b/information-schema/information-schema-collation-character-set-applicability.md @@ -5,7 +5,7 @@ summary: COLLATION_CHARACTER_SET_APPLICABILITY` INFORMATION_SCHEMA テーブル # 照合文字セットの適用性 {#collation-character-set-applicability} -`COLLATION_CHARACTER_SET_APPLICABILITY`テーブルは、照合順序を該当する文字セット名にマッピングします。3 `COLLATIONS`と同様に、MySQL との互換性のためだけに含まれています。 +`COLLATION_CHARACTER_SET_APPLICABILITY`テーブルは、照合順序を該当する文字セット名にマッピングします。`COLLATIONS`と同様に、MySQL との互換性のためだけに含まれています。 ```sql USE INFORMATION_SCHEMA; @@ -24,7 +24,7 @@ DESC COLLATION_CHARACTER_SET_APPLICABILITY; 2 rows in set (0.00 sec) ``` -`COLLATION_CHARACTER_SET_APPLICABILITY`テーブルの`utf8mb4`の文字セットの照合順序マッピングをビュー。 +`COLLATION_CHARACTER_SET_APPLICABILITY`テーブルの`utf8mb4`の文字セットの照合順序マッピングを確認します。 ```sql SELECT * FROM COLLATION_CHARACTER_SET_APPLICABILITY WHERE character_set_name='utf8mb4'; diff --git a/information-schema/information-schema-collations.md b/information-schema/information-schema-collations.md index 25d983690a97e..0864f0ca837c2 100644 --- a/information-schema/information-schema-collations.md +++ b/information-schema/information-schema-collations.md @@ -52,7 +52,7 @@ SELECT * FROM collations WHERE character_set_name='utf8mb4'; - `IS_DEFAULT` : この照合順序が、それが属する文字セットのデフォルトの照合順序であるかどうか。 - `IS_COMPILED` : 文字セットがサーバーにコンパイルされているかどうか。 - `SORTLEN` :照合順序が文字をソートするときに割り当てられるメモリの最小長。 -- `PAD_ATTRIBUTE` : 文字列の比較中に末尾のスペースを無視するかどうか。2 `PAD SPACE`末尾のスペースが無視されることを意味し (たとえば、 `'abc'` `'abc '`と等しい)、 `NO PAD`末尾のスペースが重要であることを意味します (たとえば、 `'abc'` `'abc '`等しくありません)。 +- `PAD_ATTRIBUTE` : 文字列の比較中に末尾のスペースを無視するかどうか。`PAD SPACE`末尾のスペースが無視されることを意味し (たとえば、 `'abc'` `'abc '`と等しい)、 `NO PAD`末尾のスペースが重要であることを意味します (たとえば、 `'abc'` `'abc '`等しくありません)。 ## 参照 {#see-also} diff --git a/information-schema/information-schema-data-lock-waits.md b/information-schema/information-schema-data-lock-waits.md index 3bd5a9d159dbc..e70dd7979147b 100644 --- a/information-schema/information-schema-data-lock-waits.md +++ b/information-schema/information-schema-data-lock-waits.md @@ -26,7 +26,7 @@ DESC data_lock_waits; `DATA_LOCK_WAITS`テーブル内の各列フィールドの意味は次のとおりです。 - `KEY` : ロックを待機しているキー（16 進形式）。 -- `KEY_INFO` : `KEY`の詳細情報。4 [キー情報](#key_info)セクションを参照してください。 +- `KEY_INFO` : `KEY`の詳細情報。[キー情報](#key_info)セクションを参照してください。 - `TRX_ID` : ロックを待機しているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 - `CURRENT_HOLDING_TRX_ID` : 現在ロックを保持しているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 - `SQL_DIGEST` : ロック待機中のトランザクションで現在ブロックされている SQL ステートメントのダイジェスト。 diff --git a/information-schema/information-schema-deadlocks.md b/information-schema/information-schema-deadlocks.md index 5ffe481af7835..34a5efca18dfb 100644 --- a/information-schema/information-schema-deadlocks.md +++ b/information-schema/information-schema-deadlocks.md @@ -30,7 +30,7 @@ DESC deadlocks; +-------------------------+---------------------+------+------+---------+-------+ ``` -`DEADLOCKS`表では、複数の行を使用して同じデッドロックイベントを表示し、各行にはデッドロックイベントに関係するトランザクションの1つに関する情報が表示されます。TiDBノードが複数のデッドロックエラーを記録した場合、各エラーは`DEADLOCK_ID`列を使用して区別されます。同じ`DEADLOCK_ID`同じデッドロックイベントを示します。7 `DEADLOCK_ID`**グローバルな一意性を保証するものではなく、永続化されないことに**注意してください。同じ結果セット内の同じデッドロックイベントのみを示します。 +`DEADLOCKS`表では、複数の行を使用して同じデッドロックイベントを表示し、各行にはデッドロックイベントに関係するトランザクションの1つに関する情報が表示されます。TiDBノードが複数のデッドロックエラーを記録した場合、各エラーは`DEADLOCK_ID`列を使用して区別されます。同じ`DEADLOCK_ID`同じデッドロックイベントを示します。`DEADLOCK_ID`**グローバルな一意性を保証するものではなく、永続化されないことに**注意してください。同じ結果セット内の同じデッドロックイベントのみを示します。 `DEADLOCKS`テーブル内の各列フィールドの意味は次のとおりです。 @@ -41,7 +41,7 @@ DESC deadlocks; - `CURRENT_SQL_DIGEST` : ロックを取得するトランザクションで現在実行されている SQL ステートメントのダイジェスト。 - `CURRENT_SQL_DIGEST_TEXT` : ロックを取得するトランザクションで現在実行されている SQL ステートメントの正規化された形式。 - `KEY` : トランザクションがロックしようとしたブロックされたキー。このフィールドの値は16進文字列で表示されます。 -- `KEY_INFO` : `KEY`の詳細情報。4 [`KEY_INFO`](#key_info)セクションを参照してください。 +- `KEY_INFO` : `KEY`の詳細情報。[`KEY_INFO`](#key_info)セクションを参照してください。 - `TRX_HOLDING_LOCK` : 現在キーのロックを保持し、ブロックを引き起こしているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 @@ -194,7 +194,7 @@ SELECT * FROM INFORMATION_SCHEMA.DEADLOCKS; ## クラスターデッドロック {#cluster-deadlocks} -`CLUSTER_DEADLOCKS`テーブルは、クラスター全体の各 TiDB ノードの最近のデッドロック エラーに関する情報を返します。これは、各ノードの`DEADLOCKS`テーブルの情報を組み合わせたものです。5 `CLUSTER_DEADLOCKS`は、異なる TiDB ノードを区別するために、ノードの IP アドレスとポートを表示する追加の`INSTANCE`列も含まれています。 +`CLUSTER_DEADLOCKS`テーブルは、クラスター全体の各 TiDB ノードの最近のデッドロック エラーに関する情報を返します。これは、各ノードの`DEADLOCKS`テーブルの情報を組み合わせたものです。`CLUSTER_DEADLOCKS`は、異なる TiDB ノードを区別するために、ノードの IP アドレスとポートを表示する追加の`INSTANCE`列も含まれています。 `DEADLOCK_ID`グローバルな一意性が保証されないため、 `CLUSTER_DEADLOCKS`テーブルのクエリ結果では、結果セット内の異なるデッドロック エラーの情報を区別するために、 `INSTANCE`と`DEADLOCK_ID`一緒に使用する必要があることに注意してください。 diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index a679b1825ca7b..8357fd4f4bf68 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`診断テーブルは、問題を迅速に発見し、手作業の繰り返しを削減するのに役立ちます。`select * from information_schema.inspection_result`ステートメントを使用して、内部診断をトリガーできます。 > **Note:** > @@ -50,7 +50,7 @@ DESC inspection_result; - `INSTANCE` : 診断されたインスタンスの特定のアドレス。 - `STATUS_ADDRESS` : インスタンスの HTTP API サービス アドレス。 - `VALUE` : 特定の診断項目の値。 -- `REFERENCE` ：この診断項目の基準値（閾値）。2 `VALUE`閾値を超えると、対応する診断情報が生成されます。 +- `REFERENCE` ：この診断項目の基準値（閾値）。`VALUE`閾値を超えると、対応する診断情報が生成されます。 - `SEVERITY` : 重大度レベル。オプションの値は`warning`と`critical`です。 - `DETAILS` : 診断の詳細。追加の診断のための SQL ステートメントまたはドキュメント リンクも含まれる場合があります。 diff --git a/information-schema/information-schema-inspection-summary.md b/information-schema/information-schema-inspection-summary.md index d2923fb77cf2b..2241055acefc4 100644 --- a/information-schema/information-schema-inspection-summary.md +++ b/information-schema/information-schema-inspection-summary.md @@ -40,7 +40,7 @@ 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の結果を照会できます。`AVG_VALUE` 、 `MIN_VALUE` 、 `MAX_VALUE`は、それぞれ集計の平均値、最小値、最大値を示します。 - `COMMENT` : 対応する監視メトリックに関するコメント。 > **Note:** @@ -49,7 +49,7 @@ DESC inspection_summary; 使用例: -診断結果表と診断監視サマリー表はどちらも、 `hint`を使用して診断時間範囲を指定できます。3 `select /*+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` 、 `2020-03-07 12:00:00` ～ `2020-03-07 13:00:00`期間の監視サマリーです。監視サマリー表と同様に、 `inspection_summary`表を使用すると、異なる2期間のデータを比較することで、差異の大きい監視項目を素早く見つけることができます。 +診断結果表と診断監視サマリー表はどちらも、 `hint`を使用して診断時間範囲を指定できます。`select /*+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` 、 `2020-03-07 12:00:00` ～ `2020-03-07 13:00:00`期間の監視サマリーです。監視サマリー表と同様に、 `inspection_summary`表を使用すると、異なる2期間のデータを比較することで、差異の大きい監視項目を素早く見つけることができます。 次の例では、2 つの期間における読み取りリンクの監視メトリックを比較します。 diff --git a/information-schema/information-schema-metrics-summary.md b/information-schema/information-schema-metrics-summary.md index 1d1b5a745a506..a1429b4b6038f 100644 --- a/information-schema/information-schema-metrics-summary.md +++ b/information-schema/information-schema-metrics-summary.md @@ -138,7 +138,7 @@ COMMENT | The quantile of TiDB query durations(second) - 期間t1: `("2020-03-03 17:08:00", "2020-03-03 17:11:00")` - 期間t2: `("2020-03-03 17:18:00", "2020-03-03 17:21:00")` -2 つの期間の監視項目は`METRICS_NAME`に従って結合され、差異値に従ってソートされます。3 `TIME_RANGE`クエリ時間を指定するヒントです。 +2 つの期間の監視項目は`METRICS_NAME`に従って結合され、差異値に従ってソートされます。`TIME_RANGE`クエリ時間を指定するヒントです。 ```sql SELECT GREATEST(t1.avg_value,t2.avg_value)/LEAST(t1.avg_value, @@ -179,7 +179,7 @@ ORDER BY ratio DESC LIMIT 10; - 期間 t2 の`tib_slow_query_cop_process_total_time` (TiDB のスロークエリでの時間消費量`cop process` ) は、期間 t1 の 5,865 倍になります。 - 期間t2における`tidb_distsql_partial_scan_key_total_num` （TiDBの`distsql`が要求するスキャンキー数）は、期間t1の3,648倍です。期間t2における`tidb_slow_query_cop_wait_total_time` （コプロセッサーがTiDBのスロークエリのキューイングを要求する際の待機時間）は、期間t1の267倍です。 - 期間 t2 の`tikv_cop_total_response_size` (TiKVコプロセッサー要求結果のサイズ) は、期間 t1 の 192 倍になります。 -- 期間 t2 (TiKVコプロセッサーによって要求されたスキャン) の`tikv_cop_scan_details` 、期間 t1 の 0 の 105 倍になります。 +- 期間 t2 (TiKVコプロセッサーによって要求されたスキャン) の`tikv_cop_scan_details`は、期間 t1 の 105 倍になります。 上記の結果から、期間t2のコプロセッサーリクエストが期間t1よりもはるかに多いことがわかります。これによりTiKVコプロセッサーが過負荷になり、 `cop task`待機状態になります。期間t2に大規模なクエリが発生し、負荷がさらに増加している可能性があります。 diff --git a/information-schema/information-schema-sequences.md b/information-schema/information-schema-sequences.md index 6f086c197a868..940f535f93dc0 100644 --- a/information-schema/information-schema-sequences.md +++ b/information-schema/information-schema-sequences.md @@ -5,7 +5,7 @@ summary: SEQUENCES` INFORMATION_SCHEMA テーブルについて学習します # シーケンス {#sequences} -`SEQUENCES`のテーブルはシーケンスに関する情報を提供します。3 [シーケンス機能](/sql-statements/sql-statement-create-sequence.md)テーブルは、MariaDB の同様の機能をモデルにしています。 +`SEQUENCES`のテーブルはシーケンスに関する情報を提供します。[シーケンス機能](/sql-statements/sql-statement-create-sequence.md)は、MariaDB の同様の機能をモデルにしています。 ```sql USE INFORMATION_SCHEMA; diff --git a/information-schema/information-schema-sql-diagnostics.md b/information-schema/information-schema-sql-diagnostics.md index 519691da3ac65..16a0cc8d1fd25 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)には、システムの診断結果が表示されます。診断は受動的にトリガーされます。`select * from inspection_result`を実行すると、すべての診断ルールがトリガーされ、システムが診断され、システム内の障害またはリスクが結果に表示されます。 - 診断サマリーテーブル[`information_schema.inspection_summary`](/information-schema/information-schema-inspection-summary.md) 、特定のリンクまたはモジュールの監視情報を要約したものです。モジュールまたはリンク全体のコンテキストに基づいて、トラブルシューティングを行い、問題を特定することができます。 diff --git a/information-schema/information-schema-table-constraints.md b/information-schema/information-schema-table-constraints.md index e47aa41f33839..cea747feb876b 100644 --- a/information-schema/information-schema-table-constraints.md +++ b/information-schema/information-schema-table-constraints.md @@ -51,4 +51,4 @@ SELECT * FROM table_constraints WHERE constraint_type='UNIQUE'; - `CONSTRAINT_SCHEMA` : 制約が属するデータベースの名前。 - `CONSTRAINT_NAME` : 制約の名前。 - `TABLE_NAME` : テーブルの名前。 -- `CONSTRAINT_TYPE` : 制約の種類。値は`UNIQUE` 、 `PRIMARY KEY` 、または`FOREIGN KEY`いずれかです。8 と`UNIQUE` `PRIMARY KEY`情報は、 `SHOW INDEX`ステートメントの実行結果と同様です。 +- `CONSTRAINT_TYPE` : 制約の種類。値は`UNIQUE` 、 `PRIMARY KEY` 、または`FOREIGN KEY`のいずれかです。`UNIQUE`と`PRIMARY KEY`の情報は、 `SHOW INDEX`ステートメントの実行結果と同様です。 diff --git a/information-schema/information-schema-tables.md b/information-schema/information-schema-tables.md index 6565249014c48..da08c150d5477 100644 --- a/information-schema/information-schema-tables.md +++ b/information-schema/information-schema-tables.md @@ -106,7 +106,7 @@ SHOW TABLES - `ROW_FORMAT` : 行形式。現在の値は`Compact`です。 - `TABLE_ROWS` : 統計におけるテーブル内の行数。 - `AVG_ROW_LENGTH` : 表の平均行の長さ`AVG_ROW_LENGTH` = `DATA_LENGTH` / `TABLE_ROWS` 。 -- `DATA_LENGTH` : データ長。2 = `DATA_LENGTH` * タプル内の列`TABLE_ROWS`storage長の合計。TiKVのレプリカは考慮されません。 +- `DATA_LENGTH` : データ長。`DATA_LENGTH` = `TABLE_ROWS` * タプル内の列のstorage長の合計。TiKVのレプリカは考慮されません。 - `MAX_DATA_LENGTH` : 最大データ長。現在の値は`0` 、データ長に上限がないことを意味します。 - `INDEX_LENGTH` : インデックスの長さ`INDEX_LENGTH` = `TABLE_ROWS` * インデックスタプル内の列の長さの合計。TiKVのレプリカは考慮されません。 - `DATA_FREE` : データフラグメント。現在の値は`0`です。 diff --git a/information-schema/information-schema-tidb-check-constraints.md b/information-schema/information-schema-tidb-check-constraints.md index 2bf5bf8283ea0..375fc8ddb4c81 100644 --- a/information-schema/information-schema-tidb-check-constraints.md +++ b/information-schema/information-schema-tidb-check-constraints.md @@ -5,7 +5,7 @@ summary: TIDB_CHECK_CONSTRAINTS` INFORMATION_SCHEMA テーブルについて学 # TIDB_CHECK_CONSTRAINTS {#tidb-check-constraints} -`TIDB_CHECK_CONSTRAINTS`表は[`CHECK`制約](/constraints.md#check)表に関する情報を提供します。5 の[`CHECK_CONSTRAINTS`](/information-schema/information-schema-check-constraints.md)に加えて、 `TIDB_CHECK_CONSTRAINTS` `CHECK`制約を定義する表の名前と ID を提供します。 +`TIDB_CHECK_CONSTRAINTS`表は[`CHECK`制約](/constraints.md#check)表に関する情報を提供します。[`CHECK_CONSTRAINTS`](/information-schema/information-schema-check-constraints.md)の列に加えて、 `TIDB_CHECK_CONSTRAINTS`は`CHECK`制約を定義する表の名前と ID を提供します。 ```sql USE INFORMATION_SCHEMA; diff --git a/information-schema/information-schema-tidb-servers-info.md b/information-schema/information-schema-tidb-servers-info.md index c8f2006440b47..61ee5ffe7da46 100644 --- a/information-schema/information-schema-tidb-servers-info.md +++ b/information-schema/information-schema-tidb-servers-info.md @@ -35,7 +35,7 @@ DESC tidb_servers_info; 9 rows in set (0.00 sec) ``` -`TIDB_SERVERS_INFO`テーブルをビュー。 +`TIDB_SERVERS_INFO`テーブルを確認します。 ```sql SELECT * FROM TIDB_SERVERS_INFO\G diff --git a/information-schema/information-schema-tidb-trx.md b/information-schema/information-schema-tidb-trx.md index f924245610aab..7756da326b086 100644 --- a/information-schema/information-schema-tidb-trx.md +++ b/information-schema/information-schema-tidb-trx.md @@ -52,7 +52,7 @@ DESC TIDB_TRX; - `SESSION_ID` : このトランザクションが属するセッションの ID。 - `USER` : トランザクションを実行するユーザーの名前。 - `DB` : トランザクションが実行されるセッションの現在のデフォルトのデータベース名。 -- `ALL_SQL_DIGESTS` : トランザクションによって実行された文のダイジェストリスト。このリストはJSON形式の文字列配列として表示されます。各トランザクションは最大で最初の50文を記録します。2 [`TIDB_DECODE_SQL_DIGESTS`](/functions-and-operators/tidb-functions.md#tidb_decode_sql_digests)を使用すると、この列の情報を対応する正規化されたSQL文のリストに変換できます。 +- `ALL_SQL_DIGESTS` : トランザクションによって実行された文のダイジェストリスト。このリストはJSON形式の文字列配列として表示されます。各トランザクションは最大で最初の50文を記録します。[`TIDB_DECODE_SQL_DIGESTS`](/functions-and-operators/tidb-functions.md#tidb_decode_sql_digests)を使用すると、この列の情報を対応する正規化されたSQL文のリストに変換できます。 - `RELATED_TABLE_IDS` : トランザクションがアクセスするテーブル、ビュー、およびその他のオブジェクトの ID。 > **Note:** @@ -64,7 +64,7 @@ DESC TIDB_TRX; ## 例 {#example} -`TIDB_TRX`テーブルをビュー: +`TIDB_TRX`テーブルを確認します: ```sql SELECT * FROM INFORMATION_SCHEMA.TIDB_TRX\G @@ -125,7 +125,7 @@ all_sql_digests: ["e6f07d43b5c21db0fbb9a31feac2dc599787763393dd5acbfad80e247eb02 ## クラスター_TIDB_TRX {#cluster-tidb-trx} -`TIDB_TRX`テーブルは、単一の TiDB ノードで実行されているトランザクションに関する情報のみを提供します。クラスター全体のすべての TiDB ノードで実行されているトランザクションの情報を表示するには、 `CLUSTER_TIDB_TRX`テーブルをクエリする必要があります。5 テーブルのクエリ結果と比較すると、 `TIDB_TRX`テーブルのクエリ結果には`INSTANCE`フィールドが追加されています`INSTANCE`フィールド`CLUSTER_TIDB_TRX`は、クラスター内の各ノードの IP アドレスとポート番号が表示され、トランザクションが配置されている TiDB ノードを識別するために使用されます。 +`TIDB_TRX`テーブルは、単一の TiDB ノードで実行されているトランザクションに関する情報のみを提供します。クラスター全体のすべての TiDB ノードで実行されているトランザクションの情報を表示するには、 `CLUSTER_TIDB_TRX`テーブルをクエリする必要があります。`TIDB_TRX`テーブルのクエリ結果と比較すると、 `CLUSTER_TIDB_TRX`テーブルのクエリ結果には`INSTANCE`フィールドが追加されています。`INSTANCE`フィールドには、クラスター内の各ノードの IP アドレスとポート番号が表示され、トランザクションが配置されている TiDB ノードを識別するために使用されます。 ```sql USE INFORMATION_SCHEMA; diff --git a/information-schema/information-schema-tiflash-replica.md b/information-schema/information-schema-tiflash-replica.md index 3d424c764de45..300e471359d59 100644 --- a/information-schema/information-schema-tiflash-replica.md +++ b/information-schema/information-schema-tiflash-replica.md @@ -37,4 +37,4 @@ DESC TIFLASH_REPLICA; - `REPLICA_COUNT` : TiFlashレプリカの数。 - `LOCATION_LABELS` : TiFlashレプリカが作成されるときに設定される LocationLabelList。 - `AVAILABLE` : テーブルのTiFlashレプリカが利用可能かどうかを示します。値が`1` （利用可能）の場合、TiDB オプティマイザーはクエリコストに基づいて、クエリを TiKV またはTiFlashにプッシュダウンするかをインテリジェントに選択します。値が`0` （利用不可）の場合、TiDB はクエリをTiFlashにプッシュダウンしません。このフィールドの値が`1` （利用可能）になると、それ以上変化しなくなります。 -- `PROGRESS` : TiFlashレプリカのレプリケーションの進行状況。小数点以下2桁の精度で分単位です。このフィールドのスコープは`[0, 1]`です。4 `AVAILABLE`が`1`で`PROGRESS` 1未満の場合、 TiFlashレプリカはTiKVより大幅に遅れており、データレプリケーションの待機タイムアウトにより、 TiFlashにプッシュダウンされたクエリは失敗する可能性があります。 +- `PROGRESS` : TiFlashレプリカのレプリケーションの進行状況。小数点以下2桁の精度で分単位です。このフィールドのスコープは`[0, 1]`です。`AVAILABLE`が`1`で`PROGRESS` 1未満の場合、 TiFlashレプリカはTiKVより大幅に遅れており、データレプリケーションの待機タイムアウトにより、 TiFlashにプッシュダウンされたクエリは失敗する可能性があります。 diff --git a/information-schema/information-schema-tiflash-segments.md b/information-schema/information-schema-tiflash-segments.md index d79052c0da69f..052ff638dc2c7 100644 --- a/information-schema/information-schema-tiflash-segments.md +++ b/information-schema/information-schema-tiflash-segments.md @@ -59,7 +59,7 @@ DESC tiflash_segments; - `TIDB_DATABASE` : TiDB内のデータベース名。セグメントはこのデータベース内のテーブルに属します。 - `TIDB_TABLE` : TiDB内のテーブル名。セグメントはこのテーブルに属します。 - `TABLE_ID` : セグメントが属するテーブルの内部ID。このIDはTiDBクラスタ内で一意です。 -- `IS_TOMBSTONE` : セグメントが属するテーブルがリサイクル可能かどうかを示します。2 `1`テーブルがリサイクル可能であることを示します。4 `0`テーブルが通常の状態であることを示します。 +- `IS_TOMBSTONE` : セグメントが属するテーブルがリサイクル可能かどうかを示します。`1`テーブルがリサイクル可能であることを示します。`0`テーブルが通常の状態であることを示します。 - `SEGMENT_ID` : テーブル内で一意のセグメント ID。 - `RANGE` : セグメントに含まれるデータの範囲。 - `EPOCH` : セグメントの更新バージョン。各セグメントのバージョン番号は単調に増加します。 diff --git a/information-schema/information-schema-tiflash-tables.md b/information-schema/information-schema-tiflash-tables.md index 43dfd3471b65c..3e4aa72d71e81 100644 --- a/information-schema/information-schema-tiflash-tables.md +++ b/information-schema/information-schema-tiflash-tables.md @@ -80,7 +80,7 @@ DESC tiflash_tables; - `TIDB_DATABASE` : TiDB 内でテーブルが属するデータベースの名前。 - `TIDB_TABLE` : TiDB 内のテーブルの名前。 - `TABLE_ID` : テーブルの内部 ID。TiDB クラスター内で一意です。 -- `IS_TOMBSTONE` : テーブルがリサイクル可能かどうかを示します。2 `1`テーブルがリサイクル可能であることを示し、 `0`テーブルが通常の状態であることを示します。 +- `IS_TOMBSTONE` : テーブルがリサイクル可能かどうかを示します。`1`テーブルがリサイクル可能であることを示し、 `0`テーブルが通常の状態であることを示します。 - `SEGMENT_COUNT` : テーブル内のセグメント数。セグメントはTiFlashにおけるデータ管理単位です。 - `TOTAL_ROWS` : テーブル内の行の合計数。 - `TOTAL_SIZE` : テーブルの合計サイズ (バイト単位)。 diff --git a/information-schema/information-schema-variables-info.md b/information-schema/information-schema-variables-info.md index 38bca48e99379..eb6246706ae58 100644 --- a/information-schema/information-schema-variables-info.md +++ b/information-schema/information-schema-variables-info.md @@ -46,7 +46,7 @@ SELECT * FROM variables_info ORDER BY variable_name LIMIT 3; `VARIABLES_INFO`テーブル内のフィールドは次のように説明されます。 - `VARIABLE_NAME` : システム変数の名前。 -- `VARIABLE_SCOPE` : システム変数のスコープ。2 `SESSION` 、システム変数が現在のセッションでのみ有効であることを意味します。4 `INSTANCE` 、システム変数が TiDB インスタンスで有効であることを意味します。6 `GLOBAL` 、システム変数が TiDB クラスターで有効であることを意味します。8 `NONE` 、システム変数が TiDB クラスターで読み取り専用であることを意味します。 +- `VARIABLE_SCOPE` : システム変数のスコープ。`SESSION` 、システム変数が現在のセッションでのみ有効であることを意味します。`INSTANCE` 、システム変数が TiDB インスタンスで有効であることを意味します。`GLOBAL` 、システム変数が TiDB クラスターで有効であることを意味します。`NONE` 、システム変数が TiDB クラスターで読み取り専用であることを意味します。 - `DEFAULT_VALUE` : システム変数のデフォルト値。 - `CURRENT_VALUE` : システム変数の現在の値。スコープに`SESSION`含まれる場合、現在のセッションでは`CURRENT_VALUE`値となります。 - `MIN_VALUE` : システム変数に許容される最小値。システム変数が数値でない場合、 `MIN_VALUE` NULL になります。 diff --git a/latency-breakdown.md b/latency-breakdown.md index ee161256538f2..74d62e169996d 100644 --- a/latency-breakdown.md +++ b/latency-breakdown.md @@ -138,7 +138,7 @@ read value duration(from disk) = sum(rate(tikv_storage_rocksdb_perf{metric="block_read_time",req="get/batch_get_command"})) / sum(rate(tikv_storage_rocksdb_perf{metric="block_read_count",req="get/batch_get_command"})) ``` -TiKVはストレージエンジンとしてRocksDBを使用します。必要な値がブロックキャッシュに存在しない場合、TiKVはディスクから値をロードする必要があります。1 `tikv_storage_rocksdb_perf`場合、getリクエストは`get`または`batch_get_command`いずれかになります。 +TiKVはストレージエンジンとしてRocksDBを使用します。必要な値がブロックキャッシュに存在しない場合、TiKVはディスクから値をロードする必要があります。`tikv_storage_rocksdb_perf`の場合、getリクエストは`get`または`batch_get_command`のいずれかになります。 ### Batch PointGet {#batch-point-get} @@ -227,7 +227,7 @@ tidb_session_execute_duration_seconds{type="general"} = tidb_distsql_handle_query_duration_seconds{sql_type="general"} <= send request duration ``` -テーブルスキャンとインデックススキャンは同じように処理されます。1 `req_per_copr`分散タスク数です。コプロセッサの実行とクライアントへのデータ応答は異なるスレッドで行われるため、待機時間は`tidb_distsql_handle_query_duration_seconds{sql_type="general"}`となり、 `send request duration`よりも短くなります。 +テーブルスキャンとインデックススキャンは同じように処理されます。`req_per_copr`分散タスク数です。コプロセッサの実行とクライアントへのデータ応答は異なるスレッドで行われるため、待機時間は`tidb_distsql_handle_query_duration_seconds{sql_type="general"}`となり、 `send request duration`よりも短くなります。 `send request duration`と`req_per_copr`次のように計算されます。 @@ -247,7 +247,7 @@ tikv_grpc_msg_duration_seconds{type="coprocessor"} = req_per_copr = rate(tidb_distsql_handle_query_duration_seconds_count) / rate(tidb_distsql_scan_keys_partial_num_count) ``` -TiKVでは、テーブルスキャンタイプは`select` 、インデックススキャンタイプは`index`です。5と`select` `index`タイプの所要時間の詳細は同じです。 +TiKVでは、テーブルスキャンタイプは`select` 、インデックススキャンタイプは`index`です。`select`と`index`タイプの所要時間の詳細は同じです。 ### インデックス検索 {#index-look-up} @@ -757,7 +757,7 @@ async io enabled commit = max( ) ``` -v5.3.0以降、TiKVはAsync IO Raft （StoreWriterスレッドプールによるRaftログの書き込み）をサポートしています。Async IO Raftは、 [`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)正の値に設定されている場合にのみ有効になり、コミットプロセスが変更されます。3と`persist log locally duration` `wait by write worker duration`以下のように計算されます。 +v5.3.0以降、TiKVはAsync IO Raft （StoreWriterスレッドプールによるRaftログの書き込み）をサポートしています。Async IO Raftは、 [`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)が正の値に設定されている場合にのみ有効になり、コミットプロセスが変更されます。`persist log locally duration`と`wait by write worker duration`は以下のように計算されます。 ```text persist log locally duration = @@ -779,7 +779,7 @@ wait by write worker duration = 非同期IOの有無の違いは、ログがローカルに保持される期間です。非同期IOを使用する場合、ログがローカルに保持される期間は、ウォーターフォールメトリックから直接計算できます（バッチ待機時間は考慮されません）。 -レプリケートログ期間は、クォーラムピアに保持されたログの期間を記録します。これには、RPC期間と過半数に保持されたログの期間が含まれます。1は`replicate log duration`のように計算されます。 +レプリケートログ期間は、クォーラムピアに保持されたログの期間を記録します。これには、RPC期間と過半数に保持されたログの期間が含まれます。`replicate log duration`は以下のように計算されます。 ```text replicate log duration = diff --git a/literal-values.md b/literal-values.md index d7c79bc1f0ce3..ddb0fec3a0638 100644 --- a/literal-values.md +++ b/literal-values.md @@ -130,7 +130,7 @@ SELECT TRUE, true, tRuE, FALSE, FaLsE, false; ## 16進数リテラル {#hexadecimal-literals} -16進数リテラル値は`X'val'`または`0xval`表記法で記述されます。5 `val`は16進数が含まれます。先頭の`0x`は大文字と小文字が区別され、 `0X`と表記することはできません。 +16進数リテラル値は`X'val'`または`0xval`表記法で記述されます。`val`は16進数が含まれます。先頭の`0x`は大文字と小文字が区別され、 `0X`と表記することはできません。 有効な16進数リテラル: @@ -146,7 +146,7 @@ SELECT TRUE, true, tRuE, FALSE, FaLsE, false; X'1z' (z is not a hexadecimal legal digit) 0X12AC (0X must be written as 0x) -`X'val'`記法で記述された`val`進数リテラルは、偶数桁でなければなりません。3 の長さが奇数（例えば`X'A'`や`X'11A'` ）の場合、構文エラーを回避するには、値の先頭にゼロを付加します。 +`X'val'`記法で記述された`val`進数リテラルは、偶数桁でなければなりません。`val`の長さが奇数（例えば`X'A'`や`X'11A'` ）の場合、構文エラーを回避するには、値の先頭にゼロを付加します。 ```sql mysql> select X'aff'; @@ -184,7 +184,7 @@ mysql> SELECT X'54694442'; ## ビット値リテラル {#bit-value-literals} -ビット値リテラルは`b'val'`または`0bval`表記法で記述されます。5 `val` 0と1で記述された2進値です。先頭の`0b`は大文字と小文字が区別され、 `0B`と記述することはできません。 +ビット値リテラルは`b'val'`または`0bval`表記法で記述されます。`val` 0と1で記述された2進値です。先頭の`0b`は大文字と小文字が区別され、 `0B`と記述することはできません。 有効なビット値リテラル: diff --git a/log-redaction.md b/log-redaction.md index 0ea590c79e618..27174f45445be 100644 --- a/log-redaction.md +++ b/log-redaction.md @@ -33,7 +33,7 @@ ERROR 1062 (23000): Duplicate entry '1' for key 't.a' 上記のエラー ログから、値`tidb_redact_log`が`ON`に設定されると、データ セキュリティ リスクを回避するために、機密情報が TiDB ログで`?`マークに置き換えられることがわかります。 -さらに、TiDBには`MARKER`オプションが用意されています。3 `tidb_redact_log`値を`MARKER`に設定すると、TiDBはログ内の機密情報を直接置き換えるのではなく、 `‹›`でマークするため、編集ルールをカスタマイズできます。 +さらに、TiDBには`MARKER`オプションが用意されています。`tidb_redact_log`値を`MARKER`に設定すると、TiDBはログ内の機密情報を直接置き換えるのではなく、 `‹›`でマークするため、編集ルールをカスタマイズできます。 ```sql set @@global.tidb_redact_log = MARKER; diff --git a/metadata-lock.md b/metadata-lock.md index 363406f12523c..f2074dba44e2a 100644 --- a/metadata-lock.md +++ b/metadata-lock.md @@ -50,7 +50,7 @@ TiDB v6.5.0以降、メタデータロックはデフォルトで有効になり | `INSERT INTO t VALUES(1);` | | | `BEGIN;` | | | | `ALTER TABLE t ADD COLUMN b INT;` | - | `SELECT * FROM t;`
(テーブル`t`の現在のメタデータ バージョンを使用します。5 `(a=1, b=NULL)`返し、テーブル`t`をロックします。) | | + | `SELECT * FROM t;`
(テーブル`t`の現在のメタデータ バージョンを使用します。`(a=1, b=NULL)`を返し、テーブル`t`をロックします。) | | | | `ALTER TABLE t ADD COLUMN c INT;` (セッション 1 によってブロックされています) | 繰り返し可能読み取り分離レベルでは、トランザクションの開始からテーブルのメタデータを決定する時点までの間に、インデックスの追加や列タイプの変更など、データの変更を必要とする DDL が実行されると、DDL は次のようにエラーを返します。 @@ -94,7 +94,7 @@ SQL_DIGESTS: ["begin","select * from `t`"] ``` -上記の出力から、 `SESSION ID`が`1547698182`あるトランザクションが`ADD COLUMN` DDLをブロックしていることがわかります。7 `SQL_DIGEST` 、このトランザクションによって実行されたSQL文（ ``["begin","select * from `t`"]``を示しています。ブロックされたDDLの実行を継続するには、次のグローバル`KILL`文を使用して`1547698182`トランザクションを強制終了します。 +上記の出力から、 `SESSION ID`が`1547698182`あるトランザクションが`ADD COLUMN` DDLをブロックしていることがわかります。`SQL_DIGEST` 、このトランザクションによって実行されたSQL文（ ``["begin","select * from `t`"]``を示しています。ブロックされたDDLの実行を継続するには、次のグローバル`KILL`文を使用して`1547698182`トランザクションを強制終了します。 ```sql mysql> KILL 1547698182; diff --git a/metrics-schema.md b/metrics-schema.md index d38e390a376a7..6846add7dc04a 100644 --- a/metrics-schema.md +++ b/metrics-schema.md @@ -113,9 +113,9 @@ SELECT * FROM information_schema.metrics_tables WHERE table_name='tidb_query_dur - `TABLE_NAME` : `metrics_schema`のテーブル名に対応します。この例では、テーブル名は`tidb_query_duration`です。 - `PROMQL` : 監視テーブルの動作原理は、まずSQL文を`PromQL`にマッピングし、次にPrometheusにデータを要求し、Prometheusの結果をSQLクエリ結果に変換することです。このフィールドは`PromQL`の式テンプレートです。監視テーブルのデータをクエリすると、クエリ条件を使用してこのテンプレート内の変数が書き換えられ、最終的なクエリ式が生成されます。 -- `LABELS` : 監視項目のラベル。2 `tidb_query_duration`は`instance`と`sql_type` 2 つのラベルがあります。 +- `LABELS` : 監視項目のラベル。`tidb_query_duration`は`instance`と`sql_type` 2 つのラベルがあります。 - `QUANTILE` : パーセンタイル。ヒストグラム型の監視データの場合、デフォルトのパーセンタイルが指定されます。このフィールドの値が`0`の場合、監視テーブルに対応する監視項目はヒストグラムではないことを意味します。 -- `COMMENT` : 監視テーブルの説明。2 `tidb_query_duration`テーブルは、TiDBクエリ実行のパーセンタイル時間（P999/P99/P90のクエリ時間など）を照会するために使用されていることがわかります。単位は秒です。 +- `COMMENT` : 監視テーブルの説明。`tidb_query_duration`テーブルは、TiDBクエリ実行のパーセンタイル時間（P999/P99/P90のクエリ時間など）を照会するために使用されていることがわかります。単位は秒です。 `tidb_query_duration`テーブルのスキーマをクエリするには、次のステートメントを実行します。 @@ -138,7 +138,7 @@ SHOW CREATE TABLE metrics_schema.tidb_query_duration; ``` - `time` : 監視項目の時間。 -- `instance`と`sql_type` : `tidb_query_duration`監視項目のラベル。6 `instance`監視アドレスを意味します。8 `sql_type`実行された SQL 文の種類を意味します。 +- `instance`と`sql_type` : `tidb_query_duration`監視項目のラベル。`instance`は監視アドレスを意味します。`sql_type`は実行された SQL 文の種類を意味します。 - `quantile` : パーセンタイル。ヒストグラム型の監視項目にはこの列があり、クエリのパーセンタイル時間を示します。例えば、 `quantile = 0.9` P90の時間をクエリすることを意味します。 - `value` : 監視項目の値。 @@ -164,7 +164,7 @@ SELECT * FROM metrics_schema.tidb_query_duration WHERE value is not null AND tim +---------------------+-------------------+----------+----------+----------------+ ``` -上記のクエリ結果の最初の行は、2020年3月25日 23:40:00の時点において、TiDBインスタンス`172.16.5.40:10089`において、 `Insert`番目の文のP99実行時間が0.509929485256秒であることを意味します。他の行も同様の意味を持ちます。5 `sql_type`の列のその他の値は、以下のように記述されます。 +上記のクエリ結果の最初の行は、2020年3月25日 23:40:00の時点において、TiDBインスタンス`172.16.5.40:10089`において、 `Insert`番目の文のP99実行時間が0.509929485256秒であることを意味します。他の行も同様の意味を持ちます。`sql_type`の列のその他の値は、以下のように記述されます。 - `Select` : `select`型のステートメントが実行されます。 - `internal` : 統計情報を更新し、グローバル変数を取得するために使用される TiDB の内部 SQL ステートメント。 @@ -186,7 +186,7 @@ DESC SELECT * FROM metrics_schema.tidb_query_duration WHERE value is not null AN 上記の結果から、実行プランには`PromQL` 、 `start_time` 、 `end_time` 、 `step`含まれていることがわかります。実行プロセス中、TiDBはPrometheusの`query_range` HTTP APIを呼び出して監視データを照会します。 -[ `2020-03-25 23:40:00` , `2020-03-25 23:42:00` ] の範囲では、各ラベルに3つの時間値しかないことに気づくかもしれません。実行プランでは、 `step`の値は1分であり、これらの値の間隔は1分であることを意味します。7 `step`次の2つのセッション変数によって決定されます。 +[ `2020-03-25 23:40:00` , `2020-03-25 23:42:00` ] の範囲では、各ラベルに3つの時間値しかないことに気づくかもしれません。実行プランでは、 `step`の値は1分であり、これらの値の間隔は1分であることを意味します。`step`次の2つのセッション変数によって決定されます。 - `tidb_metric_query_step` : クエリ解決ステップ幅。Prometheusから`query_range`データを取得するには、 `start_time` 、 `end_time` 、 `step`指定する必要があります。 `step` 、この変数の値が使用されます。 - `tidb_metric_query_range_duration` : 監視データが照会されると、 `PROMQL`の`$ RANGE_DURATION`のフィールドの値がこの変数の値に置き換えられます。デフォルト値は60秒です。 diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index 6dbe380d1313a..da215cdf246b8 100644 --- a/migrate-from-tidb-to-tidb.md +++ b/migrate-from-tidb-to-tidb.md @@ -151,7 +151,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー +---------------+----------+--------------------+---------------------+---------------------+ 1 row in set (2.11 sec) - `BACKUP`コマンドの実行後、TiDB はバックアップデータに関するメタデータを返します。3 はバックアップ前に生成されたデータなので、ご注意ください。このドキュメントでは、 `BackupTS` `BackupTS`**データチェックの終了**と**TiCDC による増分移行スキャンの開始**として使用します。 + `BACKUP`コマンドの実行後、TiDB はバックアップデータに関するメタデータを返します。`BackupTS`より前に生成されたデータがバックアップされるため、ご注意ください。このドキュメントでは、 `BackupTS`を**データチェックの終了**と**TiCDC による増分移行スキャンの開始**として使用します。 3. データを復元します。 diff --git a/migrate-large-mysql-shards-to-tidb.md b/migrate-large-mysql-shards-to-tidb.md index ad834af095bcb..a74f82052d6a9 100644 --- a/migrate-large-mysql-shards-to-tidb.md +++ b/migrate-large-mysql-shards-to-tidb.md @@ -204,7 +204,7 @@ CREATE TABLE `table5` ( 3. 移行タスクを開始した後、以下のいずれかの方法で進捗状況を確認できます。 - `grep`ツールを使用して、ログファイル内でキーワード`progress`を検索してください。デフォルトでは、進行状況を報告するメッセージが5分ごとにログファイルに書き込まれます。 - - 監視ダッシュボードから進捗状況をビュー。詳細については、 [TiDB Lightningモニタリング](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 + - 監視ダッシュボードから進捗状況を確認します。詳細については、 [TiDB Lightningモニタリング](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 diff --git a/migrate-large-mysql-to-tidb.md b/migrate-large-mysql-to-tidb.md index b19f45cbf1e21..3067cca213aa8 100644 --- a/migrate-large-mysql-to-tidb.md +++ b/migrate-large-mysql-to-tidb.md @@ -94,7 +94,7 @@ LIMIT `${data-path}`には、エクスポートされたすべての上流テーブルを保存するのに十分な空き容量があることを確認してください。必要な容量を計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。大きなテーブルがすべてのスペースを消費してエクスポートが中断されるのを防ぐため、 `-F`オプションを使用して単一ファイルのサイズを制限することを強くお勧めします。 -2. `metadata`ディレクトリにある`${data-path}`ファイルをビュー。これは、Dumpling によって生成されたメタデータ ファイルです。ステップ 3 の増分レプリケーションに必要なbinlogの位置情報を記録します。 +2. `${data-path}`ディレクトリにある`metadata`ファイルを確認します。これは、Dumpling によって生成されたメタデータ ファイルです。ステップ 3 の増分レプリケーションに必要なbinlogの位置情報を記録します。 SHOW MASTER STATUS: Log: mysql-bin.000004 diff --git a/migrate-small-mysql-shards-to-tidb.md b/migrate-small-mysql-shards-to-tidb.md index dbc0ff7723a77..14b9d0fe69da1 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 クラスターに読み込みます。 +ターミナルで次のコマンドを実行します。`tiup dmctl`を指定して、データソース構成を DM クラスターに読み込みます。 ```shell tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml @@ -204,7 +204,7 @@ tiup dmctl --master-addr ${advertise-addr} start-task task.yaml 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}`を使用して詳細情報を表示してください。`query-status`のクエリ結果、タスクステータス、サブタスクステータスの詳細については、 [TiDB データ移行クエリのステータス](/dm/dm-query-status.md)を参照してください。 ## ステップ5. タスクを監視し、ログを確認する（オプション） {#step-5-monitor-tasks-and-check-logs-optional} diff --git a/migrate-with-more-columns-downstream.md b/migrate-with-more-columns-downstream.md index 43b32687af0fb..c583756322385 100644 --- a/migrate-with-more-columns-downstream.md +++ b/migrate-with-more-columns-downstream.md @@ -73,11 +73,11 @@ DM がダウンストリーム テーブル スキーマを使用してアップ | パラメータ | 説明 | | :------------------ | :--------------------------------------------------------------------------------------------------------------- | - | `-master-addr` | dmctl が接続されるクラスター内の任意の DM マスター ノードの`${advertise-addr}`指定します。3 `${advertise-addr}` 、DM マスターが外部にアドバタイズするアドレスを示します。 | + | `-master-addr` | dmctl が接続されるクラスター内の任意の DM マスター ノードの`${advertise-addr}`を指定します。`${advertise-addr}` 、DM マスターが外部にアドバタイズするアドレスを示します。 | | `binlog-schema set` | スキーマ情報を手動で設定します。 | - | `-s` | ソースを指定します。1 `${source-id}` MySQL データのソース ID を示します。 | + | `-s` | ソースを指定します。`${source-id}` MySQL データのソース ID を示します。 | | `${task-name}` | データ移行タスクの`task.yaml`構成ファイルで定義されている移行タスクの名前を指定します。 | - | `${database-name}` | データベースを指定します。1 `${database-name}`アップストリーム データベースの名前を示します。 | + | `${database-name}` | データベースを指定します。`${database-name}`アップストリーム データベースの名前を示します。 | | `${table-name}` | アップストリーム テーブルの名前を指定します。 | | `${schema-file}` | 設定するテーブル スキーマ ファイルを指定します。 | diff --git a/migration-overview.md b/migration-overview.md index 37033a2d70b75..03a22c57c5438 100644 --- a/migration-overview.md +++ b/migration-overview.md @@ -32,7 +32,7 @@ Auroraから AWS にデプロイされた TiDB クラスターにデータを移 クラウドストレージ(S3) サービスを使用しておらず、ネットワーク接続が良好で、ネットワークレイテンシーが低い場合は、 [小規模データセットをMySQLからTiDBに移行する](/migrate-small-mysql-to-tidb.md)の手順に従って、MySQL から TiDB にデータを移行できます。 -移行速度への要求が高い場合、またはデータサイズが大きい場合（例：1TiB以上）、かつ移行期間中に他のアプリケーションによるTiDBへの書き込みを許可しない場合は、 TiDB Lightningを使用してデータを迅速にインポートできます。その後、DMを使用して、アプリケーションのニーズに応じて増分データ（binlog）を複製できます。1 [大規模データセットをMySQLからTiDBに移行する](/migrate-large-mysql-to-tidb.md)参照してください。 +移行速度への要求が高い場合、またはデータサイズが大きい場合（例：1TiB以上）、かつ移行期間中に他のアプリケーションによるTiDBへの書き込みを許可しない場合は、 TiDB Lightningを使用してデータを迅速にインポートできます。その後、DMを使用して、アプリケーションのニーズに応じて増分データ（binlog）を複製できます。[大規模データセットをMySQLからTiDBに移行する](/migrate-large-mysql-to-tidb.md)を参照してください。 ## MySQL シャードを TiDB に移行してマージする {#migrate-and-merge-mysql-shards-into-tidb} diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md index 1ed3b48f0fa9b..ff719380591ec 100644 --- a/multi-data-centers-in-one-city-deployment.md +++ b/multi-data-centers-in-one-city-deployment.md @@ -161,7 +161,7 @@ tikv_servers: 上記の例では、 `zone`レプリカの分離を制御する論理可用性ゾーンレイヤーです (サンプル クラスターには 3 つのレプリカがあります)。 -将来的に AZ がスケールアウトされる可能性があることを考慮し、3階層ラベル構造（ `az` 、 `rack` 、 `host` ）はそのまま採用しません。 `AZ2` 、 `AZ3` 、 `AZ4`スケールアウトすると仮定した場合、対応するアベイラビリティゾーン内の AZ とラックをスケールアウトするだけで済みます。 +将来的に AZ がスケールアウトされる可能性があることを考慮し、3階層ラベル構造（ `az` 、 `rack` 、 `host` ）はそのまま採用しません。 `AZ2` 、 `AZ3` 、 `AZ4`をスケールアウトすると仮定した場合、対応するアベイラビリティゾーン内の AZ とラックをスケールアウトするだけで済みます。 この 3 層のラベル構造をそのまま採用すると、AZ をスケールアウトした後に、新しいラベルを適用し、TiKV 内のデータを再調整する必要がある場合があります。 diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index a2b0b9eb9fee0..fa0147416016f 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -95,7 +95,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `OFF` - 可能`OFF`値: `ON` -- この変数は、クエリ実行時に演算子`Point Get`と`Batch Point Get`無効にするかどうかを制御します。デフォルト値`OFF` 、演算子`Point Get`と`Batch Point Get`クエリ実行に使用できることを意味します。11 `ON`設定すると、オプティマイザは演算子`Point Get`と`Batch Point Get`無効にし、クエリ実行にコプロセッサーを強制的に選択します。 +- この変数は、クエリ実行時に演算子`Point Get`と`Batch Point Get`を無効にするかどうかを制御します。デフォルト値`OFF`は、演算子`Point Get`と`Batch Point Get`をクエリ実行に使用できることを意味します。`ON`に設定すると、オプティマイザは演算子`Point Get`と`Batch Point Get`を無効にし、クエリ実行にコプロセッサーを強制的に選択します。 - `Point Get`と`Batch Point Get`列投影をサポートしていません（つまり、列のサブセットのみを返すことはできません）。そのため、シナリオによっては、実行効率がコプロセッサーよりも低くなる可能性があります。この変数を`ON`に設定すると、クエリのパフォーマンスが向上します。この変数を`ON`に設定する推奨シナリオは次のとおりです。 - 多数の列を持つ幅の広いテーブルで、少数の列のみがクエリされます。 diff --git a/optimizer-hints.md b/optimizer-hints.md index 26873e4e55325..2e2c9d61c4f94 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -724,7 +724,7 @@ select /*+ NO_INDEX_MERGE() */ * from t where t.a > 0 or t.b > 0; ### USE_TOJA(ブール値) {#use-toja-boolean-value} -`boolean_value`パラメータは`TRUE`または`FALSE`です。7 ヒント`USE_TOJA(TRUE)` 、オプティマイザが`in`条件（サブクエリを含む）を結合および集計演算に変換できるようにします。一方、 `USE_TOJA(FALSE)`ヒントはこの機能を無効にします。 +`boolean_value`パラメータは`TRUE`または`FALSE`です。`USE_TOJA(TRUE)`ヒントは、オプティマイザが`in`条件（サブクエリを含む）を結合および集計演算に変換できるようにします。一方、 `USE_TOJA(FALSE)`ヒントはこの機能を無効にします。 たとえば、次のクエリは`in (select t2.a from t2) subq`対応する結合および集計操作に変換します。 @@ -826,7 +826,7 @@ SELECT /*+ STRAIGHT_JOIN() */ * FROM t t1, t t2 WHERE t1.a = t2.a; ### NTH_PLAN(N) {#nth-plan-n} -ヒント`NTH_PLAN(N)`は、物理的な最適化中に見つかった`N`番目の物理プランを選択するようにオプティマイザーに通知します。5 `N`正の整数である必要があります。 +ヒント`NTH_PLAN(N)`は、物理的な最適化中に見つかった`N`番目の物理プランを選択するようにオプティマイザーに通知します。`N`正の整数である必要があります。 指定された`N`物理最適化の検索範囲を超える場合、TiDB は警告を返し、このヒントを無視する戦略に基づいて最適な物理プランを選択します。 diff --git a/oracle-functions-to-tidb.md b/oracle-functions-to-tidb.md index 0d78ee425d19d..8444e1b806cd3 100644 --- a/oracle-functions-to-tidb.md +++ b/oracle-functions-to-tidb.md @@ -23,7 +23,7 @@ summary: Oracle と TiDB の関数と構文の比較を学習します。 | 現在のシステム時間を秒精度で取得する | `SYSDATE` | `NOW()` | | | 現在のシステム時間をマイクロ秒精度で取得する | `SYSTIMESTAMP` | `CURRENT_TIMESTAMP(6)` | | | 2つの日付間の日数を取得する | `date1 - date2` | `DATEDIFF(date1, date2)` | | -| 2つの日付間の月数を取得する | `MONTHS_BETWEEN(ENDDATE,SYSDATE)` | `TIMESTAMPDIFF(MONTH,SYSDATE,ENDDATE)` | Oracleの`MONTHS_BETWEEN()`とTiDBの`TIMESTAMPDIFF()`の結果は異なります。5 `TIMESTAMPDIFF()`整数を返します。2つの関数のパラメータが入れ替わっていることに注意してください。 | +| 2つの日付間の月数を取得する | `MONTHS_BETWEEN(ENDDATE,SYSDATE)` | `TIMESTAMPDIFF(MONTH,SYSDATE,ENDDATE)` | Oracleの`MONTHS_BETWEEN()`とTiDBの`TIMESTAMPDIFF()`の結果は異なります。`TIMESTAMPDIFF()`整数を返します。2つの関数のパラメータが入れ替わっていることに注意してください。 | | 日付に`n`日を追加する | `DATEVAL + n` | `DATE_ADD(dateVal,INTERVAL n DAY)` | `n`負の値になる場合があります。 | | 日付に`n`月を加算する | `ADD_MONTHS(dateVal,n)` | `DATE_ADD(dateVal,INTERVAL n MONTH)` | `n`負の値になる場合があります。 | | デートの日をゲット | `TRUNC(SYSDATE)` |
  • `CAST(NOW() AS DATE)`
  • `DATE_FORMAT(NOW(),'%Y-%m-%d')`
    • | TiDB では、 `CAST`と`DATE_FORMAT`同じ結果を返します。 | @@ -116,7 +116,7 @@ Oracleでは、最初のクエリ結果には含まれているが2番目のク SELECT * FROM t1 MINUS SELECT * FROM t2 ``` -TiDBは`MINUS`演算をサポートしていません。3 `EXCEPT`の演算を使用できます。例: +TiDBは`MINUS`演算をサポートしていません。`EXCEPT`の演算を使用できます。例: ```sql SELECT * FROM t1 EXCEPT SELECT * FROM t2 diff --git a/partition-pruning.md b/partition-pruning.md index aea8230e7e54a..f486e634f4044 100644 --- a/partition-pruning.md +++ b/partition-pruning.md @@ -226,7 +226,7 @@ explain select * from t where x between 7 and 14; - [`UNIX_TIMESTAMP()`](/functions-and-operators/date-and-time-functions.md) - [`TO_DAYS()`](/functions-and-operators/date-and-time-functions.md) -- [`EXTRACT(<time unit> FROM <DATETIME/DATE/TIME column>)`](/functions-and-operators/date-and-time-functions.md) 。2列および`DATE` `DATETIME`の場合、 `YEAR`および`YEAR_MONTH`時間単位は単調関数とみなされます。10 `TIME`の場合、 `HOUR` 、および`HOUR_SECOND` `HOUR_MICROSECOND`単調関数とみなされます。パーティションプルーニングでは、 `EXTRACT`では`WEEK`時間単位としてサポートされていないこと`HOUR_MINUTE`注意してください。 +- [`EXTRACT(<time unit> FROM <DATETIME/DATE/TIME column>)`](/functions-and-operators/date-and-time-functions.md) 。`DATE`列および`DATETIME`列の場合、 `YEAR`および`YEAR_MONTH`時間単位は単調関数とみなされます。`TIME`列の場合、 `HOUR` 、 `HOUR_MINUTE` 、 `HOUR_SECOND` 、および`HOUR_MICROSECOND`は単調関数とみなされます。パーティションプルーニングでは、 `EXTRACT`で`WEEK`は時間単位としてサポートされていないことに注意してください。 たとえば、パーティション プルーニングは、パーティション式が`fn(col)`形式 ( `fn`は単調関数`to_days`の場合に有効になります。 diff --git a/password-management.md b/password-management.md index 3f00ec01f5468..5d8e0bc5a1a22 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 にログインすることを防ぐことです。`ALTER USER ... ACCOUNT UNLOCK`文でロールのロックが解除されると、パスワードが空であってもこのアカウントでログインできます。そのため、TiDB は`password_expired`属性を使用してパスワードを手動で期限切れにし、ユーザーがアカウントに有効なパスワードを設定するようにしています。 ```sql mysql> CREATE ROLE testrole; @@ -372,7 +372,7 @@ TiDBは、アカウントのログイン失敗回数を追跡できます。ブ `CREATE USER`または`ALTER USER`ステートメントの`FAILED_LOGIN_ATTEMPTS`および`PASSWORD_LOCK_TIME`オプションを使用して、各アカウントのログイン失敗回数とロック時間を設定できます。使用可能な値オプションは次のとおりです。 -- `FAILED_LOGIN_ATTEMPTS` : N。2 `N`連続してログインに失敗すると、アカウントは一時的にロックされます。Nの値の範囲は0～32767です。 +- `FAILED_LOGIN_ATTEMPTS` : N。`N`連続してログインに失敗すると、アカウントは一時的にロックされます。Nの値の範囲は0～32767です。 - `PASSWORD_LOCK_TIME` : N | 無制限。 - Nは、連続してログインに失敗すると、アカウントが`N`日間一時的にロックされることを意味します。Nの値の範囲は0～32767です。 - `UNBOUNDED`ロック時間が無制限であり、アカウントを手動でロック解除する必要があることを意味します。Nの値の範囲は0から32767です。 @@ -418,5 +418,5 @@ ALTER USER 'test3'@'localhost' FAILED_LOGIN_ATTEMPTS 0 PASSWORD_LOCK_TIME 0; > > 連続してログインに失敗したためにアカウントがロックされた場合、アカウント ロック ポリシーを変更すると、次の影響があります。 > -> - `FAILED_LOGIN_ATTEMPTS`変更しても、アカウントのロック状態は変わりません。3 `FAILED_LOGIN_ATTEMPTS`変更は、アカウントのロックが解除され、再度ログインを試みた後に有効になります。 -> - `PASSWORD_LOCK_TIME`変更しても、アカウントのロック状態は変わりません。3 `PASSWORD_LOCK_TIME`変更は、アカウントが再度ログインしようとした際に有効になります。その際、TiDB は新しいロック時間が経過したかどうかを確認します。経過した場合、TiDB はユーザーのロックを解除します。 +> - `FAILED_LOGIN_ATTEMPTS`変更しても、アカウントのロック状態は変わりません。`FAILED_LOGIN_ATTEMPTS`変更は、アカウントのロックが解除され、再度ログインを試みた後に有効になります。 +> - `PASSWORD_LOCK_TIME`変更しても、アカウントのロック状態は変わりません。`PASSWORD_LOCK_TIME`変更は、アカウントが再度ログインしようとした際に有効になります。その際、TiDB は新しいロック時間が経過したかどうかを確認します。経過した場合、TiDB はユーザーのロックを解除します。 diff --git a/pd-configuration-file.md b/pd-configuration-file.md index e8a823d8ac2cf..cf65103ea562d 100644 --- a/pd-configuration-file.md +++ b/pd-configuration-file.md @@ -379,7 +379,7 @@ pd-server関連のコンフィグレーション項目 ### `affinity-schedule-limit` v8.5.5 の新機能 {#affinity-schedule-limit-new-in-v855} -- 同時に実行できる[親和性](/table-affinity.md)スケジュールタスクの数を制御します。3に設定すると`0`アフィニティスケジュールが無効になります。 +- 同時に実行できる[親和性](/table-affinity.md)スケジュールタスクの数を制御します。`0`に設定すると、アフィニティスケジュールが無効になります。 - デフォルト値: `0` ### `high-space-ratio` {#high-space-ratio} diff --git a/pd-control.md b/pd-control.md index 66fcba40da399..b431962045b00 100644 --- a/pd-control.md +++ b/pd-control.md @@ -19,7 +19,7 @@ PD Controlを使用するには、 `tiup ctl:v pd -u http:// pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - config set max-pending-peer-count 64 // Set the maximum number of pending peers to 64 ``` -- `max-merge-region-size`リージョンマージのサイズ上限を制御します（単位は MiB）。2 `regionSize`指定値を超える場合、PD は隣接するリージョンとマージしません。0 に設定すると、リージョンマージが無効になります。 +- `max-merge-region-size`リージョンマージのサイズ上限を制御します（単位は MiB）。`regionSize`指定値を超える場合、PD は隣接するリージョンとマージしません。0 に設定すると、リージョンマージが無効になります。 ```bash config set max-merge-region-size 16 // Set the upper limit on the size of Region Merge to 16 MiB ``` -- `max-merge-region-keys`リージョンマージのキー数の上限を制御します。2 `regionKeyCount`指定された値を超える場合、PD は隣接するリージョンとマージしません。 +- `max-merge-region-keys`はリージョンマージのキー数の上限を制御します。`regionKeyCount`が指定された値を超える場合、PD は隣接するリージョンとマージしません。 ```bash config set max-merge-region-keys 50000 // Set the upper limit on keyCount to 50000 @@ -204,13 +204,13 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - config set split-merge-interval 24h // Set the interval between `split` and `merge` to one day ``` -- `enable-one-way-merge` 、PD がリージョン を次のリージョンとの結合のみを許可するかどうかを制御します。2 `false`設定すると、PD はリージョン を隣接する 2 つの Region との結合を許可します。 +- `enable-one-way-merge` 、PD がリージョン を次のリージョンとの結合のみを許可するかどうかを制御します。`false`設定すると、PD はリージョン を隣接する 2 つの Region との結合を許可します。 ```bash config set enable-one-way-merge true // Enables one-way merging. ``` -- `enable-cross-table-merge` 、テーブル間のリージョンのマージを有効にするために使用されます。2 `false`設定すると、PD は異なるテーブルのリージョンをマージしません。このオプションは、キータイプが「テーブル」の場合にのみ機能します。 +- `enable-cross-table-merge` 、テーブル間のリージョンのマージを有効にするために使用されます。`false`設定すると、PD は異なるテーブルのリージョンをマージしません。このオプションは、キータイプが「テーブル」の場合にのみ機能します。 ```bash config set enable-cross-table-merge true // Enable cross table merge. @@ -219,7 +219,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - `key-type` 、クラスターで使用されるキーエンコーディングの種類を指定します。サポートされているオプションは ["table", "raw", "txn"] で、デフォルト値は "table" です。 - クラスター内に TiDB インスタンスが存在しない場合は、 `key-type` 「raw」または「txn」になり、PD は`enable-cross-table-merge`設定に関係なくテーブル間でリージョンをマージできます。 - - クラスター内にTiDBインスタンスが存在する場合、 `key-type` 「table」である必要があります。PDがテーブル間でリージョンをマージできるかどうかは、 `enable-cross-table-merge`によって決まります。5 `key-type` 「raw」の場合、配置ルールは機能しません。 + - クラスター内にTiDBインスタンスが存在する場合、 `key-type` 「table」である必要があります。PDがテーブル間でリージョンをマージできるかどうかは、 `enable-cross-table-merge`によって決まります。`key-type` 「raw」の場合、配置ルールは機能しません。 ```bash config set key-type raw // Enable cross table merge. @@ -315,17 +315,17 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - `replication-mode`デュアルデータセンターシナリオにおけるリージョンのレプリケーションモードを制御します。詳細は[DR自動同期モードを有効にする](/two-data-centers-in-one-city-deployment.md#enable-the-dr-auto-sync-mode)参照してください。 -- `leader-schedule-policy`はリーダーのスケジューリング戦略を選択するために使用されます。2 または`size`に従ってリーダー`count`スケジュールできます。 +- `leader-schedule-policy`はリーダーのスケジューリング戦略を選択するために使用されます。`size`または`count`に従ってリーダーをスケジュールできます。 - `scheduler-max-waiting-operator`は、各スケジューラ内の待機オペレータの数を制御するために使用されます。 -- `enable-remove-down-replica`は`false`ダウンタイムレプリカの自動削除機能を有効にするために使用されます。2 に設定すると、PDはダウンタイムレプリカを自動的にクリーンアップしません。 +- `enable-remove-down-replica`はダウンタイムレプリカの自動削除機能を有効にするために使用されます。`false`に設定すると、PDはダウンタイムレプリカを自動的にクリーンアップしません。 -- `enable-replace-offline-replica`は、OfflineReplica の移行機能を有効にするために使用されます。2 `false`設定すると、PD はオフラインレプリカを移行しません。 +- `enable-replace-offline-replica`は、OfflineReplica の移行機能を有効にするために使用されます。`false`設定すると、PD はオフラインレプリカを移行しません。 - `enable-make-up-replica`はレプリカ作成機能を有効にするために使用されます。 `false`に設定すると、PDはレプリカが不足しているリージョンに対してレプリカを追加しません。 -- `enable-remove-extra-replica` `false`余分なレプリカを削除する機能を有効にするために使用されます。2 に設定すると、PDは冗長レプリカを持つリージョンの余分なレプリカを削除しません。 +- `enable-remove-extra-replica`は余分なレプリカを削除する機能を有効にするために使用されます。`false`に設定すると、PDは冗長レプリカを持つリージョンの余分なレプリカを削除しません。 - `enable-location-replacement`は分離レベルチェックを有効にするために使用されます。 `false`に設定すると、PDはスケジュール設定によってリージョンレプリカの分離レベルを上げません。 @@ -333,9 +333,9 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - `enable-placement-rules`は配置ルールを有効にするために使用され、v5.0 以降のバージョンではデフォルトで有効になっています。 -- `store-limit-mode`はストア速度を制限するモードを制御するために使用されます。オプションのモードは`auto`と`manual`です。6 `auto`では、ストアは負荷に応じて自動的にバランス調整されます（非推奨）。 +- `store-limit-mode`はストア速度を制限するモードを制御するために使用されます。オプションのモードは`auto`と`manual`です。`auto`では、ストアは負荷に応じて自動的にバランス調整されます（非推奨）。 -- `store-limit-version`ストア制限の計算式のバージョンを制御します。v1 モードでは、 `store limit`を手動で変更することで、単一の TiKV のスケジュール速度を制限できます。v2 モードでは、PD が TiKV スナップショットの機能に基づいて 4 の値を動的に調整するため、 `store limit`値を手動で設定する必要はありません。詳細については、 [ストア制限の原則 v2](/configure-store-limit.md#principles-of-store-limit-v2)を参照してください。 +- `store-limit-version`ストア制限の計算式のバージョンを制御します。v1 モードでは、 `store limit`を手動で変更することで、単一の TiKV のスケジュール速度を制限できます。v2 モードでは、PD が TiKV スナップショットの機能に基づいてその値を動的に調整するため、 `store limit`値を手動で設定する必要はありません。詳細については、 [ストア制限の原則 v2](/configure-store-limit.md#principles-of-store-limit-v2)を参照してください。 ```bash config set store-limit-version v2 // using store limit v2 @@ -1101,7 +1101,7 @@ scheduler config balance-leader-scheduler set batch 3 // Set the size of the ope scheduler config balance-hot-region-scheduler set byte-rate-rank-step-ratio 0.05 ``` -- `src-tolerance-ratio`と`dst-tolerance-ratio`期待値スケジューラの設定項目です。4 `tolerance-ratio`小さいほど、スケジューリングが容易になります。冗長なスケジューリングが発生する場合は、この値を適切に増やしてください。 +- `src-tolerance-ratio`と`dst-tolerance-ratio`期待値スケジューラの設定項目です。`tolerance-ratio`小さいほど、スケジューリングが容易になります。冗長なスケジューリングが発生する場合は、この値を適切に増やしてください。 ```bash scheduler config balance-hot-region-scheduler set src-tolerance-ratio 1.1 @@ -1133,8 +1133,8 @@ scheduler config balance-leader-scheduler set batch 3 // Set the size of the ope - `rank-formula-version`ホットリージョンスケジューリングで使用するスケジューラアルゴリズムのバージョンを制御します。値の選択肢は`v1`と`v2`です。デフォルト値は`v2`です。 - `v1`アルゴリズムは、TiDB v6.3.0以前のバージョンで使用されていたスケジューラ戦略です。このアルゴリズムは、主にストア間の負荷差を軽減することに重点を置いており、他のディメンションへの副作用の発生を回避します。 - - `v2`アルゴリズムは、TiDB v6.3.0 で導入された実験的スケジューラ戦略であり、TiDB v6.4.0 で一般提供（GA）されました。このアルゴリズムは、副作用を少なくしながら、ストアとファクタ間の公平性を向上させることに主眼を置いています。5 が`strict-picking-store` `true`ある`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 1 次元の優先度均等化により重点を置いています。13 が`strict-picking-store` `false`ある`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 2 次元のバランスを考慮しています。 - - `strict-picking-store`を`true`とする`v1`アルゴリズムは保守的であり、両次元に高負荷のストアがある場合にのみスケジューリングが生成されます。特定のシナリオでは、次元の競合によりバランス調整を継続できなくなる可能性があります。第 1 次元でより適切なバランス調整を実現するには、 `strict-picking-store`を`false`に設定する必要があります。11 アルゴリズムは`v2`両次元でより適切なバランス調整を実現し、無効なスケジューリングを削減します。 + - `v2`アルゴリズムは、TiDB v6.3.0 で導入された実験的スケジューラ戦略であり、TiDB v6.4.0 で一般提供（GA）されました。このアルゴリズムは、副作用を少なくしながら、ストアとファクタ間の公平性を向上させることに主眼を置いています。`strict-picking-store`が`true`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 1 次元の優先度均等化により重点を置いています。`strict-picking-store`が`false`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 2 次元のバランスを考慮しています。 + - `strict-picking-store`を`true`とする`v1`アルゴリズムは保守的であり、両次元に高負荷のストアがある場合にのみスケジューリングが生成されます。特定のシナリオでは、次元の競合によりバランス調整を継続できなくなる可能性があります。第 1 次元でより適切なバランス調整を実現するには、 `strict-picking-store`を`false`に設定する必要があります。`v2`アルゴリズムは両次元でより適切なバランス調整を実現し、無効なスケジューリングを削減します。 ```bash scheduler config balance-hot-region-scheduler set rank-formula-version v2 diff --git a/pd-microservices.md b/pd-microservices.md index 8c7a346e1e9ca..3613f9a0cfcb8 100644 --- a/pd-microservices.md +++ b/pd-microservices.md @@ -81,8 +81,8 @@ TiUP Playground を使用して TiDB ローカル クラスターに PD マイ PD マイクロサービスをデプロイして使用する場合、次の点に注意してください。 - マイクロサービスを有効にしてクラスターのPDを再起動すると、PDはクラスターへのTSOの割り当てを停止します。そのため、マイクロサービスを有効にする際には、クラスターに`tso`マイクロサービスをデプロイする必要があります。 -- `scheduling`マイクロサービスがクラスターにデプロイされている場合、クラスターのスケジューリング機能は`scheduling`マイクロサービスによって提供されます。5 `scheduling`マイクロサービスがデプロイされていない場合でも、クラスターのスケジューリング機能はPDによって提供されます。 -- `scheduling`マイクロサービスは動的スイッチングをサポートしており、これはデフォルトで有効になっています（ `enable-scheduling-fallback`デフォルトで`true`に設定されています）。7 `scheduling`サービスのプロセスが終了した場合、PD はデフォルトでクラスターのスケジューリングサービスを継続します。 +- `scheduling`マイクロサービスがクラスターにデプロイされている場合、クラスターのスケジューリング機能は`scheduling`マイクロサービスによって提供されます。`scheduling`マイクロサービスがデプロイされていない場合でも、クラスターのスケジューリング機能はPDによって提供されます。 +- `scheduling`マイクロサービスは動的スイッチングをサポートしており、これはデフォルトで有効になっています（ `enable-scheduling-fallback`デフォルトで`true`に設定されています）。`scheduling`サービスのプロセスが終了した場合、PD はデフォルトでクラスターのスケジューリングサービスを継続します。 `scheduling`マイクロサービスと PD のバイナリバージョンが異なる場合、スケジューリングロジックの変更を防ぐため、 `pd-ctl config set enable-scheduling-fallback false`実行して`scheduling`マイクロサービスの動的切り替え機能を無効化できます。この機能を無効化すると、 `scheduling`マイクロサービスのプロセスが終了しても PD はスケジューリングサービスを引き継ぎません。つまり、 `scheduling`マイクロサービスが再起動されるまで、クラスターのスケジューリングサービスは利用できなくなります。 @@ -94,4 +94,4 @@ PD マイクロサービスをデプロイして使用する場合、次の点 - PD がパフォーマンスのボトルネックになるかどうかをどのように判断すればよいですか? - クラスターが正常な状態であれば、Grafana PDパネルで監視メトリクスを確認できます。1 `TiDB - PD server TSO handle time`メトリクスでレイテンシーが著しく増加している場合、または`Heartbeat - TiKV side heartbeat statistics`メトリクスで保留中の項目が多数表示されている場合は、PDがパフォーマンスのボトルネックになっていることを示しています。 + クラスターが正常な状態であれば、Grafana PDパネルで監視メトリクスを確認できます。`TiDB - PD server TSO handle time`メトリクスでレイテンシーが著しく増加している場合、または`Heartbeat - TiKV side heartbeat statistics`メトリクスで保留中の項目が多数表示されている場合は、PDがパフォーマンスのボトルネックになっていることを示しています。 diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md index 16ac08d68c11a..bf3457bb9d3f4 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -254,7 +254,7 @@ TiDB、TiKV、PDのCPU/メモリパネルでは、平均CPU、最大CPU、デル - `TiDB -> TiKV: general` : フォアグラウンドトランザクションが TiDB から TiKV に書き込まれる速度 - `TiDB -> TiKV: internal` : 内部トランザクションが TiDB から TiKV に書き込まれる速度 - `TiKV -> Rocksdb` : TiKVからRocksDBへの書き込み操作の流れ - - `RocksDB Compaction` : RocksDBの圧縮操作によって生成される読み取りおよび書き込みI/Oフローの合計。2 `RocksDB Compaction` `TiKV -> Rocksdb`よりも大幅に大きく、平均行サイズが512バイトを超える場合は、min-blob-sizeを`"512B"`または`"1KB"`に設定し、blob-file-compressionを`"zstd"`に設定することで、Titanによる圧縮I/Oフローを削減できます。 + - `RocksDB Compaction` : RocksDBの圧縮操作によって生成される読み取りおよび書き込みI/Oフローの合計。`RocksDB Compaction` `TiKV -> Rocksdb`よりも大幅に大きく、平均行サイズが512バイトを超える場合は、min-blob-sizeを`"512B"`または`"1KB"`に設定し、blob-file-compressionを`"zstd"`に設定することで、Titanによる圧縮I/Oフローを削減できます。 ```toml [rocksdb.titan] @@ -331,7 +331,7 @@ TiDB、TiKV、PDのCPU/メモリパネルでは、平均CPU、最大CPU、デル - アプリケーションサーバーからデータベースへのネットワークレイテンシーが高い。例えば、パブリッククラウド環境では、アプリケーションとTiDBクラスタが同じリージョンに存在しない、またはDNSワークロードバランサとTiDBクラスタが同じリージョンに存在しない場合、ネットワークレイテンシーが高くなります。 - ボトルネックとなっているのはクライアントアプリケーションです。アプリケーションサーバーのCPUコアとNumaリソースを最大限に活用できていません。例えば、TiDBへの数千ものJDBC接続を確立するのに、たった1つのJVMしか使用されていません。 -「接続数」パネルでは、総接続数と各TiDBノードの接続数を確認できます。これにより、総接続数が正常かどうか、また各TiDBノードの接続数が不均衡かどうかを確認できます。1 `active connections`アクティブな接続数を示し、これは1秒あたりのデータベース時間に相当します。右側のY軸（ `disconnection/s` ）は、クラスター内の1秒あたりの切断数を示しており、アプリケーションが短い接続を使用しているかどうかを判断するのに役立ちます。 +「接続数」パネルでは、総接続数と各TiDBノードの接続数を確認できます。これにより、総接続数が正常かどうか、また各TiDBノードの接続数が不均衡かどうかを確認できます。`active connections`アクティブな接続数を示し、これは1秒あたりのデータベース時間に相当します。右側のY軸（ `disconnection/s` ）は、クラスター内の1秒あたりの切断数を示しており、アプリケーションが短い接続を使用しているかどうかを判断するのに役立ちます。 **例1: 切断回数が多すぎる** @@ -341,7 +341,7 @@ TiDB、TiKV、PDのCPU/メモリパネルでは、平均CPU、最大CPU、デル - すべての SQL ステートメントの平均レイテンシーと P99レイテンシーは、それぞれ 10.8 ミリ秒と 84.1 ミリ秒です。 - トランザクション`avg-in-txn`の平均接続アイドル時間は 9.4 ミリ秒です。 -- クラスタへの総接続数は3,700で、各TiDBノードへの接続数は1,800です。アクティブ接続の平均数は40.3で、ほとんどの接続がアイドル状態であることを示しています。1 `disconnection/s`平均数は55.8で、アプリケーションが頻繁に接続と切断を繰り返していることを示しています。短い接続の動作は、TiDBのリソースと応答時間に一定の影響を与えます。 +- クラスタへの総接続数は3,700で、各TiDBノードへの接続数は1,800です。アクティブ接続の平均数は40.3で、ほとんどの接続がアイドル状態であることを示しています。`disconnection/s`平均数は55.8で、アプリケーションが頻繁に接続と切断を繰り返していることを示しています。短い接続の動作は、TiDBのリソースと応答時間に一定の影響を与えます。 **例2: TiDBがユーザー応答時間のボトルネックとなっている** @@ -492,7 +492,7 @@ v5.4.0 では、gPRC モジュールが最適化され、 Raftログのレプリ `Commit Log Duration` `Apply Log Duration` 、raftstore内の主要な操作のレイテンシー指標です。これらのレイテンシはバッチ操作レベルで計測され、各操作は複数の書き込みリクエストを組み合わせます。したがって、これら`Append Log Duration`レイテンシは前述の`Store Duration`と`Apply Duration`に直接対応するものではありません。 -- `Commit Log Duration`と`Append Log Duration` 、 `Store`スレッドで実行された操作時間を記録します。6 `Commit Log Duration`は、 Raftログを他の TiKV ノードにコピーする時間が含まれます (raft-log の永続性を確保するため)。8 `Commit Log Duration`は通常、リーダー用とフォロワー用の 2 つの`Append Log Duration`操作が含まれます。12 は、通常、 `Append Log Duration`よりも大幅に大きくなります。 `Commit Log Duration` 、前者には、ネットワークを介してRaftログを他の TiKV ノードにコピーする時間が含まれるためです。 +- `Commit Log Duration`と`Append Log Duration` 、 `Store`スレッドで実行された操作時間を記録します。6 `Commit Log Duration`は、 Raftログを他の TiKV ノードにコピーする時間が含まれます (raft-log の永続性を確保するため)。8 `Commit Log Duration`は通常、リーダー用とフォロワー用の 2 つの`Append Log Duration`操作が含まれます。`Commit Log Duration`は、通常、 `Append Log Duration`よりも大幅に大きくなります。これは、前者には、ネットワークを介してRaftログを他の TiKV ノードにコピーする時間が含まれるためです。 - `Apply Log Duration` `Apply`スレッドによる`apply` Raftログのレイテンシーを記録します。 `Commit Log Duration`が長い場合の一般的なシナリオ: @@ -537,7 +537,7 @@ v5.4.0 では、gPRC モジュールが最適化され、 Raftログのレプリ - 平均`Commit Log Duration` = 7.92ミリ秒 - 平均`Apply Log Duration` = 172 us -スレッド`Store`の場合、 `Commit Log Duration`明らかに`Apply Log Duration`よりも高い値です。一方、 `Append Log Duration` `Apply Log Duration`よりも大幅に高い値であり、スレッド`Store`はCPUとI/Oの両方でボトルネックが発生している可能性があることを示しています。13と`Commit Log Duration` `Append Log Duration`削減する方法としては、以下のものが考えられます。 +スレッド`Store`の場合、 `Commit Log Duration`は`Apply Log Duration`よりも明らかに高い値です。一方、 `Append Log Duration`は`Apply Log Duration`よりも大幅に高い値であり、スレッド`Store`はCPUとI/Oの両方でボトルネックが発生している可能性があることを示しています。`Commit Log Duration`と`Append Log Duration`を削減する方法としては、以下のものが考えられます。 - TiKV CPU リソースが十分な場合は、 `raftstore.store-pool-size`の値を増やして`Store`スレッドを追加することを検討してください。 - TiDBがv5.4.0以降の場合は、 `raft-engine.enable: true`設定して[`Raft Engine`](/tikv-configuration-file.md#raft-engine)有効にすることを検討してください。RaftRaft Engineは軽量な実行パスを備えています。これにより、I/O書き込みの削減と、一部のシナリオにおける書き込みのロングテールレイテンシーの削減に役立ちます。 diff --git a/performance-tuning-overview.md b/performance-tuning-overview.md index 4a38d9b2bb39d..edb1a9879be1b 100644 --- a/performance-tuning-overview.md +++ b/performance-tuning-overview.md @@ -28,7 +28,7 @@ summary: このドキュメントでは、ユーザー応答時間、スルー ### データベース時間 {#database-time} -データベース時間は、データベースが提供するサービス時間の合計を示します。1 `ΔT`データベース時間は、データベースがすべてのアプリケーション要求を同時に処理するのにかかる時間の合計です。 +データベース時間は、データベースが提供するサービス時間の合計を示します。`ΔT`データベース時間は、データベースがすべてのアプリケーション要求を同時に処理するのにかかる時間の合計です。 データベースの時間を取得するには、次のいずれかの方法を使用できます。 diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index 01185bd4d91c9..9f88df52f4da6 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -180,9 +180,9 @@ TiDB の平均 CPU 使用率は 874% から 936% に増加します。 ### 分析の結論 {#analysis-conclusion} -シナリオ2とは異なり、シナリオ3のアプリケーションはPrepared Statementインターフェースを有効にしていますが、それでもキャッシュにヒットしません。さらに、シナリオ2ではCPS By Typeコマンドの種類が1つ（ `Query` ）しかありませんが、シナリオ3ではコマンドの種類が3つ（ `StmtPrepare` ） `StmtClose`あります。シナリオ2と比較すると、シナリオ3 `StmtExecute`ネットワークのラウンドトリップ遅延が2つ多くなっています。 +シナリオ2とは異なり、シナリオ3のアプリケーションはPrepared Statementインターフェースを有効にしていますが、それでもキャッシュにヒットしません。さらに、シナリオ2ではCPS By Typeコマンドの種類が1つ（ `Query` ）しかありませんが、シナリオ3ではコマンドの種類が3つ（ `StmtPrepare` 、 `StmtExecute` 、 `StmtClose` ）多くあります。シナリオ2と比較すると、シナリオ3はネットワークのラウンドトリップ遅延が2つ多くなっています。 -- QPS の減少に関する分析： **「CPS By Type」**ペインを見ると、シナリオ 2 には「CPS By Type `StmtExecute`コマンドタイプが 1 つ ( `Query` ) しか存在しないのに対し、シナリオ 3 にはさらに 3 つのコマンドタイプ ( `StmtPrepare` ) が存在する`StmtClose` `StmtClose` `StmtPrepare`にカウントされない非従来型コマンドであるため、QPS が減少しています。非従来型コマンドの`StmtPrepare`と`StmtClose`は`general` SQL タイプにカウントされるため、シナリオ 3 のデータベース概要には`general`時間が表示され、これはデータベース時間の 4 分の 1 以上を占めています。 +- QPS の減少に関する分析： **「CPS By Type」**ペインを見ると、シナリオ 2 には CPS By Type コマンドタイプが 1 つ ( `Query` ) しか存在しないのに対し、シナリオ 3 にはさらに 3 つのコマンドタイプ ( `StmtPrepare` 、 `StmtExecute` 、 `StmtClose` ) が存在することがわかります。`StmtPrepare`と`StmtClose`は QPS にカウントされない非従来型コマンドであるため、QPS が減少しています。非従来型コマンドの`StmtPrepare`と`StmtClose`は`general` SQL タイプにカウントされるため、シナリオ 3 のデータベース概要には`general`時間が表示され、これはデータベース時間の 4 分の 1 以上を占めています。 - 平均クエリ時間が大幅に短縮された理由の分析：シナリオ3で新たに追加されたコマンドタイプ`StmtPrepare`と`StmtClose`については、TiDB内部処理においてクエリ時間が個別に計算されます。TiDBはこれらの2種類のコマンドを非常に高速に実行するため、平均クエリ時間が大幅に短縮されます。 シナリオ3ではPrepared Statementインターフェースを使用していますが、多くのアプリケーションフレームワークはメモリリークを防ぐためにメソッド`StmtExecute`の後にメソッド`StmtClose`を呼び出すため、実行プランのキャッシュは依然としてアクセスされません。v6.0.0以降では、グローバル変数`tidb_ignore_prepared_cache_close_stmt=on;`を設定できます。その後、アプリケーションがメソッド`StmtClose`を呼び出しても、TiDBはキャッシュされた実行プランをクリアしません。そのため、次のSQL実行では既存の実行プランを再利用でき、実行プランの繰り返しコンパイルを回避できます。 @@ -296,7 +296,7 @@ TiDBの平均CPU使用率は827%から577%に低下しました。QPSが増加 - シナリオ 4 と比較すると、シナリオ 5 の**CPS By Type**ペインには`StmtExecute`コマンドのみがあり、これにより 2 回のネットワーク ラウンド トリップが回避され、システム全体の QPS が向上します。 - QPSが増加すると、解析時間、コンパイル時間、実行時間の観点からレイテンシーは減少しますが、クエリ時間は増加します。これは、TiDBが`StmtPrepare`と`StmtClose`非常に高速に処理するため、これら2つのコマンドタイプを削除すると平均クエリ時間が増加するためです。 - 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を要求する必要があるためです。 +- 1秒あたり`tso wait`回の実行時間の合計は5.46秒です。`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 が使用されます。 diff --git a/pipelined-dml.md b/pipelined-dml.md index 16e0166352922..81a31f531bcd5 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を使用したステートメントの実行を拒否した場合、それに応じた警告メッセージが生成されます。`SHOW WARNINGS;`を実行すると警告の内容を確認し、原因を特定できます。 一般的な理由: diff --git a/predicate-push-down.md b/predicate-push-down.md index b5378a9702f04..1a30d6482f880 100644 --- a/predicate-push-down.md +++ b/predicate-push-down.md @@ -129,7 +129,7 @@ explain select * from t where a < @a; このクエリでは、テーブル`t`に述語`a < @a`あります。述語の`@a`ユーザー変数です。 -`explain`結果からわかるように、述語はケース 2 とは異なり、ケース`a < 1`に簡略化されて TiKV にプッシュダウンされます。これは、ユーザー変数`@a`の値が計算中に変化する可能性があり、TiKV がその変化を認識しないためです。そのため、TiDB は`@a` `1`に置き換えず、TiKV にプッシュダウンしません。 +`explain`結果からわかるように、述語はケース 2 とは異なり、 `a < 1`に簡略化されて TiKV にプッシュダウンされることはありません。これは、ユーザー変数`@a`の値が計算中に変化する可能性があり、TiKV がその変化を認識しないためです。そのため、TiDB は`@a`を`1`に置き換えず、TiKV にプッシュダウンしません。 理解を助ける例は次のとおりです。 diff --git a/quick-start-with-htap.md b/quick-start-with-htap.md index 51ca90e2c5042..b31c82567f7be 100644 --- a/quick-start-with-htap.md +++ b/quick-start-with-htap.md @@ -148,7 +148,7 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'test' and 上記のステートメントの結果: -- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。2 `1`利用可能、 `0`利用不可を意味します。6 フィールドが`AVAILABLE` `1`なると、このステータスは変更されなくなります。 +- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。`1`は利用可能、 `0`は利用不可を意味します。`AVAILABLE`フィールドが`1`になると、このステータスは変更されなくなります。 - `PROGRESS`レプリケーションの進行状況を表します。値は0.0～1.0の範囲です。1はTiFlashレプリカのレプリケーションの進行状況が完了したことを意味します。 ### ステップ5. HTAPを使用してデータをより速く分析する {#step-5-analyze-data-faster-using-htap} diff --git a/read-historical-data.md b/read-historical-data.md index e923f8acf34a9..2a8604eb220fa 100644 --- a/read-historical-data.md +++ b/read-historical-data.md @@ -22,7 +22,7 @@ TiDB は、特別なクライアントやドライバーを使用せずに、標 ## TiDBが履歴バージョンからデータを読み取る方法 {#how-tidb-reads-data-from-history-versions} -[`tidb_snapshot`](/system-variables.md#tidb_snapshot)のシステム変数は、履歴データの読み取りをサポートするために導入されました。3 `tidb_snapshot`の変数について： +[`tidb_snapshot`](/system-variables.md#tidb_snapshot)のシステム変数は、履歴データの読み取りをサポートするために導入されました。`tidb_snapshot`の変数について： - 変数は`SESSION`スコープ内で有効です。 - その値は`SET`ステートメントを使用して変更できます。 diff --git a/releases/release-2.1.17.md b/releases/release-2.1.17.md index 8f9396d8adea3..061db317d0e47 100644 --- a/releases/release-2.1.17.md +++ b/releases/release-2.1.17.md @@ -30,7 +30,7 @@ TiDB Ansible バージョン: 2.1.17 - SQLオプティマイザー - `EvalSubquery`ビルド`Executor` 中にエラーが発生したときにエラーメッセージが正しく返されない問題を修正 [＃11811](https://github.com/pingcap/tidb/pull/11811) - - インデックスルックアップ結合において、外部テーブルの行数が単一バッチの行数より多い場合にクエリ結果が正しくない可能性がある問題を修正しました。インデックスルックアップ結合の機能範囲を拡張しました。1 `UnionScan` `IndexJoin` のサブノードとして使用できます。 [＃11843](https://github.com/pingcap/tidb/pull/11843) + - インデックスルックアップ結合において、外部テーブルの行数が単一バッチの行数より多い場合にクエリ結果が正しくない可能性がある問題を修正しました。インデックスルックアップ結合の機能範囲を拡張しました。`UnionScan` `IndexJoin` のサブノードとして使用できます。 [＃11843](https://github.com/pingcap/tidb/pull/11843) - 統計フィードバック処理中に無効なキーが発生する可能性がある状況に備えて、 `SHOW STAT_BUCKETS`構文に無効なキー（ `invalid encoded key flag 252`など）の表示を追加します[＃12098](https://github.com/pingcap/tidb/pull/12098) - SQL実行エンジン - `CAST`関数が数値型を変換するときに最初に`UINT`に変換される数値によって発生するいくつかの誤った結果 ( `select cast(13835058000000000000 as double)`など) を修正しました。 [＃11712](https://github.com/pingcap/tidb/pull/11712) diff --git a/releases/release-2.1.19.md b/releases/release-2.1.19.md index 85565b7678af1..d6dcf5cd75c08 100644 --- a/releases/release-2.1.19.md +++ b/releases/release-2.1.19.md @@ -17,7 +17,7 @@ TiDB Ansible バージョン: 2.1.19 - `select max(_tidb_rowid) from t`のシナリオを最適化して、テーブル全体のスキャンを回避する[＃13294](https://github.com/pingcap/tidb/pull/13294) - クエリ内のユーザー変数に割り当てられた誤った値と述語のプッシュダウンによって発生する誤った結果を修正しました[＃13230](https://github.com/pingcap/tidb/pull/13230) - 統計情報の更新時にデータ競合が発生し、統計情報が正確でない問題を修正しました[＃13690](https://github.com/pingcap/tidb/pull/13690) - - `UPDATE`ステートメントにサブクエリとストアされた生成列の両方が含まれている場合に結果が正しくない問題を修正しました。3 `UPDATE`ステートメントに異なるデータベースの同じ名前のテーブルが 2 つ含まれている場合にステートメント実行エラーが発生する問題を修正しました[＃13357](https://github.com/pingcap/tidb/pull/13357) + - `UPDATE`ステートメントにサブクエリとストアされた生成列の両方が含まれている場合に結果が正しくない問題を修正しました。`UPDATE`ステートメントに異なるデータベースの同じ名前のテーブルが 2 つ含まれている場合にステートメント実行エラーが発生する問題を修正しました[＃13357](https://github.com/pingcap/tidb/pull/13357) - `PhysicalUnionScan`演算子が統計誤って設定するため、クエリ プランが誤って選択される可能性がある問題を修正しました。 [＃14134](https://github.com/pingcap/tidb/pull/14134) - `minAutoAnalyzeRatio`制約を取り除き、自動`ANALYZE`をよりタイムリーにする [＃14013](https://github.com/pingcap/tidb/pull/14013) - `WHERE`句に一意キー等号条件が含まれている場合に推定行数が`1`より大きくなる問題を修正しました。 [＃13385](https://github.com/pingcap/tidb/pull/13385) diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index 1caca0bfca048..61ec7fd26e14d 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -23,7 +23,7 @@ TiDB Ansible バージョン: 3.0.0 ## TiDB {#tidb} - 新機能 - - ウィンドウ関数`NTH_VALUE` `RANK` 。1、3、5、7、9、11、13、15、17、19、21 `LEAD`含むMySQL 8.0 `NTILE`すべての`CUME_DIST`関数`ROW_NUMBER` `LAST_VALUE` `FIRST_VALUE` `PERCENT_RANK`あり`DENSE_RANK` `LAG` + - ウィンドウ関数をサポート。`NTILE` 、 `LEAD` 、 `LAG` 、 `PERCENT_RANK` 、 `NTH_VALUE` 、 `CUME_DIST` 、 `FIRST_VALUE` 、 `LAST_VALUE` 、 `RANK` 、 `DENSE_RANK` 、 `ROW_NUMBER`を含む、MySQL 8.0のすべてのウィンドウ関数と互換性があります - ビューのサポート（**Experimental**） - テーブルパーティションの改善 - サポート範囲パーティション @@ -54,7 +54,7 @@ TiDB Ansible バージョン: 3.0.0 - ログ出力を最適化: `EXECUTE`ユーザー変数を出力し、 `COMMIT`トラブルシューティングを容易にするためにスロークエリログを出力します。 - SQLチューニングの使いやすさを向上させる`EXPLAIN ANALYZE`機能をサポート - 次の行のIDを取得するための`admin show next_row_id`コマンドをサポートします - - 6 `NAME_CONST` `JSON_ARRAY_APPEND`組み込み関数`BENCHMARK`追加し`COALESCE` `JSON_MERGE_PRESERVE` `JSON_QUOTE` + - `JSON_QUOTE` 、 `JSON_ARRAY_APPEND` 、 `JSON_MERGE_PRESERVE` 、 `BENCHMARK` 、 `COALESCE` 、 `NAME_CONST`の6つの組み込み関数を追加 - チャンクサイズの制御ロジックを最適化し、クエリコンテキストに基づいて動的に調整することで、SQL実行時間とリソース消費を削減します。 - 3つの演算子（ `TableReader` `IndexLookupReader`でメモリ使用量の追跡と制御をサポートします`IndexReader` - 空の`ON`条件をサポートするように Merge Join 演算子を最適化します。 diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index d3bb7ea323b64..5b39afa20d9aa 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -31,7 +31,7 @@ TiDB Ansible バージョン: 3.0.2 - INDEX JOIN がプレフィックスインデックスを使用すると結果が間違ってしまう可能性がある問題を修正しました [＃11246](https://github.com/pingcap/tidb/pull/11246) - `DATE_ADD`関数がマイクロ秒を含む日付数値の減算を行う際に分数の配置が誤っているために結果が間違っている可能性がある問題を修正しました[＃11288](https://github.com/pingcap/tidb/pull/11288) - `DATE_ADD`関数が`INTERVAL` の負の数を誤って処理することによって発生する誤った結果を修正しました。 [＃11325](https://github.com/pingcap/tidb/pull/11325) - - `Mod(%)` `Mod(%)` 0 を返し、 `Minus(-)`以下の桁数が大きい場合 ( `select 0.000 % 0.11234500000000000000`など)、 `Multiple(*)` `Minus(-)`返す小数点以下の桁数`Multiple(*)` MySQL と異なる問題を修正しました[＃11251](https://github.com/pingcap/tidb/pull/11251) + - `Mod(%)` 、 `Multiple(*)` 、または`Minus(-)`が 0 を返し、小数点以下の桁数が大きい場合 ( `select 0.000 % 0.11234500000000000000`など)、 `Mod(%)` 、 `Multiple(*)` 、または`Minus(-)`が返す小数点以下の桁数が MySQL と異なる問題を修正しました[＃11251](https://github.com/pingcap/tidb/pull/11251) - `CONCAT`と`CONCAT_WS`関数によって返される結果の長さが`max_allowed_packet`超えると、警告付きの`NULL`が誤って返される問題を修正しました[＃11275](https://github.com/pingcap/tidb/pull/11275) - `SUBTIME`と`ADDTIME`関数のパラメータが無効な場合に警告付きの`NULL`が誤って返される問題を修正しました[＃11337](https://github.com/pingcap/tidb/pull/11337) - `CONVERT_TZ`関数のパラメータが無効な場合に`NULL`が誤って返される問題を修正しました[＃11359](https://github.com/pingcap/tidb/pull/11359) @@ -44,7 +44,7 @@ TiDB Ansible バージョン: 3.0.2 - `DATE_ADD`と`DATE_SUB`関数の結果が超える場合に`NULL`返されない場合がある問題を修正しました。 [＃11476](https://github.com/pingcap/tidb/pull/11476) - 長い文字列を整数に変換するときに、文字列に無効な文字が含まれているとMySQLの変換結果と異なる問題を修正しました。 [＃11469](https://github.com/pingcap/tidb/pull/11469) - この関数大文字と小文字の区別により、関数`REGEXP BINARY`の結果がMySQLと互換性がない問題を修正しました。 [＃11504](https://github.com/pingcap/tidb/pull/11504) - - `GRANT ROLE`文が`CURRENT_ROLE`受け取ったときにエラーが報告される問題を修正します。5 `REVOKE ROLE`が`mysql.default_role`権限を正しく取り消さない問題を修正します。 [＃11356](https://github.com/pingcap/tidb/pull/11356) + - `GRANT ROLE`文が`CURRENT_ROLE`受け取ったときにエラーが報告される問題を修正します。`REVOKE ROLE`が`mysql.default_role`権限を正しく取り消さない問題を修正します。 [＃11356](https://github.com/pingcap/tidb/pull/11356) - `SELECT ADDDATE('2008-01-34', -1)` のような文を実行する際の`Incorrect datetime value`警告情報の表示形式の問題を修正しました [＃11447](https://github.com/pingcap/tidb/pull/11447) - JSONデータの浮動小数点フィールドを整数に変換するときに結果がオーバーフローすると、エラーメッセージが`constant … overflows bigint`ではなく`constant … overflows float`報告する問題を修正しました。 [＃11534](https://github.com/pingcap/tidb/pull/11534) - `DATE_ADD`関数が`FLOAT` 、 `DOUBLE` 、 `DECIMAL`列のパラメータを受け取ったときに、誤った型変換によって結果が間違ってしまう可能性がある問題を修正しました[＃11527](https://github.com/pingcap/tidb/pull/11527) diff --git a/releases/release-3.0.6.md b/releases/release-3.0.6.md index 39bfb49ea889b..8d0381f5d70c7 100644 --- a/releases/release-3.0.6.md +++ b/releases/release-3.0.6.md @@ -19,7 +19,7 @@ TiDB Ansible バージョン: 3.0.6 - SQLバインディングで引用符が正しく処理されない問題を修正 [＃13117](https://github.com/pingcap/tidb/pull/13117) - `select max(_tidb_rowid) from t`シナリオを最適化してテーブル全体のスキャンを回避する[＃13095](https://github.com/pingcap/tidb/pull/13095) - クエリステートメントに変数代入式が含まれている場合にクエリ結果が正しくない問題を修正しました[＃13231](https://github.com/pingcap/tidb/pull/13231) - - `UPDATE`ステートメントにサブクエリと生成された列の両方が含まれている場合に結果が正しくない問題を修正しました。3 `UPDATE`ステートメントに異なるソース データベースからの同じ名前のテーブルが 2 つ含まれている場合に発生するステートメント実行エラーを修正しました[＃13350](https://github.com/pingcap/tidb/pull/13350) + - `UPDATE`ステートメントにサブクエリと生成された列の両方が含まれている場合に結果が正しくない問題を修正しました。`UPDATE`ステートメントに異なるソース データベースからの同じ名前のテーブルが 2 つ含まれている場合に発生するステートメント実行エラーを修正しました[＃13350](https://github.com/pingcap/tidb/pull/13350) - ポイントクエリのサポート`_tidb_rowid` [＃13416](https://github.com/pingcap/tidb/pull/13416) - パーティションテーブル統計の不適切な使用により、生成されたクエリ実行プランが正しくない問題を修正しました[＃13628](https://github.com/pingcap/tidb/pull/13628) - SQL実行エンジン diff --git a/releases/release-3.0.9.md b/releases/release-3.0.9.md index cb6f5fbe679e6..787d4aa2d1738 100644 --- a/releases/release-3.0.9.md +++ b/releases/release-3.0.9.md @@ -30,7 +30,7 @@ TiDB Ansible バージョン: 3.0.9 - `primary`列に`alter table ... add index`を使用して作成された匿名インデックスの結果がMySQL と一致しない問題を修正しました [＃14310](https://github.com/pingcap/tidb/pull/14310) - `drop table`構文で`VIEW`が誤って削除される問題を修正[＃14052](https://github.com/pingcap/tidb/pull/14052) - プランナー - - `select max(a), min(a) from t`のような文のパフォーマンスを最適化します。3 `a`にインデックスが存在する場合、文は`select * from (select a from t order by a desc limit 1) as t1, (select a from t order by a limit 1) as t2`に最適化され、フルテーブルスキャンを回避します。 [＃14410](https://github.com/pingcap/tidb/pull/14410) + - `select max(a), min(a) from t`のような文のパフォーマンスを最適化します。`a`にインデックスが存在する場合、文は`select * from (select a from t order by a desc limit 1) as t1, (select a from t order by a limit 1) as t2`に最適化され、フルテーブルスキャンを回避します。 [＃14410](https://github.com/pingcap/tidb/pull/14410) ## TiKV {#tikv} diff --git a/releases/release-4.0.0-beta.md b/releases/release-4.0.0-beta.md index df90ee9292fbf..817b030717aca 100644 --- a/releases/release-4.0.0-beta.md +++ b/releases/release-4.0.0-beta.md @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 4.0.0-beta ## TiDB {#tidb} -- `INSERT` / `REPLACE` / `DELETE` / `UPDATE`の実行中に使用されたメモリが[＃14289](https://github.com/pingcap/tidb/pull/14289) `MemQuotaQuery`項目で指定された制限を超えた場合、ログを出力するか、SQL 実行をキャンセルします。実際の動作は`OOMAction`設定に依存します。13 [＃14179](https://github.com/pingcap/tidb/pull/14179) [＃14299](https://github.com/pingcap/tidb/pull/14299) +- `INSERT` / `REPLACE` / `DELETE` / `UPDATE`の実行中に使用されたメモリが`MemQuotaQuery`設定項目で指定された制限を超えた場合、ログを出力するか、SQL 実行をキャンセルします。実際の動作は`OOMAction`設定に依存します。 [＃14179](https://github.com/pingcap/tidb/pull/14179) [＃14289](https://github.com/pingcap/tidb/pull/14289) [＃14299](https://github.com/pingcap/tidb/pull/14299) - 駆動テーブルと被駆動テーブルの両方の行数を考慮して、 `Index Join`のコスト計算の精度を高めます。 [＃12085](https://github.com/pingcap/tidb/pull/12085) - オプティマイザの動作を制御し、オプティマイザをより安定させるために 15 個の SQL ヒントを追加します。 - [＃11253](https://github.com/pingcap/tidb/pull/11253) [＃11364](https://github.com/pingcap/tidb/pull/11364) [＃11673](https://github.com/pingcap/tidb/pull/11673) [＃11740](https://github.com/pingcap/tidb/pull/11740) [＃11746](https://github.com/pingcap/tidb/pull/11746) diff --git a/releases/release-4.0.0-rc.1.md b/releases/release-4.0.0-rc.1.md index 40f315676641c..f0a454d66eac1 100644 --- a/releases/release-4.0.0-rc.1.md +++ b/releases/release-4.0.0-rc.1.md @@ -117,7 +117,7 @@ TiDB バージョン: 4.0.0-rc.1 - `show create table`文のデフォルトシーケンス値の誤った表示を修正 [＃16526](https://github.com/pingcap/tidb/pull/16526) - シーケンスが主キーのデフォルト値として使用されるために`not-null`エラーが返される問題を修正しました [＃16510](https://github.com/pingcap/tidb/pull/16510) - TiKVが`StaleCommand`エラーを返し続けているときに、ブロックされたSQL実行に対してエラーが報告されない問題を修正しました。 [＃16530](https://github.com/pingcap/tidb/pull/16530) -- データベースの作成時に`COLLATE`を指定するとエラーが報告される問題を修正しました。5 `SHOW CREATE DATABASE`の結果に不足している`COLLATE`部分を追加します[＃16540](https://github.com/pingcap/tidb/pull/16540) +- データベースの作成時に`COLLATE`を指定するとエラーが報告される問題を修正しました。`SHOW CREATE DATABASE`の結果に不足している`COLLATE`部分を追加します[＃16540](https://github.com/pingcap/tidb/pull/16540) - プランキャッシュが有効な場合のパーティションプルーニングの失敗を修正[＃16723](https://github.com/pingcap/tidb/pull/16723) - オーバーフロー処理時に誤った結果を返すバグ`PointGet`修正 [＃16755](https://github.com/pingcap/tidb/pull/16755) - 同じ時間値を持つ`slow_query`システムテーブルをクエリすると間違った結果が返される問題を修正しました[＃16806](https://github.com/pingcap/tidb/pull/16806) diff --git a/releases/release-4.0.15.md b/releases/release-4.0.15.md index fa1cfafab23f0..c5225c147cf0a 100644 --- a/releases/release-4.0.15.md +++ b/releases/release-4.0.15.md @@ -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`を使用します。これは、`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-5.2.4.md b/releases/release-5.2.4.md index 24f8472d80384..72fd1f45b539e 100644 --- a/releases/release-5.2.4.md +++ b/releases/release-5.2.4.md @@ -65,7 +65,7 @@ TiDBバージョン：5.2.4 - ウィンドウ関数がトランザクションを使用する場合と使用しない場合で異なる結果を返す可能性がある問題を修正しました [#29947](https://github.com/pingcap/tidb/issues/29947) - SQL文に自然結合が含まれている場合に`Column 'col_name' in field list is ambiguous`エラーが予期せず報告される問題を修正しました [#25041](https://github.com/pingcap/tidb/issues/25041) - `Decimal`を`String`にキャストする際に長さ情報が間違っている問題を修正しました [#29417](https://github.com/pingcap/tidb/issues/29417) - - `GREATEST`関数が`tidb_enable_vectorized_expression`の値が異なる場合（{{B-PLACEHOLDER-2- `on`または`off` 。 [#29434](https://github.com/pingcap/tidb/issues/29434) + - `GREATEST`関数が`tidb_enable_vectorized_expression`の値が異なる場合（`on`または`off`に設定）に一貫性のない結果を返す問題を修正しました [#29434](https://github.com/pingcap/tidb/issues/29434) - `left join`を使用して複数のテーブルのデータを削除する際の誤った結果を修正 [#31321](https://github.com/pingcap/tidb/issues/31321) - TiDBがTiFlashに重複したタスクをディスパッチする可能性があるバグを修正しました [#32814](https://github.com/pingcap/tidb/issues/32814) - クエリ実行時に発生するMPPタスクリストの空エラーを修正する [#31636](https://github.com/pingcap/tidb/issues/31636) diff --git a/releases/release-5.3.2.md b/releases/release-5.3.2.md index ee8a3a0f792f2..589afa2aca317 100644 --- a/releases/release-5.3.2.md +++ b/releases/release-5.3.2.md @@ -11,7 +11,7 @@ TiDB バージョン: 5.3.2 > **Warning:** > -> v5.3.2 には既知のバグがあるため、使用は推奨されません。詳細はご覧ください。このバグは v5.3.3 で修正されています。3 [バージョン5.3.3](/releases/release-5.3.3.md)使用を推奨します。 [＃12934](https://github.com/tikv/tikv/issues/12934) +> v5.3.2 には既知のバグがあるため、使用は推奨されません。詳細は [＃12934](https://github.com/tikv/tikv/issues/12934) をご覧ください。このバグは v5.3.3 で修正されています。 [バージョン5.3.3](/releases/release-5.3.3.md)の使用を推奨します。 ## 互換性の変更 {#compatibility-changes} diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md index dbbac0b13534e..68f2216d5531e 100644 --- a/releases/release-6.1.1.md +++ b/releases/release-6.1.1.md @@ -33,7 +33,7 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - `blackbox_exporter-{version}-linux-amd64.tar.gz` - `node_exporter-{version}-linux-amd64.tar.gz` -- オペレーティングシステムとCPUアーキテクチャの組み合わせに応じて、異なる品質基準に対する多層的なサポートを導入します。1 [OSおよびプラットフォームの要件](https://docs-archive.pingcap.com/tidb/v6.1/hardware-and-software-requirements#os-and-platform-requirements)参照してください。 +- オペレーティングシステムとCPUアーキテクチャの組み合わせに応じて、異なる品質基準に対する多層的なサポートを導入します。[OSおよびプラットフォームの要件](https://docs-archive.pingcap.com/tidb/v6.1/hardware-and-software-requirements#os-and-platform-requirements)を参照してください。 ## 改善点 {#improvements} diff --git a/releases/release-6.1.6.md b/releases/release-6.1.6.md index 1b91b76df9114..30429cb521f9e 100644 --- a/releases/release-6.1.6.md +++ b/releases/release-6.1.6.md @@ -74,7 +74,7 @@ TiDB バージョン: 6.1.6 - 直交積[＃6730](https://github.com/pingcap/tiflash/issues/6730) @ [gengliqi](https://github.com/gengliqi)を計算するときにセミ結合が過剰なメモリを使用する問題を修正しました - TiFlashログ検索が遅すぎる問題を修正[＃6829](https://github.com/pingcap/tiflash/issues/6829) @ [hehechen](https://github.com/hehechen) - 新しい照合順序[＃6807](https://github.com/pingcap/tiflash/issues/6807) @ [xzhangxian1008](https://github.com/xzhangxian1008)を有効にした後に TopN/Sort 演算子が誤った結果を生成する問題を修正しました - - 特定のケースで[＃6994](https://github.com/pingcap/tiflash/issues/6994) @ [windtalker](https://github.com/windtalker) 10 進キャストが誤って切り上げられる問題を修正しました + - 特定のケースで 10 進キャストが誤って切り上げられる問題を修正しました [＃6994](https://github.com/pingcap/tiflash/issues/6994) @ [windtalker](https://github.com/windtalker) - TiFlashが生成された列[＃6801](https://github.com/pingcap/tiflash/issues/6801) @ [guo-shaoge](https://github.com/guo-shaoge)を認識できない問題を修正 - 特定のケースで小数点以下の桁が切り上げられない問題を修正[＃7022](https://github.com/pingcap/tiflash/issues/7022) @ [LittleFall](https://github.com/LittleFall) diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 2b09650ce5193..b3c6cba654a37 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -45,7 +45,7 @@ TiDBバージョン: 6.4.0-DMR - `FLASHBACK CLUSTER TO TIMESTAMP`を使用した特定の時点へのクラスターの復元のサポート (実験的) [#37197](https://github.com/pingcap/tidb/issues/37197) [#13303](https://github.com/tikv/tikv/issues/13303) @[Defined2014](https://github.com/Defined2014) @[bb7133](https://github.com/bb7133) @[JmPotato](https://github.com/JmPotato) @[Connor1996](https://github.com/Connor1996) @[HuSharp](https://github.com/HuSharp) @[CalvinNeo](https://github.com/CalvinNeo) - `FLASHBACK CLUSTER TO TIMESTAMP`構文を使用すると、ガベージコレクション（GC）の有効期間内に、クラスタを特定の時点に迅速に復元できます。この機能は、DML操作の誤りを簡単かつ迅速に取り消すのに役立ちます。たとえば、{{B-PLACEHOLDER-2-PLACEHOLDER-E} `WHERE`句なしで誤って`DELETE`を実行した後、この構文を使用して数分で元のクラスタを復元できます。この機能はデータベースのバックアップに依存せず、異なる時点のデータをロールバックして、データが変更された正確な時刻を特定できます。 `FLASHBACK CLUSTER TO TIMESTAMP`はデータベースのバックアップの代わりにはならないことに注意してください。 + `FLASHBACK CLUSTER TO TIMESTAMP`構文を使用すると、ガベージコレクション（GC）の有効期間内に、クラスタを特定の時点に迅速に復元できます。この機能は、DML操作の誤りを簡単かつ迅速に取り消すのに役立ちます。たとえば、 `WHERE`句なしで誤って`DELETE`を実行した後、この構文を使用して数分で元のクラスタを復元できます。この機能はデータベースのバックアップに依存せず、異なる時点のデータをロールバックして、データが変更された正確な時刻を特定できます。 `FLASHBACK CLUSTER TO TIMESTAMP`はデータベースのバックアップの代わりにはならないことに注意してください。 `FLASHBACK CLUSTER TO TIMESTAMP`を実行する前に、TiCDC などのツールで実行されている PITR およびレプリケーション タスクを一時停止し、 `FLASHBACK`が完了した後に再開する必要があります。そうしないと、レプリケーション タスクが失敗する可能性があります。 @@ -340,7 +340,7 @@ TiDBバージョン: 6.4.0-DMR - TiKV - - Applyスレッドが1回のポーリングで1つの有限状態マシンに対して書き込める最大バイト数を制御し、Applyスレッドが大量のデータを書き込む際のRaftstoreの混雑を緩和するために、新しい設定項目`apply-yield-write-size` -0-PLACEHOLDER-E}}を追加します。 [#13313](https://github.com/tikv/tikv/issues/13313) @[glorv](https://github.com/glorv) + - Applyスレッドが1回のポーリングで1つの有限状態マシンに対して書き込める最大バイト数を制御し、Applyスレッドが大量のデータを書き込む際のRaftstoreの混雑を緩和するために、新しい設定項目`apply-yield-write-size`を追加します。 [#13313](https://github.com/tikv/tikv/issues/13313) @[glorv](https://github.com/glorv) - リージョンのリーダーを移行する前にエントリキャッシュをウォームアップして、リーダー転送プロセス中のQPSジッターを回避する [#13060](https://github.com/tikv/tikv/issues/13060) @[cosven](https://github.com/cosven) - `json_constrains`演算子をコプロセッサーにプッシュダウンするサポート [#13592](https://github.com/tikv/tikv/issues/13592) @[lizhenhuan](https://github.com/lizhenhuan) - `CausalTsProvider`に非同期関数を追加して、一部のシナリオでのフラッシュパフォーマンスを改善します [#13428](https://github.com/tikv/tikv/issues/13428) @[zeminzhou](https://github.com/zeminzhou) diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index 8b3f8a7769dbf..d9230012bd26d 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -149,7 +149,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - [インデックスマージ](/glossary.md#index-merge)は、 `AND` で接続された式をサポートします [＃39333](https://github.com/pingcap/tidb/issues/39333) @ [guo-shaoge](https://github.com/guo-shaoge) @ [time-and-fate](https://github.com/time-and-fate) @ [hailanwhu](https://github.com/hailanwhu) - v6.5.0より前のTiDBでは、 `OR`で連結されたフィルタ条件に対してのみインデックスマージがサポートされていました。v6.5.0以降、TiDBは`WHERE`句の`AND`で連結されたフィルタ条件に対してもインデックスマージがサポートされるようになりました。これにより、TiDBのインデックスマージは、より一般的なクエリフィルタ条件の組み合わせをカバーできるようになり、union( `OR` )関係に限定されなくなりました。現在のv6.5.0バージョンでは、オプティマイザによって自動的に選択された`OR`の条件でのインデックスマージのみがサポートされています。11 `AND`条件でインデックスマージを有効にするには、 [`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)ヒントを使用する必要があります。 + v6.5.0より前のTiDBでは、 `OR`で連結されたフィルタ条件に対してのみインデックスマージがサポートされていました。v6.5.0以降、TiDBは`WHERE`句の`AND`で連結されたフィルタ条件に対してもインデックスマージがサポートされるようになりました。これにより、TiDBのインデックスマージは、より一般的なクエリフィルタ条件の組み合わせをカバーできるようになり、union( `OR` )関係に限定されなくなりました。現在のv6.5.0バージョンでは、オプティマイザによって自動的に選択された`OR`の条件でのインデックスマージのみがサポートされています。`AND`条件でインデックスマージを有効にするには、 [`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)ヒントを使用する必要があります。 インデックスマージの詳細については、 [v5.4.0 リリースノート](/releases/release-5.4.0.md#performance)と[インデックスのマージについて説明する](/explain-index-merge.md)参照してください。 @@ -179,7 +179,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - オプティマイザーはより正確なコストモデルバージョン2（GA） を導入しました [＃35240](https://github.com/pingcap/tidb/issues/35240) @ [qw4990](https://github.com/qw4990) - TiDB v6.2.0 では、 [コストモデル バージョン 2](/cost-model.md#cost-model-version-2)実験的機能として導入されました。このモデルは、より正確なコスト推定手法を用いて、オプティマイザーが最適な実行プランを選択できるように支援します。特にTiFlashを導入している場合、コストモデル バージョン 2 は適切なストレージエンジンを自動的に選択し、手動による介入を大幅に削減します。一定期間の実環境テストを経て、このモデルは v6.5.0 で一般提供となります。v6.5.0 以降、新規に作成されたクラスターはデフォルトでコストモデル バージョン 2 を使用します。v6.5.0 にアップグレードするクラスターでは、コストモデル バージョン 2 によってクエリプランが変更される可能性があるため、十分なパフォーマンステストを行った後、 [`tidb_cost_model_version = 2`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数を設定して新しいコストモデルを使用するように設定できます。 + TiDB v6.2.0 では、 [コストモデル バージョン 2](/cost-model.md#cost-model-version-2)が実験的機能として導入されました。このモデルは、より正確なコスト推定手法を用いて、オプティマイザーが最適な実行プランを選択できるように支援します。特にTiFlashを導入している場合、コストモデル バージョン 2 は適切なストレージエンジンを自動的に選択し、手動による介入を大幅に削減します。一定期間の実環境テストを経て、このモデルは v6.5.0 で一般提供となります。v6.5.0 以降、新規に作成されたクラスターはデフォルトでコストモデル バージョン 2 を使用します。v6.5.0 にアップグレードするクラスターでは、コストモデル バージョン 2 によってクエリプランが変更される可能性があるため、十分なパフォーマンステストを行った後、 [`tidb_cost_model_version = 2`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数を設定して新しいコストモデルを使用するように設定できます。 コスト モデル バージョン 2 は、TiDB オプティマイザーの全体的な機能を大幅に向上させ、TiDB をより強力な HTAP データベースへと進化させる、一般利用可能な機能になります。 @@ -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では、実行プランの出力形式が拡張されました。`EXPLAIN`に`FORMAT = "tidb_json"`を指定することで、SQL実行プランをJSON形式で出力できます。この機能により、SQLデバッグツールや診断ツールは実行プランをより便利かつ正確に読み取ることができるため、SQL診断やチューニングの利便性が向上します。 詳細については[ドキュメント](/sql-statements/sql-statement-explain.md)参照してください。 @@ -312,7 +312,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では | [`tidb_cost_model_version`](/system-variables.md#tidb_cost_model_version-new-in-v620) | 変更 | さらにテストを行った後、デフォルト値を`1`から`2`に変更します。つまり、インデックス選択と演算子選択には、デフォルトでコスト モデル バージョン 2 が使用されることになります。 | | [`tidb_enable_gc_aware_memory_track`](/system-variables.md#tidb_enable_gc_aware_memory_track) | 変更 | デフォルト値を`ON`から`OFF`に変更します。GC対応メモリトラックはテストで不正確であることが判明し、追跡されるメモリサイズが大きくなりすぎるため、メモリトラックは無効化されています。また、 Golang 1.19では、GC対応メモリトラックによって追跡されるメモリは、全体のメモリに大きな影響を与えません。 | | [`tidb_enable_metadata_lock`](/system-variables.md#tidb_enable_metadata_lock-new-in-v630) | 変更 | さらにテストを行った後、デフォルト値を`OFF`から`ON`に変更します。これは、メタデータ ロック機能がデフォルトで有効になっていることを意味します。 | -| [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 変更 | `DELETE` 6.5.0以降で有効になります。1、3、5 `INSERT` `UPDATE` SQL文の読み取り操作をTiFlashにプッシュダウンできるかどうかを制御します。デフォルト値は`OFF`です。 | +| [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 変更 | 6.5.0以降で有効になります。`INSERT` 、 `DELETE` 、 `UPDATE`を含むSQL文の読み取り操作をTiFlashにプッシュダウンできるかどうかを制御します。デフォルト値は`OFF`です。 | | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) | 変更 | さらにテストを行った後、デフォルト値を`OFF`から`ON`に変更します。つまり、 `ADD INDEX`と`CREATE INDEX`の加速はデフォルトで有効になります。 | | [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) | 変更 | TiDB v6.5.0より前のバージョンでは、この変数はクエリのメモリクォータのしきい値を設定するために使用されます。TiDB v6.5.0以降のバージョンでは、DMLステートメントのメモリをより正確に制御するために、この変数はセッションのメモリクォータのしきい値を設定するために使用されます。 | | [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40) | 変更 | v6.5.0 以降では、 TiDB ノード間の負荷分散を最適化するために、この変数が`closest-adaptive`に設定され、読み取り要求の推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)以上の場合、 `closest-adaptive`構成が有効になる TiDB ノードの数が各アベイラビリティーゾーンで制限されます。これは常に、 TiDB ノードが最も少ないアベイラビリティーゾーンの TiDB ノードの数と同じになり、その他の TiDB ノードは自動的にリーダーレプリカから読み取ります。 | @@ -331,7 +331,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では | [`tidb_ttl_delete_batch_size`](/system-variables.md#tidb_ttl_delete_batch_size-new-in-v650) | 新しく追加された | この変数は、TTL ジョブ内の単一`DELETE`トランザクションで削除できる行の最大数を設定するために使用されます。 | | [`tidb_ttl_delete_rate_limit`](/system-variables.md#tidb_ttl_delete_rate_limit-new-in-v650) | 新しく追加された | この変数は、TTLジョブにおいて単一ノードで1秒あたりに許可される`DELETE`ステートメントの最大数を制限するために使用されます。この変数を`0`に設定すると、制限は適用されません。 | | [`tidb_ttl_delete_worker_count`](/system-variables.md#tidb_ttl_delete_worker_count-new-in-v650) | 新しく追加された | この変数は、各 TiDB ノード上の TTL ジョブの最大同時実行数を設定するために使用されます。 | -| [`tidb_ttl_job_enable`](/system-variables.md#tidb_ttl_job_enable-new-in-v650) | 新しく追加された | この変数は、TTLジョブを有効にするかどうかを制御するために使用されます。1 `OFF`設定すると、TTL属性を持つすべてのテーブルで期限切れデータのクリーンアップが自動的に停止されます。 | +| [`tidb_ttl_job_enable`](/system-variables.md#tidb_ttl_job_enable-new-in-v650) | 新しく追加された | この変数は、TTLジョブを有効にするかどうかを制御するために使用されます。`OFF`設定すると、TTL属性を持つすべてのテーブルで期限切れデータのクリーンアップが自動的に停止されます。 | | `tidb_ttl_job_run_interval` | 新しく追加された | この変数は、バックグラウンドでのTTLジョブのスケジュール間隔を制御するために使用されます。例えば、現在の値が`1h0m0s`に設定されている場合、TTL属性を持つ各テーブルは、期限切れのデータを1時間ごとにクリーンアップします。 | | [`tidb_ttl_job_schedule_window_start_time`](/system-variables.md#tidb_ttl_job_schedule_window_start_time-new-in-v650) | 新しく追加された | この変数は、バックグラウンドで実行されるTTLジョブのスケジュールウィンドウの開始時刻を制御するために使用されます。この変数の値を変更する際は、ウィンドウが小さいと期限切れデータのクリーンアップが失敗する可能性があるので注意してください。 | | [`tidb_ttl_job_schedule_window_end_time`](/system-variables.md#tidb_ttl_job_schedule_window_end_time-new-in-v650) | 新しく追加された | この変数は、バックグラウンドで実行されるTTLジョブのスケジュールウィンドウの終了時刻を制御するために使用されます。この変数の値を変更する際は、ウィンドウが小さいと期限切れデータのクリーンアップが失敗する可能性があるので注意してください。 | diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index 1623cc73b807e..2304b30e1acb3 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -94,7 +94,7 @@ TiDB バージョン: 6.5.6 - PDリーダーの故障により1分間に`IMPORT INTO`タスクが失敗する問題を修正[＃48307](https://github.com/pingcap/tidb/issues/48307) @ [D3Hunter](https://github.com/D3Hunter) - 日付型フィールドにインデックスを作成することによって発生する`ADMIN CHECK`の失敗の問題を修正しました [＃47426](https://github.com/pingcap/tidb/issues/47426) @ [tangenta](https://github.com/tangenta) - `TABLESAMPLE` によって返されるソートされていない行データの問題を修正しました [＃48253](https://github.com/pingcap/tidb/issues/48253) @ [tangenta](https://github.com/tangenta) - - DDL `jobID` 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) + - DDL `jobID`が 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) - TiKV diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md index e8630c6467a1d..c945b43befee4 100644 --- a/releases/release-6.6.0.md +++ b/releases/release-6.6.0.md @@ -320,7 +320,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone | [`mpp_version`](/system-variables.md#mpp_version-new-in-v660) | 新しく追加された | この変数は、MPP実行プランのバージョンを指定します。バージョンを指定すると、TiDBは指定されたバージョンのMPP実行プランを選択します。デフォルト値`UNSPECIFIED` 、TiDBが最新バージョン`1`自動的に選択することを意味します。 | | [`tidb_ddl_distribute_reorg`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660) | 新しく追加された | この変数は、DDL 再編成フェーズの分散実行を有効にしてこのフェーズを高速化するかどうかを制御します。デフォルト値`OFF`は、デフォルトでは DDL 再編成フェーズの分散実行を有効にしないことを意味します。現在、この変数は`ADD INDEX`に対してのみ有効です。 | | [`tidb_enable_historical_stats_for_capture`](/system-variables.md#tidb_enable_historical_stats_for_capture) | 新しく追加された | この変数は`PLAN REPLAYER CAPTURE`で取得される情報に、デフォルトで履歴統計が含まれるかどうかを制御します。デフォルト値の`OFF`は、デフォルトでは履歴統計が含まれないことを意味します。 | -| [`tidb_enable_plan_cache_for_param_limit`](/system-variables.md#tidb_enable_plan_cache_for_param_limit-new-in-v660) | 新しく追加された | この変数は`COUNT` `Limit` 0-PLACEHOLDER-E}} が含まれる実行プランをプリペアドプランキャッシュがキャッシュするかどうかを制御します。デフォルト値は`ON`で、これはプリペアドプランキャッシュ がそのような実行プランのキャッシュをサポートすることを意味します。ただし、 プリペアドプランキャッシュ は、 10000 を超える数値をカウントする`COUNT`条件を含む実行プランのキャッシュをサポートしていないことに注意してください。 | +| [`tidb_enable_plan_cache_for_param_limit`](/system-variables.md#tidb_enable_plan_cache_for_param_limit-new-in-v660) | 新しく追加された | この変数は`Limit`の後に`COUNT`が含まれる実行プランをプリペアドプランキャッシュがキャッシュするかどうかを制御します。デフォルト値は`ON`で、これはプリペアドプランキャッシュ がそのような実行プランのキャッシュをサポートすることを意味します。ただし、 プリペアドプランキャッシュ は、 10000 を超える数値をカウントする`COUNT`条件を含む実行プランのキャッシュをサポートしていないことに注意してください。 | | [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) | 新しく追加された | この変数は、リソース制御機能を有効にするかどうかを制御します。デフォルト値は`OFF`です。この変数を`ON`に設定すると、TiDB クラスタはリソース グループに基づいたアプリケーションのリソース分離をサポートします。 | | [`tidb_historical_stats_duration`](/system-variables.md#tidb_historical_stats_duration-new-in-v660) | 新しく追加された | この変数は、過去の統計情報をストレージに保存する期間を制御します。デフォルト値は7日間です。 | | [`tidb_index_join_double_read_penalty_cost_rate`](/system-variables.md#tidb_index_join_double_read_penalty_cost_rate-new-in-v660) | 新しく追加された | この変数は、インデックス結合の選択にペナルティコストを追加するかどうかを制御します。デフォルト値`0`は、この機能がデフォルトで無効になっていることを意味します。 | diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index c25695619571a..35570c1bbcb0c 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -200,8 +200,8 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - デフォルト設定では[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)がサポートされているため、 TiDB Cloud Starterへの接続が容易になります。 - TiDBのバージョンを識別して、外部キーのタブを表示または非表示にする機能をサポートしています。 - `EXPLAIN`結果に SQL 実行プランを視覚化することをサポートします。 - - `PESSIMISTIC` 、 `OPTIMISTIC` 、 `AUTO_RANDOM` 、 `PLACEMENT` 、 {{B-PLACEHOLDER `POLICY` 、 `REORGANIZE` 、 `EXCHANGE` 、 `CACHE` `NONCLUSTERED` } 、 `CLUSTERED`などの TiDB キーワードの強調表示をサポートします。 - - `TIDB_BOUNDED_STALENESS` 、 `TIDB_DECODE_KEY` 、 `TIDB_DECODE_PLAN` 、 `TIDB_IS_DDL_OWNER` 、{{B-PLACEHOLDER `TIDB_PARSE_TSO` 、 `TIDB_VERSION` `TIDB_DECODE_SQL_DIGESTS` }}、 `TIDB_SHARD`などのTiDB関数の強調表示をサポートします。 + - `PESSIMISTIC` 、 `OPTIMISTIC` 、 `AUTO_RANDOM` 、 `PLACEMENT` 、 `POLICY` 、 `REORGANIZE` 、 `EXCHANGE` 、 `CACHE` 、 `NONCLUSTERED` 、 `CLUSTERED`などの TiDB キーワードの強調表示をサポートします。 + - `TIDB_BOUNDED_STALENESS` 、 `TIDB_DECODE_KEY` 、 `TIDB_DECODE_PLAN` 、 `TIDB_IS_DDL_OWNER` 、 `TIDB_PARSE_TSO` 、 `TIDB_VERSION` 、 `TIDB_DECODE_SQL_DIGESTS` 、 `TIDB_SHARD`などのTiDB関数の強調表示をサポートします。 詳細については、 [DBeaverのドキュメント](https://github.com/dbeaver/dbeaver/wiki)を参照してください。 diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index 3c2b04e9a4ccc..ee8aa85295b9e 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -29,7 +29,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 現在、この機能は実験的であり、本番環境での使用は推奨されません。このエンジンは新規に作成されたクラスターでのみ使用でき、元のTiKVストレージエンジンから直接アップグレードすることはできません。 - 詳細については[ドキュメント](/partitioned-raft-kv.md)参照してください。 + 詳細については[ドキュメント](/partitioned-raft-kv.md)を参照してください。 - TiFlashは遅延マテリアライゼーション（GA） をサポートします [＃5829](https://github.com/pingcap/tiflash/issues/5829) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) @@ -37,7 +37,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 バージョン7.1.0以降、 TiFlashの遅延マテリアライゼーション機能が一般提供され、デフォルトで有効化されています（システム変数[`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700)はデフォルトで`ON`に設定されています）。TiDBオプティマイザーは、クエリの統計情報とフィルター条件に基づいて、TableScan演算子にプッシュダウンするフィルターを決定します。 - 詳細については[ドキュメント](/tiflash/tiflash-late-materialization.md)参照してください。 + 詳細については[ドキュメント](/tiflash/tiflash-late-materialization.md)を参照してください。 - TiFlashは、ネットワーク伝送のオーバーヘッドに応じてMPP Joinアルゴリズムを自動的に選択することをサポートしています[＃7084](https://github.com/pingcap/tiflash/issues/7084) @ [solotzg](https://github.com/solotzg) @@ -45,13 +45,13 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 v7.1.0 では、TiDB に[`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-new-in-v710)変数が導入されました。この変数は、ネットワーク伝送の最小オーバーヘッドに基づいて MPP Join アルゴリズムを選択するかどうかを制御し、この変数はデフォルトで無効になっています。この変数を`ON`に設定すると、デフォルトのアルゴリズム選択方法が v7.1.0 以前と同じままであることを示します。この変数を有効にすると、 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50)と[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50)変数を手動で調整する必要がなくなります（この時点では両方の変数は有効になりません）。TiDB は、異なる Join アルゴリズムによるネットワーク伝送のしきい値を自動的に推定し、全体的なオーバーヘッドが最小のアルゴリズムを選択します。これにより、ネットワークトラフィックが削減され、MPP クエリのパフォーマンスが向上します。 - 詳細については[ドキュメント](/tiflash/use-tiflash-mpp-mode.md#algorithm-support-for-the-mpp-mode)参照してください。 + 詳細については[ドキュメント](/tiflash/use-tiflash-mpp-mode.md#algorithm-support-for-the-mpp-mode)を参照してください。 - 読み取りホットスポットを軽減するために負荷ベースのレプリカ読み取りをサポートする[＃14151](https://github.com/tikv/tikv/issues/14151) @ [sticnarf](https://github.com/sticnarf) @ [you06](https://github.com/you06) 読み取りホットスポットが発生すると、ホットスポット TiKV ノードは読み取り要求を時間内に処理できず、読み取り要求がキューイングされます。ただし、この時点ですべての TiKV リソースが使い果たされるわけではありません。レイテンシーを短縮するために、TiDB v7.1.0 では負荷ベースのレプリカ読み取り機能が導入されました。この機能により、TiDB はホットスポット TiKV ノードでキューイングすることなく、他の TiKV ノードからデータを読み取ることができます。読み取り要求のキューの長さは、 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700)システム変数を使用して制御できます。リーダーノードの推定キュー時間がこのしきい値を超えると、TiDB はフォロワーノードからのデータの読み取りを優先します。この機能により、読み取りホットスポットが発生すると、読み取りホットスポットを分散させない場合と比較して、読み取りスループットが 70% ～ 200% 向上します。 - 詳細については[ドキュメント](/troubleshoot-hot-spot-issues.md#scatter-read-hotspots)参照してください。 + 詳細については[ドキュメント](/troubleshoot-hot-spot-issues.md#scatter-read-hotspots)を参照してください。 - 非プリペアドステートメントの実行プランをキャッシュする機能の強化（実験的） [＃36598](https://github.com/pingcap/tidb/issues/36598) @ [qw4990](https://github.com/qw4990) @@ -63,7 +63,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 非プリペアドプランキャッシュは、デフォルトではDML文をサポートしません。この制限を解除するには、システム変数[`tidb_enable_non_prepared_plan_cache_for_dml`](/system-variables.md#tidb_enable_non_prepared_plan_cache_for_dml-new-in-v710)を`ON`に設定してください。 - 詳細については[ドキュメント](/sql-non-prepared-plan-cache.md)参照してください。 + 詳細については[ドキュメント](/sql-non-prepared-plan-cache.md)を参照してください。 - TiDB 分散実行フレームワーク (DXF) のサポート (実験的) [＃41495](https://github.com/pingcap/tidb/issues/41495) @ [benjamin2037](https://github.com/benjamin2037) @@ -75,7 +75,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 SET GLOBAL tidb_enable_dist_task = ON; ``` - 詳細については[ドキュメント](/tidb-distributed-execution-framework.md)参照してください。 + 詳細については[ドキュメント](/tidb-distributed-execution-framework.md)を参照してください。 ### 信頼性 {#reliability} @@ -89,13 +89,13 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 ユーザーエクスペリエンスを向上させるために、TiDB Dashboardは[リソースマネージャーページ](/dashboard/dashboard-resource-manager.md)を提供します。このページでは、リソースグループの構成を表示し、クラスターの容量を視覚的に見積もることができるため、適切なリソース割り当てが容易になります。 - 詳細については[ドキュメント](/tidb-resource-control-ru-groups.md)参照してください。 + 詳細については[ドキュメント](/tidb-resource-control-ru-groups.md)を参照してください。 - フォールトトレランスと自動リカバリ機能を向上させるために、高速オンラインDDLのチェックポイントメカニズムをサポートします[＃42164](https://github.com/pingcap/tidb/issues/42164) @ [tangenta](https://github.com/tangenta) TiDB v7.1.0では、 [高速オンラインDDL](/best-practices/ddl-introduction.md)のチェックポイント機構が導入され、Fast Online DDLのフォールトトレランスと自動リカバリ機能が大幅に向上しました。障害によりTiDBオーナーノードが再起動または変更された場合でも、TiDBは定期的に自動更新されるチェックポイントから進捗状況をリカバリできるため、DDL実行の安定性と効率性が向上します。 - 詳細については[ドキュメント](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)参照してください。 + 詳細については[ドキュメント](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)を参照してください。 - バックアップと復元はチェックポイント復元をサポートします [＃42339](https://github.com/pingcap/tidb/issues/42339) @ [Leavrth](https://github.com/Leavrth) @@ -103,7 +103,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイント・リストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。 - 詳細については[ドキュメント](/br/br-checkpoint-restore.md)参照してください。 + 詳細については[ドキュメント](/br/br-checkpoint-restore.md)を参照してください。 - 統計のロード戦略を最適化する [＃42160](https://github.com/pingcap/tidb/issues/42160) @ [xuyifangreeneyes](https://github.com/xuyifangreeneyes) @@ -111,19 +111,19 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 TiDBの起動時、初期統計情報が完全にロードされる前に実行されるSQL文は、最適ではない実行プランを持つ可能性があり、パフォーマンスの問題を引き起こす可能性があります。このような問題を回避するために、TiDB v7.1.0では設定パラメータ[`force-init-stats`](/tidb-configuration-file.md#force-init-stats-new-in-v657-and-v710)が導入されました。このオプションを使用すると、起動時に統計情報の初期化が完了した後にのみTiDBがサービスを提供するかどうかを制御できます。このパラメータはデフォルトで無効になっています。 - 詳細については[ドキュメント](/statistics.md#load-statistics)参照してください。 + 詳細については[ドキュメント](/statistics.md#load-statistics)を参照してください。 - TiCDCは、単一行データのデータ整合性検証機能をサポートしています[＃8718](https://github.com/pingcap/tiflow/issues/8718) [＃42747](https://github.com/pingcap/tidb/issues/42747) @ [3AceShowHand](https://github.com/3AceShowHand) @ [zyguan](https://github.com/zyguan) v7.1.0以降、TiCDCはデータ整合性検証機能を導入しました。この機能は、チェックサムアルゴリズムを用いて単一行データの整合性を検証します。この機能は、TiDBからデータを書き込み、TiCDCを介してレプリケーションし、Kafkaクラスターに書き込むプロセスでエラーが発生していないかどうかを検証するのに役立ちます。データ整合性検証機能は、Kafkaをダウンストリームとして使用するチェンジフィードのみをサポートし、現在はAvroプロトコルをサポートしています。 - 詳細については[ドキュメント](/ticdc/ticdc-integrity-check.md)参照してください。 + 詳細については[ドキュメント](/ticdc/ticdc-integrity-check.md)を参照してください。 - TiCDCはDDLレプリケーション操作[＃8686](https://github.com/pingcap/tiflow/issues/8686) [ハイ・ラスティン](https://github.com/Rustin170506)で最適化します v7.1.0より前のバージョンでは、大規模なテーブルのすべての行に影響を与えるDDL操作（列の追加や削除など）を実行すると、TiCDCのレプリケーションレイテンシーが大幅に増加していました。v7.1.0以降、TiCDCはこのレプリケーション操作を最適化し、DDL操作が下流のレイテンシーに与える影響を軽減します。 - 詳細については[ドキュメント](/ticdc/ticdc-faq.md#does-ticdc-replicate-data-changes-caused-by-lossy-ddl-operations-to-the-downstream)参照してください。 + 詳細については[ドキュメント](/ticdc/ticdc-faq.md#does-ticdc-replicate-data-changes-caused-by-lossy-ddl-operations-to-the-downstream)を参照してください。 - TiB レベルのデータをインポートする際のTiDB Lightningの安定性を向上[＃43510](https://github.com/pingcap/tidb/issues/43510) [＃43657](https://github.com/pingcap/tidb/issues/43657) @ [D3Hunter](https://github.com/D3Hunter) @ [lance6716](https://github.com/lance6716) @@ -134,7 +134,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - `tikv-importer.region-check-backoff-limit` 、分割および分散処理後にリージョンがオンラインになるまでの再試行回数を制御します。デフォルト値は`1800`で、最大再試行間隔は 2 秒です。再試行の間にいずれかのリージョンがオンラインになった場合、再試行回数は増加しません。 - `tikv-importer.pause-pd-scheduler-scope` TiDB Lightning がPD スケジューリングを一時停止する範囲を制御します。値のオプションは`"table"`と`"global"`です。デフォルト値は`"table"`です。v6.1.0 より前のバージョンの TiDB では、データインポート中にグローバルスケジューリングを一時停止する`"global"`オプションのみを設定できます。v6.1.0 以降では、ターゲットテーブルデータが格納されているリージョンのスケジューリングのみを一時停止する`"table"`オプションがサポートされています。データ量が多いシナリオでは、安定性を向上させるために、この設定項目を`"global"`に設定することをお勧めします。 - 詳細については[ドキュメント](/tidb-lightning/tidb-lightning-configuration.md)参照してください。 + 詳細については[ドキュメント](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 ### SQL {#sql} @@ -142,9 +142,9 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 TiDB v6.5.0以降、 `INSERT INTO SELECT`ステートメントの`SELECT`の句（分析クエリ）をTiFlashにプッシュダウンできるようになりました。これにより、 TiFlashクエリの結果を`INSERT INTO`の句で指定されたTiDBテーブルに簡単に保存し、さらに分析することができます。これは、結果のキャッシュ（つまり、結果のマテリアライゼーション）として機能します。 - この機能はバージョン7.1.0で一般公開されています。3 `INSERT INTO SELECT`の`SELECT`句の実行中、オプティマイザーは、 [SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定できます。そのため、実験的段階で導入された`tidb_enable_tiflash_read_for_write_stmt`システム変数は非推奨となりました。TiFlashの`INSERT INTO SELECT`文の計算規則は`STRICT SQL Mode`要件を満たしていないため、TiDBは、現在のセッションの[SQLモード](/sql-mode.md)が厳密でない場合にのみ、 `INSERT INTO SELECT`文の`SELECT`句をTiFlashにプッシュダウンすることを許可します。つまり、 `sql_mode`値に`STRICT_TRANS_TABLES`と`STRICT_ALL_TABLES`が含まれません。 + この機能はバージョン7.1.0で一般公開されています。`INSERT INTO SELECT`の`SELECT`句の実行中、オプティマイザーは、 [SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定できます。そのため、実験的段階で導入された`tidb_enable_tiflash_read_for_write_stmt`システム変数は非推奨となりました。TiFlashの`INSERT INTO SELECT`文の計算規則は`STRICT SQL Mode`要件を満たしていないため、TiDBは、現在のセッションの[SQLモード](/sql-mode.md)が厳密でない場合にのみ、 `INSERT INTO SELECT`文の`SELECT`句をTiFlashにプッシュダウンすることを許可します。つまり、 `sql_mode`値に`STRICT_TRANS_TABLES`と`STRICT_ALL_TABLES`が含まれません。 - 詳細については[ドキュメント](/tiflash/tiflash-results-materialization.md)参照してください。 + 詳細については[ドキュメント](/tiflash/tiflash-results-materialization.md)を参照してください。 - MySQL互換の多値インデックスが一般提供（GA）される[＃39592](https://github.com/pingcap/tidb/issues/39592) @ [xiongjiwei](https://github.com/xiongjiwei) @ [qw4990](https://github.com/qw4990) @ [YangKeao](https://github.com/YangKeao) @@ -152,19 +152,19 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 バージョン7.1.0では、多値インデックス機能が一般提供（GA）されました。より包括的なデータ型をサポートし、TiDBツールとの互換性も備えています。多値インデックスを使用することで、本番環境におけるJSON配列の検索操作を高速化できます。 - 詳細については[ドキュメント](/sql-statements/sql-statement-create-index.md#multi-valued-indexes)参照してください。 + 詳細については[ドキュメント](/sql-statements/sql-statement-create-index.md#multi-valued-indexes)を参照してください。 - ハッシュおよびキーパーティションテーブルのパーティション管理を改善[＃42728](https://github.com/pingcap/tidb/issues/42728) @ [mjonss](https://github.com/mjonss) v7.1.0より前では、TiDBのハッシュおよびキーパーティションテーブルは、パーティション管理ステートメント`TRUNCATE PARTITION`をサポートしていました。v7.1.0以降では、ハッシュおよびキーパーティションテーブルは、パーティション管理ステートメント`ADD PARTITION`および`COALESCE PARTITION`もサポートするようになりました。そのため、必要に応じてハッシュおよびキーパーティションテーブルのパーティション数を柔軟に調整できます。例えば、パーティション管理ステートメント`ADD PARTITION`でパーティション数を増やしたり、パーティション管理ステートメント`COALESCE PARTITION`でパーティション数を減らしたりすることができます。 - 詳細については[ドキュメント](/partitioned-table.md#manage-hash-and-key-partitions)参照してください。 + 詳細については[ドキュメント](/partitioned-table.md#manage-hash-and-key-partitions)を参照してください。 - 範囲INTERVALパーティションの構文が一般公開（GA） になります [＃35683](https://github.com/pingcap/tidb/issues/35683) @ [mjonss](https://github.com/mjonss) バージョン6.3.0で導入されたRange INTERVALパーティショニングの構文がGAになりました。この構文を使用すると、すべてのパーティションを列挙することなく、任意の間隔でRangeパーティショニングを定義できるため、RangeパーティショニングのDDL文の長さが大幅に短縮されます。この構文は、従来のRangeパーティショニングの構文と同等です。 - 詳細については[ドキュメント](/partitioned-table.md#range-interval-partitioning)参照してください。 + 詳細については[ドキュメント](/partitioned-table.md#range-interval-partitioning)を参照してください。 - 生成された列は一般公開（GA）されます @[bb7133](https://github.com/bb7133) @@ -172,7 +172,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 生成列を使用すると、TiDBのMySQL互換性が向上し、MySQLからの移行プロセスが簡素化されます。また、データメンテナンスの複雑さが軽減され、データの一貫性とクエリ効率が向上します。 - 詳細については[ドキュメント](/generated-columns.md)参照してください。 + 詳細については[ドキュメント](/generated-columns.md)を参照してください。 ### DB操作 {#db-operations} @@ -182,7 +182,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 よりスムーズなアップグレードを実現するために、TiDB v7.1.0 では DDL タスクの自動一時停止と再開をサポートしています。v7.1.0 以降では、事前に DDL タスクを手動でキャンセルすることなく、クラスターをアップグレードできます。TiDB は、アップグレード前に実行中またはキューに登録されているユーザー DDL タスクを自動的に一時停止し、ローリングアップグレード後にこれらのタスクを再開します。これにより、TiDB クラスターのアップグレードが容易になります。 - 詳細については[ドキュメント](/smooth-upgrade-tidb.md)参照してください。 + 詳細については[ドキュメント](/smooth-upgrade-tidb.md)を参照してください。 ### 可観測性 {#observability} @@ -206,7 +206,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 v7.1.0 以降、TiDB は LDAP 認証をサポートし、 `authentication_ldap_sasl`と`authentication_ldap_simple` 2 つの認証プラグインを提供します。 - 詳細については[ドキュメント](/security-compatibility-with-mysql.md)参照してください。 + 詳細については[ドキュメント](/security-compatibility-with-mysql.md)を参照してください。 - データベース監査機能の強化（Enterprise Edition） @@ -236,22 +236,22 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - TiDB バージョン v6.2.0 から v7.0.0 のTiDB Lightning は、TiDB クラスターのバージョンに基づいてグローバル スケジューリングを一時停止するかどうかを決定します。TiDB クラスター バージョン >= v6.1.0 の場合、スケジュールはターゲット テーブル データを格納するリージョンに対してのみ一時停止され、ターゲット テーブルのインポートが完了すると再開されます。その他のバージョンの場合、 TiDB Lightning はグローバル スケジューリングを一時停止します。TiDB v7.1.0 以降では、 [`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md)設定することで、グローバル スケジューリングを一時停止するかどうかを制御できます。デフォルトでは、 TiDB Lightning はターゲット テーブル データを格納するリージョンのスケジュールを一時停止します。ターゲット クラスターのバージョンが v6.1.0 より前の場合、エラーが発生します。この場合、パラメータの値を`"global"`に変更して再試行できます。 -- TiDB v7.1.0で[`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)使用すると、FLASHBACK操作が完了した後も、一部のリージョンがFLASHBACKプロセスに残る可能性があります。v7.1.0ではこの機能の使用を避けることをお勧めします。詳細については、問題を参照してください。この問題が発生した場合は、機能[TiDBスナップショットのバックアップと復元](/br/br-snapshot-guide.md)を使用してデータを復元できます。 [＃44292](https://github.com/pingcap/tidb/issues/44292) +- TiDB v7.1.0で[`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)を使用すると、FLASHBACK操作が完了した後も、一部のリージョンがFLASHBACKプロセスに残る可能性があります。v7.1.0ではこの機能の使用を避けることをお勧めします。詳細については、問題を参照してください。この問題が発生した場合は、機能[TiDBスナップショットのバックアップと復元](/br/br-snapshot-guide.md)を使用してデータを復元できます。 [＃44292](https://github.com/pingcap/tidb/issues/44292) ### システム変数 {#system-variables} | 変数名 | タイプを変更 | 説明 | | --------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 非推奨 | デフォルト値を`OFF`から`ON`に変更します。 [`tidb_allow_mpp = ON`](/system-variables.md#tidb_allow_mpp-new-in-v50)の場合、オプティマイザーは[SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定します。 | -| [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。1 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)指定することで、キャッシュ可能なプランの最大数を制御できます。 | -| [`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-new-in-v610) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。1 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)指定することで、キャッシュ可能なプランの最大数を制御できます。 | +| [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を指定することで、キャッシュ可能なプランの最大数を制御できます。 | +| [`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-new-in-v610) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を指定することで、キャッシュ可能なプランの最大数を制御できます。 | | `tidb_ddl_distribute_reorg` | 削除済み | この変数の名前は[`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)に変更されます。 | | [`default_authentication_plugin`](/system-variables.md#default_authentication_plugin) | 変更 | 2 つの新しい値オプション`authentication_ldap_sasl`と`authentication_ldap_simple`が導入されました。 | | [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700) | 変更 | バージョン7.1.0以降で有効となり、負荷ベースのレプリカ読み取りをトリガーするためのしきい値を制御します。追加のテストを経て、デフォルト値を`"0s"`から`"1s"`に変更します。 | | [`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_base_dn`](/system-variables.md#authentication_ldap_sasl_bind_base_dn-new-in-v710) | 新しく追加された | LDAP SASL認証における検索ツリー内の検索範囲を制限します。`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_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サーバーへの接続プール内の初期接続を指定します。 | @@ -259,9 +259,9 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | [`authentication_ldap_sasl_server_host`](/system-variables.md#authentication_ldap_sasl_server_host-new-in-v710) | 新しく追加された | LDAP SASL 認証で LDAPサーバーホストを指定します。 | | [`authentication_ldap_sasl_server_port`](/system-variables.md#authentication_ldap_sasl_server_port-new-in-v710) | 新しく追加された | LDAP SASL 認証における LDAPサーバーのTCP/IP ポート番号を指定します。 | | [`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_auth_method_name`](/system-variables.md#authentication_ldap_simple_auth_method_name-new-in-v710) | 新しく追加された | LDAP簡易認証における認証方式名を指定します。`SIMPLE`のみがサポートされます。 | +| [`authentication_ldap_simple_bind_base_dn`](/system-variables.md#authentication_ldap_simple_bind_base_dn-new-in-v710) | 新しく追加された | LDAP簡易認証における検索ツリー内の検索範囲を制限します。`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_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) @@ -451,7 +451,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - TiDBDumpling - `UNSIGNED INTEGER`型の主キーがチャンクの分割に使用できない問題を修正しました [＃42620](https://github.com/pingcap/tidb/issues/42620) @ [lichunzhu](https://github.com/lichunzhu) - - `--output-file-template`誤って設定されている場合に TiDB Dumpling がpanic可能性がある問題を修正しました [＃42391](https://github.com/pingcap/tidb/issues/42391) @ [lichunzhu](https://github.com/lichunzhu) + - `--output-file-template`誤って設定されている場合に TiDB Dumpling がpanicする可能性がある問題を修正しました [＃42391](https://github.com/pingcap/tidb/issues/42391) @ [lichunzhu](https://github.com/lichunzhu) - TiDB Binlog diff --git a/releases/release-7.1.3.md b/releases/release-7.1.3.md index 38c6b284e1447..1a42849d8319e 100644 --- a/releases/release-7.1.3.md +++ b/releases/release-7.1.3.md @@ -73,8 +73,8 @@ 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) - - DDL `jobID` 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) + - 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) - ウィンドウ関数によって導入されたソートを削減するために、オプティマイザが誤って IndexFullScan を選択する問題を修正しました。 [＃46177](https://github.com/pingcap/tidb/issues/46177) @ [qw4990](https://github.com/qw4990) diff --git a/releases/release-7.1.4.md b/releases/release-7.1.4.md index c4fba3938468a..f3b431c360f9d 100644 --- a/releases/release-7.1.4.md +++ b/releases/release-7.1.4.md @@ -88,19 +88,19 @@ 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) + - `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) - ネットワークが不安定な場合にインデックスを追加するとインデックスデータの不整合が発生する可能性がある問題を修正[＃49773](https://github.com/pingcap/tidb/issues/49773) @ [tangenta](https://github.com/tangenta) - DDLジョブの実行順序を修正して、TiCDCが順序どおりに動作しないDDL を受信しないようにします。 [＃49498](https://github.com/pingcap/tidb/issues/49498) @ [tangenta](https://github.com/tangenta) - - `tidb_server_memory_limit`変数がに変更された後、 `tidb_gogc_tuner_threshold`システム変数がそれに応じて調整されない問題を修正しました [＃48180](https://github.com/pingcap/tidb/issues/48180) @ [hawkingrei](https://github.com/hawkingrei) + - `tidb_server_memory_limit`変数が変更された後、 `tidb_gogc_tuner_threshold`システム変数がそれに応じて調整されない問題を修正しました [＃48180](https://github.com/pingcap/tidb/issues/48180) @ [hawkingrei](https://github.com/hawkingrei) - 誤ったパーティションプルーニングが原因で、範囲パーティションテーブルのクエリ結果が間違っている場合がある問題を修正しました。 [＃50082](https://github.com/pingcap/tidb/issues/50082) @ [Defined2014](https://github.com/Defined2014) - `CREATE TABLE`文に特定のパーティションまたは制約が含まれている場合に、テーブル名の変更などの DDL 操作が停止する問題を修正しました[＃50972](https://github.com/pingcap/tidb/issues/50972) @ [lcwangchao](https://github.com/lcwangchao) - 列のデフォルト値が削除されている場合に列のデフォルト値を取得するとエラーが返される問題を修正[＃50043](https://github.com/pingcap/tidb/issues/50043) [＃51324](https://github.com/pingcap/tidb/issues/51324) @ [crazycs520](https://github.com/crazycs520) @@ -116,7 +116,7 @@ TiDBバージョン: 7.1.4 - ノードをオフラインにする前に、リージョン内のすべてのレプリカの最後のハートビート時間をチェックすることで、1 つのレプリカがオフラインになるとリージョン全体が使用できなくなる問題を修正しました[＃16465](https://github.com/tikv/tikv/issues/16465) @ [tonyxuqqi](https://github.com/tonyxuqqi) - Titan が有効になっているときに RocksDB に保存されるテーブルプロパティが不正確になる可能性がある問題を修正[＃16319](https://github.com/tikv/tikv/issues/16319) @ [hicqu](https://github.com/hicqu) - クラスターにTiFlashノードがある場合に`tikv-ctl compact-cluster`実行が失敗する問題を修正しました [＃16189](https://github.com/tikv/tikv/issues/16189) @ [frew](https://github.com/frew) - - gRPC スレッドが`is_shutdown` をチェックしているときに TiKV がpanic可能性がある問題を修正しました [＃16236](https://github.com/tikv/tikv/issues/16236) @ [pingyu](https://github.com/pingyu) + - gRPC スレッドが`is_shutdown` をチェックしているときに TiKV がpanicする可能性がある問題を修正しました [＃16236](https://github.com/tikv/tikv/issues/16236) @ [pingyu](https://github.com/pingyu) - `DECIMAL`算術乗算切り捨てを処理するときに TiDB と TiKV が矛盾した結果を生成する可能性がある問題を修正しました [＃16268](https://github.com/tikv/tikv/issues/16268) @ [solotzg](https://github.com/solotzg) - `cast_duration_as_time`誤った結果を返す可能性がある問題を修正[＃16211](https://github.com/tikv/tikv/issues/16211) @ [gengliqi](https://github.com/gengliqi) - TiKVがブラジルとエジプトのタイムゾーンを誤って変換する問題を修正[＃16220](https://github.com/tikv/tikv/issues/16220) @ [overvenus](https://github.com/overvenus) @@ -142,13 +142,13 @@ TiDBバージョン: 7.1.4 - TiFlash - - レプリカ移行中に PD とのネットワーク接続が不安定になり、 TiFlash がpanic可能性がある問題を修正しました [＃8323](https://github.com/pingcap/tiflash/issues/8323) @ [JaySon-Huang](https://github.com/JaySon-Huang) - - `ENUM`値が 0 の場合にTiFlash が`ENUM`誤って処理する問題を修正しました [＃8311](https://github.com/pingcap/tiflash/issues/8311) @ [solotzg](https://github.com/solotzg) + - レプリカ移行中に PD とのネットワーク接続が不安定になり、 TiFlash がpanicする可能性がある問題を修正しました [＃8323](https://github.com/pingcap/tiflash/issues/8323) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - `ENUM`値が 0 の場合にTiFlash が`ENUM`を誤って処理する問題を修正しました [＃8311](https://github.com/pingcap/tiflash/issues/8311) @ [solotzg](https://github.com/solotzg) - 定数文字列パラメータを含む`GREATEST`または`LEAST`関数で発生する可能性のある、ランダムに無効なメモリアクセスの問題を修正しました。 [＃8604](https://github.com/pingcap/tiflash/issues/8604) @ [windtalker](https://github.com/windtalker) - `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.4.0.md b/releases/release-7.4.0.md index 34dc6f1a5a219..2b1001af3c5ae 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -176,7 +176,7 @@ TiDB バージョン: 7.4.0 - 照合順序`utf8mb4_0900_ai_ci`と`utf8mb4_0900_bin`をサポート [＃37566](https://github.com/pingcap/tidb/issues/37566) @ [YangKeao](https://github.com/YangKeao) @ [zimulala](https://github.com/zimulala) @ [bb7133](https://github.com/bb7133) - TiDB v7.4.0 では、MySQL 8.0 からのデータ移行のサポートが強化され、 `utf8mb4_0900_ai_ci`と`utf8mb4_0900_bin` 2 つの照合順序が追加されました。5 `utf8mb4_0900_ai_ci` MySQL 8.0 のデフォルトの照合順序です。 + TiDB v7.4.0 では、MySQL 8.0 からのデータ移行のサポートが強化され、 `utf8mb4_0900_ai_ci`と`utf8mb4_0900_bin` 2 つの照合順序が追加されました。`utf8mb4_0900_ai_ci` MySQL 8.0 のデフォルトの照合順序です。 TiDB v7.4.0では、MySQL 8.0と互換性のあるシステム変数`default_collation_for_utf8mb4`も導入されました。これにより、utf8mb4文字セットのデフォルトの照合順序を指定できるようになり、 MySQL 5.7以前のバージョンからの移行やデータレプリケーションとの互換性が確保されます。 @@ -257,8 +257,8 @@ TiDB バージョン: 7.4.0 | [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) | 変更 | さらにテストを行った後、デフォルト値を`ON`から`OFF`に変更します。これは、非プリペアドプランキャッシュが無効であることを意味します。 | | [`default_collation_for_utf8mb4`](/system-variables.md#default_collation_for_utf8mb4-new-in-v740) | 新しく追加された | `utf8mb4`文字セットのデフォルトの照合順序を制御します。デフォルト値は`utf8mb4_bin`です。 | | [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) | 新しく追加された | 有効にするクラウドストレージURI を指定します[グローバルソート](/tidb-global-sort.md) 。 | -| [`tidb_opt_enable_hash_join`](/system-variables.md#tidb_opt_enable_hash_join-new-in-v656-v712-and-v740) | 新しく追加された | オプティマイザがテーブルに対してハッシュ結合を選択するかどうかを制御します。デフォルトの値は`ON`です。3 に`OFF`すると、他に利用可能な実行プランがない限り、オプティマイザはテーブルのハッシュ結合を選択しません。 | -| [`tidb_opt_objective`](/system-variables.md#tidb_opt_objective-new-in-v740) | 新しく追加された | この変数はオプティマイザの目的を制御します。1 `moderate` TiDB v7.4.0 より前のバージョンのデフォルトの動作を維持し、オプティマイザはより多くの情報を使用してより優れた実行プランを生成しようとします。3 `determinate`はより保守的になる傾向があり、実行プランをより安定させます。 | +| [`tidb_opt_enable_hash_join`](/system-variables.md#tidb_opt_enable_hash_join-new-in-v656-v712-and-v740) | 新しく追加された | オプティマイザがテーブルに対してハッシュ結合を選択するかどうかを制御します。デフォルトの値は`ON`です。`OFF`に設定すると、他に利用可能な実行プランがない限り、オプティマイザはテーブルのハッシュ結合を選択しません。 | +| [`tidb_opt_objective`](/system-variables.md#tidb_opt_objective-new-in-v740) | 新しく追加された | この変数はオプティマイザの目的を制御します。`moderate`は、TiDB v7.4.0 より前のバージョンのデフォルトの動作を維持し、オプティマイザはより多くの情報を使用してより優れた実行プランを生成しようとします。`determinate`はより保守的になる傾向があり、実行プランをより安定させます。 | | [`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740) | 新しく追加された | 現在のセッションのタスクタイプを明示的に指定します。タスクタイプは[リソース管理](/tidb-resource-control-ru-groups.md)によって識別および制御されます。例: `SET @@tidb_request_source_type = "background"` 。 | | [`tidb_schema_version_cache_limit`](/system-variables.md#tidb_schema_version_cache_limit-new-in-v740) | 新しく追加された | この変数は、TiDBインスタンスにキャッシュできる履歴スキーマバージョンの数を制限します。デフォルト値は`16`で、これはTiDBがデフォルトで16個の履歴スキーマバージョンをキャッシュすることを意味します。 | | [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) | 新しく追加された | この変数はインスタンスレベルのシステム変数です。これを使用して、 [TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md)配下のTiDBノードのサービススコープを制御できます。TiDBノードの`tidb_service_scope` `background`に設定すると、DXFはそのTiDBノードで[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)や[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)などのDXFタスクを実行するようにスケジュールします。 | diff --git a/releases/release-7.5.1.md b/releases/release-7.5.1.md index b7a8d90122b91..ed3ecdff3be94 100644 --- a/releases/release-7.5.1.md +++ b/releases/release-7.5.1.md @@ -141,7 +141,7 @@ TiDB バージョン: 7.5.1 - 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) + - DDL `jobID`が 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) - `STREAM_AGG()` CI を誤って処理したためにクエリ結果が正しくない問題を修正しました [＃49902](https://github.com/pingcap/tidb/issues/49902) @ [wshwsh12](https://github.com/wshwsh12) - 多数のテーブルまたはパーティションを処理するときに TiDB ノードが OOM エラーに遭遇する可能性がある問題を軽減します。 [＃50077](https://github.com/pingcap/tidb/issues/50077) @ [zimulala](https://github.com/zimulala) - `LEADING`ヒントが`UNION ALL`ステートメントで有効にならない問題を修正しました [＃50067](https://github.com/pingcap/tidb/issues/50067) @ [hawkingrei](https://github.com/hawkingrei) @@ -191,7 +191,7 @@ TiDB バージョン: 7.5.1 - `DROP TABLE`データ挿入の直後に実行されると、 `FLASHBACK TABLE`または`RECOVER TABLE`一部のTiFlashレプリカのデータを回復できない可能性がある潜在的な問題を修正しました。 [＃8395](https://github.com/pingcap/tiflash/issues/8395) @ [JaySon-Huang](https://github.com/JaySon-Huang) - Grafana の一部のパネルの最大パーセンタイル時間の表示が誤っていた問題を修正 [＃8076](https://github.com/pingcap/tiflash/issues/8076) @ [JaySon-Huang](https://github.com/JaySon-Huang) - リモート読み取り中にTiFlashがクラッシュする可能性がある問題を修正 [＃8685](https://github.com/pingcap/tiflash/issues/8685) @ [guo-shaoge](https://github.com/guo-shaoge) - - `ENUM`値が 0 の場合にTiFlash が`ENUM`誤って処理する問題を修正しました [＃8311](https://github.com/pingcap/tiflash/issues/8311) @ [solotzg](https://github.com/solotzg) + - `ENUM`値が 0 の場合にTiFlash が`ENUM`を誤って処理する問題を修正しました [＃8311](https://github.com/pingcap/tiflash/issues/8311) @ [solotzg](https://github.com/solotzg) - 短いクエリが正常に実行され、過剰な情報ログが出力される問題を修正しました。 [＃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) - `lowerUTF8`と`upperUTF8`関数で、大文字と小文字が異なるバイトを占めることができない問題を修正しました。 [＃8484](https://github.com/pingcap/tiflash/issues/8484) @ [gengliqi](https://github.com/gengliqi) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index 259703e32ac28..7c602968614ac 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -219,7 +219,7 @@ TiDB バージョン: 8.4.0 | [`tidb_enable_list_partition`](/system-variables.md#tidb_enable_list_partition-new-in-v50) | 非推奨 | バージョン8.4.0では、この変数は非推奨となります。その値はデフォルト値`ON`に固定され、[リスト分割](/partitioned-table.md#list-partitioning)がデフォルトで有効になります。 | | [`tidb_enable_table_partition`](/system-variables.md#tidb_enable_table_partition) | 非推奨 | v8.4.0 では、この変数は非推奨になりました。その値はデフォルト値`ON`に固定されます。つまり、[テーブルパーティショニング](/partitioned-table.md)はデフォルトで有効になります。 | | [`tidb_analyze_partition_concurrency`](/system-variables.md#tidb_analyze_partition_concurrency) | 変更 | 値の範囲を`[1, 18446744073709551615]`から`[1, 128]`に変更します。 | -| [`tidb_enable_inl_join_inner_multi_pattern`](/system-variables.md#tidb_enable_inl_join_inner_multi_pattern-new-in-v700) | 変更 | デフォルト値を`OFF`から`ON`に変更します。v8.4.0 以降、内部テーブルに`Selection` 、{{B-PLACEHOLDER-3-PLACEHOLDER- `Aggregation` `Projection`デフォルトでサポートされます。 | +| [`tidb_enable_inl_join_inner_multi_pattern`](/system-variables.md#tidb_enable_inl_join_inner_multi_pattern-new-in-v700) | 変更 | デフォルト値を`OFF`から`ON`に変更します。v8.4.0 以降、内部テーブルに`Selection` 、 `Aggregation` 、または`Projection`演算子がある場合、Index Join がデフォルトでサポートされます。 | | [`tidb_opt_prefer_range_scan`](/system-variables.md#tidb_opt_prefer_range_scan-new-in-v50) | 変更 | デフォルト値を`OFF`から`ON`に変更します。統計情報がないテーブル (擬似統計情報) または空のテーブル (統計情報がゼロ) の場合、オプティマイザはフルテーブルスキャンよりもインターバルスキャンを優先します。 | | [`tidb_scatter_region`](/system-variables.md#tidb_scatter_region) | 変更 | v8.4.0 より前は、型はブール型で、 `ON`と`OFF`のみをサポートし、新しく作成されたテーブルのリージョンは、有効化後にのみテーブルレベルの分散をサポートします。v8.4.0 以降では、 `SESSION`スコープが追加され、型がブール型から列挙型に変更され、デフォルト値が`OFF`から null に変更され、オプション値`TABLE`と`GLOBAL`が追加されました。さらに、バッチでの高速テーブル作成中にリージョンの不均一な分散によって発生する TiKV OOM の問題を回避するために、クラスタレベルの分散ポリシーがサポートされるようになりました。 | | [`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800) | 変更 | デフォルト値を`0`から`536870912` (512 MiB) に変更し、この機能がデフォルトで有効になっていることを示します。許可される最小値は`67108864` (64 MiB) に設定されています。 | @@ -273,7 +273,7 @@ v8.4.0 以降、次のコンテンツが`TiDB-community-toolkit`[バイナリパ TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 -- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 にアップグレードすると、クラスタが利用できなくなります。 +- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)によると、CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 にアップグレードすると、クラスタが利用できなくなります。 - [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB は、8.4 DMR バージョン以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタを v8.4.0 以降にアップグレードすると、クラスタが使用できなくなります。 ## 削除された機能 {#removed-features} diff --git a/releases/release-8.5.0.md b/releases/release-8.5.0.md index 3d2f7a0cc15a0..c3924867f3684 100644 --- a/releases/release-8.5.0.md +++ b/releases/release-8.5.0.md @@ -144,7 +144,7 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 -- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 および v8.5.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 または v8.5.0 にアップグレードすると、クラスタが利用できなくなるリスクがあります。CentOS Linux 7 を引き続き使用しているユーザーを支援するため、TiDB v8.5.1 では CentOS Linux 7 のテストを再開し、互換性を持たせています。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 +- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)によると、CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 および v8.5.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 または v8.5.0 にアップグレードすると、クラスタが利用できなくなるリスクがあります。CentOS Linux 7 を引き続き使用しているユーザーを支援するため、TiDB v8.5.1 では CentOS Linux 7 のテストを再開し、互換性を持たせています。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 - [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB はバージョン 8.4.0 以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタをバージョン 8.4.0 以降にアップグレードすると、クラスタが利用できなくなります。 ## 削除された機能 {#removed-features} diff --git a/releases/release-8.5.1.md b/releases/release-8.5.1.md index 8328c541b41b0..e461fb02b969c 100644 --- a/releases/release-8.5.1.md +++ b/releases/release-8.5.1.md @@ -15,9 +15,9 @@ TiDBバージョン：8.5.1 バージョン8.5.1以降、TiDBはCentOS Linux 7のテストを再開し、互換性を確保しています。TiDB v8.5をデプロイする場合、またはクラスタをv8.5にアップグレードする場合は、TiDB v8.5.1以降のバージョンを使用してください。 -- TiDB v8.4.0 DMR および v8.5.0 リリースは[2024年6月30日をもってサポート終了となります](https://www.redhat.com/en/topics/linux/centos-linux-eol) CentOS 7 上の TiDB クラスターを v8.4.0 または v8.5.0 にアップグレードすると、クラスターが使用できなくなるリスクが発生します。 +- CentOS Linux 7 は[2024年6月30日をもってサポート終了となります](https://www.redhat.com/en/topics/linux/centos-linux-eol)。そのため、TiDB v8.4.0 DMR および v8.5.0 リリースでは、CentOS Linux 7 のサポートとテストを終了しました。CentOS 7 上の TiDB クラスターを v8.4.0 または v8.5.0 にアップグレードすると、クラスターが使用できなくなるリスクが発生します。 -- 現在も CentOS Linux 7 を使用しているユーザーを支援するために、TiDB は v8.5.1 から CentOS Linux 7 のテストを再開します。ただし、CentOS Linux の EOL ステータスのため、CentOS Linux 7 の[公式発表およびセキュリティに関するガイダンス](https://www.redhat.com/en/blog/centos-linux-has-reached-its-end-life-eol)およびセキュリティに関するガイダンスを確認し、Rocky Linux 9.1 以降などの本番使用用の[TiDBがサポートするオペレーティングシステム](/hardware-and-software-requirements.md#os-and-platform-requirements)する報酬システムに移行することを強くお勧めします。 +- 現在も CentOS Linux 7 を使用しているユーザーを支援するために、TiDB は v8.5.1 から CentOS Linux 7 のテストを再開します。ただし、CentOS Linux の EOL ステータスのため、CentOS Linux 7 の[公式発表およびセキュリティに関するガイダンス](https://www.redhat.com/en/blog/centos-linux-has-reached-its-end-life-eol)を確認し、Rocky Linux 9.1 以降などの本番使用向けの[TiDBがサポートするオペレーティングシステム](/hardware-and-software-requirements.md#os-and-platform-requirements)に移行することを強くお勧めします。 CentOS Linux 7はサポート終了（EOL）を迎えたため、今後のTiDBリリースではこのディストリビューションのテストは中止されます。 diff --git a/releases/release-8.5.4.md b/releases/release-8.5.4.md index 9665ccae49b27..596724826dbba 100644 --- a/releases/release-8.5.4.md +++ b/releases/release-8.5.4.md @@ -90,7 +90,7 @@ TiDBバージョン：8.5.4 ### MySQLとの互換性 {#mysql-compatibility} -バージョン 8.5.4 以降、TiDB は`DECIMAL`列にデータを挿入する際の動作を MySQL と同期させました。小数点以下の桁数が列の定義済みスケールを超える場合、TiDB は余分な桁を自動的に切り捨て、切り捨てられたデータを正常に挿入します。小数点以下の桁数に関係なく、切り捨てられたデータは挿入されます。以前の TiDB バージョンでは、挿入される`DECIMAL`値の小数点以下の桁数が 72 を超えると、挿入は失敗し、エラーが返されました。詳細については、 [JDBCを使用してTiDBに接続する](https://docs.pingcap.com/tidb/v8.5/dev-guide-sample-application-java-jdbc#mysql-compatibility) +バージョン 8.5.4 以降、TiDB は`DECIMAL`列にデータを挿入する際の動作を MySQL と同期させました。小数点以下の桁数が列の定義済みスケールを超える場合、TiDB は、超過した小数点以下の桁数に関係なく、余分な桁を自動的に切り捨て、切り捨てられたデータを正常に挿入します。以前の TiDB バージョンでは、挿入される`DECIMAL`値の小数点以下の桁数が 72 を超えると、挿入は失敗し、エラーが返されました。詳細については、 [JDBCを使用してTiDBに接続する](https://docs.pingcap.com/tidb/v8.5/dev-guide-sample-application-java-jdbc#mysql-compatibility)を参照してください。 ## 改善点 {#improvements} diff --git a/releases/versioning.md b/releases/versioning.md index 63a64f612441b..16017f5090708 100644 --- a/releases/versioning.md +++ b/releases/versioning.md @@ -22,9 +22,9 @@ TiDB のメジャー リリースのサポート ポリシーについては、 TiDB のバージョン番号は`X.Y.Z`から始まり、 `X.Y`リリース シリーズを表します。 -- TiDB 1.0以降、毎年`X`増加します。3リリース`X`に新機能と改善が導入されます。 -- `Y`から増加します。 `Y`ごとに新しい機能と改善が導入されます。 -- リリースシリーズの最初のリリースでは、デフォルトで`Z`が 0 に設定されます。パッチリリースの場合は、1 から`Z`増加します。 +- TiDB 1.0以降、`X`は毎年増加します。`X`リリースごとに新しい機能と改善が導入されます。 +- `Y`は 0 から増加します。 `Y`リリースごとに新しい機能と改善が導入されます。 +- リリースシリーズの最初のリリースでは、デフォルトで`Z`が 0 に設定されます。パッチリリースの場合は、 `Z`は 1 から増加します。 TiDB v5.0.0 以前のバージョンのバージョン管理システムについては、 [歴史的なバージョン管理](#historical-versioning-deprecated)を参照してください。 @@ -32,7 +32,7 @@ TiDB v5.0.0 以前のバージョンのバージョン管理システムにつ 長期サポート (LTS) バージョンは約 6 か月ごとにリリースされ、新しい機能、改善、バグ修正、セキュリティ脆弱性修正が導入されます。 -LTS リリースのバージョンは`X.Y.Z`です。3 `Z`デフォルトは 0 です。 +LTS リリースのバージョンは`X.Y.Z`です。`Z`デフォルトは 0 です。 例のバージョン: @@ -41,7 +41,7 @@ LTS リリースのバージョンは`X.Y.Z`です。3 `Z`デフォルトは 0 LTS のライフサイクル中は、パッチリリースがオンデマンドで提供されます。パッチリリースにはバグ修正とセキュリティ脆弱性の修正が含まれており、新機能は導入されません。 -パッチリリースのバージョン番号は`X.Y.Z`です。3 `X.Y`対応する LTS バージョン番号と一致しています。パッチ番号`Z` 1 から増加します。 +パッチリリースのバージョン番号は`X.Y.Z`です。`X.Y`対応する LTS バージョン番号と一致しています。パッチ番号`Z` 1 から増加します。 例のバージョン: @@ -57,7 +57,7 @@ v5.1.0、v5.2.0、v5.3.0、v5.4.0 は、前のリリースからわずか 2 か 開発マイルストーンリリース（DMR）は、LTSを含まない約2ヶ月ごとにリリースされます。DMRバージョンでは、新機能、改善、バグ修正が導入されます。TiDBはDMRに基づくパッチリリースを提供しておらず、関連するバグは後続のリリースシリーズで修正されます。 -DMR のバージョン番号は`X.Y.Z`です。3 `Z`デフォルトで 0 になります。バージョン番号に`-DMR`というサフィックスが追加されます。 +DMR のバージョン番号は`X.Y.Z`です。`Z`デフォルトで 0 になります。バージョン番号に`-DMR`というサフィックスが追加されます。 例のバージョン: diff --git a/role-based-access-control.md b/role-based-access-control.md index 5f3ce18bbe024..80b2e1dafd81f 100644 --- a/role-based-access-control.md +++ b/role-based-access-control.md @@ -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()`を使用します。`SHOW GRANTS`と`SHOW GRANTS FOR CURRENT_USER()`は次の点で異なります。 - `SHOW GRANTS` 、現在のユーザーに対して有効なロールの権限を示します。 - `SHOW GRANTS FOR CURRENT_USER()`場合、有効なロールの権限は表示されません。 diff --git a/runtime-filter.md b/runtime-filter.md index 80480b274e9be..f1ea02c5c8182 100644 --- a/runtime-filter.md +++ b/runtime-filter.md @@ -22,7 +22,7 @@ summary: ランタイム フィルターの動作原理とその使用方法を ### 例 {#example} -`store_sales`テーブルと`date_dim`テーブルの間に結合クエリがあり、結合方法はハッシュ結合であるとします。5 `store_sales`主に店舗の売上データを格納するファクトテーブルで、行数は100万行です。7 `date_dim`主に日付情報を格納する時間ディメンションテーブルです。2001年の売上データを取得するクエリを実行するため、 `date_dim`テーブルの365行が結合操作に関係します。 +`store_sales`テーブルと`date_dim`テーブルの間に結合クエリがあり、結合方法はハッシュ結合であるとします。`store_sales`主に店舗の売上データを格納するファクトテーブルで、行数は100万行です。`date_dim`主に日付情報を格納する時間ディメンションテーブルです。2001年の売上データを取得するクエリを実行するため、 `date_dim`テーブルの365行が結合操作に関係します。 ```sql SELECT * FROM store_sales, date_dim @@ -170,7 +170,7 @@ WHERE d_date = '2002-2-01' AND ### ステップ4. パフォーマンスの比較 {#step-4-performance-comparison} -この例では、50 GBのTPC-DSデータを使用しています。ランタイムフィルターを有効にすると、クエリ時間は0.38秒から0.17秒に短縮され、効率は`ANALYZE` %向上します。1 ステートメントを使用すると、ランタイムフィルター有効後の各演算子の実行時間を確認できます。 +この例では、50 GBのTPC-DSデータを使用しています。ランタイムフィルターを有効にすると、クエリ時間は0.38秒から0.17秒に短縮され、効率は 50 %向上します。`ANALYZE`ステートメントを使用すると、ランタイムフィルター有効後の各演算子の実行時間を確認できます。 ランタイム フィルターが有効になっていない場合のクエリの実行情報は次のとおりです。 diff --git a/scale-microservices-using-tiup.md b/scale-microservices-using-tiup.md index 6522c24c5aa44..aaa402f4dc30c 100644 --- a/scale-microservices-using-tiup.md +++ b/scale-microservices-using-tiup.md @@ -84,8 +84,8 @@ scheduling_servers: 上記のコマンドでは、 - `scale-out.yml`はスケールアウト構成ファイルです。 -- `--user root` 、クラスタのスケールアウトを完了するために、ターゲットマシンに`root`ユーザーとしてログインすることを示します。4 `root`ユーザーは、ターゲットマシンに対して`ssh`と`sudo`権限を持つことが想定されています。または、 `ssh`と`sudo`権限を持つ他のユーザーを使用してデプロイを完了することもできます。 -- `[-i]`と`[-p]`オプションです。ターゲットマシンへのログインにパスワードを使用しない設定をしている場合は、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。4 `[-i]` 、ターゲットマシンにアクセスできるルートユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。8 `[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 +- `--user root` 、クラスタのスケールアウトを完了するために、ターゲットマシンに`root`ユーザーとしてログインすることを示します。`root`ユーザーは、ターゲットマシンに対して`ssh`と`sudo`権限を持つことが想定されています。または、 `ssh`と`sudo`権限を持つ他のユーザーを使用してデプロイを完了することもできます。 +- `[-i]`と`[-p]`オプションです。ターゲットマシンへのログインにパスワードを使用しない設定をしている場合は、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。`[-i]` 、ターゲットマシンにアクセスできるルートユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。`[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 `Scaled cluster out successfully`表示された場合、スケールアウト操作は成功しています。 diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md index b8fc682b34f50..fbc3c4ac34b85 100644 --- a/scale-tidb-using-tiup.md +++ b/scale-tidb-using-tiup.md @@ -107,8 +107,8 @@ TiDB クラスターの容量は、オンライン サービスを中断する 上記のコマンドでは、 - `scale-out.yml`はスケールアウト構成ファイルです。 - - `--user root` 、クラスタのスケールアウトを完了するために、ターゲットマシンに`root`ユーザーとしてログインすることを示します。4 `root`ユーザーは、ターゲットマシンに対して`ssh`と`sudo`権限を持つことが想定されています。または、 `ssh`と`sudo`権限を持つ他のユーザーを使用してデプロイを完了することもできます。 - - `[-i]`と`[-p]`オプションです。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。4 `[-i]` 、ターゲットマシンにアクセスできるルートユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。8 `[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 + - `--user root` 、クラスタのスケールアウトを完了するために、ターゲットマシンに`root`ユーザーとしてログインすることを示します。`root`ユーザーは、ターゲットマシンに対して`ssh`と`sudo`権限を持つことが想定されています。または、 `ssh`と`sudo`権限を持つ他のユーザーを使用してデプロイを完了することもできます。 + - `[-i]`と`[-p]`オプションです。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。`[-i]` 、ターゲットマシンにアクセスできるルートユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。`[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 `Scaled cluster out successfully`表示された場合、スケールアウト操作は成功しています。 @@ -338,13 +338,13 @@ TiDB クラスターの容量は、オンライン サービスを中断する ### 1. 残りのTiFlashノードの数に応じてテーブルのレプリカ数を調整する {#1-adjust-the-number-of-replicas-of-the-tables-according-to-the-number-of-remaining-tiflash-nodes} -1. スケールイン後のTiFlashノード数を超えるTiFlashレプリカを持つテーブルがあるかどうかを照会します。1 `tobe_left_nodes`スケールイン後のTiFlashノード数を意味します。クエリ結果が空の場合、 TiFlashのスケールインを開始できます。クエリ結果が空でない場合は、関連テーブルのTiFlashレプリカ数を変更する必要があります。 +1. スケールイン後のTiFlashノード数を超えるTiFlashレプリカを持つテーブルがあるかどうかを照会します。`tobe_left_nodes`スケールイン後のTiFlashノード数を意味します。クエリ結果が空の場合、 TiFlashのスケールインを開始できます。クエリ結果が空でない場合は、関連テーブルのTiFlashレプリカ数を変更する必要があります。 ```sql SELECT * FROM information_schema.tiflash_replica WHERE REPLICA_COUNT > 'tobe_left_nodes'; ``` -2. スケールイン後のTiFlashノードの数より多いTiFlashレプリカを持つすべてのテーブルに対して次のステートメントを実行します。1 `new_replica_num` `tobe_left_nodes`である必要があります。 +2. スケールイン後のTiFlashノードの数より多いTiFlashレプリカを持つすべてのテーブルに対して次のステートメントを実行します。`new_replica_num` `tobe_left_nodes`である必要があります。 ```sql ALTER TABLE . SET tiflash replica 'new_replica_num'; diff --git a/schedule-replicas-by-topology-labels.md b/schedule-replicas-by-topology-labels.md index 09ff463606d60..434ec0c2862d1 100644 --- a/schedule-replicas-by-topology-labels.md +++ b/schedule-replicas-by-topology-labels.md @@ -21,7 +21,7 @@ TiDBクラスターの高可用性と災害復旧能力を向上させるには TiUPを使用してクラスターをデプロイする場合、 [初期化設定ファイル](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)で TiKV の場所を設定できます。TiUPは、デプロイ中に TiDB、TiKV、PD、およびTiFlashの対応する設定ファイルを生成します。 -以下の例では、2層トポロジ（ `zone/host`が定義されています。クラスターのTiDBノード、TiKVノード、およびTiFlashノードは、3つのゾーン（z1、z2、z3）に分散されています。 +以下の例では、2層トポロジ（ `zone/host` ）が定義されています。クラスターのTiDBノード、TiKVノード、およびTiFlashノードは、3つのゾーン（z1、z2、z3）に分散されています。 - 各ゾーンには、TiDB インスタンスがデプロイされているホストが 2 つあり、各ホストには個別の TiDB インスタンスがデプロイされています。 - 各ゾーンには、TiKVインスタンスがデプロイされたホストが2つあります。z1では、各ホストに2つのTiKVインスタンスがデプロイされています。z2とz3では、各ホストに個別のTiKVインスタンスがデプロイされています。 @@ -223,7 +223,7 @@ host = "" > **Note:** > > - 設定を有効にするには、PDに`location-labels` 、TiKVに`labels`同時に設定する必要があります。そうしないと、PDはトポロジに従ってスケジューリングを実行しません。 -> - SQL の配置ルールを使用する場合、TiKV の場合は`labels`のみ設定する必要があります。現在、SQL の配置ルールは PD の`location-labels`設定と互換性がなく、この設定は無視されます。5 `location-labels` SQL の配置ルールを同時に使用することは推奨されません。予期しない結果が発生する可能性があります。 +> - SQL の配置ルールを使用する場合、TiKV の場合は`labels`のみ設定する必要があります。現在、SQL の配置ルールは PD の`location-labels`設定と互換性がなく、この設定は無視されます。`location-labels` SQL の配置ルールを同時に使用することは推奨されません。予期しない結果が発生する可能性があります。 `location-labels`構成するには、クラスターの状況に応じて次のいずれかの方法を選択します。 @@ -244,7 +244,7 @@ host = "" `location-labels`が設定されている場合は、PD 設定ファイルで`isolation-level`設定することで、TiKV クラスターのトポロジ分離要件をさらに強化できます。 -上記の手順に従って`location-labels`ゾーン -> ラック -> ホストと設定して 3 層クラスタ トポロジを作成したと仮定すると、 `isolation-level` ～ `zone`次のように設定できます。 +上記の手順に従って`location-labels`をゾーン -> ラック -> ホストと設定して 3 層クラスタ トポロジを作成したと仮定すると、次のように`isolation-level`を`zone`に設定できます。 ```toml [replication] @@ -277,6 +277,6 @@ PD はラベルレイヤーに従ってレプリカをスケジュールし、 `isolation-level`設定が`zone`に設定されている場合、これは物理レベルでのリージョンレプリカの最小分離要件を指定します。この場合、PD は常に同じリージョンのレプリカが異なるゾーンに分散されることを保証します。この分離制限に従うことで`max-replicas`のマルチレプリカ要件が満たされない場合でも、PD はそれに応じてスケジュールを設定しません。3 つのデータ ゾーン (z1、z2、z3) に分散された TiKV クラスターを例にとると、各リージョンに 3 つのレプリカが必要な場合、PD は同じリージョンの 3 つのレプリカをそれぞれこれらの 3 つのデータ ゾーンに分散します。z1 で停電が発生し、一定時間 (デフォルトでは 30 分、 [`max-store-down-time`](/pd-configuration-file.md#max-store-down-time)によって制御) が経過しても回復できない場合、PD は z1 のリージョンレプリカが使用できなくなったと判断します。ただし、 `isolation-level` `zone`に設定されているため、PD は、同じリージョンの異なるレプリカが同じデータ ゾーンにスケジュールされないことを厳密に保証する必要があります。 z2 と z3 の両方にすでにレプリカがあるため、現時点でレプリカが 2 つしかない場合でも、PD は最小分離レベル制限`isolation-level`の下ではスケジュールを実行しません。 -同様に、 `isolation-level` `rack`に設定すると、同一データセンター内の異なるラックに最小分離レベルが適用されます。この構成では、ゾーンレイヤーでの分離が可能な限り最初に保証されます。ゾーンレベルでの分離が保証できない場合、PD は同じゾーン内の同じラックに異なるレプリカがスケジュールされることを避けようとします。5 `host` `isolation-level`設定した場合も同様にスケジューリングが行われ、PD はまずラックの分離レベルを保証し、次にホストの分離レベルを保証します。 +同様に、 `isolation-level` `rack`に設定すると、同一データセンター内の異なるラックに最小分離レベルが適用されます。この構成では、ゾーンレイヤーでの分離が可能な限り最初に保証されます。ゾーンレベルでの分離が保証できない場合、PD は同じゾーン内の同じラックに異なるレプリカがスケジュールされることを避けようとします。`host` `isolation-level`設定した場合も同様にスケジューリングが行われ、PD はまずラックの分離レベルを保証し、次にホストの分離レベルを保証します。 要約すると、PDは現在のトポロジに応じてクラスターの災害復旧を最大化します。したがって、一定レベルの災害復旧を実現したい場合は、トポロジに応じて、異なるサイトに`max-replicas`台以上のマシンを展開する必要があります。TiDBは、 `isolation-level`などの必須構成項目も提供しており、さまざまなシナリオに応じてデータのトポロジ分離レベルをより柔軟に制御できます。 diff --git a/security-compatibility-with-mysql.md b/security-compatibility-with-mysql.md index 38bc790053180..da382e51502cb 100644 --- a/security-compatibility-with-mysql.md +++ b/security-compatibility-with-mysql.md @@ -249,7 +249,7 @@ TiDB Self-Managed ユーザーの認証方法として`tidb_auth_token`設定し mycli -h 127.0.0.1 -P 4000 -u 'user@pingcap.com' -p '' ``` - ここで紹介するMySQLクライアントが`mysql_clear_password`プラグインをサポートしていることを確認してください。3 [mycli](https://www.mycli.net/)デフォルトでこのプラグインをサポートし、有効化します。5 [MySQLコマンドラインクライアント](https://dev.mysql.com/doc/refman/8.0/en/mysql.html)使用している場合は、 `--enable-cleartext-plugin`オプションを使用してこのプラグインを有効化する必要があります。 + ここで紹介するMySQLクライアントが`mysql_clear_password`プラグインをサポートしていることを確認してください。[mycli](https://www.mycli.net/)はデフォルトでこのプラグインをサポートし、有効化します。[MySQLコマンドラインクライアント](https://dev.mysql.com/doc/refman/8.0/en/mysql.html)を使用している場合は、 `--enable-cleartext-plugin`オプションを使用してこのプラグインを有効化する必要があります。 ```Shell mysql -h 127.0.0.1 -P 4000 -u 'user@pingcap.com' -p'' --enable-cleartext-plugin diff --git a/smooth-upgrade-tidb.md b/smooth-upgrade-tidb.md index d9da2d1fbbf4d..fae3c5528140e 100644 --- a/smooth-upgrade-tidb.md +++ b/smooth-upgrade-tidb.md @@ -49,7 +49,7 @@ These limitations can be summarized as that you need to ensure that there are no #### TiUPを使用してアップグレードする {#use-tiup-to-upgrade} -v1.14.0以降、 TiUPはこの機能を自動的にサポートします。つまり、 `tiup cluster upgrade`コマンドを使用してTiDBクラスタを直接アップグレードできます。3 `tiup cluster patch`は現在サポートされていないことに注意してください。 +v1.14.0以降、 TiUPはこの機能を自動的にサポートします。つまり、 `tiup cluster upgrade`コマンドを使用してTiDBクラスタを直接アップグレードできます。`tiup cluster patch`は現在サポートされていないことに注意してください。 #### TiDB Operatorを使用してアップグレードする {#use-tidb-operator-to-upgrade} diff --git a/sql-plan-management.md b/sql-plan-management.md index 1f2d6e2fca969..1318e9e3ae203 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -9,7 +9,7 @@ SQL計画管理は、SQLバインディングを実行してSQL実行計画を ## SQLバインディング {#sql-binding} -SQLバインディングはSPMの基盤です。1 [オプティマイザヒント](/optimizer-hints.md)ドキュメントでは、ヒントを用いて特定の実行プランを選択する方法を紹介しています。しかし、SQL文を変更せずに実行プランの選択を操作したい場合もあります。SQLバインディングを使用すれば、SQL文を変更せずに特定の実行プランを選択できます。 +SQLバインディングはSPMの基盤です。[オプティマイザヒント](/optimizer-hints.md)ドキュメントでは、ヒントを用いて特定の実行プランを選択する方法を紹介しています。しかし、SQL文を変更せずに実行プランの選択を操作したい場合もあります。SQLバインディングを使用すれば、SQL文を変更せずに特定の実行プランを選択できます。 @@ -196,7 +196,7 @@ USING explain SELECT * FROM t1, t2 WHERE t1.id = t2.id; ``` -最初の`SELECT`番目の文が実行されると、オプティマイザはGLOBALスコープのバインディングを介して`sm_join(t1, t2)`ヒントを文に追加します。5 `explain`の結果における実行プランの最上位ノードはMergeJoinです。2番目の`SELECT`番目の文が実行されると、オプティマイザはGLOBALスコープのバインディングではなくSESSIONスコープのバインディングを使用し、 `hash_join(t1, t2)`ヒントを文に追加します。11 `explain`の結果における実行プランの最上位ノードはHashJoinです。 +最初の`SELECT`番目の文が実行されると、オプティマイザはGLOBALスコープのバインディングを介して`sm_join(t1, t2)`ヒントを文に追加します。`explain`の結果における実行プランの最上位ノードはMergeJoinです。2番目の`SELECT`番目の文が実行されると、オプティマイザはGLOBALスコープのバインディングではなくSESSIONスコープのバインディングを使用し、 `hash_join(t1, t2)`ヒントを文に追加します。11 `explain`の結果における実行プランの最上位ノードはHashJoinです。 各標準化SQL文には、 `CREATE BINDING`ずつ作成できるバインディングが1つだけです。同じ標準化SQL文に複数のバインディングが作成された場合、最後に作成されたバインディングが保持され、それ以前に作成されたバインディング（作成済みおよび展開済み）はすべて削除済みとしてマークされます。ただし、セッションバインディングとグローバルバインディングは共存可能であり、このロジックの影響を受けません。 @@ -324,7 +324,7 @@ drop session binding for SELECT * FROM t1, t2 WHERE t1.id = t2.id; explain SELECT * FROM t1,t2 WHERE t1.id = t2.id; ``` -上記の例では、SESSIONスコープ内の削除されたバインディングが、GLOBALスコープ内の対応するバインディングを隠蔽しています。オプティマイザは、文に`sm_join(t1, t2)`ヒントを追加しません。3 `explain`の結果における実行プランのトップノードは、このヒントによってMergeJoinに固定されるわけではありません。代わりに、オプティマイザはコスト見積もりに基づいてトップノードを独自に選択します。 +上記の例では、SESSIONスコープ内の削除されたバインディングが、GLOBALスコープ内の対応するバインディングを隠蔽しています。オプティマイザは、文に`sm_join(t1, t2)`ヒントを追加しません。`explain`の結果における実行プランのトップノードは、このヒントによってMergeJoinに固定されるわけではありません。代わりに、オプティマイザはコスト見積もりに基づいてトップノードを独自に選択します。 #### SQLダイジェストに従ってバインディングを削除する {#remove-a-binding-according-to-sql-digest} diff --git a/sql-plan-replayer.md b/sql-plan-replayer.md index 52147e75e1885..f2546671f08ba 100644 --- a/sql-plan-replayer.md +++ b/sql-plan-replayer.md @@ -202,7 +202,7 @@ TiDBの実行プランを特定する場合、対象となるSQL文と実行プ ### PLAN REPLAYER CAPTUREを有効にする {#enable-code-plan-replayer-capture-code} -`PLAN REPLAYER CAPTURE`はシステム変数[`tidb_enable_plan_replayer_capture`](/system-variables.md#tidb_enable_plan_replayer_capture)によって制御されます。4 `PLAN REPLAYER CAPTURE`有効にするには、システム変数の値を`ON`に設定します。 +`PLAN REPLAYER CAPTURE`はシステム変数[`tidb_enable_plan_replayer_capture`](/system-variables.md#tidb_enable_plan_replayer_capture)によって制御されます。`PLAN REPLAYER CAPTURE`有効にするには、システム変数の値を`ON`に設定します。 ### PLAN REPLAYER CAPTURE使用する {#use-code-plan-replayer-capture-code} @@ -286,7 +286,7 @@ Empty set (0.01 sec) ### PLAN REPLAYER CONTINUOUS CAPTUREを有効にする {#enable-code-plan-replayer-continuous-capture-code} -`PLAN REPLAYER CONTINUOUS CAPTURE`はシステム変数[`tidb_enable_plan_replayer_continuous_capture`](/system-variables.md#tidb_enable_plan_replayer_continuous_capture-new-in-v700)によって制御されます。4 `PLAN REPLAYER CONTINUOUS CAPTURE`有効にするには、システム変数の値を`ON`に設定します。 +`PLAN REPLAYER CONTINUOUS CAPTURE`はシステム変数[`tidb_enable_plan_replayer_continuous_capture`](/system-variables.md#tidb_enable_plan_replayer_continuous_capture-new-in-v700)によって制御されます。`PLAN REPLAYER CONTINUOUS CAPTURE`有効にするには、システム変数の値を`ON`に設定します。 ### キャプチャ結果を表示する {#view-the-capture-results} diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index ee8dce525a4f1..c5b600681a624 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -128,7 +128,7 @@ MySQL [test]> select @@last_plan_from_cache; ### SHOW WARNINGSを使用して診断する {#use-code-show-warnings-code-to-diagnose} -一部のクエリまたはプランはキャッシュできません。1 ステートメント`SHOW WARNINGS`使用して、クエリまたはプランがキャッシュされているかどうかを確認できます。キャッシュされていない場合は、結果で失敗の理由を確認できます。例: +一部のクエリまたはプランはキャッシュできません。`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. @@ -280,7 +280,7 @@ MySQL [test]> select @@last_plan_from_cache; -- The cached plan cannot be select 1 row in set (0.00 sec) ``` -現在、TiDBは`GLOBAL`実行計画キャッシュのクリアをサポートしていません。つまり、TiDBクラスタ全体のキャッシュされた計画をクリアすることはできません。3 `GLOBAL`実行計画キャッシュをクリアしようとすると、以下のエラーが報告されます。 +現在、TiDBは`GLOBAL`実行計画キャッシュのクリアをサポートしていません。つまり、TiDBクラスタ全体のキャッシュされた計画をクリアすることはできません。`GLOBAL`実行計画キャッシュをクリアしようとすると、以下のエラーが報告されます。 ```sql MySQL [test]> admin flush global plan_cache; diff --git a/sql-statements/sql-statement-admin-cancel-ddl.md b/sql-statements/sql-statement-admin-cancel-ddl.md index d7950d2dfe0fa..e92b7907cb4a5 100644 --- a/sql-statements/sql-statement-admin-cancel-ddl.md +++ b/sql-statements/sql-statement-admin-cancel-ddl.md @@ -33,7 +33,7 @@ ADMIN CANCEL DDL JOBS job_id [, job_id] ...; > **Note:** > > - バージョン6.2.0より前では、この操作のみがDDLジョブをキャンセルでき、他のすべての操作や環境変更（マシンの再起動やクラスタの再起動など）ではこれらのジョブをキャンセルできませんでした。バージョン6.2.0以降では、 [`KILL`](/sql-statements/sql-statement-kill.md)ステートメントを使用して実行中のDDLジョブを強制終了することでキャンセルできるようになりました。 -> - この操作では、複数のDDLジョブを同時にキャンセルできます。1 ステートメントを使用して、 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ジョブのIDを取得できます。 +> - この操作では、複数のDDLジョブを同時にキャンセルできます。 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブのIDを取得できます。 > - キャンセルするジョブが完了している場合、キャンセル操作は失敗します。 ## MySQLの互換性 {#mysql-compatibility} diff --git a/sql-statements/sql-statement-admin-checksum-table.md b/sql-statements/sql-statement-admin-checksum-table.md index c4aa08b6ebed1..92cbdc502d937 100644 --- a/sql-statements/sql-statement-admin-checksum-table.md +++ b/sql-statements/sql-statement-admin-checksum-table.md @@ -12,7 +12,7 @@ category: reference [チェックサム](/tidb-lightning/tidb-lightning-glossary.md#checksum) 、テーブルのデータと`table_id`などのプロパティに基づいて計算されます。つまり、同じデータを持ちながらも`table_id`値が異なる 2 つのテーブルでは、チェックサムは異なります。 -[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 、 [TiDB Data Migration](/dm/dm-overview.md) 、または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE `実行されます。 +[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 、 [TiDB Data Migration](/dm/dm-overview.md) 、または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE
    `が実行されます。 diff --git a/sql-statements/sql-statement-admin-pause-ddl.md b/sql-statements/sql-statement-admin-pause-ddl.md index e85601f63b2ac..98ff300c0e829 100644 --- a/sql-statements/sql-statement-admin-pause-ddl.md +++ b/sql-statements/sql-statement-admin-pause-ddl.md @@ -35,7 +35,7 @@ ADMIN PAUSE DDL JOBS job_id [, job_id] ...; > > - このステートメントは DDL ジョブを一時停止できますが、他の操作や環境の変更 (マシンの再起動やクラスターの再起動など) では、クラスターのアップグレードを除き、DDL ジョブは一時停止されません。 > - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](/smooth-upgrade-tidb.md)ご覧ください。 -> - このステートメントは複数のDDLジョブを一時停止できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 +> - このステートメントは複数のDDLジョブを一時停止できます。[`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`を取得できます。 @@ -44,7 +44,7 @@ ADMIN PAUSE DDL JOBS job_id [, job_id] ...; > > - このステートメントは DDL ジョブを一時停止できますが、他の操作や環境の変更 (マシンの再起動やクラスターの再起動など) では、クラスターのアップグレードを除き、DDL ジョブは一時停止されません。 > - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](https://docs.pingcap.com/tidb/stable/smooth-upgrade-tidb)ご覧ください。 -> - このステートメントは複数のDDLジョブを一時停止できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 +> - このステートメントは複数のDDLジョブを一時停止できます。[`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`を取得できます。 diff --git a/sql-statements/sql-statement-admin-resume-ddl.md b/sql-statements/sql-statement-admin-resume-ddl.md index 2e329c67aed5d..8913fc2b8226f 100644 --- a/sql-statements/sql-statement-admin-resume-ddl.md +++ b/sql-statements/sql-statement-admin-resume-ddl.md @@ -34,7 +34,7 @@ ADMIN RESUME DDL JOBS job_id [, job_id] ...; > **Note:** > > - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](/smooth-upgrade-tidb.md)ご覧ください。 -> - このステートメントは複数のDDLジョブを再開できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 +> - このステートメントは複数のDDLジョブを再開できます。[`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`を取得できます。 > - その他のステータス ( `paused`以外) の DDL ジョブは再開できず、再開操作は失敗します。 > - ジョブを複数回再開しようとすると、TiDB はエラー`Error Number: 8261`報告します。 @@ -44,7 +44,7 @@ ADMIN RESUME DDL JOBS job_id [, job_id] ...; > **Note:** > > - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](https://docs.pingcap.com/tidb/stable/smooth-upgrade-tidb)ご覧ください。 -> - このステートメントは複数のDDLジョブを再開できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 +> - このステートメントは複数のDDLジョブを再開できます。[`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`を取得できます。 > - その他のステータス ( `paused`以外) の DDL ジョブは再開できず、再開操作は失敗します。 > - ジョブを複数回再開しようとすると、TiDB はエラー`Error Number: 8261`報告します。 diff --git a/sql-statements/sql-statement-admin-show-ddl.md b/sql-statements/sql-statement-admin-show-ddl.md index 742ed21e6f504..c6c60ece1be6f 100644 --- a/sql-statements/sql-statement-admin-show-ddl.md +++ b/sql-statements/sql-statement-admin-show-ddl.md @@ -32,10 +32,10 @@ WhereClauseOptional ::= 現在実行中の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)参照してください。 +- `OWNER_ID` : DDL所有者のUUID。[`TIDB_IS_DDL_OWNER()`](/functions-and-operators/tidb-functions.md)もを参照してください。 - `OWNER_ADDRESS` : DDL 所有者の IP アドレス。 - `RUNNING_JOBS` : 実行中の DDL ジョブの詳細。 -- `SELF_ID` : 現在接続しているTiDBノードのUUID。2 `SELF_ID` `OWNER_ID`と同じ場合は、DDL所有者に接続していることを意味します。 +- `SELF_ID` : 現在接続しているTiDBノードのUUID。`SELF_ID` `OWNER_ID`と同じ場合は、DDL所有者に接続していることを意味します。 - `QUERY` : クエリのステートメント。 ```sql @@ -59,7 +59,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 -- `JOB_ID` : 各 DDL 操作は DDL ジョブに対応します。2 `JOB_ID`グローバルに一意です。 +- `JOB_ID` : 各 DDL 操作は DDL ジョブに対応します。`JOB_ID`グローバルに一意です。 - `DB_NAME` : DDL 操作が実行されるデータベースの名前。 - `TABLE_NAME` : DDL 操作が実行されるテーブルの名前。 - `JOB_TYPE` : DDL操作の種類。一般的なジョブの種類は次のとおりです。 @@ -67,9 +67,9 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `create table` : [`CREATE TABLE`](/sql-statements/sql-statement-create-table.md)操作の場合。 - `create view` : [`CREATE VIEW`](/sql-statements/sql-statement-create-view.md)操作の場合。 - `add index` : [`ADD INDEX`](/sql-statements/sql-statement-add-index.md)操作の場合。 -- `SCHEMA_STATE` : DDLが操作するスキーマオブジェクトの現在の状態。2 が`JOB_TYPE` `ADD INDEX`場合はインデックスの状態、 `JOB_TYPE`が`ADD COLUMN`の場合は列の状態、 `JOB_TYPE`が`CREATE TABLE`の場合はテーブルの状態です。一般的な状態には以下が含まれます。 +- `SCHEMA_STATE` : DDLが操作するスキーマオブジェクトの現在の状態。 `JOB_TYPE`が`ADD INDEX`の場合はインデックスの状態、 `JOB_TYPE`が`ADD COLUMN`の場合は列の状態、 `JOB_TYPE`が`CREATE TABLE`の場合はテーブルの状態です。一般的な状態には以下が含まれます。 - `none` : 存在しないことを示します。通常、 `DROP`操作の後、または`CREATE`操作が失敗してロールバックした後、 `none`番目の状態になります。 - - `delete only` `write reorganization`これらの4つの状態は中間状態です。それぞれの具体的な意味については、 [TiDBにおけるオンラインDDL非同期変更の仕組み](/best-practices/ddl-introduction.md#how-the-online-ddl-asynchronous-change-works-in-tidb)参照してください。中間状態の変換`delete reorganization`高速であるため、これらの状態は通常`write only`演算中は表示されません。10 `ADD INDEX`演算を実行する場合にのみ、 `write reorganization`状態が表示され、インデックスデータが追加されていることを示します。 + - `delete only` 、 `write only` 、 `delete reorganization` 、 `write reorganization` : これらの4つの状態は中間状態です。それぞれの具体的な意味については、 [TiDBにおけるオンラインDDL非同期変更の仕組み](/best-practices/ddl-introduction.md#how-the-online-ddl-asynchronous-change-works-in-tidb)を参照してください。中間状態の変換は高速であるため、これらの状態は通常、演算中は表示されません。`ADD INDEX`演算を実行する場合にのみ、 `write reorganization`状態が表示され、インデックスデータが追加されていることを示します。 - `public` : 存在し、ユーザーが利用できることを示します。通常、 `CREATE TABLE`と`ADD INDEX` （または`ADD COLUMN` ）の操作が完了すると、状態は`public`になり、新しく作成されたテーブル、列、およびインデックスが正常に読み書きできることを示します。 - `SCHEMA_ID` : DDL 操作が実行されるデータベースの ID。 - `TABLE_ID` : DDL 操作が実行されるテーブルの ID。 @@ -87,7 +87,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `cancelling` : 操作がキャンセルされていることを示します。この状態は、 [`ADMIN CANCEL DDL JOBS`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルした場合にのみ表示されます。 - `cancelled` : 操作がキャンセルされたことを示します。 - `pausing` : 操作が一時停止されていることを示します。 - - `paused` : 操作が一時停止されていることを示します。この状態は、 [`ADMIN PAUSED DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。4 コマンドを使用して DDL ジョブ[`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)再開できます。 + - `paused` : 操作が一時停止されていることを示します。この状態は、 [`ADMIN PAUSED DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。 [`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)コマンドを使用して DDL ジョブを再開できます。 - `done` : 操作は TiDB 所有者ノードで正常に実行されたが、他の TiDB ノードではこの DDL ジョブによって実行された変更がまだ同期されていないことを示します。 - `COMMENTS` : 診断目的の追加情報が含まれます。 - `ingest` : [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)で構成された高速化されたインデックス バックフィルの追加のためのタスクを取り込みます。 @@ -95,21 +95,21 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `txn-merge` : バックフィルが完了すると元のインデックスとマージされる一時インデックスを使用したトランザクション バックフィル。 - `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`指定することで動的な変更が可能です。 - - `max_write_speed` : インジェストタスクのインポート時のフロー制御。初期値は`tidb_ddl_reorg_max_write_speed`に設定できます。4 による動的な変更`ADMIN ALTER DDL JOBS`サポートされます。 + - `thread` : バックフィルタスクの同時実行数。初期値は`tidb_ddl_reorg_worker_cnt`に設定できます。[`ADMIN ALTER DDL JOBS`](/sql-statements/sql-statement-admin-alter-ddl.md)を指定することで動的な変更が可能です。 + - `batch_size` : バックフィルタスクのバッチサイズ。初期値は`tidb_ddl_reorg_batch_size`に設定できます。`ADMIN ALTER DDL JOBS`を指定することで動的な変更が可能です。 + - `max_write_speed` : インジェストタスクのインポート時のフロー制御。初期値は`tidb_ddl_reorg_max_write_speed`に設定できます。 `ADMIN ALTER DDL JOBS`による動的な変更がサポートされます。 -- `JOB_ID` : 各 DDL 操作は DDL ジョブに対応します。2 `JOB_ID`グローバルに一意です。 +- `JOB_ID` : 各 DDL 操作は DDL ジョブに対応します。`JOB_ID`グローバルに一意です。 - `DB_NAME` : DDL 操作が実行されるデータベースの名前。 - `TABLE_NAME` : DDL 操作が実行されるテーブルの名前。 - `JOB_TYPE` : DDL 操作のタイプ。 -- `SCHEMA_STATE` : DDLが操作するスキーマオブジェクトの現在の状態。2 が`JOB_TYPE` `ADD INDEX`場合はインデックスの状態、 `JOB_TYPE`が`ADD COLUMN`の場合は列の状態、 `JOB_TYPE`が`CREATE TABLE`の場合はテーブルの状態です。一般的な状態には以下が含まれます。 +- `SCHEMA_STATE` : DDLが操作するスキーマオブジェクトの現在の状態。 `JOB_TYPE`が`ADD INDEX`の場合はインデックスの状態、 `JOB_TYPE`が`ADD COLUMN`の場合は列の状態、 `JOB_TYPE`が`CREATE TABLE`の場合はテーブルの状態です。一般的な状態には以下が含まれます。 - `none` : 存在しないことを示します。通常、 `DROP`操作の後、または`CREATE`操作が失敗してロールバックした後、 `none`番目の状態になります。 - - `delete only` `write reorganization`これらの4つの状態は中間状態です。それぞれの具体的な意味については、 [TiDBにおけるオンラインDDL非同期変更の仕組み](https://docs.pingcap.com/tidb/stable/ddl-introduction#how-the-online-ddl-asynchronous-change-works-in-tidb)参照してください。中間状態の変換`delete reorganization`高速であるため、これらの状態は通常`write only`演算中は表示されません。10 `ADD INDEX`演算を実行する場合にのみ、 `write reorganization`状態が表示され、インデックスデータが追加されていることを示します。 + - `delete only` 、 `write only` 、 `delete reorganization` 、 `write reorganization` : これらの4つの状態は中間状態です。それぞれの具体的な意味については、 [TiDBにおけるオンラインDDL非同期変更の仕組み](https://docs.pingcap.com/tidb/stable/ddl-introduction#how-the-online-ddl-asynchronous-change-works-in-tidb)を参照してください。中間状態の変換は高速であるため、これらの状態は通常、演算中は表示されません。`ADD INDEX`演算を実行する場合にのみ、 `write reorganization`状態が表示され、インデックスデータが追加されていることを示します。 - `public` : 存在し、ユーザーが利用できることを示します。通常、 `CREATE TABLE`と`ADD INDEX` （または`ADD COLUMN` ）の操作が完了すると、状態は`public`になり、新しく作成されたテーブル、列、およびインデックスが正常に読み書きできることを示します。 - `SCHEMA_ID` : DDL 操作が実行されるデータベースの ID。 - `TABLE_ID` : DDL 操作が実行されるテーブルの ID。 @@ -122,7 +122,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `rollback done` : 操作が失敗し、ロールバックが完了したことを示します。 - `rollingback` : 操作が失敗し、ロールバック中であることを示します。 - `cancelling` : 操作がキャンセルされていることを示します。この状態は、 [`ADMIN CANCEL DDL JOBS`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルした場合にのみ表示されます。 - - `paused` : 操作が一時停止されていることを示します。この状態は、 [`ADMIN PAUSED DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。4 コマンドを使用して DDL ジョブ[`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)再開できます。 + - `paused` : 操作が一時停止されていることを示します。この状態は、 [`ADMIN PAUSED DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。 [`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)コマンドを使用して DDL ジョブを再開できます。 diff --git a/sql-statements/sql-statement-alter-sequence.md b/sql-statements/sql-statement-alter-sequence.md index c7cefa9b3a366..059cb8d682443 100644 --- a/sql-statements/sql-statement-alter-sequence.md +++ b/sql-statements/sql-statement-alter-sequence.md @@ -52,11 +52,11 @@ ALTER SEQUENCE sequence_name | パラメータ | デフォルト値 | 説明 | | :---------- | :--------------------------- | :---------------------------------------------------------------------------------------------------------------------------------- | | `INCREMENT` | `1` | シーケンスの増分を指定します。正または負の値を指定することで、シーケンスの増加方向を制御できます。 | -| `MINVALUE` | `1`または`-9223372036854775807` | シーケンスの最小値を指定します。1 > `0` `INCREMENT`場合、デフォルト値は`1`です。7 < `0` `INCREMENT`場合、デフォルト値は`-9223372036854775807`です。 | -| `MAXVALUE` | `9223372036854775806`または`-1` | シーケンスの最大値を指定します。1 > `0` `INCREMENT`場合、デフォルト値は`9223372036854775806`です。7 < `0` `INCREMENT`場合、デフォルト値は`-1`です。 | -| `START` | `MINVALUE`または`MAXVALUE` | シーケンスの初期値を指定します。1 > `0` `INCREMENT`場合、デフォルト値は`MINVALUE`です。7 < `0` `INCREMENT`場合、デフォルト値は`MAXVALUE`です。 | +| `MINVALUE` | `1`または`-9223372036854775807` | シーケンスの最小値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`1`です。`INCREMENT` < `0`の場合、デフォルト値は`-9223372036854775807`です。 | +| `MAXVALUE` | `9223372036854775806`または`-1` | シーケンスの最大値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`9223372036854775806`です。`INCREMENT` < `0`の場合、デフォルト値は`-1`です。 | +| `START` | `MINVALUE`または`MAXVALUE` | シーケンスの初期値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | | `CACHE` | `1000` | TiDB 内のシーケンスのローカル キャッシュ サイズを指定します。 | -| `CYCLE` | `NO CYCLE` | シーケンスを最小値（降順シーケンスの場合は最大値）から再開するかどうかを指定します。1 > `0` `INCREMENT` 、デフォルト値は`MINVALUE`です。7 < `INCREMENT` `0`場合、デフォルト値は`MAXVALUE`です。 | +| `CYCLE` | `NO CYCLE` | シーケンスを最小値（降順シーケンスの場合は最大値）から再開するかどうかを指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | > **Note:** > @@ -68,7 +68,7 @@ ALTER SEQUENCE sequence_name - `NEXTVAL`または`NEXT VALUE FOR` - 基本的に、どちらもシーケンスオブジェクトの次の有効な値を取得する`NEXTVAL()`関数です。3 `NEXTVAL()`の関数の引数は、シーケンスの`identifier`の値です。 + 基本的に、どちらもシーケンスオブジェクトの次の有効な値を取得する`NEXTVAL()`関数です。`NEXTVAL()`の関数の引数は、シーケンスの`identifier`の値です。 - `LASTVAL` diff --git a/sql-statements/sql-statement-alter-table-compact.md b/sql-statements/sql-statement-alter-table-compact.md index 696f30812bbcc..a4726261bff42 100644 --- a/sql-statements/sql-statement-alter-table-compact.md +++ b/sql-statements/sql-statement-alter-table-compact.md @@ -5,7 +5,7 @@ summary: TiDB データベースの ALTER TABLE ... COMPACT の使用法の概 # ALTER TABLE ... COMPACT {#alter-table-compact} -読み取りパフォーマンスを向上させ、ディスク使用量を削減するために、TiDB はストレージノード上でバックグラウンドでデータ圧縮を自動的にスケジュールします。圧縮中、ストレージノードは物理データを書き換えます。これには、削除された行のクリーンアップや、更新によって発生した複数のデータバージョンのマージなどが含まれます。1 ステートメントを使用すると、 `ALTER TABLE ... COMPACT`グラウンドで圧縮がトリガーされるまで待たずに、特定のテーブルの圧縮を即座に開始できます。 +読み取りパフォーマンスを向上させ、ディスク使用量を削減するために、TiDB はストレージノード上でバックグラウンドでデータ圧縮を自動的にスケジュールします。圧縮中、ストレージノードは物理データを書き換えます。これには、削除された行のクリーンアップや、更新によって発生した複数のデータバージョンのマージなどが含まれます。 `ALTER TABLE ... COMPACT`ステートメントを使用すると、バックグラウンドで圧縮がトリガーされるまで待たずに、特定のテーブルの圧縮を即座に開始できます。 この文を実行しても、既存のSQL文はブロックされず、トランザクション、DDL、GCといったTiDBの機能にも影響はありません。SQL文で選択可能なデータも変更されません。この文の実行は、IOリソースとCPUリソースを消費します。業務への悪影響を避けるため、リソースに余裕があるタイミングなど、適切なタイミングで実行するようご注意ください。 @@ -89,7 +89,7 @@ ALTER TABLE employees COMPACT PARTITION pNorth, pEast TIFLASH REPLICA; ## データ圧縮の進行状況を観察する {#observe-data-compaction-progress} -`INFORMATION_SCHEMA.TIFLASH_TABLES`テーブルの`TOTAL_DELTA_ROWS`列を確認することで、データ圧縮の進行状況を確認したり、テーブルの圧縮を開始するかどうかを判断したりできます`TOTAL_DELTA_ROWS`の値が大きいほど、圧縮できるデータ量が多くなります。7 が`TOTAL_DELTA_ROWS` `0`場合、テーブル内のすべてのデータは最適な状態であり、圧縮する必要はありません。 +`INFORMATION_SCHEMA.TIFLASH_TABLES`テーブルの`TOTAL_DELTA_ROWS`列を確認することで、データ圧縮の進行状況を確認したり、テーブルの圧縮を開始するかどうかを判断したりできます`TOTAL_DELTA_ROWS`の値が大きいほど、圧縮できるデータ量が多くなります。 `TOTAL_DELTA_ROWS`が`0`の場合、テーブル内のすべてのデータは最適な状態であり、圧縮する必要はありません。
    例:パーティションテーブルの圧縮状態を確認する diff --git a/sql-statements/sql-statement-alter-table.md b/sql-statements/sql-statement-alter-table.md index a2dea678f684a..094f8a9892ff7 100644 --- a/sql-statements/sql-statement-alter-table.md +++ b/sql-statements/sql-statement-alter-table.md @@ -95,7 +95,7 @@ EXPLAIN SELECT * FROM t1 WHERE c1 = 3; 3 rows in set (0.00 sec) ``` -ステートメント[`ALTER TABLE .. ADD INDEX`](/sql-statements/sql-statement-add-index.md)は、テーブル t1 にインデックスを追加するために使用できます。3 `EXPLAIN`元のクエリでインデックス範囲スキャンが使用されるようになり、より効率的になっていることを確認します。 +ステートメント[`ALTER TABLE .. ADD INDEX`](/sql-statements/sql-statement-add-index.md)は、テーブル t1 にインデックスを追加するために使用できます。`EXPLAIN`元のクエリでインデックス範囲スキャンが使用されるようになり、より効率的になっていることを確認します。 ```sql ALTER TABLE t1 ADD INDEX (c1); diff --git a/sql-statements/sql-statement-calibrate-resource.md b/sql-statements/sql-statement-calibrate-resource.md index f0a128744281c..985e5988a0661 100644 --- a/sql-statements/sql-statement-calibrate-resource.md +++ b/sql-statements/sql-statement-calibrate-resource.md @@ -55,7 +55,7 @@ TiDB は推定に 2 つの方法を提供します。 - `OLTP_WRITE_ONLY` : 大量のデータ書き込みを伴うワークロードに適用されます。これは`sysbench oltp_write_only`と同様のワークロードモデルに基づいて推定されます。 - `OLTP_READ_WRITE` : データの読み取りと書き込みが均等なワークロードに適用されます。これは`sysbench oltp_read_write`と同様のワークロードモデルに基づいて推定されます。 - `OLTP_READ_ONLY` : 大量のデータ読み取りを伴うワークロードに適用されます。これは`sysbench oltp_read_only`と同様のワークロードモデルに基づいて推定されます。 -- `TPCH_10` : APクエリに適用されます。2 からの`TPCH-10G`のクエリに基づいて推定されます。 +- `TPCH_10` : APクエリに適用されます。 `TPCH-10G`からの22個のクエリに基づいて推定されます。 > **Note:** > diff --git a/sql-statements/sql-statement-create-sequence.md b/sql-statements/sql-statement-create-sequence.md index bf4d09fac7f7a..839382400c217 100644 --- a/sql-statements/sql-statement-create-sequence.md +++ b/sql-statements/sql-statement-create-sequence.md @@ -55,11 +55,11 @@ CREATE [TEMPORARY] SEQUENCE [IF NOT EXISTS] sequence_name | :---------- | :--------------------------- | :---------------------------------------------------------------------------------------------------------------------------------- | | `TEMPORARY` | `false` | TiDB は現在`TEMPORARY`オプションをサポートしておらず、構文の互換性のみを提供しています。 | | `INCREMENT` | `1` | シーケンスの増分を指定します。正または負の値を指定することで、シーケンスの増加方向を制御できます。 | -| `MINVALUE` | `1`または`-9223372036854775807` | シーケンスの最小値を指定します。1 > `0` `INCREMENT`場合、デフォルト値は`1`です。7 < `0` `INCREMENT`場合、デフォルト値は`-9223372036854775807`です。 | -| `MAXVALUE` | `9223372036854775806`または`-1` | シーケンスの最大値を指定します。1 > `0` `INCREMENT`場合、デフォルト値は`9223372036854775806`です。7 < `0` `INCREMENT`場合、デフォルト値は`-1`です。 | -| `START` | `MINVALUE`または`MAXVALUE` | シーケンスの初期値を指定します。1 > `0` `INCREMENT`場合、デフォルト値は`MINVALUE`です。7 < `0` `INCREMENT`場合、デフォルト値は`MAXVALUE`です。 | +| `MINVALUE` | `1`または`-9223372036854775807` | シーケンスの最小値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`1`です。`INCREMENT` < `0`の場合、デフォルト値は`-9223372036854775807`です。 | +| `MAXVALUE` | `9223372036854775806`または`-1` | シーケンスの最大値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`9223372036854775806`です。`INCREMENT` < `0`の場合、デフォルト値は`-1`です。 | +| `START` | `MINVALUE`または`MAXVALUE` | シーケンスの初期値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | | `CACHE` | `1000` | TiDB 内のシーケンスのローカル キャッシュ サイズを指定します。 | -| `CYCLE` | `NO CYCLE` | シーケンスを最小値（降順シーケンスの場合は最大値）から再開するかどうかを指定します。1 > `0` `INCREMENT` 、デフォルト値は`MINVALUE`です。7 < `INCREMENT` `0`場合、デフォルト値は`MAXVALUE`です。 | +| `CYCLE` | `NO CYCLE` | シーケンスを最小値（降順シーケンスの場合は最大値）から再開するかどうかを指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | ## SEQUENCE関数 {#code-sequence-code-function} @@ -67,7 +67,7 @@ CREATE [TEMPORARY] SEQUENCE [IF NOT EXISTS] sequence_name - `NEXTVAL`または`NEXT VALUE FOR` - 基本的に、どちらもシーケンスオブジェクトの次の有効な値を取得する`NEXTVAL()`関数です。3 `NEXTVAL()`の関数の引数は、シーケンスの`identifier`の値です。 + 基本的に、どちらもシーケンスオブジェクトの次の有効な値を取得する`NEXTVAL()`関数です。`NEXTVAL()`の関数の引数は、シーケンスの`identifier`の値です。 - `LASTVAL` diff --git a/sql-statements/sql-statement-create-view.md b/sql-statements/sql-statement-create-view.md index 58a50bf7445df..f151048e793b7 100644 --- a/sql-statements/sql-statement-create-view.md +++ b/sql-statements/sql-statement-create-view.md @@ -89,8 +89,8 @@ ERROR 1105 (HY000): insert into view v1 is not supported now. ## MySQLの互換性 {#mysql-compatibility} -- 現在、TiDB 内のどのビューも挿入または更新できません (つまり、 `INSERT VIEW`と`UPDATE VIEW`サポートされていません)。5 `WITH CHECK OPTION`構文的に互換性があるだけで、有効ではありません。 -- 現在、TiDB のビューは`ALTER VIEW`サポートしていませんが、代わりに`CREATE OR REPLACE`使用できます。 +- 現在、TiDB 内のどのビューも挿入または更新できません (つまり、 `INSERT VIEW`と`UPDATE VIEW`サポートされていません)。`WITH CHECK OPTION`構文的に互換性があるだけで、有効ではありません。 +- 現在、TiDB のビューは`ALTER VIEW`をサポートしていませんが、代わりに`CREATE OR REPLACE`を使用できます。 - 現在、 `ALGORITHM`フィールドは TiDB において構文的に互換性があるものの、効果がありません。TiDB は現在 MERGE アルゴリズムのみをサポートしています。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-do.md b/sql-statements/sql-statement-do.md index 4bf4fc3c5a13c..ae4caf5f8930c 100644 --- a/sql-statements/sql-statement-do.md +++ b/sql-statements/sql-statement-do.md @@ -9,7 +9,7 @@ summary: TiDB データベースにおける DO の使用法の概要。 > **Note:** > -> `DO`式のみを実行します。2 `SELECT`使用できるすべてのケースで使用できるわけではありません。例えば、 `DO id FROM t1`テーブルを参照するため無効です。 +> `DO`式のみを実行します。`SELECT`を使用できるすべてのケースで使用できるわけではありません。例えば、 `DO id FROM t1`は、テーブルを参照するため無効です。 MySQLでは、ストアドプロシージャやトリガーの実行が一般的なユースケースです。TiDBはストアドプロシージャやトリガーを提供していないため、この機能の用途は限定されます。 @@ -53,7 +53,7 @@ Query OK, 0 rows affected (2.50 sec) ## MySQLの互換性 {#mysql-compatibility} -TiDBの`DO`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`DO`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-drop-index.md b/sql-statements/sql-statement-drop-index.md index 784e8a43dbddf..6ea746e30ee02 100644 --- a/sql-statements/sql-statement-drop-index.md +++ b/sql-statements/sql-statement-drop-index.md @@ -58,7 +58,7 @@ Query OK, 0 rows affected (0.30 sec) ## MySQLの互換性 {#mysql-compatibility} -- `CLUSTERED`型`CLUSTERED`主キーの削除はサポートされていません。3 型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 +- `CLUSTERED`型の主キーの削除はサポートされていません。 `CLUSTERED`型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-explain-analyze.md b/sql-statements/sql-statement-explain-analyze.md index 70830347fcc0b..2339c29cfa606 100644 --- a/sql-statements/sql-statement-explain-analyze.md +++ b/sql-statements/sql-statement-explain-analyze.md @@ -38,7 +38,7 @@ ExplainableStmt ::= | 属性名 | 説明 | | :----- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | アクトロウズ | 演算子によって出力される行数。 | -| 実行情報 | 演算子の実行情報。1 `time`演算子に入ってから演算子を出るまでの合計`wall time`表します。これには、すべてのサブ演算子の合計実行時間が含まれます。演算子が親演算子（ループ内）によって何度も呼び出される場合は、その累積時間を参照します。5 `loops` 、現在の演算子が親演算子によって呼び出された回数です。 | +| 実行情報 | 演算子の実行情報。`time`演算子に入ってから演算子を出るまでの合計`wall time`表します。これには、すべてのサブ演算子の合計実行時間が含まれます。演算子が親演算子（ループ内）によって何度も呼び出される場合は、その累積時間を参照します。`loops` 、現在の演算子が親演算子によって呼び出された回数です。 | | メモリ | 演算子によって占有されるメモリ領域。 | | ディスク | オペレータが占有するディスク領域。 | @@ -160,7 +160,7 @@ EXPLAIN ANALYZE SELECT * FROM t1; ### IndexHashJoin {#indexhashjoin} -`IndexHashJoin`演算子の実行プロセスは`IndexJoin`演算子と同様です。5演算`IndexHashJoin`も1つの外部ワーカーとN個の内部ワーカーで並列実行されますが、出力順序は外部テーブルと一致するとは限りません。詳細な実行プロセスは以下のとおりです。 +`IndexHashJoin`演算子の実行プロセスは`IndexJoin`演算子と同様です。`IndexHashJoin`演算子も1つの外部ワーカーとN個の内部ワーカーで並列実行されますが、出力順序は外部テーブルと一致するとは限りません。詳細な実行プロセスは以下のとおりです。 1. 外側のワーカーは N 個の外側の行を読み取り、タスクを構築して、それを内側のワーカー チャネルに送信します。 2. 内部ワーカーは内部ワーカーチャネルからタスクを受け取り、各タスクに対して以下の3つの操作を順番に実行します。a. 外部行からハッシュテーブルを構築する。b. 外部行からキー範囲を構築し、内部行を取得する。c. ハッシュテーブルをプローブし、結合結果を結果チャネルに送信する。注：ステップaとステップbは同時に実行されます。 @@ -226,7 +226,7 @@ tiflash_scan: { - `dtfile` : テーブル スキャン中の DTFile (DeltaTree ファイル) 関連情報。TiFlashレイヤーのデータ スキャン ステータスを反映します。 - `total_scanned_packs` : DTFileでスキャンされたパックの総数。パックとは、 TiFlash DTFileで読み取ることができる最小単位です。デフォルトでは、8192行ごとに1パックが構成されます。 - - `total_skipped_packs` : DTFile 内のスキャンでスキップされたパックの総数。2 `WHERE`が粗集合インデックスにヒットするか、主キーの範囲フィルタリングに一致する場合、無関係なパックはスキップされます。 + - `total_skipped_packs` : DTFile 内のスキャンでスキップされたパックの総数。`WHERE`が粗集合インデックスにヒットするか、主キーの範囲フィルタリングに一致する場合、無関係なパックはスキップされます。 - `total_scanned_rows` : DTFile でスキャンされた行の総数。MVCC により更新または削除のバージョンが複数ある場合、各バージョンは個別にカウントされます。 - `total_skipped_rows` : DTFile 内のスキャンによってスキップされる行の合計数。 - `total_rs_index_load_time` : DTFile のラフ セット インデックスの読み取りに費やされた合計時間。 @@ -313,7 +313,7 @@ TiDB v7.1 を使用している場合、計算は`pd/pd-client/model.go`の`Befo ### その他の一般的な実行情報 {#other-common-execution-information} -コプロセッサーオペレータには通常、実行時間情報の2つの部分、 `cop_task`と`tikv_task`含まれます。5 `cop_task` TiDBによって記録された時間で、リクエストがサーバーに送信されてからレスポンスが受信されるまでの時間です。7 `tikv_task` TiKVコプロセッサー自体によって記録された時間です。この2つの値に大きな差がある場合は、レスポンスの待機時間が長すぎるか、gRPCまたはネットワークで費やされた時間が長すぎることを示している可能性があります。 +コプロセッサーオペレータには通常、実行時間情報の2つの部分、 `cop_task`と`tikv_task`含まれます。`cop_task` TiDBによって記録された時間で、リクエストがサーバーに送信されてからレスポンスが受信されるまでの時間です。`tikv_task` TiKVコプロセッサー自体によって記録された時間です。この2つの値に大きな差がある場合は、レスポンスの待機時間が長すぎるか、gRPCまたはネットワークで費やされた時間が長すぎることを示している可能性があります。 ## MySQLの互換性 {#mysql-compatibility} diff --git a/sql-statements/sql-statement-explain.md b/sql-statements/sql-statement-explain.md index e35f5f3a2f825..78167b6e9e2d5 100644 --- a/sql-statements/sql-statement-explain.md +++ b/sql-statements/sql-statement-explain.md @@ -5,11 +5,11 @@ summary: TiDB データベースにおけるEXPLAINの使用法の概要。 # `EXPLAIN` {#explain} -`EXPLAIN`の文は、クエリを実行せずにその実行プランを表示します。これは、クエリを実行する`EXPLAIN ANALYZE`の文を補完するものです。5 `EXPLAIN`出力が期待される結果と一致しない場合は、クエリ内の各テーブルに対して`ANALYZE TABLE`実行して、テーブル統計が最新であることを確認することを検討してください。 +`EXPLAIN`文は、クエリを実行せずにその実行プランを表示します。これは、クエリを実行する`EXPLAIN ANALYZE`文を補完するものです。`EXPLAIN`出力が期待される結果と一致しない場合は、クエリ内の各テーブルに対して`ANALYZE TABLE`を実行して、テーブル統計が最新であることを確認することを検討してください。 > **Note:** > -> 最適化フェーズでは、 `EXPLAIN`文であっても、最適な実行プランを生成するために特定のサブクエリが事前実行されます。この動作の詳細と無効化方法については、 [`tidb_opt_enable_non_eval_scalar_subquery`](/system-variables.md#tidb_opt_enable_non_eval_scalar_subquery-new-in-v730)および[サブクエリの早期実行を無効にする](/explain-walkthrough.md#disable-the-early-execution-of-subqueries)参照してください。 +> 最適化フェーズでは、 `EXPLAIN`文であっても、最適な実行プランを生成するために特定のサブクエリが事前実行されます。この動作の詳細と無効化方法については、 [`tidb_opt_enable_non_eval_scalar_subquery`](/system-variables.md#tidb_opt_enable_non_eval_scalar_subquery-new-in-v730)および[サブクエリの早期実行を無効にする](/explain-walkthrough.md#disable-the-early-execution-of-subqueries)を参照してください。 `DESC`文と`DESCRIBE`文は`EXPLAIN`の別名です。文`EXPLAIN `の代替使用法については[`SHOW [FULL] COLUMNS FROM`](/sql-statements/sql-statement-show-columns-from.md)に記載されています。 @@ -39,18 +39,18 @@ ExplainableStmt ::= > **Note:** > -> MySQLクライアントを使用してTiDBに接続する場合、出力結果を行の折り返しなしでより明確に読み取るには、 `pager less -S`コマンドを使用します。3 `EXPLAIN`結果が出力された後、キーボードの右矢印→キーを押して出力を水平にスクロールします。 +> MySQLクライアントを使用してTiDBに接続する場合、出力結果を行の折り返しなしでより明確に読み取るには、 `pager less -S`コマンドを使用します。`EXPLAIN`結果が出力された後、キーボードの右矢印→キーを押して出力を水平にスクロールします。 > **Note:** > > 返される実行プランにおいて、 `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`、`task`、`access object`、`operator info`）を出力します。実行プラン内の各演算子はこれらの属性によって記述され、`EXPLAIN`出力の各行が演算子を記述します。各属性の説明は次のとおりです。 | 属性名 | 説明 | | :--------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | id | オペレータIDは、実行プラン全体におけるオペレータの一意の識別子です。TiDB 2.1では、このIDはオペレータのツリー構造を表すようにフォーマットされています。データは子ノードから親ノードへと流れます。オペレータごとに親ノードは1つだけです。 | -| estRows | 演算子が出力すると予想される行数。この数は、統計情報と演算子のロジックに基づいて推定されます。1 `estRows` 、TiDB 4.0 の以前のバージョンでは`count`呼ばれていました。 | +| estRows | 演算子が出力すると予想される行数。この数は、統計情報と演算子のロジックに基づいて推定されます。`estRows` 、TiDB 4.0 の以前のバージョンでは`count`呼ばれていました。 | | タスク | オペレータが属するタスクの種類。現在、実行プランは tidb-server 上で実行される**ルート**タスクと、 TiKV またはTiFlash上で並列実行される**cop**タスクの2つのタスクに分かれています。タスクレベルでの実行プランのトポロジは、ルートタスクの後に多数の cop タスクが続くというものです。ルートタスクは cop タスクの出力を入力として使用します。cop タスクとは、TiDB が TiKV またはTiFlashにプッシュダウンするタスクを指します。各 cop タスクは TiKV クラスターまたはTiFlashクラスターに分散され、複数のプロセスによって実行されます。 | | アクセスオブジェクト | オペレータがアクセスするデータ項目情報。この情報には、 `table` 、および`index` （存在する場合） `partition`含まれます。この情報は、データに直接アクセスするオペレータのみが使用できます。 | | オペレーター情報 | 演算子に関するその他の情報。演算子ごとに`operator info`異なります。以下の例を参照してください。 | @@ -176,12 +176,12 @@ EXPLAIN DELETE FROM t1 WHERE c1=3; | 形式 | 説明 | | ------------ | ------------------------------------------------------------------------------------------------------------------------- | -| 指定されていない | 形式が指定されていない場合は、デフォルトの形式`EXPLAIN` `row`使用されます。 | -| `brief` | `EXPLAIN`ステートメントの出力の演算子 ID は、 `FORMAT`指定されていない場合に比べて簡素化されます。 | +| 指定されていない | 形式が指定されていない場合、 `EXPLAIN`はデフォルトの形式`row`を使用します。 | +| `brief` | `EXPLAIN`ステートメントの出力の演算子 ID は、 `FORMAT`が指定されていない場合に比べて簡素化されます。 | | `dot` | `EXPLAIN`ステートメントは DOT 実行プランを出力します。これを使用して、 `dot`プログラム ( `graphviz`パッケージ内) を通じて PNG ファイルを生成することができます。 | -| `row` | `EXPLAIN`文は結果を表形式で出力します。詳細については[クエリ実行プランを理解する](/explain-overview.md)参照してください。 | +| `row` | `EXPLAIN`文は結果を表形式で出力します。詳細については[クエリ実行プランを理解する](/explain-overview.md)を参照してください。 | | `tidb_json` | `EXPLAIN`ステートメントは実行プランを JSON 形式で出力し、演算子情報を JSON 配列に格納します。 | -| `verbose` | `EXPLAIN`文は`row`形式で結果を出力し、さらに`estCost`列にクエリの推定コストが表示されます。この形式の使用方法の詳細については、 [SQLプラン管理](/sql-plan-management.md)参照してください。 | +| `verbose` | `EXPLAIN`文は`row`形式で結果を出力し、さらに`estCost`列にクエリの推定コストが表示されます。この形式の使用方法の詳細については、 [SQLプラン管理](/sql-plan-management.md)を参照してください。 | | `plan_cache` | `EXPLAIN`ステートメントは、 [プランキャッシュ](/sql-non-prepared-plan-cache.md#diagnostics)情報を警告として含めて、 `row`形式で結果を出力します。 | | `cost_trace` | `EXPLAIN`ステートメントは、推定コストの`estCost`とコストの計算式の`costFormula`列の 2 つの追加列を含む拡張`row`形式で結果を出力します。 | @@ -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..6bab1c14e6b48 100644 --- a/sql-statements/sql-statement-flashback-database.md +++ b/sql-statements/sql-statement-flashback-database.md @@ -34,7 +34,7 @@ FlashbackToNewName ::= - `tikv_gc_safe_point`回目より前にデータベースが削除された場合、 `FLASHBACK DATABASE`ステートメントを使用してデータを復元することはできません。`FLASHBACK DATABASE`のステートメントは`ERROR 1105 (HY000): Can't find dropped database 'test' in GC safe point 2022-11-06 16:10:10 +0800 CST`と同様のエラーを返します。 -- `FLASHBACK DATABASE`ステートメントを使用して、同じデータベースを複数回リストアすることはできません。3 でリストアされ`FLASHBACK DATABASE`データベースは元のデータベースと同じスキーマ ID を持つため、同じデータベースを複数回リストアするとスキーマ ID が重複します。TiDB では、データベースのスキーマ ID はグローバルに一意である必要があります。 +- `FLASHBACK DATABASE`ステートメントを使用して、同じデータベースを複数回リストアすることはできません。 `FLASHBACK DATABASE`でリストアされたデータベースは元のデータベースと同じスキーマ ID を持つため、同じデータベースを複数回リストアするとスキーマ ID が重複します。TiDB では、データベースのスキーマ ID はグローバルに一意である必要があります。 ## 例 {#example} diff --git a/sql-statements/sql-statement-flashback-table.md b/sql-statements/sql-statement-flashback-table.md index a2ad760a6c8ae..efdb5363fb693 100644 --- a/sql-statements/sql-statement-flashback-table.md +++ b/sql-statements/sql-statement-flashback-table.md @@ -69,7 +69,7 @@ FlashbackToNewName ::= `FLASHBACK TABLE t TO t1`の作業工程は以下のとおりです。 1. TiDBは最近のDDL履歴ジョブを検索し、テーブル`t`で最初のDDL操作（タイプ`DROP TABLE`またはタイプ`truncate table`を見つけます。TiDBが見つけられなかった場合は、エラーが返されます。 -2. TiDBは、DDLジョブの開始時刻が`tikv_gc_safe_point`より前かどうかを確認します。3 `tikv_gc_safe_point`前の場合、 `DROP`または`TRUNCATE`操作で削除されたテーブルがGCによってクリーンアップされたことを意味し、エラーが返されます。 +2. TiDBは、DDLジョブの開始時刻が`tikv_gc_safe_point`より前かどうかを確認します。`tikv_gc_safe_point`前の場合、 `DROP`または`TRUNCATE`操作で削除されたテーブルがGCによってクリーンアップされたことを意味し、エラーが返されます。 3. TiDB は、DDL ジョブの開始時刻をスナップショットとして使用して、履歴データを読み取り、テーブル メタデータを読み取ります。 4. TiDB は`mysql.gc_delete_range`のテーブル`t`に関連する GC タスクを削除します。 5. TiDBはテーブルのメタデータの`name` `t1`に変更し、このメタデータを使用して新しいテーブルを作成します。テーブル名のみが変更され、テーブルIDは変更されないことに注意してください。テーブルIDは、以前に削除されたテーブル`t`と同じです。 diff --git a/sql-statements/sql-statement-import-into.md b/sql-statements/sql-statement-import-into.md index 2165456952383..43932b60e779e 100644 --- a/sql-statements/sql-statement-import-into.md +++ b/sql-statements/sql-statement-import-into.md @@ -283,7 +283,7 @@ IMPORT INTO t(id, name, @1) FROM '/path/to/file.csv' WITH skip_rows=1; #### ワイルドカードを使用して複数のデータファイルをインポートする {#import-multiple-data-files-using-wildcards} -`file-01.csv`ディレクトリに`file-02.csv` 、 `file-03.csv` 、 `/path/to/` -PLACEHOLDER-E}} という名前のファイルが 3 つあるとします。これらの 3 つのファイルを`t`を使用してターゲット テーブル`IMPORT INTO`にインポートするには、次の SQL ステートメントを実行します。 +`/path/to/`ディレクトリに`file-01.csv` 、 `file-02.csv` 、 `file-03.csv`という名前のファイルが 3 つあるとします。これらの 3 つのファイルを`IMPORT INTO`を使用してターゲット テーブル`t`にインポートするには、次の SQL ステートメントを実行します。 ```sql IMPORT INTO t FROM '/path/to/file-*.csv'; 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 b6a65a0b62532..a583f93e67eb9 100644 --- a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md +++ b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md @@ -13,9 +13,9 @@ TiDBでは、クライアントセッションがテーブルロックを取得 `LOCK TABLES` 、現在のクライアントセッションのテーブルロックを取得します。ロック対象となる各オブジェクトに対して`LOCK TABLES`および`SELECT`権限を持っている場合は、共通テーブルのテーブルロックを取得できます。 -`UNLOCK TABLES` 、現在のセッションによって保持されているすべてのテーブル ロックを明示的に解放します。2 `LOCK TABLES` 、新しいロックを取得する前に、現在のセッションによって保持されているすべてのテーブル ロックを暗黙的に解放します。 +`UNLOCK TABLES` 、現在のセッションによって保持されているすべてのテーブル ロックを明示的に解放します。`LOCK TABLES` 、新しいロックを取得する前に、現在のセッションによって保持されているすべてのテーブル ロックを暗黙的に解放します。 -テーブルロックは、他のセッションによる読み取りや書き込みから保護します。1 ロックを保持しているセッションは、 `WRITE`や`TRUNCATE TABLE` `DROP TABLE`のテーブルレベルの操作を実行できます。 +テーブルロックは、他のセッションによる読み取りや書き込みから保護します。 `WRITE`ロックを保持しているセッションは、 `DROP TABLE`や`TRUNCATE TABLE`などのテーブルレベルの操作を実行できます。 > **Note:** > diff --git a/sql-statements/sql-statement-savepoint.md b/sql-statements/sql-statement-savepoint.md index c177fc91053e2..a2c55d5c1e5e5 100644 --- a/sql-statements/sql-statement-savepoint.md +++ b/sql-statements/sql-statement-savepoint.md @@ -122,7 +122,7 @@ ROLLBACK TO SAVEPOINT sp1; Query OK, 0 rows affected (0.01 sec) ``` -トランザクションをコミットし、テーブルをクエリします。1 `sp1`前に挿入されたデータのみが返されます。 +トランザクションをコミットし、テーブルをクエリします。`sp1`の前に挿入されたデータのみが返されます。 ```sql COMMIT; diff --git a/sql-statements/sql-statement-show-analyze-status.md b/sql-statements/sql-statement-show-analyze-status.md index 2c256fc9b0c65..a1906002a92d5 100644 --- a/sql-statements/sql-statement-show-analyze-status.md +++ b/sql-statements/sql-statement-show-analyze-status.md @@ -20,7 +20,7 @@ TiDB v7.3.0 以降では、システム テーブル`mysql.analyze_jobs`また | `Table_schema` | データベース名 | | `Table_name` | テーブル名 | | `Partition_name` | パーティション名 | -| `Job_info` | タスク情報。インデックスが分析される場合、この情報にはインデックス名が含まれます。1 `tidb_analyze_version =2`場合、この情報にはサンプルレートなどの設定項目が含まれます。 | +| `Job_info` | タスク情報。インデックスが分析される場合、この情報にはインデックス名が含まれます。`tidb_analyze_version =2`の場合、この情報にはサンプルレートなどの設定項目が含まれます。 | | `Processed_rows` | 分析された行数 | | `Start_time` | タスクが開始される時間 | | `State` | タスクの状態`failed` `pending` `finished`含む`running` | diff --git a/sql-statements/sql-statement-truncate.md b/sql-statements/sql-statement-truncate.md index 7b94a0e2e3707..51991701395b0 100644 --- a/sql-statements/sql-statement-truncate.md +++ b/sql-statements/sql-statement-truncate.md @@ -5,7 +5,7 @@ summary: TiDB データベースにおける TRUNCATE の使用法の概要。 # TRUNCATE {#truncate} -`TRUNCATE`ステートメントは、非トランザクション方式でテーブルからすべてのデータを削除します。3 `TRUNCATE` 、前の定義の`DROP TABLE` + `CREATE TABLE`と意味的に同じであると考えることができます。 +`TRUNCATE`ステートメントは、非トランザクション方式でテーブルからすべてのデータを削除します。`TRUNCATE` 、前の定義の`DROP TABLE` + `CREATE TABLE`と意味的に同じであると考えることができます。 `TRUNCATE TABLE tableName`と`TRUNCATE tableName`どちらも有効な構文です。 diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index 9e5140d35fe3f..97c3230288d03 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -161,7 +161,7 @@ PLAN REPLAYER DUMP EXPLAIN [ANALYZE] [WITH STATS AS OF TIMESTAMP expression] sql 上の図では、プロトコルレイヤーの右側に TiDBサーバーのオプティマイザーがあり、次のように SQL ステートメントを処理します。 1. SQL ステートメントはプロトコルレイヤーを介して SQL オプティマイザーに到達し、抽象構文ツリー (AST) に解析されます。 -2. TiDBは、それが[ポイントゲット](/explain-indexes.md#point_get-and-batch_point_get)文であるかどうかを識別します。1文は、 `SELECT * FROM t WHERE pk_col = 1`や`SELECT * FROM t WHERE uk_col IN (1,2,3)`などの主キーまたは一意キーを介した単純な1テーブル検索です。7 `Point Get`の場合、TiDBは後続の最適化手順をスキップし、SQLエグゼキュータで直接実行します。 +2. TiDBは、それが[ポイントゲット](/explain-indexes.md#point_get-and-batch_point_get)文であるかどうかを識別します。この文は、 `SELECT * FROM t WHERE pk_col = 1`や`SELECT * FROM t WHERE uk_col IN (1,2,3)`などの主キーまたは一意キーを介した単純な1テーブル検索です。`Point Get`の場合、TiDBは後続の最適化手順をスキップし、SQLエグゼキュータで直接実行します。 3. クエリが`Point Get`でない場合、AST は論理変換され、TiDB は特定のルールに基づいて SQL を論理的に書き換えます。 4. 論理変換後、TiDB はコストベースの最適化を通じて AST を処理します。 5. コストベースの最適化では、オプティマイザーは統計を使用して適切な演算子を選択し、物理的な実行プランを生成します。 @@ -343,7 +343,7 @@ EXPLAIN SELECT COUNT(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00 `EXPLAIN ANALYZE`出力には以下が含まれます。 - `actRows` : 演算子によって出力される行数。 -- `execution info` : オペレータの詳細な実行情報。2 `time` 、すべてのサブオペレータの合計実行時間を含む合計`wall time`表します。オペレータが親オペレータによって何度も呼び出される場合、時間は累積時間を参照します。 +- `execution info` : オペレータの詳細な実行情報。`time` 、すべてのサブオペレータの合計実行時間を含む合計`wall time`表します。オペレータが親オペレータによって何度も呼び出される場合、時間は累積時間を参照します。 - `memory` : 演算子によって使用されるメモリ。 - `disk` : オペレータが使用するディスク容量。 @@ -418,7 +418,7 @@ EXPLAIN SELECT COUNT(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00 次の例では、プランツリーの最初のリーフノードである`IndexRangeScan_47`調べることから始めます。オプティマイザは、 `stars`テーブルから`name`と`id`列のみを選択します。これらの列は`name(name)`インデックスから取得できます。その結果、 `stars`のルートリーダーは`IndexReader_48`ではなく`TableReader`なります。 -`stars`と`planets`の結合はハッシュ結合です（ `HashJoin_44` ）。7 `planets`テーブルはフルテーブルスキャン（ `TableFullScan_45` ）を使用してアクセスされます。結合後、 `TopN_26`と`TopN_19`それぞれ`ORDER BY`と`LIMIT`句を適用します。最後の演算子`Projection_16` 、最後の列`t5.name`選択します。 +`stars`と`planets`の結合はハッシュ結合です（ `HashJoin_44` ）。`planets`テーブルはフルテーブルスキャン（ `TableFullScan_45` ）を使用してアクセスされます。結合後、 `TopN_26`と`TopN_19`それぞれ`ORDER BY`と`LIMIT`句を適用します。最後の演算子`Projection_16` 、最後の列`t5.name`選択します。 ```sql EXPLAIN @@ -481,13 +481,13 @@ LIMIT 3; - 推定精度を評価するには、 `actRows`と`estRows`を比較します。 - 実行時間の長さやその他のメトリックなど、 `execution info`の詳細なメトリックを分析します。 - 潜在的なリソース制約について、 `memory`と`disk`使用状況を確認します。 -3. これらの要因を相関させることで、パフォーマンス問題の根本原因を特定できます。例えば、 `TableFullScan`操作で`actRows`カウントが高く、 `execution info`で実行時間が長い場合は、インデックスの作成を検討してください。7 `HashJoin`操作でメモリ使用量と実行時間が高い場合は、結合順序を最適化するか、別の結合方法を使用することを検討してください。 +3. これらの要因を相関させることで、パフォーマンス問題の根本原因を特定できます。例えば、 `TableFullScan`操作で`actRows`カウントが高く、 `execution info`で実行時間が長い場合は、インデックスの作成を検討してください。`HashJoin`操作でメモリ使用量と実行時間が高い場合は、結合順序を最適化するか、別の結合方法を使用することを検討してください。 以下の実行プランでは、クエリは5分51秒間実行された後、キャンセルされます。主な問題点は次のとおりです。 1. 重大な過小評価：最初のリーフノード`IndexReader_76`インデックス`index_orders_on_adjustment_id(adjustment_id)`からデータを読み取ります。実際の行数（ `actRows` ）は256,811,189で、推定された1行（ `estRows` ）よりも大幅に多くなっています。 2. メモリ オーバーフロー: この過小評価により、ハッシュ結合演算子`HashJoin_69`予想よりもはるかに多くのデータを含むハッシュ テーブルを構築し、過剰なメモリ(22.6 GB) とディスク領域 (7.65 GB) を消費します。 -3. クエリの終了： `0` `HashJoin_69`の演算子の値が`actRows`の場合、1は一致する行がないか、リソース制約によりクエリが終了したことを示します。この場合、ハッシュ結合はメモリを過剰に消費し、メモリ制御メカニズムがトリガーされてクエリが終了します。 +3. クエリの終了： `HashJoin_69`とその上位の演算子の`actRows`の値が`0`の場合、一致する行がないか、リソース制約によりクエリが終了したことを示します。この場合、ハッシュ結合はメモリを過剰に消費し、メモリ制御メカニズムがトリガーされてクエリが終了します。 4. 結合順序が正しくありません: この非効率的な計画の根本的な原因は、 `estRows` `IndexRangeScan_75`に対して大幅に過小評価していることであり、オプティマイザーが誤った結合順序を選択することになります。 これらの問題に対処するには、特に`orders`テーブルと`index_orders_on_adjustment_id`インデックスのテーブル統計が最新であることを確認します。 diff --git a/statement-summary-tables.md b/statement-summary-tables.md index 4e9dc0159d1d3..e333da1823141 100644 --- a/statement-summary-tables.md +++ b/statement-summary-tables.md @@ -96,7 +96,7 @@ select * from employee where id in (...) and salary between ? and ?; > **Note:** > -> [`tidb_stmt_summary_enable_persistent`](#persist-statements-summary)有効になっている場合、 `statements_summary_history`テーブルのデータはディスクに永続化されます。この場合、 `tidb_stmt_summary_max_stmt_count` 、 `statements_summary`テーブルがメモリに格納できる SQL ダイジェストの数のみを制限し、{{B-PLACEHOLDER-5-PLACEHOLDER- `tidb_stmt_summary_max_stmt_count` `statements_summary`から最も使用頻度の低い SQL ダイジェストのみを削除します。 +> [`tidb_stmt_summary_enable_persistent`](#persist-statements-summary)有効になっている場合、 `statements_summary_history`テーブルのデータはディスクに永続化されます。この場合、 `tidb_stmt_summary_max_stmt_count`は、 `statements_summary`テーブルがメモリに格納できる SQL ダイジェストの数のみを制限し、TiDB は`tidb_stmt_summary_max_stmt_count`を超えると`statements_summary`テーブルから最も使用頻度の低い SQL ダイジェストのみを削除します。 diff --git a/statistics.md b/statistics.md index 0d430b13ab5aa..4f05b8ea603bf 100644 --- a/statistics.md +++ b/statistics.md @@ -85,7 +85,7 @@ TiDBは、テーブルへの変更回数に基づいて、自動的に[`ANALYZE` ### ヒストグラム {#histogram} -ヒストグラム統計は、オプティマイザが区間または範囲述語の選択性を推定するために使用され、また、統計のバージョン 2 で等号/IN 述語を推定するために列内の異なる値の数を決定するためにも使用される場合があります (統計[統計のバージョン](#versions-of-statistics)を参照)。 +ヒストグラム統計は、オプティマイザが区間または範囲述語の選択性を推定するために使用され、また、統計のバージョン 2 で等号/IN 述語を推定するために列内の異なる値の数を決定するためにも使用される場合があります ( [統計のバージョン](#versions-of-statistics)を参照)。 ヒストグラムは、データの分布を近似的に表現したものです。値の全範囲を複数のバケットに分割し、各バケットに含まれる値の数など、単純なデータを用いて各バケットを記述します。TiDBでは、各テーブルの特定の列に対して等深ヒストグラムが作成されます。この等深ヒストグラムは、区間クエリの推定に利用できます。 @@ -105,14 +105,14 @@ Count-Min Sketch はハッシュ構造です。 `a = 1`や`IN`クエリ (例え Count-Min Sketch はハッシュ構造であるため、ハッシュ衝突が発生する可能性があります。EXPLAIN [`EXPLAIN`](/sql-statements/sql-statement-explain.md)において、同等のクエリの推定値が実際の値から大きく乖離する場合、より大きな値とより小さな値がハッシュ化されているとみなすことができます。この場合、ハッシュ衝突を回避するために、以下のいずれかの方法を取ることができます。 -- `WITH NUM TOPN`パラメータを変更します。TiDB は、高頻度 (上位 x) のデータを別々に格納し、その他のデータは Count-Min Sketch に格納します。そのため、より大きな値とより小さな値が一緒にハッシュ化されるのを防ぐには、 `WITH NUM TOPN`の値を増やすことができます。TiDB では、デフォルト値は 20 です。最大値は 1024 です。このパラメータの詳細については、 を参照[手動収集](#manual-collection)てください。 -- `WITH NUM CMSKETCH DEPTH`と`WITH NUM CMSKETCH WIDTH`の 2 つのパラメータを変更します。どちらもハッシュ バケットの数と衝突確率に影響します。実際のシナリオに応じて 2 つのパラメータの値を適切に増やすことでハッシュ衝突の確率を減らすことができますが、統計情報のメモリ使用量が増加します。TiDB では、 `WITH NUM CMSKETCH DEPTH`のデフォルト値は 5、 `WITH NUM CMSKETCH WIDTH`のデフォルト値は 2048 です。2 つのパラメータの詳細については、 を参照[手動収集](#manual-collection)てください。 +- `WITH NUM TOPN`パラメータを変更します。TiDB は、高頻度 (上位 x) のデータを別々に格納し、その他のデータは Count-Min Sketch に格納します。そのため、より大きな値とより小さな値が一緒にハッシュ化されるのを防ぐには、 `WITH NUM TOPN`の値を増やすことができます。TiDB では、デフォルト値は 20 です。最大値は 1024 です。このパラメータの詳細については、 [手動収集](#manual-collection)を参照してください。 +- `WITH NUM CMSKETCH DEPTH`と`WITH NUM CMSKETCH WIDTH`の 2 つのパラメータを変更します。どちらもハッシュ バケットの数と衝突確率に影響します。実際のシナリオに応じて 2 つのパラメータの値を適切に増やすことでハッシュ衝突の確率を減らすことができますが、統計情報のメモリ使用量が増加します。TiDB では、 `WITH NUM CMSKETCH DEPTH`のデフォルト値は 5、 `WITH NUM CMSKETCH WIDTH`のデフォルト値は 2048 です。2 つのパラメータの詳細については、 [手動収集](#manual-collection)を参照してください。 ### トップN {#top-n} トップN値とは、列またはインデックス内で出現頻度が最も高いN個の値のことです。トップN統計は、頻度統計またはデータスキューと呼ばれることもあります。 -TiDB は上位 N 個の値とその出現回数を記録します。ここでは`N`は`WITH NUM TOPN`パラメータによって制御されます。デフォルト値は 20 で、これは最も頻繁に出現する上位 20 個の値が収集されることを意味します。最大値は 1024 です。パラメータの詳細については、 を参照[手動収集](#manual-collection)てください。 +TiDB は上位 N 個の値とその出現回数を記録します。ここでは`N`は`WITH NUM TOPN`パラメータによって制御されます。デフォルト値は 20 で、これは最も頻繁に出現する上位 20 個の値が収集されることを意味します。最大値は 1024 です。パラメータの詳細については、 [手動収集](#manual-collection)を参照してください。 ## 選択的統計収集 {#selective-statistics-collection} @@ -314,7 +314,7 @@ TiDB は、最新の`ANALYZE`ステートメントで指定された新しい構 ### 列構成を保持する {#persist-column-configurations} -`ANALYZE`ステートメント ( `COLUMNS ColumnNameList` 、{{B-PLACEHOLDER-2-PLACEHOLDER- `PREDICATE COLUMNS`を含む) の列構成を永続化する場合は、 `tidb_persist_analyze_options` `ALL COLUMNS`変数の値を`ON`に設定して[構成の永続性を分析する](#persist-analyze-configurations)機能を有効にします。 ANALYZE 構成永続化機能を有効にした後: +`ANALYZE`ステートメント ( `COLUMNS ColumnNameList` 、 `PREDICATE COLUMNS` 、 `ALL COLUMNS`を含む) の列構成を永続化する場合は、 `tidb_persist_analyze_options`システム変数の値を`ON`に設定して[構成の永続性を分析する](#persist-analyze-configurations)機能を有効にします。 ANALYZE 構成永続化機能を有効にした後: - TiDB が統計情報を自動的に収集する場合、または列構成を指定せずに`ANALYZE`ステートメントを実行して手動で統計情報を収集する場合、TiDB は統計情報の収集に以前に保持された構成を引き続き使用します。 - 列構成を指定して`ANALYZE`ステートメントを手動で複数回実行すると、TiDB は最新の`ANALYZE`ステートメントで指定された新しい構成を使用して、以前に記録された永続構成を上書きします。 diff --git a/storage-engine/titan-configuration.md b/storage-engine/titan-configuration.md index b2dbe9ff003ef..ab49cee115e14 100644 --- a/storage-engine/titan-configuration.md +++ b/storage-engine/titan-configuration.md @@ -11,7 +11,7 @@ summary: Titan の設定方法を学びます。 > **Note:** > -> - TiDB v7.6.0以降、新規クラスタではTitanがデフォルトで有効化され、ワイドテーブルとJSONデータの書き込みパフォーマンスが向上します。1 [`min-blob-size`](/tikv-configuration-file.md#min-blob-size)のデフォルト値は`1KB`から`32KB`に変更されました。 +> - TiDB v7.6.0以降、新規クラスタではTitanがデフォルトで有効化され、ワイドテーブルとJSONデータの書き込みパフォーマンスが向上します。[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)のデフォルト値は`1KB`から`32KB`に変更されました。 > - v7.6.0 以降のバージョンにアップグレードされた既存のクラスターは元の構成を保持します。つまり、Titan が明示的に有効になっていない場合は、引き続き RocksDB が使用されます。 > - クラスタをTiDB v7.6.0以降のバージョンにアップグレードする前にTitanを有効にしていた場合、アップグレード後もTitanが有効になり、アップグレード前の設定値[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)も保持されます。アップグレード前に明示的に値を設定しない場合は、アップグレード後のクラスタ構成の安定性を確保するために、旧バージョンのデフォルト値`1KB`が保持されます。 @@ -111,7 +111,7 @@ Titan BLOBファイルとRocksDBブロックファイルの共有キャッシュ ### Titanの構成例 {#titan-configuration-example} -以下は Titan 設定ファイルの例です。1 または[Kubernetes上でTiDBクラスターを構成する](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster) [TiUPを使用して設定を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)かを選択できます。 +以下は Titan 設定ファイルの例です。[TiUPを使用して設定を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)か[Kubernetes上でTiDBクラスターを構成する](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster)かを選択できます。 ```toml [rocksdb] diff --git a/storage-engine/titan-overview.md b/storage-engine/titan-overview.md index 72e9e903b8ca2..c5454ef804b9e 100644 --- a/storage-engine/titan-overview.md +++ b/storage-engine/titan-overview.md @@ -27,7 +27,7 @@ Titan は、大量のデータが TiKV フォアグラウンドに書き込ま Titan を有効にするための前提条件は次のとおりです。 -- 値の平均サイズが大きい、またはすべての大きな値のサイズが値の合計サイズの大部分を占めています。現在、1KBを超える値のサイズは大きな値とみなされます。状況によっては、この数値（1KB）が512Bになる場合があります。TiKV Raftレイヤーの制限により、TiKVに書き込まれる単一の値は8MBを超えることはできません。1 [`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)設定値を調整することで、この制限を緩和できます。 +- 値の平均サイズが大きい、またはすべての大きな値のサイズが値の合計サイズの大部分を占めています。現在、1KBを超える値のサイズは大きな値とみなされます。状況によっては、この数値（1KB）が512Bになる場合があります。TiKV Raftレイヤーの制限により、TiKVに書き込まれる単一の値は8MBを超えることはできません。[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)設定値を調整することで、この制限を緩和できます。 - 範囲クエリは実行されないか、高い範囲クエリのパフォーマンスを必要としません。Titan に格納されるデータは整列されていないため、範囲クエリのパフォーマンスは RocksDB よりも低く、特に広い範囲のクエリではその傾向が顕著です。PingCAP の内部テストによると、Titan の範囲クエリのパフォーマンスは RocksDB よりも 40% から数倍低いことが示されています。 - 十分なディスク容量（同じデータ量でRocksDBのディスク消費量の2倍の容量を確保することを検討してください）。これは、Titanがディスク容量を犠牲にして書き込み増幅を削減するためです。また、Titanは値を1つずつ圧縮するため、圧縮率はRocksDBよりも低くなります。RocksDBはブロックを1つずつ圧縮するため、TitanはRocksDBよりも多くのストレージ容量を消費しますが、これは想定内の正常な動作です。状況によっては、Titanのストレージ消費量がRocksDBの2倍になる場合があります。 @@ -133,7 +133,7 @@ Titan は、選択された BLOB ファイルについて、各値に対応す ### min-blob-sizeがパフォーマンスに与える影響 {#impact-of-code-min-blob-size-code-on-performance} -[`min-blob-size`](/tikv-configuration-file.md#min-blob-size) 、値が Titan に格納されるかどうかを決定します。値が`min-blob-size`以上の場合、Titan に格納されます。それ以外の場合は、ネイティブの RocksDB 形式で格納されます。4 `min-blob-size`小さすぎたり大きすぎたりすると、パフォーマンスに影響します。 +[`min-blob-size`](/tikv-configuration-file.md#min-blob-size) 、値が Titan に格納されるかどうかを決定します。値が`min-blob-size`以上の場合、Titan に格納されます。それ以外の場合は、ネイティブの RocksDB 形式で格納されます。`min-blob-size`小さすぎたり大きすぎたりすると、パフォーマンスに影響します。 以下の表は、YCSBワークロードのQPSを異なる`min-blob-size`値に基づいて比較したものです。各テストラウンドでは、テストデータの行幅は`min-blob-size`に設定されており、Titanが有効な場合はデータがTitanに保存されます。 diff --git a/sys-schema/sys-schema.md b/sys-schema/sys-schema.md index c376ab2f5b96a..90a1be9e5d65c 100644 --- a/sys-schema/sys-schema.md +++ b/sys-schema/sys-schema.md @@ -5,7 +5,7 @@ summary: sys` スキーマ内のシステム テーブルについて学習し # sysスキーマ {#code-sys-code-schema} -TiDBはv8.0.0以降、 `sys`スキーマを提供します。3 `sys`のビューを使用して、TiDBのシステムテーブル[`INFORMATION_SCHEMA`](/information-schema/information-schema.md) [`PERFORMANCE SCHEMA`](/performance-schema/performance-schema.md)データを把握できます。 +TiDBはv8.0.0以降、 `sys`スキーマを提供します。`sys`のビューを使用して、TiDBのシステムテーブル[`INFORMATION_SCHEMA`](/information-schema/information-schema.md) [`PERFORMANCE SCHEMA`](/performance-schema/performance-schema.md)データを把握できます。 ## MySQL互換性のためのテーブル {#tables-for-mysql-compatibility} diff --git a/system-variables.md b/system-variables.md index fddb06b4e2920..b5efbd74530f0 100644 --- a/system-variables.md +++ b/system-variables.md @@ -1275,7 +1275,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - `tidb_auto_analyze_start_time='01:00 +0000'` - `tidb_auto_analyze_end_time='03:00 +0000'` -- パラメータ内の時刻にタイムゾーン情報が含まれている場合、そのタイムゾーンが解析に使用されます。そうでない場合は、現在のセッションの`time_zone`で指定されたタイムゾーンが使用されます。たとえば、 `01:00 +0000` UTC の午前 1:00 を指します。 +- パラメータ内の時刻にタイムゾーン情報が含まれている場合、そのタイムゾーンが解析に使用されます。そうでない場合は、現在のセッションの`time_zone`で指定されたタイムゾーンが使用されます。たとえば、 `01:00 +0000`は UTC の午前 1:00 を指します。 ### tidb_auto_analyze_partition_batch_size はv6.4.0 で追加されました。 {#tidb-auto-analyze-partition-batch-size-span-class-version-mark-new-in-v6-4-0-span} @@ -1319,7 +1319,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - `tidb_auto_analyze_start_time='01:00 +0000'` - `tidb_auto_analyze_end_time='03:00 +0000'` -- パラメータ内の時刻にタイムゾーン情報が含まれている場合、そのタイムゾーンが解析に使用されます。そうでない場合は、現在のセッションの`time_zone`で指定されたタイムゾーンが使用されます。たとえば、 `01:00 +0000` UTC の午前 1:00 を指します。 +- パラメータ内の時刻にタイムゾーン情報が含まれている場合、そのタイムゾーンが解析に使用されます。そうでない場合は、現在のセッションの`time_zone`で指定されたタイムゾーンが使用されます。たとえば、 `01:00 +0000`は UTC の午前 1:00 を指します。 ### tidb_auto_build_stats_concurrency v6.5.0で追加 {#tidb-auto-build-stats-concurrency-new-in-v650} @@ -1771,8 +1771,8 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 範囲: `[32, 10240]` - 単位：行 - この変数は、DDL 操作の`re-organize`フェーズ中にバッチ サイズを設定するために使用されます。たとえば、TiDB が`ADD INDEX`操作を実行すると、インデックス データは`tidb_ddl_reorg_worker_cnt` (数) 個の同時実行ワーカーによってバックフィルされる必要があります。各ワーカーは、インデックス データをバッチ単位でバックフィルします。 - - `tidb_ddl_enable_fast_reorg`が`OFF`に設定されている場合、 `ADD INDEX`はトランザクションとして実行されます。 `UPDATE`の実行中に、対象列で`REPLACE`や`ADD INDEX` }} などの更新操作が多数発生する場合、バッチサイズが大きいほどトランザクション競合が発生する可能性が高くなります。この場合、バッチサイズを小さい値に設定することをお勧めします。最小値は 32 です。 - - トランザクションの競合が存在しない場合、または`tidb_ddl_enable_fast_reorg`が`ON`に設定されている場合は、バッチ サイズを大きな値に設定できます。これにより、データのバックフィルが高速になりますが、TiKV への書き込み圧力も増加します。適切なバッチ サイズについては、 `tidb_ddl_reorg_worker_cnt`の値も参照する必要があります。参考として[オンラインワークロードと`ADD INDEX`操作に関する相互作用テスト](https://docs.pingcap.com/tidb/dev/online-workloads-and-add-index-operations)参照してください。 + - `tidb_ddl_enable_fast_reorg`が`OFF`に設定されている場合、 `ADD INDEX`はトランザクションとして実行されます。 `ADD INDEX`の実行中に、対象列で`UPDATE`や`REPLACE`などの更新操作が多数発生する場合、バッチサイズが大きいほどトランザクション競合が発生する可能性が高くなります。この場合、バッチサイズを小さい値に設定することをお勧めします。最小値は 32 です。 + - トランザクションの競合が存在しない場合、または`tidb_ddl_enable_fast_reorg`が`ON`に設定されている場合は、バッチ サイズを大きな値に設定できます。これにより、データのバックフィルが高速になりますが、TiKV への書き込み圧力も増加します。適切なバッチ サイズについては、 `tidb_ddl_reorg_worker_cnt`の値も参照する必要があります。参考として[オンラインワークロードと`ADD INDEX`操作に関する相互作用テスト](https://docs.pingcap.com/tidb/dev/online-workloads-and-add-index-operations)を参照してください。 - バージョン8.3.0以降、このパラメータはセッションレベルでサポートされています。グローバルレベルでパラメータを変更しても、現在実行中のDDLステートメントには影響しません。変更は、新規セッションで送信されるDDLにのみ適用されます。 - バージョン 8.5.0 以降では、 `ADMIN ALTER DDL JOBS BATCH_SIZE = ;`を実行することで、実行中の DDL ジョブのこのパラメータを変更できます。TiDB バージョン 8.5.5 より前のバージョンでは、 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)が有効になっている場合、 `ADD INDEX` DDL に対してこの操作はサポートされていないことに注意してください。詳細については、 [`ADMIN ALTER DDL JOBS`](/sql-statements/sql-statement-admin-alter-ddl.md)を参照してください。 @@ -5159,7 +5159,7 @@ SHOW WARNINGS; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Boolean - デフォルト値: `OFF` -- この変数は、オプティマイザが`DISTINCT`を含む集計関数を、 `SELECT b, COUNT(DISTINCT a) FROM t GROUP BY b`を`SELECT b, COUNT(a) FROM (SELECT b, a FROM t GROUP BY b, a) t GROUP BY b` } に書き換えるなど、2 レベルの集計関数に書き換えるかどうかを設定します。集計列に深刻な偏りがあり、 `DISTINCT`列にさまざまな値がある場合、この書き換えによってクエリ実行時のデータ偏りを回避し、クエリのパフォーマンスを向上させることができます。 +- この変数は、オプティマイザが`DISTINCT`を含む集計関数を、 `SELECT b, COUNT(DISTINCT a) FROM t GROUP BY b`を`SELECT b, COUNT(a) FROM (SELECT b, a FROM t GROUP BY b, a) t GROUP BY b`に書き換えるなど、2 レベルの集計関数に書き換えるかどうかを設定します。集計列に深刻な偏りがあり、 `DISTINCT`列にさまざまな値がある場合、この書き換えによってクエリ実行時のデータ偏りを回避し、クエリのパフォーマンスを向上させることができます。 ### tidb_opt_three_stage_distinct_agg v6.3.0で追加 {#tidb-opt-three-stage-distinct-agg-new-in-v630} @@ -5725,7 +5725,7 @@ SHOW WARNINGS; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `ON` -- この変数は[`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)ステートメントと[`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name)オプティマイザヒントに特権制御を適用するかどうかを制御します。このシステム変数が`ON`に設定されている場合、これらの 2 つの方法で現在のセッションまたは現在のステートメントのバインドされたリソース グループを変更するには`SUPER` `RESOURCE_GROUP_ADMIN` 、 `RESOURCE_GROUP_USER` PLACEHOLDER-E}} の特権が必要です。 `OFF`に設定されている場合、これらの権限は不要となり、この変数がない以前の TiDB バージョンと同じ動作になります。 +- この変数は[`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)ステートメントと[`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name)オプティマイザヒントに特権制御を適用するかどうかを制御します。このシステム変数が`ON`に設定されている場合、これらの 2 つの方法で現在のセッションまたは現在のステートメントのバインドされたリソース グループを変更するには`SUPER` 、 `RESOURCE_GROUP_ADMIN` 、または`RESOURCE_GROUP_USER`の特権が必要です。 `OFF`に設定されている場合、これらの権限は不要となり、この変数がない以前の TiDB バージョンと同じ動作になります。 - TiDB クラスターを以前のバージョンから v8.2.0 以降にアップグレードすると、この変数のデフォルト値は`OFF`に設定され、この機能はデフォルトで無効になります。 ### tidb_retry_limit {#tidb-retry-limit} diff --git a/table-affinity.md b/table-affinity.md index 937d31256d749..35a195638cfc9 100644 --- a/table-affinity.md +++ b/table-affinity.md @@ -35,7 +35,7 @@ PDアフィニティスケジューリングはデフォルトで無効になっ pd-ctl config set schedule.affinity-schedule-limit 4 ``` -2. （オプション）必要に応じてPD設定項目[`schedule.max-affinity-merge-region-size`](/pd-configuration-file.md#max-affinity-merge-region-size-new-in-v855)を変更します。デフォルト値は`256`です。これは、同じアフィニティグループ内の隣接する小さなリージョンを自動的にマージするためのサイズしきい値を制御します。5に設定すると`0`アフィニティグループ内の隣接する小さなリージョンの自動マージが無効になります。 +2. （オプション）必要に応じてPD設定項目[`schedule.max-affinity-merge-region-size`](/pd-configuration-file.md#max-affinity-merge-region-size-new-in-v855)を変更します。デフォルト値は`256` MiB です。これは、同じアフィニティグループ内の隣接する小さなリージョンを自動的にマージするためのサイズしきい値を制御します。`0`に設定すると、アフィニティグループ内の隣接する小さなリージョンの自動マージが無効になります。 ## 使用法 {#usage} @@ -84,7 +84,7 @@ ALTER TABLE t1 AFFINITY = ''; テーブルまたはパーティションのアフィニティ情報は、次の方法で表示できます。 -- [`SHOW AFFINITY`](/sql-statements/sql-statement-show-affinity.md)番目のステートメントを実行します。3 `Status`の列には、アフィニティが有効になっているテーブルまたはパーティションと、それらのスケジュールステータスが表示されます。5 `Status`の列の値の意味は次のとおりです。 +- [`SHOW AFFINITY`](/sql-statements/sql-statement-show-affinity.md)番目のステートメントを実行します。`Status`の列には、アフィニティが有効になっているテーブルまたはパーティションと、それらのスケジュールステータスが表示されます。`Status`の列の値の意味は次のとおりです。 - `Pending` : リーダーまたは投票者がまだ決定されていない場合など、PD はテーブルまたはパーティションのアフィニティ スケジューリングを開始していません。 - `Preparing` : PD はアフィニティ要件を満たすようにリージョンをスケジュールしています。 diff --git a/table-attributes.md b/table-attributes.md index e00ad2fd3d730..24ea569bda507 100644 --- a/table-attributes.md +++ b/table-attributes.md @@ -133,8 +133,8 @@ ALTER TABLE t PARTITION p ATTRIBUTES 'merge_option=allow'; > **Note:** > -> - パーティションを持つテーブルの場合、 `merge_option`属性がテーブルレベルでのみ設定されている場合、 `merge_option=allow`であっても、テーブルはデフォルトで実際のパーティション数に応じて複数のリージョンに分割されます。すべてのリージョンをマージするには、 [テーブルの属性をリセットする](#usage)実行する必要があります。 -> - `merge_option`属性を使用する場合は、PD設定パラメータ[`split-merge-interval`](/pd-configuration-file.md#split-merge-interval)に注意する必要があります。5 属性`merge_option`設定されていない場合、リージョンが条件を満たしている場合、 `split-merge-interval`で指定された間隔後にリージョンをマージできます`merge_option`属性が設定されている場合、PDは`merge_option`設定に基づいて、指定された間隔後にリージョンをマージするかどうかを決定します。 +> - パーティションを持つテーブルの場合、 `merge_option`属性がテーブルレベルでのみ設定されている場合、 `merge_option=allow`であっても、テーブルはデフォルトで実際のパーティション数に応じて複数のリージョンに分割されます。すべてのリージョンをマージするには、 [テーブルの属性をリセットする](#usage)を実行する必要があります。 +> - `merge_option`属性を使用する場合は、PD設定パラメータ[`split-merge-interval`](/pd-configuration-file.md#split-merge-interval)に注意する必要があります。`merge_option`属性が設定されていない場合、リージョンが条件を満たしている場合、 `split-merge-interval`で指定された間隔後にリージョンをマージできます`merge_option`属性が設定されている場合、PDは`merge_option`設定に基づいて、指定された間隔後にリージョンをマージするかどうかを決定します。 @@ -142,7 +142,7 @@ ALTER TABLE t PARTITION p ATTRIBUTES 'merge_option=allow'; > **Note:** > -> - パーティションを持つテーブルの場合、 `merge_option`属性がテーブルレベルでのみ設定されている場合、 `merge_option=allow`であっても、テーブルはデフォルトで実際のパーティション数に応じて複数のリージョンに分割されます。すべてのリージョンをマージするには、 [テーブルの属性をリセットする](#usage)実行する必要があります。 -> - `merge_option`の属性が設定されていない場合、リージョンが条件を満たしていれば、1時間後にリージョンを統合できます。3 `merge_option`属性が設定されている場合、PDは`merge_option`設定に基づいて、1時間後にリージョンを統合するかどうかを決定します。 +> - パーティションを持つテーブルの場合、 `merge_option`属性がテーブルレベルでのみ設定されている場合、 `merge_option=allow`であっても、テーブルはデフォルトで実際のパーティション数に応じて複数のリージョンに分割されます。すべてのリージョンをマージするには、 [テーブルの属性をリセットする](#usage)を実行する必要があります。 +> - `merge_option`の属性が設定されていない場合、リージョンが条件を満たしていれば、1時間後にリージョンを統合できます。`merge_option`属性が設定されている場合、PDは`merge_option`設定に基づいて、1時間後にリージョンを統合するかどうかを決定します。 diff --git a/ticdc/integrate-confluent-using-ticdc.md b/ticdc/integrate-confluent-using-ticdc.md index 606d4f9738ac1..b3da26e7323fb 100644 --- a/ticdc/integrate-confluent-using-ticdc.md +++ b/ticdc/integrate-confluent-using-ticdc.md @@ -103,7 +103,7 @@ TiDB v6.1.0以降、TiCDCはAvro形式でConfluentへの増分データのレプ - `` - `` - 1 の値を置き換える前に、 [HTML URL エンコーディングリファレンス](https://www.w3schools.com/tags/ref_urlencode.asp)に基づいて``エンコードする必要があることに注意してください。上記のすべてのフィールドを置き換えた後、設定ファイルは次のようになります。 + ``の値を置き換える前に、 [HTML URL エンコーディングリファレンス](https://www.w3schools.com/tags/ref_urlencode.asp)に基づいてエンコードする必要があることに注意してください。上記のすべてのフィールドを置き換えた後、設定ファイルは次のようになります。 ```shell tiup cdc:v cli changefeed create --server="http://127.0.0.1:8300" --sink-uri="kafka://xxx-xxxxx.ap-east-1.aws.confluent.cloud:9092/ticdc-meta?protocol=avro&replication-factor=3&enable-tls=true&auto-create-topic=true&sasl-mechanism=plain&sasl-user=L5WWA4GK4NAT2EQV&sasl-password=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" --schema-registry="https://7NBH2CAFM2LMGTH7:xxxxxxxxxxxxxxxxxx@yyy-yyyyy.us-east-2.aws.confluent.cloud" --changefeed-id="confluent-changefeed" --config changefeed.conf @@ -156,14 +156,14 @@ Snowflakeはクラウドネイティブなデータウェアハウスです。Co ### 前提条件 {#prerequisites} -- Snowflakeクラスターの登録と作成が完了しました[Snowflakeを使い始める](https://docs.snowflake.com/en/user-guide-getting-started.html)参照してください。 -- Snowflakeクラスタに接続する前に、クラスタ用の秘密鍵を生成しておきます。1 [キーペア認証とキーペアローテーション](https://docs.snowflake.com/en/user-guide/key-pair-auth.html)参照してください。 +- Snowflakeクラスターの登録と作成が完了しています。[Snowflakeを使い始める](https://docs.snowflake.com/en/user-guide-getting-started.html)を参照してください。 +- Snowflakeクラスタに接続する前に、クラスタ用の秘密鍵を生成しておきます。[キーペア認証とキーペアローテーション](https://docs.snowflake.com/en/user-guide/key-pair-auth.html)を参照してください。 ### 統合手順 {#integration-procedure} 1. Snowflake でデータベースとスキーマを作成します。 - Snowflakeコントロールコンソールで、 **「データ」** > **「データベース」**を選択します。5 `TPCC`名前のデータベースと`TiCDC`という名前のスキーマを作成します。 + Snowflakeコントロールコンソールで、 **「データ」** > **「データベース」**を選択します。`TPCC`名前のデータベースと`TiCDC`という名前のスキーマを作成します。 2. Confluent Cloud Consoleで、 **「データ統合」** > **「コネクタ」** > **「Snowflake Sink」**を選択します。以下のページが表示されます。 diff --git a/ticdc/ticdc-alert-rules.md b/ticdc/ticdc-alert-rules.md index cb07ddd01f2b5..c6f4c33915e6a 100644 --- a/ticdc/ticdc-alert-rules.md +++ b/ticdc/ticdc-alert-rules.md @@ -53,7 +53,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 解決： - このアラートはレプリケーションの中断に似ています。1 [TiCDC はレプリケーションの中断を処理します](/ticdc/troubleshoot-ticdc.md#how-do-i-handle-replication-interruptions)参照してください。 + このアラートはレプリケーションの中断に似ています。[TiCDC はレプリケーションの中断を処理します](/ticdc/troubleshoot-ticdc.md#how-do-i-handle-replication-interruptions)を参照してください。 ## 警告アラート {#warning-alerts} @@ -155,7 +155,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 解決： - 考えられる根本原因は多数あります。1 [TiCDC のトラブルシューティング](/ticdc/troubleshoot-ticdc.md)参照してください。 + 考えられる根本原因は多数あります。[TiCDC のトラブルシューティング](/ticdc/troubleshoot-ticdc.md)を参照してください。 ### `ticdc_memory_abnormal` {#ticdc-memory-abnormal} diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md index b0be9e83a3e29..6fb53811969c5 100644 --- a/ticdc/ticdc-avro-protocol.md +++ b/ticdc/ticdc-avro-protocol.md @@ -82,7 +82,7 @@ TiCDC は DML イベントを Kafka イベントに変換し、イベントの ## TiDB拡張フィールド {#tidb-extension-fields} -デフォルトでは、AvroはDMLイベント内の変更された行のデータのみを収集し、データ変更の種類やTiDB固有のCommitTS（トランザクションの一意の識別子）は収集しません。この問題に対処するため、TiCDCはAvroプロトコルメッセージに以下の3つのTiDB拡張フィールドを導入しています。7で`enable-tidb-extension` `true` （デフォルトは`false` ）に設定すると、TiCDC `sink-uri`メッセージ生成時にこれらの3つのフィールドをAvroメッセージに追加します。 +デフォルトでは、AvroはDMLイベント内の変更された行のデータのみを収集し、データ変更の種類やTiDB固有のCommitTS（トランザクションの一意の識別子）は収集しません。この問題に対処するため、TiCDCはAvroプロトコルメッセージに以下の3つのTiDB拡張フィールドを導入しています。`sink-uri`で`enable-tidb-extension`を`true` （デフォルトは`false` ）に設定すると、TiCDCはメッセージ生成時にこれらの3つのフィールドをAvroメッセージに追加します。 - `_tidb_op` : DML タイプ。「c」は挿入を示し、「u」は更新を示します。 - `_tidb_commit_ts` : トランザクションの一意の識別子。 @@ -158,7 +158,7 @@ dispatchers = [ } - `{{ColumnName}}`列名を示します。 -- `{{TIDB_TYPE}}` TiDB 内の型を示します。これは SQL 型との 1 対 1 のマッピングではありません。 +- `{{TIDB_TYPE}}`は TiDB 内の型を示します。これは SQL 型との 1 対 1 のマッピングではありません。 - `{{AVRO_TYPE}}` [Avro仕様](https://avro.apache.org/docs/++version++/specification)内のタイプを示します。 | SQLの型 | TiDBの型 | AVRO_TYPE | 説明 | @@ -168,7 +168,7 @@ dispatchers = [ | SMALLINT | INT | int | 符号なしの場合、TIDB_TYPE は INT UNSIGNED になります。 | | MEDIUMINT | INT | int | 符号なしの場合、TIDB_TYPE は INT UNSIGNED になります。 | | INT | INT | int | 符号なしの場合、TIDB_TYPE は INT UNSIGNED になり、AVRO_TYPE は long になります。 | -| BIGINT | BIGINT | long | 符号なしの場合、TIDB_TYPEはBIGINT UNSIGNEDです。1 `avro-bigint-unsigned-handling-mode`文字列の場合、AVRO_TYPEは文字列です。 | +| BIGINT | BIGINT | long | 符号なしの場合、TIDB_TYPEはBIGINT UNSIGNEDです。`avro-bigint-unsigned-handling-mode`文字列の場合、AVRO_TYPEは文字列です。 | | TINYBLOB | BLOB | bytes | - | | BLOB | BLOB | bytes | - | | MEDIUMBLOB | BLOB | bytes | - | @@ -284,7 +284,7 @@ TiCDC Avro プロトコルは[`io.confluent.kafka.serializers.KafkaAvroDeseriali コンシューマー プログラムは、次のルールによって DML イベント タイプを区別できます。 - Key部分のみの場合はDeleteイベントになります。 -- キーと値の両方がある場合、挿入イベントまたは更新イベントのいずれかです。1 [TiDB拡張フィールド](#tidb-extension-fields)有効になっている場合は、 `_tidb_op`フィールドを使用して挿入イベントか更新イベントかを識別できます。TiDB拡張フィールドが有効になっていない場合は、それらを区別できません。 +- キーと値の両方がある場合、挿入イベントまたは更新イベントのいずれかです。[TiDB拡張フィールド](#tidb-extension-fields)が有効になっている場合は、 `_tidb_op`フィールドを使用して挿入イベントか更新イベントかを識別できます。TiDB拡張フィールドが有効になっていない場合は、それらを区別できません。 ## トピックの分布 {#topic-distribution} diff --git a/ticdc/ticdc-bidirectional-replication.md b/ticdc/ticdc-bidirectional-replication.md index e6face4e1601a..9658af2973e72 100644 --- a/ticdc/ticdc-bidirectional-replication.md +++ b/ticdc/ticdc-bidirectional-replication.md @@ -23,7 +23,7 @@ TiCDCは、指定されたタイムスタンプ以降に発生した増分デー 1. 上流クラスタと下流クラスタの時点を確認します。2つのTiDBクラスタがある場合は、特定の時点において2つのクラスタのデータが整合していることを確認します。例えば、TiDB 1の`ts=1`時点のデータとTiDB 2の`ts=2`のデータは整合しています。 - 2. changefeed を作成する際、上流クラスターの changefeed の`--start-ts`対応する`tso`に設定します。つまり、上流クラスターが TiDB 1 の場合は`--start-ts=1` 、下流クラスターが TiDB 2 の場合は`--start-ts=2`設定します。 + 2. changefeed を作成する際、上流クラスターの changefeed の`--start-ts`を対応する`tso`に設定します。つまり、上流クラスターが TiDB 1 の場合は`--start-ts=1` 、下流クラスターが TiDB 2 の場合は`--start-ts=2`を設定します。 4. `--config`パラメータで指定された構成ファイルに、次の構成を追加します。 @@ -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)を使用しないでください。`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-canal-json.md b/ticdc/ticdc-canal-json.md index 26179c694c7f4..b140b016875bd 100644 --- a/ticdc/ticdc-canal-json.md +++ b/ticdc/ticdc-canal-json.md @@ -82,7 +82,7 @@ TiCDC は、DDL イベントを次の Canal-JSON 形式にエンコードしま | mysqlType | object | isDdlが`false`場合、各列のデータ型がMySQLでどのように表現されるかを記録します。 | | データ | object | isDdlが`false`の場合、各列の名前とそのデータ値を記録します。 | | 古い | object | メッセージが更新イベントによって生成された場合のみ、更新前の各列の名前とデータ値を記録します。 | -| _tidb | object | TiDB拡張フィールド。1 を`enable-tidb-extension` `true`設定した場合にのみ存在します。5 `commitTs`値は、行の変更を引き起こしたトランザクションのTSOです。 | +| _tidb | object | TiDB拡張フィールド。`enable-tidb-extension`を`true`に設定した場合にのみ存在します。`commitTs`の値は、行の変更を引き起こしたトランザクションのTSOです。 | ### DMLイベント {#dml-event} @@ -167,8 +167,8 @@ TiCDCは、 `enable-tidb-extension`を`true`に設定した場合のみ、WATERM 上記の例からわかるように、Canal-JSON は統一されたデータ形式を持ち、イベントの種類ごとに異なるフィールドの入力ルールを備えています。コンシューマーは、統一された方法でこの JSON 形式のデータを解析し、フィールド値をチェックすることでイベントの種類を判別できます。 -- `isDdl`が`true`場合、メッセージには DDL イベントが含まれます。 -- `isDdl`が`false`場合、 `type`フィールドをさらに確認する必要があります。7 が`type` `TIDB_WATERMARK`場合、それは WATERMARK イベントです。それ以外の場合は、DML イベントです。 +- `isDdl`が`true`の場合、メッセージには DDL イベントが含まれます。 +- `isDdl`が`false`の場合、 `type`フィールドをさらに確認する必要があります。`type`が`TIDB_WATERMARK`の場合、それは WATERMARK イベントです。それ以外の場合は、DML イベントです。 ## フィールドの説明 {#field-descriptions} @@ -338,7 +338,7 @@ values (127, 32767, 8388607, 2147483647, 9223372036854775807); update tp_int set c_int = 0, c_tinyint = 0 where c_smallint = 32767; ``` -`update`ステートメントでは、TiCDCは以下に示すように、 `type`を`UPDATE`としてイベントメッセージを出力します。7 `update`ステートメントは、列番号`c_int`と`c_tinyint`のみを変更します。出力イベントメッセージの`old`フィールドには、すべての列データが含まれます。 +`update`ステートメントでは、TiCDCは以下に示すように、 `type`を`UPDATE`としてイベントメッセージを出力します。`update`ステートメントは、列番号`c_int`と`c_tinyint`のみを変更します。出力イベントメッセージの`old`フィールドには、すべての列データが含まれます。 ```json { diff --git a/ticdc/ticdc-changefeed-overview.md b/ticdc/ticdc-changefeed-overview.md index 634a048a146b0..8baed00adc661 100644 --- a/ticdc/ticdc-changefeed-overview.md +++ b/ticdc/ticdc-changefeed-overview.md @@ -35,7 +35,7 @@ summary: チェンジフィードの基本的な概念、状態の定義、お - ⑤ changefeedの自動リトライが30分を超えて失敗し、changefeedは失敗状態になります。このとき、changefeedは`gc-ttl`で指定された期間、上流GCをブロックし続けます。 - ⑥ changefeed は回復不能なエラーに遭遇し、直接 failed 状態に移行します。このとき、changefeed は`gc-ttl`で指定された期間、上流の GC をブロックし続けます。 - ⑦ changefeedのレプリケーション進行状況が`target-ts`で設定した値に到達し、レプリケーションが完了します。 -- 8 チェンジフィードが`gc-ttl`で指定された値よりも長い期間中断されたため、GC 進行エラーが発生し、再開できません。 +- ⑧ チェンジフィードが`gc-ttl`で指定された値よりも長い期間中断されたため、GC 進行エラーが発生し、再開できません。 - ⑨ 失敗の原因が解決され、変更フィードが`gc-ttl`で指定された値よりも短い期間中断された場合は、 `changefeed resume`コマンドを実行してレプリケーション タスクを再開します。 ## チェンジフィードを操作する {#operate-changefeeds} diff --git a/ticdc/ticdc-csv.md b/ticdc/ticdc-csv.md index 017fcbaef3f5a..c5e6623e199d6 100644 --- a/ticdc/ticdc-csv.md +++ b/ticdc/ticdc-csv.md @@ -33,7 +33,7 @@ output-field-header = false # New in v8.5.6 (only available in the TiCDC new arc ## トランザクション上の制約 {#transactional-constraints} -- 単一のCSVファイルでは、ある行の`commit-ts`は、次の行の{{B-PLACEHOLDER-E}}と同じかそれ以下です。 +- 単一のCSVファイルでは、ある行の`commit-ts`は、次の行の`commit-ts`と同じかそれ以下です。 - 同一テーブルの同じトランザクションは、同じCSVファイルに保存されます。 - 同じトランザクションの複数のテーブルを、異なるCSVファイルに保存することができます。 diff --git a/ticdc/ticdc-data-replication-capabilities.md b/ticdc/ticdc-data-replication-capabilities.md index 880965812aa45..a8612bb803efc 100644 --- a/ticdc/ticdc-data-replication-capabilities.md +++ b/ticdc/ticdc-data-replication-capabilities.md @@ -13,7 +13,7 @@ summary: TiCDC のデータ複製機能について学びます。 - TiCDCは`UPDATE` `INSERT` `DELETE`を生成します。詳細については[TiCDCがデータ変更を処理する方法](/ticdc/ticdc-overview.md#implementation-of-processing-data-changes)参照してください。 -- TiCDCはトランザクションの最終的な一貫性を保証します。1 [再実行ログ](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios)有効にすると、TiCDCは災害復旧シナリオにおいて最終的な一貫性を保証できます。3 [同期ポイント](/ticdc/ticdc-upstream-downstream-check.md#enable-syncpoint)有効にすると、TiCDCは一貫性のあるスナップショット読み取りとデータ整合性の検証をサポートします。 +- TiCDCはトランザクションの最終的な一貫性を保証します。[再実行ログ](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios)を有効にすると、TiCDCは災害復旧シナリオにおいて最終的な一貫性を保証できます。[同期ポイント](/ticdc/ticdc-upstream-downstream-check.md#enable-syncpoint)を有効にすると、TiCDCは一貫性のあるスナップショット読み取りとデータ整合性の検証をサポートします。 ## サポートされている下流システム {#supported-downstream-systems} diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md index 78011d4cad652..867786a0fb338 100644 --- a/ticdc/ticdc-ddl.md +++ b/ticdc/ticdc-ddl.md @@ -144,7 +144,7 @@ ignore-event = ["create table", "drop table", "truncate table", "rename table"] | `DROP TABLE test.t1;` | 無視する |
  • | `test.t1`イベントフィルタルールに一致するため、イベント`DROP TABLE`は無視されます。テーブルが削除されたため、TiCDC は`t1`の DML イベントを複製しなくなります。 | | `TRUNCATE TABLE test.t1;` | 無視する | 複製する | `test.t1`イベントフィルタルールに一致するため、 `TRUNCATE TABLE`イベントは無視されます。DMLイベントのレプリケーションは影響を受けません。 | | `RENAME TABLE test.t1 TO test.t2;` | 無視する | 複製する | `test.t1`イベントフィルタルールに一致するため、 `RENAME TABLE`イベントは無視されます。DMLイベントのレプリケーションは影響を受けません。 | -| `RENAME TABLE test.t1 TO test.ignore;` | 無視する | 無視する | `test.t1`イベント フィルター ルールに一致するため、 `RENAME TABLE`イベントは無視されます。4 `test.ignore`イベント フィルター ルールに一致するため、DDL イベントと DML イベントの両方が無視されます。 | +| `RENAME TABLE test.t1 TO test.ignore;` | 無視する | 無視する | `test.t1`イベント フィルター ルールに一致するため、 `RENAME TABLE`イベントは無視されます。`test.ignore`イベント フィルター ルールに一致するため、DDL イベントと DML イベントの両方が無視されます。 | > **Note:** > diff --git a/ticdc/ticdc-debezium.md b/ticdc/ticdc-debezium.md index 6dea71fa76b6c..50c83179927b8 100644 --- a/ticdc/ticdc-debezium.md +++ b/ticdc/ticdc-debezium.md @@ -152,7 +152,7 @@ TiCDC は、キーと値の両方を Debezium 形式でエンコードして、D | フィールド名 | 型 | 説明 | | :------------------- | :----- | :------------------------------------------------------------------------------------------------------------------------------- | -| payload.op | String | 変更イベントのタイプ。1 `"c"` `INSERT`イベント、 `"u"` `UPDATE`イベント、 `"d"` `DELETE`イベントを示します。 | +| payload.op | String | 変更イベントのタイプ。`"c"` `INSERT`イベント、 `"u"` `UPDATE`イベント、 `"d"` `DELETE`イベントを示します。 | | payload.ts_ms | number | TiCDC がこのメッセージを生成したときのタイムスタンプ (ミリ秒単位)。 | | payload.before | JSON | ステートメントの変更イベント前のデータ値。イベントが`"c"`場合、フィールド`before`の値は`null`なります。 | | payload.after | JSON | The data value after the change event of a statement. For `"d"` events, the value of the `after` field is `null`. | diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index e855f9abd2dee..bf5890637c34e 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -335,7 +335,7 @@ TiDB v7.1.0 以降、TiCDC はこれらの冗長な DML イベントを削除し ## DDL文を下流のMySQL 5.7に複製する際に、時間型フィールドのデフォルト値が一致しません。どうすればよいでしょうか？ {#the-default-value-of-the-time-type-field-is-inconsistent-when-replicating-a-ddl-statement-to-the-downstream-mysql-5-7-what-can-i-do} -上流のTiDBで`create table test (id int primary key, ts timestamp)`文が実行されたとします。TiCDCがこの文を下流のMySQL 5.7に複製する際、MySQLはデフォルト設定を使用します。複製後のテーブルスキーマは以下のようになります。3 `timestamp`のフィールドのデフォルト値は`CURRENT_TIMESTAMP`になります。 +上流のTiDBで`create table test (id int primary key, ts timestamp)`文が実行されたとします。TiCDCがこの文を下流のMySQL 5.7に複製する際、MySQLはデフォルト設定を使用します。複製後のテーブルスキーマは以下のようになります。`timestamp`のフィールドのデフォルト値は`CURRENT_TIMESTAMP`になります。 ```sql mysql root@127.0.0.1:test> show create table test; diff --git a/ticdc/ticdc-manage-changefeed.md b/ticdc/ticdc-manage-changefeed.md index 09518aca005d7..9999167e71671 100644 --- a/ticdc/ticdc-manage-changefeed.md +++ b/ticdc/ticdc-manage-changefeed.md @@ -51,7 +51,7 @@ cdc cli changefeed list --server=http://10.0.10.25:8300 ## 特定のレプリケーションタスクをクエリする {#query-a-specific-replication-task} -特定のレプリケーションタスク`-s`クエリするには、 `changefeed query`コマンドを実行します。クエリ結果には、タスク情報とタスク状態が含まれます。3 または`--simple`引数を指定すると、クエリ結果を簡略化し、基本的なレプリケーション状態とチェックポイント情報のみを含めることができます。この引数を指定しない場合は、詳細なタスク設定、レプリケーション状態、およびレプリケーションテーブル情報が出力されます。 +特定のレプリケーションタスクをクエリするには、 `changefeed query`コマンドを実行します。クエリ結果には、タスク情報とタスク状態が含まれます。`--simple`または`-s`引数を指定すると、クエリ結果を簡略化し、基本的なレプリケーション状態とチェックポイント情報のみを含めることができます。この引数を指定しない場合は、詳細なタスク設定、レプリケーション状態、およびレプリケーションテーブル情報が出力されます。 ```shell cdc cli changefeed query -s --server=http://10.0.10.25:8300 --changefeed-id=simple-replication-task @@ -174,7 +174,7 @@ cdc cli changefeed resume --server=http://10.0.10.25:8300 --changefeed-id simple > **Note:** > -> - `--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`間のデータは下流に複製されません。これによりデータ損失が発生します。`cdc cli changefeed query`を実行すると`t1`を取得できます。 > - `--overwrite-checkpoint-ts` （ `t2` ）で指定されたTSOがチェンジフィード（ `t1` ）の現在のチェックポイントTSOより小さい場合、TiCDCは古い時点（ `t2` ）からデータをプルします。これにより、データの重複が発生する可能性があります（たとえば、下流がMQシンクの場合）。 ## レプリケーションタスクを削除する {#remove-a-replication-task} @@ -274,7 +274,7 @@ force-replicate = true > **Note:** > -> v6.0.0以降、TiCDCはデフォルトでDB Sorterエンジンを使用し、Unified Sorterエンジンは使用しなくなりました。1 `sort engine`項目は設定しないことを推奨します。 +> v6.0.0以降、TiCDCはデフォルトでDB Sorterエンジンを使用し、Unified Sorterエンジンは使用しなくなりました。`sort engine`項目は設定しないことを推奨します。 統合ソートエンジンはTiCDCのソートエンジンです。以下のシナリオで発生するOOM問題を軽減できます。 diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md index 8448ed66da974..62af8ebe45bbd 100644 --- a/ticdc/ticdc-open-api-v2.md +++ b/ticdc/ticdc-open-api-v2.md @@ -108,7 +108,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/status - `id` : ノードのキャプチャ ID。 - `pid` : ノードのキャプチャプロセス ID (PID)。 - `is_owner` : ノードが所有者であるかどうかを示します。 -- `liveness` : このノードがライブかどうか。2 `0`正常を意味します。4 `1`ノードが`graceful shutdown`状態にあることを意味します。 +- `liveness` : このノードがライブかどうか。`0`正常を意味します。`1`ノードが`graceful shutdown`状態にあることを意味します。 ## TiCDC クラスターのヘルスステータスを確認する {#check-the-health-status-of-a-ticdc-cluster} @@ -240,25 +240,25 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | `start_ts` | `UINT64`型。変更フィードの開始TSOを指定します。TiCDCクラスターは、このTSOからデータのプルを開始します。デフォルト値は現在時刻です。（オプション） | | `target_ts` | `UINT64`型。変更フィードのターゲットTSOを指定します。TiCDCクラスターは、このTSOに到達するとデータのプルを停止します。デフォルト値は空で、TiCDCは自動的に停止しません。(オプション) | -`changefeed_id` `target_ts`意味と`sink_uri`は、 [`cdc cli`を使用してレプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)ドキュメントに記載されているものと同じです。これら`start_ts`パラメータの詳細については、 `sink_uri`のドキュメントを参照してください。11 で証明書パスを指定する際は、対応する証明書が対応する TiCDCサーバーにアップロードされていることを確認してください。 +`changefeed_id` `target_ts`意味と`sink_uri`は、 [`cdc cli`を使用してレプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)ドキュメントに記載されているものと同じです。これら`start_ts`パラメータの詳細については、 `sink_uri`のドキュメントを参照してください。`sink_uri`で証明書パスを指定する際は、対応する証明書が対応する TiCDCサーバーにアップロードされていることを確認してください。 `replica_config`パラメータの説明は次のとおりです。 | パラメータ名 | 説明 | | :------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `bdr_mode` | `BOOLEAN`型。2 [双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md)有効にするかどうかを決定します。デフォルト値は`false`です。（オプション） | +| `bdr_mode` | `BOOLEAN`型。[双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md)を有効にするかどうかを決定します。デフォルト値は`false`です。（オプション） | | `case_sensitive` | `BOOLEAN`型。テーブル名をフィルタリングする際に大文字と小文字を区別するかどうかを指定します。v6.5.6、v7.1.3、v7.5.0以降では、デフォルト値が`true`から`false`に変更されます。（オプション） | | `check_gc_safe_point` | `BOOLEAN`型。レプリケーションタスクの開始時刻がGC時刻よりも前であるかどうかを確認するかどうかを指定します。デフォルト値は`true`です。（オプション） | | `consistent` | REDOログの設定パラメータ。(オプション) | -| `enable_sync_point` | `BOOLEAN`型。2 `sync point`有効にするかどうかを決定します。（オプション） | +| `enable_sync_point` | `BOOLEAN`型。`sync point`有効にするかどうかを決定します。（オプション） | | `filter` | `filter`の設定パラメータ。(オプション) | | `force_replicate` | `BOOLEAN`型。デフォルト値は`false`です`true`に設定すると、レプリケーションタスクは一意インデックスを持たないテーブルを強制的にレプリケートします。（オプション） | | `ignore_ineligible_table` | `BOOLEAN`型。デフォルト値は`false`です`true`に設定すると、レプリケーションタスクはレプリケートできないテーブルを無視します。（オプション） | | `memory_quota` | `UINT64`型。レプリケーションタスクのメモリクォータ。（オプション） | | `mounter` | `mounter`の設定パラメータ。(オプション) | | `sink` | `sink`の設定パラメータ。(オプション) | -| `sync_point_interval` | `STRING`型。返される値は`UINT64`型のナノ秒単位の時間であることに注意してください。4 `sync point`が有効な場合、このパラメータは同期ポイントが上流と下流のスナップショットを同期させる間隔を指定します。デフォルト値は`10m`で、最小値は`30s`です。（オプション） | -| `sync_point_retention` | `STRING`型。返される値は`UINT64`型のナノ秒単位の時間であることに注意してください。4 `sync point`が有効な場合、このパラメータは、下流テーブルにおける同期ポイントによるデータの保持期間を指定します。この期間を超えると、データはクリーンアップされます。デフォルト値は`24h`です。（オプション） | +| `sync_point_interval` | `STRING`型。返される値は`UINT64`型のナノ秒単位の時間であることに注意してください。`sync point`が有効な場合、このパラメータは同期ポイントが上流と下流のスナップショットを同期させる間隔を指定します。デフォルト値は`10m`で、最小値は`30s`です。（オプション） | +| `sync_point_retention` | `STRING`型。返される値は`UINT64`型のナノ秒単位の時間であることに注意してください。`sync point`が有効な場合、このパラメータは、下流テーブルにおける同期ポイントによるデータの保持期間を指定します。この期間を超えると、データはクリーンアップされます。デフォルト値は`24h`です。（オプション） | `consistent`パラメータは次のように記述されます。 @@ -306,14 +306,14 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | :---------------------------- | :--------------------------------------------------------------------------------------------------------------------------- | | `column_selectors` | 列セレクターの構成。(オプション) | | `csv` | CSV 構成。(オプション) | -| `date_separator` | `STRING`型。ファイルディレクトリの日付区切り文字の種類を示します。値の選択肢は`none` 、 `year` 、 `month` 、 `day`です。10 `none`デフォルト値で、日付が区切られないことを意味します。(オプション) | +| `date_separator` | `STRING`型。ファイルディレクトリの日付区切り文字の種類を示します。値の選択肢は`none` 、 `year` 、 `month` 、 `day`です。`none`がデフォルト値で、日付が区切られないことを意味します。(オプション) | | `dispatchers` | イベントディスパッチ用の構成配列。(オプション) | | `encoder_concurrency` | `INT`型。MQシンク内のエンコーダスレッドの数。デフォルト値は`16`です。（オプション） | | `protocol` | `STRING`型。MQシンクの場合、メッセージのプロトコル形式を指定できます。現在サポートされているプロトコルは、 `canal-json` 、 `open-protocol` 、 `avro` 、 `debezium` 、 `simple` 。 | | `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`型。`canal-json`または`open-protocol`プロトコルを使用するMQシンクの場合、変更された列のみを出力するかどうかを指定できます。デフォルト値は`false`です。（オプション） | | `cloud_storage_config` | ストレージシンクの構成。(オプション) | | `open` | オープンプロトコルの構成。(オプション) | | `debezium` | Debezium プロトコルの設定。(オプション) | @@ -333,7 +333,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | `include_commit_ts` | `BOOLEAN`型。CSV行にコミット情報を含めるかどうか。デフォルト値は`false`です。 | | `null` | `STRING`型。CSV列がnullの場合に表示される文字。デフォルト値は`\N`です。 | | `quote` | `STRING`型。CSVファイル内のフィールドを囲むために使用される引用符文字。値が空の場合、引用符は使用されません。デフォルト値は`"`です。 | -| `binary_encoding_method` | `STRING`型。バイナリデータのエンコード方式。2 または`"base64"` `"hex"`指定できます。デフォルト値は`"base64"`です。 | +| `binary_encoding_method` | `STRING`型。バイナリデータのエンコード方式。`"base64"`または`"hex"`を指定できます。デフォルト値は`"base64"`です。 | `sink.dispatchers` : MQタイプのシンクの場合、このパラメータを使用してイベントディスパッチャを設定できます。サポートされているディスパッチャは`default` 、 `ts` 、 `index-value` 、 `table`です。ディスパッチャのルールは以下のとおりです。 @@ -357,7 +357,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | `worker_count` | `INT`型。下流のクラウドストレージへのデータストレージの同時実行性が変更されます。 | | `flush_interval` | `STRING`型。下流のクラウドストレージへのデータ保存間隔が変更されます。 | | `file_size` | `INT`型。このファイル内のバイト数がこのパラメータの値を超えると、データ変更ファイルがクラウドストレージに保存されます。 | -| `file_expiration_days` | `INT`タイプ。ファイルを保持する期間。2 `date-separator` `day`に設定されている場合にのみ有効になります。 | +| `file_expiration_days` | `INT`タイプ。ファイルを保持する期間。`date-separator` `day`に設定されている場合にのみ有効になります。 | | `file_cleanup_cron_spec` | `STRING`型。crontab 設定と互換性のある、スケジュールされたクリーンアップタスクの実行サイクル。形式は` `です。 | | `flush_concurrency` | `INT`型。単一ファイルのアップロードの同時実行性。 | | `output_raw_change_event` | `BOOLEAN`タイプ。MySQL 以外のシンクの元のデータ変更イベントを出力するかどうかを制御します。 | @@ -509,7 +509,7 @@ curl -X POST -H "Content-type: application/json" http://127.0.0.1:8300/api/v2/ch | `resolved_ts` | `UINT64`タイプ。レプリケーション タスクは ts を解決しました。 | | `sink_uri` | `STRING`タイプ。レプリケーション タスク シンクの URI。 | | `start_ts` | `UINT64`タイプ。レプリケーションタスクが開始されます。 | -| `state` | `STRING`型。レプリケーションタスクの`failed` 。2、4、6、8、10 `stopped` `normal`か`finished`なります`error` | +| `state` | `STRING`型。レプリケーションタスクのステータス。`normal` 、 `stopped` 、 `error` 、 `failed` 、または`finished`になります。 | | `target_ts` | `UINT64`タイプ。レプリケーションタスクのターゲット ts。 | | `task_status` | レプリケーション タスクのディスパッチの詳細なステータス。 | @@ -803,7 +803,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/changefeeds/test1/synced 応答には次のフィールドが含まれます。 -- `synced` : このレプリケーションタスクが完了したかどうか。2 `true`タスクが完了したこと、 `false`タスクが完了していない可能性があることを意味します。6 `false`場合は、 `info`フィールドとその他のフィールドの両方で具体的なステータスを確認する必要があります。 +- `synced` : このレプリケーションタスクが完了したかどうか。`true`タスクが完了したこと、 `false`タスクが完了していない可能性があることを意味します。`false`の場合は、 `info`フィールドとその他のフィールドの両方で具体的なステータスを確認する必要があります。 - `sink_checkpoint_ts` : シンク モジュールのチェックポイント ts 値 (PD 時間)。 - `puller_resolved_ts` : PD 時間での、プラー モジュールのresolved-ts値。 - `last_synced_ts` : TiCDC によって処理された最新のデータの commit-ts 値 (PD 時間)。 diff --git a/ticdc/ticdc-open-api.md b/ticdc/ticdc-open-api.md index c778a08f937d0..e7617ca2ad68d 100644 --- a/ticdc/ticdc-open-api.md +++ b/ticdc/ticdc-open-api.md @@ -9,7 +9,7 @@ summary: OpenAPI インターフェースを使用してクラスターのステ > **注記** > -> TiCDC OpenAPI v1は非推奨であり、将来削除される予定です。1 [TiCDC オープンAPI v2](/ticdc/ticdc-open-api-v2.md)使用をお勧めします。 +> TiCDC OpenAPI v1は非推奨であり、将来削除される予定です。[TiCDC オープンAPI v2](/ticdc/ticdc-open-api-v2.md)の使用をお勧めします。 TiCDC は、TiCDC クラスターを照会および操作するための OpenAPI 機能を提供します。これは、 [`cdc cli`ツール](/ticdc/ticdc-manage-changefeed.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`です。`true`を指定すると、TiCDC は一意インデックスを持たないテーブルを強制的に複製しようとします。 -`ignore_ineligible_table` : このパラメータのデフォルトは`false`です。4 `true`指定すると、TiCDC は複製できないテーブルを無視します。 +`ignore_ineligible_table` : このパラメータのデフォルトは`false`です。`true`を指定すると、TiCDC は複製できないテーブルを無視します。 `filter_rules` : テーブルスキーマフィルタリングのルール（例： `filter_rules = ['foo*.*','bar*.*']` ）。詳細については、 [テーブルフィルター](/table-filter.md)ドキュメントを参照してください。 diff --git a/ticdc/ticdc-server-config.md b/ticdc/ticdc-server-config.md index 5164998dd9a4e..27851cda5e61d 100644 --- a/ticdc/ticdc-server-config.md +++ b/ticdc/ticdc-server-config.md @@ -23,7 +23,7 @@ summary: TiCDC で使用される CLI と構成パラメータについて学習 - `cert` : TLS 接続用の PEM 形式の証明書ファイルのパスを指定します (オプション)。 - `cert-allowed-cn` : TLS 接続の PEM 形式の共通名のパスを指定します (オプション)。 - `key` : TLS 接続用の PEM 形式の秘密鍵ファイルのパスを指定します (オプション)。 -- `tz` : TiCDC サービスが使用するタイムゾーン。TiCDC は、 `TIMESTAMP`などの時間データ型を内部的に変換するとき、またはデータをダウンストリームに複製するときに、このタイムゾーンを使用します。デフォルトは、プロセスが実行されるローカルタイムゾーンです。6 `sink-uri` `time-zone`パラメータは、 `mysql`と`tidb`シンクにのみ有効で、ダウンストリーム接続セッションのタイムゾーンを設定するために使用されることに注意してください。12 パラメータと`time-zone`パラメータの`tz`を指定する場合は、両方のパラメータで同じタイムゾーンを使用するようにしてください。これは、TiCDC プロセスは内部的に`tz`で指定されたタイムゾーンを使用するのに対し、MySQL シンクと TiDB シンクはダウンストリーム操作の実行時に`time-zone`で指定されたタイムゾーンを使用するためです。 +- `tz` : TiCDC サービスが使用するタイムゾーン。TiCDC は、 `TIMESTAMP`などの時間データ型を内部的に変換するとき、またはデータをダウンストリームに複製するときに、このタイムゾーンを使用します。デフォルトは、プロセスが実行されるローカルタイムゾーンです。`sink-uri`の`time-zone`パラメータは、 `mysql`と`tidb`シンクにのみ有効で、ダウンストリーム接続セッションのタイムゾーンを設定するために使用されることに注意してください。`tz`パラメータと`time-zone`パラメータの両方を指定する場合は、両方のパラメータで同じタイムゾーンを使用するようにしてください。これは、TiCDC プロセスは内部的に`tz`で指定されたタイムゾーンを使用するのに対し、MySQL シンクと TiDB シンクはダウンストリーム操作の実行時に`time-zone`で指定されたタイムゾーンを使用するためです。 - `cluster-id` : (オプション) TiCDC クラスターの ID。デフォルト値は`default`です。 `cluster-id`は TiCDC クラスターの一意の識別子です。同じ`cluster-id`を持つ TiCDC ノードは同じクラスターに属します。 `cluster-id`の長さは最大 128 文字です。 `cluster-id` `^[a-zA-Z0-9]+(-[a-zA-Z0-9]+)*$`のパターンに従う必要があり、 `owner` 、 `capture` 、 `task` 、 `changefeed` 、 `job` 、 `meta`のいずれかにすることはできません。 ## cdc server構成ファイルのパラメータ {#code-cdc-server-code-configuration-file-parameters} diff --git a/ticdc/ticdc-simple-protocol.md b/ticdc/ticdc-simple-protocol.md index d66342fc6213a..ccd8029295ec1 100644 --- a/ticdc/ticdc-simple-protocol.md +++ b/ticdc/ticdc-simple-protocol.md @@ -236,8 +236,8 @@ TiCDC は、DDL イベントを次の JSON 形式でエンコードします。 | `sql` | string | DDL ステートメント。 | | `commitTs` | number | DDL ステートメントの実行がアップストリームで完了したときのコミット タイムスタンプ。 | | `buildTs` | number | TiCDC 内でメッセージが正常にエンコードされたときの UNIX タイムスタンプ。 | -| `tableSchema` | object | テーブルの現在のスキーマ情報。詳細については、 [TableSchemaの定義](#tableschema-definition)参照してください。 | -| `preTableSchema` | object | DDL文が実行される前のテーブルのスキーマ情報。1 `CREATE`のDDLイベントを除くすべてのDDLイベントにこのフィールドがあります。 | +| `tableSchema` | object | テーブルの現在のスキーマ情報。詳細については、 [TableSchemaの定義](#tableschema-definition)を参照してください。 | +| `preTableSchema` | object | DDL文が実行される前のテーブルのスキーマ情報。`CREATE`のDDLイベントを除くすべてのDDLイベントにこのフィールドがあります。 | ### DML {#dml} diff --git a/ticdc/ticdc-sink-to-cloud-storage.md b/ticdc/ticdc-sink-to-cloud-storage.md index d93efadc6a87f..7e70c47842909 100644 --- a/ticdc/ticdc-sink-to-cloud-storage.md +++ b/ticdc/ticdc-sink-to-cloud-storage.md @@ -54,7 +54,7 @@ URI の`[query_parameters]`には、次のパラメータを設定できます > **Note:** > -> データ変更ファイルは、 `flush-interval`または`file-size`いずれかが要件を満たしている場合に下流に保存されます。5 `protocol`パラメータは必須です。TiCDCが変更フィードの作成時にこのパラメータを受け取らない場合は、 `CDC:ErrSinkUnknownProtocol`エラーが返されます。 +> データ変更ファイルは、 `flush-interval`または`file-size`のいずれかが要件を満たしている場合に下流に保存されます。`protocol`パラメータは必須です。TiCDCが変更フィードの作成時にこのパラメータを受け取らない場合は、 `CDC:ErrSinkUnknownProtocol`エラーが返されます。 ### 外部ストレージのシンクURIを構成する {#configure-sink-uri-for-external-storage} diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index dda9e120d3ca8..ce4492507796f 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -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"`を使用してパーティションディスパッチャを指定できます。`default` 、 `index-value` 、 `columns` 、 `table` 、 `ts`の5つのディスパッチャをサポートします。ディスパッチャのルールは以下のとおりです。 - `default` : デフォルトで`table`ディスパッチャルールを使用します。スキーマ名とテーブル名に基づいてパーティション番号を計算し、テーブルからのデータが必ず同じパーティションに送信されるようにします。その結果、1つのテーブルからのデータは1つのパーティションにのみ存在し、順序付けが保証されます。ただし、このディスパッチャルールは送信スループットを制限し、コンシューマーを追加しても消費速度を向上させることはできません。 - `index-value` : 主キー、一意インデックス、または`index`で明示的に指定されたインデックスのいずれかを使用してパーティション番号を計算し、テーブルデータを複数のパーティションに分散します。単一のテーブルのデータは複数のパーティションに送信され、各パーティションのデータは順序付けされます。コンシューマーを追加することで、消費速度を向上させることができます。このディスパッチャは、同じ行への更新が同じパーティションに送信されるようにすることで、その行の順序付けされた処理を保証します。 @@ -307,7 +307,7 @@ dispatchers = [ > **Note:** > -> バージョン6.1.0以降、設定の意味を明確にするため、パーティションディスパッチャを指定するための設定が`dispatcher`から`partition`に変更されました。5 `partition` `dispatcher`の別名です。例えば、次の2つのルールは全く同じ意味です。 +> バージョン6.1.0以降、設定の意味を明確にするため、パーティションディスパッチャを指定するための設定が`dispatcher`から`partition`に変更されました。`partition` `dispatcher`の別名です。例えば、次の2つのルールは全く同じ意味です。 > > [sink] > dispatchers = [ @@ -408,7 +408,7 @@ large-message-handle-compression = "none" - `large-message-handle-compression`で指定された圧縮アルゴリズムは、単一のKafkaメッセージを圧縮します。圧縮は、メッセージサイズの制限と比較する前に実行されます。 - 同時に、 [`sink-uri`](#configure-sink-uri-for-kafka)の`compression`パラメータを使用して圧縮アルゴリズムを設定することもできます。この圧縮アルゴリズムは、複数のKafkaメッセージを含むデータ送信リクエスト全体に適用されます。 -`large-message-handle-compression`設定した場合、TiCDC はメッセージを受信すると、まずメッセージサイズ制限パラメータの値と比較し、サイズ制限を超えるメッセージを圧縮します。5 に`compression` [`sink-uri`](#configure-sink-uri-for-kafka)設定した場合、TiCDC は`sink-uri`設定に基づいて、送信データ要求全体をシンクレベルで再度圧縮します。 +`large-message-handle-compression`設定した場合、TiCDC はメッセージを受信すると、まずメッセージサイズ制限パラメータの値と比較し、サイズ制限を超えるメッセージを圧縮します。[`sink-uri`](#configure-sink-uri-for-kafka)に`compression`も設定した場合、TiCDC は`sink-uri`設定に基づいて、送信データ要求全体をシンクレベルで再度圧縮します。 前述の 2 つの圧縮方法の圧縮率は次のように計算されます`compression ratio = size before compression / size after compression * 100` 。 diff --git a/ticdc/ticdc-sink-to-pulsar.md b/ticdc/ticdc-sink-to-pulsar.md index fc04b6a393198..ee7d66a4105a1 100644 --- a/ticdc/ticdc-sink-to-pulsar.md +++ b/ticdc/ticdc-sink-to-pulsar.md @@ -30,7 +30,7 @@ Info: {"upstream_id":7277814241002263370,"namespace":"default","id":"simple-repl - `--server` : TiCDC クラスター内の TiCDCサーバーのアドレス。 - `--changefeed-id` : レプリケーションタスクのID。形式は正規表現`^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$`一致する必要があります。IDが指定されていない場合、TiCDCは自動的にUUID（バージョン4形式）をIDとして生成します。 -- `--sink-uri` ：レプリケーションタスクのダウンストリームアドレス。2 [シンクURIを使用してPulsarを構成する](#sink-uri)参照してください。 +- `--sink-uri` ：レプリケーションタスクのダウンストリームアドレス。[シンクURIを使用してPulsarを構成する](#sink-uri)を参照してください。 - `--start-ts` : チェンジフィードの開始TSO。TiCDCクラスターはこのTSOからデータのプルを開始します。デフォルト値は現在時刻です。 - `--target-ts` : チェンジフィードのターゲットTSO。TiCDCクラスターはこのTSOでデータのプルを停止します。デフォルトでは空であり、TiCDCはデータのプルを自動的に停止しません。 - `--config` : changefeed設定ファイル[TiCDC チェンジフィード構成パラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。 diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index 54172d86904a5..517f8aa3d6c90 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -129,7 +129,7 @@ v6.5.10、v7.1.6、v7.5.3、v8.1.1以降、MySQL以外のシンクを使用す | --------------- | ------- | ---------------------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------- | | バージョン6.5.2以下 | 全て | ✗ | ✓ | | | v6.5.3 / v6.5.4 | Canal/オープン | ✗ | ✓ | | -| バージョン6.5.3 | CSV/Avro | ✗ | ✗ | 分割しますが、並べ替えは行いません。1を参照してください[＃9086](https://github.com/pingcap/tiflow/issues/9658) | +| バージョン6.5.3 | CSV/Avro | ✗ | ✗ | 分割しますが、並べ替えは行いません。[＃9086](https://github.com/pingcap/tiflow/issues/9658)を参照してください。 | | バージョン6.5.4 | Canal/オープン | ✗ | ✗ | 複数の変更を含むトランザクションのみを分割して並べ替える | | v6.5.5 ～ v6.5.9 | 全て | ✓ | ✗ | | | = v6.5.10 | 全て | ✓ (デフォルト値: `output-raw-change-event = false` ) | ✓ （オプション： `output-raw-change-event = true` ） | | @@ -140,7 +140,7 @@ v6.5.10、v7.1.6、v7.5.3、v8.1.1以降、MySQL以外のシンクを使用す | --------------- | ------- | ---------------------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------- | | バージョン7.1.0 | 全て | ✗ | ✓ | | | バージョン7.1.1 | Canal/オープン | ✗ | ✓ | | -| バージョン7.1.1 | CSV/Avro | ✗ | ✗ | 分割しますが、並べ替えは行いません。1を参照してください[＃9086](https://github.com/pingcap/tiflow/issues/9658) | +| バージョン7.1.1 | CSV/Avro | ✗ | ✗ | 分割しますが、並べ替えは行いません。[＃9086](https://github.com/pingcap/tiflow/issues/9658)を参照してください。 | | v7.1.2 ~ v7.1.5 | 全て | ✓ | ✗ | | | = v7.1.6 | 全て | ✓ (デフォルト値: `output-raw-change-event = false` ) | ✓ （オプション： `output-raw-change-event = true` ） | | diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index a05759fc1dc07..17d05f844628b 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -17,18 +17,18 @@ 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`を実行して、レプリケーションタスクのステータスを確認します。`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 ``` -上記のコマンドの出力で、 `admin-job-type`このレプリケーションタスクの状態を示しています。各状態とその意味の詳細については、 [チェンジフィードの状態](/ticdc/ticdc-changefeed-overview.md#changefeed-state-transfer)参照してください。 +上記のコマンドの出力で、 `admin-job-type`このレプリケーションタスクの状態を示しています。各状態とその意味の詳細については、 [チェンジフィードの状態](/ticdc/ticdc-changefeed-overview.md#changefeed-state-transfer)を参照してください。 ### レプリケーションの中断をどのように処理しますか? {#how-do-i-handle-replication-interruptions} @@ -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 ステートメントがあるため、レプリケーションを続行できません。 @@ -56,7 +56,7 @@ cdc cli changefeed query --server=http://127.0.0.1:8300 --changefeed-id 28c43ffc ## レプリケーション タスクを作成するとき、または MySQL にデータをレプリケートするときに、「 Error 1298: Unknown or incorrect time zone: 'UTC'エラーを処理するにはどうすればよいですか? {#how-do-i-handle-the-code-error-1298-unknown-or-incorrect-time-zone-utc-code-error-when-creating-the-replication-task-or-replicating-data-to-mysql} -このエラーは、下流のMySQLがタイムゾーンをロードしていない場合に返されます。1 [`mysql_tzinfo_to_sql`](https://dev.mysql.com/doc/refman/8.0/en/mysql-tzinfo-to-sql.html)実行することでタイムゾーンをロードできます。タイムゾーンをロードした後は、タスクを作成し、通常どおりデータをレプリケートできます。 +このエラーは、下流のMySQLがタイムゾーンをロードしていない場合に返されます。[`mysql_tzinfo_to_sql`](https://dev.mysql.com/doc/refman/8.0/en/mysql-tzinfo-to-sql.html)を実行することでタイムゾーンをロードできます。タイムゾーンをロードした後は、タスクを作成し、通常どおりデータをレプリケートできます。 ```shell mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql -p @@ -70,7 +70,7 @@ mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql -p Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skipping it. -ダウンストリームが特殊なMySQL環境（パブリッククラウドRDSまたは一部のMySQL派生バージョン）であり、前述の方法によるタイムゾーンのインポートに失敗した場合は、シンクURIの`time-zone`空の値（例： `time-zone=""` ）に設定することで、ダウンストリームのデフォルトのタイムゾーンを使用できます。5 `time-zone` `mysql`と`tidb`シンクにのみ有効であることに注意してください。 +ダウンストリームが特殊なMySQL環境（パブリッククラウドRDSまたは一部のMySQL派生バージョン）であり、前述の方法によるタイムゾーンのインポートに失敗した場合は、シンクURIの`time-zone`空の値（例： `time-zone=""` ）に設定することで、ダウンストリームのデフォルトのタイムゾーンを使用できます。`time-zone` `mysql`と`tidb`シンクにのみ有効であることに注意してください。 `mysql`と`tidb`シンクを使用する場合は、タイムゾーンを明示的に指定することをお勧めします（例： `time-zone="Asia/Shanghai"` 。また、TiCDCサーバー構成で指定する`tz`とシンクURIで指定する`time-zone`が、下流データベースのタイムゾーン設定と一致していることを確認してください。これにより、タイムゾーンの不一致によるデータの不整合を防ぐことができます。 @@ -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 @@ -128,7 +128,7 @@ cdc cli changefeed resume -c test-cf --server=http://127.0.0.1:8300 > **Note:** > -> changefeed `start-ts`エラー発生時の`checkpoint-ts`に 1 を加えた値に設定してタスクを再作成すると、DDL 文をスキップできますが、TiCDC が`checkpointTs+1`の時点での DML データ変更を失う可能性があります。したがって、この操作は実本番環境では厳禁です。 +> changefeed の`start-ts`をエラー発生時の`checkpoint-ts`に 1 を加えた値に設定してタスクを再作成すると、DDL 文をスキップできますが、TiCDC が`checkpointTs+1`の時点での DML データ変更を失う可能性があります。したがって、この操作は実本番環境では厳禁です。 ```shell cdc cli changefeed remove --server=http://127.0.0.1:8300 --changefeed-id simple-replication-task diff --git a/tidb-cloud/data-service-api-key.md b/tidb-cloud/data-service-api-key.md index 2d06a3125f1aa..52ed4901b386e 100644 --- a/tidb-cloud/data-service-api-key.md +++ b/tidb-cloud/data-service-api-key.md @@ -103,7 +103,7 @@ TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access このロールは、APIキーがデータアプリにリンクされたデータソースに対してデータの読み取りまたは書き込みを行えるかどうかを制御するために使用されます。 `ReadOnly`または`ReadAndWrite`ロールを選択できます。 - - `ReadOnly` : API キーで`SELECT` 、 {{B-PLACEHOLDER `SHOW` 、 `USE` `DESC` }} 、 `EXPLAIN`ステートメントなどのデータを読み取ることのみを許可します。 + - `ReadOnly` : API キーで`SELECT` 、 `SHOW` 、 `USE` 、 `DESC` 、 `EXPLAIN`ステートメントなどのデータを読み取ることのみを許可します。 - `ReadAndWrite` : このAPIキーは、データの読み書きを可能にします。このAPIキーを使用して、DMLステートメントやDDLステートメントなど、すべてのSQLステートメントを実行できます。 3. （オプション）APIキーの希望するレート制限を設定します。 diff --git a/tidb-cloud/data-service-app-config-files.md b/tidb-cloud/data-service-app-config-files.md index 33c2855107677..0f2c2f461f19a 100644 --- a/tidb-cloud/data-service-app-config-files.md +++ b/tidb-cloud/data-service-app-config-files.md @@ -163,7 +163,7 @@ summary: このドキュメントでは、TiDB Cloudのデータ アプリの構 | `method` | string | エンドポイントの HTTP メソッド。 `GET`を使用してデータを取得し、 `POST`を使用してデータを作成または挿入し、 `PUT`を使用してデータを更新または変更し、 `DELETE`を使用してデータを削除できます。 | | `endpoint` | string | データ アプリ内のエンドポイントの一意のパス。パスには、文字、数字、アンダースコア ( `_` )、およびスラッシュ ( `/` ) のみを使用できます。パスはスラッシュ ( `/` ) で始まり、文字、数字、またはアンダースコア ( `_` ) で終わる必要があります。例: `/my_endpoint/get_id` 。パスの長さは 64 文字未満である必要があります。 | | `cluster_id` | string | エンドポイントのTiDB Cloud Starterインスタンスの ID です。インスタンスの URL から取得できます。たとえば、インスタンスの URL が`https://tidbcloud.com/tidbs/1234567891234567890/overview?orgId=`の場合、インスタンス ID は`1234567891234567890`です。 | -| `params` | 配列 | エンドポイントで使用されるパラメーター。パラメーターを定義することで、エンドポイントを介してクエリ内のパラメーター値を動的に置き換えることができます。 `params`では、1 つまたは複数のパラメーターを定義できます。各パラメーターについて、 `name` 、 `type` 、 `required` 、および`default`フィールドを定義する必要があります。エンドポイントにパラメーターが必要ない場合は`params` }} のように { `"params": []` PLACEHOLDER-5-PLACEHOLDER-E}} を空のままにすることができます。 | +| `params` | 配列 | エンドポイントで使用されるパラメーター。パラメーターを定義することで、エンドポイントを介してクエリ内のパラメーター値を動的に置き換えることができます。 `params`では、1 つまたは複数のパラメーターを定義できます。各パラメーターについて、 `name` 、 `type` 、 `required` 、および`default`フィールドを定義する必要があります。エンドポイントにパラメーターが必要ない場合は、 `"params": []`のように`params`を空のままにすることができます。 | | `params.name` | string | パラメータ名。名前には文字、数字、アンダースコアのみを使用できます（ `_` ）。また、文字またはアンダースコアで始まる必要があります（ `_` ）。 `page`および`page_size`はリクエスト結果のページネーション用に**予約されて**いるため、パラメータ名として使用しないでください。 | | `params.type` | string | パラメーターのデータ型。サポートされている値は`string` 、 `number` 、 `integer` 、 `boolean` 、および`array` 。 `string`型のパラメーターを使用する場合は、引用符（ `'`または`"` ）を追加する必要はありません。例えば、 `foo` `string`タイプに対して有効であり、 `"foo"`として処理されますが、 `"foo"`は`"\"foo\""`として処理されます。 | | `params.required` | integer | リクエストでパラメータが必須かどうかを指定します。サポートされている値は、 `0` (必須ではない) と`1` (必須) です。デフォルト値は`0`です。 | diff --git a/tidb-cloud/data-service-get-started.md b/tidb-cloud/data-service-get-started.md index f2322409f1685..12c0e96642d3e 100644 --- a/tidb-cloud/data-service-get-started.md +++ b/tidb-cloud/data-service-get-started.md @@ -203,7 +203,7 @@ HTTPSリクエストを送信することでエンドポイントを呼び出す このロールは、APIキーがデータアプリにリンクされたTiDB Cloud Starterインスタンスに対してデータの読み取りまたは書き込みを行えるかどうかを制御するために使用されます。 `ReadOnly`または`ReadAndWrite`ロールを選択できます。 - - `ReadOnly` : API キーで`SELECT` 、 {{B-PLACEHOLDER `SHOW` 、 `USE` `DESC` }} 、 `EXPLAIN`ステートメントなどのデータを読み取ることのみを許可します。 + - `ReadOnly` : API キーで`SELECT` 、 `SHOW` 、 `USE` 、 `DESC` 、 `EXPLAIN`ステートメントなどのデータを読み取ることのみを許可します。 - `ReadAndWrite` : このAPIキーは、データの読み書きを可能にします。このAPIキーを使用して、DMLステートメントやDDLステートメントなど、すべてのSQLステートメントを実行できます。 3. （オプション）APIキーの希望するレート制限を設定します。 diff --git a/tidb-cloud/data-service-manage-data-app.md b/tidb-cloud/data-service-manage-data-app.md index e97c2d0baeee3..d7df32a55f268 100644 --- a/tidb-cloud/data-service-manage-data-app.md +++ b/tidb-cloud/data-service-manage-data-app.md @@ -7,7 +7,7 @@ summary: TiDB Cloudコンソールでデータ アプリを作成、表示、変 Data Service（プレビュー版）のデータアプリは、特定のアプリケーションのデータにアクセスするために使用できるエンドポイントのコレクションです。APIキーを使用して認証設定を構成し、データアプリ内のエンドポイントへのアクセスを制限できます。 -このドキュメントでは、 TiDB Cloudコンソールでデータアプリを管理する方法について説明します。1 [**データサービス**](https://tidbcloud.com/project/data-service)目では、すべてのデータアプリ、エンドポイント、API キーを管理できます。 +このドキュメントでは、 TiDB Cloudコンソールでデータアプリを管理する方法について説明します。[**Data Service**](https://tidbcloud.com/project/data-service)ページでは、すべてのデータアプリ、エンドポイント、API キーを管理できます。 ## データアプリを作成する {#create-a-data-app} diff --git a/tidb-cloud/migrate-from-op-tidb.md b/tidb-cloud/migrate-from-op-tidb.md index 1daaef714e36a..1b23b3c0c3a9d 100644 --- a/tidb-cloud/migrate-from-op-tidb.md +++ b/tidb-cloud/migrate-from-op-tidb.md @@ -264,7 +264,7 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート } ``` -4. 役割を設定します。 [IAMロールの作成（コンソール）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)参照してください。 「アカウント ID」フィールドに、ステップ 1 で書き留めたTiDB Cloudアカウント ID とTiDB Cloud外部 ID を入力します。 +4. 役割を設定します。 [IAMロールの作成（コンソール）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)を参照してください。 「アカウント ID」フィールドに、ステップ 1 で書き留めたTiDB Cloudアカウント ID とTiDB Cloud外部 ID を入力します。 5. ロール ARN を取得します。 [AWSコンソール > IAM > アクセス管理 > ロール](https://console.aws.amazon.com/iamv2/home#/roles)。お住まいの地域に切り替えてください。作成したロールをクリックし、ARN をメモします。これは、データをTiDB Cloudにインポートするときに使用します。 diff --git a/tidb-cloud/prometheus-grafana-integration.md b/tidb-cloud/prometheus-grafana-integration.md index 7eec243d6b66d..e0504e6d1ed31 100644 --- a/tidb-cloud/prometheus-grafana-integration.md +++ b/tidb-cloud/prometheus-grafana-integration.md @@ -13,7 +13,7 @@ TiDB Cloudは[Prometheus](https://prometheus.io/)APIエンドポイントを提 - TiDB CloudをPrometheusと統合するには、自己ホスト型またはマネージド型のPrometheusサービスが必要です。 -- TiDB Cloudのサードパーティ メトリクス統合を設定するには、TiDB Cloud で`Organization Owner`または`Instance Manager`アクセス権が必要です。統合ページを表示するには、 TiDB Cloud の組織内の対象の TiDB Cloud TiDB Cloud Essential TiDB Cloud Premium Premium インスタンスにアクセスするための {{B-PLACEHOLDER-2 -`Project Viewer`または`Instance Viewer`ロール以上が必要です。 +- TiDB Cloudのサードパーティ メトリクス統合を設定するには、TiDB Cloud で`Organization Owner`または`Instance Manager`アクセス権が必要です。統合ページを表示するには、 TiDB Cloud の組織内の対象のTiDB Cloud Essential TiDB Cloud Premiumインスタンスにアクセスするための`Project Viewer`または`Instance Viewer`ロール以上が必要です。 ## 制限 {#limitation} diff --git a/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md b/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md index 4845364d21f85..85d1a42be729a 100644 --- a/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md +++ b/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md @@ -32,8 +32,8 @@ TiDB Cloud Starterの管理インフラストラクチャをアップグレー - クラスタ管理 - クラスターを作成する - クラスターを削除する - - スケールクラスター - - クラスターをビュー + - クラスターをスケールする + - クラスターを表示する - クラスターを一時停止または再開する - クラスターのパスワードを変更する - クラスタートラフィックフィルターを変更する diff --git a/tidb-cloud/releases/release-notes-2021.md b/tidb-cloud/releases/release-notes-2021.md index cba773bbd6852..2c2731668e873 100644 --- a/tidb-cloud/releases/release-notes-2021.md +++ b/tidb-cloud/releases/release-notes-2021.md @@ -110,7 +110,7 @@ summary: 2021 年のTiDB Cloudのリリース ノートについて説明しま 一般的な -- TiDB Cloudは現在パブリックプレビュー中です。1 [サインアップ](https://tidbcloud.com/signup)クリックして、以下のトライアルオプションのいずれかを選択してください。 +- TiDB Cloudは現在パブリックプレビュー中です。[サインアップ](https://tidbcloud.com/signup)をクリックして、以下のトライアルオプションのいずれかを選択してください。 - 48時間無料トライアル - 2週間のPoC無料トライアル diff --git a/tidb-cloud/releases/release-notes-2022.md b/tidb-cloud/releases/release-notes-2022.md index 2a69506593285..db3a3dc1c73a6 100644 --- a/tidb-cloud/releases/release-notes-2022.md +++ b/tidb-cloud/releases/release-notes-2022.md @@ -122,7 +122,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま さらに、データ移行では、既存のデータと進行中の変更の両方をデータ ソースからTiDB Cloudに移行するための完全および増分データ移行機能が提供されます。 - 現在、データ移行機能は**ベータ版**です。3 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスター、AWSオレゴン（us-west-2）およびAWSシンガポール（ap-southeast-1）リージョンでのみご利用いただけます。組織ごとに1つの移行ジョブを無料で作成できます。組織に複数の移行ジョブを作成するには、 [チケットを提出する](/tidb-cloud/tidb-cloud-support.md)が必要です。 + 現在、データ移行機能は**ベータ版**です。[Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスター、AWSオレゴン（us-west-2）およびAWSシンガポール（ap-southeast-1）リージョンでのみご利用いただけます。組織ごとに1つの移行ジョブを無料で作成できます。組織に複数の移行ジョブを作成するには、 [チケットを提出する](/tidb-cloud/tidb-cloud-support.md)が必要です。 詳細については[データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)参照してください。 diff --git a/tidb-cloud/releases/release-notes-2023.md b/tidb-cloud/releases/release-notes-2023.md index 6e4e63d1faeef..4bacc63df3fcc 100644 --- a/tidb-cloud/releases/release-notes-2023.md +++ b/tidb-cloud/releases/release-notes-2023.md @@ -410,7 +410,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - changefeed を使用してデータを Amazon S3 にストリーミングすることをサポートします。 - これにより、 TiDB CloudとAmazon S3のシームレスな統合が可能になります。1 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターからAmazon S3へのリアルタイムのデータキャプチャとレプリケーションが可能になり、下流のアプリケーションと分析機能が最新のデータにアクセスできるようになります。 + これにより、 TiDB CloudとAmazon S3のシームレスな統合が可能になります。[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターからAmazon S3へのリアルタイムのデータキャプチャとレプリケーションが可能になり、下流のアプリケーションと分析機能が最新のデータにアクセスできるようになります。 詳細については[クラウドストレージに保存](/tidb-cloud/changefeed-sink-to-cloud-storage.md)参照してください。 diff --git a/tidb-cloud/releases/release-notes-2024.md b/tidb-cloud/releases/release-notes-2024.md index 16fd0dda4cb0f..f43af9f45eb42 100644 --- a/tidb-cloud/releases/release-notes-2024.md +++ b/tidb-cloud/releases/release-notes-2024.md @@ -178,7 +178,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) AWS上でのロードバランシングに関する課金体系の変更。 - 2024 年 8 月 1 日以降、 TiDB Cloud Dedicated の請求書には、AWS [AWSの料金改定は2024年2月1日から適用されます](https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/)各パブリック IPv4 アドレスの料金は 1 時間あたり 0.005 ドルで、これは AWS でホストされるTiDB Cloud Dedicatedクラスターごとに月額約 10 ドルになります。 + 2024 年 8 月 1 日以降、 TiDB Cloud Dedicated の請求書には、[AWSの料金改定は2024年2月1日から適用されます](https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/)に伴い、パブリック IPv4 アドレスに対する新しい AWS 料金が含まれます。各パブリック IPv4 アドレスの料金は 1 時間あたり 0.005 ドルで、これは AWS でホストされるTiDB Cloud Dedicatedクラスターごとに月額約 10 ドルになります。 この料金は、お客様の既存の**TiDB Cloud Dedicated - Data Transfer - Load Balancing**サービスの下に表示されます。 [請求明細](/tidb-cloud/tidb-cloud-billing.md#billing-details)。 diff --git a/tidb-cloud/releases/release-notes-2025.md b/tidb-cloud/releases/release-notes-2025.md index 728c505030c58..98e673e6c4db7 100644 --- a/tidb-cloud/releases/release-notes-2025.md +++ b/tidb-cloud/releases/release-notes-2025.md @@ -715,7 +715,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - [TiDB Cloudサーバーレス](/tidb-cloud/select-cluster-tier.md#starter)クラスター内のパブリック エンドポイントのファイアウォール ルールをサポートします。 - TiDB Cloud Serverless クラスターのファイアウォールルールを設定して、パブリックエンドポイント経由のアクセスを制御できるようになりました。1 [TiDB Cloudコンソール](https://tidbcloud.com/)許可する IP アドレスまたは範囲を直接指定することで、セキュリティを強化できます。 + TiDB Cloud Serverless クラスターのファイアウォールルールを設定して、パブリックエンドポイント経由のアクセスを制御できるようになりました。[TiDB Cloudコンソール](https://tidbcloud.com/)で許可する IP アドレスまたは範囲を直接指定することで、セキュリティを強化できます。 詳細については[パブリックエンドポイント用のTiDB Cloudサーバーレス ファイアウォール ルールを構成する](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md)参照してください。 diff --git a/tidb-cloud/serverless-export.md b/tidb-cloud/serverless-export.md index 68a7617ce799e..28bb65107bc98 100644 --- a/tidb-cloud/serverless-export.md +++ b/tidb-cloud/serverless-export.md @@ -332,7 +332,7 @@ ticloud serverless export create -c --target-type GCS --gcs.uri .blob.core.windows.net///`形式で Azure Blob Storage の URI を入力します。 - - **SASトークン**: コンテナへのアクセス権を持つSASトークンを入力します。2でSASトークンを作成することをお勧めします。詳細については、 [Azure Blob Storage アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access) [Azure ARM テンプレート](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/)してください。 + - **SASトークン**: コンテナへのアクセス権を持つSASトークンを入力します。[Azure ARM テンプレート](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/)を使用してSASトークンを作成することをお勧めします。詳細については、 [Azure Blob Storage アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 4. **［エクスポート］**をクリックします。 diff --git a/tidb-cloud/serverless-limitations.md b/tidb-cloud/serverless-limitations.md index a747ffef6068d..a014e650ac004 100644 --- a/tidb-cloud/serverless-limitations.md +++ b/tidb-cloud/serverless-limitations.md @@ -20,10 +20,10 @@ TiDB Cloud Starter/EssentialとTiDB Cloud Dedicated間の機能ギャップを ### 繋がり {#connection} -- [パブリックエンドポイント](/tidb-cloud/connect-via-standard-connection-serverless.md)と[プライベートエンドポイント](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)のみ使用できます。5 [VPC ピアリング](/tidb-cloud/set-up-vpc-peering-connections.md) TiDB Cloud StarterまたはTiDB Cloud Essentialクラスターに接続するためには使用できません。 +- [パブリックエンドポイント](/tidb-cloud/connect-via-standard-connection-serverless.md)と[プライベートエンドポイント](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)のみ使用できます。[VPC ピアリング](/tidb-cloud/set-up-vpc-peering-connections.md)は TiDB Cloud StarterまたはTiDB Cloud Essentialクラスターに接続するためには使用できません。 - プライベートエンドポイントのサポート[ファイアウォールルール](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md) 。 -- データベースクライアント接続は、30分以上開いたままになっていると、予期せず終了する可能性があります。これは、TiDBサーバーのシャットダウン、再起動、またはメンテナンス時に発生する可能性があり、アプリケーションの中断につながる可能性があります。この問題を回避するには、最大接続有効期間を設定してください。最初は5分から始め、テールレイテンシーに影響がある場合は徐々に増やすことを推奨します。詳細については、 [接続プールの推奨設定](/develop/dev-guide-connection-parameters.md)参照してください。 -- TiDB Cloud Starterクラスターでは、最大400の同時接続が可能です。1 [支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)設定すると、この制限は5,000に増加します。 +- データベースクライアント接続は、30分以上開いたままになっていると、予期せず終了する可能性があります。これは、TiDBサーバーのシャットダウン、再起動、またはメンテナンス時に発生する可能性があり、アプリケーションの中断につながる可能性があります。この問題を回避するには、最大接続有効期間を設定してください。最初は5分から始め、テールレイテンシーに影響がある場合は徐々に増やすことを推奨します。詳細については、 [接続プールの推奨設定](/develop/dev-guide-connection-parameters.md)を参照してください。 +- TiDB Cloud Starterクラスターでは、最大400の同時接続が可能です。[支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)を設定すると、この制限は5,000に増加します。 > **Note:** > 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..54d04ace1af8b 100644 --- a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md +++ b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md @@ -61,7 +61,7 @@ TiDB Cloud がAmazon MSK プロビジョニングクラスターにアクセス export PATH=$PATH:/home/ec2-user/jdk-22.0.2/bin ``` -4. 以下の内容を含む`scram-client.properties`という名前のファイルを作成します。3と`pswd` `username` /SCRAMの認証情報に置き換えてください。 +4. 以下の内容を含む`scram-client.properties`という名前のファイルを作成します。`username`と`pswd`をSASL/SCRAMの認証情報に置き換えてください。 ```properties security.protocol=SASL_SSL @@ -71,7 +71,7 @@ TiDB Cloud がAmazon MSK プロビジョニングクラスターにアクセス password="pswd"; ``` -5. ACLを作成します。1 `bootstrap-server` MSKブートストラップサーバーのアドレスとポート（例： `b-2.xxxxx.c18.kafka.us-east-1.amazonaws.com:9096` ）に置き換え、必要に応じてKafkaへのパスを置き換えます。 +5. ACLを作成します。`bootstrap-server` MSKブートストラップサーバーのアドレスとポート（例： `b-2.xxxxx.c18.kafka.us-east-1.amazonaws.com:9096` ）に置き換え、必要に応じてKafkaへのパスを置き換えます。 ```shell /home/ec2-user/kafka_2.13-3.7.1/bin/kafka-acls.sh --bootstrap-server --command-config scram-client.properties --add --allow-principal User: --operation All --topic '*' @@ -117,7 +117,7 @@ SASL/SCRAM の代わりに、 IAM認証を使用して MSK クラスターと同 sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler ``` -5. ACLを作成します。1 `bootstrap-server` MSKブートストラップサーバーのアドレスとポート（例： `b-1.xxxxx.c18.kafka.us-east-1.amazonaws.com:9098` ）に置き換え、必要に応じてKafkaへのパスを置き換えます。 +5. ACLを作成します。`bootstrap-server` MSKブートストラップサーバーのアドレスとポート（例： `b-1.xxxxx.c18.kafka.us-east-1.amazonaws.com:9098` ）に置き換え、必要に応じてKafkaへのパスを置き換えます。 ```shell /home/ec2-user/kafka_2.13-3.7.1/bin/kafka-acls.sh --bootstrap-server --command-config iam-client.properties --add --allow-principal User: --operation All --topic '*' @@ -142,7 +142,7 @@ SASL/SCRAM の代わりに、 IAM認証を使用して MSK クラスターと同 ## ステップ3. クラスターポリシーをアタッチする {#step-3-attach-the-cluster-policy} -[クラスタポリシーをアタッチする](https://docs.aws.amazon.com/msk/latest/developerguide/mvpc-cluster-owner-action-policy.html) [前提条件](#prerequisites-for-essential)して、 TiDB Cloud がMSK クラスターに接続できるようにします。2 で取得したTiDB Cloud AWS アカウント ID を使用してください。 +[クラスタポリシーをアタッチする](https://docs.aws.amazon.com/msk/latest/developerguide/mvpc-cluster-owner-action-policy.html)して、 TiDB Cloud がMSK クラスターに接続できるようにします。[前提条件](#prerequisites-for-essential)で取得したTiDB Cloud AWS アカウント ID を使用してください。 ## ステップ4. マルチVPC接続を有効にする {#step-4-turn-on-multi-vpc-connectivity} diff --git a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md index 179d1bcd755b3..20c93b9378fa4 100644 --- a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md +++ b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md @@ -112,7 +112,7 @@ Kafka VPC を作成するには、次の手順を実行します。 [ECSコンソール](https://ecs.console.alibabacloud.com/home#/)に進みます。vSwitch に 3 つのブローカー ノード (AZ ごとに 1 つ) を作成します。 -- vSwitch 1 のブローカー`broker-ap-southeast-1a` +- vSwitch `broker-ap-southeast-1a`のブローカー 1 - **ネットワークとゾーン**: `Kafka VPC`および`broker-ap-southeast-1a` vSwitch - **インスタンスとイメージ**: `ecs.t5-lc1m2.small`インスタンスタイプと`Alibaba Cloud Linux`イメージ @@ -187,7 +187,7 @@ Kafka VPC を作成するには、次の手順を実行します。 1. `listeners`項目の場合、3 つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 1. すべての**コントローラー**ロールノードに同じ CONTROLLER リスナーを設定します。**ブローカー**ロールノードのみを追加する場合は、 `server.properties`の CONTROLLER リスナーは必要ありません。 - 2. **ブローカー**リスナーを 2 つ構成します。3 `INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 + 2. **ブローカー**リスナーを 2 つ構成します。`INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 2. `advertised.listeners`項目については、次の操作を行います。 diff --git a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md index b0eb764c9d827..4c594768622bf 100644 --- a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md +++ b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md @@ -130,7 +130,7 @@ Kafka VPC を作成するには、次の手順を実行します。 4. 要塞サブネットをパブリック サブネットに構成します。 - 1. [VPCダッシュボード > インターネットゲートウェイ](https://console.aws.amazon.com/vpcconsole/home#igws:)に進みます。3 `kafka-vpc-igw`名前のインターネットゲートウェイを作成します。 + 1. [VPCダッシュボード > インターネットゲートウェイ](https://console.aws.amazon.com/vpcconsole/home#igws:)に進みます。`kafka-vpc-igw`名前のインターネットゲートウェイを作成します。 2. **インターネット ゲートウェイの詳細**ページの**アクション**で、 **VPC に接続を**クリックして、インターネット ゲートウェイを Kafka VPC に接続します。 @@ -264,7 +264,7 @@ Kafka VPC を作成するには、次の手順を実行します。 1. `listeners`項目の場合、3 つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 1. すべての**コントローラー**ロールノードに同じ CONTROLLER リスナーを設定します。**ブローカー**ロールノードのみを追加する場合は、 `server.properties`の CONTROLLER リスナーは必要ありません。 - 2. **ブローカー**リスナーを 2 つ構成します。3 `INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 + 2. **ブローカー**リスナーを 2 つ構成します。`INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 2. `advertised.listeners`項目については、次の操作を行います。 diff --git a/tidb-cloud/set-up-private-endpoint-connections.md b/tidb-cloud/set-up-private-endpoint-connections.md index fcfc89e735364..7b6b4b162ccad 100644 --- a/tidb-cloud/set-up-private-endpoint-connections.md +++ b/tidb-cloud/set-up-private-endpoint-connections.md @@ -39,7 +39,7 @@ AWS PrivateLink を利用することで、エンドポイント接続は安全 ## 前提条件 {#prerequisites} -AWS VPC設定でDNSホスト名とDNS解決の[AWS マネジメントコンソール](https://console.aws.amazon.com/)が有効になっていることを確認してください。1でVPCを作成すると、これらはデフォルトで無効になります。 +AWS VPC設定でDNSホスト名とDNS解決の両方が有効になっていることを確認してください。[AWS マネジメントコンソール](https://console.aws.amazon.com/)でVPCを作成すると、これらはデフォルトで無効になります。 ## プライベートエンドポイント接続を設定し、クラスターに接続する {#set-up-a-private-endpoint-connection-and-connect-to-your-cluster} diff --git a/tidb-cloud/set-up-vpc-peering-connections.md b/tidb-cloud/set-up-vpc-peering-connections.md index 57db4051f9321..1d53e0ab26c6d 100644 --- a/tidb-cloud/set-up-vpc-peering-connections.md +++ b/tidb-cloud/set-up-vpc-peering-connections.md @@ -188,7 +188,7 @@ AWS CLI または AWS ダッシュボードを使用して、VPC ピアリング aws ec2 modify-vpc-attribute --vpc-id "$app_vpc_id" --enable-dns-support ``` -設定が完了すると、VPCピアリングが作成されます。1 [TiDBクラスタに接続する](#connect-to-the-tidb-cluster)結果を確認できます。 +設定が完了すると、VPCピアリングが作成されます。[TiDBクラスタに接続する](#connect-to-the-tidb-cluster)ことで結果を確認できます。
    diff --git a/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md b/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md index 1ee6cbd51e14d..74fb14a2d267e 100644 --- a/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md +++ b/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md @@ -167,7 +167,7 @@ Kafka VPC を作成するには、次の手順を実行します。 4. 要塞サブネットをパブリック サブネットに構成します。 - 1. [VPCダッシュボード > インターネットゲートウェイ](https://console.aws.amazon.com/vpcconsole/home#igws:)に進みます。3 `kafka-vpc-igw`名前のインターネットゲートウェイを作成します。 + 1. [VPCダッシュボード > インターネットゲートウェイ](https://console.aws.amazon.com/vpcconsole/home#igws:)に進みます。`kafka-vpc-igw`名前のインターネットゲートウェイを作成します。 2. **インターネット ゲートウェイの詳細**ページの**アクション**で、 **VPC に接続を**クリックして、インターネット ゲートウェイを Kafka VPC に接続します。 @@ -301,7 +301,7 @@ Kafka VPC を作成するには、次の手順を実行します。 1. `listeners`項目の場合、3 つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 1. すべての**コントローラー**ロールノードに同じ CONTROLLER リスナーを設定します。**ブローカー**ロールノードのみを追加する場合は、 `server.properties`の CONTROLLER リスナーは必要ありません。 - 2. **ブローカー**リスナーを 2 つ構成します。3 `INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 + 2. **ブローカー**リスナーを 2 つ構成します。`INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 2. `advertised.listeners`項目については、次の操作を行います。 diff --git a/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md b/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md index 6aaad95a01548..155e9f5c0d230 100644 --- a/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md +++ b/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md @@ -314,7 +314,7 @@ summary: このドキュメントでは、Azure でセルフホスト型 Kafka consume_messages ``` -4. `produce.sh`と`consume.sh`スクリプトを実行します。これらのスクリプトは、接続とメッセージフローを自動的にテストし、Kafkaクラスターが正しく機能していることを確認します。5 `produce.sh`スクリプトは、 `--partitions 3 --replication-factor 3`でトピックを作成し、テストメッセージを送信し、 `--broker-list`パラメータを使用して3つのブローカーすべてに接続します。11 `consume.sh`スクリプトは、トピックからメッセージを読み取り、メッセージの配信が成功したことを確認します。 +4. `produce.sh`と`consume.sh`スクリプトを実行します。これらのスクリプトは、接続とメッセージフローを自動的にテストし、Kafkaクラスターが正しく機能していることを確認します。`produce.sh`スクリプトは、 `--partitions 3 --replication-factor 3`でトピックを作成し、テストメッセージを送信し、 `--broker-list`パラメータを使用して3つのブローカーすべてに接続します。11 `consume.sh`スクリプトは、トピックからメッセージを読み取り、メッセージの配信が成功したことを確認します。 ```shell # Test write message. 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..8e95574fcd428 100644 --- a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md +++ b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md @@ -16,9 +16,9 @@ summary: このドキュメントでは、Google Cloud でセルフホスト型 Google Cloud でセルフホスト型 Kafka に Private Service Connect を設定するには、次の 2 つの方法があります。 -- Private Service Connect（PSC）ポートマッピングメカニズムを使用します。この方法では、静的なポートブローカーマッピング設定が必要です。EXTERNALリスナーとアドバタイズリスナーのグループを追加するには、既存のKafkaクラスターを再構成する必要があります。1 [PSC ポート マッピングによるセルフホスト型 Kafka Private Service Connect サービスの設定](#set-up-self-hosted-kafka-private-service-connect-service-by-psc-port-mapping)参照してください。 +- Private Service Connect（PSC）ポートマッピングメカニズムを使用します。この方法では、静的なポートブローカーマッピング設定が必要です。EXTERNALリスナーとアドバタイズリスナーのグループを追加するには、既存のKafkaクラスターを再構成する必要があります。詳細は[PSC ポート マッピングによるセルフホスト型 Kafka Private Service Connect サービスの設定](#set-up-self-hosted-kafka-private-service-connect-service-by-psc-port-mapping)を参照してください。 -- [Kafkaプロキシ](https://github.com/grepplabs/kafka-proxy)使用してください。この方法では、Kafka クライアントと Kafka ブローカー間のプロキシとして、追加の実行プロセスが導入されます。プロキシはポートとブローカーのマッピングを動的に設定し、リクエストを転送します。既存の Kafka クラスターを再設定する必要はありません。3 [Kafka-proxy によるセルフホスト型 Kafka プライベート サービス接続のセットアップ](#set-up-self-hosted-kafka-private-service-connect-by-kafka-proxy)参照してください。 +- [Kafkaプロキシ](https://github.com/grepplabs/kafka-proxy)を使用してください。この方法では、Kafka クライアントと Kafka ブローカー間のプロキシとして、追加の実行プロセスが導入されます。プロキシはポートとブローカーのマッピングを動的に設定し、リクエストを転送します。既存の Kafka クラスターを再設定する必要はありません。詳細は[Kafka-proxy によるセルフホスト型 Kafka プライベート サービス接続のセットアップ](#set-up-self-hosted-kafka-private-service-connect-by-kafka-proxy)を参照してください。 このドキュメントでは、Google Cloud の 3 つのアベイラビリティゾーン（AZ）にデプロイされた Kafka Private Service Connect サービスへの接続例を示します。同様のポートマッピング原則に基づいて他の構成も可能ですが、このドキュメントでは Kafka Private Service Connect サービスの基本的な設定プロセスについて説明します。本番環境では、運用の保守性と可観測性を強化した、より回復力の高い Kafka Private Service Connect サービスの使用を推奨します。 @@ -657,7 +657,7 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが - **IPv4 範囲**: ネットワーク計画に基づいて CIDR を設定します - **承認されたプロジェクト**: [前提条件](#prerequisites)で取得したTiDB Cloudの Google Cloud プロジェクト (例: `tidbcloud-prod-000` )。 -3. **kafka-proxy-psc**の詳細ページに移動します。3 （例： `projects/tidbcloud-dp-stg-000/regions/us-west1/serviceAttachments/kafka-proxy-psc` ） `Service attachment`メモします。これは、 TiDB Cloudがこの PSC に接続する際に使用されます。 +3. **kafka-proxy-psc**の詳細ページに移動します。 `Service attachment` （例： `projects/tidbcloud-dp-stg-000/regions/us-west1/serviceAttachments/kafka-proxy-psc` ）をメモします。これは、 TiDB Cloudがこの PSC に接続する際に使用されます。 4. VPC ネットワークの詳細ページに移動し、すべてのブローカーの PSC トラフィックを許可するファイアウォール ルールを追加します。 diff --git a/tidb-cloud/sql-proxy-account.md b/tidb-cloud/sql-proxy-account.md index 3d156a9e0e6f1..da0ca6710a975 100644 --- a/tidb-cloud/sql-proxy-account.md +++ b/tidb-cloud/sql-proxy-account.md @@ -26,7 +26,7 @@ SQL プロキシ アカウントの主な利点は次のとおりです。 SELECT user FROM user WHERE plugin = 'tidb_auth_token'; ``` -2. SQLアカウントの権限を確認してください。1、3、5 `role_admin`のロール`role_readonly`リストさ`role_readwrite`ている場合は、SQLプロキシアカウントです。 +2. SQLアカウントの権限を確認してください。`role_admin` 、 `role_readonly` 、 `role_readwrite`などのロールがリストされている場合は、SQLプロキシアカウントです。 ```sql SHOW GRANTS for 'username'; diff --git a/tidb-cloud/terraform-use-cluster-resource.md b/tidb-cloud/terraform-use-cluster-resource.md index 010b5bbaf1357..67a8e748f121c 100644 --- a/tidb-cloud/terraform-use-cluster-resource.md +++ b/tidb-cloud/terraform-use-cluster-resource.md @@ -387,7 +387,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを ``` -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_cluster.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_cluster.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_cluster.example_cluster @@ -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 @@ -592,7 +592,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の 1. [クラスターを作成する](#create-a-cluster-using-the-cluster-resource)際に使用される`cluster.tf`ファイルで、 `components`構成を編集します。 - たとえば、TiDB 用にさらに 1 つのノード、TiKV 用にさらに 3 つのノード (TiKV ノードの数は、ステップが 3 であるため 3 の倍数である必要があります[クラスタ仕様からこの情報を取得します](#get-cluster-specification-information-using-the-tidbcloud_cluster_specs-data-source)することができます)、およびTiFlash用にさらに 1 つのノードを追加するには、次のように構成を編集します。 + たとえば、TiDB 用にさらに 1 つのノード、TiKV 用にさらに 3 つのノード (TiKV ノードの数は、ステップが 3 であるため 3 の倍数である必要があります。[クラスタ仕様からこの情報を取得](#get-cluster-specification-information-using-the-tidbcloud_cluster_specs-data-source)することができます)、およびTiFlash用にさらに 1 つのノードを追加するには、次のように構成を編集します。 components = { tidb = { @@ -762,7 +762,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の ... } -5. `terraform apply`コマンドを実行し、確認のために`yes`入力します。5 コマンドでステータスを確認すると、 `RESUMING`になっていること`terraform state show tidbcloud_cluster.${resource-name}`わかります。 +5. `terraform apply`コマンドを実行し、確認のために`yes`入力します。 `terraform state show tidbcloud_cluster.${resource-name}`コマンドでステータスを確認すると、 `RESUMING`になっていることがわかります。 # tidbcloud_cluster.example_cluster: resource "tidbcloud_cluster" "example_cluster" { @@ -870,7 +870,7 @@ Terraform で管理されていない TiDB クラスターの場合は、イン status = "AVAILABLE" } -4. Terraformを使用してクラスタを管理するには、前の手順の出力を構成ファイルにコピーします。1 `id`と`status`行目はTerraformによって制御されるため、削除する必要があることに注意してください。 +4. Terraformを使用してクラスタを管理するには、前の手順の出力を構成ファイルにコピーします。`id`と`status`行目はTerraformによって制御されるため、削除する必要があることに注意してください。 resource "tidbcloud_cluster" "import_cluster" { cloud_provider = "AWS" diff --git a/tidb-cloud/terraform-use-dedicated-cluster-resource.md b/tidb-cloud/terraform-use-dedicated-cluster-resource.md index 99435bb0e6e88..8bf9e0df83f88 100644 --- a/tidb-cloud/terraform-use-dedicated-cluster-resource.md +++ b/tidb-cloud/terraform-use-dedicated-cluster-resource.md @@ -22,7 +22,7 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi ## tidbcloud_projectsデータソースを使用してプロジェクト ID を取得する {#get-project-ids-using-the-code-tidbcloud-projects-code-data-source} -各TiDB Cloud Dedicatedクラスタはプロジェクトに属します。TiDB Cloud Dedicatedクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。1 `project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 +各TiDB Cloud Dedicatedクラスタはプロジェクトに属します。TiDB Cloud Dedicatedクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。`project_id`が指定されていない場合は、デフォルトのプロジェクトが使用されます。 利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データ ソースを使用します。 @@ -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}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```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 diff --git a/tidb-cloud/terraform-use-dedicated-network-container-resource.md b/tidb-cloud/terraform-use-dedicated-network-container-resource.md index 2ce47a033315f..eb4683e4df7b3 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}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_dedicated_network_container.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 1d1cb2b4b75ef..fca4f9e4c1dc7 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}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_dedicated_private_endpoint_connection.example diff --git a/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md b/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md index 65e7e2d7b91c1..0f58a5b6a198c 100644 --- a/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md +++ b/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md @@ -117,7 +117,7 @@ summary: tidbcloud_dedicated_vpc_peering` リソースを使用して、 TiDB Cl クラウドプロバイダーのコンソールでVPCピアリング接続を承認するまで、リソースのステータスは`Creating`ままです。VPCピアリング接続を承認すると、ステータスは[VPC ピアリングの承認と設定](/tidb-cloud/set-up-vpc-peering-connections.md#step-2-approve-and-configure-the-vpc-peering)基準に`Active`に変わります。 -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_vpc_peering.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_vpc_peering.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_dedicated_vpc_peering.example diff --git a/tidb-cloud/terraform-use-import-resource.md b/tidb-cloud/terraform-use-import-resource.md index eb23c6f674a23..f206bc83192f4 100644 --- a/tidb-cloud/terraform-use-import-resource.md +++ b/tidb-cloud/terraform-use-import-resource.md @@ -66,7 +66,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク file_name = "your_csv_path" } - ファイル内のリソース値（プロジェクトID、クラスタID、CSVパスなど）をご自身のものに置き換えてください。1 の詳細は`csv_format` [設定ページ](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/import#nested-schema-for-csv_format)記載されています。 + ファイル内のリソース値（プロジェクトID、クラスタID、CSVパスなど）をご自身のものに置き換えてください。 `csv_format`の詳細は [設定ページ](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/import#nested-schema-for-csv_format)に記載されています。 3. `terraform apply`コマンドを実行してインポート タスクを作成し、 `yes`入力して作成を確認し、インポートを開始します。 diff --git a/tidb-cloud/terraform-use-serverless-branch-resource.md b/tidb-cloud/terraform-use-serverless-branch-resource.md index 613b19fb40f39..ea2bb0d8f3439 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}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_branch.example 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..a95a04541cf2a 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md @@ -22,7 +22,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Ess ## tidbcloud_projectsデータソースを使用してプロジェクト ID を取得する {#get-project-ids-using-the-code-tidbcloud-projects-code-data-source} -各TiDBクラスタはプロジェクトに属します。TiDB Cloud Essentialクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。1 `project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 +各TiDBクラスタはプロジェクトに属します。TiDB Cloud Essentialクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。`project_id`が指定されていない場合は、デフォルトのプロジェクトが使用されます。 利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データ ソースを使用します。 @@ -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}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```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}`を使用してリソースの状態を確認します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_cluster.example diff --git a/tidb-cloud/terraform-use-serverless-cluster-resource.md b/tidb-cloud/terraform-use-serverless-cluster-resource.md index dfaffd90e0145..b79480541e853 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource.md @@ -22,7 +22,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Sta ## tidbcloud_projectsデータソースを使用してプロジェクト ID を取得する {#get-project-ids-using-the-code-tidbcloud-projects-code-data-source} -各TiDBクラスタはプロジェクトに属します。TiDB Cloud Starterクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。1 `project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 +各TiDBクラスタはプロジェクトに属します。TiDB Cloud Starterクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。`project_id`が指定されていない場合は、デフォルトのプロジェクトが使用されます。 利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データ ソースを使用します。 @@ -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}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```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}`を使用してリソースの状態を確認します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_cluster.example diff --git a/tidb-cloud/terraform-use-serverless-export-resource.md b/tidb-cloud/terraform-use-serverless-export-resource.md index 89e97acf90898..22cfc4d059f92 100644 --- a/tidb-cloud/terraform-use-serverless-export-resource.md +++ b/tidb-cloud/terraform-use-serverless-export-resource.md @@ -15,7 +15,7 @@ summary: tidbcloud_serverless_export` リソースを使用して、 TiDB Cloud > **Note:** > -> `tidbcloud_serverless_export`リソースは変更できません。3 `tidbcloud_serverless_export`のリソースの設定を変更する場合は、既存のリソースを削除してから、新しいリソースを作成する必要があります。 +> `tidbcloud_serverless_export`リソースは変更できません。`tidbcloud_serverless_export`のリソースの設定を変更する場合は、既存のリソースを削除してから、新しいリソースを作成する必要があります。 ## 前提条件 {#prerequisites} @@ -115,9 +115,9 @@ summary: tidbcloud_serverless_export` リソースを使用して、 TiDB Cloud この例では、 `tidbcloud_serverless_export.example`リソースがクラスター全体からデータをエクスポートするエクスポート タスクを作成します。 - このリソースは同期されていません。1 `terraform refresh`使用すると最新の状態を取得できます。 + このリソースは同期されていません。`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}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_export.example diff --git a/tidb-cloud/terraform-use-sql-user-resource.md b/tidb-cloud/terraform-use-sql-user-resource.md index f882364a431f6..543f2772e7651 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}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```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: @@ -189,7 +189,7 @@ summary: tidbcloud_sql_user` リソースを使用してTiDB Cloud SQL ユーザ user_name = "example_user" } -`builtin_role` `role_readonly`に変更されます。5 `password`センシティブな値であるため表示されません。 +`builtin_role` `role_readonly`に変更されます。`password`センシティブな値であるため表示されません。 ## SQLユーザーをインポートする {#import-a-sql-user} diff --git a/tidb-cloud/ticloud-cluster-create.md b/tidb-cloud/ticloud-cluster-create.md index 5fcd0eb1f74d8..bac9e7ec94dda 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 文字列 | クラウドリージョンの名前を指定します。 `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-import-start.md b/tidb-cloud/ticloud-import-start.md index d799ca121d687..89d9fafd70a09 100644 --- a/tidb-cloud/ticloud-import-start.md +++ b/tidb-cloud/ticloud-import-start.md @@ -76,9 +76,9 @@ ticloud serverless import start --source-type AZURE_BLOB --azblob.uri .blob.core.windows.net//`形式で指定します。 | いいえ | 非対話型モードでのみ動作します。 | | | | | --gcs.サービスアカウントキー文字列 | GCS の base64 でエンコードされたサービス アカウント キーを指定します。 | いいえ | 非対話型モードでのみ動作します。 | | | | | --gcs.uri 文字列 | GCS URIを`gcs:///`形式で指定します。ソースタイプがGCSの場合は必須です。 | はい | 非対話型モードでのみ動作します。 | | | | -| --s3.アクセスキーID文字列 | Amazon S3のアクセスキーIDを指定します。1と[ `s3.access-key-id` ] `s3.secret-access-key` `s3.role-arn`か1つだけ設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | -| --s3.role-arn 文字列 | Amazon S3のロールARNを指定します。1と[ `s3.access-key-id` ] `s3.secret-access-key` `s3.role-arn`か1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | -| --s3.secret-access-key 文字列 | Amazon S3のシークレットアクセスキーを指定します。1と[ `s3.access-key-id` ] `s3.secret-access-key` `s3.role-arn`か1つだけ設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | +| --s3.アクセスキーID文字列 | Amazon S3のアクセスキーIDを指定します。`s3.role-arn`と[ `s3.access-key-id` , `s3.secret-access-key` ]のいずれか1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | +| --s3.role-arn 文字列 | Amazon S3のロールARNを指定します。`s3.role-arn`と[ `s3.access-key-id` , `s3.secret-access-key` ]のいずれか1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | +| --s3.secret-access-key 文字列 | Amazon S3のシークレットアクセスキーを指定します。`s3.role-arn`と[ `s3.access-key-id` , `s3.secret-access-key` ]のいずれか1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | | --s3.uri 文字列 | S3 URIを`s3:///`形式で指定します。ソースタイプがS3の場合は必須です。 | はい | 非対話型モードでのみ動作します。 | | | | | --source-type 文字列 | インポートソースの種類を [ `"LOCAL"` `"S3"` `"GCS"` `"AZURE_BLOB"` ] のいずれかで指定します。デフォルト値は`"LOCAL"`です。 | いいえ | 非対話型モードでのみ動作します。 | | | | | -c, --cluster-id 文字列 | クラスター ID を指定します。 | はい | 非対話型モードでのみ動作します。 | | | | diff --git a/tidb-cloud/ticloud-serverless-audit-log-config-update.md b/tidb-cloud/ticloud-serverless-audit-log-config-update.md index 864bfca8692f0..d4515fb84e253 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-config-update.md +++ b/tidb-cloud/ticloud-serverless-audit-log-config-update.md @@ -59,9 +59,9 @@ ticloud serverless audit-log config update -c --enabled=false | --oss.uri 文字列 | `oss:///`形式の Alibaba Cloud OSS URI。 | いいえ | 非対話型モードでのみ動作します。 | | --rotation-interval-minutes int32 | ローテーション間隔（分）。有効な範囲： `[10, 1440]` 。 | いいえ | 非対話型モードでのみ動作します。 | | --rotation-size-mib int32 | 回転サイズ（MiB）。有効な範囲： `[1, 1024]` 。 | いいえ | 非対話型モードでのみ動作します。 | -| --s3.アクセスキーID文字列 | Amazon S3のアクセスキーID。 `--s3.role-arn`いずれか、または`--s3.access-key-id`と`--s3.secret-access-key`両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | -| --s3.role-arn 文字列 | Amazon S3 のロール ARN。 `--s3.role-arn`いずれか、または`--s3.access-key-id`と`--s3.secret-access-key`両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | -| --s3.secret-access-key 文字列 | Amazon S3のシークレットアクセスキー。1 `--s3.role-arn`いずれか、または`--s3.access-key-id`と`--s3.secret-access-key`両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | +| --s3.アクセスキーID文字列 | Amazon S3のアクセスキーID。 `--s3.role-arn`のいずれか、または`--s3.access-key-id`と`--s3.secret-access-key`の両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | +| --s3.role-arn 文字列 | Amazon S3 のロール ARN。 `--s3.role-arn`のいずれか、または`--s3.access-key-id`と`--s3.secret-access-key`の両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | +| --s3.secret-access-key 文字列 | Amazon S3のシークレットアクセスキー。`--s3.role-arn`のいずれか、または`--s3.access-key-id`と`--s3.secret-access-key`の両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | --s3.uri 文字列 | `s3:///`形式の Amazon S3 URI。 | いいえ | 非対話型モードでのみ動作します。 | | --unredacted | データベース監査ログを編集解除または編集します。 | いいえ | 非対話型モードでのみ動作します。 | | -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | diff --git a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md index ccdba05c3726b..7124e7a1dd6a2 100644 --- a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md +++ b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md @@ -45,7 +45,7 @@ CMEK 対応プロジェクトを作成するには、次の手順に従います
    -この手順は、TiDB Cloud APIを使用して[CMEK 対応プロジェクトを作成する](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Project/operation/CreateProject)エンドポイント経由で完了できます。3フィールド`aws_cmek_enabled` `true`に設定されていることを確認してください。 +この手順は、TiDB Cloud APIを使用して[CMEK 対応プロジェクトを作成する](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Project/operation/CreateProject)エンドポイント経由で完了できます。`aws_cmek_enabled`フィールドが`true`に設定されていることを確認してください。 現在、 TiDB Cloud APIはパブリックプレビューです。詳細については、 [TiDB Cloud API ドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)をご覧ください。 diff --git a/tidb-cloud/tidb-cloud-htap-quickstart.md b/tidb-cloud/tidb-cloud-htap-quickstart.md index e1917f1704e91..258733e494214 100644 --- a/tidb-cloud/tidb-cloud-htap-quickstart.md +++ b/tidb-cloud/tidb-cloud-htap-quickstart.md @@ -62,8 +62,8 @@ SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_ID, REPLICA_COUNT, LOCATION_LABELS, AVAIL 上記のステートメントの結果は次のようになります。 -- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。2 `1`利用可能、 `0`利用不可を意味します。レプリカが利用可能になると、このステータスは変更されません。 -- `PROGRESS`レプリケーションの進行状況を表します。値は`0`から`1`までです。6 `1`少なくとも1つのレプリカがレプリケートされていることを意味します。 +- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。`1`利用可能、 `0`利用不可を意味します。レプリカが利用可能になると、このステータスは変更されません。 +- `PROGRESS`レプリケーションの進行状況を表します。値は`0`から`1`までです。`1`少なくとも1つのレプリカがレプリケートされていることを意味します。 ### ステップ2. HTAPを使用してデータをクエリする {#step-2-query-data-using-htap} diff --git a/tidb-cloud/tidb-cloud-poc.md b/tidb-cloud/tidb-cloud-poc.md index 94b5c34b7da95..102ca8e26a13b 100644 --- a/tidb-cloud/tidb-cloud-poc.md +++ b/tidb-cloud/tidb-cloud-poc.md @@ -47,7 +47,7 @@ PoC の目標を特定するには、次の質問を参考にしてください ## ステップ2. ワークロードの特性を特定する {#step-2-identify-characteristics-of-your-workload} -TiDB Cloudは、高可用性と大容量データの強力な整合性が求められる様々なユースケースに適しています。1 [TiDB の紹介](https://docs.pingcap.com/tidb/stable/overview)主要な機能とシナリオをリストアップしました。お客様のビジネスシナリオに当てはまるかどうかご確認ください。 +TiDB Cloudは、高可用性と大容量データの強力な整合性が求められる様々なユースケースに適しています。[TiDB の紹介](https://docs.pingcap.com/tidb/stable/overview)では、主要な機能とシナリオをリストアップしました。お客様のビジネスシナリオに当てはまるかどうかご確認ください。 - 水平方向のスケールアウトまたはスケールイン - 金融グレードの高可用性 @@ -143,10 +143,10 @@ TiDB Cloudにはさまざまな形式のデータをインポートできます ワークロードを開始した後、次の方法を使用してシステムを観察できます。 -- クラスターの一般的なメトリクスは、クラスター概要ページで確認できます。これには、合計QPS、レイテンシ、接続数、 TiFlashリクエストQPS、 TiFlashリクエスト期間、 TiFlashストレージサイズ、TiKVストレージサイズ、TiDB CPU、TiKV CPU、TiKV IO読み取り、TiKV IO書き込みが含まれます。1 [TiDBクラスタを監視する](/tidb-cloud/monitor-tidb-cluster.md)参照してください。 -- クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページ目に移動し、 **「SQLステートメント」**タブを確認してください。ここでは、システムテーブルをクエリすることなく、SQL実行を監視し、パフォーマンスの問題を簡単に特定できます。5 [ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis)参照してください。 -- クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページ目に移動し、 **「Key Visualizer」**タブでTiDBのデータアクセスパターンとデータホットスポットを確認できます[Key Visualizer](/tidb-cloud/tune-performance.md#key-visualizer)参照してください。 -- これらのメトリクスを独自のDatadogおよびPrometheusに統合することもできます。1 [サードパーティの監視統合](/tidb-cloud/third-party-monitoring-integrations.md)参照してください。 +- クラスターの一般的なメトリクスは、クラスター概要ページで確認できます。これには、合計QPS、レイテンシ、接続数、 TiFlashリクエストQPS、 TiFlashリクエスト期間、 TiFlashストレージサイズ、TiKVストレージサイズ、TiDB CPU、TiKV CPU、TiKV IO読み取り、TiKV IO書き込みが含まれます。詳細は[TiDBクラスタを監視する](/tidb-cloud/monitor-tidb-cluster.md)を参照してください。 +- クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページに移動し、 **「SQLステートメント」**タブを確認してください。ここでは、システムテーブルをクエリすることなく、SQL実行を監視し、パフォーマンスの問題を簡単に特定できます。詳細は[ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis)を参照してください。 +- クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページに移動し、 **「Key Visualizer」**タブでTiDBのデータアクセスパターンとデータホットスポットを確認できます。詳細は[Key Visualizer](/tidb-cloud/tune-performance.md#key-visualizer)を参照してください。 +- これらのメトリクスを独自のDatadogおよびPrometheusに統合することもできます。詳細は[サードパーティの監視統合](/tidb-cloud/third-party-monitoring-integrations.md)を参照してください。 次はテスト結果を評価する時です。 @@ -180,7 +180,7 @@ TiDB Cloudにはさまざまな形式のデータをインポートできます - アップグレード - TiDB CloudはTiDBクラスタを定期的にアップグレードします。また、サポートチケットを送信してクラスタのアップグレードをリクエストすることもできます。1 [TiDBクラスタのアップグレード](/tidb-cloud/upgrade-tidb-cluster.md)ご覧ください。 + TiDB CloudはTiDBクラスタを定期的にアップグレードします。また、サポートチケットを送信してクラスタのアップグレードをリクエストすることもできます。詳細は[TiDBクラスタのアップグレード](/tidb-cloud/upgrade-tidb-cluster.md)をご覧ください。 - バックアップ diff --git a/tidb-cloud/tidb-node-group-management.md b/tidb-cloud/tidb-node-group-management.md index 5525c8afdc04a..3a5853b97a747 100644 --- a/tidb-cloud/tidb-node-group-management.md +++ b/tidb-cloud/tidb-node-group-management.md @@ -57,7 +57,7 @@ TiDB ノード グループを作成するには、次の手順を実行しま デフォルトでは、 TiDB Cloud Dedicated クラスターに最大 5 つの TiDB ノードグループを作成できます。さらにグループが必要な場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 -TiDBノードグループを作成しても、デフォルトグループのエンドポイントを使用してクラスターに接続すると、TiDBノードグループ内のTiDBノードはワークロードを引き受けることができず、リソースが無駄になります。新しいTiDBノードグループ内のTiDBノードへの新しい接続を作成する必要があります。1 [TiDBノードグループに接続する](#connect-to-a-tidb-node-group)参照してください。 +TiDBノードグループを作成しても、デフォルトグループのエンドポイントを使用してクラスターに接続すると、TiDBノードグループ内のTiDBノードはワークロードを引き受けることができず、リソースが無駄になります。新しいTiDBノードグループ内のTiDBノードへの新しい接続を作成する必要があります。[TiDBノードグループに接続する](#connect-to-a-tidb-node-group)を参照してください。 ## TiDBノードグループに接続する {#connect-to-a-tidb-node-group} diff --git a/tidb-cloud/troubleshoot-import-access-denied-error.md b/tidb-cloud/troubleshoot-import-access-denied-error.md index 3af80baf032c9..13c4f9f79afe8 100644 --- a/tidb-cloud/troubleshoot-import-access-denied-error.md +++ b/tidb-cloud/troubleshoot-import-access-denied-error.md @@ -150,7 +150,7 @@ IAMユーザーのポリシーを確認するには、次の手順を実行し - `"arn:aws:s3:::tidb-cloud-source-data/mydata/*"`の`"arn:aws:s3:::tidb-cloud-source-data"`はサンプルの S3 バケット ARN で、 `/mydata/*`データストレージ用に S3 バケットのルートレベルでカスタマイズできるディレクトリです。ディレクトリの末尾は`/*` （例： `"//*"` ）でなければなりません。 `/*`追加されていない場合、 `AccessDenied`エラーが発生します。 -- カスタマー管理のキー暗号化で AWS Key Management Service キー (SSE-KMS) を有効にしている場合は、次の設定がポリシーに含まれていることを確認してください。1 `"arn:aws:kms:ap-northeast-1:105880447796:key/c3046e91-fdfc-4f3a-acff-00597dd3801f"`バケットのサンプル KMS キーです。 +- カスタマー管理のキー暗号化で AWS Key Management Service キー (SSE-KMS) を有効にしている場合は、次の設定がポリシーに含まれていることを確認してください。`"arn:aws:kms:ap-northeast-1:105880447796:key/c3046e91-fdfc-4f3a-acff-00597dd3801f"`バケットのサンプル KMS キーです。 { "Sid": "AllowKMSkey", diff --git a/tidb-cloud/use-chat2query-api.md b/tidb-cloud/use-chat2query-api.md index ddad2ea0241aa..07842a5d8ec2c 100644 --- a/tidb-cloud/use-chat2query-api.md +++ b/tidb-cloud/use-chat2query-api.md @@ -11,7 +11,7 @@ Chat2Query API には HTTPS 経由でのみアクセスできるため、ネッ > **Note:** > -> Chat2Query APIはAWSでホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターでのみ利用可能です。3 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでChat2Query APIをご利用いただくには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 +> Chat2Query APIはAWSでホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターでのみ利用可能です。[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでChat2Query APIをご利用いただくには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 ## 始める前に {#before-you-begin} @@ -157,7 +157,7 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://.data.dev.tidbcloud.com/api/v1beta/app/chat2query-/endpoint/v2/jobs/{job_id}'\ @@ -353,7 +353,7 @@ TiDB Cloudデータ サービスは、次の Chat2Query v1 エンドポイント | -- | --------------- | ------------------------------------------------------------------------ | | 役職 | `/v1/chat2data` | このエンドポイントを使用すると、ターゲット データベース名と指示を指定して、人工知能を使用して SQL ステートメントを生成および実行できます。 | -`/v1/chat2data`エンドポイントを直接呼び出して、SQL文を生成・実行できます。3 と比較すると、 `/v2/chat2data` `/v1/chat2data`レスポンスが速くなりますが、パフォーマンスは低くなります。 +`/v1/chat2data`エンドポイントを直接呼び出して、SQL文を生成・実行できます。 `/v2/chat2data`と比較すると、 `/v1/chat2data`はレスポンスが速くなりますが、パフォーマンスは低くなります。 TiDB Cloudは、エンドポイントの呼び出しを支援するためのコードサンプルを生成します。サンプルコードを入手して実行するには、 [エンドポイントのコード例を取得する](#get-the-code-example-of-an-endpoint)参照してください。 diff --git a/tidb-cloud/use-chat2query-knowledge.md b/tidb-cloud/use-chat2query-knowledge.md index da9b2336217fe..ea9d82183b33b 100644 --- a/tidb-cloud/use-chat2query-knowledge.md +++ b/tidb-cloud/use-chat2query-knowledge.md @@ -11,7 +11,7 @@ v3 以降、Chat2Query API を使用すると、Chat2Query データ アプリ > **Note:** > -> ナレッジベース関連エンドポイントは、AWS でホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターでのみご利用いただけます。3 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでナレッジベース関連エンドポイントをご利用になる場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 +> ナレッジベース関連エンドポイントは、AWS でホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターでのみご利用いただけます。[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでナレッジベース関連エンドポイントをご利用になる場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 ## 始める前に {#before-you-begin} diff --git a/tidb-cloud/use-chat2query-sessions.md b/tidb-cloud/use-chat2query-sessions.md index f10adb8defed1..b3d16df184bc0 100644 --- a/tidb-cloud/use-chat2query-sessions.md +++ b/tidb-cloud/use-chat2query-sessions.md @@ -83,7 +83,7 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://eu-cen - `question` :*文字列*。必要なクエリを説明する自然言語での質問。 - `feedback_answer_id` ：*文字列*。フィードバック回答ID。このフィールドはオプションであり、フィードバックにのみ使用されます。 - `feedback_task_id` ：*文字列*。フィードバックタスクID。このフィールドはオプションであり、フィードバックにのみ使用されます。 -- `sql_generate_mode` :*文字列*。SQL文を生成するモード。値は`direct`または`auto_breakdown`です。8 `direct`設定すると、APIは指定された`question` SQL文に基づいて直接SQL文を生成します。12 に設定すると、APIは`auto_breakdown` `question` SQL文を複数のタスクに分割し、各タスクごとにSQL文を生成します。 +- `sql_generate_mode` :*文字列*。SQL文を生成するモード。値は`direct`または`auto_breakdown`です。 `direct`に設定すると、APIは指定された`question`に基づいて直接SQL文を生成します。 `auto_breakdown`に設定すると、APIは`question`を複数のタスクに分割し、各タスクごとにSQL文を生成します。 応答の例は次のとおりです。 diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md index 02575a6e778e0..8a5a8dfbce427 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md @@ -57,7 +57,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md index 5daacd14614b2..40c6505a9d33e 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md @@ -60,7 +60,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md index 5ce52edb6c354..c3b5655dba647 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md @@ -78,7 +78,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md index e9575f4d31436..62b83b1900ce9 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md @@ -61,7 +61,7 @@ aliases: ['/ja/tidbcloud/v7.1.0-performance-benchmarking-with-tpcc'] curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md index 0ceced3994d41..9ad6cca04b44d 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md @@ -78,7 +78,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md index 5421626304f9d..e948e3b307694 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md @@ -61,7 +61,7 @@ aliases: ['/ja/tidbcloud/v7.5.0-performance-benchmarking-with-tpcc'] curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md index 8980f911cdad8..695e9b2666fa4 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md @@ -83,7 +83,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md index 740934f9f0695..693e3f7b6b649 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md @@ -72,7 +72,7 @@ raft-engine.prefill-for-recycle = true curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md index 818a5a8f94f86..d2ffac8173dc1 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md @@ -83,7 +83,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md index 26163c48bb733..95b35c19874c5 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md @@ -72,7 +72,7 @@ raft-engine.prefill-for-recycle = true curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.5-performance-highlights.md b/tidb-cloud/v8.5-performance-highlights.md index 6ac47e8d77ae9..3b376197a2e23 100644 --- a/tidb-cloud/v8.5-performance-highlights.md +++ b/tidb-cloud/v8.5-performance-highlights.md @@ -72,7 +72,7 @@ TiDB v8.5.0 では、クラウド ディスク IO ジッターによるパフォ - **Leader書き込み最適化**: リーダーがコミットされたがまだ永続化されていないRaftログを早期に適用できるようにし、リーダー ピアの書き込みレイテンシーに対する IO ジッターの影響を軽減します。 -- **低速ノード検出の強化**：低速ノード検出アルゴリズムを改良し、デフォルトで低速スコア検出を有効にしました。これにより、低速ノードが特定されると、エビクトリーダースケジューラがトリガーされ、パフォーマンスが回復します。2 [遅いノード検出メカニズム](https://docs.pingcap.com/tidb/v8.5/pd-scheduling-best-practices#troubleshoot-tikv-node) [低速ストアの排除スケジューラ](https://docs.pingcap.com/tidb/v8.5/pd-control#scheduler-show--add--remove--pause--resume--config--describe)を使用して低速ノードを検出・管理し、クラウドディスクジッターの影響を軽減します。 +- **低速ノード検出の強化**：低速ノード検出アルゴリズムを改良し、デフォルトで低速スコア検出を有効にしました。これにより、低速ノードが特定されると、エビクトリーダースケジューラがトリガーされ、パフォーマンスが回復します。[遅いノード検出メカニズム](https://docs.pingcap.com/tidb/v8.5/pd-scheduling-best-practices#troubleshoot-tikv-node)は、 [低速ストアの排除スケジューラ](https://docs.pingcap.com/tidb/v8.5/pd-control#scheduler-show--add--remove--pause--resume--config--describe)を使用して低速ノードを検出・管理し、クラウドディスクジッターの影響を軽減します。 - **統合ヘルスコントローラー**：TiKVに統合ヘルスコントローラーを追加し、KVクライアントにフィードバックメカニズムを追加します。KVクライアントは、TiKVノードのヘルスとパフォーマンスに基づいて、エラー処理とレプリカ選択を最適化します。 diff --git a/tidb-computing.md b/tidb-computing.md index 7e07dd5d674d5..a9311e97097db 100644 --- a/tidb-computing.md +++ b/tidb-computing.md @@ -83,7 +83,7 @@ CREATE TABLE User ( t10_r2 --> ["TiKV", "KV Engine", 20] t10_r3 --> ["PD", " Manager", 30] -このテーブルには、主キーに加えて、一意ではない通常のセカンダリインデックス`idxAge`あります。3 `IndexID` `1`であるとすると、TiKV に保存されるインデックスデータは次のようになります。 +このテーブルには、主キーに加えて、一意ではない通常のセカンダリインデックス`idxAge`あります。`IndexID` `1`であるとすると、TiKV に保存されるインデックスデータは次のようになります。 t10_i1_10_1 --> null t10_i1_20_2 --> null @@ -109,7 +109,7 @@ TiDB の SQLレイヤーである TiDB サーバーは、SQL ステートメン SQL コンピューティングの最もシンプルなソリューションは、前のセクションで説明した[テーブルデータからキー値へのマッピング](#mapping-of-table-data-to-key-value)です。これは、SQL クエリを KV クエリにマッピングし、KV インターフェイスを介して対応するデータを取得し、さまざまな計算を実行します。 -例えば、SQL文`select count(*) from user where name = "TiDB"`を実行するには、TiDBはテーブル内のすべてのデータを読み取り、フィールド`name`が`TiDB`かどうかを確認し、5であればその行を返します。このプロセスは以下のとおりです。 +例えば、SQL文`select count(*) from user where name = "TiDB"`を実行するには、TiDBはテーブル内のすべてのデータを読み取り、フィールド`name`が`TiDB`かどうかを確認し、そうであればその行を返します。このプロセスは以下のとおりです。 1. キー範囲を構築します。表内のすべての`RowID` `[0, MaxInt64)`範囲に含まれます。行データの`Key`エンコード規則に従って、 `0`と`MaxInt64`を使用すると、左閉じ、右開きの`[StartKey, EndKey)`範囲を構築できます。 2. キー範囲のスキャン: 上記で構築されたキー範囲に従って TiKV 内のデータを読み取ります。 diff --git a/tidb-control.md b/tidb-control.md index 0ff921d40b43d..a65ec62ac269d 100644 --- a/tidb-control.md +++ b/tidb-control.md @@ -140,7 +140,7 @@ tidb-ctl schema in #### tidサブコマンド {#the-code-tid-code-subcommand} -`tid` 、データベース全体で一意の`table_id`を使用してテーブルスキーマを取得するために使用されます。4 `in`コマンドを使用して特定のスキーマのすべてのテーブルIDを取得し、 `tid`サブコマンドを使用して詳細なテーブル情報を取得できます。 +`tid` 、データベース全体で一意の`table_id`を使用してテーブルスキーマを取得するために使用されます。`in`コマンドを使用して特定のスキーマのすべてのテーブルIDを取得し、 `tid`サブコマンドを使用して詳細なテーブル情報を取得できます。 例えば、テーブルID `mysql.stat_meta`は`21`です。テーブルID `tidb-ctl schema tid -i 21`を使用すると、テーブルID `mysql.stat_meta`の詳細を取得できます。 @@ -267,7 +267,7 @@ tidb-ctl base64decode [table_id] [base64_data] 実際には、 KEY が`/tidb/ddl/all_schema_versions/foo`で VALUE が`bar`あるキーと値のペアが etcd に追加されます。 -- `tidb-ctl etcd delkey` etcd 内の KEY を削除します。2 または`/tidb/ddl/fg/owner/` `/tidb/ddl/all_schema_versions/`プレフィックスを持つ KEY のみ削除できます。 +- `tidb-ctl etcd delkey` etcd 内の KEY を削除します。`/tidb/ddl/fg/owner/`または`/tidb/ddl/all_schema_versions/`プレフィックスを持つ KEY のみ削除できます。 ```shell tidb-ctl etcd delkey "/tidb/ddl/fg/owner/foo" @@ -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行形式です。`tidb-ctl log`を指定すると、複数行形式に変更できます。 ### keyrangeコマンド {#the-code-keyrange-code-command} diff --git a/tidb-external-ts.md b/tidb-external-ts.md index 7698f2dd9484f..353503ebe9659 100644 --- a/tidb-external-ts.md +++ b/tidb-external-ts.md @@ -15,7 +15,7 @@ summary: tidb_external_ts` 変数を使用して履歴データを読み取る システム変数[`tidb_external_ts`](/system-variables.md#tidb_external_ts-new-in-v640) 、 `tidb_enable_external_ts_read`が有効な場合に読み取る履歴データのタイムスタンプを指定します。 -システム変数[`tidb_enable_external_ts_read`](/system-variables.md#tidb_enable_external_ts_read-new-in-v640) 、履歴データを現在のセッションで読み取るか、グローバルで読み取るかを制御します。デフォルト値は`OFF`で、履歴データの読み取り機能は無効であり、 `tidb_external_ts`は無視されます。7 `tidb_enable_external_ts_read`グローバルに`ON`に設定すると、すべてのクエリは`tidb_external_ts`で指定された時刻より前に履歴データを読み取ります。13 `tidb_enable_external_ts_read`特定のセッションのみ`ON`に設定すると、そのセッションのクエリのみが履歴データを読み取ります。 +システム変数[`tidb_enable_external_ts_read`](/system-variables.md#tidb_enable_external_ts_read-new-in-v640) 、履歴データを現在のセッションで読み取るか、グローバルで読み取るかを制御します。デフォルト値は`OFF`で、履歴データの読み取り機能は無効であり、 `tidb_external_ts`は無視されます。`tidb_enable_external_ts_read`グローバルに`ON`に設定すると、すべてのクエリは`tidb_external_ts`で指定された時刻より前に履歴データを読み取ります。13 `tidb_enable_external_ts_read`特定のセッションのみ`ON`に設定すると、そのセッションのクエリのみが履歴データを読み取ります。 `tidb_enable_external_ts_read`有効にすると、TiDB は読み取り専用になります。すべての書き込みクエリは`ERROR 1836 (HY000): Running in read-only mode`ようなエラーで失敗します。 diff --git a/tidb-global-sort.md b/tidb-global-sort.md index 9eb76bbea3586..3932527970c09 100644 --- a/tidb-global-sort.md +++ b/tidb-global-sort.md @@ -20,7 +20,7 @@ summary: TiDB グローバル ソートの使用例、制限、使用方法、 ## 概要 {#overview} -TiDBのグローバルソート機能は、データインポートとDDL（データ定義言語）操作の安定性と効率性を向上させます。1 [TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md)汎用演算子として機能し、クラウド上でグローバルソートサービスを提供します。 +TiDBのグローバルソート機能は、データインポートとDDL（データ定義言語）操作の安定性と効率性を向上させます。[TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md)の汎用演算子として機能し、クラウド上でグローバルソートサービスを提供します。 現在、グローバルソート機能は、クラウドストレージとして Amazon S3 の使用をサポートしています。 @@ -46,7 +46,7 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ -2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。3 [例](/br/backup-and-restore-storages.md)参照してください。 +2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。[例](/br/backup-and-restore-storages.md)を参照してください。 ```sql SET GLOBAL tidb_cloud_storage_uri = 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role' @@ -55,7 +55,7 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ -2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。3 [例](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)参照してください。 +2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。[例](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)を参照してください。 ```sql SET GLOBAL tidb_cloud_storage_uri = 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role' diff --git a/tidb-lightning/import-into-vs-tidb-lightning.md b/tidb-lightning/import-into-vs-tidb-lightning.md index 70ceb6cb370d4..ee3e08c76ec8f 100644 --- a/tidb-lightning/import-into-vs-tidb-lightning.md +++ b/tidb-lightning/import-into-vs-tidb-lightning.md @@ -7,9 +7,9 @@ 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文に段階的に統合してきました。`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のリリースノートおよびドキュメントで事前にお知らせいたします。 +`IMPORT INTO`はv7.2.0で導入され、v7.5.0で一般提供（GA）されます。今後のバージョンでも引き続き改良と最適化が行われます。`IMPORT INTO`機能がTiDB Lightningを完全に置き換えることが可能になった時点で、 TiDB Lightningは廃止されます。その際には、TiDBのリリースノートおよびドキュメントで事前にお知らせいたします。 ## IMPORT INTOとTiDB Lightningの比較 {#comparison-between-code-import-into-code-and-tidb-lightning} @@ -29,7 +29,7 @@ summary: IMPORT INTO` とTiDB Lightningの違いについて説明します。 #### `IMPORT INTO` {#import-into} -`IMPORT INTO`タスクと他のビジネスワークロードは、TiDB リソースを共有したり、異なるタイミングで利用したりすることで、TiDB リソースを最大限に活用できます。3 タスクのパフォーマンスと安定性を維持しながら、ビジネスワークロードの安定した運用を確保するために、 `IMPORT INTO`タスクにデータインポート専用の[特定のTiDBノード](/system-variables.md#tidb_service_scope-new-in-v740)を指定することができ`IMPORT INTO` 。 +`IMPORT INTO`タスクと他のビジネスワークロードは、TiDB リソースを共有したり、異なるタイミングで利用したりすることで、TiDB リソースを最大限に活用できます。`IMPORT INTO`タスクのパフォーマンスと安定性を維持しながら、ビジネスワークロードの安定した運用を確保するために、データインポート用に`IMPORT INTO`専用の[特定のTiDBノード](/system-variables.md#tidb_service_scope-new-in-v740)を指定することができます。 [TiDB グローバルソート](/tidb-global-sort.md)使用する場合、大容量のローカルディスクをマウントする必要はありません。TiDB Global Sort は Amazon S3 をstorageとして使用できます。インポートタスクが完了すると、グローバルソート用に Amazon S3 に保存された一時データは自動的に削除され、ストレージコストを節約できます。 diff --git a/tidb-lightning/monitor-tidb-lightning.md b/tidb-lightning/monitor-tidb-lightning.md index 058d5c0e97aff..4ed7b819769ea 100644 --- a/tidb-lightning/monitor-tidb-lightning.md +++ b/tidb-lightning/monitor-tidb-lightning.md @@ -11,7 +11,7 @@ summary: TiDB Lightningのモニター構成と監視メトリックについて TiDB Lightning を手動でインストールする場合は、以下の手順に従ってください。 -`tidb-lightning`のメトリクスは、Prometheus が検出済みであれば直接収集できます。3 のメトリクスポートは`tidb-lightning.toml`のように設定できます。 +`tidb-lightning`のメトリクスは、Prometheus が検出済みであれば直接収集できます。`tidb-lightning.toml`のメトリクスポートは次のように設定できます。 ```toml [lightning] diff --git a/tidb-lightning/tidb-lightning-command-line-full.md b/tidb-lightning/tidb-lightning-command-line-full.md index 097cb6ea851f9..c419f6369184e 100644 --- a/tidb-lightning/tidb-lightning-command-line-full.md +++ b/tidb-lightning/tidb-lightning-command-line-full.md @@ -20,7 +20,7 @@ TiDB Lightning は、設定ファイルまたはコマンドラインから設 | `-d ` | ローカル ディレクトリまたはデータ ファイルの[外部ストレージURI](/external-storage-uri.md) 。 | `mydumper.data-source-dir` | | `-L ` | ログ`info` : `debug` 、または`error` `warn`は`info` `fatal` 。 | `lightning.level` | | `-f ` | [テーブルフィルタルール](/table-filter.md) 。複数回指定できます。 | `mydumper.filter` | -| `--backend ` | インポート モードを選択します。1 は`local` 、 `tidb` [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)指します。 | `tikv-importer.backend` | +| `--backend ` | インポート モードを選択します。`local`は[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を、 `tidb`は[論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)を指します。 | `tikv-importer.backend` | | `--log-file ` | ログファイルのパス。デフォルトでは`/tmp/lightning.log.{timestamp}`です。「-」に設定すると、ログファイルは標準出力に出力されます。 | `lightning.log-file` | | `--status-addr ` | TiDB Lightning HTTPサーバーのリスニング アドレス | `lightning.status-addr` | | `--pd-urls ` | PDエンドポイントアドレス。v7.6.0以降、TiDBは複数のPDアドレスの設定をサポートします。 | `tidb.pd-addr` | diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index b09dda71f886f..b25ae3c722076 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -68,13 +68,13 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `index-concurrency` {#index-concurrency} -- 同時に開くインデックスエンジンの最大数。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。1と`table-concurrency` `index-concurrency`は、各エンジンタイプの最大同時実行数を制御します。通常はデフォルト値を使用してください。 +- 同時に開くインデックスエンジンの最大数。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時実行数を制御します。通常はデフォルト値を使用してください。 #### `table-concurrency` {#table-concurrency} -- 同時に開くことができるデータエンジンの最大数です。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。1と`table-concurrency` `index-concurrency`は、各エンジンタイプの最大同時接続数を制御します。通常はデフォルト値を使用してください。 +- 同時に開くことができるデータエンジンの最大数です。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時接続数を制御します。通常はデフォルト値を使用してください。 @@ -168,7 +168,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `keep-after-success` {#keep-after-success} -- すべてのデータのインポート後もチェックポイントを保持するかどうかを制御します。1 `false`場合、チェックポイントは削除されます。 +- すべてのデータのインポート後もチェックポイントを保持するかどうかを制御します。`false`の場合、チェックポイントは削除されます。 - チェックポイントを保持するとデバッグが容易になりますが、データ ソースに関するメタデータが漏洩します。 @@ -202,7 +202,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `threshold` {#threshold} -- [`strategy`](#strategy)が`"replace"`または`"ignore"`の場合に処理できる競合エラーの最大数を制御します。7 `strategy` `"replace"`または`"ignore"`場合のみ設定できます。 +- [`strategy`](#strategy)が`"replace"`または`"ignore"`の場合に処理できる競合エラーの最大数を制御します。`strategy`が`"replace"`または`"ignore"`の場合のみ設定できます。 - `10000`より大きい値を設定すると、インポートプロセスのパフォーマンスが低下する可能性があります。 - デフォルト値: `10000` @@ -241,7 +241,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - 物理インポート モードで重複レコード (一意キーの競合) を検出して解決するかどうかを制御します。 - デフォルト値: `'none'` - 値のオプション: - - `'none'` : 重複レコードを検出しません。データソースに重複レコードがある場合、ターゲットTiDBでデータの不整合が発生する可能性があります。2 `duplicate-resolution = 'none'`設定し、 `conflict.strategy`設定していない場合、 TiDB Lightningは自動的に`""`から`conflict.strategy`割り当てます。 + - `'none'` : 重複レコードを検出しません。データソースに重複レコードがある場合、ターゲットTiDBでデータの不整合が発生する可能性があります。`duplicate-resolution = 'none'`設定し、 `conflict.strategy`設定していない場合、 TiDB Lightningは自動的に`""`から`conflict.strategy`割り当てます。 - `'remove'` : `duplicate-resolution = 'remove'`設定し、 `conflict.strategy`設定しない場合、 TiDB Lightning は自動的に`conflict.strategy`に「置換」を割り当て、新しいバージョンの競合検出を有効にします。 #### `send-kv-pairs` {#send-kv-pairs} @@ -418,7 +418,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `max-region-size` {#max-region-size} -- [`strict-format`](#strict-format)が`true`の場合、 TiDB Lightning は大きな CSV ファイルを複数のチャンクに分割して並列処理します。5 `max-region-size`分割後の各チャンクの最大サイズです。 +- [`strict-format`](#strict-format)が`true`の場合、 TiDB Lightning は大きな CSV ファイルを複数のチャンクに分割して並列処理します。`max-region-size`分割後の各チャンクの最大サイズです。 - デフォルト値: `"256MiB"` #### `filter` {#filter} @@ -643,7 +643,7 @@ CSV ファイルの解析方法を構成します。 - `"optional"` : 管理者チェックサムを実行します。チェックサムに失敗した場合、 TiDB Lightning はWARN ログを報告しますが、エラーは無視されます。 - `"off"` : チェックサムを実行しません。 - チェックサムの失敗は通常、インポート例外（データの損失または不整合）を意味します。チェックサムは常に有効にすることをお勧めします。 -- 下位互換性のため、このフィールドでは bool 値`true`と`false`も許可されます。5 `true` `required`に相当し、 `false` `off`に相当します。 +- 下位互換性のため、このフィールドでは bool 値`true`と`false`も許可されます。`true` `required`に相当し、 `false` `off`に相当します。 #### `checksum-via-sql` {#checksum-via-sql} diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md index e6c86a3f801c3..f7a2bb20f7f82 100644 --- a/tidb-lightning/tidb-lightning-data-source.md +++ b/tidb-lightning/tidb-lightning-data-source.md @@ -52,7 +52,7 @@ rename srcdb. tgtdb. *.sql - データファイル`pattern`の一致ルールは`^({schema_regrex})\.({table_regrex})\.({file_serial_regrex})\.(csv|parquet|sql)`です。 - `schema`を`'$1'`と指定すると、最初の正規表現の値`schema_regrex`は変更されません。または、 `schema` `'tgtdb'`などの文字列として指定すると、固定のターゲットデータベース名になります。 - `table`を`'$2'`と指定すると、2番目の正規表現の値`table_regrex`は変更されません。または、 `table` `'t1'`などの文字列として指定すると、固定のターゲットテーブル名になります。 -- `type` `'$3'` （データファイルの種類）として指定します。5 `type` `"table-schema"` （ `schema.sql`ファイル）または`"schema-schema"` （ `schema-create.sql`ファイル）として指定できます。 +- `type` `'$3'` （データファイルの種類）として指定します。`type` `"table-schema"` （ `schema.sql`ファイル）または`"schema-schema"` （ `schema-create.sql`ファイル）として指定できます。 ```toml [mydumper] @@ -179,7 +179,7 @@ trim-last-separator = false #### `header` {#header} - *すべての*CSV ファイルにヘッダー行が含まれているかどうか。 -- `header`が`true`場合、最初の行は*列名*として使用されます。7 が`header` `false`場合、最初の行は通常のデータ行として扱われます。 +- `header`が`true`の場合、最初の行は*列名*として使用されます。`header`が`false`の場合、最初の行は通常のデータ行として扱われます。 #### not-nullとnull {#code-not-null-code-and-code-null-code} diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index 0730cfd4322ed..b2a23f31cb398 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -18,7 +18,7 @@ TiDB Lightning を使用すると、次のシナリオでデータを並列に > > - 並列インポートは、TiDB 内の初期化された空のテーブルのみをサポートし、既存のサービスによって書き込まれたデータを含むテーブルへのデータ移行はサポートしません。そうしないと、データの不整合が発生する可能性があります。 > -> - 並列インポートは通常、物理インポートモードで使用されます。1 `parallel-import = true`設定する必要があります。 +> - 並列インポートは通常、物理インポートモードで使用されます。`parallel-import = true`設定する必要があります。 > > - 複数のTiDB Lightningインスタンスを使用して同じターゲットにデータをインポートする場合は、一度に1つのバックエンドのみを適用してください。例えば、同じTiDBクラスターに物理インポートモードと論理インポートモードの両方で同時にデータをインポートすることはできません。 diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md index c60fbc0b02b40..e7c89482fb3e6 100644 --- a/tidb-lightning/tidb-lightning-faq.md +++ b/tidb-lightning/tidb-lightning-faq.md @@ -26,7 +26,7 @@ TiDB Lightningのバージョンはクラスターと同じである必要があ ## TiDB Lightningを適切に再起動するにはどうすればよいですか? {#how-to-properly-restart-tidb-lightning} 1. [`tidb-lightning`プロセスを停止する](#how-to-stop-the-tidb-lightning-process) 。 -2. 新しい`tidb-lightning`タスクを開始します。3 `nohup tiup tidb-lightning -config tidb-lightning.toml`の前の開始コマンドを実行します。 +2. 新しい`tidb-lightning`タスクを開始します。`nohup tiup tidb-lightning -config tidb-lightning.toml`の前の開始コマンドを実行します。 ## インポートされたデータの整合性を確保するにはどうすればよいですか? {#how-to-ensure-the-integrity-of-the-imported-data} diff --git a/tidb-lightning/tidb-lightning-requirements.md b/tidb-lightning/tidb-lightning-requirements.md index d32ffbb6eb69a..c4c9c4111c3d7 100644 --- a/tidb-lightning/tidb-lightning-requirements.md +++ b/tidb-lightning/tidb-lightning-requirements.md @@ -15,7 +15,7 @@ TiDB Lightningを使用する前に、環境が要件を満たしているかど ## 対象データベースのストレージスペース {#storage-space-of-the-target-database} -ターゲットTiKVクラスターには、インポートしたデータを保存するための十分なディスク容量が必要です。1 に加え[標準的なハードウェア要件](/hardware-and-software-requirements.md) 、ターゲットTiKVクラスターのストレージ容量**は、データソースのサイズ × レプリカ数 × 2**よりも大きくなければなりません。例えば、クラスターがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスターにはデータソースのサイズの6倍よりも大きなストレージ容量が必要です。式に x 2 が含まれているのは、以下の理由によるものです。 +ターゲットTiKVクラスターには、インポートしたデータを保存するための十分なディスク容量が必要です。[標準的なハードウェア要件](/hardware-and-software-requirements.md)に加え、ターゲットTiKVクラスターのストレージ容量**は、データソースのサイズ × レプリカ数 × 2**よりも大きくなければなりません。例えば、クラスターがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスターにはデータソースのサイズの6倍よりも大きなストレージ容量が必要です。式に x 2 が含まれているのは、以下の理由によるものです。 - インデックスは余分なスペースを占める可能性があります。 - RocksDB には空間増幅効果があります。 diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md index a202df09b9256..ec465c3d71781 100644 --- a/tidb-lightning/troubleshoot-tidb-lightning.md +++ b/tidb-lightning/troubleshoot-tidb-lightning.md @@ -70,7 +70,7 @@ tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode ### `checksum failed: checksum mismatched remote vs local` {#checksum-failed-checksum-mismatched-remote-vs-local} -**原因**: ローカルデータソースとリモートインポートデータベースのテーブルのチェックサムが異なります。このエラーには、より深刻な理由がいくつか考えられます。2 `checksum mismatched`含むログを確認することで、原因をさらに特定できます。 +**原因**: ローカルデータソースとリモートインポートデータベースのテーブルのチェックサムが異なります。このエラーには、より深刻な理由がいくつか考えられます。`checksum mismatched`含むログを確認することで、原因をさらに特定できます。 `checksum mismatched`を含む行は情報`total_kvs: x vs y`提供します。ここで、 `x`インポートの完了後にターゲット クラスターによって計算されたキーと値のペア (KV ペア) の数を示し、 `y`ローカル データ ソースによって生成されたキーと値のペアの数を示します。 @@ -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`を実行してインストールされているバージョンとアップデートの有無を確認します。`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} @@ -163,7 +163,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= TiDB Lightning Local-backend は、v4.0.0 以降のバージョンの TiDB クラスターへのデータインポートのみをサポートしています。Local-backend を使用して v2.x または v3.x クラスターにデータをインポートしようとすると、上記のエラーが報告されます。その場合は、設定を変更して、データのインポートに Importer-backend または TiDB-backend を使用するように設定できます。 -`nightly`バージョンの中には、v4.0.0-beta.2 に類似しているものもあります。これらの`nightly`バージョンのTiDB Lightning は、実際にはローカルバックエンドをサポートしています。5 バージョン`nightly`使用時にこのエラーが発生した場合は、設定`check-requirements = false`設定することでバージョンチェックを省略できます。このパラメータを設定する前に、 TiDB Lightningの設定が対応するバージョンをサポートしていることを確認してください。そうでない場合、インポートが失敗する可能性があります。 +`nightly`バージョンの中には、v4.0.0-beta.2 に類似しているものもあります。これらの`nightly`バージョンのTiDB Lightning は、実際にはローカルバックエンドをサポートしています。`nightly`バージョンの使用時にこのエラーが発生した場合は、設定`check-requirements = false`設定することでバージョンチェックを省略できます。このパラメータを設定する前に、 TiDB Lightningの設定が対応するバージョンをサポートしていることを確認してください。そうでない場合、インポートが失敗する可能性があります。 ### `restore table test.district failed: unknown columns in header [...]` {#restore-table-test-district-failed-unknown-columns-in-header} diff --git a/tidb-read-staleness.md b/tidb-read-staleness.md index d07de0f160ddd..7d9aadfc6925c 100644 --- a/tidb-read-staleness.md +++ b/tidb-read-staleness.md @@ -95,7 +95,7 @@ summary: tidb_read_staleness` システム変数を使用して履歴データ > **Note:** > - > - `tidb_read_staleness`前には`@`ではなく`@@`使用します。7 `@@`システム変数、 `@`ユーザー変数を意味します。 + > - `tidb_read_staleness`の前には`@`ではなく`@@`を使用します。`@@`はシステム変数、 `@`はユーザー変数を意味します。 > - 履歴時間範囲（値`tidb_read_staleness` ）は、手順 3 と手順 4 に費やした合計時間に応じて設定する必要があります。そうしないと、クエリ結果には履歴データではなく最新のデータが表示されてしまいます。したがって、操作に費やした時間に応じてこの時間範囲を調整する必要があります。例えば、この例では設定時間範囲が 5 秒であるため、手順 3 と手順 4 を 5 秒以内に完了する必要があります。 ここで読み取られるデータは更新前のデータ、つまり履歴データです。 diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index 7eb8b36abbf14..fe981fd02ae39 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -11,8 +11,8 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ランナウェイクエリとは、予想よりも多くの時間やリソースを消費するクエリです。以下では、ランナウェイクエリを管理する機能を説明するために「ランナ**ウェイクエリ」という**用語を使用します。 -- バージョン7.2.0以降、リソース制御機能にランナウェイクエリの管理機能が導入されました。リソースグループに対してランナウェイクエリを特定するための条件を設定し、ランナウェイクエリによるリソースの枯渇や他のクエリへの影響を防ぐためのアクションを自動的に実行できます。3 または[`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md) [`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md) `QUERY_LIMIT`フィールドを含めることで、リソースグループのランナウェイクエリを管理できます。 -- バージョン7.3.0以降、リソース制御機能にランナウェイ・ウォッチの手動管理が導入され、特定のSQL文またはダイジェストに対するランナウェイ・クエリを迅速に特定できるようになりました。ステートメント[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)実行することで、リソースグループ内のランナウェイ・クエリ・ウォッチリストを手動で管理できます。 +- バージョン7.2.0以降、リソース制御機能にランナウェイクエリの管理機能が導入されました。リソースグループに対してランナウェイクエリを特定するための条件を設定し、ランナウェイクエリによるリソースの枯渇や他のクエリへの影響を防ぐためのアクションを自動的に実行できます。[`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md)または[`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md)に`QUERY_LIMIT`フィールドを含めることで、リソースグループのランナウェイクエリを管理できます。 +- バージョン7.3.0以降、リソース制御機能にランナウェイ・ウォッチの手動管理が導入され、特定のSQL文またはダイジェストに対するランナウェイ・クエリを迅速に特定できるようになりました。ステートメント[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)を実行することで、リソースグループ内のランナウェイ・クエリ・ウォッチリストを手動で管理できます。 リソース制御機能の詳細については、 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)参照してください。 @@ -55,7 +55,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 > **Note:** > -> ランナウェイクエリを特定のリソースグループに厳密に制限したい場合は、 `SWITCH_GROUP`と[`QUERY WATCH`](#query-watch-parameters)ステートメントを併用することをお勧めします。5 `QUERY_LIMIT` 、クエリが条件を満たした場合にのみ対応する`ACTION`操作をトリガーするため、このようなシナリオでは`SWITCH_GROUP`クエリを適切なタイミングで対象のリソースグループに切り替えられない可能性があります。 +> ランナウェイクエリを特定のリソースグループに厳密に制限したい場合は、 `SWITCH_GROUP`と[`QUERY WATCH`](#query-watch-parameters)ステートメントを併用することをお勧めします。`QUERY_LIMIT` 、クエリが条件を満たした場合にのみ対応する`ACTION`操作をトリガーするため、このようなシナリオでは`SWITCH_GROUP`クエリを適切なタイミングで対象のリソースグループに切り替えられない可能性があります。 ## 例 {#examples} @@ -98,7 +98,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 QUERY WATCH ADD ACTION KILL SQL TEXT EXACT TO 'select * from test.t2'; ``` -- SQLをSQLダイジェストに解析することで、リソースグループ`rg1`ランナウェイクエリ監視リストに一致する機能を追加します。3 `ACTION`指定されていない場合は、リソースグループ`rg1`に既に設定されているオプション`ACTION`使用されます。 +- SQLをSQLダイジェストに解析することで、リソースグループ`rg1`ランナウェイクエリ監視リストに一致する機能を追加します。`ACTION`が指定されていない場合は、リソースグループ`rg1`に既に設定されているオプション`ACTION`が使用されます。 ```sql QUERY WATCH ADD RESOURCE GROUP rg1 SQL TEXT SIMILAR TO 'select * from test.t2'; diff --git a/tidb-rowid.md b/tidb-rowid.md index dd4c4874495ea..6859cd56293ba 100644 --- a/tidb-rowid.md +++ b/tidb-rowid.md @@ -123,7 +123,7 @@ 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`の値はパーティション間で一意であることが保証されません。`EXCHANGE PARTITION`を実行した後、異なるパーティションに同じ`_tidb_rowid`値を持つ行が含まれる可能性があります。 - `_tidb_rowid`存在するかどうかは、テーブルのスキーマによって異なります。クラスター化インデックスを持つテーブルの場合は、行識別子として主キーを使用してください。 ## ホットスポットの問題に対処する {#address-hotspot-issues} diff --git a/tidb-scheduling.md b/tidb-scheduling.md index 58e579f323e2b..540ac00881a17 100644 --- a/tidb-scheduling.md +++ b/tidb-scheduling.md @@ -67,7 +67,7 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン - 各 TiKV ピアによって報告される状態情報: - 各 TiKV ピアは定期的に PD にハートビートを送信します。PD はストアが生きているかどうかを確認するだけでなく、ハートビートメッセージで[`StoreState`](https://github.com/pingcap/kvproto/blob/release-8.5/proto/pdpb.proto#L473)も収集します。3 には`StoreState`が含まれます。 + 各 TiKV ピアは定期的に PD にハートビートを送信します。PD はストアが生きているかどうかを確認するだけでなく、ハートビートメッセージで[`StoreState`](https://github.com/pingcap/kvproto/blob/release-8.5/proto/pdpb.proto#L473)も収集します。`StoreState`には次の情報が含まれます。 - ディスク容量合計 - 使用可能なディスク容量 diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index 1eeedde6684f5..e4c235a474ff0 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -153,7 +153,7 @@ OOM のトラブルシューティングの詳細については、 [TiDBのメ - 3.3.2 実行計画の調査 - - `explain analyze {SQL}` 。実行時間が許容範囲内であれば、 `count`の結果の`explain analyze`と`row`の`execution info` 3-PLACEHOLDER-E}} の数を比較します。 `TableScan/IndexScan`行で大きな差が見つかった場合は、統計情報が間違っている可能性があります。他の行で大きな差が見つかった場合は、統計情報に問題がない可能性があります。 + - `explain analyze {SQL}` 。実行時間が許容範囲内であれば、 `explain analyze`の結果の`count`と`execution info`の`row`の数を比較します。 `TableScan/IndexScan`行で大きな差が見つかった場合は、統計情報が間違っている可能性があります。他の行で大きな差が見つかった場合は、統計情報に問題がない可能性があります。 - `select count(*)` 。実行プランに`join`操作が含まれている場合、 `explain analyze`の実行に時間がかかる場合があります。 `select count(*)`を実行し、 `TableScan/IndexScan`の結果に含まれる`row count`の情報を比較することで、 `explain`情報にあるかどうかを確認できます。 diff --git a/tiflash-performance-tuning-methods.md b/tiflash-performance-tuning-methods.md index ef20c468fb5f7..724c3b74fcd33 100644 --- a/tiflash-performance-tuning-methods.md +++ b/tiflash-performance-tuning-methods.md @@ -34,7 +34,7 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサ要求の数。 - `cop_execution` : 現在実行中のコプロセッサ要求の数。 - `remote_read` `remote_read_sent`リモート読み取り関連のメトリックです。リモート読み取りの増加は通常`remote_read_constructed`システムに問題があることを示しています。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG 演算子の数。1 はテーブル スキャン演算子、 `table_scan` `selection`選択演算子、 `aggregation`は集約演算子、 `top_n`は TopN 演算子、 `limit`は制限演算子、 `join`は結合演算子、 `exchange_sender`はデータ送信演算子、 `exchange_receiver`データ受信演算子です。 +- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG 演算子の数。`table_scan`はテーブル スキャン演算子、 `selection`は選択演算子、 `aggregation`は集約演算子、 `top_n`は TopN 演算子、 `limit`は制限演算子、 `join`は結合演算子、 `exchange_sender`はデータ送信演算子、 `exchange_receiver`データ受信演算子です。 ### レイテンシメトリクス {#latency-metrics} diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md index 3f1804b255e9a..7503103c54a9d 100644 --- a/tiflash/create-tiflash-replicas.md +++ b/tiflash/create-tiflash-replicas.md @@ -21,7 +21,7 @@ ALTER TABLE table_name SET TIFLASH REPLICA count; > **Note:** > -> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)クラスターの場合、 TiFlashレプリカの`count` `2`しか設定できません。7 `1`を設定した場合、実行時に自動的に`2`に調整されます。2 より大きい数に設定した場合、レプリカ数に関するエラーが発生します。 +> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)クラスターの場合、 TiFlashレプリカの`count` `2`しか設定できません。`1`を設定した場合、実行時に自動的に`2`に調整されます。2 より大きい数に設定した場合、レプリカ数に関するエラーが発生します。 同じテーブルに対して複数のDDL文を実行した場合、最後に実行された文のみが確実に有効になります。次の例では、テーブル`tpch50`に対して2つのDDL文が実行されていますが、2番目の文（レプリカを削除する文）のみが確実に有効になります。 @@ -60,7 +60,7 @@ ALTER TABLE `tpch50`.`lineitem` SET TIFLASH REPLICA 0; ### レプリケーションの進行状況を確認する {#check-replication-progress} -特定のテーブルのTiFlashレプリカのステータスを確認するには、次のステートメントを使用します。テーブルは`WHERE`句で指定します。3 `WHERE`の句を削除すると、すべてのテーブルのレプリカステータスを確認できます。 +特定のテーブルのTiFlashレプリカのステータスを確認するには、次のステートメントを使用します。テーブルは`WHERE`句で指定します。`WHERE`の句を削除すると、すべてのテーブルのレプリカステータスを確認できます。 ```sql SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = '' and TABLE_NAME = ''; @@ -68,8 +68,8 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = ' 上記のステートメントの結果は次のようになります。 -- `AVAILABLE` 、このテーブルのTiFlashレプリカが使用可能かどうかを示します。2 `1`使用可能、 `0`使用不可を意味します。レプリカが使用可能になると、このステータスは変更されません。DDL ステートメントを使用してレプリカの数を変更すると、レプリケーション ステータスは再計算されます。 -- `PROGRESS`レプリケーションの進行状況を表します。値は`0.0`から`1.0`までです。6 `1`少なくとも 1 つのレプリカがレプリケートされていることを意味します。 +- `AVAILABLE` 、このテーブルのTiFlashレプリカが使用可能かどうかを示します。`1`使用可能、 `0`使用不可を意味します。レプリカが使用可能になると、このステータスは変更されません。DDL ステートメントを使用してレプリカの数を変更すると、レプリケーション ステータスは再計算されます。 +- `PROGRESS`レプリケーションの進行状況を表します。値は`0.0`から`1.0`までです。`1`少なくとも 1 つのレプリカがレプリケートされていることを意味します。 ## データベースのTiFlashレプリカを作成する {#create-tiflash-replicas-for-databases} diff --git a/tiflash/monitor-tiflash.md b/tiflash/monitor-tiflash.md index f850e66c3a35a..585138de2fc0f 100644 --- a/tiflash/monitor-tiflash.md +++ b/tiflash/monitor-tiflash.md @@ -37,10 +37,10 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## コプロセッサー {#coprocessor} -- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。1 `batch`バッチ要求の数です。3 `batch_cop`バッチ要求内のコプロセッサ要求の数です。5 `cop`コプロセッサ インターフェイスを介して直接送信されたコプロセッサ要求の数です。7 `cop_dag`すべてのコプロセッサ要求内の DAG 要求の数です。9 `super_batch`スーパー バッチ機能を有効にするための要求の数です。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。1 `table_scan`テーブル スキャン Executor です。3 は選択 Executor です`selection` `aggregation`集約 Executor です`top_n`は`TopN` Executor です`limit`制限 Executor です。 +- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。`batch`はバッチ要求の数です。`batch_cop`はバッチ要求内のコプロセッサ要求の数です。`cop`はコプロセッサ インターフェイスを介して直接送信されたコプロセッサ要求の数です。`cop_dag`はすべてのコプロセッサ要求内の DAG 要求の数です。`super_batch`はスーパー バッチ機能を有効にするための要求の数です。 +- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。`table_scan`はテーブル スキャン Executor です。`selection`は選択 Executor です。`aggregation`は集約 Executor です。`top_n`は`TopN` Executor です。`limit`は制限 Executor です。 - リクエスト期間: コプロセッサリクエストを処理するすべてのTiFlashインスタンスの合計期間。合計期間は、コプロセッサリクエストを受信してからリクエストへの応答が完了するまでの期間です。 -- エラー QPS: コプロセッサ要求を処理するすべてのTiFlashインスタンスのエラー数。1 `meet_lock`読み取りデータがロックされていることを意味します。3 `region_not_found`リージョンが存在しないことを意味します。5 `epoch_not_match`読み取りリージョンエポックがローカル エポックと一致していないことを意味します。7 `kv_client_error` TiKV との通信でエラーが返されたことを意味します`internal_error`はTiFlashの内部システム エラーです。11 `other`その他のタイプのエラーです。 +- エラー QPS: コプロセッサ要求を処理するすべてのTiFlashインスタンスのエラー数。`meet_lock`読み取りデータがロックされていることを意味します。`region_not_found`リージョンが存在しないことを意味します。`epoch_not_match`読み取りリージョンエポックがローカル エポックと一致していないことを意味します。`kv_client_error` TiKV との通信でエラーが返されたことを意味します`internal_error`はTiFlashの内部システム エラーです。11 `other`その他のタイプのエラーです。 - リクエスト処理期間：すべてのTiFlashインスタンスがコプロセッサリクエストを処理する期間。処理時間は、コプロセッサリクエストの実行開始から完了までです。 - 応答バイト/秒: すべてのTiFlashインスタンスからの応答の合計バイト数。 - Cop タスクのメモリ使用量: コプロセッサ要求を処理するすべてのTiFlashインスタンスの合計メモリ使用量。 @@ -62,14 +62,14 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## DDL {#ddl} - スキーマ バージョン: 各TiFlashインスタンスに現在キャッシュされているスキーマのバージョン。 -- スキーマ適用OPM：すべてのTiFlashインスタンスによって1分間に`apply`操作で同期されたTiDB `schema diff`の数。この項目には、 `diff apply`の3 `failed apply`の`apply`のカウントが含まれます。13 `diff apply`単一の適用の通常のプロセスです。15 `full apply`失敗した場合、 `diff apply` `failed apply` `1`増加し、 TiFlashは`full apply`にロールバックし、最新のスキーマ情報を取得してTiFlashのスキーマバージョンを更新します。 +- スキーマ適用OPM：すべてのTiFlashインスタンスによって1分間に`apply`操作で同期されたTiDB `schema diff`の数。この項目には、 `diff apply` 、 `full apply` 、 `failed apply`の3種類の`apply`のカウントが含まれます。`diff apply`は単一の適用の通常のプロセスです。`diff apply`が失敗した場合、 `failed apply`が`1`増加し、 TiFlashは`full apply`にロールバックし、最新のスキーマ情報を取得してTiFlashのスキーマバージョンを更新します。 - スキーマ内部 DDL OPM: すべてのTiFlashインスタンスで 1 分あたりに実行された特定の DDL 操作の数。 - スキーマ適用期間: すべてのTiFlashインスタンスでの単一の`apply schema`操作に使用される時間。 ## ストレージ {#storage} - 書き込みコマンド OPS: すべてのTiFlashインスタンスのストレージレイヤーで 1 秒あたりに受信される書き込み要求の数。 -- 書き込み増幅: 各TiFlashインスタンスの書き込み増幅 (実際のディスク書き込みバイト数を論理データの書き込みバイト数で割った値)。1 `total`この開始以降の書き込み増幅で、 `5min`過去 5 分間の書き込み増幅です。 +- 書き込み増幅: 各TiFlashインスタンスの書き込み増幅 (実際のディスク書き込みバイト数を論理データの書き込みバイト数で割った値)。`total`この開始以降の書き込み増幅で、 `5min`過去 5 分間の書き込み増幅です。 - 読み取りタスク OPS: TiFlashインスタンスごとのストレージレイヤーでの 1 秒あたりの読み取りタスクの数。 - 粗セット フィルタ レート: ストレージストレージの粗セットレイヤーによってフィルタされた、過去 1 分間に各TiFlashインスタンスによって読み取られたパケット数の割合。 - 内部タスク OPS: すべてのTiFlashインスタンスが 1 秒あたりに内部データ ソート タスクを実行する回数。 diff --git a/tiflash/tiflash-alert-rules.md b/tiflash/tiflash-alert-rules.md index 41cadf172686c..28ccd8cad98c6 100644 --- a/tiflash/tiflash-alert-rules.md +++ b/tiflash/tiflash-alert-rules.md @@ -19,7 +19,7 @@ summary: TiFlashクラスターのアラート ルールについて学習しま - 解決： - このエラーは、何らかの間違ったロジックによって発生した可能性があります。1 [サポートを受ける](/support.md)またはコミュニティから。 + このエラーは、何らかの間違ったロジックによって発生した可能性があります。PingCAP またはコミュニティから[サポートを受ける](/support.md)。 ## `TiFlash_schema_apply_duration` {#tiflash-schema-apply-duration} @@ -33,7 +33,7 @@ summary: TiFlashクラスターのアラート ルールについて学習しま - 解決： - これは、 TiFlashストレージエンジンの内部的な問題が原因である可能性があります。1 [サポートを受ける](/support.md) PingCAP またはコミュニティから提供されました。 + これは、 TiFlashストレージエンジンの内部的な問題が原因である可能性があります。PingCAP またはコミュニティから[サポートを受ける](/support.md)。 ## `TiFlash_raft_read_index_duration` {#tiflash-raft-read-index-duration} @@ -65,4 +65,4 @@ summary: TiFlashクラスターのアラート ルールについて学習しま - 解決： - これは、TiKV とプロキシ間の通信エラーが原因である可能性があります。1 [サポートを受ける](/support.md) PingCAP またはコミュニティから提供されました。 + これは、TiKV とプロキシ間の通信エラーが原因である可能性があります。PingCAP またはコミュニティから[サポートを受ける](/support.md)。 diff --git a/tiflash/tiflash-command-line-flags.md b/tiflash/tiflash-command-line-flags.md index 5c36a3d6599a8..fca487175c401 100644 --- a/tiflash/tiflash-command-line-flags.md +++ b/tiflash/tiflash-command-line-flags.md @@ -30,8 +30,8 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま - `--algorithm` : データ検証に使用するハッシュアルゴリズム。値の選択肢は`xxh3` （デフォルト）、 `city128` 、 `crc32` 、 `crc64` 、 `none`です。このパラメータは`version`が`2`場合にのみ有効です。 - `--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`参照してください。 + - `--level` : 目標圧縮レベル。指定しない場合は、圧縮アルゴリズムに応じて推奨圧縮レベルがデフォルトで使用されます。`compression`が`LZ4`または`zstd`に設定されている場合、デフォルトのレベルは 1 です。`compression`が`LZ4HC`に設定されている場合、デフォルトのレベルは 9 です。 + - `--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` : ドライランモード。移行プロセスのみが出力されます。 @@ -52,9 +52,9 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま - DTFile の基本的な I/O 速度テストを提供します。 - パラメータ: - - `--version` : DTFileのバージョン[`dttool migrate`における`--version`](#dttool-migrate)参照してください。 - - `--algorithm` : データ検証に使用されるハッシュアルゴリズム。2 [`dttool migrate` `--algorithm`](#dttool-migrate)参照してください。 - - `--frame` : 検証フレームのサイズ[`dttool migrate`における`--frame`](#dttool-migrate)参照してください。 + - `--version` : DTFileのバージョン。[`dttool migrate`における`--version`](#dttool-migrate)を参照してください。 + - `--algorithm` : データ検証に使用されるハッシュアルゴリズム。[`dttool migrate`における`--algorithm`](#dttool-migrate)を参照してください。 + - `--frame` : 検証フレームのサイズ。[`dttool migrate`における`--frame`](#dttool-migrate)を参照してください。 - `--column` : テストするテーブルの列。デフォルト値は`100`です。 - `--size` : テストするテーブルの行。デフォルト値は`1000`です。 - `--field` : テスト対象テーブルのフィールド長制限。デフォルト値は`1024`です。 @@ -76,6 +76,6 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま - `--config-file` : `dttool bench`の設定ファイル[`dttool migrate`における`--config-file`](#dttool-migrate)参照してください。 - `--check` : ハッシュ検証を実行します。 - - `--file-id` ：DTFileのID。2 [`dttool migrate`における`--file-id`](#dttool-migrate)参照してください。 - - `--imitative` : データベースコンテキストを模倣します。2 [`dttool migrate`における`--imitative`](#dttool-migrate)参照してください。 - - `--workdir` : データディレクトリ。2 [`dttool migrate`における`--workdir`](#dttool-migrate)参照してください。 + - `--file-id` ：DTFileのID。[`dttool migrate`における`--file-id`](#dttool-migrate)を参照してください。 + - `--imitative` : データベースコンテキストを模倣します。[`dttool migrate`における`--imitative`](#dttool-migrate)を参照してください。 + - `--workdir` : データディレクトリ。[`dttool migrate`における`--workdir`](#dttool-migrate)を参照してください。 diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 40017e4c12b19..5e3129a3d089a 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -140,28 +140,28 @@ I/O トラフィック制限設定を構成します。 -- TiFlashは内部的にI/O要求を4つのタイプに分類します。フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取りです。1 `foreground_write_weight`フォアグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- TiFlashは内部的にI/O要求を4つのタイプに分類します。フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取りです。`foreground_write_weight`フォアグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 - I/O トラフィック制限が初期化されると、 TiFlash は`foreground_write_weight` 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `background_write_weight` {#background-write-weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。1 `background_write_weight` 、バックグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_write_weight` 、バックグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 - I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 `background_write_weight` 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `foreground_read_weight` {#foreground-read-weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。1 `foreground_read_weight` 、フォアグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`foreground_read_weight` 、フォアグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 - I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 `foreground_read_weight` 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `background_read_weight` {#background-read-weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。1 `background_read_weight` 、バックグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_read_weight` 、バックグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 - I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 `background_read_weight`の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 @@ -350,7 +350,7 @@ I/O トラフィック制限設定を構成します。 ##### `max_threads` {#max-threads} -- `max_threads` 、 TiFlash がMPP タスクを実行する際の内部スレッド同時実行数を示します。2 `0`設定すると、 TiFlash は論理 CPU コアの数を同時実行数として使用します。 +- `max_threads` 、 TiFlash がMPP タスクを実行する際の内部スレッド同時実行数を示します。`0`設定すると、 TiFlash は論理 CPU コアの数を同時実行数として使用します。 - このパラメータは、システム変数[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610) `-1`に設定されている場合にのみ有効になります。 - デフォルト値: `0` @@ -358,7 +358,7 @@ I/O トラフィック制限設定を構成します。 - 単一のクエリで生成される中間データのメモリ使用量の制限。 - 値が整数の場合、単位はバイトです。例えば、 `34359738368` 32GiBのメモリ制限を意味します。 -- 値が 1 から`[0.0, 1.0)`の範囲の浮動小数点数の場合、ノードの総メモリに対する許容メモリ使用量の比率を表します。例えば、 `0.8`総メモリの 80% を意味し、 `0.0`無制限を意味します。 +- 値が`[0.0, 1.0)`の範囲の浮動小数点数の場合、ノードの総メモリに対する許容メモリ使用量の比率を表します。例えば、 `0.8`総メモリの 80% を意味し、 `0.0`無制限を意味します。 - クエリがこの制限を超えるメモリを消費しようとすると、クエリは終了され、エラーが報告されます。 - デフォルト値: `0` 、制限がないことを意味します。 @@ -366,7 +366,7 @@ I/O トラフィック制限設定を構成します。 - すべてのクエリで生成される中間データのメモリ使用量制限。 - 値が整数の場合、単位はバイトです。例えば、 `34359738368` 32GiBのメモリ制限を意味し、 `0`制限なしを意味します。 -- v6.6.0以降では、 `[0.0, 1.0)`から10000000000000の範囲の浮動小数点数で値を設定できます。この数値は、許容されるメモリ使用量とノード全体のメモリ使用量の比率を表します。例えば、 `0.8`メモリの80%、 `0.0`無制限を意味します。 +- v6.6.0以降では、 `[0.0, 1.0)`の範囲の浮動小数点数で値を設定できます。この数値は、許容されるメモリ使用量とノード全体のメモリ使用量の比率を表します。例えば、 `0.8`メモリの80%、 `0.0`無制限を意味します。 - クエリがこの制限を超えるメモリを消費しようとすると、クエリは終了され、エラーが報告されます。 - デフォルト値： `0.8` （総メモリの80%を意味します）。v6.6.0より前のバージョンでは、デフォルト値は`0` （無制限を意味します）でした。 @@ -438,7 +438,7 @@ I/O トラフィック制限設定を構成します。 ##### `enable_resource_control`バージョン7.4.0の新機能 {#enable-resource-control-new-in-v740} -- TiFlashリソース制御機能を有効にするかどうかを制御します。1 `true`設定すると、 TiFlashは[パイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用します。 +- TiFlashリソース制御機能を有効にするかどうかを制御します。`true`設定すると、 TiFlashは[パイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用します。 - デフォルト値: `true` - 値`false`オプション: `true` @@ -536,7 +536,7 @@ I/O トラフィック制限設定を構成します。 ##### `snap-handle-pool-size` v4.0.0 の新機能 {#snap-handle-pool-size-new-in-v400} -- スナップショットを処理するスレッドの数。1 `0`設定すると、マルチスレッド最適化は無効になります。 +- スナップショットを処理するスレッドの数。`0`設定すると、マルチスレッド最適化は無効になります。 - デフォルト値: `2` #### 安全 {#security} @@ -554,7 +554,7 @@ I/O トラフィック制限設定を構成します。 ##### `data-encryption-method` {#data-encryption-method} -- データファイルの暗号化方法。1以外の値は暗号化`"plaintext"`有効であることを意味します。その場合はマスターキーを指定する必要があります。 +- データファイルの暗号化方法。`"plaintext"`以外の値は暗号化が有効であることを意味します。その場合はマスターキーを指定する必要があります。 - デフォルト値: `"plaintext"` 。これは、暗号化がデフォルトで無効になっていることを意味します。 - `"aes256-ctr"` `"aes192-ctr"`オプション: `"aes128-ctr"` `"sm4-ctr"` `"plaintext"`で導入`"sm4-ctr"`れました。 diff --git a/tiflash/tiflash-overview.md b/tiflash/tiflash-overview.md index f3cc020a88b23..bc599c30295ef 100644 --- a/tiflash/tiflash-overview.md +++ b/tiflash/tiflash-overview.md @@ -25,7 +25,7 @@ TiFlashは、ClickHouseによって効率的に実装されたコプロセッサ TiFlashは、 TiKVノード内のデータのリアルタイムレプリケーションを低コストで実行します。これにより、TiKVへの書き込みがブロックされることはありません。同時に、TiKVと同様の読み取り一貫性を提供し、最新のデータが読み取られることを保証します。TiFlashのリージョンレプリカはTiKVのレプリカと論理的に同一であり、TiKVのLeaderレプリカと同時に分割・統合されます。 -Linux AMD64アーキテクチャでTiFlash を展開するには、CPU が AVX2 命令セットをサポートしている必要があります。1 `grep avx2 /proc/cpuinfo`出力が生成されることを確認して確認してください。Linux ARM64アーキテクチャの場合、CPU が ARMv8 命令セットアーキテクチャをサポートしている必要があります。3 `grep 'crc32' /proc/cpuinfo | grep 'asimd'`出力が生成されることを確認して確認してください。これらの命令セット拡張を使用することで、TiFlash のベクトル化エンジンはより優れたパフォーマンスを発揮できます。 +Linux AMD64アーキテクチャでTiFlash を展開するには、CPU が AVX2 命令セットをサポートしている必要があります。`grep avx2 /proc/cpuinfo`出力が生成されることを確認して確認してください。Linux ARM64アーキテクチャの場合、CPU が ARMv8 命令セットアーキテクチャをサポートしている必要があります。`grep 'crc32' /proc/cpuinfo | grep 'asimd'`出力が生成されることを確認して確認してください。これらの命令セット拡張を使用することで、TiFlash のベクトル化エンジンはより優れたパフォーマンスを発揮できます。 diff --git a/tiflash/tiflash-results-materialization.md b/tiflash/tiflash-results-materialization.md index 16b778bb14cbc..750253b22bb34 100644 --- a/tiflash/tiflash-results-materialization.md +++ b/tiflash/tiflash-results-materialization.md @@ -7,7 +7,7 @@ summary: TiFlashのクエリ結果をトランザクションに保存する方 このドキュメントでは、 `INSERT INTO SELECT`トランザクションでTiFlashクエリ結果を指定された TiDB テーブルに保存する方法を紹介します。 -TiDB v6.5.0以降、 TiFlashクエリ結果をテーブルに保存すること、つまりTiFlashクエリ結果のマテリアライゼーションがサポートされています。1 `INSERT INTO SELECT`のステートメントの実行中に、TiDBが`SELECT`サブクエリをTiFlashにプッシュダウンすると、 `INSERT INTO`番目の句で指定されたTiDBテーブルにTiFlashクエリ結果を保存できます。v6.5.0より前のバージョンのTiDBでは、 TiFlashクエリ結果は読み取り専用であるため、 TiFlashクエリ結果を保存するには、アプリケーションレベルから結果を取得し、別のトランザクションまたはプロセスで保存する必要があります。 +TiDB v6.5.0以降、 TiFlashクエリ結果をテーブルに保存すること、つまりTiFlashクエリ結果のマテリアライゼーションがサポートされています。`INSERT INTO SELECT`のステートメントの実行中に、TiDBが`SELECT`サブクエリをTiFlashにプッシュダウンすると、 `INSERT INTO`番目の句で指定されたTiDBテーブルにTiFlashクエリ結果を保存できます。v6.5.0より前のバージョンのTiDBでは、 TiFlashクエリ結果は読み取り専用であるため、 TiFlashクエリ結果を保存するには、アプリケーションレベルから結果を取得し、別のトランザクションまたはプロセスで保存する必要があります。 > **Note:** > @@ -47,7 +47,7 @@ SELECT app_name, country FROM t1; - TiFlashによるオンライン アプリケーションの提供 - TiFlashがサポートする同時リクエスト数は、データ量とクエリの複雑さによって異なりますが、通常は 100 QPS を超えることはありません。1 `INSERT INTO SELECT`指定してTiFlashクエリ結果を保存し、クエリ結果テーブルを使用して、同時実行性の高いオンラインリクエストをサポートできます。結果テーブルのデータは、 TiFlash の同時実行制限をはるかに下回る低頻度（例：0.5 秒間隔）でバックグラウンドで更新できますが、データの鮮度は高いレベルで維持されます。 + TiFlashがサポートする同時リクエスト数は、データ量とクエリの複雑さによって異なりますが、通常は 100 QPS を超えることはありません。`INSERT INTO SELECT`を指定してTiFlashクエリ結果を保存し、クエリ結果テーブルを使用して、同時実行性の高いオンラインリクエストをサポートできます。結果テーブルのデータは、 TiFlash の同時実行制限をはるかに下回る低頻度（例：0.5 秒間隔）でバックグラウンドで更新できますが、データの鮮度は高いレベルで維持されます。 ## 例 {#example} diff --git a/tiflash/troubleshoot-tiflash.md b/tiflash/troubleshoot-tiflash.md index 4bf45266a2515..8f12905fceced 100644 --- a/tiflash/troubleshoot-tiflash.md +++ b/tiflash/troubleshoot-tiflash.md @@ -29,7 +29,7 @@ TiFlash は様々な理由により正常に起動しない場合があります 4. CPU が SIMD 命令をサポートしているかどうかを確認します。 - バージョン6.3以降、Linux AMD64アーキテクチャでTiFlashを展開するには、AVX2命令セットをサポートするCPUが必要です。1 `grep avx2 /proc/cpuinfo`出力が生成されることを確認して検証してください。Linux ARM64アーキテクチャの場合、CPUはARMv8命令セットアーキテクチャをサポートしている必要があります。3 `grep 'crc32' /proc/cpuinfo | grep 'asimd'`出力が生成されることを確認して検証してください。 + バージョン6.3以降、Linux AMD64アーキテクチャでTiFlashを展開するには、AVX2命令セットをサポートするCPUが必要です。`grep avx2 /proc/cpuinfo`出力が生成されることを確認して検証してください。Linux ARM64アーキテクチャの場合、CPUはARMv8命令セットアーキテクチャをサポートしている必要があります。`grep 'crc32' /proc/cpuinfo | grep 'asimd'`出力が生成されることを確認して検証してください。 仮想マシンにデプロイするときにこの問題が発生した場合は、VM の CPUアーキテクチャを Haswell に変更してから、 TiFlash を再デプロイしてみてください。 diff --git a/tiflash/tune-tiflash-performance.md b/tiflash/tune-tiflash-performance.md index 9b4d1a1f228f5..62f7cadf322fd 100644 --- a/tiflash/tune-tiflash-performance.md +++ b/tiflash/tune-tiflash-performance.md @@ -33,7 +33,7 @@ MPP実行プランは分散コンピューティングリソースを最大限 set @@tidb_enforce_mpp = ON; ``` -以下の例は、 `tidb_enforce_mpp`有効にする前後のクエリ結果を示しています。この変数を有効にする前は、TiDB は TiKV からデータを読み取り、 `Join`と`Aggregation` TiDB で実行する必要があります。7 `tidb_enforce_mpp`有効にすると、 `Join`と`Aggregation` TiFlashにプッシュダウンされます。また、オプティマイザは必ずしも MPP 実行プランを生成するとは限らないため、 `tidb_enforce_mpp`有効にすることで、オプティマイザに MPP 実行プランを強制的に生成させることができます。 +以下の例は、 `tidb_enforce_mpp`を有効にする前後のクエリ結果を示しています。この変数を有効にする前は、TiDB は TiKV からデータを読み取り、 `Join`と`Aggregation`をTiDB で実行する必要があります。`tidb_enforce_mpp`を有効にすると、 `Join`と`Aggregation`がTiFlashにプッシュダウンされます。また、オプティマイザは必ずしも MPP 実行プランを生成するとは限らないため、 `tidb_enforce_mpp`を有効にすることで、オプティマイザに MPP 実行プランを強制的に生成させることができます。 MPP モードを有効にする前: @@ -93,7 +93,7 @@ mysql> explain analyze select o_orderpriority, count(*) as order_count from orde 18 rows in set (6.00 sec) ``` -### 集計関数をJoinまたはUnion前の位置へプッシュダウンします {#push-down-aggregate-functions-to-a-position-before-code-join-code-or-code-union-code} +### 集計関数をJoinまたはUnion前の位置へプッシュダウンします {#push-down-aggregate-functions-to-a-position-before-join-or-union} 集計演算を`Join`または`Union`前の位置までプッシュダウンすることで、 `Join`または`Union`演算で処理されるデータを削減でき、パフォーマンスが向上します。 @@ -103,7 +103,7 @@ mysql> explain analyze select o_orderpriority, count(*) as order_count from orde set @@tidb_opt_agg_push_down = ON; ``` -以下の例は、変数`tidb_opt_agg_push_down`有効にする前後のクエリ結果を示しています。この変数を有効にする前は、操作`HashJoin_41`後に操作`HashAgg_58`実行されます。この変数を有効にすると、新たに生成された操作`HashAgg_21`と`HashAgg_32`操作`HashJoin_76`の前に実行されます。これにより、操作`Join`で処理されるデータ量が大幅に削減されます。 +以下の例は、変数`tidb_opt_agg_push_down`を有効にする前後のクエリ結果を示しています。この変数を有効にする前は、操作`HashJoin_41`の後に操作`HashAgg_58`が実行されます。この変数を有効にすると、新たに生成された操作`HashAgg_21`と`HashAgg_32`が操作`HashJoin_76`の前に実行されます。これにより、操作`Join`で処理されるデータ量が大幅に削減されます。 `tidb_opt_agg_push_down`有効になる前: @@ -165,7 +165,7 @@ mysql> explain analyze select count(*) from t1 join t2 where t1.a = t2.b group b 18 rows in set (0.46 sec) ``` -### Distinct最適化を有効にする {#enable-code-distinct-code-optimization} +### Distinct最適化を有効にする {#enable-distinct-optimization} TiFlashは、 `Sum`列など、 `Distinct`列を受け入れる一部の集計関数をサポートしていません。デフォルトでは、集計関数全体がTiDBで計算されます。 `Distinct`最適化を有効にすると、一部の操作をTiFlashにプッシュダウンできるため、クエリパフォーマンスが向上します。 @@ -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`有効になる前: @@ -215,7 +215,7 @@ mysql> explain analyze select count(distinct a) from test.t; 5 rows in set, 2 warnings (0.24 sec) ``` -### ALTER TABLE ... COMPACTステートメントを使用してデータを圧縮する {#compact-data-using-the-code-alter-table-compact-code-statement} +### ALTER TABLE ... COMPACTステートメントを使用してデータを圧縮する {#compact-data-using-the-alter-table--compact-statement} [`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md)文を実行すると、 TiFlashノード上の特定のテーブルまたはパーティションのコンパクションが開始されます。コンパクション中は、ノード上の物理データが書き換えられ、削除された行のクリーンアップや、更新によって発生した複数のデータバージョンのマージなどが含まれます。これにより、アクセスパフォーマンスが向上し、ディスク使用量が削減されます。以下に例を示します。 @@ -304,7 +304,7 @@ mysql> explain analyze select max(l_shipdate), max(l_commitdate), max(l_receiptd set @@tidb_max_tiflash_threads = 20; ``` -以下の例は、 `tidb_max_tiflash_threads`再設定する前後のクエリ結果を示しています。3 `tidb_max_tiflash_threads`設定する前は、単一のTiFlashインスタンスに対するリクエスト実行の同時実行数は 8 スレッドです。クラスターには合計 3 つのTiFlashインスタンスがあるため、すべてのTiFlashインスタンスにおけるリクエスト実行のスレッド数の合計は 24 (8 × 3) です`tidb_max_tiflash_threads` `20`に設定すると、すべてのTiFlashインスタンスにおけるリクエスト実行のスレッド数の合計は 60 (20 × 3) になります。 +以下の例は、 `tidb_max_tiflash_threads`を再設定する前後のクエリ結果を示しています。`tidb_max_tiflash_threads`を設定する前は、単一のTiFlashインスタンスに対するリクエスト実行の同時実行数は 8 スレッドです。クラスターには合計 3 つのTiFlashインスタンスがあるため、すべてのTiFlashインスタンスにおけるリクエスト実行のスレッド数の合計は 24 (8 × 3) です。`tidb_max_tiflash_threads`を`20`に設定すると、すべてのTiFlashインスタンスにおけるリクエスト実行のスレッド数の合計は 60 (20 × 3) になります。 `tidb_max_tiflash_threads`再構成される前: @@ -353,9 +353,9 @@ mysql> explain analyze select a, count(*) from t group by a; 9 rows in set (0.37 sec) ``` -### tiflash_fine_grained_shuffle_stream_countを設定する {#configure-code-tiflash-fine-grained-shuffle-stream-count-code} +### tiflash_fine_grained_shuffle_stream_countを設定する {#configure-tiflash_fine_grained_shuffle_stream_count} -Fine Grained Shuffle 機能を[`tiflash_fine_grained_shuffle_stream_count`](/system-variables.md#tiflash_fine_grained_shuffle_stream_count-new-in-v620)設定することで、ウィンドウ関数の実行における同時実行性を高めることができます。これにより、ウィンドウ関数の実行により多くのシステムリソースが使用されるようになり、クエリのパフォーマンスが向上します。 +Fine Grained Shuffle 機能の[`tiflash_fine_grained_shuffle_stream_count`](/system-variables.md#tiflash_fine_grained_shuffle_stream_count-new-in-v620)を設定することで、ウィンドウ関数の実行における同時実行性を高めることができます。これにより、ウィンドウ関数の実行により多くのシステムリソースが使用されるようになり、クエリのパフォーマンスが向上します。 ウィンドウ関数がTiFlashにプッシュダウンされて実行される際、この変数を使用してウィンドウ関数実行の同時実行レベルを制御できます。単位はスレッドです。 @@ -363,7 +363,7 @@ Fine Grained Shuffle 機能を[`tiflash_fine_grained_shuffle_stream_count`](/sys set @@tiflash_fine_grained_shuffle_stream_count = 20; ``` -次の例は、変数`tiflash_fine_grained_shuffle_stream_count`が再構成される前後のクエリ結果を示しています。再構成前は、 `[ExchangeSender_11, ExchangeReceiver_12, Sort_13, Window_22]`のうち`stream_count` 8 です。再構成後は、 `stream_count` 20 になります。 +次の例は、変数`tiflash_fine_grained_shuffle_stream_count`が再構成される前後のクエリ結果を示しています。再構成前は、 `[ExchangeSender_11, ExchangeReceiver_12, Sort_13, Window_22]`のうち`stream_count`は 8 です。再構成後は、 `stream_count`は 20 になります。 `tiflash_fine_grained_shuffle_stream_count`が再構成される前: diff --git a/tiflash/use-tidb-to-read-tiflash.md b/tiflash/use-tidb-to-read-tiflash.md index 65a41299b59c8..c0246fd34b582 100644 --- a/tiflash/use-tidb-to-read-tiflash.md +++ b/tiflash/use-tidb-to-read-tiflash.md @@ -11,7 +11,7 @@ TiDBは、 TiFlashレプリカを読み取る3つの方法を提供します。 ## スマートな選択 {#smart-selection} -TiFlashレプリカを持つテーブルの場合、TiDBオプティマイザーはコスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に決定します。1または`desc` `explain analyze`ステートメントを使用して、 TiFlashレプリカが選択されているかどうかを確認できます。例： +TiFlashレプリカを持つテーブルの場合、TiDBオプティマイザーはコスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に決定します。`desc`または`explain analyze`ステートメントを使用して、 TiFlashレプリカが選択されているかどうかを確認できます。例： ```sql desc select count(*) from test.t; diff --git a/tiflash/use-tiflash-mpp-mode.md b/tiflash/use-tiflash-mpp-mode.md index ea1014de787f4..86d502066c1e6 100644 --- a/tiflash/use-tiflash-mpp-mode.md +++ b/tiflash/use-tiflash-mpp-mode.md @@ -17,7 +17,7 @@ summary: TiFlashの MPP モードとその使用方法を学びます。 -TiFlashは、クエリ実行にMPPモードをサポートしています。このモードでは、ノード間のデータ交換（データシャッフルプロセス）が計算に導入されます。TiDBは、オプティマイザのコスト推定に基づいて、MPPモードを選択するかどうかを自動的に決定します。1と[`tidb_allow_mpp`](/system-variables.md#tidb_allow_mpp-new-in-v50) [`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-new-in-v51)値を変更することで、選択戦略を変更できます。 +TiFlashは、クエリ実行にMPPモードをサポートしています。このモードでは、ノード間のデータ交換（データシャッフルプロセス）が計算に導入されます。TiDBは、オプティマイザのコスト推定に基づいて、MPPモードを選択するかどうかを自動的に決定します。[`tidb_allow_mpp`](/system-variables.md#tidb_allow_mpp-new-in-v50)と[`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-new-in-v51)の値を変更することで、選択戦略を変更できます。 次の図は、MPP モードの動作を示しています。 @@ -81,7 +81,7 @@ set @@session.tidb_enforce_mpp=1; ## MPPモードのアルゴリズムサポート {#algorithm-support-for-the-mpp-mode} -MPPモードは、ブロードキャストハッシュ結合、シャッフルハッシュ結合、シャッフルハッシュ集計、Union All、TopN、およびLimitという物理アルゴリズムをサポートしています。オプティマイザーは、クエリで使用するアルゴリズムを自動的に決定します。具体的なクエリ実行プランを確認するには、 `EXPLAIN`のステートメントを実行してください。3 `EXPLAIN`のステートメントの結果にExchangeSender演算子とExchangeReceiver演算子が表示された場合、MPPモードが有効になっていることを示します。 +MPPモードは、ブロードキャストハッシュ結合、シャッフルハッシュ結合、シャッフルハッシュ集計、Union All、TopN、およびLimitという物理アルゴリズムをサポートしています。オプティマイザーは、クエリで使用するアルゴリズムを自動的に決定します。具体的なクエリ実行プランを確認するには、 `EXPLAIN`のステートメントを実行してください。`EXPLAIN`のステートメントの結果にExchangeSender演算子とExchangeReceiver演算子が表示された場合、MPPモードが有効になっていることを示します。 次のステートメントは、TPC-H テスト セット内のテーブル構造を例として示しています。 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 4373ac825acee..b014064d1b284 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -1287,7 +1287,7 @@ Raftstoreに関連するコンフィグレーション項目。 > **Warning:** > > - `enable-region-bucket`は、TiDB v6.1.0 で導入された実験的機能です。本番環境での使用は推奨されません。 -> - この設定は、 `region-split-size` `region-bucket-size`の 2 倍以上である場合にのみ有効です。それ以外の場合は、バケットは実際には生成されません。 +> - この設定は、 `region-split-size`が`region-bucket-size`の 2 倍以上である場合にのみ有効です。それ以外の場合は、バケットは実際には生成されません。 > - `region-split-size`をより大きな値に調整すると、パフォーマンスの低下やスケジューリングの遅延のリスクが生じる可能性があります。 ### `region-bucket-size` v6.1.0の新機能 {#region-bucket-size-new-in-v610} @@ -1697,7 +1697,7 @@ Titanに関連するコンフィグレーション項目。 - `lockcf`のデフォルト値: `"128MiB"` - 最小値: `0` - 単位：KiB｜MiB｜GiB -- 不要な圧縮を減らすため、 `max-bytes-for-level-base`の値は L0 のデータ量とほぼ等しく設定することをお勧めします。たとえば、圧縮方法が "no:no:lz4:lz4:lz4:lz4:lz4" の場合、L0 と L1 は圧縮されず、L0 の圧縮のトリガー条件は SST ファイルの数が 4 (デフォルト値) に達することであるため、{{B-PLACEHOLDER `max-bytes-for-level-base`の値は`write-buffer-size * 4`にする必要があります。L0 と L1 の両方で圧縮を採用する場合は、RocksDB ログを分析して、memtable から圧縮された SST ファイルのサイズを把握する必要があります。例えば、ファイルサイズが 32 MiB の場合、 `max-bytes-for-level-base`の値を 128 MiB ( `32 MiB * 4` ) に設定することをお勧めします。 +- 不要な圧縮を減らすため、 `max-bytes-for-level-base`の値は L0 のデータ量とほぼ等しく設定することをお勧めします。たとえば、圧縮方法が "no:no:lz4:lz4:lz4:lz4:lz4" の場合、L0 と L1 は圧縮されず、L0 の圧縮のトリガー条件は SST ファイルの数が 4 (デフォルト値) に達することであるため、 `max-bytes-for-level-base`の値は`write-buffer-size * 4`にする必要があります。L0 と L1 の両方で圧縮を採用する場合は、RocksDB ログを分析して、memtable から圧縮された SST ファイルのサイズを把握する必要があります。例えば、ファイルサイズが 32 MiB の場合、 `max-bytes-for-level-base`の値を 128 MiB ( `32 MiB * 4` ) に設定することをお勧めします。 ### `target-file-size-base` {#target-file-size-base} diff --git a/tikv-control.md b/tikv-control.md index d73cd7fbbc448..5bfc70c305e63 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -15,7 +15,7 @@ TiKV Control ( `tikv-ctl` ) は、クラスターの管理に使用される TiK > > 使用する制御ツールのバージョンは、クラスターのバージョンと一致させることをお勧めします。 -`tikv-ctl`は`tiup`コマンドにも統合されています。4 ツール`tikv-ctl`呼び出すには、以下のコマンドを実行してください。 +`tikv-ctl`は`tiup`コマンドにも統合されています。`tikv-ctl`ツールを呼び出すには、以下のコマンドを実行してください。 ```shell tiup ctl:v tikv @@ -139,7 +139,7 @@ AAFF `region`サブコマンドの場合: -- 表示するリージョンを指定するには、 `-r`オプションを使用してください。複数のリージョンを指定する場合は、 `,`で区切ります。また、 `--all-regions`オプションを使用してすべてのリージョンを表示することもできます。7 と`-r` `--all-regions`同時に使用できないことに注意してください。 +- 表示するリージョンを指定するには、 `-r`オプションを使用してください。複数のリージョンを指定する場合は、 `,`で区切ります。また、 `--all-regions`オプションを使用してすべてのリージョンを表示することもできます。`-r`と`--all-regions`は同時に使用できないことに注意してください。 - 印刷するリージョンの数を制限するには、 `--limit`オプションを使用します (デフォルト: `16` )。 - 特定のキー範囲に含まれるリージョンを照会するには、 `--start`および`--end`オプションを使用します (デフォルト: 範囲制限なし、16 進形式)。 @@ -519,7 +519,7 @@ tikv-ctl ldb --hex manifest_dump --path=/tmp/db/MANIFEST-000001 [storage] data-dir = "/path/to/tikv/data" -`--path`オプションは、対象のデータファイルへの絶対パスまたは相対パスを指定するために使用できます。データファイルが暗号化されていない場合、コマンドは空の出力を返すことがあります。3 `--path`指定しない場合は、すべてのデータファイルの暗号化情報が出力されます。 +`--path`オプションは、対象のデータファイルへの絶対パスまたは相対パスを指定するために使用できます。データファイルが暗号化されていない場合、コマンドは空の出力を返すことがあります。`--path`を指定しない場合は、すべてのデータファイルの暗号化情報が出力されます。 ```shell tikv-ctl --config=./conf.toml encryption-meta dump-file --path=/path/to/tikv/data/db/CURRENT @@ -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をカンマ区切りのリストで指定できます。`--ids`を指定しない場合は、すべてのデータ暗号化キーと、最新のアクティブなデータ暗号化キーのIDである現在のキーIDが出力されます。 このコマンドを使用すると、機密情報が公開される可能性があることを警告するメッセージが表示されます。続行するには「同意します」と入力してください。 diff --git a/time-to-live.md b/time-to-live.md index f50fb06b813b7..d891cf1ca0801 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`を指定しています。これはデータの作成時刻を示します。また、テーブル内で行が保持できる最長期間を、 `INTERVAL 3 MONTH`によって 3 か月に設定しています。この値を超えて保持されるデータは、後で削除されます。 - 期限切れのデータをクリーンアップする機能を有効または無効にするには、 `TTL_ENABLE`属性を設定します。 @@ -271,7 +271,7 @@ TTL は、他の TiDB 移行、バックアップ、およびリカバリ ツー - 削除がデータ サイズを比較的安定させるのに十分な速さであるかどうかをどのように判断すればよいでしょうか? - [Grafana `TiDB`ダッシュボード](/grafana-tidb-dashboard.md)パネル`TTL Insert Rows Per Hour`は、過去 1 時間に挿入された行の総数を記録します。対応する`TTL Delete Rows Per Hour` 、過去 1 時間に TTL タスクによって削除された行の総数を記録します。7 `TTL Insert Rows Per Hour`長期間にわたって`TTL Delete Rows Per Hour`よりも高い場合、挿入率が削除率を上回り、データの総量が増加することを意味します。例: + [Grafana `TiDB`ダッシュボード](/grafana-tidb-dashboard.md)パネル`TTL Insert Rows Per Hour`は、過去 1 時間に挿入された行の総数を記録します。対応する`TTL Delete Rows Per Hour` 、過去 1 時間に TTL タスクによって削除された行の総数を記録します。`TTL Insert Rows Per Hour`長期間にわたって`TTL Delete Rows Per Hour`よりも高い場合、挿入率が削除率を上回り、データの総量が増加することを意味します。例: ![insert fast example](/media/ttl/insert-fast.png) diff --git a/tiproxy/tiproxy-api.md b/tiproxy/tiproxy-api.md index ece92c0c1cc07..22b389d7436dd 100644 --- a/tiproxy/tiproxy-api.md +++ b/tiproxy/tiproxy-api.md @@ -11,7 +11,7 @@ summary: TiProxy API を使用して構成、ヘルス ステータス、監視 > > TiProxy APIはデバッグ用に特別に設計されており、TiProxyに将来導入される機能との互換性が完全には保証されない可能性があります。情報取得のためにこのツールをアプリケーションやユーティリティの開発に組み込むことは推奨されません。 -TiProxy APIにアクセスするためのアドレスは`http://${host}:${port}${path}`です。3 `${host}:${port}` TiProxy設定項目[`api.addr`](/tiproxy/tiproxy-configuration.md#addr-1)で指定され、 `${path}`アクセスしたい特定のAPIエンドポイントです。例： +TiProxy APIにアクセスするためのアドレスは`http://${host}:${port}${path}`です。`${host}:${port}` TiProxy設定項目[`api.addr`](/tiproxy/tiproxy-configuration.md#addr-1)で指定され、 `${path}`アクセスしたい特定のAPIエンドポイントです。例： ```bash curl http://127.0.0.1:3080/api/admin/config/ diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index 522e8f7dbb90f..da9a0275ff438 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -65,20 +65,20 @@ SQL ポートのコンフィグレーション。 - デフォルト値: `15` - ホットリロードのサポート: はい - 単位: 秒 -- TiProxy がシャットダウンする際、現在のトランザクション（ドレインクライアントとも呼ばれます）が`graceful-close-conn-timeout`秒以内に完了すると、接続が閉じられます。その後、すべての接続が一度に閉じられます。3 `graceful-close-conn-timeout` `graceful-wait-before-shutdown`後に発生します。このタイムアウトは、トランザクションのライフサイクルよりも長く設定することをお勧めします。 +- TiProxy がシャットダウンする際、現在のトランザクション（ドレインクライアントとも呼ばれます）が`graceful-close-conn-timeout`秒以内に完了すると、接続が閉じられます。その後、すべての接続が一度に閉じられます。`graceful-close-conn-timeout`は`graceful-wait-before-shutdown`の後に発生します。このタイムアウトは、トランザクションのライフサイクルよりも長く設定することをお勧めします。 #### `max-connections` {#max-connections} - デフォルト値: `0` - ホットリロードのサポート: はい -- 各 TiProxy インスタンスは最大`max-connections`接続を受け入れることができます。3 `0`制限がないことを意味します。 +- 各 TiProxy インスタンスは最大`max-connections`接続を受け入れることができます。`0`制限がないことを意味します。 #### `conn-buffer-size` {#conn-buffer-size} - デフォルト値: `32768` - ホットリロードのサポート: はい、ただし新規接続のみ - 範囲: `[1024, 16777216]` -- この設定項目では、接続バッファのサイズを指定できます。各接続は、読み取りバッファと書き込みバッファをそれぞれ1つずつ使用します。これはメモリとパフォーマンスのトレードオフです。バッファサイズを大きくするとパフォーマンスは向上しますが、メモリ消費量も増加します。1 `0`設定すると、TiProxy はデフォルトのバッファサイズを使用します。 +- この設定項目では、接続バッファのサイズを指定できます。各接続は、読み取りバッファと書き込みバッファをそれぞれ1つずつ使用します。これはメモリとパフォーマンスのトレードオフです。バッファサイズを大きくするとパフォーマンスは向上しますが、メモリ消費量も増加します。`0`設定すると、TiProxy はデフォルトのバッファサイズを使用します。 #### `pd-addrs` {#pd-addrs} @@ -91,7 +91,7 @@ SQL ポートのコンフィグレーション。 - デフォルト値: `""` - ホットリロードのサポート: はい、ただし新規接続のみ - 可能な`"v2"` : `""` -- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にしてください。PROXYプロトコルを有効にすると、TiProxyは実際のクライアントIPアドレスをTiDBに渡すことができます。3 `"v2"` PROXYプロトコルバージョン2の使用を示し、 `""` PROXYプロトコルの無効化を示します。TiProxyでPROXYプロトコルが有効になっている場合は、TiDBサーバーでも[PROXYプロトコル](/tidb-configuration-file.md#proxy-protocol)有効にする必要があります。 +- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にしてください。PROXYプロトコルを有効にすると、TiProxyは実際のクライアントIPアドレスをTiDBに渡すことができます。`"v2"` PROXYプロトコルバージョン2の使用を示し、 `""` PROXYプロトコルの無効化を示します。TiProxyでPROXYプロトコルが有効になっている場合は、TiDBサーバーでも[PROXYプロトコル](/tidb-configuration-file.md#proxy-protocol)有効にする必要があります。 ### API {#api} @@ -101,14 +101,14 @@ HTTP ゲートウェイの構成。 - デフォルト値: `0.0.0.0:3080` - ホットリロードのサポート: いいえ -- APIゲートウェイアドレス。1 `ip:port`指定できます。 +- APIゲートウェイアドレス。`ip:port`を指定できます。 #### `proxy-protocol` {#proxy-protocol} - デフォルト値: `""` - ホットリロードのサポート: いいえ - 可能な`"v2"` : `""` -- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にします。3 `"v2"` PROXY プロトコル バージョン 2 を使用することを示し、 `""` PROXY プロトコルを無効にすることを示します。 +- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にします。`"v2"` PROXY プロトコル バージョン 2 を使用することを示し、 `""` PROXY プロトコルを無効にすることを示します。 ### バランス {#balance} diff --git a/tiproxy/tiproxy-overview.md b/tiproxy/tiproxy-overview.md index 9484d86a6a14d..38d2834a323d2 100644 --- a/tiproxy/tiproxy-overview.md +++ b/tiproxy/tiproxy-overview.md @@ -272,7 +272,7 @@ TiProxyとTiDBサーバー間のTLS接続は、以下のルールに従って有 TiProxyには、TiDBと互換性のない以下の動作があります。 -- `STATUS`と`SHOW STATUS`ステートメントは異なるTLS情報を返す可能性があります。5 `STATUS`のステートメントはクライアントとTiProxy間のTLS情報を返し、 `SHOW STATUS`ステートメントはTiProxyとTiDBサーバー間のTLS情報を返します。 +- `STATUS`と`SHOW STATUS`ステートメントは異なるTLS情報を返す可能性があります。`STATUS`のステートメントはクライアントとTiProxy間のTLS情報を返し、 `SHOW STATUS`ステートメントはTiProxyとTiDBサーバー間のTLS情報を返します。 - TiProxy は[証明書ベースの認証](/certificate-authentication.md)サポートしていません。そうでない場合、クライアントと TiProxy 間の TLS 証明書が TiProxy と TiDBサーバー間の TLS 証明書と異なるため、クライアントはログインに失敗する可能性があります。TiDBサーバーはTiProxy 上の TLS 証明書に基づいて TLS 証明書を検証します。 ## 制限事項 {#limitations} diff --git a/tiproxy/tiproxy-traffic-replay.md b/tiproxy/tiproxy-traffic-replay.md index 9f5206c3ee305..59c90abb7d89f 100644 --- a/tiproxy/tiproxy-traffic-replay.md +++ b/tiproxy/tiproxy-traffic-replay.md @@ -52,7 +52,7 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア tiproxyctl traffic capture --host 10.0.1.10 --port 3080 --output="/tmp/traffic" --duration=1h ``` - トラフィックファイルは自動的にローテーションされ、圧縮されます。1 `/tmp/traffic`内のファイルの例: + トラフィックファイルは自動的にローテーションされ、圧縮されます。`/tmp/traffic`内のファイルの例: ```shell ls /tmp/traffic diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md index e8a602b4d7226..4b7f748465cb2 100644 --- a/tiup/tiup-cluster-no-sudo-mode.md +++ b/tiup/tiup-cluster-no-sudo-mode.md @@ -118,7 +118,7 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ 2. トポロジ ファイルを編集します。 - 通常モードと比較して、 TiUPをno-sudoモードで使用する場合は、 `topology.yaml`ファイルの`global`モジュールに`systemd_mode: "user"`行目を追加する必要があります。7パラメータ`systemd_mode` 、 `systemd user`モードを使用するかどうかを設定するために使用されます。このパラメータが設定されていない場合、デフォルト値は`system`で、sudo権限が必要であることを意味します。 + 通常モードと比較して、 TiUPをno-sudoモードで使用する場合は、 `topology.yaml`ファイルの`global`モジュールに`systemd_mode: "user"`の行を追加する必要があります。`systemd_mode`パラメータは、`systemd user`モードを使用するかどうかを設定するために使用されます。このパラメータが設定されていない場合、デフォルト値は`system`で、sudo権限が必要であることを意味します。 さらに、no-sudoモードでは、非rootユーザー`tidb`は`/data`ディレクトリを`deploy_dir`または`data_dir`として使用する権限がないため、非rootユーザーがアクセスできるパスを選択する必要があります。以下の例では相対パスを使用しており、実際に使用されるパスは`/home/tidb/data/tidb-deploy`と`/home/tidb/data/tidb-data`です。トポロジファイルの残りの部分は、通常モードと同じです。別の方法として、rootユーザーを使用してディレクトリを作成し、その後`chown`を使用して所有権を`tidb:tidb`に変更することもできます。 diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index 995fb626e64a0..c619ed3218f31 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -36,7 +36,7 @@ TiUPを使用した TiDB デプロイメントのトポロジ構成ファイル `global`セクションはクラスターのグローバル構成に対応し、次のフィールドがあります。 -- `user` : デプロイされたクラスターを起動するために使用するユーザー。デフォルト値は`"tidb"`です。4 フィールドに指定されたユーザーが``マシン上に存在しない場合、このユーザーは自動的に作成されます。 +- `user` : デプロイされたクラスターを起動するために使用するユーザー。デフォルト値は`"tidb"`です。``フィールドに指定されたユーザーがターゲットマシン上に存在しない場合、このユーザーは自動的に作成されます。 - `group` : ユーザーが所属するユーザーグループ。ユーザー作成時に指定されます。デフォルト値は``番目のフィールドの値です。指定されたグループが存在しない場合は、自動的に作成されます。 @@ -129,7 +129,7 @@ monitored: ### `server_configs` {#server-configs} -`server_configs` 、サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。2 `global`と同様に、このセクションの設定は、インスタンス内の同名の設定によって上書きできます。4 `server_configs`は主に以下のフィールドが含まれます。 +`server_configs` 、サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。`global`と同様に、このセクションの設定は、インスタンス内の同名の設定によって上書きできます。`server_configs`は主に以下のフィールドが含まれます。 - `tidb` : TiDBサービス関連の設定。詳細な設定については[TiDB構成ファイル](/tidb-configuration-file.md)参照してください。 @@ -426,7 +426,7 @@ tiflash_servers: ### `tiproxy_servers` {#tiproxy-servers} -`tiproxy_servers` 、TiProxy サービスが展開されるマシンと、各マシン上のサービスの構成を指定します。2 `tiproxy_servers`配列であり、配列の各要素には次のフィールドが含まれます。 +`tiproxy_servers` 、TiProxy サービスが展開されるマシンと、各マシン上のサービスの構成を指定します。`tiproxy_servers`配列であり、配列の各要素には次のフィールドが含まれます。 - `host` : TiProxyサービスがデプロイされているマシンのIPアドレスを指定します。このフィールドは必須です。 @@ -577,7 +577,7 @@ cdc_servers: ### `tso_servers` {#tso-servers} -`tso_servers` 、 `tso`マイクロサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。4 `tso_servers`配列であり、配列の各要素には以下のフィールドが含まれます。 +`tso_servers` 、 `tso`マイクロサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。`tso_servers`配列であり、配列の各要素には以下のフィールドが含まれます。 - `host` : `tso`マイクロサービスがデプロイされているマシンのIPアドレスを指定します。このフィールド値は必須です。 - `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 @@ -607,7 +607,7 @@ tso_servers: ### `scheduling_servers` {#scheduling-servers} -`scheduling_servers` 、 `scheduling`マイクロサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。4 `scheduling_servers`配列であり、配列の各要素には以下のフィールドが含まれます。 +`scheduling_servers` 、 `scheduling`マイクロサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。`scheduling_servers`配列であり、配列の各要素には以下のフィールドが含まれます。 - `host` : `scheduling`マイクロサービスがデプロイされているマシンのIPアドレスを指定します。このフィールドは必須です。 - `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 diff --git a/tiup/tiup-cluster.md b/tiup/tiup-cluster.md index 9e45b391b7a2b..936584766a146 100644 --- a/tiup/tiup-cluster.md +++ b/tiup/tiup-cluster.md @@ -515,7 +515,7 @@ tiup cluster import --dir=/path/to/tidb-ansible ## 操作ログを表示する {#view-the-operation-log} -操作ログを表示するには、 `audit`コマンドを使用します。3 コマンドの使用方法は`audit`のとおりです。 +操作ログを表示するには、 `audit`コマンドを使用します。`audit`コマンドの使用方法は次のとおりです。 ```bash Usage: @@ -548,7 +548,7 @@ tiup cluster audit 4BLhr0 ## TiDB クラスター内のホストでコマンドを実行する {#run-commands-on-a-host-in-the-tidb-cluster} -TiDBクラスタ内のホストでコマンドを実行するには、 `exec`コマンドを使用します。3 `exec`のコマンドの使用方法は次のとおりです。 +TiDBクラスタ内のホストでコマンドを実行するには、 `exec`コマンドを使用します。`exec`のコマンドの使用方法は次のとおりです。 ```bash Usage: diff --git a/tiup/tiup-command-env.md b/tiup/tiup-command-env.md index 9a88eb7ecb625..308ca02bbf53c 100644 --- a/tiup/tiup-command-env.md +++ b/tiup/tiup-command-env.md @@ -5,7 +5,7 @@ summary: TiUPは、環境変数を用いた柔軟でカスタマイズされた # tiup env {#tiup-env} -TiUPは、ユーザーに柔軟でカスタマイズされたインターフェースを提供します。その一部は環境変数を使用して実装されています。1コマンド`tiup env` 、 TiUPがサポートするユーザー定義の環境変数とその値を照会するために使用されます。 +TiUPは、ユーザーに柔軟でカスタマイズされたインターフェースを提供します。その一部は環境変数を使用して実装されています。`tiup env`コマンドは、TiUPがサポートするユーザー定義の環境変数とその値を照会するために使用されます。 ## 構文 {#syntax} diff --git a/tiup/tiup-command-install.md b/tiup/tiup-command-install.md index 576de769e87b2..df1634b5dd1c8 100644 --- a/tiup/tiup-command-install.md +++ b/tiup/tiup-command-install.md @@ -13,7 +13,7 @@ summary: "tiup installコマンドは、ミラーリポジトリからコンポ tiup install [:version] [component2...N] [flags] ``` -``と``コンポーネント名を表し、 `[version]`オプションのバージョン番号を表します。6 `version`追加されていない場合は、指定されたコンポーネントの最新の安定バージョンがインストールされます。8 `[component2...N]` 、複数のコンポーネント、または同じコンポーネントの複数のバージョンを同時に指定できることを意味します。 +``と``コンポーネント名を表し、 `[version]`オプションのバージョン番号を表します。`version`追加されていない場合は、指定されたコンポーネントの最新の安定バージョンがインストールされます。`[component2...N]` 、複数のコンポーネント、または同じコンポーネントの複数のバージョンを同時に指定できることを意味します。 ## オプション {#option} diff --git a/tiup/tiup-command-list.md b/tiup/tiup-command-list.md index 392006205fc1a..12e39f8463e07 100644 --- a/tiup/tiup-command-list.md +++ b/tiup/tiup-command-list.md @@ -13,7 +13,7 @@ summary: tiup list`コマンドは、ミラーで利用可能なコンポーネ tiup list [component] [flags] ``` -`[component]` 、特定のコンポーネントを指定するために使用されるオプションパラメータです。2 `[component]`設定されている場合、 TiUP は指定されたコンポーネントのすべてのバージョンを一覧表示します。そうでない場合、 TiUP はすべてのコンポーネントを一覧表示します。 +`[component]`は、特定のコンポーネントを指定するために使用されるオプションパラメータです。`[component]`が設定されている場合、 TiUP は指定されたコンポーネントのすべてのバージョンを一覧表示します。そうでない場合、 TiUP はすべてのコンポーネントを一覧表示します。 ## オプション {#options} @@ -38,9 +38,9 @@ tiup list [component] [flags] ## 出力 {#outputs} - `[component]`が設定されていない場合: - - `--verbose`指定した場合: TiUP は、 `Name` (コンポーネント名)、 `Installed` (インストールされているバージョン)、 `Owner` (コンポーネント所有者)、および`Description` (コンポーネントの説明) で構成されるコンポーネント情報リストを出力します。 + - `--verbose`を指定した場合: TiUP は、 `Name` (コンポーネント名)、 `Installed` (インストールされているバージョン)、 `Owner` (コンポーネント所有者)、および`Description` (コンポーネントの説明) で構成されるコンポーネント情報リストを出力します。 - `--verbose`が指定されていない場合: TiUP は、 `Name` (コンポーネント名)、 `Owner` (コンポーネント所有者)、および`Description` (コンポーネントの説明) で構成されるコンポーネント情報リストを出力します。 -- `[component]`設定されている場合: +- `[component]`が設定されている場合: - 指定されたコンポーネントが存在する場合: TiUP は、指定されたコンポーネントのバージョン情報リストを出力します。リストは、 `Version` (バージョン番号)、 `Installed` (インストール状態)、 `Release` (リリース日)、および`Platforms` (サポートされているプラットフォーム) で構成されます。 - 指定されたコンポーネントが存在しない場合: TiUP はエラー`failed to fetch component: unknown component`報告します。 diff --git a/tiup/tiup-command-mirror-clone.md b/tiup/tiup-command-mirror-clone.md index 114f18c78a6a5..8b9a6a5f06c58 100644 --- a/tiup/tiup-command-mirror-clone.md +++ b/tiup/tiup-command-mirror-clone.md @@ -44,7 +44,7 @@ tiup mirror clone [global version] [flags] ### - {コンポーネント} {#component} -- クローンするコンポーネントのバージョンリストを指定します`{component}`にコンポーネント名を入力してください。3 [`tiup list --all`](/tiup/tiup-command-list.md)実行すると、使用可能なコンポーネント名が表示されます。 +- クローンするコンポーネントのバージョンリストを指定します`{component}`にコンポーネント名を入力してください。[`tiup list --all`](/tiup/tiup-command-list.md)を実行すると、使用可能なコンポーネント名が表示されます。 - データ型: 文字列 - デフォルト: Null diff --git a/tiup/tiup-command-mirror-genkey.md b/tiup/tiup-command-mirror-genkey.md index 0c53eaf5aaa9c..8a4a9383efa78 100644 --- a/tiup/tiup-command-mirror-genkey.md +++ b/tiup/tiup-command-mirror-genkey.md @@ -34,13 +34,13 @@ tiup mirror genkey [flags] ### -p, --public {#p-public} - オプション`-n/--name`で指定された秘密鍵に対応する公開鍵を表示します。 -- `-p/--public`指定された場合、 TiUP は新しい`-n/--name`鍵を作成しません。3 で指定された秘密鍵が存在しない場合、 TiUP はエラーを返します。 +- `-p/--public`が指定された場合、 TiUP は新しい秘密鍵を作成しません。`-n/--name`で指定された秘密鍵が存在しない場合、 TiUP はエラーを返します。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### - 保存 {#save} -- 公開鍵の情報を現在のディレクトリにファイルとして保存します。ファイル名は`{hash-prefix}-public.json`です。3 `hash-prefix`鍵IDの最初の16ビットです。 +- 公開鍵の情報を現在のディレクトリにファイルとして保存します。ファイル名は`{hash-prefix}-public.json`です。`hash-prefix`鍵IDの最初の16ビットです。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 diff --git a/tiup/tiup-command-mirror-grant.md b/tiup/tiup-command-mirror-grant.md index 325c8e72f7ae6..f742b158f8702 100644 --- a/tiup/tiup-command-mirror-grant.md +++ b/tiup/tiup-command-mirror-grant.md @@ -32,7 +32,7 @@ tiup mirror grant [flags] ### -n, --name {#n-name} -- コンポーネント所有者の名前を指定します。名前はコンポーネントリストの`Owner`フィールドに表示されます。3 `-n/--name`指定されていない場合は、 ``コンポーネント所有者の名前として使用されます。 +- コンポーネント所有者の名前を指定します。名前はコンポーネントリストの`Owner`フィールドに表示されます。`-n/--name`が指定されていない場合は、 ``がコンポーネント所有者の名前として使用されます。 - データ型: `STRING` - デフォルト: `` diff --git a/tiup/tiup-command-mirror-publish.md b/tiup/tiup-command-mirror-publish.md index d8e745b36519a..31212e5b9e52a 100644 --- a/tiup/tiup-command-mirror-publish.md +++ b/tiup/tiup-command-mirror-publish.md @@ -46,7 +46,7 @@ tiup mirror publish [flags] ### --os {#os} -- ``のバイナリファイルが実行できるオペレーティングシステムを指定します。3 ``パッケージの場合、オペレーティングシステムは以下のオプションからのみ選択できます。 +- ``のバイナリファイルが実行できるオペレーティングシステムを指定します。``パッケージの場合、オペレーティングシステムは以下のオプションからのみ選択できます。 - `linux` : ファイルが Linux オペレーティング システムで実行されることを示します。 - `darwin` : ファイルが Darwin オペレーティング システムで実行されることを示します。 diff --git a/tiup/tiup-command-mirror-set.md b/tiup/tiup-command-mirror-set.md index 6329c9b939260..b937733b45932 100644 --- a/tiup/tiup-command-mirror-set.md +++ b/tiup/tiup-command-mirror-set.md @@ -34,7 +34,7 @@ tiup mirror set [flags] tiup mirror set -r /path/to/local/root.json -上記の手順では、 `wget`コマンドの前にミラーが攻撃された場合、ルート証明書が正しくないことが分かります。3 `wget`コマンドの後にミラーが攻撃された場合、 TiUPはミラーがルート証明書と一致しないことを検出します。 +上記の手順では、 `wget`コマンドの前にミラーが攻撃された場合、ルート証明書が正しくないことが分かります。`wget`コマンドの後にミラーが攻撃された場合、 TiUPはミラーがルート証明書と一致しないことを検出します。 - データ型: `String` - デフォルト: `{mirror-dir}/root.json` diff --git a/tiup/tiup-command-uninstall.md b/tiup/tiup-command-uninstall.md index ea220a00c46a5..b371637ca25eb 100644 --- a/tiup/tiup-command-uninstall.md +++ b/tiup/tiup-command-uninstall.md @@ -21,13 +21,13 @@ tiup uninstall : [component2...N] [flags] ### --all {#all} -- 指定されたコンポーネントのインストール済みバージョンをすべてアンインストールします。1 ``省略した場合は、このオプションを使用する必要があります。 +- 指定されたコンポーネントのインストール済みバージョンをすべてアンインストールします。``省略した場合は、このオプションを使用する必要があります。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### - 自己 {#self} -- TiUP自体をアンインストールします。このオプションを使用すると、ミラーからダウンロードされたすべてのデータが削除されますが、 TiUPとそのコンポーネントによって生成されたデータは保持されます。データは環境変数`TIUP_HOME`で指定されたディレクトリに保存されます。3 `TIUP_HOME`設定されていない場合、デフォルト値は`~/.tiup/`です。 +- TiUP自体をアンインストールします。このオプションを使用すると、ミラーからダウンロードされたすべてのデータが削除されますが、 TiUPとそのコンポーネントによって生成されたデータは保持されます。データは環境変数`TIUP_HOME`で指定されたディレクトリに保存されます。`TIUP_HOME`設定されていない場合、デフォルト値は`~/.tiup/`です。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 diff --git a/tiup/tiup-component-cluster-check.md b/tiup/tiup-component-cluster-check.md index 920d65217354e..f17d7b9c0bd69 100644 --- a/tiup/tiup-component-cluster-check.md +++ b/tiup/tiup-component-cluster-check.md @@ -74,7 +74,7 @@ THP が有効になっているかどうかを確認するには、次のコマ SELinuxを無効にするか、permissiveモードに設定する必要があります。現在のステータスを確認するには、 [ゲットエンフォース(8)](https://linux.die.net/man/8/getenforce)ユーティリティを使用してください。 -SELinuxが無効になっていない場合は、 `/etc/selinux/config`ファイルを開き、 `SELINUX=`で始まる行を`SELINUX=disabled`に変更します。この変更を行った後、システムを再起動する必要があります。7または`enforcing` `permissive` `disabled`への変更は、再起動しないと有効になりません。 +SELinuxが無効になっていない場合は、 `/etc/selinux/config`ファイルを開き、 `SELINUX=`で始まる行を`SELINUX=disabled`に変更します。この変更を行った後、システムを再起動する必要があります。`enforcing`または`permissive`から`disabled`への変更は、再起動しないと有効になりません。 一部のシステム（Ubuntuなど）では、 `/etc/selinux/config`ファイルが存在せず、getenforceユーティリティがインストールされていない場合があります。その場合は、この手順をスキップしてください。 diff --git a/tiup/tiup-component-cluster-clean.md b/tiup/tiup-component-cluster-clean.md index 30b8831004d8f..2092e0a7c6504 100644 --- a/tiup/tiup-component-cluster-clean.md +++ b/tiup/tiup-component-cluster-clean.md @@ -23,7 +23,7 @@ tiup cluster clean [flags] ### --all {#all} -- データとログを同時に消去します。1と`--data` `--log`同時に指定するのと同じです。 +- データとログを同時に消去します。`--data`と`--log`を同時に指定するのと同じです。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 - 指定されていない場合は、少なくとも次のいずれかのオプションを指定する必要があります。 diff --git a/tiup/tiup-component-cluster-deploy.md b/tiup/tiup-component-cluster-deploy.md index 28323d22d9f08..a0c4932dfefd7 100644 --- a/tiup/tiup-component-cluster-deploy.md +++ b/tiup/tiup-component-cluster-deploy.md @@ -39,15 +39,15 @@ tiup cluster deploy [flags] ### --ignore-config-check {#ignore-config-check} -- このオプションは、構成チェックをスキップするために使用されます。コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `を使用してTiDB、TiKV、およびPDコンポーネントの構成がチェックされます。3 ``デプロイされたバイナリファイルのパスです。5 ``ユーザー設定に基づいて生成された構成ファイルです。 +- このオプションは、構成チェックをスキップするために使用されます。コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `を使用してTiDB、TiKV、およびPDコンポーネントの構成がチェックされます。``は、デプロイされたバイナリファイルのパスです。``は、ユーザー設定に基づいて生成された構成ファイルです。 - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 - デフォルト: false ### --no-labels {#no-labels} - このオプションはラベル チェックをスキップするために使用されます。 -- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、PDがクラスタトポロジを学習できないため、同じ物理マシン上の異なるTiKVノードにリージョンの複数のレプリカをスケジュールし、その物理マシンを単一のポイントにしてしまうというリスクが生じます。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)参照してください。 -- テスト環境では、このリスクが重要になる可能性があるため、 `--no-labels`使用してチェックをスキップできます。 +- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、PDがクラスタトポロジを学習できないため、同じ物理マシン上の異なるTiKVノードにリージョンの複数のレプリカをスケジュールし、その物理マシンを単一のポイントにしてしまうというリスクが生じます。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)を参照してください。 +- テスト環境では、このリスクが重要になる可能性があるため、 `--no-labels`を使用してチェックをスキップできます。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 diff --git a/tiup/tiup-component-cluster-display.md b/tiup/tiup-component-cluster-display.md index 4388dc81d4405..4bfda6c4cfa9e 100644 --- a/tiup/tiup-component-cluster-display.md +++ b/tiup/tiup-component-cluster-display.md @@ -19,7 +19,7 @@ tiup cluster display [flags] ### --dashboard {#dashboard} -- デフォルトでは、クラスター全体のすべてのノード情報が表示されます。1オプションを指定すると、 `--dashboard`ボード情報のみが表示されます。 +- デフォルトでは、クラスター全体のすべてのノード情報が表示されます。`--dashboard`オプションを指定すると、ダッシュボード情報のみが表示されます。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 @@ -82,7 +82,7 @@ tiup cluster display [flags] - ポート: サービスが占有するポート番号 - OS/アーキテクチャ: このノードのオペレーティングシステムとマシンアーキテクチャ - ステータス: ノードサービスの現在のステータス - - データ ディレクトリ: サービスのデータ ディレクトリ。1 `-`データ ディレクトリがないことを意味します。 + - データ ディレクトリ: サービスのデータ ディレクトリ。`-`データ ディレクトリがないことを意味します。 - デプロイディレクトリ: サービスのデプロイディレクトリ ### ノードサービスステータス {#node-service-status} diff --git a/tiup/tiup-component-cluster-edit-config.md b/tiup/tiup-component-cluster-edit-config.md index e5dc8410cfab1..cefb9149e3cd9 100644 --- a/tiup/tiup-component-cluster-edit-config.md +++ b/tiup/tiup-component-cluster-edit-config.md @@ -5,7 +5,7 @@ summary: tiup cluster edit-config` コマンドを使用すると、デプロイ # tiup cluster edit-config {#tiup-cluster-edit-config} -クラスタのデプロイ後にクラスタ設定を変更する必要がある場合は、 `tiup cluster edit-config`コマンドを使用してエディタを起動し、クラスタの[トポロジファイル](/tiup/tiup-cluster-topology-reference.md)編集できます。このエディタは、デフォルトで`$EDITOR`環境変数に指定されています。7 環境変数が存在しない場合は、 `$EDITOR`エディタ`vi`使用されます。 +クラスタのデプロイ後にクラスタ設定を変更する必要がある場合は、 `tiup cluster edit-config`コマンドを使用してエディタを起動し、クラスタの[トポロジファイル](/tiup/tiup-cluster-topology-reference.md)編集できます。このエディタは、デフォルトで`$EDITOR`環境変数に指定されています。`$EDITOR`環境変数が存在しない場合は、 `vi`エディタが使用されます。 > **Note:** > diff --git a/tiup/tiup-component-cluster-help.md b/tiup/tiup-component-cluster-help.md index 9ef4fc98d9b50..177c3009e6685 100644 --- a/tiup/tiup-component-cluster-help.md +++ b/tiup/tiup-component-cluster-help.md @@ -5,7 +5,7 @@ summary: tiup-cluster は、コマンドラインインターフェースでユ # tiup cluster help {#tiup-cluster-help} -tiup-cluster は、コマンドラインインターフェースでユーザー向けに豊富なヘルプ情報を提供します。ヘルプ情報は、コマンド`help`またはオプション`--help`で取得できます。5 `tiup cluster help `基本的に`tiup cluster --help`と同じです。 +tiup-cluster は、コマンドラインインターフェースでユーザー向けに豊富なヘルプ情報を提供します。ヘルプ情報は、コマンド`help`またはオプション`--help`で取得できます。`tiup cluster help `基本的に`tiup cluster --help`と同じです。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-cluster-list.md b/tiup/tiup-component-cluster-list.md index 5594ed5a27876..5bbebab6b149d 100644 --- a/tiup/tiup-component-cluster-list.md +++ b/tiup/tiup-component-cluster-list.md @@ -5,7 +5,7 @@ summary: tiup-cluster は、同一の制御マシンを用いた複数のクラ # tiup cluster list {#tiup-cluster-list} -tiup-cluster は、同じコントロールマシンを使用して複数のクラスターをデプロイすることをサポートします。1 コマンド`tiup cluster list` 、現在ログインしているユーザーがこのコントロールマシンを使用してデプロイしたすべてのクラスターを出力します。 +tiup-cluster は、同じコントロールマシンを使用して複数のクラスターをデプロイすることをサポートします。`tiup cluster list`コマンドは、現在ログインしているユーザーがこのコントロールマシンを使用してデプロイしたすべてのクラスターを出力します。 > **Note:** > diff --git a/tiup/tiup-component-cluster-reload.md b/tiup/tiup-component-cluster-reload.md index 0a8c5360c2d06..ecdfee3cb7319 100644 --- a/tiup/tiup-component-cluster-reload.md +++ b/tiup/tiup-component-cluster-reload.md @@ -17,13 +17,13 @@ tiup cluster reload [flags] ## オプション {#options} -### --force {#force} +### --force {#--force} - 再ロード プロセス中のエラーを無視し、強制的に再ロードします。 - データ型: `BOOLEAN` - デフォルト: false -### --transfer-timeout {#transfer-timeout} +### --transfer-timeout {#--transfer-timeout} - PDまたはTiKVを再起動する際、再起動されたノードのリーダーノードが最初に他のノードに移行されるため、移行プロセスには時間がかかります。最大待機時間（秒単位）を`-transfer-timeout`に設定できます。タイムアウト後、サービスは待機せずに直接再起動できます。 - データ型: `UINT` @@ -33,13 +33,13 @@ tiup cluster reload [flags] > > 待機をスキップして直接再起動する場合、サービスのパフォーマンスが不安定になる可能性があります。 -### --ignore-config-check {#ignore-config-check} +### --ignore-config-check {#--ignore-config-check} -- コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `使用して TiDB、TiKV、PD コンポーネントの設定がチェックされます。3 ``デプロイされたバイナリファイルのパスです。5 ``ユーザー設定に基づいて生成された設定ファイルです。このチェックをスキップしたい場合は、このオプションを使用できます。 +- コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `を使用して TiDB、TiKV、PD コンポーネントの設定がチェックされます。``は、デプロイされたバイナリファイルのパスです。``は、ユーザー設定に基づいて生成された設定ファイルです。このチェックをスキップしたい場合は、このオプションを使用できます。 - データ型: `BOOLEAN` - デフォルト: false -### -N, --node {#n-node} +### -N, --node {#-n---node} - 再起動するノードを指定します。指定しない場合は、すべてのノードが再起動されます。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 - データ型: `STRINGS` @@ -48,9 +48,9 @@ tiup cluster reload [flags] > **Note:** > > - `-R, --role`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 -> - オプション`--skip-restart`指定した場合、オプション`-N, --node`は無効になります。 +> - オプション`--skip-restart`を指定した場合、オプション`-N, --node`は無効になります。 -### -R, --role {#r-role} +### -R, --role {#-r---role} - 再起動するロールを指定します。指定しない場合は、すべてのロールが再起動されます。このオプションの値は、ノードロールのカンマ区切りのリストです。ロールは、表[クラスターステータス](/tiup/tiup-component-cluster-display.md)の2番目の列です。 - データ型: `STRINGS` @@ -59,9 +59,9 @@ tiup cluster reload [flags] > **Note:** > > 1. `-N, --node`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 -> 2. オプション`--skip-restart`指定した場合、オプション`-R, --role`は無効になります。 +> 2. オプション`--skip-restart`を指定した場合、オプション`-R, --role`は無効になります。 -### --skip-restart {#skip-restart} +### --skip-restart {#--skip-restart} `tiup cluster reload`コマンドは 2 つの操作を実行します。 @@ -73,13 +73,13 @@ tiup cluster reload [flags] - データ型: `BOOLEAN` - デフォルト: false -### -h, --help {#h-help} +### -h, --help {#-h---help} - ヘルプ情報を出力します。 - データ型: `BOOLEAN` - デフォルト: false -### --pre-restart-script {#pre-restart-script} +### --pre-restart-script {#--pre-restart-script} > **Warning:** > @@ -87,9 +87,9 @@ tiup cluster reload [flags] - リロード前にスクリプトを実行します。 - データ型: `STRINGS` -- このオプションは、リロードするノードで実行されるスクリプトのパスを指定します。1 `--skip-restart` `true`に設定した場合は無効になります。 +- このオプションは、リロードするノードで実行されるスクリプトのパスを指定します。`--skip-restart` `true`に設定した場合は無効になります。 -### --post-restart-script {#post-restart-script} +### --post-restart-script {#--post-restart-script} > **Warning:** > @@ -97,7 +97,7 @@ tiup cluster reload [flags] - リロード後にスクリプトを実行します。 - データ型: `STRINGS` -- このオプションは、ノードのリロード後に実行されるスクリプトのパスを指定します。1 `--skip-restart` `true`に設定されている場合は有効になりません。 +- このオプションは、ノードのリロード後に実行されるスクリプトのパスを指定します。`--skip-restart` `true`に設定されている場合は有効になりません。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-rename.md b/tiup/tiup-component-cluster-rename.md index 1fece741a3b46..da090e890d2de 100644 --- a/tiup/tiup-component-cluster-rename.md +++ b/tiup/tiup-component-cluster-rename.md @@ -11,7 +11,7 @@ summary: tiup cluster renameコマンドは、デプロイ後にクラスター > > TiUPクラスターの`dashboard_dir`フィールドが`grafana_servers`に設定されている場合、コマンド`tiup cluster rename`を実行してクラスターの名前を変更した後、次の追加手順が必要になります。 > -> - ローカル ダッシュボード ディレクトリ内の`*.json`ファイルについては、各ファイルの`datasource`フィールドを新しいクラスター名に更新します。5 `datasource`値はクラスターの名前である必要があるためです。 +> - ローカル ダッシュボード ディレクトリ内の`*.json`ファイルについては、各ファイルの`datasource`フィールドを新しいクラスター名に更新します。`datasource`の値はクラスターの名前である必要があるためです。 > - コマンド`tiup cluster reload -R grafana`を実行します。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-cluster-replay.md b/tiup/tiup-component-cluster-replay.md index 464699eb76c68..a22ed66ed0a97 100644 --- a/tiup/tiup-component-cluster-replay.md +++ b/tiup/tiup-component-cluster-replay.md @@ -13,7 +13,7 @@ summary: tiup cluster replay` コマンドを使用すると、失敗したク tiup cluster replay [flags] ``` -- `` : 再試行するコマンドの`audit-id` 。6 [`tiup cluster audit`](/tiup/tiup-component-cluster-audit.md)を使用すると、履歴コマンドとその`audit-id`番目を表示できます。 +- `` : 再試行するコマンドの`audit-id` 。[`tiup cluster audit`](/tiup/tiup-component-cluster-audit.md)を使用すると、履歴コマンドとその`audit-id`を表示できます。 ## オプション {#option} diff --git a/tiup/tiup-component-cluster-upgrade.md b/tiup/tiup-component-cluster-upgrade.md index b23b2320d7efa..4e4580962b4ca 100644 --- a/tiup/tiup-component-cluster-upgrade.md +++ b/tiup/tiup-component-cluster-upgrade.md @@ -18,9 +18,9 @@ tiup cluster upgrade [flags] ## オプション {#options} -### --force {#force} +### --force {#--force} -- クラスターをアップグレードするには、クラスターが現在起動していることを確認する必要があります。場合によっては、クラスターが起動していない状態でアップグレードを実行したい場合があります。その場合は、 `--force`使用すると、アップグレード中のエラーを無視し、バイナリファイルを強制的に置き換えてクラスターを起動できます。 +- クラスターをアップグレードするには、クラスターが現在起動していることを確認する必要があります。場合によっては、クラスターが起動していない状態でアップグレードを実行したい場合があります。その場合は、 `--force`を使用すると、アップグレード中のエラーを無視し、バイナリファイルを強制的に置き換えてクラスターを起動できます。 - データ型: `BOOLEAN` - デフォルト: false @@ -28,9 +28,9 @@ tiup cluster upgrade [flags] > > サービスを提供しているクラスターを強制的にアップグレードすると、サービスが利用できなくなる可能性があります。アップグレードが成功すると、起動していないクラスターは自動的に起動されます。 -### --transfer-timeout {#transfer-timeout} +### --transfer-timeout {#--transfer-timeout} -- PDまたはTiKVをアップグレードする場合、アップグレード対象ノードのリーダーノードが最初に他のノードに移行されます。移行プロセスには時間がかかります。1 `-transfer-timeout`で最大待機時間（秒単位）を設定できます。タイムアウト後、待機はスキップされ、サービスは直接アップグレードされます。 +- PDまたはTiKVをアップグレードする場合、アップグレード対象ノードのリーダーノードが最初に他のノードに移行されます。移行プロセスには時間がかかります。`-transfer-timeout`で最大待機時間（秒単位）を設定できます。タイムアウト後、待機はスキップされ、サービスは直接アップグレードされます。 - データ型: `uint` - デフォルト: 600 @@ -38,98 +38,98 @@ tiup cluster upgrade [flags] > > 待機をスキップしてサービスを直接アップグレードすると、サービスのパフォーマンスが不安定になる可能性があります。 -### --ignore-config-check {#ignore-config-check} +### --ignore-config-check {#--ignore-config-check} -- バイナリの更新後、 ` --config-check `使用して TiDB、TiKV、PD コンポーネントの構成チェックが実行されます。3 ``新しくデプロイされたバイナリへのパス、 ``ユーザー設定に基づいて生成された構成ファイルです。このチェックをスキップするには、 `--ignore-config-check`オプションを使用します。 +- バイナリの更新後、 ` --config-check `を使用して TiDB、TiKV、PD コンポーネントの構成チェックが実行されます。``は、新しくデプロイされたバイナリへのパスであり、 ``は、ユーザー設定に基づいて生成された構成ファイルです。このチェックをスキップするには、 `--ignore-config-check`オプションを使用します。 - データ型: `BOOLEAN` - デフォルト: false -### --ignore-version-check {#ignore-version-check} +### --ignore-version-check {#--ignore-version-check} -- アップグレード前に、 TiUP はターゲットバージョンが現在のバージョン以上であるかどうかを確認します。このチェックを省略するには、オプション`--ignore-version-check`使用します。 +- アップグレード前に、 TiUP はターゲットバージョンが現在のバージョン以上であるかどうかを確認します。このチェックを省略するには、オプション`--ignore-version-check`を使用します。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 -### --offline {#offline} +### --offline {#--offline} - 現在のクラスターが実行中でないことを宣言します。このオプションが指定されると、 TiUP はサービスリーダーを別のノードに移動させたり、サービスを再起動したりせず、クラスターコンポーネントのバイナリファイルのみを置き換えます。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 -### --pdバージョン {#pd-version} +### --pdバージョン {#--pd-version} - PDのバージョンを指定します。このオプションを設定すると、PDのバージョンとクラスターのバージョンが一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、PD のバージョンはクラスターのバージョンと一致し続けます。 -### --tikv バージョン {#tikv-version} +### --tikv バージョン {#--tikv-version} - TiKVのバージョンを指定します。このオプションを設定すると、TiKVのバージョンはクラスターのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、TiKV のバージョンはクラスターのバージョンと一致し続けます。 -### --tikv-cdc-バージョン {#tikv-cdc-version} +### --tikv-cdc-バージョン {#--tikv-cdc-version} - TiKV CDCのバージョンを指定します。このオプションを設定すると、TiKV CDCのバージョンはクラスタのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、TiKV CDC のバージョンはクラスターのバージョンと一致し続けます。 -### --tiflash-version {#tiflash-version} +### --tiflash-version {#--tiflash-version} - TiFlashのバージョンを指定します。このオプションを設定すると、 TiFlashのバージョンはクラスターのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、 TiFlashのバージョンはクラスターのバージョンと一致したままになります。 -### --cdc バージョン {#cdc-version} +### --cdc バージョン {#--cdc-version} - TiCDCのバージョンを指定します。このオプションを設定すると、TiCDCのバージョンはクラスターのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、TiCDC のバージョンはクラスターのバージョンと一致し続けます。 -### --tiproxy バージョン {#tiproxy-version} +### --tiproxy バージョン {#--tiproxy-version} - TiProxyのバージョンを指定します。このオプションを設定すると、TiProxyのバージョンはクラスタのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、TiProxy のバージョンはクラスターのバージョンと一致したままになります。 -### --tidb-ダッシュボードバージョン {#tidb-dashboard-version} +### --tidb-ダッシュボードバージョン {#--tidb-dashboard-version} - TiDB Dashboardのバージョンを指定します。このオプションを設定すると、TiDB Dashboardのバージョンはクラスターのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、TiDB Dashboardのバージョンはクラスターのバージョンと一致したままになります。 -### --alertmanager-バージョン {#alertmanager-version} +### --alertmanager-バージョン {#--alertmanager-version} - Alertmanagerのバージョンを指定します。このオプションを設定すると、Alertmanagerのバージョンはクラスターのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、アラート マネージャーのバージョンはクラスターのバージョンと一致したままになります。 -### --blackbox-exporter-version {#blackbox-exporter-version} +### --blackbox-exporter-version {#--blackbox-exporter-version} - Blackbox Exporterのバージョンを指定します。このオプションを設定すると、Blackbox Exporterのバージョンとクラスタのバージョンが一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、Blackbox Exporter のバージョンはクラスターのバージョンと一致したままになります。 -### --node-exporter-version {#node-exporter-version} +### --node-exporter-version {#--node-exporter-version} - Node Exporterのバージョンを指定します。このオプションを設定すると、Node Exporterのバージョンとクラスターのバージョンが一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、Node Exporter のバージョンはクラスターのバージョンと一致したままになります。 -### --再起動タイムアウト {#restart-timeout} +### --再起動タイムアウト {#--restart-timeout} - ローリング アップグレード中にコンポーネントをアップグレードした後の待機時間を指定します。 - データ型: `STRINGS` [`golang time.ParseDuration`](https://pkg.go.dev/time#ParseDuration)で解析できるすべての型がサポートされます。 - デフォルト: `0` - このオプションを指定しないと、コンポーネントのアップグレード後に待機時間は発生しません。 -### -h, --help {#h-help} +### -h, --help {#-h---help} - ヘルプ情報を出力します。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 -### ---アップグレード前スクリプト {#pre-upgrade-script} +### ---アップグレード前スクリプト {#---pre-upgrade-script} > **Warning:** > @@ -139,7 +139,7 @@ tiup cluster upgrade [flags] - データ型: `STRINGS` - このオプションは、アップグレードするノードで実行されるスクリプトのパスを指定します。 -### ---アップグレード後のスクリプト {#post-upgrade-script} +### ---アップグレード後のスクリプト {#---post-upgrade-script} > **Warning:** > diff --git a/tiup/tiup-component-dm-display.md b/tiup/tiup-component-dm-display.md index caef34d6cd430..a89d82209efe7 100644 --- a/tiup/tiup-component-dm-display.md +++ b/tiup/tiup-component-dm-display.md @@ -55,7 +55,7 @@ tiup dm display [flags] - `Ports` : サービスで使用されるポート番号。 - `OS/Arch` : ノードのオペレーティング システムとマシンアーキテクチャ。 - `Status` : ノード上のサービスの現在のステータス。 - - `Data Dir` : サービスのデータ ディレクトリ。2 `-`データ ディレクトリが存在しないことを意味します。 + - `Data Dir` : サービスのデータ ディレクトリ。`-`データ ディレクトリが存在しないことを意味します。 - `Deploy Dir` : サービスのデプロイメント ディレクトリ。 [<< 前のページに戻る - TiUP DMコマンドリスト](/tiup/tiup-component-dm.md#command-list) diff --git a/tiup/tiup-component-dm-edit-config.md b/tiup/tiup-component-dm-edit-config.md index d2ab7b3153407..b087b49ce15a2 100644 --- a/tiup/tiup-component-dm-edit-config.md +++ b/tiup/tiup-component-dm-edit-config.md @@ -5,7 +5,7 @@ summary: tiup dm edit-config`コマンドを使用すると、デプロイメン # tiup dm 編集設定 {#tiup-dm-edit-config} -クラスターのデプロイ後にクラスターサービス設定を変更する必要がある場合は、 `tiup dm edit-config`コマンドを使用してエディターを起動し、指定したクラスターの[トポロジファイル](/tiup/tiup-dm-topology-reference.md) . を変更できます。このエディターは、デフォルトで`$EDITOR`環境変数に指定されています。7 環境変数が存在しない場合は、 `$EDITOR`エディター`vi`使用されます。 +クラスターのデプロイ後にクラスターサービス設定を変更する必要がある場合は、 `tiup dm edit-config`コマンドを使用してエディターを起動し、指定したクラスターの[トポロジファイル](/tiup/tiup-dm-topology-reference.md) . を変更できます。このエディターは、デフォルトで`$EDITOR`環境変数に指定されています。`$EDITOR`環境変数が存在しない場合は、 `vi`エディターが使用されます。 > **Note:** > diff --git a/tiup/tiup-component-dm-import.md b/tiup/tiup-component-dm-import.md index 6ecd4eca9ace2..982b8d1dd6da4 100644 --- a/tiup/tiup-component-dm-import.md +++ b/tiup/tiup-component-dm-import.md @@ -20,8 +20,8 @@ DM v1.0では、クラスターは基本的にTiDB Ansibleを使用してデプ > - 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コンポーネントを最新バージョンにアップグレードします。 +> - 一部のコンポーネントのデプロイメントディレクトリは、元のクラスタのものと異なる場合があります。`display`コマンドで確認できます。 +> - クラスターをインポートする前に、 `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-list.md b/tiup/tiup-component-dm-list.md index 06432d8dd6866..6f88dabf2eaa6 100644 --- a/tiup/tiup-component-dm-list.md +++ b/tiup/tiup-component-dm-list.md @@ -5,7 +5,7 @@ summary: tiup-dm は、同一の制御マシンを用いた複数のクラスタ # tiup dm list {#tiup-dm-list} -`tiup-dm` `tiup dm list`同じコントロールマシンを使用して複数のクラスターをデプロイすることをサポートしています。2 コマンドを使用すると、現在ログインしているユーザーがコントロールマシンを使用してデプロイしているクラスターを確認できます。 +`tiup-dm`は、同じコントロールマシンを使用して複数のクラスターをデプロイすることをサポートしています。`tiup dm list`コマンドを使用すると、現在ログインしているユーザーがコントロールマシンを使用してデプロイしているクラスターを確認できます。 > **Note:** > diff --git a/tiup/tiup-component-dm-patch.md b/tiup/tiup-component-dm-patch.md index 32eb8223bab68..5861f6af6719c 100644 --- a/tiup/tiup-component-dm-patch.md +++ b/tiup/tiup-component-dm-patch.md @@ -145,7 +145,7 @@ tiup dm patch [flags] 172.16.100.21:9090 prometheus 172.16.100.21 9090 linux/x86_64 Up /home/tidb/dm/data/prometheus-9090 /home/tidb/dm/deploy/prometheus-9090 Total nodes: 5 - 指定されたノードまたは指定されたロールにホットフィックスを適用します。1と`-N` `-R`が指定されている場合は、共通部分が採用されます。 + 指定されたノードまたは指定されたロールにホットフィックスを適用します。`-N`と`-R`の両方が指定されている場合は、共通部分が採用されます。 # Apply hotfix to a specified node. tiup dm patch dm-test dm-master-hotfix-linux-amd64.tar.gz -N 172.16.100.21:8261 diff --git a/tiup/tiup-component-dm-replay.md b/tiup/tiup-component-dm-replay.md index fb75a637c3c2a..e805b5e1004f4 100644 --- a/tiup/tiup-component-dm-replay.md +++ b/tiup/tiup-component-dm-replay.md @@ -13,7 +13,7 @@ summary: tiup dm replay` コマンドを使用すると、失敗したクラス tiup dm replay [flags] ``` -- `` : 再試行するコマンドの`audit-id` 。6 [`tiup dm audit`](/tiup/tiup-component-dm-audit.md)を使用すると、履歴コマンドとその`audit-id`番目を表示できます。 +- `` : 再試行するコマンドの`audit-id` 。[`tiup dm audit`](/tiup/tiup-component-dm-audit.md)を使用すると、履歴コマンドとその`audit-id`を表示できます。 ## オプション {#option} diff --git a/tiup/tiup-component-dm-scale-out.md b/tiup/tiup-component-dm-scale-out.md index 5faa58fa68878..4f28b998ea335 100644 --- a/tiup/tiup-component-dm-scale-out.md +++ b/tiup/tiup-component-dm-scale-out.md @@ -5,7 +5,7 @@ summary: tiup dm scale-out` コマンドは、新しいノードへの SSH 接 # tiup dm scale-out {#tiup-dm-scale-out} -`tiup dm scale-out`コマンドはクラスタのスケールアウトに使用されます。クラスタのスケールアウトの内部ロジックは、クラスタのデプロイメントと同様です。3 `tiup-dm`コンポーネントは、まず新しいノードへのSSH接続を確立し、ターゲットノードに必要なディレクトリを作成し、次にデプロイメントを実行してサービスを起動します。 +`tiup dm scale-out`コマンドはクラスタのスケールアウトに使用されます。クラスタのスケールアウトの内部ロジックは、クラスタのデプロイメントと同様です。`tiup-dm`コンポーネントは、まず新しいノードへのSSH接続を確立し、ターゲットノードに必要なディレクトリを作成し、次にデプロイメントを実行してサービスを起動します。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-management.md b/tiup/tiup-component-management.md index d963b531d0585..291b568df658e 100644 --- a/tiup/tiup-component-management.md +++ b/tiup/tiup-component-management.md @@ -136,7 +136,7 @@ tiup status - `Name` : インスタンスのタグ名。 - `Component` : インスタンスのコンポーネント名。 - `PID` : 動作中のインスタンスのプロセス ID。 -- `Status` : インスタンスのステータス。2 `RUNNING`インスタンスが動作中であることを意味します。4 `TERM`インスタンスが終了していることを意味します。 +- `Status` : インスタンスのステータス。`RUNNING`インスタンスが動作中であることを意味します。`TERM`インスタンスが終了していることを意味します。 - `Created Time` : インスタンスの開始時刻。 - `Directory` : インスタンスの作業ディレクトリ`--tag`を使用して指定できます。 - `Binary` : インスタンスの実行可能プログラム`--binpath`を使用して指定できます。 @@ -154,7 +154,7 @@ tiup clean [tag] [flags] - `--all` : すべてのインスタンス情報をクリーンアップします。 -上記のコマンドでは、 `tag`クリーンアップするインスタンスタグです。3 `--all`使用すると、タグは渡されません。 +上記のコマンドでは、 `tag`クリーンアップするインスタンスタグです。`--all`を使用すると、タグは渡されません。 例 1: `experiment`タグ名を持つコンポーネントインスタンスをクリーンアップします。 @@ -183,7 +183,7 @@ tiup uninstall [component][:version] [flags] - `--all` : すべてのコンポーネントまたはバージョンをアンインストールします。 - `--self` : TiUP自体をアンインストールします。 -`component`はアンインストールするコンポーネントです。2 `version`アンインストールするバージョンです。8 `tiup uninstall`では、 `component`と`version`どちらも無視できます。どちらか一方を無視する場合は、 `--all`フラグを追加する必要があります。 +`component`はアンインストールするコンポーネントです。`version`アンインストールするバージョンです。`tiup uninstall`では、 `component`と`version`どちらも無視できます。どちらか一方を無視する場合は、 `--all`フラグを追加する必要があります。 - バージョンを無視する場合、 `--all`を追加すると、このコンポーネントのすべてのバージョンがアンインストールされます。 - バージョンとコンポーネントの両方が無視される場合、 `--all`追加すると、すべてのバージョンのすべてのコンポーネントがアンインストールされます。 diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 66a907642412f..6f29467dc2719 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -25,7 +25,7 @@ TiUPを使用した DM クラスターのデプロイメントのトポロジ構 `global`セクションはクラスターのグローバル構成に対応し、次のフィールドがあります。 -- `user` : デプロイされたクラスタを起動するユーザー。デフォルト値は「tidb」です。2 ``に指定されたユーザーがターゲットマシン上に存在しない場合、 TiUP は自動的にユーザーの作成を試みます。 +- `user` : デプロイされたクラスタを起動するユーザー。デフォルト値は「tidb」です。``に指定されたユーザーがターゲットマシン上に存在しない場合、 TiUP は自動的にユーザーの作成を試みます。 - `group` : ユーザーが自動作成された際に所属するユーザーグループ。デフォルト値は``フィールドと同じです。指定されたグループが存在しない場合は、自動的に作成されます。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポート。デフォルト値は「22」です。 - `deploy_dir` : 各コンポーネントのデプロイメントディレクトリ。デフォルト値は「deploy」です。構築ルールは以下のとおりです。 @@ -63,7 +63,7 @@ global: ### `server_configs` {#server-configs} -`server_configs` `server_configs`サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。2 セクションと同様に、 `global`セクションの設定は、インスタンス内の同じキーを持つ設定によって上書きできます。6 `server_configs`は主に以下のフィールドが含まれます。 +`server_configs`は、サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。`global`セクションと同様に、 `server_configs`セクションの設定は、インスタンス内の同じキーを持つ設定によって上書きできます。`server_configs`には主に以下のフィールドが含まれます。 - `master` : DMマスターサービスに関連する設定。サポートされているすべての設定項目については、 [DMマスターコンフィグレーションファイル](/dm/dm-master-configuration-file.md)参照してください。 - `worker` : DM ワーカー サービスに関連する構成。サポートされているすべての構成項目については、 [DMワーカーコンフィグレーションファイル](/dm/dm-worker-configuration-file.md)参照してください。 @@ -93,8 +93,8 @@ server_configs: - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 -- `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、ターゲットマシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 -- `config` ：このフィールドの設定ルールは、セクション`server_configs`の`master`と同じです。6を指定した場合、セクション`config` `config`設定が`server_configs` `master`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 +- `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、ターゲットマシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)を使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 +- `config` ：このフィールドの設定ルールは、セクション`server_configs`の`master`と同じです。`config`を指定した場合、`config`の設定が`server_configs`セクションの`master`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 - `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`os`値です。 - `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`arch`値になります。 - `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 @@ -149,8 +149,8 @@ master_servers: - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 -- `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、ターゲットマシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 -- `config` ：このフィールドの設定ルールは、セクション`server_configs`の`worker`と同じです。6を指定した場合、セクション`config` `config`設定が`server_configs` `worker`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 +- `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、ターゲットマシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)を使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 +- `config` ：このフィールドの設定ルールは、セクション`server_configs`の`worker`と同じです。`config`を指定した場合、`config`の設定が`server_configs`セクションの`worker`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 - `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`os`値です。 - `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`arch`値になります。 - `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 diff --git a/tiup/tiup-overview.md b/tiup/tiup-overview.md index d8ee5335ad5d5..6e401479b2f35 100644 --- a/tiup/tiup-overview.md +++ b/tiup/tiup-overview.md @@ -125,4 +125,4 @@ tiup --help TiUPコマンドは TiUP の内部コードに実装され、パッケージ管理操作に使用されますが、 TiUPコンポーネントはTiUPコマンドによってインストールされる独立したコンポーネントパッケージです。 -たとえば、 `tiup list`コマンドを実行すると、 TiUP は独自の内部コードを直接実行します。3 コマンドを実行する`tiup playground` 、 TiUP はTiUP「playground」という名前のローカル パッケージがあるかどうかを確認し、ない場合はミラーからパッケージをダウンロードして実行します。 +たとえば、 `tiup list`コマンドを実行すると、 TiUP は独自の内部コードを直接実行します。`tiup playground`コマンドを実行すると、 TiUP は「playground」という名前のローカル パッケージがあるかどうかを確認し、ない場合はミラーからパッケージをダウンロードして実行します。 diff --git a/tiup/tiup-playground.md b/tiup/tiup-playground.md index 6176a096075cb..c04f4ec73c9db 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`を指定できます。`pid`を表示するには、 `tiup playground display`を実行します。 ```shell tiup playground scale-in --pid 86526 diff --git a/tiup/tiup-reference.md b/tiup/tiup-reference.md index db58aaa79c75b..1eb7f476c6458 100644 --- a/tiup/tiup-reference.md +++ b/tiup/tiup-reference.md @@ -17,7 +17,7 @@ tiup [flags] [args...] # Runs a component `--help`コマンドを使用すると、特定のコマンドの情報を取得できます。各コマンドの概要には、そのパラメータと使用方法が表示されます。必須パラメータは山括弧で、オプションパラメータは角括弧で示されます。 -``コマンド名を表します。サポートされているコマンドのリストについては、以下の[コマンドリスト](#command-list)参照してください。4 ``コンポーネント名を表します。サポートされているコンポーネントのリストについては、以下の[コンポーネントリスト](#component-list)参照してください。 +``はコマンド名を表します。サポートされているコマンドのリストについては、以下の[コマンドリスト](#command-list)を参照してください。``はコンポーネント名を表します。サポートされているコンポーネントのリストについては、以下の[コンポーネントリスト](#component-list)を参照してください。 ## オプション {#options} @@ -25,8 +25,8 @@ tiup [flags] [args...] # Runs a component - このオプションを有効にすると、指定されたバイナリ ファイルのパスが出力されます。 - - `tiup --binary `実行すると、最新の安定版がインストールされた``コンポーネントのパスが表示されます。5 ``インストールされていない場合はエラーが返されます。 - - `tiup --binary :`実行すると、インストールされた``コンポーネントの``パスが出力されます。この``が出力されない場合は、エラーが返されます。 + - `tiup --binary `を実行すると、最新の安定版がインストールされた``コンポーネントのパスが表示されます。``がインストールされていない場合はエラーが返されます。 + - `tiup --binary :`を実行すると、インストールされた``コンポーネントの``パスが出力されます。この``が出力されない場合は、エラーが返されます。 - データ型: `BOOLEAN` diff --git a/tiup/tiup-troubleshooting-guide.md b/tiup/tiup-troubleshooting-guide.md index 6ba4809fba802..2d9253ceeb4f0 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はミラーサーバーから最新のコンポーネントリストを毎回更新するわけではありません。`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 `実行することでコンポーネントリストを更新できます。 +前回の問題と同様に、コンポーネントのバージョン情報は、ローカルキャッシュが存在しない場合にのみミラーサーバーから取得されます。`tiup list `を実行することでコンポーネントリストを更新できます。 ### コンポーネントのダウンロードプロセスが中断されました {#component-downloading-process-is-interrupted} @@ -33,8 +33,8 @@ CDNサーバーのキャッシュ時間が短いため、新しいチェック この問題を解決するには、 `tiup cluster deploy -i identity_file`実行して秘密鍵を指定したかどうかを確認します。 -- `-i`フラグが指定されていない場合、 TiUP は秘密鍵のパスを自動的に検出しない可能性があります。3 `-i`使用して秘密鍵のパスを明示的に指定することをお勧めします。 -- フラグ`-i`が指定されている場合、 TiUPは指定された秘密鍵を使用してリモートホストにログインできない可能性があります。3コマンド`ssh -i identity_file user@remote`手動で実行することで確認できます。 +- `-i`フラグが指定されていない場合、 TiUP は秘密鍵のパスを自動的に検出しない可能性があります。`-i`を使用して秘密鍵のパスを明示的に指定することをお勧めします。 +- フラグ`-i`が指定されている場合、 TiUPは指定された秘密鍵を使用してリモートホストにログインできない可能性があります。`ssh -i identity_file user@remote`コマンドを手動で実行することで確認できます。 - リモート ホストへのログインにパスワードを使用する場合は、フラグ`-p`を指定して正しいログイン パスワードを入力したことを確認してください。 ### TiUPクラスタコンポーネントを使用したクラスタのアップグレード プロセスが中断されます {#the-process-of-upgrading-the-cluster-using-the-tiup-cluster-component-is-interrupted} diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md index 9eb8c9f1f97b1..bde1d9e6e008b 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -80,7 +80,7 @@ v6.0.0以降、TiDBは、読み取り/書き込み競合が稀なシナリオに 分離レベル`READ-COMMITTED`が使用され、ステートメントが`SELECT`多く、読み取り/書き込みの競合がまれなシナリオでは、この変数を有効にすると、グローバル タイムスタンプを取得する際のレイテンシーとコストを回避できます。 -v6.3.0以降、TiDBはポイント書き込みの競合が少ないシナリオにおいて、システム変数[`tidb_rc_write_check_ts`](/system-variables.md#tidb_rc_write_check_ts-new-in-v630)有効にすることでタイムスタンプ取得の最適化をサポートします。この変数を有効にすると、ポイント書き込みステートメントの実行中に、TiDBは現在のトランザクションの有効なタイムスタンプを使用してデータの読み取りとロックを試みます。3 [`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600)有効になっている場合も、TiDBは同様にデータを読み取ります。 +v6.3.0以降、TiDBはポイント書き込みの競合が少ないシナリオにおいて、システム変数[`tidb_rc_write_check_ts`](/system-variables.md#tidb_rc_write_check_ts-new-in-v630)有効にすることでタイムスタンプ取得の最適化をサポートします。この変数を有効にすると、ポイント書き込みステートメントの実行中に、TiDBは現在のトランザクションの有効なタイムスタンプを使用してデータの読み取りとロックを試みます。[`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600)が有効になっている場合も、TiDBは同様にデータを読み取ります。 現在、適用可能なポイント書き込みステートメントの種類は`UPDATE` 、 `DELETE` 、 `SELECT ...... FOR UPDATE`です。ポイント書き込みステートメントとは、主キーまたは一意キーをフィルター条件として使用し、最終実行演算子に`POINT-GET`含まれる書き込みステートメントを指します。現在、3種類のポイント書き込みステートメントに共通するのは、まずキー値に基づいてポイントクエリを実行することです。キーが存在する場合は、キーをロックします。キーが存在しない場合は、空のセットを返します。 diff --git a/transaction-overview.md b/transaction-overview.md index 4feb35adc3142..f60ca07e9b141 100644 --- a/transaction-overview.md +++ b/transaction-overview.md @@ -272,7 +272,7 @@ mysql> SELECT * FROM test; TiDBは楽観的トランザクションと悲観的トランザクションの両方をサポートしており、楽観的トランザクションは悲観的トランザクションの基盤となります。楽観的トランザクションはまず変更をプライベートメモリにキャッシュするため、TiDBは単一トランザクションのサイズを制限します。 -デフォルトでは、TiDB は単一トランザクションの合計サイズを 100 MB 以下に設定します。このデフォルト値は、設定ファイルで`txn-total-size-limit`設定することで変更できます。最大値は`txn-total-size-limit`で、1 TB です。個々のトランザクションのサイズ制限は、サーバーで使用可能なメモリの残り容量にも依存します。これは、トランザクションの実行時に、TiDB プロセスのメモリ使用量がトランザクションサイズと比較して、最大でトランザクションサイズの 2 ～ 3 倍以上にまで増加するためです。 +デフォルトでは、TiDB は単一トランザクションの合計サイズを 100 MB 以下に設定します。このデフォルト値は、設定ファイルで`txn-total-size-limit`を設定することで変更できます。 `txn-total-size-limit`の最大値は 1 TB です。個々のトランザクションのサイズ制限は、サーバーで使用可能なメモリの残り容量にも依存します。これは、トランザクションの実行時に、TiDB プロセスのメモリ使用量がトランザクションサイズと比較して、最大でトランザクションサイズの 2 ～ 3 倍以上にまで増加するためです。 TiDBでは以前、1トランザクションあたりのキーと値のペアの総数が300,000個に制限されていました。この制限はTiDB v4.0で削除されました。 diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index c28665f9290ce..a6c7d0b180e06 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -15,7 +15,7 @@ summary: 読み取りおよび書き込みのレイテンシーが長くなる #### 現象 {#phenomenon} -- スローログにクエリ実行プランが出力されている場合は、プランを直接確認できます。1 `select tidb_decode_plan('xxx...')`ステートメントを実行すると、詳細な実行プランを解析できます。 +- スローログにクエリ実行プランが出力されている場合は、プランを直接確認できます。`select tidb_decode_plan('xxx...')`ステートメントを実行すると、詳細な実行プランを解析できます。 - モニター内のスキャンされたキーの数が異常に増加し、スローログでは`Scan Keys`の数が多くなります。 - TiDBにおけるSQL実行時間は、MySQLなどの他のデータベースと比べて大きく異なります。他のデータベースの実行プランと比較することで、例えば`Join Order`異なるかどうかなどを確認できます。 @@ -27,7 +27,7 @@ summary: 読み取りおよび書き込みのレイテンシーが長くなる - 統計情報を更新する - `analyze table`手動で実行し、統計の正確性を維持するために、 `crontab`コマンドを使用して`analyze`定期的に実行します。 - - `auto analyze`自動的に実行します。3 `analyze ratio`しきい値を下げ、情報収集の頻度を上げ、実行の開始時刻と終了時刻を設定します。以下の例をご覧ください。 + - `auto analyze`自動的に実行します。`analyze ratio`しきい値を下げ、情報収集の頻度を上げ、実行の開始時刻と終了時刻を設定します。以下の例をご覧ください。 - `set global tidb_auto_analyze_ratio=0.2;` - `set global tidb_auto_analyze_start_time='00:00 +0800';` - `set global tidb_auto_analyze_end_time='06:00 +0800';` @@ -50,7 +50,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - サーバーの負荷が高いです。ログには`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 がLeaderを選出できません: PD ログには`lease is not expired`が表示されます。[この号](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`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。 @@ -78,7 +78,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - TiKVが再開されたため再選。 - TiKVがパニック状態になった後、 `systemd`引き上げられ、正常に動作します。panicが発生したかどうかは、TiKVのログを確認することで確認できます。この問題は予期せぬものであるため、発生した場合は[バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md) 。 - - TiKVは第三者によって停止または強制終了され、その後`systemd`によってプルアップされます。3 `dmesg` TiKVログを確認して原因を確認してください。 + - TiKVは第三者によって停止または強制終了され、その後`systemd`によってプルアップされます。`dmesg` TiKVログを確認して原因を確認してください。 - TiKV は OOM であり、再起動を引き起こします。 - `THP` (Transparent Hugepage) を動的に調整しているため、TiKV がハングします。 diff --git a/troubleshoot-high-disk-io.md b/troubleshoot-high-disk-io.md index a4807918253a8..ad8ddf8cdf4f4 100644 --- a/troubleshoot-high-disk-io.md +++ b/troubleshoot-high-disk-io.md @@ -30,7 +30,7 @@ TiDBクラスターのメインstorageコンポーネントはTiKVです。1つ **TiKV-Details** > **Raft IO**では、これら 2 つのインスタンスのディスク書き込みに関連するメトリックを確認できます。 -- `Append log duration` : このメトリックは、 Raftログを保存するRockDBへの書き込みの応答時間を示します。2 `.99`応答時間は50ミリ秒以内である必要があります。 +- `Append log duration` : このメトリックは、 Raftログを保存するRockDBへの書き込みの応答時間を示します。`.99`応答時間は50ミリ秒以内である必要があります。 - `Apply log duration` ：このメトリックは、実データを格納するRockDBへの書き込みの応答時間を示します。 `.99`時間は100ミリ秒以内である必要があります。 これら 2 つのメトリックには、書き込みホットスポットを表示するのに役立つ**サーバーごとの**監視パネルもあります。 @@ -55,7 +55,7 @@ TiDBクラスターのメインstorageコンポーネントはTiKVです。1つ - `apply log`は遅いです。TiKV Grafana の`Raft I/O`と`apply log duration`指標は比較的高く、これは通常、 `Raft Propose` / `apply wait duration`指標も比較的高い場合に発生します。考えられる原因は次のとおりです。 - - `[raftstore]`のうち`apply-pool-size`は小さすぎます。この値は`[1, 5]`から大きすぎない範囲に設定することをお勧めします。7と`Thread CPU` `apply cpu`比較的高い値です。 + - `[raftstore]`のうち`apply-pool-size`は小さすぎます。この値は`[1, 5]`の範囲で、大きすぎないように設定することをお勧めします。`Thread CPU`/`apply cpu`の値も比較的高くなっています。 - マシンの CPU リソースが不足しています。 - 単一リージョンの書き込みホットスポットの問題（現在、この問題の解決は進行中です）。単一スレッド`apply`のCPU使用率が高くなっています（Grafana式に`by (instance, name)`追加することで確認できます）。 - RocksDBへの書き込み速度が遅く、 `RocksDB kv` / `max write duration`高い値です。1つのRaftログには複数のキーと値のペア（kv）が含まれる場合があります。128 kvが一括でRocksDBに書き込まれるため、 `apply`ログ1つにつきRocksDBへの書き込みが複数回発生する可能性があります。 @@ -67,7 +67,7 @@ TiDBクラスターのメインstorageコンポーネントはTiKVです。1つ - クライアントが`server is busy`や特に`raftstore is busy`などのエラーを報告する場合、エラーは I/O の問題に関連している可能性があります。 - `busy`エラーの具体的な原因を確認するには、監視パネル（ **Grafana** -> **TiKV** -> **errors** ）を確認してください。9 `server is busy` TiKVのフロー制御メカニズムです。これにより、TiKVは`tidb/ti-client` 、現在のTiKVの負荷が高すぎるため、クライアントは後で再試行する必要があることを通知します。 + `busy`エラーの具体的な原因を確認するには、監視パネル（ **Grafana** -> **TiKV** -> **errors** ）を確認してください。`server is busy` TiKVのフロー制御メカニズムです。これにより、TiKVは`tidb/ti-client` 、現在のTiKVの負荷が高すぎるため、クライアントは後で再試行する必要があることを通知します。 - TiKV RocksDB ログに`Write stall`表示されます。 diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 3affeed9ad8ec..56f235a9c134d 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -41,7 +41,7 @@ TiDBは各テーブルにTableID、各インデックスにIndexID、各行にRo ### テーブルホットスポット {#table-hotspots} -TiDBのコーディングルールによれば、同一テーブルのデータはTableIDの先頭で始まる範囲に収められ、RowID値の順序で並べられます。テーブルへの挿入時にRowID値が増加する場合、挿入された行は末尾にのみ追加されます。Regionは一定のサイズに達すると分割されますが、その後も範囲の末尾にのみ追加できます。1 `INSERT`操作は1つのリージョンに対してのみ実行でき、ホットスポットを形成します。 +TiDBのコーディングルールによれば、同一テーブルのデータはTableIDの先頭で始まる範囲に収められ、RowID値の順序で並べられます。テーブルへの挿入時にRowID値が増加する場合、挿入された行は末尾にのみ追加されます。Regionは一定のサイズに達すると分割されますが、その後も範囲の末尾にのみ追加できます。`INSERT`操作は1つのリージョンに対してのみ実行でき、ホットスポットを形成します。 一般的なAUTO_INCREMENT主キーは、順次増加します。主キーが整数型の場合、デフォルトで主キーの値がRowIDとして使用されます。この場合、RowIDは順次増加し、 `INSERT`操作が多数発生すると、テーブルの書き込みホットスポットが発生します。 @@ -81,7 +81,7 @@ TiDBのコーディングルールによれば、同一テーブルのデータ ## SHARD_ROW_ID_BITSを使用してホットスポットを処理する {#use-code-shard-row-id-bits-code-to-process-hotspots} -非クラスター化主キーまたは主キーのないテーブルの場合、TiDBは暗黙的なAUTO_INCREMENT RowIDを使用します。1 `INSERT`操作が多数存在する場合、データは単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 +非クラスター化主キーまたは主キーのないテーブルの場合、TiDBは暗黙的なAUTO_INCREMENT RowIDを使用します。`INSERT`操作が多数存在する場合、データは単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)設定すると、行 ID が分散されて複数のリージョンに書き込まれるため、書き込みホットスポットの問題を軽減できます。 @@ -98,7 +98,7 @@ ALTER TABLE: ALTER TABLE t SHARD_ROW_ID_BITS = 4; `SHARD_ROW_ID_BITS`の値は動的に変更できます。変更された値は、新しく書き込まれたデータにのみ適用されます。 -`CLUSTERED`型の主キーを持つテーブルの場合、TiDBはテーブルの主キーをRowIDとして使用します。この場合、 `SHARD_ROW_ID_BITS`オプションはRowIDの生成ルールを変更するため使用できません。5 `NONCLUSTERED`の主キーを持つテーブルの場合、TiDBは自動的に割り当てられた64ビット整数をRowIDとして使用します。この場合、 `SHARD_ROW_ID_BITS` `CLUSTERED`が使用できます。9型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 +`CLUSTERED`型の主キーを持つテーブルの場合、TiDBはテーブルの主キーをRowIDとして使用します。この場合、 `SHARD_ROW_ID_BITS`オプションはRowIDの生成ルールを変更するため使用できません。`NONCLUSTERED`の主キーを持つテーブルの場合、TiDBは自動的に割り当てられた64ビット整数をRowIDとして使用します。この場合、 `SHARD_ROW_ID_BITS`機能が使用できます。`CLUSTERED`型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 以下の2つの負荷図は、主キーを持たない2つのテーブルで`SHARD_ROW_ID_BITS`使用してホットスポットを分散させた場合を示しています。最初の図はホットスポットを分散させる前の状況を示し、2番目の図はホットスポットを分散させた後の状況を示しています。 diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index fa02286050085..49ae5d4c684ca 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`テーブルに表示される情報は、クエリ実行時に実行中のトランザクションの情報でもあることに注意してください。これらのテーブルには、完了したトランザクションの情報は表示されません。同時実行トランザクションの数が多い場合、クエリの結果セットも大きくなる可能性があります。`limit`句または`where`句を使用すると、ロック待機時間が長いトランザクションをフィルタリングできます。Lock ビューで複数のテーブルを結合する場合、異なるテーブルのデータが同時に取得されない可能性があり、異なるテーブルの情報が一致しない可能性があることに注意してください。 たとえば、 `where`句を使用してロック待機時間が長いトランザクションをフィルタリングするには、次の SQL ステートメントを実行します。 diff --git a/troubleshoot-tidb-cluster.md b/troubleshoot-tidb-cluster.md index f4ebc1de34924..35583af34f413 100644 --- a/troubleshoot-tidb-cluster.md +++ b/troubleshoot-tidb-cluster.md @@ -26,7 +26,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 - すべてのプロセスが実行中の場合は、 `tidb-server`ログをチェックして、次のメッセージが表示されているかどうかを確認します。 - - 情報スキーマが古くなっています: `tikv-server`接続できない場合にこのメッセージが表示されます。3 と`pd-server` `tikv-server`状態とログを確認してください。 + - 情報スキーマが古くなっています: `tikv-server`接続できない場合にこのメッセージが表示されます。`pd-server`と`tikv-server`の状態とログを確認してください。 - panic：プログラムに問題が発生した場合、このメッセージが表示されます。詳細なpanicログをご提供いただければ、 [バグを報告する](/support.md) . 3. データがクリアされ、サービスが再デプロイされる場合は、次の点を確認してください。 diff --git a/troubleshoot-write-conflicts.md b/troubleshoot-write-conflicts.md index 41d0c8121021a..eeb5cf94a0937 100644 --- a/troubleshoot-write-conflicts.md +++ b/troubleshoot-write-conflicts.md @@ -11,7 +11,7 @@ TiDB v3.0.8より前のバージョンでは、TiDBはデフォルトで楽観 ## 書き込み競合の原因 {#the-reason-of-write-conflicts} -TiDBは[Percolator](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Peng.pdf)トランザクションモデルを用いてトランザクションを実装します。3 `percolator`一般的に2PCの実装です。2PCの詳細なプロセスについては[TiDB 楽観的トランザクションモデル](/optimistic-transaction.md)参照してください。 +TiDBは[Percolator](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Peng.pdf)トランザクションモデルを用いてトランザクションを実装します。`percolator`一般的に2PCの実装です。2PCの詳細なプロセスについては[TiDB 楽観的トランザクションモデル](/optimistic-transaction.md)を参照してください。 クライアントが TiDB に`COMMIT`リクエストを送信すると、TiDB は 2PC プロセスを開始します。 @@ -20,7 +20,7 @@ TiDBは[Percolator](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/ 3. TiDB は、 `prewrite`リクエストがすべて成功したという結果を受け取ります。 4. TiDB は PD から`commit_ts`を取得します。 5. TiDBは、トランザクションの主キーを含むTiKVリージョンに`commit`リクエストを送信します。TiKVは`commit`リクエストを受信すると、データの有効性を確認し、 `prewrite`番目のステージに残っているロックを解除します。 -6. `commit`回目のリクエストが正常に返されると、TiDB はクライアントに成功を返します。 +6. `commit`リクエストが正常に返されると、TiDB はクライアントに成功を返します。 書き込み競合はステージ`prewrite`で発生します。トランザクションが、別のトランザクションが現在のキー（ `data.commit_ts` > `txn.start_ts` ）に書き込みを行っていることを検出すると、書き込み競合が発生します。 @@ -59,10 +59,10 @@ TiDBログを検索するキーワードとして`[kv:9007]Write conflict`を使 上記のログの説明は次のとおりです。 - `[kv:9007]Write conflict` : 書き込み間の競合を示します。 -- `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`競合が発生しているインデックスの値を示します。 +- `txnStartTS=416617006551793665` : 現在のトランザクションの`start_ts`を示します。`pd-ctl`ツールを使用して、 `start_ts`を物理時間に変換できます。 +- `conflictStartTS=416617018650001409` : 書き込み競合トランザクションの`start_ts`を示します。 +- `conflictCommitTS=416617023093080065` : 書き込み競合トランザクションの`commit_ts`を示します。 +- `key={tableID=47, indexID=1, indexValues={string, }}` : 書き込み競合キーを示します。`tableID`は書き込み競合テーブルのIDを示します。`indexID`は書き込み競合インデックスのIDを示します。書き込み競合キーがレコードキーの場合、ログには競合が発生しているレコード（行）を示す`handle=x`が出力されます。`indexValues`は競合が発生しているインデックスの値を示します。 - `primary={tableID=47, indexID=1, indexValues={string, }}` : 現在のトランザクションの主キー情報を示します。 `pd-ctl`ツールを使用して、タイムスタンプを読み取り可能な時間に変換できます。 @@ -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 c1d76d1ca8d60..63bb90119cb44 100644 --- a/tune-operating-system.md +++ b/tune-operating-system.md @@ -99,7 +99,7 @@ echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler #### mountパラメータ {#code-mount-code-parameters} -`mount`コマンドで`noatime`オプションが有効になっている場合、ファイルの読み取り時にメタデータの更新が無効になります。5 `nodiratime`動作が有効になっている場合、ディレクトリの読み取り時にメタデータの更新が無効になります。 +`mount`コマンドで`noatime`オプションが有効になっている場合、ファイルの読み取り時にメタデータの更新が無効になります。`nodiratime`動作が有効になっている場合、ディレクトリの読み取り時にメタデータの更新が無効になります。 ### ネットワークチューニング {#network-tuning} diff --git a/tune-tikv-memory-performance.md b/tune-tikv-memory-performance.md index 663a40d6dd49e..cade589a40db5 100644 --- a/tune-tikv-memory-performance.md +++ b/tune-tikv-memory-performance.md @@ -25,7 +25,7 @@ TiKV 3.0以降では、デフォルトですべてのCFが1つのブロックキ TiKV 3.0 より前では、共有ブロックキャッシュはサポートされていないため、各 CF ごとにブロックキャッシュを個別に構成する必要があります。 -各 CF にはそれぞれ`write buffer`あります。3 パラメータ`write-buffer-size`設定することでサイズを設定できます。 +各 CF にはそれぞれ`write buffer`あります。`write-buffer-size`パラメータを設定することでサイズを設定できます。 ## パラメータ仕様 {#parameter-specification} diff --git a/tune-tikv-thread-performance.md b/tune-tikv-thread-performance.md index d02329a6ae874..3cef0218acbde 100644 --- a/tune-tikv-thread-performance.md +++ b/tune-tikv-thread-performance.md @@ -64,7 +64,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで - StoreWriterスレッドプールのサイズが0の場合、すべての書き込みリクエストはRaftstoreスレッドによって`fsync`としてRocksDBに書き込まれます。この場合、以下の方法でパフォーマンスをチューニングすることをお勧めします。 - - Raftstoreスレッド全体の CPU 使用率を 60% 未満に保ちます。RaftstoreRaftstore数が 2 の場合、Grafana 上の**TiKV-Details** 、 **Thread CPU** 、 **Raft store CPU を**120% 未満に保ちます。I/O リクエストにより、 Raftstoreスレッドの CPU 使用率は理論上は常に 100% 未満になります。 + - Raftstoreスレッド全体の CPU 使用率を 60% 未満に保ちます。Raftstoreスレッド数が 2 の場合、Grafana 上の**TiKV-Details** 、 **Thread CPU** 、 **Raft store CPU を**120% 未満に保ちます。I/O リクエストにより、 Raftstoreスレッドの CPU 使用率は理論上は常に 100% 未満になります。 - 書き込みパフォーマンスを向上させるために、 Raftstoreスレッド プールのサイズを慎重に検討せずに増やさないでください。そうすると、ディスクの負荷が増加し、パフォーマンスが低下する可能性があります。 - StoreWriterスレッドプールのサイズが0でない場合、すべての書き込みリクエストはStoreWriterスレッドによって`fsync`としてRocksDBに書き込まれます。この場合、以下の方法でパフォーマンスをチューニングすることをお勧めします。 diff --git a/upgrade-monitoring-services.md b/upgrade-monitoring-services.md index dc94287e06e33..2f4980044cfb5 100644 --- a/upgrade-monitoring-services.md +++ b/upgrade-monitoring-services.md @@ -45,7 +45,7 @@ TiDBとの互換性を高めるため、TiDBインストールパッケージに ### ステップ3. TiUPが使用できる新しいPrometheusパッケージを作成する {#step-3-create-a-new-prometheus-package-that-tiup-can-use} 1. [ステップ1](#step-1-download-a-new-prometheus-installation-package-from-the-prometheus-website)で抽出したファイルをコピーし、コピーしたファイルを使用して[ステップ2](#step-2-download-the-prometheus-installation-package-provided-by-tidb)で抽出した`./prometheus-v{version}-linux-amd64/prometheus`ディレクトリ内のファイルを置き換えます。 -2. `./prometheus-v{version}-linux-amd64`ディレクトリを再圧縮し、新しい圧縮パッケージに`prometheus-v{new-version}.tar.gz`という名前を付けます。5 `{new-version}`必要に応じて指定できます。 +2. `./prometheus-v{version}-linux-amd64`ディレクトリを再圧縮し、新しい圧縮パッケージに`prometheus-v{new-version}.tar.gz`という名前を付けます。`{new-version}`必要に応じて指定できます。 ```bash cd prometheus-v{version}-linux-amd64 @@ -92,7 +92,7 @@ TiDBとの互換性を高めるため、TiDBインストールパッケージに ### ステップ3. TiUPが使用できる新しいGrafanaパッケージを作成する {#step-3-create-a-new-grafana-package-that-tiup-can-use} 1. [ステップ1](#step-1-download-a-new-grafana-installation-package-from-the-grafana-website)で抽出したファイルをコピーし、コピーしたファイルを使用して[ステップ2](#step-2-download-the-grafana-installation-package-provided-by-tidb)で抽出した`./grafana-v{version}-linux-amd64/`ディレクトリ内のファイルを置き換えます。 -2. `./grafana-v{version}-linux-amd64`ディレクトリを再圧縮し、新しい圧縮パッケージに`grafana-v{new-version}.tar.gz`という名前を付けます。5 `{new-version}`必要に応じて指定できます。 +2. `./grafana-v{version}-linux-amd64`ディレクトリを再圧縮し、新しい圧縮パッケージに`grafana-v{new-version}.tar.gz`という名前を付けます。`{new-version}`必要に応じて指定できます。 ```bash cd grafana-v{version}-linux-amd64 diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index aedbcf6f2084a..e7b63373c4cb0 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -142,7 +142,7 @@ tiup update cluster tiup cluster edit-config ``` -2. フォーマットを参照[トポロジー](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)設定テンプレートを参照し、トポロジファイルの`server_configs`セクションに変更したいパラメータを入力します。 +2. [トポロジー](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)設定テンプレートのフォーマットを参照し、トポロジファイルの`server_configs`セクションに変更したいパラメータを入力します。 3. 変更後、 「: + w + q」と入力して変更を保存し、編集モードを終了します。変更を確定するには「Y」と入力してください。 diff --git a/user-account-management.md b/user-account-management.md index c58f68b70055a..2c774563d07bb 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -171,7 +171,7 @@ TiDBはパスワードを[`mysql.user`](/mysql-schema/mysql-schema-user.md)シ 1. tidb-server インスタンスの 1 つが配置されているマシンにログインします。 2. TiDB ノードのデプロイメント ディレクトリの下の`conf`ディレクトリに入り、 `tidb.toml`構成ファイルを見つけます。 - 3. 設定ファイルの[`security`](/tidb-configuration-file.md#security)セクションに設定項目[`skip-grant-table`](/tidb-configuration-file.md)追加します。5 `security`がない場合は、 `tidb.toml`設定ファイルの末尾に次の2行を追加します。 + 3. 設定ファイルの[`security`](/tidb-configuration-file.md#security)セクションに設定項目[`skip-grant-table`](/tidb-configuration-file.md)追加します。`security`がない場合は、 `tidb.toml`設定ファイルの末尾に次の2行を追加します。 [security] skip-grant-table = true diff --git a/wrong-index-solution.md b/wrong-index-solution.md index 65381573efae8..5cf475ac79209 100644 --- a/wrong-index-solution.md +++ b/wrong-index-solution.md @@ -21,7 +21,7 @@ summary: 間違ったインデックスの問題を解決する方法を学び ### 健康状態が低い {#low-health-state} -ヘルス状態が低いということは、TiDBが`ANALYZE`ステートメントを長期間実行していないことを意味します。3 `ANALYZE`コマンドを実行することで統計情報を更新できます。更新後もオプティマイザーが誤ったインデックスを使用している場合は、次のセクションを参照してください。 +ヘルス状態が低いということは、TiDBが`ANALYZE`ステートメントを長期間実行していないことを意味します。`ANALYZE`コマンドを実行することで統計情報を更新できます。更新後もオプティマイザーが誤ったインデックスを使用している場合は、次のセクションを参照してください。 ### ほぼ100%の健康状態 {#near-100-health-state}