Aurora 5.6 升级不同数据量和机型所需要时间的测试 – PCMAN的技术博客

一、背景

Aurora MySQL 5.6在2023年2月28日End of life，因此需要升级到5.7或者8.0。参考AWS这篇官方文档对5.6结束生命周期的解释。

最简单的升级方式是：直接编辑数据库版本，选择新的版本，然后点击保存。此时数据库会修改版本并重启，升级期间无法接受外部访问。

为了合理申请停机窗口，本文模拟了一个有一定数据量的测试环境，评估升级所需要的时间。

二、用压力机生成数据

1、EC2压力测试机准备和Sysbench安装

部署一台EC2，使用Amazon Linux 2操作系统，并建议配置不低于m5.4xlarge规格，然后安装对应软件：

amazon-linux-extras install epel -y
yum update -y
yum install sysbench mysql -y
echo "kernel.pid_max = 65535" >> /etc/sysctl.conf
echo "" > /etc/security/limits.d/20-nproc.conf

cat > /etc/security/limits.conf <<EOF
* soft nofile 65536
* hard nofile 65536
* soft nproc 65536
* hard nproc 65536
EOF

cat > /etc/security/limits.d/20-nproc.conf <<EOF
* soft nofile 65536
* hard nofile 65536
EOF
root

注：以上步骤安装mysql软件包主要是使用命令行下的mysql客户端软件包，方便后续调试，并不是在压力测试机上启动完整数据库。

最后执行reboot命令重启EC2，让以上所有内核参数的修改彻底生效。

2、创建特定版本的数据库集群

创建Aurora MySQL数据库，机型选择为r5.xlarge的数据库，版本选择为Aurroa 1.19.6版本。

执行如下命令可以查看Aurora的版本：

select aurora_version(), @@aurora_version;

3、使用Sysbench填充数据

本实验模拟环境为

每个Aurora实例有1个数据库
每张表5000000行（约1GB）
总计约为2GB/20GB/50GB/100GB/200GB
机型为r5.large/r5.4xlarge/r5.8xlarge

在客户机上执行如下命令生成数据：

sysbench --db-driver=mysql \
    --mysql-host=aurora-1-19-6.cluster-cfv0psntfqnh.rds.cn-northwest-1.amazonaws.com.cn \
    --mysql-port=3306 \
    --mysql-user=admin \
    --mysql-password=1qazxsw2 \
    --mysql-db=lxy \
    --table_size=5000000 \
    --tables=20 \
    --events=0 \
    --threads=2 \
    oltp_read_write prepare

写在一行上便于复制，命令如下：

sysbench --db-driver=mysql --mysql-host=aurora-1-19-6.cluster-cfv0psntfqnh.rds.cn-northwest-1.amazonaws.com.cn --mysql-port=3306 --mysql-user=admin --mysql-password=1qazxsw2 --mysql-db=lxy --table_size=5000000 --tables=20 --events=0 --threads=2 oltp_read_write prepare

4、查看所有数据库的存储使用量

Sysbench生成数据完毕后，在压力机上使用mysql客户端，登录到Aurora后，执行如下SQL命令查询数据库占用空间情况。

use information_schema;
SELECT
    table_schema as '数据库',
    sum(table_rows) as '记录数',
    sum(truncate(data_length/1024/1024, 2)) as '数据容量(MB)',
    sum(truncate(index_length/1024/1024, 2)) as '索引容量(MB)',
    sum(truncate(DATA_FREE/1024/1024, 2)) as '碎片占用(MB)'
from
    information_schema.tables
group by table_schema
order by
    sum(data_length) desc, sum(index_length) desc;

以上命令调整格式写在同一行，方便查询。

SELECT table_schema as '数据库', sum(table_rows) as '记录数', sum(truncate(data_length/1024/1024, 2)) as '数据容量(MB)', sum(truncate(index_length/1024/1024, 2)) as '索引容量(MB)', sum(truncate(DATA_FREE/1024/1024, 2)) as '碎片占用(MB)' from information_schema.tables group by table_schema order by sum(data_length) desc, sum(index_length) desc;

查询结果类似如下截图。

如上截图，可看到这个数据库的使用了磁盘空间是20GB左右。

5、查看特定数据库内所有表的容量

执行如下命令查询某个数据库内各表占用的空间。请替换table_schema为实际的数据库名。

SELECT
    table_schema as '数据库',
    table_name as '表名',
    table_rows as '记录数',
    truncate(data_length/1024/1024, 2) as '数据容量(MB)',
    truncate(index_length/1024/1024, 2) as '索引容量(MB)',
    truncate(DATA_FREE/1024/1024, 2) as '碎片占用(MB)'
from 
    information_schema.tables
where 
    table_schema='lxy'
order by 
    data_length desc, index_length desc;

