Mysql磁盘IO占用过高的一种解决办法

Posted 时栈

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Mysql磁盘IO占用过高的一种解决办法相关的知识,希望对你有一定的参考价值。

背景:

在之前的主从同步过程中(Mysql的多级复制),从数据库Z存在磁盘IO占用过高的问题。

磁盘IO在同步期间占用率达到100%,且数据存在滞后,不能实现实时更新。

从数据库的磁盘为机械硬盘,读写性能相对于固态硬盘要差一点。

一、原因:

可能是因为mysql在日志在每次事务提交时,都会将其写入并刷新到磁盘,造成磁盘IO的高占用。

二、查看配置:

通过在MySQL命令行运行以下命令:

show variables like 'sync_binlog';

可以看到:sync_binlog 的值为1。

该值意味着:启用在提交事务之前将二进制日志同步到磁盘。这是最安全的设置,但是会造成磁盘的较高占用。

show variables like 'innodb_flush_log_at_trx_commit';

可以看到:innodb_flush_log_at_trx_commit 的值为1。

该值意味着:日志会在每次事务提交时写入并刷新到磁盘。

三、配置参数含义:

sync_binlog:控制MySQL服务器将二进制日志同步到磁盘的频率

默认值:1
最小值:0
最大值:4294967295

sync_binlog=0:禁用 MySQL 服务器将二进制日志同步到磁盘。相反,MySQL服务器依赖于操作系统不时将二进制日志刷新到磁盘,就像它对任何其他文件所做的那样。此设置提供最佳性能,但在发生电源故障或操作系统崩溃时,服务器可能已提交尚未同步到二进制日志的事务。

sync_binlog=1:启用在提交事务之前将二进制日志同步到磁盘。这是最安全的设置,但由于磁盘写入次数增加,可能会对性能产生负面影响。如果发生电源故障或操作系统崩溃,二进制日志中缺少的事务仅处于就绪状态。这允许自动恢复例程回滚事务,从而保证二进制日志中不会丢失任何事务。

sync_binlog=N,其中 N 是 0 或 1 以外的值:收集二进制日志提交组后,二进制日志将同步到磁盘。如果发生电源故障或操作系统崩溃,服务器可能已提交尚未刷新到二进制日志的事务。由于磁盘写入次数增加,此设置可能会对性能产生负面影响。值越高,性能越高,但数据丢失的风险也会增加。

innodb_flush_log_at_trx_commit:控制提交操作的严格 ACID 合规性与重新排列并批量完成与提交相关的 I/O 操作时可能实现的更高性能之间的平衡。

默认值为1

有效值为:0、1、2

可以通过更改默认值来获得更好的性能,但随后可能会在崩溃中丢失事务。

innodb_flush_log_at_trx_commit=1 :完全符合 ACID 所必需的。日志在每次事务提交时写入并刷新到磁盘。

innodb_flush_log_at_trx_commit=0:每秒将日志写入磁盘并刷新一次。尚未刷新其日志的事务可能会在崩溃中丢失。

innodb_flush_log_at_trx_commit=2:在每次事务提交后写入日志,并每秒刷新一次到磁盘。尚未刷新其日志的事务可能会在崩溃中丢失。

对于设置 0 和 2,不能 100% 保证每秒一次刷新。由于 DDL 更改和其他内部活动导致独立于innodb_flush_log_at_trx_commit设置刷新日志,刷新可能会更频繁地发生,有时由于计划问题而降低刷新频率。如果每秒刷新一次日志,则崩溃时最多可能会丢失一秒钟的事务。如果刷新日志的频率高于或低于每秒一次的频率,则可能丢失的事务量会相应地变化。

四、通过修改配置解决问题:

注意:这种解决办法是在牺牲数据库安全的前提下,提高磁盘的性能!!!更改配置可能会带来更高的数据丢失风险!!!

可以通过以下两条命令修改配置。 

set global sync_binlog=你希望的值;
set global innodb_flush_log_at_trx_commit=你希望的值;

更多设置请参考:

MySQL的二进制日志记录选项和变量

以上是关于Mysql磁盘IO占用过高的一种解决办法的主要内容,如果未能解决你的问题,请参考以下文章

mysql占用磁盘IO过高的解决办法

主机sql数据库占用磁盘IO读写过高,怎么解决?

io等待为啥引发cpu过高

swap空间占用过高解决方案

主机sql数据库占用磁盘IO读写过高,怎么解决?

mysql占用服务器cpu过高的原因以及解决办法