开发者学堂课程【PolarDB-X 开源系列课程：PolarDB-X集群运维1：升降配、扩缩容_与备份恢复（四）】学习笔记与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/1032/detail/15145
PolarDB-X集群运维1：升降配、扩缩容_与备份恢复（四）
五、资源及相关问题
1、训练营相关资源介绍
(1)给出了github上的源码，感兴趣可以阅读相关的源码，了解更多的细节，如果对如何使用polarDB-x感兴趣，可以关注产品文档以及知乎专栏的原理解读文章。
(2)云起实验室有一系列的动手实践课程，可以课后在云起实验室上进行动手操作加深自己的理解。
(3)联系方式，如果对polarDB-x相关的知识感兴趣，或是想要探讨更多的内容，可以加微信做进一步交流。
2、问题
（1）SCOTT的时候为什么客票时会为零。
因为刚才一边在申CN一边也在申dn，如果只申dn不会出现零的，因为cn是流量的入口，存在流量切换的过程，会导致TTS跌到0的情况。
（2）公共云也是用k84进行管控的吗？
在公共云上也是通过K84来对资源进行管控，只不过在公共云上不是用的Operator方式，采用的是云上的管控架构，和开源有一点区别。
（1）数据量比较大的情况下，dn节点的扩容失败会怎么样。可以从几个步骤来看，假如在新增期，第一步需要新增一个dn节点，在新增dn节点的过程中出现了失败的情况，不影响实际的使用，因为数据和分区都没有迁移。
假如在迁移的过程中出现，也没有问题，因为流量没有切，而且所有的数据分区计算和数据迁移也是异步的过程，同时也设计了自适应的留空，不会对业务造成影响。如果出现问题，也提供异步低调的运维手段，可以排查解决。
如果都是多副本dn，由于多副本会有切换，而且并不是流量的入口，所以不会归零，而cn因为是流量的入口，流量打过来先有下线过程，下线的过程中会将已有的连接断开，就会出现为零的情况。
另外，在实验的过程也说明了一下，在同一台ecs上既创建 又 压测流量，之间会有资源的互相影响，会导致cn启动过程相对慢一些，或是 流量有一定影响。
（4）Dn的一副本是一主一从吗？
不是，dn目前有两种模式，一种是一副本，是一个leader的模式，还有一种是推荐的三副本模式，一个leader，一个FOLLOWer加一个logger，leader和FOLLOWer有全量数据，logger存储bean log日志，不会apply bean log。
k84对资源的管理比较方便，所以在生产环境下用了K84，不仅仅是灰度发布的功能，需要整个数据库的生命周期管理，高可用能力实现，K84方便实现这些功能。
（5）生产环境扩容cn有什么办法避免失败？
失败可能会有几种情况，第一种整体资源不够，导致pod处于pending的状态，这种情况已经在pending，通常会先保证新的pod完全可对外服务，再将老pod下线来尽量降低对整个资源的影响。可以理解为rolling upgreat的操作，和K84里的depoloiment升级类似。
（6）实验室环境上的部署操作命令在cental ONCE上直接按步骤操作是不是不行？
基本是一致的，如果有疑问也可以参考开源文档，上面有具体的操作说明，不同的操作系统版本可能会有一定差异，但整体不大。如果在操作过程中遇到问题，也可以在群里面反馈并协助解决。
