首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >innodb_flush_log_at_trx_commit =1比innodb_flush_log_at_trx_commit = 2更能磨损SSD吗?

innodb_flush_log_at_trx_commit =1比innodb_flush_log_at_trx_commit = 2更能磨损SSD吗?
EN

Database Administration用户
提问于 2016-11-25 04:43:21
回答 3查看 2.8K关注 0票数 1

我正在运行一个Nextcloud实例,当很多小文件被同步时,我的同步速度很慢。我发现innodb_flush_log_at_trx_commit = 1要对此负责,所以我不得不设置innodb_flush_log_at_trx_commit = 2。现在,我正在考虑将我的数据库移动到SSD。我想确认一下,我确实遇到了访问时间问题。

innodb_flush_log_at_trx_commit设置为1时,是否将相同数量的数据写入磁盘,就像将其设置为2一样?

EN

回答 3

Database Administration用户

回答已采纳

发布于 2016-11-25 06:02:39

你刚刚问

当innodb_flush_log_at_trx_commit设置为1时,是否将相同数量的数据写入磁盘,就像将其设置为2一样?

答案是肯定的,因为这是个拙劣的问题。瓶颈在哪里?

请看一下InnoDB架构( Percona CTO Vadim Tkachenko提供)

请注意InnoDB内存侧的右下角。是日志缓冲区。日志信息在哪里被刷新?看看InnoDB磁盘侧的左上角。是重做日志。

为了提高InnoDB的写入性能,请注意以下建议:

建议#1

默认情况下,日志缓冲区大小(按诺姆b_日志_缓冲器_大小大小)为8M (8388608)

请将诺姆b_日志_缓冲器_大小提高到64M

建议#2

默认情况下,重做日志(按诺姆b_日志_文件_大小大小)为48M (50331648)

请将诺姆b_日志_文件_大小提高到1G

如何实现

步骤01 :将这些选项添加到/etc/my.cnf (或my.ini for Windows)中

代码语言:javascript
运行
复制
[mysqld]
innodb_log_file_size=1G
innodb_log_buffer_size=64M

步骤2:登录到MySQL并运行

代码语言:javascript
运行
复制
mysql> SET GLOBAL innodb_fast_shutdown = 0;

步骤03 :关闭MySQL

代码语言:javascript
运行
复制
service mysql stop

或从Windows命令行作为管理员

代码语言:javascript
运行
复制
C:\> net stop mysql

步骤04 :重做日志文件的重命名

代码语言:javascript
运行
复制
mv ib_logfile0 ib_logfile0.bak
mv ib_logfile1 ib_logfile1.bak

或从Windows命令行作为管理员

代码语言:javascript
运行
复制
rename ib_logfile0 ib_logfile0.bak
rename ib_logfile1 ib_logfile1.bak

步骤05:启动MySQL

代码语言:javascript
运行
复制
service mysql start

或从Windows命令行作为管理员

代码语言:javascript
运行
复制
C:\> net start mysql

注意:这个步骤可能需要2-3分钟,因为它正在创建两个不同的日志文件,每个1G。

为什么更改这些设置?

当SSD对小型重做日志执行随机写入时,损耗将被记录到磁盘的一个部分。使重做日志扩展日志缓冲区的写操作。使日志缓冲区变大,减少写入频率,以换取写入数据量的增加。

如果一个完整的MySQL实例位于SSD中,那么您必须进行这种调优,使用混合磁盘布局(请参阅我以前的post MySQL on SSD -缺点是什么?)。

更多信息

有关更多的MySQL调优选项,请阅读优化InnoDB磁盘I/O上的InnoDB文档。

票数 1
EN

Database Administration用户

发布于 2016-11-25 06:02:13

代码语言:javascript
运行
复制
innodb_flush_logs_at_trx_commit
When 1:
for each Txn Commit { 
    - Write log buffer to log file
    - flush log files to disk
    }

When 0:
Approx every second {
    - Write log buffer to log file
    - flush log files to disk
    }

When 2:
    {
    - For each commit: { Write log buffer to log file }
    - Appx every sec: { flush log files to disk }
    }

因为刷新到磁盘操作大约每秒只发生一次,因此在操作系统崩溃或电源中断时,您可能会损失多达一秒的事务。

嗯,我刚刚从文档复制了以上所有内容;)

不管怎么说,现在谈谈你的观点。

  • innodb_flush_logs_at_trx_commit改变了:在酸和速度之间的选择。对于performance.okay,您将其改为2,但您知道风险。
  • 转移到SSD:他们被证明比他们的祖先更快..。考虑到这一点,您最好在SSD上使用更好的innodb_flush_logs_trx_commit值1(默认)对您的流量进行基准测试。
  • 同样的数据量.?:是的,数据的数量当然是一样的,尽管你可能想问别的问题。我们知道,它如何提高性能是通过减少磁盘操作数。

因此,“innodb_flush_log_at_trx_commit =1比innodb_flush_log_at_trx_commit =2磨损SSD吗?”->,无论磁盘类型如何,值1的工作量(磁盘操作数)比值2都要大,因此性能差异很大。

票数 2
EN

Database Administration用户

发布于 2016-11-26 06:00:06

一种“商品”的SSD可能会磨损。“企业”SSD几乎可以连续几年编写。

任何SSD有一个限制,多少次,一个块可以写之前,它是损坏,无法修复。(阅读没有问题。)

一个企业SSD有固件做“磨损平整”。它实际上是在移动街区,因此每个街区以相同的、缓慢的速度磨损。这是足够慢,它将需要数年的磨损。

这些块是通过查找表找到的。

因此,对于企业级SSD,无论您是在冲击日志、双写缓冲区还是SSD上的任何其他块,都不重要。对于随意使用来说,便宜的SSD不会有问题。

票数 0
EN
页面原文内容由Database Administration提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://dba.stackexchange.com/questions/156330

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档