当前位置：首页 > 文章列表 > 数据库 > MySQL > Mysql专栏 - Linux底层交互和Raid存储架构

Mysql专栏 - Linux底层交互和Raid存储架构

来源：SegmentFault 2023-01-10 08:13:50 0浏览收藏

你在学习数据库相关的知识吗？本文《Mysql专栏 - Linux底层交互和Raid存储架构》，主要介绍的内容就涉及到MySQL，如果你想提升自己的开发能力，就不要错过这篇文章，大家要知道编程理论基础和实战操作都是不可或缺的哦！

Mysql专栏 - Linux底层交互和Raid存储架构

概述

介绍mysql的随机读写和顺序读写，那一部分是随机读写，那一部分是顺序读写
linux的系统分层逻辑结构，以及和mysql系统的交互步骤。
Raid的存储结构简单了解，以及他对于mysql服务的影响。
补充关于too many connections问题的产生原因和解决办法。

mysql的随机读写和顺序读写

mysql在执行增删改查的时候，会从表空间的磁盘文件里面读取数据页，首先我们需要明白一点，虽然在表空间的磁盘文件的数据页上进行磁盘的时是随机读写，但是包括Redo log、 bin log 等这些日志文件其实在磁盘上是顺序读写的。

磁盘的随机读

随机读取一个数据页到缓存就是磁盘的随机读操作，因为数据页的位置并不是固定的可能在磁盘的任意一位置，所以整个读写性能十分差的，根据之前的介绍,当数据页读取之后放到buffer pool里面。

为了IO的性能，这里需要了解两个重要的性能指标：IOPS和响应延迟。IOPS 指的是存储系统每秒可以执行多少次磁盘读写操作，底层磁盘支持每秒执行1000个随机读写和200个差距是很大的。响应延迟说的则是一次IO请求之后多少时间进行响应，也是十分大的影响的，一秒200个读写是10MS完成和一次200读写却在1S完成响应差距也是非常大的。

redo日志是顺序写

虽然对于磁盘是随机读写到缓冲池，但是在缓存页更新了之后，这个数据是需要按照顺序写到redo log日志的，顺序写意味着读取的时候也可以顺序读。（关于redo log的细节将会在后续的文章介绍）磁盘顺序写的性能其实是很重要的，某种程度上来高速的顺序磁盘访问差不多可以赶上内存的读写性能，尤其是在数据库里用了os cache机制的情况下，也就是说就是redo log顺序写入磁盘之前，先是进入os cache，就是操作系统管理的内存缓存里。

关于os cache可以翻一翻之前的文章，他还有一个作用是如果innodb引擎中设置：innodb_flush_log_at_trx_commit 为 2，会在写入redo日志的时候把数据显写到os cache当中，并且在1S之后（可能）再把数据刷新回redo log的磁盘文件，但是这样在mysql宕机的时候会出现数据丢失的隐患....
另外这里在学习的时候查找了一下关于os cache以及application cache的速度消耗对比，在答案中讨论了缓存的有效性判定条件，以及什么时候才需要使用cache。感兴趣可以查看一下具体的文章内容：
https://stackoverflow.com/que...

最后我们根据上面的文字总结下面的图：

根据上面的说明，我们大致可以总结出下面两点：

写redo log的速度越快说明查询的sql性能就越高。
磁盘每秒可以写入越多的数据，也说明越高的性能。

Linux系统分层

下面我们进入正题，简单来说Linux的存储系统分为VFS层、文件系统层、Page Cache缓存层、通用Block层、IO调度层、Block设备驱动层、Block设备层，如下图：

mysql和linux交互步骤：

下面是mysql和llinux交互的大致流程：

VFS层：当mysql发起一次数据页的随机读写，一次redo log顺序读写的时候，实际上会把io请求交给linux的vfs层面。
文件系统：vfs会把io请求需按照对应的文件管理系统进行操作和读写。比如ext1、ext2、ext3
Page cache：文件系统会在page cache基于内存的缓存找所需的数据，基于内存缓存来执行读写，如果还没有此时会交给block层
Block层：在一层把你对文件的io请求转换为block io
io调度层：默认用的是CFS 公平调度算法，io调度完成之后，会决定那个io请求先执行那个后执行。

CFS调度器：采用完全公平调度算法，引入虚拟运行时间概念；
Deadline调度器：使用红黑树，把进程按照绝对截止期限进行排序，选择最小进程进行调度运行
实际情况下执行多个数据库请求的时候多个sql同时在io，所以建议生产环境把io调度算法换成 deadline调度，核心思想就是任何一个io不能随心所欲一直等待，在指定范围内他必须执行。

Block设备驱动层：此时可以执行io的请求的就会交给block设备驱动层，最后把驱动交给设备层
Block设备层：硬件设备完成了IO读写操作之后要不然是写要不然是读，最后就把响应经过上面的层级反向依次返回。

最终 MySQL可以得到本次IO读写操作的结果，最终的结构图如下所示：

ERROR 1040(HY000): Too many connections问题

下面补充一个比较常见的linux相关问题。

在专栏的第一篇介绍中我们知道数据库是存在连接池的概念，但是连接池的容量总归是有限的，出现这个报错说明连接池已经满了。

默认情况下每一台机器默认的连接池大小是200，每台java系统最多建立200个连接，如果是2台机器，最多400个连接。

关于这个设置的关键的参数是max_connections：比如最大连接数目是800.

实际上，在运行过程中通常会发现：

show variables like 'max_connections'

在线上的设置只有214，这是什么情况？为什么mysql会自动重置呢？其实是因为linux打开句柄的数量是1024导致只能连接214个。

如何解决上面的问题

在linux当中：执行命令

Ulimit -HSn 65535

可以修改句柄的配置，为了验证是否成功，可以通过下面的命令查看句柄的配置：

Cat /ect/security/limits.conf

Cat /etc/rc.load

为了保险起见，也可以在

my.cnf

的内部确保了

mac_connections

参数配置。

为什么最大连接数是214呢？

linux默认会限制你每个进程对机器资源的使用的，包括可以打开的文件句柄的限制，可以打开的子进程数的限制，网络缓存的限制，最大可以锁定的内存大小。

为了让mysql发挥最大的功效，句柄的设置值通常都是65535。

 所以我们平时可以用`ulimit`命令来设置每个进程被限制使用的资源量，用ulimit -a就可以看到进程被限制使用的各种资 源的量比如 core file size 代表的进程崩溃时候的转储文件的大小限制，max locked memory就是最大锁定内存大小，open files就是最大可以打开的文件句柄数量，max user processes就是最多可以拥有的子进程数量。

设置之后，我们要确保变更落地到/etc/security/limits.conf文件里，永久性的设置进程的资源限制所以执行