关于云原生:云原生数据库极致弹性体验-Amazon-Aurora-Serverless-v2

Aurora Serverless 是 Amazon Aurora 的按需主动扩大配置。Aurora Serverless v2 在几分之一秒内将数据库工作负载扩大到数十万个事务。它以细粒度的增量调整容量，为应用程序的需要提供适量的数据库资源。您无需治理数据库容量，只需为应用程序耗费的资源付费。早在 2018 年 Amazon Aurora 即提供了 Serverless 选项。

Amazon Aurora 最新提供的 Aurora Serverless V2 版本相比于上一代 V1 版本更上一层楼，重点晋升局部：资源容量采纳原地扩大，使资源容量扩大速度由 V1 分钟级晋升到秒级，v2 版本可能在容量调整时做到更细粒度, 以 0.5 ACU 作为扩大单元（V1 翻倍扩大），并可能根据多个维度进行容量调整，通过继续的监控和尽可能大的利用缓冲池。Aurora Serverless v2 相比 V1 减少了残缺的 Amazon Aurora 性能，包含多可用区反对、只读正本和寰球数据库等，反对跨 AZ 和跨区域的高可用部署和读取扩大。

Amazon Aurora Serverless v2 非常适合各种应用程序。例如，面对业务快速增长场景与海量多租户场景时，当领有数十万个应用程序的企业，或领有具备成千盈百个数据库的多租户环境的软件即服务 (SaaS) 供应商，能够应用 Amazon Aurora Serverless v2 来治理整个 SaaS 利用中泛滥数据库的容量，同时还实用于业务吞吐量稳定显著的场景，如游戏业务、电商业务、测试环境等，以及无奈预估吞吐量的新业务零碎。对于大部分工夫都处于低谷的业务零碎，Amazon Aurora Serverless v2 能够无效地为客户节省成本。

作为新一代云原生无服务数据库，Aurora Serverless V2 提供了无可比拟弹性伸缩性，动如脱兔；同时也提供了面向企业级利用的坚不可摧的高可用性，静若磐石。

本博客重点会围绕着 Aurora Serverless V2 的弹性伸缩和高可用个性，开展测试和剖析，进一步向您展现 Aurora Serverless V2 的特点。

Aurora Serverless V2 随负载变动的弹性伸缩能力
Aurora Serverless V2 与 V1 弹性伸缩能力比拟

Aurora Serverless 资源扩大以 ACU 为单位，对于 ACU 定义：

Aurora Capacity Unit (ACU) 用于测量 Aurora Serverless 所分配资源容量
1 个 ACU 有 2 GiB 的内存，同时具备相应的 CPU 和网络等资源，CPU、网络和内存的配比与预置 Aurora 实例雷同
Aurora Serverless V2 启动容量能够最低设置成 0.5 ACU（1 GiB 内存），最高 ACU 反对设置为 128

模仿负载波峰波谷，采纳 sysbench 读写负载，基于不同线程压测 10/100/50/600/10，每轮压测 120 秒，观测在初始 20 秒 Aurora Serverless V2/V1 资源扩大状况：

测试过程中 CloudWatch Dashboard 监控指标：

观测后果： V2 CPUUtilization 与 ServerlessDabaseCapacity 曲线拟合度十分高，ACU 值随着 CPU 指标变动而变动，特地是负载回升期间 CPU 回升 ACU 可达到霎时回升；CPU 下降时 ACU 值绝对安稳降落

V1 ServerlessDabaseCapacity 扩大绝对于 CPUUtilization 扩大有肯定的提早和滞后

V2/V1 总体性能比拟：

因为 Aurora Serverless V2 零碎扩大更麻利负载回升 V2 始终取得比 V1 更高的资源配置（ACU）因此 Aurora Serverless V2 相比 V1 在不同压测场景性能晋升 1.5-3 倍 (TPS & QPS) 同时 V2 采纳 MySQL 8.0 V1 采纳 MySQL 5.7 版本不同性能体现也会有所差别

扩大速度测试：

将 V2 Min ACU 设置成 8 ACU 和 4 ACU 查看 ACU 扩大速度是否有晋升测试负载 sysbench 读写线程数采纳恒定值 100 运行 15 分钟

测试察看：

