Skip to main content
Enterprise applications
简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

采用SAN的MySQL

贡献者

使用通常的双卷模式为MySQL配置SAN有两种选择。

只要I/O和容量需求不超过单个LUN文件系统的限制、就可以将较小的数据库放置在一对标准LUN上。例如、需要大约2K随机IOPS的数据库可以托管在单个LUN上的单个文件系统上。同样、大小仅为100 GB的数据库可以容纳在一个LUN上、而不会产生管理问题。

大型数据库需要多个LUN。例如、需要100K IOPS的数据库最有可能至少需要八个LUN。由于驱动器的SCSI通道数量不足、单个LUN将成为瓶颈。同样、在一个10 TB LUN上管理一个10 TB数据库也很困难。逻辑卷管理器旨在将多个LUN的性能和容量功能绑定在一起、以提高性能和易管理性。

在这两种情况下、一对ONTAP卷都应足以满足要求。在简单的配置中、数据文件LUN会像日志LUN一样放置在一个专用卷中。使用逻辑卷管理器配置时、数据文件卷组中的所有LUN都将位于一个专用卷中、而日志卷组的LUN将位于另一个专用卷中。

提示

*MySQL建议*在SAN上部署NetApp时使用两个文件系统：

  • 第一个文件系统存储所有MySQL数据、包括表空间、数据和索引。

  • 第二个文件系统存储所有日志(二进制日志、慢速日志和事务日志)。

以这种方式分隔数据有多种原因、包括：

  • 数据文件和日志文件的I/O模式不同。如果将它们分开、则可以使用QoS控制提供更多选项。

  • 要充分利用Snapshot技术、需要能够独立还原数据文件。将数据文件与日志文件相结合会影响数据文件还原。

  • NetApp SnapMirror技术可用于为数据库提供简单的低RPO灾难恢复功能；但是、它需要为数据文件和日志制定不同的复制计划。
备注 使用此基本的双卷布局可使解决方案适应未来需要、以便在需要时可以使用所有ONTAP功能。
提示

  • NetApp建议*使用ext4文件系统格式化驱动器，因为它具有以下功能：

  • 日志文件系统(jfs)中使用的块管理功能的扩展方法以及扩展文件系统(xfs)的延迟分配功能。

  • ext4允许文件系统最多包含1个外部字节(2^60字节)、文件最多包含16个TB (16 * 2^40字节)。相比之下、ext3文件系统仅支持最大文件系统大小16 TB和最大文件大小2 TB。

  • 在ext4文件系统中、多块分配(mbALLO每次 操作)会为一个文件分配多个块、而不是像ext3那样逐个分配。此配置可减少多次调用块分配器的开销、并优化内存分配。

  • 虽然XFS是许多Linux分发版的默认设置、但它管理元数据的方式不同、不适用于某些MySQL配置。
提示

  • NetApp建议*在mkfs实用程序中使用4k块大小选项、以便与现有块LUN大小保持一致。

mkfs.ext4 -b 4096

NetApp LUN将数据存储在4 KB物理块中、从而生成八个512字节逻辑块。

如果未设置相同的块大小、I/O将无法与物理块正确对齐、并且可能会在RAID组中的两个不同驱动器中写入数据、从而导致延迟。

备注 请务必对齐I/O、以实现顺畅的读/写操作。但是、如果I/O从逻辑块开始、而逻辑块不是物理块的起始位置、则表示I/O未对齐。只有当I/O操作从逻辑块(即物理块中的第一个逻辑块)开始时、才会对齐。