目录

sysbench压测-innodb_flush_log_at_trx_commit,sync_binlog参数对性能的影响

一、OLTP测试前准备

基本信息：

• 主机信息

CPU	内存	硬盘	系统版本	MySQL版本	sysbench版本
Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz *2	2G	虚拟机硬盘	CentOS release 6.9 (Final)	5.7.18	1.1.0-76

• sysbench 目录（/software/sysbench）

二、MySQL 数据落盘的过程

• 确认数据从InnoDB的内存到真正写到存储设备的介质上到底有哪些缓冲在起作用

从上图中，我们可以看到，数据InnoDB到磁盘需要经过

1.InnoDB buffer pool，Redo log buffer。这个是InnoDB应用系统本身的缓冲。
2.page cache /Buffer cache（可通过o_direct绕过）。这个是vfs层的缓冲。
3.Inode cache/directory buffer。这个也是vfs层的缓冲。需要通过O_SYNC或者fsync()来刷新。
4.Write-Back buffer。(可设置存储控制器参数绕过)
5.Disk on-borad buffer。(可通过设置磁盘控制器参数绕过)

这里我们使用术语“缓冲”(一般为buffer)来表示对数据写的暂存，使用术语“缓存”(一般为cache)来表示对数据读的暂存。顾名思义，由于底层存储设备和内存之间速率的差异，缓冲是用来暂“缓”对底层存储设备IO的“冲”击。缓存主要是在内存中暂“存”从磁盘读到的数据，以便接下来对这些数据的访问不用再次访问慢速的底层存储设备。

三、参数说明

• innodb_flush_log_at_trx_commit
  • innodb_flush_log_at_trx_commit目前支持3种不同的参数值0，1，2
  • innodb_flush_log_at_trx_commit设置为0，log buffer将每秒一次地写入log file中，并且log file的flush(刷到磁盘)操作同时进行.在事务提交时不执行从日志缓冲区到日志文件的写入.该模式下,由于进程调度策略问题,这个“每秒执行一次flush(刷到磁盘)操作”并不是保证100%的“每秒”.
  • innodb_flush_log_at_trx_commit设置为1，每次事务提交时MySQL都会把log buffer的数据写入log file，并且flush(刷到磁盘)中去.
  • innodb_flush_log_at_trx_commit设置为2，每次事务提交时MySQL都会把log buffer的数据写入log file.
  • innoDB日志刷新频率由控制 innodb_flush_log_at_timeout，它允许用户设置记录flush频率为N秒（其中 N是1 … 2700，为1的默认值）。但是，任何mysqld进程崩溃都可以丢失多达N几秒的事务。
• 安全问题
  • 当innodb_flush_log_at_trx_commit和sync_binlog 都为 1 时是最安全的，在mysqld服务崩溃或者服务器主机crash的情况下，binary log 只有可能丢失最多一个语句或者一个事务。但是鱼与熊掌不可兼得，双11 会导致频繁的io操作，因此该模式也是最慢的一种方式。
  • 当innodb_flush_log_at_trx_commit设置为0，mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失。
  • 当innodb_flush_log_at_trx_commit设置为2，只有在操作系统崩溃或者系统掉电的情况下，上一秒钟所有事务数据才可能丢失。

• sync_binlog
  • sync_binlog 的默认值是0，像操作系统刷其他文件的机制一样，MySQL不会同步到磁盘中去而是依赖操作系统来刷新binary log。
  • 当sync_binlog =N (N>0) ，MySQL 在每写 N次 二进制日志binary log时，会使用fdatasync()函数将它的写二进制日志binary log同步到磁盘中去。
  • 注意:
    • 如果启用了autocommit，那么每一个语句statement就会有一次写操作；否则每个事务对应一个写操作。
• innodb_flush_method
  • 目前支持4种不同的参数值：

    fdatasync 、O_DSYNC 、O_DIRECT 、O_DIRECT_NO_FSYNC

  • 日志刷新对应表

- innodb_flush_method数据文件和日志刷新对应表

四、Test性能

• 场景说明

  

• 所有场景图

- note：sync_binlog=1时，QPS和TPS性能明显比其他的弱5%-10%

• • innodb_flush_log_at_trx_commit={0，1，2} ；sync_binlog=0 场景图
    
    
    
    • note: innodb_flush_log_at_trx_commit=1时；性能最差
  • innodb_flush_log_at_trx_commit={0，1，2} ；sync_binlog=1 场景图
    
    
    
    • note：innodb_flush_log_at_trx_commit=1；sync_binlog=1 性能最差
  • innodb_flush_log_at_trx_commit=2 ；sync_binlog={0，1，2} 场景图
    
    
    
    • note：innodb_flush_log_at_trx_commit=2；sync_binlog={0，1，100} 这个需要根据业务来进行压测。
      

      五、总结

  • 对数据安全性要求非常高，而且磁盘IO写能力足够支持业务，比如订单,交易,充值,支付消费系统。配置双1模式
  • 当对数据安全性要求低和并发要求也不高时，可以配置innodb_flush_log_at_trx_commit=2，sync_binlog=0,让系统开决定刷新频率
  • 当磁盘IO无法满足业务需求时，推荐的做法是 innodb_flush_log_at_trx_commit=2 ，sync_binlog=N (N为500 或1000) 且使用带蓄电池后备电源的缓存cache，防止系统断电异常。