开发者学堂课程【如何对 PolarDB-X集群做动态扩缩容：如何对 PolarDB-X 集群做动态扩缩容】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/985/detail/14935
如何对 PolarDB-X 集群做动态扩缩容
可以通过第二个 shell 窗口在 sysbench_test 库里面可以看到 sbtest 的表
mysgl> create database sysbench_test;
Query OK, 1 row affected (0.15 sec)
mysql> use sysbench_test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+--------------------------------+
| TABLES_IN_SYSBENCH_TEST |
+--------------------------------+
| sbtest1 |
+--------------------------------+
1 row in set(0.00 sec)
//观看数据的数量，16万，说明数据已经成功灌到 PolarDB-X quick start 集群里面
mysql> select count(*) from sbtest1;
+---------+
| count(*) |
+---------+
| 160000 |
+---------+
1 row in set (0.30 sec)
mysql>
sysbench压测模拟业务流量
admin@polardb-x-demo ~/class-4>vim sysbench-run.yaml
//这个时候会用八个线程来做一个压测，用的是 sysbench 的select的场景，现在开始压测流量。
adminepolardb-x-demo ~/class-4> kubectl apply -f sysbench -run.yaml
job.batch/sysbench-point-select-test created
admin@polardb-x-demo ~/class-4>kubectl get pods
//最关键一步。
NAME READY STATUS Running RESTARTS AGE
quick-start-965c-cdc-default-dcfffd454-642fb 2/2 Running 0 5m53s
quick-start-965c-cn-default-6d5c7b46d8-lpkwq 3/3 Running 0 5m53s
quick-start-965c-dn-0-single-0 3/3 Running 0 6m28s
quick-start-965c-gms-single-0 3/3 Running 0 6m28s
sysbench-point-select-test--1-28kmp 1/1 Running 0 18s
sysbench-prepare-data-test--1-txllr 0/1 Completed 2m13s
admin@polardb-x-demo ~/class-4>kubectl logs-f sysbench- prepare-data-test--1-28kmp
//可以看到已经开始进行压测，压测线程是8个，tps 是2000，错误率一开始保持在80%，现在基本没错一两个的水平。假设系统遇到瓶颈想要更高的 tps 可以对系统进行扩容
[5s] thds:8 tps:1091.48 qps:1091.48(r/w/o:1091.48/0.00/0.00) lat(ms,95%):84.47err/:0.00 reconn/s:0.00
[10s] thds:8 tps:1302.20 qps:1302.20(r/w/o:1302.20/0.00/ 0.00)lat(ms,95%):82.96 err/s:0.00 reconn/s: 0.00
[15s] thds:8 tps:1466.20 aps:1466.20(r/w/o:1466.20/0.00/ 0.00)lat(ms,95%:818err/s.00 reconn/s:0.00
[20s] thds:8 tps:1466.00 qps:1466.00(r/w/o:1466.00/0.00/ 0.00)at(ms,95%):81.48err/s:0.00 reconn/s:0.00
[25s]thds:8tps:1578.79qps:1578.79(r/w/o:1578.79/0.00/0.00)lat(ms,95%):74.46err/s:0.00 reconn/s:0.00
[30s] thds:I8 tps:1698.39qps:1698.39(r/w/o:1698.39/0.00/0. 00)lat(ms,95%):3.36 err/s:0.00 reconn/s:0.00
[35s] thds:8 tps:2066.41qps:2066.41(r/w/o:2066.41/0.00/ 0.00)lat (ms,95%):1.42 err/s:0.00 reconn/s:0.00
[40s] thds:8 tps:2240.40 qps:2240.40(r/w/o:2240.40/0.00/ 0.00)lat(ms,95%):121 err/s:0.00 reconn/s:0.00
[45s1thds:8 tps:2112.22 aps:2112.22(r/w/o:211222/0.00/0. 00)lat(ms,95%):1.44 err/s: 0.00 reconn/s: 0.00
[50s]thds:8tps:1919.98qps:1919.98(r/w/o:1919.98/0.00/0.00)lat(ms,95%):235 err/s:0.00 reconn/s: 0.00
[55s]thds:8 tps:2334.61qps:2334.61(r/w/o:2334.61/0.00/0.00 lat(ms,95%)1.14err/:0.00 reconn/s: 0.00
[60s]thds:8 tps:2338.60qps:2338.60(r/w/o:2338.60/0.00/0. 00)lat(ms,95%):127err/s:0.00 reconn/s:0.00
[65s] thds:8 tps:2299.58 qps:2299.58(r/w/o:2299.58/0.00/0. 00)lat(ms,95%118err/s:0.00 reconn/s:0.00
[70s]thds:8 tps:2328.01 qps:2328.01(r/w/o:2328.01/0.00/0. 00)lat(ms,95%)1.21err/s:0.00 reconn/s: 0.00
[75s] thds:8 tps:2051.00qps;2051.00(r/w/o:2051.00/0.00/ 0.00)lat(ms,95%)1.32err/s0.00 reconn/s: 0.00
[80s]thds:8 tps:2334.56 qps:2334.56(r/w/o:2334.5/000/0 00)lat(ms,95%)1.18err/:0.00reconn/s:0.00
[85s] thds:8 tps:2285.64 aps:2285.64(r/w/o:2285.64/0.00/0.0 0)lat (ms95%)1.21err/s:0.00 reconn/s:0.00
[90s ] thds:8 tps:2264.58 qps:2264.58(r/w/o:2264.58/0.00/0.0 0)lat(ms95%12err/:0.00 reconn/s:0.00
[95s]thds:8 tps:2308.63 qps:2308.63(r/w/o:2308.63/0.00/0. 00lat(ms95%)155err/0.00 reconn/s:0.00
[100s] thds:8 tps:20 35.81 qps:2035.81(r/w/o:2035.81/0.00/0. 00)lat(ms95%)3.30err/s: 0.00 reconn/s:0.00
[105s]thds:8 tps:1756.40 qps:1756.40(r/w/o:1756.40/0.00/0.
00)lat(ms95%):4.82 err/s:0.00 reconn/s: 0.00
[110s]thds:8 tps:1724.60 qps:1724.60(r/w/o:1724.60/0.00/ 0.00)latms95%632err/s0.00 reconn/s:0.00
[115s] 1 thds:8 tps:2061.19 aps:2061.19(r/w/o:2061.19/0.00 000lat(ms.95%)261err/:0.00reconn/s0.00
[120s] thds:8 tps:2203.98 qps:2203.98(r/w/o:2203.98/0.00/ 000)lat(ms95%)207err/:0.00reconn/s:0.00
[125s] thds:8tps:2118.62gps:2118.62(r/w/o:2118.62/0.00/0. 00) lat (ms,95%):3.25 err/s: 0.00 reconn/s:0.00
[130s ] thds:8tps:2025.82 qps:2025.82(r/w/o:2025.82/0.00/00 0lat(ms,95%)75err/s0.00 reconn/s:0.0
[135s] thds:8tps:2272.97qps:2272.97(r/w/o:2272.97/0.00/ 0.00)lat(ms,95%):3.02 err/s:0.00 reconn/s:0.00
[140s ] thds:8tps:12346.38 qps:2346.38(r/w/o:2346.38/0.00/0. 00)lat(ms,95%):1.76 err/s:0.00 reconn/s:0.00
[145s]thds:8tps:2041.81qps:2041.81(r/w/o:2041.81/0.00 /0.00)lat(ms,95%325err/s:0.00reconn/s:0.00
[150s ] thds:8 tps:2286.42 qps:2286.42(r/w/o:2286.42/0.00/0. 00)lat(ms,95%1.61err/s:0.00 reconn/s:0.00
[155s] thds:8 tps:2175.37 qps:2175.37(r/w/o:2175.37/0.00/ 0.00)lat(ms,95%):3.43err/s:0.00 reconn/s:0.00
[160s ] thds:8tps:2212.23qps:2212.23(r/w/o:221223/000/ 000lat(ms,95%.55err/s:0.00reconn/s:0.00
[165s] thds:8 tps:2280.16 qps:2280.16(r/w/o:2280.16/0.00/00 0lat(ms,95%)1.37err/s:0.00 reconn/s:0.00
[170s] thds:8 tps: 2094.44 qps:2094.44(r/w/o:2094.44/0.00/0. 00)lat(ms,95%:3.68 err/s: 0.00 reconn/s:0.00
[175s] thds:8tps:1961.00 qps:1961.00(r/w/o:1961.00/0.00/ 0.00)lat(ms,95%):3.68 err/s:0.00 reconn/s:0.00
[180s] thds:8 tps:1876.39 qps:1876.39(r/w/o:1876.39/0.00 /000)at(ms,95%）4.91err/s:0.00reconn/s:0.00
[185s]thds:8 tps:1537.84qps:1537.84 (r/w/o:1537.84/0.00 /000)at(ms,95%）6.67err/s:0.00reconn/s:0.00
//压测线程是8个，tps是2000，错误率一开始是80个，现在已经接近没有，假设系统想要更高的tps,可以对系统进行扩容。
//如何扩容 Demo 最关键的一步，在开启另外一个 shell
free6om@free6om ~> ssh polardb-x-demo
Welcome to Ubuntu 20.04.3 LTS(GNU/Linux5.4.0-91-gen eric*86_64)
*Documentation: https://help.ubuntu.com
*Management: https://landscape.canonical.com
*Support: https://ubuntu.com/advantage
Welcome to Alibaba Cloud Elastic Compute Service!
Last login: Fri Feb 11 16:15:51 2022 from 42.120.75.252 Welcome to fish, the friendly interactive shell
Type `help` for instructions on how to use fish
admin@polardb-x-demo ~> cd class-4
admin@polardb-x-demo ~/class-4> alias kubectl="minikube kubectl -- “
Admin@polardb-x-demo ~/class-4>
admin@polardb-x-demo ~/class-4> kubectl edit polardbxClu ster quick-start
//quick start 配置文件进行编辑
# Please edit the object below. Lines beginning with a '#’ will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion:polardbx.aliyun.com/v1
kind:PolarDBXCluster metadata:
annotations:
"/tmp/kubectl-edit-624880352.yaml"176L，4133C
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"polardbx.aliyun.com/v1","kind":"PolarDBXCluster","metadata”:{"annotations”:{"polardbx/topology-mode-guide":"quick-stort"} ,"name":"quick-start" , "namesp ace":"default"}} creationTimestamp:"2022-02-11T08:12:562" finalizers:
-polardbx/finalizer
generation: 2
name:quick-start
namespace: default
resourceVersion:"8623"
uid:850833b3-bcfe-4e14-95bd-b8a4fde999dd
spec:
config:
cn:{}
dn:
logPurgeInterval:0s
protocolVersion:"8.0"
serviceName:quick-start
serviceType:ClusterIP
topology:
nodes:
cdc：
reolicas.
template:
resources:
limits:
cpu:"1"
memory:1Gi
requests:
cpu:100m
memory:500Mi
cn:
replicas:2
template:
resources:
limits:
cpu:"4"
memory:8Gi
requests:
cpu:100m
memory:1Gi
dn:
replicas:2
template:
engine: galaxy
hostNetwork : true
resources:
limits：
cpu：“8”
memory:16Gi
requests:
cpu:100m
memory:500Gi
serviceType:ClusterIP
gms:
template:
//CN replicas一个把它变成两个，资源限制把它放得更大一点，原来是 1Gi，现在改成 8Gi。 GN 也从一个变成两个同样把资源也放开把它改成8 cpu 就可以。刚才做的修改主要是两个地方，第一个是增加节点，分别将 CN 从一个增加到两个,DN 从一个增加到两个另外对 CN、DN 所能使用的资源的上限都进行一个放大。
//保存配置文件
Type `help`for instructions on how to use fish
adminepolardb-x-demo ~> cd class-4
admin@polardb-x-demo ~/class-4> alias kubectl="minikube kubectl -- '
admin@polardb-x-demo ~/class-4> kubectl edit polardbxClu ster quick-start
polardbxcluster.polardbx.aliyun.com/quick-start edited
//弄完之后 K8S会自动对比两次的差异之后始扩容的过程
admin@polardb-x-demo ~/class-4> kubectl get polardbx Cluster quick-start -w -o wide
NAME PROTOCOL GMS CN DN CDC PHASE DISK STAGE REBALANCE VERSION AGE
quick-start 8.0 1/11/2 1/2 1/1 Upgrading 2.6 GiB 5.6.29-PXC-5.4.12-20220127/8.0.18 9m18s
quick-start 8.0 1/1 2/2 1/2 1/1 Upgrading 2.6 GiB 5.6.29-PXC-5.4.12-20220127/8.0.18 9m22s
quick-start 8.0 1/1 2/2 2/2 1/1 5Upgrading 2.6 GiB RebalanceStart 6.29-PXC-5.4.12-20220127/8.0.189m22s 9m
32s
quick-start 8.0 1/1 2/2 2/2 1/1 Upgrading 3.8 GiB RebalanceWatch 5.6.29-PXC-5.4.12-20220127/8.0.18 9m57s
quick-start 8.0 1/1 2/2 2/2 1/1 Upgrading 3.8 GiB Clean 100.0% 5.6.29-PXC-5.4.12-20220127/8.0.18 9m57s
quick-start 8.0 1/1 2/2 2/2 1/1 Running 3.8 GiB I 5.6.29-PXC-5.4.12-20220127/8.0.18 9m57s
^Cl
admin@polardb-x-demo ~/class-4 [SIGINT]>| kubectl get polardbxCluster quick-start -w -o wide AGE
NAME PROTOCOL GMS CN DN CDC PHASE DISK STAGE REBALANCE VERSION AGE
quick-start 8.0 1/1 2/2 1/1 Running 3.8GiB 5.6.29-PXC-5.4.12-20220127/8.0.18 10m
quick-start 8.0 1/1 2/2 2/2 1/ Running 3.9 GiB 5.6.29-PXC-5.4.12-20220127/8.0.18 10m
quick-start 8.0 1/1 2/2 2/2 0/1 Running 3.9 GiB 5.6.29-PXC-5.4.12-20220127/8.0.18 11m
^C
admin@polardb-x-demo ~/class-4 [SIGINT]>
//可以用命令看一下 quick start 集群动态变化过程，同时也关注整个系统当中 tps 的变化，CN 已经从刚才一个变成两个，两个之后系统会自动触发 Rebalance 过程。因为计算节点由一个变成两个可以看到 tps 已经比原来高，原来是2000的水平已经变成了4000的水平 Rebalance 因为增加了 CN、DN，会涉及到一个数据从原来一个DN搬到两个 DN 上面这样一个过程，所以会有个数据搬迁的过程，现在可以看到这个进度已经100%。100%之后PolarDB-X的quick start 集群，再次进行一个 running 就是正常的状态，可以看到当前系统里面已经变成了一个 GMS 两个 CN 两个 DN 一个 ctl Running 状态
[190s] ]thds:8 tps:2431.56qps:2431.56(r/w/o:2431.56/0.00/0 00)at(m95%)5.18err/s:0.00 reconn/s:0.00
[195s]thds:8 tps:3921.20 qps:3721.20(r/w/o:372120/0.00/ 0.00)at(ms95%:1.96err/s: 0.00 reconn/s:0.00
[200s ] thds: 8 tps:3839.00 qps:3839.00(r/w/o:3839.00/0.00/0. 00)lat(ms95%):1.70 err/s:0.00 reconn/s:0.00
[205s] thds:8 tps:3801.62 qps:3801.62(r/w/o:380162/0.00/0 00)lat(ms95%125err000reconn/s:0.00
[210s ] thds:8 tps:3716.38 qps:3716.38(r/w/o:3716.38/0.00/0. 00)lat (ms95%);1.55 err/s: 0.00 reconn/s:0.00
[215s ]thds:8 tps:3705.41 qps:3705.41(r/w/o:3705.41/0.00/00 0)lat(ms95%)271err/s0.00reconn/s:0.00
[220s] thds:8 tps:3921.13 qps:3921.13(r/w/o:3921.13/0.00/0. 00)lat(ms95%):1.34 err/s:0.00 reconn/s:0.00
[225s] thds:8 tps:704.56 qps:704.56(r/w/o:704.56/0.00/0. 00)lat(ms95%355err/s:2553.54reconn/s:0.00
[230s] thds:8 tps:3448.98 qps:3448.98(r/w/o:3448.98/0.00/0. 00)lat(ms95%):2.52 err/s:0.00 reconn/s:0.00
[235s] thds:8 tps:3656.40 qps:3656.40(r/w/o:3656.40/0.00/ 0.00)lat(ms,95%):1.93err/s:0.00 reconn/s:0.00
[240s] thds:8 tps:3369.04 qps:3369.04(r/w/o:3369.04/0.00/ 0.00)lat(ms95%)281rr/s:0.00reconn/s:0.00
245s thds:8 tps: 3243.60 qps: 3243.60(r/w/o:3243.60/0.00/0.00)lat (ms,95%:3.75 err/s: 0.00 reconn/s:0.00
[250s ] thds:8 tps:4637.33 gps:4637.33(r/w/o:4637.33/0.00/ 0.00) lat (ms,95%: 1.61 err/s: 0.00 reconn/s:0.00
[255s] thds:8 tps:7504.56qps:7504.56(r/w/:7504.56/0.00/ 0.00)lat(ms,95%):1.37 err/s:0.00 reconn/s:0.00
[260s] thds:8 tps:7441.31 qps:7441.31(r/w/o:7441.31/0.00/0. 00lat(ms95%)1.21err/s:0.00 reconn/s:0.00
[265s]thds:8tps:7323.17qps:7323.17(r/w/o:7323.17/0.00/0.00)lat(ms95%):1.06 err/s:0.00 reconn/s:0.00
[270s]thds:8tps:7326.58 qps:7326.58(r/w/o:732658000/0 00)at(ms95%)134err/:0.00reconn/s:0.00
[280s ]thds:8tps:7657.76qps:7657.76(r/w/o:7657.76/0.00/0.00)lat (ms.95%):1.25 err/s:0.00 reconn/s:0.00
[285s ]thds:8tps:7848.70qps:7848.70(r/w/o:7848.70/0.00/0.00)latms95%):0.99err/s:0.00 reconn/s:0.00
[290s ]thds:8tps:7837.03qps:7837.03(r/w/o:7837.03/0.00/0.00)lat(ms95%):0.97err/s:0.00 reconn/s:0.00
[295s] thds:8 tps: 7995.57qps:7995.57(r/w/o:7995.57/0.00/ 0.00)lat(ms95%0.95 err/s:0.00 reconn/s:0.00
[300s] thds: 8 tps: 7991.59 qps:7991.59(r/w/o:799159/0.00/ 0.00) lat(ms95%0.95 err/s: 0.00 reconn/s:0.00
[305s]thds:8tps:7910.69qps:7910.69(r/w/o:7910.69/0.00/0.00)lat(ms95%):0.95err/s:0.00 reconn/s:0.00
[310s ] thds:8tps:7965.56 qps:7965.56(r/w/o:7965.56/0.00/ 0.00)lat(ms95%):0.95err/s:0.00 reconn/s:0.00
[315s ]thds:8tps:7872.39qps:7872.39(r/w/o:7872.39000000)lat(ms95%0.95err/s:0.00 reconn/s:0.00
[320s ]thds:8tps:7910.69qps:7910.69(r/w/o:7910.69/0.00/0.00)lat(ms95%):0.97err/s:0.00 reconn/s: 0.00
[325s]thds:8 tps:7847.10 qps:7847.10(r/w/o:7847.10/0.000. 00)lat(ms95%): 0.99 err/s:0.00 reconn/s: 0.00
//当前业务 tps 已经到达了7300,一开始一个 CN 一个 DN 的时候是2000的水平，对系统资源进行扩容之后变成了7000多的水平，扩容的效果还是很明显的，另外一点就是在扩容的过程中可以看到业务的报错一直在一个比较低的水平，其他跟原来的报错率保持在差不多的水平。调整完之后因为现在系统的资源相对来说比较充裕，tps 已经到8000的水平，同时报错会进一步下降。
2、PolarDB-X 扩缩容相关原理
扩容流程
每个步骤是怎么做的
如何消除副作用
第二部分是扩缩容或者水平扩展能力背后的一些基本的流程或者原理是怎么样的，原理讲的比较稍微有点深入， Demo 首先跑一个 PolarDB-X 集群，这个集群是用官方文档里面的quick stat 集群，它刚跑起来的时候，有一个 CN 一个 CD 一个CDT 三个节点的情况。之后会开始用 sysbench 对它做一个压测，压测开始之后一段时间会对系统里面动态添加一个 CN 和一个 DN 使整个系统变成两个 CN 两个 DN 的状态，然后观察一下压缩流量的变化情况，直到最后加入的 CN 和 DN 成功的开始去承载压测流量。
因为做扩容如果之前有过分库分表，中间件相关的扩展经历，会知道每做一次扩容是非常麻烦的一个过程，刚才的演示当中对 PolarDB-X 做一个水平扩展，好像是一条命令或者做一个改动，把配置改一下之后剩下的就全部交给系统，系统会全部自动化去完成这样的功能过程。系统做的一个自动化，意味着这里面有非常大量的工作去做。接下来讲一下扩容相关的原理，这个原理包括三个方面，第一个会讲扩容大概的流程是怎么样的；第二个是流程里面的每一步怎么做的；第三个可能会想到一些如果不这么做可能会产生什么影响，有一些副作用或者有一些担忧，系统里面都是怎么去处理的，会讲这几部分的内容。
（1）PolarDB-X 里数据是怎样分布的
PolarDB-X架构图：
讲这个过程之前，稍微的了解一下数据在 PolarDB-X 里面具体是怎么样分布的。如前面的架构图所示，系统里面最关键的两个组件，一个叫 CN 一个叫 DN，数据是全部以分片的方式 Partition 方式放在了 DN 上面，比如现在这个图里面，只看上面半部分下面半部分先不管，比如现在有一张表被水平的拆分成了 n 多份，最终 n 多份在 DN 上可能是这样的分布，DN1 上会有分区一，分区二和分区三 ，DN2 上会有分区四分区五和分级六一直到其他的 DN 上有其他的若干个分区，直到所有的分区在 DN 上面出现，是这样的一个分布。系统里面增加一个 DN 之后，这个时候新增的 DN 里面数据是空白的，首先 PolarDB-X 集群知道增加了一个 DN 或者增加一个 CN 增加了资源，这是第一点。
第二点的话，知道之后要进行计算，要把哪些数据从现有的 DN 上面搬到新的 DN 上面。第三步搬完之后要做一个切换，最后业务流量在新的 DN 上进行了生效，所以这是扩容的过程。
（2）PolarDB-X 水平扩容的流程是怎样的
①加入节点。系统添加一个新的空的DN节点;
②分区调度。均衡调度器决定需要迁移到新DN节点的分区;
③分区变更。执行分区迁移任务(这个过程可能同时还伴随有分区分裂或分区合并的操作);
④流量切换。被迁移的分区的流量切换到新DN节点，达到负载均衡状态。
水平扩展简单来说分四个步骤，第一个是加入节点，不管增加一个节点，还是 n 个节点都是增加资源的步骤，这是对系统互动的第一步；第二步增加之后，系统会进行分区的调度，会进行计算，计算之后得出一个结果，是以什么样的一个最佳的方案，把已有的 DN 上的一些数据、一些分片来迁移到新增加的 DN 上面，迁移完之后在系统总体上面它是一个随游的，会有一个调的算法来决定具体是哪个方面迁移到新增加的点上面；第三步是分区的变更，是第一步要把数据给迁移过去，第二个让元数据出现生效等等的过程；最后数据迁移完让新增加的资源进行生效来承载真正业务流量，所以会有流量切换的过程，前面的加节点和分局调度相对来说加节点比较简单，分区调动是一个算法。
（3）分区迁移的过程是怎样的
分区迁移：
数据量大，迁的慢怎么办？
迁移过程遇到业务高峰，影响业务怎么办？
在这张图里面所示，DN-2 是新增加的 DN 的一个节点，一开始里面的数据是空的，调度算法最终决定把 DN1 上面的 Tbl.P3 来牵引到它上面，所以它会进行一个 DML 操作，这个过程就是简单的把里面的数据全量的给迁移过去，同时要考虑 P3 新增的一些数据，比如有新增或者有更新或者有删除，增量的部分也要实时的同步到 DN2 上，保持两边数据的强一致性。这个过程做完之后，首先在 DN2 上准备了一个新的 partition ，跟 DN1上原来 partition 两个的数据保持了完全的一致，达到这样一个状态之后会通过一种方式来进行一个切换，切换完之后在老的DN 上的 partition3会被清理掉，把上面的磁盘空间给释放掉，同时把业务的流量、新的流量全部打在DN2上面也是新增加的上面，来承载新的流量，这样是整个系统处理能力的增加，这是分区迁移的过程。
迁移是完全自动转换成的，所以自然而然大家会想到两个问题：
第一个问题就是在一个分布式的系统、分布式的数据库里面，通常它的数据量是非常的大的，比如 P3 可能有接近 1T 的数据进行迁移或者里面有上亿几十亿条数据要迁移，如果单纯的比如一个县城以很慢的速度再迁过程会非常的长，希望这个过程可以加速所以在 PolarDB-X 的里面迁移的过程是按照并行的方式去迁的，并行可以达到一个非常高的水平，所以迁的过程可以达到一个相对来说非常快的速度，也就说不是串行是并行去做的，它的速度话相对来说是非常快的。
第二个问题因为迁移必然要消化到系统当中的一些资源，不管是 CN 的还是 DN 的，通常来说这样的一个 PP的数据库，做的都是一些核心业务的处理，如果恰好在做扩容的过程当中有了一波业务的高峰，扩容数据迁移的现场会不会跟业务上面的一个处理这样的现场在资源上构成一个增强，最终影响到线上的业务，所以在这点上迁移过程同时涉及留空的一些算法在里面，简短来说它可以做到这样的一个效果，当系统处于比较空闲状态的时候，会把并发、迁移的速度等等所消耗的资源等等提上去来加快这个活动的过程。而当来自于业务的一个流量升高之后，会把迁移的并发度还有消耗的资源等等给降下来，甚至极端情况下，当发现系统处于非常高的一个负载的时候，会完全把迁移的过程暂停掉，避免对线上业务造成影响。这是分区迁移的一个过程。
（4）透明切换是如何做的
数据迁移完之后，当新增加的里面的数据经跟原来老的地方保持了一个完全同步的状态，那么最后一步就是切换，也就是让新的 DN 进行一个生效 ，这个切换的过程也是有非常多的细节来进行考虑。简单来分析两个场景，比如切的时候应该怎么切：
一种方法是简单粗暴，直接切啥都不管；因为系统当中是个分布式系统，也就意味着可能有多个 CN 节点，不同的应用或者应用里面不同的连接，它是连接到不同的 CN 的，切换的过程也就是现在 CN 到底认为下面是哪个 DN 在生效，是当前的一个 DN，在这件事情上，不同的 CN 可能会有不同的看法，因为总得有单点的一个点来通知到所有的 CN 说从现在开始新的 DN2 进行生效，那这件事情不能保证所有的 CN 是同时生效的，也就是说在某一瞬间可能一部分 CN 会认为还是老 DN 在生效，另外一部分 CN 会认为新的 DN 在生效，如果直接切的话会导致从不同的连接，不同的 CN，或者不同的应用连接所看到的数据状态是不一致的，导致出现了数据不一致的情况。
另外一种也是简单粗暴的，通知到所有的 CN 并且要等到所有的 CN 都说OK了现在是 DN2 新的 DN 生效了，老 DN 已经不去管它了，对这件事情全部达成一致，如果做这样一件事情会发现也是有问题的，这个时候就会涉及到对所有的 CN 进行一个停写，在应用上面看起来应用暂时不能访问了，这是一个非常不好的体验，另外一点，并不能保证所有的时间在一定时间范围之内一定被通知到，比如在通知新的 DN 生效这件事情的时候，恰巧有一个CN的网络出现了问题。然后可能有长时间的一个等待的过程，并且给予理论上并不能保证到底什么时候可以恢复，所以填写的过程可能是非常漫长的，对业务上来说是不可接受的。
所以如何进行一个切换才能给业务上面提供一个非常流畅的体验称之为透明的切换，在 PolarDB-X 里面首先这个切换的过程，是参考了 Gobu的 online SKY/M change论文里面的一些算法，具体在处理新的 DN2 和老的 DN1 两个之间的数据到底谁生效的时候呢？把新的 DN2 里面那个表当成主表，把老的 DN 里面的那个表当成是一个索引表，两个是假设是这样的关系之后，流量切换的过程或者说原数据切换的过程，相当于做了一次的删除索引。
所以老的 DN 上面的 partition3 过程是怎么样的呢？如果大家对详细的Gobu的 online SKY/M change感兴趣可以去看一下论文，这里就简单说一下在 PolarDB-X 里面是怎么去做的，这个过程跟Gobu 论文里面的流程是一样的，比如现在开始进行切换，看一下这张图最右边的四个状态的切换，最上面的一个状态叫做ready public 可以简单理解为是正常状态，是系统的初始状态，也就是说现在所有的流量还是打在老的 DN1 上面。这个时候因为已经有了前面分区迁移操作，所以此时老的 DN 和新的 DN 上面关于 partition3的数据是完全一致的，并且会保持实时的同步。另外需要强调的一点是同步是用分布式事物来进行保障的，它是一个强一致的同步，而不是一补，最终以这样的一个同步。
接下来开始通知所有的 CN 说现在索引表也就是老 DN 上面这个分区，现在处于 right only 这样一个状态，因为刚才说了这个通知可能不能再所有的 DN 同时生效，也就是说从这个通知发出去之后，系统里面所有的 CN 可能看到两种状态，一种就是一部分 CN 认为老的 DN 的处于 ready public 状态，另外一部分 CN 会认为它是处于 right only 状态，仔细的去分析这里面的流量的一些处理的方式，会发现不管 CN 认为老的 DN 是怎样的状态，都不会导致不管是 select 这样的语句还是 DML 也是delay up date 都不会出错，这点大家可以去稍微去做一下分析，也就是分析的场景是现在系统里面有两个 CN 然后一个 CN 认为老的 DN 是 ready public 的一个状态，是状态图的第一张图，那么它会把所有的 select 还有DML的interrup delete全部去访问老的 DN 。另外一个 CN 会认为老的系统当前是处于一个 write only 的状态，这时候只是把 DML也就是insert delete update去路游到老的 DN 上面把 select 路到到新的点上面，即使这两种状态叠加，系统依然不会有任何的问题。
在这个状态持续一段时间，所有的 CN 都达到了认为老的 DN 上面分区处于 right only 的状态之后，也就是说大家都走到了 STEP 7 步骤之后，所有的 CN 走到了 STEP 7 步骤之后，接下来就系统再次发起一个通知，现在老的 DN 处于一个 delete 状态，跟刚才那个过程类似，所有的 CN 节点又有这样的状态变化的过程，并且系统里面如果 CN 处于两种不同的状态的时候，流量不会有任何的报错，最后一步就是把它变成一个aprsent，也就是说老的 DN 上面的partition彻底下线掉，经过这四个步骤切换之后，会发现系统已经成功的从原来的老的 DN 上面切到了新的 DN 上面，并且整个过程当中所有的查询不会去报错,简单来说是切换的过程。
(5) 总结
简单的总结一下，今天展示了最新发布的 PolarDB-X 扩容能力，在第一讲里面出现的 quick starts，一个 CN，一个 DN 集群的基础上。在跑有 sysbench 压测的状态下面， quick start 集群动态的增加到两个 CN，两个 DN 在增加的整个过程当中压测都在正常的进行，并且扩容完成之后，系统的容量确实提高了四倍的情况，后面是对扩容简单的过程的讲解。
