评测｜PolarDB MySQL 版 Serverless

评测｜PolarDB MySQL 版 Serverless

目录

一、测试背景

1.1、云原生数据库 PolarDB Serverless新架构概念

1.2、Serverless资源弹性扩缩触发条件

1.3、数据库的基准测试、压力测试

1.3.1、数据库的基准测试：

1.3.2、数据库的压力测试：

1.3.3、基准测试和压力测试区别

1.4、Sysbench工具命令解释

二、PolarDB的Serverless能力与同类型产品进行对比

三、动态弹性升降资源的能力测试

3.1、测试资源

3.2、测试一、主节点Serverless弹性压测

3.2.1、设置Serverless弹性策略

3.2.2、主节点Serverless弹性压测

（1）、初始化相关数据

（2）、256并发读写混合压测

（３）、Serverless性能监控指标

3.2.3、测试结论

3.3、测试二、只读节点Serverless弹性压测

3.3.1、设置Serverless弹性策略

3.3.2、读写混合压测

（1）、初始化相关数据

（2）、读写混合压测

（３）、性能监控

3.3.3、测试结论

3.4、测试三、只读节点Serverless并发压测

3.4.1、设置Serverless弹性策略如测试3.3

3.4.2、只读并发压测

（一）自动扩容能力测试

（二）自动缩容能力测试

（三）性能监控

3.4.3、测试结论

3.5、测试四、全局一致性（SCC）测试

 3.5.1、设置Serverless弹性策略

 3.5.2、全局一致性（SCC）测试

 3.5.3、测试结论

四、异常反馈

4.1、数据库节点异常

4.2、只读节点异常

五、测试总结

---

一、测试背景

1.1、云原生数据库 PolarDB Serverless新架构概念

云原生数据库 PolarDB：

　　云原生数据库 PolarDB 是阿里云自研产品，在存储计算分离架构下，利用了软硬件结合的优势，为用户提供秒级弹性、高性能、海量存储、安全可靠的数据库服务。100%兼容MySQL和PostgreSQL生态，支持分布式扩展，高度兼容Oracle语法。产品具有多主多写、多活容灾、HTAP 等特性，交易性能最高可达开源数据库的6倍，分析性能最高可达开源数据库的400倍，TCO 低于自建数据库50%。

　　数据库是现代企业IT系统中非常重要的一部分。在创建数据库时，客户往往需要比较保守地去配置数据库集群的资源，包括CPU、内存、存储以及连接数等多种参数配置，以确保业务能够在波峰和波谷都能平稳运行。在这种情况下，客户购买的集群资源在业务波谷时期会被闲置，导致整体成本偏高；而在业务压力增长阶段，集群资源又应对不足。

　　第一代云原生数据库无法实现计算和内存资源解耦，导致目前云原生数据库价格依然高于RDS和自建数据库，这也是其无法占据大部分市场的核心原因。

　　随着PolarDB Serverless新架构的率先提出，原生数据库的困境出现极大改变。

PolarDB Serverless的最大创新之处在于：

　　▶ 在业内首次实现了内存与计算/存储的解耦，内存进一步池化，形成三层池化，使得弹性能力有数量级的提升。

　　▶ 内存池化大幅度降低了成本，实现了完全地按量使用和按需弹性，贴合各种场景。

Serverless集群的技术架构图

　　PolarDB Serverless构建了一个全新的数据库形态，即DCaaDB（Datacenter as a Database）。整个IDC形成一个多租户的大数据库，其全部的CPU、内存和存储构成三个独立的资源池。在资源池未耗尽的情况下，任何一个用户（租户）都可以任意的弹性扩展任何一种资源到任何一个规格，用户为其SQL动态消耗的CPU、内存和存储买单，不需要预置任何的规格。

　　这种情况下，CPU和内存资源因其池化其使用率将会大幅度提升，云原生数据的成本将会远低于自建和RDS等一体化数据库，云原生技术的价值将会得到充分的体现

　　Serverless数据库能够使得数据库集群资源随客户业务负载动态弹性扩缩，将客户从复杂的业务资源评估和运维工作中解放出来。

