当binlog禁用时,mysql服务器大多停止工作

性能比我想在MySQL服务器上慢一点,我们不使用复制,也不需要时间点恢复。 所以一个推荐的提高性能的方法似乎是closuresbin-logging。 我在my.cnf中有以下内容:

## Replication / Transaction Logging # binlog_format = row log-bin = /var/lib/mysql/mysql-bin.log expire_logs_days = 3 sync-binlog = 1 

我注释了所有四行,并重新启动MySQL。 该服务启动正常,没有任何问题在任何错误日志或缓慢的查询日志中显示。 除了写入性能降低到无法使用的水平之外,一切看起来都很好。 它确实继续工作。 取消注释上述四行并重新启动服务立即恢复以前的性能级别。

以前的性能水平并不是我想要的,但我希望在closuresbin-logging的情况下,希望能够提高性能。

为什么会发生? 如何成功closures垃圾箱logging以获得性能?

眼镜:

  • 所有的表都是innodb(一些相当大的)
  • mysql版本14.14 Distrib 5.6.19,用于使用EditLine wrapper的debian-linux-gnu(x86_64)
  • Ubuntu 12.04 LTS服务器

同步二进制日志

当你注释掉sync-binlog = 1 ,发生了什么事?

你使sync_binlog的默认值为0.那么会发生什么? MySQL文档说:

sync_binlog的缺省值是0,它不会与磁盘同步,在这种情况下,服务器依赖于操作系统不时地刷新二进制日志的内容,就像其他文件一样。

这意味着mysqld是在操作系统的摆布刷新磁盘更改二进制日志。 这表示必须有许多文件打开( 运行lsof )操作系统必须刷新到磁盘。 MySQL的当前二进制日志必须处于需要定期刷新到磁盘的打开文件的日志堵塞的中间,特别是如果正在定期写入大量打开的文件。

MySQL文档进一步说:

值为1是最安全的select,因为在发生崩溃时,您最多会从二进制日志中丢失一个提交组。 但是,这也是最慢的select(除非磁盘有一个电池支持的caching,这使得同步非常快)。

这只是意味着由sync-binlog=1执行的对磁盘的刷新为服务器提供了一定的稳定性,因为磁盘更改正在刷新到磁盘,并释放了操作系统的执行情况。 没有它,mysqld具有与其他打开文件的进程(应用程序或操作系统)相同的优先级。

InnoDB的

这里是InnoDB的图片展示(来自Percona首席技术官Vadim Tkachenko)

InnoDB管道

您可能希望强制InnoDB更积极地刷新到磁盘,并仍然performance良好。

  • 将innodb_flush_method设置为O_DIRECT使InnoDB可以自行处理对磁盘的更改。 鉴于此,InnoDB将显式刷新到系统表空间(ibdata1)中的双写缓冲区以及缓冲池中表的.ibd文件。 在具有硬件RAID控制器和电池支持的写入caching的系统上,O_DIRECT可以帮助避免InnoDB缓冲池和操作系统的文件系统caching之间的双重缓冲。
  • 将innodb_write_io_threads设置为8(或16)
  • 将innodb_log_buffer_size设置为128M,以减less磁盘I / O
  • 将innodb_log_file_size设置为1G

因此,将这些设置添加到my.cnf(需要重新启动)

 [mysqld] innodb_flush_method = O_DIRECT innodb_write_io_threads = 8 innodb_log_buffer_size = 128M innodb_log_file_size = 1G 

结语

如果你想禁用二进制日志,调整InnoDB以更好的补偿