容器技术扭转了利用交付、运行的形式,简直各种Linux环境下的应用程序都能够应用容器来运行。但是否能在容器环境里运行数据库利用,以及数据库利用是否适宜在容器里运行,始终都是大家很关注的问题,明天咱们就来深入分析一下容器环境运行MySQL数据库的事。
在容器中运行数据库,能帮忙用户进步服务器利用效率,升高基础架构老本,更疾速地部署、更便捷地治理数据库服务。
依据云监控供应商Datadog的调查报告, Postgres、MongoDB和MySQL等数据库技术都位于容器上运行的十大技术之中——并且使用量还在增长。
MySQL容器化须要容器存储的无力反对
数据库实际上由两大组件组成:读取、写入和查问数据的利用,以及数据存储,咱们通常称之为数据卷。MySQL等数据库利用所需的计算资源齐全能够通过容器技术提供,是否能流畅运行MySQL数据库的关键在于容器存储计划。国内大多数用户在抉择容器存储时,通常有以下几种计划:
- 新版本的Kubernetes能够反对块设施挂载至容器外部(该块设施能够来自服务器的物理磁盘,也能够来自传统的SAN阵列)
- 通过Ceph提供的CSI插件应用CephRBD或者CephFS
- 应用YRCloudFile提供的容器存储
- 大多数客户对容器存储的以下几点尤为关注:
数据可靠性
- 是否能通过容器编排平台疾速实现存储资源的生命周期治理(创立、扩容、删除和回收等)
- MySQL在容器化环境中的容灾备份
- MySQL容器故障后,在新节点重新启动,其数据是否能快速访问
- MySQL应用容器存储的理论性能如何,是否能满足业务需要
对于用户关注的上述个性,咱们在之前的文章中都有过介绍,在当前的文章里也会进一步形容。本文针对用户最关注的,MySQL基于不同存储的理论性能进行了理论测试和比照。
MySQL存储引擎和数据写入策略
在介绍理论测试性能之前,有必要介绍一下MySQL数据库的存储引擎,以及相干的写入策略,这对于数据库的理论使用性能有十分要害的影响。
MySQL存储引擎
MySQL数据库提供插件式的存储引擎,这个存储引擎提供了一系列规范的治理和数据读写服务的反对,不同的存储引擎有不同的特点,存储引擎对于业务开发人员而言是通明的。其中,InnoDB是驰名的第三方存储引擎,后被Oracle收买,是MySQL数据库OLTP(Online Transaction Processing,在线事务处理)利用中应用最广的存储引擎,也是5.5.8版本后,MySQL默认的存储引擎,以下的测试就基于InnoDB存储引擎进行。
InnoDB刷数据策略
InnoDB中有一项设置——innodb_flush_method,这项设置负责管制InnoDB刷数据时所应用的零碎调用。所谓刷数据,行将缓存在内存中或长期磁盘存储区域中的数据写入特定的日志及数据文件(log,如ib_logfile和数据库data file),实现长久化。
刷数据动作可能是因为内存区域已满并且零碎须要开释一些空间而触发,或是因为事务实现更改的commit操作而触发,或者由须要终结所有未实现工作的敞开操作而触发。
innodb_flush_method的值对应着不同的零碎调用,从而会触发不同的零碎行为,常常应用的值包含:
- fsync:InnoDB应用fsync()零碎调用将MySQL的数据和日志文件都刷到长久化存储中,fsync是InnoDB的模式设置。
- O_DIRECT:InnoDB应用O_DIRECT标识关上MySQL的数据文件,意味着MySQL数据将绕过pagecache,间接写入磁盘,并应用fsync()零碎调用将MySQL数据和日志文件的元数据信息更新刷入磁盘。
- O_DIRECT_NO_FSYNC:只应用O_DIRECT形式,绕过pagecache,将数据间接写入磁盘,并在写操作时跳过fsync()更新日志的元数据信息。在8.0.14版本之后, MySQL会在创立文件、减少文件长度以及敞开文件时主动调用fsync()来更新MySQL文件在文件系统中的元数据信息。
YRCloudFile能够反对这种刷数据形式,即能够很好地确保每个数据都间接落盘,同时缩小频繁调用fsync带来的开销,极大晋升性能。
sysbench性能比照测试
在上面进行的性能比照的测试中,咱们在MySQL容器中应用了以下几种存储计划进行比照:
- 将本地物理SSD盘挂载到MySQL容器中
- 将基于RoCE(RDMA over Converged Ethernet)的YRCloudFile集群中的PV挂载到MySQL容器中
- 将基于TCP的YRCloudFile集群中的PV挂载到MySQL容器中
- 将CephRDB的PV挂载到MySQL容器中
- 将CephFS的PV挂载到容器中
除物理SSD盘外,YRCloudFile和Ceph集群都采纳以下四台雷同的物理服务器进行搭建:
- CPU:Intel 4112 * 2
- 内存:64GB
- 系统盘:240GB * 2
- 元数据盘:960GB SSD * 2(CephRBD时不须要元数据盘)
- 缓存盘:960GB SSD * 2
- 数据盘:4TB SATA * 2
- 管理网络:1Gb * 2
- 存储网络:10Gb * 2
MySQL版本为8.0.14,应用InnoDB作为存储引擎,innodb_flush_method设为O_DIRECT_NO_FSYNC ;Ceph版本为mimic,Ceph基于filestore;sysbench版本为1.0.17,基于50个表,每个表中蕴含100万条数据的数据库进行oltp_write_only和oltp_read_write测试。
测试后果如下:
从测试后果看:
- 间接应用物理SSD时,因为是进行本地SSD读写,延时很低;且MySQL利用为了确保其操作的程序性,次要是采纳无限线程低并发进行程序追加写,延时性能决定了单个MySQL的整体性能,因而无论YRCloudFile还是Ceph存储集群对单个MySQL实例而言,会受到延时影响,性能不如本地SSD盘。
- 另一方面,咱们看到基于RoCE的YRCloudFile的性能曾经靠近本地SSD盘,基于TCP的YRCloudFile集群所提供的性能略低于RoCE的性能。
- 基于RoCE的YRCloudFile性能高于基于TCP的YRCloudFile性能,是CephRBD或CephFS性能的将近一倍。这是因为:1)YRCloudFile集群的元数据保留在本地SSD,绝对于CephFS的元数据保留在RADOS中而言,其元数据读延时显著低于CephFS;2)基于RDMA的YRCloudFile绕过了零碎内核,间接拜访集群中的磁盘数据,进一步升高了提早。
兴许有读者会问,从单个MySQL实例的测试性能看,YRCloudFile分布式存储系统的劣势如何体现呢?通过应用YRCloudFile,能够充分发挥集群中所有磁盘的性能,使整个集群反对更多的MySQL实例,而单块SSD盘的性能能够撑持的MySQL实例就无限得多了。此外,YRCloudFile也正在通过硬件offload,NVMe优化等形式,进一步缩短集群IO的延时,使集群IO的延时尽可能靠近本地SSD的延时,从而使单MySQL实例的性能更加靠近应用本地SSD运行MySQL的性能。
在这篇文章中,咱们介绍了如何通过设置MySQL InnoDB的innodb_flush_method参数,应用YRCloudFile获得最佳的MySQL运行性能,并比照了在等同环境下,应用SSD、CephRBD、CephFS所取得的性能。在后续文章里,咱们还会分享更多基于YRCloudFile运行各种中间件利用的最佳实际,以及相干的技术细节。