From 14f4cf3b12fa9b6d8f86756fe590a55b2f333b5e Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 21 Jul 2026 18:05:38 +0900 Subject: [PATCH] i18n(ja): align heading anchors with the English source MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The translation pipeline rewrote heading anchors into its own scheme while the links kept pointing at the anchor the English heading produces, so those links resolve to nothing: EN : ### SET_VAR(VAR_NAME=VAR_VALUE) -> #set_varvar_namevar_value JA : ### SET_VAR(変数名=変数値) {#set-var-var-name-var-value} link : optimizer-hints.md#set_varvar_namevar_value -> dead Re-derive each anchor from the English heading and pin it on the Japanese heading. Heading text is untouched. Three ja-internal links that pointed at the old ja anchors are updated to match. 928 lines across 123 files. Unresolved anchor links drop from 581 to 3, none newly broken. Co-Authored-By: Claude Opus 4.8 (1M context) --- .../vector-search-auto-embedding-overview.md | 8 +- .../vector-search-functions-and-operators.md | 16 +- alert-rules.md | 166 +++++++++--------- auto-increment.md | 4 +- .../massive-regions-best-practices.md | 4 +- .../pd-scheduling-best-practices.md | 12 +- br/backup-and-restore-overview.md | 6 +- br/br-snapshot-guide.md | 2 +- br/br-snapshot-manual.md | 2 +- check-before-deployment.md | 2 +- command-line-flags-for-tidb-configuration.md | 74 ++++---- command-line-flags-for-tikv-configuration.md | 22 +-- configure-memory-usage.md | 4 +- configure-placement-rules.md | 2 +- constraints.md | 8 +- dashboard/dashboard-faq.md | 8 +- dashboard/top-sql.md | 4 +- data-type-date-and-time.md | 12 +- data-type-numeric.md | 20 +-- data-type-string.md | 28 +-- develop/dev-guide-bookshop-schema-design.md | 12 +- develop/dev-guide-connection-parameters.md | 2 +- .../dev-guide-hybrid-oltp-and-olap-queries.md | 4 +- .../dev-guide-optimize-sql-best-practices.md | 4 +- develop/dev-guide-update-data.md | 16 +- develop/java-app-best-practices.md | 4 +- dm/dm-compatibility-catalog.md | 2 +- dm/dm-error-handling.md | 18 +- dm/dm-faq.md | 44 ++--- dm/dm-safe-mode.md | 6 +- dm/maintain-dm-using-tiup.md | 4 +- dm/manually-upgrade-dm-1.0-to-2.0.md | 12 +- dm/shard-merge-best-practices.md | 4 +- enable-tls-between-components.md | 2 +- explain-indexes.md | 2 +- explain-subqueries.md | 6 +- faq/backup-and-restore-faq.md | 36 ++-- faq/deploy-and-maintain-faq.md | 16 +- faq/migration-tidb-faq.md | 8 +- faq/sql-faq.md | 24 +-- .../bit-functions-and-operators.md | 14 +- .../encryption-and-compression-functions.md | 10 +- .../information-functions.md | 16 +- .../json-functions-aggregate.md | 4 +- .../json-functions/json-functions-create.md | 6 +- .../json-functions/json-functions-modify.md | 22 +-- .../json-functions/json-functions-return.md | 8 +- .../json-functions/json-functions-search.md | 12 +- .../json-functions/json-functions-utility.md | 6 +- .../json-functions/json-functions-validate.md | 2 +- .../miscellaneous-functions.md | 26 +-- functions-and-operators/string-functions.md | 34 ++-- functions-and-operators/tidb-functions.md | 36 ++-- functions-and-operators/window-functions.md | 14 +- glossary.md | 48 ++--- grafana-tikv-dashboard.md | 14 +- identify-slow-queries.md | 12 +- index-advisor.md | 8 +- .../information-schema-data-lock-waits.md | 4 +- .../information-schema-deadlocks.md | 4 +- .../information-schema-processlist.md | 2 +- .../information-schema-slow-query.md | 4 +- .../information-schema-tidb-index-usage.md | 4 +- .../information-schema-tidb-trx.md | 4 +- latency-breakdown.md | 2 +- max-min-eliminate.md | 6 +- non-transactional-dml.md | 8 +- optimizer-hints.md | 100 +++++------ pd-control.md | 54 +++--- scale-tidb-using-tiup.md | 4 +- schedule-replicas-by-topology-labels.md | 10 +- security-compatibility-with-mysql.md | 2 +- sql-plan-replayer.md | 16 +- sql-prepared-plan-cache.md | 6 +- .../sql-statement-admin-bdr-role.md | 2 +- sql-statements/sql-statement-admin.md | 12 +- .../sql-statement-alter-table-compact.md | 2 +- .../sql-statement-create-sequence.md | 2 +- sql-statements/sql-statement-overview.md | 6 +- statement-summary-tables.md | 12 +- storage-engine/titan-overview.md | 2 +- sys-schema/sys-schema-unused-indexes.md | 4 +- ticdc/ticdc-ddl.md | 2 +- ticdc/ticdc-faq.md | 24 +-- ticdc/ticdc-server-config.md | 8 +- ticdc/ticdc-sink-to-kafka.md | 2 +- ticdc/ticdc-split-update-behavior.md | 18 +- ticdc/ticdc-upstream-downstream-check.md | 2 +- tidb-cloud/backup-and-restore-serverless.md | 2 +- tidb-cloud/branch-github-integration.md | 14 +- ...migrate-from-mysql-using-data-migration.md | 4 +- ...itor-prometheus-and-grafana-integration.md | 4 +- tidb-cloud/prometheus-grafana-integration.md | 4 +- .../terraform-migrate-cluster-resource.md | 2 +- tidb-cloud/terraform-use-cluster-resource.md | 6 +- tidb-cloud/tidb-cloud-clinic.md | 2 +- .../tidb-cloud-org-sso-authentication.md | 2 +- tidb-cloud/use-chat2query-api.md | 6 +- tidb-configuration-file.md | 38 ++-- tidb-control.md | 16 +- tidb-lightning/tidb-lightning-checkpoints.md | 8 +- .../tidb-lightning-configuration.md | 18 +- tidb-lightning/tidb-lightning-faq.md | 4 +- ...db-lightning-physical-import-mode-usage.md | 4 +- tidb-lightning/troubleshoot-tidb-lightning.md | 16 +- tidb-resource-control-background-tasks.md | 2 +- tidb-resource-control-runaway-queries.md | 4 +- tidb-troubleshooting-map.md | 52 +++--- tiflash/tiflash-command-line-flags.md | 2 +- tiflash/tiflash-configuration.md | 138 +++++++-------- tiflash/tune-tiflash-performance.md | 8 +- tikv-configuration-file.md | 112 ++++++------ tikv-control.md | 4 +- tiup/tiup-cluster-topology-reference.md | 28 +-- tiup/tiup-component-cluster-reload.md | 18 +- tiup/tiup-component-cluster-upgrade.md | 38 ++-- tiup/tiup-component-cluster.md | 12 +- tiup/tiup-dm-topology-reference.md | 12 +- troubleshoot-hot-spot-issues.md | 4 +- tune-operating-system.md | 16 +- tune-region-performance.md | 4 +- upgrade-tidb-using-tiup.md | 2 +- user-account-management.md | 2 +- 123 files changed, 929 insertions(+), 929 deletions(-) diff --git a/ai/integrations/vector-search-auto-embedding-overview.md b/ai/integrations/vector-search-auto-embedding-overview.md index a1a6467dc8dde..2df2ee6611cf9 100644 --- a/ai/integrations/vector-search-auto-embedding-overview.md +++ b/ai/integrations/vector-search-auto-embedding-overview.md @@ -67,7 +67,7 @@ LIMIT 3; 前述の例では、Amazon Titan モデルを使用しています。その他のモデルについては、[利用可能なテキスト埋め込みモデル](#available-text-embedding-models)を参照してください。 -## 自動埋め込み + ベクトルインデックス {#auto-embedding-vector-index} +## 自動埋め込み + ベクトルインデックス {#auto-embedding--vector-index} 自動埋め込みはクエリのパフォーマンスを向上させるための[ベクトルインデックス](/ai/reference/vector-search-index.md)と互換性があります。生成されたベクトル列にベクトル インデックスを定義でき、それは自動的に使用されます。 @@ -135,7 +135,7 @@ TiDB Cloudがサポートする以下の推論サービスを通じて、オー ## 主要関数 {#key-functions} -### `EMBED_TEXT()` {#embed-text} +### `EMBED_TEXT()` {#embed_text} テキストをベクトル埋め込みに変換します。 @@ -145,7 +145,7 @@ EMBED_TEXT("model_name", text_content[, additional_json_options]) `GENERATED ALWAYS AS`句でこの関数を使用すると、テキストデータの挿入または更新時に埋め込みを自動的に生成できます。 -### `VEC_EMBED_COSINE_DISTANCE()` {#vec-embed-cosine-distance} +### `VEC_EMBED_COSINE_DISTANCE()` {#vec_embed_cosine_distance} ベクトル列に格納されているベクトルとテキストクエリ間のコサイン類似度を計算します。 @@ -155,7 +155,7 @@ VEC_EMBED_COSINE_DISTANCE(vector_column, "query_text") `ORDER BY`句でこの関数を使用すると、コサイン距離に基づいて結果をランク付けできます。[`VEC_COSINE_DISTANCE()`](/ai/reference/vector-search-functions-and-operators.md#vec_cosine_distance)と同じ計算方法を使用しますが、クエリテキストの埋め込みを自動的に生成します。 -### `VEC_EMBED_L2_DISTANCE()` {#vec-embed-l2-distance} +### `VEC_EMBED_L2_DISTANCE()` {#vec_embed_l2_distance} 保存されたベクトルとテキストクエリ間のL2（ユークリッド）距離を計算します。 diff --git a/ai/reference/vector-search-functions-and-operators.md b/ai/reference/vector-search-functions-and-operators.md index ad655f1329feb..8e9d0a0890c28 100644 --- a/ai/reference/vector-search-functions-and-operators.md +++ b/ai/reference/vector-search-functions-and-operators.md @@ -100,7 +100,7 @@ aliases: ['/ja/tidb/stable/vector-search-functions-and-operators/','/ja/tidbclou ## 完全な参考文献 {#full-references} -### VEC_L2_距離 {#vec-l2-distance} +### VEC_L2_距離 {#vec_l2_distance} ```sql VEC_L2_DISTANCE(vector1, vector2) @@ -124,7 +124,7 @@ SELECT VEC_L2_DISTANCE('[0, 3]', '[4, 0]'); | 5 | +-------------------------------------+ -### VEC_COSINE_DISTANCE {#vec-cosine-distance} +### VEC_COSINE_DISTANCE {#vec_cosine_distance} ```sql VEC_COSINE_DISTANCE(vector1, vector2) @@ -150,7 +150,7 @@ SELECT VEC_COSINE_DISTANCE('[1, 1]', '[-1, -1]'); | 2 | +-------------------------------------------+ -### VEC_負の内部積 {#vec-negative-inner-product} +### VEC_負の内部積 {#vec_negative_inner_product} ```sql VEC_NEGATIVE_INNER_PRODUCT(vector1, vector2) @@ -174,7 +174,7 @@ SELECT VEC_NEGATIVE_INNER_PRODUCT('[1, 2]', '[3, 4]'); | -11 | +------------------------------------------------+ -### VEC_L1_距離 {#vec-l1-distance} +### VEC_L1_距離 {#vec_l1_distance} ```sql VEC_L1_DISTANCE(vector1, vector2) @@ -198,7 +198,7 @@ SELECT VEC_L1_DISTANCE('[0, 0]', '[3, 4]'); | 7 | +-------------------------------------+ -### VEC_DIMS {#vec-dims} +### VEC_DIMS {#vec_dims} ```sql VEC_DIMS(vector) @@ -228,7 +228,7 @@ SELECT VEC_DIMS('[]'); | 0 | +----------------+ -### VEC_L2_NORM {#vec-l2-norm} +### VEC_L2_NORM {#vec_l2_norm} ```sql VEC_L2_NORM(vector) @@ -250,7 +250,7 @@ SELECT VEC_L2_NORM('[3, 4]'); | 5 | +-----------------------+ -### VEC_FROM_TEXT {#vec-from-text} +### VEC_FROM_TEXT {#vec_from_text} ```sql VEC_FROM_TEXT(string) @@ -270,7 +270,7 @@ SELECT VEC_FROM_TEXT('[1, 2]') + VEC_FROM_TEXT('[3, 4]'); | [4,6] | +-------------------------------------------------+ -### VEC_AS_TEXT {#vec-as-text} +### VEC_AS_TEXT {#vec_as_text} ```sql VEC_AS_TEXT(vector) diff --git a/alert-rules.md b/alert-rules.md index 3b736b346f521..57a99851a3eed 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -21,9 +21,9 @@ summary: TiDB クラスターのアラート ルールについて学習しま このセクションでは、TiDBコンポーネントのアラート ルールについて説明します。 -### 緊急レベルの警報 {#emergency-level-alerts} +### 緊急レベルの警報 {#emergency-level-alerts-1} -#### `TiDB_schema_error` {#tidb-schema-error} +#### `TiDB_schema_error` {#tidb_schema_error} - アラートルール: @@ -37,7 +37,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま これは、利用できないリージョンやTiKVのタイムアウトが原因であることが多いです。TiKVの監視項目を確認して問題を特定する必要があります。 -#### `TiDB_tikvclient_region_err_total` {#tidb-tikvclient-region-err-total} +#### `TiDB_tikvclient_region_err_total` {#tidb_tikvclient_region_err_total} - アラートルール: @@ -51,7 +51,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま リーダーのバランスが取れているかどうかを確認するには、[**TiKV詳細**>**クラスタ**ダッシュボード](/grafana-tikv-dashboard.md#cluster)を確認する。 -#### `TiDB_domain_load_schema_total` {#tidb-domain-load-schema-total} +#### `TiDB_domain_load_schema_total` {#tidb_domain_load_schema_total} - アラートルール: @@ -65,9 +65,9 @@ summary: TiDB クラスターのアラート ルールについて学習しま [`TiDB_schema_error`](#tidb_schema_error)と同じです。 -### 重大レベルのアラート {#critical-level-alerts} +### 重大レベルのアラート {#critical-level-alerts-1} -#### `TiDB_server_panic_total` {#tidb-server-panic-total} +#### `TiDB_server_panic_total` {#tidb_server_panic_total} - アラートルール: @@ -81,9 +81,9 @@ summary: TiDB クラスターのアラート ルールについて学習しま panicログを収集して問題を特定します。 -### 警告レベルのアラート {#warning-level-alerts} +### 警告レベルのアラート {#warning-level-alerts-1} -#### `TiDB_memory_abnormal` {#tidb-memory-abnormal} +#### `TiDB_memory_abnormal` {#tidb_memory_abnormal} - アラートルール: @@ -97,7 +97,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま HTTP API を使用して、goroutine リークの問題をトラブルシューティングします。 -#### `TiDB_query_duration` {#tidb-query-duration} +#### `TiDB_query_duration` {#tidb_query_duration} - アラートルール: @@ -111,7 +111,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま TiDB ログを確認し、キーワード`SLOW_QUERY`と`TIME_COP_PROCESS`を検索して、遅い SQL クエリを見つけます。 -#### `TiDB_server_event_error` {#tidb-server-event-error} +#### `TiDB_server_event_error` {#tidb_server_event_error} - アラートルール: @@ -128,7 +128,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま サービスを回復するには、TiDB を再起動します。 -#### `TiDB_tikvclient_backoff_seconds_count` {#tidb-tikvclient-backoff-seconds-count} +#### `TiDB_tikvclient_backoff_seconds_count` {#tidb_tikvclient_backoff_seconds_count} - アラートルール: @@ -142,7 +142,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま TiKV の監視ステータスを確認する。 -#### `TiDB_monitor_time_jump_back_error` {#tidb-monitor-time-jump-back-error} +#### `TiDB_monitor_time_jump_back_error` {#tidb_monitor_time_jump_back_error} - アラートルール: @@ -156,7 +156,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま NTP 構成のトラブルシューティングを行います。 -#### `TiDB_ddl_waiting_jobs` {#tidb-ddl-waiting-jobs} +#### `TiDB_ddl_waiting_jobs` {#tidb_ddl_waiting_jobs} - アラートルール: @@ -174,9 +174,9 @@ summary: TiDB クラスターのアラート ルールについて学習しま このセクションでは、PDコンポーネントのアラート ルールについて説明します。 -### 緊急レベルの警報 {#emergency-level-alerts} +### 緊急レベルの警報 {#emergency-level-alerts-2} -#### `PD_cluster_down_store_nums` {#pd-cluster-down-store-nums} +#### `PD_cluster_down_store_nums` {#pd_cluster_down_store_nums} - アラートルール: @@ -191,9 +191,9 @@ summary: TiDB クラスターのアラート ルールについて学習しま - TiKV/ TiFlashプロセスが正常かどうか、ネットワークが分離されているか、負荷が高すぎるかどうかを確認し、可能な限りサービスを回復します。 - TiKV/ TiFlashインスタンスを回復できない場合は、オフラインにすることができます。 -### 重大レベルのアラート {#critical-level-alerts} +### 重大レベルのアラート {#critical-level-alerts-2} -#### `PD_etcd_write_disk_latency` {#pd-etcd-write-disk-latency} +#### `PD_etcd_write_disk_latency` {#pd_etcd_write_disk_latency} - アラートルール: @@ -209,7 +209,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - サービスを回復するには、PD を再起動するか、リーダーを手動で別の PD に転送してください。 - 環境要因により問題のある PD インスタンスを回復できない場合は、オフラインにして交換してください。 -#### `PD_miss_peer_region_count` {#pd-miss-peer-region-count} +#### `PD_miss_peer_region_count` {#pd_miss_peer_region_count} - アラートルール: @@ -224,9 +224,9 @@ summary: TiDB クラスターのアラート ルールについて学習しま - ダウンしている、またはオフラインになっている TiKV マシンがあるかどうかを確認して、問題の原因を見つけます。 - リージョンのヘルスパネルを監視し、 `miss-peer-region-count`継続的に減少しているかどうかを確認します。 -### 警告レベルのアラート {#warning-level-alerts} +### 警告レベルのアラート {#warning-level-alerts-2} -#### `PD_cluster_lost_connect_store_nums` {#pd-cluster-lost-connect-store-nums} +#### `PD_cluster_lost_connect_store_nums` {#pd_cluster_lost_connect_store_nums} - アラートルール: @@ -243,7 +243,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - TiKV/ TiFlashインスタンスが回復できないことが確認できた場合は、オフラインにすることができます。 - TiKV/ TiFlashインスタンスが回復可能であることが確認できたものの、短期間で回復できない場合は、 `max-down-time`の値を増やすことを検討してください。これにより、TiKV/ TiFlashインスタンスが回復不能と判断され、TiKV/ TiFlashからデータが削除されるのを防ぐことができます。 -#### `PD_cluster_unhealthy_tikv_nums` {#pd-cluster-unhealthy-tikv-nums} +#### `PD_cluster_unhealthy_tikv_nums` {#pd_cluster_unhealthy_tikv_nums} - アラートルール: @@ -257,7 +257,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま TiKV ストアの状態を確認します。 -#### `PD_cluster_low_space` {#pd-cluster-low-space} +#### `PD_cluster_low_space` {#pd_cluster_low_space} - アラートルール: @@ -275,7 +275,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - データ量を削減するには、ノードのリージョン重みを下げます。 - スペースを解放できない場合は、事前にノードをオフラインにすることを検討してください。これにより、ディスク容量不足によるダウンタイムの発生を防止できます。 -#### `PD_etcd_network_peer_latency` {#pd-etcd-network-peer-latency} +#### `PD_etcd_network_peer_latency` {#pd_etcd_network_peer_latency} - アラートルール: @@ -290,7 +290,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - ネットワークとシステムの負荷状態を確認します。 - 環境要因により問題のある PD インスタンスを回復できない場合は、オフラインにして交換してください。 -#### `PD_tidb_handle_requests_duration` {#pd-tidb-handle-requests-duration} +#### `PD_tidb_handle_requests_duration` {#pd_tidb_handle_requests_duration} - アラートルール: @@ -307,7 +307,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - PD リーダーを手動で切り替えます。 - 環境要因により問題のある PD インスタンスを回復できない場合は、オフラインにして交換してください。 -#### `PD_down_peer_region_nums` {#pd-down-peer-region-nums} +#### `PD_down_peer_region_nums` {#pd_down_peer_region_nums} - アラートルール: @@ -323,7 +323,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - リージョンのヘルスパネルを監視し、 `down_peer_region_count`継続的に減少しているかどうかを確認します。 - TiKV サーバー間のネットワークを確認します。 -#### `PD_pending_peer_region_count` {#pd-pending-peer-region-count} +#### `PD_pending_peer_region_count` {#pd_pending_peer_region_count} - アラートルール: @@ -338,7 +338,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - リージョンのヘルスパネルを監視し、 `pending_peer_region_count`継続的に減少しているかどうかを確認します。 - TiKV サーバー間のネットワーク、特に十分な帯域幅があるかどうかを確認します。 -#### `PD_leader_change` {#pd-leader-change} +#### `PD_leader_change` {#pd_leader_change} - アラートルール: @@ -354,7 +354,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - ネットワークとシステムの負荷状態を確認します。 - 環境要因により問題のある PD インスタンスを回復できない場合は、オフラインにして交換してください。 -#### `TiKV_space_used_more_than_80%` {#tikv-space-used-more-than-80} +#### `TiKV_space_used_more_than_80%` {#tikv_space_used_more_than_80} - アラートルール: @@ -369,7 +369,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 容量を増やす必要があるかどうかを確認します。 - ログ、スナップショット、コアダンプなど、大量のディスク領域を占有するファイルがあるかどうかを確認します。 -#### `PD_system_time_slow` {#pd-system-time-slow} +#### `PD_system_time_slow` {#pd_system_time_slow} - アラートルール: @@ -383,7 +383,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま システム時刻が正しく設定されているかどうかを確認します。 -#### `PD_no_store_for_making_replica` {#pd-no-store-for-making-replica} +#### `PD_no_store_for_making_replica` {#pd_no_store_for_making_replica} - アラートルール: @@ -398,7 +398,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 店内に十分なスペースがあるかどうかを確認します。 - ラベル構成が設定されている場合は、それに従って追加のレプリカ用のストアがあるかどうかを確認します。 -#### `PD_cluster_slow_tikv_nums` {#pd-cluster-slow-tikv-nums} +#### `PD_cluster_slow_tikv_nums` {#pd_cluster_slow_tikv_nums} - アラートルール: @@ -419,9 +419,9 @@ summary: TiDB クラスターのアラート ルールについて学習しま このセクションでは、TiKVコンポーネントのアラート ルールについて説明します。 -### 緊急レベルの警報 {#emergency-level-alerts} +### 緊急レベルの警報 {#emergency-level-alerts-3} -#### `TiKV_memory_used_too_fast` {#tikv-memory-used-too-fast} +#### `TiKV_memory_used_too_fast` {#tikv_memory_used_too_fast} - アラートルール: @@ -435,7 +435,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま `rocksdb.defaultcf`と`rocksdb.writecf`両方の`block-cache-size`値を調整します。 -#### `TiKV_GC_can_not_work` {#tikv-gc-can-not-work} +#### `TiKV_GC_can_not_work` {#tikv_gc_can_not_work} - アラートルール: @@ -451,9 +451,9 @@ summary: TiDB クラスターのアラート ルールについて学習しま 2. `tidb-server`のログを確認し、`grep gc_worker tidb.log` を実行します。 3. この時間中にGCワーカーがロックを解決中（最後のログは「start resolve locks」）または範囲を削除中（最後のログは「start delete {number} ranges」）であることが確認された場合、GCプロセスは正常に動作していることを意味します。それ以外の場合は、PingCAPまたはコミュニティから[サポートを受ける](/support.md)取得してください。 -### 重大レベルのアラート {#critical-level-alerts} +### 重大レベルのアラート {#critical-level-alerts-3} -#### `TiKV_server_report_failure_msg_total` {#tikv-server-report-failure-msg-total} +#### `TiKV_server_report_failure_msg_total` {#tikv_server_report_failure_msg_total} - アラートルール: @@ -469,7 +469,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 2. リモート TiKV がダウンしていないかどうかを確認します。 3. リモートTiKVがダウンしていない場合は、圧力が高すぎないか確認してください。1の解決策を参照してください[`TiKV_channel_full_total`](#tikv_channel_full_total) -#### `TiKV_channel_full_total` {#tikv-channel-full-total} +#### `TiKV_channel_full_total` {#tikv_channel_full_total} - アラートルール: @@ -485,7 +485,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 2. [**TiKV-詳細**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 3. [**TiKV詳細**>**Raftプロセス**ダッシュボード](/grafana-tikv-dashboard.md#raft-process)見て、 `tick duration`ハイかどうかを確認してください。ハイなら、 [`raftstore.raft-base-tick-interval`](/tikv-configuration-file.md#raft-base-tick-interval) `"2s"`に設定する必要があります。 -#### `TiKV_write_stall` {#tikv-write-stall} +#### `TiKV_write_stall` {#tikv_write_stall} - アラートルール: @@ -501,7 +501,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 2. TiKV に書き込みホットスポットがあるかどうかを確認します。 3. `[rocksdb]`および`[raftdb]`構成では、 `max-sub-compactions`より大きな値に設定します。 -#### `TiKV_raft_log_lag` {#tikv-raft-log-lag} +#### `TiKV_raft_log_lag` {#tikv_raft_log_lag} - アラートルール: @@ -511,7 +511,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま この値が比較的大きい場合、FollowerがLeaderから大きく遅れており、 Raftが正常に複製できないことを意味します。Followerが配置されているTiKVマシンがスタックまたはダウンしている可能性があります。 -#### `TiKV_async_request_snapshot_duration_seconds` {#tikv-async-request-snapshot-duration-seconds} +#### `TiKV_async_request_snapshot_duration_seconds` {#tikv_async_request_snapshot_duration_seconds} - アラートルール: @@ -525,7 +525,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま [`TiKV_channel_full_total`](#tikv_channel_full_total)の解決策を参照してください。 -#### `TiKV_async_request_write_duration_seconds` {#tikv-async-request-write-duration-seconds} +#### `TiKV_async_request_write_duration_seconds` {#tikv_async_request_write_duration_seconds} - アラートルール: @@ -541,7 +541,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 2. [**TiKV詳細**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 3. アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#storage-async-write-duration-store-duration-and-apply-duration)参照してください。 -#### `TiKV_coprocessor_request_wait_seconds` {#tikv-coprocessor-request-wait-seconds} +#### `TiKV_coprocessor_request_wait_seconds` {#tikv_coprocessor_request_wait_seconds} - アラートルール: @@ -557,7 +557,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 2. ホットスポットがあるかどうかを確認します。 3. コプロセッサーモニターで、 `coprocessor table/index scan`の`total`と`process`一致しているかどうかを確認してください。大きく異なる場合は、無効なクエリが多すぎることを示しています。7 `over seek bound`あるかどうかも確認できます。もしそうであれば、GC が時間内に処理できないバージョンが多すぎます。その場合は、並列 GC スレッドの数を増やす必要があります。 -#### `TiKV_raftstore_thread_cpu_seconds_total` {#tikv-raftstore-thread-cpu-seconds-total} +#### `TiKV_raftstore_thread_cpu_seconds_total` {#tikv_raftstore_thread_cpu_seconds_total} - アラートルール: @@ -573,7 +573,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま [`TiKV_channel_full_total`](#tikv_channel_full_total)の解決策を参照してください。 -#### `TiKV_raft_append_log_duration_secs` {#tikv-raft-append-log-duration-secs} +#### `TiKV_raft_append_log_duration_secs` {#tikv_raft_append_log_duration_secs} - アラートルール: @@ -583,7 +583,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま Raftログの追加にかかる時間コストを示します。この値が高い場合は、通常、I/Oが混雑していることを意味します。 -#### `TiKV_raft_apply_log_duration_secs` {#tikv-raft-apply-log-duration-secs} +#### `TiKV_raft_apply_log_duration_secs` {#tikv_raft_apply_log_duration_secs} - アラートルール: @@ -593,7 +593,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま Raftログの適用にかかる時間コストを示します。この値が高い場合は、通常、I/Oが混雑していることを意味します。 -#### `TiKV_scheduler_latch_wait_duration_seconds` {#tikv-scheduler-latch-wait-duration-seconds} +#### `TiKV_scheduler_latch_wait_duration_seconds` {#tikv_scheduler_latch_wait_duration_seconds} - アラートルール: @@ -609,7 +609,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 2. `Scheduler`と`Scheduler-${cmd}`モニターのスケジューラ スキャンの詳細で`total`と`process`値を確認し、 `total`と`process`一致するかどうかを確認します。 3. ストレージ モニターでストレージの非同期スナップショット/書き込み期間を確認し、 Raft操作が時間どおりに実行されているかどうかを確認します。 -#### `TiKV_thread_apply_worker_cpu_seconds` {#tikv-thread-apply-worker-cpu-seconds} +#### `TiKV_thread_apply_worker_cpu_seconds` {#tikv_thread_apply_worker_cpu_seconds} - アラートルール: @@ -619,9 +619,9 @@ summary: TiDB クラスターのアラート ルールについて学習しま Raftログ適用スレッドに大きな負荷がかかっており、限界に近づいているか、すでに限界を超えています。これは多くの場合、書き込みの集中によって発生します。 -### 警告レベルのアラート {#warning-level-alerts} +### 警告レベルのアラート {#warning-level-alerts-3} -#### `TiKV_leader_drops` {#tikv-leader-drops} +#### `TiKV_leader_drops` {#tikv_leader_drops} - アラートルール: @@ -636,7 +636,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. [`TiKV_channel_full_total`](#tikv_channel_full_total)を参照してください。 2. TiKVの負荷が低い場合は、PDスケジュールの頻度が高すぎないか検討してください。PDページのオペレータ作成パネルで、PDスケジュールの種類と数を確認できます。 -#### `TiKV_raft_process_ready_duration_secs` {#tikv-raft-process-ready-duration-secs} +#### `TiKV_raft_process_ready_duration_secs` {#tikv_raft_process_ready_duration_secs} - アラートルール: @@ -646,7 +646,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま Raft準備完了の処理にかかる時間コストを示します。この値が大きい場合、ログ追加タスクのスタックが原因であることが多いです。 -#### `TiKV_raft_process_tick_duration_secs` {#tikv-raft-process-tick-duration-secs} +#### `TiKV_raft_process_tick_duration_secs` {#tikv_raft_process_tick_duration_secs} - アラートルール: @@ -661,7 +661,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. `warn`や`error`などの上位レベルのログの使用を検討してください。 2. `[raftstore]`構成の下に`raft-base-tick-interval = "2s"`追加します。 -#### `TiKV_scheduler_context_total` {#tikv-scheduler-context-total} +#### `TiKV_scheduler_context_total` {#tikv_scheduler_context_total} - アラートルール: @@ -675,7 +675,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま [`TiKV_scheduler_latch_wait_duration_seconds`](#tikv_scheduler_latch_wait_duration_seconds)を参照してください。 -#### `TiKV_scheduler_command_duration_seconds` {#tikv-scheduler-command-duration-seconds} +#### `TiKV_scheduler_command_duration_seconds` {#tikv_scheduler_command_duration_seconds} - アラートルール: @@ -689,7 +689,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま [`TiKV_scheduler_latch_wait_duration_seconds`](#tikv_scheduler_latch_wait_duration_seconds)を参照してください。 -#### `TiKV_coprocessor_outdated_request_wait_seconds` {#tikv-coprocessor-outdated-request-wait-seconds} +#### `TiKV_coprocessor_outdated_request_wait_seconds` {#tikv_coprocessor_outdated_request_wait_seconds} - アラートルール: @@ -703,7 +703,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま [`TiKV_coprocessor_request_wait_seconds`](#tikv_coprocessor_request_wait_seconds)を参照してください。 -#### `TiKV_coprocessor_pending_request` {#tikv-coprocessor-pending-request} +#### `TiKV_coprocessor_pending_request` {#tikv_coprocessor_pending_request} - アラートルール: @@ -717,7 +717,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま [`TiKV_coprocessor_request_wait_seconds`](#tikv_coprocessor_request_wait_seconds)を参照してください。 -#### `TiKV_batch_request_snapshot_nums` {#tikv-batch-request-snapshot-nums} +#### `TiKV_batch_request_snapshot_nums` {#tikv_batch_request_snapshot_nums} - アラートルール: @@ -727,7 +727,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま TiKV マシンのコプロセッサーCPU 使用率が 90% を超えています。 -#### `TiKV_pending_task` {#tikv-pending-task} +#### `TiKV_pending_task` {#tikv_pending_task} - アラートルール: @@ -741,7 +741,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま [**TiKV詳細**>**タスク**ダッシュボード](/grafana-tikv-dashboard.md#task)のうち`Worker pending tasks`メトリックから、どの種類のタスクの値が高いかを確認します。 -#### `TiKV_low_space` {#tikv-low-space} +#### `TiKV_low_space` {#tikv_low_space} - アラートルール: @@ -756,7 +756,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - ノードスペースのバランス状態を確認します。 - さまざまな状況に応じて、ディスク容量を増やすか、一部のデータを削除するか、クラスター ノードを増やす計画を立てます。 -#### `TiKV_approximate_region_size` {#tikv-approximate-region-size} +#### `TiKV_approximate_region_size` {#tikv_approximate_region_size} - アラートルール: @@ -778,13 +778,13 @@ TiFlashアラート ルールの詳細な説明については、 [TiFlashアラ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラートルール](/ticdc/ticdc-alert-rules.md)参照してください。 -## Node_exporterホストアラートルール {#node-exporter-host-alert-rules} +## Node_exporterホストアラートルール {#node_exporter-host-alert-rules} このセクションでは、Node_exporter ホストのアラート ルールについて説明します。 -### 緊急レベルの警報 {#emergency-level-alerts} +### 緊急レベルの警報 {#emergency-level-alerts-4} -#### `NODE_disk_used_more_than_80%` {#node-disk-used-more-than-80} +#### `NODE_disk_used_more_than_80%` {#node_disk_used_more_than_80} - アラートルール: @@ -799,7 +799,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - マシンにログインし、コマンド`df -h`を実行してディスク領域の使用量を確認します。 - さまざまな状況に応じて、ディスク容量を増やすか、一部のデータを削除するか、クラスター ノードを増やす計画を立てます。 -#### `NODE_disk_inode_more_than_80%` {#node-disk-inode-more-than-80} +#### `NODE_disk_inode_more_than_80%` {#node_disk_inode_more_than_80} - アラートルール: @@ -814,7 +814,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - マシンにログインし、 `df -i`コマンドを実行してファイルシステムのノード使用状況を表示します。 - さまざまな状況に応じて、ディスク容量を増やすか、一部のデータを削除するか、クラスター ノードを増やす計画を立てます。 -#### `NODE_disk_readonly` {#node-disk-readonly} +#### `NODE_disk_readonly` {#node_disk_readonly} - アラートルール: @@ -831,7 +831,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー ### 重大レベルのアラート {#critical-level-alerts} -#### `NODE_memory_used_more_than_80%` {#node-memory-used-more-than-80} +#### `NODE_memory_used_more_than_80%` {#node_memory_used_more_than_80} - アラートルール: @@ -846,9 +846,9 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - Grafana Node Exporter ダッシュボードでホストのメモリ パネルを確認し、使用済みメモリが多すぎるかどうか、使用可能なメモリが少なすぎるかどうかを確認します。 - マシンにログインし、コマンド`free -m`を実行してメモリ使用量を確認します。コマンド`top`実行すると、メモリ使用量が過度に高い異常なプロセスがあるかどうかを確認できます。 -### 警告レベルのアラート {#warning-level-alerts} +### 警告レベルのアラート {#warning-level-alerts-4} -#### `NODE_node_overload` {#node-node-overload} +#### `NODE_node_overload` {#node_node_overload} - アラートルール: @@ -863,7 +863,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - マシンにログインして`top`実行し、負荷平均と CPU 使用率をチェックして、CPU 使用率が過度に高い異常なプロセスがないか確認します。 -#### `NODE_cpu_used_more_than_80%` {#node-cpu-used-more-than-80} +#### `NODE_cpu_used_more_than_80%` {#node_cpu_used_more_than_80} - アラートルール: @@ -878,7 +878,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - マシンにログインして`top`実行し、負荷平均と CPU 使用率をチェックして、CPU 使用率が過度に高い異常なプロセスがあるかどうかを確認します。 -#### `NODE_tcp_estab_num_more_than_50000` {#node-tcp-estab-num-more-than-50000} +#### `NODE_tcp_estab_num_more_than_50000` {#node_tcp_estab_num_more_than_50000} - アラートルール: @@ -893,7 +893,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - マシンにログインし、 `ss -s`実行して、現在のシステムで「estab」ステータスにある TCP リンクの数を確認します。 - `netstat`実行して異常なリンクがないか確認します。 -#### `NODE_disk_read_latency_more_than_32ms` {#node-disk-read-latency-more-than-32ms} +#### `NODE_disk_read_latency_more_than_32ms` {#node_disk_read_latency_more_than_32ms} - アラートルール: @@ -909,7 +909,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - ディスク レイテンシ パネルを表示して、ディスクの読み取りレイテンシーを確認します。 - ディスク I/O 使用率パネルを表示して、I/O 使用率を確認します。 -#### `NODE_disk_write_latency_more_than_16ms` {#node-disk-write-latency-more-than-16ms} +#### `NODE_disk_write_latency_more_than_16ms` {#node_disk_write_latency_more_than_16ms} - アラートルール: @@ -925,13 +925,13 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - ディスク レイテンシ パネルを表示して、ディスクの書き込みレイテンシーを確認します。 - ディスク I/O 使用率パネルを表示して、I/O 使用率を確認します。 -## Blackbox_exporter TCP、ICMP、HTTP アラートルール {#blackbox-exporter-tcp-icmp-and-http-alert-rules} +## Blackbox_exporter TCP、ICMP、HTTP アラートルール {#blackbox_exporter-tcp-icmp-and-http-alert-rules} このセクションでは、Blackbox_exporter の TCP、ICMP、および HTTP のアラート ルールについて説明します。 ### 緊急レベルの警報 {#emergency-level-alerts} -#### `TiDB_server_is_down` {#tidb-server-is-down} +#### `TiDB_server_is_down` {#tidb_server_is_down} - アラートルール: @@ -947,7 +947,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - TiDB プロセスが存在するかどうかを確認します。 - 監視マシンと TiDB マシン間のネットワークが正常かどうかを確認します。 -#### `TiFlash_server_is_down` {#tiflash-server-is-down} +#### `TiFlash_server_is_down` {#tiflash_server_is_down} - アラートルール: @@ -963,7 +963,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - TiFlashプロセスが存在するかどうかを確認します。 - 監視マシンとTiFlashマシン間のネットワークが正常かどうかを確認します。 -#### `TiKV_server_is_down` {#tikv-server-is-down} +#### `TiKV_server_is_down` {#tikv_server_is_down} - アラートルール: @@ -979,7 +979,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - TiKV プロセスが存在するかどうかを確認します。 - 監視マシンと TiKV マシン間のネットワークが正常かどうかを確認します。 -#### `PD_server_is_down` {#pd-server-is-down} +#### `PD_server_is_down` {#pd_server_is_down} - アラートルール: @@ -995,7 +995,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - PD プロセスが存在するかどうかを確認します。 - 監視マシンとPDマシン間のネットワークが正常かどうかを確認します。 -#### `Node_exporter_server_is_down` {#node-exporter-server-is-down} +#### `Node_exporter_server_is_down` {#node_exporter_server_is_down} - アラートルール: @@ -1011,7 +1011,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - Node_exporter プロセスが存在するかどうかを確認します。 - 監視マシンとNode_exporterマシン間のネットワークが正常かどうかを確認します。 -#### `Blackbox_exporter_server_is_down` {#blackbox-exporter-server-is-down} +#### `Blackbox_exporter_server_is_down` {#blackbox_exporter_server_is_down} - アラートルール: @@ -1027,7 +1027,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - Blackbox_Exporter プロセスが存在するかどうかを確認します。 - 監視マシンと Blackbox_Exporter マシン間のネットワークが正常かどうかを確認します。 -#### `Grafana_server_is_down` {#grafana-server-is-down} +#### `Grafana_server_is_down` {#grafana_server_is_down} - アラートルール: @@ -1043,7 +1043,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - Grafana プロセスが存在するかどうかを確認します。 - 監視マシンと Grafana マシン間のネットワークが正常かどうかを確認します。 -#### `Pushgateway_server_is_down` {#pushgateway-server-is-down} +#### `Pushgateway_server_is_down` {#pushgateway_server_is_down} - アラートルール: @@ -1059,7 +1059,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - Pushgateway プロセスが存在するかどうかを確認します。 - 監視マシンと Pushgateway マシン間のネットワークが正常かどうかを確認します。 -#### `Kafka_exporter_is_down` {#kafka-exporter-is-down} +#### `Kafka_exporter_is_down` {#kafka_exporter_is_down} - アラートルール: @@ -1075,7 +1075,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - Kafka_Exporter プロセスが存在するかどうかを確認します。 - 監視マシンと Kafka_Exporter マシン間のネットワークが正常かどうかを確認します。 -#### `Pushgateway_metrics_interface` {#pushgateway-metrics-interface} +#### `Pushgateway_metrics_interface` {#pushgateway_metrics_interface} - アラートルール: @@ -1093,7 +1093,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー ### 警告レベルのアラート {#warning-level-alerts} -#### `BLACKER_ping_latency_more_than_1s` {#blacker-ping-latency-more-than-1s} +#### `BLACKER_ping_latency_more_than_1s` {#blacker_ping_latency_more_than_1s} - アラートルール: diff --git a/auto-increment.md b/auto-increment.md index 16ac74a383500..c9184ee96fc4f 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -3,7 +3,7 @@ title: AUTO_INCREMENT summary: TiDB の AUTO_INCREMENT` 列属性について学習します。 --- -# AUTO_INCREMENT {#auto-increment} +# AUTO_INCREMENT {#auto_increment} このドキュメントでは、 `AUTO_INCREMENT`列属性の概念、実装原則、AUTO_INCREMENT関連の機能、制限などについて説明します。 @@ -181,7 +181,7 @@ Records: 2 Duplicates: 1 Warnings: 0 この例では、 `INSERT INTO t (a) VALUES ('A'), ('C') ON DUPLICATE KEY UPDATE cnt = cnt + 1;`のキー`A`の`INSERT`に値`3`の`AUTO_INCREMENT`が割り当てられていますが、この`INSERT`文には重複キー`A`が含まれているため、実際には使用されません。これにより、シーケンスが連続しないギャップが発生します。この動作はMySQLとは異なりますが、有効とみなされます。MySQLでは、トランザクションが中止されてロールバックされるなどの他のシナリオでも、シーケンスにギャップが発生します。 -## 自動IDキャッシュ {#auto-id-cache} +## 自動IDキャッシュ {#auto_id_cache} 異なるTiDBサーバーに対して`INSERT`操作を実行すると、 `AUTO_INCREMENT`番目のシーケンスが大幅に*ジャンプする*ように見える場合があります。これは、各サーバーが`AUTO_INCREMENT`の値のキャッシュを独自に持っているためです。 diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md index 341868db839a4..40f2de20b311e 100644 --- a/best-practices/massive-regions-best-practices.md +++ b/best-practices/massive-regions-best-practices.md @@ -82,7 +82,7 @@ TiKVでは、デフォルトで`raftstore.store-pool-size`から`2`に設定さ [TiKVマスター](https://github.com/tikv/tikv/tree/master)では、Hibernate リージョン がデフォルトで有効になっています。この機能は必要に応じて設定できます。詳細は[Hibernateリージョンを構成する](/tikv-configuration-file.md)を参照してください。 -### 方法3: Region Mergeを有効にする {#method-3-enable-code-region-merge-code} +### 方法3: Region Mergeを有効にする {#method-3-enable-region-merge} > **Note:** > @@ -108,7 +108,7 @@ TiKVでは、デフォルトで`raftstore.store-pool-size`から`2`に設定さ I/O リソースと CPU リソースが十分な場合は、単一のマシンに複数の TiKV インスタンスをデプロイして、単一の TiKV インスタンス上のリージョンの数を減らすことも、TiKV クラスター内のマシンの数を増やすこともできます。 -### 方法5: raft-base-tick-intervalを調整する {#method-5-adjust-code-raft-base-tick-interval-code} +### 方法5: raft-base-tick-intervalを調整する {#method-5-adjust-raft-base-tick-interval} リージョン数を減らすだけでなく、単位時間あたりに各リージョンに送信されるメッセージ数を減らすことで、 Raftstoreへの負荷を軽減することもできます。例えば、 `raft-base-tick-interval`設定項目の値を適切に増やすことができます。 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index c05ad675ed769..19b372ab49bbb 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -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の実際の負荷やストレージ使用量から、負荷の不均衡が発生しているかどうかを確認する必要があります。 @@ -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} diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index e886446396798..31b583248b82a 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -3,7 +3,7 @@ title: TiDB Backup & Restore Overview summary: TiDB Backup & Restore (BR) は、クラスタの高可用性とデータの安全性を確保します。短い RPO でディザスタリカバリをサポートし、誤操作を処理し、履歴データの監査機能を提供します。バックアップ操作はオフピーク時に実行し、バックアップデータは互換性のあるストレージシステムに保存することをお勧めします。BRは、フルバックアップとログバックアップ、および任意の時点へのデータ復元をサポートします。バックアップと復元には、TiDB クラスタと同じメジャーバージョンのBRを使用することが重要です。 --- -# TiDBのバックアップと復元の概要 {#tidb-backup-x26-restore-overview} +# TiDBのバックアップと復元の概要 {#tidb-backup--restore-overview} TiDBは、 Raftプロトコルと適切なデプロイメントトポロジーに基づいて、クラスタの高い可用性を実現しています。クラスタ内のノードがいくつか故障しても、クラスタは引き続き利用可能です。さらにデータの安全性を確保するため、TiDBは、自然災害や誤操作からデータを復旧するための最終手段として、バックアップ＆リストア（BR）機能を提供しています。 @@ -128,7 +128,7 @@ TiDBの一部の機能が有効化または無効化されている場合、バ バージョン 7.0.0 以降、TiDB は SQL ステートメントによるバックアップおよびリストア操作を段階的にサポートしています。そのため、クラスタ データのバックアップおよびリストアを行う際には、TiDB クラスタと同じメジャー バージョンのBRツールを使用することを強く推奨します。また、メジャー バージョンをまたいでのデータ バックアップおよびリストア操作は避けてください。これにより、リストア操作のスムーズな実行とデータの一貫性が確保されます。バージョン 7.6.0 以降、 BR はデフォルトで一部の`mysql`システム テーブルにデータをリストアします。つまり、 `--with-sys-table`オプションはデフォルトで`true`に設定されます。異なるバージョンの TiDB クラスタにデータを復元する際に、システム テーブルのスキーマが異なるために`[BR:Restore:ErrRestoreIncompatibleSys]incompatible system table`と同様のエラーが発生した場合は、 `--with-sys-table=false`を設定してシステム テーブルの復元をスキップし、このエラーを回避できます。 -#### TiDB v6.6.0以前のBRバージョン互換性マトリックス {#br-version-compatibility-matrix-before-tidb-v6-6-0} +#### TiDB v6.6.0以前のBRバージョン互換性マトリックス {#br-version-compatibility-matrix-before-tidb-v660} TiDB v6.6.0より前のBRの互換性情報は以下のとおりです。 @@ -137,7 +137,7 @@ TiDB v6.6.0より前のBRの互換性情報は以下のとおりです。 | TiDB v6.0、v6.1、v6.2、v6.3、v6.4、または v6.5 スナップショット バックアップ | 互換性あり（既知の問題[#36379](https://github.com/pingcap/tidb/issues/36379) ：バックアップデータに空のスキーマが含まれている場合、 BR がエラーを報告する可能性があります。） | 互換性がある | 互換性がある | 互換性がある | 互換性あり（BRはv6.6である必要があります） | | TiDB v6.3、v6.4、v6.5、またはv6.6のログバックアップ | 互換性がない | 互換性がない | 互換性がない | 互換性がある | 互換性がある | -#### TiDB v6.5.0とv8.5.0間のBRバージョン互換性マトリックス {#br-version-compatibility-matrix-between-tidb-v6-5-0-and-v8-5-0} +#### TiDB v6.5.0とv8.5.0間のBRバージョン互換性マトリックス {#br-version-compatibility-matrix-between-tidb-v650-and-v850} このセクションでは、TiDB v6.5.0からv8.5.0までのすべての[長期サポート（LTS）](/releases/versioning.md#long-term-support-releases)バージョン（v6.5.0、v7.1.0、v7.5.0、v8.1.0、v8.5.0を含む）のBR互換性情報について説明します。 diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md index 16f3f7ac8cdbc..25f78de5190a9 100644 --- a/br/br-snapshot-guide.md +++ b/br/br-snapshot-guide.md @@ -143,7 +143,7 @@ tiup br restore full \ --storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" ``` -### mysqlスキーマ内のテーブルを復元する {#restore-tables-in-the-code-mysql-code-schema} +### mysqlスキーマ内のテーブルを復元する {#restore-tables-in-the-mysql-schema} - BR v5.1.0以降では、スナップショットをバックアップすると、 BRは`mysql`スキーマ内の**システムテーブルを**自動的にバックアップしますが、デフォルトではこれらのシステムテーブルを復元しません。 - バージョン6.2.0以降、 BRでは`--with-sys-table`を指定して、**一部のシステムテーブルのデータを**復元できます。 diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md index 28c5d01bc98b0..d3436651e41e7 100644 --- a/br/br-snapshot-manual.md +++ b/br/br-snapshot-manual.md @@ -267,7 +267,7 @@ tiup br restore full \ --log-file restorefull.log ``` -### mysqlスキーマから実行プランバインディングを復元する {#restore-execution-plan-bindings-from-the-code-mysql-code-schema} +### mysqlスキーマから実行プランバインディングを復元する {#restore-execution-plan-bindings-from-the-mysql-schema} クラスターの実行プラン バインディングを復元するには、 `--with-sys-table`オプションと、復元する`mysql`スキーマを指定する`--filter`または`-f`オプションを含む`tiup br restore full`コマンドを実行します。 diff --git a/check-before-deployment.md b/check-before-deployment.md index 3d9b7dd67e5bc..60ad4c03b5bcf 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -719,7 +719,7 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t [root@10.0.1.1 tidb]# -## numactlツールをインストールする {#install-the-code-numactl-code-tool} +## numactlツールをインストールする {#install-the-numactl-tool} このセクションでは、NUMAツールのインストール方法について説明します。オンライン環境では、ハードウェア構成が通常必要以上に高くなるため、ハードウェアリソースをより適切に計画するために、TiDBまたはTiKVの複数のインスタンスを1台のマシンにデプロイすることができます。このようなシナリオでは、NUMAツールを使用して、CPUリソースの競合によるパフォーマンス低下を防ぐことができます。 diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index 7dbc450dab5c8..3ca057e462525 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -7,104 +7,104 @@ summary: TiDB の構成オプションについて学習します。 TiDBクラスタを起動する際には、コマンドラインオプションまたは環境変数を使用して設定できます。このドキュメントでは、TiDBのコマンドオプションについて説明します。デフォルトのTiDBポートは、クライアントリクエスト用に`4000` 、ステータスレポート用に`10080`です。 -## `--advertise-address` {#advertise-address} +## `--advertise-address` {#--advertise-address} - TiDBサーバーにログインするためのIPアドレス - デフォルト: `""` - このアドレスは、TiDB クラスターの残りの部分とユーザーがアクセスできる必要があります。 -## `--config` {#config} +## `--config` {#--config} - 設定ファイル - デフォルト: `""` - 設定ファイルが指定されている場合、TiDB は設定ファイルを読み取ります。対応する設定がコマンドラインオプションにも存在する場合、TiDB はコマンドラインオプションの設定を使用して設定ファイルの設定を上書きします。詳細な設定情報については、 [TiDBコンフィグレーションファイルの説明](/tidb-configuration-file.md)参照してください。 -## `--config-check` {#config-check} +## `--config-check` {#--config-check} - 設定ファイルの有効性をチェックして終了します - デフォルト: `false` -## `--config-strict` {#config-strict} +## `--config-strict` {#--config-strict} - 設定ファイルの有効性を強制する - デフォルト: `false` -## `--cors` {#cors} +## `--cors` {#--cors} - TiDB HTTPステータスサービスのクロスオリジンリクエスト共有（CORS）リクエストの値`Access-Control-Allow-Origin`指定します。 - デフォルト: `""` -## `--host` {#host} +## `--host` {#--host} - TiDBサーバーが監視するホストアドレス - デフォルト: `"0.0.0.0"` - TiDBサーバーはこのアドレスを監視します。 - `"0.0.0.0"`アドレスはデフォルトですべてのネットワークカードを監視します。複数のネットワークカードがある場合は、サービスを提供するネットワークカード（例： `192.168.100.113` ）を指定してください。 -## `--initialize-insecure` {#initialize-insecure} +## `--initialize-insecure` {#--initialize-insecure} - tidb-server を非セキュアモードでブートストラップする - デフォルト: `true` -## `--initialize-secure` {#initialize-secure} +## `--initialize-secure` {#--initialize-secure} - tidb-server の初期化時に、認証方式`auth_socket`使用してアカウント`root`を作成するかどうかを制御します。 `true`に設定した場合、TiDB への初回ログインにはソケット接続を使用する必要があります。これにより、セキュリティが強化されます。 - デフォルト: `false` -## `--initialize-sql-file` {#initialize-sql-file} +## `--initialize-sql-file` {#--initialize-sql-file} - TiDBクラスタの初回起動時に実行されるSQLスクリプト。詳細は[構成項目`initialize-sql-file`](/tidb-configuration-file.md#initialize-sql-file-new-in-v660)参照。 - デフォルト: `""` -## `-L` {#l} +## `-L` {#-l} - ログレベル - デフォルト: `"info"` - `"warn"` `"fatal"` `"error"` `"debug"` `"info"` -## `--lease` {#lease} +## `--lease` {#--lease} - スキーマリースの期間。何をするかを十分に理解していない場合は、値を変更するのは**危険**です。 - デフォルト: `45s` -## `--log-file` {#log-file} +## `--log-file` {#--log-file} - ログファイル - デフォルト: `""` - このオプションが設定されていない場合、ログは「stderr」に出力されます。このオプションが設定されている場合、ログは対応するファイルに出力されます。 -## `--log-general` {#log-general} +## `--log-general` {#--log-general} - [一般ログ](/system-variables.md#tidb_general_log)のファイル名 - デフォルト: `""` - このオプションが設定されていない場合、一般ログはデフォルトで[`--log-file`](#--log-file)で指定されたファイルに書き込まれます。 -## `--log-slow-query` {#log-slow-query} +## `--log-slow-query` {#--log-slow-query} - スロークエリログのディレクトリ - デフォルト: `""` - このオプションが設定されていない場合、ログはデフォルトで`--log-file`で指定されたファイルに出力されます。 -## `--metrics-addr` {#metrics-addr} +## `--metrics-addr` {#--metrics-addr} - Prometheus Pushgatewayアドレス - デフォルト: `""` - 空のままにすると、Prometheus クライアントのプッシュが停止します。 - 形式は`--metrics-addr=192.168.100.115:9091`です。 -## `--metrics-interval` {#metrics-interval} +## `--metrics-interval` {#--metrics-interval} - Prometheusクライアントのプッシュ間隔（秒） - デフォルト: `15s` - 値を 0 に設定すると、Prometheus クライアントのプッシュが停止します。 -## `-P` {#p} +## `-P` {#-p} - TiDBサービスの監視ポート - デフォルト: `"4000"` - TiDBサーバーはこのポートからの MySQL クライアント要求を受け入れます。 -## `--path` {#path} +## `--path` {#--path} - 「unistore」のようなローカルストレージエンジンのデータディレクトリへのパス - `--store = tikv`場合、パスを指定する必要があります。 `--store = unistore`場合、パスを指定しないとデフォルト値が使用されます。 @@ -112,12 +112,12 @@ TiDBクラスタを起動する際には、コマンドラインオプション - デフォルト: `"/tmp/tidb"` - 純粋なインメモリ TiDB を有効にするには、 `tidb-server --store=unistore --path=""`使用します。 -## `--proxy-protocol-fallbackable` {#proxy-protocol-fallbackable} +## `--proxy-protocol-fallbackable` {#--proxy-protocol-fallbackable} - PROXYプロトコルフォールバックモードを有効にするかどうかを制御します。このパラメータを`true`に設定すると、TiDBはPROXYプロトコル仕様を使用せず、PROXYプロトコルヘッダーを送信せずに、 `--proxy-protocol-networks`に属するクライアント接続を受け入れます。デフォルトでは、TiDBは`--proxy-protocol-networks`に属し、PROXYプロトコルヘッダーを送信するクライアント接続のみを受け入れます。 - デフォルト値: `false` -## `--proxy-protocol-networks` {#proxy-protocol-networks} +## `--proxy-protocol-networks` {#--proxy-protocol-networks} - [PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)使用して TiDB に接続できるプロキシ サーバーの IP アドレスのリスト。 - デフォルト: `""` @@ -132,7 +132,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション > > PROXYプロトコルを有効にしたAWS Network Load Balancer（NLB）を使用するには、NLBの`target group`プロパティを設定する必要があります。具体的には、 `proxy_protocol_v2.client_to_server.header_place`を`on_first_ack`に設定します。同時に、AWSサポートにチケットを送信する必要があります。PROXYプロトコルを有効にすると、クライアントはサーバーからのハンドシェイクパケットの取得に失敗し、クライアントがタイムアウトするまでパケットがブロックされることに注意してください。これは、NLBがクライアントがデータを送信した後にのみプロキシパケットを送信するためです。ただし、クライアントがデータパケットを送信する前に、サーバーから送信されたデータパケットは内部ネットワークでドロップされます。 -## `--proxy-protocol-header-timeout` {#proxy-protocol-header-timeout} +## `--proxy-protocol-header-timeout` {#--proxy-protocol-header-timeout} - PROXYプロトコルヘッダー読み取りのタイムアウト - デフォルト: `5` (秒) @@ -145,25 +145,25 @@ TiDBクラスタを起動する際には、コマンドラインオプション > > 値を`0`に設定しないでください。特別な状況を除き、デフォルト値を使用してください。 -## `--report-status` {#report-status} +## `--report-status` {#--report-status} - ステータスレポートとpprofツールを有効（ `true` ）または無効（ `false` ）にする - デフォルト: `true` - このパラメータを`true`に設定すると、メトリクスとpprofが有効になります。 `false`に設定すると、メトリクスとpprofが無効になります。 -## `--run-ddl` {#run-ddl} +## `--run-ddl` {#--run-ddl} - `tidb-server` DDL文を実行するかどうかを確認し、クラスタ内の`tidb-server`の数が2を超える場合に設定する - デフォルト: `true` - 値は (true) または (false) になります。 (true) は、 `tidb-server` DDL 自体を実行することを示します。 (false) は、 `tidb-server` DDL 自体を実行しないことを示します。 -## `--socket string` {#socket-string} +## `--socket string` {#--socket-string} - TiDB サービスは、外部接続に Unix ソケット ファイルを使用します。 - デフォルト: `""` - `/tmp/tidb.sock`使用して Unix ソケット ファイルを開きます。 -## `--status` {#status} +## `--status` {#--status} - TiDBサーバーのステータスレポートポート - デフォルト: `"10080"` @@ -171,65 +171,65 @@ TiDBクラスタを起動する際には、コマンドラインオプション - Prometheus メトリックには`"http://host:status_port/metrics"`でアクセスできます。 - pprof データには`"http://host:status_port/debug/pprof"`でアクセスできます。 -## `--status-host` {#status-host} +## `--status-host` {#--status-host} - TiDBサービスのステータスを監視するために使用される`HOST` - デフォルト: `0.0.0.0` -## `--store` {#store} +## `--store` {#--store} - 最下層で TiDB が使用するストレージエンジンを指定します - デフォルト: `"unistore"` - 「unistore」または「tikv」を選択できます。（「unistore」はローカルストレージエンジン、「tikv」は分散ストレージエンジンです） -## `--temp-dir` {#temp-dir} +## `--temp-dir` {#--temp-dir} - TiDBの一時ディレクトリ - デフォルト: `"/tmp/tidb"` -## `--tidb-service-scope` {#tidb-service-scope} +## `--tidb-service-scope` {#--tidb-service-scope} - 現在の TiDB インスタンスの初期値として[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)指定します。 - デフォルト: `""` -## `--token-limit` {#token-limit} +## `--token-limit` {#--token-limit} - TiDBで同時に実行できるセッション数。トラフィック制御に使用されます。 - デフォルト: `1000` - 同時セッション数が`token-limit`より大きい場合、リクエストはブロックされ、トークンを解放する操作が終了するまで待機します。 -## `-V` {#v} +## `-V` {#-v} - TiDBのバージョンを出力します - デフォルト: `""` -## `--plugin-dir` {#plugin-dir} +## `--plugin-dir` {#--plugin-dir} - プラグインのストレージディレクトリ。 - デフォルト: `"/data/deploy/plugin"` -## `--plugin-load` {#plugin-load} +## `--plugin-load` {#--plugin-load} - ロードするプラグインの名前。それぞれはコンマで区切られます。 - デフォルト: `""` -## `--affinity-cpus` {#affinity-cpus} +## `--affinity-cpus` {#--affinity-cpus} - TiDBサーバーのCPUアフィニティをカンマ区切りで設定します。例："1,2,3"。 - デフォルト: `""` -## `--redact` {#redact} +## `--redact` {#--redact} - サブコマンド`collect-log`使用するときに、 TiDBサーバーがログ ファイルを非感度化するかどうかを決定します。 - デフォルト: false - 値が`true`の場合、マスキング操作となり、 `‹ ›`マーク記号で囲まれたすべてのフィールドが`?`に置き換えられます。値が`false`の場合、リストア操作となり、すべてのマーク記号が削除されます。この機能を使用するには、 `./tidb-server --redact=xxx collect-log `実行して、 ``で指定された TiDBサーバーログファイルを非感応化またはリストアし、 ``に出力します。詳細については、システム変数[`tidb_redact_log`](/system-variables.md#tidb_redact_log)参照してください。 -## `--repair-mode` {#repair-mode} +## `--repair-mode` {#--repair-mode} - データ修復シナリオでのみ使用される修復モードを有効にするかどうかを決定します。 - デフォルト: `false` -## `--repair-list` {#repair-list} +## `--repair-list` {#--repair-list} - 修復モードで修復されるテーブルの名前。 - デフォルト: `""` diff --git a/command-line-flags-for-tikv-configuration.md b/command-line-flags-for-tikv-configuration.md index ee00768b3a89d..fbe77218a5d24 100644 --- a/command-line-flags-for-tikv-configuration.md +++ b/command-line-flags-for-tikv-configuration.md @@ -10,46 +10,46 @@ TiKV は、コマンドラインパラメータに対していくつかの読み - ファイルサイズ（バイト単位）: KB、MB、GB、TB、PB（または小文字） - 時間（ミリ秒単位）: ms、s、m、h -## `-A, --addr` {#a-addr} +## `-A, --addr` {#-a---addr} - TiKVサーバーが監視するアドレス - デフォルト: `"127.0.0.1:20160"` - クラスターをデプロイするには、現在のホストのIPアドレスを`--addr`で指定する必要があります（例： `"192.168.100.113:20160"` 。クラスターがDocker上で実行される場合は、DockerのIPアドレスを`"0.0.0.0:20160"`で指定します。 -## `--advertise-addr` {#advertise-addr} +## `--advertise-addr` {#--advertise-addr} - サーバーは外部からのクライアントトラフィックのアドレスをアドバタイズします - デフォルト: `${addr}` - Docker または NAT ネットワークのためにクライアントが`--addr`アドレス経由で TiKV に接続できない場合は、 `--advertise-addr`アドレスを手動で設定する必要があります。 - 例えば、Dockerの内部IPアドレスが172.17.0.1で、ホストのIPアドレスが192.168.100.113で、ポートマッピングが`-p 20160:20160`に設定されている場合、 `--advertise-addr` 「192.168.100.113:20160」に設定できます。クライアントは192.168.100.113:20160を介してこのサービスにアクセスできます。 -## `--status-addr` {#status-addr} +## `--status-addr` {#--status-addr} - TiKV サービスのステータスをリッスンするポート - デフォルト: `"20180"` - Prometheus は`http://host:status_port/metrics`介してこのステータス情報にアクセスできます。 - プロファイルは`http://host:status_port/debug/pprof/profile`を介してこのステータス情報にアクセスできます。 -## `--advertise-status-addr` {#advertise-status-addr} +## `--advertise-status-addr` {#--advertise-status-addr} - TiKV が外部からサービス ステータスにアクセスするために使用するアドレス。 - デフォルト: 値`--status-addr`が使用されます。 - Docker または NAT ネットワークのためにクライアントが`--status-addr`アドレス経由で TiKV に接続できない場合は、 `--advertise-status-addr`アドレスを手動で設定する必要があります。 - 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 20180:20180`に設定されています。この場合、 `--advertise-status-addr="192.168.100.113:20180"`設定します。クライアントは`192.168.100.113:20180`を通じてこのサービスを見つけられます。 -## `-C, --config` {#c-config} +## `-C, --config` {#-c---config} - 設定ファイル - デフォルト: `""` - コマンドラインを使用して設定を行うと、設定ファイル内の同じ設定が上書きされます。 -## `--capacity` {#capacity} +## `--capacity` {#--capacity} - ストアキャパシティ - デフォルト: `0` (無制限) - PDはこのフラグを使用して、TiKVサーバーのバランス調整方法を決定します。（ヒント：1073741824の代わりに10GBを使用することもできます） -## `--config-info <FORMAT>` {#config-info-x3c-format} +## `--config-info <FORMAT>` {#--config-info-format} - このフラグを使用すると、使用可能な構成値が`FORMAT`に従ってリストされ、終了します。 - `FORMAT`の値オプション: `json` 。現在、JSON 形式のみがサポートされています。 @@ -74,24 +74,24 @@ TiKV は、コマンドラインパラメータに対していくつかの読み } ``` -## `--data-dir` {#data-dir} +## `--data-dir` {#--data-dir} - データディレクトリへのパス - デフォルト: `"/tmp/tikv/store"` -## `-L` {#l} +## `-L` {#-l} - ログレベル - デフォルト: `"info"` - `"warn"` `"fatal"` `"error"` `"debug"` `"info"` -## `--log-file` {#log-file} +## `--log-file` {#--log-file} - ログファイル - デフォルト: `""` - このフラグが設定されていない場合、ログは「stderr」に書き込まれます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 -## `--pd` {#pd} +## `--pd` {#--pd} - PDサーバーのアドレスリスト - デフォルト: `""` diff --git a/configure-memory-usage.md b/configure-memory-usage.md index 916aa933340da..672cd50cc2f6d 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -58,7 +58,7 @@ tidb-server インスタンスのメモリ使用量が総メモリの一定割 > > ハイブリッド展開シナリオでは、物理マシン全体の合計メモリしきい値ではなく、単一の tidb-server インスタンスのメモリ使用量しきい値は`tidb_server_memory_limit`なります。 -## INFORMATION_SCHEMA システム テーブルを使用して、現在の tidb-server インスタンスのメモリ使用量を表示する {#view-the-memory-usage-of-the-current-tidb-server-instance-using-the-information-schema-system-table} +## INFORMATION_SCHEMA システム テーブルを使用して、現在の tidb-server インスタンスのメモリ使用量を表示する {#view-the-memory-usage-of-the-current-tidb-server-instance-using-the-information_schema-system-table} 現在のインスタンスまたはクラスターのメモリ使用量を表示するには、システム テーブル[`INFORMATION_SCHEMA.(CLUSTER_)MEMORY_USAGE`](/information-schema/information-schema-memory-usage.md)をクエリします。 @@ -194,7 +194,7 @@ TiDBは、実行演算子のディスクへの書き込みをサポートして ## その他 {#others} -### GOMEMLIMITを設定して OOM の問題を軽減する {#mitigate-oom-issues-by-configuring-code-gomemlimit-code} +### GOMEMLIMITを設定して OOM の問題を軽減する {#mitigate-oom-issues-by-configuring-gomemlimit} GO 1.19 では、GC をトリガーするメモリ制限を設定するための環境変数[`GOMEMLIMIT`](https://pkg.go.dev/runtime@go1.19#hdr-Environment_Variables)導入されています。 diff --git a/configure-placement-rules.md b/configure-placement-rules.md index e86e0381fcad6..c25e46c99dc18 100644 --- a/configure-placement-rules.md +++ b/configure-placement-rules.md @@ -324,7 +324,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} +### シナリオ2: 3つのデータセンターに5つのレプリカを2:2:1の割合で配置し、Leaderは3番目のデータセンターに配置しない {#scenario-2-place-five-replicas-in-three-data-centers-in-the-proportion-of-221-and-the-leader-should-not-be-in-the-third-data-center} 3つのルールを作成します。レプリカ数をそれぞれ`2` 、 `2` 、 `1`に設定します。各ルールで、レプリカを対応するデータセンター`label_constraints`から 8 に制限します。さらに、Leaderを必要としないデータセンターについては、 `role`を`follower`に変更します。 diff --git a/constraints.md b/constraints.md index d34200b89e512..d75d62a0cb3aa 100644 --- a/constraints.md +++ b/constraints.md @@ -64,7 +64,7 @@ TiDB の`CHECK`制約の構文は MySQL と同じです。 - `CHECK (expr)` : 制約条件を指定します。ここで、 `expr`ブール式である必要があります。テーブルの各行について、この式の計算結果は`TRUE` 、 `FALSE` 、または`UNKNOWN` ( `NULL`値の場合) のいずれかである必要があります。ある行の計算結果が`FALSE`場合、制約に違反していることを示します。 - `[NOT] ENFORCED` : 制約チェックを実装するかどうかを指定します。これを使用して、制約`CHECK`有効または無効にすることができます。 -### CHECK制約を追加する {#add-code-check-code-constraints} +### CHECK制約を追加する {#add-check-constraints} TiDB では、 [`CREATE TABLE`](/sql-statements/sql-statement-create-table.md)または[`ALTER TABLE`](/sql-statements/sql-statement-modify-column.md)ステートメントのいずれかを使用して、テーブルに`CHECK`制約を追加できます。 @@ -84,7 +84,7 @@ TiDB では、 [`CREATE TABLE`](/sql-statements/sql-statement-create-table.md) `CHECK`制約を追加する場合、制約名を指定するか、未指定のままにすることができます。制約名を指定しない場合は、TiDB が`_chk_<1, 2, 3...>`形式で自動的に制約名を生成します。 -### CHECK制約を表示する {#view-code-check-code-constraints} +### CHECK制約を表示する {#view-check-constraints} [`SHOW CREATE TABLE`](/sql-statements/sql-statement-show-create-table.md)ステートメントを使用すると、テーブル内の制約情報を表示できます。例: @@ -105,7 +105,7 @@ CONSTRAINT `t_chk_2` CHECK ((1 < `c`)) 1 row in set (0.00 sec) ``` -### CHECK制約を削除する {#delete-code-check-code-constraints} +### CHECK制約を削除する {#delete-check-constraints} `CHECK`制約を削除する場合は、削除する制約の名前を指定する必要があります。例： @@ -113,7 +113,7 @@ CONSTRAINT `t_chk_2` CHECK ((1 < `c`)) ALTER TABLE t DROP CONSTRAINT t_chk_1; ``` -### CHECK制約を有効または無効にする {#enable-or-disable-code-check-code-constraints} +### CHECK制約を有効または無効にする {#enable-or-disable-check-constraints} テーブルに[`CHECK`制約を追加する](#add-check-constraints)設定すると、データの挿入または更新時に TiDB が制約チェックを実装する必要があるかどうかを指定できます。 diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index cff3050e93c2b..4a8f8d16d8bbe 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -25,7 +25,7 @@ summary: このドキュメントは、TiDB Dashboardに関するよくある質 ## UIに関するよくあるFAQ {#ui-related-faq} -### 概要ページのQPSとレイテンシのセクションにprometheus_not_foundエラーが表示される {#a-code-prometheus-not-found-code-error-is-shown-in-strong-qps-strong-and-strong-latency-strong-sections-on-the-overview-page} +### 概要ページのQPSとレイテンシのセクションにprometheus_not_foundエラーが表示される {#a-prometheus_not_found-error-is-shown-in-qps-and-latency-sections-on-the-overview-page} **概要**ページの**QPS**と**レイテンシの**セクションには、Prometheusがデプロイされたクラスターが必要です。そうでない場合、エラーが表示されます。この問題を解決するには、クラスターにPrometheusインスタンスをデプロイしてください。 @@ -50,11 +50,11 @@ Prometheusインスタンスをデプロイしてもこの問題が引き続き クラスタが起動している場合でも、このコマンドを実行してください。このコマンドはクラスタ内の通常のアプリケーションには影響を与えませんが、メトリクスアドレスを更新してレポートするため、TiDB Dashboardに監視メトリクスが正常に表示されるようになります。 -### スロークエリページにinvalid connectionエラーが表示されます {#an-code-invalid-connection-code-error-is-shown-on-the-strong-slow-queries-strong-page} +### スロークエリページにinvalid connectionエラーが表示されます {#an-invalid-connection-error-is-shown-on-the-slow-queries-page} 原因として考えられるのは、TiDBのプリペアドプランキャッシュ機能を有効にしていることです。これは実験的機能であるため、有効にすると特定のTiDBバージョンでプリペアドプランキャッシュが正常に機能しない可能性があり、TiDB Dashboard（およびその他のアプリケーション）でこの問題が発生する可能性があります。プリペアドプランキャッシュを無効にするには、システム変数[`tidb_enable_prepared_plan_cache = OFF`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610)を設定します。 -### required component NgMonitoring is not startedというエラーが表示されます {#a-code-required-component-ngmonitoring-is-not-started-code-error-is-shown} +### required component NgMonitoring is not startedというエラーが表示されます {#a-required-component-ngmonitoring-is-not-started-error-is-shown} NgMonitoringは、TiDB v5.4.0以降のバージョンに組み込まれた高度な監視コンポーネントで、**継続的プロファイリング**や**Top SQL**などのTiDB Dashboard機能をサポートします。TiUPの新しいバージョンを使用してクラスターをデプロイまたはアップグレードすると、NgMonitoringが自動的にデプロイされます。TiDB Operatorを使用してデプロイされたクラスターの場合は、 [継続的なプロファイリングを有効にする](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/access-dashboard/#enable-continuous-profiling)を参照してTiUPを手動でデプロイできます。 @@ -123,7 +123,7 @@ tiup update playground -### スロークエリページにunknown fieldエラーが表示されます {#an-code-unknown-field-code-error-is-shown-on-the-strong-slow-queries-strong-page} +### スロークエリページにunknown fieldエラーが表示されます {#an-unknown-field-error-is-shown-on-the-slow-queries-page} クラスターのアップグレード後に**「スロークエリ」**ページにエラー`unknown field`が表示される場合、そのエラーはTiDB Dashboardのサーバーフィールド（更新される可能性があります）とユーザー設定フィールド（ブラウザキャッシュ内）の差異に起因する互換性の問題に関連しています。この問題は修正されています。クラスターのバージョンがv5.0.3またはv4.0.14より前の場合は、以下の手順に従ってブラウザキャッシュをクリアしてください。 diff --git a/dashboard/top-sql.md b/dashboard/top-sql.md index 0cdafe454e620..43fccea752d7e 100644 --- a/dashboard/top-sql.md +++ b/dashboard/top-sql.md @@ -63,7 +63,7 @@ UIに加えて、TiDBシステム変数[`tidb_enable_top_sql`](/system-variables SET GLOBAL tidb_enable_top_sql = 1; ``` -### （オプション）TiKV Network IO collectionを有効にする v8.5.7の新機能 +### （オプション）TiKV Network IO collectionを有効にする v8.5.7の新機能 {#optional-enable-tikv-network-io-collection-new-in-v857} TiKVノードで`Order By Network`または`Order By Logical IO`によるTop SQLを表示したり、`By Region`集計を使用したりするには、Top SQL設定で**Enable TiKV Network IO collection (multi-dimensional)**スイッチを有効にして変更を保存します。 @@ -167,7 +167,7 @@ UIに加えて、TiDBシステム変数[`tidb_enable_top_sql`](/system-variables SET GLOBAL tidb_enable_top_sql = 0; ``` -### TiKV Network IO collectionを無効にする +### TiKV Network IO collectionを無効にする {#disable-tikv-network-io-collection} Top SQLのCPU次元の分析機能は維持したまま、TiKVの`Network Bytes`や`Logical IO Bytes`などの多次元データの収集のみを停止したい場合は、Top SQL設定パネルで**Enable TiKV Network IO collection (multi-dimensional)**スイッチを無効にします。 diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md index 1609f9b4452fd..8641504de152c 100644 --- a/data-type-date-and-time.md +++ b/data-type-date-and-time.md @@ -83,7 +83,7 @@ TiDBは、時間値を格納するためにMySQLのすべての日付と時刻 ## サポートされているタイプ {#supported-types} -### DATE型 {#code-date-code-type} +### DATE型 {#date-type} `DATE`日付部分のみを含み、時刻部分は含みません`YYYY-MM-DD`形式で表示されます。サポートされる範囲は「0000-01-01」から「9999-12-31」です。 @@ -91,7 +91,7 @@ TiDBは、時間値を格納するためにMySQLのすべての日付と時刻 DATE ``` -### TIME型 {#code-time-code-type} +### TIME型 {#time-type} `TIME`型の場合、フォーマットは`HH:MM:SS[.fraction]`で、有効な値の範囲は '-838:59:59.000000' から '838:59:59.000000' です。5 `TIME` 、1 日の時刻だけでなく、2 つのイベント間の時間間隔も示します。オプションで 0 から 6 の範囲の`fsp`値を指定し、小数秒の精度を指定できます。省略した場合、デフォルトの精度は 0 です。 @@ -103,7 +103,7 @@ TIME[(fsp)] > > `TIME`の省略形に注意してください。例えば、「11:12」は「00:11:12」ではなく「11:12:00」を意味します。一方、「1112」は「00:11:12」を意味します。これらの違いは、 `:`文字の有無によって生じます。 -### DATETIME型 {#code-datetime-code-type} +### DATETIME型 {#datetime-type} `DATETIME`日付部分と時刻部分の両方が含まれます。有効な値の範囲は「0000-01-01 00:00:00.000000」から「9999-12-31 23:59:59.999999」です。 @@ -113,7 +113,7 @@ TiDBは`DATETIME`値を`YYYY-MM-DD HH:MM:SS[.fraction]`形式で表示します DATETIME[(fsp)] ``` -### TIMESTAMP型 {#code-timestamp-code-type} +### TIMESTAMP型 {#timestamp-type} `TIMESTAMP`日付部分と時刻部分の両方を含みます。有効な値の範囲は、UTC時間で「1970-01-01 00:00:01.000000」から「2038-01-19 03:14:07.999999」までです。オプションで0から6の範囲のfsp値を指定して、小数秒の精度を指定できます。省略した場合、デフォルトの精度は0です。 @@ -131,7 +131,7 @@ TIMESTAMP[(fsp)] > > MySQLと同様に、 `TIMESTAMP`データ型は[2038年問題](https://en.wikipedia.org/wiki/Year_2038_problem)影響を受けます。2038を超える値を格納する場合は、代わりに`DATETIME`型の使用を検討してください。 -### YEAR型 {#code-year-code-type} +### YEAR型 {#year-type} `YEAR`型は「YYYY」形式で指定します。サポートされる値の範囲は1901から2155まで、または0000です。 @@ -149,7 +149,7 @@ YEAR[(4)] 無効な値`YEAR`は自動的に 0000 に変換されます (ユーザーが`NO_ZERO_DATE` SQL モードを使用していない場合)。 -## TIMESTAMPとDATETIMEの自動初期化と更新 {#automatic-initialization-and-update-of-code-timestamp-code-and-code-datetime-code} +## TIMESTAMPとDATETIMEの自動初期化と更新 {#automatic-initialization-and-update-of-timestamp-and-datetime} `TIMESTAMP`または`DATETIME`値タイプを持つ列は、自動的に初期化されるか、現在の時刻に更新されます。 diff --git a/data-type-numeric.md b/data-type-numeric.md index 64478f1ce2610..99f90c31254d7 100644 --- a/data-type-numeric.md +++ b/data-type-numeric.md @@ -49,7 +49,7 @@ TiDBは、 `INTEGER` / `INT` 、 `TINYINT` 、 `SMALLINT` 、 `MEDIUMINT` 、 `B | `INT` | 4 | -2147483648 / 0 | 2147483647 / 4294967295 | | `BIGINT` | 8 | -9223372036854775808 / 0 | 9223372036854775807 / 18446744073709551615 | -### BITタイプ {#code-bit-code-type} +### BITタイプ {#bit-type} BITデータ型。BIT(M)型はMビット値をstorageします。Mは1から64までの範囲で指定でき、デフォルト値は1です。 @@ -57,7 +57,7 @@ BITデータ型。BIT(M)型はMビット値をstorageします。Mは1から64 BIT[(M)] ``` -### BOOLEAN型 {#code-boolean-code-type} +### BOOLEAN型 {#boolean-type} `BOOLEAN`型とそのエイリアス`BOOL` `TINYINT(1)`と同等です。値が`0`場合は`False` 、それ以外の場合は`True`とみなされます。MySQLと同様に、 `True`は`1` 、 `False`は`0`です。 @@ -65,7 +65,7 @@ BIT[(M)] BOOLEAN ``` -### TINYINT型 {#code-tinyint-code-type} +### TINYINT型 {#tinyint-type} `TINYINT`データ型は、[-128, 127] の範囲の符号付き値と [0, 255] の範囲の符号なし値を格納します。 @@ -73,7 +73,7 @@ BOOLEAN TINYINT[(M)] [UNSIGNED] [ZEROFILL] ``` -### SMALLINT型 {#code-smallint-code-type} +### SMALLINT型 {#smallint-type} `SMALLINT`データ型は、[-32768、32767]の範囲の符号付き値と、[0、65535]の範囲の符号なし値を格納します。 @@ -81,7 +81,7 @@ TINYINT[(M)] [UNSIGNED] [ZEROFILL] SMALLINT[(M)] [UNSIGNED] [ZEROFILL] ``` -### MEDIUMINTタイプ {#code-mediumint-code-type} +### MEDIUMINTタイプ {#mediumint-type} `MEDIUMINT`データ型は、[-8388608、8388607]の範囲の符号付き値と、[0、16777215]の範囲の符号なし値を格納します。 @@ -89,7 +89,7 @@ SMALLINT[(M)] [UNSIGNED] [ZEROFILL] MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL] ``` -### INTEGER型 {#code-integer-code-type} +### INTEGER型 {#integer-type} `INTEGER`型とそのエイリアス`INT`は、[-2147483648、2147483647] の範囲の符号付き値と、[0、4294967295] の範囲の符号なし値を格納します。 @@ -103,7 +103,7 @@ INT[(M)] [UNSIGNED] [ZEROFILL] INTEGER[(M)] [UNSIGNED] [ZEROFILL] ``` -### BIGINT型 {#code-bigint-code-type} +### BIGINT型 {#bigint-type} `BIGINT`データ型は、[-9223372036854775808、9223372036854775807]の範囲の符号付き値と、[0、18446744073709551615]の範囲の符号なし値を格納します。 @@ -132,7 +132,7 @@ TiDBは、 `FLOAT` 、 `DOUBLE`含むすべてのMySQL浮動小数点型をサ | `FLOAT(p)` | 0 <= p <= 24の場合は4、25 <= p <= 53の場合は8 | | `DOUBLE` | 8 | -### FLOAT型 {#code-float-code-type} +### FLOAT型 {#float-type} `FLOAT`型は単精度浮動小数点数を保存します。許容値は-3.402823466E+38～-1.175494351E-38、0、1.175494351E-38～3.402823466E+38です。これらはIEEE標準に基づく理論上の制限です。実際の範囲は、ハードウェアやオペレーティングシステムによって若干狭くなる場合があります。 @@ -149,7 +149,7 @@ FLOAT(p) [UNSIGNED] [ZEROFILL] > > TiDBでは、 `FLOAT`データ型のデフォルトの精度は8桁ですが、MySQLでは6桁です。例えば、TiDBとMySQLの両方で`FLOAT`型の列に`123456789`と`1.23456789`挿入した場合、MySQLで対応する値をクエリすると、 `123457000`と`1.23457`返されますが、TiDBでは`123456790`と`1.2345679`返されます。 -### DOUBLE型 {#code-double-code-type} +### DOUBLE型 {#double-type} `DOUBLE`型とそのエイリアス`DOUBLE PRECISION`は、倍精度浮動小数点数を格納します。許容値は -1.7976931348623157E+308 ～ -2.2250738585072014E-308、0、および 2.2250738585072014E-308 ～ 1.7976931348623157E+308 です。これらは IEEE 標準に基づく理論上の制限です。実際の範囲は、ハードウェアやオペレーティングシステムによって若干狭くなる場合があります。 @@ -179,7 +179,7 @@ TiDBは、DECIMALやNUMERICを含むすべてのMySQL浮動小数点型をサポ | UNSIGNED | UNSIGNED。省略した場合はSIGNEDになります。 | | ZEROFILL | 数値列に ZEROFILL を指定すると、TiDB は列に UNSIGNED 属性を自動的に追加します。 | -### DECIMAL型 {#code-decimal-code-type} +### DECIMAL型 {#decimal-type} `DECIMAL`とそのエイリアス`NUMERIC`は、パックされた「正確な」固定小数点数を格納します。M は小数点以下の桁数（精度）、D は小数点以下の桁数（スケール）です。小数点と（負数の場合は）- 記号は M には含まれません。D が 0 の場合、値には小数点も小数部もありません。DECIMAL の最大桁数（M）は 65 です。サポートされる小数点の最大桁数（D）は 30 です。D が省略された場合、デフォルトは 0 です。M が省略された場合、デフォルトは 10 です。 diff --git a/data-type-string.md b/data-type-string.md index 05af978d4623b..979a6ba7db5d2 100644 --- a/data-type-string.md +++ b/data-type-string.md @@ -9,7 +9,7 @@ TiDBは、 `CHAR` 、 `VARCHAR` 、 `BINARY` 、 `VARBINARY` 、 `BLOB` 、 `TEX ## サポートされているタイプ {#supported-types} -### CHAR型 {#code-char-code-type} +### CHAR型 {#char-type} `CHAR`は固定長文字列です。Mは列の長さを文字数（バイト数ではありません）で表します。Mの範囲は0から255です。2とは異なり、 `VARCHAR`列にデータを挿入する場合、末尾のスペース`CHAR`切り捨てられます。 @@ -17,7 +17,7 @@ TiDBは、 `CHAR` 、 `VARCHAR` 、 `BINARY` 、 `VARBINARY` 、 `BLOB` 、 `TEX [NATIONAL] CHAR[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] ``` -### VARCHAR型 {#code-varchar-code-type} +### VARCHAR型 {#varchar-type} `VARCHAR`は可変長の文字列です。Mは列の最大長（バイト数ではありません）を文字数で表します。2 `VARCHAR`最大サイズは65,535バイトを超えることはできません。4 `VARCHAR`長さは、行の最大長と使用されている文字セットによって決まります。 @@ -35,7 +35,7 @@ TiDBは、 `CHAR` 、 `VARCHAR` 、 `BINARY` 、 `VARBINARY` 、 `BLOB` 、 `TEX [NATIONAL] VARCHAR(M) [CHARACTER SET charset_name] [COLLATE collation_name] ``` -### TEXTタイプ {#code-text-code-type} +### TEXTタイプ {#text-type} `TEXT`は可変長の文字列です。列の最大長は65,535バイトです。オプションのM引数は文字数で、 `TEXT`列の最適な型を自動的に選択するために使用されます。例えば`TEXT(60)`指定すると、最大255バイトを保持できる`TINYTEXT`データ型が生成され、1文字あたり最大4バイト（4×60=240）の60文字のUTF-8文字列に適合します。M引数の使用は推奨されません。 @@ -43,7 +43,7 @@ TiDBは、 `CHAR` 、 `VARCHAR` 、 `BINARY` 、 `VARBINARY` 、 `BLOB` 、 `TEX TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] ``` -### TINYTEXT型 {#code-tinytext-code-type} +### TINYTEXT型 {#tinytext-type} `TINYTEXT`型は[`TEXT`タイプ](#text-type)と似ていますが、 `TINYTEXT`の最大列長が255である点が異なります。 @@ -51,7 +51,7 @@ TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] TINYTEXT [CHARACTER SET charset_name] [COLLATE collation_name] ``` -### MEDIUMTEXTタイプ {#code-mediumtext-code-type} +### MEDIUMTEXTタイプ {#mediumtext-type} @@ -68,7 +68,7 @@ TINYTEXT [CHARACTER SET charset_name] [COLLATE collation_name] MEDIUMTEXT [CHARACTER SET charset_name] [COLLATE collation_name] ``` -### LONGTEXT型 {#code-longtext-code-type} +### LONGTEXT型 {#longtext-type} @@ -85,7 +85,7 @@ MEDIUMTEXT [CHARACTER SET charset_name] [COLLATE collation_name] LONGTEXT [CHARACTER SET charset_name] [COLLATE collation_name] ``` -### BINARY型 {#code-binary-code-type} +### BINARY型 {#binary-type} `BINARY`型は[`CHAR`型](#char-type)と似ています。違いは、 `BINARY`バイナリバイト文字列を格納することです。 @@ -93,7 +93,7 @@ LONGTEXT [CHARACTER SET charset_name] [COLLATE collation_name] BINARY(M) ``` -### VARBINARY型 {#code-varbinary-code-type} +### VARBINARY型 {#varbinary-type} `VARBINARY`型は[`VARCHAR`型](#varchar-type)と似ています。違いは、 `VARBINARY`バイナリバイト文字列を格納するという点です。 @@ -101,7 +101,7 @@ BINARY(M) VARBINARY(M) ``` -### BLOB型 {#code-blob-code-type} +### BLOB型 {#blob-type} `BLOB`は大きなバイナリファイルです。M は列の最大長（バイト単位）を表し、範囲は 0 から 65,535 です。 @@ -109,7 +109,7 @@ VARBINARY(M) BLOB[(M)] ``` -### TINYBLOB型 {#code-tinyblob-code-type} +### TINYBLOB型 {#tinyblob-type} `TINYBLOB`型は[`BLOB`型](#blob-type)と似ていますが、 `TINYBLOB`の最大列長が255である点が異なります。 @@ -117,7 +117,7 @@ BLOB[(M)] TINYBLOB ``` -### MEDIUMBLOB型 {#code-mediumblob-code-type} +### MEDIUMBLOB型 {#mediumblob-type} @@ -134,7 +134,7 @@ TINYBLOB MEDIUMBLOB ``` -### LONGBLOB型 {#code-longblob-code-type} +### LONGBLOB型 {#longblob-type} @@ -151,7 +151,7 @@ MEDIUMBLOB LONGBLOB ``` -### ENUM型 {#code-enum-code-type} +### ENUM型 {#enum-type} `ENUM`は、テーブル作成時に列指定で明示的に列挙された許容値のリストから選択された値を持つ文字列オブジェクトです。構文は次のとおりです。 @@ -174,7 +174,7 @@ ENUM('apple', 'orange', 'pear') 詳細については[MySQLのENUM型](https://dev.mysql.com/doc/refman/8.0/en/enum.html)参照してください。 -### SET型 {#code-set-code-type} +### SET型 {#set-type} `SET` 、0 個以上の値を持つことができる文字列オブジェクトです。各値は、テーブルの作成時に指定された許可された値のリストから選択する必要があります。構文は次のとおりです。 diff --git a/develop/dev-guide-bookshop-schema-design.md b/develop/dev-guide-bookshop-schema-design.md index 1775bdba205bb..fc768d5d75f33 100644 --- a/develop/dev-guide-bookshop-schema-design.md +++ b/develop/dev-guide-bookshop-schema-design.md @@ -153,7 +153,7 @@ WHERE table_schema LIKE 'bookshop'; | price | DECIMAL(15,2) | 価格 | | published_at | DATETIME | 発行日 | -### authors一覧 {#code-authors-code-table} +### authors一覧 {#authors-table} この表には著者の基本情報が格納されています。 @@ -165,7 +165,7 @@ WHERE table_schema LIKE 'bookshop'; | birth_year | SMALLINT | 生年 | | death_year | SMALLINT | 死亡年 | -### usersテーブル {#code-users-code-table} +### usersテーブル {#users-table} このテーブルには、書店利用者の情報が格納されています。 @@ -175,7 +175,7 @@ WHERE table_schema LIKE 'bookshop'; | balance | DECIMAL(15,2) | バランス | | nickname | VARCHAR(100) | ニックネーム | -### ratings表 {#code-ratings-code-table} +### ratings表 {#ratings-table} このテーブルには、書籍に対するユーザー評価の記録が保存されています。 @@ -186,7 +186,7 @@ WHERE table_schema LIKE 'bookshop'; | score | TINYINT | ユーザー評価（1～5） | | rated_at | DATETIME | 評価時間 | -### book_authorsテーブル {#code-book-authors-code-table} +### book_authorsテーブル {#book_authors-table} 著者は複数の書籍を執筆することがあり、また、一冊の書籍に複数の著者が関わる場合もあります。この表は、書籍と著者間の対応関係を格納します。 @@ -195,7 +195,7 @@ WHERE table_schema LIKE 'bookshop'; | book_id | BIGINT | 書籍の固有ID（[本](#books-table)にリンク） | | author_id | BIGINT | 著者の固有ID（[著者](#authors-table)へのリンク） | -### ordersテーブル {#code-orders-code-table} +### ordersテーブル {#orders-table} このテーブルにはユーザーの購入情報が保存されます。 @@ -207,7 +207,7 @@ WHERE table_schema LIKE 'bookshop'; | quantity | TINYINT | 購入数量 | | ordered_at | DATETIME | 購入時間 | -## データベース初期化スクリプトdbinit.sql {#database-initialization-script-code-dbinit-sql-code} +## データベース初期化スクリプトdbinit.sql {#database-initialization-script-dbinitsql} Bookshopアプリケーションでデータベーステーブル構造を手動で作成する場合は、次のSQLステートメントを実行してください。 diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index cc1892edc14cc..0222fd06cc29b 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -160,7 +160,7 @@ OLTP（オンライン・トランザクション処理）シナリオでは、 > > バッチネットワーク転送を行う場合は、JDBC接続パラメータで`rewriteBatchedStatements = true`設定する必要があります。詳細なパラメータ設定については、 [バッチ関連パラメータ](#batch-related-parameters)参照してください。 -#### StreamingResultを使用して実行結果を取得します。 {#use-code-streamingresult-code-to-get-the-execution-result} +#### StreamingResultを使用して実行結果を取得します。 {#use-streamingresult-to-get-the-execution-result} ほとんどのシナリオでは、実行効率を向上させるために、JDBCはデフォルトでクエリ結果を事前に取得し、クライアントのメモリに保存します。しかし、クエリが非常に大きな結果セットを返す場合、クライアントはデータベースサーバーに一度に返されるレコード数を減らし、クライアントのメモリが準備できるまで待機し、次のバッチを要求することがよくあります。 diff --git a/develop/dev-guide-hybrid-oltp-and-olap-queries.md b/develop/dev-guide-hybrid-oltp-and-olap-queries.md index 1b5f05be998bc..8674b87332a96 100644 --- a/develop/dev-guide-hybrid-oltp-and-olap-queries.md +++ b/develop/dev-guide-hybrid-oltp-and-olap-queries.md @@ -39,7 +39,7 @@ FROM table_name ``` -### ORDER BY句 {#code-order-by-code-clause} +### ORDER BY句 {#order-by-clause} 集計ウィンドウ関数`sum()`を使用すると、特定の書籍の注文量の推移を分析できます。例えば、次のようになります。 @@ -80,7 +80,7 @@ ORDER BY month ASC; 上記のデータを、横軸に時間、縦軸に累計受注額を取った折れ線グラフで視覚化します。傾きの変化から、書籍の過去の受注傾向を簡単に把握できます。 -### PARTITION BY句 {#code-partition-by-code-clause} +### PARTITION BY句 {#partition-by-clause} さまざまな種類の書籍の過去の注文傾向を分析し、それを複数のシリーズを含む同じ折れ線グラフで視覚化したいとします。 diff --git a/develop/dev-guide-optimize-sql-best-practices.md b/develop/dev-guide-optimize-sql-best-practices.md index dad031a4c803e..bb3a36beacc28 100644 --- a/develop/dev-guide-optimize-sql-best-practices.md +++ b/develop/dev-guide-optimize-sql-best-practices.md @@ -34,7 +34,7 @@ DELETE FROM t WHERE id = 2; DELETE FROM t WHERE id = 3; ``` -### PREPARE使用する {#use-code-prepare-code} +### PREPARE使用する {#use-prepare} SQL ステートメントを複数回実行する必要がある場合は、SQL 構文を繰り返し解析することによるオーバーヘッドを回避するために、 `PREPARE`ステートメントを使用することをお勧めします。 @@ -103,7 +103,7 @@ SELECT title, price FROM books WHERE title = 'Marian Yost'; 大量のデータを更新する場合は[一括更新](/develop/dev-guide-update-data.md#bulk-update)使用することをお勧めします。 -### テーブルデータ全体を取得するには、 DELETEではなくTRUNCATE使用します。 {#use-code-truncate-code-instead-of-code-delete-code-for-full-table-data} +### テーブルデータ全体を取得するには、 DELETEではなくTRUNCATE使用します。 {#use-truncate-instead-of-delete-for-full-table-data} テーブルからすべてのデータを削除する必要がある場合は、 `TRUNCATE`ステートメントを使用することをお勧めします。 diff --git a/develop/dev-guide-update-data.md b/develop/dev-guide-update-data.md index 8dc3eca7d1295..716f1b742c4cf 100644 --- a/develop/dev-guide-update-data.md +++ b/develop/dev-guide-update-data.md @@ -19,7 +19,7 @@ aliases: ['/ja/tidb/stable/dev-guide-update-data/','/ja/tidb/dev/dev-guide-updat - [スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md)、データベース[データベースを作成する](/develop/dev-guide-create-database.md)、[テーブルを作成する](/develop/dev-guide-create-table.md)、 [セカンダリインデックスを作成する](/develop/dev-guide-create-secondary-indexes.md)読んでください。 - `UPDATE`データを取得したい場合は、最初に[データを挿入する](/develop/dev-guide-insert-data.md)必要があります。 -## UPDATEを使用する {#use-code-update-code} +## UPDATEを使用する {#use-update} テーブル内の既存の行を更新するには、更新対象の列をフィルタリングするために`WHERE`句を含む[`UPDATE`文](/sql-statements/sql-statement-update.md)使用する必要があります。 @@ -27,7 +27,7 @@ aliases: ['/ja/tidb/stable/dev-guide-update-data/','/ja/tidb/dev/dev-guide-updat > > 多数の行（例えば1万行以上）を更新する必要がある場合は、一度にすべてを更新するのではなく、すべての行が更新されるまで、一部ずつ繰り返し更新することをお***勧め***します。この操作をループさせるスクリプトやプログラムを作成できます。詳しくは[一括更新](#bulk-update)ご覧ください。 -### UPDATE SQL構文 {#code-update-code-sql-syntax} +### UPDATE SQL構文 {#update-sql-syntax} SQLでは、 `UPDATE`ステートメントは一般的に次の形式になります。 @@ -45,14 +45,14 @@ UPDATE {table} SET {update_column} = {update_value} WHERE {filter_column} = {fil 詳細については、 [UPDATE構文](/sql-statements/sql-statement-update.md)を参照してください。 -### ベストプラクティスUPDATE {#code-update-code-best-practices} +### ベストプラクティスUPDATE {#update-best-practices} データ更新に関するベストプラクティスを以下に示します。 - `WHERE`ステートメントには、必ず`UPDATE`句を指定してください。 `UPDATE`ステートメントに`WHERE`句がない場合、TiDB はテーブル内の***すべての行***を更新します。 - 大量の行 (たとえば、1 万行以上) を更新する必要がある場合は[一括更新](#bulk-update)を使用します。 TiDB は 1 つのトランザクションのサイズを制限しているため ( [トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)、一度にあまりにも多くのデータ更新が行われると、長時間ロックが保持されすぎたり ([悲観的トランザクション](/pessimistic-transaction.md))、競合が発生したり ([楽観的トランザクション](/optimistic-transaction.md)) されます。 -### UPDATE例 {#code-update-code-example} +### UPDATE例 {#update-example} [著者](/develop/dev-guide-bookshop-schema-design.md#authors-table)が名前を**ヘレン・ハルキ**に変更したとします。テーブルを変更する必要があります。彼女の固有の`id`が**1で**あると仮定すると、フィルターは`id = 1`になります。 @@ -82,11 +82,11 @@ try (Connection connection = ds.getConnection()) { -## INSERT ON DUPLICATE KEY UPDATE使用する {#use-code-insert-on-duplicate-key-update-code} +## INSERT ON DUPLICATE KEY UPDATE使用する {#use-insert-on-duplicate-key-update} テーブルに新しいデータを挿入する必要があるが、一意キー（主キーも一意キーです）の競合がある場合、最初に競合したレコードが更新されます。挿入または更新には`INSERT ... ON DUPLICATE KEY UPDATE ...`ステートメントを使用できます。 -### INSERT ON DUPLICATE KEY UPDATE SQL構文 {#code-insert-on-duplicate-key-update-code-sql-syntax} +### INSERT ON DUPLICATE KEY UPDATE SQL構文 {#insert-on-duplicate-key-update-sql-syntax} SQLでは、 `INSERT ... ON DUPLICATE KEY UPDATE ...`ステートメントは一般的に次の形式になります。 @@ -103,12 +103,12 @@ INSERT INTO {table} ({columns}) VALUES ({values}) | `{update_column}` | 更新するカラム名 | | `{update_value}` | 更新するカラムの値 | -### INSERT ON DUPLICATE KEY UPDATEベストプラクティス {#code-insert-on-duplicate-key-update-code-best-practices} +### INSERT ON DUPLICATE KEY UPDATEベストプラクティス {#insert-on-duplicate-key-update-best-practices} - `INSERT ON DUPLICATE KEY UPDATE`は、一意キーが 1 つだけのテーブルでのみ使用してください。このステートメントは***、一意キー***(主キーを含む) の競合が検出された場合、データを更新します。競合する行が複数ある場合、更新されるのは 1 行のみです。したがって、競合する行が 1 つだけであることを保証できない限り、一意キーが複数あるテーブルで`INSERT ON DUPLICATE KEY UPDATE`ステートメントを使用することはお勧めしません。 - データを作成または更新する際に、このステートメントを使用してください。 -### INSERT ON DUPLICATE KEY UPDATE例 {#code-insert-on-duplicate-key-update-code-example} +### INSERT ON DUPLICATE KEY UPDATE例 {#insert-on-duplicate-key-update-example} 例えば、 [評価](/develop/dev-guide-bookshop-schema-design.md#ratings-table)テーブルを更新して、ユーザーが書籍に付けた評価を含める必要があるとします。ユーザーがまだ書籍を評価していない場合は、新しい評価が作成されます。ユーザーが既に評価している場合は、以前の評価が更新されます。 diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index d998b339c1257..d1831782ba7b3 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -58,7 +58,7 @@ OLTP (オンライン トランザクション処理) シナリオの場合、 > > ネットワーク転送をバッチ処理する場合は、JDBC 接続パラメータで`rewriteBatchedStatements = true`を構成する必要があります。詳細なパラメータ設定については、[バッチ関連パラメータ](#batch-related-parameters)を参照してください。 -#### StreamingResultを使用して実行結果を取得します。 {#use-code-streamingresult-code-to-get-the-execution-result} +#### StreamingResultを使用して実行結果を取得します。 {#use-streamingresult-to-get-the-execution-result} ほとんどのシナリオでは、実行効率を向上させるために、JDBCはデフォルトでクエリ結果を事前に取得し、クライアントのメモリに保存します。しかし、クエリが非常に大きな結果セットを返す場合、クライアントはデータベースサーバーに一度に返されるレコード数を減らし、クライアントのメモリが準備できるまで待機し、次のバッチを要求することがよくあります。 @@ -382,7 +382,7 @@ jstackを複数回使用することで、スタックしている問題（例 - `printf "%x\n" pid`を使用して、スレッド ID を 16 進数に変換します。 - jstackの出力結果を確認すると、対応するスレッドのスタック情報が表示されます。 -#### jmap & mat {#jmap-x26-mat} +#### jmap & mat {#jmap--mat} Go の pprof/heap とは異なり、 [jmap](https://docs.oracle.com/javase/7/docs/technotes/tools/share/jmap.html)プロセス全体のメモリスナップショットをダンプし (Go ではディストリビュータのサンプリング)、その後、スナップ[Eclipse MAT](https://www.eclipse.org/mat/)を別のツールで分析できます。 diff --git a/dm/dm-compatibility-catalog.md b/dm/dm-compatibility-catalog.md index 49dab7c2ea3a1..897018e8f4bcb 100644 --- a/dm/dm-compatibility-catalog.md +++ b/dm/dm-compatibility-catalog.md @@ -27,7 +27,7 @@ DMは、さまざまなソースからTiDBクラスタへのデータ移行を | MariaDB 10.1.2 ～ 10.5.10 | Experimental | | | MariaDB > 10.5.10 | テストされていません | [事前チェック](/dm/dm-precheck.md)をバイパスした後は、ほとんどの場合に機能すると予想されます。 [MariaDBに関する注記](#mariadb-notes)参照してください。 | -### 外部キーのCASCADE操作 {#foreign-key-code-cascade-code-operations} +### 外部キーのCASCADE操作 {#foreign-key-cascade-operations} > **Warning:** > diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md index 131fe19e62965..f1e10d88ca545 100644 --- a/dm/dm-error-handling.md +++ b/dm/dm-error-handling.md @@ -105,22 +105,22 @@ DM の実行中にエラーが発生した場合は、次の手順に従って | `code=32001` | 異常ダンプ処理装置 | エラーメッセージに`mydumper: argument list too long.`が含まれている場合は、ブロック/許可リストに従って、 `task.yaml`ファイルの Mydumper 引数`extra-args`に`--regex`正規表現を手動で追加して、エクスポートするテーブルを設定します。例えば、 `hello`という名前のテーブルをすべてエクスポートするには`--regex '.*\\.hello$'`を追加し、すべてのテーブルをエクスポートするには`--regex '.*'`を追加します。 | | `code=38008` | DM コンポーネント間の gRPC 通信でエラーが発生します。 | チェック`class` ：どのコンポーネントの相互作用でエラーが発生しているかを確認します。通信エラーの種類を特定します。gRPC接続の確立時にエラーが発生する場合は、通信サーバーが正常に動作しているかどうかを確認します。 | -### invalid connectionエラーが返され、移行タスクが中断された場合、どうすればよいですか? {#what-can-i-do-when-a-migration-task-is-interrupted-with-the-code-invalid-connection-code-error-returned} +### invalid connectionエラーが返され、移行タスクが中断された場合、どうすればよいですか? {#what-can-i-do-when-a-migration-task-is-interrupted-with-the-invalid-connection-error-returned} -#### 理由 {#reason} +#### 理由 {#reason-1} エラー`invalid connection`は、DM と下流の TiDB データベース間の接続に異常 (ネットワーク障害、TiDB の再起動、TiKV のビジー状態など) が発生し、現在の要求のデータの一部が TiDB に送信されたことを示します。 -#### ソリューション {#solutions} +#### ソリューション {#solutions-1} DMは移行タスクにおいてデータを下流へ並行して移行する機能を備えているため、タスクが中断されると様々なエラーが発生する可能性があります。これらのエラーは`query-status`使用して確認できます。 - 増分レプリケーション プロセス中に`invalid connection`エラーのみが発生した場合、DM はタスクを自動的に再試行します。 - バージョンの問題により DM が自動的に再試行されない場合、または再試行に失敗した場合は、 `stop-task`使用してタスクを停止し、 `start-task`使用してタスクを再起動します。 -### 移行タスクがdriver: bad connectionエラーが返されました {#a-migration-task-is-interrupted-with-the-code-driver-bad-connection-code-error-returned} +### 移行タスクがdriver: bad connectionエラーが返されました {#a-migration-task-is-interrupted-with-the-driver-bad-connection-error-returned} -#### 理由 {#reason} +#### 理由 {#reason-2} エラー`driver: bad connection`は、DM と上流の TiDB データベース間の接続に異常 (ネットワーク障害や TiDB の再起動など) が発生し、その時点では現在のリクエストのデータがまだ TiDB に送信されていないことを示します。 @@ -128,7 +128,7 @@ DMは移行タスクにおいてデータを下流へ並行して移行する機 現在のバージョンのDMは、エラー発生時に自動的に再試行します。自動再試行をサポートしていない以前のバージョンをご利用の場合は、コマンド`stop-task`を実行してタスクを停止し、その後コマンド`start-task`実行してタスクを再開してください。 -### リレーユニットはevent from * in * diff from passed-in event *スローするか、または、 binlogエラーの取得または解析に失敗して移行タスクが中断され、binlog get binlog error ERROR 1236 (HY000)やbinlog checksum mismatch, data may be corrupted 。 {#the-relay-unit-throws-error-code-event-from-in-diff-from-passed-in-event-code-or-a-migration-task-is-interrupted-with-failing-to-get-or-parse-binlog-errors-like-code-get-binlog-error-error-1236-hy000-code-and-code-binlog-checksum-mismatch-data-may-be-corrupted-code-returned} +### リレーユニットはevent from * in * diff from passed-in event *スローするか、または、 binlogエラーの取得または解析に失敗して移行タスクが中断され、binlog get binlog error ERROR 1236 (HY000)やbinlog checksum mismatch, data may be corrupted 。 {#the-relay-unit-throws-error-event-from--in--diff-from-passed-in-event--or-a-migration-task-is-interrupted-with-failing-to-get-or-parse-binlog-errors-like-get-binlog-error-error-1236-hy000-and-binlog-checksum-mismatch-data-may-be-corrupted-returned} #### 理由 {#reason} @@ -136,7 +136,7 @@ DMは移行タスクにおいてデータを下流へ並行して移行する機 **原因：**リレーログを書き込む際、DMはbinlogの位置とbinlogファイルのサイズに基づいてイベント検証を行い、複製されたbinlogの位置をチェックポイントとして保存する必要があります。しかし、公式のMySQLではbinlogの位置を`uint32`保存しています。そのため、4GBを超えるbinlogファイルのbinlogの位置がオーバーフローし、上記のエラーが発生します。 -#### ソリューション {#solutions} +#### ソリューション {#solutions-2} リレー ユニットの場合は、次のソリューションを使用して手動で移行を回復します。 @@ -172,13 +172,13 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ 6. `query-status`使用して移行タスクのステータスを確認する。元のエラーの原因となったリレーログファイルの移行が完了したら、 `safe-mode`元の値に戻して移行タスクを再開できます。 -### タスクをクエリするかログを確認すると、 Access denied for user 'root'@'172.31.43.27' (using password: YES)表示されます。 {#code-access-denied-for-user-root-172-31-43-27-using-password-yes-code-shows-when-you-query-the-task-or-check-the-log} +### タスクをクエリするかログを確認すると、 Access denied for user 'root'@'172.31.43.27' (using password: YES)表示されます。 {#access-denied-for-user-root172314327-using-password-yes-shows-when-you-query-the-task-or-check-the-log} すべてのDM設定ファイルにおけるデータベース関連のパスワードについては、 `dmctl`で暗号化したパスワードを使用することをお勧めします。データベースパスワードが空の場合は、暗号化する必要はありません。プレーンテキストパスワードの暗号化方法については、 [dmctlを使用してデータベースパスワードを暗号化する](/dm/dm-manage-source.md#encrypt-the-database-password)参照してください。 さらに、上流データベースと下流データベースのユーザーには、対応する読み取り権限と書き込み権限が必要です。データ移行タスクを開始する際には、データ移行も[対応する権限を自動的に事前チェックします](/dm/dm-precheck.md)必要です。 -### load処理ユニットからpacket for query is too large. Try adjusting the 'max_allowed_packet' variable {#the-code-load-code-processing-unit-reports-the-error-code-packet-for-query-is-too-large-try-adjusting-the-max-allowed-packet-variable-code} +### load処理ユニットからpacket for query is too large. Try adjusting the 'max_allowed_packet' variable {#the-load-processing-unit-reports-the-error-packet-for-query-is-too-large-try-adjusting-the-max_allowed_packet-variable} #### 理由 {#reasons} diff --git a/dm/dm-faq.md b/dm/dm-faq.md index f610439f922af..419af615a9a5a 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -18,7 +18,7 @@ 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)参照してください。 -## タスク構成のブロックおよび許可リストの正規表現は、 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)参照してください。 @@ -51,7 +51,7 @@ TiDBでサポートされていないDDL文に遭遇した場合は、dmctlを - タスク設定ファイルで新しいタスク名を指定します。次に、 `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は前回のチェックポイントから増分レプリケーションを継続します。 @@ -118,24 +118,24 @@ MySQLはエクスポート時にスナップショットを指定できないた 5. `query-status`までタスクの状態を観察します。3 `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} このエラーをさらに分析するには、エラーメッセージとログファイルを確認してください。原因としては、権限不足のためにダンプユニットが正しいメタデータファイルを生成していないことが考えられます。 @@ -146,15 +146,15 @@ DM v2.0 以降、増分データレプリケーションを続行するために - `block-allow-list`下にある上流のデータベースとテーブルの名前を設定する必要があります。3 `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,11 +173,11 @@ 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)参照してください。 -## 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 `使用して、これらの文に一致するパターンを設定できます。 @@ -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つです。 @@ -243,7 +243,7 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する 4. フォルダー`deploy/grafana-$port/bin/public` `grafana-v4.0.3-**.tar.gz`のフォルダー`public`に置き換えます。 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つの条件が同時に満たされた場合に発生します。 @@ -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)を使用して下流で事前にテーブルスキーマを作成してください。 diff --git a/dm/dm-safe-mode.md b/dm/dm-safe-mode.md index 0246e84eadbea..11930a848f46b 100644 --- a/dm/dm-safe-mode.md +++ b/dm/dm-safe-mode.md @@ -91,7 +91,7 @@ DMがチェックポイントから増分レプリケーションタスクを再 # Other configuration items are not provided in this example. syncer-config-name: "global" # Name of the syncers configuration. -## 外部キーの処理（v8.5.6の新機能） {#foreign-key-handling-span-class-version-mark-new-in-v8-5-6-span} +## 外部キーの処理（v8.5.6の新機能） {#foreign-key-handling-new-in-v856} > **Warning:** > @@ -99,7 +99,7 @@ DMがチェックポイントから増分レプリケーションタスクを再 セーフ モードを有効にしてダウンストリーム タスク セッションで`foreign_key_checks=1`を設定すると、 `DELETE`ステートメントのデフォルトの`REPLACE` + `UPDATE`書き換えにより、子行に意図しない`ON DELETE CASCADE`影響が発生する可能性があります。v8.5.6 以降、DM ではこの問題に対処するために以下の改善が導入されています。 -### 非キーUPDATE最適化 {#non-key-code-update-code-optimization} +### 非キーUPDATE最適化 {#non-key-update-optimization} 主キーまたは一意キーの値を変更しない`UPDATE`ステートメントの場合、DM は`DELETE`ステップをスキップし、 `REPLACE INTO`のみを実行します。主キーは変更されないため、 `REPLACE INTO`外部キーのカスケード削除をトリガーすることなく既存の行を上書きします。この最適化はセーフモードで自動的に適用されます。 @@ -126,7 +126,7 @@ REPLACE INTO dummydb.dummytbl (id, int_value, ...) VALUES (123, 888999, ...); - > > `foreign_key_checks=1`の場合、DM は主キーまたは一意キーの値を変更する`UPDATE`ステートメントの複製をサポートしません。この場合、複製タスクはエラー`safe-mode update with foreign_key_checks=1 and PK/UK changes is not supported`で一時停止されます。外部キーを持つテーブルでそのような`UPDATE`ステートメントを複製するには、 `safe-mode: false`を設定します。 -### セッションレベルのforeign_key_checks {#session-level-code-foreign-key-checks-code} +### セッションレベルのforeign_key_checks {#session-level-foreign_key_checks} セーフモードでのバッチ実行中、DM は`SET SESSION foreign_key_checks=0`および`INSERT`バッチを実行する前に`UPDATE`を実行し、その後`foreign_key_checks`の元の値を復元します。これにより`REPLACE INTO` (内部で`DELETE` + `INSERT`を実行) が下流で外部キーのカスケード操作をトリガーするのを防ぎます。 diff --git a/dm/maintain-dm-using-tiup.md b/dm/maintain-dm-using-tiup.md index 7959a96a1c879..5f5645780789f 100644 --- a/dm/maintain-dm-using-tiup.md +++ b/dm/maintain-dm-using-tiup.md @@ -237,7 +237,7 @@ tiup dm patch prod-cluster /tmp/dm-master-hotfix.tar.gz -R dm-master tiup dm patch prod-cluster /tmp/dm--hotfix.tar.gz -N 172.16.4.5:8261 ``` -## DM-Ansible を使用してデプロイされた DM 1.0 クラスターをインポートおよびアップグレードする {#import-and-upgrade-a-dm-1-0-cluster-deployed-using-dm-ansible} +## DM-Ansible を使用してデプロイされた DM 1.0 クラスターをインポートおよびアップグレードする {#import-and-upgrade-a-dm-10-cluster-deployed-using-dm-ansible} > **Note:** > @@ -339,7 +339,7 @@ dmctlのバージョンを指定します。このコマンドを実行する前 tiup dmctl --master-addr master1:8261 operate-source create /tmp/source1.yml ``` -## システムのネイティブSSHクライアントを使用してクラスタに接続します {#use-the-system-s-native-ssh-client-to-connect-to-cluster} +## システムのネイティブSSHクライアントを使用してクラスタに接続します {#use-the-systems-native-ssh-client-to-connect-to-cluster} クラスタマシン上で実行される上記のすべての操作は、 TiUPに組み込まれたSSHクライアントを使用してクラスタに接続し、コマンドを実行します。ただし、シナリオによっては、制御マシンシステムにネイティブなSSHクライアントを使用してクラスタ操作を実行する必要がある場合もあります。例： diff --git a/dm/manually-upgrade-dm-1.0-to-2.0.md b/dm/manually-upgrade-dm-1.0-to-2.0.md index ae9c2059764db..cca02d4f02fcc 100644 --- a/dm/manually-upgrade-dm-1.0-to-2.0.md +++ b/dm/manually-upgrade-dm-1.0-to-2.0.md @@ -3,7 +3,7 @@ title: Manually Upgrade TiDB Data Migration from v1.0.x to v2.0+ summary: TiDB Data Migrationをv1.0.xからv2.0+へ手動でアップグレードする方法を学びましょう。 --- -# TiDB Data Migrationをv1.0.xからv2.0+へ手動でアップグレードする {#manually-upgrade-tidb-data-migration-from-v1-0-x-to-v2-0} +# TiDB Data Migrationをv1.0.xからv2.0+へ手動でアップグレードする {#manually-upgrade-tidb-data-migration-from-v10x-to-v20} このドキュメントでは、TiDB DMツールをv1.0.xからv2.0+に手動でアップグレードする方法について説明します。主な手順は、v1.0.xのグローバルチェックポイント情報を使用して、v2.0+クラスタで新しいデータ移行タスクを開始することです。 @@ -19,7 +19,7 @@ TiDB DM ツールを v1.0.x から v2.0+ に自動的にアップグレードす 手動アップグレードの手順は以下のとおりです。 -## ステップ1：v2.0+設定ファイルを準備する {#step-1-prepare-v2-0-configuration-file} +## ステップ1：v2.0+設定ファイルを準備する {#step-1-prepare-v20-configuration-file} バージョン2.0以降で準備された構成ファイルには、上流データベースの構成ファイルとデータ移行タスクの構成ファイルが含まれています。 @@ -31,7 +31,7 @@ v2.0以降では、[アップストリームデータベース構成ファイル > > v1.0.x から v2.0+ へのアップグレード中にソース構成の`enable-gtid`が有効になっている場合、 binlogまたはリレーログファイルを解析して、 binlog の位置に対応する GTID セットを取得する必要があります。 -#### DM-Ansibleによってデプロイされたv1.0.xクラスターをアップグレードする {#upgrade-a-v1-0-x-cluster-deployed-by-dm-ansible} +#### DM-Ansibleによってデプロイされたv1.0.xクラスターをアップグレードする {#upgrade-a-v10x-cluster-deployed-by-dm-ansible} v1.0.x DM クラスターが DM-Ansible によってデプロイされ、 `dm_worker_servers`ファイルに次の`inventory.ini`設定が含まれていると仮定します。 @@ -65,7 +65,7 @@ from: password: "VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU=" # Corresponds to the original `mysql_password`. ``` -#### バイナリによってデプロイされたv1.0.xクラスターをアップグレードする {#upgrade-a-v1-0-x-cluster-deployed-by-binary} +#### バイナリによってデプロイされたv1.0.xクラスターをアップグレードする {#upgrade-a-v10x-cluster-deployed-by-binary} v1.0.x DM クラスターがバイナリによってデプロイされ、対応する DM-worker 構成が以下のようになっていると仮定します。 @@ -100,7 +100,7 @@ from: [データ移行タスク構成ガイド](/dm/dm-task-configuration-guide.md)については、v2.0+ は基本的に v1.0.x と互換性があります。 v1.0.x の設定を直接コピーできます。 -## ステップ2：v2.0+クラスターをデプロイ {#step-2-deploy-the-v2-0-cluster} +## ステップ2：v2.0+クラスターをデプロイ {#step-2-deploy-the-v20-cluster} > **Note:** > @@ -108,7 +108,7 @@ from: [TiUPを使用する](/dm/deploy-a-dm-cluster-using-tiup.md)必要なノード数に応じて新しい v2.0+ クラスターをデプロイします。 -## ステップ3：v1.0.xクラスタを停止します {#step-3-stop-the-v1-0-x-cluster} +## ステップ3：v1.0.xクラスタを停止します {#step-3-stop-the-v10x-cluster} 元の v1.0.x クラスターが DM-Ansible によってデプロイされている場合は、 [DM-Ansibleを使用してv1.0.xクラスタを停止します](https://docs-archive.pingcap.com/tidb-data-migration/v1.0/cluster-operations#stop-a-cluster) 。 diff --git a/dm/shard-merge-best-practices.md b/dm/shard-merge-best-practices.md index a880affb0e779..f1431213a7e08 100644 --- a/dm/shard-merge-best-practices.md +++ b/dm/shard-merge-best-practices.md @@ -38,7 +38,7 @@ summary: シャードマージのシナリオにおけるデータ移行のベ このセクションでは、AUTO_INCREMENT主キーの競合を処理するための 2 つの推奨ソリューションを紹介します。 -### 列からPRIMARY KEY属性を削除します {#remove-the-code-primary-key-code-attribute-from-the-column} +### 列からPRIMARY KEY属性を削除します {#remove-the-primary-key-attribute-from-the-column} アップストリーム スキーマが次のとおりであると仮定します。 @@ -121,7 +121,7 @@ CREATE TABLE `tbl_multi_pk` ( アップストリームデータソースがRDSで、シャーディングされたテーブルが含まれている場合、SQLクライアントへの接続時にMySQL binlog内のテーブル名が表示されないことがあります。例えば、アップストリームがUCloud分散データベースの場合、 binlog内のテーブル名にプレフィックス`_0001`が付加されることがあります。そのため、SQLクライアントのテーブル名ではなく、 binlog内のテーブル名に基づいて[テーブルルーティング](/dm/dm-table-routing.md)を設定する必要があります。 -## アップストリームでテーブルを作成/削除する {#create-drop-tables-in-the-upstream} +## アップストリームでテーブルを作成/削除する {#createdrop-tables-in-the-upstream} [シャードテーブルからのデータのマージと移行](/dm/feature-shard-merge-pessimistic.md#principles)では、シャーディングDDLロックの調整は、下流データベースが上流のすべてのシャードテーブルのDDL文を受信したかどうかに依存することが明らかです。また、DMは現在、上流におけるシャードテーブルの動的な作成または削除**をサポートしていません**。したがって、上流でシャードテーブルを作成または削除するには、以下の手順を実行することをお勧めします。 diff --git a/enable-tls-between-components.md b/enable-tls-between-components.md index 5eece87095698..f949a793546fd 100644 --- a/enable-tls-between-components.md +++ b/enable-tls-between-components.md @@ -143,7 +143,7 @@ summary: TiDB コンポーネント間の TLS 認証を有効にする方法を ./tikv-ctl --host="127.0.0.1:20160" --ca-path="/path/to/ca.pem" --cert-path="/path/to/client.pem" --key-path="/path/to/clinet-key.pem" ``` -### コンポーネント呼び出し元のIDを確認する {#verify-component-caller-s-identity} +### コンポーネント呼び出し元のIDを確認する {#verify-component-callers-identity} 一般的に、呼び出し先は、呼び出し元が提供する鍵、証明書、およびCAを検証するだけでなく、 `Common Name`を使用して呼び出し元のIDを検証する必要があります。例えば、TiKVはTiDBのみがアクセスでき、他の訪問者は正当な証明書を持っていてもブロックされます。 diff --git a/explain-indexes.md b/explain-indexes.md index 7ec1a7286619c..5a927e6c5d853 100644 --- a/explain-indexes.md +++ b/explain-indexes.md @@ -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`よりも効率的です。例えば、 diff --git a/explain-subqueries.md b/explain-subqueries.md index 0e9e7f467dc7f..045af71a03d5f 100644 --- a/explain-subqueries.md +++ b/explain-subqueries.md @@ -123,7 +123,7 @@ EXPLAIN SELECT * FROM t1 WHERE id IN (SELECT t1_id FROM t2 WHERE t1_id != t1.int 元の文は*相関サブクエリ*とみなされます。これは、サブクエリがサブクエリの外部に存在する列 ( `t1.int_col` ) を参照しているためです。ただし、 `EXPLAIN`の出力は、 [サブクエリの相関除去最適化](/correlated-subquery-optimization.md)適用した後の実行プランを示しています。条件`t1_id != t1.int_col`は`t1.id != t1.int_col`に書き換えられます。TiDB はテーブル`t1`からデータを読み取る際に`└─Selection_21`でこれを実行できるため、この相関関係の除去と書き換えによって実行効率が大幅に向上します。 -## アンチセミジョイン（サブクエリNOT IN ） {#anti-semi-join-code-not-in-code-subquery} +## アンチセミジョイン（サブクエリNOT IN ） {#anti-semi-join-not-in-subquery} 次の例では、サブクエリに`t3.t1_id`が含まれてい*ない限り、*クエリは意味的にテーブル`t3`のすべての行を返します。 @@ -146,7 +146,7 @@ EXPLAIN SELECT * FROM t3 WHERE t1_id NOT IN (SELECT id FROM t1 WHERE int_col < 1 このクエリは、まずテーブル`t3`読み取り、次にテーブル`t1` `PRIMARY KEY`に基づいてプローブを実行します。結合タイプは*アンチセミ結合*です。この例は値 ( `NOT IN` ) が存在しないことを想定しているためアンチ結合、結合を拒否するには最初の行のみが一致する必要があるためセミ結合です。 -## Null 対応セミ結合 ( INおよび= ANYサブクエリ) {#null-aware-semi-join-code-in-code-and-code-any-code-subqueries} +## Null 対応セミ結合 ( INおよび= ANYサブクエリ) {#null-aware-semi-join-in-and--any-subqueries} `IN`または`= ANY`集合演算子の値は3つの値（ `true` 、 `false` 、 `NULL` ）です。2つの演算子のいずれかから変換された結合型の場合、TiDBは結合キーの両側にある`NULL`を認識し、特別な方法で処理する必要があります。 @@ -196,7 +196,7 @@ tidb> EXPLAIN SELECT * FROM t WHERE (a,b) IN (SELECT * FROM s); > > `Exists`演算子もセミ結合に変換されますが、null を認識しません。 -## Null 対応アンチセミ結合 ( NOT INかつ!= ALLサブクエリ) {#null-aware-anti-semi-join-code-not-in-code-and-code-all-code-subqueries} +## Null 対応アンチセミ結合 ( NOT INかつ!= ALLサブクエリ) {#null-aware-anti-semi-join-not-in-and--all-subqueries} `NOT IN`または`!= ALL`集合演算子の値は3つの値（ `true` 、 `false` 、 `NULL` ）です。2つの演算子のいずれかから変換された結合型の場合、TiDBは結合キーの両側にある`NULL`を認識し、特別な方法で処理する必要があります。 diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md index 072ff14e2432a..477c4d11aaaa5 100644 --- a/faq/backup-and-restore-faq.md +++ b/faq/backup-and-restore-faq.md @@ -3,7 +3,7 @@ title: Backup & Restore FAQs summary: よくある質問 (FAQ) とバックアップおよび復元のソリューションについて説明します。 --- -# バックアップと復元に関するよくある質問 {#backup-x26-restore-faqs} +# バックアップと復元に関するよくある質問 {#backup--restore-faqs} このドキュメントには、TiDB バックアップ & 復元 (BR) に関するよくある質問 (FAQ) と解決策が記載されています。 @@ -11,7 +11,7 @@ summary: よくある質問 (FAQ) とバックアップおよび復元のソリ TiDB v6.4.0では、フラッシュバック機能が導入されました。この機能を使用すると、GC時間内に特定の時点までデータを迅速に復旧できます。そのため、誤操作が発生した場合でも、この機能を使用してデータを復旧できます。詳細は[フラッシュバッククラスタ](/sql-statements/sql-statement-flashback-cluster.md)と[フラッシュバックデータベース](/sql-statements/sql-statement-flashback-database.md)参照してください。 -## TiDB v5.4.0 以降のバージョンでは、ワークロードが高いクラスターでバックアップ タスクを実行すると、バックアップ タスクの速度が遅くなるのはなぜですか? {#in-tidb-v5-4-0-and-later-versions-when-backup-tasks-are-performed-on-the-cluster-under-a-heavy-workload-why-does-the-speed-of-backup-tasks-become-slow} +## TiDB v5.4.0 以降のバージョンでは、ワークロードが高いクラスターでバックアップ タスクを実行すると、バックアップ タスクの速度が遅くなるのはなぜですか? {#in-tidb-v540-and-later-versions-when-backup-tasks-are-performed-on-the-cluster-under-a-heavy-workload-why-does-the-speed-of-backup-tasks-become-slow} TiDB v5.4.0以降、 BRはバックアップタスクの自動チューニング機能を導入しました。v5.4.0以降のバージョンのクラスターでは、この機能はデフォルトで有効になっています。クラスターのワークロードが高い場合、この機能はバックアップタスクで使用されるリソースを制限し、オンラインクラスターへの影響を軽減します。詳細については、 [バックアップオートチューン](/br/br-auto-tune.md)を参照してください。 @@ -28,7 +28,7 @@ TiKVは[動的構成](/tikv-control.md#modify-the-tikv-configuration-dynamically ## PITRの問題 {#pitr-issues} -### PITRとクラスターフラッシュバックの違いは何ですか? {#what-is-the-difference-between-a-href-br-br-pitr-guide-md-pitr-a-and-a-href-sql-statements-sql-statement-flashback-cluster-md-cluster-flashback-a} +### PITRとクラスターフラッシュバックの違いは何ですか? {#what-is-the-difference-between-pitrbrbr-pitr-guidemd-and-cluster-flashbacksql-statementssql-statement-flashback-clustermd} ユースケースの観点から見ると、PITRは通常、クラスターが完全にサービス停止状態になった場合、またはデータが破損して他のソリューションでは復旧できない場合に、クラスターのデータを特定の時点に復元するために使用されます。PITRを使用するには、データ復旧用の新しいクラスターが必要です。クラスターのフラッシュバック機能は、ユーザーの誤操作やその他の要因によって発生するデータエラーのシナリオ向けに特別に設計されており、データエラーが発生する前の最新のタイムスタンプにクラスターのデータをインプレースで復元できます。 @@ -48,11 +48,11 @@ TiKVは[動的構成](/tikv-control.md#modify-the-tikv-configuration-dynamically この問題を解決するには、 `br log resume`コマンドを手動で実行して、ログ バックアップ タスクを再開する必要があります。 -## br restore pointコマンドを使用してダウンストリームクラスターを復元した後、 TiFlashからデータにアクセスできなくなりました。どうすればよいでしょうか？ {#after-restoring-a-downstream-cluster-using-the-code-br-restore-point-code-command-data-cannot-be-accessed-from-tiflash-what-should-i-do} +## br restore pointコマンドを使用してダウンストリームクラスターを復元した後、 TiFlashからデータにアクセスできなくなりました。どうすればよいでしょうか？ {#after-restoring-a-downstream-cluster-using-the-br-restore-point-command-data-cannot-be-accessed-from-tiflash-what-should-i-do} 現在、PITRはリストアフェーズ中にTiFlashへの直接データ書き込みをサポートしていません。代わりに、brコマンドラインツールが`ALTER TABLE table_name SET TIFLASH REPLICA ***` DDLを実行してデータを複製します。そのため、PITRによるデータリストアが完了した直後にTiFlashレプリカは利用できません。TiKVノードからデータが複製されるまで、一定時間待つ必要があります。レプリケーションの進行状況を確認するには、 `INFORMATION_SCHEMA.tiflash_replica`番目の表の`progress`情報を確認してください。 -### ログ バックアップ タスクのstatusがERRORになった場合はどうすればよいでしょうか? {#what-should-i-do-if-the-code-status-code-of-a-log-backup-task-becomes-code-error-code} +### ログ バックアップ タスクのstatusがERRORになった場合はどうすればよいでしょうか? {#what-should-i-do-if-the-status-of-a-log-backup-task-becomes-error} ログバックアップタスクの実行中に、タスクが失敗し、再試行しても回復できない場合、タスクステータスは`ERROR`になります。以下に例を示します。 @@ -97,7 +97,7 @@ checkpoint[global]: 2022-07-25 14:46:50.118 +0000; gap=6m28s > > この機能は、複数のバージョンのデータをバックアップします。長時間のバックアップタスクが失敗し、ステータスが`ERROR`になると、このタスクのチェックポイントデータは`safe point`に設定され、 `safe point`のデータは24時間以内にガベージコレクションされません。そのため、エラーからの再開後、バックアップタスクは最後のチェックポイントから続行されます。タスクが24時間以上失敗し、最後のチェックポイントデータがガベージコレクションされている場合、タスクを再開するとエラーが報告されます。この場合、まず`br log stop`コマンドを実行してタスクを停止し、新しいバックアップタスクを開始する必要があります。 -### br log resumeコマンドを使用して中断されたタスクを再開するときに、エラー メッセージErrBackupGCSafepointExceeded返された場合、どうすればよいですか? {#what-should-i-do-if-the-error-message-code-errbackupgcsafepointexceeded-code-is-returned-when-using-the-code-br-log-resume-code-command-to-resume-a-suspended-task} +### br log resumeコマンドを使用して中断されたタスクを再開するときに、エラー メッセージErrBackupGCSafepointExceeded返された場合、どうすればよいですか? {#what-should-i-do-if-the-error-message-errbackupgcsafepointexceeded-is-returned-when-using-the-br-log-resume-command-to-resume-a-suspended-task} ```shell Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepoint 433193092308795392 exceed TS 433177834291200000: [BR:Backup:ErrBackupGCSafepointExceeded]backup GC safepoint exceeded @@ -107,7 +107,7 @@ Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepo この問題を解決するには、 `br log stop`使用して現在のタスクを削除し、 `br log start`を使用してログバックアップタスクを作成します。同時に、後続の PITR のためにフルバックアップを実行できます。 -### PITR テーブル フィルターの使用時にエラー メッセージ[ddl:8204]invalid ddl job type: noneが返された場合はどうすればよいですか? {#what-should-i-do-if-the-error-message-code-ddl-8204-invalid-ddl-job-type-none-code-is-returned-when-using-the-pitr-table-filter} +### PITR テーブル フィルターの使用時にエラー メッセージ[ddl:8204]invalid ddl job type: noneが返された場合はどうすればよいですか? {#what-should-i-do-if-the-error-message-ddl8204invalid-ddl-job-type-none-is-returned-when-using-the-pitr-table-filter} ```shell failed to refresh meta for database with schemaID=124, dbName=pitr_test: [ddl:8204]invalid ddl job type: none @@ -125,7 +125,7 @@ failed to refresh meta for database with schemaID=124, dbName=pitr_test: [ddl:82 [`filter.rules`](https://github.com/pingcap/tiflow/blob/7c3c2336f98153326912f3cf6ea2fbb7bcc4a20c/cmd/changefeed.toml#L16)使用して、TiCDC のブロック リストを構成できます。 -### 復元中にnew_collation_enabled不一致が報告されるのはなぜですか? {#why-is-code-new-collation-enabled-code-mismatch-reported-during-restore} +### 復元中にnew_collation_enabled不一致が報告されるのはなぜですか? {#why-is-new_collation_enabled-mismatch-reported-during-restore} TiDB v6.0.0以降、デフォルト値の[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)は`false`から`true`に変更されました。BRは上流クラスタの`mysql.tidb`テーブルにある`new_collation_enabled`設定をバックアップし、この設定の値が上流クラスタと下流クラスタ間で一致しているかどうかを確認します。値が一致している場合、 BRは上流クラスタにバックアップされたデータを下流クラスタに安全に復元します。値が一致していない場合、 BRはデータの復元を実行せず、エラーを報告します。 @@ -140,7 +140,7 @@ v6.0.0より前では、 BRは[配置ルール](/placement-rules-in-sql.md)サ ## データ復元の問題 {#data-restore-issues} -### Io(Os...)エラーを処理するにはどうすればよいですか? {#what-should-i-do-to-handle-the-code-io-os-code-error} +### Io(Os...)エラーを処理するにはどうすればよいですか? {#what-should-i-do-to-handle-the-ioos-error} これらの問題のほとんどは、TiKV がディスクにデータを書き込むときに発生するシステム コール エラーです (例: `Io(Os {code: 13, kind: PermissionDenied...})`または`Io(Os {code: 2, kind: NotFound...})` )。 @@ -148,19 +148,19 @@ v6.0.0より前では、 BRは[配置ルール](/placement-rules-in-sql.md)サ たとえば、 `samba`で構築されたネットワーク ディスクにデータをバックアップするときに、 `Code: 22(invalid argument)`エラーが発生する可能性があります。 -### 復元中にrpc error: code = Unavailable desc =... error occurred in restore?」を処理するにはどうすればよいですか? {#what-should-i-do-to-handle-the-code-rpc-error-code-unavailable-desc-code-error-occurred-in-restore} +### 復元中にrpc error: code = Unavailable desc =... error occurred in restore?」を処理するにはどうすればよいですか? {#what-should-i-do-to-handle-the-rpc-error-code--unavailable-desc--error-occurred-in-restore} このエラーは、復元するクラスターの容量が不足している場合に発生する可能性があります。このクラスターの監視メトリックまたはTiKVログを確認することで、原因をさらに確認できます。 この問題に対処するには、クラスター リソースをスケール アウトし、復元の値`tikv-max-restore-concurrency`を減らして、オプション`ratelimit`を有効にしてみてください。 -### the entry too large, the max entry size is 6291456, the size of data is 7690800 」というエラー メッセージが表示されて復元が失敗した場合は、どうすればよいでしょうか。 {#what-should-i-do-if-the-restore-fails-with-the-error-message-code-the-entry-too-large-the-max-entry-size-is-6291456-the-size-of-data-is-7690800-code} +### the entry too large, the max entry size is 6291456, the size of data is 7690800 」というエラー メッセージが表示されて復元が失敗した場合は、どうすればよいでしょうか。 {#what-should-i-do-if-the-restore-fails-with-the-error-message-the-entry-too-large-the-max-entry-size-is-6291456-the-size-of-data-is-7690800} `--ddl-batch-size` ～ `128`またはそれより小さい値を設定することで、バッチで作成されるテーブルの数を減らすことができます。 BRを使用して[`--ddl-batch-size`](/br/br-batch-create-table.md#use-batch-create-table)の値が`1`より大きいバックアップ データを復元する場合、TiDB はテーブル作成の DDL ジョブを TiKV が管理する DDL ジョブ キューに書き込みます。このとき、ジョブ メッセージの最大値がデフォルトで`6 MB`であるため (この値を変更することは**推奨されません**。詳細については、 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)と[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)を参照してください)、TiDB が一度に送信するすべてのテーブル スキーマの合計サイズは 6 MB を超えてはなりません。したがって、 `--ddl-batch-size`過度に大きな値に設定すると、TiDB が一度にバッチで送信するテーブルのスキーマ サイズが指定値を超え、 BR が`entry too large, the max entry size is 6291456, the size of data is 7690800`エラーを報告します。 -### localストレージを使用する場合、バックアップされたファイルはどこに保存されますか? {#where-are-the-backed-up-files-stored-when-i-use-code-local-code-storage} +### localストレージを使用する場合、バックアップされたファイルはどこに保存されますか? {#where-are-the-backed-up-files-stored-when-i-use-local-storage} > **Note:** > @@ -168,11 +168,11 @@ BRを使用して[`--ddl-batch-size`](/br/br-batch-create-table.md#use-batch-cre ローカルストレージを使用する場合、 BRが稼働しているノードに`backupmeta`生成され、各リージョンのLeaderノードにバックアップファイルが生成されます。 -### データの復元中にcould not read local://...:download sst failedというエラー メッセージが返された場合、どうすればよいですか? {#what-should-i-do-if-the-error-message-code-could-not-read-local-download-sst-failed-code-is-returned-during-data-restore} +### データの復元中にcould not read local://...:download sst failedというエラー メッセージが返された場合、どうすればよいですか? {#what-should-i-do-if-the-error-message-could-not-read-localdownload-sst-failed-is-returned-during-data-restore} データを復元する場合、各ノードは**すべての**バックアップファイル（SSTファイル）にアクセスできる必要があります。デフォルトでは、ストレージを`local`使用している場合、バックアップファイルが複数のノードに分散しているため、データを復元できません。そのため、各TiKVノードのバックアップファイルを他のTiKVノードにコピーする必要があります。**バックアップデータは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、またはNFSに保存することをお勧めします**。 -### ルートを使用してbrを実行しようとしたがうまくいかなかった場合、「 Permission denied 」またはNo such file or directory 」というエラーを処理するにはどうすればよいでしょうか? {#what-should-i-do-to-handle-the-code-permission-denied-code-or-code-no-such-file-or-directory-code-error-even-if-i-have-tried-to-run-code-br-code-using-root-in-vain} +### ルートを使用してbrを実行しようとしたがうまくいかなかった場合、「 Permission denied 」またはNo such file or directory 」というエラーを処理するにはどうすればよいでしょうか? {#what-should-i-do-to-handle-the-permission-denied-or-no-such-file-or-directory-error-even-if-i-have-tried-to-run-br-using-root-in-vain} TiKVがバックアップディレクトリにアクセスできるかどうかを確認する必要があります。データをバックアップするには、TiKVに書き込み権限があるかどうかを確認してください。データを復元するには、TiKVに読み取り権限があるかどうかを確認してください。 @@ -245,7 +245,7 @@ TiKVがバックアップディレクトリにアクセスできるかどうか 手順2の出力から、インスタンス`tikv-server`がユーザー`tidb_ouo`によって起動されたことがわかります。しかし、ユーザー`tidb_ouo`はインスタンス`backup`への書き込み権限がありません。そのため、バックアップは失敗します。 -### mysqlスキーマ内のテーブルが復元されないのはなぜですか? {#why-are-tables-in-the-code-mysql-code-schema-not-restored} +### mysqlスキーマ内のテーブルが復元されないのはなぜですか? {#why-are-tables-in-the-mysql-schema-not-restored} BR v5.1.0以降では、フルバックアップを実行すると、 BRは**`mysql`スキーマ内のテーブル**をバックアップします。BRより前のデフォルト設定では、 BRはユーザーデータのみを復元し、 **`mysql`スキーマ**内のテーブルは復元しません。 @@ -273,7 +273,7 @@ br restore full -f 'mysql.usertable' -s $external_storage_url --with-sys-table - システム変数テーブル（ `mysql.tidb` `mysql.global_variables` - [その他のシステムテーブル](https://github.com/pingcap/tidb/blob/release-8.5/br/pkg/restore/snap_client/systable_restore.go#L31) -### 復元中にcannot find rewrite ruleというエラーに対処するにはどうすればよいですか? {#how-to-deal-with-the-error-of-code-cannot-find-rewrite-rule-code-during-restoration} +### 復元中にcannot find rewrite ruleというエラーに対処するにはどうすればよいですか? {#how-to-deal-with-the-error-of-cannot-find-rewrite-rule-during-restoration} 復元クラスタ内に、バックアップデータ内の他のテーブルと同じ名前を持ちながら構造が不整合なテーブルがないか確認してください。多くの場合、この問題は復元クラスタ内のテーブルでインデックスが欠落していることが原因です。推奨される方法は、まず復元クラスタ内のそのようなテーブルを削除してから、復元を再試行することです。 @@ -289,7 +289,7 @@ br restore full -f 'mysql.usertable' -s $external_storage_url --with-sys-table この不整合は、バックアップで使用されるデータ圧縮率が、復元で使用されるデフォルトの圧縮率と異なるために発生します。チェックサムが成功した場合は、この問題は無視できます。 -### BR がバックアップ データを復元した後、テーブルとインデックスの TiDB の統計を更新するために、テーブルに対してANALYZEステートメントを実行する必要がありますか? {#after-br-restores-the-backup-data-do-i-need-to-execute-the-code-analyze-code-statement-on-the-table-to-update-the-statistics-of-tidb-on-the-tables-and-indexes} +### BR がバックアップ データを復元した後、テーブルとインデックスの TiDB の統計を更新するために、テーブルに対してANALYZEステートメントを実行する必要がありますか? {#after-br-restores-the-backup-data-do-i-need-to-execute-the-analyze-statement-on-the-table-to-update-the-statistics-of-tidb-on-the-tables-and-indexes} BRは統計情報をバックアップしません（v4.0.9を除く）。そのため、バックアップデータを復元した後は、 `ANALYZE TABLE`手動で実行するか、TiDBが`ANALYZE`自動的に実行するのを待つ必要があります。 @@ -305,7 +305,7 @@ v4.0.9では、 BRはデフォルトで統計情報をバックアップしま - BR はデータの復元に大量のクラスター リソースを消費するため、実際には復元タスクを並列で実行しても復元速度は限られた範囲でしか向上しません。 - データの復元のために複数の復元タスクを並行して実行するテストは行われていないため、成功することは保証されません。 -### BR はテーブルのSHARD_ROW_ID_BITSとPRE_SPLIT_REGIONS情報をバックアップしますか? 復元されたテーブルには複数のリージョンがありますか? {#does-br-back-up-the-code-shard-row-id-bits-code-and-code-pre-split-regions-code-information-of-a-table-does-the-restored-table-have-multiple-regions} +### BR はテーブルのSHARD_ROW_ID_BITSとPRE_SPLIT_REGIONS情報をバックアップしますか? 復元されたテーブルには複数のリージョンがありますか? {#does-br-back-up-the-shard_row_id_bits-and-pre_split_regions-information-of-a-table-does-the-restored-table-have-multiple-regions} はい。BRはテーブルの[`SHARD_ROW_ID_BITS`と`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)情報をバックアップします。復元されたテーブルのデータも複数のリージョンに分割されます。 diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 63482d8ba1d96..b4f07d5b8089c 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -17,15 +17,15 @@ TiDB がサポートするオペレーティング システムについては TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェア・サーバー・プラットフォーム、またはARMアーキテクチャのハードウェア・サーバー・プラットフォームに導入および実行できます。開発環境、テスト環境、および本番環境におけるサーバー・ハードウェア構成の要件と推奨事項については、 [ソフトウェアとハ​​ードウェアの推奨事項 - サーバー要件](/hardware-and-software-requirements.md#server-requirements)参照してください。 -### 10 ギガビットのネットワーク カード 2 枚の目的は何ですか? {#what-s-the-purposes-of-2-network-cards-of-10-gigabit} +### 10 ギガビットのネットワーク カード 2 枚の目的は何ですか? {#whats-the-purposes-of-2-network-cards-of-10-gigabit} 分散型クラスタであるTiDBは、特にPDに対して高い時間要件を要求します。これは、PDが一意のタイムスタンプを配布する必要があるためです。PDサーバーの時刻が一致していないと、PDサーバーを切り替える際に待機時間が長くなります。2枚のネットワークカードの結合によりデータ転送の安定性が保証され、10ギガビットの速度により転送速度が保証されます。ギガビットネットワークカードはボトルネックになりやすいため、10ギガビットネットワークカードの使用を強くお勧めします。 -### SSD に RAID を使用しない場合は実現可能でしょうか? {#is-it-feasible-if-we-don-t-use-raid-for-ssd} +### SSD に RAID を使用しない場合は実現可能でしょうか? {#is-it-feasible-if-we-dont-use-raid-for-ssd} リソースが十分にある場合は、SSDにRAID 10を使用することをお勧めします。リソースが不十分な場合は、SSDにRAIDを使用しなくても問題ありません。 -### TiDB コンポーネントの推奨構成は何ですか? {#what-s-the-recommended-configuration-of-tidb-components} +### TiDB コンポーネントの推奨構成は何ですか? {#whats-the-recommended-configuration-of-tidb-components} - TiDB は CPU とメモリに対して高い要件があります。 - PDはクラスタのメタデータを保存し、頻繁に読み取りおよび書き込みリクエストが発生します。そのため、高いI/Oディスクを必要とします。ディスクパフォ​​ーマンスが低いと、クラスタ全体のパフォーマンスに影響します。SSDディスクの使用をお勧めします。また、リージョン数が多いほど、CPUとメモリの要件が高くなります。 @@ -37,11 +37,11 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ 本番環境では、 [TiUP](/tiup/tiup-overview.md)使用してTiDBクラスタをデプロイすることをお勧めします。3 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)参照してください。 -### TiKV/PD 用に変更されたtoml構成が有効にならないのはなぜですか? {#why-the-modified-code-toml-code-configuration-for-tikv-pd-does-not-take-effect} +### TiKV/PD 用に変更されたtoml構成が有効にならないのはなぜですか? {#why-the-modified-toml-configuration-for-tikvpd-does-not-take-effect} `toml`設定を有効にするには、TiKV/PD で`--config`パラメータを設定する必要があります。TiKV/PD はデフォルトでは設定を読み取りません。現在、この問題はバイナリを使用してデプロイする場合にのみ発生します。TiKV の場合は、設定を編集してサービスを再起動してください。PD の場合は、設定ファイルは PD の初回起動時にのみ読み込まれ、その後は pd-ctl を使用して設定を変更できます。詳細は[PD Controlユーザー ガイド](/pd-control.md)参照してください。 -### TiDB モニタリングフレームワーク (Prometheus + Grafana) はスタンドアロンマシンにデプロイするべきでしょうか、それとも複数のマシンにデプロイするべきでしょうか? 推奨される CPU とメモリはどれくらいでしょうか? {#should-i-deploy-the-tidb-monitoring-framework-prometheus-grafana-on-a-standalone-machine-or-on-multiple-machines-what-is-the-recommended-cpu-and-memory} +### TiDB モニタリングフレームワーク (Prometheus + Grafana) はスタンドアロンマシンにデプロイするべきでしょうか、それとも複数のマシンにデプロイするべきでしょうか? 推奨される CPU とメモリはどれくらいでしょうか? {#should-i-deploy-the-tidb-monitoring-framework-prometheus--grafana-on-a-standalone-machine-or-on-multiple-machines-what-is-the-recommended-cpu-and-memory} 監視マシンはスタンドアロン構成での使用を推奨します。8コアCPU、16GB以上のメモリ、500GB以上のハードディスクを搭載することを推奨します。 @@ -57,17 +57,17 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ 3. ログに加えて、 `ADMIN SHOW SLOW`コマンドを使用してスロークエリも表示できます。詳細は[`ADMIN SHOW SLOW`コマンド](/identify-slow-queries.md#admin-show-slow-command)参照してください。 -### TiDB クラスターを初めてデプロイしたときに TiKV のlabelが構成されていなかった場合、 label構成を追加するにはどうすればよいですか? {#how-to-add-the-code-label-code-configuration-if-code-label-code-of-tikv-was-not-configured-when-i-deployed-the-tidb-cluster-for-the-first-time} +### TiDB クラスターを初めてデプロイしたときに TiKV のlabelが構成されていなかった場合、 label構成を追加するにはどうすればよいですか? {#how-to-add-the-label-configuration-if-label-of-tikv-was-not-configured-when-i-deployed-the-tidb-cluster-for-the-first-time} TiDB `label`の設定は、クラスタのデプロイメントアーキテクチャに関連しています。これは重要であり、PDがグローバル管理とスケジューリングを実行するための基盤となります。以前のクラスタのデプロイメント時に`label`設定していない場合は、PD管理ツール`pd-ctl`を使用して`location-labels`情報を手動で追加し、デプロイメント構造を調整する必要があります（例： `config set location-labels "zone,rack,host"` ）。（実際の`label`レベル名に基づいて設定する必要があります）。 `pd-ctl`の使い方については[PD Controlユーザー ガイド](/pd-control.md)参照してください。 -### ディスク テストのddコマンドがoflag=directオプションを使用するのはなぜですか? {#why-does-the-code-dd-code-command-for-the-disk-test-use-the-code-oflag-direct-code-option} +### ディスク テストのddコマンドがoflag=directオプションを使用するのはなぜですか? {#why-does-the-dd-command-for-the-disk-test-use-the-oflagdirect-option} ダイレクト モードでは、書き込み要求を I/O コマンドにラップし、このコマンドをディスクに送信してファイル システム キャッシュをバイパスし、ディスクの実際の I/O 読み取り/書き込みパフォーマンスを直接テストします。 -### fioコマンドを使用して TiKV インスタンスのディスク パフォーマンスをテストするにはどうすればよいですか? {#how-to-use-the-code-fio-code-command-to-test-the-disk-performance-of-the-tikv-instance} +### fioコマンドを使用して TiKV インスタンスのディスク パフォーマンスをテストするにはどうすればよいですか? {#how-to-use-the-fio-command-to-test-the-disk-performance-of-the-tikv-instance} 以下の例では`ioengine=psync` （同期I/O）を使用しているため、 `iodepth`通常`1`に固定され、同時実行性は主に`numjobs`によって制御されます。ファイルシステムキャッシュをバイパスするには、 `direct=1`設定することをお勧めします。 diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md index 027d18f160ff0..605a2635bad3a 100644 --- a/faq/migration-tidb-faq.md +++ b/faq/migration-tidb-faq.md @@ -88,7 +88,7 @@ Db2 または Oracle から TiDB にすべてのデータを移行するか、 現在はOGGの使用が推奨されています。 -### エラー: java.sql.BatchUpdateException: Sqoop を使用して TiDB にデータをbatchesで書き込むときにjava.sql.BatchUpdateException:statement count 5001 exceeds the transaction limitation {#error-code-java-sql-batchupdateexception-statement-count-5001-exceeds-the-transaction-limitation-code-while-using-sqoop-to-write-data-into-tidb-in-code-batches-code} +### エラー: java.sql.BatchUpdateException: Sqoop を使用して TiDB にデータをbatchesで書き込むときにjava.sql.BatchUpdateException:statement count 5001 exceeds the transaction limitation {#error-javasqlbatchupdateexceptionstatement-count-5001-exceeds-the-transaction-limitation-while-using-sqoop-to-write-data-into-tidb-in-batches} Sqoopでは、 `--batch`各バッチで100個の`statement`文をコミットすることを意味しますが、デフォルトでは各`statement`に100個のSQL文が含まれます。つまり、100 * 100 = 10000個のSQL文となり、単一のTiDBトランザクションで許可される最大SQL文数である5000を超えてしまいます。 @@ -109,7 +109,7 @@ Sqoopでは、 `--batch`各バッチで100個の`statement`文をコミットす - 単一の TiDB トランザクション内のステートメントの制限数を増やすこともできますが、これにより消費されるメモリが増加します。 -### Dumpling がテーブルをエクスポートするときにThe local disk space is insufficientエラーを返したり、アップストリーム データベースのメモリ不足を引き起こしたりする原因になるのはなぜですか? {#why-does-dumpling-return-code-the-local-disk-space-is-insufficient-code-error-or-cause-the-upstream-database-to-run-out-of-memory-when-exporting-a-table} +### Dumpling がテーブルをエクスポートするときにThe local disk space is insufficientエラーを返したり、アップストリーム データベースのメモリ不足を引き起こしたりする原因になるのはなぜですか? {#why-does-dumpling-return-the-local-disk-space-is-insufficient-error-or-cause-the-upstream-database-to-run-out-of-memory-when-exporting-a-table} この問題には次の原因が考えられます。 @@ -138,7 +138,7 @@ Sqoopでは、 `--batch`各バッチで100個の`statement`文をコミットす 読み取り容量の合計に制限はありません。TiDBサーバーを追加することで、読み取り容量を増やすことができます。書き込み容量にも、一般的に制限はありません。TiKVノードを追加することで、書き込み容量を増やすことができます。 -### transaction too largeエラーメッセージが表示されます {#the-error-message-code-transaction-too-large-code-is-displayed} +### transaction too largeエラーメッセージが表示されます {#the-error-message-transaction-too-large-is-displayed} 基盤となるストレージエンジンの制限により、TiDB の各キーと値のエントリ（1行）は 6MB 以下にする必要があります。1 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)設定値は最大 120MB まで調整できます。 @@ -158,7 +158,7 @@ Google Cloud Spanner には[同様の制限](https://cloud.google.com/spanner/do いいえ。データをロードするときに、ターゲット テーブルで DDL 操作を実行することはできません。そうしないと、データのロードに失敗します。 -### TiDB はreplace into構文をサポートしていますか? {#does-tidb-support-the-code-replace-into-code-syntax} +### TiDB はreplace into構文をサポートしていますか? {#does-tidb-support-the-replace-into-syntax} はい。 diff --git a/faq/sql-faq.md b/faq/sql-faq.md index 90db954e13360..381cc72ee439e 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -60,7 +60,7 @@ DROP GLOBAL BINDING for [システム変数](/system-variables.md)参照。 -## ORDER BYを省略した場合、結果の順序はMySQLと異なります。 {#the-order-of-results-is-different-from-mysql-when-code-order-by-code-is-omitted} +## ORDER BYを省略した場合、結果の順序はMySQLと異なります。 {#the-order-of-results-is-different-from-mysql-when-order-by-is-omitted} これはバグではありません。レコードのデフォルトの順序は様々な状況に依存し、一貫性は保証されません。 @@ -124,7 +124,7 @@ MySQLでは、クエリが単一スレッドで実行されるため、結果の TiDB では、システム変数[`tidb_enable_ordered_result_mode`](/system-variables.md#tidb_enable_ordered_result_mode)を使用して最終出力結果を自動的にソートすることもできます。 -## TiDB はSELECT FOR UPDATEサポートしていますか? {#does-tidb-support-code-select-for-update-code} +## TiDB はSELECT FOR UPDATEサポートしていますか? {#does-tidb-support-select-for-update} はい。悲観的ロック（TiDB v3.0.8以降のデフォルト）を使用する場合、 `SELECT FOR UPDATE`実行はMySQLと同様に動作します。 @@ -146,14 +146,14 @@ TiDBのデフォルトの文字セットは`utf8mb4`です。文字列はmemcomp TiDBのAUTO_INCREMENT ID機能は、自動的に増分され一意であることが保証されているだけで、連続的に割り当てられることは保証されていません。現在、TiDBはIDをバッチで割り当てています。複数のTiDBサーバーに同時にデータが挿入された場合、割り当てられるIDは連続的ではありません。複数のスレッドが`tidb-server`のインスタンスに同時にデータを挿入した場合、後で挿入されたデータのAUTO_INCREMENT IDは小さくなる可能性があります。TiDBでは整数フィールドに`AUTO_INCREMENT`指定できますが、1つのテーブルに`AUTO_INCREMENT`フィールドは1つしか指定できません。詳細については、 [AUTO_INCREMENT ID](/mysql-compatibility.md#auto-increment-id)と[AUTO_INCREMENT属性](/auto-increment.md)参照してください。 -## TiDB のsql_mode変更するにはどうすればよいですか? {#how-do-i-modify-the-code-sql-mode-code-in-tidb} +## TiDB のsql_mode変更するにはどうすればよいですか? {#how-do-i-modify-the-sql_mode-in-tidb} TiDB は、SESSION または GLOBAL ベースで[`sql_mode`](/system-variables.md#sql_mode)システム変数を変更することをサポートします。 - [`GLOBAL`](/sql-statements/sql-statement-set-variable.md)スコープの変数への変更は、クラスター内の残りのサーバーに伝播し、再起動後も保持されます。つまり、各 TiDBサーバーで`sql_mode`値を変更する必要はありません。 - `SESSION`スコープ変数への変更は、現在のクライアントセッションにのみ影響します。サーバーを再起動すると、変更は失われます。 -## エラー: java.sql.BatchUpdateException:statement count 5001 exceeds the transaction limitation {#error-code-java-sql-batchupdateexception-statement-count-5001-exceeds-the-transaction-limitation-code-while-using-sqoop-to-write-data-into-tidb-in-batches} +## エラー: java.sql.BatchUpdateException:statement count 5001 exceeds the transaction limitation {#error-javasqlbatchupdateexceptionstatement-count-5001-exceeds-the-transaction-limitation-while-using-sqoop-to-write-data-into-tidb-in-batches} Sqoopでは、 `--batch`各バッチで100文をコミットすることを意味しますが、デフォルトでは各文に100個のSQL文が含まれます。つまり、100 * 100 = 10000のSQL文となり、単一のTiDBトランザクションで許可される文の最大数である5000を超えてしまいます。 @@ -190,7 +190,7 @@ Sqoopでは、 `--batch`各バッチで100文をコミットすることを意 TiDBはマルチバージョン同時実行制御（MVCC）を使用しているため、古いデータが新しいデータで上書きされる際、古いデータは置き換えられず、新しいデータと共に保持されます。データのバージョンを識別するためにタイムスタンプが使用されます。データを削除しても、すぐに領域が解放されるわけではありません。同時実行トランザクションが以前のバージョンの行を参照できるように、ガベージコレクションは遅延されます。これは、システム変数[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50) （デフォルト： `10m0s` ）で設定できます。 -## SHOW PROCESSLISTシステム プロセス ID を表示しますか? {#does-code-show-processlist-code-display-the-system-process-id} +## SHOW PROCESSLISTシステム プロセス ID を表示しますか? {#does-show-processlist-display-the-system-process-id} TiDB `SHOW PROCESSLIST`の表示内容は MySQL `SHOW PROCESSLIST`とほぼ同じです。TiDB `SHOW PROCESSLIST`ではシステムプロセスIDが表示されません。表示されるのは現在のセッションIDです。TiDB `SHOW PROCESSLIST`と MySQL `SHOW PROCESSLIST`の違いは次のとおりです。 @@ -225,7 +225,7 @@ TiDBは、 [グローバル](/system-variables.md#tidb_force_priority)単位ま 2. フル テーブル スキャン ステートメントは、自動的に低い優先度に調整されます。 [`ANALYZE`](/sql-statements/sql-statement-analyze-table.md) 、デフォルトで低い優先度を持ちます。 -## TiDB でのauto analyzeのトリガー戦略は何ですか? {#what-s-the-trigger-strategy-for-code-auto-analyze-code-in-tidb} +## TiDB でのauto analyzeのトリガー戦略は何ですか? {#whats-the-trigger-strategy-for-auto-analyze-in-tidb} テーブル内の行数またはパーティションテーブルの単一パーティションの行数が 1000 に達し、テーブルまたはパーティションの比率 (変更された行数 / 現在の行の合計数) が[`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio)超えると、 [`ANALYZE`](/sql-statements/sql-statement-analyze-table.md)ステートメントが自動的にトリガーされます。 @@ -273,7 +273,7 @@ DDL操作がブロックされておらず、各TiDBサーバーがスキーマ - クラスター内の特定の TiDB ノードと PD または TiKV の間で通信の問題が発生し、TiDB が最新のバージョン情報を時間内に取得できなくなります。 -### Information schema is changedエラーの原因は何ですか? {#what-triggers-the-code-information-schema-is-changed-code-error} +### Information schema is changedエラーの原因は何ですか? {#what-triggers-the-information-schema-is-changed-error} SQL文を実行する際、TiDBは分離レベルに基づいてオブジェクトの`schema`バージョンを決定し、それに応じてSQL文を処理します。TiDBはオンライン非同期DDL変更もサポートしています。DML文を実行する際、他のDDL文が同時に実行される可能性があり、TiDBは各SQL文が同じ`schema`バージョンに対して実行されるようにする必要があります。そのため、DML実行時にDDL操作が進行中の場合、TiDBはエラー`Information schema is changed`を報告する可能性があります。さらに、一部の同時実行DDLシナリオでは、DDL文が失敗した後、TiDBは元のエラーを返す前に`schema`が変更されたかどうかを確認します。そのDDL文で使用された`schema`バージョンがすでに最新の`schema`バージョンより古い場合、TiDBはこのエラーを返すこともあります。 @@ -338,7 +338,7 @@ TiDB v6.2.0以降、TiDB DDLモジュールは並列フレームワークを採 このセクションでは、JDBC接続で使用される照合順序に関する質問を示します。TiDBでサポートされている文字セットと照合順序については、 [文字セットと照合順序](/character-set-and-collation.md)参照してください。 -### JDBC URL でconnectionCollationが構成されていない場合、JDBC 接続ではどの照合順序が使用されますか? {#what-collation-is-used-in-a-jdbc-connection-when-code-connectioncollation-code-is-not-configured-in-the-jdbc-url} +### JDBC URL でconnectionCollationが構成されていない場合、JDBC 接続ではどの照合順序が使用されますか? {#what-collation-is-used-in-a-jdbc-connection-when-connectioncollation-is-not-configured-in-the-jdbc-url} JDBC URL に`connectionCollation`が設定されていない場合、次の 2 つのシナリオが考えられます。 @@ -368,7 +368,7 @@ TiDB v7.5 以降のバージョンにアップグレードした後は、JDBC UR spring.datasource.url=JDBC:mysql://{TiDBIP}:{TiDBPort}/{DBName}?characterEncoding=UTF-8&connectionCollation=utf8mb4_bin&useSSL=false&useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSqlLimit=10000&prepStmtCacheSize=1000&useConfigs=maxPerformance&rewriteBatchedStatements=true&defaultFetchSize=-2147483648&allowMultiQueries=true -### utf8mb4_bin順序とutf8mb4_0900_ai_ci照合順序の違いは何ですか? {#what-are-the-differences-between-the-code-utf8mb4-bin-code-and-code-utf8mb4-0900-ai-ci-code-collations} +### utf8mb4_bin順序とutf8mb4_0900_ai_ci照合順序の違いは何ですか? {#what-are-the-differences-between-the-utf8mb4_bin-and-utf8mb4_0900_ai_ci-collations} | 照合 | 大文字と小文字を区別 | 末尾のスペースを無視する | アクセントを重視 | 比較方法 | | -------------------- | ---------- | ------------ | -------- | --------------------- | @@ -407,7 +407,7 @@ SELECT 'café' = 'cafe' COLLATE utf8mb4_0900_ai_ci; -- Returns 1 (TRUE) [統計入門](/statistics.md)参照。 -### select count(1)を最適化するにはどうすればいいでしょうか? {#how-to-optimize-code-select-count-1-code} +### select count(1)を最適化するにはどうすればいいでしょうか? {#how-to-optimize-select-count1} `count(1)`文はテーブル内の行の総数をカウントします。同時実行性を向上させることで、速度を大幅に向上させることができます。同時実行性を変更するには、 [`tidb_distsql_scan_concurrency`ドキュメント](/system-variables.md#tidb_distsql_scan_concurrency)を参照してください。ただし、これはCPUとI/Oリソースにも依存します。TiDBはすべてのクエリでTiKVにアクセスします。データ量が少ない場合、MySQLはすべてメモリ内にあるため、TiDBはネットワークアクセスを実行する必要があります。 @@ -445,7 +445,7 @@ ADMIN SHOW DDL; はい。TiDBはコストベースオプティマイザを使用しています。コストモデルと統計は常に最適化されています。また、TiDBはハッシュ結合やソートマージ結合などの結合アルゴリズムもサポートしています。 -### テーブルでanalyze実行する必要があるかどうかを判断するにはどうすればよいでしょうか? {#how-to-determine-whether-i-need-to-execute-code-analyze-code-on-a-table} +### テーブルでanalyze実行する必要があるかどうかを判断するにはどうすればよいでしょうか? {#how-to-determine-whether-i-need-to-execute-analyze-on-a-table} `SHOW STATS_HEALTHY`を使用して`Healthy`フィールドを確認する。通常、フィールド値が 60 より小さい場合は、テーブルで`ANALYZE`実行する必要があります。 @@ -453,7 +453,7 @@ ADMIN SHOW DDL; これらのIDにはルールはありませんが、IDは一意です。IDが生成されるとカウンターが動作し、プランが1つ生成されるごとに1が加算されます。実行順序はIDとは無関係です。クエリプラン全体はツリー構造になっており、実行プロセスはルートノードから開始され、データは上位レベルへと連続的に返されます。クエリプランの詳細については、 [TiDBクエリ実行プランの理解](/explain-overview.md)参照してください。 -### TiDBクエリプランでは、 copタスクは同じルートにあります。それらは同時に実行されますか？ {#in-the-tidb-query-plan-code-cop-code-tasks-are-in-the-same-root-are-they-executed-concurrently} +### TiDBクエリプランでは、 copタスクは同じルートにあります。それらは同時に実行されますか？ {#in-the-tidb-query-plan-cop-tasks-are-in-the-same-root-are-they-executed-concurrently} 現在、 TiDB のコンピューティング タスクは、タスク`cop task`と`root task`の 2 つの異なるタイプに属しています。 diff --git a/functions-and-operators/bit-functions-and-operators.md b/functions-and-operators/bit-functions-and-operators.md index 835d90b1a9f34..f7e08a48b5ceb 100644 --- a/functions-and-operators/bit-functions-and-operators.md +++ b/functions-and-operators/bit-functions-and-operators.md @@ -19,7 +19,7 @@ TiDB は、MySQL 8.0 で利用可能な[ビット関数と演算子](https://dev | [`<<`](#-left-shift) | 左シフト | | [`>>`](#-right-shift) | 右シフト | -## `BIT_COUNT()` {#bit-count} +## `BIT_COUNT()` {#bit_count} `BIT_COUNT(expr)`関数は、 `expr`のうち 1 に設定されているビットの数を返します。 @@ -64,7 +64,7 @@ SELECT BIT_COUNT(INET_ATON('255.255.255.0')); +---------------------------------------+ 1 row in set (0.00 sec) -## & (ビットAND) {#code-x26-code-bitwise-and} +## & (ビットAND) {#-bitwise-and} `&`演算子はビットごとのAND演算を実行します。2つの数値の対応するビットを比較します。対応するビットが両方とも1の場合、結果の対応するビットは1になります。それ以外の場合は0になります。 @@ -114,7 +114,7 @@ SELECT INET_NTOA(INET_ATON('192.168.1.2') & INET_ATON('255.255.255.0')); +------------------------------------------------------------------+ 1 row in set (0.00 sec) -## ~ (ビット反転) {#code-code-bitwise-inversion} +## ~ (ビット反転) {#-bitwise-inversion} `~`演算子は、与えられた値に対してビット反転（またはビット否定）演算を実行します。与えられた値の各ビットを反転します。つまり、0のビットは1になり、1のビットは0になります。 @@ -150,7 +150,7 @@ SELECT CONV(~ b'1111111111111111111111111111111111111111111111110000111100001111 +----------------------------------------------------------------------------------+ 1 row in set (0.00 sec) -## | (ビット論理和) {#code-code-bitwise-or} +## | (ビット論理和) {#-bitwise-or} `|`演算子はビットごとのOR演算を実行します。2つの数値の対応するビットを比較します。対応するビットの少なくとも1つが1の場合、結果の対応するビットも1になります。 @@ -174,7 +174,7 @@ SELECT CONV(b'1010' | b'1100',10,2); +------------------------------+ 1 row in set (0.00 sec) -## ^ (ビット単位のXOR) {#code-code-bitwise-xor} +## ^ (ビット単位のXOR) {#-bitwise-xor} `^`演算子はビット単位のXOR（排他的論理和）演算を実行します。2つの数値の対応するビットを比較します。対応するビットが異なる場合、結果の対応するビットは1になります。 @@ -200,7 +200,7 @@ SELECT CONV(b'1010' ^ b'1100',10,2); 先頭のゼロが削除されているため、結果は`0110`ではなく`110`と表示されることに注意してください。 -## << （左シフト） {#code-x3c-x3c-code-left-shift} +## << （左シフト） {#-left-shift} `<<`演算子は左シフト演算を実行し、数値のビットを指定された位置数だけ左にシフトし、右側の空いたビットをゼロで埋めます。 @@ -232,7 +232,7 @@ SELECT n,1<>> (右シフト) {#code-code-right-shift} +## >> (右シフト) {#-right-shift} `>>`演算子は右シフト演算を実行し、数値のビットを指定された位置数だけ右にシフトし、左側の空いたビットをゼロで埋めます。 diff --git a/functions-and-operators/encryption-and-compression-functions.md b/functions-and-operators/encryption-and-compression-functions.md index 11537a962f906..05c625a254bd6 100644 --- a/functions-and-operators/encryption-and-compression-functions.md +++ b/functions-and-operators/encryption-and-compression-functions.md @@ -25,7 +25,7 @@ TiDB は、MySQL 8.0 で利用可能な[暗号化および圧縮関数](https:// | [`UNCOMPRESSED_LENGTH()`](#uncompressed_length) | 圧縮前の文字列の長さを返す | | [`VALIDATE_PASSWORD_STRENGTH()`](#validate_password_strength) | パスワードの強度を検証する | -### `AES_DECRYPT()` {#aes-decrypt} +### `AES_DECRYPT()` {#aes_decrypt} `AES_DECRYPT(data, key [,iv])`関数は、同じ`key`を使用して[`AES_ENCRYPT()`](#aes_encrypt)関数を使用して以前に暗号化された`data`復号化します。 @@ -44,7 +44,7 @@ SELECT AES_DECRYPT(0x28409970815CD536428876175F1A4923, 'secret'); +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) -### `AES_ENCRYPT()` {#aes-encrypt} +### `AES_ENCRYPT()` {#aes_encrypt} `AES_ENCRYPT(data, key [,iv])`関数は、 [高度暗号化規格（AES）](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard)アルゴリズムを使用して`data` `key`で暗号化します。 @@ -149,7 +149,7 @@ SELECT PASSWORD('secret'); Warning (Code 1681): PASSWORD is deprecated and will be removed in a future release. -### `RANDOM_BYTES()` {#random-bytes} +### `RANDOM_BYTES()` {#random_bytes} `RANDOM_BYTES(n)`関数は`n`ランダム バイトを返します。 @@ -242,7 +242,7 @@ SELECT UNCOMPRESS(0x03000000789C72747206040000FFFF018D00C7); +------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) -### `UNCOMPRESSED_LENGTH()` {#uncompressed-length} +### `UNCOMPRESSED_LENGTH()` {#uncompressed_length} `UNCOMPRESSED_LENGTH(data)`関数は、圧縮データの最初の 4 バイトを返します。これには、 [`COMPRESS()`](#compress)関数で圧縮される前の圧縮文字列の長さが格納されます。 @@ -257,7 +257,7 @@ SELECT UNCOMPRESSED_LENGTH(0x03000000789C72747206040000FFFF018D00C7); +---------------------------------------------------------------+ 1 row in set (0.00 sec) -### `VALIDATE_PASSWORD_STRENGTH()` {#validate-password-strength} +### `VALIDATE_PASSWORD_STRENGTH()` {#validate_password_strength} diff --git a/functions-and-operators/information-functions.md b/functions-and-operators/information-functions.md index 69c4dcd077ed7..7b907b76ae816 100644 --- a/functions-and-operators/information-functions.md +++ b/functions-and-operators/information-functions.md @@ -51,7 +51,7 @@ SELECT BENCHMARK(5, SLEEP(2)); +------------------------+ 1 row in set (10.00 sec) -### 接続ID() {#connection-id} +### 接続ID() {#connection_id} @@ -80,7 +80,7 @@ SELECT CONNECTION_ID(); +-----------------+ 1 row in set (0.00 sec) -### 現在のロール() {#current-role} +### 現在のロール() {#current_role} @@ -105,7 +105,7 @@ SELECT CURRENT_ROLE(); +----------------+ 1 row in set (0.00 sec) -### 現在のユーザー() {#current-user} +### 現在のユーザー() {#current_user} `CURRENT_USER()`関数は、現在のセッションで使用されているアカウントを返します。 @@ -135,7 +135,7 @@ SELECT DATABASE(); +------------+ 1 row in set (0.00 sec) -### 見つかった行() {#found-rows} +### 見つかった行() {#found_rows} `FOUND_ROWS()`関数は、最後に実行された`SELECT`ステートメントの結果セット内の行数を返します。 @@ -166,7 +166,7 @@ SELECT FOUND_ROWS(); > > クエリ修飾子`SQL_CALC_FOUND_ROWS` 、クエリ修飾子`LIMIT`を考慮せずに結果セットの合計行数を計算しますが、クエリ修飾子[`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)有効な場合にのみ使用できます。このクエリ修飾子は、MySQL 8.0.17 以降では非推奨です。代わりにクエリ修飾子`COUNT(*)`使用することをお勧めします。 -### 最終挿入ID() {#last-insert-id} +### 最終挿入ID() {#last_insert_id} `LAST_INSERT_ID()`関数は、 [`AUTO_INCREMENT`](/auto-increment.md)または[`AUTO_RANDOM`](/auto-random.md)列を含むテーブルに最後に挿入された行の ID を返します。 @@ -206,7 +206,7 @@ TABLE t1; `LAST_INSERT_ID(expr)`関数は式を引数として受け取り、その値を`LAST_INSERT_ID()`次回呼び出し時に保存します。MySQL互換のシーケンス生成メソッドとして使用できます。TiDBは[シーケンス関数](/functions-and-operators/sequence-functions.md)もサポートしています。 -### ROW_COUNT() {#row-count} +### ROW_COUNT() {#row_count} `ROW_COUNT()`関数は影響を受ける行の数を返します。 @@ -231,11 +231,11 @@ SELECT ROW_COUNT(); `SCHEMA()`関数は[`DATABASE()`](#database)の同義語です。 -### セッションユーザー() {#session-user} +### セッションユーザー() {#session_user} `SESSION_USER()`関数は[`USER()`](#user)の同義語です。 -### SYSTEM_USER() {#system-user} +### SYSTEM_USER() {#system_user} `SYSTEM_USER()`関数は[`USER()`](#user)の同義語です。 diff --git a/functions-and-operators/json-functions/json-functions-aggregate.md b/functions-and-operators/json-functions/json-functions-aggregate.md index fb577dfeee191..c972eda0730b5 100644 --- a/functions-and-operators/json-functions/json-functions-aggregate.md +++ b/functions-and-operators/json-functions/json-functions-aggregate.md @@ -9,7 +9,7 @@ summary: JSON 値を集約する JSON関数について学習します。 TiDB は MySQL 8.0 で利用可能な[2つの集計JSON関数](https://dev.mysql.com/doc/refman/8.0/en/aggregate-functions.html)サポートします。 -## `JSON_ARRAYAGG()` {#json-arrayagg} +## `JSON_ARRAYAGG()` {#json_arrayagg} `JSON_ARRAYAGG(key)`関数は、指定された`key`に従ってキーの値を JSON 配列に集約します。5 `key`通常、式または列名です。 @@ -28,7 +28,7 @@ SELECT JSON_ARRAYAGG(v) FROM (SELECT 1 'v' UNION SELECT 2); +------------------+ 1 row in set (0.00 sec) -## `JSON_OBJECTAGG()` {#json-objectagg} +## `JSON_OBJECTAGG()` {#json_objectagg} `JSON_OBJECTAGG(key,value)`関数は、指定された`key`と`value`に従って、キーとキーの値をJSONオブジェクトに集約します。 `key`と`value`は通常、式または列名です。 diff --git a/functions-and-operators/json-functions/json-functions-create.md b/functions-and-operators/json-functions/json-functions-create.md index 4f0aebd95654e..c3ac082ee4ed5 100644 --- a/functions-and-operators/json-functions/json-functions-create.md +++ b/functions-and-operators/json-functions/json-functions-create.md @@ -7,7 +7,7 @@ summary: JSON 値を作成する JSON関数について学習します。 TiDB は、MySQL 8.0 で利用可能な[JSON値を作成するJSON関数](https://dev.mysql.com/doc/refman/8.0/en/json-creation-functions.html)すべてをサポートします。 -## `JSON_ARRAY()` {#json-array} +## `JSON_ARRAY()` {#json_array} `JSON_ARRAY([val[, val] ...])`関数は、(空の可能性のある)値のリストを評価し、それらの値を含む JSON 配列を返します。 @@ -22,7 +22,7 @@ SELECT JSON_ARRAY(1,2,3,4,5), JSON_ARRAY("foo", "bar"); +-----------------------+--------------------------+ 1 row in set (0.00 sec) -## `JSON_OBJECT()` {#json-object} +## `JSON_OBJECT()` {#json_object} `JSON_OBJECT([key, val[, key, val] ...])`関数は、キーと値のペアの (空の場合もある) リストを評価し、それらのペアを含む JSON オブジェクトを返します。 @@ -37,7 +37,7 @@ SELECT JSON_OBJECT("database", "TiDB", "distributed", TRUE); +------------------------------------------------------+ 1 row in set (0.00 sec) -## `JSON_QUOTE()` {#json-quote} +## `JSON_QUOTE()` {#json_quote} `JSON_QUOTE(str)`関数は、引用符付きの JSON 値として文字列を返します。 diff --git a/functions-and-operators/json-functions/json-functions-modify.md b/functions-and-operators/json-functions/json-functions-modify.md index fced3289c3acd..5c8688a7441be 100644 --- a/functions-and-operators/json-functions/json-functions-modify.md +++ b/functions-and-operators/json-functions/json-functions-modify.md @@ -7,11 +7,11 @@ summary: JSON 値を変更する JSON関数について学習します。 TiDB は、MySQL 8.0 で利用可能な[JSON値を変更するJSON関数](https://dev.mysql.com/doc/refman/8.0/en/json-modification-functions.html)すべてをサポートします。 -## `JSON_APPEND()` {#json-append} +## `JSON_APPEND()` {#json_append} [`JSON_ARRAY_APPEND()`](#json_array_append)の別名。 -## `JSON_ARRAY_APPEND()` {#json-array-append} +## `JSON_ARRAY_APPEND()` {#json_array_append} `JSON_ARRAY_APPEND(json_array, path, value [,path, value] ...)`関数は、JSON ドキュメント内の指定された配列の末尾に指定された`path`に値を追加し、結果を返します。 @@ -45,7 +45,7 @@ SELECT JSON_ARRAY_APPEND('{"transport_options": ["Car", "Boat", "Train"]}', '$.t +-------------------------------------------------------------+ 1 row in set (0.00 sec) -## `JSON_ARRAY_INSERT()` {#json-array-insert} +## `JSON_ARRAY_INSERT()` {#json_array_insert} `JSON_ARRAY_INSERT(json_array, path, value [,path, value] ...)`関数は、 `path`の`json_array`の指定された位置に`value`挿入し、結果を返します。 @@ -79,7 +79,7 @@ SELECT JSON_ARRAY_INSERT('["Car", "Boat", "Train"]', '$[1]', "Airplane") AS "Tra +--------------------------------------+ 1 row in set (0.00 sec) -## `JSON_INSERT()` {#json-insert} +## `JSON_INSERT()` {#json_insert} `JSON_INSERT(json_doc, path, value [,path, value] ...)`関数は、JSON ドキュメントに 1 つ以上の値を挿入し、結果を返します。 @@ -113,7 +113,7 @@ SELECT JSON_INSERT('{"a": 61, "b": 62}', '$.a', 41, '$.c', 63); +---------------------------------------------------------+ 1 row in set (0.00 sec) -## `JSON_MERGE_PATCH()` {#json-merge-patch} +## `JSON_MERGE_PATCH()` {#json_merge_patch} `JSON_MERGE_PATCH(json_doc, json_doc [,json_doc] ...)`関数は、重複するキーの値を保持せずに、2つ以上のJSONドキュメントを1つのJSONドキュメントにマージします。重複するキーを持つ`json_doc`引数の場合、マージされた結果には、後に指定された`json_doc`引数の値のみが保持されます。 @@ -136,7 +136,7 @@ SELECT JSON_MERGE_PATCH( +-----------------------------------------------------------------+ 1 row in set (0.00 sec) -## `JSON_MERGE_PRESERVE()` {#json-merge-preserve} +## `JSON_MERGE_PRESERVE()` {#json_merge_preserve} `JSON_MERGE_PRESERVE(json_doc, json_doc [,json_doc] ...)`関数は、各キーに関連付けられたすべての値を保持しながら 2 つ以上の JSON ドキュメントをマージし、マージされた結果を返します。 @@ -155,7 +155,7 @@ SELECT JSON_MERGE_PRESERVE('{"a": 1, "b": 2}','{"a": 100}', '{"c": 300}'); +--------------------------------------------------------------------+ 1 row in set (0.00 sec) -## `JSON_MERGE()` {#json-merge} +## `JSON_MERGE()` {#json_merge} > **Warning:** > @@ -163,7 +163,7 @@ SELECT JSON_MERGE_PRESERVE('{"a": 1, "b": 2}','{"a": 100}', '{"c": 300}'); [`JSON_MERGE_PRESERVE()`](#json_merge_preserve)の非推奨のエイリアス。 -## `JSON_REMOVE()` {#json-remove} +## `JSON_REMOVE()` {#json_remove} `JSON_REMOVE(json_doc, path [,path] ...)`関数は、JSON ドキュメントから指定された`path`のデータを削除し、結果を返します。 @@ -195,7 +195,7 @@ SELECT JSON_REMOVE('{"a": 61, "b": 62, "c": 63}','$.b','$.c'); +--------------------------------------------------------+ 1 row in set (0.00 sec) -## `JSON_REPLACE()` {#json-replace} +## `JSON_REPLACE()` {#json_replace} `JSON_REPLACE(json_doc, path, value [, path, value] ...)`関数は、JSON ドキュメント内の指定されたパス内の値を置き換え、結果を返します。指定されたパスが存在しない場合、そのパスに対応する値は結果に追加されません。 @@ -229,7 +229,7 @@ SELECT JSON_REPLACE('{"a": 41, "b": 62}','$.b',42,'$.c',43); +------------------------------------------------------+ 1 row in set (0.00 sec) -## `JSON_SET()` {#json-set} +## `JSON_SET()` {#json_set} `JSON_SET(json_doc, path, value [,path, value] ...)`関数は、JSON ドキュメントにデータを挿入または更新し、結果を返します。 @@ -263,7 +263,7 @@ SELECT JSON_SET('{"version": 1.1, "name": "example"}','$.version',1.2,'$.branch' +------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) -## `JSON_UNQUOTE()` {#json-unquote} +## `JSON_UNQUOTE()` {#json_unquote} `JSON_UNQUOTE(json)`関数はJSON値の引用符を解除し、結果を文字列として返します。これは[`JSON_QUOTE()`](/functions-and-operators/json-functions/json-functions-create.md#json_quote)関数の逆の動作です。 diff --git a/functions-and-operators/json-functions/json-functions-return.md b/functions-and-operators/json-functions/json-functions-return.md index 9c7d26964ab81..1b0d0d7354aee 100644 --- a/functions-and-operators/json-functions/json-functions-return.md +++ b/functions-and-operators/json-functions/json-functions-return.md @@ -7,7 +7,7 @@ summary: JSON 値を返す JSON関数について学習します。 TiDB は、MySQL 8.0 で利用可能な[JSON値属性を返すJSON関数](https://dev.mysql.com/doc/refman/8.0/en/json-attribute-functions.html)すべてをサポートします。 -## `JSON_DEPTH()` {#json-depth} +## `JSON_DEPTH()` {#json_depth} `JSON_DEPTH(json_doc)`関数は、JSON ドキュメントの最大深度を返します。 @@ -30,7 +30,7 @@ SELECT JSON_DEPTH('{"weather": {"current": "sunny"}}'); +-------------------------------------------------+ 1 row in set (0.00 sec) -## `JSON_LENGTH()` {#json-length} +## `JSON_LENGTH()` {#json_length} `JSON_LENGTH(json_doc [,path])`番目の関数はJSONドキュメントの長さを返します。3 `path`引数が指定された場合は、パス内の値の長さを返します。 @@ -62,7 +62,7 @@ SELECT JSON_LENGTH('{"weather": {"current": "sunny", "tomorrow": "cloudy"}}','$. +------------------------------------------------------------------------------------+ 1 row in set (0.01 sec) -## `JSON_TYPE()` {#json-type} +## `JSON_TYPE()` {#json_type} `JSON_TYPE(json_val)`関数は[JSON値の型](/data-type-json.md#json-value-types)を示す文字列を返します。 @@ -120,7 +120,7 @@ SELECT JSON_TYPE('"2025-06-14"'),JSON_TYPE(CAST(CAST('2025-06-14' AS date) AS js +---------------------------+-----------------------------------------------------+ 1 row in set (0.00 sec) -## `JSON_VALID()` {#json-valid} +## `JSON_VALID()` {#json_valid} `JSON_VALID(str)`関数は、引数が有効なJSONかどうかを確認します。これは、列を`JSON`型に変換する前にチェックするのに役立ちます。 diff --git a/functions-and-operators/json-functions/json-functions-search.md b/functions-and-operators/json-functions/json-functions-search.md index 3ca624b0e3a37..2a7fdb7907dd6 100644 --- a/functions-and-operators/json-functions/json-functions-search.md +++ b/functions-and-operators/json-functions/json-functions-search.md @@ -7,7 +7,7 @@ summary: JSON 値を検索する JSON関数について学習します。 TiDB は、MySQL 8.0 で利用可能な[JSON値を検索するJSON関数](https://dev.mysql.com/doc/refman/8.0/en/json-search-functions.html)のほとんどをサポートしています。 -## `JSON_CONTAINS()` {#json-contains} +## `JSON_CONTAINS()` {#json_contains} `JSON_CONTAINS(json_doc, candidate [,path])`関数は、 `1`または`0`返すことにより、指定された`candidate` JSON ドキュメントがターゲット JSON ドキュメント内に含まれているかどうかを示します。 @@ -78,7 +78,7 @@ SELECT JSON_CONTAINS('{"foo": "bar", "aaa": 5}','"bar"', '$.foo'); +------------------------------------------------------------+ 1 row in set (0.00 sec) -## `JSON_CONTAINS_PATH()` {#json-contains-path} +## `JSON_CONTAINS_PATH()` {#json_contains_path} `JSON_CONTAINS_PATH(json_doc, all_or_one, path [,path, ...])`関数は、JSON ドキュメントに指定されたパスのデータが含まれているかどうかを示す`0`または`1`返します。 @@ -123,7 +123,7 @@ SELECT JSON_CONTAINS_PATH('{"foo": "bar", "aaa": 5}','all','$.foo', '$.aaa'); +-----------------------------------------------------------------------+ 1 row in set (0.00 sec) -## `JSON_EXTRACT()` {#json-extract} +## `JSON_EXTRACT()` {#json_extract} `JSON_EXTRACT(json_doc, path[, path] ...)`関数は、 `path`引数に一致するドキュメントの部分から選択して、JSON ドキュメントからデータを抽出します。 @@ -182,7 +182,7 @@ FROM ( +------------+--------------------------+-------------+----------------------------------------+ 1 row in set (0.00 sec) -## `JSON_KEYS()` {#json-keys} +## `JSON_KEYS()` {#json_keys} `JSON_KEYS(json_doc [,path])`関数は、JSONオブジェクトの最上位キーをJSON配列として返します。3 引数`path`指定された場合は、選択されたパスの最上位キーを返します。 @@ -214,7 +214,7 @@ SELECT JSON_KEYS('{"name": {"first": "John", "last": "Doe"}, "type": "Person"}', +-------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) -## `JSON_SEARCH()` {#json-search} +## `JSON_SEARCH()` {#json_search} `JSON_SEARCH(json_doc, one_or_all, str)`関数は、JSON ドキュメントで文字列の 1 つまたはすべての一致を検索します。 @@ -262,7 +262,7 @@ SELECT JSON_SEARCH('{"a": ["aa", "bb", "cc"], "b": ["cc", "dd"]}','all','cc'); ``` -## `JSON_OVERLAPS()` {#json-overlaps} +## `JSON_OVERLAPS()` {#json_overlaps} `JSON_OVERLAPS(json_doc, json_doc)`関数は、2つのJSONドキュメントに重複部分があるかどうかを示します。重複がある場合は`1` 、重複しない場合は`0`返します。引数のいずれかが`NULL`の場合は`NULL`返します。 diff --git a/functions-and-operators/json-functions/json-functions-utility.md b/functions-and-operators/json-functions/json-functions-utility.md index 1307f7216f541..30f5882409599 100644 --- a/functions-and-operators/json-functions/json-functions-utility.md +++ b/functions-and-operators/json-functions/json-functions-utility.md @@ -7,7 +7,7 @@ summary: JSON ユーティリティ関数について学習します。 TiDB は、MySQL 8.0 で利用可能な[JSONユーティリティ関数](https://dev.mysql.com/doc/refman/8.0/en/json-utility-functions.html)すべてをサポートします。 -## `JSON_PRETTY()` {#json-pretty} +## `JSON_PRETTY()` {#json_pretty} `JSON_PRETTY(json_doc)`関数は JSON ドキュメントのフォーマットを整えます。 @@ -27,7 +27,7 @@ SELECT JSON_PRETTY('{"person":{"name":{"first":"John","last":"Doe"},"age":23}}') } 1 row in set (0.00 sec) -## `JSON_STORAGE_FREE()` {#json-storage-free} +## `JSON_STORAGE_FREE()` {#json_storage_free} `JSON_STORAGE_FREE(json_doc)`関数は、JSON 値がその場で更新された後にバイナリ表現で解放されるストレージ容量を返します。 @@ -46,7 +46,7 @@ SELECT JSON_STORAGE_FREE('{}'); +-------------------------+ 1 row in set (0.00 sec) -## `JSON_STORAGE_SIZE()` {#json-storage-size} +## `JSON_STORAGE_SIZE()` {#json_storage_size} `JSON_STORAGE_SIZE(json_doc)`関数は、JSON 値を格納するために必要なバイト数の概算値を返します。このサイズは TiKV 圧縮を考慮していないため、この関数の出力は MySQL と厳密には互換性がありません。 diff --git a/functions-and-operators/json-functions/json-functions-validate.md b/functions-and-operators/json-functions/json-functions-validate.md index d2c7ef06ae626..61894ba57fbb5 100644 --- a/functions-and-operators/json-functions/json-functions-validate.md +++ b/functions-and-operators/json-functions/json-functions-validate.md @@ -11,7 +11,7 @@ TiDB は、MySQL 8.0 で利用可能な[JSONスキーマ検証関数](https://de > > 現在、この機能は[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)インスタンスではご利用いただけません。 -## `JSON_SCHEMA_VALID()` {#json-schema-valid} +## `JSON_SCHEMA_VALID()` {#json_schema_valid} `JSON_SCHEMA_VALID(schema, json_doc)`関数は、JSON ドキュメントをスキーマに対して検証し、データの整合性と一貫性を確保します。 diff --git a/functions-and-operators/miscellaneous-functions.md b/functions-and-operators/miscellaneous-functions.md index 83fad731f93a8..7f730fe827088 100644 --- a/functions-and-operators/miscellaneous-functions.md +++ b/functions-and-operators/miscellaneous-functions.md @@ -30,7 +30,7 @@ TiDB は、MySQL 8.0 で利用可能な[その他の関数](https://dev.mysql.co | [`UUID_TO_BIN()`](#uuid_to_bin) | UUIDをテキスト形式からバイナリ形式に変換する | | [`VALUES()`](#values) | INSERT時に使用される値を定義します | -### 任意の値() {#any-value} +### 任意の値() {#any_value} `ANY_VALUE()`関数は、値のグループから任意の値を返します。通常、 `SELECT`ステートメントに集計されていない列を`GROUP BY`句とともに含める必要があるシナリオで使用されます。 @@ -59,7 +59,7 @@ SELECT ANY_VALUE(id),GROUP_CONCAT(id),name FROM fruits GROUP BY name; 前述の例では、 `SELECT`列が非集計列であり、 `id`句に含まれていないため、TiDB は最初の`GROUP BY`ステートメントに対してエラーを返します。この問題を解決するために、2 番目の`SELECT`クエリでは、 `ANY_VALUE()`を使用して各グループから任意の値を取得し、 `GROUP_CONCAT()`を使用して各グループ内の`id`列のすべての値を単一の文字列に連結します。この方法により、非集計列の SQL モードを変更することなく、各グループから 1 つの値とグループ内のすべての値を取得できます。 -### BIN_TO_UUID() {#bin-to-uuid} +### BIN_TO_UUID() {#bin_to_uuid} `BIN_TO_UUID()`と`UUID_TO_BIN()`は、テキスト形式の UUID とバイナリ形式の UUID を相互に変換するために使用できます。どちらの関数も 2 つの引数を受け取ります。 @@ -143,7 +143,7 @@ TABLE t1; [`GROUP BY`修飾子](/functions-and-operators/group-by-modifier.md)を参照してください。 -### INET_ATON() {#inet-aton} +### INET_ATON() {#inet_aton} `INET_ATON()`関数は、ドット付き四分音符表記の IPv4 アドレスを、効率的に保存できるバイナリ バージョンに変換します。 @@ -158,7 +158,7 @@ SELECT INET_ATON('127.0.0.1'); +------------------------+ 1 row in set (0.00 sec) -### INET_NTOA() {#inet-ntoa} +### INET_NTOA() {#inet_ntoa} `INET_NTOA()`関数は、バイナリ IPv4 アドレスをドット付き四角形表記に変換します。 @@ -173,7 +173,7 @@ SELECT INET_NTOA(2130706433); +-----------------------+ 1 row in set (0.00 sec) -### INET6_ATON() {#inet6-aton} +### INET6_ATON() {#inet6_aton} `INET6_ATON()`関数は[`INET_ATON()`](#inet_aton)と似ていますが、 `INET6_ATON()` IPv6 アドレスも処理できます。 @@ -188,7 +188,7 @@ SELECT INET6_ATON('::1'); +--------------------------------------+ 1 row in set (0.00 sec) -### INET6_NTOA() {#inet6-ntoa} +### INET6_NTOA() {#inet6_ntoa} `INET6_NTOA()`関数は[`INET_NTOA()`](#inet_ntoa)と似ていますが、 `INET6_NTOA()` IPv6 アドレスも処理できます。 @@ -203,7 +203,7 @@ SELECT INET6_NTOA(0x00000000000000000000000000000001); +------------------------------------------------+ 1 row in set (0.00 sec) -### IS_IPV4() {#is-ipv4} +### IS_IPV4() {#is_ipv4} `IS_IPV4()`関数は、指定された引数が IPv4 アドレスであるかどうかをテストします。 @@ -229,7 +229,7 @@ SELECT IS_IPV4('300.0.0.1'); +----------------------+ 1 row in set (0.00 sec) -### IS_IPV4_COMPAT() {#is-ipv4-compat} +### IS_IPV4_COMPAT() {#is_ipv4_compat} `IS_IPV4_COMPAT()`関数は、指定された引数が IPv4 互換アドレスであるかどうかをテストします。 @@ -244,7 +244,7 @@ SELECT IS_IPV4_COMPAT(INET6_ATON('::127.0.0.1')); +-------------------------------------------+ 1 row in set (0.00 sec) -### IS_IPV4_MAPPE() {#is-ipv4-mapped} +### IS_IPV4_MAPPE() {#is_ipv4_mapped} `IS_IPV4_MAPPED()`関数は、指定された引数が IPv4 マップド アドレスであるかどうかをテストします。 @@ -259,7 +259,7 @@ SELECT IS_IPV4_MAPPED(INET6_ATON('::ffff:127.0.0.1')); +------------------------------------------------+ 1 row in set (0.00 sec) -### IS_IPV6() {#is-ipv6} +### IS_IPV6() {#is_ipv6} `IS_IPV6()`関数は、指定された引数が IPv6 アドレスであるかどうかをテストします。 @@ -274,7 +274,7 @@ SELECT IS_IPV6('::1'); +----------------+ 1 row in set (0.00 sec) -### IS_UUID() {#is-uuid} +### IS_UUID() {#is_uuid} `IS_UUID()`関数は、指定された引数が[UUID](/best-practices/uuid.md)であるかどうかをテストします。 @@ -289,7 +289,7 @@ SELECT IS_UUID('eb48c08c-eb71-11ee-bacf-5405db7aad56'); +-------------------------------------------------+ 1 row in set (0.00 sec) -### NAME_CONST() {#name-const} +### NAME_CONST() {#name_const} `NAME_CONST()`関数は列に名前を付けるために使用されます。代わりに列エイリアスを使用することをお勧めします。 @@ -351,7 +351,7 @@ SELECT UUID(); [UUIDのベストプラクティス](/best-practices/uuid.md)も参照してください。 -### UUIDからビンへ {#uuid-to-bin} +### UUIDからビンへ {#uuid_to_bin} [BIN_TO_UUID()](#bin_to_uuid)を参照してください。 diff --git a/functions-and-operators/string-functions.md b/functions-and-operators/string-functions.md index bf33fc04d5a2b..787ca197e7311 100644 --- a/functions-and-operators/string-functions.md +++ b/functions-and-operators/string-functions.md @@ -86,7 +86,7 @@ SELECT BIN(-7); +------------------------------------------------------------------+ ``` -### `BIT_LENGTH()` {#bit-length} +### `BIT_LENGTH()` {#bit_length} `BIT_LENGTH()`関数は、指定された引数の長さをビット単位で返すために使用されます。 @@ -198,7 +198,7 @@ SELECT CHAR(65,66,67); +----------------+ 1 row in set (0.00 sec) -### `CHAR_LENGTH()` {#char-length} +### `CHAR_LENGTH()` {#char_length} `CHAR_LENGTH()`関数は、指定された引数内の文字の合計数を整数として取得するために使用されます。 @@ -229,7 +229,7 @@ SELECT CustomerName, CHAR_LENGTH(CustomerName) AS LengthOfName FROM Customers; > > 上記の例は、 `Customers`という名前のテーブルと、テーブル内に`CustomerName`という名前の列を持つデータベースが存在するという前提で動作します。 -### `CHARACTER_LENGTH()` {#character-length} +### `CHARACTER_LENGTH()` {#character_length} 関数`CHARACTER_LENGTH()`は関数`CHAR_LENGTH()`と同じです。どちらの関数も同じ出力を生成するため、同義語として使用できます。 @@ -295,7 +295,7 @@ SELECT 'Ti' 'DB' ' ' 'Server'; +-------------+ ``` -### `CONCAT_WS()` {#concat-ws} +### `CONCAT_WS()` {#concat_ws} `CONCAT_WS()`関数は、セパレーター付きの[`CONCAT()`](#concat)の形式で、指定されたセパレーターで連結された文字列を返します。 @@ -433,7 +433,7 @@ SELECT ELT(3, 'This', 'is', 'TiDB'); 上記の例では、 3 番目の要素である`'TiDB'`返します。 -### `EXPORT_SET()` {#export-set} +### `EXPORT_SET()` {#export_set} `EXPORT_SET()`関数は、指定された数（ `number_of_bits` ）の`on`または`off`の値からなる文字列を返します。これらの値は、オプションで`separator`で区切られます。これらの値は、 `bits`引数の対応するビットが`1`であるかどうかに基づいて決定されます。最初の値は`bits`の右端（最下位）ビットに対応します。 @@ -512,7 +512,7 @@ SELECT FIELD('needle', 'A', 'needle', 'in', 'a', 'haystack'); 1 row in set (0.00 sec) ``` -### `FIND_IN_SET()` {#find-in-set} +### `FIND_IN_SET()` {#find_in_set} 2 番目の引数内の最初の引数のインデックス位置を返します。 @@ -580,7 +580,7 @@ mysql> SELECT FORMAT(12.36, 2); +------------------+ ``` -### `FROM_BASE64()` {#from-base64} +### `FROM_BASE64()` {#from_base64} `FROM_BASE64()`関数は、 [ベース64](https://datatracker.ietf.org/doc/html/rfc4648)エンコードされた文字列をデコードし、デコードされた結果を 16 進形式で返すために使用されます。 @@ -1350,7 +1350,7 @@ SELECT CONCAT('«',LTRIM(' hello'),'»'); +------------------------------------+ 1 row in set (0.00 sec) -### `MAKE_SET()` {#make-set} +### `MAKE_SET()` {#make_set} `MAKE_SET()`関数は、 `bits`引数の対応するビットが`1`に設定されているかどうかに基づいて、コンマで区切られた文字列のセットを返します。 @@ -1548,7 +1548,7 @@ SELECT n, OCT(n) FROM nr; +------+--------+ 20 rows in set (0.00 sec) -### `OCTET_LENGTH()` {#octet-length} +### `OCTET_LENGTH()` {#octet_length} [`LENGTH()`](#length)の同義語。 @@ -1681,7 +1681,7 @@ WHERE +------+ 1 row in set (0.01 sec) -### `REGEXP_INSTR()` {#regexp-instr} +### `REGEXP_INSTR()` {#regexp_instr} 正規表現に一致する部分文字列の開始インデックスを返します（MySQLと部分的に互換性があります。詳細については[MySQLとの正規表現の互換性](#regular-expression-compatibility-with-mysql)参照してください）。 @@ -1802,7 +1802,7 @@ SELECT REGEXP_INSTR('abcabc','A' COLLATE utf8mb4_bin); +------------------------------------------------+ 1 row in set (0.00 sec) -### `REGEXP_LIKE()` {#regexp-like} +### `REGEXP_LIKE()` {#regexp_like} 文字列が正規表現に一致するかどうか（MySQLと部分的に互換性があります。詳細については[MySQLとの正規表現の互換性](#regular-expression-compatibility-with-mysql)参照してください）。 @@ -1849,7 +1849,7 @@ SELECT REGEXP_LIKE('abc','^A','i'); +-----------------------------+ 1 row in set (0.00 sec) -### `REGEXP_REPLACE()` {#regexp-replace} +### `REGEXP_REPLACE()` {#regexp_replace} 正規表現に一致する部分文字列を置き換えます（MySQLと部分的に互換性があります。詳しくは[MySQLとの正規表現の互換性](#regular-expression-compatibility-with-mysql)参照してください）。 @@ -1931,7 +1931,7 @@ SELECT REGEXP_REPLACE('TooDB', 'O{2}','i',1,1,'i'); +---------------------------------------------+ 1 row in set (0.00 sec) -### `REGEXP_SUBSTR()` {#regexp-substr} +### `REGEXP_SUBSTR()` {#regexp_substr} 正規表現に一致する部分文字列を返します（MySQLと部分的に互換性があります。詳細については[MySQLとの正規表現の互換性](#regular-expression-compatibility-with-mysql)参照してください）。 @@ -2046,7 +2046,7 @@ SELECT REPEAT('ha',3); 指定されたとおりに部分文字列を返します。 -### `SUBSTRING_INDEX()` {#substring-index} +### `SUBSTRING_INDEX()` {#substring_index} `SUBSTRING_INDEX()`関数は、指定された区切り文字とカウントに基づいて文字列から部分文字列を抽出するために使用されます。この関数は、CSVデータの解析やログファイルの処理など、特定の区切り文字で区切られたデータを扱う場合に特に便利です。 @@ -2095,7 +2095,7 @@ SELECT SUBSTRING_INDEX('www.tidbcloud.com', '.', -1); +------------------------------------------+ ``` -### `TO_BASE64()` {#to-base64} +### `TO_BASE64()` {#to_base64} `TO_BASE64()`関数は、指定された引数をBase64エンコードされた文字列に変換し、現在の接続の文字セットと照合順序に従って結果を返します。Base64エンコードされた文字列は、 [`FROM_BASE64()`](#from_base64)関数を使用してデコードできます。 @@ -2221,7 +2221,7 @@ SELECT UPPER('bigdata') AS result_upper, UPPER(null) AS result_null; +--------------+-------------+ ``` -### `WEIGHT_STRING()` {#weight-string} +### `WEIGHT_STRING()` {#weight_string} `WEIGHT_STRING()`関数は、入力文字列の重み文字列（バイナリ文字）を返します。これは主に、複数文字セットのシナリオにおけるソートや比較演算に使用されます。引数が`NULL`の場合、 `NULL`返します。構文は次のとおりです。 @@ -2268,7 +2268,7 @@ SELECT HEX(WEIGHT_STRING('ab' AS CHAR(3))) AS char_result, HEX(WEIGHT_STRING('ab MySQLはInternational Components for Unicode (ICU)を使用して正規表現を実装し、TiDBはRE2を使用しています。2つのライブラリの構文の違いについては、 [ICUの文書](https://unicode-org.github.io/icu/userguide/)と[RE2 構文](https://github.com/google/re2/wiki/Syntax)を参照してください。 -### match_type互換性 {#code-match-type-code-compatibility} +### match_type互換性 {#match_type-compatibility} TiDB と MySQL 間の`match_type`の値オプションは次のとおりです。 diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index 168be1a46d220..4aeb6d02bacb6 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -57,7 +57,7 @@ summary: TiDB 固有の関数の使用法について学習します。 -## 現在のリソースグループ {#current-resource-group} +## 現在のリソースグループ {#current_resource_group} `CURRENT_RESOURCE_GROUP()`機能は、現在のセッションがバインドされているリソースグループ名を表示するために使用されます。3 [リソース管理](/tidb-resource-control-ru-groups.md)機能を有効にすると、SQL ステートメントで使用できるリソースは、バインドされているリソースグループのリソースクォータによって制限されます。 @@ -101,11 +101,11 @@ SELECT CURRENT_RESOURCE_GROUP(); +--------------------------+ 1 row in set (0.00 sec) -## TIDB_BOUNDED_STALENESS {#tidb-bounded-staleness} +## TIDB_BOUNDED_STALENESS {#tidb_bounded_staleness} `TIDB_BOUNDED_STALENESS()`関数は[`AS OF TIMESTAMP`](/as-of-timestamp.md)構文の一部として使用されます。 -## TIDB_CURRENT_TSO {#tidb-current-tso} +## TIDB_CURRENT_TSO {#tidb_current_tso} `TIDB_CURRENT_TSO()`関数は、現在のトランザクションの[TSO](/tso.md)を返します。これはシステム変数[`tidb_current_ts`](/system-variables.md#tidb_current_ts)に似ています。 @@ -137,7 +137,7 @@ SELECT @@tidb_current_ts; +--------------------+ 1 row in set (0.00 sec) -## TIDB_DECODE_BINARY_PLAN {#tidb-decode-binary-plan} +## TIDB_DECODE_BINARY_PLAN {#tidb_decode_binary_plan} `TIDB_DECODE_BINARY_PLAN(binary_plan)`関数は、 [`STATEMENTS_SUMMARY`](/statement-summary-tables.md)表の`BINARY_PLAN`列にあるようなバイナリ プランをデコードします。 @@ -158,7 +158,7 @@ SELECT BINARY_PLAN,TIDB_DECODE_BINARY_PLAN(BINARY_PLAN) FROM information_schema. 1 row in set (0.00 sec) -## TIDB_デコード_キー {#tidb-decode-key} +## TIDB_デコード_キー {#tidb_decode_key} `TIDB_DECODE_KEY()`関数は、TiDBでエンコードされたキーエントリを、 `_tidb_rowid`と`table_id`含むJSON構造にデコードします。これらのエンコードされたキーは、一部のシステムテーブルとログ出力に存在します。 @@ -262,7 +262,7 @@ ORDER BY `TIDB_DECODE_KEY`成功した場合は有効な JSON を返し、デコードに失敗した場合は引数の値を返します。 -## TIDB_デコード_プラン {#tidb-decode-plan} +## TIDB_デコード_プラン {#tidb_decode_plan} TiDB実行プランは、スロークエリログにエンコードされた形式で保存されています。1関数`TIDB_DECODE_PLAN()` 、エンコードされたプランを人間が読める形式にデコードするために使用されます。 @@ -280,7 +280,7 @@ SELECT tidb_decode_plan('8QIYMAkzMV83CQEH8E85LjA0CWRhdGE6U2VsZWN0aW9uXzYJOTYwCXR └─TableFullScan_5 cop[tikv] 960 table:t, keep order:false, stats:pseudo 960 tikv_task:{time:153µs, loops:960} N/A N/A ``` -## TIDB_DECODE_SQL_DIGESTS {#tidb-decode-sql-digests} +## TIDB_DECODE_SQL_DIGESTS {#tidb_decode_sql_digests} `TIDB_DECODE_SQL_DIGESTS()`関数は、クラスタ内のSQLダイジェストセットに対応する正規化されたSQL文（フォーマットと引数のない形式）を照会するために使用されます。この関数は1つまたは2つの引数を取ります。 @@ -333,7 +333,7 @@ SELECT TIDB_DECODE_SQL_DIGESTS(@digests, 10); - [明細書要約表](/statement-summary-tables.md) - [`INFORMATION_SCHEMA.TIDB_TRX`](/information-schema/information-schema-tidb-trx.md) -## TIDB_ENCODE_SQL_DIGEST {#tidb-encode-sql-digest} +## TIDB_ENCODE_SQL_DIGEST {#tidb_encode_sql_digest} `TIDB_ENCODE_SQL_DIGEST(query_str)`クエリ文字列の SQL ダイジェストを返します。 @@ -361,7 +361,7 @@ SELECT TIDB_ENCODE_SQL_DIGEST('SELECT 2'); +------------------------------------------------------------------+ 1 row in set (0.00 sec) -## TIDB_IS_DDL_OWNER {#tidb-is-ddl-owner} +## TIDB_IS_DDL_OWNER {#tidb_is_ddl_owner} 接続しているインスタンスが DDL 所有者である場合、 `TIDB_IS_DDL_OWNER()`関数は`1`返します。 @@ -376,7 +376,7 @@ SELECT TIDB_IS_DDL_OWNER(); +---------------------+ 1 row in set (0.00 sec) -## TIDB_PARSE_TSO {#tidb-parse-tso} +## TIDB_PARSE_TSO {#tidb_parse_tso} `TIDB_PARSE_TSO()`関数は、TiDB TSO タイムスタンプから物理タイムスタンプを抽出します。3 [TSO](/tso.md) Time Stamp Oracle を表し、PD (Placement Driver) によってトランザクションごとに発行される単調に増加するタイムスタンプです。 @@ -402,7 +402,7 @@ ROLLBACK; ここで`TIDB_PARSE_TSO` 、セッション変数`tidb_current_ts`で利用可能なタイムスタンプ番号から物理タイムスタンプを抽出するために使用されています。タイムスタンプはトランザクションごとに発行されるため、この関数はトランザクション内で実行されます。 -## TIDB_PARSE_TSO_LOGICAL {#tidb-parse-tso-logical} +## TIDB_PARSE_TSO_LOGICAL {#tidb_parse_tso_logical} `TIDB_PARSE_TSO_LOGICAL(tso)`関数は、 [TSO](/tso.md)タイムスタンプの論理部分を返します。 @@ -428,7 +428,7 @@ SELECT TIDB_PARSE_TSO_LOGICAL(450456244814610434); +--------------------------------------------+ 1 row in set (0.00 sec) -## TIDB_ROW_CHECKSUM {#tidb-row-checksum} +## TIDB_ROW_CHECKSUM {#tidb_row_checksum} `TIDB_ROW_CHECKSUM()`関数は、行のチェックサム値を照会するために使用されます。この関数は、FastPlanプロセス内の`SELECT`ステートメントでのみ使用できます。つまり、 `SELECT TIDB_ROW_CHECKSUM() FROM t WHERE id = ?`や`SELECT TIDB_ROW_CHECKSUM() FROM t WHERE id IN (?, ?, ...)`のようなステートメントで照会できます。 @@ -465,7 +465,7 @@ SELECT *, TIDB_ROW_CHECKSUM() FROM t WHERE id = 1; 1 row in set (0.000 sec) ``` -## TIDB_シャード {#tidb-shard} +## TIDB_シャード {#tidb_shard} `TIDB_SHARD()`関数は、インデックスホットスポットを分散させるためのシャードインデックスを作成します。シャードインデックスは、 `TIDB_SHARD()`関数をプレフィックスとして持つ式インデックスです。 @@ -518,7 +518,7 @@ SELECT *, TIDB_ROW_CHECKSUM() FROM t WHERE id = 1; CREATE TABLE test(id INT PRIMARY KEY CLUSTERED, a INT, b INT, UNIQUE KEY uk((tidb_shard(a)), a)); ``` -## TIDB_バージョン {#tidb-version} +## TIDB_バージョン {#tidb_version} `TIDB_VERSION()`関数は、接続している TiDBサーバーのバージョンとビルドの詳細を取得するために使用されます。この関数は、GitHub で問題を報告するときに使用できます。 @@ -540,7 +540,7 @@ Store: tikv 1 row in set (0.00 sec) ``` -## VITESS_ハッシュ {#vitess-hash} +## VITESS_ハッシュ {#vitess_hash} `VITESS_HASH(num)`関数は、Vitess と同じ方法で数値をハッシュするために使用されます。これは、Vitess から TiDB への移行を容易にするためのものです。 @@ -557,7 +557,7 @@ SELECT VITESS_HASH(123); +---------------------+ 1 row in set (0.00 sec) -## TIDB_ENCODE_INDEX_KEY {#tidb-encode-index-key} +## TIDB_ENCODE_INDEX_KEY {#tidb_encode_index_key} `TIDB_ENCODE_INDEX_KEY()`関数は、指定されたインデックスキーを16進文字列にエンコードします。構文は次のとおりです。 @@ -622,7 +622,7 @@ SELECT TIDB_ENCODE_INDEX_KEY('test', 't', 'idx', 2, 1); +----------------------------------------------------------------------------+ 1 row in set (0.00 sec) -## TIDB_ENCODE_RECORD_KEY {#tidb-encode-record-key} +## TIDB_ENCODE_RECORD_KEY {#tidb_encode_record_key} `TIDB_ENCODE_RECORD_KEY()`関数は、指定された行レコードキーを16進文字列にエンコードします。関数の構文は次のとおりです。 @@ -670,7 +670,7 @@ SELECT TIDB_DECODE_KEY('7480000000000000845f728000000000000001'); +-----------------------------------------------------------+ 1 row in set (0.00 sec) -## TIDB_MVCC_INFO {#tidb-mvcc-info} +## TIDB_MVCC_INFO {#tidb_mvcc_info} キーの[MVCC (マルチバージョン同時実行制御)](https://docs.pingcap.com/tidb/stable/glossary#multi-version-concurrency-control-mvcc)の情報を返します。キーを取得するには[`TIDB_ENCODE_INDEX_KEY`](#tidb_encode_index_key)関数を使用できます。 diff --git a/functions-and-operators/window-functions.md b/functions-and-operators/window-functions.md index 9e2e1bda5e9b2..b98ca582be596 100644 --- a/functions-and-operators/window-functions.md +++ b/functions-and-operators/window-functions.md @@ -31,7 +31,7 @@ TiDBは、 `GROUP_CONCAT()`と`APPROX_PERCENTILE()`を除く[`GROUP BY`集計関 | [`RANK()`](#rank) | パーティション内の現在の行の順位を返します。順位にはギャップがある場合があります。 | | [`ROW_NUMBER()`](#row_number) | パーティション内の現在の行番号を返します。 | -## `CUME_DIST()` {#cume-dist} +## `CUME_DIST()` {#cume_dist} `CUME_DIST()`値のグループ内における値の累積分布を計算します。値のグループをソートするには、 `ORDER BY`句と`CUME_DIST()`を使用する必要があります。そうしないと、この関数は期待される値を返しません。 @@ -63,7 +63,7 @@ FROM +------+------------------------------+ 4 rows in set (0.00 sec) -## `DENSE_RANK()` {#dense-rank} +## `DENSE_RANK()` {#dense_rank} `DENSE_RANK()`関数は現在行の順位を返します。3 [`RANK()`](#rank)と似ていますが、同順位（同じ値と順序条件を共有する行）の場合に空白を残しません。 @@ -97,7 +97,7 @@ FROM ( +----+--------------------------------+ 6 rows in set (0.00 sec) -## `FIRST_VALUE()` {#first-value} +## `FIRST_VALUE()` {#first_value} `FIRST_VALUE(expr)`ウィンドウ内の最初の値を返します。 @@ -174,7 +174,7 @@ FROM +------+----------------+ 10 rows in set (0.01 sec) -## `LAST_VALUE()` {#last-value} +## `LAST_VALUE()` {#last_value} `LAST_VALUE()`関数はウィンドウ内の最後の値を返します。 @@ -256,7 +256,7 @@ FROM +------+-----------------+ 10 rows in set (0.00 sec) -## `NTH_VALUE()` {#nth-value} +## `NTH_VALUE()` {#nth_value} `NTH_VALUE(expr, n)`関数はウィンドウの`n`番目の値を返します。 @@ -345,7 +345,7 @@ FROM ``` -## `PERCENT_RANK()` {#percent-rank} +## `PERCENT_RANK()` {#percent_rank} `PERCENT_RANK()`関数は、現在の行の値よりも小さい値を持つ行の割合を示す 0 から 1 までの数値を返します。 @@ -415,7 +415,7 @@ FROM ( +----+--------------------------+--------------------------------+ 6 rows in set (0.00 sec) -## `ROW_NUMBER()` {#row-number} +## `ROW_NUMBER()` {#row_number} `ROW_NUMBER()`結果セット内の現在の行の行番号を返します。 diff --git a/glossary.md b/glossary.md index 2bf4423b4f092..770b692ac8189 100644 --- a/glossary.md +++ b/glossary.md @@ -15,7 +15,7 @@ summary: TiDBに関する用語集。 -## A {#a-id-a-class-letter-href-a-a-a} +## A {#a} ### ACID {#acid} @@ -29,9 +29,9 @@ ACIDとは、トランザクションの4つの主要な特性、すなわち原 - **永続性**とは、一度トランザクションがコミットされると、システム障害が発生した場合でもコミットされた状態が維持されることを意味します。TiKVは永続ストレージを使用して永続性を確保しています。 -## B {#a-id-b-class-letter-href-b-b-a} +## B {#b} -### Backup & Restore (BR) {#backup-x26-restore-br} +### Backup & Restore (BR) {#backup--restore-br} BRは TiDB のバックアップおよび復元ツールです。詳細については[BR概要](/br/backup-and-restore-overview.md)参照してください。 @@ -49,7 +49,7 @@ TiDBでは、 `br`はバックアップまたはリストアに使用される[b [リージョン](#regionpeerraft-group)は論理的にバケットと呼ばれるいくつかの小さな範囲に分割されます。TiKV はバケットごとにクエリ統計を収集し、バケットの状態を PD に報告します。詳細については、 [バケット設計ドキュメント](https://github.com/tikv/rfcs/blob/master/text/0082-dynamic-size-region.md#bucket)を参照してください。 -## C {#a-id-c-class-letter-href-c-c-a} +## C {#c} ### キャッシュされたテーブル {#cached-table} @@ -87,7 +87,7 @@ RocksDBとTiKVでは、カラムファミリー（CF）は、データベース コプロセッサーは、TiDBと計算ワークロードを共有するコプロセッシングメカニズムです。ストレージレイヤー（TiKVまたはTiFlash）に配置され、リージョンごとにTiDBからの計算[プッシュダウンする](/functions-and-operators/expressions-pushed-down.md)共同で処理します。 -## D {#a-id-d-class-letter-href-d-d-a} +## D {#d} ### Dumpling {#dumpling} @@ -123,7 +123,7 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ 動的プルーニングモードは、TiDBがパーティションテーブルにアクセスするモードの1つです。動的プルーニングモードでは、各演算子が複数のパーティションへの直接アクセスをサポートします。そのため、TiDBはUnionを使用しなくなります。Union操作を省略することで、実行効率が向上し、Unionの同時実行による問題を回避できます。 -## E {#a-id-e-class-letter-href-e-e-a} +## E {#e} ### 式インデックス or 関数インデックス {#expression-index} @@ -131,7 +131,7 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ 詳細については、 [インデックスの作成 -式インデックス or 関数インデックス](/sql-statements/sql-statement-create-index.md#expression-index)参照してください。 -## G {#a-id-g-class-letter-href-g-g-a} +## G {#g} ### ガベージコレクション（GC） {#garbage-collection-gc} @@ -145,7 +145,7 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ グローバルトランザクション識別子（GTID）は、MySQLバイナリログで使用される一意のトランザクションIDで、どのトランザクションが複製されたかを追跡するために使用されます。1 [データ移行（DM）](/dm/dm-overview.md) 、これらのIDを使用して一貫性のあるレプリケーションを保証します。 -## H {#a-id-h-class-letter-href-h-h-a} +## H {#h} ### ホットスポット {#hotspot} @@ -155,7 +155,7 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ ハイブリッドトランザクションおよび分析処理（HTAP）は、同一データベース内でOLTP（オンライントランザクション処理）とOLAP（オンライン分析処理）の両方のワークロードを可能にするデータベース機能です。TiDBでは、行ストレージにTiKV、列ストレージにTiFlashを使用することでHTAP機能が提供されます。詳細については、 [TiDB HTAPクイックスタート](/quick-start-with-htap.md)および[HTAPを探索する](/explore-htap.md)参照してください。 -## 私 {#a-id-i-class-letter-href-i-i-a} +## 私 {#i} ### インメモリ悲観的ロック {#in-memory-pessimistic-lock} @@ -165,7 +165,7 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ インデックスマージは、TiDB v4.0で導入されたテーブルアクセス方法です。この方法を使用すると、TiDBオプティマイザはテーブルごとに複数のインデックスを使用し、各インデックスから返される結果をマージできます。場合によっては、この方法によってフルテーブルスキャンが回避され、クエリの効率が向上します。インデックスマージは、v5.4以降、一般提供（GA）機能となっています。 -## K {#a-id-k-class-letter-href-k-k-a} +## K {#k} ### キー管理サービス（KMS） {#key-management-service-kms} @@ -175,9 +175,9 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ キーバリュー（KV）は、値を一意のキーに関連付けることで情報を保存する方法であり、迅速なデータ検索を可能にします。TiDBはTiKVを使用してテーブルとインデックスをキーバリューペアにマッピングし、データベース全体で効率的なデータストレージとアクセスを実現します。 -## L {#a-id-l-class-letter-href-l-l-a} +## L {#l} -### Leader／Follower／Learner {#leader-follower-learner} +### Leader／Follower／Learner {#leaderfollowerlearner} Raftグループ（ [仲間](#regionpeerraft-group)構成）では、Leader、Follower、Learnerがそれぞれ役割を担います。リーダーはすべてのクライアント要求を処理し、フォロワーにデータを複製します。グループリーダーが故障した場合、フォロワーの中から1人が新しいリーダーに選出されます。ラーナーは投票権を持たないフォロワーであり、複製データの追加処理のみに関与します。 @@ -195,7 +195,7 @@ Raftグループ（ [仲間](#regionpeerraft-group)構成）では、Leader、Fo 長期サポート (LTS) とは、長期間にわたって徹底的にテストおよびメンテナンスされるソフトウェア バージョンを指します。詳細については、 [TiDB バージョン管理](/releases/versioning.md)参照してください。 -## M {#a-id-m-class-letter-href-m-m-a} +## M {#m} ### 超並列処理（MPP） {#massively-parallel-processing-mpp} @@ -205,7 +205,7 @@ TiDBはv5.0以降、 TiFlashノードを介して大規模並列処理（MPP） [MVCC](https://en.wikipedia.org/wiki/Multiversion_concurrency_control)は、TiDBをはじめとするデータベースにおける並行性制御メカニズムです。トランザクションによって読み取られたメモリを処理することで、TiDBへの同時アクセスを実現し、同時読み取りと書き込みの競合によって発生するブロッキングを回避します。 -## O {#a-id-o-class-letter-href-o-o-a} +## O {#o} ### 旧価格 {#old-value} @@ -248,7 +248,7 @@ TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出 詳細については、 [TiDBの楽観的トランザクションモデル](/optimistic-transaction.md)参照してください。 -## P {#a-id-p-class-letter-href-p-p-a} +## P {#p} ### パーティショニング {#partitioning} @@ -258,7 +258,7 @@ TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出 PD Control (pd-ctl) は、TiDB クラスタ内の Placement Driver (PD) と対話するために使用されるコマンドライン ツールです。これを使用して、クラスタの状態情報を取得したり、クラスタ構成を変更したりできます。詳細については、 [PD Controlユーザーガイド](/pd-control.md)参照してください。 -### 保留中／ダウン中 {#pending-down} +### 保留中／ダウン中 {#pendingdown} 「保留中」と「ダウン」は、ピアの2つの特別な状態です。「保留中」とは、フォロワーまたはラーナーのRaftログがリーダーのログと大きく異なる状態を指します。保留中のフォロワーはリーダーに選出されません。「ダウン」とは、ピアが長時間リーダーに応答しなくなった状態を指し、通常は対応するノードがダウンしているか、ネットワークから孤立していることを意味します。 @@ -284,7 +284,7 @@ PointGetとは、一意インデックスまたは主インデックスによっ ほとんどの場合、SQL ステートメントを実行する際、オプティマイザは一部の列 ( `WHERE` `GROUP BY`の列など) の統計情報のみを使用します。これらの使用される列`ORDER BY`述語列と呼ばれます。詳細については、 [いくつかの列の統計情報を収集する](/statistics.md#collect-statistics-on-some-columns) `JOIN`してください。 -## Q {#a-id-q-class-letter-href-q-q-a} +## Q {#q} ### 1秒あたりのクエリ数（QPS） {#queries-per-second-qps} @@ -294,7 +294,7 @@ PointGetとは、一意インデックスまたは主インデックスによっ クォータリミッターは、TiDB v6.0.0 で導入された実験的機能です。TiKV がデプロイされているマシンにリソース制限がある場合（例えば、CPU が 4V、メモリが 16GB しかない場合）、TiKV のフォアグラウンドが読み書き要求を過剰に処理すると、バックグラウンドで使用される CPU リソースがこれらの要求の処理に使用され、TiKV のパフォーマンスの安定性に影響します。この状況を回避するために、クォータリミッターを[クォータ関連の設定項目](/tikv-configuration-file.md#quota)に設定して、フォアグラウンドで使用される CPU リソースを制限できます。 -## R {#a-id-r-class-letter-href-r-r-a} +## R {#r} ### Raft Engine {#raft-engine} @@ -306,7 +306,7 @@ TiKVクラスタ内のリージョンは、最初は分割されておらず、 リージョン分割の仕組みは、まず1つの初期リージョンを使用して鍵空間全体をカバーし、リージョンのサイズまたは鍵の数が閾値に達するたびに、既存のリージョンを分割して新しいリージョンを生成するというものです。 -### リージョン／仲間／Raftグループ {#region-peer-raft-group} +### リージョン／仲間／Raftグループ {#regionpeerraft-group} TiKV におけるデータストレージの最小単位はリージョンであり、それぞれがデータ範囲 (デフォルトでは 256 MiB) を表します。各リージョンには、デフォルトで 3 つのレプリカがあります。リージョンのレプリカはピアと呼ばれます。同じリージョンの複数のピアは、 Raftコンセンサスアルゴリズムを使用してデータを複製するため、ピアもRaftインスタンスのメンバーとなります。TiKV は、マルチ Raft を使用してデータを管理します。つまり、各リージョンには、対応する独立したRaftグループが存在します。 @@ -326,7 +326,7 @@ TiKV におけるデータストレージの最小単位はリージョンであ [RocksDB](https://rocksdb.org/)は、キーバリューstorageと読み書き機能を提供するLSMツリー構造のエンジンです。Facebookによって開発され、LevelDBをベースとしています。RocksDBはTiKVの中核となるストレージエンジンです。 -## S {#a-id-s-class-letter-href-s-s-a} +## S {#s} ### スケジューラ {#scheduler} @@ -349,7 +349,7 @@ TiKV におけるデータストレージの最小単位はリージョンであ 詳細については、 [ステイル読み取り](/stale-read.md)参照してください。 -### 静的ソート済みテーブル／ソート済み文字列テーブル（SST） {#static-sorted-table-sorted-string-table-sst} +### 静的ソート済みテーブル／ソート済み文字列テーブル（SST） {#static-sorted-table--sorted-string-table-sst} 静的ソートテーブルまたはソート文字列テーブルは、RocksDB（ [TiKV](/storage-engine/rocksdb-overview.md)で使用されているストレージエンジン）で使用されるファイルストレージ形式です。 @@ -357,7 +357,7 @@ TiKV におけるデータストレージの最小単位はリージョンであ ストアとは、TiKV クラスタ内のストレージノード (インスタンス`tikv-server` ) を指します。各ストアには、対応する TiKV インスタンスがあります。 -## T {#a-id-t-class-letter-href-t-t-a} +## T {#t} ### 一時テーブル {#temporary-table} @@ -399,7 +399,7 @@ Top SQLは、指定された時間範囲内でTiDBまたはTiKVノードの負 トランザクション/秒（TPS）とは、データベースが1秒間に処理するトランザクションの数であり、データベースのパフォーマンスとスループットを測定するための重要な指標です。 -## U {#a-id-u-class-letter-href-u-u-a} +## U {#u} ### 統一リソース識別子（URI） {#uniform-resource-identifier-uri} @@ -409,7 +409,7 @@ URI（Uniform Resource Identifier）は、リソースを識別するための UUID（Universally Unique Identifier）は、データベース内のレコードを一意に識別するために使用される128ビット（16バイト）の生成されたIDです。詳細については、 [UUID](/best-practices/uuid.md)参照してください。 -## V {#a-id-v-class-letter-href-v-v-a} +## V {#v} ### ベクトル検索 {#vector-search} diff --git a/grafana-tikv-dashboard.md b/grafana-tikv-dashboard.md index 17505c5e00585..7c3e5ee532604 100644 --- a/grafana-tikv-dashboard.md +++ b/grafana-tikv-dashboard.md @@ -208,7 +208,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 ![TiKV Dashboard - Scheduler metrics](/media/tikv-dashboard-scheduler.png) -### スケジューラ - コミット {#scheduler-commit} +### スケジューラ - コミット {#scheduler---commit} - スケジューラステージ合計：コミットコマンド実行時の、各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 - スケジューラコマンドの実行時間: コミットコマンドの実行に要する時間。 `1s`未満である必要があります。 @@ -222,7 +222,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 ![TiKV Dashboard - Scheduler commit metrics](/media/tikv-dashboard-scheduler-commit.png) -### スケジューラ - 悲観的ロールバック {#scheduler-pessimistic-rollback} +### スケジューラ - 悲観的ロールバック {#scheduler---pessimistic_rollback} - スケジューラステージ合計： `pessimistic_rollback`コマンド実行時の、各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 - スケジューラコマンドの実行時間: `pessimistic_rollback`コマンドの実行に要する時間。 `1s`より短くなければなりません。 @@ -234,7 +234,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - スケジューラのスキャン詳細[書き込み]: `pessimistic_rollback`コマンド実行時の書き込み CF のキー スキャン詳細 - スケジューラのスキャン詳細[デフォルト]: `pessimistic_rollback`コマンド実行時のデフォルト CF のキー スキャン詳細 -### スケジューラ - 事前書き込み {#scheduler-prewrite} +### スケジューラ - 事前書き込み {#scheduler---prewrite} - スケジューラステージ合計：プリライトコマンド実行時の、各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 - スケジューラコマンドの実行時間: プリライトコマンドの実行に要する時間。 `1s`未満である必要があります。 @@ -246,7 +246,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - スケジューラスキャン詳細[書き込み]: プリライトコマンド実行時の書き込みCFのキースキャン詳細 - スケジューラスキャン詳細[デフォルト]: プリライトコマンド実行時のデフォルトCFのキースキャン詳細 -### スケジューラ - ロールバック {#scheduler-rollback} +### スケジューラ - ロールバック {#scheduler---rollback} - スケジューラステージ合計：ロールバックコマンド実行時の、各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 - スケジューラコマンドの実行時間: ロールバックコマンドの実行に要する時間。 `1s`未満である必要があります。 @@ -318,7 +318,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - スレッドの自発的コンテキストスイッチ: TiKVスレッドの自発的コンテキストスイッチの数 - スレッドの非自発的コンテキストスイッチ: TiKVスレッドの非自発的コンテキストスイッチの数 -### RocksDB - kv/raft {#rocksdb-kv-raft} +### RocksDB - kv/raft {#rocksdb---kvraft} - 取得操作: 1秒あたりの取得操作の回数 - 取得時間：取得操作の実行に要した時間 @@ -380,7 +380,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - rewrite: Raft Engineによって書き換えられたエントリの数 - append: Raft Engineによって追加されたエントリの数 -### Titan - すべて {#titan-all} +### Titan - すべて {#titan---all} - Blobファイル数：Titan Blobファイルの数 - Blobファイルサイズ：Titan Blobファイルの合計サイズ @@ -523,7 +523,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - リージョンオペレーション回数の取得：コーディネーターがPDからリージョン情報を要求した回数 - アドバンストリガー時間：コーディネーターがチェックポイントを進めることを試みるまでにかかる時間 -### バックアップとインポート {#backup-x26-import} +### バックアップとインポート {#backup--import} - インポート時のCPU使用率：SSTインポーターによって集計されたCPU使用率。 - インポートスレッド数：SSTインポーターが使用するスレッドの数。 diff --git a/identify-slow-queries.md b/identify-slow-queries.md index 75433fa271d97..7dd4310ae5784 100644 --- a/identify-slow-queries.md +++ b/identify-slow-queries.md @@ -172,7 +172,7 @@ TiKVコプロセッサータスクフィールド： - `Storage_from_kv` : v8.5.5 で導入され、このステートメントが TiKV からデータを読み取ったかどうかを示します。 - `Storage_from_mpp` : v8.5.5 で導入され、このステートメントがTiFlashからデータを読み取ったかどうかを示します。 -## tidb_slow_log_rulesを使用する {#use-code-tidb-slow-log-rules-code} +## tidb_slow_log_rulesを使用する {#use-tidb_slow_log_rules} [`tidb_slow_log_rules`](/system-variables.md#tidb_slow_log_rules-new-in-v856)は、スロークエリログのトリガールールを定義するために使用され、多次元メトリックの組み合わせをサポートします。スローログの「ターゲットサンプリング」と「問題再現」に適しており、特定のメトリックの組み合わせに基づいて対象のステートメントをフィルタリングできます。 @@ -389,7 +389,7 @@ TiDB 4.0 では、すべての TiDB ノードのスロー クエリ情報を照 `CLUSTER_SLOW_QUERY`テーブルに対してクエリを実行すると、TiDB は他のノードからすべてのスロークエリ情報を取得して 1 つの TiDB ノードで操作を実行するのではなく、計算と判断を他のノードにプッシュします。 -## SLOW_QUERY / CLUSTER_SLOW_QUERY使用例 {#code-slow-query-code-code-cluster-slow-query-code-usage-examples} +## SLOW_QUERY / CLUSTER_SLOW_QUERY使用例 {#slow_query--cluster_slow_query-usage-examples} ### 上位N件のスロークエリ {#top-n-slow-queries} @@ -412,7 +412,7 @@ limit 2; | 0.734982725 | select t0.c0, t1.c1 from t_slim t0, t_wide t1 where t0.c0=t1.c0; | +--------------+------------------------------------------------------------------+ -### testユーザーの上位N件のスロークエリを照会する {#query-the-top-n-slow-queries-of-the-code-test-code-user} +### testユーザーの上位N件のスロークエリを照会する {#query-the-top-n-slow-queries-of-the-test-user} 次の例では、 `test`ユーザーによって実行されたスロークエリが照会され、最初の 2 つの結果が実行時間の逆順に表示されます。 @@ -472,7 +472,7 @@ limit 2; | select * from t1 where a=2; | 0.401313532 | +-----------------------------+-------------+ -## 擬似統計statsを使用して、スロークエリをクエリする {#query-slow-queries-with-pseudo-code-stats-code} +## 擬似統計statsを使用して、スロークエリをクエリする {#query-slow-queries-with-pseudo-stats} ```sql select query, query_time, stats @@ -619,7 +619,7 @@ TiDB は`tidb_slow_query_file` `INFORMATION_SCHEMA.SLOW_QUERY`を使用します set tidb_slow_query_file = "/path-to-log/tidb-slow.log" ``` -### pt-query-digestを使用してTiDBのスローログを解析する {#parse-tidb-slow-logs-with-code-pt-query-digest-code} +### pt-query-digestを使用してTiDBのスローログを解析する {#parse-tidb-slow-logs-with-pt-query-digest} TiDB のスローログを解析するには、 `pt-query-digest`を使用します。 @@ -663,7 +663,7 @@ pt-query-digest --report tidb-slow.log `wait_time`が非常に大きく、 `process_time`が非常に小さいステートメントは、通常は問題になりません。これは、そのステートメントが実際に問題のあるステートメントによってブロックされ、実行キューで待機する必要があるため、応答時間が大幅に長くなるためです。 -### ADMIN SHOW SLOWコマンド {#code-admin-show-slow-code-command} +### ADMIN SHOW SLOWコマンド {#admin-show-slow-command} TiDBログファイルに加えて、 `ADMIN SHOW SLOW`コマンドを実行することで、スロークエリを特定できます。 diff --git a/index-advisor.md b/index-advisor.md index dce97cb8f676f..e0240fe0166f1 100644 --- a/index-advisor.md +++ b/index-advisor.md @@ -15,7 +15,7 @@ TiDB v8.5.0では、クエリパフォーマンスを向上させるインデッ [新しい指標を推奨する](#recommend-indexes-using-the-recommend-index-statement)ことに加えて、インデックスアドバイザーは効率的なインデックス管理を確保するために[非アクティブなインデックスの削除](#remove-unused-indexes)も提案します。 -## RECOMMEND INDEXステートメントを使用してインデックスを推奨します。 {#recommend-indexes-using-the-code-recommend-index-code-statement} +## RECOMMEND INDEXステートメントを使用してインデックスを推奨します。 {#recommend-indexes-using-the-recommend-index-statement} TiDB では、インデックス アドバイザ タスク用の`RECOMMEND INDEX` SQL ステートメントが導入されました。 `RUN`サブコマンドは、過去のワークロードを分析し、推奨事項をシステム テーブルに保存します。 `FOR`オプションを使用すると、以前に実行されていない特定の SQL ステートメントを対象にすることができます。さらに、[オプション](#recommend-index-options)の を使用して高度な制御を行うこともできます。構文は次のとおりです。 @@ -105,7 +105,7 @@ SELECT * FROM mysql.index_advisor_results; +----+---------------------+---------------------+-------------+------------+------------+---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------+-------+ ``` -### RECOMMEND INDEXオプションの推奨 {#code-recommend-index-code-options} +### RECOMMEND INDEXオプションの推奨 {#recommend-index-options} `RECOMMEND INDEX`ステートメントのオプションを設定および表示して、ワークロードに合わせて動作を微調整するには、次のようにします。 @@ -155,7 +155,7 @@ Query OK, 1 row affected (0.00 sec) バージョン8.0.0以降では、 [`schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md)と[`INFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md)を使用して、ワークロード内の非アクティブなインデックスを特定できます。これらのインデックスを削除することで、ストレージ容量を節約し、オーバーヘッドを削減できます。本番環境では、対象のインデックスを完全に削除する前に、まず非表示にして、1回の業務サイクルにわたって影響を確認することを強くお勧めします。 -### sys.schema_unused_indexesを使用します {#use-code-sys-schema-unused-indexes-code} +### sys.schema_unused_indexesを使用します {#use-sysschema_unused_indexes} [`sys.schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md)ビューは、すべての TiDB インスタンスの最後の起動以降に使用されていないインデックスを識別します。このビューは、スキーマ、テーブル、および列情報を含むシステム テーブルに基づいており、スキーマ、テーブル、およびインデックス名を含む、各インデックスの完全な仕様を提供します。このビューを照会することで、どのインデックスを非表示にするか、または削除するかを決定できます。 @@ -167,7 +167,7 @@ Query OK, 1 row affected (0.00 sec) > SELECT START_TIME,UPTIME FROM INFORMATION_SCHEMA.CLUSTER_INFO WHERE TYPE='tidb'; > ``` -### INFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGEを使用してください。 {#use-code-information-schema-cluster-tidb-index-usage-code} +### INFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGEを使用してください。 {#use-information_schemacluster_tidb_index_usage} [`INFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md)テーブルには、選択バケット、最終アクセス時刻、アクセスされた行数などのメトリックが格納されています。以下の例は、このテーブルに基づいて未使用または非効率なインデックスを特定するクエリを示しています。 diff --git a/information-schema/information-schema-data-lock-waits.md b/information-schema/information-schema-data-lock-waits.md index 3bd5a9d159dbc..ec6ebb4daba26 100644 --- a/information-schema/information-schema-data-lock-waits.md +++ b/information-schema/information-schema-data-lock-waits.md @@ -3,7 +3,7 @@ title: DATA_LOCK_WAITS summary: DATA_LOCK_WAITS` information_schema テーブルについて学習します。 --- -# データロック待機 {#data-lock-waits} +# データロック待機 {#data_lock_waits} `DATA_LOCK_WAITS`テーブルには、悲観的トランザクションのロック待機情報とブロックされている楽観的トランザクションの情報を含む、クラスター内のすべての TiKV ノードで進行中のロック待機情報が表示されます。 @@ -40,7 +40,7 @@ DESC data_lock_waits; > - 異なる TiKV ノードからの情報が、同じ時刻のスナップショットであるとは限りません。 > - `SQL_DIGEST`列の情報（SQLダイジェスト）は、正規化されたSQL文から計算されたハッシュ値です。`SQL_DIGEST_TEXT`列の情報は、内部的にステートメントサマリーテーブルから照会されるため、対応するステートメントが内部的に見つからない可能性があります。SQLダイジェストとステートメントサマリーテーブルの詳細については、 [ステートメントサマリーテーブル](/statement-summary-tables.md)参照してください。 -## `KEY_INFO` {#key-info} +## `KEY_INFO` {#key_info} `KEY_INFO`列は`KEY`列の詳細情報です。情報はJSON形式で表示されます。各フィールドの説明は以下の通りです。 diff --git a/information-schema/information-schema-deadlocks.md b/information-schema/information-schema-deadlocks.md index 5ffe481af7835..573d47b77e72a 100644 --- a/information-schema/information-schema-deadlocks.md +++ b/information-schema/information-schema-deadlocks.md @@ -61,7 +61,7 @@ DESC deadlocks; > - [PROCESS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_process)権限を持つユーザーのみがこのテーブルをクエリできます。 > - `CURRENT_SQL_DIGEST`列の情報（SQLダイジェスト）は、正規化されたSQL文から計算されたハッシュ値です。`CURRENT_SQL_DIGEST_TEXT`列の情報は、内部的にステートメントサマリーテーブルから照会されるため、対応するステートメントが内部的に見つからない可能性があります。SQLダイジェストとステートメントサマリーテーブルの詳細については、 [ステートメントサマリーテーブル](/statement-summary-tables.md)参照してください。 -## `KEY_INFO` {#key-info} +## `KEY_INFO` {#key_info} `KEY_INFO`列は`KEY`列の詳細情報です。情報はJSON形式で表示されます。各フィールドの説明は以下の通りです。 @@ -192,7 +192,7 @@ SELECT * FROM INFORMATION_SCHEMA.DEADLOCKS; 上記のクエリ結果の`DEADLOCK_ID`列を見ると、最初の2行はデッドロックエラーの情報を表しており、互いに待機する2つのトランザクションがデッドロックを形成していることがわかります。次の3行は別のデッドロックエラーの情報を表しており、循環的に待機する3つのトランザクションがデッドロックを形成しています。 -## クラスターデッドロック {#cluster-deadlocks} +## クラスターデッドロック {#cluster_deadlocks} `CLUSTER_DEADLOCKS`テーブルは、クラスター全体の各 TiDB ノードの最近のデッドロック エラーに関する情報を返します。これは、各ノードの`DEADLOCKS`テーブルの情報を組み合わせたものです。5 `CLUSTER_DEADLOCKS`は、異なる TiDB ノードを区別するために、ノードの IP アドレスとポートを表示する追加の`INSTANCE`列も含まれています。 diff --git a/information-schema/information-schema-processlist.md b/information-schema/information-schema-processlist.md index a2d9342999399..3361f4b064746 100644 --- a/information-schema/information-schema-processlist.md +++ b/information-schema/information-schema-processlist.md @@ -137,7 +137,7 @@ RESOURCE_GROUP: default -## クラスタープロセスリスト {#cluster-processlist} +## クラスタープロセスリスト {#cluster_processlist} `CLUSTER_PROCESSLIST`は`PROCESSLIST`に対応するクラスタシステムテーブルです。これは、クラスタ内のすべての TiDB ノードの`PROCESSLIST`情報を照会するために使用されます。 `CLUSTER_PROCESSLIST`のテーブルスキーマには`PROCESSLIST`よりも1つ多い列、つまり`INSTANCE`列があり、このデータ行の元となる TiDB ノードのアドレスが格納されます。 diff --git a/information-schema/information-schema-slow-query.md b/information-schema/information-schema-slow-query.md index cb40144363e92..66f61fde0d9fb 100644 --- a/information-schema/information-schema-slow-query.md +++ b/information-schema/information-schema-slow-query.md @@ -3,7 +3,7 @@ title: SLOW_QUERY summary: SLOW_QUERY` INFORMATION_SCHEMA テーブルについて学習してください。 --- -# スロークエリ {#slow-query} +# スロークエリ {#slow_query} @@ -128,7 +128,7 @@ DESC SLOW_QUERY; `Session_connect_attrs`カラムには、スローログから解析されたセッション接続属性が JSON 形式で格納されます。TiDB は、[`performance_schema_session_connect_attrs_size`](/system-variables.md#performance_schema_session_connect_attrs_size-new-in-v857) を使用して、このフィールドに書き込まれる最大ペイロードサイズを制御します。 -## CLUSTER_SLOW_QUERY テーブル {#cluster-slow-query-table} +## CLUSTER_SLOW_QUERY テーブル {#cluster_slow_query-table} `CLUSTER_SLOW_QUERY`テーブルは、クラスター内のすべてのノードのスロークエリ情報を提供します。これは、TiDB スローログファイルの解析結果です。 `CLUSTER_SLOW_QUERY`テーブルは、 `SLOW_QUERY`と同様に使用できます。 `CLUSTER_SLOW_QUERY`テーブルのテーブルスキーマは`SLOW_QUERY`テーブルとは異なり`INSTANCE`に`CLUSTER_SLOW_QUERY`列が追加されています。 `INSTANCE`列は、スロークエリの行情報の TiDB ノードアドレスを表します。 diff --git a/information-schema/information-schema-tidb-index-usage.md b/information-schema/information-schema-tidb-index-usage.md index 3e6b7753af79d..648b801807313 100644 --- a/information-schema/information-schema-tidb-index-usage.md +++ b/information-schema/information-schema-tidb-index-usage.md @@ -3,7 +3,7 @@ title: TIDB_INDEX_USAGE summary: TIDB_INDEX_USAGE` INFORMATION_SCHEMA テーブルについて学習してください。 --- -# TIDB_INDEX_USAGE {#tidb-index-usage} +# TIDB_INDEX_USAGE {#tidb_index_usage} @@ -61,7 +61,7 @@ DESC TIDB_INDEX_USAGE; - `PERCENTAGE_ACCESS_100` : 行アクセス率が 100% になる回数。 - `LAST_ACCESS_TIME` : インデックスへの最新のアクセス時刻。 -## クラスターTIDBインデックス使用状況 {#cluster-tidb-index-usage} +## クラスターTIDBインデックス使用状況 {#cluster_tidb_index_usage} `TIDB_INDEX_USAGE`テーブルは、単一の TiDB ノード上のすべてのインデックスの使用統計情報のみを提供します。クラスタ内のすべての TiDB ノードのインデックス使用統計情報を取得するには、 `CLUSTER_TIDB_INDEX_USAGE`テーブルをクエリする必要があります。 diff --git a/information-schema/information-schema-tidb-trx.md b/information-schema/information-schema-tidb-trx.md index f924245610aab..53d508f0f84d9 100644 --- a/information-schema/information-schema-tidb-trx.md +++ b/information-schema/information-schema-tidb-trx.md @@ -3,7 +3,7 @@ title: TIDB_TRX summary: TIDB_TRX` INFORMATION_SCHEMA テーブルについて学習します。 --- -# TIDB_TRX {#tidb-trx} +# TIDB_TRX {#tidb_trx} `TIDB_TRX`テーブルは、TiDB ノードで現在実行されているトランザクションに関する情報を提供します。 @@ -123,7 +123,7 @@ all_sql_digests: ["e6f07d43b5c21db0fbb9a31feac2dc599787763393dd5acbfad80e247eb02 このクエリは、テーブル`TIDB_TRX`の列`ALL_SQL_DIGESTS`に対して関数[`TIDB_DECODE_SQL_DIGESTS`](/functions-and-operators/tidb-functions.md#tidb_decode_sql_digests)呼び出し、システム内部クエリを通じてSQLダイジェスト配列を正規化されたSQL文の配列に変換します。これにより、トランザクションによって実行された過去のSQL文の情報を視覚的に取得できます。ただし、上記のクエリはテーブル`TIDB_TRX`全体をスキャンし、各行に対して関数`TIDB_DECODE_SQL_DIGESTS`呼び出すことに注意してください。関数`TIDB_DECODE_SQL_DIGESTS`呼び出しには大きなオーバーヘッドがかかります。したがって、クラスター内に多数の同時トランザクションが存在する場合は、このタイプのクエリの使用を避けてください。 -## クラスター_TIDB_TRX {#cluster-tidb-trx} +## クラスター_TIDB_TRX {#cluster_tidb_trx} `TIDB_TRX`テーブルは、単一の TiDB ノードで実行されているトランザクションに関する情報のみを提供します。クラスター全体のすべての TiDB ノードで実行されているトランザクションの情報を表示するには、 `CLUSTER_TIDB_TRX`テーブルをクエリする必要があります。5 テーブルのクエリ結果と比較すると、 `TIDB_TRX`テーブルのクエリ結果には`INSTANCE`フィールドが追加されています`INSTANCE`フィールド`CLUSTER_TIDB_TRX`は、クラスター内の各ノードの IP アドレスとポート番号が表示され、トランザクションが配置されている TiDB ノードを識別するために使用されます。 diff --git a/latency-breakdown.md b/latency-breakdown.md index ee161256538f2..fee2e31e7fbe3 100644 --- a/latency-breakdown.md +++ b/latency-breakdown.md @@ -199,7 +199,7 @@ read value duration(from disk) = スナップショットを取得した後、TiKVは同じスナップショットから複数の値を読み取ります。読み取り時間は[PointGet](#point-get)と同じです。TiKVがディスクからデータを読み込む場合の平均時間は、 `tikv_storage_rocksdb_perf`と`req="batch_get"`で計算できます。 -### テーブルスキャンとインデックススキャン {#table-scan-x26-index-scan} +### テーブルスキャンとインデックススキャン {#table-scan--index-scan} 以下は、テーブルスキャンとインデックススキャン操作の時間コスト図です。 diff --git a/max-min-eliminate.md b/max-min-eliminate.md index 641ac06cf094f..0199be4800ccf 100644 --- a/max-min-eliminate.md +++ b/max-min-eliminate.md @@ -3,7 +3,7 @@ title: Eliminate Max/Min summary: Max/Min関数を排除するための規則を紹介します。 --- -# 最大/最小を排除 {#eliminate-max-min} +# 最大/最小を排除 {#eliminate-maxmin} SQL文に`max` `min`関数が含まれている場合、クエリオプティマイザは`max`最適化ルールを適用して、 `max` / `min`集計関数をTopN演算子に変換しようとします。これにより、TiDBはインデックスを通じてクエリ`min`より効率的に実行できます。 @@ -12,7 +12,7 @@ SQL文に`max` `min`関数が含まれている場合、クエリオプティマ - [`max` / `min`関数が1つだけあるステートメント](#one-maxmin-function) - [複数の`max` / `min`関数を含むステートメント](#multiple-maxmin-functions) -## 1つのmax / min関数 {#one-code-max-code-code-min-code-function} +## 1つのmax / min関数 {#one-maxmin-function} SQL ステートメントが次の条件を満たす場合、このルールが適用されます。 @@ -49,7 +49,7 @@ mysql> explain select max(a) from t; 5 rows in set (0.00 sec) ``` -## 複数のmax / min関数 {#multiple-code-max-code-code-min-code-functions} +## 複数のmax / min関数 {#multiple-maxmin-functions} SQL ステートメントが次の条件を満たす場合、このルールが適用されます。 diff --git a/non-transactional-dml.md b/non-transactional-dml.md index e5ea8e7cf017f..73dd8f366c735 100644 --- a/non-transactional-dml.md +++ b/non-transactional-dml.md @@ -319,7 +319,7 @@ batch-dml は、DML ステートメントの実行中にトランザクション ## よくある問題 {#common-issues} -### 複数のテーブル結合ステートメントを実行するとUnknown column xxx in 'where clause'エラーが発生します。 {#executing-a-multiple-table-joins-statement-results-in-the-code-unknown-column-xxx-in-where-clause-code-error} +### 複数のテーブル結合ステートメントを実行するとUnknown column xxx in 'where clause'エラーが発生します。 {#executing-a-multiple-table-joins-statement-results-in-the-unknown-column-xxx-in-where-clause-error} このエラーは、クエリ内で連結された`WHERE`句が、 [破片の列](#parameter-description)が定義されているテーブル以外のテーブルに関係する場合に発生します。例えば、次のSQL文では、シャード列は`t2.id`で、テーブル`t2`に定義されていますが、 `WHERE`句はテーブル`t2`と`t3`に関係しています。 @@ -355,7 +355,7 @@ SELECT t2.id, t2.v, t3.id FROM t2 JOIN t3 ON t2.id = t3.id | 0 | all succeeded | +----------------+---------------+ -### 非トランザクションDML文でテーブルエイリアスを使用すると、 Unknown column '<alias>.<column>' in 'where clause'エラーが発生します。 {#the-code-unknown-column-x3c-alias-x3c-column-in-where-clause-code-error-occurs-when-using-table-aliases-in-non-transactional-dml-statements} +### 非トランザクションDML文でテーブルエイリアスを使用すると、 Unknown column '<alias>.<column>' in 'where clause'エラーが発生します。 {#the-unknown-column-aliascolumn-in-where-clause-error-occurs-when-using-table-aliases-in-non-transactional-dml-statements} 非トランザクションDML文を実行すると、TiDBは内部的にバッチを分割するためのクエリを構築し、実際の分割実行文を生成します。これらの2種類の文は、それぞれ[`DRY RUN QUERY`](/non-transactional-dml.md#query-the-batch-dividing-statement)と[`DRY RUN`](/non-transactional-dml.md#query-the-statements-corresponding-to-the-first-and-the-last-batches)で確認できます。 @@ -384,7 +384,7 @@ WHERE t.c1 IS NULL; さらに、他の同時書き込みが発生すると、各バッチで処理される行数は指定されたバッチ サイズと異なる場合があります。 -### 実行中に、 Failed to restore the delete statement, probably because of unsupported type of the shard columnエラーが発生します。 {#the-code-failed-to-restore-the-delete-statement-probably-because-of-unsupported-type-of-the-shard-column-code-error-occurs-during-execution} +### 実行中に、 Failed to restore the delete statement, probably because of unsupported type of the shard columnエラーが発生します。 {#the-failed-to-restore-the-delete-statement-probably-because-of-unsupported-type-of-the-shard-column-error-occurs-during-execution} シャード列は`ENUM` 、 `BIT` 、 `SET` 、 `JSON`型をサポートしていません。新しいシャード列を指定してください。整数型または文字列型の列を使用することをお勧めします。 @@ -400,7 +400,7 @@ WHERE t.c1 IS NULL; -### 非トランザクションDELETE 、通常のDELETEと同等ではない「例外的な」動作をします。 {#non-transactional-code-delete-code-has-exceptional-behavior-that-is-not-equivalent-to-ordinary-code-delete-code} +### 非トランザクションDELETE 、通常のDELETEと同等ではない「例外的な」動作をします。 {#non-transactional-delete-has-exceptional-behavior-that-is-not-equivalent-to-ordinary-delete} 非トランザクション DML ステートメントは、この DML ステートメントの元の形式と同等ではありません。次のような理由が考えられます。 diff --git a/optimizer-hints.md b/optimizer-hints.md index 26873e4e55325..769b59a607c4a 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -58,7 +58,7 @@ SELECT /*+ HASH_JOIN(@sel_1 t1@sel_1, t3) */ * FROM (SELECT t1.a, t1.b FROM t t1 > > ヒントは、ヒントが有効になるクエリブロック内またはその前に置く必要があります。ヒントをクエリブロックの後に置くと、ヒントは有効になりません。 -### QB_NAME {#qb-name} +### QB_NAME {#qb_name} クエリ文が複数のネストされたクエリを含む複雑な文である場合、特定のクエリブロックのIDと名前が誤って識別される可能性があります。この点については、ヒント`QB_NAME`が役立ちます。 @@ -74,7 +74,7 @@ SELECT /*+ QB_NAME(QB1) */ * FROM (SELECT * FROM t) t1, (SELECT * FROM t) t2; > > 上記の例では、ヒントが`QB_NAME`から`sel_2`指定し、元の 2 番目のクエリ ブロック`SELECT`に新しい`QB_NAME`指定していない場合、2 番目のクエリ ブロック`SELECT`に対して`sel_2`無効な名前になります。 -### MERGE_JOIN(t1_name [, tl_name ...]) {#merge-join-t1-name-tl-name} +### MERGE_JOIN(t1_name [, tl_name ...]) {#merge_joint1_name--tl_name-} ヒント`MERGE_JOIN(t1_name [, tl_name ...])`は、指定されたテーブルに対してソートマージ結合アルゴリズムを使用するようオプティマイザに指示します。一般的に、このアルゴリズムはメモリ消費量が少なくなりますが、処理時間は長くなります。データ量が非常に多い場合やシステムメモリが不足している場合は、このヒントを使用することをお勧めします。例： @@ -86,7 +86,7 @@ select /*+ MERGE_JOIN(t1, t2) */ * from t1, t2 where t1.id = t2.id; > > `TIDB_SMJ`は TiDB 3.0.x 以前のバージョンにおける`MERGE_JOIN`の別名です。これらのバージョンを使用している場合は、ヒントに`TIDB_SMJ(t1_name [, tl_name ...])`構文を適用する必要があります。TiDB のそれ以降のバージョンでは、ヒントの名前として`TIDB_SMJ`と`MERGE_JOIN`はどちらも有効ですが、 `MERGE_JOIN`使用を推奨します。 -### NO_MERGE_JOIN(t1_name [, tl_name ...]) {#no-merge-join-t1-name-tl-name} +### NO_MERGE_JOIN(t1_name [, tl_name ...]) {#no_merge_joint1_name--tl_name-} ヒント`NO_MERGE_JOIN(t1_name [, tl_name ...])`は、指定されたテーブルに対してソートマージ結合アルゴリズムを使用しないようオプティマイザに指示します。例: @@ -94,7 +94,7 @@ select /*+ MERGE_JOIN(t1, t2) */ * from t1, t2 where t1.id = t2.id; SELECT /*+ NO_MERGE_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; ``` -### INL_JOIN(t1_name [, tl_name ...]) {#inl-join-t1-name-tl-name} +### INL_JOIN(t1_name [, tl_name ...]) {#inl_joint1_name--tl_name-} > **Note:** > @@ -114,7 +114,7 @@ SELECT /*+ INL_JOIN(t1, t2) */ * FROM t1, t2, t3 WHERE t1.id = t2.id AND t2.id = > > `TIDB_INLJ`は TiDB 3.0.x 以前のバージョンにおける`INL_JOIN`の別名です。これらのバージョンを使用している場合は、ヒントに`TIDB_INLJ(t1_name [, tl_name ...])`構文を適用する必要があります。TiDB のそれ以降のバージョンでは、ヒントの名前として`TIDB_INLJ`と`INL_JOIN`はどちらも有効ですが、 `INL_JOIN`使用を推奨します。 -### NO_INDEX_JOIN(t1_name [, tl_name ...]) {#no-index-join-t1-name-tl-name} +### NO_INDEX_JOIN(t1_name [, tl_name ...]) {#no_index_joint1_name--tl_name-} ヒント`NO_INDEX_JOIN(t1_name [, tl_name ...])`は、指定されたテーブルに対してインデックスネストループ結合アルゴリズムを使用しないようオプティマイザに指示します。例: @@ -122,23 +122,23 @@ SELECT /*+ INL_JOIN(t1, t2) */ * FROM t1, t2, t3 WHERE t1.id = t2.id AND t2.id = SELECT /*+ NO_INDEX_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; ``` -### INL_HASH_JOIN {#inl-hash-join} +### INL_HASH_JOIN {#inl_hash_join} ヒント`INL_HASH_JOIN(t1_name [, tl_name])`は、インデックス・ネストループ・ハッシュ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムを使用するための条件は、インデックス・ネストループ結合アルゴリズムを使用するための条件と同じです。2つのアルゴリズムの違いは、 `INL_JOIN`結合された内部テーブルにハッシュテーブルを作成するのに対し、 `INL_HASH_JOIN`結合された外部テーブルにハッシュテーブルを作成する点です。 `INL_HASH_JOIN`はメモリ使用量に制限がありますが、ヒント`INL_JOIN`は内部テーブルで一致する行数に応じてメモリ使用量が異なります。 -### NO_INDEX_HASH_JOIN(t1_name [, tl_name ...]) {#no-index-hash-join-t1-name-tl-name} +### NO_INDEX_HASH_JOIN(t1_name [, tl_name ...]) {#no_index_hash_joint1_name--tl_name-} ヒント`NO_INDEX_HASH_JOIN(t1_name [, tl_name ...])`は、指定されたテーブルに対してインデックス ネスト ループ ハッシュ結合アルゴリズムを使用しないようオプティマイザに指示します。 -### INL_MERGE_JOIN {#inl-merge-join} +### INL_MERGE_JOIN {#inl_merge_join} ヒント`INL_MERGE_JOIN(t1_name [, tl_name])`は、インデックス・ネストループ・マージ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムを使用する条件は、インデックス・ネストループ結合アルゴリズムを使用する条件と同じです。 -### NO_INDEX_MERGE_JOIN(t1_name [, tl_name ...]) {#no-index-merge-join-t1-name-tl-name} +### NO_INDEX_MERGE_JOIN(t1_name [, tl_name ...]) {#no_index_merge_joint1_name--tl_name-} ヒント`NO_INDEX_MERGE_JOIN(t1_name [, tl_name ...])`は、指定されたテーブルに対してインデックス ネスト ループ マージ結合アルゴリズムを使用しないようオプティマイザに指示します。 -### HASH_JOIN(t1_name [, tl_name ...]) {#hash-join-t1-name-tl-name} +### HASH_JOIN(t1_name [, tl_name ...]) {#hash_joint1_name--tl_name-} `HASH_JOIN(t1_name [, tl_name ...])`ヒントは、指定されたテーブルに対してハッシュ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムにより、クエリを複数のスレッドで同時に実行できるため、処理速度は向上しますが、メモリ消費量は増加します。例: @@ -150,7 +150,7 @@ select /*+ HASH_JOIN(t1, t2) */ * from t1, t2 where t1.id = t2.id; > > `TIDB_HJ`は TiDB 3.0.x 以前のバージョンにおける`HASH_JOIN`の別名です。これらのバージョンを使用している場合は、ヒントに`TIDB_HJ(t1_name [, tl_name ...])`構文を適用する必要があります。TiDB のそれ以降のバージョンでは、ヒントの名前として`TIDB_HJ`と`HASH_JOIN`はどちらも有効ですが、 `HASH_JOIN`使用を推奨します。 -### NO_HASH_JOIN(t1_name [, tl_name ...]) {#no-hash-join-t1-name-tl-name} +### NO_HASH_JOIN(t1_name [, tl_name ...]) {#no_hash_joint1_name--tl_name-} `NO_HASH_JOIN(t1_name [, tl_name ...])`ヒントは、指定されたテーブルに対してハッシュ結合アルゴリズムを使用しないようオプティマイザに指示します。例: @@ -158,7 +158,7 @@ select /*+ HASH_JOIN(t1, t2) */ * from t1, t2 where t1.id = t2.id; SELECT /*+ NO_HASH_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; ``` -### HASH_JOIN_BUILD(t1_name [, tl_name ...]) {#hash-join-build-t1-name-tl-name} +### HASH_JOIN_BUILD(t1_name [, tl_name ...]) {#hash_join_buildt1_name--tl_name-} `HASH_JOIN_BUILD(t1_name [, tl_name ...])`ヒントは、指定されたテーブルをビルド側として、ハッシュ結合アルゴリズムを使用するようオプティマイザに指示します。これにより、特定のテーブルを使用してハッシュテーブルを構築できます。例: @@ -166,7 +166,7 @@ SELECT /*+ NO_HASH_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; SELECT /*+ HASH_JOIN_BUILD(t1) */ * FROM t1, t2 WHERE t1.id = t2.id; ``` -### HASH_JOIN_PROBE(t1_name [, tl_name ...]) {#hash-join-probe-t1-name-tl-name} +### HASH_JOIN_PROBE(t1_name [, tl_name ...]) {#hash_join_probet1_name--tl_name-} `HASH_JOIN_PROBE(t1_name [, tl_name ...])`ヒントは、指定されたテーブルをプローブ側としてハッシュ結合アルゴリズムを使用するようオプティマイザに指示します。これにより、特定のテーブルをプローブ側としてハッシュ結合アルゴリズムを実行できます。例： @@ -174,7 +174,7 @@ SELECT /*+ HASH_JOIN_BUILD(t1) */ * FROM t1, t2 WHERE t1.id = t2.id; SELECT /*+ HASH_JOIN_PROBE(t2) */ * FROM t1, t2 WHERE t1.id = t2.id; ``` -### セミジョインリライト() {#semi-join-rewrite} +### セミジョインリライト() {#semi_join_rewrite} `SEMI_JOIN_REWRITE()`ヒントは、オプティマイザに準結合クエリを通常の結合クエリに書き換えるよう指示します。現在、このヒントは`EXISTS`サブクエリに対してのみ機能します。 @@ -222,7 +222,7 @@ EXPLAIN SELECT * FROM t WHERE EXISTS (SELECT /*+ SEMI_JOIN_REWRITE() */ 1 FROM t 前述の例から、ヒント`SEMI_JOIN_REWRITE()`を使用すると、TiDB は駆動テーブル`t1`に基づいて IndexJoin の実行方法を選択できることがわかります。 -### SHUFFLE_JOIN(t1_name [, tl_name ...]) {#shuffle-join-t1-name-tl-name} +### SHUFFLE_JOIN(t1_name [, tl_name ...]) {#shuffle_joint1_name--tl_name-} ヒント`SHUFFLE_JOIN(t1_name [, tl_name ...])`は、指定されたテーブルに対してシャッフル結合アルゴリズムを使用するようオプティマイザに指示します。このヒントはMPPモードでのみ有効です。例： @@ -235,7 +235,7 @@ SELECT /*+ SHUFFLE_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; > - このヒントを使用する前に、現在のTiDBクラスタがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 > - このヒントは、 [`HASH_JOIN_BUILD`ヒント](#hash_join_buildt1_name--tl_name-)および[`HASH_JOIN_PROBE`ヒント](#hash_join_probet1_name--tl_name-)と組み合わせて使用して、シャッフル結合アルゴリズムのビルド側とプローブ側を制御できます。 -### BROADCAST_JOIN(t1_name [, tl_name ...]) {#broadcast-join-t1-name-tl-name} +### BROADCAST_JOIN(t1_name [, tl_name ...]) {#broadcast_joint1_name--tl_name-} `BROADCAST_JOIN(t1_name [, tl_name ...])`ヒントは、指定されたテーブルに対してブロードキャスト結合アルゴリズムを使用するようオプティマイザに指示します。このヒントはMPPモードでのみ有効です。例： @@ -248,7 +248,7 @@ SELECT /*+ BROADCAST_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; > - このヒントを使用する前に、現在のTiDBクラスタがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 > - このヒントは、 [`HASH_JOIN_BUILD`ヒント](#hash_join_buildt1_name--tl_name-)および[`HASH_JOIN_PROBE`ヒント](#hash_join_probet1_name--tl_name-)と組み合わせて使用して、ブロードキャスト結合アルゴリズムのビルド側とプローブ側を制御できます。 -### NO_DECORRELATE() {#no-decorrelate} +### NO_DECORRELATE() {#no_decorrelate} `NO_DECORRELATE()`ヒントは、指定されたクエリブロック内の相関サブクエリに対して、相関解除を実行しないようにオプティマイザに指示します。このヒントは`EXISTS` 、 `IN` 、 `ANY` 、 `ALL` 、 `SOME`サブクエリ、および相関列を含むスカラーサブクエリ（つまり、相関サブクエリ）に適用されます。 @@ -308,7 +308,7 @@ explain select * from t1 where t1.a < (select /*+ NO_DECORRELATE() */ sum(t2.a) 上記の実行プランから、オプティマイザが相関除去を実行していないことがわかります。実行プランには依然としてApply演算子が含まれています。相関列を含むフィルタ条件（ `t2.b = t1.b` ）は、テーブル`t2`へのアクセス時にもフィルタ条件として使用されます。 -### ハッシュ_AGG() {#hash-agg} +### ハッシュ_AGG() {#hash_agg} `HASH_AGG()`ヒントは、指定されたクエリブロック内のすべての集計関数でハッシュ集計アルゴリズムを使用するようにオプティマイザに指示します。このアルゴリズムにより、クエリを複数のスレッドで同時に実行できるため、処理速度は向上しますが、メモリ消費量は増加します。例： @@ -316,7 +316,7 @@ explain select * from t1 where t1.a < (select /*+ NO_DECORRELATE() */ sum(t2.a) select /*+ HASH_AGG() */ count(*) from t1, t2 where t1.a > 10 group by t1.id; ``` -### ストリーム_AGG() {#stream-agg} +### ストリーム_AGG() {#stream_agg} ヒント`STREAM_AGG()`は、指定されたクエリブロック内のすべての集計関数でストリーム集約アルゴリズムを使用するようオプティマイザに指示します。一般的に、このアルゴリズムはメモリ消費量が少なくなりますが、処理時間は長くなります。データ量が非常に多い場合やシステムメモリが不足している場合は、このヒントを使用することをお勧めします。例： @@ -324,7 +324,7 @@ select /*+ HASH_AGG() */ count(*) from t1, t2 where t1.a > 10 group by t1.id; select /*+ STREAM_AGG() */ count(*) from t1, t2 where t1.a > 10 group by t1.id; ``` -### MPP_1PHASE_AGG() {#mpp-1phase-agg} +### MPP_1PHASE_AGG() {#mpp_1phase_agg} `MPP_1PHASE_AGG()`指定されたクエリブロック内のすべての集計関数に対して、1フェーズ集計アルゴリズムを使用するようオプティマイザに指示します。このヒントはMPPモードでのみ有効です。例： @@ -336,7 +336,7 @@ SELECT /*+ MPP_1PHASE_AGG() */ COUNT(*) FROM t1, t2 WHERE t1.a > 10 GROUP BY t1. > > このヒントを使用する前に、現在のTiDBクラスタがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 -### MPP_2PHASE_AGG() {#mpp-2phase-agg} +### MPP_2PHASE_AGG() {#mpp_2phase_agg} `MPP_2PHASE_AGG()`指定されたクエリブロック内のすべての集計関数に対して2フェーズ集計アルゴリズムを使用するようオプティマイザに指示します。このヒントはMPPモードでのみ有効です。例： @@ -348,7 +348,7 @@ SELECT /*+ MPP_2PHASE_AGG() */ COUNT(*) FROM t1, t2 WHERE t1.a > 10 GROUP BY t1. > > このヒントを使用する前に、現在のTiDBクラスタがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 -### USE_INDEX(t1_name, idx1_name [, idx2_name ...]) {#use-index-t1-name-idx1-name-idx2-name} +### USE_INDEX(t1_name, idx1_name [, idx2_name ...]) {#use_indext1_name-idx1_name--idx2_name-} `USE_INDEX(t1_name, idx1_name [, idx2_name ...])`のヒントは、指定された`t1_name`番目のテーブルに対して、指定されたインデックスのみを使用するようにオプティマイザに指示します。例えば、次のヒントを適用すると、 `select * from t t1 use index(idx1, idx2);`番目の文を実行するのと同じ効果が得られます。 @@ -360,7 +360,7 @@ SELECT /*+ USE_INDEX(t1, idx1, idx2) */ * FROM t1; > > このヒントでテーブル名のみを指定し、インデックス名を指定しない場合、実行ではインデックスは考慮されず、テーブル全体がスキャンされます。 -### FORCE_INDEX(t1_name, idx1_name [, idx2_name ...]) {#force-index-t1-name-idx1-name-idx2-name} +### FORCE_INDEX(t1_name, idx1_name [, idx2_name ...]) {#force_indext1_name-idx1_name--idx2_name-} ヒント`FORCE_INDEX(t1_name, idx1_name [, idx2_name ...])`は、オプティマイザに指定されたインデックスのみを使用するように指示します。 @@ -375,7 +375,7 @@ SELECT * FROM t use index(idx1); SELECT * FROM t force index(idx1); ``` -### IGNORE_INDEX(t1_name, idx1_name [, idx2_name ...]) {#ignore-index-t1-name-idx1-name-idx2-name} +### IGNORE_INDEX(t1_name, idx1_name [, idx2_name ...]) {#ignore_indext1_name-idx1_name--idx2_name-} `IGNORE_INDEX(t1_name, idx1_name [, idx2_name ...])`ヒントは、指定された`t1_name`番目のテーブルの指定されたインデックスを無視するようにオプティマイザに指示します。例えば、次のヒントを適用すると、 `select * from t t1 ignore index(idx1, idx2);`番目の文を実行するのと同じ効果が得られます。 @@ -383,7 +383,7 @@ SELECT * FROM t force index(idx1); select /*+ IGNORE_INDEX(t1, idx1, idx2) */ * from t t1; ``` -### ORDER_INDEX(t1_name, idx1_name [, idx2_name ...]) {#order-index-t1-name-idx1-name-idx2-name} +### ORDER_INDEX(t1_name, idx1_name [, idx2_name ...]) {#order_indext1_name-idx1_name--idx2_name-} ヒント`ORDER_INDEX(t1_name, idx1_name [, idx2_name ...])`は、指定されたテーブルに対して指定されたインデックスのみを使用し、指定されたインデックスを順番に読み取るようにオプティマイザに指示します。 @@ -416,7 +416,7 @@ EXPLAIN SELECT /*+ ORDER_INDEX(t, a) */ a FROM t ORDER BY a LIMIT 10; > - クエリ自体がインデックスを順番に読み取る必要がない場合（つまり、ヒントがない場合、オプティマイザはいかなる状況でもインデックスを順番に読み取るプランを生成しません）、ヒント`ORDER_INDEX`を使用するとエラー`Can't find a proper physical plan for this query`が発生します。この場合、対応するヒント`ORDER_INDEX`を削除する必要があります。 > - パーティションテーブルのインデックスは順番に読み取ることができないため、パーティションテーブルとその関連インデックスでは`ORDER_INDEX`ヒントを使用しないでください。 -### NO_ORDER_INDEX(t1_name, idx1_name [, idx2_name ...]) {#no-order-index-t1-name-idx1-name-idx2-name} +### NO_ORDER_INDEX(t1_name, idx1_name [, idx2_name ...]) {#no_order_indext1_name-idx1_name--idx2_name-} `NO_ORDER_INDEX(t1_name, idx1_name [, idx2_name ...])`ヒントは、指定されたテーブルに対して指定されたインデックスのみを使用し、指定されたインデックスを順番に読み取らないようにオプティマイザに指示します。このヒントは通常、以下のシナリオに適用されます。 @@ -440,7 +440,7 @@ EXPLAIN SELECT /*+ NO_ORDER_INDEX(t, a) */ a FROM t ORDER BY a LIMIT 10; ヒント`ORDER_INDEX`の例と同様に、オプティマイザはこのクエリに対して`Limit + IndexScan(keep order: true)`と`TopN + IndexScan(keep order: false)` 2種類のプランを生成します。ヒント`NO_ORDER_INDEX`が使用される場合、オプティマイザは後者のプランを選択してインデックスを順不同で読み取ります。 -### INDEX_LOOKUP_PUSHDOWN(t1_name, idx1_name [, idx2_name ...])バージョン8.5.5の新機能 {#index-lookup-pushdown-t1-name-idx1-name-idx2-name-new-in-v855} +### INDEX_LOOKUP_PUSHDOWN(t1_name, idx1_name [, idx2_name ...])バージョン8.5.5の新機能 {#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855} ヒント`INDEX_LOOKUP_PUSHDOWN(t1_name, idx1_name [, idx2_name ...])`は、指定されたインデックスのみを使用して指定されたテーブルにアクセスし、演算子`IndexLookUp` TiKV にプッシュダウンして実行するようにオプティマイザに指示します。 @@ -477,7 +477,7 @@ EXPLAIN SELECT /*+ INDEX_LOOKUP_PUSHDOWN(t1, a) */ a, b FROM t1; - プッシュダウンされた`LocalIndexLookUp`演算子は、ページング モードでのコプロセッサー要求の送信をサポートしていません。 - プッシュダウンされた`LocalIndexLookUp`演算子は[コプロセッサーキャッシュ](/coprocessor-cache.md)サポートしません。 -### NO_INDEX_LOOKUP_PUSHDOWN(t1_name)バージョン8.5.5の新機能 {#no-index-lookup-pushdown-t1-name-new-in-v855} +### NO_INDEX_LOOKUP_PUSHDOWN(t1_name)バージョン8.5.5の新機能 {#no_index_lookup_pushdownt1_name-new-in-v855} `NO_INDEX_LOOKUP_PUSHDOWN(t1_name)`ヒントは、指定されたテーブルの`IndexLookUp`プッシュダウンを明示的に無効にします。このヒントは通常、 [`tidb_index_lookup_pushdown_policy`](/system-variables.md#tidb_index_lookup_pushdown_policy-new-in-v855)システム変数と組み合わせて使用されます。この変数の値が`force`または`affinity-force`の場合、このヒントを使用して特定のテーブルの`IndexLookUp`プッシュダウンを防止できます。 @@ -494,7 +494,7 @@ SELECT /*+ NO_INDEX_LOOKUP_PUSHDOWN(t) */ * FROM t WHERE a > 1; > > `NO_INDEX_LOOKUP_PUSHDOWN`は[`INDEX_LOOKUP_PUSHDOWN`](#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855)よりも優先されます。同じクエリで両方のヒントを指定した場合、 `NO_INDEX_LOOKUP_PUSHDOWN`有効になります。 -### AGG_TO_COP() {#agg-to-cop} +### AGG_TO_COP() {#agg_to_cop} ヒント`AGG_TO_COP()`は、指定されたクエリブロック内の集計演算をコプロセッサにプッシュダウンするようオプティマイザに指示します。オプティマイザがプッシュダウンに適した集計関数をプッシュダウンしない場合は、このヒントを使用することをお勧めします。例： @@ -502,7 +502,7 @@ SELECT /*+ NO_INDEX_LOOKUP_PUSHDOWN(t) */ * FROM t WHERE a > 1; select /*+ AGG_TO_COP() */ sum(t1.a) from t t1; ``` -### LIMIT_TO_COP() {#limit-to-cop} +### LIMIT_TO_COP() {#limit_to_cop} `LIMIT_TO_COP()`ヒントは、指定されたクエリブロック内の`Limit`と`TopN`演算子をコプロセッサにプッシュダウンするようオプティマイザに指示します。オプティマイザがそのような操作を実行しない場合は、このヒントを使用することをお勧めします。例: @@ -510,7 +510,7 @@ select /*+ AGG_TO_COP() */ sum(t1.a) from t t1; SELECT /*+ LIMIT_TO_COP() */ * FROM t WHERE a = 1 AND b > 10 ORDER BY c LIMIT 1; ``` -### READ_FROM_STORAGE(TIFLASH[t1_name [, tl_name ...]], TIKV[t2_name [, tl_name ...]]) {#read-from-storage-tiflash-t1-name-tl-name-tikv-t2-name-tl-name} +### READ_FROM_STORAGE(TIFLASH[t1_name [, tl_name ...]], TIKV[t2_name [, tl_name ...]]) {#read_from_storagetiflasht1_name--tl_name--tikvt2_name--tl_name-} ヒント`READ_FROM_STORAGE(TIFLASH[t1_name [, tl_name ...]], TIKV[t2_name [, tl_name ...]])`は、オプティマイザに特定のストレージエンジンから特定のテーブルを読み取るように指示します。現在、このヒントは`TIKV`と`TIFLASH`の2つのストレージエンジンパラメータをサポートしています。テーブルにエイリアスがある場合は、そのエイリアスを`READ_FROM_STORAGE()`のパラメータとして使用します。テーブルにエイリアスがない場合は、テーブルの元の名前をパラメータとして使用します。例： @@ -518,7 +518,7 @@ SELECT /*+ LIMIT_TO_COP() */ * FROM t WHERE a = 1 AND b > 10 ORDER BY c LIMIT 1; select /*+ READ_FROM_STORAGE(TIFLASH[t1], TIKV[t2]) */ t1.a from t t1, t t2 where t1.a = t2.a; ``` -### USE_INDEX_MERGE(t1_name, idx1_name [, idx2_name ...]) {#use-index-merge-t1-name-idx1-name-idx2-name} +### USE_INDEX_MERGE(t1_name, idx1_name [, idx2_name ...]) {#use_index_merget1_name-idx1_name--idx2_name-} ヒント`USE_INDEX_MERGE(t1_name, idx1_name [, idx2_name ...])`は、オプティマイザにインデックスマージ方式で特定のテーブルにアクセスするよう指示します。インデックスマージには、交差型と結合型の2種類があります。詳細は[インデックスマージを使用したステートメントの説明](/explain-index-merge.md)参照してください。 @@ -536,7 +536,7 @@ SELECT /*+ USE_INDEX_MERGE(t1, idx_a, idx_b, idx_c) */ * FROM t1 WHERE t1.a > 10 > > `USE_INDEX_MERGE`のパラメータは列名ではなくインデックス名を参照します。主キーのインデックス名は`primary`です。 -### LEADING(t1_name [, tl_name ...]) {#leading-t1-name-tl-name} +### LEADING(t1_name [, tl_name ...]) {#leadingt1_name--tl_name-} `LEADING(t1_name [, tl_name ...])`ヒントは、実行プランを生成する際に、ヒントで指定されたテーブル名の順序に従って複数テーブルの結合順序を決定するようオプティマイザに指示します。例: @@ -602,7 +602,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * グローバルヒントは[ビュー](/views.md)で機能します。グローバルヒントとして指定すると、クエリで定義されたヒントがビュー内で有効になります。グローバルヒントを指定するには、まず`QB_NAME`ヒントを使用してクエリブロック名を定義し、次に`ViewName@QueryBlockName`の形式で対象のヒントを追加します。 -### ステップ1: QB_NAMEヒントを使用してビューのクエリブロック名を定義する {#step-1-define-the-query-block-name-of-the-view-using-the-code-qb-name-code-hint} +### ステップ1: QB_NAMEヒントを使用してビューのクエリブロック名を定義する {#step-1-define-the-query-block-name-of-the-view-using-the-qb_name-hint} [`QB_NAME`ヒント](#qb_name)は、ビューの各クエリブロックに新しい名前を定義するために使用します。ビューの`QB_NAME`のヒントの定義は[クエリブロック](#qb_name)と同じですが、構文が`QB_NAME(QB)`から`QB_NAME(QB, ViewName@QueryBlockName [.ViewName@QueryBlockName .ViewName@QueryBlockName ...])`に拡張されています。 @@ -705,7 +705,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * > > このカテゴリのヒントにはオプションの隠し変数`@QB_NAME`ありますが、変数を指定した場合でもヒントはクエリ全体に適用されます。 -### NO_INDEX_MERGE() {#no-index-merge} +### NO_INDEX_MERGE() {#no_index_merge} ヒント`NO_INDEX_MERGE()`は、オプティマイザのインデックス マージ機能を無効にします。 @@ -722,7 +722,7 @@ select /*+ NO_INDEX_MERGE() */ * from t where t.a > 0 or t.b > 0; > - `NO_INDEX_MERGE`は`USE_INDEX_MERGE`よりも優先度が高くなります。両方のヒントが使用されている場合、 `USE_INDEX_MERGE`効果がありません。 > - サブクエリの場合、 `NO_INDEX_MERGE`サブクエリの最も外側のレベルに配置された場合にのみ有効になります。 -### USE_TOJA(ブール値) {#use-toja-boolean-value} +### USE_TOJA(ブール値) {#use_tojaboolean_value} `boolean_value`パラメータは`TRUE`または`FALSE`です。7 ヒント`USE_TOJA(TRUE)` 、オプティマイザが`in`条件（サブクエリを含む）を結合および集計演算に変換できるようにします。一方、 `USE_TOJA(FALSE)`ヒントはこの機能を無効にします。 @@ -734,7 +734,7 @@ select /*+ USE_TOJA(TRUE) */ t1.a, t1.b from t1 where t1.a in (select t2.a from このヒントに加えて、 `tidb_opt_insubq_to_join_and_agg`システム変数を設定することで、この機能を有効にするかどうかも制御できます。 -### 最大実行時間(N) {#max-execution-time-n} +### 最大実行時間(N) {#max_execution_timen} `MAX_EXECUTION_TIME(N)`ヒントは、サーバーが文の実行を終了させるまでの制限時間`N` （ミリ秒単位のタイムアウト値）を設定します。次のヒントでは、 `MAX_EXECUTION_TIME(1000)`タイムアウトが 1000 ミリ秒（つまり 1 秒）であることを意味します。 @@ -744,7 +744,7 @@ select /*+ MAX_EXECUTION_TIME(1000) */ * from t1 inner join t2 where t1.id = t2. このヒントに加えて、 `global.max_execution_time`システム変数はステートメントの実行時間を制限することもできます。 -### メモリクォータ(N) {#memory-quota-n} +### メモリクォータ(N) {#memory_quotan} `MEMORY_QUOTA(N)`ヒントは、文が使用できるメモリ量に制限`N` （MB または GB 単位のしきい値）を設定します。文のメモリ使用量がこの制限を超えると、TiDB は文の制限超過動作に基づいてログメッセージを生成するか、文を終了します。 @@ -756,7 +756,7 @@ select /*+ MEMORY_QUOTA(1024 MB) */ * from t; このヒントに加えて、 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)システム変数を使用してステートメントのメモリ使用量を制限することもできます。 -### READ_CONSISTENT_REPLICA() {#read-consistent-replica} +### READ_CONSISTENT_REPLICA() {#read_consistent_replica} `READ_CONSISTENT_REPLICA()`ヒントは、TiKVフォロワーノードから一貫性のあるデータを読み取る機能を有効にします。例: @@ -766,7 +766,7 @@ select /*+ READ_CONSISTENT_REPLICA() */ * from t; このヒントに加えて、環境変数`tidb_replica_read` `'follower'`または`'leader'`に設定することで、この機能を有効にするかどうかも制御できます。 -### IGNORE_PLAN_CACHE() {#ignore-plan-cache} +### IGNORE_PLAN_CACHE() {#ignore_plan_cache} `IGNORE_PLAN_CACHE()`ヒントは、現在の`prepare`ステートメントを処理するときにプラン キャッシュを使用しないようにオプティマイザーに通知します。 @@ -778,7 +778,7 @@ select /*+ READ_CONSISTENT_REPLICA() */ * from t; prepare stmt from 'select /*+ IGNORE_PLAN_CACHE() */ * from t where t.id = ?'; ``` -### SET_VAR(変数名=変数値) {#set-var-var-name-var-value} +### SET_VAR(変数名=変数値) {#set_varvar_namevar_value} `SET_VAR(VAR_NAME=VAR_VALUE)`ヒントを使用すると、文の実行中にシステム変数の値を一時的に変更できます。文の実行後、現在のセッションにおけるシステム変数の値は自動的に元の値に戻ります。このヒントは、オプティマイザとエグゼキュータに関連する一部のシステム変数を変更するために使用できます。このヒントを使用して変更できるシステム変数のリストについては、 [システム変数](/system-variables.md)を参照してください。 @@ -811,7 +811,7 @@ SELECT @@MAX_EXECUTION_TIME; 1 row in set (0.00 sec) ``` -### ストレート結合() {#straight-join} +### ストレート結合() {#straight_join} `STRAIGHT_JOIN()`ヒントは、結合プランを生成するときに、 `FROM`番目の句のテーブル名の順序でテーブルを結合するようにオプティマイザーに通知します。 @@ -824,7 +824,7 @@ SELECT /*+ STRAIGHT_JOIN() */ * FROM t t1, t t2 WHERE t1.a = t2.a; > - `STRAIGHT_JOIN`は`LEADING`よりも優先度が高くなります。両方のヒントが使用されている場合、 `LEADING`効果がありません。 > - `STRAIGHT_JOIN`ヒントよりも一般的な`LEADING`ヒントを使用することをお勧めします。 -### NTH_PLAN(N) {#nth-plan-n} +### NTH_PLAN(N) {#nth_plann} ヒント`NTH_PLAN(N)`は、物理的な最適化中に見つかった`N`番目の物理プランを選択するようにオプティマイザーに通知します。5 `N`正の整数である必要があります。 @@ -842,7 +842,7 @@ SELECT /*+ NTH_PLAN(3) */ count(*) from t where a > 5; > > `NTH_PLAN(N)`は主にテスト用に使用されており、それ以降のバージョンとの互換性は保証されていません。このヒントは**慎重に**使用してください。 -### RESOURCE_GROUP(リソースグループ名) {#resource-group-resource-group-name} +### RESOURCE_GROUP(リソースグループ名) {#resource_groupresource_group_name} `RESOURCE_GROUP(resource_group_name)`は[リソース管理](/tidb-resource-control-ru-groups.md)代わりにリソースを分離するために使用されます。このヒントは、指定されたリソースグループを使用して現在のステートメントを一時的に実行します。指定されたリソースグループが存在しない場合、このヒントは無視されます。 @@ -932,9 +932,9 @@ SHOW WARNINGS; この場合、ヒントは`SELECT`キーワードの直後に配置する必要があります。詳細については、 [構文](#syntax)番目のセクションをご覧ください。 -### INL_JOINヒントは有効になりません {#code-inl-join-code-hint-does-not-take-effect} +### INL_JOINヒントは有効になりません {#inl_join-hint-does-not-take-effect} -#### INL_JOINヒントは、テーブル結合の列に組み込み関数が使用されている場合には効果がありません。 {#code-inl-join-code-hint-does-not-take-effect-when-built-in-functions-are-used-on-columns-for-joining-tables} +#### INL_JOINヒントは、テーブル結合の列に組み込み関数が使用されている場合には効果がありません。 {#inl_join-hint-does-not-take-effect-when-built-in-functions-are-used-on-columns-for-joining-tables} 場合によっては、テーブルを結合する列で組み込み関数を使用すると、オプティマイザーが`IndexJoin`プランを選択できず、 `INL_JOIN`ヒントも有効にならないことがあります。 @@ -997,7 +997,7 @@ EXPLAIN SELECT /*+ INL_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id=t2.id AND SUBST 7 rows in set (0.00 sec) ``` -#### INL_JOIN 、 INL_HASH_JOIN 、およびINL_MERGE_JOINヒントは、照合順序の非互換性のため有効になりません。 {#code-inl-join-code-code-inl-hash-join-code-and-code-inl-merge-join-code-hints-do-not-take-effect-due-to-collation-incompatibility} +#### INL_JOIN 、 INL_HASH_JOIN 、およびINL_MERGE_JOINヒントは、照合順序の非互換性のため有効になりません。 {#inl_join-inl_hash_join-and-inl_merge_join-hints-do-not-take-effect-due-to-collation-incompatibility} 2つのテーブル間で結合キーの照合順序に互換性がない場合、 `IndexJoin`演算子を使用してクエリを実行することはできません。この場合、 [`INL_JOIN`](#inl_joint1_name--tl_name-) 、 [`INL_HASH_JOIN`](#inl_hash_join) 、 [`INL_MERGE_JOIN`](#inl_merge_join)ヒントは効果がありません。例: @@ -1034,7 +1034,7 @@ SHOW WARNINGS; 1 row in set (0.00 sec) ``` -#### INL_JOINヒントは結合順序により有効になりません {#code-inl-join-code-hint-does-not-take-effect-due-to-join-order} +#### INL_JOINヒントは結合順序により有効になりません {#inl_join-hint-does-not-take-effect-due-to-join-order} [`INL_JOIN(t1, t2)`](#inl_joint1_name--tl_name-)または`TIDB_INLJ(t1, t2)`ヒントは、 `t1`と`t2` `IndexJoin`演算子を使用して直接結合するのではなく、 `IndexJoin`演算子内の内部テーブルとして動作させ、他のテーブルと結合するように指示します。例: @@ -1076,7 +1076,7 @@ EXPLAIN SELECT /*+ leading(t1, t3), inl_join(t3) */ * FROM t1, t2, t3 WHERE t1.i 9 rows in set (0.01 sec) ``` -### ヒントを使用するとCan't find a proper physical plan for this query 」というエラーが発生します。 {#using-hints-causes-the-code-can-t-find-a-proper-physical-plan-for-this-query-code-error} +### ヒントを使用するとCan't find a proper physical plan for this query 」というエラーが発生します。 {#using-hints-causes-the-cant-find-a-proper-physical-plan-for-this-query-error} `Can't find a proper physical plan for this query`エラーは次のシナリオで発生する可能性があります。 @@ -1100,7 +1100,7 @@ EXPLAIN SELECT /*+ NO_MERGE_JOIN(t1) */ * FROM t1, t2 WHERE t1.a=t2.a; ERROR 1815 (HY000): Internal : Can't find a proper physical plan for this query ``` -### SET_VARサブクエリに記述すると効果を発揮しません {#code-set-var-code-does-not-take-effect-when-written-in-subqueries} +### SET_VARサブクエリに記述すると効果を発揮しません {#set_var-does-not-take-effect-when-written-in-subqueries} `SET_VAR` 、現在のステートメントのシステム変数の値を変更するために使用されます。サブクエリには記述しないでください。サブクエリに記述した場合、サブクエリの特殊な処理により、 `SET_VAR`効力を持たない可能性があります。 diff --git a/pd-control.md b/pd-control.md index 66fcba40da399..75fe983a1d52f 100644 --- a/pd-control.md +++ b/pd-control.md @@ -64,43 +64,43 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - ## コマンドラインフラグ {#command-line-flags} -### `--cacert` {#cacert} +### `--cacert` {#--cacert} - 信頼されたCAの証明書ファイルへのパスをPEM形式で指定します。 - デフォルト： "" -### `--cert` {#cert} +### `--cert` {#--cert} - PEM形式のSSL証明書へのパスを指定します - デフォルト： "" -### `--detach` / `-d` {#detach-code-d-code} +### `--detach` / `-d` {#--detach---d} - 単一のコマンドラインモードを使用します（readline には入りません） - デフォルト: true -### `--help` / `-h` {#help-code-h-code} +### `--help` / `-h` {#--help---h} - ヘルプ情報を出力します - デフォルト: false -### `--interact` / `-i` {#interact-code-i-code} +### `--interact` / `-i` {#--interact---i} - 対話モードを使用する（readlineに入る） - デフォルト: false -### `--key` {#key} +### `--key` {#--key} - PEM形式のSSL証明書キーファイルへのパスを指定します。これは`--cert`で指定された証明書の秘密鍵です。 - デフォルト： "" -### `--pd` / `-u` {#pd-code-u-code} +### `--pd` / `-u` {#--pd---u} - PDアドレスを指定します - デフォルトアドレス: `http://127.0.0.1:2379` - 環境変数: `PD_ADDR` -### `--version` / `-V` {#version-code-v-code} +### `--version` / `-V` {#--version---v} - バージョン情報を出力して終了します - デフォルト: false @@ -121,7 +121,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - } ``` -### `config [show | set <option> <value> | placement-rules]` {#config-show-set-x3c-option-x3c-value-placement-rules} +### `config [show | set <option> <value> | placement-rules]` {#config-show--set-option-value--placement-rules} このコマンドを使用して、構成情報を表示または変更します。 @@ -349,7 +349,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - config set flow-round-by-digit 4 ``` -### `config [show | set service-middleware <option> [<key> <value> | <label> <qps|concurrency> <value>]]` {#config-show-set-service-middleware-x3c-option-x3c-key-x3c-value-x3c-label-x3c-qps-concurrency-x3c-value} +### `config [show | set service-middleware <option> [<key> <value> | <label> <qps|concurrency> <value>]]` {#config-show--set-service-middleware-option-key-value--label-qpsconcurrency-value} `service-middleware`はPDの設定モジュールであり、主にPDサービスのミドルウェア関数（監査ログ、リクエストレート制限、同時実行制限など）の管理と制御に使用されます。v8.5.0以降では、 `pd-ctl`を使用して`service-middleware`の以下の設定を変更できます。 @@ -466,7 +466,7 @@ config set service-middleware rate-limit GetRegion qps 0 config set service-middleware rate-limit GetRegion concurrency 0 ``` -### `config placement-rules [disable | enable | load | save | show | rule-group]` {#config-placement-rules-disable-enable-load-save-show-rule-group} +### `config placement-rules [disable | enable | load | save | show | rule-group]` {#config-placement-rules-disable--enable--load--save--show--rule-group} `config placement-rules [disable | enable | load | save | show | rule-group]`の使い方については[配置ルールを構成する](/configure-placement-rules.md#configure-rules)参照してください。 @@ -492,7 +492,7 @@ config set service-middleware rate-limit GetRegion concurrency 0 ] ``` -### `hot [read | write | store| history <start_time> <end_time> [<key> <value>]]` {#hot-read-write-store-history-x3c-start-time-x3c-end-time-x3c-key-x3c-value} +### `hot [read | write | store| history <start_time> <end_time> [<key> <value>]]` {#hot-read--write--store--history-start_time-end_time-key-value} このコマンドを使用して、クラスターのホット スポット情報を表示します。 @@ -550,7 +550,7 @@ config set service-middleware rate-limit GetRegion concurrency 0 v8.5.7 以降では、 `hot read`および`hot history`コマンドの出力に`flow_cpu`フィールドが含まれ、 `hot store`コマンドの出力に`cpu-read-rate`フィールドが含まれます。これらのフィールドは、CPU を認識した読み取りホットスポット スケジューリングのための読み取り CPU 使用率を示します。 -### `label [store <name> <value>]` {#label-store-x3c-name-x3c-value} +### `label [store <name> <value>]` {#label-store-name-value} このコマンドを使用して、クラスターのラベル情報を表示します。 @@ -561,7 +561,7 @@ v8.5.7 以降では、 `hot read`および`hot history`コマンドの出力に` >> label store zone cn // Display all stores including the "zone":"cn" label ``` -### `member [delete | leader_priority | leader [show | resign | transfer <member_name>]]` {#member-delete-leader-priority-leader-show-resign-transfer-x3c-member-name} +### `member [delete | leader_priority | leader [show | resign | transfer <member_name>]]` {#member-delete--leader_priority--leader-show--resign--transfer-member_name} > **Note:** > @@ -610,7 +610,7 @@ member leader_priority pd-5 0 > > 利用可能なすべての PD ノードの中で、優先順位番号が最も高いノードがリーダーになります。 -### `operator [check | show | add | remove]` {#operator-check-show-add-remove} +### `operator [check | show | add | remove]` {#operator-check--show--add--remove} このコマンドを使用して、スケジュール操作を表示および制御します。 @@ -647,7 +647,7 @@ member leader_priority pd-5 0 time: 43.12698ms ``` -### `region <region_id> [--jq="<query string>"]` {#region-x3c-region-id-jq-x3c-query-string} +### `region <region_id> [--jq="<query string>"]` {#region-region_id---jqquery-string} このコマンドを使用してリージョン情報を表示します。jq形式の出力については、 [jq形式のjson出力の使用法](#jq-formatted-json-output-usage)参照してください。 @@ -688,7 +688,7 @@ time: 43.12698ms } ``` -### `region key [--format=raw|encode|hex] <key>` {#region-key-format-raw-encode-hex-x3c-key} +### `region key [--format=raw|encode|hex] <key>` {#region-key---formatrawencodehex-key} このコマンドを使用して、特定のキーが存在するリージョンを照会します。raw形式、エンコード形式、および16進形式をサポートしています。エンコード形式の場合は、キーを一重引用符で囲む必要があります。 @@ -742,7 +742,7 @@ time: 43.12698ms } ``` -### `region sibling <region_id>` {#region-sibling-x3c-region-id} +### `region sibling <region_id>` {#region-sibling-region_id} このコマンドを使用して、特定のリージョンに隣接するリージョンを確認します。 @@ -756,7 +756,7 @@ time: 43.12698ms } ``` -### `region keys [--format=raw|encode|hex] <start_key> <end_key> <limit>` {#region-keys-format-raw-encode-hex-x3c-start-key-x3c-end-key-x3c-limit} +### `region keys [--format=raw|encode|hex] <start_key> <end_key> <limit>` {#region-keys---formatrawencodehex-start_key-end_key-limit} このコマンドを使用して、指定された範囲`[startkey, endkey)`内のすべてのリージョンを照会します。 `endKey`のない範囲もサポートされています。 @@ -790,7 +790,7 @@ time: 43.12698ms } ``` -### `region store <store_id>` {#region-store-x3c-store-id} +### `region store <store_id>` {#region-store-store_id} このコマンドを使用して、特定のストアのすべてのリージョンを一覧表示します。 @@ -875,7 +875,7 @@ time: 43.12698ms ``` -### `region check [miss-peer | extra-peer | down-peer | pending-peer | offline-peer | empty-region | hist-size | hist-keys] [--jq="<query string>"]` {#region-check-miss-peer-extra-peer-down-peer-pending-peer-offline-peer-empty-region-hist-size-hist-keys-jq-x3c-query-string} +### `region check [miss-peer | extra-peer | down-peer | pending-peer | offline-peer | empty-region | hist-size | hist-keys] [--jq="<query string>"]` {#region-check-miss-peer--extra-peer--down-peer--pending-peer--offline-peer--empty-region--hist-size--hist-keys---jqquery-string} このコマンドを使用して、異常状態にあるリージョンを確認します。jq形式の出力については、 [jq形式のJSON出力の使用法](#jq-formatted-json-output-usage)参照してください。 @@ -932,7 +932,7 @@ resource-manager config controller show pd-ctl resource-manager config controller set ltb-max-wait-duration 30m ``` -### `scheduler [show | add | remove | pause | resume | config | describe]` {#scheduler-show-add-remove-pause-resume-config-describe} +### `scheduler [show | add | remove | pause | resume | config | describe]` {#scheduler-show--add--remove--pause--resume--config--describe} このコマンドを使用して、スケジュール ポリシーを表示および制御します。 @@ -1187,7 +1187,7 @@ scheduler config balance-leader-scheduler set batch 3 // Set the size of the ope } ``` -### `store [delete | cancel-delete | label | weight | remove-tombstone | limit ] <store_id> [--jq="<query string>"]` {#store-delete-cancel-delete-label-weight-remove-tombstone-limit-x3c-store-id-jq-x3c-query-string} +### `store [delete | cancel-delete | label | weight | remove-tombstone | limit ] <store_id> [--jq="<query string>"]` {#store-delete--cancel-delete--label--weight--remove-tombstone--limit--store_id---jqquery-string} jq 形式の出力については、 [jq形式のjson出力の使用法](#jq-formatted-json-output-usage)参照してください。 @@ -1301,7 +1301,7 @@ store weight 1 5 10 > > `pd-ctl`使用すると、TiKVストアの状態（ `Up` 、 `Disconnect` 、 `Offline` 、 `Down` 、または`Tombstone` ）を確認できます。各状態の関係については、 [TiKVストアの各状態間の関係](/tidb-scheduling.md#information-collection)参照してください。 -### `log [fatal | error | warn | info | debug]` {#log-fatal-error-warn-info-debug} +### `log [fatal | error | warn | info | debug]` {#log-fatal--error--warn--info--debug} このコマンドを使用して、PD リーダーのログ レベルを設定します。 @@ -1323,7 +1323,7 @@ system: 2017-10-09 05:50:59 +0800 CST logic: 120102 ``` -### `unsafe remove-failed-stores [store-ids | show]` {#unsafe-remove-failed-stores-store-ids-show} +### `unsafe remove-failed-stores [store-ids | show]` {#unsafe-remove-failed-stores-store-ids--show} > **Warning:** > @@ -1358,7 +1358,7 @@ unsafe remove-failed-stores show ## Jq形式のJSON出力の使用 {#jq-formatted-json-output-usage} -### storeの出力を簡素化 {#simplify-the-output-of-code-store-code} +### storeの出力を簡素化 {#simplify-the-output-of-store} ```bash >> store --jq=".stores[].store | {id, address, state_name}" @@ -1376,7 +1376,7 @@ unsafe remove-failed-stores show ... ``` -### ステータスがUpではないすべてのノードを照会する {#query-all-nodes-whose-status-is-not-code-up-code} +### ステータスがUpではないすべてのノードを照会する {#query-all-nodes-whose-status-is-not-up} ```bash store --jq='.stores[].store | select(.state_name!="Up") | {id, address, state_name}' diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md index b8fc682b34f50..f2819ba15c2fb 100644 --- a/scale-tidb-using-tiup.md +++ b/scale-tidb-using-tiup.md @@ -21,7 +21,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する | 10.0.1.1 | TiKV | | 10.0.1.2 | TiKV | -## TiDB/PD/TiKV クラスターをスケールアウトする {#scale-out-a-tidb-pd-tikv-cluster} +## TiDB/PD/TiKV クラスターをスケールアウトする {#scale-out-a-tidbpdtikv-cluster} このセクションでは、 `10.0.1.5`ホストに TiDB ノードを追加する方法を例示します。 @@ -245,7 +245,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する | 10.0.1.1 | TiKV | | 10.0.1.2 | TiKV | -## TiDB/PD/TiKV クラスターのスケールイン {#scale-in-a-tidb-pd-tikv-cluster} +## TiDB/PD/TiKV クラスターのスケールイン {#scale-in-a-tidbpdtikv-cluster} このセクションでは、 `10.0.1.5`ホストから TiKV ノードを削除する方法を例示します。 diff --git a/schedule-replicas-by-topology-labels.md b/schedule-replicas-by-topology-labels.md index 09ff463606d60..bd0d575bf4105 100644 --- a/schedule-replicas-by-topology-labels.md +++ b/schedule-replicas-by-topology-labels.md @@ -13,7 +13,7 @@ TiDBクラスターの高可用性と災害復旧能力を向上させるには このメカニズムを有効にするには、TiKVとPDを適切に設定し、クラスターのトポロジ情報、特にTiKVの位置情報（特にデプロイメント中にPDに報告される）が適切に送信されるようにする必要があります。開始する前に、まず[TiUPを使用して TiDBをデプロイ](/production-deployment-using-tiup.md)ご確認ください。 -## TiKV、 TiFlash、TiDBのlabelsを構成する {#configure-code-labels-code-for-tikv-tiflash-and-tidb} +## TiKV、 TiFlash、TiDBのlabelsを構成する {#configure-labels-for-tikv-tiflash-and-tidb} クラスター トポロジに基づいて、TiKV、 TiFlash、および TiDB に`labels`設定できます。 @@ -160,7 +160,7 @@ TiUPを使用してクラスターをデプロイする場合、 [初期化設 ### コマンドラインまたは構成ファイルを使用してクラスターを構成する {#configure-a-cluster-using-command-lines-or-configuration-files} -#### TiKVとTiFlashのlabelsを設定する {#configure-code-labels-code-for-tikv-and-tiflash} +#### TiKVとTiFlashのlabelsを設定する {#configure-labels-for-tikv-and-tiflash} コマンドラインフラグを使用するか、TiKVまたはTiFlash構成ファイルを設定すると、キーと値のペアの形式でいくつかの属性をバインドできます。これらの属性は`labels`呼ばれます。TiKVとTiFlashは起動後、PDに`labels`報告し、ユーザーがTiKVノードとTiFlashノードの位置を特定できるようにします。 @@ -194,7 +194,7 @@ rack = "" host = "" ``` -#### (オプション) TiDBのlabelsを構成する {#optional-configure-code-labels-code-for-tidb} +#### (オプション) TiDBのlabelsを構成する {#optional-configure-labels-for-tidb} [Followerが読んだ](/follower-read.md)有効になっている場合、TiDB が同じリージョンからのデータを優先的に読み取るようにするには、TiDB ノードに対して`labels`設定する必要があります。 @@ -212,7 +212,7 @@ host = "" > > 現在、TiDBは、同じリージョンにあるレプリカのマッチングと選択に`zone`ラベルを使用しています。この機能を使用するには、 [PDの`location-labels`設定](#configure-location-labels-for-pd)設定する際に`zone`追加し、TiDB、TiKV、 TiFlashを設定する際に`labels`設定する際に`zone`追加する必要があります。詳細については、 [TiKVとTiFlashの`labels`を設定する](#configure-labels-for-tikv-and-tiflash)参照してください。 -## PDのlocation-labelsを設定する {#configure-code-location-labels-code-for-pd} +## PDのlocation-labelsを設定する {#configure-location-labels-for-pd} 上記の説明によると、ラベルはTiKV属性を記述するために使用される任意のキーと値のペアです。しかし、PDは位置関連のラベルとそれらのラベルのレイヤー関係を識別できません。そのため、PDがTiKVノードのトポロジを理解できるように、以下の設定を行う必要があります。 @@ -240,7 +240,7 @@ host = "" pd-ctl config set location-labels zone,rack,host ``` -## PDのisolation-levelを設定する {#configure-code-isolation-level-code-for-pd} +## PDのisolation-levelを設定する {#configure-isolation-level-for-pd} `location-labels`が設定されている場合は、PD 設定ファイルで`isolation-level`設定することで、TiKV クラスターのトポロジ分離要件をさらに強化できます。 diff --git a/security-compatibility-with-mysql.md b/security-compatibility-with-mysql.md index 38bc790053180..06adbb90b31a6 100644 --- a/security-compatibility-with-mysql.md +++ b/security-compatibility-with-mysql.md @@ -140,7 +140,7 @@ The support for TLS authentication is configured differently. For detailed infor | GSSAPI (MariaDB) | いいえ | | ファイド | いいえ | -### `tidb_auth_token` {#tidb-auth-token} +### `tidb_auth_token` {#tidb_auth_token} `tidb_auth_token` [JSON Web Token (JWT)](https://datatracker.ietf.org/doc/html/rfc7519)ベースにしたパスワードレス認証方式です。v6.4.0では、 `tidb_auth_token` TiDB Cloudのユーザー認証にのみ使用されます。v6.5.0以降では、 `tidb_auth_token` TiDB Self-Managedのユーザー認証方式としても設定できます。 `mysql_native_password`や`caching_sha2_password`などのパスワードベースの認証方式とは異なり、 `tidb_auth_token`を使用してユーザーを作成する場合、カスタムパスワードを設定したり保存したりする必要はありません。TiDBにログインするには、ユーザーはパスワードの代わりに署名付きトークンを使用するだけで済むため、認証プロセスが簡素化され、セキュリティが向上します。 diff --git a/sql-plan-replayer.md b/sql-plan-replayer.md index 52147e75e1885..a8f29c9d0afcb 100644 --- a/sql-plan-replayer.md +++ b/sql-plan-replayer.md @@ -12,7 +12,7 @@ TiDB クラスタの問題を特定してトラブルシューティングする - オンサイトトラブルシューティング時の TiDB クラスターの情報を ZIP 形式のファイルにエクスポートしてstorage。 - 別のTiDBクラスタからエクスポートされたZIP形式のファイルをクラスタにインポートします。このファイルには、オンサイトトラブルシューティング時の後者のTiDBクラスタの情報が含まれています。 -## PLAN REPLAYERを使用してクラスター情報をエクスポートします {#use-code-plan-replayer-code-to-export-cluster-information} +## PLAN REPLAYERを使用してクラスター情報をエクスポートします {#use-plan-replayer-to-export-cluster-information} `PLAN REPLAYER`使用すると、TiDBクラスタのオンサイト情報を保存できます。エクスポートインターフェースは次のとおりです。 @@ -121,7 +121,7 @@ http://${tidb-server-ip}:${tidb-server-status-port}/plan_replayer/dump/${file_to curl http://127.0.0.1:10080/plan_replayer/dump/replayer_JOGvpu4t7dssySqJfTtS4A==_1635750890568691080.zip > plan_replayer.zip ``` -## PLAN REPLAYERを使用してクラスター情報をインポートする {#use-code-plan-replayer-code-to-import-cluster-information} +## PLAN REPLAYERを使用してクラスター情報をインポートする {#use-plan-replayer-to-import-cluster-information} > **Warning:** > @@ -188,7 +188,7 @@ mysql> show stats_meta; > > `mysql`コマンドラインクライアントを使用していて`ERROR 2068 (HY000): LOAD DATA LOCAL INFILE file request rejected due to restrictions on access.`遭遇した場合は、接続文字列に`--local-infile=true`追加できます。 -## PLAN REPLAYER CAPTUREを使用してターゲットプランをキャプチャします {#use-code-plan-replayer-capture-code-to-capture-target-plans} +## PLAN REPLAYER CAPTUREを使用してターゲットプランをキャプチャします {#use-plan-replayer-capture-to-capture-target-plans} TiDBの実行プランを特定する場合、対象となるSQL文と実行プランがクエリ内にまれにしか出現しないため、 `PLAN REPLAYER`使用して文とプランを直接取得できない場合があります。このような場合、 `PLAN REPLAYER CAPTURE`使用すると、対象となるSQL文と実行プランのオプティマイザー情報を取得できます。 @@ -200,11 +200,11 @@ TiDBの実行プランを特定する場合、対象となるSQL文と実行プ - システム テーブルを通じて、進行中の一致するタスクと生成されたファイルを表示します。 - 履歴ファイルを定期的にクリーンアップします。 -### PLAN REPLAYER CAPTUREを有効にする {#enable-code-plan-replayer-capture-code} +### PLAN REPLAYER CAPTUREを有効にする {#enable-plan-replayer-capture} `PLAN REPLAYER CAPTURE`はシステム変数[`tidb_enable_plan_replayer_capture`](/system-variables.md#tidb_enable_plan_replayer_capture)によって制御されます。4 `PLAN REPLAYER CAPTURE`有効にするには、システム変数の値を`ON`に設定します。 -### PLAN REPLAYER CAPTURE使用する {#use-code-plan-replayer-capture-code} +### PLAN REPLAYER CAPTURE使用する {#use-plan-replayer-capture} 次のステートメントを使用して、対象の SQL ステートメントと実行プランのダイジェストを TiDB クラスターに登録できます。 @@ -235,7 +235,7 @@ mysql> SELECT * FROM mysql.plan_replayer_task; 1 row in set (0.01 sec) ``` -### キャプチャ結果を表示する {#view-the-capture-results} +### キャプチャ結果を表示する {#view-the-capture-results-1} `PLAN REPLAYER CAPTURE`結果を正常に取得したら、次の SQL ステートメントを使用して、ファイルのダウンロードに使用されたトークンを表示できます。 @@ -280,11 +280,11 @@ mysql> SELECT * FROM mysql.plan_replayer_task; Empty set (0.01 sec) ``` -## PLAN REPLAYER CONTINUOUS CAPTUREを使用する {#use-code-plan-replayer-continuous-capture-code} +## PLAN REPLAYER CONTINUOUS CAPTUREを使用する {#use-plan-replayer-continuous-capture} `PLAN REPLAYER CONTINUOUS CAPTURE`有効にすると、TiDB はアプリケーションの SQL 文を`SQL DIGEST`と`PLAN DIGEST`に基づいて`PLAN REPLAYER`方法で非同期的に記録します。同じ DIGEST を共有する SQL 文と実行プランについては、 `PLAN REPLAYER CONTINUOUS CAPTURE`によって重複して記録されません。 -### PLAN REPLAYER CONTINUOUS CAPTUREを有効にする {#enable-code-plan-replayer-continuous-capture-code} +### PLAN REPLAYER CONTINUOUS CAPTUREを有効にする {#enable-plan-replayer-continuous-capture} `PLAN REPLAYER CONTINUOUS CAPTURE`はシステム変数[`tidb_enable_plan_replayer_continuous_capture`](/system-variables.md#tidb_enable_plan_replayer_continuous_capture-new-in-v700)によって制御されます。4 `PLAN REPLAYER CONTINUOUS CAPTURE`有効にするには、システム変数の値を`ON`に設定します。 diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index ee8dce525a4f1..d814196a8d31e 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -126,7 +126,7 @@ MySQL [test]> select @@last_plan_from_cache; ## プリペアドプランキャッシュの診断 {#diagnostics-of-prepared-plan-cache} -### SHOW WARNINGSを使用して診断する {#use-code-show-warnings-code-to-diagnose} +### SHOW WARNINGSを使用して診断する {#use-show-warnings-to-diagnose} 一部のクエリまたはプランはキャッシュできません。1 ステートメント`SHOW WARNINGS`使用して、クエリまたはプランがキャッシュされているかどうかを確認できます。キャッシュされていない場合は、結果で失敗の理由を確認できます。例: @@ -166,7 +166,7 @@ mysql> SHOW WARNINGS; 1 row in set (0.00 sec) ``` -### 診断にはStatements Summaryを使用する {#use-code-statements-summary-code-to-diagnose} +### 診断にはStatements Summaryを使用する {#use-statements-summary-to-diagnose} `Statements Summary`テーブルには`plan_cache_unqualified`と`plan_cache_unqualified_last_reason`という2つのフィールドがあり、それぞれ対応するクエリがプランキャッシュを使用できなかった回数とその理由を示します。これらの2つのフィールドは診断に使用できます。 @@ -287,7 +287,7 @@ MySQL [test]> admin flush global plan_cache; ERROR 1105 (HY000): Do not support the 'admin flush global scope.' ``` -## COM_STMT_CLOSEコマンドとDEALLOCATE PREPAREステートメントを無視します。 {#ignore-the-code-com-stmt-close-code-command-and-the-code-deallocate-prepare-code-statement} +## COM_STMT_CLOSEコマンドとDEALLOCATE PREPAREステートメントを無視します。 {#ignore-the-com_stmt_close-command-and-the-deallocate-prepare-statement} SQL ステートメントの構文解析コストを削減するには、 `prepare stmt` 1 回実行し、次に`execute stmt`複数回実行してから`deallocate prepare`実行することをお勧めします。 diff --git a/sql-statements/sql-statement-admin-bdr-role.md b/sql-statements/sql-statement-admin-bdr-role.md index d351c3e6ae370..6fce689c9c0fa 100644 --- a/sql-statements/sql-statement-admin-bdr-role.md +++ b/sql-statements/sql-statement-admin-bdr-role.md @@ -3,7 +3,7 @@ title: ADMIN [SET|SHOW|UNSET] BDR ROLE summary: TiDB データベースの ADMIN [SET|SHOW|UNSET] BDR ROLE の使用法の概要。 --- -# ADMIN [SET|SHOW|UNSET] BDR ROLE {#admin-set-show-unset-bdr-role} +# ADMIN [SET|SHOW|UNSET] BDR ROLE {#admin-setshowunset-bdr-role} - クラスターのBDRロールを設定するには、 `ADMIN SET BDR ROLE`使用します。現在、TiDBクラスターには`PRIMARY`と`SECONDARY` BDRロールを設定できます。BDRロールの詳細については、 [TiCDC 双方向レプリケーションにおける DDL 同期](/ticdc/ticdc-bidirectional-replication.md#ddl-replication)参照してください。 - クラスターの BDR ロールを表示するには、 `ADMIN SHOW BDR ROLE`使用します。 diff --git a/sql-statements/sql-statement-admin.md b/sql-statements/sql-statement-admin.md index e8926adef2b82..888a00e698ffc 100644 --- a/sql-statements/sql-statement-admin.md +++ b/sql-statements/sql-statement-admin.md @@ -40,7 +40,7 @@ summary: TiDBデータベースにおけるADMINの使用方法の概要。 -## ADMIN RELOADステートメント {#code-admin-reload-code-statement} +## ADMIN RELOADステートメント {#admin-reload-statement} ```sql ADMIN RELOAD expr_pushdown_blacklist; @@ -54,7 +54,7 @@ ADMIN RELOAD opt_rule_blacklist; 上記のステートメントは、ロジック最適化ルールのブロックリストを再読み込みするために使用されます。 -## ADMIN PLUGINS関連のステートメント {#code-admin-plugins-code-related-statement} +## ADMIN PLUGINS関連のステートメント {#admin-plugins-related-statement} > **Note:** > @@ -72,7 +72,7 @@ ADMIN PLUGINS DISABLE plugin_name [, plugin_name] ...; 上記のステートメントは`plugin_name`プラグインを無効にするために使用されます。 -## ADMIN BINDINGS関連のステートメント {#code-admin-bindings-code-related-statement} +## ADMIN BINDINGS関連のステートメント {#admin-bindings-related-statement} ```sql ADMIN FLUSH BINDINGS; @@ -98,7 +98,7 @@ ADMIN RELOAD BINDINGS; 上記のステートメントは、SQLプランのバインディング情報を再読み込みするために使用されます。 -## ADMIN REPAIRステートメント {#code-admin-repair-code-statement} +## ADMIN REPAIRステートメント {#admin-repair-statement} @@ -120,7 +120,7 @@ ADMIN REPAIR TABLE tbl_name CREATE TABLE STATEMENT; -## ADMIN SHOW NEXT_ROW_IDステートメント {#code-admin-show-next-row-id-code-statement} +## ADMIN SHOW NEXT_ROW_IDステートメント {#admin-show-next_row_id-statement} ```sql ADMIN SHOW t NEXT_ROW_ID; @@ -128,7 +128,7 @@ ADMIN SHOW t NEXT_ROW_ID; 上記のステートメントは、テーブルの特定の列の詳細を表示するために使用されます。出力は[SHOW TABLE NEXT_ROW_ID](/sql-statements/sql-statement-show-table-next-rowid.md)と同じです。 -## ADMIN SHOW SLOWステートメント {#code-admin-show-slow-code-statement} +## ADMIN SHOW SLOWステートメント {#admin-show-slow-statement} > **Note:** > diff --git a/sql-statements/sql-statement-alter-table-compact.md b/sql-statements/sql-statement-alter-table-compact.md index 696f30812bbcc..51baa6dfaeff9 100644 --- a/sql-statements/sql-statement-alter-table-compact.md +++ b/sql-statements/sql-statement-alter-table-compact.md @@ -3,7 +3,7 @@ title: ALTER TABLE ... COMPACT summary: TiDB データベースの ALTER TABLE ... COMPACT の使用法の概要。 --- -# ALTER TABLE ... COMPACT {#alter-table-compact} +# ALTER TABLE ... COMPACT {#alter-table--compact} 読み取りパフォーマンスを向上させ、ディスク使用量を削減するために、TiDB はストレージノード上でバックグラウンドでデータ圧縮を自動的にスケジュールします。圧縮中、ストレージノードは物理データを書き換えます。これには、削除された行のクリーンアップや、更新によって発生した複数のデータバージョンのマージなどが含まれます。1 ステートメントを使用すると、 `ALTER TABLE ... COMPACT`グラウンドで圧縮がトリガーされるまで待たずに、特定のテーブルの圧縮を即座に開始できます。 diff --git a/sql-statements/sql-statement-create-sequence.md b/sql-statements/sql-statement-create-sequence.md index bf4d09fac7f7a..17dc77d6bbbc6 100644 --- a/sql-statements/sql-statement-create-sequence.md +++ b/sql-statements/sql-statement-create-sequence.md @@ -61,7 +61,7 @@ CREATE [TEMPORARY] SEQUENCE [IF NOT EXISTS] sequence_name | `CACHE` | `1000` | TiDB 内のシーケンスのローカル キャッシュ サイズを指定します。 | | `CYCLE` | `NO CYCLE` | シーケンスを最小値（降順シーケンスの場合は最大値）から再開するかどうかを指定します。1 > `0` `INCREMENT` 、デフォルト値は`MINVALUE`です。7 < `INCREMENT` `0`場合、デフォルト値は`MAXVALUE`です。 | -## SEQUENCE関数 {#code-sequence-code-function} +## SEQUENCE関数 {#sequence-function} 次の式関数を通じてシーケンスを制御できます。 diff --git a/sql-statements/sql-statement-overview.md b/sql-statements/sql-statement-overview.md index 88d9a0e670141..60a124245afab 100644 --- a/sql-statements/sql-statement-overview.md +++ b/sql-statements/sql-statement-overview.md @@ -7,7 +7,7 @@ summary: TiDBでサポートされているSQL文について学びましょう TiDBは、ISO/IEC SQL標準に準拠することを目的としたSQL文を使用しており、必要に応じてMySQL用の拡張機能やTiDB固有の文が追加されています。 -## スキーマ管理／データ定義文（DDL） {#schema-management-data-definition-statements-ddl} +## スキーマ管理／データ定義文（DDL） {#schema-management--data-definition-statements-ddl} | SQLステートメント | 説明 | | ---------------------------------------------------------------------------------- | ---------------------------------------------------- | @@ -132,7 +132,7 @@ TiDBは、ISO/IEC SQL標準に準拠することを目的としたSQL文を使 | [`LOAD DATA`](/sql-statements/sql-statement-load-data.md) | Amazon S3またはGoogle Cloud Storageからデータをテーブルに読み込みます。 | | [`SHOW IMPORT JOB`](/sql-statements/sql-statement-show-import-job.md) | インポートジョブのステータスを表示します。 | -## バックアップと復元 {#backup-x26-restore} +## バックアップと復元 {#backup--restore} | SQLステートメント | 説明 | | --------------------------------------------------------------------------- | --------------------------------------------- | @@ -269,7 +269,7 @@ TiDBは、ISO/IEC SQL標準に準拠することを目的としたSQL文を使 | [`UNLOCK STATS`](/sql-statements/sql-statement-unlock-stats.md) | テーブルまたはパーティションの統計情報へのアクセス権限を解放します。 | | [`UNLOCK TABLES`](/sql-statements/sql-statement-lock-tables-and-unlock-tables.md) | テーブルのロックを解除します。 | -## アカウント管理／データ制御言語 {#account-management-data-control-language} +## アカウント管理／データ制御言語 {#account-management--data-control-language} | SQLステートメント | 説明 | | -------------------------------------------------------------------------------- | ------------------------------ | diff --git a/statement-summary-tables.md b/statement-summary-tables.md index 4e9dc0159d1d3..8abf6b2ac8e9c 100644 --- a/statement-summary-tables.md +++ b/statement-summary-tables.md @@ -21,7 +21,7 @@ SQL のパフォーマンス問題をより適切に処理するために、MySQ このドキュメントでは、これらのテーブルの詳細を説明し、SQLのパフォーマンス問題のトラブルシューティングにそれらを使用する方法を紹介します。 -## `statements_summary` {#statements-summary} +## `statements_summary` {#statements_summary} `statements_summary`は`information_schema`内のシステム テーブルです。 `statements_summary`は、SQL ステートメントをリソース グループ、SQL ダイジェスト、およびプラン ダイジェストごとにグループ化し、各 SQL カテゴリの統計情報を提供します。 @@ -82,13 +82,13 @@ select * from employee where id in (...) and salary between ? and ?; > - TiDBでは、ステートメントサマリーテーブルのフィールドの時間単位はナノ秒（ns）ですが、MySQLではピコ秒（ps）です。 > - v7.5.1 および v7.6.0 以降、 が有効に[リソース制御](/tidb-resource-control-ru-groups.md)ているクラスターでは、 `statements_summary`リソース グループごとに集約されます。たとえば、異なるリソース グループで実行された同じステートメントは、異なるレコードとして収集されます。 -## `statements_summary_history` {#statements-summary-history} +## `statements_summary_history` {#statements_summary_history} `statements_summary_history`のテーブルスキーマは`statements_summary`と同一です。 `statements_summary_history`は、特定の期間の履歴データを保存します。履歴データを確認することで、異常のトラブルシューティングや、異なる期間の監視メトリクスの比較を行うことができます。 `SUMMARY_BEGIN_TIME`フィールドと`SUMMARY_END_TIME`フィールドは、履歴期間の開始時刻と終了時刻を表します。 -## `statements_summary_evicted` {#statements-summary-evicted} +## `statements_summary_evicted` {#statements_summary_evicted} [`tidb_stmt_summary_max_stmt_count`](/system-variables.md#tidb_stmt_summary_max_stmt_count-new-in-v40)システム変数は`statements_summary`テーブルと`statements_summary_history`テーブルがメモリに格納できる SQL ダイジェストの総数を制限します。この制限を超えると、TiDB は`statements_summary`テーブルと`statements_summary_history`テーブルの両方から、最も使用頻度の低い SQL ダイジェストを削除します。 @@ -114,7 +114,7 @@ select * from employee where id in (...) and salary between ? and ?; -## ステートメントサマリーのclusterテーブル {#the-code-cluster-code-tables-for-statement-summary} +## ステートメントサマリーのclusterテーブル {#the-cluster-tables-for-statement-summary} `statements_summary` 、 `statements_summary_history` 、および`statements_summary_evicted`テーブルには、単一の TiDBサーバーのステートメントの概要のみが表示されます。クラスタ全体のデータを照会するには、 `cluster_statements_summary` 、 `cluster_statements_summary_history` 、または`cluster_statements_summary_evicted`テーブルを照会する必要があります。 @@ -312,7 +312,7 @@ SELECT sum_latency, avg_latency, exec_count, query_sample_text ## フィールドの説明 {#fields-description} -### statements_summaryフィールドの説明 {#code-statements-summary-code-fields-description} +### statements_summaryフィールドの説明 {#statements_summary-fields-description} 以下は`statements_summary`テーブルのフィールドの説明です。 @@ -448,7 +448,7 @@ TiKVコプロセッサータスクに関連するフィールド： - `STORAGE_KV` : v8.5.5 で導入され、このカテゴリの SQL ステートメントの以前の実行が TiKV からデータを読み取ったかどうかを示します。 - `STORAGE_MPP` : v8.5.5 で導入され、このカテゴリの SQL ステートメントの以前の実行がTiFlashからデータを読み取ったかどうかを示します。 -### statements_summary_evictedフィールドの説明 {#code-statements-summary-evicted-code-fields-description} +### statements_summary_evictedフィールドの説明 {#statements_summary_evicted-fields-description} - `BEGIN_TIME` : 開始時刻を記録します。 - `END_TIME` : 終了時刻を記録します。 diff --git a/storage-engine/titan-overview.md b/storage-engine/titan-overview.md index 72e9e903b8ca2..b08e9c7c682aa 100644 --- a/storage-engine/titan-overview.md +++ b/storage-engine/titan-overview.md @@ -131,7 +131,7 @@ Titan は、選択された BLOB ファイルについて、各値に対応す 後方互換性のため、スケーリング中もTiKVスナップショットはRocksDB形式のままです。スケーリングされたノードはすべてRocksDBから取得されるため、従来のTiKVノードよりも高い圧縮率、より小さいストアサイズ、コンパクション時の比較的大きな書き込み増幅など、RocksDBの特性を引き継いでいます。これらのRocksDB形式のSSTファイルは、コンパクション後に徐々にTitan形式に変換されます。 -### min-blob-sizeがパフォーマンスに与える影響 {#impact-of-code-min-blob-size-code-on-performance} +### min-blob-sizeがパフォーマンスに与える影響 {#impact-of-min-blob-size-on-performance} [`min-blob-size`](/tikv-configuration-file.md#min-blob-size) 、値が Titan に格納されるかどうかを決定します。値が`min-blob-size`以上の場合、Titan に格納されます。それ以外の場合は、ネイティブの RocksDB 形式で格納されます。4 `min-blob-size`小さすぎたり大きすぎたりすると、パフォーマンスに影響します。 diff --git a/sys-schema/sys-schema-unused-indexes.md b/sys-schema/sys-schema-unused-indexes.md index a4eb98f25d3a2..3951a4bf33dc1 100644 --- a/sys-schema/sys-schema-unused-indexes.md +++ b/sys-schema/sys-schema-unused-indexes.md @@ -3,7 +3,7 @@ title: schema_unused_indexes summary: sys` スキーマの `schema_unused_indexes` テーブルについて学習します。 --- -# `schema_unused_indexes` {#schema-unused-indexes} +# `schema_unused_indexes` {#schema_unused_indexes} `schema_unused_indexes` 、TiDB の前回の起動以降使用されていないインデックスを記録します。以下の列が含まれます。 @@ -29,7 +29,7 @@ DESC SCHEMA_UNUSED_INDEXES; 3 rows in set (0.00 sec) ``` -## schema_unused_indexesビューを手動で作成する {#manually-create-the-code-schema-unused-indexes-code-view} +## schema_unused_indexesビューを手動で作成する {#manually-create-the-schema_unused_indexes-view} v8.0.0より前のバージョンからアップグレードされたクラスターの場合、 `sys`スキーマとその中のビューは自動的には作成されません。以下のSQL文を使用して手動で作成できます。 diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md index 78011d4cad652..f967a1312c5b1 100644 --- a/ticdc/ticdc-ddl.md +++ b/ticdc/ticdc-ddl.md @@ -59,7 +59,7 @@ summary: TiCDC でサポートされている DDL ステートメントといく ## DDLレプリケーションの考慮事項 {#ddl-replication-considerations} -### ADD INDEXおよびCREATE INDEX DDL の非同期実行 {#asynchronous-execution-of-code-add-index-code-and-code-create-index-code-ddls} +### ADD INDEXおよびCREATE INDEX DDL の非同期実行 {#asynchronous-execution-of-add-index-and-create-index-ddls} ダウンストリームがTiDBの場合、TiCDCは`ADD INDEX`と`CREATE INDEX` DDL操作を非同期的に実行し、変更フィードレプリケーションのレイテンシーへの影響を最小限に抑えます。つまり、 `ADD INDEX`と`CREATE INDEX` DDLをダウンストリームTiDBにレプリケーションして実行した後、TiCDCはDDL実行の完了を待たずに直ちに戻ります。これにより、後続のDML実行がブロックされることを回避できます。 diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index e855f9abd2dee..e5af1f4f81d9c 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -11,7 +11,7 @@ summary: TiCDC を使用する際に遭遇する可能性のある FAQ につい > > このドキュメントでは、 `cdc cli`コマンドで指定されているサーバーアドレスは`--server=http://127.0.0.1:8300`です。コマンドを使用する際は、このアドレスを実際の PD アドレスに置き換えてください。 -## TiCDC でタスクを作成するときにstart-ts選択するにはどうすればよいですか? {#how-do-i-choose-code-start-ts-code-when-creating-a-task-in-ticdc} +## TiCDC でタスクを作成するときにstart-ts選択するにはどうすればよいですか? {#how-do-i-choose-start-ts-when-creating-a-task-in-ticdc} レプリケーションタスクの`start-ts`は、上流TiDBクラスタ内のタイムスタンプOracle（TSO）に対応します。TiCDCは、レプリケーションタスクでこのTSOにデータを要求します。したがって、レプリケーションタスクの`start-ts` 、以下の要件を満たす必要があります。 @@ -20,7 +20,7 @@ summary: TiCDC を使用する際に遭遇する可能性のある FAQ につい `start-ts`指定しない場合、または`start-ts` `0`として指定した場合、レプリケーション タスクが開始されると、TiCDC は現在の TSO を取得し、この TSO からタスクを開始します。 -## TiCDC でタスクを作成するときに一部のテーブルを複製できないのはなぜですか? {#why-can-t-some-tables-be-replicated-when-i-create-a-task-in-ticdc} +## TiCDC でタスクを作成するときに一部のテーブルを複製できないのはなぜですか? {#why-cant-some-tables-be-replicated-when-i-create-a-task-in-ticdc} `cdc cli changefeed create`実行してレプリケーションタスクを作成すると、TiCDC は上流のテーブルが[レプリケーション要件](/ticdc/ticdc-overview.md#best-practices)を満たしているかどうかを確認します。要件を満たしていないテーブルがある場合は、 `some tables are not eligible to replicate`不適格なテーブルのリストが返されます。タスクの作成を続行するには`Y`または`y`選択できます。この場合、これらのテーブルに対するすべての更新はレプリケーション中に自動的に無視されます。 `Y`または`y`以外の入力を選択した場合、レプリケーションタスクは作成されません。 @@ -158,7 +158,7 @@ cdc cli changefeed list --server=http://127.0.0.1:8300 最新の`primary_ts`に対応する時間が、手順 1 で取得した上流 TiDB クラスターの TSO 以上である場合、TiCDC はすべての更新を下流に複製しています。 -## TiCDC のgc-ttlとは何ですか? {#what-is-code-gc-ttl-code-in-ticdc} +## TiCDC のgc-ttlとは何ですか? {#what-is-gc-ttl-in-ticdc} v4.0.0-rc.1以降、PDはサービスレベルのGCセーフポイントの設定において外部サービスをサポートします。どのサービスでもGCセーフポイントを登録・更新できます。PDは、このGCセーフポイント以降のキーバリューデータがGCによってクリーンアップされないようにします。 @@ -189,7 +189,7 @@ TiCDC がサービス GC セーフポイントに設定するデフォルトの 2. 値を`gc-ttl`に増やすと、エラーを修正するための時間が長くなり、エラーが修正された後にレプリケーションの遅延が`gc-ttl`超えたためにレプリケーション タスクが`failed`ステータスにならないようになります。 3. システムへの影響を評価した後、TiDB の値を[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)増やして GC をブロックし、データを保持して、エラーが修正された後に GC がデータをクリーンアップすることによってレプリケーション タスクが`failed`ステータスにならないようにします。 -## TiCDC タイムゾーンとupstream/downstreamデータベースのタイムゾーンの関係を理解するにはどうすればよいでしょうか? {#how-to-understand-the-relationship-between-the-ticdc-time-zone-and-the-time-zones-of-the-upstream-downstream-databases} +## TiCDC タイムゾーンとupstream/downstreamデータベースのタイムゾーンの関係を理解するにはどうすればよいでしょうか? {#how-to-understand-the-relationship-between-the-ticdc-time-zone-and-the-time-zones-of-the-upstreamdownstream-databases} | | 上流タイムゾーン | TiCDCタイムゾーン | 下流タイムゾーン | | :----------: | :-------------------------------------------------------------------------: | :----------------------------------------------------------------------------------: | :------------------------------------------------------------------------------: | @@ -208,7 +208,7 @@ TiCDC がサービス GC セーフポイントに設定するデフォルトの > - `--tz`利用できない場合、TiCDC は`TZ`環境変数を使用してタイム ゾーン セットを読み取ろうとします。 > - `TZ`環境変数が使用できない場合、TiCDC はマシンのデフォルトのタイムゾーンを使用します。 -## --configで構成ファイルを指定せずにレプリケーション タスクを作成した場合、TiCDC のデフォルトの動作はどうなりますか? {#what-is-the-default-behavior-of-ticdc-if-i-create-a-replication-task-without-specifying-the-configuration-file-in-code-config-code} +## --configで構成ファイルを指定せずにレプリケーション タスクを作成した場合、TiCDC のデフォルトの動作はどうなりますか? {#what-is-the-default-behavior-of-ticdc-if-i-create-a-replication-task-without-specifying-the-configuration-file-in---config} `-config`パラメータを指定せずに`cdc cli changefeed create`コマンドを使用すると、TiCDC は次のデフォルト動作でレプリケーション タスクを作成します。 @@ -272,7 +272,7 @@ cdc cli changefeed create --server=http://127.0.0.1:8300 --sink-uri="kafka://127 Kafka メッセージのキーの`ts` 18 ビット右に移動すると、Unix タイムスタンプを取得できます。 -## TiCDC オープン プロトコルはnullどのように表現しますか? {#how-does-ticdc-open-protocol-represent-code-null-code} +## TiCDC オープン プロトコルはnullどのように表現しますか? {#how-does-ticdc-open-protocol-represent-null} TiCDC オープン プロトコルでは、タイプ コード`6`は`null`表します。 @@ -282,7 +282,7 @@ TiCDC オープン プロトコルでは、タイプ コード`6`は`null`表し 詳細については[TiCDCオープンプロトコル列タイプコード](/ticdc/ticdc-open-protocol.md#column-type-code)を参照してください。 -## TiCDC オープン プロトコルの行変更イベントがINSERTイベントなのかUPDATEイベントなのかをどのように判断すればよいですか? {#how-can-i-tell-if-a-row-changed-event-of-ticdc-open-protocol-is-an-code-insert-code-event-or-an-code-update-code-event} +## TiCDC オープン プロトコルの行変更イベントがINSERTイベントなのかUPDATEイベントなのかをどのように判断すればよいですか? {#how-can-i-tell-if-a-row-changed-event-of-ticdc-open-protocol-is-an-insert-event-or-an-update-event} - `UPDATE`イベントには`"p"`と`"u"`両方のフィールドが含まれます - `INSERT`イベントには`"u"`フィールドのみが含まれます @@ -333,7 +333,7 @@ TiDB v7.1.0より前のバージョンでは、TiCDCは新旧のデータが同 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} +## DDL文を下流のMySQL 5.7に複製する際に、時間型フィールドのデフォルト値が一致しません。どうすればよいでしょうか？ {#the-default-value-of-the-time-type-field-is-inconsistent-when-replicating-a-ddl-statement-to-the-downstream-mysql-57-what-can-i-do} 上流のTiDBで`create table test (id int primary key, ts timestamp)`文が実行されたとします。TiCDCがこの文を下流のMySQL 5.7に複製する際、MySQLはデフォルト設定を使用します。複製後のテーブルスキーマは以下のようになります。3 `timestamp`のフィールドのデフォルト値は`CURRENT_TIMESTAMP`になります。 @@ -355,7 +355,7 @@ mysql root@127.0.0.1:test> show create table test; v5.0.1 または v4.0.13 以降、MySQL へのレプリケーションごとに、TiCDC は上流と下流の間で時刻型の一貫性を保つために、自動的に`explicit_defaults_for_timestamp = ON`設定します。v5.0.1 または v4.0.13 より前のバージョンでは、TiCDC を使用して時刻型データをレプリケーションする際に、不一致な`explicit_defaults_for_timestamp`値によって発生する互換性の問題にご注意ください。 -## TiCDC レプリケーション タスクを作成するときにsafe-mode trueに設定すると、アップストリームからのINSERT / UPDATEステートメントがダウンストリームにレプリケートされた後にREPLACE INTOになるのはなぜですか? {#why-do-code-insert-code-code-update-code-statements-from-the-upstream-become-code-replace-into-code-after-being-replicated-to-the-downstream-if-i-set-code-safe-mode-code-to-code-true-code-when-i-create-a-ticdc-replication-task} +## TiCDC レプリケーション タスクを作成するときにsafe-mode trueに設定すると、アップストリームからのINSERT / UPDATEステートメントがダウンストリームにレプリケートされた後にREPLACE INTOになるのはなぜですか? {#why-do-insertupdate-statements-from-the-upstream-become-replace-into-after-being-replicated-to-the-downstream-if-i-set-safe-mode-to-true-when-i-create-a-ticdc-replication-task} TiCDCは、すべてのデータが少なくとも1回は複製されることを保証します。下流に重複データが存在する場合、書き込み競合が発生します。この問題を回避するために、TiCDCは`INSERT`と`UPDATE`ステートメントを`REPLACE INTO`ステートメントに変換します。この動作は`safe-mode`パラメータによって制御されます。 @@ -430,7 +430,7 @@ enable-table-across-nodes = true TiDBにはトランザクションタイムアウト機構があります。トランザクションの実行時間が[`max-txn-ttl`](/tidb-configuration-file.md#max-txn-ttl)秒を超えると、TiDBは強制的にロールバックします。TiCDCはトランザクションがコミットされるまで待機してからレプリケーションを続行するため、レプリケーションの遅延が発生します。 -## TiDB Operatorによってデプロイされた TiCDC クラスターをcdc cliコマンドを使用して操作できないのはなぜですか? {#why-can-t-i-use-the-code-cdc-cli-code-command-to-operate-a-ticdc-cluster-deployed-by-tidb-operator} +## TiDB Operatorによってデプロイされた TiCDC クラスターをcdc cliコマンドを使用して操作できないのはなぜですか? {#why-cant-i-use-the-cdc-cli-command-to-operate-a-ticdc-cluster-deployed-by-tidb-operator} これは、 TiDB OperatorによってデプロイされたTiCDCクラスタのデフォルトポート番号が`8301`あるのに対し、TiCDCサーバーに接続するための`cdc cli`コマンドのデフォルトポート番号が`8300`であるためです。TiDB OperatorによってデプロイされたTiCDCクラスタを`cdc cli`コマンドで操作する場合は、以下のように`--server`パラメータを明示的に指定する必要があります。 @@ -468,7 +468,7 @@ TiDBにはトランザクションタイムアウト機構があります。ト > > 保存された生成列をKafkaまたはストレージサービスにレプリケーションし、その後MySQLに書き戻すと、 `Error 3105 (HY000): The value specified for generated column 'xx' in table 'xxx' is not allowed`発生する可能性があります。このエラーを回避するには、レプリケーションに[オープンプロトコル](/ticdc/ticdc-open-protocol.md#ticdc-open-protocol)使用します。このプロトコルの出力には[列のビットフラグ](/ticdc/ticdc-open-protocol.md#bit-flags-of-columns)含まれており、列が生成列かどうかを区別できます。 -## 頻繁に発生するCDC:ErrMySQLDuplicateEntryCDCエラーを解決するにはどうすればよいですか? {#how-do-i-resolve-frequent-code-cdc-errmysqlduplicateentrycdc-code-errors} +## 頻繁に発生するCDC:ErrMySQLDuplicateEntryCDCエラーを解決するにはどうすればよいですか? {#how-do-i-resolve-frequent-cdcerrmysqlduplicateentrycdc-errors} TiCDC を使用してデータを TiDB または MySQL に複製する場合、アップストリームの SQL ステートメントが特定のパターンで実行されると、次のエラーが発生する可能性があります。 @@ -510,7 +510,7 @@ UPDATE data_table SET value = 'v1' WHERE id = 2; セーフ モードでは、TiCDC は`UPDATE`操作を`DELETE + REPLACE INTO`に分割して実行し、一意のキーの競合エラーを回避します。 -## Kafka への TiCDC レプリケーション タスクがbroken pipeエラーで頻繁に失敗するのはなぜですか? {#why-do-ticdc-replication-tasks-to-kafka-often-fail-with-code-broken-pipe-code-errors} +## Kafka への TiCDC レプリケーション タスクがbroken pipeエラーで頻繁に失敗するのはなぜですか? {#why-do-ticdc-replication-tasks-to-kafka-often-fail-with-broken-pipe-errors} TiCDCはSaramaクライアントを使用してKafkaにデータを複製します。データの順序が乱れるのを防ぐため、TiCDCはSaramaの自動再試行メカニズムを無効化します（再試行回数を0に設定）。その結果、TiCDCとKafka間の接続が一定時間アイドル状態になった後にKafkaによって切断された場合、TiCDCからの後続の書き込みは`write: broken pipe`エラーをトリガーし、レプリケーションタスクが失敗します。 diff --git a/ticdc/ticdc-server-config.md b/ticdc/ticdc-server-config.md index 5164998dd9a4e..cce5307dd2048 100644 --- a/ticdc/ticdc-server-config.md +++ b/ticdc/ticdc-server-config.md @@ -7,7 +7,7 @@ summary: TiCDC で使用される CLI と構成パラメータについて学習 このドキュメントでは、TiCDC で使用される CLI および構成ファイルのパラメータについて説明します。 -## cdc server CLIパラメータ {#code-cdc-server-code-cli-parameters} +## cdc server CLIパラメータ {#cdc-server-cli-parameters} 以下は、 `cdc server`コマンドで使用できるオプションの説明です。 @@ -26,11 +26,11 @@ summary: TiCDC で使用される CLI と構成パラメータについて学習 - `tz` : TiCDC サービスが使用するタイムゾーン。TiCDC は、 `TIMESTAMP`などの時間データ型を内部的に変換するとき、またはデータをダウンストリームに複製するときに、このタイムゾーンを使用します。デフォルトは、プロセスが実行されるローカルタイムゾーンです。6 `sink-uri` `time-zone`パラメータは、 `mysql`と`tidb`シンクにのみ有効で、ダウンストリーム接続セッションのタイムゾーンを設定するために使用されることに注意してください。12 パラメータと`time-zone`パラメータの`tz`を指定する場合は、両方のパラメータで同じタイムゾーンを使用するようにしてください。これは、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} +## cdc server構成ファイルのパラメータ {#cdc-server-configuration-file-parameters} 以下は、コマンド`cdc server`の`config`オプションで指定される設定ファイルについて説明します。デフォルトの設定ファイルは[`pkg/cmd/util/ticdc.toml`](https://github.com/pingcap/tiflow/blob/master/pkg/cmd/util/ticdc.toml)にあります。 -### `newarch` v8.5.4-release.1 の新機能 {#newarch-new-in-v854-release-1} +### `newarch` v8.5.4-release.1 の新機能 {#newarch-new-in-v854-release1} - [TiCDCの新しいアーキテクチャ](/ticdc/ticdc-architecture.md)を有効にするかどうかを制御します。 - デフォルト値: `false` 、 [TiCDC クラシックアーキテクチャ](/ticdc/ticdc-classic-architecture.md)が使用されることを示します。 @@ -132,7 +132,7 @@ summary: TiCDC で使用される CLI と構成パラメータについて学習 - zapログモジュールの内部エラーログの出力場所を指定します。このパラメータはオプションです。 - デフォルト値: `"stderr"` -#### ログファイル {#log-file} +#### ログファイル {#logfile} ##### `max-size` {#max-size} diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index dda9e120d3ca8..094f1171dc7c2 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -542,7 +542,7 @@ Kafkaコンシューマーは、外部ストレージ内の大きなメッセー `key`と`value`フィールドは、Kafka メッセージ内の同名のフィールドに対応しています。コンシューマーは、これらの 2 つのフィールドのデータを解析することで、元の大きなメッセージを取得できます。オープンプロトコルでエンコードされた Kafka メッセージのみが、 `key`フィールドに有効なコンテンツを含みます。TiCDC は、 `key`と`value`両方を単一の JSON オブジェクトにエンコードして、完全なメッセージを一度に配信します。他のプロトコルでは、 `key`フィールドは常に空です。 -#### valueフィールドを外部ストレージにのみ送信する {#send-the-code-value-code-field-to-external-storage-only} +#### valueフィールドを外部ストレージにのみ送信する {#send-the-value-field-to-external-storage-only} バージョン8.4.0以降、TiCDCはKafkaメッセージの`value`フィールドのみを外部ストレージに送信できるようになりました。この機能は、Open Protocol以外のシナリオにのみ適用されます。この機能は、 `claim-check-raw-value`パラメータ（デフォルトは`false`を設定することで制御できます。 diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index 54172d86904a5..4ad6340e5143f 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -5,7 +5,7 @@ summary: TiCDC が UPDATE` イベントを分割するかどうかに関する # TiCDC の UPDATE イベントの分割動作 {#ticdc-behavior-in-splitting-update-events} -## MySQLシンクのUPDATEイベントを分割する {#split-code-update-code-events-for-mysql-sinks} +## MySQLシンクのUPDATEイベントを分割する {#split-update-events-for-mysql-sinks} v6.5.10、v7.1.6、v7.5.2、v8.1.1、v8.2.0以降では、MySQLシンクを使用する場合、テーブルのレプリケーション要求を受信したTiCDCノードは、下流へのレプリケーションを開始する前に、PDから現在のタイムスタンプ`thresholdTS`取得します。このタイムスタンプの値に基づいて、TiCDCは`UPDATE`イベントを分割するかどうかを決定します。 @@ -72,9 +72,9 @@ UPDATE t SET a = 3 WHERE a = 2; > > この動作変更後、MySQLシンクを使用する場合、TiCDCはほとんどの場合、 `UPDATE`イベントを分割しません。その結果、変更フィード実行時に主キーまたは一意キーの競合が発生し、変更フィードが自動的に再起動される可能性があります。再起動後、TiCDCは競合する`UPDATE`イベントを`DELETE`つと`INSERT`イベントに分割してから、Sorterモジュールに書き込みます。これにより、同一トランザクション内のすべてのイベントが正しく順序付けされ、 `DELETE`イベントすべてが`INSERT`イベントの前に配置されるため、データレプリケーションが正しく完了します。 -## MySQL以外のシンクの主キーまたは一意キーのUPDATEイベントを分割する {#split-primary-or-unique-key-code-update-code-events-for-non-mysql-sinks} +## MySQL以外のシンクの主キーまたは一意キーのUPDATEイベントを分割する {#split-primary-or-unique-key-update-events-for-non-mysql-sinks} -### 単一のUPDATE変更を含むトランザクション {#transactions-containing-a-single-code-update-code-change} +### 単一のUPDATE変更を含むトランザクション {#transactions-containing-a-single-update-change} v6.5.3、v7.1.1、v7.2.0以降、MySQL以外のシンクを使用する場合、単一の更新変更のみを含むトランザクションにおいて、主キーまたはnull以外の一意インデックス値が`UPDATE`イベントで変更されると、TiCDCはこのイベントを`DELETE`つと`INSERT`イベントに分割します。詳細については、GitHubのissue [＃9086](https://github.com/pingcap/tiflow/issues/9086)ご覧ください。 @@ -88,7 +88,7 @@ UPDATE t SET a = 2 WHERE a = 1; この例では、主キー`a`が`1`から`2`に更新されます。イベント`UPDATE`が分割されていない場合、CSV プロトコルおよび AVRO プロトコルを使用する場合、コンシューマーは新しい値`a = 2`のみを取得でき、古い値`a = 1`取得できません。そのため、下流のコンシューマーは古い値`1`を削除せずに、新しい値`2`のみを挿入する可能性があります。 -### 複数のUPDATE変更を含むトランザクション {#transactions-containing-multiple-code-update-code-changes} +### 複数のUPDATE変更を含むトランザクション {#transactions-containing-multiple-update-changes} v6.5.4、v7.1.2、v7.4.0以降、複数の変更を含むトランザクションにおいて、 `UPDATE`イベントで主キーまたはNULL以外の一意インデックス値が変更された場合、TiCDCはイベントを`DELETE`と`INSERT`イベントに分割し、すべてのイベントが`INSERT`のイベントの前の`DELETE`のイベントのシーケンスに従うようにします。詳細については、GitHubのissue [＃9430](https://github.com/pingcap/tiflow/issues/9430)ご覧ください。 @@ -112,7 +112,7 @@ COMMIT; したがって、TiCDC はこれら 2 つのイベントを 4 つのイベントに分割します。つまり、レコード`(1, 1)`と`(2, 2)`削除し、レコード`(2, 1)`と`(1, 2)`書き込みます。 -### 主キーまたは一意キーのUPDATEイベントを分割するかどうかを制御する {#control-whether-to-split-primary-or-unique-key-code-update-code-events} +### 主キーまたは一意キーのUPDATEイベントを分割するかどうかを制御する {#control-whether-to-split-primary-or-unique-key-update-events} v6.5.10、v7.1.6、v7.5.3、v8.1.1以降、MySQL以外のシンクを使用する場合、TiCDCはGitHub Issue [＃11211](https://github.com/pingcap/tiflow/issues/11211)に記載されているように、 `output-raw-change-event`パラメータを介して主キーまたは一意キーの`UPDATE`イベントを分割するかどうかを制御できるようになりました。このパラメータの具体的な動作は次のとおりです。 @@ -123,7 +123,7 @@ v6.5.10、v7.1.6、v7.5.3、v8.1.1以降、MySQL以外のシンクを使用す > > 次の表では、UK/PK は主キーまたは一意キーを表します。 -#### リリース6.5の互換性 {#release-6-5-compatibility} +#### リリース6.5の互換性 {#release-65-compatibility} | バージョン | プロトコル | UK/PK `UPDATE`イベントの分割 | UK/ `UPDATE`イベントを分割しない | コメント | | --------------- | ------- | ---------------------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------- | @@ -134,7 +134,7 @@ v6.5.10、v7.1.6、v7.5.3、v8.1.1以降、MySQL以外のシンクを使用す | v6.5.5 ～ v6.5.9 | 全て | ✓ | ✗ | | | = v6.5.10 | 全て | ✓ (デフォルト値: `output-raw-change-event = false` ) | ✓ （オプション： `output-raw-change-event = true` ） | | -#### リリース7.1の互換性 {#release-7-1-compatibility} +#### リリース7.1の互換性 {#release-71-compatibility} | バージョン | プロトコル | UK/PK `UPDATE`イベントの分割 | UK/ `UPDATE`イベントを分割しない | コメント | | --------------- | ------- | ---------------------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------- | @@ -144,14 +144,14 @@ v6.5.10、v7.1.6、v7.5.3、v8.1.1以降、MySQL以外のシンクを使用す | v7.1.2 ~ v7.1.5 | 全て | ✓ | ✗ | | | = v7.1.6 | 全て | ✓ (デフォルト値: `output-raw-change-event = false` ) | ✓ （オプション： `output-raw-change-event = true` ） | | -#### リリース7.5の互換性 {#release-7-5-compatibility} +#### リリース7.5の互換性 {#release-75-compatibility} | バージョン | プロトコル | UK/PK `UPDATE`イベントの分割 | UK/ `UPDATE`イベントを分割しない | コメント | | ------------ | ----- | ---------------------------------------------- | -------------------------------------------- | ---- | | バージョン7.5.2以下 | 全て | ✓ | ✗ | | | = v7.5.3 | 全て | ✓ (デフォルト値: `output-raw-change-event = false` ) | ✓ （オプション： `output-raw-change-event = true` ） | | -#### リリース8.1の互換性 {#release-8-1-compatibility} +#### リリース8.1の互換性 {#release-81-compatibility} | バージョン | プロトコル | UK/PK `UPDATE`イベントの分割 | UK/ `UPDATE`イベントを分割しない | コメント | | ---------- | ----- | ---------------------------------------------- | -------------------------------------------- | ---- | diff --git a/ticdc/ticdc-upstream-downstream-check.md b/ticdc/ticdc-upstream-downstream-check.md index 51e43ce76f521..417aec7ab48b4 100644 --- a/ticdc/ticdc-upstream-downstream-check.md +++ b/ticdc/ticdc-upstream-downstream-check.md @@ -49,7 +49,7 @@ sync-point-retention = "1h" アップストリーム クラスターとダウンストリーム クラスターのデータを検証するには、sync-diff-inspector で`snapshot`設定するだけです。 -### ステップ1: ts-mapを取得する {#step-1-obtain-code-ts-map-code} +### ステップ1: ts-mapを取得する {#step-1-obtain-ts-map} 下流TiDBクラスタで次のSQL文を実行すると、上流TSO（ `primary_ts` ）と下流TSO（ `secondary_ts` ）を取得できます。 diff --git a/tidb-cloud/backup-and-restore-serverless.md b/tidb-cloud/backup-and-restore-serverless.md index f9ff43f33349d..7f7860e1e8195 100644 --- a/tidb-cloud/backup-and-restore-serverless.md +++ b/tidb-cloud/backup-and-restore-serverless.md @@ -4,7 +4,7 @@ summary: TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスのバ aliases: ['/ja/tidbcloud/restore-deleted-tidb-cluster'] --- -# TiDB Cloud StarterまたはEssentialデータのバックアップと復元 {#back-up-and-restore-tidb-cloud-starter-or-essential-data} +# TiDB Cloud StarterまたはEssentialデータのバックアップと復元 {#back-up-and-restore--starter--or-essential-data} このドキュメントでは、TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンス上のデータのバックアップと復元方法について説明します。 diff --git a/tidb-cloud/branch-github-integration.md b/tidb-cloud/branch-github-integration.md index b9132c712d6c1..9f3132905d78c 100644 --- a/tidb-cloud/branch-github-integration.md +++ b/tidb-cloud/branch-github-integration.md @@ -3,7 +3,7 @@ title: Integrate TiDB Cloud Branching (PREVIEW) with GitHub summary: TiDB Cloudのブランチ機能をGitHubと連携させる方法を学びましょう。 --- -# TiDB Cloud Branching（PREVIEW）とGitHubの統合 {#integrate-tidb-cloud-branching-beta-with-github} +# TiDB Cloud Branching（PREVIEW）とGitHubの統合 {#integrate-tidb-cloud-branching-preview-with-github} > **Note:** > @@ -67,7 +67,7 @@ TiDB Cloud Starterインスタンスを GitHub リポジトリに接続すると [TiDB Cloud Branching](https://github.com/apps/tidb-cloud-branching)の動作を設定するには リポジトリのルートディレクトリに`tidbcloud.yml`ファイルを追加し、以下の手順に従って必要な設定をこのファイルに追加します。 -### branch.blockList {#branch-blocklist} +### branch.blockList {#branchblocklist} **型:**文字列の配列。**デフォルト:** `[]` 。 @@ -81,7 +81,7 @@ github: - ".*_blackList" ``` -### branch.allowList {#branch-allowlist} +### branch.allowList {#branchallowlist} **型:**文字列の配列。**デフォルト:** `[.*]` 。 @@ -94,7 +94,7 @@ github: - ".*_db" ``` -### branch.mode {#branch-mode} +### branch.mode {#branchmode} **型:**文字列。**デフォルト:** `reset` 。 @@ -109,7 +109,7 @@ github: mode: reset ``` -### branch.autoDestroy {#branch-autodestroy} +### branch.autoDestroy {#branchautodestroy} **型:**ブール値。**デフォルト:** `true` 。 @@ -127,7 +127,7 @@ github: ワークフローを作成するための主な手順は以下のとおりです。 -1. [TiDB Cloud BranchingをGitHubリポジトリと統合する](#integrate-branching-with-your-github-repository)。 +1. [TiDB Cloud BranchingをGitHubリポジトリと統合する](#integrate-tidb-cloud-branching-with-your-github-repository)。 2. 支店の接続情報を取得します。 @@ -159,7 +159,7 @@ github: テストコードを修正して、GitHub Actions からの接続情報を受け入れるようにしてください。たとえば、 [ライブデモ](https://github.com/shiyuhang0/tidbcloud-branch-gorm-example)で示されているように、環境を介して接続情報を受け入れることができます。 -## 次は？ {#what-s-next} +## 次は？ {#whats-next} 以下の例を通して、ブランチング機能を備えたGitHub連携の使い方を学びましょう。 diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md index 0730e04f4bfac..ec4b6f50e76a0 100644 --- a/tidb-cloud/migrate-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md @@ -332,7 +332,7 @@ TiDB Cloud Premiumで利用可能な接続方法は以下のとおりです。 ご利用のクラウドプロバイダー、ネットワーク構成、およびセキュリティ要件に最適な接続方法を選択し、その方法の設定手順に従ってください。 -#### TLS/SSLによるエンドツーエンド暗号化 {#end-to-end-encryption-over-tls-ssl} +#### TLS/SSLによるエンドツーエンド暗号化 {#end-to-end-encryption-over-tlsssl} 接続方法に関わらず、エンドツーエンド暗号化にはTLS/SSLの使用を強く推奨します。プライベートエンドポイントおよびVPCピアリングネットワークパスを保護しますが、TLS/SSLはデータ自体を保護し、コンプライアンス要件を満たすのに役立ちます。 @@ -956,7 +956,7 @@ TiDB Cloud Dedicatedは、さまざまなシナリオにおけるパフォーマ - 移行ジョブの仕様を拡張するには、約5～10分かかります。 - スケーリングが失敗した場合、ジョブの仕様はスケーリング前と同じままになります。 -### 制限事項 {#limitations} +### 制限事項 {#limitations-1} - 移行ジョブの仕様をスケーリングできるのは、ジョブが**「実行中」**または**「一時停止中」の**状態にある場合のみです。 - TiDB Cloudは、既存のデータエクスポート段階における移行ジョブ仕様のスケーリングをサポートしていません。 diff --git a/tidb-cloud/monitor-prometheus-and-grafana-integration.md b/tidb-cloud/monitor-prometheus-and-grafana-integration.md index e364097d76dd4..61c75d6d14bcf 100644 --- a/tidb-cloud/monitor-prometheus-and-grafana-integration.md +++ b/tidb-cloud/monitor-prometheus-and-grafana-integration.md @@ -34,7 +34,7 @@ TiDB Cloudは、2022年3月15日よりプロジェクトレベルのPrometheus ## 手順 {#steps} -### ステップ1. Prometheus用のscrape_configファイルを取得する {#step-1-get-a-scrape-config-file-for-prometheus} +### ステップ1. Prometheus用のscrape_configファイルを取得する {#step-1-get-a-scrape_config-file-for-prometheus} Prometheus サービスでTiDB Cloudのメトリクスを読み取るように設定する前に、まずTiDB Cloudで`scrape_config` YAML ファイルを生成する必要があります。 `scrape_config`ファイルには、Prometheus サービスが対象のTiDB Cloud Dedicatedクラスターを監視できるようにする一意のベアラー トークンが含まれています。 @@ -95,7 +95,7 @@ PrometheusサービスがTiDB Cloudからメトリクスを読み取るように Grafana の使用方法の詳細については、 [Grafanaのドキュメント](https://grafana.com/docs/grafana/latest/getting-started/getting-started-prometheus/)を参照してください。 -## scrape_configをローテーションするベストプラクティス {#best-practice-of-rotating-scrape-config} +## scrape_configをローテーションするベストプラクティス {#best-practice-of-rotating-scrape_config} データセキュリティを向上させるために、 `scrape_config`ファイルベアラートークンを定期的にローテーションすることが一般的なベストプラクティスです。 diff --git a/tidb-cloud/prometheus-grafana-integration.md b/tidb-cloud/prometheus-grafana-integration.md index 7eec243d6b66d..1e0c343320e75 100644 --- a/tidb-cloud/prometheus-grafana-integration.md +++ b/tidb-cloud/prometheus-grafana-integration.md @@ -22,7 +22,7 @@ TiDB Cloudは[Prometheus](https://prometheus.io/)APIエンドポイントを提 ## 手順 {#steps} -### ステップ1. Prometheus用のscrape_configファイルを取得する {#step-1-get-a-code-scrape-config-code-file-for-prometheus} +### ステップ1. Prometheus用のscrape_configファイルを取得する {#step-1-get-a-scrape_config-file-for-prometheus} Prometheus サービスでTiDB Cloudのメトリクスを読み取るように設定する前に、まずTiDB Cloudで`scrape_config` YAML ファイルを生成する必要があります。 `scrape_config`ファイルには、Prometheus サービスが対象のTiDB Cloud Essential TiDB Cloud Premiumインスタンスを監視できるようにする一意のベアラー トークンが含まれています。 @@ -86,7 +86,7 @@ PrometheusサービスがTiDB Cloudからメトリクスを読み取った後、 Grafana の使用方法の詳細については、 [Grafanaのドキュメント](https://grafana.com/docs/grafana/latest/getting-started/getting-started-prometheus/)を参照してください。 -## scrape_configをローテーションするためのベストプラクティス {#best-practice-for-rotating-code-scrape-config-code} +## scrape_configをローテーションするためのベストプラクティス {#best-practice-for-rotating-scrape_config} データセキュリティを向上させるため、 `scrape_config`ファイルベアラートークンを定期的にローテーションしてください。 diff --git a/tidb-cloud/terraform-migrate-cluster-resource.md b/tidb-cloud/terraform-migrate-cluster-resource.md index d6654a4ca8fd2..46fb25b8dc602 100644 --- a/tidb-cloud/terraform-migrate-cluster-resource.md +++ b/tidb-cloud/terraform-migrate-cluster-resource.md @@ -15,7 +15,7 @@ TiDB Cloud Terraform Provider v0.4.0 以降では、 `tidbcloud_cluster`リソ - [TiDB Cloud Terraform プロバイダー v0.4.0 以降](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest)にアップグレード -## ステップ1. 移行するtidbcloud_clusterリソースを特定する {#step-1-identify-the-code-tidbcloud-cluster-code-resource-to-migrate} +## ステップ1. 移行するtidbcloud_clusterリソースを特定する {#step-1-identify-the-tidbcloud_cluster-resource-to-migrate} 1. すべての`tidbcloud_cluster`リソースを一覧表示します: diff --git a/tidb-cloud/terraform-use-cluster-resource.md b/tidb-cloud/terraform-use-cluster-resource.md index 010b5bbaf1357..16f8a80f3c3b2 100644 --- a/tidb-cloud/terraform-use-cluster-resource.md +++ b/tidb-cloud/terraform-use-cluster-resource.md @@ -3,7 +3,7 @@ title: Use the `tidbcloud_cluster` Resource (Deprecated) summary: クラスター リソースを使用してTiDB Cloudクラスターを作成および変更する方法を学習します。 --- -# tidbcloud_clusterリソースを使用する（非推奨） {#use-the-code-tidbcloud-cluster-code-resource-deprecated} +# tidbcloud_clusterリソースを使用する（非推奨） {#use-the-tidbcloud_cluster-resource-deprecated} > **Warning:** > @@ -23,7 +23,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを - [TiDB Cloud Terraform プロバイダーを入手する](/tidb-cloud/terraform-get-tidbcloud-provider.md) 。 -## tidbcloud_projectsデータソースを使用してプロジェクト ID を取得する {#get-project-ids-using-the-code-tidbcloud-projects-code-data-source} +## tidbcloud_projectsデータソースを使用してプロジェクト ID を取得する {#get-project-ids-using-the-tidbcloud_projects-data-source} 各 TiDB クラスターはプロジェクトに属します。TiDB クラスターを作成する前に、クラスターを作成するプロジェクトの ID を取得する必要があります。 @@ -119,7 +119,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを これで、出力から利用可能なすべてのプロジェクトを取得できます。必要なプロジェクトIDを1つコピーしてください。 -## tidbcloud_cluster_specsデータソースを使用してクラスター仕様情報を取得する {#get-cluster-specification-information-using-the-code-tidbcloud-cluster-specs-code-data-source} +## tidbcloud_cluster_specsデータソースを使用してクラスター仕様情報を取得する {#get-cluster-specification-information-using-the-tidbcloud_cluster_specs-data-source} クラスターを作成する前に、使用可能なすべての構成値 (サポートされているクラウド プロバイダー、リージョン、ノード サイズなど) が含まれるクラスター仕様情報を取得する必要があります。 diff --git a/tidb-cloud/tidb-cloud-clinic.md b/tidb-cloud/tidb-cloud-clinic.md index ca503384c9c52..1a850d268267f 100644 --- a/tidb-cloud/tidb-cloud-clinic.md +++ b/tidb-cloud/tidb-cloud-clinic.md @@ -91,7 +91,7 @@ TiDB Cloudコンソールのデフォルトの[**スロークエリ**](/tidb-clo 詳細については[TiDB Dashboardのスロークエリ](https://docs.pingcap.com/tidb/stable/dashboard-slow-query)参照してください。 -## TopSQLを監視する {#monitor-topsql} +## TopSQLを監視する {#monitor-top-sql} TiDB Cloud ClinicはTopSQL情報を提供し、データベース内の各SQL文のCPUオーバーヘッドをリアルタイムで監視し、視覚的に調査することができます。これにより、データベースのパフォーマンスに関する問題の最適化と解決に役立ちます。 diff --git a/tidb-cloud/tidb-cloud-org-sso-authentication.md b/tidb-cloud/tidb-cloud-org-sso-authentication.md index ffe55afb1ad81..31a3533cfdfc3 100644 --- a/tidb-cloud/tidb-cloud-org-sso-authentication.md +++ b/tidb-cloud/tidb-cloud-org-sso-authentication.md @@ -123,7 +123,7 @@ Cloud Organization SSO を有効にした後、次のようにユーザー名と 4. **［保存］**をクリックします。 -### OIDC と SAML のドメインを追加して検証する +### OIDC と SAML のドメインを追加して検証する {#add-and-verify-domains-for-oidc-and-saml} OIDC または SAML で **Auto-provision Accounts** を有効にする場合、または SAML で **SCIM Provisioning Accounts** を有効にする場合は、組織メンバーがサインインに使用するメールドメインを追加して検証してください。これらの場合、 **Allowed Email Domains** は必須であり、 **Verified** ステータスのドメインのみ使用できます。 diff --git a/tidb-cloud/use-chat2query-api.md b/tidb-cloud/use-chat2query-api.md index ddad2ea0241aa..f1482bb2f4409 100644 --- a/tidb-cloud/use-chat2query-api.md +++ b/tidb-cloud/use-chat2query-api.md @@ -135,7 +135,7 @@ TiDB Cloudデータ サービスは、次の Chat2Query v3 エンドポイント `/v3/chat2data`と`/v2/chat2data`呼び出す手順は同じです。以下のセクションでは、 `/v3/chat2data`例に挙げてその呼び出し方法を説明します。 -#### 1. /v3/dataSummariesを呼び出してデータサマリーを生成する {#1-generate-a-data-summary-by-calling-code-v3-datasummaries-code} +#### 1. /v3/dataSummariesを呼び出してデータサマリーを生成する {#1-generate-a-data-summary-by-calling-v3datasummaries} `/v3/chat2data`呼び出す前に、まず`/v3/dataSummaries`呼び出して AI にデータベースを分析してデータの概要を生成させます。そうすることで、後で`/v3/chat2data` SQL 生成でより優れたパフォーマンスを得ることができます。 @@ -172,7 +172,7 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https:///v2/jobs/{job_id}を呼び出して分析ステータスを確認します。 {#2-check-the-analysis-status-by-calling-code-v2-jobs-job-id-code} +#### 2. /v2/jobs/{job_id}を呼び出して分析ステータスを確認します。 {#2-check-the-analysis-status-by-calling-v2jobsjob_id} `/v3/dataSummaries` APIは非同期です。大規模なデータセットを持つデータベースの場合、データベース分析を完了して完全なデータサマリーを返すまでに数分かかる場合があります。 @@ -238,7 +238,7 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request GET 'https:///v3/chat2dataを呼び出してSQL文を生成し実行する {#3-generate-and-execute-sql-statements-by-calling-code-v3-chat2data-code} +#### 3. /v3/chat2dataを呼び出してSQL文を生成し実行する {#3-generate-and-execute-sql-statements-by-calling-v3chat2data} データベースのデータ概要が準備できたら、クラスター ID、データベース名、質問を指定して`/v3/chat2data`呼び出して SQL ステートメントを生成および実行できます。 diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index f5b5bb1720c03..8381d02725f28 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -139,7 +139,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - デフォルト値: [] - リストはデフォルトでは空です。これは、修復が必要な不良テーブルが存在しないことを意味します。 -### `new_collations_enabled_on_first_bootstrap` {#new-collations-enabled-on-first-bootstrap} +### `new_collations_enabled_on_first_bootstrap` {#new_collations_enabled_on_first_bootstrap} - 新しい照合順序のサポートを有効または無効にします。 - デフォルト値: `true` @@ -351,7 +351,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - 単位：秒 - 一部のユーザーシナリオでは、TiDBログがホットプラグ対応ディスクまたはネットワーク接続ディスクに保存されることがありますが、これらのディスクが永久的に使用不能になる可能性があります。このような場合、TiDBは自動的に復旧できず、ログ書き込み操作は永久的にブロックされます。TiDBプロセスは実行されているように見えても、実際にはどの要求にも応答しません。この設定項目は、このような状況に対処するために設計されています。 -### log.file {#log-file} +### log.file {#logfile} ログファイルに関連するコンフィグレーション項目。 @@ -658,7 +658,7 @@ OpenTracingに関連するコンフィグレーション項目。 - RPCメトリクスを有効にします。 - デフォルト値: `false` -### opentracing.sampler {#opentracing-sampler} +### opentracing.sampler {#opentracingsampler} opentracing.sampler に関連するコンフィグレーション項目。 @@ -692,7 +692,7 @@ opentracing.sampler に関連するコンフィグレーション項目。 - jaeger-agentのサンプリングポリシーをポーリングする頻度を制御します。 - デフォルト値: `0` -### opentracing.reporter {#opentracing-reporter} +### opentracing.reporter {#opentracingreporter} opentracing.reporter に関連するコンフィグレーション項目。 @@ -812,7 +812,7 @@ opentracing.reporter に関連するコンフィグレーション項目。 - TiKVにRPCリクエストを送信する際に、リージョンレプリカセレクターの新しいバージョンを使用するかどうか。 - デフォルト値: `true` -### tikv-client.copr-cache v4.0.0 の新機能 {#tikv-client-copr-cache-new-in-v400} +### tikv-client.copr-cache v4.0.0 の新機能 {#tikv-clientcopr-cache-new-in-v400} [コプロセッサーキャッシュ](/coprocessor-cache.md)キャッシュ機能に関する設定項目を紹介します。 @@ -903,20 +903,20 @@ TiDBサービスの状態に関するコンフィグレーション。 ## instance {#instance} -### `tidb_enable_collect_execution_info` {#tidb-enable-collect-execution-info} +### `tidb_enable_collect_execution_info` {#tidb_enable_collect_execution_info} - この設定では、各オペレーターの実行情報をスロークエリログに記録するかどうか、および[インデックスの使用統計](/information-schema/information-schema-tidb-index-usage.md)を記録するかどうかを制御します。 - デフォルト値: `true` - v6.1.0より前は、この設定は`enable-collect-execution-info`によって設定されます。 -### `tidb_enable_slow_log` {#tidb-enable-slow-log} +### `tidb_enable_slow_log` {#tidb_enable_slow_log} - この設定は、スローログ機能を有効にするかどうかを制御するために使用されます。 - デフォルト値: `true` - 値のオプション: `true`または`false` - v6.1.0より前は、この設定は`enable-slow-log`によって設定されます。 -### `tidb_slow_log_threshold` {#tidb-slow-log-threshold} +### `tidb_slow_log_threshold` {#tidb_slow_log_threshold} - スローログが消費する時間のしきい値を出力します。 - デフォルト値: `300` @@ -935,7 +935,7 @@ TiDBサービスの状態に関するコンフィグレーション。 - この設定は、最近使用されたスロークエリのうち、メモリにキャッシュされるクエリの数を制御します。 - デフォルト値: 500 -### `tidb_expensive_query_time_threshold` {#tidb-expensive-query-time-threshold} +### `tidb_expensive_query_time_threshold` {#tidb_expensive_query_time_threshold} - この設定は、高負荷なクエリログを出力するかどうかを決定するしきい値を設定するために使用されます。高負荷なクエリログと低負荷なクエリログの違いは次のとおりです。 - スローログは、ステートメントの実行後に出力されます。 @@ -945,7 +945,7 @@ TiDBサービスの状態に関するコンフィグレーション。 - 単位：秒 - v5.4.0より前は、この設定は`expensive-threshold`によって設定されます。 -### `tidb_record_plan_in_slow_log` {#tidb-record-plan-in-slow-log} +### `tidb_record_plan_in_slow_log` {#tidb_record_plan_in_slow_log} - この設定は、スロークエリの実行プランをスローログに含めるかどうかを制御するために使用されます。 - デフォルト値: `1` @@ -953,7 +953,7 @@ TiDBサービスの状態に関するコンフィグレーション。 - この設定値は、システム変数[`tidb_record_plan_in_slow_log`](/system-variables.md#tidb_record_plan_in_slow_log)の値を初期化します。 - v6.1.0より前は、この設定は`record-plan-in-slow-log`によって設定されます。 -### `tidb_force_priority` {#tidb-force-priority} +### `tidb_force_priority` {#tidb_force_priority} - この設定は、TiDBサーバー上で実行されるステートメントのデフォルトの優先度を変更するために使用されます。 - デフォルト値: `NO_PRIORITY` @@ -964,7 +964,7 @@ TiDBサービスの状態に関するコンフィグレーション。 > > バージョン6.6.0以降、TiDBは[リソース制御](/tidb-resource-control-ru-groups.md)サポートしています。この機能を使用すると、異なるリソースグループで異なる優先度のSQLステートメントを実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、異なる優先度のSQLステートメントのスケジューリングをより適切に制御できます。リソース制御が有効になっている場合、ステートメントの優先度は適用されなくなります。 を使用して[リソース制御](/tidb-resource-control-ru-groups.md)異なるSQLステートメントのリソース使用量を管理することをお勧めします。 -### `max_connections` {#max-connections} +### `max_connections` {#max_connections} - 単一のTiDBインスタンスで許可される最大接続数。リソース制御に使用できます。 - デフォルト値: `0` @@ -973,7 +973,7 @@ TiDBサービスの状態に関するコンフィグレーション。 - この設定値は、システム変数[`max_connections`](/system-variables.md#max_connections)の値を初期化します。 - v6.2.0より前は、この設定は`max-server-connections`によって設定されます。 -### `tidb_enable_ddl` {#tidb-enable-ddl} +### `tidb_enable_ddl` {#tidb_enable_ddl} - この設定により、対応するTiDBインスタンスがDDLの所有者になれるかどうかを制御します。 - デフォルト値: `true` @@ -981,14 +981,14 @@ TiDBサービスの状態に関するコンフィグレーション。 - この設定値は、システム変数[`tidb_enable_ddl`](/system-variables.md#tidb_enable_ddl-new-in-v630)の値を初期化します。 - v6.3.0より前は、この設定は`run-ddl`によって設定されます。 -### `tidb_enable_stats_owner` v8.4.0 で追加されました。 {#tidb-enable-stats-owner-new-in-v840} +### `tidb_enable_stats_owner` v8.4.0 で追加されました。 {#tidb_enable_stats_owner-new-in-v840} - この構成は、対応する TiDB インスタンスが[統計情報の自動更新](/statistics.md#automatic-update)タスクを実行できるかどうかを制御します。 - デフォルト値: `true` - 指定可能な値: `true` 、 `false` - この設定値は、システム変数[`tidb_enable_stats_owner`](/system-variables.md#tidb_enable_stats_owner-new-in-v840)の値を初期化します。 -### `tidb_stmt_summary_enable_persistent` v6.6.0で追加 {#tidb-stmt-summary-enable-persistent-new-in-v660} +### `tidb_stmt_summary_enable_persistent` v6.6.0で追加 {#tidb_stmt_summary_enable_persistent-new-in-v660} > **Warning:** > @@ -998,7 +998,7 @@ TiDBサービスの状態に関するコンフィグレーション。 - デフォルト値: `false` - 詳細については、 [持続ステートメントの概要](/statement-summary-tables.md#persist-statements-summary)ご覧ください。 -### `tidb_stmt_summary_filename` v6.6.0で追加 {#tidb-stmt-summary-filename-new-in-v660} +### `tidb_stmt_summary_filename` v6.6.0で追加 {#tidb_stmt_summary_filename-new-in-v660} > **Warning:** > @@ -1007,7 +1007,7 @@ TiDBサービスの状態に関するコンフィグレーション。 - 明細書の要約データの永続化が有効になっている場合、この設定では永続データが書き込まれるファイルを指定します。 - デフォルト値: `tidb-statements.log` -### `tidb_stmt_summary_file_max_days` v6.6.0 で追加されました。 {#tidb-stmt-summary-file-max-days-new-in-v660} +### `tidb_stmt_summary_file_max_days` v6.6.0 で追加されました。 {#tidb_stmt_summary_file_max_days-new-in-v660} > **Warning:** > @@ -1018,7 +1018,7 @@ TiDBサービスの状態に関するコンフィグレーション。 - 単位：日 - データ保持要件とディスク容量の使用状況に基づいて値を調整できます。 -### `tidb_stmt_summary_file_max_size` v6.6.0 で追加されました。 {#tidb-stmt-summary-file-max-size-new-in-v660} +### `tidb_stmt_summary_file_max_size` v6.6.0 で追加されました。 {#tidb_stmt_summary_file_max_size-new-in-v660} > **Warning:** > @@ -1029,7 +1029,7 @@ TiDBサービスの状態に関するコンフィグレーション。 - 単位: MiB - データ保持要件とディスク容量の使用状況に基づいて値を調整できます。 -### `tidb_stmt_summary_file_max_backups` v6.6.0で追加 {#tidb-stmt-summary-file-max-backups-new-in-v660} +### `tidb_stmt_summary_file_max_backups` v6.6.0で追加 {#tidb_stmt_summary_file_max_backups-new-in-v660} > **Warning:** > diff --git a/tidb-control.md b/tidb-control.md index 0ff921d40b43d..e834ad0ef6e31 100644 --- a/tidb-control.md +++ b/tidb-control.md @@ -88,9 +88,9 @@ TiDBコントロールは複数のコマンド層で構成されています。 - TiDB のデフォルトのサービス ポート: `10080` 。 - PD のデフォルトのサービス ポート: `2379` 。 -### schemaコマンド {#the-code-schema-code-command} +### schemaコマンド {#the-schema-command} -#### inサブコマンド {#the-code-in-code-subcommand} +#### inサブコマンド {#the-in-subcommand} `in` 、データベース名を通じてデータベース内のすべてのテーブルのテーブル スキーマを取得するために使用されます。 @@ -138,7 +138,7 @@ tidb-ctl schema in デフォルトのTiDBサービスアドレスとポートを使用しない場合は、 `--host`と`--port`オプションを使用して設定します。例： `tidb-ctl --host 172.16.55.88 --port 8898 schema in mysql -n db` 。 -#### tidサブコマンド {#the-code-tid-code-subcommand} +#### tidサブコマンド {#the-tid-subcommand} `tid` 、データベース全体で一意の`table_id`を使用してテーブルスキーマを取得するために使用されます。4 `in`コマンドを使用して特定のスキーマのすべてのテーブルIDを取得し、 `tid`サブコマンドを使用して詳細なテーブル情報を取得できます。 @@ -159,7 +159,7 @@ tidb-ctl schema in `in`サブコマンドと同様に、デフォルトの TiDB サービス アドレスとステータス ポートを使用しない場合は、 `--host`および`--port`オプションを使用してホストとポートを指定します。 -#### base64decodeコマンド {#the-code-base64decode-code-command} +#### base64decodeコマンド {#the-base64decode-command} `base64decode` `base64`データをデコードするために使用されます。 @@ -235,7 +235,7 @@ tidb-ctl base64decode [table_id] [base64_data] e not found in data ``` -### decoderコマンド {#the-code-decoder-code-command} +### decoderコマンド {#the-decoder-command} - 次の例は、インデックス キーのデコードと同様に、行キーをデコードする方法を示しています。 @@ -255,7 +255,7 @@ tidb-ctl base64decode [table_id] [base64_data] index_value[1]: {type: bigint, value: 1024} ``` -### etcdコマンド {#the-code-etcd-code-command} +### etcdコマンド {#the-etcd-command} - `tidb-ctl etcd ddlinfo` DDL 情報を取得するために使用されます。 @@ -274,11 +274,11 @@ tidb-ctl base64decode [table_id] [base64_data] tidb-ctl etcd delkey "/tidb/ddl/all_schema_versions/bar" ``` -### logコマンド {#the-code-log-code-command} +### logコマンド {#the-log-command} TiDBエラーログのスタック情報は1行形式です。1 `tidb-ctl log`指定すると、複数行形式に変更できます。 -### keyrangeコマンド {#the-code-keyrange-code-command} +### keyrangeコマンド {#the-keyrange-command} `keyrange`サブコマンドは、16 進形式で出力されるグローバルまたはテーブル関連のキー範囲情報を照会するために使用されます。 diff --git a/tidb-lightning/tidb-lightning-checkpoints.md b/tidb-lightning/tidb-lightning-checkpoints.md index 11df08558937d..5360569414c9e 100644 --- a/tidb-lightning/tidb-lightning-checkpoints.md +++ b/tidb-lightning/tidb-lightning-checkpoints.md @@ -59,7 +59,7 @@ Lightning は、ターゲットデータベースをチェックポイントのs `tidb-lightning`回復不能なエラー（データ破損など）により異常終了した場合、エラーが解決されるまでチェックポイントの再利用を拒否します。これは状況の悪化を防ぐためです。チェックポイントエラーは`tidb-lightning-ctl`プログラムを使用して解決できます。 -### `--checkpoint-error-destroy` {#checkpoint-error-destroy} +### `--checkpoint-error-destroy` {#--checkpoint-error-destroy} ```sh tidb-lightning-ctl --checkpoint-error-destroy='`schema`.`table`' @@ -80,7 +80,7 @@ tidb-lightning-ctl --checkpoint-error-destroy='`schema`.`table`' tidb-lightning-ctl --checkpoint-error-destroy=all ``` -### `--checkpoint-error-ignore` {#checkpoint-error-ignore} +### `--checkpoint-error-ignore` {#--checkpoint-error-ignore} ```sh tidb-lightning-ctl --checkpoint-error-ignore='`schema`.`table`' @@ -93,7 +93,7 @@ tidb-lightning-ctl --checkpoint-error-ignore=all > > このオプションは、エラーが実際に無視できると確信できる場合にのみ使用してください。そうでない場合、インポートされたデータの一部が失われる可能性があります。唯一の安全策は最終的な「チェックサム」チェックであるため、 `--checkpoint-error-ignore`使用する場合は常に「チェックサム」オプションを有効にする必要があります。 -### `--checkpoint-remove` {#checkpoint-remove} +### `--checkpoint-remove` {#--checkpoint-remove} ```sh tidb-lightning-ctl --checkpoint-remove='`schema`.`table`' @@ -102,7 +102,7 @@ tidb-lightning-ctl --checkpoint-remove=all このオプションは、ステータスに関係なく、1 つのテーブルまたはすべてのテーブルに関するすべてのチェックポイント情報を削除します。 -### `--checkpoint-dump` {#checkpoint-dump} +### `--checkpoint-dump` {#--checkpoint-dump} ```sh tidb-lightning-ctl --checkpoint-dump=output/directory diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index b09dda71f886f..c78cba25ae012 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -11,7 +11,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 ## TiDB Lightning （グローバル） {#tidb-lightning-global} -### TiDB Lightning {#lightning} +### TiDB Lightning {#lightning-1} #### `status-addr` {#status-addr} @@ -116,19 +116,19 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 `security`セクションでは、クラスター内の TLS 接続の証明書とキーを指定します。 -#### `ca-path` {#ca-path} +#### `ca-path` {#ca-path-1} - CAの公開証明書を指定します。TLSを無効にする場合は空白のままにしてください。 -#### `cert-path` {#cert-path} +#### `cert-path` {#cert-path-1} - このサービスの公開証明書を指定します。 -#### `key-path` {#key-path} +#### `key-path` {#key-path-1} - このサービスの秘密鍵を指定します。 @@ -143,7 +143,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 -#### `schema` {#schema} +#### `schema` {#schema-1} - チェックポイントを保存するスキーマ名 (データベース名) を指定します。 @@ -427,7 +427,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 -### mydumper.csv {#mydumper-csv} +### mydumper.csv {#mydumpercsv} CSV ファイルの解析方法を構成します。 @@ -490,7 +490,7 @@ CSV ファイルの解析方法を構成します。 -### mydumper.files {#mydumper-files} +### mydumper.files {#mydumperfiles} #### `pattern` {#pattern} @@ -596,7 +596,7 @@ CSV ファイルの解析方法を構成します。 - `"skip-verify"` : TLSを強制しますが、サーバーの証明書を検証しません。この設定は安全ではないことに注意してください。 - `"preferred"` : `"skip-verify"`と同じですが、サーバーがTLS をサポートしていない場合は、暗号化されていない接続にフォールバックします。 -### tidb.セキュリティ {#tidb-security} +### tidb.セキュリティ {#tidbsecurity} - TLS 対応の MySQL 接続の証明書とキーを指定します。 - デフォルト値: [`security`](#security)セクションのコピー。 @@ -621,7 +621,7 @@ CSV ファイルの解析方法を構成します。 -### tidb.セッション変数 {#tidb-session-vars} +### tidb.セッション変数 {#tidbsession-vars} その他の TiDB セッション変数を指定します。 diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md index c60fbc0b02b40..64cba9dbde722 100644 --- a/tidb-lightning/tidb-lightning-faq.md +++ b/tidb-lightning/tidb-lightning-faq.md @@ -7,7 +7,7 @@ summary: TiDB Lightningに関するよくある質問 (FAQ) と回答につい このドキュメントには、 TiDB Lightningに関するよくある質問 (FAQ) と回答が記載されています。 -## TiDB Lightningでサポートされる最小の TiDB/TiKV/PD クラスター バージョンは何ですか? {#what-is-the-minimum-tidb-tikv-pd-cluster-version-supported-by-tidb-lightning} +## TiDB Lightningでサポートされる最小の TiDB/TiKV/PD クラスター バージョンは何ですか? {#what-is-the-minimum-tidbtikvpd-cluster-version-supported-by-tidb-lightning} TiDB Lightningのバージョンはクラスターと同じである必要があります。Local-backendモードを使用する場合、利用可能な最新バージョンは4.0.0です。Importer-backendモードまたはTiDB-backendモードを使用する場合、利用可能な最新バージョンは2.0.9ですが、安定版の3.0を使用することをお勧めします。 @@ -71,7 +71,7 @@ sql-mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION" ... ``` -## tidb-lightningプロセスを停止するにはどうすればいいですか? {#how-to-stop-the-code-tidb-lightning-code-process} +## tidb-lightningプロセスを停止するにはどうすればいいですか? {#how-to-stop-the-tidb-lightning-process} `tidb-lightning`プロセスを停止するには、展開方法に応じて対応する操作を選択できます。 diff --git a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md index 14db99220e2b8..9009f5813f224 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md @@ -133,7 +133,7 @@ analyze = "optional" 新しいバージョンの競合検出では`precheck-conflict-before-import`パラメータを使用して、インポート前の競合検出を有効にするかどうかを制御します。元のデータに競合データが多く含まれている場合、インポート前後の競合検出にかかる合計時間は、旧バージョンよりも短くなります。そのため、競合レコードの割合が 1% 以上で、ローカルディスクの空き容量が十分な場合は、インポート前の競合検出を有効にすることをお勧めします。 -### 旧バージョンの競合検出機能（v8.0.0で非推奨） {#the-old-version-of-conflict-detection-deprecated-in-v8-0-0} +### 旧バージョンの競合検出機能（v8.0.0で非推奨） {#the-old-version-of-conflict-detection-deprecated-in-v800} バージョン 8.0.0 以降、競合検出の旧バージョン ( `tikv-importer.duplicate-resolution` ) は非推奨となります。 `tikv-importer.duplicate-resolution`パラメータは今後のリリースで削除されます。 `tikv-importer.duplicate-resolution`が`remove`であり、 `conflict.strategy`が設定されていない場合、 TiDB Lightning は`conflict.strategy`の値`"replace"` 。 `tikv-importer.duplicate-resolution`と`conflict.strategy`は同時に設定できません。同時に設定するとエラーが発生しますのでご注意ください。 @@ -276,7 +276,7 @@ TiDB Lightningは、物理インポートモードでのインポートパフォ TiKV の[`num-threads`](/tikv-configuration-file.md#num-threads)設定もパフォーマンスに影響を与える可能性があります。新しいクラスターの場合は、 `num-threads` CPU コア数に設定することをお勧めします。 -## ディスククォータの設定（v6.2.0の新機能） {#configure-disk-quota-span-class-version-mark-new-in-v6-2-0-span} +## ディスククォータの設定（v6.2.0の新機能） {#configure-disk-quota-new-in-v620} 物理インポートモードでデータをインポートする場合、 TiDB Lightning は元のデータをエンコード、ソート、分割するために、ローカルディスク上に多数の一時ファイルを作成します。ローカルディスクの空き容量が不足すると、書き込みエラーが発生し、 TiDB Lightning はエラーを報告して終了します。 diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md index a202df09b9256..95e146928763d 100644 --- a/tidb-lightning/troubleshoot-tidb-lightning.md +++ b/tidb-lightning/troubleshoot-tidb-lightning.md @@ -38,7 +38,7 @@ strict-format = true 最新バージョンをお試しください。速度が改善されているかもしれません。 -## tidb-lightningプロセスがバックグラウンドで実行中に突然終了する {#the-code-tidb-lightning-code-process-suddenly-quits-while-running-in-background} +## tidb-lightningプロセスがバックグラウンドで実行中に突然終了する {#the-tidb-lightning-process-suddenly-quits-while-running-in-background} これは、 `tidb-lightning`正しく起動されていないためにシステムが SIGHUP シグナルを送信し、 `tidb-lightning`プロセスを停止したことが原因である可能性があります。この場合、 `tidb-lightning.log`通常、次のログを出力します。 @@ -64,7 +64,7 @@ tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode ## TiDB Lightningがエラーを報告 {#tidb-lightning-reports-an-error} -### `could not find first pair, this shouldn't happen` {#could-not-find-first-pair-this-shouldn-t-happen} +### `could not find first pair, this shouldn't happen` {#could-not-find-first-pair-this-shouldnt-happen} このエラーは、 TiDB Lightningがソート済みのローカルファイルを読み取る際に、開いているファイル数がシステム制限を超えたために発生する可能性があります。Linuxシステムでは、 `ulimit -n`コマンドを使用して、このシステム制限の値が小さすぎないかどうかを確認できます。インポート中にこの値を`1000000` （ `ulimit -n 1000000` ）に調整することをお勧めします。 @@ -94,7 +94,7 @@ tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode 3. TiDB Lightningが不適切に再起動された場合は、 FAQの「 [TiDB Lightningを適切に再起動する方法](/tidb-lightning/tidb-lightning-faq.md#how-to-properly-restart-tidb-lightning) 」セクションも参照してください。 -### Checkpoint for … has invalid status: (エラー コード) {#code-checkpoint-for-has-invalid-status-code-error-code} +### Checkpoint for … has invalid status: (エラー コード) {#checkpoint-for--has-invalid-status-error-code} **原因**: [チェックポイント](/tidb-lightning/tidb-lightning-checkpoints.md)が有効になっており、 TiDB Lightningまたは TiKV Importer が以前に異常終了しています。偶発的なデータ破損を防ぐため、エラーが解決されるまでTiDB Lightning は起動しません。 @@ -122,7 +122,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= 3. `[mydumper] character-set = "binary"`設定するとチェックをスキップします。ただし、これにより対象データベースに文字化けが発生する可能性があります。 -### [sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 …}' {#code-sql2kv-sql-encode-error-types-1292-invalid-time-format-1970-1-1-code} +### [sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 …}' {#sql2kv-sql-encode-error--types1292invalid-time-format-1970-1-1-} **原因**: テーブルに`timestamp`型の列が含まれていますが、時刻値自体が存在しません。これは、夏時間の変更、または時刻値がサポート範囲（1970年1月1日から2038年1月19日）を超えていることが原因です。 @@ -150,7 +150,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= - 制限を動的に増やすには、 [`tidb_txn_entry_size_limit`](/system-variables.md#tidb_txn_entry_size_limit-new-in-v760)システム変数を使用します。 - TiKVにも同様の制限があることに注意してください。1回の書き込みリクエストのデータサイズが[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size) （デフォルトでは`8MiB` ）を超えると、TiKVはこのリクエストの処理を拒否します。テーブルに大きなサイズの行がある場合は、両方の設定を変更する必要があります。 -### TiDB Lightningがモードを切り替えるときに、 rpc error: code = Unimplemented ... {#encounter-code-rpc-error-code-unimplemented-code-when-tidb-lightning-switches-the-mode} +### TiDB Lightningがモードを切り替えるときに、 rpc error: code = Unimplemented ... {#encounter-rpc-error-code--unimplemented--when-tidb-lightning-switches-the-mode} **原因**: クラスタ内の一部のノードが`switch-mode`サポートしていません。例えば、 TiFlash のバージョンが`v4.0.0-rc.2` 、 [`switch-mode`はサポートされていません](https://github.com/pingcap/tidb-lightning/issues/273)より前の場合などです。 @@ -159,13 +159,13 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= - クラスター内にTiFlashノードがある場合は、クラスターを`v4.0.0-rc.2`以上のバージョンに更新できます。 - クラスターをアップグレードしない場合は、 TiFlash を一時的に無効にします。 -### `tidb lightning encountered error: TiDB version too old, expected '>=4.0.0', found '3.0.18'` {#tidb-lightning-encountered-error-tidb-version-too-old-expected-4-0-0-found-3-0-18} +### `tidb lightning encountered error: TiDB version too old, expected '>=4.0.0', found '3.0.18'` {#tidb-lightning-encountered-error-tidb-version-too-old-expected-400-found-3018} 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の設定が対応するバージョンをサポートしていることを確認してください。そうでない場合、インポートが失敗する可能性があります。 -### `restore table test.district failed: unknown columns in header [...]` {#restore-table-test-district-failed-unknown-columns-in-header} +### `restore table test.district failed: unknown columns in header [...]` {#restore-table-testdistrict-failed-unknown-columns-in-header-} このエラーは通常、CSVデータファイルにヘッダーが含まれていないこと（最初の行が列名ではなくデータである）が原因で発生します。そのため、 TiDB Lightning設定ファイルに以下の設定を追加する必要があります。 @@ -176,7 +176,7 @@ TiDB Lightning Local-backend は、v4.0.0 以降のバージョンの TiDB ク TiDBはMySQLのすべての文字セットをサポートしていません。そのため、インポート中にテーブルスキーマを作成する際にサポートされていない文字セットが使用されると、 TiDB Lightningはこのエラーを報告します。このエラーを回避するには、特定のデータに応じて、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)使用して下流で事前にテーブルスキーマを作成してください。 -### `invalid compression type ...` {#invalid-compression-type} +### `invalid compression type ...` {#invalid-compression-type-} - TiDB Lightning v6.4.0以降のバージョンでは、 `gzip` `snappy`圧縮データファイルのみがサポートされています。その他の種類の圧縮ファイルを使用するとエラーが発生します。ソースデータファイルが保存されているディレクトリにサポートされていない圧縮ファイルが存在する場合、タスク`zstd`エラーを報告します。このようなエラーを回避するには、サポートされていないファイルをインポートデータディレクトリから移動してください。詳細については、 [圧縮ファイル](/tidb-lightning/tidb-lightning-data-source.md#compressed-files)参照してください。 diff --git a/tidb-resource-control-background-tasks.md b/tidb-resource-control-background-tasks.md index 2b6f931f432dd..445eae892c8ca 100644 --- a/tidb-resource-control-background-tasks.md +++ b/tidb-resource-control-background-tasks.md @@ -17,7 +17,7 @@ v7.4.0以降、 [TiDB リソース制御](/tidb-resource-control-ru-groups.md) > > リソース制御におけるバックグラウンドタスク管理は、TiKVによるCPU/IO使用率のリソースクォータの動的調整に基づいています。そのため、各インスタンスの利用可能なリソースクォータに依存します。複数のコンポーネントまたはインスタンスを単一サーバーにデプロイする場合、 `cgroup`を通して各インスタンスに適切なリソースクォータを設定する必要があります。TiUP Playgroundのような共有リソースを持つデプロイメントでは、期待される効果を得ることが困難です。 -## BACKGROUNDパラメータ {#code-background-code-parameters} +## BACKGROUNDパラメータ {#background-parameters} - `TASK_TYPES` : バックグラウンドタスクとして管理する必要があるタスクの種類を指定します。複数のタスクの種類を指定する場合は、カンマ ( `,` ) で区切ります。 - `UTILIZATION_LIMIT` : 各 TiKV ノード上でバックグラウンドタスクが消費できるリソースの最大割合（0～100）を制限します。デフォルトでは、TiKV はノードの総リソースとフォアグラウンドタスクが現在占有しているリソースに基づいて、バックグラウンドタスクに利用可能なリソースを計算します。`UTILIZATION_LIMIT`を設定すると、バックグラウンドタスクに割り当てられるリソースはこの制限を超えません。 diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index 7eb8b36abbf14..e4b3ee07c06e7 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -16,7 +16,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 リソース制御機能の詳細については、 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)参照してください。 -## QUERY_LIMITパラメータ {#code-query-limit-code-parameters} +## QUERY_LIMITパラメータ {#query_limit-parameters} クエリが次のいずれかの制限を超えると、ランナウェイ クエリとして識別されます。 @@ -77,7 +77,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ALTER RESOURCE GROUP rg1 QUERY_LIMIT=NULL; ``` -## QUERY WATCHパラメータ {#code-query-watch-code-parameters} +## QUERY WATCHパラメータ {#query-watch-parameters} `QUERY WATCH`のあらすじについては[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)参照してください。 diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index 1eeedde6684f5..03fa1a5b8a8a5 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -9,7 +9,7 @@ summary: TiDBでよく発生するエラーのトラブルシューティング ## 1. サービス利用不可 {#1-service-unavailable} -### 1.1 クライアントからRegion is Unavailableエラーが報告されました {#1-1-the-client-reports-code-region-is-unavailable-code-error} +### 1.1 クライアントからRegion is Unavailableエラーが報告されました {#11-the-client-reports-region-is-unavailable-error} - 1.1.1 `Region is Unavailable`エラーは通常、リージョンが一定期間利用できないことが原因です。 `TiKV server is busy`が発生する場合や、 `not leader`または`epoch not match` } が原因で TiKV へのリクエストが失敗するか、TiKV へのリクエストがタイムアウトする場合があります。このような場合、TiDB は`backoff`再試行メカニズムを実行します。 `backoff`がしきい値 (デフォルトでは 20 秒) を超えると、エラーがクライアントに送信されます。 `backoff`のしきい値内であれば、このエラーはクライアントには表示されません。 @@ -21,20 +21,20 @@ summary: TiDBでよく発生するエラーのトラブルシューティング - 1.1.5Followerの申請が前のエポックで遅延した場合、FollowerがLeaderになった後、 `epoch not match`を使用してリクエストを拒否します。中国語の[ケース958](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case958.md)参照してください（TiKV はそのメカニズムを最適化する必要があります）。 -### 1.2 PDエラーによりサービスが利用できなくなる {#1-2-pd-errors-cause-service-unavailable} +### 1.2 PDエラーによりサービスが利用できなくなる {#12-pd-errors-cause-service-unavailable} [5つのPD問題](#5-pd-issues)を参照。 ## 2. 遅延が大幅に増加する {#2-latency-increases-significantly} -### 2.1 一時的な増加 {#2-1-transient-increase} +### 2.1 一時的な増加 {#21-transient-increase} - 2.1.1 TiDB の実行プランが間違っているとレイテンシーが増加します[3.3](#33-wrong-execution-plan)を参照してください。 - 2.1.2 PD Leader選挙問題またはOOM。5.2および[5.2](#52-pd-election) [5.3](#53-pd-oom)参照してください。 - 2.1.3 一部のTiKVインスタンスでLeaderが多数ドロップする[4.4](#44-some-tikv-nodes-drop-leader-frequently)を参照。 - 2.1.4 他の原因については、[読み取り/書き込みレイテンシの増加に関するトラブルシューティング](/troubleshoot-cpu-issues.md)参照してください。 -### 2.2 持続的かつ著しい増加 {#2-2-persistent-and-significant-increase} +### 2.2 持続的かつ著しい増加 {#22-persistent-and-significant-increase} - 2.2.1 TiKVシングルスレッドのボトルネック @@ -52,7 +52,7 @@ summary: TiDBでよく発生するエラーのトラブルシューティング ## 3. TiDBの問題 {#3-tidb-issues} -### 3.1 DDL {#3-1-ddl} +### 3.1 DDL {#31-ddl} - 3.1.1 `ERROR 1105 (HY000): unsupported modify decimal column precision`フィールドの長さを変更すると、エラー`decimal`が報告されます。 TiDB は`decimal`フィールドの長さを変更することをサポートしていません。 @@ -99,7 +99,7 @@ summary: TiDBでよく発生するエラーのトラブルシューティング - 原因2については、TiDBサーバーとPD/TiKV間のネットワークを確認してください。 - 原因 3 については、TiKV がビジーである理由を調査します。 [TiKVに関する4つの問題](#4-tikv-issues)を参照。 -### 3.2 メモリ不足の問題 {#3-2-oom-issues} +### 3.2 メモリ不足の問題 {#32-oom-issues} - 3.2.1 症状 @@ -141,7 +141,7 @@ summary: TiDBでよく発生するエラーのトラブルシューティング OOM のトラブルシューティングの詳細については、 [TiDBのメモリ不足問題​​のトラブルシューティング](/troubleshoot-tidb-oom.md)を参照してください。 -### 3.3 実行計画の誤り {#3-3-wrong-execution-plan} +### 3.3 実行計画の誤り {#33-wrong-execution-plan} - 3.3.1 症状 @@ -165,7 +165,7 @@ OOM のトラブルシューティングの詳細については、 [TiDBのメ - その他の状況については、 [バグを報告する](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)。 -### 3.4 SQL実行エラー {#3-4-sql-execution-error} +### 3.4 SQL実行エラー {#34-sql-execution-error} - 3.4.1 クライアントは`ERROR 1265(01000) Data Truncated`エラーを報告します。これは、TiDB が内部的に`Decimal`型の精度を計算する方法が MySQL の計算方法と互換性がないためです。この問題は v3.0.10 ( [#14438](https://github.com/pingcap/tidb/pull/14438) ) で修正されました。 @@ -183,25 +183,25 @@ OOM のトラブルシューティングの詳細については、 [TiDBのメ - 解決策： `Cast(xx as decimal(a, b))`と`a`目標精度として、 `b` } を手動で追加することで、この問題を回避できます。 -### 3.5 クエリの遅延に関する問題 {#3-5-slow-query-issues} +### 3.5 クエリの遅延に関する問題 {#35-slow-query-issues} スロークエリを特定するには、[スロークエリを特定する](/identify-slow-queries.md)参照してください。スロークエリを分析して処理するには、[スロークエリを分析する](/analyze-slow-queries.md)参照してください。 -### 3.6 ホットスポットの問題 {#3-6-hotspot-issues} +### 3.6 ホットスポットの問題 {#36-hotspot-issues} 分散データベースであるTiDBは、サーバーリソースをより有効活用するために、アプリケーションの負荷をさまざまなコンピューティングノードやストレージノードに均等に分散させるロードバランシングメカニズムを備えています。しかし、特定のシナリオでは、アプリケーションの負荷が適切に分散されない場合があり、パフォーマンスに影響を与え、ホットスポットと呼ばれる高負荷の一点が発生する可能性があります。 TiDB は、ホットスポットのトラブルシューティング、解決、回避のための完全なソリューションを提供します。負荷ホットスポットのバランスをとることで、QPS の向上やレイテンシーの削減など、全体的なパフォーマンスを向上させることができます。詳細な解決策については、[ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md)参照してください。 -### 3.7 ディスクI/O使用率が高い {#3-7-high-disk-i-o-usage} +### 3.7 ディスクI/O使用率が高い {#37-high-disk-io-usage} CPU ボトルネックとトランザクションの競合によって引き起こされるボトルネックのトラブルシューティングを行った後に TiDB の応答が遅くなった場合は、現在のシステム ボトルネックを特定するために I/O メトリックを確認する必要があります。 TiDB での高い I/O 使用率の問題を特定して処理する方法については、[ディスクI/O使用率が高い場合のトラブルシューティング](/troubleshoot-high-disk-io.md)参照してください。 -### 3.8 ロックの競合 {#3-8-lock-conflicts} +### 3.8 ロックの競合 {#38-lock-conflicts} TiDB は完全な分散トランザクションをサポートします。 v3.0 以降、TiDB は楽観的トランザクション モードと悲観的トランザクション モードを提供します。ロック関連の問題のトラブルシューティング方法、および楽観的ロックと悲観的ロックの競合の処理方法については、[ロックの競合をトラブルシューティングする](/troubleshoot-lock-conflicts.md)参照してください。 -### 3.9 データと指標の不整合 {#3-9-inconsistency-between-data-and-indexes} +### 3.9 データと指標の不整合 {#39-inconsistency-between-data-and-indexes} TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|INDEX]`](/sql-statements/sql-statement-admin-check-table-index.md)ステートメントの実行時に、データとインデックスの一貫性をチェックします。チェックの結果、レコードのキーと値、および対応するインデックスのキーと値が一致しない、つまり、行データを格納するキーと値のペアと、そのインデックスを格納する対応するキーと値のペアが一致しない（例えば、インデックスが多すぎる、またはインデックスが欠落している）ことが判明した場合、TiDB はデータ不整合エラーを報告し、関連するエラーをエラー ログに出力。 @@ -209,7 +209,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND ## 4. TiKVに関する問題 {#4-tikv-issues} -### 4.1 TiKVがパニックを起こして起動に失敗する {#4-1-tikv-panics-and-fails-to-start} +### 4.1 TiKVがパニックを起こして起動に失敗する {#41-tikv-panics-and-fails-to-start} - 4.1.1 TiKVが仮想マシンにデプロイされている場合、仮想マシンが強制終了されたり、物理マシンが電源オフになったりすると、 `entries[X, Y] is unavailable from storage`エラーが報告されます。 @@ -217,7 +217,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 4.1.2 その他の予期せぬ原因については、 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 -### 4.2 TiKV OOM {#4-2-tikv-oom} +### 4.2 TiKV OOM {#42-tikv-oom} - 4.2.1 `block-cache`の設定が大きすぎると、メモリ不足が発生する可能性があります。 @@ -233,7 +233,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND この問題は予期せぬものです。 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)ことができます。 -### 4.3 クライアントがserver is busyと報告するエラー {#4-3-the-client-reports-the-code-server-is-busy-code-error} +### 4.3 クライアントがserver is busyと報告するエラー {#43-the-client-reports-the-server-is-busy-error} ビジー状態の具体的な原因を確認するには、モニター**Grafana** -> **TiKV** -> **errors を**確認してください。 `server is busy` 、TiKV のフロー制御メカニズムが原因で発生しており、TiKV が現在過負荷状態にあるため後で再試行することを`tidb/ti-client`に通知します。 @@ -269,7 +269,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 4.3.4 TiKV コプロセッサがキューに入っています。スタックされたタスクの数が`coprocessor threads * readpool.coprocessor.max-tasks-per-worker-[normal|low|high]`を超えています。大きなクエリが多すぎると、コプロセッサでタスクがスタックされます。実行プランの変更によってテーブルスキャン操作が大量に発生していないか確認する必要があります[3.3](#33-wrong-execution-plan)を参照してください。 -### 4.4 一部のTiKVノードは頻繁にLeaderをドロップする {#4-4-some-tikv-nodes-drop-leader-frequently} +### 4.4 一部のTiKVノードは頻繁にLeaderをドロップする {#44-some-tikv-nodes-drop-leader-frequently} - 4.4.1 TiKVが再起動されたため再選が行われる @@ -285,7 +285,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 4.4.3 ネットワークの孤立による再選出。 -### 4.5 TiKVへの書き込みが遅い {#4-5-tikv-write-is-slow} +### 4.5 TiKVへの書き込みが遅い {#45-tikv-write-is-slow} - 4.5.1 TiKV gRPC の`prewrite/commit/raw-put`の継続時間を表示して、TiKV 書き込みが遅いかどうかを確認します (RawKV クラスターの場合のみ)。一般に、 [パフォーマンスマップ](https://github.com/pingcap/tidb-map/blob/master/maps/performance-map.png)に従って遅い段階を特定できます。よくある状況のいくつかを以下に示します。 @@ -330,7 +330,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND ## 5. PD問題 {#5-pd-issues} -### 5.1 PDスケジューリング {#5-1-pd-scheduling} +### 5.1 PDスケジューリング {#51-pd-scheduling} - 5.1.1 マージ @@ -348,7 +348,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - Leader/リージョンの数が均等に分布していません。中国語の[ケース394](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case394.md)と[ケース759](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case759.md)を参照してください。主な原因は、バランス調整がリージョン/Leaderのサイズに基づいてスケジューリングを実行するため、数の分布が不均等になる可能性があることです。TiDB 4.0では、 `[leader-schedule-policy]`パラメータが導入され、Leaderのスケジューリングポリシーを`count`ベースまたは`size`ベースに設定できるようになりました。 -### 5.2 PD選挙 {#5-2-pd-election} +### 5.2 PD選挙 {#52-pd-election} - 5.2.1 PD スイッチLeader。 @@ -382,19 +382,19 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - その他の状況については、 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 -### 5.3 PD OOM {#5-3-pd-oom} +### 5.3 PD OOM {#53-pd-oom} - 5.3.1 `/api/v1/regions`インターフェースを使用する場合、リージョンが多すぎると PD OOM が発生する可能性があります。この問題は v3.0.8 ( [#1986](https://github.com/pingcap/pd/pull/1986) ) で修正されました。 - 5.3.2 ローリングアップグレード中にPD OOMが発生します。gRPCメッセージのサイズに制限がなく、モニターにはTCP InSegsが比較的大きいことが示されています。この問題はv3.0.6で修正されました（ [#1952](https://github.com/pingcap/pd/pull/1952) ）。 -### 5.4 Grafanaの表示 {#5-4-grafana-display} +### 5.4 Grafanaの表示 {#54-grafana-display} - 5.4.1 **Grafana** -> **PD** -> **cluster** -> **role**のモニターにフォロワーが表示されます。Grafana の式に関する問題は v3.0.8 で修正されました。 ## 6. エコシステムツール {#6-ecosystem-tools} -### 6.1 データ移行 {#6-1-data-migration} +### 6.1 データ移行 {#61-data-migration} - 6.1.1 TiDB Data Migration (DM)は、MySQL/MariaDBからTiDBへのデータ移行をサポートする移行ツールです。詳細については、 [DMの概要](/dm/dm-overview.md)参照してください。 @@ -442,7 +442,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - この値は MySQL 8.0 または TiDB には正常に書き込めませんが、 MySQL 5.7には書き込めます。 `tidb_skip_utf8_check`パラメータを有効にすることで、データ形式のチェックをスキップできます。 -### 6.2 TiDB Lightning {#6-2-tidb-lightning} +### 6.2 TiDB Lightning {#62-tidb-lightning} - 6.2.1 TiDB Lightningは、大量のデータを TiDB クラスタに高速に完全インポートするためのツールです。TiDB [TiDB Lightning （GitHub）](https://github.com/pingcap/tidb/tree/release-8.5/lightning)を参照してください。 @@ -491,7 +491,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND ## 7. 一般的なログ分析 {#7-common-log-analysis} -### 7.1 TiDB {#7-1-tidb} +### 7.1 TiDB {#71-tidb} - 7.1.1 `GC life time is shorter than transaction duration` 。 @@ -524,7 +524,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND SET GLOBAL tidb_gc_enable = 0; ``` -### 7.2 TiKV {#7-2-tikv} +### 7.2 TiKV {#72-tikv} - 7.2.1 `key is locked` 。 diff --git a/tiflash/tiflash-command-line-flags.md b/tiflash/tiflash-command-line-flags.md index 5c36a3d6599a8..d64b04ce0d3b8 100644 --- a/tiflash/tiflash-command-line-flags.md +++ b/tiflash/tiflash-command-line-flags.md @@ -7,7 +7,7 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま このドキュメントでは、 TiFlash を起動するときに使用できるコマンドラインフラグについて説明します。 -## `server --config-file` {#server-config-file} +## `server --config-file` {#server---config-file} - TiFlash構成ファイルのパスを指定します - デフォルト： "" diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 40017e4c12b19..995a93376792f 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -15,31 +15,31 @@ summary: TiFlash の設定方法を学びます。 > > 構成項目の値を調整する必要がある場合は、 [設定を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)を参照してください。 -### tiflash.tomlファイルを設定する {#configure-the-code-tiflash-toml-code-file} +### tiflash.tomlファイルを設定する {#configure-the-tiflashtoml-file} -#### `listen_host` {#listen-host} +#### `listen_host` {#listen_host} - TPC/HTTP などのサービスをサポートするためのリスニング ホスト。 - これを`"0.0.0.0"`に設定することをお勧めします。これは、このマシンのすべての IP アドレスをリッスンすることを意味します。 -#### `tcp_port` {#tcp-port} +#### `tcp_port` {#tcp_port} - TiFlash TCP サービスポート。このポートは内部テストに使用され、デフォルトでは 9000 に設定されています。 - TiFlash v7.1.0より前のバージョンでは、このポートはデフォルトで有効になっていますが、セキュリティリスクがあります。セキュリティを強化するため、このポートにアクセス制御を適用し、ホワイトリストに登録されたIPアドレスからのアクセスのみを許可することをお勧めします。TiFlash v7.1.0以降では、このポートの設定をコメントアウトすることでセキュリティリスクを回避できます。TiFlashの設定ファイルでこのポートが指定されていない場合、このポートは無効になります。 - TiFlashデプロイメントでは、このポートを構成することは推奨され**ません**。(注: TiFlash v7.1.0 以降、 TiUP >= v1.12.5 またはTiDB Operator >= v1.5.0 でデプロイされたTiFlash は、デフォルトでポートを無効にし、より安全になっています。) - デフォルト値: `9000` -#### `mark_cache_size` {#mark-cache-size} +#### `mark_cache_size` {#mark_cache_size} - データブロックのメタデータのキャッシュサイズ制限。通常、この値を変更する必要はありません。 - デフォルト値: `1073741824` -#### `minmax_index_cache_size` {#minmax-index-cache-size} +#### `minmax_index_cache_size` {#minmax_index_cache_size} - データブロックの最小-最大インデックスのキャッシュサイズ制限。通常、この値を変更する必要はありません。 - デフォルト値: `1073741824` -#### `delta_index_cache_size` {#delta-index-cache-size} +#### `delta_index_cache_size` {#delta_index_cache_size} - DeltaIndex のキャッシュ サイズの制限。 - デフォルト値: `0` 、制限がないことを意味します。 @@ -53,14 +53,14 @@ summary: TiFlash の設定方法を学びます。 -#### `path_realtime_mode` {#path-realtime-mode} +#### `path_realtime_mode` {#path_realtime_mode} - `true`に設定し、 `path`に複数のディレクトリを設定した場合、最初のディレクトリに最新のデータが保存され、残りのディレクトリには古いデータが保存されます。 - TiDB v4.0.9以降、 [`path`](#path)と`path_realtime_mode`は非推奨となりました。マルチディスク展開シナリオでパフォーマンスを向上させるには、 [`storage`](#storage-new-in-v409)セクションの設定を使用してください。 - `storage`構成が存在する場合、 [`path`](#path)と`path_realtime_mode`構成は両方とも無視されます。 - デフォルト値: `false` -#### `tmp_path` {#tmp-path} +#### `tmp_path` {#tmp_path} - TiFlash一時ファイルが保存されるパス。 - デフォルトでは、 [`path`](#path)の最初のディレクトリ、または[`storage.latest.dir`](#dir-1)に`"/tmp"`を付加したディレクトリになります。 @@ -71,7 +71,7 @@ summary: TiFlash の設定方法を学びます。 ストレージパス関連の設定を構成します。 -##### `format_version` {#format-version} +##### `format_version` {#format_version} - DTFile 形式。 - デフォルト値: `7` @@ -83,60 +83,60 @@ summary: TiFlash の設定方法を学びます。 - `format_version = 6` : v8.4.0 で導入され、ベクトル インデックスの構築とストレージを部分的にサポートします。 - `format_version = 7` : v8.4.0 で導入され、v8.4.0 以降のバージョンのデフォルト形式で、ベクトル インデックスの構築とストレージをサポートします。 -#### storage.main {#storage-main} +#### storage.main {#storagemain} -##### `dir` {#dir} +##### `dir` {#dir-1} - メインデータを保存するディレクトリのリスト。例： `[ "/tidb-data/tiflash-9000" ]`または`[ "/ssd0/tidb-data/tiflash", "/ssd1/tidb-data/tiflash" ]` 。 - 全データの 90% 以上がディレクトリ リストに保存されます。 -##### `capacity` {#capacity} +##### `capacity` {#capacity-1} - [`storage.main.dir`](#dir)内の各ディレクトリの最大ストレージ容量。例: `[10737418240, 10737418240]` 。 - 設定されていない場合、または`0`倍数に設定されている場合、実際のディスク (ディレクトリが配置されているディスク) の容量が使用されます。 - 単位: バイト`"10GB"`などの人間が読める数値はまだサポートされていないことに注意してください。 - `capacity`番目のリストのサイズは[`storage.main.dir`](#dir)リストのサイズと同じである必要があります。 -#### storage.latest {#storage-latest} +#### storage.latest {#storagelatest} -##### `dir` {#dir} +##### `dir` {#dir-2} - 最新データを保存するディレクトリのリストです。全データの約10%がこのディレクトリリストに保存されます。ここにリストされているディレクトリ（またはディレクトリ）は、 [`storage.main.dir`](#dir)よりも高いIOPSメトリックを必要とします。 - 設定されていない場合（デフォルト）、値[`storage.main.dir`](#dir)が使用されます。 -##### `capacity` {#capacity} +##### `capacity` {#capacity-2} - [`storage.latest.dir`](#dir-1)内の各ディレクトリの最大ストレージ容量。設定されていない場合、または`0`倍数に設定されている場合は、実際のディスク（ディレクトリが配置されているディスク）の容量が使用されます。 -#### storage.io_rate_limit v5.2.0 の新機能 {#storage-io-rate-limit-new-in-v520} +#### storage.io_rate_limit v5.2.0 の新機能 {#storageio_rate_limit-new-in-v520} I/O トラフィック制限設定を構成します。 -##### `max_bytes_per_sec` {#max-bytes-per-sec} +##### `max_bytes_per_sec` {#max_bytes_per_sec} - ディスクの読み取りと書き込みの合計I/O帯域幅。この設定項目は、I/Oトラフィックを制限するかどうかを決定します。デフォルトでは無効になっています。TiFlashにおけるこのトラフィック制限は、ディスク帯域幅が小さく、特定のサイズに制限TiFlashれているクラウドストレージに適しています。 - デフォルト値: `0` 。これは、I/O トラフィックがデフォルトで制限されないことを意味します。 - 単位: バイト -##### `max_read_bytes_per_sec` {#max-read-bytes-per-sec} +##### `max_read_bytes_per_sec` {#max_read_bytes_per_sec} - ディスク読み取りの合計 I/O 帯域幅。 - 設定項目`max_read_bytes_per_sec`および`max_write_bytes_per_sec` 、ディスクの読み取りと書き込みの I/O 帯域幅を個別に制限します。Google Cloud が提供する Persistent Disk など、ディスクの読み取りと書き込みの I/O 帯域幅の制限を個別に計算するクラウドストレージに使用できます。 - `max_bytes_per_sec`の値が`0`でない場合は[`max_bytes_per_sec`](#max_bytes_per_sec)が優先されます。 - デフォルト値: `0` -##### `max_write_bytes_per_sec` {#max-write-bytes-per-sec} +##### `max_write_bytes_per_sec` {#max_write_bytes_per_sec} - ディスク書き込みの合計 I/O 帯域幅。 - 設定項目`max_read_bytes_per_sec`および`max_write_bytes_per_sec` 、ディスクの読み取りと書き込みの I/O 帯域幅を個別に制限します。Google Cloud が提供する Persistent Disk など、ディスクの読み取りと書き込みの I/O 帯域幅の制限を個別に計算するクラウドストレージに使用できます。 - `max_bytes_per_sec`の値が`0`でない場合は[`max_bytes_per_sec`](#max_bytes_per_sec)が優先されます。 - デフォルト値: `0` -##### `foreground_write_weight` {#foreground-write-weight} +##### `foreground_write_weight` {#foreground_write_weight} @@ -145,35 +145,35 @@ I/O トラフィック制限設定を構成します。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 -##### `background_write_weight` {#background-write-weight} +##### `background_write_weight` {#background_write_weight} - TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。1 `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} +##### `foreground_read_weight` {#foreground_read_weight} - TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。1 `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} +##### `background_read_weight` {#background_read_weight} - TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。1 `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% の割り当てを表します。 -##### `auto_tune_sec` {#auto-tune-sec} +##### `auto_tune_sec` {#auto_tune_sec} - TiFlashは、現在のI/O負荷に応じて、異なるI/Oタイプのトラフィック制限を自動的に調整する機能をサポートしています。調整された帯域幅が、上記で設定した重み付け比率を超える場合があります。 - `auto_tune_sec`自動チューニングの間隔を示します。auto_tune_sec の値が`0`の場合、自動チューニングは無効になります。 - デフォルト値: `5` - 単位: 秒 -#### storage.s3 {#storage-s3} +#### storage.s3 {#storages3} 以下の設定項目は、 TiFlash分散ストレージおよびコンピューティングアーキテクチャモードにのみ適用されます。詳細については、 [TiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 サポート](/tiflash/tiflash-disaggregated-and-s3.md)参照してください。 @@ -189,15 +189,15 @@ I/O トラフィック制限設定を構成します。 - S3 バケット内でデータが保存されるルートディレクトリ。例: `/cluster1_data` 。 -##### `access_key_id` {#access-key-id} +##### `access_key_id` {#access_key_id} - S3 にアクセスするために使用される ACCESS_KEY_ID。 -##### `secret_access_key` {#secret-access-key} +##### `secret_access_key` {#secret_access_key} - S3 にアクセスするために使用される SECRET_ACCESS_KEY。 -#### storage.remote.cache {#storage-remote-cache} +#### storage.remote.cache {#storageremotecache} ##### `dir` {#dir} @@ -211,44 +211,44 @@ I/O トラフィック制限設定を構成します。 #### フラッシュ {#flash} -##### `service_addr` {#service-addr} +##### `service_addr` {#service_addr} - TiFlashコプロセッサ サービスのリスニング アドレス。 -##### `compact_log_min_gap` v7.4.0 の新機能 {#compact-log-min-gap-new-in-v740} +##### `compact_log_min_gap` v7.4.0 の新機能 {#compact_log_min_gap-new-in-v740} - 現在のRaftステート マシンによって進められた`applied_index`と最後のディスク スピル時の`applied_index`との差が`compact_log_min_gap`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクにスピルします。 - このギャップを大きくすると、 TiFlashのディスク書き込み頻度が低下し、ランダム書き込みシナリオにおける読み取りレイテンシーが短縮される可能性がありますが、メモリオーバーヘッドも増加する可能性があります。このギャップを小さくすると、 TiFlashのディスク書き込み頻度が増加し、 TiFlashのメモリ負荷が軽減される可能性があります。ただし、現段階では、このギャップを`0`に設定しても、 TiFlashのディスク書き込み頻度は TiKV よりも高くなることはありません。 - デフォルト値を維持することをお勧めします。 - デフォルト値: `200` -##### `compact_log_min_rows`バージョン5.0の新機能 {#compact-log-min-rows-new-in-v50} +##### `compact_log_min_rows`バージョン5.0の新機能 {#compact_log_min_rows-new-in-v50} - TiFlashによってキャッシュされたリージョン内の行の数またはサイズが`compact_log_min_rows`または`compact_log_min_bytes`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクに書き込みます。 - デフォルト値を維持することをお勧めします。 - デフォルト値: `40960` -##### `compact_log_min_bytes`バージョン5.0の新機能 {#compact-log-min-bytes-new-in-v50} +##### `compact_log_min_bytes`バージョン5.0の新機能 {#compact_log_min_bytes-new-in-v50} - TiFlashによってキャッシュされたリージョン内の行の数またはサイズが`compact_log_min_rows`または`compact_log_min_bytes`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクに書き込みます。 - デフォルト値を維持することをお勧めします。 - デフォルト値: `33554432` -##### `disaggregated_mode` {#disaggregated-mode} +##### `disaggregated_mode` {#disaggregated_mode} - この設定項目は、 TiFlash分散ストレージおよびコンピューティングアーキテクチャモードにのみ適用されます。詳細については、 [TiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 サポート](/tiflash/tiflash-disaggregated-and-s3.md)参照してください。 - 値`"tiflash_compute"`オプション: `"tiflash_write"` -##### `graceful_wait_shutdown_timeout` v8.5.4 の新機能 {#graceful-wait-shutdown-timeout-new-in-v854} +##### `graceful_wait_shutdown_timeout` v8.5.4 の新機能 {#graceful_wait_shutdown_timeout-new-in-v854} - TiFlashサーバーをシャットダウンする際の最大待機時間を制御します。この期間中、 TiFlash は未完了の MPP タスクの実行を継続しますが、新しいタスクは受け付けません。実行中のすべての MPP タスクがこのタイムアウト前に終了した場合、 TiFlash は直ちにシャットダウンします。それ以外の場合は、待機時間が経過した後に強制的にシャットダウンされます。 - デフォルト値: `600` - 単位: 秒 - TiFlashサーバーがシャットダウンを待機している間 (猶予期間中)、TiDB は新しい MPP タスクをサーバーに送信しません。 -#### フラッシュプロキシ {#flash-proxy} +#### フラッシュプロキシ {#flashproxy} ##### `addr` {#addr} @@ -328,33 +328,33 @@ I/O トラフィック制限設定を構成します。 #### ラフト {#raft} -##### `pd_addr` {#pd-addr} +##### `pd_addr` {#pd_addr} - PD サービス アドレス。 - 複数のアドレスはカンマで区切られます。例： `"10.0.1.11:2379,10.0.1.12:2379,10.0.1.13:2379"` 。 #### 状態 {#status} -##### `metrics_port` {#metrics-port} +##### `metrics_port` {#metrics_port} - Prometheus がメトリック情報を取得するポート。 - デフォルト値: `8234` -#### プロファイル.デフォルト {#profiles-default} +#### プロファイル.デフォルト {#profilesdefault} -##### `dt_enable_logical_split` {#dt-enable-logical-split} +##### `dt_enable_logical_split` {#dt_enable_logical_split} - DeltaTreeストレージエンジンのセグメントで論理分割を使用するかどうかを指定します。論理分割を使用すると書き込み増幅を削減できますが、ディスク領域の無駄が発生します。 - v6.2.0以降のバージョンでは、デフォルト値の`false`を維持し、 `true`に変更しないことを強くお勧めします。詳細については、既知の問題[＃5576](https://github.com/pingcap/tiflash/issues/5576)を参照してください。 - デフォルト値: `false` -##### `max_threads` {#max-threads} +##### `max_threads` {#max_threads} - `max_threads` 、 TiFlash がMPP タスクを実行する際の内部スレッド同時実行数を示します。2 `0`設定すると、 TiFlash は論理 CPU コアの数を同時実行数として使用します。 - このパラメータは、システム変数[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610) `-1`に設定されている場合にのみ有効になります。 - デフォルト値: `0` -##### `max_memory_usage` {#max-memory-usage} +##### `max_memory_usage` {#max_memory_usage} - 単一のクエリで生成される中間データのメモリ使用量の制限。 - 値が整数の場合、単位はバイトです。例えば、 `34359738368` 32GiBのメモリ制限を意味します。 @@ -362,7 +362,7 @@ I/O トラフィック制限設定を構成します。 - クエリがこの制限を超えるメモリを消費しようとすると、クエリは終了され、エラーが報告されます。 - デフォルト値: `0` 、制限がないことを意味します。 -##### `max_memory_usage_for_all_queries` {#max-memory-usage-for-all-queries} +##### `max_memory_usage_for_all_queries` {#max_memory_usage_for_all_queries} - すべてのクエリで生成される中間データのメモリ使用量制限。 - 値が整数の場合、単位はバイトです。例えば、 `34359738368` 32GiBのメモリ制限を意味し、 `0`制限なしを意味します。 @@ -370,45 +370,45 @@ I/O トラフィック制限設定を構成します。 - クエリがこの制限を超えるメモリを消費しようとすると、クエリは終了され、エラーが報告されます。 - デフォルト値： `0.8` （総メモリの80%を意味します）。v6.6.0より前のバージョンでは、デフォルト値は`0` （無制限を意味します）でした。 -##### `cop_pool_size`バージョン5.0の新機能 {#cop-pool-size-new-in-v50} +##### `cop_pool_size`バージョン5.0の新機能 {#cop_pool_size-new-in-v50} - TiFlashコプロセッサーが同時に実行できるcopリクエストの最大数を指定します。リクエスト数がこの値を超えても、10倍以内の場合、超過したリクエストはキューに入れられます。リクエスト数がこの値の10倍を超える場合、超過したリクエストはTiFlashによって拒否されます。設定値が`0`に設定されている場合、または設定されていない場合は、デフォルト値（物理コア数の2倍）が使用されます。 - デフォルト値: 物理コア数の2倍 -##### `cop_pool_handle_limit`バージョン5.0の新機能 {#cop-pool-handle-limit-new-in-v50} +##### `cop_pool_handle_limit`バージョン5.0の新機能 {#cop_pool_handle_limit-new-in-v50} - TiFlashコプロセッサーが同時に処理できるCOPリクエストの最大数を指定します。これには、実行中のリクエストとキューで待機中のリクエストが含まれます。リクエスト数が指定値を超えると、エラー`TiFlash Server is Busy`が返されます。 - `-1`制限がないことを示し、 `0`デフォルト値の`10 * cop_pool_size`を使用することを示します。 -##### `cop_pool_max_queued_seconds`バージョン5.0の新機能 {#cop-pool-max-queued-seconds-new-in-v50} +##### `cop_pool_max_queued_seconds`バージョン5.0の新機能 {#cop_pool_max_queued_seconds-new-in-v50} - cop要求がTiFlashにキューイングできる最大時間を指定します。cop要求がこの設定で指定された値よりも長くキュー内で待機した場合、エラー`TiFlash Server is Busy`が返されます。 - `0`以下の値は制限がないことを示します。 - デフォルト値: `15` -##### `batch_cop_pool_size`バージョン5.0の新機能 {#batch-cop-pool-size-new-in-v50} +##### `batch_cop_pool_size`バージョン5.0の新機能 {#batch_cop_pool_size-new-in-v50} - TiFlashコプロセッサーが同時に実行するバッチリクエストの最大数を指定します。リクエスト数が指定値を超えた場合、超過分のリクエストはキューに入れられます。設定値が`0`に設定されているか未設定の場合は、デフォルト値（物理コア数の2倍）が使用されます。 - デフォルト値: 物理コア数の2倍 -##### `manual_compact_pool_size`バージョン6.1の新機能 {#manual-compact-pool-size-new-in-v61} +##### `manual_compact_pool_size`バージョン6.1の新機能 {#manual_compact_pool_size-new-in-v61} - TiFlash がTiDB から`ALTER TABLE ... COMPACT`受信したときに同時に処理できる要求の数を指定します。 - 値が`0`に設定されている場合、デフォルト値`1`が優先されます。 - デフォルト値: `1` -##### `enable_elastic_threadpool`バージョン5.4.0の新機能 {#enable-elastic-threadpool-new-in-v540} +##### `enable_elastic_threadpool`バージョン5.4.0の新機能 {#enable_elastic_threadpool-new-in-v540} - エラスティック スレッド プール機能を有効にするかどうかを制御します。この機能により、 TiFlashの同時実行性の高いシナリオで CPU 使用率が大幅に向上します。 - デフォルト値: `true` -##### `dt_compression_method` {#dt-compression-method} +##### `dt_compression_method` {#dt_compression_method} - TiFlashストレージエンジンの圧縮アルゴリズム。 - デフォルト値: `LZ4` - 値のオプション: `LZ4` `LZ4HC`値は`zstd`と小文字を区別しません。 -##### `dt_compression_level` {#dt-compression-level} +##### `dt_compression_level` {#dt_compression_level} - TiFlashストレージエンジンの圧縮レベル。 - `dt_compression_method`が`LZ4`の場合は、この値を`1`に設定することをお勧めします。 @@ -416,52 +416,52 @@ I/O トラフィック制限設定を構成します。 - `dt_compression_method`が`LZ4HC`の場合は、この値を`9`に設定することをお勧めします。 - デフォルト値: `1` -##### `dt_page_gc_threshold` v6.2.0 の新機能 {#dt-page-gc-threshold-new-in-v620} +##### `dt_page_gc_threshold` v6.2.0 の新機能 {#dt_page_gc_threshold-new-in-v620} - PageStorageデータファイル内の有効データの最小比率を指定します。PageStorageデータファイル内の有効データの比率がこの設定値を下回ると、GCがトリガーされ、ファイル内のデータが圧縮されます。 - デフォルト値: `0.5` -##### `max_bytes_before_external_group_by` v7.0.0 の新機能 {#max-bytes-before-external-group-by-new-in-v700} +##### `max_bytes_before_external_group_by` v7.0.0 の新機能 {#max_bytes_before_external_group_by-new-in-v700} - ハッシュ集計演算子（キー`GROUP BY`で使用可能な最大メモリを指定します。この値を超えるとディスクへの書き込みがトリガーされます。メモリ使用量がしきい値を超えると、ハッシュ集計はメモリ使用量を[ディスクへのスピル](/tiflash/tiflash-spill-disk.md)削減します。 - デフォルト値: `0` 。これは、メモリ使用量が無制限であり、ハッシュ集計にディスクへのスピルが使用されないことを意味します。 -##### `max_bytes_before_external_sort`バージョン7.0.0の新機能 {#max-bytes-before-external-sort-new-in-v700} +##### `max_bytes_before_external_sort`バージョン7.0.0の新機能 {#max_bytes_before_external_sort-new-in-v700} - ソート演算子またはtopN演算子で使用可能な最大メモリを指定します。この値を超えるとディスクへの書き込みがトリガーされます。メモリ使用量がこのしきい値を超えると、ソート演算子またはtopN演算子はメモリ使用量を[ディスクへのスピル](/tiflash/tiflash-spill-disk.md)ずつ減らします。 - デフォルト値: `0` 。これは、メモリ使用量が無制限であり、ソートや topN にディスクへのスピルが使用されないことを意味します。 -##### `max_bytes_before_external_join`バージョン7.0.0の新機能 {#max-bytes-before-external-join-new-in-v700} +##### `max_bytes_before_external_join`バージョン7.0.0の新機能 {#max_bytes_before_external_join-new-in-v700} - 等価結合条件を持つハッシュ結合演算子で使用可能な最大メモリを指定します。この値を超えるとディスクへの書き込みがトリガーされます。メモリ使用量がしきい値を超えると、HashJoin はメモリ使用量を[ディスクへのスピル](/tiflash/tiflash-spill-disk.md)減らします。 - デフォルト値: `0` 。これは、メモリ使用量が無制限であり、等価結合条件によるハッシュ結合ではディスクへのスピルが使用されないことを意味します。 -##### `enable_resource_control`バージョン7.4.0の新機能 {#enable-resource-control-new-in-v740} +##### `enable_resource_control`バージョン7.4.0の新機能 {#enable_resource_control-new-in-v740} - TiFlashリソース制御機能を有効にするかどうかを制御します。1 `true`設定すると、 TiFlashは[パイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用します。 - デフォルト値: `true` - 値`false`オプション: `true` -##### `task_scheduler_thread_soft_limit`バージョン6.0.0の新機能 {#task-scheduler-thread-soft-limit-new-in-v600} +##### `task_scheduler_thread_soft_limit`バージョン6.0.0の新機能 {#task_scheduler_thread_soft_limit-new-in-v600} - この項目はMinTSOスケジューラで使用されます。1つのリソースグループが使用できるスレッドの最大数を指定します。詳細については、 [TiFlash MinTSO スケジューラ](/tiflash/tiflash-mintso-scheduler.md)参照してください。 - デフォルト値: `5000` -##### `task_scheduler_thread_hard_limit`バージョン6.0.0の新機能 {#task-scheduler-thread-hard-limit-new-in-v600} +##### `task_scheduler_thread_hard_limit`バージョン6.0.0の新機能 {#task_scheduler_thread_hard_limit-new-in-v600} - この項目はMinTSOスケジューラで使用されます。グローバルスコープ内のスレッドの最大数を指定します。詳細については、 [TiFlash MinTSO スケジューラ](/tiflash/tiflash-mintso-scheduler.md)参照してください。 - デフォルト値: `10000` -##### `task_scheduler_active_set_soft_limit`バージョン6.4.0の新機能 {#task-scheduler-active-set-soft-limit-new-in-v640} +##### `task_scheduler_active_set_soft_limit`バージョン6.4.0の新機能 {#task_scheduler_active_set_soft_limit-new-in-v640} - この項目はMinTSOスケジューラに使用されます。TiFlashで同時に実行できるクエリの最大数を指定します。詳細については、 [TiFlash MinTSO スケジューラ](/tiflash/tiflash-mintso-scheduler.md)参照してください。 - デフォルト値: バージョン7.4.0より前のバージョンでは、デフォルト値は`vcpu * 0.25`で、これはvCPU数の4分の1を意味します。バージョン7.4.0以降では、デフォルト値は`vcpu * 2`で、これはvCPU数の2倍を意味します。 -#### セキュリティv4.0.5 の新機能 {#security-span-class-version-mark-new-in-v4-0-5-span} +#### セキュリティv4.0.5 の新機能 {#security-new-in-v405} セキュリティ関連の設定を構成します。 -##### `redact_info_log`バージョン5.0の新機能 {#redact-info-log-new-in-v50} +##### `redact_info_log`バージョン5.0の新機能 {#redact_info_log-new-in-v50} - ログ編集を有効にするかどうかを制御します。 - デフォルト値: `false` @@ -471,32 +471,32 @@ I/O トラフィック制限設定を構成します。 - 設定項目を`"marker"`に設定すると、ログ内のすべてのユーザーデータは`‹ ›`で囲まれます。ユーザーデータに`‹`または`›`が含まれている場合、 `‹`は`‹‹`に、 `›`は`››`にエスケープされます。マークされたログに基づいて、ログを表示する際にマークされた情報を非感度化するかどうかを決定できます。 - [`tiflash-learner.toml`](#configure-the-tiflash-learnertoml-file)での tiflash-learner のログインにも`security.redact-info-log`設定する必要があることに注意してください。 -##### `ca_path` {#ca-path} +##### `ca_path` {#ca_path} - 信頼できるSSL CAのリストを含むファイルのパス。設定する場合は、 [`cert_path`](#cert_path)と[`key_path`](#key_path)必要です。 -##### `cert_path` {#cert-path} +##### `cert_path` {#cert_path} - PEM 形式の X509 証明書が含まれるファイルのパス。 -##### `key_path` {#key-path} +##### `key_path` {#key_path} - PEM 形式の X509 キーを含むファイルのパス。 -### tiflash-learner.tomlファイルを設定する {#configure-the-code-tiflash-learner-toml-code-file} +### tiflash-learner.tomlファイルを設定する {#configure-the-tiflash-learnertoml-file} `tiflash-learner.toml`のパラメータは基本的にTiKVと同じです。TiFlashの設定については[TiKV構成](/tikv-configuration-file.md)参照してください。以下はよく使用されるパラメータのみを示しています。ご注意ください。 - TiKV と比較して、 TiFlash Proxy には[`raftstore.snap-handle-pool-size`](#snap-handle-pool-size-new-in-v400)追加パラメーターがあります。 - キーが`engine`の`label`は予約されており、手動で設定することはできません。 -#### ログ {#log} +#### ログ {#log-1} ##### `level` v5.4.0 の新機能 {#level-new-in-v540} @@ -504,7 +504,7 @@ I/O トラフィック制限設定を構成します。 - デフォルト値: `"info"` - `"info"` `"debug"` `"error"` `"warn"` `"trace"` -#### ログファイル {#log-file} +#### ログファイル {#logfile} ##### `max-backups` 5.4.0の新機能 {#max-backups-new-in-v540} @@ -550,7 +550,7 @@ I/O トラフィック制限設定を構成します。 - 構成項目が`true`または`"on"`に設定されている場合、ログ内のすべてのユーザー データは`?`に置き換えられます。 - 設定項目を`"marker"`に設定すると、ログ内のすべてのユーザーデータは`‹ ›`で囲まれます。ユーザーデータに`‹`または`›`が含まれている場合、 `‹`は`‹‹`に、 `›`は`››`にエスケープされます。マークされたログに基づいて、ログを表示する際にマークされた情報を非感度化するかどうかを決定できます。 -#### セキュリティ.暗号化 {#security-encryption} +#### セキュリティ.暗号化 {#securityencryption} ##### `data-encryption-method` {#data-encryption-method} @@ -563,11 +563,11 @@ I/O トラフィック制限設定を構成します。 - データ暗号化キーをローテーションする頻度を指定します。 - デフォルト値: `7d` -#### セキュリティ.暗号化.マスターキー {#security-encryption-master-key} +#### セキュリティ.暗号化.マスターキー {#securityencryptionmaster-key} - 暗号化が有効になっている場合、マスターキーを指定します。マスターキーの設定方法については、 [暗号化を設定する](/encryption-at-rest.md#configure-encryption)参照してください。 -#### セキュリティ.暗号化.以前のマスターキー {#security-encryption-previous-master-key} +#### セキュリティ.暗号化.以前のマスターキー {#securityencryptionprevious-master-key} - 新しいマスターキーをローテーションする際に使用する古いマスターキーを指定します。設定形式は`master-key`と同じです。マスターキーの設定方法については、 [暗号化を設定する](/encryption-at-rest.md#configure-encryption)参照してください。 diff --git a/tiflash/tune-tiflash-performance.md b/tiflash/tune-tiflash-performance.md index 9b4d1a1f228f5..db2310f4c1b00 100644 --- a/tiflash/tune-tiflash-performance.md +++ b/tiflash/tune-tiflash-performance.md @@ -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`演算で処理されるデータを削減でき、パフォーマンスが向上します。 @@ -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にプッシュダウンできるため、クエリパフォーマンスが向上します。 @@ -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ノード上の特定のテーブルまたはパーティションのコンパクションが開始されます。コンパクション中は、ノード上の物理データが書き換えられ、削除された行のクリーンアップや、更新によって発生した複数のデータバージョンのマージなどが含まれます。これにより、アクセスパフォーマンスが向上し、ディスク使用量が削減されます。以下に例を示します。 @@ -353,7 +353,7 @@ 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)設定することで、ウィンドウ関数の実行における同時実行性を高めることができます。これにより、ウィンドウ関数の実行により多くのシステムリソースが使用されるようになり、クエリのパフォーマンスが向上します。 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 4373ac825acee..f3cfb4b1b0ebd 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -74,7 +74,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも - オプション値: `true` 、 `false` - デフォルト値: `true` -## log.file v5.4.0で追加 {#log-file-new-in-v540} +## log.file v5.4.0で追加 {#logfile-new-in-v540} - ログファイルに関連するコンフィグレーション項目。 @@ -83,7 +83,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも - ログファイル。この設定項目が設定されていない場合、ログはデフォルトで「stderr」に出力されます。この設定項目が設定されている場合、ログは対応するファイルに出力されます。 - デフォルト値: `""` -### max-size v5.4.0の新機能 {#code-max-size-code-span-class-version-mark-new-in-v5-4-0-span} +### max-size v5.4.0の新機能 {#max-size-new-in-v540} - 単一ログファイルの最大サイズ。ファイルサイズがこの設定項目で設定された値よりも大きい場合、システムは自動的に単一ファイルを複数のファイルに分割します。 - デフォルト値: `300` @@ -309,7 +309,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも - デフォルト値: `100ms` - 値の範囲: `0`または`[10ms, +∞)` -## readpool.unified {#readpool-unified} +## readpool.unified {#readpoolunified} 読み取り要求を処理するシングルスレッドプールに関連するコンフィグレーション項目。このスレッドプールは、バージョン4.0以降、従来のストレージスレッドプールとコプロセッサスレッドプールに取って代わるものです。 @@ -328,7 +328,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも > > スレッド数を増やすとコンテキストスイッチの回数が増え、パフォーマンスが低下する可能性があります。この設定項目の値を変更することは推奨されません。 -### `stack-size` {#stack-size} +### `stack-size` {#stack-size-1} - 統合スレッドプール内のスレッドのスタックサイズ - 型: 整数 + 単位 @@ -363,52 +363,52 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも - 値の範囲: `[0.0, 1.0]` -## readpool.storage {#readpool-storage} +## readpool.storage {#readpoolstorage} ストレージスレッドプールに関連するコンフィグレーション項目。 -### `use-unified-pool` {#use-unified-pool} +### `use-unified-pool` {#use-unified-pool-1} - storage要求に統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメーターの値が`false`の場合、このセクションの残りのパラメーター（ `readpool.storage` ）で構成された別のスレッドプールが使用されます。 - デフォルト値: このセクション ( `readpool.storage` ) に他の設定がない場合、デフォルト値は`true`です。それ以外の場合は、下位互換性のために、デフォルト値は`false`です。このオプションを有効にする前に、必要に応じて[`readpool.unified`](#readpoolunified)の設定を変更してください。 -### `high-concurrency` {#high-concurrency} +### `high-concurrency` {#high-concurrency-1} - 優先度の高い`read`リクエストを処理する同時実行スレッドの許容数 - `8` ≤ `cpu num` ≤ `16`の場合、デフォルト値は`cpu_num * 0.5`です。 `cpu num`が`8`より小さい場合、デフォルト値は`4`です。 `cpu num`が`16`より大きい場合、デフォルト値は`8`です。 - 最小値: `1` -### `normal-concurrency` {#normal-concurrency} +### `normal-concurrency` {#normal-concurrency-1} - 通常優先度`read`リクエストを処理する同時実行スレッドの許容数 - `8` ≤ `cpu num` ≤ `16`の場合、デフォルト値は`cpu_num * 0.5`です。 `cpu num`が`8`より小さい場合、デフォルト値は`4`です。 `cpu num`が`16`より大きい場合、デフォルト値は`8`です。 - 最小値: `1` -### `low-concurrency` {#low-concurrency} +### `low-concurrency` {#low-concurrency-1} - 優先度の低い`read`リクエストを処理する同時実行スレッドの許容数 - `8` ≤ `cpu num` ≤ `16`の場合、デフォルト値は`cpu_num * 0.5`です。 `cpu num`が`8`より小さい場合、デフォルト値は`4`です。 `cpu num`が`16`より大きい場合、デフォルト値は`8`です。 - 最小値: `1` -### `max-tasks-per-worker-high` {#max-tasks-per-worker-high} +### `max-tasks-per-worker-high` {#max-tasks-per-worker-high-1} - 高優先度スレッドプール内の単一スレッドで許可されるタスクの最大数。この値を超えると、 `Server Is Busy`が返されます。 - デフォルト値: `2000` - 最小値: `2` -### `max-tasks-per-worker-normal` {#max-tasks-per-worker-normal} +### `max-tasks-per-worker-normal` {#max-tasks-per-worker-normal-1} - 通常優先度スレッドプールにおいて、1つのスレッドで実行可能なタスクの最大数。この値を超えると、 `Server Is Busy`が返されます。 - デフォルト値: `2000` - 最小値: `2` -### `max-tasks-per-worker-low` {#max-tasks-per-worker-low} +### `max-tasks-per-worker-low` {#max-tasks-per-worker-low-1} - 低優先度スレッドプール内の単一スレッドで許可されるタスクの最大数。この値を超えると`Server Is Busy`が返されます。 - デフォルト値: `2000` - 最小値: `2` -### `stack-size` {#stack-size} +### `stack-size` {#stack-size-2} - ストレージ読み取りスレッドプール内のスレッドのスタックサイズ - 型: 整数 + 単位 @@ -417,7 +417,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも - 最小値: `"2MiB"` - 最大値: システムで実行された`ulimit -sH`コマンドの結果として出力される Kバイト数。 -## `readpool.coprocessor` {#readpool-coprocessor} +## `readpool.coprocessor` {#readpoolcoprocessor} コプロセッサースレッドプールに関連するコンフィグレーション項目。 @@ -571,11 +571,11 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも - TiKVにおけるトランザクションステータスキャッシュの容量を設定します。このパラメータは変更しないでください。 - デフォルト値: `5120000` -## storage.block-cache {#storage-block-cache} +## storage.block-cache {#storageblock-cache} 複数の RocksDBカラムファミリー (CF) 間でブロックキャッシュを共有することに関連するコンフィグレーション項目。 -### `capacity` {#capacity} +### `capacity` {#capacity-1} - 共有ブロックキャッシュのサイズ。 @@ -591,11 +591,11 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも - Titanコンポーネントが使用できるブロックキャッシュ全体の割合を制御します。 - デフォルト値: `0.2` -## storage.flow-control {#storage-flow-control} +## storage.flow-control {#storageflow-control} TiKVにおけるフロー制御メカニズムに関連するコンフィグレーション項目。このメカニズムはRocksDBの書き込み停止メカニズムに代わるもので、スケジューラレイヤーでのフローを制御することで、 RaftstoreやApplyスレッドの停止によって引き起こされる二次的な障害を回避します。 -### `enable` {#enable} +### `enable` {#enable-1} - フロー制御メカニズムを有効にするかどうかを決定します。有効にすると、TiKV は KvDB の書き込み停止メカニズムと RaftDB の書き込み停止メカニズム (memtable を除く) を自動的に無効にします。 - デフォルト値: `true` @@ -615,7 +615,7 @@ TiKVにおけるフロー制御メカニズムに関連するコンフィグレ - デフォルト値: `20` -### `soft-pending-compaction-bytes-limit` {#soft-pending-compaction-bytes-limit} +### `soft-pending-compaction-bytes-limit` {#soft-pending-compaction-bytes-limit-1} - KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し始め、 `ServerIsBusy`エラーを報告します。 @@ -625,12 +625,12 @@ TiKVにおけるフロー制御メカニズムに関連するコンフィグレ - デフォルト値: `"192GiB"` -### `hard-pending-compaction-bytes-limit` {#hard-pending-compaction-bytes-limit} +### `hard-pending-compaction-bytes-limit` {#hard-pending-compaction-bytes-limit-1} - KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。 `enable`が`true`に設定されている場合、この構成項目は`rocksdb.(defaultcf|writecf|lockcf).hard-pending-compaction-bytes-limit`を上書きします。 - デフォルト値: `"1024GiB"` -## storage.io-rate-limit {#storage-io-rate-limit} +## storage.io-rate-limit {#storageio-rate-limit} I/Oレートリミッターに関連するコンフィグレーション項目。 @@ -645,7 +645,7 @@ I/Oレートリミッターに関連するコンフィグレーション項目 - 値のオプション: `"read-only"` 、 `"write-only"` 、および`"all-io"` - デフォルト値: `"write-only"` -## storage.max-ts {#storage-max-ts} +## storage.max-ts {#storagemax-ts} `max-ts` に関連する設定項目です。 @@ -1303,7 +1303,7 @@ Raftstoreに関連するコンフィグレーション項目。 RocksDBに関連するコンフィグレーション項目 -### `max-background-jobs` {#max-background-jobs} +### `max-background-jobs` {#max-background-jobs-1} - RocksDB のバックグラウンド スレッドの数。 RocksDB スレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 - デフォルト値: @@ -1321,26 +1321,26 @@ RocksDBに関連するコンフィグレーション項目 - CPUコア数が`N`の場合、デフォルト値は`[(max-background-jobs + 3) / 4]`です。 - 最小値: `1` -### `max-sub-compactions` {#max-sub-compactions} +### `max-sub-compactions` {#max-sub-compactions-1} - RocksDBで同時に実行されたサブコンパクション操作の数 - デフォルト値: `3` - 最小値: `1` -### `max-open-files` {#max-open-files} +### `max-open-files` {#max-open-files-1} - RocksDBが開くことができるファイルの総数 - デフォルト値: `40960` - 最小値: `-1` -### `max-manifest-file-size` {#max-manifest-file-size} +### `max-manifest-file-size` {#max-manifest-file-size-1} - RocksDBマニフェストファイルの最大サイズ - デフォルト値: `"256MiB"` 。v8.5.3 およびそれ以前の v8.5.x バージョンでは、デフォルト値は`"128MiB"`です。 - 最小値: `0` - 単位: B|KiB|MiB|GiB -### `create-if-missing` {#create-if-missing} +### `create-if-missing` {#create-if-missing-1} - DBスイッチを自動的に作成するかどうかを決定します - デフォルト値: `true` @@ -1355,26 +1355,26 @@ RocksDBに関連するコンフィグレーション項目 - `"skip-any-corrupted-records"` :ディザスタリカバリ。データは可能な限り復旧され、破損したレコードはスキップされます。 - デフォルト値: `"point-in-time"` -### `wal-dir` {#wal-dir} +### `wal-dir` {#wal-dir-1} - WALファイルが保存されるディレクトリ。指定しない場合、WALファイルはデータと同じディレクトリに保存されます。 - デフォルト値: `""` -### `wal-ttl-seconds` {#wal-ttl-seconds} +### `wal-ttl-seconds` {#wal-ttl-seconds-1} - アーカイブされたWALファイルの有効期間。この値を超えると、システムはこれらのファイルを削除します。 - デフォルト値: `0` - 最小値: `0` - 単位：秒 -### `wal-size-limit` {#wal-size-limit} +### `wal-size-limit` {#wal-size-limit-1} - アーカイブされたWALファイルのサイズ制限。この値を超えると、システムはこれらのファイルを削除します。 - デフォルト値: `0` - 最小値: `0` - 単位: B|KiB|MiB|GiB -### `max-total-wal-size` {#max-total-wal-size} +### `max-total-wal-size` {#max-total-wal-size-1} - RocksDB WAL の最大サイズは合計で、 `*.log`内の`data-dir`ファイルのサイズです。 - デフォルト値: @@ -1382,7 +1382,7 @@ RocksDBに関連するコンフィグレーション項目 - `storage.engine="raft-kv"`の場合、デフォルト値は`"4GiB"`です。 - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`1`です。 -### `stats-dump-period` {#stats-dump-period} +### `stats-dump-period` {#stats-dump-period-1} - 統計情報がログに出力される間隔。 - デフォルト値: @@ -1390,21 +1390,21 @@ RocksDBに関連するコンフィグレーション項目 - `storage.engine="raft-kv"`の場合、デフォルト値は`"10m"`です。 - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`"0"`です。 -### `compaction-readahead-size` {#compaction-readahead-size} +### `compaction-readahead-size` {#compaction-readahead-size-1} - RocksDBの圧縮処理中に先読み機能を有効にし、先読みデータのサイズを指定します。機械式ディスクを使用している場合は、少なくとも2MiBに設定することをお勧めします。 - デフォルト値: `0` - 最小値: `0` - 単位: B|KiB|MiB|GiB -### `writable-file-max-buffer-size` {#writable-file-max-buffer-size} +### `writable-file-max-buffer-size` {#writable-file-max-buffer-size-1} - WritableFileWriteで使用される最大バッファサイズ - デフォルト値: `"1MiB"` - 最小値: `0` - 単位: B|KiB|MiB|GiB -### `use-direct-io-for-flush-and-compaction` {#use-direct-io-for-flush-and-compaction} +### `use-direct-io-for-flush-and-compaction` {#use-direct-io-for-flush-and-compaction-1} - バックグラウンドのフラッシュと圧縮における読み取りと書き込みの両方で`O_DIRECT`を使用するかどうかを決定します。このオプションのパフォーマンスへの影響: `O_DIRECT`を有効にすると、OS バッファ キャッシュの汚染がバイパスされ防止されますが、後続のファイル読み取りではバッファ キャッシュの内容を再読み込みする必要があります。 - デフォルト値: `false` @@ -1432,26 +1432,26 @@ RocksDBに関連するコンフィグレーション項目 - 最近のワークロードに基づいて、RocksDBの圧縮レート制限設定を自動的に最適化するかどうかを決定します。この設定を有効にすると、圧縮待ちバイト数が通常よりも若干多くなります。 - デフォルト値: `true` -### `enable-pipelined-write` {#enable-pipelined-write} +### `enable-pipelined-write` {#enable-pipelined-write-1} - パイプライン書き込みを有効にするかどうかを制御します。この設定を有効にすると、従来のパイプライン書き込みが使用されます。この設定を無効にすると、新しいパイプラインコミットメカニズムが使用されます。 - デフォルト値: `false` -### `bytes-per-sync` {#bytes-per-sync} +### `bytes-per-sync` {#bytes-per-sync-1} - OSがファイルをディスクに増分的に同期する速度（これらのファイルが非同期的に書き込まれている間） - デフォルト値: `"1MiB"` - 最小値: `0` - 単位: B|KiB|MiB|GiB -### `wal-bytes-per-sync` {#wal-bytes-per-sync} +### `wal-bytes-per-sync` {#wal-bytes-per-sync-1} - OSがWALファイルの書き込み中にWALファイルをディスクに増分同期する速度 - デフォルト値: `"512KiB"` - 最小値: `0` - 単位: B|KiB|MiB|GiB -### `info-log-max-size` {#info-log-max-size} +### `info-log-max-size` {#info-log-max-size-1} > **Warning:** > @@ -1462,7 +1462,7 @@ RocksDBに関連するコンフィグレーション項目 - 最小値: `0` - 単位: B|KiB|MiB|GiB -### `info-log-roll-time` {#info-log-roll-time} +### `info-log-roll-time` {#info-log-roll-time-1} > **Warning:** > @@ -1471,7 +1471,7 @@ RocksDBに関連するコンフィグレーション項目 - Infoログが切り捨てられる時間間隔。値が`0s`の場合、ログは切り捨てられません。 - デフォルト値: `"0s"` -### `info-log-keep-log-file-num` {#info-log-keep-log-file-num} +### `info-log-keep-log-file-num` {#info-log-keep-log-file-num-1} > **Warning:** > @@ -1481,12 +1481,12 @@ RocksDBに関連するコンフィグレーション項目 - デフォルト値: `10` - 最小値: `0` -### `info-log-dir` {#info-log-dir} +### `info-log-dir` {#info-log-dir-1} - ログが保存されるディレクトリ - デフォルト値: `""` -### `info-log-level` {#info-log-level} +### `info-log-level` {#info-log-level-1} > **Warning:** > @@ -1536,7 +1536,7 @@ RocksDBに関連するコンフィグレーション項目 - RocksDBの書き込み最適化を有効にするかどうかを制御します。有効にすると、WriteBatchの内容をmemtableに同時に書き込むことができ、書き込みレイテンシーが削減されます。 - デフォルト値：なし。ただし、 `false`に明示的に設定するか、 `rocksdb.enable-pipelined-write`または`rocksdb.enable-unordered-write`有効になっている場合を除き、デフォルトで有効になります。 -## rocksdb.titan {#rocksdb-titan} +## rocksdb.titan {#rocksdbtitan} Titanに関連するコンフィグレーション項目。 @@ -1567,7 +1567,7 @@ Titanに関連するコンフィグレーション項目。 - デフォルト値: `1` 。v8.0.0 より前のバージョンでは、デフォルト値は`4`です。 - 最小値: `1` -## rocksdb.defaultcf | rocksdb.writecf | rocksdb.lockcf | rocksdb.raftcf {#rocksdb-defaultcf-rocksdb-writecf-rocksdb-lockcf-rocksdb-raftcf} +## rocksdb.defaultcf | rocksdb.writecf | rocksdb.lockcf | rocksdb.raftcf {#rocksdbdefaultcf--rocksdbwritecf--rocksdblockcf--rocksdbraftcf} `rocksdb.defaultcf` 、 `rocksdb.writecf` 、および`rocksdb.lockcf`に関連するコンフィグレーション項目。 @@ -1835,7 +1835,7 @@ Titanに関連するコンフィグレーション項目。 - 同時実行可能な圧縮タスクの最大数。値`0`は制限なしを意味します。 - デフォルト値: `0` -## rocksdb.defaultcf.titan {#rocksdb-defaultcf-titan} +## rocksdb.defaultcf.titan {#rocksdbdefaultcftitan} > **Note:** > @@ -2041,7 +2041,7 @@ Titanに関連するコンフィグレーション項目。 - 同時memtable書き込みを有効にするかどうかを制御します。 - デフォルト値: `true` -### `bytes-per-sync` {#bytes-per-sync} +### `bytes-per-sync` {#bytes-per-sync-2} - ファイルが非同期的に書き込まれている間に、OSがファイルをディスクに増分的に同期する速度 - デフォルト値: `"1MiB"` @@ -2108,7 +2108,7 @@ Raft Engineに関連するコンフィグレーション項目。 > - Raft Engineを初めて有効にすると、TiKVはRocksDBからRaft Engineにデータを転送します。そのため、TiKVが起動するまで数十秒余分に待つ必要があります。 > - TiDB v5.4.0 のRaft Engineのデータ形式は、以前の TiDB バージョンと互換性がありません。そのため、TiDB クラスタを v5.4.0 から以前のバージョンにダウングレードする必要がある場合は、ダウングレードする**前に**、 `enable`を`false`に設定してRaft Engine を無効にし、TiKV を再起動して設定を有効にしてください。 -### `enable` {#enable} +### `enable` {#enable-2} - Raftログを保存するためにRaft Engineを使用するかどうかを決定します。有効にすると、 `raftdb`の設定は無視されます。 - デフォルト値: `true` @@ -2259,7 +2259,7 @@ Raft Engineに関連するコンフィグレーション項目。 - デフォルト値: `false` - 詳しい使い方は[TiKV側でのログ編集](/log-redaction.md#log-redaction-in-tikv-side)をご覧ください。 -## セキュリティ暗号化 {#security-encryption} +## セキュリティ暗号化 {#securityencryption} [保存時の暗号化](/encryption-at-rest.md)(TDE)に関するコンフィグレーション項目。 @@ -2293,7 +2293,7 @@ Raft Engineに関連するコンフィグレーション項目。 TiDB LightningのインポートおよびBR復元に関連するコンフィグレーション項目。 -### `num-threads` {#num-threads} +### `num-threads` {#num-threads-1} - RPCリクエストを処理するスレッド数 - デフォルト値: `8` @@ -2342,7 +2342,7 @@ TiDB LightningのインポートおよびBR復元に関連するコンフィグ - `enable-compaction-filter`が`false`の場合の GC スレッドの数。 - デフォルト値: `1` -## gc.自動圧縮 {#gc-auto-compaction} +## gc.自動圧縮 {#gcauto-compaction} TiKVの自動圧縮の動作を設定します。 @@ -2440,7 +2440,7 @@ BRバックアップに関連するコンフィグレーション項目。 - データが S3 にバックアップされ、バックアップ ファイルがこの設定項目の値より大きい場合、 [マルチパートアップロード](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPart.html)が自動的に有効になります。圧縮率に基づいて、96 MiBリージョンによって生成されるバックアップ ファイルは約 10 MiB ～ 30 MiB になります。 - デフォルト値: 5MiB -### `gcp-v2-enable` New in v8.5.7 {#gcp-v2-enable-new-in-v857} +### `gcp-v2-enable` New in v8.5.7 {#gcp-v2-enable-new-in-v857-1} + Google Cloud Storage (GCS) を使用してフルバックアップまたはリストアを実行する際に、`gcp_v2` 外部ストレージバックエンドを有効にするかどうかを指定します。 + デフォルト値: `true` @@ -2448,7 +2448,7 @@ BRバックアップに関連するコンフィグレーション項目。 + フルバックアップまたはリストアのシナリオで Google Cloud Workload Identity Federation (WIF) を使用する必要がある場合は、この設定項目を `true` に設定したままにしてください。 + GCS の認証方法および WIF/ADC の使用方法については、[バックアップストレージ](/br/backup-and-restore-storages.md) を参照してください。 -## backup.hadoop {#backup-hadoop} +## backup.hadoop {#backuphadoop} ### `home` {#home} @@ -2846,7 +2846,7 @@ TiKVストレージレイヤーのリソース制御に関連するコンフィ - [`region-split-size`](#region-split-size) 4 GiB 未満の場合、 `0.25` 。 - [`region-split-size`](#region-split-size)が 4 GiB 以上の場合`0.75` 。 -## メモリv7.5.0の新機能 {#memory-span-class-version-mark-new-in-v7-5-0-span} +## メモリv7.5.0の新機能 {#memory-new-in-v750} ### `enable-heap-profiling` v7.5.0の新機能 {#enable-heap-profiling-new-in-v750} @@ -2863,7 +2863,7 @@ TiKVストレージレイヤーのリソース制御に関連するコンフィ - TiKVスレッドレベルでメモリ割り当て状況を表示して、各TiKVスレッドのメモリ使用量を追跡するかどうかを制御します。 - デフォルト値: `true` -## インメモリエンジンv8.5.0の新機能 {#in-memory-engine-span-class-version-mark-new-in-v8-5-0-span} +## インメモリエンジンv8.5.0の新機能 {#in-memory-engine-new-in-v850} TiKV MVCC インメモリエンジン (IME) のストレージレイヤーに関連する構成項目。 @@ -2878,7 +2878,7 @@ TiKV MVCC インメモリエンジン (IME) のストレージレイヤーに関 - TiKVノードには最低でも8GiBのメモリを搭載することを推奨します。最適なパフォーマンスを得るには、32GiB以上を搭載することをお勧めします。 - TiKVノードで使用可能なメモリが不足している場合、この設定項目が`true`に設定されていても、インメモリエンジンは有効になりません。このような場合は、TiKVログファイルで`"in-memory engine is disabled because"`を含むメッセージを確認し、インメモリエンジンが有効にならない理由を調べてください。 -### capacity （v8.5.0の新機能） {#code-capacity-code-span-class-version-mark-new-in-v8-5-0-span} +### capacity （v8.5.0の新機能） {#capacity-new-in-v850} > **Note:** > diff --git a/tikv-control.md b/tikv-control.md index d73cd7fbbc448..a79d5e444f3a9 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -346,7 +346,7 @@ tikv-ctl --data-dir /path/to/tikv tombstone -p 127.0.0.1:2379 -r , - `tombstone`コマンドはローカル モードのみをサポートします。 > - `-p`オプションの引数は、 `http`プレフィックスのない PD エンドポイントを指定します。PD エンドポイントを指定するのは、PD が安全に Tombstone に切り替えられるかどうかを照会するためです。 -### TiKVにconsistency-checkリクエストを送信する {#send-a-code-consistency-check-code-request-to-tikv} +### TiKVにconsistency-checkリクエストを送信する {#send-a-consistency-check-request-to-tikv} `consistency-check`コマンドを使用して、特定のリージョンの対応するRaft内のレプリカ間の整合性チェックを実行します。チェックが失敗した場合、TiKV 自体がパニック状態になります`--host`で指定された TiKV インスタンスがリージョンリーダーでない場合は、エラーが報告されます。 @@ -602,7 +602,7 @@ tikv-ctl --data-dir bad-ssts --pd - `overlap region`番目の部分は、関係するリージョンの情報を示しています。この情報はPDサーバーから取得されます。 - パート`suggested operations` 、破損したSSTファイルをクリーンアップするための提案が示されています。この提案に従ってファイルをクリーンアップし、TiKVインスタンスを再起動してください。 -### リージョンのRegionReadProgressの状態を取得する {#get-the-state-of-a-region-s-code-regionreadprogress-code} +### リージョンのRegionReadProgressの状態を取得する {#get-the-state-of-a-regions-regionreadprogress} v6.5.4およびv7.3.0以降、TiKVはリゾルバの最新の詳細情報を取得するためのサブコマンド`get-region-read-progress`と`RegionReadProgress`導入しました。リージョンIDとTiKVを指定する必要があります。これらはGrafana（ `Min Resolved TS Region`と`Min Safe TS Region` ）または`DataIsNotReady`ログから取得できます。 diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index 995fb626e64a0..efa04b1d0be38 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -127,7 +127,7 @@ monitored: 上記の構成では、 `node_exporter` `9100`ポートを使用し、 `blackbox_exporter` `9115`ポートを使用するように指定しています。 -### `server_configs` {#server-configs} +### `server_configs` {#server_configs} `server_configs` 、サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。2 `global`と同様に、このセクションの設定は、インスタンス内の同名の設定によって上書きできます。4 `server_configs`は主に以下のフィールドが含まれます。 @@ -165,7 +165,7 @@ server_configs: 上記の構成は、TiDB と TiKV のグローバル構成を指定します。 -### `component_versions` {#component-versions} +### `component_versions` {#component_versions} > **Note:** > @@ -202,7 +202,7 @@ component_versions: 上記の構成では、TiKV-CDC のバージョン番号を`v1.1.1`に指定しています。 -### `pd_servers` {#pd-servers} +### `pd_servers` {#pd_servers} `pd_servers` 、PD サービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します`pd_servers`は配列であり、配列の各要素には以下のフィールドが含まれます。 @@ -260,7 +260,7 @@ pd_servers: 上記の構成では、 PD が`10.0.1.11`と`10.0.1.12`に展開されることを指定し、 `10.0.1.11`の PD に対して特定の構成を作成します。 -### `tidb_servers` {#tidb-servers} +### `tidb_servers` {#tidb_servers} `tidb_servers` TiDB サービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します`tidb_servers`は配列であり、配列の各要素には以下のフィールドが含まれます。 @@ -310,7 +310,7 @@ tidb_servers: - host: 10.0.1.15 ``` -### `tikv_servers` {#tikv-servers} +### `tikv_servers` {#tikv_servers} `tikv_servers` TiKV サービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します`tikv_servers`は配列であり、配列の各要素には以下のフィールドが含まれます。 @@ -364,7 +364,7 @@ tikv_servers: server.labels: { zone: "zone1", host: "host2" } ``` -### `tiflash_servers` {#tiflash-servers} +### `tiflash_servers` {#tiflash_servers} `tiflash_servers` 、 TiFlashサービスが展開されるマシンを指定します。また、各マシンにおけるサービス構成も指定します。このセクションは配列であり、配列の各要素には以下のフィールドが含まれます。 @@ -424,7 +424,7 @@ tiflash_servers: - host: 10.0.1.22 ``` -### `tiproxy_servers` {#tiproxy-servers} +### `tiproxy_servers` {#tiproxy_servers} `tiproxy_servers` 、TiProxy サービスが展開されるマシンと、各マシン上のサービスの構成を指定します。2 `tiproxy_servers`配列であり、配列の各要素には次のフィールドが含まれます。 @@ -472,7 +472,7 @@ tiproxy_servers: その他の構成例については、 [TiProxy 展開トポロジ](/tiproxy/tiproxy-deployment-topology.md)参照してください。 -### `kvcdc_servers` {#kvcdc-servers} +### `kvcdc_servers` {#kvcdc_servers} `kvcdc_servers` 、 [TiKV-CDC](https://tikv.org/docs/7.1/concepts/explore-tikv-features/cdc/cdc/)サービスがデプロイされるマシンを指定します。また、各マシンにおけるサービス構成も指定します`kvcdc_servers`は配列です。各配列要素には、以下のフィールドが含まれます。 @@ -520,7 +520,7 @@ kvcdc_servers: - host: 10.0.1.22 ``` -### `cdc_servers` {#cdc-servers} +### `cdc_servers` {#cdc_servers} `cdc_servers` TiCDCサービスがデプロイされるマシンを指定します。また、各マシンにおけるサービス構成も指定します`cdc_servers`は配列です。各配列要素には以下のフィールドが含まれます。 @@ -575,7 +575,7 @@ cdc_servers: data_dir: "/cdc-data" ``` -### `tso_servers` {#tso-servers} +### `tso_servers` {#tso_servers} `tso_servers` 、 `tso`マイクロサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。4 `tso_servers`配列であり、配列の各要素には以下のフィールドが含まれます。 @@ -605,7 +605,7 @@ tso_servers: - host: 10.0.1.22 ``` -### `scheduling_servers` {#scheduling-servers} +### `scheduling_servers` {#scheduling_servers} `scheduling_servers` 、 `scheduling`マイクロサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。4 `scheduling_servers`配列であり、配列の各要素には以下のフィールドが含まれます。 @@ -635,7 +635,7 @@ scheduling_servers: - host: 10.0.1.22 ``` -### `monitoring_servers` {#monitoring-servers} +### `monitoring_servers` {#monitoring_servers} `monitoring_servers` 、Prometheus サービスがデプロイされるマシンを指定します。また、各マシンのサービス設定も指定します`monitoring_servers`は配列です。各配列要素には以下のフィールドが含まれます。 @@ -710,7 +710,7 @@ monitoring_servers: web_port: 9094 ``` -### `grafana_servers` {#grafana-servers} +### `grafana_servers` {#grafana_servers} `grafana_servers` 、Grafana サービスがデプロイされるマシンを指定します。また、各マシンにおけるサービス設定も指定します`grafana_servers`は配列です。各配列要素には以下のフィールドが含まれます。 @@ -759,7 +759,7 @@ grafana_servers: dashboard_dir: /local/dashboard/dir ``` -### `alertmanager_servers` {#alertmanager-servers} +### `alertmanager_servers` {#alertmanager_servers} `alertmanager_servers` 、Alertmanager サービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します`alertmanager_servers`は配列です。各配列要素には、以下のフィールドが含まれます。 diff --git a/tiup/tiup-component-cluster-reload.md b/tiup/tiup-component-cluster-reload.md index 0a8c5360c2d06..fda214c963c00 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 ``ユーザー設定に基づいて生成された設定ファイルです。このチェックをスキップしたい場合は、このオプションを使用できます。 - データ型: `BOOLEAN` - デフォルト: false -### -N, --node {#n-node} +### -N, --node {#-n---node} - 再起動するノードを指定します。指定しない場合は、すべてのノードが再起動されます。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 - データ型: `STRINGS` @@ -50,7 +50,7 @@ tiup cluster reload [flags] > - `-R, --role`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 > - オプション`--skip-restart`指定した場合、オプション`-N, --node`は無効になります。 -### -R, --role {#r-role} +### -R, --role {#-r---role} - 再起動するロールを指定します。指定しない場合は、すべてのロールが再起動されます。このオプションの値は、ノードロールのカンマ区切りのリストです。ロールは、表[クラスターステータス](/tiup/tiup-component-cluster-display.md)の2番目の列です。 - データ型: `STRINGS` @@ -61,7 +61,7 @@ tiup cluster reload [flags] > 1. `-N, --node`オプションを同時に指定した場合は、 `-N, --node`と`-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:** > @@ -89,7 +89,7 @@ tiup cluster reload [flags] - データ型: `STRINGS` - このオプションは、リロードするノードで実行されるスクリプトのパスを指定します。1 `--skip-restart` `true`に設定した場合は無効になります。 -### --post-restart-script {#post-restart-script} +### --post-restart-script {#--post-restart-script} > **Warning:** > diff --git a/tiup/tiup-component-cluster-upgrade.md b/tiup/tiup-component-cluster-upgrade.md index b23b2320d7efa..ec3a286747cb2 100644 --- a/tiup/tiup-component-cluster-upgrade.md +++ b/tiup/tiup-component-cluster-upgrade.md @@ -18,7 +18,7 @@ tiup cluster upgrade [flags] ## オプション {#options} -### --force {#force} +### --force {#--force} - クラスターをアップグレードするには、クラスターが現在起動していることを確認する必要があります。場合によっては、クラスターが起動していない状態でアップグレードを実行したい場合があります。その場合は、 `--force`使用すると、アップグレード中のエラーを無視し、バイナリファイルを強制的に置き換えてクラスターを起動できます。 - データ型: `BOOLEAN` @@ -28,7 +28,7 @@ tiup cluster upgrade [flags] > > サービスを提供しているクラスターを強制的にアップグレードすると、サービスが利用できなくなる可能性があります。アップグレードが成功すると、起動していないクラスターは自動的に起動されます。 -### --transfer-timeout {#transfer-timeout} +### --transfer-timeout {#--transfer-timeout} - PDまたはTiKVをアップグレードする場合、アップグレード対象ノードのリーダーノードが最初に他のノードに移行されます。移行プロセスには時間がかかります。1 `-transfer-timeout`で最大待機時間（秒単位）を設定できます。タイムアウト後、待機はスキップされ、サービスは直接アップグレードされます。 - データ型: `uint` @@ -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`オプションを使用します。 - データ型: `BOOLEAN` - デフォルト: false -### --ignore-version-check {#ignore-version-check} +### --ignore-version-check {#--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-cluster.md b/tiup/tiup-component-cluster.md index 6d614edd15e46..d499741eb3575 100644 --- a/tiup/tiup-component-cluster.md +++ b/tiup/tiup-component-cluster.md @@ -17,7 +17,7 @@ tiup cluster [command] [flags] ## オプション {#options} -### --ssh {#ssh} +### --ssh {#--ssh} - コマンド実行のためにリモート エンド (TiDB サービスがデプロイされているマシン) に接続する SSH クライアントを指定します。 @@ -31,30 +31,30 @@ tiup cluster [command] [flags] - コマンドでこのオプションを指定しない場合は、デフォルト値として`builtin`使用されます。 -### --sshタイムアウト {#ssh-timeout} +### --sshタイムアウト {#--ssh-timeout} - SSH 接続のタイムアウトを秒単位で指定します。 - データ型: `UINT` - コマンドでこのオプションを指定しない場合、デフォルトのタイムアウトは`5`秒になります。 -### --wait-timeout {#wait-timeout} +### --wait-timeout {#--wait-timeout} - 操作プロセスの各ステップの最大待機時間（秒単位）を指定します。操作プロセスは、systemctl によるサービスの開始または停止の指定、ポートのオンラインまたはオフラインの待機など、多くのステップで構成されます。各ステップは数秒かかる場合があります。ステップの実行時間が指定されたタイムアウトを超えた場合、そのステップはエラーで終了します。 - データ型: `UINT` - コマンドでこのオプションを指定しない場合、各ステップの最大待機時間は`120`秒になります。 -### -y, --はい {#y-yes} +### -y, --はい {#-y---yes} - すべてのリスクのある操作の2次確認をスキップします。スクリプトを使用してTiUPを呼び出す場合を除き、このオプションの使用は推奨されません。 - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 -### -v, --バージョン {#v-version} +### -v, --バージョン {#-v---version} - TiUP クラスタの現在のバージョンを出力します。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 -### -h, --help {#h-help} +### -h, --help {#-h---help} - 関連するコマンドのヘルプ情報を出力します。 - データ型: `BOOLEAN` diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 66a907642412f..92333783f79c4 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -61,7 +61,7 @@ global: この例では、構成により、クラスターを起動するために`tidb`ユーザーが使用され、各コンポーネントの実行時に最大 2 GB のメモリに制限されることが指定されています。 -### `server_configs` {#server-configs} +### `server_configs` {#server_configs} `server_configs` `server_configs`サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。2 セクションと同様に、 `global`セクションの設定は、インスタンス内の同じキーを持つ設定によって上書きできます。6 `server_configs`は主に以下のフィールドが含まれます。 @@ -81,7 +81,7 @@ server_configs: log-level: info ``` -## `master_servers` {#master-servers} +## `master_servers` {#master_servers} `master_servers` 、DMコンポーネントのマスターノードがデプロイされるマシンを指定します。また、各マシンのサービス構成を指定することもできます`master_servers`配列です。各配列要素には以下のフィールドが含まれます。 @@ -138,7 +138,7 @@ master_servers: name: master3 ``` -## `worker_servers` {#worker-servers} +## `worker_servers` {#worker_servers} `worker_servers` 、DMコンポーネントのマスターノードがデプロイされるマシンを指定します。また、各マシンのサービス構成を指定することもできます`worker_servers`配列です。各配列要素には以下のフィールドが含まれます。 @@ -182,7 +182,7 @@ worker_servers: - host: 10.0.1.19 ``` -### `monitoring_servers` {#monitoring-servers} +### `monitoring_servers` {#monitoring_servers} `monitoring_servers` 、Prometheus サービスがデプロイされるマシンを指定します。また、マシン上のサービス設定も指定できます`monitoring_servers`配列です。各配列要素には以下のフィールドが含まれます。 @@ -236,7 +236,7 @@ monitoring_servers: web_port: 9094 ``` -### `grafana_servers` {#grafana-servers} +### `grafana_servers` {#grafana_servers} `grafana_servers` 、Grafana サービスがデプロイされるマシンを指定します。また、マシン上のサービス設定も指定できます`grafana_servers`配列です。各配列要素には以下のフィールドが含まれます。 @@ -274,7 +274,7 @@ grafana_servers: dashboard_dir: /local/dashboard/dir ``` -### `alertmanager_servers` {#alertmanager-servers} +### `alertmanager_servers` {#alertmanager_servers} `alertmanager_servers` 、Alertmanagerサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成を指定することもできます`alertmanager_servers`は配列です。各配列要素には以下のフィールドが含まれます。 diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 3affeed9ad8ec..6bce09930fd3f 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -79,7 +79,7 @@ TiDBのコーディングルールによれば、同一テーブルのデータ ![Dashboard Example 4](/media/troubleshoot-hot-spot-issues-4.png) -## SHARD_ROW_ID_BITSを使用してホットスポットを処理する {#use-code-shard-row-id-bits-code-to-process-hotspots} +## SHARD_ROW_ID_BITSを使用してホットスポットを処理する {#use-shard_row_id_bits-to-process-hotspots} 非クラスター化主キーまたは主キーのないテーブルの場合、TiDBは暗黙的なAUTO_INCREMENT RowIDを使用します。1 `INSERT`操作が多数存在する場合、データは単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 @@ -108,7 +108,7 @@ ALTER TABLE: ALTER TABLE t SHARD_ROW_ID_BITS = 4; 上記の負荷図に示すように、設定`SHARD_ROW_ID_BITS`より前では、負荷のホットスポットが単一のリージョンに集中していました。設定`SHARD_ROW_ID_BITS`より後では、負荷のホットスポットが分散するようになります。 -## AUTO_RANDOMを使用してAUTO_INCREMENT主キー ホットスポット テーブルを処理する {#handle-auto-increment-primary-key-hotspot-tables-using-code-auto-random-code} +## AUTO_RANDOMを使用してAUTO_INCREMENT主キー ホットスポット テーブルを処理する {#handle-auto-increment-primary-key-hotspot-tables-using-auto_random} AUTO_INCREMENT主キーによってもたらされる書き込みホットスポットを解決するには、 `AUTO_RANDOM`使用して、AUTO_INCREMENT主キーを持つホットスポット テーブルを処理します。 diff --git a/tune-operating-system.md b/tune-operating-system.md index c1d76d1ca8d60..ab0a81ae5f404 100644 --- a/tune-operating-system.md +++ b/tune-operating-system.md @@ -37,7 +37,7 @@ summary: オペレーティング システムのパラメータを調整する perf は、Linux カーネルが提供する重要なパフォーマンス解析ツールです。ハードウェアレベル（CPU/PMU、パフォーマンス監視ユニット）の機能とソフトウェアレベル（ソフトウェアカウンタ、トレースポイント）の機能の両方をカバーしています。詳細な使用方法については、 [perf の例](http://www.brendangregg.com/perf.html#Background)参照してください。 -### BCC/bpftrace {#bcc-bpftrace} +### BCC/bpftrace {#bccbpftrace} CentOS 7.6以降、LinuxカーネルはBerkeley Packet Filter（BPF）をサポートしています。そのため、 [60秒で](#in-60-seconds)の結果に基づいて適切なツールを選択し、詳細な分析を行うことができます。perf/ftraceと比較すると、BPFはプログラマビリティが高く、パフォーマンスオーバーヘッドが少ないという利点があります。kprobeと比較すると、BPFはセキュリティが高く、本番環境に適しています。BCCツールキットの詳細な使用方法については、 [BPF コンパイラ コレクション (BCC)](https://github.com/iovisor/bcc/blob/master/README.md)参照してください。 @@ -45,11 +45,11 @@ CentOS 7.6以降、LinuxカーネルはBerkeley Packet Filter（BPF）をサポ このセクションでは、分類されたカーネル サブシステムに基づいたパフォーマンス チューニングについて説明します。 -### CPU—周波数スケーリング {#cpu-frequency-scaling} +### CPU—周波数スケーリング {#cpufrequency-scaling} cpufreq は、CPU周波数を動的に調整するモジュールです。5つのモードをサポートしています。サービスのパフォーマンスを確保するには、パフォーマンスモードを選択し、動的な調整を行わずにCPU周波数をサポートされている最高動作周波数に固定します。この操作を行うコマンドは`cpupower frequency-set --governor performance`です。 -### CPU—割り込み親和性 {#cpu-interrupt-affinity} +### CPU—割り込み親和性 {#cpuinterrupt-affinity} - `irqbalance`サービスを通じて自動バランスを実現できます。 - 手動バランス: @@ -62,7 +62,7 @@ cpufreq は、CPU周波数を動的に調整するモジュールです。5つ NUMA（Non-Uniform Memory Access）ノードをまたがるメモリを可能な限り回避するには、スレッド／プロセスを特定のCPUコアにバインドし、そのCPUアフィニティを設定することができます。通常のプログラムの場合、CPUバインドには`numactl`コマンドを使用できます。詳細な使用方法については、Linuxのマニュアルページを参照してください。ネットワークインターフェースカード（NIC）の割り込みについては、 [ネットワークを調整する](#network-tuning)参照してください。 -### メモリ - 透過的巨大ページ (THP) {#memory-transparent-huge-page-thp} +### メモリ - 透過的巨大ページ (THP) {#memorytransparent-huge-page-thp} データベースアプリケーションではTHPの使用は推奨**されません**。データベースは連続的なメモリアクセスパターンではなく、スパースなメモリアクセスパターンを持つことが多いためです。高レベルのメモリ断片化が深刻な場合、THPページ割り当て時にレイテンシーが増大します。THPでダイレクトコンパクションを有効にすると、CPU使用率が急上昇します。したがって、THPを無効にすることをお勧めします。 @@ -72,7 +72,7 @@ echo never > /sys/kernel/mm/transparent_hugepage/defrag grubby --update-kernel="$KERNEL" --args='transparent_hugepage=never' ``` -### メモリ - 仮想メモリパラメータ {#memory-virtual-memory-parameters} +### メモリ - 仮想メモリパラメータ {#memoryvirtual-memory-parameters} - `dirty_ratio`パーセント比。ダーティページキャッシュの総量がシステムメモリ全体のこのパーセント比に達すると、システムは`pdflush`オペレーションを使用してダーティページキャッシュをディスクに書き込みます。デフォルト値の`dirty_ratio`は 20% であり、通常は調整する必要はありません。NVMe デバイスなどの高性能 SSD の場合、この値を下げるとメモリ回収の効率が向上します。 - `dirty_background_ratio`パーセント比。ダーティページキャッシュの総量がシステムメモリ全体のこのパーセント比に達すると、システムはバックグラウンドでダーティページキャッシュをディスクに書き込み始めます。デフォルト値は`dirty_background_ratio`で、10% であり、通常は調整する必要はありません。NVMe デバイスなどの高性能 SSD の場合、値を低く設定するとメモリ回収の効率が向上します。 @@ -81,7 +81,7 @@ grubby --update-kernel="$KERNEL" --args='transparent_hugepage=never' コア I/O スタック リンクは、ファイル システムレイヤー、ブロック デバイスレイヤー、およびドライバーレイヤーを含めて長くなります。 -#### I/Oスケジューラ {#i-o-scheduler} +#### I/Oスケジューラ {#io-scheduler} I/Oスケジューラは、ストレージデバイス上でI/O操作を実行するタイミングと時間を決定します。I/Oエレベータとも呼ばれます。SSDデバイスの場合、I/Oスケジューリングポリシーを`noop`に設定することをお勧めします。 @@ -89,7 +89,7 @@ I/Oスケジューラは、ストレージデバイス上でI/O操作を実行 echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler ``` -#### フォーマットパラメータ - ブロックサイズ {#formatting-parameters-block-size} +#### フォーマットパラメータ - ブロックサイズ {#formatting-parametersblock-size} ブロックはファイルシステムの作業単位です。ブロックサイズは、1つのブロックに保存できるデータの量を決定し、それによって1回あたりに書き込んだり読み込んだりするデータの最小量を決定します。 @@ -97,7 +97,7 @@ echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler `mkfs`コマンドを使用してデバイスをフォーマットする場合、ファイルシステムオプションの一部としてブロックサイズを指定します。ブロックサイズを指定するパラメータはファイルシステムによって異なります。詳細については、対応する`mkfs`マニュアルページ（例： `man mkfs.ext4`を参照してください。 -#### mountパラメータ {#code-mount-code-parameters} +#### mountパラメータ {#mount-parameters} `mount`コマンドで`noatime`オプションが有効になっている場合、ファイルの読み取り時にメタデータの更新が無効になります。5 `nodiratime`動作が有効になっている場合、ディレクトリの読み取り時にメタデータの更新が無効になります。 diff --git a/tune-region-performance.md b/tune-region-performance.md index c88f79e82f68c..51d6530dde538 100644 --- a/tune-region-performance.md +++ b/tune-region-performance.md @@ -21,7 +21,7 @@ TiKVは自動的に[最下層のデータを分割する](/best-practices/tidb-b 多くのリージョンのパフォーマンスオーバーヘッドを削減するには、 [休止状態リージョン](/best-practices/massive-regions-best-practices.md#method-4-increase-the-number-of-tikv-instances)または[`Region Merge`](/best-practices/massive-regions-best-practices.md#method-5-adjust-raft-base-tick-interval)有効にすることもできます。 -## リージョンサイズを調整するには、 region-split-sizeを使用します。 {#use-code-region-split-size-code-to-adjust-region-size} +## リージョンサイズを調整するには、 region-split-sizeを使用します。 {#use-region-split-size-to-adjust-region-size} > **Note:** > @@ -41,7 +41,7 @@ TiKVは自動的に[最下層のデータを分割する](/best-practices/tidb-b リージョンのサイズを大きくした後、クエリの同時実行性をさらに向上させたい場合は、 [`coprocessor.enable-region-bucket`](/tikv-configuration-file.md#enable-region-bucket-new-in-v610)から`true`に設定できます。この設定では、リージョンがバケットに分割されます。バケットはリージョン内の小さな範囲であり、スキャンの同時実行性を向上させるための同時クエリの単位として使用されます。バケットサイズは[`coprocessor.region-bucket-size`](/tikv-configuration-file.md#region-bucket-size-new-in-v610)で制御できます。 -## アクティブPDFollower機能を使用して、PDのリージョン情報クエリサービスのスケーラビリティを強化します。 {#use-the-active-pd-follower-feature-to-enhance-the-scalability-of-pd-s-region-information-query-service} +## アクティブPDFollower機能を使用して、PDのリージョン情報クエリサービスのスケーラビリティを強化します。 {#use-the-active-pd-follower-feature-to-enhance-the-scalability-of-pds-region-information-query-service} 多数のリージョンを持つTiDBクラスターでは、ハートビート処理とタスクのスケジューリングによるオーバーヘッドの増加により、PDリーダーのCPU負荷が高くなる可能性があります。クラスターに多数のTiDBインスタンスがあり、リージョン情報へのリクエストが同時に発生すると、PDリーダーのCPU負荷がさらに高まり、PDサービスが利用できなくなる可能性があります。 diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index aedbcf6f2084a..e4b5bda2a1b75 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -284,7 +284,7 @@ tiup cluster display tiup cluster replay ``` -### バージョン6.2.0以降へのアップグレード時にアップグレード処理が停止してしまう問題を解決するにはどうすればよいですか？ {#how-to-fix-the-issue-that-the-upgrade-gets-stuck-when-upgrading-to-v6-2-0-or-later-versions} +### バージョン6.2.0以降へのアップグレード時にアップグレード処理が停止してしまう問題を解決するにはどうすればよいですか？ {#how-to-fix-the-issue-that-the-upgrade-gets-stuck-when-upgrading-to-v620-or-later-versions} バージョン6.2.0以降、TiDBはデフォルトで[並行DDLフレームワーク](/best-practices/ddl-introduction.md#how-the-online-ddl-asynchronous-change-works-in-tidb)を有効にし、同時DDLの実行を可能にしました。このフレームワークは、DDLジョブのストレージをKVキューからテーブルキューに変更します。この変更により、一部のシナリオではアップグレードが停止する可能性があります。この問題が発生する可能性のあるシナリオと、それに対応する解決策を以下に示します。 diff --git a/user-account-management.md b/user-account-management.md index c58f68b70055a..bf6486f9b916f 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -165,7 +165,7 @@ TiDBはパスワードを[`mysql.user`](/mysql-schema/mysql-schema-user.md)シ ALTER USER 'test'@'localhost' IDENTIFIED BY 'mypass'; ``` -## rootパスワードを忘れた {#forget-the-code-root-code-password} +## rootパスワードを忘れた {#forget-the-root-password} 1. 設定ファイルを変更します。