1.2、Serverless资源弹性扩缩触发条件

纵向扩缩：指节点的性能（CPU和内存的规格）发生变化。
横向扩缩：指只读节点的数量发生变化。

资源弹性扩展触发条件

纵向扩展触发条件:

　　PolarDB主要监控主节点和只读节点的CPU使用率、内存使用率和其他内核层面指标。

　　在监控周期内，出现如下三种情况中的任意一种时，通常会触发Serverless资源纵向扩展：

　　▶ 当单节点的CPU使用率高于80%，会触发本节点资源扩展。

　　▶ 当单节点的内存使用率高于90%，会触发本节点资源扩展。

　　▶ 当只读节点的规格小于主节点规格的一半时，会触发只读节点资源扩展。例如，当只读节点的规格是4 PCU，主节点的规格是10 PCU时，会触发只读节点资源扩展到不小于5 PCU的规格。

横向扩展触发条件:

　　当只读节点已经纵向扩展到设定上限，集群中现有的只读节点的CPU使用率或内存使用率仍然满足纵向扩展的条件（CPU使用率高于80%或内存使用率高于90%），则会触发只读节点的横向扩展。

资源弹性收缩触发条件：

　　当单节点的CPU使用率低于50%且内存使用率低于80%时，会触发本节点资源收缩。

说明：
　　以上条件适用于Serverless集群和普通集群的Serverless功能。
　　以上阈值指标是默认值，在不同集群内核参数以及不同Serverless配置策略下，会有所调整。

1.3、数据库的基准测试、压力测试

1.3.1、数据库的基准测试：

　　数据库的基准测试是一种评估和比较数据库性能的方法。它通过模拟真实的工作负载和压力，对数据库系统的各种性能参数进行测试，如并发处理能力、响应时间、吞吐量、稳定性、可靠性、可扩展性等，进而识别数据库性能的瓶颈和优化方案。基准测试是数据库系统开发、优化和选型的重要工具之一，它可以帮助用户选择适合自己需求的数据库产品，并找到最佳的配置和参数设置，从而提高系统性能和可靠性。常见的数据库基准测试工具包括TPC、BenchmarkSQL、HammerDB等。

1.3.2、数据库的压力测试：

　　数据库的压力测试是一种测试数据库系统的性能和可靠性的方法。这种测试方法主要是在极限条件下使用模拟的负载来模拟真实的数据库使用情况，以评估数据库系统处理大量请求时的性能和稳定性。

数据库的压力测试主要包括以下步骤：

1. 设计测试用例：根据实际的业务需求设计不同的测试用例。
2. 准备测试数据：准备相应负载所需的测试数据。
3. 配置测试环境：配置数据库服务器和相关的软件及硬件设备，以保证测试环境的稳定性和可靠性。
4. 进行测试：在模拟负载的情况下，进行数据库测试，并记录测试结果。
5. 分析测试结果：通过分析测试结果，了解数据库在不同的负载情况下的性能和可靠性。
6. 优化数据库系统：根据测试结果，对数据库系统进行相应的优化，以提高数据库的性能和稳定性。

　　数据库的压力测试可以帮助企业评估数据库系统的性能和可靠性，避免出现在高峰期无法处理海量请求的情况。

1.3.3、基准测试和压力测试区别

基准测试和压力测试是软件测试中的两种不同类型。

　　基准测试是一种测量性能的方法，用于确定系统的性能水平。它通过测试系统在特定负载条件下的响应时间、吞吐量、CPU使用率、内存使用率等指标来验证系统的性能水平，并与先前的测试结果进行比较。基准测试通常用于评估不同系统之间的性能差异、标识系统瓶颈并测量系统优化的成果。

　　压力测试是一种测试方法，用于确定系统在超出其正常负载范围的条件下的性能表现。它模拟高负载条件下的并发用户或请求，并测试系统的响应时间、吞吐量、资源利用率和系统稳定性等指标。压力测试有助于发现系统的弱点，帮助开发人员解决性能问题，并评估系统的承载能力。

　　总的来说，基准测试和压力测试都是测试系统性能的方法，但是它们的侧重点不同。基准测试旨在确定系统的性能水平，而压力测试则专注于测试系统在超负荷条件下的表现。

