PolarDB 大能人系列--弹性我们有一个新需求！ 普及数据库弹性知识

❝开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7 8群已经爆满 9群 300+，开10群PolarDB专业学习群110+ 针对 SQLite 我们将建立一个新的群sqlite的群，如果需要请加群的时候单独告知)

这是Austindatabases公众号的2026年的第三个系列，我是大能人。本系列会围绕PolarDB 进行知识分享，发现PolarDB云中中的问题，以及产品设计中的一些建议为主题，基于本人工作中当前核心的数据库是PolarDB for MySQL 和 PolarDB for PostgreSQL 为基础，里面也会融合一些 RDS 数据库产品，作为年度第三个核心的知识点。

上期我丢人了，那么简单的问题都没有发现，还让PolarDB的同学给查了半天，我都恨不得找地缝藏一下。

这周我们的架构师小哥给我提了一个关于PolarDB的弹性的需求，我借着这个文章和阿里云的PolarDB的老师把这个需求说一说，看看能不能做。

另外我也总结一下PolarDB的弹性部分的知识，和大家一起来看看你们的弹性和我使用的弹性是一码事吗？ 下面我以问题的形式来介绍我认知下的 PolarDB

1 弹性可以解决数据库性能，在大部分情况下遇到的资源不足的问题吗？

从我们的使用3年serverless的角度，是的。如果你的系统正在经历，突发的业务，比如你是一个saas公司，然后你的客户今天举办一个几百个店的活动，并且没有通知你。平时的情况下，我们并不知晓，只能看见CPU和内存飙升，并且此时我们去查慢SQL等问题，添加索引等。

但平时这样的操作并不能避免数据库DOWN机，OOM等问题，此时serverless的意义就出现了，就是在你没有提防的情况下，在你系统开始无法承受业务的压力，需要更多的算力，或CPU的时候，直接弹起资源，满足你的突发性的需求。

2 弹性只弹CPU和内存吗？

不，弹性哟多种方式，弹出CPU和内存仅仅是一种形式，另外PolarDB还剋弹出只读节点来应对大量的读操作，最多可以在从节点无法忍受CPU和内存的压力的情况下，直接弹出15个只读节点。

3 弹性中最小的单出单元是什么？

弹性中CPU和内存是绑定的，以PCU的形式出现。一个PCU = 1CPU + 2G memory， 弹性没错最小弹升的单位是 0.5 PCU 。

4 个读节点在什么时候弹出？

横向节点的弹出，其实这个问题我也是特别想更清楚，同时我的需求也来自于这里。一般的情况下，只要只读节点开始进行 PCU的弹升的情况下并且达到扩展的上限的情况下，横向的弹升就开始了。所以即使你有2个只读节点，一个没有任何PCU的弹升，而另一个弹升到PCU的上限，那么这个节点就开始弹出 只读节点。

所以这个问题我特别想和阿里云的POLARDB的老师讨论一下，我们的新需求。

5 什么时候弹升回缩，标准是什么

这里有一个问题，默认的情况下，数据库在没有负载的情况下，为什么弹升还不去掉，这里就的说到一个问题，内存的下降，内存不下降的情况下即使CPU不被使用，也无法下降。所以可以调整POLARDB FOR MYSQL的 innodb buffer pool的 大小来加速在弹升后的下降。

这也是目前主要的方案，同时也可以减少链接，来促成内存的下降，来进行整体的弹升的回缩。

回缩标准

回缩标准

6 横向弹升和纵向弹升的关系的问题

这个部分也是此次我想提出问题的地方，我先说说诉求

1 纵向弹升，目前的弹升方式和设置都是满足我们目前的使用的

2 横向弹升，也就是弹出只读节点的部分，这个部分我们使用的比较少，主要还是成本的问题，纵向弹升的成本可以接受，而横向弹升的成本是直接弹升出一个节点，费用自然比纵向弹升要多。

所以这里需求方，也就是用户会有几个疑问

1 我们是否可以突破 16PUC的限制，我们不想横向弹升，我们只想尽量更多的弹升纵向的配置，比如32PCU

2 横向弹升的可限制，比如如现在的横向弹升是不可以调整的，用户想调整比如我们在 CPU 达到95%以后才考虑横向弹升，而不是在用户不可控的时候进行横向的弹升。

在直白的说，用户抠门，不到他认为影响业务的时候，他就不想进行横向弹升，所以他要设置阀值，他要掌控成本，他要在成本合适的情况下，在逼不得已的阀值下，进行横向的弹升。

所以我们需要在弹性中，设置出来一个弹性横向节点的阀值，比如只读节点达到多少 cpu 内存使用率的时候，进行横向节点的弹升。 同时，在监控和告警中，还应该提示，横向节点的弹出的INFO。

或者作为产品，还可以有一个保证金的制度，比如如流量包，如果客户评估一定会弹出横向节点，可以提现付费，如果提前付费购买弹出的小时，费用比后付费的便宜多少，比如便宜30%。

提高客户的预付费的数量，为我们云资源提前得到资金。

当然这些都是我个人的想法，云厂商里面的各位大能人，想法一定会更加的出彩。

以上就是本次，我们企业对弹性的一点小的需求。

7 PolarDB 弹升的单位与如何进行弹升？

这个问题看似很简单，实际上可不是，我一个问题就能问蒙，看到此篇的你，请问PolarDB 现在需要弹升，但是我们的需求或者压力是瞬间就来的，请问POlarDB是瞬间就可以将PCU瞬间弹升到指定的弹升个数。

这里要回答的是，NO NO NO ，PolarDB的弹升是按照弹升单位弹升的，PolarDB的弹升单位是0.5 PCU，他升也不是瞬间就弹升多少个PCU ，弹升是根据系统压力进行弹升。

弹升是线性的，比如探测10秒中发现了系统的压力较大，那么会在决策时间内，启动执行。 整体的弹升是 探测时间+决策时间+执行时间。弹升是线性的，比如我们先弹 0.5PCU 发现不行系统的负载没有降下来，那么就继续弹升2个，如果还不行就在弹4个PCU ，直到弹升后系统负载下降，或者弹升到极限值后停止弹升。每次弹升的单元我们称之为步长。

写到这里，其实弹升还有很多有意思的地方，包含，监控，弹升回缩，纯serverless的主机等等，我们不行就下期继续给大家讲弹性的知识。

图片