本节将介绍当你决定更多更快的存储硬件设备投入到数据库服务器时,应该如何配置它们。 软件配置上优化InnoDB以提高I / O性能的信息,请参见第9.5.8节“优化InnoDB磁盘I/O”。
- 磁盘寻道是一个巨大的性能瓶颈,当数据量剧增到使得缓存命中率减小时,这个问题会更为明显。对于或多或少会进行随机访问的大型的数据库,可以确定对于读至少需要一次磁盘寻道,而对于写需要好几次磁盘寻道。要最小化这个问题,应该用磁盘寻道时间较小的磁盘。
-
增加可以用磁盘数,这样就可以通过符号链接将不同文件存储到不同磁盘,或者可以通过磁盘分条,来降低寻道开销。
条带化的速度差异十分依赖于参数配置。根据如何设置条带化参数和硬盘数量,你可能会得到数量级的差异。对于优化随机访问还是顺序访问,你必须做出选择。
- 为了可靠性,你可能需要使用RAID 0+1(条带加镜像),但在这种情况下,需要2×N个磁盘来N个磁盘的数据。如果你有足够的钱,这可能是最好的选择,而且,你可能还需要额外投资一些卷管理软件来有效地管理它们。
-
一个好的选择是根据数据类型的关键程度来改变RAID级别。 例如,可以再生的一般重要数据可以放在RAID 0上,但将真正重要的数据(如主机信息和日志)存储在RAID 0+1或 RAID N磁盘上。 如果写入较多,则由于更新奇偶校验位需要时间,RAID N可能不太合适。
-
你也可以设置数据库所涉及的文件系统的参数:如果您不需要知道上次访问文件的时间(这在数据库服务器上通常用途不大),则可以使用-o noatime选项来挂载文件系统。 这会跳过对文件系统上inode的最后访问时间的更新,从而避免某些磁盘寻道。在许多操作系统上,您可以通过使用-o async选项挂载文件系统以将其设为异步更新。 如果您的计算机相当稳定,这应该给你更好的性能,而不会牺牲太多的可靠性。 (在Linux上,此标志默认是打开的)
-
对于使用NFS的MySQL,应该注意的潜在问题如下:
- 放在NFS卷上的MySQL数据和日志文件变成锁定状态并且无法使用:锁定问题可能发生在多个MySQL实例访问相同数据目录或MySQL由于断电等而不正常关闭的情况下。 NFS版本4解决了咨询或租赁导致的锁定问题。 但是,MySQL实例之间共享数据目录是不被推荐的。
- 由于收到无序的消息或丢失的网络流量,引入了数据不一致: 为了避免此问题,请在使用
hard
和intr
挂载选项的情况下使用TCP。 - 最大文件大小限制: NFS版本2客户端能访问的最大文件只有2GB(带符号的32位偏移量)。 NFS V3客户端支持更大的文件(最多64位偏移量)。 最大支持的文件大小还取决于NFS服务器的本地文件系统。
- 在专业SAN环境或其他存储系统中使用NFS比在这种环境之外使用NFS更可靠。 但是,SAN环境中的NFS可能比直接连接或总线连接的非旋转存储更慢。
- 如果使用NFS,建议用NFS V4或更高版本。在部署到生产环境之前,也应彻底测试NFS设置。