以上命令调整格式写在同一行，方便查询。

SELECT table_schema as '数据库', table_name as '表名', table_rows as '记录数', truncate(data_length/1024/1024, 2) as '数据容量(MB)', truncate(index_length/1024/1024, 2) as '索引容量(MB)', truncate(DATA_FREE/1024/1024, 2) as '碎片占用(MB)' from information_schema.tables where table_schema='lxy' order by data_length desc, index_length desc;

查询结果类似如下截图。

如上截图，可看到这个数据库的各表使用空间，加起来是20GB左右。

三、Aurora版本升级时间评估

1、查看升级时间的方法

找到要升级的数据库，选择数据库的集群（请不要选取单一实例），然后进入标签页Log & events菜单。继续向下滚动页面。如下截图。

在Recent events位置可看到升级相关的事件（也包括快照等）。注意发起时刻并不会立刻记录，因此发起时刻请手工记录，然后后续即可查询日子。如下截图。

2、测试数据量和机型对升级时间的影响

(1) 数据集 2GB

采用db.r5.large（2vCPU/16GB）机型，数据量2GB：

10月10日18:07发起1.19.6升级到2.10.2，18:27完成，耗时20分钟。
10月13日13:50发起1.19.6升级到2.10.2，14:10完成，耗时20分钟。（上一次同样数据集和机型配置，本次复测）

（2）数据集 20GB

采用db.r5.large（2vCPU/16GB）机型，数据量20GB：

10月11日14:25发起1.19.6升级到2.10.2，14:41完成，耗时16分钟。
10月13日14:51发起1.19.6升级到2.10.2，15:09完成，耗时18分钟。（上一次同样数据集和机型配置，本次复测）
10月11日10:22发起1.22.3升级到2.10.2，10:43完成，耗时21分钟。
10月09日21:29发起1.23.0升级到2.10.2，21:48完成，耗时19分钟。

机型提升到db.r5.4xlarge（16vCPU/128GB），数据量20GB保持不变：

10月11日21:59发起1.19.6升级到2.10.2，22:20完成，耗时21分钟。
10月13日11:57发起1.19.6升级到2.10.2，12:14完成，耗时17分钟。（上一次同样数据集和机型配置，本次复测）
10月13日12:16发起1.23.4升级到2.10.2，12:33完成，耗时15分钟。

机型提升到db.r5.8xlarge（32vCPU/256GB），数据量20GB保持不变：

10月13日14:10发起1.23.4升级到2.10.2，14:31完成，耗时21分钟。

（3）数据集 50GB

机型提升到db.r5.8xlarge（32vCPU/256GB），数据量50GB：

10月13日17:16发起1.23.4升级到2.10.2，17:39完成，耗时23分钟。

（4）数据集 100GB

10月14日11:55发起1.23.4升级到2.10.2，12:12完成，耗时17分钟。

（5）数据集 200GB

10月14日19:56发起1.23.4升级到2.10.2，20:17完成，耗时19分钟。

升级后的版本信息是：

MySQL [(none)]> select aurora_version(), @@aurora_version;
+------------------+------------------+
| aurora_version() | @@aurora_version |
+------------------+------------------+
| 2.10.2           | 2.10.2           |
+------------------+------------------+
1 row in set (0.00 sec)

MySQL [(none)]>

再次确认数据量是200GB。返回如下结果。

MySQL [(none)]> SELECT table_schema as '数据库', sum(table_rows) as '记录数', sum(truncate(data_length/1024/1024, 2)) as '数据容量(MB)', sum(truncate(index_length/1024/1024, 2)) as '索引容量(MB)', sum(truncate(DATA_FREE/1024/1024, 2)) as '碎片占用(MB)' from information_schema.tables group by table_schema order by sum(data_length) desc, sum(index_length) desc;
+--------------------+-----------+------------------+------------------+------------------+
| 数据库             | 记录数    | 数据容量(MB)     | 索引容量(MB)     | 碎片占用(MB)     |
+--------------------+-----------+------------------+------------------+------------------+
| lxy                | 986563695 |        210493.00 |          4773.76 |           800.00 |
| mysql              |    133225 |             4.52 |             2.37 |          1925.00 |
| information_schema |      NULL |             0.00 |             0.00 |             0.00 |
| performance_schema |     77026 |             0.00 |             0.00 |             0.00 |
+--------------------+-----------+------------------+------------------+------------------+
4 rows in set (0.01 sec)

10月14日19:56发起1.23.4升级到2.10.2，20:17完成，耗时19分钟。

四、结论

通过观察数据量可看到，一般的场景下，从Aurora MySQL 1.xx系列升级到2.10.2，执行原地升级方式，一般需要20分钟左右。生产数据因为复杂度不同，可能需要更长的时间。