临时工访谈：PolarDB Serverless 发现“大”问题了之灭妖记续集-优快云博客

本文链接：https://blog.youkuaiyun.com/liuhuayang/article/details/138991774

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2300人左右 1 + 2 + 3 + 4 +5 + 6）新人奖直接分配到5群超400人已经关闭自由申请通道,开始建6群。

最近和POLARDB 算是干上了，PolarDB 灭了我第一次，我这个不服气呀，我这继续作妖的精神呀，大妖啥都不怕。想知道PolarDB 怎么上次灭我的可以看下面的文章，团灭我的过程。（这篇文章前面是描述问题，吃瓜看阿里云的老师怎么又灭了我一次往文章中段下面灭妖记续集开始看）

临时工访谈：庙小妖风大-PolarDB 组团镇妖之他们是第一

昨天大妖评测POLARDB SERVERLESS 提了一堆的问题，但需要说明一点，如果按照做车的理念，POALRDB SERVERLESS 不是彩电冰箱大沙发，他是有好的发动机和底盘的，变速箱的，三大件没问题。具体昨天怎么发难 PolarDB ServerLess 可以看下面这篇PolarDB Serverless POC测试中有没有坑与发现的疑问 ？

昨天发现了一些问题，提了一些意见但都不是大问题，整体的SERVERLESS的表现，应该是令人满意的，没有硬伤，至少我现在没有发现，今天我们变换测试的方式，因为PolarDB 本身是可以在购买固定的节点后，在使用中直接转换为 serverless 的节点的，所以大妖今天早上没有停手，继续找POALRDB SERVERLESS的麻烦，要进行更深度的测试发现一些问题，看看到底昨天测试中有没有遗漏，要是能翻出PolarDB的大瓜，那上次账就算是一雪前耻了，到底看看老道长的脸往哪放。

好在早上就找到“大瓜”这里直接上图，这里购买了PolarDB 的固定版本的数据库后，只有两个节点，配置是固定的，固定的节点就是配置是固定的，这里阿里云为了方便客户，在固定POLARDB 的基础上，给出一个固定PolarDB 转换为serverless 的方式，这也是我认为做的比较人性化的地方。但是，但是，但是，在我使用这个方式的情况下，遇到了如下的问题

1 在我购买后，多出一个只读节点，并且根本踢不下去，哪怕变更配置的下限都不行，这对我是无法容忍的，原因很简单，费用费用费用，我怎么和老板交代，本来2个节点的POALRDB 变更为SERVERLESS 后就出来三个节点了，问题是我这也没有负载呀？WHY （后面找到的原因，不是我想的那样）

2 调整配置的问题，这单也非常的怪异，调整了serverless 上限PUC的数量，而变化的只有原来的两个固定的节点，而多出来的那个节点可是不听话，1-32 的配置上限算是拉满了？ WHY （后面也找到了为什么）

3 展示的问题，在调整到SERVERLESS后，原来固定的两个节点，还是显示2核心16G ，而多出那个节点是 1-32 PCU ，这个展示的问题是否可以调整一下，要不看上去实在是..... 不过这个问题不重要

上面两个问题才是大问题，客户是不会为没有使用的东西付费的。

此后我们有尝试关闭serverless ,关闭的速度非常快，超出了我想象的速度，马上就变成了两节点。打回了原型，这里点赞。

然后我还不死心，继续和PolarDB Serverless 进行拉锯测试，不断的开启 serverless 关闭serverless ，不断的调整配置的参数。

这次我长了一个心眼，在调整的时候，直接将多节点的个数下限直接选择成0 并且只读节点和个数上限直接选择成0。得到的结果是我要的结果。那个突兀的新加的只读节点没有了，多出一个只读节点如何被消灭的方法我找到了，然后我不死心继续找茬了，为了发现其中的一些规律，对POLARDB 进行弹来弹回的操作，可能心理有点变态，就想让他出大问题，好来质问那些POLARDB的“大罗金仙”。

在多次的实验中，关了开开了关对于我的手都是一种虐待的情况下，我发现了一些规律。

然后我总结出这次的测试的一些问题

问题 1 在今天本文中的第二种购买方式中，为什么产生了一个多余的节点，原因在于变换配置的情况下，只读节点个数的下限，如果填写的是 1 ，则会产生一个除原有节点以外的只读节点。如果写的是0 则不会出现这个节点。

