沙场秋点兵——MySQL 容器化性能测试对比

容器技术改变了应用交付、运行的方式，几乎各种 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 运行各种中间件应用的最佳实践，以及相关的技术细节。