# TiDB クラスタのサイズ設定とデータ移行
## 概要
TiDB クラスタサイズツールは、TiDB Cloud Dedicated と TiDB Self-Managed 環境の両方向けに設計されています。使用する前に、Lark 上では読み取り専用であるため、別ファイルとして保存することをお勧めします。このツールは、PingCAP のプロフェッショナルおよびパートナーに提供されています。
TiDB と TiKV ノードの構成に関するスクリーンショットの強調表示部分に注意してください。この演習では、演習の TiDB クラスタと同じ構成を使用します。
+ ストレージレイヤー
+ [要入力] レプリカ数: デフォルトは3レプリカです。
+ [要入力] TiKVごとのストレージ: 各TiKVノードには最大ストレージ容量制限があり、4TBです。
+ [要入力] 圧縮比: TiDBでは通常データが圧縮されます。推定値は40%です。
+ [要入力] ストレージ容量しきい値（ストレージウォーターレベル）: 正常なシステム運用を維持し、ストレージの過負荷を避けるために、管理者は通常80%のようなストレージ使用量アラートのしきい値を定義します。
+ SQLレイヤー
+ [要入力] 合計QPS: TiDB クラスタの合計の望ましいQPS。
+ [テスト結果で定義] ノードごとのQPS: ある遅延要件の下で単一ノードが処理可能なQPS。
+ [テスト結果で定義] パフォーマンス減衰係数: ノードの数が増えるにつれて、ネットワーク遅延やリソース競合などにより、個々のノードのパフォーマンスが低下することがあります。
### 所要時間
+ この演習は約 90 分程度かかります。
### ソースデータ量とTiKVサーバーの数
最小TiKVサーバー数 = `CEIL(既存データサイズ x 圧縮率 / キャパシティしきい値 / TiKVノードストレージスペース) x リージョンレプリカ数`
### パフォーマンス要件とTiKVおよびTiDBサーバーの数
最小TiDB/TiKVサーバー数 = `CEIL(合計QPS / ノードごとのQPS x (1 - パフォーマンス減衰係数))`
### タスク
+ 現在のMySQLデータベースのボリュームに基づいて、TiDBストレージレイヤーのサイズを見積もります。
+ MySQLデータベースをTiDBクラスタに移行し、TiDBストレージレイヤーの見積もりを確認します。
+ 現在のワークロードに基づいて、TiDBとTiKVのサイズを見積もります。
+ スケールアウト操作後のパフォーマンス改善を観察します。
> [!TIP]
> 演習環境を起動するには、**開始**をクリックしてください。
> 環境の準備が整ったら、下部のツールバーで **次のモジュール** を選択して **モジュール 1** に進みます。
> そして、ステップバイステップの演習ガイドに従って、ハンズオン環境に接続し、タスクを開始してください。
## モジュール 1︓既存の MySQL データベースボリュームに基づいて TiDB ストレージレイヤーのサイズを決定する
### 手順 1. Linux マシンにログインする
+ ここをクリック - [ターミナル1](ssh://monitor1-ssh#1) して演習マシンに接続された新しいターミナルを開き、MySQLサーバーに接続して`sbtest`データベースのデータサイズを取得するクエリを実行します。
+ ログイン後に表示されるバナーは次のようになります。
```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. 既存の MySQL データベースのデータボリューム概要を取得する
+ MySQLサーバーノードに接続します。プロンプトが表示されたら、`yes`と答えます。
```bash
ssh -i /home/ec2-user/.ssh/pe-class-key-${LAB:REGION_NAME}.pem rocky@${HOST_MYSQL1_PRIVATE_IP}
```
```output
Last login: Thu Aug 1 11:58:47 2024 from 10.90.4.90
[rocky@ip-10-90-1-235 ~]$
```
+ データベースユーザー`root`としてMySQLサーバーに接続します。
```bash
mysql -h localhost -P 3306 -u root -pq1w2e3R4_ --connect-expired-password
```
```output
mysql>
```
+ `sbtest` データベース内のテーブルとデータを確認します。`sbtest` データベースは既に Sysbench によって初期化されています。
```sql
SHOW DATABASES;
```
```output
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sbtest |
| sys |
+--------------------+
5 rows in set (0.01 sec)
```
```sql
SHOW TABLES FROM sbtest;
```
```output
+------------------+
| Tables_in_sbtest |
+------------------+
| sbtest1 |
| sbtest2 |
| sbtest3 |
| sbtest4 |
| sbtest5 |
| sbtest6 |
+------------------+
6 rows in set (0.00 sec)
```
+ テーブル `sbtest.sbtest1` のスキーマと行数を確認します。それは、`sbtest2`、`sbtest3`、`sbtest4`、`sbtest5`、および `sbtest6` と類似しています。これには約1分かかります。
```sql
DESC sbtest.sbtest1;
```
```output
+-------+-----------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------+-----------+------+-----+---------+----------------+
| id | int | NO | PRI | NULL | auto_increment |
| k | int | NO | MUL | 0 | |
| c | char(120) | NO | | | |
| pad | char(60) | NO | | | |
+-------+-----------+------+-----+---------+----------------+
4 rows in set (0.00 sec)
```
```sql
SELECT COUNT(id) FROM sbtest.sbtest1;
```
```output
+-----------+
| COUNT(id) |
+-----------+
| 10000000 |
+-----------+
1 row in set (32.49 sec)
```
+ データベース `sbtest` で `ANALYZE` コマンドを実行します。
```sql
ANALYZE TABLE sbtest.sbtest1, sbtest.sbtest2, sbtest.sbtest3, sbtest.sbtest4, sbtest.sbtest5, sbtest.sbtest6;
```
```output
+----------------+---------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+----------------+---------+----------+----------+
| sbtest.sbtest1 | analyze | status | OK |
| sbtest.sbtest2 | analyze | status | OK |
| sbtest.sbtest3 | analyze | status | OK |
| sbtest.sbtest4 | analyze | status | OK |
| sbtest.sbtest5 | analyze | status | OK |
| sbtest.sbtest6 | analyze | status | OK |
+----------------+---------+----------+----------+
6 rows in set (40.95 sec)
```
+ データサイズを取得します。`sbtest`データベースのデータサイズは約`13.43GB`です。
```sql
SELECT CONCAT(ROUND(SUM((data_length + index_length)/1024/1024/1024),2), 'GB') AS data
FROM information_schema.tables
WHERE table_schema='sbtest';
```
```output
+---------+
| data |
+---------+
| 13.43GB |
+---------+
1 row in set (0.00 sec)
```
+ OSコマンドを使用してデータサイズを確認します。`sbtest`データベースの`datadir`パスを取得します。
```sql
SHOW GLOBAL VARIABLES LIKE "%datadir%";
```
```output
+---------------+-----------------+
| Variable_name | Value |
+---------------+-----------------+
| datadir | /var/lib/mysql/ |
+---------------+-----------------+
1 row in set (0.00 sec)
```
+ OSプロンプトに戻ります。
```sql
EXIT
```
```output
bye
```
+ `sbtest` データベース内のテーブルのデータファイルを一覧表示します。データの総サイズは約 `14GB` であるはずです。
```bash
sudo ls -lh /var/lib/mysql/sbtest
```
```output
total 14G
-rw-r-----. 1 mysql mysql 2.3G Jul 23 06:22 sbtest1.ibd
-rw-r-----. 1 mysql mysql 2.3G Jul 23 06:22 sbtest2.ibd
-rw-r-----. 1 mysql mysql 2.3G Jul 23 06:22 sbtest3.ibd
-rw-r-----. 1 mysql mysql 2.3G Jul 23 06:22 sbtest4.ibd
-rw-r-----. 1 mysql mysql 2.3G Jul 23 06:22 sbtest5.ibd
-rw-r-----. 1 mysql mysql 2.3G Jul 23 06:22 sbtest6.ibd
```
### 手順 3. TiDB のストレージ容量を見積もる
+ MySQL データベース内の `sbtest` のサイズを SQL クエリの結果として使用します。これはサイズツールのデータ容量入力であり、`13.43GB` です。
+ サイズツールを使用して TiDB 内の `sbtest` データベースのストレージサイズを見積もります。
+ 次の公式を使用してデータサイズを計算します：`TiKV データ容量 = (既存データサイズ) x (圧縮率) x (TiKV内のレプリカ数)`。圧縮率は、異なるデータタイプやコンテンツによって変わります。圧縮率は事前に計算することはできず、データが実際に TiKV クラスタにインポートされた後にのみ決定されます。初めから 35% から 50% の範囲を考慮して使用することを忘れないでください。
+ 推定TiKVデータ容量 = `(既存データサイズ) x (圧縮率) x (TiKV内のレプリカ数)`
+ 推定TiKVデータ容量 = `(13.43 GB) x (35% ~ 50%) x (3)`
+ 推定TiKVデータ容量 = `14.10 GB ~ 20.15 GB`
+ TiKVに必要なデータストレージ容量は、14.10 GBから20.15 GBの間であると見積もられます。移行ステップの後で、この値を確認します。
## モジュール 2: サンプルデータベースを MySQL から TiDB に移行する
### 手順 1. TiUP コントロールマシンに接続する
+ ここをクリック - [ターミナル2](ssh://monitor1-ssh#2) して TiUP コントロールマシンに接続します。
+ ログイン後に表示されるバナー：
```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. 移行目的のために MySQL で作成する
+ 移行目的のためにMySQLで専用ユーザー `dm_user` を作成します。SSHコマンドでプロンプトが表示された場合は、`yes` と答えてください。
```bash
ssh -i /home/ec2-user/.ssh/pe-class-key-${LAB:REGION_NAME}.pem rocky@${HOST_MYSQL1_PRIVATE_IP}
```
```output
[rocky@ip-10-90-1-38 ~]$
```
```bash
X=q1w2e3R4_
mysql -h localhost -P 3306 -uroot -p$X --connect-expired-password << EOF
DROP USER IF EXISTS dm_user@'%';
CREATE USER dm_user@'%' IDENTIFIED BY 'q1w2e3R4_';
GRANT ALL PRIVILEGES ON *.* TO dm_user@'%';
EXIT
EOF
```
```output
mysql: [Warning] Using a password on the command line interface can be insecure.
```
+ TiUPコントロールマシンへの退出。
```bash
exit
```
```output
logout
Connection to 10.90.1.38 closed.
```
### 手順 2. TiDB クラスタをデプロイして開始します
+ プロビジョニングされたクラスタトポロジーYAMLを確認します。
```bash
cat topology.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.11
client_port: 2379
peer_port: 2380
advertise_client_addr: "http://34.221.120.15:2379"
tidb_servers:
- host: 10.90.1.173
port: 4000
status_port: 10080
deploy_dir: /tidb-deploy/tidb-4000
log_dir: /tidb-deploy/tidb-4000/log
tikv_servers:
- host: 10.90.1.233
port: 20160
status_port: 20180
- host: 10.90.1.79
port: 20160
status_port: 20180
- host: 10.90.1.242
port: 20160
status_port: 20180
monitoring_servers:
- host: 10.90.4.90
grafana_servers:
- host: 10.90.4.90
alertmanager_servers:
- host: 10.90.4.90
tiproxy_servers:
- host: 10.90.4.90
```
+ TiDBクラスタをデプロイするために、システム構成を修正します。
```bash
~/.tiup/bin/tiup mirror set tidb-community-server-tidb_version-linux-amd64
~/.tiup/bin/tiup cluster check topology.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
- Applying changes on 10.90.2.239 ... ⠴ Sysctl: host=10.90.2.239 vm.swappiness = 0
- Applying changes on 10.90.1.190 ... ⠴ Sysctl: host=10.90.1.190 vm.swappiness = 0
- Applying changes on 10.90.1.233 ... ⠴ Sysctl: host=10.90.1.233 vm.swappiness = 0
+ Try to apply changes to fix failed checks
+ Try to apply changes to fix failed checks
- Applying changes on 10.90.2.239 ... Done
- Applying changes on 10.90.1.190 ... Done
- Applying changes on 10.90.1.233 ... Done
- Applying changes on 10.90.1.136 ... Done
- Applying changes on 10.90.1.42 ... Done
- Applying changes on 10.90.4.231 ... Done
```
+ TiDB クラスタをデプロイします。
```bash
~/.tiup/bin/tiup cluster deploy tidb-demo tidb_version ./topology.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/bin/tiup cluster start tidb-demo
```
```output
...
Started cluster `tidb-demo` successfully
```
+ TiDBクラスタのステータスを確認します。`tidb-demo` TiDBクラスタには1つのTiDBサーバーと3つのTiKVサーバーがあり、`TiProxy`は`Alert Manager`、`Grafana`、および`Prometheus`と同じノードにデプロイされています。
```bash
~/.tiup/bin/tiup cluster display tidb-demo
```
```output
Cluster type: tidb
Cluster name: tidb-demo
Cluster version: v6.5.9
Deploy user: ec2-user
SSH type: builtin
Dashboard URL: http://34.221.120.15:2379/dashboard
Grafana URL: http://10.90.4.90:3000
ID Role Host Ports OS/Arch Status Data Dir Deploy Dir
-- ---- ---- ----- ------- ------ -------- ----------
10.90.4.90:9093 alertmanager 10.90.4.90 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093
10.90.4.90:3000 grafana 10.90.4.90 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000
10.90.2.11:2379 pd 10.90.2.11 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379
10.90.4.90:9090 prometheus 10.90.4.90 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090
10.90.1.173:4000 tidb 10.90.1.173 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000
10.90.1.233:20160 tikv 10.90.1.233 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
10.90.1.242:20160 tikv 10.90.1.242 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
10.90.1.79:20160 tikv 10.90.1.79 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
10.90.4.90:6000 tiproxy 10.90.4.90 6000/3080 linux/x86_64 Up - /tidb-deploy/tiproxy-6000
Total nodes: 9
```
### 手順 3. 移行目的のために TiDB を準備する
+ 移行目的のために TiDB に専用ユーザー `dm_user` を作成します。
```bash
mysql -h ${HOST_DB1_PRIVATE_IP} -P 4000 -uroot << 'EOF'
DROP USER IF EXISTS dm_user@'%';
CREATE USER dm_user@'%' identified by 'q1w2e3R4_';
GRANT ALL PRIVILEGES ON *.* TO dm_user@'%';
EXIT
EOF
```
+ TiDBでターゲットのリレーショナルデータベース`sbtest`とその空のテーブルを作成します。カラム`id`が`AUTO_INCREMENT`ではなく`AUTO_RANDOM`に設定されていることに注意してください。`AUTO_RANDOM`はホットスポットパフォーマンスの問題を回避するためのTiDBの特徴機能です。`AUTO_RANDOM`について詳しく学びたい方は、自己ペースで進めるワークショップ[TiDB Workshop for MySQL Users](https://eng.edu.pingcap.com/catalog/info/id:231)にご参加ください。
```bash
mysql -h ${HOST_DB1_PRIVATE_IP} -P 4000 -uroot << 'EOF'
CREATE DATABASE sbtest;
CREATE TABLE `sbtest`.`sbtest1` (
`id` bigint NOT NULL AUTO_RANDOM,
`k` int NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
CREATE TABLE `sbtest`.`sbtest2` (
`id` bigint NOT NULL AUTO_RANDOM,
`k` int NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
CREATE TABLE `sbtest`.`sbtest3` (
`id` bigint NOT NULL AUTO_RANDOM,
`k` int NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
CREATE TABLE `sbtest`.`sbtest4` (
`id` bigint NOT NULL AUTO_RANDOM,
`k` int NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
CREATE TABLE `sbtest`.`sbtest5` (
`id` bigint NOT NULL AUTO_RANDOM,
`k` int NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
CREATE TABLE `sbtest`.`sbtest6` (
`id` bigint NOT NULL AUTO_RANDOM,
`k` int NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
SET GLOBAL allow_auto_random_explicit_insert = true;
USE sbtest;
SHOW TABLES;
EXIT
EOF
```
```output
Tables_in_sbtest
sbtest1
sbtest2
sbtest3
sbtest4
sbtest5
sbtest6
```
### 手順 4. TiDB Data Migration クラスタをデプロイします
+ TiDB Data Migration コンポーネントをインストールします。
```bash
~/.tiup/bin/tiup install dm dmctl:vtidb_version dm-master:vtidb_version dm-worker:vtidb_version
```
```bash
~/.tiup/bin/tiup list --verbose | grep dm
```
```output
dm pingcap v1.15.1,v1.16.0 linux/amd64 Data Migration Platform manager
dm-master pingcap v8.0.0,vtidb_version linux/amd64 dm-master component of Data Migration Platform.
dm-worker pingcap v8.0.0,vtidb_version linux/amd64 dm-worker component of Data Migration Platform.
dmctl pingcap v6.5.1,v6.5.9,v7.5.0,vtidb_version linux/amd64 dmctl component of Data Migration Platform.
```
+ TiDB Data Migration クラスタのトポロジー構成ファイルは既にプロビジョニングされています。構成を確認してください、変更は必要ありません。
```bash
cat dm-topology.yaml
```
```output
global:
user: "ec2-user"
ssh_port: 22
deploy_dir: "/tidb-deploy"
data_dir: "/tidb-data"
arch: "amd64"
master_servers:
- host: 10.90.4.191
worker_servers:
- host: 10.90.3.49
- host: 10.90.3.71
- host: 10.90.3.135
monitoring_servers:
- host: 10.90.1.7
grafana_servers:
- host: 10.90.1.7
alertmanager_servers:
- host: 10.90.1.7
```
+ TiDB Data Migration クラスタをデプロイして開始する - `dm-test`。
```bash
~/.tiup/bin/tiup dm deploy dm-test vtidb_version ./dm-topology.yaml \
--user ec2-user \
-i /home/ec2-user/.ssh/pe-class-key-${LAB:REGION_NAME}.pem \
--yes
```
```output
Starting component dm: /home/ec2-user/.tiup/components/dm/v1.16.0/tiup-dm deploy dm-test vtidb_version ./dm-topology.yaml --user ec2-user -i /home/ec2-user/.ssh/pe-class-key-${LAB:REGION_NAME}.pem --yes
+ Detect CPU Arch Name
- Detecting node 10.90.4.191 Arch info ... Done
- Detecting node 10.90.3.49 Arch info ... Done
- Detecting node 10.90.3.71 Arch info ... Done
- Detecting node 10.90.3.135 Arch info ... Done
- Detecting node 10.90.1.7 Arch info ... Done
...
Cluster `dm-test` deployed successfully, you can start it with command: `tiup dm start dm-test`
```
+ TiDB Data Migration クラスタを開始します - `dm-test`。
```bash
~/.tiup/bin/tiup dm start dm-test
```
```output
Starting component dm: /home/ec2-user/.tiup/components/dm/v1.16.0/tiup-dm start dm-test
Starting cluster dm-test...
+ [ Serial ] - SSHKeySet: privateKey=/home/ec2-user/.tiup/storage/dm/clusters/dm-test/ssh/id_rsa, publicKey=/home/ec2-user/.tiup/storage/dm/clusters/dm-test/ssh/id_rsa.pub
+ [Parallel] - UserSSH: user=ec2-user, host=10.90.1.7
+ [Parallel] - UserSSH: user=ec2-user, host=10.90.3.71
+ [Parallel] - UserSSH: user=ec2-user, host=10.90.1.7
+ [Parallel] - UserSSH: user=ec2-user, host=10.90.4.191
+ [Parallel] - UserSSH: user=ec2-user, host=10.90.1.7
+ [Parallel] - UserSSH: user=ec2-user, host=10.90.3.49
+ [Parallel] - UserSSH: user=ec2-user, host=10.90.3.135
+ [ Serial ] - StartCluster
Starting component dm-master
Starting instance 10.90.4.191:8261
Start instance 10.90.4.191:8261 success
Starting component dm-worker
Starting instance 10.90.3.135:8262
Starting instance 10.90.3.49:8262
Starting instance 10.90.3.71:8262
Start instance 10.90.3.135:8262 success
Start instance 10.90.3.71:8262 success
Start instance 10.90.3.49:8262 success
Starting component prometheus
Starting instance 10.90.1.7:9090
Start instance 10.90.1.7:9090 success
Starting component grafana
Starting instance 10.90.1.7:3000
Start instance 10.90.1.7:3000 success
Starting component alertmanager
Starting instance 10.90.1.7:9093
Start instance 10.90.1.7:9093 success
Started cluster `dm-test` successfully
```
+ TiDB Data Migration クラスタの状態が稼働していることを確認します。
```bash
tiup dm display dm-test
```
```output
Starting component dm: /home/ec2-user/.tiup/components/dm/v1.16.0/tiup-dm display dm-test
Cluster type: dm
Cluster name: dm-test
Cluster version: vtidb_version
Deploy user: ec2-user
SSH type: builtin
Grafana URL: http://10.90.3.188:3000
ID Role Host Ports OS/Arch Status Data Dir Deploy Dir
-- ---- ---- ----- ------- ------ -------- ----------
10.90.3.188:9093 alertmanager 10.90.3.188 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093
10.90.4.196:8261 dm-master 10.90.4.196 8261/8291 linux/x86_64 Healthy|L /tidb-data/dm-master-8261 /tidb-deploy/dm-master-8261
10.90.4.196:8262 dm-worker 10.90.4.196 8262 linux/x86_64 Free /tidb-data/dm-worker-8262 /tidb-deploy/dm-worker-8262
10.90.3.188:3000 grafana 10.90.3.188 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000
10.90.3.188:9090 prometheus 10.90.3.188 9090 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090
Total nodes: 5
```
### 手順 5. 移行タスクのソース設定を行う
+ タスクソースの設定を作成します。
```bash
cat << EOF > mysql-source-conf1.yaml
source-id: "mysql-replica-01"
from:
host: "${HOST_MYSQL1_PRIVATE_IP}"
port: 3306
user: "dm_user"
password: "q1w2e3R4_"
EOF
cat mysql-source-conf1.yaml
```
```output
source-id: "mysql-replica-01"
from:
host: "10.90.1.135"
port: 3306
user: "dm_user"
password: "q1w2e3R4_"
```
+ MySQLインスタンスを移行ソースとして設定し、そのソースがTiDB Data Migrationクラスタによって認識できることを確認します。
```bash
~/.tiup/bin/tiup dmctl:vtidb_version \
--master-addr=${HOST_MONITOR1_PRIVATE_IP}:8261 operate-source create mysql-source-conf1.yaml
```
```output
Starting component dmctl: /home/ec2-user/.tiup/components/dmctl/vtidb_version/dmctl/dmctl --master-addr=10.90.4.66:8261 operate-source create mysql-source-conf1.yaml
{
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"source": "mysql-replica-01",
"worker": "dm-10.90.3.187-8262"
}
]
}
```
```bash
~/.tiup/bin/tiup dmctl:vtidb_version \
--master-addr=${HOST_MONITOR1_PRIVATE_IP}:8261 get-config source mysql-replica-01
```
```output
Starting component dmctl: /home/ec2-user/.tiup/components/dmctl/vtidb_version/dmctl/dmctl --master-addr=10.90.4.66:8261 get-config source mysql-replica-01
{
"result": true,
"msg": "",
"cfg": "enable: true\nenable-gtid: false\nauto-fix-gtid: false\nrelay-dir: relay-dir\nmeta-dir: \"\"\nflavor: mysql\ncharset: \"\"\nenable-relay: false\nrelay-binlog-name: \"\"\nrelay-binlog-gtid: \"\"\nsource-id: mysql-replica-01\nfrom:\n host: 10.90.1.135\n port: 3306\n user: dm_user\n password: '******'\n max-allowed-packet: null\n session: {}\n security: null\npurge:\n interval: 3600\n expires: 0\n remain-space: 15\nchecker:\n check-enable: true\n backoff-rollback: 5m0s\n backoff-max: 5m0s\n check-interval: 5s\n backoff-min: 1s\n backoff-jitter: true\n backoff-factor: 2\nserver-id: 429530419\ntracer: {}\ncase-sensitive: false\nfilters: []\n"
}
```
```bash
~/.tiup/bin/tiup dmctl:vtidb_version \
--master-addr=${HOST_MONITOR1_PRIVATE_IP}:8261 operate-source show
```
```output
Starting component dmctl: /home/ec2-user/.tiup/components/dmctl/vtidb_version/dmctl/dmctl --master-addr=10.90.4.66:8261 operate-source show
{
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"source": "mysql-replica-01",
"worker": "dm-10.90.3.187-8262"
}
]
}
```
### 手順 6. 移行タスクの設定を作成し、移行タスクを開始します
+ 移行タスクは、MySQLサーバーからTiDBクラスタにデータベース`sbtest`を移行します。
+ 移行タスク設定を生成します。
```bash
cat << EOF > dm-task.yaml
name: "dm-task"
task-mode: all
ignore-checking-items: ["auto_increment_ID"]
target-database:
host: "${HOST_DB1_PRIVATE_IP}"
port: 4000
user: "dm_user"
password: "q1w2e3R4_"
mysql-instances:
- source-id: "mysql-replica-01"
route-rules: ["instance-1-user-schema-rule"]
block-allow-list: "rule_1"
mydumper-config-name: "global"
loader-config-name: "global"
routes:
instance-1-user-schema-rule:
schema-pattern: "sbtest"
target-schema: "sbtest"
block-allow-list:
rule_1:
do-dbs: ["sbtest"]
mydumpers:
global:
threads: 32
chunk-filesize: 64
loaders:
global:
pool-size: 8
import-mode: "physical"
pd-addr: "${HOST_PD1_PRIVATE_IP}:2379"
EOF
cat dm-task.yaml
```
```output
name: "dm-task"
task-mode: all
ignore-checking-items: ["auto_increment_ID"]
...
loaders:
global:
pool-size: 32
import-mode: "physical"
```
+ 移行タスクを事前に確認してください。メッセージは `pre-check is passed` である必要があります。
```bash
~/.tiup/bin/tiup dmctl:vtidb_version \
--master-addr=${HOST_MONITOR1_PRIVATE_IP}:8261 check-task ./dm-task.yaml
```
```output
Starting component dmctl: /home/ec2-user/.tiup/components/dmctl/vtidb_version/dmctl/dmctl --master-addr=10.90.4.235:8261 check-task ./dm-task.yaml
{
"result": true,
"msg": "pre-check is passed. "
}
```
+ マイグレーションタスクを開始し、マイグレーションの進行状況を確認します。
+ マイグレーションタスクは、3つのサブタスクユニットで構成されます：`Dump`、`Load`、`Sync`。
```bash
~/.tiup/bin/tiup dmctl:vtidb_version \
--master-addr=${HOST_MONITOR1_PRIVATE_IP}:8261 start-task ./dm-task.yaml
```
```output
Starting component dmctl: /home/ec2-user/.tiup/components/dmctl/vtidb_version/dmctl/dmctl --master-addr=10.90.4.66:8261 start-task ./dm-task.yaml
{
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"source": "mysql-replica-01",
"worker": "dm-10.90.3.187-8262"
}
],
"checkResult": "pre-check is passed. "
}
```
### 手順 7. 移行の進捗を確認する
+ `query-status` アクションを何度か使って、移行の進捗を確認します。`subTaskStatus` の `stage`、`unit`、`progress` 属性に注目してください。
+ `watch` コマンドを使用して、全体のタスクの進捗を監視します。演習環境の設定に基づいて（PoCではないため、ハンズオン演習には低スペックなサーバーを使用しています）、約8分かかる可能性があります（Dump: 4分、Load: 4分）。コーヒーを一杯飲む時間があります。
+ ユニット `Dump`、段階 `Running`
```bash
watch -n 1 -d ./.tiup/bin/tiup dmctl:vtidb_version --master-addr=${HOST_MONITOR1_PRIVATE_IP}:8261 query-status ./dm-task.yaml
```
```output
Starting component dmctl: /home/ec2-user/.tiup/components/dmctl/vtidb_version/dmctl/dmctl --master-addr=10.90.4.235:8261 query-status ./dm-task.yaml
{
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"sourceStatus": {
"source": "mysql-replica-01",
"worker": "dm-10.90.1.147-8262",
"result": null,
"relayStatus": null
},
"subTaskStatus": [
{
"name": "dm-task",
"stage": "Running",
"unit": "Dump",
"result": null,
"unresolvedDDLLockID": "",
"dump": {
"totalTables": "6",
"completedTables": 3,
"finishedBytes": 7949200595,
"finishedRows": 39359277,
"estimateTotalRows": 59224808,
"bps": "57472325",
"progress": "64.63 %"
},
"validation": null
}
]
}
]
}
```
+ ユニット`Load`、段階`Running`:
```output
Starting component dmctl: /home/ec2-user/.tiup/components/dmctl/vtidb_version/dmctl/dmctl --master-addr=10.90.4.196:8261 query-status ./dm-task.yaml
{
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"sourceStatus": {
"source": "mysql-replica-01",
"worker": "dm-10.90.4.196-8262",
"result": null,
"relayStatus": null
},
"subTaskStatus": [
{
"name": "dm-task",
"stage": "Running",
"unit": "Load",
"result": null,
"unresolvedDDLLockID": "",
"load": {
"finishedBytes": "5307344924",
"totalBytes": "8161057816",
"progress": "65.03 %",
"metaBinlog": "(binlog.000008, 157240317)",
"metaBinlogGTID": "",
"bps": "62882221"
},
"validation": null
}
]
}
]
}
```
+ ユニット `Sync`、段階 `Running`。ターゲットTiDBとソースMySQLが同期されていることに注意してください。
```output
Starting component dmctl: /home/ec2-user/.tiup/components/dmctl/vtidb_version/dmctl/dmctl --master-addr=10.90.4.196:8261 query-status ./dm-task.yaml
{
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"sourceStatus": {
"source": "mysql-replica-01",
"worker": "dm-10.90.4.196-8262",
"result": null,
"relayStatus": null
},
"subTaskStatus": [
{
"name": "dm-task",
"stage": "Running",
"unit": "Sync",
"result": null,
"unresolvedDDLLockID": "",
"sync": {
"totalEvents": "19767046",
"totalTps": "21118",
"recentTps": "0",
"masterBinlog": "(binlog.000011, 706201359)",
"masterBinlogGtid": "",
"syncerBinlog": "(binlog.000011, 706201359)",
"syncerBinlogGtid": "00000000-0000-0000-0000-000000000000:0",
"blockingDDLs": [
],
"unresolvedGroups": [
],
"synced": true,
"binlogType": "remote",
"secondsBehindMaster": "0",
"blockDDLOwner": "",
"conflictMsg": "",
"totalRows": "19767046",
"totalRps": "21118",
"recentRps": "0"
},
"validation": null
}
]
}
]
}
```
+ `Sync` ユニットが `"synced": true` に達した場合、Ctrl+C キーを押して `watch` コマンドを停止します。
### 手順 8. TiDB のストレージレイヤーのサイズ推定を確認する
+ TiDBで`sbtest`データベースのデータボリュームを取得する方法は3つあります。
+ 方法1: SQLを実行してデータサイズを取得します。結果には`sbtest`データベースのデータボリュームのみが含まれます。
+ MySQLに接続し、データサイズのクエリを実行します。
```bash
mysql -h ${HOST_MONITOR1_PRIVATE_IP} -P 6000 -uroot
```
```output
mysql>
```
+ `sbtest`データベースのすべてのテーブルを分析します。
```sql
ANALYZE TABLE sbtest.sbtest1, sbtest.sbtest2, sbtest.sbtest3, sbtest.sbtest4, sbtest.sbtest5, sbtest.sbtest6;
```
```output
Query OK, 0 rows affected, 6 warnings (22.93 sec)
```
+ システムテーブルを取得してデータサイズを確認します。
```sql
SELECT db_name, SUM(approximate_size)/1024 size_GB
FROM information_schema.TIKV_REGION_STATUS
WHERE db_name='sbtest'
GROUP BY db_name;
```
```output
+---------+---------+
| db_name | size_GB |
+---------+---------+
| sbtest | 17.3232 |
+---------+---------+
1 row in set (0.01 sec)
```
+ 方法2：OSコマンドを使用してデータファイルのストレージを確認します。データボリュームの結果には、`sbtest`データベースだけでなく、他のメタデータも含まれています。
+ OSプロンプトに戻ります。
```sql
EXIT
```
```output
logout
Connection to 10.90.1.132 closed.
```
+ TiKVノードのデータディレクトリを取得します。
```bash
~/.tiup/bin/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://34.217.88.220:2379/dashboard
Grafana URL: http://10.90.4.32:3000
ID Role Host Ports OS/Arch Status Data Dir Deploy Dir
-- ---- ---- ----- ------- ------ -------- ----------
10.90.4.32:9093 alertmanager 10.90.4.32 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093
10.90.4.32:3000 grafana 10.90.4.32 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000
10.90.2.124:2379 pd 10.90.2.124 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379
10.90.4.32:9090 prometheus 10.90.4.32 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090
10.90.1.176:4000 tidb 10.90.1.176 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000
10.90.3.108:20160 tikv 10.90.3.108 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
10.90.3.32:20160 tikv 10.90.3.32 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
10.90.3.93:20160 tikv 10.90.3.93 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
Total nodes: 8
```
+ TiKVのノードの1つに接続して、データのストレージサイズを計算します。
```bash
ssh -i /home/ec2-user/.ssh/pe-class-key-${LAB:REGION_NAME}.pem ec2-user@${HOST_KV1_PRIVATE_IP}
```
```output
Last login: Tue Jul 23 05:45:15 2024
, #_
~\_ ####_ Amazon Linux 2
~~ \_#####\
~~ \###| AL2 End of Life is 2025-06-30.
~~ \#/ ___
~~ 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/
8 package(s) needed for security, out of 27 available
Run "sudo yum update" to apply all updates.
```
```bash
sudo du -h /tidb-data/tikv-20160/db --max-depth=0
```
```output
6.0G /tidb-data/tikv-20160/db
```
+ 方法 3: Grafanaをチェックしてデータボリュームを取得します。データボリュームの結果には、`sbtest`データベースだけでなく、他のメタデータも含まれています。
+ ユーザー名`admin`とパスワード`admin`を使用してGrafanaダッシュボードにログインし、`tidb-demo-TiKV-Summary - Server - Store size`を見つけます。
+ TiKV クラスタのデータサイズは`6.6GB x 3 = 19.8GB`であることが分かります。
### モジュール 2のまとめ
ステップ8では、3つの方法全ての結果がモジュール1での推定値に近いです。
## モジュール 3: 既存のワークロードに基づいた TiDB と TiKV のサイズ設定
### 注意
+ この実践では、`sysbench`を使用してワークロードのテストを行います。このワークロードは18,000 QPSの読み取りワークロードです。
### 手順 1. `sysbench` 環境の準備
+ ここをクリック - [ターミナル 3](ssh://monitor1-ssh#3)を開き、TiUPコントロールマシンに接続します。
+ ログイン後に表示されるバナー：
```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/
```
+ `sysbench` の設定を行います。
```bash
cat << EOF > sysbench_config
mysql-host=${HOST_MONITOR1_PRIVATE_IP}
mysql-port=6000
mysql-user=root
mysql-password=
mysql-db=sbtest
time=120
threads=14
report-interval=5
EOF
cat sysbench_config
```
```output
mysql-host=10.90.1.190
mysql-port=6000
mysql-user=root
mysql-password=
mysql-db=sbtest
time=120
threads=14
report-interval=5
```
### 手順 2. テストワークロードを適用
+ `sysbench` テストを開始します。
```bash
sysbench \
--config-file=sysbench_config oltp_read_only \
--tables=6 \
--table-size=10000000 run
```
```output
sysbench 1.0.17 (using bundled LuaJIT 2.1.0-beta2)
Running the test with following options:
Number of threads: 14
Report intermediate results every 5 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
[ 5s ] thds: 14 tps: 1203.22 qps: 19280.38 (r/w/o: 16871.13/0.00/2409.25) lat (ms,95%): 14.46 err/s: 0.00 reconn/s: 0.00
...
[ 120s ] thds: 14 tps: 1224.00 qps: 19581.56 (r/w/o: 17133.37/0.00/2448.20) lat (ms,95%): 13.95 err/s: 0.00 reconn/s: 0.00
SQL statistics:
queries performed:
read: 2048564
write: 0
other: 292652
total: 2341216
transactions: 146326 (1219.27 per sec.)
queries: 2341216 (19508.27 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 120.0102s
total number of events: 146326
Latency (ms):
min: 9.18
avg: 11.48
max: 29.71
95th percentile: 13.95
sum: 1679913.22
Threads fairness:
events (avg/stddev): 10451.8571/163.05
execution time (avg/stddev): 119.9938/0.00
```
### 手順 3. ベースラインを分析
+ QPS、レイテンシ、および TiDB リソース利用率を収集します。
+ QPS は: 19,508.27 per sec
+ P95 レイテンシは: 13.95ms
+ リソース利用率。Grafana ダッシュボードに切り替えて、`tidb-demo-Performance-Overview - Performance Overview` を見つけ、`TiDB CPU` & `TiKV CPU/IO MBps` を確認します。
+ TiDB CPU(Max): ≈ 6.1vc/8vc ≈ 76%
+ TiKV CPU(Max): ≈ 1.5vc/8vc ≈ 19%
+ TiDB クラスターサイジングツールの見積もり結果:
+ サイズ: tidb(8vc/16GiB) x 1, tikv(8vc/32GiB) x 3
+ QPS: 18,000
+ リソース利用率: tidb ≈ 95.24%, tikv ≈ 21.43%
+ `sysbench` の結果はツールの見積もりよりも少し良いことがわかります。サイジングツールは TiDB 6.x を基に作られており、私たちは TiDB tidb_version を使用してテストしています。
### 手順 4. TiDB SQL レイヤーをスケールアウト
+ TiDB SQL レイヤーに TiDB サーバーを追加してスケールアウトします。QPS が増加していることを確認してください。
+ スケールアウトの設定ファイルを確認します。
```bash
cat scale-out-tidb.yaml
```
```output
tidb_servers:
- host: 10.90.2.188
port: 4000
status_port: 10080
deploy_dir: /tidb-deploy/tidb-4000
log_dir: /tidb-deploy/tidb-4000/log
```
+ 新しい tidb-server をスケールアウトします。
```bash
~/.tiup/bin/tiup cluster scale-out tidb-demo scale-out-tidb.yaml \
--user ec2-user \
-i ~/.ssh/pe-class-key-${LAB:REGION_NAME}.pem \
-y
```
```output
...
Scaled cluster `tidb-demo` out successfully
```
+ TiDB クラスターを確認します。TiDB クラスターに 2 つの tidb-server があることを確認してください。
```bash
~/.tiup/bin/tiup cluster display tidb-demo
```
```output
Cluster type: tidb
Cluster name: tidb-demo
Cluster version: v8.1.0
Deploy user: ec2-user
SSH type: builtin
Dashboard URL: http://35.89.229.27:2379/dashboard
Grafana URL: http://10.90.4.39:3000
ID Role Host Ports OS/Arch Status Data Dir Deploy Dir
-- ---- ---- ----- ------- ------ -------- ----------
10.90.4.39:9093 alertmanager 10.90.4.39 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093
10.90.4.39:3000 grafana 10.90.4.39 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000
10.90.2.182:2379 pd 10.90.2.182 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379
10.90.4.39:9090 prometheus 10.90.4.39 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090
10.90.2.253:4000 tidb 10.90.2.253 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.3.122:20160 tikv 10.90.3.122 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
10.90.3.153:20160 tikv 10.90.3.153 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
10.90.3.5:20160 tikv 10.90.3.5 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
10.90.4.39:6000 tiproxy 10.90.4.39 6000/3080 linux/x86_64 Up - /tidb-deploy/tiproxy-6000
Total nodes: 10
```
+ 現在 TiProxy に 2 つの TiDB サーバーが接続されていることを確認します。Grafana ダッシュボードにログインし、`tidb-demo-TiProxy-Summary - Backend` を見つけ、`Ping Backend Duration` パネルで 2 つの tidb-server があることを確認します。
### 手順 5. sysbench ワークロードのスケールアウト
+ `sysbench` スレッドを 28 に増やします。
```bash
cat << EOF > sysbench_config
mysql-host=${HOST_MONITOR1_PRIVATE_IP}
mysql-port=6000
mysql-user=root
mysql-password=
mysql-db=sbtest
time=120
threads=28
report-interval=5
EOF
cat sysbench_config
```
```output
mysql-host=10.90.1.190
mysql-port=6000
mysql-user=root
mysql-password=
mysql-db=sbtest
time=120
threads=28
report-interval=5
```
+ 再度 `sysbench` テストを開始します。
```bash
sysbench \
--config-file=sysbench_config oltp_read_only \
--tables=6 \
--table-size=10000000 run
```
```output
sysbench 1.0.17 (using bundled LuaJIT 2.1.0-beta2)
Running the test with following options:
Number of threads: 28
Report intermediate results every 5 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
[ 5s ] thds: 28 tps: 2272.50 qps: 36408.77 (r/w/o: 31858.37/0.00/4550.40) lat (ms,95%): 15.00 err/s: 0.00 reconn/s: 0.00
...
[ 120s ] thds: 28 tps: 2301.17 qps: 36810.07 (r/w/o: 32208.13/0.00/4601.93) lat (ms,95%): 14.73 err/s: 0.00 reconn/s: 0.00
SQL statistics:
queries performed:
read: 3861368
write: 0
other: 551624
total: 4412992
transactions: 275812 (2298.15 per sec.)
queries: 4412992 (36770.39 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 120.0136s
total number of events: 275812
Latency (ms):
min: 9.41
avg: 12.18
max: 41.35
95th percentile: 14.73
sum: 3359870.50
Threads fairness:
events (avg/stddev): 9850.4286/324.02
execution time (avg/stddev): 119.9954/0.00
```
### 手順 6. スケールアウトの結果を分析
+ QPS、レイテンシ、および TiDB リソース利用率を確認します。
+ QPS は: 36,770.39 per sec
+ P95 レイテンシは: 14.73ms
+ リソース利用率。Grafana ダッシュボードに切り替えて、`tidb-demo-Performance-Overview - Performance Overview` を見つけ、`TiDB CPU` & `TiKV CPU/IO MBps` を確認します。
+ tidb CPU(Max): ≈ 6vc/8vc ≈ 75%
+ tikv CPU(Max): ≈ 2.8vc/8vc ≈ 35%
+ TiDB クラスターサイジングツールの見積もり結果:
+ サイズ: tidb(8vc/16GiB) x 2, tikv(8vc/32GiB) x 3
+ QPS: 36,000
+ リソース利用率: tidb ≈ 95.24%, tikv ≈ 42.86%
+ `sysbench` の結果はツールの見積もりよりも少し良いことがわかります。サイジングツールは TiDB 6.x を基に作られており、私たちは TiDB tidb_version を使用してテストしています。
## 結論
TiDB クラスターサイジングツールは、Self-Managed と TiDB Cloud Dedicated のために TiDB クラスターを作成する際にクラスターノードの数を見積もるのに役立ちます。実施されたテストに基づき、ツールの見積もりが実際の要件に近いことがわかりました。しかし、`sysbench` の結果はツールの見積もりよりも良好なパフォーマンスを示しています。この差異は、演習が TiDB バージョン tidb_version を使用しているのに対し、見積もりツールがバージョン v6.x に基づいているためです。
```hbsptform
{
"ui": {
"titleLevel": 3
},
"portalId": "4466002",
"formId": "62bfb32a-a60a-4f9d-b2dc-1107a93db568",
"region": "na1",
"sfdcCampaignId": "701RC00000NdFlAYAV"
}
```