1.4、Sysbench工具命令解释

　　sysbench是跨平台的基准测试工具，支持多线程，支持多种数据库；

　　主要包括以下几种测试：

• cpu性能
• 磁盘io性能
• 调度程序性能
• 内存分配及传输速度
• POSIX线程性能
• 数据库性能(OLTP基准测试)

sysbench的基本语法：

sysbench [options]... [testname] [command]

常用的参数和命令。

（1）command
　　command是sysbench要执行的命令，包括prepare、run和cleanup，顾名思义，prepare是为测试提前准备数据，run是执行正式的测试，cleanup是在测试完成后对数据库进行清理。

（2）testname
　　testname指定了要进行的测试，在老版本的sysbench中，可以通过--test参数指定测试的脚本；而在新版本中，--test参数已经声明为废弃，可以不使用--test，而是直接指定脚本。

sysbench --test=./tests/include/oltp_legacy/oltp.lua
sysbench ./tests/include/oltp_legacy/oltp.lua

　　测试时使用的脚本为lua脚本，可以使用sysbench自带脚本，也可以自己开发。对于大多数应用，使用sysbench自带的脚本就足够了。不同版本的sysbench中，lua脚本的位置可能不同，可以自己在sysbench路径下使用find命令搜索oltp.lua。

（3）options
sysbench的参数有很多，常用的包括：

MySQL连接信息参数

• --mysql-host：MySQL服务器主机名，默认localhost；如果在本机上使用localhost报错，提示无法连接MySQL服务器，可以改成本机的IP地址。本测试中，mysql-host为指定的PolarDB实例的集群私网地址。
• --mysql-port：MySQL服务器端口，默认3306
• --mysql-user：用户名，即指定连接MySQL服务器所使用的用户名。
• --mysql-password：密码，即指定连接MySQL服务器所使用的用户名相应的密码。
• --mysql-db：指定在MySQL服务器上使用的数据库名称。

MySQL执行参数

• --oltp-test-mode：执行模式，包括simple、nontrx和complex，默认是complex。simple模式下只测试简单的查询；nontrx不仅测试查询，还测试插入更新等，但是不使用事务；complex模式下测试最全面，会测试增删改查，而且会使用事务。
• --oltp-tables-count：测试的表数量，根据实际情况选择
• --prepare：指定执行预备阶段，将在测试之前创建和填充表。
• --db-ps-mode：指定数据库预处理状态，此处为禁用。
• --tables：指定在测试期间创建的表的数量。
• --table-size：指定每个表的行数。
• --oltp-table-size：测试的表的大小，根据实际情况选择
• --threads：客户端的并发连接数，即指定并发线程数，即同时执行的任务数量。
• --time：测试执行的时间，即指定测试运行的总时间。单位是秒，该值不要太短。
• --report-interval：生成报告的时间间隔，单位是秒。
• --range_selects：指定是否进行范围查询操作。
• --rand-type：指定生成随机数的方式，这里使用均匀分布。

二、PolarDB的Serverless能力与同类型产品进行对比

　　在业务波动较大的场景下，普通集群和Serverless集群资源使用和规格变化情况如下图：

　　由上图可以看到，在业务波动较大的场景下：

普通集群：

　　在波谷期浪费的资源较多，在高峰期资源不足，业务受损。

Serverless集群：

　　由于其规格随业务需求量随时调整，总体浪费的资源很少，提升了资源利用率，降低了资源使用量。在高峰期也能完全满足业务需求，保证业务不受损，提高了系统的稳定性。打破固定资源付费模式，做到了负载与资源动态匹配的按量付费模式，可节省大量成本。无需手动变配，提高了运维效率，提升了运维管理人员和研发人员的幸福感。具备弹性扩缩能力，适合业务数据量大、并具有典型的业务访问波峰波谷场景。

三、动态弹性升降资源的能力测试

3.1、测试资源

3.1.1、场景资源信息⬇️

• 云服务器ECS

