开发者学堂课程【PolarDB-X 开源人才初级认证培训课程：PolarDB-X 集群运维1：升降配、扩缩容_与备份恢复】学习笔记（一），与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1075/detail/15543
PolarDB-X 集群运维1：升降配、扩缩容_与备份恢复
内容介绍
一、PolarDB-X 产品介绍
二、扩缩容
三、升降配
四、备份恢复
五、资源及常见问题
一、 polarDB-x 产品介绍
1、核心组件
polarDB-x 是阿里云上的分布式数据库，主要由四个核心的组件构成。
（1）CN 节点，也就是整个集群的流量入口，负责接收用户应用服务器发过来的业务Circle，将其进行相应的分布式的路由计算，同时也负责分布式事务的协调以及全球二级索引的维护。
（2）dn 节点，也就是 datanode，是实际存储数据的地方，同时对其进行改造，采用了协议，来保证数据的强一致与高可靠。
（3）元数据中心，也就是gms，它存储了polarDB-x集群的托普信息，同时也是分布式事务所依赖的tso的授时组件。
（4）CDC组件，作用主要有两个。
①将每个dn上的物理bean Log转换成一条与my circle bean log完全兼容的逻辑bean log流，能够与下游的大数据生态系统进行无缝的对接。
②提供了完全兼容my circle Application主备订阅的能力。
2、k84及弹性扩展
（1）k84
云延伸绕不开k84这个话题，polarDB-x积极拥抱kaK84的生态，在k84上进行了扩展，提供了polarDB-xOperator来支持polarDB-x集群的相关工作，例如基于K84的scheduler，apiserver和Controller-manager构建了polarDB-x的控制面，在这基础之上，能够对polarDB-x集群进行部署，运维，以及相关的一些生命周期，产品能力的管理，例如采用了 k84 里面的 Deployment 来管理无状态的CN和cdc组件。
采用类似 State for set 的方式来管理项目，采用了XTexas的dn节点，除了像部署，广运维这些基本的生命周期能力外，还提供各项弹性伸缩，高可用，监控，审计以及备份恢复等能力。
（2）弹性扩展
①首先，数据库的弹性扩展，polarDB-x是从淘宝起家的，主要面向互联网业务，特点是通常会有高并发和海量数据的存储需求，通常随着业务的发展，单机的数据库会存在性能的瓶颈，例如并发能力有限或存储空间达到瓶颈，这种情况下需要对数据库进行扩展。
②传统的扩展方式目前有两种。
垂直扩展，也就是升降配，可以理解为在已有的机器中增加更多的资源来提高数据库的处理能力，例如对于部署在物理机上的数据库，可以采用更多核的CPU，或者采用更大或者更快的内存条，来对数据库性能进行提升。
而对于云数据库而言，由于底层的资源已经通过虚拟化的技术进行了弛化，只需要修改相关资源的配置即可实现快速的垂直的升降配，提升数据库的性能，这种方式的好处是扩展过程基本不需要迁移数据。
问题是性能始终是局限于单机的，单机的性能是有上限的。
水平扩展，也就是扩缩容，相当于是加入更多的机器来解决数据库的扩展性问题，这种方式不再局限于单机的性能，但是需要对数据进行一定的迁移来做到水平扩展，同时这种方式对于数据库的水平扩展能力有更多的要求，需要有数据库有线性的扩展能力，这样才能够将增加进来的机器的性能充分地发挥出来。
二、扩缩容
阿里云的云起实验室上已经发布上线实验，对 polarDB-x 集群做动态扩缩容，直接通过实验熟悉流程。
云起实验室的页面有很多的实验，要做的是实验二，如何对polarDB-x集群做动态扩缩容。
1、实验操作
（1）申请资源，点击串联资源即可创建完成。需要在阿里云上买一台ecs部署相关的资源。回到实验手册，按照实验手册的步骤进行操作。
（2）安装环境
①安装依赖，安装docker，将命令复制粘贴。启动后接着按照命令将docker的服务启动。
②安装 kubectl，可以理解成它是K84集群的命令行工具，可以通过它与k84集群做交互，先下载kubectl的文件，对这个命令授予可执行权限，之后将其移到系统目录，就可以直接使用kubectl的命令。
③安装 mini kube，可以在ecs虚拟出k84的集群，在上面安装 polarDB-xOperator以及创建 polarDB-x实例。
完成后安装helm3，这是K84里面的包管理工具，类似Centrals的young的方式，所有的 k84 Operator 都可以通过 helm 包的方式进行管理。
④按照命令把 helm 的更换包安装好。完成后执行命令即可输出正常的结果，最后一步是安装 mycircle 的命令行。
（3）安装 polarDB-x operator 和 polarDB-x。
①用刚才安装好的mini kube创建 K84的集群。在这过程中由于不能通过注册帐号进行使用，需要创建一个独立的帐号，按照步骤创建一个GALAXY kube帐号。将帐号加到docker组里，访问docker的Soccer demon。
切换到Galaxy kube帐号下，通过命令来创建虚拟的k84基集群，集群命令的CPU是串联四个，Memory是12G，有一个镜像，由于国内访问有一定的网络延迟，于是采用上海交大的镜像源拿取镜像做k84的集群。
K84创建完成，执行kubectl cluster-info来查看刚刚创建的k84集群基本信息。
②安装polarDB-xOperator。
首先需要创建一个叫Operator system的命名空间。创建完成通过目前 polarDB-x提供的helm仓库来安装polarDB-x Operator。
创建一个叫polarDB-x的本地helm仓库，把仓库添加完成，通过helm INSTALL的方式，将polarDB-x helm包安装完成，接下来查看在polarDB-x Operator system命名空间下组件的状态。
在命名空间下，kubectl get pods——Name space指定的是Polardbx operator system，在这个命名空间下，所有控制面所需要的pod都已经ready。
③创建Polardbx。
编辑yaml文件，通过vim polarDB-x的命令打开vim的编辑器，把实验室里的yaml文件型复制过来。
文件内容：这是polarDB-x定义的单独的，独立的，在k84上的资源，叫polarDB-x Cluster，名字叫polarDB-x。
有几个部分，第一部分是Topology，指定了各个组件的信息，有CDC、cn、dn和gms。现在cdc是1，cn也是1，dn也是1，资源都是Minute，都是1c1g，cn是1C2g，dn是2C 4G，按照这个规格来配置。
其他的信息比较通用，可以在文档上查看相应的资料。
保存后通过kubectl Apply文件在k84集群上创建 polarDB-x 对象。
观察集群的创建状态，在使用的kubectl GET polarDB-x CLASS的命令，polarDB-x class就是定义好的资源类型，指定的就是polarDB-x，查看当前的状态，目前可以看到它有几个组件，gms、cn、dn和cdc，和之前对应的四个组件一致，每一个的个数都是1，处于Creating状态。
pod创建情况，正在创建gms以及dn节点，gms和dn都采用三副本模式，每个dn由三个pod构成，分别对应的是Leader，Follower和Folgger，gms也是一样的模式。
（4）扩缩容操作
①编辑polarDB-x的文件，回到文件中，cn、dn都是replicas，将CN和dn的个数改成2。K84就会将CN和dn各增加一个节点，自动化完成。保存后用kubectl apply的方式更新polarDB-x对象。
②更新后观察polarDB-x集群内的状态。状态从上面的Running变成了upgreating状态，cn和dn的个数目标变成两个，目前ready的都是一个，下面将会进行自动化扩容。
dn已经进入ready状态，接下来会有数据迁移过程，会在PPT中进行详细的介绍。
③扩容过程是自动化的，只需要告诉K84将CN和dn扩容到几个，便会自动把新的cn和dn创建出来，同时将相应的数据进行挪动，达到扩容后的状态。
④缩容和扩容类似，就是将刚才在yaml文件里面修改的个数，例如从2变成1，相当于起到缩容的效果。缩容的步骤可以在云起实验室里进行体验。
2、原理介绍
（1）扩容
①CN和CDC无状态节点怎么处理，dn有状态的节点如何处理。对于CN和cdc这样无状态的节点，举个例子，有三个CN的节点，需要扩容到四个，只需要新建一个新的cn节点，将其加入到CN集群里即可完成扩容。
对于dn这样有状态的组件而言，需要做的事情相对较多，首先创建一个新的dn，原来只有dn0在工作，现在需要创建dn1，创建完后，对dn0上已有的数据的分区进行计算，需要知道哪些数据需要移动到新建的dn1上，同时将数据迁移过来。
在迁移的过程中，所有的cn访问流量还是访问原来的dn0，dn1不会参与实际的业务请求。
等dn1所有的数据搬迁完成，与dn0达到了数据完全一致的状态，便会发起cn切流过程，将所有在dn0上的数据的请求流量移到DN1上形成，从而达到新的数据均衡状态，完成扩展的步骤。
（2）缩容，对于CN和cdc这种无状态而言比较类似，本来有三个CN的节点，需要缩容到两个，只需要将多出来的cn的节点做下线操作便可以达到缩容效果。
对于dn这样有状态的组件而言，首先将DN1下掉，只保留dn0一个dn节点，将dn1的数据全部迁移到已有的dn0上，过程涉及到分区的计算，以及数据的迁移。
迁移完成之后进行切流，将所有原来访问dn1的流量切换到dn0上。
dn1上没有业务流量，便会将dn1进行下线操作，达到缩容后的效果。
三、升降配
1、技术细节
（1）分区迁移。将老dn的数据迁移到新的dn，由于polarDB-x是一款分布式数据库，存储的数据量往往较大，迁移的数据量比较大，因此在迁移的过程中尽可能采用并行的策略来提高迁移效率，迁移过程中比较消耗CPU以及io资源，如果迁移的速度过快，也会对正常的业务业务请求造成一定的影响。
因此polarDB-x支持自适应的流控策略，一方面能够允许用户自定义控制迁移任务的启停以及迁移速率的上限，另一方面也会根据实际节点的资源情况来自适应控制迁移的速率。从而能够既保障迁移效率，也能够减少对业务的影响。
（2）切换过程。当完成数据迁移，需要从旧的dn切换到新的dn访问时，由于polarDB-x是一款分布式节点，会有多个cn节点存在。直接切流方式，由于polarDB-x有多个Cn，不可能同时切流，可能会有一前一后的延迟，假如需要将老的cn1上的数据迁移到cn2，数据迁移完成发起切换。
这时cn2完成切换过程，对新的分配数据发起删除操作，将数据删除，但是cn1的流量还没有切换到cn2，这时有select的请求过来，仍然会读到原来cn1上的这条数据，这时候便会出现数据的不一致。
简单解法是直接通知所有的cn停写进行切换，切换完成后，再把写入流量放开。但由于是分布式数据库，需要保证所有的cn节点都能被通知到，假如某一个cn节点发生异常或是有网络延迟，便会有协调开销。长时间的停写也会对业务造成一定的影响。
（3）针对上述两种问题，polarDB-x采用透明切换方式，将切换过程看成是ddl操作，将新dn2上的数据看成主表的数据，将DN2上的数据看成是主表的索引表。
切流操作就是将索引表的数据进行下线，有了抽象之后，参考GOOGLE的那篇papper，将整个切换过程分成四个步骤。
可以理解成do流量，insert流量还有delete，update流量以及剩下的所有的流量，在这个过程中保证任意一个时刻，所有的cn节点只会出现相邻的两个状态。
举个例子，在一开始切流后需要通知cn节点，这时只会出现部分节点ready public，读写请求还在访问老的cn节点，同时数据同步还在保持，部分节点只会将读请求切换到新的cn，写请求还在老的cn上，只会出现这一种状态。
等所有的cn节点全部达到step7即only状态后，才会发起向step8状态切换的步骤，直到所有的cn全部到step8后才会发起向step9切换的操作，通过这种方式能够保证不会出现数据的不一致，同时也没有长时间浪费，减少对业务的影响。
2、操作
（1）ecs提前通过kubectl安装好k84集群。这是由四个节点构成的minikube集群，polarDB-X的实例已经创建好。它由gms，cn，dn和cdc组成，通过命令拿到登录密码。
polarDB-X 实例的密码会放到 k84 的 cicol 对象里，通过拿到对象里面相应密码的字段，将其进行贝斯六十四的解码，就可以拿到密码。把密码输出出来，将 polarDB-X 的端口转发到设备上，即可从本地进行登录。
（2）将3306端口转发到本地，接下来通过命令行的方式登录。在my cercle上登录后，已经提前创建好数据库，开启压测流量，对polarDB-X 进行操作，观察过程中的变化。
（3）数据库的数据导入十六行的数据，接下来将对实例开启压测流量。压测流量的脚本是 yaml 文件，有几个关键的部分。使用的容器是目前公开的容器。在二次部分配置 pxC 实例的用户名密码以及网络的连接串。主要的区别是使用二十五个连接来进行压测，压测时使用的是slect场景。
（4）用 kubecrl apply 方式创建job。有一个叫 的pall正在运行，日志流量基本上稳定下来，实例按现在的资源规格，kps是三千多，接下来进行扩容。
（5）进行申配，通过 yaml 文件进行编辑，将cn的CPU的limite改成2，dn 的 CPU 的 limite 也改成2，保存文件。apply对象，成功后观察polarDB-X的状态，已经进入upgreating。
qPS已经上来，最初三千多，现在已经到五六千。申配过程还在继续。
（6）sisbench的流量跌到0有几个因素，在申配过程中，CN需要进行申配，中间必然会有老cn下线和新cn上线的过程，会导致切换。
由于压测流量，sisbench的流量和polarDB-X在ecs上做模拟，两个进程之间的资源会有一定的互相影响就会导致这种现象，如果单独在k84集群使用的话不会有这个问题，闪断不会这么慢。
3、原理
（1）升降配可以看成两个部分，第一个是cn、cdc这种无状态的组件，升降配其实就是把节点的资源，例如CPU内存资源更改，需要用新的pod替换老的pod。
为了保证相对的平衡，会选 rolling up great 的方式，按要求配置的新的CN节点，创建好节点，举个例子，三个 cn 的 CPU 限制都是1，现在需要改成2，就会创建三个CPU limite 是2的节点，创建完成后会将老的pod下线，替换原来的cn节点。
（2）对于 dn 这样有状态的过程，给出每一个dn内部的状态，分别是 leader、FOLLOWer 和 logger，在这个过程中，leader 对外提供请求，响应请求，follower 和 logger 主要做数据迁移之后的保障。
因此，会首先对FOLLOWer和logger进行升降配更改配置，换成新的 pod，完成后将原来的 leader 切换到 follower，由原来已经升配完的 follower 做 leader，对老的leader 进行升降配来达到最终的升配过程，这是轮转的过程，可以尽量减少对业务的影响。中间有一次流量的切换，就是主备的切换。
