## モジュール3: TiProxy経由でTiDBスケールイン時のアプリケーションベストプラクティス + このモジュールでは、アプリケーションがTiProxy経由でデータベースに接続している場合に、TiDBのスケールイン時にアプリケーションへ与える影響を確認します。 ### 手順 1. TiProxyの設定を確認する + [graceful-wait-before-shutdown](https://docs.pingcap.com/ja/tidb/stable/tidb-configuration-file/#graceful-wait-before-shutdown-new-in-v50) は、TiDB Server をシャットダウンする際（TCP ポートを閉じる前）に、クライアントが正常に切断できるよう TiDB が待機する秒数を指定します。 ```bash ./connect-tiproxy.sh ``` ```output tidb:tiproxy> ``` ```sql show config where name='graceful-wait-before-shutdown'; exit; ``` ```output +------+------------------+-------------------------------+-------+ | Type | Instance | Name | Value | +------+------------------+-------------------------------+-------+ | tidb | 10.90.1.247:4000 | graceful-wait-before-shutdown | 15 | +------+------------------+-------------------------------+-------+ 2 rows in set (0.01 sec) Bye ``` > [!TIP] > [graceful-wait-before-shutdown](https://docs.pingcap.com/tidb/stable/tidb-configuration-file/#graceful-wait-before-shutdown-new-in-v50)は、アプリケーションの最長トランザクション時間より10秒以上長く設定する必要があります。これにより、TiDBサーバーがオフラインになる際のクライアント接続の中断を防げます。 > また、ネットワークロードバランサー経由でTiDBに接続している場合、スケールイン時にはバッチ処理などの長いトランザクションの実行を避けることを推奨します。 ### 手順 2. TiDBサーバーを再度スケールアウトする + これからTiDBサーバーを再度スケールアウトし、後でスケールインできるようにします。 ```bash ~/.tiup/bin/tiup cluster scale-out tidb-demo scale-out-tidb-2.yaml \ --user ec2-user \ -i ~/.ssh/pe-class-key-${LAB:REGION_NAME}.pem \ -y ``` ```output ... Scaled cluster `tidb-demo` in successfully ``` 下図は現時点でのTiDBクラスタのトポロジーを示しています。赤い点線で囲まれたTiDBサーバーは後ほどスケールインされます。 ![demo016-m7-tapo-tiproxy.png 85%](https://lab-static.pingcap.com/images/2025/8/15/057327baab2c6324aba3f837ef2c50408670b920.png) ### 手順 3. クラスタのトポロジーを確認する + 現在、`TiDB`が2台、`TiProxy`が1台あることを確認してください。 ```bash ~/.tiup/bin/tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: v8.5.1 Deploy user: ec2-user SSH type: builtin Dashboard URL: http://3.112.81.1:2379/dashboard Grafana URL: http://10.90.4.40:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.40:9093 alertmanager 10.90.4.40 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.40:3000 grafana 10.90.4.40 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.141:2379 pd 10.90.2.141 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.40:9090 prometheus 10.90.4.40 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.165:4000 tidb 10.90.1.165 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.66:4000 tidb 10.90.1.66 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.3.160:20160 tikv 10.90.3.160 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.193:20160 tikv 10.90.3.193 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.243:20160 tikv 10.90.3.243 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.4.40:6000 tiproxy 10.90.4.40 6000/3080 linux/x86_64 Up - /tidb-deploy/tiproxy-6000 ``` ### 手順 4. 再接続ロジックなしでTiProxy経由でコードを実行する + [ターミナル1](ssh://monitor1-ssh#1)を開き、`demo_tiproxy_no_retry.py`を実行します。 + このコードは、モジュール2の手順4と同じですが、今回はネットワークロードバランサーではなくTiProxyに接続しています。 + コードにはリトライロジックはありません。 ```bash python3 demo_tiproxy_no_retry.py ``` ```output ... Thread 3: Committed. user 4 balance updated to: 2 Thread 2: Committed. user 3 balance updated to: 0 ... ``` ### 手順 5. TiDBサーバーをスケールインする + [ターミナル2](ssh://monitor1-ssh#2)を開き、以下のコマンドを実行します。 ```bash ~/.tiup/bin/tiup cluster scale-in tidb-demo --node ${LAB:HOST_DB2_PRIVATE_IP}:4000 -y ``` ```output ... Scaled cluster `tidb-demo` in successfully ``` ### 手順 6. [ターミナル1](ssh://monitor1-ssh#3)を観察する + [ターミナル1](ssh://monitor1-ssh#3)で、以下のような出力が表示されることを確認します。 ```output ... Thread 4: Committed. user 5 balance updated to: 1 Thread 2: Committed. user 1 balance updated to: 5 ... ``` ### 手順 7. ワークロードを停止する + [ターミナル1](ssh://monitor1-ssh#1)で、`ctrl` + `c`を使ってワークロードを停止します。 ### まとめ + TiProxy は、TiDB のメンテナンス作業による影響を最小限に抑えます。