　　云服务器（Elastic Compute Service，简称ECS）是阿里云提供的性能卓越、稳定可靠、弹性扩展的IaaS（Infrastructure as a Service）级别云计算服务。一台云服务器ECS实例等同于一台虚拟服务器，内含CPU、内存、操作系统、网络配置、磁盘等基础的组件。

　　ECS实例ID：i-uf6c2imr50uapz33734j

　　CPU&内存：16核(vCPU)64 GiB
　　操作系统：Alibaba Cloud Linux 2.1903 LTS 64位
　　当前使用带宽：5Mbps （峰值）

• 云原生关系型数据库PolarDB

　　云原生关系型数据库PolarDB是阿里巴巴自主研发的下一代云原生关系型数据库，100%兼容MySQL、PostgreSQL、高度兼容Oracle语法。 计算能力最高可扩展至1000核以上，存储容量最高可达 100TB。

数据库1名称：mytest
数据库2名称：sct
数据库3名称：sbtest
数据库账号名称：test_user
数据库登录密码：Password123
PolarDB实例ID：pc-uf6x937e5n0fw6138、pc-uf68j17rqld9xwh9d
PolarDB集群私网地址：
pc-uf6x937e5n0fw6138.rwlb.rds.aliyuncs.com
pc-uf68j17rqld9xwh9d.rwlb.rds.aliyuncs.com

3.1.2、测试工具⬇️：

• Sysbench工具

　　Sysbench是一款开源的多线程性能测试工具，可以执行数据库只读、只写、读写混合等类型的性能测试。

• SCC（Strict Consistency Cluster）服务

　　严格一致性集群SCC（Strict Consistency Cluster）服务。SCC功能为PolarDB for MySQL Serverless提供了跨节点无损读扩展的能力。PolarTrans事务系统利用提交时间戳技术CTS和RDMA网络，在内核层面提供集群强一致性读SCC服务，在不损失性能的基础上，保证发往集群任意副本的读请求都可以获得强一致性的结果。

3.2、测试一、主节点Serverless弹性压测

3.2.1、设置Serverless弹性策略

• 单节点资源弹性上限为：32 PCU。
• 单节点资源弹性下限为：1 PCU。
• 只读节点个数扩展上限：0。
• 只读节点个数扩展下限：0。
• 是否开启无活动暂停：关闭。
• 定时执行：立即执行

3.2.2、主节点Serverless弹性压测

　　本测试模拟客户端对PolarDB发起写请求，验证主节点的Serverless智能弹性能力。通过Sysbench脚本访问集群地址进行压测，PolarDB主节点的规格能够根据负载进行自动伸缩与自动配置，达到Serverless的能力。

　　本样例使用读写混合的压测类型（oltp_read_write），并发数为32线程。

（1）、初始化相关数据

切换至Web Terminal。

执行如下命令，初始化相关数据。

sysbench /usr/share/sysbench/oltp_read_write.lua
 --mysql-host=pc-uf6x937e5n0fw6138.rwlb.rds.aliyuncs.com
 --mysql-port=3306
 --mysql-user=test_user
 --mysql-password=Password123
 --mysql-db=sbtest
 --tables=128
 --table-size=1000000
 --report-interval=1
 --range_selects=1
 --db-ps-mode=disable
 --rand-type=uniform
 --threads=256
 --time=12000
 prepare

运行结果： 

　　由于初始化数据的负载也会造成Serverless弹升，初始化执行完毕后等待2-3min，在规格下降到初始状态（1PCU）后，再执行下面的正式的压测命令。

（2）、256并发读写混合压测

　　执行如下命令，开始进行256并发读写混合压测。

sysbench /usr/share/sysbench/oltp_read_write.lua
 --mysql-host=pc-uf6x937e5n0fw6138.rwlb.rds.aliyuncs.com
 --mysql-port=3306
 --mysql-user=test_user
 --mysql-password=Password123
 --mysql-db=sbtest
 --tables=128
 --table-size=1000000
 --report-interval=1
 --range_selects=1
 --db-ps-mode=disable
 --rand-type=uniform
 --threads=256
 --time=12000
 run

输出结果：

　　根据Sysbench输出返回结果可以直接观察到，