ACU 扩大速度与 Min ACU 或者以后数据库的 ACU 值相干 ACU 值越大扩大速度越快

Aurora Serverless V2 采纳即时原地扩大随负载变动可实现麻利扩大实现秒级 ACU 扩大
实现细颗粒度资源扩大以 0.5ACU 为扩大单元
Aurora Serverless V2 ACU 资源扩大同时，其它相应资源，例如数据库引擎缓存池 innodb_buffer_pool 也实现动静扩大
ACU 扩大速度与 min ACU 或者以后数据库的 ACU 值相干 ACU 值越大扩大速度越快
Aurora Serverless V2 资源扩大速度麻利回缩绝对安稳以保障系统负载安稳撑持
Aurora Serverless V2 vs V1
体性能晋升 5 - 3 倍
资源扩大速度晋升 10-15 倍
扩大单元更细粒度
在高并发场景可安稳运行

Aurora Serverless V2 减少了读正本性能能够通过减少读正本最多可创立 15 个读正本实现跨 AZ 容灾以及读负载扩大；Aurora Serverless V2 的高 failover 优先级读正本（Tier 0/1）ACU 会随着主节点 ACU 伸缩从而保障在主从负载故障切换后疾速承载主节点负载；Aurora Serverless V2 低 failover 优先级读正本（Tier 2-15）ACU 不会随着主节点 ACU 伸缩会根据本身实例负载实现资源 ACU 伸缩

Aurora Serverless V2 tier 0/1 读正本是否会随着主节点 ACU 扩大而扩大
Aurora Serverless V2 tier 2-15 读正本负载是否会独立主节点而扩大
Aurora Serverless V2 主从节点切换工夫

创立一主两从 Aurora Serverless V2 集群读正本 failover 级别别离为 Tier 0 和 Tier 15（Min ACU:4;Max ACU:32）:

Aurora Serverless V2 通过读正本可实现跨 AZ 高可用性主从切换工夫在秒级
Aurora Serverless V2 通过读正本实现读负载的程度扩大
Tier 0/1 读正本的 ACU 也在随着主节点的 ACU 的变动一直变动两者 ACU 值基本一致可保障主从切换后资源短缺供给
Tier 2-15 读正本读正本的 ACU 会独立变动，不会随着主节点的 ACU 的变动而变动

Aurora Serverless V2 减少了全局数据库性能能够通过减少全局数据库实现跨区域容灾以及就近本地读拜访；寰球数据库采纳物理复制形式以及通过亚马逊云科技跨区域主干网高效传输数据使得跨区域数据复制提早低小于 1 秒；容灾产生时能够在分钟级将从集群晋升为主集群；一个主集群可建最多达五个从集群主从集群总共能够创立多达 90 个读正本

Aurora Serverless V2 寰球数据库：主集群上运行读写负载在从集群上运行只读负载观测主从集群 ACU 变动
Aurora Serverless V2 寰球数据库：在主集群上运行高并发只写负载在从集群上观测主从集群复制提早
Aurora Serverless V2 寰球数据库：执行 Managed Planned Failover 操作观测 Failover 所须要工夫

主集群（4 ACU-32 ACU）在美东 1
从集群（4 ACU – 32 ACU）在美西 2

Aurora Serverless V2 通过寰球数据库可实现跨 Region 高可用性主从切换工夫在分钟级
Aurora Serverless V2 通过寰球数据库实现跨区域容灾和就近数据拜访
从集群的 ACU 会随着本身负载变动而独立变动，不会随着主集群的 ACU 的变动而变动
主从集群复制提早比拟低通常放弃在 200 毫秒左右

抉择 Aurora Serverless V2 有泛滥好处，以下从四个方面概括论述抉择 Aurora Serverless V2 的理由：

高度可扩大

翻新的云原生无服务数据库，实现数据库的弹性伸缩，进一步简化客户创立、保护和扩大数据库，实现高度扩展性及主动伸缩容量。

Amazon Aurora Serverless v2 采纳即时原地扩大技术，在扩展性方面比上一代更上一层楼，能够立刻扩大以反对最刻薄的应用程序，霎时扩大不到一秒工夫，即可将数据库工作负载由反对几百个事务扩大至反对数十万个事务。

提供面向企业级利用高可用性

