当binlog禁用时，mysql服务器通常会停止工作。
性能比我在mysql服务器上想要的要慢一些，而且我们不使用复制，也不需要实时恢复。因此，提高性能的一种推荐方法似乎是关闭回收站。我的my.cnf中有以下内容：
## Replication / Transaction Logging #
binlog_format = row
log-bin = /var/lib/mysql/mysql-bin.log
expire_logs_days = 3
sync-binlog = 1我注释掉了这四行并重新启动了mysql。服务启动良好，在任何错误日志或慢速查询日志中都没有任何问题。除了写性能下降到不可用的水平外，一切看起来都很好。尽管如此，它仍在继续工作。注释上述四行并重新启动服务，立即恢复了以前的性能水平。
不过，以前的性能水平并不是我想要的，我希望能够通过关闭bin日志来提高性能。
为什么会发生这种情况？如何成功地关闭bin日志以获得性能？
规格：
- 所有的表都是无害的(有些相当大)
- mysql 14.14远端5.6.19，用于debian gnu (x86_64)，使用EditLine包装器
- Ubuntu 12.04 LTS服务器
回答 1
Server Fault用户
发布于 2015-01-06 19:27:11
同步-binlog
当你评论sync-binlog = 1的时候，发生了什么？
您将同步_联木默认为0。然后会发生什么呢？MySQL文档说：
sync_binlog的默认值是0，它不与磁盘同步-在这种情况下，服务器依赖操作系统不时刷新二进制日志的内容，就像任何其他文件一样。
这意味着mysqld任由操作系统负责将磁盘更改刷新到二进制日志。这表明操作系统必须将大量文件打开(跑lsof)才能刷新到磁盘。当前用于MySQL的二进制日志必须处于打开文件的日志阻塞的中间，这些文件需要定期刷新到磁盘，特别是当许多打开的文件被定期写入时。
MySQL文档进一步指出：
值1是最安全的选择，因为在发生崩溃时，您最多会从二进制日志中丢失一个提交组。然而，它也是最慢的选择(除非磁盘有一个电池支持的缓存，这使得同步非常快)。
这仅仅意味着sync-binlog=1执行的磁盘刷新为服务器提供了一定的稳定性，因为磁盘更改被刷新到磁盘，并且释放了操作系统，执行得稍微好一些。没有它，mysqld具有与任何其他进程(应用程序或OS)相同的优先级，这些进程都有打开的文件。
InnoDB
以下是InnoDB的图片表示(来自Percona CTO Vadim Tkachenko)
您可能希望强迫InnoDB更积极地冲到磁盘上，并且仍然表现良好。
- 将诺姆b_同花顺_方法设置为
O_DIRECT使InnoDB处理自己对磁盘更改的刷新。根据图片，InnoDB将显式地刷新到系统表空间(ibdata1)中的双写缓冲区以及缓冲区池中表的.ibd文件。在具有硬件RAID控制器和电池支持的写缓存的系统上，O_DIRECT可以帮助避免InnoDB缓冲池和操作系统的文件系统缓存之间的双重缓冲。 - 将诺姆b_写_io_线程设置为8(或16)
- 将诺姆b_日志_缓冲器_大小设置为128 m以减少磁盘I/O
- 将诺姆b_日志_文件_大小设置为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以更好地进行补偿。
https://serverfault.com/questions/656505
复制相似问题
腾讯云开发者
