mysql binlog日志优化及思路

释放双眼,带上耳机,听听看~!

在数据库安装完毕,对于binlog日志参数设置,有一些参数的调整,来满足业务需求或使性能最大化。Mysql日志主要对io性能产生影响,本次主要关注binlog 日志。

查一下二进制日志相关的参数  

   mysql> show variables like '%binlog%';

+——————————–+———————-+

| Variable_name                  | Value                |

+——————————–+———————-+

| binlog_cache_size              | 1048576              |

| innodb_locks_unsafe_for_binlog | OFF                  |

| max_binlog_cache_size          | 18446744073709547520 |

| max_binlog_size                | 1073741824           |

| sync_binlog                    | 0                    |

+——————————–+———————-+

5 rows in set (0.14 sec)

其中innodb_locks_unsafe_for_binlog 参数是innodb存储引擎特有的与binlog相关的参数,默认是关闭的

 

Binlog_cache_size:默认大小是37268即32K.我们计算一下上面binlog_cache_size参数大小,1048576/1024/1024 = 1M,根据事务需要调整大小。次参数表示在事务中容纳二进制日志sql语句的缓存大小。那么怎么理解二进制日志缓存,就是服务器支持事务存储引擎并且服务器启用了二进制日志(-log-bin选项)的前提下为每个客户端分配的内存,是每个client都可以分配设置大小的binlog cache空间。我们可以通过以下两个状态变量判断binlog_cache_size的使用情况:

1  binlog_cache_use: Thenumber of transactions that used the temporary binary log cache.(使用二进制日志缓存的事务的数量)

  2   Binlog_cache_disk_use: The number oftransactions that used the binary log cache but that exceeded the value of binlog_cache_size andused a temporary file to store changes from the transaction.

 使用二进制日志缓存并且值达到了binlog_cache_size设置的值,用临时文件存储来自事务的变化这样的事务数量

 

Max_binlog_cache_size: 默认值是18446744073709547520,这个值很大,够我们使用的了。此参数和binlog_cache_size相对应,代表binlog所能使用的cache最大使用大小。如果系统中事务过多,而此参数值设置有小,则会报错。

 

Max_binlog_size: 1073741824=1G  binlog的最大值,一般设置为512M或1G,一般不能超过1G。此参数不能非常严格控制binlog的大小,特别是在遇到大事务时,而binlog日志又到达了尾部,为了保证事务完整性,不切换日志,把所有sql都写到当前日志。这根oracle redo日志有点不一样(感兴趣的可以google)。Mysql记录的是mysql数据库逻辑变化信息,称之为event,实际上就是引起数据库变化的query语句。

 

Sync_binlog: 参数不仅影响数据库的性能,而且还影响数据库数据的完整性。Sync_binlog参数选项有如下选择

1 Sync_binlog=0,这意味着当事务提交之后,mysql不做fsync(文件系统同步)之类的磁盘同步指令刷新binlog_cache中的信息到磁盘,而让filesystem自行决定什么时候来做同步,或者cache满了之后才同步到磁盘。

2 sync_binlog=n,当每进行n次提交之后,mysql将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

Sync_binlog=0,这是数据库默认设置,性能也是最好的,也是最危险的。一旦系统crash,在binlog_cache中的所有binlog信息都会被丢失。当synn_binlog=1的时候,是最安全性能消耗也最大,完成一个事务,同步一次。系统crash了,也只是丢掉了未完成的事务信息。没坐过这方面的测试,设置为1和0在性能方面的差距,有做过的说在高并发系统中,两种设置性能可高达5倍甚至更多。

 这需要我们来做出选择,是要性能最好,还是最安全。

 资料:《mysql性能调优与架构设计》

 http://dev.mysql.com/doc/refman/5.0/en/server-status-variables.html

http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html

给TA打赏
共{{data.count}}人
人已打赏
安全运维

OpenSSH-8.7p1离线升级修复安全漏洞

2021-10-23 10:13:25

安全运维

设计模式的设计原则

2021-12-12 17:36:11

个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索