　　随着时间的推移，在同样的并发数下，tps逐渐上升，延迟（lat）逐渐下降，最终到达一个稳定值，这说明PolarDB的处理能力借助Serverless弹性获得提升。

（３）、Serverless性能监控指标

　　在计算节点页签，查看主节点负载情况。

　　可以看到随着主节点PCU CPU使用率的不断提升，PCU数量从

　　状态（1）2023-11-23 19:17:17 PCU=1，

　　迅速上升至

　　状态（2）2023-11-23 19:17:53 PCU=32，

　　（本次测试用时为36秒）

　　不到1分钟内从1 PCU弹升到最大上限32 PCU。

　　压测持续一段时间后，切换至Web Terminal中执行Ctrl+C，停止压测脚本。

　　切换至性能监控，

　　可以观察到，当压测请求完全停止后，主节点PCU CPU使用率会立即下降，而PCU数量随后也会逐步自动缩小至1 PCU。

3.2.3、测试结论

　　通过Sysbench脚本访问集群地址，模拟客户端对PolarDB发起写请求，进行压测，PolarDB主节点的Serverless能够根据负载进行自动伸缩与自动配置，具有智能弹性能力。PolarDB的处理能力借助Serverless弹性获得提升。

　　资源弹升速度快，不到1分钟时间内（本次测试用时为36秒）从1 PCU弹升到最大上限32 PCU，1秒内完成弹升。

3.3、测试二、只读节点Serverless弹性压测

　　只读节点Serverless弹性压测

　　本测试模拟客户端对PolarDB发起读请求，验证只读节点的Serverless智能弹性能力。PolarDB for MySQL Serverless集群除了支持主节点自动弹性伸缩之外，还支持创建只读节点分摊主节点的读请求。当使用集群地址时，PolarDB for MySQL Serverless可以基于读负载的比例，智能地调整只读节点的个数和各自的规格，来达到最佳的Serverless能力。

　　PolarDB for MySQL Serverless集群主节点PCU扩容到弹升上限后，会自动创建新的只读节点并分摊部分主节点的读负载，最终使整个集群能够支撑更高的TPS请求量。

3.3.1、设置Serverless弹性策略

• 单节点资源弹性上限为：32 PCU。
• 单节点资源弹性下限为：1 PCU。
• 只读节点个数扩展上限：7。
• 只读节点个数扩展下限：0。
• 是否开启无活动暂停：关闭。
• 定时执行：立即执行

3.3.2、读写混合压测

（1）、初始化相关数据

　　切换至Web Terminal。

　　执行如下命令，初始化相关数据。

sysbench /usr/share/sysbench/oltp_read_write.lua
 --mysql-host=pc-uf68j17rqld9xwh9d.rwlb.rds.aliyuncs.com
 --mysql-port=3306
 --mysql-user=test_user
 --mysql-password=Password123
 --mysql-db=sbtest
 --tables=128
 --table-size=1000000
 --report-interval=1
 --range_selects=1
 --db-ps-mode=disable
 --rand-type=uniform
 --threads=256
 --time=12000
 prepare

运行结果： 

　　由于初始化数据的负载也会造成Serverless弹升，初始化执行完毕后等待2-3min，在规格下降到初始状态（1PCU）后，再执行下面的正式的压测命令。

（2）、读写混合压测

　　执行如下命令，开始进行读写混合压测。

　　切换至Web Terminal。

　　执行如下命令，通过访问PolarDB for MySQL Serverless集群私网地址发起256并发读写混合压测请求。

sysbench /usr/share/sysbench/oltp_read_write.lua
 --mysql-host=pc-uf68j17rqld9xwh9d.rwlb.rds.aliyuncs.com
 --mysql-port=3306
 --mysql-user=test_user
 --mysql-password=Password123
 --mysql-db=sbtest
 --tables=128
 --table-size=1000000
 --report-interval=1
 --range_selects=1
 --db-ps-mode=disable
 --rand-type=uniform
 --threads=256
 --time=12000
 run

 

　　从Sysbench输出可以直接观察到，随着时间的推移，在同样的并发数下，tps逐渐上升，延迟（lat）逐渐下降，最终到达一个稳定值。这说明PolarDB的处理能力借助Serverless弹性获得提升。

