# 演習 4: TiDB クラスタの管理 ## 概要 この演習では、TiDB クラスタの管理を行うために、アップグレード、スケールインおよびスケールアウト、モニタリング、配置ルールの使用などのタスクを実施します。以下の図は、TiDB クラスタの初期状態におけるデプロイメントトポロジを示しています。 ![60%](https://lab-static.pingcap.com/quick-demo/TiDBClusterDeploymentTopologyExercise_aa_007_20220914.png) > [!TIP] > Click **Start** to launch the lab environment. > Once the environment is ready, select **Next** on the bottom toolbar to advance to **Module 1**. > And, follow the step-by-step lab guide to connect to the hands-on environment and begin your tasks. ## モジュール 1: TiDB を v7.5.0 から v7.5.1 にアップグレードする + 本番環境でTiDBクラスタをアップグレードする前に、互換性の変更を確認し、TiUPまたはTiUPオフラインミラーをアップグレードし、TiUPトポロジー構成ファイルを編集し、クラスタのDDLとバックアップの状態を確認し、現在のクラスタの健康状態を確認する必要があります。詳細については、こちらの[ドキュメント](https://docs.pingcap.com/tidb/v7.5/upgrade-tidb-using-tiup)を参照してください。 ### 手順 1. 仮想マシンにログインする + Click here - [Terminal 1](ssh://monitor1-ssh#1) to open a new terminal connected to the virtual machine assigned for your hands-on lab. + The banner after you logged in: ```output , #_ ~\_ ####_ Amazon Linux 2 ~~ \_#####\ ~~ \###| ~~ \#/ ___ ~~ V~' '-> ~~~ / A newer version of Amazon Linux is available! ~~._. _/ _/ _/ Amazon Linux 2023, GA and supported until 2028-03-15. _/m/' https://aws.amazon.com/linux/amazon-linux-2023/ ``` ### 手順 2. TiDB クラスタのバージョンを確認します ```bash tiup cluster display tidb-test ``` ```output ... Cluster version: v7.5.0 ... ``` ### 手順 3. TiUP のローカルミラーをバージョン 7.5.1 に変更する ```bash tiup mirror set tidb-community-server-7.5.1-linux-amd64 ``` ```output Successfully set mirror to /home/ec2-user/tidb-community-server-7.5.1-linux-amd64 ``` ### 手順 4. TiDB クラスタのアップグレード + 既存のTiDB v7.5.0 クラスタをTiDB v7.5.1にアップグレードします ```bash tiup cluster upgrade tidb-test 7.5.1 ``` ```output Starting component `cluster`: /home/ec2-user/.tiup/components/cluster/v1.10.1/tiup-cluster upgrade tidb-test v7.5.0 This operation will upgrade tidb v7.5.0 cluster tidb-test to v7.5.1. Do you want to continue? [y/N]:(default=N) y ... Upgraded cluster `tidb-test` successfully ``` ### 手順 5. TiDB クラスタのバージョンを再度確認します ```bash tiup cluster display tidb-test ``` ```output tiup is checking updates for component cluster ... Starting component `cluster`: /home/ec2-user/.tiup/components/cluster/v1.10.1/tiup-cluster display tidb-test Cluster type: tidb Cluster name: tidb-test Cluster version: v7.5.1 ... ``` ## モジュール 2: TiKV クラスタをスケールアウトする ### 手順 1. `solution-scale-out-tikv.yaml` ファイルを読み取ります ```bash cat solution-scale-out-tikv.yaml ``` ```output tikv_servers: - host: 10.90.4.93 ssh_port: 22 port: 20160 status_port: 20180 deploy_dir: /tidb-deploy/tikv-20160 data_dir: /tidb-data/tikv-20160 log_dir: /tidb-deploy/tikv-20160/log config: server.labels: region: seattle zone: az4 storage-performance: high ``` ### 手順 2. TiKV クラスタをスケールアウトする ```bash tiup cluster scale-out tidb-test --user ec2-user -i ~/.ssh/pe-class-key-oregon.pem solution-scale-out-tikv.yaml ``` ```output ... Do you want to continue? [y/N]: (default=N) y ... Scaled cluster `tidb-test` out successfully ``` ### 手順 3. TiDB クラスタのステータスを確認する + デプロイされたTiDBクラスタと新しいTiKVノード（IPアドレス: `HOST_MONITOR1_PRIVATE_IP`）のステータスを確認します。現在、4つのTiKVノードがあります。 ```bash tiup cluster display tidb-test ``` ```output tiup is checking updates for component cluster ... Starting component `cluster`: /home/ec2-user/.tiup/components/cluster/v1.12.1/tiup-cluster display tidb-test Cluster type: tidb Cluster name: tidb-test Cluster version: v7.5.1 Deploy user: tidb SSH type: builtin Dashboard URL: http://10.90.1.122:2379/dashboard Grafana URL: http://10.90.4.214:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.214:9093 alertmanager 10.90.4.214 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.214:3000 grafana 10.90.4.214 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.122:2379 pd 10.90.1.122 2379/2380 linux/x86_64 Up|L|UI /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.2.243:2379 pd 10.90.2.243 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.25:2379 pd 10.90.3.25 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.214:9090 prometheus 10.90.4.214 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.133:4000 tidb 10.90.1.133 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.92:4000 tidb 10.90.2.92 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.4.103:9000 tiflash 10.90.4.103 9000/8123/3930/20170/20292/8234 linux/x86_64 Up /tidb-data/tiflash-9000 /tidb-deploy/tiflash-9000 10.90.1.98:20160 tikv 10.90.1.98 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.235:20160 tikv 10.90.2.235 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.148:20160 tikv 10.90.3.148 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.4.214:20160 tikv 10.90.4.214 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 Total nodes: 13 ``` ## モジュール 3: TiKV クラスタのスケールイン ### 手順 1. TiKV クラスタをスケールインする ```bash tiup cluster scale-in tidb-test --node ${HOST_MONITOR1_PRIVATE_IP}:20160 ``` ```output ... Do you want to continue? [y/N]:(default=N) y The component `[tikv]` will become tombstone, maybe exists in several minutes or hours, after that you can use the prune command to clean it Do you want to continue? [y/N]:(default=N) y ... Scaled cluster `tidb-test` in successfully ``` ### 手順 2. TiDB クラスタの状態を確認する + TiKVノードの状態（IPアドレス: `HOST_MONITOR1_PRIVATE_IP`）は `Tombstone` または `Pending Offline` に変更されている必要があります。 ```bash tiup cluster display tidb-test ``` ```output tiup is checking updates for component cluster ... ... ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- ... 10.90.4.214:20160 tikv 10.90.4.214 20160/20180 linux/x86_64 Tombstone /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 Total nodes: 13 There are some nodes can be pruned: Nodes: [10.90.4.214:20160] You can destroy them with the command: `tiup cluster prune tidb-test` ``` ### 手順 3. TiDB クラスタの剪定 + スケールインされたTiKVのステータスが`Tombstone`の場合、このTiKVノードを剪定してデータをクリーンアップできます。 ```bash tiup cluster prune tidb-test ``` ```output ... Do you confirm this action? [y/N]:(default=N) y ... Destroy success ``` ### 手順 4. TiDB クラスタのステータスを確認する + TiDBクラスタの状態を確認してください。 ```bash tiup cluster display tidb-test ``` ```output tiup is checking updates for component cluster ... Starting component `cluster`: /home/ec2-user/.tiup/components/cluster/v1.12.1/tiup-cluster display tidb-test Cluster type: tidb Cluster name: tidb-test Cluster version: v7.5.1 Deploy user: tidb SSH type: builtin Dashboard URL: http://10.90.1.122:2379/dashboard Grafana URL: http://10.90.4.214:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.214:9093 alertmanager 10.90.4.214 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.214:3000 grafana 10.90.4.214 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.122:2379 pd 10.90.1.122 2379/2380 linux/x86_64 Up|L|UI /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.2.243:2379 pd 10.90.2.243 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.25:2379 pd 10.90.3.25 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.214:9090 prometheus 10.90.4.214 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.133:4000 tidb 10.90.1.133 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.92:4000 tidb 10.90.2.92 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.4.103:9000 tiflash 10.90.4.103 9000/8123/3930/20170/20292/8234 linux/x86_64 Up /tidb-data/tiflash-9000 /tidb-deploy/tiflash-9000 10.90.1.98:20160 tikv 10.90.1.98 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.235:20160 tikv 10.90.2.235 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.148:20160 tikv 10.90.3.148 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 Total nodes: 12 ``` ## モジュール 4: ホットデータとコールドデータのストレージ層配置の実装 ### 概要 + この演習では、TiDBのSQL内の配置ルールの特徴機能を体験します。この機能は、SQLステートメントを使用してTiDB内でデータがどこに格納されるかを指定することができます。配置ルールを使用してコスト効率を改善するために、テーブルのパーティションを利用してコールドデータを`低コスト`ストレージ（または低パフォーマンスノード）に、ホットデータを`高コスト`ストレージ（または高パフォーマンスノード）に分離する練習を行います。 ![40%](https://lab-static.pingcap.com/quick-demo/PlacementRuleColdHot_aa_001_20230422.png) ### 手順 1. TiKV クラスタのスケールアウト + TiKV クラスタをスケールアウトして、低パフォーマンスストレージを持つ3つの追加TiKVノードを含めます。この演習では、TiKVノードが稼働している各EC2に追加のTiKVインスタンスを1つ置くだけです。3つの新しいTiKVノードが低パフォーマンスストレージを持ち、既存の3つのTiKVノードが高パフォーマンスストレージを持っていることを想定します。 ```bash tiup cluster scale-out tidb-test solution-topology-placement-rule.yaml --yes --user ec2-user -i ~/.ssh/pe-class-key-oregon.pem ``` ```output ... Scaled cluster `tidb-test` out successfully ``` ### 手順 2. TiDB クラスタの状態を確認する ```bash tiup cluster display tidb-test ``` ```output ... Cluster type: tidb Cluster name: tidb-test Cluster version: v7.5.1 Deploy user: tidb SSH type: builtin Dashboard URL: http://10.90.2.59:2379/dashboard Grafana URL: http://10.90.4.204:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.204:9093 alertmanager 10.90.4.204 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.204:3000 grafana 10.90.4.204 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.22:2379 pd 10.90.1.22 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.2.59:2379 pd 10.90.2.59 2379/2380 linux/x86_64 Up|L|UI /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.126:2379 pd 10.90.3.126 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.204:9090 prometheus 10.90.4.204 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.123:4000 tidb 10.90.1.123 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.193:4000 tidb 10.90.2.193 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.4.100:9000 tiflash 10.90.4.100 9000/8123/3930/20170/20292/8234 linux/x86_64 Up /tidb-data/tiflash-9000 /tidb-deploy/tiflash-9000 10.90.1.45:20160 tikv 10.90.1.45 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.45:20161 tikv 10.90.1.45 20161/20181 linux/x86_64 Up /tidb-data/tikv-20161 /tidb-deploy/tikv-20161 10.90.2.251:20160 tikv 10.90.2.251 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.251:20161 tikv 10.90.2.251 20161/20181 linux/x86_64 Up /tidb-data/tikv-20161 /tidb-deploy/tikv-20161 10.90.3.130:20160 tikv 10.90.3.130 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.130:20161 tikv 10.90.3.130 20161/20181 linux/x86_64 Up /tidb-data/tikv-20161 /tidb-deploy/tikv-20161 Total nodes: 15 ``` ### 手順 3. 配置ポリシーを作成する + 高パフォーマンスのストレージを持つTiKVノードにホットデータを、低パフォーマンスのストレージを持つTiKVノードにコールドデータを割り当てるために、配置ポリシーを作成します。 + rootとしてTiDBサーバーに接続します。 ```bash ./connect-db1.sh ``` ```output tidb:db1> ``` + 配置ルールに利用可能なラベルを確認します。キーが`storage-performance`のラベルに注意してください。`engine`、`zone`、および`region`は、現在は無視しても安全です。 ```sql SHOW PLACEMENT LABELS; ``` ```output tidb:db1> SHOW PLACEMENT LABELS; +---------------------+-----------------------+ | Key | Values | +---------------------+-----------------------+ | engine | ["tiflash"] | | region | ["Seattle"] | | storage-performance | ["high", "low"] | | zone | ["az1", "az2", "az3"] | +---------------------+-----------------------+ 4 rows in set (0.00 sec) ``` + 使用可能なラベルとそれに対応するTiKVストアを確認します。なお、`store_id`列はTiKVストアIDを表し、`label`列は各TiKVストアのラベル付けされたキーバリューを示しています。 ```sql SELECT store_id, address, store_state_name, label FROM information_schema.tikv_store_status; ``` ```output tidb:db1> SELECT store_id, address, store_state_name, label -> FROM information_schema.tikv_store_status; +----------+-------------------+------------------+--------------------------------------------------------------------------------------------------------------------------+ | store_id | address | store_state_name | label | +----------+-------------------+------------------+--------------------------------------------------------------------------------------------------------------------------+ | 1 | 10.90.3.130:20160 | Up | [{"key": "region", "value": "Seattle"}, {"key": "storage-performance", "value": "high"}, {"key": "zone", "value": "az3"}]| | 2 | 10.90.2.251:20160 | Up | [{"key": "region", "value": "Seattle"}, {"key": "storage-performance", "value": "high"}, {"key": "zone", "value": "az2"}]| | 3 | 10.90.1.45:20160 | Up | [{"key": "region", "value": "Seattle"}, {"key": "storage-performance", "value": "high"}, {"key": "zone", "value": "az1"}]| | 98 | 10.90.4.100:3930 | Up | [{"key": "engine", "value": "tiflash"}] | | 186 | 10.90.2.251:20161 | Up | [{"key": "region", "value": "Seattle"}, {"key": "storage-performance", "value": "low"}, {"key": "zone", "value": "az2"}] | | 187 | 10.90.1.45:20161 | Up | [{"key": "region", "value": "Seattle"}, {"key": "storage-performance", "value": "low"}, {"key": "zone", "value": "az1"}] | | 188 | 10.90.3.130:20161 | Up | [{"key": "region", "value": "Seattle"}, {"key": "storage-performance", "value": "low"}, {"key": "zone", "value": "az3"}] | +----------+-------------------+------------------+--------------------------------------------------------------------------------------------------------------------------+ 7 rows in set (0.01 sec) ``` + ホットデータのための配置ポリシーを作成し、ラベルのキー・バリューペア`(storage-performance, high)`にマッピングします。 ```sql DROP PLACEMENT POLICY IF EXISTS hot; ``` ```output tidb:db1> DROP PLACEMENT POLICY IF EXISTS hot; Query OK, 0 rows affected, 1 warning (0.00 sec) ``` ```sql CREATE PLACEMENT POLICY hot CONSTRAINTS="[+storage-performance=high]"; ``` ```output tidb:db1> CREATE PLACEMENT POLICY hot -> CONSTRAINTS="[+storage-performance=high]"; Query OK, 0 rows affected (0.07 sec) ``` + コールドデータ用の配置ポリシーを作成し、それをラベルのキー・バリュー・ペア `(storage-performance, low)` にマッピングします。 ```sql DROP PLACEMENT POLICY IF EXISTS cold; ``` ```output tidb:db1> DROP PLACEMENT POLICY IF EXISTS cold; Query OK, 0 rows affected, 1 warning (0.01 sec) ``` ```sql CREATE PLACEMENT POLICY cold CONSTRAINTS="[+storage-performance=low]"; ``` ```output tidb:db1> CREATE PLACEMENT POLICY cold -> CONSTRAINTS="[+storage-performance=low]"; Query OK, 0 rows affected (0.07 sec) ``` + 作成された配置ルールの制約定義を確認します: `hot` と `cold`: ```sql SELECT policy_name, constraints FROM information_schema.placement_policies; ``` ```output tidb:db1> SELECT policy_name, constraints FROM information_schema.placement_policies; +-------------+-----------------------------+ | policy_name | constraints | +-------------+-----------------------------+ | hot | [+storage-performance=high] | | cold | [+storage-performance=low] | +-------------+-----------------------------+ 2 rows in set (0.00 sec) ``` ### 手順 4. テーブルを2つ作成する + 前の段階での配置ルールを利用して2つのレンジパーティションテーブルを作成し、1つはコールドとホットのパーティションを持ち、もう1つはコールドのみのパーティションを持つテーブルを作成して、ストレージコストの効率を最大化します。 + `hot` と `cold` の配置ルールを使用して、`test.orders` のパーティションテーブルを作成します。`order_date` が2010年より前および2010年から2015年の間（2015年を含まない）の注文は `cold` としてマークされ、2015年以降の注文は `hot` としてマークされて `MAXVALUE` パーティションにマッピングされます。 ```sql DROP TABLE IF EXISTS test.orders; ``` ```output tidb:db1> DROP TABLE IF EXISTS test.orders; Query OK, 0 rows affected, 1 warning (0.00 sec) ``` ```sql CREATE TABLE test.orders (order_id INT, item VARCHAR(50), order_date DATE, PRIMARY KEY (order_date, order_id)) PARTITION BY RANGE( YEAR(order_date) ) ( PARTITION p10 VALUES LESS THAN (2010) PLACEMENT POLICY=cold, PARTITION p15 VALUES LESS THAN (2015) PLACEMENT POLICY=cold, PARTITION pm VALUES LESS THAN MAXVALUE PLACEMENT POLICY=hot ); ``` ```output tidb:db1> CREATE TABLE test.orders (order_id INT, item VARCHAR(50), order_date DATE, PRIMARY KEY (order_date, order_id)) -> PARTITION BY RANGE( YEAR(order_date) ) ( -> PARTITION p10 VALUES LESS THAN (2010) PLACEMENT POLICY=cold, -> PARTITION p15 VALUES LESS THAN (2015) PLACEMENT POLICY=cold, -> PARTITION pm VALUES LESS THAN MAXVALUE PLACEMENT POLICY=hot -> ); Query OK, 0 rows affected (0.34 sec) ``` + すべてのパーティションに対して`cold`配置ルールのみを使用して、パーティションテーブル`test.orders_log`を作成します。 ```sql DROP TABLE IF EXISTS test.orders_log; ``` ```output tidb:db1> DROP TABLE IF EXISTS test.orders_log; Query OK, 0 rows affected, 1 warning (0.00 sec) ``` ```sql CREATE TABLE test.orders_log (order_id INT, item VARCHAR(50), order_date DATE, PRIMARY KEY (order_date, order_id)) PARTITION BY RANGE( YEAR(order_date) ) ( PARTITION p10 VALUES LESS THAN (2010) PLACEMENT POLICY=cold, PARTITION p15 VALUES LESS THAN (2015) PLACEMENT POLICY=cold, PARTITION pm VALUES LESS THAN MAXVALUE PLACEMENT POLICY=cold ); ``` ```output tidb:db1> CREATE TABLE test.orders_log (order_id INT, item VARCHAR(50), order_date DATE, PRIMARY KEY (order_date, order_id)) -> PARTITION BY RANGE( YEAR(order_date) ) ( -> PARTITION p10 VALUES LESS THAN (2010) PLACEMENT POLICY=cold, -> PARTITION p15 VALUES LESS THAN (2015) PLACEMENT POLICY=cold, -> PARTITION pm VALUES LESS THAN MAXVALUE PLACEMENT POLICY=cold -> ); Query OK, 0 rows affected (0.38 sec) ``` ### 手順 5. 配置ルールが適用されたことを確認する + ホットとコールドのテーブル `test.orders` の TiKV リージョン情報を表示します。`START_KEY` が最も高い `REGION_ID` に注目してください。それが `MAXVALUE` パーティションです。例として出力すると、`REGION_ID` は264です（環境によってリージョンIDと開始キーの番号が異なる場合があります）。 ```sql SHOW TABLE test.orders REGIONS\G ``` ```output tidb:db1> SHOW TABLE test.orders REGIONS\G *************************** 1. row *************************** REGION_ID: 256 START_KEY: t_83_ END_KEY: t_84_ LEADER_ID: 259 LEADER_STORE_ID: 188 PEERS: 259, 269, 271 SCATTERING: 0 WRITTEN_BYTES: 136 READ_BYTES: 0 APPROXIMATE_SIZE(MB): 1 APPROXIMATE_KEYS: 0 SCHEDULING_CONSTRAINTS: CONSTRAINTS="[+storage-performance=low]" SCHEDULING_STATE: SCHEDULED *************************** 2. row *************************** REGION_ID: 260 START_KEY: t_84_ END_KEY: t_85_ LEADER_ID: 263 LEADER_STORE_ID: 188 PEERS: 263, 270, 272 SCATTERING: 0 WRITTEN_BYTES: 136 READ_BYTES: 0 APPROXIMATE_SIZE(MB): 1 APPROXIMATE_KEYS: 0 SCHEDULING_CONSTRAINTS: CONSTRAINTS="[+storage-performance=low]" SCHEDULING_STATE: SCHEDULED *************************** 3. row *************************** REGION_ID: 264 START_KEY: t_85_ END_KEY: t_86_ LEADER_ID: 266 LEADER_STORE_ID: 3 PEERS: 265, 266, 268 SCATTERING: 0 WRITTEN_BYTES: 0 READ_BYTES: 0 APPROXIMATE_SIZE(MB): 1 APPROXIMATE_KEYS: 0 SCHEDULING_CONSTRAINTS: CONSTRAINTS="[+storage-performance=high]" SCHEDULING_STATE: SCHEDULED 3 rows in set (0.02 sec) ``` + テーブル `test.orders` におけるリージョンと TiKV ストアのマッピングが配置ポリシーと一致していることを確認します。配置ルールによれば、`REGION_ID` 264 のリージョンは `ストレージパフォーマンス:高` の TiKV ノードにマッピングされるべきで、他の二つのリージョンである 256 と 260 は `ストレージパフォーマンス:低` の TiKV ノードにマッピングされるべきです。 ```sql SELECT kvrs.region_id, kvss.store_id, kvrp.is_leader, kvss.label, kvss.start_ts FROM information_schema.tikv_region_status kvrs JOIN information_schema.tikv_region_peers kvrp ON kvrs.region_id = kvrp.region_id JOIN information_schema.tikv_store_status kvss ON kvrp.store_id = kvss.store_id JOIN information_schema.tables t ON t.table_name = kvrs.table_name WHERE t.table_schema='test' AND t.table_name='orders' AND kvrs.is_index = 0 AND kvrp.is_leader = 1; ``` ```output tidb:db1> SELECT kvrs.region_id, kvss.store_id, kvrp.is_leader, kvss.label, kvss.start_ts -> FROM information_schema.tikv_region_status kvrs -> JOIN information_schema.tikv_region_peers kvrp -> ON kvrs.region_id = kvrp.region_id -> JOIN information_schema.tikv_store_status kvss -> ON kvrp.store_id = kvss.store_id -> JOIN information_schema.tables t -> ON t.table_name = kvrs.table_name -> WHERE t.table_schema='test' -> AND t.table_name='orders' -> AND kvrs.is_index = 0 -> AND kvrp.is_leader = 1; +-----------+----------+-----------+--------------------------------------------------------------------------------------------------------------------------+---------------------+ | region_id | store_id | is_leader | label | start_ts | +-----------+----------+-----------+--------------------------------------------------------------------------------------------------------------------------+---------------------+ | 264 | 3 | 1 | [{"key": "region", "value": "Seattle"}, {"key": "storage-performance", "value": "high"}, {"key": "zone", "value": "az1"}]| 2023-06-08 06:47:58 | | 256 | 188 | 1 | [{"key": "region", "value": "Seattle"}, {"key": "storage-performance", "value": "low"}, {"key": "zone", "value": "az3"}] | 2023-06-08 06:49:39 | | 260 | 188 | 1 | [{"key": "region", "value": "Seattle"}, {"key": "storage-performance", "value": "low"}, {"key": "zone", "value": "az3"}] | 2023-06-08 06:49:39 | +-----------+----------+-----------+--------------------------------------------------------------------------------------------------------------------------+---------------------+ 3 rows in set (0.01 sec) ``` + `COLD`のみのテーブル`test.orders_log`のTiKVリージョン情報を表示します。出力例において、すべてのリージョンの`REGION_ID`に注意してください。それらは277、281、および285です（ただし、環境によってはリージョンIDや開始キーの番号が異なる場合があります）。 ```sql SHOW TABLE test.orders_log REGIONS\G ``` ```output tidb:db1> SHOW TABLE test.orders_log REGIONS\G *************************** 1. row *************************** REGION_ID: 277 START_KEY: t_88_ END_KEY: t_89_ LEADER_ID: 280 LEADER_STORE_ID: 188 PEERS: 280, 289, 292 SCATTERING: 0 WRITTEN_BYTES: 136 READ_BYTES: 0 APPROXIMATE_SIZE(MB): 1 APPROXIMATE_KEYS: 0 SCHEDULING_CONSTRAINTS: CONSTRAINTS="[+storage-performance=low]" SCHEDULING_STATE: SCHEDULED *************************** 2. row *************************** REGION_ID: 281 START_KEY: t_89_ END_KEY: t_90_ LEADER_ID: 284 LEADER_STORE_ID: 188 PEERS: 284, 291, 294 SCATTERING: 0 WRITTEN_BYTES: 136 READ_BYTES: 0 APPROXIMATE_SIZE(MB): 1 APPROXIMATE_KEYS: 0 SCHEDULING_CONSTRAINTS: CONSTRAINTS="[+storage-performance=low]" SCHEDULING_STATE: SCHEDULED *************************** 3. row *************************** REGION_ID: 285 START_KEY: t_90_ END_KEY: t_91_ LEADER_ID: 288 LEADER_STORE_ID: 188 PEERS: 288, 290, 293 SCATTERING: 0 WRITTEN_BYTES: 136 READ_BYTES: 0 APPROXIMATE_SIZE(MB): 1 APPROXIMATE_KEYS: 0 SCHEDULING_CONSTRAINTS: CONSTRAINTS="[+storage-performance=low]" SCHEDULING_STATE: SCHEDULED 3 rows in set (0.02 sec) ``` + テーブル`test.orders_log`のリージョンとTiKVストアのマッピングが配置ポリシーと一致していることを確認します。配置ルールによると、すべてのリージョンは`storage-performance:low`のTiKVノードにマッピングされるべきです。 ```sql SELECT kvrs.region_id, kvss.store_id, kvrp.is_leader, kvss.label, kvss.start_ts FROM information_schema.tikv_region_status kvrs JOIN information_schema.tikv_region_peers kvrp ON kvrs.region_id = kvrp.region_id JOIN information_schema.tikv_store_status kvss ON kvrp.store_id = kvss.store_id JOIN information_schema.tables t ON t.table_name = kvrs.table_name WHERE t.table_schema='test' AND t.table_name='orders_log' AND kvrs.is_index = 0 AND kvrp.is_leader = 1; ``` ```output tidb:db1> SELECT kvrs.region_id, kvss.store_id, kvrp.is_leader, kvss.label, kvss.start_ts -> FROM information_schema.tikv_region_status kvrs -> JOIN information_schema.tikv_region_peers kvrp -> ON kvrs.region_id = kvrp.region_id -> JOIN information_schema.tikv_store_status kvss -> ON kvrp.store_id = kvss.store_id -> JOIN information_schema.tables t -> ON t.table_name = kvrs.table_name -> WHERE t.table_schema='test' -> AND t.table_name='orders_log' -> AND kvrs.is_index = 0 -> AND kvrp.is_leader = 1; +-----------+----------+-----------+-------------------------------------------------------------------------------------------------------------------------+---------------------+ | region_id | store_id | is_leader | label | start_ts | +-----------+----------+-----------+-------------------------------------------------------------------------------------------------------------------------+---------------------+ | 281 | 188 | 1 | [{"key": "region", "value": "Seattle"}, {"key": "storage-performance", "value": "low"}, {"key": "zone", "value": "az3"}]| 2023-06-08 06:49:39 | | 285 | 188 | 1 | [{"key": "region", "value": "Seattle"}, {"key": "storage-performance", "value": "low"}, {"key": "zone", "value": "az3"}]| 2023-06-08 06:49:39 | | 277 | 188 | 1 | [{"key": "region", "value": "Seattle"}, {"key": "storage-performance", "value": "low"}, {"key": "zone", "value": "az3"}]| 2023-06-08 06:49:39 | +-----------+----------+-----------+-------------------------------------------------------------------------------------------------------------------------+---------------------+ 3 rows in set (0.01 sec) ``` + クエリトレースを実行して、テーブル `test.orders` のパーティションのプルーニングを確認します。2010年から2015年までのデータをクエリしているため、コールドストレージでのクエリスキャンが予想されます。出力から、リージョンID 260 のリージョンがスキャンされていることが観察されます。これは `storage-performance:low` とラベル付けされた TiKV ノード上にあります。 ```bash TRACE SELECT item, order_date FROM test.orders WHERE order_date BETWEEN STR_TO_DATE('01/01/2013', '%m/%d/%Y') AND STR_TO_DATE('12/31/2013', '%m/%d/%Y'); ``` ```output tidb:db1> TRACE -> SELECT item, order_date FROM test.orders -> WHERE order_date BETWEEN STR_TO_DATE('01/01/2013', '%m/%d/%Y') AND STR_TO_DATE('12/31/2013', '%m/%d/%Y'); +----------------------------------------------------------------------+-----------------+------------+ | operation | startTS | duration | +----------------------------------------------------------------------+-----------------+------------+ | trace | 07:21:19.269181 | 3.05361ms | | ├─session.ExecuteStmt | 07:21:19.269186 | 993.479µs | | │ ├─executor.Compile | 07:21:19.269203 | 325.317µs | | │ └─session.runStmt | 07:21:19.269551 | 604.178µs | | │ └─TableReaderExecutor.Open | 07:21:19.270058 | 64.011µs | | │ └─distsql.Select | 07:21:19.270078 | 31.097µs | | │ └─regionRequest.SendReqCtx | 07:21:19.270210 | 1.92593ms | | │ └─rpcClient.SendRequest, region ID: 260, type: Cop | 07:21:19.270231 | 1.894279ms | | │ └─tikv.RPC | 07:21:19.270232 | 638.566µs | | │ ├─tikv.Wait | 07:21:19.270232 | 36.129µs | | │ │ └─tikv.GetSnapshot | 07:21:19.270232 | 36.129µs | | │ └─tikv.Process | 07:21:19.270268 | 9.578µs | | │ └─tikv.RocksDBBlockRead | 07:21:19.270268 | 9.578µs | | └─*executor.TableReaderExecutor.Next | 07:21:19.270188 | 2.011021ms | +----------------------------------------------------------------------+-----------------+------------+ 14 rows in set (0.00 sec) ``` + テーブル `test.orders` のパーティションプルーニングを再度確認するためにクエリトレースを実行します。2015年以降のデータをクエリしているため、ホットストレージでのクエリスキャンが予想されます。出力から、リージョンID 264 のリージョンがスキャンされていることを観察しますが、これは `storage-performance:high` ラベルが付いた TiKV ノード上にあります。 ```sql TRACE SELECT item, order_date FROM test.orders WHERE order_date BETWEEN STR_TO_DATE('01/01/2018', '%m/%d/%Y') AND STR_TO_DATE('12/31/2020', '%m/%d/%Y'); ``` ```output tidb:db1> TRACE -> SELECT item, order_date FROM test.orders -> WHERE order_date BETWEEN STR_TO_DATE('01/01/2018', '%m/%d/%Y') AND STR_TO_DATE('12/31/2020', '%m/%d/%Y'); +----------------------------------------------------------------------+-----------------+------------+ | operation | startTS | duration | +----------------------------------------------------------------------+-----------------+------------+ | trace | 07:22:01.845194 | 3.520554ms | | ├─session.ExecuteStmt | 07:22:01.845198 | 1.770717ms | | │ ├─executor.Compile | 07:22:01.845213 | 316.007µs | | │ └─session.runStmt | 07:22:01.845548 | 1.403662ms | | │ └─TableReaderExecutor.Open | 07:22:01.846018 | 896.463µs | | │ └─distsql.Select | 07:22:01.846035 | 864.376µs | | │ ├─loadRegion | 07:22:01.846045 | 813.222µs | | │ └─regionRequest.SendReqCtx | 07:22:01.847019 | 1.598742ms | | │ └─rpcClient.SendRequest, region ID: 264, type: Cop | 07:22:01.847036 | 1.569261ms | | │ └─tikv.RPC | 07:22:01.847037 | 1.176324ms | | │ └─tikv.Wait | 07:22:01.847037 | 1ms | | │ └─tikv.GetSnapshot | 07:22:01.847037 | 995.958µs | | └─*executor.TableReaderExecutor.Next | 07:22:01.846982 | 1.689167ms | +----------------------------------------------------------------------+-----------------+------------+ 13 rows in set (0.01 sec) ``` + ご興味がある方は、`test.orders_log` テーブルに対して類似のクエリを試すことができます。これはコールドTiKVノードにのみ配置されます。 ### 手順 6. テーブルと配置ポリシーを削除する ```sql DROP TABLE IF EXISTS test.orders; DROP TABLE IF EXISTS test.orders_log; DROP PLACEMENT POLICY IF EXISTS hot; DROP PLACEMENT POLICY IF EXISTS cold; ``` ```output Query OK, 0 rows affected (0.52 sec) Query OK, 0 rows affected (0.52 sec) Query OK, 0 rows affected (0.53 sec) Query OK, 0 rows affected (0.52 sec) ``` ### 手順 7. TiDB 接続を終了し、TiKV ノードをスケールインします ```sql EXIT ``` ```output tidb:db1> EXIT Bye ``` ```bash tiup cluster scale-in tidb-test --node ${HOST_KV1_PRIVATE_IP}:20161 --yes ``` ```output ... Scaled cluster `tidb-test` in successfully ``` ```bash tiup cluster scale-in tidb-test --node ${HOST_KV2_PRIVATE_IP}:20161 --yes ``` ```output ... Scaled cluster `tidb-test` in successfully ``` ```bash tiup cluster scale-in tidb-test --node ${HOST_KV3_PRIVATE_IP}:20161 --yes ``` ```output ... Scaled cluster `tidb-test` in successfully ``` + ドロップされた`tikv`は数分から数時間でトムストーンになります。その後、pruneコマンドを使ってクリーンできます。待ちたくない場合は、スケールインコマンドで`--force`を使うことができます。しかし、モニタリングサービスとダッシュボードに異常が表示される可能性があります。 ```bash tiup cluster display tidb-test ``` ```output ... Cluster type: tidb Cluster name: tidb-test Cluster version: v7.5.0 Deploy user: tidb SSH type: builtin Dashboard URL: http://10.90.2.59:2379/dashboard Grafana URL: http://10.90.4.204:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.14:9093 alertmanager 10.90.4.14 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.14:3000 grafana 10.90.4.14 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.254:2379 pd 10.90.1.254 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.2.60:2379 pd 10.90.2.60 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.58:2379 pd 10.90.3.58 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.14:9090 prometheus 10.90.4.14 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.2.231:4000 tidb 10.90.2.231 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.3.141:4000 tidb 10.90.3.141 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.4.207:9000 tiflash 10.90.4.207 9000/8123/3930/20170/20292/8234 linux/x86_64 Up /tidb-data/tiflash-9000 /tidb-deploy/tiflash-9000 10.90.1.71:20160 tikv 10.90.1.71 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.71:20161 tikv 10.90.1.71 20161/20181 linux/x86_64 Pending Offline /tidb-data/tikv-20161 /tidb-deploy/tikv-20161 10.90.2.109:20160 tikv 10.90.2.109 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.109:20161 tikv 10.90.2.109 20161/20181 linux/x86_64 Pending Offline /tidb-data/tikv-20161 /tidb-deploy/tikv-20161 10.90.3.221:20160 tikv 10.90.3.221 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.221:20161 tikv 10.90.3.221 20161/20181 linux/x86_64 Pending Offline /tidb-data/tikv-20161 /tidb-deploy/tikv-20161 Total nodes: 15 ``` ### 手順 8. スケールインされた TiKV の剪定 + 状態が `Tombstone` になるまで、数分から数時間かかることがあるので、その後でTiKVをクリーンにすることができます。 ```bash tiup cluster display tidb-test ``` ```output tiup is checking updates for component cluster ... Starting component `cluster`: /home/ec2-user/.tiup/components/cluster/v1.13.1/tiup-cluster display tidb-test Cluster type: tidb Cluster name: tidb-test Cluster version: v7.5.1 Deploy user: ec2-user SSH type: builtin Dashboard URL: http://18.141.56.57:2379/dashboard Grafana URL: http://10.90.4.14:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.14:9093 alertmanager 10.90.4.14 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.14:3000 grafana 10.90.4.14 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.254:2379 pd 10.90.1.254 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.2.60:2379 pd 10.90.2.60 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.58:2379 pd 10.90.3.58 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.14:9090 prometheus 10.90.4.14 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.2.231:4000 tidb 10.90.2.231 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.3.141:4000 tidb 10.90.3.141 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.4.207:9000 tiflash 10.90.4.207 9000/8123/3930/20170/20292/8234 linux/x86_64 Up /tidb-data/tiflash-9000 /tidb-deploy/tiflash-9000 10.90.1.71:20160 tikv 10.90.1.71 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.71:20161 tikv 10.90.1.71 20161/20181 linux/x86_64 Tombstone /tidb-data/tikv-20161 /tidb-deploy/tikv-20161 10.90.2.109:20160 tikv 10.90.2.109 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.109:20161 tikv 10.90.2.109 20161/20181 linux/x86_64 Tombstone /tidb-data/tikv-20161 /tidb-deploy/tikv-20161 10.90.3.221:20160 tikv 10.90.3.221 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.221:20161 tikv 10.90.3.221 20161/20181 linux/x86_64 Tombstone /tidb-data/tikv-20161 /tidb-deploy/tikv-20161 Total nodes: 15 There are some nodes can be pruned: Nodes: [10.90.3.221:20161 10.90.1.71:20161 10.90.2.109:20161] You can destroy them with the command: `tiup cluster prune tidb-test` ``` ```bash tiup cluster prune tidb-test --yes ``` ```output ... Destroy success ``` ## モジュール 5: Prometheus と Grafana モニタリングツールを使用して TiDB を監視する ### 手順 1. TiDB クラスタのステータスを確認する ```bash tiup cluster display tidb-test ``` ```output tiup is checking updates for component cluster ... Starting component `cluster`: /home/ec2-user/.tiup/components/cluster/v1.12.1/tiup-cluster display tidb-test Cluster type: tidb Cluster name: tidb-test Cluster version: v7.5.1 Deploy user: tidb SSH type: builtin Dashboard URL: http://10.90.1.157:2379/dashboard Grafana URL: http://10.90.4.229:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.229:9093 alertmanager 10.90.4.229 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.229:3000 grafana 10.90.4.229 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.157:2379 pd 10.90.1.157 2379/2380 linux/x86_64 Up|UI /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.2.207:2379 pd 10.90.2.207 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.169:2379 pd 10.90.3.169 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.229:9090 prometheus 10.90.4.229 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.127:4000 tidb 10.90.1.127 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.227:4000 tidb 10.90.2.227 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.4.33:9000 tiflash 10.90.4.33 9000/8123/3930/20170/20292/8234 linux/x86_64 Up /tidb-data/tiflash-9000 /tidb-deploy/tiflash-9000 10.90.1.137:20160 tikv 10.90.1.137 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.24:20160 tikv 10.90.2.24 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.198:20160 tikv 10.90.3.198 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 Total nodes: 12 ``` ### 手順 2. Grafana ダッシュボードにログイン + ブラウザを起動し、`Prometheus`と`Grafana`のモニタリング用に次のURLを入力してください: `http://${HOST_MONITOR1_PUBLIC_IP}:3000`。（`${HOST_MONITOR1_PUBLIC_IP}`の取得方法が分からない場合は、講師にお尋ねください）。`Email or username`フィールドに`admin`を入力します。`Password`フィールドにも`admin`を入力します。 ![60%](https://lab-static.pingcap.com/quick-demo/GrafanaSignIn_aa_001_20220623.png) ### 手順 3. Grafana ダッシュボードを探索する + `Search`ページで、`tidb-test`という名前のメニューを展開し、`tidb-test-Overview`をクリックします。 ![60%](https://lab-static.pingcap.com/quick-demo/GrafanaOverview01_aa_001_20220623.png) ![60%](https://lab-static.pingcap.com/quick-demo/GrafanaOverview02_aa_001_20220623.png) + `tidb-test-Overview` の `System-Info` メニューを展開すると、各ノードのCPUとメモリの構成、CPU、メモリ、IO、およびネットワーク使用率などを確認できます。 ![60%](https://lab-static.pingcap.com/quick-demo/SystemInfo_en_001_20220621.png) + `tidb-test-Overview` の `Service Port Status` を展開すると、各サービスのオンラインノード数を確認できます。 ![60%](https://lab-static.pingcap.com/quick-demo/ServicePortStatus_en_001_20220621.png) + `tidb-test-Overview` のPDモニタリングページを展開すると、PDダッシュボードからコンポーネントPDのステータスの概要を取得することができ、主要なメトリクスが表示されます。 ![60%](https://lab-static.pingcap.com/quick-demo/MonitoringIndicatorsForPD_en_001_20220621.png) + `tidb-test-Overview`のTiDBモニタリングページを拡張すると、QPS、TPS、レスポンス遅延の概要を取得でき、これは表示または報告されるモニタリング情報として役立ちます。 ![60%](https://lab-static.pingcap.com/quick-demo/MonitoringIndicatorsForTiDBServer_en_001_20220621.png) + `tidb-test-Overview`のTiKVモニタリングページを展開すると、コンポーネントであるTiKVのステータスを概観することができます。ここでは主要なメトリクスが表示されます。パフォーマンスマップに基づいて、クラスタのステータスが期待通りかどうかを確認できます。 ![60%](https://lab-static.pingcap.com/quick-demo/MonitoringIndicatorsForTiKV_en_001_20220621.png) ## モジュール 6: TiDB Dashboard による TiDB のモニタリング ### 手順 1. TiDB Dashboard へのログイン + [TiDB PD Dashboard](http://${LAB:HOST_PD1_PUBLIC_IP}:2379/dashboard)を開き、ユーザー名として`root`を入力してログインします。これもTiDBの`root`ユーザーです。 ![60%](https://lab-static.pingcap.com/quick-demo/TiDBDashboard_aa_001_20220621.png) ### 手順 2. TiDB ダッシュボードを探索する + `TiDB Dashboard`の`Overview`ページを展開すると、TiDB クラスタのクエリ毎秒 (QPS)、実行時間、最も多くのリソースを消費するSQLステートメントの種類、その他の概要情報を得ることができます。 ![60%](https://lab-static.pingcap.com/quick-demo/DashboardMonitoringMetrics_en_001_20220622.png) + `TiDB Dashboard`の`Cluster Info`ページを展開すると、クラスタ全体のTiDB、TiKV、PD、TiFlashコンポーネントの稼働状況、およびこれらのコンポーネントが配置されているホストの稼働状況を概観できます。もしTiKVノードがまだオフライン保留中の場合、それらのTiKVのステータスが`leaving`と表示されることがあります。 ![60%](https://lab-static.pingcap.com/quick-demo/DashboardClusterInformation_en_001_20220622.png) ## 演習終了