在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主要选项为:
在本次测试中,一共进行了三组测试。规格大小统一为: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来实现高可用、跨可用区数据一致性的。
在MySQL的实例创建过程中,会有一些诸如:AD、FD(Fault Domins)等选项。这是OCI特有的关于区域、可用区等选项。关于区域和可用区的概念,Oracle Cloud与其他云厂商虽然都是相同的概念,但是用了完全不同的名称,也是非常容易让人困惑的。
在Oracle中,分了几层概念:Region->Availability Domains->Fault Domains。
OCI上的MySQL使用的MGR来实现高可用、高可靠(参考:High Availability@Oracle Cloud Infrastructure Documentation、Group 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)
instance configuration host : 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.00data on 10.0.0.74
instance configuration host : 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.00data on 10.0.0.224
instance configuration host : 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
参考