MySQL(InnoDB剖析):54---性能调优之(合理地设置RAID)

一、RAID类型

  • RAID(Redundant Array of Independent Disks,独立磁盘冗余数组)的基本思想就是把多个相对便宜的硬盘组合起来,成为一个磁盘数组,使性能达到甚至超过一个价格昂贵、容量巨大的硬盘。由于将多个硬盘组合成为一个逻辑扇区,RAID看起来就像一个单独的硬盘或逻辑存储单元,因此操作系统只会把它当作一个硬盘
  • RAID的作用是:
    • 增强数据集成度
    • 增强容错功能
    • 增加处理量或容量
  • 根据不同磁盘的组合方式,常见的RAID组合方式可分为:RAID 0、RAID 1、RAID 5、RAID 10和RAID 50等

RAID0

  • RAID0将多个磁盘合并成一个大的磁盘,不会有冗余,并行IO,速度最快
  • RAID0亦称为带区集,它将多个磁盘并列起来,使之成为一个大磁盘,如下图所示在存放数据时,其将数据按磁盘的个数进行分段,同时将这些数据写进这些盘中
  • 所以,在所有的级别中,RAID0的速度是最快的。但是RAID0没有冗余功能,如果一个磁盘(物理)损坏,则所有的数据都会丢失
  • 理论上,多磁盘的效能就等于(单一磁盘效能)×(磁盘数),但实际上受限于总线IO瓶颈及其他因素的影响,RAID效能会随边际递减。也就是说,假设一个磁盘的效能是50MB/s,两个磁盘的RAID0效能约96MB/s,三个磁盘的RAID0也许是130MB/s而不是150MB/s

RAID1

  • RAID1两组以上的N个磁盘相互作为镜像(下图所示),上图RAID0结构在一些多线程操作系统中能有很好的读取速度,但写入速度略有降低。除非拥有相同数据的主磁盘与镜像同时损坏,否则只要一个磁盘正常即可维持运作,可靠性最高。RAID1就是镜像,其原理为在主硬盘上存放数据的同时也在镜像硬盘上写相同的数据。当主硬盘(物理)损坏时,镜像硬盘则代替主硬盘的工作。因为有镜像硬盘做数据备份,所以RAID1的数据安全性在所有的RAID级别上来说是最好的。但是,无论用多少磁盘作为RAID1,仅算一个磁盘的容量,是所有RAID中磁盘利用率最低的一个级别

RAID5

  • RAID5是一种存储性能、数据安全和存储成本兼顾的存储解决方案。它使用的是 Disk Striping(硬盘分区)技术。RAID5至少需要三个硬盘,RAID5不对存储的数据进行备份,而是把数据和相对应的奇偶校验信息存储到组成RAID5的各个磁盘上,并且奇偶校验信息和相对应的数据分别存储于不同的磁盘上。当RAID5的一个磁盘数据发生损坏后,利用剩下的数据和相应的奇偶校验信息去恢复被损坏的数据。RAID5可以理解为是RAID0和RAID1的折中方案。RAID5可以为系统提供数据安全保障,但保障程度要比镜像低而磁盘空间利用率要比镜像高。RADS5具有和RAD0相近似的数据读取速度,只是多了一个奇偶校验信息,写入数据的速度相当慢,若使用Write Back可以让性能改善不少。同时,由于多个数据对应一个奇偶校验信息,RAID5的磁盘空间利用率要比RAID1高,存储成本相对较低

RAID10

  • RAID10和RAD01:RAID10是先镜像再分区数据,将所有硬盘分为两组,视为RAID0的最低组合,然后将这两组各自视为RAID1运作
  • RAID10有着不错的读取速度,而且拥有比RAID0更高的数据保护性。RAID01则与RAID10的程序相反,先分区再将数据镜射到两组硬盘。RAID01将所有的硬盘分为两组,变成RAID1的最低组合,而将两组硬盘各自视为RAID0运作。RAID01比RAID10有着更快的读写速度,不过也多了一些会让整个硬盘组停止运转的几率,因为只要同一组的硬盘全部损毁,RAID01就会停止运作,而RAID10可以在牺牲RAID0的优势下正常运作。RAID10巧妙地利用了RAID0的速度及RAID1的安全(保护)两种特性,它的缺点是需要较多的硬盘,因为至少必须拥有四个以上的偶数硬盘才能使用。RAID 10和RAID 01的结构如下图所示:

  • RAID50

  • RAID50也被称为镜像阵列条带,由至少六块硬盘组成,像RAID0样,数据被分区成条带,在同一时间内向多块磁盘写人;像RAID5一样,也是以数据的校验位来保证数据的安全,且校验条带均匀分布在各个磁盘上,其目的在于提高RAID5的读写性能

  • 对于数据库应用来说,RAID10是最好的选择,它同时兼顾了RAID1和RAID0的特性。但是,当一个磁盘失效时,性能可能会受到很大的影响,因为条带(strip)会成为瓶颈。我曾在生产环境下遇到过的情况是,两台负载基本相同的数据库,一台正常的服务器磁盘IO负载为20%左右,而另一台服务器IO负载却高达90%