（３）、性能监控

　　在监控页上，可以查看到集群维度的Serverless监控指标，选择压测的时间段可以看到类似如下信息：

　　从监控可以看出，PolarDB收到读写混合请求后，主节点会首先迅速弹升到最大的32 PCU，之后监控逐步出现两个只读节点。当只读节点分摊主节点的读请求后，主节点CPU使用率逐步下降，规格最终稳定在24PCU。

　　第一个只读节点创建后，也会立刻弹升到32 PCU。此时系统会尝试继续创建只读节点，分摊读请求。第一个只读节点稳定在30PCU。第二个只读节点稳定在29PCU。

　　我们可以看到，由于目前第二个只读节点没有到最大规格32 PCU，系统判断目前Serverless规格已经满足实际负载，不会再继续增加新的只读节点。

3.3.3、测试结论

　　初始状态下，在读写混合场景下，读写流量会首先转发到集群唯一节点，即主节点（RW）中。

　　当主节点弹升到最大规格后，Serverless系统会逐个创建只读节点，分摊主节点的读请求，直到只读节点的数量满足当前负载。

　　当只读节点分摊读请求后，主节点负载会降低，触发PCU弹降，为未来支持更多写负载预留了弹升空间。

3.4、测试三、只读节点Serverless并发压测

3.4.1、设置Serverless弹性策略如测试3.3

3.4.2、只读并发压测

（一）自动扩容能力测试

　　切换至Web Terminal。

　　打开一个新的Terminal（第一个测试3.3Terminal中的压测命令先不要停止）。

　　在新的Terminal中执行如下命令，通过访问PolarDB for MySQL Serverless 集群地址发起256并发的只读请求。

sysbench /usr/share/sysbench/oltp_read_write.lua
 --mysql-host=pc-uf68j17rqld9xwh9d.rwlb.rds.aliyuncs.com
 --mysql-port=3306
 --mysql-user=test_user
 --mysql-password=Password123
 --mysql-db=sbtest
 --tables=128
 --table-size=1000000
 --report-interval=1
 --range_selects=1
 --db-ps-mode=disable
 --rand-type=uniform
 --threads=256
 --time=12000
 run

　　当数据库接收到新的只读负载后，首先当前的2个只读节点会弹升到最大规格32 PCU，之后Serverless系统会继续创建新的只读节点，直到满足新增只读负载的要求。

选择性能监控。

　　在监控页上，可以查看集群维度的Serverless监控指标，选择只读请求的压测时间段，查看Serverless的状态：

（二）自动缩容能力测试

　　切换至Web Terminal。

　　执行Ctrl+C停止所有的Sysbench脚本（包括oltp_read_write和oltp_read_only）。

（三）性能监控

　　在监控页上可以看到PolarDB for MySQL Serverless的计算节点首先会自动缩容（预计耗时1-2min），之后新增的只读节点会逐步回收（预计耗时15-20min）。

　　等待较长时间后，最终PolarDB会缩容到只有一个主节点的状态。

　　说明：时间比较久，预计需要15-20min。趁着只读节点还没回收，可以直接做下一个全局一致性测试。

3.4.3、测试结论

　　从上面的实验可以看出，PolarDB for MySQL Serverless的节点数量和规格都能够根据负载进行自动伸缩与自动配置。

3.5、测试四、全局一致性（SCC）测试

　　全局一致性（SCC）测试

　　高性能全局一致性SCC特性可以为PolarDB for MySQL Serverless提供跨节点无损读扩展的能力，即RO的无损强一致读。传统的Serverless的方案均是基于单机原地升降配实现，其规格受限于单物理机资源。而当RO能借助SCC提供无损强一致读后，针对大部分读多写少业务，可以跨机提供CPU资源，上限远超单物理机限制。

　　开源的mysqlsct工具用于检验数据库集群的强一致性读能力, 该工具通过跨session的写入+读取+结果对比的方式来测试数据库集群强一致性读的功能和性能。

