## モジュール 4: ストレージレイヤーのスケールイン + 本モジュールでは、受講者が手動で TiKV クラスターから 1 つの TiKV ノードを削除してスケールインを行います。その後、受講者は次のモジュールでスケールインの速度を制御します。 ### 手順 1. すべての TiKV ノードの `store limit` を `1` に設定します + [ターミナル 1](ssh://monitor1-ssh#1) に切り替えて，すべての TiKV ノードの `store limit` を `1` に設定します。 ```bash ~/.tiup/bin/tiup ctl:v${LAB:TIDB_VERSION} pd -u http://${HOST_PD1_PRIVATE_IP}:2379 store limit all 1 ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/v${LAB:TIDB_VERSION}/ctl pd -u http://10.90.2.178:2379 store limit all 1 Success! Set store limit successfully. ``` + すべての TiKV ノードの `store limit` が `1` に設定されていることを確認します。 ```bash ~/.tiup/bin/tiup ctl:v${LAB:TIDB_VERSION} pd -u http://${HOST_PD1_PRIVATE_IP}:2379 store limit ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/v${LAB:TIDB_VERSION}/ctl pd -u http://10.90.2.178:2379 store limit { "1": { "add-peer": 1, "remove-peer": 1 }, "4": { "add-peer": 1, "remove-peer": 1 }, "576": { "add-peer": 1, "remove-peer": 1 }, "7": { "add-peer": 1, "remove-peer": 1 } } ``` ### 手順 2. クラスタから1つの TiKV サーバーを削除 + [ターミナル 1](ssh://monitor1-ssh#1) で、ランダムに1つの TiKV サーバーを削除してストレージレイヤをスケールインします。 ```bash RANDOM_TIKV_NODE=`~/.tiup/bin/tiup cluster display tidb-demo | grep 20160 | sed 's/ .*$//' | head -n 1` ~/.tiup/bin/tiup cluster scale-in tidb-demo --node ${RANDOM_TIKV_NODE} -y ``` ```output ... Scaled cluster `tidb-demo` in successfully ``` + 削除された TiKV ノードを破棄します。 ```bash ~/.tiup/bin/tiup cluster prune tidb-demo -y ``` ```output ... Destroy success ``` + TiDB クラスターの状態を確認すると、この時点で削除された TiKV ノードは `Pending Offline` 状態にあることがわかります。これは、そのノード上にまだ移動されていないリージョンが存在するためです。 ```bash ~/.tiup/bin/tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: v${LAB:TIDB_VERSION} Deploy user: ec2-user SSH type: builtin Dashboard URL: http://35.74.236.1:2379/dashboard Grafana URL: http://10.90.4.196:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.196:9093 alertmanager 10.90.4.196 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.196:3000 grafana 10.90.4.196 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.178:2379 pd 10.90.2.178 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.196:9090 prometheus 10.90.4.196 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.140:4000 tidb 10.90.1.140 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.169:20160 tikv 10.90.1.169 20160/20180 linux/x86_64 Pending Offline /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.192:20160 tikv 10.90.1.192 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.88:20160 tikv 10.90.1.88 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.99:20160 tikv 10.90.1.99 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.4.196:6000 tiproxy 10.90.4.196 6000/3080 linux/x86_64 Up - /tidb-deploy/tiproxy-6000 Total nodes: 10 ``` + [Grafana 監視](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000)の `tidb-demo-PD` に戻り、`tidb-demo-PD` の上半分で `Offline store progress`、`Left time`、および `Current scaling speed` に数値が表示されていることを確認します。これは、スケールインが進行中であることを示しており、次にスケールインの速度を上げる必要があります。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/651768f831fc8f0850c53a533ab4529e3908197f.png) ### 手順 3. TiKV クラスターのスケールインのバランスを加速します + `tidb-demo-PD` の上半分で、`Offline store progress` が 10% を超えるのをお待ちください（注意：このステップは `Offline store progress` が 10% から 20% の間で行うことをお勧めします。20% を超えると、その後のステップを行う時間がない可能性があります）。その後、すべての TiKV ノードの `store limit` の項目を `5` に設定し、TiKV が Operator を実行する速度を向上させます。 ```bash ~/.tiup/bin/tiup ctl:v${LAB:TIDB_VERSION} pd -u http://${HOST_PD1_PRIVATE_IP}:2379 store limit all 5 ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/v${LAB:TIDB_VERSION}/ctl pd -u http://10.90.2.178:2379 store limit all 5 Success! Set store limit successfully. ``` + すべての TiKV ノードの `store limit` の項目が `5` に設定されたことを確認してください。 ```bash ~/.tiup/bin/tiup ctl:v${LAB:TIDB_VERSION} pd -u http://${HOST_PD1_PRIVATE_IP}:2379 store limit ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/v${LAB:TIDB_VERSION}/ctl pd -u http://10.90.2.178:2379 store limit { "1": { "add-peer": 5, "remove-peer": 5 }, "4": { "add-peer": 5, "remove-peer": 5 }, "576": { "add-peer": 5, "remove-peer": 5 }, "7": { "add-peer": 5, "remove-peer": 5 } } ``` + 10 秒待ちます。`tidb-demo-PD` の `Operator` タブで、`Scheduler operator create` パネルと `Scheduler operator finish` パネルにおいて、`replace-rule-offline-peer` と `replace-rule-offline-leader-peer` の速度が上昇し始めるのを確認できます。これは、TiKV が オペレーター を実行する効率が向上したためです。なお、この2つのオペレーターはスケールイン時に PD が発行する、バランスに対して主要な役割を果たすオペレーターです。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/90df54268d6aa8fa0c85a20c8baada857e155668.png) + `tidb-demo-TiKV-Details` の `Cluster` タブで、各 TiKV ノードの IO 使用率 `IO utilization` が上昇し始めるのを確認できます。これは、新たに追加された TiKV ノードとソースとして選ばれた TiKV ノードが IO リソースをスケールインに使用していることを示しており、既存のビジネス負荷に影響を与える可能性があります。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/b8369458e4f86946c674b3645dccebf788208b19.png) + 少し待ってから、`tidb-demo-PD` の上半分を観察すると、`Offline store progress` のパーセンテージが加速して上昇し、`Left time` の数値が減少し、`Current scaling speed` が上昇しているのが見えます。これは、`Store limit` の増加がスケールインの速度を加速できることを示しています。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/43df4c4872c1c59b15f220118a4e42f865d76e62.png) ### 手順 4. パラメータを調整し、TiKV クラスターのスケールインのデータバランスの速度を遅くします + `tidb-demo-PD` の上半分で、`Offline store progress` が 50% を超えるのをお待ちください（注意：このステップは `Offline store progress` が 50% から 60% の間で行うことをお勧めいたします。60% を超えると、その後のステップを行う時間がない可能性があります）。その後、すべての TiKV ノードの `store limit` の項目を `1` に設定し、TiKV が オペレーター を実行する速度を低下させます。 ```bash ~/.tiup/bin/tiup ctl:v${LAB:TIDB_VERSION} pd -u http://${HOST_PD1_PRIVATE_IP}:2379 store limit all 1 ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/v${LAB:TIDB_VERSION}/ctl pd -u http://10.90.2.178:2379 store limit all 1 Success! Set store limit successfully. ``` + すべての TiKV ノードの `store limit` の項目が `1` に設定されたことを確認してください。 ```bash ~/.tiup/bin/tiup ctl:v${LAB:TIDB_VERSION} pd -u http://${HOST_PD1_PRIVATE_IP}:2379 store limit ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/v${LAB:TIDB_VERSION}/ctl pd -u http://10.90.2.178:2379 store limit { "1": { "add-peer": 1, "remove-peer": 1 }, "4": { "add-peer": 1, "remove-peer": 1 }, "576": { "add-peer": 1, "remove-peer": 1 }, "7": { "add-peer": 1, "remove-peer": 1 } } ``` + [Grafana 監視](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000) の `tidb-demo-PD` に戻り、10 秒待ちます。`tidb-demo-PD` の `Operator` タブで、`Scheduler operator create` パネルと `Scheduler operator finish` パネルにおいて、`replace-rule-offline-peer` と `replace-rule-offline-leader-peer` の速度が下降し始めるのを確認できます。これは、TiKV が オペレーター を実行する効率が低下したためです。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/406021a71460034ad668fcf176f750098ed8175b.png) + `tidb-demo-TiKV-Details` の `Cluster` タブで、各 TiKV ノードの IO 使用率 `IO utilization` が下降し始めるのを確認できます。これは、TiKV クラスターがスケールインに少量の IO リソースを使用していることを示しており、既存のビジネス負荷に対する影響を回避できる可能性がありますが、スケールインが遅くなることを意味します。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/214390b37261a4bf2e4dacca120f9382a7dad6f7.png) + 少し待ってから、`tidb-demo-PD` の上半分を観察すると、`Online store progress` のパーセンテージの上昇速度が遅くなり、`Left time` の数値が長くなり、`Current scaling speed` が下降し始めるのが見えます。これは、`Store limit` の減少がスケールインの速度を遅くすることを示しています。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/e31ebaa56b7d09b7720cd0cd9123c91550186a90.png) ### 手順 5. TiKV クラスターのスケールインプロセスのバランスが完了するのをお待ちいただき、ノードを削除します + 少し待ってから、`tidb-demo-PD` の上半分における `Offline store progress`、`Left time`、および `Current scaling speed` の変化を観察します。`Offline store progress` が `No data` になるまで待ちます。これは、スケールインが正式に完了したことを示します。注意：参加者がスケールインが遅すぎると感じた場合は、`store limit` を `20` に調整して、スケールイン操作の完了を加速することをお勧めいたします。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/3b911baaaa83ac8dbb10dee3181fa6613f721bf9.png) + `Offline store progress` が 90% を超えると、`Current scaling speed` が持続的に低下します。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/32f4cef10c31bc4456d01881deeec463eb6153e6.png) + `Offline store progress` が `No Data` になると、スケールインプロセスのバランス段階が完了したことを示します。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/127c33db5b21e0c16ee8d35d248dbb880e7be75d.png) + `tidb-demo-PD` の下半分にある `Statistics - balance` タブで、`Store available` パネルおよび `Store available ratio` パネルがスケールイン後の TiKV クラスターのデータ分布状況を示しています。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/4a584f550935b2f764f27aac55d44c25942bbcc1.png) + `tidb-demo-TiKV-Details` の `Cluster` タブで `IO utilization` パネルを見つけ、時間範囲を全体のスケールインプロセスに拡大すると、TiKV クラスターの負荷状況が `store limit` の値によって変化することがわかります。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/2e6a23f3e643340053b5b2ae9db2fe3181b9fb92.png) + TiDB クラスターの状態を確認すると、この時点で削除された TiKV ノードが `Pending Offline` 状態から `Tombstone` 状態に変わっていることがわかります。これは、そのノード上のリージョンがすでに移行されており、`prune` 操作を行うことができることを示しています。 ```bash ~/.tiup/bin/tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: v${LAB:TIDB_VERSION} Deploy user: ec2-user SSH type: builtin Dashboard URL: http://35.74.236.1:2379/dashboard Grafana URL: http://10.90.4.196:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.196:9093 alertmanager 10.90.4.196 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.196:3000 grafana 10.90.4.196 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.178:2379 pd 10.90.2.178 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.196:9090 prometheus 10.90.4.196 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.140:4000 tidb 10.90.1.140 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.169:20160 tikv 10.90.1.169 20160/20180 linux/x86_64 Tombstone /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.192:20160 tikv 10.90.1.192 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.88:20160 tikv 10.90.1.88 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.99:20160 tikv 10.90.1.99 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.4.196:6000 tiproxy 10.90.4.196 6000/3080 linux/x86_64 Up - /tidb-deploy/tiproxy-6000 Total nodes: 10 There are some nodes can be pruned: Nodes: [10.90.1.169:20160] You can destroy them with the command: `tiup cluster prune tidb-demo` ``` + 削除された TiKV ノードを破棄します。 ```bash ~/.tiup/bin/tiup cluster prune tidb-demo -y ``` ```output ... Destroy success ``` + TiDB クラスタに3つの tikv サーバーがあることを確認します。ストレージレイヤのサイズを4から3にスケールしました。 ```bash ~/.tiup/bin/tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: v${LAB:TIDB_VERSION} Deploy user: ec2-user SSH type: builtin Dashboard URL: http://35.74.236.1:2379/dashboard Grafana URL: http://10.90.4.196:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.196:9093 alertmanager 10.90.4.196 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.196:3000 grafana 10.90.4.196 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.178:2379 pd 10.90.2.178 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.196:9090 prometheus 10.90.4.196 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.140:4000 tidb 10.90.1.140 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.192:20160 tikv 10.90.1.192 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.88:20160 tikv 10.90.1.88 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.99:20160 tikv 10.90.1.99 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.4.196:6000 tiproxy 10.90.4.196 6000/3080 linux/x86_64 Up - /tidb-deploy/tiproxy-6000 Total nodes: 9 ```