# リソース制御を使用して混合ワークロードを管理 ## 概要 この演習では、TiDB内でリソースグループを効果的に管理する方法について説明します。これにより、重要なワークロードが必要なリソースを確保する一方で、重要度の低いタスクに動的にリソースをアロケーションできることを保証します。以下の図は、データベースセッションへのシステムリソースのアロケーションを決定するためにTiDBが使用する一般的なワークフローを示しており、特にリソースグループの観点に焦点を当てています。このデモンストレーションを通じて、`RU_PER_SEC`、`PRIORITY`、`BURSTABLE`などのリソースグループ属性を使用したハンズオン体験を学びます。 ![40%](https://lab-static.pingcap.com/quick-demo/QuickDemo006_en_001_20230512.png) ### 所要時間 + この演習は約 60 分程度かかります。 ### タスク + デモをセットアップし、`userA`と`userB`のベースラインスループットを観察します。 + リソースグループのリクエストユニット/秒のクォータ（`RU_PER_SEC`属性で制御）を管理することによってTiDBサーバーの実行キューを制御します。 + リソースグループの優先順位（`PRIORITY`属性で制御）を管理することによりTiDBクラスタのスケジューリングキューを制御します。 + `BURSTABLE`をオンにして、`PRIORITY`設定を守りつつ、両方のワークロードにベストエフォートでサービスを提供します。 > [!TIP] > 演習環境を起動するには、**開始**をクリックしてください。 > 環境の準備が整ったら、下部のツールバーで **次のモジュール** を選択して **モジュール 1** に進みます。 > そして、ステップバイステップの演習ガイドに従って、ハンズオン環境に接続し、タスクを開始してください。 ## モジュール 1: テストスキーマの準備とベースラインの観察 ### 手順 1. TiUP コントロールマシンに2つのターミナルで接続します + 以下のリンクをクリックして、演習用仮想マシンへの2つのSSH接続を開きます： + [ターミナル 1](ssh://monitor1-ssh#1) + [ターミナル 2](ssh://monitor1-ssh#2) + これで2つのアクティブなターミナルセッションが開かれます。 + ログイン後に表示されるバナーは以下のようになります。 ```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 クラスタをデプロイして起動する + [ターミナル 1](ssh://monitor1-ssh#1)で、プロビジョニングされたクラスタトポロジーのYAMLを確認します。 ```bash cat nine-nodes.yaml ``` ```output global: user: "ec2-user" ssh_port: 22 deploy_dir: "/tidb-deploy" data_dir: "/tidb-data" arch: "amd64" server_configs: pd: replication.max-replicas: 3 pd_servers: - host: 10.90.2.245 client_port: 2379 peer_port: 2380 advertise_client_addr: "http://13.212.249.174:2379" - host: 10.90.2.19 client_port: 2379 peer_port: 2380 advertise_client_addr: "http://13.212.113.189:2379" - host: 10.90.2.213 client_port: 2379 peer_port: 2380 advertise_client_addr: "http://13.229.88.9:2379" tidb_servers: - host: 10.90.1.92 port: 4000 status_port: 10080 deploy_dir: /tidb-deploy/tidb-4000 log_dir: /tidb-deploy/tidb-4000/log - host: 10.90.1.139 port: 4000 status_port: 10080 deploy_dir: /tidb-deploy/tidb-4000 log_dir: /tidb-deploy/tidb-4000/log tikv_servers: - host: 10.90.3.14 port: 20160 status_port: 20180 - host: 10.90.3.196 port: 20160 status_port: 20180 - host: 10.90.3.96 port: 20160 status_port: 20180 monitoring_servers: - host: 10.90.4.181 grafana_servers: - host: 10.90.4.181 alertmanager_servers: - host: 10.90.4.181 ``` + TiDBクラスタをデプロイするためにシステム構成を修正します。 ```bash tiup mirror set tidb-community-server-tidb_version-linux-amd64 tiup cluster check nine-nodes.yaml \ --user ec2-user \ -i /home/ec2-user/.ssh/pe-class-key-${LAB:REGION_NAME}.pem \ --apply ``` ```output ... + Try to apply changes to fix failed checks + Try to apply changes to fix failed checks + Try to apply changes to fix failed checks - Applying changes on 10.90.1.139 ... ⠧ Sysctl: host=10.90.1.139 vm.swappiness = 0 - Applying changes on 10.90.4.181 ... ⠧ Shell: host=10.90.4.181, sudo=true, command=`if [ -d /sys/kernel/mm/transparent_hugepage ]; then echo never > /sys/kernel/mm/transparent_hugepage/enabled; fi` + Try to apply changes to fix failed checks + Try to apply changes to fix failed checks - Applying changes on 10.90.1.139 ... Done + Try to apply changes to fix failed checks + Try to apply changes to fix failed checks - Applying changes on 10.90.1.139 ... Done - Applying changes on 10.90.4.181 ... Done - Applying changes on 10.90.2.245 ... Done - Applying changes on 10.90.2.19 ... Done - Applying changes on 10.90.3.14 ... Done - Applying changes on 10.90.3.196 ... Done - Applying changes on 10.90.1.92 ... Done - Applying changes on 10.90.2.213 ... Done - Applying changes on 10.90.3.96 ... Done ``` + TiDBクラスタをデプロイします。 ```bash tiup cluster deploy tidb-demo tidb_version ./nine-nodes.yaml \ --user ec2-user \ -i /home/ec2-user/.ssh/pe-class-key-${LAB:REGION_NAME}.pem \ --yes ``` ```output ... Cluster `tidb-demo` deployed successfully, you can start it with command: `tiup cluster start tidb-demo --init` ``` + デプロイされたTiDBクラスタを起動します。 ```bash tiup cluster start tidb-demo ``` ```output ... Started cluster `tidb-demo` successfully ``` + クラスタのステータスを取得するためにコマンドを実行します。3つのPDサーバー、3つのTiKVサーバー、2つのTiDBサーバーがあります。あなたの環境とサンプルの出力は、IPアドレスの詳細において異なるかもしれませんが、サブネットは同じです。 ```bash tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: vtidb_version Deploy user: ec2-user SSH type: builtin Dashboard URL: http://35.92.83.178:2379/dashboard Grafana URL: http://10.90.4.99:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.99:9093 alertmanager 10.90.4.99 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.99:3000 grafana 10.90.4.99 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.3.142:2379 pd 10.90.3.142 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.218:2379 pd 10.90.3.218 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.78:2379 pd 10.90.3.78 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.99:9090 prometheus 10.90.4.99 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.152:4000 tidb 10.90.1.152 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.192:4000 tidb 10.90.1.192 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.183:20160 tikv 10.90.2.183 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.242:20160 tikv 10.90.2.242 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.93:20160 tikv 10.90.2.93 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 Total nodes: 11 ``` ### 手順 3. サンプルワークロードスキーマを準備する + 作業負荷スキーマを準備するスクリプトを確認して実行します。スキーマのセットアップ`DDL`と`tidb-lightning`のサンプルデータをロードには約1分かかります。 ```bash source ./hosts-env.sh mysql -h ${HOST_DB1_PRIVATE_IP} -uroot -P4000 --verbose << 'EOFX' CREATE USER ltask@'%' IDENTIFIED BY 'q1w2e3R4_'; GRANT ALL PRIVILEGES ON *.* TO ltask@'%'; DROP DATABASE IF EXISTS emp; CREATE DATABASE emp; USE emp; CREATE TABLE `sal` ( `emp_no` INT(11) NOT NULL, `salary` INT(11) NOT NULL, `from_date` DATE NOT NULL, `to_date` DATE NOT NULL, PRIMARY KEY (`emp_no`,`from_date`)); EOFX tiup install tidb-lightning:vtidb_version tiup tidb-lightning:vtidb_version -config solution-lightning-csv.toml ``` ```output ... +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ | # | CHECK ITEM | TYPE | PASSED | +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ | 1 | Source data files size is proper | performance | true | +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ | 2 | the checkpoints are valid | critical | true | +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ | 3 | table schemas are valid | critical | true | +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ | 4 | all importing tables on the target are empty | critical | true | +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ | 5 | Cluster version check passed | critical | true | +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ | 6 | Lightning has the correct storage permission | critical | true | +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ | 7 | sorted-kv-dir:/tmp/sorted-kv-dir and data-source-dir:/home/ec2-user/stage/TiDB-Administration-exercise-data-v2/exercise-lightning/ | performance | false | | | Importing-CSV-File are in the same disk, may slow down performance | | | +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ | 8 | local disk resources are rich, estimate sorted data size 6.842MiB, local available is 62.19GiB | critical | true | +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ | 9 | The storage space is rich, which TiKV/Tiflash is 186.3GiB/0B. The estimated storage space is 20.53MiB/0B. | performance | true | +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ | 10 | Cluster doesn't have too many empty regions | performance | true | +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ | 11 | Cluster region distribution is balanced | performance | true | +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ | 12 | no CDC or PiTR task found | critical | true | +----+------------------------------------------------------------------------------------------------------------------------------------+-------------+--------+ tidb lightning exit successfully ``` + `sysbench`スキーマを準備するスクリプトを確認して実行します。セットアッププロセスが完了するまで約2分待ちます。 ```bash source ./hosts-env.sh mysql -h ${HOST_DB1_PRIVATE_IP} -uroot -P4000 --verbose << 'EOFX' CREATE DATABASE sbtest; CREATE USER 'userA'@'%' IDENTIFIED BY 'tidb'; CREATE USER 'userB'@'%' IDENTIFIED BY 'tidb'; GRANT ALL PRIVILEGES ON *.* TO 'userA'@'%'; GRANT ALL PRIVILEGES ON *.* TO 'userB'@'%'; EOFX sysbench '/usr/local/share/sysbench/oltp_read_only.lua' \ --mysql-host=${HOST_DB1_PRIVATE_IP} \ --mysql-port=4000 \ --mysql-user=root \ --mysql-db=sbtest \ --percentile=99 \ --threads=10 \ --tables=32 \ --table-size=100000 \ --report-interval=2 \ --db-driver=mysql prepare ``` ```output ... Initializing worker threads... Creating table 'sbtest4'... Creating table 'sbtest8'... ... Creating table 'sbtest5'... Inserting 100000 records into 'sbtest8' Inserting 100000 records into 'sbtest5' ... Inserting 100000 records into 'sbtest2' Creating a secondary index on 'sbtest5'... ... Creating a secondary index on 'sbtest10'... Creating table 'sbtest15'... Inserting 100000 records into 'sbtest15' Creating a secondary index on 'sbtest15'... Creating table 'sbtest19'... Inserting 100000 records into 'sbtest19' ... Creating table 'sbtest31'... Inserting 100000 records into 'sbtest31' Creating a secondary index on 'sbtest31'... ``` ### 手順 4. サンプルワークロードを開始する + userAによるサンプルOLTPワークロードを開始するスクリプトを確認して実行します。スクリプトを実行し続けて、次のステップに進めます。 ```bash cat lab1-workload-userA.sh ``` ```output #!/bin/bash source ./hosts-env.sh sysbench '/usr/local/share/sysbench/oltp_read_only.lua' \ --mysql-host=${HOST_DB1_PRIVATE_IP} \ --mysql-port=4000 \ --mysql-user=userA \ --mysql-db=sbtest \ --percentile=99 \ --mysql-password=tidb \ --time=300 \ --threads=10 \ --tables=32 \ --table-size=100000 \ --report-interval=2 run ``` ```bash ./lab1-workload-userA.sh ``` ```output sysbench 1.0.17 (using bundled LuaJIT 2.1.0-beta2) Running the test with following options: Number of threads: 10 Report intermediate results every 2 second(s) Initializing random number generator from current time Initializing worker threads... Threads started! [ 2s ] thds: 10 tps: 330.67 qps: 5334.20 (r/w/o: 4668.36/0.00/665.84) lat (ms,99%): 77.19 err/s: 0.00 reconn/s: 0.00 [ 4s ] thds: 10 tps: 370.57 qps: 5916.63 (r/w/o: 5175.99/0.00/740.64) lat (ms,99%): 51.94 err/s: 0.00 reconn/s: 0.00 [ 6s ] thds: 10 tps: 370.49 qps: 5924.77 (r/w/o: 5183.80/0.00/740.97) lat (ms,99%): 49.21 err/s: 0.00 reconn/s: 0.00 [ 8s ] thds: 10 tps: 380.46 qps: 6093.80 (r/w/o: 5332.39/0.00/761.41) lat (ms,99%): 49.21 err/s: 0.00 reconn/s: 0.00 ... ``` + ターミナル2で、userBによる同じOLTPワークロードを開始するスクリプトを実行します。スクリプトを実行し続けて、次のステップに進めます。 ```bash cat lab1-workload-userB.sh ``` ```output #!/bin/bash source ./hosts-env.sh sysbench '/usr/local/share/sysbench/oltp_read_only.lua' \ --mysql-host=${HOST_DB2_PRIVATE_IP} \ --mysql-port=4000 \ --mysql-user=userB \ --mysql-db=sbtest \ --percentile=99 \ --mysql-password=tidb \ --time=300 \ --threads=10 \ --tables=32 \ --table-size=100000 \ --report-interval=2 run ``` ```bash ./lab1-workload-userB.sh ``` ```output sysbench 1.0.17 (using bundled LuaJIT 2.1.0-beta2) Running the test with following options: Number of threads: 10 Report intermediate results every 2 second(s) Initializing random number generator from current time Initializing worker threads... Threads started! [ 2s ] thds: 10 tps: 277.17 qps: 4471.71 (r/w/o: 3913.37/0.00/558.34) lat (ms,99%): 116.80 err/s: 0.00 reconn/s: 0.00 [ 4s ] thds: 10 tps: 274.63 qps: 4390.51 (r/w/o: 3840.76/0.00/549.75) lat (ms,99%): 356.70 err/s: 0.00 reconn/s: 0.00 [ 6s ] thds: 10 tps: 232.94 qps: 3733.50 (r/w/o: 3267.63/0.00/465.88) lat (ms,99%): 189.93 err/s: 0.00 reconn/s: 0.00 [ 8s ] thds: 10 tps: 316.08 qps: 5051.22 (r/w/o: 4419.07/0.00/632.15) lat (ms,99%): 125.52 err/s: 0.00 reconn/s: 0.00 ... ``` ### 手順 5. ベースラインを確認する + [ターミナル 1](ssh://monitor1-ssh#1)と[ターミナル 2](ssh://monitor1-ssh#2)のQPSが類似していることを確認します。これまでリソースコントロールの措置を適用していなかったため、`userA`と`userB`は同じデフォルトリソースグループに属しており、システムリソースの競争において等しい能力を持っています。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-006-setup-v2-20250331.png) + 両方のワークロードを次のモジュールに進む前にCtrl+Cで停止してください。 ## モジュール 2: リクエストユニット/秒のクォータを使用してTiDBサーバーの実行キューを制御する ![40%](https://lab-static.pingcap.com/quick-demo/demo-006-1-en.png) ### 手順 1. 2つのターミナルを開き、それぞれのターミナルでTiUPコントロールマシンにSSHログインします ```bash ssh -i ~/.ssh/pe-class-key-${LAB:REGION_NAME}.pem ec2-user@${LAB:HOST_MONITOR1_PUBLIC_IP} ``` ### 手順 2. ユーザーのRUクォータを設定する + userAとuserBに異なる秒単位のRUクォータを持つリソースグループをセットアップするスクリプトを確認して実行します。 ```bash cat lab1-rc-setup.sh ``` ```output #!/bin/bash source ./hosts-env.sh # For cluster export MYSQL_PS1="tidb:db1> " mysql -h ${HOST_DB1_PRIVATE_IP} -P 4000 -u root --verbose << 'EOFX' ALTER USER userA RESOURCE GROUP default; ALTER USER userB RESOURCE GROUP default; DROP RESOURCE GROUP IF EXISTS rg1; DROP RESOURCE GROUP IF EXISTS rg2; CREATE RESOURCE GROUP rg1 RU_PER_SEC = 500; CREATE RESOURCE GROUP rg2 RU_PER_SEC = 250; ALTER USER userA RESOURCE GROUP rg1; ALTER USER userB RESOURCE GROUP rg2; SELECT * FROM information_schema.resource_groups; SELECT Host, user, User_attributes FROM mysql.user WHERE user IN ('userA','userB'); EOFX ``` ```bash ./lab1-rc-setup.sh ``` ```output ... -------------- SELECT * FROM information_schema.resource_groups -------------- NAME RU_PER_SEC PRIORITY BURSTABLE QUERY_LIMIT BACKGROUND default UNLIMITED MEDIUM YES NULL NULL rg1 500 MEDIUM NO NULL NULL rg2 250 MEDIUM NO NULL NULL -------------- SELECT Host, User, User_attributes FROM mysql.user WHERE user IN ('userA','userB') -------------- Host User User_attributes % userA {"resource_group": "rg1"} % userB {"resource_group": "rg2"} ``` ### 手順 3. ワークロードの開始 + [ターミナル 1](ssh://monitor1-ssh#1)において、`userA`によるOLTPワークロードを開始するスクリプトを実行します。スクリプトを実行し続けて、次のステップに進めます。 ```bash ./lab1-workload-userA.sh ``` + [ターミナル 2](ssh://monitor1-ssh#2)において、userBによるOLTPワークロードを開始するスクリプトを実行します。スクリプトを実行し続けて、次のステップに進めます。 ```bash ./lab1-workload-userB.sh ``` ### 手順 4. 結果を観察する + 約1分間待ちます。`userA`のQPSが`userB`のQPSよりも高いことを確認します。`userA`の`RU_PER_SEC`クォータがより多いためです。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-006-lab-2-1.png) + ユーザー名とパスワードとして`admin/admin`で[Grafana Prometheus Dashboard](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000)にログインし、`tidb-demo-TiDB-Resource-Control` -> `Resource Unit` -> `RU`パネルを見つけ、`rg1`が`rg2`よりも高い`RU_PER_SEC`を持っていることを確認します。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-006-lab-2.png) + 次のモジュールに進む前に、[ターミナル 1](ssh://monitor1-ssh#1)と[ターミナル 2](ssh://monitor1-ssh#2)から両方のワークロードをCtrl+Cで停止してください。 ## モジュール 3: リソースグループの優先順位を使用したTiDBクラスタスケジューリングキューの制御 ![40%](https://lab-static.pingcap.com/quick-demo/demo-006-2-en.png) ### 手順 1. 2つのターミナルを開き、それぞれのターミナルでTiUPコントロールマシンにSSHログインします ```bash ssh -i ~/.ssh/pe-class-key-${LAB:REGION_NAME}.pem ec2-user@${LAB:HOST_MONITOR1_PUBLIC_IP} ``` ### 手順 2. ユーザーのリソースグループの優先順位を設定する + [ターミナル 1](ssh://monitor1-ssh#1)で、`userA`を`(priority:HIGH)`、`userB`を`(priority:MEDIUM)`としてリソースグループをセットアップするスクリプトを確認して実行します。 ```bash cat lab2-rc-setup.sh ``` ```output #!/bin/bash source ./hosts-env.sh # For cluster export MYSQL_PS1="tidb:db1> " mysql -h ${HOST_DB1_PRIVATE_IP} -P 4000 -u root --verbose << 'EOFX' ALTER USER userA RESOURCE GROUP default; ALTER USER userB RESOURCE GROUP default; DROP RESOURCE GROUP IF EXISTS rg1; DROP RESOURCE GROUP IF EXISTS rg2; CREATE RESOURCE GROUP rg1 RU_PER_SEC=50000 PRIORITY=HIGH; CREATE RESOURCE GROUP rg2 RU_PER_SEC=50000 PRIORITY=MEDIUM; ALTER USER userA RESOURCE GROUP rg1; ALTER USER userB RESOURCE GROUP rg2; SELECT * FROM information_schema.resource_groups; SELECT Host,user, User_attributes FROM mysql.user WHERE user IN ('userA','userB'); EOFX ``` ```bash ./lab2-rc-setup.sh ``` ```output ... -------------- SELECT * FROM information_schema.resource_groups -------------- NAME RU_PER_SEC PRIORITY BURSTABLE QUERY_LIMIT BACKGROUND default UNLIMITED MEDIUM YES NULL NULL rg1 50000 HIGH NO NULL NULL rg2 50000 MEDIUM NO NULL NULL -------------- SELECT Host, User, User_attributes FROM mysql.user WHERE user IN ('userA','userB') -------------- Host User User_attributes % userA {"resource_group": "rg1"} % userB {"resource_group": "rg2"} ``` ### 手順 3. ワークロードの開始 + [ターミナル 1](ssh://monitor1-ssh#1)において、userAによるバッチワークロードを開始するスクリプトを実行します（出力はありません）。スクリプトを実行し続けて、次のステップに進めます。 ```bash ./lab2-workload-userA.sh ``` + [ターミナル 2](ssh://monitor1-ssh#2)において、同じバッチワークロードをuserBによって開始するスクリプトを実行します（出力はありません）。スクリプトを実行し続けて、次のステップに進めます。 ```bash ./lab2-workload-userB.sh ``` #### 手順 4. 結果を観察する + 1分間待ち、変更されたパスワードで[Grafana Prometheus Dashboard](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000)にログインし、`tidb-demo-TiDB-Resource-Control` -> `Resource Details` -> `KV CPU Time`を探し、`rg1`が`rg2`よりも多くの`CPU Time`を消費できることを確認してください。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-006-M3-grafana-v2-20250331.png) + 次のモジュールに進む前に、Ctrl+Cを押して両方のワークロードを停止してください。 ## モジュール 4: バースタブル機能の使用 ![40%](https://lab-static.pingcap.com/quick-demo/demo-006-3-en.png) ### 手順 1. 2つのターミナルを開き、それぞれのターミナルでTiUPコントロールマシンにSSHログインします ```bash ssh -i ~/.ssh/pe-class-key-${LAB:REGION_NAME}.pem ec2-user@${LAB:HOST_MONITOR1_PUBLIC_IP} ``` ### 手順 2. バースタブルをオンにして、ベストエフォートで両方のワークロードを提供する + [ターミナル 1](ssh://monitor1-ssh#1)で、userAとuserBに低い秒単位のRUのクォータを設定したバースタブルのリソースグループをセットアップするスクリプトを確認して実行します。スクリプトは、userAにuserBよりも高い優先順位を与えます。 ```bash cat lab3-rc-setup.sh ``` ```output #!/bin/bash source ./hosts-env.sh # For cluster export MYSQL_PS1="tidb:db1> " mysql -h ${HOST_DB1_PRIVATE_IP} -P 4000 -u root --verbose << 'EOFX' ALTER USER userA RESOURCE GROUP default; ALTER USER userB RESOURCE GROUP default; DROP RESOURCE GROUP IF EXISTS rg1; DROP RESOURCE GROUP IF EXISTS rg2; CREATE RESOURCE GROUP rg1 RU_PER_SEC=500 PRIORITY=HIGH BURSTABLE; CREATE RESOURCE GROUP rg2 RU_PER_SEC=500 PRIORITY=MEDIUM BURSTABLE; ALTER USER userA RESOURCE GROUP rg1; ALTER USER userB RESOURCE GROUP rg2; SELECT * FROM information_schema.resource_groups; SELECT Host,user, User_attributes FROM mysql.user WHERE user IN ('userA','userB'); EOFX ``` ```bash ./lab3-rc-setup.sh ``` ```output ... -------------- SELECT * FROM information_schema.resource_groups -------------- NAME RU_PER_SEC PRIORITY BURSTABLE QUERY_LIMIT BACKGROUND default UNLIMITED MEDIUM YES NULL NULL rg1 500 HIGH YES NULL NULL rg2 500 MEDIUM YES NULL NULL -------------- SELECT Host,user, User_attributes FROM mysql.user WHERE user IN ('userA','userB') -------------- Host user User_attributes % userA {"resource_group": "rg1"} % userB {"resource_group": "rg2"} ``` ### 手順 3. ワークロードの開始 + [ターミナル 1](ssh://monitor1-ssh#1)において、userAによるバッチワークロードの開始スクリプトを実行します（出力はありません）が、スクリプトを実行し続けてください。 ```bash ./lab3-workload-userA.sh ``` + [ターミナル 2](ssh://monitor1-ssh#2)において、同じバッチワークロードをuserBによって開始するスクリプトを実行します（出力はありません）スクリプトを実行し続けてください。 ```bash ./lab3-workload-userB.sh ``` ### 手順 4. 結果を観察する + 1分間待ち、変更されたパスワードで[Grafana Prometheus Dashboard](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000)にログインし、`tidb-demo-TiDB-Resource-Control` -> `Resource Details` -> `KV CPU Time`を探します。`BURSTABLE`の設定のため、それらの間の`CPU Time`の違いはモジュール3での差異ほど明確ではないことがわかります。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-006-M4-burstable-grafana-v2-20250331.png) + 次のモジュールに進む前に、Ctrl+Cで両方のワークロードを止めてください。 ## モジュール 5: リソースコントロールを使用した混合ワークロードのパフォーマンス制御 ![40%](https://lab-static.pingcap.com/quick-demo/demo-006-4-en.png) ### 手順 1. 2つのターミナルを開き、それぞれのターミナルでTiUPコントロールマシンにSSHログインする ```bash ssh -i ~/.ssh/pe-class-key-${LAB:REGION_NAME}.pem ec2-user@${LAB:HOST_MONITOR1_PUBLIC_IP} ``` ### 手順 2. ユーザーのデフォルトリソースグループ設定をリセットする + [ターミナル 1](ssh://monitor1-ssh#1)で、userAとuserBをデフォルトリソースグループにリセットするスクリプトを確認して実行します。 ```bash cat lab4-rc-default.sh ``` ```output #!/bin/bash source ./hosts-env.sh # For cluster export MYSQL_PS1="tidb:db1> " mysql -h ${HOST_DB1_PRIVATE_IP} -P 4000 -u root --verbose << 'EOFX' ALTER USER userA RESOURCE GROUP default; ALTER USER userB RESOURCE GROUP default; DROP RESOURCE GROUP IF EXISTS rg1; DROP RESOURCE GROUP IF EXISTS rg2; SELECT * FROM information_schema.resource_groups; SELECT Host,user, User_attributes FROM mysql.user WHERE user IN ('userA','userB'); EOFX ``` ```bash ./lab4-rc-default.sh ``` ```output ... -------------- SELECT * FROM information_schema.resource_groups -------------- NAME RU_PER_SEC PRIORITY BURSTABLE QUERY_LIMIT BACKGROUND default UNLIMITED MEDIUM YES NULL NULL -------------- SELECT Host,user, User_attributes FROM mysql.user WHERE user IN ('userA','userB') -------------- Host user User_attributes % userA {"resource_group": "default"} % userB {"resource_group": "default"} ``` ### 手順 3. デフォルトリソースグループ設定下で混合ワークロードを開始する + [ターミナル 1](ssh://monitor1-ssh#1)において、userAによるサンプルOLTPワークロードを開始するスクリプトを実行してください。スクリプトを実行し続けて、次のステップに進めます。 ```bash ./lab4-workload-userA.sh ``` + [ターミナル 2](ssh://monitor1-ssh#2)において、userBによるサンプルバッチワークロードを開始するスクリプトを実行します（出力はありません）。スクリプトを実行し続けて、次のステップに進めます。 ```bash ./lab4-workload-userB.sh ``` ### 手順 4. デフォルトリソースグループ設定下での結果を観察する + [ターミナル 1](ssh://monitor1-ssh#1)で、userAのOLTPワークロードのQPSを観察します。パフォーマンスがuserBのバッチワークロードによってネガティブに影響を受けていることに注意してください。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-006-lab-4-1.jpeg) + 次のステップに進む前に、両方のワークロードをCtrl+Cで停止してください。 ### 手順 5. リソースグループの設定を使用して選択したワークロードを優先する + [ターミナル 1](ssh://monitor1-ssh#1)で、userAを`(RU_PER_SEC=50000 PRIORITY=HIGH BURSTABLE)`として、userBを`(RU_PER_SEC=500 PRIORITY=MEDIUM)`としてリソースグループをセットアップするスクリプトを実行します。 ```bash cat lab4-rc-setup.sh ``` ```output #!/bin/bash source ./hosts-env.sh # For cluster export MYSQL_PS1="tidb:db1> " mysql -h ${HOST_DB1_PRIVATE_IP} -P 4000 -u root --verbose << 'EOFX' ALTER USER userA RESOURCE GROUP default; ALTER USER userB RESOURCE GROUP default; DROP RESOURCE GROUP IF EXISTS rg1; DROP RESOURCE GROUP IF EXISTS rg2; CREATE RESOURCE GROUP rg1 RU_PER_SEC=50000 PRIORITY=HIGH BURSTABLE; CREATE RESOURCE GROUP rg2 RU_PER_SEC=500 PRIORITY=MEDIUM; ALTER USER userA RESOURCE GROUP rg1; ALTER USER userB RESOURCE GROUP rg2; SELECT * FROM information_schema.resource_groups; SELECT Host,user, User_attributes FROM mysql.user WHERE user IN ('userA','userB'); EOFX ``` ```bash ./lab4-rc-setup.sh ``` ```output ... -------------- SELECT * FROM information_schema.resource_groups -------------- NAME RU_PER_SEC PRIORITY BURSTABLE QUERY_LIMIT BACKGROUND default UNLIMITED MEDIUM YES NULL NULL rg1 50000 HIGH YES NULL NULL rg2 500 MEDIUM NO NULL NULL -------------- SELECT Host,user, User_attributes FROM mysql.user WHERE user IN ('userA','userB') -------------- Host user User_attributes % userA {"resource_group": "rg1"} % userB {"resource_group": "rg2"} ``` ### 手順 6. 混合ワークロードを再び開始する + [ターミナル 1](ssh://monitor1-ssh#1)で、userAによるサンプルOLTPワークロードを再び開始するスクリプトを実行し、スクリプトを実行し続けます。 ```bash ./lab4-workload-userA.sh ``` + [ターミナル 2](ssh://monitor1-ssh#2)で、userBによるサンプルバッチワークロードを再び開始するスクリプトを実行します（出力はありません）が、スクリプトを実行し続けてください。 ```bash ./lab4-workload-userB.sh ``` ### 手順 7. 結果を観察する + [ターミナル 1](ssh://monitor1-ssh#1)で、1分以内に安定するQPSを観察します。結果がステップ4よりもかなり良いことに注意してください。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-006-M5-mixed-workloads-with-RC-v3-20250331.png) + [ターミナル 1](ssh://monitor1-ssh#1)と[ターミナル 2](ssh://monitor1-ssh#2)の両方でCtrl+Cを押して、両方のワークロードを停止してください。 ## 結論 TiDBはペタバイト規模のデータを処理できる分散リレーショナルデータベース管理システム（RDBMS）であり、トランザクションの強い一貫性を保証します。これらの演習を通じてTiDBのリソースコントロール機能に精通することで、MySQL互換の複数のデータベースを単一のTiDBクラスタに統合してメンテナンスタスクを大幅に効率化できます。 デモで示されたベストプラクティスに従うことで、TiDBでのリソースグループ管理を効果的に行うことができ、重要なワークロードに必要なリソースを確保しつつ、重要度の低いタスクに動的にリソースをアロケーションすることができます。優先順位レベルとクォータ制限の慎重なバランスを通じて、リソース使用状況を継続的に監視し、要求に応じて優先順位を調整することにより、リソースアロケーションを最適化し、システム全体のパフォーマンスを向上させることができます。 ```hbsptform { "ui": { "titleLevel": 3 }, "portalId": "4466002", "formId": "62bfb32a-a60a-4f9d-b2dc-1107a93db568", "region": "na1", "sfdcCampaignId": "701RC00000NdFlAYAV" } ```