16 KB 永久性磁盘和 MySQL 的最佳做法

本文档介绍如何使用具有 16 KB 物理块大小的永久性磁盘提升 MySQL 数据库性能。

对于写入密集型 MySQL 工作负载,停用 InnoDB doublewrite 缓冲区通常十分有用。在清空脏页的过程中,MySQL 的 InnoDB 执行双重写入,因此它可以恢复可能已清理的页面。

但是,如果已有端到端 16 KB 原子写入路径以确保 16 KB 数据页面不会部分提交到磁盘或已清理的写入,则无需执行双重写入。如果停用双重写入,则数据库的脏页清空功能在本质上会加倍,减少数据库处于同步清空状态的频率,这样性能不但更稳定,而且还可能进一步增强。

准备工作

构建从数据库到块设备的 16 KB 原子写入路径

您可以利用 16 KB 永久性磁盘构建从数据库到块设备的端到端 16 KB 原子写入路径,以便在 MySQL/InnoDB 中安全停用双重写入功能,为高写入负载提供更稳定、更好的性能。

通过 Google Cloud Platform Consolegcloud 工具API 创建并挂接永久性磁盘。

  1. 创建 16 KB 块大小的永久性磁盘,并将该磁盘挂接到您的虚拟机。该 16 KB 永久性磁盘在物理块级层提供 16 KB 写入原子性。建议您对 MySQL 实例进行配置,使其将数据文件仅存储到 16 KB 永久性磁盘,但该操作不是强制性的。将日志文件(尤其是重做日志和二进制日志)存储于挂接到同一虚拟机的 4 KB 永久性磁盘。这可确保日志文件写入继续保持高性能,因为 16 KB 永久性磁盘上的小日志写入可能会触发大量“读取-修改-写入”操作,从而减缓运行速度。

  2. 将 ext4 文件系统与 BigAlloc 选项结合使用以格式化 16 KB 磁盘,并将集群大小设为 16 KB。下面是一个已指定 BigAlloc 选项的 mkfs 命令示例:

    mkfs.ext4 -O bigalloc -C 16384 [...other options…]
    

    使用集群大小为 16 KB 的 BigAlloc,这可确保文件系统分配的文件与磁盘上的 16 KB 边界一致。

  3. 创建虚拟机实例时,从 cos-cloud 项目的 Google Container-Optimized OS 映像系列中选择一个操作系统映像。

    使用 gcloud 命令查看所有可用的 cos 映像列表:

    gcloud compute images list --project cos-cloud --no-standard-images
    

    选择版本 67 或更高版本。为了获得更好的结果,请考虑从 cos-stable 系列中选择一个映像。

    选择 cos 映像可确保文件系统和物理块设备层之间的层不会跨 16 KB 边界以不正确的方式拆分写入内容。cos 映像审批过程具有内置测试,以确保此结果。

  4. 确保在操作系统中正确配置 max_segmentsmax_sectors_kb

    max_segments >= max_sectors_kb/4
    

    这两个变量已在所有 Google Compute Engine 虚拟机中进行配置,如果您不具有在创建虚拟机后用来更改这两个变量的脚本,则此时您不需要执行任何操作。

    您可以在此路径下查询操作系统中的这两个常量:

    /sys/block/sd<drive letter>/queue/
    
  5. InnoDB 配置为使用 O_DIRECT。将 O_DIRECT 设置为(或添加到)innodb_flush_method 数据库配置。

现在,您可以安全关闭 innodb_doublewrite 选项

要确保使用 16 KB 块设备执行端到端 16 KB 原子写入,此方法不是唯一的方法。例如,如果您将数据库配置为直接使用块设备作为原始设备而不使用文件系统,则您可以跳过上述有关文件系统配置的步骤。

后续步骤

此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
Compute Engine 文档