Aurora Serverless V2 提供所有的 Aurora 性能，包含回溯、克隆、寰球数据库、多可用区部署以及只读正本等，满足业务要害型应用程序的需要，能够通过创立只读正本实现跨多可用区高可用性，实现秒级跨可用区故障切换；能够通过创立寰球数据库实现跨区域高可用性，实现分钟级跨区域故障切换，可提供面向企业级利用高可用性。

易治理

Aurora Serverless V2 可按需主动扩大，依据应用程序的需要主动扩大或缩减容量，简化客户创立、保护和扩大数据库，不再须要进行简单的数据库容量预置和治理，数据库会依据应用程序的需要主动扩大资源。

经济高效

Aurora Serverless V2 能够以细粒度的 0.5 ACU 增量资源扩大，确保恰好提供利用所需的数据库资源量，并且仅为应用的容量付费，同时 Aurora Serverless V2 可按秒计费，实现更细粒度计费模式。

版本要求：

Aurora Serverless V2 MySQL: Aurora MySQL 3.0.2 及以上（兼容 MySQL 8.0）

Aurora Serverless V2 PostgreSQL: Aurora PostgreSQL 13.6 及以上

迁徙：

迁徙场景 1: 将预置模式 Aurora 集群迁徙到 Aurora Serverless V2

Aurora Serverless V2 反对集群里采纳灵便的混合配置架构 ，即主节点能够是预置模式实例，读节点是 Aurora Serverless V2 实例；同时也反对主节点是 Aurora Serverless V2 实例，读节点是 Aurora 预置模式实例

迁徙办法：创立 Aurora Serverless V2 混合配置架构通过主从切换将预置模式主节点实例转换成 Aurora Serverless V2 实例：

将 Aurora 预置模式主节点降级到 Aurora Serverless V2 所需版本
在集群级别设置 Min ACU 和 Max ACU
减少实例类型为 Serverless 读正本 (Failover 级别：Tier 0/1)
执行主从切换: Provisioned Writer 变成 Provisioned Reader; Serverless Reader 变成 Serverless Writer

迁徙场景 2: 将 Aurora Serverless V1 迁徙到 Aurora Serverless V2

迁徙办法：通过创立快照迁徙

基于 Aurora Serverless V1 创立快照
基于快照复原预置 Aurora 集群
将 Aurora 预置模式主节点降级到 Aurora Serverless V2 所需版本
在集群级别设置 Min ACU 和 Max ACU
减少实例类型为 Serverless 读正本 (Failover 级别：Tier 0/1)
执行主从切换: Provisioned Writer 变成 Provisioned Reader; Serverless Reader 变成 Serverless Writer

本博客重点展现了 Aurora Serverless V2 作为新一代云原生数据库特点：高度可扩展性 - 动如脱兔，以及面向企业级利用高可用性 - 静若磐石；当云原生数据库 Aurora 深度交融无服务，必将数据库翻新做到极致！

心愿读完此博客的您，能即刻构建，享受 Aurora Serverless V2 的翻新，来构建您的面向未来的翻新的现代化利用。

创立和装置两台 EC2 测试机 :

测试区域：us-east-1

测试端：

两台 C5 4XLarge: AMI amzn2-ami-hvm (Root Device 100g)
**
装置和配置 sysbench:**

在两台 EC2 测试机上别离装置 sysbench

sudo yum -y install git gcc make automake libtool openssl-devel ncurses-compat-libs
sudo yum -y install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm
sudo yum repolist
sudo rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022
sudo yum -y install mysql-community-devel mysql-community-client mysql-community-common 
git clone https://github.com/akopytov/sysbench
cd sysbench
./autogen.sh
./configure
make
sudo make install
sysbench --version

测试环境:

测试端

之前装置 sysbench 的两台 EC2 C5 4XLarge

筹备 sysbench 数据

别离在两台 EC2 压测机筹备 sh 设置相干环境变量

host=<Aurora Serverless V2/V1 endpoint>
username=<master user name>
password=<password>
run_time=200
interval=1

执行：

source set_variables.sh

在 Aurora Serverless V2 和 V1 库上别离创立测试数据库 demo

create database demo

Sysbench 筹备数据 500 张表每张表 5 万行总共 5GB 数据