　　本测试使用mysqlsct工具验证的无损强一致读的特性。在Serverless默认开启SCC的状态下，PolarDB通过RO实现读扩展，且不会读到不一致的数据。在关闭SCC后，同样测试条件下，使用RO分摊读请求则无法满足强一致。

　　为了更方便地测试RO一致性读，先调整Serverless配置，确保测试过程中，至少保留一个只读节点。

 3.5.1、设置Serverless弹性策略

• 单节点资源弹性上限为：32 PCU。
• 单节点资源弹性下限为：1 PCU。
• 只读节点个数扩展上限：7。
• 只读节点个数扩展下限：1。
• 是否开启无活动暂停：关闭。
• 定时执行：立即执行

　　设置参数后，实例状态为配置切换中，切换预计需要1-2min，请等待实例状态变成运行中后再执行后面的操作。

 3.5.2、全局一致性（SCC）测试

　　切换至Web Terminal。

　　执行如下mysqlsct测试命令。

/root/mysqlsct --host-rw=pc-uf68z4el2op35ozy1.rwlb.rds.aliyuncs.com
 --host-ro=pc-uf68z4el2op35ozy1.rwlb.rds.aliyuncs.com
 --port-rw=3306
 --port-ro=3306
 --user=test_user
  --password=Password123
 --iterations=100000
 --table-cnt=1
 --table-size=1000 -f=0
 --concurrency=1
 --database=sct
 --sc-gap-us=0
 --report-interval=2
 --test-mode=sct

执行后，可以看到一致性检查全部通过，输出的信息类似如下截图：

　　选择参数配置。

　　单击页面左上角的修改参数按钮，修改loose_innodb_polar_scc参数为OFF，单击提交修改，单击确定，关闭SCC特性。

　　切换至Web Terminal。

　　重新执行mysqlsct测试命令。

/root/mysqlsct --host-rw=pc-uf68z4el2op35ozy1.rwlb.rds.aliyuncs.com
 --host-ro=pc-uf68z4el2op35ozy1.rwlb.rds.aliyuncs.com
 --port-rw=3306
 --port-ro=3306
 --user=test_user
 --password=Password123
 --iterations=100000
 --table-cnt=1
 --table-size=1000 -f=0
 --concurrency=1
 --database=sct
 --sc-gap-us=0
 --report-interval=2
 --test-mode=sct

　　执行后，可以看到一致性检查出现失败，输出的信息类似如下截图：

 3.5.3、测试结论

　　从上面的实验可以看出，PolarDB for MySQL Serverless借助高性能全局一致性SCC特性，提供了跨节点无损读扩展的能力。

四、异常反馈

4.1、数据库节点异常

　　正常情况下，当主节点升至32 PCU时，此时系统会尝试继续创建只读节点，分摊读请求。而只读节点到最大规格32 PCU时，系统判断目前Serverless规格超出实际负载，会继续增加新的只读节点。

　　但测试过程中，碰到过几次不断增加并发压测，但数据库节点不增加只读节点的情况。此时在性能监控显示页里也没有增加只读节点。等了很久时间也没有增加只读节点，数据显示也不正常。

4.2、只读节点异常

　　出现了只读节点PCU数量为0的异常情况。不断增加并发压测，但有一个只读节点PCU数量始终为0不变化。

五、测试总结

　　在PolarDB Serverless架构下，我对数据库性能进行了测试。 纵向扩缩：指节点的性能（CPU和内存的规格）发生变化。横向扩缩：指只读节点的数量发生变化。

　　通过Sysbench脚本访问集群地址，模拟客户端对PolarDB发起写请求，进行压测，PolarDB主节点的Serverless能够根据负载进行自动伸缩与自动配置，具有智能弹性能力。PolarDB的处理能力借助Serverless弹性获得提升。

　　资源弹升速度快，不到1分钟时间内（本次测试用时为36秒）从1 PCU弹升到最大上限32 PCU，1秒内完成弹升。

　　初始状态下，在读写混合场景下，读写流量会首先转发到集群唯一节点，即主节点（RW）中。当主节点弹升到最大规格后，Serverless系统会逐个创建只读节点，分摊主节点的读请求，直到只读节点的数量满足当前负载。PolarDB收到读写混合请求后，主节点会首先迅速弹升到最大的32 PCU，之后监控逐步出现两个只读节点。当只读节点分摊主节点的读请求后，主节点CPU使用率逐步下降，规格最终稳定在24PCU。

