开发者学堂课程【PolarDB-X 开源分布式数据库进阶课程 ：PolarDB-X 的部署与运维（三）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1202/detail/18163
PolarDB-X 的部署与运维
五、企业级运维能力
v2.2这个版本所支持的相关的企业级的运维能力主要包括四部分，分别是日志采集，（SQL 审计）、强一制备份恢复、备库重搭以及参数模板和参数设置。
1.日志采集
V2.2版本支持三种日志的自动采集，那分别是 sql.log，记录的全量 SQL 信息,基于这个日志我们便可以构建全量的审计的功能。slow.log，记录慢 SQL 列表，基于此可以帮助我们有效的监控 polarDB-X 上是否具有慢 SQL 或者存在问题。error.log ，也就是错误日志，可以帮助我们判断是否存在业务上的异常或者系统上的异常。
那这些日志文件是如何被采集的呢？下面是一张具体的一个架构图，采用 filebeats 和 logstash 的开源解决方案。首先 filebeats 会以 beatset 的方式部署在 K8s 的每一个节点上，定时拉取相关的日志文件，同时将其投递到 logstash 的集群中。logstash负责将这些日志的文本进行解析，提取出相应的索引字段，同时发送给下游的存储系统。这里默认推荐采用 Elastic search 的方式进行存储，然后通过 kilbana 的方式做可视化查询展现。
下面是一张在 kilbana 里面查询 polarDB-X SQL 日志截图，
可以方便的利用它的查询语言帮助定位一些问题 SQL 或者高危 SQL 。如果采用 logstash 解决方案，也可以充分利用到它的多种 outputping 的能力，因为它可以支持不同的 outputping。即可以通过自己的定制将 SQL 日制或慢日志投递到不同的存储系统构建自己的实际业务。例如 mangoDB 等都是支持的，可以直接去在课后进行体验。同时那为了能够更深入的了解、体验日志采集的功能，我们提供了一个云起实验室《如何采集 polarDB-X SQL 到Elasticsearch》，可以在课后直接在实验室上去进行体验。
2.强一致备份恢复
首先 Polo dx 的备份流程分为下面几个步骤。
第一步对每一个 dn 节点进行物理并行的物理备份，等所有的 dn 都备份完成后，会根据一致性的算法在每个 dn 的增量至里面寻找一致性的位点。下面通过经典的转账场景演示，存在一张账户信息表，分为一共有四个账户A、B、C、D，他们均匀的分布在 dn 1 和 dn 2 上。AB 在 dn1上，CD 在 dn 2上，账户总金额加起来是200元。在某一个时刻 A 向 D 转账，然后 C 又向 B 来进行转账，那恰好在这个时候进行备份，之后备份完成。现在要基于之前的备份集来对数据进行恢复，这种情况下，恢复出的数据存在两笔转账都没发生或都发生了两种情况，不应该存在只有一笔转账发生而另一笔没发生的情况。即四个账户的总金额要始终保持200不变，这才能保证全局数据的一致性。第三个表格是一个反例，A 账号已经完成了转账，就是金额账户金额从100变成了50，但是转到转到50元还没有到 D 的账户中。那最终就会导致四个账户之间的总金额变成了110，这对于我而言是不可接受的。因此需要计算出一个一致性的位点来保证我恢复的时刻。有了理智性的位点后，便会对增量的那个日志进行裁剪，备份这份增加日志。最后一步是元数据的备份。 polarDB-X 备份集的构成是原数据，包括 polarDB-X 的账号密码源、拓步信息等。最后 dn 节点的全量物理备份，会为每一个 dn 节点配增加一个增量的备份日志。增量的备份日志会保证他们统一，所有的点都恢复全局一致的位点，保证恢复出的数据的一致性。目前 polarDB-X 备份集支持多种的存储方式，例如 oss、sftp 等，那未来我们也会支持更多的方式。
云起实验：《如何对 polarDB-X 进行备份恢复》
在上 ECS 创建一个 kubectl 集群。首先第一步输入 Kubectl get nodes 命令，加载出具体信息，这些信息中可以看到它是有两个节点组成的集群。通过提前创造好的 polarDB-X 实例，这个实例是由一个 cn 节点两个 dn 节点组成。接下来进行一个转账测试，来真实模拟转账流量。
首先输入 kubectl apply -f transfer.yaml，打开提前准备好的文件，里面有转账测试的工具。之后输入 kubectl get job ，创建新的 job。再输入 kubectl get pods,查看 pods 的情况。等所有 pods 进入 running 状态即可。之后输入 kubectl logs transfer-test-polan rdbx-wn6tb 查看日志情况。命令运行后可以看到已经开启了一个整个业务流量。之后登陆到 polarDB-X 查看数据情况。首先通过 kubectl get secret polardb-x -o jsonpatth="{.datal'polardbx_root']}" | base 命令，获取刚才创建的 polarDB-X 的密码。之后通过 kubectl port-forward sv c/polardb-x3306 命令转换端口。在这一端口中连接我的 polarDB-X。连接成功后输入 show Database,之后可以看到有一个 transfer test 数据库。再输入 use Transform_ test, 进行运行。之后再输入 show tables,运行后可以看到有一个 accomts 的表，输入 select * from accounts limit 5;可以查看数据运行情况，运行后可以看到每个账户的ID、账户余额。输入 Select Sum（balance）form accountants; 查看账户的总金额,之后多次进行查询，总金额数量是不变的，可以证明 polarDB-Xx 具有强一致性。
对 x 进行备份以及对备份出的数据进行验证。首先选择备份方式,目前 polarDB-X 备份仅支持 oss、sftp 两种。今天以sftp 的方式进行备份。首先，输入命令 cat backup-storage-patch.yami 打开提前准备好的 sftp 的 yami 文件。
这里面包含了sftp的名字。以及运行主机的 IP、Port、用户密码等。之后输入 kubect! -n polerdbx-operator-system patch configmap polardbx=hpfs=config 命令使存储生效，之后输入 kubectl -n polardbx-operator-system rollou it restart daemonsets polardbx-hp 重启组件。之后输入命令 cat polardb-x-backup:yaml 打开提前准备好的对应 的备份级 yaml 文件。 之后通过 kubectl apply -f polardb-x-backup. yaml 进行备份。之后可以通过 kubectl get pxb -w 观察运行情况。当备份对象变成finished的状态,表示备份已经完成。
之后对 polarDB-X 进行删除，然后根据刚才创建的备份集对对象进行恢复。^Cigalaxykube@iZuf660p6384azsfnl2cc87Z ~$ 执行这一命令，把整个测试和 polarDB-X 删除。
cat polardbx-restore.yaml 通过这一命令打开提前准备好的 yaml 文件，里面包含恢复数据的规格信息。
在这一文件中，通过制定一个
restore:
backupset: polardb -x-backup
[galaxykube@izuf660p634azsfnl2cc87Z~$
来进行恢复，之后输入
kubectl apply -f polardbx-restore.yaml，创建新的实例，对之前实例进行恢复。
可以通过 kubectl get polardbxCluster polardb-x restore -o wide -w 命令，观察实例状态，可以看出数据已经恢复。
之后观察数据内容是否满足要求。可以通过 kubectl get secret polardb-x-restore -o jsonp path="{.datal'polardbx_root']} 查看密码，之后通过 kubectl port-forward sv c/polardb-x3306 命令转换端口，之后在下面进行连接，之后和上述同样步骤来查看数据库情况，输入 show Database,之后可以看到有一个 transfer test 数据库。再输入 use Transform_ test, 进行运行。之后再输入 show tables,运行后可以看到有一个 accomts 的表，输入select * from accounts limit 5;可以查看数据运行情况，运行后可以看到每个账户的ID、账户余额。输入 Select Sum（balance）form accountants;查看账户的总金额，和原数据相同。
3.备库重搭（高可用）
备库重组是另一项重要的保证数据高质量的设定。polarDB-X 的 DN 节点是通过 XPacksouce`来实现的。一个三副本里面包括 leader、follower、logger、Learner。任意节点的宕机不会影响 polarDB-X 整体可用性。举个例子，如果leader 宕机，follower 会自动成为 leader，对外提供服务，如果 follower 宕机，leader 不会受到到影响，依旧对外提供服务。但是如果 follower 所在的主机彻底宕机，已经无法恢复。那这种情况下的话，dn 节点只有 leader 和logger 在运行。如果此时再宕机一个节点，这样的情况下我们的服务便会受到影响，因此需要一种办法将原来的follower 迁移到另外一个不同的节点上运行，重新恢复到三副本的状态。另外一种场景假如一台宿主机需要去做下线或者迁移，那么这台机器上的dn节点该怎么办？对于像 cn 还有 cdc 这样的无状态的节点，可以直接从负载均衡上摘除。但是 dn 这样的有数据的节点应该如何处理？那就是备库承担功能所使用的应用的场景啊。它可以将 follower 、logger 还有 learner 节点在另外节点上进行重建，然后加入 Packsouce 集群。但是不支持 leader 节点，因为 lerder 节点如果直接重建的话便会影响服务，因此如果想重建的节点的话，需要通主备切换的方式来将 follower 变成 leader，将 leader 降为 follower，即可做重建。同时假如机器能够恢复，又不想增加额外资源，也支持本地传达恢复。这边也对备库重搭提供了一个云起实验《如何对 polarDB-X 的存储节点发起备库重搭》帮助了解如何在副本数据损坏的情况下进行修复。