sysbench --db-driver=mysql --mysql-user=${username} --mysql-password=${password} --mysql-db=demo --mysql-host=${host} --mysql-port=3306 --tables=500 --table-size=50000 --time=${run_time} --forced-shutdown --rand-type=uniform --db-ps-mode=disable --report-interval=${interval} --threads=50 /usr/local/share/sysbench/oltp_write_only.lua prepare

查看测试表状态和数据总体测试数据 5GB

/usr/bin/mysqlcheck -u ${username} -p${password} -h ${host} -P 3306 -a -B demo

--Connect and query table sizes
/usr/bin/mysql -u ${username} -p${password} -h ${host} -P 3306

SELECT TABLE_SCHEMA, count(TABLE_NAME) AS "Table count",
 sum(DATA_LENGTH/1024/1024/1024) AS "Data size in GB" FROM INFORMATION_SCHEMA.TABLES
 WHERE TABLE_SCHEMA='demo' GROUP BY TABLE_SCHEMA;

创立 Cloudwatch Dashboard 为后续测试监控做筹备:

Name：Aurora Serverless Monitor

在 Dashboard Aurora Serverless Monitor 创立 6 个 Widgets:

别离在两台 Ec2 压测机上筹备 sysbench 压测脚本读写测试基于不同线程压测 10/100/50/600/10 不同线程规格压测 120 秒 (2 分钟) 每秒钟打印统计信息

$ cat sysbench_read_write.sh
#!/bin/bash
host= <Aurora Serverless V2/V1 endpoint>(请替换)
username=admin
password=<password>
interval=1
run_time=120
for threads in 10 100 50 600 10
do
echo "start ......................... `date`"
sysbench --db-driver=mysql --mysql-user=${username} --mysql-password=${password} --mysql-db=demo --mysql-host=${host} --mysql-port=3306 --tables=500 --table-size=50000 --time=${run_time} --forced-shutdown --rand-type=uniform --db-ps-mode=disable --report-interval=${interval} --threads=${threads} /usr/local/share/sysbench/oltp_read_write.lua run
echo "end ......................... `date`"
done

别离在两台 Ec2 压测机筹备监控脚本每秒钟监控数据库动静变量 (innodb_buffer_pool_size 和 max_connections)

$ cat stats-loop.sh
host=< Aurora Serverless V2/V1 endpoint >
username=<master user name>
export MYSQL_PWD=<password>

while true; do /usr/bin/mysql -u ${username} -h ${host} -P 3306 -e "select NOW() AS'Time',
@@max_connections AS 'Max Connections',
COUNT(host) as 'Current Connections',
round(@@innodb_buffer_pool_size/1024/1024/1024,2) AS 'Innodb Buffer Pool Size (GiB)',
COUNT AS 'InnoDB history length'
From information_schema.innodb_metrics,
information_schema.processlist
where name='trx_rseg_history_len'"; sleep 1; done

运行 aws configure 配置 id/key/region 为后续 aws cli 运行做筹备

别离在两台 Ec2 压测机筹备监控脚本每秒钟监控数据库 ACU

$ cat stats-loop-acu.sh
cluster_name="aurora-serverless-v2-demo" (请替换成你的 Aurora Serverless V2 集群名字)
export LC_ALL=Cwhile true; do
aws cloudwatch get-metric-statistics —metric-name "ServerlessDatabaseCapacity" \
--start-time "$(date -d'5 sec ago')" —end-time "$(date -d'now')" —period 1 \
--namespace "AWS/RDS" \
--statistics Average \
--dimensions Name=DBClusterIdentifier,Value=$cluster_name
sleep 1; done

别离在两台 Ec2 压测机调用 sysbench 压测脚本别离对 Aurora Serverless V2/V1 进行线程 10/100/50/600/10 压测每轮压测执行 120 秒每秒钟跟踪 Aurora Serverless V2/V1 数据库的 Innodb_buffer_pool_size 和 max_connections 大小同时每秒钟跟踪 Aurora Serverless V2/V1 数据库调配的 ACU（整体测试运行 3 次）

