MySQL

  • 在MySQL社区的帮助下,终于成功开通了Oracle Cloud,于是,第一时间测试了一下在Oracle Cloud上托管MySQL,看看Oracle MySQL原厂的性能表现如何。

    关注我朋友圈的应该知道,在国内自助的注册Oracle Cloud真的非常不容易。所以,特别感谢Oracle MySQL原厂工程师徐轶韬的帮助,他也是《MySQL高可用解决方案-从主从复制到InnoDB Cluster架构》的作者,他的公众号是“MySQL解决方案工程师”,感兴趣可以关注他的公众号。

    回到正文,Oracle Cloud的全称是”Oracle Cloud Infrastructure”,也经常被简称为”OCI”。在OCI上提供的MySQL服务,相较于AWS、阿里云来说,产品形态也比较简单。首先,托管MySQL在分类“Databases->MySQL HeatWave->DB Systems”这个类目下,在实例创建过程中,涉及的选项不算多,但是因为名词/定义与其他云厂商有一些不同,所以这里做一些解释。Oracle Cloud上的托管MySQL主要选项为:

    • 高可用类型(单节点/standalone、三节点/HA)
    • 规格大小
    • 主可用区选择
    • 空间大小(IOPS/吞吐量与此相关)

    在本次测试中,一共进行了三组测试。规格大小统一为:2 OCPU(Oracle CPU)32GB,100GB存储(对应的7500 IOPS),规格代码为MySQL.VM.Standard.E4.2.32GB。三组测试对比项分别为:单节点 vs 三节点和同可用区 vs 跨可用区。三组测试具体为:跨可用区的三节点测试、同可用区的三节点测试、同可用区的单节点测试。详细参数表如下:

    整体性能趋势图

    整体上,OCI上的MySQL高可用版本(MGR三节点)性能要比单节点低约20%。在三节点的两次测试下,跨可用区与同可用区有着几乎相同的性能表现,从延迟上来看,也非常接近,可用区之间的延迟约为百微秒级别。

    相比于其他云厂商,OCI上的MySQL性能表现,并不算高的。从架构层面,Oracle MySQL是唯一一个选择了MGR来实现高可用、跨可用区数据一致性的。

    OCI上的区域与可用区

    在MySQL的实例创建过程中,会有一些诸如:AD、FD(Fault Domins)等选项。这是OCI特有的关于区域、可用区等选项。关于区域和可用区的概念,Oracle Cloud与其他云厂商虽然都是相同的概念,但是用了完全不同的名称,也是非常容易让人困惑的。

    在Oracle中,分了几层概念:Region->Availability Domains->Fault Domains。

    • Region与其他云厂商区域概念相同;
    • Fault Domains则与其他云厂商的“可用区”对应;
    • 在OCI中,通常三个为一组的Fault Domains会组成一个“Availability Domains”。大部分的Oracle Region中只有一个Availability Domains,也有部分region有3个Availability Domains(参考),所以在MySQL的配置选项中会有AD、FD等缩写词语。

    Oracle Cloud上MySQL实例的数据可靠性架构

    OCI上的MySQL使用的MGR来实现高可用、高可靠(参考:High Availability@Oracle Cloud Infrastructure DocumentationGroup Replication@MySQL Documentation)。三个不同的MySQL节点分布在三个不同的FD,每个节点使用的存储是OCI上的Block Volume(参考),以iSCSI方式使用,类型是“Higher Performance”(此外,还有Balanced、Ultra High Performance、Lower Cost三种Block Volume)。

    根据参数配置来看,Oracle Cloud提供的MySQL三节点是通过MGR实现的,使用的是group_replication_single_primary_mode模式。

    mysql> show variables like '%group_replication_single_primary_mode%';
    +---------------------------------------+-------+
    | Variable_name                         | Value |
    +---------------------------------------+-------+
    | group_replication_single_primary_mode | ON    |
    +---------------------------------------+-------+
    1 row in set (0.00 sec)

    其他说明

    • Oracle Cloud的MySQL没有提供两节点选项
    • 产品规格,Oracle Cloud使用的是OCPUs(Oracle CPU,可以理解为core),详细参考:vCPU and OCPU pricing information。相比于其他云厂商的vCPU(大部分时候为超线程)是明显不同的。

    性能测试的原始数据

    2024-01-14@MySQL at Oracle Cloud Benchmark
    host : 10.0.0.13 
    sub_dir : 10.0.0.13 
    ins_code : MySQL.VM.Standard.E4.2.32GB 
    ha_type : ha 
    same_az : 1 
    region : tokyo 
    storage_size : 100 
    
    sysbench for host :10.0.0.13
    threads|transactions| queries| time |avg/Latency|95%/Latency
          2|       95033| 1900660|300.01|       6.31|       7.56 
          4|      148751| 2975020|300.01|       8.07|      10.27 
          8|      214974| 4299480|300.01|      11.16|      13.70 
         16|      262105| 5242100|300.01|      18.31|      30.81 
         24|      253583| 5071660|300.03|      28.39|      47.47 
         32|      272755| 5455100|300.03|      35.20|      54.83 
         48|      269370| 5387400|300.04|      53.46|      77.19 
         64|      286891| 5737820|300.06|      66.93|     102.97 
         96|      276749| 5534980|300.12|     104.08|     161.51 
        128|      287452| 5749040|300.13|     133.61|     183.21 
        192|           0|       0|  0.00|       0.00|       0.00 
    
    host : 10.0.0.74 
    sub_dir : 10.0.0.74 
    ins_code : MySQL.VM.Standard.E4.2.32GB 
    ha_type : ha 
    same_az :  
    region : tokyo 
    storage_size : 100 
    
    sysbench for host :10.0.0.74
    threads|transactions| queries| time |avg/Latency|95%/Latency
          2|       90638| 1812760|300.01|       6.62|       7.84 
          4|      147270| 2945400|300.01|       8.15|      10.09 
          8|      215078| 4301560|300.01|      11.16|      13.70 
         16|      242713| 4854260|300.02|      19.78|      33.72 
         24|      260072| 5201440|300.02|      27.68|      45.79 
         32|      273703| 5474060|300.03|      35.07|      56.84 
         48|      283811| 5676220|300.06|      50.74|      73.13 
         64|      287176| 5743520|300.06|      66.86|     102.97 
         96|      283113| 5662260|300.09|     101.74|     158.63 
        128|      285210| 5704200|300.12|     134.66|     189.93 
        192|           0|       0|  0.00|       0.00|       0.00 
    
    host : 10.0.0.224 
    sub_dir : 10.0.0.224 
    ins_code : MySQL.VM.Standard.E4.2.32GB 
    ha_type : standalone 
    same_az : 1 
    region : tokyo 
    storage_size : 100 
    
    sysbench for host :10.0.0.224
    threads|transactions| queries| time |avg/Latency|95%/Latency
          2|      102033| 2040660|300.00|       5.88|       7.56 
          4|      186602| 3732040|300.01|       6.43|       8.90 
          8|      281464| 5629280|300.01|       8.53|      12.30 
         16|      333418| 6668360|300.02|      14.40|      31.94 
         24|      345463| 6909260|300.02|      20.84|      47.47 
         32|      359902| 7198040|300.03|      26.67|      56.84 
         48|      353246| 7064920|300.06|      40.77|      78.60 
         64|      370118| 7402360|300.07|      51.88|      99.33 
         96|      380647| 7612940|300.09|      75.67|     134.90 
        128|      372683| 7453660|300.12|     103.05|     164.45 
        192|           0|       0|  0.00|       0.00|       0.00 
    

    参考

    1. High Availability@Oracle Cloud Infrastructure Documentation
    2. Group Replication@MySQL Documentation
    3. vCPU and OCPU pricing information

  • 随着云数据库的普及,数据库的传输加密也会随之被广泛使用。本文,将使用通用测试来看看,开启TLS传输对数据库的性能有什么样的影响。

    1. 原理概述

    开启TLS传输加密之后,分别会在建立连接、数据传输两个阶段对性能造成影响。因为建立连接的过程通常是一次性的,连接会被复用,所以这部分的性能开销通常是可以接受的。在传输阶段,是传输加密对性能影响的重要阶段,这时候通常会使用对称加密算法(例如AES256)对数据进行加密,那么实际的对称加密的性能就是对TLS传输加密性能影响最大的部分。需要注意的是,如果应用使用的是短链接(应该尽量避免使用这种方式),TLS加密的密钥交换阶段也会对每个连接建立的过程都有一定的性能影响。

    2. 云数据库实际测试

    这里选择对RDS MySQL进行测试,云厂商则各自选择国外、国内Top 1的云厂商AWS和阿里云。

    2.1 测试方法说明

    使用sysbench 1.1.0版本,测试类型为oltp_read_write,相关参数如下:

    • –mysql-ssl=REQUIRED 是否使用TLS加密传输
    • –percentile=95 关注95%Query的延迟
    • –histogram=on 可以查看延迟分布情况
    • –time=600 sysbench运行的总时间(秒)
    • –warmup-time=60 开始计算性能前预热时间(秒)
    • –table_size=1000000 单表100万条记录
    • –tables=5 共测试5个表
    (more…)
  • 测试说明

    这是一个云数据库性能测试系列,旨在通过简单标准的性能测试,帮助开发者、企业了解云数据库的性能,以选择适合的规格与类型。这个系列还包括:

    云数据库(RDS MySQL)性能深度测评与对比

    阿里云RDS标准版(x86) vs 经济版(ARM)性能对比

    华为云RDS通用型(x86) vs 鲲鹏(ARM)架构的性能对比

    AWS基于x86 vs Graviton(ARM)的RDS MySQL性能对比(二)

    AWS基于x86 vs Graviton(ARM)的RDS MySQL性能对比

    阿里云RDS存储类型概述

    阿里云RDS提供了较为丰富的存储类型选择,包括ESSD PL0、ESSD PL1、ESSD PL2、ESSD PL3、通用云盘、本地SSD。其中ESSD PL0仅在非常小的经济型规格中提供,并不在测试范围内。根据阿里云的官方文档可以看到,从PL0到PL3,性能越来越强,并且IO能力也越来越稳定(详细参考:ESSD云盘@阿里云文档中心),当然价格也越来越贵。这里摘抄了文档中的描述,以及关键的部分,对比如下:

    此外,“通用云盘”的说明可以参考阿里云文档描述:“通用云盘兼容ESSD云盘的所有特性,性能与ESSD PL1云盘相同,在ESSD云盘的基础上提供了IO突发能力。” 所以,可以这样理解,通用云盘是一种具备ESSD PL1能力,同时具备更加灵活的IOPS突发增长能力的云盘。突发IOPS部分,将额外计费(有少部分的免费额度),突发IOPS部分的额外费用为:0.02元/万IO。

    不同存储类型的性能趋势对比

    那么,我们看看在RDS MySQL中这些不同的存储的性能表现。这里依旧选择了“企业级规格”进行比较(企业级规格的定义可以参考:云数据库(RDS MySQL)性能深度测评与对比),详细的性能如下:

    可以看到:

    • 对于几种云盘的存储,RDS表现出了较为一致的性能,即,使用更好的存储的RDS总是能够获得了更好的性能:ESSD PL3 > ESSD PL2 > 通用存储 >> ESSD PL1
    • 本地SSD,性能则是最差的存储,相较于ESSD PL1要低9%;相较于性能最好的ESSD PL3则要低18.7%
    • 不过,相较于ESSD PL1/2/3之间成倍的价格增长,从这里的测试性能并没有展示出那么大的差距
    (more…)
  • TL;DR:用8.0系列中的8.0.34之后的版本,该系列版本后续主要以保障稳定、修复bug为主。MySQL 8.1、8.2都是“创新版”,很长时间都会快速迭代,稳定性要差一些,而且目前还不确定会添加哪些新功能在里面。9.0官方预计1年后就会发布,不过不重要,也会先发布Innovation版。

    MySQL在今年7月正式引入了新的版本发布模式,引入了包括8.1、8.2等版本。新的版本,给MySQL的新特性开发带了很大的好处,也让开发者容易变得困惑。这里概述一下各个版本,以及后续的版本发布规划,帮助开发者们在生产环境选择自己合适的版本。

    • 从MySQL 8.0.34开始,8.0系列将以Bugfix为主,保障稳定,是当前的LTS(Long Term Support)版本,一直到EOL(约为2026年4月)
    • 8.1/8.2版本,当前都是Innovation版本,预计在一年后,发布新的LTS版本;8.1 / 8.2 版本目前来看,还没有什么特别的功能引入,期待后续迭代
    • 对于LTS版本,其生命周期是标准的5+3年,5年“完整支持”、3年“扩展支持”
    • 预计8.4会是下一个LTS版本,在下一个LTS版本发布的时候,9.0就会正式发布,所以,9.0版本可能会在一年后就发布。届时,8.4就是8.x的LTS版本,同时发布9.0版本(Innovation版)。
    • Innovation版本,可以理解为,MySQL的官方工程师们可以“大刀阔斧”的做一些修改,除了添加新功能外,还可能删除某个功能、重构某个功能等。
    • MySQL 8.0的Premier Support将会到2025年4月;Extended Support 会到2026年4月

    参考:

  • 阿里云为ECS提供最新版本的是Alibaba Cloud Linux 3系统(3.2104 LTS 64位),根据Release Notes可以确定这是一个“CentOS 8、RHEL 8”兼容版,开始安装吧。

    1. 下载,并添加MySQL官方Yum仓库

    下载时选择Red Hat Enterprise Linux 8版本即可。

    # 下载,Centos 8版本:
    wget https://dev.mysql.com/get/mysql80-community-release-el8-9.noarch.rpm
    
    # 如果是你 Centos 7,那么可能是如下命令:
    wget https://dev.mysql.com/get/mysql80-community-release-el7-11.noarch.rpm
    
    # 安装配置仓库(Centos 8)
    sudo yum localinstall mysql80-community-release-el8-9.noarch.rpm
    
    # 确认与检查
    yum repolist enabled | grep mysql.*-community
    mysql-connectors-community MySQL Connectors Community
    mysql-tools-community      MySQL Tools Community
    mysql80-community          MySQL 8.0 Community Server

    2. 打开或关闭需要的子仓库

    如上面的输出,可以看到,8.0版本(mysql80-community)子仓库是默认打开的。如果要安装8.0版本,则可以跳过这一步了。但,如果要安装其他版本,例如你希望安装innovation版本,那么可以通过关闭8.0仓库,打开innovation版本子仓库的方式解决。

    # 查看有哪些子仓库,以及是否打开
    yum repolist all | grep mysql
    
    # 如果需要的话,可以禁用8.0子仓库,打开innovation版子仓库
    yum-config-manager --disable mysql80-community
    yum-config-manager --enable mysql-innovation-community
    

    我们总是可以通过yum repolist命令查看所有仓库的状态:

    yum repolist
    yum repolist enabled
    yum repolist disabled

    3. 安装需要的MySQL-Server软件

    # 查看仓库和版本
    yum list mysql-community-server
    mysql-community-server.x86_64      8.2.0-1.el8      mysql-innovation-community
    
    # 安装MySQL 8.2.0
    yum install mysql-community-server
    ...
    Complete!

    4. 启动数据库

    这是一个默认启动。

    systemctl start mysqld

    总是可以通过如下命令启动/关闭/重启或查看MySQL-Server的状态。

    systemctl start mysqld
    systemctl stop mysqld
    systemctl restart mysqld
    systemctl status mysqld

    默认的配置文件

    cat /etc/my.cnf
    [mysqld]
    datadir=/var/lib/mysql
    socket=/var/lib/mysql/mysql.sock
    
    log-error=/var/log/mysqld.log
    pid-file=/var/run/mysqld/mysqld.pid

    5. 使用root账号登录数据库

    MySQL在启动时,会随机生成一个默认的root密码,首次登录需要获取该密码,并在登录后,立刻修改密码。

    获取密码:
    # 从日志文件中获取密码
    grep 'temporary password' /var/log/mysqld.log
    [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: p!5h)W9DikW/
    登录并修改密码:
    # 登录
    mysql -uroot -p
    Enter password:
    Welcome to the MySQL monitor.  Commands end with ; or \g.
    Your MySQL connection id is 10
    Server version: 8.2.0
    
    Copyright (c) 2000, 2023, Oracle and/or its affiliates.
    
    Oracle is a registered trademark of Oracle Corporation and/or its
    affiliates. Other names may be trademarks of their respective
    owners.
    
    Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
    
    # 修改默认的root密码
    mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'MyNewPass4!';

    6. 一种不安全、但是偷懒的做法

    这是一种非常不安全的做法,但是很方便:可以在配置文件(my.cnf)中新增skip-grant-tables=ON参考)来关闭MySQL的用户认证与鉴权体系,谨慎使用

    这时候,就可以没有任何密码,不用关注任何权限去登录与使用数据库。不过,为了安全考虑,该参数打开后,数据库也会禁用所有远程的连接,仅允许本地的访问。

    EOF

    参考:

  • MySQL在上个月正式EOL,意味着官方不会再发布新版本去修复Bug或者安全漏洞。一般来说,云厂商对老版本支持要更就一些,那么一起来看看各个云厂商对5.7的支持情况。概述:

    • AWS:首先,AWS RDS MySQL将提供额外的、免费的半年标准支持,期间提供bug修复、漏洞修复等;2024年2月后,AWS RDS将提供付费的扩展支持。届时,如果不选择付费扩展支持的实例,将会自动(可以理解为“强制”)被升级到8.0版本,“付费”的扩展支持应该持续3年。(注:Aurora的免费支持时间会更长一些,到2024年11月)
    • 阿里云:目前,对于5.7还没有看到正式的说明。但,对于5.6版本,阿里云数据库曾发通告,将提供额外的三年维护时间。不过鉴于5.7实例体量巨大(因为8.0版本拖的时间太长),对于5.7版本支持的时间可能会更长。
    • 其他云厂商:目前都比较模糊,可以理解为不会有任何动作,用户可以正常使用。

    AWS对MySQL 5.7的支持

    AWS有Aurora MySQL 5.7(即Aurora 2.x系列)、RDS MySQL 5.7两个版本。在Oracle MySQL官方到达EOL后,AWS额外提供了半年(Aurora约一年)的免费标准支持,以及三年的付费支持。即,AWS RDS将免费支持5.7到2024年02月底,Aurora到2024年11月底;另外,还将提供三年的付费支持,约到2027年。是的,要收费的(参考)。这段时间,AWS将继续提供安全相关的Bug修复、以及重要的功能Bug修复。

    这个收费策略应该是开了云厂商对于旧版本数据库支持的先河。维护老的版本,需要额外的技术人员投入,维护一个过期的版本的投入从长时间来看,是低效的,所以,用户是需要为这部分服务付费的。

    AWS 扩展支持的收费方式与费率

    收费方式是按照vCPU * HourACU * Hour计费,不同的区域会有不同,不同的时间也会不同,离官方EOL时间越长,费用会越贵。不过,在官方版本到达EOL之后,AWS预留了4个月~一年的免费时间,让用户安排升级。以RDS MySQL 5.7为例,自2024年2月底之后,以新加坡地区为例,前两年付费扩展支持价格为 $0.12/(vCPU * Hour),第三年的费用为$0.24/(vCPU * Hour)。以一个4c16g(db.m5.xlarge)的实例计算,一个月费扩展支持费用约为$345。而该实例本身的价格约为(两节点高可用):$677 = 0.47*24*30*2。所以,AWS的策略是,价格摆在这里了,升不升级,由用户自己定夺。

    (more…)