共计 3105 个字符，预计需要花费 8 分钟才能阅读完成。
容器技术扭转了利用交付、运行的形式，简直各种 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 运行各种中间件利用的最佳实际，以及相干的技术细节。