二、RAID Write Back功能

  • RAID Write Back功能是指RAID控制器能够将写入的数据放入自身的缓存中,并把它们安排到后面再执行。这样做的好处是,不用等待物理磁盘实际写入的完成,因此写入变得更快了。对于数据库来说,这显得十分重要。例如,对重做日志的写人,在将sync_binlog设为1的情况下二进制日志的写入、脏页的刷新等都可以使性能得到明显的提升
  • 但是,当操作系统或数据库关机时,Write Back功能可能会破坏数据库的数据。这是由于已经写入的数据库可能还在RAID卡的缓存中,数据可能并没有完全写入磁盘,而这时故障发生了。为了解决这个问题,目前大部分的硬件RAID卡都提供了电池备份单元(BBU,Battery Backup Unit),因此可以放心地开启 Write Back的功能。不过我发现每台服务器的出厂设置都不相同,应该将RAID设置要求告知服务器提供商,开启一些认为需要的参数
  • 如果没有启用 Write Back功能,那么在RAID卡设置中显示的就是Write Through Write Through没有缓冲写入,因此写入性能可能不是很好,但它却是最安全的写入
  • 即使用户开启了 Write Back功能,RAID卡也可能只是在 Write Through模式下工作。这是因为安全使用 Write back的前提是RAID卡有电池备份单元。为了确保电池的有效性,RAID卡会定期检查电池状态,并在电池电量不足时对其进行充电,在充电的这段时间内会将 Write Back功能切换为最为安全的 Write Through
  • 用户可以在没有电池备份单元的情况下强制启用 Write Back功能,也可以在电池充电时强制使用 Write Back功能,只是写入是不安全的。用户应该非常确信这点,否则不应该在没有电池备份单元的情况下启用 Write back
  • 可以通过插入20W的记录来比较 Write back和 Write Through的性能差异:

  • 首先创建一个向表t插入20W记录的存储过程,并在 Write Back和 Write Through的设置下分别进行测试,最终测试结果如下图所示:

  • 由于批量插入不是在一个事务中完成的,而是直接用命令CALP来运行的,因此数据库实际执行了20W次的事务。很明显可以看到,在 Write Back模式下执行时间只需要43秒,而在 Write Through模式下执行时间需要31分钟,大约有40多倍的差距
  • 当然,在 Write Through模式下,通过将参数 innodb_flush_log_at_trx_commit设置为0也可以提高执行存储过程P的性能,这时只需要68秒了。因为,在此设置下,重做日志的写入不是发生在每次事务提交时,而是发生在后台 master线程每秒钟自动刷新的时候,因此减少了物理磁盘的写入请求,所以执行速度也可以有明显的提高

三、RAID配置工具

  • 对RAID卡进行配置可以在服务器启动时进入一个类似于BIOS的配置界面,然后再对其进行各种设置。此外,很多厂商都开发了各种操作系统下的软件对RAID进行配置,如果用户使用的是LSI公司生产提供的RAID卡,则可以使用 MegaCLI工具来进行配置。
  • MegaCLI为多个操作系统提供了支持,对 Windows操作系统还提供了GUI界面的配置环境,因此相对来说比较简单。这里主要介绍命令行下 MegaCLI的使用,在Windows下同样可以使用命令 MegaCLI.exe
  • 使用 MegaCL查看RAID卡的信息:
    • 这里只列出了输出的一小部分。通过命令可以看到RAID卡的一些硬件配置,如这块RAID卡的型号是MegaRAID SAS 8708ELP,缓存大小时256MB。还可以看到一些默认的配置,如默认启用的Write Policy 为WB(Write Back)等

  • MegaLI还可以用来查看当前物理磁盘的信息,如:
    • 可以看到当前使用的磁盘型号是SEAGATE ST3300655SS,可以从这个型号继续找到这个硬盘的具体信息,如在希捷官网上可以看到这块硬盘大小时3.5寸的,转速为15000,硬盘的Cache为16MB,随机读取的寻道时间是3.5秒,随机写入的寻道时间是4.0毫秒等

  • 此外,还可以通过下面的命令来查看是否开启了Write Back的功能:
    • 通过结果可以发现当前开启了RAID卡的 Write Back功能,并且当BBU有问题时或在充电时禁用 Write Back功能。此外,这里还显示了不需要启用RAID卡的预读功能,写入方式为直接写入

  • 通过下面的命令可以对当前的写入策略进行调整:

  • 特别需要注意地是,当RAID卡的写人策略从 Write Back切换为 Write Through时,该更改立即生效。然而从 Write Through切换为 Write Back时,必须重启服务器才能使其生效
发布了1481 篇原创文章 · 获赞 1026 · 访问量 38万+

猜你喜欢

转载自blog.csdn.net/qq_41453285/article/details/104381994