开发者学堂课程【PolarDB-X 开源人才初级认证培训课程：PolarDB-X 集群运维1：升降配、扩缩容_与备份恢复】学习笔记（二），与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1075/detail/15543
PolarDB-X 集群运维1：升降配、扩缩容_与备份恢复
内容介绍
一、PolarDB-X 产品介绍
二、扩缩容
三、升降配
四、备份恢复
五、资源及常见问题
四、备份恢复
1、单击my circle做备份恢复，以PiT即任意时间点的备份恢复为例。（1）把备份恢复的过程看成两部分，第一部分是全量备份的过程，另一部分是基于bean log增量备份的过程。假如需要对my circle进行任意时间点的恢复，可以找到这个时间点之前最近的全量备份，通常会采用xtrabackup开源工具做这件事。
（2）找到xtrabackup全量备份完成的时间点所对应的bean log到所需要恢复的时间点，一般是秒级，可能今天的二十一点十五分十五秒，就会找到这段时间范围内的所有的bean log，对它进行增量，从而保证单击的my circle数据恢复到想要的任意时间点。polarDB-x的dn节点主要存储数据，把每个dn看成my circle使用，但如果每一个dn都通过这种方式做备份恢复，会存在数据一致性的问题。
（3）因为polarDB-x是一款分布式数据库，上面会有分布式事务存在，可能在dn1和dn2上会有同一条分布式事务来更新两条不同的数据，示例中有四个帐号分别是ABC D，在某一时刻A向B帐号发生了转账操作，这对应的是分布式事务，同时从C向d发起了转账操作。
（4）假如按照每个d单独使用全量加增量的备份恢复方式，因为只能恢复到秒级，同时分布式事务对每个dn而言无感知，有可能会出现A的账户已经完成了转账，但是b账户转账还没开始的情况。同时C和D的转账也存在这个问题，这种情况下，原来整个账户的金额是两百，通过备份恢复的方式拿出来的数据可能会出现两百五的情况，这时候总数据不一致，对用户而言是不可接受的，无论恢复到哪一个时间点都希望所恢复出来的能够保证数据的强一致。
2、polarDB-x操作
polarDB-x的分布式事务，目前采用基于tso的事务模型，每一个分布式事务都会在prepal阶段获取tso，在这基础之上，对dn的bean log进行改造，对每个bean log的event，将tso写到bean log里。有了过程，备份恢复流程和单机my cercle类似，也是基于全量的备份加bean log增量备份的过程，全量备份可以理解为在每个dn上，基于xtrabackup做备份操作，增量备份时bean log也会按照实际的dn产出做近实时的备份，在恢复的过程中，主要的问题就是根据bean log里的tso对现有的增量的bean log进行一定的裁剪，从而保证恢复出来的数据是完全一致的。
举个例子，转账操作这两个在dn1和dn2上提交操作产生了两条bean log的event关联到同一个tso上，在恢复的过程中，要么就是会将两个event同时apply，要么就是同时不apply，这样就能够避免前面所说的数据不一致的问题。
全局一致性的备份恢复已经在公共云上上线，开源的环境正在研发中，近期也会上线。
五、资源及相关问题
1、训练营相关资源介绍
(1)给出了github上的源码，感兴趣可以阅读相关的源码，了解更多的细节，如果对如何使用polarDB-x感兴趣，可以关注产品文档以及知乎专栏的原理解读文章。
(2)云起实验室有一系列的动手实践课程，可以课后在云起实验室上进行动手操作加深自己的理解。
(3)联系方式，如果对polarDB-x相关的知识感兴趣，或是想要探讨更多的内容，可以加微信做进一步交流。
2、问题
（1）SCOTT 的时候为什么客票时会为零。
因为刚才一边在申 CN 一边也在申 dn，如果只申 dn 不会出现零的，因为cn是流量的入口，存在流量切换的过程，会导致TTS跌到0的情况。
（2）公共云也是用 k84进行管控的吗？
在公共云上也是通过 K84来对资源进行管控，只不过在公共云上不是用的Operator方式，采用的是云上的管控架构，和开源有一点区别。
（3）数据量比较大的情况下，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 上直接按步骤操作是不是不行？
基本是一致的，如果有疑问也可以参考开源文档，上面有具体的操作说明，不同的操作系统版本可能会有一定差异，但整体不大。如果在操作过程中遇到问题，也可以在群里面反馈并协助解决。
