开发者学堂课程【PolarDB-X 开源系列课程：第五节：PolarDB-X 集群运维2(二）】学习笔记与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/1032/detail/15161
第五节：PolarDB-X 集群运维2（二）
内容介绍：
三、课程演示
四、资源介绍
三、PolarDB-X CCL&SQL Advisor
当 PolarDB-X 集群如果遇到了一些问题 SQL 的时候，如何通过已有的一些手段来对它进行处理、优化，保证系统的稳定运行。会介绍两个能力，一个是 SQL 限流，另外一个是 SQL Advisor 就是索引推荐，这部分的能力目前已经在云起实验室中上线了相关的课程，今天也会直接通过云起实验室的课程进行演示。直接打开云许实验室的链接，可以看到有一个实验叫如何在 PolarDB-X 中优化慢 SQL。
首先，需要创建像实验相关的资源，
资源已经创建完成了，账号已经登录上来了，接下来会按照实验手册的步骤一步一步的进行操作。第一步，需要连接的 PolarDB-X 集群，首先需要切换账号到 galaxykube 下面，
这个已经预置在这台机器上了，接下来需要通过这个命令创建 minikube 的 K8S 集群，这个 K8S 集群其实已经在这台 ECS 上准备好了，现在只是把它重新拉起来，
这边其实已经提前创建好了 PolarDB-X 的集群,
目前 GMS 和 DN 已经起来了，现在就差 CN 和 CDC 了来，看一下它的 pods 情况。
好像有点错误，
把刚刚这个集群删掉重新创建，可能是预置在 ecs 上的集群有些问题，
CN 已经 ready 了，现在就差一个 CDC 了。
实例已经 ready 状态，接下来会按照这个命令，先拿到集群的登录密码。
这条命令其实就是从 K8S 里面的 secret 获取到 PolarDB-X 里面相关的一些密码，密码都是存在 secret 的对象里面的，然后将其进行 base64的解码，就可以拿到这样的密码。接下来需要将 PolarDB-X 实例的3306端口转发到这台机器上，通过 kubectl port-forward 命令就可以实现。在这基础之上需要再新开一个窗口，通过加号命令开了一个新的终端，之后通过MYSQL 命令行的方式登录这个视频，密码是刚刚去获取到的。
这边已经登录上来了，来看一下里面数据库的情况，
可以看到现在是一个空的实例，接下来按照下一步进行操作，首先需要启动 sysbench 的业务，创建一个 database 叫 sysbench_test。接下来用使用 sysbench_test，会 use 这个 kube，登录到这个数据库里面，
目前这是一个空的库，接下来按照第三步，需要在页面的右上角重新再创建一个新的终端三，
然后也是切换到 galaxykube 账号下，
之后到 galaxykube 账号的主目录编辑一个叫 sysbench- prepare.yaml 文件，
这个 yaml 文件其实就是 K8S 的一个 job，使用的镜像是 sysbench 的公开镜像，在参数部分配置了 PolarDB-X 实例的连接信息，包括连接串、端口、用户名、密码，同时这边会导入16万行的数据，使用的是 sysbench 里面的paraller prepare 这一场景，接下来把这个文件保存，通过 kubectl apply -f sysbench-prepare.yaml 的方式创建 job 对象来导入数据，
接下来看 job 是否创建出来，
它已经开始运行，看一下它的日志，通过 kubectl logs 命令就可以看到，
它正在导入16万行的数据到一个叫 sbtest 的表里面。接下来启动 sysbench 的压测流量，这个名字叫 sysbench-select，也是通过 vim 的方式创建这个 yaml 文件
同样的，它也是 K8S 的 job，然后我们使用的容器还是和刚刚准备数据的容器是一样的，也是 sysbench 的公开镜像，另外，这边也是配置了刚刚实例的连接串，同时这边采用的压测场景是 select_random_points，就是一个随机的点查，下面会把压测流量开起来，
保存好，然后通过 kubectl apply 的方式创建 job，已经创建出来后通过 kubectl get pods 查看运行中的 pod，
可以看到 cubectl point select k 这个 pod 已经起来了，来观察一下它的日志，
可以看到压测流量目前已经起来，现在它的一个 QPS 大概在六、七百，接下来体验 SQL限流和 SQL Advisor。现在假设模拟了刚才起的 sysbench 的压测流量是一个存在问题 SQL 的业务，它占用了较多的资源，对线上的其他业务产生了一定的影响。接下来需要找到这样的问题 SQL，然后将其进行限流。首先，到刚刚终端二里面的页面，
也就是这个实例下，因为刚刚已经 use 了 sysbench_test 数据库，通过执行这样一条语句叫 show full processlist where info is not null，能查看当前数据库里面执行的 SQL 的情况，
可以看到目前数据库压测流量大量的有这样一条 SQL 叫 select id,k,c,pad、from sbtest，它是基于 K 列的查询，这样一条查询，假设它对系统业务造成了影响，影响了其他的在线业务，这时候可以通过 PolarDB-X 提供的 SQL 限流语法快速的创建 SQL 限流规则，把这条SQL 拦截起来，不让它去消耗资源。把这条限流规则创建出来，
create ccl_rule 是关键字，我起的 ccl_rule 的限流规则的名字叫 block_select，它是对 sysbench_test 的数据库应用生效的，只对 select 的语句生效，同时会通过关键字 pad 进行限流，最后是 max_concurrency，限定的是0，就是不允许这条 SQL 在系统上执行。接下来切到之前终端里面的 sysbench 流量，看一下现在发生了什么，
可以发现 sysbench 流量已经跌0了，有大量的报错，说明刚刚这个业务起来的 SQL 已经被全部拦截，不会被执行了。接下来通过这边一条命令叫 show ccl_rules，能够查看当前 SQL限流规则的运行状况，把它用/G 的方式显示，
可以看到它的 rule 名字就是刚刚创建的叫 block_select，接下来它给出了目前规则已经 killed 的 SQL 请求数，这边目前已经 killed 了17万数目，下面给出的是 SQL 限流的一些匹配规则，比如只针对 select 的语句规则去限流，用户是 PolarDB-X_root，关键字是包含pad 的 SQL，这样它就已经起到了限流的效果，保障了业务的稳定正常运行。把这条业务SQL 已经限流住，恢复了正常的在线业务，下面便是要去分析刚刚这条 SQL 为什么会导致系统问题。对于有经验的 DBA 可能第一件事会先看它的执行计划以及这张表的表结构，也是通过云起实验室里的命令，
已经打出了执行计划，可以看到，这条查询涉及到了有八个分片上的查询，会下发到每一个分片上进行这样的查询请求，而这个 K，可以看到它的 in 只是一个值，所以它的最终结果只会存在一个分片上，来看一下这张表的表结构，
这张表的表结构里面有几个列，一个是 ID，一个是 K、C，还有一个是 pad，ID 是一个分库键，K 既不是分库键也不是分表键，但是在上面有一个本地的索引，由于只有本地索引的存在，没有全球级索引的存在，所以不知道 K 等于10这一条数据会具体落在哪几个分片上，因此把这条 SQL 转换成相应的物理 SQL 下发到所有的分片，造成一定的不必要的查询，这时候有经验的 DBA 可能会想到的操作就是针对 K 的列创建一个全局二级索引，这样就能减少不必要的一些分辨查询操作。PolarDB-X 已经提供好了一个很方便的工具叫explain advisor 的命令，它能够我们帮助自动的去做索引推荐的操作，而不用我们再去做刚刚这样的 SQL 分析，
它已经执行出来了，explain advisor 是关键字，后面跟的这条就是需要去分析的 SQL 文本，可以看出它给出了我们推荐的索引叫 advise_index，它推荐的也是我们创建关于 K 这个列的全局二级索引，同时还给出了预估创建完这一个索引之后性能提升的比例，会有37%的提升，另外，结果里面还给出了一旦把这个索引创建出来之后，我们最新的执行计划会变成什么样的情况。接下来按照 sql advisor 给出的建议来创建这个索引，
已经创建完成，由于刚刚已经创建了一个 SQL 限流的规则，把有问题的 SQL 给拦截了，接下来把限流规则删除掉，理论上如果刚刚创建的这个全球级索引生效，就会对刚刚那条 SQL 进行优化，来提高它的执行效率。把刚刚的 SQL 限流规则删掉，来接着看一下刚刚的 sysbench 的流量，
可以看到前面的因为有 SQL 限流规则存在，流量跌0之后，到这边已经把 SQL 限流规则清理掉，流量已经开始恢复。另外一个现象可以看一下，
在最初这条 SQL 执行的只有大概七八百的 QPS，等加上了刚刚推荐出来的全局二级索引，整个实例的 QPS 已经到了2000左右，它的执行效率得到了大大的提升，这便是云起实验室里面演示的 sql advisor和 SQL 限流两个内容。
这部分实验演示就到这里，接下来开始对这今天实验中的内容做知识的介绍。
1、PolarDB-X SQL限流(应急处理)
首先是 PolarDB-X 的 SQL 限流，它是一个应急处理的手段，举个例子，当 PolarDB-X 上正在运行了在线业务的时候，某一天有新的业务上线，但是这个业务里面存在一些问题 SQL 写的不那么好，会占用过多的资源，导致系统的瓶颈，这种情况下，可能常规的手段是需要联系业务的开发方，或者去跟他们沟通，让他们配合把这个业务改掉，这个问题 SQL 改掉，或者像临时的回滚，这样的过程往往也是比较耗时的。对于已经在线的业务，其实是不太能够等待这么一段时间的，它需要能够尽快的去做业务的恢复和止血。因此，PolarDB-X 提供了 SQL限流的能力，它能够快速的将问题 SQL 拦截在外，不再占用系统的任何资源，保证已有业务的稳定运行，同时，SQL 限流也支持了很丰富的 SQL 匹配方法，这边已经给出了 SQL 限流的语法，
CREATE CCL_ RULE [ IF NOT EXISTS ] 'ccl_ rule_. name'
ON 'database' . table'
TO '<usename>'@'<host>'
FOR { UPDATE| SELECT| INSERT| DELETE }
[ filter. _options ]
with_ options filter. options
[ FILTER BY KEYWORD( ' KEYWORD1', 'KEYWORD2',_) ]
[ FILTER BY TEMPLATE('template_ id')]
with. options:
WITH MAX CONCURRENCY = value1 [，WAIT_ QUEUE SIZE = value2 ] [，WAIT .TIMEOUT = value3 ] [ ,FAST _MATCH = {0，1 }]
可以看到它支持多种的匹配方式，第一个，可以针对某一个 database 的某一张具体的表来做限流，它可以做到比如只针对某一张有问题的表去限流关于这张表的 SQL，其他表的 SQL 不会限到。另外也可以按照用户名和执行的主机来去限，举个例子，假如新业务是在某一台固定的机器上使用了新建的账号访问的，这样便可以快速的定位到这个新建的业务。当然，如果只想对 select 或者 insert 这样的语句去做限流，也是支持的。除此之外，还针对 SQL 的内容提供了两种匹配的方式，一种是基于关键字叫 keyword 的方式，它能够根据 SQL 里面的关键字去做规则匹配对它进行限流，另一种是基于 SQL 模板的方式，就是可能业务是基于模板生成的，不同的 SQL，不同的用户进来，可能只是参数不一样，针对这一类的 SQL，我都想把它限流住，便可以通过模板 ID 的方式进行限流。
这边分别给出了基于关键字和模板 ID 的两个限流的语法，
基于SQL关键字：
CREATE CCL_ RULE IF NOT EXISTS、'selectrule'
ON *.*
TO 'ccltest'@'%'
FOR SELECT
FILTER BY KEYWORD (cclmatched')
WITH MAX_ CONCURRENCY=0;
基于SQL模板：
CREATE CCL_ _RULE IF NOT EXISTS、'selectrule 、
ON *.*
TO 'ccltest'@'%'
FOR SELECT
FILTER BY TEMPLATE ('b722ad1')
WITH MAX_ CONCURRENCY=0;
可以参考 SQL 限流的文档去做更深入的了解。
2、SQL 执行的过程
做完了应急处理，接下来便是要对有问题的 SQL 进行分析，找出原因并对它进行优化。
首先，来看一条 SQL 在 PolarDB-X 上它执行的过程，
它主要分成三层，首先是客户端会将业务 SQL 发到 PolarDB-X 的 CN，我们会对其进行解析、优化，然后生成执行计划并调度、执行。对于中间可以下推的部分，会直接通过网络的方式下推到每个 DN 节点上去执行，并收集返回的结果。对于不可以下推的部分，会等 DN 的结果返回，在 CN 中进行计算，最终将结果返回到用户的客户端。在这个过程中，主要关注的就是 CN 和 DN 两部分的资源使用和执行的耗时。针对这几种场景，我们将可能存在 SQL 的原因分成了这三类，第一类是业务问题，它可能包括比如数据存在明显的数据倾斜，或者不合理的分片策略，这种情况下就有可能出现某一个分片里面的数据量会非常多，某些分片数据量非常少，一旦某一个 SQL 落到了数据非常多的分片，它可能就会占用比较多的查询时间，或者产生较大的数据扫描 IO，成为整个 SQL 执行的瓶颈点，这时候可能需要对表结构进行优化和调整。还有一种问题，比如业务使用上的问题，类似刚刚实验里面看到的，基于 K 这个列进行查询，但它却缺少了一个全局二级索引，导致了很多不必要的分片的扫描，占用了较多的 CN，比如 CN 的 CPU 资源，这种情况下可能需要进行 SQL 的优化，或者是创建一些索引来对这个问题进行优化。还有一种情况是这个业务或者这个 SQL 本身就是需要返回过多的数据，举个例子，比如业务上有一个报表查询，它本身就是需要查询大量的数据去计算报表的结果，这种情况下可能就会推荐比如设置一个合理的限流规则，可能不用像刚才演示的那样去直接拦截，但是可以去限定它的并发度，避免过多的这样的 SQL 进来，占用过多的资源。第二种问题就是系统的问题导致的，比如业务发展过快，流量得到了迅速提升，导致整个目前的资源成为了瓶颈，这种情况下可能就推荐通过弹性的扩展的方式来增加更多的机器，对问题进行优化。另外一种，比如 CN 到 DN 之间的网络有抖动，导致了延迟变大，这种情况下可能就需要检查系统的一些网络配置是否正确，或者网络中间的一些组件是否存在问题。第三种是执行层面的问题，因为业务上的 SQL 到了 PolarDB-X 的 CN 节点，会对它进行解析、优化，生成相应的执行计划，在这个过程中会根据统计信息选择合适的执行计划，如果执行统计信息过期或者不是那么准确，就有可能出现选错索引，或者选错 join 的类型或顺序等等，这样也会导致 MYSQL，这种情况下可能就需要对 SQL 进行进一步的分析优化或者进行改写，来优化这样的问题。
3、数据库优化
针对刚刚提到的几种 MY SQL 产生的原因，给出了它相应的一些处理方式，这边给出了一个列表，
主要包括对 SQL 改写以及创建索引，对库表结构优化，调整系统配置以及增加更多的硬件。将这几种方式通过一个金字塔的方式进行排布，在金字塔上面自下而上，它的优化的成本是逐步提升的，但是它的效果却反而是越来越差。对于 SQL 及索引调优，对于我们而言，其实并不需要花费过多的成本，却可以取得显著的效果。对于像硬件这样的一些资源，可能需要加一台机器，或者需要去搬迁数据，其实是比较耗时，也需要付出更多成本的一种优化手段。这也是为什么当系统或者说当数据库出现问题的时候，DBA 往往第一时间会先去看我们有没有慢 SQL，然后分析这些 SQL 的执行计划，看是否有调优或者创建索引的可能，但是创建索引其实也是非常依赖 DBA 的经验的，也是比较耗时的，针对这种情况，在刚刚的演示中，PolarDB-X 提供了一个自动化的索引推荐能力，叫 explain advisor，下面将对 explain advisor 的实现原理做简单介绍。
4、PolarDB-X SQL Advisor基本原理
它的过程大概分成这三个部分，
第一个部分叫可索引列的分析，就是需要找出哪些列是可以添加索引的，这些列可能包括 while 条件里面的列，join 条件里面的列，或者 group by 或者 out by 这里面的一些列。举个例子，lineitem 这张表它有两个列是可索引的，第一个 quantity，它其实是 while 条件里面的一个列，比如 I while quantity 小于0.2，这样这个列其实可以作为我的索引候选项的。还有一个 partkey，它其实是在 join 里面起到了效果，它是我的一个 join key，同时对于 pad 表也是一样的分析方式，通过这样的第一步的方式找到这一条 SQL 里面所有可以创建索引的列，然后去构建候选索引的集合。这个候选索引的集合构建其实是基于这么一个假设的，我们认为对于一张表，它产生关键影响的索引数不会超过两个，基于这样的假设，我们限定索引的长度，也就是组合索引的长度不超过2，在这个条件下，将所有的索引进行枚举，就可以生成 candidate index，也就是所有的候选索引的集合。接下来要做的便是在这些不同的索引集合里面找到最优的集合，把它推荐出来，那便是最优的索引推荐的结果。
怎么找到最优的索引集合？PolarDB-X 的优化器其实是基于代价的优化器，
对于每一条 SQL，都会估算出它的执行代价，在这种情况下，优化器还提供了一个叫 what if 的能力，what if 就是我告诉优化器这边有这个索引，但是却不实际去创建它，这种情况下请你告诉我它的这条 SQL 的执行的代价是多少，有了 what if 的能力，我只需要将刚刚构建出来的所有的索引的候选集合分别输入到优化器中，告诉它，我如果有第一个索引，你告诉我这条 SQL 它的执行代价是多少。第二个索引创建之后它的执行代价是多少，只需要在这样的枚举中找到执行代价最小的索引组合，那便是最终的推荐结果，可以达到刚刚所说的推荐出一个最优的索引的效果，这便是 PolarDB-X 索引推荐的基本原理。
四、资源介绍
首先，代码都在 Github 上开源了，可以下载下来去阅读。另外，如果对 PolarDB-X 的使用或者运维以及相关的原理感兴趣，可以关注我们的文档以及官方知乎账号，里面有很多的源码解读或者使用相关的一些文章。这堂课程的内容已经在云起实验室上线了，课后可以直接到云起实验室进行实际操作来增加体感。
监控能接 ZPS 或者接收企业微信发短信吗？
这是可以的。我们基于的是Prometheus 加 grafana 这套方案，这个方案里面还有一个组件就是 alert manager，它可以对接 Prometheus 的数据，然后再对接不同的消息源，给大家发送报警或者一些比如通知信息，这是支持的。
explain advisor 为什么里面的结果有些 memory I 会是负的？
这条语句的推荐里面，因为它的 memory I 是负的，是这部分代价会增加，但是因为我们减少了分片的扫描，它的网络代价会是减少的一个过程，最终去判断 improve 的效率还是有提升的，所以会推荐出这个索引，你可以理解当我对一条 SQL 创建的索引，然后它可能在比如网络上会有提升，但是在 CPU 和内存上会有所增加，这也是合理的，我们会有基于优化器的代价评估。
全局索引和局部索引可以分开建吗？
这是支持的。一个 DN 上的 leader、follower 保障副本，但磁盘坏了，数据不一样丢，那做多副本的意义何在？
举个例子，高可用其实保证的是概率问题，我们认为一个 DN 上的三副本会部署在不同的机器上，如果这三台机器同时都坏了，确实也没有办法，如果只是坏了中间的一台机器，还是有办法会保证业务的可用的，如果坏了两台，可以保证数据的一个不丢。刚才在命令行里面会有一个命令补全，对的，这是我们安装的 base 的一个插件。Export 能接入自建的 Prometheus 和 grafana 吗？
是可以的，因为可以看到我们创建的 PolarDB-X 实例，默认是不带，不安装 PolarDB-X monitor 是没有监控的，但是 export 是已经启动起来了，只要 Prometheus 能够访问到 export 的服务，就可以拿到监控指标，去自己构建监控报表。
一个 DN 如何对应多个主机节点？
一个 DN 会有三个节点分散在三台主机上，分别是 leader、follow 和 log 这样的角色，对于它们会是一个 paoxs 组，最终是 leader 对外提供服务，follow 和 log 保证数据的强一致和可高可靠，假如 leader 挂了，follow 会自动的升为 leader，然后对外提供响应。
