在 mysql 服务器上,性能比我想要的要慢一点,我们不使用复制,也不需要时间点恢复。因此,建议的一种提高性能的方法似乎是关闭 bin-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。服务启动正常,没有任何错误日志或慢查询日志表明存在任何问题。一切看起来都很好,只是写入性能下降到无法使用的水平。但它确实继续工作。取消注释上述四行并重新启动服务后,立即恢复了以前的性能水平。
但是以前的性能水平不是我想要的,我希望通过关闭 bin-logging 来实现性能提升。
为什么会发生这种情况?如何成功关闭 bin 日志记录以提高性能?
眼镜:
- 所有表都是 innodb(有些相当大)
- mysql Ver 14.14 Distrib 5.6.19,适用于 debian-linux-gnu (x86_64),使用 EditLine 包装器
- Ubuntu 12.04 LTS 服务器
答案1
同步 binlog
当您注释掉时sync-binlog = 1
,发生了什么?
你做了sync_binlog默认为 0。然后会发生什么?MySQL 文档说:
sync_binlog 的默认值为 0,表示不同步到磁盘 - 在这种情况下,服务器依靠操作系统像任何其他文件一样不时刷新二进制日志的内容。
这意味着 mysqld 只能依靠操作系统来将磁盘更改刷新到二进制日志中。这表明必须有大量文件打开(跑步lsof
),操作系统必须将其刷新到磁盘。MySQL 的当前二进制日志必须位于需要定期刷新到磁盘的打开文件日志拥堵的中间,尤其是如果许多打开的文件正在定期写入。
MySQL 文档进一步指出:
值 1 是最安全的选择,因为一旦发生崩溃,您最多会丢失二进制日志中的一个提交组。但是,这也是最慢的选择(除非磁盘有电池支持的缓存,这会使同步非常快)。
这仅仅意味着执行的刷新到磁盘操作为sync-binlog=1
服务器提供了一定的稳定性,因为磁盘更改被刷新到磁盘并释放了操作系统,性能略有提高。没有它,mysqld 的优先级与任何其他打开文件的进程(应用程序或操作系统)相同。
数据库引擎InnoDB
以下是 InnoDB 的图示(来自 Percona 首席技术官 Vadim Tkachenko)
您可能希望强制 InnoDB 更积极地刷新到磁盘并保持良好的性能。
- 放innodb_flush_method使
O_DIRECT
InnoDB 自行处理磁盘更改刷新。如图所示,InnoDB 将明确刷新到系统表空间 (ibdata1) 中的双写缓冲区以及.ibd
缓冲池中的表文件。在具有硬件 RAID 控制器和电池支持的写入缓存的系统上,O_DIRECT 可以帮助避免 InnoDB 缓冲池和操作系统的文件系统缓存之间的双重缓冲。 - 放innodb_write_io_threads到 8(或 16)
- 放innodb_log_buffer_size增加到 128M 以减少磁盘 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 以更好地刷新