　　第一个只读节点创建后，也会立刻弹升到32 PCU。此时系统会尝试继续创建只读节点，分摊读请求。第一个只读节点稳定在30PCU。第二个只读节点稳定在29PCU。由于目前第二个只读节点没有到最大规格32 PCU，系统判断目前Serverless规格已经满足实际负载，不会再继续增加新的只读节点。当只读节点分摊读请求后，主节点负载会降低，触发PCU弹降，为未来支持更多写负载预留了弹升空间。

　　只读节点Serverless并发压测中，当数据库接收到新的只读负载后，首先当前的2个只读节点会弹升到最大规格32 PCU，之后Serverless系统会继续创建新的只读节点，直到满足新增只读负载的要求。当负载减少后，PolarDB for MySQL Serverless的计算节点首先会自动缩容（预计耗时1-2min），之后新增的只读节点会逐步回收。最终PolarDB会缩容到只有一个主节点的状态。

　　从上面的实验可以看出，PolarDB for MySQL Serverless的节点数量和规格都能够根据负载进行自动伸缩与自动配置。

　　全局一致性（SCC）测试中，PolarDB for MySQL Serverless借助高性能全局一致性SCC特性，提供了跨节点无损读扩展的能力。

　　由此，可以得出以下结论：

1. 资源弹升速度：PolarDB可支持5秒探测窗口，1秒内完成弹升。资源弹升速度快，不到1分钟时间内（本次测试用时为36秒）从1 PCU弹升到最大上限32 PCU。

2. 资源伸缩广度：PolarDB支持自动纵向扩展（0~32核）和横向扩展（0~8个节点），支持0~256核范围内伸缩。

3. 资源伸缩的稳定性：PolarDB支持对业务无感的纵向扩缩容与横向扩展

4. 资源伸缩的颗粒度：PolarDB支持最小0.5PCU颗粒度的资源伸缩

5. 可支持自动启停：PolarDB可支持在没有访问需求时，计算资源可缩为0。当有访问需求时，10秒即可唤醒资源。

6. 全局数据的强一致性：PolarDB可支持所有只读节点的数据强一致性，并且性能不下降。

　　云原生数据库 PolarDB MySQL版Serverless能够根据业务负载，对集群资源进行秒级动态弹降，具有动态弹性升降资源的能力，通过多节点架构保障集群的高可用，自动弹升范围广，单集群支持无感伸缩，可实现秒级弹升，能够从容应对业务负载突增，全程对业务无影响。PolarDB MySQL版Serverless支持自动启停能力。当没有连接时，集群自动暂停，释放计算成本；当请求到来时，集群自动无感启动。

　　总体来说，PolarDB MySQL版 Serverless是一种高性能、高可用、高弹性的数据库服务，适用于许多中小型企业的数据库应用场景。

问题和思考：

1、基于云的服务，依赖于网络，网络出现问题会影响服务的效率和稳定性。

2、目前PolarDB MySQL版 Serverless支持从0核~32核的范围内纵向扩展，指节点的性能（CPU和内存的规格）发生变化。以及从0~8个只读节点的范围内的横向扩展变化。对于需要极高的并发读写能力和可扩展性的应用来说，PolarDB MySQL版 Serverless可能无法满足需求。能否按需要定制？
3、 冷启动延迟：由于Serverless数据库实例的资源是动态分配的，当您启动一个新的数据库实例时，它可能需要一些时间来分配资源并准备好服务请求，这可能会导致一些问题。
4、成本不透明：由于Serverless数据库实例的资源是动态分配的，因此难以预测成本。您可能很难确定一个特定的负载量会花费多少钱，因为它取决于实例使用的资源数量和使用时间。
5、目前只有PolarDB MySQL版 Serverless，有没有其他数据库的版本？
6、实验过程中出现了数据库节点异常和只读节点异常的情况，原因我不清楚。有没有相应的监控和报警功能？

 

             推荐阅读：