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