$ cat run_sysbench.sh
sh sysbench_read_write.sh > $1_$2_sysbench.log &
sh stats-loop.sh > $1_$2_buffer_pool.log &
sh stats-loop-acu.sh > $1_$2_acu.log &
$1 – 参数 1 =V2/V1 (代表在 V2 还是 V1 上运行)
$2 – 参数 2 = 1/2/3 (代表第几次执行)
示例：sh run_sysbench.sh 2 1 (示意针对 Aurora Serverless V2 做第一轮测试) 测试输入三个 log 格局：v2_1_sysbench.log/v2_1_buffer_pool.log/v2_1_acu.log

sysbench 整体测试完结后从下面三个监控 logs(sysbench.log/buffer_pool.log/acu.log) 整顿每轮线程压测前 20 秒信息来进一步剖析 Aurora Serverless V2 在零碎负载变动时是否能够实现按需麻利扩大

sysbench 线程 10 压测 :

测试数据整顿（前 20 秒）

sysbench 线程 100 压测:

测试数据整顿（前 20 秒）

sysbench 线程 50 压测 :

测试数据整顿（前 20 秒）

sysbench 线程 600 压测 :

sysbench 线程 10 压测:

测试期间 CloudWatch Dashboard 监控指标:

观测后果： V2 CPUUtilization 与 ServerlessDabaseCapacity 曲线拟合度十分高 ACU 值随着 CPU 指标变动而变动特地是负载回升期间 CPU 回升 ACU 可达到霎时回升；CPU 下降时 ACU 值绝对安稳降落

观测后果： V2 QueriesPerSec 与 ServerlessDabaseCapacity 曲线拟合度比拟高

观测后果： V2 DBConnections 与 ServerlessDabaseCapacity 曲线拟合度比拟高

测试环境:

测试端

之前装置的 Aurora Serverless V2 测试机：EC2 C5 4XLarge

创立一主两从 Aurora Serverless V2 集群读正本 failover 级别别离为 Tier 0 和 Tier 15:

筹备 sysbench 数据:

连贯到主节点 create demo database 筹备 sysbench 测试数据（500 张表每张表 5 万条记录总共 5GB 数据）（具体步骤请参照上章测试）

创立 Cloudwatch Dashboard 为后续测试监控做筹备:

Dashboard Name：Aurora-Serverless-v2-reader

测试负载：

sysbench 读写负载（具体测试脚本请参照上章测试）
sysbench 只写负载（请参考以下所附脚本）
sysbench 只读负载（请参考以下所附脚本）

sysbench 只写负载：（循环执行 sysbench 只写负载每次执行 10 分钟）

$ cat same_sysbench_only_write.sh
host="请替换成你的 Aurora Endpoint"
username="admin"
password="****"
interval=1  
run_time= 600
threads=$1
while true  
do         
        echo $threads
echo "start ......................... `date`"
sysbench --db-driver=mysql --mysql-user=${username} --mysql-password=${password} --mysql-db=demo --mysql-host=${host} --mysql-port=3306 --tables=500 --table-size=50000 --time=${run_time} --forced-shutdown --rand-type=uniform --db-ps-mode=disable --report-interval=${interval} --threads=${threads} /usr/local/share/sysbench/oltp_write_only.lua run
echo "end ......................... `date`"
sleep 1
done

sh same_sysbench_only_write.sh 100 (参数为并发线程数)

sysbench 只读负载：（循环执行 sysbench 只读负载每次执行 10 分钟）

$ cat same_sysbench_only_read.sh
host="请替换成你的 Aurora Endpoint"
username="admin"
password="******"
interval=1  
run_time=600 
threads=$1
while true  
do         
echo "start ......................... `date`"
sysbench --db-driver=mysql --mysql-user=${username} --mysql-password=${password} --mysql-db=demo --mysql-host=${host} --mysql-port=3306 --tables=500 --table-size=50000 --time=${run_time} --forced-shutdown --rand-type=uniform --db-ps-mode=disable --report-interval=${interval} --threads=${threads} /usr/local/share/sysbench/oltp_read_only.lua run
echo "end ......................... `date`"
sleep 1
done
sh same_sysbench_only_read.sh 100 (参数为并发线程数)

测试场景 1:

测试：只在主节点增加 sysbench 读写压力：

测试场景 2:

测试：在主节点增加恒定的 sysbench 读写压力（线程为 100）, 在 Tier 15 的读正本上增加（线程为 10）的恒定的 sysbench 只读压力:

测试场景 3:

测试：在主节点手工做 Failover 观测在多少工夫主从切换至 Tier 0 读正本:

测试环境:

测试端

之前美东 1 装置的 Aurora Serverless V2 测试机：EC2 C5 4XLarge
美西 2 新装置的 Aurora Serverless V2 测试机：EC2 C5 4XLarge 装置 sysbench 测试软件（具体步骤请参照后面章节）

数据库环境

主集群（4 ACU-32 ACU）在美东 1
从集群（4 ACU – 32 ACU）在美西 2

筹备 sysbench 数据:

连贯到主集群主节点 create demo database 筹备 sysbench 测试数据（500 张表每张表 5 万条记录总共 5GB 数据）（具体步骤请参照后面章节）

创立 Cloudwatch Dashboard 为后续测试监控做筹备:

Dashboard Name：Aurora-Serverless-v2-reader

测试负载：

sysbench 读写负载（具体测试脚本请参照后面章节）
sysbench 只写负载（具体测试脚本请参照后面章节）
sysbench 只读负载（具体测试脚本请参照后面章节）

测试场景 1:

测试： 在主集群增加恒定的 sysbench 读写压力（线程为 100）, 在从集群增加（线程为 10）的恒定的 sysbench 只读压力：

测试场景 2:

测试： 在主节点增加恒定的 sysbench 只写压力（线程为 100）, 在从集群上观测复制提早:

测试场景 3:

测试： 执行 Managed-failover(从 us-west- 2 切换回 us-east-1) 观测主从切换所需工夫：

连贯到从集群 cluster endpoint 继续运行脚本查问集群的 max_connections 信息（请参照后面章节查问脚本）
在主集群上手动做 managed-failover 操作
记录 failover 操作产生工夫
观测大抵通过有多少工夫从集群能查问到信息

Bingbing liu

刘冰冰，AWS 数据库解决方案架构师，负责基于 AWS 的数据库解决方案的征询与架构设计，同时致力于大数据方面的钻研和推广。在退出 AWS 之前曾在 Oracle 工作多年，在数据库云布局、设计运维调优、DR 解决方案、大数据和数仓以及企业应用等方面有丰盛的教训。

面向 DirveSignup，可应用链接：Babelfish&Aurora Serverless v2 workshop（需微调）

关于云原生:云原生数据库极致弹性体验-Amazon-Aurora-Serverless-v2

一、前言

二、测试

2.1 扩展性测试

2.1.1 测试指标

2.1.2 测试后果和剖析

2.1.3 扩展性测试总结

2.2 读正本测试

2.2.1 测试指标

2.2.2 测试后果和剖析

2.2.3 读正本测试总结

2.3 寰球数据库测试

2.3.1 测试指标

2.3.2 测试后果和剖析

2.3.3 寰球数据库测试总结

三、迁徙数据库到 Aurora Serverless V2

3.1 抉择 Aurora Serverless V2 的理由

3.2 如何迁徙数据库到 Aurora Serverless V2

四、总结

五、附录：整体测试过程

5.1 测试环境

5.2 扩展性测试

5.2.1 测试环境筹备

5.2.2 测试

5.3 读正本测试

5.3.1 测试环境筹备

5.3.2 测试

5.4 全局数据库测试

5.4.1 测试环境筹备

5.4.2 测试

本篇作者

一、前言

二、测试

2.1 扩展性测试

2.1.1 测试指标

2.1.2 测试后果和剖析

2.1.3 扩展性测试总结

2.2 读正本测试

2.2.1 测试指标

2.2.2 测试后果和剖析

2.2.3 读正本测试总结

2.3 寰球数据库测试

2.3.1 测试指标

2.3.2 测试后果和剖析

2.3.3 寰球数据库测试总结

三、迁徙数据库到 Aurora Serverless V2

3.1 抉择 Aurora Serverless V2 的理由

3.2 如何迁徙数据库到 Aurora Serverless V2

四、总结

五、附录：整体测试过程

5.1 测试环境

5.2 扩展性测试

5.2.1 测试环境筹备

5.2.2 测试

5.3 读正本测试

5.3.1 测试环境筹备

5.3.2 测试

5.4 全局数据库 测试

5.4.1 测试环境筹备

5.4.2 测试

本篇作者

5.4 全局数据库测试