Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion analyze-slow-queries.md
Original file line number Diff line number Diff line change
Expand Up @@ -114,7 +114,7 @@ TiDB v8.5.0では、TiKV MVCCインメモリエンジン(IME)機能が導入

#### タイムスタンプの取得が遅い {#slow-in-getting-timestamps}

スローログで`Wait_TS`と`Query_time`比較できます。タイムスタンプはプリフェッチされるため、通常は`Wait_TS`値は低くなります
スローログで`Wait_TS`と`Query_time`を比較できます。タイムスタンプはプリフェッチされるため、通常は`Wait_TS`の値は低くなります

# Query_time: 0.0300000
...
Expand Down
2 changes: 1 addition & 1 deletion best-practices-for-security-configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -123,4 +123,4 @@ TiDB Dashboardにアクセスする必要がある場合は、 [リバースプ

ほとんどの脆弱性スキャナーは、MySQLの脆弱性をバージョン情報に基づいて検出します。TiDBはMySQLプロトコルと互換性がありますが、MySQL自体は互換性がないため、バージョンベースの脆弱性スキャンは誤検知につながる可能性があります。脆弱性スキャンは原則に基づく評価に重点を置くことをお勧めします。コンプライアンススキャンツールが特定のMySQLバージョンを要求する場合は、 [サーバーのバージョン番号を変更する](/faq/high-reliability-faq.md#does-tidb-support-modifying-the-mysql-version-string-of-the-server-to-a-specific-one-that-is-required-by-the-security-vulnerability-scanning-tool)使用して要件を満たすことができます。

サーバーのバージョン番号を変更することで、脆弱性スキャナーによる誤検知を回避できます。[`server-version`](/tidb-configuration-file.md#server-version)値は、TiDB ノードが現在の TiDB バージョンを確認するために使用されます。TiDB クラスターをアップグレードする前に、予期しない動作を回避するために、 `server-version`値が空であるか、実際の TiDB バージョンであることを確認してください。
サーバーのバージョン番号を変更することで、脆弱性スキャナーによる誤検知を回避できます。[`server-version`](/tidb-configuration-file.md#server-version)の値は、TiDB ノードが現在の TiDB バージョンを確認するために使用されます。TiDB クラスターをアップグレードする前に、予期しない動作を回避するために、 `server-version`の値が空であるか、実際の TiDB バージョンであることを確認してください。
2 changes: 1 addition & 1 deletion best-practices/grafana-monitor-best-practices.md
Original file line number Diff line number Diff line change
Expand Up @@ -73,7 +73,7 @@ Prometheusは多くのクエリ式と関数をサポートしています。詳

![Edit query expression and check all dimensions](/media/best-practices/edit-expression-check-dimensions.jpg)

次に、クエリ式を修正し、 `type`後に`instance`ディメンションを追加し、 `Legend format`フィールドに`{{instance}}`追加します。これにより、各TiDBサーバーで実行される様々な種類のSQL文のQPSを確認できます。
次に、クエリ式を修正し、 `type`の後に`instance`ディメンションを追加し、 `Legend format`フィールドに`{{instance}}`を追加します。これにより、各TiDBサーバーで実行される様々な種類のSQL文のQPSを確認できます。

![Add an instance dimension to the query expression](/media/best-practices/add-instance-dimension.jpeg)

Expand Down
2 changes: 1 addition & 1 deletion best-practices/index-management-best-practices.md
Original file line number Diff line number Diff line change
Expand Up @@ -94,7 +94,7 @@ DESC TIDB_INDEX_USAGE;

- 未使用のインデックス:

- `QUERY_TOTAL = 0`場合、インデックスはどのクエリでも使用されていません。
- `QUERY_TOTAL = 0`の場合、インデックスはどのクエリでも使用されていません。
- `LAST_ACCESS_TIME`かなり前のものを示している場合、インデックスはもはや関連がない可能性があります。

- 非効率的なインデックス:
Expand Down
2 changes: 1 addition & 1 deletion best-practices/massive-regions-best-practices.md
Original file line number Diff line number Diff line change
Expand Up @@ -158,7 +158,7 @@ PDは、PD Leaderノードの切り替え後、迅速にリージョンルーテ

TiKVでは、pd-workerが定期的にリージョンメタ情報をPDに報告します。TiKVが再起動されたり、リージョンリーダーが切り替わったりすると、PDは統計情報に基づいてリージョン`approximate size / keys`を再計算する必要があります。そのため、リージョン数が多い場合、シングルスレッドのpd-workerがボトルネックとなり、タスクが滞留して処理が間に合わない可能性があります。このような状況では、PDは特定のリージョンメタ情報を時間内に取得できず、ルーティング情報が時間内に更新されません。この問題は実際の読み取りや書き込みには影響しませんが、PDのスケジューリングが不正確になり、TiDBがリージョンキャッシュを更新する際に複数のラウンドトリップが必要になる可能性があります。

**TiKV Grafana**パネルの**「Task」**の下にある**「Worker pending tasks」**を確認することで、pd-workerにタスクが蓄積されているかどうかを確認できます。一般的に、 `pending tasks`値は比較的低い値に抑えておく必要があります
**TiKV Grafana**パネルの**「Task」**の下にある**「Worker pending tasks」**を確認することで、pd-workerにタスクが蓄積されているかどうかを確認できます。一般的に、 `pending tasks`の値は比較的低い値に抑えておく必要があります

![Check pd-worker](/media/best-practices/pd-worker-metrics.png)

Expand Down
2 changes: 1 addition & 1 deletion best-practices/three-nodes-hybrid-deployment.md
Original file line number Diff line number Diff line change
Expand Up @@ -86,7 +86,7 @@ RocksDBスレッドプールは、コンパクションジョブとフラッシ

`rocksdb.max-sub-compactions` 、単一の圧縮ジョブで許可される同時サブタスクの数を示します。デフォルトは`3`です。書き込みトラフィックが多くない場合は、この値を下げることができます。

このテストでは、 `rocksdb.max-background-jobs`値は`3` `rocksdb.max-sub-compactions`値は`1`に設定されています。TPC-C負荷での12時間テスト中、書き込みストールは発生しませんでした。実際の負荷に応じて2つのパラメータ値を最適化する際には、監視指標に基づいて値を徐々に下げることができます。
このテストでは、 `rocksdb.max-background-jobs`の値は`3`に、 `rocksdb.max-sub-compactions`の値は`1`に設定されています。TPC-C負荷での12時間テスト中、書き込みストールは発生しませんでした。実際の負荷に応じて2つのパラメータ値を最適化する際には、監視指標に基づいて値を徐々に下げることができます。

- 書き込み停止が発生する場合は、値を`rocksdb.max-background-jobs`増やします。
- 書き込み停止が続く場合は、値`rocksdb.max-sub-compactions`を`2`または`3`に設定します。
Expand Down
8 changes: 4 additions & 4 deletions blocklist-control-plan.md
Original file line number Diff line number Diff line change
Expand Up @@ -96,10 +96,10 @@ DESC mysql.expr_pushdown_blacklist;
上記の各フィールドの説明は次のとおりです。

- `name` : プッシュダウンが無効になっている関数の名前。
- `store_type` : 関数の計算時にプッシュダウンされないようにするコンポーネントを指定します。指定できる要素は`tidb` 、 `tikv` 、 `tiflash`です。8 `store_type`大文字と小文字を区別しません。複数の要素を指定する必要がある場合は、各コンポーネントをカンマで区切ってください。
- `store_type`が`tidb`場合、TiDBメモリテーブルの読み取り中に他の TiDB サーバーで関数を実行できるかどうかを示します。
- `store_type`が`tikv`場合、関数が TiKV サーバーのコプロセッサーコンポーネントで実行できるかどうかを示します。
- `store_type`が`tiflash`場合、関数がTiFlash Server のコプロセッサーコンポーネントで実行できるかどうかを示します。
- `store_type` : 関数の計算時にプッシュダウンされないようにするコンポーネントを指定します。指定できる要素は`tidb` 、 `tikv` 、 `tiflash`です。`store_type`大文字と小文字を区別しません。複数の要素を指定する必要がある場合は、各コンポーネントをカンマで区切ってください。
- `store_type`が`tidb`の場合、TiDBメモリテーブルの読み取り中に他の TiDB サーバーで関数を実行できるかどうかを示します。
- `store_type`が`tikv`の場合、関数が TiKV サーバーのコプロセッサーコンポーネントで実行できるかどうかを示します。
- `store_type`が`tiflash`の場合、関数がTiFlash Server のコプロセッサーコンポーネントで実行できるかどうかを示します。
- `reason` : この関数がブロックリストに追加された理由を記録します。

### 使用法 {#usage}
Expand Down
Loading
Loading