这对于上面我提出得的问题，有了解决方案，是设计者和使用者之间的理解误区。使用者认为只读节点下限包含了我之前固定主机上的只读节点，而开发者或者设计者认为，这个不包含是你要在多购买一个，所以这不是一个大问题。

使用者可以注意在固定POLARDB 的转换为SERVERLESS的情况下，将只读节点数的下限填写为 0 ，这样的情况下就不会出现本来有两个节点读和写，然后又出来一个读节点的情况了。

解决方法：调整 SERVERLESS的参数将只读节点个数下限，调整成0 同时将上限的个数也调整成0，然后多余的只读节点就下去了，然后在把上限改回成你要的上限个数，问题解决。

问题2 调整的PUC 的节点只在固定的数据库节点生效，而在多出的只读节点不生效，这又是为了什么？

解决与产生问题的理解：写节点到一定的状态就提升从库的配置，带动读节点生配，那现在这个状态是........ 从逻辑上我是明白，我给你最大的节点的PCU可调性，反正有前面两个节点控制，不会让后面只读的节点的PCU超过前面PCU的上限。我这样的大妖是能想明白明白的，可那些小妖们估计要明白就难了。虽然这个最终的逻辑是对的，但你展示上能不能下点功夫，你展示上下点功夫，你的客服和二线就不会，面对客户的这方面白痴的问题了。

客服小哥挺好，一直在当传话筒，不过我的态度不是太好，在沟通中我没有想明白一些问题，所以有了如下的截图。

然后你以为这个故事就结束了，NO NO NO ，大罗金仙出场了，负责POLARDB SERVERLESS 的云壤老师出现了，直接电话给大妖解决问题。（哪里是解决问题，分明是电话直线灭妖）

灭妖记续集开场

————————————————————————

上来云壤老师非常NICE 的将昨天文章中提出的问题，在电话里面逐一的解释，下图是昨天的问题

云壤老师： 刘老师您好，我先说说昨天您提出的问题，昨天提出的系统触发点的问题，这点我们已经修改了，很快就能上线，在官方文档中给出的值是系统资源提升PCU的触发值是整体系统资源达到80%后，这点我们已经修改了。

然后云壤老师直接在群里甩出一张图，是改后的用户界面展示图。

云壤老师：刘老师您看我们已经提供了灵活的让客户进行触发点敏感度的调节了的界面了，并且我们还给出了灵敏度这个概念，让客户可以针对一些极端的业务，如突发的OLAP的查询突发的那种，让POLARDB 以最快的速度进行弹升，但具体什么业务需要快速的弹升，用户可以自行决定。

您看这个问题，您还有问题吗？

临时大妖：（这上来就过招，昨天提出的问题，今天就解决），挺好的，但是我昨天提出的第二个问题呢，就是为什么主节点提升了PCU 还要带着从节点也提升PCU 是什么道理呀，这是不是要占客户的便宜，让客户多付费呀？

云壤老师：您这个就多想了，相信您应该是明白POALRDB 的原理的，在POLARDB FOR MySQL 中咱们是通过内存RDMA来传输 REDO 中的一些核心信息，如果您的主节点的负载在提高,PCU 也要提高，那么从节点是不是也要为大量的数据复制而做准备，提高PCU呢，我们提升PCU是为了客户的数据库系统的稳定性着想，不存在您提出的占用户的便宜的问题，您想多了。

大妖，瞬间石化，他说的有道理呀！

临时大妖：那咱们这只读节点不下线是怎么回事呀，云壤老师，这是不是一个严重的BUG 呀？

云壤老师：刘老师，您这又误会我们了，您想想我们由于业务的压力扩展出的只读节点，怎么能轻易的瞬间的回收呢，如果这样话那么客户在这个节点的压力虽然下来了，但是一定有其他的一些业务也在上面跑，我们就直接因为业务压力下来了，把只读节点就下线了，你说这样我们不是要犯错误吗？业务出现问题，这个问题您想过吗？再说了，您说这不下线，客户说成本问题，这下线了，客户说业务安全问题，您这不能两头堵呀？

大妖，瞬间石化，他说的有道理呀！

临时大妖：那也不能不下线，一直不下线吧？

云壤老师：您刚才不是找到办法了，调整上限和下限值，就能通过手工来解决问题，后面我们可以商量，在现有的基础上，给客户提供一个更简便的人工下线节点的方式，这不更符合客户的安全和客户成本，由客户来掌握的原则吗？当然我们也有一套严谨的流程，让扩展的只读节点自动下线，当然比较复杂，具体看节点上业务的情况。

大妖，瞬间石化，他说的有道理呀！