From 48fc76b2560714e13fcb97fae30277ab8efc3bf9 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:15:09 +0900 Subject: [PATCH 01/14] i18n(ja): fix wrong-object, role-reversal, and OIDC mistranslations in dashboard-faq/session-share/session-sso MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - dashboard-faq.md: fixed a wrong-object mistranslation (deploy NgMonitoring manually -> deploy TiUP manually) and a dropped verb ending. - dashboard-session-share.md: fixed the summary reversing inviter and invitee roles (both said "招待者" where the second/third should say "招待された人"), and restored 5 UI button/field labels that were inconsistently translated into Japanese while a sibling button ("Share Current Session") correctly stayed literal English -- TiDB Dashboard's UI only ships en/zh locale files (no ja), so a real user always sees these labels in English. - dashboard-session-sso.md: fixed "SQL-based OIDC sign-on" (should be "OIDC-based Single Sign-On", both the domain and "Single" were wrong), "Auth0" garbled to "オーソ0", a dropped し in デプロイして/アクセス, 2 dropped を particles (repeated 3x/2x across the Okta/Auth0/Casdoor sections), a dropped は after a link, and an OIDC Token Issuer/Audience term-pair inconsistency (one translated, one left English). Co-Authored-By: Claude Sonnet 5 --- dashboard/dashboard-faq.md | 4 ++-- dashboard/dashboard-session-share.md | 12 ++++++------ dashboard/dashboard-session-sso.md | 20 ++++++++++---------- 3 files changed, 18 insertions(+), 18 deletions(-) diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index 6d84e6efc91a6..c5a6d959edab2 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -56,7 +56,7 @@ Prometheusインスタンスをデプロイしてもこの問題が引き続き ### `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を手動でデプロイできます。 +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)を参照してNgMonitoringを手動でデプロイできます。 Web ページに`required component NgMonitoring is not started`が表示されている場合は、次のようにしてデプロイメントの問題をトラブルシューティングできます。 @@ -112,7 +112,7 @@ Web ページに`required component NgMonitoring is not started`が表示され
TiDB Operatorを使用してデプロイされたクラスター -TiDB Operatorのドキュメントのセクション[継続的なプロファイリングを有効にする](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/access-dashboard/#enable-continuous-profiling)手順に従って、NgMonitoringコンポーネントをデプロイ。 +TiDB Operatorのドキュメントの[継続的なプロファイリングを有効にする](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/access-dashboard/#enable-continuous-profiling)セクションの手順に従って、NgMonitoringコンポーネントをデプロイしてください。
diff --git a/dashboard/dashboard-session-share.md b/dashboard/dashboard-session-share.md index ad7c70be68277..f2a199e599dc6 100644 --- a/dashboard/dashboard-session-share.md +++ b/dashboard/dashboard-session-share.md @@ -1,6 +1,6 @@ --- title: Share TiDB Dashboard Sessions -summary: TiDB Dashboardでは、ユーザーが現在のセッションを他のユーザーと共有できるため、ユーザーパスワードの入力は不要です。招待者は、特定の共有設定を含む認証コードを生成し、招待者に提供できます。招待者は、その認証コードを使用してパスワードなしでサインインできます。 +summary: TiDB Dashboardでは、ユーザーが現在のセッションを他のユーザーと共有できるため、ユーザーパスワードの入力は不要です。招待者は、特定の共有設定を含む認証コードを生成し、招待された人に提供できます。招待された人は、その認証コードを使用してパスワードなしでサインインできます。 --- # TiDB Dashboardセッションを共有する {#share-tidb-dashboard-sessions} @@ -27,11 +27,11 @@ TiDB Dashboardの現在のセッションを他のユーザーと共有して、 - 読み取り専用権限として共有: 共有セッションでは読み取り操作のみが許可され、書き込み操作 (構成の変更など) は許可されません。 -5. **[認証コードの生成]を**クリックします。 +5. **Generate Authorization Code**をクリックします。 ![Sample Step](/media/dashboard/dashboard-session-share-settings-2-v650.png) -6. 生成された**認証コードを**、セッションを共有するユーザーに提供します。 +6. 生成された**Authorization Code**を、セッションを共有するユーザーに提供します。 ![Sample Step](/media/dashboard/dashboard-session-share-settings-3-v650.png) @@ -41,16 +41,16 @@ TiDB Dashboardの現在のセッションを他のユーザーと共有して、 ## 招待された人の手順 {#steps-for-the-invitee} -1. TiDB Dashboardのサインイン ページで、 **[代替認証の使用] を**クリックします。 +1. TiDB Dashboardのサインインページで、 **Use Alternative Authentication**をクリックします。 ![Sample Step](/media/dashboard/dashboard-session-share-signin-1-v650.png) -2. **承認コード**をクリックしてサインインに使用します。 +2. **Authorization Code**をクリックしてサインインに使用します。 ![Sample Step](/media/dashboard/dashboard-session-share-signin-2-v650.png) 3. 招待者から受け取った認証コードを入力します。 -4. **[サインイン]を**クリックします。 +4. **Sign In**をクリックします。 ![Sample Step](/media/dashboard/dashboard-session-share-signin-3-v650.png) diff --git a/dashboard/dashboard-session-sso.md b/dashboard/dashboard-session-sso.md index 270395e1e38c7..c16b7ea945460 100644 --- a/dashboard/dashboard-session-sso.md +++ b/dashboard/dashboard-session-sso.md @@ -5,7 +5,7 @@ summary: TiDB Dashboardは、サインイン認証にOIDCベースのSSOをサ # TiDB DashboardのSSOを構成する {#configure-sso-for-tidb-dashboard} -TiDB Dashboardは、SQLベースの[OIDC](https://openid.net/connect/)サインオン（SSO）をサポートしています。TiDB DashboardのSSO機能を有効にすると、設定されたSSOサービスがサインイン認証に使用され、SQLユーザーのパスワードを入力せずにTiDB Dashboardにアクセスできるようになります。 +TiDB Dashboardは、 [OIDC](https://openid.net/connect/)ベースのシングルサインオン（SSO）をサポートしています。TiDB DashboardのSSO機能を有効にすると、設定されたSSOサービスがサインイン認証に使用され、SQLユーザーのパスワードを入力せずにTiDB Dashboardにアクセスできるようになります。 ## OIDC SSO を構成する {#configure-oidc-sso} @@ -25,7 +25,7 @@ TiDB Dashboardは、SQLベースの[OIDC](https://openid.net/connect/)サイン 通常、SSO サービス プロバイダーから次の2つのフィールドを取得できます。 - - OIDC Client ID は、OIDC トークン発行者とも呼ばれます。 + - OIDC Client ID は、OIDC Token Issuer とも呼ばれます。 - OIDC Discovery URL は、OIDC Token Audience とも呼ばれます。 5. **Authorize Impersonation**をクリックし、SQL パスワードを入力します。 @@ -122,7 +122,7 @@ TiDB Dashboardに SSO が設定されると、次の手順に従って SSO 経 http://DASHBOARD_IP:PORT/dashboard/?sso_callback=1 ``` - `DASHBOARD_IP:PORT` 、ブラウザで TiDB Dashboardにアクセスするために使用する実際のドメイン (または IP アドレス) とポートに置き換えます。 + `DASHBOARD_IP:PORT`を、ブラウザで TiDB Dashboardにアクセスするために使用する実際のドメイン (または IP アドレス) とポートに置き換えます。 8. **Sign-out redirect URIs**を次のように入力します。 @@ -130,7 +130,7 @@ TiDB Dashboardに SSO が設定されると、次の手順に従って SSO 経 http://DASHBOARD_IP:PORT/dashboard/ ``` - 同様に、 `DASHBOARD_IP:PORT`実際のドメイン (または IP アドレス) とポートに置き換えます。 + 同様に、 `DASHBOARD_IP:PORT`を実際のドメイン (または IP アドレス) とポートに置き換えます。 ![Sample Step](/media/dashboard/dashboard-session-sso-okta-3.png) @@ -156,7 +156,7 @@ TiDB Dashboardに SSO が設定されると、次の手順に従って SSO 経 ## 例2: TiDB DashboardのSSOサインインにAuth0を使用する {#example-2-use-auth0-for-tidb-dashboard-sso-sign-in} -Oktaと同様に、 [オーソ0](https://auth0.com/)もOIDC SSOアイデンティティサービスを提供します。以下の手順では、Auth0をTiDB DashboardのSSOプロバイダーとして使用できるように、Auth0とTiDB Dashboardを設定する方法について説明します。 +Oktaと同様に、 [Auth0](https://auth0.com/)もOIDC SSOアイデンティティサービスを提供します。以下の手順では、Auth0をTiDB DashboardのSSOプロバイダーとして使用できるように、Auth0とTiDB Dashboardを設定する方法について説明します。 ### ステップ1: Auth0を構成する {#step-1-configure-auth0} @@ -180,7 +180,7 @@ Oktaと同様に、 [オーソ0](https://auth0.com/)もOIDC SSOアイデンテ http://DASHBOARD_IP:PORT/dashboard/?sso_callback=1 ``` - `DASHBOARD_IP:PORT` 、ブラウザで TiDB Dashboardにアクセスするために使用する実際のドメイン (または IP アドレス) とポートに置き換えます。 + `DASHBOARD_IP:PORT`を、ブラウザで TiDB Dashboardにアクセスするために使用する実際のドメイン (または IP アドレス) とポートに置き換えます。 6. **許可されたログアウト URL**を次のように入力します。 @@ -188,7 +188,7 @@ Oktaと同様に、 [オーソ0](https://auth0.com/)もOIDC SSOアイデンテ http://DASHBOARD_IP:PORT/dashboard/ ``` - 同様に、 `DASHBOARD_IP:PORT`実際のドメイン (または IP アドレス) とポートに置き換えます。 + 同様に、 `DASHBOARD_IP:PORT`を実際のドメイン (または IP アドレス) とポートに置き換えます。 ![Settings](/media/dashboard/dashboard-session-sso-auth0-settings-2.png) @@ -206,11 +206,11 @@ Oktaと同様に、 [オーソ0](https://auth0.com/)もOIDC SSOアイデンテ ## 例3: TiDB DashboardのSSOサインインにCasdoorを使用する {#example-3-use-casdoor-for-tidb-dashboard-sso-sign-in} -[Casdoor](https://casdoor.org/) 、独自のホストに導入できるオープンソースのSSOプラットフォームです。TiDB DashboardのSSO機能と互換性があります。以下の手順では、CasdoorをTiDB DashboardのSSOプロバイダーとして使用できるように、CasdoorとTiDB Dashboardを設定する方法について説明します。 +[Casdoor](https://casdoor.org/)は、独自のホストに導入できるオープンソースのSSOプラットフォームです。TiDB DashboardのSSO機能と互換性があります。以下の手順では、CasdoorをTiDB DashboardのSSOプロバイダーとして使用できるように、CasdoorとTiDB Dashboardを設定する方法について説明します。 ### ステップ1：Casdoorを設定する {#step-1-configure-casdoor} -1. Casdoor 管理サイトをデプロイてアクセスします。 +1. Casdoor 管理サイトをデプロイしてアクセスします。 2. 上部のサイドバーの**Applications**から移動します。 @@ -224,7 +224,7 @@ Oktaと同様に、 [オーソ0](https://auth0.com/)もOIDC SSOアイデンテ http://DASHBOARD_IP:PORT/dashboard/?sso_callback=1 ``` - `DASHBOARD_IP:PORT` 、ブラウザで TiDB Dashboardにアクセスするために使用する実際のドメイン (または IP アドレス) とポートに置き換えます。 + `DASHBOARD_IP:PORT`を、ブラウザで TiDB Dashboardにアクセスするために使用する実際のドメイン (または IP アドレス) とポートに置き換えます。 ![Settings](/media/dashboard/dashboard-session-sso-casdoor-settings-2.png) From da6747e2d61faeffc3cd3ae37b76d556ce869168 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:18:23 +0900 Subject: [PATCH 02/14] i18n(ja): fix subject/object reversal and dropped negation in dashboard-diagnostics-report/statement-details MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - dashboard-diagnostics-report.md: fixed a subject/object reversal (TOTAL_TIME/TOTAL_COUNT are monitoring data from Prometheus, not the other way around), a severely MT-scrambled Note about Raft KV write metrics (a metric name misplaced into the wrong clause, the metric list missing one entry, a truncated word), a fabricated "5th node" with no basis in EN, an unclosed parenthesis, 3 sites missing the に particle before なります, 2 more dropped-particle sites found during review, and a scrambled sentence where two error-name examples (`TiKV channel full`, `tikv write stall`) were displaced into an unrelated clause about row comments. - dashboard-statement-details.md: fixed a dropped negation that reversed the fast-plan-binding limitation's meaning (from "any statement type other than these five is unsupported" to a bare list with no qualifier), a UI button ("Drop") translated into Japanese while its sibling ("Plan Binding") correctly stayed literal English, and a stray injected "1" with scrambled clause order. Co-Authored-By: Claude Sonnet 5 --- dashboard/dashboard-diagnostics-report.md | 22 +++++++++++----------- dashboard/dashboard-statement-details.md | 6 +++--- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/dashboard/dashboard-diagnostics-report.md b/dashboard/dashboard-diagnostics-report.md index 113fd4f5390f0..d0c7d6903643d 100644 --- a/dashboard/dashboard-diagnostics-report.md +++ b/dashboard/dashboard-diagnostics-report.md @@ -32,7 +32,7 @@ summary: TiDB Dashboard診断レポートでは、基本情報、診断情報、 すべての監視メトリックは、基本的にTiDB Grafana監視ダッシュボードのメトリックと一致しています。モジュールに異常が見つかった場合は、TiDB Grafanaで詳細な監視情報を確認できます。 -また、このレポートのメトリック`TOTAL_TIME`と`TOTAL_COUNT` Prometheus から読み取ったデータを監視しているため、統計に計算上の不正確さが存在する可能性があります。 +また、このレポートのメトリック`TOTAL_TIME`と`TOTAL_COUNT`は、Prometheusから読み取った監視データであるため、統計に計算上の不正確さが存在する可能性があります。 このレポートの各部分は次のように紹介されています。 @@ -144,7 +144,7 @@ TiDBには自動診断結果が組み込まれています。各フィールド - `METRIC_NAME` : 監視メトリックの名前。 - `Label` : 監視メトリックのラベル情報。**展開を**クリックすると、メトリックの各ラベルの詳細な監視情報が表示されます。 -- `TIME_RATIO` : この監視メトリックによって消費された合計時間と、監視行の合計時間の比率（ `TIME_RATIO`は`1`です。たとえば、 `kv_request`の合計消費時間は`tidb_query`の`1.65`倍（つまり`38325.58` / `23223.86` ）です。KVリクエストは同時に実行されるため、すべてのKVリクエストの合計時間は、クエリの合計実行時間（ `tidb_query` ）を超える可能性があります。 +- `TIME_RATIO` : この監視メトリックによって消費された合計時間と、監視行の合計時間の比率（ `TIME_RATIO`は`1`です）。たとえば、 `kv_request`の合計消費時間は`tidb_query`の`1.65`倍（つまり`38325.58` / `23223.86` ）です。KVリクエストは同時に実行されるため、すべてのKVリクエストの合計時間は、クエリの合計実行時間（ `tidb_query` ）を超える可能性があります。 - `TOTAL_TIME` : この監視メトリックによって消費された合計時間。 - `TOTAL_COUNT` : この監視メトリックが実行された合計回数。 - `P999` : この監視メトリックの最大 P999時間。 @@ -174,7 +174,7 @@ TiDBには自動診断結果が組み込まれています。各フィールド 上記の部分のうち、KV リクエスト時間には次の部分が含まれます。 -- ネットワークのリクエスト送受信にかかった時間です。現在、この項目の監視指標はありません。KVリクエスト時間から`tikv_grpc_message`差し引くことで、この項目のおおよその見積もりが可能です。 +- ネットワークのリクエスト送受信にかかった時間です。現在、この項目の監視指標はありません。KVリクエスト時間から`tikv_grpc_message`の時間を差し引くことで、この項目のおおよその見積もりが可能です。 - 消費時間`tikv_grpc_message` 。 上記の部品のうち、 `tikv_grpc_message`回の消費量に含まれる部品は以下のとおりです。 @@ -193,7 +193,7 @@ TiDBには自動診断結果が組み込まれています。各フィールド 上記のメトリックのうち、 `tikv_storage_async_request`の書き込み時間の消費は、次の部分を含むRaft KV の書き込み時間の消費を指します。 - `tikv_raft_propose_wait` -- `tikv_raft_process` 、主に`tikv_raft_append_log`含む +- `tikv_raft_process` 、主に`tikv_raft_append_log`を含む - `tikv_raft_commit_log` - `tikv_raft_apply_wait` - `tikv_raft_apply_log` @@ -202,13 +202,13 @@ TiDBには自動診断結果が組み込まれています。各フィールド > **Note:** > -> Raft KVへ`tikv_raft_commit_log`書き込みは1つのバッチで処理される可能性があるため、各モジュールの消費時間を`TOTAL_TIME`で測定することは、 Raft KVへの書き込みに関連するメトリクス（具体的には`tikv_raft_process` `tikv_raft_apply_wait` `tikv_raft_append_log`監視には適していませ`tikv_raft_apply_log` 。このような状況では、各モジュールの消費時間をP999とP99の時間と比較する方が合理的です。 +> Raft KVへの書き込みは1つのバッチで処理される可能性があるため、各モジュールの消費時間を`TOTAL_TIME`で測定することは、 Raft KVへの書き込みに関連するメトリクス（具体的には`tikv_raft_process`、 `tikv_raft_append_log`、 `tikv_raft_commit_log`、 `tikv_raft_apply_wait`、および`tikv_raft_apply_log`）の監視には適していません。このような状況では、各モジュールの消費時間をP999とP99の時間と比較する方が合理的です。 > -> その理由は、非同期書き込みリクエストが10件ある場合、 Raft KVは内部的に10件のリクエストをバッチ実行にまとめ、その実行時間は1秒だからです。そのため、各リクエストの実行時間は1秒で、10件のリクエストの合計時間は10秒ですが、 Raft KVの処理時間の合計は1秒です。消費時間を`TOTAL_TIME`計測すると、残りの9秒がどこに費やされているのかが分からなくなってしまう可能性があります。また、リクエストの総数（ `TOTAL_COUNT` ）からも、 Raft KVの監視メトリクスとこれまでの監視メトリクスの違いが分かります。 +> その理由は、非同期書き込みリクエストが10件ある場合、 Raft KVは内部的に10件のリクエストをバッチ実行にまとめ、その実行時間は1秒だからです。そのため、各リクエストの実行時間は1秒で、10件のリクエストの合計時間は10秒ですが、 Raft KVの処理時間の合計は1秒です。消費時間を`TOTAL_TIME`で計測すると、残りの9秒がどこに費やされているのかが分からなくなってしまう可能性があります。また、リクエストの総数（ `TOTAL_COUNT` ）からも、 Raft KVの監視メトリクスとこれまでの監視メトリクスの違いが分かります。 #### 各コンポーネントでエラーが発生しました {#errors-occurred-in-each-component} -表`Errors Occurred in Each Component`は、TiDBとTiKVにおけるエラーの総数を示しています。binlogへのbinlog失敗、 `tikv server is busy`などです。各エラーの具体的な意味については`TiKV channel full`行のコメント`tikv write stall`を参照してください。 +表`Errors Occurred in Each Component`は、TiDBとTiKVにおけるエラーの総数を示しています。例えば、binlogの書き込み失敗、 `tikv server is busy`、 `TiKV channel full`、 `tikv write stall`などです。各エラーの具体的な意味については、行のコメントを参照してください。 ![Errors Occurred in Each Component report](/media/dashboard/dashboard-diagnostics-error.png) @@ -247,7 +247,7 @@ TiDBには自動診断結果が組み込まれています。各フィールド ![TiDB DDL Owner Report](/media/dashboard/dashboard-diagnostics-tidb-ddl.png) -上記の表は、 `2020-05-21 14:40:00`から5ノード目にあるクラスタの`DDL OWNER`ノード`10.0.1.13:10080`であることを示しています。所有者が変更された場合、上記の表には複数のデータ行が存在し、 `Min_Time`列は対応する既知の所有者の最小時間を示します。 +上記の表は、 `2020-05-21 14:40:00`から、クラスターの`DDL OWNER`が`10.0.1.13:10080`ノードにあることを示しています。所有者が変更された場合、上記の表には複数のデータ行が存在し、 `Min_Time`列は対応する既知の所有者の最小時間を示します。 > **Note:** > @@ -347,9 +347,9 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり `DIFF_RATIO` : 2つの時間範囲の差の値を示します。以下の値があります。 -- 監視メトリックの値が`t2`以内のみで、 `t1`以内の値がない場合は、 `DIFF_RATIO`の値は`1`なります。 -- 監視メトリックの値が`t1`内のみにあり、 `t2`時間範囲内に値がない場合は、 `DIFF_RATIO`の値は`-1`なります。 -- `t2`の値が`t1`より大きい場合、 `DIFF_RATIO` = `(t2.value / t1.value)-1`なります。 +- 監視メトリックの値が`t2`以内のみで、 `t1`以内の値がない場合は、 `DIFF_RATIO`の値は`1`になります。 +- 監視メトリックの値が`t1`内のみにあり、 `t2`時間範囲内に値がない場合は、 `DIFF_RATIO`の値は`-1`になります。 +- `t2`の値が`t1`より大きい場合、 `DIFF_RATIO` = `(t2.value / t1.value)-1`になります。 - `t2`の値が`t1`の値より小さい場合、 `DIFF_RATIO` = `1-(t1.value / t2.value)` たとえば、上の表では、 `t2`の`tidb`ノードの平均 CPU 使用率は`t1`の 2.02 倍、つまり`2.02` = `1240/410-1`です。 diff --git a/dashboard/dashboard-statement-details.md b/dashboard/dashboard-statement-details.md index d92e3af6f5b76..d0a09b200b93b 100644 --- a/dashboard/dashboard-statement-details.md +++ b/dashboard/dashboard-statement-details.md @@ -9,7 +9,7 @@ summary: TiDB Dashboardは、SQLテンプレートの概要、実行計画一覧 - SQL 文の概要。これには、SQL テンプレート、SQL テンプレート ID、表示されている SQL 実行の現在の時間範囲、実行計画の数、SQL 文が実行されるデータベース、および高速プランバインディング機能が含まれます (次の図の領域 1)。 - 実行計画リスト：SQL文に複数の実行計画がある場合、このリストが表示されます。実行計画のテキスト情報に加え、TiDB v6.2.0ではビジュアル実行計画が導入され、文の各オペレーターや詳細情報をより直感的に把握できるようになりました。複数の実行計画を選択すると、選択したプランの詳細がリストの下に表示されます（下図の領域2）。 -- プランの実行詳細。選択した実行計画の詳細情報が表示されます。1（下図の領域3） [実行計画の詳細](#execution-details-of-plans)を参照してください。 +- プランの実行詳細。選択した実行計画の詳細情報が表示されます。 [実行計画の詳細](#execution-details-of-plans)を参照してください（下図の領域3）。 ![Details](/media/dashboard/dashboard-statement-detail-v660.png) @@ -39,7 +39,7 @@ TiDB v6.6.0以降、高速プランバインディング機能が導入されま ![Fast plan binding - bound - entry](/media/dashboard/dashboard-quick-binding-entry-bound.png) -2. **［ドロップ］を**クリックします。 +2. **Drop**をクリックします。 ![Fast plan binding - popup - bound](/media/dashboard/dashboard-quick-binding-popup-bound.png) @@ -51,7 +51,7 @@ TiDB v6.6.0以降、高速プランバインディング機能が導入されま 現在、高速プランバインディング機能では、次の種類の SQL文はサポートされていません。 -- `SELECT` `INSERT` `UPDATE` `REPLACE` `DELETE` +- `SELECT`、 `DELETE`、 `UPDATE`、 `INSERT`、 `REPLACE`のいずれでもないステートメント - サブクエリを含むクエリ - TiFlashにアクセスするクエリ - 3つ以上のテーブルを結合するクエリ From f1c82987dfbf3c7c2b614ff60a0eed01fad78dd6 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:21:34 +0900 Subject: [PATCH 03/14] i18n(ja): fix dropped particles and literal-name defects in 6 dashboard files MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - continuous-profiling.md: dropped を before ご覧ください - dashboard-access.md: scrambled word order in a "wrong root password" bullet, 2 dropped を particles - dashboard-cluster-info.md: an untranslated lowercase "tombstone" status inconsistent with its capitalized/literal sibling status names elsewhere in the corpus (pd-control.md, tidb-scheduling.md), and a dropped は topic marker - dashboard-diagnostics-access.md: missing punctuation after a backtick timestamp range (2 sites) - dashboard-diagnostics-usage.md: 転属リーダー (personnel-transfer false friend) for "transferred leaders" (PD Region leader scheduling) - dashboard-intro.md: 6 sites with a dropped を before 参照 (2 sibling sentences in the same file already had it correctly), and the "Search Logs" page name translated into Japanese while every sibling TiDB Dashboard page name in the same file (Key Visualizer, SQL Statements, Slow Queries) stays literal English Co-Authored-By: Claude Sonnet 5 --- dashboard/continuous-profiling.md | 2 +- dashboard/dashboard-access.md | 6 +++--- dashboard/dashboard-cluster-info.md | 4 ++-- dashboard/dashboard-diagnostics-access.md | 4 ++-- dashboard/dashboard-diagnostics-usage.md | 2 +- dashboard/dashboard-intro.md | 14 +++++++------- 6 files changed, 16 insertions(+), 16 deletions(-) diff --git a/dashboard/continuous-profiling.md b/dashboard/continuous-profiling.md index 922bfcd35cac0..cfefd25db2454 100644 --- a/dashboard/continuous-profiling.md +++ b/dashboard/continuous-profiling.md @@ -48,7 +48,7 @@ summary: TiDB Dashboardの継続的プロファイリングにより、専門家 > **Note:** > -> 継続的プロファイリングを使用するには、クラスターを最新バージョンのTiUP （v1.9.0以上）またはTiDB Operator （v1.3.0以上）でデプロイまたはアップグレードする必要があります。以前のバージョンのTiUPまたはTiDB Operatorを使用してクラスターをアップグレードした場合は、手順[FAQ](/dashboard/dashboard-faq.md#a-required-component-ngmonitoring-is-not-started-error-is-shown)ご覧ください。 +> 継続的プロファイリングを使用するには、クラスターを最新バージョンのTiUP （v1.9.0以上）またはTiDB Operator （v1.3.0以上）でデプロイまたはアップグレードする必要があります。以前のバージョンのTiUPまたはTiDB Operatorを使用してクラスターをアップグレードした場合は、手順については[FAQ](/dashboard/dashboard-faq.md#a-required-component-ngmonitoring-is-not-started-error-is-shown)をご覧ください。 継続的プロファイリングを有効にすると、Webページを常にアクティブにしておくことなく、バックグラウンドで継続的にパフォーマンスデータを収集できます。収集されたデータは一定期間保存され、期限切れのデータは自動的に削除されます。 diff --git a/dashboard/dashboard-access.md b/dashboard/dashboard-access.md index 14f3ad0d3fbe2..27d29e6eef1bc 100644 --- a/dashboard/dashboard-access.md +++ b/dashboard/dashboard-access.md @@ -13,7 +13,7 @@ TiDB Dashboardにアクセスするには、ブラウザから[http://127.0.0.1: ## 複数のPDインスタンスがデプロイされている場合にTiDB Dashboardにアクセスする {#access-tidb-dashboard-when-multiple-pd-instances-are-deployed} -クラスターに複数の PD インスタンスがデプロイされていて、**すべての**PD インスタンスとポートに直接アクセスできる場合は、アドレス[http://127.0.0.1:2379/dashboard/](http://127.0.0.1:2379/dashboard/)の`127.0.0.1:2379`**任意の**PD インスタンスのアドレスとポートに置き換えるだけです。 +クラスターに複数の PD インスタンスがデプロイされていて、**すべての**PD インスタンスとポートに直接アクセスできる場合は、アドレス[http://127.0.0.1:2379/dashboard/](http://127.0.0.1:2379/dashboard/)の`127.0.0.1:2379`を**任意の**PD インスタンスのアドレスとポートに置き換えるだけです。 > **Note:** > @@ -36,7 +36,7 @@ TiDB Dashboardは、比較的新しいバージョンの次の一般的なデス TiDB Dashboardにアクセスすると、ユーザー ログイン インターフェイスに移動します。 - TiDB `root`アカウントを使用して TiDB Dashboardにサインインできます。 -- TiDB Dashboardには、シングルサインオン（SSO）経由でサインインすることもできます。詳細については、 [TiDB DashboardのSSOを構成する](/dashboard/dashboard-session-sso.md)ご覧ください。 +- TiDB Dashboardには、シングルサインオン（SSO）経由でサインインすることもできます。詳細については、 [TiDB DashboardのSSOを構成する](/dashboard/dashboard-session-sso.md)をご覧ください。 - [ユーザー定義のSQLユーザー](/dashboard/dashboard-user.md)を作成した場合は、このアカウントと対応するパスワードを使用してサインインできます。 次のいずれかの状況が存在する場合、ログインが失敗する可能性があります。 @@ -44,7 +44,7 @@ TiDB Dashboardにアクセスすると、ユーザー ログイン インター - TiDB `root`ユーザーが存在しません。 - PD が起動していないか、アクセスできません。 - TiDB が起動されていないか、アクセスできません。 -- パスワードが`root`間違っています。 +- `root`のパスワードが間違っています。 サインイン後、セッションは24時間有効です。サインアウトの方法については、 [ログアウト](#logout)セクションをご覧ください。 diff --git a/dashboard/dashboard-cluster-info.md b/dashboard/dashboard-cluster-info.md index c1b887f926f08..27fa918a08eb3 100644 --- a/dashboard/dashboard-cluster-info.md +++ b/dashboard/dashboard-cluster-info.md @@ -38,13 +38,13 @@ summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体 - 稼働中: インスタンスは正常に実行されています。 - ダウンまたは到達不能: インスタンスが実行されていないか、対応するホストにネットワークの問題が発生しています。 -- tombstone: インスタンス上のデータが完全に移行され、スケールインが完了しました。このステータスは、TiKV またはTiFlashインスタンスにのみ存在します。 +- `Tombstone`: インスタンス上のデータが完全に移行され、スケールインが完了しました。このステータスは、TiKV またはTiFlashインスタンスにのみ存在します。 - 離脱中: インスタンス上のデータが移行中で、スケールインが進行中です。このステータスは、TiKV またはTiFlashインスタンスでのみ表示されます。 - 不明: インスタンスの実行状態は不明です。 > **Note:** > -> - TiDB Dashboardの`Leaving` 、PD API によって返される`Offline` 、およびTiUPの`Pending Offline`同じステータスを示します。 +> - TiDB Dashboardの`Leaving` 、PD API によって返される`Offline` 、およびTiUPの`Pending Offline`は同じステータスを示します。 > - テーブル内の一部の列は、インスタンスが起動している場合にのみ表示できます。 インスタンスのステータスはPDのスケジュール情報から取得されます。詳細については[情報収集](/tidb-scheduling.md#information-collection)を参照してください。 diff --git a/dashboard/dashboard-diagnostics-access.md b/dashboard/dashboard-diagnostics-access.md index 3f1d1aa681200..0faed4f511544 100644 --- a/dashboard/dashboard-diagnostics-access.md +++ b/dashboard/dashboard-diagnostics-access.md @@ -43,8 +43,8 @@ TiDB Dashboardのクラスタ診断機能は、指定された時間範囲内で 特定の時点でシステム例外が発生した場合（例えば、QPSジッターやレイテンシーの上昇など）、診断レポートを生成できます。このレポートでは、異常な時間帯のシステムと正常な時間帯のシステムを比較します。例えば、 -- 異常時間範囲: `2022-05-21 14:40:00` - `2022-05-21 14:45:00`この時間範囲内では、システムは異常です。 -- 正常な時間範囲: `2022-05-21 14:30:00` - `2022-05-21 14:35:00`この時間範囲内では、システムは正常です。 +- 異常時間範囲: `2022-05-21 14:40:00` - `2022-05-21 14:45:00`。この時間範囲内では、システムは異常です。 +- 正常な時間範囲: `2022-05-21 14:30:00` - `2022-05-21 14:35:00`。この時間範囲内では、システムは正常です。 前の 2つの時間範囲の比較レポートを生成するには、次の手順に従います。 diff --git a/dashboard/dashboard-diagnostics-usage.md b/dashboard/dashboard-diagnostics-usage.md index c89f181bb129e..2e44a3bca988b 100644 --- a/dashboard/dashboard-diagnostics-usage.md +++ b/dashboard/dashboard-diagnostics-usage.md @@ -36,7 +36,7 @@ T2: `2020-03-10 13:24:30` ～ `2020-03-10 13:27:30` 。この範囲ではQPSが - `tidb_cop_duration` : P999 コプロセッサリクエストの処理レイテンシーが 2.48 倍に増加しました。 - `tidb_kv_write_num` : P999 TiDB トランザクションで書き込まれた KV の数は 7.61 倍に増加しました。 - `tikv_cop_scan_keys_total_nun` : TiKVコプロセッサーによってスキャンされるキー/値の数が 3つの TiKV インスタンスで大幅に改善されました。 -- `pd_operator_step_finish_total_count`では、転属リーダー数が2.45倍に増加しており、異常時間帯のスケジュールが正常時間帯のスケジュールよりも高くなっていることがわかります。 +- `pd_operator_step_finish_total_count`では、移行したリーダー数が2.45倍に増加しており、異常時間帯のスケジュールが正常時間帯のスケジュールよりも高くなっていることがわかります。 - このレポートは、スロークエリが存在する可能性があることを示しており、SQL文を使用してスロークエリを照会できることを示しています。SQL文の実行結果は次のとおりです。 ```sql diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md index 138c4616a3296..bc781176cd85a 100644 --- a/dashboard/dashboard-intro.md +++ b/dashboard/dashboard-intro.md @@ -21,13 +21,13 @@ TiDB Dashboardは[GitHub](https://github.com/pingcap-incubator/tidb-dashboard) TiDB Dashboardを使用すると、TiDB クラスターの 1秒あたりのクエリ数 (QPS)、実行時間、最も多くのリソースを消費する SQL文の種類などの概要情報を確認できます。 -詳細は[TiDB Dashboardの概要](/dashboard/dashboard-overview.md)参照。 +詳細は[TiDB Dashboardの概要](/dashboard/dashboard-overview.md)を参照してください。 ## コンポーネントとホストの実行ステータスを表示する {#show-the-running-status-of-components-and-hosts} TiDB Dashboardを使用すると、クラスター全体の TiDB、TiKV、PD、 TiFlashコンポーネントの実行状態と、これらのコンポーネントが配置されているホストの実行状態を表示できます。 -詳細は[TiDB Dashboardのクラスタ情報ページ](/dashboard/dashboard-cluster-info.md)参照。 +詳細は[TiDB Dashboardのクラスタ情報ページ](/dashboard/dashboard-cluster-info.md)を参照してください。 ## 読み取りおよび書き込みトラフィックの分布と傾向を表示します {#show-distribution-and-trends-of-read-and-write-traffic} @@ -39,7 +39,7 @@ TiDB DashboardのKey Visualizer機能は、クラスター全体の読み取り/ すべてのSQL文の実行情報は、SQL Statementsページに表示されます。このページでは、すべてのステージにおける実行時間と合計実行回数を確認できます。これにより、最もリソースを消費しているSQLクエリを分析して特定し、クラスター全体のパフォーマンスを向上させることができます。 -詳細は[TiDB DashboardのSQL Statementsページ](/dashboard/dashboard-statement-list.md)参照。 +詳細は[TiDB DashboardのSQL Statementsページ](/dashboard/dashboard-statement-list.md)を参照してください。 ## スロークエリの詳細な実行情報を知る {#learn-the-detailed-execution-information-of-slow-queries} @@ -51,13 +51,13 @@ TiDB DashboardのSlow Queriesページには、実行に時間のかかるすべ TiDB Dashboardの診断機能は、クラスター内に一般的なリスク (不一致な構成など) や問題が存在するかどうかを自動的に判断し、レポートを生成して操作の提案を行ったり、異なる時間範囲で各クラスター メトリックの状態を比較して、起こりうる問題を分析したりします。 -詳細は[TiDB Dashboardのクラスタ診断ページ](/dashboard/dashboard-diagnostics-access.md)参照。 +詳細は[TiDB Dashboardのクラスタ診断ページ](/dashboard/dashboard-diagnostics-access.md)を参照してください。 ## すべてのコンポーネントのクエリログ {#query-logs-of-all-components} -TiDB Dashboardの [ログの検索] ページでは、クラスター内で実行中のすべてのインスタンスのログをキーワード、時間範囲、その他の条件ですばやく検索し、これらのログをパッケージ化してローカルマシンにダウンロードできます。 +TiDB DashboardのSearch Logsページでは、クラスター内で実行中のすべてのインスタンスのログをキーワード、時間範囲、その他の条件ですばやく検索し、これらのログをパッケージ化してローカルマシンにダウンロードできます。 -詳細は[検索ログページ](/dashboard/dashboard-log-search.md)参照。 +詳細は[Search Logsページ](/dashboard/dashboard-log-search.md)を参照してください。 ## リソース制御のためのクラスター容量の見積もり {#estimate-cluster-capacity-for-resource-control} @@ -69,4 +69,4 @@ TiDB Dashboardの [ログの検索] ページでは、クラスター内で実 これは、サードパーティのツールを使用せずに、各インスタンスをオンラインでプロファイリングし、プロファイリング データ収集期間中にインスタンスが実行したさまざまな内部操作と、この期間中の操作実行時間の割合を分析できる高度なデバッグ機能です。 -詳細は[プロファイルインスタンスページ](/dashboard/dashboard-profiling.md)参照。 +詳細は[プロファイルインスタンスページ](/dashboard/dashboard-profiling.md)を参照してください。 From 9ad0c52d6d1383feaa31d58c5d3cf78cd6e6501e Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:23:50 +0900 Subject: [PATCH 04/14] i18n(ja): fix self-contradiction and dropped particles in 3 more dashboard files MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - dashboard-key-visualizer.md: fixed a same-file self-contradiction (色が濃いほど used for BOTH lower and higher traffic; should be 寒色系/暖色系 matching the file's own correct wording elsewhere), 2 metric descriptions rendered as verb phrases inconsistent with sibling noun-phrase items in the same list, and a garbled redundant trailing clause. - dashboard-metrics-relation.md: fixed a fabricated "9th node" ordinal with no basis in EN (likely a misread of the "9070.18" figure), 3 dropped particles (は x2, を x1), and a Get/Cop type-name word order inconsistent with sibling bullets in the same list. - dashboard-monitoring.md: fixed an unclosed parenthesis and a dropped を before ご覧ください. Co-Authored-By: Claude Sonnet 5 --- dashboard/dashboard-key-visualizer.md | 8 ++++---- dashboard/dashboard-metrics-relation.md | 10 +++++----- dashboard/dashboard-monitoring.md | 4 ++-- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/dashboard/dashboard-key-visualizer.md b/dashboard/dashboard-key-visualizer.md index 1c346528ce393..1691e55241e1e 100644 --- a/dashboard/dashboard-key-visualizer.md +++ b/dashboard/dashboard-key-visualizer.md @@ -52,11 +52,11 @@ TiDBデータベースを使用する場合、ホットスポット問題が発 ヒートマップはKey Visualizerの中核部分であり、メトリクスの経時的な変化を表示します。ヒートマップのX軸は時間を示します。Y軸は、TiDBクラスターのすべてのスキーマとテーブルをカバーするキー範囲に基づいて、連続したリージョンを示します。 -ヒートマップ内の色が濃いほど、その期間におけるリージョンの読み取りおよび書き込みトラフィックが少ないことを示します。色が濃いほど（明るいほど）、トラフィックが多いことを示します。 +ヒートマップ内の色が寒色系であるほど、その期間におけるリージョンの読み取りおよび書き込みトラフィックが少ないことを示します。色が暖色系（明るい色）であるほど、トラフィックが多いことを示します。 ### リージョン圧縮 {#region-compression} -TiDB クラスターには最大数十万のリージョンが含まれる場合があります。これほど多くのリージョンを画面に表示するのは困難です。そのため、各ヒートマップでは、これらのリージョンを 1,500 個の連続した範囲に圧縮し、各範囲を「バケット」と呼びます。ヒートマップでは、負荷の高いインスタンスに重点を置く必要があるため、Key Visualizer はトラフィックの少ない多数のリージョンを 1つのバケットに圧縮し、トラフィックの多いリージョンも 1つのバケットに表示するリージョンがあります。 +TiDB クラスターには最大数十万のリージョンが含まれる場合があります。これほど多くのリージョンを画面に表示するのは困難です。そのため、各ヒートマップでは、これらのリージョンを 1,500 個の連続した範囲に圧縮し、各範囲を「バケット」と呼びます。ヒートマップでは、負荷の高いインスタンスに重点を置く必要があるため、Key Visualizer はトラフィックの少ない多数のリージョンを 1つのバケットに圧縮し、トラフィックの多いリージョンも 1つのバケットに表示します。 ## Key Visualizerを使用する {#use-key-visualizer} @@ -116,8 +116,8 @@ Key Visualizer を開くと、デフォルトで過去 6時間のデータベー 関心のあるメトリックを表示するには、**メトリック選択ボックス**(上記のインターフェイスの`Write (bytes)`の位置) でこのメトリックを選択します。 -- `Read (bytes)` : トラフィックを読み取ります。 -- `Write (bytes)` : トラフィックを書き込みます。 +- `Read (bytes)` : 読み取りトラフィック。 +- `Write (bytes)` : 書き込みトラフィック。 - `Read (keys)` : 読み取られた行数。 - `Write (keys)` : 書き込まれた行数。 - `All` : 読み取りトラフィックと書き込みトラフィックの合計。 diff --git a/dashboard/dashboard-metrics-relation.md b/dashboard/dashboard-metrics-relation.md index 90ac10346cc5f..d89e3d64119a5 100644 --- a/dashboard/dashboard-metrics-relation.md +++ b/dashboard/dashboard-metrics-relation.md @@ -41,7 +41,7 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー ![tidb\_execute node example1](/media/dashboard/dashboard-metrics-relation-node-example1.png) -- `tidb_execute` 、TiDB 実行エンジンでの SQL クエリの実行期間を表す監視メトリックの名前です。 +- `tidb_execute`は、TiDB 実行エンジンでの SQL クエリの実行期間を表す監視メトリックの名前です。 - `19306.46s`は、メトリック`tidb_execute`の合計実行時間が 19306.46秒であることを示します。`89.40%`は、19306.46秒がすべての SQL クエリ（ユーザー SQL クエリと TiDB 内部 SQL クエリを含む）の合計実行時間の 89.40% を占めていることを示します。クエリの合計実行時間は、 `tidb_query`の合計実行時間です。 - `9070.18s`は、 `tidb_execute`ノード自体の合計実行時間が 9070.18秒であり、残りがその子ノードによって消費された時間であることを表します。`42.00%`は、9070.18秒がすべてのクエリの合計クエリ時間の 42.00% を占めることを表します。 @@ -59,7 +59,7 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー 上のグラフから、 `tidb_execute`の 2つの子ノードがわかります。 -- `pd_start_tso_wait` : トランザクションの`start_tso`待機する合計時間。これは 300.66秒です。 +- `pd_start_tso_wait` : トランザクションの`start_tso`を待機する合計時間。これは 300.66秒です。 - `tidb_txn_cmd` : TiDB が関連するトランザクション コマンドを実行する合計時間。9935.62秒です。 さらに、 `tidb_execute`は`tidb_cop`ボックス領域を指す点線の矢印もあり、次のことを示しています。 @@ -68,7 +68,7 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー > **Note:** > -> ノードに子ノードを指す点線矢印がある場合、そのノード自体の持続時間は不正確です。例えば、 `tidb_execute`のノードの場合、ノード自体の持続時間は9070.18秒（ `9070.18 = 19306.46 - 300.66 - 9935.62` ）です。この式では、 `tidb_cop`子ノードの持続時間は`tidb_execute`の子ノードの持続時間に含まれていません。しかし、実際にはそうではありません。9番目のノード自体の持続時間である9070.18秒には、 `tidb_cop` `tidb_execute`ノードの持続時間の一部が含まれており、この部分の持続時間は特定できません。 +> ノードに子ノードを指す点線矢印がある場合、そのノード自体の持続時間は不正確です。例えば、 `tidb_execute`のノードの場合、ノード自体の持続時間は9070.18秒（ `9070.18 = 19306.46 - 300.66 - 9935.62` ）です。この式では、 `tidb_cop`子ノードの持続時間は`tidb_execute`の子ノードの持続時間に含まれていません。しかし、実際にはそうではありません。`tidb_execute`自体の持続時間である9070.18秒には、 `tidb_cop`の持続時間の一部が含まれており、この部分の持続時間は特定できません。 ### `tidb_kv_request`とその親ノード {#tidb-kv-request-and-its-parent-nodes} @@ -84,6 +84,6 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー - `tidb_kv_request.Get` : TiDB が`Get`型のキー値リクエストを送信する期間。 - `tidb_kv_request.Cop` : TiDB が`Cop`型のキー値リクエストを送信する期間。 -`tidb_kv_request`子ノードとして`tidb_kv_request.Get`と`tidb_kv_request.Cop`ノードを含みませんが、後者の2つのノードで構成されます。子ノードの名前プレフィックスは親ノードの名前に`.xxx`を加えたもので、これは子ノードが親ノードのサブクラスであることを意味します。このケースは次のように理解できます。 +`tidb_kv_request`は子ノードとして`tidb_kv_request.Get`と`tidb_kv_request.Cop`ノードを含みませんが、後者の2つのノードで構成されます。子ノードの名前プレフィックスは親ノードの名前に`.xxx`を加えたもので、これは子ノードが親ノードのサブクラスであることを意味します。このケースは次のように理解できます。 -TiDB がキー値リクエストを送信する合計時間は 14745.07秒で、そのうち、タイプ`Get`と`Cop`キー値リクエストにはそれぞれ 9798.02秒と 4946.46秒かかります。 +TiDB がキー値リクエストを送信する合計時間は 14745.07秒で、そのうち、 `Get`型と`Cop`型のキー値リクエストにはそれぞれ 9798.02秒と 4946.46秒かかります。 diff --git a/dashboard/dashboard-monitoring.md b/dashboard/dashboard-monitoring.md index ba83331d88cdc..901288f534814 100644 --- a/dashboard/dashboard-monitoring.md +++ b/dashboard/dashboard-monitoring.md @@ -5,7 +5,7 @@ summary: TiDB Dashboardのモニタリングページでは、パフォーマン # TiDB Dashboard監視ページ {#tidb-dashboard-monitoring-page} -モニタリングページでは、TiDB v6.1.0で導入されたパフォーマンス分析およびチューニングツールである「パフォーマンス概要」ダッシュボードを表示できます。「パフォーマンス概要」ダッシュボードを使用すると、パフォーマンスを効率的に分析し、ユーザー応答時間のボトルネックがデータベースにあるかどうかを確認できます。ボトルネックがデータベースにある場合は、データベース時間の概要、ワークロードプロファイル、SQLレイテンシーの内訳を表示することで、データベース内のボトルネックを特定できます。詳細は[パフォーマンス分析とチューニング](/performance-tuning-methods.md)ご覧ください。 +モニタリングページでは、TiDB v6.1.0で導入されたパフォーマンス分析およびチューニングツールである「パフォーマンス概要」ダッシュボードを表示できます。「パフォーマンス概要」ダッシュボードを使用すると、パフォーマンスを効率的に分析し、ユーザー応答時間のボトルネックがデータベースにあるかどうかを確認できます。ボトルネックがデータベースにある場合は、データベース時間の概要、ワークロードプロファイル、SQLレイテンシーの内訳を表示することで、データベース内のボトルネックを特定できます。詳細は[パフォーマンス分析とチューニング](/performance-tuning-methods.md)をご覧ください。 ## ページにアクセスする {#access-the-page} @@ -121,7 +121,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `Duration` : 実行時間 - クライアントからのリクエストをTiDBが受信してから、TiDBがそのリクエストを実行し、結果をクライアントに返すまでの時間。通常、クライアントからのリクエストはSQL文の形式で送信されますが、この時間には`COM_PING` 、 `COM_SLEEP` 、 `COM_STMT_FETCH` 、 `COM_SEND_LONG_DATA`などのコマンドの実行時間も含まれる場合があります。 - - TiDBはマルチクエリをサポートしています。つまり、クライアントは一度に複数のSQL文（例： `select 1; select 1; select 1;`を送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 + - TiDBはマルチクエリをサポートしています。つまり、クライアントは一度に複数のSQL文（例えば `select 1; select 1; select 1;` ）を送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 - `avg` : すべてのリクエストを実行する平均時間 From ed8eec41e1af271650dbccf15e6eb83689687ad1 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:24:40 +0900 Subject: [PATCH 05/14] i18n(ja): fix terminology inconsistency and dropped particles in dashboard-ops-deploy.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fixed 2 sites using として機能する ("functions as") instead of the file's own consistently-used 提供する ("serves"), matching EN's consistent use of "serves" throughout, and 4 dropped を particles in "Replace `X` with..." instructions. Co-Authored-By: Claude Sonnet 5 --- dashboard/dashboard-ops-deploy.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md index c3bc765aa2fa6..62041bc3637e9 100644 --- a/dashboard/dashboard-ops-deploy.md +++ b/dashboard/dashboard-ops-deploy.md @@ -1,6 +1,6 @@ --- title: Deploy TiDB Dashboard -summary: TiDB Dashboardは、v4.0以降のPDに組み込まれています。追加のデプロイメントは不要です。Kubernetes上に独立してデプロイすることも可能です。複数のPDインスタンスがデプロイされている場合、ダッシュボードとして機能するのは1つだけです。`tiup cluster display`コマンドを使用して、ダッシュボードの機能を確認してください。ダッシュボードの無効化と有効化は`tiup ctl`コマンドを使用して行うことができます。 +summary: TiDB Dashboardは、v4.0以降のPDに組み込まれています。追加のデプロイメントは不要です。Kubernetes上に独立してデプロイすることも可能です。複数のPDインスタンスがデプロイされている場合、ダッシュボードを提供するのは1つだけです。`tiup cluster display`コマンドを使用して、ダッシュボードの機能を確認してください。ダッシュボードの無効化と有効化は`tiup ctl`コマンドを使用して行うことができます。 --- # TiDB Dashboardをデプロイ {#deploy-tidb-dashboard} @@ -23,7 +23,7 @@ TiDB Dashboard UIは、v4.0以降のバージョンのPDコンポーネントに ## 複数のPDインスタンスを使用したデプロイメント {#deployment-with-multiple-pd-instances} -クラスターに複数の PD インスタンスがデプロイされている場合、これらのインスタンスのうち 1つだけが TiDB Dashboardとして機能します。 +クラスターに複数の PD インスタンスがデプロイされている場合、これらのインスタンスのうち 1つだけが TiDB Dashboardを提供します。 PDインスタンスが初めて実行される際、インスタンスは自動的に相互にネゴシエーションを行い、TiDB Dashboardを提供するインスタンスを1つ選択します。TiDB Dashboardは他のPDインスタンスでは実行されません。PDインスタンスが再起動されたり、新しいPDインスタンスが追加された場合でも、TiDB Dashboardサービスは選択されたPDインスタンスによって常に提供されます。ただし、TiDB Dashboardを提供するPDインスタンスがクラスターから削除（スケールイン）された場合は、再ネゴシエーションが行われます。このネゴシエーションプロセスではユーザーの介入は必要ありません。 @@ -72,8 +72,8 @@ tiup ctl:v pd -u http://127.0.0.1:2379 config set dashboard-add 上記のコマンドでは、 -- `127.0.0.1:2379`任意の PD インスタンスの IP とポートに置き換えます。 -- `9.9.9.9:2379` TiDB Dashboard サービスを実行する新しい PD インスタンスの IP とポートに置き換えます。 +- `127.0.0.1:2379`を任意の PD インスタンスの IP とポートに置き換えます。 +- `9.9.9.9:2379`を TiDB Dashboard サービスを実行する新しい PD インスタンスの IP とポートに置き換えます。 変更が有効になっているかどうかを確認するには、 `tiup cluster display`コマンドを使用します ( `CLUSTER_NAME`をクラスター名に置き換えます)。 @@ -87,7 +87,7 @@ tiup cluster display CLUSTER_NAME --dashboard ## TiDB Dashboardを無効にする {#disable-tidb-dashboard} -TiUPを使用してデプロイされた実行中のクラスターの場合は、 `tiup ctl:v pd`コマンドを使用して、すべての PD インスタンスで TiDB Dashboardを無効にします ( `127.0.0.1:2379`任意の PD インスタンスの IP とポートに置き換えます)。 +TiUPを使用してデプロイされた実行中のクラスターの場合は、 `tiup ctl:v pd`コマンドを使用して、すべての PD インスタンスで TiDB Dashboardを無効にします ( `127.0.0.1:2379`を任意の PD インスタンスの IP とポートに置き換えます)。 ```bash tiup ctl:v pd -u http://127.0.0.1:2379 config set dashboard-address none @@ -107,7 +107,7 @@ Dashboard is not started. ## TiDB Dashboardを再度有効にする {#re-enable-tidb-dashboard} -TiUPを使用してデプロイされた実行中のクラスターの場合は、 `tiup ctl:v pd`コマンドを使用して、PD にインスタンスの再ネゴシエーションをリクエストし、TiDB Dashboardを実行します ( `127.0.0.1:2379`任意の PD インスタンスの IP とポートに置き換えます)。 +TiUPを使用してデプロイされた実行中のクラスターの場合は、 `tiup ctl:v pd`コマンドを使用して、PD にインスタンスの再ネゴシエーションをリクエストし、TiDB Dashboardを実行します ( `127.0.0.1:2379`を任意の PD インスタンスの IP とポートに置き換えます)。 ```bash tiup ctl:v pd -u http://127.0.0.1:2379 config set dashboard-address auto From 5515657c2aa49ffc230181d0c3d22407b4f9d78a Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:25:41 +0900 Subject: [PATCH 06/14] i18n(ja): fix dropped particles and redundant example marker in dashboard-ops-reverse-proxy.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fixed a dropped を before "リバースプロキシとして使用する" (NGINX site; the HAProxy sibling already had it correctly), a redundant doubled "for example" marker (例えば...（例）"), 2 dropped を before "例にとると" ("taking X as an example"), 4 dropped を in "Replace `X` with..." address-substitution instructions, and a dropped を before 参照 in a cross-reference. Co-Authored-By: Claude Sonnet 5 --- dashboard/dashboard-ops-reverse-proxy.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/dashboard/dashboard-ops-reverse-proxy.md b/dashboard/dashboard-ops-reverse-proxy.md index 81243e6f3343f..cb7a413e0a7d0 100644 --- a/dashboard/dashboard-ops-reverse-proxy.md +++ b/dashboard/dashboard-ops-reverse-proxy.md @@ -44,7 +44,7 @@ http://192.168.0.123:2379/dashboard/ [HAProxy](https://www.haproxy.org/)をリバースプロキシとして使用する場合は、次の手順を実行します。 -1. 例えば、TiDB Dashboardのリバースプロキシを`8033`ポート（例）で使用します。HAProxy設定ファイルに以下の設定を追加します。 +1. TiDB Dashboardのリバースプロキシを`8033`ポート（例）で使用します。HAProxy設定ファイルに以下の設定を追加します。 ```haproxy frontend tidb_dashboard_front @@ -56,7 +56,7 @@ http://192.168.0.123:2379/dashboard/ server tidb_dashboard 192.168.0.123:2379 ``` - `192.168.0.123:2379` 、 [ステップ1](#step-1-get-the-actual-tidb-dashboard-address)で取得した TiDB Dashboardの実際のアドレスの IP とポートに置き換えます。 + `192.168.0.123:2379`を、 [ステップ1](#step-1-get-the-actual-tidb-dashboard-address)で取得した TiDB Dashboardの実際のアドレスの IP とポートに置き換えます。 > **Warning:** > @@ -70,7 +70,7 @@ http://192.168.0.123:2379/dashboard/
NGINXを使用する -[NGINX](https://nginx.org/)リバースプロキシとして使用する場合は、次の手順を実行します。 +[NGINX](https://nginx.org/)をリバースプロキシとして使用する場合は、次の手順を実行します。 1. TiDB Dashboardのリバースプロキシを`8033`ポート（例）で使用します。NGINX設定ファイルに以下の設定を追加します。 @@ -83,7 +83,7 @@ http://192.168.0.123:2379/dashboard/ } ``` - `http://192.168.0.123:2379/dashboard/` 、 [ステップ1](#step-1-get-the-actual-tidb-dashboard-address)で取得した TiDB Dashboardの実際のアドレスに置き換えます。 + `http://192.168.0.123:2379/dashboard/`を、 [ステップ1](#step-1-get-the-actual-tidb-dashboard-address)で取得した TiDB Dashboardの実際のアドレスに置き換えます。 > **Warning:** > @@ -175,7 +175,7 @@ server_configs: tiup cluster reload CLUSTER_NAME -R pd ``` -詳細は[一般的なTiUP操作 - 構成の変更](/maintain-tidb-using-tiup.md#modify-the-configuration)参照。 +詳細は[一般的なTiUP操作 - 構成の変更](/maintain-tidb-using-tiup.md#modify-the-configuration)を参照してください。
@@ -195,7 +195,7 @@ server_configs:
HAProxyを使用する -`http://example.com:8033/foo/`例にとると、対応する HAProxy 構成は次のようになります。 +`http://example.com:8033/foo/`を例にとると、対応する HAProxy 構成は次のようになります。 ```haproxy frontend tidb_dashboard_front @@ -208,7 +208,7 @@ backend tidb_dashboard_back server tidb_dashboard 192.168.0.123:2379 ``` -`192.168.0.123:2379` 、 [ステップ1](#step-1-get-the-actual-tidb-dashboard-address)で取得した TiDB Dashboardの実際のアドレスの IP とポートに置き換えます。 +`192.168.0.123:2379`を、 [ステップ1](#step-1-get-the-actual-tidb-dashboard-address)で取得した TiDB Dashboardの実際のアドレスの IP とポートに置き換えます。 > **Warning:** > @@ -232,7 +232,7 @@ backend tidb_dashboard_back
NGINXを使用する -`http://example.com:8033/foo/`例にとると、対応する NGINX 構成は次のようになります。 +`http://example.com:8033/foo/`を例にとると、対応する NGINX 構成は次のようになります。 ```nginx server { @@ -243,7 +243,7 @@ server { } ``` -`http://192.168.0.123:2379/dashboard/` 、 [ステップ1](#step-1-get-the-actual-tidb-dashboard-address)で取得した TiDB Dashboardの実際のアドレスに置き換えます。 +`http://192.168.0.123:2379/dashboard/`を、 [ステップ1](#step-1-get-the-actual-tidb-dashboard-address)で取得した TiDB Dashboardの実際のアドレスに置き換えます。 > **Warning:** > From 80e4500a2c7d9f42eb5e23a56dd3c2527161e49a Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:26:40 +0900 Subject: [PATCH 07/14] i18n(ja): fix false friend, misplaced bold, and broken anchor in dashboard-ops-security.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - "SSL Termination" (a networking term) mistranslated as "SSL 終了" (end/finish) -- restored to literal English matching the link text - 3 dropped を particles before ご覧ください - Bold emphasis misplaced onto the wrong word twice: "any" (EN's actual emphasis) rendered as bold "client" instead, and a bold span splitting the middle of "リバースプロキシ" instead of covering "NOT"/"ONLY" as EN does - A broken in-page anchor link using the literal Japanese heading text as the anchor fragment instead of the heading's real English slug Co-Authored-By: Claude Sonnet 5 --- dashboard/dashboard-ops-security.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/dashboard/dashboard-ops-security.md b/dashboard/dashboard-ops-security.md index 09e7899749f29..f2ef4c69a4df6 100644 --- a/dashboard/dashboard-ops-security.md +++ b/dashboard/dashboard-ops-security.md @@ -13,13 +13,13 @@ TiDB Dashboardにアクセスするにはサインインする必要がありま TiDB Dashboardのアカウントシステムは、 TiDB SQLユーザーのアカウントシステムと一致しています。デフォルトでは、TiDBの`root`ユーザーにはパスワードが設定されていないため、TiDB Dashboardへのアクセスにはパスワード認証が不要です。これにより、悪意のある訪問者は、特権SQL文の実行を含む高い権限を取得できます。 -TiDB `root`ユーザーには強力なパスワードを設定することをお勧めします。詳細は[TiDB ユーザーアカウント管理](/user-account-management.md)ご覧ください。または、TiDB `root`ユーザーを無効にすることもできます。 +TiDB `root`ユーザーには強力なパスワードを設定することをお勧めします。詳細は[TiDB ユーザーアカウント管理](/user-account-management.md)をご覧ください。または、TiDB `root`ユーザーを無効にすることもできます。 ### TiDB Dashboard用の最小権限ユーザーを作成する {#create-a-least-privileged-user-for-tidb-dashboard} TiDB Dashboardのアカウントシステムは、 TiDB SQLのアカウントシステムと一致しています。TiDB Dashboardにアクセスするユーザーは、 TiDB SQLユーザーの権限に基づいて認証および認可されます。そのため、TiDB Dashboardでは限定的な権限、つまり読み取り専用権限のみが必要です。最小権限の原則に基づいてユーザーがTiDB Dashboardにアクセスできるように設定することで、高い権限を持つユーザーのアクセスを回避できます。 -TiDB Dashboardにアクセスしてサインインするには、最小限の権限を持つSQLユーザーを作成することをお勧めします。これにより、高い権限を持つユーザーによるアクセスを回避し、セキュリティを向上できます。詳細は[TiDB Dashboardのユーザー管理](/dashboard/dashboard-user.md)ご覧ください。 +TiDB Dashboardにアクセスしてサインインするには、最小限の権限を持つSQLユーザーを作成することをお勧めします。これにより、高い権限を持つユーザーによるアクセスを回避し、セキュリティを向上できます。詳細は[TiDB Dashboardのユーザー管理](/dashboard/dashboard-user.md)をご覧ください。 ## ファイアウォールを使用して信頼できないアクセスをブロックする {#use-a-firewall-to-block-untrusted-access} @@ -31,7 +31,7 @@ TiDB DashboardはPDクライアントポート（デフォルトは[http://IP:23 以下の対策を講じることをお勧めします。 -- ファイアウォールを使用して、コンポーネントが外部ネットワークまたは信頼できないネットワーク経由で PDコンポーネントの**クライアント**ポートにアクセスすることを禁止します。 +- ファイアウォールを使用して、コンポーネントが外部ネットワークまたは信頼できないネットワーク経由で PDコンポーネントの**任意の**クライアントポートにアクセスすることを禁止します。 > **Note:** > @@ -80,7 +80,7 @@ http://192.168.0.123:2379/dashboard/ ## TiDB Dashboard専用のリバースプロキシ {#reverse-proxy-only-for-tidb-dashboard} -[ファイアウォールを使用して信頼できないアクセスをブロックする](#ファイアウォールを使用して信頼できないアクセスをブロックする)で述べたように、PDクライアントポートで提供されるサービスには、TiDB Dashboard（ [http://IP:2379/dashboard/](http://IP:2379/dashboard/)に配置）だけでなく、PD内の他の特権インターフェース（ [http://IP:2379/pd/api/v1/members](http://IP:2379/pd/api/v1/members)など）も含まれます。したがって、リバースプロキシを使用してTiDB Dashboardを外部ネットワークに提供する場合は、外部ネットワークが**リバース**プロキシを介してPD内の特権インターフェースにアクセスできないように、ポート内のすべてのサービスで**はなく**、プレフィックスが`/dashboard`サービスのみを提供するようにしてください。 +[ファイアウォールを使用して信頼できないアクセスをブロックする](#use-a-firewall-to-block-untrusted-access)で述べたように、PDクライアントポートで提供されるサービスには、TiDB Dashboard（ [http://IP:2379/dashboard/](http://IP:2379/dashboard/)に配置）だけでなく、PD内の他の特権インターフェース（ [http://IP:2379/pd/api/v1/members](http://IP:2379/pd/api/v1/members)など）も含まれます。したがって、リバースプロキシを使用してTiDB Dashboardを外部ネットワークに提供する場合は、外部ネットワークがリバースプロキシを介してPD内の特権インターフェースにアクセスできないように、ポート内のすべてのサービス**ではなく**、プレフィックスが`/dashboard`であるサービス**のみ**を提供するようにしてください。 安全で推奨されるリバースプロキシ構成を確認するには、 [リバースプロキシの背後で TiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)を参照することをお勧めします。 @@ -88,7 +88,7 @@ http://192.168.0.123:2379/dashboard/ トランスポートレイヤーのセキュリティをさらに強化するには、リバースプロキシに対して TLS を有効にし、さらに mTLS を導入してユーザー証明書を認証することもできます。 -詳細は[HTTPSサーバーの設定](http://nginx.org/en/docs/http/configuring_https_servers.html)と[HAProxy SSL 終了](https://www.haproxy.com/blog/haproxy-ssl-termination/)ご覧ください。 +詳細は[HTTPSサーバーの設定](http://nginx.org/en/docs/http/configuring_https_servers.html)と[HAProxy SSL Termination](https://www.haproxy.com/blog/haproxy-ssl-termination/)をご覧ください。 ## その他の推奨される安全対策 {#other-recommended-safety-measures} From 8182acc4ff71220d25dfcb877f06eeb1f3f38f8f Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:27:24 +0900 Subject: [PATCH 08/14] i18n(ja): fix bold-span and phrase-style defects in 3 more dashboard files MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - dashboard-overview.md: one bullet ("monitor and alert messages") rendered as a verb sentence, breaking the parallel noun-phrase structure of its 5 siblings in the same list. - dashboard-profiling.md: a bold span split the katakana compound word "オンデマンド" in half. - dashboard-resource-manager.md: a trailing は particle trapped inside a bold span, and a dropped を before 持っている after a backtick privilege name. Co-Authored-By: Claude Sonnet 5 --- dashboard/dashboard-overview.md | 2 +- dashboard/dashboard-profiling.md | 2 +- dashboard/dashboard-resource-manager.md | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/dashboard/dashboard-overview.md b/dashboard/dashboard-overview.md index 630819be528c7..9a18034d98b8f 100644 --- a/dashboard/dashboard-overview.md +++ b/dashboard/dashboard-overview.md @@ -12,7 +12,7 @@ summary: TiDB概要ページには、クラスターのQPS、レイテンシー - 最近の期間に最も長い実行時間を累積した SQL文。 - 最近の期間の実行時間がしきい値を超えたスロークエリ。 - 各インスタンスのノード数とステータス。 -- メッセージを監視および警告します。 +- 監視および警告メッセージ。 ## ページにアクセスする {#access-the-page} diff --git a/dashboard/dashboard-profiling.md b/dashboard/dashboard-profiling.md index 148176a91d95c..cb1c9240f90db 100644 --- a/dashboard/dashboard-profiling.md +++ b/dashboard/dashboard-profiling.md @@ -9,7 +9,7 @@ summary: 手動プロファイリングを使用すると、TiDB、TiKV、PD、 > > この機能はデータベースのエキスパート向けに設計されています。エキスパートでない方は、PingCAPテクニカルサポートの指示に従ってこの機能を使用することをお勧めします。 -手動プロファイリングを使用すると、TiDB、TiKV、PD、 TiFlashの各インスタンスの現在のパフォーマンスデータをワンクリックでオン**デマンドで**収集できます。収集されたパフォーマンスデータは、FlameGraphまたはDAG形式で視覚化できます。 +手動プロファイリングを使用すると、TiDB、TiKV、PD、 TiFlashの各インスタンスの現在のパフォーマンスデータをワンクリックで**オンデマンド**で収集できます。収集されたパフォーマンスデータは、FlameGraphまたはDAG形式で視覚化できます。 これらのパフォーマンスデータを使用すると、専門家はインスタンスの CPU やメモリなどの現在のリソース消費の詳細を分析し、CPU オーバーヘッドの増加、メモリ使用量の増加、プロセスの停止など、進行中の高度なパフォーマンスの問題を正確に特定できます。 diff --git a/dashboard/dashboard-resource-manager.md b/dashboard/dashboard-resource-manager.md index b11c91193bcb7..8df550b9fd238 100644 --- a/dashboard/dashboard-resource-manager.md +++ b/dashboard/dashboard-resource-manager.md @@ -47,7 +47,7 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ ![Calibrate by Hardware](/media/dashboard/dashboard-resource-manager-calibrate-by-hardware.png) - **ユーザーリソースグループの合計RUは**、 `default`リソースグループを除くすべてのユーザーリソースグループのRUの合計量を表します。この値が推定容量を超えると、システムはアラートをトリガーします。デフォルトでは、システムは定義済みの`default`リソースグループに無制限の使用量を割り当てます。すべてのユーザーが`default`リソースグループに属している場合、リソースはリソース制御が無効になっている場合と同じように割り当てられます。 + **ユーザーリソースグループの合計RU**は、 `default`リソースグループを除くすべてのユーザーリソースグループのRUの合計量を表します。この値が推定容量を超えると、システムはアラートをトリガーします。デフォルトでは、システムは定義済みの`default`リソースグループに無制限の使用量を割り当てます。すべてのユーザーが`default`リソースグループに属している場合、リソースはリソース制御が無効になっている場合と同じように割り当てられます。 - [実際の作業負荷に基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload) @@ -65,7 +65,7 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ > **Note:** > -> 容量推定機能を使用するには、現在のログインユーザーが権限`SUPER`または`RESOURCE_GROUP_ADMIN` 、および一部のシステムテーブルに対する権限`SELECT`持っている必要があります。この機能を使用する前に、現在のユーザーがこれらの権限を持っていることを確認してください。権限がない場合、一部の機能が正しく動作しない可能性があります。詳細については、 [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md#privileges)を参照してください。 +> 容量推定機能を使用するには、現在のログインユーザーが権限`SUPER`または`RESOURCE_GROUP_ADMIN` 、および一部のシステムテーブルに対する権限`SELECT`を持っている必要があります。この機能を使用する前に、現在のユーザーがこれらの権限を持っていることを確認してください。権限がない場合、一部の機能が正しく動作しない可能性があります。詳細については、 [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md#privileges)を参照してください。 ## メトリクス {#metrics} From 1d7ff5b6d5183f93b9dbc2d9664104ec49caae6e Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:28:33 +0900 Subject: [PATCH 09/14] i18n(ja): fix register inconsistency, run-on sentence, and dropped particle in 4 dashboard files MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - dashboard-slow-query.md and top-sql.md: a polite-imperative heading ("...してください") inconsistent with every sibling heading in the file using plain dictionary form - top-sql.md: a duplicated "Top Top SQL" - dashboard-statement-list.md: two EN sentences merged into one run-on with no punctuation between them - dashboard-user.md: a dropped を before "デフォルトのロールとして設定" Co-Authored-By: Claude Sonnet 5 --- dashboard/dashboard-slow-query.md | 2 +- dashboard/dashboard-statement-list.md | 2 +- dashboard/dashboard-user.md | 2 +- dashboard/top-sql.md | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/dashboard/dashboard-slow-query.md b/dashboard/dashboard-slow-query.md index 87a4320bb367b..ad9d3dc021433 100644 --- a/dashboard/dashboard-slow-query.md +++ b/dashboard/dashboard-slow-query.md @@ -13,7 +13,7 @@ TiDB Dashboardの「スロークエリ」ページでは、クラスタ内のす > > スロークエリログが無効になっている場合、この機能は利用できません。スロークエリログはデフォルトで有効になっており、システム変数[`tidb_enable_slow_log`](/system-variables.md#tidb_enable_slow_log)を使用して有効または無効にすることができます。 -## ページにアクセスしてください {#access-the-page} +## ページにアクセスする {#access-the-page} スロークエリページにアクセスするには、以下の2つの方法のいずれかを使用できます。 diff --git a/dashboard/dashboard-statement-list.md b/dashboard/dashboard-statement-list.md index bd174198e424b..b9b77856e2401 100644 --- a/dashboard/dashboard-statement-list.md +++ b/dashboard/dashboard-statement-list.md @@ -62,7 +62,7 @@ SQL Statementsページの上部で、表示するSQL実行の時間範囲を変 > > - ステートメント システムテーブルはメモリ内にのみ保存されるため、SQL Statements機能が無効にされると、システムテーブル内のデータはクリアされます。 > -> - `Collect interval`と`retain duration`の値はメモリ使用量に影響するため、実際の状況に応じて調整することをお勧めします`retain duration`の値は大きすぎないようにしてください。 +> - `Collect interval`と`retain duration`の値はメモリ使用量に影響するため、実際の状況に応じて調整することをお勧めします。 `retain duration`の値は大きすぎないようにしてください。 ### その他 {#others} diff --git a/dashboard/dashboard-user.md b/dashboard/dashboard-user.md index 43d0f729d1e59..2d7026be66891 100644 --- a/dashboard/dashboard-user.md +++ b/dashboard/dashboard-user.md @@ -97,7 +97,7 @@ SQL ユーザーが前述の権限要件を満たしていない場合、以下 GRANT SUPER ON *.* TO 'dashboardAdmin'@'%'; ``` -2. `dashboard_access`ロールを他のユーザーに付与し、 `dashboard_access`デフォルトのロールとして設定します。 +2. `dashboard_access`ロールを他のユーザーに付与し、 `dashboard_access`をデフォルトのロールとして設定します。 ```sql CREATE USER 'dashboardAdmin'@'%' IDENTIFIED BY ''; diff --git a/dashboard/top-sql.md b/dashboard/top-sql.md index f08a0ee132529..4139ea6f21a3a 100644 --- a/dashboard/top-sql.md +++ b/dashboard/top-sql.md @@ -33,7 +33,7 @@ Top SQLは、パフォーマンスの問題を分析するのに適していま - Top SQLは、データの誤りや異常なクラッシュなど、パフォーマンス以外の問題を特定するために使用することはできません。 - Top SQLは、ロック競合、トランザクションのセマンティクスエラー、またはリソース消費が原因ではないその他の問題を直接分析するには適していません。 -## ページにアクセスしてください {#access-the-page} +## ページにアクセスする {#access-the-page} 以下のいずれかの方法で、Top SQLページにアクセスできます。 @@ -49,7 +49,7 @@ Top SQLは、パフォーマンスの問題を分析するのに適していま > > Top SQLを使用するには、クラスターが最新バージョンのTiUP （v1.9.0以降）またはTiDB Operator （v1.3.0以降）を使用してデプロイまたはアップグレードされている必要があります。以前のバージョンのTiUPまたはTiDB Operatorを使用してクラスターをアップグレードした場合は、 [FAQ](/dashboard/dashboard-faq.md#a-required-component-ngmonitoring-is-not-started-error-is-shown)を参照して手順を確認してください。 -Top SQLは、有効にするとクラスタのパフォーマンスにわずかな影響（平均で3%以内）を与えるため、デフォルトでは有効になっていません。Top Top SQLを有効にするには、以下の手順に従ってください。 +Top SQLは、有効にするとクラスタのパフォーマンスにわずかな影響（平均で3%以内）を与えるため、デフォルトでは有効になっていません。Top SQLを有効にするには、以下の手順に従ってください。 1. [Top SQLページ](#access-the-page)にアクセスしてください。 2. **Open Settings**をクリックします。ページ右側の**Settings**領域で、**Enable Feature**スイッチを有効にします。 From 0582beb3f381835019ef6b8ae0f2f549ae505e40 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:33:24 +0900 Subject: [PATCH 10/14] i18n(ja): restore literal instance status names in dashboard-cluster-info.md Up, Down, Unreachable, Leaving, and Unknown are literal instance status names, confirmed against tiup-command-status.md and tiup-component-cluster-display.md (which list these same literal names, untranslated, in their own JA summaries) and against pd-control.md/tidb-scheduling.md's consistent literal treatment of PD store states. Only Tombstone had been fixed in the previous commit; this restores the other four to match, and brings the whole list in line with this same file's own Note paragraph, which already backtick-quotes `Leaving`/`Offline`/`Pending Offline` as literal status values. Co-Authored-By: Claude Sonnet 5 --- dashboard/dashboard-cluster-info.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/dashboard/dashboard-cluster-info.md b/dashboard/dashboard-cluster-info.md index 27fa918a08eb3..69789fa05a71b 100644 --- a/dashboard/dashboard-cluster-info.md +++ b/dashboard/dashboard-cluster-info.md @@ -36,11 +36,11 @@ summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体 インスタンスは次のいずれかのステータスで実行できます。 -- 稼働中: インスタンスは正常に実行されています。 -- ダウンまたは到達不能: インスタンスが実行されていないか、対応するホストにネットワークの問題が発生しています。 +- `Up`: インスタンスは正常に実行されています。 +- `Down` または`Unreachable`: インスタンスが実行されていないか、対応するホストにネットワークの問題が発生しています。 - `Tombstone`: インスタンス上のデータが完全に移行され、スケールインが完了しました。このステータスは、TiKV またはTiFlashインスタンスにのみ存在します。 -- 離脱中: インスタンス上のデータが移行中で、スケールインが進行中です。このステータスは、TiKV またはTiFlashインスタンスでのみ表示されます。 -- 不明: インスタンスの実行状態は不明です。 +- `Leaving`: インスタンス上のデータが移行中で、スケールインが進行中です。このステータスは、TiKV またはTiFlashインスタンスでのみ表示されます。 +- `Unknown`: インスタンスの実行状態は不明です。 > **Note:** > From da352c3bb16dbc85e05641c84148308fbd4a3e84 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:33:46 +0900 Subject: [PATCH 11/14] =?UTF-8?q?i18n(ja):=20unify=20=E7=95=B0=E5=B8=B8?= =?UTF-8?q?=E6=99=82=E9=96=93=E7=AF=84=E5=9B=B2=20->=20=E7=95=B0=E5=B8=B8?= =?UTF-8?q?=E3=81=AA=E6=99=82=E9=96=93=E7=AF=84=E5=9B=B2=20for=20consisten?= =?UTF-8?q?cy?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Matches the sibling label 正常な時間範囲 right below it, and the な-form already used earlier in the same paragraph (異常な時間帯/ 正常な時間帯). Co-Authored-By: Claude Sonnet 5 --- dashboard/dashboard-diagnostics-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dashboard/dashboard-diagnostics-access.md b/dashboard/dashboard-diagnostics-access.md index 0faed4f511544..09702442389dc 100644 --- a/dashboard/dashboard-diagnostics-access.md +++ b/dashboard/dashboard-diagnostics-access.md @@ -43,7 +43,7 @@ TiDB Dashboardのクラスタ診断機能は、指定された時間範囲内で 特定の時点でシステム例外が発生した場合（例えば、QPSジッターやレイテンシーの上昇など）、診断レポートを生成できます。このレポートでは、異常な時間帯のシステムと正常な時間帯のシステムを比較します。例えば、 -- 異常時間範囲: `2022-05-21 14:40:00` - `2022-05-21 14:45:00`。この時間範囲内では、システムは異常です。 +- 異常な時間範囲: `2022-05-21 14:40:00` - `2022-05-21 14:45:00`。この時間範囲内では、システムは異常です。 - 正常な時間範囲: `2022-05-21 14:30:00` - `2022-05-21 14:35:00`。この時間範囲内では、システムは正常です。 前の 2つの時間範囲の比較レポートを生成するには、次の手順に従います。 From f045bb90a9718d04b60f56e38c099aae37669a47 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:35:16 +0900 Subject: [PATCH 12/14] i18n(ja): improve phrasing of a scheduling-frequency sentence MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "スケジュールが高い" (a schedule being "high") is not natural Japanese -- EN's "the scheduling ... is higher" is about the frequency/amount of scheduling activity, not a schedule itself having a magnitude. Insert 頻度 (frequency) so 高い modifies a noun it can naturally modify. Co-Authored-By: Claude Sonnet 5 --- dashboard/dashboard-diagnostics-usage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dashboard/dashboard-diagnostics-usage.md b/dashboard/dashboard-diagnostics-usage.md index 2e44a3bca988b..8fdec9362b8cb 100644 --- a/dashboard/dashboard-diagnostics-usage.md +++ b/dashboard/dashboard-diagnostics-usage.md @@ -36,7 +36,7 @@ T2: `2020-03-10 13:24:30` ～ `2020-03-10 13:27:30` 。この範囲ではQPSが - `tidb_cop_duration` : P999 コプロセッサリクエストの処理レイテンシーが 2.48 倍に増加しました。 - `tidb_kv_write_num` : P999 TiDB トランザクションで書き込まれた KV の数は 7.61 倍に増加しました。 - `tikv_cop_scan_keys_total_nun` : TiKVコプロセッサーによってスキャンされるキー/値の数が 3つの TiKV インスタンスで大幅に改善されました。 -- `pd_operator_step_finish_total_count`では、移行したリーダー数が2.45倍に増加しており、異常時間帯のスケジュールが正常時間帯のスケジュールよりも高くなっていることがわかります。 +- `pd_operator_step_finish_total_count`では、移行したリーダー数が2.45倍に増加しており、異常時間帯のスケジューリングの頻度が正常時間帯よりも高くなっていることがわかります。 - このレポートは、スロークエリが存在する可能性があることを示しており、SQL文を使用してスロークエリを照会できることを示しています。SQL文の実行結果は次のとおりです。 ```sql From 5bfbf8522ba54958ccbda410bb63ae76348f3594 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:39:00 +0900 Subject: [PATCH 13/14] =?UTF-8?q?i18n(ja):=20add=20=E3=81=AE=20particle=20?= =?UTF-8?q?for=20TiDB=20root=20user=20phrasing=20consistency?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The heading and one body sentence rendered "TiDB \`root\` user" as "TiDB \`root\`ユーザー" (no particle between the two nouns), while a third sentence in the same file correctly used "TiDBの\`root\`ユーザー". Unify on the の form, which also reads more naturally in Japanese. Co-Authored-By: Claude Sonnet 5 --- dashboard/dashboard-ops-security.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dashboard/dashboard-ops-security.md b/dashboard/dashboard-ops-security.md index f2ef4c69a4df6..a4651a95e248c 100644 --- a/dashboard/dashboard-ops-security.md +++ b/dashboard/dashboard-ops-security.md @@ -9,11 +9,11 @@ TiDB Dashboardにアクセスするにはサインインする必要がありま ## TiDBユーザーのセキュリティを強化する {#enhance-security-of-tidb-users} -### TiDB `root`ユーザーに強力なパスワードを設定する {#set-a-strong-password-for-the-tidb-root-user} +### TiDBの`root`ユーザーに強力なパスワードを設定する {#set-a-strong-password-for-the-tidb-root-user} TiDB Dashboardのアカウントシステムは、 TiDB SQLユーザーのアカウントシステムと一致しています。デフォルトでは、TiDBの`root`ユーザーにはパスワードが設定されていないため、TiDB Dashboardへのアクセスにはパスワード認証が不要です。これにより、悪意のある訪問者は、特権SQL文の実行を含む高い権限を取得できます。 -TiDB `root`ユーザーには強力なパスワードを設定することをお勧めします。詳細は[TiDB ユーザーアカウント管理](/user-account-management.md)をご覧ください。または、TiDB `root`ユーザーを無効にすることもできます。 +TiDBの`root`ユーザーには強力なパスワードを設定することをお勧めします。詳細は[TiDB ユーザーアカウント管理](/user-account-management.md)をご覧ください。または、TiDBの`root`ユーザーを無効にすることもできます。 ### TiDB Dashboard用の最小権限ユーザーを作成する {#create-a-least-privileged-user-for-tidb-dashboard} From c0ce50add7971cff443bb9a90c4c6795bb557a1e Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 16 Sep 2026 11:41:22 +0900 Subject: [PATCH 14/14] i18n(ja): clarify high-traffic-region bucket sentence per CodeRabbit review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "トラフィックの多いリージョンも 1つのバケット" could be misread as grouping ALL high-traffic Regions into a single shared bucket. Add それぞれ to clarify that each high-traffic Region gets its own individual bucket (as opposed to low-traffic Regions, many of which are compressed into one shared bucket). Co-Authored-By: Claude Sonnet 5 --- dashboard/dashboard-key-visualizer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dashboard/dashboard-key-visualizer.md b/dashboard/dashboard-key-visualizer.md index 1691e55241e1e..0420416ed9a81 100644 --- a/dashboard/dashboard-key-visualizer.md +++ b/dashboard/dashboard-key-visualizer.md @@ -56,7 +56,7 @@ TiDBデータベースを使用する場合、ホットスポット問題が発 ### リージョン圧縮 {#region-compression} -TiDB クラスターには最大数十万のリージョンが含まれる場合があります。これほど多くのリージョンを画面に表示するのは困難です。そのため、各ヒートマップでは、これらのリージョンを 1,500 個の連続した範囲に圧縮し、各範囲を「バケット」と呼びます。ヒートマップでは、負荷の高いインスタンスに重点を置く必要があるため、Key Visualizer はトラフィックの少ない多数のリージョンを 1つのバケットに圧縮し、トラフィックの多いリージョンも 1つのバケットに表示します。 +TiDB クラスターには最大数十万のリージョンが含まれる場合があります。これほど多くのリージョンを画面に表示するのは困難です。そのため、各ヒートマップでは、これらのリージョンを 1,500 個の連続した範囲に圧縮し、各範囲を「バケット」と呼びます。ヒートマップでは、負荷の高いインスタンスに重点を置く必要があるため、Key Visualizer はトラフィックの少ない多数のリージョンを 1つのバケットに圧縮し、トラフィックの多いリージョンをそれぞれ 1つのバケットに表示します。 ## Key Visualizerを使用する {#use-key-visualizer}