## Module 3: Application Best Practice When TiDB Scaling in with TiProxy + In this module, we show you the effects of the application during TiDB scaling in, when your application is connected to the database via TiProxy ### Step 1. Verify the TiProxy settings + [graceful-wait-before-shutdown](https://docs.pingcap.com/tidb/stable/tidb-configuration-file/#graceful-wait-before-shutdown-new-in-v50) specifies the number of seconds that TiDB waits when you shut down the server (closing the TCP port), which allows the clients to disconnect. ```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) must be at least 10 seconds greater than the duration of the longest transaction of your application to avoid client connection interruption when the TiDB server goes offline. > Moreover, we recommend you avoid running long transactions, such as batch processing, when scaling in TiDB server, if you connect to TiDB using a network load balancer. ### Step 2. Scale out a TiDB Server again + Let’s now scale out a TiDB Server again, so that later we can scale in a TiDB Server. ```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 ``` The figure below shows the topology of the TiDB cluster at this moment. The TiDB Server with the red dotted line will be scaled in later. ![demo016-m7-tapo-tiproxy.png 85%](https://lab-static.pingcap.com/images/2025/8/15/057327baab2c6324aba3f837ef2c50408670b920.png) ### Step 3. Check the cluster topology + Make sure you now have two `TiDB`s and one `TiProxy`. ```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 ``` ### Step 4. Run the code against TiProxy without reconnect logic + Open [Terminal 1](ssh://monitor1-ssh#1), run the code `demo_tiproxy_no_retry.py`. + The code is same as the one in Module 2 Step 4, except that it is now connected to TiProxy, instead of the network load balancer. + There is no retry logic in the code. ```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 ... ``` ### Step 5. Scale in a TiDB Server + Open [Terminal 2](ssh://monitor1-ssh#2), run the following command ```bash ~/.tiup/bin/tiup cluster scale-in tidb-demo --node ${LAB:HOST_DB2_PRIVATE_IP}:4000 -y ``` ```output ... Scaled cluster `tidb-demo` in successfully ``` ### Step 6. Observe [Terminal 1](ssh://monitor1-ssh#3) + In [Terminal 1](ssh://monitor1-ssh#3), you can see the following output ```output ... Thread 4: Committed. user 5 balance updated to: 1 Thread 2: Committed. user 1 balance updated to: 5 ... ``` ### Step 7. Stop the workload + In [Terminal 1](ssh://monitor1-ssh#1), use `ctrl` + `c` to stop the workload. ### Conclusion + TiProxy minimizes the impact of the maintenance tasks of TiDB.